World: r3wp

it's not a big deal indeed, it just means disabling the rest of the 
code - that's why it seems quite weird to me :)

It's not worth the hassle of not putting it in.

How about net-logging a prominent message when falling back ? That 
way, it should eventually turn up in someone's log, and we'll see 
it that way.

good idea... that way any techie does not miss it, if its at all 
important.  and any average user, gets improved mileage without the 
hassle.

Anton, it will be in the build ... do you really want to update all 
builds once someone reports a problem

ok, i guess i will add the fall back.

I'm just always trying to find "the correct thing to do".

I am accepting #4143. note, that although i think it is unlikely, 
this change could break old code that made assumptions about switch. 
so please do test this one when released (i assume 2.7.2), and if 
it breaks code, we can revert to the old switch, and maybe add a 
refinement or something like that.

anyone has the original contents of #3056?

can anyone check if #3666 still applies?

gabriele, is 3056 not listed in http://www.rebol.net/cgi-bin/projects/share.r?id=35&
?

http://www.rebol.net/cgi-bin/projects/share.r<--- interesting, I 
don't remember this page?

the urls for various code submissions contain spaces, so that breaks 
all the links

ah, that script is still working? :)

#3666 "CALL interferes with UDP ports"  - doesn't seem to apply on 
Windows Rebol/View, I've tested about 30 versions so far.

Just to be sure... when running the second server, I should expect 
a print out of "false-awake-event" to indicate the bug, shouldn't 
I ?

I didn't see this printout on any Rebol/View 1.2.1.3.1 -> 2.7.0.3.1

#3666 applies to Linux: 1.3.2.4.2 and OpenBSD

re #4143: as I mentioned elsewhere, I would prefer FIND/LITERAL or 
changed FIND/ONLY to get more expected result for datatypes

(and I guess, that #3666 may apply to OSX too)

(Ladislav, well, I'm sure of that now !  I should have paid attention 
to the version numbers.)

#4143: yes, but what i think could break code, is people expecting 
this to work:

>> switch 2 [2 1]
== 1

it won't with the new switch. it's unlikely anyone is doing that... 
but it's possible :)

looks like Holger used that feature:

switch port/locals/access/type [
            list [
                port/locals/list: copy* []
                port/state/tail: 0

                imap-check port reform [uppercase port/locals/access/list {""}

                    imap-form-string port/locals/access/name] none [ok]
            ]
            box select-block
            iuid [
                do select-block
                port/state/tail: 1
            ]
            search [
                port/locals/msg-uids: copy* []
                do select-block

                imap-check port reform ["UID SEARCH" port/locals/access/search] none 
                [ok]
                port/state/tail: length? port/locals/msg-uids
            ]
        ]

(imap protocol)

notice    box select-block

anyone else doing this?

I made an observation while using FTP a couple of months ago that 
login names couldn't contain the \ character. I've found that certain 
web providers use \ by standard in their user names to separate the 
user's name with server name. This is non standard, but not likely 
that the webhost will change this policy.

This can be changed with:


net-utils/url-parser/user-char: union net-utils/url-parser/user-char 
make bitset! #"\"


If I hadn't known this, I would not have been able to use this webhost 
(one of my customers have all his sites there). It gave me a lot 
of head scratching, but Pekr found this solution for me. I imagine 
that other REBOL users will face the same problem.

Should it be included even though it's non-standard?

RAMBO'ed

An ever-present question. I guess being non-standard, the character 
can cause trouble in another situation. Then who is to blame ?

use a block instead of a url

Anton, the problem is actually that rebol does not handle percent 
encoding correctly in URLs. (i hope we can fix this in r3)

#4143  not sure I like the proposed change, .  I'd prefer if this 
new version was a refinement  /ONLY .  I don't see what is the issue 
with switch as it stands !?!?

I've been using switch for years and have used other second values 
than blocks many times... its very usefull.  sometimes I put functions 
there.

max, there was a discussion here about switch and the new one was 
agreed to be a better solution. Ladislav can explain better what 
his concerns with the current switch are (mainly dealing with none 
i think). the feature with multiple values going to one block is 
very useful (i needed it many times and implemented my own switch 
because of that), so it seemed a good idea to integrate it in switch 
directly; but it could be a refirement if that would create too many 
problems.

Ladislav, care to clue me on why the proposed change of "evaluates 
following value" to "evaluates following block" ?

if you already have only blocks, I don't see the advantage, it seems 
like adding a limitation !?

ok, I just looked more deeply into the #4143 ticket.... its a nice 
alternative to switch cause it allows multiple cases for each action... 
 

it functions differently, why not call it 'CHOOSE   ?

We already have CHOOSE.

Gabriele, I have noted that in a file. You will never have to remind 
me of that again, hopefully.

about 'CHOOSE  eek I hate that VID populates the global space  like 
that...

max, i would be ok with switch/multiple. but is it worth to "bloat" 
switch? anyway if the change breaks actual code maybe we'll need 
to. do you think we should still let it in 2.7.2 and then you can 
test it and see how it goes in practice? if it only breaks one script 
in the world, it's quite easy to fix just that :)

I agree that the new switch is better in practice.  I will try it 
against my current code base and report back  I use switch profusely... 
so if its not an issue for me I think that it should be a good reference 
in general.

any tests wrt speed?  is it much slower than previous version?


I also think we should add /all  like the 'CASE.... since we are 
revisiting and operating on such a fundamental mezz, it could be 
a good time to make it as consistent with other similar mezz...  
 and the /all could be usefull. especially for handling non-exclusive 
refinements.

not sure i understand how /all should work.

speed: it's probably a bit slower (two calls to find instead of one 
to select) but i haven't done benchmarks.

do all the switches which match instead of only the first one ex:

switch [ 1 2 3 [do this]  3 4 5 [do that]]

3 would execute both blocks.

ah, i see, with multiple values it makes sense.

yep it almost looks  like the third friend in the ANY/ALL  combination