<beneroth>
wow, most (of the few) comments are not even derailed yet! :D
<abu[7]>
T
<beneroth>
whenever picolisp is on HN, the comments usually derail very fast into general lisp or lang discussions ^^
<abu[7]>
Yeah
<beneroth>
good comment you made, abu[7]
<abu[7]>
My wording "infinite" was indeed wrong though
<beneroth>
not really. infinite in terms of language design
<beneroth>
you're one of the least people needing that nitpick
<beneroth>
usually you are telling this nitpick
<abu[7]>
true
<beneroth>
anyway, just ignore it, doesn't matter .)
<beneroth>
:)
<abu[7]>
but "arbitrary" is better
<beneroth>
T
<abu[7]>
I in fact wanted to say "unlimited", but that's not correct either
<abu[7]>
It is limited by hardware
<beneroth>
I think "arbitrary" is indeed the correct term. That is the term I use to explain this.
<beneroth>
but unlimited (by language design) is also correct
<beneroth>
everything is limited by hardware, so that is a pointless fact, it applies to everything.
<abu[7]>
yup
<beneroth>
virtual things (information in a computer, doesn't matter if on silicon or biological basis) can be infinite. real implemented things are always finite.
<abu[7]>
Even execution time, is the life span of the Universe is finite :)
<beneroth>
well quantum computing might put an interesting spin on this, if it turns out to actually work. but that is not clear yet afaik.
<beneroth>
I think the whole concept is wrong. If your configuration is so complicated that it needs a (turing-complete) programming language, then you should get rid of that configuration and use a tool which is better suited for configuring electronic computers: programming languages
<beneroth>
if you need multiple layers to make another software do want you want, then it's all bloat and instead you probably should implement the real task in a real programming language directly
<beneroth>
of course if you are somehow forced to work in a braindead environment then this might be needed.
<beneroth>
it can be legitimate as a temporarily way during migrating a legacy system into a new implementation.
<abu[7]>
Well said!
<beneroth>
thx :)
bjorkintosh has quit [Ping timeout: 276 seconds]
rob_w has quit [Remote host closed the connection]
<abu[7]>
Pil has more layers, the lowest is just external symbols
<abu[7]>
They press all in one layer it seems
<beneroth>
not sure about that, I guess their tuple's are kinda equivalent to pil's external symbols - apparently they also store index values and other objects in tuples
<beneroth>
s/index values/index nodes
<abu[7]>
probably
<beneroth>
its a lot more metadata, but I don't see the principal benefits of that over the pildb structure
<beneroth>
I'm actually surprised. I thought that postgres et al would do use moch more optimized physical structures
<beneroth>
I don't see the benefits yet, the disadvantage are clearly the necessary linking-indirections and artificial limitations
<beneroth>
abu[7], do you know of anyone doing a real benchmark with pildb and a "mainstream" dbms since that (half-botched) heise c't comparison?
<abu[7]>
I have not heard of
<beneroth>
picolisp is of course slower than C/C++, but the advantage of lisp architecture might gain quite some benefits...
<abu[7]>
I did TPC-H many years ago
<beneroth>
TPC-H?
<abu[7]>
Should dig that out again
<beneroth>
ofc in pil the greater control fo the programmer also means more direct "costs" if the programm is bad
<beneroth>
I don't find "pico" or "pil" in the results (in the txt, the xls are 404) - I guess you implemented TPC-H for yourself, but you didn't officially participate?
<abu[7]>
Yes
<beneroth>
kk :)
<abu[7]>
On pil32
<abu[7]>
12 years ago
<abu[7]>
I'll investigate
<beneroth>
I must have missed that
<beneroth>
I've found the c't competition you participated back then
<abu[7]>
I never published
<beneroth>
well, even longer ago
<abu[7]>
just played around
<beneroth>
:)
<beneroth>
as a general estimate, I would expect pil64 to be faster than pil32, and pil21 also faster than pil32 (unsure about comparison to pil64), right?
<beneroth>
(without benchmarking, just theorizing)
<abu[7]>
I think so too
<abu[7]>
Main problem was too small memory back then
<abu[7]>
maybe 1 GiB
<beneroth>
I see
<beneroth>
CPU caches also got a lot bigger
<abu[7]>
It is a disk cache issue
<abu[7]>
not CPU
<beneroth>
right
<beneroth>
postgres limits the physical files to 1 GB. I wonder if that comes from older fs limitations or performance considerations
<abu[7]>
Strange indeed
<beneroth>
postgres also requires a filesystem
<beneroth>
so I guess that's a point for pilDB (though likely ignoring things like bit rot / checksums etc...)
<abu[7]>
Pil does not require it, but a fs probably does better block caching
<beneroth>
T
<beneroth>
and also error detection
<beneroth>
pil assumes the storage medium to be reliable
<beneroth>
right?
<abu[7]>
You mean it does not read after write to check?
<abu[7]>
It check write() return values though
<beneroth>
no, I mean checksum to mitigate storage errors over time
<abu[7]>
Pil has no control over that
<beneroth>
T
stephen_ has joined #picolisp
<geri`>
abu[7]: what's the difference between idx and enum?
<geri`>
enum seems to be a balanced binary tree (not sure what's used as a key though), not sure about idx
<tankf33der>
both are trees
<abu[7]>
In '"call foo" plus "ret" Is ths same as "jump foo" but uses the stack and takes more time.
<abu[7]>
call foo
<abu[7]>
Why? The call instruction pushes the current address and jumps to foo. When foo is done, it pops that address and jumps to it, so it arrives at the "ret" which is following the "call foo" instruction. Then the "ret" again pops a return address and jumps to that.
<abu[7]>
ret
<abu[7]>
...foo runs...
<abu[7]>
ret
<abu[7]>
Instead
<abu[7]>
jmp foo
<abu[7]>
...foo runs...
<abu[7]>
ret
<abu[7]>
ooh
<abu[7]>
sorry
<abu[7]>
Steno paste :)
<abu[7]>
In 'idx" the key is stored in the tree
<abu[7]>
In 'enum' the key is numeric and not stored
<abu[7]>
it is implicit
<abu[7]>
: (idx 'I 1 T)
<abu[7]>
-> NIL
<abu[7]>
: I
<abu[7]>
-> (1)
<abu[7]>
: (enum 'E 1)
<abu[7]>
-> (NIL)
<abu[7]>
: E
<abu[7]>
-> (NIL)
<abu[7]>
(NIL) is a cell you can use to store a payload value
corecheckno has joined #picolisp
<beneroth>
idx is usually not balanced (and therefore inserts should not be in sequential order) unless you use 'balance (build a balanced idx from a ordered list)
<beneroth>
idx is used to represent/store a set, but can be used as a lookup table when combining it with 'lup function