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>
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 ok
<
abu[7]>
It is s390x?
<
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]>
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]>
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]>
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
<
tankf33der>
Look what i get on s390x :)
<
tankf33der>
and coredump in the end
<
abu[7]>
Yeah, seems an infinite recursion
<
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]