World: r3wp

So obviously no PAE hacks, but we get 4GB usable address space for 
the R3 process, at least.

On pre-Vista server versions of Windows you used to be able to change 
the balance to 1GB OS, 3GB apps, as an install opton. This is likely 
done dynamically now.

The famous /3GB switch :)

Recently Carl increased the limit on maps - it used to be less than 
500,000 pairs - but if there is a hard limit now it is unlikely to 
be increased for the 32bit builds.

Do you have a CureCode reference for that handy?

He even wrote a blog about it.

Here are my current findings:
https://gist.github.com/1ece58c8302b2d1f734b

Ah, of course!

A hard-coded allocation progression would have been my current guess 
:)

http://issue.cc/r3/1344

http://www.rebol.net/r3blogs/0295.html

We clearly have a different concept of "recently" :)

On this project, anything in the last year is recently.

Disqualifying that ticket and blog :)

Which this wasn't

I'm having AltME freezes again.

A single map! is limited to 2 ** 26 - 1 entries. Or ~3GB memory.

You should put that in a comment to #1344.

Already did. Also added a (rather unlovingly formatted) comment to 
the map! docs.

(http://www.rebol.com/r3/docs/datatypes/map.html)

Here's a plot of the DT for each "put" operation (m/(i): i) for 19M 
puts:
http://bolka.at/2010/rebol3/tmp/raw19.png

Will do a properly sampled one tomorrow.

>> to-integer #{ffff}

== 65535  ; how can I make it -1,  is there a to-signed-integer function?

I believe that integer!s in R3 are signed 64-bit integers.

>> to-integer #{ffffffffffffffff}

== -1

They are, but that's the question is different... we should be able 
to do such a conversions somehow. Don't know how at this moment.

>> sext32: func [x] [32768 xor x - 32768]
>> sext32 to-integer #{ffff}
== -1

something like:
>> shift to-integer #{FFFF0000 00000000} -48
== -1

:)

sorry, should be sext16

>> sext16: func [x] [32768 xor x - 32768]
>> sext16 to-integer #{ffff}
== -1

>> shift shift to-integer #{FFFF} 48 -48
== -1

>> shift shift to-integer #{0001} 48 -48
== 1

My version seems to be a little bit faster:
>> sext16_v1: func [x] [32768 xor (to integer! x) - 32768]
>> sext16_v2: func [x] [shift shift to integer! x 48 -48]
>> dt [sext16_v1 #{ffff}]
== 0:00:00.00001
>> dt [sext16_v2 #{ffff}]
== 0:00:00.000009

Your persone is a little bit saner as well :)

version*

Well, another idea for the map! performance degradation: the actual 
hash function used is flawed for >>2^24 keys.

Another indication: plain CHECKSUM computes a 24-bit CRC

I'm now quite confident that this is the underlying problem.

Conclusion: R3 map! is currently basically unusable for 2^24+ entries.

It should be rather easy to fix, though.

2 Andreas:  2 ** 26 limit is hardcoded into checksum/hash function 
IMO, this hash function is used for calculating respective key hashes 
in map! datatype I think, nevertheless this hashing is pretty fast 
and could be used in in-file hashes, there the limit can be theoretically 
limiting. But still 2 ** 26 hash table is pretty huge indeed.

For 2**25 and 2**26 hash table sizes the hash function gives different 
hash numbers, so I think the limit is 2**26 (sorry I missed your 
observation few lines before you are right off course)

Does anyone have any information / Documentation on how to invoke 
a separate R2 program from R3 and/or vice versa?  In other words, 
is it possible to have an R3 script running and start up a separate 
instance of another R2 and/or R3 program to complete some tasks and 
then resume the original script?


Is it possible to time the event to run in a pre-determined amount 
of time?  Say like 5 seconds for the second program to run, if not, 
then show some error message.


What, if any, communications can occur between the programs, passing 
arguments, blocks, files, urls, etc.

You can do that with CALL and communicate via TCP.

Thank you Rebolek -- I'll check that out.

Let's have:
	o: context [a: 1 b: 2]
I can do:
	values-of o ;== [1 2]

Can I update these values somehow to get o == make object! [a: 3 
b: 4]  just using block of values [3 4]?

v: values-of o
... change v ...
set o v

Great... and it is possible in R2 as well.. I'm still learning:)

shortcut:
get o 
== [1 2]

if you want to set an object with another one, better to use
resolve/all o1 o2

I wanted to avoid using objects as an extension's command argument, 
but I decided that it will be more user friendly to use object directly 
anyway... more work on C side, but it worths for it.