02:00:31 gz_ [~gz@209-6-49-85.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com] has joined #ccl 02:49:30 -!- gz [Clozure@clozure-123267BA.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com] has quit [Quit: gz] 02:49:30 -!- gz_ [~gz@209-6-49-85.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com] has quit [Quit: gz_] 03:06:48 -!- rme [~rme@50.43.147.52] has quit [Quit: rme] 05:56:02 rme [~rme@50.43.147.52] has joined #ccl 06:18:55 -!- rme [~rme@50.43.147.52] has quit [Quit: rme] 08:16:47 jdz [~jdz@193.206.22.97] has joined #ccl 09:08:34 -!- jdz [~jdz@193.206.22.97] has quit [Quit: Byebye.] 09:10:39 jdz [~jdz@193.206.22.97] has joined #ccl 16:54:07 -!- jdz [~jdz@193.206.22.97] has quit [Ping timeout: 240 seconds] 17:37:03 rme [~rme@50.43.147.52] has joined #ccl 17:41:47 gz_ [~gz@209-6-49-85.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com] has joined #ccl 18:04:24 milanj [~milanj_@93-87-248-80.dynamic.isp.telekom.rs] has joined #ccl 20:06:30 Modius [~user@cpe-70-123-128-240.austin.res.rr.com] has joined #ccl 20:07:58 Ticket #862 ? 20:09:30 I'm pretty sure nobody's looked at it. 20:09:37 Not that I'm proud of that. 20:10:10 I don't even have enough of a background to get unixy/windows projects *compiling* properly 20:13:38 Only viable multithreaded conformant winxx Common Lisp :) 20:16:12 I actually did look at it a week or so ago (after not having done so for a few months). I was running under GDB, and made GDB print information about threads after the thread running the GC had stopped all other threads, hoping that I'd see some correlation between that info and the failure. I let it run and forgot about it; when I looked at it several hours later, it had printed several 100 thousand messages without crashing. 20:18:45 That made no sense; I would have guessed that the problem was a timing screw having to do with the state threads were in when they were stopped. That made it look like the problem had to do with them not (ordinarily) being stopped "long enough", and the printing changed that. 20:19:45 It's been a long time since I (tried) to get it building - how do you compile the win32 ? Do you do it from windows? Cygwin? What? 20:21:55 I usually compile the kernel using the cygwin toolchain on Windows, and we usually try to keep up-to-date kernel binaries for Windows in svn (because it's hard/undesirable for many people to install cygwin or mingw.) 20:28:37 -!- Modius [~user@cpe-70-123-128-240.austin.res.rr.com] has quit [Remote host closed the connection] 20:29:07 Modius [~user@cpe-70-123-128-240.austin.res.rr.com] has joined #ccl 21:24:23 Hmm - seems w64cl64.exe now trivially builds from a stock cygwin installation. So could a mere mortal figure out how the garbage collection works in CCL? 21:39:11 Chapter 17 of the manual discusses it in some detail. 21:41:36 From a code standpoint? 21:42:33 862 bugs me as I have a bit of code (that happens do encrypt or decrypt on side threads) that reliably breaks in cll. . . . 21:45:36 Modius_ [~Modius@cpe-70-123-128-240.austin.res.rr.com] has joined #ccl 21:46:23 I think that the code would be easier to understand if you read and understood that chapter first, but it's inherently pretty complicated code. What I said earlier - about how printing things in GDB made the problem go away - suggests that there could be a Windows bug involved, though I don't know that with absolute certainty. 21:47:09 Couldnt that mean just that you changed the timing? 21:48:14 I changed the timing when there was only one thread running (and all other threads were stopped.) It's hard to understand how that would affect what happens after the GC runs and the threads resume. 21:55:21 Things that I'd expect to be timing-sensitive - exactly when a thread is stopped and how the GC interprets that - wouldn't be affected by GDB printing things after everything stops, and every case that I looked at involving what happens during the act of stopping and restarting other threads seems to behave as I'd expect it to. 21:58:49 stassats [~stassats@wikipedia/stassats] has joined #ccl