freenode/#lisp - IRC Chatlog
Search
4:22:25
aeth
So this seems to work as a way to run something in another thread but the consing quickly adds up so it's clearly not supposed to be done in a big loop: (defun my-thread () (loop (bt:with-lock-held (*world*) (bt:condition-wait *hello* *world*)) (format t "Hello!~%")))
4:23:49
aeth
Is there a better way to tell a thread to wait to resume until it's told to do so by another thread? One that's more loop-friendly.
4:28:51
pjb
aeth: condition-wait is the way to do it. However you have to be careful if several threads wait on the same condition, since it's random which will wake on signaling the condition.
4:30:31
aeth
pjb: What I like about condition-wait is that every subthread can be written like a loop, just like the outer controlling loop. What I don't like about it is: (1) it would be tricky to coordinate e.g. 127 child threads since they'd all need their own name to be awken that way
4:31:25
aeth
and (3) in SBCL it appears to cons a decent measurable amount *each* iteration of the loop, so for something that's a quick calculation meant to be run very frequently, this is going to be very suboptimal
4:57:44
emaczen
I'm using cffi:define-foreign-library and cffi:use-foreign-library no differently than I have in the past, but for some reason when I asdf:load-system my system with the foreign-libraries lisp just hangs
4:58:46
emaczen
Strangely, the compilation reports that it has cached the fasl so if I restart, it will successfully load the cached version
5:02:45
emaczen
It looks like the use-foreign-library form is what is hanging (if I comment it out and try asdf:load-system) but even when I leave it in, the forms following are compiled/loaded but it just hangs...
5:49:16
emaczen
Related to what I asked about an hour ago, I decided to try loading my system with my own loader rather than ASDF (my loader doesn't know how to load CFFI, so I used ASDF to load CFFI first before loading my system) and I'm not getting any hangs
6:18:22
PuercoPop
yeah, its an external contrib. (I'm using the Sly port of said contrib. Just expanded a macrolet)
6:20:03
PuercoPop
https://github.com/joddie/macrostep The macrostep repo appears to have the Slime support included
6:28:12
emaczen
What is the correct method to customize when a defclass form is evaluated? I tried ensure-class-using-class with my metaclass being the first specializer, and it works, but only after the defclass form has been evaluated once (which is because of the way ensure-class is defined by default)
6:50:24
emaczen
phoe: I'm reading the definitions of sb-mop:ensure-class and sb-mop:ensure-class-using-class
6:52:10
emaczen
The reason why, is because the metaclass object in (defmethod ensure-class-using-class ((class null) name &rest args &key) ...) has type standard-class
6:53:02
emaczen
I put a break point in the call right above (apply #'make-instance metaclass :name name initargs)
7:12:34
emaczen
The problem is the metaclass argument in ensure-class-using class is a standard-class with the name of my metaclass
7:18:04
emaczen
Before, after I tried what I thought, then I tried make-instance like you originally said haha
8:32:18
schweers
I have a question about DECLAIM. If I put a toplevel form at the beginning of a file, it will affect the compilation of the rest of said file, correct?
8:33:53
jackdaniel
schweers: "As with other defining macros, it is unspecified whether or not the compile-time side-effects of a declaim persist after the file has been compiled. "
8:34:46
schweers
I can’t help it, but this seems like a bad idea. Do you know the reasoning behind this descision?
8:37:15
schweers
This seems to me as if the declaim forms in a library I load (might) affect how my code is optimized. Or did I get that wrong?
8:38:02
jackdaniel
it is unspecified, so they might (just as proclaim and changing reader settings will)
8:39:09
jackdaniel
as of rationale: I can imagine it is for consistency with other macros which are treated specially when toplevel
8:40:22
schweers
I’m not sure which others are treated this way, can you give an example off the top of your head?
8:43:04
jackdaniel
i.e defmacro, in-package and such, they affect compiler even without being put in eval-when
8:43:45
schweers
Ah, and there too it is unspecified when the effect ends? Well, I guess not for defmacro, but for in-package?
8:51:04
jackdaniel
this is a tricky one, in-package setf *package*, but package is bound for each file
9:03:35
makomo
"(...) nor is it specified whether they are available in subsequent compilation units or subsequent invocations of the compiler."
9:10:57
makomo
and then there's also "In particular, the information stored by the defining macros at compile time might or might not be available to the interpreter (either during or after compilation), or during subsequent calls to the compiler.", along with a surprising example
9:11:22
schweers
It seems to me that this is so that (say) defmacro causes effects which affect runtime, but not compilation. But I’m not sure.
9:20:54
pjb
No, it's just that you can compile the code in a different image than where you load it, and also where you run it.
9:21:51
pjb
ccl -x '(compile-file "foo.lisp")' -x '(ccl:quit)' ; ccl -x '(load-file "foo")' -x '(ccl:save-application "foo" …)' -x '(ccl:quit)' ; ./foo
9:22:07
pjb
It's compiled in the first process, loaded in the second process, and executed in the third process.
9:22:34
pjb
There is nothing in common between the first two process (compilation, load), and little in common between the second and the third.
9:23:13
pjb
And with ecl, it's even worse, since it doesn't save a lisp image, but reload the compiled files when you launch the run-time program.
9:24:03
schweers
Well, doesn’t your example also load the code twice? Once in the second step, and again in the third?
9:25:51
schweers
So if I added a (eval-when (:load-toplevel) ... ) with some visible side-effect (say, format), it would only show up once?
9:26:01
pjb
schweers: it's easy to see: (eval-when (:compile-toplevel) (print :compile-toplevel)) (eval-when (:load-toplevel) (print :load-toplevel)) (eval-when (:execute) (print :execute)) (defun main () (print :run-time))
9:27:21
pjb
Saving a lisp image, and restoring is neutral for non-live data. (and even for some live data, eg. clisp tries to re-open opened files if they're found at the same path).
9:27:29
schweers
Running such an executable does something similar to loading, right? Somehow the image has to be restored. But this is not considered load-time as far as the language is concerned?
9:29:17
pjb
This is why you have this development mode, called "in image", where you run a lisp image, mutate it (eg. at the repl), and save it for the next session, rinse and repeat until your lisp image contains your application.
9:29:39
schweers
Even though there are still some cases which I have not yes successfully wrapped my head around, I like how most implementations handle this image based approach.
9:29:53
pjb
The defect of this development mode is that it's not reproducible, unless you have very good introspection tools (not in standard CL implementations, but have a look at ibcl).
9:29:59
makomo
just to refresh my memory: :compile-toplevel corresponds to COMPILE-FILE, :load-toplevel to LOADing compiled files, and :execute to EVAL/LOADing source files, right?
9:29:59
pjb
Image Based Development http://www.informatimago.com/develop/lisp/com/informatimago/small-cl-pgms/ibcl/index.html
9:31:57
makomo
and what about COMPILE? i always forget how that fits into the picture. i guess COMPILE doesn't do top-level form processing so the only relevant situation is :execute?
9:34:16
makomo
hm yeah, only :execute is relevant, but the evaluation happens at run-time of course, once the compiled function is called
9:35:18
makomo
pjb: but even with all this EVAL-WHEN recap, is this line "nor is it specified whether they are available in subsequent compilation units or subsequent invocations of the compiler" not surprising?
9:35:42
pjb
(eval-when (:compile-toplevel) (compile foo)) But by definition compile doesn't compile toplevel forms.
9:36:24
makomo
pjb: i meant more like (compile nil '(lambda () (eval-when ...)), but yeah, not top-level form processing so that's settled
9:39:26
makomo
so let's say we have files A and B, and there's a macro M defined in A. subsequent forms in A use the macro M, and forms in B also use the macro M. does this mean that just compiling A is not enough in order to compile B?
9:39:38
makomo
i.e. you'd have to also load A in order to be sure that M is available when B is being compiled?
9:41:14
pjb
See the discussion about the environments at http://www.lispworks.com/documentation/HyperSpec/Body/03_ba.htm
9:42:34
pjb
M can be used in A, because the compiler will use what it has saved in the compilation environment of A to be used by the rest of the file.
9:43:00
makomo
yeah, i've read this a couple of times. now i see that it's actually quite a normal thing, but it was surprising to me because it regarded such a common macro, DEFMACRO (but i get that that makes no difference now)
9:43:04
pjb
On the other hand, M can be used in B, only because the compiler saved some information in the fasl file, that has been loaded into the compilation environment of B.
9:44:31
pjb
But notice that how the enviroments are segregated is entirely implementation dependent. But you find that you soon need to load A to compile B.
10:31:26
schweers
Given a class, I want to get all slots in it (to generate some code for every slot). Do I have to use MOP for this?
10:33:20
no-defun-allowed
You could write a macro which reads the defclass slot descriptions and generates code from them.
10:33:21
schweers
Now that I think about it, I could instead use a macro which defines both the class and the code per slot. This may be easier.