00:00:02 -!- nyef [~nyef@ip-64-134-155-138.public.wayport.net] has quit [Quit: G'night all.] 00:23:57 Phoodus [~foo@ip72-223-116-248.ph.ph.cox.net] has joined #sbcl 02:40:15 -!- Phoodus [~foo@ip72-223-116-248.ph.ph.cox.net] has quit [Ping timeout: 252 seconds] 04:10:53 Phoodus [~foo@ip72-223-32-241.ph.ph.cox.net] has joined #sbcl 04:14:36 -!- Phoodus [~foo@ip72-223-32-241.ph.ph.cox.net] has quit [Read error: Connection reset by peer] 04:40:14 -!- homie [~levgue@xdsl-78-35-138-106.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 05:08:45 -!- pchrist [~spirit@gentoo/developer/pchrist] has quit [Ping timeout: 260 seconds] 05:09:17 pchrist [~spirit@gentoo/developer/pchrist] has joined #sbcl 05:11:21 -!- angavrilov [~angavrilo@217.71.227.181] has quit [Ping timeout: 260 seconds] 05:11:26 angavrilov [~angavrilo@217.71.227.181] has joined #sbcl 05:32:10 -!- angavrilov [~angavrilo@217.71.227.181] has quit [Ping timeout: 244 seconds] 05:37:07 angavrilov [~angavrilo@217.71.227.181] has joined #sbcl 06:09:39 Phoodus [~foo@68.107.217.139] has joined #sbcl 06:38:48 -!- les [les@unaffiliated/les] has quit [Quit: leaving] 07:05:22 sdemarre [~serge@91.176.11.83] has joined #sbcl 07:24:30 Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has joined #sbcl 07:26:19 good morning everyone 08:25:54 -!- lichtblau [~user@91-65-217-112-dynip.superkabel.de] has quit [Ping timeout: 255 seconds] 08:51:28 prxq [~mommer@mnhm-5f75f2f8.pool.mediaWays.net] has joined #sbcl 09:37:05 -!- Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has quit [Remote host closed the connection] 09:37:37 Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has joined #sbcl 10:22:00 akovalen` [~anton@95.73.127.155] has joined #sbcl 10:23:43 -!- akovalenko [~anton@95.73.216.150] has quit [Ping timeout: 248 seconds] 10:29:25 -!- akovalen` is now known as akovalenko 11:12:28 -!- antoszka [~antoszka@unaffiliated/antoszka] has quit [Quit: +++ killed by SIGSEGV +++] 11:20:52 antoszka [~antoszka@unaffiliated/antoszka] has joined #sbcl 11:59:06 -!- prxq [~mommer@mnhm-5f75f2f8.pool.mediaWays.net] has quit [Quit: Leaving] 12:16:10 -!- angavrilov [~angavrilo@217.71.227.181] has quit [Ping timeout: 258 seconds] 12:18:20 angavrilov [~angavrilo@217.71.227.181] has joined #sbcl 12:49:47 -!- christoph_debian [~user@oteiza.siccegge.de] has quit [Ping timeout: 244 seconds] 13:39:35 -!- redline6561_nop is now known as redline6561 13:40:55 nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has joined #sbcl 13:49:24 Does anybody here know how to build a 32-bit SBCL on 64-bit OSX? 14:16:36 setting SBCL_ARCH isn't sufficient? 14:16:54 Looks like it is, which is a surprise given that it isn't on linux. 14:17:31 I'm trying a build on a clean tree now, since I'm getting a fault during cold-init. 14:20:48 I just successfully completed a build, but it was with a tree from Sep 2 14:22:34 I'm getting "Floating point exception: 8" during make-target-2. 14:23:37 Version is 1.0.52.24.master.1-7d49722. 14:23:52 I had cd470a05b55209cf32072274b7e096dcd6077097, I'll pull and try again 14:24:12 Which is HEAD~3 right now. 14:26:34 *nyef* tries with straight 1.0.52. 14:30:49 I suppose it could also be something stupid in the way of cross-compiling an x86 build from an x86-64 host. 14:30:56 Hrm. 1.0.52 bombed in the same way. 14:31:12 Trying 1.0.50. 14:31:23 I just built 1.0.52.27-987e39e 14:31:47 and MACHINE-TYPE does return "X86" 14:31:54 This is going to turn out to be something stupid and leonine, isn't it? 14:32:20 I'm running 10.7.2. You? 14:32:26 I'm running 10.6 and xcode 3 14:32:36 Mmm. 10.7.2 and xcode 4.1 here. 14:34:38 1.0.52.28 shouldn't affect x86 builds, but should affect x86-64 builds. 14:35:42 Bwah? 14:36:01 "1.0.52.24.tags/sbcl-1.0.50^0.0-da8bc5f" ?!? 14:37:24 I think I need to open a couple bugs... 14:38:55 Would you mind building 1.0.52.28-f60e993 for x86-64 on your system and running float.pure.lisp? 14:39:05 I'd hate to find that it only works on Lion. 14:40:12 homie [~levgue@xdsl-78-35-129-90.netcologne.de] has joined #sbcl 14:42:55 sure 14:46:59 Should just be an expected-failure for the range reduction, no unexpected success, no unexpected failures. 14:48:36 angavrilov_ [~angavrilo@217.71.227.181] has joined #sbcl 14:49:01 -!- angavrilov [~angavrilo@217.71.227.181] has quit [Ping timeout: 240 seconds] 14:51:53 *nyef* tries a build with :sb-show. 14:52:08 just the one expected failure 14:52:22 Wonderful. 14:52:25 Thank you. 14:53:01 That makes one darwin target with only one failure in that file. 14:53:45 (As opposed to three failures before .52.28, and four failures after.) 14:56:39 Hrm. Dies after entering !COLD-INIT, but before entering !EVAL-COLD-INIT. 15:05:20 Dies in that block of setfs, the only remotely complicated one is to set *GC-EPOCH* to (CONS NIL NIL), and that's the only one that isn't just a straight set-to-constant-value. 15:25:52 lichtblau [~user@91-65-217-112-dynip.superkabel.de] has joined #sbcl 15:33:11 Is anybody able to build git-head mainline SBCL on Windows, and try (room) in a fresh, warm SBCL? (build fails with my hairy cross-compilation environment, and it'll take time to set up a normal one). In my fork, I started getting failed AVER in (ROOM), except (ROOM NIL), right after nyef's disentwingling of fixnum-tag-stuff (32-bit only affected)... 15:35:26 Hrm. I have no windows machine, and I'm currently utterly failing to build a 32-bit SBCL on OSX. 15:36:10 heh. Isn't it perchance writing value 0 to address 0, eip somewhere in heap on cold init? 15:36:40 ^ that's what I got when trying to build current mainline head for Windows x86 15:36:44 Floating point exception trying to set *AFTER-GC-HOOKS*. 15:37:11 Known to work on OSX 10.6 with xcode 3, but I have 10.7 and xcode 4. 15:38:00 The actual mechanism for getting a floating-point exception for what should be, at worst, a write barrier hit escapes me. 15:38:52 nyef: that might be a delayed exception from something happened long ago (if there's a WAITing fpu insn) 15:39:21 This early in cold-init, though? 15:40:22 The VOP sequence thus far is XEP-ALLOCATE-FRAME, NOTE-ENVIRONMENT-START, PRINT, SET, . 15:40:23 well, if initial set-floating-point-modes happen before that point.. 15:41:03 The print happens, a print inserted just after the set doesn't happen, I think I know where it's dying. 15:41:11 At least in the context of !cold-init. 15:41:11 btw, /show may have a Heisenbergian effect here 15:41:26 Repeated /SHOW should have highlighted it, though. 15:41:57 And it's reliably giving the same symptoms without :sb-show, although there's obviously less information about why. 15:42:12 (Or where, for that matter.) 15:58:36 Does anyone actually understand what's going on with x86-darwin-os.c? Because it's operating in a very unfamiliar domain for me. 16:10:26 -!- akovalenko [~anton@95.73.127.155] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 16:10:43 -!- Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has quit [Quit: cya] 16:13:38 akovalenko [~anton@95.73.127.155] has joined #sbcl 16:18:05 antgreen [~user@bas3-toronto06-2925098489.dsl.bell.ca] has joined #sbcl 16:20:23 Qworkescence [~quad@71-212-169-133.hlrn.qwest.net] has joined #sbcl 16:20:25 -!- Qworkescence [~quad@71-212-169-133.hlrn.qwest.net] has quit [Changing host] 16:20:25 Qworkescence [~quad@unaffiliated/quadrescence] has joined #sbcl 16:28:53 -!- Qworkescence [~quad@unaffiliated/quadrescence] has quit [Quit: Leaving] 16:31:28 -!- angavrilov_ [~angavrilo@217.71.227.181] has quit [Ping timeout: 258 seconds] 16:41:52 angavrilov_ [~angavrilo@217.71.227.181] has joined #sbcl 16:43:44 Qworkescence [~quad@unaffiliated/quadrescence] has joined #sbcl 16:45:37 ... lovely. signal_emulation_wrapper is broken. 16:46:25 And it's in my critical path. 16:50:05 What's the lowest version of gcc that we have to support on darwin? 16:56:43 Okay, vast improvement, doing first GC, "Memory fault at: 0x0, PC: 0x5ba9". 17:01:57 nyef, What are you working on? 17:02:32 Trying to get a 32-bit SBCL to build and run on my MBP. 17:03:04 nyef: I was hoping that you'll find&fix some 32-bit gc-related problem manifesting itself in my (room) failures. I've almost abandoned that hope when you mentioned signal_emulation_wrapper, but now it's alive again :) 17:04:00 If I can get a 32-bit build that expresses the problem, I'll consider looking into it. 17:04:19 Meanwhile, my 32-bit builds are expressing different problems. 17:04:28 nyef: while we're at it -- 32-bit SBCL/linux/x86 builds and runs fine (and no map-allocated-objects problem there...) 17:05:02 nyef, I was thinking about improving/updating SBCL for darwin ppc 17:05:03 Mmm. But I'm not set up to do an x86 linux build. 17:05:20 Qworkescence: Oho! I was wondering if that was even worth bothering with. 17:05:38 It's the only machine I've got at the moment. 17:05:51 And I know others who depend on it. 17:06:09 I might be able to get a working PPC OSX machine fairly easily (have to swap the drive cables over), but I've never tried to boot it in such a configuration. 17:07:30 And, hey, you can even try to make threading work on it! 17:07:57 There's a lot I need to learn about how SBCL works. I still don't understand much of it, even from a "global" POV. 17:09:05 Odd, it's choking in scrub_control_stack()... 17:09:17 nyef: does that have a memcpy/memset hidden? 17:09:33 I have no idea? 17:12:02 Okay, time to see if the corresponding x86-64 change broke anything, then go back to dealing with the x86 damage. 17:14:44 ... Bwah? WTF is going on in scrub_control_stack()? 17:25:48 seriously, I don't know. 17:26:52 the byte-at-a-time pointer arithmetic is very strange. 17:32:47 Heh. Just looking at the test results for an x86-64 build and wondering why the bug-372 tests for float.pure were giving expected failures, before remembering that this tree is about a commit behind HEAD. 17:33:52 tsuru [~charlie@adsl-74-179-28-14.bna.bellsouth.net] has joined #sbcl 17:51:43 -!- Qworkescence [~quad@unaffiliated/quadrescence] has quit [Quit: Leaving] 17:54:39 How do I write the NEWS entry for this? 17:55:17 My current attempt is: bug fix: x86oid darwin "signal-handling" emulations no longer grant the C compiler freedom to produce incorrect code for their assembly fragments. 17:59:23 Qworkescence [~quad@unaffiliated/quadrescence] has joined #sbcl 18:01:44 What... the... fuck?!? Please, please tell me that scrub_control_stack() isn't relying on sp being the "last" variable in the frame. Please. 18:01:52 *nyef* whimpers. 18:01:58 nyef: it is :( 18:02:45 But... but... no... Just... no... 18:06:47 nyef: if we are targetting C99, zeroing out variable-length array of size-to-scrub bytes would be how I'd write it.. 18:07:25 * _volatile_ VLA, so it won't be optimized out 18:08:07 I might go so far as to call another function or use inline assembly to find a usable starting point. 18:08:33 At the same time, this only matters for LISP_FEATURE_C_STACK_IS_CONTROL_STACK systems. 18:08:58 I don't believe that there are three such backends. 18:11:19 akovalenko: if we are targetting real compilers, not using VLA is what I'd do (: 18:11:33 ok, things have probably gotten much better since 4.0 18:11:41 real vs. imaginary vs. complex compilers :) 18:13:45 fast_bzero* stuff is good to use here, as the compiler doesn't know anything about it, and can't optimize/reorder it, unlike memset.. 18:14:26 Sure, except that you need to pick a usable starting point from whence to zero. 18:15:01 inline-assemly load from %esp? 18:15:15 The only positive here is that stack scavenging is conservative under these scenarios, so it doesn't actually matter too-too much if we miss a few words. 18:15:26 I'm considering it. 18:16:01 (To the point of having checked the GCC info documentation for a constraint meaning the stack pointer, to save having separate fragments for x86-64 and x86.) 18:16:11 on X86, void* get_esp(int dummy) {return &dummy; } is a good approximation :) 18:16:27 Yes, that's another one I was considering. 18:17:20 if we're okwith pure GCCism, there are extensions to get FP 18:17:34 yep, __builtin_frame_address 18:18:28 We're okay with pure GCCism elsewhere. 18:19:13 I wouldn't mutate random stuff after esp from a C function, because on x86-64, the compiler can write above esp within a function. 18:19:14 Those poor MSVC users can fend for themselves. d-: 18:19:25 foom: only a couple hundred bytes. 18:19:30 256, iirc 18:19:42 Oh, right. The red zone. Joy. 18:20:01 if you just do it in asm, you should be all set.. 18:21:16 there is -mno-red-zone gcc option, btw 18:21:19 Wait, wait... I just need this to run with one combination of CPU, OS, and compiler. I should just change the 1 to a 4, so as to have a reasonable chance at missing all of the variables. 18:22:39 I haven't read the whole conversation to get context, but an asm function to zero out memory starting with esp sounds like an easy and reliable solution to me. 18:23:04 Sure, probably would be, and only needs to be done for x86 and x86-64, as everything else can just use the C function. 18:24:22 -!- rpg [~rpg@216.243.156.16.real-time.com] has quit [Ping timeout: 258 seconds] 18:24:47 Yup. Bumping the offset to 4 gets me past the first GC. 18:27:10 Okay, back to my commit message for the bogus assembly fragments. 18:27:20 My current attempt is: bug fix: x86oid darwin "signal-handling" emulations no longer grant the C compiler freedom to produce incorrect code for their assembly fragments. 18:27:28 Err... NEWS entry, sorry. 18:27:38 Any ideas for better wording? 18:28:04 Repair crash in x86oid darwin signal handling emulation on certain compilers. 18:28:50 A lot better, thank you. 18:29:12 s/on/compiled with/? 18:29:27 sure. 18:38:41 repair compiler-dependent crash (: 18:40:07 And now to try and repeat current HEAD for x86... 18:51:07 rpg [~rpg@63-229-199-194.mpls.qwest.net] has joined #sbcl 18:55:09 -!- tsuru [~charlie@adsl-74-179-28-14.bna.bellsouth.net] has quit [Read error: Connection reset by peer] 18:56:22 tsuru [~charlie@adsl-74-179-19-221.bna.bellsouth.net] has joined #sbcl 19:17:52 prxq [~mommer@mnhm-5f75f2f8.pool.mediaWays.net] has joined #sbcl 19:18:47 -!- antgreen [~user@bas3-toronto06-2925098489.dsl.bell.ca] has quit [Remote host closed the connection] 19:20:41 antgreen [~user@bas3-toronto06-2925098489.dsl.bell.ca] has joined #sbcl 19:21:14 -!- homie [~levgue@xdsl-78-35-129-90.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 19:24:39 rpg_ [~rpg@63-229-199-194.mpls.qwest.net] has joined #sbcl 19:25:45 -!- rpg_ [~rpg@63-229-199-194.mpls.qwest.net] has quit [Client Quit] 19:28:13 -!- rpg [~rpg@63-229-199-194.mpls.qwest.net] has quit [Ping timeout: 240 seconds] 19:31:59 Okay, I think I'm done for now. I'll leave the scrub_control_stack() thing for later or for someone else. 19:40:36 nyef: now I understand why it survived for so long in its present state :) 19:40:52 Heh. 19:41:20 Well, this is the first report of trouble with it, right? 19:41:33 And the brain-damage has survived the addition of guard pages. 19:42:56 -!- lichtblau [~user@91-65-217-112-dynip.superkabel.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 19:43:13 And, oddly enough, I have actual paying work to do. 19:43:19 *akovalenko* had to start mswinmt-stable branch for public builds because of longer-fixnum (map-allocated-objects) mess. I should have done it before... 19:43:55 It really breaks on 32-bit builds in that tree? 19:44:37 yep (that's why I asked about mainline windows build -- not sure if it's platform specific) 19:44:57 Bisect? 19:45:04 It really shouldn't have broken. 19:45:17 And I should have thought to ask for a bisect ages ago. 19:46:00 I've already narrowed the scope to longer-fixnum changes, going to try further.. 19:47:11 There are only two patches in that series that directly touch room.lisp. 19:47:15 that's not easy to bisect when some conflicts were involved.. 19:50:54 ...somehow, map-allocated-objects ends up using some data as object headers (not random garbage, though, but not lisp objects either...) 19:50:57 There's something bugging me about ROOM, the dynamic space free pointer, and threads. 19:51:33 well, if dynamic-space-free-pointer can't go back, we are safe with without-gc 19:51:38 *without-gcing 19:53:29 Krystof [~user@81.174.155.115] has joined #sbcl 19:54:12 I think it might have been that I had to keep reg_ALLOC loaded with some global dynamic space free pointer purely to keep ROOM happy. 19:59:47 christoph_debian [~user@oteiza.siccegge.de] has joined #sbcl 20:36:37 nyef: *-space-free-pointer* are retrivied in lisp and shifted by n-fixnum-tag-bits, is that right? (- n-word-bits n-fixnum-tag-bits) seems more appropriate, unless the whole semantics of those pointers has changed... 20:40:22 Well, they're unboxed, aligned pointers, being stashed in symbol value slots. 20:40:34 tsuru` [~charlie@adsl-74-179-19-82.bna.bellsouth.net] has joined #sbcl 20:40:50 They used to be multiplied by some constant related to the number of bytes in a word. 20:41:26 nyef: when they're accessed in Lisp, we see them as fixnums, and in that stage they're already shifted by n-fixnum-tag-bits, n'est-ce pas? 20:41:51 ... Yes. I'm about to feel a little stupid, aren't I? 20:41:57 *akovalenko* too. 20:42:00 -!- tsuru [~charlie@adsl-74-179-19-221.bna.bellsouth.net] has quit [Ping timeout: 240 seconds] 20:42:27 so we need to "unshift" them by n-fixnum-tag-bits and then shift by n-word-bits.. 20:42:41 *by word-shift 20:42:46 Umm... 20:43:03 The old value was to scale by n-word-bytes. 20:43:14 Which is, what, four? 20:43:30 The new value is to shift by n-fixnum-tag-bits. 20:43:33 four on 32-bit 20:43:41 Which is two on 32-bit. 20:44:06 that is, on 32-bit platform no shift should really happen 20:44:17 Approximately, yes. 20:44:57 It'll be shifted one way to compensate for the unboxing, and then the other to "unbox". 20:45:03 At which point you have a byte pointer. 20:47:01 This is one of those stupid, twisty, why the heck did you have to stash these in boxed storage things. 20:47:23 space-bounds is not inline, so I was able to test (room) thing right now and see that it works :) 20:48:10 -!- prxq [~mommer@mnhm-5f75f2f8.pool.mediaWays.net] has quit [Quit: Leaving] 20:48:42 If n-word-bytes is 4, and n-fixnum-tag-bits is 2, how is (* X n-word-bytes) not the same as (ash X n-fixnum-tag-bits)? 20:50:34 hmm 20:51:44 seems that it shouldn't be the problem.. 20:52:47 You might double-check the changes to alloc.lisp. I'm not able to reconstruct the proof-of-correctness for that anywhere near as easily. 20:53:14 The other possibility that comes to mind is TLS-area access. 20:53:44 Remember that the meaning of the TLS index values changed fairly early in the patch series. 21:00:20 nyef: (defun fixnumize (num).. (ash num (1- n-lowtag-bits))) ;; is "fixnumize" a misnomer now? 21:00:41 akovalenko: Yes. At best. 21:00:42 well, shouldn't matter for 32-bit platform.. 21:00:51 True, but where is this? 21:01:04 src/compiler/generic/utils.lisp 21:01:07 rpg [~rpg@216.243.156.16.real-time.com] has joined #sbcl 21:03:27 It's n-fixnum-tag-bits here. 21:03:52 ah, sorry... mixed branches :( 21:51:43 nyef: rolling back 2d73332bb8d137917888f7d588a786bbf20f44b9 "Fixnum and unsigned-fixnum array cleanups" apparently fixes the ROOM 21:52:39 Hrm... 21:53:10 Starts with dd04bd44 here. 21:53:20 Must be your merged version? 21:53:33 nyef: sorry, dd04bd449535e9016b5652a708a3cac2ca24c87d 21:53:45 that one above was the ID of my rollback 21:53:57 Oh, for the... 21:54:06 Hang on. 21:54:27 Damnit, this is broken for both 32-bit and 64-bit.. 21:54:48 this one was my first suspect, btw -- and I think I studied it with enough concentration, but... 21:54:59 ... you don't see it? 21:55:39 I didn't, at least yesterday :) 21:56:00 -!- sdemarre [~serge@91.176.11.83] has quit [Ping timeout: 240 seconds] 21:56:21 Well, I see it now. 21:56:40 Change the constants next to the two fixnum array tags to #.sb!vm:word-shift. 21:58:10 here? (simple-array-unsigned-fixnum-widetag . 3) ;; + there 21:58:12 I love the fixme-comment at the top, too. 21:58:27 Yeah, change the 3 to #.sb!vm:word-shift. 21:58:52 And do the same with the 2 for the not-unsigned fixnum widetag. 21:59:08 btw, would it build from detached HEAD now? 21:59:23 Hmm? Why wouldn't it? 22:00:02 You'll probably get some crazy version string, but that's fine. 22:00:09 Make it work with detached heads and historical builds. commit 1ae15ca163c85f5bce5fdfca5fa73af39ee7ffaa Date: Wed Aug 10 13:36:36 2011 +0300 22:00:50 Neat. But ISTR this commit being from October, so you should be good. 22:03:43 monkey-patching is one more reason to love Lisp :) 22:05:03 You don't have to tell me. I went so far in production code to grab SBCL FDEFINITION objects instead of FUNCTION objects to build a dispatch table, just so I could redefine the functions easily and still pretend to have efficient code. 22:08:39 (The idea of having to do a full globaldb lookup when trying to dispatch a web request just seemed wrong.) 22:10:05 https://github.com/akovalenko/sbcl-win32-threads/commit/a25c2c49c9060519a4fcfb88c8622ae62f067642 22:10:33 Yup, that's the change. 22:10:44 Most of the way through typing up my own commit message now. 22:10:51 Does it work? 22:10:54 yep 22:11:38 okay, I think our changes are identical (character-to-character), so there's no conflict :) 22:12:24 Oops. I really should have built that before pushing. 22:15:36 well, we didn't miss ! in sb!vm [the #1 easy way to break a build] 22:15:43 Heh. 22:16:19 The other easy way is to put ! in sb-vm during target-2. 22:16:22 I'm spinning an x86/linux build right now. 22:16:57 I'm building x86-64/linux, myself. 22:17:40 Will anyone mind if I just don't do anything for the November release cycle? 22:18:11 do you mean "will everyone be happy" ? 22:18:35 I more mean "will anyone else commit something featureful"? 22:18:36 it was fun to hunt it down, after all 22:18:37 did the win32 fd handler thing in run-program go in? 22:19:02 I don't have time for anything except maintenance. 22:19:12 pkhuong: removing variable reference? David have done this, iirc 22:19:30 k. 22:19:36 I've basically comitted everything I had ready to commit, and then some. 22:20:15 it builds and room.test.sh passes. 22:21:28 Same here. 22:21:34 Running the full test suite, just in case. 22:21:37 same (: 22:28:43 Three expected failures, seven skips. 22:28:57 yup. Crisis averted (; 22:29:43 Today I am grateful for... code changes that really ARE too simple to go wrong. 22:31:53 And some version running on darwin gives three expected failures, four broken, and 38 skips. 22:34:01 Is darwin SIGTRAP delivery reliable these days, or at least reliable for the single-step flag? 22:34:09 -!- rpg [~rpg@216.243.156.16.real-time.com] has quit [Quit: rpg] 22:38:36 -!- redline6561 is now known as redline6561_nop 22:51:34 Okay, time I got going. 22:51:37 -!- nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has quit [Quit: G'night all.] 22:56:33 -!- redline6561_nop is now known as redline6561 23:31:07 -!- Qworkescence [~quad@unaffiliated/quadrescence] has quit [Quit: Leaving]