00:46:38 -!- palter [palter@clozure-BB1CFD88.hsd1.ma.comcast.net] has quit [Quit: palter] 00:46:38 -!- palter [~palter@c-65-96-32-204.hsd1.ma.comcast.net] has quit [Quit: palter] 00:55:20 leo2007 [~leo@soup.linux.pwf.cam.ac.uk] has joined #ccl 02:58:54 -!- leo2007 [~leo@soup.linux.pwf.cam.ac.uk] has quit [Quit: rcirc on GNU Emacs 22.3.1] 03:04:48 alms [~alms@146-115-42-237.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 03:11:21 palter [~palter@c-65-96-32-204.hsd1.ma.comcast.net] has joined #ccl 03:34:11 -!- airolson [~airolson@CPE000ae6922d9c-CM001cea397dac.cpe.net.cable.rogers.com] has quit [Quit: airolson] 03:55:37 Fare [~Fare@c-24-218-127-11.hsd1.ma.comcast.net] has joined #ccl 03:57:14 devinus [~devinus@cpe-66-25-177-158.austin.res.rr.com] has joined #ccl 03:57:49 does the 32-bit port run on 64-bit windows? 03:59:45 -!- alms [~alms@146-115-42-237.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [Quit: alms] 04:03:44 alms [~alms@146-115-42-237.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 04:15:42 Fare: no 04:15:47 it's a known problem 04:15:53 I just asked about it recently 04:16:10 is there a "standard" driver to autoselect between the two? 04:16:21 Fare: http://www.clozure.com/pipermail/openmcl-devel/2009-March/009002.html 04:16:42 the problem is that Win32 allows you to use segment registers, Win64 doesn't 04:16:53 -!- devinus [~devinus@cpe-66-25-177-158.austin.res.rr.com] has quit [Quit: devinus] 04:16:58 Fare: I dunno what you mean 04:18:44 devinus [~devinus@cpe-66-25-177-158.austin.res.rr.com] has joined #ccl 04:24:47 reading the extra GPR vs %fs message, 04:25:13 isn't it possible to store a pointer to Lisp-level thread data in the C-level thread data? 04:25:38 then you can use the existing C-level thread-specific data register 04:26:19 at the cost of an extra indirection during special variable access. 04:28:19 -!- devinus [~devinus@cpe-66-25-177-158.austin.res.rr.com] has quit [Quit: devinus] 04:30:02 devinus [~devinus@cpe-66-25-177-158.austin.res.rr.com] has joined #ccl 04:30:39 i.e. a pick_the_correct_ccl.exe that runs ccl32.exe on win32, ccl64.exe on win64 04:30:40 fare: doing an extra indirection generally requires an extra GPR, and extra GPRs are in somewhat short supply. 04:31:13 gbyers: isn't it the same "extra" GPR that you need to hold the results, anyway? 04:31:32 On loads, it could be. On stores ... 04:32:27 don't you usually need a GPR to hold the target address anyway? 04:32:45 What's "the target address" ? 04:32:51 but yes, there might be a slight slowdown. 04:33:08 -!- devinus [~devinus@cpe-66-25-177-158.austin.res.rr.com] has quit [Client Quit] 04:33:27 (hard to tell what matters most in actual applications) 04:33:35 (short of measuring it) 04:33:56 stores are usually memory-bandwidth limited rather than register-limited, though. 04:34:41 (but I admit I don't understand very well the performance of modern memory hierarchy architectures) 04:34:45 If you don't -have- a practical way to use another GPR, that's small consolation, isn't it ? 04:35:04 :( 04:35:32 Having been raised on 3 to 8, I didn't realize that 15 was so small. 04:35:58 win32 = ia32 = 8 GPRs. 04:37:49 more like 7 actually 04:38:33 I feel a little obliged to point out that people have thought about this. That's no guarantee that noone missed anything obvious, but it lessens the chance of that a bit. 04:38:45 reminds me of how we viewed the 6502 as a 256-register machine by considering its page 0 as a register file. 04:39:36 so instead of having 1 GPR, we had 256 ! 04:39:53 I'm so old that I actually wrote code for a predeccessor of the 8080, which also used page-zero addressing. 04:40:43 ouch 04:45:00 Anyway: we do have a scheme in mind that'll let us load/store the most-commonly-accessed lisp thread-local-data cheaply and that'd allow the 32-bit Windows binary to run on 64-bit Windows. I don't know how soon someone will be able to work on that, but it'd be nice to remove the restriction. 04:46:39 (how expensive is it to allocate lisp data in the C T-L-D zone?) 04:46:53 That's the scheme. 05:02:09 btw, what's the process to get ccl to update its asdf? 05:02:25 how often are you ready to do it? 05:02:51 Process ? There's a process ? Why doesn't anyone tell me these things? 05:03:01 :-/ 05:03:17 I mean, asdf has been much improved recently. 05:03:36 we've got to better document the improvements, but they are there already. 05:04:05 once it's documented, I'd like to make a asdf 2.0 release and push it to all implementations, free or proprietary. 05:04:21 (but it's already usable now, and e.g. ECL is an early adopter) 05:07:16 We generally just grab a new release sometimes soon after it's available. Many (most ?) of us rarely use it and aren't that familiar with its internals, so there's some tension between "bundling it for convenience" and " implying that we can support it." 05:08:28 pray tell, what do you use to keep your systems organised then? 05:08:41 What systems ? 05:09:35 the main thing about the new ASDF is that it makes configuration so much easier, and allows further upgrade without implementation support through (asdf:load-system :asdf) 05:09:41 I've heard rumors that people actually use CCL for things other than working on CCL itself, but they're hard for me to believe ... 05:09:51 (which is not quite as simple from an old asdf) 05:10:33 -!- palter [palter@clozure-BB1CFD88.hsd1.ma.comcast.net] has quit [Connection reset by peer] 05:10:47 palter_ [~palter@2002:4160:20cc:0:21b:63ff:fe96:e1ff] has joined #ccl 05:10:47 -!- palter [~palter@c-65-96-32-204.hsd1.ma.comcast.net] has quit [Read error: Connection reset by peer] 05:10:48 -!- palter_ is now known as palter 05:12:35 gbyers: umm, aka organised bodies of code. Something one is likely to encounter when one does, in fact, use CCL to run code designed to solve concrete tasks other than running CCL 05:12:56 You mean these rumors are true ? 05:13:30 rumors, rumors! 05:14:50 gbyers: yup! I've personally used CCL to build a windows image of just such code 05:15:45 then I run into much funk when trying to build a win64 version of the same from a VM running on a 32-bit host through QEMU, something I'm not done investigating yet 05:16:14 Perhaps it'd have been clearer if I'd said that since 99+% of my use of CCL is to work on CCL, I don't personally have much need for things like ASDF and as a result I'm not very familiar with it. I do understand that my use isn't typical, and that these rumors are in fact true. 05:17:38 but there's something definitely not right about it, otherwise (load "foo.lisp") wouldn't fail to complete within 10 minutes if just READ + EVAL by hand take 5s 05:21:02 Is emulation via QEMU noticably slower in general ? I wonder if the LOAD case happened to trigger a GC and READ+EVAL happened not to. 05:21:52 gbyers: it is, but not to this extent 05:22:27 emulating a 64-bit machine on a 32-bit machine is bound to be slow. 05:22:29 I can't believe it'd consistently hit GC and stay there every time right after entering %%STAT 05:23:11 Fare: but we're talking 20x slower, which I'm prepared to take. What I'm seeing is LOAD being 2000x slower while the rest stays the same 05:24:19 gbyers: I intend to investigate it further, I just haven't because it's such a monumental PITA to run the way I do currently 05:24:34 and because the day only has 24h 05:25:13 Unlikely that that'd happen consistently. %%STAT is just a wrapper around the stat syscall on Unix; I don't remember whether we call a native Windows thing directly or call something that looks more stat-like and is implemented in terms of a native windows thing. 05:25:58 yeah, I know it dies always in the same point, I just haven't managed to pinpoint what that point is yet 05:26:05 well, "dies" 05:26:09 I interrupt it 05:26:21 because it's stuck 05:26:58 qemu sometimes has bugs, especially when running code that doesn't do what a typical C program does. 05:27:07 but I've seen some very odd behaviour, such as adding (format t "Done~&") after reading/evaling in the file by hand increasing the run time tenfold 05:27:36 I remember how I couldn't run clisp under qemu-arm because its sigsegv support was lacking. 05:28:13 that's possible, but I need to set up remote SLIME before I can do anything 05:28:37 mathrick, better to get a 64-bit box. 05:28:50 Output to *terminal-io* sometimes gets flushed by a background thread; I wonder if the delays there have to do with threads/locking. 05:29:35 what if you use single-threaded-ccl or some such to avoid background threads? 05:29:38 Fare: they're notoriously not free. I'm notoriously broke 05:29:51 hmm, I dunno, I'd have to try that 05:29:56 (I haven't tried single-threaded-ccl on windows) 05:30:18 is it hanging when loading any file or only when loading some specific file? 05:30:28 any 05:30:35 :( 05:30:37 You call FORCE-OUTPUT yourself, or the output side of a two-way stream gets flushed when reading from the input side. 05:35:56 All this lisp talk has made me hungry! Good night. 05:36:02 -!- gbyers [~gb@c-68-35-15-143.hsd1.nm.comcast.net] has quit [Quit: Leaving] 05:53:15 -!- Fare [~Fare@c-24-218-127-11.hsd1.ma.comcast.net] has quit [Quit: Leaving] 07:24:46 gbyers [~gb@c-68-35-15-143.hsd1.nm.comcast.net] has joined #ccl 08:23:08 -!- gbyers [~gb@c-68-35-15-143.hsd1.nm.comcast.net] has quit [Quit: Leaving] 08:23:31 gbyers [~gbyers@c-68-35-15-143.hsd1.nm.comcast.net] has joined #ccl 10:38:10 leo2007 [~leo@soup.linux.pwf.cam.ac.uk] has joined #ccl 11:52:58 -!- leo2007 [~leo@soup.linux.pwf.cam.ac.uk] has quit [Remote host closed the connection] 14:13:18 airolson [~airolson@CPE000ae6922d9c-CM001cea397dac.cpe.net.cable.rogers.com] has joined #ccl 15:40:18 -!- Adlai [~adlai@unaffiliated/adlai] has quit [Quit: reboot] 15:52:56 Adlai [~Adlai@unaffiliated/adlai] has joined #ccl 18:17:30 -!- gbyers [~gbyers@c-68-35-15-143.hsd1.nm.comcast.net] has quit [Quit: gbyers] 18:17:54 gbyers [~gb@c-68-35-15-143.hsd1.nm.comcast.net] has joined #ccl 18:26:29 Dawgmatix_ [~dman@c-76-124-9-27.hsd1.nj.comcast.net] has joined #ccl 23:30:29 -!- airolson [~airolson@CPE000ae6922d9c-CM001cea397dac.cpe.net.cable.rogers.com] has quit [Quit: airolson] 23:59:57 -!- palter [~palter@2002:4160:20cc:0:21b:63ff:fe96:e1ff] has quit [Quit: palter]