04:53:04 adamvh [~adamvh@adsl-99-103-186-186.dsl.sfldmi.sbcglobal.net] has joined #ccl 14:12:10 ccl-logbot [~ccl-logbo@setf.clozure.com] has joined #ccl 14:12:10 14:12:10 -!- names: ccl-logbot rme bzzbzz sellout adamvh bfulgham jdz e-user alms_ Modius TeMPOraL Intensity billstclair ArmyOfBruce rbancroft gz sswords clop2 deepfire gnooth |3b|` gbyers mdc @ChanServ 14:12:10 -niven.freenode.net:#ccl- [freenode-info] help freenode weed out clonebots -- please register your IRC nick and auto-identify: http://freenode.net/faq.shtml#nicksetup 14:44:57 -!- adamvh [~adamvh@adsl-99-103-186-186.dsl.sfldmi.sbcglobal.net] has quit [Quit: adamvh] 15:56:16 adamvh [~adamvh@adsl-99-103-186-186.dsl.sfldmi.sbcglobal.net] has joined #ccl 15:56:31 -!- adamvh [~adamvh@adsl-99-103-186-186.dsl.sfldmi.sbcglobal.net] has quit [Client Quit] 16:07:32 adamvh [~adamvh@adsl-99-103-186-186.dsl.sfldmi.sbcglobal.net] has joined #ccl 16:26:07 anRch [~markmilli@64.134.102.75] has joined #ccl 16:44:02 -!- jdz [~jdz@193.206.22.97] has quit [Ping timeout: 255 seconds] 17:12:25 roffe [~roffe@ti0165a340-dhcp0944.bb.online.no] has joined #ccl 17:16:25 -!- rme [~rme@pool-70-106-129-201.chi01.dsl-w.verizon.net] has quit [Quit: rme] 17:17:18 rme [~user@pool-70-106-129-201.chi01.dsl-w.verizon.net] has joined #ccl 17:24:08 -!- anRch [~markmilli@64.134.102.75] has quit [Quit: anRch] 17:38:00 -!- e-user [~akahl@nat/nokia/x-rxoplazfwybmuhzu] has quit [Quit: Leaving.] 17:45:25 -!- adamvh [~adamvh@adsl-99-103-186-186.dsl.sfldmi.sbcglobal.net] has quit [Quit: adamvh] 17:54:00 jdz [~jdz@host151-111-dynamic.15-87-r.retail.telecomitalia.it] has joined #ccl 18:20:56 -!- gnooth [~gnooth@ip98-176-79-151.sd.sd.cox.net] has quit [Quit: Leaving] 18:25:42 adamvh [~adamvh@adsl-99-103-186-186.dsl.sfldmi.sbcglobal.net] has joined #ccl 18:31:13 gnooth [~gnooth@ip98-176-79-151.sd.sd.cox.net] has joined #ccl 18:52:15 -!- sswords [~sswords@moat3.centtech.com] has quit [Ping timeout: 250 seconds] 18:52:27 -!- clop2 [~jared@moat3.centtech.com] has quit [Ping timeout: 260 seconds] 19:13:41 -!- jdz [~jdz@host151-111-dynamic.15-87-r.retail.telecomitalia.it] has quit [*.net *.split] 19:13:45 -!- bzzbzz [~franco@modemcable240.34-83-70.mc.videotron.ca] has quit [*.net *.split] 19:13:45 -!- bfulgham [~brent@wsip-72-215-191-226.sb.sd.cox.net] has quit [*.net *.split] 19:13:45 -!- gnooth [~gnooth@ip98-176-79-151.sd.sd.cox.net] has quit [*.net *.split] 19:13:47 -!- rbancroft [~rumble@S0106000024ccf2b4.cg.shawcable.net] has quit [*.net *.split] 19:13:48 -!- roffe [~roffe@ti0165a340-dhcp0944.bb.online.no] has quit [*.net *.split] 19:14:07 sswords [~sswords@moat3.centtech.com] has joined #ccl 19:18:22 gnooth [~gnooth@ip98-176-79-151.sd.sd.cox.net] has joined #ccl 19:18:22 jdz [~jdz@host151-111-dynamic.15-87-r.retail.telecomitalia.it] has joined #ccl 19:18:22 bzzbzz [~franco@modemcable240.34-83-70.mc.videotron.ca] has joined #ccl 19:18:22 bfulgham [~brent@wsip-72-215-191-226.sb.sd.cox.net] has joined #ccl 19:18:22 rbancroft [~rumble@S0106000024ccf2b4.cg.shawcable.net] has joined #ccl 19:21:30 Anyone who knows the obj-C bridge on? 19:21:32 -!- rme [user@clozure-1F3CDCA9.chi01.dsl-w.verizon.net] has quit [Connection reset by peer] 19:21:32 -!- rme [~user@pool-70-106-129-201.chi01.dsl-w.verizon.net] has quit [Remote host closed the connection] 19:22:12 rme [~rme@pool-70-106-129-201.chi01.dsl-w.verizon.net] has joined #ccl 19:23:30 adamvh: What's your question? 19:25:05 So, I have successfully generated a bunch of .cdb files, running ffigen4, parse-standard-ffi-files 19:25:07 all that 19:27:03 I added a directory 19:27:08 in darwin-x86 headers 19:27:33 for my Objective-C-Class 19:27:38 however, (require 'cocoa) 19:27:42 now errors off 19:27:44 when 19:27:51 -!- sswords [~sswords@moat3.centtech.com] has quit [Ping timeout: 240 seconds] 19:28:04 (#_ objc_lookUpClass) 19:28:07 errors off 19:28:17 Looking through the source of the obj-c bridge 19:28:29 adamvh: Are you writing this is some poetic form? It doesn't look like any sonnet I'm familar with ;) 19:28:54 Sorry, I just figure its best not to dump massive bunches of text over IRC 19:29:02 I will increase the mean sentence size :p 19:29:31 adamvh: It might also help if you lisppaste the errors. 19:32:15 clop [~jared@moat3.centtech.com] has joined #ccl 19:32:40 OK, one sec - sorry something came up. 19:33:25 I'll just dump the top four stack frames from SLIME 19:35:00 http://paste.lisp.org/display/118806 19:36:02 I would guess that the .dylib containing my class never gets loaded 19:36:17 And poking around the objc-bridge source seems to confirm this suspicion 19:36:30 -!- alms_ [~alms_@146-115-42-237.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [Quit: alms_] 19:36:33 The only call to open-shared-library I could find in that source 19:36:42 opens the cocoa dylib 19:37:26 So presumably the obj-c bridge assumes that every class you try to load is in the cocoa framework somewhere. 19:37:49 So, you now have a directory darwin-x86-headers/my-framework/ with your .cdb files in it? 19:37:58 (and you're using a 32-bit lisp?) 19:38:22 Yeah I 'm on Leopard and I didn't feel like getting xcode to build the 64-bit framework 19:38:45 And yes, although h-to-ffi 19:38:54 seems to reproduce the entire path structure 19:38:57 starting with the root 19:39:02 of the framework 19:39:08 So it's like 19:40:20 Never mind that last - they're all sitting in darwin-x86-headers/GTResourceFork 19:40:22 alms_ [~alms_@146-115-42-237.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 19:40:34 And presumably they are being loaded 19:40:54 (#_ objc_LookUpClass) is returning a null pointer 19:41:02 is where the code fails 19:42:17 So CCL already knows the name of my class, and asks the Objective-C runtime for it, at which point the objective-c runtime fails to return it. 19:42:21 sswords [~sswords@moat3.centtech.com] has joined #ccl 19:42:45 Which leads me to believe that the dylib has simply not been loaded 19:43:19 It's not clear to me how GTResourceFork would enter the picture just from doing (require 'cocoa). 19:44:29 It seems that something in the objective-C bridge iterates over all of the .cdb files 19:44:35 in darwin-x86 headers 19:51:01 I don't believe that's the case, though I could be wrong. What code are you looking at that leads you make that guess? 19:51:38 Just a sec, let me look 19:54:19 http://paste.lisp.org/display/118807 19:54:35 The presence of the macro cdb-enumerate-keys 19:55:24 This function, I believe, is in the stack trace of the error 19:56:47 ccl::do-interface-dirs only iterates over the interfaces currently being "used". (ccl::do-interface-dirs (d) (print d)) would show you which dirs the lisp is consulting. 19:57:13 Is it possible that you altered the files in darwin-x86-headers/cocoa/ somehow? 19:58:48 # 19:58:48 # 19:58:48 # 19:59:08 so, indeed, gtresourcefork has somehow found its way into that. 19:59:41 something in ccl-init.lisp or ccl-ide-init.lisp, perhaps? 19:59:53 Would ccl::parse-standard-ffi-files do that? 20:00:05 I feel like that is by far the most likely culprit 20:00:10 for clobbering the list of interface dirs 20:00:39 hmm 20:00:43 let me restart slime and see what happens 20:01:30 Yeah, it works now. 20:03:33 Hmm - perhaps ccl::parse-standard-ffi-files should be modified not to do that 20:06:02 milanj [~milanj_@93-86-230-158.dynamic.isp.telekom.rs] has joined #ccl 20:11:01 adamvh, I see you talking about reloading Slime, which must mean you got it working again. What did you do? 20:13:36 anRch [~markmilli@64.134.102.93] has joined #ccl 20:16:00 I was setting swank:*communication-style* to :fd-handler in .swank.lisp 20:16:26 This is apparently a CMUCL-derivative only feature 20:16:52 I had been doing that because that was the best way to get lispbuilder-sdl to work with SBCL 20:17:26 However, someone suggested a different workaround for CCL and SLIME 20:17:56 which I have yet to try, since I have to sort out the cocoa portion of my application before sorting out the SDL portion of the application 20:18:11 Anyways, thanks all once again. 20:24:40 -!- adamvh [~adamvh@adsl-99-103-186-186.dsl.sfldmi.sbcglobal.net] has quit [Quit: adamvh] 21:08:43 -!- anRch [~markmilli@64.134.102.93] has quit [Quit: anRch] 21:41:31 Fare [~Fare@ita4fw1.itasoftware.com] has joined #ccl 21:58:53 adamvh [~adamvh@adsl-99-103-186-186.dsl.sfldmi.sbcglobal.net] has joined #ccl 22:04:30 batrick [~batrick@nmap/developer/batrick] has joined #ccl 22:04:45 -!- batrick [~batrick@nmap/developer/batrick] has left #ccl 22:23:40 -!- adamvh [~adamvh@adsl-99-103-186-186.dsl.sfldmi.sbcglobal.net] has quit [Quit: adamvh] 22:50:32 hi 22:58:00 I see that some externals in the CCL svn are non-versioned. Isn't that an issue wrt reproducibility of builds? 23:03:52 -!- milanj [~milanj_@93-86-230-158.dynamic.isp.telekom.rs] has quit [Ping timeout: 246 seconds] 23:22:04 -!- jdz [~jdz@host151-111-dynamic.15-87-r.retail.telecomitalia.it] has quit [Ping timeout: 246 seconds] 23:50:23 Fare: The externals are used kind of like symbolic links to refer to the subdirectories of source/ (in the same branch). I agree that it's a difficulty if you want to build, say, ccl-1.6 at revision 123, because the externals will always fetch HEAD. 23:50:54 adamvh [~adamvh@adsl-99-103-186-186.dsl.sfldmi.sbcglobal.net] has joined #ccl 23:50:58 couldn't you have a script that just refreshes the checked in externals? 23:51:14 or checks out things at matching version? etc. 23:51:25 this kind of defeats versioning 23:51:39 -!- Fare [~Fare@ita4fw1.itasoftware.com] has quit [Quit: Leaving]