00:11:22 hargettp [~anonymous@pool-71-184-181-149.bstnma.east.verizon.net] has joined #sbcl 01:46:08 -!- rme [rme@clozure-769EB638.chi.dsl-w.verizon.net] has quit [Quit: rme] 01:46:08 -!- rme [~rme@pool-70-104-121-193.chi.dsl-w.verizon.net] has quit [Quit: rme] 02:36:13 -!- hargettp [~anonymous@pool-71-184-181-149.bstnma.east.verizon.net] has quit [Quit: hargettp] 04:17:22 rbarraud [~rbarraud@118-92-12-143.dsl.dyn.ihug.co.nz] has joined #sbcl 04:36:25 -!- rbarraud [~rbarraud@118-92-12-143.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 04:37:05 rbarraud [~rbarraud@118-92-12-143.dsl.dyn.ihug.co.nz] has joined #sbcl 05:54:17 rbarraud_ [~rbarraud@118-92-0-92.dsl.dyn.ihug.co.nz] has joined #sbcl 05:55:23 -!- rbarraud [~rbarraud@118-92-12-143.dsl.dyn.ihug.co.nz] has quit [Ping timeout: 272 seconds] 06:04:41 -!- rbarraud_ [~rbarraud@118-92-0-92.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 06:05:17 rbarraud_ [~rbarraud@118-92-0-92.dsl.dyn.ihug.co.nz] has joined #sbcl 06:19:00 -!- rbarraud_ [~rbarraud@118-92-0-92.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 06:19:32 rbarraud_ [~rbarraud@118-92-0-92.dsl.dyn.ihug.co.nz] has joined #sbcl 06:23:32 -!- rbarraud_ [~rbarraud@118-92-0-92.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 06:24:08 rbarraud_ [~rbarraud@118-92-0-92.dsl.dyn.ihug.co.nz] has joined #sbcl 06:28:08 -!- rbarraud_ [~rbarraud@118-92-0-92.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 06:28:53 rbarraud_ [~rbarraud@118.92.0.92] has joined #sbcl 07:19:03 angavrilov [~angavrilo@217.71.227.181] has joined #sbcl 07:38:36 -!- rbarraud_ [~rbarraud@118.92.0.92] has quit [Ping timeout: 272 seconds] 08:57:38 attila_lendvai [~attila_le@4d6f5d3b.adsl.enternet.hu] has joined #sbcl 10:00:57 -!- Krystof [~csr21@84-51-132-95.christ977.adsl.metronet.co.uk] has quit [Ping timeout: 272 seconds] 10:03:41 hargettp [~anonymous@pool-71-184-181-149.bstnma.east.verizon.net] has joined #sbcl 10:31:35 -!- hargettp [~anonymous@pool-71-184-181-149.bstnma.east.verizon.net] has quit [Quit: hargettp] 10:34:52 hargettp [~anonymous@pool-71-184-181-149.bstnma.east.verizon.net] has joined #sbcl 10:37:34 Krystof [~csr21@84-51-132-95.christ977.adsl.metronet.co.uk] has joined #sbcl 10:37:34 -!- ChanServ has set mode +o Krystof 10:42:32 rbarraud [~rbarraud@118-92-0-92.dsl.dyn.ihug.co.nz] has joined #sbcl 10:44:03 nikodemus [~nikodemus@cs181199216.pp.htv.fi] has joined #sbcl 10:44:03 -!- ChanServ has set mode +o nikodemus 10:50:36 -!- rbarraud [~rbarraud@118-92-0-92.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 10:51:21 rbarraud [~rbarraud@118-92-0-92.dsl.dyn.ihug.co.nz] has joined #sbcl 10:55:20 -!- rbarraud [~rbarraud@118-92-0-92.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 10:55:46 rbarraud [~rbarraud@118-92-0-92.dsl.dyn.ihug.co.nz] has joined #sbcl 11:00:48 -!- rbarraud [~rbarraud@118-92-0-92.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 11:01:31 rbarraud [~rbarraud@118-92-0-92.dsl.dyn.ihug.co.nz] has joined #sbcl 11:02:25 -!- rbarraud [~rbarraud@118-92-0-92.dsl.dyn.ihug.co.nz] has quit [Read error: Connection reset by peer] 11:15:12 -!- nikodemus [~nikodemus@cs181199216.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 11:49:42 -!- hargettp [~anonymous@pool-71-184-181-149.bstnma.east.verizon.net] has quit [Quit: hargettp] 12:14:56 hargettp [~anonymous@pool-71-184-181-149.bstnma.east.verizon.net] has joined #sbcl 12:27:33 davazp [~user@128.Red-88-6-207.staticIP.rima-tde.net] has joined #sbcl 13:07:08 -!- davazp [~user@128.Red-88-6-207.staticIP.rima-tde.net] has quit [Remote host closed the connection] 13:19:05 rme [~rme@pool-70-104-121-193.chi.dsl-w.verizon.net] has joined #sbcl 13:28:52 udzinari [~user@nat/ibm/x-lexzxvxzmehnmmhl] has joined #sbcl 13:31:36 -!- rme [~rme@pool-70-104-121-193.chi.dsl-w.verizon.net] has left #sbcl 13:33:10 froydnj [~froydnj@gateway.codesourcery.com] has joined #sbcl 13:36:53 Wow. Busy channel. 13:38:35 this is merely the start of our journey to World Domination 13:45:32 nikodemus [~nikodemus@cs181199216.pp.htv.fi] has joined #sbcl 13:45:32 -!- ChanServ has set mode +o nikodemus 13:55:01 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 14:19:13 rmarynch [~roman@bras-7-ge-62.122.200.234.utm.if.ua] has joined #sbcl 14:52:54 slyrus [~chatzilla@adsl-75-36-215-204.dsl.pltn13.sbcglobal.net] has joined #sbcl 15:04:27 pkhuong_ [~pkhuong@gravelga.xen.prgmr.com] has joined #sbcl 15:33:18 -!- attila_lendvai [~attila_le@4d6f5d3b.adsl.enternet.hu] has quit [Quit: Leaving.] 15:43:15 rmarynch: aroundp 15:46:34 nikodemus: Hello 15:56:45 hi, just updating one of your bugs 15:56:58 https://bugs.launchpad.net/sbcl/+bug/586940 15:57:06 does that make sense? 16:00:38 yes, thank you for pointing that problem out. I agree with your opinion 16:06:25 unless you know that something cannot have a negative effect on performance, it's better not to make assumptions :) 16:06:42 (we all do, of course) 16:08:20 Yep, it was a surprise for me to see this degradation :) 16:08:49 good idea, this #sbcl 16:09:25 seconded 16:09:43 definitely. 16:11:00 aye 16:11:41 all in favor...oh, wait, I guess we already passed that 16:13:13 froydnj: re peephole at the VOP level, do you think we could instead insert a tree-parsing phase to convert expressions to VOPs? 16:14:49 pkhuong_: tree-parsing = sexps -> VOPs? 16:15:06 no, something like IR1-ish -> VOP 16:15:39 what does that buy us re peepholing? 16:16:02 it gets us most of the transformations we'd want to perform via peephole, but in a slightly more powerful way. 16:16:35 e.g. in-place arithmetic, or recognizing x86 EA. 16:16:42 where does this tree-parsing phase get inserted in the pipeline? 16:17:20 somewhere around IR1 -> IR2. 16:17:42 VOPs are the right level of operations, but we'd have to recover the expression graph from TNs. 16:17:53 my main worry with implementing peepholing is that the peephole patterns will accumulate hacks that could be addressed by ir2optimization or even cleverness at ir1 16:18:17 right. That's what I'm trying to avoid with the tree parsing codegen. 16:18:42 pkhuong_: you mean tree-tiling_ 16:18:47 ?, even 16:19:40 froydnj: i'm pretty sure that there will always be stuff that you can do at a peephole pass that is fiendishly difficult earlier 16:19:56 nikodemus: oh, agreed. 16:20:51 nikodemus: seems to be a synonym; anyway, BURGS-style or simpler stuff like 16:21:14 pkhuong_: yes, that's what i meant as well 16:21:57 nikodemus: but for something like shl reg, 2 / mov reg2, [base + reg] => mov reg, [base + reg*2] 16:22:09 I implemented a version of Aho Johnson in scheme; it's effective on x86, easy, and the pattern language was decent. 16:22:24 that could be done by peepholing, but I think it should be done earlier 16:22:53 froydnj: same here. 16:23:06 as long as it gets done :) 16:23:11 true :) 16:23:19 (: 16:24:11 problem is, IR1 is slightly too high level, and IR2 is already flattened. The easy way would be to try and recover the data from IR2, like I did for cmov. 16:24:44 IR1.5? 16:24:58 attila_lendvai [~attila_le@4d6f5d3b.adsl.enternet.hu] has joined #sbcl 16:25:04 pkhuong_: I think a tree tiling pass (vop combination or somesuch) could be useful. ISTR there's a prologue optimization you can do if you could combine vops like that 16:25:05 bah. I'll try to figure out how to do it during IR1 -> IR2. 16:25:34 I'm sure others exist 16:26:02 but when looking at IR1 for vop emission it is already pretty flat 16:26:10 oh yeah, another point for IR2: we want to work with ptypes, conversions, etc. 16:26:27 nikodemus: yeah, we already go through lvars. 16:27:10 fuck it, I'll recover information at the bblock-level... I really have this feeling that, in ten years, we'll end up with two completely independent SSA passes. 16:28:17 nah, i predict that in 5 years we split our time between maintaining sbcl and writing a brand new compiler for a new dialect :P 16:28:55 I like my work to be minimally useful ;) 16:29:01 we can call it preCL ("prequel") ;) 16:29:38 and confuse the hell out of everyone who's heard of prescheme ;) 16:29:59 pkhuong_: did you say you know how to get generics into cold init? 16:31:09 because a GF protocol for basic-block-like-things, etc, might make things like multiple similar-but-different passes less terrible 16:31:42 nikodemus: sure, but it's a hack: write a static mini-clos to compiler everything in the host, and then regenerate all the methods post-PCL 16:32:13 or, much more likely: for our huge etypecase, punt to a GF instead of erroring out. 16:32:13 it's not a terrible hack, really 16:32:57 especially if it does at least standard method combinations so you can do useful things with it 16:33:16 we already have like 3-5 object systems lying around 16:33:32 method ordering might be hard to get exactly right. 16:33:54 with only single inheritance? 16:33:59 ok :) 16:34:30 i mean if classes aren't in cold init, then it's just defstructs :) 16:34:31 with single inheritance and no MOP/method combinations, a dispatch tree should be decent. 16:36:06 the !foo magic macros to accumulate top-level forms work across multiple files, right? 16:39:14 drewc [~user@S01060013101b6ddb.vc.shawcable.net] has joined #sbcl 16:43:12 ... May we collect the majority of requirements (about new features/optimizations) to the compiler and then design some small architecture document? Just to have the general vision of the whole thing 16:45:28 pkhuong_: if i understand your question correctly, yes 16:46:48 rmarynch: a set of requirements makes sense for a discrete subproject. for general work on sbcl, not so much. 16:48:08 -!- udzinari [~user@nat/ibm/x-lexzxvxzmehnmmhl] has quit [Remote host closed the connection] 16:50:27 but if you think such a document would be helpful, well, it's not impossible 16:52:41 I mean 'compiler core' (Python), not the whole SBCL. There are many desirable features, but they should be fit into the single architecture. 16:53:18 rmarynch: i'm not sure what you mean 16:53:27 -!- attila_lendvai [~attila_le@4d6f5d3b.adsl.enternet.hu] has quit [Quit: Leaving.] 16:53:36 pipping [pipping@exherbo/developer/pipping] has joined #sbcl 16:54:11 stassats [~stassats@wikipedia/stassats] has joined #sbcl 16:54:33 hi. is this the right place for a quick bug report? 16:54:43 launchpad is way better 16:54:50 here it just gets lost 16:54:57 alright 16:55:03 https://bugs.launchpad.net/sbcl 16:55:34 if you mean describing the current state of affairs in a document, then yes, the cmucl internals docs should be updated to reflect the state of sbcl (but eliminating details which keep changing) 16:55:53 nikodemus: No, I mean a roadmap or so 16:56:14 if you mean going over things we'd like to see and whiteboarding a new compiler design to cover that, i don't think so given the current manpower 16:58:08 *except* if/when someone(s) are willing and able to spend a better part of a year refactoring/writing a ton of code 17:00:18 I think about adding the SSA pass, but the scope is as you have pointed - a year or so. Hmm... 17:00:41 -!- Krystof [~csr21@84-51-132-95.christ977.adsl.metronet.co.uk] has quit [Ping timeout: 255 seconds] 17:02:56 well, SSA pass for a pristine compiler is easy -- not counting the optimizations on SSA, just back and forth conversions -- but given the way things are tangled up between IR1 and IR2... it becomes trickier than it should be 17:04:30 it is too costly to introduce SSA just to fix the non-linear lvars. So, the optimizations should benefit from it as well 17:06:26 definitely 17:07:44 are you thinking of a separate SSA-form, or an SSAified IR1? 17:09:01 there are two variants: 1. Come to SSA after find-initial-dfo, and come out before IR1-phases 2. Drop all IR1 part and come out of SSA to IR2 (VOPs) 17:09:42 I prefer the second, but it is a year project for me 17:09:45 nikodemus: it's https://bugs.launchpad.net/sbcl/+bug/626930 now 17:10:58 thanks 17:12:25 one of the things that bugs me to no end is that components typically have several functions which are logically part of a single graph, but are opaque to analysis 17:17:03 What is interesting, CLISP compiler core is a single 500 KB lisp file. This makes me think that early SSA skeleton could be done in several months 17:17:34 the hell comes with code analysis, as usual 17:18:15 clisp does SSA?! 17:18:21 no 17:18:36 but it does Lisp compilation :)) 17:18:38 but really, SSA conversion itself is easy 17:19:11 agree, and there is a ton of papers 17:19:43 the correct unit to use is man-days, not weeks or months :) 17:19:49 rmarynch: 500kb seems large for a file 17:19:56 the trouble comes from making existing code play nice with it 17:20:39 slyrus: but there is the whole compiler core. In SBCL it has around 5M of so, in many files 17:21:15 rmarynch: clisp compiles to a high-level VM, comparable to out vops 17:21:29 so you need to discount all the backends 17:22:04 nikodemus: I do not compare these implementations, I just say what is the minimal compiler frontend size 17:22:05 clisp doesn't optimize very much at all, so you need to discount pretty much all the defoptimizers and deftransforms 17:22:29 rmarynch: I thought you meant 500kb of lisp code, not compiled output. I don't think the SBCL source is anywhere near 5Mb. 17:23:23 rmarynch: sure. a minimal compiler can be pretty small, especially if you have a nice VM to compile to 17:23:45 nikodemus: so, in case we have a plain SSA without any optimizations, we are likely to have 500 KB of sources. Not so huge. 17:23:52 but i don't see the bearing this has on estimating how long implementing SSA takes 17:24:00 ah, wait 17:25:45 rmarynch: i have a private hobby-compiler for a lispy dialect, which is 6K loc at the monent. this includes 2 IRs + SSA and codegen 17:26:36 counting lines from another vaguely similar project is a really bad way to estimate 17:27:25 -!- slyrus [~chatzilla@adsl-75-36-215-204.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 252 seconds] 17:27:35 nikodemus: maybe, but this gives the upper limit for sure:) 17:27:56 on an unrelated note, what does it take to turn "foreign function: #x806664B" frame description into something intelligible? 17:28:02 let's ignore IR2. let's say you want an IR1 -> SSA pass, which outputs the SSA as .dot files for viewing. that should be ~1K loc, and is unlikely to take more than two full weeks 17:29:23 the place where it gets hairy is getting the interface between IR1 and IR2 right. it might turn out surprisingly easy, or absolutely terrifying -- i would peg that at anything between 1 week and 2 months 17:29:37 and i mean not manually 17:30:03 stassats: probably just ensuring that _USE_GNU is turned on while groveling for presence of dladdr (it's non-posix) 17:30:18 slyrus [~chatzilla@adsl-75-36-215-204.dsl.pltn13.sbcglobal.net] has joined #sbcl 17:30:21 (at least that's what tcr said yesterday) 17:30:56 (when i say 1 week, i mean 40h) 17:33:46 Well, that is a promising estimate. What about direct CL -> SSA -> IR2? Or we should keep IR1 optimizations/transformations? 17:38:51 rmarynch: definitely. IR1 is where most of the CL-related special knowledge lives -- and unless you run them you don't have much to optimize because everything interesting is full of function calls that can do anything 17:39:42 which is actually the reason why I suspect SSAifying IR1 might be a better option 17:40:01 not sure at all, though 17:41:06 nikodemus: so, the good place for SSA phase is between the end of IR1 and the start of IR2? Or we just should SSAify the IR1 component early and keep it in that form throughout IR1 phases? 17:41:34 rmarynch: IR1 optimizations really need to iterate 17:43:18 so i suspect something like: IR1 conversion, [loop: some IR1 opt1, SSAify IR1, SSA opt, deSSAify IR1 ], IR2 conversion 17:44:02 jsnell: thanks for the pointer 17:44:51 nikodemus: oof, that sounds expensive 17:45:10 froydnj: SSA conversion is cheap compared to constraint propagation :) 17:45:33 btw, we can move CP to SSA phase, can't we? 17:45:56 probably so. but that's still quite a bit of extra work to be doing, and lots of garbage besides 17:45:59 i think so, but that makes SSA non-optional :/ 17:46:29 why should it be optional? 17:46:38 perfomance reasons 17:46:45 for the transformations we're interested in, SSA in IR1 might not be necessary. 17:47:17 Flow-sensitive analyses would do just as well; the advantage of SSA is normalization performance, and we're already performing slow fixpointed rewrites in IR1. 17:48:41 ideally we should be able to go directly from IR1 conversion to IR2 convertion without any optimizations -- but currently a many of them are required 17:50:08 basically, we'd have to modify the way variables are analysed to allow analyses/transforms to consider the range of a given variable *at a program point*. 17:52:04 you're talking about replacing parts of cprop? 17:52:19 I suppose it could work that way. 17:52:58 it should also change some things during codegen. 17:53:11 why? i don't see that 17:53:23 to get more benefits 17:53:33 oh, right 17:54:01 no, wait, what? 17:55:07 we perform regalloc on variables 17:56:19 SSA would implicitly get us stuff like (setf x ...) [use x], without explicitly allocating a register for *the variable x*, or going through a value cell (modulo barriers) 17:56:55 instead, we allocate a register for a variable, and use that register throughout its lifetime, even if we're spilling, etc. 17:57:11 oh, yes! 17:57:24 time to go --> good night 17:57:30 -!- nikodemus [~nikodemus@cs181199216.pp.htv.fi] has quit [Quit: Leaving] 17:57:51 so, again, if we change our thinking to allocate registers to values (or variables at program points), we get the same (finaly) effect as SSA. 18:01:05 pkhuong_: this is a good idea. But I do not know how it should be implemented. Is there some compiler feature which is good as a training task, for the newbie like me? 18:01:38 jsnell: yay, that did it 18:02:11 can you send a patch? 18:03:06 sure 18:03:19 rmarynch: reg alloc could be it. 18:03:22 udzinari [~user@209.158.broadband13.iol.cz] has joined #sbcl 18:09:31 okay. Good night all :) 18:09:33 -!- rmarynch [~roman@bras-7-ge-62.122.200.234.utm.if.ua] has quit [Quit: Leaving] 18:10:01 -!- pipping [pipping@exherbo/developer/pipping] has left #sbcl 18:12:08 jsnell: here it is: https://bugs.launchpad.net/sbcl/+bug/626962 18:16:57 Krystof [~csr21@84-51-132-95.christ977.adsl.metronet.co.uk] has joined #sbcl 18:16:57 -!- ChanServ has set mode +o Krystof 18:25:59 tcr [~tcr@81-233-246-97-no37.tbcn.telia.com] has joined #sbcl 18:27:59 -!- hargettp [~anonymous@pool-71-184-181-149.bstnma.east.verizon.net] has quit [Quit: hargettp] 18:30:38 hargettp [~anonymous@pool-71-184-181-149.bstnma.east.verizon.net] has joined #sbcl 18:34:02 -!- hargettp [~anonymous@pool-71-184-181-149.bstnma.east.verizon.net] has quit [Client Quit] 18:40:47 hargettp [~anonymous@pool-71-184-181-149.bstnma.east.verizon.net] has joined #sbcl 18:41:43 `micro [~micro@www.bway.net] has joined #sbcl 18:44:24 Kae [~b@c-cfcee253.97-16-64736c12.cust.bredbandsbolaget.se] has joined #sbcl 18:47:06 -!- `micro [~micro@www.bway.net] has left #sbcl 18:52:40 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 252 seconds] 18:53:41 gigamonkey [~user@c-98-248-194-46.hsd1.ca.comcast.net] has joined #sbcl 19:44:56 -!- udzinari [~user@209.158.broadband13.iol.cz] has quit [Read error: Connection reset by peer] 20:09:26 cmm [~cmm@bzq-79-181-203-193.red.bezeqint.net] has joined #sbcl 21:04:35 -!- gigamonkey [~user@c-98-248-194-46.hsd1.ca.comcast.net] has quit [Quit: Must work.] 21:05:39 nikodemus [~nikodemus@cs181199216.pp.htv.fi] has joined #sbcl 21:05:39 -!- ChanServ has set mode +o nikodemus 21:10:05 -!- hargettp [~anonymous@pool-71-184-181-149.bstnma.east.verizon.net] has quit [Quit: hargettp] 21:17:28 moocow [~new@poco208-2.fredcanhelp.com] has joined #sbcl 21:17:39 hi all 21:18:08 just curious on thoughts of porting sbcl to the arm architecture 21:18:17 how much work might something like that be? 21:21:12 traditionally porting sbcl to an entirely new platform takes a few wizard-months 21:22:08 moocow: CCL has recently added arm support if you actually need an arm lisp now-ish. 21:22:32 but nyef already started an ARM port, so it might not take very long 21:22:52 ahh.. the nyef factor 21:22:54 http://www.lisphacker.com/projects/sbcl-arm/port-log.txt 21:23:17 is that the first advert for the competition on #sbcl? :) 21:23:50 oh 21:23:53 really? 21:24:19 yeah i'm starting to get into arm sbcl devices and they come with huge amounts of memory and storage these days, the cpus are even getting up into the 1ghz range 21:24:29 i'd like to have a proper non 'c' environment to play with 21:24:34 nyef is already working on it? oh! 21:24:40 i didn't know, i was purely speculating 21:24:49 maybe then i can help with some money and stuff 21:25:05 thanks for the links and info guys 21:25:15 looking at the dates in that log might give you an idea of how actively he's working on it these days :-) 21:25:24 oh haha 21:26:00 thats kind of awesome that he keeps alog of this. 21:50:40 -!- moocow is now known as holycow 22:00:55 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Quit: Leaving.] 22:07:00 gigamonkey [~user@c-98-248-194-46.hsd1.ca.comcast.net] has joined #sbcl 22:21:36 rbarraud [~rbarraud@118-92-0-92.dsl.dyn.ihug.co.nz] has joined #sbcl 22:25:38 -!- tcr [~tcr@81-233-246-97-no37.tbcn.telia.com] has quit [Quit: Leaving.] 22:34:26 who wants to explain read/print consistency requirements for strings *again* on sbcl-devel? 22:34:34 this is becoming a FAQ 22:34:49 hargettp [~anonymous@pool-71-184-181-149.bstnma.east.verizon.net] has joined #sbcl 22:47:37 attila_lendvai [~attila_le@catv-89-133-171-82.catv.broadband.hu] has joined #sbcl 22:51:55 no volunteers? wussies, the lot of ya :) 23:11:02 lnostdal [~quassel@62.80-203-136.nextgentel.com] has joined #sbcl 23:12:47 hi! compiling cl-ppcre using latest SBCL (from git) causes some trouble here; http://paste.lisp.org/display/114065 ..i see data-vector-ref-with-offset mentioned in the 1.0.42.2 patch 23:14:07 lnostdal: i know, i'm on it 23:14:27 1.0.42.2 is the problem commit 23:14:44 if i can't fix the issue during tomorrow, i will back it out 23:20:28 -!- attila_lendvai [~attila_le@catv-89-133-171-82.catv.broadband.hu] has quit [Quit: Leaving.] 23:28:52 (the problem is that i neglected to adjust a bunch of vops as well) 23:34:05 -!- nikodemus [~nikodemus@cs181199216.pp.htv.fi] has quit [Ping timeout: 276 seconds] 23:35:48 -!- gigamonkey [~user@c-98-248-194-46.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds] 23:42:11 davazp [~user@128.Red-88-6-207.staticIP.rima-tde.net] has joined #sbcl