beneroth changed the topic of #picolisp to: PicoLisp language | The scalpel of software development | Channel Log: | Check for more information
theruran has quit [Quit: Connection closed for inactivity]
rob_w has joined #picolisp
<tankf33der> hi all
<tankf33der> keep have fun with co
<tankf33der> abu[7]: is it a problem ?
<tankf33der> : (stack)
<tankf33der> -> ((T . 63) (T . 250) . 64)
<tankf33der> double T
<abu[7]> Yes, this is a bug
<abu[7]> How did you manage?
<abu[7]> So easy. I thought it is checked (reentrant)
<tankf33der> yea
<abu[7]> I will investigate a little later
<tankf33der> np
<abu[7]> Ah, I know already, If this is the *first* co call, T is not running yet
<abu[7]> I'll fix the check
<abu[7]> released
<abu[7]> Tharks tankf33der!
<tankf33der> testing
<tankf33der> seems ok
<abu[7]> Great!
<abu[7]> I just moved the T check to the front
<abu[7]> Hmm, wait,
<abu[7]> oops
<abu[7]> No, OK
taleon has quit [Remote host closed the connection]
taleon has joined #picolisp
<tankf33der> new crash
<tankf33der> is this illegal? :/
<tankf33der> abu[7]: away in 30min
<abu[7]> OK. Not suse. At least it is difficult to handle
<abu[7]> Starting a co in the error handler of a co
<abu[7]> We are in a limited stack segment here
<abu[7]> I'm not sure what exactly goes wrong
<tankf33der> ok
<abu[7]> The error should be handled in main, but then its state is gone
<abu[7]> Perhaps this can be improved on the error handling side (?)
<tankf33der> i do not know
<abu[7]> Tbe old crashed co is not yet cleaned up, and a new one is started
<abu[7]> Tough :)
<taleon> Core dump also under OpenBSD.
<tankf33der> sure
<tankf33der> this is core issue
<abu[7]> Everywhere
<taleon> ah ok
<abu[7]> Probably the pil error handler in repeatedly crashed coroutines
<abu[7]> error in error handling is a co segment
<abu[7]> I can't reproduce in a simpler setup
<tankf33der> yea
<abu[7]> Maybe it is not even co-related
<abu[7]> (let (* 3 4)
<tankf33der> :)
<abu[7]> Now '*' is 3
<abu[7]> As long as in this error handler
<abu[7]> So calling anything which multiplies is guaranteed to crash
<abu[7]> Which is correct behavior
<abu[7]> And this (co 'b (let N (* 3 4))) does it!!
<abu[7]> So it is explained!
<abu[7]> Everything OK
<tankf33der> ok
<abu[7]> : (let (* 3) (* 3 4))
<abu[7]> Segmentation fault
<abu[7]> ☺
<tankf33der> afk
<abu[7]> cu
payphone has quit [Remote host closed the connection]
cpli has quit [Remote host closed the connection]
payphone has joined #picolisp
cpli has joined #picolisp
rob_w has quit [Remote host closed the connection]
msavoritias has joined #picolisp
msavoritias has quit [Ping timeout: 255 seconds]
msavoritias has joined #picolisp
bjorkintosh has quit [Remote host closed the connection]
bjorkintosh has joined #picolisp
bjorkintosh has joined #picolisp
<tankf33der> Since I can't find bugs in a proper way, I am doing illegal things with coroutines.
<tankf33der> cannot resist.
<abu[7]> This is very good
<abu[7]> Finds also bugs
<tankf33der> pasting
<tankf33der> cannot paste text now
<tankf33der> lets try picture
<tankf33der> eats 100% CPU on (gc)
<abu[7]> I'll try
fuxoft_mobile has quit [Quit: Connection closed for inactivity]
<abu[7]> Behaves ok here
<tankf33der> ~99% reoeatable
<tankf33der> latest ever pil21
<abu[7]> Hmm, not here on Termux
<abu[7]> I try Debian
msavoritias has quit [Ping timeout: 255 seconds]
<abu[7]> Indeed! Hangs :)
<tankf33der> ok
<abu[7]> Can be shorter
<abu[7]> Just a co error and then (gc) (stack)
<tankf33der> first versions were 20 lines
<abu[7]> Strange, only if (gc) (stack) is on the snme line
<tankf33der> entered line collected on first gc call
<abu[7]> (gc) T
<abu[7]> same
<tankf33der> i have got bt from gdb
<tankf33der> very short
<abu[7]> Can you show?
<abu[7]> OK, this does not help
<tankf33der> yea
<abu[7]> Killed in some infinite loop
<abu[7]> The strange thing is that it chokes on text on the command line
<abu[7]> : (gc) #
<abu[7]> also hangs
<abu[7]> An error is not needed
<abu[7]> (co 'a (co 'b 7))
<abu[7]> (gc) #
<abu[7]> Or just:
<abu[7]> : (+ 3 4)
<abu[7]> -> 7
<abu[7]> : (gc) #
<abu[7]> Hangs too
<abu[7]> Nooo
<abu[7]> I'm wrong :)
<abu[7]> It is just the reader *waiting*
<abu[7]> because of the comment ☺
<tankf33der> :)
<abu[7]> So it needs a co error
<abu[7]> I suspect a bug in llvm~repl
<abu[7]> and/or llvm~stdEval
<abu[7]> Hmm
<abu[7]> looks all good
<abu[7]> It it a Heisenbug. Can't reproduce on Termux
<tankf33der> eh
<abu[7]> It is not the error handler: (catch '("") (co 'a (co T)))
<abu[7]> same
<abu[7]> Ui, even worse:
<abu[7]> : (catch '("") (co 'a (co T)))
<abu[7]> -> "Reentrant coroutine"
<abu[7]> : (gc)
<abu[7]> Segmentation fault
<tankf33der> good night. afk.
<abu[7]> Me too O/