- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [update 2.0] #20269

by Pavel Krivanek

Hi, it is not possible to move messages between packages. http://code.google.com/p/pharo/issues/detail?id=6607 -- Pavel On Sun, Aug 26, 2012 at 4:28 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > btw... this last change finish first step to getting rid off PackageInfo (replacing it with RPackage)... your browser will looks weird, but with some time this will be cool... just be patient :) > > Esteban > > On Aug 26, 2012, at 4:21 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> 20269 >> ----- >> >> Issue 6575: Import RPackage from MC packages with tags >> http://code.google.com/p/pharo/issues/detail?id=6575 >> >> Issue 6578: Make Monticello work with new repackaging announcements >> http://code.google.com/p/pharo/issues/detail?id=6578 > >

Aug. 27, 2012

Re: [Pharo-project] serializing DynamicVariables (Zinc so far)

by StÃ©phane Ducasse

we are not in hurry :) On Aug 26, 2012, at 4:25 PM, Frank Shearar wrote: > On 25 August 2012 20:19, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> frank would you be interested to write a chapter on dynamicVariable and delimited one? >> Because it would be really good to be able to read that. > > I would, but I'll only have time for it next month or later. I need to > write decent documentation for the library anyway, so I could always > solve both issues in one go. > > frank > >> On Aug 25, 2012, at 12:50 PM, Frank Shearar wrote: >> >>> On 25 August 2012 09:31, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >>>> Hi Sean. I am still seing the problem :( >>>> It is difficult to make it YOU to reproduce it, but it is easy that tomorrow >>>> I show it to you :) >>>> Basically, what is happening is that >>>> >>>> ZnClient >> executeRequestResponse >>>> self logRequest. >>>> ZnSignalProgress enabled ifTrue: [ HTTPProgress signal: 'Writing request' ]. >>>> request writeOn: connection. >>>> connection flush. >>>> ZnSignalProgress enabled ifTrue: [ HTTPProgress signal: 'Reading response' >>>> ]. >>>> response := request method = #HEAD >>>> ifTrue: [ ZnResponse readHeaderFrom: connection ] >>>> ifFalse: [ >>>> self streaming >>>> ifTrue: [ ZnResponse readStreamingFrom: connection ] >>>> ifFalse: [ ZnResponse readFrom: connection ] ]. >>>> self logResponse >>>> >>>> throws a mustBeBoolean in the first line "ZnSignalProgress enabled ". It >>>> seems that such expression answered the SmallINteger 30 the first time. >>>> If I take the debugger and I evaluate ZnSignalProgress enabled again, it >>>> answers me false, which is the correct value. >>>> Ahh yes, this in latest 2.0. >>> >>> I would have expected a ZnSignalProgress class >> default saying "^ >>> true" (or something else of a Boolean nature). DynamicVariables have a >>> default value of nil unless otherwise set. Or, since you're getting a >>> value of 30, something somewhere is saying ZnSignalProgress value: 30 >>> during: ["something"]... which would be very weird. >>> >>> frank >>> >>>> Thanks! >>>> >>>> >>>> On Fri, Aug 17, 2012 at 10:32 PM, Mariano Martinez Peck >>>> <marianopeck(a)gmail.com> wrote: >>>>> >>>>> Hi Frank and Sean. The problem was quite hard to reproduce. You need to >>>>> rebuild a Pharo image from a kernel using Tanker ;) >>>>> Anyway, since we are changing completely Tanker now it may have been >>>>> solved. I did a quick test (of a similar case) and it works. So once I have >>>>> the example of the kernel again I will trying again. >>>>> Thanks for offering the help! >>>>> >>>>> >>>>> On Fri, Aug 17, 2012 at 2:33 PM, Sean P. DeNigris <sean(a)clipperadams.com> >>>>> wrote: >>>>>> >>>>>> >>>>>> Mariano Martinez Peck wrote >>>>>>> >>>>>>> The first time, #enable answers something wrong. The second time it is >>>>>>> called, it seems to answer the correct value. >>>>>> >>>>>> Mariano, would you give some more details about the wrong value, the >>>>>> expected value, and the steps to reproduce? I took a look but I'm not >>>>>> seeing >>>>>> what the problem is... b.t.w. is this a 1.4 or 2.0 image? >>>>>> >>>>>> Sean >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> View this message in context: >>>>>> http://forum.world.st/serializing-DynamicVariables-Zinc-so-far-tp4643514p46… >>>>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Mariano >>>>> http://marianopeck.wordpress.com >>>>> >>>> >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>> >> >> >

Aug. 27, 2012

Re: [Pharo-project] [ANN] NativeBoost v 1.3

by Nicolas Cellier

Pharo 2.0 has implemented & -> bitAnd: and | -> bitOr: For who is dealing with bits, that's convenient, however it creates one more case of false polymorphism, these messages being used for Boolean already... Nicolas 2012/8/27 S Krish <krishnamachari.sudhakar(a)gmail.com>: > On loading up and testing NB: > > I get possibly a very basic hurdle... Obliged for a heads up.. > > Can send the stack if its needed.. > > SmallInteger(Object)>>doesNotUnderstand: #& > Receiver: 3 > Arguments and temporary variables: > aMessage: & 3 > exception: MessageNotUnderstood: SmallInteger>>& > resumeValue: nil > Receiver's instance variables: > 3 > > AJx86Instruction>>emitMod:reg:rm: > Receiver: <<error during printing>> > Arguments and temporary variables: > mod: 3 > reg: 37 > rm: 36 > Receiver's instance variables: > name: #mov > operands: an Array(EBP ESP) > machineCode: a WriteStream > position: 1 > next: <<error during printing>> > > On Fri, Aug 24, 2012 at 7:19 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> > To load NativeBoost you can follow an instructions on project page: >> > >> http://code.google.com/p/nativeboost/wiki/Installation >> >> >> -- >> Best regards, >> Igor Stasenko. >> >

Aug. 27, 2012

Re: [Pharo-project] [ANN] NativeBoost v 1.3

by S Krish

On loading up and testing NB: I get possibly a very basic hurdle... Obliged for a heads up.. Can send the stack if its needed.. SmallInteger(Object)>>doesNotUnderstand: #& Receiver: 3 Arguments and temporary variables: aMessage: & 3 exception: MessageNotUnderstood: SmallInteger>>& resumeValue: nil Receiver's instance variables: 3 AJx86Instruction>>emitMod:reg:rm: Receiver: <<error during printing>> Arguments and temporary variables: mod: 3 reg: 37 rm: 36 Receiver's instance variables: name: #mov operands: an Array(EBP ESP) machineCode: a WriteStream position: 1 next: <<error during printing>> On Fri, Aug 24, 2012 at 7:19 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > To load NativeBoost you can follow an instructions on project page: > > > http://code.google.com/p/nativeboost/wiki/Installation > > > -- > Best regards, > Igor Stasenko. > >

Aug. 27, 2012

[Pharo-project] Reef examples and documentation

by Oscar E A Callau

Hi all, Do You known where I can find examples and documentation about Reef?. It seems to be quite powerful. I just found the slides and videos from esug 2010 and 2011. Cheers Ãscar E A Callau

Aug. 26, 2012

Re: [Pharo-project] serializing DynamicVariables (Zinc so far)

by Frank Shearar

On 26 August 2012 17:55, Levente Uzonyi <leves(a)elte.hu> wrote: > On Sun, 26 Aug 2012, Frank Shearar wrote: > >> That sounds like a reasonable workaround to address Mariano's >> immediate problem :) > > > I don't see what other issues are there to solve. :) Then you should go reread my article, and the articles it references :) Both have examples of how undelimited dynamic variables don't work sensibly with delimited continuations. Kiselyov goes further and shows how they _cannot_ work sensibly. Serialising a running process implicitly creates a delimited continuation. Ergo, Fun Times! frank > Anyway, here's a highly > untested example of what I had in my mind: > http://leves.web.elte.hu/squeak/StackSerializableDynamicVariable.st Yep, using resumable exceptions to implement delimited dynamic variables. That's exactly what Control does, only without DynamicVariable necessarily polluting the global namespace. > Is uses a method in Process which is not present in current images: > > environmentAt: key ifAbsentPut: aBlock > > ^(env ifNil: [ env := Dictionary new ]) at: key ifAbsentPut: aBlock. Current _Pharo_ images, maybe. I'm pretty sure I looked at a trunk image with it in the last few hours (but obviously am too lazy to actually go check :/) frank > Levente >

Aug. 26, 2012

Re: [Pharo-project] serializing DynamicVariables (Zinc so far)

by Levente Uzonyi

On Sun, 26 Aug 2012, Frank Shearar wrote: > That sounds like a reasonable workaround to address Mariano's > immediate problem :) I don't see what other issues are there to solve. :) Anyway, here's a highly untested example of what I had in my mind: http://leves.web.elte.hu/squeak/StackSerializableDynamicVariable.st Is uses a method in Process which is not present in current images: environmentAt: key ifAbsentPut: aBlock ^(env ifNil: [ env := Dictionary new ]) at: key ifAbsentPut: aBlock. Levente

Aug. 26, 2012

Re: [Pharo-project] [update 2.0] #20269

by Esteban Lorenzano

btw... this last change finish first step to getting rid off PackageInfo (replacing it with RPackage)... your browser will looks weird, but with some time this will be cool... just be patient :) Esteban On Aug 26, 2012, at 4:21 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > 20269 > ----- > > Issue 6575: Import RPackage from MC packages with tags > http://code.google.com/p/pharo/issues/detail?id=6575 > > Issue 6578: Make Monticello work with new repackaging announcements > http://code.google.com/p/pharo/issues/detail?id=6578

Aug. 26, 2012

Re: [Pharo-project] serializing DynamicVariables (Zinc so far)

by Frank Shearar

On 25 August 2012 20:19, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > frank would you be interested to write a chapter on dynamicVariable and delimited one? > Because it would be really good to be able to read that. I would, but I'll only have time for it next month or later. I need to write decent documentation for the library anyway, so I could always solve both issues in one go. frank > On Aug 25, 2012, at 12:50 PM, Frank Shearar wrote: > >> On 25 August 2012 09:31, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >>> Hi Sean. I am still seing the problem :( >>> It is difficult to make it YOU to reproduce it, but it is easy that tomorrow >>> I show it to you :) >>> Basically, what is happening is that >>> >>> ZnClient >> executeRequestResponse >>> self logRequest. >>> ZnSignalProgress enabled ifTrue: [ HTTPProgress signal: 'Writing request' ]. >>> request writeOn: connection. >>> connection flush. >>> ZnSignalProgress enabled ifTrue: [ HTTPProgress signal: 'Reading response' >>> ]. >>> response := request method = #HEAD >>> ifTrue: [ ZnResponse readHeaderFrom: connection ] >>> ifFalse: [ >>> self streaming >>> ifTrue: [ ZnResponse readStreamingFrom: connection ] >>> ifFalse: [ ZnResponse readFrom: connection ] ]. >>> self logResponse >>> >>> throws a mustBeBoolean in the first line "ZnSignalProgress enabled ". It >>> seems that such expression answered the SmallINteger 30 the first time. >>> If I take the debugger and I evaluate ZnSignalProgress enabled again, it >>> answers me false, which is the correct value. >>> Ahh yes, this in latest 2.0. >> >> I would have expected a ZnSignalProgress class >> default saying "^ >> true" (or something else of a Boolean nature). DynamicVariables have a >> default value of nil unless otherwise set. Or, since you're getting a >> value of 30, something somewhere is saying ZnSignalProgress value: 30 >> during: ["something"]... which would be very weird. >> >> frank >> >>> Thanks! >>> >>> >>> On Fri, Aug 17, 2012 at 10:32 PM, Mariano Martinez Peck >>> <marianopeck(a)gmail.com> wrote: >>>> >>>> Hi Frank and Sean. The problem was quite hard to reproduce. You need to >>>> rebuild a Pharo image from a kernel using Tanker ;) >>>> Anyway, since we are changing completely Tanker now it may have been >>>> solved. I did a quick test (of a similar case) and it works. So once I have >>>> the example of the kernel again I will trying again. >>>> Thanks for offering the help! >>>> >>>> >>>> On Fri, Aug 17, 2012 at 2:33 PM, Sean P. DeNigris <sean(a)clipperadams.com> >>>> wrote: >>>>> >>>>> >>>>> Mariano Martinez Peck wrote >>>>>> >>>>>> The first time, #enable answers something wrong. The second time it is >>>>>> called, it seems to answer the correct value. >>>>> >>>>> Mariano, would you give some more details about the wrong value, the >>>>> expected value, and the steps to reproduce? I took a look but I'm not >>>>> seeing >>>>> what the problem is... b.t.w. is this a 1.4 or 2.0 image? >>>>> >>>>> Sean >>>>> >>>>> >>>>> >>>>> -- >>>>> View this message in context: >>>>> http://forum.world.st/serializing-DynamicVariables-Zinc-so-far-tp4643514p46… >>>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>>> >>>> >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> > >

Aug. 26, 2012

[Pharo-project] [update 2.0] #20269

by Esteban Lorenzano

20269 ----- Issue 6575: Import RPackage from MC packages with tags http://code.google.com/p/pharo/issues/detail?id=6575 Issue 6578: Make Monticello work with new repackaging announcements http://code.google.com/p/pharo/issues/detail?id=6578

Aug. 26, 2012