World: r3wp

Well that is why I do currently in the newer Tretbase.  I actually 
read blocks from a file and they contain REBOL values.

I have it down to it being very fast but I know if the code were 
native it could be much faster.

Steeve is doing something similar with his virtual block.

bbl

k

I read through the Virtual Block Scheme thread on rebdev and it looks 
quite cool.

it's work well now, i think i could rewrite the rebdev client using 
virtual bocks, but i will not if Carl doesn't bother T_T

We can afford to wait for now: It will be a while before there are 
enough messages for that kind of optimization to be needed.

Carl is busy enough as it is. Let's wait to optimize RebDev until 
the DevBase parts are included, or at least until the source is out.

Steeve, can you explain in a few lines what it does? It simply stores 
a block as a file and lets you seek/edit it?

Right Brian,  but more the client grows more it will  need time to 
rewrite it.

The hard work doesn't come from the replacement of blocks with  virtual 
blocks (it's minor).

The problem comes from useless needs to reload and sort blocks in 
memory after each connection.

Outside the big respect i have for Carl, it's a poor conception, 
sorry.

So virtual blocks is a storage of blocks in a blocks that is then 
loaded into memory?

Henrik, yes a virtual block act like a block, you can use most natives 
which handle blocks as is.

The gain is that there is no block bloating the memory, all actions 
are converted to file actions.

So you can work with blocks containg millions of data with no pain 
and overhead.

Trying to follow so bare with me...

Your storing data in blocks into a file that is one large container 
block?

the virtual block acts like block. you can store any type of values 
in it (which are blocks or not)

So is a virtual block in essence a file?

yes

Is the whole file loaded into memory at once or is data read from 
it in chunks?

chuncks, i said no memory overhead, if not there is no interests 
to develop such scheme

so we can basically manage gigabyte sized blocks?

Yes, good.

So does it maintain the index order of the individual blocks within 
it?

yes Henrik, we can

yes Paul it uses 2 files: an index and the data

Oh, I see.

Steeve, I could use that. :-)

This is a bit like Tretbase.

so the data is a plain binary?

Tretbase uses data and a index.

yes Paul like your tretbase conception, the only difference is that 
it's a scheme and there is no new functions to deal with.
The programmer can continue to think is working with a block.

does rebdev work with chat from r3?

Cool Steeve.

Mchean, rebdev is chat. Same thing.

How is the  performance Steeve?

No Henrik, the data are stored like rebol values (not in binary or 
other obfuscated format).

It means that you can load the data files (with load %data) and you 
will load that whole block into memory.

Steeve&Paul where to read about I missed the point

About  what part Pavel?

Steeve, could the file be compressed or is that too much overhead 
or unfit for the scheme?

virtual block scheme

That is Steeve's design.

Mine is a bit different.

Henrik when i enter chat in R3 console i get Script error: chat has 
no value

is it available?

Paul, i can't test the perfs currently, because there is some remaining 
bugs in the file scheme, so that i have to open close the ports each 
time a value is append in the block.

Virutual block scheme? - I think it is going to be in R3.

OK

Yes, I konw how that is.

In Tretbase, I decide to incorporate a second method that uses just 
the data file and reads blocks from it.

It required that I had to create a block parser.