00:11:33 -!- ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has quit [Ping timeout: 264 seconds] 00:22:56 -!- drmeiste_ is now known as drmeister_ 00:24:37 tcr [~tcr@95-90-245-81-dynip.superkabel.de] has joined #sbcl 00:29:02 -!- tcr [~tcr@95-90-245-81-dynip.superkabel.de] has quit [Ping timeout: 240 seconds] 00:55:29 tcr [~tcr@95-90-245-81-dynip.superkabel.de] has joined #sbcl 01:00:02 -!- tcr [~tcr@95-90-245-81-dynip.superkabel.de] has quit [Ping timeout: 256 seconds] 01:10:45 -!- edgar-rft [~GOD@HSI-KBW-46-223-73-219.hsi.kabel-badenwuerttemberg.de] has quit [Quit: lifeform experiment stopped because of unknown subject] 01:26:28 tcr [~tcr@95-90-245-81-dynip.superkabel.de] has joined #sbcl 01:31:20 -!- tcr [~tcr@95-90-245-81-dynip.superkabel.de] has quit [Ping timeout: 256 seconds] 01:38:44 ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has joined #sbcl 01:54:43 echo-area [~user@182.92.247.2] has joined #sbcl 01:57:23 tcr [~tcr@95-90-245-81-dynip.superkabel.de] has joined #sbcl 02:02:01 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 246 seconds] 02:02:04 -!- tcr [~tcr@95-90-245-81-dynip.superkabel.de] has quit [Ping timeout: 260 seconds] 02:13:09 *|3b|* wonders if there is something specific about my windows install sbcl doesn't like, since lots of other people seem to think sbcl on windows is fine 02:28:16 tcr [~tcr@95-90-245-81-dynip.superkabel.de] has joined #sbcl 02:33:22 -!- tcr [~tcr@95-90-245-81-dynip.superkabel.de] has quit [Ping timeout: 268 seconds] 02:39:09 -!- christoph_debian [~christoph@ppp-188-174-147-98.dynamic.mnet-online.de] has quit [Ping timeout: 264 seconds] 02:40:02 pranavrc [~pranavrc@122.164.132.228] has joined #sbcl 02:40:03 -!- pranavrc [~pranavrc@122.164.132.228] has quit [Changing host] 02:40:03 pranavrc [~pranavrc@unaffiliated/pranavrc] has joined #sbcl 02:43:21 -!- kludge` [~comet@unaffiliated/espiral] has quit [Ping timeout: 264 seconds] 02:49:07 kludge` [~comet@unaffiliated/espiral] has joined #sbcl 02:52:25 christoph_debian [~christoph@ppp-188-174-132-214.dynamic.mnet-online.de] has joined #sbcl 02:59:07 tcr [~tcr@95-90-245-81-dynip.superkabel.de] has joined #sbcl 03:03:26 -!- tcr [~tcr@95-90-245-81-dynip.superkabel.de] has quit [Ping timeout: 240 seconds] 03:21:53 -!- kanru [~kanru@118-163-10-190.HINET-IP.hinet.net] has quit [Remote host closed the connection] 03:30:00 tcr [~tcr@95-90-245-81-dynip.superkabel.de] has joined #sbcl 03:34:44 -!- tcr [~tcr@95-90-245-81-dynip.superkabel.de] has quit [Ping timeout: 256 seconds] 03:38:07 -!- rpg [~rpg@216.243.156.16.real-time.com] has quit [Quit: rpg] 04:01:05 tcr [~tcr@95-90-245-81-dynip.superkabel.de] has joined #sbcl 04:05:25 -!- tcr [~tcr@95-90-245-81-dynip.superkabel.de] has quit [Ping timeout: 245 seconds] 04:24:58 *|3b|* tried running tests on windows again, got an error popup or lockup 10 out of 9 times (1 run did both) 04:31:58 tcr [~tcr@95-90-245-81-dynip.superkabel.de] has joined #sbcl 04:36:30 -!- tcr [~tcr@95-90-245-81-dynip.superkabel.de] has quit [Ping timeout: 256 seconds] 04:41:10 <|3b|> is there any way to run the tests from a binary install of sbcl? 04:57:07 |3b|: what version? dto reported much better results in Win7 SP1 than vanilla, I think. 04:58:06 re tests, I think it should work, from a binary tarball. 04:59:06 <|3b|> every version i've tried within at least last few months 04:59:20 <|3b|> i think dto doesn't use threads for his code, which might affect stability 04:59:50 <|3b|> is there a tarball in addition to the .msi for windows? 05:00:27 <|3b|> msi just installs sbcl.exe, sbcl.core and contribs as far as i can see 05:02:52 tcr [~tcr@95-90-245-81-dynip.superkabel.de] has joined #sbcl 05:03:30 *|3b|* will try a build on another machine and see if that behaves any differently 05:04:57 scymtym_ [~user@ip-5-147-120-181.unitymediagroup.de] has joined #sbcl 05:04:58 you can try to copy the runtime, core and contrib over a source tree 05:08:04 <|3b|> yeah, was just trying that since this machine doesn't seem to be set up to build yet 05:08:06 -!- tcr [~tcr@95-90-245-81-dynip.superkabel.de] has quit [Ping timeout: 276 seconds] 05:08:57 -!- ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 05:09:23 <|3b|> ok, seems to be running, will see how that does 05:12:18 -!- Bike [~Glossina@wl-nat100.it.wsu.edu] has quit [Read error: Connection reset by peer] 05:12:37 Bike [~Glossina@wl-nat100.it.wsu.edu] has joined #sbcl 05:19:14 sdemarre [~serge@251.169-64-87.adsl-dyn.isp.belgacom.be] has joined #sbcl 05:20:45 <|3b|> looks like a lockup with 1.1.8 binary on the machine i was testing on previously, possibly on other machine as well 05:24:36 kanru [~kanru@118-163-10-190.HINET-IP.hinet.net] has joined #sbcl 05:29:27 pnpuff [~l@unaffiliated/pnpuff] has joined #sbcl 05:29:51 -!- pnpuff [~l@unaffiliated/pnpuff] has left #sbcl 05:31:44 <|3b|> hmm, doesn't look like i ever got around to filing a bug about that, guess i should do so... 05:32:35 angavrilov [~angavrilo@217.71.227.190] has joined #sbcl 05:33:48 tcr [~tcr@95-90-245-81-dynip.superkabel.de] has joined #sbcl 05:36:02 -!- easye [~user@213.33.70.157] has quit [Read error: No route to host] 05:38:24 -!- tcr [~tcr@95-90-245-81-dynip.superkabel.de] has quit [Ping timeout: 256 seconds] 05:46:10 *|3b|* wonders if (sleep :non-consing) is supposed to take that long to run 05:47:26 <|3b|> hmm, judging by the sleep times in it, i'd guess not 05:54:25 <|3b|> looks like maybe combination of ctu:assert-no-consing and sleep is slow? 05:54:38 <|3b|> either by itself is fast 05:55:50 -!- sdemarre [~serge@251.169-64-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 240 seconds] 05:57:18 <|3b|> ah, looks like assert-no-consing repeats 10000 times, and sleep 0.00001s0 sleeps for 0.015 seconds 05:58:36 <|3b|> and the test does that 4 times 06:04:40 tcr [~tcr@95-90-245-81-dynip.superkabel.de] has joined #sbcl 06:09:10 -!- tcr [~tcr@95-90-245-81-dynip.superkabel.de] has quit [Ping timeout: 245 seconds] 06:09:51 *|3b|* files a bug and goes back to playing the game i originally booted into windows for :p 06:12:43 <|3b|> or rather goes back to waiting for windows update to finish so i can play games :( 06:24:23 pkhuong: do you know whether anybody started to work on the "Parametric recursive types" project from your project ideas list? 06:35:34 tcr [~tcr@95-90-245-81-dynip.superkabel.de] has joined #sbcl 06:40:24 -!- tcr [~tcr@95-90-245-81-dynip.superkabel.de] has quit [Ping timeout: 276 seconds] 06:48:51 -!- drmeister_ [~drmeister@pool-71-185-168-200.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 06:58:46 easye [~user@213.33.70.157] has joined #sbcl 07:06:26 tcr [~tcr@95-90-245-81-dynip.superkabel.de] has joined #sbcl 07:11:36 -!- tcr [~tcr@95-90-245-81-dynip.superkabel.de] has quit [Ping timeout: 276 seconds] 07:11:47 tcr [~tcr@95-90-245-81-dynip.superkabel.de] has joined #sbcl 07:15:49 -!- scymtym_ [~user@ip-5-147-120-181.unitymediagroup.de] has quit [Ping timeout: 248 seconds] 07:16:58 prxq [~mommer@mnhm-590c3ca8.pool.mediaWays.net] has joined #sbcl 07:48:12 *|3b|* fails at mailing-list, i should just stick to irc :/ 08:00:39 tcr1 [~tcr@95-90-245-81-dynip.superkabel.de] has joined #sbcl 08:00:48 -!- tcr [~tcr@95-90-245-81-dynip.superkabel.de] has quit [Read error: Connection reset by peer] 08:13:42 -!- prxq [~mommer@mnhm-590c3ca8.pool.mediaWays.net] has quit [Remote host closed the connection] 08:15:50 prxq [~mommer@mnhm-590c3ca8.pool.mediaWays.net] has joined #sbcl 08:26:27 -!- kanru [~kanru@118-163-10-190.HINET-IP.hinet.net] has quit [Remote host closed the connection] 08:27:32 kanru [~kanru@118-163-10-190.HINET-IP.hinet.net] has joined #sbcl 08:32:35 -!- angavrilov [~angavrilo@217.71.227.190] has quit [Read error: Operation timed out] 09:00:31 -!- pranavrc [~pranavrc@unaffiliated/pranavrc] has quit [Quit: Ping timeout: ] 09:02:45 davazp [~user@92.251.217.50.threembb.ie] has joined #sbcl 09:12:25 -!- yacks [~py@103.6.158.105] has quit [Read error: Connection reset by peer] 09:31:49 -!- kludge` [~comet@unaffiliated/espiral] has quit [Ping timeout: 248 seconds] 09:35:57 yacks [~py@103.6.158.105] has joined #sbcl 09:37:25 kludge` [~comet@unaffiliated/espiral] has joined #sbcl 09:59:04 -!- yacks [~py@103.6.158.105] has quit [Ping timeout: 246 seconds] 10:01:04 yacks [~py@103.6.158.105] has joined #sbcl 10:01:54 scymtym: nope. 10:02:06 well, I don't know of anyone who did 10:02:25 thanks 10:02:31 i explored the topic a bit 10:03:06 if i would upload a draft soonish, could you review it? 10:03:26 sure. 10:03:31 thanks 10:03:46 It might take ~1-2 weeks. 10:04:53 well, i had the code lying around for months :) 10:05:18 -!- echo-area [~user@182.92.247.2] has quit [Remote host closed the connection] 10:06:54 edgar-rft [~GOD@HSI-KBW-46-223-73-219.hsi.kabel-badenwuerttemberg.de] has joined #sbcl 10:27:02 -!- yacks [~py@103.6.158.105] has quit [Ping timeout: 240 seconds] 10:28:01 yacks [~py@103.6.158.105] has joined #sbcl 11:10:33 stassats [~stassats@wikipedia/stassats] has joined #sbcl 11:17:30 i wish people were trying to fix windows problems instead of bickering about cats 11:32:26 I've got question. 11:32:48 Recently Robert Swindels (spelling?) posted several NetBSD patches. 11:32:55 Were they applied? 11:33:09 Are they going to be applied? 11:33:29 you can look at the git log to see whether they are applied 11:40:00 It looks like they weren't. 11:40:15 Could anyone commit? 11:40:59 not me 11:41:55 -!- davazp [~user@92.251.217.50.threembb.ie] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 11:43:17 ASau` [~user@p4FF97457.dip0.t-ipconnect.de] has joined #sbcl 11:44:15 joshe: could you? 11:46:02 davazp [~user@92.251.217.50.threembb.ie] has joined #sbcl 11:47:08 -!- ASau [~user@p4FF96920.dip0.t-ipconnect.de] has quit [Ping timeout: 268 seconds] 12:01:44 -!- yacks [~py@103.6.158.105] has quit [Ping timeout: 260 seconds] 12:23:22 yacks [~py@103.6.158.105] has joined #sbcl 12:30:47 pranavrc [~pranavrc@122.164.120.180] has joined #sbcl 12:30:48 -!- pranavrc [~pranavrc@122.164.120.180] has quit [Changing host] 12:30:48 pranavrc [~pranavrc@unaffiliated/pranavrc] has joined #sbcl 12:36:43 |3b|: sleep might be affected by windows's coarse timer granularity, I guess. 12:40:29 *stassats* got a hold of another laptop with windows 12:41:09 but setting up mingw is a pain 12:42:09 i guess people care more about windows than ppc 13:06:13 -!- davazp [~user@92.251.217.50.threembb.ie] has quit [Ping timeout: 248 seconds] 13:10:23 davazp [~user@92.251.217.50.threembb.ie] has joined #sbcl 13:11:55 segv- [~mb@95-91-243-189-dynip.superkabel.de] has joined #sbcl 13:19:04 -!- loke_ [~elias@2001:470:36:b4a:d52b:4ec8:7cfd:58d0] has quit [Read error: Connection reset by peer] 13:19:13 -!- tcr1 [~tcr@95-90-245-81-dynip.superkabel.de] has quit [Read error: Connection reset by peer] 13:19:16 tcr [~tcr@95-90-245-81-dynip.superkabel.de] has joined #sbcl 13:19:33 loke_ [~elias@2001:470:36:b4a:d52b:4ec8:7cfd:58d0] has joined #sbcl 13:32:19 -!- tcr [~tcr@95-90-245-81-dynip.superkabel.de] has quit [Ping timeout: 264 seconds] 13:33:41 tcr [~tcr@95-90-240-240-dynip.superkabel.de] has joined #sbcl 13:40:46 tcr1 [~tcr@88-134-108-101-dynip.superkabel.de] has joined #sbcl 13:41:21 teggi [~teggi@123.20.106.65] has joined #sbcl 13:41:34 <|3b|> pkhuong: yeah, assumed something like that 13:42:31 -!- tcr [~tcr@95-90-240-240-dynip.superkabel.de] has quit [Ping timeout: 259 seconds] 13:44:15 .015 seconds most definitely looks like windows's granularity. 13:45:42 xb 13:55:22 -!- tcr1 [~tcr@88-134-108-101-dynip.superkabel.de] has quit [Ping timeout: 256 seconds] 13:55:34 tcr [~tcr@88-134-110-1-dynip.superkabel.de] has joined #sbcl 13:58:07 DGASAU: I can imagine reviewing netbsd patches from swindells before freezing 13:59:51 If you need testing (NetBSD/i386, latest stable), feel free to ping me or ASau` 14:00:24 I'd prefer to have them committed, otherwise I have to maintain them myself. 14:09:50 thanks 14:10:47 I think I can find amd64 too, perhaps even checking some linux/amd64. 14:20:47 oh, I missed the end of that netbsd thread 14:22:05 it looks like you need preprocessor magic for any function call which handles a time_t directly or indirectly? 14:22:14 quite annoying 14:28:14 -!- tcr [~tcr@88-134-110-1-dynip.superkabel.de] has quit [Quit: Leaving.] 14:30:41 I will take a more detailed look at his patch later this week if someone else doesn't beat me to it 14:32:45 drmeister [~drmeister@pool-71-185-168-200.phlapa.fios.verizon.net] has joined #sbcl 14:42:51 -!- yacks [~py@103.6.158.105] has quit [Quit: Leaving] 15:12:11 -!- drmeister [~drmeister@pool-71-185-168-200.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 15:14:58 huh, can't build contribs on windows, something wrong with shell quoting 15:15:03 quite weird 15:19:25 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 15:23:45 -!- loke_ [~elias@2001:470:36:b4a:d52b:4ec8:7cfd:58d0] has quit [Ping timeout: 245 seconds] 15:37:03 loke_ [~elias@2001:470:36:b4a:11b6:6d91:ebb9:516b] has joined #sbcl 15:38:28 apparently i was using the wrong make 15:38:34 but the right make just hangs 15:38:38 this windows thing is fascinating 15:40:28 msys-git shell was the culprit, running from mingw-shell solved it 15:43:54 hahaha 15:43:58 now SBCL itself hangs after doing sb-concurrency tests 15:44:05 and people want to remove the cat messages 15:44:09 drmeister [~drmeister@pool-71-185-168-200.phlapa.fios.verizon.net] has joined #sbcl 15:44:38 oh, it's not after, it's during 15:45:03 yeah, |3b| reported a bunch of things yesterday 15:45:04 there's a 60 second timeout for each test, so, a lot of waiting 15:45:58 yes, i'm not even bothering usually to run the test-suit because of the random hangs |3b| described 15:46:31 because i can't tell whether it's a regression or just some random non-deterministic failure 15:46:33 yacks [~py@103.6.158.105] has joined #sbcl 15:47:38 -!- drmeister [~drmeister@pool-71-185-168-200.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 15:51:02 <|3b|> as far as i could tell last time i looked at it, it wasn't specific tests failing, just some general low-level problem 15:51:46 <|3b|> at least one of the common ones seemed to be failing in a call to GC after the test for example 15:52:31 debugging that could be fun 15:52:40 <|3b|> yeah, didn't have much luck when i tried 15:54:07 all tests pass here on Linux/x86_64 having enabled all of lichtblau's goodies, :sb-safepoint etc... 15:55:29 linux/x86_64 gets the most love 15:57:01 though sb-safepoint break sb-sprof 16:13:48 how so ? 16:14:29 sigprof isn't, apparently, handled properly during gc 16:14:38 lp 1133018 16:14:39 I was just about to ask when will safepoints be enabled by default 16:14:39 https://bugs.launchpad.net/bugs/1133018 16:15:27 but i still use sb-safepoint all the time and live with the occasional sprof crashes 16:15:34 because it allows to use callbacks from foreign threads 16:33:55 -!- davazp [~user@92.251.217.50.threembb.ie] has quit [Remote host closed the connection] 16:40:04 and threads.impure expectedly hangs 16:42:57 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 17:03:13 tcr [~tcr@88-134-110-1-dynip.superkabel.de] has joined #sbcl 17:08:12 -!- teggi [~teggi@123.20.106.65] has quit [Remote host closed the connection] 17:38:43 tcr1 [~tcr@88-134-110-1-dynip.superkabel.de] has joined #sbcl 17:40:40 -!- tcr [~tcr@88-134-110-1-dynip.superkabel.de] has quit [Ping timeout: 264 seconds] 17:50:57 -!- ASau` is now known as ASau 18:08:32 without threads.impure, the tests at least run to completion 18:10:58 and ROOM seems to have regressed 18:11:43 -!- pranavrc [~pranavrc@unaffiliated/pranavrc] has quit [Quit: Ping timeout: ] 18:12:53 slyrus [~chatzilla@107.200.11.156] has joined #sbcl 18:13:02 lufu [~user@5.254.134.48] has joined #sbcl 18:21:37 tcr [~tcr@88-134-110-1-dynip.superkabel.de] has joined #sbcl 18:21:37 -!- tcr1 [~tcr@88-134-110-1-dynip.superkabel.de] has quit [Read error: Connection reset by peer] 18:34:30 drmeiste_ [~drmeister@farnsworth.chem.temple.edu] has joined #sbcl 18:41:11 -!- tcr [~tcr@88-134-110-1-dynip.superkabel.de] has quit [Quit: Leaving.] 18:41:17 -!- lufu [~user@5.254.134.48] has quit [Remote host closed the connection] 18:48:04 lufu [~user@5.254.134.48] has joined #sbcl 18:51:19 Bike_ [~Glossina@wl-nat100.it.wsu.edu] has joined #sbcl 18:51:42 very weird, the number passed to map-objects-in-range is suddenly different inside it from the number in the caller 18:52:05 -!- Bike [~Glossina@wl-nat100.it.wsu.edu] has quit [Quit: Reconnecting] 18:52:08 -!- Bike_ is now known as Bike 19:07:06 http://paste.lisp.org/display/138545 19:07:58 and of course it's not limited to windows 19:08:04 stassats: how is that mysterious? You just made the tag explicit. 19:09:04 which tag? 19:10:10 and where? 19:10:28 and how did it become explicit? 19:10:33 the tag for fixnum 19:10:49 which you've made explicit by asking for the tagged value, but as a raw machine integer. 19:11:10 You want to %make-lisp-object to roundtrip back. 19:12:11 ah, right, i didn't reproduce it well enough 19:13:28 i was thinking all along that it happened on the first iteration 19:13:36 sdemarre [~serge@91.180.123.25] has joined #sbcl 19:16:59 so the compiler is off the hook, just something wrong with the expected location of dynamic-space pages 19:19:28 -!- easye [~user@213.33.70.157] has quit [Ping timeout: 260 seconds] 19:20:30 this aver fails: https://github.com/sbcl/sbcl/blob/master/src/code/room.lisp#L274 19:22:36 looks like wraparound in the parent call 19:22:51 nope. 19:22:52 easye [~user@213.33.70.157] has joined #sbcl 19:22:58 just plain overflow, I guess. 19:23:42 is concurrent consing a possibility? 19:24:29 don't think so, it fails reliably in the same place on the first table 19:24:39 perhaps end is calculated incorrectly 19:25:58 specifically, it fails on "NIL" (the string) 19:26:58 which happens to be symbol-name of NIL 19:28:31 oh, we do strange thing to static and ro spaces on windows. 19:28:44 or safepoint builds in general, I guess. 19:28:56 -!- easye [~user@213.33.70.157] has quit [Read error: Connection reset by peer] 19:28:59 but this is supposed to by dynamic space 19:29:03 well, map-allocated-objects is called with :dynamic 19:29:07 it's in dynamic space? ok. 19:29:39 i'd expect the name of NIL to be in dynamic space 19:29:46 right. 19:33:28 it's actually the second table, and the reported bytes-used is 6 19:35:28 the preceding one is 4096, probably 6 is a left-over 19:37:37 indeed, that's how it's supposed to work 19:41:59 (loop for i below last-free-page collect (slot (deref page-table i) 'bytes-used)) returns a sequence of (4096 6 4096 6 4096 6 ... 19:42:12 while on linux-x86 it's 32768 32768 32768... 19:43:28 err, that's on x86-64, of course 19:43:34 a sequence of 4096s on x86 19:44:34 so, something is wrong with bytes-used on windows 19:44:59 <|3b|> is that 32bit or 64bit on windows? 19:45:09 32-bit 19:46:25 <|3b|> ok, probably not what i was thinking of then 19:46:42 <|3b|> did the broken alien struct layout on 64bit windows ever get fixed? 19:46:53 *|3b|* probably should have filed a bug for that too 19:47:07 haven't ever built a 64-bit sbcl on windows 19:47:31 i probably should, but the 32-bit one presents enough problems to deal with 19:47:38 <|3b|> yeah :/ 19:48:36 i really hope that resolving this ROOM issue will also help with some other GC problems 19:51:38 sb-vm::last-free-page is twice as large on windows as on linux 19:51:58 perhaps that's those sixes 19:52:31 towards the end they are actually fives 19:52:59 so the patterin is (close-to-4096 ...) 19:55:57 -!- yacks [~py@103.6.158.105] has quit [Ping timeout: 264 seconds] 19:57:28 huh, i have a 32-bit 1.0.55.7, and it has 32768 19:57:32 not 4096, and no 6/5s 19:57:42 is mswinmt the windows fork? 19:59:00 right, more weird and weird 19:59:07 |3b|: do you have any kind of windows sbcl nearby? 19:59:58 i'd love to see the results of (loop for i below 10 collect (sb-alien:slot (sb-alien:deref sb-vm::page-table i) 'sb-vm::bytes-used)) 20:02:28 the fork has https://github.com/akovalenko/sbcl-win32-threads/blob/mswin/src/compiler/x86/backend-parms.lisp#L35 20:02:34 as opposed to (setf *backend-page-bytes* 4096) 20:02:36 ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has joined #sbcl 20:03:02 without any explanation 20:03:27 <|3b|> the 1.1.8 binary says (4096 6 4096 6 4096 6 4096 6 4096 6) 20:03:32 but i think the size shouldn't matter 20:04:03 ok, so at least it's not a recent regression 20:05:28 -!- lufu [~user@5.254.134.48] has quit [Remote host closed the connection] 20:09:40 (loop for i below 10 collect (cons (sb-alien:slot (sb-alien:deref sb-vm::page-table i) 'sb-vm::bytes-used) (sb-alien:slot (sb-alien:deref sb-vm::page-table i) 'sb-vm::start))) gives 0 for 4096, but values close to 140 for 5/6 20:11:00 quite weird 20:11:28 i hope this one won't take 5 days to find out something stupid missing 20:13:38 ow, when i print 'sb-vm::flags on linux, i get values close to 140 20:14:28 so, the struct is wrongly parsed 20:15:28 or rather, seems like offsets are wrong 20:16:13 scymtym_ [~user@ip-5-147-120-181.unitymediagroup.de] has joined #sbcl 20:27:32 sizeof(struct page) => 16, (alien-size (struct sb-vm::page) :bytes) => 8 20:29:12 -!- sdemarre [~serge@91.180.123.25] has quit [Ping timeout: 256 seconds] 20:30:31 so, who can spot the disrepancy: https://github.com/sbcl/sbcl/blob/master/src/code/room.lisp#L297 and https://github.com/sbcl/sbcl/blob/master/src/runtime/gencgc-internal.h#L53 20:31:33 pkhuong: draft for recursive types is at https://github.com/scymtym/sbcl/commits/wip-recursive-types-with-back-edge 20:35:32 well, i see that syntax for enums for the first time (or remember seeing the first time), so i have no idea how its size is calculated 20:37:05 -!- slyrus [~chatzilla@107.200.11.156] has quit [Ping timeout: 245 seconds] 20:37:42 slyrus [~chatzilla@107.200.11.156] has joined #sbcl 20:40:38 s/(flags (unsigned 8))/(flags unsigned)/ solves the problem 20:40:58 but why does it work on x86-linux? 20:41:30 on x86-linux sizeof(struct page) is 8 20:41:57 what would it mean for bytes_used to be negative? 20:42:28 does windows use some different structure alignment? 20:42:33 redline6561: why are you asking? 20:42:41 Curiosity/ignorance. 20:43:06 it's unsigned 20:43:30 I see that. I'm wondering what a negative value would denote. 20:43:56 I would expect bytes_used to be a signed value. My intuition is clearly wrong. :) 20:43:58 it doesn't make sense 20:44:04 and i don't understand what you're asking 20:44:34 you can't use a negative amount of bytes 20:45:19 Right, I was wondering why page_bytes_t is an unsigned type then. 20:45:35 because it can't be negative 20:45:56 Oh, Jesus. I'm too tired to be asking questions. Excuse me. 20:50:00 and the correct solution is using unsigned char for the bitfield 20:50:22 tcr [~tcr@88-134-110-1-dynip.superkabel.de] has joined #sbcl 20:52:01 even though gcc on linux makes it as if unsigned is the same as unsigned 21:01:07 ok, with room fixed, dynamic-space-size seems to be twice as large on windows 21:01:28 just starting up 21:01:33 or wait, maybe that's because i'm using quicklisp on windows 21:02:02 right 21:02:06 ok, so, that issue is fully solved 21:02:10 bring on the next one 21:03:04 \o/ 21:03:17 I promise to handle the kitten-message-thread 21:03:43 I might be next to useless technically, but I can argue from Boring Authority with no problems 21:04:47 What about NetBSD? 21:05:09 Just asking... :) 21:06:18 Krystof: my last chance for anything SBCL-related this week is in the next ~6 hours. I'll try to move the messages around. 21:06:58 what about the typep thing? 21:08:12 stassats: needs more thought, and not this close to a release. It looks like the sort of thing that will break stuff if it goes wrong, and I don't like applying fix over fix during freeze. 21:08:30 right 21:09:18 ASau: I'll try. Depends a bit on children's sleep schedules 21:09:34 and how problematic the patches look 21:11:32 Well... 21:11:53 If you have suggestions how you'd like to fix them, tell me. 21:12:20 It may be that I'll manage it. 21:13:59 bloody windows, cannot overwrite a binary which is running 21:14:47 Well... You cannot do that in unix either. 21:15:00 E.g. in linux. 21:15:06 don't know about unix, but i can in linux 21:15:16 pkhuong: should i file a launchpad "bug" to manage the recursive types stuff? 21:15:22 No, you cannot. 21:15:28 and do that all the time 21:15:29 What you can is you can remove the file. 21:15:58 call it whatever technical detail you want, but i can't do that on windows and can on linux 21:16:00 ASau: just to confirm, you're talking about 20130712141032.24D1712306@ren.fdy2.co.uk? 21:16:05 scymtym_: it never hurts 21:16:22 stassats: thanks, will do 21:17:05 don't like the "hang in disassembly of consalot", but other than that I can't see anything too problematic with it 21:17:25 I mean, yet more wrappers, but if that's what platforms require, then fine 21:18:02 Krystof: 20130712141032.24D1712306@ren.fdy2.co.uk right 21:18:04 scymtym_: and it decreases the changes of it getting (and here i thought english had some idiom involving Lethe) 21:18:58 Krystof: Well, I'm fine keeping more or less insignificant hacks in package patches. 21:25:26 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Quit: Leaving.] 21:31:43 -!- slyrus [~chatzilla@107.200.11.156] has quit [Ping timeout: 264 seconds] 21:32:06 stassats: done 21:32:06 lp 1214610 21:32:06 https://bugs.launchpad.net/bugs/1214610 21:37:58 perhaps sb-concurrency tests should be marked as failing on windows, because they prevent other contribs from being built 21:38:50 slyrus [~chatzilla@107.200.11.156] has joined #sbcl 21:39:47 <|3b|> stassats: ah, i guess it was the foreign type stuff... thought that was 64bit problem (an i guess it hadn't gotten fixed yet) 21:43:00 |3b|: do sb-concurrency tests finish for you? 21:43:28 i can take them failing, but not hanging 21:48:02 i don't remember sb-concurrency being problematic before 21:48:29 but that was on a different cpu, this is an intel "pentium" or something lowly like that 21:49:02 probably with hyperthreading only 21:49:31 no, two cores too 21:50:33 a sandy bridge too 21:51:00 don't think there's a between home basic and professional 21:51:48 -!- tcr [~tcr@88-134-110-1-dynip.superkabel.de] has quit [Quit: Leaving.] 21:55:47 -!- drmeiste_ [~drmeister@farnsworth.chem.temple.edu] has quit [Remote host closed the connection] 22:03:58 all those threading issues have probably something in common 22:04:18 stassats: http://msdn.microsoft.com/en-us/library/windows/desktop/dd757624(v=vs.85).aspx, and try to set a period of 1 ms? 22:05:01 oh what. the side effects are awful. 22:05:01 is sleep sleeping too much a problem? 22:05:29 i looked before at sleep for shorter amounts of time and haven't found anything satisfactory 22:05:54 under high load, sb-concurrency will sleep 22:06:16 sleeps that are 10x longer than expected might cause timeouts. 22:06:53 particularly if it breaks some proportional backoff logic (but I don't think we have that). 22:07:09 how do people solve those kinds of things? 22:08:10 haha, I love that API. 22:08:23 It returns either TIMERR_NOERROR or TIMERR_NOCANDO. 22:08:24 -!- foom2 is now known as foom 22:08:28 a busy loop? 22:08:46 stassats: that would work. You'll need to use some of the fancy high resolution timers though. 22:09:09 timeGetTime suffers from the exact same timer issue. 22:09:38 It's great to have both success and failure be indicated via a negative. 22:09:43 stassats: you can also try to just disable the sleep. That's how the initial prototype worked on darwin; it was fine. 22:10:09 well, what about other threads.impure failures? 22:10:31 i don't know which, because it hangs in random places 22:10:37 no clue. 22:10:46 I don't even know what these failures are. 22:11:06 neither do i 22:12:01 without threads.impure, i get no unexpected failures 22:12:28 and even one unexpected success 22:12:55 -!- slyrus [~chatzilla@107.200.11.156] has quit [Ping timeout: 245 seconds] 22:17:13 drmeiste_ [~drmeister@166.137.87.168] has joined #sbcl 22:18:40 (:condition-variable :notify-multiple) hangs 22:24:47 -!- drmeiste_ [~drmeister@166.137.87.168] has quit [Remote host closed the connection] 22:34:36 i hate non-deterministic bugs 22:36:40 stassats: you can try to remove the call to nanosleep in %%wait-for. 22:36:44 -!- prxq [~mommer@mnhm-590c3ca8.pool.mediaWays.net] has quit [Quit: Leaving] 22:38:00 it seems to be not failing when run on its own 22:40:29 well, naturally, it fails only when it feels like it 22:41:07 now i got no failures, except my new thread-alloca failing to compile a library 22:42:30 because run-program doesn't accept :environment on windows 22:43:53 drmeiste_ [~drmeister@pool-71-185-168-200.phlapa.fios.verizon.net] has joined #sbcl 22:44:54 <|3b|> stassats: don't remember problems with contrib tests hanging, but didn't do that many builds 22:51:07 stassats: do you have backtraces from a stuck sbcl? 22:51:29 nope, C-c just kills sbcl without questions 22:51:32 tcr [~tcr@88-134-110-1-dynip.superkabel.de] has joined #sbcl 22:52:09 i reckon that's because i'm using some kind of a wrong shell or environment 22:52:28 this damn thing is so fragile 22:52:36 slyrus [~chatzilla@107.200.11.156] has joined #sbcl 22:52:52 stassats: attach with gdb? 22:53:24 or a paste of some output on failure? 22:53:41 so far i only get hangs 22:53:58 and i have gdb installed, will try it 22:54:07 on hang then. 22:54:35 well, the last time i ran threads.impure i had no failures 22:54:58 the damn thing won't cooperate 22:56:19 -!- tcr [~tcr@88-134-110-1-dynip.superkabel.de] has quit [Ping timeout: 264 seconds] 22:56:32 what does couldn't make stderr distinct from stdout mean? 22:57:01 can't use :output with run-program 22:57:02 :output t 22:57:34 :error :output ? 22:58:10 no, that's already the default. 22:58:28 i just ran gcc by hand to see what it doesn't like 22:59:02 it didn't find alloca.h 22:59:31 i guess it can live without it 23:01:29 ok, the test itself passes now 23:09:40 maybe the killing of threads can be problematic in threads.impure 23:10:09 it definitely is. 23:10:59 some tests are written in a non-joinable way 23:21:36 tcr [~tcr@88-134-110-1-dynip.superkabel.de] has joined #sbcl 23:26:26 -!- tcr [~tcr@88-134-110-1-dynip.superkabel.de] has quit [Ping timeout: 256 seconds] 23:30:29 gdb doesn't show anything enlightening 23:30:38 without lisp symbols 23:31:02 maybe sbcl.nm can help 23:31:57 i meant, cold-sbcl.map 23:32:03 but it's not cold code 23:38:58 calling ldb from gdb didn't help 23:40:11 thread apply all call backtrace_from_fp ... 23:40:31 fishing for another hang 23:45:58 i used lisp_backtrace instead, didn't work 23:46:39 stassats: you're looking at the lisp process's output, right? 23:47:02 right, it just segfaults 23:48:30 on some threads it manages to print something, but only a couple of foreign frames 23:49:06 that can still be useful. 23:49:58 i'll try running tests from slime 23:50:04 C-c is more reliable here 23:54:28 so much for that, got killed by windows 23:55:06 and i'm tired of windows problems already 23:55:30 maybe all this is already fixed in the fork and i'm just wasting my time