00:00:26 Still, sounds remarkably cludge on Windoze part. 00:01:00 Is there an inherit logic to all of this? 00:01:10 Yes. 00:01:19 I'm gone for a few minutes for dinner. 00:01:25 Time to hit the books again? 00:01:43 In the presence of something like SEH, native conventions need to be respected. You can't effect a non-local transfer of control through other means and expect the native system to be happy about it. 00:01:51 I'll be around later unless a beautiful random girl knocks on my door :-) 00:02:41 in the meantime i'll read up on the obscure parts of Windoze i no longer understand 00:03:09 Also, the "Windoze" thing gets old very quickly. 00:03:14 If you don't like it, don't use it. 00:04:37 Way back kn the late 80's I was a (broke) teenage and young adult. When windows came on the scene and liberated us from 640K, I was 00:06:26 a huge fan, and still have a sh*t load of Windows reference and how/to books. Around 1990 I switched to Linux and enjoyed its virtues, but now I'm agnostic. For my compiler I using an assebler that runs on both Windows and Linux. Of course the RTS shared library will be a duzy for each :-) 00:07:45 Switching to Linux in 1990 is a feat. 00:08:09 Not many people can claim to have used Linux before Linus! 00:09:14 Wasn't so hard. At harvard i worked at HUSC working part time one the Unix manual. And then my first job I worked on a small Sun with Sybase. 00:10:09 Oh, I may have the data wrong by a year or two. MY CFS destroys my sense of time in a pretty radical way. 00:10:53 Yeah, that should read about ~1999 rather. 00:11:24 Ah. 00:11:27 Linux - wonderful uptimes; we had boxen up for literally years. 00:11:57 19:10:16 up 920 days, 11:01, 1 user, load average: 0.02, 0.62, 0.53 00:12:37 Also a highly transparent and configurable system - thank good for the text file (or code file ala emacs) base configuration for nearly everyting!!! 00:12:46 (And that was a power failure that drained the battery, if I remember correctly.) 00:13:00 chandler: Goo for you! Uptime is a blessing :-) 00:13:20 Yes; having to remember 65536 different random, brain-damanged configuration file syntaxes is quite an advantage. 00:13:33 ?? 00:14:00 I'm not fond of "text file" configuration formats. I prefer a structured and uniform format. Emacs is much closer. 00:14:20 Are you imply a universal scheme base config file system for *nix would be ideal? 00:14:31 i more or less agree. 00:15:02 I'm implying that detonating the traditional "everything is a blob of newline-delimited bytes" philosophy of UNIX from high orbit would be a good idea. 00:15:13 I suppose guile started out in this direction, but i can't follow it's current direction 00:15:42 chandler: yes a good idea 00:16:27 Instead the dreaded XML is slowly making in roads into the the config languages for new apps. 00:17:36 It's not so bad if folks actually define schemas for the config file. In about ten years we'll finally have schema-derived smart editors for those configuration files, and everything will be back to where it should have been from the get go. 00:18:02 XML is an awful format for anything but text markup, but it's better than no or random structure. 00:18:04 sounds a little like VMS :-0 00:19:10 s-expr could have a fighting chance if Lisp/Scheme really promoted keyword arguments, including required keyword arguments. (this is a features of my tNL language - useless plug0 00:19:23 Okay, I'm back. 00:19:30 Welcome 00:19:43 And, minor note, Windows SEH is derived from the VMS version of the same. 00:19:54 I'm enjoying a Manhattan lunch - coffee and a cigarettle ;-0 00:20:16 Well that's Dave Cutler at work I suppose 00:20:18 ... It's past 8 pm in Manhattan. 00:20:18 Virtually every OS of sufficient complexity ends up with a typed registry-like system anyway. Windows, of course, has the infamous registry. OS X has NSDefaults. GNOME has GConf. KDE has somethingorother with a pointless K in the name. 00:20:36 No it's 4:40 EST 00:20:39 Heh. Yeah, that's KDE for you. 00:20:59 I'm not sure what time zone you're in, but it's 20:20 in Manhattan. 00:21:00 My clock, which is a few minutes off, says 20:19 EDT. 00:21:04 Yeah, but why does the registry suck so badly ? 00:21:48 I'm in Washington, DC EST also 00:22:18 oh crap - you're right - it's 8:40 I read the clock wrong 00:22:23 It's not the right time of year for EST, you know. 00:22:34 ?? 00:22:50 EST is for when we're not on daylight savings time. 00:22:51 Daylight savings time issue? 00:23:04 Gothca - another name? 00:23:12 palter [n=palter@c-24-128-76-188.hsd1.ma.comcast.net] has joined #ccl 00:23:12 Too few types, and too little structure. The only important differences between the Windows registry and OS X's NSUserDefaults is that the latter has more types (integers, strings, booleans, arrays, and dictionaries), and that it splits application defaults into individual files that are named by Java-style names.style.dns.reverse . 00:23:12 Eastern Daylight Time. 00:24:02 For no good reason, I prefers something like Gelertner's "tuple spaces" as the structure for the registy. 00:24:43 ok, so EDT does the job during daylight saving time? 00:25:58 Just a thought - this must be the longest ccl irc chat in quite a while :-) 00:27:43 Okay, dug up one of my old test programs, and it looks like just using CallWindowProc establishes an SEH frame. 00:28:08 Whew! What in the h*ll for ? 00:28:38 Don't know, but it's either for error handling or resource cleanup. 00:29:09 SEH frame establishment isn't all that expensive, though it's cheaper on x64 than win32. 00:29:32 Aha, the latter shouldn't present major problems should it? OTOH, it might be wound up to catch running message loops on another thread - boo 00:29:58 There's an example in ccl:examples;mswin.lisp that creates a window and does some limited event handling. 00:30:30 rme: Yeah, but what happens if you stick a (break) in the window procedure and from the debugger throw back to toplevel? 00:30:41 Intersting - why cheaper on x64? 00:30:46 I guess one test would be to try THROWing out of the callback. 00:31:21 I know that on SBCL before I fixed things the lisp process died, but it's clear that the vectored exception handler stuff fires before the done-fell-over from a blown SEH stack. 00:31:48 *rme* starts a Windows box 00:31:48 Or even a lexically scoped target via (block here ....) 00:31:51 Summermute: Because on x86 it's table-based on a stack walk, not an explicit chain of established frames. 00:31:59 Err... x64. 00:32:32 Oh that's very cool. 00:32:36 *nyef* hasn't managed to completely override the x + two digits -> x86 thing yet. 00:32:55 Seems like x84 is the way to go for new compiler work for lots of reasons. 00:33:13 Very cool, and something that a few people would like to see in SBCL, but relies on a few things that SBCL doesn't provide. 00:33:20 mdc_ [n=mdc_mobi@ds9.entity.com] has joined #ccl 00:33:22 -!- mdc_mobile [n=mdc_mobi@ds9.entity.com] has quit [Read error: 104 (Connection reset by peer)] 00:33:26 whoop x86 00:33:27 I don't know if CCL does anything along those lines. 00:33:40 You mean x64, surely? 00:33:50 -!- mdc_ is now known as mdc_mobile 00:33:54 gosh x64 - whew, I'm out of it 00:34:18 do you mean ccl is 32 bit only? 00:34:25 No. 00:34:32 good 00:34:36 What do you mean then 00:34:47 But the win32 ABI doesn't do table-based unwind. 00:35:14 windows x64 does, as does almost all non-win32 C++ ABIs. 00:35:31 So ccl will execute x64 instructions but still used the Win32 abi? 00:35:50 ... No, and I don't know how you managed to get that from what I said. 00:36:23 Oh, I vaguely see how that confusion might have occurred. 00:36:24 Remeber I'm two sheets to the wind on some prescrbed pharms - sorry 00:36:57 So what's the real lay of the land here? 00:37:32 If I break in the window procedure, and throw to top-level, the window title says "... (Not Responding)" and the window had an hourglass cursor. 00:38:04 oh, you mean without closing the window first? 00:38:20 rme: Hrm. Do you have an easy way to pick out the current value of the top SEH frame ([FS:0])? 00:38:42 I though Windows and message loops were thread specific? 00:39:09 HWND message handling is thread-affine, yes. 00:39:12 I could write a trivial little LAP function to do that. 00:40:12 That might help - otherwise a throw to the top level thread can leave the window "abandoned" (just conjection, read about windows internal way to long ago) 00:40:24 "conjecture" 00:41:04 Summermute: Not actually the case. What I'm more worried about is that when you're -not- using a vectored exception handler and the SEH chain gets screwed then your entire -process- goes away. 00:41:27 A throw to toplevel isn't a big deal if you can re-enter your message loop. 00:41:39 So long as the SEH frame stack isn't deranged. 00:42:55 Very interesting - exception handling can be useful, but it's also a huge pain in the ass. Gives me more thoughts for my own language design. 00:43:57 BTW, you're not doing the equivalent of a longjmp are you? So the SEQ structures (or references to them) are still on the stack yes? 00:44:59 Whoop again - SEQ not 'SEQ' 00:45:28 Actually, I rather expect that CCL -is- doing the moral equivalent to a longjmp for unwind through foreign frames. 00:45:29 um sincerest apologies SEQ => SEH 00:46:39 Interesting - honoring unwind-protect cleanup and exception "catchers" along the way I presume? 00:47:27 Summermute: That's the question. Certainly honoring lisp UWPs, but I don't know about win32/windows x64 native SEH. 00:49:01 Well, that's certainly a bit OUCH. Why not submit a formal bug report. Have you dowloaed the WinDbg tools and taken a close look at the behavior? 00:49:58 My current inquiry is to discover if there is a bug 00:50:10 Hence, a bug report would be premature. 00:50:23 You're doing the Lord's work :-0 00:50:31 For that matter, I don't even have an installed CCL system. 00:51:07 Again, the free WinDbg tools on a ccl binary might well get to the heart of the matter quickly. 00:51:58 nyef: ??? Big whoops. It installs like a total charm - no fuss, no muss. 00:52:09 Heck, if I installed CCL I could probably hack up the SBCL test cases I wrote ages back to test precisely this. 00:52:59 It's just an svn co away! 00:53:10 I just replace a few (like 2) lines of sbcl slime setup in my .emacs file to point to ccl.exe and it just worked like a charm. 00:53:36 rme: That's a fair point... And I even have svn installed for some reason. 00:53:50 Is there a test suite beyond the copy of ansi-tests in the svn tree? 00:53:57 I run Quack simultaneously for PLT schem and i'v found zero conflicts 00:54:23 I was lazy and just installed to .msi windows installer. 00:54:24 No tests besides the (augmented) ansi-tests in the tree. One runs the tests with (test-ccl). 00:55:37 That seems to be a bit... misleading, unless you're not testing ccl-specific extensions? 00:56:09 With the relatively frequent plt updates, it would take 1/3 of my time just building lisp environments - and on windows with MingW and all sorts of required utilities and what not - pain in the **Butt** 00:57:39 Man, I always forget that svn diff doesn't cross externals. "Why has nothing changed?!" 00:57:48 nyef: there's a ccl-specific set of tests in ansi-tests;ccl.lsp, so I guess it's kind of mis-named now. 00:57:55 BTW - GCL (not a great lisp) does it right - installs all necessary utilities and "(compile-file "foo.lisp")" just works right out of the box. Wish other distribution were just as convenient. 00:58:25 sellout: I check out svn+ssh://svn.clozure.com/usr/local/publicsvn/openmcl/trunk/source 00:58:44 then I copy interfaces and a lisp kernel and heap image into that. no more externals. 00:59:16 (That is for ccl developers only; no need for users to do that, please.) 01:00:02 It strikes me that just having one file for ccl-specific tests is... unmaintainable in the long term. 01:00:04 rme: Ah yeah ... I always just go through changing the svn repo urls. Heh 01:00:32 And having the ccl-specific tests mixed in with the generic ansi-tests is an invitation for further maintainance problems. 01:02:31 Research/dev types always want to focus on the hard interesting problesm and totally ignore the low hanging fruit for improving their product. 01:03:18 And I speak from experience as a former hard core dev type ;-) 01:04:19 Heh. Yeah, we keep expecting that someone else will come along and polish the rough edges. 01:07:00 That said, there are only four bugs in SBCL's tracker tagged as os-windows, so things can't be all bad there... Even if there's a major known issue not listed, one of the bugs has to do with unwind-protect and one involves true nastiness around the I/O system. 01:07:01 Worth communicating to the forum and mailing list. I did so on the PLT list and got some really good feedback. I might even be recruited 01:07:31 to do some research and design work regarding end user programminer usability. 01:10:51 So... how hard is it to re-target the CCL compiler to a new CPU? 01:14:12 It seems to take about 4--6 months. 01:16:15 But I'm sure rme fixed all sorts of things, so it'd be cake for someone to do a new port ;) 01:16:25 I don't suppose there's any documentation on how to do so, or retrospectives from previous porters? 01:17:42 I have some notes. I've been meaning to put them together. I'll find some time if you're interested. 01:19:22 I'm more idly curious than interested. 01:20:19 I'm rather heavily invested in SBCL, after all. 01:20:33 Of course. 01:22:24 A big job on x8664 was the assembler, I understand. 01:22:37 For a more rational target, that'd be a lot easier. 01:23:16 I find the cross-compilation instructions at http://trac.clozure.com/openmcl/wiki/PortToIA-32 to be a bit scary. 01:24:13 That was in the middle of a port, though. 01:25:37 Still scary, to be honest. 01:26:19 Well then, someone will have to put some work into making those instructions less scary for you then. And while we're at it, we'll give your concerns about how we maintain our test suite all the consideration that they're worth. Do you have any other concerns ? 01:27:21 Heh. Good response. 01:27:27 nyef: I think the lack of bugs for SBCL on Windows has more to do with the fact that nobody's using it. 01:27:38 chandler: Quite possibly. 01:27:38 Obvious response ... 01:32:31 gbyers: So, I have just one question for you before I bow out for the evening. Do you know if CCL interoperates with win32 SEH properly, or should I dedicate some time tomorrow to putting together a proper test case to determine if it does or not? 01:33:30 It makes no effort to do so, so I'd be shocked if it accidentally did. 01:37:11 Fair enough. I'll try actual experimentation tomorrow, I guess. 01:37:14 Whether SEH is involved or not, throwing out of a callback isn't something that people should do casually. SEH introduces stuff to clean up (its own frames) and a framework for running handlers, but just throwing "past" foreign code isn't the smartest thing to do. 01:37:52 psismondi [n=user@d24-150-10-209.home.cgocable.net] has joined #ccl 01:38:34 In an uncontrolled scenario, I'd agree with you. But the same argument applies to throwing "past" lisp code as well. 01:39:45 Obviously. We do the whole song and dance (both sides of it) to interoperate with ObjC exceptions, but don't currently even try to deal with SEH. 01:42:10 Mmm. One of the SBCL bugs is that I messed up part of the song-and-dance for Win32 SEH, and I'm still drawing a blank on fixing it properly. 01:42:13 psismondi: PONG to you too. 01:42:40 I'm rather impressed with what CCL does in terms of running on windows, though. 01:42:44 hey there. 01:43:03 just dropped in for the first time to see if this is a good place to get some ccl answers - don't want to intrude 01:43:14 Definately a different approach than what I did for SBCL. 01:43:24 psismondi: The whole-channel PING was a good way to intrude, though. 01:43:39 sorry - new to irc - won't do it again. 01:44:10 -!- psismondi [n=user@d24-150-10-209.home.cgocable.net] has left #ccl 01:44:36 Whoops. 01:45:13 sensitive 01:45:15 palter_ [n=palter@c-24-128-76-188.hsd1.ma.comcast.net] has joined #ccl 01:45:16 "Live and learn, die and forget. Unless you're an expert system." 01:45:24 Guy had a fistful of cash and was looking to hire CL contractors. Oh well. 01:48:19 Are CCL hash tables completely thread safe for both readers and writers? 01:48:39 chandler: yep 01:48:42 yes. 01:48:49 Ah, just found the internals document on it. 01:49:21 Nice. 01:50:15 Okay, I'm disappearing for the evening. Hopefully tomorrow I'll see about a proper set of tests for SEH behavior. 01:51:31 OK, thanks, but I don't think that it's a high priority for us to deal with SEH at the moment. 01:52:37 Is there an exposed CAS-style operation? (Forgive me if I'm missing something in the documentation.) 01:53:03 Hash tables must be one of the hairiest things in the lisp. Or maybe I just think that because when I was working on the x8632 port, I worked for weeks trying to cons a hash table. 01:53:56 -!- palter_ [n=palter@c-24-128-76-188.hsd1.ma.comcast.net] has left #ccl 01:54:03 There are several, all funky and none (AFAIK) documented. CLX wants a CONDITIONAL-STORE, and there's something that's slightly exposed for its benefit. 01:54:11 palter_ [n=palter@c-24-128-76-188.hsd1.ma.comcast.net] has joined #ccl 01:55:23 MAKE-HASH-TABLE does a little bit of FP arithmetic, and a little bit of rational arithmetic, and is usually the first thing that exercises that stuff in a new port. 01:55:24 chandler: Adlai was playing with a CAS earlier today, I think ... 01:55:48 (for CCL) 01:56:16 sellout: he's been working on it for a while. I don't know if he's gotten around to writing that latest version after he figured out what was wrong... 01:56:22 Ah, I just found that in the logs. 01:56:42 The general case of CAS is weird for a few reasons (having to do with the GC, threads, and interrupts.) 01:56:58 Without special lisp runtime support, I don't think it's possible to do a CAS for lisp objects. 01:58:02 Can you elucidate some of the reasoning behind that? 02:00:54 on x8664, "cmpxchg" uses %rax as an implicit operand: you generally load the contents of a memory location into %rax, then try to store a new value there, and the conditional store works if the location still contains the value in %rax. If the GC runs between the load and the cmpxchg, the memory location's value may change but the value in %rax (presumed to be a non-lisp value) won't change. 02:01:24 In CCL, a gc can happen at any instruction boundary. CCL's gc thinks it always knows if a register contains a lisp object ... what he said. 02:04:44 Ah. Having only dealt with this at a C level, I never noticed. 02:07:05 Presumably some sort of thread state could be updated around the instruction, with a worst case that the old value is incorrectly marked as alive. (Or I suppose the GC could look back an instruction and handle cmpxchg cases specially.) 02:07:20 rme and I walk around saying "... but if a GC happens here, we're screwed." It may be a curse. 02:07:32 Heh. 02:07:34 For a good time (not) read pc_luser_xp() in ccl:lisp-kernel;x86-exceptions.c 02:10:34 I'll have a look when I'm not IRCing from my phone. 02:11:00 We do the problematic cmpxchg's in a few known locations in the lisp kernel, and that function recognizes when a thread gets stopped in the middle of one of those sequences and backs up/moves forward as appropriate. 02:15:21 We also do the generational write-barrier stuff in software, so if a cmpxchg succeeds, it may have just stored a pointer to a young object in an old object. We need to set a bit to indicate a possible intergenerational reference, and the store and the bit-setting have to appear to be atomic. 02:18:29 Mm. Sounds like a use for DCAS. Too bad that's confined to the world of theory for the most part. 02:23:13 palter__ [n=palter@c-24-128-76-188.hsd1.ma.comcast.net] has joined #ccl 02:23:13 -!- palter [n=palter@c-24-128-76-188.hsd1.ma.comcast.net] has quit [Read error: 104 (Connection reset by peer)] 02:23:13 -!- palter_ is now known as palter 02:41:12 bfulgham_ [n=brent@adsl-69-234-114-78.dsl.irvnca.pacbell.net] has joined #ccl 02:49:19 -!- palter__ [n=palter@c-24-128-76-188.hsd1.ma.comcast.net] has quit [] 03:03:15 -!- palter [n=palter@c-24-128-76-188.hsd1.ma.comcast.net] has quit [] 03:10:14 -!- rme [n=rme@pool-70-105-85-54.chi.dsl-w.verizon.net] has quit [] 03:30:05 sellout- [n=greg@c-24-128-50-176.hsd1.ma.comcast.net] has joined #ccl 03:47:43 -!- sellout [n=greg@c-24-128-50-176.hsd1.ma.comcast.net] has quit [Read error: 113 (No route to host)] 03:47:43 -!- sellout- is now known as sellout 04:15:22 -!- mdc_mobile [n=mdc_mobi@ds9.entity.com] has quit [Read error: 104 (Connection reset by peer)] 04:16:10 mdc_mobile [n=mdc_mobi@66.92.71.19] has joined #ccl 04:58:11 -!- pem [n=pem@159.226.35.246] has quit [Remote closed the connection] 05:54:02 -!- bfulgham_ [n=brent@adsl-69-234-114-78.dsl.irvnca.pacbell.net] has quit [] 05:57:25 pem [n=pem@159.226.35.246] has joined #ccl 07:51:09 -!- gz [n=gz@209-6-18-72.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com] has quit [Read error: 60 (Operation timed out)] 09:42:02 gz [n=gz@209-6-18-72.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com] has joined #ccl 12:00:13 -!- alms [n=alms@146.115.42.237] has quit [] 12:09:49 -!- pem [n=pem@159.226.35.246] has quit [verne.freenode.net irc.freenode.net] 12:09:49 -!- mdc [n=mdc@ds9.entity.com] has quit [verne.freenode.net irc.freenode.net] 12:09:49 -!- sykopomp [n=root@unaffiliated/sykopomp] has quit [verne.freenode.net irc.freenode.net] 12:10:11 pem [n=pem@159.226.35.246] has joined #ccl 12:10:11 sykopomp [n=root@unaffiliated/sykopomp] has joined #ccl 12:10:11 mdc [n=mdc@ds9.entity.com] has joined #ccl 13:06:17 anRch [n=markmill@nmd.sbx09984.woburma.wayport.net] has joined #ccl 13:43:52 regarding CAS: I've actually not spent a lot of time on this. If you want to see what I've done so far, check the logs for this channel, I posted a link yesterday (or maybe the day before) 13:53:48 palter [n=palter@static-72-85-235-154.bstnma.east.verizon.net] has joined #ccl 14:13:53 alms [n=alms@static-72-85-235-154.bstnma.east.verizon.net] has joined #ccl 14:19:46 -!- anRch [n=markmill@nmd.sbx09984.woburma.wayport.net] has quit [] 14:27:41 -!- sellout [n=greg@c-24-128-50-176.hsd1.ma.comcast.net] has quit [] 14:39:58 milanj [n=milan@93.86.21.167] has joined #ccl 14:43:50 anRch [n=markmill@nmd.sbx07812.woburma.wayport.net] has joined #ccl 14:55:23 sellout [n=greg@static-72-85-235-154.bstnma.east.verizon.net] has joined #ccl 15:17:23 rme [n=rme@pool-70-105-85-54.chi.dsl-w.verizon.net] has joined #ccl 16:08:18 -!- anRch [n=markmill@nmd.sbx07812.woburma.wayport.net] has quit [] 16:27:13 -!- alms [n=alms@static-72-85-235-154.bstnma.east.verizon.net] has quit [] 16:46:35 -!- palter [n=palter@static-72-85-235-154.bstnma.east.verizon.net] has quit [] 16:46:50 anRch [n=markmill@ip-64-7-14-173.bos.megapath.net] has joined #ccl 16:49:39 palter [n=palter@static-72-85-235-154.bstnma.east.verizon.net] has joined #ccl 17:04:21 -!- milanj [n=milan@93.86.21.167] has quit ["This computer has gone to sleep"] 17:27:26 -!- anRch [n=markmill@ip-64-7-14-173.bos.megapath.net] has quit [] 17:28:44 leo2007 [n=leo@cpc1-cmbg13-0-0-cust936.cmbg.cable.ntl.com] has joined #ccl 17:54:36 alms [n=alms@static-72-85-235-154.bstnma.east.verizon.net] has joined #ccl 21:21:48 -!- palter [n=palter@static-72-85-235-154.bstnma.east.verizon.net] has quit [] 21:33:06 milanj [n=milan@93.87.167.128] has joined #ccl 21:34:00 -!- rme [n=rme@pool-70-105-85-54.chi.dsl-w.verizon.net] has quit [] 21:40:31 -!- leo2007 [n=leo@cpc1-cmbg13-0-0-cust936.cmbg.cable.ntl.com] has quit [Read error: 110 (Connection timed out)] 21:46:37 anRch [n=markmill@nmd.sbx07258.melroma.wayport.net] has joined #ccl 21:50:00 -!- alms [n=alms@static-72-85-235-154.bstnma.east.verizon.net] has quit [] 21:58:05 leo2007 [n=leo@cpc1-cmbg13-0-0-cust936.cmbg.cable.ntl.com] has joined #ccl 22:18:08 -!- sellout [n=greg@static-72-85-235-154.bstnma.east.verizon.net] has quit [] 22:34:44 -!- anRch [n=markmill@nmd.sbx07258.melroma.wayport.net] has quit [] 22:43:42 sellout [n=greg@c-24-128-50-176.hsd1.ma.comcast.net] has joined #ccl 23:04:13 -!- milanj [n=milan@93.87.167.128] has quit ["Leaving"] 23:14:38 BTW - GCL (not a great lisp) does it right - installs all necessary utilities and "(compile-file "foo.lisp")" just works right out of the box. Wish other distribution were just as convenient. 23:14:50 Whoops 23:15:20 Q: Does this mean ccl does a conservative scan of the registers? 23:15:29 Summermute: CCL has a precise GC 23:16:07 thus, each register effectively has a type assigned to it -- either it's a "node" (lisp object), or it's a sub-lisp value. The GC takes this into account. 23:16:10 Just noting rme's comment above 23:16:40 Sort of like a stack frame descriptor? But maybe compressed to the limited possibilities? 23:17:12 these types are hardwired into CCL 23:17:52 Hardwired? Via lowbit tags or something/ 23:17:55 Hardwired? Via lowbit tags or something/? 23:18:23 no, hardwired via "RAX is always an immediate register" 23:18:31 Aha! 23:18:43 palter [n=palter@c-24-128-76-188.hsd1.ma.comcast.net] has joined #ccl 23:18:45 Interesting strategy 23:18:59 I'm actually not entirely clear why that makes cmpxchg a problem, but it does. 23:19:20 does it mean that the GC uses RAX and thus clobbers its value during a GC? 23:19:37 I guess it does 23:19:50 We'll I presume it must use one or two registers at least 23:20:12 right, but it should restore them after the GC is complete 23:20:35 but maybe just using it could cause problems with the way I wrote CAS 23:20:58 And values of type X would have to stay put in their registers - oh yeah, unless moved thoughfully by the GC 23:21:22 this type information isn't Lisp types 23:21:22 in any case, this scheme would make the register allocateor easier ;-0 23:21:30 there are only two options -- lisp object, or immediate 23:21:41 Presumably 'meta types' related to storage class, yes? 23:21:48 Right 23:21:58 I've never heard the term "meta type" before (altohugh I've heard metaclass) 23:22:15 just typing off the cuff 23:23:03 So at a gc safepoint, CCL makes sure that the two storage types are safe at home in their preassigned registers? 23:23:25 in this case, a lisp object means somethnig where a few bits are lisp type information -- ie, 000 means a fixnum, 011 means a cons cell, etc. 23:24:03 I'm well aware of tagging schemes - I'm a low two bit man myself :-) 23:24:12 no, it doesn't make sure of that, which is why the consing routine has to include magic numbers, and my cmpxchg fails randomly 23:24:37 Hmmmm - consing routine, pray tell more 23:25:11 consing routine = (disassemble 'cons) 23:25:39 without knowing more, seems odd 23:27:02 well, it means that the GC knows whether every quadword (in the case of 64-bit) it finds in a register or on the heap is a lisp object or an immediate value 23:27:30 some Lisps don't do it this way, and as a result, they have less precise GCs 23:28:10 Sure, so whence the 'dissasemble cons' issue? 23:28:49 rme [n=rme@pool-70-105-85-54.chi.dsl-w.verizon.net] has joined #ccl 23:29:22 if the GC runs while another thread is in the middle of consing, the GC shouldn't do something funny like deallocate that cons 23:30:12 Reading my mind - sounds like a parallel GC. Darned hard to get right. 23:30:30 rme: can you explain to Summermute the whole business about some registers being lisp nodes and others being immediates? I don't think I've done a very good job. 23:31:07 http://ccl.clozure.com/ccl-documentation.html#Register-usage-and-tagging 23:31:18 No, I've got that part (implemented a CL some 20 years back - no parallel GC though ;-) 23:32:04 There's no such thing as a defined GC safepoint in CCL. A GC can occur at any instruction boundary. 23:32:16 I guess that means that everywhere is a gc safepoint. 23:32:36 rme: or rather, that everywhere has to be a gc safepoint. 23:32:44 There you go - I was going to recommend that at a GC safepoint the currently running thread take responsibility for the register set. 23:33:40 Maybe even the topmost stack frame depending upon how "loosey goosey" its format is. 23:33:55 Adlai, that's why your usage of cmpxchg loses. If %rax contains a node, the gc won't know that and will not forward it or treat it as a root. 23:34:20 rme: yeah, I understand that now. 23:34:29 Sounds like a big fat GC bug to me. 23:35:43 The gc may indeed have bugs, but that's not one of them. 23:35:48 Summermute: It's not a GC bug, it's a bug with my CAS code. 23:36:07 I translated SBCL's algorithm, basically opcode-by-opcode 23:36:07 GC + Thread Switch safe points is a "more conservative" way to go 23:36:30 Whoops - ignorance again, 'CAS' ? 23:36:36 yep, that's why we say of SBCL that it's got a conservative GC 23:36:39 compare-and-swap 23:36:53 At the asm level? 23:36:58 there's a decent description of it in the docstring for sb-ext:compare-and-swap 23:37:02 yep 23:37:21 Ah 23:37:41 ie, it'd basically be a wrapper for cmpxchg 23:37:54 the versions which I wrote work as long as the GC isn't running, which means that they fail randomly. 23:38:45 Well, I've taken a shinging fot ccl lately as my CL complement to PLT for my scheme, so maybe I'll be back with the same bug someday ? 23:39:13 *Adlai* wonders what a "shinging fot" is, and where he can get one too. 23:39:18 Anyway to briefly pause GC in CCL? 23:39:56 Sorry, I'm taking some (legit) medicine that messes me up - "shining to ccl" should read 23:40:00 Summermute: nope. I think the way consing is handled is that the GC recognizes when a thread is mid-consing, finishes the cons, and advances the thread's instruction pointer before continuing. 23:40:34 oh, this "bug" only comes up if you try to write inline assembly code for CCL before knowing how it's GC works. 23:40:59 Hm, that's a bit of a shame - I can think of many circumstances to briefly turn off the gc, especially when bit twiddling. 23:42:15 But then, pretty much any CL is light years again of most scheme implementations walking down that road 23:42:40 well, CCL makes it pretty easy to write GC-safe asm 23:42:51 it aliases the registers by their "type" 23:43:09 I'll have to look it up in the CCL docs when I get to it. 23:43:49 OH - My original questions - is there are a reasonable high quality lex/yacc available for ccl - not porting muss or fuss? 23:44:27 Or parser-combinators or whetever (with good docs) would do just as well 23:45:34 I've heard of cl-yacc, but I don't know a thing about it. 23:45:49 Rings a bell 23:46:31 One of the nice things about PLT Scheme is a lex/yacc that works right out of the box and is implemented mostly in macros for interactive use. Yumm. 23:47:00 But PLT isn't winning any speed records anytime soon :-) 23:47:36 -!- palter [n=palter@c-24-128-76-188.hsd1.ma.comcast.net] has quit [] 23:47:41 Summermute: it's very simple. When you write inline asm in CCL, rather than using rax etc, you use register aliases like arg_x and imm1 23:47:57 Caoi for now - it's been educational. 23:48:05 bye 23:59:05 Adlai: you asked earlier on #lisp about inlining svref. (I'm just reviewing irc logs now.) 23:59:18 rme: read the entire discussion, as I was confused at first.