<Regenaxer>
I suspect a simpler case will show the same problem, like http://ix.io/2b0V
<Regenaxer>
Aaahh!
<Regenaxer>
I'm stupid. I posted it above: {src64,pilos/src}/sym.l
<Regenaxer>
src/sym.c is *not* included!
<tankf33der>
2b0V works in pil32
<tankf33der>
wrong.
<tankf33der>
it was pil64
<tankf33der>
=========
<tankf33der>
2b0V fails on pil32 too.
<tankf33der>
:)
<Regenaxer>
Yeah, this feature is simply not implemented ;)
<Regenaxer>
What is 2b0V ?
<tankf33der>
ix.io/2b0V
<Regenaxer>
ah
<tankf33der>
then update doc.
<Regenaxer>
right
<Regenaxer>
Hard to express. Needs in fact a different ref entry
<tankf33der>
just one sentence.
<Regenaxer>
The signature is different, and the description in some places
<tankf33der>
"you can get symbol error meesage in pil32" :)
<Regenaxer>
the addition "or in a list" applies only to pil64
<Regenaxer>
Perhaps it is easier to add it in C too? ;)
<Regenaxer>
Tough to have a single ref for all versions
<Regenaxer>
I plan to make it from scratch for pil21
<Regenaxer>
the ref I mean
<tankf33der>
of course implement in pil32.
<Regenaxer>
:(
<Regenaxer>
I invest all my free time into pil21
<tankf33der>
ok.
<Regenaxer>
Already late in schedule
<tankf33der>
then add just one sentence, 5sec task.
<Regenaxer>
I check tomorrow on a large screen to check the diffs in doc/refP.html from 25aug19
<tankf33der>
thanks a lot.
<tankf33der>
afk.
<Regenaxer>
:)
inara has quit [Quit: Leaving]
<freemint>
Hey in doc64/structures the EXT block contains a n field. How big is it and what is it for?
<Regenaxer>
It is 6 bytes or 48 bits
<Regenaxer>
the link to the next block
<Regenaxer>
EXT-Block: means "extension" block
<freemint>
ok, the ID block and the FREE block also have a field there is it 6 bytes too?
<freemint>
(it seems to range between 0 and 1.
<Regenaxer>
not one but 2**48
<Regenaxer>
The ID block is the first one
<Regenaxer>
and yes, the free list is also linked
<Regenaxer>
linke free mints
<Regenaxer>
BLK is a constant 6
<Regenaxer>
IIRC the 'n' is one byte 0 .. 255
<Regenaxer>
if there are more blocks, they have all 255
<Regenaxer>
it is only for consistency checks with 'dbck'
<Regenaxer>
so all free blocks must have 0, and the first block of an object has 1
<Regenaxer>
ah, no
<Regenaxer>
it is 0 ... 63
<Regenaxer>
'n' is 6 bits
<Regenaxer>
Link is 42 bits
<Regenaxer>
ah, it is all decades ago, I forgot the detail
<freemint>
and for a free block n is still 6 bits but is 0
<Regenaxer>
yep
<freemint>
And the data section is the remaining block after the first 48 bits?
<Regenaxer>
exactly
<Regenaxer>
The smallest block size is 64, so you have a payload of 58 bytes
<Regenaxer>
(The first version of the db had a fixed block size of 64 only)
<Regenaxer>
(and also only a single file, so it did not scale well)
<freemint>
Why 64 bytes minimum and not start with a smaller number like 8 bytes?
<Regenaxer>
then only 2 bytes of payload?
<Regenaxer>
64 bytes is alreay too small for many objects
<Regenaxer>
so it chained a lot and degraded in performance
<Regenaxer>
Most objects have 256
<Regenaxer>
and for B-Tree blocks 1024 or 4096 is needed
inara has joined #picolisp
<Regenaxer>
usually 1024
<Regenaxer>
So 8 as faaaar toooo slow
<freemint>
Ok i am considering stealing the PilDB for another programming language which has small structures too: (16 bit numbers/fp, etc) would it make sense to set the minimum as 8 bytes then if you had small enogh data types??
<Regenaxer>
small
<freemint>
I see that makes sense for PicoLisp
<Regenaxer>
good
<Regenaxer>
But 8 is really useless
<Regenaxer>
for DB blocks in that pattern
<freemint>
What's the biggest block size again?
<Regenaxer>
64 << 255 I think
<Regenaxer>
huge
<freemint>
I see
<Regenaxer>
It is a byte
<Regenaxer>
<< in Block 0 in structures
<freemint>
I see now.
<Regenaxer>
The old DB had 0 in that field, so all was 64
<Regenaxer>
so I added a shift count for larger blocks
<Regenaxer>
historically grown
<freemint>
Since i do not aim to be compatible with pilDB (they have way more datatypes) i think i might start with 8 bytes, even though it makes little sense. Maybe someone needs it and i have no legacy
<Regenaxer>
you can use 8 bytes if you don't need links
<Regenaxer>
So 8 bytes payload
<Regenaxer>
But how to maintain higher level structures then?
<Regenaxer>
Indexes etc
<freemint>
Yes exactly. 8 bytes gives me 2 bytes which is just enough for 16-bit long number types, assuming i know the type that is stored there.
<Regenaxer>
No need for a DB perhaps. Just indexing with lseek() into the data
<Regenaxer>
OK, understand
<freemint>
Mhh, i think i need a DB.
<Regenaxer>
You can stay with variable size, just make the minimum of 64 smaller
<Regenaxer>
or, store several items in one block
<freemint>
Julia has really specific type signatures and potentially infitely many types. I was thinking of having different types of files. "Only contains one data type with ID X", "ID X is stored in block as metadata" and "Type is serialized after header but before data"
<freemint>
ID x would be fixed number of bits long and the look up table is stored in another file.
<freemint>
Does that sound resonable?
<freemint>
If i store several items in one block my storage system would no longer be orthogonal to type system of Julia since they have tupples/arrays
<Regenaxer>
Yes, sounds good
<freemint>
Thank you. The design is really elegant. I will look whether i can steal the idea of external symbols too but my grasp of them is not strong enough yet.
<Regenaxer>
No need to "steal" :)
<freemint>
What are "loaded", "dirty" and "deleted for?"
<freemint>
It is the 2 bit status flag for external symbols.
<Regenaxer>
yes, the db must keep track of these states for each symbol, whether it needs to be written on 'commit'
<freemint>
Why doesn't it do so in Ram?
<Regenaxer>
it is only in RAM
<Regenaxer>
these bits
<freemint>
ahh yes srry
<Regenaxer>
no, valid question, on disk they are not set
<freemint>
Are external symbols always a cell long or can they be stored in half a cell as short numbers are too?
<Regenaxer>
No, always exactly one cell
<Regenaxer>
Plus properties as necessary of course
<freemint>
What benefits does the weird interleaving of file number and object number have?
<Regenaxer>
Short numbers do not use half but zero cells :)
<Regenaxer>
The interleave is very important
<Regenaxer>
keeps the size small when stored
<Regenaxer>
in small dbs with not many symbols
<Regenaxer>
it results in less bytes when written
<Regenaxer>
things like "1+3 Bytes: 16 files, 1M objects"
<Regenaxer>
each ref to other symbols takes max 4 bytes
<Regenaxer>
(it is PLIO)
<freemint>
So external symbol refernces which have leading 0's are smaller when wr'd?
<Regenaxer>
yep
<freemint>
How does rd know when external symbol is over?
<Regenaxer>
it reads a plio stream, which has a definite end
<Regenaxer>
it reads 2 items: value and property list
<Regenaxer>
both can be NIL, which is a single 0 byte
<freemint>
ahh
freemint has quit [Remote host closed the connection]