freenode/#lisp - IRC Chatlog
Search
3:58:37
beach
jasom: Did you look at the chapter about garbage collection in the SICL specification?
4:42:12
mfiano
Excuse me for not paying attention to the discussions here in a couple weeks, but has anyone noticed that the recent QL dist has a broken trivia system?
9:31:23
ogamita
At least they're consistent. However, the consistency breaks at (format nil "~{~}" nil nil) where ccl keeps signaling an error.
9:44:26
heisig
ACTION wonders how many implementors already had a nervous breakdown at chapter 22 of the spec...
9:46:08
jackdaniel
heisig: for better or worse some implementations just took cmu's code for that and fixed over the years :)
9:49:11
jackdaniel
(but chapter 22 is also about pretty printing and such - this is not part of cmu format)
9:56:57
splittist
If the ~{~} is empty, then an argument is used as the contents. It must be a format control and precede any arguments processed by the iteration.
10:11:04
no-defun-allowed
Chapter 22.3 is probably the most reread chapter in the clhs if I has to guess.
10:35:00
clintm
thank you! I think I was mentally filtering out -p functions assuming they returned nil or t.
10:35:41
jackdaniel
no-defun-allowed: no, digit-char returns a character, digit-char-p is the function
10:59:57
ogamita
splittist: Ah right! ~{~} is like ~? (format nil "~{~}" "~A" '(42 33 b)) #| --> "4233b" |#
11:01:12
ogamita
all predicates are allowed to return "useful" values. Only digit-char-p is specified to do so, IIRC.
11:05:07
jackdaniel
so in conforming CL code you may depend only on digit-char-p returning something useful
11:14:01
ogamita
and mismatch, etc. So, I was wrong: there are more than one predicate specified to return useful values.
11:36:03
pfdietz
Those predicates were so annoying when writing ansi-tests. Had to wrap (not (not ...)) around many forms to convert true to T.
11:48:45
pfdietz
There are also cases where predicates returned different values depending on compilation. (typep x '(member x y z)) might return T if constant folded, or (X Y Z) if actually called with those arguments.
14:46:53
neirac
I just found out about time function in common lisp to measure execution time, made my day
14:47:46
jackdaniel
neirac: then this tool will make your whole week: https://github.com/scymtym/clim.flamegraph/blob/future/screenshots/screenshot-1.png ;-)
14:50:42
hjudt
hi! i am having a problem with the dbd-oracle library available from quicklisp. apparently, it is not thread-safe and causes sbcl to crash or report freaky memory corruptions. when using the same code with sqlite3 the problem goes away. does anyone know of alternatives?
14:56:23
pfdietz
How does dbd-oracle do with other lisps? If it works in, say, ccl, is that a sign of an sbcl bug?
14:58:27
p_l
https://github.com/sergadin/dbd-oracle/blob/master/src/oracle-api.lisp#L354 <--- looks like culprit
14:58:27
hjudt
i've used plain-odbc before, which uses the oracle oci binaries too in some way (the odbc part of it that is). it did cope well with multiple connections.
14:59:56
hjudt
p_l: could be. maybe also https://github.com/sergadin/dbd-oracle/blob/master/src/foreign-resources.lisp#L14 which should be synchronized (easy to do in sbcl)?
15:01:03
p_l
there are few, inconsistent places where the OCIEnvCreate is called, all with OCI_DEFAULT instead of OCI_THREADED
15:01:41
p_l
access to *foreign-resource-hash* should IMO also be synchronized, can be done with standard Bordeaux-Threads code
15:02:30
hjudt
p_l: i've used sbcl's (make-hash-table :synchronized t). but as you mentioned, this is probably not the only culprit.
15:02:50
p_l
so you end up with C code messing with itself, and if that causes an address written to by C code to suddenly point elsewhere because of a race condition on data structure... welll
15:06:34
hjudt
i guess i will have to read up on oci docs if i want to try to fix this. unfortunately, this seems to be the only oracle library remaining for common lisp.
15:22:14
neirac
I'm trying to use clack it was working fine in ccl but I changed to sbcl and trying to load it gives me: Retry compiling #<IRONCLAD-SOURCE-FILE "ironclad" "src" "common">.
15:25:35
p_l
hjudt: just also make sure that access to lisp-side structures is synchronized properly
15:27:14
scymtym
neirac: some ironclad versions and sbcl versions don't work together. unfortunately, the easiest solution is upgrading both to the newest released versions
15:27:19
hjudt
p_l: thanks, i will look into this and see what i can achieve, though i am not sure i have enough experience to fix it. nevertheless it is worth a try.