Re: [Pharo-users] [ANN] Python3Generator and MatplotLibBridge

[Dimitris Chloupis]

Ah ok so you want to target the AST specifically, I see now.
Yeap I did not implement any security measure for Atlas because the goal
was local and not remote execution. Yes indeed the socket connects directly
to 127.0.0 port 4000.So Atlas is preconfigured to work locally. I think
safety is something that the developer must control to make it specific to
the nature of the code. Plus I am no web dev. Plus if OS security is
breached to gain access to Atlas, the user is already in a deep mess, Atlas
will be the least of his concerns.

If my assumption is correct and you execute python code by writing it to a
python file and then executing the module, note that this approach is
actually much slower to the socket approach. Which is why I did not go for
it in the first place. Sockets work similar to files but use memory and
thus do not write to hard disk and so they work faster. Which is why
sockets are so popular for local IPC as well. I am not sure if Pipes as
faster but I doubt it.

Memory mapped files are much safer and much faster, which is why shared
memory is the most popular IPC for local comunication , the hacker would
have to hack the memory low level style because memory mapped files are
controlled by the OS kernel and is basically what is used for shared
libraries, the very popular DLLs on windows , dylib on MacOS, and so on
Linux. If performance becomes a serious issue for you and you want the
safest way to do local IPC , I highly recommend this approach.

But if you are happy with your current solution, there is no need to modify
your code.

On Fri, Jan 5, 2018 at 9:09 PM Julien  wrote:

>
> Le 5 janv. 2018 à 17:15, Dimitris Chloupis  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?
>
>
> In MatplotLibBridge I do some checking/optimisations on the AST generated
> by high-level API objects (e.g. for optimisation avoid importing a package
> twice).
> With an AST it is easy with basic Atlas I think this is not possible.
> Having an AST allow to do stuff on the code to execute before executing it
> and this easily
> and maintainable (i.e. not using regexes).
>
>
>> 
>>
>> 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 ?
>
>
> What I would like to experiment for fun is translating Pharo Smalltalk to
> Python 3.
>
> And as said before with your technique you can not modify the AST easily
> before sending it 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 int

Re: [Pharo-users] [ANN] Python3Generator and MatplotLibBridge

[Julien]

> 
> Le 5 janv. 2018 à 17:15, Dimitris Chloupis  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?

In MatplotLibBridge I do some checking/optimisations on the AST generated by 
high-level API objects (e.g. for optimisation avoid importing a package twice).
With an AST it is easy with basic Atlas I think this is not possible. Having an 
AST allow to do stuff on the code to execute before executing it and this easily
and maintainable (i.e. not using regexes).

> 
> 
> 
> 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 ? 

What I would like to experiment for fun is translating Pharo Smalltalk to 
Python 3.

And as said before with your technique you can not modify the AST easily before 
sending it 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. 

I agree that sockets are not costly but a problem I see with them is that it 
creates a *huge* security issue by letting anyone execute arbitrary Python code 
from the outside (except if you configured atlas to only accept connections 
from 127.0.0.1). Since I do not need socket to execute arbitrary code I prefer 
not using them.

Re: [Pharo-users] [ANN] Python3Generator and MatplotLibBridge

[Dimitris Chloupis]

>
> 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?

>
> [image: 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.

Re: [Pharo-users] Grafoscopio (Initial) Feedback

[Offray Vladimir Luna Cárdenas]

Hi Sean,

I would like to use the Metacello script you advised to me for loading
Grafoscopio. The Gopher scripts were created following documentation in
PBE2.

Does any has pointers to documentation on how to create Metacello
installing scripts?

Thanks,

Offray


On 31/12/17 11:08, Sean P. DeNigris wrote:
> Offray Vladimir Luna Cárdenas-2 wrote
>> Now they're in the SThub and also in the PDF Manual linked there.
> Ah, okay I see they are updated for 6.1, but they still use Gofer. Also,
> IIRC (I moved all my development to git a while ago now) the best practice
> is to always keep the most up-to-date ConfigurationOf in the canonical repo
> (i.e. yours) and then /copy/ it to the relevant platform metaRepoForXyz's.
> Otherwise, in my experience one invites chaos because people are downloading
> variously out-of-date configs from multiple sources (like me last night
> spending time reporting already-fixed bugs; don't worry I'm not upset!). See
> my previous post for the preferred script that should be expected to work on
> /any/ supported platform.
>
>
>
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>
>

Re: [Pharo-users] Examples of Garage for DB2

[Andrei Stebakov]

Thanks, Esteban, it works in my Pharo 6.1. Odbc connection works as well.

On Jan 5, 2018 6:28 AM, "Esteban Lorenzano"  wrote:

this:

SmalltalkImage compilerClass: Compiler.
Metacello new
smalltalkhubUser: 'PharoExtras' project: 'ODBC';
configuration: 'ODBC';
version: #bleedingEdge;
load.
SmalltalkImage compilerClass: OpalCompiler.

loads for me (after proceeding a warning) in Pharo7.
no idea if it will work, but it *loads* :)

Esteban



On 4 Jan 2018, at 18:18, Andrei Stebakov  wrote:

Thank you, Pierce

I got similar ffi exceptions when I call

Gofer new

  smalltalkhubUser: 'PharoExtras' project: 'ODBC';

  package: 'ConfigurationOfODBC'; load.

  (Smalltalk at: #ConfigurationOfODBC) load.

On Jan 4, 2018 11:41 AM, "Pierce Ng"  wrote:

> On Wed, Jan 03, 2018 at 11:42:22AM -0500, Andrei Stebakov wrote:
> > I tried before to install odbc.n
>
> > Gofer new
> >   squeaksource: 'ODBC';
>
> Not Squeaksource. Load the version from Smalltalkhub:
>
>   Gofer new
> smalltalkhubUser: 'PharoExtras' project: 'ODBC';
> ...
>
> Hopefully this version works with or without Esteban's suggestion.
>
> > I still don't see how postgres can help but I'll give it another try.
>
> I suggested PostgreSQL FDW because I know PostgreSQL. If you are not
> familiar
> with PostgreSQL, then setting it up, setting up its FDW, and finally
> setting up
> programmatic access to PostgreSQL to get at the FDW data is probably more
> work
> than it is worth.
>
> Pierce
>
>
>

Re: [Pharo-users] [ANN] Python3Generator and MatplotLibBridge

[Julien]

> 
> Le 5 janv. 2018 à 12:34, Dimitris Chloupis  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?

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


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

>  
> 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’.  

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.

>  
> 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.

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.

> 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 Ph

[Pharo-users] End of Pharo Mooc is delayed until end of January

[Stephane Ducasse]

Dear all,

Some of you asked for a deadline extension in order to complete the
course activities and get the certificate of attendance.

We agreed to give you a few more days. The deadline is now January 31th.

If you haven't done so, please take a moment to give us your feedback
on the course by filling in the end-of-course questionnaire.

All the team wishes you all the best for 2018

Luc, Stéphane & Inria Learning Lab team

[Pharo-users] Exception in Gofer with Pharo 7

[Rafael Luque]

Hi all.

I'm trying to load some packages from SmalltalkHub and I get an exception
because ByteString did not understand #asUrl.

Maybe it is related with String>>asUrl deprecated?
https://pharo.fogbugz.com/f/cases/2896/Deprecate-String-asUrl

Thank you!

Re: [Pharo-users] [ANN] Python3Generator and MatplotLibBridge

[Dimitris Chloupis]

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?


> 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 brin

Re: [Pharo-users] Examples of Garage for DB2

[Esteban Lorenzano]

this: 

SmalltalkImage compilerClass: Compiler.
Metacello new 
smalltalkhubUser: 'PharoExtras' project: 'ODBC';
configuration: 'ODBC';
version: #bleedingEdge;
load.
SmalltalkImage compilerClass: OpalCompiler.

loads for me (after proceeding a warning) in Pharo7. 
no idea if it will work, but it *loads* :)

Esteban



> On 4 Jan 2018, at 18:18, Andrei Stebakov  wrote:
> 
> Thank you, Pierce
> 
> I got similar ffi exceptions when I call
> Gofer new
> 
>   smalltalkhubUser: 'PharoExtras' project: 'ODBC';
> 
>   package: 'ConfigurationOfODBC'; load.
> 
>   (Smalltalk at: #ConfigurationOfODBC) load.
> 
> 
> On Jan 4, 2018 11:41 AM, "Pierce Ng"  > wrote:
> On Wed, Jan 03, 2018 at 11:42:22AM -0500, Andrei Stebakov wrote:
> > I tried before to install odbc.n
> > Gofer new
> >   squeaksource: 'ODBC';
> 
> Not Squeaksource. Load the version from Smalltalkhub:
> 
>   Gofer new
> smalltalkhubUser: 'PharoExtras' project: 'ODBC';
> ...
> 
> Hopefully this version works with or without Esteban's suggestion.
> 
> > I still don't see how postgres can help but I'll give it another try.
> 
> I suggested PostgreSQL FDW because I know PostgreSQL. If you are not familiar
> with PostgreSQL, then setting it up, setting up its FDW, and finally setting 
> up
> programmatic access to PostgreSQL to get at the FDW data is probably more work
> than it is worth.
> 
> Pierce
> 
> 

Re: [Pharo-users] Where is "recover lost changes"?

[Ben Coman]

Similar question asked here...
http://forum.world.st/Epicea-feedback-save-points-td5060619.html

I have since got close to what I needed by first doing...
Filter > Show only latest changes
then doing...
Filter > Hide changes if apply operation is redundant

cheers -ben

On 5 January 2018 at 17:13, Andreas Brodbeck  wrote:

> Hi all
>
> In the newest Pharo 6.1 I miss a feature from the older Pharos "recover
> lost changes", which showed me all code changes after the image crashed.
>
> I am aware of the new Epicea, which is great, but I can't really get it
> to show me only those changes since the last image save. How can I get
> those changes?
>
> Cheers,
> Andreas
>
> --
> Andreas Brodbeck
> www.mindclue.ch
>
>
>

[Pharo-users] Where is "recover lost changes"?

[Andreas Brodbeck]

Hi all

In the newest Pharo 6.1 I miss a feature from the older Pharos "recover
lost changes", which showed me all code changes after the image crashed.

I am aware of the new Epicea, which is great, but I can't really get it
to show me only those changes since the last image save. How can I get
those changes?

Cheers,
Andreas

-- 
Andreas Brodbeck
www.mindclue.ch

Re: [Pharo-users] [ANN] Python3Generator and MatplotLibBridge

[Julien]

> Le 4 janv. 2018 à 23:48, Kjell Godo  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


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.

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.

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.

> 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

Yes I know Roassal and I think this is a great project when you want to do 
interactive visualisations and keep them inside the image.

But, as far as I know, when it comes to export the plot into a pdf file to have 
a nice integration in a LaTeX document, you can not do that in Roassal. Of 
course you can export your plot as svg but then you have to deal with 
integrating svg inside LaTeX… Furthermore, as I said before, I already used 
MatplotLib in Python and really liked its simple interface… Finally, at the 
beginning it was just an experiment for fun, but then I saw it was quite easy 
to interface to a Python library from which you don’t need to get values back 
in Pharo so I continued this project and used it when I had to plot stuff. Now 
I think it is quite usable and I enhance it a little every time I use it and 
see there is a part of the bridge I need that is not built yet. :-)

> 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

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

---
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