00:04:22 -!- Sagane_ [~Sagane@177.100-226-89.dsl.completel.net] has quit [Read error: Connection reset by peer] 00:09:50 drmeister [~drmeister@h69-21-18-138.nwlnnh.dedicated.static.tds.net] has joined #sbcl 01:16:19 -!- drmeister [~drmeister@h69-21-18-138.nwlnnh.dedicated.static.tds.net] has quit [Remote host closed the connection] 01:24:35 -!- slyrus [~chatzilla@adsl-108-80-229-231.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 240 seconds] 01:51:28 -!- Bike [~Glossina@67-5-201-64.ptld.qwest.net] has quit [Ping timeout: 268 seconds] 02:11:04 Bike [~Glossina@67-5-201-64.ptld.qwest.net] has joined #sbcl 02:13:34 http://hackage.haskell.org/trac/ghc/ticket/6135 <- interesting... if I read this right, the situation for unboxed predicates is worse for current GHC (although LLVM can probably do some magic) than for (old) CMUCL. 02:20:10 -!- antoszka [~antoszka@unaffiliated/antoszka] has quit [Ping timeout: 256 seconds] 02:38:28 -!- christoph4 [~christoph@ppp-188-174-90-97.dynamic.mnet-online.de] has quit [Ping timeout: 252 seconds] 02:52:59 christoph4 [~christoph@ppp-93-104-161-143.dynamic.mnet-online.de] has joined #sbcl 03:19:04 -!- kanru [~kanru@118-163-10-190.HINET-IP.hinet.net] has quit [Quit: rcirc on GNU Emacs 24.3.50.1] 03:55:12 -!- Blkt [~user@dynamic-adsl-62-10-11-72.clienti.tiscali.it] has quit [Read error: Operation timed out] 03:55:54 Blkt [~user@dynamic-adsl-62-10-11-78.clienti.tiscali.it] has joined #sbcl 04:04:30 drmeister [~drmeister@173-162-165-237-NewEngland.hfc.comcastbusiness.net] has joined #sbcl 04:11:27 -!- yacks [~py@180.151.36.168] has quit [Ping timeout: 268 seconds] 04:12:09 yacks [~py@180.151.36.168] has joined #sbcl 04:32:04 edgar-rft [~GOD@HSI-KBW-149-172-63-75.hsi13.kabel-badenwuerttemberg.de] has joined #sbcl 05:07:44 -!- drmeister [~drmeister@173-162-165-237-NewEngland.hfc.comcastbusiness.net] has quit [Remote host closed the connection] 05:15:54 ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has joined #sbcl 05:33:22 attila_lendvai [~attila_le@92.47.189.151] has joined #sbcl 05:33:22 -!- attila_lendvai [~attila_le@92.47.189.151] has quit [Changing host] 05:33:22 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 05:38:39 prxq [~mommer@mnhm-590c0e6d.pool.mediaWays.net] has joined #sbcl 05:40:36 teggi [~teggi@113.173.3.200] has joined #sbcl 06:07:46 antoszka [~antoszka@unaffiliated/antoszka] has joined #sbcl 06:10:19 benkard [~benkard@ppp-93-104-161-140.dynamic.mnet-online.de] has joined #sbcl 06:14:38 attila_lendvai1 [~attila_le@92.47.189.151] has joined #sbcl 06:14:38 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Disconnected by services] 06:15:01 -!- attila_lendvai1 is now known as Guest84160 06:15:19 -!- Guest84160 is now known as attila_lendvai 06:15:49 -!- attila_lendvai is now known as Guest33398 06:16:10 -!- Guest33398 [~attila_le@92.47.189.151] has quit [Client Quit] 06:36:21 -!- ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has quit [Ping timeout: 252 seconds] 06:46:14 -!- benkard [~benkard@ppp-93-104-161-140.dynamic.mnet-online.de] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz] 06:47:46 angavrilov [~angavrilo@217.71.227.190] has joined #sbcl 07:13:22 -!- wbooze [~wbooze@xdsl-87-79-198-180.netcologne.de] has quit [Quit: none] 07:16:39 wbooze [~wbooze@xdsl-87-79-198-180.netcologne.de] has joined #sbcl 07:25:10 attila_lendvai [~attila_le@87.247.13.215] has joined #sbcl 07:25:10 -!- attila_lendvai [~attila_le@87.247.13.215] has quit [Changing host] 07:25:10 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 07:38:07 -!- wbooze [~wbooze@xdsl-87-79-198-180.netcologne.de] has quit [Ping timeout: 276 seconds] 07:38:54 wbooze [~wbooze@xdsl-78-35-166-224.netcologne.de] has joined #sbcl 07:40:22 kanru [~kanru@118-163-10-190.HINET-IP.hinet.net] has joined #sbcl 07:46:54 -!- Blkt [~user@dynamic-adsl-62-10-11-78.clienti.tiscali.it] has quit [Read error: Operation timed out] 07:48:12 Blkt [~user@82.84.170.56] has joined #sbcl 07:51:57 benkard [~benkard@dhcp-138-246-85-119.dynamic.eduroam.mwn.de] has joined #sbcl 07:53:45 -!- Blkt [~user@82.84.170.56] has quit [Read error: Operation timed out] 07:54:29 Blkt [~user@82.84.173.138] has joined #sbcl 09:05:00 foreignFunction [~niksaak@ip-4761.sunline.net.ua] has joined #sbcl 09:25:32 -!- benkard [~benkard@dhcp-138-246-85-119.dynamic.eduroam.mwn.de] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz] 09:40:08 stassats [~stassats@wikipedia/stassats] has joined #sbcl 09:46:02 foom: I've mentioned it to nikodemus again. He'll try, but no ETA known yet. 10:39:42 benkard [~benkard@dhcp-138-246-85-119.dynamic.eduroam.mwn.de] has joined #sbcl 10:58:23 -!- angavrilov [~angavrilo@217.71.227.190] has quit [Ping timeout: 240 seconds] 11:27:42 segv- [~mb@95-91-241-45-dynip.superkabel.de] has joined #sbcl 11:38:14 -!- christoph4 is now known as christoph_debian 12:00:53 -!- benkard [~benkard@dhcp-138-246-85-119.dynamic.eduroam.mwn.de] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz] 12:04:38 Sagane [~Sagane@177.100-226-89.dsl.completel.net] has joined #sbcl 12:12:58 drmeister [~drmeister@h69-21-18-138.nwlnnh.dedicated.static.tds.net] has joined #sbcl 12:28:57 -!- drmeister [~drmeister@h69-21-18-138.nwlnnh.dedicated.static.tds.net] has quit [Remote host closed the connection] 12:31:01 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 246 seconds] 13:00:34 -!- yacks [~py@180.151.36.168] has quit [Quit: Leaving] 13:06:23 -!- psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has quit [Quit: Leaving.] 13:07:30 nyef [~nyef@c-50-157-244-41.hsd1.ma.comcast.net] has joined #sbcl 13:07:40 G'morning all. 13:08:09 hi nyef 13:12:42 -!- jsnell_ [~jsnell@ash.snellman.net] has quit [Ping timeout: 264 seconds] 13:12:58 jsnell [~jsnell@ash.snellman.net] has joined #sbcl 13:33:44 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 13:36:43 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 13:43:59 *|3b|* is in windows for the moment, was there something in particular that needed tested there? 13:52:18 psilord [~pkeller@23-25-144-217-static.hfc.comcastbusiness.net] has joined #sbcl 14:03:17 <|3b|> how does it decide which arch to use on windows? 14:03:33 *|3b|* thinks i'm using 64bit sbcl to build, but it seems to be building 32 bit 14:04:06 slyrus [~chatzilla@adsl-108-80-229-231.dsl.pltn13.sbcglobal.net] has joined #sbcl 14:05:16 SBCL_ARCH, maybe? 14:05:37 <|3b|> don't think that is set 14:06:03 It's plausible that windows alwaus reports x86, like darwin used to do. 14:06:27 joshe's struct groveling patch might like further testing. I saw some unexpected failures in Nick Levine's report. 14:06:37 <|3b|> guess i'll try specifying it by hand 14:07:34 *|3b|* got the impression last time i tried that the windows port had some threading problems 14:07:38 ah yes, I was just looking at that 14:08:07 are those unexpected failures normal, I wonder 14:08:08 <|3b|> one of the threads test files would lock up or segfault at various places most of the time 14:08:47 benkard [~benkard@dhcp-138-246-85-119.dynamic.eduroam.mwn.de] has joined #sbcl 14:09:08 <|3b|> as far as i could tell one of the more common spots for it to break was at a call to GC, which doesn't seem like a good sign 14:13:04 <|3b|> and looks like my uname -m is i686, so i guess reasonable for it to pick 32 bit 14:15:40 Are safepoint-threading builds getting tested very much, or only on windows? 14:15:58 -!- slyrus [~chatzilla@adsl-108-80-229-231.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 240 seconds] 14:16:23 -!- scymtym_ [~user@ip-5-147-122-209.unitymediagroup.de] has quit [Ping timeout: 245 seconds] 14:17:59 only windows, I guess. lichteblau used to test on linux, iirc. 14:22:06 <|3b|> normal build tests seems to be stuck at ::: Running :ALL-THREADS-HAVE-ABORT-RESTART 14:23:04 I had some thought that we don't actually need P-A if the GC can tell if we have an allocation in process and simply pin the open allocation region. 14:24:03 there's some issue with unix signals, I think. 14:24:21 ah, ok, with further changes. 14:25:08 Yes. I had part of a hack working with (non-LOCK) CMPXCHG, but I kept hitting strange and hard to understand bugs and gave up (especially after safepoints revealed that PA really isn't that bad). 14:33:42 <|3b|> grovel patch seems to have built on 32 bit 14:35:06 <|3b|> and another segfault (or whatever, didn't actually read the crash popup) running tests on normal build 14:37:15 <|3b|> tests on patched build seems to be stuck on ::: Running :PRINTABLE-CONDITIONS 14:40:41 #d 14:40:52 (oops, sorry) 14:41:14 this was not the window you were looking at 14:44:45 hlavaty` [~user@friedrichstrasse.knowledgetools.de] has joined #sbcl 14:46:43 -!- hlavaty [~user@friedrichstrasse.knowledgetools.de] has quit [Ping timeout: 264 seconds] 14:47:14 <|3b|> and this time both seem to have locked up after ::: Running (:CONDITION-VARIABLE :NOTIFY-MULTIPLE) 14:47:45 <|3b|> which i think is the place i was suspecting of being a call to GC 14:54:56 slyrus [~chatzilla@adsl-108-80-229-231.dsl.pltn13.sbcglobal.net] has joined #sbcl 14:58:09 hi segv- :) 14:58:21 hey fe[nl]ix :) 15:00:12 pkhuong: re testing safepoints on non-windows builds: is anything else necessary besides building with sb-safepoint and running the test suite? 15:04:09 pranavrc [~pranavrc@122.164.161.61] has joined #sbcl 15:04:10 -!- pranavrc [~pranavrc@122.164.161.61] has quit [Changing host] 15:04:10 pranavrc [~pranavrc@unaffiliated/pranavrc] has joined #sbcl 15:09:47 <|3b|> would building without threads (assuming that is still possible on windows) provide a useful test for the struct grovelling stuff? 15:10:44 that's a big assumption 15:10:53 It shouldn' 15:10:58 t be a big assumption. 15:11:11 We usually like to keep the basic things working independent of the trickier bits. 15:12:29 sounds like a good principle in general, but we had pretty basic things that didn't work before threading, and with it they do 15:13:53 scymtym: nothing besides building with "safepoints enabled", but note that safepoints need more *features* than :sb-safepoint 15:14:40 -!- slyrus [~chatzilla@adsl-108-80-229-231.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 240 seconds] 15:16:53 hzp: thanks, do you mean 1) it needs particular features to also be enabled in customize-target-features.lisp or 2) that enabling sb-safepoint in customize-target-features.lisp may not work when particular other features are not available for the machine/os? 15:20:47 |3b|: we don't do #!-sb-thread on windows. 15:21:20 scymtym: There's a couple related features to enable/disable as well. safepoint, thruption, and another one I'm forgetting, I believe. 15:22:00 sb-wtimer IIRC 15:22:14 pkhuong, hzp: thanks, i will try that combination 15:22:53 and sb-safepoint-strictly is the one truly optional feature, in case you're adventurous 15:23:16 but regarding 2) not all platforms are supported. There's a small bit of OS support needed (present on Linux, Windows, and Solaris) and obviously ISA support (x86, x86-64, and PPC currently) 15:23:39 <|3b|> ok, that's what i suspected.. so what would count as "successful test" for the patch, when it can't usually run through the tests without the patch? 15:23:59 no regression? (: 15:24:33 -!- Posterdati [~antani@host210-219-dynamic.16-87-r.retail.telecomitalia.it] has quit [Quit: KVIrc 4.1.3 Equilibrium http://www.kvirc.net/] 15:24:47 <|3b|> well, it breaks similarly with and without the patch as far as i can tell :p 15:24:55 <|3b|> which means "pretty much at random" 15:25:23 heh. good enough. 15:25:32 <|3b|> this time it was Invalid exit status: clos-cache.impure.lisp 15:25:48 <|3b|> on the normal build, and Invalid exit status: threads.impure.lisp 15:25:48 <|3b|> Invalid exit status: timer.impure.lisp 15:25:52 <|3b|> on the patched build 15:26:02 do you think you can look at the grovelled structs to see if they match with what we's handwritten before? 15:26:13 <|3b|> where is the old version? 15:26:29 hzp: i will try to test safepoint builds on our linux x86 and x86_64 slaves then 15:27:04 <|3b|> grovelled signed 32 for both fields of timeval and timespec 15:31:12 angavrilov [~angavrilo@217.71.227.190] has joined #sbcl 15:31:35 |3b|: time-t and long 15:31:58 slyrus [~chatzilla@adsl-108-80-229-231.dsl.pltn13.sbcglobal.net] has joined #sbcl 15:32:06 ints would make sense on x86 then. 15:37:27 <|3b|> --arch=x86-64 for 64bit build? 15:38:46 I believe that works (I still SBCL_ARCH). 15:39:20 <|3b|> seems to be building at least 15:40:54 <|3b|> or not: alloc.c:1:0: sorry, unimplemented: 64-bit mode not compiled in 15:41:32 *|3b|* wonders if i need a different gcc or something 15:42:04 looks likely. 15:43:33 -!- angavrilov [~angavrilo@217.71.227.190] has quit [Read error: Operation timed out] 15:47:31 -!- hzp [~user@eth1-2.bob.askja.de] has quit [*.net *.split] 15:47:31 -!- scymtym [~user@2001:638:504:2093:226:b9ff:fe7d:3e1f] has quit [*.net *.split] 15:47:31 -!- abarch [~user@2001:638:504:2093:21d:9ff:fe30:1f87] has quit [*.net *.split] 15:47:32 -!- nicdev [user@2600:3c03::f03c:91ff:fedf:4986] has quit [*.net *.split] 15:47:45 _8david [~user@eth1-2.bob.askja.de] has joined #sbcl 15:47:45 nicdev` [user@2600:3c03::f03c:91ff:fedf:4986] has joined #sbcl 15:50:16 scymtym [~user@2001:638:504:2093:226:b9ff:fe7d:3e1f] has joined #sbcl 15:54:12 -!- jdz [~jdz@85.254.212.34] has quit [Excess Flood] 15:54:35 jdz [~jdz@85.254.212.34] has joined #sbcl 15:56:57 -!- Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has quit [Remote host closed the connection] 15:57:18 abarch [~user@2001:638:504:2093:21d:9ff:fe30:1f87] has joined #sbcl 16:04:58 -!- _8david [~user@eth1-2.bob.askja.de] has quit [Quit: ERC Version 5.2 (IRC client for Emacs)] 16:05:15 hzp [~user@eth1-2.bob.askja.de] has joined #sbcl 16:05:42 -!- slyrus [~chatzilla@adsl-108-80-229-231.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 240 seconds] 16:06:46 -!- abarch [~user@2001:638:504:2093:21d:9ff:fe30:1f87] has quit [Remote host closed the connection] 16:07:30 -!- benkard [~benkard@dhcp-138-246-85-119.dynamic.eduroam.mwn.de] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz] 16:07:44 <|3b|> hmm, seems to be lots of 64bit mingw variants to choose from :/ 16:09:07 yeah, IIRC I gave up on understanding that download nightmare and used the 64 bit TDM-GCC 16:16:57 <|3b|> x86_64-w64-mingw32-gcc-4.8.0-win64_rubenvb seems to be working so far 16:18:21 -!- pranavrc [~pranavrc@unaffiliated/pranavrc] has quit [Quit: Ping timeout: ] 16:24:11 last night I couldn't sleep, and one of the things going round and round in my head was fixing the type system for array types 16:24:12 slyrus [~chatzilla@adsl-108-80-229-231.dsl.pltn13.sbcglobal.net] has joined #sbcl 16:24:22 I didn't actually implement it really, mind, but in my head it works perfectly 16:26:24 <|3b|> looks like i got signed 32 for 64bit build too, will see if that fares any better for tests 16:27:13 -!- hzp [~user@eth1-2.bob.askja.de] has quit [Remote host closed the connection] 16:27:20 hzp [~user@eth1-2.bob.askja.de] has joined #sbcl 16:29:19 <|3b|> heh, 4 expected failures, and invalid exit status on every other test file :p 16:29:34 whoops 16:36:49 *|3b|* tries unpatched 32 and 64 bit builds with same compiler 16:37:50 |3b|: might be an environment (e.g. path) problem too. What does the error look like? 16:38:12 depressing 16:38:23 (I could swear having marked every repeatably failing test as an expected failure, even on 64 bit. BICBW.) 16:38:55 _8hzp [~user@eth1-2.bob.askja.de] has joined #sbcl 16:38:58 -!- hzp [~user@eth1-2.bob.askja.de] has quit [Read error: Connection reset by peer] 16:40:57 <|3b|> might be it doesn't like the way the compiler is configured, one of the mingw 64bit variants had options for posix or native threads, and SEH or sjlj... wouldn't be surprised if either of those could break sbcl 16:42:15 <|3b|> seems to be breaking the debugger or something, gets into debugger with no restarts, then fails to read from standard input, tries to go into debugger on that, etc 16:42:35 <|3b|> hmm, guess i can't build a 32bit sbcl with a 64bit-only gcc 16:51:01 <|3b|> unpatched tests seem to be doing better 16:54:54 time to break out wine, I guess. 16:56:03 -!- slyrus [~chatzilla@adsl-108-80-229-231.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 240 seconds] 16:56:32 <|3b|> still got stuck one of the places 32 bit build was getting stuck though 16:56:41 Krystof: no new modarith bug (: [I expect performance bugs now, actually] 16:57:01 <|3b|> does 32 bit sound right for those fields on 64bit build? 16:57:41 is long still 32 bit on win64? if so, yes. 16:59:25 (yes) 17:02:35 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 17:03:27 *|3b|* tries tests on a build from version before patch 17:07:17 <|3b|> and broken same there as in patched version, so looks like not caused by grovel patch 17:26:49 <|3b|> test results from head: http://paste.lisp.org/+2Y67 17:28:43 <|3b|> compiler.pure.lisp failure seems consistent running just that file, seq.pure.lisp didn't fail when run separately a few times, but happened on at least a few of the full runs from patched version 17:29:26 <|3b|> smoke.impure.lisp is failed AVER: 17:29:27 <|3b|> (<= (GET-LISP-OBJ-ADDRESS START) (GET-LISP-OBJ-ADDRESS END)) 17:29:33 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 17:29:57 <|3b|> as is defstruct.impure.lisp 17:31:54 <|3b|> while running ROOM in both cases 17:33:22 Ooh! 17:33:47 So, how on earth did that happen? 17:34:31 START and END are both FIXNUMs there, and the use of G-L-O-A should yield unsigned words... 17:36:01 <|3b|> and while that run happened to pass threads.impure.lisp, it still seems to be failing randomly 17:36:35 Is there something stupidly different about the page table structure on windows? 17:38:25 Can you try calling list-allocated-objects for :static and :read-only, and see if that much at least works? 17:41:11 <|3b|> (sb-vm:list-allocated-objects :static) seemed to work a few times then possibly locked up the repl after returning (or else my term got confused somehow) 17:41:49 Hrm. 17:42:15 Okay, that makes it more plausible that it's the page table structure... 17:42:19 <|3b|> no repeatably though 17:42:36 Not repeatably locking up your terminal? 17:42:38 <|3b|> actually, maybe i was just confused 17:43:06 *|3b|* will blame user error for now 17:44:46 I'm tempted to ask that you trace map-objects-in-range and run room to see if it produces anything egregiously wrong, but... It's in a without-gcing, and the output could easily be voluminous. 17:45:15 <|3b|> both :static and :read-only seem to work (static prints a bunch of stuff, read-only prints 4 code-objects 17:45:48 Right, read-only space only holds the assembly-routines. 17:46:30 <|3b|> and looks like ROOM in a fresh sbcl gets that failed AVER 17:47:27 -!- foom [jknight@nat/google/x-ujyccinkqpnynihz] has quit [Ping timeout: 260 seconds] 17:47:33 Yeah, which makes it either something weird that the system is doing to the heap structures, which is unlikely because map-objects-in-range is parallel to the structure of the GC, or the page table isn't being parsed properly. 17:47:50 What happens if you trace a recursive function, btw? 17:48:10 <|3b|> well, not completely sure the GC is working right either, but it doesn't break quite that reliably 17:48:20 foom [jknight@nat/google/x-kbpfcyibqjrpgbhn] has joined #sbcl 17:48:22 Sure, sure. 17:48:52 -!- _8hzp [~user@eth1-2.bob.askja.de] has quit [Remote host closed the connection] 17:48:59 _8hzp [~user@eth1-2.bob.askja.de] has joined #sbcl 17:49:21 <|3b|> fwiw, list-allocated-objects :dynamic gets the failed AVER 17:49:21 Actually, try tracing sb-vm::map-objects-in-range and then (sb-vm:list-allocated-objects :read-only), and see how much output you get? 17:49:52 <|3b|> not much 17:49:59 One call or four? 17:50:15 <|3b|> 5? 17:50:36 Right, forgot about the stop condition. Yes, five makes sense, and is unfortunate. 17:51:16 Doing this for :dynamic is probably going to produce voluminous output. /-: 17:51:28 <|3b|> calling room with it traced looks like it got about 485 17:51:40 -!- pkhuong [~pkhuong@modemcable086.239-37-24.mc.videotron.ca] has quit [Read error: Connection reset by peer] 17:52:36 Hrm. Any discontinuities in the END value? 17:54:51 pkhuong [~pkhuong@modemcable086.239-37-24.mc.videotron.ca] has joined #sbcl 17:54:56 Actually, 64 bit system, isn't it? Are any of the low three bits of the END value set? 17:55:23 <|3b|> END is last value in 0: (SB-VM::MAP-OBJECTS-IN-RANGE 17:55:24 <|3b|> # 34359738368 17:55:24 <|3b|> 34359754752) 17:55:26 <|3b|> ? 17:55:39 Yes, it is. 17:55:48 The parameter list is (fun start end). 17:56:34 <|3b|> seems to be always the same 17:57:01 Mmm. gencgc-card-bytes is #x4000, isn't it? 17:57:22 Or is it? 17:58:07 <|3b|> ah, looking more closely, the one we care about is the (SB-VM::MAP-OBJECTS-IN-RANGE 17:58:08 <|3b|> # 17:58:08 <|3b|> 34359774048 34359771139) 17:58:13 <|3b|> with low bits set 17:58:25 <|3b|> and start > end 17:58:40 That's the second or third value for END, isn't it? 17:59:42 <|3b|> SB-VM:GENCGC-CARD-BYTES -> 32768 17:59:59 Right, that's sane, I forgot about the fixnum shift for a bit. 18:00:15 <|3b|> you mean in that call to ROOM? 3rd i think 18:00:47 Looks like the page table structure definition is wrong somehow. 18:01:14 <|3b|> hmm, maybe second 18:01:22 *|3b|* is getting confused scrolling around 18:02:27 How wide is an os_vm_size_t on the C side, and how wide is a SIGNED on the Lisp side? 18:03:43 <|3b|> ok, tracing map-objects-in-range, and running just (list-allocated-objects :dynamic), looks like that is the 2nd value for END 18:04:05 <|3b|> how do i check that? 18:04:21 That... I'm not sure about. 18:04:28 |3b|: printing an alien with that type (or a pointer to that type) should be good, Lisp-side 18:04:59 C-side, probably easiest to add a dummy extern variables in the runtime + sizeof. 18:05:47 CL-USER> (sb-alien:sap-alien (sb-sys:int-sap 0) (* sb-alien:signed)) 18:05:47 # 18:06:06 Ideally, they'll be the same. If not, we'll need to come up with something for the definition of struct page in room.lisp. 18:06:15 <|3b|> # 18:06:35 drmeister [~drmeister@70.42.157.33] has joined #sbcl 18:07:18 Can we get type-layout information from gdb? 18:07:29 probably. 18:08:33 We need to validate the C compiler's idea of the gencgc page structure against ROOM's idea of the same. 18:09:29 ... And this might actually be the time to turn around and make it a primitive-object, so that we control the mapping explicitly. 18:09:41 "No struct type named page" 18:10:15 bitfield ABI issue? 18:10:38 Only for packing, the rewrite no longer refers to the bitfield slots. 18:12:03 I'd love to get rid of the bitfields in favor of hacking at the raw bits in a flags word via macros, the way that CMUCL did. One of the few GC maintenance decisions that I'm not a huge fan of. 18:14:12 I guess another option is that we can easily get a pointer to the page table, and dumping the memory for the first few pages worth should allow us to determine the layout by inspection. 18:16:50 leuler [~user@p548FC0C7.dip0.t-ipconnect.de] has joined #sbcl 18:16:54 <|3b|> gdb seems to think os_vm_size_t is unsigned long long 18:17:51 So, 64-bit? 18:18:21 And the page_bytes_t should be 16-bit... 18:18:39 <|3b|> yeah, unsigned short 18:18:53 What about generation_index_t? 18:19:35 <|3b|> signed char 18:19:37 So we're looking at either bitfield padding or alignment. 18:19:57 nyef: same re bitfields. 18:23:13 <|3b|> unsigned int write_protected : 1; 18:23:37 <|3b|> is that unsigned int matching the lisp side? 18:23:40 <_8hzp> this all sounds vaguely reminiscent of lp #1057631 18:23:52 <|3b|> lp 1057631 18:23:52 https://bugs.launchpad.net/bugs/1057631 18:24:27 Lisp side just has an (unsigned 8) for "flags" where the bitfields are in C. 18:25:17 <|3b|> isn't (unsigned 8) char rather than int? 18:25:30 Yeah, but there are only 8 bits worth of flags there... 18:25:57 <|3b|> wouldn't that move the last field though? 18:26:07 ... Maybe? 18:26:28 That's sortof why we're looking at this structure, though. 18:26:53 I'm still thinking that we should just remove the bitfields and go for a flags byte and some macros to access it, which would obviate most of the problem. 18:27:29 Even better would be getting it emitted from genesis, or at least the flag constants. 18:27:45 If we can all agree that this is the direction to head, I can put together a patch this weekend. 18:27:51 +1 from me. 18:28:06 maybe jsnell has an opinion. 18:28:12 <|3b|> if i'm reading right, gdb things offset of gen in the struct is 16 18:28:16 <|3b|> *thinks 18:29:23 <|3b|> testing with p (int)&((struct page*)0)->gen 18:31:18 ... It's too bad that primitive-object slot granularity is by the word, really. /-: 18:32:46 ASau` [~user@p5797EB0A.dip0.t-ipconnect.de] has joined #sbcl 18:36:27 -!- ASau [~user@p4FF9695F.dip0.t-ipconnect.de] has quit [Ping timeout: 252 seconds] 18:39:40 benkard [~benkard@mnch-5d856f2e.pool.mediaWays.net] has joined #sbcl 18:40:11 -!- benkard [~benkard@mnch-5d856f2e.pool.mediaWays.net] has quit [Client Quit] 18:42:30 <|3b|> building with 32 bit flags in (struct page) seems to have fixed room 18:44:04 *|3b|* wonders if that depends on gcc version and/or configuration 18:45:20 definitely. 18:48:53 <|3b|> hmm, though now i'm getting the "fail all the tests" thing instead... wonder if i didn't build what i thought i did 18:52:02 slyrus [~chatzilla@173-228-44-92.dsl.static.sonic.net] has joined #sbcl 18:56:59 Posterdati [~antani@host210-219-dynamic.16-87-r.retail.telecomitalia.it] has joined #sbcl 19:00:55 benkard [~benkard@mnch-5d856f2e.pool.mediaWays.net] has joined #sbcl 19:01:18 -!- teggi [~teggi@113.173.3.200] has quit [Remote host closed the connection] 19:02:28 yacks [~py@180.151.36.168] has joined #sbcl 19:04:50 -!- benkard [~benkard@mnch-5d856f2e.pool.mediaWays.net] has quit [Client Quit] 19:26:35 -!- drmeister [~drmeister@70.42.157.33] has quit [Read error: Connection reset by peer] 19:26:47 drmeister [~drmeister@70.42.157.33] has joined #sbcl 19:35:52 -!- drmeister [~drmeister@70.42.157.33] has quit [Remote host closed the connection] 19:41:19 -!- wbooze [~wbooze@xdsl-78-35-166-224.netcologne.de] has quit [Ping timeout: 264 seconds] 19:42:26 wbooze [~wbooze@xdsl-78-35-144-234.netcologne.de] has joined #sbcl 19:48:32 drmeister [~drmeister@70.42.157.33] has joined #sbcl 19:53:48 drmeiste_ [~drmeister@mobile-198-228-197-121.mycingular.net] has joined #sbcl 19:56:42 ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has joined #sbcl 19:56:48 -!- drmeister [~drmeister@70.42.157.33] has quit [Ping timeout: 245 seconds] 20:20:30 stassats [~stassats@wikipedia/stassats] has joined #sbcl 20:20:37 -!- stassats [~stassats@wikipedia/stassats] has quit [Client Quit] 20:39:31 -!- leuler [~user@p548FC0C7.dip0.t-ipconnect.de] has quit [Quit: ERC Version 5.1.2 $Revision: 1.796.2.6 $ (IRC client for Emacs)] 20:51:36 -!- drmeiste_ is now known as drmeister 20:53:32 Do I need to do anything with my local tree to fix up the remote for sourceforge's git migration thing? 20:55:14 git remote set-url origin ssh://nyef@git.code.sf.net/p/sbcl/sbcl 20:55:21 where "nyef" might not be quite correct 20:56:23 Ah, wonderful. Thank you. 21:00:03 Okay, that got me a few more commits. 21:03:42 -!- segv- [~mb@95-91-241-45-dynip.superkabel.de] has quit [Ping timeout: 264 seconds] 21:04:54 scymtym_ [~user@ip-5-147-122-209.unitymediagroup.de] has joined #sbcl 21:06:00 And my current plan for this weekend includes doing something about the bitfields in the gencgc page structure, most likely converting them BACK into a single integer with defined bitmasks and whatnot, and then arranging some magic dance to get all of the definitions for the fields available on both sides, and possibly the structure itself as well. 21:07:36 sdemarre [~serge@91.180.84.159] has joined #sbcl 21:07:45 A possible followup is that there are a number of very similar loops over the page tables looking for various conditions, which could be factored out if it were straightforward to specify the conditions in terms of a single mask-and-compare. 21:17:08 -!- edgar-rft [~GOD@HSI-KBW-149-172-63-75.hsi13.kabel-badenwuerttemberg.de] has quit [Quit: mental vacuum] 21:17:56 And now it's time for me to head out. 21:18:01 -!- nyef [~nyef@c-50-157-244-41.hsd1.ma.comcast.net] has quit [Quit: G'night all.] 21:42:53 -!- sdemarre [~serge@91.180.84.159] has quit [Read error: Operation timed out] 21:47:54 -!- drmeister [~drmeister@mobile-198-228-197-121.mycingular.net] has quit [Read error: Connection reset by peer] 21:50:28 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Quit: Leaving.] 21:55:17 drmeister [~drmeister@mobile-198-228-197-121.mycingular.net] has joined #sbcl 22:00:45 -!- psilord [~pkeller@23-25-144-217-static.hfc.comcastbusiness.net] has quit [Quit: Leaving.] 22:01:09 -!- drmeister [~drmeister@mobile-198-228-197-121.mycingular.net] has quit [Read error: Connection reset by peer] 22:01:41 drmeister [~drmeister@70.42.157.33] has joined #sbcl 22:28:33 -!- slyrus [~chatzilla@173-228-44-92.dsl.static.sonic.net] has quit [Ping timeout: 240 seconds] 22:30:36 -!- drmeister [~drmeister@70.42.157.33] has quit [Read error: Connection reset by peer] 22:30:51 drmeister [~drmeister@70.42.157.33] has joined #sbcl 22:46:25 -!- drmeister [~drmeister@70.42.157.33] has quit [Read error: Connection reset by peer] 22:46:39 drmeister [~drmeister@70.42.157.33] has joined #sbcl 22:53:35 psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has joined #sbcl 23:23:37 -!- foreignFunction [~niksaak@ip-4761.sunline.net.ua] has quit [Quit: Leaving.] 23:27:02 Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has joined #sbcl 23:33:17 -!- Sagane [~Sagane@177.100-226-89.dsl.completel.net] has quit [Read error: Connection reset by peer] 23:45:58 -!- drmeister [~drmeister@70.42.157.33] has quit [Ping timeout: 245 seconds] 23:51:21 -!- ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has quit [Read error: Connection reset by peer] 23:55:26 drmeister [~drmeister@mobile-198-228-197-121.mycingular.net] has joined #sbcl