World: r3wp

Yes, what is the reasoning behind using  MAKE BLOCK! []  instead 
of  COPY []  ?  It appears to me that COPY evaluates faster.

No reason really, it was the first method that came to mind.

COPY looks about 12% faster (for allocating empty blocks).

; I guess this is moot, but a slight variation of my prior 'switch:
switch: func [[throw] value cases /default case][
    default: copy [] 
    while [
        all [
            cases: find/tail cases value 
            cases: find cases block!
        ]
    ][case: append default first cases]
    do case
]

I know this rollback alot of lines, but I always marvel at  how Carl 
can reduce the size of code as he does.  He's been meditating about 
REBOL (throgh all of ancestors) for soooo long, it seems he can speak 
in rebol, "natively"  ;-)

unless is a nice addition to standard rebol, I know use it alll the 
time.

Paul, the interim releases are meant as "please test this" by all 
accounts.  IIRC view 1.3 had a few rollback based on user feedback 
of new features wreaking havoc on too many stuff.

So do we want to approach switch then as being /all by default?  
To me it seems to make much more sense and I liked Chris's implentation 
of that switch.

switch is now native, which allows avoiding the allocation/copying 
(because the native does not have the BREAK problem)

Which version is it most similar to ?

I believe Gabriele's.

in rambo it sais part of 2.7 release... I guess its Carl's reduced 
version?

anton, do you remember this one:


view layout [text "Push and drag out. The highlight should go away 
when the mouse exits, but it doesn't." tog "Test"]


I remember you talking about that you made a fix for that, which 
didn't work. Do you think we could make a proper fix for View 2.7.x?

max, since it is native, probably none of them. it has the same interface 
of the proposals, which is what counts.

Yeah and now that it is native it is faster than select for single 
selections.

Henrik, here's a quick 5-minute patch (not well tested).

body: second get in svv/vid-styles/tog/feel 'engage 
insert body bind bind [
	if action = 'away [over face false event]
	if action = 'over [over face true event]
] svv/vid-styles/tog/feel body/4
view center-face layout [tog "hello"]

Essentially, the ENGAGE 'away and 'over events are called when dragging 
off, and back onto, the face, and I redirect the events to the existing 
OVER function, which normally doesn't get events with the mouse pressed.

I don't really like that hover state anyway. In my style-gallery.r 
I'm aiming to use a similar highlight to indicate the focused state 
of the btn or tog.

Max, about UNC paths: the only problem with REBOL's way of (not) 
supporting them is when your hostname is only one letter long. do 
you see any other problems?

How does Carl decide what goes native and what does?

Why switch, and not case ?

append got native too :-) well, imo if you use something often, in 
mezzanine level, then it could be brought to native level? Imo it 
could be even profilet, to know if the speed gain is there or not, 
no?

I don't think it's very wise to implement 'switch native in 2.7 when 
it can broke old code. Save it for 3.0, why not, but why breaking 
the compatibility, when it's not necesary?

perhaps it's a sneaky way of testing R3 code? :-)

you can always redefine it back again.

I am with Rebolek here - 2.x family should stay as separate branch, 
usable in what it offers, no new experiments.

but maybe compatibility issue here is not a problem?

Pekr: older switch evaluates values , newer does not 
>>b: [print "!"] switch 1 [1 b]
prints "!" in older versions, returns none! in 2.7.2

that is rather big change in behavior, no? But it was probably discussed 
here enough, so that 2.7.2 is kind of consensus of developers opinion?

yes it was discussed,

anton, should we rambo it as it is?

anton, (about your patch)

anton, I tried TOGs, BTNs and overlapping TOGs and they all work 
without this problem now. looks OK to me.

Rebolek you make a good point about the switch.  Maybe we should 
modify it so that it can find block! or type? block!  - of course 
it is native right now so I have no idea what that means for the 
code.

Which I don't know if that is very desirable either as some may want 
just the block returned and not evaluate as it would now if in your 
example the b were in build in the case such as [1 [b]]         But 
in any event you can get the effect you want with the current switch 
by doing this:  do switch 1 [1 [b]]

Henrik, no, I'll clean it up first. I just thought you might have 
needed it for something. It's in my editor so I ought not to forget 
about it. :)

anton, ok. it would just be very nice to get this fixed properly. 
I've had complaints over this a few times now.

Ok, so it's not just a frivolous claim :) Don't worry, I won't forget.

WTF new switch doesn' evaluate?  that was the point of the previous 
switch.  none of my last 5 years of code will now work.

Example ?

what's the point of changing switch in 2.7?

To make it better ?

at what cost?

This works for me:
>> switch 1 [1 [print "hello"]]
hello

give me a minute... I'll do a real test.

ok I just looked at the above example and yes it makes sense now... 
 I thought it didn't evaluate the content of the block.

so since it does evaluate, yes my code seems to work pretty well 
under 2.7 GLayout presents no artifacts, and liquid will run a little 
faster with newer switch.

Graham, CASE has always been a native. SWITCH needs to be native 
for the BREAK problem I mentioned (otherwise /ALL makes the function 
rather inefficient)

Rebolek: if it really breaks important code, we will revert it back. 
The request for changes to SWITCH was in RAMBO.