00:03:22 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 252 seconds] 00:10:20 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 00:17:37 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 245 seconds] 00:21:34 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 00:23:58 Quadrescence: it's not *always* valid for reduce. Depends on :initial-value, or size of the list. 00:24:24 still, specialising an out-of-line reduce/+ would get all that magically. 00:25:07 ...and may well increase the code size compared to a straight inlined reduce, if results from initial tests with map[-into] are representative. 00:29:17 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 252 seconds] 00:36:30 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 00:43:48 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 268 seconds] 00:48:01 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 00:52:07 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 240 seconds] 01:00:11 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 01:06:16 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 245 seconds] 01:10:30 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 01:14:35 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 244 seconds] 01:22:38 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 01:26:54 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 246 seconds] 01:34:16 *froydnj* is going to commit a dx patch for functions in numbers.lisp that don't do dx already 01:34:35 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 01:39:00 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 255 seconds] 01:45:33 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 01:46:38 -!- slyrus_ [~chatzilla@173-228-44-92.dsl.static.sonic.net] has quit [Ping timeout: 244 seconds] 01:52:31 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 252 seconds] 01:55:50 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 01:59:58 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 246 seconds] 02:05:00 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 02:09:22 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 244 seconds] 02:14:31 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 02:20:52 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 255 seconds] 02:25:29 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 02:31:40 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 255 seconds] 02:36:35 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 02:43:12 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 246 seconds] 02:46:13 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 02:52:37 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 240 seconds] 02:55:08 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 03:01:34 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 246 seconds] 03:06:48 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 03:14:37 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 256 seconds] 03:20:38 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 03:27:56 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 245 seconds] 03:30:43 huangjs [~huangjs@69.84.244.131] has joined #sbcl 03:34:50 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 03:42:20 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 244 seconds] 03:49:18 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 03:55:41 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 260 seconds] 03:59:45 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 04:06:06 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 244 seconds] 04:11:07 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 04:15:25 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 246 seconds] 04:22:33 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 04:28:53 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 246 seconds] 04:33:54 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 04:43:01 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 256 seconds] 04:43:57 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 04:51:34 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 252 seconds] 04:59:04 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 05:05:58 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 245 seconds] 05:12:20 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 05:19:41 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 252 seconds] 05:26:04 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 05:33:27 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 244 seconds] 05:36:36 attila_lendvai [~attila_le@5.34.31.223] has joined #sbcl 05:36:36 -!- attila_lendvai [~attila_le@5.34.31.223] has quit [Changing host] 05:36:36 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 05:40:00 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 05:47:07 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 240 seconds] 05:51:11 attila_lendvai1 [~attila_le@37.99.47.192] has joined #sbcl 05:51:11 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Disconnected by services] 05:53:44 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 06:01:07 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 240 seconds] 06:08:17 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 06:12:34 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 240 seconds] 06:16:37 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 06:24:05 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 260 seconds] 06:25:25 -!- attila_lendvai1 [~attila_le@37.99.47.192] has quit [Quit: Leaving.] 06:26:57 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 06:33:21 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 244 seconds] 06:38:22 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 06:42:34 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 246 seconds] 06:49:33 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 06:56:45 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 260 seconds] 06:59:34 -!- sshirokov [sshirokov@2600:3c02::f03c:91ff:fe93:e02d] has quit [Ping timeout: 246 seconds] 07:00:15 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 07:02:32 sshirokov [sshirokov@2600:3c02::f03c:91ff:fe93:e02d] has joined #sbcl 07:04:21 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 244 seconds] 07:05:13 prxq [~mommer@mnhm-5f75f44d.pool.mediaWays.net] has joined #sbcl 07:08:41 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 07:11:51 attila_lendvai [~attila_le@37.99.47.192] has joined #sbcl 07:11:52 -!- attila_lendvai [~attila_le@37.99.47.192] has quit [Changing host] 07:11:52 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 07:14:58 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 246 seconds] 07:17:14 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 07:24:01 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 244 seconds] 07:28:27 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 07:34:21 Invalid exit status: threads.impure.lisp 07:34:22 07:34:54 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 240 seconds] 07:35:26 ::: Running (:INTERRUPT-THREAD :DEFERRABLES-UNBLOCKED-BY-LOCK) 07:35:26 fatal error encountered::: Success (:INTERRUPT-THREAD :DEFERRABLES-UNBLOCKED-BY-LOCK) 07:35:26 in SBCL pid 30236(tid 140737333556992): 07:35:26 deferrables blocked 07:36:44 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 07:39:49 -!- Kryztof [~user@81.174.155.115] has quit [Ping timeout: 246 seconds] 07:41:40 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 07:43:16 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 248 seconds] 07:47:22 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 07:48:41 -!- maxm- [~user@unaffiliated/maxm] has quit [Ping timeout: 268 seconds] 07:54:03 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 252 seconds] 07:55:55 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 08:02:29 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 252 seconds] 08:04:55 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 08:11:47 jdz [~jdz@85.254.212.247] has joined #sbcl 08:12:09 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 246 seconds] 08:14:46 Xof: futex or not futex? 08:15:42 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 08:22:53 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 256 seconds] 08:29:44 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 08:37:05 whatever is the default on x86-64/linux 08:37:23 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 244 seconds] 08:38:04 :sb-futex is in *features& 08:44:11 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 08:50:47 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 244 seconds] 08:58:03 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 09:05:34 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 255 seconds] 09:08:10 and it's reproducable? 09:09:00 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 09:15:38 -!- lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has quit [Ping timeout: 268 seconds] 09:17:16 Who's this lggr guy? 09:21:08 lichtblau: seems deterministic, on this build at least 09:21:17 So the test driver is behaving correctly -- if a background thread loses, the file fails, and the individual results ("Success") are being discarded, no matter what. 09:22:25 (The test itself is a little dubious, of course, because it doesn't test for truly user-visible behaviour, it doesn't test for correctness, but rather for an implementation artefact. 09:24:12 lggr [~lggr@84-73-159-126.dclient.hispeed.ch] has joined #sbcl 09:24:46 What matters as an invariant is that (and (not `signals blocked') *interrupts-enabled*) remains unchanged. 09:25:21 This test (or rather, its second half) merely asserts that our funny implementation detail happens, namely that `signals blocked' happens to change -- even though *interrupts-enabled* stays NIL, meaning that the invariant is preserved and the signal mask doesn't matter.) 09:25:47 is there a reason why SB-KERNEL:UB8-BASH-FILL doesn't use REP STOSB ? 09:26:20 Still -- I'm obviously concerned that it could be my fault. :-) 09:27:54 lggr: Please, fix your client. You keep bouncing on and off the channel. 09:31:06 it's presumably a logger bot 09:31:12 I messaged it ages ago 09:31:15 probably easiest is this 09:31:23 -!- ChanServ has set mode +o Xof 09:31:27 -!- Xof has set mode +b *!*lggr@*.dclient.hispeed.ch 09:31:35 -!- lggr [~crhodes@158.223.51.79] has been kicked from #sbcl by Xof (come back when you're fixed) 09:32:56 lichtblau: which patch would you most like me to revert to see if it disappears? From the sound of it, the test harness changes should stay and some other fun thing should be reverted 09:34:01 let's see if I can reproduce on a different machine, too 09:34:10 though ubuntu-current should be vanilla enough... 09:36:20 "I know, we'll just check in the boinkmark database at which commit the problem started" was my immediate thought. 09:36:57 but won't the problem look like it starts at the improved test harness commit? 09:36:57 Turns out the boinkmarks are hanging in timer.impure.lisp since Sep 8 or Sep 11. 09:37:20 Xof: Thx. 09:39:33 grmbl the old sbcl that I have here is too old to run threads.impure.lisp 09:41:49 ok, so 1.0.58.16-slightly-dirty passes :deferrables tests on this other machine I have here (using the new threads test harness) 09:42:35 so now I will build and test HEAD on this machine and see what happens 09:42:36 Well, can you revert Nikodemus locking changes (23912568 or so) and see if that helps? Who knows, maybe I'm not actually at fault. 09:46:00 It's also not entirely impossible that you're just unlucky. If the SLEEP 1 in the parent thread is done before the child thread is ready, you lose. (Because grabbing a lock unblocks deferrables only when the lock is not free.) 09:47:14 I feel unlucky 09:48:57 on this other machine, threads.impure.lisp on HEAD has just passed with flying colours 09:55:53 OK, plausible it's a test timing bug: I just ran it twice in succession with the locking changes reverted, and it failed on the first run and passed on the second 09:57:08 Very well then. So your computer is too slow for (sleep 1) to be sufficient. :-) 09:58:16 it's my fault for fetishizing ancient technology. clearly a four-core x86-64 can't cope with advanced technologies like Common Lisp 10:13:32 attila_lendvai [~attila_le@87.247.56.43] has joined #sbcl 10:13:32 -!- attila_lendvai [~attila_le@87.247.56.43] has quit [Changing host] 10:13:32 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 10:14:13 joshe is the SunOS guy, right? 10:15:05 Who else gets weird gettimeofday errors on SunOS/x86 that don't happen anywhere else? 10:17:52 *|3b|* gets failures on (DIVIDE-BY-ZERO BUG-346) (DIVIDE-BY-ZERO BUG-356) BUG-310173, wonders if i bult something wrong 10:19:19 <|3b|> is there some way to set default build options like --fancy and heap size? 10:20:39 Default in which sense? I thought --fancy _is_ how the young kids set default build options these days, instead of persisting them in c-t-f.lisp. 10:21:04 <|3b|> default as in i won't forget to set it every time i build then have to rebuild it again :p 10:22:27 *|3b|* runs debug.impure.lisp tests a few time and gets same failures 10:24:35 I kind of like c-t-f.lisp in principle -- exactly because it's persistent. (At least now I do, because after only about a decade or so of forgetting that there's a LAMBDA needed, I finally know what syntax the file has.) 10:24:37 *|3b|* wonders how dynamic-extent for numeric functions' &rest interacts with boxed values 10:24:59 Still I'm tempted to embrace the new way and add a --developer to make.sh that is sort of like --fancy, but enabled developer-friendly features rather than user-friendly 10:25:38 features. So, sb-after-xc-core obviously, but also ud2-breakpoints, and the new sb-qshow. 10:26:01 (Now that I've finally discovered ud2-breakpoints, I don't know how I could live without them.) 10:56:17 adding to my wishlist: whatever magic is necessary that hitting C-c at the shell after sh run-tests.sh threads.impure.lisp actually cancels the tests rather than letting I don't know what continue to happen in the background 11:17:19 hmm; SIGINT is delivered to the process group in that case? 11:49:45 waah, now I am getting the same failures as |3b| 11:49:53 all I want is to push my changes 11:50:49 ...don't we all? 11:52:52 The disassembly confirms it -- gettimeofday is a straight syscall on SunOS. So how could there be thread-safety or re-entrancy issues? But it "fails" particularly around thread- or debugger- or maybe signal-related places. 11:53:15 *|3b|* doesn't (or at least isn't sure enough about them to push them even if i could :p ) 11:53:29 so, presumably this is froydnj's dynamic-extent changing things 12:04:26 aw, is that causing problems? 12:05:44 stassats [~stassats@wikipedia/stassats] has joined #sbcl 12:05:48 mailing 12:34:44 splendid, that's what I call a solid bug fix: I can recognize the SunOS failure mode systematically, because since 2001, tv_sec and tv_usec fall onto opposite sides of the 1 billion mark. 12:34:53 So if, based on that test, it looks like tv_sec ended up in tv_usec, just loop and try again. Unless they have a time machine, the "solution" cannot legitimately be broken by users. 12:38:05 Oh wait, us, not ns. So actually such a test works since Jan 12, 1970. 12:38:06 wtf? 12:46:10 -!- sshirokov [sshirokov@2600:3c02::f03c:91ff:fe93:e02d] has quit [*.net *.split] 12:46:10 -!- cracauer [cracauer@nat/google/x-adpwqfbvkhahcwrs] has quit [*.net *.split] 12:46:10 -!- foom [jknight@nat/google/x-hjrhwlocfeedxtvi] has quit [*.net *.split] 12:56:43 sshirokov [sshirokov@2600:3c02::f03c:91ff:fe93:e02d] has joined #sbcl 13:01:17 foom [jknight@nat/google/x-iugimviezhuhnfge] has joined #sbcl 13:01:28 cracauer [cracauer@nat/google/x-khdgluwrahbzbvkm] has joined #sbcl 13:26:37 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 13:41:49 homie [~levgue@xdsl-78-35-173-127.netcologne.de] has joined #sbcl 13:43:27 pkhuong, re: REDUCE, it'll always be called with zero or two arguments, and the zero-argument case occurs in the case of (reduce f empty-seq), and only in that case. 13:51:52 gko [~user@114-34-168-13.HINET-IP.hinet.net] has joined #sbcl 13:55:21 Quadrescence: I think pkhoung was just intimating that you have to be more careful than blindly expanding F to (LAMBDA (X Y) (FUNCALL F X Y)) 13:56:57 oh yes 13:59:36 I think (reduce f seq ...) ==> (if (= 0 (length seq)) [.. (funcall f)] (reduce (lambda (x y) (funcall f x y)) seq ...)) is always a valid transformation. The [.. x] denotes a little more checking there (like whether an initial value exists and whatever; very trivial) 14:00:09 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 14:00:28 wbooze [~wbooze@xdsl-78-35-173-127.netcologne.de] has joined #sbcl 14:11:29 p_nathan [~Adium@75.87.250.229] has joined #sbcl 14:12:01 How much memory does SBCL need to compile on x86_64? 14:13:35 nobody measured it? 14:14:22 less than 4GB 14:17:01 I have a 1 gb system and sbcl's complaining about being unable to allocate memory. So I'm trying to figure out how to tune ulimit correctly. 14:17:59 you gave it --dynamic-space-size already ? 14:18:17 and make sure your libs not require more ? 14:18:57 a 1gb system may be too little for when you load too much libs..... 14:18:58 I thought that defaulted to 512mb, maybe I am out of date? 14:19:21 i have to approximately reserver 1.5 gb for the libs i have 14:19:30 1492 mb or so 14:19:37 or 1623 14:19:57 p_nathan: that's the x86 default, not the x86_64 default 14:20:27 -!- Mazingaro [~Tetsuja@host57-4-dynamic.10-87-r.retail.telecomitalia.it] has quit [Ping timeout: 245 seconds] 14:21:25 Ahhh 14:22:20 so --dynamic-space-size 500 might work with ulimit -v 600000, for example 14:23:55 *p_nathan* fiddles. 14:24:07 There we go. xc-host=sbcl dynamic-space-size 14:24:10 Mazingaro [~Tetsuja@host57-4-dynamic.10-87-r.retail.telecomitalia.it] has joined #sbcl 14:24:20 well that's the host side only 14:25:09 there's a --dynamic-space-size for the guest too 14:25:36 --dynamic-space-size blah --xc-host='sbcl --dynamic-space-size blah...' 14:29:00 so the compilation step is the guest, and the image is the host 14:29:09 wait 14:29:10 or ? 14:29:14 or vice versa ? 14:29:29 there is no "guest" 14:29:29 oh man 14:29:50 s'ok, I've got it tuned. 14:30:09 At least, it hasn't crashed and burned yet. :) 14:30:12 well there's the make step, which until bootstrap plays the role of the guest or so 14:30:15 -!- Mazingaro [~Tetsuja@host57-4-dynamic.10-87-r.retail.telecomitalia.it] has quit [Ping timeout: 245 seconds] 14:30:18 afaik 14:35:49 *Quadrescence* thinks boole-* functions should be defined as their own symbolic constants: (defconstant boole-* 'boole-*) 14:35:57 s/functions/constants/ 14:37:48 i think one shouldn't think about BOOLE at all 14:38:25 stassats, from a programmer standpoint, sure. 14:38:53 That doesn't mean the implementation style needs to live in the 70s. 14:39:42 one would think that using small integers can be faster 14:40:56 I'm going to hazard to guess that most of the time it's going to be transformed. 14:41:29 well, then boole shouldn't be used in that case at all 14:42:20 is constant equality really a lot slower than fixnum comparison 14:42:26 s/constant/symbol/ 14:43:15 small integers could be used in a jump-table 14:44:15 stassats, in what instance do you suppose we will get massive speed gains? 14:44:32 i don't want to talk about boole anymore 14:44:36 ok 14:46:23 Quadrescence: http://www.xach.com/naggum/articles/3250122499743574@naggum.no.html 14:46:50 as I recall, one of the early machines (PDP-x, maybe) had a boole instruction which had the .... 14:47:55 thanks, lichtblau. Fun fact: clisp's values for those constants are different, which was one of the early cross-compilation bugs I fixed, way back in ... 2003 14:48:08 0.8.5.3 -- when we had sane version numbers 14:48:47 sec [~sec@218.79.255.81] has joined #sbcl 14:48:53 Xof: did you recall that or looked up? 14:49:22 lichtblau, so, I'm reading that the integers chosen for boole-* operations follow a pattern for two arbitrary input arguments, and that the pattern can be exploited on the PDP-10. 14:50:48 stassats: what, my commit? Looked it up :-) 14:51:02 Xof: "people" keep saying stuff like `bump the version number to 1.1 when windows support has improved'. Just to spite those people, I might be fun to bump it in time before the windows improvements hit. 14:51:02 yeah, the commit number 14:51:28 lichtblau: then bump it to 2.0? 14:51:42 -!- sec [~sec@218.79.255.81] has quit [Quit: Leaving] 14:56:59 :-) Don't know; I don't believe much in trying to send a specific message with a version number. 14:57:29 just call it The New SBCL? 14:57:59 Having it go to \infty just comes with the downside that it's getting harder to remember just how ancient a certain number is. Might not be bad to go to 1.1 for the same reason that it's nice that Linux is finally on 3.x instead of the 2.6. convention. 14:58:08 I think incrementing the version number to reflect the new version number policy makes perfect sense 14:58:23 wait, there's a new policy? 14:58:51 there will be if I increment it 15:00:45 lichtblau: well, the best version number to gauge age is 2012.09 15:03:43 slyrus_ [~chatzilla@adsl-99-183-243-129.dsl.pltn13.sbcglobal.net] has joined #sbcl 15:07:41 oh, you were suggesting 1.y rather than 1.x.y? I didn't notice that part of the mail. 15:10:04 or maybe 1.1.z 15:10:41 which number will z approach? 15:11:41 -!- slyrus_ [~chatzilla@adsl-99-183-243-129.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 245 seconds] 15:12:27 depends when the version number policy changes again 15:18:24 *lichtblau* going to retreat to the "I don't care anyway" position 15:19:02 i prefer the "current" version anyhow 15:21:02 just let me know once we've switched to Ubuntu numbering and it's "SBCL Spectactular Symphytognathidae" etc. 15:22:27 Copper Credits 15:23:41 Aluminum Accounts, Bromine Bank, Duralumin Derivatives 15:27:36 brown [user@nat/google/x-rbxbwhqbiqooivtw] has joined #sbcl 15:28:00 -!- brown is now known as Guest66944 15:29:03 -!- Guest66944 is now known as reb 15:44:43 antgreen [user@nat/redhat/x-huavadrgpaoyzela] has joined #sbcl 15:50:50 Quadrescence: boole indices can be used as lookup tables, iirc. 15:51:58 I remain unconvinced. 15:55:16 Maybe it's unreasonable to be annoyed by > (* boole-nor boole-and) ==> 66 16:03:10 what's so annoying about that? 16:07:59 It's bad design. 16:08:27 the whole boole thing is bad design, so what? 16:09:30 There's design that can be controlled (implementation design) and design that can't (standard design). The latter is out of the control of the implementer, and the former is not. That's the difference. 16:09:51 how about spending your time on stuff that actually matters? 16:12:30 stassats, matters according to whom? 16:13:18 to common sense 16:15:33 stassats, yes, I admit that this sort of affects the user very little, and affects the implementation very little, but so does a long drawn out discussion about whether version numbers should be 1.0.x->infty or 1.1.x or 1.y or 2.0. I made the comment as I was learning more about SBCL. If you don't care about the issue, refrain from commenting. If everyone doesn't care, everyone will refrain from commenting, and it'll be forgotten about. 16:16:50 but it does matter :-). The current numbering scheme is inherently beautiful; the proposed alternative completely boring. 16:42:22 attila_lendvai [~attila_le@37.99.47.192] has joined #sbcl 16:42:22 -!- attila_lendvai [~attila_le@37.99.47.192] has quit [Changing host] 16:42:22 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 16:44:46 -!- gko [~user@114-34-168-13.HINET-IP.hinet.net] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 16:52:12 lichtblau: no, joshe is the openbsd guy 16:52:28 you confused me with the other guy who likes a weird OS and never commits anything :) 16:54:46 so who is going to work on the Genera port of SBCL 16:54:54 Faré 16:55:00 good man 17:06:25 hmm, jwise? 17:07:41 sorry about that! (at least I had the first letter right...) 17:20:48 yea, I think he's the sunos guy 17:21:00 I've built sbcl on solaris before, but only on sparc 17:22:51 re different backtraces after DX arglists, ISTM the only issue is that DX breaks tailcalls in the entry points, so we should just adjust the tests. 17:27:14 milanj [~milanj_@109-93-103-71.dynamic.isp.telekom.rs] has joined #sbcl 17:32:10 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Quit: Leaving] 17:44:32 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 17:55:35 Krystof [~user@81.174.155.115] has joined #sbcl 17:55:36 -!- ChanServ has set mode +o Krystof 18:09:04 hm 18:09:12 I don't understand dynamic-extent 18:09:51 I don't really understand what I'm seeing in the backtraces, either 18:15:09 one is the external entry point, the other the optional-handling one. 18:17:31 leuler [~user@p548F9B3F.dip.t-dialin.net] has joined #sbcl 18:20:14 I would have expected the xep to tail-call the optional handling one 18:21:03 and also the optional-handling one to tail-call the `real' one 18:24:20 sdemarre [~serge@91.176.196.235] has joined #sbcl 18:25:45 why should having a truly-dynamic-extent declaration inhibit those tail calls? 18:26:12 is it the explicit construction of a &rest list from the &more? 18:30:37 Krystof: I'd think so. 18:31:12 pretty sure &rest consing happens in either (hopefully not both) of those entry points. 18:37:26 but but, ok, the &rest consing gets put on the stack... why should /that/ inhibit tail calling? 18:37:40 and why are both tail calls inhibited? 18:42:54 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 18:47:35 DX inhibits tail calling because we have to clean it up (pop that stuff off the stack... we could try and be clever with old-fp/old-sp, but I think we have strong assumption of a contiguous stack) 19:31:28 -!- antgreen [user@nat/redhat/x-huavadrgpaoyzela] has quit [Ping timeout: 244 seconds] 19:46:10 so it's a sparse structure that you can't handle rather ? 20:26:25 -!- galdor_ is now known as galdor 20:35:33 -!- sdemarre [~serge@91.176.196.235] has quit [Ping timeout: 244 seconds] 21:09:38 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 244 seconds] 21:29:57 -!- leuler [~user@p548F9B3F.dip.t-dialin.net] has quit [Quit: ERC Version 5.1.2 $Revision: 1.796.2.6 $ (IRC client for Emacs)] 21:36:40 -!- prxq [~mommer@mnhm-5f75f44d.pool.mediaWays.net] has quit [Remote host closed the connection] 21:59:55 Mazingaro [~Tetsuja@host110-237-dynamic.20-87-r.retail.telecomitalia.it] has joined #sbcl 22:13:01 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Quit: Leaving.] 22:45:14 -!- milanj [~milanj_@109-93-103-71.dynamic.isp.telekom.rs] has quit [Quit: Leaving]