| 00:00.25 | CIA-62 | BRL-CAD: 03kunigami * r46170 10/osl/trunk/boost/tools/build/v2/ (53 files in 6 dirs): adding boost by parts |
| 00:01.22 | ``Erik | (a couple people (slow committers) have asked why we aren't on git, any valid argument?) |
| 00:02.40 | CIA-62 | BRL-CAD: 03starseeker * r46171 10/brlcad/trunk/src/librt/primitives/bot/ (bot.c g_bot_include.c): Whoops - shouldn't be resetting stp here. |
| 00:04.36 | CIA-62 | BRL-CAD: 03starseeker * r46172 10/brlcad/trunk/src/librt/primitives/ (ars/ars.c table.c): It's not strictly necessary for prep as long as we're using BoT internally for ars, but go ahead and add a bbox routine for ars. |
| 00:05.22 | starseeker | ``Erik: we aim to have everybody committing to a common branch to avoid "working in isolation" too much, as I understand it |
| 00:05.33 | starseeker | git makes it much easier to wander off in a corner and work in isolation |
| 00:06.10 | ``Erik | that was my thought, but I'd probably present it as "suck it up, stub it so it compiles and commit a lot, stop whining" |
| 00:06.52 | ``Erik | my two office mates are reluctant to commit until they feel things are "done", which throws away the continual peer review aspect |
| 00:07.39 | starseeker | nods - we've tried to discuss that with 'em before, but to no avail |
| 00:08.14 | starseeker | wonders if he should bother with a bbox routine for poly - I'm not even sure how I'd test it |
| 00:08.38 | CIA-62 | BRL-CAD: 03kunigami * r46173 10/osl/trunk/boost/tools/build/v2/ (283 files in 38 dirs): adding boost by parts |
| 00:10.22 | ``Erik | 'poly'? |
| 00:10.47 | ``Erik | open nmg, basically? |
| 00:11.38 | ``Erik | be easy to write such a func, set max to -infinity, min to infinity, then for each vertex, see if max{x,y,z} is bigger and min{x,y,z} is smaller, update them as you go |
| 00:16.20 | ``Erik | wanders off, hasta la pasta |
| 00:17.28 | CIA-62 | BRL-CAD: 03kunigami * r46174 10/osl/trunk/boost/tools/build/v2/test/ (365 files in 50 dirs): adding boost by parts |
| 00:22.13 | CIA-62 | BRL-CAD: 03kunigami * r46175 10/osl/trunk/boost/tools/build/v2/engine/ (99 files): adding boost by parts |
| 00:24.14 | abhi2011 | is anyone able to compile with strict warnings on : cmake ../brlcad -DBRLCAD_BUNDLED_LIBS=Bundled -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/home/abhi/brlcad |
| 00:24.16 | CIA-62 | BRL-CAD: 03kunigami * r46176 10/osl/trunk/boost/tools/build/v2/engine/ (14 files in 2 dirs): adding boost by parts |
| 00:24.57 | abhi2011 | i am still getting the function prototype errors I was getting yesterday from a fresh checkout : /home/abhi/socis/brlcad/src/libged/inside.c:935:2: error: call to function ârt_arb_get_cgtypeâ without a real prototype |
| 00:41.40 | CIA-62 | BRL-CAD: 03kunigami * r46177 10/osl/trunk/boost/tools/build/v2/engine/boehm_gc/ (92 files): adding boost by parts |
| 00:44.53 | CIA-62 | BRL-CAD: 03kunigami * r46178 10/osl/trunk/boost/tools/build/v2/engine/boehm_gc/ (59 files in 5 dirs): adding boost by parts |
| 00:46.36 | CIA-62 | BRL-CAD: 03kunigami * r46179 10/osl/trunk/boost/tools/build/v2/engine/boehm_gc/doc/ (37 files): adding boost by parts |
| 00:47.39 | CIA-62 | BRL-CAD: 03kunigami * r46180 10/osl/trunk/boost/ (Jamroot boost-build.jam boost.png bootstrap.sh): woot the last boost files |
| 00:50.52 | CIA-62 | BRL-CAD: 03kunigami * r46181 10/osl/trunk/compile.sh: added rule for boost and osl - it remains fixing the destination dir of oiio and osl and testing on another machine |
| 01:21.57 | starseeker | ``Erik: oh, I know it's easy to write but the primitive is an old one |
| 01:22.24 | starseeker | make and in don't support it, so creating one would require a bit of nonsense |
| 01:24.18 | starseeker | I can on gentoo - what gcc/os are you using? |
| 01:25.15 | CIA-62 | BRL-CAD: 03bhinesley * r46182 10/brlcad/trunk/src/libged/edit.c: (log message trimmed) |
| 01:25.15 | CIA-62 | BRL-CAD: Started logging tests of translate options/args. Ex. of a more complex set of |
| 01:25.15 | CIA-62 | BRL-CAD: args that is working: "translate -a -x comb/combA 3 -z combB/combC 0 0 11 -y |
| 01:25.15 | CIA-62 | BRL-CAD: combD/combE 0 7 combF/combG", which moves the instance of combG in combF from |
| 01:25.15 | CIA-62 | BRL-CAD: it's bounding box center to (x= apparent bb ctr of comb/combA offset 3 units), |
| 01:25.16 | CIA-62 | BRL-CAD: (y= apparent bb ctr of combF/combG offset 7 units), (z= apparent bb ctr of |
| 01:25.17 | CIA-62 | BRL-CAD: combB/combC offset 11 units). Disable use of batch operator as an argument to |
| 01:30.11 | brlcad | abhi2011: so fix it :) |
| 01:30.38 | brlcad | for whatever reason, nobody else is hitting that warning, making you the perfect person to fix it |
| 01:32.15 | brlcad | starseeker: poly was the precursor to BoT |
| 01:34.27 | CIA-62 | BRL-CAD: 03brlcad * r46183 10/brlcad/trunk/TODO: the hf and polysolid primitives are both supplanted by newer more complete primitives (half and BoT respectively), so mark them for removal in rel8 |
| 01:35.02 | abhi2011 | yep I turned of strict warnings :P |
| 01:35.35 | brlcad | abhi2011: that's no fix :P |
| 01:35.46 | brlcad | you do understand what that message means, yes? |
| 01:36.24 | abhi2011 | hehe yeah, will look into it, though its strange that I am getting it for almost every c function |
| 01:37.08 | brlcad | shouldn't have to look into it .. should be obvious -- if it's not, then you definitely should "fix" that warning |
| 01:37.29 | brlcad | prototype is empty |
| 01:37.44 | brlcad | it wants a real decl with the args listed |
| 01:37.58 | brlcad | decl is in include/raytrace.h |
| 01:38.56 | abhi2011 | yes and I am sure its included in the appropriate c file |
| 01:39.43 | brlcad | sure, but the prototype is *empty* |
| 01:39.53 | brlcad | that's what the compiler is warning you about |
| 01:40.10 | brlcad | make it be not empty |
| 01:40.33 | bhinesley | abhi2011: curious which gcc you're running |
| 01:40.48 | abhi2011 | yes, I can do that, I am just wondering if its code being modified by someone else |
| 01:41.19 | abhi2011 | brlcad: 4.5.1 20101208 |
| 01:41.53 | CIA-62 | BRL-CAD: 03brlcad * r46184 10/brlcad/trunk/TODO: need to include deprecation output on the old build system as well as when creating (or perhaps exporting) bspline/poly/hf primitives. |
| 01:42.30 | brlcad | abhi2011: no entiendo.. "code being modified by someone else"? |
| 01:43.23 | brlcad | no code is sacred, if code is found deficient, it gets fixed/improved/refactored |
| 01:43.37 | brlcad | revision control is our safety net |
| 01:44.48 | abhi2011 | brlcad: ok :) , though I was wondering whats the compiler version you are using |
| 01:45.11 | abhi2011 | because it seems more like a compiler flag issue |
| 01:45.15 | bhinesley | abhi2011: we're all over the place. I'm using 4.6 |
| 01:45.19 | abhi2011 | ok |
| 01:45.51 | CIA-62 | BRL-CAD: 03brlcad * r46185 10/brlcad/trunk/doc/deprecation.txt: |
| 01:45.51 | CIA-62 | BRL-CAD: they were never officially documented as such, so do so now. mark the bspline, |
| 01:45.51 | CIA-62 | BRL-CAD: poly, and hf primitives as deprecated. as removing them is a rather major |
| 01:45.51 | CIA-62 | BRL-CAD: backwards-incompatible change, they're better suited to rel8 than they are the |
| 01:45.51 | CIA-62 | BRL-CAD: usual 3-minor release timeframe. they should be documented somewhere |
| 01:45.52 | CIA-62 | BRL-CAD: regardless. |
| 01:46.34 | brlcad | abhi2011: we intentionally consider all warnings as errors for this exact reason, so that the issues get fixed |
| 01:48.41 | brlcad | the compiler usually issues warnings for pretty good reasons, so it's our project stance to halt regardless of version or environment (unless the issue is fundamentally unavoidable or a bug outside our control that cannot be compensated for easily) |
| 01:49.47 | starseeker | brlcad: do we have a tool to convert bspline/poly/hf primitives to their newer versions? |
| 01:49.59 | starseeker | wonders if cline can also get chopped... |
| 01:50.19 | brlcad | starseeker: nope |
| 01:50.22 | abhi2011 | brlcad: yes, I understand that, the errors came for a huge number of functions across multiple files, so I ll see if fixing one of them makes a difference |
| 01:50.40 | brlcad | starseeker: actually "yes" .. it just doesn't |
| 01:50.42 | brlcad | dbupgrade |
| 01:51.13 | starseeker | nods |
| 01:51.37 | starseeker | so that would be added for a 5->6 upgrade? |
| 01:51.51 | brlcad | I added code to run bspline through brep, worked well |
| 01:51.59 | brlcad | but the other two are relics |
| 01:52.45 | starseeker | nods - but I'm guessing we still don't get to ignore 'em in the upgrade path? |
| 01:52.59 | brlcad | shouldn't |
| 01:55.33 | starseeker | do we teach dbupgrade to convert 'em now when run on a v5 file? |
| 01:57.29 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 02:03.50 | CIA-62 | BRL-CAD: 03bhinesley * r46186 10/brlcad/trunk/src/libged/edit.c: Simplify iterating through arguments for execution of batch commands. |
| 02:11.42 | brlcad | starseeker: that would probably be okay |
| 02:12.52 | brlcad | presently does nothing with v5 files, of course |
| 02:35.52 | CIA-62 | BRL-CAD: 03brlcad * r46187 10/brlcad/trunk/src/librt/primitives/table.c: |
| 02:35.52 | CIA-62 | BRL-CAD: there's no need to intentionally make matters any harder for ourselves than they |
| 02:35.52 | CIA-62 | BRL-CAD: need to be, move the bbox routine to the end so we can reduce the risk of |
| 02:35.52 | CIA-62 | BRL-CAD: calling the wrong callback and crashing (or worse) if an older library somehow |
| 02:35.52 | CIA-62 | BRL-CAD: got linked. also didn't seem to be any particular grouping reason to have it |
| 02:35.52 | CIA-62 | BRL-CAD: between ifree/describe .. more closely related to prep and params, which the |
| 02:35.53 | CIA-62 | BRL-CAD: latter is conveniently at the end. |
| 02:36.35 | CIA-62 | BRL-CAD: 03brlcad * r46188 10/brlcad/trunk/include/raytrace.h: oops, this file goes with r46187. move bbox to the end. |
| 02:37.00 | brlcad | starseeker: you see tom's note? |
| 02:37.05 | brlcad | revenge of the red |
| 02:40.42 | CIA-62 | BRL-CAD: 03brlcad * r46189 10/brlcad/trunk/src/libged/red.c: remove the WARNING blather. all of the known red issues were fixed and are now integrated into our release regression testing with a rather extensive set of tests. |
| 03:04.47 | abhi2011 | ok I was looking into the error: call to function âblahblahâ without a real prototype , that I have been getting : it seems many(about 40+ functions, probably more) have been declared as follows Function(), and overhauling all of them would involve updating a huge number of files |
| 03:08.05 | abhi2011 | Not sure if it would be a good idea to do that |
| 03:08.21 | bhinesley | $5 says that it would be :) |
| 03:09.12 | abhi2011 | hehe :), well I ll get started then |
| 03:09.38 | bhinesley | i'm really curious as to why you're being alerted to these issues and not me (and others?). As brlcad pointed out, at least with the first warning, there is an actual problem that we can all observe; not the result of some configuration issue on your end. |
| 03:10.32 | bhinesley | slight differences in the compiler, I must assume |
| 03:10.42 | abhi2011 | well I am using a standard cmake configuration : cmake ../brlcad -DBRLCAD-ENABLE_STRICT=ON -DBRLCAD_BUNDLED_LIBS=Bundled -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/home/abhi/brlcad |
| 03:10.51 | abhi2011 | yes, the funny thing is, it wasnt there last week |
| 03:11.01 | abhi2011 | exactly same compiler |
| 03:11.25 | bhinesley | shrugs |
| 03:22.09 | brlcad | yeah, that's the odd part |
| 03:22.51 | brlcad | I pulled latest gcc svn (gcc 4.7) and don't get that warning, even though it's clearly a valid warning with the dumb k&r declarations being used |
| 03:24.19 | brlcad | abhi2011: so yeah, it would be a great idea to fix them since you're the one getting the reports .. but it's impossible that it's a "huge" number of files :) |
| 03:24.48 | brlcad | 40+ functions would, at worst, be 40+ files .. that's quick n' easy, maybe 20 min on a bad day :) |
| 03:25.18 | brlcad | more than likely, it's 90% in raytrace.h |
| 03:27.08 | CIA-62 | BRL-CAD: 03brlcad * r46190 10/brlcad/trunk/TODO: report that rtcheck doesn't work in previous release. probably the rt output bug, but warrants a quick test before the next release. |
| 03:31.21 | CIA-62 | BRL-CAD: 03bhinesley * r46191 10/brlcad/trunk/src/libged/edit.c: (log message trimmed) |
| 03:31.21 | CIA-62 | BRL-CAD: Argument type flags were being cleared by mistake. This led to an assert failure |
| 03:31.21 | CIA-62 | BRL-CAD: when trying to calculate vectors, as there was no argument flagged EDIT_FROM; |
| 03:31.22 | CIA-62 | BRL-CAD: which should at least defaulted to something. The batch operator is now working, |
| 03:31.22 | CIA-62 | BRL-CAD: at least in the simple cases that I tried. Also, a variable tracking the number |
| 03:31.22 | CIA-62 | BRL-CAD: of arguments in a linked list was only incremented by 1 for each batch operator, |
| 03:31.23 | CIA-62 | BRL-CAD: rather than adding the number of target objects to the total. I didn't observe |
| 03:31.44 | bhinesley | ^-- amazing the trouble a missing bit can cause |
| 03:41.04 | CIA-62 | BRL-CAD: 03bhinesley * r46192 10/brlcad/trunk/src/libged/edit.c: Error about not yet supporting use of the batch operator to specify individual coordinates was a bit overzealus. |
| 03:41.42 | bhinesley | yay, all kinds of neat stuff works now |
| 03:53.06 | brlcad | heh |
| 03:53.10 | brlcad | awesome! |
| 03:53.39 | brlcad | bhinesley: so you're soon to be on my radar to obtain deeper understanding of all the changes you've made of lagte |
| 03:53.55 | brlcad | the code is getting a bit complex for the task at hand |
| 03:54.52 | brlcad | but a bit premature to comment other than "that's a lot of code!" :) |
| 03:55.07 | brlcad | nice work on tackling such a complex task |
| 04:00.17 | bhinesley | great, I look forward to your comments/ideas |
| 04:04.47 | bhinesley | if I remove incomplete scale/rotate stuff, there are 1176 LOC according to cloc; and about as many lines in comments |
| 04:05.33 | brlcad | starseeker: nmg bbox looks good to me on the surface, save for one issue -- an empty nmg will likely crash, need to init vert_table |
| 04:06.41 | brlcad | bhinesley: like I said, that's a lot of code (for something as basically amounts to a xform call) :) |
| 04:07.06 | brlcad | the arg processing probably begs refactoring |
| 04:07.11 | bhinesley | the translate command is 158 LOC |
| 04:07.29 | brlcad | yeah, that's more what I'd expect |
| 04:07.50 | brlcad | so there's a ton of infrastructure around the meat of the matter |
| 04:07.57 | brlcad | not saying that's good or bad, it is what it is |
| 04:08.09 | bhinesley | same here |
| 04:08.43 | brlcad | it is, however, a pretty strong cue that something probably needs to be refactored |
| 04:09.37 | bhinesley | that's not suprising. I've learned a lot (about brlcad and coding), and there were a lot of suprises along the way. |
| 04:11.29 | bhinesley | I certainly didn't expect it to take me this long |
| 04:11.37 | bhinesley | but there it is |
| 04:17.21 | brlcad | yep |
| 04:18.14 | brlcad | hopefully you stick to it too, there's a lot of interesting projects you could cut your teeth on now that you've become a little familiar with the code |
| 04:18.33 | brlcad | some a lot more exciting that argument parsing ;) |
| 04:18.37 | bhinesley | hehe |
| 04:29.16 | CIA-62 | BRL-CAD: 03bhinesley * r46193 10/brlcad/trunk/src/libged/edit.c: These arguments to translate work, since r46191/92. |
| 05:37.50 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3079 10/wiki/User:Bhinesley: /* Log */ crossed out tasks, logged today |
| 06:38.09 | brlcad | publishes the logo contest finalists |
| 06:38.15 | brlcad | waddles off into the night |
| 07:34.57 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 11:18.46 | abhi2011 | brlcad: yes, I have begun modifying the k&r styles |
| 14:00.34 | CIA-62 | BRL-CAD: 03kunigami * r46194 10/osl/trunk/oiio/Makefile: modified the build script a bit so that oiio exports to a default destination install |
| 14:02.10 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 14:09.59 | CIA-62 | BRL-CAD: 03kunigami * r46195 10/osl/trunk/osl/ (Makefile src/CMakeLists.txt): added missing make from osl root and also turned off -werror |
| 14:11.35 | CIA-62 | BRL-CAD: 03kunigami * r46196 10/osl/trunk/compile.sh: now both osl and oiio should be build on default dirs |
| 14:17.25 | CIA-62 | BRL-CAD: 03kunigami * r46197 10/osl/trunk/boost/boostcpp.jam: missing file to build boost |
| 14:17.48 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 14:19.52 | CIA-62 | BRL-CAD: 03kunigami * r46198 10/osl/trunk/compile.sh: boost should be built before oiio/osl |
| 14:51.32 | CIA-62 | BRL-CAD: 03starseeker * r46199 10/brlcad/trunk/src/librt/primitives/nmg/nmg.c: initialize bu_ptbl for nmg vert list in bbox routine. |
| 14:55.00 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 15:05.07 | kunigami | is there any environment variable I can set so that cmake find_library will look there too? |
| 15:10.48 | ``Erik | mebbe LD_LIBRARY_PATH ? |
| 15:13.13 | kunigami | hmm I tried that, but didn't work. INut 'll check again |
| 15:19.04 | kunigami | nope. by the way, I'm trying to call FindPNG module, but it's not setting anything. I've build brlcad and so libpng was build on <brlcad dest>/lib/, which is the path that I added to LD_LIBRARY_PATH |
| 15:29.22 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 15:30.28 | kunigami | anyone having problems with ITK_LBRARY not being found? |
| 15:34.43 | brlcad | abhi2011: so version control 101 -- if you've been modifying them, then you should be committing already |
| 15:35.20 | brlcad | fix one, commit, fix another, commit -- at least per file |
| 15:35.52 | brlcad | waiting to commit them all as one mega change is much harder to review |
| 15:39.48 | starseeker | kunigami: you're using a system itk? |
| 15:40.36 | starseeker | kunigami: I believe the environment variable is CMAKE_LIBRARY_PATH |
| 15:58.13 | CIA-62 | BRL-CAD: 03r_weiss * r46200 10/brlcad/trunk/src/ (4 files in 4 dirs): Updated files 'get_solid_kp.c', 'rec.c', 'tgc.c' and 'nmg.c' to remove the compiler error/warning message 'ISO C90 forbids mixed declarations and code'. |
| 16:00.02 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 16:02.48 | kunigami | starseeker: I'm using -DBRLCAD-ENABLE_ALL_LOCAL_LIBS=ON, so I believe it's using from the source |
| 16:06.59 | starseeker | kunigami: that option has changed - try -DBRLCAD_BUNDLED_LIBS=Bundled |
| 16:07.05 | kunigami | starseeker: thanks, that name led me to the CMAKE_PREFIX_PATH |
| 16:07.19 | kunigami | starseeker: oh, |
| 16:10.43 | kunigami | hmm, no, the error remains |
| 16:10.56 | CIA-62 | BRL-CAD: 03abhi2011 * r46201 10/brlcad/trunk/src/librt/bbox.c: Updated librt function for finding bb from rt_db_internal |
| 16:20.29 | CIA-62 | BRL-CAD: 03abhi2011 * r46202 10/brlcad/trunk/include/raytrace.h: Updated declaration for the bb function as well |
| 16:28.52 | CIA-62 | BRL-CAD: 03abhi2011 * r46203 10/brlcad/trunk/src/fb/fb-orle.c: Filled in empty K&R style prototypes with the parameter datatypes |
| 16:29.41 | CIA-62 | BRL-CAD: 03abhi2011 * r46204 10/brlcad/trunk/include/orle.h: Filled in empty K&R style prototypes with the parameter datatypes |
| 16:31.37 | kunigami | damn |
| 16:32.17 | abhi2011 | there appears to be 2 structures in use in libfb with exactly the same definition : struct ColorMap and struct RLEColorMap |
| 16:33.19 | abhi2011 | kunigami: I was getting the itk error 2 days ago, but a clean checkout and the bundled options helped compile it successfully |
| 16:33.55 | kunigami | I had mistyped the command to DBRLCAD-BUNDLED_LIBS=Bundled sorry :( |
| 16:34.09 | abhi2011 | :) |
| 16:36.13 | abhi2011 | and strangely some of the functions in libfb are defined with struct RLEColorMap * but are passed struct ColorMap * , leading to a lot of warnings |
| 16:37.10 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 16:40.07 | starseeker | abhi2011, kunigami: if you guys can use cmake-gui, it will show you the most common "user" options |
| 16:50.53 | CIA-62 | BRL-CAD: 03starseeker * r46205 10/brlcad/trunk/src/librt/primitives/ (poly/poly.c table.c): add a bbox routine for poly - pretty minimal shifting of the logic, as this is on its way out anyway. |
| 16:54.11 | kunigami | starseeker: do you know if it is available for mac? |
| 16:55.55 | brlcad | abhi2011: why did you add fb.h to orle.h ? |
| 16:56.14 | brlcad | orle shouldn't need fb.h iirc |
| 16:57.08 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 16:58.39 | CIA-62 | BRL-CAD: 03brlcad * r46206 10/brlcad/trunk/src/fb/ (cmap-crunch.c fb-cmap.c fb-orle.c fbpoint.c): remove authors, revision control tracks actual authorship |
| 17:00.31 | bhinesley | kunigami: not sure about your question, but fyi the curses version, ccmake, will achieved the same end |
| 17:03.49 | kunigami | bhinesley: I'll take a look on that. thanks! |
| 17:07.23 | abhi2011 | brlcad: that was to allow the declaration of struct ColorMap to be available, I had modified the declaration of rle_wmap() to be rle_wmap(FILE *, ColorMap *); as a ColorMap* was being passed to it in fb-orle.c |
| 17:07.46 | abhi2011 | But i later changed it to rle_wmap(FILE *, RLEColorMap *); |
| 17:08.06 | abhi2011 | when I checked the definition of rle_wmap() |
| 17:08.32 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 17:09.00 | CIA-62 | BRL-CAD: 03brlcad * r46207 10/brlcad/trunk/src/fb/fb-orle.c: the structures are just coincidentally the same, so we need to copy the color map values before passing to rle_wmap. if fbio's structure ever changed, the hard cast would have been a potentially nasty bug to diagnose. |
| 17:09.22 | abhi2011 | So my question is I do get a lot of warnings (which of course are treated as errors), wherever a struct RLEColorMap * should be passed instead of struct ColorMap* |
| 17:09.26 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 17:10.45 | abhi2011 | brlcad: ok so I can copy the struct ColorMap values to a struct RLEColorMap instead and pass a struct RLEColorMap* as expected |
| 17:13.09 | CIA-62 | BRL-CAD: 03brlcad * r46208 10/brlcad/trunk/src/fb/ (cmap-crunch.c fb-cmap.c fb-orle.c fb-rle.c): ws indent style cleanup |
| 17:13.31 | brlcad | abhi2011: yeah, that's probably better |
| 17:13.37 | abhi2011 | ok |
| 17:13.52 | brlcad | I'm actually not 100% positive that they're actually compatible too, but that's how the code is presently written |
| 17:14.02 | brlcad | the new rle color maps have a different ordering iirc |
| 17:14.59 | CIA-62 | BRL-CAD: 03brlcad * r46209 10/brlcad/trunk/include/orle.h: shouldn't need fb.h here |
| 17:16.24 | brlcad | abhi2011: coincidentally, that's why the compiler warnings are a good thing -- we wouldn't have known that a struct was being implicitly converted until the arg list was added to the function prototype |
| 17:17.31 | CIA-62 | BRL-CAD: 03kunigami * r46210 10/osl/trunk/jpeg-8c/ (180 files): oiio also depends on jpge |
| 17:17.45 | starseeker | kunigami: cmake? sure |
| 17:17.46 | abhi2011 | brlcad: ok I ll explicitly specify the struct members while copying instead of a plain A = B |
| 17:19.19 | starseeker | kunigami: http://www.cmake.org/files/v2.8/cmake-2.8.5-Darwin-universal.dmg |
| 17:23.41 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 17:29.04 | brlcad | kunigami: heh, the list just keeps growing :) |
| 17:29.29 | kunigami | brlcad: libtiff is coming too! |
| 17:29.33 | brlcad | :) |
| 17:30.38 | brlcad | kunigami: it's a good thing OSL is actually worth it ... can't wait to see a full detail rendering run over a weekend |
| 17:31.06 | kunigami | brlcad: :) |
| 17:31.08 | starseeker | isn't sure if brlcad is making an assertion or a challenge :-P |
| 17:31.18 | kunigami | hehe |
| 17:32.46 | CIA-62 | BRL-CAD: 03starseeker * r46211 10/brlcad/trunk/src/librt/primitives/ (bspline/bspline.cpp table.c): Take a stab at a bbox routine for brep. Like poly, not going to put much effort into this one - in this can't won't even hook it into prep. |
| 17:33.10 | starseeker | hmm s/can't/case |
| 17:33.42 | brlcad | and s/brep/bspline/ |
| 17:34.03 | starseeker | er, yeah |
| 17:34.37 | brlcad | is excited, actually getting 3D geometry for the logo |
| 17:34.49 | brlcad | though that will be fun to model in BRL-CAD |
| 17:37.34 | kunigami | by far, the thing that is taking more time is to add entries on subversion/config of files without extension :( |
| 17:37.57 | starseeker | kunigami: yep, always a problem when adding an external repo |
| 17:38.48 | brlcad | kunigami: write a script? |
| 17:39.00 | brlcad | they're all header files, no? |
| 17:39.06 | starseeker | notes that the moose is out, abstract art is in ;-) |
| 17:39.38 | kunigami | brlcad: I wrote a script to tell which files are not covered by config before adding them https://gist.github.com/1150253 |
| 17:39.42 | brlcad | the moose isn't necessarily out, but the other won had considerably more votes |
| 17:39.51 | brlcad | s/won/one/ jessh |
| 17:40.19 | kunigami | maybe I can assume a default (svn:eol-style=native;svn:mime-type=text/plain) in those cases |
| 17:41.08 | brlcad | maybe I'm missing something, but you should be able to add most all of boost with a 'find' command one-liner |
| 17:42.28 | brlcad | starseeker: I think what'll amount to is a mix -- the moose is still the mascot, just the logo doesn't necessarily refer to it |
| 17:42.38 | starseeker | nods |
| 17:42.41 | brlcad | like how redhat's is a hat, even though the mascot is a penguin |
| 17:43.00 | brlcad | or ubuntu with the three holding hands |
| 17:43.51 | bhinesley | what could cause the compiler to warn about variables as being "set but not used", when they are in fact set and used (in rec.c vars:magsq_c/magsq_d)? |
| 17:44.11 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 17:44.52 | bhinesley | oh gosh, n/m I was in the wrong function with the same vars |
| 17:45.12 | starseeker | bhinesley: that's a consequence of the bbox function logic moving |
| 17:45.13 | brlcad | kunigami: cp boost /path/to/svn/boost ; cd /path/to/svn ; find boost -type d -exec svn add {} \; -type f -exec svn add {} \; -exec svn ps svn:eol-style native {} \; -exec svn ps svn:mime-type text/plain {} \; |
| 17:45.23 | brlcad | something like that at least, should do the trick |
| 17:45.26 | starseeker | magsq_c and magsq_d are apparently not used in prep now |
| 17:45.33 | kunigami | brlcad: now I'm not sure we're talking about the same things. Here are the files of libtiff that svn won't know how to set mime-type/eol-style: http://paste.ubuntu.com/668472/ |
| 17:46.31 | brlcad | yeah, so I'd just take that list as-is, set them as text/plain and move on :) |
| 17:47.17 | brlcad | cat log | awk '{print $4}' | xargs svn ps svn:eol-style native |
| 17:47.18 | brlcad | <PROTECTED> |
| 17:47.21 | CIA-62 | BRL-CAD: 03starseeker * r46212 10/brlcad/trunk/src/librt/primitives/rec/rec.c: compilers should be happy. |
| 17:48.06 | kunigami | hmmm I didn't know that it was a command to set it. I was editing the config file manually >.< |
| 17:49.24 | bhinesley | starseeker: yeah sorry, I would have removed them but went to the wrong function and it looked fine :-| |
| 17:49.37 | starseeker | np - my fault, it was my change |
| 17:49.51 | bhinesley | ah |
| 17:50.17 | starseeker | is extracting bounding box logic from prep routines - occasionally messy |
| 17:52.36 | brlcad | kunigami: oh dear!... |
| 17:53.18 | brlcad | kunigami: http://brlcad.org/wiki/Mime-types |
| 17:53.38 | brlcad | specifically, the part near the end |
| 17:54.06 | kunigami | I should have read past the 5th line too :( |
| 18:03.22 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 18:07.17 | CIA-62 | BRL-CAD: 03starseeker * r46213 10/brlcad/trunk/src/librt/primitives/ (ebm/ebm.c table.c): ebm bbox routine. |
| 18:14.46 | CIA-62 | BRL-CAD: 03starseeker * r46214 10/brlcad/trunk/src/librt/primitives/ (table.c vol/vol.c): vol is basically a variation on ebm as far as bbox goes. |
| 18:16.37 | CIA-62 | BRL-CAD: 03bhinesley * r46215 10/brlcad/trunk/src/libged/edit.c: |
| 18:16.37 | CIA-62 | BRL-CAD: Testing "translate -k -x 3 -a -y 5 shp" revealed that the default "to" points |
| 18:16.37 | CIA-62 | BRL-CAD: (ex: x/z of -a) were being set to shp's bb-ctr, rather than the kp specified |
| 18:16.37 | CIA-62 | BRL-CAD: with -k (which in turn defaults points to the bb-ctr of shp). That cmd should |
| 18:16.37 | CIA-62 | BRL-CAD: move the bb-ctr of shp to y=5 and not change its x/z pos (the -k part is |
| 18:16.38 | CIA-62 | BRL-CAD: superflous). It was moving the y-axis, but was also moving on the x-axis an |
| 18:16.39 | CIA-62 | BRL-CAD: amount equal to the difference between the bb ctr of shp and x=3. |
| 18:17.03 | brlcad | starseeker: the good news is that all counts towards GS/GE work |
| 18:17.34 | *** join/#brlcad nsd_ (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 18:21.38 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 18:32.03 | starseeker | brlcad: question - looking at bn_tol in bn.h, the comments say double perp; /**< @brief nearly 0 */ but BN_VECT_ARE_PARALLEL is doing NEAR_EQUAL comparisions between _tol->perp and -1.0/1.0. Won't those always be false? |
| 18:44.58 | CIA-62 | BRL-CAD: 03kunigami * r46216 10/osl/trunk/tiff-3.9.5/ (447 files in 26 dirs): oiio also depends on tiff |
| 18:51.02 | brlcad | starseeker: I believe the comment is misleading |
| 18:52.32 | bhinesley | starts cracking on docbook |
| 18:53.08 | brlcad | starseeker: oh, my bad -- it's right |
| 18:53.19 | CIA-62 | BRL-CAD: 03kunigami * r46217 10/osl/trunk/compile.sh: added rules for jpeg and tiff |
| 18:54.07 | brlcad | perp is close to zero, the comparison isn't between tol->perp and -1.0/1.0 .. it's between the dot product value and -1/1 .. within a tol->perp near-zero tolerance |
| 18:55.19 | brlcad | since the dot product is already range clamped, the tight distance tolerance becomes too tight.. you want a different tolerance close to zero but bigger than SMALL_FASTF, probably even bigger than 0.0005 |
| 18:56.18 | brlcad | interestingly enough, looks like it's 1e-6 in most places I can find |
| 18:56.53 | starseeker | there's an RT_DOT_TOL in the header, but I'm not sure it's used |
| 18:57.09 | brlcad | hm, 0 in some places 0.001 (which feels right) in others, and 1e-6 in most places (feels too tight) |
| 18:57.51 | brlcad | heh, nice relevant comment in libbn/plane.c |
| 18:57.57 | brlcad | <PROTECTED> |
| 18:57.58 | CIA-62 | BRL-CAD: 03starseeker * r46218 10/brlcad/trunk/src/librt/primitives/ (arbn/arbn.c table.c): |
| 18:57.59 | CIA-62 | BRL-CAD: Make a stab at arbn bbox. This is another one where prep won't call the bbox |
| 18:57.59 | CIA-62 | BRL-CAD: routine directly, since it needs the same work for other stuff. Tried to pix |
| 18:57.59 | CIA-62 | BRL-CAD: sensible defaults for tolerances, since we don't pass a tolerance into this |
| 18:57.59 | CIA-62 | BRL-CAD: function. |
| 18:58.47 | brlcad | looks like RT_DOT_TOL isn't used |
| 18:59.01 | starseeker | growl. It should be |
| 18:59.20 | brlcad | used during typein |
| 18:59.27 | brlcad | for hyp and ehy |
| 18:59.40 | starseeker | needs something in the arbn bbox routine |
| 18:59.53 | starseeker | sure don't want to hardcode a number |
| 19:00.20 | brlcad | looks like cline, ehy, epa, hyp, nmg, red, revolve, rhc, rpc, and tgc use RT_DOT_TOL internally |
| 19:00.44 | brlcad | so it is used.. just probably not in all the places it should |
| 19:00.52 | starseeker | nods |
| 19:03.33 | starseeker | yipe - pipe bbox is going to be a bit of fun |
| 19:07.06 | bhinesley | s/yipe/yipee |
| 19:07.41 | brlcad | starseeker: just call bbox on all the individual tgc and sph elements |
| 19:07.49 | brlcad | er, tor |
| 19:08.22 | starseeker | brlcad: actually, as I'm digging in it looks like there's already some more or less split out functionality for this |
| 19:08.33 | brlcad | hm, okay |
| 19:08.51 | starseeker | rt_bend_pipe_prep deals pretty much entirely with per-bend bbox issues,fromt he looks of it - just a head insertion at the end |
| 19:09.31 | starseeker | oh, wait - hmm |
| 19:09.38 | starseeker | scratch that, it is mixed abit |
| 19:10.29 | starseeker | that bp struct is not a throwaway |
| 19:11.08 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 19:11.34 | starseeker | and we do need this logic, otherwise it becomes possible (I think) to create pipes with really really bad bboxes |
| 19:16.40 | CIA-62 | BRL-CAD: 03r_weiss * r46219 10/brlcad/trunk/src/libbn/plane.c: (log message trimmed) |
| 19:16.41 | CIA-62 | BRL-CAD: Within file 'plane.c' updated functions 'bn_coplanar', 'bn_isect_2planes' and |
| 19:16.41 | CIA-62 | BRL-CAD: 'bn_isect_lseg3_lseg3_new'. Corrected a bug in 'bn_coplanar' when computing the |
| 19:16.41 | CIA-62 | BRL-CAD: distance between planes. Within function 'bn_isect_2planes' changed some |
| 19:16.41 | CIA-62 | BRL-CAD: floating point compares from zero to SMALL_FASTF and improved the comments. |
| 19:16.41 | CIA-62 | BRL-CAD: Within 'bn_isect_lseg3_lseg3_new' fixed a bug when line segments are colinear |
| 19:16.42 | CIA-62 | BRL-CAD: and the intersection in on the end point(s), the clamping of the exact end point |
| 19:40.18 | brlcad | now that's some good stuff |
| 19:40.49 | brlcad | r_weiss should get to more nitty gritty libbn review like that instead of futzing with nmg! |
| 19:41.08 | brlcad | someone should go pat him on the back, that's more like it :) |
| 19:42.23 | brlcad | except for the whole bn_isect_lseg3_lseg3_new() |
| 19:44.11 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 19:50.40 | CIA-62 | BRL-CAD: 03r_weiss * r46220 10/brlcad/trunk/src/librt/primitives/nmg/nmg_misc.c: Updated function 'nmg_ck_vert_on_fus' within file 'nmg_misc.c'. Simplified logic, did some code cleanup. Removed an unnecessary floating point compare to zero. |
| 20:09.18 | CIA-62 | BRL-CAD: 03kunigami * r46221 10/osl/trunk/compile.sh: oiio will add /dist, no need to do that with $prefix |
| 20:17.03 | CIA-62 | BRL-CAD: 03starseeker * r46222 10/brlcad/trunk/src/librt/primitives/nmg/nmg.c: Richard pointed out a pre-existing nmg bounding box function - use that. |
| 20:22.42 | bhinesley | considers investigating how much work it would be to get linkends between manual pages working |
| 20:24.34 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 20:28.34 | CIA-62 | BRL-CAD: 03bhinesley * r46223 10/brlcad/trunk/doc/docbook/system/mann/en/ (CMakeLists.txt Makefile.am translate.xml): Add placeholders for edit/translate commands |
| 20:29.07 | bhinesley | oops |
| 20:33.17 | CIA-62 | BRL-CAD: 03bhinesley * r46224 10/brlcad/trunk/doc/docbook/system/mann/en/ (edit.xml translate.xml): Overwrote translate.xml last commit... reverting and adding edit |
| 20:55.35 | CIA-62 | BRL-CAD: 03bhinesley * r46225 10/brlcad/trunk/doc/docbook/system/mann/en/ (CMakeLists.txt Makefile.am edit-translate.xml): |
| 20:55.35 | CIA-62 | BRL-CAD: Unless mged's translate command is deprecated, we'll need two sets of |
| 20:55.35 | CIA-62 | BRL-CAD: "translate" manuals. Name the new page "edit translate", where the command will |
| 20:55.35 | CIA-62 | BRL-CAD: display the page. Don't mention the Archer alias "translate", since the same man |
| 20:55.35 | CIA-62 | BRL-CAD: page will be seen in mged. |
| 20:56.16 | CIA-62 | BRL-CAD: 03r_weiss * r46226 10/brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c: |
| 20:56.16 | CIA-62 | BRL-CAD: Added a new function 'nmg_isect_2faceuse' to file 'nmg_inter.c' which finds the |
| 20:56.16 | CIA-62 | BRL-CAD: intersection line between two faceuse. This new function is based on function |
| 20:56.16 | CIA-62 | BRL-CAD: bn_isect_2planes but can better determine coplanar and parallel faceuse because |
| 20:56.18 | CIA-62 | BRL-CAD: vertex distances to the faceuse planes are used instead of the angle between the |
| 20:56.18 | CIA-62 | BRL-CAD: planes and the distance between the planes at their point closest to the origin. |
| 21:19.29 | CIA-62 | BRL-CAD: 03n_reed * r46227 10/brlcad/trunk/src/conv/obj-g_new.c: minor style and ws changes |
| 21:25.17 | CIA-62 | BRL-CAD: 03n_reed * r46228 10/brlcad/trunk/src/libgcv/wfobj/obj_parser.cpp: minor readability changes |
| 21:38.22 | CIA-62 | BRL-CAD: 03n_reed * r46229 10/brlcad/trunk/src/libgcv/wfobj/ (obj_grammar.h.in obj_grammar.yy obj_grammar.yy obj_rules.ll): Replaced Bison parser input with Lemon parser input. Parser gives identical output for a lot of input obj files, but there are still some discrepancies that need to get worked out. |
| 21:39.26 | brlcad | woot! |
| 21:45.17 | CIA-62 | BRL-CAD: 03starseeker * r46230 10/brlcad/trunk/src/librt/primitives/ (rpc/rpc.c table.c): Add rpc bbox routine - while we're at it, make a tighter bbox instead of bounding the bounding sphere. |
| 21:46.14 | starseeker | go n_reed! |
| 21:48.55 | CIA-62 | BRL-CAD: 03bhinesley * r46231 10/brlcad/trunk/src/libged/edit.c: |
| 21:48.55 | CIA-62 | BRL-CAD: I've been using the "translate" alias to test, so I didn't notice that the |
| 21:48.55 | CIA-62 | BRL-CAD: calling the edit command directly was recently broken. It was trying to call |
| 21:48.55 | CIA-62 | BRL-CAD: subcommand functions of the edit help command, which don't exist. Fixed other |
| 21:48.55 | CIA-62 | BRL-CAD: small problems with the help system. I replaced some 1-off goto's with the code |
| 21:48.56 | CIA-62 | BRL-CAD: they were redirecting to, to please the Lords of Kobol. |
| 21:50.00 | CIA-62 | BRL-CAD: 03r_weiss * r46232 10/brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c: |
| 21:50.00 | CIA-62 | BRL-CAD: Within file 'nmg_inter.c' updated function 'nmg_isect_two_generic_faces' and |
| 21:50.00 | CIA-62 | BRL-CAD: disabled functions 'nmg_isect_nearly_coplanar_faces' and |
| 21:50.00 | CIA-62 | BRL-CAD: 'nmg_isect_coplanar_edges' to quiet compiler errors/warnings because they are no |
| 21:50.00 | CIA-62 | BRL-CAD: longer used. Simplified the function 'nmg_isect_two_generic_faces' which was |
| 21:50.00 | CIA-62 | BRL-CAD: possible by using the new function 'nmg_isect_2faceuse'. |
| 21:55.14 | CIA-62 | BRL-CAD: 03r_weiss * r46233 10/brlcad/trunk/include/raytrace.h: Updated include file 'raytrace.h' to add the new function 'nmg_isect_2faceuse'. |
| 21:56.47 | CIA-62 | BRL-CAD: 03starseeker * r46234 10/brlcad/trunk/src/librt/primitives/rpc/rpc.c: comment doesn't apply anymore |
| 22:02.14 | CIA-62 | BRL-CAD: 03r_weiss * r46235 10/brlcad/trunk/src/librt/bbox.c: Updated file 'bbox.c' to stop compiler errors. |
| 22:14.48 | starseeker | wonders if smaller rpc bounding boxes are technically user visible... |
| 22:14.56 | starseeker | may have minor raytrace consequences |
| 22:49.42 | CIA-62 | BRL-CAD: 03r_weiss * r46236 10/brlcad/trunk/src/librt/primitives/nmg/nmg_fuse.c: Updated function 'nmg_ck_fu_verts' in file 'nmg_fuse.c'. Fixed a bug which caused a seg fault if a loopuse contained a single vertex instead of an edgeuse. Also did some code cleanup. |
| 22:51.38 | CIA-62 | BRL-CAD: 03kunigami * r46237 10/osl/trunk/boost/boost/math/policies/error_handling.hpp: workaround to resolve the problem with -fno-rtti and typeid. I've commented out... it wont change the logic of the program since typeid was only used to compose a print message |
| 22:52.31 | CIA-62 | BRL-CAD: 03kunigami * r46238 10/osl/trunk/compile.sh: osl was being wrongly build in /dest/dest/ |