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

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

by Richard Durr

I do not really like QT and would prefer somethink more mac like. On Tue, Feb 15, 2011 at 9:21 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > tx! > > > Here is more information: > > > > > http://stackoverflow.com/questions/596382/what-describes-an-outlet-best-in-… > > > http://developer.apple.com/library/mac/#documentation/DeveloperTools/Concep… > > >

Feb. 15, 2011

Re: [Pharo-project] [COTDC] 12 - PluggableListMorphByItem

by Igor Stasenko

On 15 February 2011 21:12, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I would love that you show me that. I will ask alain to show me that too. > I want to learn that and we fix them. > most of them are just adding indirection to some state and/or behavior. At cost of adding a lot of extra ivars. In general there is a quite visible pattern: every time people think that it's cool to make some morph's properties customizable, they adding ivar + accessors to PluggableXXX morphs. And since there is virtually no limits of how many "useful" new or custom properties could be added to widgets, the tendency of growth of these things to some horrid mosters become higher and higher. So, the question arises: should we rethink the model instead? And think towards adding extra/fresh properties to existing class(es) instead of making subclass with weird names which look like a piece of junk. > Stef > > > >> On 15 February 2011 19:03, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: >>> "Essentially useless in its current form. Probably intended to eventually >>> deal with actual objects in the list rather than indexing/string-forms." >> >> >> every time i looking at those pluggableXYZ. and it always one thought >> don't let me rest: >> - we don't need them. >> >> They are implementing/perverting functionality of base widgets. >> Because for most of them, they addding no value comparing >> to base widgets, but just some extended interface(s) on top. >> >> >>> Regards, Gary >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > -- Best regards, Igor Stasenko AKA sig.

Feb. 15, 2011

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

by StÃ©phane Ducasse

tx! > Here is more information: > > http://stackoverflow.com/questions/596382/what-describes-an-outlet-best-in-… > http://developer.apple.com/library/mac/#documentation/DeveloperTools/Concep…

Feb. 15, 2011

Re: [Pharo-project] [COTDC] 12 - PluggableListMorphByItem

by StÃ©phane Ducasse

I would love that you show me that. I will ask alain to show me that too. I want to learn that and we fix them. Stef > On 15 February 2011 19:03, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: >> "Essentially useless in its current form. Probably intended to eventually >> deal with actual objects in the list rather than indexing/string-forms." > > > every time i looking at those pluggableXYZ. and it always one thought > don't let me rest: > - we don't need them. > > They are implementing/perverting functionality of base widgets. > Because for most of them, they addding no value comparing > to base widgets, but just some extended interface(s) on top. > > >> Regards, Gary >> > > > > -- > Best regards, > Igor Stasenko AKA sig. >

Feb. 15, 2011

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

by Igor Stasenko

On 15 February 2011 20:58, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Tue, Feb 15, 2011 at 11:18 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 15 February 2011 19:59, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> > >> > >> > 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 >> > >> >> so why not put it: >> >> ^ (long bitShift: (-8*lowBits) ) bitAnd: 16rFF >> >> ? >> Or this will be slower than caseOf: ? > > Because that was the way the code was written. Â I just copied the method. > Â Further, it is only one example. Â I'm not going to rewrite the VMMaker's > uses of caseOf: jyst to suit some whim of purity. Â It is making unnecessary > work. Â Taking it out is *much* more work (/and/ emotional energy) than just > leaving it alone. Â Can't we try and be constructive? > i'm not forcing you or someone else to take it out. I just don't see a need to keep it in compiler, because its not worth it. It adds too much complexity to code generation and decompilation. Maybe it will be a lot slower without compiler support. But i'd rather implement a primitive which will speed up a dictionary lookup by a factor of X, than keep supporting this huge pile of complexity in compiler. >> >> >> >> >> Â Â Â Â - 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. >> >> This concept kinda appeal to me. >> From other side, i am also strongly feel that house should be kept clean >> :) >> >> >> >> >> Are these two points correct? >> > >> > No, IMO, definitely not. >> > >> >> >> >> Stef >> >> >> > >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > -- Best regards, Igor Stasenko AKA sig.

Feb. 15, 2011

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

by pharo＠googlecode.com

Comment #7 on issue 3589 by guillerm...(a)gmail.com: ClassComment in OB http://code.google.com/p/pharo/issues/detail?id=3589 Integrated in OB 1.2.4 (in PharoOB)

Feb. 15, 2011

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

by Igor Stasenko

On 15 February 2011 20:38, <csrabak(a)bol.com.br> wrote: > Em 15/02/2011 17:03,Â Igor Stasenko < siguctua(a)gmail.com > escreveu: > On 15 February 2011 19:23,Â wrote: > >> > 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. >> > >> Â I am not opposed to innovations or cross-breeding techs. Â My purism >> lies on simple principle: KISS. Â If something could be made simpler >> without losing key features then it should done. > > Your KISS principle has to come at odds with another one, which was the reason why the construct was put in place: performance. > > This is called engineering, it is the art of trade off. > So we will never agree here. We are different and having different view on it. >> >> >> >> 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... >> > Â I don't Â see Â a need Â of Â explaining how Â to Â interpret a Â simple >> translation without using caseOf: statement. > > You don't, because you already decided that what it is at stake doesn't > matter for Pharo. > > I'm just trying to recap here: the construct is not here to mud the purity of a beatiful OO language nor be incentive to bad code smells. Â It has been put to solve a particular problem in a very specific part of the system. > nope. I suspecting that it is there to mimic C switch statement.. because some people, when discovering something new, often trying to bring everything they knew/used before. Even if it doesn't fit.. But they are loving they old toys too much for just leaving them behind. Or they faulty thinking that some cool technique that served well for them in one case, will serve as well everywhere , not depending on environment. Such people are not trying to adapt themselves to new environment, instead they trying to adapt environment for themselves. > >> >> >> Â > 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. >> Â And i suspect that all these standards are properly documented, and >> each signal/number having its description, so you can represent them >> by names, not by numbers. >> > > I may lost something, but how will you convert the numbers in names to start with? > name := numbers at: number. where numbers is dictionary/table/whatever which contains translation. Even C code using defines to represent numbers by names. So, what you prefer to see in code. This: switch (response) case 1: .. case 2: .. case 3: .. or this: #define Yes 1 #define No 2 #define NotSure 3 switch (response) case Yes: .. case No: .. case NotSure: ... and what code to your thinking having better chance to evolve and/or live longer than its original author? > >> > So the answer "redesign your world to fit our world-view" does not >> > cut in... >> > >> Â I'm not asking Â you to redesign C world to Â fit smalltalk view. Use >> each Â tool Â what it Â made Â for. Â What i Â asking Â is Â to Â not use Â a >> microscope for hammering nails. Hammer is much better tool for that. >> > > This statement is called in Informal Logic "the Fallacy of the False Analogy". > You may call it however you like. Just don't convince me that it is a good idea to come to lab and use microscope for hammering nails. Because its shape somewhat reminds the hammer you using in garage. >> > 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 Â is Â very good Â considering >> >{dynamic} languages (or similar statement)". >> > Performance counts! >> Â Sure. At Â some point if you Â train long enough you Â can hammer nail >> using Â microscope much Â faster Â than using Â hammer. Â But that Â still >> doesn't means that you doing it right :) > > As I already pointed out, your base reasoning is false, this is consequentially /non sequitur/. > > > -- Best regards, Igor Stasenko AKA sig.

Feb. 15, 2011

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

by Eliot Miranda

On Tue, Feb 15, 2011 at 11:18 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 15 February 2011 19:59, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > > > 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 > > > > so why not put it: > > ^ (long bitShift: (-8*lowBits) ) bitAnd: 16rFF > > ? > Or this will be slower than caseOf: ? > Because that was the way the code was written. I just copied the method. Further, it is only one example. I'm not going to rewrite the VMMaker's uses of caseOf: jyst to suit some whim of purity. It is making unnecessary work. Taking it out is *much* more work (/and/ emotional energy) than just leaving it alone. Can't we try and be constructive? > > > >> > >> - 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. > > This concept kinda appeal to me. > From other side, i am also strongly feel that house should be kept clean :) > > >> > >> Are these two points correct? > > > > No, IMO, definitely not. > > > >> > >> Stef > >> > > > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

Feb. 15, 2011

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

by Richard Durr

Here is more information: http://stackoverflow.com/questions/596382/what-describes-an-outlet-best-in-… http://developer.apple.com/library/mac/#documentation/DeveloperTools/Concep… On Mon, Feb 14, 2011 at 9:41 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > What is happening if the class of your application UI gets a new variables > or if a superclass changes its structure? > May be in objective-C you have to resave your nib? > I do not know. > > Stef > > > > 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. 15, 2011

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

by Hilaire Fernandes

Le 14/02/2011 21:52, StÃ©phane Ducasse a Ã©crit : > >> 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. > > It is now. > We spent one hour together with ben and it was not difficult. Just needed time > of people knowing both sides of the problems and we also fixed 1.3 Great! Hilaire

Feb. 15, 2011