00:36:22 maxm [~user@unaffiliated/maxm] has joined #ccl 00:36:34 had anyone expirienced 100% cpu usage under slime all of a sudden? 01:01:58 maxm: No  but what is the process that is using 100% CPU? Emacs? The CL implementation? 01:10:31 sellout: CCL "Version 1.8-dev-r15230M-trunk (LinuxX8664)", slime from cvs.. There is no activity, only thing to reproduce is start slime from emacs. REPL works normally, but ccl process is using 100% cpu, one of the threads is always active 01:11:06 I think it may be either "reader thread" or swank-indentation-cache thread.. And it keeps consing, grew to around 2 gig after 2 hours or so 01:11:19 its probably slime/swank fault 01:12:10 rm -rf ~/.slime/fasl 01:12:16 err wrong window 01:18:09 ok, it seems that its (swank:receive) which spins in a loop trying to receive messages without any timeout 01:30:48 putting (sleep 0.5) in this place, stops all CPU usage http://i.imgur.com/Fjc9q.png 01:33:17 so is changing ccl:timed-wait-on-semaphore 2nd arg to 1000 from 1 01:33:25 all cpu usage gone, and slime is nice and responsive 02:05:40 ? (time (timed-wait-on-semaphore (make-semaphore) 1)) should take slightly more than 1 second. Does it ? 02:15:07 alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 02:37:39 -!- alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [Quit: alms_] 03:52:51 Fare [fare@nat/google/x-lbymzzfgneeezvzv] has joined #ccl 06:45:36 DataLinkDroid [~DataLink@1.142.113.109] has joined #ccl 07:06:49 -!- DataLinkDroid [~DataLink@1.142.113.109] has quit [Quit: Bye] 08:05:34 gbyers: hah, (time (timed-wait-on-semaphore (make-semaphore) 1)) -> 391 microseconds 08:05:59 (time (timed-wait-on-semaphore (make-semaphore) 1)) -> 9,000,329 microseconds 08:06:13 looks like some kind of rounding error you have inside 08:06:28 opensuse 11.4 08:06:42 default kernel and no fancy stuff 08:10:16 (time (timed-wait-on-semaphore (make-semaphore) 2)) > 1 second, but (time (timed-wait-on-semaphore (make-semaphore) 1)) always 0 seconds 08:30:55 hypno [~hypno@impulse2.gothiaso.com] has joined #ccl 08:47:08 i get slightly over 1 second when I ask to wait for 1 second, and I assume that everyone but you does as well; if that was "some sort of rounding error" that causes CPU time to reach 100% in SLIME, it's hard to believe that no one else would notice. 08:47:52 are you on amd64? 08:48:01 That was a Core i7. 08:48:13 But yes, in a 64-bit CCL. 08:48:48 And likewise in 32-bit CCL. 08:48:59 with ccl --no-init http://i.imgur.com/Wfs9Q.png 08:49:21 Linux momoland 2.6.37.6-0.11-desktop #1 SMP PREEMPT 2011-12-19 23:39:38 +0100 x86_64 x86_64 x86_64 GNU/Linux 08:49:34 maybe relevant, this is quad opteron numa box 08:50:43 I believe you, but if it's indeed true that the problem's unique to your system that would make me think that there' a bug in the syscall on that system. 08:51:04 we need another person on at least 2-cpu amd box to try 08:51:16 test is trivial, so just need to find someone 08:52:04 gbyers: I would agree if this was customized niche distro, but this is stock opensuse 11.4 straight from dvd 08:52:31 That wouldn't be the worst bug that's ever been in a released version of Linux. 08:53:14 A little over 1 second on an ARM ... 08:53:30 -!- Fare [fare@nat/google/x-lbymzzfgneeezvzv] has quit [Ping timeout: 252 seconds] 08:54:24 On 64-bit and 32-bit x86 FreeBSD ... 08:54:52 well I asked on #lisp maybe someone else will confirm/deny 08:56:10 I'm probably going to sleep pretty soon. There have been worse bugs in CCL too, but people would likely notice and report something like that (as you did), and I don't think that anyone else has. 08:56:53 well I don't think it was affecting anything else before.. It was fine around 3-4 months ago, until I upgraded slime 08:57:25 its slime redoing their send/receive internals using mailboxes that exposed it 08:57:27 And you've been running the same Linux kernel/C library since then ? 08:57:39 yes everything asme 08:59:22 hmm actually hold on, this may be it... I think I did "zypper patch" to install security updates and it pulled around 10 other libs with it, I have not rebooted since then, but I don't think glibc was among them 08:59:29 let me reboot the box and try again 09:05:23 -!- maxm [~user@unaffiliated/maxm] has quit [Ping timeout: 246 seconds] 09:36:08 maxm [~user@unaffiliated/maxm] has joined #ccl 09:36:43 false alarm guys, rebooting fixed it 09:36:56 *maxm* got too used to never rebooting with linux I guess 09:49:33 Glad to hear it; thanks. 12:51:06 -!- Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has quit [Quit: trivial-irc-0.0.3] 13:02:19 -!- sellout [~Adium@c-98-229-86-75.hsd1.ma.comcast.net] has quit [Quit: Leaving.] 13:08:15 Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has joined #ccl 13:20:08 hargettp [~hargettp@pool-71-174-137-155.bstnma.east.verizon.net] has joined #ccl 13:28:10 -!- hargettp [~hargettp@pool-71-174-137-155.bstnma.east.verizon.net] has quit [Quit: Leaving...] 13:36:09 hargettp [~hargettp@pool-71-174-137-155.bstnma.east.verizon.net] has joined #ccl 13:37:25 -!- hargettp [~hargettp@pool-71-174-137-155.bstnma.east.verizon.net] has quit [Client Quit] 14:08:28 alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 14:12:50 -!- alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [Client Quit] 14:15:15 Quadrescence [~quad@unaffiliated/quadrescence] has joined #ccl 14:17:49 Any reason why things like *DISASSEMBLE-VERBOSE* aren't in their own CCL-EXT package? 14:38:06 -!- rme [rme@89136AEC.80B03224.699BA7A6.IP] has quit [Ping timeout] 14:39:16 -!- rme [~rme@50.43.135.80] has quit [Ping timeout: 246 seconds] 15:24:19 Fare [~fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has joined #ccl 15:33:31 -!- Fare [~fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has quit [Ping timeout: 246 seconds] 15:47:09 Fare [fare@nat/google/x-sgdtnlydvtuxmgna] has joined #ccl 16:23:55 -!- Fare [fare@nat/google/x-sgdtnlydvtuxmgna] has quit [Ping timeout: 246 seconds] 16:24:24 Fare [fare@nat/google/x-djncypsuihjcvarw] has joined #ccl 17:27:55 -!- Fare [fare@nat/google/x-djncypsuihjcvarw] has quit [Ping timeout: 246 seconds] 17:56:28 Fare [fare@nat/google/x-tdkdsfbllnsnqdco] has joined #ccl 18:00:57 does ccl sometimes throw away a macro expansion and reexpand the same code later? 18:01:26 I'm having a heisenbug while using asdf-finalizers on CCL, and that's the only explanation I can come up with 18:01:44 when I add a debugging statement in eval-when, the bug disappears (!) 18:16:33 alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 18:25:42 jdijk [jdijk@ftth-212-84-159-210.solcon.nl] has joined #ccl 18:26:14 -!- jdijk [jdijk@ftth-212-84-159-210.solcon.nl] has quit [Client Quit] 18:59:52 or does ccl sometime decides to defer macroexpansion until loadtime or runtime? 19:05:14 it can't "defer macroexpansion" in compiled code. 19:17:31 or does it sometime does it early before fully processing previous toplevel forms? 19:18:10 in asdf-finalizers, I use side-effects to a special variable to defer things to be included in a (final-forms) macro's expansion 19:18:23 but in *some* files, when using ccl, this somehow doesn't happen. 19:19:01 it looks like the macro isn't even expanded (for a conditional format statement in the macro in debugging mode isn't run) 19:19:45 There's a compiler-macro on FORMAT ... 19:19:50 i introduced an eval-when form before (final-forms) to print the *finalizers* variable (holding the stuff to macroexpand later), and then the file compiles fine 19:20:11 which baffles me even more. 19:20:20 how can this affect that??? 19:20:44 things compile fine with sbcl 19:20:54 I don't know; I barely understand what you're talking about. 19:20:55 so there's something i don't understand about macroexpansion in ccl 19:22:21 The macro in question is user-defined ? 19:25:26 yes 19:25:53 I'm using asdf-finalizers -- http://common-lisp.net/gitweb?p=projects/asdf/asdf-finalizers.git 19:26:10 it worked well with its list-of extension. 19:26:45 then I tried to fix dlw's logging code to use it (instead of macroexpansion-time only side-effects, sure to lose when loading fasls) 19:26:57 and I'm having weird failures when compiling qres 19:27:05 (though not on sbcl) 19:32:34 I don't know or care what ASDF-FINALIZERS is, but CCL generally expands macros unless it has some builtin knowledge of the construct in question and is allowed to use that knowledge. There may be cases where a macro call is expanded more than once; I don't remember specific cases but I doubt that anything tries to avoid that. Whatever problem you're having may or may not have anything to do with macroexpansion. 19:32:43 The idea is that when you (register-final-form FORM), the form will be added to *finalizers*. At the end of the file you include a (final-forms) and it will expand to the forms in *finalizers*, and flush it. 19:33:33 this allows you to include a defun in your deftype expansion, for instance, and make sure it will be present in the fasl (as used by the monomorphic list-of) 19:34:09 dlw maintains a registry of logging categories and such in his logging code -- I'm trying to have it use that, too, but am seemingly failing 19:35:00 If you can digest that down to a very simple self-contained case, send it to me and I'll look at it. 19:35:14 I will try 19:35:48 Fare: it's odd that your attempt to add a debugging print changed the behavior. you could try altering *macroexpand-hook* to print diagnostic info for you 19:36:00 Vivitron, that's an idea. 19:36:25 Vivitron, and yes, that's very odd. 19:36:45 Actually, adding an eval-when (length *finalizers*) even w/o printing seems to have fixed the file 19:36:50 even odder 19:37:03 though at other times, this makes the thing fail 19:37:21 because *finalizers* is usually unbound at runtime 19:37:35 The macros in question are defined explicitly at compile-time - (EVAL-WHEN (:COMPILE-TOPLEVEL ...) (DEFMACRO ...)), or they're just toplevel DEFMACROs ? 19:37:46 toplevel defmacros 19:38:37 in one of the failing files, there was no defmacro, just calling of define-foo macros that expand into calls to logging (that now uses finalizers to register logging categories) 19:39:03 What can you portably assume about what environment(s) such macro definitions are defined in ? 19:39:40 I've wrapped the compile-file into a with-finalizers that specially binds *finalizers* 19:39:52 What can you portably assume about what environment(s) such macro definitions are defined in ? 19:40:00 and issues an error if it's non-null after compiling 19:40:26 the files end with (final-forms) which is meant to do the job. 19:41:01 oh, package issues... but wouldn't sbcl have found them? Lemme see... 19:41:46 nah, it's the correct package 19:41:59 at least in that one failing file 19:42:22 *maxm* remembers something tricky about this 19:42:31 This isn't likely to be a package issue. You might want to read the sections in CLHS that describe how toplevel defining forms (like DEFMACRO) are processed by COMPILE-FILE and about what you can and cannot assume about that. 19:42:37 *package* is different doing load-form in sbcl and ccl 19:43:04 ie if you have on object, that you have load-form method on, that does `(make-me-an-object ,*package*) 19:43:38 above ,*package* is original package in SBCL, but I think will be some other package under ccl 19:55:56 I don't think it's a package issue either 19:56:35 gbyers: you mean http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/sec_3-2-3.html ? 19:57:43 I don't think the problem is with defmacro -- it's with how the macros are processed 20:00:09 3.2.3.1.1 especially, and especially the passage that starts "It is not specifed ..." 20:05:58 specified, even. Given a choice between continuing this conversation on a Sunday afternoon and watching baseball on TV, I think I'll opt for baseball. 20:06:06 -!- gbyers [~gb@c-68-84-152-249.hsd1.nm.comcast.net] has quit [Quit: Leaving] 20:25:27 apparently, making sure I've in an eval-when before to expand the macro seems to do the job. Weird. 20:26:00 actually, even an empty eval-when *before* the macro does it 20:33:49 I suspect a bug wrt some state modified by fcomp-eval-when 20:34:58 -!- alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [Quit: alms_] 20:35:02 maybe calling fcomp-toplevel-forms is what does the trick 22:50:47 alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 23:04:10 -!- Fare [fare@nat/google/x-tdkdsfbllnsnqdco] has quit [Ping timeout: 252 seconds] 23:22:47 -!- alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [Quit: alms_]