00:19:08 -!- milanj [~milanj_@178-223-158-248.dynamic.isp.telekom.rs] has quit [Quit: Leaving] 00:34:19 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Quit: Leaving.] 00:45:39 -!- Blkt [~user@82.84.182.166] has quit [Quit: good night...] 00:58:18 nikodemus_: I'll be on a cafeine purge after my predoc defence on friday, but I'll try to merge in the new merge sort and smarter constants. 01:45:24 -!- Qworkescence [~quad@unaffiliated/quadrescence] has quit [Quit: Leaving] 02:00:24 homie` [~levgue@xdsl-78-35-140-14.netcologne.de] has joined #sbcl 02:02:35 -!- homie [~levgue@xdsl-87-79-195-126.netcologne.de] has quit [Ping timeout: 260 seconds] 03:22:44 Quaydon [~aaaaaaa@cpe-071-068-114-143.carolina.res.rr.com] has joined #sbcl 03:23:58 chp [~user@c-68-45-180-238.hsd1.nj.comcast.net] has joined #sbcl 03:30:58 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Quit: Leaving] 03:31:11 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 05:02:36 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 05:40:00 -!- chp [~user@c-68-45-180-238.hsd1.nj.comcast.net] has quit [Remote host closed the connection] 06:47:45 sdemarre [~serge@91.176.87.217] has joined #sbcl 07:12:15 angavrilov [~angavrilo@217.71.227.181] has joined #sbcl 07:14:02 akovalenko [~akovalenk@95.73.50.134] has joined #sbcl 07:15:28 -!- sdemarre [~serge@91.176.87.217] has quit [Ping timeout: 248 seconds] 07:21:57 Kryztof [~user@81.174.155.115] has joined #sbcl 07:21:57 -!- ChanServ has set mode +o Kryztof 07:58:49 pon1980 [~pon@195.67.88.105] has joined #sbcl 08:34:08 ASau` [~user@95-27-132-224.broadband.corbina.ru] has joined #sbcl 08:38:04 -!- ASau [~user@89-178-106-102.broadband.corbina.ru] has quit [Ping timeout: 244 seconds] 09:36:15 -!- antgreen [~user@bas3-toronto06-1177890745.dsl.bell.ca] has quit [Ping timeout: 248 seconds] 11:03:29 nikodemus [~nikodemus@188-67-8-52.bb.dnainternet.fi] has joined #sbcl 11:03:29 -!- ChanServ has set mode +o nikodemus 11:44:36 -!- angavrilov [~angavrilo@217.71.227.181] has quit [Ping timeout: 240 seconds] 12:00:34 angavrilov [~angavrilo@217.71.227.181] has joined #sbcl 12:09:50 -!- angavrilov [~angavrilo@217.71.227.181] has quit [Ping timeout: 252 seconds] 12:15:02 angavrilov [~angavrilo@217.71.227.181] has joined #sbcl 12:26:21 -!- homie` [~levgue@xdsl-78-35-140-14.netcologne.de] has quit [Read error: Connection reset by peer] 12:27:27 homie` [~levgue@xdsl-78-35-140-14.netcologne.de] has joined #sbcl 12:29:18 -!- homie` [~levgue@xdsl-78-35-140-14.netcologne.de] has quit [Read error: Connection reset by peer] 12:31:18 -!- drdo [~user@85.207.54.77.rev.vodafone.pt] has quit [Remote host closed the connection] 12:44:46 homie [~levgue@xdsl-78-35-140-14.netcologne.de] has joined #sbcl 13:00:15 snafuchs [~foobar@care.boinkor.net] has joined #sbcl 13:33:50 -!- homie [~levgue@xdsl-78-35-140-14.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 13:53:07 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 14:31:49 nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has joined #sbcl 14:32:19 G'morning all. 14:44:54 -!- nikodemus [~nikodemus@188-67-8-52.bb.dnainternet.fi] has quit [Quit: This computer has gone to sleep] 14:48:04 nikodemus [~nikodemus@188-67-8-52.bb.dnainternet.fi] has joined #sbcl 14:48:04 -!- ChanServ has set mode +o nikodemus 14:51:55 Hunh. Forgot to test non-unicode builds. 14:54:22 Heh. Forgot we had them. Are many folks using them? 14:55:48 ITA occasionally likes them. 14:56:00 Really? Interesting. 14:56:33 Well, they're faster for certain operations, especially if you either don't care about non-ascii external formats or are willing to deal with the noise yourself. 14:56:50 They're also smaller, since strings aren't as wide. 14:58:43 *redline6561_* nods 15:01:08 someday, somewhen, when i have the time, i will orthogonalize the following build options: (1) base-char: ascii or latin1 (2) disjointness of character types (3) unicode support ie. characters are wide (4) array nil: strings or not 15:01:34 Wait, what's the benefit of number four? 15:02:54 it makes a crapload of string operations unsure of if they have a sane argument or not. especially if you otherwise collapse types so that there's only a single /sane/ simple-string, you'll still be dispatching at runtime because it could be (simple-array nil (*)) 15:03:10 Oh, and I'm thinking to add a bit to shared or make-host-1 to check for various combinations of features that are mutually exclusive / dependent, and issue errors early if something is about to break. 15:03:23 +1 15:04:13 Mmm. I never want to wonder why I'm seeing an error building thread.c when I'm accidentally trying to build a threaded cheneygc target. 15:06:59 *nyef* has three full builds going on right now, for two different patches both targeting the same test. 15:07:27 ... And they're probably going to finish building in LIFO order. 15:10:01 Winnage on x86-64. 15:20:37 Winnage on x86, one of the patches is good. 15:21:23 ... and the PPC is still in host-2. 15:24:13 wbooze [~wbooze@xdsl-78-35-130-8.netcologne.de] has joined #sbcl 15:27:57 homie [~levgue@xdsl-78-35-130-8.netcologne.de] has joined #sbcl 15:29:35 -!- Quaydon [~aaaaaaa@cpe-071-068-114-143.carolina.res.rr.com] has quit [Ping timeout: 255 seconds] 15:35:47 Hrm. half a win on PPC. 15:37:32 ? 15:42:05 Getting a stunted backtrace. 15:42:34 Which is probably not new, really. 15:43:36 You know what'd be a really nice win? If we could get the name of the undefined function into the backtrace. It should be available /somewhere/ in the register set... 15:51:17 -!- wbooze [~wbooze@xdsl-78-35-130-8.netcologne.de] has quit [Quit: Client Quit] 15:58:29 Greetings. I built the latest SBCL on my 32-bit Ubuntu x86 netbook last night and saw two unexpected test failures: BACKTRACE-INTERRUPTED-CONDITION-WAIT and BUG-309448. The second test looks flaky ... it passed when I ran it a second time. 16:00:22 reb````: Thank you for the report. BUG-309448 is known to be fragile... and BACKTRACE-INTERRUPTED-CONDITION-WAIT appears to fail due to some limitation of our backtrace implementation on 32-bit x86. 16:02:16 ... does anyone know why (undefined-function bug-346) is listed as failing on x86-64/freebsd? 16:03:09 (The answer I'm looking for here is specifically not "because it fails on x86-64/freebsd".) 16:04:26 -!- pon1980 [~pon@195.67.88.105] has quit [Quit: Leaving.] 16:07:59 i vaguely remember unprecise addresses in sigill. 16:08:15 (or sigtrap) 16:08:18 But that might have been back in 5.4. 16:08:37 That's... vaguely familiar. Don't we have something similar on darwin? 16:08:58 Don't we have a build-time option to switch from sigtrap to sigill for our error traps? 16:09:31 it must be a special case though, because the rest of our error handling works fine on that platform. 16:09:59 Lovely. 16:10:20 Well, I'm not going to worry about it to the point of setting up an FBSD VM to test with. 16:11:04 I'll try building on a fresh fbsd after this friday. Not having to support 5.4 let us really simplify our signal handler code; it might all just work now. 16:20:19 wbooze [~wbooze@xdsl-78-35-130-8.netcologne.de] has joined #sbcl 16:22:16 we use sigill because darwin sometimes just ran right across INT 3 16:22:46 Yes, I know. 16:22:47 is restore-tls-segment-register-from-tls somehow relevant for the wait-on-semaphore things ? 16:22:57 Did we ever sort out if it runs right across the single-step flag? 16:23:07 i don't know 16:23:18 without the tls thing, there's no error for wait-on-semaphore, with tls there is 16:23:43 Do you still have an old enough darwin to test with, if I put a patch together on Lion? 16:24:04 snow leopard still 16:24:17 Right. Maybe this weekend, then. 16:24:50 homie: stop toggling random features and editing base-target-features.lisp 16:25:19 no i enabled the tls thing via customize-target-features.lisp this time 16:25:37 didn't touch base-target-features.lisp 16:26:08 Hrm. Invalid exit status: stream.impure.lisp. 16:27:07 homie: "stop toggling random features" 16:28:29 Qworkescence [~quad@unaffiliated/quadrescence] has joined #sbcl 16:36:50 leuler [~user@p549055D5.dip.t-dialin.net] has joined #sbcl 16:38:41 Hi everybody. 16:39:04 Hello leuler. 16:51:14 hi 17:05:49 afternoon 17:06:02 -!- wbooze [~wbooze@xdsl-78-35-130-8.netcologne.de] has quit [Quit: Client Quit] 17:08:50 Hrm. "Don't know how to use a DEBUG-SOURCE without a namestring or a form"? 17:12:06 Happens on x86oids, too! 17:38:17 apropos nothing: two issues with non-encap trace on darwin. (1) starting single-stepping gives us EXC_BREAKPOINT, which we don't handle -> boom (2) since our breakpoint sequence is 18 bits long, we never manage to restore it since after single-stepping -- we need to single-step twice before we can restore it 17:39:09 Heh. Lovely. 17:42:04 i wonder if we should just use INT3 for actual breakpoints (as opposed to error traps) on darwin too 17:42:21 Unreliable delivery, remember? 17:43:02 How did we get an 18 bit long instruction sequence on any backend? 17:47:44 -!- reb```` [user@nat/google/x-qurgoiodkpqzlcym] has quit [Remote host closed the connection] 17:54:35 unreliable delivery um, pre-tiger? 17:55:02 um, sorry, 24 17:55:09 math is hard 17:55:50 i just located cyrus' old test-case 17:56:46 Does anyone even still have tiger on x86oids? 17:59:00 probably not, and the update is pretty cheap even if they do 17:59:02 brown` [user@nat/google/x-spiyzwsgrvbgxnxu] has joined #sbcl 17:59:16 not like m$ 17:59:35 So, ditch ud2-breakpoints by default? 17:59:41 the old test-case runs here just fine at least 17:59:45 Well, not -now-, but early next cycle? 17:59:56 maybe 18:00:15 ud2-breakpoints may have its use, so please don't hurry to remove it altogether.. 18:00:15 i'm all for it happening, but i'm not sure i have the cycles 18:00:59 definitely not entirely as error traps, but using them for non-encap trace has never worked, so that part should probably be removed entirely 18:01:06 *akovalenko* once found that "gdb-ability" of SBCL improves greatly when ud2-breakpoits is enabled on windows.. 18:01:18 indeed! 18:01:46 i mean, i'm ok even using them by default for error traps 18:02:10 it's just the broken breakpoint stuff that bothers me 18:03:29 Should I reopen 851177 and 824974, or open new bugs for them? They both still fail at (debug 2). 18:05:17 reopen 18:06:21 ok, looky! i found some of my old PCL benchmarks i used when working on the method cache 19:04:16 antgreen [user@nat/redhat/x-gxgtpdebemcazhmc] has joined #sbcl 19:05:08 wbooze [~wbooze@xdsl-78-35-130-8.netcologne.de] has joined #sbcl 19:05:11 hellooooo 19:05:13 oh 19:05:21 i see my lines in this channel too 19:05:30 weird weird weird 19:06:51 wbooze: Watch it turn out to be a bug in cl-irc. 19:07:46 -!- nikodemus [~nikodemus@188-67-8-52.bb.dnainternet.fi] has quit [Quit: This computer has gone to sleep] 19:09:16 oh ok thank you nyef, good to know 19:09:30 Know what? 19:09:35 What's good to know? 19:09:41 That cl-irc is involved, somehow? 19:10:00 that it is a bug in cl-irc, and not some of my config files or so..... 19:10:16 I'm not saying that it is a bug in cl-irc, just that it might be. 19:10:33 Seriously, you're a programmer. Treat it as if it's a bug SOMEWHERE, and try to figure out where. 19:11:38 ok 19:11:52 Slap a protocol monitor on the wire. Trace the input dispatcher in cl-irc. Figure out how text that you send to a channel gets to the screen in those cases where it does get to the screen. 19:12:59 they all get to the screen it seems, the problem is displaying them in my beirc client (to me) 19:13:05 And then just give up and use XChat. d-: 19:13:12 cause i can see my messages via erc/emacs 19:14:06 on some channels i see my messages blue (and the client side works, shows me my messages in blue), and on other channels i see a gray line where i put a message .... 19:14:35 i just don't get why all of a sudden it got blue, i never specified blue..... 19:14:51 i made all message-display.lisp ink colors black actually.... 19:14:56 -!- Kryztof [~user@81.174.155.115] has quit [Ping timeout: 248 seconds] 19:15:27 Mmm. So, treat it as a debugging problem. What is the mechanism by which this effect occurs? 19:16:26 nothing!...start (beirc:beirc) with my customizations already in place, those customizations seem to be overloaded/ignored somehow.... 19:16:47 So, find the mechanism! 19:18:01 How does channel text go from beirc to mcclim? 19:18:24 It's probably going to be FORMAT, PRESENT, or one of the OUTPUT-RECORD functions. 19:18:31 (if (string-equal "localhost" (irc:host message))) ? 19:18:51 cause the only +blue+ thing i see there 19:19:03 Might be plausible. 19:19:30 I'm completely unfamiliar with beirc, btw. 19:20:25 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Read error: Operation timed out] 19:25:31 -!- wbooze [~wbooze@xdsl-78-35-130-8.netcologne.de] has quit [Quit: Client Quit] 19:29:15 homie: apropos, trace, ed are your friends. Also, this conversation would be better held in #lisp. 19:30:47 wbooze [~wbooze@xdsl-78-35-130-8.netcologne.de] has joined #sbcl 19:34:01 wtf, redline6561_ i don#t see your message in beirc at all..... 19:34:34 ok 19:39:36 kwmiebach [kwmiebach@31-222-138-133.static.cloud-ips.co.uk] has joined #sbcl 19:55:43 joshe [~joshe@opal.elsasser.org] has joined #sbcl 20:18:30 -!- samebchase [~samuel@76.73.121.203] has quit [Remote host closed the connection] 20:25:43 -!- wbooze [~wbooze@xdsl-78-35-130-8.netcologne.de] has quit [Quit: Client Quit] 20:34:03 nikodemus [~nikodemus@188-67-8-52.bb.dnainternet.fi] has joined #sbcl 20:34:03 -!- ChanServ has set mode +o nikodemus 20:39:41 -!- angavrilov [~angavrilo@217.71.227.181] has quit [Ping timeout: 252 seconds] 20:40:56 wbooze [~wbooze@xdsl-78-35-130-8.netcologne.de] has joined #sbcl 20:59:44 -!- wbooze [~wbooze@xdsl-78-35-130-8.netcologne.de] has quit [Remote host closed the connection] 21:12:24 sdemarre [~serge@91.176.87.217] has joined #sbcl 21:19:53 Quaydon [~aaaaaaa@cpe-071-068-114-143.carolina.res.rr.com] has joined #sbcl 21:22:24 -!- akovalenko [~akovalenk@95.73.50.134] has quit [Ping timeout: 248 seconds] 21:40:00 samebchase [~samuel@76.73.121.203] has joined #sbcl 21:40:49 -!- nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has quit [Quit: G'night all.] 21:50:53 -!- Quaydon [~aaaaaaa@cpe-071-068-114-143.carolina.res.rr.com] has quit [Read error: Connection timed out] 22:03:01 Have I missed any changes in tests? 22:03:20 I'm removing the third impure test in order to get it finished. 22:04:06 They all seem to stick after the last test in file. 22:08:12 -!- antgreen [user@nat/redhat/x-gxgtpdebemcazhmc] has quit [Remote host closed the connection] 22:21:58 akovalenko [~akovalenk@95.73.53.213] has joined #sbcl 22:30:19 -!- nikodemus [~nikodemus@188-67-8-52.bb.dnainternet.fi] has quit [Quit: This computer has gone to sleep] 22:34:33 -!- sdemarre [~serge@91.176.87.217] has quit [Ping timeout: 244 seconds] 22:57:10 chp [~user@NYUFGA-WLESSAUTHCLIENTS-03.NATPOOL.NYU.EDU] has joined #sbcl 23:00:11 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Quit: Leaving.] 23:09:40 do you consider keywordp foldable? 23:10:04 (unintern :some-temporary-keyword) ?? 23:10:41 yeah. 23:12:51 problem is, we use keywordp in SATISFIES test. 23:13:06 and if it's not foldable, we break half our type system 23:25:41 uninterning keywords breaks a lot of assumptions 23:25:46 like, that they're constants. 23:28:07 pkhuong: no, it doesn't. The former keyword is still a constant, bound to itself. 23:29:26 well, if we imagine some evil background thread that is always interning and uninterning random keywords, then no correct code could depend on the ability to unintern them.. 23:29:39 akovalenko: it's not a constant if I can change its symbol-value. 23:29:46 and you can't 23:29:52 I can. 23:29:59 unintern and you'll see. 23:30:20 if you can in SBCL, it's probably wrong 23:32:51 Kryztof [~user@81.174.155.115] has joined #sbcl 23:32:51 -!- ChanServ has set mode +o Kryztof 23:32:58 well, not exactly _wrong_, 'cause "it becomes a constant variable" means that an attempt to setf it causes undefined behavior.. 23:33:17 Kryztof: our keywords are broken. Can I break them further by assuming that keywordp is foldable? 23:33:40 why hello 23:33:49 there's a difference between (typep x 'keyword) and (keywordp x) 23:34:04 if I remember rightly, anyway 23:34:39 yes, interned vs home-package 23:34:52 we don't seem to think so. 23:34:58 really? 23:35:14 we have (sb!xc:deftype keyword () '(and symbol (satisfies keywordp))) 23:35:17 wait, who is "we"? "people" or "sbcl" 23:35:18 oh, right 23:35:30 yeah, well, even pfdietz didn't write a test to exercise the difference, so... 23:35:46 clhs-wise, keywordp returns true for keywords, and keyword is defined from home-package.. 23:36:07 yeah, our keywords are broken. 23:36:12 but (typep x 'keyword) only checks to see whether x is interned 23:36:14 oh, "type keyword" mentions interning 23:36:15 is that the only breakage? 23:36:40 I can unintern a symbol and setf its symbol-value. 23:36:45 *unintern a keyword 23:36:59 so constantp lies. 23:36:59 I miss this -- the arrival back on IRC after a drunken evening out to have difficult questions that no-one cares about (except pjb :-) fired at me 23:37:32 I would be happy with breaking keywords some more, and then doing what they meant by forbidding all the random broken things that one can do with keywords to expose the brokennesses 23:37:34 I just want to mark keywordp as foldable because, frankly, you deserve to suffer. 23:38:06 or, I'd like to know where we check for keyword-ness in arg list parsing, because that seems really broken to me. 23:38:18 right, let's have a YOU-DIDNT-MEAN-THAT condition on importing random symbols into KEYWORD and uninterning from KEYWORD and things like that 23:39:46 oh, wtf. We actually assume keywordp is foldable... via define-type-predicate. 23:40:26 oh, it's all eric's fault 23:40:45 yes. 23:41:33 You guys figure it out, I'm all for marking keywordp as foldable, and not caring about why exactly we assert some values to be keywords. 23:42:07 I say we mark keywordp as foldable and forbid certain operations on the keyword package 23:42:15 k. 23:43:26 woah. it is foldable. 23:43:35 I don't believe that the intent of the oh-so-careful specifiers was to distinguish between keywordp and the keyword type; I think it's more likely that no-one thought that messing with the keyword package was even conceivable 23:43:40 oups, wrong tree. now it is. 23:44:14 "The KEYWORD package contains symbols, called keywords[1]" for example 23:47:07 What about sequencep? (: 23:48:33 extended sequences are sbcl-specific extension, so forbidding class redefinitions that would alter sequencep for existing objects is okay 23:49:16 "forbidding" may be just "documenting it as undefined behavior", at least in the beginning.. 23:49:33 we have a bunch of (define-type-predicate ...), and some of them fold at the type level predicates that we don't fold on values. 23:50:01 akovalenko: it's a simple matter of adding a check to cl:unintern 23:50:11 it's not necessarily wrong, just strange, mostly. 23:50:31 what about sequencep? what have I done? 23:50:43 can it be folded? 23:51:47 sequencep's an internal function anyway. I'd say yes in any case; if you somehow manage to make a thingy that isn't a sequence yet but you change-class it later to a sequence, or redefine the class hierarchy so that it suddenly is a sequence, you deserve to lose 23:51:58 Even if the focus has changed, concerning keywords: cliki "Proposed ANSI Revisions and Clarifications" has an entry "Issue KEYWORD-TYPE". 23:52:12 I might have written that entry 23:52:13 anyway, it's a red herring, but an interesting one 23:52:44 -!- chp [~user@NYUFGA-WLESSAUTHCLIENTS-03.NATPOOL.NYU.EDU] has quit [Remote host closed the connection] 23:52:56 you could probably get 99% of the benefit of a foldable sequencep with a sequencep transform that converted to t for lists and vectors, and nil for built-in-classes 23:53:59 Kryztof: foldable has impact on the type system 23:54:57 for typep tests, or for subtypep? 23:55:02 subtypep 23:55:16 no, just typep 23:55:31 but then with the singleton type logic, it's a bit blurry 23:55:35 ..what I would expect from a perfectly-literal-implementation w.r.t keywords: (1) when interned the normal way, they become constants (as in defconstant); (2) when imported into KEYWORD package while they're homeless, they aren't constants; (3) when uninterned, normall keywords remain constants, (4) keywordp just checks home package and is not foldable. 23:55:51 Another mind bender I'm not in any shape for: is it safe to pretend that an uninhabited type is habitated by an arbitrary single value? 23:56:32 as it (typep *my-hidden-thing* nil) => T ? 23:56:55 pkhuong: that's basically the basis for hbaker's implementation of subtypep 23:56:58 no. (type-singleton-p '(and (satisfies [never]) (eql 42))) -> 42 23:57:05 so there's at least a good history 23:59:20 hmm. something like (sb-int:truly-satisfies ...) typespec may be a good thing..