World: r3wp

No, I don't have access to it.

I just figure I hadn't seen it mentioned of having this feaure.

rebdev was up. the client was too old. :-)

Good are you making the request?

I'm not sure how to describe it.

wait... perhaps it's better to use Curecode if you have an account.

Basically it is open/lines  but instead of separating lines from 
the stream it would separate the blocks.

So a block of blocks would be returned.

I don't know what curecode is.

Never heard of it before.

Curecode is the R3 bug database. It's public.

Oh, didn't know that.  Got a link?

http://curecode.org/rebol3/view-tickets.rsp

cool, I'll see what I can do in that regard.

Thanks Henrik.

NP. Please study the reports. I think there are many regarding ports.

Hmmm, it doesn't let me register.

Oh it took my name but gave me an error.

I actually would only request it for the speed.  I already have the 
produced the functionality but it obviously isn't native so I figured 
we could gain some speed.

hmm, not sure there is going to be any /lines etc. for read.

besides that - line feed is pretty common delimiter, whereas blocks 
are only REBOL facility. I think it belongs to higher level parsers 
(decoders)

some few weeks ago I posted here xy links about new ports, read vs 
load etc blogs, which sum those issues up ...

so no more /lines?

READ of file and http ports is binary, so no /lines.

The thing is that such facilities may be higher level now, to get 
more performance on the lower level. It's still possible to do, I 
think.

Other port schemes will differ. Steeve is working on a block port 
that looks really cool.

Oh I know it would be possible to do but at a cost in performance 
I would suppose.

Performance of ports is greater overall, so that is a tradeoff I 
am willing to make :)

Paul, please read those ones:

http://www.rebol.net/wiki/Port_Implementation
http://www.rebol.net/wiki/Ports
http://www.rebol.net/wiki/Port_Examples(a good one ....)
http://www.rebol.net/r3blogs/0127.html"Pruning down

Thank Pekr, will do.

The first one says that data buffer is binary or BLOCK.  Wonder what 
is meant by that.  (I'll continue reading).

Block ports return REBOL values, i.e. database ports in R2.

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