World: r3wp

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.

why did changing the executable rebol.exe to v2.7 force me to go 
throught setup of user again?

especially since it didn't even change the content of the user.r 
file... but now it accepts it?

Henrik, I published the TOG bug to RAMBO. (It didn't really need 
much cleaning. I just checked that the TOG feel was used only by 
TOG.)

wonderful! thanks :-)

Gabriele: OK, that's reasonable

I have a slightly modified help, that does not evaluate functions 
in objects and ports and that also dumps ports like objects.
>> a: open http://www.rebol.com
connecting to: www.rebol.com
>> help a
A is a port of value:
   scheme          word!     HTTP
   host            string!   "www.rebol.com"
   port-id         integer!  80
   user            none!     none
   pass            none!     none
   target          none!     none
   path            none!     none
   proxy           object!   [host port-id user pass type bypass]
   access          none!     none
   allow           none!     none
   buffer-size     none!     none
   limit           none!     none

   handler         object!   [port-flags open-check close-check write-check 
   ini...
   status          word!     file
   size            integer!  0
   date            date!     6-Nov-2006/21:26:44
   url             string!   "http://www.rebol.com/"

   sub-port        port!     make port! [ scheme: 'tcp host: "www.rebol.com" 
   po...
   locals          object!   [list headers querying]

   state           object!   [flags misc tail num with custom index 
   func fpos i...
   timeout         integer!  30
   local-ip        none!     none
   local-service   none!     none
   remote-service  none!     none
   last-remote-service none! none
   direction       none!     none
   key             none!     none
   strength        none!     none
   algorithm       none!     none
   block-chaining  none!     none
   init-vector     none!     none
   padding         none!     none
   async-modes     none!     none
   remote-ip       none!     none
   local-port      none!     none
   remote-port     none!     none
   backlog         none!     none
   device          none!     none
   speed           none!     none
   data-bits       none!     none
   parity          none!     none
   stop-bits       none!     none
   rts-cts         logic!    true
   user-data       none!     none
   awake           none!     none

Is there interest in including in the new release?

help/secure a/handler/set-modes
    there is a function inside an object or port
USAGE:
    A/HANDLER/SET-MODES port modes

DESCRIPTION:
    (undocumented)
     A/HANDLER/SET-MODES is a function value.

ARGUMENTS:
     port -- An open port spec (Type: any)
     modes -- A mode block (Type: any)

yes... please send this to Carl

very cool!

I put it into Rambo and into the library at rebol.org, as Carl promised 
it already once to include it in one of the former realeses.

I fixed some problems with blocks

scaling info.gif (which has an alpha channel) gives funky red and 
yellow stripes when specifying 2 or 4 points (but not 1 point).

This bug seems to have been introduced in View 1.3.2 and is still 
present in View 2.7.4
	  

 window: layout [b: box sky effect [draw [image info.gif 0x0 49x48]] 
 mag: box 600x600] 
	mag/image: to-image b 
	view window

It doesn't appear to be in the bug database.

I've been investigating the bug above with this script:

do read http://anton.wildit.net.au/rebol/view/draw/agg/image-fit.r

anton, testing both on XP and OSX. the bug does not appear on OSX, 
though colors are odd there due to a known bug.

another known bug, that is

it could be that the odd colors are simply hiding your bug, though. 
:-)

:)

http://rebol.hmkdesign.dk/imagebug.png

It looks like it also has the alpha channel problem.

Try the above image-fit.r program, set it to 2-points and then play 
with the SIZE pair-edit.

that's a very tall window. it doesn't fit on my screen :-)

On XP you see red and yellow stripes in the alpha channel.

Ok, I was thinking of changing that anyway. Hang five.

Ok, reorganised. Try image-fit.r again.

it's difficult to tell. the colors are shifting very quickly, where 
there should only be subtle changes. there are colors that look like 
they shouldn't be there, but I can't be sure.

Do you mean it's harder to see on OSX because of the other colour 
problem ?

yes

colors are bouncing all over the place when I resize it

Ok.

I'll post this later if no one else has any comments.

(The script I was working on which led to this bug was this one:

do read http://anton.wildit.net.au/rebol/gui/demo-future-progress.r

BTW I have fixed the OSX color bug so it could be added in next release.

Anton: the new image color problem you have found is 'by design' 
at the moment ;) The bilinear filter needs image data with premultiplied 
alpha when you want to use image with alpha/transparency. Another 
possibility is to use IMAGE-FILTER NEAREST which doesn't need premultiplied 
alpha in this case. I'll try to think how to solve this 'inconsistency' 
so it doesn't harm performance too much.

Hmm.. that's a bit annoying. Is there really no way the bilinear 
filter can work also on the alpha channel ? That would be a feature 
request to submit to AGG then wouldn't it ?

Good work on the OSX color bug. So now we'll both be able to see 
my bug. :)

Cyphre, so I'll submit a ticket to RAMBO.

Anton, according to the author of AGG the filter calculations would 
be much more complex and thus expensive if done in plain color space. 
Anyway, please submit a ticket to RAMBO I'll try to make the best 
to solve this issue.