beneroth has quit [Read error: Connection reset by peer]
beneroth has joined #picolisp
msavoritias has joined #picolisp
rob_w has joined #picolisp
stultulo has joined #picolisp
f8l has quit [Ping timeout: 268 seconds]
<
abu[7]>
tankf33der here?
oldf8l has joined #picolisp
<
abu[7]>
I think I know what the problem with your test yesterday is
<
abu[7]>
It is if 'co' is called in an reentrant way
<
tankf33der>
i think the same
<
abu[7]>
Happens also with (co 'a (co 'b (co 'a T)))
stultulo has quit [Ping timeout: 246 seconds]
<
abu[7]>
Old pil disallowed reertrancy
<
abu[7]>
I thought, in pil21 it is OK
<
abu[7]>
And it
*is* OK for 'yield' I think
<
abu[7]>
But not for 'co'
<
abu[7]>
Does it break your tests if I disallow reentrant 'co' calls?
<
tankf33der>
i do not think so
<
abu[7]>
The error "Can't stop itself" which I introduced yesterday will be removed
<
tankf33der>
this is something new
<
abu[7]>
New error "Reentrant coroutine"
<
abu[7]>
Good, let's try
<
tankf33der>
yesterday all tests were passed
<
abu[7]>
I make a release
<
tankf33der>
testing
<
abu[7]>
My tests passed so far, but they are not as general as yours
<
tankf33der>
all passed.
<
abu[7]>
Wow, cool! 😎
<
abu[7]>
You are the master of finding co bugs :)
<
tankf33der>
Now I feel more mindful when playing with coroutines.
<
tankf33der>
see, sometimes test failed on freebsd
<
tankf33der>
Freebsd14.1
<
abu[7]>
And sometimes it does not fail?
<
tankf33der>
yes, what log says
<
abu[7]>
A timing issue?
<
tankf33der>
this is test from your bundle
<
tankf33der>
this one
<
abu[7]>
Looks like a race condition
<
tankf33der>
where ?
<
abu[7]>
Hmm, should not. It waits in (until (connect "
<
abu[7]>
Only Freebsd?
<
abu[7]>
No idea :(
<
tankf33der>
where is issue ?
<
abu[7]>
We have (out @ (pr '(a b c))) and then (bye)
<
abu[7]>
Can it be that the socket it closed too early?
<
abu[7]>
What if you insert (wait 200) before (bye) ?
<
tankf33der>
the same, but less often
<
abu[7]>
200 is quite long
<
abu[7]>
What if wait before the (out ... ?
<
abu[7]>
but this really should not matter
<
tankf33der>
fail always
<
abu[7]>
And a longer wait?
<
tankf33der>
always
<
tankf33der>
like this, right ?
<
tankf33der>
fails always
<
abu[7]>
And 2000 before (bye)?
<
tankf33der>
very less ofter
<
tankf33der>
very less often
<
abu[7]>
OK, but this cannot be the real reason
<
tankf33der>
away in 30min
<
abu[7]>
What if you remove (close P) after (fork)?
<
tankf33der>
less often
<
abu[7]>
(close P) is not really needed
<
abu[7]>
Must go too
<
tankf33der>
look at this
<
tankf33der>
can not repeat now
<
abu[7]>
Only (close P) removed?
<
abu[7]>
(println -> (test also ok?
<
abu[7]>
Hmm, and the two 'wait's are needed?
oldf8l is now known as f8l
<
tankf33der>
only (wait 80) needed
<
tankf33der>
works so far
<
abu[7]>
Why should it be necessary?
<
tankf33der>
even (wait 10) enough
<
abu[7]>
It looks wrong to me. We are messing around just with the symptoms :(
<
tankf33der>
indeed
<
tankf33der>
running code in loop, lets wait for a while
<
tankf33der>
code works, stopped
<
tankf33der>
but we should debug an issue
<
abu[7]>
it is strange
<
tankf33der>
i will be away after 45mins
<
abu[7]>
Let's wait with the release of net.l - perhaps somebody here hat an idea?
<
abu[7]>
This fix cannot be right :(
<
tankf33der>
let me try to run on freebsd13
<
tankf33der>
let me try to run on freebsd13.3
<
tankf33der>
the same issue
<
abu[7]>
What is '*OS' in those cases?
<
tankf33der>
-> "FreeBSD"
<
abu[7]>
I add it conditonally
<
tankf33der>
away in 15mins
<
tankf33der>
the same workaround around issue
<
abu[7]>
Which issue?
<
tankf33der>
why no data at some point on freebsd
<
tankf33der>
let me try (wait 1)
<
abu[7]>
Yeah, only force a context switch
<
tankf33der>
(wait 1) - so far
<
tankf33der>
i must run
msavoritias has quit [Ping timeout: 260 seconds]
<
tankf33der>
At what syscall pil "fails"?
<
abu[7]>
That's the question
<
tankf33der>
strace will help
<
abu[7]>
Or why the data are not there when 'listen' returns
<
abu[7]>
Not sure if strace helps
<
abu[7]>
It is two processes plus kernel
<
tankf33der>
dtrace?
<
abu[7]>
Never used
<
tankf33der>
Ported to freebsd a long ago
<
tankf33der>
from solaris
<
tankf33der>
C code would "fail" too?
<
abu[7]>
I think so, if it uses the same system calls
<
tankf33der>
We can debug to find that place
<
abu[7]>
Can you try?
<
tankf33der>
Of course no, without you
msavoritias has joined #picolisp
rob_w has quit [Remote host closed the connection]
<
tankf33der>
I wish this is not pil problem
<
abu[7]>
Yes, I hope so too
<
tankf33der>
So, ball on your side, let me know when you will be ready
<
abu[7]>
Oh, how? I have no FreeBSD
<
abu[7]>
I can help to interprete the output perhaps
<
tankf33der>
We can do it as always before, you send patch for debug output i will return result(s).
<
tankf33der>
It worked.
<
abu[7]>
I thought you run it with dtrace
<
abu[7]>
To see where it gets lost
<
tankf33der>
Doing truss first
<
tankf33der>
dtrace huge ecosystem, no way
<
abu[7]>
What is truss?
<
tankf33der>
bsd's strace
<
abu[7]>
Hmm, perhaps it is a problem if both processes use the same 'P' file desc?
<
tankf33der>
not repeatable under truss
<
abu[7]>
Hmm, heisenbug
<
abu[7]>
Forget what I said about the same 'P'
<
abu[7]>
I think it is correct
<
tankf33der>
maybe because i run it under pil
<
tankf33der>
maybe raw picolisp required
<
abu[7]>
What makes it a difference?
<
tankf33der>
unknown so far
<
abu[7]>
You need @lib/net.l anyway
<
abu[7]>
Does it work under pil64 ?
<
tankf33der>
truss has its own context switched and bug is gone
<
tankf33der>
now i run under raw picolisp
<
abu[7]>
Plus @lib/net.l ?
<
tankf33der>
and sysdefs
<
abu[7]>
Other BSDs work?
<
tankf33der>
raw didnt helped
<
abu[7]>
Thought so
<
abu[7]>
must be port, listen or connect
<
tankf33der>
not repeatable on pil32
<
tankf33der>
not repeatable on pil64
<
abu[7]>
Interesting
<
abu[7]>
So @lib/net.l is bad?
<
tankf33der>
not ported?
<
abu[7]>
pil64 it was Asm
<
tankf33der>
i know :)
<
abu[7]>
I translated to PilSrc and native calls
<
abu[7]>
Are all constants is sysdefs correct?
<
tankf33der>
all fields have a value
<
tankf33der>
very different from linux
<
abu[7]>
In pil32 in src/net.c
<
abu[7]>
there are some conditionals
<
abu[7]>
#ifndef
__linux__
<
abu[7]>
or
__OpenBSD__
<
abu[7]>
Same in pil64
<
abu[7]>
~(as (<> *OS "OpenBSD")
<
abu[7]>
Same in @lib/net.l
<
abu[7]>
~(as (<> *OS "OpenBSD")
<
tankf33der>
replaced to freebsd didnt helped :)
<
abu[7]>
## (%@ "fcntlSetFl" 'I Sd2 0) # Non-Linux?
<
abu[7]>
in @lib/net.l
<
abu[7]>
What if you uncomment?
<
tankf33der>
helped
<
tankf33der>
bundle test failed
<
abu[7]>
So I change as conditional for FreeBSD?
<
abu[7]>
bundle test?
<
tankf33der>
pil21's bundled tests
<
tankf33der>
running again
<
tankf33der>
root@freebsd ~]# pil @lib/test.l +
<
tankf33der>
("SigVal")
<
tankf33der>
[/root/pil21/test/src/main.l:19] (a b c) -- 'test' failed
<
tankf33der>
now all ok
<
tankf33der>
two times
<
abu[7]>
I make a release
<
tankf33der>
error was on the same networking code
<
abu[7]>
So if I uncomment for FreeBSD all should be fine?
<
tankf33der>
now, i believe yes
<
abu[7]>
let me release
<
abu[7]>
It was good that you tested pil32!
<
abu[7]>
So we got the idea ☺
<
tankf33der>
(%@ "fcntlSetFl" 'I Sd2 0)
<
tankf33der>
0 says - clear all prev. flags
<
tankf33der>
right ?
<
abu[7]>
I don't remember
<
abu[7]>
decades ago ☺
<
tankf33der>
chatgpt says so
<
tankf33der>
afk in 20mins
<
abu[7]>
Thanks for all!
msavoritias has quit [Ping timeout: 264 seconds]
<
tankf33der>
networking fails on openbsd
<
tankf33der>
will check
<
tankf33der>
today's fix
<
tankf33der>
will take some time
<
abu[7]>
Today's change is relevant orly for FreeBSD
<
abu[7]>
Off for today
<
tankf33der>
see you
lagash has quit [Remote host closed the connection]
lagash has joined #picolisp
beneroth has quit [Quit: Leaving]