[Pharo-project] i know esug just started...but some kind soul can please revive squeaksource
thanks, Fernando ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Squeak VM on iPad/IPhone gets open/GL rendering
Spent a few more hours today reading and then decided the test case I had from Bert spent 90% of it's time in the interpreter's copyLoop logic. Toss that for the fall back of using bouncing atoms so I could get a better feel of the performance differences. So after some optimization, on the iPad, the CALayer pushes about 38 fps, the OpenGL code pushes 49 fps (which is limited by Morphic loop). In checking Instruments the 10% of the time taken in CALayer for memcpy of data out of the UIImages is gone when I do open/GL However if the drawing area becomes too big then the Open/GL drawing is slower, trade offs, trade offs. Also the byte alignment plays a part, that I have to explore more. Still this is significant progress and we'll see what happens this week. A quick check on an iPhone 3GS shows CALayer pushes about 27fps, OpenGL does 43 fps. So much bigger win, I think we'll keep it. Sadly it doesn't fly on an iPod Gen 1 device (3.1.3) Zero clues.. It's possible of course there isn't isn't enough memory to go around, but given I've two different implementation classes I can choose the viable one at run time... On 2010-09-11, at 3:37 PM, John M McIntosh wrote: On friday night I created an open/GL renderer to work with Squeak screen updates on the iPhone/iPad. Unfortunately it runs slows than the tiled Core Animation render that I had work out earlier in the year with help from the Apple graphics engineers. So if anyone has a fair amount of knowledge about Open/GL ES maybe they could contact me and we'll see if we can improve things? -- === John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === smime.p7s Description: S/MIME cryptographic signature ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Compiling the VM for MacOSX
which is a bit sad. Because we cannot run an hudson srever to automatically build vms. I do not really understand why this would not be possible. Indeed, it would be nice to have that Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] update to OCompletion
Nevertheless, I would say that once I pressed the down arrow, my focus is to the completion, and thus enter should mean selection of the completion. +1 I totally agree on this one. We should also be able to do a mouse click on a list item. Alexandre On 12 Sep 2010, at 01:30, Francisco Ortiz Peñaloza wrote: Hi, i'm trying the latest version cause i's tired of waiting for the switch to the longer list of suggestions. But i don't understand the following change -removed enter to insert a completion am i missing something? why do u ppl make this change? Cheers, Francisco Ortiz Peñaloza On Wed, Aug 4, 2010 at 8:20 PM, Tim Mackinnon tamackin...@gmail.com wrote: I shall definitely give that a read - especially now i have an example to think back on. By the way - these chapters that people keep writing, are a great help (the monticello one certainly took away a huge load of frustrations I was having) - so thanks to everyone that keeps chipping away at them! tim On 4 Aug 2010, at 18:44, Mariano Martinez Peck wrote: I am glad I helped. You can also take a look to the Metacello draft we wrote for Pharo By Example 2. I attach it. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com Every thing has its own flow. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Updated http://isqueak.org/PlatformVMAPI
On 12 sept. 2010, at 23:47, John M McIntosh wrote: I spent a few hours this morning and updated the VM Platform API documentation at http://isqueak.org/PlatformVMAPI To capture the details of the OS-X Cocoa work. (Squeak macintosh VM 5.x) For the most part the iPhone OS-X implementation share a common Objective-C code base because Apple uses OSX as the foundation for both devices which shares most of the functionality except for the UI components. Thus for the most part I could say see iPhone implementation details. Thans John! It's really important to have an up to date documentation. Noury @ ESUG 2010 - Barcelona :-) --- 18th International Smalltalk Joint Conference, September 13 -17 2010 Barcelona, Spain. http://www.esug.org/Conferences/2010 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Update to OCompletion
Message: 17 Date: Sun, 12 Sep 2010 08:52:27 +0300 From: Tudor Girba tudor.gi...@gmail.com Subject: Re: [Pharo-project] update to OCompletion To: Pharo-project@lists.gforge.inria.fr Message-ID: 01233679-6338-49eb-8460-4952904ba...@gmail.com Content-Type: text/plain; charset=iso-8859-1 This is because when you have a line split into multiple lines, I want Enter to mean new line, not complete. This is particularly the case when you have pseudo-domain specific languages like in Glamour or Mondrian. Nevertheless, I would say that once I pressed the down arrow, my focus is to the completion, and thus enter should mean selection of the completion. Wouldn't that be somewhat inconsistent though? You can't select the first completion with enter, only from the second on. Cheers, Romain Cheers, Doru ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Update to OCompletion
Hi Romain, On 13 Sep 2010, at 11:22, Romain Robbes wrote: Message: 17 Date: Sun, 12 Sep 2010 08:52:27 +0300 From: Tudor Girba tudor.gi...@gmail.com Subject: Re: [Pharo-project] update to OCompletion To: Pharo-project@lists.gforge.inria.fr Message-ID: 01233679-6338-49eb-8460-4952904ba...@gmail.com Content-Type: text/plain; charset=iso-8859-1 This is because when you have a line split into multiple lines, I want Enter to mean new line, not complete. This is particularly the case when you have pseudo-domain specific languages like in Glamour or Mondrian. Nevertheless, I would say that once I pressed the down arrow, my focus is to the completion, and thus enter should mean selection of the completion. Wouldn't that be somewhat inconsistent though? You can't select the first completion with enter, only from the second on. Actually I was thinking of the first arrow down to just transfer the focus from the text to the completion. Thus, the first arrow down would still select the first item and enter would work there. Cheers, Doru Cheers, Romain Cheers, Doru ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com Not knowing how to do something is not an argument for how it cannot be done. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Settings for Shout syntax highlighting
Hi A new package Settings-Shout in the Pharo Inbox for issue 1611 SLICE-Issue-1611-ShoutSettings-simon_denier.1 You can now set how (for example), instance variables, selector patterns, class references appears in the Shout pane. One point is that Shout comes with a list of hundred token types which can be individually customized, some of which I have no idea what they represent (externalCallTypePointerIndicator?). To keep things manageable, I defined some groups of logically related token types (like the gorup 'selector patterns' for token types patternKeyword, patternBinary, patternUnary). Class SHGroupStyle manages settings for the Shout syntax highlighting. Token types are organized in logical groups which will share the same style. Currently, only color and emphasis can be edited through Shout settings. Text font and size are managed through the more general appearance setting. Changing a style setting on a SHGroupStyle automatically applies the style. Groups are defined in the class-side method initializeGroups. Alternatively, one can set its own style table using Shout tokens by calling #customStyleTable (see SHTextStylerST80 classdefaultStyleTable for the format). Help needed: 1) code review 2) review group definition, because I made some groups based partly on my intuition, partly on styling difference in the current difference: there may be a better partition of token types. 3) review description for group, setting organization... Thanks to Alain for helping with settings and especially polymorph widgets. -- Simon ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Settings for Shout syntax highlighting
Thanks! Stef On Sep 13, 2010, at 11:00 AM, Simon Denier wrote: Hi A new package Settings-Shout in the Pharo Inbox for issue 1611 SLICE-Issue-1611-ShoutSettings-simon_denier.1 You can now set how (for example), instance variables, selector patterns, class references appears in the Shout pane. One point is that Shout comes with a list of hundred token types which can be individually customized, some of which I have no idea what they represent (externalCallTypePointerIndicator?). To keep things manageable, I defined some groups of logically related token types (like the gorup 'selector patterns' for token types patternKeyword, patternBinary, patternUnary). Class SHGroupStyle manages settings for the Shout syntax highlighting. Token types are organized in logical groups which will share the same style. Currently, only color and emphasis can be edited through Shout settings. Text font and size are managed through the more general appearance setting. Changing a style setting on a SHGroupStyle automatically applies the style. Groups are defined in the class-side method initializeGroups. Alternatively, one can set its own style table using Shout tokens by calling #customStyleTable (see SHTextStylerST80 classdefaultStyleTable for the format). Help needed: 1) code review 2) review group definition, because I made some groups based partly on my intuition, partly on styling difference in the current difference: there may be a better partition of token types. 3) review description for group, setting organization... Thanks to Alain for helping with settings and especially polymorph widgets. -- Simon ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Cecinestpasunepomme best squeaksource package name!
Hi Cecinestpasunepomme best squeaksource package name! Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Cecinestpasunepomme best squeaksource package name!
LOL! Nice with a little Magritte humour ;-) On Mon, Sep 13, 2010 at 11:18 AM, stephane ducasse stephane.duca...@free.fr wrote: Hi Cecinestpasunepomme best squeaksource package name! Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Settings for Shout syntax highlighting
Excellent, I merged the changes into the Shout package and the existing preferences it already defined (package and setting wise). http://source.lukas-renggli.ch/unsorted Name: Shout-lr.88 Author: lr Time: 13 September 2010, 11:24:32 am UUID: 0646e300-30df-4c6f-8b5b-bd9437569194 Ancestors: Shout-lr.86 - merged the changes of simon and alain Lukas On 13 September 2010 11:02, Stéphane Ducasse stephane.duca...@inria.fr wrote: Thanks! Stef On Sep 13, 2010, at 11:00 AM, Simon Denier wrote: Hi A new package Settings-Shout in the Pharo Inbox for issue 1611 SLICE-Issue-1611-ShoutSettings-simon_denier.1 You can now set how (for example), instance variables, selector patterns, class references appears in the Shout pane. One point is that Shout comes with a list of hundred token types which can be individually customized, some of which I have no idea what they represent (externalCallTypePointerIndicator?). To keep things manageable, I defined some groups of logically related token types (like the gorup 'selector patterns' for token types patternKeyword, patternBinary, patternUnary). Class SHGroupStyle manages settings for the Shout syntax highlighting. Token types are organized in logical groups which will share the same style. Currently, only color and emphasis can be edited through Shout settings. Text font and size are managed through the more general appearance setting. Changing a style setting on a SHGroupStyle automatically applies the style. Groups are defined in the class-side method initializeGroups. Alternatively, one can set its own style table using Shout tokens by calling #customStyleTable (see SHTextStylerST80 classdefaultStyleTable for the format). Help needed: 1) code review 2) review group definition, because I made some groups based partly on my intuition, partly on styling difference in the current difference: there may be a better partition of token types. 3) review description for group, setting organization... Thanks to Alain for helping with settings and especially polymorph widgets. -- Simon ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Fwd: [Esug-list] Live Streaming ESUG 2010
Begin forwarded message: From: Marcus Denker marcus.den...@inria.fr Date: 13 septembre 2010 10:45:02 HAEC To: ESUG Mailing list esug-l...@lists.esug.org Subject: [Esug-list] Live Streaming ESUG 2019 Hi, ESUG 2010 is streamed live: http://eventv.projectescitilab.eu Second room: http://eventv.projectescitilab.eu/page3/page3.html Start of talks is announced on Twitter: http://twitter.com/esugsmalltalk Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Esug-list mailing list esug-l...@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org Noury @ ESUG 2010 - Barcelona :-) --- 18th International Smalltalk Joint Conference, September 13 -17 2010 Barcelona, Spain. http://www.esug.org/Conferences/2010 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Settings for Shout syntax highlighting
Dumb question/request: background colors? I like to choose something other than white to reduce contrast. From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Simon Denier [simon.den...@inria.fr] Sent: Monday, September 13, 2010 5:00 AM To: Pharo Development Cc: Simon Denier Subject: [Pharo-project] Settings for Shout syntax highlighting Hi A new package Settings-Shout in the Pharo Inbox for issue 1611http://code.google.com/p/pharo/issues/detail?id=1611 SLICE-Issue-1611-ShoutSettings-simon_denier.1 You can now set how (for example), instance variables, selector patterns, class references appears in the Shout pane. One point is that Shout comes with a list of hundred token types which can be individually customized, some of which I have no idea what they represent (externalCallTypePointerIndicator?). To keep things manageable, I defined some groups of logically related token types (like the gorup 'selector patterns' for token types patternKeyword, patternBinary, patternUnary). Class SHGroupStyle manages settings for the Shout syntax highlighting. Token types are organized in logical groups which will share the same style. Currently, only color and emphasis can be edited through Shout settings. Text font and size are managed through the more general appearance setting. Changing a style setting on a SHGroupStyle automatically applies the style. Groups are defined in the class-side method initializeGroups. Alternatively, one can set its own style table using Shout tokens by calling #customStyleTable (see SHTextStylerST80 classdefaultStyleTable for the format). Help needed: 1) code review 2) review group definition, because I made some groups based partly on my intuition, partly on styling difference in the current difference: there may be a better partition of token types. 3) review description for group, setting organization... Thanks to Alain for helping with settings and especially polymorph widgets. -- Simon ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Compiler throws error in Gemstone, not in Pharo
Dear list, while testing between Pharo and Gemstone I've noticed that Pharo allows following code, while Gemstone does not. renderSelectorAndReturnBrushForSelector: aSelector. ^canvas textInput id: (self idForSelector: aSelector); value: (self inputValueForSelector: aSelector); script: (canvas jQuery new datepicker); yourself The error is that in the message definition: renderSelectorAndReturnBrushForSelector: aSelector. there is a dot on the end. This seems like an error in the Pharo compiler ? or not? Kind Regards, Bart ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Compiler throws error in Gemstone, not in Pharo
2010/9/13 Bart Gauquie bart.gauq...@gmail.com: The error is that in the message definition: renderSelectorAndReturnBrushForSelector: aSelector. there is a dot on the end. This seems like an error in the Pharo compiler ? or not? Actually Johan Brichau just mentioned this during his talk this morning. Gemstone's compiler is stricter than Pharo's. It's not really a bug that the parser in Pharo is more persmissive, but it's an inconvenience indeed. -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Improving generate accessors for refactoring browser
i would like that too On Sep 12, 2010 7:27 PM, Bart Gauquie bart.gauq...@gmail.com wrote: Dear list, I've noticed that when I'm using the generate accessors refactoring, I'm always adapting the generated code for the mutator: number: anObject number := anObject to: number: aNumber number := aNumber So I've adapted the refactoring code a bit so that it automatically generates this correctly. Anybody also thinks this is useful? If so, I will create a bug/improvement and a slice for it. Kind regards, Bart ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Compiler throws error in Gemstone, not in Pharo
Yes but what is wrong on gemstone. Stef Dear list, while testing between Pharo and Gemstone I've noticed that Pharo allows following code, while Gemstone does not. renderSelectorAndReturnBrushForSelector: aSelector. ^canvas textInput id: (self idForSelector: aSelector); value: (self inputValueForSelector: aSelector); script: (canvas jQuery new datepicker); yourself The error is that in the message definition: renderSelectorAndReturnBrushForSelector: aSelector. there is a dot on the end. This seems like an error in the Pharo compiler ? or not? Kind Regards, Bart ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Improving generate accessors for refactoring browser
How you derive the type? From the method name? I think only very few accessors/inst-vars are named after the type. Also note that you can edit the type directly in the changes browser before you install it, that's what I typically do. Lukas 2010/9/13 Mariano Martinez Peck marianop...@gmail.com: i would like that too On Sep 12, 2010 7:27 PM, Bart Gauquie bart.gauq...@gmail.com wrote: Dear list, I've noticed that when I'm using the generate accessors refactoring, I'm always adapting the generated code for the mutator: number: anObject number := anObject to: number: aNumber number := aNumber So I've adapted the refactoring code a bit so that it automatically generates this correctly. Anybody also thinks this is useful? If so, I will create a bug/improvement and a slice for it. Kind regards, Bart ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.2] #12141
12141 - - Issue 2955: some settings simplification + fixes. Thanks Alain Plantec Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] One order of magnitude faster sets/dicts?!
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 1. 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 Do0.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 Do0.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 Remove0.008 +/-0.018 Add 0.845 +/-0.039 AddExisting 0.310 +/-0.021 AddNew0.240 +/-0.021 Includes 0.365 +/-0.024 Set: 70.9 +/-1.2 Remove7.737 +/-0.051 Add 0.755 +/-0.022 AddExisting 0.305 +/-0.015 AddNew2.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
Re: [Pharo-project] Improving generate accessors for refactoring browser
El lun, 13-09-2010 a las 14:02 +0200, Lukas Renggli escribió: How you derive the type? I think it only uses the name of the inst var to name the parameter var in the accessor. From the method name? I think only very few accessors/inst-vars are named after the type. Also note that you can edit the type directly in the changes browser before you install it, that's what I typically do. Lukas 2010/9/13 Mariano Martinez Peck marianop...@gmail.com: i would like that too On Sep 12, 2010 7:27 PM, Bart Gauquie bart.gauq...@gmail.com wrote: Dear list, I've noticed that when I'm using the generate accessors refactoring, I'm always adapting the generated code for the mutator: number: anObject number := anObject to: number: aNumber number := aNumber So I've adapted the refactoring code a bit so that it automatically generates this correctly. Anybody also thinks this is useful? If so, I will create a bug/improvement and a slice for it. Kind regards, Bart ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel Cobá http://miguel.leugim.com.mx ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] One order of magnitude faster sets/dicts?!
On Mon, 13 Sep 2010, Adrian Lienhard wrote: 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 1. 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 Do0.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 Do0.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 Remove0.008 +/-0.018 Add 0.845 +/-0.039 AddExisting 0.310 +/-0.021 AddNew0.240 +/-0.021 Includes 0.365 +/-0.024 Set: 70.9 +/-1.2 Remove7.737 +/-0.051 Add 0.755 +/-0.022 AddExisting 0.305 +/-0.015 AddNew2.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. I'm a bit skeptic, because 10x improvement is pretty hard to get if the benchmark is not flawed and the code doesn't use VM support. I wonder what the #pPrimitive:plugin: pragmas stand for in PDictionary's #at:ifAbsent: and #at:put:. Where can I find the benchmark code? 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? The current HashedCollections don't shrink. Remove is a rarely used operation. 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
Re: [Pharo-project] One order of magnitude faster sets/dicts?!
do you know if they compare with squeak because levent did a lot of work in that area. Stef On Sep 13, 2010, at 2:55 PM, Adrian Lienhard wrote: 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 1. 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 Do0.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 Do0.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 Remove0.008 +/-0.018 Add 0.845 +/-0.039 AddExisting 0.310 +/-0.021 AddNew0.240 +/-0.021 Includes 0.365 +/-0.024 Set: 70.9 +/-1.2 Remove7.737 +/-0.051 Add 0.755 +/-0.022 AddExisting 0.305 +/-0.015 AddNew2.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
Re: [Pharo-project] Improving generate accessors for refactoring browser
don't use the type, i only uses the name of the parameter var to derive the name of parameter 2010/9/13 Miguel Enrique Cobá Martínez miguel.c...@gmail.com El lun, 13-09-2010 a las 14:02 +0200, Lukas Renggli escribió: How you derive the type? I think it only uses the name of the inst var to name the parameter var in the accessor. From the method name? I think only very few accessors/inst-vars are named after the type. Also note that you can edit the type directly in the changes browser before you install it, that's what I typically do. Lukas 2010/9/13 Mariano Martinez Peck marianop...@gmail.com: i would like that too On Sep 12, 2010 7:27 PM, Bart Gauquie bart.gauq...@gmail.com wrote: Dear list, I've noticed that when I'm using the generate accessors refactoring, I'm always adapting the generated code for the mutator: number: anObject number := anObject to: number: aNumber number := aNumber So I've adapted the refactoring code a bit so that it automatically generates this correctly. Anybody also thinks this is useful? If so, I will create a bug/improvement and a slice for it. Kind regards, Bart ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel Cobá http://miguel.leugim.com.mx ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- imagination is more important than knowledge - Albert Einstein Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein The true sign of intelligence is not knowledge but imagination. - Albert Einstein However beautiful the strategy, you should occasionally look at the results. - Sir Winston Churchill It's not enough that we do our best; sometimes we have to do what's required. - Sir Winston Churchill ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Compiler throws error in Gemstone, not in Pharo
What's the dot doing after 'aSelector' ? :-) it's an empty statement - gs parser does not allow that btw, I think this is a rule in code critic, so if you launch that, you will get all these problems before trying to load them into GS On 13 Sep 2010, at 13:55, Stéphane Ducasse wrote: Yes but what is wrong on gemstone. Stef Dear list, while testing between Pharo and Gemstone I've noticed that Pharo allows following code, while Gemstone does not. renderSelectorAndReturnBrushForSelector: aSelector. ^canvas textInput id: (self idForSelector: aSelector); value: (self inputValueForSelector: aSelector); script: (canvas jQuery new datepicker); yourself The error is that in the message definition: renderSelectorAndReturnBrushForSelector: aSelector. there is a dot on the end. This seems like an error in the Pharo compiler ? or not? Kind Regards, Bart ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] One order of magnitude faster sets/dicts?!
No, they just compared to Pharo 1.1. But the benchmarks are available in a separate package. Adrian On Sep 13, 2010, at 15:52 , Stéphane Ducasse wrote: do you know if they compare with squeak because levent did a lot of work in that area. Stef On Sep 13, 2010, at 2:55 PM, Adrian Lienhard wrote: 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 1. 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 Do0.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 Do0.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 Remove0.008 +/-0.018 Add 0.845 +/-0.039 AddExisting 0.310 +/-0.021 AddNew0.240 +/-0.021 Includes 0.365 +/-0.024 Set: 70.9 +/-1.2 Remove7.737 +/-0.051 Add 0.755 +/-0.022 AddExisting 0.305 +/-0.015 AddNew2.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
Re: [Pharo-project] Improving generate accessors for refactoring browser
In my image only 9% of the accessors follow this pattern. Lukas 2010/9/13 Bart Gauquie bart.gauq...@gmail.com: don't use the type, i only uses the name of the parameter var to derive the name of parameter 2010/9/13 Miguel Enrique Cobá Martínez miguel.c...@gmail.com El lun, 13-09-2010 a las 14:02 +0200, Lukas Renggli escribió: How you derive the type? I think it only uses the name of the inst var to name the parameter var in the accessor. From the method name? I think only very few accessors/inst-vars are named after the type. Also note that you can edit the type directly in the changes browser before you install it, that's what I typically do. Lukas 2010/9/13 Mariano Martinez Peck marianop...@gmail.com: i would like that too On Sep 12, 2010 7:27 PM, Bart Gauquie bart.gauq...@gmail.com wrote: Dear list, I've noticed that when I'm using the generate accessors refactoring, I'm always adapting the generated code for the mutator: number: anObject number := anObject to: number: aNumber number := aNumber So I've adapted the refactoring code a bit so that it automatically generates this correctly. Anybody also thinks this is useful? If so, I will create a bug/improvement and a slice for it. Kind regards, Bart ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel Cobá http://miguel.leugim.com.mx ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- imagination is more important than knowledge - Albert Einstein Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein The true sign of intelligence is not knowledge but imagination. - Albert Einstein However beautiful the strategy, you should occasionally look at the results. - Sir Winston Churchill It's not enough that we do our best; sometimes we have to do what's required. - Sir Winston Churchill ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Compiler throws error in Gemstone, not in Pharo
it's an empty statement - gs parser does not allow that btw, I think this is a rule in code critic, so if you launch that, you will get all these problems before trying to load them into GS Yes, Slime detects these kind of syntactic problems that impact portability. Lukas -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Compiling the VM for MacOSX
Yup, much clearer now. Thanks John! Alexandre On 11 Sep 2010, at 19:11, John M McIntosh wrote: On 2010-09-11, at 7:42 AM, Alexandre Bergel wrote: If you want a fast vm i recommend to compile in deployment, but that take more time. How do I compile in deployment? By inspecting the project and selecting the Build tab? Ok, there is a bit of learning that has to take place since I'm going to assume if you want to build your own VM, then you should be familiar with XCode, otherwise you should just use the pre-built binaries. The Build tab you refer to lets you change the compile, link, deployment settings. In the Menu Bar the Project menu has Set Active... to let you choose which project to build and the type, etc... Cheers, Alexandre -- === John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Improving generate accessors for refactoring browser
which pattern? I thought we were discussing about the default... :S I think that anObject is an ugly default, yes. I prefere to have niceSarasa: aNiceSarasa niceSarasa := aNiceSarasa than niceSarasa: anObject niceSarasa := anObject Obviously, these are useful only when we autogenerate the accesors :). If I have to modify every accesor I autogenerate, it's like not autogenerating it :). BTW, I never use that refactor :P. Cheers! On Mon, Sep 13, 2010 at 11:16 AM, Lukas Renggli reng...@gmail.com wrote: In my image only 9% of the accessors follow this pattern. Lukas 2010/9/13 Bart Gauquie bart.gauq...@gmail.com: don't use the type, i only uses the name of the parameter var to derive the name of parameter 2010/9/13 Miguel Enrique Cobá Martínez miguel.c...@gmail.com El lun, 13-09-2010 a las 14:02 +0200, Lukas Renggli escribió: How you derive the type? I think it only uses the name of the inst var to name the parameter var in the accessor. From the method name? I think only very few accessors/inst-vars are named after the type. Also note that you can edit the type directly in the changes browser before you install it, that's what I typically do. Lukas 2010/9/13 Mariano Martinez Peck marianop...@gmail.com: i would like that too On Sep 12, 2010 7:27 PM, Bart Gauquie bart.gauq...@gmail.com wrote: Dear list, I've noticed that when I'm using the generate accessors refactoring, I'm always adapting the generated code for the mutator: number: anObject number := anObject to: number: aNumber number := aNumber So I've adapted the refactoring code a bit so that it automatically generates this correctly. Anybody also thinks this is useful? If so, I will create a bug/improvement and a slice for it. Kind regards, Bart ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel Cobá http://miguel.leugim.com.mx ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- imagination is more important than knowledge - Albert Einstein Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein The true sign of intelligence is not knowledge but imagination. - Albert Einstein However beautiful the strategy, you should occasionally look at the results. - Sir Winston Churchill It's not enough that we do our best; sometimes we have to do what's required. - Sir Winston Churchill ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Compiler throws error in Gemstone, not in Pharo
ah yes an empty statement. Ugly we cleaned a lot of .. in the past I hope that Opal will fix that On Sep 13, 2010, at 4:07 PM, Johan Brichau wrote: What's the dot doing after 'aSelector' ? :-) it's an empty statement - gs parser does not allow that btw, I think this is a rule in code critic, so if you launch that, you will get all these problems before trying to load them into GS On 13 Sep 2010, at 13:55, Stéphane Ducasse wrote: Yes but what is wrong on gemstone. Stef Dear list, while testing between Pharo and Gemstone I've noticed that Pharo allows following code, while Gemstone does not. renderSelectorAndReturnBrushForSelector: aSelector. ^canvas textInput id: (self idForSelector: aSelector); value: (self inputValueForSelector: aSelector); script: (canvas jQuery new datepicker); yourself The error is that in the message definition: renderSelectorAndReturnBrushForSelector: aSelector. there is a dot on the end. This seems like an error in the Pharo compiler ? or not? Kind Regards, Bart ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update 1.2] #12141
Don't load here, I get an UndefinedObject(Object)doesNotUnderstand: #format: Cheers. 2010/9/13 Stéphane Ducasse stephane.duca...@inria.fr: 12141 - - Issue 2955: some settings simplification + fixes. Thanks Alain Plantec Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- = Germán S. Arduino gsa @ arsol.net Twitter: garduino Arduino Software Web Hosting http://www.arduinosoftware.com PasswordsPro http://www.passwordspro.com = ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Fwd: [Esug-list] Live Streaming ESUG 2010
Nice to be able to attend vicariously! Thanks. Regards, Gary - Original Message - From: Noury Bouraqadi bouraq...@gmail.com To: Pharo Development pharo-project@lists.gforge.inria.fr; Squeak-dev developers list general-purpose Squeak squeak-...@lists.squeakfoundation.org; VisualWorks NC v...@cs.uiuc.edu Sent: Monday, September 13, 2010 10:49 AM Subject: [Pharo-project] Fwd: [Esug-list] Live Streaming ESUG 2010 Begin forwarded message: From: Marcus Denker marcus.den...@inria.fr Date: 13 septembre 2010 10:45:02 HAEC To: ESUG Mailing list esug-l...@lists.esug.org Subject: [Esug-list] Live Streaming ESUG 2019 Hi, ESUG 2010 is streamed live: http://eventv.projectescitilab.eu Second room: http://eventv.projectescitilab.eu/page3/page3.html Start of talks is announced on Twitter: http://twitter.com/esugsmalltalk Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Esug-list mailing list esug-l...@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org Noury @ ESUG 2010 - Barcelona :-) --- 18th International Smalltalk Joint Conference, September 13 -17 2010 Barcelona, Spain. http://www.esug.org/Conferences/2010 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] One order of magnitude faster sets/dicts?!
On Mon, 13 Sep 2010, Levente Uzonyi wrote: On Mon, 13 Sep 2010, Adrian Lienhard wrote: 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 1. 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 Do0.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 Do0.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 Remove0.008 +/-0.018 Add 0.845 +/-0.039 AddExisting 0.310 +/-0.021 AddNew0.240 +/-0.021 Includes 0.365 +/-0.024 Set: 70.9 +/-1.2 Remove7.737 +/-0.051 Add 0.755 +/-0.022 AddExisting 0.305 +/-0.015 AddNew2.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. I'm a bit skeptic, because 10x improvement is pretty hard to get if the benchmark is not flawed and the code doesn't use VM support. Okay, I found the benchmark code, and it's flawed. The distribution of the keys is not uniform. Actually it's far from uniform, it's just 1..dictSize. Anyway I ran the benchmarks in Squeak 4.2 alpha and got the following results: PBDictionary: 0.1249 +/-0.0067 RemoveKey 6.7e-500 +/-4.6e-5 AtPutNew 0.0648 +/-0.0048 Do 0.00160 +/-0.0001 AtPutExisting 0.003302 +/-0.00018 AtIfAbsentPut 0.0192 +/-0.0035 AtPut 0.015570001 +/-0.00028 IncludesKey 0.0180 +/-0.0029 KeysAndValuesDo 0.00223 +/-0.0001201 Includes 0.000133 +/-6.3e-5 PBSTDictionary: 0.2204 +/-0.0063 RemoveKey 0.07203 +/-0.00032 AtPutNew 0.0434 +/-0.0055 Do 0.00 +/-0.0 AtPutExisting 0.00260 +/-0.00013 AtIfAbsentPut 0.01193 +/-0.0002 AtPut 0.0147 +/-0.0031 IncludesKey 0.011570001 +/-0.0002401 KeysAndValuesDo 0.002200 +/-7.4e-5 Includes 0.05993 +/-0.00019 The PDictionary is only better at 2 benchmarks: Includes (not IncludesKey!) and RemoveKey which are both rarely used. In all other tests Squeak's Dictionary implementation is faster in this flawed benchmark. Levente I wonder what the #pPrimitive:plugin: pragmas stand for in PDictionary's #at:ifAbsent: and #at:put:. Where can I find the benchmark code? 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? The current HashedCollections don't shrink. Remove is a rarely used operation. 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,
Re: [Pharo-project] Settings for Shout syntax highlighting
I thought that too, but I was told there was a relevant style - I've never found it. From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Simon Denier [simon.den...@inria.fr] Sent: Monday, September 13, 2010 11:24 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Settings for Shout syntax highlighting On 13 sept. 2010, at 13:06, Schwab,Wilhelm K wrote: Dumb question/request: background colors? I like to choose something other than white to reduce contrast. mmm, actually I'm not sure what you mean. Shout highlights tokens in a text pane, I guess you don't want to change the background color for each token, but rather change the background for the whole editor pane. It should be a setting of the editor, or even a different Theme, but I can't tell much more. From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Simon Denier [simon.den...@inria.fr] Sent: Monday, September 13, 2010 5:00 AM To: Pharo Development Cc: Simon Denier Subject: [Pharo-project] Settings for Shout syntax highlighting Hi A new package Settings-Shout in the Pharo Inbox for issue 1611http://code.google.com/p/pharo/issues/detail?id=1611 SLICE-Issue-1611-ShoutSettings-simon_denier.1 You can now set how (for example), instance variables, selector patterns, class references appears in the Shout pane. One point is that Shout comes with a list of hundred token types which can be individually customized, some of which I have no idea what they represent (externalCallTypePointerIndicator?). To keep things manageable, I defined some groups of logically related token types (like the gorup 'selector patterns' for token types patternKeyword, patternBinary, patternUnary). Class SHGroupStyle manages settings for the Shout syntax highlighting. Token types are organized in logical groups which will share the same style. Currently, only color and emphasis can be edited through Shout settings. Text font and size are managed through the more general appearance setting. Changing a style setting on a SHGroupStyle automatically applies the style. Groups are defined in the class-side method initializeGroups. Alternatively, one can set its own style table using Shout tokens by calling #customStyleTable (see SHTextStylerST80 classdefaultStyleTable for the format). Help needed: 1) code review 2) review group definition, because I made some groups based partly on my intuition, partly on styling difference in the current difference: there may be a better partition of token types. 3) review description for group, setting organization... Thanks to Alain for helping with settings and especially polymorph widgets. -- Simon ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Simon ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About CodeMorph and Styler dependency
Stéphane Ducasse wrote: Name: Morphic-FernandoOlivero.589 Rethought the CodeMorph class hierarchy, removed the subclasses and added CodeMorph class methods for creatingMethodMorph and ClassDefinitionMorph Fixed now. CodeMorph is still broken in 1.2-12123. There doesn't seem to be a way to accept changes to the code. There is the orange unsaved triangle, but cmd-s (Mac) and self accept do not save the edits. Try: m := CodeMorph codeOf: ( Object Object selectors anyOne ). m openInWorld; borderWidth: 10; margin:10; borderColor: Color lightGray; fitToParagraph; width: 300. Sean -- View this message in context: http://forum.world.st/TextEditor-and-NewTextMorph-merges-and-fixes-tp2219629p2538214.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Extension Methods
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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [squeak-dev] Re: Squeak VM on iPad/IPhone gets open/GL rendering
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 john...@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === smime.p7s Description: S/MIME cryptographic signature ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
