freenode/#lisp - IRC Chatlog
Search
10:03:59
jackdaniel
borei: its usually more wise to ask the question you have with providing details for the problem – if someone knows the answer he will probably share it with you
10:08:58
beach
I agree. Even if I were familiar with that software, I wouldn't admit that until I know what the problem is.
10:10:46
Shinmera
Having to ask back also makes it a lot more tedious. I often don't answer even if I knew what the solution was or could possibly help simply because I can't seems like too much of an annoyance.
10:23:57
Shinmera
I'm saying might because it'll be a while until it finishes compiling and I know for sure if there's any problems.
17:39:31
makomo
Shinmera: hey, just letting you know plump/clss/lquery are great. used them yesterday to scrape a site and they worked like a charm!
17:55:21
makomo
Shinmera: i'm taking a look at plump's source code out of curiosity and have a question. how come all the other asdf systems except for PLUMP don't have any components? what's their purpose then?
18:16:09
mfiano
makomo: In an older revision, everything was split up into separate systems. They are now there solely for backwards compatibility it seems -- so existing reverse dependencies that are using them do not break
18:49:40
borei
hi all, just got tired yesterday, finally found where the problem is but can't solve it. so here is description.
18:57:15
borei
apperantly problem is with glfw+threads+glx, there is nothing do with lisp, but maybe somebody has experience with it
20:46:02
makomo
is there anything like CASE but which uses a user-specified comparator instead of EQ?
20:46:53
makomo
for example, i want to branch on the values of an integer, but don't want to use COND and always repeat (= myint val)
20:50:21
_death
it doesn't evaluate the keys, so maybe that's the issue.. alexandria:switch does evaluate
21:02:29
pfdietz
If you have constant special variables you want in a CASE form, you can evaluate them at read time with #.
21:03:40
aeth
I had reader macro workarounds for using constants in macros and it worked on SBCL and ECL, but not CCL
21:16:32
pjb
aeth: you have to eval-when :compile-toplevel the defconstant for them to be available in the compilation environment, when the remaining forms are read.
21:16:51
pjb
aeth: ie. it's not a problem in the forms using the constant variables, it's a problem with defconstant.
21:17:27
pjb
clhs defconstant "An implementation may choose to evaluate the value-form at compile time, load time, or both. "
21:18:39
pjb
ALso interesting, the following sentence: "Therefore, users must ensure that the initial-value can be evaluated at compile time (regardless of whether or not references to name appear in the file) and that it always evaluates to the same value."
21:20:20
pjb
Notably, defvar/defparameter don't evaluate at compilation time, so (defparameter *foo* 42) (defconstant +foo+ *foo*) cannot work. (defconstant +foo+ 42) (defparameter *foo* +foo+) will work.
21:24:40
pjb
aeth: so what did you reader macro do? (+ +bar+ (case foo (#.+foo1+ 1) (#.+foo2+ 2))) is good enough. How do you justify !something(+ +bar+ (case foo (+foo1+ 1) (+foo2+ 2))) and do you avoid expanding +bar+?