04:48:37 ccl-logbot [~ccl-logbo@setf.clozure.com] has joined #sbcl 04:48:37 04:48:37 -!- names: ccl-logbot slyrus nixfreak_ echo-area homie tsuru Neronus antgreen danlentz peterhil` Quadrescence redline6561 @Krystof hargettp_ |3b| cmm specbot ASau` lnostdal antifuchs luis fe[nl]ix gnooth minion lisppaste2 derrotebaron jsnell clop jiacobucci joshe peddie pkhuong foom deepfire christoph 05:56:00 stassats [~stassats@wikipedia/stassats] has joined #sbcl 06:42:20 woudshoo [~user@ironhead.xs4all.nl] has joined #sbcl 06:59:26 -!- woudshoo [~user@ironhead.xs4all.nl] has quit [Ping timeout: 240 seconds] 07:19:29 flip214 [~marek@2001:858:107:1:baac:6fff:fe6b:9183] has joined #sbcl 07:19:29 -!- flip214 [~marek@2001:858:107:1:baac:6fff:fe6b:9183] has quit [Changing host] 07:19:29 flip214 [~marek@unaffiliated/flip214] has joined #sbcl 07:49:27 -!- derrotebaron [johannes@static.7.69.47.78.clients.your-server.de] has quit [Quit: WeeChat 0.3.0] 08:01:23 -!- homie [~levgue@xdsl-78-35-140-178.netcologne.de] has quit [Read error: Connection reset by peer] 08:59:10 attila_lendvai [~attila_le@catv-80-98-24-21.catv.broadband.hu] has joined #sbcl 08:59:10 -!- attila_lendvai [~attila_le@catv-80-98-24-21.catv.broadband.hu] has quit [Changing host] 08:59:10 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 09:03:27 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Client Quit] 09:30:50 tcr [~tcr@217-162-131-235.dynamic.hispeed.ch] has joined #sbcl 09:33:14 hargettp [~hargettp@pool-71-184-182-139.bstnma.east.verizon.net] has joined #sbcl 10:14:25 I want to compare if a pointer is equal to (void *) 1 10:14:45 I wonder how I do that in a platform independent way 10:24:50 (= (integer-length (pointer-address ))) ? 10:25:46 hm no :-) 10:26:29 maybe I should just use sb-vm:n-word-bits 10:28:06 <|3b|> maybe see if it is sap= (sap- (int-sap 0) 1)? 10:28:26 <|3b|> or see if adding 1 to it with sap+ gives you 0? 10:28:28 not n-word-bits, anyway 10:28:34 *|3b|* has no idea if those are portable though :) 10:28:52 you could look at how sb-posix does it (for mmap) 10:28:59 not that that's necessarily despereately stylish 10:29:22 <|3b|> and meant (sap+ .. -1) for the first one anyway 10:39:04 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 250 seconds] 10:55:54 when is n-word-bits not the same as n-machine-word-bits? when running 32bit inside 64bit? 11:18:52 yes 11:19:01 probably only on the alpha 11:19:21 (running an sbcl in 32-bit mode on an x86-64 probably means that you get a 32-bit mmap, so that worry doesn't apply) 11:51:10 stassats [~stassats@wikipedia/stassats] has joined #sbcl 11:53:45 woudshoo [~user@ironhead.xs4all.nl] has joined #sbcl 12:01:10 -!- hargettp [~hargettp@pool-71-184-182-139.bstnma.east.verizon.net] has quit [Quit: Leaving...] 12:11:29 (ldb (byte n-m-w-b 32) -1), btw. 12:17:20 erh, (byte n-m-w-b 0) 12:26:21 dlowe [~dlowe@ita4fw1.itasoftware.com] has joined #sbcl 14:08:54 -!- flip214 [~marek@unaffiliated/flip214] has quit [Remote host closed the connection] 17:00:05 ccl-logbot [~ccl-logbo@setf.clozure.com] has joined #sbcl 17:00:05 17:00:05 -!- names: ccl-logbot homie tsuru dlowe stassats deepfire jsnell fe[nl]ix nyef |3b| Neronus slyrus scymtym christop` cmm joshe gnooth @Krystof peddie froydnj foom loke derrotebaron jiacobucci danlentz Quadrescence specbot ASau` lnostdal antifuchs luis minion lisppaste2 clop pkhuong 17:05:35 tcr [~tcr@100.Red-88-6-12.staticIP.rima-tde.net] has joined #sbcl 17:26:14 homie` [~levgue@xdsl-78-35-188-100.netcologne.de] has joined #sbcl 17:28:40 -!- homie [~levgue@xdsl-78-35-176-171.netcologne.de] has quit [Ping timeout: 246 seconds] 17:34:43 -!- homie` [~levgue@xdsl-78-35-188-100.netcologne.de] has quit [Remote host closed the connection] 17:37:37 -!- Quadrescence [~Quad@unaffiliated/quadrescence] has quit [Quit: omghaahhahaohwow] 17:39:16 homie [~levgue@xdsl-78-35-188-100.netcologne.de] has joined #sbcl 17:44:10 Quadrescence [~Quad@c-24-131-149-41.hsd1.mn.comcast.net] has joined #sbcl 17:44:13 -!- Quadrescence [~Quad@c-24-131-149-41.hsd1.mn.comcast.net] has quit [Changing host] 17:44:13 Quadrescence [~Quad@unaffiliated/quadrescence] has joined #sbcl 18:44:04 -!- tcr [~tcr@100.Red-88-6-12.staticIP.rima-tde.net] has quit [Quit: Leaving.] 18:47:46 -!- homie [~levgue@xdsl-78-35-188-100.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 18:59:52 homie [~levgue@xdsl-78-35-188-100.netcologne.de] has joined #sbcl 19:41:17 rmarynch [~roman@88.135.194.233] has joined #sbcl 20:44:02 -!- rmarynch [~roman@88.135.194.233] has quit [Quit: Leaving] 21:01:00 prxq [~mommer@mnhm-4d013d98.pool.mediaWays.net] has joined #sbcl 21:15:14 -!- dlowe [~dlowe@ita4fw1.itasoftware.com] has quit [Quit: Leaving.] 21:49:00 Fare [~Fare@ita4fw1.itasoftware.com] has joined #sbcl 22:33:19 antgreen [~user@CPE00222d6c4710-CM00222d6c470d.cpe.net.cable.rogers.com] has joined #sbcl 23:12:18 hargettp [~hargettp@96.237.121.111] has joined #sbcl 23:24:15 -!- prxq [~mommer@mnhm-4d013d98.pool.mediaWays.net] has quit [Quit: good night] 23:28:33 -!- tsuru [~charlie@adsl-87-47-213.bna.bellsouth.net] has quit [Remote host closed the connection] 23:29:28 attila_lendvai [~attila_le@catv-80-98-24-21.catv.broadband.hu] has joined #sbcl 23:29:28 -!- attila_lendvai [~attila_le@catv-80-98-24-21.catv.broadband.hu] has quit [Changing host] 23:29:28 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 00:31:39 -!- lisppaste2 [~lisppaste@common-lisp.net] has quit [Quit: Want lisppaste2 in your channel? Email lisppaste-requests AT common-lisp.net.] 00:32:01 lisppaste2 [~lisppaste@common-lisp.net] has joined #sbcl 00:39:32 tcr [~tcr@100.Red-88-6-12.staticIP.rima-tde.net] has joined #sbcl 00:48:35 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 00:58:03 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 248 seconds] 01:36:48 -!- loke [~elias@bb119-74-213-61.singnet.com.sg] has quit [Remote host closed the connection] 01:40:33 -!- tcr [~tcr@100.Red-88-6-12.staticIP.rima-tde.net] has quit [Quit: Leaving.] 03:20:15 -!- hargettp [~hargettp@96.237.121.111] has quit [Quit: Leaving...] 05:03:31 nikodemus [~nikodemus@cs181199216.pp.htv.fi] has joined #sbcl 05:03:31 -!- ChanServ has set mode +o nikodemus 05:42:51 homie` [~levgue@xdsl-78-35-170-221.netcologne.de] has joined #sbcl 05:45:36 -!- homie [~levgue@xdsl-78-35-188-100.netcologne.de] has quit [Ping timeout: 260 seconds] 07:57:33 tcr [~tcr@100.Red-88-6-12.staticIP.rima-tde.net] has joined #sbcl 08:09:44 -!- antgreen [~user@CPE00222d6c4710-CM00222d6c470d.cpe.net.cable.rogers.com] has quit [Ping timeout: 250 seconds] 08:43:21 -!- tcr [~tcr@100.Red-88-6-12.staticIP.rima-tde.net] has quit [Quit: Leaving.] 08:53:24 tcr [~tcr@100.Red-88-6-12.staticIP.rima-tde.net] has joined #sbcl 09:01:27 -!- tcr [~tcr@100.Red-88-6-12.staticIP.rima-tde.net] has quit [Quit: Leaving.] 09:04:09 tcr [~tcr@100.Red-88-6-12.staticIP.rima-tde.net] has joined #sbcl 09:04:56 stassats [~stassats@wikipedia/stassats] has joined #sbcl 09:16:33 -!- lnostdal [~Lars@213.80-202-59.nextgentel.com] has quit [*.net *.split] 09:26:20 -!- tcr [~tcr@100.Red-88-6-12.staticIP.rima-tde.net] has quit [Quit: Leaving.] 09:27:52 lnostdal [~Lars@213.80-202-59.nextgentel.com] has joined #sbcl 09:29:12 attila_lendvai [~attila_le@catv-80-98-24-21.catv.broadband.hu] has joined #sbcl 09:29:16 -!- attila_lendvai [~attila_le@catv-80-98-24-21.catv.broadband.hu] has quit [Changing host] 09:29:16 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 09:30:09 tcr [~tcr@100.Red-88-6-12.staticIP.rima-tde.net] has joined #sbcl 09:38:32 tcr1 [~tcr@100.Red-88-6-12.staticIP.rima-tde.net] has joined #sbcl 09:38:32 -!- tcr [~tcr@100.Red-88-6-12.staticIP.rima-tde.net] has quit [Read error: Connection reset by peer] 09:55:12 -!- tcr1 [~tcr@100.Red-88-6-12.staticIP.rima-tde.net] has quit [Quit: Leaving.] 09:59:12 tcr [~tcr@100.Red-88-6-12.staticIP.rima-tde.net] has joined #sbcl 10:00:09 -!- tcr [~tcr@100.Red-88-6-12.staticIP.rima-tde.net] has quit [Client Quit] 11:07:39 tcr [~tcr@242.135.16.95.dynamic.jazztel.es] has joined #sbcl 11:13:35 hargettp [~hargettp@96.237.121.111] has joined #sbcl 11:35:16 -!- tcr [~tcr@242.135.16.95.dynamic.jazztel.es] has quit [Quit: Leaving.] 12:18:31 -!- homie` [~levgue@xdsl-78-35-170-221.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 12:23:21 homie [~levgue@xdsl-78-35-170-221.netcologne.de] has joined #sbcl 12:49:19 -!- hargettp [~hargettp@96.237.121.111] has quit [Quit: Leaving...] 13:11:00 tcr [~tcr@77.135.16.95.dynamic.jazztel.es] has joined #sbcl 13:16:11 -!- tcr [~tcr@77.135.16.95.dynamic.jazztel.es] has quit [Quit: Leaving.] 13:23:54 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Disconnected by services] 13:23:54 attila_lendvai1 [~attila_le@catv-80-98-24-21.catv.broadband.hu] has joined #sbcl 13:23:55 -!- attila_lendvai1 is now known as attila_lendvai 13:23:55 -!- attila_lendvai [~attila_le@catv-80-98-24-21.catv.broadband.hu] has quit [Changing host] 13:23:55 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 14:00:50 loke [~elias@bb119-74-213-61.singnet.com.sg] has joined #sbcl 14:09:42 hargettp [~hargettp@96.237.121.111] has joined #sbcl 14:53:40 -!- stassats [~stassats@wikipedia/stassats] has quit [Remote host closed the connection] 14:53:45 -!- hargettp [~hargettp@96.237.121.111] has quit [Quit: Leaving...] 15:04:41 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 15:07:50 -!- cmm [~cmm@109.65.210.62] has quit [Ping timeout: 240 seconds] 16:14:57 stassats [~stassats@wikipedia/stassats] has joined #sbcl 16:23:50 redline6561 [~user@c-66-56-55-169.hsd1.ga.comcast.net] has joined #sbcl 17:08:46 cmm [~cmm@bzq-109-66-212-239.red.bezeqint.net] has joined #sbcl 17:43:28 -!- redline6561 [~user@c-66-56-55-169.hsd1.ga.comcast.net] has quit [Ping timeout: 246 seconds] 17:45:49 hargettp [~hargettp@96.237.121.111] has joined #sbcl 17:46:16 homie` [~levgue@xdsl-78-35-128-38.netcologne.de] has joined #sbcl 17:48:38 -!- homie [~levgue@xdsl-78-35-170-221.netcologne.de] has quit [Ping timeout: 250 seconds] 18:07:50 tcr [~tcr@77.135.16.95.dynamic.jazztel.es] has joined #sbcl 18:15:48 -!- homie` [~levgue@xdsl-78-35-128-38.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 18:28:06 homie [~levgue@xdsl-78-35-128-38.netcologne.de] has joined #sbcl 18:52:17 -!- nikodemus [~nikodemus@cs181199216.pp.htv.fi] has quit [Ping timeout: 240 seconds] 19:01:18 -!- tcr [~tcr@77.135.16.95.dynamic.jazztel.es] has quit [Read error: Connection reset by peer] 19:09:27 tcr [~tcr@116.134.16.95.dynamic.jazztel.es] has joined #sbcl 20:12:43 -!- Quadrescence [~Quad@unaffiliated/quadrescence] has quit [Quit: omghaahhahaohwow] 20:13:57 Quadrescence [~Quad@unaffiliated/quadrescence] has joined #sbcl 21:07:21 -!- hargettp [~hargettp@96.237.121.111] has quit [Quit: Leaving...] 21:32:18 hargettp [~hargettp@96.237.121.111] has joined #sbcl 21:34:01 redline6561 [~user@c-66-56-55-169.hsd1.ga.comcast.net] has joined #sbcl 21:42:32 -!- hargettp [~hargettp@96.237.121.111] has quit [Quit: Linkinus - http://linkinus.com] 22:22:08 -!- lisppaste2 [~lisppaste@common-lisp.net] has quit [Quit: Want lisppaste2 in your channel? Email lisppaste-requests AT common-lisp.net.] 22:22:20 lisppaste2 [~lisppaste@common-lisp.net] has joined #sbcl 23:53:51 -!- homie [~levgue@xdsl-78-35-128-38.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 23:57:52 homie [~levgue@xdsl-78-35-128-38.netcologne.de] has joined #sbcl 01:08:17 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 240 seconds] 01:16:30 -!- homie [~levgue@xdsl-78-35-128-38.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 01:17:44 sepult [~levgue@xdsl-78-35-128-38.netcologne.de] has joined #sbcl 01:18:46 -!- sepult [~levgue@xdsl-78-35-128-38.netcologne.de] has quit [Read error: Connection reset by peer] 01:21:53 homie [~levgue@xdsl-78-35-128-38.netcologne.de] has joined #sbcl 01:42:47 -!- homie [~levgue@xdsl-78-35-128-38.netcologne.de] has left #sbcl 02:06:30 -!- tcr [~tcr@116.134.16.95.dynamic.jazztel.es] has quit [Quit: Leaving.] 02:07:36 homie [~levgue@xdsl-78-35-128-38.netcologne.de] has joined #sbcl 02:36:47 -!- froydnj [~froydnj@gateway.codesourcery.com] has quit [Ping timeout: 252 seconds] 02:39:43 -!- redline6561 [~user@c-66-56-55-169.hsd1.ga.comcast.net] has quit [Ping timeout: 240 seconds] 02:40:30 redline6561 [~user@c-66-56-55-169.hsd1.ga.comcast.net] has joined #sbcl 02:46:07 -!- redline6561 [~user@c-66-56-55-169.hsd1.ga.comcast.net] has quit [Read error: Connection reset by peer] 03:05:48 redline6561 [~user@c-66-56-55-169.hsd1.ga.comcast.net] has joined #sbcl 03:13:25 -!- redline6561 [~user@c-66-56-55-169.hsd1.ga.comcast.net] has quit [Remote host closed the connection] 06:21:25 nikodemus [~nikodemus@cs181199216.pp.htv.fi] has joined #sbcl 06:21:25 -!- ChanServ has set mode +o nikodemus 06:32:38 homie` [~levgue@xdsl-78-35-186-178.netcologne.de] has joined #sbcl 06:34:22 -!- homie [~levgue@xdsl-78-35-128-38.netcologne.de] has quit [Ping timeout: 250 seconds] 09:09:15 tcr [~tcr@116.134.16.95.dynamic.jazztel.es] has joined #sbcl 09:12:10 stassats [~stassats@wikipedia/stassats] has joined #sbcl 09:48:25 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 246 seconds] 10:45:10 -!- homie` [~levgue@xdsl-78-35-186-178.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 10:47:05 homie [~levgue@xdsl-78-35-186-178.netcologne.de] has joined #sbcl 12:15:17 hargettp [~hargettp@96.237.121.111] has joined #sbcl 13:25:06 -!- tcr [~tcr@116.134.16.95.dynamic.jazztel.es] has quit [Quit: Leaving.] 13:40:57 -!- homie [~levgue@xdsl-78-35-186-178.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 13:47:04 homie [~levgue@xdsl-78-35-186-178.netcologne.de] has joined #sbcl 14:16:13 tcr [~tcr@116.134.16.95.dynamic.jazztel.es] has joined #sbcl 14:58:31 stassats [~stassats@wikipedia/stassats] has joined #sbcl 15:14:04 -!- tcr [~tcr@116.134.16.95.dynamic.jazztel.es] has quit [Quit: Leaving.] 15:30:32 uh, I can't build multi-threaded 1.0.47 on OS X after coming from 1.0.46 15:31:06 Uh-oh. 15:31:19 http://paste.lisp.org/+2LB7 15:31:42 yeah. I've been building SBCL @ the releases steadily since about .39 :( 15:32:04 ... dare we suggest doing so during the pre-release freeze as well? 15:32:13 perhaps :) 15:32:21 I don't even know how to debug this one. 15:32:28 testing before a release? 15:32:33 what s novel concept 15:32:47 Wait, 0x3030303030304645 ? 15:32:59 I'm gonna add as many notes to the paste as I can...might open bug on launchpad later, if we need it 15:33:07 Assuming that's little-endian, isn't that 'EF '? 15:33:36 ... no, it's 'EF000000'. 15:33:36 space is 0x20 15:33:43 Yeah, just remembered that. 15:33:52 Still, not a good thing to see. 15:34:52 Are you running in a source-control directory or a freshly unpacked source tarball, or something else? 15:35:30 (You're clearly building an x86-64 version.) 15:35:33 did a git fetch to the sbcl.1.0.47 label from antifuchs git repo; building in that directory, as I have always done 15:35:45 Did you run ./clean.sh before building? 15:35:47 yep 64bit, with threading enabling 15:36:17 heh: well, not on my first failure...but did run clean before this failure 15:36:26 Hrm. 15:36:46 Enable sb-show and build, see how far it gets? 15:36:57 got an even weirder failure message the first time, but since I didn't run clean...probably a red-herring... 15:37:08 ... And I suppose I should do a clean build of x86-64/linux. 15:37:13 SBCL's init file is .sbclrc, right? 15:37:28 yes 15:37:33 I did an openbsd x86-64 build yesterday or so 15:37:38 i don't have an ~/.sbclrc file, so that's not it 15:37:39 no threading there, of course 15:37:40 I believe so, but cold-init runs without loading initfiles. 15:38:45 was just trying to think what could break the SBCL i already have...in case that's how things went wrong... :( 15:39:09 Okay, checked my c-t-f, and it just adds an after-xc core and sb-test, which shouldn't affect the cold-core. 15:39:23 And I'm now building an x86-64/linux 1.0.47. 15:39:31 (Threaded, as that's the default.) 15:39:57 i think i'll clone to another directory, and try again...leave that log and dir in place for a sec, just in case 15:40:09 Has anyone built threaded x86-64 on OSX during the freeze period? 15:40:26 I know slyrus did a ppc osx build... 15:41:10 ... and I was unable to do any ppc testing at all. :-( 15:41:33 clear, some kind of automatic thingy is needed 15:41:57 I don't mind being an OSX x86-64 guinea pig...just a pity if this is a real bug in the release, that's all :) 15:42:28 If it's a bug in the release, it's a bug in the release... And you'll know better for next month, right? 15:43:02 lol! apparently. haven't seen a release-day bug that bit me for a while :) 15:43:33 Wish I could say the same. 15:43:41 doh! 15:44:17 build #3 in progress :) 15:45:11 1.0.45, specifically, contains a bug in the lifetime analysis. 15:45:55 i hit a bug back during the transition to ASDF2 last year...asdf-install failure 15:46:15 uh, lifetime analysis sounds much worse 15:47:13 Mmm. The actual failure mode involved tail-calls to local functions. 15:47:31 ouch 15:47:48 Hey, they aren't -that- common. 15:47:54 :) 15:48:05 Still, they're common enough to be a problem. 15:48:19 only clx fell down? 15:48:33 No, apparently QPX did as well. 15:48:50 But a limitation to projects with three-letter names ending in #\x isn't all bad. 15:48:52 nyef: I did a couple non-threaded ppc builds and sent the test results to the list 15:49:47 sorry that I didn't think to do x86* osx builds too 15:49:48 Okay, I see independent confirmation of OSX build failure. 15:50:26 joshe: I think everyone involved with an x86oid osx box is regretting not building in the past week. 15:50:53 I keep forgetting that I have x86 osx available for testing now 15:51:32 who uses releases anyway? 15:51:47 more than use cvs/git, I think 15:52:07 dang, same basic failure again: http://paste.lisp.org/+2LB7/2 15:52:45 I don't know that the monthly release schedule leaves a lot of time for testing 15:52:53 too bad i have no such platform, i'd run bisect on it 15:53:01 hargettp: Right, we expected that much. Enable :sb-show in customize-target-features? 15:53:26 hargettp: Alternately, start a git bisect? 15:53:46 nyef: already pasted my customize-target-features http://paste.lisp.org/+2LB7/3 15:53:57 what am I looking for with git bisect? 15:54:20 for make.sh to succeed 15:54:24 Well, you know that 1.0.46 builds successfully, right? 15:54:32 it sure does 15:54:56 *hargettp* is reading up on git bisect 15:55:04 So, check out master, git bisect bad, check out sbcl_1_0_46, git bisect good, then keep building and reporting success or failure until it tells you which commit to blame. 15:55:31 does make.sh return a non-zero value on failure? 15:55:39 I can bisect for you if you want 15:55:48 if so, you can automate the process completely 15:55:55 joshe: feel free to get one going...seems easy enough, so i'll start it too 15:55:58 this is just a normal x86-64 osx build with :sb-thread, right? 15:56:07 joshe: yup 15:56:11 However, I will point out 1.0.46.26 through 1.0.46.32 as the most likely-to-fail commits. 15:56:31 Did I say .32? .31. 15:56:47 slyrus: Ping? 15:57:53 ok, I'm bisecting now, starting at 46.26 15:58:02 *hargettp* is bisecting with abandon 15:59:11 I keep forgetting how *fast* this machine is 15:59:22 how? 15:59:24 On the one hand, bisection is wonderful in tracking down commits that cause problems. On the other hand, I dislike doing it because it takes me a half hour per build. 15:59:41 stassats: I just got it and haven't done much compiling 15:59:49 i think i'm about 5-10 mins per build 16:00:06 I think I'm going to be -so- glad when I get a real machine again. 16:00:06 sbcl compiles in less than 3 min 30 sec here 16:00:17 nice 16:00:32 nyef: yeah, that was me last year...my condolences :) 16:00:33 I've been doing ppc builds recently so anything under an hour seems fast to me 16:00:57 joshe: Really? I used to get half-hour builds on my PPC before it died. 16:01:17 the last act of my failed business was purchasing a new laptop for me lol 16:01:26 Dual-core 2GHz G5 might have had something to do with it, though. 16:01:51 hey nyef 16:02:02 oh, this was a G5 too, so it was probably faster 16:02:14 slyrus: Check your scrollback. x86-64 OSX builds are failing. 16:02:19 I didn't actually pay much attention, I was used to hour+ builds from my old G4 16:02:36 oh? that's news to me. 16:02:40 .26 is good 16:03:05 threaded or not? 16:03:14 slyrus: Also a report from Pascal Costanza on the ML. 16:03:21 Threaded in hargettp's case, at least. 16:03:38 I'm bisecting with :sb-thread 16:03:40 hargettp: Which version of XCode are you using? 16:04:11 nyef: ah....good question...I did upgrade to the XCode 4.0 in the last few weeks....not the new 4.0.1 or w/e that came out this week tho 16:04:16 We have a success report from Didier Verna with XCode 3, and a failure from Pascal Costanza with 4. 16:04:23 i'm on 4 16:04:27 I blame Apple 16:04:36 I didn't pay for it, so I must have 3 16:04:39 pascal has the same failure I hit 16:05:04 ... see, -this- is one of the reasons I don't like OSX. 16:05:33 i like it for all the non-developer stuff I do...but yes, I see your point, on the developer front :) 16:05:34 ah, I'm on xcode 3 too 16:05:53 didn't they ditch gcc for clang in 4? 16:06:12 I suppose I can spring the $4.99 for a 4.0 xcode to try to check this down 16:06:26 gcc version is i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3) 16:06:34 gcc --version, that is 16:06:57 Have we tried checking threaded vs. non-threaded builds yet? 16:07:02 that's identical to what I have here 16:07:11 it's great folks waited until .47 came out to try building on the fancy new compiler 16:07:27 intriguing...that's usually one of the things that Xcode upgrades change...oh well 16:07:46 nobody ever tests until after releases 16:07:53 Hey, if we can blame the fancy new compiler, it at least looks a little better, especially if they charge for it. 16:08:01 not that I am entirely immune to that as well 16:08:15 hargettp: What about cc --version ? 16:08:17 often a week is just too little time to get around to it 16:08:27 If they changed the default cc, but left gcc as-was...? 16:08:30 i686-apple-darwin10-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.9) 16:08:49 Hrm. 16:09:14 note the appearance of LLVM in that string 16:09:15 for me, cc is the same as gcc 16:10:12 pascal's error message on the ML at least points out where in the make*.sh scripts the failure happened...I have no such message in my output 16:10:31 have you tried gcc --compile-and-link-normally-without-some-new-stupid-apple-default-setting ? 16:11:11 slyrus: uh, i ran ./configure && make yesterday on LLVM pulled from sources...seemed to work ok 16:11:12 hargettp: But it's not new information to the rest of us: Both messages finger cold-init as the problem. 16:11:21 k 16:11:38 hargettp: hrm... OK. of course the folks at apple probably build LLVM too. 16:11:49 we need a mole in DTS 16:13:09 nyef: think turning off threading is worth it? 16:13:34 hargettp: I think it might be... and it might not be. 16:13:48 more datapoints are always good 16:13:49 nothing to lose, except build time...starting it now... 16:13:54 If turning off threading gets a working SBCL, we at least have something to report to the list. 16:14:09 ... and my linux build finished successfully, as expected. 16:14:17 ok, builds fine here with xcode 3 and threads, but we knew that... 16:15:31 i wonder if 1.0.46 actually builds okay with XCode 4? 16:16:04 ie: does 1.0.46 actually work with xcode 4, with and without threads and does 1.0.47 build with xcode 4 without threads 16:16:08 dunno, but .46.44 builds fine with xcode 2.4! 16:16:25 i'm building 1.0.47 without threads right now 16:17:44 *slyrus* hates how Apple seems to have forgotten to introduce the App Store dev team to their HIG team 16:18:08 and how about x86? 16:18:23 *hargettp* guess the current App Store is a band-aid until Lion comes out 16:18:43 slyrus: Human Interface Guidelines are for other people, clearly. 16:20:36 ah, awesome, I should have Xcode 4 by about 21:00 UTC 16:20:50 $4.99 and a 5 hour download for a broken compiler? yay apple! 16:20:53 slyrus: yes, a heartwarming 6GB download or something, iirc 16:21:15 all counting towards your monthly cap, if you have an ISP that does that 16:21:38 but back to my earlier question, has anyone tried x86 yet? 16:22:00 okay 1.0.47 x86_64 fails w/o threading, too... 16:22:41 i can try x86 now...is it (disable :x86_64) in customize-target-features.lisp? 16:22:53 SBCL_ARCH=x86 sh make.sh 16:22:57 k 16:24:02 fyi: for completeness, I remembered I have a shell script that wraps invocations to SBCL...looks innocuous, but for completeness here it is : http://paste.lisp.org/+2LB7/4 16:24:45 so... should we up .47 binaries carefully built with xcode 3 or try to fix the problem and maybe roll another release? 16:24:47 that's where I actually do set a value for SBCL_HOME...and UTF-8 16:25:12 I think we saved a 3rd-significant-digit build number away for a rainy day a few months back 16:26:47 I didn't realize SBCL might be short on OS X testing...guess I'll pull sources and build more often in the future :) 16:29:01 aha! x86 1.0.47 builds just fine 16:29:04 we have a datapoint 16:29:34 that's with threading on, too 16:32:23 any value in CC=/path/to/gcc sh make.sh? I noticed my cc has a diff version from gcc...unlike joshe, for example 16:32:48 the other thing that's been nagging me about x86-64 builds is the occasional (although usually reproducible when it happens) failure with sb-after-xc-core 16:33:13 slyrus: I may have seen that too...esp when building my own executables, with save-lisp-and-die, iirc 16:33:15 tcr [~tcr@116.134.16.95.dynamic.jazztel.es] has joined #sbcl 16:33:43 Something about a bogus scavenge function for a fixnum in SLAD? 16:33:51 *slyrus* wonders if the mach_port fixes might be part of the xcode 4 problem 16:34:18 hargettp: can you try 1.0.46.24? 16:34:25 Should be easy to check, right? Build .24? 16:34:31 slyrus: will do so after this current build finish 16:34:33 *finishes 16:34:40 thnaks 16:34:47 ofc! :) 16:35:01 4 hours 1 minute remaining... 16:35:11 for...? :) 16:35:43 XCode 4 download, presumably. 16:35:47 lol 16:36:36 hey....CC=/usr/bin/gcc sh make.sh made it past the previous failure point.... 16:36:44 i thought slyrus had so small wage he needed to work for 4 hours to get 4.99$ for xcode 16:37:43 no, he's VERY RICH 16:37:54 wow...folks, that worked...specifying GCC for CC (since cc is new and LLVM flavored with XCode 4) seemed to build fine 16:38:41 going to do again to verify carefullly that that was the only change 16:46:14 morning jsnell 16:47:02 hargettp: that would be nice if true 16:47:16 2 for 2: 2nd build worked fine....cd tests && ./run-tests.sh going now... 16:47:34 slyrus: at least it's a workaround...and good evidence that it's an Apple bug :) 16:47:40 "CC=gcc sh make.sh" is enough to fix it? 16:48:05 slyrus: yes, altho I had an explicit path to GCC...but yes, that was the trick 16:48:19 it's probably too early to declare it an apple bug. it's quite possible that sbcl is doing something it shouldn't 16:48:43 :) 16:48:57 "CC=`which gcc` sh make.sh", maybe? 16:49:16 nyef: nicely complete :) 16:49:59 re run-tests.sh...I don't run this very often...will there be a summary output when it's done? 16:50:03 Arguably, a lot of what SBCL does is something it shouldn't. 16:50:10 lol 16:50:12 hargettp: Yes, provided it doesn't break horribly. 16:50:29 good...it seems busy, so no horrible breakage...yet... 16:50:31 And there's at least one compiler test which fails intermittently. 16:53:19 rpg [~rpg@216.243.156.16.real-time.com] has joined #sbcl 16:55:16 okay, test output here...guessing this looks about right: http://paste.lisp.org/+2LBB 16:55:56 slyrus: I am presuming since CC= resolved the issue, building 46.24 is no longer useful at this time? :) 16:58:45 that's looks like too much failures 16:59:20 pity I don't have test results from earlier releases :( 17:04:13 hargettp: well, no, I'd still like to know when things break (perhaps it's always been broken with CLANG though). but I can do that in 3 hrs and 31 minutes from now... 17:04:16 if you don't get to it first 17:05:07 slyrus: I am thinking i should try building 1.0.46 or earlier...in case the problematic code pre-dates the release of XCode 4...thoughts? 17:05:16 sure, that sounds good 17:05:26 -!- rpg [~rpg@216.243.156.16.real-time.com] has quit [Quit: rpg] 17:05:34 sbcl can't be build by clang without applying some patches, at least on linux 17:05:45 jsnell: in the absence of data, let's just jump to conclusions and blame apple -- that's more fun than taking responsibility for our code 17:08:18 nyef: git bisect rocks; thanks for giving me a reason to use it :) 17:08:54 hargettp: You're welcome. And, yes, it's totally amazing and how on earth did we survive without it? 17:09:01 i have no idea :) 17:09:31 i need to figure out how to do several bisections at once 17:09:50 stassats: multiple work trees 17:10:06 fe[nl]ix: that's obvious 17:10:54 and i can write my own bisector, that's obvious too 17:15:43 whatever happened to our fleet of buildbots? 17:16:17 slyrus: I think they're still running XCode 3. :-P 17:16:33 ah, but are they still building? if so, that's good 17:17:23 you know, all the extra testing that comes with a new release is a good argument for an eventual 1.1 release. As soon we release that, we'll get all sorts of problem reports! 17:17:55 Heh. I still remember the 1.0 release. Held the "buggiest release ever" title for quite a while. 17:17:57 or it's an argument for long-time users like me to pull sources and build pre-release :) 17:18:11 or both 17:18:25 *long-time being relative, of course 17:18:30 Aren't we still missing some features desired for a 1.0 release? 17:18:54 like darwin threads tests passing? 17:21:34 Heh. "a threadsafe serve-event replacement". 17:21:57 I actually proposed a 1.1 release for last December. 17:22:17 But beyond acknowledging the humour and appropriateness of it, nobody did anything. 17:23:26 skip 1.1, release 1.2! 17:25:17 ugh...1.0.40, 1.0.45, 1.0.46, 1.0.47 are all failing with the same error 17:25:56 so whatever in SBCL is triggering this bug / issue in the new cc is older 17:27:08 hargettp: And may, in fact, have always been that way. 17:27:11 what's the --version for the offending cc again? 17:27:20 nyef: yeah, huh? 17:27:45 stassats: cc --version yields "i686-apple-darwin10-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.9)" 17:27:49 hargettp: It could have been "wrong" from the start. 17:28:06 hargettp: llvm-gcc, that's what i wanted to see, let me try to build with llvm-gcc on linux 17:28:26 nyef: yes, perhaps it's more strict thatn previous non-llvm compilers 17:28:53 *stassats* does aptitude install -R llvm-gcc-4.2 17:32:17 it has llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build), looks close 17:32:32 wow, definitely 17:33:13 hargettp: that's good news 17:33:22 slyrus: indeed 17:34:30 nope, seems to be compiling fine 17:34:57 got past that # step? 17:35:04 built fine 17:35:08 :( 17:35:36 hargettp: That step is GENESIS, btw. Only thing in the system that uses GSPACEs. 17:35:50 nyef: ah ty 17:36:32 it seems Apple's sources for LLVM-GCC are online...is a diff against the Linux sources doable? 17:36:49 well, i doubt it will help 17:37:07 and may not acutally produce a diff, if version #s are any indicationg 17:37:10 *indication 17:37:38 Doesn't help that it's a memory-corruption bug, does it? 17:41:00 worth transitioning this to a bug on Launchpad? 17:41:29 You know I always wonder if LP helped its cause or not 17:41:45 Definitively yes, it does very good to not forgetting bugs 17:42:09 I'm almost surprised that there's not a bug for this on launchpad already. 17:42:34 OTOH it might make people lazy in so far as they think logging a bug is enough help already 17:42:55 (This is unrelated commentary to hargettp - in fact I'm speaking of my own experience) 17:43:38 nyef: just looking at new bugs, I don't see anything exactly like this...sure, some issues around x86_64 & darwin, but not obviously the same 17:46:25 hargettp: This is new as of XCode 4, surely? There haven't been any new SBCL bugs filed about it in the past week. 17:46:46 nyef: I think you're right. It's the most likely variable, of all we have discuss today 17:55:58 ok, bugged that sucker on Launchpad: #743751 17:56:46 lp 743751 17:56:47 https://bugs.launchpad.net/bugs/743751 17:58:03 Looks good. 17:58:15 cool 18:00:06 I'm happy to help more, but my knowledge of SBCL internals is non-existent...but I can at least be a build-bot, when needed :) 18:00:27 thanks very much to all who helped today :) 18:06:15 oh, it's the commit window again 18:06:31 stassats: Yup! 18:06:48 too short? 18:07:25 so, i have changes to sb-cover, they're split into many small git commits, how should i commit, everything in one big commit? because those small commits are quite uninteresting 18:07:47 stassats: What sort of "quite uninteresting"? 18:07:54 stassats: doesn't rebase help in that scenario? 18:07:57 (And how many is "many"?) 18:08:01 hargettp: No, it doesn't. 18:08:06 shucks 18:08:28 Well, it does in a way: rebase --interactive and then squash, but there's a policy decision to be made beforehand. 18:09:29 nyef: like changing only a couple of lines 18:10:17 but they all can be grouped into one category 18:10:43 stassats: Have a look at 1.0.44.6 through 1.0.44.19 or 1.0.41.2 through 1.0.41.42 for the kind of granularity that I've been known to use. 18:11:06 and i don't think anyone will be interested in reading re-factoring commits 18:11:58 Rather have them as separate commits than bundled with interesting functional changes. 18:12:22 Arguably, 1.0.41.12 is a refactoring commit, for example. 18:13:20 ok, i'll use common sense for that 18:13:24 We can look at a refactoring commit and say, "yes, that clearly is behavior preserving. we can stop thinking about it now." 18:14:30 well, the whole thins can be called refactoring, the changes are for adding the way to get coverage information suitable for Slime 18:14:49 Mmm. You don't break the build at any point in this series, do you? 18:15:11 so it consists of splitting existing functions and then skipping some steps which are done to generate HTML 18:15:41 it only concerns sb-cover contrib, not internal coverage implementation 18:15:53 Fair enough, I guess. 18:16:16 I hate to give a blanket answer on things like this. 18:27:10 stassats: if someone else committed those changes, and a year later you need to figure out what was done at that point, how would you wish they had committed them? 18:29:34 Ah, yes. That's a good way to look at it. 18:30:58 Oh, and bad nikodemus, breaking control-stack-expands-upward systems. :-P 18:31:19 i confess 18:31:44 but i really blame whoever decided that sap- and sap+ need to be different 18:32:07 i can understand the motivation, but the names suck 18:32:31 *stassats* actually looks at the commits in question 18:33:10 s/sap-/sap-distance/ or s/sap+/sap-offset/ or something 18:33:38 looks like there's one big commit, a three small cleaning up commits, so splitting them up wouldn't improve understanding 18:34:45 *slyrus* twiddles thumbs... 1 hr 57 minuntes remaining... 18:35:24 don't worry, it'll fail at 1 minute remaining 18:51:47 cmm- [~cmm@bzq-79-176-209-182.red.bezeqint.net] has joined #sbcl 18:55:05 -!- cmm [~cmm@bzq-109-66-212-239.red.bezeqint.net] has quit [Ping timeout: 276 seconds] 18:55:28 heh 19:12:31 homie` [~levgue@xdsl-78-35-159-187.netcologne.de] has joined #sbcl 19:13:14 -!- homie` [~levgue@xdsl-78-35-159-187.netcologne.de] has quit [Remote host closed the connection] 19:14:43 -!- homie [~levgue@xdsl-78-35-186-178.netcologne.de] has quit [Ping timeout: 240 seconds] 19:46:08 -!- tcr [~tcr@116.134.16.95.dynamic.jazztel.es] has quit [Quit: Leaving.] 20:04:44 homie [~levgue@xdsl-78-35-159-187.netcologne.de] has joined #sbcl 21:05:05 -!- nikodemus [~nikodemus@cs181199216.pp.htv.fi] has quit [Ping timeout: 240 seconds] 21:19:19 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 246 seconds] 21:21:52 FareWell [~Fare@64.119.159.126] has joined #sbcl 21:22:12 -!- Fare [~Fare@ita4fw1.itasoftware.com] has quit [Remote host closed the connection] 21:22:52 -!- FareWell is now known as Fare 22:17:41 nikodemus [~nikodemus@cs181199216.pp.htv.fi] has joined #sbcl 22:17:41 -!- ChanServ has set mode +o nikodemus 22:47:29 -!- nikodemus [~nikodemus@cs181199216.pp.htv.fi] has quit [Ping timeout: 240 seconds] 22:59:50 redline6561 [~user@c-66-56-55-169.hsd1.ga.comcast.net] has joined #sbcl 23:09:13 tcr [~tcr@92.58.136.182] has joined #sbcl 23:15:45 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 23:54:13 -!- tcr [~tcr@92.58.136.182] has quit [Quit: Leaving.] 00:14:42 wow. in order to install this new tool chain I need to quit ... iTunes??!? 00:23:45 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 00:37:27 cmm [~cmm@109.65.203.181] has joined #sbcl 00:39:52 -!- cmm- [~cmm@bzq-79-176-209-182.red.bezeqint.net] has quit [Ping timeout: 246 seconds] 01:18:35 score one for apple 01:20:11 Oh? 01:20:51 "This function returns 0 if the path was successfully copied. It returns -1 if the buffer is not large enough, and * bufsize is set to the size required." 01:22:34 the new mach-o/dyld.h has the helpful comment "and *bufsize is left unchanged." after "was successfully copied." 01:22:51 we were scribbling a '\0' at path[size] 01:23:26 does that fix the problem? 01:23:35 (asking the question so you don't have to) 01:24:19 why, yes, it seems to 01:24:40 I think this is a long-standing bug on all darwins and we were just getting lucky before 01:26:40 I also think we should check runtime_path again before trying to free it because we could end up in that free code path if runtime_path is NULL but saved_runtime_path isn't, BICBW about that 01:27:23 oops, did I introduce this bug when I did the saved runtime path stuff? 01:51:19 antgreen [~user@CPE00222d6c4710-CM00222d6c470d.cpe.net.cable.rogers.com] has joined #sbcl 01:52:40 -!- slyrus [~chatzilla@adsl-76-254-45-145.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 250 seconds] 01:58:59 slyrus [~chatzilla@adsl-76-254-45-145.dsl.pltn13.sbcglobal.net] has joined #sbcl 02:04:48 damn flaky networks 02:42:37 joshe, hargettp: can you verify that the 1.0.47.1 fixes the problem? 02:44:20 I don't have xcode 4 02:44:39 I suppose I can test with llvm-gcc from macports 02:45:08 no, don't worry about it, test with what you've got :) 02:45:23 sure 02:45:30 and it wasn't your bug in the first place :) chandler maybe? 02:45:39 just x86oid or ppc too? 02:45:58 ah, nice to know :) 02:48:08 heh. I was just looking at that. looks like it was both. 02:49:34 did you already commit 1.0.47.1? 02:51:34 yes, I did 02:52:02 hmm... looks like jsnell in 0.9.9.12, but maybe he got that code from James Bielman 02:57:49 yup, that's the ticket. 02:59:01 I wonder how long it takes the git mirror to update 03:02:07 <= 1 hour 03:02:37 hey, I've got an idea! what if we switched from sf.net's to cvs to somebody else's git repo? 03:03:15 if the cvs outage had gone on a few days longer then we might have :( 03:12:32 or maybe if more people had commented on that pretty concrete proposal that went up on the list (: 03:14:46 -!- hargettp [~hargettp@96.237.121.111] has quit [Quit: Leaving...] 03:39:40 echo-area [~user@114.251.86.0] has joined #sbcl 03:52:09 hrm... I wonder if that fixed the sb-after-xc-core heisenbug as well. 04:17:01 hm 04:17:08 stassats [~stassats@wikipedia/stassats] has joined #sbcl 04:17:12 isn't it safe to free NULL? 04:17:52 I thought the standard explicitly defined that as a no-op 04:25:31 slyrus: that doesn't seem to be clang, but llvm-gcc 04:25:54 oh, my bad 04:26:17 clang doesn't yet compile sbcl without a couple of patches 04:26:45 has anyone tried to use pcc? :) 04:26:46 lp 658414 04:26:47 https://bugs.launchpad.net/bugs/658414 04:27:10 but i don't know how correct they are, though seem to work 04:27:57 actually, ecl with pcc might be interesting 04:28:22 though i suppose i might commit the CC part 04:28:24 joshe: oh, yeah, it's been a long time since I've had to look at any C code :) 04:30:09 and, no, this doesn't fix the sb-after-xc-core heisenbug :( 04:31:36 oops, I keep forgetting how fast this machine is 04:31:56 *stassats* wants a machine which builds SBCL in less than a minute 04:32:14 then i'll admit that it's the 21st century already 04:32:24 nonthreaded x86-64 1.0.47.1 still builds and finishes tests fine with xcode 3 04:35:56 if only sbcl building process could be parallelized 04:51:31 threaded x86-64 1.0.47.1 still builds fine with xcode 3 04:52:02 there's tons of test failures in thread.impure.lisp but maybe that's normal? 04:52:25 patches gratefully accepted :) 04:53:35 I don't even have time to fix sbcl on the os that I actually use :( 04:54:50 anyway, the (nonthreaded) ppc build with code 3 should be done tomorrow 04:55:10 code 3? 04:55:16 *xcode 3 04:55:17 xcode 3, got it 04:55:34 yeah, I'll fire off a 10.4.11 xcode 2.4 build here too 04:56:22 if someone lets me know what it's been decided to upload for darwin release builds then I can do the same for ppc 06:04:32 -!- slyrus [~chatzilla@adsl-76-254-45-145.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 240 seconds] 06:08:38 slyrus [~chatzilla@adsl-76-254-45-145.dsl.pltn13.sbcglobal.net] has joined #sbcl 06:17:37 -!- slyrus [~chatzilla@adsl-76-254-45-145.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 246 seconds] 06:19:58 slyrus [~chatzilla@adsl-76-254-45-145.dsl.pltn13.sbcglobal.net] has joined #sbcl 06:26:03 flip214 [~marek@2001:858:107:1:219:d1ff:fe07:e073] has joined #sbcl 06:26:03 -!- flip214 [~marek@2001:858:107:1:219:d1ff:fe07:e073] has quit [Changing host] 06:26:03 flip214 [~marek@unaffiliated/flip214] has joined #sbcl 06:57:15 nikodemus [~nikodemus@cs181199216.pp.htv.fi] has joined #sbcl 06:57:15 -!- ChanServ has set mode +o nikodemus 07:22:48 morning nikodemus 07:24:33 morning 07:35:44 homie` [~levgue@xdsl-78-35-172-43.netcologne.de] has joined #sbcl 07:37:49 -!- homie [~levgue@xdsl-78-35-159-187.netcologne.de] has quit [Ping timeout: 252 seconds] 07:44:23 tcr [~tcr@92.58.136.182] has joined #sbcl 07:53:31 -!- tcr [~tcr@92.58.136.182] has quit [Ping timeout: 246 seconds] 08:26:33 -!- Krystof [~csr21@csrhodes.plus.com] has quit [Read error: Operation timed out] 09:06:39 attila_lendvai [~attila_le@catv-80-98-24-21.catv.broadband.hu] has joined #sbcl 09:06:39 -!- attila_lendvai [~attila_le@catv-80-98-24-21.catv.broadband.hu] has quit [Changing host] 09:06:39 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 09:55:56 stassats` [~stassats@wikipedia/stassats] has joined #sbcl 09:56:59 -!- stassats [~stassats@wikipedia/stassats] has quit [Read error: Operation timed out] 10:07:21 hargettp [~hargettp@96.237.121.111] has joined #sbcl 10:22:04 slyrus: your 1.0.47.1 fix worked just fine :) 10:28:45 slyrus: nice work finding the memory stompage 10:31:06 -!- hargettp [~hargettp@96.237.121.111] has quit [Quit: Leaving...] 10:36:49 hargettp [~hargettp@96.237.121.111] has joined #sbcl 10:37:04 color me impressed :) 10:39:40 stassats [~stassats@wikipedia/stassats] has joined #sbcl 10:39:49 -!- stassats` [~stassats@wikipedia/stassats] has quit [Ping timeout: 240 seconds] 10:41:02 slyrus: re %get-image-dimensions. (alexandria:type= '(integer 0 255) '(unsigned-byte 8)) => T, T ; just in case it allows you to simplify code 10:45:11 stassats` [~stassats@wikipedia/stassats] has joined #sbcl 10:45:23 (mod 256) is shorter 10:45:58 sure. point was that TYPE= let's you easily compare types reasonably portably 10:46:30 oh, that's what %get-image-dimensions is doing 10:46:32 though looking at the code it should not really care about the second element of the type designator at all 10:46:41 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 276 seconds] 10:48:48 type designator being (simple-array ) -- either it should check that the eltype is just what it wants with type=, or it should just check that it's a simple-array or whatever and not worry about the element type 11:14:44 Krystof [~csr21@csrhodes.plus.com] has joined #sbcl 11:14:44 -!- ChanServ has set mode +o Krystof 11:20:23 after doing (time (defparameter *list* (make-array 200000000 :initial-element 1))) three times, TIME says 0 bytes consed on the third time 11:22:58 is that because GC happens before TIME calculates consed bytes after evaluation? 11:23:29 though it doesn't say about GC happening 11:30:12 -!- flip214 [~marek@unaffiliated/flip214] has quit [Remote host closed the connection] 11:38:41 -!- nikodemus [~nikodemus@cs181199216.pp.htv.fi] has quit [Ping timeout: 240 seconds] 11:40:41 nikodemus [~nikodemus@cs181199216.pp.htv.fi] has joined #sbcl 11:40:41 -!- ChanServ has set mode +o nikodemus 11:47:10 -!- hargettp [~hargettp@96.237.121.111] has quit [Quit: Leaving...] 11:51:29 flip214 [~marek@2001:858:107:1:20c:6eff:feb5:e2d0] has joined #sbcl 11:51:29 -!- flip214 [~marek@2001:858:107:1:20c:6eff:feb5:e2d0] has quit [Changing host] 11:51:29 flip214 [~marek@unaffiliated/flip214] has joined #sbcl 12:29:21 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has left #sbcl 12:45:53 -!- homie` [~levgue@xdsl-78-35-172-43.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 12:55:29 homie [~levgue@xdsl-78-35-172-43.netcologne.de] has joined #sbcl 12:57:06 gor[e] [U2FsdGVkX1@79.165.187.105] has joined #sbcl 12:58:18 -!- gor[e] [U2FsdGVkX1@79.165.187.105] has quit [Client Quit] 12:59:43 gor[e] [U2FsdGVkX1@79.165.187.105] has joined #sbcl 12:59:52 quit 12:59:59 -!- gor[e] [U2FsdGVkX1@79.165.187.105] has quit [Client Quit] 13:01:44 gor[e] [U2FsdGVkX1@79.165.187.105] has joined #sbcl 13:06:17 -!- gor[e] [U2FsdGVkX1@79.165.187.105] has quit [Client Quit] 13:13:59 dlowe [~dlowe@ita4fw1.itasoftware.com] has joined #sbcl 13:46:36 tcr [~tcr@92.58.136.182] has joined #sbcl 14:06:59 -!- tcr [~tcr@92.58.136.182] has quit [Quit: Leaving.] 14:18:25 hargettp_ [~hargettp_@dhcp-162.mirrorimage.net] has joined #sbcl 14:31:24 tcr [~tcr@92.58.136.182] has joined #sbcl 14:38:17 -!- echo-area [~user@114.251.86.0] has quit [Remote host closed the connection] 14:39:45 -!- tcr [~tcr@92.58.136.182] has quit [Quit: Leaving.] 14:46:49 -!- flip214 [~marek@unaffiliated/flip214] has quit [Remote host closed the connection] 14:46:57 tsuru [~charlie@adsl-87-47-213.bna.bellsouth.net] has joined #sbcl 14:46:58 tcr [~tcr@92.58.136.182] has joined #sbcl 15:12:22 hi 15:12:29 Hello. 15:12:41 would any committer update asdf from 2.010 to 2.014? 15:13:17 2.010 is a bit old. there have been a few sbcl-specific fixes, plus robustness things, since 15:22:30 does sbcl have a functional run-program on windows? 15:48:32 AIUI, someone put some effort into making run-program work on windows, but I have no idea if it still does, or how well it does. 16:06:47 slyrus: no new darwin/ppc regressions with 1.0.47.1 16:13:10 -!- hargettp_ [~hargettp_@dhcp-162.mirrorimage.net] has quit [Remote host closed the connection] 16:16:29 good! 16:17:18 so, should I revert the bogus non-null check before freeing runtime_path? 16:17:29 -!- stassats` [~stassats@wikipedia/stassats] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 16:20:42 ... why? 16:27:57 i got an email sort of complaining about it. The fact that free(NULL) is supposed to work seems stupid to me, but the C folks never asked me... 16:30:08 You know why the did it that way, right? Laziness! 16:32:34 slyrus: it's in the C99 standard :D 16:32:50 C99? Better not rely on it, then! 16:33:26 Hunh. Just saw something "weird" in the CLIM spec. (defgeneric invoke-with-drawing-options (medium continuation &key) (declare (dynamic-extent continuation))). 16:33:47 that... what? 16:34:21 Now, clearly, CONTINUATION is meant to be a function here, most likely a closure. 16:34:56 My first question is, is declaring the parameter to be dynamic-extent here conceptually correct? 16:35:08 yes, that's CLIM likes to do with closure names 16:35:43 ... and my second question was if SBCL actually does the right thing with it, but it can't. 16:35:47 I'm not sure if that's the right way to do it... but it might be there just to make the intent clear 16:35:59 And the example (CLIM 2.9) doesn't rely on it, either. 16:36:24 Since it also creates the closure using FLET and declares it to be dynamic-extent in the body of the FLET as well. 16:36:39 Which is the signal that SBCL pays attention to. 16:37:34 which also makes sense 16:37:49 but... declaring dx in the method again? not really 16:38:13 It might make sense if it were part of the ftype. 16:41:41 We could argue that the CONTINUATION passed to INVOKE-WITH-DRAWING-OPTIONS should be of type (FUNCTION (MEDIUM)) or similar. 16:41:58 Oh well. 16:43:39 I think it's so that in e.g. (invoke-with-drawing-options ... (lambda (x) ...)) the lambda can be stack-allocated 16:43:42 conceptually, anyway 16:44:07 That's the impression I get as well, but is it defined to work that way per CLHS? 16:45:25 (I know it doesn't work that way in SBCL, but that's because of stuff related to USE-GOOD-FOR-DX-P not being set up right for such things.) 16:46:33 And that's only the first level of why it doesn't work; there's more lurking under there and it just doesn't seem worth sorting through at this point. 16:53:58 Okay, I'm going to argue that declaring a generic-function parameter to be dynamic-extent in such a way is useless in any manner other than as documentation. 16:54:30 Because dynamic-extent is a bound declaration, and it can't propagate to the caller unless the function is declared inline. 17:10:21 rmarynch [~roman@88.135.194.233] has joined #sbcl 17:22:09 -!- tcr [~tcr@92.58.136.182] has quit [Quit: Leaving.] 17:26:44 -!- Fare [~Fare@64.119.159.126] has quit [Ping timeout: 240 seconds] 17:57:04 Fare [~Fare@63.115.78.49] has joined #sbcl 18:29:59 -!- peddie [~peddie@XVM-107.MIT.EDU] has quit [Read error: Operation timed out] 18:37:38 -!- rmarynch [~roman@88.135.194.233] has quit [Quit: Leaving] 18:39:45 peddie [~peddie@XVM-107.MIT.EDU] has joined #sbcl