| 00:12.12 | starseeker | brlcad: another one - http://pastebin.mozilla.org/1655632 |
| 00:12.21 | brlcad | _fkr: great way to get involved if you're interested is any of these http://brlcad.org/wiki/Quickies |
| 00:13.11 | brlcad | _fkr: it was more just to inquire where your interests lie -- discussion is usually good and all that, but we can often have nearly the exact same discussion while being productive towards some goal |
| 00:13.54 | brlcad | for example, if you're interested in the philosophical aspects that you've been discussing, as they pertain to BRL-CAD development, there are actually materials you could review and provide feedback on |
| 00:14.18 | brlcad | cristina: commit please :) |
| 00:14.27 | brlcad | commit is usually the right answer unless you know it's going to break something |
| 00:14.35 | starseeker | also http://pastebin.mozilla.org/1655636 |
| 00:15.37 | brlcad | starseeker: yeah, those fall into the same boat |
| 00:15.45 | brlcad | just not as critical as the spatial partitioning |
| 00:15.58 | brlcad | but important to those applications |
| 00:16.21 | brlcad | the first is saying "wtf is wrong with you?" |
| 00:16.36 | brlcad | the second is saying "this is a huge ass function, you sure you want to inline it??" |
| 00:16.57 | brlcad | or "this will make for one huge ass function, you sure??" |
| 00:17.17 | starseeker | doesn't actually know how to debug these... |
| 00:17.26 | brlcad | it's not a debug issue |
| 00:17.55 | brlcad | if the compiler told you "this function is really big and that's usually a sign of bad design" what would you do? |
| 00:18.30 | starseeker | go bug the guy who wrote it? ;-) |
| 00:18.47 | CIA-55 | BRL-CAD: 03cprecup * r50865 10/brlcad/trunk/src/conv/CMakeLists.txt: added check for libavoid's existence as a system-installed library |
| 00:18.48 | brlcad | heh, you look at the function, see if it logically breaks up or needs to be or is best being that big |
| 00:19.10 | brlcad | now say that guy is you |
| 00:19.59 | brlcad | because open source is collective ownership, you effectively are just as responsible for it as everyone else :) |
| 00:21.27 | starseeker | I take it std::istringstream buffer(string) is responsible for the size complaint? |
| 00:22.31 | CIA-55 | BRL-CAD: 03brlcad * r50866 10/brlcad/trunk/src/librt/ (48 files in 19 dirs): ws cleanup, mostly trailing space junk from suboptimally configured editors. :) |
| 00:25.26 | brlcad | the first or second? |
| 00:26.42 | starseeker | the istringstream |
| 00:26.49 | starseeker | RegionList.h |
| 00:27.05 | starseeker | oh - second |
| 00:28.09 | brlcad | so it's saying toValue cannot be inlined in a variety of places |
| 00:29.03 | brlcad | the reason it's saying it cannot inline it is because it makes the function that calls it way too big (usually more than 100% bigger iirc) |
| 00:29.32 | brlcad | so the first is to check out toValue() |
| 00:29.48 | brlcad | confirm that it's in a header and marked inline so that's why it's trying to forcibly inline |
| 00:29.57 | starseeker | it's a C++ conversion of a string to a fastf_t |
| 00:30.08 | starseeker | marked inline |
| 00:30.24 | brlcad | seems simple enough, istringstream template instantiation could very well have something to do with it's ultimate size, but it logically seems simple and reasonable to me |
| 00:30.41 | brlcad | so the next point is to look at the caller code |
| 00:30.49 | brlcad | the first one is raw-g.cpp:113 |
| 00:30.56 | brlcad | looking at that, I already see a little red flag |
| 00:32.13 | starseeker | um... why is a C++ string converted to a C string in order to be fed to a C++ routine? Isn't there a simpler way? |
| 00:32.16 | brlcad | it's being invoked as a function parameter instead of just being called, which is outright "wrong" given I said I expect it to be inline |
| 00:32.28 | brlcad | I'd set it to a variable, pass the variable to that function |
| 00:34.02 | brlcad | conversions from C++ strings to C strings are practically free, even the reverse is "free-enough" for most cases |
| 00:34.53 | brlcad | so having set that function result to a variable in that if/else block with {} scope, rerun and see if the warning about raw-g.cpp:113 goes away |
| 00:35.03 | brlcad | if it does, that very well could be the rest of them |
| 00:36.02 | brlcad | however, given the next six or so are that same function, it's *probably* more an issue of that specific function getting too big |
| 00:36.36 | brlcad | in which case it's a judgement call to break it up into multiple functions (usually best) or increase the default growth limit for inlining |
| 00:37.05 | brlcad | pardon, next 9 instances are all in that while loop |
| 00:37.43 | brlcad | that'd make a good function actually, either the while loop or the guts to it |
| 00:38.04 | starseeker | hum. I'm trying to set the output of toValue to a fastf_t variable and use it, but I'm getting an unused var error |
| 00:38.18 | brlcad | you did pass it to the function, right? :) |
| 00:38.29 | starseeker | fastf_t val = toValue(thickf.c_str()); |
| 00:38.36 | starseeker | bot.setThickness(val); |
| 00:38.58 | brlcad | and you added braces |
| 00:39.25 | starseeker | hmm? |
| 00:39.51 | brlcad | braces |
| 00:39.58 | brlcad | {} |
| 00:39.59 | brlcad | you needed to add them |
| 00:40.38 | starseeker | ah, right |
| 00:40.41 | brlcad | mumbles something about crappy coding tools |
| 00:41.36 | starseeker | shakes his head - didn't clear the error |
| 00:41.54 | brlcad | paste |
| 00:42.14 | brlcad | didn't clear the inline warning or the unused var error? |
| 00:42.20 | starseeker | inline |
| 00:42.39 | brlcad | oh, that was expected (but still worth doing) |
| 00:42.56 | starseeker | huh? |
| 00:43.09 | starseeker | thought we were trying to clear the inline error |
| 00:43.27 | brlcad | likes I said above.. "given the next [nine] or so are that same function, it's *probably* more an issue of that specific function getting too big" |
| 00:43.53 | starseeker | so... with something basic like that in C++, how do we make it small? |
| 00:43.54 | brlcad | see the while loop below? |
| 00:44.07 | starseeker | oh, right |
| 00:45.24 | CIA-55 | BRL-CAD: 03starseeker * r50867 10/brlcad/trunk/src/conv/raw/raw-g.cpp: Assign toValue to a variable |
| 00:45.32 | brlcad | that already 'relatively big' main function is calling toValue() 10 times, so gcc is rightly warning about us trying to force inline |
| 00:45.58 | brlcad | breaking the guts of that while loop into a static function should do the trick |
| 00:46.10 | brlcad | or the whole while loop |
| 00:46.23 | starseeker | oh - so the size issue is coming from the "main" loop pulling in 10 copies of that particular function? |
| 00:46.34 | brlcad | right |
| 00:46.49 | brlcad | that's what "large-function-growth limit reached" means |
| 00:46.52 | starseeker | ah - I didn't realize that. I thought it ment toValue itself was too big to be inlined |
| 00:47.18 | brlcad | "it's already considered a big function and you're jacking it up a lot bigger with all this inlining.. you sure you wanna do that?" |
| 00:48.27 | brlcad | the contents of toValue are increasing the size of the calling function (main()) too mcuh |
| 00:48.42 | starseeker | nods |
| 00:48.45 | starseeker | I understand now |
| 00:49.00 | starseeker | cusses C++ error messages under his breath... |
| 00:50.44 | brlcad | more of a gcc issue |
| 00:51.02 | brlcad | that's actually not a c++ error message -- it applies equally to C |
| 00:55.00 | starseeker | growl |
| 00:56.14 | starseeker | brlcad: was this the refactor you had in mind? http://bzflag.bz/~starseeker/raw-g.cpp |
| 00:59.19 | starseeker | that's not avoiding the issue, unfortunately, so I must have done something wrong |
| 01:02.28 | CIA-55 | BRL-CAD: 03brlcad * r50868 10/brlcad/trunk/src/conv/intaval/ (regtab.cpp regtab.h): combine constructors with default parameters and make the latter be non-inline. gcc was unwilling to inline it anyways given the WMEMBER_INIT() expansions are relatively lengthy. |
| 01:03.19 | brlcad | starseeker: not quite, you wouldn't want to pass around the whole container like that |
| 01:03.40 | brlcad | I'd start minimal with just the guts |
| 01:04.29 | brlcad | it very well may not like a single one of them expanding in which case it could be an issue with the side of toValue(), but doing just the guts should indicate that |
| 01:05.10 | starseeker | why are we inlining toValue again? Are there actual performance gains here? |
| 01:06.05 | starseeker | by "guts" are you referring to one set of xyz point assignments? |
| 01:07.28 | brlcad | right |
| 01:08.03 | brlcad | logically, it makes sense to specify inline on toValue |
| 01:08.19 | brlcad | try this first |
| 01:08.30 | brlcad | revert and just comment out the while loop |
| 01:08.37 | brlcad | does it still complain about the first call |
| 01:09.07 | brlcad | if it does, then that leaves only two (or three) options |
| 01:09.19 | starseeker | it doesn't |
| 01:09.45 | brlcad | okay, so it's the cumulative effect on that "big" function |
| 01:10.04 | brlcad | next up is the guts |
| 01:10.56 | brlcad | heck, even just a simple getPoint() function will probably do the trick |
| 01:11.04 | brlcad | to get just one point |
| 01:11.17 | brlcad | er, one triplet of points |
| 01:11.34 | starseeker | nods |
| 01:12.39 | brlcad | void getPoint(const char *x, const char *y, const char *z, point &p) {... |
| 01:12.58 | starseeker | need triangleLine too |
| 01:13.12 | starseeker | oh, you want to use c_str in the call? |
| 01:13.18 | brlcad | { p[X] = toValue(x); p[Y] = toValue[y]; p[Z] = toValue[z]; return p; } |
| 01:13.30 | brlcad | sure, whatever |
| 01:13.37 | brlcad | those are free |
| 01:13.46 | brlcad | const std::string works too |
| 01:13.57 | brlcad | less to type as chars :) |
| 01:14.23 | starseeker | if function type is void, how come we're returning p? |
| 01:14.34 | brlcad | er, right |
| 01:14.54 | brlcad | hugs c++ references |
| 01:14.58 | starseeker | (not rhetorical - did I miss something?) |
| 01:15.08 | brlcad | no, you're right -- that's wrong |
| 01:15.46 | brlcad | no need to return, you pass point in and it'll get set |
| 01:17.52 | starseeker | grr - now it's complaining about it the toValue calls made from getPoint |
| 01:19.17 | brlcad | different though, right? |
| 01:19.28 | starseeker | same error, different line numbers |
| 01:19.33 | starseeker | and only three of them this time |
| 01:20.01 | brlcad | I doubt it's exactly the same |
| 01:20.21 | brlcad | the previous was large-function-growth limit, and it's by no means a large function any more |
| 01:21.36 | starseeker | http://pastebin.mozilla.org/1655689 |
| 01:21.54 | starseeker | http://bzflag.bz/~starseeker/raw-g.cpp |
| 01:22.36 | brlcad | bingo, not the same |
| 01:22.40 | brlcad | large-stack-frame-growth limit |
| 01:23.14 | brlcad | presumably all the others went away? |
| 01:23.20 | starseeker | yes |
| 01:23.28 | brlcad | good, progress :) |
| 01:23.43 | starseeker | sort of |
| 01:24.00 | starseeker | (is that the correct use of the point variable?) |
| 01:24.26 | starseeker | I gotta head out - do you want me to commit that Sean? |
| 01:25.16 | brlcad | sure, go ahead |
| 01:26.18 | brlcad | fwiw, convention is "usually" inputs followed by outputs unless there's a complex struct involved (like our libged api) or an established api convention otherwise |
| 01:26.29 | CIA-55 | BRL-CAD: 03starseeker * r50869 10/brlcad/trunk/src/conv/raw/ (CMakeLists.txt raw-g.cpp): Reduces (but doesn't eliminate) strict compilation failures in raw-g |
| 01:46.58 | *** join/#brlcad xth1 (~thiago@201.82.133.7) |
| 02:07.39 | CIA-55 | BRL-CAD: 03brlcad * r50870 10/brlcad/trunk/src/conv/raw/ (RegionList.h raw-g.cpp): give getPoint() a little more to do by passing a std::string. make toValue() static since inline is but a hint. quells gcc inline warnings. |
| 02:09.45 | CIA-55 | BRL-CAD: 03brlcad * r50871 10/brlcad/trunk/src/conv/raw/CMakeLists.txt: nostrict no longer needed? compiles clean with gcc 4.6.3 |
| 02:09.56 | brlcad | starseeker: check that out, does the trick here |
| 03:14.16 | _fkr | Those materials sound interesting, brlcad (long way back in the log you mentioned something). I gotta run at the moment though. Back later. |
| 03:19.25 | _fkr | Thank you for the link too, I'll check it out later - slept too long and am in a hurry now. |
| 03:22.05 | brlcad | _fkr: no problem, just a great way for anyone to get started with something that only takes a smidgen of time but advances the project usefully |
| 03:22.22 | brlcad | if you have any questions or have another idea, feel free to chime on in with it |
| 03:34.47 | CIA-55 | BRL-CAD: 03r_weiss * r50872 10/brlcad/trunk/src/libged/red.c: Updated the mged/archer 'red' command. Improved editing of matrices in Windows. |
| 03:36.57 | CIA-55 | BRL-CAD: 03brlcad * r50873 10/brlcad/trunk/src/mged/setup.c: |
| 03:36.57 | CIA-55 | BRL-CAD: cliff removed hideline.c in r48460 when it came up with a coverity maintenance |
| 03:36.57 | CIA-55 | BRL-CAD: cost, but this reference to f_hidline() lingered. upon investigating, it was |
| 03:36.57 | CIA-55 | BRL-CAD: commented out back in 3.1 by phil with a note saying it doesn't work everyone, |
| 03:36.57 | CIA-55 | BRL-CAD: so sounds good to finally fully kill it regardless. the command supposedly |
| 03:36.57 | CIA-55 | BRL-CAD: produced a plotfile hidden line style rendering. |
| 03:47.58 | CIA-55 | BRL-CAD: 03brlcad * r50874 10/brlcad/trunk/src/mged/mged.c: now that coverity quellage has fully disabled it, remove the half-assed log_event() mged event logging interface. simplify maintainability on a feature rarely, if ever, used and costly to keep. |
| 03:53.11 | CIA-55 | BRL-CAD: 03brlcad * r50875 10/brlcad/trunk/src/liboptical/sh_scloud.c: VINIT_ZERO instead of literals |
| 03:57.23 | CIA-55 | BRL-CAD: 03brlcad * r50876 10/brlcad/trunk/src/conv/obj-g.c: |
| 03:57.24 | CIA-55 | BRL-CAD: using bu_calloc() means we don't have to check for null. coverity was |
| 03:57.24 | CIA-55 | BRL-CAD: complaining because we were already checking null in one place implying that we |
| 03:57.24 | CIA-55 | BRL-CAD: need to check for it in other places, but the real fix is to simply not check |
| 03:57.24 | CIA-55 | BRL-CAD: for null anywhere. (cid 1757, r48342) |
| 03:59.52 | CIA-55 | BRL-CAD: 03brlcad * r50877 10/brlcad/trunk/src/libged/view_obj.c: VINIT_ZERO instead of numeric literals |
| 04:00.51 | CIA-55 | BRL-CAD: 03brlcad * r50878 10/brlcad/trunk/src/libged/view_obj.c: VINIT_ZERO scope initialization instead of explicit VSETALL |
| 04:03.12 | brlcad | ``Erik: why >>3 in http://brlcad.svn.sourceforge.net/viewvc/brlcad?view=revision&revision=48523 |
| 04:13.41 | *** join/#brlcad yukonbob (~bch@methodlogic.net) |
| 04:15.50 | CIA-55 | BRL-CAD: 03brlcad * r50879 10/brlcad/trunk/src/libged/get_solid_kp.c: re-enable the 'temporarily disabled' support for pipe keypointing. |
| 04:27.16 | CIA-55 | BRL-CAD: 03brlcad * r50880 10/brlcad/trunk/src/libbu/parse.c: use %zu for size_t instead of casting through long int |
| 04:29.41 | CIA-55 | BRL-CAD: 03brlcad * r50881 10/brlcad/trunk/src/librt/db5_io.c: use BU_EXTERNAL_INIT_ZERO scope initialization instead of explicit init. |
| 04:36.23 | CIA-55 | BRL-CAD: 03brlcad * r50882 10/brlcad/trunk/src/anim/anim_hardtrack.c: use scope initialization where we can |
| 04:41.28 | brlcad | starseeker: would you review richard's r50872 (or at least see if red regressions pass)? he changed one of the regexes for windows |
| 04:41.58 | brlcad | looks mostly safe, changine blank to space, but also removed a mandatory space after one of the numbers |
| 04:55.06 | *** join/#brlcad ksuzee (~ksuzee91@193.151.107.42) |
| 06:00.47 | *** join/#brlcad n_reed_ (~molto_cre@BZ.BZFLAG.BZ) |
| 06:20.05 | *** join/#brlcad cristina (~quassel@188.24.64.37) |
| 06:57.46 | *** join/#brlcad andrei_ (~andrei@5-12-78-246.residential.rdsnet.ro) |
| 07:24.26 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) |
| 07:30.44 | andrei_ | hello |
| 07:31.08 | andrei_ | I m trying to recompile the svn checkout I downloaded to see if my tpkg works |
| 07:31.13 | andrei_ | and it fails |
| 07:31.48 | andrei_ | http://pastebin.ca/2158286 |
| 07:32.02 | andrei_ | these are the errors |
| 07:44.26 | d_rossberg | at a first attempt i would try to remove the /home/andrei/brlcad-build/CMakeTmp/toglstubs directory |
| 07:47.11 | andrei_ | now I get a large number of errors |
| 07:47.27 | andrei_ | but the final output is build files have been written |
| 07:47.45 | andrei_ | CMake Error: Cannot open file for write: /home/andrei/brlcad-build/src/libbu/CMakeFiles/test_bitv.dir/build.make.tmp |
| 07:47.47 | andrei_ | CMake Error: : System Error: Permission denied |
| 07:48.04 | andrei_ | this is one of the errors, for example |
| 07:48.37 | d_rossberg | are you working with different users, e.g. make install as root? |
| 07:50.48 | andrei_ | yes |
| 07:50.52 | andrei_ | i m running sudo make install |
| 07:51.15 | andrei_ | the build process goes on so far |
| 07:51.52 | andrei_ | I m curious if the build process completes succesfully |
| 07:51.53 | d_rossberg | so: if the root writes there something andrei can not change it |
| 07:52.02 | d_rossberg | no it won't |
| 07:52.28 | andrei_ | all that I did was to svn checkout from brlcad rep |
| 07:52.33 | andrei_ | then move into some file called build |
| 07:52.39 | andrei_ | and run $: cmake ../brlcad |
| 07:54.09 | andrei_ | I erased the current build directory and I m attempting a " fresh " installation |
| 07:54.10 | d_rossberg | the repository build is broken, i'm working on it |
| 07:54.17 | andrei_ | aah :) , sorry. |
| 07:54.21 | andrei_ | Anything I could do? |
| 07:55.00 | d_rossberg | btw: i recomment to set the installation directory to /home/andrei/bin/brlcad |
| 07:55.34 | d_rossberg | this way you do not have to change the user for install and you don't influence the remeining system |
| 07:56.05 | andrei_ | thanks for the advice |
| 07:56.53 | andrei_ | so the repo build needs to be fixed before I install it again, right? |
| 08:00.00 | CIA-55 | BRL-CAD: 03d_rossberg * r50883 10/brlcad/trunk/src/anim/anim_hardtrack.c: fixed a crash during build cause by typing error |
| 08:00.35 | d_rossberg | it should now work |
| 08:00.46 | andrei_ | thanks |
| 08:06.30 | andrei_ | d_rossberg : it's working fine now |
| 08:26.41 | andrei_ | there s another error I get while building, I don't think that my system causes it |
| 08:26.43 | andrei_ | http://pastebin.ca/2158306 |
| 08:26.51 | andrei_ | should I try to fix it? |
| 08:42.07 | d_rossberg | i'm not sure, are you working on a 32bit system? maybe this error came with the c++ strict-flag |
| 09:04.49 | *** join/#brlcad stas (~stas@82.208.133.12) |
| 09:13.56 | *** join/#brlcad ksuzee (~ksuzee91@193.151.107.42) |
| 09:42.40 | andrei_ | yes, I m working on 32 bit |
| 10:00.29 | d_rossberg | static_cast<unsigned char>(r) etc. should solve it |
| 10:26.38 | CIA-55 | BRL-CAD: 03Phoenix 07http://brlcad.org * r3810 10/wiki/User:Phoenix/GSoc2012/Reports: /* Week 3 */ |
| 10:37.35 | brlcad | just that one typo or is there more? |
| 10:43.05 | brlcad | andrei_: you working on that error, or something else? |
| 10:45.37 | CIA-55 | BRL-CAD: 03brlcad * r50884 10/brlcad/trunk/src/conv/3dm/3dm-g.cpp: avoid c++ warnings about narrowing conversion within the curly braces. cast accordingly outside initialization. |
| 11:05.15 | CIA-55 | BRL-CAD: 03brlcad * r50885 10/brlcad/trunk/src/proc-db/CMakeLists.txt: |
| 11:05.15 | CIA-55 | BRL-CAD: interestingly enough, only two of the four opennurbs-using proc db apps fail |
| 11:05.15 | CIA-55 | BRL-CAD: strict compilation due to opennurbs headerness. still, disable strict for those |
| 11:05.15 | CIA-55 | BRL-CAD: two with a comment as to what the issue is so compile may succeed (since a fix |
| 11:05.15 | CIA-55 | BRL-CAD: to quell the warning was non-obvious) |
| 11:13.55 | ``Erik | brlcad: to avoid overflow from the <<=3 a couple lines down |
| 11:18.46 | CIA-55 | BRL-CAD: 03erikgreenwald * r50886 10/brlcad/trunk/src/librt/db5_io.c: note that >>3 is to avoid overflow on the <<=3 in the next statement |
| 11:20.43 | *** join/#brlcad ksuzee (~ksuzee91@193.151.107.42) |
| 11:21.18 | ``Erik | andrei_: you're alive! how are exams going? |
| 11:24.47 | ``Erik | d_rossberg: if you need a 32b system for testing, you have an account on crit.brlcad.org (just be aware that syncs from bz might change things on you) |
| 11:34.44 | brlcad | ``Erik: ah, cool, didn't see that! |
| 11:36.16 | ksuzee | brlcad: Hello, Sean! |
| 11:36.37 | ksuzee | Have you read my summary? |
| 11:37.50 | brlcad | ksuzee: if it was written in the last 30 hours, probably not yet |
| 11:39.45 | ksuzee | okay |
| 11:41.59 | d_rossberg | brlcad: after fixing this single type the build succeeded, therefore i think this was the only one |
| 11:44.34 | starseeker | andrei_: what version of CMake is that? |
| 11:45.27 | starseeker | ah, nevermind |
| 11:45.31 | starseeker | user permission stuff |
| 11:48.31 | starseeker | brlcad: (red) I'll take a look - tjt |
| 11:48.36 | starseeker | gre |
| 11:49.03 | starseeker | come on fingers - that's a point I'm not sure of, whether we have red regression testing a matrix-bearing object |
| 11:53.50 | *** part/#brlcad ksuzee (~ksuzee91@193.151.107.42) |
| 11:57.50 | *** join/#brlcad ksuzee (~ksu@193.151.107.42) |
| 12:01.33 | brlcad | d_rossberg: thanks, it was late -- I should have done one more compile to catch that, my bad |
| 12:02.04 | brlcad | got through nearly 500 commit reviews yesterday, less than 50 remaining for release |
| 12:02.42 | brlcad | from about 2000+ to less than 50 now. i smell a release brewing |
| 12:04.09 | brlcad | and 2/3rds of those remaining are richard's, got through everyone else without too many pending more investigation |
| 12:06.04 | brlcad | starseeker: the only one I have left for you is r49752 -- how is BRLCAD_DATA_SUBPATH different from BRLCAD_DATA? |
| 12:06.45 | brlcad | I see it's a relative path value, but then uses bu_brlcad_root to get the prefix |
| 12:07.15 | brlcad | which is curious because one of the bu_brlcad_data behaviors is that as well |
| 12:09.05 | brlcad | ``Erik: the only other issue I had on yours was r48539, which was "bn_dist_pt2_lseg2 returns [-2,3], so cases 4 and 5 can never be reached. Comment them out for now. Cov354" in primitives/bot/bot.c |
| 12:10.52 | brlcad | and by "issue" I mean that seemed suspect since it left dead code around -- those cases matter? or should all of them shift to match bn_dist_pt2_lseg2 return values? |
| 12:16.13 | ``Erik | I d'no, bn_dist_p2_lseg2 comment says it returnsl [-4,3] (and I do see a -4 case), would have to dig in to see what those commented out cases are supposed to deal with to see if it's legitimately dead or if someone changed the bn func without updating the bot func |
| 12:18.42 | CIA-55 | BRL-CAD: 03phoenixyjll * r50887 10/brlcad/trunk/src/librt/primitives/pipe/pipe_brep.cpp: There used to be bugs with the colinear parts. |
| 12:46.06 | andrei_ | hey |
| 12:46.09 | andrei_ | sorry I fell asleep |
| 12:46.36 | brlcad | :) |
| 12:46.39 | andrei_ | Erik,brlcad,starseeker : I should "keep" beeing alive from now |
| 12:47.03 | andrei_ | I finished ( or so I think) the tpkg patch |
| 12:47.14 | brlcad | andrei_: glad to hear it, looking forward to seeing and reading about all the catchup activity here on our! |
| 12:47.18 | brlcad | out even |
| 12:47.41 | andrei_ | yeah, reading and learning tanenbaum in 3 days was nasty stuff :) |
| 12:49.06 | ksuzee | brlcad: hello, once more) Sean, I'm working with directory Util. And there's a couple of functions, which are copied from file to file and I decided to put these common functions in one file util.c (as I told you before). Also I added the headers to the util.h and included it everywhere. But after making there's error - undefined function. Though, if I put the whole function (its body) to the util.h, everything compiles well. So why isn't connection between . |
| 12:49.07 | ksuzee | h and .c seen? Maybe this moment in C is different from C++? I don't know about this moment |
| 12:55.56 | andrei_ | ksuzee, the files in which the undefined function error appears; are they in the same directory? |
| 12:56.24 | ksuzee | andrei_, yeah, of course |
| 12:56.42 | ksuzee | In the same directory "util" |
| 12:58.58 | andrei_ | hm |
| 12:59.16 | andrei_ | are you including it in any c++ file? |
| 12:59.42 | ksuzee | What exactly? |
| 13:00.10 | andrei_ | so you have a .h header with a .c file where the functions are, right? |
| 13:00.21 | ksuzee | yes |
| 13:00.42 | ksuzee | these functions are calling in other file |
| 13:00.44 | andrei_ | and when you include the .h in other files you get undefined functions |
| 13:00.46 | ksuzee | the same dir |
| 13:01.01 | andrei_ | do you get that error on every file or selectively? |
| 13:01.59 | ksuzee | no, no. I get undefined only if put the whole funcftion to the *.c and header - to the *.h. But if the whole function's in *.h, everything works |
| 13:04.09 | ksuzee | also I do include "util.h" in util.c |
| 13:04.12 | ksuzee | as usual |
| 13:04.48 | andrei_ | are you compiling the header files before? |
| 13:05.17 | ksuzee | no, only make util |
| 13:06.00 | andrei_ | I think ( tho , I m not sure , you should ask brlcad for a confirmation or so) that you need to edit the makefile |
| 13:06.10 | andrei_ | err, cmake |
| 13:08.49 | CIA-55 | BRL-CAD: 03starseeker * r50888 10/brlcad/trunk/src/conv/CMakeLists.txt: Add NOSTRICT to 3dm-g until we can get the warning(s) sorted out |
| 13:09.36 | ksuzee | sure, will wait for him) But I'm not sure, that problem's in makefile. The problem's just that header doesn't see its body in *.c |
| 13:09.52 | ksuzee | Because just wih header everything works well |
| 13:11.04 | starseeker | brlcad: BRLCAD_DATA_SUBPATH is relative, where BRLCAD_DATA is absolute |
| 13:12.16 | starseeker | there was a situation where I needed that relative path |
| 13:13.01 | starseeker | if bu_brlcad_root returns something other than CMAKE_INSTALL_PREFIX, BRLCAD_DATA != bu_brlcad_root/BRLCAD_DATA_SUBPATH |
| 13:14.45 | starseeker | I believe it was when I tweaked the data subdirectory in CMake to be something other than share/brlcad/${version} |
| 13:15.26 | starseeker | ah, yes |
| 13:15.28 | starseeker | I remember now |
| 13:16.32 | starseeker | bu_brlcad_data has hard coded checks for share/brlcad/${version}, share/brlcad, share, and a number of other alternatives for the relative data directory |
| 13:17.17 | starseeker | if you set the data directory to something totally different (say, "brlcad_data/${version}") things broke |
| 13:18.00 | starseeker | Adding the BRLCAD_DATA_SUBPATH entry allows bu_brlcad_data to inherit the information of what exactly that relative directory path is from CMake |
| 13:18.26 | starseeker | It doesn't have to try variations on the share directory - it already has the correct answer defined |
| 13:21.29 | starseeker | in principle, bu_brlcad_data now only needs to check the first three cases - getenv("BRLCAD_DATA"), the compile-time path from _brlcad_data(), and bu_brlcad_root/BRLCAD_DATA_SUBPATH |
| 13:22.49 | starseeker | it needs some of the others for the autotools build, which doesn't gurantee the use of the data directory until BRL-CAD is actually installed |
| 13:23.56 | starseeker | I probably should have added a TODO to simplify bu_brlcad_data after autotools goes away |
| 13:33.10 | andrei_ | I updated my folder with svn checkout and I still get some errors |
| 13:33.13 | andrei_ | http://pastebin.ca/2158400 |
| 13:48.19 | ``Erik | andrei_: can you do "make tpkg" or "cd src/libpkg ; make" ? won't fix those errors, but it will build enough of the system for the bit you're concerned with |
| 13:51.36 | CIA-55 | BRL-CAD: 03starseeker * r50889 10/brlcad/trunk/src/proc-db/CMakeLists.txt: |
| 13:51.36 | CIA-55 | BRL-CAD: C++ strict issue - csgbrep.cpp:401:5: error: narrowing conversion of |
| 13:51.36 | CIA-55 | BRL-CAD: '-1759248401l' from 'long int' to 'uint32_t {aka unsigned int}' inside { } is |
| 13:51.36 | CIA-55 | BRL-CAD: ill-formed in C++11 [-Werror=narrowing] - turn off CXX strict until resolved. |
| 14:08.06 | andrei_ | oh, I will do that |
| 14:13.11 | andrei_ | Erik, that works fine. Thanks |
| 14:17.39 | CIA-55 | BRL-CAD: 03starseeker * r50890 10/brlcad/trunk/src/proc-db/CMakeLists.txt: Oops - not a mixed source exec, just use NOSTRICT |
| 14:26.20 | CIA-55 | BRL-CAD: 03starseeker * r50891 10/brlcad/trunk/src/conv/CMakeLists.txt: Don't print messages that will repeat every time - for message handling, this should be turned into a FindADAPTAGRAMS.cmake file (see misc/CMake/FindUTAHRLE.cmake for an idea of how to proceed) |
| 14:26.25 | andrei_ | hm, my tpkg seems to ignore the given -b parameter and I have no idea why. What I did was follow the port example |
| 14:27.19 | andrei_ | I m calling tpkg like this : ./tpkg -t 2000 4096 myfile |
| 14:27.34 | starseeker | no -b flag? |
| 14:27.49 | andrei_ | if I call it with a -b flag I get the " too many arguments" error |
| 14:27.53 | andrei_ | and I modified that in tpkg |
| 14:27.56 | andrei_ | to be > 4 |
| 14:27.59 | andrei_ | instead of 3 |
| 14:28.06 | starseeker | ah |
| 14:28.32 | starseeker | you also need to mod the bu_getopt call |
| 14:28.33 | andrei_ | I mean it doesn't " not work" |
| 14:28.38 | andrei_ | it just uses the default 2048 |
| 14:28.44 | andrei_ | as the parameter was never given or read |
| 14:28.55 | starseeker | line 327 in tpkg.c |
| 14:29.14 | andrei_ | while ((c = bu_getopt(argc, argv, "tTrRp:P:hH:bB")) != -1) { |
| 14:29.30 | starseeker | right - you want -b to read an arg |
| 14:29.51 | starseeker | look at the other options that read args - notice a pattern? |
| 14:30.15 | andrei_ | it should've been |
| 14:30.21 | andrei_ | ":bB:"? |
| 14:30.36 | starseeker | close - the colin comes after the arg letter |
| 14:30.36 | andrei_ | without the first one |
| 14:30.44 | starseeker | so b:B: |
| 14:30.51 | andrei_ | ah, that makes sense |
| 14:31.07 | cristina | starseeker: thanks for letting me know about the message handling for libavoid. This means that I should write a FindADAPTAGRAMS.cmake file besides the check for libavoid in the CMakeListst.txt file? |
| 14:31.15 | andrei_ | thanks starseeker |
| 14:32.16 | starseeker | cristina: actually, it will replace that check - the find_library call will be part of FindADAPTAGRAMS.cmake, and that in turn will be called with find_package(ADAPTAGRAMS) (which is what will replace the current find_library call) |
| 14:32.39 | cristina | ah, ok, I understand. Thank you :) |
| 14:33.47 | starseeker | FindADAPTAGRAMS.cmake will also allow us to search for the other libraries of adaptagrams, if it turns out they are needed |
| 14:33.48 | andrei_ | starseeker, it worked. now |
| 14:33.58 | starseeker | andrei_: good :-) |
| 14:34.11 | andrei_ | but in order to prevent a future re edit I ll paste my call line |
| 14:34.15 | andrei_ | to see if it is how it should be |
| 14:34.35 | andrei_ | $ ./bin/tpkg -t -p 2000 -b 4000 127.0.0.1 myfile |
| 14:34.50 | cristina | starseeker: yes, we might need other libraries as well |
| 14:35.05 | starseeker | andrei_: looks good |
| 14:35.28 | andrei_ | nice, I ll commit it in a few minutes, thanks. |
| 14:37.27 | starseeker | cristina: OK - that just means multiple find_library calls, and more variables passed to FIND_PACKAGE_HANDLE_STANDARD_ARGS |
| 14:37.53 | starseeker | I'd suggest starting with FindUTAHRLE.cmake - copy it to FindADAPTAGRAMS.cmake and start modifying it |
| 14:38.26 | cristina | will do that and then just use find_package in CMakeLists.txt |
| 14:38.35 | starseeker | nods |
| 14:38.48 | starseeker | it shouldn't be terribly complicated |
| 14:38.58 | starseeker | (they can be, but this is a pretty simple one) |
| 14:40.49 | starseeker | cristina: FindADAPTAGRAMS.cmake is also one of the things we will eventually need for src/other support, once substantial features are using adaptagrams - so a good thing to have all around |
| 14:43.06 | cristina | I'll take care of this .cmake file today |
| 14:59.16 | andrei_ | brlcad : I have edited both patches. I ll see later if I manage to do some part of the shell script. |
| 15:10.52 | CIA-55 | BRL-CAD: 03n_reed * r50892 10/brlcad/trunk/src/other/step/src/fedex_plus/classes.c: generate spaces instead of tabs; SCL git 86b9f12 |
| 15:20.42 | CIA-55 | BRL-CAD: 03n_reed * r50893 10/brlcad/trunk/src/other/step/src/clstepcore/STEPattribute.inline.cc: Use UNKNOWN_TYPE when an attribute has no NonRefType. SCL git 6aa4695. |
| 15:21.14 | *** join/#brlcad andrei_ (andrei@5-12-78-246.residential.rdsnet.ro) |
| 15:26.30 | brlcad | cristina: you'll also want to mark the variable advanced (so it doesn't show up in a ccmake listing) and cache it if you can so it doesn't rerun the test every invocation of cmake |
| 15:30.38 | CIA-55 | BRL-CAD: 03starseeker * r50894 10/brlcad/trunk/src/conv/raw/CMakeLists.txt: Grr - still getting strict issues with raw-g. Flag it for now. |
| 15:30.58 | cristina | brlcad: hm, I am not really sure how to do that but I'll look into that matter |
| 15:33.06 | brlcad | cristina: if you run "ccmake ." in your build directory, you'll see your newly added variable -- it shouldn't be in that default listing |
| 15:33.19 | brlcad | look for examples of MARK_AS_ADVANCED |
| 15:33.26 | brlcad | similar for caching |
| 15:33.40 | cristina | aha |
| 15:34.53 | CIA-55 | BRL-CAD: 03n_reed * r50895 10/brlcad/trunk/src/other/step/src/clstepcore/STEPattribute.inline.cc: ensure constructors receive non-null AttrDescriptor; SCL git e547807 |
| 15:51.54 | CIA-55 | BRL-CAD: 03Anuragmurty 07http://brlcad.org * r3811 10/wiki/User:Anuragmurty: /* Development Log */ |
| 15:54.13 | *** join/#brlcad yukonbob (~bch@methodlogic.net) |
| 15:54.18 | yukonbob | hello, #brlcad |
| 17:12.59 | *** join/#brlcad yukonbob (~bch@methodlogic.net) |
| 17:22.34 | CIA-55 | BRL-CAD: 03starseeker * r50896 10/brlcad/trunk/src/tclscripts/rtwizard/rtwizard.tcl: Need to be able to specify both port and framebuffer type on command line for rtwizard |
| 17:24.33 | cristina | brlcad: I added MARK_AS_ADVANCED for my variables. I have a question about caching: don't the find_path and find_library take care of caching? I.e. if the variables are set to valid values, then the functions do nothing? This is what I read here: http://www.vtk.org/Wiki/CMake:How_To_Find_Libraries#Performance_and_caching |
| 17:26.30 | cristina | if I look into the CMakeCache.txt file I see that the variables are set (provided that the library is found) |
| 17:26.36 | CIA-55 | BRL-CAD: 03starseeker * r50897 10/brlcad/trunk/src/tclscripts/rtwizard/rtwizard.tcl: Use verbose flag |
| 17:26.56 | starseeker | cristina: yes, they should |
| 17:27.47 | cristina | starseeker: so there's no need to add something extra, that would 'enforce' caching? |
| 17:55.44 | DarkCalf | waves to brlcad |
| 17:56.28 | CIA-55 | BRL-CAD: 03cprecup * r50898 10/brlcad/trunk/misc/CMake/FindADAPTAGRAMS.cmake: Added helper script FindADAPTAGRAMS.cmake to check for libavoid's existence as a system-installed library and mark as advanced the set variables. |
| 17:57.36 | CIA-55 | BRL-CAD: 03cprecup * r50899 10/brlcad/trunk/src/conv/CMakeLists.txt: Replaced find_library for libavoid with find_package |
| 18:00.18 | *** join/#brlcad ksuzee (~ksu@193.151.107.42) |
| 18:00.48 | CIA-55 | BRL-CAD: 03cprecup * r50900 10/brlcad/trunk/src/conv/CMakeLists.txt: Uncommented harmless line for setting the source files corresponding to libavoid |
| 18:07.20 | *** join/#brlcad ScribbleJ (~ScribbleJ@c-67-173-124-226.hsd1.il.comcast.net) |
| 18:30.55 | *** join/#brlcad jarray52 (~bigbear@unaffiliated/jarray52) |
| 19:13.26 | CIA-55 | BRL-CAD: 03starseeker * r50901 10/brlcad/trunk/src/tclscripts/rtwizard/rtwizard.tcl: Add support for explicitly setting the view model. Also wait more robustly for fbserv to come up before trying to raytrace, and fix one of the -F handling cases in framebuffer type option parsing. |
| 19:22.56 | brlcad | cristina: good progress, but check the header on the new FindADAPTAGRAMS.cmake file |
| 19:23.13 | brlcad | name and copyright years are wrong |
| 19:26.33 | CIA-55 | BRL-CAD: 03cprecup * r50902 10/brlcad/trunk/misc/CMake/FindADAPTAGRAMS.cmake: Corrected header |
| 19:26.54 | cristina | brlcad: thanks for the observation, I've corrected the header |
| 19:27.05 | cristina | sorry about that |
| 19:27.08 | brlcad | thanks |
| 19:27.13 | brlcad | no worries |
| 19:31.01 | brlcad | starseeker: aw, cmon now -- r50889 is trivial to quell :) |
| 19:32.23 | brlcad | just as much effort to add (and later remove) NOSTRICTCXX as it is to do the fix (init outside of the curlies with proper casts) |
| 19:38.35 | crdueck | brlcad: for some primitives with a general and then more specific cases (eg. ell/sph), when making a volume function for the generalized case theres some logic to determine the particular special case which is duplicated exactly in the surface area function. when using these functions in the analyze commands which is going to always use both volume and surface area function it seems a little redundant. |
| 19:41.41 | crdueck | my thought was to write functions for each specific primitive and move the logic to determine the specific instance of the general case to the analyze command |
| 19:44.03 | ksuzee | brlcad: thanks for your comments, Sean! It's just function get_args(int argc, char **argv). I want to rename it to get_args_rle and it's called only in bw_rle.c and pix-rle.c and no more files |
| 20:38.52 | CIA-55 | BRL-CAD: 03n_reed * r50903 10/brlcad/trunk/src/ (7 files in 2 dirs): Put generated globals in a namespace. Namespace declaration written to *Names.h. SCL git 88e9634, da0a395, and 3ed8797. |
| 20:47.52 | *** join/#brlcad ksuzee (~ksuzee91@193.151.107.42) |
| 20:48.02 | *** part/#brlcad ksuzee (~ksuzee91@193.151.107.42) |
| 21:12.41 | brlcad | crdueck: not following, what's redundant? |
| 21:14.41 | brlcad | crdueck: sph's surface area function could merely call the ell's surface area function, if that's what you mean -- or they could be treated as completely separate entities with just very similar calculations being performed |
| 21:18.50 | crdueck | brlcad: maybe tgc is a better example. a tgc could be a rec, rcc, tec or trc. if i make a volume and surface area function for tgc, i need some logic to find which of those special cases is being dealt with. if the analyze command uses those functions to analyze any tgc, then the logic to determine the special case is being preformed twice. |
| 21:20.24 | crdueck | unless there are separate vol/area functions for each special case, and the analyze command determines determines which case is being dealt with and calls those specific functions. I'm just wondering if its better to have many separate functions for different cases of a general shape, or one function for the general case that will result in some code duplication. |
| 21:34.27 | CIA-55 | BRL-CAD: 03starseeker * r50904 10/brlcad/trunk/src/conv/intaval/regtab.h: Clear deprecated string conversion warning with clang |
| 21:36.28 | CIA-55 | BRL-CAD: 03starseeker * r50905 10/brlcad/trunk/src/other/clipper/clipper.hpp: Clear clang warning |
| 21:46.16 | CIA-55 | BRL-CAD: 03brlcad * r50906 10/brlcad/trunk/src/conv/intaval/ (regtab.cpp regtab.h): NULL is not the same thing at all as an emptry string, especially with c++. convert to an empty std::string initializer instead. hopefully not intentionally avoiding stl in api? |
| 21:50.42 | CIA-55 | BRL-CAD: 03starseeker * r50907 10/brlcad/trunk/src/libgcv/wfobj/CMakeLists.txt: Strict issue with obj-g as well |
| 21:51.13 | CIA-55 | BRL-CAD: 03starseeker * r50908 10/brlcad/trunk/doc/docbook/system/man1/en/rtwizard.xml: More work on rtwizard man page. |
| 21:55.18 | brlcad | crdueck: have you looked at the analyze command much yet? |
| 21:55.44 | brlcad | you'll find it already switches on tgc/rec/rcc/trc |
| 21:56.12 | brlcad | (and calculates surface areas and volumes) |
| 21:56.21 | brlcad | just not in a good way |
| 21:57.13 | brlcad | I don't think it matters much if you put fully generalized logic into tgc and have trc/tec/rcc/rec reference or even call that logic |
| 21:57.37 | brlcad | or whether you just treat them all independently and make them do the logic for their case (postentially resulting in a little duplication) |
| 21:58.20 | brlcad | I"d probably lean towards the latter myself and refactor if I found a substantial duplication or general portion that could be extracted and reused, but it really doesn't matter much at that level |
| 21:58.50 | brlcad | what DOES matter more is to move more towards the analyze command knowing absolutely nothing about primitive types |
| 21:59.38 | brlcad | it should just be calling into functab or the rt_ob_*() interface, getting the data and printing it up pretty for the user |
| 22:00.22 | brlcad | all of the existing rt_*_internal awareness is TODO cleanup work that needs to be pushed down into librt |
| 22:01.01 | CIA-55 | BRL-CAD: 03Stattrav 07http://brlcad.org * r3812 10/wiki/User:Stattrav/GSoC2012_log: Updation of the logs. |
| 22:01.57 | *** join/#brlcad cristina (~quassel@188.24.64.37) |
| 22:02.08 | brlcad | most commands in libged shouldn't be aware of object types, only that it's an rt_db_internal -- the rest happening through librt callbacks and API |
| 22:03.40 | CIA-55 | BRL-CAD: 03n_reed * r50909 10/brlcad/trunk/src/other/step/src/fedex_plus/ (classes.c classes.h classes_wrapper.cc multpass.c): cleanup from SCL git cb35164 and 1cfb41d |
| 22:04.17 | *** join/#brlcad cristina (~quassel@188.24.64.37) |
| 22:05.53 | *** join/#brlcad cristina (~quassel@188.24.64.37) |
| 22:06.55 | *** join/#brlcad cristina (~quassel@188.24.64.37) |
| 22:08.12 | *** join/#brlcad cristina (~quassel@188.24.64.37) |
| 22:09.46 | *** join/#brlcad cristina (~quassel@188.24.64.37) |
| 22:13.27 | *** join/#brlcad cristina (~quassel@188.24.64.37) |
| 22:14.13 | *** join/#brlcad cristina (~quassel@188.24.64.37) |
| 22:15.20 | *** join/#brlcad cristina (~quassel@188.24.64.37) |
| 22:16.36 | *** join/#brlcad cristina (~quassel@188.24.64.37) |
| 22:18.06 | *** join/#brlcad cristina (~quassel@188.24.64.37) |
| 22:20.43 | *** join/#brlcad cristina (~quassel@188.24.64.37) |
| 22:20.51 | *** join/#brlcad cristina (~quassel@unaffiliated/cristina) |
| 22:21.20 | *** join/#brlcad cristina (~quassel@188.24.64.37) |
| 22:22.23 | *** join/#brlcad cristina (~quassel@188.24.64.37) |
| 22:26.05 | *** join/#brlcad cristina (~quassel@188.24.64.37) |
| 22:29.46 | *** join/#brlcad cristina (~quassel@188.24.64.37) |
| 22:30.00 | CIA-55 | BRL-CAD: 03n_reed * r50910 10/brlcad/trunk/src/other/step/src/fedex_plus/ (classes_misc.c classes_wrapper.cc): cleanup from SCL git 0bb182b and ed8474e |
| 22:30.50 | *** join/#brlcad cristina (~quassel@188.24.64.37) |
| 22:34.41 | *** join/#brlcad cristina (~quassel@188.24.64.37) |
| 22:36.16 | *** join/#brlcad cristina (~quassel@188.24.64.37) |
| 22:37.23 | *** join/#brlcad cristina (~quassel@188.24.64.37) |
| 22:38.22 | *** join/#brlcad cristina (~quassel@188.24.64.37) |
| 22:39.26 | *** join/#brlcad cristina (~quassel@188.24.64.37) |
| 22:40.40 | *** join/#brlcad louipc (~louipc@archlinux/fellow/louipc) |
| 22:40.53 | *** join/#brlcad cristina (~quassel@188.24.64.37) |
| 22:43.03 | *** join/#brlcad cristina (~quassel@188.24.64.37) |
| 22:43.14 | CIA-55 | BRL-CAD: 03brlcad * r50911 10/brlcad/trunk/src/proc-db/ (CMakeLists.txt csgbrep.cpp): don't punt. less effort to actually fix the problem, especially when there was already a commit showing exactly how to fix a narrowing conversion warning. in this case, even simpler since the cast was wrong. |
| 22:57.11 | CIA-55 | BRL-CAD: 03Al Da Best 07http://brlcad.org * r3813 10/wiki/User:Al_Da_Best/devlog: Update 5th June |
| 23:12.21 | CIA-55 | BRL-CAD: 03crdueck * r50912 10/brlcad/trunk/src/librt/primitives/tgc/tgc.c: added general volume function for tgc |
| 23:14.02 | *** join/#brlcad cristina (~quassel@188.24.71.66) |