01:24:43 -!- drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 01:25:48 drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has joined #sbcl 01:27:07 -!- davazp [~user@92.251.188.53.threembb.ie] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 01:56:00 bege [~bege@S0106001d7e5132b0.ed.shawcable.net] has joined #sbcl 02:23:10 -!- drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 02:42:50 drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has joined #sbcl 03:14:46 enupten [~neptune@c-24-18-243-195.hsd1.wa.comcast.net] has joined #sbcl 04:15:10 attila_lendvai [~attila_le@92.46.7.103] has joined #sbcl 04:15:10 -!- attila_lendvai [~attila_le@92.46.7.103] has quit [Changing host] 04:15:10 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 04:33:09 -!- p_nathan [~vlion@76.178.163.213] has quit [Ping timeout: 248 seconds] 04:37:46 Strigoides [~owen@114-134-0-23.lightwire.co.nz] has joined #sbcl 05:02:52 sdemarre [~serge@55.152-66-87.adsl-dyn.isp.belgacom.be] has joined #sbcl 05:16:14 -!- drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 05:18:47 tcr [~tcr@46-126-110-164.dynamic.hispeed.ch] has joined #sbcl 05:22:56 attila_lendvai1 [~attila_le@92.46.7.103] has joined #sbcl 05:22:57 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Disconnected by services] 05:22:57 -!- attila_lendvai1 [~attila_le@92.46.7.103] has quit [Changing host] 05:22:57 attila_lendvai1 [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 05:50:04 -!- sdemarre [~serge@55.152-66-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 256 seconds] 05:59:57 -!- attila_lendvai1 [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 06:01:00 -!- Strigoides [~owen@114-134-0-23.lightwire.co.nz] has quit [Quit: leaving] 06:26:13 prxq [~mommer@mnhm-590c3f70.pool.mediaWays.net] has joined #sbcl 06:32:22 -!- tcr [~tcr@46-126-110-164.dynamic.hispeed.ch] has quit [Quit: Leaving.] 06:38:16 -!- enupten [~neptune@c-24-18-243-195.hsd1.wa.comcast.net] has quit [Remote host closed the connection] 07:03:39 tcr [~tcr@77-56-40-229.dclient.hispeed.ch] has joined #sbcl 07:41:34 -!- minion [~minion@50.7.166.114] has quit [Ping timeout: 246 seconds] 07:41:35 -!- specbot [~specbot@50.7.166.114] has quit [Ping timeout: 255 seconds] 07:50:11 davazp [~user@178.167.171.75.threembb.ie] has joined #sbcl 08:27:30 -!- scymtym_ [~user@ip-5-147-116-166.unitymediagroup.de] has quit [Ping timeout: 272 seconds] 08:28:04 minion [~minion@50.7.166.114] has joined #sbcl 08:28:06 specbot [~specbot@50.7.166.114] has joined #sbcl 08:28:58 -!- Bike [~Glossina@67-5-241-73.ptld.qwest.net] has quit [Quit: leaving] 09:03:52 -!- akovalenko [~user@195.18.46.21] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 09:15:34 akovalenko [~user@195.18.46.21] has joined #sbcl 09:33:56 rudi [~rudi@1x-193-157-247-171.uio.no] has joined #sbcl 09:50:06 angavrilov [~angavrilo@217.71.227.190] has joined #sbcl 10:46:04 foreignFunction [~niksaak@ip-4761.sunline.net.ua] has joined #sbcl 11:19:01 Munksgaard [~philip@192.38.109.188] has joined #sbcl 11:40:25 pranavrc [~pranavrc@122.164.210.80] has joined #sbcl 11:40:30 -!- pranavrc [~pranavrc@122.164.210.80] has quit [Changing host] 11:40:30 pranavrc [~pranavrc@unaffiliated/pranavrc] has joined #sbcl 12:20:10 drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has joined #sbcl 12:20:13 attila_lendvai [~attila_le@92.46.7.103] has joined #sbcl 12:20:14 -!- attila_lendvai [~attila_le@92.46.7.103] has quit [Changing host] 12:20:14 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 12:31:36 -!- drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 12:50:55 drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has joined #sbcl 12:55:44 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 13:01:18 -!- drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 13:02:08 -!- jdz [~jdz@85.254.212.34] has quit [Quit: Byebye.] 13:05:06 jdz [~jdz@85.254.212.34] has joined #sbcl 13:08:47 -!- flip214 [~marek@unaffiliated/flip214] has quit [Ping timeout: 268 seconds] 13:10:16 flip214 [~marek@86.59.100.100] has joined #sbcl 13:10:16 -!- flip214 [~marek@86.59.100.100] has quit [Changing host] 13:10:17 flip214 [~marek@unaffiliated/flip214] has joined #sbcl 13:12:09 -!- akovalenko [~user@195.18.46.21] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 13:13:57 akovalenko [~user@195.18.46.21] has joined #sbcl 13:22:25 wbooze [~wbooze@xdsl-78-35-144-234.netcologne.de] has joined #sbcl 13:30:06 -!- xymox [lechuck@unaffiliated/contempt] has quit [Ping timeout: 264 seconds] 13:32:41 xymox [lechuck@unaffiliated/contempt] has joined #sbcl 13:35:22 attila_lendvai1 [~attila_le@92.46.7.103] has joined #sbcl 13:35:22 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Disconnected by services] 13:35:22 -!- attila_lendvai1 [~attila_le@92.46.7.103] has quit [Changing host] 13:35:22 attila_lendvai1 [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 13:45:25 stassats [~stassats@wikipedia/stassats] has joined #sbcl 13:55:30 -!- rudi [~rudi@1x-193-157-247-171.uio.no] has quit [Quit: Client exciting.] 13:56:11 drmeister [~drmeister@mobile-166-147-108-214.mycingular.net] has joined #sbcl 14:08:41 nyef [~nyef@c-50-157-244-41.hsd1.ma.comcast.net] has joined #sbcl 14:08:50 G'morning all. 14:09:54 mooorning missa nyef 14:10:41 attila_lendvai [~attila_le@92.46.7.103] has joined #sbcl 14:10:41 -!- attila_lendvai [~attila_le@92.46.7.103] has quit [Changing host] 14:10:41 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 14:11:48 -!- attila_lendvai1 [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Read error: Connection reset by peer] 14:11:58 -!- drmeister [~drmeister@mobile-166-147-108-214.mycingular.net] has quit [Remote host closed the connection] 14:12:40 hmm.. can I ask someone to check my proposal for GSoC? (someone with access from the org panel) 14:13:53 drmeister [~drmeister@mobile-166-147-108-214.mycingular.net] has joined #sbcl 14:13:54 https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/p_l/3023 (that should work for the link, right?) 14:14:25 brb - I'll be in ~20 minutes 14:15:11 uh, it says I am not a mentor for the project it was submitted to 14:15:38 maybe in google's world I'm not (because I am the org admin) 14:22:01 oh, but hey, I've received it by e-mail. p_l|omoikane, I think at the least I'd want to see more detail about your work placement commitment 14:31:07 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 14:31:14 attila_lendvai [~attila_le@92.46.7.103] has joined #sbcl 14:31:14 -!- attila_lendvai [~attila_le@92.46.7.103] has quit [Changing host] 14:31:14 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 14:35:39 -!- drmeister [~drmeister@mobile-166-147-108-214.mycingular.net] has quit [Remote host closed the connection] 14:39:48 Krystof: Yeah, I figured it to be the biggest possible blocker at the moment, although By the time GSoC gets to speed the actual workload is probably going to be much lower 14:54:35 drmeister [~drmeister@wirelessNAT188.wireless.temple.edu] has joined #sbcl 14:54:47 updated. Other than the work commitment (which is understandable issue), anything screaming out from my proposal? 15:03:56 drmeiste_ [~drmeister@wirelessNAT188.wireless.temple.edu] has joined #sbcl 15:04:28 -!- drmeister [~drmeister@wirelessNAT188.wireless.temple.edu] has quit [Read error: Connection reset by peer] 15:07:45 p_l|omoikane: I find it worrying that the big part of the project is planned to be finished half way through the work period, in only two weeks... even more so considering that the plan doesn't sketch how you think you'll achieve that. 15:10:35 Ugh. I'm looking at the current implementation of map-allocated-objects (not my rewrite), and there's a bit where it skips forward by a single word if it decides that whatever object it's looking at is bogus, completely ignoring the fact that our allocation granularity is two words. 15:11:00 nyef: yeah, I don't get that part either. 15:11:54 I also don't get why it doesn't skip to the next allocation region on too large objects. 15:13:14 Well, the other thing is that it should never *SEE* a too-large object. 15:15:08 If we assume that the heap is in a consistent state, which it has to be otherwise the GC would pitch a fit, and that a flip can't happen (which is what the WITHOUT-GCING is for), then the bytes_used field on the page tables is going to be pointing to an object boundary. 15:15:39 The only thing that should be able to screw things up is closing a multi-page region after having scanned the first page but not any of the later pages. 15:17:45 Of course, the existing implementation is more than a bit screwy. I'm trying to figure out how to get from it to my rewrite in reasonable-looking stages, so there's no big "and here I've torn the entire thing apart and rewritten it, it's better now, honest" commit. 15:21:23 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 245 seconds] 15:33:45 drdo [~user@85.207.54.77.rev.vodafone.pt] has joined #sbcl 15:33:48 drmeister [~drmeister@wirelessNAT188.wireless.temple.edu] has joined #sbcl 15:33:53 -!- drmeiste_ [~drmeister@wirelessNAT188.wireless.temple.edu] has quit [Read error: Connection reset by peer] 15:34:03 Bike [~Glossina@67-5-241-73.ptld.qwest.net] has joined #sbcl 15:40:37 -!- drmeister [~drmeister@wirelessNAT188.wireless.temple.edu] has quit [Read error: Connection reset by peer] 15:40:57 drmeister [~drmeister@wirelessNAT188.wireless.temple.edu] has joined #sbcl 15:45:20 -!- drmeister [~drmeister@wirelessNAT188.wireless.temple.edu] has quit [Ping timeout: 255 seconds] 15:47:45 kanru` [~kanru@118-168-245-145.dynamic.hinet.net] has joined #sbcl 15:51:34 -!- Munksgaard [~philip@192.38.109.188] has quit [Ping timeout: 246 seconds] 15:52:10 pkhuong: oh, thanks, didn't notice I got too aggressive there 15:57:37 pkhuong: I apparently skipped a few things that were obvious to me but now I see were completely missing from proposal 15:59:01 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 16:01:12 drmeister [~drmeister@farnsworth.chem.temple.edu] has joined #sbcl 16:13:13 pkhuong: I submitted a bit of an update, with references to specific bits of MPS I think would be used for the deliverables 16:17:27 -!- kanru` [~kanru@118-168-245-145.dynamic.hinet.net] has quit [Ping timeout: 276 seconds] 16:22:15 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 16:25:40 ... This is going to interact with / break the work I'm doing on ROOM, isn't it? 16:28:27 nyef: probably? 16:30:37 Could someone critique my proposal as well? 16:30:40 https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/robgssp/1 16:31:03 nyef: well, as point 4, I have work for things that might fix what it breaks 16:31:27 I haven't read the proposal, and suspect that I CAN'T read the proposal. 16:31:47 nyef: https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/p_l/3023 try? 16:32:06 I can set it open, I guess, though I'll probably remove the link to CV for that time 16:32:30 Is this going to change any of the in-memory object layouts, or just the arrangement and management of the heap spaces? 16:33:20 nyef: I doubt it would involve any change in object layouts 16:33:23 It's not public, I'm not you, nor am I a mentor. And I don't know that I need to read the proposal, really. 16:33:29 https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/p_l/3023 <--- okay, public now 16:33:51 nyef: you might have interesting and valuable criticism of it :) 16:34:02 Okay, so at least part of what I've got will still be valid, and will still be more valid than what we have now anyway. 16:35:52 ... unfortunately now that I delved deepere into MPS docs it seems that a lot of the juicier stuff is proprietary 16:35:53 p_l|omoikane: MPS's licence isn't GPL 16:36:12 p_l|omoikane: where do you see that ? 16:37:24 fe[nl]ix: isn't? I guess I must have mixed stuff up, let me correct it 16:37:26 I'm unfamiliar with MPS, but how well does it interact with threaded runtimes, and what are the options for "inline" allocation of memory? 16:39:11 -!- davazp [~user@178.167.171.75.threembb.ie] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 16:39:19 fe[nl]ix: fixed 16:40:18 nyef: there's support for threaded runtimes (seems to be a bit similar to what I recall of SBCL's approach, actually) and as for inline... what kind of inline? 16:42:13 The compiler knows how to allocate memory from either gencgc or cheneygc without having to call out to a specialized allocation function, though there is a "trap" if it runs out of space in the current alloc region. 16:43:05 from when i played with mps it seemed that allocation was commonly done with a system of C macros (so, inline) 16:43:25 robgssp: it would help if you made it public 16:44:02 nyef: hmmm 16:44:25 Would anyone here claim that the alpha and hppa backends are "maintained"? 16:45:04 technically, it has a very simple allocation protocol based on "init", "alloc" and "limit" variables - init is the current pointer to free space, alloc is the newly allocated space, and limit is the limit of the region 16:47:16 I'm willing to claim that the MIPS backend is somewhat "maintained", though not as much as the sparc and ppc backends. 16:47:40 How thread-safe is that allocation protocol? 16:48:17 This platform breakdown would mean that cheneygc is supported on all non-x86oid platforms, and gencgc is supported on all maintained platforms other than MIPS... 16:48:37 nyef: basically a two-phase transaction system 16:49:05 scymtym_ [~user@ip-5-147-116-166.unitymediagroup.de] has joined #sbcl 16:51:21 you have two functions which implement the safety part, mps_reserve and mps_commit 16:52:05 fe[nl]ix: Yes it would. Fixed. 16:55:13 robgssp: One crazy possibilities for using jump tables with symbol data on threaded systems is to use the TLS-index of the symbol as a lookup key, though this could run into problems as TLS indexes are a finite, non-renewable resource. 16:57:01 s/possibilities/possibility/ 16:59:33 robgssp: Another approach would be to have a vector of possible symbols and to use the index of the symbol within the vector as an index. 17:00:01 This second one scales better in terms of the number of symbols, but not as well in terms of execution time. 17:04:35 nyef: for a vector of symbols you'd have to look the symbol up in it first, which would itself be linear-time, right? 17:04:53 so would there really be any time savings there? 17:08:03 :/ 17:08:30 the more I delve into MPS docs, the less enthusiastic I get. It could be plain old tiredness, though 17:11:41 robgssp: You're doing the lookup in a tight loop, rather than a stack of conditionals, which has to help branch prediction, followed by a computed jump which has to kill branch prediction... I have no idea if it'd be time-saving or not, but it should at least be space-saving. 17:14:25 omoikane: why less enthusiastic? 17:16:01 mmuggli: too many references to contracting Ravenbrook make me thing of the released code more in terms for tech demo while actual nice stuff is propriertary 17:16:04 brb, food 17:19:54 which nice stuff? 17:21:45 nyef: true. wrt your first suggestion, do you mean that symbol references are already kept in tls? 17:26:38 mmuggli: they constantly imply about more complex, interesting GC implementations 17:29:09 Any symbol with a thread-local binding will have a TLS index for its thread-local value. It's not impossible to arrange for a symbol to have a TLS index even without anyone binding it (or to arrange to bind it temporarily so that it will have a TLS index). 17:33:06 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 264 seconds] 17:44:34 nyef: how small is TLS? 17:44:56 I don't remember offhand, I'm afraid. 17:47:52 omoikane: well, even if so, it still provides flexibility and code sharing between clients. One paper I read tested eight different garbage collectors on a bunch of programs, and each of the eight beat all the others on at least one of those programs, so having the option to choose would be great. 17:48:45 mmuggli: well, yeah. Anyway, I submitted my proposal, though I am definitely less sure about it now than few hours ago 17:48:53 omoikane: FWIW, I sent in a proposal to integrate MPS too, if you get it, no hard feelings and I'll be rooting for you! 17:49:34 mmuggli: you have bigger chances (for various reasons). At least I've still got one more chance with GSoC next year (thanks to final exams being in June :>) 17:49:50 omoikane: less sure because it seems less beneficial, or too complicated? 17:51:15 mmuggli: less sure in terms of benefits, I think 17:51:40 still, might be nice way to play with more allocation strategies, I wonder if it can be mangled into concurrent collector 17:52:03 at the very least we should get a better documentation of how GC interacts with the rest :) 17:52:21 true! have you worked with GC algos before? 17:53:17 nothing practical, but I know how they work in general and been angling to get dirty for some time 17:54:09 GSoC was, in a way, an excuse to grab someone to pester more while also getting a bit of extra cash (translating to "I might get earn enough for both a laptop and a place to stay during final year!" ;)) 17:56:23 hmmm... OpenDylan got an implementation of exact collector if I'm reading right 17:56:28 might be worth stealing :> 17:57:08 it's just regular MPS 17:57:12 (=precise?) as opposed to conservative? 17:57:25 I think that's orthogonal to the GC algo 17:57:38 ah nope 17:57:40 misread 17:57:58 mmuggli: actually, MPS docs mention "contact us if you need exact collector" :) 18:04:43 also, seems they didn't get any exception to the requirement of distributing source code with your binaries 18:05:52 I suspect the rest of the OpenDylan runtime and compiler is exact, but when they use the Boehm collector, all but the roots are scanned for refs conservatively 18:07:37 p_l|omoikane: "Software that makes use of the Memory Pool System only via the Dylan programming language using the Open Dylan implementation and any accompanying software is exempt from clause 3 of the license, provided that the Dylan program is not providing memory management services." 18:09:00 pkhuong: ah. I blame being up for too long (for unrelated reasons I ended up staying up all night) 18:09:22 lack of sleep -> jumping to conclusions 18:10:00 mmuggli: as for precise, doesn't that require a bit of handling in GC regarding stack scanning? 18:13:14 GC certainly needs to know about live objects on the stack, else it would collect their referants and all hell would break loose :) 18:13:28 -!- pranavrc [~pranavrc@unaffiliated/pranavrc] has quit [Quit: Ping timeout: ] 18:46:41 -!- Bike [~Glossina@67-5-241-73.ptld.qwest.net] has quit [Ping timeout: 255 seconds] 18:48:30 Bike [~Glossina@67-5-235-38.ptld.qwest.net] has joined #sbcl 19:05:09 attila_lendvai [~attila_le@92.46.7.103] has joined #sbcl 19:05:09 -!- attila_lendvai [~attila_le@92.46.7.103] has quit [Changing host] 19:05:09 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 19:14:10 -!- redline6561 [~redline65@li69-162.members.linode.com] has quit [Quit: ZNC - http://znc.in] 19:33:58 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 19:40:57 redline6561 [~redline65@li69-162.members.linode.com] has joined #sbcl 19:44:05 davazp [~user@178.167.157.176.threembb.ie] has joined #sbcl 19:52:36 -!- angavrilov [~angavrilo@217.71.227.190] has quit [Ping timeout: 276 seconds] 19:53:26 stassats [~stassats@wikipedia/stassats] has joined #sbcl 19:56:07 -!- drmeister [~drmeister@farnsworth.chem.temple.edu] has quit [Remote host closed the connection] 19:58:44 drmeister [~drmeister@wirelessNAT188.wireless.temple.edu] has joined #sbcl 20:01:07 sdemarre [~serge@55.152-66-87.adsl-dyn.isp.belgacom.be] has joined #sbcl 20:19:20 -!- sdemarre [~serge@55.152-66-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 256 seconds] 20:19:22 -!- drmeister [~drmeister@wirelessNAT188.wireless.temple.edu] has quit [Remote host closed the connection] 20:20:55 drmeister [~drmeister@farnsworth.chem.temple.edu] has joined #sbcl 20:32:00 -!- milosn [~milosn@user-5af50a8b.broadband.tesco.net] has quit [Ping timeout: 264 seconds] 20:32:04 milosn_ [~milosn@user-5af50a8b.broadband.tesco.net] has joined #sbcl 20:32:33 -!- milosn_ is now known as milosn 20:55:37 -!- drmeister [~drmeister@farnsworth.chem.temple.edu] has quit [Remote host closed the connection] 21:06:29 drmeister [~drmeister@mobile-166-147-108-214.mycingular.net] has joined #sbcl 21:18:31 hm, :trace-file showing me a not very pretty disassemble, no annotations 21:19:47 only error traps are annotated 21:27:43 i can look at the pretty disassembly in the inspector, can't figure what's wrong with :trace-file 21:28:23 -!- drmeister [~drmeister@mobile-166-147-108-214.mycingular.net] has quit [Remote host closed the connection] 21:36:20 -!- nyef [~nyef@c-50-157-244-41.hsd1.ma.comcast.net] has quit [Quit: G'night all.] 21:36:39 drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has joined #sbcl 21:38:23 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Quit: Leaving.] 21:40:19 i assume that it's safe to do (inst cmp x nil-value), i.e., it won't be sign-extended? 21:48:00 looks like, that fact makes values-list one byte shorter 21:58:17 -!- drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 22:05:47 -!- scymtym_ [~user@ip-5-147-116-166.unitymediagroup.de] has quit [Remote host closed the connection] 22:06:41 drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has joined #sbcl 22:19:44 -!- whoops [~whoops@2a01:4f8:161:41e1::2] has quit [Quit: Farewell] 22:26:02 whoops [~whoops@2a01:4f8:161:41e1::2] has joined #sbcl 22:27:18 -!- whoops [~whoops@2a01:4f8:161:41e1::2] has quit [Read error: Connection reset by peer] 22:31:03 I think we already assume that static space is < 2^31 22:31:28 an assembly-time check would be more robust 22:33:40 *stassats* tried to use XORPS XMM0, XMM0 MOVAPS [RAX-16], XMM0 instead of MOV QWORD PTR [RAX-16], 0 MOV QWORD PTR [RAX-8], 0 didn't turn out to be any faster, unsurprisingly, but 9 bytes smaller 22:40:18 whoops [~whoops@2a01:4f8:161:41e1::2] has joined #sbcl 22:49:03 -!- psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has quit [Remote host closed the connection] 22:56:16 psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has joined #sbcl 23:10:34 -!- danlentz [~danlentz@c-68-37-70-235.hsd1.nj.comcast.net] has quit [Remote host closed the connection] 23:19:19 -!- drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 23:20:02 -!- prxq [~mommer@mnhm-590c3f70.pool.mediaWays.net] has quit [Quit: Leaving] 23:29:53 drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has joined #sbcl 23:49:14 ASau`` [~user@p5797F028.dip0.t-ipconnect.de] has joined #sbcl 23:52:11 -!- ASau` [~user@p5797F5CD.dip0.t-ipconnect.de] has quit [Read error: Operation timed out]