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

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

by Eliot Miranda

On Mon, Feb 14, 2011 at 11:00 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > Eliot > > you use caseOf: for the generation of C in Slang and VM maker. > Now this means that > - it does not need to be inlined > No. If it is not inlined the simulator will go *much* slower. e.g. CogVMSimulatorLSB>>byteAt: byteAddress | lowBits long | lowBits := byteAddress bitAnd: 3. long := self longAt: byteAddress - lowBits. ^(lowBits caseOf: { [0] -> [ long ]. [1] -> [ long bitShift: -8 ]. [2] -> [ long bitShift: -16 ]. [3] -> [ long bitShift: -24 ] }) bitAnd: 16rFF > - it could be packaged with VMMaker > No. It needs to be in the compiler to be inlined. Why have you got on this hobby-horse? It is a non-issue. caseOf: ios not widelty used but extremely useful in certain circumstances. This has the feeling of a religious pogrom, not a rational approach to the system. IIABDFI = If It Ain't Broke, Don't Fix It. > Are these two points correct? > No, IMO, definitely not. > > Stef > >

Feb. 15, 2011

Re: [Pharo-project] Issue 3620 in pharo: Settings: OCompletion settings appear twice

by pharo＠googlecode.com

Comment #8 on issue 3620 by stephane...(a)gmail.com: Settings: OCompletion settings appear twice http://code.google.com/p/pharo/issues/detail?id=3620 Why not in the OCompletion repository?

Feb. 15, 2011

Re: [Pharo-project] Working with weak announcements...

by StÃ©phane Ducasse

>>> I think it is relatively easy to modify VM , since it touching only GC >>> related stuff. >> >> Ok how many weeks? > > I have to read the paper about it to refresh my memory.. and then > apply these concepts to squeak/cog vm reality :) if you have a pointer I'm interested in reading it.

Feb. 15, 2011

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

by Schwab,Wilhelm K

I am not completely certain who is on which side here anymore, other than #caseOf: is at the center of it. I think I saw Eliot say that Cog uses it; if I got that right, it's a pretty compelling reason to keep it in the image. Doing that, either for Cog's benefit, or even just for the convenience of a subset of users does not necessarily imply that Pharo itself needs to use the message. That is about the limit of what I can offer in the form of guidance, and it is really more of a question: could Pharo be changed to ignore the message, and then keep it in the image for Cog and other users? Maybe that is too idealistic, or just plain naive :) Mapping integers from the outside world to objects and/or behavior is something that I do a lot. I have to more or less agree with Sig; case statements as such generally point to room for a design to better exploit messaging. There are indeed scenarios (especially if not exclusively in external interfacing) that call for mapping numbers to actions. I have had great results with dictionaries for that purpose, but I am not trying to squeeze every last byte code per second out of a portable VM. There have been situations in which Smalltalkers have climbed the ivory tower and looked with contempt on things that make the world work. I am not convinced that is happening here. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of csrabak(a)bol.com.br [csrabak(a)bol.com.br] Sent: Tuesday, February 15, 2011 1:23 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise: Em 13/02/2011 21:21, Stephen Taylor < stephen.taylor(a)bom.gov.au > escreveu: 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 :) Igor's attitude, which I'll take as sample of a school of thought is dangerously similar to the one which in name of keeping certain aspects of Smalltalk "pure" or near to the origins has made its acceptance fall as the other aspects of the technology (OO, WIMP, etc.), made their way into other languages/platforms/technologies. > You didn't answer the question though. And then this: to the first concrete example, no complete answer comes out which we could check if the code construct is indeed only a syntactic sugar, or deserves incorporation in the toolset of the language... > > 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? FWIW, this kind of need, namely having to take alternate actions due different integer codes is pretty common when interfacing with industrial boards, a lot of protocols use this as well and most of them are already in use, some even have international standards. So the answer "redesign your world to fit our world-view" does not cut in... Also, another argument I've seen in this thread which is pretty commonplace w.r.t. performance must be extirpated in our discourse: "the performance x to y slower than <baseline implementation> is very good considering {dynamic} languages (or similar statement)". Performance counts! One of the reasons we're working in Pharo is to bring its performance on par with competitive technologies. We're doing things to take out 'cruft', some to make the abstractions more elegant, but some are pragmatic which require depart of breaking 'pure' Smalltalk OO way of thinking. -- Cesar Rabak > > > Steve >

Feb. 15, 2011

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

by csrabak＠bol.com.br

Adrien, Case (a.k.a "switch") constructs are not "so bad in Smalltalk" only, they are considered bad OO practice and it is tabled in the "The Object-Orientation Abuse" code smell when refactoring. there is an abundant literature about it that you can find online, so I'll refrain to make this post to long. If you folks think it is worth, we can open a different thread... -- Cesar Rabak Em 14/02/2011 20:33, Adrien BARREAU < abarreau.dev(a)live.fr > escreveu: Hi, I'm sorry to interrupt that discussion, but I read all the messages about that subject since you started to discuss it and I really would like to understand a thing: Why does the case structure seem to be so bad in Smalltalk? I hope some of you could explain me :) Adrien.

Feb. 15, 2011

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

by csrabak＠bol.com.br

Craig, Fantastic wishlist! However, maybe because the synthetic nature of the proposal, I think I missed something: How can a "...a method be transferred to another live system." as per your "4." and "Represent the state of that GUI with an object" and even be "amenable to framework change" simultaneously? -- Cesar Rabak Em 14/02/2011 08:14, Craig Latta < craig(a)netjam.org > escreveu: Hi GÃ¶ran-- Thanks for the summary! I think there's another option as well. If you have... - the ability to transfer methods directly between live systems, without having to recompile source code - a way of specifying groups of methods ("modules"), and prerequisite relationships between those groups ...then you can... 1. Compose a GUI using a direct-manipulation editor. 2. Represent the state of that GUI with an object (which probably makes references to several other objects). 3. Create a method that refers to that object. (One way to store the object would be as a class variable.) 4. Transfer that method to another live system. The method is probably little more than asking the GUI object to render itself. If you want to know more about how the GUI object was created, you can ask it that too. The method's module specifies at least of the GUI framework as a prerequisite. You can have as many different GUI frameworks around in a system as you like, perhaps introducing some as others are phased out. Perhaps message interfaces common to all of them will emerge over time. All along the way one uses familiar tools to inspect and change state and behavior. Although source code isn't necessary for transferring behavior from one system to another, it's all still readable. This scheme is readable, editable, easy to store, and amenable to framework change (the four things you were after). thanks again, -C -- Craig Latta www.netjam.org/resume +31 06 2757 7177 + 1 415 287 3547

Feb. 15, 2011

Re: [Pharo-project] Issue 3589 in pharo: ClassComment in OB

by pharo＠googlecode.com

Comment #6 on issue 3589 by guillerm...(a)gmail.com: ClassComment in OB http://code.google.com/p/pharo/issues/detail?id=3589 I'll integrate it in OB tonight

Feb. 15, 2011

Re: [Pharo-project] Issue 3620 in pharo: Settings: OCompletion settings appear twice

by pharo＠googlecode.com

Comment #7 on issue 3620 by guillerm...(a)gmail.com: Settings: OCompletion settings appear twice http://code.google.com/p/pharo/issues/detail?id=3620 These are OCompletion changes... I can move them into PharoTaskForces tonight. Will that do it?

Feb. 15, 2011

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

by csrabak＠bol.com.br

I would like to add to this discussion the following: 1) Are we willing to create a Pharo only solution to a GUI designer? Or: 2) Can we think of a Smalltalk wide new solution which could be standard and flavour agnostic, so once a programmer learns to use it, its knowledge will be useful to any Smalltalk? 3) Do we fell we should lead the way inventing a new GUI design approach, or the ones in market suffice and nullPointer's view that the designer is a commodity which we should make use of as other thing we do in Pharo, so steering us to concentrate in a set of widgets which those mainstream GUI design expect? I think if we invest in answering these questions we could arrive quickly to a feasible plan. my 0.019999 -- Cesar Rabak Em 14/02/2011 06:10, Geert Claes < geert.wl.claes(a)gmail.com > escreveu: 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. 15, 2011

Re: [Pharo-project] [COTDC] 11 - ColorMappingCanvas

by Igor Stasenko

On 15 February 2011 18:29, laurent laffont <laurent.laffont(a)gmail.com> wrote: > So the comment I propose mixing what you said with my understanding: > I'm an abstract class which introduce a filter between a drawing request and > the final output, handled by #mapColor: > For each potential pixel operation like:Â source -> op -> output > it introducing a color mapping stage:Â source -> op -> mapping -> output > Then #mapColor: can be redefined in subclasses to implement more specific > behavior. For example: > - ShadowDrawingCanvas will replace the rendered color with the color of > shadow (if not transparent). > - AlphaBlendingCanvas will add or intensify alpha of rendered color. > > For an easy to understand example see > Â #drawPolygon:color:borderWidth:borderColor: > ShadowDrawingCanvas: > see ColorMappingCanvas comment. > AlphaBlendingCanvas: > see ColorMappingCanvas comment. > Sounds good. > Laurent. > On Mon, Feb 14, 2011 at 7:57 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 14 February 2011 18:45, laurent laffont <laurent.laffont(a)gmail.com> >> wrote: >> > Today: Â ColorMappingCanvas >> > >> >> As far as i understood, this class is abstract, and its subclasses >> implement more specific behavior >> - shadow >> - semitransparency mapping >> >> >> The idea of is kind of canvas is to modify/filter the final output in >> rendering pipe.. >> i.e., for each potential pixel operation like: >> >> source -> op -> output >> >> it introducing a color mapping stage: >> >> source -> op -> mapping -> output >> >> >> So, then for instance you could make a subclass which could turn all >> colors to be grayscale (disregarding that initial input was in >> colors). >> >> in fact i think this guy took wrong direction. It is much more >> effective to let the canvas to draw whatever it wants to some >> backup/temporary surface, and once it done, simply blit + color-map >> result to destination form using one, single strike. >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > -- Best regards, Igor Stasenko AKA sig.

Feb. 15, 2011