Hi Stephane,

No, we haven't.  I'm finding it challenging to figure out all the new 
tools.  For example, last week, I was intrigued by the discussion of 
Shout and wondered what it was.  I searched the Squeak Swiki, then the 
mailing list archives, and finally Googled that it was a syntax 
highlighter.  The new tools do sound very interesting (thank you, all, 
for the explanation of the new functionality being proposed wrt 
.sources and .changes) and we will consider adding the new tools to our 
course as we can.

Best wishes,
   Mark

On Sep 27, 2004, at 2:03 PM, stéphane ducasse wrote:

> 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/
>>
>>
>
>
>
__________
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/