[ANN] Python3Generator and MatplotLibBridge

Le 4 janv. 2018 à 23:48, Kjell Godo <[hidden email]> a écrit :

did you use a socket to communicate from Pharo to Python?

     it does not sound like it     it sounds more one way

     i am interested in using sockets to communicate between programs

          but i haven't done much with it yet

     maybe you can include sockets in your generated Python to talk

          back to Pharo ?

     i got Dolphin Smalltalk to talk to Pharo using a socket

          but i kind of forgot about it

did you look at Roassal ? Roassal does a lot of plotting they look very nice

     they have mouse interactions and lots of cool stuff

          but i don't know how they relate to other plotting programs

     i imagine that Roassal tries to do things not done in other programs

          but i don't really know     i looked at some other plotting thing also

          can't remember Sci something

     Roassal has a nice declarative style that is nice

          i want to use it a lot in future

      i use Roassal in the Moose Pharo image because it is pre installed

i have a rich text tree editing program in Dolphin Smalltalk

     that i use like a note taking program like everNote but as a great big tree

          using the old Windows tree widget in Dolphin 6 which i like

          and i store a lot of my text stuff in there

     and i would like to store and edit Racket programs or lisp programs

          in there in a tree format

     and your project sounds interesting

          about how to maybe generate Racket code that will allow

          me to use Dolphin and Pharo and other Smalltalks as a front end to 

          Racket or commonLisp etc

          because i don't like the GUIs or IDEs of those things

               ( they're so primative )( but i don't know them well )( they just look

                    brittle )( and C like )

     and i believe there is a command line interface in Pharo so you can

          execute external programs like generated scripts

Le 5 janv. 2018 à 12:34, Dimitris Chloupis <[hidden email]> a écrit :

Well done, great to see my code be reused for new project. I am happy to see people take it one step further. 

What exactly your code offers additional to my code ? Is there is something special you do with it?

ast := 'print' asP3GIdentifier callWith: #('Hello world').

ast inspect

 

There is a concept of « Interpreter » in this framework. Basically, an interpreter is an object to which you provide strings containing Python 3 code and that execute it.

There is a FFI interpreter which writes the python code in a file on the file system and uses the int system(char *) function to make python execute the file. It also redirect stderr to a file and read that file after execution in order to have eventual execution errors.

You don't really need this approach. The reason why I did not add this feature in Atlas is because the way that Python import its files is basically normal execution. 

So each time you 

import mymodule

what you do is you execute mymodule. Basically Python does the same thing with execution when it does a import. This is why we need the if main thing to detect whether the module execution happened because of import or because it was executed directly (via terminal, or double click).

So in case of Atlas all you have to do is put your code in a python module and import then module from atlas with sendMessage: 'import mymodule’.  

 

There is a Atlas interpreter which uses the Atlas project from Kilon. Atlas makes Python and Pharo talk trough sockets. So this is what you want I guess. The thing is, if I want to send data from Python Pharo, I would use the Atlas interpreter and serialise data to send to Pharo through a socket as JSON for example. But for Matplotlib I do not need to read Python’s value so I did not implemented that. Nevertheless, it could be cool to have this ability to get Python’s data in Pharo because we could use Numpy or others Python modules for which getting Python's is important.

Atlas provide this ability via getValue: message. There is a catch , what you get is always strings. So that means if you use a complex Python object you will have to convert that to some form of string format that clearly represents the data . JSON could be a good candidate here because both Python and Pharo support this. I have created a very basic template Pharo object that parses strings to Pharo objects as an example that I have included but still its going to be tricky especially with Numpy because it all happens at C level and not Python level for performance reasons. Still its not that hard to do if you really need this feature which in your case you don't.

Another interesting thing when communicating through sockets between two different languages is: How do you manage callbacks? For example I would like to be able to make Python execute a Pharo Block at a certain point of the execution or to make Pharo execute a Python’s lambda. I do not have answer for that.

You can do that in Pharo side or Python side , its up to you. Only you need is a string that acts as a single. For example getValue: technically is kinda like a callback because it sends the string containing the python command but it waits for response from Python that will signal it if the return string contains the signature, if I remember correctly, getvalue: value. So essentially what I have done is create a mini transfer protocol.  

It was necessary for me to do this not because of callback  per se, but because I wanted to retain the live coding abilities of Pharo while coding using Python libraries. In order to do that I wanted to send Python errors back to Pharo and trigger the Pharo debugger with the python error as the name of the error. To do that I had to implement a protocol that diffirentiate between return values and value that concern only Atlas in this case python errors. 

This protocol can be extended of course to contain a myriad of things, callbacks, thread synchronization, C function calls , C memory etc. 

So technically speaking its already possible through Atlas. If you want to do something very special with callback that involves the Pharo IDE as I did with Python error you only need to extend this protocol adding your own kind of signal strings.

I think you could re-use the ideas behind the bridge but not the code. It is really specific to Python 3, I do not see how you could generate LISP using it as is.

Julien

As far as my Atlas  is concerned I had made also a Python 2 version but never bothered to continue developing it because I needed only Python 3. The good news is Python 2 and 3 have minor differences when it comes to sockets.

Indeed Atlas wont work magically with other language but porting it is not hard because I tried to keep the majority of the code as much as I could in Pharo side for this precise reason. So my initial intention was to provide Atlas to Pharo community as a means to use libraries of any programming language from inside Pharo. I hoped that people would use it as the foundation to bring other languages inside Pharo like I did for Python but alas it seems Pharoers for some weird reason prefer to use Pharo :D (joke for those that did not notice the laughing smiley face)

I was also planning adding the ability of memory mapped files that I used in my CPPBridge prohect. This form of communication accelerate things by thousands of times because its low level. But it sacrifices remote execution which means in this case you fall back to the existing socket bridge approach. This was necessary at the time because sockets are not a good idea if you plan on doing large loops, because obviously there is a delays , its low around 1 millisecond and less depending on the power of CPU but if you do 1 million iterations would turn that 1 millisecond to 1000 seconds which of course is no fun. 

On the other hand even without memory mapped files you can avoid this by making sure you keep the loop either on python side or pharo side with the condition it does not contain Atlas communication commands that open and close the socket.  

Le 5 janv. 2018 à 17:15, Dimitris Chloupis <[hidden email]> a écrit :

 

Python3Generator allows to generate a Python 3 AST programatically. So basically you have objects that represent Python 3 AST nodes and some messages in top of that to make the generation of the AST easier from Pharo.

E.g.

ast := 'print' asP3GIdentifier callWith: #('Hello world').

ast inspect

yes buy why ? Why you want to generate objects , Python AST nodes are already python objects and you already generate AST nodes each time you execute python code. 

Using the Atlas syntax your above example would be simpler

py = ATLPyParser new

py print:'("Hello World")'

Is there an advantage using your own syntax ? Is there any advantage of direct access to Python AST?

<Capture d’écran 2018-01-05 à 13.06.41.png>

If you have a look at the readme on GitHub you will see more complexe examples.

Yes I did take a look but I still did not know why you bother generating identifiers for each python command manually when ATLPyParser does this automatically for you.

For example you have this example

"Use and initialize the FFI interpreter."
P3GInterpreter useFFIInterpreter.
P3GInterpreter current pathToPython: '/usr/bin/python3'.

instr := P3GInstructionsList new.

json := 'json' asP3GIdentifier.
file := 'file' asP3GIdentifier.
os := 'os' asP3GIdentifier.

instr addAll: {
    json import.
    os import.
    file <- ('open' asP3GIdentifier callWith: #('/tmp/osp3g.json' 'w')).
    (file=>#write) callWith: { (json=>#dumps) callWith: {{
                                                'os' -> (os=>#name).
                                                'uname' -> (os=>#uname) call } asDictionary} }.
    ((file=>#close) call)
}.

instr execute.

Using the ATLPyParser of Atlas would have been much simpler

py = ATLPyParser

Atlas sendMessage:'import json,os'

py 

file:'= open("/tmp/osp3.json","w")';e;

file write:'(json.dump({"os":os.name,"uname":os.uname}))';e;

file close;e.

Or the point is to fully parse pharo syntax to python ? 

 

I wanted that to avoid the user having to set up a Python server listening on a socket when it is not needed to get data from Python.

Yep, but if I want to get value from Python into Pharo, I want to have them as Pharo objects so as you said some conversion has to be made which means more work.

Actually the server is setup at Pharo side, Python side is merely a client. All the heavy lifting is taking place via Pharo. The user does not need to do anything , its automatic.  But yeah if you want to completely liberate yourself from sockets I can understand that, though I do not understand why, you use sockets every time you access the internet and they are really fast. So its not as if you can avoid socket generation.