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

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

by pharo＠googlecode.com

Updates: Status: Fixed Comment #8 on issue 3589 by guillerm...(a)gmail.com: ClassComment in OB http://code.google.com/p/pharo/issues/detail?id=3589 Now in MetacelloRepository. Will load in next build

Feb. 16, 2011

Re: [Pharo-project] Pharo 1.2 virtual sprint

by Serge Stinckwich

Launch a doodle for a day long virtual sprint all over the world ;-) On Wed, Feb 16, 2011 at 4:54 AM, laurent laffont <laurent.laffont(a)gmail.com> wrote: > Which day you prefer ? > Laurent > On Tue, Feb 15, 2011 at 10:00 AM, StÃ©phane Ducasse > <Stephane.Ducasse(a)inria.fr> wrote: >> >> If there is internet connection where I will be hacking with alain we can >> participate :). >> >> Stef >> >> On Feb 14, 2011, at 10:01 PM, laurent laffont wrote: >> >> > Could we organize a Pharo 1.2 virtual sprint over IRC to resolve, kill, >> > eleminate, eradicate, destroy remaining issues ? and learn together too. >> > >> > I can do this next week from monday to wednesday evening (France time >> > zone). >> > >> > Laurent >> >> >> > > -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

Feb. 16, 2011

Re: [Pharo-project] Issue 2820 in pharo: Format Source shortcut key (cmd-r) doesn't work

by pharo＠googlecode.com

Comment #1 on issue 2820 by intrader.intrader: Format Source shortcut key (cmd-r) doesn't work http://code.google.com/p/pharo/issues/detail?id=2820 I have a similar problem what appeared when I loaded Version 1.1.1 of pharo. I have subsequently loaded Pharo 1.2 (Pharo1.2 rc2 Latest update #12335). I have an entry in http://news.gmane.org/gmane.comp.lang.smalltalk.squeak.seaside/23773 that describes the problem. Propblem still remains. P.S. I definitely would not see this kind of problem in eclipse or VS - sad

Feb. 16, 2011

[Pharo-project] Metacello tests failing in 1.2

by Guillermo Polito

Hi Dale! There are 13 failing tests on the 1.2 dev build since a week ago ( https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/141/testReport/ ). Do we have the right version? Do you have any clue so I don't dive in the code blindly? :) Cheers, Guille

Feb. 16, 2011

[Pharo-project] Issue 3709 in pharo: Clean OB**WithShout in omnibrowser

by pharo＠googlecode.com

Status: Accepted Owner: guillerm...(a)gmail.com Labels: Milestone-1.3-DevImage Type-OB New issue 3709 by guillerm...(a)gmail.com: Clean OB**WithShout in omnibrowser http://code.google.com/p/pharo/issues/detail?id=3709 Most of it is not needed since the styling was moved to the core.

Feb. 16, 2011

Re: [Pharo-project] Issue 3579 in pharo: "declare temp" adds the variable twice

by pharo＠googlecode.com

Updates: Status: Fixed Comment #13 on issue 3579 by guillerm...(a)gmail.com: "declare temp" adds the variable twice http://code.google.com/p/pharo/issues/detail?id=3579 Integrated and on next Hudson build

Feb. 16, 2011

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

by pharo＠googlecode.com

Comment #10 on issue 3620 by guillerm...(a)gmail.com: Settings: OCompletion settings appear twice http://code.google.com/p/pharo/issues/detail?id=3620 Yep, I' don't want to break squeak compatibility unless it's completely necessary... I guess that if we have to change the settings pragma collector, it's not fixed yet :)

Feb. 16, 2011

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

by csrabak＠bol.com.br

Em 15/02/2011 20:28, Craig Latta < craig(a)netjam.org > escreveu: > Hi Cesar-- > > > Fantastic wishlist! However, maybe because the synthetic nature of > > the proposal... > Well, I'm cheating here, because I've already implemented the > givens (live method transfer and modules). See [1] and [2]. I see. I'd a suspition but was too busy when I wrote my reply to check on Spoon... > > > ...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? > When you're done composing a GUI with an editor, you've got an > object that represents the GUI, typically a hierarchy of widgets and > event-handlers (perhaps similar to a VisualWorks viewspec, but an > original object instead of a transcription of one). The precise > nature of the objects in that hierarchy depends on your GUI > framework. Yes! this was the part that triggered my attention! > But whatever it is, you can transfer a method using it to > another live system, because (at least in the stuff I wrote) you can > transfer any method no matter what its literals are. I see, but then we have to check if a given message send may end up in MNUs, right? > So given that, you're dealing with first-class objects all the > time. I think you're partially right here: your implementation scheme gives us an impression of 'first-class' objects. If underlying framework is different enough to have the methods that when called end up in Debugger, I see this only as a kind of Grease or similar mechanism (perhaps SIXX with a bit more of semantics). I think I can see this grand vision working if some kind of 'equivalence' of widgets could be produced so that a Morphic based GUI design could be used in [say] wxWidgets based {Pharo,Squeak}. > That's what makes this scheme adaptable to GUI framework > change. You can examine GUI objects, ask them to convert themselves > to another framework's structures, etc. with familiar Smalltalk > tools. I understand that in order that be possible they would need to answer to the become: protocol and need to have in the target image both the frameworks, right? > There are no "dead-data" formats to worry about, because all > method literals get transferred as part of fundamental system > behavior, without any special consideration by the GUI framework. Well, this seems to me more or less neutral for being compelling. The representation of a GUI design, if we get a good format, could be one of the best contributions we could do to the programming comunity. As we're learning, (slowly) but it is part of our growing pains, Smalltalk does not lead the way in the design of GUIs anymore. We need to fit in an industry. The same way we needed to accomodate the ORM in order to be able do do CRUD in Smalltalks, we need to go to the GUI side and go for a more aligned with the mainstream technology and practice. With the caveat I may still have not undertood your proposal in full, I see that in limit, the right mapping would be to the host system GUI primitives, so the whole issue of having to design a specific widget hierarchy would vanish. Correct? regards, and keep the research in Spoon! -- Cesar Rabak

Feb. 16, 2011

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

by Igor Stasenko

On 15 February 2011 22:24, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2011/2/15 Igor Stasenko <siguctua(a)gmail.com>: >> 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. >> > > Totally agree with Igor. Looking at the name, it already smells like a > case of composition by inheritance. > It reminds me the RWBinaryOrTextStreamWhatElse hierarchy. > > Maybe it has some cousins like > PluggableMultipleSelectionListMorphByItem PluggableTreeMorphByItem > etc... ;) > If Pluggability is a noble feature for a GUI to have, maybe there is > no much reason to carry a HardcodedListMorphByItem... Yeah... no tools using ListMorph. Everyone using PluggableListMorph and its variants.. So, why just not merge all stuf to ListMorph? > > Nicolas > >> >>> Regards, Gary >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> > > -- 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 22:28, Benoit St-Jean <bstjean(a)yahoo.com> wrote: > Eliot, > > Now I fully understand the pain you'd have to go through (and others > involved in the VM) if we'd remove this method we don't "like"...Â I guess > it's way easier to live with #caseOf: than live without it... > yeah, in smalltalk you can just reify it to a lot of classes (one for each instruction) and implement #computeMaximumSize per each. Oh.. and you even don't have to do that per each.. if you look at code, it has size=6 for jumps. So, you can implement only 1 method in base 'jump' class, while others will simply reuse it. > CogIA32Compiler>>#computeMaximumSize, when one method is worth a thousand > words... > > > > ----------------- > Benoit St-Jean > Yahoo! Messenger: bstjean > A standpoint is an intellectual horizon of radius zero. > (Albert Einstein) > > ________________________________ > From: Eliot Miranda <eliot.miranda(a)gmail.com> > To: Pharo-project(a)lists.gforge.inria.fr > Sent: Tue, February 15, 2011 3:56:11 PM > Subject: Re: [Pharo-project] could we agree to remove caseOf: and > caseOf:otherwise: > > > > On Tue, Feb 15, 2011 at 12:39 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> Eliot >> >> I can understand that well. Now we could just let this code in VMMaker and >> not inlining. >> We fix 8 users and we are done. I have concerned that we have a complex >> solution because it is complex >> for a couple of use case. Of course we can do nothing (and we will >> probably not do it now) but in that case we can >> also stop pharo right now because a large part of the system could follow >> the exact same principle. > > That's a false distinction. Â There's nothing wrong with caseOf: and not > addressing it will not leave Pharo any the worse. Â Case statements are not > in themselves evil in the right context. Â The main problems with the > index/dictionary approach are that > a) the solution is no longer contained in a single method > b) the dictionary is metadata that needs to be updated in an initialize > method; forget to initialize the dictionary when an index changes and your > program is broken. > As my first wife said "don't sweat the petty stuff; pet the sweaty stuff". > > BTW, there's a false assumption that has been stated in this thread that the > caseOf: statement is only used with explicit integers. Â It can be used with > anything. Â Expressions, class constants etc. >> >> BTW why marcus and jorge work on Opal because the compiler is just working >> good? >> >> Now I will focus on 1.2, FS, Opal if I can help, and the rest but caseOf: >> will be in our radar. >> >> Just a remark if people would have spend the time to write mail to fix the >> users of caseof: in the image and >> other non VMmaker package we would have get already done. > > Fix this (rhetorical - I think this is /much/ better as a single case > statement than as an index/dictionary refactoring, both in Smalltalk and > when translated to C): > CogIA32Compiler>>computeMaximumSize > "Compute the maximum size for each opcode. Â This allows jump offsets to > be determined, provided that all backward branches are long branches." > "N.B. Â The ^maxSize := N forms are to get around the compiler's long branch > limits which are exceeded when each case jumps around the otherwise." > opcode caseOf: { > "Noops & Pseudo Ops" > [Label] -> [^maxSize := 0]. > [AlignmentNops] -> [^maxSize := (operands at: 0) - 1]. > [Fill16] -> [^maxSize := 2]. > [Fill32] -> [^maxSize := 4]. > [FillFromWord] -> [^maxSize := 4]. > [Nop] -> [^maxSize := 1]. > "Specific Control/Data Movement" > [CDQ] -> [^maxSize := 1]. > [IDIVR] -> [^maxSize := 2]. > [IMULRR] -> [^maxSize := 3]. > [CPUID] -> [^maxSize := 2]. > [CMPXCHGAwR] -> [^maxSize := 7]. > [CMPXCHGMwrR] -> [^maxSize := 8]. > [LFENCE] -> [^maxSize := 3]. > [MFENCE] -> [^maxSize := 3]. > [SFENCE] -> [^maxSize := 3]. > [LOCK] -> [^maxSize := 1]. > [XCHGAwR] -> [^maxSize := 6]. > [XCHGMwrR] -> [^maxSize := 7]. > [XCHGRR] -> [^maxSize := 2]. > "Control" > [Call] -> [^maxSize := 5]. > [JumpR] -> [^maxSize := 2]. > [Jump] -> [self resolveJumpTarget. ^maxSize := 5]. > [JumpLong] -> [self resolveJumpTarget. ^maxSize := 5]. > [JumpZero] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpNonZero] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpNegative] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpNonNegative] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpOverflow] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpNoOverflow] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpCarry] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpNoCarry] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpLess] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpGreaterOrEqual] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpGreater] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpLessOrEqual] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpBelow] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpAboveOrEqual] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpAbove] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpBelowOrEqual] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpLongZero] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpLongNonZero] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpFPEqual] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpFPNotEqual] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpFPLess] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpFPGreaterOrEqual] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpFPGreater] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpFPLessOrEqual] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpFPOrdered] -> [self resolveJumpTarget. ^maxSize := 6]. > [JumpFPUnordered] -> [self resolveJumpTarget. ^maxSize := 6]. > [RetN] -> [^maxSize := (operands at: 0) = 0 > ifTrue: [1] > ifFalse: [3]]. > "Arithmetic" > [AddCqR] -> [^maxSize := (self isQuick: (operands at: 0)) > ifTrue: [3] > ifFalse: [(self concreteRegister: (operands at: 1)) = EAX > ifTrue: [5] > ifFalse: [6]]]. > [AndCqR] -> [^maxSize := (self isQuick: (operands at: 0)) > ifTrue: [3] > ifFalse: [(self concreteRegister: (operands at: 1)) = EAX > ifTrue: [5] > ifFalse: [6]]]. > [CmpCqR] -> [^maxSize := (self isQuick: (operands at: 0)) > ifTrue: [3] > ifFalse: [(self concreteRegister: (operands at: 1)) = EAX > ifTrue: [5] > ifFalse: [6]]]. > [OrCqR] -> [^maxSize := (self isQuick: (operands at: 0)) > ifTrue: [3] > ifFalse: [(self concreteRegister: (operands at: 1)) = EAX > ifTrue: [5] > ifFalse: [6]]]. > [SubCqR] -> [^maxSize := (self isQuick: (operands at: 0)) > ifTrue: [3] > ifFalse: [(self concreteRegister: (operands at: 1)) = EAX > ifTrue: [5] > ifFalse: [6]]]. > [AddCwR] -> [^maxSize := (self concreteRegister: (operands at: 1)) = EAX > ifTrue: [5] > ifFalse: [6]]. > [CmpCwR] -> [^maxSize := (self concreteRegister: (operands at: 1)) = EAX > ifTrue: [5] > ifFalse: [6]]. > [SubCwR] -> [^maxSize := (self concreteRegister: (operands at: 1)) = EAX > ifTrue: [5] > ifFalse: [6]]. > [XorCwR] -> [^maxSize := (self concreteRegister: (operands at: 1)) = EAX > ifTrue: [5] > ifFalse: [6]]. > [AddRR] -> [^maxSize := 2]. > [AndRR] -> [^maxSize := 2]. > [CmpRR] -> [^maxSize := 2]. > [OrRR] -> [^maxSize := 2]. > [XorRR] -> [^maxSize := 2]. > [SubRR] -> [^maxSize := 2]. > [NegateR] -> [^maxSize := 2]. > [LoadEffectiveAddressMwrR] > -> [^maxSize := ((self isQuick: (operands at: 0)) > ifTrue: [3] > ifFalse: [6]) > + ((self concreteRegister: (operands at: 1)) = ESP > ifTrue: [1] > ifFalse: [0])]. > [LogicalShiftLeftCqR] -> [^maxSize := (operands at: 0) = 1 > ifTrue: [2] > ifFalse: [3]]. > [LogicalShiftRightCqR] -> [^maxSize := (operands at: 0) = 1 > ifTrue: [2] > ifFalse: [3]]. > [ArithmeticShiftRightCqR] -> [^maxSize := (operands at: 0) = 1 > ifTrue: [2] > ifFalse: [3]]. > [LogicalShiftLeftRR] -> [self computeShiftRRSize]. > [LogicalShiftRightRR] -> [self computeShiftRRSize]. > [ArithmeticShiftRightRR] -> [self computeShiftRRSize]. > [AddRdRd] -> [^maxSize := 4]. > [CmpRdRd] -> [^maxSize := 4]. > [SubRdRd] -> [^maxSize := 4]. > [MulRdRd] -> [^maxSize := 4]. > [DivRdRd] -> [^maxSize := 4]. > [SqrtRd] -> [^maxSize := 4]. > "Data Movement" > [MoveCqR] -> [^maxSize := (operands at: 0) = 0 ifTrue: [2] ifFalse: [5]]. > [MoveCwR] -> [^maxSize := 5]. > [MoveRR] -> [^maxSize := 2]. > [MoveAwR] -> [^maxSize := (self concreteRegister: (operands at: 1)) = EAX > ifTrue: [5] > ifFalse: [6]]. > [MoveRAw] -> [^maxSize := (self concreteRegister: (operands at: 0)) = EAX > ifTrue: [5] > ifFalse: [6]]. > [MoveRMwr] -> [^maxSize := ((self isQuick: (operands at: 1)) > ifTrue: [3] > ifFalse: [6]) > + ((self concreteRegister: (operands at: 2)) = ESP > ifTrue: [1] > ifFalse: [0])]. > [MoveRdM64r] -> [^maxSize := ((self isQuick: (operands at: 1)) > ifTrue: [5] > ifFalse: [8]) > + ((self concreteRegister: (operands at: 2)) = ESP > ifTrue: [1] > ifFalse: [0])]. > [MoveMbrR] -> [^maxSize := ((self isQuick: (operands at: 0)) > ifTrue: [3] > ifFalse: [6]) > + ((self concreteRegister: (operands at: 1)) = ESP > ifTrue: [1] > ifFalse: [0])]. > [MoveRMbr] -> [^maxSize := ((self isQuick: (operands at: 1)) > ifTrue: [3] > ifFalse: [6]) > + ((self concreteRegister: (operands at: 2)) = ESP > ifTrue: [1] > ifFalse: [0])]. > [MoveM16rR] -> [^maxSize := ((self isQuick: (operands at: 0)) > ifTrue: [4] > ifFalse: [7]) > + ((self concreteRegister: (operands at: 1)) = ESP > ifTrue: [1] > ifFalse: [0])]. > [MoveM64rRd] -> [^maxSize := ((self isQuick: (operands at: 0)) > ifTrue: [5] > ifFalse: [8]) > + ((self concreteRegister: (operands at: 1)) = ESP > ifTrue: [1] > ifFalse: [0])]. > [MoveMwrR] -> [^maxSize := ((self isQuick: (operands at: 0)) > ifTrue: [3] > ifFalse: [6]) > + ((self concreteRegister: (operands at: 1)) = ESP > ifTrue: [1] > ifFalse: [0])]. > [MoveXbrRR] -> [self assert: (self concreteRegister: (operands at: 0)) ~= > ESP. > ^maxSize := (self concreteRegister: (operands at: 1)) = EBP > ifTrue: [5] > ifFalse: [4]]. > [MoveXwrRR] -> [self assert: (self concreteRegister: (operands at: 0)) ~= > ESP. > ^maxSize := (self concreteRegister: (operands at: 1)) = EBP > ifTrue: [4] > ifFalse: [3]]. > [MoveRXwrR] -> [self assert: (self concreteRegister: (operands at: 1)) ~= > ESP. > ^maxSize := (self concreteRegister: (operands at: 2)) = EBP > ifTrue: [4] > ifFalse: [3]]. > [PopR] -> [^maxSize := 1]. > [PushR] -> [^maxSize := 1]. > [PushCw] -> [^maxSize := 5]. > [PrefetchAw] -> [^maxSize := self hasSSEInstructions ifTrue: [7] ifFalse: > [0]]. > "Conversion" > [ConvertRRd] -> [^maxSize := 4] }. > ^0 "to keep C compiler quiet" >> >> Stef >> >> >> > > >> > > >> > > 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. >> > >> > >> >> > > > -- Best regards, Igor Stasenko AKA sig.

Feb. 15, 2011