Hi, Great job, Andrei! Just a couple of complementary remarks: - Moldable tools offer a significant departure from the original Smalltalk environment. Just think about it: we pride ourselves on our live environment, yet the default tools are utterly static. In contrast, the moldable debugger lets you switch change your debugging tools while debugging. Another example from the same family is the GTInspector: there too you can switch the inspection workflow and presentation while inspecting. "Live" should describe everything in our environment, not just the code model. - The Moldable Debugger also brings enhanced presentations into the debugger. For example, in the Glamour-specific debugger instead of only textual presentations of your objects, you get a visualization that shows the schematics of your browser. - But, the Moldable Debugger is not just a debugger or a collection of debuggers, it's an engine for building your own debuggers. And the great thing about it is that it makes it cheap. A couple of hundred lines of code cheap. This was made possible through to a complete rewrite of the debugger model that is essentially integrated in Pharo 3.0. - By making it cheap, a moldable tool opens another door: if you spend your energy building a framework, you should spend a little fraction of the overall effort and ship dedicated tools to handle that framework, too. This can increase the value of your framework significantly. For example, in Moose, we now have a browser dedicated for developing and analyzing parsers, we have debuggers for PetitParser and Glamour, we have dedicated editors for building interactive tools like Roassal or Glamour, and we have enhancements to the GTInspector for various object types we work often with. This makes Moose much more than a library: it makes it a versatile environment with which you can craft your own analyses cheaply. Yet, the cost of these additional tools is tiny compared with the overall cost of building the engines. All in all, please take a bit of time and look into this work. Moose offers examples of how it looks in practice, but the moldable tools should be used for any Pharo project. Yes, having worked on this I am biased, but I believe if we go on this route we can redefine what the IDE means. And this can be a huge opportunity both for Pharo and for Moose. Cheers, Doru On Sun, Sep 8, 2013 at 12:31 AM, Andrei Vasile Chis < chisvasileandrei@gmail.com> wrote:

Hi,

I'd like to announce the first version of the Moldable Debugger. It is a framework for creating and working with domain specific debuggers.

It's integrated into Moose and it currently comes with three debuggers: one for announcements, one for PetitParser and one for Glamour.

More information can be found here: * http://scg.unibe.ch/research/moldabledebugger* A video introducing the framework is here: *https://vimeo.com/73980431* (more are on the way)

Cheers, Andrei

-- www.tudorgirba.com "Every thing has its own flow"

excellent. BTW do you have some news about the object centric debugger for Pharo30? Stef On Sep 8, 2013, at 12:31 AM, Andrei Vasile Chis <chisvasileandrei@gmail.com> wrote:

Hi,

I'd like to announce the first version of the Moldable Debugger. It is a framework for creating and working with domain specific debuggers.

It's integrated into Moose and it currently comes with three debuggers: one for announcements, one for PetitParser and one for Glamour.

More information can be found here: http://scg.unibe.ch/research/moldabledebugger A video introducing the framework is here: https://vimeo.com/73980431 (more are on the way)

Cheers, Andrei