00:07:00 -!- mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has quit [Ping timeout: 245 seconds] 00:35:15 -!- tcr1 [~tcr@217-162-131-235.dynamic.hispeed.ch] has quit [Quit: Leaving.] 03:32:38 -!- attila_lendvai [~attila_le@catv-80-98-24-21.catv.broadband.hu] has quit [Quit: Leaving.] 03:35:48 -!- tsuru [~charlie@adsl-179-29-10.bna.bellsouth.net] has quit [Ping timeout: 265 seconds] 03:38:51 -!- homie [~levgue@xdsl-78-35-173-125.netcologne.de] has quit [Read error: Connection reset by peer] 03:39:33 homie [~levgue@xdsl-78-35-158-37.netcologne.de] has joined #sbcl 03:40:53 -!- homie [~levgue@xdsl-78-35-158-37.netcologne.de] has quit [Remote host closed the connection] 03:45:24 homie [~levgue@xdsl-78-35-158-37.netcologne.de] has joined #sbcl 06:16:33 tcr1 [~tcr@217-162-131-235.dynamic.hispeed.ch] has joined #sbcl 06:55:10 mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has joined #sbcl 06:55:49 -!- tcr1 [~tcr@217-162-131-235.dynamic.hispeed.ch] has quit [Quit: Leaving.] 07:17:06 flip214 [~marek@2001:858:107:1:baac:6fff:fe6b:9183] has joined #sbcl 07:17:07 -!- flip214 [~marek@2001:858:107:1:baac:6fff:fe6b:9183] has quit [Changing host] 07:17:07 flip214 [~marek@unaffiliated/flip214] has joined #sbcl 07:48:21 tcr1 [~tcr@217-162-131-235.dynamic.hispeed.ch] has joined #sbcl 08:50:50 -!- tcr1 [~tcr@217-162-131-235.dynamic.hispeed.ch] has quit [Quit: Leaving.] 09:35:31 stassats` [~stassats@wikipedia/stassats] has joined #sbcl 10:05:55 tcr1 [~tcr@212.47.174.118] has joined #sbcl 10:12:24 -!- mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.] 10:12:31 mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has joined #sbcl 10:37:59 attila_lendvai [~attila_le@catv-80-98-24-21.catv.broadband.hu] has joined #sbcl 10:57:00 -!- pkhuong [~pkhuong@gravelga.xen.prgmr.com] has quit [Ping timeout: 260 seconds] 11:25:15 hargettp [~hargettp@pool-71-184-188-141.bstnma.east.verizon.net] has joined #sbcl 11:32:00 -!- hargettp [~hargettp@pool-71-184-188-141.bstnma.east.verizon.net] has quit [Quit: Leaving...] 11:44:49 Blkt [~user@net-93-151-237-119.cust.dsl.teletu.it] has joined #sbcl 11:46:32 good day everyone 11:55:26 pkhuong [~pkhuong@gravelga.xen.prgmr.com] has joined #sbcl 12:08:02 hargettp [~hargettp@pool-71-184-188-141.bstnma.east.verizon.net] has joined #sbcl 12:14:23 nikodemus [~nikodemus@cs181199216.pp.htv.fi] has joined #sbcl 12:14:23 -!- ChanServ has set mode +o nikodemus 12:47:46 -!- deepfire [~deepfire@80.92.100.69] has quit [Read error: Connection reset by peer] 12:48:36 deepfire [~deepfire@80.92.100.69] has joined #sbcl 13:03:55 tsuru [~charlie@adsl-179-29-10.bna.bellsouth.net] has joined #sbcl 13:28:05 nikodemus: what's up with the debugger/backtrace cleanup patches? someone reported something slightly connected recently: https://bugs.launchpad.net/sbcl/+bug/711146 13:29:45 attila: i got stuck sorting out the debug names -- still some work left, but not a huge amount 13:32:46 nikodemus: do you have an opinion regarding class-prototype vs. (defmethod print-object)? I raised that on the mailing list, and I'd be happy about a fix in the next release 13:34:55 flip214: i have a ton of unread sbcl messages from the last couple of months -- including yours 13:35:06 ok 13:35:06 so no opinion right now 13:35:14 thanks all the same 13:42:15 flip214: ok, found it. i agree with attila and stas -- resiliency to printer errors is right fix 13:42:45 so a simple unwind-protect around the (print-object) call? 13:44:08 flip214: I've posted a proposed patch that deals with printer errors generally 13:44:29 and you probably mean handler-bind not uwp 13:44:34 ok, fine ... so I'm looking forward to having that fixed ;-) 13:54:43 -!- flip214 [~marek@unaffiliated/flip214] has quit [Remote host closed the connection] 14:15:14 -!- hargettp [~hargettp@pool-71-184-188-141.bstnma.east.verizon.net] has quit [Quit: Leaving...] 14:18:34 hargettp [~hargettp@pool-71-184-188-141.bstnma.east.verizon.net] has joined #sbcl 14:33:44 nyef [~nyef@pool-70-109-148-200.cncdnh.east.myfairpoint.net] has joined #sbcl 14:33:54 G'morning all. 14:34:07 heya nyef 14:34:26 Hello nikodemus. Long time no see. 14:34:58 indeed 14:35:18 Busy with work or a vacation, I hope, and not anything worse? 14:36:51 let's call it a short sabbatical. personal and family stuff 14:37:14 so, we've been waiting for nikodemus to resurface to make the final push towards git as official...? :) 14:37:25 So, not the best-case scenario, but certainly not the worst. 14:37:34 yep 14:37:55 I've still not seen the documentation that I'd like to have before supporting a move to git. 14:38:42 one way would be for there to be a single integretor, pulling stuff into his tree and making the release at the end of the month 14:38:58 but i'm not in a rush 14:53:33 -!- antgreen [~user@CPE00222d6c4710-CM00222d6c470d.cpe.net.cable.rogers.com] has quit [Remote host closed the connection] 14:56:44 I'd much rather see a central repo that's pushed to than a single integrator who pulls 14:58:10 Same here. Maintainers have lives, having a truck number of one for integration has the potential for badness. 14:58:12 and version.lisp-expr needs to die 14:58:30 or rather incrementing it for minor builds need to die 14:58:47 I'm all for centralised git. 14:59:44 and I really wonder whether NEWS should just be generated from commits every release instead of updated on every commit 15:00:35 I think there's value in having NEWS not be a straight list of commit logs (or one-line commit summaries, or whatever) 15:02:14 I've been considering updating my local commit system to be able to specify a NEWS entry in the commit message, and have the scripts strip it out and move it to NEWS when exporting to CVS. 15:02:53 not a raw dump, but some metadata in the commit message 15:03:20 News: * bug fix: froz the qubixer (patch by ...) 15:03:57 and then merge those using the "normal" sbcl NEWS rules 15:04:10 ok, that would be reasonable 15:04:22 i'm cool with centralized git too 15:04:59 automated NEWS would be cool 15:05:07 I think centralized git wins 15:07:32 sourceforge git? 15:07:49 khm 15:07:54 I still want to see a document outlining what changes we expect to see, for maintainers as well as users. 15:09:10 -!- tcr1 [~tcr@212.47.174.118] has quit [Quit: Leaving.] 15:10:28 antgreen [~user@CPE00222d6c4710-CM00222d6c470d.cpe.net.cable.rogers.com] has joined #sbcl 15:19:33 so, code-char on sbcl interprets the numbers above 127 as an iso-8859-1 code-point, right? 15:20:57 attila_lendvai: unicode code point 15:22:41 fe[nl]ix: well, I lack enough understanding to conclude anything from your remark. my question is: if I map code-char on some bytes, then will I effectively get the same as (octets-to-string byte-vector :iso-8859-1)? 15:25:23 attila_lendvai: there's one simple way to find out ;) but, I think so, in all my encoding ignorance. 15:25:46 attila_lendvai: iso-8859-1 coincides with the first 256 code points of unicode 15:26:10 ok, thanks for the help guys! 15:40:12 -!- attila_lendvai [~attila_le@catv-80-98-24-21.catv.broadband.hu] has quit [Quit: Leaving.] 15:41:58 tcr1 [~tcr@217-162-131-235.dynamic.hispeed.ch] has joined #sbcl 15:50:25 -!- cmm [~cmm@bzq-109-66-206-178.red.bezeqint.net] has quit [Ping timeout: 260 seconds] 15:51:12 cmm [~cmm@bzq-109-66-206-178.red.bezeqint.net] has joined #sbcl 15:56:07 howdy nikodemus 15:57:55 and the rest o' y'all 16:25:04 -!- homie [~levgue@xdsl-78-35-158-37.netcologne.de] has quit [Read error: Connection reset by peer] 16:26:08 homie [~levgue@xdsl-78-35-145-12.netcologne.de] has joined #sbcl 16:29:48 mega1` [~user@catv4E5CABA2.pool.t-online.hu] has joined #sbcl 17:01:06 oho! hello nikodemus! 17:14:41 hi 17:22:21 what's the recommened way to silence warnings/notes from inside code being compiled these days? 17:23:40 sb-ext:muffle-conditions declaration? 17:24:04 redline6561 [~user@c-66-56-55-169.hsd1.ga.comcast.net] has joined #sbcl 17:31:08 hm, don't seem to have that symbol. boo 17:32:29 froydnj: have you seen the email on the gcc farm list? 17:32:52 mega1`: which one is that? 17:33:03 "disk full on gcc40" 17:33:13 *froydnj* checks 17:33:38 bother, I have trees there. 17:38:59 *froydnj* cleans things out 17:43:22 you don't have sb-ext:muffle-conditions? It's, like, a gazillion years old 17:46:33 ah, hm, slime apropos was not showing it 18:13:07 does slime apropros filter out thing which are not types, functions, or variables? 18:14:15 (yes, it does) 18:21:37 -!- nikodemus [~nikodemus@cs181199216.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 18:24:49 it wouldn't, if i knew the way to know whether symbol is a declaration or not 18:25:39 (info :declaration :recognized x) works only on declarations declared via DECLARATION declaration 18:26:21 ... File a bug, that muffle-conditions isn't declared to be a declaration? 18:26:43 well, neither of usual declarations are declared 18:47:39 -!- Blkt [~user@net-93-151-237-119.cust.dsl.teletu.it] has quit [Ping timeout: 246 seconds] 18:47:58 nikodemus [~nikodemus@cs181199216.pp.htv.fi] has joined #sbcl 18:47:58 -!- ChanServ has set mode +o nikodemus 18:52:33 Blkt [~user@net-93-151-237-119.cust.dsl.teletu.it] has joined #sbcl 18:53:53 rmarynch [~roman@88.135.194.233] has joined #sbcl 19:00:45 -!- homie [~levgue@xdsl-78-35-145-12.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 19:08:46 homie [~levgue@xdsl-78-35-145-12.netcologne.de] has joined #sbcl 19:13:44 -!- rmarynch [~roman@88.135.194.233] has quit [Quit: Leaving] 19:15:44 phil [~hargettp@pool-71-184-188-141.bstnma.east.verizon.net] has joined #sbcl 19:16:26 -!- hargettp [~hargettp@pool-71-184-188-141.bstnma.east.verizon.net] has quit [Ping timeout: 240 seconds] 19:16:33 -!- phil [~hargettp@pool-71-184-188-141.bstnma.east.verizon.net] has quit [Client Quit] 19:16:39 hargettp [~hargettp@pool-71-184-188-141.bstnma.east.verizon.net] has joined #sbcl 19:31:59 sineer [~cluster@184.163.30.58] has joined #sbcl 20:01:47 -!- redline6561 [~user@c-66-56-55-169.hsd1.ga.comcast.net] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 20:07:36 redline6561 [~user@c-66-56-55-169.hsd1.ga.comcast.net] has joined #sbcl 20:16:26 -!- hargettp [~hargettp@pool-71-184-188-141.bstnma.east.verizon.net] has quit [Ping timeout: 240 seconds] 20:19:54 Blkt` [~user@net-93-151-238-83.cust.dsl.teletu.it] has joined #sbcl 20:21:14 -!- Blkt [~user@net-93-151-237-119.cust.dsl.teletu.it] has quit [Ping timeout: 240 seconds] 20:21:16 Quadrescence [~Quad@unaffiliated/quadrescence] has joined #sbcl 20:27:02 Launchpad is for enhancements too, right? 20:27:40 sure! 20:27:54 patch and all welcome 20:28:05 unified and all, as usual (or whatever git does ;) 20:28:37 I don't know really about making a patch explicitly, but I can provide the code that should essentially be cut-and-paste. 20:28:56 sure, good enough. 20:29:14 Quadrescence: you can cut-and-paste and make git diff 20:29:20 If you're interested in working on SBCL's numeric tower, I can try and guide you. 20:29:49 stassats`: I would probably mess things up until I learn git and more about SBCL internally... 20:30:09 learn by doing! 20:30:38 you should see everyone's early commits 20:30:44 &^£$*&£ "forgot to update version.lisp-expr" 20:30:46 happy days 20:31:08 -!- deepfire [~deepfire@80.92.100.69] has quit [Ping timeout: 276 seconds] 20:31:17 Quadrescence: the numeric tower (except for some float and fixnum stuff) is well modularised. 20:34:45 Quadrescence: in fact, you can probably hack all of that with runtime redefinitions. 20:35:09 Of course. 20:36:13 rpg [~rpg@216.243.156.16.real-time.com] has joined #sbcl 20:36:29 although there was a faster bignum multiplication for sbcl, it wasn't committed 20:36:42 is that "policy" changed? 20:37:46 stassats`: IIRC it was a minor improvement at a specific range at the expense of a lot of complexity -- and the patch author himself (juho) was against committing it 20:38:00 but i may misremember details 20:38:22 karatsuba might be nice to have, I guess. 20:38:37 i was referring to this http://jsnell.iki.fi/blog/archive/2004-08-22.html 20:38:48 -!- slyrus [~chatzilla@adsl-75-36-217-249.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 276 seconds] 20:38:57 i think "I'm still not really happy with the performance vs. complexity of the code, and am waiting inspiration to strike before submitting the code for inclusion to SBCL." explains it 20:39:39 anyway, for large numbers it's hard to beat GMP, although trying wouldn't hurt 20:39:55 Is there no equivalent BSD-licensed bignum library? 20:40:04 foom: it's LGPL, so it doesn't taint SBCL. 20:40:19 as long as wel dlopen it :) 20:40:29 pkhuong: oh, cool. Why doesn't sbcl use gmp then. :) 20:40:42 why would you have to dlopen it? 20:41:21 slyrus [~chatzilla@adsl-75-36-217-249.dsl.pltn13.sbcglobal.net] has joined #sbcl 20:41:30 foom: additional dependency? Someone's already started working on switching sb-bignum to gmp at runtime. 20:41:44 I've been looking into that avenue for a while, haven't got a nice way to integrate just yet. 20:42:15 might just switch over to encode/gmp/decode after a couple words. 20:42:24 static linking and lgpl? (using dlopen to actually mean depending on the .so) 20:42:49 you can use the .so without dlopening it. 20:43:38 not after as much wine as i've had 20:43:44 ah, good point. :) 20:53:50 pkhuong: did you see that PDF I tried to make stassats read 20:55:10 yup. 20:57:21 I don't have a lot of time to spend on SBCL, even less so on improvements, but, again, I can try and help. 21:04:06 Well, I'm sure some stuff I do for NumeriCL (aforementioned in #lisp) could help directly with SBCL. GMP is fast, but it's a C dependency, and---as even the website says---most people don't even build it right. 21:05:03 is there any way that accessors defined with sb-c:def-reffer leave some footprints for introspection? 21:05:52 stassats`: i don't think so, but it would be easy to add something 21:06:24 is it desirable? 21:07:36 so that M-. on symbol-name could refer to (define-primitive-object (symbol ...)) 21:08:33 Quadrescence: most people don't need to know how to build it, because it's already built. 21:11:32 Quadrescence: ISQRT in SBCL isn't inlined, could the difference on small numbers benchmarks attributed to that? 21:13:35 stassats`: I did my first tests actually without it inlined. 21:14:00 stassats`: has a certain coolness value certainly 21:14:41 nikodemus: at least it will resolve questions like why car is defined like (defun car (x) (car x)) 21:14:41 hm. apparently there's a fork of GMP, MPIR, which makes it possible for mere mortals to build on windows. 21:17:30 -!- nikodemus [~nikodemus@cs181199216.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 21:18:33 Quadrescence: how much time do you spend on recursive calls? 21:19:19 I can't say exactly, but there are log(log(n)) calls for integer n 21:19:55 k. so the leaves don't matter. 21:20:17 hargettp [~hargettp@pool-71-184-184-49.bstnma.east.verizon.net] has joined #sbcl 21:20:36 stassats`: I was quite confused about that for a while :) 21:20:49 The exponential increase in time required is (unfortunately) the bignum's fault. 21:21:01 bignums' 21:21:59 -!- hargettp [~hargettp@pool-71-184-184-49.bstnma.east.verizon.net] has quit [Client Quit] 21:25:07 hargettp [~hargettp@pool-71-184-184-49.bstnma.east.verizon.net] has joined #sbcl 21:34:46 -!- redline6561 [~user@c-66-56-55-169.hsd1.ga.comcast.net] has left #sbcl 21:35:21 -!- Blkt` [~user@net-93-151-238-83.cust.dsl.teletu.it] has quit [Ping timeout: 276 seconds] 21:35:37 redline6561 [~user@c-66-56-55-169.hsd1.ga.comcast.net] has joined #sbcl 21:43:58 -!- redline6561 [~user@c-66-56-55-169.hsd1.ga.comcast.net] has quit [Remote host closed the connection] 21:44:39 redline6561 [~user@c-66-56-55-169.hsd1.ga.comcast.net] has joined #sbcl 21:47:08 -!- redline6561 [~user@c-66-56-55-169.hsd1.ga.comcast.net] has quit [Remote host closed the connection] 21:55:23 -!- stassats` [~stassats@wikipedia/stassats] has quit [Ping timeout: 265 seconds] 21:56:30 redline6561 [~user@c-66-56-55-169.hsd1.ga.comcast.net] has joined #sbcl 21:57:19 so, let's just move a copy of antifuchs git tree to common-lisp.net and call it a day 21:58:52 Quadrescence: I'm pretty sure that an initial guess with float arithmetic would be closer, and likely faster. 22:00:32 ... I'm /still/ not seeing the documentation on how this would affect our development process and release policies, or how it would affect end users, so no. Let's not move to git as our system of record just yet. 22:01:41 nyef: we'll write the documentation to describe the new process once it exists 22:01:54 I'm sure the old process was written up after CVS repo was in use... 22:02:25 nyef: I'll try to come up with a proposal tomorrow 22:02:41 pkhuong: A float wouldn't give you 1/2 precision though. 22:02:45 maybe we'll arrive at a sort of concensus sometime soon (: 22:02:58 nope, indeed. 22:03:07 cvs was in use when there was exactly one developer 22:03:24 and a gradual increase of developers through stern vetting and mentoring 22:03:39 pkhuong: We can guarantee 1/2 precision this way (mathematically), and a proof of termination is rather easy. 22:03:41 not at all the same thing as declaring a new repository the master and saying "ok, everyone, off you go" 22:03:45 right. 22:03:50 I'm also looking at some weird recurrence with sqrt{a^2-b^2} = sqrt{a+b} * sqrt{a-b}... 22:04:03 doesn't look too useful, but, at least, it'll extend the range of the fast path. 22:04:22 (going with a float approximation) 22:05:19 pkhuong: You mean extend the range of those "base" cases? 22:05:23 right. 22:05:31 Ah, yeah, maybe. 22:05:55 bah. who put the grownups in charge? 22:07:45 slyrus: They sort of took over as they grew out of being kinds. 22:08:03 yeah, yeah :) 22:08:12 kids as well. 22:08:34 I'm all for an exciting free-for-all; sbcl developers (or at least me) have got a bit conservative lately 22:08:43 it's more fun when clx breaks all the time! 22:08:52 *nyef* winces. 22:09:08 but there's code-free-for-all and wtf-happened-to-my-repository free-for-all 22:09:11 I really should have caught that before committing. 22:09:12 and I like the second kind less 22:09:20 nyef: meh, happens to us all :-) 22:09:38 you should have seen the early threads days. Totally, totally broken 22:09:41 I suppose. But it /was/ a great big hole in my analysis... 22:10:30 And I'm supposedly the current clx maintainer, though more by default than anything else. 22:10:39 yes, well, dan_b was back then too :-) 22:10:50 Heh. 22:10:52 Fair enough. 22:11:17 so I would say we don't have to have the perfect policy for the brave new world -- just something that we can agree to try 22:11:53 jsnell and nikodemus get veto power; otherwise, vague consensus here. If we get some kind of agreement by Monday then I can announce the new state of the world at the Zurich Lisp User Meeting 22:12:15 that would be nice 22:12:40 I'm not even too bothered about what the new policy ends up being at this point, I just want some level of expectation management. 22:12:59 don't let SBCL turn into Maxima 22:13:06 (I would offer the experience of the business world for managing a complex multi-person git tree operation, only I discover that the business world doesn't have much of a clue either :-) 22:13:21 Krystof: "whatever works", eh? (: 22:13:44 and multiplayer-notepad-based synchronization primitives 22:13:58 night night :-) 22:14:06 There's the linux-kernel experience, but they're far, far higher-end than we are, and they still have the bottleneck of a single integrator in the end. 22:14:50 and that of a beneficial dictator (: 22:15:02 or whatever the adjective is nowadays 22:15:09 Right, right. 22:16:18 anyway. if all goes well, I'll try to integrate your scripts into the tree tomorrow, and see if I can make something that can build with and without git, make a source and binary distribution, and survives merging. 22:16:28 Well, I'm setting up gerrit to manage my end of the business world. 22:16:28 sound good? 22:16:32 any other use cases? 22:16:39 yeah, gerrit works very well for us, too 22:17:42 foom: What's this about d-x variables, mv-return and %%nip-values? 22:18:26 nyef: hm, yes...that line could use some fleshing out. :P 22:18:47 nyef: hold on, let me see if I can dredge up some context about that. :) 22:21:47 foom: It's not bug 308934 is it? 22:23:38 -!- mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has quit [Ping timeout: 240 seconds] 22:23:55 Hrm. Wouldn't surprise me in the least if there's something deeply stupid in the stack analysis around there, actually. 22:24:10 -!- mega1` [~user@catv4E5CABA2.pool.t-online.hu] has quit [Ping timeout: 260 seconds] 22:27:57 -!- redline6561 [~user@c-66-56-55-169.hsd1.ga.comcast.net] has quit [Remote host closed the connection] 22:30:40 deepfire [~deepfire@80.92.100.69] has joined #sbcl 22:49:00 nyef: okay, I've recalled the issue 22:49:23 nyef: if you have d-x variables in a stackframe, and it tail calls another function that might have an mv return 22:49:42 then, the tail call isn't a tail call anymore, because it has to call %%nip-values afterwards 22:49:51 which is okay probably 22:49:57 but %%nip-values is extremely slow 22:50:00 which seems unnecessary 22:51:06 I think it might be because it uses the STD instruction. 22:53:00 Ah, right, because the compiler can't tell that the d-x values aren't live, yes? 22:53:49 -!- rpg [~rpg@216.243.156.16.real-time.com] has quit [Quit: rpg] 22:54:12 rpg [~rpg@216.243.156.16.real-time.com] has joined #sbcl 22:54:22 Hm. I think that they might have actually been live in this case, but I'm not 100% sure. But certainly if they're dead it shouldn't do that at all. :) 22:58:06 In any case, I think the issue I meant to write down was "nip-values seems to be taking a lot more time than it ought to be in order to just move a couple of words" 22:59:13 That's plausible. I think that some of the code in the x86oid backends might have been written back when the 486 was state-of-the-art. 22:59:30 At best, when the Pentium was reasonably recent. 23:00:21 I'm pretty sure modern cpu references say "don't ever use STD, you fools!" 23:00:58 ... there's a sex-ed joke around here somewhere, but I couldn't be bothered working it out. 23:02:52 Really, it's more a question of why on earth we're still using the string instructions in the first place. 23:03:29 I suppose because nobody bothered to get rid of them yet. :) 23:03:30 ... could almost make a case that it should be an assembly-routine. 23:03:51 hey, isn't there one of those already, called memcpy? 23:04:13 Heh. 23:04:20 -!- dlowe [~dlowe@ita4fw1.itasoftware.com] has quit [Quit: *poof*] 23:04:23 Do you really want to do a full call-out for this? 23:04:39 probably not, since I expect most of the time it'd only copy 1-3 words of data. 23:04:45 Right. 23:10:04 I wonder if there's more that can be done here with this interface. Like, if the displacement is always constant, or... Something for next week, maybe. 23:10:18 redline6561 [~user@c-66-56-55-169.hsd1.ga.comcast.net] has joined #sbcl 23:26:59 -!- redline6561 [~user@c-66-56-55-169.hsd1.ga.comcast.net] has quit [Remote host closed the connection] 23:28:36 redline6561 [~user@c-66-56-55-169.hsd1.ga.comcast.net] has joined #sbcl 23:40:16 Okay, the displacement should rarely, if ever, be constant, because the entire point is that it's /unknown/ values.