| 00:35.41 | louipc | whoa |
| 02:27.00 | brlcad | 102480 surface edges, 27195 edge loops, 51393 edge curves, 18359 advanced faces, 10015 cylindrical surfaces, 2691 bspline surfaces, ... |
| 02:56.31 | CIA-63 | BRL-CAD: 03brlcad * r46858 10/brlcad/trunk/src/librt/db_match.c: get rid of the stupid BU_ASSERTING, they're really just UNUSED. |
| 02:56.50 | CIA-63 | BRL-CAD: 03brlcad * r46859 10/brlcad/trunk/src/librt/prep.c: client_data isn't actually UNUSED.. |
| 02:58.15 | CIA-63 | BRL-CAD: 03brlcad * r46860 10/brlcad/trunk/src/librt/ (db_match.c prep.c): ws consistency cleanup |
| 03:11.28 | CIA-63 | BRL-CAD: 03brlcad * r46861 10/brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c: hit_count is potentially used prior to initialization, account for it and all of his friends by initializing to zero/null. |
| 03:15.19 | CIA-63 | BRL-CAD: 03brlcad * r46862 10/brlcad/trunk/src/librt/primitives/ (ehy/ehy.c epa/epa.c hyp/hyp.c rpc/rpc.c submodel/submodel.c): remove a slew of BU_ASSERT hacks that were only added to quell use warnings. use the UNUSED() macro for betterness. |
| 03:15.57 | CIA-63 | BRL-CAD: 03brlcad * r46863 10/brlcad/trunk/src/libgcv/bottess.c: someone was just kidding, tol isn't really unused |
| 03:44.09 | CIA-63 | BRL-CAD: 03brlcad * r46864 10/brlcad/trunk/src/libged/push.c: curtree is actually used. hard to miss it. |
| 04:11.21 | CIA-63 | BRL-CAD: 03brlcad * r46865 10/brlcad/trunk/include/nmg.h: not your responsibility to define NULL and it's a crappy definition anyways. |
| 05:12.06 | CIA-63 | BRL-CAD: 03brlcad * r46866 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: more unused LIARS |
| 05:14.57 | CIA-63 | BRL-CAD: 03brlcad * r46867 10/brlcad/trunk/src/liboptical/ (sh_air.c sh_light.c): and a few more checks added for quellage, but they're really UNUSED |
| 05:28.59 | CIA-63 | BRL-CAD: 03brlcad * r46868 10/brlcad/trunk/src/ (mged/dodraw.c remrt/remrt.c): couple more UNUSED tricksters |
| 05:32.28 | CIA-63 | BRL-CAD: 03brlcad * r46869 10/brlcad/trunk/include/common.h: |
| 05:32.28 | CIA-63 | BRL-CAD: add a new IGNORE() macro for use by all of the various macros that turn into |
| 05:32.28 | CIA-63 | BRL-CAD: 'nothing' if the right compilation flags are set. for now, go with a simple |
| 05:32.28 | CIA-63 | BRL-CAD: '(void)param' to quell unused usage warnings but begs testing on msvc2010. |
| 05:32.28 | CIA-63 | BRL-CAD: while we're at it, mangle parameters marked as UNUSED() with a prefix so we can |
| 05:32.28 | CIA-63 | BRL-CAD: catch failings in both directions, catching instances where UNUSED() was |
| 05:32.29 | CIA-63 | BRL-CAD: erroneously set yet the parameter is actually used. |
| 05:34.39 | CIA-63 | BRL-CAD: 03brlcad * r46870 10/brlcad/trunk/include/ (bu.h magic.h raytrace.h): |
| 05:34.39 | CIA-63 | BRL-CAD: put the new IGNORE() macro to use in place of (void)0 since we were still |
| 05:34.39 | CIA-63 | BRL-CAD: getting strict warnings about parameters not being used because they were only |
| 05:34.39 | CIA-63 | BRL-CAD: being used in ifdef sections or CK macros. IGNORE() shouldn't be used in |
| 05:34.39 | CIA-63 | BRL-CAD: application code, but these bombing/checking macros are perfect use cases. |
| 05:37.06 | brlcad | whew, finally got all of them |
| 05:43.38 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 07:13.28 | brlcad | boo, hiss .. step import churned and churned but only a few things came in |
| 07:13.42 | brlcad | and the few that did come in aren't looking so hot |
| 07:13.56 | brlcad | wanders |
| 08:24.42 | *** join/#brlcad dli_ (~dli@dsl-173-248-196-72.acanac.net) | |
| 09:43.08 | *** join/#brlcad dli_ (~dli@dsl-173-248-235-17.acanac.net) | |
| 12:54.32 | abhi2011 | i have been getting this stranger error whenever I try to include raytrace.h in simphysics.cpp |
| 12:55.30 | abhi2011 | the error is : /home/abhi/socis/brlcad/include/brep.h:36:23: fatal error: opennurbs.h: No such file or directory |
| 12:56.21 | abhi2011 | raytrace.h:47 > rtgeom.h:42:0, > brep.h |
| 12:56.53 | abhi2011 | this is because now I am trying to do librt stuff inside the cpp file |
| 12:57.33 | abhi2011 | I need to use rt for detecting overlaps and generate contact points, but I do not want to that in the simulate.c file |
| 12:58.08 | abhi2011 | so I am going to transforms the objects into their new position in the db and then shoot rays within functions defined in the cpp file |
| 12:58.46 | abhi2011 | but it seems that the minute i try to include raytrace.h in the cpp file the build breaks :( |
| 13:00.39 | abhi2011 | i of course need raytrace.h included to have access to rt_matrix_transform() to position the simulated objects, after each physics step |
| 13:40.39 | ``Erik | probably means an omission from the cmake/automake file about legitimage paths... though this does expose something; rt_matrix_transform might be better placed as bn_matrix_transform O.o |
| 14:12.10 | brlcad | rt_matrix_transform isn't just a general matrix function |
| 14:12.23 | brlcad | it applies that matrix and writes it out on specified geometry |
| 14:13.10 | brlcad | the db internal geometry is transformed, not the matrix |
| 14:19.12 | brlcad | abhi2011: so you're somehow missing a common include directory (src/other/opennurbs) |
| 14:19.42 | brlcad | what does "make VERBOSE=1" output (pastebin)? |
| 14:27.30 | ``Erik | rt_write_matrix(bn_matrix_transform(m)); ? |
| 14:29.47 | ``Erik | (symbol documentation, I spew what I assume as a reasonably knowledgeable codemonkey) |
| 14:31.32 | brlcad | that's my point, there is no transform being done on a matrix |
| 14:31.46 | brlcad | so it's just be a rename to rt_write_matrix perhaps |
| 14:32.05 | brlcad | rt_apply_matrix() is probably more apt |
| 14:32.17 | brlcad | since it won't necessarily "write" anything |
| 14:33.38 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:35.30 | ``Erik | I'm in favor of renaming that function, fwiw |
| 14:39.07 | CIA-63 | BRL-CAD: 03starseeker * r46871 10/brlcad/trunk/src/libged/CMakeLists.txt: Add the opennurbs include dir to libged's include list |
| 14:40.32 | starseeker | abhi2011: give that a shot |
| 14:42.05 | brlcad | starseeker: it seems backwards (and it's not your fault, autotools is also to blame) to have to list include dirs like that |
| 14:44.20 | brlcad | think there should be top-level BU_CPPFLAGS, RT_CPPFLAGS, etc or BU_INCLUDE_DIRS, RT_INCLUDE_DIRS, etc that have those interface paths defined, then lower-level CMakeLists.txt files would just use them if they use the library |
| 14:44.50 | brlcad | otherwise we're just going to end up with "include everything all the time" and that's not very useful or safe |
| 14:45.38 | starseeker | disagrees - i never liked those vars in autotools, it made it difficult to see where a particular directory was coming from in the logic |
| 14:45.50 | starseeker | too much obfuscation |
| 14:46.13 | brlcad | the alternative is excessive replication |
| 14:46.41 | starseeker | how bad is that, really though? |
| 14:46.51 | starseeker | once set up, the changes aren't too bad |
| 14:47.00 | starseeker | (this one was a straightforward one-liner) |
| 14:47.24 | brlcad | short term gain, long term cost (like any code duplication) |
| 14:47.30 | brlcad | change one of them |
| 14:47.35 | starseeker | if this had happened with toplevel vars, I would have had to track back through to see what the toplevel vars contained and which one might be a logica candidate for this dir... |
| 14:47.49 | brlcad | you have to find the 400+ instances it's used (or dozens if it's per dir) |
| 14:48.04 | brlcad | doesn't have to be top-level vars |
| 14:48.24 | brlcad | in terms of encapsulation, it's make more sense for the libs to define their needs |
| 14:49.21 | brlcad | think of libbu as its own product, it'd declare cppflags that included tcl, for example .. but users of libbu just use libbu's declared interface |
| 14:50.10 | brlcad | that wasn't done for autotools because it wasn't easily doable with our recursive automake setup, so the variables propagated up to the top |
| 14:50.17 | brlcad | for cmake, that's not the case |
| 14:50.58 | starseeker | concedes the point, but still doesn't like the idea of "what gets included" being buried so deep - it feels like C++, digging through layers to find an int at the bottom of the type pile... |
| 14:54.16 | starseeker | but I always lose these arguments ;-), so let's see... how to do it... probably the BU_INCLUDE_DIRS approach would be best... |
| 14:54.24 | brlcad | another way to look at it -- just about every app (400+) uses librt which uses libbu which results in *always* needing paths for zlib, regex, tcl, opennurbs, .. always needing to include ${ZLIB_INCLUDE_DIR}, ${REGEX_INCLUDE_DIR}, ${TCL_INCLUDE_DIRS}, ${OPENNURBS_INCLUDE_DIR} |
| 14:54.58 | starseeker | nods - yeah, it would be a LoC reduction, no question |
| 14:55.08 | brlcad | there are minimally about 50 source dirs where those have to be specified |
| 14:55.36 | brlcad | add one more, rename one, remove one ... that's 50+ edits |
| 14:55.47 | brlcad | massive DRY fail :) |
| 14:58.18 | starseeker | I'm going to do one additional thing though, if I introduce the BU_INCLUDE_DIRS style mechanisms - I'm going to build a list of dirs and then remove duplicates before the actual include command, to try and keep the command line verbosity down... |
| 15:08.24 | brlcad | yeah, that'd be awesome |
| 15:08.35 | starseeker | blinks in surprise - apparently libbu doesn't use regex |
| 15:09.25 | brlcad | librt |
| 15:09.35 | starseeker | nods |
| 15:10.01 | starseeker | I knew it was in there, just a little startled it hasn't crept down to the libbu level yet |
| 15:10.23 | starseeker | would have thought some sort of regex something or other would have been packaged up for general consumption by now ;-) |
| 15:10.31 | brlcad | another benefit of the encapsulation, catch issues like that more obviously so you don't include regex by default everywhere bu is used |
| 15:11.06 | brlcad | regex it is needed, but indirect |
| 15:11.09 | brlcad | bu -> tcl -> regex |
| 15:11.28 | brlcad | so tcl should have it specified in tcl's include dirs |
| 15:11.35 | starseeker | nods |
| 15:12.18 | brlcad | last night was a good coding night, trying to get some new libbu interfaces in place |
| 15:12.34 | starseeker | sweet |
| 15:13.24 | brlcad | better string management to help with processing object names and lists of objects (which all of libged could use) |
| 15:13.47 | brlcad | basic things that makes one slap the forehead and ask why they weren't there 10 years ago |
| 15:14.04 | brlcad | but some more complex ones too, like globbing |
| 15:14.16 | starseeker | something beyond fnmatch? |
| 15:14.21 | brlcad | yep |
| 15:15.01 | starseeker | that would be awesome - I'd love to be able to do per-command globbing on mged command line to avoid having to quote the bejeezus out of search commands... |
| 15:15.03 | brlcad | basically a corollary to glob(3) |
| 15:15.16 | brlcad | including a mechanism for iterating |
| 15:28.32 | CIA-63 | BRL-CAD: 03starseeker * r46872 10/brlcad/trunk/src/ (3 files in 3 dirs): Start figuring out how to wrap includes needed for a directory into a variable and use that variable in other CMakeLists.txt files that are including the library |
| 15:48.38 | brlcad | hm, careful use there -- BU_INCLUDE_DIRS only needs to include headers used by the public headers |
| 15:49.00 | brlcad | implementation headers don't need to be included, they're still just regular include_dirs() |
| 15:49.24 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 15:50.11 | brlcad | uce-dirent, png being the two examples not publicly used |
| 15:50.47 | brlcad | zlib too, hm! |
| 15:51.09 | brlcad | those are INCLUDE_DIRS like regex, needed by src/other stuff |
| 15:52.20 | brlcad | opennurbs, png, and tkpng use zlib |
| 15:55.48 | brlcad | doesn't look like anything uses png publicly |
| 15:56.20 | brlcad | bu, fb, dm, ged, tclcad, and a few util tools use it privately |
| 16:53.22 | abhi2011 | brlcad: here is the verbose build output : http://bin.cakephp.org/view/1626192759 |
| 16:54.17 | abhi2011 | ah ok, just saw starseeker's update, will try it |
| 17:04.50 | CIA-63 | BRL-CAD: 03bob1961 * r46873 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Set zclip flag to 0 in ArcherCore::doLighting. |
| 17:13.00 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 17:25.50 | abhi2011 | cool, now the raytrace.h related errors are gone, however I also need to pass gedp to the functions in simphysics.cpp, so I have included ../ged_private.h in the simulate.h file(as that file declares struct ged in ged.h) |
| 17:26.24 | abhi2011 | i get this warning : /home/abhi/socis/brlcad/include/ged.h:2289:78: warning: âint ged_view(ged*, int, const char**)â hides constructor for âstruct ged_viewâ |
| 17:27.37 | starseeker | so... once we get tcl out of libbu, we'll have no need for BU_INCLUDE_DIRS? |
| 17:32.12 | CIA-63 | BRL-CAD: 03n_reed * r46874 10/brlcad/trunk/src/ (conv/obj-g_new.c libgcv/wfobj/tri_face.c): plugged a few leaks |
| 17:36.49 | abhi2011 | hmm I think the warning is coming because ged.h is being compiled by the c++ component of gcc |
| 17:37.09 | abhi2011 | otherwise no constructor stuff should have been seen |
| 17:39.08 | abhi2011 | i do need the gedp as i get the internal representation of a object using GED_DB_GET_INTERNAL(gedp,.... |
| 17:39.17 | abhi2011 | in the cpp file |
| 17:39.38 | abhi2011 | however I ll see if I can use just librt instead, so all gedp references can be removed |
| 17:45.13 | CIA-63 | BRL-CAD: 03starseeker * r46875 10/brlcad/trunk/src/ (4 files in 2 dirs): Swap in the new obj-g for the old, stop building both. |
| 17:54.51 | starseeker | didn't realize the current installed layout wasn't ideal... I'm not really sure how much logic would have to be reworked to suport another layout, I was assuming the current layout was *the* layout... |
| 17:56.36 | starseeker | thought the version number in the share subdirectory was to allow for warnings/wipeouts running one version of brlcad and having the root directory set to another version's location... then attempts to get "version x.y.z" data from that direcory would fail despite being set to the wrong directory... |
| 17:58.32 | starseeker | seemed like a nice way to avoid subtle "almost working but it failed" situations... |
| 19:17.24 | brlcad | abhi2011: you should only include ged_private.h if you use something that header provides -- just include ged.h directly |
| 19:18.27 | brlcad | starseeker: there's still a need for BU_INCLUDE_DIRS -- it's presently just the top-level include dir |
| 19:19.04 | brlcad | your logic that eliminates duplicates will take care of keeping only one instance, while letting bu-only and rt-only apps to behave correctly |
| 19:20.47 | brlcad | starseeker: having the versioned sub-directory does help with multi-version installs, that was also intentional |
| 19:21.50 | brlcad | but the fact that it's only the datadir wasn't -- the goal was fully versioned installs into a NON-VERSIONED root directory (like /usr) |
| 19:25.09 | brlcad | having separation of BRLCAD_DATA and BRLCAD_ROOT provides similar multi-redundancy protections from using the wrong data |
| 19:25.23 | brlcad | should probably just write this all up on the wiki |
| 19:36.20 | brlcad | n_reed: a cleanup chare, should mark all of the non-public functions as static in wfobj |
| 19:36.59 | n_reed | consider it done |
| 19:37.58 | n_reed | although HIDDEN would be better right? |
| 19:38.16 | brlcad | if there is value in being able to debug into that function, sure |
| 19:38.38 | brlcad | not for front-end code, that should use static |
| 19:38.58 | brlcad | but library funcs can use either -- HIDDEN for public API and discretion for non-public |
| 19:42.58 | n_reed | trying to understand... so the point of HIDDEN is just to allow toggling static-ness |
| 19:49.42 | CIA-63 | BRL-CAD: 03n_reed * r46876 10/brlcad/trunk/ (doc/docbook/system/man1/en/obj-g.xml src/conv/obj-g.c): some updates to obj-g documentation |
| 19:56.39 | starseeker | erm. the top level include dir I've been including in *all* of src via the src/CMakeLists.txt file... |
| 19:58.55 | brlcad | n_reed: basically |
| 19:59.50 | brlcad | some compilers will fully inline static functions at their discretion, making it impossible to set a breakpoint for debugging |
| 20:00.56 | brlcad | so if there is any value at any time to be able to debug into that function as a breakpoint (which there is for most public API, by definition), then HIDDEN should be used instead of static |
| 20:03.05 | brlcad | coincidentally, it also helps to avoid function name ambiguity by not allowing implementation-detail functions to have the same name as front-end application functions |
| 20:03.43 | brlcad | helps ensure functions are properly named with some non-conflicting prefix or other name convention |
| 20:09.22 | *** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 20:30.21 | CIA-63 | BRL-CAD: 03starseeker * r46877 10/brlcad/trunk/src/ (7 files in 7 dirs): Make another try at include_dirs updates... |
| 20:30.42 | starseeker | brlcad: that more what you had in mind? (before I go any further...) |
| 20:34.40 | brlcad | starseeker: yeah, that's looking great |
| 20:36.01 | starseeker | k. actually kinda handy that I was including the toplevel include in src - taking it out makes for a very simple "fail because I'm not converted yet" situation :-) |
| 20:36.16 | brlcad | also makes a couple low-lying fruit obvious, things that should get fixed |
| 20:36.31 | brlcad | like libfb needing to include pkg.h .. stupid |
| 20:36.52 | brlcad | should be hidden in the impl or passed by the caller |
| 20:37.10 | brlcad | it's for just one pointer |
| 20:40.31 | starseeker | I realize it's a bit premature, but with the "every command in libged being a plugin" approach, will the policy be that headers included by the individual commands not be part of the required includeds at the toplevel? Or, put another way, can we require that any include dir needed for ged users be specified at the toplevel ged CMakeLists.txt and not in the command subdirectories? |
| 20:45.21 | CIA-63 | BRL-CAD: 03starseeker * r46878 10/brlcad/trunk/src/ (3 files in 3 dirs): Convert a few more directories to new include_dir scheme |
| 20:52.26 | starseeker | man liborle is so small it's hardly even there... |
| 20:53.23 | starseeker | wonders if that could fold entirely into something else like libicv... |
| 21:28.43 | brlcad | that's just sad.. |
| 21:29.22 | brlcad | came across some old tcl code in some old directory in my data archive |
| 21:30.27 | brlcad | my fingerprints are all over it .. naming conventions, code structure, style .. and sure enough my name is in one of the files as the author |
| 21:31.02 | brlcad | but it took a solid 10 minutes of actually running the code, seeing the gui that pops up, poking on it to even have a glimmer of memory doing that |
| 21:33.07 | brlcad | (it was an inteface for shooting rays at geometry, plotting the hit points (similar to nirt), and providing the option to create actual geometry for the hit points (spheres) and path segments (cylinders/arb8s) .. which someone had requested at some point) |
| 21:35.38 | starseeker | hmm, nifty |
| 21:35.45 | brlcad | starseeker: liborle and the two tools that use it can be deprecated, but they've just not been a maintenance burden to even bother |
| 21:35.46 | starseeker | surprised it didn't get rolled into mged |
| 21:35.53 | brlcad | it wasn't completed |
| 21:35.58 | starseeker | ah |
| 21:36.15 | starseeker | brlcad: is code tidiness a sufficient motive to depricate? :-P |
| 21:36.19 | brlcad | the gui is actually pretty far along |
| 21:36.21 | starseeker | deprecate even |
| 21:37.50 | brlcad | *shrug*, if you want to both go for it, but there are *hundreds* of code tidiness issues like that such that it's been plenty enough as-is to just deprecate when they incur some cost (like a build failure that might take more than 10 seconds to fix) |
| 21:38.30 | brlcad | deprecating has a cost too .. those little 10 minute activities add up with context switching :) |
| 21:38.32 | starseeker | <snort> in this case, it's just rewriting the CMake logic for liborle everytime a paradigm change takes place - once that stops, I suppose i twon't matter |
| 21:38.46 | brlcad | that's a maintenance cost actually |
| 21:39.14 | brlcad | so if you deprecate now, they could go when autotools goes |
| 21:39.33 | brlcad | then you don't even have to worry, let autotools build and yank the cmake |
| 21:39.40 | starseeker | nods - let me check which tools those are... - src/util I presume? |
| 21:39.48 | brlcad | fb and util |
| 21:41.10 | brlcad | that goes MUCH farther back than my tcl discovery today, but i *think* it used to be a hand-rolled rle library that was replaced when urtoolkit's librle came out |
| 21:42.08 | CIA-63 | BRL-CAD: 03starseeker * r46879 10/brlcad/trunk/doc/deprecation.txt: list liborle and corresponding tools for deprecation |
| 21:42.15 | brlcad | new tools were written but the old ones were kept around for some reason that's been lost in time (probably out-perform) |
| 21:42.22 | starseeker | nods |
| 21:42.47 | starseeker | has yet to use *any* of the rle utils at all... guess I just haven't needed 'em yet |
| 21:42.53 | brlcad | should put the version too |
| 21:43.05 | starseeker | hmm? |
| 21:43.22 | starseeker | oh |
| 21:43.32 | starseeker | 7.20? |
| 21:43.35 | brlcad | nods |
| 21:44.05 | CIA-63 | BRL-CAD: 03starseeker * r46880 10/brlcad/trunk/doc/deprecation.txt: add version |
| 21:44.51 | brlcad | that's so deprecations can be cherry-picked into the obsolete section with just a copy-paste |
| 21:46.00 | CIA-63 | BRL-CAD: 03starseeker * r46881 10/brlcad/trunk/src/ (8 files in 8 dirs): Add a few more to the 'converted' list for include dirs - got a ways to go, pretty far reaching change. |
| 21:46.39 | brlcad | starseeker: since there are binaries going away, they get a statement too (see src/util/dbcp.c) |
| 21:47.04 | starseeker | each one gets a statement? |
| 21:47.27 | brlcad | so a message is printed when run |
| 21:47.34 | starseeker | oh, gotcha |
| 21:47.42 | starseeker | not in doc/deprecation, but in the C code itself |
| 21:47.43 | brlcad | doesn't have to be the same message as dbcp's, but should be something similar |
| 21:47.47 | brlcad | right |
| 21:48.11 | brlcad | doc/deprecation is meant to let devs know -- if a tool is going to disappear, we just put a statement in the tool |
| 21:48.58 | brlcad | (and in doc/deprecation, but users just aren't likely to or expected to look there .. they just use the tools they know) |
| 21:49.04 | brlcad | would be good to point them to the new tools |
| 21:49.09 | CIA-63 | BRL-CAD: 03starseeker * r46882 10/brlcad/trunk/src/fbserv/CMakeLists.txt: that was easy... convert fbserv to new includes |
| 21:49.16 | brlcad | "Use rle-fb instead!" |
| 21:51.10 | brlcad | been consistently using the marker DEPRECATED for both dev code comments and user printing statements |
| 21:51.17 | brlcad | so they're all easy to find |
| 21:51.36 | starseeker | do I need to support the D option? |
| 21:52.40 | starseeker | interesting - fb-orle's usage statement says fb-rle |
| 21:55.35 | CIA-63 | BRL-CAD: 03n_reed * r46883 10/brlcad/trunk/src/libgcv/wfobj/ (6 files): interface cleanup, including hiding local functions |
| 21:57.27 | CIA-63 | BRL-CAD: 03starseeker * r46884 10/brlcad/trunk/src/ (fb/fb-orle.c fb/orle-fb.c util/orle-pix.c util/pix-orle.c): Add deprecation warning messages to the fb and pix tools pertaining to orle. |
| 21:59.40 | *** join/#brlcad dli (~dli@dyn-157-046.wireless.concordia.ca) | |
| 22:14.48 | CIA-63 | BRL-CAD: 03starseeker * r46885 10/brlcad/trunk/src/ (5 files in 5 dirs): Convert a few more include dir lists. |
| 23:10.58 | *** join/#brlcad dli (~dli@dyn-157-046.wireless.concordia.ca) | |
| 23:16.57 | CIA-63 | BRL-CAD: 03abhi2011 * r46886 10/brlcad/trunk/src/libged/simulate/ (simphysics.cpp simulate.c simulate.h): Moved position transformation functions into simphysics.cpp and rearranged some code to fit in a call to rt |
| 23:42.56 | *** join/#brlcad dli (~dli@dyn-157-046.wireless.concordia.ca) | |