Out of image IDE
Locked
 
|
Hello All,
I've been playing with Pharo off and on for a few years now. I have thought a lot about where and how I could potentially use it. I have an idea about how I would really like it to work, but up to now I haven't had the chance to pursue it. I think I may even have had a discussion about it with someone on this list at some point. Due to some recent changes in my situation, It looks I may be at a point that I can look into things more seriously. Basically, I want an IDE that exists outside of the image. I want to be able to target multiple vm instances and provide some ipc mechanism for distributed instances. There are also some other interesting possibilities that this architecture could support. I have a couple of questions about this idea. 1. Should I do an MDI interface similar to what is in the image now or an interface with separate windows more like VW? 2. Is there anything that currently exists that involves remote image access that I could leverage as a starting point? 3. Is there anyone that finds the idea interesting at all? Thanks for your time, -S |
|
Administrator
|
Forwarding message stuck on Nabble (probably the author is not subscribed to the list)...
Cheers,
Sean |
|
|
Hi How answer him if he is out of this list? 2017-05-04 5:26 GMT+02:00 Sean P. DeNigris <[hidden email]>:
|
|
|
Denis,
IIUC, mails from the Mailing List will be replicated to Nabble, but if you post to the list from Nabble and are not subscribed to the list, your message won't make it onto the list. So your message should occur on Nabble ;-) Joachim Am 04.05.17 um 10:09 schrieb Denis Kudriashov:
-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel [hidden email] Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 |
|
|
In reply to this post by Sean P. DeNigris
On 4 May 2017 at 05:26, Sean P. DeNigris <[hidden email]> wrote: Forwarding message stuck on Nabble (probably the author is not subscribed to I am in a possibly similar situation. I have also been wanting better tools for my application development work for some years now, and this year it has finally bubbled up to the top of my priority list. My applications are not based on Pharo but I want to use Pharo for the tooling. The basic design I am following is a frontend/backend split. The frontend is Pharo with the "Moldable Tools" concept i.e. spotter, inspector, Roassal visualizations, etc. The backend is nix i.e. integrating diverse tools (profilers, debuggers, protocol analyzers, statistical models, physical hardware resources, etc.) I am building network equipment and mostly need diagnostic tools for profiling and troubleshooting issues after they have occurred. So my emphasis is not so much live coding as "what interesting observations can we make about these 1000 core dump files from various environments and software versions?" I hope that the design will be practical and that the project will grow to support other people's applications too. Just now it is very early days. Link: https://github.com/studio/studio Cheers, -Luke |
|
<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. On Thu, May 4, 2017 at 12:13 PM Luke Gorrie <[hidden email]> wrote:
|
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |