freenode/#lisp - IRC Chatlog
Search
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?
23:29:32
pjb
makomo: I don't understand it. (let ((v (vector 0 0 0 0 0 0)) (i 0)) (incf (aref v (incf i)) (incf i)) v) #| --> #(0 2 0 0 0 0) |# (in all implementations).
23:33:23
makomo
pjb: the analogy in your example would be "when is the place given by (aref v (incf i)) read?
23:33:54
makomo
is it right after all of the subforms of AREF are evaluated, or only when all of the subforms of the outer INCF have been evaluated?
23:34:17
makomo
you have nothing in your example that would affect the AREF place though, so it's not a very good example
23:35:02
pjb
How would you have anything affecting the operator of the place, when the purpose of define-modify-macro (and other setf-expanders), is to make sure that the subforms are evaluated once for all?
23:36:03
pjb
(let ((v (vector 0 0 0 0 0 0)) (i 0)) (incf (aref v (incf i)) (progn (setf (aref v 1) 42) (incf i))) v) #| --> #(0 44 0 0 0 0) |#
23:37:32
makomo
pjb: from what i can see in 5.1.3 that's not correct. preceding-forms are handled in (1). the subforms of the place are handled in (2)
23:37:59
makomo
i get that incf & co. work however they work, but i'm wondering about defining your own place-based macros
23:38:11
pjb
makomo: I don't know if (4) (3) would be better than (3) (4), but the later order, as specified, seems more logical to me.
23:38:52
makomo
pjb: none of the macros listed in the figure ever use (3), because they don't have any following-forms
23:39:09
pjb
Ok, they evaluate the subforms of the place in (2). I don't know what the preceding-forms in (1) are.
23:40:18
makomo
but no place-based macro has a following-form, so i don't have any examples (3) (4) vs. (4) (3)
23:41:12
pjb
with (3) (4) we get: (let ((v (vector 0 0 0 0 0 0)) (i 0)) (incf (aref v (incf i)) (progn (setf (aref v 1) 42) (incf i))) v) #| --> #(0 44 0 0 0 0) |#
23:41:23
pjb
with (4) (3) we'd have: (let ((v (vector 0 0 0 0 0 0)) (i 0)) (incf (aref v (incf i)) (progn (setf (aref v 1) 42) (incf i))) v) #| --> #(0 2 0 0 0 0) |#
23:41:45
pjb
so the setf would be inoperative. The first option gives us more semantic alternatives.
23:42:58
pjb
Also, 5.1.3 specifies two separate phases: evaluation of the forms an subforms. Then read-compute-storee. Both phases can be performed thus easily by different parts: a macro for the eval, a function for the update.
23:43:43
pjb
Now, who will write a modify macro where there are both preceding-forms and following-forms?
23:46:06
makomo
idk, in this case i think i would prefer (4) (3), because _f almost looks like a normal function call, except that is modifies its first argument (which is given as a place)
23:46:19
pjb
Yes. Nice example. Indeed, if you want to be consistent with 5.1.3, you will have to use _f34.
23:47:09
pjb
Well, there's always the left-to-right order of evaluation. At least, _f34 respects that.
23:48:43
makomo
hm what do you mean? don't they both respect the left-to-right order? (i'm not treating reading the place as an evaluation btw. i'm only taking into account the subforms of the macro and the place)
23:48:46
pjb
Sorry, I've got a harder time understanding what the values of (car yo) will be in the various subexpressions of _f43.
23:50:52
makomo
i agree that both examples are pretty horrible :-D, but f43 might be a little easier to think about
23:52:26
pjb
Are you sure such a macro would be useful? Instead, you could write a macro to generate a bunch of define-modify-macro forms for all the functions you need?
23:53:09
pjb
Will you have things like: (_f43 (case (random 3) (0 (function sin)) (1 (function cos)) (3 (function atan))) (car yo)) ?
23:53:33
makomo
hm well, i'm not sure yet, but wouldn't that be like defining lots of little useless functions instead of just using LAMBDA?
23:54:07
makomo
i.e. _f allows you to use a function "on-the-spot", without having to define a one-off read-compute-update macro for it
23:54:29
pjb
The question is whether the functions will always be known at compilation time, or whether they will be decided at run-time. In the former case, I don't think a macro like _f43 or _f34 is justified.
23:55:23
makomo
btw, from what i can see, (4) (3) is how it's implemented in On Lisp https://i.imgur.com/LXmuDG8.png
23:56:55
pjb
So for consistency you could still want to use _f34. Just so (incf …) and (_f34 '+ …) give the same results.
23:59:10
makomo
i guess that's a good point. i'm not sure whether that or "it almost looks like a function call and i expect left-to-right evaluation" is more compelling
0:00:32
makomo
an unrelated but interesting thing is that, theoretically, getting a place's value could yield different results depending on how you get the value: (1) by treating the place as a form or (2) by using code generated by get-setf-expansion
0:01:16
makomo
because (2) might arrange a different order of evaluation that what you would get from (1) by relying on normal left-to-right rules
0:03:13
pjb
You mean things that you can put as first argument of setf, but couldn't be used to get an object? Kind of write-only forms?
0:03:33
pjb
I guess you can do it easily with (defun (setf foo) (new-value where) …) without a defun foo.
0:07:28
pjb
There's very few write-only stuff in CL. IIRC, there must be one or two, but not with accessors.