00:14:48 -!- drewc [~user@S01060013101b6ddb.vc.shawcable.net] has quit [Ping timeout: 272 seconds] 00:39:56 The_Jon_Smith [~The_Jon_S@ip24-250-13-137.ri.ri.cox.net] has joined #sbcl 00:47:06 -!- The_Jon_Smith [~The_Jon_S@ip24-250-13-137.ri.ri.cox.net] has quit [Ping timeout: 272 seconds] 01:04:38 tcr [~tcr@81-233-246-97-no37.tbcn.telia.com] has joined #sbcl 01:17:33 -!- tcr [~tcr@81-233-246-97-no37.tbcn.telia.com] has quit [Quit: Leaving.] 02:02:35 -!- nyef [~nyef@pool-71-255-129-229.cncdnh.east.myfairpoint.net] has quit [Quit: G'night all.] 02:34:59 hargettp [~anonymous@pool-71-184-181-149.bstnma.east.verizon.net] has joined #sbcl 02:37:23 -!- hargettp [~anonymous@pool-71-184-181-149.bstnma.east.verizon.net] has quit [Client Quit] 02:43:06 The_Jon_Smith [~The_Jon_S@ip24-250-13-137.ri.ri.cox.net] has joined #sbcl 02:47:55 -!- The_Jon_Smith [~The_Jon_S@ip24-250-13-137.ri.ri.cox.net] has quit [Ping timeout: 272 seconds] 03:12:38 -!- stassats` [~stassats@wikipedia/stassats] has quit [Ping timeout: 245 seconds] 03:29:34 -!- froydnj [~froydnj@gateway.codesourcery.com] has quit [*.net *.split] 03:29:34 -!- joshe [~joshe@opal.elsasser.org] has quit [*.net *.split] 03:38:39 froydnj [~froydnj@gateway.codesourcery.com] has joined #sbcl 03:38:40 joshe [~joshe@opal.elsasser.org] has joined #sbcl 04:09:32 The_Jon_Smith [~The_Jon_S@ip24-250-13-137.ri.ri.cox.net] has joined #sbcl 04:09:57 not sure if this went through: if I do run-tests.sh in sbcl, and get an 'unexpected success' does it mean I am very lucky, or does it mean i broke something? 04:10:12 it was in consing-hash-tables 04:14:44 -!- cmm [~cmm@bzq-79-181-203-193.red.bezeqint.net] has quit [Ping timeout: 276 seconds] 04:15:04 cmm [~cmm@bzq-79-181-203-193.red.bezeqint.net] has joined #sbcl 04:15:52 Unexpected success: dynamic-extent.impure.lisp / (NO-CONSING HASH-TABLES) 05:04:29 <_3b`> The_Jon_Smith: bug in the test, fixed already i think 05:09:10 lnostdal [~quassel@56.84-48-233.nextgentel.com] has joined #sbcl 05:10:11 -!- lnostdal_ [~quassel@56.84-48-233.nextgentel.com] has quit [Ping timeout: 276 seconds] 05:16:00 oh ok cool 05:16:29 in that case, i have peephole optimized successfully :-) 05:17:18 but now i need to sleep 05:28:48 -!- The_Jon_Smith [~The_Jon_S@ip24-250-13-137.ri.ri.cox.net] has left #sbcl 05:56:30 rbarraud__ [~rbarraud@118-93-183-153.dsl.dyn.ihug.co.nz] has joined #sbcl 06:00:53 -!- rbarraud_ [~rbarraud@118-93-183-153.dsl.dyn.ihug.co.nz] has quit [Ping timeout: 276 seconds] 06:02:50 -!- rbarraud__ [~rbarraud@118-93-183-153.dsl.dyn.ihug.co.nz] has quit [Ping timeout: 276 seconds] 06:49:56 poet [~tim@unaffiliated/poet] has joined #sbcl 06:53:58 nikodemus [~nikodemus@cs181199216.pp.htv.fi] has joined #sbcl 06:54:03 -!- ChanServ has set mode +o nikodemus 06:57:08 morning 06:57:30 morning 06:57:45 cold-fset is magical if and only if it happens at toplevel 06:57:46 it is the way that functions exist immediately at the start of cold-sbcl.core's initial function 06:59:13 cold-fset remains at top-level 07:01:00 hm 07:01:04 http://paste.lisp.org/display/114180 # is the expansion i'm trying to get to build 07:01:46 and what's the cold-init error? 07:07:12 hi. are the most recent versions of SBCL tested on OS X (or do the OS X versions lage behind Linux because of a lack of testers)? 07:10:46 Krystof: trying to call :SYMBOL's function -- the macro doesn't get expanded 07:11:54 poet: i build regularly on OS X, albeit on Leopard, not Snow Leopard. also, threads are not really stable on OS X -- good enough for casual work, but i would not run a threaded server on OS X 07:14:00 nikodemus: ok, thanks 07:25:21 nikodemus: hm. Odd. Should work. 07:25:34 is it failing in cold-init, or at the end of host-1? 07:30:05 -!- poet [~tim@unaffiliated/poet] has quit [Quit: Lost terminal] 07:30:30 cold-init 07:31:14 huh 07:31:48 actually, if it gets *never* expanded if it is a def!macro 07:33:09 ur doin somethin wrong 07:33:12 but I don't know what 07:33:40 rbarraud__ [~rbarraud@118-92-14-238.dsl.dyn.ihug.co.nz] has joined #sbcl 07:35:01 aha: ("src/code/early-package" :not-host) 07:37:34 yes, but 07:38:59 there's also src/code/cross-misc 07:39:04 anyway, try harder 08:08:54 since xc has the cross-macro, and early-package.lisp is not build on host at all, def!macro is clearly wrong for this (unless i rearrange things more, at least) 08:10:18 -!- lnostdal [~quassel@56.84-48-233.nextgentel.com] has quit [Ping timeout: 258 seconds] 08:10:24 s/on host/for host/ 08:10:42 more coffee 08:11:27 def!macro is indeed clearly wrong 08:11:37 OK, I need to pretend to work 08:11:45 no, wait: actually work 08:11:55 hah 08:18:21 my new favorite sbcl hacking trick: (when (string= 'something-im-interested-in ) (break)) 08:48:15 tcr [~tcr@81-233-246-97-no37.tbcn.telia.com] has joined #sbcl 09:04:35 -!- cmm [~cmm@bzq-79-181-203-193.red.bezeqint.net] has quit [Ping timeout: 260 seconds] 09:05:16 cmm [~cmm@bzq-79-181-203-193.red.bezeqint.net] has joined #sbcl 09:53:59 this is most annoying 09:55:09 i think i solved my build problem, but i also think the change that caused the problem was bogus in the first place 10:09:11 -!- rbarraud__ [~rbarraud@118-92-14-238.dsl.dyn.ihug.co.nz] has quit [Ping timeout: 276 seconds] 10:44:28 attila_lendvai [~attila_le@4d6f5d3b.adsl.enternet.hu] has joined #sbcl 10:54:20 hargettp [~anonymous@pool-71-184-181-149.bstnma.east.verizon.net] has joined #sbcl 11:08:08 -!- hargettp [~anonymous@pool-71-184-181-149.bstnma.east.verizon.net] has quit [Quit: hargettp] 11:11:07 hargettp [~anonymous@pool-71-184-181-149.bstnma.east.verizon.net] has joined #sbcl 11:59:04 froydnj: If you use "Bug #nnnnnnn" in a launchpad entry, it will automatically cross-link. 12:12:04 tcr: I thought there was some xref facility, but I didn't know exactly what it was. thanks for fixing 12:23:12 No problem. I'm interested in getting to know how to achieve 
 and I'd be fully satisfied with launchpad :-)
12:25:00  report a bug against launchpad
12:25:58  i have one that is effectively the same (about collapsing inline whitespace) -- but i decided against asking for pre and complained about a specific issue instead
12:46:47 -!- hargettp [~anonymous@pool-71-184-181-149.bstnma.east.verizon.net] has quit [Quit: hargettp]
12:47:37 -!- cmm [~cmm@bzq-79-181-203-193.red.bezeqint.net] has quit [Ping timeout: 252 seconds]
12:48:27 cmm [~cmm@bzq-79-181-203-193.red.bezeqint.net] has joined #sbcl
12:50:55 hargettp [~anonymous@pool-71-184-181-149.bstnma.east.verizon.net] has joined #sbcl
13:04:32 -!- cmm [~cmm@bzq-79-181-203-193.red.bezeqint.net] has quit [Ping timeout: 276 seconds]
13:05:12 cmm [~cmm@bzq-79-181-203-193.red.bezeqint.net] has joined #sbcl
13:14:26 -!- cmm [~cmm@bzq-79-181-203-193.red.bezeqint.net] has quit [Ping timeout: 272 seconds]
13:14:55 cmm [~cmm@bzq-79-181-203-193.red.bezeqint.net] has joined #sbcl
13:22:16 nyef [~nyef@pool-71-255-129-229.cncdnh.east.myfairpoint.net] has joined #sbcl
13:22:28  G'morning all.
13:25:43  good morning nyef
13:25:55 -!- cmm [~cmm@bzq-79-181-203-193.red.bezeqint.net] has quit [Ping timeout: 260 seconds]
13:26:38 cmm [~cmm@bzq-79-181-203-193.red.bezeqint.net] has joined #sbcl
13:29:21  Hrm. Raw slot ref/set VOP refactoring, huh?
13:31:18  Tediousity reduction proposal: Throw a build-time feature on it, do it for the machines you have access to, and allow people with access to other machines to fix what they can.  This will probably leave HPPA, Alpha, and possibly MIPS and SPARC out in the cold, but should still do some good, won't it?
13:35:43  yeah, that's the lazy way to do it
13:35:52  I could probably do mips and sparc if I had to
13:36:17  ... Do we expect the MIPS build to work on 2.4?
13:36:27  on the one hand, I wouldn't want half-done refactorings scattered all over the backend
13:36:51  OTOH, some cleanups would be very nice and waiting until every backend is modified means that nothing's going to get done
13:37:11  Right. I mean, look at the state of, say, atomic-incf support.
13:37:15  Or compare-and-swap.
13:37:28  yeah
13:38:05  Or any of the dynamic-extent things.
13:40:33  mips on 2.4 kernel?  I don't know...probably?
13:41:09  Mmm. Didn't work too well the last time I tried it, but I didn't try too hard to debug it, either.
13:41:32  I think partly because I didn't want to risk breaking it on any of the systems that it might currently work on.
13:48:26  Heh. A version of grep that sorts its output by build order. Neat.
13:49:04  with options to put all the :not-target stuff first
13:49:34 stassats` [~stassats@wikipedia/stassats] has joined #sbcl
13:50:26  Krystof: do you think you have time to read my backtrace email on sbcl-devel this week, and say if you hate the idea?
13:51:26  I should have a bit of time this weekend
13:51:40  ... It's not a long weekend for you guys, is it?
13:53:14  nope
14:59:48 -!- Krystof [~csr21@cpc1-bour2-0-0-cust414.15-1.cable.virginmedia.com] has quit [Ping timeout: 265 seconds]
15:04:08 angavrilov_ [~angavrilo@217.71.227.181] has joined #sbcl
15:05:18 -!- deepfire [~deepfire@80.92.100.69] has quit [Ping timeout: 276 seconds]
15:05:19 -!- angavrilov [~angavrilo@217.71.227.181] has quit [Read error: Connection reset by peer]
15:07:05 -!- hargettp [~anonymous@pool-71-184-181-149.bstnma.east.verizon.net] has quit [Quit: hargettp]
15:10:48 hargettp [~anonymous@pool-71-184-181-149.bstnma.east.verizon.net] has joined #sbcl
15:52:53 -!- nikodemus [~nikodemus@cs181199216.pp.htv.fi] has quit [Quit: This computer has gone to sleep]
16:10:49 attila_lendvai1 [~attila_le@4d6f5d3b.adsl.enternet.hu] has joined #sbcl
16:10:49 -!- attila_lendvai [~attila_le@4d6f5d3b.adsl.enternet.hu] has quit [Disconnected by services]
16:10:52 -!- attila_lendvai1 is now known as attila_lendvai
16:18:39 nikodemus [~nikodemus@cs181199216.pp.htv.fi] has joined #sbcl
16:18:39 -!- ChanServ has set mode +o nikodemus
16:22:33  wait does SBCL close FDs for garbaged collected fd streams??
16:22:51  that would be news to me but it seems that's what I'm seeing
16:23:11  I believe it always has
16:24:03  Why?
16:24:41  why not?
16:25:08  it sweeps fd leakage problems under the carpet, only make them appear on fullmoon and high load
16:28:48  I'm trying to find the bit in the sources where it closes streams, not lucky so far, any pointer?
16:30:47  grepping for finalize in fd-streams.lisp helped
16:31:20  you can build with sb-show to get a warning
16:32:48  how useful
16:33:56  do you want crashing?
16:34:41  I think a warning is reasonable, but enabling sb-show is not a useful suggestion :-)
16:35:04  well, you can remove #+sb-show
16:35:25  not easy to do on a server without sbcl sources
16:35:39  monkey patching!
16:36:04  anyway I'll file a bug for this, I think it should print always warning, possibly disable via a special
16:36:22  my grammar is as bad as my mood :-)
16:59:58 deepfire [~deepfire@80.92.100.69] has joined #sbcl
17:00:41 -!- attila_lendvai [~attila_le@4d6f5d3b.adsl.enternet.hu] has quit [Quit: Leaving.]
17:24:13  tcr: if the fd-stream is created with :auto-close t, then a finalizer will close the fd if necessary
17:25:03  don't remember if :auto-close is the default or not for file-streams, but MAKE-SOCKET-STREAM can use it if the user wants
18:16:47 -!- cmm [~cmm@bzq-79-181-203-193.red.bezeqint.net] has quit [Ping timeout: 240 seconds]
18:17:59 cmm [~cmm@bzq-79-181-203-193.red.bezeqint.net] has joined #sbcl
18:41:42 drewc [~user@S01060014bff6e985.vn.shawcable.net] has joined #sbcl
18:53:53 Fare [~Fare@ita4fw1.itasoftware.com] has joined #sbcl
18:57:05  hum. Our application seems to create two pairs of pipes each time a thread is created, 3 fds of which are never freed. Same application doesn't do any such thing with CCL. Is there a mechanism in SBCL that creates those pipes, or is it something in a library we use (or the application itself)?
18:59:44 *nyef* doesn't remember seeing anything involving pipes in the thread-creation path.
19:00:36  Doesn't mean there isn't anything, just that either I didn't notice it or it wasn't in the parts of the path I last messed with.
19:01:04  ok. I'll try to trace with something less stupid than strace.
19:01:36  it would be interesting to have a tool that dumped stack frames when some event happen other than a timer event.
19:02:05  nyef, if someday you do that "lisp in a remote process" seriously, I think I want to work on that.
19:02:24  The ptrace-debugger thing?
19:02:34  yes
19:02:41  Fair enough.
19:02:49  not just debugger - the whole compiler that way.
19:02:58  ... though, I rather suspect that it'll need to mask SIGCHLD...
19:03:20  what will?
19:03:26  The ptrace interface.
19:03:32  is that a problem?
19:03:52  Not now that we've figured out how to do it without the runtime pitching a fit, no.
19:04:09  Fare: what sort of event?
19:05:43  fwiw, modulo GC, you can use C stuff that assumes frame-pointers (e.g. linux perf)
19:05:54  like, a syscall being called, a variable being modified
19:06:28  Actually, the main issues that I'm aware of with the external-process lisp stuff are maintaining common-lisp compatibility and sorting out build-time vs. load-time vs. run-time dependencies.
19:06:34  "I want to know what chain of calls causes this variable to go wrong"
19:07:16  "where wrong is defined as (lambda (...) ...)..."
19:12:38 -!- nikodemus [~nikodemus@cs181199216.pp.htv.fi] has quit [Quit: This computer has gone to sleep]
19:12:38  nikodemus: OPEN passes :auto-close t to make-fd-stream, so it seems
19:13:08  How about adding :auto-close :warn, and making that the default for open?
19:14:29  Bah I thought OPEN is explicitly allowed to take additional keyword parameters, but a quick searching through its clhs did not reveal such a passage
19:15:54  tcr: Might be section 1.6, plus the definition of "conforming program".
19:19:08  nyef: 3.5.1.4 says an error of type program error must be signalled in case of an unrecognized keyword argument in a safe call site
19:19:49  Hrm. Is there some leeway in terms of having a standard function recognizing additional keyword arguments?
19:20:20  now my take on the issue is pretty liberal, extend where reasonable, but I Xof was a bit more weary about back when briefly talked about it in persona
19:20:38  nyef: some entries explicitly allow for it, e.g. defpackage
19:20:45  Ah, damn.
19:22:21  I mean where does it matter? In case you apply OPEN to a user specified list, in which case allowing the extensions is actually a good thing
19:29:22  I wish people would get around to writing profiling tools that worked without frame pointers.
19:29:44  especially now that gcc is gonna default to -fomit-frame-pointer on x86 32 in the next version too.
19:31:02  It'd probably be nice if SBCL could backtrace foreign frames without frame pointers as well.
19:35:07  ... Oh, neat. My main system seems to gain two "phy"s per suspend. Something to do with the wireless device, it seems.
19:35:37 -!- tcr [~tcr@81-233-246-97-no37.tbcn.telia.com] has quit [Read error: Operation timed out]
19:35:45  nyef, you seem to be particularly unlucky.. what hardware?
19:36:02 tcr [~tcr@81-233-246-97-no37.tbcn.telia.com] has joined #sbcl
19:36:34  nyef: heh, I had my external usb drive mounted 15 times according to mount
19:37:12  foom: I'll blame gcc's (and x86-64's) default, frankly. frame pointers seem much more robust than any dwarf-like logic.
19:37:50  deepfire: PowerMac7,2 with an rt73usb wifi device... At least, I -think- it's an rt73usb.
19:38:55  pkhuong_: foom: fortunately, switching the defaults will make the profiler writers move that much faster 
19:39:54  heh. The frame pointer choice seems conscious for linux perf. I don't think I'd want a DWARF VM inside the kernel either (:
19:40:37  I just hope the distros compile libraries, at least, with -fno-omit-frame-pointer so that users can get decent profiler if they need to
19:40:53 *froydnj* thought the switch was a poor decision on upstream's behalf
19:40:58  froydnj: the debug versions, at least.
19:41:12  frame pointers on stripped binaries isn't that useful.
19:41:25  pkhuong_: I belive there's already one there
19:41:40  there aren't generally debug versions anymore
19:41:45  just debug symbols files
19:42:47  foom: you think there's a dwarf implementation in my kernel? :|
19:43:08  only if your kernel is linux
19:43:37  pkhuong_, why would you need a dwarf vm in the kernel?
19:43:50  Fare: for backtraces.
19:44:09  uh - why would it need be in the kernel? for oopsen?
19:44:11  "but why would you need to record backtraces in the kernel"
19:44:21  to get backtraces of user processes for things like perf, systemtap, etcetc.
19:44:47  can't they be had either by the process itself or a ptrace'ing master?
19:45:02  Fare: introduce noise and more overhead.
19:45:20  more so than with the 'preter in the kernel?
19:45:27  yes
19:45:28  Doing it in the kernel minimises context switches, and lets us play with profiling masks more easily.
19:46:22  if you want to read some stuff, http://lwn.net/Articles/379949/
19:46:33  the whole thread is pretty interesting
19:47:12 -!- drewc [~user@S01060014bff6e985.vn.shawcable.net] has quit [Ping timeout: 258 seconds]
19:47:14  foom: perf's syscall interface is fairly simple.
19:47:21  pkhuong_: I know, using it now
19:47:33  (pretty slow, too, though)
19:47:44  ah, so you worked your way around the poor callgraph output format (:
19:47:59  foom: with the mmapped region?
19:48:19  no, the simple interface
19:48:21  the read
19:49:36 -!- christoph_debian [christoph@sf-ogame.de] has quit [Read error: Connection reset by peer]
19:57:45 nikodemus [~nikodemus@cs181199216.pp.htv.fi] has joined #sbcl
19:57:45 -!- ChanServ has set mode +o nikodemus
20:00:56  foom: so, iiuc, libunwind would solve our backtracing woes?
20:03:20  pkhuong_: yea, libunwind seems to work great.
20:04:36  you need context switches because you can't simply mmap the whole child process in the master?
20:04:37 Krystof [~csr21@84-51-132-95.christ977.adsl.metronet.co.uk] has joined #sbcl
20:04:37 -!- ChanServ has set mode +o Krystof
20:05:11  Fare: you need context switches because profiling events are caught by the kernel first.
20:15:30  http://cgit.freedesktop.org/cairo/tree/src/cairo-tor-scan-converter.c#n1185 <- interesting list mergesort.
20:17:36  Hrm. Dies on the seventh or eighth hibernate normally, but just did ten with the wireless card removed.
20:19:50  pkhuong_: very nice
20:25:11 -!- nikodemus [~nikodemus@cs181199216.pp.htv.fi] has quit [Quit: Leaving]
20:30:25 -!- hargettp [~anonymous@pool-71-184-181-149.bstnma.east.verizon.net] has quit [Quit: hargettp]
20:39:43 lnostdal [~quassel@56.84-48-233.nextgentel.com] has joined #sbcl
21:02:07 -!- cmm [~cmm@bzq-79-181-203-193.red.bezeqint.net] has quit [Ping timeout: 240 seconds]
21:03:14 cmm [~cmm@bzq-79-181-203-193.red.bezeqint.net] has joined #sbcl
22:03:19 -!- Fare [~Fare@ita4fw1.itasoftware.com] has quit [Quit: Leaving]
23:15:45 -!- tcr [~tcr@81-233-246-97-no37.tbcn.telia.com] has quit [Quit: Leaving.]
23:33:41 -!- nyef [~nyef@pool-71-255-129-229.cncdnh.east.myfairpoint.net] has quit [Quit: G'night all.]