02:07:56 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 256 seconds] 02:18:50 stassats [~stassats@wikipedia/stassats] has joined #sbcl 02:52:00 homie` [~levgue@xdsl-78-35-143-146.netcologne.de] has joined #sbcl 02:53:50 -!- homie [~levgue@78.35.190.31] has quit [Ping timeout: 260 seconds] 03:05:23 -!- Krystof [~user@81.174.155.115] has quit [Ping timeout: 260 seconds] 04:08:30 -!- homie` [~levgue@xdsl-78-35-143-146.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 06:01:44 sdemarre [~serge@91.176.68.211] has joined #sbcl 07:27:15 Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has joined #sbcl 07:30:32 oiiii [~oiiii@82.71.241.25] has joined #sbcl 07:35:53 good morning everyone 08:21:36 Krystof [~user@81.174.155.115] has joined #sbcl 08:29:33 attila_lendvai [~attila_le@80.98.25.142] has joined #sbcl 08:29:33 -!- attila_lendvai [~attila_le@80.98.25.142] has quit [Changing host] 08:29:33 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 09:24:01 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 276 seconds] 09:41:12 akovalen` [~user@95.73.109.170] has joined #sbcl 09:43:11 -!- akovalenko [~user@95.73.107.178] has quit [Ping timeout: 248 seconds] 10:39:31 stassats [~stassats@wikipedia/stassats] has joined #sbcl 12:44:23 -!- loke [~elias@bb115-66-85-121.singnet.com.sg] has quit [Remote host closed the connection] 12:51:54 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has left #sbcl 13:25:56 -!- akovalen` is now known as akovalenko 13:30:10 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 13:49:22 -!- antgreen [~user@70.50.67.27] has quit [Remote host closed the connection] 14:21:08 nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has joined #sbcl 14:28:45 -!- oiiii [~oiiii@82.71.241.25] has quit [Remote host closed the connection] 15:01:19 antgreen [~user@70.50.67.27] has joined #sbcl 15:12:42 tsuru` [~user@c-68-53-57-241.hsd1.tn.comcast.net] has joined #sbcl 15:43:31 hargettp [~hargettp@pool-71-184-177-139.bstnma.east.verizon.net] has joined #sbcl 16:01:13 -!- Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has quit [Quit: going to Tuscany!!!] 16:09:30 -!- slyrus [~chatzilla@adsl-99-62-136-133.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 260 seconds] 16:22:14 slyrus [~chatzilla@adsl-99-62-136-133.dsl.pltn13.sbcglobal.net] has joined #sbcl 16:51:27 -!- slyrus [~chatzilla@adsl-99-62-136-133.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 252 seconds] 17:27:11 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 248 seconds] 17:32:40 slyrus [~chatzilla@adsl-99-62-136-133.dsl.pltn13.sbcglobal.net] has joined #sbcl 17:37:11 <_8david> so... SBCL testing on weird RISC platforms emulated by qemu is less fun than I had imagined. 17:37:44 So I found out some time ago. Far more fun to have an actual weird RISC box. 17:38:28 <_8david> Compilation on PPC sort of works, except that after a looong time, the qemu progress just disappeared. Currently on test run No. 2, hoping that it's not reproducable. 17:39:11 ... I should be able to at least /try/ to do a PPC build in about another week. 17:39:59 <_8david> SPARC is a sad situation; Debian stopped supporting 32bit kernels after etch, and a fresh installation of Linux on qemu-system-sparc64 doesn't seem to be supported. 17:41:04 At least 32-bit PPC systems are easy enough to come by these days. 17:41:10 No RAM, but... 17:42:07 Actually, that could be an interesting embedded-core target. 17:46:37 Gamecubes or something? 17:47:08 redline6561: Good guess, although the Wii is easier to get with a network interface. 17:47:44 Good point. :) 17:49:40 (gamestop values the network interface at something like a penny, but the nearest one in stock isn't in the continental US.) 17:56:35 -!- slyrus [~chatzilla@adsl-99-62-136-133.dsl.pltn13.sbcglobal.net] has quit [Read error: Connection reset by peer] 17:56:53 slyrus [~chatzilla@adsl-99-62-136-133.dsl.pltn13.sbcglobal.net] has joined #sbcl 17:57:49 -!- antgreen [~user@70.50.67.27] has quit [Remote host closed the connection] 18:11:10 seems like etypecase doesn't pick up the extra type info... is that the case? shall I report it in launchpad? with my naivity I'd expect that to be a basic feature of type inference... 18:11:42 I'm doing some simple-base-string/string optimization and an etypecase would be a readable implementation... 18:23:03 attila_lendvai: Are you accounting for (array nil)? 18:24:14 nyef: you got me. what is (array nil)? 18:24:42 I don't care about funny strings if it's about that... 18:24:48 (stringp (make-array 0 :element-type nil)) => t 18:25:09 attila_lendvai: type inference does care about funny strings => hence the problem 18:25:32 (vector character) == "non-base unfunny string" 18:26:28 nyef: no, but I'll leave the debugging of that for people who construct strings that way... :) 18:27:20 attila_lendvai: Mmm. Remember how non-unicode builds were broken for a quite a while last year? 18:27:20 akovalenko: don't know... if I rewrite it into two functions, and declaring the second one's input as simple-base-string, then the notes are gone. I'd expect the same in the appropriate branch of an etypecase... 18:27:41 nyef: thanks for the headsup though! 18:28:10 Hrm. etypecase isn't propagating type information? That's... not quite right. 18:29:48 with my lack of detailed knowledge about all the string corner cases, I may be overlooking something. but that's what seems to be the case... 18:29:57 nyef: it propagates, but if you have (simple-base-string) clause first, and (simple-string) second, (vector nil) is a possible type for the second clause 18:30:13 argh, right 18:30:29 *attila_lendvai* tests 18:31:56 adding a (vector nil) branch doesn't seem to change the number of notes in the later s-b-s branch 18:32:43 attila_lendvai: do you add (vector nil) branch _before_ simple-string ? 18:33:03 yes 18:33:07 hmm 18:33:11 well, simple-base-string 18:33:33 I only dispatch on s-b-s and string 18:33:39 could you share that code? 18:34:06 *attila_lendvai* creates a standalone test-case 18:34:12 ..it should be (s-b-s )..(vector nil)..(simple-string) 18:34:38 ..or (vector nil).. (s-b-s )..(simple-string) 18:37:44 *attila_lendvai* notes that it's more complicated than the clean situation described above 18:41:24 attila_lendvai: we have string-dispatch to hide that ugliness. 18:44:04 http://paste.lisp.org/display/125165 18:44:53 somehow the labels is needed. if I get rid of them, or call it only once, then the note is gone that input's element type is not known at compile time. so it's not really etypecase... 18:45:22 note though the check-type weirdness... I'd expect it to be a nop, but it changes the number of notes. 18:47:06 hmm, nothing changes for me (notes are present, whether check-type is present or not) 18:47:12 it's an interaction between closed-over variables and the fact that check-type assigns to the place. 18:47:50 It basically comes down to the fact that we don't have SSA, and only have something that's both weaker and stronger during constraint propagation. 18:49:20 akovalenko: the number of notes is what is changing. 18:49:55 but it looks like something more substantial than a simple overlooking of something... 18:50:08 what happens is that because INPUT is both closed over (never mind that it's never passed around), and assigned to. 18:50:25 When these two conditions are met, propagation is disabled for the variable. 18:50:46 [hence why it's safe to do type propagation even in the presence of concurrency] 18:51:09 An easy fix is to rebind input after the check-type 18:52:04 that way you get assignments, but only to a local variable, and rebinding between the check-type and labels get you an immutable variable that's safe to close over. 18:52:54 I've annotated the paste with the standalone defun version, which is essentially the same code body with a (delcare (type... )) and it yields no notes 18:53:25 It's too bad we can't mark certain closures as only being synchronously called, and doing appropriate propagation for them. 18:54:05 (declare (inline read-next-char));; => no notes 18:54:16 attila_lendvai: check the paste for annotation. 18:54:25 ..well, no notes in (labels...) body.. 18:54:26 akovalenko: right, if you inline, there's no closing-over happening. 18:55:21 and also note that the check-type is not my main issue... what surprises me is the difference between one branch of a typecase and a standalone function with type declaration 18:55:49 pkhuong: For the curious, would you explain how/why what we have is strong weaker *and* stronger than SSA? 18:55:57 re inlining: that's why the two calls are needed. with a single call it gets inlined 18:56:51 pkhuong: keep an eye on the opportunity to write up a TODO in the repo instead of here getting lost if it's about the same effort. then you can drop the link to the commit here... 18:56:51 redline6561: we split on conditional branches, unlike classical SSA. 18:57:46 redline6561: but all the analyses except constraint propagation work with variables instead of variable-at-program-point 18:58:07 attila_lendvai: I'm just hoping that's not due to my speed-up refactoring from a few months back. 18:58:41 pkhuong: fyi, this is with "1.0.51.27.hu.dwim.9-ad49e42" 19:00:10 *attila_lendvai* ponders that there could be some marker that would run the body inside the context of the compilation, and then tests could be recorded for such things using that primitive 19:00:51 we have debug-only transforms in the test suite 19:01:21 JFYI, a variant with inlined read-next-char (and two calls) is almost twice *shorter* 19:02:22 maybe automatic inlining shouldn't be limited to single use.. 19:13:01 all right. So constraint propagation per-se works. 19:13:23 right. 19:13:39 ... How important is the asynchronous use-case for closures, anyway? 19:13:46 nyef: cl-ppcre ;) 19:14:39 But I'll wager that there's an 80% rule: 80% of the uses for first-class functions are synchronous dynamic-extent. 19:14:42 well, if a closure is neither passed downwards nor upwards.. 19:15:00 akovalenko: ... it gets let-converted. 19:16:08 pkhuong: It's probably more than that, 80% of that last 20% are probably synchronous indefinite-extent. 19:16:09 attila_lendvai: I'm not going to fix this. 19:16:30 nyef: if they're sync, they're dx ;) 19:16:40 pkhuong: no worries, it's not crucial... just thought I raise attention if it's unknown 19:16:49 pkhuong: Umm. I fail to see how. 19:17:32 nyef: perhaps more accurate: "they're dx or you can't really know if they're sync" 19:17:47 Right, that's a little more likely. 19:18:03 Except that you can't know that a dx closure is sync, either. 19:19:39 So, probably 90% or more of closures are sync, and it's the rare few that aren't that cause problems. 19:19:45 attila_lendvai: myeah, I think I can see how to fix this, but at this point I'd rather rewrite the framework. 19:25:54 -!- hargettp [~hargettp@pool-71-184-177-139.bstnma.east.verizon.net] has quit [Quit: Leaving...] 19:26:14 <_8david> Who is up for some code review? 19:27:01 _8david: What do you have? 19:27:33 <_8david> Basically all uses of the FS segment prefix in the backend need to be touched for Windows support. Instead of having #+ #- fun (affecting two forms for each such use!), I'd like to wrap all this in a macro. 19:27:42 <_8david> ... the macro is a little insane though, so please comment. 19:28:08 <_8david> http://www.lichteblau.com/tmp/ea-1.diff (macro introduction) http://www.lichteblau.com/tmp/ea-2.diff (windows support then just plugs in) 19:29:11 Okay, this has always bugged me: Why is the segment-prefix an attribute of the instruction and not an attribute of the EA? 19:29:12 <_8david> Oh, and please do not suggest changes to the macro :-), because I've already hand-inspected all macro expansions on Linux to check that the code after macro expansion is unchanged by this commit. 19:31:19 you mean I'm not allowed to say "subst!? are you insane?!"? 19:31:36 Umm... Does this intersect with TLS-index fixups at all? Did TLS-index fixups even get committed? 19:31:49 oh, I am; I'm not allowed to say "here is a less insane way of doing that". Fine :_) 19:32:02 FWIW, I'm unsure that every use of :fs on windows will be covered 19:32:57 *akovalenko* seems to recall some hairiness that can be hard to reduce 19:33:14 Somewhere in my fork on repo.or.cz is a year-old branch with x86oid disassembler changes, some of which are broken and wrong, but one of which is converting FS-SEGMENT-PREFIX to FS: in the following instruction. 19:33:35 <_8david> akovalenko: if so, those unusual hunks should be all be found in ea-2.diff 19:36:49 <_8david> Krystof: that's just the sort of comment which I was trying to guard against! 19:37:57 <_8david> hmm, I don't recall why I stopped using LET and went for SUBST instead. There was an excuse, possibly a very bad one though. 19:38:36 _8david: they probably are, if only I didn't forget something (allocation.lisp was the first thing I though of) 19:38:42 <_8david> I suppose it made it easier to read the macro expansions. 19:41:19 nyef: well, my horribly old-fashioned e-mail today complained about unreadable FS-SEGMENT-PREFIX stuff everywhere 19:41:32 maybe it's always been like that and I used to build unthreaded stuff so that I could actually read disassembly 19:41:59 Krystof: Yeah, it's always been like that. 19:42:21 ok, so the only remaining mystery is why sleep conses 19:42:36 I think I probably need to commit a non-broken ROUND in any case 19:42:57 <_8david> Krystof: so this hasn't gone in yet? http://sourceforge.net/mailarchive/message.php?msg_id=28038014 19:44:10 no 19:44:15 blame the maintainers 19:44:16 <_8david> (Also, people who get to read disassembly using SBCL at all -- instead of having to use gdb on windows for that task -- ought to count themselves lucky!) 19:44:18 oh wait, that's us 19:44:57 though honestly having a disassembler hint as to what mov [fs:#x5c] actually was would help too 19:45:35 Krystof: http://repo.or.cz/w/sbcl/nyef.git/shortlog/refs/heads/x86oid-disassembler-fixes 19:46:25 <_8david> The 90s called -- they want their build times back: //build started: Fri Oct 7 17:27:48 UTC 2011 //build finished: Fri Oct 7 19:25:11 UTC 2011 19:46:25 I'm fairly sure that's not my most up-to-date version of that tree, and it has bugs in it, but... It does have that hint for the TLS addresses. 19:47:48 ok. Now all I need to do is find time, ideally while jsnell isn't trying to convince us all not to make random changes 19:48:34 I'm hoping to dig up my latest version of that tree (which I /know/ has PPC fixes, or should), and see if I can figure out what state it's in. 19:49:02 wait, do we have threads on ppc linux? 19:49:18 _8david: that is impressively terrible 19:50:04 apparently we do. Huh 19:50:20 Yeah, threading on PPC linux as of 1.0.41.42. 19:50:36 _8david: there's also those of us who have to attach gdb because they can't trust the disassembler. 19:51:02 That was most of what went into 1.0.42, actually. 19:51:11 well, look, you guys, I can play the crusty old geezer too 19:51:29 I have spent a lot of time running cold-init under gdb and reverse-engineering broken instruction sequences 19:51:38 so I too have walked uphill in the snow both ways 19:51:52 it's just that now I am senior enough that you guys do all the uphill snow-walking for me :-) 19:56:34 Hunh. There was quite a bit of work involved in sorting out non-x86oid gencgc. 20:00:11 Oh yeah, and using gdb on cold-init problems? During the Win32 port bring-up, I didn't even /have/ gdb, I wrote my own debugging tool in MSVC. 20:05:25 hargettp [~hargettp@pool-71-184-177-139.bstnma.east.verizon.net] has joined #sbcl 20:06:24 <_8david> akovalenko: what's the specific benefit of moving to a newer version of the WiX tools? 20:07:22 <_8david> I'd like to merge in your changes, but I'm not actually running those scripts myself, so I suppose I'd have to explain to eslaugther why I'm breaking his workflow. 20:08:09 *_8david* was disappointed to find that no version of WiX works in wine 20:08:58 _8david: my point was to make it work on wine, precisely. 20:09:16 <_8david> oh? am I doing it wrong? 20:09:32 Oh dear. You didn't change our handling of the breakpoint exception to work on wine, did you? 20:09:41 _8david: if older (but not newer) wix works for you, than you can help _that other half_ of users.. 20:10:13 My position always was that the wine people already had a test in their test suite that showed that their breakpoint handling was wrong, and thus they should be the one to change, not SBCL. 20:10:15 <_8david> akovalenko: no, neither works for me. Which version have you had success with, and how can I install it? 20:10:33 nyef: I've committed some fixes for breakpoints pretty recently, not sure if they are in _8david's tree 20:11:05 _8david: oh, there is a known issue with WiX and zero-sized files (as in "test-passed") 20:11:41 <_8david> nyef: I don't know anything about breakpoint handling. akovalenko fixed os_validate to work on Wine. 20:12:02 Oh dear. It might have gotten "fixed" long ago, then. 20:12:05 _8david: I make them one-byte-sized before building MSI in my (unpublished) build-everything scripts 20:13:35 <_8david> akovalenko: hmm. I didn't touch this stuff in 3 months, so I don't recall what the issue was. I'll just retry. 20:13:43 Hrm. I wonder if anyone fixed the "last" race condition in the PPC calling convention? 20:20:50 -!- hargettp [~hargettp@pool-71-184-177-139.bstnma.east.verizon.net] has quit [Quit: Linkinus - http://linkinus.com] 20:21:00 hargettp [~hargettp@pool-71-184-177-139.bstnma.east.verizon.net] has joined #sbcl 20:21:44 pom pom pom (disassemble 'sb-unix:nanosleep) pom pom pom 20:21:54 does show %sap-alien and consing even without sb-thread 20:23:08 oh, wait, time-t might be 64-bit. I wonder if we can do 64-bit stuff on the stack 20:23:14 homie [~levgue@xdsl-78-35-174-143.netcologne.de] has joined #sbcl 20:23:19 maybe not without... one of _8david's long-uncommitted hacks 20:23:44 or maybe not 20:24:38 (and here I was initially thinking Krystof was channeling psychedelic teenage j-pop) 20:24:55 (but that would have been "pon pon"/"wai wai") 20:25:36 Heh. "KLUDGE: This relies on N-FIXNUM-TAG-BITS being the same as WORD-SHIFT. I know better than to do this. --AB, 2010-Jun-16" 20:25:39 Krystof: right. 20:26:07 (From 1.0.41.35.) 20:28:51 pkhuong: except that on linux everything is long, not time-t 20:34:56 Hm 20:35:39 recompiling the definition removes all the %SAP-ALIEN stuff 20:37:05 Blame your OPTIMIZE settings? 20:38:24 *akovalenko* suspects #+sb-xc-host influences 20:38:44 is that cross-compiled? 20:39:26 yes, no, maybe 20:39:47 Wow: "repeatedly pressing the power button eventually unlocked the system completely." 20:40:43 I simply observe that putting the definition into a file of its own and compiling and loading it in the warmed-up compiler seems to remove all the %sap-alien stuff 20:40:56 nanosleep is cross-compiled (not by the host CL, that is, but by SBCL compiler running on host CL). 20:41:22 Well... neat. Is this a case of cross-float-infinity-kludge loses again, or something more insidious? 20:42:35 akovalenko: yes 20:42:42 and there are differences in the cross-compiler 20:43:06 but on x86-64 the cross-compilation succeeds in making nanosleep non-consing, and on x86 it does not 20:43:27 or I could be doing something wrong 20:44:00 in the meantime I am going to commit a non-broken ROUND because although nothing works I'm pretty sure that it works less badly than it currently does 21:06:55 -!- sdemarre [~serge@91.176.68.211] has quit [Ping timeout: 248 seconds] 21:16:24 it's not just nanosleep: same deal for unix-pipe 21:17:01 So the obvious next question is, has it always been this way? 21:18:56 looking for build logs now 21:20:19 https://buildd.debian.org/status/fetch.php?pkg=sbcl&arch=i386&ver=2%3A1.0.51.0-1&stamp=1314222637 21:21:56 Hrm. I'm not sure I have a suitably-aged 32-bit x86 SBCL around. 21:22:03 At least, not where I can find it. 21:22:29 csr21@lambda:~$ sbcl --version 21:22:29 SBCL 0.8.20.6 21:22:34 it doesn't start up, mind you 21:22:36 Neat. 21:22:38 Heh. 21:23:24 I've just found an SBCL git tree with a branch called "stupid-setf-tricks", and I have no idea what it does. 21:23:42 nyef: something pretty smart, obviously :) 21:24:35 *akovalenko* realised that we can have dead trees in electronic form now.. 21:25:08 (define-alien-type-method (integer :naturalize-gen) (type alien) 21:25:08 (if (<= (alien-type-bits type) 16) 21:25:31 Looks like the branch starts with removing DO loops in read-modify-write macros. 21:26:00 I wonder why we only naturalize 16-bit integers 21:26:08 <17-bit integers 21:26:13 there is no good way of writing that 21:27:25 ... looks like a lot of my knowledge about SB-ALIEN got garbage collected. 21:27:34 ISTR there was something unexpected with (truly-the fixnum ...) 21:29:45 Okay, stupid-setf-tricks starts off by getting rid of the CLtL1-era machinery that is no longer useful, making a number of functions on multiply-valued places now set extra values to NIL instead of raising an error. 21:30:09 And then it veers off into making complex setf-expander functions better supported in DESCRIBE. 21:30:50 wait a minute 21:31:00 when is src/compiler/target/c-call.lisp xcompiled 21:31:13 no, wait, that shouldn't matter 21:31:27 we host-compile it, then it's available for use 21:33:34 -!- hargettp [~hargettp@pool-71-184-177-139.bstnma.east.verizon.net] has quit [Quit: Linkinus - http://linkinus.com] 21:40:12 Krystof: narrower than 17 bits => there is a need for explicit sign-extension 21:40:38 yes, I found the comment 21:40:57 *akovalenko* figured it out by looking at 64-bit version 21:41:39 there's a comment in src/code/host-alieneval.lisp 21:47:15 no-one puts build logs up on the web any more 21:48:04 invoke-with-saved-fp-and-pc? ISTR there was a commit where this setting (used during sbcl compilation) was changed.. 21:50:43 are unexpected %sap-aliens there before e7b2c507c364da9395ad1f9591210dac44f24afd ? 21:50:44 -!- tsuru` [~user@c-68-53-57-241.hsd1.tn.comcast.net] has quit [Ping timeout: 258 seconds] 21:51:57 I was about to say 21:52:09 on x86 invoke-with-saved-fp-and-pc is for some reason not inlined 21:52:13 whereas on x86-64 it is 21:52:50 or is not called 21:53:36 hm, so that at least I understand: (declaim inline) doesn't do what people think it does in cross-compilation 21:54:29 the (declaim inline) registers an inline expansion in the host compiler, but the cross-compiler has no way of knowing about the expansion 21:55:23 Time to look into altering the XC machinery, maybe? 22:00:53 nah 22:01:02 just rewrite as a defun+deftransform 22:01:48 it's already 4 hours past my bedtime 22:01:53 Fair enough. 22:14:31 bother. That is apparently not enough 22:14:57 Deal with it tomorrow? 22:16:29 ignotus [~ignotus@unaffiliated/ignotus] has joined #sbcl 22:22:29 ah, it is also optimization-quality sensitive 22:23:07 Shouldn't you be asleep already? 22:23:09 "file a bug" might be the right response now :-/ dealing with it tomorrow is unlikely 22:23:14 yes 22:23:32 Krystof: g'night (and no consing while you sleep) 22:24:04 thank you :) 22:37:00 homie` [~levgue@78.35.152.245] has joined #sbcl 22:39:11 -!- homie [~levgue@xdsl-78-35-174-143.netcologne.de] has quit [Ping timeout: 248 seconds] 23:06:18 -!- homie` [~levgue@78.35.152.245] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 23:09:35 -!- nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has quit [Ping timeout: 248 seconds] 23:46:42 tsuru` [~user@c-68-53-57-241.hsd1.tn.comcast.net] has joined #sbcl 23:51:14 -!- tsuru` [~user@c-68-53-57-241.hsd1.tn.comcast.net] has quit [Ping timeout: 260 seconds]