freenode/#lisp - IRC Chatlog
Search
20:37:50
krwq
aeth: code is here: https://pastebin.com/QiKumC52 - so very thin wrapper on top of launch-program
20:40:49
krwq
aeth: I don't like thinking about names uiop used. They feel inconsistent - i.e. I usually group functions with similar functionality with prefix (i.e. process-*) besides I have found bugs in so many libraries already that I prefer to create wrappers so that I have stable APIs
20:41:51
aeth
There are probably lighter ways to rename a function. Maybe even just making the trivial wrapper functions inline.
20:42:15
krwq
aeth: while usually in lisp people prefer verb-something (i.e. kill-process rather than process-kill) I have gone with less english readable names but easier to discover
20:43:38
aeth
Common CL implementations basically never automatically inline unless you tell them to, afaik.
20:44:08
krwq
I don't care, when I do I will fix it - process execution is already way higher overhead than that
20:44:59
krwq
aeth: besides I've already started using builtin stuff after a way so many times :P (wasn't convinced to APIs at first but once I expanded my use cases I decided to just use original)
20:46:51
krwq
aeth: true but I have my own tiny standard library and I try to avoid putting stuff there which I'm not convinced will be useful yet
20:47:38
aeth
for renaming, maybe with one of those libraries that take a function lambda list and then `(progn (declaim (inline ,new-name)) (defun ,new-name ,old-lambda-list ...)) ; might get tricky with keyword/optional
20:50:54
krwq
basically playing with ADCs in C# on my Raspberry PI and wanted to plot the data in lisp from my main machine so will just run C# app by ssh and print the data out
20:51:35
krwq
would prefer use lisp all the way but need the ADC for work so got constrained by the language
20:56:52
krwq
Josh_2: that's what my plan was hence my question about streaming from process (technically could use sockets as well but didn't want to add too much logic in the process)
21:06:49
Josh_2
One of which has been sending data over sockets from java to cl backend, no problemos
21:06:50
aeth
The default encoder/decoder treats CL's NIL as JSON null, and one-way translates JSON's false to CL's NIL. https://common-lisp.net/project/cl-json/cl-json.html
21:07:42
aeth
That's a sign of a complete failure to understand that CL's NIL is used as false considerably more often than as a null-equivalent, and causes me to completely distrust the competency of the author
21:09:17
aeth
You can probably override that and do something like NIL <-> false, and :null <-> null, but I'm not sure I trust code written by someone who shows such a lack of understanding of the language that the author doesn't even understand a language's "false".
21:09:58
Josh_2
I suppose because I have always decided the data that is sent it hasn't been an issue
21:10:44
aeth
But look at that table (which is a pretty useful table). The defaults are not round-trippable.
21:11:15
aeth
So going CL->JSON->CL could give you different data than you sent. e.g. sending #\C will give you "C"
21:12:55
aeth
At that point you might as well not directly support characters/symbols and require that the user convert them imo. CL isn't an auto-coerce language, there would be a (+ 1 "foo") probablem even if + was overloaded to also mean concatenate 'string
6:11:18
no-defun-allowed
Can confirm, was looking for that page with the animated lambda magic on xach.com but the certificate broke