avocadoist has joined #picolisp
avocadoist has quit [Read error: Connection reset by peer]
avocadoist has joined #picolisp
avocadoist has quit [Ping timeout: 256 seconds]
isaneran has joined #picolisp
isaneran has quit [Remote host closed the connection]
isaneran has joined #picolisp
z4k4ri4 has joined #picolisp
<
tankf33der>
Morning
<
tankf33der>
100k co with 10% gc run for 10h without crash. Good.
chexum has quit [Remote host closed the connection]
chexum has joined #picolisp
chexum has quit [Remote host closed the connection]
chexum has joined #picolisp
seninha has quit [Quit: Leaving]
<
abu[7]>
Thanks tankf33der!
z4k4ri4 has quit [Quit: WeeChat 3.6]
z4k4ri4 has joined #picolisp
<
tankf33der>
want to implement new test for co
<
tankf33der>
create 100k co, (gc), stop 100k co, repeat
<
abu[7]>
Tests if all i
<
abu[7]>
s cleaned up
<
tankf33der>
i will post my prototype
rob_w has joined #picolisp
msavoritias has joined #picolisp
<
fbytez>
No interest in cleaning up the FD leak?
<
abu[7]>
Hmm, as I tried to explain above, I don't consider this as an FD leak
<
abu[7]>
And I also see no consistent way (also see above)
<
fbytez>
If I were to write a patch, would it be worth my time or you have no interest at all in fixing it?
<
abu[7]>
How would you do it? I mean then you need to clean up more stuff
<
fbytez>
I haven't explored enough yet—I don't want to waste my time—to settle on exactly how.
<
abu[7]>
I think it would be inconsistent
<
fbytez>
Fine. I'll not bother.
<
abu[7]>
You need to clean up
*all* possible resources allocated in forkLisp()
<
abu[7]>
Yeah, better
<
abu[7]>
I think it is not an issue
<
fbytez>
I don't agree, but it's not my decision.
<
abu[7]>
But thanks for the proposal!
<
tankf33der>
my tor machine is broken
<
tankf33der>
can paste only here manually via browser
<
abu[7]>
A leak is a repeating loss of resources, growing losses over time, finylly resulting in a system failure
<
abu[7]>
Here we have a single case, in an error
<
abu[7]>
And production applications exit on an error
<
abu[7]>
If forkLisp() fails, it is a fatal error
<
abu[7]>
If you would despite this want to clean up, you would need cleanup code after every call to (closeOnExec), as they all might throw an error
<
abu[7]>
So this all is a huge bunch of code, which would never be helpful as applications exit anyway
<
abu[7]>
tankf33der, (stack 1) is too small
<
abu[7]>
Stack frames keep a reserve of 1 K
<
abu[7]>
So nothing will run without error
<
abu[7]>
(stack 2) probably also is too small for anything useful
<
tankf33der>
it works here
<
abu[7]>
hmm, but very risky
<
abu[7]>
I think I would never go below (stack 4)
<
tankf33der>
i do see in top or htop heap not freed
<
abu[7]>
Some internal functions like string processing will use stack in unexpected situations
<
abu[7]>
e.g. reading data
<
abu[7]>
You mean heap, not stack?
<
abu[7]>
Stack is never freed
<
fbytez>
abu[7], Do you think of pil more as web framework or a general purpose language?
<
abu[7]>
Heap
*may* be freed if you do (gc 0)
<
abu[7]>
fbytez: both
<
tankf33der>
i see the same szie
<
abu[7]>
Heap is freed if (gc 0) leaves one or more heap structures without
*any* cell
<
tankf33der>
ix.io is dead
<
tankf33der>
i will switch to pb1n.de everywhere
<
abu[7]>
Good that we have pb1n
<
fbytez>
I was wondering actually, does pb1n belong to someone here?
<
abu[7]>
Unix allocates memory by increasing the "system break". malloc() then uses and frees memory from that
<
abu[7]>
system break may not be decreased
<
abu[7]>
and this is what ps shows probably
<
abu[7]>
fbytez, yes, tankf33der made it
<
fbytez>
Nice. Is it a pil app?
<
abu[7]>
I think so. Right tankf33der?
<
tankf33der>
pil app
<
tankf33der>
abu[7]: is code ok for testing?
<
abu[7]>
'intern' is not needed
<
abu[7]>
just 'pack' is ok
<
abu[7]>
What if you remove the co's in a random order?
<
abu[7]>
(let Lst (range 1 500000) ... (shuffle Lst)
<
abu[7]>
'shuffle' from @lib/simul.l
<
tankf33der>
too long list
<
tankf33der>
thinkinhg
<
abu[7]>
(range 1 500000) is not so very big though
<
abu[7]>
also good to stress the gc a little
<
abu[7]>
But shuffle may take a while
<
tankf33der>
i do not have memory for 500K with big stack
<
abu[7]>
Then perhaps delete coroutines with (rand 1 500000)
<
tankf33der>
with do ?
<
abu[7]>
It may not stop all
<
tankf33der>
but co should stop if call without body
<
abu[7]>
(do 500000 (co (pack .. (rand ..]
<
abu[7]>
this stops many
<
abu[7]>
(for X (stack) (co (car X)))
<
tankf33der>
!? (co 'T)
<
tankf33der>
Can't stop main routine
<
abu[7]>
Needs a check
<
abu[7]>
(for X ... (unless (=T ..
seninha has joined #picolisp
seninha has quit [Remote host closed the connection]
seninha has joined #picolisp
avocadoist has joined #picolisp
pablo_escoberg has quit [Quit: Client closed]
<
tankf33der>
super slow variation
<
abu[7]>
yes, (stack) takes very long, it builds a list each time
<
tankf33der>
reimplementing
<
abu[7]>
Better (shuffle (stack))
<
abu[7]>
Looks good
<
abu[7]>
Why do you use pastebin and not pb1n?
<
tankf33der>
tor is broken from work, i must pass firewalls-proxy
<
tankf33der>
something happened after full upgrade
isaneran has quit [Ping timeout: 240 seconds]
avocadoist has quit [Read error: Connection reset by peer]
avocadoist has joined #picolisp
<
abu[7]>
tankf33der: Not time critical here, but generally (head (dec (length L)) L) is not very good, because 'head' copies the list
<
abu[7]>
(non-destructive)
<
abu[7]>
Better is (cdr (rot L))
<
abu[7]>
(destructive, but OK here because (stack) builds a fresh list)
rob_w has quit [Quit: Leaving]
pablo_escoberg has joined #picolisp
pablo_escoberg has quit [Quit: Client closed]
msavoritias has quit [Ping timeout: 268 seconds]
seninha has quit [Ping timeout: 240 seconds]
seninha has joined #picolisp
avocadoist has quit [Read error: Connection reset by peer]
beneroth has quit [Read error: Connection reset by peer]
avocadoist has joined #picolisp
avocadoist has quit [Remote host closed the connection]
avocadoist has joined #picolisp