World: r3wp

On the other hand, list nodes are allocated one at a time rather 
than in groups, so if you have a lot of small lists they may take 
less ram than a lot of small blocks. I don't know how many cells 
are allocated when the runtime (re)allocates a block - I think it 
is powers of two up to multiples of 128.

I may be wrong about that multiple value though - it might be 64.

by my testing I'd say its 64, since creating 1 million empty blocks 
takes 64MBs.

No, that's the element size that causes that. Each block element 
has to hold a 64bit value (of various types) plus some typing overhead. 
Plus I would bet that every block has a one element prefix to store 
the block lengths. Plus, there is the overhead of your reference 
to the block which would be a value in another block.

right... I'm a bit tired ;-)

What I was talking about earlier was the allocation quanta. Blocks 
are allocated with the assumption that you will want to insert stuff 
into them without having to reallocate them every time. So by that 
powers of two to multiples of 128, when you want a block length 10, 
you get 16. When you want 129, you get 256, and so on. On that note, 
when you want 1000000, you would get 1000064.

A list may be twice as big, but if you want memory predictability 
you can't beat it because the allocation quanta is 1 node and the 
insert/delete is O(1). Indexing and length calculations are O(n) 
though.

Later...

ciao, thanks for all that info  :-)

wouldn't it make sense for SKIP to support hex values? I'm trying 
to locate a specific position in a binary and it's tedious having 
to convert to number! every time.

what do you convert to number?

What is a hex value in REBOL?

volker, a specific location in the binary taken from a hex editor

but that conversion could be put in a little function by yourself?

i think non-system-coders rarely use hex.

skip can be redefined to something which supports hex numbers...

I just think it's too obvious and useful to leave out

But what is the proper representation of a hex value in REBOL? An 
issue? An ENBASEd string?

it's an issue

why not write a converter and then
  skip bin &h #c4d9

Ah, but an issue is really a string, not a number. The TO-HEX function 
makes it look like this is the recommended approach (it's what I 
would say, too), but I think it's a type mismatch (unfortunately).

I see

That is, I don't think standard functions should take issue! params 
for hex values unless RT says, officially, that it's how you do hex 
values in REBOL.

Is hex notation something we should propose for R3? I'd bet money 
Carl thought about it long and hard in the original design, and may 
even have left some lexical wiggle-room to add it later.

propose = request.

well, I can understand it if there is no official way to represent 
hex values. I think it should be proposed for R3

Its nearly never needed, but if it is needed, its very usefull.

hex-editor or ascii or decoding this unix-rights-numbers or such.

REBOL is very high level, and you tend to use hex notation more in 
low level scenarios, but it's *so* handy to have it there when you 
need it.

yess the kind of thing you need when you are doing projects and the 
specs are not your own.  on the other hand, HTTP 1.1 uses hex values 
for chunk sizes (stupid design if there is one)... so they are still 
used.

Here's what I use:

    hex: func [
        {Returns the base-10 value of a hexadecimal number.}
        value [integer! string! issue!] "A hexadecimal number"
    ][

        ; Convert to an issue first, so integers can also be translated.
        to integer! to issue! value
    ]

When I first started in REBOL, I also aliased it as &H (as a func 
name), since that's the hex notation prefix in BASIC and can be used 
as a func name, unlike "0x"

It is a little extra work to use a func to convert values, but not 
awful. If you need to use it heavily in a particular app, I'd consider 
using a dialect.

binary tools powerpack then?

You bet. Outline the domain and we can cook up a killer dialect.

the problem I have with dialects is they are not extensible

it would be worthy of its own group, wouldn't it?

I think so Henrik, for better focus.

I'll create it now

I mean without rewriting the original dialect parser itself.

Who says Max?

OT: regarding dialects: could 'any be an option in parse? i often 
have
 parse blk [ any[  .. ] ]
would like 
  parse/any blk [ .. ]

when I tried to plug within VID... man it was awfull.

I ended having to piggy back on top of VID.

The Logo interpreter I did (early in REBOL for me) allowed user defined 
functions; basically it just added things to the list of parse rules 
it knew about, naive, but semi-functional. :-)

it predates the block-parser, and that shows.

and that means actually calling the VID parser many many times...

rebgui looks much cleaner IMHO.

Dialects have to be planned for extensibility, just like languages.

gregg, exactly... you have to dialect your dialect's  dialecting 
ability  ;-)