For what it's worth, there's an OCaml "summer of code" being organized by a financial company which uses OCaml extensively. If Squeak was rejected for not being "mainstream" enough, it sounds like there's a pattern here.

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.