World: r3wp

Curious objection from Carl (The users may be unable to understand 
how to use it) 
Uh ?????

i want some proofs that we actually use "chaining" insertions ?
I can send him some dozen of old scripts if he wants... :-)

*he wants

He's aware of the value of chaining, but is wary of the "bug" reports 
he already gets about INSERT. Apparently there is some tiny amount 
of overhead too, which for a function as low-level as REDUCE might 
matter. "Penny wise, pound foolish" - I'm trying to convince him 
otherwise.

We can save much more overhead by replacing chained inserts in the 
mezzanines. COMPOSE/into will have massive impact :)

Actually, the first optimization i do in my scripts which need speed 
and low memory usage, is to remove all the reduce and compose usage.
It's always the first thing i do

Now, you will be replacing REDUCE and COMPOSE with REDUCE/into and 
COMPOSE/into and preallocated or reused buffers :)

but this optimization isn't always possible.  when nests are deep 
and composes are chained within each other, you can't just chain 
insert and remain sane  ;-)

with liquid-paint, this would have MASSIVE impact.

although liquid-paint is already much faster than AGG and lazy so 
the gains might not be as noticeable, but still I can't wait to have 
time to try and port my stuff to R3, it does seem to be much more 
series stable, by all accounts.

Nested REDUCE and COMPOSE is not that common outside of code generation 
and nested data structure creation. I do that a lot, but I write 
my own mezzanines and some of them compile internally. I can think 
of many mezzanines that could be sped up with /into.

See this line of code i do to rebuild a draw block in area-tc (it's 
called thousand times when the style is scrolled)


    out-style: insert insert insert insert insert insert insert insert 
    out-style
					'pen color/2 'fill-pen color/2 'box

     as-pair abs-x 7 as-pair (f/x * length? str) + abs-x 7 + f/y 3

Insane ;-)

it's slower than a reduce, but it's save memory, a lot.

Seriously, post that code to the blog comments right away, with the 
COMPOSE/into equivalent. We need examples.

Actually, I''d use REDUCE/into for that one - too few lit-words.

yep

Actually, i'd do a test and choose the faster ;-)

out-style: reduce/into ['pen color/2 'fill-pen color/2 'box as-pair 
abs-x 7 as-pair (f/x * length? str) + abs-x 7 + f/y 3] out-style

*est

The REDUCE/into should be about as fast as REDUCE, but with less 
overhead.

i talked about REDUCE vs COMPOSE

but you insert example is just a chain... it gets insane when you 
also have offsets, cause you want to insert into sub-blocks  ;-)

Yeah, REDUCE/into and COMPOSE/into were designed to replace chained 
inserts or appends. They're pretty common in optimal code.

yes steeve, please do post your chained insert example  vs brian's 
reduce/into example

ok ok, don't push me, i go
;-)

done

Cool :)
Though now I wish I had word-wrapped my version :(

yep, i saw that but too late

Steeve I've just read the changes to A55 released today. It seems 
write/port errors patched. So Block sheme can be upgraded for quicker 
file updates?

51 fixes/enhancements, unbelievable this happens in the REBOL land 
:-)

perhaps it's a bit too many fixes for one release. one part of chat 
is mysteriously broken right now.

Henrik - I just use: chat .... n .... lm :-)

oh, 'lm has been updated. Nice.

ah, load-plugin .... what a bad name once again. Why load or import 
does not handle it internally? ('import is used in the blog article)

That sounds like an internal function that hasn't been put in a module 
yet. There is a similar function MAKE-MODULE.

You don't call make-module - MAKE calls it.

Good thing is, that Carl asked us to not use plugins yet, which might 
mean, that the code is already in there :-)

But I can't say for certain, as that part of the plugin interface 
isn't documented yet.

I just re-read docs about plugins and devices, and I still wonder 
what is the main difference? Are devices just for I/O? Because devices 
do use commands too. But - devices just don't define new functions, 
whereas plugins might do.

Brian - what needs to be implemented for utypes? Do you think we 
will get them for 3.0?

A:

1) They are different concepts, but devices may be implemented in 
plugins.

2) Devices wrap host or hardware things. These things include stuff 
needed for I/O, graphics, etc.
3) Well, plugins for start :)
4) Yes, absolutely.

thanks. I just have a little problem understanding 1), but never 
mind. So plugins are superset, the ability to extend environment. 
And as they can contain REBOL code, C code, they can contain even 
Device in itself? Well, it will be better to wait for API docs probably, 
to see some real-life examples ....

Basically, the difference between plugins and devices is that pluugins 
are code that wraps code, while devices are objects that wrap hardware.

As for 4) - I know you guys find them important (utypes). But what 
will we gain having the ability to do our own datatypes? btw - having 
own datatype will have to fulfill some needs, as for e.g. utype will 
have to be able to react to some functions?

Plugins are pretty much modules, but with the possibility of native 
code.

do devices wrap hardware directly like a real device driver or does 
it wrap the underlying OS driver?

We need utypes for host interoperability, to replace rebcode, and 
more. A utype will need to be able to react to the actions, just 
like a type

Re 1): Pekr, it's the same difference than driver vs library for 
an OS.

Henrik, yes, in theory either. R3 is built like an OS.

But - I can imagine having library containing functions to handle 
mouse, but Amiga had device for each, which allowed it to function 
in a more async way ...