02:56:05 billstclair [~billstcla@unaffiliated/billstclair] has joined #ccl 07:50:22 e-user [~e-user@port-87-234-24-237.static.qsc.de] has joined #ccl 08:14:30 jdz [~jdz@193.206.22.97] has joined #ccl 13:48:41 -!- gb_ [~gb@c-68-35-35-22.hsd1.nm.comcast.net] has quit [Quit: Leaving] 13:49:03 gbyers [~gb@c-68-35-35-22.hsd1.nm.comcast.net] has joined #ccl 14:02:17 sellout [~greg@c-24-61-13-161.hsd1.ma.comcast.net] has joined #ccl 14:02:25 e-user: ping 14:05:22 gybers: pong 14:05:33 gbyers: pong (sorry, typo) 14:06:28 I don't know if you realize, but the reason that the stab section size doesn't seem to be an integral multiple of the entry size is that as only writes 12 bytes (instead of 20) for each entry. 14:08:10 i guessed so :) if i got it right, the section size should usually just match the entry size. 14:08:24 which is not the case here.. 14:09:11 is it worth fixing? for 1.5 i do already have the stripped version using a patch, what's 1.6's state regarding stabs? 14:10:14 I can't seem to get line number info any other way, and am hesitant to change anything in 1.6 unless it's a showstopper bug. 14:11:24 The .stab section size should be a multiple of the entry size. Each entry is in fact 12 bytes long, but the entry size is advertised as being 20 bytes. 14:13:33 is it easy to add padding? 14:14:37 It's probably easier to fix the assembler (gas), which is where this bug is and which is what you'd have to change to "add padding." 14:17:02 alms_ [~alms_@146-115-42-237.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 14:17:12 you mean gnu as definitely has a bug here? ouch 14:17:41 Since other things seem to work (gdb, ld, etc.), the "fix" is probably to change the advertised entry size to 12. I don't know whether elfutils can deal with that. 14:18:47 Where else would the bug be ? m4 macros don't really get to exercise control over the object file format, they just emit .stab directives ... 14:19:51 ah, originally i'd thought you were in direct control of the stabs section size through the actual content emission..? 14:20:01 Nope. 14:21:02 Those directives just get encoded into a struct, as defined here: http://sources.redhat.com/gdb/download/onlinedocs/stabs/Symbol-Table-Format.html#Symbol-Table-Format 14:22:01 do you think we could hack together a minimal sample that reproduces the error? 14:22:20 that would have to be reported to the gnu binutils project 14:22:33 Sure. And at some point, it'd likely get fixed. 14:24:02 as is basically always using a 32-bit version of that struct, where the "long" and "bfd_vma" -typed fields are 4 bytes wide. It then claims that each entry in the section is 20 bytes. 14:24:22 bzzbzz [~franco@modemcable240.34-83-70.mc.videotron.ca] has joined #ccl 14:24:39 what an astute tool. 14:25:12 I'd guess that elfutils is the only thing that cares - gdb, ld, etc. clearly don't. 14:26:08 i can confirm that.. it's unfortunate that elfutils play a role in rpm packaging and just deactivating that part is a way of definitely not getting this through the review 14:26:19 s/play/plays/ 14:27:34 for now i could just try to patch the ELF binary after building or, again, patch away the stabs sections one last time and try get the binutils team fix gas until 1.7 14:27:44 any better idea(s)? 14:27:46 In the relatively short term, the right thing is probably to have an option that gets passed to m4 and which prevents .stab generation. 14:28:59 If you patch the elf section header (and change the entry size from 20 to 12), I don't know if elfutils would like that; it may expect a real 64-bit version of the structure. 14:30:50 would you write this change for 1.6 or shall i write it myself and hand in the patch as a temporary official workaround in ccl's (post-1.6) HEAD? 14:31:04 What chage ? 14:31:11 change? 14:31:38 The option in the Makefile ? Sure, I can do that. 14:31:39 the said m4 conditional. 14:32:01 thank you gary :) 14:32:26 The Makefile would probably generate stabs by default, but you could uncomment something to build without them and avoid these problems. 14:41:07 that's 14:41:17 itchy finger 14:41:52 gbyers: that's just fine, the makefile is already being patched during the build process anyway 14:46:14 btw, is there any other distro that features ccl yet? 14:46:19 sellout- [~greg@c-24-61-13-161.hsd1.ma.comcast.net] has joined #ccl 14:46:23 -!- sellout [~greg@c-24-61-13-161.hsd1.ma.comcast.net] has quit [Read error: Connection reset by peer] 14:46:25 -!- sellout- is now known as sellout 14:51:45 -!- Modius [~Modius@cpe-70-123-158-125.austin.res.rr.com] has quit [Quit: "Object-oriented design" is an oxymoron] 14:55:30 Xach [~xach@pdpc/supporter/professional/xach] has joined #ccl 14:56:09 Hi, ccl friends. Is there a version of 1.5 that has working ~ behavior on windows, or is it only in 1.6 and beyond? 15:06:18 e-user: maybe Gentoo. 15:08:39 xach: I don't think so, and ~ is also used by Windows to indicate that a longer pathname has been truncated to 8.3 format. I don't know if that conflicts with the ~/file-in-home-dir usage, and would be shocked if anyone wants to deal with 8.3 pathnames, but ... 15:08:55 gybers: indeed, but it's still pre-ccl (openmcl-0.14.2) 15:09:31 gbyers: Ok, thanks. 15:11:20 http://www.gentooportage.info/portage/dev-lisp/clozurecl.html 15:11:55 gbyers: ah, searched for "ccl" and "openmcl" but not "clozurecl", thanks 15:13:51 interesting.. they seem to be doing a lot less stuff to build ccl 15:16:58 is [./${CCL_RUNTIME} -n -b -Q -e '(ccl:rebuild-ccl :full t)' -e '(ccl:quit)' || die "Compilation failed"] really equivalent to all the commands described in ccl documentation chapters 3.4 and 3.5? 15:17:23 i.e. does it encompass building the kernel, fasls and a brand new heap image? 15:17:37 -!- Xach [~xach@pdpc/supporter/professional/xach] has left #ccl 15:19:07 (ccl:rebuild-ccl :full t) does indeed rebuild the kernel, compile all sources to fasl, and dump a new image 15:19:28 -!- sellout [~greg@c-24-61-13-161.hsd1.ma.comcast.net] has quit [Ping timeout: 240 seconds] 15:19:54 I usually do it twice, just to ensure that I'm compiling with the latest CCL lisp compiler 15:20:50 I have encountered situations in some Linux distros where the distributed kernel doesn't work, and I have to rebuild the kernel from the Linux command line 15:21:17 billstclair: Nice, thanks for the tip. So you always use the binary-distributed ccl kernel for bootstrapping? 15:21:17 milanj [~milanj_@109-92-123-152.dynamic.isp.telekom.rs] has joined #ccl 15:21:18 But that has been rare 15:21:27 Usually that works 15:21:47 And you HAVE to use the binary distributed heap, of course 15:22:03 We don't have a cross-compilation mechanism, like SBCL 15:22:25 Though we CAN cross-compile for other processors 15:22:38 That's how Gary built the ARM port 15:23:44 I'm not even sure whether I'm allowed to use a prebuilt binary for bootstrapping new ccl releases save from the very first iteration (obviously); Fedora guidelines are very strict. 15:24:33 Well, if they consider the heap image to be a prebuild binary, then you're hosed. It contains code, but isn't executable without the corresponding kernel executable 15:24:59 But you can certainly leave the kernel executable out, and use "make" to build it 15:25:32 That's what my build currently does, actually.. :) 15:25:56 A long time ago (at Digitool), Hazem got a Sun workstation with no C compiler on it. Whoever makes policies that say that you can't use prebuilt binaries should be forced to build GCC on a machine that doesn't have a C compiler installed. 15:25:58 I just realized the (ccl:rebuild-ccl :full t) version requires the pre-built kernel 15:26:10 yes 15:27:16 gbyers: There are exceptions for things like bootstrapping, of course. 15:27:28 cd lisp-kernel/linuxx86??;make 15:27:35 That's exactly what this is. 15:28:07 Where ?? is 32 or 64 15:28:29 Maybe you could try reading my current SPEC file, it's just declarations, sections and bourne shell code: http://akahl.fedorapeople.org/ccl/ccl.spec 15:32:12 You can also do (REBUILD-CCL :CLEAN T); that'll recompile all lisp sources and build a new image, but doesn't update the kernel. 15:33:04 I've always used rebuild-ccl, with :full t, except on Windows machines where I have no C compiler, where I use :clean t 15:33:27 I've never explicitly called xload-level-0 or compile-ccl, and have only used save-application to save my own application executables 15:34:03 gbyers: Running that saves me from doing "(ccl:xload-level-0 :force)", "(ccl:compile-ccl t)" and "(ccl:save-application "%{full_image}")" (using the newly built boot image) as being done now? 15:34:30 sellout [~greg@c-24-61-13-161.hsd1.ma.comcast.net] has joined #ccl 15:34:42 Guidelines require that I *always* build ccl from source completely 15:35:17 Yes; it does the compilation steps, then uses RUN-PROGRAM to run a second copy of the lisp that builds the full image from the bootstrapping image. 15:35:43 Probably using rebuild-ccl to build a new image with the potentially old compiler, then rebuild-ccl again to build a new image with the new compiler. 15:36:38 gbyers: or is the compiler reloaded before compiling all the other source? 15:36:38 Is it possible to use a preinstalled, previously built from source ccl to build a new one for subsequent iterations (i.e. new releases)? 15:37:20 bill: the compiler's usually re-compiled and re-loaded before other things. 15:37:38 gentoo has dev-lisp/clozurecl, versions 1.4 and 1.5 15:38:09 oh, i'm late, nvm 15:38:21 e-user: that's the only way it's ever done. A previous build is used to compile a new build 15:38:22 jdz: np, thanks anyway 15:38:46 Sorta like GCC 15:38:54 e-user: that should work in the release tree within a given version. In the trunk, we try to check in new binaries when changes are hard to bootstrap. 15:39:03 billstclair: To clarify, can I use e.g. a working ccl 1.5 to build ccl 1.6? 15:39:32 Modulo bootstrapping problems, yes. But there are often bootstrapping problems that require downloading a newer image from the CCL web site 15:40:43 Not often for trunk commits, but usually at least a few commits with bootstrapping problems between major dot releases 15:40:48 So I can generally try to use an old version and fall back (how paradox..) to a newer, provided kernel and image. 15:41:41 I suppose, but using the original released 1.5 to build 1.6, or 1.6 to build 1.7 will usually fail 15:46:58 In that case I'll stick to building the kernel from scratch for each new release.. and use the prebuilt heap images as long as no one objects. 15:47:16 (i.e. in order to built new images using the freshly built kernel) 15:47:21 s/built/build/ 15:50:44 Is there any reason not to set *openmcl-revision* like I'm doing now? 15:52:49 If you're tracking a release, no. If you do updates between releases, I'd ideally like to know what svn revision those interim releases correspond to. 15:58:49 Hmm this is problematic, I'm expected not to do svn checkouts without purging .svn metadata before building the uploaded tarball, but this is required here in order to determine the revision during build time, right? 16:02:32 E.g. ccl, as built from the SPEC file, reports itself as 1.5-3.fc14; this is even more accurate than any build revision as the release (-3) tells which patches and other distro-specific are contained. I just want to know whether anything else reads the variable and expects and integer or "exported" which is IIRC the only other default value. 16:02:37 Yes, to generate it automatically. I just mean that it'd be good to know that Fedora release x.y.z corresponds to a given svn revision; if someone reports a bug in the Fedora release, it'd be good to be able to map that to the svn revision. Just mentioning "built from svn revision N" in the release notes would be fine. 16:03:44 Perfect, the guidelines demand that self-build tarballs contain exact built instructions (including VCS revision identifiers) anyway. 16:05:32 Whatever happens, I'm also responsible which is a Good Thing(tm). 16:06:59 Would you mind tooting your horn a bit as soon as ccl is officially part of Fedora? The distribution could use more Lispers. 16:07:27 And installing ccl couldn't be easier for any user :) 16:20:56 anRch [~markmilli@64.134.66.194] has joined #ccl 16:39:35 -!- leo2007 [~leo@cpc1-cmbg13-0-0-cust596.5-4.cable.virginmedia.com] has quit [Quit: rcirc on GNU Emacs 23.2.20] 16:40:01 leo2007 [~leo@cpc1-cmbg13-0-0-cust596.5-4.cable.virginmedia.com] has joined #ccl 16:57:08 -!- jdz [~jdz@193.206.22.97] has quit [Ping timeout: 240 seconds] 17:13:38 -!- anRch [~markmilli@64.134.66.194] has quit [Quit: anRch] 17:22:34 anRch [~markmilli@64.134.66.194] has joined #ccl 17:27:41 -!- milanj [~milanj_@109-92-123-152.dynamic.isp.telekom.rs] has quit [Ping timeout: 264 seconds] 17:32:30 milanj [~milanj_@178-223-153-138.dynamic.isp.telekom.rs] has joined #ccl 17:35:19 Modius [~Modius@cpe-70-123-158-125.austin.res.rr.com] has joined #ccl 17:58:44 -!- anRch [~markmilli@64.134.66.194] has quit [Ping timeout: 255 seconds] 18:50:58 Genosh [~Genosh@133.Red-81-33-93.dynamicIP.rima-tde.net] has joined #ccl 18:52:03 Hi. 18:52:57 I'm wondering whether this could be a bug or expected behaviour: 18:53:08 ? `(2 ,. (+ 2 3)) 18:53:08 (2 . 5) 18:54:34 And: 18:54:40 ? `(2 . (,+ 2 3)) 18:54:40 (2 NIL 2 3) 18:54:40 ? `(2 . (,+ 2 3)) 18:54:40 (2 (LIST* 2 (LIST* + '(2 3))) 2 3) 19:00:31 anRch [~markmilli@64.134.241.38] has joined #ccl 19:05:27 Genosh: That's expected behavior. 19:05:51 Genosh: http://www.lispworks.com/documentation/HyperSpec/Body/v_pl_plp.htm 19:07:47 `(2 . (,+ 2 3)) = `(2 ,+ 2 3) and + = (list* 2 (list* + '(2 3))) from the previous evaluation 19:08:28 Thank you. :) 19:12:22 -!- Genosh [~Genosh@133.Red-81-33-93.dynamicIP.rima-tde.net] has left #ccl 19:59:50 oconnore [~eric@wsip-70-168-242-70.mc.at.cox.net] has joined #ccl 20:48:59 -!- anRch [~markmilli@64.134.241.38] has quit [Quit: anRch] 20:54:05 eitpwd 20:54:07 ack 21:05:40 -!- milanj [~milanj_@178-223-153-138.dynamic.isp.telekom.rs] has quit [Ping timeout: 250 seconds] 21:24:54 -!- e-user [~e-user@port-87-234-24-237.static.qsc.de] has quit [Quit: Leaving.] 21:27:06 -!- oconnore [~eric@wsip-70-168-242-70.mc.at.cox.net] has quit []