Thoughts on workflow
Locked
 
|
Not saving the image totally makes sense when working on a shared artifact, but it doesn't suit my solo development style. Sometimes I work on things for a long time before sharing them, and being able to keep my work context alive is one of the reasons I love working with Smalltalk.
The warning every time I make a change to a method or class that's *not* a core part of Cuis seems a little bit much to me. Here's a thought: why not keep a #(registry of classes) which belong to the core, and warn about a save only in that case? I love being able to use git, but I'm not super sure I like being forced into it all the time:/
Casey Ransberger _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
Hi Casey,
Casey Ransberger wrote: > Not saving the image totally makes sense when working on a shared > artifact, but it doesn't suit my solo development style. Sometimes I > work on things for a long time before sharing them, and being able to > keep my work context alive is one of the reasons I love working with > Smalltalk. I understand. I want to support that style too. > The warning every time I make a change to a method or class that's > *not* a core part of Cuis seems a little bit much to me. Here's a > thought: why not keep a #(registry of classes) which belong to the > core, and warn about a save only in that case? I love being able to > use git, but I'm not super sure I like being forced into it all the time:/ > > -- > Casey Ransberger Ok. I guess you refer to the warnings you get when you save the image, right? I guess you're ok with the warnings when quitting without saving, as they prevent you from the need to go to the .changes log file to recover your work. When saving the image, you get a warning about unsaved packages and another one about unsaved changes to Cuis core (i.e. changes that don't belong in any package). Their purpose is _not_ to force you to use Git, just to remind you that saving them is good practice... The warning about changes that don't belong in a package is perhaps the most important. Those change sets are zapped at image save, so you might forget about them, and maybe never publish them, or save them to be loaded on another image... The warning about unsaved packages is less important: you can save the packages on next image start, or anytime you prefer. For this warning, a possible solution would be to ask if to suppress it in the future. Or we can even remove it, after all, it is important when you quit _without_ save. What do you think? Cheers, Juan Vuletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
Below.
On Dec 30, 2012, at 6:20 PM, Juan Vuletich <[hidden email]> wrote: > Hi Casey, > > Casey Ransberger wrote: >> Not saving the image totally makes sense when working on a shared artifact, but it doesn't suit my solo development style. Sometimes I work on things for a long time before sharing them, and being able to keep my work context alive is one of the reasons I love working with Smalltalk. > > I understand. I want to support that style too. > >> The warning every time I make a change to a method or class that's *not* a core part of Cuis seems a little bit much to me. Here's a thought: why not keep a #(registry of classes) which belong to the core, and warn about a save only in that case? I love being able to use git, but I'm not super sure I like being forced into it all the time:/ >> >> -- >> Casey Ransberger > > Ok. I guess you refer to the warnings you get when you save the image, right? I guess you're ok with the warnings when quitting without saving, as they prevent you from the need to go to the .changes log file to recover your work. > > When saving the image, you get a warning about unsaved packages and another one about unsaved changes to Cuis core (i.e. changes that don't belong in any package). Their purpose is _not_ to force you to use Git, just to remind you that saving them is good practice... > > The warning about changes that don't belong in a package is perhaps the most important. Those change sets are zapped at image save, so you might forget about them, and maybe never publish them, or save them to be loaded on another image... > > The warning about unsaved packages is less important: you can save the packages on next image start, or anytime you prefer. For this warning, a possible solution would be to ask if to suppress it in the future. Or we can even remove it, after all, it is important when you quit _without_ save. > > What do you think? Forgive me if this is a bit daft, but why do the change sets have to get zapped on save? It seems like I'd want to keep them going until I was ready to commit them. Part of the problem, I think, is that I'm not completely understanding what motivates some of the design decisions involved. Casey _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
Is it correct to say that change sets (*.cs.st) are only for changes
related to core classes whereas all the other development should go to packages (*.pck.st) files? --Hannes On 12/31/12, Casey Ransberger <[hidden email]> wrote: > Below. > > On Dec 30, 2012, at 6:20 PM, Juan Vuletich <[hidden email]> wrote: > >> Hi Casey, >> >> Casey Ransberger wrote: >>> Not saving the image totally makes sense when working on a shared >>> artifact, but it doesn't suit my solo development style. Sometimes I work >>> on things for a long time before sharing them, and being able to keep my >>> work context alive is one of the reasons I love working with Smalltalk. >> >> I understand. I want to support that style too. >> >>> The warning every time I make a change to a method or class that's *not* >>> a core part of Cuis seems a little bit much to me. Here's a thought: why >>> not keep a #(registry of classes) which belong to the core, and warn >>> about a save only in that case? I love being able to use git, but I'm not >>> super sure I like being forced into it all the time:/ >>> >>> -- >>> Casey Ransberger >> >> Ok. I guess you refer to the warnings you get when you save the image, >> right? I guess you're ok with the warnings when quitting without saving, >> as they prevent you from the need to go to the .changes log file to >> recover your work. >> >> When saving the image, you get a warning about unsaved packages and >> another one about unsaved changes to Cuis core (i.e. changes that don't >> belong in any package). Their purpose is _not_ to force you to use Git, >> just to remind you that saving them is good practice... >> >> The warning about changes that don't belong in a package is perhaps the >> most important. Those change sets are zapped at image save, so you might >> forget about them, and maybe never publish them, or save them to be loaded >> on another image... >> >> The warning about unsaved packages is less important: you can save the >> packages on next image start, or anytime you prefer. For this warning, a >> possible solution would be to ask if to suppress it in the future. Or we >> can even remove it, after all, it is important when you quit _without_ >> save. >> >> What do you think? > > Forgive me if this is a bit daft, but why do the change sets have to get > zapped on save? It seems like I'd want to keep them going until I was ready > to commit them. Part of the problem, I think, is that I'm not completely > understanding what motivates some of the design decisions involved. > > Casey > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
In reply to this post by Casey Ransberger-2
Hi Casey,
(below) Casey Ransberger wrote: > Below. > > On Dec 30, 2012, at 6:20 PM, Juan Vuletich <[hidden email]> wrote: > > >> Hi Casey, >> >> Casey Ransberger wrote: >> >>> Not saving the image totally makes sense when working on a shared artifact, but it doesn't suit my solo development style. Sometimes I work on things for a long time before sharing them, and being able to keep my work context alive is one of the reasons I love working with Smalltalk. >>> >> I understand. I want to support that style too. >> >> >>> The warning every time I make a change to a method or class that's *not* a core part of Cuis seems a little bit much to me. Here's a thought: why not keep a #(registry of classes) which belong to the core, and warn about a save only in that case? I love being able to use git, but I'm not super sure I like being forced into it all the time:/ >>> >>> -- >>> Casey Ransberger >>> >> Ok. I guess you refer to the warnings you get when you save the image, right? I guess you're ok with the warnings when quitting without saving, as they prevent you from the need to go to the .changes log file to recover your work. >> >> When saving the image, you get a warning about unsaved packages and another one about unsaved changes to Cuis core (i.e. changes that don't belong in any package). Their purpose is _not_ to force you to use Git, just to remind you that saving them is good practice... >> >> The warning about changes that don't belong in a package is perhaps the most important. Those change sets are zapped at image save, so you might forget about them, and maybe never publish them, or save them to be loaded on another image... >> >> The warning about unsaved packages is less important: you can save the packages on next image start, or anytime you prefer. For this warning, a possible solution would be to ask if to suppress it in the future. Or we can even remove it, after all, it is important when you quit _without_ save. >> >> What do you think? >> > > Forgive me if this is a bit daft, but why do the change sets have to get zapped on save? It seems like I'd want to keep them going until I was ready to commit them. Part of the problem, I think, is that I'm not completely understanding what motivates some of the design decisions involved. > > Casey > Well, this new way of handling code in Cuis is still young, and only starting to get broader feedback. Nothing of this is carved on stone! We need to evolve it. Besides, it seems I didn't publicize enough http://jvuletich.org/Cuis/CodeManagementInCuis4.html and http://jvuletich.org/Cuis/CuisAndGitHub.html . The first one is what I had in my head when I did Packages and the new behavior of ChangeSets. The second one are my initial thoughts on using GitHub to host packages. Please read them, especially CodeManagementInCuis4. The main motivation for all this is that working with ChangeSets as they used to behave (and still do in Squeak and others) is a PITA. It was quite common to lose changes, contaminate one change set with stuff from the other, etc. So, now, the main idea is that regular change sets are used only for updating the base image, and they form a sequence (the update stream). Stuff that doesn't belong there is better stored in some package. This is a key idea. If you fight it, then all the rest won't make sense. If you really want to keep using change sets for stuff that will never be part of an update stream, then we need to discuss the use case, and find a way to support it (or decide to abandon it!). (There are other 'automatic' change sets for the changes you do to each package, and others that record what happens when you install a package. You can usually just ignore them.) In particular, when you save the image, the change sets with stuff for the base image are removed. My thinking here is that when you are working on them, the result of that work is not an updated image, but a sequence of change sets. This works quite well, as it eases producing an "update stream" that can be used to update other images or for publication. The idea is that when you save the image, those change sets become part of it, you no longer need them as a separate entity. See that the first option of the right click menu in the Change Sorter is "file out and remove". It is the same thing. When you are done with some changes to the base image, you save the change set, and start a new change set for what follows. This means that there is usually one single change set in existence that captures changes to the base image. This means there's no way for change sets to get mangled! And this almost enforces the change sets to form a sequence (an ordered list). To keep the discussion concrete, please give some thought to all this (especially CodeManagementInCuis4.html), and then describe your use case telling what goes into packages and what goes into change sets, at what times you save them, and if you save the image and when. It will require some effort, but the result will be polishing our procedures and tools. Cheers, Juan Vuletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
In reply to this post by Hannes Hirzel
Yes. Please see my other response to this thread.
BTW, I apologize for not being clear enough on these issues... In any case, let me repeat that this is quite young. We'll be learning about all this, and I hope we'll evolve the procedures and the tools. I mean: please tell about the flaws in the reasoning and the tools! Cheers, Juan Vuletich H. Hirzel wrote: > Is it correct to say that change sets (*.cs.st) are only for changes > related to core classes whereas all the other development should go to > packages (*.pck.st) files? > > --Hannes > > On 12/31/12, Casey Ransberger <[hidden email]> wrote: > >> Below. >> >> On Dec 30, 2012, at 6:20 PM, Juan Vuletich <[hidden email]> wrote: >> >> >>> Hi Casey, >>> >>> Casey Ransberger wrote: >>> >>>> Not saving the image totally makes sense when working on a shared >>>> artifact, but it doesn't suit my solo development style. Sometimes I work >>>> on things for a long time before sharing them, and being able to keep my >>>> work context alive is one of the reasons I love working with Smalltalk. >>>> >>> I understand. I want to support that style too. >>> >>> >>>> The warning every time I make a change to a method or class that's *not* >>>> a core part of Cuis seems a little bit much to me. Here's a thought: why >>>> not keep a #(registry of classes) which belong to the core, and warn >>>> about a save only in that case? I love being able to use git, but I'm not >>>> super sure I like being forced into it all the time:/ >>>> >>>> -- >>>> Casey Ransberger >>>> >>> Ok. I guess you refer to the warnings you get when you save the image, >>> right? I guess you're ok with the warnings when quitting without saving, >>> as they prevent you from the need to go to the .changes log file to >>> recover your work. >>> >>> When saving the image, you get a warning about unsaved packages and >>> another one about unsaved changes to Cuis core (i.e. changes that don't >>> belong in any package). Their purpose is _not_ to force you to use Git, >>> just to remind you that saving them is good practice... >>> >>> The warning about changes that don't belong in a package is perhaps the >>> most important. Those change sets are zapped at image save, so you might >>> forget about them, and maybe never publish them, or save them to be loaded >>> on another image... >>> >>> The warning about unsaved packages is less important: you can save the >>> packages on next image start, or anytime you prefer. For this warning, a >>> possible solution would be to ask if to suppress it in the future. Or we >>> can even remove it, after all, it is important when you quit _without_ >>> save. >>> >>> What do you think? >>> >> Forgive me if this is a bit daft, but why do the change sets have to get >> zapped on save? It seems like I'd want to keep them going until I was ready >> to commit them. Part of the problem, I think, is that I'm not completely >> understanding what motivates some of the design decisions involved. >> >> Casey >> _______________________________________________ >> Cuis mailing list >> [hidden email] >> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >> >> > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > > _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
Juan,
I think once one has found your web page where you explain how *.cs.st files are for the core only and the rest should be handled by *.pck.st files it is very clear. And it is a solution to a long standing problem which created a lot of discussions in the past years on the Squeak list. However at the moment I do not find the access to that page any more. :-( I do not see a link to it from http://www.jvuletich.org/Cuis/Index.html And I think as this is a major new conceptual step in terms of source code and update management (at least from the point of view of a Squeak or Pharo Smalltalk user) this deserves to have a workspace in the 'help' menu. Or at least a link in the 'Welcome' window. --Hannes On 12/31/12, Juan Vuletich <[hidden email]> wrote: > Yes. Please see my other response to this thread. > > BTW, I apologize for not being clear enough on these issues... > > In any case, let me repeat that this is quite young. We'll be learning > about all this, and I hope we'll evolve the procedures and the tools. I > mean: please tell about the flaws in the reasoning and the tools! > > Cheers, > Juan Vuletich > > H. Hirzel wrote: >> Is it correct to say that change sets (*.cs.st) are only for changes >> related to core classes whereas all the other development should go to >> packages (*.pck.st) files? >> >> --Hannes >> >> On 12/31/12, Casey Ransberger <[hidden email]> wrote: >> >>> Below. >>> >>> On Dec 30, 2012, at 6:20 PM, Juan Vuletich <[hidden email]> wrote: >>> >>> >>>> Hi Casey, >>>> >>>> Casey Ransberger wrote: >>>> >>>>> Not saving the image totally makes sense when working on a shared >>>>> artifact, but it doesn't suit my solo development style. Sometimes I >>>>> work >>>>> on things for a long time before sharing them, and being able to keep >>>>> my >>>>> work context alive is one of the reasons I love working with >>>>> Smalltalk. >>>>> >>>> I understand. I want to support that style too. >>>> >>>> >>>>> The warning every time I make a change to a method or class that's >>>>> *not* >>>>> a core part of Cuis seems a little bit much to me. Here's a thought: >>>>> why >>>>> not keep a #(registry of classes) which belong to the core, and warn >>>>> about a save only in that case? I love being able to use git, but I'm >>>>> not >>>>> super sure I like being forced into it all the time:/ >>>>> >>>>> -- >>>>> Casey Ransberger >>>>> >>>> Ok. I guess you refer to the warnings you get when you save the image, >>>> right? I guess you're ok with the warnings when quitting without >>>> saving, >>>> as they prevent you from the need to go to the .changes log file to >>>> recover your work. >>>> >>>> When saving the image, you get a warning about unsaved packages and >>>> another one about unsaved changes to Cuis core (i.e. changes that don't >>>> belong in any package). Their purpose is _not_ to force you to use Git, >>>> just to remind you that saving them is good practice... >>>> >>>> The warning about changes that don't belong in a package is perhaps the >>>> most important. Those change sets are zapped at image save, so you >>>> might >>>> forget about them, and maybe never publish them, or save them to be >>>> loaded >>>> on another image... >>>> >>>> The warning about unsaved packages is less important: you can save the >>>> packages on next image start, or anytime you prefer. For this warning, >>>> a >>>> possible solution would be to ask if to suppress it in the future. Or >>>> we >>>> can even remove it, after all, it is important when you quit _without_ >>>> save. >>>> >>>> What do you think? >>>> >>> Forgive me if this is a bit daft, but why do the change sets have to get >>> zapped on save? It seems like I'd want to keep them going until I was >>> ready >>> to commit them. Part of the problem, I think, is that I'm not completely >>> understanding what motivates some of the design decisions involved. >>> >>> Casey >>> _______________________________________________ >>> Cuis mailing list >>> [hidden email] >>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >>> >>> >> >> _______________________________________________ >> Cuis mailing list >> [hidden email] >> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >> >> >> > > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
Eh, I found the link at the bottom of the README.md file at
https://github.com/jvuletich/Cuis https://github.com/jvuletich/Cuis http://www.jvuletich.org/Cuis/CodeManagementInCuis4.html --HJH On 12/31/12, H. Hirzel <[hidden email]> wrote: > Juan, > > I think once one has found your web page where you explain how *.cs.st > files are for the core only and the rest should be handled by *.pck.st > files it is very clear. And it is a solution to a long standing > problem which created a lot of discussions in the past years on the > Squeak list. > > However at the moment I do not find the access to that page any more. :-( > I do not see a link to it from http://www.jvuletich.org/Cuis/Index.html > > And I think as this is a major new conceptual step in terms of source > code and update management (at least from the point of view of a > Squeak or Pharo Smalltalk user) this deserves to have a workspace in > the 'help' menu. Or at least a link in the 'Welcome' window. > > > --Hannes > > > On 12/31/12, Juan Vuletich <[hidden email]> wrote: >> Yes. Please see my other response to this thread. >> >> BTW, I apologize for not being clear enough on these issues... >> >> In any case, let me repeat that this is quite young. We'll be learning >> about all this, and I hope we'll evolve the procedures and the tools. I >> mean: please tell about the flaws in the reasoning and the tools! >> >> Cheers, >> Juan Vuletich >> >> H. Hirzel wrote: >>> Is it correct to say that change sets (*.cs.st) are only for changes >>> related to core classes whereas all the other development should go to >>> packages (*.pck.st) files? >>> >>> --Hannes >>> >>> On 12/31/12, Casey Ransberger <[hidden email]> wrote: >>> >>>> Below. >>>> >>>> On Dec 30, 2012, at 6:20 PM, Juan Vuletich <[hidden email]> wrote: >>>> >>>> >>>>> Hi Casey, >>>>> >>>>> Casey Ransberger wrote: >>>>> >>>>>> Not saving the image totally makes sense when working on a shared >>>>>> artifact, but it doesn't suit my solo development style. Sometimes I >>>>>> work >>>>>> on things for a long time before sharing them, and being able to keep >>>>>> my >>>>>> work context alive is one of the reasons I love working with >>>>>> Smalltalk. >>>>>> >>>>> I understand. I want to support that style too. >>>>> >>>>> >>>>>> The warning every time I make a change to a method or class that's >>>>>> *not* >>>>>> a core part of Cuis seems a little bit much to me. Here's a thought: >>>>>> why >>>>>> not keep a #(registry of classes) which belong to the core, and warn >>>>>> about a save only in that case? I love being able to use git, but I'm >>>>>> not >>>>>> super sure I like being forced into it all the time:/ >>>>>> >>>>>> -- >>>>>> Casey Ransberger >>>>>> >>>>> Ok. I guess you refer to the warnings you get when you save the image, >>>>> right? I guess you're ok with the warnings when quitting without >>>>> saving, >>>>> as they prevent you from the need to go to the .changes log file to >>>>> recover your work. >>>>> >>>>> When saving the image, you get a warning about unsaved packages and >>>>> another one about unsaved changes to Cuis core (i.e. changes that >>>>> don't >>>>> belong in any package). Their purpose is _not_ to force you to use >>>>> Git, >>>>> just to remind you that saving them is good practice... >>>>> >>>>> The warning about changes that don't belong in a package is perhaps >>>>> the >>>>> most important. Those change sets are zapped at image save, so you >>>>> might >>>>> forget about them, and maybe never publish them, or save them to be >>>>> loaded >>>>> on another image... >>>>> >>>>> The warning about unsaved packages is less important: you can save the >>>>> packages on next image start, or anytime you prefer. For this warning, >>>>> a >>>>> possible solution would be to ask if to suppress it in the future. Or >>>>> we >>>>> can even remove it, after all, it is important when you quit _without_ >>>>> save. >>>>> >>>>> What do you think? >>>>> >>>> Forgive me if this is a bit daft, but why do the change sets have to >>>> get >>>> zapped on save? It seems like I'd want to keep them going until I was >>>> ready >>>> to commit them. Part of the problem, I think, is that I'm not >>>> completely >>>> understanding what motivates some of the design decisions involved. >>>> >>>> Casey >>>> _______________________________________________ >>>> Cuis mailing list >>>> [hidden email] >>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >>>> >>>> >>> >>> _______________________________________________ >>> Cuis mailing list >>> [hidden email] >>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >>> >>> >>> >> >> >> _______________________________________________ >> Cuis mailing list >> [hidden email] >> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >> > _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
In reply to this post by Hannes Hirzel
Hi Hannes,
H. Hirzel wrote: > Juan, > > I think once one has found your web page where you explain how *.cs.st > files are for the core only and the rest should be handled by *.pck.st > files it is very clear. And it is a solution to a long standing > problem which created a lot of discussions in the past years on the > Squeak list. > > However at the moment I do not find the access to that page any more. :-( > I do not see a link to it from http://www.jvuletich.org/Cuis/Index.html > I added it today. > And I think as this is a major new conceptual step in terms of source > code and update management (at least from the point of view of a > Squeak or Pharo Smalltalk user) this deserves to have a workspace in > the 'help' menu. Or at least a link in the 'Welcome' window. > Yes, you're right. Cheers, Juan Vuletich > --Hannes > > > On 12/31/12, Juan Vuletich <[hidden email]> wrote: > >> Yes. Please see my other response to this thread. >> >> BTW, I apologize for not being clear enough on these issues... >> >> In any case, let me repeat that this is quite young. We'll be learning >> about all this, and I hope we'll evolve the procedures and the tools. I >> mean: please tell about the flaws in the reasoning and the tools! >> >> Cheers, >> Juan Vuletich >> >> H. Hirzel wrote: >> >>> Is it correct to say that change sets (*.cs.st) are only for changes >>> related to core classes whereas all the other development should go to >>> packages (*.pck.st) files? >>> >>> --Hannes >>> >>> On 12/31/12, Casey Ransberger <[hidden email]> wrote: >>> >>> >>>> Below. >>>> >>>> On Dec 30, 2012, at 6:20 PM, Juan Vuletich <[hidden email]> wrote: >>>> >>>> >>>> >>>>> Hi Casey, >>>>> >>>>> Casey Ransberger wrote: >>>>> >>>>> >>>>>> Not saving the image totally makes sense when working on a shared >>>>>> artifact, but it doesn't suit my solo development style. Sometimes I >>>>>> work >>>>>> on things for a long time before sharing them, and being able to keep >>>>>> my >>>>>> work context alive is one of the reasons I love working with >>>>>> Smalltalk. >>>>>> >>>>>> >>>>> I understand. I want to support that style too. >>>>> >>>>> >>>>> >>>>>> The warning every time I make a change to a method or class that's >>>>>> *not* >>>>>> a core part of Cuis seems a little bit much to me. Here's a thought: >>>>>> why >>>>>> not keep a #(registry of classes) which belong to the core, and warn >>>>>> about a save only in that case? I love being able to use git, but I'm >>>>>> not >>>>>> super sure I like being forced into it all the time:/ >>>>>> >>>>>> -- >>>>>> Casey Ransberger >>>>>> >>>>>> >>>>> Ok. I guess you refer to the warnings you get when you save the image, >>>>> right? I guess you're ok with the warnings when quitting without >>>>> saving, >>>>> as they prevent you from the need to go to the .changes log file to >>>>> recover your work. >>>>> >>>>> When saving the image, you get a warning about unsaved packages and >>>>> another one about unsaved changes to Cuis core (i.e. changes that don't >>>>> belong in any package). Their purpose is _not_ to force you to use Git, >>>>> just to remind you that saving them is good practice... >>>>> >>>>> The warning about changes that don't belong in a package is perhaps the >>>>> most important. Those change sets are zapped at image save, so you >>>>> might >>>>> forget about them, and maybe never publish them, or save them to be >>>>> loaded >>>>> on another image... >>>>> >>>>> The warning about unsaved packages is less important: you can save the >>>>> packages on next image start, or anytime you prefer. For this warning, >>>>> a >>>>> possible solution would be to ask if to suppress it in the future. Or >>>>> we >>>>> can even remove it, after all, it is important when you quit _without_ >>>>> save. >>>>> >>>>> What do you think? >>>>> >>>>> >>>> Forgive me if this is a bit daft, but why do the change sets have to get >>>> zapped on save? It seems like I'd want to keep them going until I was >>>> ready >>>> to commit them. Part of the problem, I think, is that I'm not completely >>>> understanding what motivates some of the design decisions involved. >>>> >>>> Casey >>>> _______________________________________________ >>>> Cuis mailing list >>>> [hidden email] >>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >>>> >>>> >>>> >>> _______________________________________________ >>> Cuis mailing list >>> [hidden email] >>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >>> >>> >>> >>> >> _______________________________________________ >> Cuis mailing list >> [hidden email] >> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >> >> > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > > _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
In reply to this post by Hannes Hirzel
H. Hirzel wrote:
> Juan, > > I think once one has found your web page where you explain how *.cs.st > files are for the core only and the rest should be handled by *.pck.st > files it is very clear. And it is a solution to a long standing > problem which created a lot of discussions in the past years on the > Squeak list. > > However at the moment I do not find the access to that page any more. :-( > I do not see a link to it from http://www.jvuletich.org/Cuis/Index.html > > And I think as this is a major new conceptual step in terms of source > code and update management (at least from the point of view of a > Squeak or Pharo Smalltalk user) this deserves to have a workspace in > the 'help' menu. Or at least a link in the 'Welcome' window. > > > --Hannes > > Added them to the help menu. Cheers, Juan Vuletich > On 12/31/12, Juan Vuletich <[hidden email]> wrote: > >> Yes. Please see my other response to this thread. >> >> BTW, I apologize for not being clear enough on these issues... >> >> In any case, let me repeat that this is quite young. We'll be learning >> about all this, and I hope we'll evolve the procedures and the tools. I >> mean: please tell about the flaws in the reasoning and the tools! >> >> Cheers, >> Juan Vuletich >> >> H. Hirzel wrote: >> >>> Is it correct to say that change sets (*.cs.st) are only for changes >>> related to core classes whereas all the other development should go to >>> packages (*.pck.st) files? >>> >>> --Hannes >>> >>> On 12/31/12, Casey Ransberger <[hidden email]> wrote: >>> >>> >>>> Below. >>>> >>>> On Dec 30, 2012, at 6:20 PM, Juan Vuletich <[hidden email]> wrote: >>>> >>>> >>>> >>>>> Hi Casey, >>>>> >>>>> Casey Ransberger wrote: >>>>> >>>>> >>>>>> Not saving the image totally makes sense when working on a shared >>>>>> artifact, but it doesn't suit my solo development style. Sometimes I >>>>>> work >>>>>> on things for a long time before sharing them, and being able to keep >>>>>> my >>>>>> work context alive is one of the reasons I love working with >>>>>> Smalltalk. >>>>>> >>>>>> >>>>> I understand. I want to support that style too. >>>>> >>>>> >>>>> >>>>>> The warning every time I make a change to a method or class that's >>>>>> *not* >>>>>> a core part of Cuis seems a little bit much to me. Here's a thought: >>>>>> why >>>>>> not keep a #(registry of classes) which belong to the core, and warn >>>>>> about a save only in that case? I love being able to use git, but I'm >>>>>> not >>>>>> super sure I like being forced into it all the time:/ >>>>>> >>>>>> -- >>>>>> Casey Ransberger >>>>>> >>>>>> >>>>> Ok. I guess you refer to the warnings you get when you save the image, >>>>> right? I guess you're ok with the warnings when quitting without >>>>> saving, >>>>> as they prevent you from the need to go to the .changes log file to >>>>> recover your work. >>>>> >>>>> When saving the image, you get a warning about unsaved packages and >>>>> another one about unsaved changes to Cuis core (i.e. changes that don't >>>>> belong in any package). Their purpose is _not_ to force you to use Git, >>>>> just to remind you that saving them is good practice... >>>>> >>>>> The warning about changes that don't belong in a package is perhaps the >>>>> most important. Those change sets are zapped at image save, so you >>>>> might >>>>> forget about them, and maybe never publish them, or save them to be >>>>> loaded >>>>> on another image... >>>>> >>>>> The warning about unsaved packages is less important: you can save the >>>>> packages on next image start, or anytime you prefer. For this warning, >>>>> a >>>>> possible solution would be to ask if to suppress it in the future. Or >>>>> we >>>>> can even remove it, after all, it is important when you quit _without_ >>>>> save. >>>>> >>>>> What do you think? >>>>> >>>>> >>>> Forgive me if this is a bit daft, but why do the change sets have to get >>>> zapped on save? It seems like I'd want to keep them going until I was >>>> ready >>>> to commit them. Part of the problem, I think, is that I'm not completely >>>> understanding what motivates some of the design decisions involved. >>>> >>>> Casey >>>> _______________________________________________ >>>> Cuis mailing list >>>> [hidden email] >>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >>>> >>>> >>>> >>> _______________________________________________ >>> Cuis mailing list >>> [hidden email] >>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >>> >>> >>> >>> >> _______________________________________________ >> Cuis mailing list >> [hidden email] >> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >> >> > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > > _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
In reply to this post by Juan Vuletich-4
Hi Hannes, Juan, List:
2012/12/31 Juan Vuletich <[hidden email]>
May be when we have a fully functional web framework in Cuis we should have a community site where all can contribute and document. I think that is very important to have a neat site to get new users.
Cheers. Germán. _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
In reply to this post by Juan Vuletich-4
On 12/31/12, Juan Vuletich <[hidden email]> wrote:
> H. Hirzel wrote: >> Juan, >> >> I think once one has found your web page where you explain how *.cs.st >> files are for the core only and the rest should be handled by *.pck.st >> files it is very clear. And it is a solution to a long standing >> problem which created a lot of discussions in the past years on the >> Squeak list. >> >> However at the moment I do not find the access to that page any more. >> :-( >> I do not see a link to it from http://www.jvuletich.org/Cuis/Index.html >> >> And I think as this is a major new conceptual step in terms of source >> code and update management (at least from the point of view of a >> Squeak or Pharo Smalltalk user) this deserves to have a workspace in >> the 'help' menu. Or at least a link in the 'Welcome' window. >> >> >> --Hannes >> >> > > Added them to the help menu. Thank you. In fact the content is well written and very understandable. Having it in the image really means that we are serious about following this approach :-) --Hannes > Cheers, > Juan Vuletich > >> On 12/31/12, Juan Vuletich <[hidden email]> wrote: >> >>> Yes. Please see my other response to this thread. >>> >>> BTW, I apologize for not being clear enough on these issues... >>> >>> In any case, let me repeat that this is quite young. We'll be learning >>> about all this, and I hope we'll evolve the procedures and the tools. I >>> mean: please tell about the flaws in the reasoning and the tools! >>> >>> Cheers, >>> Juan Vuletich >>> >>> H. Hirzel wrote: >>> >>>> Is it correct to say that change sets (*.cs.st) are only for changes >>>> related to core classes whereas all the other development should go to >>>> packages (*.pck.st) files? >>>> >>>> --Hannes >>>> >>>> On 12/31/12, Casey Ransberger <[hidden email]> wrote: >>>> >>>> >>>>> Below. >>>>> >>>>> On Dec 30, 2012, at 6:20 PM, Juan Vuletich <[hidden email]> wrote: >>>>> >>>>> >>>>> >>>>>> Hi Casey, >>>>>> >>>>>> Casey Ransberger wrote: >>>>>> >>>>>> >>>>>>> Not saving the image totally makes sense when working on a shared >>>>>>> artifact, but it doesn't suit my solo development style. Sometimes I >>>>>>> work >>>>>>> on things for a long time before sharing them, and being able to >>>>>>> keep >>>>>>> my >>>>>>> work context alive is one of the reasons I love working with >>>>>>> Smalltalk. >>>>>>> >>>>>>> >>>>>> I understand. I want to support that style too. >>>>>> >>>>>> >>>>>> >>>>>>> The warning every time I make a change to a method or class that's >>>>>>> *not* >>>>>>> a core part of Cuis seems a little bit much to me. Here's a thought: >>>>>>> why >>>>>>> not keep a #(registry of classes) which belong to the core, and warn >>>>>>> about a save only in that case? I love being able to use git, but >>>>>>> I'm >>>>>>> not >>>>>>> super sure I like being forced into it all the time:/ >>>>>>> >>>>>>> -- >>>>>>> Casey Ransberger >>>>>>> >>>>>>> >>>>>> Ok. I guess you refer to the warnings you get when you save the >>>>>> image, >>>>>> right? I guess you're ok with the warnings when quitting without >>>>>> saving, >>>>>> as they prevent you from the need to go to the .changes log file to >>>>>> recover your work. >>>>>> >>>>>> When saving the image, you get a warning about unsaved packages and >>>>>> another one about unsaved changes to Cuis core (i.e. changes that >>>>>> don't >>>>>> belong in any package). Their purpose is _not_ to force you to use >>>>>> Git, >>>>>> just to remind you that saving them is good practice... >>>>>> >>>>>> The warning about changes that don't belong in a package is perhaps >>>>>> the >>>>>> most important. Those change sets are zapped at image save, so you >>>>>> might >>>>>> forget about them, and maybe never publish them, or save them to be >>>>>> loaded >>>>>> on another image... >>>>>> >>>>>> The warning about unsaved packages is less important: you can save >>>>>> the >>>>>> packages on next image start, or anytime you prefer. For this >>>>>> warning, >>>>>> a >>>>>> possible solution would be to ask if to suppress it in the future. Or >>>>>> we >>>>>> can even remove it, after all, it is important when you quit >>>>>> _without_ >>>>>> save. >>>>>> >>>>>> What do you think? >>>>>> >>>>>> >>>>> Forgive me if this is a bit daft, but why do the change sets have to >>>>> get >>>>> zapped on save? It seems like I'd want to keep them going until I was >>>>> ready >>>>> to commit them. Part of the problem, I think, is that I'm not >>>>> completely >>>>> understanding what motivates some of the design decisions involved. >>>>> >>>>> Casey >>>>> _______________________________________________ >>>>> Cuis mailing list >>>>> [hidden email] >>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Cuis mailing list >>>> [hidden email] >>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> Cuis mailing list >>> [hidden email] >>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >>> >>> >> >> _______________________________________________ >> Cuis mailing list >> [hidden email] >> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >> >> >> > > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
+1
2013/1/1 H. Hirzel <[hidden email]>
_______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
«
Return to Cuis Smalltalk
|
1 view|%1 views
| Free forum by Nabble | Edit this page |