February 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] [COTDC] 17 - MCSnapshotReader
by laurent laffont Feb. 23, 2011

Feb. 23, 2011

Today: MCSnapshotReader Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest Laurent

3 5

[Pharo-project] [update 1.3] #13062
by laurent laffont Feb. 23, 2011

Feb. 23, 2011

13062 ----- COTDC: - 9. HTTPDownloadRequest - L.Laffont - 10. DummyUIManager - L.Laffont - 11. ColorMappingCanvas - I.Stasenko, L.Laffont - 12. PluggableListMorphByItem - G.Chambers - 13. NullEncoder - I.Stasenko - 14. MCSnapshotReader - H.Johansen - 15. PSMCPatchMorph - G.Polito - 16. GoferReinitialize - L.Renggli Laurent

2 1

[Pharo-project] Issue 3748 in pharo: The Dark Side of Pharo: Keyboard Inputs
by pharo＠googlecode.com Feb. 23, 2011

Feb. 23, 2011

Status: New Owner: ---- New issue 3748 by camillob...(a)gmail.com: The Dark Side of Pharo: Keyboard Inputs http://code.google.com/p/pharo/issues/detail?id=3748 It seems that handling keyboard events is more or less random in pharo. These are the properties of the KeyboardEvent for different inputs under OSX: Cmd-home: [keystroke '<Cmd-home>'] keyVal=1 keyCode=1 scanCode=115 buttons=64 cmd=true ctrl=false Ctrl-home: [keystroke '<Cmd-home>'] keyVal=97 keyCode=1 scanCode=115 buttons=64 cmd=true ctrl=false ??? Cmd-a: [keystroke '<Cmd-a>'] keyVal=97 keyCode=97 scanCode=0 buttons=64 cmd=true ctrl=false Ctrl-a: [keystroke '<Cmd-home>'] keyVal=97 keyCode=1 scanCode=0 buttons=64 cmd=true ctrl=false ??? Alt-a: [keystroke '<Opt-Ã¥>'] keyVal=140 keyCode=229 scanCode=0 buttons=32 cmd=false ctrl=false Under Ubuntu: Cmd-home: NOT WORKING! (maybe virtualbox issues...) Ctrl-home: [keystroke '<Cmd-home>'] keyVal=97 keyCode=1 scanCode=97 buttons=64 cmd=true ctrl=false Cmd-a: NOT WORKING! (maybe virtualbox issues...) Ctrl-a: [keystroke '<Cmd-a>'] keyVal=97 keyCode=97 scanCode=97 buttons=64 cmd=true ctrl=false Alt-a: [keystroke '<Cmd-a>'] keyVal=97 keyCode=97 scanCode=97 buttons=64 cmd=true ctrl=false ??? Under Windose: Cmd-home: NOT WORKING! (maybe virtualbox issues...) Ctrl-home: [keystroke '<Cmd-home>'] keyVal=97 keyCode=1 scanCode=97 buttons=64 cmd=true ctrl=false Cmd-a: NOT WORKING! (maybe virtualbox issues...) Ctrl-a: [keystroke '<Cmd-home>'] keyVal=97 keyCode=1 scanCode=65 buttons=64 cmd=true ctrl=false??? Alt-a: [keystroke '<Cmd-a>'] keyVal=97 keyCode=97 scanCode=65 buttons=64 cmd=true ctrl=false ??? ---- I am your father Luke! ---- Several problems can be identified here: 1. There is no clear platform distinction between cmd and ctrl 2. missing support for meta (command under OSX) and alt under win/unix prohibits extended shortcuts 3. unification of different keyboard events under the same platform. which is undone for instance for ctrl-a and cmd-a under OSX select the whole text, although the input keyboardEvent shows no distinction in ctrlKeyPressed and cmdKeyPressed! Fix requires several steps: 1. fix the VM to forward clearly distinct keyboard events for ctrl and meta/command and alt 2. Unify the keyboard inputs on all three platforms, the inputs right now are unbearable and obey to obscure rules! 3. adapt the UI keyboard event handling to not rely on the internals of the keyboard event but a nice API 4. provide system dependent firstCommandKeyPressed and secondCommandKeyPressed in order to avoid the following ugly checks all over the system (aKeyboardEvent commandKeyPressed and: [ aKeyboardEvent controlKeyPressed ]) ---- may the force be with you ----

2 2

[Pharo-project] XMLWriter question
by StÃ©phane Ducasse Feb. 23, 2011

Feb. 23, 2011

Hi guys I have a question about XMLWriter. I have cards and group of cards. Each class know how to serialize itself. For card I have xmlOn: (one of my methods) that describes the card attributes Card>>xmlOn: aWriter "write a description of the receiver properties as xml uing aWriter, an instance of XMLWriter" aWriter tag name: #card; with: [self xmlInstVarOn: aWriter] Group>>xmlOn: aWriter "write a description of the receiver properties as xml uing aWriter, an instance of XMLWriter" | cardWriter | cardWriter := XMLWriter new. cards do: [:each | each xmlOn: cardWriter]. aWriter tag name: #group; with: [ aWriter tag: #groupName with: self groupName. aWriter tag: #cards with: [ aWriter raw: cardWriter contents]] And I'm not really happy. Because I would like to avoid to use raw: and instantiate a new writer. I would like to know how I could use the write to pass the results of the iteration over cards I wanted to write something like aWriter tag name: #group; with: [ aWriter tag: #groupName with: self groupName. aWriter tag: #cards with: [self cards do: [:each | each xmlOn: aWriter]]

2 1

[Pharo-project] XML browser
by laurent laffont Feb. 23, 2011

Feb. 23, 2011

As I haven't found something to browse XML the way I want, I've written a little tool: http://magaloma.blogspot.com/2011/02/xml-browser-with-pharo.html If there's already a good tool please tell me. Laurent Laffont - @lolgzs <http://twitter.com/#!/lolgzs> Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/

2 1

[Pharo-project] Accessing OS windows within smalltalk VM
by Nathan Tuttle Feb. 23, 2011

Feb. 23, 2011

Is it possible to access operating system windows (screen captures) in pharo. Since this would be OS specific does anyone know of a primitive plugin that would allow this?

3 2

[Pharo-project] Pattern for reifying XML doc?
by stephane ducasse Feb. 22, 2011

Feb. 22, 2011

Hi guys I often encounter the following situation: I have an xmldoc and I want to load it and get the corresponding objects. Here is an example <group> <groupName>Test2Cards</groupName> <cards><card> <cardName>All Is Dust</cardName> <manaCost>7</manaCost> <convertedManaCost>7</convertedManaCost> <type>Tribal Sorcery â Eldrazi</type> <cardText>Each player sacrifices all colored permanents he or she controls.</cardText> <rarity>mythic</rarity> <cardNumber>1</cardNumber> <artist>Jason Felix</artist> <kind>STD</kind> <expansionId>ELDRAZI</expansionId> </card> <card> <cardName>Kird Ape</cardName> <manaCost>G</manaCost> <convertedManaCost>1</convertedManaCost> <type>Tribal Sorcery â Eldrazi</type> <cardText>get +1/+1 when you control</cardText> <rarity>common</rarity> <cardNumber>33</cardNumber> <artist>Zork</artist> <kind>STD</kind> <expansionId>WORLDWAKE</expansionId> </card></cards> </group> I have card and group. But I could have several kind of nodes. So I was wondering if there are patterns to read in and map that to objects. In the future I would like to have magritte like type of first class instance variables that perform i/o in xml or other formats because this is always the same. stef

6 8

[Pharo-project] Cog VM -- Thanks and Performance / Optimization Questions
by John B Thiel Feb. 22, 2011

Feb. 22, 2011

Cog VM -- Thanks and Performance / Optimization Questions To Everyone, thanks for your great work on Pharo and Squeak, and to Eliot Miranda, Ian Piumarta, and all VM/JIT gurus, especially thanks for the Squeak VM Cog and its precursors, which I was keenly anticipating for a decade or so, and is really going into stride with the latest builds. I like to code with awareness of performance issues. Can you tell or point me to some performance and efficiency tips for Cog and the Squeak compiler -- detail on which methods are inlined, best among alternatives, etc. For example, I understand #to:do: is inlined -- what about #to:do:by: and #timesRepeat and #repeat ? Basically, I would like to read a full overview of which core methods are specially optimized (or planned). I know about the list of NoLookup primitives, as per Object class>>howToModifyPrimitives, supposing that is still valid? What do you think is a reasonable speed factor for number-crunching Squeak code vs C ? I am seeing about 20x slower in the semi-large scale, which surprised me a bit because I got about 10x on smaller tests, and a simple fib: with beautiful Cog is now about 3x (wow!). That range, 3x tiny tight loop, to 20x for general multi-class computation, seems a bit wide -- is it about expected? My profiling does not reveal any hotspots, as such -- it's basically 2, 3, 5% scattered around, so I envision this is just the general vm/jit overhead as you scale up -- referencing distant objects, slots, dispatch lookups, more cache misses, etc. But maybe I am generally using some backwater loop/control methods, techniques, etc. that could be tuned up. e.g. I seem to recall a trace at some point showing #timesRepeat taking 10% of the time (?!). Also, I recall reading about an anomaly with BlockClosures -- something like being rebuilt every time thru the loop - has that been fixed? Any other gotchas to watch for currently? (Also, any notoriously slow subsystems? For example, Transcript writing is glacial.) The Squeak bytecode compiler looks fairly straightforward and non-optimizing - just statement by statement translation. So it misses e.g. chances to store and reuse, instead of pop, etc. I see lots of redundant sequences emitted. Are those kind of things now optimized out by Cog, or would tighter bytecode be another potential optimization path. (Is that what the Opal project is targetting?) -- jbthiel

9 13

[Pharo-project] Decimal comma
by John Toohey Feb. 22, 2011

Feb. 22, 2011

Without changing the OS locale, is there an easy was to have Pharo recognize a comma as a decimal point, i.e. '2,13' asNumber -> 2,13. I am receiving number from a Seaside app, in this format, and I need to convert them before storing them in Postgres. Currently '2,12' asNumber gives 2. -- ~JT

2 3

[Pharo-project] Cobol is the new language to know?
by Geert Claes Feb. 22, 2011

Feb. 22, 2011

I just cringed when I read: "The Sydney-based Object Consulting has released a paper detailing those languages which will no longer be supported in the near future, including the likes of .NET 2.0, J2SE 1.4 and Cold Fusion (according to Object Consulting they have a three-year shelf life), while anything on Smalltalk or FoxPro should be junked or moved to a new system immediately as a result of non-support and no further development of the environments." http://www.channelregister.co.uk/2011/02/20/cobol_is_the_new_language_to_kn… http://www.channelregister.co.uk/2011/02/20/cobol_is_the_new_language_to_kn… -- View this message in context: http://forum.world.st/Cobol-is-the-new-language-to-know-tp3317188p3317188.h… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

5 11