00:07:20 -!- homie [~levgue@xdsl-78-35-148-60.netcologne.de] has quit [Read error: Connection reset by peer] 00:10:58 -!- LiamH [~healy@pool-108-18-166-81.washdc.east.verizon.net] has quit [Quit: Leaving.] 00:16:49 -!- Iceland_jack [~baldur@earth.sudo.is] has quit [Ping timeout: 258 seconds] 00:17:50 homie [~levgue@xdsl-78-35-148-60.netcologne.de] has joined #sbcl 01:12:32 akovalenko [~user@95.72.169.53] has joined #sbcl 01:13:36 -!- homie [~levgue@xdsl-78-35-148-60.netcologne.de] has quit [Read error: Connection reset by peer] 01:14:51 homie [~levgue@xdsl-78-35-148-60.netcologne.de] has joined #sbcl 01:19:34 -!- homie [~levgue@xdsl-78-35-148-60.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 01:23:01 homie [~levgue@xdsl-78-35-148-60.netcologne.de] has joined #sbcl 01:26:34 -!- |3b|` [foobar@cpe-72-179-19-4.austin.res.rr.com] has quit [Read error: Connection reset by peer] 01:27:37 |3b|` [foobar@cpe-72-179-19-4.austin.res.rr.com] has joined #sbcl 01:45:36 -!- antifuchs [~foobar@2001:470:1f15:1c54::fade:1] has quit [Read error: Connection reset by peer] 01:52:48 antifuchs [~foobar@care.boinkor.net] has joined #sbcl 02:04:45 -!- |3b|` is now known as |3b| 02:14:24 LiamH [~healy@pool-108-18-166-81.washdc.east.verizon.net] has joined #sbcl 04:14:20 -!- LiamH [~healy@pool-108-18-166-81.washdc.east.verizon.net] has quit [Quit: Leaving.] 04:39:20 -!- antgreen [~user@bas3-toronto06-1177889870.dsl.bell.ca] has quit [Ping timeout: 260 seconds] 04:44:39 Phoodus [~foo@63-235-81-162.dia.static.qwest.net] has joined #sbcl 04:47:04 -!- akovalenko [~user@95.72.169.53] has quit [Ping timeout: 240 seconds] 05:39:27 akovalen` [~anton@95.73.52.175] has joined #sbcl 05:39:58 -!- akovalen` is now known as akovalenko` 05:40:21 udzinari [~user@ip-89-102-12-6.net.upcbroadband.cz] has joined #sbcl 05:46:32 udzinari` [~user@ip-89-102-12-6.net.upcbroadband.cz] has joined #sbcl 05:48:24 -!- akovalenko` is now known as akovalenko 05:49:07 -!- udzinari` [~user@ip-89-102-12-6.net.upcbroadband.cz] has quit [Remote host closed the connection] 05:49:25 -!- udzinari [~user@ip-89-102-12-6.net.upcbroadband.cz] has quit [Ping timeout: 240 seconds] 05:56:21 -!- akovalenko [~anton@95.73.52.175] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 06:04:00 akovalenko [~akovalenk@95.73.52.175] has joined #sbcl 06:09:09 angavrilov [~angavrilo@217.71.227.181] has joined #sbcl 07:50:02 -!- Phoodus [~foo@63-235-81-162.dia.static.qwest.net] has quit [Ping timeout: 245 seconds] 09:50:38 homie` [~levgue@xdsl-78-35-137-217.netcologne.de] has joined #sbcl 09:53:19 -!- homie [~levgue@xdsl-78-35-148-60.netcologne.de] has quit [Ping timeout: 248 seconds] 10:02:37 attila_lendvai [~attila_le@87.247.46.34] has joined #sbcl 10:02:37 -!- attila_lendvai [~attila_le@87.247.46.34] has quit [Changing host] 10:02:37 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 10:34:35 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 252 seconds] 10:38:17 -!- deepfire [~deepfire@80.92.100.69] has quit [Quit: ircII EPIC4-2.10.1 -- Are we there yet?] 10:59:13 nikodemus [~nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 10:59:13 -!- ChanServ has set mode +o nikodemus 11:12:21 deepfire [~deepfire@80.92.100.69] has joined #sbcl 11:17:34 morning 11:19:39 5% of dynamic space size == 400Mb default on typical 64-bit sbcl.. 11:25:58 akovalenko: yeap 11:31:47 nikodemus: thanks for making a decision about long => os-vm-size-t. Finally! 11:32:52 akovalenko: i admit to dragging my feet because i felt that i wasn't the best person to make that decision. my what's-right-for-C instinct isn't the sharpest there is 11:32:54 btw, are there SBCL targets without %z... and %t.. printf width formats? (except windows -- but modern mingw can provide its own printf even there). 11:33:06 don't know 11:34:01 but C does have string catenation, so we could do printf("foo: " OS_VM_SIZE_FTM " bytes", x) 11:35:01 at least on openbsd os_vm_size_t != size_t, though i'm not sure if the actual size differs 11:35:23 openbsd people seem to believe in having a lot of typedefs... 11:35:57 morning 11:36:16 deepfire_ [~deepfire@80.92.100.69] has joined #sbcl 11:36:29 -!- deepfire_ [~deepfire@80.92.100.69] has quit [Client Quit] 11:36:29 oh, and another thing: winsock's gethostbyname buffer is thread-local 11:36:53 akovalenko: if you send a patch that removes the lock for windows, i'll merge it 11:38:59 and I suspect run-program on windows is now broken 11:39:05 yikes 11:39:10 that's not good 11:39:30 i tried to think about windows when i merged that, but ... 11:40:15 I'll need to look closer at the mainline code to be sure, but iirc, spawn() returns /result code/ instead of a process handle for :wait t case (P_WAIT flag) 11:40:41 and return code can be zero without being an error. 11:42:30 in the mainline it's hProcess = (HANDLE) spawnvp ( wait_mode, program, argv ); / hProcess = (HANDLE) spawnv ( wait_mode, program, argv ); 11:42:34 which is returned 11:47:42 can that be zero? 11:47:57 *nikodemus* googles 11:48:36 hReturn = hProcess 11:48:40 exit status, yeah 11:49:13 i'll #-win32 the (0 (error ...)) leg 11:49:30 and plusp => (> .. 0) 11:49:35 er, >= 11:51:11 what if i just make the exec-error code -2 instead of zero? 11:52:02 can that get confused with something else? 11:52:22 looks fine. 12:16:30 -!- loke [~elias@bb115-66-85-121.singnet.com.sg] has quit [Quit: Leaving] 12:23:21 pushed 12:44:07 attila_lendvai [~attila_le@87.247.56.161] has joined #sbcl 12:44:07 -!- attila_lendvai [~attila_le@87.247.56.161] has quit [Changing host] 12:44:07 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 12:46:04 Kryztof: if you don't have anything in your review-queue, can you take https://bugs.launchpad.net/sbcl/+bug/741564 ? 12:48:05 which is not to say i needs to be done on any particular schedule -- i just think you and paul are the two people most qualified to review it 12:51:05 "queue" 12:51:07 OK 12:51:58 thanks 12:52:33 hey, if a queue as 1 slot, it's even more important to keep it filled :) 12:54:11 well it's either a 1-slot queue or a randomized heap 12:54:20 unbounded heap 13:01:39 do you have a stand on using cmucl-style syntax for readably printing stuff -- #A( ) ? 13:05:21 i want to support readably printing specialized arrays, but mislike forcing *read-eval* on people 13:06:34 I somewhat think I would prefer to use stuff reserved for the implementation 13:06:46 you mean ~? 13:08:07 clhs: 2.1.4 13:08:50 either ~ or one of the undefined but not asterisked things in # 13:10:26 well, maybe I could be persuaded to go with otherwise-undefined syntax in #a 13:12:08 #"foo" for base strings... ooh 13:12:24 i never realized the unasterisked ones were ALL OURS 13:12:36 *nikodemus* goes nuts 13:13:02 :-) 13:13:08 a positive contribution. Go me. 13:13:54 of course sometime in the 2050s we can drop support for non-Unicode builds and use any number of the (expt 2 21) characters we like for specialized arrays 13:13:57 seriously speaking, if we start using unportable printing, should we add *print-portably*? 13:14:17 and default it to T, just to annoy everyone? :-) 13:14:37 haha 13:15:02 with a reference condition on PRINT-NOT-READABLEs that would have worked if it was NIL 13:15:04 I quite like that 13:15:44 wait, let me actually finish doing this "git am" thing that is in the middle of conflicts before I forget what I'm doing 13:18:55 so, srsly, what should the default be? I think *print-portably* is excellent; how far can my philosophy of "educate the ignorant" be maintained? 13:21:37 not sure 13:22:14 there's also the issue of how aggressively to use it 13:22:42 for example, i'd dearly like readably printed arrays in the repl, but # is still ok there 13:23:42 so, maybe default to T, but when NIL use unportable syntax if it allows more accurate representation? 13:24:18 plus provide sb-ext:print-unportably restart for print-not-readable when possible 13:32:17 nikodemus pasted "sketch" at http://paste.lisp.org/display/125983 13:36:03 LiamH [~healy@pool-108-18-166-81.washdc.east.verizon.net] has joined #sbcl 13:36:19 -!- cow-orker [~foobar@pogostick.net] has quit [*.net *.split] 13:36:20 -!- natesm [~pelican@nate.xen.prgmr.com] has quit [*.net *.split] 13:36:25 cow-orker [~foobar@pogostick.net] has joined #sbcl 13:36:30 natesm [~pelican@nate.xen.prgmr.com] has joined #sbcl 13:50:53 bbl 13:50:55 -!- nikodemus [~nikodemus@cs181063174.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 13:52:00 -!- homie` [~levgue@xdsl-78-35-137-217.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 14:03:26 pers [~user@96-25-162-104.gar.clearwire-wmx.net] has joined #sbcl 14:08:39 homie [~levgue@xdsl-78-35-137-217.netcologne.de] has joined #sbcl 14:20:46 udzinari [~user@ip-89-102-12-6.net.upcbroadband.cz] has joined #sbcl 14:25:27 nikodemus` [~nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 14:28:22 nikodemus`: someone is using your nick? you don't have a nickserv account? 14:28:37 my priv msg ended up at him 14:30:21 -!- udzinari [~user@ip-89-102-12-6.net.upcbroadband.cz] has quit [Remote host closed the connection] 14:45:26 hm. i do, and my client used to identify me automatically 14:46:34 -!- ChanServ has set mode +o nikodemus` 14:47:11 -!- nikodemus` is now known as nikodemus 14:49:01 aha, i had it auto-identify, but not ghost 14:51:00 ok, that should do it 14:51:57 -!- nikodemus is now known as nikodemus_ 14:52:09 -!- nikodemus_ is now known as nikodemus` 14:53:43 -!- nikodemus` is now known as nikodemus 14:54:02 -!- nikodemus is now known as nikodemus` 14:54:43 -!- nikodemus` is now known as nikodemus 14:55:10 -!- nikodemus is now known as nikodemus` 14:55:24 -!- nikodemus` is now known as nikodemus 14:55:45 lol 14:56:10 ok, all nicks grouped under the same account now 14:56:32 which client do you use ? 14:56:35 if i may ask 14:56:40 erc ? 14:56:50 or beirc ? 14:57:14 xchat mostly, sometimes erc, sometimes an random ipad or android client 14:57:44 used to use irssi 15:04:16 -!- nikodemus [~nikodemus@cs181063174.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 15:07:49 udzinari [~user@ip-89-102-12-6.net.upcbroadband.cz] has joined #sbcl 15:17:54 loke [~elias@bb115-66-85-121.singnet.com.sg] has joined #sbcl 15:36:48 nikodemus [~nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 15:36:48 -!- ChanServ has set mode +o nikodemus 15:37:53 Blkt [~user@82.84.130.206] has joined #sbcl 15:43:43 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 248 seconds] 15:43:55 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 15:50:26 -!- Blkt [~user@82.84.130.206] has quit [Read error: Connection reset by peer] 15:51:42 sheesh. Never let me drive git. 15:51:58 no wonder I can only cope with one patch a week 15:52:21 *Kryztof* rebuilds, this time with the patch actually applied, not just disappeared into the ether 16:33:54 drdo [~drdo@85.207.54.77.rev.vodafone.pt] has joined #sbcl 16:45:40 -!- udzinari [~user@ip-89-102-12-6.net.upcbroadband.cz] has quit [Remote host closed the connection] 16:48:39 -!- homie [~levgue@xdsl-78-35-137-217.netcologne.de] has quit [Read error: Connection reset by peer] 16:49:41 homie [~levgue@xdsl-78-35-137-217.netcologne.de] has joined #sbcl 16:52:50 -!- homie [~levgue@xdsl-78-35-137-217.netcologne.de] has quit [Client Quit] 16:58:10 homie [~levgue@xdsl-78-35-137-217.netcologne.de] has joined #sbcl 17:03:32 -!- mensch [~mensch@c-98-217-184-95.hsd1.ma.comcast.net] has quit [Quit: leaving] 17:08:05 wait timed out in thread blah, blocked by blah, retrying 60 sec.....? 17:08:15 what maybe the cause ? 17:11:15 -!- angavrilov [~angavrilo@217.71.227.181] has quit [Ping timeout: 260 seconds] 17:11:26 Probably blah. 17:11:58 lol 17:12:05 :) 17:34:01 Phoodus [~foo@63-235-81-162.dia.static.qwest.net] has joined #sbcl 17:39:47 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 244 seconds] 18:10:21 -!- LiamH [~healy@pool-108-18-166-81.washdc.east.verizon.net] has quit [Quit: Leaving.] 18:13:38 -!- nikodemus [~nikodemus@cs181063174.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 18:17:09 Sysop_fb [~bleh@108-66-160-34.lightspeed.spfdmo.sbcglobal.net] has joined #sbcl 18:17:16 -!- Sysop_fb [~bleh@108-66-160-34.lightspeed.spfdmo.sbcglobal.net] has left #sbcl 18:17:41 nikodemus [~nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 18:17:41 -!- ChanServ has set mode +o nikodemus 18:18:23 -!- drdo [~drdo@85.207.54.77.rev.vodafone.pt] has quit [Read error: Connection reset by peer] 18:19:04 drdo [~drdo@85.207.54.77.rev.vodafone.pt] has joined #sbcl 18:22:52 tyson1 [~Ian@CPE0026f3374420-CM0026f337441d.cpe.net.cable.rogers.com] has joined #sbcl 18:26:20 -!- nikodemus [~nikodemus@cs181063174.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 18:26:59 milanj [~milanj_@109-92-103-199.dynamic.isp.telekom.rs] has joined #sbcl 18:34:55 what's the win64-safe 64 bit integer type? 18:35:33 -!- tyson1 [~Ian@CPE0026f3374420-CM0026f337441d.cpe.net.cable.rogers.com] has left #sbcl 18:47:43 how bad of a surprise would it be for (sse-pack *) to be equivalent to (sse-pack integer), and not (sse-pack t)? 19:06:11 -!- homie [~levgue@xdsl-78-35-137-217.netcologne.de] has quit [Read error: Connection reset by peer] 19:07:33 homie [~levgue@xdsl-78-35-137-217.netcologne.de] has joined #sbcl 19:10:31 Kryztof: I'm bitching about the old trivial-features/clx incompatibility over on #quicklisp if you care to join the discussion 19:32:18 LiamH [~healy@pool-108-18-166-81.washdc.east.verizon.net] has joined #sbcl 19:34:02 -!- milanj [~milanj_@109-92-103-199.dynamic.isp.telekom.rs] has quit [Quit: Leaving] 20:01:24 nikodemus [~nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 20:01:24 -!- ChanServ has set mode +o nikodemus 20:22:03 400MB default nursery size does not seem reasonable 20:26:46 is there a reasonable way to estimate the system RAM size? 20:28:48 must be something that would be no uglier than e.g. the os-specific binary path determination code 20:29:08 but I'm not convinced that estimating the nursery size from system ram would be any more valid 20:29:35 less invalid. 20:30:01 fair enough. I don't think it crosses any significant validity threshold :-) 20:30:58 if part of the solution is to make the default heap size smaller, then that's fine 20:32:13 since 8GB was totally arbitrary, chosen on the flawed assumption that nobody would want a 64-bit sbcl unless they needed a larger address space than 32-bit sbcl could provide 20:33:40 or scaling bytes-consed-between-gcs based on the amount of live data after the last gc 20:35:04 -!- sdemarre [~serge@91.176.94.227] has quit [Ping timeout: 240 seconds] 20:41:35 jsnell: do we know for sure that multiple generations are useful? 20:45:30 pkhuong: last time i experimented with cutting the number down, yes 20:47:15 jsnell: it doesn't seem particularly unreasonable to me -- but i admit my perspective may be off 20:47:41 (for an 8Gb heap, that is) 20:47:56 i do also happen to think we could maybe cut down on the heap size 20:48:12 nikodemus: we still have laptops with < 1-2 GB RAM. 20:48:19 right 20:48:38 so default to 1Gb heap on both x86 and x86-64? 20:49:14 and advertise the build-time --dynamic-space-size= option more? 20:50:06 that would be good. It can also be saved in the core, right? 20:50:19 i think so, yes 20:50:20 is there a simple way to track the age and size of deallocated objects? 20:51:02 i don't think so, not unless you're willing to stick a finalizer on everything... 20:51:42 something with generation_average_age, maybe. 20:52:06 not deallocated objects, unless i misunderstand your meaning 20:52:41 we could compare values before and after GCs. 20:53:24 for dynamic scaling of nursery? 20:54:21 no, to try and develop a smarter way to tune the GC. 20:54:25 ah 20:55:02 and to test the generational hypothesis on real workloads. 20:57:01 well, the GC can certainly keep track of the number of bytes that survive/are freed when a generation is collected 20:57:43 not sure if that number is easily available right now, but ... 20:58:31 on other topics, restart names for print-not-readably-error: PRINT-UNREADABLY, PRINT-UNPORTABLY, PRINT-READ-EVALUABLY? 20:58:33 a table of age (in minor GC) -> # bytes would suffice, I guess. 20:59:11 i can't think of good name for "yes, print it so I can read it with *read-eval* t" 20:59:47 PRINT-HASHDOTTELY, PRINT-FOR-READ-EVAL, PRINT-SOMEHOW? 20:59:50 print-sharp-dottedly 20:59:56 (: 21:00:31 ideally it would spell with same number of letter as print-unreadably and print-unportably, but can't have everything... 21:00:50 print-is-readable 21:02:37 print-sharpdotly is the right length, but looks a bit dotty... 21:04:02 What about print-read-as-#. 21:04:17 Right length but not so nice to see. 21:04:26 pkhuong: re. generational hypothesis, did you seem jrm's comments on it and little's law? 21:05:21 yes. That's what made me think I could try and get data to talk to some queueing theory people (... like my father) 21:06:38 print-rereadably 21:07:30 print-arbitrarily 21:07:54 nikodemus: print-sharpdotly fits the char count 21:08:06 it's kind of growing on me, actually 21:43:16 -!- homie [~levgue@xdsl-78-35-137-217.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 21:44:43 hmh 21:45:16 would it be such a terrible thing to use #.(coerce ...) syntax for printing things readably if *read-eval* is nil? 21:45:35 i kind of mislike a reader control variable affecting printing 21:46:33 that is already the case, with *read-default-float-format* 21:46:44 point 21:47:44 but I'm not sure it would be a good idea to add one more 21:54:16 slyrus: thanks, but I've already stormed out of one lisp channel in disgust today 21:54:21 probably best not tempt more fate 21:56:06 besides, you've probably sorted it all out now by taking control of clx 22:14:55 well, i just got a recursive lock attempt on the scheduler lock that caused a memory fault doing load testing in the git head checkout. 22:15:40 but the image is continuing with fingers crossed 22:16:11 *ottergwc* tries to replicate it 22:17:01 ottergwc: what platform? 22:17:22 Linux hiccup 2.6.38-12-generic #51-Ubuntu SMP Wed Sep 28 14:27:32 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux 22:17:58 I just did a git pull and got a few changes, so i'm re-running it anyway. this git pull I last did was yesterday that died 22:18:51 normal futex build? 22:19:14 defaults on the build with the exception of install path 22:23:58 it seems that swank causes instability 22:24:50 or probably exposes it 22:27:28 did you see a backtrace from the recursive lock attempt? 22:27:58 yes, but in swank, not to the error channel 22:28:15 what's the url for the lisp paste site and i'll post it 22:29:25 paste.lisp.org/new/sbcl 22:30:47 ottergwc pasted "swank crash report" at http://paste.lisp.org/display/125991 22:33:47 ottergwc: you first had a memory fault, which in turn caused the recursive lock attempt, i think 22:34:02 that makes sense. the recursive lock was probably in swank's reporting 22:34:03 22: (ERROR SB-SYS:MEMORY-FAULT-ERROR :ADDRESS 0) 22:34:34 This was the fault from the error channel: Memory fault at 0 (pc=(nil), sp=0x7fffe91bedd0) 22:34:56 normally no user code is ever run while holding on o the scheduler lock, but apparetly the memory fault occurred while holding on to it 22:35:27 in load testing i could simply have blown the instance out of memory 22:36:04 but i've seen that and it says someting about heap exahusted game over 22:37:37 this testing is on my laptop using only 33 total threads 22:38:03 do you use lots of timers? 22:38:07 we don't use any 22:38:13 swank probably does though 22:38:22 We run swank as our repl into our running server 22:40:03 i don't see any timer or asynch timeouts in current slime/swank 22:40:30 pop ... hit it again 22:41:12 ottergwc annotated #125991 "hit it again" at http://paste.lisp.org/display/125991#1 22:41:40 different address in the failure too: Memory fault at 0 (pc=(nil), sp=0x7fffeda66dd0) 22:42:35 can you evaluate (sb-impl::%pqueue-contents sb-impl::*schedule*)? 22:42:56 #() 22:43:11 the system is still running, so until it eventually dies, I have slime into it. 22:44:38 what's M-: (slime-changelog-date) ? 22:45:21 (2011-04-16) 22:46:28 No, that's a string "2001-04-16" 22:46:37 No, that's a string "2011-04-16" 22:47:44 aha, that explains /some/ of it at least. 4 days later slime got rid of with-timeout, and replaced it with with-deadline -- which doesn't use asynch interrupts 22:48:22 we can update swank and slime 22:48:28 it still doesn't explain what's trying to deref 0 while holding onto the scheduler lock, but... 22:48:40 we're also not using an native calls 22:49:00 we're pure lisp 22:49:27 no ffi or anything 22:51:16 aside from whatever this bug is sbcl is doing really well 22:52:17 on the four core laptop in a sleep of five seconds we get 5.928 seconds real time, 16.95 seconds cpu time and .820 seconds gc time with 13,603,725,860 processor cycles and 3,113,845,664 bytes consed 22:53:08 woo, I may have figured out that openbsd sb-posix problem 22:53:24 need to read some more kernel code to confirm my suspicions now 22:53:30 the only theory i have right now is that something in the timer code is calling make-alien and not checking it succeeds -- so running out of foreign heap might show up as a memory fault at 0 22:54:05 ottergwc annotated #125991 "untitled" at http://paste.lisp.org/display/125991#2 22:54:07 nikodemus: that doesn't really happen on x86-64. 22:54:08 nikodemus annotated #125991 "you can try this" at http://paste.lisp.org/display/125991#3 22:54:12 (linux) 22:54:20 and maximum error nesting depth exceeded, it just failed again: %PRIMITIVE HALT called; the party is over. 22:54:48 pkhuong: any other reason why malloc could return 0? 22:56:02 ottergwc: i would recommend updating slime at any rate, since it's putting asynch signals into your system 22:56:20 yes, i will certainly do that. 22:56:34 that might help fix the reporting problem in the debugger dump at the least 22:58:39 oops, I guess not 22:59:29 nikodemus: requests for a huge allocation? 23:01:46 pkhuong: yeah. but it seems to happen while inside with-scheduler-lock, which doesn't really do very much -- but has without-interrupts 23:04:49 but this reminds me: it would be good to teach slime not to use its own debugger by default for certain things 23:05:08 like stack-exaustion or memory-faults 23:06:34 time to hit the bed 23:06:39 -!- nikodemus [~nikodemus@cs181063174.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 23:07:11 now i am guilty of nightmares about memory faults