World: r3wp

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

ok.

How bad would it be to have a strict  version of rebol vs a relaxed 
version.  I'm thinking of things like skip which require an integer 
and choke on none ...

It would be bad to have a non-strict version, as someone might use 
it.

That's only bad if their scripts were published or used by others.

Can I create object from block of words and values?

*blocks of... like -  words: [a b] values [1 2]

This is one (fairly manual) way:
    words: [a b]
    values: [1 2]
    obj: make object! []
    for n 1 length? words 1 [
        append obj words/:n set in obj words/:n values/:n
        ]

set bind/new/copy words obj values

yes..I though that there may be some fast native function for it 
;)

ah, thanks!

The /copy is only necessary if you will be reusing the words block.