World: r3wp

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 ...

Right. R3 is built like an OS. And designed by the same guy who designed 
*that* OS. It might follow a similar model.

this will probably be most useful on embedded or specialized hardware 
for now

The device will have associated functions, but those functions might 
be defined in a plugin. Or not.

R3 devices wrap OS API (or third-parties API), no direct hardware 
access, that's way too costly to achieve.

Too costly on host OSes, you mean. Some host OSes provide APIs that 
structure hardware access, like the Direct* APIs. Devices could use 
those. Or if R3 is just running on a bootloader (as proposed in Wildman), 
the device functions would access hardware directly.

Brian - ticket #588 does not crash here. It just takes lots of time 
and resources to display 20x9999999 size button :-)

it is related to other bug, which is marked as Tested already. We 
should close this one probably too ...

OK, I'll mark it as tested for the same alpha.

Done.

About #564 and blog#207: I'm a little lost, is option 3 already implemented 
in alpha55?

No, most of 2 is already implemented.

Ok, after testing and reading again your comment in #564, my example 
in blog's article is wrong, it should have been :
>> if any [get/any 'tst 123] [print "ok"]
ok

My example raises an error (as it should do) : 
>> if any [tst 123] [print "ok"]
** Script error: tst has no value
** Where: any
** Near: any [tst 123] [print "ok"]

Yeah, that makes sense. Btw, option 2 has been mostly implemented 
since alpha 38, which came out in January.

So the silently ignored typo issue still exists, but would be much 
less frequent than I feared.

Part of the trick here is that you have to balance the benefits of 
error generation versus the overhead of error handling. We've been 
careful to make a lot of code that used to generate errors in R2 
just work in R3. If there is a good rationale for "just working" 
that is.

Is such move really going toward the PITL where R3 is supposed to 
bring us? It sounds more like going in the PITS way, making throw-away 
code even eaiser to write. Maybe I'm just not understanding well 
what your were saying.

I agree on the benefits of treating unset! as noops in such cases 
: 
ANY [( )] == none
ANY [( ) 1] == 1
It's usefull and is consistent with the way COMPOSE treats ( ).


But I still think that's some way of getting unset! values may lead 
to undetected errors like in :
>> test: func [a] [print a exit]
>> if any [test 123] [print "ok"]
123
== none
>> result: test 1
1
** Script error: result: needs a value


I understand why you were asking for such change, but it's hard to 
know if it won't cause more trouble than gain.

What I'm saying is that sometimes this kind of thing is not an error. 
The question is whether it is an error more often than not, and if 
the error is critical enough to justify the error handling code that 
comes from generating the error.


Take the ordinals, for example. We decided to redefine out-of-bounds 
for the ordinals as not-an-error. It now means return-none, where 
none is the possibly OK non-data that can be handled with low overhead.