freenode/#lisp - IRC Chatlog
Search
12:05:18
pjb
drmeister: you have 3 solutions: 1- wrap your (cdr (assoc key table :test 'string=)) in a functional abstraction. 2- intern those strings into some package (intern key "PYTHON-SYMBOL"). 3- internalize the strings themselves: (setf (gethash key *interned-strings*) key) with (defparmeter *interned-strings* (make-hash-table :test 'equal) or 'equalp for case insensitivity.
12:05:56
pjb
then (cdr (assoc (intern key "PYTHON-SYMBOLS" table))) or (cdr (assoc (gethash key *interned-strings* table)))
12:07:02
pjb
drmeister: it's rather trivial to write either a macro or a reader macro so that dict["a"] can be interpreted as ([] dict "a").
13:44:47
easye
Anyone know of any open concolic testing CL code <https://en.wikipedia.org/wiki/Concolic_testing>?
13:46:15
easye
err, the language tested doesn't have to be Common Lisp (actually I am interested in many others: JavaScript, EVM, etc.), but is there any concolic testing analysis expressed in CL?
14:31:15
phoe
drmeister: fun trivia, dict["a"] is an M-expression, which was the proposed syntax for Lisp back in the day
14:33:45
pjb
https://www.informatimago.com/develop/lisp/com/informatimago/small-cl-pgms/m-expression/index.html
15:41:09
gendl
Hi, any idea why asdf would suddenly start ignoring asdf/output-translations:*output-translations* ?
15:41:35
gendl
(((#P"/Users/dcooper8/.cache/common-lisp/ccl-1.11-f96-macosx-x64/**/*.*" T) (T T) (T #P"/Users/dcooper8/.cache/common-lisp/ccl-1.11-f96-macosx-x64/**/*.*")))
15:42:39
gendl
same thing with compiling systems etc -- the fasls are just going directly in with the sources
15:43:17
gendl
i'm not sure when this started happening, as far as I know I didn't touch my asdf version... have been running 3.3.1 for a while.
16:17:16
gendl
... working on it... Just started a bare vanilla lisp with asdf, and the output-file is working correctly. So, apparently we're doing something to step on the output-translations at some point. Tracking it down...
16:26:02
gendl
Just cleared all old .fasl files, in ~/.cache/common-lisp, quicklisp/cache/, and the ones which were ending up next to source files, restarted, and now it seems back to normal.
16:26:38
gendl
apparently something was reading one or more stale .fasl files which was causing things to get wedged.
18:03:12
gendl
I finally found the issue. aserve.asd from https://github.com/franzinc/aserve is disabling output-translations.
18:13:52
gendl
tbf the aserve.asd is not used by Franz themselves - it was just contributed by somebody.
18:16:33
gendl
although I don't assign any malicious intent to anyone in this case, the effect it has can be felt as malicious.
18:17:11
gendl
the library itself is anything but low-quality, when used with Allegro (or now, zacl).
18:17:56
gendl
I'm going to lodge a pull request to delete that (asdf:disable-output-translations) - I don't see where it serves any possible useful purpose. Maybe 20 years ago it did.
18:18:50
gendl
there are a few other minor tweaks needed to make current aserve work with zacl on SBCL and CCL - someone (and it might end up being me as well) needs to lodge a pull request for those as well.
18:19:13
gendl
otherwise a very slightly forked version of aserve will have to be carried by Quicklisp.
18:19:16
fe[nl]ix
I remember a complaint buy sombody at Franz a few years ago, that output translations broke their special build system which relied heavily on symlinks
18:21:15
gendl
If anyone knows if/where he's still around, I can ask him his original intention there (if he remembers from 20+ years ago).
18:23:34
gendl
I can understand people wanting to disable or tweak output-translations for certain build environments, but 1) it sure doesn't seem like that should ever be done in an actual .asd file(!), and 2) there should be some temporary way to do it, which "bounces back" when the special build environment comes out of scope (I'm not sure the canonical way to tweak or disable output-translations "temporarily").
22:14:40
makomo
http://clhs.lisp.se/Body/05_ac.htm lists a couple of "read-modify-write" macros, describes their general form as "(operator preceding-form* place following-form*)" and defines the order of evaluation of their subforms. what i'm interested in particular is points (3) and (4) -- do you think (3) (4) is a better order than (4) (3)?
22:14:42
makomo
personally i think the order (3) (4) is weird, because one would expect the value to be read (point (4)) right after the place's subforms are evaluated (before (3)), and not at the end of evaluating "following-forms" (after (3)).
22:14:49
makomo
even define-modify-macro defines macros that work this way because their general form is (disregarding the multiple evaluation problem of the place's subforms) "(setf ,reference (function ,reference ,arg1 ,arg2 ...))". the order here is (2) (4) (3).
22:14:52
makomo
the page above doesn't even list any macros that have "following-forms" and that use (3) (4) and i don't know of any examples off the top of my head. are there even any?
22:14:55
makomo
this question of style might vary from macro to macro, but as a concrete example, what order would you expect from the macro "_f" given by https://i.imgur.com/ucUEOP0.png? disregard the actual implementation and try to only look at the call to the macro. here are the two implementations but with the modification that "op" isn't a symbol but a form that is evaluated to get a function:
22:24:06
drmeister
How would I get a slot-definition given the slot name and the class of an object?