- Pharo-dev - lists.pharo.org

[Pharo-project] New inspector: pain when inspecting large collections

by Igor Stasenko

Try this: SystemOrganization inspect -- Best regards, Igor Stasenko AKA sig.

Oct. 26, 2009

[Pharo-project] Test what primitive is faster #clone, of #basicNew?

by Igor Stasenko

Hello, creating a new objects is quite fast, but i wonder, what if it could be made even faster for objects of fixed size (not variable sized ones) by using a #clone primitive instead of #basicNew? The trick to use #clone is, that we can keep a 'sample' in class instance variable: Mytestclass class instanceVariableNames: 'sample' Mytestclass class>>initialize sample := self basicNew and then: Mytestclass class>>new ^ sample clone initialize The problem, that i can't make a benchmark , which could really tell the difference between those two ways, so we could be 100% sure what is faster. Any ideas how to bench it? -- Best regards, Igor Stasenko AKA sig.

Oct. 26, 2009

Re: [Pharo-project] (a = b) => (a hash = b hash)

by Andrew P. Black

I agree with Nicolas, but I think that it's really important that we have this discussion, reach a consensus, and them implement it! That's why I posted the message here rather than just posting a bug report. There used to be a method called hasSameElementsAs: (now called, inexplicably, sameElements:) that could be pressed into service so that two intervals, or an array and and interval, can have the same elements but still be unequal. But the role of species was to define when things could be equal... Maybe we need a method "hasSameSequenceOfElementsAs:" which would be applicable to any pair of sequenceable collections, as well as being faster to implement, than sameElements: (which is currently quadratic). On 25 Oct 2009, at 06:53, Nicolas Cellier wrote: > > IMO, we should not let Array hash ~= Interval hash coexist with > Array = Interval > Because it's like putting some traps on programmers path. > One day or the other an application will exhibit a non repeatable > error, just because the size of a Set was different and caused a > collision.

Oct. 26, 2009

Re: [Pharo-project] ClassOrganizer oddities

by Igor Stasenko

On top of that, i found annoying, that ClassOrganizer sends notifications using SystemNotification. While , IMO best place and only place where notifications should be sent from - is a class. A simple consistency check: | uncategorized | uncategorized := IdentityDictionary new. ClassDescription allSubInstances do: [:behavior | | invalidSels | invalidSels := behavior methodDict keys select: [:selector | (behavior organization categoryOfElement: selector) isNil ]. invalidSels ifNotEmpty: [ uncategorized at: behavior put: invalidSels] ]. uncategorized shows that , there is no uncategorized selectors for all classes in system, i.e. things like: Object organization categoryOfElement: #jjj => nil Then i did a little experiment: added the #blabla method to Object class, and then did Object organization removeElement: #blabla and now the consistency check above shows me that method is still in class, while not present in categorizer. A browser behaves interestingly in this case: - it lists this method only if you selecting '-- all --' metacategory. -- Best regards, Igor Stasenko AKA sig.

Oct. 26, 2009

Re: [Pharo-project] question about results of MessageTally

by Henrik Sperre Johansen

Personally, I always change to 0.1 in spyOn: (my experience in VW was that doing 0.0 makes the tree building take a long time). You'd probably also want to try out TimeProfileBrowser onBlock: instead of MessageTally spyOn:, while not a huge improvement, it's nice to have the method source accessible directly. I had a dream of making a new one, with a proper treeview of the tally (and a button for auto-expand to certain %, no need to worry if you'd set the cutoff correctly before starting the tally), color-coding of the hotspots in the method view, and store/compare of tallies, but never seem to get around to it. Well, I did start once, but my head started hurting too soon from the total lack of separation between result production/storage/presentation responsibilities in MT. Cheers, Henry On 25.10.2009 21:00, Laval Jannik wrote: > yes, with 0 it works. > > But, in some cases, we would like to have all branches. > So, I will do the method spyOn:cutoff:, and keep the 1% threshold for > spyOn:. > > Cheers, > Jannik > > > On Oct 25, 2009, at 20:54 , Adrian Lienhard wrote: > > >> Have you tried with 0? I guess you get way too much in the tree >> (especially when you trace a larger part of your application and not >> only adding elements to a dictionary). It seems that 1% is a sensible >> default as usually it does not make sense to look into these branches >> more closely as you cannot optimize them much. >> >> Adrian >> >> On Oct 25, 2009, at 19:42 , Laval Jannik wrote: >> >> >>> Hi Adrian, >>> >>> Now I understand the "problem". >>> So we can use "report:cutoff:" which allows us to give a specific >>> value for the threshold. >>> >>> I will create a new method, spyOn:cutoff:. >>> >>> I think the method "spyOn:" must have the threshold equals to 0. >>> No ? >>> >>> Cheers, >>> Jannik >>> >>> >>> On Oct 24, 2009, at 12:08 , Adrian Lienhard wrote: >>> >>> >>>> Hi Jannik, >>>> >>>> Interesting question! >>>> >>>> You left out an important part oft the tally: the part about GC >>>> activity. >>>> >>>> For the large dictionary I get: >>>> >>>> **GCs** >>>> full 9 totalling 1,696ms (1.0% uptime), avg 188.0ms >>>> incr 3776 totalling 186,310ms (94.0% uptime), avg 49.0ms >>>> >>>> That is, 95% of time is spent in GC! A lot of incremental GC cycles >>>> are triggered because for each at:put: a new association instance is >>>> created. The larger the dictionary, the larger is the new memory >>>> space >>>> and hence the incremental GC takes longer to complete. In the above >>>> tally the average was 49ms compared to >>>> >>>> incr 275 totalling 1,113ms (58.0% uptime), avg 4.0ms >>>> >>>> for the smaller dictionary. Therefore, the ratio between actual >>>> method >>>> execution time and GC time differs significantly between the two >>>> runs. >>>> As a result, a lot of branches of the tally are below a total of 1% >>>> runtime in the second case. Message tally has a threshold that cuts >>>> off branches with less than 1% runtime. Therefore you see less >>>> details. >>>> >>>> Cheers, >>>> Adrian >>>> >>>> >>>> On Oct 24, 2009, at 07:21 , Laval Jannik wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> when I use MassageTally>>spyOn: on the creation of a Dictionary, >>>>> results have not the same details according to the size of >>>>> Dictionary. >>>>> >>>>> For example: >>>>> === >>>>> |n| >>>>> MessageTally spyOn:[ >>>>> n := Dictionary new. >>>>> 1 to: 400000 do:[:each | n at: each put:each]. >>>>> ] >>>>> === >>>>> >>>>> returns this results: >>>>> >>>>> ==== >>>>> - 1745 tallies, 1751 msec. >>>>> >>>>> **Tree** >>>>> -------------------------------- >>>>> Process: (40s) 1964: nil >>>>> -------------------------------- >>>>> 45.8% {802ms} Dictionary(Set)>>atNewIndex:put: >>>>> |43.6% {763ms} Dictionary(Set)>>fullCheck >>>>> | |39.4% {690ms} Dictionary(Set)>>grow >>>>> | | |27.2% {476ms} Dictionary>>noCheckAdd: >>>>> | | | |25.2% {441ms} Dictionary(Set)>>findElementOrNil: >>>>> | | | | |23.6% {413ms} Dictionary>>scanFor: >>>>> | | | | |1.6% {28ms} primitives >>>>> | | | |2.0% {35ms} primitives >>>>> | | |9.2% {161ms} primitives >>>>> | | |3.0% {53ms} Array(SequenceableCollection)>>do: >>>>> | |2.4% {42ms} primitives >>>>> | |1.8% {32ms} SmallInteger(Magnitude)>>max: >>>>> |2.2% {39ms} primitives >>>>> 22.4% {392ms} Association class>>key:value: >>>>> |18.9% {331ms} Association class(LookupKey class)>>key: >>>>> | |16.3% {285ms} Association(LookupKey)>>key: >>>>> | |2.6% {46ms} primitives >>>>> |1.9% {33ms} Association>>value: >>>>> |1.6% {28ms} primitives >>>>> 4.4% {77ms} Dictionary(Set)>>findElementOrNil: >>>>> |2.3% {40ms} primitives >>>>> |2.1% {37ms} Dictionary>>scanFor: >>>>> 1.9% {33ms} primitives >>>>> ==== >>>>> >>>>> But, if I do: >>>>> === >>>>> |n| >>>>> MessageTally spyOn:[ >>>>> n := Dictionary new. >>>>> 1 to: 4000000 do:[:each | n at: each put:each]. >>>>> ] >>>>> === >>>>> >>>>> results are: >>>>> ==== >>>>> - 179772 tallies, 180312 msec. >>>>> >>>>> **Tree** >>>>> -------------------------------- >>>>> Process: (40s) 1964: nil >>>>> -------------------------------- >>>>> 3.1% {5590ms} Dictionary(Set)>>atNewIndex:put: >>>>> |2.8% {5049ms} Dictionary(Set)>>fullCheck >>>>> | 2.3% {4147ms} Dictionary(Set)>>grow >>>>> | 1.3% {2344ms} Dictionary>>noCheckAdd: >>>>> 1.0% {1803ms} Association class>>key:value: >>>>> ==== >>>>> >>>>> Where are the rest of the process ? >>>>> Does anybody understand this behavior ? can you explain ? >>>>> >>>>> >>>>> Cheers, >>>>> Jannik >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> --- >>> Jannik Laval >>> PhD Student - Rmod Team - INRIA >>> Certified Project Management Associate (IPMA) >>> http://www.jannik-laval.eu >>> http://rmod.lille.inria.fr >>> --- >>> >>> >>> _______________________________________________ >>> 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 >> > --- > Jannik Laval > PhD Student - Rmod Team - INRIA > Certified Project Management Associate (IPMA) > http://www.jannik-laval.eu > http://rmod.lille.inria.fr > --- > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >

Oct. 25, 2009

[Pharo-project] NewCompiler for pharo?

by StÃ©phane Ducasse

Hi I would really like to know the status of the newcompiler for pharo? - when do you think we will be able to use it? - what is left to do? - how can people help? - is there a way to get something compiled in between? so I go back to preclosure or just hack the old compiler? Stef

Oct. 25, 2009

Re: [Pharo-project] Thread-safe collections

by Schwab,Wilhelm K

Stef, It sounds like I am indeed missing something in saving slices. I saw mention of it, but thought I read that it was not the preferred method and didn't dig further. Are you saying that I can make one big slice with all of my stuff and suddenly all becomes easy?? On the load side, I was having problems over name mis-matches that would not exist given a good packaging system. I could probably get around them now by reifying the names in my load script. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Sunday, October 25, 2009 2:59 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Thread-safe collections On Oct 23, 2009, at 3:31 PM, Schwab,Wilhelm K wrote: > Stef, > > With no disrespect to Sig's opinions, I'm glad to hear that. I very > quickly cobbled together a class called SharedLookupTable, and have no > problems making it (suitably debugged) available. > > Now it's time for me to kick your ass a little, to coin a phrase :) no problem > Monticello is pretty good at what it does, but I sense the things it > does not do interfering with good decision making. The class ended up > in my Dolphin compatibility package, in part because it belongs there, > though it really should be separate so I can easily release it and > people would be able to get it w/o having to accept other ideas they > might not want. But it went in the compatiblity package so I would > not have to mess around with another package. Saving them is a pain; > loading them into a new image is a pain. why? > Saving: the interface works well once understood, and the features it > offers should never go away. However, either by script or by multiple > selection, it would be nice to provide a comment to be applied to > everything to be saved "now" vs. having to be prompted for it, then > have the list scroll, then have to click away another window. Do that > 30 times and it starts to get old. this is strange because I thought that we fixed that pop up plague when saving slices Then you get all the comments you already typed in one of the button of the poped up window. Did you see it? > Loading: I spent a chunk of yesterday trying to build an RC1 image. > Doing so revealed that my script-loader for script-loader does not > validate package names. I had one build attempt come to a halt over > case-sensitivity; I do not mind that. What I mind is that the > particular case mix in question was more or less forced on me by a > typo of mine. If MC were better about offering choices when they > apply, I might not have typed it that way. > > I realize that Gofer is coming, and it might fix a lot of this. yes and also metacello which is coming along well > The ideas above are probably not new, but I list them just in case. > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo- > project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse > Sent: Friday, October 23, 2009 2:46 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Thread-safe collections > > I would really like to see some packages getting implementing around > the idea of a couple of robust and well tested thread safe > collections. > > Stef > > On Oct 23, 2009, at 2:16 AM, Schwab,Wilhelm K wrote: > >> Sig, >> >> One can always construct examples in which protecting the entire loop >> is the better option. That's not the scenario of interest. >> Just as shared queues are useful, shared sets and dictionaries have >> value for sporadic access scenarios. Doing it your way, everyone >> writes their own incompletely protected (read buggy/dangerous) ad- >> hoc implementations of these common collections. >> >> I favor having solid implementations that are complete and as correct >> as we can get them, leaving people to optimize as you suggest when it >> makes sense to do so. >> >> Bill >> >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo- >> project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko >> Sent: Thursday, October 22, 2009 5:23 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Thread-safe collections >> >> 2009/10/23 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >>> Hello all, >>> >>> I just looked around for thread-safe collections, and found nothing >>> that looks like a shared dictionary. The squeak-dev archives >>> contain the obligatory newbie posts (wanting all collections to be >>> thread >>> safe) and the expected replies, some of which are overly dismissive >>> of the idea. Something that protects things like >>> #at:ifAbsentPut: and friends is _really_ useful. Am I missing an >>> existing implementation? >>> >> >> Imo, there's only one shared collection which is useful - shared >> queue. :) If you need more kinds of thread-safe collections, it >> probably indicating that the concurrent code (or model) which you >> designed is in pretty bad shape. >> >> Just compare two following snippets: >> >> 1 to: 100 do: [:i | collection threadSafeAt: i put: something]. >> >> and: >> >> semaphore critical: [ 1 to: 100 do: [:i | collection at: i put: >> something] ]. >> >> What you think, which one is better? >> >> >>> Bill >>> >>> >>> _______________________________________________ >>> 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 > > > _______________________________________________ > 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

Oct. 25, 2009

Re: [Pharo-project] Shared directories: The bug is quicker than the eye

by David T. Lewis

I don't know if this helps, but for purposes of debugging here is a way to get at the error code from a flush(). No doubt I wrote the primitive by accident, not noticing that there was already a primitiveFileFlush in the FilePlugin. aStream := FileStream readOnlyFileNamed: 'foo.tmp'. result := OSProcess accessor flushExternalStream: aStream fileID. errorString := OSProcess accessor primErrorMessageAt: result. Dave On Fri, Oct 23, 2009 at 11:57:06AM -0700, John M McIntosh wrote: > If you invoke the flush primitive then it does this on unix/linux/mac- > osx/iPhone > http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPa… > & > http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPa… > > sqInt sqFileFlush(SQFile *f) { > /* Return the length of the given file. */ > > if (!sqFileValid(f)) return interpreterProxy->success(false); > fflush(getFile(f)); > return 1; > } > > On windows it does > http://msdn.microsoft.com/en-us/library/aa364439(VS.85).aspx > > sqInt sqFileFlush(SQFile *f) { > if (!sqFileValid(f)) FAIL(); > /* note: ignores the return value in case of read-only access */ > FlushFileBuffers(FILE_HANDLE(f)); > return 1; > } > > I'll note the api doesn't actually check for errors, give feedback or > whatever. > *cough* it could be failing and give you a clue, but you would need to > resort to FFI to do the file system calls to > get the data to visualize, or build your own VM with that returns the > result. > > > > On 2009-10-22, at 5:31 PM, Schwab,Wilhelm K wrote: > > > Hello all, > > > > I'm not sure what to make of this one. I just spent a couple of > > hours trying to find the "leak" in an algorithm of mine. It was > > reading roughly 1200 records, claiming to have processed all of > > them, and yet writing only about 450 rows into an output text file. > > One clue should have been that the number of output rows was > > somewhat random; I did not fully appreciate that until I worked > > around the problme. > > > > I tried an explicit #flush - no help. I looked for logic errors and > > found none. The file was being written to a Windows hosted share > > mounted by CIFS (which I am learning to view with contempt) from > > Ubuntu 9.04. You can see where this is going: writing the file > > locally gave the expected result. > > > > Any ideas on how one might further isolate the problem? My trust in > > Windows is well known<g>; I have never liked shared directories; I > > _really_ do not like CIFS as compared (reliability wise) to SMBFS; > > the network between me and the server is in question too (long > > story). All of that said, file support in Squeak, and hence so far > > inherited by Pharo, is not the best code I have seen to date, so it > > is easy to suspect too. Can one argue that since it worked locally, > > Pharo is not the problem? > > > > The little bit that I know of cifs is not encouraging. It sounds as > > though things moved from an easily killed process into the kernel > > which shows an almost Windows-like unwillingness to shut down when > > it cannot see servers. I have found numerous reports of problems > > copying large files over cifs, and I have enountered them too. > > > > Bill > >

Oct. 25, 2009

Re: [Pharo-project] question about results of MessageTally

by Laval Jannik

yes, with 0 it works. But, in some cases, we would like to have all branches. So, I will do the method spyOn:cutoff:, and keep the 1% threshold for spyOn:. Cheers, Jannik On Oct 25, 2009, at 20:54 , Adrian Lienhard wrote: > Have you tried with 0? I guess you get way too much in the tree > (especially when you trace a larger part of your application and not > only adding elements to a dictionary). It seems that 1% is a sensible > default as usually it does not make sense to look into these branches > more closely as you cannot optimize them much. > > Adrian > > On Oct 25, 2009, at 19:42 , Laval Jannik wrote: > >> Hi Adrian, >> >> Now I understand the "problem". >> So we can use "report:cutoff:" which allows us to give a specific >> value for the threshold. >> >> I will create a new method, spyOn:cutoff:. >> >> I think the method "spyOn:" must have the threshold equals to 0. >> No ? >> >> Cheers, >> Jannik >> >> >> On Oct 24, 2009, at 12:08 , Adrian Lienhard wrote: >> >>> Hi Jannik, >>> >>> Interesting question! >>> >>> You left out an important part oft the tally: the part about GC >>> activity. >>> >>> For the large dictionary I get: >>> >>> **GCs** >>> full 9 totalling 1,696ms (1.0% uptime), avg 188.0ms >>> incr 3776 totalling 186,310ms (94.0% uptime), avg 49.0ms >>> >>> That is, 95% of time is spent in GC! A lot of incremental GC cycles >>> are triggered because for each at:put: a new association instance is >>> created. The larger the dictionary, the larger is the new memory >>> space >>> and hence the incremental GC takes longer to complete. In the above >>> tally the average was 49ms compared to >>> >>> incr 275 totalling 1,113ms (58.0% uptime), avg 4.0ms >>> >>> for the smaller dictionary. Therefore, the ratio between actual >>> method >>> execution time and GC time differs significantly between the two >>> runs. >>> As a result, a lot of branches of the tally are below a total of 1% >>> runtime in the second case. Message tally has a threshold that cuts >>> off branches with less than 1% runtime. Therefore you see less >>> details. >>> >>> Cheers, >>> Adrian >>> >>> >>> On Oct 24, 2009, at 07:21 , Laval Jannik wrote: >>> >>>> Hi, >>>> >>>> when I use MassageTally>>spyOn: on the creation of a Dictionary, >>>> results have not the same details according to the size of >>>> Dictionary. >>>> >>>> For example: >>>> === >>>> |n| >>>> MessageTally spyOn:[ >>>> n := Dictionary new. >>>> 1 to: 400000 do:[:each | n at: each put:each]. >>>> ] >>>> === >>>> >>>> returns this results: >>>> >>>> ==== >>>> - 1745 tallies, 1751 msec. >>>> >>>> **Tree** >>>> -------------------------------- >>>> Process: (40s) 1964: nil >>>> -------------------------------- >>>> 45.8% {802ms} Dictionary(Set)>>atNewIndex:put: >>>> |43.6% {763ms} Dictionary(Set)>>fullCheck >>>> | |39.4% {690ms} Dictionary(Set)>>grow >>>> | | |27.2% {476ms} Dictionary>>noCheckAdd: >>>> | | | |25.2% {441ms} Dictionary(Set)>>findElementOrNil: >>>> | | | | |23.6% {413ms} Dictionary>>scanFor: >>>> | | | | |1.6% {28ms} primitives >>>> | | | |2.0% {35ms} primitives >>>> | | |9.2% {161ms} primitives >>>> | | |3.0% {53ms} Array(SequenceableCollection)>>do: >>>> | |2.4% {42ms} primitives >>>> | |1.8% {32ms} SmallInteger(Magnitude)>>max: >>>> |2.2% {39ms} primitives >>>> 22.4% {392ms} Association class>>key:value: >>>> |18.9% {331ms} Association class(LookupKey class)>>key: >>>> | |16.3% {285ms} Association(LookupKey)>>key: >>>> | |2.6% {46ms} primitives >>>> |1.9% {33ms} Association>>value: >>>> |1.6% {28ms} primitives >>>> 4.4% {77ms} Dictionary(Set)>>findElementOrNil: >>>> |2.3% {40ms} primitives >>>> |2.1% {37ms} Dictionary>>scanFor: >>>> 1.9% {33ms} primitives >>>> ==== >>>> >>>> But, if I do: >>>> === >>>> |n| >>>> MessageTally spyOn:[ >>>> n := Dictionary new. >>>> 1 to: 4000000 do:[:each | n at: each put:each]. >>>> ] >>>> === >>>> >>>> results are: >>>> ==== >>>> - 179772 tallies, 180312 msec. >>>> >>>> **Tree** >>>> -------------------------------- >>>> Process: (40s) 1964: nil >>>> -------------------------------- >>>> 3.1% {5590ms} Dictionary(Set)>>atNewIndex:put: >>>> |2.8% {5049ms} Dictionary(Set)>>fullCheck >>>> | 2.3% {4147ms} Dictionary(Set)>>grow >>>> | 1.3% {2344ms} Dictionary>>noCheckAdd: >>>> 1.0% {1803ms} Association class>>key:value: >>>> ==== >>>> >>>> Where are the rest of the process ? >>>> Does anybody understand this behavior ? can you explain ? >>>> >>>> >>>> Cheers, >>>> Jannik >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> --- >> Jannik Laval >> PhD Student - Rmod Team - INRIA >> Certified Project Management Associate (IPMA) >> http://www.jannik-laval.eu >> http://rmod.lille.inria.fr >> --- >> >> >> _______________________________________________ >> 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 --- Jannik Laval PhD Student - Rmod Team - INRIA Certified Project Management Associate (IPMA) http://www.jannik-laval.eu http://rmod.lille.inria.fr ---

Oct. 25, 2009

Re: [Pharo-project] [ANN] Pharo rc1dev10491 - Win32 Installer

by StÃ©phane Ducasse

yeap! Thanks Stef On Oct 25, 2009, at 8:56 PM, Adrian Lienhard wrote: > Thanks, Torsten! > > Adrian > > On Oct 25, 2009, at 20:49 , Torsten Bergmann wrote: > >> Forgot to mention: >> >> Windows Installer 1.0-10491-rc1dev09.10.5 is up >> on the download page. >> >> Bye >> Torsten >> -- >> GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! >> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 >> >> _______________________________________________ >> 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

Oct. 25, 2009