05:00 <aw-> abu[7]: tankf33der just saying hi, I hope you guys are doing good.

06:18 <abu[7]> Hi aw-! Yes, thanks, all green here ;) I hope the same for you!

06:49 <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

06:56 <tankf33der> Morning

06:57 <tankf33der> it exit himself, i can not type co or bt

06:57 <tankf33der> itself

06:57 <abu[7]> You must start the tests in the REPL

06:57 <abu[7]> Then you get an error break

06:57 <tankf33der> doing

06:58 <abu[7]> I would always work in the reple

06:58 <abu[7]> repl

06:58 <abu[7]> That's one big advantage of Lisp

06:59 <abu[7]> Just omit the (bye) at the end while debugging

06:59 <abu[7]> (I know you know, just for the records)

07:00 <tankf33der> did not helped

07:00 <tankf33der> i started in repl and it exits to bash

07:01 <tankf33der> i just do it to prove or check pil is ok

07:01 <tankf33der> pil21

07:01 <abu[7]> I always get a normal error break in stack overflow

07:01 <tankf33der> i started repl as pil +

07:02 <abu[7]> yeah

07:06 <tankf33der> i have correct stack call so this is not big deal.

07:06 <tankf33der> thanks.

07:06 <tankf33der> stack increase call

07:07 <tankf33der> ed25519 is great bigint test

07:07 <abu[7]> http://pb1n.de/?68506e

07:07 <tankf33der> yeah

07:08 <abu[7]> I ĉäñ ínteract at the "?" prompt

07:08 <abu[7]> when I leave the repl with enter, it exits with "No stack"

07:08 <tankf33der> i do not see such a behaviour

07:09 <abu[7]> Strange

07:10 <abu[7]> It does immediately say "No stack"? No REPL?

07:10 <tankf33der> no stack and bash

07:10 <tankf33der> or new info:

07:10 <tankf33der> ohm new info:

07:10 <tankf33der> oh, new info:

07:11 <tankf33der> if i disable coroutines i got repl!

07:12 <tankf33der> and i see my recursion in (bt)

07:12 <tankf33der> :)

07:12 <tankf33der> repl exits in Ctrl-D

07:12 <abu[7]> Hmm. Without coroutines the main segment is much bigger, perhaps some borderline situation

07:13 <abu[7]> But in the sources I see that "No stack" is only issued in err()

07:14 <tankf33der> i do not stop co's in tests

07:14 <abu[7]> err() also exits immediately if there is no TTY at stdout

07:15 <abu[7]> Not stopping co's is all right

07:16 <tankf33der> good :)

07:19 <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

07:23 <tankf33der> i can create cut file to repeat and can get it if clone a git repo

07:24 <tankf33der> you can get it

07:24 <abu[7]> Thanks, not necessary I think

07:24 <tankf33der> ok

07:24 <tankf33der> issue closed then, thanks.

07:24 <abu[7]> I think there is no perfect way to handle stack errors

07:24 <abu[7]> yeah

07:25 <abu[7]> I mean, perhaps there *is* a perfcct way, but at high runtime costs

07:26 <abu[7]> I did some trade-offs with runtime stack checks

07:26 <abu[7]> For practical purposes, this is ok

07:27 <abu[7]> If operating at the limits of the stack, we will get an error, exit, and just set the limits higher ;)

07:28 <tankf33der> ok

08:31 <abu[7]> I just notice that the reference for 'stack' is a bit wrong

18:48 <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?

22:01 <abu[7]> The relations are inherited

22:02 <abu[7]> (class +A +Entity) (rel ...

22:03 <abu[7]> (class +B +A)

22:03 <abu[7]> then +B inherits all relations and methods from +A

22:03 <abu[7]> afp

22:23 <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.