00:02:23 -!- rme_ [~rme@50.43.133.173] has quit [Quit: rme_] 00:03:33 rme_ [~rme@50.43.133.173] has joined #ccl 00:13:19 kmcorbett [~kmcorbett@173-9-35-41-NewEngland.hfc.comcastbusiness.net] has joined #ccl 00:31:18 -!- kmcorbett [kmcorbett@clozure-9FE07BBF.hfc.comcastbusiness.net] has quit [Quit: Quit] 00:31:18 -!- kmcorbett [~kmcorbett@173-9-35-41-NewEngland.hfc.comcastbusiness.net] has quit [Quit: Quit] 01:18:56 -!- alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [Quit: alms_] 01:42:03 alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 02:11:52 -!- rme_ [~rme@50.43.133.173] has quit [Quit: rme_] 02:13:17 rme_ [~rme@50.43.133.173] has joined #ccl 02:14:08 -!- alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [Quit: alms_] 02:21:49 alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 02:36:34 -!- alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [Quit: alms_] 02:49:57 alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 03:14:13 -!- alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [Quit: alms_] 03:55:13 alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 04:00:28 -!- alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [Ping timeout: 276 seconds] 04:04:05 alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 04:11:19 -!- alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [Quit: alms_] 04:24:53 -!- rme_ [~rme@50.43.133.173] has quit [Quit: rme_] 04:26:09 gko [~gko@114-34-168-13.HINET-IP.hinet.net] has joined #ccl 05:33:20 -!- gko [~gko@114-34-168-13.HINET-IP.hinet.net] has quit [Ping timeout: 272 seconds] 06:42:52 >/leave 06:42:53 -!- pjb [~t@81.202.16.46.dyn.user.ono.com] has left #ccl 12:54:01 gko [~gko@114-34-168-13.HINET-IP.hinet.net] has joined #ccl 14:48:09 alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 14:49:29 -!- alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [Client Quit] 16:40:38 -!- sellout [~Adium@c-98-245-92-119.hsd1.co.comcast.net] has quit [Quit: Leaving.] 17:38:08 -!- gko [~gko@114-34-168-13.HINET-IP.hinet.net] has quit [Ping timeout: 240 seconds] 17:53:37 rme_ [~rme@50.43.133.173] has joined #ccl 17:59:12 alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 18:01:36 sellout [~Adium@64.134.223.67] has joined #ccl 19:12:46 bzzbzz [~franco@modemcable151.155-57-74.mc.videotron.ca] has joined #ccl 21:43:39 -!- sellout [~Adium@64.134.223.67] has quit [Quit: Leaving.] 21:49:15 rtoym [~chatzilla@24.130.4.105] has joined #ccl 21:51:36 I'm trying to get matlisp running with ccl (32-bit) and I'm getting NaN for some results. I hear it works fine with ccl 64-bit on linux. Any known issues with 32-bit ccl and ffi? 21:53:36 As far as I know, the 32-bit x86 ffi is OK. 21:57:15 It's possible there are bugs, of course. 21:58:16 Ok. I'll have to do some digging, I guess. It's the same lisp code, so maybe the foreign code is different. But the foreign code is the same (or should be) for ccl and cmucl, where matlisp works fine. 22:00:32 A bit of a pain because I'm not that familiar with cffi or ccl. 22:03:15 Most of CCL doesn't know anything about the x87. If there's a result on the x87 stack, and the ff-call code botches retrieving it somehow (or ends up writing to an MMX register before retrieving it), Bad Things might happen. 22:03:41 Do you have a fairly reasonable test case? 22:06:59 The test case is simple, but you need to compile up matlisp including the fortran code. 22:07:24 Hmm. But maybe I can find a simple case that calls one fortran routine... 22:08:33 There shouldn't be a problem with x87; this is osx, so the fortran compiler should be using sse2 already. 22:10:37 Right. On OS X, I wouldn't expect the x87 to be in the way. 22:17:09 rtoym: If you have steps to reproduce, I can try to take a look. It should be possible to figure out where the NaN is introduced if I can use gdb. Please mail me at rme@clozure.com or make a ticket on trac.clozure.com/ccl. 22:19:01 rme_: It's easy to reproduce. Clone matlisp, get the matlisp-cffi branch, configure/make. Then (in-package #:matlisp-user) (m+ [1 2] [3 4]) 22:19:08 :-) 22:19:17 But you probably want something a little simpler than that. :-) 22:30:22 to exhibit some ignorance here: does OSX/Xcode include a Fortran compiler ? If not, do you know what Fortran compiler was used ? 22:43:24 OSX does not include a fortran compiler. I googled from some and found one that uses the same gcc sources used on osx to build the fortran compiler. (I didn't compile it myself.) 22:43:32 s/from/for/ 22:43:59 Thanks; that's what I'd started to conclude. 23:01:51 sellout [~Adium@c-98-245-92-119.hsd1.co.comcast.net] has joined #ccl 23:27:05 The code wants to turn off the GC and pass a foreign pointer to a lisp vector's first data element to foreign code. In 32-bit CCL, there's some confusion as to what a vector's first data element is when the vector is specialized to DOUBLE-FLOAT; the first word is basically just there for alignment padding and the actual double-float data is a word later. We could/should change the primitive to return a pointer to the real data, since no one should c 23:27:06 are about the alignment word 23:31:24 We seem to DTRT on ARM and 32-bit PPC, but not on 32-bit X86. 23:32:13 *rme_* takes the blame 23:33:07 Of course, %ivector-from-macptr doesn't work in that case, then. 23:35:52 But it looks like that function doesn't even has any callers. 23:35:58 I think we clear the low bits and add the tag in %ivector-from-macptr, don't we ? 23:42:47 D'oh. We do that, but you're right that that wouldn't help in this case. 23:47:26 Anyhow ... whether we think of a way to fix %ivector-from-macptr or drop it, that seems to be the problem that affects matlisp. 23:49:07 rtoym: I don't know if any of that made any sense, but it seems to be our bug.