00:01:31 -!- gunter [~user@ip68-231-216-62.oc.oc.cox.net] has quit [Ping timeout: 276 seconds] 00:05:28 -!- attila_lendvai2 [~attila_le@188-143-56-181.pool.digikabel.hu] has quit [Quit: Leaving.] 00:37:49 tsuru`` [~charlie@adsl-98-87-43-139.bna.bellsouth.net] has joined #sbcl 00:39:08 -!- tsuru` [~charlie@adsl-74-240-217-174.bna.bellsouth.net] has quit [Ping timeout: 240 seconds] 01:49:23 psilord [~psilord@c-24-118-208-140.hsd1.mn.comcast.net] has joined #sbcl 02:46:10 -!- specbot [~specbot@pppoe.178-66-10-110.dynamic.avangarddsl.ru] has quit [Disconnected by services] 02:46:12 specbot [~specbot@pppoe.178-66-49-82.dynamic.avangarddsl.ru] has joined #sbcl 02:47:10 -!- stassats` [~stassats@wikipedia/stassats] has quit [Read error: Operation timed out] 02:47:49 plutoid [~pluto@61.170.248.215] has joined #sbcl 02:53:10 -!- huangjs [~huangjs@190.8.100.83] has quit [Ping timeout: 255 seconds] 02:53:25 huangjs [~huangjs@190.8.100.83] has joined #sbcl 03:05:55 -!- CampinSam [~Sam@24-176-98-217.dhcp.jcsn.tn.charter.com] has quit [Quit: leaving] 03:11:37 Qworkescence [~quad@unaffiliated/quadrescence] has joined #sbcl 03:36:17 -!- Fare [~Fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has quit [Ping timeout: 246 seconds] 03:49:05 stassats [~stassats@wikipedia/stassats] has joined #sbcl 03:58:23 -!- Qworkescence is now known as Quadrescence 04:25:58 Phoodus [~foo@wsip-68-107-217-139.ph.ph.cox.net] has joined #sbcl 04:57:14 -!- psilord [~psilord@c-24-118-208-140.hsd1.mn.comcast.net] has quit [Quit: Leaving.] 04:57:32 angavrilov [~angavrilo@217.71.227.190] has joined #sbcl 05:09:38 -!- blackwol` [~blackwolf@ool-4575fc51.dyn.optonline.net] has quit [Remote host closed the connection] 05:43:02 sdemarre [~serge@91.176.18.35] has joined #sbcl 07:34:37 tcr [~tcr@84-72-21-32.dclient.hispeed.ch] has joined #sbcl 07:58:07 -!- plutoid [~pluto@61.170.248.215] has quit [Quit: Leaving] 08:07:25 -!- ASau` [~user@95-25-227-191.broadband.corbina.ru] has quit [Remote host closed the connection] 08:08:58 ASau` [~user@95-25-227-191.broadband.corbina.ru] has joined #sbcl 08:28:09 -!- sdemarre [~serge@91.176.18.35] has quit [Quit: Leaving.] 08:58:27 prxq [~mommer@mnhm-4d010c62.pool.mediaWays.net] has joined #sbcl 09:10:17 -!- tcr [~tcr@84-72-21-32.dclient.hispeed.ch] has quit [Quit: Leaving.] 09:23:53 prxq_ [~mommer@mnhm-5f75f3d4.pool.mediaWays.net] has joined #sbcl 09:27:14 -!- prxq [~mommer@mnhm-4d010c62.pool.mediaWays.net] has quit [Ping timeout: 245 seconds] 09:31:11 -!- prxq_ is now known as prxq 09:33:32 nikodemus [~nikodemus@87-93-248-182.bb.dnainternet.fi] has joined #sbcl 09:33:32 -!- ChanServ has set mode +o nikodemus 09:37:00 afternoon 09:37:23 tcr [~tcr@178-83-229-138.dynamic.hispeed.ch] has joined #sbcl 09:39:47 mornin' 09:43:36 nikodemus: thanks for the function-lambda-expression hint, but that gives strange results. 09:43:46 for a normal function I get NIL (ie. no data) 09:43:56 for a (declaim (inline)) function it works 09:43:56 that's expected 09:44:04 we don't save source for functions unless requested 09:44:16 for a (declaim (inline)) generic it gives NIL and (LAMBDA (&REST SB-PCL::ARGS) :IN SB-PCL::MAKE-INITIAL-DFUN) 09:44:32 that's actualy pretty funny :) 09:44:38 how would I request storing the lambda for defmethods? 09:44:44 (should fix that) 09:44:57 hairy 09:45:01 not really supported 09:45:04 flip214: the easiest way is probably with a gf metaclass. 09:45:05 you can compile everything with C-c C-c, it stores sources 09:45:23 oh, and BTW, I noticed that the experimental patch you sent me (don't inline flet with same arguments multiple times) is not in current git 09:45:49 flip214: well, it is experimental 09:46:23 "works for me"™ 09:46:43 http://discontinuity.info/~pkhuong/gf-sealing.lisp <- (defclass inlined-sealed-gf ...) and (defmethod make-method-lambda ...) 09:46:46 stassats: what's C-c C-c in swank speak, slimv has different keybindings? 09:47:11 pkhuong: thanks, I'll take a look. 09:47:12 "C-c C-c runs the command slime-compile-defun" 09:47:41 and since it's slimv, i don't know what it will be doing 09:48:59 stassats: well, I have a compile-defun, too ... but that just sends the form to the lisp, what part would store the source? (apart from the lisp with some speed, space, debug settings)? 09:49:25 i have no idea what slimv does 09:50:38 but that's not going to work on non-instrumented code. 09:58:59 flip214: are you interested in lambda sources for development/debugging, or for some other reason? 10:06:56 Kryztof [c1c66933@gateway/web/freenode/ip.193.198.105.51] has joined #sbcl 10:26:34 I tried to implement inlined methods from generic functions, ie. what pkhuong sent me a bit earlier 10:26:42 how about taking that into sbcl? 10:27:26 kpreid has a couple very bad cases for any (AFAICT) static CLOS. 10:27:48 we'd have to figure out a decent policy before putting anything like that in master. 10:28:20 well, only use it if the generic function has your inlined class, and/or (declaim (inline my-generic))? 10:31:35 flip214: are you working on that for the coo/interesting factor, or do you have an actual use case? 10:45:25 -!- easye` [~user@213.33.70.157] has quit [Remote host closed the connection] 10:49:23 -!- homie` [~levgue@xdsl-78-35-156-194.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 10:52:26 pkhuong: I'm thinking about rewriting something, but don't want to lose performance 10:55:32 flip214: have you measured/analyzed the cost yet? 10:56:21 I suspect that even inlined CLOS dispatch can add notable costs, but at the same time for many applications CLOS dispatch costs are noise 10:56:53 saschakb [~saschakb@p4FEA0CD6.dip0.t-ipconnect.de] has joined #sbcl 10:57:13 nikodemus: iirc, the main gain was when the dispatch could be partially performed at compile-time. 10:58:11 Kryztof had preliminary work for inline clos dispatch caches. I think that's a better approach in general. 10:58:58 yay 10:59:12 nikodemus: did you at one point try to organize an implementors' forum? 11:02:32 imp-hackers@common-lisp.net 11:02:41 not very lively or productive so far 11:03:41 pkhuong: i agree. inlining dispatch seems like a better place to aim for than inlining whole method bodies 11:06:09 any comments on *BEFORE-EXIT-HOOKS* and *EXIT-HOOKS*? 11:06:54 you know, me and pragmatic issues. I just hack; delivery is for engineers ;) 11:07:23 hah 11:39:11 -!- Kryztof [c1c66933@gateway/web/freenode/ip.193.198.105.51] has quit [Ping timeout: 245 seconds] 11:52:49 i think i've convinced myself that *before-exit-hooks* are good 11:53:14 as is moving *exit-hooks* after everything has been unwound 11:53:52 why not name it *after-exit-hooks* anyway? it's more descriptive 11:55:16 you mean rename *EXIT-HOOKS* *AFTER-EXIT-HOOKS*? 11:55:50 yes, if it makes sense 11:56:32 possible, but would need to keep *exit-hooks* around for a fair while anyways -- renaming API variables is tricky without breaking stuff 11:57:56 hm 11:58:32 actually, can't sanely move *EXIT-HOOKS*. it's been in the right place for thread termination until now 11:58:52 so need to add *AFTER-EXIT-HOOKS* for that... 11:58:57 hurt 11:59:13 so, before-, -, and after-? 11:59:37 only *around-exit-hooks* is missing 11:59:52 hah 12:00:39 current *EXIT-HOOKS* could become *BEFORE-EXIT-HOOKS*, actually 12:00:50 it's just the naming that is a pain 12:01:15 *AT-EXIT-HOOKS*? 12:01:48 entirely confusing 12:01:57 if we have *AT-EXIT-HOOK* after everything has been unwound, and *EXIT-HOOKS* before that? 12:03:38 i would really like to avoid having three variables, which means avoiding renaming *EXIT-HOOKS* 12:04:19 but maybe that just ain't gonna work 12:09:20 -!- saschakb [~saschakb@p4FEA0CD6.dip0.t-ipconnect.de] has quit [Ping timeout: 260 seconds] 12:09:35 at the same time, *AFTER-EXIT-HOOKS* sounds silly to me. i mean, the process hasn't exited yet... 12:10:28 fork another sbcl and call *after-exit-hooks* in it? 12:15:25 but *exit-hooks* was previously called when a thread was killed, wasn't it? 12:16:08 so it already lost its previous meaning 12:20:27 -!- nikodemus [~nikodemus@87-93-248-182.bb.dnainternet.fi] has quit [Quit: This computer has gone to sleep] 12:26:15 saschakb [~saschakb@p4FEA0CD6.dip0.t-ipconnect.de] has joined #sbcl 12:27:41 nikodemus [~nikodemus@87-93-248-182.bb.dnainternet.fi] has joined #sbcl 12:27:41 -!- ChanServ has set mode +o nikodemus 12:31:26 -!- saschakb [~saschakb@p4FEA0CD6.dip0.t-ipconnect.de] has quit [Ping timeout: 246 seconds] 12:43:08 -!- nikodemus [~nikodemus@87-93-248-182.bb.dnainternet.fi] has quit [Quit: This computer has gone to sleep] 12:49:57 saschakb [~saschakb@p4FEA0DE1.dip0.t-ipconnect.de] has joined #sbcl 12:58:33 plutoid [~pluto@58.39.164.31] has joined #sbcl 13:43:17 psilord [~psilord@23-25-144-217-static.hfc.comcastbusiness.net] has joined #sbcl 13:50:53 leuler [~user@p54905518.dip.t-dialin.net] has joined #sbcl 14:01:57 milanj [~milanj_@178-223-150-244.dynamic.isp.telekom.rs] has joined #sbcl 14:02:47 nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has joined #sbcl 14:15:39 -!- plutoid [~pluto@58.39.164.31] has quit [Quit: Leaving] 14:47:54 what parts should i rebuild when i only modify the runtime? 14:48:41 blackwolf [~blackwolf@ool-4575fc51.dyn.optonline.net] has joined #sbcl 14:49:25 Is all this really needed? 14:49:28 what's the use case for after-exit-hooks? 14:49:48 (and why bother shutting down threads at all, really...just exit) 14:49:50 Depends on how thoroughly you modify it. Generally, re-running genesis-2 and target-2 is sufficient. 14:50:17 If you modify anything that gets grovelled for, however, you might need to re-run host-2 completely. 14:50:49 (Well, you'll also need to rebuild the runtime, too, of course.) 14:51:11 that's obvious 14:52:27 and by grovelling you mean calculating the addresses of routines? 14:54:04 No, I mean emitted constants and whatnot that need to be compiled. 14:54:10 Routine addresses are fixed up in genesis. 14:55:20 oh, ok, that's what i do (the latter) 15:00:05 hmm "can't load .core for different runtime, sorry" 15:00:42 including the version of the core into the message would be helpful 15:00:52 You changed the build-id? 15:01:05 don't think so, probably some git-voodoo 15:01:20 Ah, even more of a hair-trigger than before. 15:01:27 -!- saschakb [~saschakb@p4FEA0DE1.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 15:02:10 Not sure what to do there, TBH. 15:03:33 ok, so the build id is not related to git, apparently 15:03:38 can't load .core for different runtime ("debian-stas-2012-04-30-18-59-45"), sorry 15:04:58 Okay, so if that's a mismatch between the cold-core and the runtime, your options are to change the ID in the runtime, to change the ID that genesis puts into the core, to change the ID in the core (dd and hexl-mode might help here), or to just do a full build. 15:05:17 a full build is too slow 15:05:51 You on one of those "fifty minutes or more for a build" systems? 15:06:30 well, not exactly, without contribs and clean.sh, it's 2 minutes 13 seconds 15:06:54 but multiply that, and it'll be easily into fifty minutes in total 15:08:16 especially considering that i sometimes need several builds in successions just to get the C code right 15:08:43 I hear that. 15:09:09 So, trace where the build id comes from and how it gets changed? 15:09:34 (Alternately, disable the test temporarily?) 15:09:36 i can actualy modify the runtime to disregard the build id 15:09:58 Just make sure you don't commit that modification. (-: 15:10:08 no, it's just experiments 15:10:31 and i've already modified make.sh enough 15:14:37 that worked, now it's just 18 seconds 15:14:57 stassats: you do slam when you can, right? 15:15:09 not really, never got to figuring it out 15:15:11 slam is overkill for runtime changes. 15:15:39 18 seconds I can live with 15:17:02 Hey, what happens if I do an (eval-when (:compile-toplevel) (compile-file "whatever")) from a file being compiled? 15:17:29 a deadlock? 15:18:16 (compile-file *compile-file-pathname*) :-) 15:19:21 Specifically, I'm thinking to compile a different file. 15:19:40 seems fine, i guess it uses a recursive lock, on which i stumbled in slime before 15:19:57 compiling errors, i don't leave the debugger, trying to compile something else, nothing happens 15:20:16 Hrm... Yeah, probably mostly safe, unless block compilation is involved? 15:21:40 (eval-when (:compile-toplevel) (sb-thread:join-thread (sb-thread:make-thread #'compile-file :arguments "/tmp/bar.lisp"))) dead locks 15:21:46 so, you probably don't want to do that 15:21:58 Yeah, I'm just thinking of working inside a single thread. 15:22:22 yeah, i just wanted to replicate the deadlock scenario 15:23:21 Okay, so I have an angle if I want to go down that route. Thanks. 15:28:55 ok, not compiling the warm init and just loading it, 9.5 seconds 15:31:32 Your next trick is to throw RAM at the problem so that you don't have to hit the disk for any of it. (-: 15:31:39 already 15:32:50 the fastest way would be just to patch the symbol table in the image 15:34:56 Can't, unless runtime references go via linkage-tables. 15:36:00 nyef: SSD! 15:37:40 ... I might get an SSD-based machine soon, actually, but not for SBCL. Well, not for hacking ON SBCL, might run SBCL on it, though. 15:38:03 sbcl build is not I/O bound usually 15:59:41 9.5 seconds is much better, but i'd much prefer somewhere 500ms 16:00:51 genesis takes most of the time 16:02:06 Faster fasls should help there. 16:02:33 i'll never recover the wasted time that way 16:03:50 Oh, while I think about it, does anyone actually like FOP-FSET? Because if we had a FOP-%DEFUN instead, we might be able to make cold-fasls warmer. 16:09:51 -!- tcr [~tcr@178-83-229-138.dynamic.hispeed.ch] has quit [Quit: Leaving.] 16:18:47 gko [~gko@114-34-168-13.HINET-IP.hinet.net] has joined #sbcl 16:18:54 -!- gko [~gko@114-34-168-13.HINET-IP.hinet.net] has left #sbcl 16:37:51 dtw [~dtw@pdpc/supporter/active/dtw] has joined #sbcl 16:55:52 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 17:03:14 bringing cold and warm fasls closer together sounds good regardless 17:03:40 memset appears to be faster than sse fast_bzero 17:04:10 not significantly, though 17:06:43 At least they're already much closer than once they were. 17:07:15 and memset doesn't appear to be using sse explicitly 17:07:20 Somewhere I have a tree in which the cold fasls and genesis are entirely in terms of warm package names. 17:12:08 CampinSam [~Sam@24-176-98-217.dhcp.jcsn.tn.charter.com] has joined #sbcl 17:12:38 (Unfortunately, making it work required a special hack similar to FOP-FSET in the compiler.) 17:13:00 Err... s/FOP-FSET/COLD-FSET/. 17:14:31 slyrus_ [~chatzilla@173-228-44-92.dsl.static.sonic.net] has joined #sbcl 17:15:31 hm, no, memset uses sse2 17:16:28 it is more elaborate, more loops are unrolled 17:19:43 although doesn't use xmm registers 17:25:56 tcr [~tcr@84-72-21-32.dclient.hispeed.ch] has joined #sbcl 17:26:59 -!- slyrus_ [~chatzilla@173-228-44-92.dsl.static.sonic.net] has quit [Remote host closed the connection] 18:06:20 homie [~levgue@xdsl-78-35-143-164.netcologne.de] has joined #sbcl 18:11:04 -!- stassats [~stassats@wikipedia/stassats] has quit [Remote host closed the connection] 18:11:05 -!- specbot [~specbot@pppoe.178-66-49-82.dynamic.avangarddsl.ru] has quit [Remote host closed the connection] 18:14:49 specbot [~specbot@pppoe.178-66-49-82.dynamic.avangarddsl.ru] has joined #sbcl 18:14:54 stassats [~stassats@wikipedia/stassats] has joined #sbcl 18:15:58 damn, tried running a gc test and OOM everything 18:16:08 killed, that is 18:28:30 Kryztof [~user@83-131-81-169.adsl.net.t-com.hr] has joined #sbcl 18:28:31 -!- ChanServ has set mode +o Kryztof 18:32:57 -!- christoph_debian [~user@oteiza.siccegge.de] has quit [Remote host closed the connection] 19:01:01 -!- dtw [~dtw@pdpc/supporter/active/dtw] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 19:05:35 -!- tcr [~tcr@84-72-21-32.dclient.hispeed.ch] has quit [Quit: Leaving.] 19:20:38 -!- cmm- [~cmm@bzq-79-182-209-72.red.bezeqint.net] has quit [Ping timeout: 240 seconds] 19:36:59 -!- Kryztof [~user@83-131-81-169.adsl.net.t-com.hr] has quit [Ping timeout: 252 seconds] 19:57:31 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 276 seconds] 20:04:25 cmm [~cmm@bzq-79-182-209-72.red.bezeqint.net] has joined #sbcl 20:04:53 attila_lendvai [~attila_le@178-164-240-221.pool.digikabel.hu] has joined #sbcl 20:04:53 -!- attila_lendvai [~attila_le@178-164-240-221.pool.digikabel.hu] has quit [Changing host] 20:04:53 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 20:15:04 Kryztof [~user@83-131-81-169.adsl.net.t-com.hr] has joined #sbcl 20:15:04 -!- ChanServ has set mode +o Kryztof 20:28:04 -!- cmm [~cmm@bzq-79-182-209-72.red.bezeqint.net] has quit [Ping timeout: 245 seconds] 21:03:10 -!- angavrilov [~angavrilo@217.71.227.190] has quit [Ping timeout: 276 seconds] 21:14:08 -!- homie [~levgue@xdsl-78-35-143-164.netcologne.de] has quit [Remote host closed the connection] 21:15:36 hi. any comments to my patch on the floating point random numbers? 21:22:43 luis: ping 21:23:24 saschakb [~saschakb@p4FEA0DE1.dip0.t-ipconnect.de] has joined #sbcl 21:46:33 -!- leuler [~user@p54905518.dip.t-dialin.net] has quit [Quit: ERC Version 5.1.2 $Revision: 1.796.2.6 $ (IRC client for Emacs)] 21:48:14 homie [~levgue@xdsl-78-35-143-164.netcologne.de] has joined #sbcl 21:54:18 -!- prxq [~mommer@mnhm-5f75f3d4.pool.mediaWays.net] has quit [Quit: Leaving] 21:56:24 Fare [~Fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has joined #sbcl 21:57:06 -!- psilord [~psilord@23-25-144-217-static.hfc.comcastbusiness.net] has quit [Quit: Leaving.] 22:13:27 fe[nl]ix: pong 22:17:46 -!- tsuru`` is now known as tsuru` 22:18:54 ah, wrong channel 22:20:25 luis: -> #lisp 22:34:22 plutoid [~pluto@58.39.164.31] has joined #sbcl 23:13:34 -!- huangjs [~huangjs@190.8.100.83] has quit [Ping timeout: 252 seconds] 23:19:15 prxq [~mommer@mnhm-5f75f3d4.pool.mediaWays.net] has joined #sbcl 23:22:12 -!- prxq [~mommer@mnhm-5f75f3d4.pool.mediaWays.net] has quit [Client Quit] 23:23:59 huangjs [~huangjs@190.8.100.83] has joined #sbcl 23:25:10 -!- nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has quit [Quit: G'night all.] 23:38:41 tcr [~tcr@84-72-21-32.dclient.hispeed.ch] has joined #sbcl 23:44:25 -!- homie [~levgue@xdsl-78-35-143-164.netcologne.de] has quit [Read error: Connection reset by peer] 23:45:45 homie [~levgue@xdsl-78-35-143-164.netcologne.de] has joined #sbcl 23:50:17 homie` [~levgue@xdsl-78-35-168-240.netcologne.de] has joined #sbcl 23:51:38 -!- homie [~levgue@xdsl-78-35-143-164.netcologne.de] has quit [Ping timeout: 240 seconds] 23:56:05 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Ping timeout: 272 seconds]