| 00:00.27 | brlcad | the accessors will definitely need to know the type completely, but they are by design all private |
| 00:00.50 | starseeker | they're defined with the EXPORT stuff? |
| 00:00.58 | brlcad | it's okay if the struct itself ends up being publicly declared -- you just leave a comment saying "don't access this directly" |
| 00:01.08 | brlcad | the EXPORT stuff is just windows foo |
| 00:01.19 | starseeker | ah, BU_EXTERN then? |
| 00:01.24 | brlcad | same thing |
| 00:01.38 | starseeker | raises eyebrow |
| 00:01.47 | starseeker | ah, I hadn't realized that |
| 00:01.58 | brlcad | that's just a wrapper for windows and for supporting older k&r compilers |
| 00:02.18 | brlcad | pre ansi-C, you would declare functions just by name, no arguments |
| 00:02.40 | starseeker | Oh, OK. (yech) |
| 00:02.45 | brlcad | e.g., extern void *malloc(); |
| 00:03.08 | starseeker | that must have made for some entertaining debugging |
| 00:03.58 | brlcad | having the params just gives it more things it can test for when looking for type mismatches, can abort earlier during compilation |
| 00:04.21 | brlcad | did you ever get to writing any regex code? |
| 00:04.44 | starseeker | erm. A little during the search work perhaps |
| 00:05.21 | brlcad | well if you recall, struct regex aka regex_t is a lot like how I see our struct ged |
| 00:05.33 | starseeker | OK :-) |
| 00:05.40 | starseeker | pulls up the regex header... |
| 00:05.57 | brlcad | you pass it into regcomp() and regexec() pretty much without any care in the world |
| 00:06.39 | starseeker | chuckles - looks like regex could use some enum work :-P |
| 00:09.09 | starseeker | eyes ged.h and decides to start transcribing it into a new ged.h, attempting things like enum defs and de-Tclifying as he goes, then make the C code match the header... |
| 00:09.56 | brlcad | hm, wouldn't mix de-tcling at the same time.. |
| 00:10.02 | brlcad | that can cascade changes |
| 00:10.45 | brlcad | each type/signature change is probably a good commit-state in itself |
| 00:11.13 | starseeker | ah. OK, I was pondering a branch to do the testing in |
| 00:11.58 | brlcad | fwiw, enums vs defs isn't nearly as an important issue as, say, getting rid of tcl and having clear private/public separation |
| 00:12.09 | brlcad | branch? what's risky? |
| 00:12.33 | starseeker | mucking with the headers and ged structs and proceeding to break everything using libged ;-) |
| 00:12.54 | starseeker | <insert bull in china shop metaphor here> |
| 00:13.16 | brlcad | that's not very risky -- that'll break compilation up front for most changes if you do something wrong |
| 00:13.22 | brlcad | and all the more reason to go at it incremental |
| 00:13.40 | starseeker | OK, so subtle breakage is less likely? |
| 00:13.49 | brlcad | yeah, not very |
| 00:13.59 | starseeker | right :-) |
| 00:14.40 | brlcad | yeah, I can't even think of something subtle that could happen that won't get caught during compilation so long as you're not forcing casts |
| 00:14.51 | starseeker | would LOVE to start by converting the results string to something more useful for search exec, but knows that's going to be a LOT of code to change... |
| 00:15.09 | brlcad | so focus on just that though |
| 00:15.31 | brlcad | separate the private/public so you can have a place to make the private accessor func for the resulst string |
| 00:15.48 | brlcad | update the code to use the new accessor |
| 00:16.21 | starseeker | there is a ged_private.h - is that where such things should go? |
| 00:16.34 | brlcad | update the accessor implementation to store in a list container instead of a string under the hood |
| 00:16.50 | brlcad | then add an iterator for results, all done ;) |
| 00:17.46 | brlcad | yeah, ged_private.h is a start .. could use some cleanup but it's got a lot of the existing private funcs |
| 00:18.15 | starseeker | brlcad: is there an example of a private accessor function I can use for a template? (maybe some of libbu's stuff?) |
| 00:18.25 | brlcad | there really needs to be a common naming convention to separate public from private -- they can't all be ged_* prefixed |
| 00:18.33 | starseeker | ah |
| 00:18.46 | brlcad | right now, they're all ged_ GED_ etc.. |
| 00:18.59 | starseeker | so, should ged_init (called by GED_INIT) be private? |
| 00:19.11 | starseeker | (for example) |
| 00:19.31 | brlcad | ged_open_dbip() sounds like a pretty private func |
| 00:22.47 | brlcad | not sure it's a good "example", it's more just thinking about whether a function is something an external developer would code to directly when using libged as a library, like libpng |
| 00:23.33 | brlcad | in that vein, even our "testing" macros that are used extensively in our implementation, like GED_CHECK_DATABASE_OPEN() become questionable |
| 00:23.52 | brlcad | should that be exposed? maybe, maybe not |
| 00:24.00 | starseeker | OK. Do I take it correctly that functions called in #define GED_**** macros do need to be public? |
| 00:24.33 | brlcad | inclination would be to just expose the primary command ged_*() functions for starters, then see what's actually needed/used by mged .. and if it's something that shouldn't be migrated to libged, then it's something that needs to be public |
| 00:24.44 | starseeker | Oh, so the question is whether GED_CHECK_DATABASE_OPEN would ever be needed outside of libged itself |
| 00:24.48 | brlcad | no, not necessary |
| 00:24.55 | brlcad | right |
| 00:25.29 | brlcad | no to the macros, right to whether it needs to be used outside libged :) |
| 00:25.43 | starseeker | so first step is to rename according to private convention the stuff already in ged_private, and then start migrating things to it as it appears they are used only in libged |
| 00:26.00 | brlcad | yeah, sure |
| 00:26.25 | starseeker | is the naming convention for structs as well as functions, or just functions? |
| 00:26.38 | brlcad | what do you mean? |
| 00:27.07 | starseeker | well, there's a struct in ged_private.h named ged_id_names - should that be _ged_id_names instead since it's private? |
| 00:27.52 | brlcad | if the convention for private names is to prefix _ged_ then sure :) |
| 00:28.03 | brlcad | should be consistent |
| 00:28.37 | starseeker | nods. Is there a de-facto standard in BRL-CAD or C generally? |
| 00:28.37 | brlcad | ged_ and GED_ are public, so if it's not public.. they obviously shouldn't use that |
| 00:28.44 | starseeker | right |
| 00:28.53 | brlcad | could be as simple as _ged_ and _GED_ if it's private, not sure if that's good enough or not without more thought |
| 00:29.12 | Ralith | that is the de-facto standard, is it not? |
| 00:29.35 | starseeker | will start there - search/replace will fix it later if need be :-P |
| 00:30.04 | starseeker | Ralith: meh - no response to the Qt-in-Ogre posting in the Ogre forums |
| 00:30.21 | starseeker | apparently we're still up with the state of the art ;-) |
| 00:31.13 | Ralith | starseeker: that's rather dissapointing. |
| 00:31.24 | Ralith | we should replace it with a real Ogre or Qt rendering backend at some point, anyway. |
| 00:31.52 | starseeker | Ralith: did you see the link I posted? Not sure if Qt embedded relates to what we need, but interesting none the lest |
| 00:31.59 | starseeker | less even |
| 00:32.12 | Ralith | don't think I did |
| 00:32.48 | starseeker | http://labs.trolltech.com/blogs/2009/10/02/introducing-new-port-of-qt-to-your-favourite-platform/ |
| 00:32.51 | brlcad | underscore is as close as anything to "common convention" -- the problem is the C preprocessor and names in caps as it technically claims a set for compiler mangling iirc |
| 00:33.44 | starseeker | brlcad: erm. ~ged and ~GED ? |
| 00:35.01 | brlcad | heh, invalid |
| 00:35.09 | brlcad | go with _ged_ that should be fine |
| 00:35.27 | brlcad | matches the little bit of consistency with libbu and friends |
| 00:35.37 | starseeker | k. what about all caps - P_GED maybe? |
| 00:35.59 | brlcad | case is already conventioned |
| 00:36.34 | starseeker | ? there are all capital defines in both ged.h and ged_private.h |
| 00:36.34 | brlcad | _ged_lowercase_private_function() and _GED_PRIVATE_MACRO_OR_DEFINE |
| 00:36.39 | starseeker | Oh |
| 00:36.50 | starseeker | that won't break the preprocessor? |
| 00:37.18 | brlcad | there are some bastard hybrids from the *_obj funcs that should die, mixed underscore camelCasers.. |
| 00:37.28 | brlcad | no, it doesn't break it |
| 00:38.12 | Ralith | brlcad: the ones reserved by the C standard are __foo only, I believe |
| 00:38.35 | starseeker | starts on ged_private.h |
| 00:38.36 | brlcad | it just means that they might use the same name .. which is so highly unlikely regardless |
| 00:38.46 | Ralith | I think _foo is actually reserved, or at least recommended, for private use within programs, conveniently. |
| 00:40.40 | Ralith | starseeker: ooh: "Letâs look at the âminimalâ backend, which is a complete example showing how to use a QImage as a display device:" |
| 00:40.49 | Ralith | this could be useful. |
| 00:41.15 | Ralith | in fact this could make a real Qt-in-Ogre solution pretty easy to do |
| 00:42.20 | Ralith | needs to study up on how the relevant type of texture overlay is done in Ogre |
| 00:47.13 | brlcad | here's the relevant section, from the standard regarding names in the global namespace: "Each name that contains a double underscore __ or begins with an underscore followed by an uppercase letter (2.11) is reserved to the implementation for any use." |
| 00:47.58 | starseeker | OK, so if we end up conflicting on the caps cases we're in the wrong and need to rename |
| 00:48.16 | brlcad | basically |
| 00:49.27 | brlcad | given those are actually preprocessor defines, even arguable that they're not in the global namespace |
| 01:04.55 | Ralith | the spec is probably clear on whether that's not the case somewhere. |
| 01:05.01 | Ralith | definition of namespace perhaps? |
| 01:08.48 | brlcad | yeah, I'm just not that worried to read it all up in detail .. and given there is a separate section on macro name restrictions, more an indication that we're taking a gamble like everyone else |
| 01:09.37 | brlcad | that other clause was actually in any namespace -- all names |
| 01:10.19 | brlcad | the global namespace restriction is even more broad, "Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace." |
| 02:10.42 | CIA-33 | BRL-CAD: 03starseeker * r36188 10/brlcad/trunk/src/libged/ (62 files): Start converting private ged structures, defines and functions to using an underscore prefix. Done through _ged_getspace. |
| 02:10.57 | starseeker | brlcad: how would a public macro make use of a private function without including the private header? Doesn't the preprocessor expand out the code of the macro everywhere it is used (and thus any code that uses it will need to know about functions it uses?) |
| 02:27.20 | brlcad | it wouldn't |
| 02:28.27 | brlcad | it's either a private macro or should be a function instead |
| 02:31.34 | brlcad | haven't seen a compelling reason why the various existing macros are macros and not functions other than it was conceived they'd just be very short functions (in which case they could have just been inline functions instead) |
| 02:32.20 | brlcad | they were also merely the start at capturing code patterns internal to the ged func implementations |
| 02:54.26 | ``Erik | boogies to duke spirit |
| 03:52.07 | CIA-33 | BRL-CAD: 03starseeker * r36189 10/brlcad/branches/dmtogl-branch/src/other/togl/Makefile.in: Meh. togl_ws.h gets generated in the build directory not the source directory - handle it differently. |
| 03:54.52 | brlcad | shakes fist at configuring the second IP address |
| 08:04.06 | *** join/#brlcad Ralith (n=ralith@69.90.49.189) |
| 10:28.50 | *** join/#brlcad parigaudi (n=quassel@217.91.127.94) |
| 11:29.47 | *** join/#brlcad parigaudi (n=quassel@217.91.127.94) |
| 11:40.23 | *** join/#brlcad archivist (n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT VICTIM] |
| 11:42.59 | *** join/#brlcad parigaudi (n=quassel@217.91.127.94) |
| 12:10.19 | *** join/#brlcad akafubu (n=akafubu@unaffiliated/akafubu) [NETSPLIT VICTIM] |
| 12:10.19 | *** join/#brlcad b0ef (n=b0ef@157.26.202.84.customer.cdi.no) [NETSPLIT VICTIM] |
| 13:28.48 | *** join/#brlcad mafm (n=mafm@42.Red-83-40-127.dynamicIP.rima-tde.net) |
| 15:34.55 | CIA-33 | BRL-CAD: 03indianlarry * r36190 10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: |
| 15:34.55 | CIA-33 | BRL-CAD: added code to make sure UV pullback solver keeps within |
| 15:34.55 | CIA-33 | BRL-CAD: current node bounding UV |
| 15:38.00 | CIA-33 | BRL-CAD: 03indianlarry * r36191 10/brlcad/trunk/src/other/openNURBS/opennurbs_brep.cpp: |
| 15:38.00 | CIA-33 | BRL-CAD: changed trim error tolerance to be relative to UV size not trim point |
| 15:38.00 | CIA-33 | BRL-CAD: distance |
| 16:33.01 | CIA-33 | BRL-CAD: 03indianlarry * r36192 10/brlcad/trunk/src/other/step/src/ (4 files in 2 dirs): Cleaned up some memory freeing calls reported by valgrind |
| 17:23.20 | CIA-33 | BRL-CAD: 03starseeker * r36193 10/brlcad/trunk/src/conv/ (358 files in 2 dirs): Commit initial upload of Keith's step-g code. Makefile.am is updated, but still some issues so disable it in src/other/Makefile.am for the time being. |
| 17:25.23 | *** join/#brlcad Axman6 (n=Axman6@210.9.142.242) |
| 17:55.41 | CIA-33 | BRL-CAD: 03bob1961 * r36194 10/brlcad/trunk/src/libged/ (blast.c clip.c erase.c loadview.c open.c preview.c zap.c): Revert function names for _ged_zap and _ged_clip. |
| 18:09.32 | CIA-33 | BRL-CAD: 03bob1961 * r36195 10/brlcad/trunk/src/libdm/dm-ogl.c: Get rid of a call to bu_log. |
| 19:06.33 | *** join/#brlcad cpc26 (n=cpc26@72.170.156.242) |
| 19:12.03 | CIA-33 | BRL-CAD: 03starseeker * r36196 10/brlcad/trunk/src/libged/ (9 files): Rename a few more things in ged_private, remove clip and vclip as they're public - still a ways to go. |
| 19:57.56 | brlcad | anytime the function is not the basic gedp/argc/argv signature, the header should probably document why it's a public function |
| 19:58.19 | brlcad | and it's a candidate to get refactored, scrutinized as to why/if it needs to be public |
| 19:59.09 | brlcad | as it's more likely maldesigned |
| 20:00.12 | starseeker | nods - I'm just hitting ged_private in a general sweep right now - once that is done can get more thoughtful |
| 20:00.54 | starseeker | probably want to involve Bob in those discussions |
| 20:11.54 | CIA-33 | BRL-CAD: 03indianlarry * r36197 10/brlcad/trunk/src/conv/step/Makefile.am: |
| 20:11.54 | CIA-33 | BRL-CAD: Added fedex_src and fedex_hdrs directly to build, currently builds from |
| 20:11.54 | CIA-33 | BRL-CAD: a static copy of the SCL sources. |
| 20:17.43 | CIA-33 | BRL-CAD: 03starseeker * r36198 10/brlcad/trunk/src/libged/ (27 files): More ged_private renaming. |
| 20:29.05 | *** join/#brlcad poolio (n=poolio@BZ.BZFLAG.BZ) |
| 20:29.32 | starseeker | hey Ben |
| 20:30.01 | poolio | howdy starseeker |
| 20:30.07 | poolio | how goes the brep? |
| 20:30.12 | starseeker | well, actually |
| 20:30.22 | starseeker | you've probably seen the progress? |
| 20:31.18 | poolio | actually no, I've been insanely busy with midterms. do you have pretty pictures? |
| 20:31.50 | starseeker | not to hand, but try running the proc-db csgbrep and raytracing the results :-) |
| 20:32.48 | poolio | ooo, I'll try it in an hour or so once I'm done recompiling :) |
| 20:33.36 | starseeker | more work to do for full robustness, but pretty good progress |
| 20:35.01 | poolio | sweet! |
| 20:48.51 | poolio | ah shoot, I was going back through the versions of the brep files, and I managed to not commit a ton of code >_< |
| 21:06.04 | starseeker | ? |
| 21:06.14 | starseeker | poolio: you mean there was duplicated effort? |
| 21:10.05 | starseeker | auuugh... |
| 21:13.47 | CIA-33 | BRL-CAD: 03starseeker * r36199 10/brlcad/trunk/src/libged/ (42 files): OK, the remainder of ged_private is now prefixed. |
| 22:11.18 | starseeker | arrrrgh - ../../../../brlcad/src/conv/step/RepresentationItem.h:45: error: 'SCLP23' has not been declared |
| 22:32.25 | brlcad | poolio: some shots of the raytracing in action here: http://brlcad.org/tmp/nurbs2brep/ |
| 22:32.36 | brlcad | some before and after images of the wireframe and render |
| 23:03.43 | *** join/#brlcad Ralith (n=ralith@69.90.49.189) |