rob_w has quit [Remote host closed the connection]
rob_w has joined #picolisp
teddydd has quit [Ping timeout: 256 seconds]
teddydd has joined #picolisp
inara has quit [Quit: Leaving]
inara has joined #picolisp
fuxoft has joined #picolisp
<fuxoft>
The docs for pico say: "A global constant holding the initial (default) namespace of internal symbols. Its value is a cons pair of two 'idx' trees, one for symbols with short names and one for symbols with long names (more than 7 bytes in the name)." Is this true? It looks like a standard idx tree to me, not a cons pair of two trees
<abu[7]>
The doc is correct here
<fuxoft>
Then how come (length (car pico)) is 1?
<fuxoft>
Shouldn't (car pico) be the first of two tree?
<fuxoft>
Shouldn't (car pico) be the first of two trees?
<abu[7]>
The car is in fact '~
<abu[7]>
s (cadr pico))
<abu[7]>
(less (cadr pico))
<abu[7]>
(less (cddr pico))
<abu[7]>
These are the two trees
<abu[7]>
The pair is consed with the symbol '~' as a marker
<beneroth>
fuxoft, use (view pico) to see whole tree rendered as ascii (from left to right)
<abu[7]>
So at runtime namespaces can be detected
<abu[7]>
So indeed the ref is incomplete
<abu[7]>
I will add a note
<beneroth>
:)
<beneroth>
abu[7], you got time for another question?
<fuxoft>
O
<abu[7]>
Sure :)
<beneroth>
abu[7], the ref for *DB says "Except during debugging, any explicit literal access to symbols in the database should be avoided, because otherwise a memory leak might occur (The garbage collector temporarily sets *DB to NIL and restores its value after collection"
<abu[7]>
T
<beneroth>
how is that to be understood? I think this is a newer warning?
<beneroth>
literal access is any access to external symbols? or just when accessing external symbols by internal address?
<fuxoft>
If the two trees are (cadr pico) and (cddr pico), shouldn't (idx (cadr pico)) return the first of two trees as a list?
<abu[7]>
It was there since early on
<abu[7]>
(idx (cdr pico) ...
<abu[7]>
needs a var
<abu[7]>
so the other tree cannot be accessed this way
<abu[7]>
The are kind of internal idx trees
<abu[7]>
The key handling is also special
<abu[7]>
treating the names numerically iirc
<fuxoft>
This seems to work: (setq coms (cddr pico)) (idx 'coms)
<abu[7]>
beneroth, if you have (if (; '{A7} 'foo) ...
<beneroth>
I guess because access to this tree is happening in the reader, so in LLVM picoscript, not on lisp-level
<abu[7]>
T
<abu[7]>
in @src/sym.l
<beneroth>
abu[7], this is kinda my use case, (; *DB foo)
<abu[7]>
Ah, this is Ok
<abu[7]>
(; {1} foo) is not
<abu[7]>
*DB is the only safe way
<beneroth>
so using *DB or using another variable pointing to another external symbol, e.g. (val A) -> {345} because (setq A (db ...)), would be ok?
<beneroth>
but direct access to {345} or {1} is a risk?
<fuxoft>
Oh, so analyzing pico is not the best way to understand idx trees... :)
<beneroth>
fuxoft, T
<abu[7]>
Not access, but literal use
<beneroth>
fuxoft, idx is a bit tricky. my recommendation: 1) keep in mind that (idx) expects a 'var, and 2) check out (lup) function
<beneroth>
abu[7], what about (extern) to fetch an external symbol?
<abu[7]>
OK too
<beneroth>
I sometimes use (name) for an identifier
<beneroth>
when there is no Key or it's feasible for other reasons
<beneroth>
abu[7], ok, so just no hardcoded literal external symbols
<abu[7]>
(de foo () (xxx `(get *DB abc) ... is a problem
<beneroth>
and if absolutely necessary (I cannot think of any good reason), then hardcode it e.g. as (; (extern "354) foo) to prevent the memory leak?
<abu[7]>
OK too
<beneroth>
ok I see
<beneroth>
and I understand the issue
<abu[7]>
gc does not care
<beneroth>
external symbols might get new internal address during gc run
<beneroth>
thx
<abu[7]>
Yes, but this is not the problem
<abu[7]>
if a symbol is in the code, all others reachable from it won't be collected
<abu[7]>
even if not in use
<beneroth>
ah, like properties of the external symbol materialized in the literal instance?
<abu[7]>
materialized -> referred
fuxoft has quit [Quit: Client closed]
<abu[7]>
{1} refers to *all* syms
<abu[7]>
*DB is handled specially by gc
<abu[7]>
It first cuts it off
<abu[7]>
then collects
<abu[7]>
and then connects back
<abu[7]>
So all symbol reachable from local parameters and bindings are kept