beneroth changed the topic of #picolisp to: PicoLisp language | The scalpel of software development | Channel Log: | Check for more information
theruran has joined #picolisp
msavoritias has joined #picolisp
lagash has quit [Remote host closed the connection]
lagash has joined #picolisp
<aw-> abu[7]: tankf33der just saying hi, I hope you guys are doing good.
<abu[7]> Hi aw-! Yes, thanks, all green here ;) I hope the same for you!
<abu[7]> tankf33der, "i do not have such code": You can find out *where* an error occurred if you backtrace with (bt) in the error repl
<tankf33der> Morning
<tankf33der> it exit himself, i can not type co or bt
<tankf33der> itself
<abu[7]> You must start the tests in the REPL
<abu[7]> Then you get an error break
<tankf33der> doing
<abu[7]> I would always work in the reple
<abu[7]> repl
<abu[7]> That's one big advantage of Lisp
<abu[7]> Just omit the (bye) at the end while debugging
<abu[7]> (I know you know, just for the records)
<tankf33der> did not helped
<tankf33der> i started in repl and it exits to bash
<tankf33der> i just do it to prove or check pil is ok
<tankf33der> pil21
<abu[7]> I always get a normal error break in stack overflow
<tankf33der> i started repl as pil +
<abu[7]> yeah
<tankf33der> i have correct stack call so this is not big deal.
<tankf33der> thanks.
<tankf33der> stack increase call
<tankf33der> ed25519 is great bigint test
<tankf33der> yeah
<abu[7]> I ĉäñ ínteract at the "?" prompt
<abu[7]> when I leave the repl with enter, it exits with "No stack"
<tankf33der> i do not see such a behaviour
<abu[7]> Strange
<abu[7]> It does immediately say "No stack"? No REPL?
<tankf33der> no stack and bash
<tankf33der> or new info:
<tankf33der> ohm new info:
<tankf33der> oh, new info:
<tankf33der> if i disable coroutines i got repl!
<tankf33der> and i see my recursion in (bt)
<tankf33der> :)
<tankf33der> repl exits in Ctrl-D
<abu[7]> Hmm. Without coroutines the main segment is much bigger, perhaps some borderline situation
<abu[7]> But in the sources I see that "No stack" is only issued in err()
<tankf33der> i do not stop co's in tests
<abu[7]> err() also exits immediately if there is no TTY at stdout
<abu[7]> Not stopping co's is all right
<tankf33der> good :)
<abu[7]> Not sure exactly what happens ;) In any case, out-of-memory and out-of-stack errors are difficult to handle or predict, because of lack of resources
<tankf33der> i can create cut file to repeat and can get it if clone a git repo
<tankf33der> you can get it
<abu[7]> Thanks, not necessary I think
<tankf33der> ok
<tankf33der> issue closed then, thanks.
<abu[7]> I think there is no perfect way to handle stack errors
<abu[7]> yeah
<abu[7]> I mean, perhaps there *is* a perfcct way, but at high runtime costs
<abu[7]> I did some trade-offs with runtime stack checks
<abu[7]> For practical purposes, this is ok
<abu[7]> If operating at the limits of the stack, we will get an error, exit, and just set the limits higher ;)
<tankf33der> ok
<abu[7]> I just notice that the reference for 'stack' is a bit wrong
bjorkintosh has quit [Remote host closed the connection]
bjorkintosh has joined #picolisp
bjorkintosh has joined #picolisp
bjorkintosh has quit [Changing host]
seninha has joined #picolisp
seninha has quit [Remote host closed the connection]
seninha has joined #picolisp
seninha has quit [Remote host closed the connection]
seninha has joined #picolisp
pablo_escoberg has joined #picolisp
<pablo_escoberg> AFAIT, when an entity inherits from another entity, it does not inherit its relations.  Is that true or do I have a different bug?  If it is true, any way to make the inheriting entity inherit the relations?
msavoritias has quit [Remote host closed the connection]
seninha has quit [Ping timeout: 268 seconds]
seninha has joined #picolisp
seninha has quit [Read error: Connection reset by peer]
seninha has joined #picolisp
<abu[7]> The relations are inherited
<abu[7]> (class +A +Entity) (rel ...
<abu[7]> (class +B +A)
<abu[7]> then +B inherits all relations and methods from +A
<abu[7]> afp
<pablo_escoberg> Ah, ok.  Then I have a bug somewhere.  I'll figure it out, but just wanted to make sure it wasn't that way by design.