00:01:42 udzinari [~user@ip-89-102-12-6.net.upcbroadband.cz] has joined #sbcl 00:20:25 -!- LiamH [~healy@pool-108-18-166-81.washdc.east.verizon.net] has quit [Quit: Leaving.] 01:08:17 slyrus_ [~chatzilla@adsl-99-35-55-18.dsl.pltn13.sbcglobal.net] has joined #sbcl 01:10:19 -!- slyrus [~chatzilla@adsl-99-35-53-209.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 244 seconds] 01:10:28 -!- slyrus_ is now known as slyrus 01:27:14 -!- udzinari [~user@ip-89-102-12-6.net.upcbroadband.cz] has quit [Remote host closed the connection] 01:27:29 udzinari [~user@ip-89-102-12-6.net.upcbroadband.cz] has joined #sbcl 02:26:06 drl [~lat@110.139.229.172] has joined #sbcl 02:28:02 -!- drl [~lat@110.139.229.172] has quit [Remote host closed the connection] 02:31:42 drl [~lat@110.139.229.172] has joined #sbcl 02:41:47 -!- drl [~lat@110.139.229.172] has quit [Quit: Leaving] 02:49:37 -!- udzinari [~user@ip-89-102-12-6.net.upcbroadband.cz] has quit [Ping timeout: 244 seconds] 03:30:46 huh, I seem to have found a regression in openbsd 5.0 03:47:00 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 03:47:47 antgreen [~user@bas3-toronto06-1176449659.dsl.bell.ca] has joined #sbcl 03:56:07 slyrus_ [~chatzilla@adsl-99-49-14-228.dsl.pltn13.sbcglobal.net] has joined #sbcl 03:57:49 -!- slyrus [~chatzilla@adsl-99-35-55-18.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 240 seconds] 03:58:03 -!- slyrus_ is now known as slyrus 04:47:04 -!- akovalenko [~akovalenk@95.73.52.175] has quit [Ping timeout: 240 seconds] 04:50:02 -!- antgreen [~user@bas3-toronto06-1176449659.dsl.bell.ca] has quit [Ping timeout: 245 seconds] 05:03:49 akovalenko [~akovalenk@95.72.173.116] has joined #sbcl 05:10:38 angavrilov [~angavrilo@217.71.227.181] has joined #sbcl 06:39:07 Cryotank2011 [~Cryotank2@c-24-17-62-152.hsd1.wa.comcast.net] has joined #sbcl 06:46:42 -!- pers [~user@96-25-162-104.gar.clearwire-wmx.net] has quit [Ping timeout: 245 seconds] 06:48:34 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 260 seconds] 06:53:01 -!- Cryotank2011 [~Cryotank2@c-24-17-62-152.hsd1.wa.comcast.net] has quit [Quit: Cryotank2011] 07:04:28 attila_lendvai [~attila_le@87.247.60.133] has joined #sbcl 07:04:28 -!- attila_lendvai [~attila_le@87.247.60.133] has quit [Changing host] 07:04:28 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 07:23:47 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 245 seconds] 07:37:24 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 08:25:57 -!- drdo [~drdo@85.207.54.77.rev.vodafone.pt] has quit [Ping timeout: 276 seconds] 09:10:30 -!- angavrilov [~angavrilo@217.71.227.181] has quit [Remote host closed the connection] 09:10:55 angavrilov [~angavrilo@217.71.227.181] has joined #sbcl 09:18:21 -!- pchrist [~spirit@gentoo/developer/pchrist] has quit [Ping timeout: 260 seconds] 09:19:28 pchrist [~spirit@gentoo/developer/pchrist] has joined #sbcl 09:37:52 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 240 seconds] 09:48:06 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 10:02:23 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 248 seconds] 10:08:53 attila_lendvai [~attila_le@87.247.10.198] has joined #sbcl 10:08:53 -!- attila_lendvai [~attila_le@87.247.10.198] has quit [Changing host] 10:08:53 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 10:35:39 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 244 seconds] 10:41:42 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 11:13:52 -!- peddie [~peddie@repl.esden.net] has quit [Ping timeout: 240 seconds] 11:18:47 peddie [~peddie@repl.esden.net] has joined #sbcl 11:38:46 nikodemus [~nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 11:38:46 -!- ChanServ has set mode +o nikodemus 11:40:54 morning 11:52:39 -!- nikodemus [~nikodemus@cs181063174.pp.htv.fi] has quit [Ping timeout: 276 seconds] 12:01:17 nikodemus [~nikodemus@178-55-44-208.bb.dnainternet.fi] has joined #sbcl 12:01:17 -!- ChanServ has set mode +o nikodemus 12:32:52 hlavaty [~user@91.65.217.112] has joined #sbcl 12:37:23 re. default dynamic-space-size: how does 512Mb for 32 bits, and 1Gb for 64 sound? 12:48:22 hm. openbsd has default ulimit of 512, it seems -- and going below that everywhere is ridiculous 12:58:46 nikodemus: how about just asking the limit when starting, and using that (minus, say, 32MB) as initial value? 12:59:12 I know that I've had to patch the SBCL binary to make it work on a shared hosting. 13:01:41 low ulimit? 13:02:31 ha! min(getrlimit(RLIMIT_DATA, ...), 1Gb) 13:02:57 well, the rlimit needs to be adjusted a bit, but... 13:02:59 IIRC the problem was that the virtual size was restricted to ~1GB or something like that 13:06:15 nikodemus: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559954 and/or http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=474402 13:07:09 I know that I'm changing the binary to some lower value, too ... in case I'm forgetting the base-case in a recursion or something like that, so that not the whole desktop is dead until the OOM killer gets invoked 13:08:03 sadly it doesn't just work to set the as ulimits - then SBCL doesn't start, because it doesn't get the 8GB or whatever it wants (without being patched, that is) 13:08:22 flip214: fwiw, --dynamic-space-size is both a runtime and a build-time option 13:08:31 no need to patch 13:09:03 nikodemus: yes, it's a runtime and build option ... but the scripts that call it in debian (for installing, building cores, etc) don't take any global configuration file for that 13:09:17 so it's much easier to use hte - look for the symbol, patch it, done 13:09:52 it wouldn't hurt if there was an utility to do that ... 13:11:27 flip214: building sbcl yourself is also an option... 13:11:40 :P 13:14:41 much more work that just changing 2 bits (8GB => 1GB) 13:16:29 and, TBH, it wouldn't even work ... SBCL needs a CL to build, right? well, the installed SBCL won't run without being patched, so the new version cannot be built ... 13:17:42 sh make.sh --xc-host="sbcl --dynamic-space-size " --dynamic-space-size= 13:18:05 and you can ride the bleeding edge! 13:18:36 that said, i think automatically adjusting dynamic-space-size to fit under ulimits would probably be good 13:21:01 -!- tsuru` [~charlie@adsl-74-179-25-191.bna.bellsouth.net] has quit [Remote host closed the connection] 13:21:09 yes, surely! At least the address-space limit is a big problem ... and you've got to subtract a fair amount from there, too, to make everything fit (eg. in case foreign libraries are loaded) 13:22:36 nikodemus: Is there a way to provide tuning _while running_? I'd think that doing a (gc :full t), allocating some consecutive pages (and marking them non-moveable), followed by munmap()ping them should have the wanted result ... 13:29:58 udzinari [user@nat/ibm/x-sfmaudvfivftzrjf] has joined #sbcl 13:44:13 homie [~levgue@xdsl-78-35-154-35.netcologne.de] has joined #sbcl 13:51:12 -!- pchrist [~spirit@gentoo/developer/pchrist] has quit [Quit: leaving] 13:51:42 pchrist [~spirit@gentoo/developer/pchrist] has joined #sbcl 13:59:25 at what level are atomic ops inmplemented on the os side ? is that kernel stuff ? 14:00:37 normally CPU dependent ... bus lock, etc. 14:01:54 ok then another way to ask, what means atomic on that level ? i mean hardware ?! 14:02:50 that the CPU sets a statusline to lock the bus, loads the data from the address, changes it (incf, decf, xchg, whatever), stores it back, and releases the bus lock signal 14:03:18 ie. the other CPUs (if there are any) cannot access memory (at least that address) in the meantime ... 14:03:28 oh ok 14:05:17 again, implementation-dependent that might mean that the other CPUs have to flush data caches, etc ... can be really expensive 14:07:11 hmmmm ok 14:07:57 cache hit and reordering issues and efficiency...... 14:37:33 tsuru` [~charlie@adsl-74-179-25-191.bna.bellsouth.net] has joined #sbcl 14:40:26 rpg [~rpg@216.243.156.16.real-time.com] has joined #sbcl 14:45:50 Qworkescence [~quad@unaffiliated/quadrescence] has joined #sbcl 15:03:35 nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has joined #sbcl 15:03:42 G'morning all. 15:06:14 milanj [~milanj_@109-92-103-199.dynamic.isp.telekom.rs] has joined #sbcl 15:06:23 hi nyef 15:06:26 *nikodemus* is planning to shrink dynamic-space defaults to 512Mb on 32-bit platforms and 1Gb on 64-bit platforms, and braces for impact 15:06:47 Shrink the defaults? Why? 15:07:21 Can we at least grow the heap dynamically? 15:08:04 to play nice with the new default nursery size -- which performs better, but makes it easier to hit swap on a low-end system if the dynamic-space size is >> physical memory, which isn't all that rare 15:08:41 nyef: i'd be happy see lichtblau's heap-growing stuff merged, but don't have time to attend to it myself just now 15:09:45 the logic is to encourage people to build and run with dynamic-space-size corresponding to their actual memory size 15:10:40 Hrm... You might make sure that the default is large enough to build SBCL with. 15:10:45 sure 15:10:57 Especially, large enough to cross-build a different word-length sbcl with. 15:10:59 just about to do that 15:11:31 (apropos, openbsd/x86-64 is the exception, as it already has only 444Mb dynamic-space) 15:13:29 Oh, and the threads.pure.lisp tests have yet to fail for me since building on Friday afternoon. I'm about ready to call it good. 15:13:48 \o/ 15:14:38 Admittedly, I haven't been running them over the weekend. 15:15:20 i never go above 1024mb for dynamic size 15:23:01 oh feh, darwin/x86 build is broken 15:23:13 *nikodemus* looks for other likely culprits 15:23:27 *nikodemus* feels lonely 15:23:34 Darwin/x86? 15:23:42 Broken how? 15:24:06 I mean, beyond the scrub_control_stack() disaster, that is? 15:25:50 x86-darwin-os.c:276: error: can't find a register in class ?BREG? while reloading ?asm? 15:26:11 Hunh. That... may have been me, actually. 15:26:51 Then again, if it /was/ me, it was to fix a build error on darwin/x86 and darwin/x86-64. 15:27:02 heh 15:27:28 it's for the line with the trap to restore signal context 15:27:31 That's the bit in the signal handling wrapper that does the restore... yeah. 15:27:45 Bloody nuisance. 15:28:33 If you look at the old version, you'll find that the compiler is allowed to pack both values into any register, and the fragment needs to load two specific registers. 15:29:28 right, i see it 15:29:35 So I changed it to tell the compiler to pack to the specific registers in question, using the information from the gcc info file. 15:30:22 Fixed dying of SIGFPE immediately post-first-memory-fault. 15:31:39 xcode version issue, maybe? 15:32:21 Let's be more specific. gcc/clang version issue? 15:32:45 > cc --version 15:32:47 i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3) 15:32:53 Because it'd be far too useful for compiler manuals to indicate which range of versions a particular extension is available in... 15:33:19 darwin11-llvm-gcc here. 15:34:03 Still 4.2.1, though. 15:37:14 hm. -fno-pic stops the compaint, but then i need -read_only_relocs suppress in linkflags as well 15:37:23 let's see if the resulting system works... 15:37:27 Ohh... 15:37:36 Okay, I see what it's complaining about then. 15:37:52 We should move it off of EBX. 15:38:09 ah. linkage base 15:38:12 Spot on. 15:38:25 ECX should be free, shouldn't it? 15:38:52 if ECX was reserved, it would make a lot of instructions pretty hard to use... 15:39:07 That too. 15:39:16 counter ? 15:39:31 Floating-point context pointer, in this case, but yeah. 15:40:30 totally unrelated, but it reminds me: we have logic *in the GC's C code* to save/restore FPU context. 15:41:42 Buried treasure, or something important? 15:42:05 gencgc, cheneygc, or gc-common? 15:42:17 gencgc. more like, why aren't we doing this in asm. 15:44:23 Where do we do this? It's not obvious to me yet. 15:44:30 nikodemus pasted "look about right?" at http://paste.lisp.org/display/126001 15:44:38 Oh, write_generation_stats()? 15:44:42 nyef: yeah. 15:45:01 write_generation_stats, not just for debug builds anymore. 15:45:49 pkhuong: What the hell is that... THING... that sets up the context save area?!? 15:46:04 27, 32, etc? (: 15:46:05 nyef: no other less-obvious places to frob for ebx -> ecx? 15:46:14 nikodemus: Just checking now. 15:46:53 Looks good to me. 15:47:20 I don't /think/ there's any references in the compiler backend, and there doesn't seem to be any in x86-assem.S either. 15:51:35 pkhuong: I think the most reasonable thing to do there is to "#define FPU_STATE_VARIABLE(name) long long name[32]" in target-arch.h and call it tolerably well contained. 15:52:01 seems to work, pushed 15:52:03 (Substitute a different definition of FPU_STATE_VARIABLE() on those other platforms that need it...) 15:52:53 Or maybe FPU_STATE_STORAGE() instead of _VARIABLE? 15:55:32 nyef: I think we should save around all C calls. 15:56:00 I think we mostly do. 15:56:30 We may safely assume that any path from lisp to C that involves call_into_c or a signal-handler does the save. 15:57:01 And that leaves the allocation overflow handlers on x86(oids?) and %PRIMITIVE PRINT. 15:59:14 right, there's allocation overflow. alloc_tramp doesn't save. 15:59:47 i feel like in OP room 15:59:49 lol 16:00:02 -!- Phoodus [~foo@63-235-81-162.dia.static.qwest.net] has quit [Ping timeout: 245 seconds] 16:00:03 Mmm. PPC allocation overflow, if memory serves, always goes through the signal-handler path. 16:00:24 (It uses TWNLE or similar to do the overflow test.) 16:00:59 And that's for both cheneygc and gencgc. 16:01:04 ... I think. 16:03:21 attila_lendvai1 [~attila_le@87.247.63.160] has joined #sbcl 16:03:21 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Disconnected by services] 16:04:29 Hrm. 16:04:43 cheneygc doesn't -have- an allocation overflow trap? 16:06:14 Tentative conclusion, must be some cleverness in the memory-fault path. 16:07:47 yes. It has a guard page 16:10:18 Okay, so that's through the signal-handling path. 16:10:44 So we shouldn't have to do anything with the FPU state on PPC anyway, surely? 16:11:42 At the same time, we'd probably prefer to not save the FPU state on x86oids unless we're doing a full GC rather than merely having overflowed our alloc region. 16:16:46 they're around 100 cycle each. 16:17:23 (save/restore) for SSE. x87 is ~150 each. 16:24:41 -!- udzinari [user@nat/ibm/x-sfmaudvfivftzrjf] has quit [Read error: Connection reset by peer] 16:33:52 Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has joined #sbcl 16:44:35 -!- nikodemus [~nikodemus@178-55-44-208.bb.dnainternet.fi] has quit [Quit: This computer has gone to sleep] 17:09:39 nikodemus [~Nikodemus@GGZYYYMMCCXV.gprs.sl-laajakaista.fi] has joined #sbcl 17:09:39 -!- ChanServ has set mode +o nikodemus 17:21:47 lucky you, am testing your sbcl, both for glibc old and new...lol 17:33:25 -!- attila_lendvai1 [~attila_le@87.247.63.160] has quit [Ping timeout: 252 seconds] 17:41:18 I haven't had time to bisect where the change occurred, but it seems that recent SBCLs broke opticl which was doing a (require :sb-cltl2) without the benefit of eval-when (c-t l-t e) ... 18:00:15 reduced to 1 failure on old-stable glibc now 18:00:22 i'm switching 18:28:39 -!- Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has quit [Remote host closed the connection] 18:32:13 udzinari [~user@ip-89-102-12-6.net.upcbroadband.cz] has joined #sbcl 18:40:36 ok one of the failures seems due to glibc 18:40:43 the new one i mean 18:40:53 and that is not the backtrace thing 19:04:28 -!- angavrilov [~angavrilo@217.71.227.181] has quit [Ping timeout: 244 seconds] 19:25:15 udzinari` [~user@ip-89-102-12-6.net.upcbroadband.cz] has joined #sbcl 19:27:27 -!- udzinari [~user@ip-89-102-12-6.net.upcbroadband.cz] has quit [Ping timeout: 258 seconds] 19:39:59 homie` [~levgue@xdsl-84-44-176-121.netcologne.de] has joined #sbcl 19:40:17 Nice. 19:41:55 -!- homie` [~levgue@xdsl-84-44-176-121.netcologne.de] has quit [Client Quit] 19:42:17 -!- homie [~levgue@xdsl-78-35-154-35.netcologne.de] has quit [Ping timeout: 244 seconds] 19:44:17 -!- nikodemus [~Nikodemus@GGZYYYMMCCXV.gprs.sl-laajakaista.fi] has quit [Remote host closed the connection] 19:44:21 homie [~levgue@xdsl-84-44-176-121.netcologne.de] has joined #sbcl 19:56:38 Phoodus [~foo@ip72-223-116-248.ph.ph.cox.net] has joined #sbcl 20:07:32 nope, i didn't switch the glibc's it seems, just installing the old one had an effect on some header files, which were absent in the newer one, and the headers make a difference, rpc and nis stuff... 20:07:42 nikodemus [~nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 20:07:42 -!- ChanServ has set mode +o nikodemus 20:48:47 -!- Phoodus [~foo@ip72-223-116-248.ph.ph.cox.net] has quit [Ping timeout: 245 seconds] 21:03:26 sdemarre [~serge@91.176.94.227] has joined #sbcl 21:23:23 -!- nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has quit [Quit: G'night all.] 21:59:35 -!- udzinari` [~user@ip-89-102-12-6.net.upcbroadband.cz] has quit [Remote host closed the connection] 22:06:16 -!- sdemarre [~serge@91.176.94.227] has quit [Ping timeout: 240 seconds] 22:25:28 -!- milanj [~milanj_@109-92-103-199.dynamic.isp.telekom.rs] has quit [Read error: Connection timed out] 22:33:34 -!- nikodemus [~nikodemus@cs181063174.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 23:31:56 mensch [~mensch@c-98-217-184-95.hsd1.ma.comcast.net] has joined #sbcl 23:32:29 -!- |3b| [foobar@cpe-72-179-19-4.austin.res.rr.com] has quit [Remote host closed the connection] 23:32:35 tsuru`` [~charlie@adsl-74-179-25-191.bna.bellsouth.net] has joined #sbcl 23:33:12 |3b| [foobar@cpe-72-179-19-4.austin.res.rr.com] has joined #sbcl 23:33:25 -!- tsuru` [~charlie@adsl-74-179-25-191.bna.bellsouth.net] has quit [Remote host closed the connection] 23:59:25 drdo [~drdo@85.207.54.77.rev.vodafone.pt] has joined #sbcl