World: r3wp

or, even send-page copy data mime

rather than mutating, we say "altering" :)

actually it worked fine the original way.. problem was  i set the 
out: "test" within tiny server's try block

sorry, not try.. in it's ANY[] block

whatever

:-)

so.. any [ out: "test"    send-page out mime] 
well.. out: "test" is any, isn't it ;)

but thanks for the quick response

I like that ... have a  "whatever [ ..  ] "

yes, so send-page never gets executed

hehe

send-page also doesn't return anything

you probably meant 

all [ out: "test" blah .. ]

here's another question..

if you have a block like so.. 

aaa: [bbb[ccc "string"]]


do the 'words  take up memory?  is there a limit to the number of 
'words in a block?

length? first system/words
== 1245
   aaa: [bbb[ccc "string"]]
== [bbb [ccc "string"]]
   length? first system/words
== 1248


Max words is around 8192 (varies by version). Note that 1000 or so 
are taken up when you start.

hmm, so that's not very practical way of storing a large flat DB 
?

Ashley's rebdb is an in memory db

That's *unique* words, not total words used

You can have as many aaa's as you like in different contexts; it 
adds only 1 to system/words

yeah.. i just need a simple hash table

but i like the  aaa/bbb/ccc  path syntax

a dictionary , for example..   cat ["def of cat" ] dog ["def of dog"]
run out of words real quick

But you may need to use strings or some other form of identifier 
-- REBOL words are rationed.

yeah

but then you lose the path syntax.

Use ordinals, then you can  go up to maximum integer with path syntax:
  database/1/234/4454/655/3

Slight problem there: when you delete things you have to leave empty 
slots or change all numbers.

given they would act as keys.. that would be more than a 'slight' 
problem

There's always a design trade-off.

I have various systems where real keys (usually strings) are mapped 
to surrogate keys (usually integers). It's a good compromise in many 
cases.

What is THE best way to store a large hash table in memory  like 
a dictionary, .. and access the data?

terry, about accessing data, there is a speed issue with doing so 
with using indexes with paths, so data/2 is much slower than second 
data or pick data 2. that should solve at least that aspect.

Not sure there is one best way.....I have a structure that has 158,000 
keys indexing 120,000 documents. All in  memory. 
The index (when loaded) is nearly 6meg.

The code uses nested tables, hashes, surrogate keys and a couple 
of other tricks devised for the purpose.

It's worth playing with approaches. You can normally expect a  ten 
fold improvement between initial ideas and later improvements.

yeah, i see that just pokin around with some data now..

I take it your keys are string?

Just thinknig that even Carl's tiny web server, that loads the www 
content into a hash table would be a very fast server

Don't even need mod-rewrites.. just intercept the GET request and 
take it from there

I've been working with Apache and PHP quite a bit, and it just feels 
really bloated.

Is there any reason why to write for example: [ b: make block! 100 
] instead of just  [ b: copy [] ] ?

make block! 100 means that you can insert at least 98 values before 
a reallocation is needed

Whereas.

copy [] reserves some other number (you can find out, more-or-less, 
by close observation of stats)

(the difference is an implementation quirk)

i mean the diff between 100 and 98

to say it another way, as long as length? b is less than 98, insert 
tail b is guaranteed to be O(1)

it looks, that the copy is faster a little bit, at least if I don't 
know how big the block can be, so it's probably better to use copy 
[] (if I don't know precise size):

>> tm 1000 [b: make block! 20000 loop 5 [insert/dup tail b 0 1000]]
0:00:00.907
>> tm 1000 [b: make block! 200 loop 5 [insert/dup tail b 0 1000]]
0:00:00.453
>> tm 1000 [b: copy [] loop 5 [insert/dup tail b 0 1000]]
0:00:00.437

>> tm 1000 [b: make block! 5002 loop 5 [insert/dup tail b 0 1000]]
0:00:00.343

Try do it several times and take the average.

perhaps also make block! is easier to garbage collect?

Is there a rebol based wiki that has versioning?

This seems at least inconsistent to me:

>> to integer! none
== 0
>> to decimal! none
** Script Error: Invalid argument: none
** Near: to decimal! none

also happens with empty strings

rebolek: i believe that is on rambo already. if not, feel free to 
add it.

oldes: i would guess that make block! n also clears the allocated 
memory, so it may be slower than a reallocation if you are using 
something like insert/dup etc. i think that when reallocating, the 
size is always doubled, up to a limit after which it is increased 
linearly.