KronosTheLate
commented
1 year ago This resource (first result upon googling the error) might be relevant: https://stackoverflow.com/questions/2790828/python-cant-pickle-module-objects-error
Closed KronosTheLate closed 1 year ago
KronosTheLate
commented
1 year ago This resource (first result upon googling the error) might be relevant: https://stackoverflow.com/questions/2790828/python-cant-pickle-module-objects-error
c42f
commented
1 year ago @remote fetches the result of evaluation from the server back to the client. For this to work, you need
typeof(result) to be defined on both the client and server side. Usually this means loading the relevant module defining that type on both the client and server (in this case, PyCall needs to be loaded on the client as well as the server)result must be serializable and deserializable with the Serialization module. From the server logs it seems this isn't the case because there's a pickle failure.In this case I guess you didn't intend to serialize the python module piplates.DAQC2plate, rather you just want to load it on the server side. In that case you can try suppressing the output by just returning nothing instead of returning the module to the client:
julia> @remote (pyimport("piplates.DAQC2plate"); nothing)So, keep in mind that @remote is for fetching data back to the client as julia data structures. If you just want to see the results of showing the data on the server, you can use the REPL for that.
KronosTheLate
commented
1 year ago That all makes a lot of sense. So I can import the modules, just making sure to return nothing. And then should a) load Py(thon)Call on the client side, or convert to julia types remotely. So something like
function DAQC2get_adc(bit, addr)
measurement = DAQC2.get_adc(bit, addr)
return pyconvert(Float64, measurement)
endShould probably do the trick. Fingers crossed - I will test when I have time.
A section could perhaps be added to the docs, something like "Transferring non-standard types", explaining that the package defining the type should be defined on both sides, and also perhaps a specific example with python interop. I can look into it if I get things working as I want them to ^_^
KronosTheLate
commented
1 year ago So with PythonCall loaded on both sides, I am able to transfer python variables. I was however still unable to load the package and return nothing. It causes an error about returning Int64 instead of Int32 (or opposite). When I tried to return 4 I got an error about returning a symbol. However, if I load the python library directly over SSH, in the remote Julia session, I am able to call on it using RemoteREPL. So the fix for me seems to be
Run the following on the Pi:
using RemoteREPL
using PythonCall
DAQC2 = pyimport("piplates.DAQC2plate")
serve_repl()On the host/client side, now do
using RemoteREPL
using PythonCall
connect_remote()And from there, I could sucessfully run stuff like pyconvert(Vector, @remote(DAQC2.daqc2sPresent)) to get a julia vector of the present plates. To with that, it seems to be working. It is absolutely not straightforward though, so I feel like a guide would be needed if we want new users to be able to get going without this dance of creating issues and testing fixes over several days.
KronosTheLate
commented
1 year ago The contents of this comment are more accuratly covered in https://github.com/c42f/RemoteREPL.jl/issues/54
c42f
commented
1 year ago I was however still unable to load the package and return nothing. It causes an error about returning Int64 instead of Int32 (or opposite).
What was the code you ran which caused this error?
Are you using 32-bit Julia on the pi while using 64-bit on the client computer? That would cause issues as Serialization only works between the same Julia versions on the same architecture (binary layout of data structures needs to be the same on both sides).
KronosTheLate
commented
1 year ago I actually do not remember the code I ran. Something like @remote DAQC2 = pyimport("piplates.DAQC2plate"); nothing. But after this errored, any call to @remote, including just a numeric literal, returned the same error. So something broke in the session. I just restarted, defined DAQC2 directly in the Pi session, and went on my merry way.
I believe the Pi 400 is 64-bit, which is supported by the fact that I was able to make it work eventually, right?
c42f
commented
1 year ago You need parentheses for that to work:
@remote (DAQC2 = pyimport("piplates.DAQC2plate"); nothing)In any case, I think there's not much we can do about this issue (aside from additional docs, perhaps)
KronosTheLate
commented
1 year ago Right, of course. Yhea, a docs section about python interop would not hurt ^_^
Btw, awesome work on JuliaSyntax.jl. I almost feel bad for diverting your attention with this stuff.
c42f
commented
1 year ago Thanks, it's all good! I haven't used this package for a while which is why I've been a bit inattentive to it sorry :)
I realize that it is entirely possible that this is a problem only with PyCall, but I will raise it here, since it only occurs when I use both packages, and there is not error when only using PyCall.
I can use PyImport when I run julia directly from an SSH session:
However, when I do this through RemoteREPL, the follwing happens:
Error on remote (Pi) side:
``` ┌ Error: RemoteREPL responder crashed │ exception = │ PyError ($(Expr(:escape, :(ccall(#= /home/pi/.julia/packages/PyCall/twYvK/src/pyfncall.jl:43 =# @pysym(:PyObject_Call), PyPtr, (PyPtr, PyPtr, PyPtr), o, pyargsptr, kw)))))Any idea what the root issue is, and if there are potential workarounds?