- Pharo-dev - lists.pharo.org

[Pharo-project] PharoCore 1.3 built stalled

by laurent laffont

Last built started more than 1 day ago and not finished .... Laurent.

May 2, 2011

Re: [Pharo-project] [COTDC] 57 - ColorMap

by Fernando Olivero

I'm a transformation of pixel values. I apply up to four masks and shits to compute the transformed pixel value. I'm used when applying a BitBlt transfer, whenever pixels from a source to a destination have diferent depths. For further information refer to BitBlt class comments. To see me in action evaluate: BitBlt exampleColorMap Fernando On Mon, May 2, 2011 at 8:52 PM, laurent laffont <laurent.laffont(a)gmail.com> wrote: > Today: Â ColorMap > > Comment Of The Day Contest - One Day One Comment > Rules: > #1: Each day a not commented class is elected. Each day the best comment > will be integrated with name of the author(s). > #2: If you cannot comment it, deprecate it. > Results:Â http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > Laurent

May 2, 2011

Re: [Pharo-project] System time

by Andres Valloud

> The way I read it, each _call_ to timeGetTime should be accurate to > within 5 milliseconds. The docs say 5ms or more, depending on the machine, and there is no indication of what affects the precision on the machine. But even if that's irrelevant, your argument assumes nobody else in the machine called timerBeginPeriod with an argument of, say, 100. Basically, relying on timeGetTime is bound to cause problems because it forces you to assume (guess) what every other program is doing, which opens the door to wrong assumptions and weird, hard to reproduce behavior. > The current time is calculated > baseTime + (newTimeGetTime - baseTimeGetTime) , so precisions not adding > up does not explain drifts of 36 seconds... How many times is timeGetTime() called during the accumulated drift? Andres.

May 2, 2011

[Pharo-project] [COTDC] 57 - ColorMap

by laurent laffont

Today: ColorMap Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest Laurent

May 2, 2011

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

by Mariano Martinez Peck

On Mon, May 2, 2011 at 7:54 PM, Camillo Bruni <camillo.bruni(a)inria.fr>wrote: > > On 2011-05-02, at 17:59, Eliot Miranda wrote: > > > Hi Camillo, > > > > On May 2, 2011, at 8:22 AM, Camillo Bruni <camillo.bruni(a)inria.fr> > wrote: > > > >> Hi eliot, > >> > >> I wanted to know if there is a particular reason that you use svn over > git? > > History. > > > >> 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... > > > > It's a hastle for me to change. > sure, but all of us changed as well, which is at least 10 to 1 ;). > > > Surely you can set-up some script that pings the Cog branch every ten > minutes and does the replication to got automatically. > > Please, DON'T do that to the blessed. The most important thing from gitorious is how to sync platforms code and VMMaker. Every commit in the blessed comes with an associated (if required) new version in ConfigurationOfCog, and hence, the update of the file blesses/codegen-scripts/LoadVMMaker.st That is the ONLY way to have in sync both parts and to be able to "always" build a VM. So...ok, we can have a cron automatically pick up the branch from SVN and push it in gitorious, but please, not to blessed. > Well merging does not work fully automated, so there is some human > interaction involved. > And SVN is not really about collaboration, which is not so nice. > > > I don't want to change all my process just yet. > > so when do you intend to change your process yet? > You should get the basics in 5mins, most of the rest can be solved with > compatibility configurations (which I will provide ;) free of charge), and > the rest just works more stable than svn. > > So would be a cool step towards a more community based VM IMO. > > -(~_~)- > camillo > > > -- Mariano http://marianopeck.wordpress.com

May 2, 2011

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

by Camillo Bruni

On 2011-05-02, at 17:59, Eliot Miranda wrote: > Hi Camillo, > > On May 2, 2011, at 8:22 AM, Camillo Bruni <camillo.bruni(a)inria.fr> wrote: > >> Hi eliot, >> >> I wanted to know if there is a particular reason that you use svn over git? > History. > >> 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... > > It's a hastle for me to change. sure, but all of us changed as well, which is at least 10 to 1 ;). > Surely you can set-up some script that pings the Cog branch every ten minutes and does the replication to got automatically. Well merging does not work fully automated, so there is some human interaction involved. And SVN is not really about collaboration, which is not so nice. > I don't want to change all my process just yet. so when do you intend to change your process yet? You should get the basics in 5mins, most of the rest can be solved with compatibility configurations (which I will provide ;) free of charge), and the rest just works more stable than svn. So would be a cool step towards a more community based VM IMO. -(~_~)- camillo

May 2, 2011

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

by Camillo Bruni

On 2011-05-02, at 17:59, Eliot Miranda wrote: > Hi Camillo, > > On May 2, 2011, at 8:22 AM, Camillo Bruni <camillo.bruni(a)inria.fr> wrote: > >> Hi eliot, >> >> I wanted to know if there is a particular reason that you use svn over git? > History. > >> 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... > > It's a hastle for me to change. sure, but all of us changed as well, which is at least 10 to 1 ;). > Surely you can set-up some script that pings the Cog branch every ten minutes and does the replication to got automatically. Well merging does not work fully automated, so there is some human interaction involved. And SVN is not really about collaboration, which is not so nice. > I don't want to change all my process just yet. so when do you intend to change your process yet? You should get the basics in 5mins, most of the rest can be solved with compatibility configurations (which I will provide ;) free of charge), and the rest just works more stable than svn. So would be a cool step towards a more community based VM IMO. -(~_~)- camillo

May 2, 2011

Re: [Pharo-project] digitAt: issue

by Nicolas Cellier

You are perfectly right, digitus means finger in latin, so it generally carries the notion of 10-base. I guess #byteAt: was not selected because it was considered as an implementation detail. The implementation might as well switch to 16 or 32 bits "digits", and you could still use generic code like 1 to: self digitLength do: [:i | (self digitAt: i) doSomething ] As long as you don't put any expectation on #digitAt: bit length... Since plenty of optimization depending on #digitAt: returning a byte have been added to the system - some by me :( - we shall better use byteAt:, but it's hard to control how a living system evolves... Nicolas 2011/5/2 Bernat Romagosa <tibabenfortlapalanca(a)gmail.com>: > As intended, yes. But not as expected from what digit usually means (any of > the arabic figures of 1 through 9 and 0. [3]). > I guess that'd change the behavior of too many things, but IMHO byteAt: > would suit much better what this method does. > > 2011/5/2 Eliot Miranda <eliot.miranda(a)gmail.com> >> >> digitAt: answers a byte in an integer and so is working as intended. >> >> Eliot (phone) >> On May 2, 2011, at 2:13 AM, Bernat Romagosa >> <tibabenfortlapalanca(a)gmail.com> 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. >

May 2, 2011

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

by StÃ©phane Ducasse

Hi guys I do not know how many of you are coding in 1.3 but when the system asks me to add if I want to add a temp, the temp does not show up. Stef

May 2, 2011

[Pharo-project] monthly skype chat?

by StÃ©phane Ducasse

Hi guys may be the irc did not work well. I still think that there is a value in communication and understanding our objectives. So may be a skype discussion would be great or if you have any other ideas to communicate let me know. Stef

May 2, 2011