Hi Mark

do you ask them to use Monticello because if they learn to publish 
regularly on their disk but also on a place such as
www.squeaksource.com then you may have a better chance to teach them a 
bit of software engineering practices (building, reproducability
of compositing an application out of components....)

I will start a lecture here and we will use: shout, refactoring 
browser, monticello and squeaksource and I will
ask them to regularly throw away their image and rebuild it from 
scratch.

Stef



> I'm sorry that I missed the beginning of this thread, to better 
> understand WHY we would want to do away with the .changes file.  I do 
> know how much we'd miss the .changes file here.
>
> Novices break Squeak, at a pretty deep level.  We have at least 75 
> students who take our second-year undergraduate required course EACH 
> SEMESTER, and several of those do corrupt their images.  (We recently 
> had a case of a Ph.D. student here corrupting his image so deeply that 
> it couldn't be saved, and we had to go bit-spelunking to retrieve code 
> that he desperately needed from workspaces!)  With the .changes file, 
> these corruptions are no more than a minor annoyance -- you recollect 
> your code from .changes, and plug it all into a new image.  Without a 
> .changes file, a crashed and corrupt image means restarting one's 
> project.  Since Murphy's Law requires that all such errors must occur 
> 12 hours before the homework deadline, the .changes file is absolutely 
> critical to our students.
>
> Mark
>
> On Sep 27, 2004, at 9:40 AM, Colin Putney wrote:
>
>> Quoting Diego Gomez Deck <DiegoGomezDeck at ConsultAr.com>:
>>
>>> This idea is the base for a lot of changes we need to do:
>>>
>>> - Store the sources *inside* the image.  The string is also an 
>>> object,
>>> isn't it?
>>>
>>> - Let use a .changes files ONLY to store the changes not present in 
>>> the
>>> image.  The .changes has to contains only the modifications made to 
>>> the
>>> image but still not saved.  That means, for instance, every time we 
>>> save
>>> the image the .changes goes empty. Note that .changes concept don't
>>> implies text-format, the .changes can be a stream of serialized 
>>> command
>>> to impact on the image.  For example, all the changes made in the 
>>> image
>>> but in browsers can be saved (like all the changes a normal user can
>>> make to an image just using the UI).
>>
>> Hi Diego,
>>
>> Actually I've done some work on this already, as part of a new 
>> packaging system
>> for Squeak. The idea is to store behavior as parse nodes in the image 
>> rather
>> than as text on disk. Then the .changes file would become a series of
>> serialized SystemChangeNotifier events, and would be cleared when the 
>> image is
>> saved. On start up we'd check the .changes file and automatically 
>> bring up a
>> "recently logged changes" browser if it's not empty.
>>
>> The main trick is to do this without breaking the VersionsBrowser or 
>> loosing
>> method history. I think Avi's Unstable Squeak experiment will help in 
>> making
>> Monticello suitable for tracking source code evolution.
>>
>> Colin
>>
>>
>>
>>
>>
> __________
> Mark Guzdial : Georgia Tech : College of Computing/GVU
> Atlanta, GA 30332-0280
> Collaborative Software Lab, http://coweb.cc.gatech.edu/csl
> http://www.cc.gatech.edu/~mark.guzdial/
>
>