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

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

by Sven Van Caekenberghe

On 28 Jul 2011, at 12:54, Lukas Renggli wrote: > What I want to do next is replace Kom with Zn in Seaside 3.0, Magritte 2 and Pier 2 images. OK, please let me know ASAP if run into any issues. Sven

July 28, 2011

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

by Damien Cassou

On Thu, Jul 28, 2011 at 11:39 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > 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. So I guess I can't use Ring as a meta-model for building browsers with Glamour. -- 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] cool to see pier, and other running on 1.3

by Sven Van Caekenberghe

On 28 Jul 2011, at 12:41, Sven Van Caekenberghe 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 One request, Lukas: would you please consider loading 'Zinc-Seaside' from http://www.squeaksource.com/ZincHTTPComponents with Seaside builds ? Zinc is a default part of Pharo 1.3 and this small package (just two classes) adds another Seaside Server Adaptor alternative. Whether you use it (by default) or not, that is entirely up to you. But by including it, chances are more people will use and (stress) test it. Thx, Sven PS: And just for fun, have a look at how cool GLMOrangeUITheme looks on your background ;-)

July 28, 2011

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

by Norbert Hartl

Am 28.07.2011 um 12:54 schrieb Lukas Renggli: > What I want to do next is replace Kom with Zn in Seaside 3.0, Magritte > 2 and Pier 2 images. Very good idea! Norbert

July 28, 2011

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