freenode/#lisp - IRC Chatlog
Search
12:21:20
Xach
I'll glom all the separate bits into a single response object, then specialize that object, then have a gf that finds an error condition for that object based on all its parts (response code, headers, body)
13:09:47
Shinmera
I don't know if grouping things into a single feed per author is a good idea. Some people might individually care about failures of a particular project.
13:10:25
Shinmera
And no, I'm fine with subscribing to multiple feeds, so just doing per-github-account or something is fine by me.
13:11:20
Shinmera
And who knows, maybe some day I'll get lucky and someone else will finally contribute significantly to Shirakumo projects.
13:56:53
phoe
I have a list (A B C D E F ... P Q R ... X Y Z). Is there a function that will get me a subsequence of this list, starting from the beginning, and ending at Q?
14:12:06
sabrac
Thank you. I wish I had more time to work on them because I learn so much doing them.
14:13:20
Shinmera
sabrac: I remember you mailing me about one some months back, but I don't recall it ever getting released
14:19:18
pagnol
apparently people use dots in package names to achieve something like nested namespaces, I'm wondering if I should adopt that
14:32:07
beach
pagnol: That way, you can use long names for your packages and short ones to refer to them.
14:35:19
Xach
Some systems use one big package and lump everything into it. I don't like that style a lot - I want the comfort of knowing I won't affect unrelated things in a particular section of a larger project.
14:37:29
sabrac
_death: Thank you for the reminder on package-inferred systems. I had forgotten about that. Heads off to re-read the asdf documentation.
14:39:13
Shinmera
sabrac: By the way, thanks again for the feedback and bug reports that spawned from the previous articles you wrote :)
15:29:36
pagnol
I got the impression there's quite a high reliance on global variables in lisp libraries
15:35:55
beach
pagnol: It is a convenient way of having several parameters without passing them explicitly to each function.
15:48:13
beach
pagnol: And in most Common Lisp implementations, a binding of a special variable is thread local (the global value is shared). That makes special variables even more convenient.
17:13:36
tfb
shka: I repeatedly find myself having to *implement* dynamic binding in other languages.
17:17:23
shka
pagnol: if you are not using alexandria, quickload it, then (alexandria:curry #'identity x) will do the trick
17:20:21
sonologico
pagnol: the resulting function accepts more combinations of arguments than what you wrote, but it does the trick
17:40:58
dmiles
(so checking to see if anyone made clisp disable its readline and forced rlwrap to takeover or suppliment)
17:55:36
loli
the issue I run into is that I make a few structs to model the type, and I terminate the structure on a symbol
17:56:14
loli
but the issue is that symbols don't really play nice when trying to defmethod as other data structures end on a symbol and there would thus be a conflict
18:44:56
emaczen
SBCL from the debugger with SLIME won't find my sources with M-. or v -- what should I try?
19:01:47
beach
Lots of people just use the default values, and waste a lot of time trying to debug their code with insufficient information generated by the compiler.
19:02:38
emaczen
beach: I have been using CCL to debug since it seems to by default always give me a lot of information in the debugger haha
19:03:40
rumbler31
beach: how would you go about triggering a recompilation once you want to change those values?
19:30:28
pagnol
I've begun littering my code with check-type and assert... presumably this is a very unidiomatic style in cl?
19:33:59
pjb
pagnol: check-type is what you should use (instead of declare type), in ALL your public functions!
19:52:14
pjb
Of course. The post condition of check-type is that the place is bound to an object of the given type.
19:58:23
_death
I think with the python compiler one of the big things was also the converse, that type declarations can perform as type checks (forget safety 0)
20:00:34
Xach
pagnol: adding lots of checks makes it harder to change things in the future. sometimes that's not very important.
20:01:47
pjb
Also, (defmacro disable-assert (&body body) `(macrolet ((assert (&rest args) 'nil)) ,@body)) (#+want-assert progn #-want-assert disable-assert …)
20:04:09
pjb
You would have to use your own macro, not cl:assert. This allows you to globally enable or disable checks if you want that too.
20:04:55
makomo
pjb: lol, i thought for a second that string of numbers was a version number. phew...
21:06:12
_death
pagnol: mop = metaobject protocol, which gives a way of introspecting and extending CLOS
21:22:11
aeth
pagnol: Macros can easily cause problems and unreadable code, but imo there are three common patterns that are very safe to stick with: define-foo, do-foo, and with-foo. (There are some uncommon ones that are safe, too, like foof, similar to incf or decf, that can be defined trivially via define-modify-macro.)
21:23:07
aeth
Pretty much everyone should be able to read these, especially if you stay close to similar APIs.
21:24:53
aeth
If you're talking about a define-foo, that appears all of the time. Sometimes it appears as "deffoo" if foo is one word, but please don't do that. Tools like emacs only recognize define-* and built in def* like defun, so your form won't stand out as a define.
21:29:54
Bike
you could do a dynamic binding deal with setf and unwind-protect, though it would be dumb as hell and inconvenient besides.
21:42:44
shka
or at the very least don't write macros were function will do, or you will use it just a couple of times
21:48:25
fourier
or how to create a C file accompanying my lisp code (if I want to implement just one function in C)
22:43:06
fiddlerwoaroof
I generally like def* more than define-*, editors are programmable for a reason: you should bend the editor to your workflow, not your workflow to the editor.
22:45:04
Shinmera
I generally like define-* more than def* and feel it's easier to read and a better convention, so I'm perfectly fine with the editor pushing people in that direction.
22:51:37
fiddlerwoaroof
I generally don't find def* less easy to read, since prefixes are pretty normal in ordinary languages
22:51:56
fiddlerwoaroof
And, define- is a bit too verbose for the amount of work it does, to my taste
22:53:07
aeth
Common Lisp the standard has plenty of archaic styles because it does not break backwards compatibility. That doesn't mean that the older APIs should be emulated. e.g. if you're doing a sequence accessor, copy elt or aref, not nth (and the reason is because there might be more than one index, like in aref, which requires the sequence to come first)
22:57:06
aeth
(Sorry, I should clarify that aref is only a sequence accessor when it's a 1D array, but that was not really the point with my example.)
23:03:26
_death
fe[nl]ix: interesting observation.. but not sure I've seen evidence for the existence of such a convention.. if it did exist, I suppose CLOS authors found a loophole.. just shorten the term to one word and we can use defgeneric :)
23:06:01
pjb
In-extenso names are all nice and well, but it often occurs that you have to write formula and that you need concision there, to ease readability, just because it's very much harder to read a formula with a lot of references to the same names when they're long and furthermore, when they have common prefixes! This is why there is LET, FLET and MACROLET.
23:07:01
pjb
Said otherwise, when you define APIs, use long and explicit names. When you use APIs, wrap them around in your own short names.
23:08:05
pjb
aeth: it's not worse, again, it's historic: there are not 2 prefixes, but 3! DE DEF and DEFINE-