World: r3wp

http://www.rebol.net/cgi-bin/r3blog.r?view=0282#comments- so those 
are the problems Carl faced ...

in any case, i fear the console on win32 is mostly a lost cause :)

I haven't given up on it yet :)

I see there's no Linux release beyond alpha 107, so I can't do any 
testing

They are working on Linux and host kit issues now (for European sleep 
schedule values of now).

Don't worry, I'm more aligned with US sleep schedules :-)

The mix of mutating and non-mutating series functions sometimes really 
is maddening. Not to mention the uglyness of the resulting code.

MAP-EACH copies, REMOVE-EACH modifies, SORT modifies, UNIQUE copies, 
... yuck.

yes, I agree, but therefore it needs to be clear which function modifies 
and which one does not:

? modifies

Yes, that's fine.

Doesn't beautify the code or make it less maddening that does pieces 
do not fit together nicely.

those*

I also think we could use a document that states why some of the 
functions modify and some copy. I had a longer discussion about UNIQUE 
recently.

? "(Modifies)" will be a great start to write a always-copy overlay 
module.

For those who worry more about elegance and conciseness than about 
performance ...

That can be a doc string convention and it would work just as well. 
We have already put (modifies) in a lot of doc strings.

However, a better convention would be to put (modified) on the doc 
strings of the particular parameters that are modified. Some functions 
modify only one or two of their parameters, not the rest.

Consistent application of this convention is key here, or else HELP 
won't find them.

We should consider this to be a requirement for the multitasking 
project, since using the modifying functions can be tricky when multitasking.

Is there a reason MAP-EACH copies?  Wouldn't it be faster if it modified?

Certainly an option. But that are not the semantics one usually associates 
with "map". In that case, "change-each" would be a much better name.

MAP-EACH that modifies would be FOREACH. Generating a new block is 
the entire reason for MAP-EACH.

FORALL rather than FOREACH.

Right, but in some way already covered by an efficient function or 
code pattern.

(If anything.)

Anyone still happens to have R3 A30 binaries? If so, please send 
me a private message.

A109 for Linux has been uploaded.  There was an odd glitch in the 
build that delayed it.

Andreas, A30?

do you have an ETA for A109 host-kit?

I'm about to prepare a package which has a working version of openGL 
in view...

wondering if Its better to wait for A109

I uploaded it for the RMA guys to test out.

ok, so its already done... cool.

The A109 did not focus on host-kit, but on other things... so not 
sure it works. I can give you a copy to try if you want.

yeah, it would be nice, I'll try to update the Custom Gob Rendering 
API to it.

btw have fun at amiwest tomorrow... wish I where there  :-)

www.rebol.com/r3/downloads/r3-host-kit-a109.zip

thx !

so... give it a try, but no promises on this one, not tested

(and perhaps some of the files not quite right either... so, it's 
not official.)

Thanks on AmiWest... my truck is full of really old Amiga stuff to 
take over. Cleaned the basement.

no problem on testing, I'll be diffing it against my modified A107.

Well... hopefully it works. CU later, must go get some sleep.

I can't wait to share the 3d enabled version or R3.... btw, I just 
named my 3d model format...    .R3D    :-)

ciao!

I'm looking forward to it, as I'm sure many others are!

full-screen animation at 10% cpu  ;-)

Carl, a minor glitch in the A109 hostkit, which prevents it from 
compiling with AGG: in reb-lib.h the #ifdef __cplusplus definition 
of RXIEXT is borked.

Should be
#define RXIEXT extern "C" __declspec(dllexport)
instead of
#define extern "C" RXIEXT __declspec(dllexport)
(reb-lib.h, line 68).

Other than that, the hostkit works fine (and hostkit-built binarries 
pass the same number of tests as the RT binaries).