May 2011 - Pharo-dev - lists.pharo.org

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

by Stefan Marr

Hi: On 02 May 2011, at 17:22, Camillo Bruni wrote: > Hi eliot, > > I wanted to know if there is a particular reason that you use svn over git? > Since it is quite a hassle each time to merge the svn history to the git repos, which I think is a bit of useless repetitive work which could be avoided. +1, a general sync between the Cog git repos and the main SVN trunk would also be very helpful. > I think it would be nice if you could switch to git as well, actually there is not much difference to svn, and with some nice macros you can make behave almost the same... Easy git is very nice for ex-svn users like me: http://people.gnome.org/~newren/eg/git-for-svn-users.html And is the best Git GUI I came across so far: http://www.git-tower.com/ Best regards Stefan PS: Camillo, what happened to the MCGit, it just works? -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

May 2, 2011

Re: [Pharo-project] Think about migration upfront! (was Re: squeaksource is down - a different perspective)

by Miguel CobÃ¡

Sometimes it is just enough to let the old versions in the old system and start afresh in the new system with the last version of the project. I think that the main reason for a project not being accepted is that they lack enough traction and aren't end-user appealing. Also, there can be a few hard core users of a system but the real measure of impact is the number of new users they got. A bad (or good) example, some years ago there was MySpace. It was the site all the garage bands want to be in. It was the place for young people. Then there comes Facebook and in just a couple years put MySpace to bite the dust. There was a way to "migrate" your info (post, messages, pics) from MySpace to Facebook? I (really) don't know, but I doubt that if they existed they could make the migration faster that it was. The people just went away to the new shiny, easier, more social and more appealing that the old crap that MySpace pages were. People sometimes doesn't care for the past. Just a good system (I am not talking about facebook anymore, I don't use it) is enough to move a lot of people from old system to new system. Cheers El lun, 02-05-2011 a las 10:00 +0200, Janko MivÅ¡ek escribiÃ³: > I think we should learn very carefully from Gemstone migration > experiences to develop our Smalltalk systems *upfront* with migration in > mind. > > Just see all recent (or less recent) examples: MC2 seems too radical to > be easily migrated from MC1 and obviously designed without migration in > mind, SqueakSource as well, SS3 too? > > Such systems just don't have any chance to be accepted and old systems > will live and live instead. So, don't develop just a "cool" stuff, take > some time to think about migration and long-term maintenance issues as > well, if you like that your system will be accepted with the community > to your glory :) > > Janko > > On 27. 04. 2011 22:16, Dale Henrichs wrote: > > Since you mention GemStone:) > > > > We have customers who have migrated repositories created 10+ years ago > > with our 32 bit product to the latest current version of our 64 bit > > product. > > > > We have changed our Smalltalk class-library over the years and customers > > have had to upgrade their own class libraries if they chose to continue > > taking advantage of our newer releases ... then there are some who have > > chosen not to migrate: I think there are still production applications > > running GemStone on a version 20 years old:) ... as long as their > > hardware holds out they are fine:) > > > > Production customers don't tend to move very fast in upgrading their > > hardware and software so we end up supporting older versions of oSes for > > quite awhile...But when the os vendor announces and end of life of an > > os, it becomes difficult for us to continue to support that version... > > > > For the older versions we backport critical bugfixes to the older > > versions as long as their are active customers (read paying maintenance > > dollars) using the older versions. > > > > Dale > > -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

May 2, 2011

Re: [Pharo-project] digitAt: issue

by Nicolas Cellier

Yes, if you want ith decimalDigit of integer n, 1 being least significant digit, then you shall write the division with a method like: decimalDigitOfRank: i "Answer the ith decimal digit, i=1 being the least significant digit" ^self // (10 raisedTo: i - 1) \\ 10 However, the awfull method you proposed might be faster if your intention is to scan all digits on very large numbers, because printString is optimized. Nicolas 2011/5/2 Bernat Romagosa <tibabenfortlapalanca(a)gmail.com>: > 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 2, 2011

Re: [Pharo-project] digitAt: issue

by StÃ©phane Ducasse

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 2, 2011

[Pharo-project] SVN vs Git for the cogvm

by Camillo Bruni

Hi eliot, I wanted to know if there is a particular reason that you use svn over git? Since it is quite a hassle each time to merge the svn history to the git repos, which I think is a bit of useless repetitive work which could be avoided. I think it would be nice if you could switch to git as well, actually there is not much difference to svn, and with some nice macros you can make behave almost the same... best regards, camillo

May 2, 2011

Re: [Pharo-project] digitAt: issue

by Bernat Romagosa

Yup, it seems to me like a horrible name too, especially considering that bitAt: already exists :) 2011/5/2 Camillo Bruni <camillo.bruni(a)inria.fr> > 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 2, 2011

Re: [Pharo-project] digitAt: issue

by Camillo Bruni

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 2, 2011

Re: [Pharo-project] stable RPackage version

by StÃ©phane Ducasse

Yes probably and after I will create 4.0 for the new experiences: getting the dirt out of it. Stef On May 2, 2011, at 12:30 PM, Tudor Girba wrote: > Hi, > > ConfigurationOfRPackage 1.0 seems to go out of sync with the image after a while. For example, download the following Moose image: > http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/… > > and try > RPackage organizer packageNamed: 'Famix-Core' > > If you load RPackage 3.0 it works. So, can we mark 3.0 as stable? > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Being happy is a matter of choice." > > > >

May 2, 2011

[Pharo-project] prog21: Impressed by Slow Code

by Sven Van Caekenberghe

He might as well talk about Smalltalk: http://prog21.dadgum.com/98.html Sven

May 2, 2011

Re: [Pharo-project] System time

by Henrik Sperre Johansen

On 02.05.2011 13:02, Andres Valloud wrote: > Ok, so each time you add the offset things become more and more > imprecise... > > http://msdn.microsoft.com/en-us/library/dd757629%28v=vs.85%29.aspx > > "The default precision of the timeGetTime function can be five > milliseconds or more, depending on the machine. You can use the > timeBeginPeriod and timeEndPeriod functions to increase the precision > of timeGetTime. If you do so, the minimum difference between > successive values returned by timeGetTime can be as large as the > minimum period value set using timeBeginPeriod and timeEndPeriod." > > Note you cannot even assume what the precision is because the function > timeBeginPeriod() changes the precision for EVERY program (plus it has > other side effects). Of course, then the docs state > > "Use the QueryPerformanceCounter and QueryPerformanceFrequency > functions to measure short time intervals at a high resolution" > > even though the relevant specs mention all sorts of problems when one > uses QueryPerformanceCounter(). This is typical MSDN, unfortunately. The way I read it, each _call_ to timeGetTime should be accurate to within 5 milliseconds. The current time is calculated baseTime + (newTimeGetTime - baseTimeGetTime) , so precisions not adding up does not explain drifts of 36 seconds... Then when timeGetTime wraps, new baseTime + baseTimeGetTime is obtained. Cheers, Henry

May 2, 2011