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

Fix deprecation of int(x) in Julia 0.4 #25

Merged
merged 1 commit into from
Mar 26, 2015
Merged

Fix deprecation of int(x) in Julia 0.4 #25

merged 1 commit into from
Mar 26, 2015

Conversation

axsk
Copy link
Contributor

@axsk axsk commented Mar 25, 2015

Doing a Pkg.update() on the newest Julia nightly I receive a LOT of

WARNING: int(x) is deprecated, use Int(x) instead.
 in cdata at C:\cygwin64\home\Alex\.julia\v0.4\LibExpat\src\LibExpat.jl:166

slowing down the update process so much, that I actually canceled it after 10 minutes.

The provided ad-hoc patch solved this issue.
I did not check for other deprecated code, as I am not informed on these changes.

WARNING:
I do not know if this works with Julia 0.3.

@@ -163,7 +163,7 @@ cb_end_cdata = cfunction(end_cdata, Void, (Ptr{Void},))
function cdata (p_xph::Ptr{Void}, s::Ptr{Uint8}, len::Cint)
xph = unsafe_pointer_to_objref(p_xph)::XPHandle

txt = bytestring(s, int(len))
txt = bytestring(s, Int(len))
push!(xph.pdata.elements, txt)
Copy link
Collaborator

Choose a reason for hiding this comment

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

Needs to be @compat(Int(len))

Copy link
Collaborator

Choose a reason for hiding this comment

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

Line 63 of src/streaming.jl also needs this treatment.

@garborg
Copy link
Collaborator

garborg commented Mar 25, 2015

Thanks, @axsk -- if you make the changes I marked inline, we can get your PR merged.

@garborg
Copy link
Collaborator

garborg commented Mar 25, 2015

If you haven't seen it yet, running Pkg.test("LibExpat") after making your initial changes would catch the third change, and running it again on 0.3 would confirm whether or not adjustments were needed for 0.3 compatibility.

@garborg
Copy link
Collaborator

garborg commented Mar 25, 2015

When you make the edits, please squash them to one atomic commit (so there's not an intermediate commit that doesn't work on 0.3). Thanks!

@tkelman
Copy link
Contributor

tkelman commented Mar 25, 2015

Shouldn't Travis be running here?

@garborg
Copy link
Collaborator

garborg commented Mar 25, 2015

@tkelman It should be (as of #23). I just flipped off Travis's 'Build only if .travis.yml is present' switch, though that shouldn't make a difference. The other switches are on.

@amitmurthy Could you check that this package (GitHub) Settings -> Webhooks & Services has Travis CI present with a green checkmark in the Services section?

That's supposed to be taken care of when you turned on Travis -- not sure how easiest to fix it if not, but @tkelman may know.

@amitmurthy
Copy link
Collaborator

This is what it looks like now. I don't see a green checkmark.

image

@tkelman
Copy link
Contributor

tkelman commented Mar 25, 2015

That looks like it's disabled for some reason, does it let you turn it back on if you click edit?

@garborg
Copy link
Collaborator

garborg commented Mar 25, 2015

(Maybe it's just a little unchecked checkbox at the bottom titled 'Active'.)

@amitmurthy
Copy link
Collaborator

The green checkmark is there now. Maybe the Travis/Github setup process was taking time.

@garborg
Copy link
Collaborator

garborg commented Mar 25, 2015

And #26 (a fresh, just-to-test-travis PR) triggered a build. I'm wondering if there was a problem with the "only when .travis.yml is present" option.

@amitmurthy
Copy link
Collaborator

No, sorry I wasn't clear. Travis CI was not present as an added Service. I added it and expected to see a checkmark, which I didn't find. I guess #26 triggered a build and so we are all good now.

@garborg
Copy link
Collaborator

garborg commented Mar 25, 2015

Ah, gotcha -- thanks!

On Wed, Mar 25, 2015 at 10:05 AM, Amit Murthy notifications@github.com
wrote:

No, sorry I wasn't clear. Travis CI was not present as an added Service. I
added it and expected to see a checkmark, which I didn't find. I guess #26
#26 triggered a build and
so we are all good now.


Reply to this email directly or view it on GitHub
#25 (comment).

@coveralls
Copy link

Coverage Status

Changes Unknown when pulling 78d32e5 on axsk:patch-1 into * on amitmurthy:master*.

@garborg
Copy link
Collaborator

garborg commented Mar 26, 2015

Hmmm... tested before committing and this passed on 0.3 and 0.4 locally.

I believe the the failure on 0.4 on Travis is the same failure that keeps OpenStreetMap.jl failing (0.4, on Travis, not locally) failing downstream:
https://travis-ci.org/tedsteiner/OpenStreetMap.jl/jobs/49702311
https://travis-ci.org/tedsteiner/OpenStreetMap.jl/jobs/49701904
https://travis-ci.org/tedsteiner/OpenStreetMap.jl/jobs/47683838

Anyone seen similar elsewhere?

@amitmurthy
Copy link
Collaborator

The same issue on Travis has been present for HTTPClient.jl https://travis-ci.org/JuliaWeb/HTTPClient.jl/jobs/53431520 - I have been unable to figure it out. Happens on a ccall . One difference I noticed was that Travis uses AMD CPUs while local testing (which passed) were all Intel.

I think you can go ahead and merge if it passes locally. Current master is also failing on Travis I guess.

garborg added a commit that referenced this pull request Mar 26, 2015
Fix deprecation of int(x) in Julia 0.4
@garborg garborg merged commit 96f5450 into JuliaIO:master Mar 26, 2015
@garborg garborg deleted the patch-1 branch March 26, 2015 16:43
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

5 participants