<abu[7]>
I did not expect that anyone takes a look at it ;)
<abu[7]>
Especially as I won't release it to PlayStore probably
<tankf33der>
now i about openbsd issue this:
<tankf33der>
now i think about openbsd issue this:
<tankf33der>
listen expecting traffic over ipv6, traffic is ipv4
<tankf33der>
thinking how to prove
<tankf33der>
yes, proved!
<abu[7]>
ok
<tankf33der>
urah!
<tankf33der>
A weight off my shoulders.
<abu[7]>
What does this insight help?
<tankf33der>
this explains why (udp 3) do not receive '(a b c)
<abu[7]>
Yes
<abu[7]>
But what to do that it *does* receive '(a b c) ?
<tankf33der>
two variants
<tankf33der>
1. (port ...) must bind to ipv4
<tankf33der>
or
<tankf33der>
2. (udp ...) sends over ipv6
<abu[7]>
How?
<tankf33der>
good question
<abu[7]>
The pil network stack is hybrid
<abu[7]>
transparent
<tankf33der>
but openbsd stack is not
<tankf33der>
how i understands this now
<abu[7]>
I see
<beneroth>
I would like picolisp network functions to take additional parameters or global variables where this could be specified
<beneroth>
I also have use cases with servers with multiple IPs where a program/listen must only bind to a specific IP and not all IP's
<abu[7]>
Yeah, aw- also asked for this a few years ago
<beneroth>
yeah. the current way it works is very easy to use for simple cases, but practically unusable for more complex setups
<abu[7]>
A different issue than the IPv4 problem above
<beneroth>
there are good use cases for more complex setups
<beneroth>
T
<beneroth>
different, but related. if you decide that we solve this, than both topics could ideally be solved the same way
<beneroth>
ofc today with virtualization, especially Linux Containers, picolisp app can always be put in its own virtual container with a naive standard network interface and the more complex network setup than handled on the host. But would be nice to be able to do such things with pil directly, too
<abu[7]>
I don't know how to do it, but we could add optional args to e.g. 'listen' and 'connct' etc.
<beneroth>
yeah something like this.
<beneroth>
the default use should remain the current one, perfect for simple setups.
<abu[7]>
T
<abu[7]>
'udp' has already varargs, so a global might be better
<beneroth>
picolisp being relatively lightweight (short of custom implementation) would be quite usable for manage interfaces / scripting on routers/firewall/small network devices, I think
<beneroth>
there was a picolisp implementation running on OpenWRT. I never had a deeper look at it, but i wonder how that handled it. I guess it was pil32 and not even pil64.
<beneroth>
looks like it makes nothing with picolisp, just a makefile to install it on openwrt
<beneroth>
also, picolisp is listed in the "Available, but likely won't be updated" category
<beneroth>
abu[7], I also don't know much about unix/bsd sockets. I only know that there are many configuration options, which might be actually handy when doing video streaming or lower level networking stuff.
<abu[7]>
T, me too
<abu[7]>
(don't know)
<beneroth>
I don't expect you to do this all yourself, if you don't feel like it. Maybe we could do it altogether, surely aw- and tankf33der would help. Maybe Henrik too.
<abu[7]>
Perhaps more versions? @lib/netIPv4.l etcc?
<beneroth>
oh, that also sounds like a good idea!
<abu[7]>
net.l is quite short
<beneroth>
yeah, that might be much better than one overloaded complex version.
<abu[7]>
t
<abu[7]>
T
<beneroth>
T. better way for the custom needs.
<beneroth>
question is then, if OpenBSD could be handled somehow easily in the default net.l or if it just requires this more specific setup
<aw->
hi
<beneroth>
hey, I hope I haven't disturbed you with poking you :)
<aw->
what do you need?
<beneroth>
abu[7], @lib/net.l is really short. Is it right, that basically all networking is in there? nothing in the LLVM code?
<abu[7]>
Hi aw-!
<aw->
hi abu[7] and beneroth
<aw->
sorry i wasnt paying attention to the conversation
<beneroth>
I fill you in
<abu[7]>
Yep, only net.l
<beneroth>
aw-, two topics: 1) pil network stack has some issues on OpenBSD, because pil network handles everything hybrid, running as IPv6 with IPv4 support/fallback. Unlike Linux, OpenBSD separates them completely.
<abu[7]>
Starting to rain, and I'm in the fields. Must hurry
<beneroth>
abu[7], get home well!
<beneroth>
ignore chat :)
<beneroth>
aw-, 2) the older topic, from you and me and maybe others, that more low-level control over networking in pil would be desirable for some use cases
<abu[7]>
:)
<beneroth>
aw-, do you have advanced knowledge about unix/bsd sockets? because abu[7] and me don't really have that, unfortunately.
<beneroth>
good to know: all picolisp networking is implemented on lisp level as C FFI in @lib/net.l - nothing on the picolisp implementation level (LLVM etc.).
<beneroth>
so the solution for custom networking would obviously be separate versions of @lib/net.l
<beneroth>
question is, if the OpenBSD issue could be solved in the standard version or if a @lib/net.l specifically for OpenBSD is needed.
<abu[7]>
Now under a bridge ☺
<beneroth>
we have clouds but no rain at the moment
<beneroth>
you got floodings in Bavaria, right?
<abu[7]>
net.l did never change except pil32:net.c -> pil64:net.l -> pil21:net.l
<abu[7]>
yes
<abu[7]>
2 km from here
<beneroth>
CSU should pay personally for it, they reduced all the construction work etc. to prevent that, I've read.
<abu[7]>
So maintaining specific versions should be no trouble
<beneroth>
yeah
<beneroth>
sounds rather easy, tbh
<beneroth>
it just needs knowledge about the low level C interface of sockets ^^'
<abu[7]>
T, and are against climate prevention
<abu[7]>
Yep
<abu[7]>
Rain stopped, I go home
<beneroth>
I think German car industry is doomed, doesn't matter how much protectionism is applied. Their way of working (with many small vendors) just cannot compete even with Tesla, and even Tesla is not as good as the Chinese car industry.
<beneroth>
abu[7], ok :)
<abu[7]>
True
<beneroth>
too bad German politics killed German solar industry 10y ago. So Germany will likely stay world-leader in machinery but otherwise no big horses anymore.
<beneroth>
in IT, only SAP and Software-Lab are worth mentioning ;-)
<abu[7]>
Haha ☺
<aw->
beneroth: thanks for the info
<aw->
OK so i worked a lot with unix C networking/sockets, but that was like ~8~15 years ago haha
<aw->
i haven't touched that stuff in so long
<aw->
however what I can say is it's not easy haha
<abu[7]>
net.l is just a translation of pil32's net.c, and that was probably from books