<Regenaxer>
'need' needs a 'cnt' as first argument
<tankf33der>
in read macro it is NIL
<Regenaxer>
Yes
<Regenaxer>
*read* time
<Regenaxer>
a read macro is evaluated at read time
<Regenaxer>
So it depends on what 'L' is at read time
<beneroth>
hi all :)
<Regenaxer>
It cannot be NIL and 15 at the same time ;)
<Regenaxer>
A quantum-L ;)
<Regenaxer>
Hi beneroth! :)
<beneroth>
tankf33der, `(setq L 15) ?
<beneroth>
keep in mind, reading only takes place once (unless you re-(load) the file)
<beneroth>
Regenaxer, does standard apply have a limit for the argument list size? I thought it only has that in mini and ersatz picolisp?
<Regenaxer>
I think there is no limit, also not in mini or ersatz
<Regenaxer>
In pil21 and pil64 the limit is the stack size
<beneroth>
I had a case of (apply min Lst) and (apply max Lst) not working, with Lst being huge with length 479'460 elements.
<beneroth>
(mini prog Lst) and (maxi prog Lst) work
<beneroth>
pil64
<beneroth>
segmentation fault within the apply
<Regenaxer>
pil64 does not check the stack in 'apply'
<Regenaxer>
try in pil21, it gives "Stack overflow"
<beneroth>
ah, okay
<Regenaxer>
or set ulimit -s unlimited
<beneroth>
I have
<Regenaxer>
'mini' and 'maxi' don't use the stack
<beneroth>
that must it be
<Regenaxer>
yeah
<beneroth>
but I have ulimit -> unlimited
<Regenaxer>
nasty :)
<Regenaxer>
if unlimited, it should just get slow
<Regenaxer>
Perhaps you have no swap partition?
<Regenaxer>
But 479'460 elements is not soo big
<beneroth>
I have 1GB swap and 15GB memory on the machine where I did this, and memory was not exceeded
<Regenaxer>
I see
<beneroth>
yeah and the elements are numbers, not bignums generally
<Regenaxer>
Can you try in pil21 to see if it a stack overflow?
<beneroth>
not now, but I will
<Regenaxer>
ok
<beneroth>
thank you
<beneroth>
must be stack limit
<Regenaxer>
I think so
<beneroth>
I don't think it's corrupted anyhow
<Regenaxer>
perhaps ulimit did not work?
<Regenaxer>
must be in .bashrc
<beneroth>
when I enter "ulimit" in shell I get "unlimited"
<beneroth>
hmmm.. I don't have it in .bashrc
<Regenaxer>
I get a permission error if I set it later
<Regenaxer>
probably because it was set once in .bashrc
<Regenaxer>
Seems it can be set only a single time
<Regenaxer>
Anyway, instead of such a big apply mini is better
<Regenaxer>
tankf33der, why do you need a read macro here?
<beneroth>
i've made some funny things with read macros - but one should keep them to a minimum. can produce very funny errors (especially after modifying 'load function...)
<beneroth>
not so fun to debug.
<Regenaxer>
yep
<Regenaxer>
I'm experimenting with a change to the top level REPL
<Regenaxer>
I make it such that it does not exit any more on NIL
<Regenaxer>
It is an early-on "feature" of PicoLisp
<Regenaxer>
but always kind of surprising
<Regenaxer>
Because an empty line loses privates rnd transients
<Regenaxer>
and resets the namespace search order
<Regenaxer>
So here I have a version now which does *not* exit
<Regenaxer>
I wonder if this could have any bad effect
<Regenaxer>
(I don't even remember if this "feature" was documented somewhere)
<beneroth>
isn't this sabotaging use of `(once T) and use of NIL ?
<beneroth>
I often use NIL on a single line to comment everything below out
<Regenaxer>
'once' depends only on file and line number
<Regenaxer>
And for files everything stays the same
<beneroth>
ok, then I didn't get what you are alluding to
<beneroth>
code example?
<Regenaxer>
The change is only for the *top* level REPL
<Regenaxer>
always on stdin
<Regenaxer>
so if a file is piped to stdin, it would not stop
<Regenaxer>
cat file | pil ...
<Regenaxer>
this would change in behavior
<Regenaxer>
pil file ...
<Regenaxer>
this would not change
<Regenaxer>
I think over it
<Regenaxer>
Perhaps if stdin is a tty only change behavior
<Regenaxer>
I think it is not a problem
clacke has joined #picolisp
<Regenaxer>
I don't see a use case where REPL input is from a pipe
<Regenaxer>
It also doesn't behave well in pil64
<Regenaxer>
It hangs infinitely when the pipe is done
<Regenaxer>
Much better now
<Regenaxer>
Shall I release this?
<Regenaxer>
I like it much better than before
v88m has joined #picolisp
<beneroth>
I think I never piped into pil, but I can imagine use cases where it is good. but hanging is always bad...
<beneroth>
of course what about "tail -f logfile.log | pil ..." where the pipe is kept open and gets new data from time to time?
<Regenaxer>
thats fine
<Regenaxer>
pil21 behaves like pil64 except that it does not hang on eof
<Regenaxer>
Modified pil21
<beneroth>
ok. I guess you will not patch pil64?
<Regenaxer>
hmm, no, that's much more work
<Regenaxer>
It is a re-factoring of 'repl'
<beneroth>
ok, I see. yeah all good, just wanted to know
<beneroth>
I don't think its a critical change
<Regenaxer>
yeah
<Regenaxer>
Good, I release now :)
<Regenaxer>
Done
<Regenaxer>
Now use it in PilBox
razzy has joined #picolisp
<tankf33der>
Regenaxer: do you have bitcoin wallet?
<Regenaxer>
yeap
<razzy>
tankf33der: how close are you to ua?
<Regenaxer>
There is even one published on software-lab
<tankf33der>
razzy: i am from Latvia so close.
<Regenaxer>
Belarus in between
<tankf33der>
good we are in nato.
<Regenaxer>
T
<tankf33der>
belarus is satellite of russia.
<Regenaxer>
I will from now on boycot Russia, by no more drinking russian Vodka
<razzy>
NATO is satelite of USA
<Regenaxer>
yeah
<Regenaxer>
and soon we will all be satellites of China
<razzy>
USA imperialism is only slightly better than russian :]
v88m has quit [Ping timeout: 256 seconds]
v88m has joined #picolisp
v88m has quit [Read error: Connection reset by peer]
<beneroth>
I find morally all sides playing bad, which angers me especially the moral failing on the "western" side I live in.
aw- has quit [Ping timeout: 240 seconds]
<beneroth>
on the technical (strategic/political) perspective, I must say Russia is very good, USA somewhat and Europe gets completely outplayed by everyone and does not even realize it
<beneroth>
Regenaxer, hope you don't have gas heating? maybe this will increase changing to less polluting heating, I expect gas prices to remain/keep high
<beneroth>
on topic question Regenaxer: what is the relevance of *Dbs ?
<beneroth>
is *Dbs used by (pool) to create the files? or are the files automatically created when a commit attempts to write it?
<Regenaxer>
Heating: No, I (still) have oil (and wood a little)
<Regenaxer>
Yes, *Dbs is used by (pool)
<beneroth>
[heating] wood should be better for climate, it does not add C02 to the C02-loop
<Regenaxer>
and whenever a symbol is 'new'ed
<Regenaxer>
But wood gives dust pollution
<beneroth>
okay, so if I maintain file assignments properly in daemon objects, I still need to declare the files/blocksizes in *Dbs before opening (pool), correct?
<Regenaxer>
yes, it needs the list of sizes
<beneroth>
thanks
<Regenaxer>
So 'new' does not use *Dbs directly
<beneroth>
what happens when the block sizes get changed for an existing database, with existing files with another (smaller) block size?
<Regenaxer>
but the properties in classes created by 'dbs'
<beneroth>
only affects new blocks, or risking of corrupting the files?
<razzy>
Regenaxer: Wood is bad only if you burn it wrong and have little green to catch the remains.
<beneroth>
yeah, I know about the usage of 'new'. I specially ask only about the *Dbs globale
<Regenaxer>
It has no effect, because pool takes the block sizes from existing files
<Regenaxer>
but trees may get confused
<beneroth>
ah, good to know!
<Regenaxer>
nodes assume the wrong size
<Regenaxer>
no bad effect though
<Regenaxer>
just not optimal
<beneroth>
so seeking etc. fails, but recovers (so performance hit) ?
<Regenaxer>
seeking will not faal
<Regenaxer>
fail
<Regenaxer>
as it has the old correct block sizes
v88m has joined #picolisp
<Regenaxer>
but b-tree nodes assume a size
<beneroth>
ok, what is then the effect in trees?
<beneroth>
for spliting tree nodes?
<Regenaxer>
to know when to split
<Regenaxer>
yes
<beneroth>
okay
<beneroth>
I see, makes sense
<Regenaxer>
it splits too early
<Regenaxer>
or uses 2 blocks
<beneroth>
but they also get their sizes from the daemon objects, not from *Dbs, or do they?
<beneroth>
I haven't fully grokked where the file assignments for index are maintained
<Regenaxer>
the logical size is from 'dbs'
<Regenaxer>
and the physical from the file's root block
<beneroth>
yeah I know what (dbs) does. I'm talking about *Dbs which is also maintained by it
<Regenaxer>
*Dbs has only a list of sizes
<beneroth>
yep, this one
<Regenaxer>
the sizes are actually only used for a new db
<beneroth>
what is it relevant for?
<Regenaxer>
later just the length is used
<Regenaxer>
to know how many files to open
<beneroth>
during (pool), right?
<Regenaxer>
for a new db, yes
<Regenaxer>
creating the files
<Regenaxer>
and that size is stored in the first block of each file
<beneroth>
so if in the daemon objects any file assignments exist which point to not existing database files, then (commit) fails with a write error because the file is not there?
<beneroth>
ah perfect
<Regenaxer>
yes, right. DB access error
<beneroth>
yeah we need to do a documentation of the file format besides PLIO eventually :D
<beneroth>
okay
<beneroth>
thank you!
<Regenaxer>
yeah
<Regenaxer>
It is rudimentary in doc/structures
<beneroth>
so I must properly maintain *Dbs before calling (pool). size changes only affect newly created files and are stored in the file itself. good.
<beneroth>
yeah
<beneroth>
thank you.
<Regenaxer>
correct
<Regenaxer>
BTW, I dared to use move!> in a production app
<Regenaxer>
Seems to have worked :)
<beneroth>
hehe, brave you!
<Regenaxer>
:)
<Regenaxer>
I did some test runs on a copy of the DB first
<Regenaxer>
Checked all links etc
<Regenaxer>
not all, but some
<Regenaxer>
indexes, blobs etc
<Regenaxer>
had a lot of joints, to moved and non-moved objects
<Regenaxer>
hard to make sure everything is correct
<Regenaxer>
But dbCheck does not complain
<Regenaxer>
and (dbgc) removed the old objects cleanly, so they were indeed nowhere referred to any more
v88m has quit [Ping timeout: 256 seconds]
<Regenaxer>
Of course you can *add* a new file any time to an existing DB by extending (dbs) -> *Dbs
v88m has joined #picolisp
razzy has quit [Ping timeout: 240 seconds]
razzy has joined #picolisp
Abhishek_ has quit [Quit: Connection closed for inactivity]
<beneroth>
Regenaxer, adding new files: but needs a restart (new call to (pool) at least), right?
<beneroth>
ah yes we already discussed, nevermind
<beneroth>
@move: yeah Joints are tricky.
v88m has quit [Ping timeout: 272 seconds]
<Regenaxer>
Yes, just (pool) is enough
<beneroth>
:)
rob_w has quit [Quit: Leaving]
<razzy>
so far i like (dbgc)
<Regenaxer>
:)
aw- has joined #picolisp
theruran has quit [Quit: Connection closed for inactivity]