Fix 0.4-dev dlopen breakage

[yuyichao]

The first commit is some white space fixes.

The roundtrip test is failing for unknown reason. Haven't looked further yet.

Fix #143.

[yuyichao]

OK, the failing test seems to be there for python 3 before this PR so I guess it is unrelated.

Is this a known issue? The problem seems to be that the return value is an array of 0-dim arrays. Is this expected?

[yuyichao]

• - ... is the nightly version not updated yet?....

[stevengj]

Yes, the python 3 round-trip issue is known, and is unrelated. It should hopefully be fixed by the upcoming array overhaul using the buffer protocol.

[yuyichao]

Also note that since the nightly build seems to be on a earlier version, the CI is actually not testing the change made by this PR... The version test I've added is just the version I was using and is not really the version this change is introduced. It should be closed enough to the actually commit for practical purpose though... (And IMHO, it is not necessary to make a package works on every commit of julia....)

[stevengj]

The main reason that pyinitialize takes a pointer argument is in order to support the pyjulia package: when Julia is being called from Python, and PyCall is initialized, we pass in C_NULL (from Python) in order to use the running Python library (although there are still some problems getting this working from Windows).

So, I'd like to continue to support pyinitialize(C_NULL).

Maybe there can be a method pyinitialize(p::Ptr{Void}) in v"0.4.0-dev+4922" or later that calls pyinitialize(HandleT(p)) (or however you create a HandleT from p)?

[yuyichao]

OK, I'll try that. I think it is still necessary to keep the handle around in order to not let the finalizer run.

Also, could you have a look at the change in the pyfinalize and check if there were a issue before when the C_NULL was passed in? (IMHO it would try to free the jl_dl_handle/jl_exe_handle) Or is that never supposed to happen?

[stevengj]

The finalize change looks okay.

The pyjulia module never calls pyfinalize. (I'm thinking of just removing that function; it's not really something that people ever need to call, as far as I can tell.)

[yuyichao]

Done. Not exactly in the way you suggested but I think it will work.
It passes my local test on 0.4.0-dev+4934.

P.S. This is when I love Union().... =)

[coveralls]

Coverage decreased (-3.08%) to 51.24% when pulling 7a4a996 on yuyichao:0.4-dev into 32b10a5 on stevengj:master.

[coveralls]

Coverage decreased (-0.04%) to 54.28% when pulling 7a4a996 on yuyichao:0.4-dev into 32b10a5 on stevengj:master.

[coveralls]

Coverage decreased (-0.04%) to 54.28% when pulling a497bf9 on yuyichao:0.4-dev into 32b10a5 on stevengj:master.

[yuyichao]

Hmmm. I got a SegFault when running using PyPlot = = ..................

[yuyichao]

Only happens in REPL and here the backtrace.

[yuyichao]

Smaller repro

julia> using PyCall

julia>     global const pltm = pyimport("matplotlib.pyplot") # raw Python module
PyObject <module 'matplotlib.pyplot' from '/usr/lib/python3.4/site-packages/matplotlib/pyplot.py'>

julia>     global const plt = pywrap(pltm)

signal (11): 段错误
unknown function (ip: 384505338)
unknown function (ip: 384505443)
unknown function (ip: 383989187)
jl_get_global at /usr/bin/../lib/julia/libjulia.so (unknown line)
unknown function (ip: 384348467)
unknown function (ip: 384348278)
unknown function (ip: 384348891)
unknown function (ip: 384349659)
unknown function (ip: 384349835)
jl_toplevel_eval_in at /usr/bin/../lib/julia/libjulia.so (unknown line)
pywrap at /usr/share/julia/site/v0.4/PyCall/src/PyCall.jl:327
pywrap at /usr/share/julia/site/v0.4/PyCall/src/PyCall.jl:312
jl_apply_generic at /usr/bin/../lib/julia/libjulia.so (unknown line)
unknown function (ip: 384272739)
unknown function (ip: 384269560)
unknown function (ip: 384269003)
unknown function (ip: 384274417)
unknown function (ip: 384275513)
unknown function (ip: 384350743)
jl_toplevel_eval_in at /usr/bin/../lib/julia/libjulia.so (unknown line)
eval_user_input at ./REPL.jl:62
unknown function (ip: 404968679)
jl_apply_generic at /usr/bin/../lib/julia/libjulia.so (unknown line)
anonymous at ./task.jl:84
unknown function (ip: 384297344)
unknown function (ip: 0)
[1]    7993 segmentation fault (core dumped)  julia -f

[yuyichao]

Reproduce without REPL

using PyCall
const pltm = pyimport("numpy")
print(pltm)
const plt = pywrap(pltm)
print(plt)

[yuyichao]

I guess I'll report to julia since it is unlikely that PyCall.jl is causing it....

[yuyichao]

@stevengj
The SegFault I saw was not related to the breakage and is probably another julia bug.
Are you going to merge this soon or do you want to wait for more update/changes on DLHandle?

[stevengj]

Thanks!

[yuyichao]

I've also just managed to strip PyCall completely out of the script to reproduce the SegFault. So it indeed has nothing to do with PyCall