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

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

by Henrik Sperre Johansen

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. Cheers, Henry

Sept. 27, 2010

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

by Igor Stasenko

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. 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.

Sept. 27, 2010

Re: [Pharo-project] About installing NativeBoost in Linux

by Igor Stasenko

On 28 September 2010 01:05, Fernando olivero <fernando.olivero(a)usi.ch> wrote: > > On Sep 27, 2010, at 10:20 PM, Igor Stasenko wrote: > >> On 27 September 2010 17:36, Fernando olivero <fernando.olivero(a)usi.ch> wrote: >>> Hi Igor, great news that NativeBoost is available in Linux. >>> >>> In the installation page, in steps 1 and 2 you specify how to create a plugin/vm . >>> The outcome is the vm for linux with NativeBoost support? >>> >> >> Its not a full instruction how to build a vm. >> First, you must download the sources and have an image with vmmaker. >> This is described on http://squeakvm.org/unix/devel.html page. >> >> Then you need to download small patch from NB site >> svn checkout http://nativeboost.googlecode.com/svn/trunk/ nativeboost-read-only >> >> and copy patched files to unix platform-specific sources. >> >> In image with VMMaker, you can load NBInstaller , and then do >> NBInstaller installPlugin. >> >> Before generating VM/plugins source code in vmmaker, don't forget >> about setting target platform for plugin: >> >> NativeBoostPlugin setTargetPlatform: (NativeBoostConstants linux32PlatformId). >> >> >> Now open VMMaker, include NativeBoostPlugin into internal plugins list, >> and you ready to build a VM. >> > > Thanks for the detailed info Igor. > > Â I think the web page would benefit from adding this extra info. > Ok, i will add this. >> Yes, building VM is somewhat tedious procedure, but once you have >> everything set up, >> it don't takes much time anymore. >> > > ok, maybe what we could have is an ready made image for each OS. ( with the above steps already performed) > so people just press the "generate" button. > I can provide an image with VMMaker + NB plugin, if you want. I running linux in virtual box, and had a problems with OpenGL, so i had to disable it & exclude everything which using it (B3DAcceleratorPlugin) from build, as well as some other plugins, which for one or another reason didn't worked for me. So, it could be not the same VM you wanna use on your box. :) >> >>> Is there a prebuilt vm for linux available? >>> >> Yes, on my PC :) but i don't know how to package it. >> >>> Fernando >>> >>> >>> pd: When would it be available for Mac OSX? How can we help? >>> >> Well, since i don't have Mac right now, i can't build & test VM and plugin. >> >> I just added a necessary patch to platforms/Mac OS/sqMacMemory.c >> in plugin's svn source at google code, >> which is needed to make plugin execute native code. >> >> (Make sure that you building plugin with Mac platform id). >> >> The rest of stuff should be done at image level: >> - create a subclass of NativeBoost, like NativeBoostMac32 >> and implement missing functionality. >> You can use NativeBoostLinux32 as a guide to follow. >> >> I think that for someone, who knows mac platforms well, it could take >> maybe a day to >> make a working port. >> > > Ok, i'll do that ( in the not so distant future). > Just try to build a VM with plugin. And once it can run a native code, the rest is a piece of cake :) I can give you detailed explanation, what you should implement/override to complete NB bootstrap on Mac, once you will be ready. > Fernando > >>> >>> >>> _______________________________________________ >>> 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 > > > _______________________________________________ > 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.

Sept. 27, 2010

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

by Levente Uzonyi

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. > > >> If you have n classes in the system, the method takes O(n^2) time. I have >> already fixed this, though it's not available yet. >> > > let us know when this is available. A preview version is available here: http://leves.web.elte.hu/squeak/Ocompletion-ul.77.mcz It should work in Pharo 1.1, though it has some additional Squeak specific code which is unnecessary for Pharo. Levente > > >> >> Using the Pharo 1.1 OneClick image I get these values for >> [ECContextTest new testUntypedVarsOnly] timeToRun : >> Old: 28227 >> New: 1241 >> >> >> Levente >> >> >> >>> cheers >>> >>> Mariano >>> >>> >>> On Mon, Sep 27, 2010 at 9:30 PM, Lukas Renggli <renggli(a)gmail.com> wrote: >>> >>> In a plain ECompletion image the code >>>> >>>> [ Smalltalk environment keysDo: >>>>> [ :each | >>>>> selectors add: (ECGlobalEntry >>>>> contents: each >>>>> type: #globalVar) ]. >>>>> >>>> >>>> takes around 30 milliseconds to evaluate. >>>> >>>> Lukas >>>> >>>> On 27 September 2010 16:23, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>>> wrote: >>>> >>>>> mariano can you open a bug entry. >>>>> >>>>> Stef >>>>> On Sep 26, 2010, at 6:21 PM, Mariano Martinez Peck wrote: >>>>> >>>>> Hi. I am loading OCompletion in PharoCore 1.1 while building the Dev >>>>>> >>>>> image. If I just take a core image, load OCompletion and run tests, they >>>> take a lot of time, not acceptable. >>>> >>>>> >>>>>> Now....if I build a Dev image (with OB, RB, etc) and at the end I try >>>>>> to >>>>>> >>>>> run OCompletion tests, the tests takes HOURS. The image seems frozen, >>>> but >>>> actually is working. If I interrupt I see the problem is in >>>> >>>>> >>>>>> ECUntypedModel >> initializeSelectors >>>>>> >>>>>> the part of >>>>>> >>>>>> >>>>>> [ Smalltalk environment keysDo: >>>>>> [ :each | >>>>>> selectors add: (ECGlobalEntry >>>>>> contents: each >>>>>> type: #globalVar) ]. >>>>>> >>>>>> >>>>>> takes a lot of time >>>>>> >>>>>> and it seems related to "ECPreferences caseSensitive" and >>>>>> >>>>> "ECUntypedModel >> resetSelectors" >>>> >>>>> >>>>>> I don't know what else to say. To reproduce, take a PharoCore 1.1 and >>>>>> >>>>> evaluate: >>>> >>>>> >>>>>> Gofer new >>>>>> squeaksource: 'MetacelloRepository'; >>>>>> package: 'ConfigurationOfOCompletion'; >>>>>> load. >>>>>> >>>>>> (ConfigurationOfOCompletion project version: '1.2') load: 'Core Tests' >>>>>> >>>>>> Then, run all the tests inside OCompletionTests. You will see that >>>>>> after >>>>>> >>>>> running some threads....it will look like frozen. There, do an interrupt >>>> and >>>> analize. >>>> >>>>> >>>>>> IF you do that for a Dev image, it takes muuuuch more. I guess this is >>>>>> >>>>> because "Smalltalk environment keys" will have muuuuuch more elements >>>> than a >>>> simple core. >>>> >>>>> >>>>>> Anyway, help is appreciated. >>>>>> >>>>>> Cheers >>>>>> >>>>>> Mariano >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>>> >>>> >>>> >>>> -- >>>> 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 >>>> >>>> >> _______________________________________________ >> 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] About installing NativeBoost in Linux

by Fernando olivero

On Sep 27, 2010, at 10:20 PM, Igor Stasenko wrote: > On 27 September 2010 17:36, Fernando olivero <fernando.olivero(a)usi.ch> wrote: >> Hi Igor, great news that NativeBoost is available in Linux. >> >> In the installation page, in steps 1 and 2 you specify how to create a plugin/vm . >> The outcome is the vm for linux with NativeBoost support? >> > > Its not a full instruction how to build a vm. > First, you must download the sources and have an image with vmmaker. > This is described on http://squeakvm.org/unix/devel.html page. > > Then you need to download small patch from NB site > svn checkout http://nativeboost.googlecode.com/svn/trunk/ nativeboost-read-only > > and copy patched files to unix platform-specific sources. > > In image with VMMaker, you can load NBInstaller , and then do > NBInstaller installPlugin. > > Before generating VM/plugins source code in vmmaker, don't forget > about setting target platform for plugin: > > NativeBoostPlugin setTargetPlatform: (NativeBoostConstants linux32PlatformId). > > > Now open VMMaker, include NativeBoostPlugin into internal plugins list, > and you ready to build a VM. > Thanks for the detailed info Igor. I think the web page would benefit from adding this extra info. > Yes, building VM is somewhat tedious procedure, but once you have > everything set up, > it don't takes much time anymore. > ok, maybe what we could have is an ready made image for each OS. ( with the above steps already performed) so people just press the "generate" button. > >> Is there a prebuilt vm for linux available? >> > Yes, on my PC :) but i don't know how to package it. > >> Fernando >> >> >> pd: When would it be available for Mac OSX? How can we help? >> > Well, since i don't have Mac right now, i can't build & test VM and plugin. > > I just added a necessary patch to platforms/Mac OS/sqMacMemory.c > in plugin's svn source at google code, > which is needed to make plugin execute native code. > > (Make sure that you building plugin with Mac platform id). > > The rest of stuff should be done at image level: > - create a subclass of NativeBoost, like NativeBoostMac32 > and implement missing functionality. > You can use NativeBoostLinux32 as a guide to follow. > > I think that for someone, who knows mac platforms well, it could take > maybe a day to > make a working port. > Ok, i'll do that ( in the not so distant future). Fernando >> >> >> _______________________________________________ >> 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] Alien Plugin for Linux

by Fernando olivero

Great! thanks eliot. Good enough for the project we want to do , ( that's reifying the MatLab library in Smalltalk) Fernando On Sep 27, 2010, at 8:12 PM, Eliot Miranda wrote: > > > 2010/9/27 Fernando olivero <fernando.olivero(a)usi.ch> > Does the prebuilt CogVM for linux include Alien support? > http://www.mirandabanda.org/files/Cog/VM/VM.r2313/ > > Only of the data manipulation and callout parts, not the callback parts. I'm trying to find time to work on integrating the Alien callback machinery with the FFI. > > best > Eliot > > > > On Sep 27, 2010, at 4:41 PM, Schwab,Wilhelm K wrote: > >> I share your interest. Just to fan the fires of healthy competition, Sig has posted code for a NativeBoost plugin on Linux. Stef will understand that I don't dare look at it until my grant proposal is submitted, but it is a step in the right direction. >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Fernando olivero [fernando.olivero(a)usi.ch] >> Sent: Monday, September 27, 2010 10:32 AM >> To: Pharo-project(a)lists.gforge.inria.fr Development >> Subject: [Pharo-project] Alien Plugin for Linux >> >> Hi, is there an Alien plugin for linux ? >> I recall somebody working on it. >> Would be nice if its made available somewhere on the web. >> >> Thanks, >> Fernando >> >> _______________________________________________ >> 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 > > <ATT00001..txt>

Sept. 27, 2010

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

by Henrik Sperre Johansen

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 :) Cheers, Henry

Sept. 27, 2010

Re: [Pharo-project] After loading a package...all changes with "revision changed"

by Javier PimÃ¡s

I reviewed the code we had. It wasn't a problem of initialize actually, it had to do with automatic code generation. Monticello calls initialize method for the classes it loads, which we didn't know, and we had made initialize to touch and recompile some methods. The thing is that maybe some code you have is subreptitiously recompiling the methods automatically once and again without your knowledge, and thus monticello takes note. 2010/9/27 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > 2010/9/26 Javier PimÃ¡s <elpochodelagente(a)gmail.com> > > We had a similar problem in squeaknos package, but just for some kind of >> classes. It was caused by having an initialize class method in classes >> derived from ExternalStructure, maybe it's because of the same reason? look >> there, you may get some answers. >> >> > Thanks. It is good to know I am not the only one. This bug is REAAAAALY > annoying since you cannot see your changes. > > I've checked and I have no #initialize at class level :( > > The only thing I found is class side #new implementd something like: > > new > > ^super new initialize. > > can this be the problem? > > where could I put a halt to see the problem ? > > thanks in advance > > mariano > > > >> regards, >> javier. >> >> 2010/9/26 Norbert Hartl <norbert(a)hartl.name> >> >> FYI I encountered the same problem in gemstone. The only thing I know is >>> that all loaded packages were created in pharo that showed this behaviour. >>> It didn't show up in a reproducable manner and some packages were clean >>> again after a few package updates. And for some month now I didn't see it. >>> >>> Norbert >>> >>> >>> Am 25.09.2010 um 21:12 schrieb Mariano Martinez Peck < >>> marianopeck(a)gmail.com>: >>> >>> >>> >>> On Sat, Sep 25, 2010 at 9:02 PM, StÃ©phane Ducasse <<stephane.ducasse(a)inria.fr> >>> stephane.ducasse(a)inria.fr> wrote: >>> >>>> >>>> On Sep 25, 2010, at 8:25 PM, Mariano Martinez Peck wrote: >>>> >>>> > Hi. I am having a probem with Glorp and I really have no idea what can >>>> be. The problem is that I load the package Glorp and just after loading, I >>>> do a "changes" in the MC Browser and I see a lot of classes with a lot of >>>> changes and all of them like "revison changed". This is annoying since it >>>> doesn't let me easily see what I have really changed. >>>> > >>>> > To reproduce: >>>> > >>>> > - Load the package "Glorp" from >>>> <http://www.squeaksource.com/SqueakDBX> >>>> http://www.squeaksource.com/SqueakDBX >>>> > - Open a MC Browser, select Glorp package and press the "Changes" >>>> button agains the ss repo. And you will see :) >>>> >>>> May be the image used to save the package got a problem and changed the >>>> timestamp of the methods. >>>> So when you merge you get changed methods. >>>> >>> >>> I've just tried commiting and load them in a clean image...same problem. >>> >>> And if it were what you say...is there a solution? >>> >>> thanks >>> >>> mariano >>> >>> >>>> >>>> > >>>> > Any help is really appreaciated. >>>> > >>>> > Thanks >>>> > >>>> > Mariano >>>> > _______________________________________________ >>>> > Pharo-project mailing list >>>> > <Pharo-project(a)lists.gforge.inria.fr> >>>> Pharo-project(a)lists.gforge.inria.fr >>>> > <http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project> >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> <Pharo-project(a)lists.gforge.inria.fr> >>>> Pharo-project(a)lists.gforge.inria.fr >>>> <http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project> >>>> 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 >>> >> >> >> >> -- >> Javier PimÃ¡s >> Ciudad de Buenos Aires >> >> _______________________________________________ >> 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 > -- Javier PimÃ¡s Ciudad de Buenos Aires

Sept. 27, 2010

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

by Mariano Martinez Peck

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? > If you have n classes in the system, the method takes O(n^2) time. I have > already fixed this, though it's not available yet. > let us know when this is available. > > Using the Pharo 1.1 OneClick image I get these values for > [ECContextTest new testUntypedVarsOnly] timeToRun : > Old: 28227 > New: 1241 > > > Levente > > > >> cheers >> >> Mariano >> >> >> On Mon, Sep 27, 2010 at 9:30 PM, Lukas Renggli <renggli(a)gmail.com> wrote: >> >> In a plain ECompletion image the code >>> >>> [ Smalltalk environment keysDo: >>>> [ :each | >>>> selectors add: (ECGlobalEntry >>>> contents: each >>>> type: #globalVar) ]. >>>> >>> >>> takes around 30 milliseconds to evaluate. >>> >>> Lukas >>> >>> On 27 September 2010 16:23, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>> wrote: >>> >>>> mariano can you open a bug entry. >>>> >>>> Stef >>>> On Sep 26, 2010, at 6:21 PM, Mariano Martinez Peck wrote: >>>> >>>> Hi. I am loading OCompletion in PharoCore 1.1 while building the Dev >>>>> >>>> image. If I just take a core image, load OCompletion and run tests, they >>> take a lot of time, not acceptable. >>> >>>> >>>>> Now....if I build a Dev image (with OB, RB, etc) and at the end I try >>>>> to >>>>> >>>> run OCompletion tests, the tests takes HOURS. The image seems frozen, >>> but >>> actually is working. If I interrupt I see the problem is in >>> >>>> >>>>> ECUntypedModel >> initializeSelectors >>>>> >>>>> the part of >>>>> >>>>> >>>>> [ Smalltalk environment keysDo: >>>>> [ :each | >>>>> selectors add: (ECGlobalEntry >>>>> contents: each >>>>> type: #globalVar) ]. >>>>> >>>>> >>>>> takes a lot of time >>>>> >>>>> and it seems related to "ECPreferences caseSensitive" and >>>>> >>>> "ECUntypedModel >> resetSelectors" >>> >>>> >>>>> I don't know what else to say. To reproduce, take a PharoCore 1.1 and >>>>> >>>> evaluate: >>> >>>> >>>>> Gofer new >>>>> squeaksource: 'MetacelloRepository'; >>>>> package: 'ConfigurationOfOCompletion'; >>>>> load. >>>>> >>>>> (ConfigurationOfOCompletion project version: '1.2') load: 'Core Tests' >>>>> >>>>> Then, run all the tests inside OCompletionTests. You will see that >>>>> after >>>>> >>>> running some threads....it will look like frozen. There, do an interrupt >>> and >>> analize. >>> >>>> >>>>> IF you do that for a Dev image, it takes muuuuch more. I guess this is >>>>> >>>> because "Smalltalk environment keys" will have muuuuuch more elements >>> than a >>> simple core. >>> >>>> >>>>> Anyway, help is appreciated. >>>>> >>>>> Cheers >>>>> >>>>> Mariano >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>> >>> >>> -- >>> 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 >>> >>> > _______________________________________________ > 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] ('a' == 'a') == true ?

by Levente Uzonyi

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 > > Levente > >> >> Inversely, I have never run into that issue myself either, until I was >> just testing those little snippets for the students. Or... at least, I think >> I never have :-) >> >> Johan >> _______________________________________________ >> 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 > -- 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