World: r3wp

i used the first alpha release

I'll yield to those that have used the Alpha a bit more as I really 
couldn't speculate at this point even.

Steeve, it does look odd, like a bug.

These are ok.
>> same? o do bind [self] o
== true
>> same? o do bind [self] in o 'b
== true

If you think it is a bug Anton, then you should report it to Rambo 
assuming your talking about R2.

I leave this honour to Steeve. :)

boring...

There are no tickets that match a search for "bind?" in Rambo.

so you are the one who will fill the hole ;-)

Aha! I like your style of humour! :)

especialy when we know that the word humour has a greek root  meaning 
FLUID

Steeve, o and the result of bind? are the same context but not the 
same object. this is an implementation detail of R2.

I do not think this is a bug, and it may not be trivial to fix it 
if it was (which means, it'll never get fixed as Carl is not going 
to spend that much time on R2 for something not important)

i agree Gab, for me, it's not a bug but a functionnality

What use does it have ?

none for the moment... ;-)

i

in R3 it would be usefull combined with the ability to expand an 
object

it would be something like an inheritance link

a dynamic one

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