Johan Brichau could execute java code from VisualWorks. He had special metaclass whose dictionaries contains strange mirror to java methods. So I'm interested to see how far you can get :) On Wed, Jan 10, 2018 at 4:58 PM, Julien <julien.delplanque@inria.fr> wrote:
Even if I learned things from your answer, I think you misunderstood what I was talking about. :p
What I want is a mechanism to describe pythonâs objects from Pharo and being able to: 1. Serialise those objects from Python 2. Send those object to Pharo (whatever the way it is done: socket, write in a file from python and read from Pharo, etcâ¦) 3. Materialize those serialised Pythonâs objects as Pharo objects.
Basically, I want to be able to transfer data from Python to Pharo easily.
Something better than getting the values held by Python objects by parsing their String representation « by hand »... :-)
Julien
--- Julien Delplanque Doctorant à lâUniversité de Lille 1 http://juliendelplanque.be/phd.html Equipe Rmod, Inria Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq Numéro de téléphone: +333 59 35 86 40
Le 10 janv. 2018 à 16:43, Dimitris Chloupis <kilon.alios@gmail.com> a écrit :
On Mon, Jan 8, 2018 at 5:50 PM Julien <julien.delplanque@inria.fr> wrote:
Beware that no mechanism to get back values from Python is defined for now (except if you just want the String representation of those objects, then you can get that if you use atlas).
Iâd like to have that but it is not easy. I would like a way to describe how to map Pythonâs objects to Pharoâs objects from Pharo and to have the code to do that in Python side generated automatically but some thinking is neededâ¦
Julien
It won't be easy
I have noted in the past the similarities between Pharo and Python but here there is also a massive difference.
In Pharo we have the mentality of reinventing many stuffs ourselves so the systems is based to a very large extend on Pharo that runs on very efficient JIT VM. Almost everything is Pharo code.
Python on the other hand is the exact opposite, Python runs on an extremely slow VM but more than 50% of its code in written in C, Python itself or its third party libraries.
So the irony is that even though in theory and practice Python code is one of the slowest , in actual scenarios its one of the fastest able to outperform even Java to a very large extend because its libraries that are made for high performance like Numpy are predominately C code. Pretty much every C or C++ library has wrappers for Python which is what made it so popular. Hence the reason behind the insanity when it comes to top performance Python being second only to C++.
So you will have not only map the Python oobjects to Pharo object but also map the C code. Even though this may sound impossible the good news is that Python libraries, having the extension pyd , are basically DLLs made supporting a specific API which is very minimal in design. Similar to our UFFI , the only major difference is that library is responsible of keeping track of the reference count, which is used by Python GC to erase no longer used objects from memory. Which is a very simple increase and decrease.
So not only you will have to remap the Python objects but also DLLs as well.
To add salt to the wound , Python has something that Pharo does not. Multiple inheritance. Which of course makes your goal even harder. Python coder's generally avoid multiple inheritance as much as we avoid overriding doesNotUnderstand , but its a feature they use none the less.
Hence why I did not even consider trying something like that. Plus you will be gaining no advantage because C code is unportable to Pharo anyway. Sure we have Slang , but Slang is extra careful with types which normal Pharo code does not. You will be losing performance because yes porting to Pharo as much as JIT VM may be great , its no much for Python libraries that merely leverage C. Plus you will have to update it each time the library changes etc.
So my conclusion was that the most efficient way was to let Python execute the library and just manipulate Python.
It's much easier to do the exact opposite, which goes against our mentality , and port your Pharo objects to Python objects. Because a) your objects will always be far less than a complete library and system b) you wont have to worry about C code because you wont have any c) all the other negatives I mention , disappear.
It usual case of not being able to have your cake and eat it too.