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

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

by Stephen Taylor

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. 13, 2011

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

by GÃ¶ran Krampe

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 :) 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. regards, GÃ¶ran

Feb. 13, 2011

Re: [Pharo-project] [COTDC] 10 - DummyUIManager

by Igor Stasenko

On 13 February 2011 19:48, laurent laffont <laurent.laffont(a)gmail.com> wrote: > Today: Â DummyUIManager > Since i went into that area not long ago.. i can give it a try. Hmm.. I'm not sure we need it anymore.. Maybe we still need it in a sense, that you don't want quit image on errors (like NonInteractiveIUManager). I am not an author of this class, so i can only guess what its purpose and so if NonInteractiveIUManager having the same one, then we should simply get rid of it. Oh yeah.. if someone wiil give an elaborate comment about its purpose we can see :) > 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 -- Best regards, Igor Stasenko AKA sig.

Feb. 13, 2011

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

by Igor Stasenko

On 13 February 2011 17:44, Ricardo Moran <richi.moran(a)gmail.com> wrote: > 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" :) I meant a code which using it should die, not people of course. And of course this was not an argument at all. It was just to express my attitude to that :) And of course, i know Levente long enough to faulty considering him ignorant. Yes, i hate bad code.. But clearly not people :) > 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 >> >> >> > > -- Best regards, Igor Stasenko AKA sig.

Feb. 13, 2011

[Pharo-project] Issue 3700 in pharo: it is not possible to install O2 on pharo 1.2

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3700 by patin...(a)gmail.com: it is not possible to install O2 on pharo 1.2 http://code.google.com/p/pharo/issues/detail?id=3700 Pharo image: Pharo | Pharo-core Pharo1.2rc2 Latest update: #12333 Macos X : Squeak 4.2.5beta1U.app OBSystemBrowserAdapter Steps to reproduce: 1. evaluate DEVImageWorkspaces openExternalProjectWorkspace 2. evaluate (provided through previous command) Gofer new squeaksource: 'MetacelloRepository'; package:'ConfigurationOfO2'; load. 3. then evaluate ((Smalltalk at: #ConfigurationOfO2) project version: '1.2') load: 'Dev'. The installation freeze and the debuguer opens. Here joined the log file and a screen capture. Attachments: bugO2.tiff 384 KB PharoDebug.log 246 KB

Feb. 13, 2011

Re: [Pharo-project] Issue 2374 in pharo: Dragging a .image in a Windows VM raises an error

by pharo＠googlecode.com

Comment #5 on issue 2374 by DougEdmu...(a)gmail.com: Dragging a .image in a Windows VM raises an error http://code.google.com/p/pharo/issues/detail?id=2374 This works in XP. I no longer get the "Error:invalid utf8 input detected" 1. Delete the last two lines from pharo.ini ImageFile=Contents\Resources\pharo.image WindowTitle=Pharo Development 2. Set up a filetype association for .image files to pharo.exe (this allows double-clicking to open the image). Now when you click on pharo.exe (or a shortcut to it), it will ask you to select an image file. The first time, it needs some help finding the directory where they are located; the next time, it remembers that location. By deleting the WindowsTitle= line from the pharo.ini file, the title bar shows the name of the image file that you have opened.

Feb. 13, 2011

Re: [Pharo-project] shout and Pharo 1.2 or 1.3

by Marcus Denker

On Feb 13, 2011, at 5:44 AM, Hilaire Fernandes wrote: > I have been reading the related discussion in the bug tracker. It is not > clear to me if finally shout will eventually work with 1.2. > I am going to prepare a DrGeo public release where I want shout, I am > wondering if I should just use early 1.3 Pharo to do (where shout works > nicely). Are there any reason or pitfall I should be aware of before > doing so? If there is something so important so people would use 1.3 instead of 1.2, then why do we not fix it? http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.2-DevImage We should really try to get 1.2 ready. this is getting really boring, and I really have no energy left anymore for it. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 13, 2011

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

by Tobias Pape

Am 2011-02-13 um 17:58 schrieb Richard Durr: > Btw, why the use of qt's signals and slots and not Cocoas outlets? > Because the author of the Morphic Builder has had more experience with qt and likes it. He hasn't done Mac programming until now, afaik.

Feb. 13, 2011

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

by Janko MivÅ¡ek

+1 to your arguments, Benoit! Janko On 13. 02. 2011 19:29, Benoit St-Jean wrote: > 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 > <mailto:pharo-project-bounces@lists.gforge.inria.fr> > [pharo-project-bounces(a)lists.gforge.inria.fr > <mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of > Benoit St-Jean [bstjean(a)yahoo.com <mailto:bstjean@yahoo.com>] > Sent: Sunday, February 13, 2011 9:43 AM > To: Pharo-project(a)lists.gforge.inria.fr > <mailto:Pharo-project@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 <mailto:leves@elte.hu>> > To: Pharo-project(a)lists.gforge.inria.fr > <mailto:Pharo-project@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 >> >> >> > > > > -- Janko MivÅ¡ek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

Feb. 13, 2011

[Pharo-project] [COTDC] 10 - DummyUIManager

by laurent laffont

Today: DummyUIManager 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

Feb. 13, 2011