- Pharo-dev - lists.pharo.org

Re: [Pharo-project] cool to see pier, and other running on 1.3

by Lukas Renggli

Yep, here: https://twitter.com/renggli/status/96470364368023552 I haven't thoroughly tested everything yet, but unit tests pass and everything works smoothly. What I want to do next is replace Kom with Zn in Seaside 3.0, Magritte 2 and Pier 2 images. Lukas On 28 July 2011 12:41, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > Yes, this is very cool indeed. > > On 28 Jul 2011, at 11:59, StÃ©phane Ducasse wrote: > >> Hi lukas >> >> this is cool to see all your projects running on 1.3. >> I see that somewhere (tweet) but could not find it anymore (too many windows open and too much information). >> but this is cool. >> >> Stef >> >> > > > -- Lukas Renggli www.lukas-renggli.ch

July 28, 2011

Re: [Pharo-project] cool to see pier, and other running on 1.3

by Sven Van Caekenberghe

Yes, this is very cool indeed. On 28 Jul 2011, at 11:59, StÃ©phane Ducasse wrote: > Hi lukas > > this is cool to see all your projects running on 1.3. > I see that somewhere (tweet) but could not find it anymore (too many windows open and too much information). > but this is cool. > > Stef > >

July 28, 2011

[Pharo-project] cool to see pier, and other running on 1.3

by StÃ©phane Ducasse

Hi lukas this is cool to see all your projects running on 1.3. I see that somewhere (tweet) but could not find it anymore (too many windows open and too much information). but this is cool. Stef

July 28, 2011

Re: [Pharo-project] Downloading 1.4

by StÃ©phane Ducasse

On Jul 27, 2011, at 1:20 AM, Sean P. DeNigris wrote: > > Esteban Lorenzano wrote: >> >> El 26/07/2011, a las 7:48p.m., Sean P. DeNigris escribiÃ³: >>> >>> Igor Stasenko wrote: >>>> >>>> Okay, so far, Quicktime builds ok (but i have no idea how to test if it >>>> working). >>>> >>> I can test it. Just point me to the VM. >>> >> >> https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/Cog-Mac-Cocoa/ >> > > I successfully played a .flv video file in a 1.3 image using the VM. can you provide the code snippet :) > > HTH, > Sean > > -- > View this message in context: http://forum.world.st/Downloading-1-4-tp3696454p3697265.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

July 28, 2011

Re: [Pharo-project] DNU with beMethodArg?

by StÃ©phane Ducasse

I added your mail to the bug entry so that it is not lost. This is part of my next year objectives to understand deeply all the context internals and friends. Stef On Jul 27, 2011, at 8:50 PM, Eliot Miranda wrote: > Hi Steph, > > this is an interesting bug with Debugger doits inside Debugger doits. So at the outer level one has some method m0 in the debugger: > > nextEvent > "Return the next event from the receiver." > eventQueue == nil > ifTrue:[^self nextEventSynthesized] > ifFalse:[^self nextEventFromQueue] > > and in the right-hand context inspector one evaluates the following (which will cause a subscript bounds because there are no temps) > > ThisContext namedTempAt: 1 > > to create m1: > > DoItIn: ThisContext > ^ ThisContext namedTempAt: 1 > > If in the debugger on m1 I evaluate e.g. ThisContext I get the below error in the compiler as it is trying to create m2 > > The underlying bug is that in m2 ThisContext is ambiguous. It can refer to the context for m1 or, as the programmer intends, the context for m0. What the programmer means to achieve is an m2 that reads > > DoItIn: ThisContext > ^ (ThisContext tempAt: 0) namedTempAt: 1 > > where ThisContext tempAt: 0 accesses thisContext in m0. > > The symptom is due to Encoder>>init:context:notifying: binding ThisContext twice in > > aContext ~~ nil ifTrue: > [| homeNode | > homeNode := self bindTemp: self doItInContextName. > "0th temp = aContext passed as arg" > aContext tempNames withIndexDo: > [:variable :index| > scopeTable > at: variable > put: (MessageAsTempNode new > receiver: homeNode > selector: #namedTempAt: > arguments: (Array with: (self encodeLiteral: index)) > precedence: 3 > from: self)]]. > > since aContext tempNames includes 'ThisContext' which is also self doItInContextName. > > I'm not sure how to fix this. One way is for the above loop to encode 'ThisContext' as 'ThisContext tempAt: 0', but that only works one level deep. Once one has an m3 it will access the wrong ThisContext, but it'll be better than the current situation as there will be no exception. > > On Tue, Jul 26, 2011 at 7:02 AM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > Hi guys > > I was debugging some bug and I got the following > > > DoItIn: ThisContext > ^ self > do: [:each | ((ThisContext namedTempAt: 1) > includes: each) > ifFalse: [^ false]] > > > I selected (ThisContext namedTempAt: 1 > > and I got MessageAsTempNode does not understand beMethodArg > > method: doit context: ctxt > " pattern [ | temporaries ] block => MethodNode." > > | sap blk prim temps messageComment methodNode | > properties := AdditionalMethodState new. > sap := self pattern: doit inContext: ctxt. > "sap={selector, arguments, precedence}" > properties selector: (sap at: 1). > encoder selector: (sap at: 1). > (sap at: 2) do: [:argNode | argNode beMethodArg]. > ^^^^ > doit ifFalse: [self pragmaSequence]. > temps := self temporaries. > messageComment := currentComment. > currentComment := nil. > doit ifFalse: [self pragmaSequence]. > prim := self pragmaPrimitives. > self statements: #() innerBlock: doit. > blk := parseNode. > doit ifTrue: [blk returnLast] > ifFalse: [blk returnSelfIfNoOther: encoder]. > hereType == #doIt ifFalse: [^self expected: 'Nothing more']. > self interactive ifTrue: [self removeUnusedTemps]. > methodNode := self newMethodNode comment: messageComment. > ^methodNode > selector: (sap at: 1) > arguments: (sap at: 2) > precedence: (sap at: 3) > temporaries: temps > block: blk > encoder: encoder > primitive: prim > properties: properties > > > argNode is a MessageAsTempNode and beMethodArg is only defined on TempVariableNode > > > http://code.google.com/p/pharo/issues/detail?id=4551 > > Stef > > > > > > -- > best, > Eliot >

July 28, 2011

Re: [Pharo-project] DNU with beMethodArg?

by StÃ©phane Ducasse

Thanks I should digest that :) Now resting on holidays... should not read mails for a real cure but I do not succeed yet. Stef On Jul 27, 2011, at 8:50 PM, Eliot Miranda wrote: > Hi Steph, > > this is an interesting bug with Debugger doits inside Debugger doits. So at the outer level one has some method m0 in the debugger: > > nextEvent > "Return the next event from the receiver." > eventQueue == nil > ifTrue:[^self nextEventSynthesized] > ifFalse:[^self nextEventFromQueue] > > and in the right-hand context inspector one evaluates the following (which will cause a subscript bounds because there are no temps) > > ThisContext namedTempAt: 1 > > to create m1: > > DoItIn: ThisContext > ^ ThisContext namedTempAt: 1 > > If in the debugger on m1 I evaluate e.g. ThisContext I get the below error in the compiler as it is trying to create m2 > > The underlying bug is that in m2 ThisContext is ambiguous. It can refer to the context for m1 or, as the programmer intends, the context for m0. What the programmer means to achieve is an m2 that reads > > DoItIn: ThisContext > ^ (ThisContext tempAt: 0) namedTempAt: 1 > > where ThisContext tempAt: 0 accesses thisContext in m0. > > The symptom is due to Encoder>>init:context:notifying: binding ThisContext twice in > > aContext ~~ nil ifTrue: > [| homeNode | > homeNode := self bindTemp: self doItInContextName. > "0th temp = aContext passed as arg" > aContext tempNames withIndexDo: > [:variable :index| > scopeTable > at: variable > put: (MessageAsTempNode new > receiver: homeNode > selector: #namedTempAt: > arguments: (Array with: (self encodeLiteral: index)) > precedence: 3 > from: self)]]. > > since aContext tempNames includes 'ThisContext' which is also self doItInContextName. > > I'm not sure how to fix this. One way is for the above loop to encode 'ThisContext' as 'ThisContext tempAt: 0', but that only works one level deep. Once one has an m3 it will access the wrong ThisContext, but it'll be better than the current situation as there will be no exception. > > On Tue, Jul 26, 2011 at 7:02 AM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > Hi guys > > I was debugging some bug and I got the following > > > DoItIn: ThisContext > ^ self > do: [:each | ((ThisContext namedTempAt: 1) > includes: each) > ifFalse: [^ false]] > > > I selected (ThisContext namedTempAt: 1 > > and I got MessageAsTempNode does not understand beMethodArg > > method: doit context: ctxt > " pattern [ | temporaries ] block => MethodNode." > > | sap blk prim temps messageComment methodNode | > properties := AdditionalMethodState new. > sap := self pattern: doit inContext: ctxt. > "sap={selector, arguments, precedence}" > properties selector: (sap at: 1). > encoder selector: (sap at: 1). > (sap at: 2) do: [:argNode | argNode beMethodArg]. > ^^^^ > doit ifFalse: [self pragmaSequence]. > temps := self temporaries. > messageComment := currentComment. > currentComment := nil. > doit ifFalse: [self pragmaSequence]. > prim := self pragmaPrimitives. > self statements: #() innerBlock: doit. > blk := parseNode. > doit ifTrue: [blk returnLast] > ifFalse: [blk returnSelfIfNoOther: encoder]. > hereType == #doIt ifFalse: [^self expected: 'Nothing more']. > self interactive ifTrue: [self removeUnusedTemps]. > methodNode := self newMethodNode comment: messageComment. > ^methodNode > selector: (sap at: 1) > arguments: (sap at: 2) > precedence: (sap at: 3) > temporaries: temps > block: blk > encoder: encoder > primitive: prim > properties: properties > > > argNode is a MessageAsTempNode and beMethodArg is only defined on TempVariableNode > > > http://code.google.com/p/pharo/issues/detail?id=4551 > > Stef > > > > > > -- > best, > Eliot >

July 28, 2011

Re: [Pharo-project] Morph does not refresh or show

by StÃ©phane Ducasse

>> I would say, that's the only way how morphs should animate themselves. >> Because if you do it otherwise (like in a loop), then you pausing a >> rest of processing, blocking UI etc and this is not good. > > I agree, but the above code does not have that problem. In fact it > works pretty well, i.e. when the system is busy/slow it just sets the > end state of the animation. > >> A good example for morphs animation is bouncing atoms. But i'm not >> sure if it still residing in pharo images. > > Now if somebody is looking for an interesting project I would suggest > to implement CoreAnimation clone > (http://en.wikipedia.org/wiki/Core_Animation) CoreAnimation is a > beautiful and powerful object-oriented animation system for Cocoa. It > should be strait forward to port the API, because Cocoa is essentially > a nice implementation of Morphic. > Thanks for the pointer. I really think that we should start to move and have sexy new stuff. I hope that soon we will be done with the basic infrastructure of Pharo (file, collection, compiler...) so that we can do more fun stuff > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

July 28, 2011

Re: [Pharo-project] [update 1.4] #14060

by StÃ©phane Ducasse

(Point>>#dist:) asRingDefinition Now there is no automatic creation (because it would mean reifying everything). Now may be we will provide an interface. RIght now you have to explicitly create ring objects or convert existing ones to ring. We will add = because this is missing. Stef On Jul 27, 2011, at 12:50 PM, Damien Cassou wrote: > On Tue, Jul 26, 2011 at 7:38 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> so far veronica did a MC bridge and also >> You can have a look in the ringCaseStudy for example veronica creates ring object to replace the pseudoClass >> So normally ring use the API (or will use the API of ring) and we will be able to browse remote or pseudo or class in another kernel. > > That's blabla :-). How do I get the Ring meta-model instantiated for my image? > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry >

July 28, 2011

Re: [Pharo-project] [update 1.3] #13289

by Lukas Renggli

Thank you! On 28 July 2011 11:29, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 13289 > ----- > > Issue 4555: Â Â Fix SUnit to prevent forked process from escaping to debugger > Issue 4558: Â Â Test Runner UI is strange > > > -- > Marcus Denker -- http://marcusdenker.de > > > -- Lukas Renggli www.lukas-renggli.ch

July 28, 2011

Re: [Pharo-project] [update 1.3] #13288

by Lukas Renggli

Great. Thanks a lot :-) On 28 July 2011 11:19, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 13288 > ----- > > Issue 4500: Â Â Put SUnit-Help be put into a separate package > Issue 4508: Â Â SimpleMorphic package is back. Remove > > > > -- > Marcus Denker -- http://marcusdenker.de > > > -- Lukas Renggli www.lukas-renggli.ch

July 28, 2011