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

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

by Benoit St-Jean

I mostly agree with you on all points Bill.. It's just that usually, "ugliness" in Smalltalk, is a symptom of bad design or at least that something could be refactored a little bit more... In all the years and all the Smalltalk implementations, why did no one ever implemented Number arithmetic operations using case statements (or case style) and used double dispatch instead ?? I guess there are many other ways this could have been implemented more effectively (performance-wise) but simplicity & clarity seem to have won. Simplicity & clarity have their merits. It's no wonder, a few years ago, there was a Smalltalk implementation that allowed "assembly code" inside Smalltalk code but this feature never got popular even though "it could have been extremely fast". What a real mess. Probably really efficient & fast but was a mess from a readability & maintenance standpoint... I'm just really skeptical about always presenting speed as the main argument when it comes to Smalltalk & the way to code and implement things. It's like having a Cessna and trying to make it fly like the space shuttle. It wasn't designed for that. Yes we could add boosters, yes we could extend the wings, yes we could change the engine, yes we could patch this, yes we could do that, etc. If I want to go to the moon, I'll use the Space Shuttle but in the meantime, I must not forget I'm piloting and using a Cessna. This #caseOf:otherwise: painfully reminds me of a coding horror I saw years ago... The programmer told us he was never sure of the receiver (a few possible classes only) and had to rely on a "very useful and flexible" method called #ifTrue:ifFalse:ifNil:ifEmpty:otherwise: .Obviously, you can only imagine the rest of the "logic" involved where this method was called... Double dispatching would have been so simpler and more elegant. It felt like doing BASIC a class browser ! I'm not against change when needed. I'm not against suggestions. I'm not against speed improvements. But I'm not for speed at all costs, especially code readability. If we want speed, it's in the VM we have to implement it. Cincom rarely relied on ugly Smalltalk code implementations to make VW faster. They pushed the VM. Not the Collection hierrachy, not the Number hierarchy, not the Stream, etc. Besides, performance arguments is a slippery slope. What about memory consumption? Which road should we take ? It's fast but it instantiates 10 million objects or it's small and used 3Ks of memory but runs 5 seconds slower? There's always another side to what "efficiency" means to everyone. My 2 cents! :) ----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein) ________________________________ From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> To: "Pharo-project(a)lists.gforge.inria.fr" <Pharo-project(a)lists.gforge.inria.fr> Sent: Sun, February 13, 2011 12:13:41 PM Subject: Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise: Read the Federalist Papers and Bastiat's "The Law," and then we can talk about democracy, one illustration of which is three wolves and a sheep voting on the dinner menu. In its raw form, yes, I argue against democracy, aka mob rule. However, we are not talking about taking someone's life, liberty or property here: this is software, and one can always retain #caseOf: in any image. However, a vote seems reasonable. I would be just as willing to accept the ruling of the benign dictators. A switch often suggests inadequate reification (aka direct polymorphism or double dispatch might be in order), but I sometimes resort to a dictionary as a quick way to map numbers or strings to actions. Since landing in Pharo, I have been using the modified stream protocol I developed in response to default actions, which I consider to be a disaster in the making. Others are less worried about it. It is fairly easy to have some code that one loads into an image. I do it for streams, others can do it for case statements. The above said, one thing I don't like is "you can't do that because I think its' ugly." Perhaps a compromise for Stef to consider is to clean the uses of the method so it is not used in the image (effectively removing it), but leave it in place for those who want to use it their own code?? Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Benoit St-Jean [bstjean(a)yahoo.com] Sent: Sunday, February 13, 2011 9:43 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise: Let's get to the point here... Most people will tell you it's an awful "beast" that doesn't belong to the OO and Smalltalk world. If I *love* case statements and I absolutely need them, I can code in C. If I *love* case statements and I absolutely need them, nothing prevents me from adding them to the image as my own-superoptimized extension. You'll always find something, someone, somewhere who could argue about the need for such a thing but in reality, I guess this method has always bugged most Smalltalkers... It's ugly, not OO, not good style and good practice, not essential and not needed by 99% of the people here (and if it's sooooooooooo needed, how do you explain that all other Smalltalk vendors haven't implement it as part of their core libraries ?). So let's vote (you won't argue against democracy, won't you?!) for the removal of #caseOf:otherwise: and let's move forward onto more important business. On a less serious note, let's all remember what Spock said: "Were I to invoke logic, however, logic clearly dictates that the needs of the many outweigh the needs of the few" Let's remove this thing! +1 P.S. Performance-wise, if you always need "optimized" code, you can always rely on primitives & plugins... Let's not go performance-frenzy here! We don't want to end up in an environment where all the code is unreadable... Clarity & simplicity are good, not evil in Smalltalk! ----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein) ________________________________ From: Levente Uzonyi <leves(a)elte.hu> To: Pharo-project(a)lists.gforge.inria.fr Sent: Sun, February 13, 2011 8:50:53 AM Subject: Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise: On Sun, 13 Feb 2011, Sven Van Caekenberghe wrote: > > On 12 Feb 2011, at 18:41, Levente Uzonyi wrote: > >> ~27x slowdown in this case. > > I personally never heard of #caseOf:otherwise ! > > It feels like a hack that is not often needed. You don't need it often, but it's sometimes useful. > > If after writing correct code you need to optimize integer/byte handling, there >are many solutions, check any book on algorithms, most of them are using table >dispatch. The blocks of #caseOf: are not just boilerplate code, you can evaluate any expression there. It's cumbersome to do that with table based dispatch. > > Another problem in your benchmark is that you keep the creation of the dynamic >array inside the code to measure, while in the compiler primitive case it is of >course compiled away, that alone makes a huge difference: It's not a problem, it's intentional. See the mail that I replied to. Levente > > (timings on my machine) > > [ 1 to: 10 do: [ :each | > each > caseOf: { > [ 1 ] -> [ $a ]. > [ 2 ] -> [ $b ]. > [ 3 ] -> [ $c ]. > [ 4 ] -> [ $d ]. > [ 5 ] -> [ $e ] } > otherwise: [ $x ] ] ] bench. > '8,920,000 per second.' > > [ 1 to: 10 do: [ :each | > ({ > [ 1 ] -> [ $a ]. > [ 2 ] -> [ $b ]. > [ 3 ] -> [ $c ]. > [ 4 ] -> [ $d ]. > [ 5 ] -> [ $e ] } > detect: [ :ea | ea key value = each ] > ifNone: [ [ $x ] ]) value ] ] bench. > '70,600 per second.' > > | actions | > actions := { [ $a ]. [ $b ]. [ $c ]. [ $d ]. [ $e ]. [ $x ]. [ $x ]. [ $x ]. [ >$x ]. [ $x ]. }. > [ 1 to: 10 do: [ :each | > (actions at: each) value ] ] bench. > '3,230,000 per second.' > > | letters | > letters := 'abcdexxxxx'. > [ 1 to: 10 do: [ :each | > letters at: each ] ] bench. > '8,930,000 per second.' > > If other Smalltalks can live without it, so can we. > > Sven > > >

Feb. 13, 2011

Re: [Pharo-project] Call a external executable file. What is the best option?

by Max Leske

I asked something similar a while back. I've pasted the contents of that discussion below. Max --- begin pasted discussion --- On 13.12.2010, at 09:54, StÃ©phane Ducasse wrote: > Guys > > we should create a nice documentation for the OSProcess please please spend some time on the collabactive book because we need more documentation. > > Stef > > On Dec 12, 2010, at 6:34 PM, Schwab,Wilhelm K wrote: > >> OSProcess, which I am learning to like more as I learn more about it, is not well supported on Windows. Dave recently advised me to use ProcessWrapper on Windows; if he is saying that, then it must be the better path for now. >> >> I have done FFI on both Windows and Linux. I have not (yet anyway) done any one task in a cross-platform way. So far, I have not seen anything horrible that would prevent it. I have zero interest (at least so far) in moving my numerical analysis adventures back toward Windows (they started there and moved to Linux where I am quite happy). I have a .so interface to Acces IO A/D hardware and a DLL interface to Ascension Technology's 3D tracking software. Ultimately, I hope to be able to use both of them on either platform (the software exists on both), but have not yet made the connections. >> >> I transparently use OutputDebugString() on Linux and syslog() on Linux, but that does a test on platform and calls completely different code, so it does not count here. >> >> Sorry I can't be of more help. I urge you to wade into it and ask for help as you get stuck. For creating libraries, you might want to have a look at Code::Blocks; I don't push it very hard, but I have no complaints. The "default" is to install MinGW on Windows (last time I looked at least) and it uses gcc on Linux. >> >> Bill >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Lukas Renggli [renggli(a)gmail.com] >> Sent: Sunday, December 12, 2010 11:43 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Is executing a file platform dependent? >> >> With OS Process you can run scripts. That should work identical on Mac >> and Unix systems; probably also Windows, but I haven't tried. >> >> With FFI and Alien you can call C libraries. I have not much >> experience with those, but normally it should be possible to use them >> on all platforms. >> >> Lukas >> >> On 12 December 2010 17:31, Max Leske <maxleske(a)gmail.com> wrote: >>> Hi guys >>> >>> I was wondering if it is true that executing a file from within Pharo is platform dependent. I don't actually need to execute a file; it's more a theoretical question and I have no idea what the mechanisms are that would be used. To give you a clearer picture: Imagine you have C, sh, and perl files. What I'm thinking about is that I would have some data in the image that I would want to process with the code in one of those files. I would then wait for the result and process the result in the image. >>> >>> So my questions are: is there a platform independent way to execute C, sh or perl files from Pharo? Does the VM handle the platform dependencies? Are there any other issues with the idea I described? >>> >>> Don't go out of your way to find answers, please. But I'd be happy to hear your thoughts. >>> >>> Cheers, >>> Max >>> >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> > > On 13.02.2011, at 19:20, Schwab,Wilhelm K wrote: > I think you will find that OS Process work on mac an Linux and NOT on Windows, but ProcessWrapper does work there. A test on the OS should let you interchange them well enough to get by. > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of nullPointer [epicfan(a)gmail.com] > Sent: Sunday, February 13, 2011 1:19 PM > To: pharo-project(a)lists.gforge.inria.fr > Subject: [Pharo-project] Call a external executable file. What is the best option? > > I need call executable files of OS. I see various options, but IÂ´m not sure. > I believe donÂ´t understand correctly. > > I need: > > -Call executable files from system. > -Call associated programs of links, for example, I could pass > 'http://google.com'. The result must be open the default browser of user > with that link. > -Call commands or .BATs files from OS. > -I need use that on any OS, must be cross-platform, is very important. > > If that is not implemented on Pharo, is possible create a .exe file with > another language, where I call functions of OS, and invoke from Smalltalk > that exe? > > Regards. > > > > -- > View this message in context: http://forum.world.st/Call-a-external-executable-file-What-is-the-best-opti… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

Feb. 13, 2011

Re: [Pharo-project] Call a external executable file. What is the best option?

by Schwab,Wilhelm K

I think you will find that OS Process work on mac an Linux and NOT on Windows, but ProcessWrapper does work there. A test on the OS should let you interchange them well enough to get by. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of nullPointer [epicfan(a)gmail.com] Sent: Sunday, February 13, 2011 1:19 PM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Call a external executable file. What is the best option? I need call executable files of OS. I see various options, but IÂ´m not sure. I believe donÂ´t understand correctly. I need: -Call executable files from system. -Call associated programs of links, for example, I could pass 'http://google.com'. The result must be open the default browser of user with that link. -Call commands or .BATs files from OS. -I need use that on any OS, must be cross-platform, is very important. If that is not implemented on Pharo, is possible create a .exe file with another language, where I call functions of OS, and invoke from Smalltalk that exe? Regards. -- View this message in context: http://forum.world.st/Call-a-external-executable-file-What-is-the-best-opti… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 13, 2011

[Pharo-project] Call a external executable file. What is the best option?

by nullPointer

I need call executable files of OS. I see various options, but IÂ´m not sure. I believe donÂ´t understand correctly. I need: -Call executable files from system. -Call associated programs of links, for example, I could pass 'http://google.com'. The result must be open the default browser of user with that link. -Call commands or .BATs files from OS. -I need use that on any OS, must be cross-platform, is very important. If that is not implemented on Pharo, is possible create a .exe file with another language, where I call functions of OS, and invoke from Smalltalk that exe? Regards. -- View this message in context: http://forum.world.st/Call-a-external-executable-file-What-is-the-best-opti… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 13, 2011

Re: [Pharo-project] Issue 3694 in pharo: Balloon message should be opaque for better readability

by pharo＠googlecode.com

Comment #1 on issue 3694 by patrick....(a)gmail.com: Balloon message should be opaque for better readability http://code.google.com/p/pharo/issues/detail?id=3694 Seems that this color is hard coded in BalloonMorph class, without using UITheme. Maybe we could give theme writers a chance to manage balloons color ?

Feb. 13, 2011

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

by Nicolas Cellier

Yes, I myself find the implementation hackish, but I wish I could see more pragmatic analysis based on exact usage of this message. The discussion isn't going forward, every one camping on its position. 1) Where is the message used ? 2) How would you refactor the senders ? 3) Does speed degrade ? 4) Does it matter ? For Pharo, I invite you to simply remove the compiler optimization, and run some benchmark. Then deprecate the message if you want (but you'll need a compatibility layer, notably for Cog). Nicolas 2011/2/13 Ricardo Moran <richi.moran(a)gmail.com>: > Of course discussion is good. But turning your position into a religion and > blaming other parties ignorance is bad. That's what the discussion seemed to > be heading (at least to me) and I just tried to avoid that. > Maybe I'm just too new in this community (and smalltalk in general, for that > matter) and this is how you solve your discussions, but I just don't like > arguments such:Â "I don't like it and everyone using it should die" :) > Now that more voices have joined the thread I think we are actually getting > somewhere :) > Cheers > Richo > > On Sun, Feb 13, 2011 at 7:58 AM, Alain Plantec <alain.plantec(a)yahoo.com> > wrote: >> >> Le 13/02/2011 04:05, Ricardo Moran a Ã©crit : >>> >>> Ok, guys... I'm sorry to interrupt this polite discussion, but this is >>> taking nowhere. >> >> no, it allows people to make their own opinion. >> interesting thread. >> >> Now I can say that I would be more for getting rid of case of. >> >> thanks >> Alain >> >> >> > >

Feb. 13, 2011

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

by Schwab,Wilhelm K

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. I favor the idea of SIXX more to avoid falling into a trap of being subliminally influenced by (aka stealing from) Window Builder than because I think it is the correct thing to do. 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 ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Richard Durr [richard.durr(a)googlemail.com] Sent: Sunday, February 13, 2011 11:56 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] A new GUI visual designer Just a comment: :) The Interface Builder of Nextstep and Mac OS X â a closely Smalltalk-related and inspired system â creates the objects making up the user interface (it instantiates them) and then saves the state of everything into a nib/xib file (binary/xml) using the general object-persistency mechanism of Cocoa (NSKeyedArchiver). This file is then loaded when the application in question starts, all the freeze-dried objects in the UI-file are revived (awakened â not created) and then loaded into the object space of the app. This reminds me of the way, the Smalltalk Image works â except that the image stores the whole application object space where the nib/xib only stores the objects the interface is composed of. With Morphic there even exists an easy way to compose an interface with using original objects directly like or better than Interface Builder. But instead of using the image as a storage mechanism for the instantiated objects of a morphic-designed interface we are stuck with the textual distribution mechanism and discussing how we can for example use xml to do that. That is ironic, I think ^^ -- Sent from my DynaBook.

Feb. 13, 2011

[Pharo-project] invalid utf8 input detected on loading associated image (XP)

by DougEdmunds

From: dougedmunds(a)gmail.com To: Pharo-project(a)lists.gforge.inria.fr Subject: [BUG]UTF8TextConverter(Object)>>error: here insert explanation of what you were doing, suspect changes you've made and so forth. Using Windows XP SP3. Associated .image files with pharo.exe Pharo.exe is placed in c:\pharo directory. When I click on an image, I get an error: "Invalid UTF8 input detected". This happens with the original pharo.image, newer pharo.1.image. But if I open pharo.exe by clicking it (which automatically opens an image), I don't get this error. It only happens when I click on one of the .image files. (I tried to send this via the debugger's 'mail bug report', but then got a telnet error). 13 February 2011 9:23:14 am VM: Win32 - IX86 - NT - Squeak3.10.2 of 11 February 2010 [latest update: #9314] Image: Pharo-1.1.1-- [Latest update: #11414] SecurityManager state: Restricted: false FileAccess: true SocketAccess: true Working Dir C:\Pharo\Contents\Resources Trusted Dir C:\Pharo\Contents\Resources\dae Untrusted Dir C:\Documents and Settings\dae\My Documents\My Squeak UTF8TextConverter(Object)>>error: Receiver: an UTF8TextConverter Arguments and temporary variables: aString: 'Invalid utf8 input detected' Receiver's instance variables: latin1Map: #[0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ...etc... latin1Encodings: #(nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil ...etc... UTF8TextConverter>>errorMalformedInput Receiver: an UTF8TextConverter Arguments and temporary variables: Receiver's instance variables: latin1Map: #[0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ...etc... latin1Encodings: #(nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil ...etc... UTF8TextConverter>>nextFromStream: Receiver: an UTF8TextConverter Arguments and temporary variables: aStream: MultiByteFileStream: 'C:\Pharo\Contents\Resources\pharo.1.image' character1: $Â« value1: 171 character2: Character backspace value2: 8 unicode: nil character3: $Â´ value3: 180 character4: nil value4: nil Receiver's instance variables: latin1Map: #[0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ...etc... latin1Encodings: #(nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil ...etc... MultiByteFileStream>>next Receiver: MultiByteFileStream: 'C:\Pharo\Contents\Resources\pharo.1.image' Arguments and temporary variables: char: nil secondChar: nil state: nil Receiver's instance variables: [] in MultiByteFileStream>>upToEnd Receiver: MultiByteFileStream: 'C:\Pharo\Contents\Resources\pharo.1.image' Arguments and temporary variables: stream: a WriteStream 'h -- View this message in context: http://forum.world.st/invalid-utf8-input-detected-on-loading-associated-ima… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 13, 2011

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

by Schwab,Wilhelm K

Read the Federalist Papers and Bastiat's "The Law," and then we can talk about democracy, one illustration of which is three wolves and a sheep voting on the dinner menu. In its raw form, yes, I argue against democracy, aka mob rule. However, we are not talking about taking someone's life, liberty or property here: this is software, and one can always retain #caseOf: in any image. However, a vote seems reasonable. I would be just as willing to accept the ruling of the benign dictators. A switch often suggests inadequate reification (aka direct polymorphism or double dispatch might be in order), but I sometimes resort to a dictionary as a quick way to map numbers or strings to actions. Since landing in Pharo, I have been using the modified stream protocol I developed in response to default actions, which I consider to be a disaster in the making. Others are less worried about it. It is fairly easy to have some code that one loads into an image. I do it for streams, others can do it for case statements. The above said, one thing I don't like is "you can't do that because I think its' ugly." Perhaps a compromise for Stef to consider is to clean the uses of the method so it is not used in the image (effectively removing it), but leave it in place for those who want to use it their own code?? Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Benoit St-Jean [bstjean(a)yahoo.com] Sent: Sunday, February 13, 2011 9:43 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise: Let's get to the point here... Most people will tell you it's an awful "beast" that doesn't belong to the OO and Smalltalk world. If I *love* case statements and I absolutely need them, I can code in C. If I *love* case statements and I absolutely need them, nothing prevents me from adding them to the image as my own-superoptimized extension. You'll always find something, someone, somewhere who could argue about the need for such a thing but in reality, I guess this method has always bugged most Smalltalkers... It's ugly, not OO, not good style and good practice, not essential and not needed by 99% of the people here (and if it's sooooooooooo needed, how do you explain that all other Smalltalk vendors haven't implement it as part of their core libraries ?). So let's vote (you won't argue against democracy, won't you?!) for the removal of #caseOf:otherwise: and let's move forward onto more important business. On a less serious note, let's all remember what Spock said: "Were I to invoke logic, however, logic clearly dictates that the needs of the many outweigh the needs of the few" Let's remove this thing! +1 P.S. Performance-wise, if you always need "optimized" code, you can always rely on primitives & plugins... Let's not go performance-frenzy here! We don't want to end up in an environment where all the code is unreadable... Clarity & simplicity are good, not evil in Smalltalk! ----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein) ________________________________ From: Levente Uzonyi <leves(a)elte.hu> To: Pharo-project(a)lists.gforge.inria.fr Sent: Sun, February 13, 2011 8:50:53 AM Subject: Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise: On Sun, 13 Feb 2011, Sven Van Caekenberghe wrote: > > On 12 Feb 2011, at 18:41, Levente Uzonyi wrote: > >> ~27x slowdown in this case. > > I personally never heard of #caseOf:otherwise ! > > It feels like a hack that is not often needed. You don't need it often, but it's sometimes useful. > > If after writing correct code you need to optimize integer/byte handling, there are many solutions, check any book on algorithms, most of them are using table dispatch. The blocks of #caseOf: are not just boilerplate code, you can evaluate any expression there. It's cumbersome to do that with table based dispatch. > > Another problem in your benchmark is that you keep the creation of the dynamic array inside the code to measure, while in the compiler primitive case it is of course compiled away, that alone makes a huge difference: It's not a problem, it's intentional. See the mail that I replied to. Levente > > (timings on my machine) > > [ 1 to: 10 do: [ :each | > each > caseOf: { > [ 1 ] -> [ $a ]. > [ 2 ] -> [ $b ]. > [ 3 ] -> [ $c ]. > [ 4 ] -> [ $d ]. > [ 5 ] -> [ $e ] } > otherwise: [ $x ] ] ] bench. > '8,920,000 per second.' > > [ 1 to: 10 do: [ :each | > ({ > [ 1 ] -> [ $a ]. > [ 2 ] -> [ $b ]. > [ 3 ] -> [ $c ]. > [ 4 ] -> [ $d ]. > [ 5 ] -> [ $e ] } > detect: [ :ea | ea key value = each ] > ifNone: [ [ $x ] ]) value ] ] bench. > '70,600 per second.' > > | actions | > actions := { [ $a ]. [ $b ]. [ $c ]. [ $d ]. [ $e ]. [ $x ]. [ $x ]. [ $x ]. [ $x ]. [ $x ]. }. > [ 1 to: 10 do: [ :each | > (actions at: each) value ] ] bench. > '3,230,000 per second.' > > | letters | > letters := 'abcdexxxxx'. > [ 1 to: 10 do: [ :each | > letters at: each ] ] bench. > '8,930,000 per second.' > > If other Smalltalks can live without it, so can we. > > Sven > > >

Feb. 13, 2011

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

by Richard Durr

Btw, why the use of qt's signals and slots and not Cocoas outlets?

Feb. 13, 2011