Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge of fernomac/ion-go #26

Merged
merged 57 commits into from
May 20, 2020
Merged

Merge of fernomac/ion-go #26

merged 57 commits into from
May 20, 2020

Conversation

therapon
Copy link
Contributor

@therapon therapon commented May 8, 2020

Description of changes:

Brings in all the code from fernomac/ion-go

  1. Removes existing code (backed up on branch original-repo-bkp)
  2. Merge's fernomac/ion-go and keeps history from both repos. Fixes the following conflicts
    • LICENSE - were almost identical, some extra lines and an ending sentence
    • README - did my best as a first pass.
    • NOTICE - kept ours
  3. Moved the code under ion folder
    • updated path in tests for ion-test
  4. Updated ion-tests to latest commit
    • updated blacklist
    • filtered files with suffix md
  5. Added empty internal folder for private packages

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the Apache 2.0 license.

@therapon therapon marked this pull request as ready for review May 8, 2020 04:18
@codecov-io
Copy link

codecov-io commented May 8, 2020

Codecov Report

Merging #26 into master will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##           master      #26   +/-   ##
=======================================
  Coverage   71.81%   71.81%           
=======================================
  Files          22       22           
  Lines        4528     4528           
=======================================
  Hits         3252     3252           
  Misses        791      791           
  Partials      485      485           

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0cddde4...0cddde4. Read the comment docs.

Copy link
Contributor

@fernomac fernomac left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code looks good to me, I'm excited to have this officially maintained!

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

I would, however, like to explicitly opt out of this bit. You are welcome to use, modify, etc my parts of this "contribution" under the terms of the Apache license I applied to it, and only under those terms.

Specifically, section 4D of that license asks you to include the Copyright 2019 David Murray from my NOTICE file in any redistributions. Standard practice and my preference would be for you to include that line in your NOTICE file, alongside the copyright notice for any modifications made by Amazon.

Fix that up and I'm happy to approve!

README.md Outdated Show resolved Hide resolved
@therapon
Copy link
Contributor Author

therapon commented May 8, 2020

Code looks good to me, I'm excited to have this officially maintained!

Great.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

I would, however, like to explicitly opt out of this bit. You are welcome to use, modify, etc my parts of this "contribution" under the terms of the Apache license I applied to it, and only under those terms.

Sorry that is the template that I skip for the common case of a PR. Updated to read:

"By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the Apache 2.0 license."

Specifically, section 4D of that license asks you to include the Copyright 2019 David Murray from my NOTICE file in any redistributions. Standard practice and my preference would be for you to include that line in your NOTICE file, alongside the copyright notice for any modifications made by Amazon.

Fix that up and I'm happy to approve!

You are right, since there was a NOTICE file to begin with. Updated.

fernomac
fernomac previously approved these changes May 8, 2020
Copy link
Contributor

@fernomac fernomac left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome, thanks!

@fernomac
Copy link
Contributor

Had a bit of free time yesterday and added support for pretty-printing and a first draft of an ion-go CLI tool. Once this is merged I'll rebase and send them over here as PRs.

almann
almann previously approved these changes May 12, 2020
Copy link
Contributor

@almann almann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall this seems reasonable based on what we discussed and what I could see (I looked mostly at your commits).

I was unable to comment on the file, but do we need internal/.keep since we seem to be eliminating that module.

@therapon
Copy link
Contributor Author

I was unable to comment on the file, but do we need internal/.keep since we seem to be eliminating that module.

During an offline discussion there was a mention for creating a private package. I seeded the folder as a convenience. I can take it off now and we can add it later if needed.

@fernomac
Copy link
Contributor

FWIW I did end up sticking a small bit of code in internal/ in the aforementioned CLI tool branch. Would be fine to expose from ion/ if you wanted to though.

mrutter-amzn
mrutter-amzn previously approved these changes May 15, 2020
Copy link
Contributor

@mrutter-amzn mrutter-amzn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nothing that seems like it should block the merge. Several things to cut issues about to discuss.

README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
if err != nil {
panic(err)
}
fmt.Printf("--- t:\n%v\n\n", t)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These Printfs should be followed with a comment that shows what would be printed. The code can't be copy/pasted into a playground because it relies on an external library.

README.md Show resolved Hide resolved
Comment on lines +68 to +71
// Next advances the Reader to the next position in the current value stream.
// It returns true if this is the position of an Ion value, and false if it
// is not. On error, it returns false and sets Err.
Next() bool
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be slightly more idiomatic and user-friendly to return the Type from Next() and have one of the possible values indicate error.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was following the pattern of sql.Rows, and personally find that style to be friendlier than (what I imagine to be) the alternative?

for r.Next() {
   switch r.Type() { ... }
}

if r.Err() {
  return r.Err()
}

vs

for {
  t := r.Next()
  if t == ion.ErrorType {
    return r.Err()
  }
  if t == ion.EndOfSequenceType {
    break
  }
  switch t { ... }
}

(Unless I'm misunderstanding what you're saying, which is entirely possible. :))

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking more like:

for {
    switch r.Next() {
        case ion.ErrorType:
            return r.Err()
        case ion.EndOfSequenceType:
            return nil
        case ...
    }
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which if you think about it could be simplified to

for {
    switch r.Next() {
        case ion.ErrorType, ion.EndOfSequenceType:
            return r.Err()
        case ...
    }
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah. That's better than my attempt, although I still prefer things the sql.Rows way. Not my problem any more so feel free to change it if you disagree. :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I made the suggestion because it is similar to text.Scanner and I was thinking that the Reader is kind of like an ion.Scanner. I don't think that me saying my suggestion was more idiomatic was fair. They are both idiomatic approaches.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Created #28

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume Type should be mapping to Ion Types.
In case of EndOfSequenceType or ErrorType could we return NoType ?
When I check ion-dotnet, I see we have similar logic for MoveNext() in BinaryReader and TextReader.

Comment on lines +24 to +25
// UnmarshalStr unmarshals Ion data from a string to the given object.
func UnmarshalStr(data string, v interface{}) error {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not really necessary and adds another function to the Unmarshal story.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#29

Comment on lines +37 to +52
// A Decoder decodes go values from an Ion reader.
type Decoder struct {
r Reader
}

// NewDecoder creates a new decoder.
func NewDecoder(r Reader) *Decoder {
return &Decoder{
r: r,
}
}

// NewTextDecoder creates a new text decoder. Well, a decoder that uses a reader with
// no shared symbol tables, it'll work to read binary too if the binary doesn't reference
// any shared symbol tables.
func NewTextDecoder(in io.Reader) *Decoder {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think that the decoder story is clear. What if I have binary data that is composed of multiple Ion datagrams each one should decode into an instance of a struct? What is the binary story? If the reader is supposed to be able to determine text or binary, then why are there multiple ways to create a Decoder?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Decoders read one value at a time, without respect to datagrams (the symbol table gets reset under the covers when we hit a new BVM, but that isn't exposed up through the Reader). I didn't have a use case for decoding an entire datagram at a time, if you do please feel free to refactor to support that.

NewTextDecoder is a convenience since I was mostly decoding text Ion and got sick of typing NewDecoder(NewReader(in)). :) It's not well-named, feel free to change or delete it.

Copy link
Contributor Author

@therapon therapon May 17, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Encode/Decode as well as the Marshall/Unmarshall are a good seed and is already on our todo list. #30

Comment on lines +55 to +56
// FieldName sets the field name for the next value written.
FieldName(val string) error
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SetFieldName or StartField?

Comment on lines +111 to +112
// Finish finishes writing values and flushes any buffered data.
Finish() error
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems like the expectation is that there would be no more writes after a call to Finish. If that is the case, then Close seems like a better option.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's the direct equivalent of the finish method from ion-java; when writing binary Ion without a pre-canned local symbol table, you might want to Finish periodically to avoid buffering the whole output in memory.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering if Flush() error would be a more idiomatic alternative then.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#31

@therapon therapon dismissed stale reviews from mrutter-amzn and almann via 749c0a7 May 17, 2020 05:39
Copy link
Contributor Author

@therapon therapon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks to me that merging this as a seed is ok with the majority of reviewers. I added some minor fixes and created issues for comments made.

Unless I hear otherwise, I plan to merge this PR by Tuesday (05/19).

@therapon therapon merged commit e32dee6 into amazon-ion:master May 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants