World: r3wp
[!REBOL3-OLD1]
older newer | first last |
[unknown: 5] 21-Jan-2009 [9739x2] | 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. | |
Pekr 21-Jan-2009 [9741x3] | 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 ... | |
[unknown: 5] 21-Jan-2009 [9744] | so no more /lines? |
BrianH 21-Jan-2009 [9745] | READ of file and http ports is binary, so no /lines. |
Henrik 21-Jan-2009 [9746] | 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. |
BrianH 21-Jan-2009 [9747] | Other port schemes will differ. Steeve is working on a block port that looks really cool. |
[unknown: 5] 21-Jan-2009 [9748] | Oh I know it would be possible to do but at a cost in performance I would suppose. |
BrianH 21-Jan-2009 [9749] | Performance of ports is greater overall, so that is a tradeoff I am willing to make :) |
Pekr 21-Jan-2009 [9750] | 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 |
[unknown: 5] 21-Jan-2009 [9751x2] | 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). | |
BrianH 21-Jan-2009 [9753] | Block ports return REBOL values, i.e. database ports in R2. |
[unknown: 5] 21-Jan-2009 [9754x2] | 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. | |
BrianH 21-Jan-2009 [9756x2] | Steeve is doing something similar with his virtual block. |
bbl | |
[unknown: 5] 21-Jan-2009 [9758] | k |
Henrik 21-Jan-2009 [9759] | I read through the Virtual Block Scheme thread on rebdev and it looks quite cool. |
Steeve 21-Jan-2009 [9760] | 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 |
BrianH 21-Jan-2009 [9761x2] | 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. | |
Henrik 21-Jan-2009 [9763] | 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? |
Steeve 21-Jan-2009 [9764] | 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. |
[unknown: 5] 21-Jan-2009 [9765] | So virtual blocks is a storage of blocks in a blocks that is then loaded into memory? |
Steeve 21-Jan-2009 [9766] | 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. |
[unknown: 5] 21-Jan-2009 [9767x2] | Trying to follow so bare with me... |
Your storing data in blocks into a file that is one large container block? | |
Steeve 21-Jan-2009 [9769] | the virtual block acts like block. you can store any type of values in it (which are blocks or not) |
[unknown: 5] 21-Jan-2009 [9770] | So is a virtual block in essence a file? |
Steeve 21-Jan-2009 [9771] | yes |
[unknown: 5] 21-Jan-2009 [9772] | Is the whole file loaded into memory at once or is data read from it in chunks? |
Steeve 21-Jan-2009 [9773] | chuncks, i said no memory overhead, if not there is no interests to develop such scheme |
Henrik 21-Jan-2009 [9774] | so we can basically manage gigabyte sized blocks? |
[unknown: 5] 21-Jan-2009 [9775x2] | Yes, good. |
So does it maintain the index order of the individual blocks within it? | |
Steeve 21-Jan-2009 [9777x2] | yes Henrik, we can |
yes Paul it uses 2 files: an index and the data | |
[unknown: 5] 21-Jan-2009 [9779] | Oh, I see. |
Henrik 21-Jan-2009 [9780] | Steeve, I could use that. :-) |
[unknown: 5] 21-Jan-2009 [9781] | This is a bit like Tretbase. |
Henrik 21-Jan-2009 [9782] | so the data is a plain binary? |
[unknown: 5] 21-Jan-2009 [9783] | Tretbase uses data and a index. |
Steeve 21-Jan-2009 [9784] | 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. |
Mchean 21-Jan-2009 [9785] | does rebdev work with chat from r3? |
[unknown: 5] 21-Jan-2009 [9786] | Cool Steeve. |
Henrik 21-Jan-2009 [9787] | Mchean, rebdev is chat. Same thing. |
[unknown: 5] 21-Jan-2009 [9788] | How is the performance Steeve? |
older newer | first last |