World: r3wp

The R2-Forward APPLY is not as fast as the native, but I've found 
it fast enough for wrapper functions in R2.

Plus it disables the special treatment of 'a and :a declared parameters.

is that gone in R3?  (set word arguments)

Nope, they just work better.

Don't forget to keep it simple! As simple as possible, but not simpler.

Is there a way in R3 to "capture" error messages when using ATTEMPT, 
or some other command.
i.e.
>> WRITE %missing/File.txt to-binary "test string"
** Access error: Cannot open: %missing/File.txt reason: -3
** Where: WRITE
** Near: WRITE %missing/File.txt to-binary "test string"

>> ATTEMPT [WRITE %missing/File.txt to-binary "test string"]
== none

Is there any way to get the error message from the ATTEMPT?

Found it!

>> probe disarm try [WRITE %missing/File.txt to-binary "test string"
make object! [
    code: 500
    type: 'Access
    id: 'cannot-open
    arg1: %missing/File.txt
    arg2: -3
    arg3: none
    near: [WRITE %missing/File.txt to-binary "test string"]
    where: [WRITE try]
]
== make object! [
    code: 500
    type: 'Access
    id: 'cannot-open
    arg1: %missing/File.txt
    arg2: -3
    arg3: none
    near: [WRITE %missing/File.txt to-binary "test string"]
    where: [WRITE try]
]

in R3 is there a way to intercept the write event before the send 
occurs - and if not, is there a way to force a send before another 
write takes place in an Async queue?  I'm getting an issue where 
multiple write events are being cached and sent all at once (about 
10 write events per second).

What I think most people do is this:

if error? set/any 'err try [            ][
	probe mold disarm err
]

Is there any advantage to using set/any over a set-word ?

I'm not sure what you mean. They're unrelated.

if error? err: try [  ][
   print mold disarm err
]

I've always used the second way, but almost everywhere else, I see 
others use set/any

Ah, I see now *a* set-word!. :-\  Consider an unset! result:

>> if error? err: try [()] [print mold disarm err]
** Script Error: err needs a value
** Near: if error? err: try [()]
>> if error? set/any 'err try [()] [print mold disarm err]
== none

Ohhkay, guess I've just never run across it.  Thanks

Is there any way in R3 to optimize code such as 


 out: insert insert insert insert insert [] 'fill-pen color [text 
 vectorial] 0x0 "hello"


?  I think the appearance of n INSERTs is kind of ludicrous. People 
are doing this for performance reasons, so the usual way we would 
optimize the code (which produces an intermediate block), isn't an 
answer.

I've forgotten if R3 has any way. (A quick look at APPLY and MAP 
doesn't seem to bear any fruit.)

it's not more fast than using a reduce or a compose.

but it saves memory overheads, exspecially in big loops

---> thus, does become a speed issue.

It would be nice to be able to say:

	loop 5 [insert] [ ] v1 v2 v3 v4 v5

so no intermediate block is generated.

Or have a method of reducing only the items in a block as they are 
being applied, without generating a new temporary block to hold them.

(This idea has been discussed before, somewhere...)

About the loop 5 example; I remember Carl saying that would break 
the rebol evaluation rules, or something like that.
But could we get that functionality some other way?

i think a reduce that can not creates a new block is not interesting, 
because the same block can not be anymore reduced next.

so, you can't use it in a loop

but an insert fonction which can reduce all the values from a a block 
before adding them, is quite interesting.

something like,

insert/reduce ['fill-pen color 'text 'vectorial offset message]]

it means get the value of the worlds before adding them

could be, insert/get or insert/load as well

so that no new blocks are created

Steeve...

REPEND

=D

compose ? hihihihi

yes ok for the name REPEND, but we need a native func with no reduce 
inside

Yes, it would be great if REPEND worked that way.

Anton, is there a reason COMPOSE won't do what you need here?  If 
the objective is to avoid creating a temporary block, compose does 
it.

Look here: http://curecode.org/rebol3/ticket.rsp?id=506

Right on topic with what you are saying, and my biggest personal 
reqest for R3.

Ammon, both COMPOSE and REDUCE generate a new block.

BrianH, that's good that that ticket exists. Thanks for pointing 
it out. Hopefully that will be implemented someday soon.

That's why it's "urgent" priority.

I'm seriously beginning to loose faith in R3. As I see it, there 
are still a lot of bugs on the lowest levels, and most development 
is going on far above that level. It's like a tall building, where 
new windows are put in on the 123 floor, while there are still many 
cracks in the basement. I guess, it'll take years at best, before 
we see a stable R3 on major platforms at the same time.

Most of the bugs in lower levels of R3 are found through higher level 
development, so that will likely continue. Also, getting things right 
is more important this time around. Please don't use it in production 
environments yet.

The lowers levels should then have been tested better, before going 
into higher levels. When you fix a bug on a low level now, it could 
have significal influence on higher levels, so more tests and probably 
new bugs. Problem is the low levels are hidden from us.


Memory problem on OS X concern me a lot. Also today I wanted to do 
some test on issue! datatype, and get strange results. Like doing:

i: #
insert i "abc"


If low level series handling like this has bugs, then I'm very concerned.

Henrik, when I made Canvas RPaint, you helped a lot with testing. 
And I didn't move ahead, before everything worked completely. That's 
the way to do large projects.

I'm not sure I understand this concern. Clearly there is a bug, and 
Carl usually fixes those, but only if they are reported to Curecode.

It looks like the issue type's new unicode (16bit?) internal representation 
isn't being formed or molded correctly yet.

Yes, we can find bugs, report to Curecode. Before Curecode we did 
it in r3-alpha. It has been going on for years. And it will continue 
to years. The problem is the way, the whole project is run.

continue *for* years