Thoughts on workflow

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Thoughts on workflow

Casey Ransberger-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on workflow

Juan Vuletich-4
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
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on workflow

Casey Ransberger-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on workflow

Hannes Hirzel
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
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on workflow

Juan Vuletich-4
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
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on workflow

Juan Vuletich-4
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
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on workflow

Hannes Hirzel
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
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on workflow

Hannes Hirzel
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
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on workflow

Juan Vuletich-4
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
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on workflow

Juan Vuletich-4
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
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on workflow

garduino
In reply to this post by Juan Vuletich-4
Hi Hannes, Juan, List:

2012/12/31 Juan Vuletich <[hidden email]>

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


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
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on workflow

Hannes Hirzel
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
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on workflow

garduino
+1

2013/1/1 H. Hirzel <[hidden email]>
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




_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org