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.
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
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.
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.
We need to open this up..
I want to expose the image using fuse on linux.
Le 8 juin 2017 10:17, "Dimitris Chloupis" <[hidden email]> a écrit :
Can you be a bit more specific I have no clue what you talking about :D
In reply to this post by Ben Coman
On 8 June 2017 at 07:18, Ben Coman <[hidden email]> wrote:
JFYI: I have a very new project called Studio that will use Pharo as the front-end for "add on" development tools.
The notion is to have a UI based on Pharo/Glamor that presents a unified interface to a back-end built on many and various diagnostic tools (e.g. perf, wireshark, etc, depending on what is relevant to a given application.)
The assumption is that people already have an editor, etc, but what they don't have is an easy way to create application-specific development and diagnostic tools. That's my situation, anyway, and I am initially the main target user here.
Currently I am working towards teaching the Inspector to explore internal data structures in a tracing JIT. This will provide end-users with visibility into the way the JIT generates code (currently completely inscrutable) and make for easy cross-referencing with profilers and benchmarks. I am taking a semi-generic approach where the JIT will log raw C structs and then the Studio IDE will use DWARF debug information to import them for meaningful inspection ("gdb-style").
On Thu, Jun 8, 2017 at 6:15 PM, Luke Gorrie <[hidden email]> wrote:
Having a Pharo front end to wireshark coupled to Roassal for graphing would be super-super cool.
Always the best kind of target user.
I presume this is for LuaJIT that Snabbu uses?
That will be impressive. It would be nice if the DWARF stuff can be separated. I'm sure that could be useful sometime elsewhere.
In reply to this post by Luke Gorrie
On Jun 8, 2017, at 3:15 AM, Luke Gorrie <[hidden email]> wrote:
There is nothing inscrutable about the Cog JIT in the standard Pharo and Squeak VMs.
Once the VMMaker.oscog package is loaded (and there's a script to build such an image in the image subdirrectory of the opensmalltalk/vm repository) one can either simulate execution of an entire image or use "in image compilation" to compile any single method in the host image to machine code. The JIT is written entirely in Smalltalk. Decompilation is derived from a processor/specific plugin but then decorated by Smalltalk code to produce the most easily read jutted code I've ever worked with.
I don't see how this counts as at all inscrutable.
Sophie Kaleba is a GSoC intern working with Clément Bera, and is extending the Cog VMProfiler with more information about the jutted code. Perhaps there's synergy here?
In reply to this post by kilon.alios
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.
Thanks Eliot for the detailed explanation it makes a lot more sense now. I agree its very interesting.
On Thu, Jun 8, 2017 at 6:46 PM Eliot Miranda <[hidden email]> wrote:
On Thu, Jun 8, 2017 at 5:45 PM, Eliot Miranda <[hidden email]> wrote:
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:
For workspace contents, it would do a doIt on write, possibly creating a contents.out
It is a cool project :-)
On 8 June 2017 at 17:30, Eliot Miranda <[hidden email]> wrote:
I am working with LuaJIT. I have half a dozen significant technical problems to solve before I am anywhere close to helping mere mortals to understand the tracing JIT and use it effectively.
My interest in Pharo is to build development tools for my application, which is network equipment for ISPs written in LuaJIT with a little assembler.
In reply to this post by Ben Coman
On 8 June 2017 at 15:07, Ben Coman <[hidden email]> wrote:
Short answer is yes.
Long answer is that it is for RaptorJIT, which is the fork of LuaJIT where I am moving from diagnostics by introspection (Lua code running inside the VM) to by inspection (external Pharo/Nix tools that deeply understand the VM.)
Ongoing hacking here: https://github.com/raptorjit/raptorjit/pull/63
Once it works the question will be whether to migrate Snabb to RaptorJIT or port the functionality back to LuaJIT.
I am finding it an interesting experience to write an application that is half Pharo (frontend) and half Nix (backend).
For each piece of functionality the question is, how much should be done in the frontend vs the backend? For visualizing the JIT I could on the one hand do everything in the frontend with Pharo code to parse DWARF files, etc, or on the other hand I could do everything in the backend with Pharo simply displaying PNG files produced by Nix.
Current trade-off is that Nix will produce a JSON summary of the DWARF type information and then Pharo will use that to decode the logged binary data structures via the GT Inspector.
and when I say "Nix" I really mean the whole Nix ecosystem that includes basically every program and programming language. So I am able to freely mix shell, awk, perl, python, R, etc, and still keep things under control. That's the hypothesis anyway.
Here is a PR showing the current Frankenstein DWARF backend if you're curious: https://github.com/studio/studio/pull/14
On Thursday 08 June 2017 09:15 PM, Eliot Miranda wrote:
> 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
FUSE is really useful for passive stores like zip, iso or tgz but not
for suspended live object graph like an image. The toughest part here is
not the mounting and name resolution but the semantic mapping between
nodes and live objects.
I have a different suggestion that I feel is more 'Smalltalkish'. It
would be easier for us to build an object server thread into the VM to
serve live objects in the image as a file hierarchy. It allows a finer
control of object graph to filetree mapping. This encapsulates object
implementation details in a single place (object manager) and respects
There is already a precedence in sysfs of Linux. It shows a live tree of
device and drivers object graph - subsystems, buses, devices, their
drivers and events. The code is under 1500 lines  because it
leverages ramfs for name resolution and just has the semantic functions
for just four concepts - directory, file, group and mount. It uses
special filenames like 'uevents' to pass events between userspace and
kernel (equivalent to user processes and vm plugins in our case).
The VM needs to have:
a) a network responder (to listen and translate requests to paths
(ordered collection of nodes),
b) a name resolver to resolve paths to a name and name to a special
c) a semantic getter/setter to interpret these special objects.
So you could have:
/classes -> /globals/classes/
/classes/Morph/instances/oop1/value, sizeInMemory etc.
/objects -> /classes/Object/instances/
Instances don't comes with names one but they do have a unique id (oop)
which can be mapped to a file (say oop%d). Indexed variables can be
managed as 'group'.
Regards .. Subbu
|Free forum by Nabble - Scala forum||Edit this page|