| 00:03.30 | polyspin | anyone know if a cocoa app can "know" the path to it's own executable? |
| 00:06.10 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/sh/make_pkg.sh: ls file sizes are in bytes, we need kilobytes |
| 00:07.06 | polyspin | ls -s? |
| 00:07.09 | brlcad | yes.. /me looks it up |
| 00:11.06 | brlcad | couple ways |
| 00:11.51 | brlcad | Cocoa way would be the NSBundle mainBundle class method |
| 00:12.04 | brlcad | Carbon way would be FSFindFolder() |
| 00:12.25 | polyspin | Thanks. I see that now. I couldn't remember "bundle" |
| 00:15.14 | polyspin | cool, build the extra app, drop it in the MacOSX folder and "pathForAuxiliaryExecutable" will *find* it |
| 00:22.43 | polyspin | I suspect the runtime env notes where the executable loads. That's how the app can find the .nib files |
| 01:18.33 | brlcad | 141 mb compressed for ia32 .. that is so odd |
| 02:39.25 | brlcad | ugh |
| 02:39.39 | brlcad | the .so problem is a libtool version conflict |
| 02:45.45 | brlcad | the AC_PROG_LIBTOOL was added from 1.5, so if you run autogen.sh or autoreconf on a system with 1.4, it looses the suffix for shared libs.. |
| 04:47.19 | *** join/#brlcad parasite-- (~parasite@69-30-99-234.dv1sn.easystreet.com) |
| 05:19.36 | *** join/#brlcad parasite-- (~parasite@69-30-99-234.dv1sn.easystreet.com) [NETSPLIT VICTIM] |
| 06:15.21 | *** join/#brlcad Pimpi (~frank@p50821686.dip0.t-ipconnect.de) |
| 06:57.11 | *** join/#brlcad noyb (~noyb@wbar2.lax1-4-8-213-215.dsl-verizon.net) |
| 08:13.45 | *** join/#brlcad ChanServ (ChanServ@services.) |
| 08:13.45 | *** mode/#brlcad [+o ChanServ] by irc.freenode.net |
| 13:59.35 | *** join/#brlcad amathis (~amathis@cpe-024-165-189-009.midsouth.rr.com) |
| 14:28.38 | jano | bork |
| 17:00.54 | *** join/#brlcad slomo (~jerry@rdbck-265.palmer.mtaonline.net) |
| 17:01.45 | brlcad | hello slomo |
| 17:01.54 | slomo | howdy |
| 18:12.05 | *** part/#brlcad slomo (~jerry@rdbck-265.palmer.mtaonline.net) |
| 23:14.09 | *** join/#brlcad polyspin (~butler@bz.bzflag.bz) |
| 23:14.25 | polyspin | Yo ho ho! |
| 23:21.04 | brlcad | heh |
| 23:23.06 | brlcad | polyspin: don't know if you saw, but I found the cause of the missing shared library suffix problem.. hopefully i'll figure out a good fix soon |
| 23:23.19 | polyspin | Excellent! |
| 23:23.37 | polyspin | I've been wrapping up pKgen to day. It's almost completely behind me. |
| 23:23.53 | polyspin | Playing with doxygen right now. Looks way cool |
| 23:24.16 | polyspin | What was the gem from #gforge? |
| 23:24.38 | polyspin | Wanna go to a movie tonight? We're thinking of going to see Aviator |
| 23:25.02 | brlcad | yeah, kermit just called |
| 23:25.15 | brlcad | i'll be over in about 20 |
| 23:25.41 | polyspin | ab fab |
| 23:26.39 | brlcad | the gforge folks helped solve a couple db problems, but the real gem is their docs.. their documentation is in docbook. excellent example with makefile rules |
| 23:27.10 | polyspin | Like it better than doxygen? |
| 23:29.39 | brlcad | No no.. |
| 23:29.52 | brlcad | different documentation needs |
| 23:30.03 | brlcad | doxygen is the way to go for code/dev documentation |
| 23:30.48 | brlcad | docbook would be where I'd go for things like the volumes |
| 23:31.15 | polyspin | Yes. For that I agree. |
| 23:31.18 | brlcad | you can go from docbook to html, pdf, tek, txt, etc from a single formatted source |
| 23:31.49 | brlcad | plus, text format that could be shoved into cvs and organized/maintained there |
| 23:32.37 | polyspin | The only problem is the lack of a nice, industry standard WYSIWYG editor. We looked at Docbook a couple of years ago when writing Vol-II |
| 23:32.49 | brlcad | the fact that they had a nice make-based functioning example was part of the gemmage |
| 23:33.37 | polyspin | how familiar are you with doxygen? |
| 23:33.53 | polyspin | I'm looking to make a "section" that certain file's contents live in |
| 23:34.00 | polyspin | Know hou? |
| 23:34.07 | polyspin | s/u/w/ |
| 23:34.42 | brlcad | a per-file section? |
| 23:34.54 | polyspin | no. A per-library section |
| 23:35.03 | polyspin | eg. "libbu" |
| 23:35.15 | brlcad | mm.. groups |
| 23:35.41 | brlcad | i've ran across the syntax, but it's a pita to keep maintained sometimes |
| 23:36.17 | polyspin | I tried "addtogroup" but it doesn't provide enough content in the result. |
| 23:36.30 | brlcad | you have to @defgroup somewhere |
| 23:37.08 | brlcad | and mark everything you want in it with @ingroup groupname |
| 23:37.52 | brlcad | you can @ingroup group1 group2 group3 too |
| 23:37.54 | polyspin | yes. addtogroup and defgroup are functionally similar |
| 23:38.42 | brlcad | right, just gets rid of the warning |
| 23:39.58 | brlcad | you might be able to get away with putting an @ingroup in the file block |
| 23:40.08 | brlcad | to get the whole file contents added to some group |
| 23:40.53 | brlcad | the file block is the first section in a file with a @file |
| 23:41.59 | polyspin | ingroup does not work in the file section |
| 23:44.35 | brlcad | ahh |
| 23:45.20 | brlcad | that's odd. the docs say it can go there.. |
| 23:45.25 | brlcad | http://www.stack.nl/~dimitri/doxygen/commands.html#cmdingroup |
| 23:47.23 | polyspin | thx |
| 23:48.28 | brlcad | i've never used it, but @namespace might do the trick too |
| 23:49.40 | polyspin | If I wrap the file in @addtogroup foo @{ ... @} it works |
| 23:50.13 | brlcad | ahh, oops, yea :) |
| 23:50.17 | brlcad | minor detail :) |
| 23:51.59 | polyspin | Argh. And it cannot be in the @file block |