On Thu, Jun 8, 2017 at 5:45 PM, Eliot Miranda <[email protected]> wrote:
> 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. > 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" <[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 >>>> >>>
