On Thu, Jun 8, 2017 at 5:45 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Dimitris,


On Jun 8, 2017, at 3:01 AM, Dimitris Chloupis <kilon.alios@gmail.com> wrote:

Can you be a bit more specific I have no clue what you talking about :D

On Thu, Jun 8, 2017 at 11:33 AM philippe.back@highoctane.be <philippe.back@gmail.com> wrote:
We need to open this up..
I want to expose the image using fuse on linux.

Fuse, MacFuse and Dokan are all instances of "file system in user space" systems that allow and program to function as a file system server, much like NFS, over a socket.

There systems define a wire format and a set of requests and responses that cover the domain of file systems (listing directory contents, creating, opening, reading, writing, closing and deleting files, etc).

The program functioning as a server can therefore externalise any data it so chooses as a file system.�� It is possible, for example, to make classes appear as directories with methods as files within them, with subclasses as sub directories, and hence the entire class hierarchy as a directory tree.�� Writing a file could be mapped into recompiling or adding a method, etc.

There are many things one could use this for, but one clear direction, from the success of docker, is to make a Smalltalk image observable and configurable by devops people without having to start up an image and navigate an unfamiliar and foreign UI & IDE.�� Such a direction is probably not well served by a na��ve mapping of classes and methods to directories and files (what about global variables, what about doits, what about Instantiation?) but the potential is there.

My basic idea is to:

1/ be able to drop binary resources in the image (including datasets)
2/ be able to edit those resources with native tools from the FS view (say, Gimp, or Vim ..)
3/ be able to edit classes and methods using vim on a server.
4/ be able to see vm and image parameters as files and be able to change them as needed (sysctl style)

We need several logical locations in the filesystem like:

/vm/
/environment/
/workspace/ws1/contents

For workspace contents, it would do a doIt on write, possibly creating a contents.out

It is a cool project :-)

Phil


HTH

Holidays coming...

Phil

Le��8 juin 2017 10:17, "Dimitris Chloupis" <kilon.alios@gmail.com> a ��crit��:
problem is when you try to use a generic ide or an ide made for another language is that you get a sub standard experience. For example pyDev is an Eclipse extension that allows one to use Eclipse which is a predominantly Java IDE for Python. I used that in the past now I use PyCharm a Python exclusive IDE that is like nigh and day with PyDev.��

Pharo IDE has a lot of issues (auto completion being the worst for me) but its after all tailor made for Pharo. IDE APIs by the way are very common , especially for open source IDEs like Eclipse, Netbeans etc. So its possible to connect pharo with a ton of IDEs out there and not particularly hard , but there is little motivation to do so.��

On Thu, Jun 8, 2017 at 8:19 AM Ben Coman <btc@openinworld.com> wrote:
I just bumped into Microsoft's MIT Licensed IDE "Visual Studio Code" that runs on OSX, Linux & Windows.�� What is interesting is their Debug Protocol for connecting to language specific debuggers.
* https://code.visualstudio.com/docs/extensionAPI/api-debugging

If I had time, it would be interesting (and super cool) to build a Debug Adaptor in Pharo��
as well as a Language Server Protocol provider
Could make a good student project or two.�� The skills learnt and demonstrated would be quite marketable outside of the Pharo community. ��

From a marketing perspective, it might be more palatable for existing Visual Studio users to install Pharo as an extension rather than install Pharo as a whole new IDE (i.e. Pharo) - a common complaint about Smalltalk in general.�� At a minimum there is the exposure gained from Microsoft's Extension Marketplace, with early adoptors trying out Pharo just-because-its-there. It also smashes that regular criticism of Smalltalk that it lives too much in its on isolated world.

It might attract developers wanting to do polygot development, for example (just guessing that might be possible):
* game development using Unity libraries for the game engine with Ronnie's minimal-vm embedded as the scripting language, ��and debugging both in parallel from a single environment��
* Pharo web server backend with Javascript frontend

I vaguely wonder if it would be possible to make a Debug Adaptor that integrates VM & Image level debugging, transparently stepping from Smalltalk into the VM C code.�� That could be useful for FFI debugging, or developing low-level graphics interfaces that might break our internal IDE.

Disclaimer: Like all my random ideas, its a bit vague and dreamy, but I had no concept of it yesterday, so just sharing the find to stimulate future ideas.

cheers -ben��