00:02:23 davazp` [~user@92.251.222.64] has joined #sbcl 00:02:58 -!- davazp` [~user@92.251.222.64] has quit [Client Quit] 00:05:55 -!- davazp [~user@31.200.158.14] has quit [Ping timeout: 264 seconds] 00:26:32 -!- wbooze [~wbooze@xdsl-87-79-196-51.netcologne.de] has quit [Ping timeout: 260 seconds] 00:35:12 Watcher7 [~w@silly.tabby.cat] has joined #sbcl 00:38:47 edgar-rft [~GOD@HSI-KBW-149-172-63-75.hsi13.kabel-badenwuerttemberg.de] has joined #sbcl 01:07:32 -!- minion [~minion@common-lisp.net] has quit [Remote host closed the connection] 01:07:38 minion [~minion@common-lisp.net] has joined #sbcl 02:19:52 Krystof: i've hit my coding quota. div by mul will have to be a paper ;) 02:37:03 kanru` [~kanru@118-163-10-190.HINET-IP.hinet.net] has joined #sbcl 02:38:34 -!- drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 02:39:01 -!- christoph4 [~christoph@ppp-93-104-2-211.dynamic.mnet-online.de] has quit [Ping timeout: 276 seconds] 02:44:44 drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has joined #sbcl 02:52:48 christoph4 [~christoph@ppp-188-174-138-74.dynamic.mnet-online.de] has joined #sbcl 02:53:22 -!- edgar-rft [~GOD@HSI-KBW-149-172-63-75.hsi13.kabel-badenwuerttemberg.de] has quit [Ping timeout: 246 seconds] 03:19:33 -!- Hydan [~hydan@ip-89-103-110-5.net.upcbroadband.cz] has quit [Ping timeout: 252 seconds] 04:05:12 Strigoides [~owen@114-134-0-26.lightwire.co.nz] has joined #sbcl 04:06:52 edgar-rft [~GOD@HSI-KBW-149-172-63-75.hsi13.kabel-badenwuerttemberg.de] has joined #sbcl 04:10:19 looking at our move-from-* VOPs really makes me think we should move the slow paths to *elsewhere* 04:22:35 -!- Watcher7 [~w@silly.tabby.cat] has left #sbcl 04:23:52 attila_lendvai [~attila_le@92.46.2.228] has joined #sbcl 04:23:52 -!- attila_lendvai [~attila_le@92.46.2.228] has quit [Changing host] 04:23:52 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 05:02:16 -!- Fare [~fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has quit [Quit: Leaving] 05:30:02 scymtym [~user@89.31.118.161] has joined #sbcl 05:33:25 -!- Bike [~Glossina@71-214-81-94.ptld.qwest.net] has quit [Ping timeout: 248 seconds] 05:34:57 Bike [~Glossina@71-214-81-94.ptld.qwest.net] has joined #sbcl 05:50:30 -!- yacks [~py@180.151.36.168] has quit [Ping timeout: 264 seconds] 05:53:14 yacks [~py@180.151.36.168] has joined #sbcl 06:15:28 -!- Bike [~Glossina@71-214-81-94.ptld.qwest.net] has quit [Ping timeout: 276 seconds] 06:18:58 Bike [~Glossina@71-214-81-94.ptld.qwest.net] has joined #sbcl 06:19:51 -!- kanru` [~kanru@118-163-10-190.HINET-IP.hinet.net] has quit [Remote host closed the connection] 06:22:23 prxq [~mommer@mnhm-4d012407.pool.mediaWays.net] has joined #sbcl 06:37:38 teggi [~teggi@123.20.48.15] has joined #sbcl 06:39:57 kanru` [~kanru@118-163-10-190.HINET-IP.hinet.net] has joined #sbcl 06:43:43 -!- kanru` [~kanru@118-163-10-190.HINET-IP.hinet.net] has quit [Remote host closed the connection] 06:57:18 -!- teggi [~teggi@123.20.48.15] has quit [Ping timeout: 256 seconds] 07:04:01 pkhuong: good for you (also, curses). Regarding , could the message not simply be "Derived type of (MIN X Y) is (VALUES FIXNUM &OPTIONAL) ..."? 07:19:18 -!- robgssp [~user@c-24-147-78-203.hsd1.nh.comcast.net] has quit [Ping timeout: 264 seconds] 07:33:11 -!- Bike [~Glossina@71-214-81-94.ptld.qwest.net] has quit [Ping timeout: 240 seconds] 07:39:59 -!- edgar-rft [~GOD@HSI-KBW-149-172-63-75.hsi13.kabel-badenwuerttemberg.de] has quit [Quit: nuclear meltdown] 07:52:01 -!- ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has quit [Ping timeout: 248 seconds] 07:57:52 kanru` [~kanru@118-163-10-190.HINET-IP.hinet.net] has joined #sbcl 08:23:48 teggi [~teggi@113.172.45.143] has joined #sbcl 08:31:54 stassats [~stassats@wikipedia/stassats] has joined #sbcl 08:35:22 -!- stassats [~stassats@wikipedia/stassats] has quit [Read error: Connection reset by peer] 08:44:24 -!- teggi [~teggi@113.172.45.143] has quit [Ping timeout: 256 seconds] 08:45:49 minion: memo for nyef: there have in the past been bugs on ppc (and sparc, and alpha) regarding loading constants using sequences of assembly instructions 08:45:49 Remembered. I'll tell nyef when he/she/it next speaks. 08:46:26 (istr there being a hilarious one on alpha where bit 49 of a 64-bit constant was wrong 25% of the time. And of course there was the bit-13 bug in call_into_c on ppc) 10:04:27 Krystof: how can such a bug pass through any testing? One would expect loading of 64-bit constants to be an operation that isn't particularly rare? 10:06:45 ah. It was only wrong when it was meant to be set 10:07:39 stassats [~stassats@wikipedia/stassats] has joined #sbcl 10:07:43 so loading of 64-bit constants is rare compared with loading 32-bit constants 10:07:53 -!- Strigoides [~owen@114-134-0-26.lightwire.co.nz] has quit [Quit: leaving] 10:17:09 -!- kanru` [~kanru@118-163-10-190.HINET-IP.hinet.net] has quit [Ping timeout: 248 seconds] 10:23:23 oh i see 10:23:26 but still :-) 10:23:36 well quite 10:24:12 I'd imagine loading of things like ~0 was done through something like sub g0,1,l0 (in sparc, I don't know Alpha, but you get the gist?) 10:24:26 the call_into_lisp thing which only worked if bit 13 of the address that it was calling to was particularly painful 10:25:00 loke_: right, that kind of thing works for "special" values 10:25:52 How many registers does the alpha have? 10:27:07 32 10:45:42 johnc [~johnc@61.135.169.73] has joined #sbcl 10:52:51 time to test on windows 10:52:57 -!- stassats [~stassats@wikipedia/stassats] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 10:54:35 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 10:56:32 -!- yacks [~py@180.151.36.168] has quit [Ping timeout: 260 seconds] 10:59:58 stassats [~stassats@wikipedia/stassats] has joined #sbcl 11:00:19 just tried, and inded C-c just exits sbcl on windows, 1.1.7 11:00:43 the fork manages to print "debugger invoked" and then exits too 11:02:17 that's in the mingw shell, bare cmd.exe enters into the debugger in the fork 11:02:29 waiting for the build to try mainline in cmd.exe 11:03:20 why is building on windows so much slower? 11:05:21 yacks [~py@180.151.36.168] has joined #sbcl 11:05:32 I can't remember why, but it might be related to why git is slow -- filesystem access? stat? 11:06:20 maybe, the initial phase takes very long, before it even starts compiling anything 11:08:53 the build seems to be fine, waiting for sb-concurrency tests to fail 11:09:05 they take a long time to do so 11:09:51 oh, that reminds me, i had a threading (?) failure on OS X 10.8.3 while on the train 11:10:06 and the general tests, there have been failed tests for some time now, not sure how to compare them with the current situation 11:10:25 Quadrescence: how fast was your train moving? 11:10:55 at least 60mph (100kph) 11:11:30 that shouldn't bring any relativistic effects 11:11:36 :) 11:12:52 and now the build process seems to be hung completely 11:13:00 the joy of windows threads 11:15:05 why don't we have any developers who actually use windows? 11:15:58 or care enough for it 11:18:54 the build is ok, that's how much i care 11:20:01 if i was still using windows and lisp for work, i'd care about it more 11:20:38 if i didn't have to reboot to get into it, it'd be a bit easier to care 11:21:08 stassats, hey when are you going to write a patch for cool colourful disassemblies 11:21:54 when it will start to make sense 11:34:00 -!- johnc [~johnc@61.135.169.73] has quit [Ping timeout: 252 seconds] 11:38:21 johnc [~johnc@61.135.169.73] has joined #sbcl 11:49:15 davazp [~user@31.200.185.238] has joined #sbcl 11:49:21 -!- johnc [~johnc@61.135.169.73] has left #sbcl 12:31:30 Krystof: it's not always possible to find a source form, or sometimes you have really hairy macros. 12:33:54 -!- davazp [~user@31.200.185.238] has quit [Ping timeout: 256 seconds] 12:35:18 -!- drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 12:35:56 drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has joined #sbcl 12:43:02 -!- drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 12:45:28 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 13:02:01 drmeister [~drmeister@166.137.87.66] has joined #sbcl 13:02:07 davazp [~user@31.200.140.131] has joined #sbcl 13:02:30 edgar-rft [~GOD@HSI-KBW-149-172-63-75.hsi13.kabel-badenwuerttemberg.de] has joined #sbcl 13:03:49 pkhuong: fair enough then 13:12:10 -!- drmeister [~drmeister@166.137.87.66] has quit [Remote host closed the connection] 13:25:12 drmeister [~drmeister@farnsworth.chem.temple.edu] has joined #sbcl 13:46:45 segv- [~mb@95-91-241-68-dynip.superkabel.de] has joined #sbcl 13:48:06 wbooze [~wbooze@xdsl-78-35-148-78.netcologne.de] has joined #sbcl 14:14:53 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Quit: Leaving] 14:15:16 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 14:17:08 nyef [~nyef@c-50-157-244-41.hsd1.ma.comcast.net] has joined #sbcl 14:19:36 ah, I don't run the tests on darwin/x86 anymore, so there might be regressions: the x86 tests make my laptop panic. 14:20:00 Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has joined #sbcl 14:20:02 treerex [~tree@c-24-34-53-59.hsd1.ma.comcast.net] has joined #sbcl 14:23:49 Is there an equivalent to a "make dist-clean" for SBCL that yields a clean slate? 14:24:06 ... git clone, maybe? 14:24:06 nyef, memo from Krystof: there have in the past been bugs on ppc (and sparc, and alpha) regarding loading constants using sequences of assembly instructions 14:24:37 nyef: yeah, that was what I was going to do, but wondered if there was another way. 14:25:27 treerex: like clean.sh? 14:25:44 I suspect that clean.sh isn't perfect. 14:25:57 wow, I suppose it would help if I actually looked at the directory listing... 14:26:28 it leaves junk in tests/ 14:27:03 Okay, building SPARC/Linux HEAD now. 14:28:53 I'm hoping for a distinct lack of surprises in the test output. That's not to say that I'm hoping for a CLEAN test output, just not to be surprised. 14:58:10 slyrus [~chatzilla@adsl-108-192-103-248.dsl.pltn13.sbcglobal.net] has joined #sbcl 15:18:40 -!- scymtym [~user@89.31.118.161] has quit [Ping timeout: 252 seconds] 15:50:13 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Quit: Leaving] 15:50:34 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 16:14:37 -!- slyrus [~chatzilla@adsl-108-192-103-248.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 256 seconds] 16:22:31 -!- drmeister [~drmeister@farnsworth.chem.temple.edu] has quit [Remote host closed the connection] 16:24:00 milanj [~milanj@82.117.199.26] has joined #sbcl 16:29:59 What's alien.impure.lisp / BUG-654485 ? 16:30:38 Hrm. "bad note"? 16:31:31 Ah. "Could not stack allocate". The test is fragile. 16:32:01 Oh, and compiler.pure.lisp / MODULAR-CUT-CONSTANT-TO-WIDTH again. 16:32:47 An unhandled error in compiler.impure...? 16:33:24 we've got a couple bare asserts in there, iirc. 16:33:40 Poor form. /-: 16:33:52 alien performance test tend to be fragile... they could at least compare the note's string before complaining. 16:34:02 Yeah, exactly. 16:34:40 Still checking for further regressions of significance, but I'm obviously going to have to get my hands on a sparc archref and a couple of weeks of spare hacking time. 16:35:32 "The value 5129 is not of type (OR TN (SIGNED-BYTE 13) NULL FIXUP)." 16:36:43 constant character in VOP? 16:37:26 Looks to be compiling either defmacro def-many-code-constants or test :many-code-constants. 16:38:44 Might be exceeding some limit on the number of constants that the compiler can address in a function, but doing so in such a way that it blows up while building the test. 16:39:13 I think this test would work better with a COMPILE NIL rather than a DEFUN. 16:40:54 drmeister [~drmeister@166.137.84.99] has joined #sbcl 16:41:15 Okay, so there were some surprises, and a couple of them look like they might be nasty surprises, but I don't think that I'm about to call any of them showstoppers. 16:47:19 When you shut down a SPARC system, does it become a Data General NOVA system, or does that only happen to the larger machines? 16:54:25 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 248 seconds] 16:55:18 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 17:05:57 -!- drmeister [~drmeister@166.137.84.99] has quit [Remote host closed the connection] 17:07:46 drmeister [~drmeister@166.137.84.99] has joined #sbcl 17:11:28 -!- drmeister [~drmeister@166.137.84.99] has quit [Remote host closed the connection] 17:15:02 sdemarre [~serge@91.176.221.3] has joined #sbcl 17:16:35 Bike [~Glossina@71-214-81-94.ptld.qwest.net] has joined #sbcl 17:16:45 drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has joined #sbcl 17:17:50 stassats` [~stassats@wikipedia/stassats] has joined #sbcl 17:19:24 -!- stassats [~stassats@wikipedia/stassats] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 17:27:38 slyrus [~chatzilla@173-228-44-92.dsl.static.sonic.net] has joined #sbcl 17:33:42 -!- davazp [~user@31.200.140.131] has quit [Ping timeout: 252 seconds] 17:52:22 -!- wbooze [~wbooze@xdsl-78-35-148-78.netcologne.de] has quit [Ping timeout: 256 seconds] 17:57:02 so, what's wrong on sparc/ppc with modular-cut-to-constant-width? 17:57:13 I was beginning to hope that all the excitement was calming down 18:01:21 -!- treerex [~tree@c-24-34-53-59.hsd1.ma.comcast.net] has quit [Quit: Leaving.] 18:01:39 treerex [~tree@c-24-34-53-59.hsd1.ma.comcast.net] has joined #sbcl 18:11:02 wbooze [~wbooze@xdsl-78-35-130-152.netcologne.de] has joined #sbcl 18:11:55 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 260 seconds] 18:14:52 attila_lendvai [~attila_le@92.46.2.228] has joined #sbcl 18:14:52 -!- attila_lendvai [~attila_le@92.46.2.228] has quit [Changing host] 18:14:52 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 18:20:27 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Read error: Connection reset by peer] 18:20:34 attila_lendvai [~attila_le@92.46.2.228] has joined #sbcl 18:20:34 -!- attila_lendvai [~attila_le@92.46.2.228] has quit [Changing host] 18:20:34 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 18:23:15 attila_lendvai1 [~attila_le@92.46.2.228] has joined #sbcl 18:23:15 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Disconnected by services] 18:23:15 -!- attila_lendvai1 [~attila_le@92.46.2.228] has quit [Changing host] 18:23:15 attila_lendvai1 [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 18:24:55 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 18:24:55 -!- attila_lendvai1 [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Read error: Connection reset by peer] 18:26:51 foreignFunction [~niksaak@ip-4761.sunline.net.ua] has joined #sbcl 18:31:48 attila_lendvai1 [~attila_le@92.46.2.228] has joined #sbcl 18:31:48 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Disconnected by services] 18:31:48 -!- attila_lendvai1 [~attila_le@92.46.2.228] has quit [Changing host] 18:31:48 attila_lendvai1 [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 18:33:20 Bike_ [~Glossina@71-214-84-201.ptld.qwest.net] has joined #sbcl 18:34:43 Krystof: Best guess, existing issues with modular operations on these platforms. I'm HOPING that it's not a regression, but haven't exactly checked. 18:35:03 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 18:35:03 -!- attila_lendvai1 [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Client Quit] 18:35:34 -!- Bike [~Glossina@71-214-81-94.ptld.qwest.net] has quit [Ping timeout: 256 seconds] 18:36:11 -!- Bike_ is now known as Bike 18:36:37 The only regression I can think of would be in b111015 (Complete cut-to-width), but the modified codepath shouldn't be used tickled in that test. 18:39:42 nyef: do you have evaluation results / disassembly? 18:40:08 hm, do I have access to any ppc machines any more? 18:40:14 No, and my PPC and SPARC are currently offline. I can wake one of them up, if necessary. 18:40:32 "necessary" is a terrible word 18:40:44 I'm sure it's not a regression, but it would be nice to fix 18:40:48 A beautiful and terrible word. 18:41:19 It's on my list for the next month, both PPC and SPARC, and possibly to check it on MIPS. 18:42:17 attila_lendvai1 [~attila_le@92.46.2.228] has joined #sbcl 18:42:17 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Disconnected by services] 18:42:17 -!- attila_lendvai1 [~attila_le@92.46.2.228] has quit [Changing host] 18:42:17 attila_lendvai1 [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 18:42:22 *nyef* restarts his PPC. 18:46:49 -!- attila_lendvai1 [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Client Quit] 18:46:50 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 18:47:26 attila_lendvai1 [~attila_le@92.46.2.228] has joined #sbcl 18:47:26 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Disconnected by services] 18:47:26 -!- attila_lendvai1 [~attila_le@92.46.2.228] has quit [Changing host] 18:47:26 attila_lendvai1 [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 18:50:12 Okay, preliminary investigation: http://paste.lisp.org/display/137260 18:52:55 that's interesting. 18:53:23 Annotated with trace output. 18:55:09 2 18:55:14 wtf 18:55:15 2 18:55:26 shades of (* 2 3) => 12 18:56:27 also, BF L6 immediately followed by B L6 does not inspire confidence 18:57:05 ... we do (if (eq x 3) [c24] [c25]) c24: return 2. 18:57:12 it's an IR1 bug (!?) 18:57:43 wait, no, that's right. 18:59:32 yes, that's right, but quite a lot of the other conditions end up at c24 too 18:59:50 Let me know if you need me to test anything. I'm afraid that my problem-solving bandwidth is mostly allocated for the remaining hour and a half before I have to leave for the evening. 19:01:19 yeah, we're not clever enough for that transform to be right. 19:02:33 so, we have the same problem that the value of CASE was inferred to be 3. 19:04:32 Krystof: any idea on the cause of http://paste.lisp.org/+2XWT ? 19:06:21 hm, no 19:06:49 not off the top of my head 19:07:05 (what's different on ppc type/value case derivation ?!) 19:07:46 Speaking of, I'm seeing stuff about "unable to optimize because environment argument present and not null" and "unable to~% optimize~%because:~% optimize away possible call to FDEFINITION at runtime", (SB-PCL::CACHE SB-PCL::EMF SB-PCL::MISS-FN) (SB-PCL::INVOKE-EFFECTIVE-METHOD-FUNCTION ). 19:07:56 Krystof: unsigned -> fixnum 19:08:05 Krystof: Might not be PPC, might be x86oids that are different. 19:08:26 or just plain fixnum modarith in general 19:10:09 hm, wait, is it true that on ppc there's just (unsigned 32) modular arithmetic? 19:10:42 Might be. I think there's a comment about not being able to think through the shifts required for signed modular math. 19:11:21 funny. If there was something that I was previously confident(ish) in, it was (unsigned 32) with no clever replacements anywhere 19:11:50 (same for sparc and mips) 19:13:32 As I said, I'm planning to give the whole integer arithmetic area a bit of an audit soon, for PPC and SPARC. 19:14:03 so presumably this is a lurking bug because of unsigned constant replacement? 19:14:23 OK, so I should be able to reproduce this if I build on x86 and remove other kinds of modular arithmetic 19:14:24 trying 19:18:58 -!- whoops [~whoops@2a01:4f8:161:41e1::2] has quit [Ping timeout: 246 seconds] 19:23:45 whoops [~whoops@2a01:4f8:161:41e1::2] has joined #sbcl 19:26:49 -!- stassats` [~stassats@wikipedia/stassats] has quit [Read error: Operation timed out] 19:28:39 -!- attila_lendvai1 [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 252 seconds] 19:30:33 nyef: I'm thinking of adding (sb-ext:inhibit-warnings 3) in *optimize-speed* (src/pcl/low.lisp) 19:31:49 attila_lendvai [~attila_le@92.46.2.228] has joined #sbcl 19:31:49 -!- attila_lendvai [~attila_le@92.46.2.228] has quit [Changing host] 19:31:49 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 19:31:59 pkhuong: I have pretty much NO CLUE when it comes to any of the PCL stuff... But those notes annoy me whenever I run my test suite at work. 19:35:04 _8david` [~user@port-212-202-134-139.static.qsc.de] has joined #sbcl 19:35:26 nicdev` [user@2600:3c03::f03c:91ff:fedf:4986] has joined #sbcl 19:37:50 pkhuong_ [~pkhuong@modemcable086.239-37-24.mc.videotron.ca] has joined #sbcl 19:38:13 -!- pkhuong [~pkhuong@modemcable086.239-37-24.mc.videotron.ca] has quit [Disconnected by services] 19:38:15 -!- pkhuong_ is now known as pkhuong 19:38:27 pkhuong: ok, if I removed tagged modular arithmetic from the x86 I get the same failure case 19:39:24 "new inferred type (integer 251 251) conflicts with old type (integer 922...803 922...803)" 19:40:22 actually I get that conflict [except with (integer -5 -5)] with tagged modular arithmetic too, but somehow it doesn't end up utterly confusing the whole compiler 19:42:00 calling derive-note-type from change-ref-leaf isn't a good idea 19:42:04 *node-type 19:42:44 -!- nicdev [user@2600:3c03::f03c:91ff:fedf:4986] has quit [*.net *.split] 19:42:45 -!- _8david [~user@port-212-202-134-139.static.qsc.de] has quit [*.net *.split] 19:43:21 -!- nicdev` is now known as nicdev 19:45:00 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 19:48:50 indeed, taking that away makes everything better 19:49:11 I wonder what breaks because of it 19:49:38 Krystof: http://paste.lisp.org/+2XWS/2 ? 19:50:01 -!- drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 19:50:04 I wonder how it could *not* break. 19:50:26 drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has joined #sbcl 19:51:12 Are you going to need me to do more PPC testing today, or does being able to reproduce the effect on an x86 obviate that? 19:51:48 thanks, I think the x86 is a good enough platform for this 19:52:17 pkhuong: for the modular replacement case, I agree. Most of the other uses are of sane things like replacing something of type (member :foo) with :foo 19:52:25 right. 19:53:07 pkhuong: will try your patch in a bit 19:53:18 I've put off reading these undergrad project reports for too long :-( 19:54:17 I don't understand how the old way could work (: 19:58:26 Hydan [~hydan@ip-89-103-110-5.net.upcbroadband.cz] has joined #sbcl 20:04:34 -!- Posterdati [~antani@host89-93-dynamic.19-79-r.retail.telecomitalia.it] has quit [Ping timeout: 240 seconds] 20:04:49 -!- sdemarre [~serge@91.176.221.3] has quit [Ping timeout: 248 seconds] 20:06:49 I feel like I'm in an episode of Star Trek. The PCI ROM for the video card on my PPC system is entirely full of threes. 20:06:58 Every single byte is a three. 20:14:30 -!- Hydan [~hydan@ip-89-103-110-5.net.upcbroadband.cz] has quit [Ping timeout: 264 seconds] 20:24:43 maxm [~user@openchat.com] has joined #sbcl 20:25:27 hi, I remember there was an explanation somewhere why sbcl's with-mutex and similar code uses without-interrupts/with-local-interrupts/with-interrupts-allowed stuff 20:25:57 so that control-c doesn't break it 20:26:20 something about a race, where (let (resource) (unwind-protect (blah (setq resource blah)) (when resource (free-resource resource)))) 20:26:28 and how it breaks if certain scenario happens 20:26:37 i can't find this explanation now 20:27:18 can someone refresh me to the race in doing unwinds like above? it was something about signal being delivered, and basically resource not freed in some very rare cases 20:27:21 hit an interrupt while releasing the lock. 20:27:47 but I remember reading either docstring or comment, that this kind of race is generic 20:27:57 unwind, but you're already in the cleanup code, so you're SOL with at best a mutex held, and at worst inconsistent state. 20:28:27 so without locking there is nothing to worry about? 20:28:30 yes, it is generic. 20:28:38 anytime you interrupt in a random place in random code 20:28:45 you will probably corrupt whatever it's working on 20:29:00 "don't do that". 20:29:04 no, it's generic: unwind while in the cleanup code, and your clean up might not be run at all (if you're lucky), or only partially. 20:29:09 if I use above for example with resource being (foreign-alloc) and unwind being /(foreign-free) pair, can it still not-free if signal is delivered in a wrong moment? 20:29:28 if unwind happens at the wrong moment. 20:29:45 I think CCL always blocks interrupts in cleanups, which has its own, different, issues. 20:29:47 what causes unwind while in cleanup, async SIGTERM? 20:30:07 most commonly, hitting control-c and then typing 0. 20:30:15 in an interactive interpreter 20:30:38 it's nice to have that not hang the interpreter by corrupting internal streams and such thigns 20:31:08 hmm, I wondering if I should be doing this for all libraries I use.. And all of them are full of such unwind-protects for resource management... ie ZMQ libs 20:31:11 probably not so incredibly useful to have it apply to all users' mutexes. 20:32:29 is there sb-ext or such macro, that does the without-interrupts/with-local-interrupts wrapping, or I have to use my own? 20:32:49 Well, in our codebase, we use an unsafe-with-mutex which doesn't even have unwind-protect, cause it's too slow. (except in a safe build, where it asserts there was no non-local unwind). That's just the opposite. :) 20:33:25 meh, unwind-protect being slow kind of sucks honestly, its like used a lot :-) 20:33:43 yes. 20:33:46 please fix it. :) 20:34:01 whats the major issue with it? 20:34:12 switch to lock-free ;) 20:34:33 *maxm* is not SBCL hacker, but I actually pretty descent with ideas (ie remember slime streams / world-lock thing? :) 20:34:41 -!- yacks [~py@180.151.36.168] has quit [Ping timeout: 248 seconds] 20:34:45 hmm 20:35:00 It allocates an unwind frame and sticks it on a stack. 20:35:26 And puts the body in a function and calls it. There's just a lot of code there. 20:35:50 the function is DX, at least (?) 20:35:53 yes 20:35:54 *maxm* thought that if declared dynamic-extent, SBCL kind of folds internal function inisde? 20:36:09 I think it still has overhead, though. 20:36:27 mutable bindings are always on stack, for one. 20:36:45 where is the actual locking, coz I went into M-. on unwind, then %unwind and %within-cleanup, I don't see no locking? 20:37:05 the locking is within the mutex macros 20:37:21 Other language implementations (not of CL afaik) have free unwind-protect by doing table-based unwind based on the current instruction pointer. 20:37:34 yea c++ right? 20:37:43 ASau` [~user@p5797FB60.dip0.t-ipconnect.de] has joined #sbcl 20:38:01 isn't there a project something with SBCL and CLANG etc? or thats wrong tree? 20:38:33 there is a thing. not so much a project. 20:38:39 it's barely a thing 20:40:19 well anyway, thanks for explaining. SBCL is actually fast enough for me, its these little things like with-interrupts/without-interrupts business, and rare races, that prevents someone writing next twitter in it 20:40:44 Note that using table-based unwind increases the cost of unwind used for flow control, which may be a poor trade-off for certain workloads. 20:41:08 -!- ASau [~user@p4FF9664F.dip0.t-ipconnect.de] has quit [Ping timeout: 252 seconds] 20:41:48 *maxm* goes back to coding.. I'm trying to quickly whip-out Tuxedo-like RPC for CL, using zmq and cl-store 20:42:09 maxm: of course, because other languages don't have the same problem. 20:43:18 -!- edgar-rft [~GOD@HSI-KBW-149-172-63-75.hsi13.kabel-badenwuerttemberg.de] has quit [Quit: lifeform experiment terminated] 20:44:55 And it's time (and past time) that I signed off for the evening. 20:44:58 -!- nyef [~nyef@c-50-157-244-41.hsd1.ma.comcast.net] has quit [Quit: G'night all.] 20:46:30 I'm kinda having a hard time imagining a real piece of code for which the increased cost of a remote-destination throw would be a worse performance problem than unwind-protect. 20:54:57 -!- drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 20:55:27 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Quit: This computer has gone to sleep] 21:07:54 foom: my concern is not with speed here but with robustness 21:08:59 right now there is no plans to, but I want by resource allocation/deallocation to be tight-proof, in a big program, where other unrelated things can go on, ie profiling, someone doing SIGALM, calls to some other libraries that start their own threads and such 21:09:32 those should be fine as they don't generally unwind from interrupts. 21:10:03 Doing an unwind from an async interrupt is a terrible idea, you should never do that in a production system. 21:10:21 E.g. don't send SIGALRM and then unwind from it. Terrible plan. 21:11:11 what about just regular signals that are handled? Like periodically zmq waiting fuction receive EINTR, I think just from SBCL internals doing their things 21:11:28 ie I start a thread, it just sits there tight in zmq_recv 21:11:51 i continue to work from REPL, bam -> eintr, (i think GC probably) 21:12:38 that's not an unwind. 21:14:01 so cleanup form called without non-local exit from deeper inside, is not considered an unwind? 21:14:43 so only danger is someone trying to kill thread when its in it cleanup form 21:15:55 *maxm* is concerned about this, because ZMQ req/resp sockets are tricky, and send/recv have to be paired, if it somehow misses one recv, whole socket is hang, and needs to be re-created.. So i'm trying to think of unual scenarios 21:17:20 but anyway, I'll just use without-interrupts trick. Its fine to run cleanup with them disabled, coz cleanups are mostly freeing the memory 21:23:56 -!- milanj [~milanj@82.117.199.26] has quit [Ping timeout: 240 seconds] 21:26:48 -!- ASau` is now known as ASau 21:35:49 -!- prxq [~mommer@mnhm-4d012407.pool.mediaWays.net] has quit [Quit: Leaving] 21:38:20 Strigoides [~owen@114-134-0-113.lightwire.co.nz] has joined #sbcl 21:39:25 -!- foreignFunction [~niksaak@ip-4761.sunline.net.ua] has quit [Quit: Leaving.] 21:42:47 davazp [~user@92.251.175.178.threembb.ie] has joined #sbcl 21:47:39 milanj [~milanj@cable-94-189-145-213.dynamic.sbb.rs] has joined #sbcl 21:53:29 -!- Bike [~Glossina@71-214-84-201.ptld.qwest.net] has quit [Ping timeout: 256 seconds] 21:54:56 Bike [~Glossina@67-5-223-95.ptld.qwest.net] has joined #sbcl 21:56:03 -!- treerex [~tree@c-24-34-53-59.hsd1.ma.comcast.net] has quit [Quit: Leaving.] 22:24:22 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Ping timeout: 252 seconds] 22:38:20 edgar-rft [~GOD@HSI-KBW-149-172-63-75.hsi13.kabel-badenwuerttemberg.de] has joined #sbcl 23:14:39 drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has joined #sbcl 23:21:10 -!- segv- [~mb@95-91-241-68-dynip.superkabel.de] has quit [Remote host closed the connection] 23:44:40 -!- slyrus [~chatzilla@173-228-44-92.dsl.static.sonic.net] has quit [Ping timeout: 252 seconds] 23:54:58 -!- drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has quit [Remote host closed the connection]