On Sat, Feb 24, 2007 at 01:21:50AM +0100, Yann Monclair wrote:
> Hi Giovanni,
> 
> IIRC last year we tried to apply to Google's Summer of Code. I think 
> Stephane
> Ducasse was involved too. We weren't accepted either as ESUG or  SqF, 
> not being
> "mainstream".
> I think that was one of the reasons to push forward SummerTalk.
> 
> I think Google SoC is a great initiative, but unfortunately, I don't think
> Google will accept Smalltalk projects this year again... I would love to be
> proven wrong!
> 
> What I would rather propose, is to build up a great SummerTalk, making great
> stuff with motivated students and mentors :) I was part of the first batch 
> of
> SummerTalkers in 2006, and I really enjoyed the experience. My mentor was 
> one
> of my teachers in University, Bernard Pottier, who is a long time 
> Smalltalker.
> 
> If we build up to a good SummerTalk event each year, then we will stand more
> chances to enter google SoC, or maybe we will not even want to get in :)
> 
> I would rather encourage people to offer projects and mentorship (and 
> sponsoring
> if you want to), to ESUG's SummerTalk :)

I have a project I would like to propose: an Inspector/Debugger
I am calling peek for now. It combines the best of OmniBrowser
and eToys:
http://wiki.squeak.org/squeak/5771

I am reproducing it here so people can respond to it: 

!! Idea

Peek is a different kind of object inspector that incorperates
features from an inspector and debugger to give the illusion of
being able to take apart any object into it's components
(instance variables and such) and watch it tick. It will have a
graph-based interface, where objects are represented by nodes
and pointers by edges.

The key idea behind peek is that an inspector and debugger are
fundamentally the same kind of thing: a view on an object, or
set of objects. They differ in two aspects: speed of execution,
and field of view. An inspector views it's object as it is
running in real-time, but it has a narrow field of view in that
it only views a single object and it's immediate sub-components. 

Similarly, a debugger is a view on a set of objects which share
a common thread of execution. It views the objects in
"user-time", where the speed is completely controlled by the
user, ranging from stopped to full-speed.

Peek will generalize these two concepts into an object-viewer,
where both the speed of execution and the field of view are
completely user-definable. A user-definable field of view
creates many possibilities: 

- We could open a viewer on a window and it's submorphs and
  their messages.  Messages are objects, and we could observe
  them as they are created, sent, executed, and returned.
- An object and all it's temporaries. As an object executes, it
  tends to create many short-lived objects to do it's bidding. A
  great way to speed up objects is to eliminate the creation of
  as many of those temporaries as possible. In this view, one
  could, at a glance, see how much time is spent creating and
  garbage-collecting temporary objects.
- A client socket, the requests flowing through it, and their
  creators.  Doing protocol debugging means finding the packets
  that are not correct and then figuring out where it came from.
  This usually means logging all the packets searching through
  them until the invalid ones are found. At that point,
  information about who sent the packet has often been lost. If
  we watch the socket and its packets as they are flowing, it is
  much easier to trace their origin.

This cannot easily be done using the existing tools of debugger
and inspector without a bit of indirect intervention (such as
putting self halt in the code).  This creates an additional step
in that the user has to inteligently guess about where the
problem lies, and hope that they are "close enough" to find it
when the debugger engages.

!! Interface

A dynamic field of view will require a dynamic interface; the
interfaces of the debugger and inspector are too static. Peek
will use a more direct view: every object of interest will be
drawn on screen as a view. If an object contains another object,
such as an instance variable, and both objects are within the
fild of view, An arrow will be drawn from the container to the
sub-object.  Thus, peek will render dynamic graphs of the
objects in its field of view, showing the relations between
them. Nearly all the tools in a smalltalk system could, under
peek, be reduced to the task of finding the appropriate field of
view, and let peek actually show the objects. A heiarchy browser
would set the field of view to a class and some of its ancestors
and decendents; a method finder would set the field of view to a
set of methods and their implementors.

!! Implementation

This project is quite broad in scope and has some very tricky
goals. Not the least of these is an easy way to specify the
field of view. The field of view can have absolutely any
requirements, and peek should be able to quickly find a set of
objects that satisfy any number of constraints. A simple
constraint is that the user must be able to see and understand
most of the graph at a glance.  It would be nearly impossible to
neatly compute the best set of objects to include in the field
of view. A much better solution would be to approximate the
field of view and progressively refine it as new constraints
arrive.

Also, drawing a nicee graph is no simple task, and peek requires
a graph that adjuests as objects may be added or removed from
the feild of view.

Finally, there is the original question I have neglected until
now of speed of execution. Peek will have many properties of a
veriable-speed simulator, having to address the issue of
migitating the speed of execution, especially at the speed
discontinuity between the objects inside and outside the field
of view. The Exupery solved a spiritually similar problem:
bridging the gap between compiled and interpreted code. We may
be able to borrow ideas and maybe Exupery in this area.

Given these requirements, the best way to make them into
reality, I believe, is ThingLab. ThingLab is at once a simulator
and a constraint solver, with the user interface of a graph
builder. In short, I believe it is the best way to get most of
peek working in a short ammount of time. 

Unfortunately, ThingLab is a very old abandoned project, and has
not seen any use, let alone active development, in nearly 10
years. As such, it does not work in recent squeak images and
does not integrate at all with Morphic.

!! Schedule

The first order of business is therefore to get ThingLab into a
working state in recent Squeak images. I will target a squeak
3.8 image, with the intention of eventually making ThingLab play
nicely with Morphic and eventually Tweak. 

The next task is to start building peek. The first component
that must be built is the simulator. It must be able to recieve
messages from outside the field of view and slow them down to
simulation speed, and send out messages from within the field of
view out to the raw squeak world. This could potentially done in
conjunction with the first task using ThingLab running on an
older image, such as Squeak 2.8. 

Next step would be to create the vizuallization for the objects.
One could begin by drawing all objects as a simple rectangle, or
we could use something like morphic wrappers to render all
objects as Morphs.  This solution would require some hacking of
ThingLab to replace its internal renderer with the Morphic
renderer. Depending on the difficulty this presents, it may be
postponed until later. 

At this point the guts of peek will be usable, and we can begin
creating better methods of specifying the field of view, or
implement a spring-graph to improve the look of the graph. Then
we can start improving the look and animations in the graph,
such as making messages originate from the sender and execute
inside the receiver.

-- 
Matthew Fulmer -- http://mtfulmer.wordpress.com/
Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808