00:41:52 mdc_mobile [n=mdc_mobi@ds9.entity.com] has joined #ccl
01:09:51 codewitch [n=thecodew@b1FBB.static.pacific.net.au] has joined #ccl
01:10:46 <codewitch> Hello rme, thank you for looking after the Win32 build of Clozure
01:11:16 sellout [n=greg@c-24-128-50-176.hsd1.ma.comcast.net] has joined #ccl
01:11:20 <rme> You're welcome, but I'm not the only one who looks after it.
01:14:23 <codewitch> I've managed to integrate it with emacs and load lispbuilder-sdl with it, and I was very happy to be able to have another repl interacting with the running sdl examples
01:16:01 <codewitch> I have a problem running the cl-opengl glut examples however.
01:17:39 <codewitch> When I try (cl-glut-examples:gears), a window appears, a single frame is rendered, and ccl breaks to its kernel debugger with an exception from freeglut.dll
01:21:19 <codewitch> Has Clozure Win32 ever been tested with cl-opengl?
01:21:23 <rme> Can you paste the backtrace from the kernel debugger?  (use "b" to print a backtrace)
01:21:30 <codewitch> Right away
01:22:06 <codewitch> [7560] Clozure CL kernel debugger: B
01:22:06 <codewitch> current thread: tcr = 0x5cb310, native thread ID = 0x1980, interrupts enabled
01:22:06 <codewitch> (#x00B80D44) #x08DC69A5 : #<Function %GLUTMAINLOOP #x08DC6946> + 95
01:22:06 <codewitch> (#x00B80D4C) #x08DC676D : #<Function MAIN-LOOP #x08DC6756> + 23
01:22:06 <codewitch> (#x00B80D54) #x081139A5 : #<Function %%STANDARD-COMBINED-METHOD-DCODE #x081136FE> + 679
01:22:06 <codewitch> (#x00B80D8C) #x083686DD : #<Function CALL-CHECK-REGS #x083685E6> + 247
01:22:08 <codewitch> (#x00B80DA8) #x083744B5 : #<Function TOPLEVEL-EVAL #x083741C6> + 751
01:22:10 <codewitch> (#x00B80DE8) #x08375E25 : #<Function READ-LOOP #x0837570E> + 1815
01:22:12 <codewitch> (#x00B80EFC) #x0836832D : #<Function TOPLEVEL-LOOP #x083682E6> + 71
01:22:14 <codewitch> (#x00B80F04) #x08318175 : #<Function (:INTERNAL (TOPLEVEL-FUNCTION (LISP-DEVELOPMENT-SYSTEM T))) #x08318116> + 95
01:22:16 <codewitch> (#x00B80F14) #x083D945D : #<Function (:INTERNAL MAKE-MCL-LISTENER-PROCESS) #x083D9216> + 583
01:22:18 <codewitch> (#x00B80F60) #x08330A95 : #<Function RUN-PROCESS-INITIAL-FORM #x083307F6> + 671
01:22:20 <codewitch> (#x00B80FA4) #x083312E5 : #<Function (:INTERNAL %PROCESS-PRESET-INTERNAL) #x08331196> + 335
01:22:22 <codewitch> (#x00B80FCC) #x083061BD : #<Function (:INTERNAL THREAD-MAKE-STARTUP-FUNCTION) #x083060A6> + 279
01:22:24 <codewitch> [7560] Clozure CL kernel debugger:
01:23:57 <codewitch> In the kernel debugger, if I choose "Exit from this debugger, asserting that any exception was handled", it runs for one frame, refreshes the display, then throws another exception.
01:30:20 <rme> I haven't been making very good guesses today.  You might send mail to openmcl-devel.
01:30:39 <rme> http://clozure.com/pipermail/openmcl-devel/2009-June/009691.html might be relevant
01:34:15 <gbyers> The exception wasn't handled.
01:35:40 <codewitch> I built freeglut.dll from source using MSys/MinGW - I'll try instrumenting glutMainLoop
01:36:25 <gbyers> I wonder - I don't know- if GLUT can just run on the listener thread in Windows.
01:37:06 <gbyers> Did you see an exception message when it entered the kernel debugger ?
01:41:27 <codewitch> Yes, it said:
01:41:29 <codewitch> ? (cl-glut-examples:gears)
01:41:30 <codewitch> %eax = 0x00000001
01:41:30 <codewitch> %ecx = 0x00000000
01:41:30 <codewitch> %edx = 0x0086ff94
01:41:30 <codewitch> %ebx = 0x0086ff94
01:41:30 <codewitch> %esp = 0x00a6f9e4
01:41:32 <codewitch> %ebp = 0x00a6f9fc
01:41:34 <codewitch> %esi = 0x00a6fb94
01:41:36 <codewitch> %edi = 0x00c36278
01:41:38 <codewitch> %eip = 0x00019c35
01:41:40 <codewitch> %eflags = 0x00040212
01:41:42 <codewitch> %cs = 0x001b
01:41:44 <codewitch> %ds = 0x0023
01:41:46 <codewitch> %ss = 0x0023
01:41:48 <codewitch> %es = 0x0023
01:41:50 <codewitch> %fs = 0x003b
01:41:52 <codewitch> %gs = 0x0000
01:41:53 <gbyers> something caused it to read an 'r'.
01:41:54 <codewitch> Exception on foreign stack
01:41:56 <codewitch> Exception occurred while executing foreign code
01:41:58 <codewitch> ? for help
01:42:00 <codewitch> [2356] Clozure CL kernel debugger:
01:42:19 <codewitch> what do you mean?
01:45:34 <gbyers> The registers output was its response to having read an 'r' from somewhere.
01:51:31 <codewitch> Could the version of cffi I'm using make a difference? Or is this something internal to Clozure? I'm using the latest cffi 0.10.4
01:51:50 <gbyers> Any of the above; I have no idea.
02:07:24 <codewitch> * trying something
02:13:54 -!- codewitch [n=thecodew@b1FBB.static.pacific.net.au] has quit [Read error: 54 (Connection reset by peer)]
02:19:13 codewitch [n=thecodew@b1FBB.static.pacific.net.au] has joined #ccl
02:20:18 <codewitch> Ignoring exceptions too many times results in a crash
02:21:50 <gbyers> That command is supposed to be used if you've fixed things (in gdb or somehow) and want to try to proceed, "asserting that the exception has been handled."'
02:22:42 <codewitch> Yes - I was hoping that it was one of those ignorable, non-lethal exceptions
02:23:11 <codewitch> I've narrowed it down to a call to fgEnumWindows
02:23:54 <codewitch> The reason I thought the exception might have been non-lethal is because CLisp runs it without any problems. Apart from the annoying problem of not being multithreaded
02:24:13 <gbyers> Which means, of course, next to nothing.
02:25:54 <codewitch> What means nothing, that it runs in CLisp, or that I'm spraying printfs in fgEnumWindows?
02:26:19 *codewitch* away for a while
02:39:15 -!- mdc_mobile [n=mdc_mobi@ds9.entity.com] has quit []
02:43:54 bfulgham_ [n=brent@adsl-69-234-130-247.dsl.irvnca.pacbell.net] has joined #ccl
02:44:56 -!- bfulgham_ [n=brent@adsl-69-234-130-247.dsl.irvnca.pacbell.net] has quit [Client Quit]
02:45:18 -!- alms [n=alms@209-150-48-250.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit []
02:48:12 <codewitch> May I ask, what country are you guys in? (gbyer, rme, Clozure Win32 developers)
02:48:16 alms [n=alms@209-150-48-250.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl
02:49:21 <gbyers> Most of us are in the US; Clozure has some people (subcontractors) in Germany and I'm not sure where else.
02:50:18 <codewitch> Clozure is fantastic. I am very grateful that you guys have ported it to Win32, and despite this cl-opengl problem, its a beautiful piece of work. Is there a way I can donate?
02:50:38 <gbyers> See if you can get alms' attention.
02:55:21 <rme> http://clozure.com/about.html contains contact information.
03:03:02 chandler [n=n@opendarwin/developer/chandler] has joined #ccl
03:03:28 lisppaste5 [n=lisppast@common-lisp.net] has joined #ccl
03:04:12 <chandler> rme: sorry about that! apparently freenode had some issues earlier and lisppaste didn't recover gracefully
03:04:13 <codewitch> http://clozure.com/about.html is a good read.
03:04:17 <rme> There's the lisppaste bot again.  Thanks chandler.
03:08:38 bfulgham_ [n=brent@adsl-69-234-130-247.dsl.irvnca.pacbell.net] has joined #ccl
03:12:54 <codewitch> Would freeglut.dll functions be running in more than one thread?
03:15:57 <gbyers> On some platforms (OSX), they're sensitive about what thread they're on.  The thing that I wonder about is whether they expect to use 'cdecl' or 'stdcall' calling conventions, and what cffi knows about that.
03:20:43 mdc_mobile [n=mdc_mobi@ds9.entity.com] has joined #ccl
03:21:33 <codewitch> I'll try to compare it to the SDL and SDL glue library code, since that works. OpenGL is explicitly mentioned here http://trac.clozure.com/ccl/wiki/OpenMclFfi so is there a testbed available?
03:26:55 <gbyers> There's lots of OpenGL code running in OpenMCL/CCL.  (On OSX, Linux, ....)
03:29:10 <codewitch> lispbuilder-sdl uses __declspec(dllexport) and has its own little cffi, cl-opengl also uses __declspec(dllexport) but has a cffi package dependency
03:29:26 <codewitch> Just throwing random trivia out there
03:31:35 <gbyers> I tried to build freeglut, and the build process got confused about whether function names have '@n' appended to them.  That generally means that the function follows Pascal-like calling convents (called 'stdcall' on Windows.)  We don't care, but it probably also means that callback functions are expected to discard their arguments before returning, and we don't do that unless told to.
03:35:48 <codewitch> Which freeglut are you building?
03:36:38 <gbyers> 2.6.0-rc1 from SourceForge.  Trying to build a non-Cygwin version with the Cygwin compiler.
03:38:21 <codewitch> I'm building this one: http://www.turtle.dds.nl/gl4newlisp/freeglut-devel.tar.gz
03:39:17 <codewitch> The reason is, I started playing with Lisp 3 weeks ago and started off with CLisp. After scraping lots of forums, I found that this is the freeglut build I should use.
03:40:39 <codewitch> Its unfortunate that cl-opengl and freeglut have to be obtained separately
03:41:46 <codewitch> I could be wrong. I probably am wrong. I'm going to build from 2.6.0-rc1 using Msys/MinGW and see if that helps....
03:41:50 <gbyers> I don't know if the version of FreeGLUT necessarily matters, but I am concerned that cffi may not know how to generate stdcall callbacks.  If the calling function and callee don't agree about that sort of thing, bad things happen.
03:42:37 <codewitch> I only understand cffi broadly, not enough to mess around with it...
03:43:56 <codewitch> Guess I'd better get my hands dirty
03:45:30 <gbyers> I think that that's worth looking at; the whole stdcall/cdecl thing is windows-specific, and CCL on Windows is fairly new and defaults to 'cdecl' for callbacks;  the FreeGLUT convention may be to use stdcall.
03:49:47 <codewitch> ....you're right.
03:52:09 <gbyers> So, if CFFI has a means of generating a 'stdcall' callback, the DEFCALLBACK that gets generated for CCL has to say something special whose syntax I don't recall at the monent ...
03:56:09 jauaor [n=araujo@gentoo/developer/araujo] has joined #ccl
03:58:43 <codewitch> I removed all instances of __stdcall, now interface functions are defined as __declspec(dllexport) instead of __declspec(dllexport) void __stdcall
03:59:18 <codewitch> Exception still occurs. I thought I'd give it a try.
04:00:26 <gbyers> I don't know if that's correct; FreeGLUT may use stdcall for a reason.  The demos will define lisp functions that are called from the GLUT code, and it may expect them to be 'stdcall' and crash if they aren't.
04:07:24 <codewitch> features.lisp in cffi/src has #:no-stdcall declared in #:cffi-features, which suggests that cffi will automagically convert standard calls.... much like I just did now that I think about it
04:08:19 <gbyers> I don't know for sure what that means.
04:08:52 <codewitch> Here is the code:
04:09:02 <codewitch> (defpackage #:cffi-features
04:09:02 <codewitch>   (:use #:cl)
04:09:02 <codewitch>   (:export
04:09:02 <codewitch>    #:cffi-feature-p
04:09:02 <codewitch>    ;; Features related to the CFFI-SYS backend.  Why no-*?  This
04:09:02 <codewitch>    ;; reflects the hope that these symbols will go away completely
04:09:04 <codewitch>    ;; meaning that at some point all lisps will support long-longs,
04:09:06 <codewitch>    ;; the foreign-funcall primitive, etc...
04:09:08 <codewitch>    #:no-long-long
04:09:10 <codewitch>    #:no-foreign-funcall
04:09:12 <codewitch>    #:no-stdcall
04:09:12 <rme> lisppaste5: url
04:09:14 <codewitch>    #:flat-namespace
04:09:14 <lisppaste5> To use the lisppaste bot, visit http://paste.lisp.org/new/ccl and enter your paste.
04:10:40 <lisppaste5> codewitch pasted "Code from cffi/src" at http://paste.lisp.org/display/81259
04:13:33 -!- bfulgham_ [n=brent@adsl-69-234-130-247.dsl.irvnca.pacbell.net] has quit []
04:14:35 bfulgham_ [n=brent@adsl-69-234-130-247.dsl.irvnca.pacbell.net] has joined #ccl
04:15:28 <codewitch> Do you want me to provide the simplest way to reproduce this problem?
04:18:54 <rme> The CFFI documentation seems to imply that it supports specifying the calling convention.  http://common-lisp.net/project/cffi/manual/html_node/defcallback.html
04:20:00 <gbyers> If you can, please fill out a ticket in trac.  I suspect that it's a CFFI issue, ultimately, but it'd be good to have a record of it.
04:20:01 <codewitch> But Clozure doesn't support it yet, based on what Gary is saying
04:20:23 <gbyers> No, that's not what I'm saying.
04:20:57 <rme> And I guess that cl-opengl would need to be updated to define callbacks using stdcall for Windows systems.
04:22:08 <gbyers> If it doesn't.  We don't know whether it does or not, but what's CFFI's idea of a stdcall callback for CCL ?
04:26:00 <rme> It looks like the CCL backend in the current CFFI sources ignores other calling conventions.
04:26:11 <rme> %defcallback in http://common-lisp.net/project/cffi/darcs/cffi/src/cffi-openmcl.lisp
04:26:56 <gbyers> Yep.
04:37:47 <codewitch> Ticket added to trac: http://trac.clozure.com/ccl/ticket/527
04:40:02 <gbyers> Thanks.  It's almost certainly necessary to fix CFFI's defcallback support; don't know if that's the only problem, but this sort of thing can't work until that's fixed.
04:40:21 <codewitch> Is it something you know how to do?
04:41:21 <gbyers> When I'm not watching baseball on the net ? Yes, I can probably figure it out, or rme can.
04:42:04 <gbyers> If/when we do, we'll send the patch to Luis or whoever maintains cffi these days.
04:46:53 <codewitch> I posted to cl-opengl-devel yesterday about this problem, and Luis replied - interesting how in all the world, there are literally about 5 people looking after Lisp
04:47:10 <codewitch> Link: http://common-lisp.net/pipermail/cl-opengl-devel/2009-June/000585.html
04:48:52 <codewitch> Thank you again so much for taking the time today to think about this problem and reply to my noob questions
04:49:09 <gbyers> NP.
04:49:12 <rme> Only 5? There's got to be at least a dozen lisp hackers.
04:50:22 <codewitch> gbyers, rme, luis, paul graham, and a legion of bloggers
05:57:42 <codewitch> Thanks again
05:57:46 -!- codewitch [n=thecodew@b1FBB.static.pacific.net.au] has left #ccl
05:57:51 <gbyers> ok.
06:05:29 codewitch [n=thecodew@b1FBB.static.pacific.net.au] has joined #ccl
06:05:56 -!- codewitch [n=thecodew@b1FBB.static.pacific.net.au] has quit [Client Quit]
06:32:03 -!- rme [n=rme@pool-70-104-125-18.chi.dsl-w.verizon.net] has quit []
06:57:33 codewitch [n=thecodew@CPE-124-177-50-95.vic.bigpond.net.au] has joined #ccl
06:59:55 -!- codewitch [n=thecodew@CPE-124-177-50-95.vic.bigpond.net.au] has quit [Client Quit]
07:03:49 codewitch [n=thecodew@CPE-124-177-50-95.vic.bigpond.net.au] has joined #ccl
08:24:08 -!- sellout [n=greg@c-24-128-50-176.hsd1.ma.comcast.net] has quit [Read error: 110 (Connection timed out)]
09:22:18 sellout [n=greg@c-24-128-50-176.hsd1.ma.comcast.net] has joined #ccl
09:36:16 -!- codewitch [n=thecodew@CPE-124-177-50-95.vic.bigpond.net.au] has quit []
10:08:42 codewitch [n=thecodew@CPE-124-177-50-95.vic.bigpond.net.au] has joined #ccl
10:48:27 -!- codewitch [n=thecodew@CPE-124-177-50-95.vic.bigpond.net.au] has quit []
10:59:06 -!- jauaor [n=araujo@gentoo/developer/araujo] has quit []
11:47:55 -!- sellout [n=greg@c-24-128-50-176.hsd1.ma.comcast.net] has quit []
12:30:09 sellout [n=greg@guest-fw.dc4.itasoftware.com] has joined #ccl
13:40:29 jajcloz [n=jaj@pool-173-76-163-72.bstnma.fios.verizon.net] has joined #ccl
14:46:19 -!- bfulgham_ [n=brent@adsl-69-234-130-247.dsl.irvnca.pacbell.net] has quit []
15:33:49 dat [n=dthomp@nmd.sbx08736.mcminor.wayport.net] has joined #ccl
15:39:16 rme [n=rme@pool-70-104-125-18.chi.dsl-w.verizon.net] has joined #ccl
15:40:38 -!- mdc_mobile [n=mdc_mobi@ds9.entity.com] has quit [Remote closed the connection]
15:57:25 milanj [n=milan@93.87.142.252] has joined #ccl
16:00:05 -!- dat [n=dthomp@nmd.sbx08736.mcminor.wayport.net] has quit [Read error: 113 (No route to host)]
16:05:21 dat [n=dthomp@dyn-188-dynamic.linfield.edu] has joined #ccl
17:31:08 -!- dat [n=dthomp@dyn-188-dynamic.linfield.edu] has quit ["Leaving"]
17:43:52 anRch [n=markmill@12.147.116.237] has joined #ccl
18:05:03 -!- anRch [n=markmill@12.147.116.237] has quit []
18:14:41 anRch [n=markmill@12.147.116.237] has joined #ccl
18:21:45 -!- rme [n=rme@pool-70-104-125-18.chi.dsl-w.verizon.net] has quit []
18:22:09 rme [n=rme@pool-70-104-125-18.chi.dsl-w.verizon.net] has joined #ccl
18:49:58 -!- rme [n=rme@pool-70-104-125-18.chi.dsl-w.verizon.net] has quit []
18:53:43 -!- anRch [n=markmill@12.147.116.237] has quit []
18:55:06 rme [n=rme@pool-70-104-125-18.chi.dsl-w.verizon.net] has joined #ccl
20:19:47 -!- segv__ [n=mb@p4FC1AC90.dip.t-dialin.net] has quit [Read error: 110 (Connection timed out)]
20:20:13 segv__ [n=mb@p4FC1C27F.dip.t-dialin.net] has joined #ccl
20:35:07 -!- sellout [n=greg@guest-fw.dc4.itasoftware.com] has quit []
20:50:58 REPLeffect [n=REPLeffe@69.54.115.254] has joined #ccl
21:10:07 -!- jajcloz [n=jaj@pool-173-76-163-72.bstnma.fios.verizon.net] has quit [Read error: 113 (No route to host)]
21:14:48 sellout [n=greg@c-24-128-50-176.hsd1.ma.comcast.net] has joined #ccl
21:27:23 jauaor [n=araujo@gentoo/developer/araujo] has joined #ccl
21:38:41 jajcloz [n=jaj@pool-173-76-163-72.bstnma.fios.verizon.net] has joined #ccl
21:55:36 milanj- [n=milan@93.86.186.165] has joined #ccl
21:56:50 amblerc [n=user@24-180-81-97.dhcp.bycy.mi.charter.com] has joined #ccl
22:08:00 -!- amblerc [n=user@24-180-81-97.dhcp.bycy.mi.charter.com] has quit ["ERC Version 5.3 (IRC client for Emacs)"]
22:15:21 -!- milanj [n=milan@93.87.142.252] has quit [Read error: 110 (Connection timed out)]
22:15:57 -!- alms [n=alms@209-150-48-250.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit []
22:58:01 -!- milanj- [n=milan@93.86.186.165] has quit ["Leaving"]
23:37:36 alms [n=alms@209-150-48-250.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl