+1<br><br><div class="gmail_quote">2013/1/1 H. Hirzel <span dir="ltr"><<a href="mailto:hannes.hirzel@gmail.com" target="_blank">hannes.hirzel@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 12/31/12, Juan Vuletich <<a href="mailto:juan@jvuletich.org">juan@jvuletich.org</a>> wrote:<br>
</div><div class="im">> H. Hirzel wrote:<br>
>> Juan,<br>
>><br>
>> I think once one has found your web page where you explain how *.<a href="http://cs.st" target="_blank">cs.st</a><br>
>> files are for the core only and the rest should be handled by *.<a href="http://pck.st" target="_blank">pck.st</a><br>
>> files it is very clear. And it is a solution to a long standing<br>
>> problem which created a lot of discussions in the past years on the<br>
>> Squeak list.<br>
>><br>
>> However at the moment I do not find the access to that page any more.<br>
>> :-(<br>
>> I do not see a link to it from <a href="http://www.jvuletich.org/Cuis/Index.html" target="_blank">http://www.jvuletich.org/Cuis/Index.html</a><br>
>><br>
>> And I think as this is a major new conceptual step in terms of source<br>
>> code and update management (at least from the point of view of a<br>
>> Squeak or Pharo Smalltalk user) this deserves to have a workspace in<br>
>> the 'help' menu. Or at least a link in the 'Welcome' window.<br>
>><br>
>><br>
>> --Hannes<br>
>><br>
>><br>
><br>
> Added them to the help menu.<br>
<br>
<br>
</div>Thank you. In fact the content is well written and very<br>
understandable. Having it in the image really means that we are<br>
serious about following this approach :-)<br>
<br>
--Hannes<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
> Cheers,<br>
> Juan Vuletich<br>
><br>
>> On 12/31/12, Juan Vuletich <<a href="mailto:juan@jvuletich.org">juan@jvuletich.org</a>> wrote:<br>
>><br>
>>> Yes. Please see my other response to this thread.<br>
>>><br>
>>> BTW, I apologize for not being clear enough on these issues...<br>
>>><br>
>>> In any case, let me repeat that this is quite young. We'll be learning<br>
>>> about all this, and I hope we'll evolve the procedures and the tools. I<br>
>>> mean: please tell about the flaws in the reasoning and the tools!<br>
>>><br>
>>> Cheers,<br>
>>> Juan Vuletich<br>
>>><br>
>>> H. Hirzel wrote:<br>
>>><br>
>>>> Is it correct to say that change sets (*.<a href="http://cs.st" target="_blank">cs.st</a>) are only for changes<br>
>>>> related to core classes whereas all the other development should go to<br>
>>>> packages (*.<a href="http://pck.st" target="_blank">pck.st</a>) files?<br>
>>>><br>
>>>> --Hannes<br>
>>>><br>
>>>> On 12/31/12, Casey Ransberger <<a href="mailto:casey.obrien.r@gmail.com">casey.obrien.r@gmail.com</a>> wrote:<br>
>>>><br>
>>>><br>
>>>>> Below.<br>
>>>>><br>
>>>>> On Dec 30, 2012, at 6:20 PM, Juan Vuletich <<a href="mailto:juan@jvuletich.org">juan@jvuletich.org</a>> wrote:<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>>> Hi Casey,<br>
>>>>>><br>
>>>>>> Casey Ransberger wrote:<br>
>>>>>><br>
>>>>>><br>
>>>>>>> Not saving the image totally makes sense when working on a shared<br>
>>>>>>> artifact, but it doesn't suit my solo development style. Sometimes I<br>
>>>>>>> work<br>
>>>>>>> on things for a long time before sharing them, and being able to<br>
>>>>>>> keep<br>
>>>>>>> my<br>
>>>>>>> work context alive is one of the reasons I love working with<br>
>>>>>>> Smalltalk.<br>
>>>>>>><br>
>>>>>>><br>
>>>>>> I understand. I want to support that style too.<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>>> The warning every time I make a change to a method or class that's<br>
>>>>>>> *not*<br>
>>>>>>> a core part of Cuis seems a little bit much to me. Here's a thought:<br>
>>>>>>> why<br>
>>>>>>> not keep a #(registry of classes) which belong to the core, and warn<br>
>>>>>>> about a save only in that case? I love being able to use git, but<br>
>>>>>>> I'm<br>
>>>>>>> not<br>
>>>>>>> super sure I like being forced into it all the time:/<br>
>>>>>>><br>
>>>>>>> --<br>
>>>>>>> Casey Ransberger<br>
>>>>>>><br>
>>>>>>><br>
>>>>>> Ok. I guess you refer to the warnings you get when you save the<br>
>>>>>> image,<br>
>>>>>> right? I guess you're ok with the warnings when quitting without<br>
>>>>>> saving,<br>
>>>>>> as they prevent you from the need to go to the .changes log file to<br>
>>>>>> recover your work.<br>
>>>>>><br>
>>>>>> When saving the image, you get a warning about unsaved packages and<br>
>>>>>> another one about unsaved changes to Cuis core (i.e. changes that<br>
>>>>>> don't<br>
>>>>>> belong in any package). Their purpose is _not_ to force you to use<br>
>>>>>> Git,<br>
>>>>>> just to remind you that saving them is good practice...<br>
>>>>>><br>
>>>>>> The warning about changes that don't belong in a package is perhaps<br>
>>>>>> the<br>
>>>>>> most important. Those change sets are zapped at image save, so you<br>
>>>>>> might<br>
>>>>>> forget about them, and maybe never publish them, or save them to be<br>
>>>>>> loaded<br>
>>>>>> on another image...<br>
>>>>>><br>
>>>>>> The warning about unsaved packages is less important: you can save<br>
>>>>>> the<br>
>>>>>> packages on next image start, or anytime you prefer. For this<br>
>>>>>> warning,<br>
>>>>>> a<br>
>>>>>> possible solution would be to ask if to suppress it in the future. Or<br>
>>>>>> we<br>
>>>>>> can even remove it, after all, it is important when you quit<br>
>>>>>> _without_<br>
>>>>>> save.<br>
>>>>>><br>
>>>>>> What do you think?<br>
>>>>>><br>
>>>>>><br>
>>>>> Forgive me if this is a bit daft, but why do the change sets have to<br>
>>>>> get<br>
>>>>> zapped on save? It seems like I'd want to keep them going until I was<br>
>>>>> ready<br>
>>>>> to commit them. Part of the problem, I think, is that I'm not<br>
>>>>> completely<br>
>>>>> understanding what motivates some of the design decisions involved.<br>
>>>>><br>
>>>>> Casey<br>
>>>>> _______________________________________________<br>
>>>>> Cuis mailing list<br>
>>>>> <a href="mailto:Cuis@jvuletich.org">Cuis@jvuletich.org</a><br>
>>>>> <a href="http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org" target="_blank">http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org</a><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>> _______________________________________________<br>
>>>> Cuis mailing list<br>
>>>> <a href="mailto:Cuis@jvuletich.org">Cuis@jvuletich.org</a><br>
>>>> <a href="http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org" target="_blank">http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org</a><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>> _______________________________________________<br>
>>> Cuis mailing list<br>
>>> <a href="mailto:Cuis@jvuletich.org">Cuis@jvuletich.org</a><br>
>>> <a href="http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org" target="_blank">http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org</a><br>
>>><br>
>>><br>
>><br>
>> _______________________________________________<br>
>> Cuis mailing list<br>
>> <a href="mailto:Cuis@jvuletich.org">Cuis@jvuletich.org</a><br>
>> <a href="http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org" target="_blank">http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org</a><br>
>><br>
>><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> Cuis mailing list<br>
> <a href="mailto:Cuis@jvuletich.org">Cuis@jvuletich.org</a><br>
> <a href="http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org" target="_blank">http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org</a><br>
><br>
<br>
_______________________________________________<br>
Cuis mailing list<br>
<a href="mailto:Cuis@jvuletich.org">Cuis@jvuletich.org</a><br>
<a href="http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org" target="_blank">http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>