freenode/#lisp - IRC Chatlog
Search
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