World: r3wp

..which I believe Ladislav supplied.

I suspect some rounding is being automatically applied with the money! 
datatype

>> round .3 - .2 - .1
== 0

R3:

>> $.3 - $.2 - $.1
== $0

Dockimbel - sorry, please accept my apology. It was not you, it was 
actually Geomol on 8-Apr, who too refused to submit bugs, as those 
might not be corrected anyway :-) You just contacted me privately 
the same day, expressing your opinion to me.

My only problem is that you have to use the money datatype to use 
this number format. It could be useful in other places. But I think 
we've had this discussion before.

If you do a ? datatype!, in R3 you get:


money!          datatype! high precision decimals with denomination 
(opt)

So you may wonder as a beginner why the description is like that.

yes, we have had that discussion before. I better don't jump into 
that discussion once again :-), because I never used money!, and 
I don't know why such general functionality as math precision should 
be expressed by the datatype called money! I would prefer BCD! precise!, 
or something else. Also very weird to use $ in front of it ...

PeterWood: thanks for the documentation reminder, I should have read 
it to refresh my mind about that before posting. I wonder if the 
R3 money! implementation could be easily backported to R2? It shouldn't 
be dependent on new R3 features.

Pekr: Apologies accepted, I guess I shouldn't post to you privately 
when you're already upset ;-).

I guess Ladilsav can answer your question about the ease of back-porting 
to R2 but I would guess that it's c code which means it is likely 
to be a long time before it would get back-ported.

Well for one thing, the space for the underlying data is less in 
R2 than in R3.

If R3 still uses 128bits slots for values, it shouldn't change memory 
usage from a user POV?

R3 uses larger slots for values, a side effect of the 64bit integers 
and such.

Does that mean that the average memory usage will increase in R3?

Between that and the Unicode strings, basic data does take more RAM. 
We're making up for it by making all of the standard object types 
more efficient, so that overall memory usage will likely be less.

While we're talking about memory management, will it be possible 
to add in R3, a mean to adjust or tune GC behaviour by exposing some 
of the internal parameters? The goal is being able to adapt the tradeoff 
between speed and memory usage in various situations. For example 
: being able to set a max amount of memory for a REBOL session.

String, number and block data will be more; binary data will be the 
same; port and graphics objects will be much less. When we get vector! 
working that will drop memory usage in many data processing scenarios. 
Many of the changes to the mezzanines and natives (including changes 
in alpha 49) lower the number of block copies, so that cuts down 
memory overhead.

Adjusting the GC: I don't know.

I've asked on chat.

R3 uses larger slots for values, a side effect of the 64bit integers 
and such.
Can you be more precise Brian ?
How long are the new slots ?

Long enough but not longer? :-)

uhm... something like that

Don't know off the top of my head. Not double in size, as the slot 
overhead hasn't doubled, just the data part.

Is Carl hiding from you such important infos ? :)

I don't ask - haven't needed to know.

You're not Brian, the Brian i know would have killed some kitten 
to know that

I think of memory in terms of number of elements (which i can affect) 
rather than element size (which I can't). I don't think of RAM size 
except for at a overall process level.

He mentioned the real sizes at some point (in a blog I think), but 
I don't remember the exact numbers.

don't remember that

For my code I find that I only need to think in terms of number of 
copies, or preallocation. On an algorithmic level you can save orders 
of magnitude in memory overhead (space and time) by controlling the 
number of copies.

The FOREACH changes in alpha 49 were done to reduce memory overhead, 
for instance.

Don't force me to disassemble the binary to know that, otherwise 
i'm afraid that Dockimbel will kill me.

Same with exposing COLLECT-WORDS so it can be used instead of BIND/set 
into a temporary object.

Oh the FOREACH overhead has been reduced ?

nice news

not anymore  bind/copy with FOREACH ?

The BIND/copy overhead is still there, but being able to use FOREACH 
on map!, object!, module!, port! and error! means that you don't 
have to generate a block! copy of those types in order to work on 
them. Plus you don't need the EITHER or CASE to screen for those 
cases.

In general the size of the code block passed to FOREACH is much smaller 
than the size of the data passed to it.

foreach works now on ports ? are you sure of that ?

In theory, but I think it works on the port fields as if it were 
an object, not on the returned data.

I haven't checked though.

Uhm, was not my request, it would be more usefull to be able to use 
FOREACH as an ACTOR in a scheme.

So on data, rather than to populate properties of an object port

Yeah, I didn't request that either. Did you file a CureCode ticket 
for FOREACH on ports? I recall some overly general ticket you filed 
that was requested to be broken up iinto individual tickets, but 
not the individual tickets.

have to

Ticket 556.

You might be a little late here - port! has been added to the any-object! 
typeset (I can't say for sure). You gotta file tickets if you want 
to get things done.

At least on a native level. On a mezzanine level you can do it yourself, 
as long as it's a good idea :)

uhm, the any-object! type is troublemaker

Port should not be in it, to allow functions to behave as scheme 
actors

It's not a type, it's a collection of types (typeset!). In this case 
a collection of the types that act like objects.