[Newbies] Re: Collaboration with Squeak 2.8
clinton.blackmore at gmail.com
Wed Aug 11 03:05:32 UTC 2010
On Tue, Aug 10, 2010 at 12:34 AM, Serge Stinckwich <
Serge.Stinckwich at gmail.com> wrote:
> On 22/06/10 09:59, Clinton Blackmore wrote:
>> Greetings again.
>> I'm hacking on Scratch, which is based on MIT Squeak, which is based on
>> Squeak 2.8. I want to collaborate with others on a project.
>> Monticello appears to require Squeak 3.1 or later. Is there a way for
>> me to upgrade an image?
>> If not, is there a sensible way to use a revision control system?
>> It appears to me that:
>> 1) collaborators could each create change sets, and e-mail them to each
>> other, for every one to file in (which sounds like it would be
>> confusing; surely I am not understanding something)
>> 2) every class in the code could be filed out into a directory, standard
>> version control systems could be used, and then every class could be
>> filed back in (which likewise seems daunting).
>> What sort of workflows would you recommend?
> Another idea (not the easiest) is to port Scratch to a Squeak 4.1 or Pharo
> 1.1. I have already put all the code in a metacello repository.
> Serge Stinckwich
> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam
> Every DSL ends up being Smalltalk
I had contemplated porting the code, but was not up to the task. In these
last couple of months of slowly working on my project, I've gone from
saying, "What the heck is this thing (referring to Squeak)?" to saying "How
did I ever live without live debugging and an environment like this? This
is awesome!" And that's with a Squeak that is ten years old.
This is the first I've heard of Metacello, and it wouldn't hurt me to
re-read the Monticello section in Squeak By Example. I've installed
Metacello and started on the tutorial. How do I access your repository for
Scratch? Does it run at all for you?
Going back to the original question, this is the partial solution I came up
with; I would've mentioned it here earlier but for one significant
1 - I added code to go through almost all classes in the image, and check
the timestamp on each selector. If it was newer than January 1, 2010 [the
Scratch source was released in fall 2009], it files out the class, using
cr/lf line-endings, with a number in front marking the depth in the class
hierarchy. The modified classes are all filed out to the same directory,
which can be managed with version control tools that have no idea what an
2 - I wrote another routine to look at all the files in the Classes folder,
and import them based on the order of the number in front -- ensuring that
superclasses are imported before subclasses.
The big shortcoming is that I have not got a good way to deal with deleting
selectors or classes. If you create a class, export it, and commit it to an
external version control system, and then delete it, I have no obvious way
to tell the external system that a class or method has been removed. I'm
coming to the point now where that would be useful. Conceivably I could
make some sort of manual, error-prone list of timestamps for when things are
deleted, and, on importing code, look at the timestamps, and, if they
proceed the deletion time, delete the method or class.
I have written up how to use this system for my small team here:
Incidentally, Serge, seeing as you are interesting in robotics, I thought
it'd be worth mentioning that an important aim of my project is to allow
children to program their LEGO Mindstorms Robots in a Scratch-like
environment. I am close now to being able to take a stack of Scratch blocks
and export them as real Java code, which could, in turn, be compiled with
LeJOS and uploaded to a Mindstorms NXT robot running custom firmware.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Beginners