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

[Pharo-project] Glass
by Torsten Bergmann Sept. 14, 2010

Sept. 14, 2010

Heard rumors about a (free) Glass announcement from ESUG. Any details or pointers to a website? Thx T. -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail

4 3

[Pharo-project] One order of magnitude faster sets/dicts?!
by Adrian Lienhard Sept. 14, 2010

Sept. 14, 2010

This mail is quite long as I copied it from a conversation with Toon Verwaest. Toon and Camillo re-implemented hashed collections for Pinocchio (http://scg.unibe.ch/research/pinocchio) Their benchmarks have shown that the new implementation is significantly faster than the one in Pharo 1.1. The source code is available from www.squeaksource.com/p.html (they haven't set a license, but I'm pretty sure they'll release their code as MIT). I post this here to find somebody knowledgeable in the area to take a look at the code and figure out whether this implementation would be interesting for Pharo... Cheers, Adrian citing Toon: We ran some benchmarks on our data structures (It's in comparison with and benchmarked in standard Pharo 1.1). We just add / remove integers within a certain range thus always perfectly distributed making it ideal for Pharo dictionaries. The numbers show how long a certain benchmark took on average in 20 runs of the benchmark and its standard deviation over those runs. A single benchmark run generally consists of many individual operations on the collection in question. For example: benchIncludes 1 to: set size * 2 do: [ :i| set includes: i ] where the set has size 10000. Evaluating this once results in a single run. So the number at the top of the benchmark is the sum of all averages with the average stdev. The results: PDictionary: 15.8 +/-1.7 Do 0.472 +/-0.079 RemoveKey 0.010 +/-0.021 AtPut 0.947 +/-0.02 AtIfAbsentPut 1.64 +/-0.96 AtPutExisting 0.198 +/-0.011 KeysAndValuesDo 0.502 +/-0.09 IncludesKey 0.365 +/-0.024 AtPutNew 4.2 +/-1.3 Includes 7.40 +/-0.33 Dictionary: 138.2 +/-4.7 Do 0.830 +/-0.098 RemoveKey 10.292 +/-0.077 AtPut 0.957 +/-0.044 AtIfAbsentPut 1.52 +/-0.95 AtPutExisting 0.203 +/-0.011 KeysAndValuesDo 0.850 +/-0.096 IncludesKey 80.25 +/-0.25 AtPutNew 3.5 +/-1.3 Includes 39.8 +/-4.4 PSet: 1.767 +/-0.057 Remove 0.008 +/-0.018 Add 0.845 +/-0.039 AddExisting 0.310 +/-0.021 AddNew 0.240 +/-0.021 Includes 0.365 +/-0.024 Set: 70.9 +/-1.2 Remove 7.737 +/-0.051 Add 0.755 +/-0.022 AddExisting 0.305 +/-0.015 AddNew 2.473 +/-0.03 Includes 59.6 +/-1.2 Obviously the very slight differences have to be taken with a grain of salt, but whenever it's more than 10x faster it's quite unlikely that it's due to some random runtime variation that might totally change in another run. An important thing for our datastructures is that they don't degrade since we don't have colliding hashes; but we didn't really test that yet (although it becomes obvious in some of the benchmark results such as removing of elements and testing presence of elements). > Is there anything special that one would neet to consider when replacing the old implementation in Pharo with yours? What doesn't happen at the moment is shrinking dictionaries after they have grown significantly. I wouldn't know at what point to do so either; nor do I think Dictionary does that? There is a parameter indicating how many elements can be added before it switches from a SmallDictionary version to a dictionary with buckets. This is set to 20 by default, and I have no idea if it makes sense to change it; I didn't really profile what the optimal number is. Maybe it makes sense to make that a constant in the code rather than an instance variable to save a bit of space and time ... We have our own PHashedCollection subclassing from Collection; so the biggest part of the hierarchy is compatible with what Pharo has. Mostly while porting Pinocchio-specific stuff will have to be removed; mostly annotations related to Pinocchio Primitives and exporting directives. This is all straightforward though. The current "ratio" of hashes to elements is set to 500%. So basically when you have 32 buckets it will only grow when it contains 160 elements (or key-value pairs), so 5 elements per bucket on average. This seems to not make it slower which is understandable since SmallDictionary is pretty fast for small amounts of elements; but this ratio might have to be tweaked depending on the kind of objects and is currently a parameter. The advantage of using 500% is that you have A LOT less garbage. Oh, and our dictionaries do use a lot less garbage, since Pharo's dictionaries use association objects for each key-value pair. We don't, so we never generate garbage when you remove an object. Our Sets on the other hand do use a bit more memory because of the bucket scheme. Sets don't use associations so we don't have an edge there :) Only performance-wise in that case. The hashes are masked with the amount of buckets - 1, since the buckets are always a power of 2. This implies that the lower bits of the hash are the most significant ones. This does not work together with the current identityHash / IdentityDictionary since the 12bit hash is shifted to the left by 18 (or so). This would make all the lower 18 bits 0 and all objects thus ending up in the first bucket. That is a very important thing to note enough. However, I also think it's a bit strange to just bitshift the identityHash by 18. You don't win any significant numbers with it ... you have 12bit hashes; no way to improve that (without changing the image format). Since we overfill our dictionaries however this works quite ok with those bad hashes; and we'll only start wasting a bit of space after you have added 20480 elements to the dictionary (you have 4096 different hashes with 12 bits, * 5).

4 8

[Pharo-project] Extension Methods
by DeNigris Sean Sept. 14, 2010

Sept. 14, 2010

Extension methods showing up as *[PackageName] is an ugly hack!! It is an implementation detail (in this context) that probably should be first class (as a package name somewhere else), but definitely shouldn't be displayed to the user here :( How about if *[PackageName]-[method category] showed up in the browser as: Category (in the category pane): [method category] Method name (in the right pane): [method name] (*[PackageName]) This way, since categories would cease to be hijacked, the methods would show up in their correct logical category, and it would still be clear that they were in a different package. Ideally, the dialogs to change the package/category would reflect this model, but changing the browsers would be a good start. >From ESUG Sean

2 1

[Pharo-project] Strange behavior with TestRunner
by Noury Bouraqadi Sept. 14, 2010

Sept. 14, 2010

On the pharo 1.2-12141, I run the SocketStreamTest. All green. But, when I try the "Run Coverage" all turn red. Any hint? Noury @ ESUG 2010 - Barcelona :-) --- 18th International Smalltalk Joint Conference, September 13 -17 2010 Barcelona, Spain. http://www.esug.org/Conferences/2010

3 2

[Pharo-project] Automatically (OB?) run class methods?
by Mariano Martinez Peck Sept. 14, 2010

Sept. 14, 2010

HI guys. I tend to see these pattern everywhere: openLoadAndQueryWorkspace "self openLoadAndQueryWorkspace" (Workspace new acceptContents: ' â¦â¦ Having to have that kind of thing from my point of view, reveals a weakness in our IDE. Furthermore, when we rename the method, the comment is not refactored. Now I was thinking if it would be interesting or not, to be able to directly run class side methods. It would be nice: - To have an entry in the context (right click) menu, only when selecting a class method, to directly evaluate it. Maybe we can call it "Evaluate it" or "Send message" or "Do it" â¦ I don't know. - To have a shortcut for that. Thenâ¦we are inside that method for example, and with a shortcut we can evaluate itâ¦no need to go up to the name and evaluate the comment. What do you think? Cheers

3 3

[Pharo-project] Thanks Marcus for the presentation of Pharo
by Alexandre Bergel Sept. 14, 2010

Sept. 14, 2010

I like very much the way you described the role of Pharo for doing Research. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

1 0

[Pharo-project] Refactor class name should check also in comments?
by Mariano Martinez Peck Sept. 14, 2010

Sept. 14, 2010

Hi Lukas. Several times I refractor a class name and I forget to update a lot of references to it in comments, class comments, etcâ¦ Do you think we can adapt RB so that it also checks there? Thanks Mariano

2 1

[Pharo-project] help needed for xmlparser
by Alexandre Bergel Sept. 14, 2010

Sept. 14, 2010

Hi! There has been a yellow test for some times already. XMLParserTest>>#testDecodingCharacters I am not really sure how to fix it. It would be _really_ cool to have a character encoding guru to have a look at it... If you fixed it and happen to be at esug, I invite you for a beer :-) Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

2 3

Re: [Pharo-project] [squeak-dev] Re: Squeak VM on iPad/IPhone gets open/GL rendering
by John M McIntosh Sept. 14, 2010

Sept. 14, 2010

I figured out we can't reasonably do open/GL arbitrary sized textures on the first gen iPhone or iPod Touch. So I check for iOS 3.1.x and fall back to using the CALayer render, the wonders of polymorphism. I also commented out some of the nifty eToys on the iPad features lurking in the VM, like rotate me to get a keyboard, and also checked and confirmed that rotation of both types of renders with the view as a plain view or embedded in a scrolling view worked as expected. At this point I'm somewhat done the open/GL optimization. The implementation is to: Ccreate a texture and populate via glTexImage2D using apple's extension APPLE_texture_2D_limited_npot at view surface creation time. Then on a ioForceDisplayUpdate (implicit or explicit) we take the union of the rectangles observed in ioShowDisplayOnWindow and then use the glTexSubImage2D to push the bytes one row at a time by calculating the offset into the bytes found in the Display special object, the texture then is drawn to the screen. I note we create the full sized glTexImage2D only once at startup time. An alternate choice was to use kEAGLDrawablePropertyRetainedBacking=YES and set the glTexImage2D & glTexSubImage2D pair for each ioForceDisplayUpdate using the subrectangle. But I found the Open/GL fps had a lot of jitter, so it seemed less animation friendly than creating the glTexImage2D once and doing the glTexSubImage2D on each ioForceDisplayUpdate. Someone mutters, GL_FRAMEBUFFER_OES but at this point someone can pay me to explore faster alternatives. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

1 0

[Pharo-project] TextEditor and NewTextMorph merges and fixes
by Fernando olivero Sept. 13, 2010

Sept. 13, 2010

Issue: 2375 Name: System-Text-FernandoOlivero.8 Author: FernandoOlivero Time: 17 May 2010, 3:22:14 pm ###################################### Issue: -- Name: Morphic-FernandoOlivero.588 Author: FernandoOlivero Time: 17 May 2010, 1:42:04 pm

3 9