But mark

You have to look at Monticello :). The idea is that a category is a 
package then you have to mark class extension using *mycategory
then you can publish a package on a ftp, disk, http server and this is 
really cool. Because you get all your code away from an image in a save 
and
reproduceable environment. I can send you the extremely limited doc I 
started to do for my students. (but this is really limited 3 pages).
Shout is really cool.

Squeaksource is just a repository, go a create an account for your 
package
go to www.squeaksource.com
create an account and a project (after once you have created a 
Squeakmap account) you can publish on SM with on click :)

Stef

On 27 sept. 04, at 20:39, Mark Guzdial wrote:

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