World: r3wp

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

I don't understand how you expect it to be done differently.

Carl can only fix bugs so fast.

I tried in r3-alpha to make a list of things, to be tested, with 
a hierarchy from a description from Carl. (The r3-status.r script) 
But it didn't happen the way, I had in mind.

I think, it would have less bugs, if lower levels were tested better 
before moving on. Doing it that way, you'll end up using less time 
on the whole things, before it's finished.

It would also be another situation, if it were open source. But even 
with closed source, I can think of better ways to run it, that how 
it's actually done.

I don't think it would have less bugs. More bugs would have been 
exposed, but the rate of fixes would be roughly the same. We already 
have a rigorous testing system in place, only it has not been used 
much yet. I think it's because Carl is too busy designing the remaining 
subsystems.


What's important at higher level development, is not to use workarounds 
for bugs, but await proper fixes.

that = than