beneroth changed the topic of #picolisp to: PicoLisp language | The scalpel of software development | Channel Log: | Check for more information
msavoritias has joined #picolisp
rob_w has joined #picolisp
<tankf33der> morning
<tankf33der> my question is pil ok.
<tankf33der> there is (stack) output after error.
<taleon> Is `stack-guard` possibly active?
<tankf33der> Mmmmm
<tankf33der> could be, unknown
<tankf33der> pil21 is llvm-clang based, no gcc
<taleon> I assumed that it is similar with LLVM, because the stack of the S/390 grows downwards.
<taleon> But I honestly don't know much about it.
<tankf33der> Me too
<abu[7]> The "main" coroutine is out of stack: (T . 0) .
<abu[7]> Zero bytes left
<abu[7]> So better increase the default size of 256KiB
<abu[7]> taleon: This stack issue is not releated to the hardware stack
<abu[7]> Pil maintains stack segments for coroutines *inside* the hardware stack
<abu[7]> Without coroutines, Pil uses the whole hardware stack, as limited by "ulimit -s"
<abu[7]> But as soon as coroutine(s) start, the stack is segmented according to the (stack) arguments.
<taleon> I understand
<tankf33der> abu[7]: what is correct stack call in first line in co.l ?
<abu[7]> Fore example (stack 256 4096)
<abu[7]> or perhaps a little less
<tankf33der> the same error
<abu[7]> you can use 256 4096 and then look after execution with (stack) how much is unused
<tankf33der> the same digits as in link above
<abu[7]> Then ther must be something going wrong and it goes into an infinite recursion?
<abu[7]> Same digits? But no longer 64 right?
<tankf33der> the same.
<abu[7]> Can you paste the output of (stack) here?
<abu[7]> Still 256, so you called it when there was already a coroutine running
<abu[7]> "if at least one argument and no coroutine running"
<tankf33der> stack call is first line in a file
<abu[7]> Not just file, but whole program?
<abu[7]> Segment size can only be changed before a coroutine is started
<abu[7]> hmm, right
<abu[7]> ((a . 254) (T . 0) . 256)
<abu[7]> so co size is 256 and main dropped to zero
<abu[7]> So there is really something using up all stack
<abu[7]> co.l is all right
<abu[7]> Must be something else
<abu[7]> Do other co tests run ok?
<tankf33der> seems
<tankf33der> seems ok
<abu[7]> It is s390x?
<tankf33der> yeap
<abu[7]> A Sparc CPU?
<tankf33der> s390x under qemu
<abu[7]> Hard to diagnose
<tankf33der> let me know when you have energy to dig in to be sure pil is ok
<abu[7]> Thanks
<abu[7]> You tested several co programs?
<abu[7]> The question is what is special with this one?
<tankf33der> now i believe any co programs fails, i can not find work one
<tankf33der> rest pil tests passed.
<tankf33der> do you have a trivial co program ?
<abu[7]> I always use on the repl:
<abu[7]> : (co 'a (let N 0 (loop (yield (inc 'N)))))
<abu[7]> looks good
<abu[7]> What if you then start a second one (co 'b (let ...
<abu[7]> And then call both randomly in the reple
<abu[7]> repl
<abu[7]> Is this because of the 'ht' error, or because of 2 coroutines?
<tankf33der> because of second
<abu[7]> also without calling ht:Pack?
<tankf33der> the same
<abu[7]> I see, then it is indeed the stack
<abu[7]> Does it grow downwards?
<abu[7]> taleon said "because the stack of the S/390 grows downwards"
<abu[7]> Downwards is needed in Pil
<tankf33der> downwards.
<abu[7]> good
<abu[7]> Something messes up the stack segments
<tankf33der> away in 30mins.
<abu[7]> It is really hard to debug
<tankf33der> i understand
<abu[7]> What may be different in the sparc architecture?
<tankf33der> file says co issue
<abu[7]> (co 'a (* 3 4))
<abu[7]> even such a simple one
<abu[7]> So this is SPARC, Solaris 11.4
<abu[7]> not s390x?
<tankf33der> Sparc solaris
<abu[7]> ok
<tankf33der> Look what i get on s390x :)
<tankf33der> and coredump in the end
<abu[7]> Yeah, seems an infinite recursion
<abu[7]> u
<abu[7]> Needs debugging on the machine level
<abu[7]> Let's postpone for now
<tankf33der> good. see you.
<abu[7]> Thanks anyway! ☺
seninha has joined #picolisp
rob_w has quit [Remote host closed the connection]
bjorkintosh has quit [Quit: Leaving]
bjorkintosh has joined #picolisp
ello has quit [Read error: Connection reset by peer]
ello has joined #picolisp
msavoritias has quit [Ping timeout: 255 seconds]