Hi Dimitris,
> On Jun 8, 2017, at 3:01 AM, Dimitris Chloupis <[email protected]> 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 [email protected] >> <[email protected]> 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. HTH >> Holidays coming... >> >> Phil >> >> Le 8 juin 2017 10:17, "Dimitris Chloupis" <[email protected]> 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 <[email protected]> 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 >>>> * https://code.visualstudio.com/docs/extensionAPI/language-support >>>> as well as a Language Server Protocol provider >>>> * https://code.visualstudio.com/docs/extensionAPI/language-support >>>> 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
