karswell has quit [Remote host closed the connection]
karswell has joined #picolisp
<aw->
i'm trying to figure out how to get the date from a unix timestamp, like "February 21, 2018" directly in pil.. i can do it with (call 'date "-d" "@1519203572")
<Regenaxer>
Hi aw-
<Regenaxer>
You can get the month with (index "February" *MonFmt)
<Regenaxer>
(if the locale is "en")
<aw->
what is *MonFmt ?
<aw->
it's documented?
<Regenaxer>
I don't remember
<Regenaxer>
It is part of the locale/date stuff in @lib/misc.l and @loc/??
<aw->
oh I see it
<aw->
*Mon and *Day exist as well
<aw->
and *DayFmt
<aw->
great!
<aw->
ok I think (datSym) is closest to what I want.. i can create a modified version to output differently
<aw->
thanks!
<Regenaxer>
yeah, just 'date' after parsing the numbers
orivej has quit [Ping timeout: 264 seconds]
orivej has joined #picolisp
mtsd has quit [Ping timeout: 260 seconds]
orivej has quit [Ping timeout: 256 seconds]
alexshendi has quit [Ping timeout: 256 seconds]
<tankf33der>
i've implement all crypto primitives for wireguard, look forward.
<Regenaxer>
Impressive!
<tankf33der>
tomorrow i will try udp client programming first time ever
<Regenaxer>
Good
<beneroth>
nice tankf33der :)
<beneroth>
any idea how to do "audio (speech) file to text" (ideally on MacOS) short of doing some machine learning yourself ? I find cloud services and crippling attempts to hook feed audio files into dictation feature
<Regenaxer>
UDP is connection less. You can listen and send on both sides though, making your own kind of protocol
<Regenaxer>
PicoLisp UDP makes sense only between two pil processes, as it uses PLIO
<tankf33der>
sad.
<tankf33der>
then i cant do it on picolisp.
<Regenaxer>
right
<Regenaxer>
At least not with the built-in 'udp' function
<Regenaxer>
'native' would do
<tankf33der>
libc functions ?
<tankf33der>
all this unknown to me.
<tankf33der>
musl
<Regenaxer>
You could check the end of src/net.c, doUdp()
<cess11>
Why would PLIO not work for wireguard protocol?
rob_w has quit [Remote host closed the connection]
<beneroth>
Regenaxer, maybe this should be explicitly stated in the ref for (udp), that the data is always transcoded using PLIO
<Regenaxer>
Hmm, what else could one expect? It sends/receives s-expressions
<Regenaxer>
The thing is that PLIO is nowhere mentioned in the ref, it is an "internal" format
<Regenaxer>
So we should open the pandora box and introduce PLIO
<beneroth>
hm. T.
<Regenaxer>
A section about it would be good indeed
<beneroth>
I can understand your view. you're right. its just that people coming from other languages will think this (udp) is similar to udp functions in other stacks - arbitrary binary data - no?
<beneroth>
do I understand it correctly, you use it mainly as a kind of pil-IPC-independent variant of (tell) ?
<Regenaxer>
I would not expect that, as Lisp has no concept of arbitrary binary data -
<Regenaxer>
Yes, IPC
<beneroth>
well (wr) (rd) :P
<Regenaxer>
right, but to remote machines
<Regenaxer>
'tell' is only the current process family
<beneroth>
aye
<Regenaxer>
and 'wr' and 'rd' would use TCP normally
<Regenaxer>
So UDP is useful for broadcasting or some messagings
<beneroth>
yeah makes sense. but I guess people will generally come with the assumption that they can use (udp) similar to TCP (different underlying guarantees aside)
<Regenaxer>
True
<beneroth>
I saw you used UDP on rosettacode for IPC
<Regenaxer>
(wr) and (rd) do not make sense for UDP
<Regenaxer>
There is no binary buffer on the Lisp level
<beneroth>
about the synchronous concurrency task: you think this would be a good approach for a productive setup too? what about lost packages?
<Regenaxer>
Not sure. It was just an easy solution of the task ;)
<Regenaxer>
There is also a coroutine solution
<beneroth>
yeah I'm asking because I like the distributed-over-multiple-hosts-aspect ;)
<Regenaxer>
yes, this is powerful
<Regenaxer>
but then packet loss becomes a risk
<Regenaxer>
So it needs some protocol on top of it
<beneroth>
yeah, so would need some kind of confirmation response. also ordering of packages can be a problem.
<Regenaxer>
But when using a protocol, you end up with self-made TCP
<beneroth>
so in most cases, just using TCP would be nicer
<beneroth>
yeah
<beneroth>
in gamedev there are some approaches to do your own protocols on top of udp
<beneroth>
mixed results afaik
<Regenaxer>
For speed perhaps
<beneroth>
yeah.
<Regenaxer>
There are cases where lost messages do not harm
<Regenaxer>
then UDP is fine
<beneroth>
yeah, video, audio etc
<beneroth>
though usually not true for game netcode
<Regenaxer>
yes
<beneroth>
so you have not used that IPC approach (via udp) in production yet? :)
<Regenaxer>
no
<beneroth>
for what did/do you use then (upd) at all? :D
<Regenaxer>
Never in commercial systems iirc
<Regenaxer>
I could imagine some peer-to-peer system, sending packets to each other
<Regenaxer>
If packets are lost it is no harm
<Regenaxer>
The info will propagate to all reachable nodes
<Regenaxer>
Or some time tick server
<Regenaxer>
I was playing (more thinking than actually building) of a simulation of neurons
<Regenaxer>
They could "fire" by sending UDP packets, distributed on many servers
<beneroth>
distributed deep learning system, eh? :P
<Regenaxer>
Perhaps :) Brain simulation
<tankf33der>
so udp client on natives, nightmare.
<beneroth>
ok. might be useful for me when I might eventually try out more distributed DB stuff
<Regenaxer>
tankf33der: native calls a nightmare?
<beneroth>
tankf33der, maybe you can copy the pil ASM source for (udp) and change it to your needs?
<beneroth>
though native is probably better...maybe
<Regenaxer>
yeah
<tankf33der>
native is now, no blood from nose anymore
<Regenaxer>
doUdp() calls only a handful of C functions
<Regenaxer>
:)
aw- has quit [Quit: Leaving.]
beneroth has quit [Read error: No route to host]
beneroth has joined #picolisp
<tankf33der>
then i have to implement networking primitives for udp client too
<Regenaxer>
T
<beneroth>
tough
<beneroth>
so you write the UDP stack for pilOS then? :D
<Regenaxer>
The nasty thing when using native here is setting up the addrinfo structures, I 'm afraid. Needs some digging into the system include files
<Regenaxer>
The call getaddrinfo(), socker() and sendto() # for server
<Regenaxer>
Client is easy, calls only recv() I think
<Regenaxer>
(looking at doUdp() in src/net.c)
orivej has joined #picolisp
alexshendi has joined #picolisp
rob_w has joined #picolisp
rob_w has quit [Client Quit]
karswell has quit [Remote host closed the connection]
orivej has quit [Ping timeout: 248 seconds]
Regenaxer has left #picolisp [#picolisp]
Regenaxer has joined #picolisp
<cess11>
Is it OK to have an er.l with 'class and 'rel definitions and keep another file with 'class and 'dm definitions? Any known gotchas or reasons not to?
<Regenaxer>
It is fine
<Regenaxer>
I often do (extend +Cls) in other files too
<Regenaxer>
However, re-loading the same classes gives "redefined" warnings
<cess11>
Ah, right, 'extend would probably be a little cleaner but also require 'load er.l to happen before 'load dms.l, no?
<cess11>
It is mostly to keep code readable as is, not sure if it will be kept into something published.
<Regenaxer>
Yes, it should be before
<Regenaxer>
OK :)
<Regenaxer>
If you just want to define a method in another file, (dm (msg> . +Cls) (Arg) ...) is also fine
<Regenaxer>
I do that quite often
<Regenaxer>
eg. GUI methods in the GUI context
<cess11>
Clever, thanks!
alexshendi has quit [Ping timeout: 248 seconds]
alexshendi has joined #picolisp
alexshendi has quit [Client Quit]
alexshendi has joined #picolisp
alexshendi has quit [Read error: Connection reset by peer]
alexshendi has joined #picolisp
orivej has joined #picolisp
orivej has quit [Ping timeout: 260 seconds]
miakatonic has joined #picolisp
miakatonic has quit [Remote host closed the connection]
miskatonic has joined #picolisp
miskatonic has quit [Quit: ERC (IRC client for Emacs 24.5.1)]