ChanServ changed the topic of #picolisp to: PicoLisp language | Channel Log: https://irclog.whitequark.org/picolisp/ | Check also http://www.picolisp.com for more information
ym has quit [Remote host closed the connection]
orivej has quit [Ping timeout: 258 seconds]
Blukunfando has quit [Ping timeout: 265 seconds]
karswell has joined #picolisp
_whitelogger has joined #picolisp
beneroth has quit [Remote host closed the connection]
beneroth has joined #picolisp
orivej has joined #picolisp
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #picolisp
patrixl has joined #picolisp
patrixl has left #picolisp [#picolisp]
<tankf33der> first loop didnt finoshed in 20h. i will decrease cpu and processess and will start again
<Regenaxer> Yeah, gc+ takes forever ;)
<Regenaxer> I will go down, analyze IPC code and check individual components manually
<tankf33der> 1 cpu and 4 children
rob_w has joined #picolisp
orivej has quit [Ping timeout: 260 seconds]
Blukunfando has joined #picolisp
mtsd has joined #picolisp
dTal has quit [K-Lined]
dTal has joined #picolisp
<Regenaxer> I analyzed the corefiles more
<tankf33der> ok
<Regenaxer> It always crashes *after* gc
<Regenaxer> the avail list is damaged
<Regenaxer> so it may be gc *itself*
<Regenaxer> This would explain why gc+ finds nothing
<Regenaxer> It could be gc modifying the external namespace
<Regenaxer> this does noy occur in our other "normal" tests
<Regenaxer> so if that part were faulty, it would explain it
<Regenaxer> unfortunately this part is complicated
<tankf33der> eh
<Regenaxer> The big loop after # Externals
<Regenaxer> Non-recursive tree traversal
<Regenaxer> 2 times such a loop in fact, one marking and one cleaning up
mtsd has quit [Quit: Leaving]
mtsd has joined #picolisp
Blukunfando has quit [Remote host closed the connection]
Blukunfando has joined #picolisp
<tankf33der> reading gc.l
mtsd has quit [Quit: Leaving]
beneroth_ has joined #picolisp
beneroth has quit [Ping timeout: 272 seconds]
<Regenaxer> hmm, doesn't seem wrong
<Regenaxer> And this part of gc works usually, only not in this context
<Regenaxer> and very heisen
<tankf33der> 1
<tankf33der> 2
<tankf33der> ?
<tankf33der> !? (cdr (root Tree))
<tankf33der> key -- List expected
<tankf33der> got such error when switch to 2 cpus and 32 child
orivej has joined #picolisp
<Regenaxer> Yeah, data are all garbled
<Regenaxer> really tuff
beneroth__ has joined #picolisp
beneroth_ has quit [Ping timeout: 246 seconds]
<Regenaxer> All this happens a long time after the original error occurred
orivej has quit [Ping timeout: 246 seconds]
beneroth__ has quit [Quit: Leaving]
beneroth has joined #picolisp
<beneroth> Regenaxer, sounds like there might now way around extensive dumping and checking of memory state? :-/
<beneroth> or maybe a profiler could be written (similiar to valgrind or such), adapted to picolisp, checking all the stuff
<beneroth> but I guess an existing standard tool cannot be used as the problem is with the picolisp-specific memory structures, aye?
<Regenaxer> Right
<Regenaxer> I trace backward now
<Regenaxer> I know the avail pointer is damaged
<Regenaxer> trying to find the place where that happens
<Regenaxer> *very* hard to reproduce
<Regenaxer> needs many parallel processes
<Regenaxer> I print to stderr when that condition arises in one of the 90 processes
<Regenaxer> Just got it again, the process did not even crash
<Regenaxer> All this take a lot of time. Have to run it several times until it happens by chance
<beneroth> yeah, very annoying work :/
<tankf33der> i am running new code under gc+ which run only once many monthes ago and it passed.
rob_w has quit [Quit: Leaving]
<Regenaxer> good idea
orivej has joined #picolisp
<Regenaxer> ok, it is *before* 'gc'
<beneroth> so during writing of memory, not allocation/gc'ing ?
<beneroth> interesting
<Regenaxer> No idea
<Regenaxer> The global Avail pointer should not be touched by anybody
<Regenaxer> I try to reproduce again
<beneroth> I'm certain you will find it faster then you expect
<beneroth> no worries
<Regenaxer> Will take time
<tankf33der> i found libedit could replace readline. will take a play with.
<Regenaxer> Never heard of
<Regenaxer> Does it also use .inputrc ?
<tankf33der> maybe. adelie linux have only libedit in base and all software links against it. will take a look.
<Regenaxer> makes senes
<Regenaxer> What is the advantage?
<tankf33der> just reimplementation.
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #picolisp
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #picolisp
beneroth_ has joined #picolisp
beneroth has quit [Ping timeout: 265 seconds]
casaca has quit [Ping timeout: 246 seconds]