World: r4wp

Brian, it's so nice to have a Parse expert here. Thanks for your 
advice.

Just for fun :)

It's no fun when you can' t figure out why something you think should 
work doesn't :-)

Really though, you are probably one of the few who really know Parse.

Speaking of Parse. I think it could be useful to compile some kind 
of FAQ or even better a tips&tricks doc.

Graham, wait, are you using MOLD on the output? The surrounding { 
} are as much in there as the surrounding ' ' in the JS output.

Nope ... no mold

Amazon SWF holds the connection open for 60 seconds to allow events 
to appear.  This times out my http(s) connections though.  I tried 
setting system/schemes/timeout to 60 but that doesn't work??

system/schemes/default/timeout

Tried setting system/schemes/http/timeout too?

or rather system/schemses/https/timeout

Yes

put it higher than 60 seconds?...  we have tcp connections open for 
45 minutes so I don't think  REBOL is at fault ...  note that you 
have to set the default timeouts before you start opening ports (I 
assume you did this ;-).

just using the default http scheme ....

What odes this function: http://synapse-ehr.com/community/threads/what-does-this-function-do.1538/
 ?

Two things:

- It iterates through a range of numbers by step, sort of like FOR, 
returning the new value.

- It saves the state of these iterations in a block that is local 
to the function, which it calls "stack" even though it is not a stack.

Here's the function commented:

iter: func [idx start end step  /local stack][

 stack: head []  ; Saved iteration states, persistently updated, indexed 
 by idx
	; Prefill with none through idx
	while [tail? stack: at head stack idx] [insert tail stack none]
	; Initialize iteration state to end value
	if stack/1 = none [stack/1: end ]
	; Increment by step
	stack/1: stack/1 + step
	; If we've gone past the end, rotate back to the start
	if stack/1 > end [stack/1: start]
	; Return the current value of the iteration
	stack/1
]

And optimized/simplified:

iter: func [idx start end step /local stack][

 stack: []  ; head unnecessary, the inline value is at its head already

 insert/dup tail stack none idx - length? stack  ; faster than while

 stack: at stack idx  ; will succeed now, position doesn't persist 
 between calls

 stack/1: step + any [stack/1 end]  ; initialize and increment in 
 one step
	if stack/1 > end [stack/1: start]
	stack/1
]


Note that the function doesn't work if idx, start and end aren't 
numbers, start isn't less than end, and step isn't greater than 1. 
However, all of the code that calls it has these qualities.

Hi, I would have used stack: copy []  but this is not necessary here? 
Because stack is local?

If you use COPY it won't persist between function calls.

It is stil confusing (to me) because the variable 'stack' is declared 
to be a local variable.

stack: []  ; head unnecessary, the inline value is at its head already
 - are you sure?

aha, yes, it is correct

It is stil confusing (to me) because the variable 'stack' is declared 
to be a local variable.
 - more confusing is that it is not a stack as Brian pointed out

Arnold, 'stack is local to the function.  Ordinarily you would make 
a copy each time the function is called so that you have an empty 
new block.  But here the function does not so that the block contents 
are available unchanged between calls.

So, I guess my question is .. when do local variables get garbage 
collected?

When do local variables get garbage collected?
 - never, only in case they are not accessible

,i.e. only in case the function is collected

however, the STACK local variable is actually not just "local variable", 
it is a value in the function body. In this case the only way how 
the value could be collected is to collect the function

so you would have to unset the function ?  Or just set it to none?

However, the function looks strange to me. I guess that it should 
have been implemented differently.

so you would have to unset the function ?

 - you cannot unset a function. You can only unset the variable referring 
 to it.

yes, that's what I meant

Arnold, if you are proficient at language C,  R2's local word model 
is the same as static variables in C.

E.g.

    f: func [] []
    unset 'f

would make the function inaccessible (collectable), but, e.g.

    g: func [][]
    g: 1

makes the function inaccessible (collectable) as well

that wasn't worded how I meant it...

R2's local word model is the same as static variables in C.
 - hmm, there are some significant differences

Arnold, What I meant to say (and what ladislav is trying to say, 
I think) is that the code inside a function is not Garbage collected, 
so when a function has a litteral value.. that litteral value is 
the same at each execution (its static).

the local values are reset to none at each execution, but they will 
be re-assigned to the same litteral.

(which is why they look like static variables in terms of series 
which are references)

So, anonymous functions are automatically garbage collected?

no.  it depends if they are referenced at least once in a value which 
is not also GCd.

so if you have a function in a block, named or not, it won't be GCd 
if that block is still refered to somewhere.

so let's say you have something in a vid defintion

button "Test" [
	use [ f ][
		f: func [] []
	]
]

this is not subject to GC?

the local values are reset to none at each execution
 - that should have been:


the local variables are reset to NONE at every function call. After 
the function returns, the local variables are:
- in R2 they 
remember" the last (outermost call) value
- in R3 their values are inaccessible

this is not subject to GC?

 - Such a function looks like a subject to GC, but you need to find 
 out *when*.


- in R2 it is a subject to GC right after the button is pressed and 
released

- in R3 the function *may* persist after the button is pressed for 
the first time and *before* it is pressed for the second time

@Ladislav, have you written a paper on GC in Rebol ?

Aha, I was wrong with R2, actually in R2 the function persists between 
presses as well, but the reasons are different for R2 and R3

have you written a paper on GC in Rebol ?

 - the reason why the function persists between presses in R2 is based 
 on the fact that USE modifies its argument block "leaving" the local 
 variable in it. (it is described in Bindology). In R3 USE is a closure 
 written in REBOL, that is why there may be some "persistence" until 
 the USE function is called next time

IIRC in R3 closures do a BIND/copy of their bodies at every call, 
then execute the copy. As soon as the USE is finished executing its 
context and body are no longer referenced, at least if you didn't 
save a reference elsewhere. The context containing the 'f and the 
function it references would be able to be GC'd as soon as the USE 
returns.

The CLOSURE function in R2 should behave the same way, though it 
fakes it with mezz code.

Checked the USE implementation in R3 (source use) and you are right, 
Brian, so, the function in R3 shall not persist at all.