World: r3wp

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.

This line of code (complete with typo of extra colon on the ONLY) 
works in R2
    a: copy [] insert/only: a 8
But, in R3, it acts as a no-op

Neither behaviour seems reasonable -- why not a syntax error?

There is a ticket about that already.

Thanks -- must have missed that one.

See http://issue.cc/r3/1558and http://issue.cc/r3/1559

the rebol3-gui of RMA is on a good way. now we would like a R3 fixe 
to have the GUI on Linux & Mac !!!!!

Is there some good documentation about ports and schemes? Finding 
anything on rebol.com is almost impossible.

I don't know of anything current from RT, but maybe these will help:

http://www.rebol.net/docs/prot-http.html
http://www.rebol.net/docs/
http://www.compkarori.co.nz:8000/Rebol3/Schemes/Http

Thanks! I also found this useful doc

http://www.rebol.net/wiki/Schemes:Notes

There were imo better docs. I'll try to find my previous posts, I 
gathered some links ...

http://www.rebol.net/wiki/Ports
http://www.rebol.net/wiki/Port_Examples

http://www.rebol.net/r3blogs/0130.html- More about Port layers - 
the OSI Model

http://www.rebol.net/r3blogs/0129.html- Simple TCP example: HTTP 
web page transfer
http://www.rebol.net/r3blogs/0128.html- Skip and Seek on ports
http://www.rebol.net/wiki/TCP_Port_Details

Should we copy these to the REBOL 3 Schemes group?

I have not understood REBOL response of Sunanda question

     b: reduce ['now]
    do first b
    (nothing on console)
    do b
    ==6-Mar-2011/0:48:32+1:00
    do do first b
    == 6-Mar-2011/0:48:32+1:00


Why 2 "DO" are needed when you use FIRST ? Which is the difference 
?

The same for DO B/1. Which is the difference between the WORD "now" 
used by "DO B" and the WORD "now" you get from DO B/1 ?

In R3, DO of a word! value is basically equivalent to GET of the 
word. So in the example above, the first DO performs a GET of 'now, 
retrieving the value assigned to it, the NOW function. Then the second 
DO of the value of the NOW function performs that function.

If you DO a block, it interprets the block. In that case, the word 
is inline so it is evaluated as an inline word, as a GET then a DO.

So, getting rid of the distracting REDUCE, the first line is this:
    b: [now]

It is a block with a word! value in it. In the context that the word 
is bound to, the function value NOW is assigned to that word.

You can either have a dialect processor like DO interpret the block:
    do b

or you can treat the block like data and interpret the data yourself, 
emulating the dialect processor (all of these lines are equivalent):
    do do first b
    do do b/1
    do get b/1

Note that those lines are equivalent for that particular data. For 
other data, they may or not be equivalent.

Is there a reason this works in R3? (it fails in R2)
    >> context [a: :b b: :c c: a]
    == make object! [
        a: none
        b: none
        c: none

I'm guessing convenience.

Note that it works in USE that way as well. Specified words are initialized 
to none.

That makes some sense, thanks.

Also consistent with local words (and unused refinement words) in 
functions

The guideline in R3 seems to be that things are to be consistent 
unless there is a good reason to not be in specific cases. Fewer 
docs needed that way :)

Hmm, I do not see a consistency there anyway - system/contexts/user 
context words are not initialized to NONE

So, instead of achieving consistency in R3 we just obtained a different 
kind of inconsistency. (Actually, I do not mind much, I just do like 
to name the things properly)

There is a good reason not to be in the specific case of system/contexts/user: 
RESOLVE overriding. So this is an example of the "unless" part :)

That is not exactly what I had in mind. (especially when taking into 
account, that the usage of RESOLVE does not need to be considered 
"initialization") What I had in mind was, that:


1) there are two different values used to initialize variables: #[unset!] 
and #[none!]

2) because of that, the situation cannot be considered "consistent", 
unless one of the above values ceases to be used for initialization 
purposes, no matter whether we move some of the variables from the 
category of "initialized to #[unset!]' to the category of 'initialized 
to #[none!]'