World: r3wp

Brian, i added the option to save the data as row binaries today 
in VBS

all other values are stored as molded values

I saw that. Does it save all REBOL values in binary, or just binary!?

except binaries

just binary!

Still cool :)

binaries are saved as-is (compact format), all other values are molded 
before being stored as binaries

Rebin is intended to be a binary syntax for REBOL, like EBML for 
XML. All REBOL values (or maybe just the literal values) will be 
stored in a binary format. I suppose rebin would be an output format 
of MOLD and SAVE.

You would need something like RIF to restore the bindings though, 
since you could translate references to RIF indexes. In theory.

You would need a binary format to even have a way to store those 
references since REBOL syntax doesn't, even with MOLD/all.

hmmm... the rebin format will be hudge, cause for series, there is 
2 indirections (2 references) + the value himself

am i wrong ?

No, just the value and the reference to the value with the position. 
The poisition isn't a reference, just an integer (internally). So 
you need the series, the length of the series, a datatype tag, the 
reference to the series, and the offset. The reference and offset 
would be part of the contents of anotther series. It would take less 
space in binary than in memory or REBOL syntax.

I'm not sure that you're wrong though. There's also the index to 
consider.

ahah.... i was near to argue you...:-)

Brian you must be looking over the Carl shoulder :)

The only thing I could dispute would be the "huge" part. References 
wouldn't necessarily need to be stored as full 64-bit integers if 
there is an index, so there could be even more space savings, though 
speed would be king for RIF I expect. In any case I expect much more 
space savings than REBOL text syntax.

As for looking over Carl''s shoulder, I've been more following the 
process and discussions. If you know the REBOL semantics and have 
experience implementing this kind of thing yourself, the big picture 
is obvious. Carl's better at this than I am though - I can only guess 
so far.

B: next A: "blabla"

A (contains a logical reference) --> (physical reference)-->"blabla" 
(value)

B (contains a second logical reference to the same physical reference) 
--> 

if "blabla" is expanded the physical reference is modified and "blabla***" 
is stored in another one place.
The references in A and B are not modified.
That why i said there is 2 indirections (2 references)

but perhaps i use wrong words to explain

I was only disputing "huge", not the rest.

ok

Sqlab and Steeve: Thank you for the user-agent issue

Steeve small typo in your idx.r missing " in the end of line 266 
starting with  "; (notice that binary data.. otherwise works!

ah ! thanks

Thanks, Brian. That´s important info for my optimisation considerations

When surplus memory is preallocated for a block, is the block still 
initialised at the start of the memory or somewhere in the middle?

one more question: when a value is removed inside the block. Is always 
the tail which is moved, or the head can be also ? (depending of 
the nearest one)

Theoreticaly empty space may be in the middle, that is question of 
implementation with influence to performance of course (and diference 
betwen block, hash, list, map etc.)

diference= performance difference

ie shuffle data or pointers only

Pavel, i'm talking about the new implementaion of blocks in R3 (it 
was addressed to Brian). There is no empty space in the middle of 
a block, never.

I have no clue about low level implementation of blocks, but if it 
would be double linked list (from C algorithm POV) it wpould be possible, 
but you are right, doesnt mention it

The double linked lists was used to implement list! type in R2, not 
blocks.

OK

I'm afraid I don't know more about R3's blocks than I've already 
said here - for more, ask Carl. That optimization sounds sensible, 
Steeve, but I don't know whether it is implemented, or what the performance 
tradeoff would be.

Brian, Vector datatype can't be expanded or appended, ie the size 
is fixed in the moment of creation, for use as fix lookup maybe good, 
practically not, it is kind of series and should behave similarly

IMO

there is lot of missing features related to vectors (find, mold, 
to binary!, etc...) It should have the same capabitilies than other 
series...

they are clearly not finished, it's not bugs

Some are missing features, some are bugs. For example, this one:

>> v: make vector! [- decimal! 32 100]
== vector!

>> v/0: 0
== 0

>> v/0
== 49151558502227733

Or this one:

>> v: make vector! [+ integer! 16 100]
== vector!

>> v/0: 20
== 20

>> v/1: 100
== 100

>> first v
== 100


See? I said that introducing zero based series in REBOL is not good 
idea :)

I don't like Zero based indexing too. We are imo opening can of worms 
here.

I really don't understand, how guys might like new 'pick behaviour. 
The example given looks like very bad desicion was made. Why was 
it added? To enable various forms of loops over series?

Pekr, read my response in the blog post.

Yes Pekr, this has nothing to do with zero based indexing. Series 
are still one based:
>> b: [a b c d e]
== [a b c d e]

>> b/1
== a

>> b/0
== none

What we need to worry about is clarity of how each series type behaves 
with the series functions (as uniformly as possible) and fixing the 
bugs for AT on blocks and PICK on strings.

Rebolek - but that is weird, isn't it? So b/-1 will return some word, 
while pick b -1 will return another?

Pekr, both kinds behave identically here.

Henrik - I am referring to Carl's proposed change to 'pick. Is it 
already implemented?