On Sat, 25 Aug 2012, Frank Shearar wrote:
On 25 August 2012 14:30, Levente Uzonyi <[email protected]> wrote:
On Sat, 25 Aug 2012, Sven Van Caekenberghe wrote:
The nil default is used as a 'not set' third value.
ZnSignalProgress class>>#enabled
"Answer if HTTPProgress should be signalled.
The default is false."
^ self value
ifNil: [ false ]
ifNotNil: [ :value | value ]
ZnClient>>#withProgressDo: block
^ ZnSignalProgress value
ifNil: [
ZnSignalProgress
value: self signalProgress
during: [ ^ block value ] ]
ifNotNil: [
block value ]
DynamicVariables are stored in the env variable of Process, the stack
doesn't store this information, so if you're about to serialize a state of a
Process, then you have to serialize the env variable too, otherwise you'll
lose information.
I'm sure that's what I said in my initial response to Mariano's
question :) Yes, indeed, that is precisely the problem with
DynamicVariable. (Scala's and Clojure's dynamic variables suffer the
same problem.) That's why these guys don't play well with stack
slicing & dicing
(http://www.lshift.net/blog/2012/06/27/resumable-exceptions-can-macro-express-delimited-dynamic-variables).
Handily, http://ss3.gemstone.com/ss/Control _does_ do this - keep the
information on the stack, that is. Look at the
DelimitedDynamicVariable tests in that package.
Yeah, right, but it lacks the performance advantage of DynamicVariable
over Exceptions. I don't think it's too much hassle to serialize the
variables of the Process besides the stack (sometimes you just can't
avoid it), but if you think it is, then a mixed system is the best
solution:
- store the value both in the process and on the stack
- start the lookup in the process first, if the variable is not found
there, then continue on the stack and store the result in the process
before returning it, so it will be found next time there
Levente
frank
Levente
ZnClient>>#signalProgress
"Return true if I signal HTTPProgress notifications during
execution."
^ self optionAt: #signalProgress ifAbsent: [ false ]
Sven
On 25 Aug 2012, at 12:50, Frank Shearar <[email protected]> wrote:
On 25 August 2012 09:31, Mariano Martinez Peck <[email protected]>
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
<[email protected]> 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
<[email protected]>
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-tp4643514p4644374.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
--
Mariano
http://marianopeck.wordpress.com
--
Mariano
http://marianopeck.wordpress.com
