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@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@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@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@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-tp4643514p464... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com