September 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Smalltalks 2010 - Declared as Important Province Event

by Tudor Girba

Ahh, I am already sorry that I will miss that, too (not just ESUG). Doru On 28 Sep 2010, at 07:25, Lukas Renggli wrote: > Very cool, I am looking forward to be there. > > Lukas > > 2010/9/28 Hernan Wilkinson <hernan.wilkinson(a)gmail.com>: >> Hi, >> we just wanted to share with you that Smalltalks 2010 (the 4th Argentinean >> Smalltalk conference) has been declare of "public interest" at the Entre >> Rios province (where the city of Concepcion del Uruguay is and where the >> conference is going to be held). >> We are very happy and proud of such recognition to Smalltalk and our >> community!! >> We hope to see you there! >> Hernan. >> PS: Attached is the statement... although, it is is Spanish :-) >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Every thing should have the right to be different."

Sept. 28, 2010

Re: [Pharo-project] Smalltalks 2010 - Declared as Important Province Event

by Lukas Renggli

Very cool, I am looking forward to be there. Lukas 2010/9/28 Hernan Wilkinson <hernan.wilkinson(a)gmail.com>: > Hi, > Â we just wanted to share with you that Smalltalks 2010 (the 4th Argentinean > Smalltalk conference) has been declare of "public interest" at the Entre > Rios province (where the city of Concepcion del Uruguay is and where the > conference is going to be held). > Â We are very happy and proud of such recognition to Smalltalk and our > community!! > Â We hope to see you there! > Hernan. > PS: Attached is the statement... although, it is is Spanish :-) > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

Sept. 28, 2010

Re: [Pharo-project] ECompletion/OCompletion tests takes A LIFE!!

by Lukas Renggli

Looks like some changes of ECompletion are then missing in OCompletion. ECompletion doesn't use Preferences for a long time anymore. Lukas On 28 September 2010 02:26, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > Â On 28.09.2010 01:43, Levente Uzonyi wrote: >> >> On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote: >> >>> On 28.09.2010 00:41, Levente Uzonyi wrote: >>>> >>>> On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote: >>>> >>>>> On 28.09.2010 00:07, Levente Uzonyi wrote: >>>>>> >>>>>> On Mon, 27 Sep 2010, Mariano Martinez Peck wrote: >>>>>> >>>>>>> 2010/9/27 Levente Uzonyi <leves(a)elte.hu> >>>>>>> >>>>>>>> On Mon, 27 Sep 2010, Mariano Martinez Peck wrote: >>>>>>>> >>>>>>>> Â IF you take a 1.1 core and just load OCompletion: >>>>>>>>> >>>>>>>>> MessageTally time: [ECContextTest new testUntypedVarsOnly] Â 20907 >>>>>>>>> >>>>>>>>> If you load OCompletion and the rest of the dev image: >>>>>>>>> >>>>>>>>> MessageTally time: [ECContextTest new testUntypedVarsOnly] 100137 >>>>>>>>> >>>>>>>>> >>>>>>>>> However, IN pharo dev 1.0 it is >>>>>>>>> >>>>>>>>> MessageTally time: [ECContextTest new testUntypedVarsOnly] Â 7405 >>>>>>>>> >>>>>>>>> >>>>>>>>> sooo.... ???? >>>>>>>>> >>>>>>>>> something has changed? >>>>>>>>> >>>>>>>> >>>>>>>> As I said, SortedCollection is not suitable for this kind of usage. >>>>>>> >>>>>>> >>>>>>> But in Pharo 1.0 OCompletion was doing the same....so? Â did >>>>>>> SortedCollection >>>>>>> chang between 1.0 and 1.1? >>>>>> >>>>>> No, something else changed. The same test is still 5x faster in 1.0 >>>>>> dev with the new code. >>>>> >>>>> TimeProfiler to the rescue: >>>>> Preferences class >> ecompletionCaseSensitive >>>>> 1.0: (1725ms) >>>>> 1.1 (19724ms) >>>>> >>>>> Preference>>settingValue which is there for backwards-compatability in >>>>> 1.1 does both symbol creation and respondsTo:, so yeah, it's much slower >>>>> than the old dictionary lookup. >>>> >>>> Nice find. If you check my code, you'll find that I optimized that away. >>>> :) >>>> >>>> >>>> Levente >>> >>> Yes ,you moved it out of the actual sort loop :) >>> Rewrite the methods in ECPreferences to use the new syntax: >>> <preference: category: description: type:>, and you shouldn't even have >>> to do that to get ok performance. >>> >>> IMHO, it's rather disturbing to see things like EC, where its preferences >>> are actually separated tucked away in an ECPreferences class, only to be >>> delegated from there over to Preferences... >> >> The preferences should be updated, but sending a message once is still >> better than 2k-30k times. >> >> >> Levente > > Sure, on the order of a couple of milliseconds difference. > I keep forgetting the fact we generally have different definitions of what > constitutes "ok performance" ;) > > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

Sept. 28, 2010

Re: [Pharo-project] [ANN] NativeBoost meets Linux

by Igor Stasenko

On 26 September 2010 21:09, Igor Stasenko <siguctua(a)gmail.com> wrote: > Hello all, > > I just uploaded a fresh snapshots of NB plugin and image code, > with necessary bits for using it under Linux. > > I don't know how to package Linux VM binaries, so you won't find a prebuilt VM > and should build it yourself (anyone wants to help me with that, so i > can add a prebuilt VM at downloads?). > > As usual, follow the installation instructions, located here: > http://code.google.com/p/nativeboost/wiki/Installation > > Warning: recently, i found a bug in callback code. > So, please don't try using smalltalk callbacks until i fix it :) > > Running tests should be safe (i disabled the test which causing VM crash). > Update: bug was fixed after two days sitting with debugger and trying to convince gdb to let me debug and find the place with problem, which finished by looking to own code once again and finding what it doing wrong. Thanks DDD+gdb developers with not letting me simply debug my stuff, but instead train my brain's analytic capabilities. :) > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

Sept. 28, 2010

[Pharo-project] Smalltalks 2010 - Declared as Important Province Event

by Hernan Wilkinson

Hi, we just wanted to share with you that Smalltalks 2010 (the 4th Argentinean Smalltalk conference) has been declare of "public interest" at the Entre Rios province (where the city of Concepcion del Uruguay is and where the conference is going to be held). We are very happy and proud of such recognition to Smalltalk and our community!! We hope to see you there! Hernan. PS: Attached is the statement... although, it is is Spanish :-) * *

Sept. 28, 2010

Re: [Pharo-project] ECompletion/OCompletion tests takes A LIFE!!

by Henrik Sperre Johansen

On 28.09.2010 01:43, Levente Uzonyi wrote: > On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote: > >> On 28.09.2010 00:41, Levente Uzonyi wrote: >>> On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote: >>> >>>> On 28.09.2010 00:07, Levente Uzonyi wrote: >>>>> On Mon, 27 Sep 2010, Mariano Martinez Peck wrote: >>>>> >>>>>> 2010/9/27 Levente Uzonyi <leves(a)elte.hu> >>>>>> >>>>>>> On Mon, 27 Sep 2010, Mariano Martinez Peck wrote: >>>>>>> >>>>>>> IF you take a 1.1 core and just load OCompletion: >>>>>>>> >>>>>>>> MessageTally time: [ECContextTest new testUntypedVarsOnly] 20907 >>>>>>>> >>>>>>>> If you load OCompletion and the rest of the dev image: >>>>>>>> >>>>>>>> MessageTally time: [ECContextTest new testUntypedVarsOnly] 100137 >>>>>>>> >>>>>>>> >>>>>>>> However, IN pharo dev 1.0 it is >>>>>>>> >>>>>>>> MessageTally time: [ECContextTest new testUntypedVarsOnly] 7405 >>>>>>>> >>>>>>>> >>>>>>>> sooo.... ???? >>>>>>>> >>>>>>>> something has changed? >>>>>>>> >>>>>>> >>>>>>> As I said, SortedCollection is not suitable for this kind of usage. >>>>>> >>>>>> >>>>>> But in Pharo 1.0 OCompletion was doing the same....so? did >>>>>> SortedCollection >>>>>> chang between 1.0 and 1.1? >>>>> >>>>> No, something else changed. The same test is still 5x faster in >>>>> 1.0 dev with the new code. >>>> TimeProfiler to the rescue: >>>> Preferences class >> ecompletionCaseSensitive >>>> 1.0: (1725ms) >>>> 1.1 (19724ms) >>>> >>>> Preference>>settingValue which is there for backwards-compatability >>>> in 1.1 does both symbol creation and respondsTo:, so yeah, it's >>>> much slower than the old dictionary lookup. >>> >>> Nice find. If you check my code, you'll find that I optimized that >>> away. :) >>> >>> >>> Levente >> Yes ,you moved it out of the actual sort loop :) >> Rewrite the methods in ECPreferences to use the new syntax: >> <preference: category: description: type:>, and you shouldn't even >> have to do that to get ok performance. >> >> IMHO, it's rather disturbing to see things like EC, where its >> preferences are actually separated tucked away in an ECPreferences >> class, only to be delegated from there over to Preferences... > > The preferences should be updated, but sending a message once is still > better than 2k-30k times. > > > Levente Sure, on the order of a couple of milliseconds difference. I keep forgetting the fact we generally have different definitions of what constitutes "ok performance" ;) Cheers, Henry

Sept. 28, 2010

Re: [Pharo-project] ECompletion/OCompletion tests takes A LIFE!!

by Levente Uzonyi

On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote: > On 28.09.2010 00:41, Levente Uzonyi wrote: >> On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote: >> >>> On 28.09.2010 00:07, Levente Uzonyi wrote: >>>> On Mon, 27 Sep 2010, Mariano Martinez Peck wrote: >>>> >>>>> 2010/9/27 Levente Uzonyi <leves(a)elte.hu> >>>>> >>>>>> On Mon, 27 Sep 2010, Mariano Martinez Peck wrote: >>>>>> >>>>>> IF you take a 1.1 core and just load OCompletion: >>>>>>> >>>>>>> MessageTally time: [ECContextTest new testUntypedVarsOnly] 20907 >>>>>>> >>>>>>> If you load OCompletion and the rest of the dev image: >>>>>>> >>>>>>> MessageTally time: [ECContextTest new testUntypedVarsOnly] 100137 >>>>>>> >>>>>>> >>>>>>> However, IN pharo dev 1.0 it is >>>>>>> >>>>>>> MessageTally time: [ECContextTest new testUntypedVarsOnly] 7405 >>>>>>> >>>>>>> >>>>>>> sooo.... ???? >>>>>>> >>>>>>> something has changed? >>>>>>> >>>>>> >>>>>> As I said, SortedCollection is not suitable for this kind of usage. >>>>> >>>>> >>>>> But in Pharo 1.0 OCompletion was doing the same....so? did >>>>> SortedCollection >>>>> chang between 1.0 and 1.1? >>>> >>>> No, something else changed. The same test is still 5x faster in 1.0 dev >>>> with the new code. >>> TimeProfiler to the rescue: >>> Preferences class >> ecompletionCaseSensitive >>> 1.0: (1725ms) >>> 1.1 (19724ms) >>> >>> Preference>>settingValue which is there for backwards-compatability in 1.1 >>> does both symbol creation and respondsTo:, so yeah, it's much slower than >>> the old dictionary lookup. >> >> Nice find. If you check my code, you'll find that I optimized that away. :) >> >> >> Levente > Yes ,you moved it out of the actual sort loop :) > Rewrite the methods in ECPreferences to use the new syntax: > <preference: category: description: type:>, and you shouldn't even have to do > that to get ok performance. > > IMHO, it's rather disturbing to see things like EC, where its preferences are > actually separated tucked away in an ECPreferences class, only to be > delegated from there over to Preferences... The preferences should be updated, but sending a message once is still better than 2k-30k times. Levente > > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 27, 2010

Re: [Pharo-project] ECompletion/OCompletion tests takes A LIFE!!

by Henrik Sperre Johansen

On 28.09.2010 00:41, Levente Uzonyi wrote: > On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote: > >> On 28.09.2010 00:07, Levente Uzonyi wrote: >>> On Mon, 27 Sep 2010, Mariano Martinez Peck wrote: >>> >>>> 2010/9/27 Levente Uzonyi <leves(a)elte.hu> >>>> >>>>> On Mon, 27 Sep 2010, Mariano Martinez Peck wrote: >>>>> >>>>> IF you take a 1.1 core and just load OCompletion: >>>>>> >>>>>> MessageTally time: [ECContextTest new testUntypedVarsOnly] 20907 >>>>>> >>>>>> If you load OCompletion and the rest of the dev image: >>>>>> >>>>>> MessageTally time: [ECContextTest new testUntypedVarsOnly] 100137 >>>>>> >>>>>> >>>>>> However, IN pharo dev 1.0 it is >>>>>> >>>>>> MessageTally time: [ECContextTest new testUntypedVarsOnly] 7405 >>>>>> >>>>>> >>>>>> sooo.... ???? >>>>>> >>>>>> something has changed? >>>>>> >>>>> >>>>> As I said, SortedCollection is not suitable for this kind of usage. >>>> >>>> >>>> But in Pharo 1.0 OCompletion was doing the same....so? did >>>> SortedCollection >>>> chang between 1.0 and 1.1? >>> >>> No, something else changed. The same test is still 5x faster in 1.0 >>> dev with the new code. >> TimeProfiler to the rescue: >> Preferences class >> ecompletionCaseSensitive >> 1.0: (1725ms) >> 1.1 (19724ms) >> >> Preference>>settingValue which is there for backwards-compatability >> in 1.1 does both symbol creation and respondsTo:, so yeah, it's much >> slower than the old dictionary lookup. > > Nice find. If you check my code, you'll find that I optimized that > away. :) > > > Levente Yes ,you moved it out of the actual sort loop :) Rewrite the methods in ECPreferences to use the new syntax: <preference: category: description: type:>, and you shouldn't even have to do that to get ok performance. IMHO, it's rather disturbing to see things like EC, where its preferences are actually separated tucked away in an ECPreferences class, only to be delegated from there over to Preferences... Cheers, Henry

Sept. 27, 2010

Re: [Pharo-project] ('a' == 'a') == true ?

by Eliot Miranda

On Mon, Sep 27, 2010 at 3:31 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 28 September 2010 00:29, Henrik Sperre Johansen > <henrik.s.johansen(a)veloxit.no> wrote: > > On 27.09.2010 23:05, Levente Uzonyi wrote: > >> > >> On Mon, 27 Sep 2010, Igor Stasenko wrote: > >> > >>> On 27 September 2010 22:10, Levente Uzonyi <leves(a)elte.hu> wrote: > >>> On Mon, 27 Sep 2010, Johan Brichau wrote: > >>> > >>>> > >>>> On 27 Sep 2010, at 14:37, Schwab,Wilhelm K wrote: > >>>> > >>>>> "Works fine" is a value judgment that can cut both ways: one could > also > >>>>> argue that VW lacks a useful optimization of literals. Non-literal > >>>>> strings > >>>>> should do what you want. > >>>> > >>>> I wonder how useful the optimization is, actually. > >>>> Probably not many (if any) methods will use the same literal multiple > >>>> times and count on the compiler to optimize them into the same > literal. > >>> > >>> I think this is from the 80's or 90's where this could save some > memory. > >>> According to my calculations in Squeak 4.2 with some extra packages > >>> loaded > >>> it saves at least 36591 bytes (object size + 1 slot in the literal > >>> array), > >>> which is only 0.79 bytes / method. > >>> > >> > >> Well, you can save a bit more, if you scan a whole image literals and > >> unify them. > >> This could be userful for tidying up the image size. > >> > >> > >> Probably yes, but that's not the point I guess. I just wanted to show > that > >> the current method doesn't really save much. Unifying the literals in > the > >> image is dangerous, because literal strings are not immutable (and they > >> shouldn't be IMHO). So that could lead to random errors if a method is > >> modifying a shared string literal. > >> > >> > >> Levente > >> > > ByteString allInstances asBag sortedCounts > > Guess who the biggest waster in Core12147 is, at nearly 60KB duplicate > > strings for three top 5 finishes? :) > > > > Starting in VW post the immutable string literals change that was done > > there, I don't really mind it. > > Personally, I feel the gains are too low to even justify it for space > > efficiency reasons though, and the immutable string literal discussion, > > which would be needed, is a big one. > > > > I vaguely remember reading something like that in CompiledMethods, access > is > > faster for literal slots 1-n, where n is a rather low number. > > Even if that would turn out to be true, I doubt it warrants the compiler > > optimizations for equivalent literal strings anymore though. > > Spacewise you've at least already debunked that it's needed :) > > > > Well, unifying for space is one thing. > Another is search for a literal in image. It could be much quicker if > all literals are unified. > Arguably, but much of the time would go in the search of methods for literals rather than the faster comparisons between literals. However, the notion that this would save space is suspect. To implement literal pooling you either slow-down compilation *a lot* by searching for literals amongst all methods (an implicit pool) or you maintain an explicit pool and likely end up _not saving any space_ since the space occupied by the pool is more-or-less equal to to the space saved by pooling since you'll likely find literals are shared approximately once. We've been-there-done-that with VisualWorks trying to pool the bytecodes in methods and abandoned the idea because there was no net space saving. So you need to quantify the degree of sharing you see in a typical dev image and see whether average sharing is significantly greater than 1. Its not an invitation to do it, just to consider options which opening > for us, if we do that :) > > > Cheers, > > Henry > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 27, 2010

Re: [Pharo-project] ECompletion/OCompletion tests takes A LIFE!!

by Levente Uzonyi

On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote: > On 28.09.2010 00:07, Levente Uzonyi wrote: >> On Mon, 27 Sep 2010, Mariano Martinez Peck wrote: >> >>> 2010/9/27 Levente Uzonyi <leves(a)elte.hu> >>> >>>> On Mon, 27 Sep 2010, Mariano Martinez Peck wrote: >>>> >>>> IF you take a 1.1 core and just load OCompletion: >>>>> >>>>> MessageTally time: [ECContextTest new testUntypedVarsOnly] 20907 >>>>> >>>>> If you load OCompletion and the rest of the dev image: >>>>> >>>>> MessageTally time: [ECContextTest new testUntypedVarsOnly] 100137 >>>>> >>>>> >>>>> However, IN pharo dev 1.0 it is >>>>> >>>>> MessageTally time: [ECContextTest new testUntypedVarsOnly] 7405 >>>>> >>>>> >>>>> sooo.... ???? >>>>> >>>>> something has changed? >>>>> >>>> >>>> As I said, SortedCollection is not suitable for this kind of usage. >>> >>> >>> But in Pharo 1.0 OCompletion was doing the same....so? did >>> SortedCollection >>> chang between 1.0 and 1.1? >> >> No, something else changed. The same test is still 5x faster in 1.0 dev >> with the new code. > TimeProfiler to the rescue: > Preferences class >> ecompletionCaseSensitive > 1.0: (1725ms) > 1.1 (19724ms) > > Preference>>settingValue which is there for backwards-compatability in 1.1 > does both symbol creation and respondsTo:, so yeah, it's much slower than the > old dictionary lookup. Nice find. If you check my code, you'll find that I optimized that away. :) Levente > > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 27, 2010