10:01:05larsenarduo: if you're looking for an italian Lisp channel, I'd like to resurrect #lisp-it (currently no traffic, but it is not completely desert)
10:02:17arduook I'll add it to my autoconn list so we'll meet there
15:12:11jurovwhich says about :number lol "Benefits: Programmer expectations that any useful behavior can be portably relied upon in this pathological case should be soundly trounced."
15:12:51flip214phoe_: yeah, a function would be better here. it's just an example, I guess?!
15:13:00phoe_flip214: I want my examples to be sane.
15:13:13ogamitaphoe_: double quotes in default values for macro arguments is not strange, because macro arguments are source code!
15:13:31phoe_ogamita: yes, I got it after some internal brainwork.
15:13:47ogamitaphoe_: on the other hand, the fact that it seems unnatural to you is a hint it should be written as a function, not as a macro. ;-)
15:13:48flip214phoe_: then just change that to a function.
15:13:48phoe_One quote is for evaluating the source code, second quote is for evaluating the function argument.
15:14:03phoe_flip214: looks like SETF will break this way.
15:14:21flip214phoe_: as you said, a SETF expansion would then be needed.
15:14:27phoe_so I need a clever defsetf or a define-setf-expander.
15:19:16ogamitaflip214: with (setf getf) can change a nil into a list. (defun (setf …) …) cannot do that, you need a define-setf-expander.
15:20:05ogamitaphoe_: : on the other hand, with get, we have already an object, since get works on symbols, so there's no point in using the macro, (defun (setf age) (new-age p &optional d) (declare (ignore d)) (setf (get p 'age) new-age)) works nicely.
15:20:05phoe_but SETF GET seems to expand into something sane.
15:20:40phoe_ogamita: yes, that was my point - why the macro?
15:21:18ogamitaTo spare the double definition defun and defun setf…
16:20:05phoe_ACTION pushes chapter Symbols to CLUS
16:20:34shka_i am glad that lisp allows you to optimize memory allocation to a some extent
16:20:54shka_sometimes it can make huge difference
16:37:41d4ryusHi, is there a way to check how many bytes i can read off a stream (iam using usocket socket-streams)? because read-sequence blocks if my buffer size is bigger than the amount of available bytes.
16:39:02d4ryusI guess i could loop with LISTEN and read off one byte each time, but that sounds horrible performance wise :D
16:50:04ymTrying to build last sbcl from git on OpenBSD I get "./src/runtime/sbcl[1]: ELF: not found" and "./src/runtime/sbcl[2]: syntax error: `(' unexpected" messages. Google says nothing. Am I doing something wrong?
18:32:32d4ryusyay, there is (usocket:socket-option socket :receive-timeout), read-sequence will throw a error when the specified timeout is reached, perfekt
18:53:07drmeisterI'd like to run a webserver in Clasp Common Lisp that responds to http requests as well as websocket connections - what do people recommend?
18:59:36clintmI would have opted for fukamachi's websocket-driver-* packages, but there's missing support for the async lib in FreeBSD. It would seem that they are linux specific, though I didn't dig deeper since I'd already used hunchensocket a while back.
19:08:10myrkraverkDoes Lisp have any kind of coding style genealogy? I just learned that my preferred fortran comment syntax is for compatibility with fortran66.
19:11:23myrkraverkHas the usual coding style (as laid down be emacs) remained the same from the 50s/60s? Or has it changed?
19:11:34myrkraverkI haven't read any of that old lisp code (yet) so I don't know.
19:14:04Faremyrkraverk, not sure about "genealogy" here
19:14:20FareI once wrote Google's Common Lisp Style Guide.
19:14:49Fare(or rather, pieced it together from parts originally written by others.)
19:14:59Fare(I don't control the document anymore.)
19:15:41Faremyrkraverk, there are documents on the history of Lisp that explain how much the style has changed from the 1950s to the 1990s.
19:15:45Bikewell, the genealogy would be what others you got it from, and who they got it from