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

improve deserialize error message #31374

Merged
merged 3 commits into from
Apr 4, 2019
Merged

improve deserialize error message #31374

merged 3 commits into from
Apr 4, 2019

Conversation

GregPlowman
Copy link
Contributor

Ref: #31337 (comment)

The values were written with the same Serializer context, so there can be shared references within the stream. They need to be deserialized using the same context object as well.

If this is not the case, then an error can be triggered with the somewhat cryptic message:

ERROR: KeyError: key 0 not found

This is an attempt to improve that error message.
Maybe the new message is too verbose or imprecise?
Or maybe there are other conditions which trigger the error?
In any case I submit this for your consideration.

Copy link
Sponsor Member

@StefanKarpinski StefanKarpinski left a comment

Choose a reason for hiding this comment

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

Much better. I think it might be clearer to say that if the serialize calls use the same serializer object then the corresponding deserialize calls should also use the same serializer object.

@@ -748,6 +748,21 @@ function resolve_ref_immediately(s::AbstractSerializer, @nospecialize(x))
nothing
end

function gettable(s::AbstractSerializer, id::Int)
if haskey(s.table, id)
return s.table[id]
Copy link
Sponsor Member

Choose a reason for hiding this comment

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

I would worry about the performance implications of this double lookup --- in the common case the key will be found.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Can we use get(s.table, id, -1)?

Or perhaps get(s.table, id, secret_table_token)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated to use this form:

get(s.table, id) do
    errmsg = ...
    error(errmsg)
end

@GregPlowman
Copy link
Contributor Author

Wow, CI overload. I'm overwhelmed.
Some passed, some failed. I don't know how to interpret this.
Are any of the errors related to this PR?

@StefanKarpinski
Copy link
Sponsor Member

Yeah, I have to confess the new CI output is pretty confusing. What's going on with this, @staticfloat?

@staticfloat
Copy link
Sponsor Member

Yes, lots of new CI. This new CI has a separate checkmark for Julia building on each platform, and for testing on each platform. So, for instance, you can see that this PR built successfully on linux i686, linux x86_64, linux aarch64, and macOS x86_64. It did not test successfully on any of them though. Clicking details on the right of the tester_linux64 builder, shows that the error was due to CI being broken. I'm going to close and re-open the PR to re-trigger the CI and we'll see if you get more green checkmarks this time around. :)

We're still shaking out all the bugs of this CI system, and some of the problems (on systems like armv7l, which weren't tested very thoroughly before) have required merging some commits into master, so if you want all the green checkmarks, then you'll probably need to rebase this branch on top of master. That being said, for the next couple days, I would look primarily at linux32, linux64, macos64, win32 and win64, as those should be issue-free already.

@GregPlowman
Copy link
Contributor Author

Closing and reopening to restart CI

@GregPlowman GregPlowman closed this Apr 4, 2019
@GregPlowman GregPlowman reopened this Apr 4, 2019
@StefanKarpinski
Copy link
Sponsor Member

Travis failures are unrelated.

@StefanKarpinski StefanKarpinski merged commit b471640 into JuliaLang:master Apr 4, 2019
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.

None yet

4 participants