- Pharo-dev - lists.pharo.org

[Pharo-project] Cog open-source process [WAS] Re: [Vm-dev] Re: SVN vs Git for the cogvm

by Mariano Martinez Peck

On Tue, May 3, 2011 at 5:06 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > On 3 May 2011 16:57, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > Instead of discussing where to commit I would discuss how to merge and > > define the process with VMMaker. I mean, how WE (the community) and > Eliot, > > manage the development of Cog (the VMMaker part). > > > > Take as an example today. There is "our branch" which is in > > VMMaker-oscog-XXX.NUMBER. For example, the last one is > > VMMaker-oscog-MarianoMartinezPeck.66. > > Eliot commits are in (since now) VMMaker.oscog-eem.56. Who merges? > Eliot? > > us? Would Eliot took the result of the merge as his next base version? > > Because suppose I merge it, and I get > VMMaker-oscog-MarianoMartinezPeck.67 > > which is the merge with VMMaker.oscog-eem.56. Will Eliot take that > version > > and follow his code from that one? > > or he will release VMMaker.oscog-eem.5N tomorrow, and we will need to > merge > > with VMMaker-oscog-MarianoMartinezPeck.6N? if so, the merge will always > be > > more complicated and the differences will be more and more... > > > > As to me the rule is simple: > - before making new release (or snapshot) an author should merge with > latest available version. > > it means, whoever are responsible for update, he should merge previous > work (or just base his work on > latest available version). > > This btw, a typical rule for group development. I've been followed it > since using CVS, then SVN > in many other project i were involved. > Its simple and straightforward. > Why we should invent something else? > Because it is not fun to do the same merge over and over. And the merge will be each time bigger and bigger. This is why I would like to know whether Eliot will take the result of the merge or not as the base of his next version > > Okay. So, Mariano, it is your call. Please do the merge eem.56 + > MarianoMartinezPeck.66 > and then create new ConfigurationOfCog, so next time we will build new > VMs based on this version. > > mmm I don't promise anything. I don't feel brave enough. My unique commit to VMMaker (.66) was a simple change in VMMakerTool to avoid the WorldMenu. There are more than 10 commits between them and none of them done by me. So...I am not sure I will be able to do it or to do it correctly (as opposite to CMakeVMMaker where I feel more confortable to commit and merge). Moreover one of the commits of Dave changed almost all classes (I am not saying it is bad ehh!!)...so the merge doesn't look easy. I would appreciate if you can take a look this time. Otherwise, I will try to do it along the week. Cheers mariano > Cheers > > > > Mariano > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Mariano http://marianopeck.wordpress.com

May 3, 2011

Re: [Pharo-project] SVN vs Git for the cogvm

by Igor Stasenko

On 3 May 2011 16:57, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Instead of discussing where to commit I would discuss how to merge and > define the process with VMMaker.Â I mean, how WE (the community) and Eliot, > manage the development of Cog (the VMMaker part). > > Take as an example today. There is "our branch" which is in > VMMaker-oscog-XXX.NUMBER. For example, the last one is > VMMaker-oscog-MarianoMartinezPeck.66. > Eliot commits are in (since now) VMMaker.oscog-eem.56.Â Who merges? Eliot? > us? Would Eliot took the result of the merge as his next base version? > Because suppose I merge it, and I get VMMaker-oscog-MarianoMartinezPeck.67 > which is the merge with VMMaker.oscog-eem.56. Will Eliot take that version > and follow his code from that one? > or he will release VMMaker.oscog-eem.5N tomorrow, and we will need to merge > with VMMaker-oscog-MarianoMartinezPeck.6N?Â if so, the merge will always be > more complicated and the differences will be more and more... > As to me the rule is simple: - before making new release (or snapshot) an author should merge with latest available version. it means, whoever are responsible for update, he should merge previous work (or just base his work on latest available version). This btw, a typical rule for group development. I've been followed it since using CVS, then SVN in many other project i were involved. Its simple and straightforward. Why we should invent something else? Okay. So, Mariano, it is your call. Please do the merge eem.56 + MarianoMartinezPeck.66 and then create new ConfigurationOfCog, so next time we will build new VMs based on this version. > Cheers > > Mariano -- Best regards, Igor Stasenko AKA sig.

May 3, 2011

Re: [Pharo-project] SVN vs Git for the cogvm

by Mariano Martinez Peck

Instead of discussing where to commit I would discuss how to merge and define the process with VMMaker. I mean, how WE (the community) and Eliot, manage the development of Cog (the VMMaker part). Take as an example today. There is "our branch" which is in VMMaker-oscog-XXX.NUMBER. For example, the last one is VMMaker-oscog-MarianoMartinezPeck.66. Eliot commits are in (since now) VMMaker.oscog-eem.56. Who merges? Eliot? us? Would Eliot took the result of the merge as his next base version? Because suppose I merge it, and I get VMMaker-oscog-MarianoMartinezPeck.67 which is the merge with VMMaker.oscog-eem.56. Will Eliot take that version and follow his code from that one? or he will release VMMaker.oscog-eem.5N tomorrow, and we will need to merge with VMMaker-oscog-MarianoMartinezPeck.6N? if so, the merge will always be more complicated and the differences will be more and more... Cheers Mariano On Tue, May 3, 2011 at 4:45 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 3 May 2011 16:36, Toon Verwaest <toon.verwaest(a)gmail.com> wrote: > > On 05/03/2011 07:57 AM, StÃ©phane Ducasse wrote: > >> > >> LOL > >> > >> But I can tell that I hated when sbe changed under my feets from svn to > >> git. > > > > Why the hate? See it as an opportunity to grow ;) > > > > > Personally, i really like a > git status > command.. > > It is much more convenient than analogous to svn or cvs. > I am also like that i can do crazy things with branches/sources , and > be sure that nothing is lost > and i can always revert things back to normal if i break something. > > -- > Best regards, > Igor Stasenko AKA sig. > > -- Mariano http://marianopeck.wordpress.com

May 3, 2011

Re: [Pharo-project] [OT] Meeting in Europe

by StÃ©phane Ducasse

what is eastern europe? we are at one hour from paris so if you drop by let us know Stef On May 3, 2011, at 5:45 PM, HernÃ¡n Morales Durand wrote: > Hi all, > > Sorry for the OT, I'm during this month in eastern Europe, if someone > would like to meet and talk about the Smalltalk world just write me > here or by private e-mail. > Cheers, > > -- > HernÃ¡n Morales > Information Technology Manager, > Institute of Veterinary Genetics. > National Scientific and Technical Research Council (CONICET). > La Plata (1900), Buenos Aires, Argentina. > Telephone: +54 (0221) 421-1799. > Internal: 422 > Fax: 425-7980 or 421-1799. >

May 3, 2011

Re: [Pharo-project] SVN vs Git for the cogvm

by Igor Stasenko

On 3 May 2011 16:36, Toon Verwaest <toon.verwaest(a)gmail.com> wrote: > On 05/03/2011 07:57 AM, StÃ©phane Ducasse wrote: >> >> LOL >> >> But I can tell that I hated when sbe changed under my feets from svn to >> git. > > Why the hate? See it as an opportunity to grow ;) > > Personally, i really like a git status command.. It is much more convenient than analogous to svn or cvs. I am also like that i can do crazy things with branches/sources , and be sure that nothing is lost and i can always revert things back to normal if i break something. -- Best regards, Igor Stasenko AKA sig.

May 3, 2011

Re: [Pharo-project] SVN vs Git for the cogvm

by Toon Verwaest

On 05/03/2011 07:57 AM, StÃ©phane Ducasse wrote: > LOL > > But I can tell that I hated when sbe changed under my feets from svn to git. Why the hate? See it as an opportunity to grow ;)

May 3, 2011

Re: [Pharo-project] SVN vs Git for the cogvm

by Sean Allen

On Tue, May 3, 2011 at 3:17 AM, Randal L. Schwartz <merlyn(a)stonehenge.com> wrote: >>>>>> "Norbert" == Norbert Hartl <norbert(a)hartl.name> writes: > > Norbert> Am 03.05.2011 um 08:07 schrieb Sean Allen: > >>> The more I understand git, the more I grow to hate SVN. >>> >>> And I hate SVN quite a lot now. :) >>> >>> >>> There's a lot to hate but... it could be CVS. >>> > Norbert> Which I liked much better than SCCS. > > And only slightly better than "cp foo.c foo.c.04june2008" :) > > Or my favorite: > > Â cp foo.c foo.c-GOOD > > How many of you just cringed there? :) One step down from RCS!

May 3, 2011

Re: [Pharo-project] add temp does not add the temp in 1.3 13179

by Johan Brichau

On 03 May 2011, at 10:14, Mariano Martinez Peck wrote: > aha.... I didn't try that ;) > So...in 1.2.1 adding from a browser does work, but not from the debugger? > And in 1.3 none of them? I don't know about 1.3 but it's one of the things I started to notice about 1.2.1 this week. In the browser, it works fine.

May 3, 2011

Re: [Pharo-project] digitAt: issue

by Bernat Romagosa

Done: http://code.google.com/p/pharo/issues/detail?id=4154 2011/5/2 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > open an issue and propose a path to get there > > Stef > > On May 2, 2011, at 3:34 PM, Camillo Bruni wrote: > > > DigitAt: is a horrible name then, should rather be bitAt:. > > > > the digitAt: implementation you're looking for: > > > > ^ self // (10 raisedTo: index - 1) \\ 10 > > > > thats quite short :) > > > > On 2011-05-02, at 11:35, Bernat Romagosa wrote: > > > >> Ouch, understood! > >> > >> Then what would be the proper way to address a decimal digit in a > number? I can only think of (bigNumber asString at: index) asNumber, which > is... awful. > >> > >> 2011/5/2 Sven Van Caekenberghe <sven(a)beta9.be> > >> Bernat, > >> > >> On 02 May 2011, at 11:13, Bernat Romagosa wrote: > >> > >> > Hi, try to run the following: > >> > > >> > (2 raisedTo: 100000) digitAt: 1 > >> > > >> > The expected result (if I understood what digitAt: should return) is > 9, but the message returns 0 instead. In fact, it returns 0 for any index. > >> > > >> > Is this a bug or am I missunderstanding how digitAt: should work? > >> > > >> > Cheers, > >> > > >> > Bernat Romagosa. > >> > > >> > p.s. My config is Pharo 1.2 with a 'Croquet Closure Cog VM > [CoInterpreter VMMaker-oscog.51]' on Debian Lenny. > >> > >> Consider, > >> > >> 2 raisedTo: 32 > >> > >> #digitAt: for digits 1 to 4 returns 0, 5 return 1. > >> From the comments you can see that the number is looked at in base 256. > >> The above number thus has 5 digits in this base, four are zero and the > highest one is one. > >> Furthermore, the first digit is the lowest one. > >> If you inspect the number it might become clearer. > >> > >> Any #digitAt: has to depend on the base you use to represent the number, > this one doesn't, so it seems to be useful only to return internal parts of > a number. > >> > >> HTH, > >> > >> Sven > >> > >> > >> > > > > >

May 3, 2011

Re: [Pharo-project] add temp does not add the temp in 1.3 13179

by Mariano Martinez Peck

On Tue, May 3, 2011 at 10:12 AM, Johan Brichau <johan(a)inceptive.be> wrote: > > On 03 May 2011, at 10:04, Mariano Martinez Peck wrote: > > > On Tue, May 3, 2011 at 7:53 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > > This is already broken in Pharo 1.2. > > > > In the official Pharo 1.2.1 it works correct. > > Nope. > When adding a temp while in the debugger it does not add the temp either in > Pharo1.2.1 > aha.... I didn't try that ;) So...in 1.2.1 adding from a browser does work, but not from the debugger? And in 1.3 none of them? > Johan > > > > -- Mariano http://marianopeck.wordpress.com

May 3, 2011