June 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] New Extensible Inspector for Pharo-Core

by Michael Roberts

At some point does it make sense to move the tools (OB etc) into the core so that we don't have folk working around them not being there? I don't believe such fragmentation of tools helps us long term. Thanks Mike On Tuesday, June 9, 2009, Frederic Pluquet <fpluquet(a)ulb.ac.be> wrote: > Hello Alex, > > On Tue, Jun 9, 2009 at 4:26 PM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > > > Hi Frederic, > > It looks really good. I tried to used it instead of the Explorer. > Few comments: > Â Â Â Â - Unfolding a branch that contains an element with a very very long > printOn: seems to freeze the system. > Ok, I should limit the size of the generated string (with ... at the end). > > I got an error niDescription notÂ found. > Do you have an example I can reproduce ? > > Â Â Â Â - I spend a lot of time in unfolding branches to see field content. > Maybe field values could be displayed without having to unfold ? > Good idea. I'll see what I can do. > Cheers, > FrÃ©d > > > >

June 12, 2009

Re: [Pharo-project] Duration milliSeconds: (was Animation bench)

by StÃ©phane Ducasse

so if you have version that we should integrate let us know: open a BT entry :) stef On Jun 12, 2009, at 7:18 PM, Nicolas Cellier wrote: > IMHO this is premature optimization. > Please correct milliSeconds: (see nanoSeconds:) > > milliSeconds: milliCount > "Since seconds is 0 we can call the instance directly." > > ^milliCount < 1000 > ifTrue: [ self basicNew seconds: 0 nanoSeconds: milliCount * > NanosInMillisecond ] > ifFalse: [ > | quo | > quo := milliCount quo: 1000. > ^ self basicNew > seconds: quo > nanoSeconds: (milliCount - (quo * 1000)) * NanosInMillisecond] > > Nicolas > > > 2009/6/12 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: >> I assume the // and \\ involved in converting millis to seconds were >> found too slow (see comment for similiar method nanoseconds:, which >> does >> it), therefore it's assumed milliseconds: is always called with value >> 0<value<1000. >> >> However, changing to a version that "auto-translates" to seconds: >> >> milliSeconds: milliCount >> ^ self basicNew seconds: (milliCount // 1000) nanoSeconds: >> (milliCount \\ 1000) * NanosInMillisecond >> (there was no MillisInSecond, I didn't bother adding just for this) >> >> and running some tests against old version: >> >> Time millisecondsToRun: [10000 to: 1000000 do: [:ms | dur := Duration >> milliSeconds: ms]]] 305 >> Time millisecondsToRun: [10000 to: 1000000 do: [:ms | durr := >> Duration >> milliSecondsOld: ms]] 1683 >> with float values: >> Time millisecondsToRun: [10000.0 to: 1000000.0 do: [:ms | dur := >> Duration milliSeconds: ms]]] 1944 2058 2151 >> Time millisecondsToRun: [10000.0 to: 1000000.0 do: [:ms | durr := >> Duration milliSecondsOld: ms]] 5396 5458 5171 >> >> For the small, valid, values though: >> Time millisecondsToRun: [5000 timesRepeat: [1 to: 999 do: [:ix | >> durr := >> Duration milliSeconds: ix]]] 1620 1628 1483 1747 1722 >> Time millisecondsToRun: [5000 timesRepeat: [1 to: 999 do: [:ix | >> durr := >> Duration milliSecondsOld: ix]]] 1549 1670 1525 1498 1651 >> >> So I guess it does make *some* sense, just puts rather strict >> limits on >> the input accepted. >> >> Cheers, >> Henry >> >> Henrik Johansen skrev: >>> Besides, durationToRun has a bug when durationTime is bigger than >>> 1s, >>> calling Duration milliSeconds: durationTime . >>> (Or Duration milliSeconds: has a bug, depending on your point of >>> view) >>> Ex: >>> (In Squeak) >>> Duration milliSeconds: 7666 prints as: 0:00:00:00.7666 >>> (In Pharo) >>> Duration milliSeconds: 7666 prints as: 0:00:00:07.7666 >>> >>> In both cases, A Duration with 0 seconds, and 7666000000 >>> nanoseconds is >>> created. >>> >>> Cheers, >>> Henry >>> >>> StÃ©phane Ducasse skrev: >>> >>>> on mac >>>> >>>> 0:00:00:00.409 >>>> >>>> On Jun 12, 2009, at 11:43 AM, Gary Chambers wrote: >>>> >>>> >>>> >>>>> Depends if the preference for "higher performance" is enabled >>>>> too... >>>>> >>>>> For comparison (Windows VM, updated 10304cl image): >>>>> >>>>> "higher performance" off: 0:00:00:06.6087 >>>>> "higher performance" on: 0:00:00:00.524 >>>>> >>>>> Regards, Gary >>>>> >>>>> ----- Original Message ----- >>>>> From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> >>>>> To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> >>>>> Sent: Friday, June 12, 2009 7:12 AM >>>>> Subject: [Pharo-project] Animation bench >>>>> >>>>> >>>>> Hi guys >>>>> >>>>> could you run the following: >>>>> >>>>> >>>>> >>>>>>> [ >>>>>>> (m := Morph new) openInWorld. >>>>>>> 1 to: 300 do: [:i | >>>>>>> m position: m position + (1@1). >>>>>>> World doOneCycle] >>>>>>> ] >>>>>>> durationToRun >>>>>>> >>>>>>> >>>>> because frederic.ferrere(a)free.fr did it and here are the result >>>>> >>>>> * vm : pharo-vm-0.15.1b-linux >>>>> * image : pharo0.1-10332dev09.06.2 >>>>> - Test 1 : Project est vide, juste le workspace ouvert Ã >>>>> l'opposÃ© du >>>>> trajet >>>>> RÃ©sultat 0:00:00:07.704 >>>>> - Test 2 : ClassBrowser recouvrant tout le 'World' >>>>> RÃ©sultat : 0:00:00:00.689 >>>>> >>>>> - Test 1 >>>>> * vm : squeak3.9.8-3ubuntu3 >>>>> * image : Squeak-dev 3.10.2 >>>>> - Test 1 : Project est vide, juste le workspace ouvert Ã >>>>> l'opposÃ© du >>>>> trajet >>>>> RÃ©sultat : 0:00:00:02.098 >>>>> - Test 2 : ClassBrowser recouvrant tout le 'World' >>>>> RÃ©sultat : 0:00:00:00.608 >>>>> Donc contrairement Ã ce qu'il semblait Ãªtre >>>>> logique, >>>>> le morph avance plus vite si le "World" n'est pas vide. >>>>> >>>>> StÃ©phane Rollandin a Ã©crit : >>>>> >>>>> >>>>>> [ >>>>>> (m := Morph new) openInWorld. >>>>>> 1 to: 300 do: [:i | >>>>>> m position: m position + (1@1). >>>>>> World doOneCycle] >>>>>> ] >>>>>> durationToRun >>>>>> >>>>>> retourne 0:00:00:00.373 dans mon image, soit un gros tiers de >>>>>> seconde. on est loin des 6 s >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 12, 2009

Re: [Pharo-project] Missing primitive

by Norbert Hartl

Hi, I downloaded the vm from the website again and now it works. Seems I have an older version of exupery (don't ask why). I closed the ticket that I've created. Norbert On Fri, 2009-06-12 at 12:10 -0100, Mariano Martinez Peck wrote: > This seems to be already reported but fixed in > exupery-vm-0.15.1-linux.tz :( > > Here's a VM that should have the IP6 primitives in it: > > http://ftp.squeak.org/Exupery/vms/exupery-vm-0.15.1-linux.tz > > That's the vm that you are using? which version of Pharo? > > See this thread: > http://n2.nabble.com/Undefined-symbol-using-Exupery-VM-td2581456.html#a2581… > > Cheers, > > Mariano > > > On Fri, Jun 12, 2009 at 5:42 AM, Norbert Hartl <norbert(a)hartl.name> > wrote: > Hi, > > I fixed issue 864 a few minutes ago. But that showed > another problem. SocketAddress>>hostNumber is using > a primitve > > primitiveResolverHostNameSize > > that is not there. At least not on my machine. I use > expury-0.15.1 vm. Can anybody check if this is a > problem or only on my site? > > I created an issue 882 for it > > Norbert > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 12, 2009

Re: [Pharo-project] [ANN] MouseOverHandler refactoring

by Hernan Wilkinson

I uploaded to the pharo inbox repository... is that right?The only way to test it that I found of is just to install it and play with the mouse... if you do not have a debugger, it means it is working :-) On Fri, Jun 12, 2009 at 2:47 PM, Damien Cassou <damien.cassou(a)gmail.com>wrote: > 2009/6/12 Hernan Wilkinson <hernan.wilkinson(a)gmail.com>: > > Hope you like it. > > Where can we find it? > How to test it? > > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 12, 2009

[Pharo-project] [update] #10336

by Marcus Denker

#10336 ------ Issue 880: SystemNavigation allCallsOn: from: broken Issue 823: Line breaks lost when copy from clipboard on Mac -- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile

June 12, 2009

Re: [Pharo-project] [ANN] MouseOverHandler refactoring

by Damien Cassou

2009/6/12 Hernan Wilkinson <hernan.wilkinson(a)gmail.com>: > Â Hope you like it. Where can we find it? How to test it? -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

June 12, 2009

[Pharo-project] [ANN] MouseOverHandler refactoring

by Hernan Wilkinson

Hi, I completely refactor the MouseOverHandler class. It also fixes the errors reported last week (I have it as http://code.google.com/p/pharo/issues/detail?id=86 but that is not the right error). Hope you like it. Hernan.

June 12, 2009

Re: [Pharo-project] Character enter?

by Michael Rueger

Damien Cassou wrote: > On Fri, Jun 12, 2009 at 5:08 PM, Michael Rueger<m.rueger(a)acm.org> wrote: >> which platforms actually deliver this Character (3)? >> And which key is it? > > How can we test? > If you manage to invoke a print-it with hitting the magic enter key then you got it. See ParapgraphEditor>>dispatchOnEnterWith: typeAheadStream Michael

June 12, 2009

Re: [Pharo-project] Duration milliSeconds: (was Animation bench)

by Nicolas Cellier

IMHO this is premature optimization. Please correct milliSeconds: (see nanoSeconds:) milliSeconds: milliCount "Since seconds is 0 we can call the instance directly." ^milliCount < 1000 ifTrue: [ self basicNew seconds: 0 nanoSeconds: milliCount * NanosInMillisecond ] ifFalse: [ | quo | quo := milliCount quo: 1000. ^ self basicNew seconds: quo nanoSeconds: (milliCount - (quo * 1000)) * NanosInMillisecond] Nicolas 2009/6/12 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > I assume the // and \\ involved in converting millis to seconds were > found too slow (see comment for similiar method nanoseconds:, which does > it), therefore it's assumed milliseconds: is always called with value > 0<value<1000. > > However, changing to a version that "auto-translates" to seconds: > > milliSeconds: milliCount > Â Â ^ self basicNew seconds: (milliCount // 1000) nanoSeconds: > (milliCount \\ 1000) * NanosInMillisecond > (there was no MillisInSecond, I didn't bother adding just for this) > > and running some tests against old version: > > Time millisecondsToRun: [10000 to: 1000000 do: [:ms | dur := Duration > milliSeconds: ms]]] Â 305 > Time millisecondsToRun: [10000 to: 1000000 do: [:ms | durr := Duration > milliSecondsOld: ms]] 1683 > with float values: > Time millisecondsToRun: [10000.0 to: 1000000.0 do: [:ms | dur := > Duration milliSeconds: ms]]] Â 1944 2058 2151 > Time millisecondsToRun: [10000.0 to: 1000000.0 do: [:ms | durr := > Duration milliSecondsOld: ms]] 5396 5458 5171 > > For the small, valid, values though: > Time millisecondsToRun: [5000 timesRepeat: [1 to: 999 do: [:ix | durr := > Duration milliSeconds: ix]]] 1620 1628 1483 1747 1722 > Time millisecondsToRun: [5000 timesRepeat: [1 to: 999 do: [:ix | durr := > Duration milliSecondsOld: ix]]] 1549 1670 1525 1498 1651 > > So I guess it does make *some* sense, just puts rather strict limits on > the input accepted. > > Cheers, > Henry > > Henrik Johansen skrev: >> Besides, durationToRun has a bug when durationTime is bigger than 1s, >> calling Duration milliSeconds: durationTime . >> (Or Duration milliSeconds: has a bug, depending on your point of view) >> Ex: >> (In Squeak) >> Duration milliSeconds: 7666 prints as: 0:00:00:00.7666 >> (In Pharo) >> Duration milliSeconds: 7666 prints as: 0:00:00:07.7666 >> >> In both cases, A Duration with 0 seconds, and 7666000000 nanoseconds is >> created. >> >> Cheers, >> Henry >> >> StÃ©phane Ducasse skrev: >> >>> on mac >>> >>> 0:00:00:00.409 >>> >>> On Jun 12, 2009, at 11:43 AM, Gary Chambers wrote: >>> >>> >>> >>>> Depends if the preference for "higher performance" is enabled too... >>>> >>>> For comparison (Windows VM, updated 10304cl image): >>>> >>>> "higher performance" off: Â 0:00:00:06.6087 >>>> "higher performance" on: 0:00:00:00.524 >>>> >>>> Regards, Gary >>>> >>>> ----- Original Message ----- >>>> From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> >>>> To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> >>>> Sent: Friday, June 12, 2009 7:12 AM >>>> Subject: [Pharo-project] Animation bench >>>> >>>> >>>> Hi guys >>>> >>>> could you run the following: >>>> >>>> >>>> >>>>>> [ >>>>>> Â (m := Morph new) openInWorld. >>>>>> Â 1 to: 300 do: [:i | >>>>>> Â Â m position: m position + (1@1). >>>>>> Â Â World doOneCycle] >>>>>> ] >>>>>> durationToRun >>>>>> >>>>>> >>>> because frederic.ferrere(a)free.fr did it and here are the result >>>> >>>> * vm : pharo-vm-0.15.1b-linux >>>> * image : pharo0.1-10332dev09.06.2 >>>> - Test 1 : Project est vide, juste le workspace ouvert Ã l'opposÃ© du >>>> trajet >>>> Â Â Â Â Â Â Â RÃ©sultat Â 0:00:00:07.704 >>>> - Test 2 : ClassBrowser recouvrant tout le 'World' >>>> Â Â Â Â Â Â Â RÃ©sultat : Â 0:00:00:00.689 >>>> >>>> - Test 1 >>>> * vm : squeak3.9.8-3ubuntu3 >>>> * image : Squeak-dev 3.10.2 >>>> - Test 1 : Project est vide, juste le workspace ouvert Ã l'opposÃ© du >>>> trajet >>>> Â Â Â Â Â Â Â RÃ©sultat : 0:00:00:02.098 >>>> - Test 2 : ClassBrowser recouvrant tout le 'World' >>>> Â Â Â Â Â Â Â RÃ©sultat : 0:00:00:00.608 >>>> Â Â Â Â Â Â Â Â Â Donc contrairement Ã ce qu'il semblait Ãªtre logique, >>>> le morph avance plus vite si le "World" n'est pas vide. >>>> >>>> StÃ©phane Rollandin a Ã©crit : >>>> >>>> >>>>> [ >>>>> Â (m := Morph new) openInWorld. >>>>> Â 1 to: 300 do: [:i | >>>>> Â Â m position: m position + (1@1). >>>>> Â Â World doOneCycle] >>>>> ] >>>>> durationToRun >>>>> >>>>> retourne 0:00:00:00.373 dans mon image, soit un gros tiers de >>>>> seconde. on est loin des 6 s >>>>> >>>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 12, 2009

Re: [Pharo-project] Character enter?

by Damien Cassou

On Fri, Jun 12, 2009 at 5:08 PM, Michael Rueger<m.rueger(a)acm.org> wrote: > which platforms actually deliver this Character (3)? > And which key is it? How can we test? -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

June 12, 2009