World: r3wp

Anton, Geomol, thanks...will try those on my next visit.

Good luck.

I was going to ask what is a good hex editor to download into ubunto...but 
then I figured out I should just use a REBOL hex editor...if I need 
to to change I can just change it myself.

BTW, your virtual face demo rocks, Anton.  I contorted the face so 
hard, it nearly cracked my CRT!   ;-)

Thanks. :) I had to contort my forehead for a few days to get that 
to work.

That could cause wrinkles.  Hmmn, I searched the library and don't 
see the hex editors...trying to remember where they came from.  I 
think at least one was pretty decent.

eFish - wasn't it in terms of competition? Try ViewTop then, and 
rebol.com competition section ...

http://www.tgd-consulting.de/Download.html

thanks, Pekr

Am I the only one who thinks that 64bytes for an empty block is a 
lot or ram?

doing stress testing, of liquid and inderctly REBOL, I have measured 
that allocating 1million blocks takes up exactly 64MB of ram and 
each block I add to the context adds exactly 64MB.

each block adds exactly 64 bytes...do you mean?

yes.

seems like an empty block should only take 2 bytes...but then that 
is just the ASCII representation...binaries are bigger than their 
source code...I would expect some list links pointing, some datatype 
info...dunno.  Maybe try a small program like REBOL[] probe empty: 
[] and inspect the RAM of it.

hehe, your the embeded hw expert  ;-)  probing RAM directly.. man 
haven't done that since I've used amiga!

would be a good extension of a hex-editor...to just load a memory 
address and peek around and look at things...have REBOL inspect itself.

.... and hackers hack in :-)

if I understand it correctly, we should get it with debug hooks ... 
powerfull debugger would help ...

I don't have a Lauterbach debugger for x86 ... only for ARM, PPC, 
XSCALE, and some other MCUs...or that WOULD be cool.

I am starting to understand the challenges "big" app developpers 
encounter when trying to solve complex data models.

I think I will have to design a cluster engine for liquid quite rapidly 
for some of my projects.

for very structured data, when space is a premium, and if it is packed 
tight, you could always do it through a dynamic linked library.

yeah, I intend to recode code liquid as a c module eventually, and 
probably use that natively in python and make a dll for it in rebol.

but waiting R3 for that... I'd like to allow liquids to be datatypes.

...but how much does the size increase when you populate the empty 
blocks with data?

the size of that data linearly.

thus integers add 2bytes per ints, etc.

maybe a little bit more for linkeage data.

(also, you might find ways to structure your data in REBOL which 
reduce the number of block...like make them into structured objects 
... just a wild guess, maybe that would compact it more?)

objects take way more... hehe have you ever even tried to allocate 
1 million objects which have 40 methods.  REBOL won't even be able 
to allocate 20 thousand of them.

I had to use shared methods (like face/feel)

and can still allocate 20000 nodes a second on my trusty 1.5GHz laptop.

does an array help?

do you mean the array function?

cause it allocates blocks ;-)

seems like some improvements could be made by storing more things 
in each block.

each node is an atom.

but it seems it would be a speed - size tradeoff.

and needs its own block to determine its dependencies.

note that I am allocating 1 million objects... we are talking enterprise 
solutions here.

with more ram I can go to 10 million... that's without data...

the fallacy of db-centric programming ... is having data centrialized, 
rather than distributed.  If you split it apart into separate messaging 
agents, then you might be able to reduce the bottlenecks created 
by having the data cetralized.

with bedrock, each cell, is its own individual atom. there are no 
tables.

each cell is a store of associations this cell has with other things 
in the db.  being bi-directional nodes, I can create sets or groups 
of nodes and nodes can backtrack them to query related informations.

so in theory, when I add offloading of nodes (to disk or remote computers) 
within liquid, we'll be able to scale the db infinitely.

well, limited by 64 bits of addressing at a time.

(thats if R3 has a 64bit mode)

bits or bytes?

oh, is that what you are worried about?  I thought you were saying 
an empty block takes 64 bytes.

two different issues.