World: r3wp

Hmmm, what if you had a body block for each item in the dialect, 
so the main body is the innermost loop. Interesting to think about 
anyway.

Gregg, the issue becomes, do you want all of them to advance at the 
same time, or nested, and if nested, in which order?

I'd say that nested cases are already well handled by what we have 
so they can be ignored.

So... I guess your idea is not bad at all.

I wonder if there is a way for 'if to not return a value?

I'm looking for a pass thru mode if 'if is false

eg. if I want to avoid the #[none]

>> print rejoin [ "hello " if false [ "world" ]]
hello none

>> print rejoin [ "hello " either true [ "world" ]["" ]]
hello world

>> print rejoin [ "hello " if/only false [ "world" ]]
hello

so something like that ...

This is the construct I saw which I don't like

either true [ tail s ][s ]

which I could  then replace with

 if/only true [ tail ] s

It's less verbose and possibly clearer than using the 'either construct

if/else false [][#[unset!]]

>> only: func [c b][if/else c b [#[unset!]]]
>> only true ["howdy"]
== "howdy"
>> only false ["howdy"]

is this what you need?

Nope .. 

>> print rejoin [ "Hello " only false [ "world" ]]
Hello ?unset?

functions which don't return anything actually return unset!

rejoin is the culprit here.  the only reason your tail s works is 
because you are appending an empty block to a string, which = to 
appending an empty string to a string.

ex:  >> rejoin ["" prin ""]
== "?unset?"

IIRC R3's rejoin now ignores the unset values

I just want if/only to drop a value off the stack if false

only: func [c b][if/else not c b [#[unset!]]]


you can reverse the truth, but you will always return unset!   there 
is no such thing as a function which doesn't return a value in REBOL.

I want to avoid these 'none values ... where you are forced to use 
'either

well, you have to chose between unset! or none!, but R2's rejoin 
collects the unset values and appends them to strings (which is a 
bit dumb).

you can also use compose, which ignores unset! values.

>> reduce compose ["" (prin "")]
== [""]

that's for rejoin ... which is just one example

yes, but other funcs will react differently to unset!... some will 
raise the "expects a value" error, for example, if you return unset! 
from 'IF and try to use it.

well, the value is just one more upstream :)

>> print only true ["rr"]
rr
>> print only false [""]
** Script Error: print is missing its value argument
** Near: print only false [""]

ah, ok, you aren't trying to prevent a return value, but providing 
your own default.

I suspect it's not possible ...

well, yes.  your only, just needs to require an argument value.

only = /only

in which case I might as well use 'either

or use Maxim's 'only, just with a different value:
only: func [c b][if/else c b [copy {}]]

http://stackoverflow.com/questions/3400315/trigger-close-event-for-rebol-console/3402413#3402413


I think he's after the ctrl_close_event http://msdn.microsoft.com/en-us/library/ms683242(VS.85).aspx


though how he can detect it without any scripts running is beyond 
me.
So, is this detectable in the system port?

He obviously underspecified what he is after in the question.

Someone should point Carl to this, I'm pretty sure he wants to know: 
http://www.rebol.net/cgi-bin/rambo.r?id=4398&

Notified him privately.

Gabriele:


Carl: "BTW, that REBOL example code is "C code" not REBOL. The crash 
occurs in GC due to a stack overflow. Works fine in R3. Ticket updated."

I don't understand how it is "C code". Anyone have any idea?
(And will R2 be fixed?)

I believe Carl is saying that in his opinion the code has been written 
in the style of C rather than making use of REBOL's language features.

Agreed that the code is "Javaish"... still, hard crashes are always 
worth fixing, you'll never know when they're going to bite you! (Maybe 
Carl should do a blog post explaining why that approach is bad and 
what is the alternative, most people get thaught that stuff in school 
and don't know better.)

Oh ok, I see. In that case, I'd like to see suggestions for how to 
do it more rebolishly. It doesn't immediately occur to me, not knowing 
the context for the code, how it should be better.

Another explanation could be that Carl is suggesting that such code 
(manipulating millions of vectors) makes more sense implemented in 
C (for higher performance), with rebol calling out to it.

Yes, that is a valid interpretation as well (things like that are 
not a good thing to do in REBOL). I do think that you can't give 
a more "rebolish" implementation without the context (that's the 
whole point of REBOL).

Is this helpful?

>> trim none

** Script Error: trim expected series argument of type: series port
** Near: trim none

What harm would there be in ignoring none?

I guess it's about the propagation of NONE. If TRIM is used as part 
of a larger concatenated string, you could be forced to handle the 
NONE case after TRIM.

I'm having difficulty using the find function to find an image in 
an image. The image specification seems to indicate that this should 
be fine. Is this a known issue?

Can you give an example where it doesn't work?

;Rule30
rule30: to-image layout/tight [box 6x1 yellow edge none]
foreach n [2 5 6] [poke rule30 n orange]

;Img
screen: system/view/screen-face

img: draw make image! screen/size  reduce ['pen 'yellow 'fill-pen 
'yellow 'box 0x0 screen/size]


img: at img img/size/x / 2
change img orange
img: at img -2x0
width: 3


it: copy/part rule30 3
find img it