01:52:00 -!- hargettp [~hargettp@pool-71-184-190-145.bstnma.east.verizon.net] has quit [Quit: Leaving...] 02:13:27 hargettp [~hargettp@pool-71-184-190-145.bstnma.east.verizon.net] has joined #ccl 02:39:11 -!- hargettp [~hargettp@pool-71-184-190-145.bstnma.east.verizon.net] has quit [Quit: Leaving...] 02:52:12 leo2007 [~leo@123.114.52.195] has joined #ccl 04:18:41 -!- leo2007 [~leo@123.114.52.195] has quit [Ping timeout: 240 seconds] 05:14:19 -!- dsantiago [~dsantiago@c-98-226-186-156.hsd1.il.comcast.net] has quit [Ping timeout: 246 seconds] 05:19:05 -!- sellout [~Adium@c-24-61-13-161.hsd1.ma.comcast.net] has quit [Ping timeout: 240 seconds] 05:21:02 dsantiago [~dsantiago@c-98-226-186-156.hsd1.il.comcast.net] has joined #ccl 06:43:44 udzinari [~udzinari@ip-89-102-12-6.net.upcbroadband.cz] has joined #ccl 06:51:39 -!- udzinari [~udzinari@ip-89-102-12-6.net.upcbroadband.cz] has quit [Quit: zzzzzzZZZZZZZZZzzzzzzz] 06:52:50 udzinari [~udzinari@ip-89-102-12-6.net.upcbroadband.cz] has joined #ccl 06:53:17 -!- udzinari [~udzinari@ip-89-102-12-6.net.upcbroadband.cz] has quit [Client Quit] 07:21:20 jdz [~jdz@193.206.22.97] has joined #ccl 07:25:15 sellout [~Adium@c-24-61-13-161.hsd1.ma.comcast.net] has joined #ccl 07:48:58 -!- jdz [~jdz@193.206.22.97] has quit [Ping timeout: 240 seconds] 08:01:13 jdz [~jdz@193.206.22.97] has joined #ccl 08:56:26 -!- jdz [~jdz@193.206.22.97] has quit [Quit: Leaving] 08:57:14 jdz [~jdz@193.206.22.97] has joined #ccl 09:00:54 -!- jdz [~jdz@193.206.22.97] has quit [Read error: Connection reset by peer] 09:02:02 jdz [~jdz@193.206.22.97] has joined #ccl 10:04:05 hargettp [~hargettp@pool-71-184-190-145.bstnma.east.verizon.net] has joined #ccl 10:12:52 -!- hargettp [~hargettp@pool-71-184-190-145.bstnma.east.verizon.net] has quit [Quit: Leaving...] 10:13:45 hargettp [~hargettp@pool-71-184-190-145.bstnma.east.verizon.net] has joined #ccl 11:51:10 -!- hargettp [~hargettp@pool-71-184-190-145.bstnma.east.verizon.net] has quit [Quit: Leaving...] 12:27:09 -!- sellout [~Adium@c-24-61-13-161.hsd1.ma.comcast.net] has quit [Read error: Connection reset by peer] 12:28:54 sellout [~Adium@c-24-61-13-161.hsd1.ma.comcast.net] has joined #ccl 12:51:43 -!- sellout [~Adium@c-24-61-13-161.hsd1.ma.comcast.net] has quit [Quit: Leaving.] 13:12:44 sellout [~Adium@173-162-137-153-NewEngland.hfc.comcastbusiness.net] has joined #ccl 13:45:18 milanj [~milanj_@212-200-194-87.dynamic.isp.telekom.rs] has joined #ccl 13:46:36 alms_ [~alms_@173-162-137-153-NewEngland.hfc.comcastbusiness.net] has joined #ccl 15:22:24 anRch [~markmilli@64.134.70.11] has joined #ccl 15:41:35 -!- jdz [~jdz@193.206.22.97] has quit [Quit: Leaving] 16:02:47 -!- anRch [~markmilli@64.134.70.11] has quit [Quit: anRch] 16:05:58 udzinari [~udzinari@ip-89-102-12-6.net.upcbroadband.cz] has joined #ccl 16:11:04 anRch [~markmilli@pool-68-163-177-162.bos.east.verizon.net] has joined #ccl 16:19:06 -!- anRch [~markmilli@pool-68-163-177-162.bos.east.verizon.net] has quit [Ping timeout: 248 seconds] 16:23:15 peterhil` [~peterhil@a91-152-135-21.elisa-laajakaista.fi] has joined #ccl 16:24:11 Hi! Why there is not a /opt/local/bin/ccl - only ccl64 when installing ClozureCL from MacPorts on an Intel iMac? 16:24:46 I did that file myself by search and replacing s/cl64/cl/g on /opt/local/bin/ccl 16:25:07 Also I get: > Error: Module ASDF-INSTALL was not provided by any function on *MODULE-PROVIDER-FUNCTIONS*. 16:25:07 > While executing: REQUIRE, in process listener(1). 16:25:37 As described here also (CCL 1.6 on Linux): http://permalink.gmane.org/gmane.lisp.openmcl.devel/6801 16:25:48 Is this a Windows onlu release...? ;-) 16:26:09 ...only 16:27:03 anRch [~markmilli@pool-68-163-177-162.bos.east.verizon.net] has joined #ccl 16:32:51 -!- anRch [~markmilli@pool-68-163-177-162.bos.east.verizon.net] has quit [Ping timeout: 240 seconds] 16:36:56 OK, it seems that with Quicklisp, requiring asdf is unncessary if there is the code added by ql:add-to-init-file on .ccl-init.lisp 16:37:09 So I got the latter problem solved also 16:37:15 I'm afraid I don't know what installation choices macports makes. 16:38:39 It installs ccl on /opt/local/share/ccl 16:38:53 But anyway, now I got everything back working it seems 16:39:13 I had ccl installed on /usr/local/src/ccl 16:39:42 ok, glad it works. 16:39:43 anRch [~markmilli@pool-68-163-168-246.bos.east.verizon.net] has joined #ccl 16:45:24 Hmph, the MacPorts version doesn't include the Mac OS X apps. But apparently the .apps with version number 1.4-dev work 16:45:40 Maybe I should complain at #macports? :-) 16:48:44 -!- anRch [~markmilli@pool-68-163-168-246.bos.east.verizon.net] has quit [Quit: anRch] 16:49:36 Ah, there is build instructions on cocoa-ide direcory 16:50:02 you should be able to start ccl, do (require 'cocoa-application) and that will build the .app bundle. 16:55:35 Yes 16:59:44 The version string in the built apps is still 1.4-dev? 17:00:00 Even though I'm quite sure they are from 2.6 sources 17:00:04 1.6 17:00:37 Maybe there hasn't happened much in the IDE code? 17:01:09 In the About box, you mean? I can believe that. One of these days we need to make it so that the version in the About box stays closer to reality. 17:04:02 anRch [~markmilli@63.112.62.27] has joined #ccl 17:14:13 gz [~gz@173-162-137-153-NewEngland.hfc.comcastbusiness.net] has joined #ccl 17:53:37 -!- udzinari [~udzinari@ip-89-102-12-6.net.upcbroadband.cz] has quit [Quit: udzinari] 18:01:55 udzinari [~udzinari@ip-89-102-12-6.net.upcbroadband.cz] has joined #ccl 18:03:36 -!- gz [gz@clozure-93943513.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com] has quit [Ping timeout] 18:38:08 -!- alms_ [~alms_@173-162-137-153-NewEngland.hfc.comcastbusiness.net] has quit [Quit: alms_] 18:38:16 alms_ [~alms_@173-162-137-153-NewEngland.hfc.comcastbusiness.net] has joined #ccl 18:41:58 David2 [David@horatio-135.cs.utexas.edu] has joined #ccl 18:43:00 -!- anRch [~markmilli@63.112.62.27] has left #ccl 19:06:07 No, in Finder. 19:06:23 And in the about box 19:12:08 The version string in the about box (at least) just comes from an HTML file; as rme said, we should rewrite that string when the IDE is built (rather than "every few years, when someone remembers to do it manually.") 19:14:59 (Or maybe it's the Info.plist file, I don't remember.) 19:17:59 pjb [~t@81.202.16.46.dyn.user.ono.com] has joined #ccl 19:19:24 I get a "XIO: fatal IO error 104 (Connection reset by peer) on X server ":0" after 56647 requests (56647 known processed) with 0 events remaining." and then "Process inferior-lisp exited abnormally with code 1" upon killing a X window created with glut:display-window. What can I do to catch this error and avoid killing ccl? (I tried handler-case and handler-bind on ERROR). 19:20:35 If the glut event loop runs on the initial thread, the lisp will die when it stops. 19:20:48 So I'd have to do it in a thread. 19:23:45 No, it doesn't work. 19:23:57 Still get the fata IO error 104, and process exit. 19:24:35 What would you do on a thread ? Have glut not call exit() or abort() or whatever it does ? 19:24:55 Just (glut:display-window (make-instance 'my-window)) ; that's all. 19:25:17 Before or after the OS process dies ? 19:25:25 Before :-) 19:25:26 Perhaps I need to define a on-close method or something. 19:26:34 The example in ccl:examples; opengl-ffi.lisp does tricks to run the event loop on the main thread because Mac OS X insists on it. On other systems, you might be able to say (process-run-funtion "glut event loop" #'my-glut-main) or something. But glutMainLoop() calls exit(), there's not a lot we can do about that. 19:27:03 (set-action-on-window-close :action-glutmainloop-returns) should do it. 19:27:06 (I mean *if* glutMainLoop() calls exit) 19:28:28 I'm on Linux. That's seems to be what happens. 19:33:20 Well, Neither (set-action-on-window-close :action-glutmainloop-returns) nor (set-action-on-window-close :action-continue-execution) do it. :-( 19:45:29 And assuming I don't call glutMainLoop by setting (setf *run-main-loop-after-display* nil), what would I have to do? 19:46:43 Well, it behaves exactly the same with *run-main-loop-after-display* set to NIL. 19:54:12 <|3b|> pjb: are you using cl-opengl/cl-glut with recent freeglut? i'd expect it to work without any extra effort on linux ccl 19:54:27 I have media-libs/freeglut-2.6.0. 19:54:37 But I'm watching the sources, there are a lot of calls to exit... 19:54:55 notably there's one in fgError. 19:55:50 <|3b|> that sounds like a similar version to what i have (ubuntu calls it freeglut3, version 2.6.0-0ubuntu2) 19:57:05 <|3b|> possibly some edge cases will still kill the lisp, but i don't remember having too much trouble 19:57:12 *|3b|* hasn't used glut in a while though 19:57:43 Yes, the problem is the C code of libglut. We should add an exception handling system and a call back to deal with errors instead of exiting. 19:58:10 <|3b|> i mean i didn't think it was that big of a problem 19:58:36 Well, when your lisp exits at each REPL interaction, it's a problem. 19:58:43 *|3b|* would have to look at code to see why, maybe it assigns its own callback that doesn't exit()? 19:59:04 An alternative would be to rewrite glut in lisp. 19:59:10 *|3b|* points at glop 19:59:21 It doesn't use glut? 19:59:26 <|3b|> which is one reason i haven't been using glut much lately 19:59:34 Perhaps I should look at glop again, yes. 19:59:42 <|3b|> right, direct ffi to windows or x (or osx if a mac users ever decides to help) 20:01:07 After all, freeglut is 25234 loc of C, that should be writable in less than 2500 loc of lisp... 20:02:40 <|3b|> well, freeglut also includes decades of thousands of people exposing it to random hardware/software configurations... even if we can improve that by a factor of 10, we still have a ways to go :/ 20:03:28 Well, we would obviously rewrite it with the C code in another window :-) 20:03:59 *|3b|* isn't sure that would be worth the effort 20:04:21 Improving the interactivity of the code. 20:05:35 <|3b|> right, not pointless, just not a strategy i'm interested in at the moment :) 20:05:54 <|3b|> did you say if you are using cl-opengl/cl-glut? 20:06:00 Yes. 20:06:07 That's what I'm trying to use. 20:06:28 <|3b|> hmm, does it break if you try the sample apps? 20:07:11 No, it runs ok. But when developing (and later, when running the application) I want to be able to kill the window, and have the lisp still run (and eventually open another window). 20:07:25 I mean, it's the most trivial gui thing, close a window and open another. 20:07:32 (But perhaps not for a C game programmer). 20:07:37 <|3b|> well, 'close' might not mean the same as 'kill' 20:08:00 <|3b|> you should be able to open and close windows at will 20:08:25 <|3b|> (aside from some edge cases where you need to restart the mainloop by hand to get it to notice a window closed, if you did a nlx outside it) 20:08:43 <|3b|> but even then it is usually possible to poke at it enough to get back to a sane state 20:09:19 <|3b|> and with enough restarts or restartable frames and careful debugger use it isn't too hard to avoid that problem 20:10:01 Ah, correct, there's also a delete command in ratpoison. I've been using kill somewhat indiscriminately. 20:10:19 With delete, it resumes to the REPL. 20:10:33 Well, that will do for now. Thank you. 20:11:44 *|3b|* doesn't remember if you can stop 'fatal x error' from killing things or if that is at xlib level 20:12:09 It seems to be in fgError, where there's the call to exit(1). 20:23:29 <|3b|> error you pasted earlier looks more like xlib than freeglut, looks like fgError would print "freeglut" if it handled it, or call a user defined error function if available 20:24:59 *|3b|* doesn't have convenient access to the source and is half afk, does freeglut call XSetIOErrorHandler anywhere? 20:27:49 No, it doesn't seem to call it. 20:28:24 You're right, fgError starts by writing "freeglut ". 20:31:20 <|3b|> ok, do fixing that might be a hassle, would have to grab a Display* out of freeglut somehow (don't remember if that is hard or not), add a handler, then figure out how to convince freeglut to make a new connection to X... probably easier to just ask it to close nicely if possible :) 20:35:20 -!- alms_ [~alms_@173-162-137-153-NewEngland.hfc.comcastbusiness.net] has quit [Quit: alms_] 20:36:55 Well, I can just use delete instead of kill in ratpoison. I mean, this exiting is done on purpose to kill the program from X. 20:37:34 It's just that kill is called with C-t K while delete is C-t k, the ratpoison bindings are close (no pun intended). 20:38:26 With C-t k (delete) it closes the window and exit the glutMainLoop as expected. 20:45:14 -!- sellout [~Adium@173-162-137-153-NewEngland.hfc.comcastbusiness.net] has quit [Quit: Leaving.] 21:32:52 -!- milanj [~milanj_@212-200-194-87.dynamic.isp.telekom.rs] has quit [Quit: Leaving] 21:33:48 Fare [~Fare@ita4fw1.itasoftware.com] has joined #ccl 21:34:52 -!- gz [Clozure@clozure-FDAAE900.hfc.comcastbusiness.net] has quit [Quit: gz] 21:34:52 -!- gz [~gz@173-162-137-153-NewEngland.hfc.comcastbusiness.net] has quit [Quit: gz] 22:01:56 alms_ [~alms_@146-115-42-237.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 22:51:42 -!- David2 [David@horatio-135.cs.utexas.edu] has quit [Ping timeout: 248 seconds] 23:01:40 -!- udzinari [~udzinari@ip-89-102-12-6.net.upcbroadband.cz] has quit [Quit: zzzzzzZZZZZZZZZzzzzzzz] 23:31:54 -!- Fare [~Fare@ita4fw1.itasoftware.com] has quit [Quit: Leaving] 23:31:56 hargettp [~hargettp@pool-71-184-190-145.bstnma.east.verizon.net] has joined #ccl