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

Re: [Pharo-project] Issue 3703 in pharo: cogitClass / interpreterClass

by pharo＠googlecode.com

Updates: Status: Closed Comment #1 on issue 3703 by stephane...(a)gmail.com: cogitClass / interpreterClass http://code.google.com/p/pharo/issues/detail?id=3703 Alexander Lazarević uploaded a new version of System to project The Trunk: http://source.squeak.org/trunk/System-laza.420.mcz ==================== Summary ==================== Name: System-laza.420 Author: laza Time: 8 February 2011, 11:46:58.466 am UUID: e6f5183c-6a98-764c-b348-b52e9e9a69de Ancestors: System-ul.419 Add system attributes 1007 and 1008 for Cog VMs =============== Diff against System-ul.419 =============== Item was added: + ----- Method: SmalltalkImage>>cogitClass (in category 'vm') ----- + cogitClass + ^self getSystemAttribute: 1008! Item was changed: ----- Method: SmalltalkImage>>getSystemAttribute: (in category 'private') ----- getSystemAttribute: attributeID "Optional. Answer the string for the system attribute with the given integer ID. Answer nil if the given attribute is not defined on this platform. On platforms that support invoking programs from command lines (e.g., Unix), this mechanism can be used to pass command line arguments to programs written in Squeak. By convention, the first command line argument that is not a VM configuration option is considered a 'document' to be filed in. Such a document can add methods and classes, can contain a serialized object, can include code to be executed, or any combination of these. Currently defined attributes include: -1000 1000th command line argument that specify VM options ... -1 first command line argument that specify VM options 0 the full path name for currently executing VM (or, on some platforms, just the path name of the VM's directory) 1 full path name of this image (better use primImageName instead) 2 a Squeak document to open, if any 3 first command line argument for Squeak programs ... 1000 1000th command line argument for Squeak programs 1001 this platform's operating system 'Mac OS', 'Win32', 'unix', ... 1002 operating system version 1003 this platform's processor type 1004 vm version 1005 window system name 1006 vm build id + 1007 Interpreter class (Cog VM only) + 1008 Cogit class (Cog VM only) 1201 always returns 255 (Mac OS only) 1202 file last error (Mac OS only) 10001 hardware details (Win32 only) 10002 operating system details (Win32 only) 10003 graphics hardware details (Win32 only) " <primitive: 149> ^ nil! Item was added: + ----- Method: SmalltalkImage>>interpreterClass (in category 'vm') ----- + interpreterClass + ^self getSystemAttribute: 1007!

Feb. 14, 2011

[Pharo-project] Issue 3703 in pharo: cogitClass / interpreterClass

by pharo＠googlecode.com

Status: Fixed Owner: stephane...(a)gmail.com Labels: Milestone-1.3 New issue 3703 by stephane...(a)gmail.com: cogitClass / interpreterClass http://code.google.com/p/pharo/issues/detail?id=3703 add these two methods

Feb. 14, 2011

Re: [Pharo-project] A new GUI visual designer

by Igor Stasenko

On 14 February 2011 09:59, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > Hi GÃ¶ran, > > On 14 Feb 2011, at 00:18, GÃ¶ran Krampe wrote: > >> Hi! >> >> Sorry, this post turned out long. But hopefully interesting anyway. >> >> On 02/13/2011 06:36 PM, Schwab,Wilhelm K wrote: >>> You cite an example very similar to what Dolphin does, and we could do with SIXX. >> > Dolphin serializes things not to avoid the image but to allow packaging. >> > SIXX could do the same for us. >> [SNIP] >> >> > If we had something that could read and rewrite Smalltalk code that is truly independent >> > of WB, then class methods would be nice way to store GUI designs. >>> >>> Bill >> >> Just wanted to chip in here - IMHO there is a loooong history when it comes to how to "save" UIs. We have seen (and in many different programming languages) various ways through the years: >> >> - Build them with code each time we want them >> Â Â Â Pros: Â Resilient against framework/library changes >> Â Â Â Â Â Â Â Very readable and editable >> Â Â Â Â Â Â Â Easy to "store" in the language (just save as a method) >> Â Â Â Cons: Â Very hard to use as a "save format" >> Â Â Â Â Â Â Â Has too much freedom if we hand edit it >> >> I actually favor the above since I normally dislike UI Designer tools :). But I can of course see the value of a really good UI designer (WB Pro is one of the best I have ever used, and the one in VisualAge was also superb). >> >> - Save them in "dumb" data structures (like VW specs) >> Â Â Â Pros: Â A bit resilient since it relies on a builder, but not as good as code because it is just dumb data >> Â Â Â Â Â Â Â Similar easy to store in the language >> Â Â Â Cons: Â Not readable and editable >> >> VW has used this for a long time and it is indeed pretty slick since you just "store" it in a method. That is one very nice characteristic, and if you have good options to dig into the builder after it has read the spec - then having the spec be "non readable/editable" is not that painful. But still, it is a bit of a serialization hack and ... doesn't feel quite right. >> >> >> - Save them in a more advanced (than an Array) non Smalltalk langauge like XML >> Â Â Â Pros: Â Quite resilient against framework/library changes, if grammar is made to be declarative in style >> Â Â Â Â Â Â Â Easy to use as "save format" >> Â Â Â Cons: Â Get's complex and icky >> Â Â Â Â Â Â Â Not so easy to "store" in language (a String literal?) >> Â Â Â Â Â Â Â Not so readable and editable >> >> IMHO using XML is "nice" (well...) for inter system and inter language communications/interchange. But realistically, how much interplay can we expect when we are talking about Morphic UIs? AFAIK the rest of the world haven't been able to gather around a single format either. If there indeed was a format that all the Gtk/Qts and whatnots out there used - then by all means. But is there? >> >> >> - Serialize (in binary or whatever language like XML etc) them as they are in their object form and deserialize to instantiate >> Â Â Â Pros: Â Simple as save format, just smack it out >> Â Â Â Cons: Â Not resilient against framework/library changes, in fact very brittle >> Â Â Â Â Â Â Â Not readable nor editable >> Â Â Â Â Â Â Â Not so easy to "store" in langauge (ByteArray? String literal? >> >> Serialization (as in "storing the object model exactly as it is") IMO almost only has drawbacks. It is very brittle when systems change and it is not readable nor editable etc. I just don't like it at all :) > > Excellent summary/writeup ! > >> Ok, sooo... not sure if I made the Pros/Cons clear enough to be understood here. Anyway, in my quest earlier to build Deltas and Deltastreams I ended up investigating "formats" and then I created Tirade: >> >> Â Â Â http://goran.krampe.se/blog/Squeak/Tirade.rdoc >> Â Â Â http://goran.krampe.se/blog/Squeak/Tirade2.rdoc >> Â Â Â http://goran.krampe.se/blog/Squeak/Tirade3.rdoc >> >> (sorry for lack of nice CSS there) >> >> NOTE: Since those articles I have simplified it a bit - I scratched the complicated "stack" logic around figuring out the receiver. >> >> Anyway, Tirade is in short a very long cascade that only allows arguments in literal forms. So basically Tirade doesn't serialize objects - it serializes a *sequence of messages*. And then when we "deserialize it" we replay those messages onto a receiver. >> >> Thus, in syntax it is very Squeakish - it even uses the same number parser etc as the Compiler does. But it is a very restricted subset of Smalltalk which makes it fast and secure. >> >> So, given the Pros/Cons above, let's see how Tirade would fit: >> >> * Easy to read and edit: yes, it looks like Smalltalk, but without a receiver to the left. >> >> * Easy to store in a method: yes, quite simple, the easiest way may be to save it as "Smalltalk" like this: >> >> tiradeOn: recorder >> Â Â Â "Create Tirade by sending messages to a Tirade recorder." >> Â Â Â recorder message1; message2; message3 >> >> In that way you can still use senders/implementors etc of the message selectors. >> >> * Easy to store outside of the language: yes, trivial, and fast to write and read >> >> * Very resilient against framework/library changes if we use a declarative style. > > Tirade looks cool, very nice idea, simple and powerful. Nice name too. > > Some questions: > > - don't you need a more formal (BNF) spec (I like the drawings on the http://json.org/ site) ? > - there does not seem to be a way to deal with non-ascii strings like 'GÃ¶ran', shouldn't there be something like JSON escapes ? No. Wake up. Its 2011 outside. Use unicode encodings (like UTF-8) for reading/writing source streams. Just don't use ascii, then you won't need to escape non-ascii characters. :) > - should there not be some kind of convention to note the expected reader (in a comment as meta data maybe) ? > - has this since 2009 been used anywhere ? > - how about inter Smalltalk interoperability ? > > Sven > > > -- Best regards, Igor Stasenko AKA sig.

Feb. 14, 2011

Re: [Pharo-project] Issue 3702 in pharo: squeeze out a bit more speed from TextDiffBuilder

by pharo＠googlecode.com

Updates: Labels: Difficulty-Easy Comment #1 on issue 3702 by stephane...(a)gmail.com: squeeze out a bit more speed from TextDiffBuilder http://code.google.com/p/pharo/issues/detail?id=3702 to create a cs lcsFor: xFilteredLines and: yFilteredLines "I find one of the longest common subsequences of my the arguments. I assume that none of my arguments are empty. I return nil or an Array which represents a list. The first two elements are the matching line numbers, the last is the next node in the list or nil if there are no more elements. The list containts the longest common subsequence. I'm a modified version of the greedy lcs algorithm from the 6th page of 'An O(ND) Difference Algorithm and Its Variations (1986)' by Eugene W. Myers" | n m v lcss max | n := xFilteredLines size. m := yFilteredLines size. max := m + n. v := Array new: 2 * max + 1. v at: max + 2 put: 0. lcss := Array new: 2 * max + 1. 0 to: max do: [ :d | d negated to: d by: 2 do: [ :k | | index lcs x y | index := max + k. (k + d = 0 or: [ k ~= d and: [ (v at: index) < (v at: index + 2) ] ]) ifTrue: [ x := v at: (index := index + 2) ] ifFalse: [ x := (v at: index) + 1 ]. y := x - k. lcs := lcss at: index. [ x < n and: [ y < m and: [ (xFilteredLines at: x + 1) = (yFilteredLines at: y + 1) ] ] ] whileTrue: [ lcs := { x := x + 1. y := y + 1. lcs } ]. (x >= n and: [ y >= m ]) ifTrue: [ ^lcs ]. v at: max + k + 1 put: x. lcss at: max + k + 1 put: lcs ] ]. self error and findMatches "I find the matching pairs of xLines and yLines. First I filter out all lines that can't have a pair, then I find the longest common subsequence of the remaining elements. Finally I mark the matching pairs." | temp lcs xFilteredLines yFilteredLines xNumbers yNumbers | "Filter out all lines that can't have a pair." temp := yLines asSet. xFilteredLines := xLines select: [ :each | temp includes: each ]. xFilteredLines size = 0 ifTrue: [ ^self ]. temp := xLines asSet. yFilteredLines := yLines select: [ :each | temp includes: each ]. yFilteredLines size = 0 ifTrue: [ ^self ]. "Map all lines to SmallIntegers, because they can be compared faster." temp := Dictionary new. xNumbers := xFilteredLines collect: [ :each | temp at: each ifAbsentPut: [ temp size ] ]. yNumbers := yFilteredLines collect: [ :each | temp at: each ifAbsentPut: [ temp size ] ]. temp := nil. "Find the longest common subsequence." lcs := self lcsFor: xNumbers and: yNumbers. "Mark the matching pairs." [ lcs == nil ] whileFalse: [ (xFilteredLines at: (lcs at: 1)) matches: (yFilteredLines at: (lcs at: 2)). lcs := lcs at: 3 ]

Feb. 14, 2011

[Pharo-project] Issue 3702 in pharo: squeeze out a bit more speed from TextDiffBuilder

by pharo＠googlecode.com

Status: FixedWaitingToBePharoed Owner: stephane...(a)gmail.com Labels: Type-Squeak New issue 3702 by stephane...(a)gmail.com: squeeze out a bit more speed from TextDiffBuilder http://code.google.com/p/pharo/issues/detail?id=3702 I analysed the following changes and they are based on exactly the same method versions in pharo so they can be applied (without problems from their side) Name: System-ul.419 Author: ul Time: 8 February 2011, 3:36:03.896 am UUID: 0ca6c6be-d524-b444-9c5e-c16ef8059669 Ancestors: System-ul.418 - squeeze out a bit more speed from TextDiffBuilder =============== Diff against System-ul.418 =============== Item was changed: ----- Method: TextDiffBuilder>>findMatches (in category 'private') ----- findMatches "I find the matching pairs of xLines and yLines. First I filter out all lines that can't have a pair, then I find the longest common subsequence of the remaining elements. Finally I mark the matching pairs." + | temp lcs xFilteredLines yFilteredLines xNumbers yNumbers | + "Filter out all lines that can't have a pair." + temp := yLines asSet. - | lineSet lcs xFilteredLines yFilteredLines | - lineSet := yLines asSet. xFilteredLines := xLines select: [ :each | + temp includes: each ]. - lineSet includes: each ]. xFilteredLines size = 0 ifTrue: [ ^self ]. + temp := xLines asSet. - lineSet := xLines asSet. yFilteredLines := yLines select: [ :each | + temp includes: each ]. - (lineSet includes: each) ]. yFilteredLines size = 0 ifTrue: [ ^self ]. + "Map all lines to SmallIntegers, because they can be compared faster." + temp := Dictionary new. + xNumbers := xFilteredLines collect: [ :each | + temp at: each ifAbsentPut: [ temp size ] ]. + yNumbers := yFilteredLines collect: [ :each | + temp at: each ifAbsentPut: [ temp size ] ]. + temp := nil. + "Find the longest common subsequence." + lcs := self lcsFor: xNumbers and: yNumbers. + "Mark the matching pairs." - lcs := self - lcsFor: xFilteredLines - and: yFilteredLines. [ lcs == nil ] whileFalse: [ (xFilteredLines at: (lcs at: 1)) matches: (yFilteredLines at: (lcs at: 2)). lcs := lcs at: 3 ]! Item was changed: ----- Method: TextDiffBuilder>>lcsFor:and: (in category 'private') ----- lcsFor: xFilteredLines and: yFilteredLines - "I find one of the longest common subsequences of my the arguments. I assume that none of my arguments are empty. I return nil or an Array which represents a list. The first two elements are the matching line numbers, the last is the next node in the list or nil if there are no more elements. The list containts the longest common subsequence. I'm a modified version of the greedy lcs algorithm from the 6th page of 'An O(ND) Difference Algorithm and Its Variations (1986)' by Eugene W. Myers" | n m v lcss max | n := xFilteredLines size. m := yFilteredLines size. max := m + n. v := Array new: 2 * max + 1. v at: max + 2 put: 0. lcss := Array new: 2 * max + 1. 0 to: max do: [ :d | d negated to: d by: 2 do: [ :k | | index lcs x y | + index := max + k. + (k + d = 0 or: [ k ~= d and: [ (v at: index) < (v at: index + 2) ] ]) + ifTrue: [ x := v at: (index := index + 2) ] + ifFalse: [ x := (v at: index) + 1 ]. - (k + d = 0 or: [ k ~= d and: [ (v at: max + k ) < (v at: max + k + 2) ] ]) - ifTrue: [ - index := max + k + 2. - x := v at: index ] - ifFalse: [ - index := max + k. - x := (v at: index) + 1 ]. y := x - k. lcs := lcss at: index. [ x < n and: [ y < m and: [ (xFilteredLines at: x + 1) = (yFilteredLines at: y + 1) ] ] ] whileTrue: [ lcs := { x := x + 1. y := y + 1. lcs } ]. + (x >= n and: [ y >= m ]) ifTrue: [ ^lcs ]. - (x >= n and: [ y >= m ]) ifTrue: [ - ^lcs ]. v at: max + k + 1 put: x. lcss at: max + k + 1 put: lcs ] ]. self error!

Feb. 14, 2011

Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

by Igor Stasenko

On 14 February 2011 01:32, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > That's where I typically use a dictionary. Â Map the numbers to what is often a factory (a factory that reads from a stream being a common scenario) or sometimes closures. Â Create the map once on class initialization or once per "session" (or at least try not to build the map "every time"), and the result is reasonably efficient. Â It is really no different from what Smalltalk user interface frameworks do to dispatch messages to objects. Â Obviously, if the numbers are contiguous, one could use an array, but I find a dictionary convenient because there is no need to mess with offsets. > Indeed. > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Stephen Taylor [stephen.taylor(a)bom.gov.au] > Sent: Sunday, February 13, 2011 6:21 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] could we agree to remove caseOf: Â and Â Â caseOf:otherwise: > > Igor Stasenko wrote: > >>> You have some integers: 0 83 67 77 68 72 80 112 113 87 70 82. When a >>> variable's value is equal to any of these... > >> Don't try to convince me that there are sort of problems which can be >> solved only by using case statement :) > > You didn't answer the question though. > Because it sounds rhetoric to me. How to deal with randomly put integers coming from outer source? If you're a software engineer, you should know it. :) But i can explain my vision: - first try to avoid dealing with them. So if you can control the protocol, use other ways of encoding actions/data. - organize these numbers (using dictionary or whatever), so they won't look like a random noise for people who first looking at your code. Put them into single place with documentation etc. And convert them to their symbolic representation as soon as possible. - never use bare numbers as a labels which influencing a control flow (like in switch statement, branches etc). Instead, use their symbolic names. This will prevent many many many errors, typos and mistakes and make your code more documented. >> First, get rid of these integers in your code. > > That's the killer - yes, we can usually design around cases where we'd > use case constructs (though I'm not convinced they're the spawn of the > devil) but what about cases where we're interfacing with external data > sources and we don't get to redesign the whole system to suit our needs? > > > > Â Â Â Â Â Â Â Steve -- Best regards, Igor Stasenko AKA sig.

Feb. 14, 2011

[Pharo-project] Issue 3701 in pharo: FloatArray>>dot: is defined in plugin but not at the image level

by pharo＠googlecode.com

Status: FixedWaitingToBePharoed Owner: stephane...(a)gmail.com Labels: Milestone-1.3 Type-Squeak Difficulty-Easy New issue 3701 by stephane...(a)gmail.com: FloatArray>>dot: is defined in plugin but not at the image level http://code.google.com/p/pharo/issues/detail?id=3701 Name: Collections-ul.423 Author: ul Time: 7 February 2011, 8:55:57.134 pm UUID: e18716fc-a36b-874c-8946-5c21b447a96f Ancestors: Collections-ul.422 - use the primitive for FloatArray >> #dot: (~50x faster). =============== Diff against Collections-ul.422 =============== Item was changed: ----- Method: FloatArray>>dot: (in category 'arithmetic') ----- dot: aFloatVector "Primitive. Return the dot product of the receiver and the argument. Fail if the argument is not of the same size as the receiver." + | result | + <primitive: 'primitiveDotProduct' module: 'FloatArrayPlugin'> - "<primitive:'primitiveFloatArrayDotProduct'>" self size = aFloatVector size ifFalse:[^self error:'Must be equal size']. result := 0.0. 1 to: self size do:[:i| result := result + ((self at: i) * (aFloatVector at: i)). ]. ^result!

Feb. 14, 2011

Re: [Pharo-project] A new GUI visual designer

by Sven Van Caekenberghe

Hi GÃ¶ran, On 14 Feb 2011, at 00:18, GÃ¶ran Krampe wrote: > Hi! > > Sorry, this post turned out long. But hopefully interesting anyway. > > On 02/13/2011 06:36 PM, Schwab,Wilhelm K wrote: >> You cite an example very similar to what Dolphin does, and we could do with SIXX. > > Dolphin serializes things not to avoid the image but to allow packaging. > > SIXX could do the same for us. > [SNIP] > > > If we had something that could read and rewrite Smalltalk code that is truly independent > > of WB, then class methods would be nice way to store GUI designs. >> >> Bill > > Just wanted to chip in here - IMHO there is a loooong history when it comes to how to "save" UIs. We have seen (and in many different programming languages) various ways through the years: > > - Build them with code each time we want them > Pros: Resilient against framework/library changes > Very readable and editable > Easy to "store" in the language (just save as a method) > Cons: Very hard to use as a "save format" > Has too much freedom if we hand edit it > > I actually favor the above since I normally dislike UI Designer tools :). But I can of course see the value of a really good UI designer (WB Pro is one of the best I have ever used, and the one in VisualAge was also superb). > > - Save them in "dumb" data structures (like VW specs) > Pros: A bit resilient since it relies on a builder, but not as good as code because it is just dumb data > Similar easy to store in the language > Cons: Not readable and editable > > VW has used this for a long time and it is indeed pretty slick since you just "store" it in a method. That is one very nice characteristic, and if you have good options to dig into the builder after it has read the spec - then having the spec be "non readable/editable" is not that painful. But still, it is a bit of a serialization hack and ... doesn't feel quite right. > > > - Save them in a more advanced (than an Array) non Smalltalk langauge like XML > Pros: Quite resilient against framework/library changes, if grammar is made to be declarative in style > Easy to use as "save format" > Cons: Get's complex and icky > Not so easy to "store" in language (a String literal?) > Not so readable and editable > > IMHO using XML is "nice" (well...) for inter system and inter language communications/interchange. But realistically, how much interplay can we expect when we are talking about Morphic UIs? AFAIK the rest of the world haven't been able to gather around a single format either. If there indeed was a format that all the Gtk/Qts and whatnots out there used - then by all means. But is there? > > > - Serialize (in binary or whatever language like XML etc) them as they are in their object form and deserialize to instantiate > Pros: Simple as save format, just smack it out > Cons: Not resilient against framework/library changes, in fact very brittle > Not readable nor editable > Not so easy to "store" in langauge (ByteArray? String literal? > > Serialization (as in "storing the object model exactly as it is") IMO almost only has drawbacks. It is very brittle when systems change and it is not readable nor editable etc. I just don't like it at all :) Excellent summary/writeup ! > Ok, sooo... not sure if I made the Pros/Cons clear enough to be understood here. Anyway, in my quest earlier to build Deltas and Deltastreams I ended up investigating "formats" and then I created Tirade: > > http://goran.krampe.se/blog/Squeak/Tirade.rdoc > http://goran.krampe.se/blog/Squeak/Tirade2.rdoc > http://goran.krampe.se/blog/Squeak/Tirade3.rdoc > > (sorry for lack of nice CSS there) > > NOTE: Since those articles I have simplified it a bit - I scratched the complicated "stack" logic around figuring out the receiver. > > Anyway, Tirade is in short a very long cascade that only allows arguments in literal forms. So basically Tirade doesn't serialize objects - it serializes a *sequence of messages*. And then when we "deserialize it" we replay those messages onto a receiver. > > Thus, in syntax it is very Squeakish - it even uses the same number parser etc as the Compiler does. But it is a very restricted subset of Smalltalk which makes it fast and secure. > > So, given the Pros/Cons above, let's see how Tirade would fit: > > * Easy to read and edit: yes, it looks like Smalltalk, but without a receiver to the left. > > * Easy to store in a method: yes, quite simple, the easiest way may be to save it as "Smalltalk" like this: > > tiradeOn: recorder > "Create Tirade by sending messages to a Tirade recorder." > recorder message1; message2; message3 > > In that way you can still use senders/implementors etc of the message selectors. > > * Easy to store outside of the language: yes, trivial, and fast to write and read > > * Very resilient against framework/library changes if we use a declarative style. Tirade looks cool, very nice idea, simple and powerful. Nice name too. Some questions: - don't you need a more formal (BNF) spec (I like the drawings on the http://json.org/ site) ? - there does not seem to be a way to deal with non-ascii strings like 'GÃ¶ran', shouldn't there be something like JSON escapes ? - should there not be some kind of convention to note the expected reader (in a comment as meta data maybe) ? - has this since 2009 been used anywhere ? - how about inter Smalltalk interoperability ? Sven

Feb. 14, 2011

Re: [Pharo-project] A new GUI visual designer

by Geert Claes

I'll leave in the middle whether or not the "Morphic UI Designer" is the right solution for Pharo, but looking at the number of posts in this thread I do have a feeling that: 1. most do agree that a better way to create the user interface really is needed 2. there are strong opinions on how this UI designer should and/or should not be implemented As most applications require a UI, having a powerful UI builder is extremely important for any development environment to succeed. If Pharo were to have an intuitive UI builder, I think even more people would give Pharo a go and probably improve Pharo's existing development environment along the way. GÃ¶ran just constructively summarized and grouped some groups and optiobs for the "how". So rather than arguing what "not" to do, let's try and focus on how it will be done and who is able to help. Having said all that, I think Smalltalk could benefit even more if Smalltalk had a powerful UI builder for web applications, but I guess that's outside Pharo's scope and is something the frameworks like AIDA, Seaside or Iliad need to address. -- View this message in context: http://forum.world.st/A-new-GUI-visual-designer-tp3067111p3304566.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 14, 2011

Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

by Schwab,Wilhelm K

That's where I typically use a dictionary. Map the numbers to what is often a factory (a factory that reads from a stream being a common scenario) or sometimes closures. Create the map once on class initialization or once per "session" (or at least try not to build the map "every time"), and the result is reasonably efficient. It is really no different from what Smalltalk user interface frameworks do to dispatch messages to objects. Obviously, if the numbers are contiguous, one could use an array, but I find a dictionary convenient because there is no need to mess with offsets. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Stephen Taylor [stephen.taylor(a)bom.gov.au] Sent: Sunday, February 13, 2011 6:21 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise: Igor Stasenko wrote: >> You have some integers: 0 83 67 77 68 72 80 112 113 87 70 82. When a >> variable's value is equal to any of these... > Don't try to convince me that there are sort of problems which can be > solved only by using case statement :) You didn't answer the question though. > First, get rid of these integers in your code. That's the killer - yes, we can usually design around cases where we'd use case constructs (though I'm not convinced they're the spawn of the devil) but what about cases where we're interfacing with external data sources and we don't get to redesign the whole system to suit our needs? Steve

Feb. 14, 2011