World: r3wp

It is definitely not #1506, though the behavior of the first example 
was complained about in that ticket.

The behavior in the first example is arguably correct, but let's 
not rehash that argument. See #1506 for details.

As Andreas said in another group, /wait works with CALL under Windows, 
but there is no /output refinement yet. I believe RT is hoping for 
outside help on CALL for R3 due to its complexity under R2. I don't 
know if there's a bounty for it or not.

there were some bounties for some R3 related stuff, but I don't remember 
if it was for CALL, most probably not ...

No bounties offered by RT though

Carl did offer to provide the ODBC sources but that has not happened 
either

You have a R2 implementation of CALL for Windows here: http://code.google.com/p/cheyenne-server/source/browse/trunk/Cheyenne/misc/call.r


Shouldn't be difficult to port it to C and extend the existing R3's 
CALL implementation to support /output, /input and /error.

Too bad about /wait not being optional there. Is that a solvable 
problem?

This is the non-blocking version: http://softinnov.org/rebol/acall.shtml

The issue with this async CALL is that it's not possible to make 
user events in R2's event loop, so it's relying on a dirty port hack 
and a bit of busy looping IIRC.

I was thinking of fire and forget, but that was my next question.

Async call, and async in general, is a lot easier in R3. I would 
be quite interested in an async call port in R3, particularly when 
we start to get port plumbing.

From a quick glance at Cheyene's call.r, enabling /wait should be 
rather simple: don't enter the final UNTIL loop unless WAIT (or OUTPUT, 
or ERROR) is set.

I think you could also get rid of the until loop completely, by using 
WaitForSingleObject to wait for process termination. Which is exactly 
how the current win32 hostkit does it, btw.

but then, you probably couldn't in cheyenne, as it will block everything 
else.

In fact, this blocking mezz-level CALL is used in worker process 
where it's allowed to wait. Right, WaitForSingleObject is the correct 
way, this CALL was just a quick adaptation of my async version for 
Cheyenne (I needed to pass environments variables to a child process 
for CGI support),  but I think I'll drop it in next Cheyenne revisions 
and use a different approach.

I had a question regarding event handling in REBOL 2. Please let 
me know the appropriate forum for that sort of question. :)

Try Core or View.

Or "Rebol School" :)

Thanks, sorry. Works for me. :)

Me: "What makes CASE/all different from a long sequence of IFs?"
Brian: "Maintainability of code."


That's probably an effect of CASE/all enforcing a strict sequence 
of IFs, i.e. without other (unconditional) code blocks in between 
those IFs.

But this is probably only a matter of discipline, as one can easily 
smuggle uncoditional code into CASE/all too (by using #[true] as 
condition).

At which point, all that's left with CASE/all is one additional level 
of indentation.

And maybe a more efficient evaluation in case of R3.

Yes to both of those. With the old LOAD, noone other than me could 
add features because the old control flow was too complex. With the 
new LOAD and LOAD-HEADER, features were easy to add.

The most efficient way to add non-conditional code is to put the 
code in the conditional clause and have none for the associated code 
block. There are several lines like that in LOAD-HEADER.

And it is definitely more efficient evaluation in R3, and R2 as well.

What makes CASE/all different from a long sequence of IFs?

 - as far as I am concerned, I simply don't use, and never used CASE/ALL

You should try it, it's not bad.

Do not have any code where it would be of any advantage

As far as the maintainability of the code goes, it shall be noted, 
that CASE/ALL is one of the worst constructs to test.

I have two CASE/ALLs in NLPP (Ladislav knows what NLPP is). :-)

http://www.saphirion.com/downloads/files/saphirion_nlpp.pdf

Nevertheless, the code could be replaced, if needed, but it looks 
to be working ok with CASE/ALL.

I've never had a problem with CASE itself, /all or not. If it is 
tough to test I've never seen it.

There are a few functions in R3 that take the form of a CASE/all 
followed by a CASE. SAVE is one such function, though it has a series 
of IF statements at its beginning leftover from before that could 
be made more efficient by adding to the beginning of the CASE/all.

CASE/all is no more difficult to test than the series of IF statements 
it replaces. Easier to analyze, because it's more structured.

CASE/all is no more difficult to test than the series of IF statements 
it replaces.
 - yes, sure that is true

As to why CASE/ALL is hard to test: for example, if you have 10 cases 
in a CASE statement, and use 10 different tests for testing such 
a code, then, to be as thorough when CASE/ALL using 10 cases you 
would need 1024 tests.

sorry for the formulation, but I hope the idea is clear

Is this a problem, or a change in execution model?

     b: reduce ['now]
    do first b
    (nothing on console)
    do do first b
    == 2-Mar-2011/13:10:13

R2 will respond with the date with only  one DO

A change in execution model

Anyone knows if error printing is currently hookable in R3? I.e. 
is there a function somewhere which is called by the interpreter 
when an error! escapes to the top-level?

Not currently.

Bug?

>> a: context [f: does [print b] b: none]
== make object! [
    f: make function! [[][print b]]
    b: none
]

>> c: context  [b: make map! [m 4]]
== make object! [
    b: make map! [
        m 4
    ]
]

>> a1: make a c
== make object! [
    f: make function! [[][print b]]
    b: make map! [
        m 4
    ]
]

>> a1/f
none

Appears to be a bug. I'm writing the ticket now.

See here for details: http://issue.cc/r3/1863

Does tab for path completion not work anymore ?

Or, did it never work?

never worked in R3