Open raphaelquast opened 5 years ago
The problem is bigger than that. We would need to serialize the function objects. C++, which (unbelievably) still lacks proper reflection makes serialization a hassle (essentially forcing projects to do their own code generation, see e.g. Qt's moc, google's protobuf etc.). xref: https://github.com/symengine/symengine/issues/1394
EDIT: On that note, I've been looking into using libclang to parse the ast of a project of mine and generate serialization/deserialization functions during the build process (I've seen some talks on the subject, some also use annotations, but I haven't found a well established and maintained tool for this)
OK, thanks for the quick reply! ...i already thought that the actual issue might lie a bit deeper...
will I run into any (expected) problems if I use the 'llvm' backend instead?
@raphaelquast, the pickle file for llvm
backend is platform dependent. You won't be able to save in linux and load in macos
As long as you pickle and unpickle on a machines with the same instruction set there shouldn't be any issues (barring any unknown bugs of course). (and OS as @isuruf points out)
Perfect, thanks! (the platform-dependency is fortunately only a minor issue for me)
I've just noticed that pickling of symengine Lambdify functions fails with the default 'lambda' backend, but works fine with the 'llvm' backend... is there any particular reason for that? (or in other words... will I run into problems when I use the 'llvm' backend?)
maybe the fixes of #213 need to be repeated?