freenode/#lisp - IRC Chatlog
Search
10:28:23
no-defun-allowed
(usocket:wait-for-input <list of sockets> :ready-only t) will do something like poll or select.
10:34:29
no-defun-allowed
You may also be interested in cl-async if you want to do asynchronous code, but I would learn synchronous sockets first, so you don't lose your mind picking up sockets and async code (if you aren't familiar with either).
10:36:22
h4ck3r9696
Can I easly integrate it with usockets? I don't think there are a lot of examples online.
10:38:37
no-defun-allowed
Not easily. usocket is synchronous and blocking (meaning it allows for sequential code that you can read staying in one piece), and cl-async is non-blocking and asynchronous (meaning you get a lot of "callbacks" and you have basically reinvented Node.js in your Lisp image).
10:42:26
no-defun-allowed
Plain old multithreading is also possible using bordeaux-threads; oh dear, they've left already.
11:24:42
dlowe
one of these days I'd really like to see a lisp implementation with a fiber/thread scheduler runtime.
11:25:36
flip214
dlowe: that's a real hard problem... priorities, fair scheduling, assignment to pthreads, ...
11:26:49
dlowe
I can tell you from experience that my OS scheduler gets pretty unhappy with 100k+ threads
11:28:09
kelamir[m]
comp.lang.lisp is now available from https://www.usenetarchives.com/threads.php?id=comp.lang.lisp&p=0
11:28:32
flip214
dlowe: yeah, but do you think your own would be much better, apart from 1 or 2 special cases that you care about?
11:28:36
no-defun-allowed
CMUCL had green threads, but that was a common survival strategy when POSIX threads weren't around (also seen in early Java).
11:29:14
flip214
I did work a few years on a c library doing fibers on pthreads... and it was no easy work
11:29:50
no-defun-allowed
flip214: You just need to context switch faster than your kernel, which should be easy given you don't have to fiddle with the MMU.
11:30:51
flip214
no-defun-allowed: well, if you need the kernel to find out whether it makes sense to switch threads (I/O or other events), it doesn't make much difference
11:31:36
flip214
ie. doing select() and then switching to some fiber stack isn't that much different from just blocking on read() and letting the kernel to its thing
11:32:26
flip214
yeah, in principle user-space switching could save lots of CPU and memory.... but lots of things needed for a sound implementation
11:33:46
flip214
what's that much better? all signals blocked, exactly one pthread that gets all of them
11:40:54
dlowe
the actual handling of the signal is made more complicated. It's not unsolvable, just annoying.
13:38:48
semz
this is possibly a cffi noob question, but is there a way to dig through a chain of foreign structs (think a->b.c->d) such that: 1. there are no allocations except for maybe the final result 2. the solution isn't to calculate the offsets by hand every time?
13:39:38
semz
it's fine if it only works for structs that are directly embedded, though if it can go across pointers that'd be even better
13:51:31
mfiano
What's a good test you can come up with for checking if an integer is one of [4,7,10,13,..,∞] and not [0-3,5-6,8-9,11-12,..,∞]? I currently have (and (> i 1) (= 1 (mod i 3))).
13:54:31
mfiano
Right, then replace with most-positive-fixnum if you didn't know I meant mathematically zero plus the whole number set
13:58:21
mfiano
and I stupidly used the answer without much thought, when it was wrong. The above is correct
16:52:11
pxpxp
Does anyone have experience with hunchentoot session management? I'm trying to use sessions only through cookies, not URL rewriting. But in my minimal example here (https://pastebin.com/iJEcD9rv), hunchentoot does URL rewriting even though it also correctly sets a cookie (seen from the developer tools): after logging in, I see an unwanted "?hunchentoot-session=..." in the URL.
17:40:35
flip214
pxpxp: the documentation says "Once a request handler has called START-SESSION, Hunchentoot uses either cookies or (if the client doesn't send the cookies back) rewrites URLs"
17:45:42
pxpxp
I've looked at the packets with wireshark. On submission of the login form, the reply is a 302 Moved Temporarily, to new location: http://localhost:4242/?hunchentoot-session=<cookie> and also a Set-Cookie to this cookie. Then my client dutifully sends back the cookie. But I understand why hunchentoot does it this way: if the user didn't send back the cookie, the session would be lost.
17:46:54
pxpxp
However I thought setting *rewrite-for-session-urls* to nil would make the server send the cookie but not redirect to a URL containing it.
17:50:56
mfiano
YOu might be able to look at what clack's hunchentoot backend does. I know I've never seen it use GET query parameters for cookies.
17:50:57
pxpxp
So I'll probably only have the URL "polluted" just after login (then when I click on a link, hunchentoot knows I'm sending back the cookies and everything is fine). Still, I'd like to avoid this if possible.
17:52:28
mfiano
Might even be worth developing for clack so you can switch out the server in production without any server-specific code changes
17:55:01
flip214
otherwise the ?ht-s=... gets added, unless you already have a cookie or provide a more-complete url
17:58:51
pxpxp
mfiano: I've considered Clack and I understand that it's probably a superior solution, but as a beginner I decided to go for the project with good documentation (I guess this might be a frequent debate?)
18:21:08
jasom
pxpxp: the choice of hunchentoot is fine; mfiano was suggesting you look at the clack code that interfaces with hunchentoot to figure out how this can be done, since we know that clack can do this with hunchentoot
18:21:51
jasom
pxpxp: however I suspect that clack does not use hunchentoot's session management at all, so that's probably a dead-end
18:22:48
mfiano
Right, I was also noting that it _might_ be worth it to build on top of clack instead of hunchentoot directly, for the benefits that provides, and if you can't do it otherwise. Depends how invested you are already, etc, but it is an option.
18:33:17
jasom
Also the builtin session logic in hunchentoot looks questionable from a security point of view
18:37:31
jasom
and you can plug the session-verify, and inherit from session to use something more obviously correct
18:39:03
jasom
actually you can't do what I just said because regenerate-session-cookie-value is not generic nor is stringify-session. That's slightly annoying
18:51:51
pxpxp
(if I remove the :add-session-id nil and only (setf hunchentoot:*content-types-for-url-rewrite* nil) once on server startup)
18:53:15
jasom
pxpxp: apparently there's also hunchentoot:*rewrite-for-session-urls* which is probably the better way anyways; I'll try with a quick test
18:59:05
jasom
my quick test was (define-easy-handler (foo :uri "/foo") () (start-session) (redirect "/bar"))
19:52:04
pxpxp
jasom: interesting, it doesn't for me (I already had this line in my initial question)
20:22:49
dbotton__
is there a reason examples of clos use a defgeneric when it is automatically generated on first defmethod?
20:29:38
no-defun-allowed
It's considered better style, and you need a DEFGENERIC to use a non-standard method combination or other settings.
21:42:52
no-defun-allowed
And you usually see DEFGENERIC in definitions of a protocol, as well as defining protocol classes.
21:44:53
Bike
it can vary. beach, for example, likes to have a separate protocol definition, like this https://github.com/robert-strandh/SICL/blob/master/Code/Cleavir/CST-to-AST/generic-functions.lisp
21:48:16
no-defun-allowed
My code usually has protocol files, but they're probably not as clean as beach-style, as it also contains default implementations.
21:48:50
aeth
I usually put defgeneric, defconstant, etc., at the very top of the first relevant file, and then the other non-defun/defmethod defines like deftype/defclass/defstruct right below them
21:55:16
aeth
Often it makes sense to e.g. have a file full of just define-condition or a file full of just defconstant or whatever, but those are usually larger projects, which are rare. I could see myself having a file full of defgeneric, but it would have to be a pretty large application