- Pharo-dev - lists.pharo.org

Removing a package from Smalltalkhub
by roberto.minelli＠usi.ch May 22, 2013

May 22, 2013

Hi, I was wondering if and how can I delete a package from Smalltalkhub. Thanks in avance, R

4 4

[regression reporter]regression occurred
by no-reply＠ci.inria.fr May 22, 2013

May 22, 2013

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=wi… 2 regressions found. OpalCompiler.Tests.Misc.MustBeBooleanTests.testIfTrueEffect OpalCompiler.Tests.Misc.MustBeBooleanTests.testIfTrueValue

1 0

[regression reporter]regression occurred
by no-reply＠ci.inria.fr May 22, 2013

May 22, 2013

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=ma… 2 regressions found. OpalCompiler.Tests.Misc.MustBeBooleanTests.testIfTrueEffect OpalCompiler.Tests.Misc.MustBeBooleanTests.testIfTrueValue

1 0

[regression reporter]regression occurred
by no-reply＠ci.inria.fr May 22, 2013

May 22, 2013

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=li… 2 regressions found. OpalCompiler.Tests.Misc.MustBeBooleanTests.testIfTrueEffect OpalCompiler.Tests.Misc.MustBeBooleanTests.testIfTrueValue

1 0

Pharo por Ejemplo vs Pharo en exemplos
by StÃ©phane Ducasse May 21, 2013

May 21, 2013

Hi guys one guy mentions that Pharo en exemplos is a better translation than Pharo por Ejemplo so what is your point of view on that? Stef

10 10

(Identity)Dictionary benchmarks
by Max Leske May 21, 2013

May 21, 2013

My coworker performed some interesting benchmarks on the various dictionary types in Pharo. If you look at the attachments you'll see four things: 1. SmallDictionary and SmallIdentityDictionary are totally useless when it comes to performance. Unless their existence is somehow justified by saving space (which might be important for embedded systems) I don't see why we should keep them around. 2. The special Fuel collections for large numbers of elements could be a valuable addition to the basic collections 3. SmallInteger>>identityHash is really slow. Using SmallInteger as keys in IdentityDictionary is significantly slower than using them in a regular Dictionary because the identity check is done via #identityHash (#hash simply answers self). 4. Arrays are cool :) Should I open issues on FogBugz for any of these points? Especially point 3 bothers me because I feel that using a "primitive" type should be fast under all circumstances. You'll find below the benchmark data (collected in 1.4, verified in 2.0) and the code to run it. Cheers, Max > > > > > > > > > -------------------------------------------------------------- > > ( comments are variations) > > sizes := #( 10 20 30 40 50 60 70 80 90 100 120 130 140 150 160 170 180 190 200 300 400 500 600 700 800 900 1000 ). > "sizes := #( 10 20 30 40 50 60 70 80 90 100 120 130 140 150 160 170 180 190 200 300 400 500 600 700 800 900 1000 1500 2000 2500 3000 3500 4000 4500 5000 6000 7000 8000 9000 10000 )." > "batches := sizes collect: [ :size | size -> ((10000000 / size) asFloat // 10) ]." > batches := sizes collect: [ :size | size -> 10000 ]. > alphabet := Character alphabet. > > batches do: [ :a | Transcript tab; show: a key asString ]. Transcript cr. > batches do: [ :a | Transcript tab; show: a value asString ]. Transcript cr. > "{ Dictionary. SmallDictionary. IdentityDictionary. SmallIdentityDictionary. FLLargeIdentityDictionary } " > { Dictionary. IdentityDictionary. FLLargeIdentityDictionary } > "{ Array }" > do: [ :class | > Smalltalk garbageCollect. > Transcript show: class name. > batches > do: [ :a | > | struct strings iterations | > "strings := (1 to: a key) collect: [ :i | i asString ]." > strings := (1 to: a key) collect: [ :i | > String streamContents: [ :s | > 20 atRandom timesRepeat: [ s nextPut: alphabet atRandom ] ] ]. > struct := class new. > "struct := (class = FLLargeIdentityDictionary > ifTrue: [ class new ] > ifFalse: [ class new: a key ])." > Transcript tab; show: ([ > a value timesRepeat: [ > 1 to: a key do: [ :i | struct at: (strings at: i)" i" put: i ] ] ] timeToRun). > strings := nil ] > displayingProgress: class name asString. > Transcript cr. ] > displayingProgress: 'Processing ...' >

3 3

Re: [Pharo-dev] [Pharo-fuel] (Identity)Dictionary benchmarks
by Max Leske May 21, 2013

May 21, 2013

On 21.05.2013, at 10:58, Camillo Bruni <camillobruni(a)gmail.com> wrote: > my random pessimistic comments > > a) your benchmarking script sucks! => use SMARK!! http://smalltalkhub.com/#!/~StefanMarr/SMark We're fully aware of that :) > b) check my master thesis for a more thorough testing of dictionary, including a cleaner implementation that defaults to something like a small dictionary without a special class: http://scg.unibe.ch/archive/masters/Brun11a.pdf > > the optimistic version: > > > On 2013-05-21, at 09:47, Max Leske <m.leske(a)netstyle.ch> wrote: > >> My coworker performed some interesting benchmarks on the various dictionary types in Pharo. If you look at the attachments you'll see four things: >> 1. SmallDictionary and SmallIdentityDictionary are totally useless when it comes to performance. Unless their existence is somehow justified by saving space (which might be important for embedded systems) I don't see why we should keep them around. > > yes their usage is not always justified, but be careful what you measure: as far as I see you only measure addition, no? (sorry again, but that benchmark brutally sucks, it's so damn hard to read... :P). Iteration and retrieval have to measure as well, also how the dictionaries behave under key hash collisions (though I am definitely not defending the small dicts.. :). > >> 2. The special Fuel collections for large numbers of elements could be a valuable addition to the basic collections > > THere is the pluggable key dictionary for that reason already, no? The main problem is the limited hashes which results in quite some hash collisions for very large dictionaries. > >> 3. SmallInteger>>identityHash is really slow. Using SmallInteger as keys in IdentityDictionary is significantly slower than using them in a regular Dictionary because the identity check is done via #identityHash (#hash simply answers self). > > that is really strange :/ > >> 4. Arrays are cool :) >> >> Should I open issues on FogBugz for any of these points? Especially point 3 bothers me because I feel that using a "primitive" type should be fast under all circumstances. >> >> You'll find below the benchmark data (collected in 1.4, verified in 2.0) and the code to run it. >> >> Cheers, >> Max >> >>> >> <performance.xlsx> >>> >>> >> <performance.xls> >>> >>> >>> >>> >>> >>> -------------------------------------------------------------- >>> >>> ( comments are variations) >>> >>> sizes := #( 10 20 30 40 50 60 70 80 90 100 120 130 140 150 160 170 180 190 200 300 400 500 600 700 800 900 1000 ). >>> "sizes := #( 10 20 30 40 50 60 70 80 90 100 120 130 140 150 160 170 180 190 200 300 400 500 600 700 800 900 1000 1500 2000 2500 3000 3500 4000 4500 5000 6000 7000 8000 9000 10000 )." >>> "batches := sizes collect: [ :size | size -> ((10000000 / size) asFloat // 10) ]." >>> batches := sizes collect: [ :size | size -> 10000 ]. >>> alphabet := Character alphabet. >>> >>> batches do: [ :a | Transcript tab; show: a key asString ]. Transcript cr. >>> batches do: [ :a | Transcript tab; show: a value asString ]. Transcript cr. >>> "{ Dictionary. SmallDictionary. IdentityDictionary. SmallIdentityDictionary. FLLargeIdentityDictionary } " >>> { Dictionary. IdentityDictionary. FLLargeIdentityDictionary } >>> "{ Array }" >>> do: [ :class | >>> Smalltalk garbageCollect. >>> Transcript show: class name. >>> batches >>> do: [ :a | >>> | struct strings iterations | >>> "strings := (1 to: a key) collect: [ :i | i asString ]." >>> strings := (1 to: a key) collect: [ :i | >>> String streamContents: [ :s | >>> 20 atRandom timesRepeat: [ s nextPut: alphabet atRandom ] ] ]. >>> struct := class new. >>> "struct := (class = FLLargeIdentityDictionary >>> ifTrue: [ class new ] >>> ifFalse: [ class new: a key ])." >>> Transcript tab; show: ([ >>> a value timesRepeat: [ >>> 1 to: a key do: [ :i | struct at: (strings at: i)" i" put: i ] ] ] timeToRun). >>> strings := nil ] >>> displayingProgress: class name asString. >>> Transcript cr. ] >>> displayingProgress: 'Processing ...' >>> >> >> _______________________________________________ >> Pharo-fuel mailing list >> Pharo-fuel(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel > > > _______________________________________________ > Pharo-fuel mailing list > Pharo-fuel(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel

3 3

Re: [Pharo-dev] WhatsUp from: 2013-05-20 until: 2013-05-31
by Stephan Eggermont May 21, 2013

May 21, 2013

Hi, I've worked a bit with Dusty & Diego on LightHouse, the Distributed Issue Tracker. Here is a short video of the current state of the project: http://www.youtube.com/watch?v=g_Q1DeeEiAQ Source can be found on Smalltalkhub, DiegoLont/LightHouse Stephan

1 0

[update 3.0] #30152
by Esteban Lorenzano May 21, 2013

May 21, 2013

30152 ----- 10478 Add Symbol >> #asClass https://pharo.fogbugz.com/f/cases/10478 10705 Safer NativeBoost usage https://pharo.fogbugz.com/f/cases/10705 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-Support-EstebanLorenza… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Base-EstebanLorenzano… http://smalltalkhub.com/mc/Pharo/Pharo30/main/FileSystem-Core-EstebanLorenz…

1 0

[Fuel] [FuelMetaLevel] Help
by roberto.minelli＠usi.ch May 21, 2013

May 21, 2013

Hi, I am using Fuel to serialize/deserialize some objects. As part as the objects I need to serialize there are some classes, class definitions (i.e., Ring) and some CompiledMethod. It's not always the case that I serialize and materialize in the same image, thus sometimes I experience FLClassNotFound and FLMerthodChanged exceptions. I discovered FuelMetaLevel, as far as I can understand, it can solve many problems. Now my questions are (1) am I correct that it can help? and (2) from which repository should I load FuelMetaLevel? As far as I understood not Fuel is developed as part of Pharo so it's pre-installed in every fresh image. I tried to get FuelMetaLevel from ss3 (both Pharo20 and PharoInbox) but when I run FLSerializer newFull serialize: 'whatever' toFileNamed: 'whatever.fuel' I got a MNU on FLFullGlobalMapper>>#initializeWithInternalBehaviors:internalMethods:globalSymbols: since the class FLGlobalAssociationCluster is not part of my image. I'm attaching the stack trace of the error I'm getting. Thanks in advance, RM > UndefinedObject(Object)>>doesNotUnderstand: #newAnalyzing > FLFullGlobalMapper>>initializeWithInternalBehaviors:internalMethods:globalSymbols: > FLFullGlobalMapper class>>newWithInternalBehaviors:internalMethods:globalSymbols: > FLAnalyzer>>fullGlobalMappers > FLAnalyzer>>useFullMappers in Block: [self fullGlobalMappers] > FLAnalyzer>>globalMappers > FLAnalyzer>>mappers > FLAnalyzer>>firstInMapperChain > FLAnalyzer>>setDefaultAnalysis in Block: [:anObject | (FLAnalysis... > FLAnalyzer>>analysisFor: > FLSerialization>>analysisStep > FLSerialization>>run > FLSerializer>>setDefaultSerialization in Block: [:anObject :anEncoder | (FLSerialization... > FLSerializer>>serialize:on: in Block: [:anEncoder | ... > FLEncoder class>>on:globalEnvironment:do: in Block: [aBlock value: anEncoder] > BlockClosure>>ensure: > FLEncoder class>>on:globalEnvironment:do: > FLSerializer>>serialize:on: > FLSerializer>>serialize:toFileNamed: in Block: [:aFileStream | ... > StandardFileStream class(FileStream class)>>detectFile:do: in Block: [anotherBlock value: file] > BlockClosure>>ensure: > StandardFileStream class(FileStream class)>>detectFile:do: > StandardFileStream class(FileStream class)>>forceNewFileNamed:do: > FLSerializer>>serialize:toFileNamed: > UndefinedObject>>DoIt > Compiler>>evaluate:in:to:notifying:ifFail:logged: > SmalltalkEditor>>evaluateSelectionAndDo: in Block: [rcvr class evaluatorClass new... > BlockClosure>>on:do: > SmalltalkEditor>>evaluateSelectionAndDo: > SmalltalkEditor>>evaluateSelection >

3 3