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.delplan...@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.al...@gmail.com> a écrit > : > > > > On Mon, Jan 8, 2018 at 5:50 PM Julien <julien.delplan...@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. > > >
