World: r3wp

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

Is this a bug or an expected/justifiable result:
  1x.00000000000000000000000000000000000001
 == 1x9.999999e-39

I thint it may be a specific case of this -- unexpected by me, anyway:
    (second 1x.1) = 0.1
    == false

Ah yes, floating point not being able to represent 0.1 exactly. But 
with the default digits that should work.

The (second 1x.1) <> 0.1 result is caused by:


1) the fact, that binary floating point cannot exactly represent 
1 / 10

2) the fact, that 64-bit IEEE754 (REBOL decimal!) is more accurate 
than 32-bit IEEE754 (REBOL pair coordinate)

Thus, the result is both justifiable, as well as expected.

Thanks, Ladislav.

There are several anomalies, which at least could be noted in the 
documentation under the pair! data type.


Another [anomaly]/[undocumented change from R2 behaviour] is when 
a pair overflows:

....R2 throws an error, or replacee the large number with 0 (itself 
an odd behaviour).

....R3 can generate +/-infinity. As far as I know this is the only 
way in R3 to get a -/-INF; and the value is not usably serialisable:
    xx: as-pair -1e44 1e44
    == -1.#INFx1.#INF
    type? first xx
    == decimal!
    load mold first xx
    ** Syntax error: invalid "integer" -- "-1.#INF"

Thanks, Ladislav.
There are several anomalies, which at least could 
be noted in the documentation under the pair! data type.

Another 
[anomaly]/[undocumented change from R2 behaviour] is when a pair 
overflows:


....or replacee the large number with 0" - which expression do you 
mean?

The infinity may be a problem, but, it looks like a low priority 
issue to me.

I mean sometimes one, sometimes the other:
R2:
>> as-pair 1 1e308
== 1x0
as-pair 1 1e309
** Math Error: Math or number overflow

Thanks, did not notice that

aha, but this behaviour does not have anything in common with pairs, 
in fact

The 1e309 value causes the overflow when loaded

Otherwise, the R2 pairs never overflow, instead they "wrap around"