World: r3wp

Sure it does - it allows Gabriele's function to work.

don't think it's related

Gabriele's func would work without this

be

besides in R3, the bind? func doen't return a cloned object anymore

Anton, it's not that it has any use, it's that there is no "object" 
internally, just a "context", and the bind? function creates an "object" 
for the "context" so that it can return it (there is no way to access 
a context directly). bind? does not know whether the context is already 
referenced by an existing object or not, nor has any way to get to 
any such existing objects, so it just always creates a new one.

Ahh that makes sense. So yes, an implementation detail of R2.

Has anyone noticed a max length for filenames giving to EXISTS? under 
Windows? I get a false reply, if the length of the full path is more 
than some 54 characters.

Ah, my bad. It works! I had my dir in another place. doh! ;-)

When using local blocks in functions, that is called many times, 
I often define them as:

my-block: clear []

instead of

my-block: copy []


The idea is to reuse the block (the memory area), so the garbage 
collection has less to do. Could there be any drawback in this?

I do the same thing, so I would be interested in hearing about draw 
backs. But it may also be important to specify the size of the block, 
when it's first created. That gives the garbage collector even less 
to do.

Yeah, you don't want to do that.  Because with each loop that evaluates 
the command you actually recreating the pointer.  Instead do this:

my-block: []
...
clear my-block

This way your doing less evaluation.

However, it allows you to be more flexible and possibly save some 
evaluation depending on how you implement it.

Let me give some examples.

Example 1
>> stats/evals/clear
== [1 1 1]
>> my-block: []
== []
>> loop 100 [insert my-block "somedata" clear my-block]
== []
>> stats/evals
== [506 202 103]

Example 2
>> stats/evals/clear
== [507 203 104]
>> loop 100 [my-block: clear [] insert my-block "somedata"]
== []
>> stats/evals
== [604 202 102]

Example 3
>> stats/evals/clear
== [605 203 103]
>>
>> loop 100 [insert my-block: clear [] "somedata"]
== []
>> stats/evals
== [504 202 102]

Notice that example1 is more efficient than example 2.  However, 
Example 3 takes the flexibility of setting my-block to a cleared 
block and actually is more efficient than example 1.

So unless your gonna utilize that method as in Example 3 then your 
better off with Example 1.

Am I missing something or should this function be like an operator 
or something?:

family?: func [arg1 arg2][
    if equal? type? arg1 type? arg2 [return true]
    false
]


Maybe convert >< into op! that performs that task.  Maybe there is 
another function I overlooked.

I'm running a CGI script from which I want to 'launch another script 
to do some housekeeping. The output from the launched script (including 
the Rebol banners) is returned to the browser. Is there a way to 
redirect the output from the launched Rebol session?

(I am getting this behaviour on both Mac OS X and Linux).

OK, so 'close does not return anything...so you can't  try a block 
with close if close is the last line in the block of you check if 
error? try [close whatever]

If I use instead:

if error? catch [
	close whatever
 	true
][print "will this ever get printed?"]

I'm finding a bug in loop function.  Anyone know of a problem with 
loop.  Heading to Rambo...

enough...
family?: func [arg1 arg2][
    equal? type? arg1 type? arg2
]

Yes Steeve, I was doing other things with ihe function which is why 
it had the false.  That was a remant.

Notice this  problem I'm seeing in loop:

>> d: []
== []
>> loop 2 [append d [1 [fname]]]
== [1 [fname] 1 [fname]]
>> db/get test5 d
>> d
== [1 [0] 1 [0]]
>> d: []
== []
>> append d [1 [fname] 1 [fname]]
== [1 [fname] 1 [fname]]
>> db/get test5 d
>> d
== [1 [1] 1 [1]]

I spent a couple hours checking my code and yet  it seems LOOP is 
the culprit.

would be surprising...

I don't get it either it is really strange.

try...
 loop 2 [append d copy/deep [1 [fname]]]

that works

>> loop 2 [append d copy/deep [1 [fname]]]
== [1 [fname] 1 [fname]]
>> db/get test5 d
>> d
== [1 [1] 1 [1]]

But the crazy thing is that the block contained the correct values 
without the  copy/deep.

Still seems to be a bug somewhere.

missing a copy somewhere in your code

I added copies and it didn't change anything so I removed them again.

Besides it works find it I didn't use the loop  to populate the block.

do u use poke or change block! somewhere ?

yes I use change

tried copy on that part also and it didnt' make a difference.

hmm...

See this works fine:

>> d: []
== []
>> insert tail d [1 [fname]]
== []
>> insert tail d [1 [fname]]
== []
>> d
== [1 [fname] 1 [fname]]
>> db/get test5 d
>> d
== [1 [1] 1 [1]]

It is when I get the 0's in the part that I  know it failed somewhere. 
 I get that only when using loop to fill the d block.

normal, it's different blocks, walways the same bug with a missing 
copy some

...somewhere

I copied it to death until I figured out it was in loop.

Maybe not a bug just a need to use copy/deep in loop.

Steeve, I see what you were saying.  I went ahead and fixed that 
by changing a piece of code so that the d block wasn't modified also.

It's not a bg in loop, you are reusing the inner block [fname] where 
you shouldn't.

>> d: []
== []
>> loop 2 [append d [1 [fname]]]
== [1 [fname] 1 [fname]]
>> same? second d fourth d
== true

Yeah we already determined  that.  Thanks Brian.