00:03:14 yena [~yena@cpe-72-177-30-155.austin.res.rr.com] has joined #sbcl 01:26:30 -!- huangjs [~huangjs@69.84.244.131] has quit [Remote host closed the connection] 03:22:33 slyrus [~chatzilla@adsl-108-81-169-220.dsl.pltn13.sbcglobal.net] has joined #sbcl 03:26:53 -!- Fare [~fare@FLH1Acq098.kyt.mesh.ad.jp] has quit [Ping timeout: 255 seconds] 03:34:34 Fare [~fare@FLH1Acq098.kyt.mesh.ad.jp] has joined #sbcl 03:34:36 -!- wbooze [~wbooze@xdsl-87-79-194-188.netcologne.de] has quit [Ping timeout: 240 seconds] 03:40:15 -!- slyrus [~chatzilla@adsl-108-81-169-220.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 276 seconds] 03:40:48 rpg [~rpg@216.243.156.16.real-time.com] has joined #sbcl 03:47:36 -!- Fare [~fare@FLH1Acq098.kyt.mesh.ad.jp] has quit [Ping timeout: 240 seconds] 04:34:39 -!- easye [~user@213.33.70.157] has quit [Read error: Operation timed out] 04:58:59 -!- rpg [~rpg@216.243.156.16.real-time.com] has quit [Quit: rpg] 05:32:58 easye [~user@213.33.70.157] has joined #sbcl 05:42:52 prxq [~mommer@mnhm-590c16c6.pool.mediaWays.net] has joined #sbcl 06:14:12 angavrilov [~angavrilo@217.71.227.190] has joined #sbcl 11:39:13 attila_lendvai [~attila_le@37.99.50.112] has joined #sbcl 11:39:14 -!- attila_lendvai [~attila_le@37.99.50.112] has quit [Changing host] 11:39:14 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 11:53:19 Fare [~fare@FLH1Acq098.kyt.mesh.ad.jp] has joined #sbcl 11:55:00 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 12:33:32 -!- scymtym [~user@2001:638:504:2093:226:b9ff:fe7d:3e1f] has quit [Ping timeout: 260 seconds] 12:37:15 scymtym [~user@2001:638:504:2093:226:b9ff:fe7d:3e1f] has joined #sbcl 12:40:39 gko [~user@114-34-168-13.HINET-IP.hinet.net] has joined #sbcl 13:04:37 loke [~elias@bb115-66-85-121.singnet.com.sg] has joined #sbcl 14:00:19 -!- gko [~user@114-34-168-13.HINET-IP.hinet.net] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 14:12:40 wbooze [~wbooze@xdsl-78-35-136-73.netcologne.de] has joined #sbcl 14:20:45 -!- Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has quit [Quit: trivial-irc-0.0.3] 14:21:42 -!- hlavaty [~user@91-65-217-229-dynip.superkabel.de] has quit [Remote host closed the connection] 14:39:36 nyef [~nyef@c-76-119-183-159.hsd1.ma.comcast.net] has joined #sbcl 14:53:31 nyef: you're the go-to windows guy, right? 14:54:07 Can _you_ reproduce the problems reported by Anton V. and Elliott? Namedly, that on Windows (ql:quickload :cl-interpol) runs into an access violation? That's with SBCL git or with Elliott's .msi. 14:54:52 Everyone (including me) is blaming me for the bug, but I don't even know whether it's actually a regression, or how to reproduce it. 15:07:45 I actually don't have a windows machine anymore. 15:08:12 Had to borrow someone else's to "root" my ARM system, actually. 15:10:06 I know that drewc keeps a windows VM or two kicking around, but he's not due to wake up for about an hour yet. 15:10:24 Do you know what windows versions and CPU types are involved? 15:11:58 Reported to happen on Windows 7 64 bit. I'm running 7 32 bit, 7 64 bit, Server 2012. Not happening for me. 15:12:09 Tried with my own build; tried with Elliotts binary. 15:12:47 And Anton mentioned non-deterministic behaviour. I don't see why an ASDF build should, after cleaning fasls, be particularly non-deterministic. 15:13:04 ... bad RAM? That's a bit of a stretch, though... 15:13:34 i had a computer home which was running windows (xp) quite fine with a faulty RAM module 15:13:45 so it was not easy to notice that there was a problem 15:14:14 so i'd not call it a big stretch 15:14:29 Oh, that reminds me. I think I may have found a bug on most/all of the cheneygc-using backends that can store unboxed garbage to the control stack. 15:14:44 "Dear Anton, we've analyzed the situation, and came to the conclusion that you have bad RAM, and Elliott has bad RAM in the exact same way, and all the other dozens of builds you are running with other Lisps and other libraries just happen to be completely unaffected. HAND HTH" 15:17:02 So, bad RAM is a stretch... How about something similar to the ALLOCATION-INFORMATION problem involving struct bitfield endianness? 15:17:16 (For which there is a rather obvious fix, btw.) 15:18:59 I'm thinking that if it's the C compiler, then his .exe should fail for me, which it doesn't. 15:19:27 Oh, an obvious fix? Let's implement that! 15:20:20 Pack and unpack the bitfields "manually". That is, just have byte-wide or word-wide fields and mask and insert anything smaller. 15:20:58 The other "obvious" fix is to add something to tools-for-build to determine which way around the fields are and use it to control either SB-ALIEN's bitfield handling or the field layout in the runtime. 15:21:19 why would windows have wrong endianness? 15:21:30 On a bitfield? 15:21:39 yes 15:22:06 It's left unspecified what the order is for packing the bits in a bitfield, IIRC, and some windows compilers do it in a different order than others. 15:22:27 Really? I'd find that quite unlikely. 15:22:30 hmm, the test output in the lp entry looks like alignment, not order to me. 15:22:52 If you add padding to the order...? 15:22:54 the bitfield packing order is specified by the ABI, although true, not by C. 15:23:11 it's a bit field in a struct, so it didn't seem obvious to me that it's not the struct layout itself that we're reading wrong. 15:23:43 The other thing is that we can grovel for word-wide fields if necessary. 15:24:55 I just didn't have such a problematic MinGW at the time, but now that I've got another Windows running, I may be lucky and can perhaps reproduce that alignment/packing/whatever problem. The solution ought to be easy once the problem materializes at all. 15:48:35 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 16:09:01 pnpuff [~aeiou@unaffiliated/pnpuff] has joined #sbcl 16:21:48 -!- Fare [~fare@FLH1Acq098.kyt.mesh.ad.jp] has quit [Quit: Leaving] 16:38:02 stassats [~stassats@wikipedia/stassats] has joined #sbcl 16:51:18 pnpuff` [~aeiou@unaffiliated/pnpuff] has joined #sbcl 16:52:42 -!- pnpuff` [~aeiou@unaffiliated/pnpuff] has left #sbcl 16:53:33 -!- pnpuff [~aeiou@unaffiliated/pnpuff] has quit [Disconnected by services] 16:54:02 pnpuff [~aeiou@unaffiliated/pnpuff] has joined #sbcl 17:22:09 Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has joined #sbcl 17:32:36 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 248 seconds] 18:21:49 slyrus [~chatzilla@173-228-44-92.dsl.static.sonic.net] has joined #sbcl 18:46:21 -!- pnpuff [~aeiou@unaffiliated/pnpuff] has quit [Quit: Bye.] 19:51:54 -!- wbooze [~wbooze@xdsl-78-35-136-73.netcologne.de] has quit [Ping timeout: 240 seconds] 20:18:03 tcr1 [~tcr@84-72-21-32.dclient.hispeed.ch] has joined #sbcl 20:38:07 -!- psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has quit [Quit: Leaving.] 20:38:30 Anyone here familiar with the code-paths surrounding the use of internal error breaks in the runtime? 20:39:18 Or do I get to work out why I'm getting a badly corrupt internal error report and what to do about it from first principles? 20:53:33 ... Turned out to be an off-by-one error in my arch code, followed by an off-by-a-factor-of-two error in my assembly code. 20:54:00 The crash is a bit weird, though. 21:01:54 -!- tcr1 [~tcr@84-72-21-32.dclient.hispeed.ch] has quit [Quit: Leaving.] 21:02:28 Ah. I know why the crash is weird. Another off-by-one error. 21:06:27 -!- prxq [~mommer@mnhm-590c16c6.pool.mediaWays.net] has quit [Quit: Leaving] 21:41:57 -!- angavrilov [~angavrilo@217.71.227.190] has quit [Ping timeout: 272 seconds] 22:15:23 -!- nyef [~nyef@c-76-119-183-159.hsd1.ma.comcast.net] has quit [Quit: G'night all.] 22:27:07 psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has joined #sbcl 23:03:04 -!- slyrus [~chatzilla@173-228-44-92.dsl.static.sonic.net] has quit [Ping timeout: 244 seconds] 23:08:20 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Quit: Leaving.]