00:01:09 hargettp [~anonymous@pool-71-184-188-218.bstnma.east.verizon.net] has joined #sbcl 00:06:12 mbohun [~mbohun@ppp115-156.static.internode.on.net] has joined #sbcl 00:26:34 -!- rbarraud [~rbarraud@118-92-15-104.dsl.dyn.ihug.co.nz] has quit [Ping timeout: 272 seconds] 00:42:32 rbarraud [~rbarraud@118-92-15-104.dsl.dyn.ihug.co.nz] has joined #sbcl 01:28:35 -!- nyef [~nyef@pool-70-109-134-127.cncdnh.east.myfairpoint.net] has quit [Quit: G'night all.] 01:41:55 -!- Blkt [~user@dynamic-adsl-94-37-238-79.clienti.tiscali.it] has quit [Remote host closed the connection] 01:50:53 -!- hargettp [~anonymous@pool-71-184-188-218.bstnma.east.verizon.net] has quit [Quit: hargettp] 02:31:10 rbarraud_ [~rbarraud@118-92-15-104.dsl.dyn.ihug.co.nz] has joined #sbcl 02:31:55 -!- rbarraud [~rbarraud@118-92-15-104.dsl.dyn.ihug.co.nz] has quit [Ping timeout: 240 seconds] 02:39:44 The_Jon_Smith [~The_Jon_S@ip24-250-13-137.ri.ri.cox.net] has joined #sbcl 02:45:24 tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has joined #sbcl 03:24:03 -!- tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has quit [Quit: Leaving.] 03:33:08 minion: memo for nyef: we can bias stack tn offsets instead 03:33:08 Remembered. I'll tell nyef when he/she/it next speaks. 03:34:07 kclifton [~kclifton@S010600123ff34d7d.cg.shawcable.net] has joined #sbcl 04:03:03 -!- rbarraud_ [~rbarraud@118-92-15-104.dsl.dyn.ihug.co.nz] has quit [Ping timeout: 245 seconds] 04:06:18 -!- drewc [~user@S01060013101b6ddb.vc.shawcable.net] has quit [Ping timeout: 240 seconds] 04:14:54 rbarraud_ [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has joined #sbcl 04:47:06 -!- kclifton [~kclifton@S010600123ff34d7d.cg.shawcable.net] has quit [Quit: kclifton] 05:02:45 -!- mbohun [~mbohun@ppp115-156.static.internode.on.net] has quit [Quit: Leaving] 05:12:50 morganb` [~user@64-238-171-196.cab.apt.gru.net] has joined #sbcl 05:15:02 morganb`` [~user@64-238-171-196.cab.apt.gru.net] has joined #sbcl 05:16:19 -!- morganb [~user@64-238-171-196.cab.apt.gru.net] has quit [Ping timeout: 240 seconds] 05:18:32 -!- morganb` [~user@64-238-171-196.cab.apt.gru.net] has quit [Ping timeout: 272 seconds] 06:30:22 -!- rbarraud_ [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 06:30:42 rbarraud_ [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has joined #sbcl 06:37:27 mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has joined #sbcl 06:37:42 -!- Krystof [~csr21@92.24.94.2] has quit [Ping timeout: 272 seconds] 06:37:43 -!- rbarraud_ [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 06:39:34 rbarraud_ [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has joined #sbcl 06:49:32 Krystof [~csr21@92.24.94.2] has joined #sbcl 06:49:32 -!- ChanServ has set mode +o Krystof 07:06:40 mbohun [~mbohun@ppp115-156.static.internode.on.net] has joined #sbcl 07:18:33 stassats [~stassats@wikipedia/stassats] has joined #sbcl 07:21:41 -!- rbarraud_ [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has quit [Read error: Connection reset by peer] 07:21:58 rbarraud_ [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has joined #sbcl 07:29:25 -!- rbarraud_ [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 07:29:41 rbarraud_ [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has joined #sbcl 07:41:30 -!- rbarraud_ [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 07:41:55 rbarraud_ [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has joined #sbcl 09:08:24 tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has joined #sbcl 09:17:09 nikodemus [~nikodemus@cs181058025.pp.htv.fi] has joined #sbcl 09:17:09 -!- ChanServ has set mode +o nikodemus 09:18:16 afternoon 10:05:06 hargettp [~anonymous@pool-71-184-188-218.bstnma.east.verizon.net] has joined #sbcl 10:07:50 -!- rbarraud_ [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 10:08:08 rbarraud_ [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has joined #sbcl 10:13:39 -!- rbarraud_ [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 10:13:59 rbarraud_ [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has joined #sbcl 10:33:57 -!- hargettp [~anonymous@pool-71-184-188-218.bstnma.east.verizon.net] has quit [Quit: hargettp] 10:35:14 -!- rbarraud_ [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 10:35:41 rbarraud_ [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has joined #sbcl 10:35:58 attila_lendvai [~attila_le@4d6f5d3b.adsl.enternet.hu] has joined #sbcl 10:38:22 hargettp [~anonymous@pool-71-184-188-218.bstnma.east.verizon.net] has joined #sbcl 10:45:12 -!- rbarraud_ [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 10:45:31 rbarraud_ [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has joined #sbcl 10:53:23 rbarraud__ [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has joined #sbcl 10:56:25 -!- rbarraud_ [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has quit [Ping timeout: 252 seconds] 10:57:24 -!- rbarraud__ [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 10:57:43 rbarraud__ [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has joined #sbcl 11:01:42 -!- rbarraud__ [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 11:02:11 rbarraud__ [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has joined #sbcl 11:06:10 -!- rbarraud__ [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 11:06:31 rbarraud__ [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has joined #sbcl 11:10:31 -!- rbarraud__ [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 11:11:47 rbarraud__ [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has joined #sbcl 11:19:05 -!- rbarraud__ [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 11:19:51 rbarraud__ [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has joined #sbcl 11:22:47 rmarynch [~roman@bras-4-ge-62.122.200.230.utm.if.ua] has joined #sbcl 11:24:03 -!- rbarraud__ [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 11:24:21 rbarraud__ [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has joined #sbcl 11:28:19 -!- rbarraud__ [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 11:28:42 rbarraud__ [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has joined #sbcl 11:35:55 -!- mbohun [~mbohun@ppp115-156.static.internode.on.net] has quit [Quit: Leaving] 11:55:41 Heap exhaustion during allocation: X bytes available, X+Y bytes requested 11:56:01 Why does SBCL die with that in ldb? 11:56:09 Can't it check for that and turn it into a lisp error? 11:56:17 not if it happens during a gc 11:57:46 * Heap exhausted during allocation: 4163100672 bytes available, 4294967312 requested. 11:57:47 Gen StaPg UbSta LaSta LUbSt Boxed Unboxed LB LUB !move Alloc Waste Trig WP GCs Mem-age 11:57:47 CORRUPTION WARNING in SBCL pid 23915(tid 140737293018880): 11:57:47 Memory fault at 0 (pc=0x7ffff74c982b, sp=0x7ffff45b3d68) 11:59:00 the page table is probably corrupted if you get a SIGSEGV while trying to print the heap layout 11:59:54 but does it mean the request was made during GC? 12:00:29 Is there any good reading about tweaking sbcl's GC? 12:02:00 I often see 'GC invariant lost' error with our application, but I still have no suitable test case. Another error we observe is 'No transport function for...'. But it allocates near 1GB of memory before giving up 12:02:03 there certainly shouldn't be a 4GB allocation during gc 12:02:22 "during allocation", so not during gc 12:03:38 rmarynch: indicative of heap corruption, typically caused by foreign code, (safety 0) code, or --more seldom these days-- thread or signal handling issues 12:04:39 rmarynch: good first step is to recompile after (restrict-compiler-policy 'safety 2) and see if you catch any type-errors 12:05:11 So why is it not caught in this case? 12:05:16 nikodemus: well, we have a single thread application. But it calls the foreign functions a lot. We compile with (debug 3) (safety 3), but the error rate is 30% or worse (every third launch eventually fails)) 12:06:30 tcr: because it's crashing before a lisp condition is signaled 12:06:41 tcr: because the page table is borked, it looks like, and it crashes into ldb due to the memory fault before it gets back to lisp 12:10:26 So what can I do to track the reason down? It's 100% reproducible for me 12:11:14 rmarynch: i'm inclined to blame the foreign code then. the basic possibilities include: (1) foreign code is "basically correct", but retains a pointer to a lisp object after the call returns, that lisp-object is then moved by GC, and later the foreign code later scribbles at a random place in the heap (2) foreign code being right, but lisp-side code interfacing with it playing nasty tricks that make the compiler think an object used by the forei 12:11:14 gn function is dead, and hence not pinning it (3) foreign code scribbling off the end of an array or on top of object headers -- fault can either be in tricksy interface code on the lisp side, or in the foreign code 12:12:59 tcr: it is likely that a GC happening just before the allocation will catch the issue as well by breaking horribly. so one way to start would be to add GC calls to try to find the site where the corruption occurs 12:14:20 but also the lisp condition being signaled is going to be just a convenience for development, not something you can expect to reliably handle in a production setting 12:14:28 tcr: but if you're feeling brave, stepping through and inspecting things in gdb can definitely 12:14:52 jsnell: not without david's heap magic stuff at any rate... 12:15:16 nikodemus: one thing that confuses me is the fact that Lispworks loads the same code without any issues, and I have never seen it crashing. So, it is more likely some problem in SBCL 12:15:46 nikodemus: so at one point, the call to GC will die? 12:15:58 for example if you'd had just a little bit more memory available there, your silly 4GB array would have just fit in during allocation. and then you would instead have crashed during gc 12:16:15 rmarynch: cases #1 and #2 above can easily manifest in just a single implementation 12:16:42 jsnell: Yeah I used to crash during GC 12:16:52 it looks like running out of memory 12:17:40 rmarynch: of course it can be an sbcl issue -- or an FFI portability layer issue 12:17:50 this one is different though because it dies pretty early on. Might easily be that a length calculation gets astray 12:18:55 rmarynch: but regardless of the fundamental cause, it is very very likely to lie along the lisp/foreign divide 12:19:12 nikodemus: I will be happy to find the cause of the issue and fix it, but it happens too random. As for now, I just restart the whole thing and hope that it will not crash the next time 12:19:17 jsnell: How is the new length of a hash-table calculated on rehashing? 12:19:56 rmarynch: do you get the LDB backtraces? 12:20:36 tcr: it used to be to multiply by some supplied factor, then find the next likely prime above it 12:20:46 you could also connect gdb to it 12:20:48 but did we switch to power of 2 hashtables? 12:21:01 you're the last person who worked on them... 12:21:03 i think 12:21:28 nikodemus: no, I don't. Will try the next time it fails 12:21:42 tcr: I hope you're not implying that you've got a 4GB hashtable :-P 12:21:54 power-of-two-ceiling after magic factorizing 12:22:30 that is, add or multiply by rehash-size, then round up to next power of 2 12:24:48 tcr: a good start would really be to investigate the memory fault. you're getting 0 where a sensible pointer is expected, and it is occuring somewhere in print_generation_stats() 12:27:21 and page_table and generations are about the only possibilities there 12:31:33 0: ((FLET #:CLEANUP-FUN-[SUB-GC]27))[:CLEANUP] 12:31:33 1: (SB-KERNEL:SUB-GC)[:EXTERNAL] 12:31:33 2: (SB-EXT:GC)[:EXTERNAL] 12:31:50 I can interrupt to that point 12:32:15 maybe you want to check if that's a sensible point an interrupt can happen 12:32:53 sounds about right to me 12:34:36 -!- rmarynch [~roman@bras-4-ge-62.122.200.230.utm.if.ua] has quit [Quit: Leaving] 12:38:16 tcr: apropos: you want to do most of your debugging from C and gdb with stuff like this 12:39:23 lisp side can help narrow things down, but it is very easy to get a heisenbug that moves elsewhere when you try to pin it down -- because your debugging allocated a bit more and caused things to lie in different addresses 12:40:38 running GC manually early and often can help you narrow down the area a bit, but it is a shotgun approach, and is unlikely to get you all the way there 12:41:36 other alternatives are "think hard, think krystof hard!" and careful test-case reduction -- but even then poking at the actual memory with gdb is likely to be an immense help 13:01:04 nikodemus: if I'm running it in gdb I get lots of sigsegvs; that's part of sbcl's memory handling right? 13:01:27 so how am I supposed to know which one is the right one? 13:01:37 I mean which one I should not just skip 13:03:21 *froydnj* hates debugging sbcl in gdb for precisely that reason 13:03:24 -!- slyrus [~chatzilla@adsl-75-36-215-204.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 272 seconds] 13:03:27 tcr: you want something like "handle SIGSEGV pass", and then a breakpoint on unhandled_sigmemoryfault 13:03:56 alteratively, just run till you hit ldb and attach gdb at that point 13:04:15 :INVALID-VALUE-FOR-UNESCAPED-REGISTER-STORAGE; what's that one? 13:04:18 or in your first scenario, put a breakpoint on print_generation_stats 13:05:15 it's what the debugger returns if it can't figure out the value in some cases 13:05:39 need not be anything serious -- easy to see when in some local functions, etc 13:08:29 nikodemus: http://paste.lisp.org/display/114806 13:09:02 that's attaching gdb after having crashed in ldb 13:09:07 -!- rbarraud__ [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 13:09:24 rbarraud__ [~rbarraud@118-92-9-129.dsl.dyn.ihug.co.nz] has joined #sbcl 13:10:11 tcr: from the same error as in the first case? 13:12:22 yeah 13:12:32 -!- attila_lendvai [~attila_le@4d6f5d3b.adsl.enternet.hu] has quit [Ping timeout: 276 seconds] 13:13:54 ok, check page_table and generations 13:15:26 why doesn't backtrace_from_fp work there? 13:17:03 don't know -- especially for unknown values of "doesn't work" :) 13:17:16 but backtrace isn't the important thing here 13:17:36 That is what I am interesting in 13:17:51 I thought :-) 13:17:57 x/a (void*)page_table 13:18:20 it's a null pointer 13:18:35 Blkt [~user@dynamic-adsl-94-37-238-79.clienti.tiscali.it] has joined #sbcl 13:19:19 good day everyone 13:19:52 not "0x1000000: 0x0" but "0x00000000: Cannot access memory at address 0x0"? 13:20:07 the former 13:21:39 copy'n' pasting is not easy for me sorry, for some reason macosx's kill ring stopped being shared with vmware's 13:22:47 I can in case it's needed by going over a file :-) 13:25:56 nikodemus: I think I am interested in a backtrace, I want to find out the call site where that amount of memory was requested 13:27:16 tcr: the corruption is likely elsewhere, though 13:29:03 but that is actually a sensible value for page_table -- 0x1000000 is the address where the page table begins 13:29:16 coulnd anyone tell me why is it wrong to write something like this in SBCL's REPL? (defpackage :spam) (in-package :spam) (defclass foo () ((bar :accessor bar))) 13:29:46 (:use :cl) 13:29:48 you forgot 13:29:55 ah I see 13:29:56 nikodemus: Oh sorry it's not that address 13:29:56 thanks 13:30:10 nikodemus: I thought that was only a template address 13:30:28 breakpoint at print_generation_stats and then stepping from there should show where the null is 13:30:56 0x7ffff63e4010: 0x0 13:31:11 I found the bug meanwhile, it's indeed a length calulcation having gone astray 13:31:29 good :) 13:31:55 i'm still wondering about the rest of the breakage, but if you're happy, i'm happy :) 13:32:04 I'll give the stepping a go nontheless 13:37:53 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 276 seconds] 14:02:50 -!- Blkt [~user@dynamic-adsl-94-37-238-79.clienti.tiscali.it] has quit [Remote host closed the connection] 14:08:17 Blkt [~user@dynamic-adsl-94-37-238-79.clienti.tiscali.it] has joined #sbcl 14:09:12 mbohun [~mbohun@ppp115-156.static.internode.on.net] has joined #sbcl 14:12:23 nyef [~nyef@pool-70-109-134-127.cncdnh.east.myfairpoint.net] has joined #sbcl 14:12:36 G'morning all. 14:12:36 nyef, memo from pkhuong: we can bias stack tn offsets instead 14:12:54 ... With a variable bias? 14:13:22 (That is, by number of required function arguments?) 14:14:33 hi nyef 14:17:45 kclifton [~kclifton@s198-166-45-245.ab.hsia.telus.net] has joined #sbcl 14:21:53 tcr1 [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has joined #sbcl 14:22:38 -!- tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has quit [Ping timeout: 245 seconds] 14:41:41 rmarynch [~roman@88.135.194.233] has joined #sbcl 14:44:41 hi fe[nl]ix 14:53:24 nyef: well, by, say, 1024? 14:53:46 or whatever C-A-LIMIT will be when we set it to a sane value (: 14:56:53 Might work, I suppose, but then you also have to keep it from packing anything below the bias point. 14:57:23 Anyway, it's a long-shot idea, anyway. 14:57:59 ... Where'd that second "anyway" come from? 15:01:24 attila_lendvai [~attila_le@89.135.206.66] has joined #sbcl 15:04:49 -!- Blkt [~user@dynamic-adsl-94-37-238-79.clienti.tiscali.it] has quit [Remote host closed the connection] 15:17:59 I have refactored my sse contrib, sharing code between the SBCL and ECL versions where it seemed appropriate: http://github.com/angavrilov/sbcl/commit/7ccb0197c484e1b4b3db8be7d1289913f8eac81e 15:20:17 stassats [~stassats@wikipedia/stassats] has joined #sbcl 15:28:04 angavrilov: I have looked into your cl-gpu library recently, and it is the definitely cool thing. Do you plan to extend it with the direct PTX assembly generation (I know that it is a hard task, but it is interesting to know your opinion about that) ? 15:29:43 My immediate objective is making some particular code run as fast as I can, and I sort of doubt that I can easily generate ptx as efficient as the C compiler. 15:33:43 I do however have a vague idea of trying out OpenCL as a backend when I have time. I have built the code generation system in two ContextL layers, to facilitate multiple back-ends. 15:35:21 that's reasonable - in such a way you will add ATI cards support as well. 16:02:26 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 264 seconds] 16:07:16 -!- nikodemus [~nikodemus@cs181058025.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 16:19:25 -!- rmarynch [~roman@88.135.194.233] has quit [Quit: Leaving] 17:03:14 drewc [~user@S01060013101b6ddb.vc.shawcable.net] has joined #sbcl 17:28:35 Anyone knows off-hand what's the buffering scheme of fd streams? 17:28:56 ... It's configurable, isn't it? 17:29:04 -!- tcr1 is now known as tcr 17:29:16 *nyef* doesn't remember offhand, but seems to recall some option for that, at least. 17:33:05 tcr: full/line/none(configurable at creation), default is :full and :line for terminal streams(*standard-output* & co.) 17:34:38 Yeah looking at the code, I'm wondering why the Lisp side implements its own buffer; isn't that all handled by the OS? 17:35:11 for FILE *, it's implemented by libc, for bare file descriptors, no? 17:37:25 Mmm. We use bare file descriptors, which aren't buffered by the kernel. 17:37:54 right 17:39:10 so a call to write(2) to a real fd is guaranteed to end up on disk? 17:39:16 well, they *are* buffered 17:40:03 tcr: no. between the FD and the disk there's the VM cache and the disk controller buffers 17:40:05 usually 17:50:38 -!- mbohun [~mbohun@ppp115-156.static.internode.on.net] has quit [Quit: Leaving] 17:51:14 stassats [~stassats@wikipedia/stassats] has joined #sbcl 18:04:47 -!- tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has quit [Quit: Leaving.] 18:05:34 tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has joined #sbcl 18:14:05 What does everyone think of the idea of constructing two symbols that share a TLS index? 18:17:55 the first question that comes to mind is "why"? 18:18:07 Well, there is that, yes. 18:38:26 -!- froydnj [~froydnj@gateway.codesourcery.com] has quit [Ping timeout: 264 seconds] 18:42:08 Am I better off using a 16-bit or 32-bit offset in an effective address on x86-64? What about x86? 18:43:40 (Can I even -have- a 16-bit offset on x86-64?) 19:01:50 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 264 seconds] 19:53:28 -!- attila_lendvai [~attila_le@89.135.206.66] has quit [Ping timeout: 245 seconds] 20:00:40 -!- kclifton [~kclifton@s198-166-45-245.ab.hsia.telus.net] has quit [*.net *.split] 20:00:40 -!- mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has quit [*.net *.split] 20:00:41 -!- _3b` [foobar@cpe-72-179-19-4.austin.res.rr.com] has quit [*.net *.split] 20:00:46 mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has joined #sbcl 20:01:08 _3b` [foobar@cpe-72-179-19-4.austin.res.rr.com] has joined #sbcl 20:01:12 kclifton [~kclifton@s198-166-45-245.ab.hsia.telus.net] has joined #sbcl 20:20:20 attila_lendvai [~attila_le@89.135.206.66] has joined #sbcl 20:21:42 -!- hargettp [~anonymous@pool-71-184-188-218.bstnma.east.verizon.net] has quit [Quit: hargettp] 20:24:10 hargettp [~anonymous@pool-71-184-188-218.bstnma.east.verizon.net] has joined #sbcl 21:00:08 -!- angavrilov [~angavrilo@217.71.227.181] has quit [Ping timeout: 272 seconds] 21:06:48 -!- mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has quit [Ping timeout: 245 seconds] 21:17:47 Fare [~Fare@ita4fw1.itasoftware.com] has joined #sbcl 21:36:49 is anyone here going to ILC? 21:37:00 *nyef* isn't. 21:37:44 not me. too bad, I haven't seen a good allegrograph talk in ages 21:38:28 And do I recall correctly that Xach will be giving a quicklisp talk there? 21:40:12 *Krystof* drums his fingers 21:40:36 JonL is organising a vendor panel and wondered whether an SBCL representative could show up 21:40:52 maybe we could send lisppaste2 21:41:50 *Fare* is going, but not qualified to represent SBCL. 21:42:02 is martin going? 21:42:08 I'll ask... 21:42:21 Or james knight, maybe? 21:42:45 yes 21:42:49 foom? 21:44:16 maybe Xach :) 21:45:07 The PPC :L fixup is the low 16 bits of the address to the low 16 bits of the instruction, isn't it? 21:48:17 (Looks like it has to be.) 22:59:22 shawn-p [~fake@97-91-222-215.dhcp.stls.mo.charter.com] has joined #sbcl 23:00:58 Hello. I am trying to build a fork of SBCL on Windows ( http://clgtk2.wordpress.com/2010/09/16/related-project-sbcl-win32-threads/ ) however I am running into some problems. 23:01:10 When I enter "sh make.sh" into msys, here is the result: http://dl.dropbox.com/u/315/random_text/make.log 23:01:39 here's a .txt version so that it'll open without downloading: http://dl.dropbox.com/u/315/random_text/make.txt 23:02:13 erm.. apparently "sh make.sh > make.log" doesn't output to the text file properly 23:02:22 sec. 23:03:51 http://dl.dropbox.com/u/315/random_pics/sbcl_build_error.png 23:05:20 here we go 23:05:22 http://dl.dropbox.com/u/315/random_text/sbcl_build_output.txt 23:07:59 anyone have any idea what the problem might be? 23:08:29 FAILURE-P was set when creating "obj/from-host/src/code/cross-make-load-form.lisp-obj". 23:09:46 looks like I may have found the solution.... 23:09:49 "Please ignore last mail. It's my fault. I should check out SBCL CVS without convent text files into Windows 23:09:49 native EOL style (\r\n), or SBCL will say "Found non-STANDARD-CHAR in ...". The missing of function "BUG" 23:09:49 was actually not any problem." 23:10:02 so I think TortoiseGIT is converting the line endings 23:31:54 Wouldn't surprise me. Line-end-format support is a wishlist item in the tracker. 23:32:14 -!- kclifton [~kclifton@s198-166-45-245.ab.hsia.telus.net] has quit [Quit: kclifton] 23:41:02 -!- attila_lendvai [~attila_le@89.135.206.66] has quit [Quit: Leaving.] 23:42:36 -!- shawn-p [~fake@97-91-222-215.dhcp.stls.mo.charter.com] has quit [] 23:44:09 Does anyone have a good benchmark handy for testing dynamic bind/unbind of fixed symbols (that is, not via PROGV)? 23:51:16 there's stak in the gabriel benchmarks 23:52:22 Thanks. 23:55:50 mbohun [~mbohun@eth649.act.adsl.internode.on.net] has joined #sbcl 23:56:29 -!- mbohun [~mbohun@eth649.act.adsl.internode.on.net] has quit [Read error: Connection reset by peer] 23:56:34 Umm... I can't think straight right now. If I have a :constant VOP argument (in this case, a symbol) and want to load it into a descriptor register, how do I do that? 23:57:13 mbohun [~mbohun@ppp115-156.static.internode.on.net] has joined #sbcl 23:59:17 Hrm. Okay, looks like I create a "constant TN" for it and just use MOV.