<Begin stupid proud moment>
Been there done that��
<End stupid proud moment>
I have two Pharo libraries available through the Package Browser.��
The first is Atlas, it allows Pharo to use python code. This happening by Atlas sending python commands as string via a socket (super unsecure I know but I use it only locally) , the communication is two way, Pharo sends commands , python sends data if pharo ask them. I manage to create a pharo python syntax, very basic parsing and super simple syntax (full support of python syntax is not necessary because I intended only to use python libraries not develop python code). The lib is made to work locally but its architecture is open enough that should be easy to use also remotely.��
Pros:
1) Ability to use pharo syntax that is converted to python syntax. The trick here through a nasty hack on MessageNotUnderstood Atlas is able to call python libraries directly with pharo syntax with zero need for wrapping
2) Socket mechanism is already installed in all OS , so there is nothing to install if you have pharo and python 3
3) There is support for live coding this happens because Atlas sends Python errors back to Pharo and triggers the Pharo debugger. It then stops execution at Python side, it does not allow the application to end because it uses a python exception to capture python errors , but it waits till the next command from Pharo
4) There is a basic parser for python objects to pharo objects that can be used as an example
5) It works with most Python libraries apart from ones depending on thread and async
6) Library is open enough that can be used for remote or locally connecting to anything and anywhere
Cons:
1) The pharo to python syntax is super limited to method and functions call and variable assignments. But there is nothing stop it from been improved
2) Sockets are Slowwwwwwwwwww . They offer awesome cross platform compatibility but it comes with performance cost. Local communication usually goes under on millisecond but still slow I would say anywhere between 10-100 times. So no long loops. This can be avoided by making the loop entirely in python and this way make much less connections. Atlas support sending python code as a string
3) Live coding works but I have not heavily tested so it will be probably limited because unlike Pharo , Python is not an out of the box live coding language
4) Types parser is super basic and offers close to zero support its there only as an example. I did not bother with it because the types I receive from python are just numbers, floats and strings.
5) It had issues once with a library that used threads.
6) It does not come with a communication protocol , it sends only python commands as strings thus its��unsecured��but��nowadays��encryption is super easy so it should not be a problem adding it as a features.��
The second one is CPPBridge this one uses Shared Memory Mapped Files to use an API inside a C++ executable. Its like��embedding��Pharo but without��embedding��it. Shared memory is a functionality of the OS, its pretty standard and supported by all major OS, it allows two or more processes to have an area of memory that can access. There are access rights that can be setup but in my case its send so both sides can read and write.
Pros:��
1) The most important , its nuclear fast. This happens because shared memory uses the lowest level of memory management from OS
2) Because everything is saved into a file and because you are not required to call a save actions , the OS does this for you, it becomes impossible to lose data. Even in the case of crash and believe I had to crash Pharo a ton of times to make this work, the data is never lost.��
3) Its super reliable , memory mapped files is how DLLs and other dynamic libraries work , so its a feature that is heavily used by the OS
4) Because its really low level , it allows you to compact memory down to the last bit , giving you full control over memory management, You can replicate the data to Pharo side if you want but its not necessary
5) Its allow you to use Pharo as if it was embeded inside a C++ executable
6) Because it gives you access to memory and because a C++ executable is statically compiled its super safe and it would require very low level hacking. Also being strictly local helps
Cons:
1) This is the most important for you, it does not work remotely, this is 100% local but of course it could be combined with sockets
2) Its quite technical because it demands a basic understanding of the OS way of handling memory
3) continuing from the previous points, its manual memory management which means you have to be extra careful what you do because its easy to crass. I tried with the API to make it less easy but still , its not safe.
4) It wont automagically copy data from the shared memory to Pharo but the good news is that unlike a socket you do not need to wait for the other end to open to access your data since it is stored in a file
5) You will have to handle yourself��synchronizations��issue, generally speaking corruption cannot happen because it handled by the OS BUT it could mess up the order of your data if both sides are not in agreement whos is��writing��and when.
So that is how I control Pharo mainly locally but as I said the first would be very easily converted to remote connection. Also besides me a couple of other people used it without any major issues other than the usual bug.��
��
����