00:04:09 -!- Kryztof [~user@81.174.155.115] has quit [Remote host closed the connection] 00:04:30 Kryztof [~user@81.174.155.115] has joined #sbcl 00:04:30 -!- ChanServ has set mode +o Kryztof 00:38:49 -!- Qworkescence [~quad@unaffiliated/quadrescence] has quit [Quit: Leaving] 01:48:56 Phoodus [~foo@68.107.217.139] has joined #sbcl 01:49:15 -!- christoph_debian [~user@oteiza.siccegge.de] has quit [Remote host closed the connection] 02:35:48 antgreen [~user@bas3-toronto06-1177890250.dsl.bell.ca] has joined #sbcl 03:05:15 attila_lendvai [~attila_le@87.247.63.160] has joined #sbcl 03:05:15 -!- attila_lendvai [~attila_le@87.247.63.160] has quit [Changing host] 03:05:15 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 03:23:01 -!- jaimef [jaimef@dns.mauthesis.com] has quit [Ping timeout: 240 seconds] 04:07:29 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 244 seconds] 04:20:20 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 04:22:05 *Phoodus* impacts the 1GB default 04:22:50 all of our config is driven from lisp. If I understand correctly, I cannot set dynamic space size from lisp itself 04:24:23 Not for the current lisp runtime, but you could start a second lisp or write out a shell script which starts a new lisp or something. 04:24:33 Phoodus: yes, but it's saved when you dump your own image with :save-runtime-options t 04:25:00 right, we dump an image to deploy, then that deployed image is driven by sexpr configuration read by lisp itself 04:25:59 if we had a very large default size, will it randomly allocate all over that space? or will it stick to the bottom end without swapping if it doesn't use that much total? 04:26:25 Why would it matter which pages it started using? 04:26:53 because if we set it to 128GB and the machine only has 32GB, if it stuck to using the lower end it wouldn't needlessly swap 04:27:24 assuming nobody using that build has more than 128GB 04:27:47 or else they'd be needlessly capped 04:28:00 *akovalenko* doesn't like the new default too much, too. DYNAMIC-SPACE-SIZE is a hard limit for a given session, so making it as high as possible would be better. 04:28:48 right, I'd prefer it to grow stupidly big, cap it down if you want to enforce a smaller footprint 04:29:07 though is the GC nursery size now related to the dynamic space size? 04:29:14 it looks like a workaround for new bytes-consed-between-gcs defaulting to 5% of dynamic-space-size 04:29:40 (sb-kernel::bytes-consed-between-gcs) is setfable at runtime, though 04:29:47 right, that's actually part of our runtime config 04:31:14 I could see defaults working in 2 different configs 04:31:46 1) you don't specify anything, the dynamic size is effectively unbounded, nursery size is "reasonable" 04:31:58 2) you specify both 04:32:18 but I guess that's sort of what it was before :-P 04:33:58 or 2) if you set dynamic size, only then does GC nursery default to 5% of what you set it as 04:42:05 -!- antgreen [~user@bas3-toronto06-1177890250.dsl.bell.ca] has quit [Read error: Connection reset by peer] 04:42:36 antgreen [~user@bas3-toronto06-1177890250.dsl.bell.ca] has joined #sbcl 04:47:04 -!- akovalenko [~akovalenk@95.72.173.116] has quit [Ping timeout: 240 seconds] 04:50:24 -!- antgreen [~user@bas3-toronto06-1177890250.dsl.bell.ca] has quit [Read error: Connection reset by peer] 04:50:58 antgreen [~user@bas3-toronto06-1177890250.dsl.bell.ca] has joined #sbcl 04:54:19 akovalenko [~akovalenk@95.72.172.69] has joined #sbcl 05:00:02 -!- homie [~levgue@xdsl-84-44-176-121.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 05:04:12 -!- antgreen [~user@bas3-toronto06-1177890250.dsl.bell.ca] has quit [Ping timeout: 276 seconds] 05:26:40 angavrilov [~angavrilo@217.71.227.181] has joined #sbcl 06:45:03 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 248 seconds] 07:20:23 -!- drdo [~drdo@85.207.54.77.rev.vodafone.pt] has quit [Read error: Connection reset by peer] 07:32:43 attila_lendvai [~attila_le@87.247.3.243] has joined #sbcl 07:32:43 -!- attila_lendvai [~attila_le@87.247.3.243] has quit [Changing host] 07:32:43 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 07:41:24 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Read error: Operation timed out] 08:01:12 attila_lendvai [~attila_le@87.247.34.108] has joined #sbcl 08:01:12 -!- attila_lendvai [~attila_le@87.247.34.108] has quit [Changing host] 08:01:12 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 08:06:26 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 252 seconds] 08:10:52 drdo [~drdo@85.207.54.77.rev.vodafone.pt] has joined #sbcl 08:11:25 -!- kanru [~kanru@kanru-1-pt.tunnel.tserv15.lax1.ipv6.he.net] has quit [Ping timeout: 240 seconds] 08:14:55 kanru [~kanru@kanru-1-pt.tunnel.tserv15.lax1.ipv6.he.net] has joined #sbcl 08:17:15 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 08:19:22 blumbri [1000@204.152.219.51] has joined #sbcl 08:21:50 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 252 seconds] 08:31:54 attila_lendvai [~attila_le@87.247.47.30] has joined #sbcl 08:31:54 -!- attila_lendvai [~attila_le@87.247.47.30] has quit [Changing host] 08:31:54 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 09:10:09 nikodemus [~nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 09:10:09 -!- ChanServ has set mode +o nikodemus 09:11:46 nikodemus: so far two people here, Phoodus and I, expressed some discontent on new dynamic-space-size defaults (together with 5% nursery) 09:12:34 akovalenko: i'll go read the logs, just a sec 09:14:13 hm 09:16:06 the times i've had issues with dynamic space have been mostly running into swap -- in which case it may be a long time before i manage to kill the offending process, and sometimes having someting else OOM-killed before tat 09:20:07 is ulimit -m currently useless on Linux? 09:21:15 yes 09:21:47 the swap death scenario has happened for me too often too 09:23:19 i'll take a look at david's relocation branch and see what state it is in 09:23:20 hmm. and ulimit -v will prevent sbcl from starting, unless we learn to back off to lower dynamic-space-size.. 09:23:27 I had some success with the address-space limit ... but that needs changing the dynamic-space value 09:24:11 the only ulimit in Linux that works is the address space limit 09:24:46 I got the R people to see the light on this; last time I was sad about something I ended up leaving an IRC channel in a huff, but I am sad that we haven't got this right amongst ourselves 09:24:54 https://stat.ethz.ch/pipermail/r-devel/2011-July/061640.html 09:24:59 ulimit -v has some effect at least, apparently 09:25:37 ah, it /is/ called "address space limit" elsewhere.. 09:27:45 btw, shrinking our dynamic-space-size on the fly seems to be easily implementable (..mremap) 09:29:45 akovalenko: win64 is only on your fork, not on mainline yet, right? 09:29:51 right 09:30:31 nikodemus: I can say that it's not too different in this respect 09:31:17 akovalenko: i'm asking because david's relocation code has some "when porting to win64" alert comments 09:31:21 that is, it has no problems with 8Gb reserved virtual memory, and it starts to swap if we actually use much of it. 09:38:59 hmm. are MAP_NORESERVE pages accounted for w.r.t -v limit until they're accessed? 09:48:49 apparently, it can mmap 8Gb /under/ 100Mb ulimit -v, even without MAP_NORESERVE (does it depends on kernel overcommit settings?) 10:09:39 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 10:18:50 good news is that a forward port of david's relocation branch seems painless (have it building just now) 10:19:10 bad news is that it didn't have the code i was looking for, which must be on another branch... 10:19:38 I talked to him about it a while ago 10:19:42 I can't remember what he said, though 10:19:53 incremental-allocation might be the name of the branch? 10:20:12 I can't remember whether he said it dependend on relocation or not 10:20:53 yeah, just-relocation seems to have just the relocation... 10:21:39 i think incremental-allocation-using-mmap is the branch i want 10:22:06 it does seem to depend on relocation, though 10:25:41 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 10:58:29 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 11:02:07 -!- |3b| [foobar@cpe-72-179-19-4.austin.res.rr.com] has quit [Ping timeout: 248 seconds] 11:30:29 -!- mensch [~mensch@c-98-217-184-95.hsd1.ma.comcast.net] has quit [Quit: leaving] 11:57:59 -!- Kryztof [~user@81.174.155.115] has quit [Ping timeout: 252 seconds] 12:12:47 |3b| [foobar@cpe-72-179-19-4.austin.res.rr.com] has joined #sbcl 12:12:59 -!- flip214 [~marek@unaffiliated/flip214] has quit [Quit: Leaving] 12:24:16 -!- rpg [~rpg@216.243.156.16.real-time.com] has quit [Ping timeout: 240 seconds] 12:28:58 flip214 [~marek@unaffiliated/flip214] has joined #sbcl 12:29:29 rpg [~rpg@216.243.156.16.real-time.com] has joined #sbcl 12:33:24 -!- antifuchs [~foobar@care.boinkor.net] has quit [Ping timeout: 244 seconds] 12:33:43 antifuchs [~foobar@care.boinkor.net] has joined #sbcl 13:07:32 mensch [~mensch@158.121.107.71] has joined #sbcl 13:19:33 attila_lendvai [~attila_le@87.247.35.194] has joined #sbcl 13:19:33 -!- attila_lendvai [~attila_le@87.247.35.194] has quit [Changing host] 13:19:33 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 13:23:25 -!- rpg [~rpg@216.243.156.16.real-time.com] has quit [Ping timeout: 244 seconds] 13:38:50 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 260 seconds] 13:47:29 lichtblau: aroundp 13:53:08 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 14:07:51 rpg [~rpg@mpls.sift.info] has joined #sbcl 14:27:29 Kryztof [~user@81.174.155.115] has joined #sbcl 14:27:29 -!- ChanServ has set mode +o Kryztof 14:30:42 I had a weird problem today where I can reproducibly get WITH-TIMEOUT to fail 14:32:49 antgreen [~user@bas3-toronto06-1177890206.dsl.bell.ca] has joined #sbcl 14:35:20 Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has joined #sbcl 14:39:22 -!- mensch [~mensch@158.121.107.71] has quit [Ping timeout: 244 seconds] 14:48:36 I'm getting an 'invalid exit status' test failure in interface.impure.lisp with HEAD on linux x86_64. Is this already known? 14:57:05 loke and tsuru``: please send details to sbcl-devel, sbcl-bugs, or launchpad 14:59:00 nikodemus: That's the problem. The issue only occurrs inside my application. Any attempt to make it smaller has failed so far 14:59:58 nikodemus: The test case is super simple, I just try to interrupt a SLEEP, but it just doesn't interrupt anymore (even when run from the REPL) if my hunchentoot is running, and I've made a few requests 15:00:24 heh 15:00:39 My question is, is there something I can do to investigate further, for the purpose of being able to provide a bug report fo ryou? 15:00:44 loke: are you doing interactive interrupt, aka Ctrl+C? 15:00:59 akovalenko: No, it's a SLEEP wrapped in a WITH-TIMEOUT 15:01:06 the timeout just doesn't happen 15:02:01 it's something like (handler-bind (sb-ext:with-timeout 1 (sleep 10) (sb-ext:timeout (v) nil))) 15:02:23 that one will sleep 1 second when it works, but sleeps 10 seconds when it doesn't 15:02:28 handler-case, maybe 15:02:32 yeah, you're right 15:02:37 handler-case 15:03:23 SInce I can easily put my SBCL in a state where the problem occurrs, the question is what I can do at that point to pin the problem down? 15:03:23 *akovalenko* can't remember with-timeout details on Unix. Does it create a timer?.. 15:04:58 loke: if you stop hunchentoot, does the problem go away? 15:05:26 akovalenko: I never tried... I just restarted the entire SBCL 15:05:37 I can try that (have to do it in the office tomorrow) 15:07:08 loke: that's a suggestion to try. And if it doesn't go away when you stop hunchentoot, the next step I'd recommend is (MAKE-THREAD 'LIST), /instead/ of hunchentoot, and see if it causes the problem in a fresh sbcl. 15:08:01 akovalenko: well, it's not hunchentoot per se, as it still works after starting it. It's after doing some stuff in my hunchentoot-based application that it happens 15:08:19 once it happens, every single attempt at using WITH-TIMEOUT fails in that way 15:08:24 (rgardless of thread) 15:08:42 *akovalenko* thinks of blocked deferrables. 15:09:07 This is the git-version of sbcl by the way 15:09:32 I had some thoughts of rolling back to a pre-redesigned locks-thingy (1.0.50?) 15:10:28 loke: what plapforms, what build options? 15:10:44 Linux x64. Default build flags 15:10:49 1.0.53 release is still "pre-redesigned" 15:11:12 ah ok 15:12:19 loke: (handler-bind (sb-ext:with-timeout 1 (sleep 10) (sb-ext:timeout (v) nil))) ; this is obviously not the whole picture -- or otherwise you'd just be doing (sleep 1) -- can you expand on this a bit? 15:12:34 -!- tsuru`` is now known as tsuru` 15:13:21 nikodemus: of course. In the actual application it does a bit more. The sleep thing is just something I did to have a minimal test in the REPL 15:13:49 The actual version wraps a call to BORDEAUX-THREADS:SIGNAL-WAIT 15:14:14 oops 15:14:20 I mean CONDITION_WAIT 15:14:32 loke: ok, so this is not actually what /causes/ the problem -- this is a symptom of the problem 15:14:36 ah. and bt:condition-* uses semaphores under the hood. 15:14:40 Right now I worked around my problems with a #+sbcl that uses SB-THREAD:CONDITION-WAIT with the extra option that allows me to specify a timeout 15:14:43 akovalenko: correct 15:15:02 loke: is this HEAD from today or? 15:15:05 akovalenko: I have no idea what causes the problem, and that's what I need to figure out before I can do a bug report for you guys. 15:15:17 nikodemus: HEAD as of about 9 hours ago 15:15:51 I upgraded as soon as I found the issue in the hope it had just been fixed (I used to use HEAD as of a week ago or so) 15:15:52 loke: apparently /something/ is wrong with asynch unwinds now 15:16:38 i'll look into it, but regardless of the speed of solution, i woud strongly recommed against using with-timeout in production 15:17:09 use either with-deadline, or a :timeout argument to the blocking function 15:17:18 nikodemus: I'm specifically only using it around CONDITION-WAIT which should be considered OK, yes? It's what's recommended in the bordaux-threads docs. 15:17:34 The problem is that bordeaux-threads doesn't expose that 15:17:49 loke: are you running outside sbcl as well? 15:17:52 nikodemus: yes 15:17:57 ok, fair enough 15:18:03 nikodemus: I'm trying to be as platform-unspecific as possible. 15:18:23 As I said, I have already worked around it for SBCL using the timeout option in SBCL's version of condition-wait 15:18:47 So I'm OK, but I still wanted to report the issue to you 15:19:22 loke: if you were a paying client, i would keep telling you not to use with-timeout, interrupt-thread, and terminate-thread -- regardless of platform -- since as long as you do, you little else i can tell you will make as big a long-term impact in your applications stability 15:19:39 ...but i'll see if i can reproduce this 15:19:40 nikodemus: I know, and I don't, as far as possible :-) 15:20:16 In my opinion, bordeaux-threads made a mistake not including a timeout option in their version of condition-wait 15:23:19 nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has joined #sbcl 15:23:29 G'morning all. 15:23:51 hello nyef 15:23:58 loke: patches are welcome 15:25:15 Okay, I have about five hours left with my PPC system, which is enough to do a couple of build/test cycles. Other than the sb-futex thing, what's critical to go in? 15:26:11 leuler [~user@p5490336F.dip.t-dialin.net] has joined #sbcl 15:26:55 zyg [57e37c83@gateway/web/freenode/ip.87.227.124.131] has joined #sbcl 15:28:52 Hi! how can I read out the current OPTIMIZE qualities? 15:30:06 milanj [~milanj_@109-92-103-199.dynamic.isp.telekom.rs] has joined #sbcl 15:30:24 Have an apropos for "compiler-policy", it should be fairly obvious from there. 15:31:14 (sb-ext:describe-compiler-policy) 15:33:06 nyef: how simple :) .. thanks 15:33:35 That's for human-readable description. Something like SB-C::*POLICY* gives an unofficial programmatic access to what's currently proclaimed. 15:34:48 there's sb-cltl2:declaration-information which might be more official 15:46:16 homie [~levgue@xdsl-78-35-167-160.netcologne.de] has joined #sbcl 15:54:49 -!- zyg [57e37c83@gateway/web/freenode/ip.87.227.124.131] has quit [Quit: Page closed] 16:01:46 rpg_ [~rpg@mpls.sift.info] has joined #sbcl 16:04:13 ... I can (declare (t some-variable)), right? 16:04:37 right 16:04:43 Okay, good. 16:05:10 ..in sbcl, you can also (declare ((and t t) some-variable)), though it's not portable. 16:05:14 Qworkescence [~quad@unaffiliated/quadrescence] has joined #sbcl 16:05:39 -!- rpg [~rpg@mpls.sift.info] has quit [Ping timeout: 244 seconds] 16:06:49 Yeah, I just need to say that a given variable can hold any object. 16:07:19 nyef: that's the default. I don't see why you'd want to declare that. 16:10:02 loke: Because I'm saying "no, I didn't forget about this, and yes, it really is supposed to be any object". And I'm saying it to future maintainers, not to the compiler. 16:10:39 nyef: Hmm... a comment perhaps? Or (check-type xxx t) 16:10:58 Or just put it in with the other two type declarations? 16:13:11 *loke* always uses (declare (TYPE type foo)) 16:14:16 There's already a precedent for (declare (fixnum foo)) along with a precedent for (declare (type ... foo)) in these functions, so I'm going with the argument that standard types get the shorter treatment. 16:21:35 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 248 seconds] 16:38:55 -!- antgreen [~user@bas3-toronto06-1177890206.dsl.bell.ca] has quit [Remote host closed the connection] 16:49:12 attila_lendvai [~attila_le@87.247.51.76] has joined #sbcl 16:49:12 -!- attila_lendvai [~attila_le@87.247.51.76] has quit [Changing host] 16:49:12 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 16:49:14 nikodemus, Care to extend SLIME(-indentation) to align &rest arguments? :) 16:49:59 Qworkescence: what do you mean? 16:50:46 send email to slime-devel with the kind of indentation you'd like, and i'll look at it 16:51:06 (defun f (a b &rest c) ..) (f a b {c d e}) <-- it might be nice for c d e to be aligned at the same column, which is how keyword indentation works at the moment I believe 16:52:00 Qworkescence: can't figure out what you mean fore sure form a single line. need to see the indentation laid out 16:52:25 oh, i think i understand 16:52:36 i would not like that myself at all 16:52:53 so i'm extremely unlikely to implement it :) 16:53:17 a clean patch that does it only when explicitly requested via style or customization can be merged, though 16:54:07 Qworkescence pasted "indentation" at http://paste.lisp.org/display/126018 16:54:11 There 16:55:18 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 276 seconds] 16:55:38 i'm very doubtful if that generalizes to other functions using &rest 16:56:20 Does SBCL have a special mechanism for condition handling when it processes a --load argument? 16:56:21 also, keyword are indented based on them being :keywords, not based on the lambda-list 16:56:40 (sorry, didn't realize nikodemus wasn't done...) 16:57:11 rpg_: no special mechnism as such 16:57:25 it binds a few restarts. don't remember if it handles conditions or not offhand 16:58:03 I think I must be screwing up the restarts myself.... 16:59:24 nikodemus, What's an example where you might see that as a bad thing? I can only think of something like (defun my-+ (number &rest numbers) ...) 17:00:38 Qworkescence: i consider that typical 17:02:30 Maybe it's time to make &rest+n which requires a list of length at least n, and &rest is equivalent to &rest+0 ;). Oh, the joys of subtle semantic information. 17:03:14 ... Too bad you can't just have something like a SLIME-INDENT-RULES declaration... 17:03:42 nyef, :) 17:04:24 (Yes, that was an invitation to say "wait, yes we can actually do that, and here's how".) 17:04:53 -!- blumbri [1000@204.152.219.51] has quit [Ping timeout: 252 seconds] 17:05:46 At the very least, you could pull source-location information to find the function definition, and parse it to find the declarations. This would break down for any cleverness involved in generating the functions, but would cover the 90%-case nicely. 17:09:32 So, I have a build running now that should hopefully deal with the nasty race condition in SVIT due to the use of MAKE-LISP-OBJ while the GC is enabled... By not using MAKE-LISP-OBJ in the first place. 17:12:12 blumbri [1000@204.152.219.51] has joined #sbcl 17:25:29 i ended up trying to forward port david's incremental allocation stuff after all 17:26:40 ...and? 17:26:49 it all works and we have a magical happy fun land? 17:27:42 well, i've now succesfully built the forward port without incremental allocation enabled 17:28:01 still working on building it with it actually turned on... 17:30:50 a /lot/ of water has passed under the bridge since 1.0.12.42... 17:34:10 Bleh. Missed a DEFSETF. )-: 17:34:57 Which, of course, is not a slammable change. /-: 17:36:56 "failed to brk read-only and static space" 17:38:13 i wonder if darwin even has a functional brk... 17:38:58 ... or if it's just plain brk(2)en? 17:39:06 -!- Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has quit [Read error: Connection reset by peer] 17:42:16 -!- rpg_ [~rpg@mpls.sift.info] has quit [Quit: rpg_] 17:47:36 it probably works, you'd be surprised what relies on a functional brk/sbrk 17:47:39 emacs, for example 17:48:23 ah, the spaces are then probably just off 17:51:46 rpg [~rpg@mpls.sift.info] has joined #sbcl 17:52:24 aren't mmap and brk in the same process a no-no? 17:54:32 mmap tries to stay out of the way of brk until there's no other option. 17:54:44 well, with :incremental-allocation-uses-mmap i got as far as saving a warm core -- so progress 17:55:19 the warm core unfortunately doesn't work... 18:04:03 *nyef* tries to figure out how to disguise a playstation 3 as a desktop computer, so he can keep one around the office... 18:05:15 nyef: get a cheap case & route cables through the rear? (: 18:05:27 Yeah, maybe. 18:05:47 The case has to not act as a araday cage, though. 18:05:53 Err... Faraday cage. 18:08:13 lasercut a wooden case then (: 18:09:25 I think the other option is to actually set it up with linux and a keyboard and mouse, then hide the game controllers. 18:09:37 Oh, and not keep any ps3 games at the office. 18:09:38 ps3 doesn't run linux anymore 18:10:09 There's apparently a fix for that. 18:10:34 Then again, I don't know if said fix works, or how well it works. 18:12:40 I also don't want to spend out on the hardware unless I'm reasonably confident that I can get the software working, you know? 18:20:02 hm. it succesfully grows the page table at least once while pcl is building 18:20:31 but somehow the same operation goes astray on startup -- realloc() appeantly going haywire 18:29:24 homie` [~levgue@xdsl-78-35-154-167.netcologne.de] has joined #sbcl 18:31:18 -!- homie` [~levgue@xdsl-78-35-154-167.netcologne.de] has quit [Remote host closed the connection] 18:31:49 -!- homie [~levgue@xdsl-78-35-167-160.netcologne.de] has quit [Ping timeout: 240 seconds] 18:45:39 homie [~levgue@xdsl-78-35-154-167.netcologne.de] has joined #sbcl 18:46:27 -!- angavrilov [~angavrilo@217.71.227.181] has quit [Ping timeout: 276 seconds] 18:47:42 nikodemus: ? 18:49:25 my recollection is that the older incremental-allocation branch using sbrk is the one that's better tested. The -using-mmap branch was a quick attempt setting next to antifuchs at a congress, trying to get things running on MacOS, where brk doesn't work. 18:49:27 (MacOS kept being annoying though, and I didn't pursue it further.) 18:49:53 s/setting/sitting/ 18:51:47 lichtblau: ah, i'm on osx so... 18:52:14 the breakage is pretty weird, though 18:52:26 i'm about done for today at any rate 18:52:36 ... My OSX box has a VirtualBox VM for Linux. 18:53:29 Is SB-SYS:SAP-REF-LISPOBJ a NEWS-worthy change? 18:55:22 oh, yes, good idea. The commit log should be enough for people who play with internals, though, i'd think 18:55:54 lichtblau: haha, wow, that was ages ago! 18:57:45 Is faster and more robust SVIT a NEWS-worthy change, given that it's only been observed to actually fail once, on PPC? 19:03:55 ... Actually, on consideration, it can ONLY fail on PPC at present. 19:04:09 Still faster on all targets, though. 19:04:34 At least, I don't see how it can really fail on x86oids. 19:12:15 ... "The value NIL is not of type SB-DI:FRAME." 19:12:32 Let's discuss unwind-to-frame-and-call tests, shall we? 19:12:52 I'm going to presume that I'm not the one that broke them. 19:18:06 yeah, darwin's brk returns always -1 19:18:26 pha 19:18:40 doesn't even have the grace to set the errno to ENOSYS 19:18:50 now, food 19:18:53 -!- nikodemus [~nikodemus@cs181063174.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 19:18:55 gabnet [~gabnet@245.23.67.86.rev.sfr.net] has joined #sbcl 19:21:31 Okay, my PPC is now in shutdown until at least Monday. 19:21:47 I'll worry about d-x and related damage for the next release cycle. 19:22:20 poor neglected ppc port 19:23:25 Oh, I wouldn't say that. It still gets more attention than, say, MIPS. 19:23:57 It's probably the most-maintained non-x86oid port, really. 19:24:41 I suppose it's the token !x86 port, whereas everything else is just quietly bitrotting 19:25:22 I really need to see about fixing my pa-risc machine 19:27:51 I think that the ports that I'd really like to see maintained are PPC, MIPS, and ALPHA. Maybe also ARM, but we'd need a working port for that first. 19:28:02 why mips and alpha? 19:28:16 my manager has an old alpha which he keeps threatening to give me 19:28:24 only arm, ppc, and sparc are really left. 19:28:36 Alpha because of the memory models, both the 32-bit heap and the multi-CPU synchronization. 19:28:48 new mips hardware is being sold and developed, foom 19:29:07 no 32-bit mips port for openbsd, unfortunately 19:29:08 MIPS more because I rather like the ISA. 19:30:11 and if I were going to attempt porting an sbcl backend to 64-bit, I'd pick sparc rather than mips 19:30:21 oh, right. MIPS does still exist, Loongson. 19:30:22 Not PPC? 19:30:31 Forgot about that. 19:30:48 no ppc64 openbsd ports 19:31:59 maybe someone should work on that. :) 19:32:46 Hey, I hear FreeBSD supports it, you could switch! 19:41:00 heh 19:42:10 if someone was still making affordable ppc64 hardware then that might happen, but I doubt it will for a handful of macintosh models 19:42:36 nikodemus [~nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 19:42:36 -!- ChanServ has set mode +o nikodemus 19:55:05 joshe: Umm... Isn't the Cell processor in the playstation 3 a ppc64? 19:55:28 oh right, it is 19:55:48 I thought you couldn't run other OSes on it anymore though 19:56:08 Apparently, that limitation was broken last year. 19:56:40 ah 19:57:25 ... The XBox 360 apparently also uses a PPC of some sort, probably a PPC64. 20:04:16 -!- blumbri [1000@204.152.219.51] has quit [Ping timeout: 240 seconds] 20:05:26 antgreen [~user@bas3-toronto06-1177890206.dsl.bell.ca] has joined #sbcl 20:05:35 -!- nikodemus [~nikodemus@cs181063174.pp.htv.fi] has quit [Ping timeout: 260 seconds] 20:11:19 nyef: permanently? I thought they re-broke it every time there was a firmware update 20:11:24 udzinari [~user@ip-89-102-12-6.net.upcbroadband.cz] has joined #sbcl 20:12:17 Something like that. 20:12:45 Still, it might just be a matter of getting some hardware and waiting however long for a new exploit. 20:20:46 blumbri [1000@204.152.219.23] has joined #sbcl 20:41:13 Okay, heading out the door. 20:41:16 -!- nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has quit [Quit: g'night all.] 21:02:02 -!- pchrist [~spirit@gentoo/developer/pchrist] has quit [Quit: leaving] 21:05:19 -!- rpg [~rpg@mpls.sift.info] has quit [Ping timeout: 244 seconds] 21:06:38 -!- udzinari [~user@ip-89-102-12-6.net.upcbroadband.cz] has quit [Remote host closed the connection] 21:07:04 udzinari [~user@ip-89-102-12-6.net.upcbroadband.cz] has joined #sbcl 21:18:10 all 3 current consoles use PPC. Xbox360 = 3-core PPC64, PS3 = 1 PPC64 + 6x(?) vector processors, Wii = 1 PPC32 21:20:26 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 21:23:35 sdemarre [~serge@91.176.94.227] has joined #sbcl 21:57:04 -!- blumbri [1000@204.152.219.23] has quit [Ping timeout: 240 seconds] 21:59:23 -!- sdemarre [~serge@91.176.94.227] has left #sbcl 22:09:28 blumbri [~blumbri@c-67-181-176-186.hsd1.ca.comcast.net] has joined #sbcl 22:21:40 -!- blumbri [~blumbri@c-67-181-176-186.hsd1.ca.comcast.net] has quit [Ping timeout: 258 seconds] 22:22:35 -!- gabnet [~gabnet@245.23.67.86.rev.sfr.net] has quit [Quit: Quitte] 22:29:02 -!- leuler [~user@p5490336F.dip.t-dialin.net] has quit [Quit: ERC Version 5.1.2 $Revision: 1.796.2.6 $ (IRC client for Emacs)] 22:34:32 blumbri [1000@204.152.219.46] has joined #sbcl 22:37:34 christoph_debian [~user@oteiza.siccegge.de] has joined #sbcl 22:44:47 rpg [~rpg@216.243.156.16.real-time.com] has joined #sbcl 23:24:13 -!- blumbri [1000@204.152.219.46] has quit [Ping timeout: 240 seconds] 23:36:57 blumbri [1000@204.152.219.7] has joined #sbcl