00:15:26 alms_ [~alms_@146-115-42-237.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 00:23:18 -!- Phoodus [foo@174-17-246-43.phnx.qwest.net] has quit [Ping timeout: 240 seconds] 00:32:53 The hashing algorithm's similar, but is supposed to always return an (UNSIGNED-BYTE 29) (IIRC), so it's always a fixnum on 32-bit platforms. 00:37:18 -!- rme [~rme@pool-70-106-139-149.chi01.dsl-w.verizon.net] has quit [Quit: rme] 00:58:52 -!- alms_ [~alms_@146-115-42-237.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [Quit: alms_] 01:04:38 alms_ [~alms_@146-115-42-237.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 02:20:46 Phoodus [foo@174-17-23-38.phnx.qwest.net] has joined #ccl 02:40:15 m7d [~lriley@pool-71-102-237-143.snloca.dsl-w.verizon.net] has joined #ccl 03:00:59 -!- alms_ [~alms_@146-115-42-237.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [Quit: alms_] 04:33:24 -!- m7d [~lriley@pool-71-102-237-143.snloca.dsl-w.verizon.net] has quit [Quit: m7d] 06:00:22 roffe [~roffe@adsl-149-197.romerikebb.no] has joined #ccl 07:21:28 jdz [~jdz@193.206.22.97] has joined #ccl 11:25:58 -!- billstclair [~billstcla@unaffiliated/billstclair] has quit [Read error: Connection reset by peer] 11:41:38 billstclair [~billstcla@unaffiliated/billstclair] has joined #ccl 11:48:57 alms_ [~alms_@146-115-42-237.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 12:41:37 -!- Phoodus [foo@174-17-23-38.phnx.qwest.net] has quit [Read error: Connection reset by peer] 14:44:38 rme [~rme@pool-70-106-139-149.chi01.dsl-w.verizon.net] has joined #ccl 15:06:18 yakov [~yzaytsev@183.49.62.92.nienschanz.ru] has joined #ccl 15:06:21 hello 15:15:58 anRch [~markmilli@64.134.98.175] has joined #ccl 15:33:47 i keep getting Segmentation fault with either 1.5 and trunk 15:34:10 ubuntu 10.04 15:34:18 ./ccl-1.5-linuxx86/scripts/ccl 15:34:18 Segmentation fault 15:34:27 what could it be?! 15:35:03 what's your kernel version? 15:35:36 i was on ubuntu 10.04 (64-bit) recently, and ccl worked just fine 15:35:59 http://trac.clozure.com/ccl/ticket/731 15:37:29 If that's the issue, go to lisp-kernel/linuxx8664 (or linuxx8632) and run "make". That'll build a new lisp kernel that should run without crashing. 15:37:40 Linux movistar 2.6.32-24-generic #43-Ubuntu SMP 15:37:45 updated today 15:37:52 antiwiener [~antiwiene@84.114.246.246] has joined #ccl 15:38:08 no problems on 2.6.32-21 though! (my laptop) 15:38:36 damn. they borked my system. 15:39:59 rme, thk! solved. 15:40:13 good 16:04:24 -!- jdz [~jdz@193.206.22.97] has quit [Ping timeout: 272 seconds] 16:16:32 -!- anRch [~markmilli@64.134.98.175] has quit [Quit: anRch] 16:18:57 -!- antiwiener [~antiwiene@84.114.246.246] has quit [Quit: antiwiener] 16:21:34 anRch [~markmilli@64.134.98.175] has joined #ccl 16:29:10 -!- yakov [~yzaytsev@183.49.62.92.nienschanz.ru] has quit [Quit: Ex-Chat] 16:30:42 cvandusen [~user@68-90-30-246.ded.swbell.net] has joined #ccl 16:51:38 antiwiener [~antiwiene@84.114.246.246] has joined #ccl 17:02:03 -!- anRch [~markmilli@64.134.98.175] has quit [Quit: anRch] 17:19:20 Hi, I had sent an email to the list about (require :cocoa-application) failing to build, which turns out to probably have been cruft in the lisp itself. Is that a possibility, (i.e., some setting getting compiled into the image that screws up future compiles)? 17:21:06 cvandusen: do you often update/rebuild from within the IDE ? 17:22:30 gbyers: nope. I usually update via terminal. If I have an instance running I kill it, then run ccl64 (also from the terminal). 17:23:45 Or load asdf in your init file ? (I'm fishing, but ASDF changed recently, and I wonder if the problem had to do with that. I don't know exactly how it would have ...) 17:25:29 That's my suspicion, as well. Actually, I suspect that it was the conflation of trying out quicklisp and setting up one of those new ASDF config files (e.g., ~/.config/common-lisp/source-registry.conf). 17:26:16 I do load ASDF in my ccl-init file, and had added loading of quicklisp.lisp to it. 17:27:21 Well, maybe not the source-registry file... 17:27:59 cvandusen: Whenever I rebuild lisp, I start it with the --no-init flag, to keep my settings from screwing things up. 17:28:09 I did notice that quicklisp downloads its own copy of asdf. 17:29:09 sellout: Yeah, I tried that after getting the exception that I had initially reported, but is seems that whatever was causing the asdf-related error had been baked in by then. 17:32:20 I guess my question at this point would be, is there any way to get something like a clean slate from the existing lisp, or do I need to check out a new copy? 17:34:14 There might be some way to (for instance) delete the ASDF package, so that the old one didn't conflict with the new. I'm not sure that I understand what happened, so I'm not sure if that would fix whatever the problem is/was. 17:34:40 cvandusen: Just rm dx86cl* (or whatever it is on your platform), svn up, and rebuild again. 17:37:50 I'm going to try introducing the elements one at a time into the mix to try to determine where things went awry. The fact that there are two asdf's in the mix at all is kind of disturbing. 17:53:08 milanj [~milanj_@109-92-122-77.dynamic.isp.telekom.rs] has joined #ccl 18:02:22 I was able to reproduce by building ccl and requiring the app with both (require :asdf) and (load "~/quicklisp.lisp") in my init file, and then commenting out the quicklisp line and building/requiring. 18:06:25 anRch [~markmilli@64.134.68.175] has joined #ccl 18:38:23 roxlu [~roxlu@53569942.cable.casema.nl] has joined #ccl 18:38:39 -!- roxlu [~roxlu@53569942.cable.casema.nl] has left #ccl 18:51:26 Fade [fade@outrider.deepsky.com] has joined #ccl 18:52:06 does ccl provide a means to customize the behaviour of #'require? 18:52:25 forex, sbcl allows you to push functions into sb-ext:*module-provider-functions* 18:52:42 if so, where are the semantics documented. 18:52:47 s/\./\? 19:05:05 ccl has ccl:*module-provider-functions* also 19:05:54 I think the docstring is the only documentation. 19:08:47 rme: thanks 19:09:59 I grepped for the docstring, but didn't find. what file is it in? 19:10:19 ccl:level-1;l1-files.lisp 19:15:12 thank you 19:30:45 -!- anRch [~markmilli@64.134.68.175] has quit [Quit: anRch] 19:51:48 -!- antiwiener [~antiwiene@84.114.246.246] has quit [Ping timeout: 245 seconds] 20:17:12 antiwiener [~antiwiene@84.114.246.246] has joined #ccl 20:21:50 Fare [~Fare@ita4fw1.itasoftware.com] has joined #ccl 20:22:05 is there a way to muffle a CCL::PARSE-UNKNOWN-TYPE error? 20:25:58 It's a CONDITION, not an ERROR, and it's usually raised by SIGNAL, not #'ERROR. You have to do something - like establish a handler for CONDITION - in order for it not to be effectively muffled. 20:28:54 I *want* it to be muffled, rather than to display a warning and cause the compile-file to return a failure. 20:29:20 I don't know how else to say what I just said. 20:29:51 like, tell me what my handler can do. muffle-warning doesn't work, there's no restart for that. 20:30:02 (on the qres branch, r14261) 20:30:20 so I don't know how to effectively muffle it. 20:30:56 So, you're establishing a handler for CONDITION ? 20:31:09 yes, at least I'm trying. 20:31:26 but is there anything I can do in such handler? 20:32:46 When you get a condition that's not a warning or error, you turn it into a warning ? 20:33:20 we don't. 20:33:47 but somehow, with SAFETY 3, it gets displayed and promoted to some warning or something. 20:34:05 ;Compiler warnings for "/ita/x2/qres/lisp/quux/modules/metadata.lisp" : 20:34:05 ; In METADATA-MODULE: Unknown or invalid type MODULE, declaration ignored 20:34:35 doesn't happen with SAFETY 2. 20:37:25 Ah, now I see. 20:40:42 -!- antiwiener [~antiwiene@84.114.246.246] has quit [Quit: antiwiener] 20:50:06 any fix? workaround? 20:50:09 explanation? 20:51:31 Actually, I don't see: compiling (e.g.) a function definition that uses an undefined type in a declaration WARNs at all safety levels, but the code that does that does so by handling a PARSE-UNKNOWN-TYPE condition and WARNing with a COMPILER-WARNING. You're not really trying to handle a PARSE-UNKNOWN-TYPE. 20:52:07 what should I be handling instead? 20:52:42 Um, if I understand, you're trying to suppress the warning, aren't you ? 20:53:12 yes 20:54:23 also, is there any reason why size of the coverage-enabled binary has grown manifold 20:55:46 Ask gz. 20:57:13 Is there some reason why you can't do (handler-bind (warning #'muffle-warning) (compile-file ...)) ? 20:57:25 with enough parens ... 20:57:38 and how come the size of an image with coverage is 3 times the sum total of the sizes of the fasls? 21:00:40 Well, a fasl opcode that says (make-array 100000000) is probably a lot smaller than the resulting array, and there isn't generally much of a correlation between image size and size of fasls. Other than that, I don't know, and I certainly don't know specifically. 21:05:16 ok, looks like I could try to muffle those warnings with CCL::WARNING-TYPE: :UNKNOWN-TYPE-IN-DECLARATION 21:07:59 (maybe the *3 factor is due to strings being UTF8 or such in FASL and UCS4 in image?) 21:08:48 (and no, we don't try not to build huge static datastructures in QRes - unlike we do in QPX) 21:10:26 -!- alms_ [~alms_@146-115-42-237.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [Quit: alms_] 21:11:53 that ratio is true in general (e.g., most strings in fasl files are stored in an 8-bit encoding.) I honestly don't know much of anything about recent code-coverage changes; gz would. 21:12:49 -!- billstclair [~billstcla@unaffiliated/billstclair] has quit [Read error: Connection reset by peer] 21:13:03 -!- cvandusen [~user@68-90-30-246.ded.swbell.net] has quit [Quit: quit] 21:16:04 billstclair [~billstcla@unaffiliated/billstclair] has joined #ccl 21:18:46 fare: code coverage now records the macroexpanded sources for covered forms. They are stored as strings. I didn't think to compress them, but I could if the image size is a problem. 21:24:18 RPM currently has a 2GB size limit on the whole package (solved in trunk, but that's not likely to be universally deployed any time soon). 21:24:48 so compression might be useful. 21:26:15 -!- Fare [~Fare@ita4fw1.itasoftware.com] has quit [Quit: Leaving] 21:31:11 -!- billstclair [~billstcla@unaffiliated/billstclair] has quit [Quit: Ex-Chat] 21:35:13 jdz [~jdz@host212-109-dynamic.5-87-r.retail.telecomitalia.it] has joined #ccl 21:49:30 billstclair [~billstcla@unaffiliated/billstclair] has joined #ccl 22:35:03 alms_ [~alms_@146-115-42-237.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 22:35:31 -!- jdz [~jdz@host212-109-dynamic.5-87-r.retail.telecomitalia.it] has quit [Ping timeout: 240 seconds] 22:48:49 -!- alms_ [~alms_@146-115-42-237.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [Quit: alms_] 23:22:54 alms_ [~alms_@146-115-42-237.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 23:30:46 -!- milanj [~milanj_@109-92-122-77.dynamic.isp.telekom.rs] has quit [Ping timeout: 240 seconds] 23:31:03 milanj [~milanj_@109-92-122-77.dynamic.isp.telekom.rs] has joined #ccl