freenode/#lisp - IRC Chatlog
Search
12:48:02
beach
phoe: Heh, so it's good to see that someone is paying attention (referring to commondoc).
17:32:16
jackdaniel
by standard he meant something what is /expected/ to be implemented by common lisp vendors
17:54:53
_death
so, where's the spec? it's just a library that people use.. there are others like it.. and now it'll be two libraries in one
17:59:23
Bike
i also meant something that's more exacting about specifications than portability libraries usually are
18:00:01
Bike
something that's important with atomics because debugging problems related to them is really annoying.
18:01:29
aeth
debugging problems related to threads is really annoying, atomics are just unnecessary in single-threaded programs.
18:02:13
Bike
i meant atomics makes things even worse than normal multithreaded programs. I thought that was obvious.
18:02:31
_death
it seems the new interface will have a document associated with it, but it's in a very early state.. https://sionescu.github.io/bordeaux-threads/
18:04:00
Bike
that's pretty reasonable in light of how patchy things are across implementations per shinmera's tracker
18:06:44
Bike
yeah. i've thought some about what an actual standard would look like and it would at least require a fair bit of work on every implementation
18:08:40
fe[nl]ix
for example, some implementations support atomic ops for struct accessors, but only for boxed slots
18:09:22
Bike
and one of the few libraries i could find using atomics, lparallel, assumes reads are sequentially consistent, i believe
18:10:49
fe[nl]ix
the only implementation that has a documented and well-thought API for barriers seems to be Lispworks
18:28:24
jackdaniel
timeouts are not implemented (I have them working locally, but that needs cleanup I did not have time to apply lately). also, they are based on spinlocks for portability; I suppose using i.e pthreads unices would be better for both cpu and performance
18:28:57
jackdaniel
I want to also bring back green threads, so there is n-to-m mapping; but that's another story
18:39:26
fe[nl]ix
jackdaniel: once Linux gets support for usermode scheduling, I'd like to experiment with a simpler Lisp before adding that support to SBCL
18:42:44
p_l
fe[nl]ix: doesn't read to me as full MxN threading... more like another implementation of what was part of QNX RPC port or the code that is part of Android Binder
18:45:01
jackdaniel
fe[nl]ix: if you have questions regarding ecl (if you decide to experiment with it) please let me know
18:55:40
fe[nl]ix
it's technically still 1:1 but the process can determine its scheduling priorities and control switching
19:04:02
p_l
Binder did that combined with the RPC - this meant that when you call a "remote" service, you stay in the same scheduler time slice
19:36:26
Duuqnd
From usocket's page on common-lisp.net: "(IPv6 support is also in progress and already available for SBCL/CCL with version 0.6.3+)"
19:37:36
gendl
now i have to make sure i have that version and see how to use it. I'm not seeing an argument for ip version in usocket:socket-listen
19:45:21
gendl
yeah i'm not seeing anything about ipv6 in https://common-lisp.net/project/usocket/api-docs.shtml
19:57:39
gendl
if you simply specify an ipv6 host to socket-listen, it'll be a ipv6 socket. Or just use *wildcard-host* which will make it listen for ipv6 connections on ipv6 capable systems.
20:06:45
phoe
I remember being stung by usocket that making a socket on "localhost" opened a socket on ::1
20:44:39
MichaelRaskin
Ah right, ::1 for localhost. I wonder when it will listen both protocols on loopback. like :: includes listening on 0.0.0.0 in some cases…
21:08:28
jcowan
What are use cases for conditions that are neither errors nor warnings? (I know that storage-condition is neither.)
21:11:22
p_l
also, the classic example is about interactive REPL, I believe, where technically there's an error
21:11:47
jcowan
That sounds more like restarts than conditions. What I am asking is about application condition types that descend neither from `error` nor from `warning`.
21:19:20
lonjil
jcowan: all condition handlers can do non-local control flow, and in any case you'd would signal a condition for someone to be able to select a restart even if there's no error or anything to warn about.
21:32:21
pve
jcowan: I'm writing a small language where the reader/parser may encounter expressions similar to (eval-when ...). When it does, it signals a condition that contains the expression, so that whoever invoked the parser may choose how to handle it (execute or ignore).
21:37:53
pve
that's my biggest difficulty with conditions, they always make me go "hmm, is this good design or just spaghetti?"
21:48:50
phoe
pve: you might want to use the idiom of (with-simple-restart (muffle-my-condition "Muffle my condition.) (signal 'my-condition))
21:49:25
phoe
this additionally lets the handler in question prevent next handlers from running, if - for whatever reason - it considers that to be appropriate.
21:53:23
aeth
pve: I'd personally make it optional and put it under a keyword argument (or something similar... maybe just a global dynamic variable) so the behavior of ignoring all conditions is implemented as a simple boolean lookup rather than signalling and then ignoring conditions.
21:54:11
aeth
Afaik this behavior needs to exist for e.g. --non-interactive in sbcl (or flags that imply that, or other CLs that use other command line flags)
22:06:44
pve
aeth: do you mean that --non-interactive bails on unhandled conditions of type "condition"?
22:07:40
aeth
pve: --non-interactive will, which is fine, because when you're using a Lisp non-interactively like that, the two most simple cases in your case would be (1) exit program with an error (basically for "free") or (2) ignore all of your custom conditions
22:08:56
aeth
#2 is equally trivial, but if done (no matter where in the program) by signalling and ignoring a condition, it'll be like... 1000x slower than a WHEN around each SIGNAL. If not more.
22:10:51
aeth
So if ignoring all is an expected common path, then I think it makes sense to extremely optimize for it in the API by putting a WHEN around each SIGNAL. (You don't need to optimize the exit-with-an-error path, since that doesn't have to be efficient)
22:13:08
aeth
phoe's path is not quite the same thing, in case you missed the distinction. That's the case where you handle it (at least) once and after a certain point ignore all of the rest. Although you might be able to modify the variable tested in WHEN there, too.
22:14:43
pve
but I just tried sbcl --non-interactive --load foo.lisp where foo.lisp signals a "condition", and sbcl didn't error out
22:18:04
aeth
fwoaroof[m]: It exists with error code 1 in --non-interactive if it gets an error at compile time. It doesn't always do that with an error?
22:18:50
fwoaroof[m]
I've had cases, though, where CI was succeeding when I was running dumped images that failed
22:19:31
aeth
I manually (uiop:quit 1) at the end of testing (so all tests still run) when I fail at least one test.
22:24:06
pve
aeth: ignoring the conditions is not the expected common path, but adding a switch might still be a good idea
22:32:46
pve
I guess I could have a dynamic variable that defaults to (constantly nil), which gets called whenever these special expressions are encountered
23:00:30
pve
aeth: was thinking I could just unconditionally call the handler variable, and it could replace the signal