"cannot pickle 'module' object" from PyCall #50
Comments
|
This resource (first result upon googling the error) might be relevant: |
|
In this case I guess you didn't intend to serialize the python module So, keep in mind that |
|
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 Should 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 ^_^ |
|
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 On the host/client side, now do And from there, I could sucessfully run stuff like |
|
The contents of this comment are more accuratly covered in #54 Original postFor something completely unrelated to this issue: When I run `@time pyconvert(Float32, DAQC2.getADC(0, 0))` directly over SSH, I get around 1 ms. When I run `@time pyconvert(Float32, @Remote(DAQC2.getADC(0, 0)))` from the client/host, I get around 50 ms. Is it the serialization and deserialization that takes so long? I also tried `@time @Remote(pyconvert(Float32, DAQC2.getADC(0, 0)))` to perform the conversion before the serialization process, but the timings remained the same.With a 50 ms overhead to each call, real-time applications are limited to an update rate of 20 Hz, which is perhaps worthy of mention somewhere in the readme. At least that it is known that this is a potential bottleneck. Perhaps BSON.jl would show different performance, but hard to tell without testing. |
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 |
|
I actually do not remember the code I ran. Something like I believe the Pi 400 is 64-bit, which is supported by the fact that I was able to make it work eventually, right? |
|
You need parentheses for that to work: In any case, I think there's not much we can do about this issue (aside from additional docs, perhaps) |
|
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. |
|
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:
Any idea what the root issue is, and if there are potential workarounds?
The text was updated successfully, but these errors were encountered: