Hi Luke,



_,,,^..^,,,_ (phone)
On Jun 8, 2017, at 3:15 AM, Luke Gorrie <luke@snabb.co> wrote:

On 8 June 2017 at 07:18, Ben Coman <btc@openinworld.com> wrote:
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.

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)

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.

and make for easy cross-referencing with profilers and benchmarks.

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?

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").


Cheers,
-Luke