00:06:20 slyrus [~chatzilla@173-228-44-92.dsl.static.sonic.net] has joined #sbcl 01:17:24 echo-area [~user@182.92.247.2] has joined #sbcl 01:20:33 -!- antoszka [~antoszka@unaffiliated/antoszka] has quit [Ping timeout: 264 seconds] 01:21:53 antoszka [~antoszka@unaffiliated/antoszka] has joined #sbcl 01:25:23 -!- slyrus [~chatzilla@173-228-44-92.dsl.static.sonic.net] has quit [Ping timeout: 240 seconds] 02:32:16 -!- Bike [~Glossina@174-25-57-167.ptld.qwest.net] has quit [Ping timeout: 264 seconds] 02:37:50 Bike_ [~Glossina@174-25-57-167.ptld.qwest.net] has joined #sbcl 02:38:33 -!- christoph_debian [~christoph@ppp-188-174-152-236.dynamic.mnet-online.de] has quit [Ping timeout: 264 seconds] 02:50:06 -!- Bike_ is now known as Bike 02:51:50 christoph_debian [~christoph@ppp-188-174-143-92.dynamic.mnet-online.de] has joined #sbcl 03:02:10 -!- tcr [~tcr@77-56-40-229.dclient.hispeed.ch] has quit [Ping timeout: 268 seconds] 03:35:51 -!- drmeister [~drmeister@pool-71-185-168-200.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 03:40:14 drmeister [~drmeister@pool-71-185-168-200.phlapa.fios.verizon.net] has joined #sbcl 03:58:16 tcr [~tcr@77-56-40-229.dclient.hispeed.ch] has joined #sbcl 03:58:30 -!- yacks [~py@103.6.158.102] has quit [Quit: Leaving] 04:02:30 -!- tcr [~tcr@77-56-40-229.dclient.hispeed.ch] has quit [Ping timeout: 245 seconds] 04:08:30 -!- ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has quit [Remote host closed the connection] 04:38:58 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Quit: This computer has gone to sleep] 04:50:43 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 04:58:45 tcr [~tcr@77-56-40-229.dclient.hispeed.ch] has joined #sbcl 05:00:33 edgar-rft [~GOD@HSI-KBW-149-172-63-75.hsi13.kabel-badenwuerttemberg.de] has joined #sbcl 05:03:26 -!- tcr [~tcr@77-56-40-229.dclient.hispeed.ch] has quit [Ping timeout: 256 seconds] 05:06:24 -!- oleo [~oleo@xdsl-78-35-184-171.netcologne.de] has quit [Read error: Connection reset by peer] 05:23:42 oleo [~oleo@78.35.133.117] has joined #sbcl 05:28:56 sdemarre [~serge@109.134.136.172] has joined #sbcl 05:40:45 prxq [~mommer@mnhm-590c1030.pool.mediaWays.net] has joined #sbcl 05:48:22 -!- drmeister [~drmeister@pool-71-185-168-200.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 05:59:15 tcr [~tcr@77-56-40-229.dclient.hispeed.ch] has joined #sbcl 06:01:00 -!- oleo [~oleo@78.35.133.117] has quit [Ping timeout: 268 seconds] 06:02:07 oleo [~oleo@xdsl-87-79-194-40.netcologne.de] has joined #sbcl 06:04:04 -!- tcr [~tcr@77-56-40-229.dclient.hispeed.ch] has quit [Ping timeout: 264 seconds] 06:04:07 -!- antoszka [~antoszka@unaffiliated/antoszka] has quit [Ping timeout: 264 seconds] 06:04:46 antoszka [~antoszka@unaffiliated/antoszka] has joined #sbcl 06:38:55 -!- easye [~user@213.33.70.157] has quit [Ping timeout: 276 seconds] 06:59:49 tcr [~tcr@77-56-40-229.dclient.hispeed.ch] has joined #sbcl 07:04:08 -!- tcr [~tcr@77-56-40-229.dclient.hispeed.ch] has quit [Ping timeout: 256 seconds] 07:15:31 -!- sdemarre [~serge@109.134.136.172] has quit [Ping timeout: 246 seconds] 07:18:51 easye [~user@213.33.70.157] has joined #sbcl 07:34:10 tcr [~tcr@77-56-40-229.dclient.hispeed.ch] has joined #sbcl 08:00:47 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Read error: Connection reset by peer] 08:01:33 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 09:04:01 sdemarre [~serge@109.134.136.172] has joined #sbcl 09:21:19 -!- tcr [~tcr@77-56-40-229.dclient.hispeed.ch] has left #sbcl 09:31:35 -!- Fare [~fare@cpe-69-203-115-132.nyc.res.rr.com] has quit [Ping timeout: 260 seconds] 10:08:20 Sagane [~Sagane@177.100-226-89.dsl.completel.net] has joined #sbcl 10:20:32 Ralt [Ralt@2a01:7e00::f03c:91ff:feae:6c69] has joined #sbcl 10:23:05 -!- Ralt [Ralt@2a01:7e00::f03c:91ff:feae:6c69] has left #sbcl 10:36:19 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 10:50:51 -!- echo-area [~user@182.92.247.2] has quit [Remote host closed the connection] 11:15:41 angavrilov [~angavrilo@217.71.227.190] has joined #sbcl 11:33:24 stassats [~stassats@wikipedia/stassats] has joined #sbcl 12:09:52 segv- [~mb@95-91-241-73-dynip.superkabel.de] has joined #sbcl 12:14:05 attila_lendvai [~attila_le@95.56.65.5] has joined #sbcl 12:14:05 -!- attila_lendvai [~attila_le@95.56.65.5] has quit [Changing host] 12:14:05 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 12:33:42 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Read error: Operation timed out] 12:49:40 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 13:19:27 -!- sdemarre [~serge@109.134.136.172] has quit [Ping timeout: 268 seconds] 13:19:30 stassats: can I bother you again with the #'length issue on circular lists? 13:19:59 you can 13:22:34 I came up with this http://paste.lisp.org/+2YOG and I wanted to know two things 13:22:45 1) is it what you were looking for? 13:23:24 2) how should I test it? (i.e. what should I remove from existing sbcl's sources and where should I put what I wrote) 13:23:50 ah, obviously, #'circular-list is not fundamental 13:24:46 pranavrc [~pranavrc@unaffiliated/pranavrc] has joined #sbcl 13:26:39 well, _i_ weren't looking for a length erring on circular lists, pkhuong were 13:27:11 it was plural 13:27:12 but that looks like what pkhuong was after 13:27:17 and you would need to not only have a transform, but the out-of-line LENGTH should call %list-length 13:27:48 let me edit 13:27:55 and see if I get it right 13:28:01 and the error is no the best, :expected-type 'list requirement is not broken 13:28:10 I know it 13:28:26 but I don't think 'proper-list is a correct type 13:28:27 is it? 13:28:31 I mean 13:28:38 it is not, you would have to spell it out 13:29:12 http://www.lispworks.com/documentation/HyperSpec/Body/f_length.htm says "Should be prepared to signal an error of type type-error if sequence is not a proper sequence." 13:29:18 oh 13:29:56 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 13:30:32 get a simple-type-error 13:30:57 ok let me see 13:33:42 drmeister [~drmeister@pool-71-185-168-200.phlapa.fios.verizon.net] has joined #sbcl 13:35:51 is this correct? http://paste.lisp.org/display/138256#1 13:36:30 ah I forgot one thing 13:36:36 should it be a static function? 13:36:51 it could be 13:37:21 would this suffice? (define-static-fun %list-length (list) :translate %list-length) 13:37:52 it's just like length's one 13:37:53 yes, and adding to that list 13:42:36 -!- oleo [~oleo@xdsl-87-79-194-40.netcologne.de] has quit [Read error: Connection reset by peer] 13:48:51 http://paste.lisp.org/display/138256#2 13:49:37 by the way, why adding the new define-static-fun instead of replacing it? 13:50:23 a simple-type-error still needs to have the datum and expected-type slots filled 13:50:43 if there's nothing better for expected-type, (satisfies proper-list-p) or whatever will do 13:51:38 (satisfies list-length) 13:51:59 I don't understand this last part 13:52:02 ok for the datum 13:52:57 you mean I should pass :expected-type '(satisfies list-length) to error? 13:53:07 if you have no better type specifier to initialize the type error with, you can concoct a suitable satisfies type, such as (and sequence (or (not list) (satisfies list-length))) 13:53:42 I'm not following closely, but the handler of a type error needs in principle to be able to inspect the type-error-datum and type-error-expected-type to know what to do next 13:54:30 I see 13:55:06 but what is satisfies? 13:55:19 something internal to SBCL or just a symbol? 13:55:46 Fare [~fare@cpe-69-203-115-132.nyc.res.rr.com] has joined #sbcl 13:56:20 also, could I use the datum as format argument? 13:56:42 to avoid using format-arguments 13:57:32 -!- drmeister [~drmeister@pool-71-185-168-200.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 13:58:51 clhs satisfies 13:58:51 http://www.lispworks.com/reference/HyperSpec/Body/t_satisf.htm 14:04:05 drmeister [~drmeister@pool-71-185-168-200.phlapa.fios.verizon.net] has joined #sbcl 14:05:18 can you look at what the impact is of just having generic LENGTH be a static fun? 14:06:46 isn't it already? 14:06:49 https://github.com/sbcl/sbcl/commit/ac405df3f196d58f6a5a2003afd8f48f490300df 14:07:03 right, it is. 14:07:06 good. 14:07:27 I'd try and see if the %ligt-length static fun is any help then. 14:08:15 I'd be glad to, but I'd like to ask you where should I put that code in sbcl's sources in order to compile it 14:08:36 and if there's anything I should erase first 14:09:10 Blkt: grep for (def.*length and find where the stuff for LENGTH is defined. 14:09:18 ok 14:10:01 and you'll want to disable the VOPs for length/list in src/compiler/x86[-64]/subprim.lisp 14:10:03 also, I see that define-static-fun for length is defined in both src/compiler/x86-64/parms.lisp and src/compiler/x86/parms.lisp 14:10:07 sdemarre [~serge@109.134.136.172] has joined #sbcl 14:10:12 I was about to ask that 14:10:18 yes. one is for x86 and the other for x86-64. 14:10:41 is it possible to write it once for both? 14:10:42 deciding which functions should be static and which not should be more scientific 14:10:58 using some code-base to decide which functions are most used 14:12:57 and in a way that it doesn't require a new page for static space, it's already allocated with 32K granularity, so the loft-over space can be used for static functions 14:14:17 you mean filling that 32K with the most frequently used functions, don't you? 14:14:46 stassats: that's configuration dependent. 14:15:13 after the space for NIL, T, etc. is filled, the rest goes unused, so, it can be used for static functions 14:16:47 there could be something for space, but not speed, sensitive functions, where a static trampoline takes care of setting up the stack frame 14:17:07 one thing i see about static functions is that they don't get TCOed 14:19:59 I see that a lot of stuff related to length is in subprim.lisp, for various architectures 14:20:37 being that %list-length is pure common lisp, wouldn't it be wiser to write it once for all architectures elsewhere than subprim.lisp? 14:21:07 it wouldn't make sense to put it into subprim.lisp in the first place 14:21:34 well, that's sure for %list-length 14:21:39 I didn't explain myself 14:21:52 I meant the new define-static-fun 14:22:22 having space for static functions is backend dependent 14:22:38 as you previosly said, right 14:22:48 even OS-dependent 14:24:29 so: (1) %list-length in seq.lisp, (2) define-static-fun in subprim.lisp, (3) modify (defun length in its actual place 14:24:35 what about the deftransform? 14:24:39 where should I put it? 14:24:43 seqtran 14:24:50 ok thanks 14:35:48 stassats: should I remove (define-vop (fast-length/list) ...) too? 14:35:49 -!- Bike [~Glossina@174-25-57-167.ptld.qwest.net] has quit [Ping timeout: 246 seconds] 14:36:24 no, change it so that it translates %list-length 14:37:49 Bike [~Glossina@174-25-57-167.ptld.qwest.net] has joined #sbcl 14:38:00 with another define-static-fun? 14:38:07 no 14:38:14 just change :translate 14:38:25 let me paste it to be clear 14:38:45 it'll be used with (safety 0) 14:40:19 so to disable length/list and fast-length/list I have to remove the :generator part of the define-vop for both? 14:40:37 and change (:translate length) into (:translate %list-length)? 14:40:38 no, just change :translate of fast-length/list 14:40:47 and remove length/list vop altogether 14:41:13 ah, you want to use %list-length when safety is not 0 14:41:18 and the vop when it is? 14:41:28 yes 14:41:31 ok thanks 14:43:50 *stassats* takes a look at HAIRY-DATA-VECTOR-REF and it's really weird 14:44:06 what's the difference between deftransform and define-source-transform? 14:44:27 define-source-transform is basically a compiler-macro: it operates in the world of source 14:44:30 define-source-transform works on s-exp forms, deftransform on ir1 14:44:35 deftransform work in the ... yes 14:45:11 deftransform has access to more information, like types 14:46:16 what if arrays just had an address of its getter in the header? 14:48:50 well, it already does something similar 14:48:57 I get an error compiling 14:49:08 "%LIST-LENGTH is not a known function." 14:49:19 you need to make it a known function in fndb.lisp 14:49:27 ah 14:49:28 let me see 14:53:45 -!- drmeister [~drmeister@pool-71-185-168-200.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 14:55:33 it keeps telling me it's unknown 14:56:05 I wrote (defknown %list-length (sequence) index) right after (defknown length ...) 14:57:11 it dies while loading x86-64/subprim.fasl 14:59:24 you need to export it from, say, sb-kernel 14:59:32 or sb-impl 14:59:38 how should I do that? 14:59:48 see package-data-list.lisp-expr 15:00:21 from sb-kernel is the best choice 15:04:01 nyef [~nyef@c-50-157-244-41.hsd1.ma.comcast.net] has joined #sbcl 15:04:30 rpg [~rpg@216.243.156.16.real-time.com] has joined #sbcl 15:13:13 Blkt: also, don't feel bad about what feels like a host of hurdles -- we've all been through it ("what, you mean I have to make changes here and here *and* here?") 15:14:32 and "%primitive-halt: i don't know where i need to make changes" 15:16:25 well, I felt bad before having a (basic) understanding of vop and transformations 15:17:07 also I didn't understand 'till now how it could find the definition of a new function (namely %list-length) 15:19:17 after a few days reading the sources it starts to feel nice 15:20:02 don't be fooled 15:20:16 by what? 15:20:27 by the nice feeling I have now? 15:20:33 yep 15:20:37 I won't :D 15:21:02 Indeed. The more I know about how the compiler works, the less happy I am with it. 15:21:10 hahaha 15:22:06 hi Blkt 15:22:08 I once heard a complaint about open source common lisp distributions' garbage collectors a few years back (at ELS in Lisbon) 15:22:10 hi fe[nl]ix 15:22:12 :D 15:22:16 how is the situation now? 15:22:25 did anything change since, say, 2009? 15:23:58 Oh, a few things have, but I've still got quite the project list for hacking on gencgc... 15:30:28 :) 15:43:27 tsuru` [~charlie@adsl-98-87-48-253.bna.bellsouth.net] has joined #sbcl 15:43:53 pkhuong: how should I check the efficiency of the static %list-length against the normal one? 15:44:37 (time (loop :repeat 10000 (length (circular-list 1)))) ? 15:47:24 for i to 10000 makes less noise, and create the list once 15:47:48 ok 15:48:17 and test (length list) and (length (the list)) separately 15:48:27 and to check the efficiency, you really not a non-circular list 15:48:32 really need 15:49:03 I need a list with more than 2000000 elements then 15:49:04 a lot more 15:49:42 you need to check against different numbers of elements 16:03:48 I didn't remember compiling sbcl took so long... 16:04:08 drmeister [~drmeister@farnsworth.chem.temple.edu] has joined #sbcl 16:04:08 I may be wrong but the last time was about 15 minutes long 16:04:42 this time took an hour and it's still working 16:04:48 is that normal? 16:04:50 no 16:04:59 :| 16:05:01 did it overheat your cpu? 16:05:09 sbcl compiles in about 3.5 minutes here 16:05:35 cpu is at 99.8% 16:05:51 that doesn't answer the overheating question 16:05:59 dmesg may 16:06:14 Bike_ [~Glossina@75-175-68-213.ptld.qwest.net] has joined #sbcl 16:07:16 no, no overheating 16:07:55 another way is to check the frequency 16:08:52 -!- Bike [~Glossina@174-25-57-167.ptld.qwest.net] has quit [Ping timeout: 264 seconds] 16:09:14 isn't it more likely that Blkt has constructed something that runs an infinite loop? 16:09:24 I don't think so 16:09:30 it keeps writing down stuff 16:09:42 is it actually different stuff? 16:09:44 -!- tsuru` [~charlie@adsl-98-87-48-253.bna.bellsouth.net] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 16:10:07 it's hard to imagine it would do so with the changes Blkt was doing 16:10:08 it seems to me 16:10:45 -!- Bike_ is now known as Bike 16:10:56 maybe your computers travels in space close to the speed of light? 16:11:01 computer 16:11:41 relative to you, that is 16:12:23 or you're compiling it with clisp 16:12:35 which involves in any way the speed of light too? 16:13:14 or some other physical quirk 16:14:06 -!- rpg [~rpg@216.243.156.16.real-time.com] has quit [Quit: rpg] 16:15:10 could it be I did ./make.sh clean before compiling? 16:16:06 ./make.sh clean? 16:16:13 yes 16:16:17 literally? 16:16:25 yes 16:16:27 that doesn't make sense 16:16:30 ok 16:16:38 let me see 16:16:41 ./clean.sh does make sense 16:16:49 and make.sh always runs ./clean.sh 16:16:58 so it's pointless 16:17:12 i'm not sure ./make.sh clean even works 16:17:47 unless you have a cl implementation named "clean" 16:18:04 which is apt name, it has "cl" in it 16:19:07 oh it finished right now 16:19:22 it couldn't build several contribs 16:19:35 -!- drmeister [~drmeister@farnsworth.chem.temple.edu] has quit [Remote host closed the connection] 16:19:41 maybe you made LENGTH so slow it was slow 16:23:07 drmeister [~drmeister@farnsworth.chem.temple.edu] has joined #sbcl 16:27:58 let me try again 16:29:13 if all array accessors are made static, then their addresses can be stored in the high bits of the array wide-tag 16:29:19 on x86-64 16:29:37 then generic-aref can be made faster 16:32:14 hey, that's potentially neat 16:32:31 could they be on 32-bit platforms if what was stored was an offset from the start of static-space (in 24 bits)? 16:33:56 right, full on 64-bit and offset on 32 16:33:58 rpg [~rpg@216.243.156.16.real-time.com] has joined #sbcl 16:35:30 would have to make sure that anything that tests wide-tags doesn't assume that high-bits are zero 16:37:05 (define-static-fun %list-length (list) :translate %list-length) gives error %list-length isn't a static function 16:37:12 how does that work then? 16:37:23 have you added it to the list of static functions? 16:37:31 I doubt that... 16:37:42 is there something like fndb.lisp? 16:37:49 specific for static functions? 16:38:35 sb-vm:*static-funs* 16:38:38 -!- sdemarre [~serge@109.134.136.172] has quit [Ping timeout: 268 seconds] 16:40:09 in src/compiler//parms.lisp ? 16:40:21 if that's where it is 16:41:30 ok, let's try again 17:00:54 the only question is how to distinguish between check-bounds and not-check-bounds one 17:01:10 -!- drmeister [~drmeister@farnsworth.chem.temple.edu] has quit [Remote host closed the connection] 17:02:15 make them adjacent, the check-bounds, then not-check-bounds, store check-bounds address in the widetag, then add the width if the not-check-bounds flavor is needed 17:03:02 Note that some platforms have a hard limit on the total number of static functions. 17:03:39 yeah, that's another problem 17:03:51 ... and I think there might be a GC hole for some/all precisely-scavenged platforms when calling a static function. 17:04:10 I know that there tends to be one for more-arg processing. 17:06:04 so, it needs 27 referers, 54 for check/non-check 17:06:18 108 for referrers and setters 17:06:56 -!- pranavrc [~pranavrc@unaffiliated/pranavrc] has quit [Read error: Operation timed out] 17:07:42 on x86-64 17:08:10 32-bytes per entry, that's about 3KB in total 17:09:35 on x86, 96 entries x 16-byte 1.5KB 17:12:48 even with only having the check-bound variety, not going through an array should be faster 17:14:01 Guest97417 [~oleo@xdsl-78-35-178-165.netcologne.de] has joined #sbcl 17:15:42 -!- Guest97417 [~oleo@xdsl-78-35-178-165.netcologne.de] has quit [Max SendQ exceeded] 17:18:47 attila_lendvai [~attila_le@95.56.69.30] has joined #sbcl 17:18:47 -!- attila_lendvai [~attila_le@95.56.69.30] has quit [Changing host] 17:18:47 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 17:19:00 I'll just point out that there's a good chance that ARM will have one of the lowest hard limits on static functions of any platform, possibly to the point of single digits or fewer. 17:24:01 that's not enough even for current ones 17:24:18 Uh-huh. 17:24:48 The actual limit is for offset-addressing specific slots within the FDEFN structure working purely from reg_NULL as a base. 17:25:44 And with precise-gc register rules, plus the utter paucity of registers on ARM... 17:27:30 Oh, and the absolutely bloody tiny offset field for instructions, and the fact that reg_NULL is pointer-tagged, thus negating the possibility of using a shifted offset... 17:28:04 can you just access immediate addresses? static function addresses are known at compile-time 17:28:28 and offsets too, usually 17:30:27 8-bit shifted immediates only. 17:30:34 And shift counts are constrained to be even. 17:31:01 how's the arm port going in general? 17:31:20 Haven't really done anything recently, been a bit busy with other things. 17:34:12 -!- rpg [~rpg@216.243.156.16.real-time.com] has quit [Quit: rpg] 17:36:35 rpg [~rpg@216.243.156.16.real-time.com] has joined #sbcl 17:39:06 -!- Bike [~Glossina@75-175-68-213.ptld.qwest.net] has quit [Ping timeout: 256 seconds] 17:41:01 Bike [~Glossina@67-5-253-108.ptld.qwest.net] has joined #sbcl 18:06:30 -!- reb`` [user@nat/google/x-alvldosivfghkbux] has quit [Remote host closed the connection] 18:15:08 drmeister [~drmeister@farnsworth.chem.temple.edu] has joined #sbcl 18:24:13 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 18:25:07 oleo [~oleo@xdsl-78-35-178-165.netcologne.de] has joined #sbcl 18:33:20 -!- Fare [~fare@cpe-69-203-115-132.nyc.res.rr.com] has quit [Ping timeout: 268 seconds] 18:44:38 -!- prxq [~mommer@mnhm-590c1030.pool.mediaWays.net] has quit [Remote host closed the connection] 18:53:26 Fare [~fare@cpe-69-203-115-132.nyc.res.rr.com] has joined #sbcl 18:57:43 slyrus [~chatzilla@107.200.11.156] has joined #sbcl 19:08:29 -!- xymox [lechuck@unaffiliated/contempt] has quit [Ping timeout: 268 seconds] 19:11:47 xymox [lechuck@unaffiliated/contempt] has joined #sbcl 19:28:57 -!- Fare [~fare@cpe-69-203-115-132.nyc.res.rr.com] has quit [Ping timeout: 264 seconds] 19:41:11 Fare [~fare@cpe-69-203-115-132.nyc.res.rr.com] has joined #sbcl 19:46:56 -!- angavrilov [~angavrilo@217.71.227.190] has quit [Remote host closed the connection] 19:47:45 -!- Fare [~fare@cpe-69-203-115-132.nyc.res.rr.com] has quit [Ping timeout: 256 seconds] 19:48:42 nyef: double indirection for 256 static routines? 19:50:56 brown [user@nat/google/x-toyfeqpwofkffymb] has joined #sbcl 19:51:20 -!- brown is now known as Guest51329 19:52:43 Might not work, as the basic operation for a static function is to call the unboxed entry point, which could be as simple as a load direct to reg_PC... Though I think that, in the case of ARM, it might not be, which would mean that we have a free register ANYWAY, but... Still a bit of a mess. 19:52:53 -!- slyrus [~chatzilla@107.200.11.156] has quit [Ping timeout: 240 seconds] 19:53:29 k. table of jump instructions. 19:53:55 no, still not general: fixups aren't that big. 19:54:56 So, museum tonight? 19:57:11 yes! We'll be taking the T to the MFA in a couple minutes. I'm not sure how much patience my friend'll have for art exhibits; at least 1-2h, I'm guessing. 19:58:55 I'm hoping to get another look at the Samurai exhibit before it disappears (according to the website, it's only on until this weekend), but other than that... 20:00:11 -!- Guest51329 is now known as reb 20:00:54 ok!. 20:01:46 So, meet-up protocol? I'll be wearing a pale-ish green short-sleeved shirt, somewhat unusual shoes, and will probably have my computer with me. 20:03:45 slyrus [~chatzilla@107.200.11.156] has joined #sbcl 20:04:19 Jeans and a T-shirt with a caffeine molecule on the front. With a short blonde, probably wearing a green/teal dress. 20:07:04 Okay, sounds good. See you at the visitor center in about an hour and a half or so. 20:20:06 sdemarre [~serge@109.134.136.172] has joined #sbcl 20:32:33 -!- Bike [~Glossina@67-5-253-108.ptld.qwest.net] has quit [Ping timeout: 264 seconds] 20:34:54 Bike [~Glossina@67-5-253-108.ptld.qwest.net] has joined #sbcl 20:37:27 pipping [~pipping@exherbo/developer/pipping] has joined #sbcl 20:37:53 -!- pipping [~pipping@exherbo/developer/pipping] has left #sbcl 20:49:32 -!- rpg [~rpg@216.243.156.16.real-time.com] has quit [Quit: rpg] 20:57:26 rpg [~rpg@216.243.156.16.real-time.com] has joined #sbcl 20:58:15 Fare [fare@nat/google/x-rketrumhvlqrxvcd] has joined #sbcl 21:00:03 hopefully nyef can recognize the 2-d structure of caffeine when he sees it 21:01:04 I have some buggy and incomplete code for drawing caffeine, e.g., in mcclim if anyone's interested 21:01:21 -!- sdemarre [~serge@109.134.136.172] has quit [Ping timeout: 264 seconds] 21:04:40 It's fairly unusual for someone to have any chemical structure on their shirt, plus the other identifying characteristics, plus the fact that it's a two-sided recognition protocol means that we can lose a few bits worth of data without undue loss of accuracy. 21:04:41 -!- Bike [~Glossina@67-5-253-108.ptld.qwest.net] has quit [Ping timeout: 246 seconds] 21:04:52 And, on that note, I need to sign off and catch the T to the MFA... 21:04:54 -!- nyef [~nyef@c-50-157-244-41.hsd1.ma.comcast.net] has quit [Quit: G'night all.] 21:05:25 beware, some other sbcl hackers may spoof it with a picture of a different molecule 21:06:36 Bike [~Glossina@71-222-53-89.ptld.qwest.net] has joined #sbcl 21:06:37 SbCl_5, for example 21:10:02 it's not even organic! 21:21:16 -!- rpg [~rpg@216.243.156.16.real-time.com] has quit [Quit: rpg] 21:43:28 yacks [~py@103.6.158.102] has joined #sbcl 22:24:27 -!- drmeister [~drmeister@farnsworth.chem.temple.edu] has quit [Remote host closed the connection] 22:30:55 alkymist [~user@static-72-87-239-154.lsanca.fios.verizon.net] has joined #sbcl 22:31:09 -!- alkymist [~user@static-72-87-239-154.lsanca.fios.verizon.net] has left #sbcl 22:35:38 -!- segv- [~mb@95-91-241-73-dynip.superkabel.de] has quit [Remote host closed the connection] 22:39:44 drmeister [~drmeister@166.137.87.46] has joined #sbcl 22:59:03 -!- drmeister [~drmeister@166.137.87.46] has quit [Remote host closed the connection] 23:00:58 drmeister [~drmeister@c-68-82-220-150.hsd1.pa.comcast.net] has joined #sbcl 23:04:21 -!- Bike [~Glossina@71-222-53-89.ptld.qwest.net] has quit [Ping timeout: 264 seconds] 23:06:12 Bike_ [~Glossina@71-222-53-89.ptld.qwest.net] has joined #sbcl 23:09:31 -!- drmeister [~drmeister@c-68-82-220-150.hsd1.pa.comcast.net] has quit [Ping timeout: 276 seconds] 23:11:54 drmeister [~drmeister@pool-71-185-168-200.phlapa.fios.verizon.net] has joined #sbcl 23:14:09 -!- Bike_ is now known as Bike 23:32:20 -!- Sagane [~Sagane@177.100-226-89.dsl.completel.net] has quit [Read error: Connection reset by peer] 23:38:04 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 23:40:07 referrer-in-widetag seems to be about 1.5 times faster 23:54:46 davazp [~user@204.Red-79-153-96.dynamicIP.rima-tde.net] has joined #sbcl