- Pharo-dev - lists.pharo.org

[Pharo-project] Inspector limiting an object printString output
by Igor Stasenko Aug. 3, 2011

Aug. 3, 2011

In Inspector>>selectionPrintString it uses: text := [self selection printStringLimitedTo: 5000] which sometimes not quite adequate (sometimes i need to display more). I think it would be nicer if inspector would ask object, if it desires to limit itself (when printing in big inspection pane) and what concrete limit it desires, instead of hardcoding the number in inspector. Something like: Object>>printStringLimited ^ self printLimit ifNotNil: [:limit | self printStringLimitedTo: limit ] ifNil: [ self printString ]. so, then #printLimit could be overridden by choice of developer, to set (or not) the limits -- Best regards, Igor Stasenko AKA sig.

3 2

[Pharo-project] Optimizing RunArray
by Nicolas Cellier Aug. 3, 2011

Aug. 3, 2011

I played a bit with RunArray, and found some un-optimized features. First, I don't know why RunArray is an ArrayedCollection. It cannot #add: but it can #addFirst: and #addLast:. It cannot #add:withOccurrences: but it can #addLast:times:. Why inventing new selectors for old behaviours ? These operations will cost a realloc it the last value is different, so the underlying runs/values could better be an OrderedCollection if these operations are used often. A RunArray cannot remove at all. Very weird collection species, I don't like the implementation too much. Then, #do: loops could be far faster. They rely on ArrayedCollection which inlines do: loops with #to:do: and #at: But #at: is not that fast. Scanning the runs and counting elements would result in a n^2 cost. Fortunately there is a cache lastIndex,lastRun,lastOffset to keep a cost n. Nonetheless, all the tests cost, and the loop is suboptimal. Let use see: version 1: RunArray>>fastDo: aBlock runs with: values do: [:r :v | r timesRepeat: [aBlock value: v]]. | tmp | tmp := ((Array new: 1000) collect: [:e | 4 atRandom]) as: RunArray. { [ tmp do: [:e |]] bench. [ tmp fastDo: [:e |]] bench. } #('3,220 per second.' '6,290 per second.') But timesRepeat: is slow, it is unoptimized by the compiler and costs a message send. I think we should implement BlockClosure>>repeat: and optimize that call in Compiler. But let's not do it, and rather inline by ourself: version 2: runs with: values do: [:r :v | 1 to: r do: [:i | aBlock value: v]]. | tmp | tmp := ((Array new: 1000) collect: [:e | 4 atRandom]) as: RunArray. { [ tmp do: [:e |]] bench. [ tmp do2: [:e |]] bench. } #('3,070 per second.' '25,500 per second.') We can even inline the with:do: loop itself: version 3: 1 to: runs size do: [:i | | r v | v := values at: i. r := runs at: i. [( r := r - 1) >= 0] whileTrue: [aBlock value: v]]. | tmp | tmp := ((Array new: 1000) collect: [:e | 4 atRandom]) as: RunArray. { [ tmp do: [:e |]] bench. [ tmp do2: [:e |]] bench. } #('3,370 per second.' '32,200 per second.') Now the operation I wanted to use was reverseDo: so I implemented: RunArray>>fastReverseDo: aBlock | i | i := runs size. [i > 0] whileTrue: [ | r v | v := values at: i. r := runs at: i. i := i - 1. [( r := r - 1) >= 0] whileTrue: [aBlock value: v]]. | tmp | tmp := ((Array new: 1000) collect: [:e | 4 atRandom]) as: RunArray. { [ tmp reverseDo: [:e |]] bench. [ tmp reverseDo2: [:e |]] bench. } #('83.9 per second.' '32,600 per second.') Ouch! The cache is missing a lot of indices, and our loop turns into a n^2 cost. I know, premature optimization bla bla bla, but a factor x400 is worth some inlining no? I guess these features are never used. By now RunArray is kind of private utility for Text implementation. But it could / should be generic. I also have proposals for count: / select: / collect:. etc... It would be to evaluate the block only once per group of values. For example RunArray>>collect: aBlock "Beware, the block will be evaluated only once per group of values." ^(self class runs: (runs collect: aBlock) contents values: values copy) coalesce But that's controversial, it would make the RunArray behave differently if the block has side effects... | i tmp tmp2 tmp3 | tmp := ((Array new: 1000) collect: [:e | 4 atRandom]). i := 0. tmp2 := tmp collect: [:e | i := i + 1]. i := 0. tmp3 := (tmp as: RunArray) collect: [:e | i := i + 1]. tmp2 = tmp3 asArray ==> false Nicolas

3 7

[Pharo-project] [ANN] SmalltalkHub demo online
by Nicolas Petton Aug. 3, 2011

Aug. 3, 2011

Hi, We are happy to announce the first public demo of SmalltalkHub: http://smalltalkhub.objectfusion.fr You can explore SmalltalkHub at: http://smalltalkhub.objectfusion.fr/explore This is an alpha quality demo, please use it for testing purposes only. Several features that will be included in the final release are missing, especially: - Team management - Client-side scripting features - Full commit lists Still incomplete features: - the UI for cloning is incomplete, especially, the list of forks is missing - The issue tracker is only partly implemented - Several admin tools are missing - The explore page misses a few things Cheers, Nicolas -- Objectfusion S.A.R.L. Web application development & design http://www.objectfusion.fr/en

16 45

[Pharo-project] identityHash bits not incremented for new objects?
by Igor Stasenko Aug. 3, 2011

Aug. 3, 2011

I found that #testBecomeIdentityHash sometimes failing, sometimes not. It seems like VM 'forgets' to produce different identityHash bits for two consequently allocated objects, while test assumes that they are always different. If i insert a statement (see the code), test no longer fails. testBecomeIdentityHash "Note. The identity hash of both objects seems to change after the become:" | a b c d | a := 'ab' copy. b := 'cd' copy. >>> [ b identityHash = a identityHash ] whileTrue: [ b := b copy ]. c := a. d := b. a become: b. self assert: a identityHash = c identityHash; assert: b identityHash = d identityHash; deny: a identityHash = b identityHash. A simple piece of code reveals the problem: (1 to: 20) collect: [:i | 'ab' copy basicIdentityHash ] #(954 954 955 955 956 956 957 957 958 958 959 959 960 960 961 961 962 962 963 963) -- Best regards, Igor Stasenko AKA sig.

5 9

[Pharo-project] writing a test method
by Alexandre Bergel Aug. 3, 2011

Aug. 3, 2011

Hi! When I write a test method, I always need to open a new window with the definition of the setUp. It would be really cool to have a better support in the browser for this. Maybe having a split of the text pane or something. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

1 0

[Pharo-project] Small Seaside image
by laurent laffont Aug. 3, 2011

Aug. 3, 2011

Hi, actually using PharoCore 1.3, loading ConfigurationOfSeaside30 Core, then ScriptLoader>>cleanUpForProduction I have a 13MB image. Is it possible to have it smaller ? (I know a next step is to be able to use PharoKernel). Laurent Laffont - @lolgzs <http://twitter.com/#!/lolgzs> Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/ Developer group: http://cara74.seasidehosting.st

5 6

[Pharo-project] [update 1.3] #13293
by Marcus Denker Aug. 3, 2011

Aug. 3, 2011

13293 ----- Issue 4565: Monticello workflow broken http://code.google.com/p/pharo/issues/detail?id=4565 -- Marcus Denker -- http://marcusdenker.de

2 1

[Pharo-project] something we lost with events [was Optimizing RunArray]
by Nicolas Cellier Aug. 3, 2011

Aug. 3, 2011

I've got the feeling that we've lost one feature: When you're typing super fast, characters would be inserted several at once in a st80 ParagraphEditor That typically happens when the displaying or more probably the paragraph re-composition is slow. The composition/display cycle would occur after first key - giving the impression of a non responsive UI - but then consecutive key strokes would flow all in once thanks to the while loops in #readKeyboard and the buffered Queue of events. Not the most interactive UI ever, but now things are worse with current event implementation. There is a one by one keystroke / composition / display, and the result is a less responsive UI than polling ! If you edit a Smalltalk method, no problem, but try editing your 45 MByte change log just to see how deadly it feels, super fast means 0.2 Hz on my machine. I wonder how we could restore this feature... Nicolas

3 2

[Pharo-project] ESUG 2011 Innovation Technology Awards: Reminder
by jdelgado Aug. 3, 2011

Aug. 3, 2011

Hi, Again, a reminder: ESUG 2011 Innovation Technology Awards http://esug.org/Conferences/2011/InnovationTechnologyAwards New Deadline: August 15. Have you written innovative Smalltalk? The developers of any Smalltalk-based software can enter by submitting a 3-5min video of their software. Entrants demo their systems in a session at the end of Monday August 22nd 2011, after which the conference attendees vote. (A vote consists in providing a sorted list of 3 preferred pieces of software.) The top 3 teams with the most innovative software will receive, respectively, 500 Euros, 300 Euros and 200 Euros. The results are announced in the Awards ceremony that is held during the social event. Applicants should provide the following information on the conference registration server. Once you have registered your personal info, an "Awards" menu allows submitting your software. You can provide this information when you first register, or login again later and update your details. Info to provide: Name of the software Licence information (free, or shareware, or a commercial) Name of the Smalltalk dialect used Names, Affiliation and Country of developers URL for a video (3-5 min) showing a screencast / demo of the software URL for downloading the software or at least a runnable demo Deadline: August 15 Any Smalltalker can apply (students, companies, ...). The presented piece of code/software should be written in Smalltalk or directly support Smalltalk (e.g. Smalltalk VM). All Smalltalk dialects are accepted. The applicant should own the copyright/copyleft of presented code or at least be the official representative of the copyright/copyleft owner. The software should be available on-line for evaluation (time-limited evaluation version, demo version, free for non-commercial use ...). Bests Jordi -- View this message in context: http://forum.world.st/ESUG-2011-Innovation-Technology-Awards-Reminder-tp371… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

1 0

[Pharo-project] [update 1.4] #14073
by Marcus Denker Aug. 3, 2011

Aug. 3, 2011

14073 ----- Issue 4574: ChangedMessageSet is not referenced http://code.google.com/p/pharo/issues/detail?id=4574 Issue 4569: load updates just loads the last update? http://code.google.com/p/pharo/issues/detail?id=4569 -- Marcus Denker -- http://marcusdenker.de

1 0