00:04:56 danlentz [~danlentz@c-76-117-5-156.hsd1.nj.comcast.net] has joined #sbcl 00:24:23 -!- homie [~homie@xdsl-78-35-180-183.netcologne.de] has quit [Read error: Connection reset by peer] 00:24:33 -!- wbooze [~wbooze@xdsl-78-35-180-183.netcologne.de] has quit [Read error: Connection reset by peer] 00:24:42 -!- asciilifeform [~asciilife@pool-71-191-43-115.washdc.fios.verizon.net] has left #sbcl 00:55:51 :-) 01:15:50 -!- danlentz [~danlentz@c-76-117-5-156.hsd1.nj.comcast.net] has quit [Quit: Colloquy for iPhone - http://colloquy.mobi] 01:41:51 kanru` [~kanru@118-163-10-190.HINET-IP.hinet.net] has joined #sbcl 03:12:46 -!- hlavaty [~user@91-65-217-229-dynip.superkabel.de] has quit [Read error: Operation timed out] 03:13:11 hlavaty [~user@91-65-217-229-dynip.superkabel.de] has joined #sbcl 03:33:22 Fare [~fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has joined #sbcl 04:36:29 -!- Fare [~fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has quit [Ping timeout: 260 seconds] 04:38:24 danlentz [~danlentz@c-76-117-5-156.hsd1.nj.comcast.net] has joined #sbcl 04:49:19 -!- danlentz [~danlentz@c-76-117-5-156.hsd1.nj.comcast.net] has quit [Quit: Colloquy for iPhone - http://colloquy.mobi] 05:24:23 milanj [~milanj_@178-223-146-31.dynamic.isp.telekom.rs] has joined #sbcl 05:27:36 -!- milanj [~milanj_@178-223-146-31.dynamic.isp.telekom.rs] has quit [Client Quit] 05:57:03 sdemarre [~serge@91.176.0.118] has joined #sbcl 05:58:23 angavrilov [~angavrilo@217.71.227.190] has joined #sbcl 06:34:18 prxq [~mommer@mnhm-5f75e695.pool.mediaWays.net] has joined #sbcl 06:40:46 -!- sdemarre [~serge@91.176.0.118] has quit [Ping timeout: 246 seconds] 07:03:55 attila_lendvai [~attila_le@87.247.57.51] has joined #sbcl 07:03:55 -!- attila_lendvai [~attila_le@87.247.57.51] has quit [Changing host] 07:03:55 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 09:22:50 -!- prxq [~mommer@mnhm-5f75e695.pool.mediaWays.net] has quit [Remote host closed the connection] 09:23:04 prxq [~mommer@mnhm-5f75e695.pool.mediaWays.net] has joined #sbcl 10:23:31 -!- kanru` [~kanru@118-163-10-190.HINET-IP.hinet.net] has quit [Ping timeout: 246 seconds] 11:26:39 -!- huangjs [~huangjs@69.84.244.131] has quit [Quit: Ex-Chat] 11:34:44 kanru` [~kanru@1-162-49-128.dynamic.hinet.net] has joined #sbcl 12:04:33 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 12:05:50 -!- jdz [~jdz@85.254.212.248] has quit [Quit: Byebye.] 12:08:06 -!- DGASAU [~user@91.218.144.129] has quit [Remote host closed the connection] 12:10:00 jdz [~jdz@85.254.212.248] has joined #sbcl 12:13:20 gko [~user@114-34-168-13.HINET-IP.hinet.net] has joined #sbcl 12:45:21 LiamH [~healy@129-2-129-145.wireless.umd.edu] has joined #sbcl 12:49:08 -!- kanru` [~kanru@1-162-49-128.dynamic.hinet.net] has quit [Remote host closed the connection] 13:13:31 with current GIT I still have my "unbound variable" problem [(declare (special ...)) in a LET, cl-ppcre] 13:16:32 Fare [~fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has joined #sbcl 13:21:16 flip214: when you say "still" is there an existing bug report? 13:22:04 no, don't think so. I asked about a week ago, and tried again just now. (hoping for the best.) 13:22:47 Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has joined #sbcl 13:27:34 -!- LiamH [~healy@129-2-129-145.wireless.umd.edu] has quit [Quit: Leaving.] 13:31:31 Krystof: https://bugs.launchpad.net/ubuntu/+source/sbcl/+bug/1064389 13:42:25 not a compiler bug. 13:42:36 "(declare (special end-string-offset end-anchored-p end-string))" 13:43:56 -!- Fare [~fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has quit [Ping timeout: 246 seconds] 13:44:20 You refer to end-string-offset from within the closure later on, and it escapes upwards so you get a consistent failure rather than one hidden by the package system and typical usage. 13:45:05 I still don't understand why my change causes this. 13:45:52 ask #lisp to tell you more about dynamic scoping and returning closures. 13:46:26 pkhuong: I know about dynamic scoping and closures. (At least I think I do ;) 13:47:02 But the end-string should be set by the LET before even returning the LAMBDA, right? That's how I read it. 13:47:35 it's also unbound by the time the lambda returns, before it's even called. 13:47:50 is it the case that you have (let ((x foo)) (declare (special x)) (lambda (&rest args) (funcall (frob x)))) now 13:48:11 Krystof: yes, something like that 13:48:24 and you used to have (let ((x foo)) (declare (special x)) (let ((frobbed (frob x))) (lambda (&rest args) (funcall frobbed)))) 13:50:09 I hope that the silence means that realisation is dawning :-) because I have to go and wake one child and pick the other one up from school now 13:51:13 Krystof: it was (LET* ((var) (var2 (function-that-sets var)) (var3 (form-that-returns-a-lambda)) (declare (special var)) (lambda () (apply var3))) 13:51:38 now I don't have var3 anymore, but use (apply (form-that-returns-a-lambda)) within the LET* 13:51:57 it's not that easy to extract, please take a look at the source. 13:52:04 flip214: I have. 13:52:33 flip214: (form-that-returns-a-lambda) refers to the special-bound variables. 13:53:03 AFAICS with the change the (LET*) body seems to refer to the var3 _before_ the var2 function is called 13:53:37 to extract another way - what's the difference between 13:53:46 flip214: ask #lisp. 13:54:07 (LET* ((a (function-returning-lambda))) (lambda () (apply a))) and 13:54:13 the evaluation time of (form-that-returns-a-lambda is totally different 13:55:38 (LET* () (lambda () (apply (function-returning-lambda)) with respect to a special variable declared within the LET* 13:56:01 in one case, it is evaluated before the lambda is returned, in the dynamic scope of the lambda-creating function 13:56:09 in the other case, it is evaluated each time the lambda is called 13:56:15 Krystof: should be both time _after_ var2 got filled (which should set var, too) 13:56:25 no, look, pkhuong is right, and this is totally basic 13:56:28 Fare [fare@nat/google/x-vuxhxbanscdwcypw] has joined #sbcl 13:56:43 let me put it this way: (lambda () ) delays the evaluation of until the lambda is _called_ 13:56:49 ah, perhaps the fog is lifting now .... one moment, please 13:57:12 (let ((x )) (lambda () ... x ...)) closes over the value of at the time that the lambda is _created_ 13:57:14 yes, I think I got it. thanks. 13:57:20 None of this is SBCL specific; have you tried reproducing it in another implementation before crying "compiler bug"? 13:57:51 pkhuong: no. I asked on #lisp, but got no answer - then asked on #sbcl and got no answer. bad luck, I suppose. 13:58:20 well, in the latter case (create-scanner-aux) is called every time the LAMBDA is called, right. that's clear. 13:58:45 but why is VAR, that should have been set since setting VAR2 in the LET*, now unbound? 13:59:34 ah, the dynamic context at the _call_ time is important? hmmmrpf. 13:59:39 You might have had better luck if your responding to your original bug report didn't entail pulling all your fork of cl-ppcre. 13:59:54 yes. these are dynamically-bound variables. 14:00:52 well, learned something new. (or perhaps just repeated again, hoping that it sticks sometime.) 14:01:34 pkhuong: thanks for closing, would've just done that myself. 14:11:55 attila_lendvai [~attila_le@37.99.42.61] has joined #sbcl 14:11:56 -!- attila_lendvai [~attila_le@37.99.42.61] has quit [Changing host] 14:11:56 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 15:00:23 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 15:30:59 StevenZhang [~user@61.188.4.60] has joined #sbcl 15:42:06 wbooze [~wbooze@xdsl-78-35-149-246.netcologne.de] has joined #sbcl 16:13:00 attila_lendvai [~attila_le@37.99.42.61] has joined #sbcl 16:13:00 -!- attila_lendvai [~attila_le@37.99.42.61] has quit [Changing host] 16:13:01 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 16:15:10 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 16:30:17 homie [~homie@xdsl-78-35-149-246.netcologne.de] has joined #sbcl 16:30:17 -!- StevenZhang [~user@61.188.4.60] has quit [Remote host closed the connection] 16:40:55 -!- gko [~user@114-34-168-13.HINET-IP.hinet.net] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 16:53:15 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Read error: Connection reset by peer] 16:53:50 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 17:09:35 -!- kanru [~kanru@kanru-1-pt.tunnel.tserv15.lax1.ipv6.he.net] has quit [Ping timeout: 272 seconds] 17:13:08 kanru [~kanru@kanru-1-pt.tunnel.tserv15.lax1.ipv6.he.net] has joined #sbcl 17:25:57 superjudge [~mjl@c83-250-198-227.bredband.comhem.se] has joined #sbcl 17:33:22 stassats [~stassats@wikipedia/stassats] has joined #sbcl 17:36:28 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 18:13:09 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Quit: Leaving.] 18:36:39 how important are the optimizations in 1.0.4.28 really? 18:38:56 We're trying desperately to avoid consing bignums there, to the extent that thread safety is even being neglected a little. 18:41:26 mmm.. it's kind of important for our spinlock infrastructure 18:42:22 Yet if I read this right, if unix time isn't a fixnum (which it isn't, I think, on 32 bit), that code is consing in spite of the optimization. 18:42:30 And wouldn't be consing on 64 bit even without the optimization. 18:44:12 And I've now managed to get those odd Solaris/sparc gettimeofday failures on Linux/ppc, so I want to do away with this nonsense and use clock_gettime(CLOCK_MONOTONIC). And I think that throws out any assumptions that the base values are anywhere near unix epoch in the first place. 18:46:36 corss-platform monotonic times seems to be hairy. Will you wrapp all that C-side? 18:48:06 Probably. I've been reading http://www.python.org/dev/peps/pep-0418/ and https://github.com/ThomasHabets/monotonic_clock and came to the conclusion that it's not really hard. 18:48:09 That was before I really read the SBCL code though :-). 18:48:13 which kind of monotonic time ? with or without ntp adjustments ? with or without suspend time ? 18:49:15 fe[nl]ix: we'd probably not guarantee anything to users, I think, but would do our best to use the "best" clock available. 18:49:21 lichtblau: so you can hide some more stuff behind C, and lisp gets to receive runtimes directly without any arithmetic? (: 18:49:56 fe[nl]ix: would you recommend use of CLOCK_MONOTONIC_RAW over CLOCK_MONOTONIC if the former is indeed available or are you aware of unfortunate issues there? 18:50:09 for small measurements, including ntp adjustments can transform an effective 0.001s into 0.151s, or even -0.149s 18:50:39 lichtblau: depends on what you want to do 18:50:57 fe[nl]ix: if we could have something that never goes backward and usually goes forward with time, that'd be useful. 18:52:08 pkhuong: yeah, that might be a good idea. Right now it looks to me like warm init is calling get-internal-real-time before reinit-internal-real-time (argh!). I suppose that would solve itself, too, if the runtime took care of it. 18:54:31 CLOCK_MONOTONIC_RAW should usually be better than CLOCK_MONOTONIC 18:55:36 I've got most of pep-0418 in libfixposix 18:55:49 but not clock_monotonic_raw 19:11:13 sdemarre [~serge@91.176.76.27] has joined #sbcl 19:23:37 LiamH [~healy@12.133.56.98] has joined #sbcl 19:42:45 -!- LiamH [~healy@12.133.56.98] has quit [Ping timeout: 245 seconds] 19:47:54 LiamH [~healy@12.133.56.98] has joined #sbcl 19:54:25 -!- LiamH [~healy@12.133.56.98] has quit [Ping timeout: 246 seconds] 19:58:02 huangjs [~huangjs@69.84.244.131] has joined #sbcl 20:23:57 -!- angavrilov [~angavrilo@217.71.227.190] has quit [Ping timeout: 256 seconds] 20:32:02 -!- SHUPFS [~hercules@S0106001111de1fc8.cg.shawcable.net] has quit [Quit: leaving] 20:41:34 slyrus_ [~chatzilla@173-228-44-92.dsl.static.sonic.net] has joined #sbcl 21:01:26 -!- sdemarre [~serge@91.176.76.27] has quit [Ping timeout: 246 seconds] 21:04:35 SHUPFS [~hercules@S0106001111de1fc8.cg.shawcable.net] has joined #sbcl 21:04:44 -!- SHUPFS [~hercules@S0106001111de1fc8.cg.shawcable.net] has quit [Client Quit] 21:12:09 SHUPFS [~hercules@S0106001111de1fc8.cg.shawcable.net] has joined #sbcl 21:22:15 -!- prxq [~mommer@mnhm-5f75e695.pool.mediaWays.net] has quit [Quit: Leaving] 21:45:18 ccl-logbot [~ccl-logbo@setf.clozure.com] has joined #sbcl 21:45:18 21:45:18 -!- names: ccl-logbot SHUPFS slyrus_ huangjs stassats superjudge kanru homie wbooze Fare Vivitron jdz hlavaty ASau specbot asedeno_work galdor cmm pchrist Quadrescence Posterdati daimrod fe[nl]ix minion flip214 luis` |3b| sshirokov christoph_debian antoszka milosn joshe antifuchs scymtym slyrus lichtblau @Krystof redline6561 reb` les pkhuong ivan`` easye egn foom jsnell pipping 22:03:06 really? I would have expected that we want clock_monotonic rather than *_raw 22:03:35 not that it makes a huge difference 22:05:16 specifically, I thought that with *_RAW a machine clock running at the wrong speed would never get adjusted to the right value 22:05:41 which seems worse than a one-off skip, which could happen anyway e.g. if there's a scheduling hickup 22:10:56 for short timings, even a wrong speed is approximately correct in absolute value 22:12:01 I'm talking about the most common cases where the host clock skews by a few seconds per day at most 22:14:27 is it worse to have a constant 0.1% skew (due to a clock that's running at a wrong rate) than a single skip of at most 0.128s (due to ntp adjusting the date)? 22:14:42 I don't know for sure, but somehow the latter seems less bad 22:16:17 when you want to measure very short periods, a 0.128s adjustment can be wrong by 10000% 22:16:45 but it's a one-off 22:18:16 and an unlikely one, since it'd need to happen exactly when a ntp non-skew adjustment happens 22:18:46 and anyone depending on their process even getting scheduled every 1/8 of a second is screwed anyway 22:20:19 not necessarily 22:20:52 on Linux you can have a single thread to be assigned real-time priority 22:21:18 it's what pulseaudio does(using rtkit) 22:23:10 then they're screwed once that process decides to use some cpu time :-) speaking from the experience of trying to run rt priority processes 22:23:38 not process, thread 22:24:07 it works quite well on stock linux as long as there aren't too many real-time threads 22:24:07 don't see how that matters 22:24:20 (process vs. thread, that is) 22:28:37 -!- slyrus_ [~chatzilla@173-228-44-92.dsl.static.sonic.net] has quit [Ping timeout: 256 seconds] 23:04:36 I think we do not want g-i-real-t to ever go backwards, so that user code can depend on the sign of the difference between successive calls. 23:04:55 And I think CLOCK_MONOTONIC is meant to provide that guarantee, but there are kernel versions which are buggy. 23:05:39 oh, hadn't heard of that. though that the difference between monotonic and _raw was whether the rate the clock ran at was adjusted 23:05:42 But since we keep track of the previous result anyway, we can guard against that easily and just keep returning the old value, resulting only in an apparent freeze. 23:06:20 (because it user code can't deal with a freeze, that's a different matter, that's a user code bug) 23:07:09 indeed 23:07:23 Well, from the little I've found I think any kernel new enough to have _raw is also new enough to not have the bug with non_raw. 23:29:22 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 252 seconds] 23:51:26 -!- Posterdati [~quassel@host45-237-dynamic.6-87-r.retail.telecomitalia.it] has quit [Read error: Connection reset by peer] 23:53:36 Posterdati [~quassel@host45-237-dynamic.6-87-r.retail.telecomitalia.it] has joined #sbcl