Smalltalk › Cuis Smalltalk

Compose a Cuis distribution from *.pck files? (was Re: [Fwd: Re: [squeak-dev] Squeaksource, Squeak and Pharo..])

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

15 messages Options

Hannes Hirzel

Compose a Cuis distribution from *.pck files? (was Re: [Fwd: Re: [squeak-dev] Squeaksource, Squeak and Pharo..])

Juan

what you note below is a very promising perspective.
Thank you very much indeed for the 4.1 release. It is very neat.

I like 4.1 very much.

--Hannes

See other notes below....

On 12/26/12, Juan Vuletich <[hidden email]> wrote:
> FYI...
>

[...]

>
> Hi Folks,
>
> Thanks for suggesting all this, Ron.
> (inline)
>
> Ron Teitelbaum wrote:
>>
>> I’m happy with the fragmentation. I wasn’t at the start of this
>> conversation but I think I’m starting to appreciate it. I agree that
>> the goals for each are a bit different and having separated achieving
>> those goals is easier. We are building some new stuff and it seems
>> that selecting the right fork for the right job “may” not have been
>> possible without the split. There are a number of new developments
>> coming, (in the VM, Spoon, Seaside, Cuis, EToys, …) and it’s possible
>> that one big monolithic Squeak may have made it more difficult for
>> all. It seems that we are closer to having split up the components
>> then we had thought.
>>
>
> I agree.
>
>> I know we cannot make everyone happy. It seems that the starting point
>> which seems to me to be COG, is the common link that binds everything
>> else. Let me know if you think that is wrong. If that is true then
>> building Squeak, or Pharo, or Cuis from a single point seems like
>> something that might help bring the communities back together. Will
>> Github or SmalltalkHub help to accomplish this? If this were a goal
>> would either do more than the other?
>>
>
> I believe that the option that allows for a minimal image that can grow
> is something close to the package support in Cuis, that is extremely
> compact, doesn't require Monticello and relies on Github (or similar)
> for version control. I like the idea of building each distribution from
> a single point. That single point could be not far from current Cuis. I
> believe that Cuis, removing Morphic, programming tools, and any other
> non-kernel image or Cuis specific stuff, could become that single point.
>
> If the people behind other Squeak distributions and Squeak derived
> projects want to go ahead with this, I volunteer for building that
> starting point by removing from Cuis any stuff that anybody doesn't want
> in there.

Yes, parts of Cuis in
https://github.com/jvuletich/Cuis

could be put into a packages (pck) directory and be loaded in with a
load script.
This would ease cooperative development of the parts in github (forking).

A first candidate could be to offload a major part of Morphic so that
only a minimal GUI like the one attached remains.

One Workspace (REPL equivalent) and the Transcript. (No movable
windows, just the screen split into two parts with the left part being
editable).

From there with an Installer script Morphic and other subsystem may be loaded.

BTW

https://github.com/search?q=cuis&p=1&ref=searchbar&type=Repositories&l=

gives as the second entry the
https://github.com/jvuletich/Cuis
project

but marked as a C# project. I assume it is because of the *.cs
extensions in the CuisUpdates subdirectory.

Having *.cs.st as equally valuable file extension for *.cs could solve
the problem.
I assume there are other solutions for this as well.

The goal is that Cuis shows up on the
https://github.com/languages/Smalltalk
dash board to enhance the visibility.

However before Morphic other packages (like Sound) are probably easier
to unload as *.pck files.

A subdirectory build or 'configurations' would be needed as well where
people can put there scripts which build various Cuis distributions.
(e.g. for example one which has Regex, PetitParser and XML tools preloaded)

>Then, the Cuis distribution would be built by loading a set of
> packages on top of it. The same could be done for the projects that
> adhere to this idea. Some of those packages could be shared. For
> instance, for Cuis, I'd be more than happy to use the Compiler package
> that Eliot works on. But, most likely, I'd not use the same Morphic
> package as Squeak. This could reduce the effort due to code duplication.
>
>> I agree with the goal, we want to be able to load a package and have
>> it work and it would be nice if the dependencies were limited/managed
>> such so that it will load in any fork. Not all packages will load in
>> every fork so knowing which will work beforehand is preferable. VW is
>> different since nobody expects that with some work it will run on
>> Oinq, I mean Cog (my name for the vm didn’t stick).
>>
>
> Qwaq for the voice of the duck, and Oinq for the pig, right? :)
>
>> It seems to me that it doesn’t really matter. There seems to be some
>> movement behind Metacello and SmalltalkHub. Sometimes movement is
>> preferable to good ideas. If Metacello works for Squeak and will work
>> with SmalltalkHub should we not include it in Squeak to give it a
>> boost? If Squeak goes with GitHub will Pharo follow?
>>
>
> Cuis doesn't include Monticello. I believe that a more compact and
> simpler implementation of package support, together with Github for
> version control, repositories, etc. is better. We are already using this
> with Cuis, and the results are good. It would be quite improbable that I
> could be persuaded of pre-loading Monticello into Cuis.
>
>> Nobody likes change but if we would all benefit from adopting some
>> similar tools should we not consider doing that for the benefit of the
>> entire Smalltalk community.
>>
>
> Agreed. Especially if it helps making the system (Cuis in my case)
> simpler, easy to understand, and manage.
>
> Cheers,
> Juan Vuletich
>
>> All the best,
>>
>> *Ron Teitelbaum*
>>
>> /Head Of Engineering/
>>
>> *3d Immersive Collaboration Consulting*
>>
>> [hidden email] <mailto:[hidden email]>
>>
>> Follow Me On Twitter: @RonTeitelbaum <https://twitter.com/RonTeitelbaum>
>>
>> www.3dicc.com <http://www.3dicc.com/>
>>
>> 3d ICC on G+
>> <https://plus.google.com/u/0/b/108936249366287171125/108936249366287171125/posts>
>>
>> *From:* [hidden email]
>> [mailto:[hidden email]] *On Behalf Of
>> *Juan Vuletich (mail lists)
>> *Sent:* Friday, December 21, 2012 3:47 PM
>> *To:* dimitris chloupis; The general-purpose Squeak developers list
>> *Subject:* Re: [squeak-dev] Squeaksource, Squeak and Pharo..
>>
>> Cuis is reasonably compatible with Squeak. It has a distinct set of
>> objectives, so some decisions are taken differently. Please see
>> http://www.jvuletich.org/Cuis/Index.html .
>>
>> Maybe after some time with the various Smalltalk variants you get used
>> to that fragmentation, and believe there are reasons for it. Or maybe
>> you can help find the means to reduce that fragmentation.
>>
>> Cheers,
>>
>> Juan Vuletich
>>
>> Quoting dimitris chloupis <[hidden email]
>> <mailto:[hidden email]>>:
>>
>> Thank you. I am definetly going to take a look at Cuis. How
>> compatible is Cuis to Squeak ?
>>
>> By the way I am already using Github for my first smalltalk
>> (pharo) project which I call "Ephestos", together with ss3 as a
>> backup plan.
>>
>> I dont do much with git , just the usual stuff, git push commit
>> pull rm add .
>>
>> I have to say, the smalltalk field is abit confusing to me as a
>> beginner, there is squeak , then there is pharo , then there is
>> Cuis, etc etc
>>
>> Its a pity there is so much fragmentation. I am sure for some
>> people this kind of freedome is cool and fun , but I personally
>> try find ways to make things work together.
>>
>> But I have loads of fun with pharo , and definitely my eye is on
>> Squeak too. I love smalltalk I wish I had discovered it earlier.
>> But better late than never I guess :D
>>
>>
>> ------------------------------------------------------------------------
>>
>> *From:* Juan Vuletich (mail lists) <[hidden email]
>> <mailto:[hidden email]>>
>> *To:* dimitris chloupis <[hidden email]
>> <mailto:[hidden email]>>; The general-purpose Squeak
>> developers list <[hidden email]
>> <mailto:[hidden email]>>
>> *Sent:* Friday, 21 December 2012, 21:33
>> *Subject:* Re: [squeak-dev] Squeaksource, Squeak and Pharo..
>>
>> Hi Dimitris,
>>
>> With Cuis, we use Github as the main place for storing packages.
>> We use git as it is intended to be used. This means that we let
>> git handle file versioning. Besides, Cuis uses lf as the line
>> terminator. This means that git can diff and merge Cuis packages.
>> For example see
>>
>>
>> https://github.com/pbella/Cuis-Ports/commit/d2c70f95b6efee4f4d7671f432b4b304b5115c1d
>> .
>>
>> Cheers,
>>
>> Juan Vuletich
>>
>> Quoting dimitris chloupis <[hidden email]
>> <mailto:[hidden email]>>:
>>
>> SqueakMap is dead, SqueakSource dead, later SmalltalkHub will
>> be dead.
>>
>> I am coming from pharo by the way, I am new with smalltalk, I
>> was a python developer.
>>
>> And I love squeak too.
>>
>> I dont understand why every smalltalk problem should be solved
>> by smalltalk.
>>
>> Github is a great community , already has gathered tons of
>> ruby and python projects, js and many more.
>>
>> I think its a great candidate for smalltalk, no offense
>> intended but definitely better that what SmalltalkHub can offer.
>>
>> I want to embrace at times all these smalltalk technologies,
>> but is hard to abandon Gihub that I have used for my projects
>> and support the smalltalk solutions instead.
>>
>> I dont want to downgrade the hard work of good people, but its
>> hard to compete with products that are designed full time by
>> big teams and matured through thousands of use cases.
>>
>> My vote goes to Github.
>>
>>
>> ------------------------------------------------------------------------
>>
>> *From:* Göran Krampe <[hidden email] <mailto:[hidden email]>>
>> *To:* The general-purpose Squeak developers list
>> <[hidden email]
>> <mailto:[hidden email]>>
>> *Sent:* Thursday, 20 December 2012, 23:14
>> *Subject:* Re: [squeak-dev] Squeaksource, Squeak and Pharo..
>>
>>
>> Hi folks!
>>
>> As the author of SqueakMap, long time Squeaker (and nowadays
>> both Squeaker and Pharooner) and also involved in some other
>> related projects (SmalltalkHub and more) my view might be of
>> some interest.
>>
>> First of all, Angel compares with the rest of the world - but
>> we have both historic and technical differences at play. Some
>> things worth noting:
>>
>> - SqueakMap was indeed started out as a generic package
>> *catalog*. It is not a SCM tool. It was format agnostic from
>> the very beginning.
>>
>> - Monticello and SqueakSource came from Avi. Superb tools but
>> when Squeaksource came I quickly warned the community that it
>> would deminish SqueakMap because it overlapped and "took over"
>> several "catalog" aspects. I was right unfortunately, but at
>> the same time SS was great and has served us very well in its
>> own right.
>>
>> - Noone has really taken SM and moved it forward. I also don't
>> have that amount of free time anymore.
>>
>> - SqueakMap is dead. Face it. :) It is not the future IMHO.
>>
>> - Monticello and Metacello are the de facto standard these
>> days for SCM and package loading. Metacello took the whole
>> dependencies/tagging/releases issue and simply rode on MC to
>> solve it. I have felt it looks overly complex but it's mostly
>> some line noise - it is not that complicated.
>>
>> - This also means that for a very, very long time package
>> management and source code management will be forever
>> "intertwined" in the Smalltalk world. Personally I say - fine!
>> Again, let's just embrace it and go.
>>
>> - The advantage is that Metacello "configurations" is "just
>> code" and can offer functionality totally independent of the
>> hosting platform for MC. So it doesn't matter if you load a
>> Metacello configuration from a website, from SS or SS3 or
>> Smalltalkhub - it all works the same!
>>
>> - Monticello AND Metacello are meant to work in Squeak too. I
>> haven't tried, but I presume Metacello works or is very close
>> to working?
>>
>> - Pharo is betting hard on Smalltalkhub. It is a really nice
>> system AND there is also an image side client tool brewing for
>> it! This means the equivalence of the SqueakMap Package Loader
>> will be easy to build in Squeak for Smalltalkhub.
>>
>>
>> So my advice would be:
>>
>> 1. Keep SqueakMap on oxygen for a little while longer while we
>> get ready to ditch it. Really.
>>
>> 2. Bet hard on Monticello (we already do, right?) and
>> Metacello for Squeak. Make sure they work. Embrace Metacello
>> even if it does look a bit complex to begin with. There are
>> lots of articles, tutorials and tons of examples to just copy
>> from. I have written two configurations these last two days
>> and "the shit works". Good work Dale! :)
>>
>> 3. Get involved in Smalltalkhub and help out making it work
>> fine for Squeak, note the name - *Smalltalk* hub. It's not
>> Pharohub! Don't set up your own unless for some odd reason
>> Pharo makes it uninhabitable for Squeak and turns it into
>> "Pharohub".
>>
>> Note that Smalltalkhub is "just" a new SS, but much more solid
>> architecture, really snazzy modern web UI, offering githubish
>> features and bloody hell, I mean, it can show diffs right
>> there in the browser!
>>
>> Smalltalkhub also has a really cool architecture so the coding
>> fun is rated A++, Nicolas is busy as a bee making it better,
>> better. I think it should be seen as a unifying playground and
>> Metacello as the "glue" that makes it possible to have
>> projects tailored for both Squeak and Pharo. It has many
>> functions for EXACTLY that.
>>
>> Either way, I am putting my efforts right there. IMHO the
>> Squeak community should do so too. If the Squeak community can
>> ride a bit on the momentum in Pharo - there is really no
>> reason not to.
>>
>> regards, Göran
>>
>>
>
>
>
> _______________________________________________
> 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

ProposalForMinimalMorphicGUIforCuis4.1.png (45K) Download Attachment

Juan Vuletich-4

Re: Compose a Cuis distribution from *.pck files? (was Re: [Fwd: Re: [squeak-dev] Squeaksource, Squeak and Pharo..])

Hi Hannes,

(inline)

H. Hirzel wrote:

> Juan
>
> what you note below is a very promising perspective.
> Thank you very much indeed for the 4.1 release. It is very neat.
>
> I like 4.1 very much.
>
> --Hannes
>
>

Thanks, Hannes. I'm glad you like it.

> See other notes below....
>
>
>
>> Hi Folks,
>> ...
>>
>> I believe that the option that allows for a minimal image that can grow
>> is something close to the package support in Cuis, that is extremely
>> compact, doesn't require Monticello and relies on Github (or similar)
>> for version control. I like the idea of building each distribution from
>> a single point. That single point could be not far from current Cuis. I
>> believe that Cuis, removing Morphic, programming tools, and any other
>> non-kernel image or Cuis specific stuff, could become that single point.
>>
>> If the people behind other Squeak distributions and Squeak derived
>> projects want to go ahead with this, I volunteer for building that
>> starting point by removing from Cuis any stuff that anybody doesn't want
>> in there.
>>
>
> Yes, parts of Cuis in
> https://github.com/jvuletich/Cuis
>
> could be put into a packages (pck) directory and be loaded in with a
> load script.
> This would ease cooperative development of the parts in github (forking).
>
> A first candidate could be to offload a major part of Morphic so that
> only a minimal GUI like the one attached remains.
>

Yes, this would be nice. It is not currently my highest priority,
although that would change if Squeak or some Squeak fork(s) adopted the
idea. I that case, supporting such project would be top priority,
because of the community impact.

If it is just for Cuis, it is of course nice, but the benefits would be
limited to Cuis and its users. Unless someone else wants to work on
this. I'd fully support such initiative.

> One Workspace (REPL equivalent) and the Transcript. (No movable
> windows, just the screen split into two parts with the left part being
> editable).
>
> >From there with an Installer script Morphic and other subsystem may be loaded.
>

Yes. This is a great idea. And it is not really hard to do. Transcript
is already read-only and independent of Morphic. And for the REPL we
have Transcripter (a.k.a. Emergency Evaluator. See #emergencyEvaluator).
In any case, living in such a restricted world, we'd really miss the
Browser and Debugger!

> BTW
>
> https://github.com/search?q=cuis&p=1&ref=searchbar&type=Repositories&l=
>
> gives as the second entry the
> https://github.com/jvuletich/Cuis
> project
>
> but marked as a C# project. I assume it is because of the *.cs
> extensions in the CuisUpdates subdirectory.
>
> Having *.cs.st as equally valuable file extension for *.cs could solve
> the problem.
> I assume there are other solutions for this as well.
>
> The goal is that Cuis shows up on the
> https://github.com/languages/Smalltalk
> dash board to enhance the visibility.
>

Agreed. I'd really like to be able to tell GitHub this is smalltalk,
without changing the file extensions (asked for help on another thread).
But we can do it if there's no alternative.

> However before Morphic other packages (like Sound) are probably easier
> to unload as *.pck files.
>
> A subdirectory build or 'configurations' would be needed as well where
> people can put there scripts which build various Cuis distributions.
> (e.g. for example one which has Regex, PetitParser and XML tools preloaded)
>

This would be nice. But for this to work smoothly, I think we'd adopt
Angel's idea of having the packages in the same repo as Cuis, so, if you
just download some (tagged) commit from there, you already have package
versions that are compatible with the Cuis version. Right?

Cheers,
Juan Vuletich

>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------

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

Hannes Hirzel

Re: Compose a Cuis distribution from *.pck files? (was Re: [Fwd: Re: [squeak-dev] Squeaksource, Squeak and Pharo..])

Thank you Juan for the answer. I have to think about it. In the
meantime I want to learn more how to use github, in particular how to
use branches. It might be that a central 'packages' directory in
https://github.com/jvuletich/Cuis together with individual forks and
branches could do the job....

And thank you for making 'Cuis' a 'Smalltalk' project on github. It show up as
'most starred this month' on https://github.com/languages/Smalltalk

And on the Squeak side some efforts have (re-)started to create a
minimal Squeak (Pavel, Colin & Edgar) from which packages may be
loaded. We'll see how it goes. Maybe some synergy is possible.

--Hannes

On 12/30/12, Juan Vuletich <[hidden email]> wrote:

> Hi Hannes,
>
> (inline)
>
> H. Hirzel wrote:
>> Juan
>>
>> what you note below is a very promising perspective.
>> Thank you very much indeed for the 4.1 release. It is very neat.
>>
>> I like 4.1 very much.
>>
>> --Hannes
>>
>>
>
> Thanks, Hannes. I'm glad you like it.
>
>> See other notes below....
>>
>>
>>
>>> Hi Folks,
>>> ...
>>>
>>> I believe that the option that allows for a minimal image that can grow
>>> is something close to the package support in Cuis, that is extremely
>>> compact, doesn't require Monticello and relies on Github (or similar)
>>> for version control. I like the idea of building each distribution from
>>> a single point. That single point could be not far from current Cuis. I
>>> believe that Cuis, removing Morphic, programming tools, and any other
>>> non-kernel image or Cuis specific stuff, could become that single point.
>>>
>>> If the people behind other Squeak distributions and Squeak derived
>>> projects want to go ahead with this, I volunteer for building that
>>> starting point by removing from Cuis any stuff that anybody doesn't want
>>> in there.
>>>
>>
>> Yes, parts of Cuis in
>> https://github.com/jvuletich/Cuis
>>
>> could be put into a packages (pck) directory and be loaded in with a
>> load script.
>> This would ease cooperative development of the parts in github (forking).
>>
>> A first candidate could be to offload a major part of Morphic so that
>> only a minimal GUI like the one attached remains.
>>
>
> Yes, this would be nice. It is not currently my highest priority,
> although that would change if Squeak or some Squeak fork(s) adopted the
> idea. I that case, supporting such project would be top priority,
> because of the community impact.
>
> If it is just for Cuis, it is of course nice, but the benefits would be
> limited to Cuis and its users. Unless someone else wants to work on
> this. I'd fully support such initiative.
>
>> One Workspace (REPL equivalent) and the Transcript. (No movable
>> windows, just the screen split into two parts with the left part being
>> editable).
>>
>> >From there with an Installer script Morphic and other subsystem may be
>> loaded.
>>
>
> Yes. This is a great idea. And it is not really hard to do. Transcript
> is already read-only and independent of Morphic. And for the REPL we
> have Transcripter (a.k.a. Emergency Evaluator. See #emergencyEvaluator).
> In any case, living in such a restricted world, we'd really miss the
> Browser and Debugger!
>
>> BTW
>>
>> https://github.com/search?q=cuis&p=1&ref=searchbar&type=Repositories&l=
>>
>> gives as the second entry the
>> https://github.com/jvuletich/Cuis
>> project
>>
>> but marked as a C# project. I assume it is because of the *.cs
>> extensions in the CuisUpdates subdirectory.
>>
>> Having *.cs.st as equally valuable file extension for *.cs could solve
>> the problem.
>> I assume there are other solutions for this as well.
>>
>> The goal is that Cuis shows up on the
>> https://github.com/languages/Smalltalk
>> dash board to enhance the visibility.
>>
>
> Agreed. I'd really like to be able to tell GitHub this is smalltalk,
> without changing the file extensions (asked for help on another thread).
> But we can do it if there's no alternative.
>
>> However before Morphic other packages (like Sound) are probably easier
>> to unload as *.pck files.
>>
>> A subdirectory build or 'configurations' would be needed as well where
>> people can put there scripts which build various Cuis distributions.
>> (e.g. for example one which has Regex, PetitParser and XML tools
>> preloaded)
>>
>
> This would be nice. But for this to work smoothly, I think we'd adopt
> Angel's idea of having the packages in the same repo as Cuis, so, if you
> just download some (tagged) commit from there, you already have package
> versions that are compatible with the Cuis version. Right?
>
> Cheers,
> Juan Vuletich
>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> ------------------------------------------------------------------------
>
>
> _______________________________________________
> 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

Hannes Hirzel

Re: Compose a Cuis distribution from *.pck files? (was Re: [Fwd: Re: [squeak-dev] Squeaksource, Squeak and Pharo..])

And I think it is useful to have a look at the directory structure of
https://github.com/bonzini/smalltalk (GNU Smalltalk)

--Hannes

On 12/30/12, H. Hirzel <[hidden email]> wrote:

> Thank you Juan for the answer. I have to think about it. In the
> meantime I want to learn more how to use github, in particular how to
> use branches. It might be that a central 'packages' directory in
> https://github.com/jvuletich/Cuis together with individual forks and
> branches could do the job....
>
> And thank you for making 'Cuis' a 'Smalltalk' project on github. It show up
> as
> 'most starred this month' on https://github.com/languages/Smalltalk
>
> And on the Squeak side some efforts have (re-)started to create a
> minimal Squeak (Pavel, Colin & Edgar) from which packages may be
> loaded. We'll see how it goes. Maybe some synergy is possible.
>
> --Hannes
>
>
> On 12/30/12, Juan Vuletich <[hidden email]> wrote:
>> Hi Hannes,
>>
>> (inline)
>>
>> H. Hirzel wrote:
>>> Juan
>>>
>>> what you note below is a very promising perspective.
>>> Thank you very much indeed for the 4.1 release. It is very neat.
>>>
>>> I like 4.1 very much.
>>>
>>> --Hannes
>>>
>>>
>>
>> Thanks, Hannes. I'm glad you like it.
>>
>>> See other notes below....
>>>
>>>
>>>
>>>> Hi Folks,
>>>> ...
>>>>
>>>> I believe that the option that allows for a minimal image that can grow
>>>> is something close to the package support in Cuis, that is extremely
>>>> compact, doesn't require Monticello and relies on Github (or similar)
>>>> for version control. I like the idea of building each distribution from
>>>> a single point. That single point could be not far from current Cuis. I
>>>> believe that Cuis, removing Morphic, programming tools, and any other
>>>> non-kernel image or Cuis specific stuff, could become that single
>>>> point.
>>>>
>>>> If the people behind other Squeak distributions and Squeak derived
>>>> projects want to go ahead with this, I volunteer for building that
>>>> starting point by removing from Cuis any stuff that anybody doesn't
>>>> want
>>>> in there.
>>>>
>>>
>>> Yes, parts of Cuis in
>>> https://github.com/jvuletich/Cuis
>>>
>>> could be put into a packages (pck) directory and be loaded in with a
>>> load script.
>>> This would ease cooperative development of the parts in github
>>> (forking).
>>>
>>> A first candidate could be to offload a major part of Morphic so that
>>> only a minimal GUI like the one attached remains.
>>>
>>
>> Yes, this would be nice. It is not currently my highest priority,
>> although that would change if Squeak or some Squeak fork(s) adopted the
>> idea. I that case, supporting such project would be top priority,
>> because of the community impact.
>>
>> If it is just for Cuis, it is of course nice, but the benefits would be
>> limited to Cuis and its users. Unless someone else wants to work on
>> this. I'd fully support such initiative.
>>
>>> One Workspace (REPL equivalent) and the Transcript. (No movable
>>> windows, just the screen split into two parts with the left part being
>>> editable).
>>>
>>> >From there with an Installer script Morphic and other subsystem may be
>>> loaded.
>>>
>>
>> Yes. This is a great idea. And it is not really hard to do. Transcript
>> is already read-only and independent of Morphic. And for the REPL we
>> have Transcripter (a.k.a. Emergency Evaluator. See #emergencyEvaluator).
>> In any case, living in such a restricted world, we'd really miss the
>> Browser and Debugger!
>>
>>> BTW
>>>
>>> https://github.com/search?q=cuis&p=1&ref=searchbar&type=Repositories&l=
>>>
>>> gives as the second entry the
>>> https://github.com/jvuletich/Cuis
>>> project
>>>
>>> but marked as a C# project. I assume it is because of the *.cs
>>> extensions in the CuisUpdates subdirectory.
>>>
>>> Having *.cs.st as equally valuable file extension for *.cs could solve
>>> the problem.
>>> I assume there are other solutions for this as well.
>>>
>>> The goal is that Cuis shows up on the
>>> https://github.com/languages/Smalltalk
>>> dash board to enhance the visibility.
>>>
>>
>> Agreed. I'd really like to be able to tell GitHub this is smalltalk,
>> without changing the file extensions (asked for help on another thread).
>> But we can do it if there's no alternative.
>>
>>> However before Morphic other packages (like Sound) are probably easier
>>> to unload as *.pck files.
>>>
>>> A subdirectory build or 'configurations' would be needed as well where
>>> people can put there scripts which build various Cuis distributions.
>>> (e.g. for example one which has Regex, PetitParser and XML tools
>>> preloaded)
>>>
>>
>> This would be nice. But for this to work smoothly, I think we'd adopt
>> Angel's idea of having the packages in the same repo as Cuis, so, if you
>> just download some (tagged) commit from there, you already have package
>> versions that are compatible with the Cuis version. Right?
>>
>> Cheers,
>> Juan Vuletich
>>
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> ------------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> 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

Angel Java Lopez

Re: Compose a Cuis distribution from *.pck files? (was Re: [Fwd: Re: [squeak-dev] Squeaksource, Squeak and Pharo..])

Interesting... see the combination of tags and branches

On Sun, Dec 30, 2012 at 6:53 PM, H. Hirzel <[hidden email]> wrote:

And I think it is useful to have a look at the directory structure of
https://github.com/bonzini/smalltalk (GNU Smalltalk)

--Hannes

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

Juan Vuletich-4

Re: Compose a Cuis distribution from *.pck files? (was Re: [Fwd: Re: [squeak-dev] Squeaksource, Squeak and Pharo..])

In reply to this post by Hannes Hirzel

H. Hirzel wrote:
> Thank you Juan for the answer. I have to think about it. In the
> meantime I want to learn more how to use github, in particular how to
> use branches. It might be that a central 'packages' directory in
> https://github.com/jvuletich/Cuis together with individual forks and
> branches could do the job....
>

I'm not a github expert at all. Please keep us posted on what you learn...

> And thank you for making 'Cuis' a 'Smalltalk' project on github. It show up as
> 'most starred this month' on https://github.com/languages/Smalltalk
>

:)

> And on the Squeak side some efforts have (re-)started to create a
> minimal Squeak (Pavel, Colin & Edgar) from which packages may be
> loaded. We'll see how it goes. Maybe some synergy is possible.
>

Yes. Let's hope the best.

Cheers,
Juan Vuletich

> --Hannes
>
>
> On 12/30/12, Juan Vuletich <[hidden email]> wrote:
>
>> Hi Hannes,
>>
>> (inline)
>>
>> H. Hirzel wrote:
>>
>>> Juan
>>>
>>> what you note below is a very promising perspective.
>>> Thank you very much indeed for the 4.1 release. It is very neat.
>>>
>>> I like 4.1 very much.
>>>
>>> --Hannes
>>>
>>>
>>>
>> Thanks, Hannes. I'm glad you like it.
>>
>>
>>> See other notes below....
>>>
>>>
>>>
>>>
>>>> Hi Folks,
>>>> ...
>>>>
>>>> I believe that the option that allows for a minimal image that can grow
>>>> is something close to the package support in Cuis, that is extremely
>>>> compact, doesn't require Monticello and relies on Github (or similar)
>>>> for version control. I like the idea of building each distribution from
>>>> a single point. That single point could be not far from current Cuis. I
>>>> believe that Cuis, removing Morphic, programming tools, and any other
>>>> non-kernel image or Cuis specific stuff, could become that single point.
>>>>
>>>> If the people behind other Squeak distributions and Squeak derived
>>>> projects want to go ahead with this, I volunteer for building that
>>>> starting point by removing from Cuis any stuff that anybody doesn't want
>>>> in there.
>>>>
>>>>
>>> Yes, parts of Cuis in
>>> https://github.com/jvuletich/Cuis
>>>
>>> could be put into a packages (pck) directory and be loaded in with a
>>> load script.
>>> This would ease cooperative development of the parts in github (forking).
>>>
>>> A first candidate could be to offload a major part of Morphic so that
>>> only a minimal GUI like the one attached remains.
>>>
>>>
>> Yes, this would be nice. It is not currently my highest priority,
>> although that would change if Squeak or some Squeak fork(s) adopted the
>> idea. I that case, supporting such project would be top priority,
>> because of the community impact.
>>
>> If it is just for Cuis, it is of course nice, but the benefits would be
>> limited to Cuis and its users. Unless someone else wants to work on
>> this. I'd fully support such initiative.
>>
>>
>>> One Workspace (REPL equivalent) and the Transcript. (No movable
>>> windows, just the screen split into two parts with the left part being
>>> editable).
>>>
>>> >From there with an Installer script Morphic and other subsystem may be
>>> loaded.
>>>
>>>
>> Yes. This is a great idea. And it is not really hard to do. Transcript
>> is already read-only and independent of Morphic. And for the REPL we
>> have Transcripter (a.k.a. Emergency Evaluator. See #emergencyEvaluator).
>> In any case, living in such a restricted world, we'd really miss the
>> Browser and Debugger!
>>
>>
>>> BTW
>>>
>>> https://github.com/search?q=cuis&p=1&ref=searchbar&type=Repositories&l=
>>>
>>> gives as the second entry the
>>> https://github.com/jvuletich/Cuis
>>> project
>>>
>>> but marked as a C# project. I assume it is because of the *.cs
>>> extensions in the CuisUpdates subdirectory.
>>>
>>> Having *.cs.st as equally valuable file extension for *.cs could solve
>>> the problem.
>>> I assume there are other solutions for this as well.
>>>
>>> The goal is that Cuis shows up on the
>>> https://github.com/languages/Smalltalk
>>> dash board to enhance the visibility.
>>>
>>>
>> Agreed. I'd really like to be able to tell GitHub this is smalltalk,
>> without changing the file extensions (asked for help on another thread).
>> But we can do it if there's no alternative.
>>
>>
>>> However before Morphic other packages (like Sound) are probably easier
>>> to unload as *.pck files.
>>>
>>> A subdirectory build or 'configurations' would be needed as well where
>>> people can put there scripts which build various Cuis distributions.
>>> (e.g. for example one which has Regex, PetitParser and XML tools
>>> preloaded)
>>>
>>>
>> This would be nice. But for this to work smoothly, I think we'd adopt
>> Angel's idea of having the packages in the same repo as Cuis, so, if you
>> just download some (tagged) commit from there, you already have package
>> versions that are compatible with the Cuis version. Right?
>>
>> Cheers,
>> Juan Vuletich
>>
>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>> _______________________________________________
>> 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 Vuletich-4

Re: Compose a Cuis distribution from *.pck files? (was Re: [Fwd: Re: [squeak-dev] Squeaksource, Squeak and Pharo..])

In reply to this post by Angel Java Lopez

Can you elaborate? You see here something I don't get.

Thanks,
Juan Vuletich

Angel Java Lopez wrote:

> Interesting... see the combination of tags and branches
>
> On Sun, Dec 30, 2012 at 6:53 PM, H. Hirzel <[hidden email]
> <mailto:[hidden email]>> wrote:
>
> And I think it is useful to have a look at the directory structure of
> https://github.com/bonzini/smalltalk (GNU Smalltalk)
>
> --Hannes
>

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

Hannes Hirzel

Re: Compose a Cuis distribution from *.pck files? (was Re: [Fwd: Re: [squeak-dev] Squeaksource, Squeak and Pharo..])

There are about 40 branches with names like 'Seaside', 'Omnibrowser',
'Filesystem' ....

and the tags are used for version numbers.

It seems that the integration/development of a subsystem is done in a branch.

I think we all have to read Chapter 3 of the git book

http://git-scm.com/book/en/Git-Branching

<citation>
Some people refer to the branching model in Git as its “killer
feature” , and it certainly sets Git apart in the VCS community. Why
is it so special? The way Git branches is incredibly lightweight,
making branching operations nearly instantaneous and switching back
and forth between branches generally just as fast. Unlike many other
VCSs, Git encourages a workflow that branches and merges often, even
multiple times in a day. Understanding and mastering this feature
gives you a powerful and unique tool and can literally change the way
that you develop.
</citation>

:-)

--Hannes

On 12/31/12, Juan Vuletich <[hidden email]> wrote:

> Can you elaborate? You see here something I don't get.
>
> Thanks,
> Juan Vuletich
>
> Angel Java Lopez wrote:
>> Interesting... see the combination of tags and branches
>>
>> On Sun, Dec 30, 2012 at 6:53 PM, H. Hirzel <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>> And I think it is useful to have a look at the directory structure of
>> https://github.com/bonzini/smalltalk (GNU Smalltalk)
>>
>> --Hannes
>>
>
>
> _______________________________________________
> 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

Hannes Hirzel

Re: Compose a Cuis distribution from *.pck files? (was Re: [Fwd: Re: [squeak-dev] Squeaksource, Squeak and Pharo..])

and later

<citation>
Because a branch in Git is in actuality a simple file that contains
the 40 character SHA-1 checksum of the commit it points to, branches
are cheap to create and destroy. Creating a new branch is as quick and
simple as writing 41 bytes to a file (40 characters and a newline).

This is in sharp contrast to the way most VCS tools branch, which
involves copying all of the project’s files into a second directory.
This can take several seconds or even minutes, depending on the size
of the project, whereas in Git the process is always instantaneous.
Also, because we’re recording the parents when we commit, finding a
proper merge base for merging is automatically done for us and is
generally very easy to do. These features help encourage developers to
create and use branches often.
</citation>

Angel,

how do you think we should use branches?

Amber https://github.com/NicolasPetton/amber (Smalltalk which compiles
to JavaScript and runs on node.js or in a browser) for example only
has 5.

--Hannes

On 12/31/12, H. Hirzel <[hidden email]> wrote:

> There are about 40 branches with names like 'Seaside', 'Omnibrowser',
> 'Filesystem' ....
>
> and the tags are used for version numbers.
>
> It seems that the integration/development of a subsystem is done in a
> branch.
>
> I think we all have to read Chapter 3 of the git book
>
> http://git-scm.com/book/en/Git-Branching
>
> <citation>
> Some people refer to the branching model in Git as its “killer
> feature” , and it certainly sets Git apart in the VCS community. Why
> is it so special? The way Git branches is incredibly lightweight,
> making branching operations nearly instantaneous and switching back
> and forth between branches generally just as fast. Unlike many other
> VCSs, Git encourages a workflow that branches and merges often, even
> multiple times in a day. Understanding and mastering this feature
> gives you a powerful and unique tool and can literally change the way
> that you develop.
> </citation>
>
> :-)
>
> --Hannes
>
>
> On 12/31/12, Juan Vuletich <[hidden email]> wrote:
>> Can you elaborate? You see here something I don't get.
>>
>> Thanks,
>> Juan Vuletich
>>
>> Angel Java Lopez wrote:
>>> Interesting... see the combination of tags and branches
>>>
>>> On Sun, Dec 30, 2012 at 6:53 PM, H. Hirzel <[hidden email]
>>> <mailto:[hidden email]>> wrote:
>>>
>>> And I think it is useful to have a look at the directory structure
>>> of
>>> https://github.com/bonzini/smalltalk (GNU Smalltalk)
>>>
>>> --Hannes
>>>
>>
>>
>> _______________________________________________
>> 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

Hannes Hirzel

Re: Compose a Cuis distribution from *.pck files? (was Re: [Fwd: Re: [squeak-dev] Squeaksource, Squeak and Pharo..])

Sorry, the last two mails should have gone under the 'Learning git'
subject line.

As for building a Cuis distribution from *.pck files I think we need a
'packages' and a 'scripts' directory in the main repository

https://github.com/jvuletich/Cuis

And as we are at adding directories...
in addition a 'documentation' directory

--Hannes

On 12/31/12, H. Hirzel <[hidden email]> wrote:

> and later
>
> <citation>
> Because a branch in Git is in actuality a simple file that contains
> the 40 character SHA-1 checksum of the commit it points to, branches
> are cheap to create and destroy. Creating a new branch is as quick and
> simple as writing 41 bytes to a file (40 characters and a newline).
>
> This is in sharp contrast to the way most VCS tools branch, which
> involves copying all of the project’s files into a second directory.
> This can take several seconds or even minutes, depending on the size
> of the project, whereas in Git the process is always instantaneous.
> Also, because we’re recording the parents when we commit, finding a
> proper merge base for merging is automatically done for us and is
> generally very easy to do. These features help encourage developers to
> create and use branches often.
> </citation>
>
> Angel,
>
> how do you think we should use branches?
>
> Amber https://github.com/NicolasPetton/amber (Smalltalk which compiles
> to JavaScript and runs on node.js or in a browser) for example only
> has 5.
>
>
> --Hannes
>
> On 12/31/12, H. Hirzel <[hidden email]> wrote:
>> There are about 40 branches with names like 'Seaside', 'Omnibrowser',
>> 'Filesystem' ....
>>
>> and the tags are used for version numbers.
>>
>> It seems that the integration/development of a subsystem is done in a
>> branch.
>>
>> I think we all have to read Chapter 3 of the git book
>>
>> http://git-scm.com/book/en/Git-Branching
>>
>> <citation>
>> Some people refer to the branching model in Git as its “killer
>> feature” , and it certainly sets Git apart in the VCS community. Why
>> is it so special? The way Git branches is incredibly lightweight,
>> making branching operations nearly instantaneous and switching back
>> and forth between branches generally just as fast. Unlike many other
>> VCSs, Git encourages a workflow that branches and merges often, even
>> multiple times in a day. Understanding and mastering this feature
>> gives you a powerful and unique tool and can literally change the way
>> that you develop.
>> </citation>
>>
>> :-)
>>
>> --Hannes
>>
>>
>> On 12/31/12, Juan Vuletich <[hidden email]> wrote:
>>> Can you elaborate? You see here something I don't get.
>>>
>>> Thanks,
>>> Juan Vuletich
>>>
>>> Angel Java Lopez wrote:
>>>> Interesting... see the combination of tags and branches
>>>>
>>>> On Sun, Dec 30, 2012 at 6:53 PM, H. Hirzel <[hidden email]
>>>> <mailto:[hidden email]>> wrote:
>>>>
>>>> And I think it is useful to have a look at the directory structure
>>>> of
>>>> https://github.com/bonzini/smalltalk (GNU Smalltalk)
>>>>
>>>> --Hannes
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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

Hannes Hirzel

Re: Compose a Cuis distribution from *.pck files? (was Re: [Fwd: Re: [squeak-dev] Squeaksource, Squeak and Pharo..])

I have now done a sample how a repository could look like, see
https://github.com/hhzl/Cuis

A copy of PetitParser is in a subdirectory 'packages'.

I did this following the instructions of Angel in the 'Learning github
...' thread. Thank you, Angel.

What is still missing is the proper use of branches. This should not
be done in a main branch but in a 'PetitParser' branch.

--Hannes

On 12/31/12, H. Hirzel <[hidden email]> wrote:

> Sorry, the last two mails should have gone under the 'Learning git'
> subject line.
>
> As for building a Cuis distribution from *.pck files I think we need a
> 'packages' and a 'scripts' directory in the main repository
>
> https://github.com/jvuletich/Cuis
>
> And as we are at adding directories...
> in addition a 'documentation' directory
>
> --Hannes
>
> On 12/31/12, H. Hirzel <[hidden email]> wrote:
>> and later
>>
>> <citation>
>> Because a branch in Git is in actuality a simple file that contains
>> the 40 character SHA-1 checksum of the commit it points to, branches
>> are cheap to create and destroy. Creating a new branch is as quick and
>> simple as writing 41 bytes to a file (40 characters and a newline).
>>
>> This is in sharp contrast to the way most VCS tools branch, which
>> involves copying all of the project’s files into a second directory.
>> This can take several seconds or even minutes, depending on the size
>> of the project, whereas in Git the process is always instantaneous.
>> Also, because we’re recording the parents when we commit, finding a
>> proper merge base for merging is automatically done for us and is
>> generally very easy to do. These features help encourage developers to
>> create and use branches often.
>> </citation>
>>
>> Angel,
>>
>> how do you think we should use branches?
>>
>> Amber https://github.com/NicolasPetton/amber (Smalltalk which compiles
>> to JavaScript and runs on node.js or in a browser) for example only
>> has 5.
>>
>>
>> --Hannes
>>
>> On 12/31/12, H. Hirzel <[hidden email]> wrote:
>>> There are about 40 branches with names like 'Seaside', 'Omnibrowser',
>>> 'Filesystem' ....
>>>
>>> and the tags are used for version numbers.
>>>
>>> It seems that the integration/development of a subsystem is done in a
>>> branch.
>>>
>>> I think we all have to read Chapter 3 of the git book
>>>
>>> http://git-scm.com/book/en/Git-Branching
>>>
>>> <citation>
>>> Some people refer to the branching model in Git as its “killer
>>> feature” , and it certainly sets Git apart in the VCS community. Why
>>> is it so special? The way Git branches is incredibly lightweight,
>>> making branching operations nearly instantaneous and switching back
>>> and forth between branches generally just as fast. Unlike many other
>>> VCSs, Git encourages a workflow that branches and merges often, even
>>> multiple times in a day. Understanding and mastering this feature
>>> gives you a powerful and unique tool and can literally change the way
>>> that you develop.
>>> </citation>
>>>
>>> :-)
>>>
>>> --Hannes
>>>
>>>
>>> On 12/31/12, Juan Vuletich <[hidden email]> wrote:
>>>> Can you elaborate? You see here something I don't get.
>>>>
>>>> Thanks,
>>>> Juan Vuletich
>>>>
>>>> Angel Java Lopez wrote:
>>>>> Interesting... see the combination of tags and branches
>>>>>
>>>>> On Sun, Dec 30, 2012 at 6:53 PM, H. Hirzel <[hidden email]
>>>>> <mailto:[hidden email]>> wrote:
>>>>>
>>>>> And I think it is useful to have a look at the directory structure
>>>>> of
>>>>> https://github.com/bonzini/smalltalk (GNU Smalltalk)
>>>>>
>>>>> --Hannes
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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

Angel Java Lopez

Re: Compose a Cuis distribution from *.pck files? (was Re: [Fwd: Re: [squeak-dev] Squeaksource, Squeak and Pharo..])

Hi people!

I don't know enough of Smalltalk (and its source code in file) to see the best o better way of using GitHub. But I see in other technologies, used in this way:

- Branch x is an experimental branch, on new or improved feature a. For example, x == stm and the feature is a == Software Transactional Memory. Eventually, the branch dissapears, or it is merged with the main one

- Branch x is for other platform. Some people uses branch in this way, or eventually it fork another project. But this way of use is rare, AFAIK

- Branch x is an experimental branch, but born from an external pull request. That is, some other author wrote a Software Transactional Memory implementation, and then, the main author(s) of the central repo, accept his/her contribution, but not in master yet, only to be testes and stressed by all.

In forked repos, branches are used by the external contributor in the following way. He/she has many ideas, fixes, issues it can resolved. Then, forks the original repo, and not start to work DIRECTLY on this new fork. Instead, he/she creates a branch FOR EACH idea, fix, bug solution, etc... The branches are used like the patches in other systems. Author makes a pull request to central repo, per branch. So, the central authors can accept or reject by branch.

Regarding Juan question, about "elaborate", the above was about branch. About tags, you can see in the Smalltalk GNU project the use of tags for versions. That is the "standard" way on most technologies.

Angel "Java" Lopez

@ajlopez

github:ajlopez

On Mon, Dec 31, 2012 at 5:49 AM, H. Hirzel <[hidden email]> wrote:

I have now done a sample how a repository could look like, see
https://github.com/hhzl/Cuis

A copy of PetitParser is in a subdirectory 'packages'.

I did this following the instructions of Angel in the 'Learning github
...' thread. Thank you, Angel.

What is still missing is the proper use of branches. This should not
be done in a main branch but in a 'PetitParser' branch.

--Hannes

On 12/31/12, H. Hirzel <[hidden email]> wrote:
> Sorry, the last two mails should have gone under the 'Learning git'
> subject line.
>
> As for building a Cuis distribution from *.pck files I think we need a
> 'packages' and a 'scripts' directory in the main repository
>
> https://github.com/jvuletich/Cuis
>
> And as we are at adding directories...
> in addition a 'documentation' directory
>
> --Hannes
>
> On 12/31/12, H. Hirzel <[hidden email]> wrote:
>> and later
>>
>> <citation>
>> Because a branch in Git is in actuality a simple file that contains
>> the 40 character SHA-1 checksum of the commit it points to, branches
>> are cheap to create and destroy. Creating a new branch is as quick and
>> simple as writing 41 bytes to a file (40 characters and a newline).
>>
>> This is in sharp contrast to the way most VCS tools branch, which
>> involves copying all of the project’s files into a second directory.
>> This can take several seconds or even minutes, depending on the size
>> of the project, whereas in Git the process is always instantaneous.
>> Also, because we’re recording the parents when we commit, finding a
>> proper merge base for merging is automatically done for us and is
>> generally very easy to do. These features help encourage developers to
>> create and use branches often.
>> </citation>
>>
>> Angel,
>>
>> how do you think we should use branches?
>>
>> Amber https://github.com/NicolasPetton/amber (Smalltalk which compiles
>> to JavaScript and runs on node.js or in a browser) for example only
>> has 5.
>>
>>
>> --Hannes
>>
>> On 12/31/12, H. Hirzel <[hidden email]> wrote:
>>> There are about 40 branches with names like 'Seaside', 'Omnibrowser',
>>> 'Filesystem' ....
>>>
>>> and the tags are used for version numbers.
>>>
>>> It seems that the integration/development of a subsystem is done in a
>>> branch.
>>>
>>> I think we all have to read Chapter 3 of the git book
>>>
>>> http://git-scm.com/book/en/Git-Branching
>>>
>>> <citation>
>>> Some people refer to the branching model in Git as its “killer
>>> feature” , and it certainly sets Git apart in the VCS community. Why
>>> is it so special? The way Git branches is incredibly lightweight,
>>> making branching operations nearly instantaneous and switching back
>>> and forth between branches generally just as fast. Unlike many other
>>> VCSs, Git encourages a workflow that branches and merges often, even
>>> multiple times in a day. Understanding and mastering this feature
>>> gives you a powerful and unique tool and can literally change the way
>>> that you develop.
>>> </citation>
>>>
>>> :-)
>>>
>>> --Hannes
>>>
>>>
>>> On 12/31/12, Juan Vuletich <[hidden email]> wrote:
>>>> Can you elaborate? You see here something I don't get.
>>>>
>>>> Thanks,
>>>> Juan Vuletich
>>>>
>>>> Angel Java Lopez wrote:
>>>>> Interesting... see the combination of tags and branches
>>>>>
>>>>> On Sun, Dec 30, 2012 at 6:53 PM, H. Hirzel <[hidden email]
>>>>> <mailto:[hidden email]>> wrote:
>>>>>
>>>>> And I think it is useful to have a look at the directory structure
>>>>> of
>>>>> https://github.com/bonzini/smalltalk (GNU Smalltalk)
>>>>>
>>>>> --Hannes
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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

Hannes Hirzel

Re: Compose a Cuis distribution from *.pck files? (was Re: [Fwd: Re: [squeak-dev] Squeaksource, Squeak and Pharo..])

Hello Angel

thank you for this concise summary. It helps me a lot.

So a workflow for me could look like this

1) I work in my fork https://github.com/hhzl/Cuis
2) I create a branch for an idea, fix, bug solution as concerns the
general Cuis development as well as branches for my own development.
3a) I issue pull requests to Juan for a particular branch if I think
it should go into Juan's repository.
3b) Juan accepts and merges the update or not.
3c) I re-synchronize with Juan's master branch from time to time by
git pull upstream master [1]
3d) I merge it into my master branch.
4) For the 'repositories' subdirectory: we have a branch for each
package group, i.e. one for PetitParser, one for RegularExpressions
etc.

From a Cuis point of view it seems that this is a good solution.

So far however people have been developing external packages for Cuis
in separate repositories
https://github.com/jvuletich/Cuis/blob/master/ListOfCuisPackages.md.
In case of a package which should be loadable in different Squeak
(Smalltalk) distributions that seems to be better.

But as all packages on the list
https://github.com/jvuletich/Cuis/blob/master/ListOfCuisPackages.md
are Cuis specific they might as well just be maintained in individual
forks/branches of the main Cuis distribution as shown in
https://github.com/hhzl/Cuis (no branches yet)

And in particular as it is about Smalltalk artifacts which are
compatible with the Cuis core.

What do you think?

--Hannes

[1] http://stackoverflow.com/questions/2257196/git-pull-from-other-branch

On 12/31/12, Angel Java Lopez <[hidden email]> wrote:

> Hi people!
>
> I don't know enough of Smalltalk (and its source code in file) to see the
> best o better way of using GitHub. But I see in other technologies, used in
> this way:
>
> - Branch x is an experimental branch, on new or improved feature a. For
> example, x == stm and the feature is a == Software Transactional Memory.
> Eventually, the branch dissapears, or it is merged with the main one
>
> - Branch x is for other platform. Some people uses branch in this way, or
> eventually it fork another project. But this way of use is rare, AFAIK
>
> - Branch x is an experimental branch, but born from an external pull
> request. That is, some other author wrote a Software Transactional Memory
> implementation, and then, the main author(s) of the central repo, accept
> his/her contribution, but not in master yet, only to be testes and stressed
> by all.
>
> In forked repos, branches are used by the external contributor in the
> following way. He/she has many ideas, fixes, issues it can resolved. Then,
> forks the original repo, and not start to work DIRECTLY on this new fork.
> Instead, he/she creates a branch FOR EACH idea, fix, bug solution, etc...
> The branches are used like the patches in other systems. Author makes a
> pull request to central repo, per branch. So, the central authors can
> accept or reject by branch.
>
> Regarding Juan question, about "elaborate", the above was about branch.
> About tags, you can see in the Smalltalk GNU project the use of tags for
> versions. That is the "standard" way on most technologies.
>
> Angel "Java" Lopez
> @ajlopez
> github:ajlopez
>
>
> On Mon, Dec 31, 2012 at 5:49 AM, H. Hirzel <[hidden email]> wrote:
>
>> I have now done a sample how a repository could look like, see
>> https://github.com/hhzl/Cuis
>>
>> A copy of PetitParser is in a subdirectory 'packages'.
>>
>> I did this following the instructions of Angel in the 'Learning github
>> ...' thread. Thank you, Angel.
>>
>> What is still missing is the proper use of branches. This should not
>> be done in a main branch but in a 'PetitParser' branch.
>>
>> --Hannes
>>
>> On 12/31/12, H. Hirzel <[hidden email]> wrote:
>> > Sorry, the last two mails should have gone under the 'Learning git'
>> > subject line.
>> >
>> > As for building a Cuis distribution from *.pck files I think we need a
>> > 'packages' and a 'scripts' directory in the main repository
>> >
>> > https://github.com/jvuletich/Cuis
>> >
>> > And as we are at adding directories...
>> > in addition a 'documentation' directory
>> >
>> > --Hannes
>> >
>> > On 12/31/12, H. Hirzel <[hidden email]> wrote:
>> >> and later
>> >>
>> >> <citation>
>> >> Because a branch in Git is in actuality a simple file that contains
>> >> the 40 character SHA-1 checksum of the commit it points to, branches
>> >> are cheap to create and destroy. Creating a new branch is as quick and
>> >> simple as writing 41 bytes to a file (40 characters and a newline).
>> >>
>> >> This is in sharp contrast to the way most VCS tools branch, which
>> >> involves copying all of the project’s files into a second directory.
>> >> This can take several seconds or even minutes, depending on the size
>> >> of the project, whereas in Git the process is always instantaneous.
>> >> Also, because we’re recording the parents when we commit, finding a
>> >> proper merge base for merging is automatically done for us and is
>> >> generally very easy to do. These features help encourage developers to
>> >> create and use branches often.
>> >> </citation>
>> >>
>> >> Angel,
>> >>
>> >> how do you think we should use branches?
>> >>
>> >> Amber https://github.com/NicolasPetton/amber (Smalltalk which compiles
>> >> to JavaScript and runs on node.js or in a browser) for example only
>> >> has 5.
>> >>
>> >>
>> >> --Hannes
>> >>
>> >> On 12/31/12, H. Hirzel <[hidden email]> wrote:
>> >>> There are about 40 branches with names like 'Seaside', 'Omnibrowser',
>> >>> 'Filesystem' ....
>> >>>
>> >>> and the tags are used for version numbers.
>> >>>
>> >>> It seems that the integration/development of a subsystem is done in a
>> >>> branch.
>> >>>
>> >>> I think we all have to read Chapter 3 of the git book
>> >>>
>> >>> http://git-scm.com/book/en/Git-Branching
>> >>>
>> >>> <citation>
>> >>> Some people refer to the branching model in Git as its “killer
>> >>> feature” , and it certainly sets Git apart in the VCS community. Why
>> >>> is it so special? The way Git branches is incredibly lightweight,
>> >>> making branching operations nearly instantaneous and switching back
>> >>> and forth between branches generally just as fast. Unlike many other
>> >>> VCSs, Git encourages a workflow that branches and merges often, even
>> >>> multiple times in a day. Understanding and mastering this feature
>> >>> gives you a powerful and unique tool and can literally change the way
>> >>> that you develop.
>> >>> </citation>
>> >>>
>> >>> :-)
>> >>>
>> >>> --Hannes
>> >>>
>> >>>
>> >>> On 12/31/12, Juan Vuletich <[hidden email]> wrote:
>> >>>> Can you elaborate? You see here something I don't get.
>> >>>>
>> >>>> Thanks,
>> >>>> Juan Vuletich
>> >>>>
>> >>>> Angel Java Lopez wrote:
>> >>>>> Interesting... see the combination of tags and branches
>> >>>>>
>> >>>>> On Sun, Dec 30, 2012 at 6:53 PM, H. Hirzel <[hidden email]
>> >>>>> <mailto:[hidden email]>> wrote:
>> >>>>>
>> >>>>> And I think it is useful to have a look at the directory
>> structure
>> >>>>> of
>> >>>>> https://github.com/bonzini/smalltalk (GNU Smalltalk)
>> >>>>>
>> >>>>> --Hannes
>> >>>>>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> 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 Vuletich-4

Re: Compose a Cuis distribution from *.pck files? (was Re: [Fwd: Re: [squeak-dev] Squeaksource, Squeak and Pharo..])

In reply to this post by Angel Java Lopez

Thanks Angel. Your insights will surely be very useful, even if we'll
take it slow.

Cheers,
Juan Vuletich

Angel Java Lopez wrote:

> Hi people!
>
> I don't know enough of Smalltalk (and its source code in file) to see
> the best o better way of using GitHub. But I see in other
> technologies, used in this way:
>
> - Branch x is an experimental branch, on new or improved feature a.
> For example, x == stm and the feature is a == Software Transactional
> Memory. Eventually, the branch dissapears, or it is merged with the
> main one
>
> - Branch x is for other platform. Some people uses branch in this way,
> or eventually it fork another project. But this way of use is rare, AFAIK
>
> - Branch x is an experimental branch, but born from an external pull
> request. That is, some other author wrote a Software Transactional
> Memory implementation, and then, the main author(s) of the central
> repo, accept his/her contribution, but not in master yet, only to be
> testes and stressed by all.
>
> In forked repos, branches are used by the external contributor in the
> following way. He/she has many ideas, fixes, issues it can resolved.
> Then, forks the original repo, and not start to work DIRECTLY on this
> new fork. Instead, he/she creates a branch FOR EACH idea, fix, bug
> solution, etc... The branches are used like the patches in other
> systems. Author makes a pull request to central repo, per branch. So,
> the central authors can accept or reject by branch.
>
> Regarding Juan question, about "elaborate", the above was about
> branch. About tags, you can see in the Smalltalk GNU project the use
> of tags for versions. That is the "standard" way on most technologies.
>
> Angel "Java" Lopez
> @ajlopez
> github:ajlopez
>
>
> On Mon, Dec 31, 2012 at 5:49 AM, H. Hirzel <[hidden email]
> <mailto:[hidden email]>> wrote:
>
> I have now done a sample how a repository could look like, see
> https://github.com/hhzl/Cuis
>
> A copy of PetitParser is in a subdirectory 'packages'.
>
> I did this following the instructions of Angel in the 'Learning github
> ...' thread. Thank you, Angel.
>
> What is still missing is the proper use of branches. This should not
> be done in a main branch but in a 'PetitParser' branch.
>
> --Hannes
>
> On 12/31/12, H. Hirzel <[hidden email]
> <mailto:[hidden email]>> wrote:
> > Sorry, the last two mails should have gone under the 'Learning git'
> > subject line.
> >
> > As for building a Cuis distribution from *.pck files I think we
> need a
> > 'packages' and a 'scripts' directory in the main repository
> >
> > https://github.com/jvuletich/Cuis
> >
> > And as we are at adding directories...
> > in addition a 'documentation' directory
> >
> > --Hannes
> >
> > On 12/31/12, H. Hirzel <[hidden email]
> <mailto:[hidden email]>> wrote:
> >> and later
> >>
> >> <citation>
> >> Because a branch in Git is in actuality a simple file that contains
> >> the 40 character SHA-1 checksum of the commit it points to,
> branches
> >> are cheap to create and destroy. Creating a new branch is as
> quick and
> >> simple as writing 41 bytes to a file (40 characters and a newline).
> >>
> >> This is in sharp contrast to the way most VCS tools branch, which
> >> involves copying all of the project’s files into a second
> directory.
> >> This can take several seconds or even minutes, depending on the
> size
> >> of the project, whereas in Git the process is always instantaneous.
> >> Also, because we’re recording the parents when we commit, finding a
> >> proper merge base for merging is automatically done for us and is
> >> generally very easy to do. These features help encourage
> developers to
> >> create and use branches often.
> >> </citation>
> >>
> >> Angel,
> >>
> >> how do you think we should use branches?
> >>
> >> Amber https://github.com/NicolasPetton/amber (Smalltalk which
> compiles
> >> to JavaScript and runs on node.js or in a browser) for example only
> >> has 5.
> >>
> >>
> >> --Hannes
> >>
> >> On 12/31/12, H. Hirzel <[hidden email]
> <mailto:[hidden email]>> wrote:
> >>> There are about 40 branches with names like 'Seaside',
> 'Omnibrowser',
> >>> 'Filesystem' ....
> >>>
> >>> and the tags are used for version numbers.
> >>>
> >>> It seems that the integration/development of a subsystem is
> done in a
> >>> branch.
> >>>
> >>> I think we all have to read Chapter 3 of the git book
> >>>
> >>> http://git-scm.com/book/en/Git-Branching
> >>>
> >>> <citation>
> >>> Some people refer to the branching model in Git as its “killer
> >>> feature” , and it certainly sets Git apart in the VCS
> community. Why
> >>> is it so special? The way Git branches is incredibly lightweight,
> >>> making branching operations nearly instantaneous and switching
> back
> >>> and forth between branches generally just as fast. Unlike many
> other
> >>> VCSs, Git encourages a workflow that branches and merges
> often, even
> >>> multiple times in a day. Understanding and mastering this feature
> >>> gives you a powerful and unique tool and can literally change
> the way
> >>> that you develop.
> >>> </citation>
> >>>
> >>> :-)
> >>>
> >>> --Hannes
> >>>
> >>>
> >>> On 12/31/12, Juan Vuletich <[hidden email]
> <mailto:[hidden email]>> wrote:
> >>>> Can you elaborate? You see here something I don't get.
> >>>>
> >>>> Thanks,
> >>>> Juan Vuletich
> >>>>
> >>>> Angel Java Lopez wrote:
> >>>>> Interesting... see the combination of tags and branches
> >>>>>
> >>>>> On Sun, Dec 30, 2012 at 6:53 PM, H. Hirzel
> <[hidden email] <mailto:[hidden email]>
> >>>>> <mailto:[hidden email]
> <mailto:[hidden email]>>> wrote:
> >>>>>
> >>>>> And I think it is useful to have a look at the directory
> structure
> >>>>> of
> >>>>> https://github.com/bonzini/smalltalk (GNU Smalltalk)
> >>>>>
> >>>>> --Hannes
> >>>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Cuis mailing list
> >>>> [hidden email] <mailto:[hidden email]>
> >>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> >>>>
> >>>
> >>
> >
>
> _______________________________________________
> Cuis mailing list
> [hidden email] <mailto:[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

garduino

Re: Compose a Cuis distribution from *.pck files? (was Re: [Fwd: Re: [squeak-dev] Squeaksource, Squeak and Pharo..])

Sure, a great contribution of Angel with knowledge about Git.

Thanks.

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

Thanks Angel. Your insights will surely be very useful, even if we'll take it slow.

Cheers,

Juan Vuletich

Angel Java Lopez wrote:

Hi people!

I don't know enough of Smalltalk (and its source code in file) to see the best o better way of using GitHub. But I see in other technologies, used in this way:

- Branch x is an experimental branch, on new or improved feature a. For example, x == stm and the feature is a == Software Transactional Memory. Eventually, the branch dissapears, or it is merged with the main one

- Branch x is for other platform. Some people uses branch in this way, or eventually it fork another project. But this way of use is rare, AFAIK

- Branch x is an experimental branch, but born from an external pull request. That is, some other author wrote a Software Transactional Memory implementation, and then, the main author(s) of the central repo, accept his/her contribution, but not in master yet, only to be testes and stressed by all.

In forked repos, branches are used by the external contributor in the following way. He/she has many ideas, fixes, issues it can resolved. Then, forks the original repo, and not start to work DIRECTLY on this new fork. Instead, he/she creates a branch FOR EACH idea, fix, bug solution, etc... The branches are used like the patches in other systems. Author makes a pull request to central repo, per branch. So, the central authors can accept or reject by branch.

Regarding Juan question, about "elaborate", the above was about branch. About tags, you can see in the Smalltalk GNU project the use of tags for versions. That is the "standard" way on most technologies.

Angel "Java" Lopez
@ajlopez
github:ajlopez

On Mon, Dec 31, 2012 at 5:49 AM, H. Hirzel <[hidden email] <mailto:[hidden email]>> wrote:

I have now done a sample how a repository could look like, see
https://github.com/hhzl/Cuis

A copy of PetitParser is in a subdirectory 'packages'.

I did this following the instructions of Angel in the 'Learning github
...' thread. Thank you, Angel.

What is still missing is the proper use of branches. This should not
be done in a main branch but in a 'PetitParser' branch.

--Hannes

On 12/31/12, H. Hirzel <[hidden email]
<mailto:[hidden email]>> wrote:
> Sorry, the last two mails should have gone under the 'Learning git'
> subject line.
>
> As for building a Cuis distribution from *.pck files I think we
need a
> 'packages' and a 'scripts' directory in the main repository
>
> https://github.com/jvuletich/Cuis
>
> And as we are at adding directories...
> in addition a 'documentation' directory
>
> --Hannes
>
> On 12/31/12, H. Hirzel <[hidden email]
<mailto:[hidden email]>> wrote:
>> and later
>>
>> <citation>
>> Because a branch in Git is in actuality a simple file that contains
>> the 40 character SHA-1 checksum of the commit it points to,
branches
>> are cheap to create and destroy. Creating a new branch is as
quick and
>> simple as writing 41 bytes to a file (40 characters and a newline).
>>
>> This is in sharp contrast to the way most VCS tools branch, which
>> involves copying all of the project’s files into a second
directory.
>> This can take several seconds or even minutes, depending on the
size
>> of the project, whereas in Git the process is always instantaneous.
>> Also, because we’re recording the parents when we commit, finding a
>> proper merge base for merging is automatically done for us and is
>> generally very easy to do. These features help encourage
developers to
>> create and use branches often.
>> </citation>
>>
>> Angel,
>>
>> how do you think we should use branches?
>>
>> Amber https://github.com/NicolasPetton/amber (Smalltalk which
compiles
>> to JavaScript and runs on node.js or in a browser) for example only
>> has 5.
>>
>>
>> --Hannes
>>
>> On 12/31/12, H. Hirzel <[hidden email]
<mailto:[hidden email]>> wrote:
>>> There are about 40 branches with names like 'Seaside',
'Omnibrowser',
>>> 'Filesystem' ....
>>>
>>> and the tags are used for version numbers.
>>>
>>> It seems that the integration/development of a subsystem is
done in a
>>> branch.
>>>
>>> I think we all have to read Chapter 3 of the git book
>>>
>>> http://git-scm.com/book/en/Git-Branching
>>>
>>> <citation>
>>> Some people refer to the branching model in Git as its “killer
>>> feature” , and it certainly sets Git apart in the VCS
community. Why
>>> is it so special? The way Git branches is incredibly lightweight,
>>> making branching operations nearly instantaneous and switching
back
>>> and forth between branches generally just as fast. Unlike many
other
>>> VCSs, Git encourages a workflow that branches and merges
often, even
>>> multiple times in a day. Understanding and mastering this feature
>>> gives you a powerful and unique tool and can literally change
the way
>>> that you develop.
>>> </citation>
>>>
>>> :-)
>>>
>>> --Hannes
>>>
>>>
>>> On 12/31/12, Juan Vuletich <[hidden email]
<mailto:[hidden email]>> wrote:
>>>> Can you elaborate? You see here something I don't get.
>>>>
>>>> Thanks,
>>>> Juan Vuletich
>>>>
>>>> Angel Java Lopez wrote:
>>>>> Interesting... see the combination of tags and branches
>>>>>
>>>>> On Sun, Dec 30, 2012 at 6:53 PM, H. Hirzel
<[hidden email] <mailto:[hidden email]>
>>>>> <mailto:[hidden email]

<mailto:[hidden email]>>> wrote:
>>>>>
>>>>> And I think it is useful to have a look at the directory
structure
>>>>> of
>>>>> https://github.com/bonzini/smalltalk (GNU Smalltalk)
>>>>>
>>>>> --Hannes
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Cuis mailing list
>>>> [hidden email] <mailto:[hidden email]>

>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>>
>>>
>>
>

_______________________________________________
Cuis mailing list
[hidden email] <mailto:[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