| 00:45.11 | Notify | 03BRL-CAD:brlcad * 57957 brlcad/trunk/src/libbu/gethostname.c: sprintf() is bad. bu_strlcpy() is good. ensures result is always null terminated and removes need for assert (case-insensitive cpp or just never tested?) |
| 00:51.25 | Notify | 03BRL-CAD:brlcad * 57958 brlcad/trunk/include/bu.h: Expand the documentation on bu_gethostname() |
| 01:03.55 | Notify | 03BRL-CAD:brlcad * 57959 brlcad/trunk/src/libbu/gethostname.c: should not be using WIN32, use the corresponding feature we care about, i.e., HAVE_WINSOCK_H, to initialize the networking library on windows. also should NOT be testing __STD_VERSION__ (and it was wrongly testing __STD_VERSION value). toggle instead on HAVE_GETHOSTNAME. this sig should probably change as this is not libbu's memory management style. |
| 01:13.24 | Notify | 03BRL-CAD:brlcad * 57960 brlcad/trunk/src/libbu/file.c: /* */ comment within a /* */ comment results in a syntax error, but I'm not convinced we should be introducing these as BU API. They don't fit the design and are not functions we can portably implement. while fileno() is also unlikely to NOT exist (similar to inline), there may be other options (like converting callers to FILE*'s or forcing it on as a |
| 01:13.26 | Notify | low-level platform intrinsic) |
| 01:25.25 | brlcad | Ch3ck: massive errors compiling pull.c |
| 01:26.40 | brlcad | /home/sean/brlcad/src/libged/pull.c:150:18: error: ?t_mat[0]? is used uninitialized in this function [-Werror=uninitialized] |
| 01:31.44 | brlcad | Ch3ck: please check that |
| 01:31.54 | Notify | 03BRL-CAD:brlcad * 57961 brlcad/trunk/src/libged/pull.c: looks like the logic is assuming memory starts as zero? might need to be identity. needs testing. |
| 01:31.57 | brlcad | (that being r57961) |
| 01:49.43 | Notify | 03BRL-CAD:brlcad * 57962 brlcad/branches/RELEASE/include/bu.h: mark gethostname() as do-not-use.. likely needs to change signature/name and it was introduced the previous release. |
| 02:09.17 | Notify | 03BRL-CAD:brlcad * 57963 brlcad/trunk/src/libbu/realpath.c: HAVE_REALPATH should not be defined if we're compiling in some mode/environment where it's not available. if it's a decalaration issue, yet available, we should declare it as-needed. there's already a fallback. |
| 02:11.11 | Notify | 03BRL-CAD:brlcad * 57964 brlcad/trunk/src/rt/main.c: no longer need the WIN32 wrapping. |
| 02:47.06 | Notify | 03BRL-CAD:brlcad * 57965 brlcad/trunk/src/libbu/str.c: implement strcasecmp functionality, but keep using system implementation when available |
| 02:47.55 | Notify | 03BRL-CAD:brlcad * 57966 brlcad/trunk/CMakeLists.txt: check for strcasecmp/strncasecmp functions since they are not c89 or c99 (they're posix.1 and 4.4. bsd) |
| 02:51.19 | Notify | 03BRL-CAD:brlcad * 57967 brlcad/trunk/src/libbu/str.c: also implement a simple strncasecmp. |
| 03:14.09 | Notify | 03BRL-CAD:brlcad * 57968 brlcad/trunk/src/libbu/gethostname.c: didn't mean to rename this just yet |
| 03:56.17 | Notify | 03BRL-CAD:brlcad * 57969 brlcad/trunk/src/libbu/malloc.c: looks same false-positive as the other, HAVE_POSIX_MEMALIGN should be the only test needed. we definitely will not be implementing a wrapper like this as bu api... bu_alloc() could handle delivering aligned memory while still using malloc/calloc, but thusfar not necessary/significant. |
| 04:25.37 | Notify | 03BRL-CAD:brlcad * 57970 brlcad/trunk/src/libbu/interrupt.c: should not be defining __* macro vars as they are paramount to invoking -std=gnu (and compiler-specific, they own that namespace). HAVE_SIG_T looks like the right fix, though. shouldn't be either/or: sigaction() can be an additional method (when signal() isn't available). |
| 04:42.11 | *** join/#brlcad n_reed__ (~molto_cre@66-118-151-70.static.sagonet.net) |
| 04:45.33 | Notify | 03BRL-CAD:brlcad * 57971 brlcad/trunk/src/compat/README.compat: should not be setting OR reading the __* compiler preprocessor symbols because they are private and compiler-specific. we'd need a test for that type. |
| 04:58.47 | Notify | 03BRL-CAD:brlcad * 57972 brlcad/trunk/src/libtclcad/tclcad_obj.c: use bu_sscanf() instead of sscanf() since it implements a %z size_t specifier. already have a patch that converts all instances, but am waiting to apply after release is posted |
| 06:12.04 | *** join/#brlcad KimK (~Kim__@wsip-184-176-200-171.ks.ks.cox.net) |
| 06:14.41 | Notify | 03BRL-CAD:brlcad * 57973 brlcad/trunk/src/libbu/vls_vprintf.c: ctype functions required unsigned chars on some bsd platforms (for safety) |
| 06:20.16 | Notify | 03BRL-CAD:brlcad * 57974 brlcad/trunk/src/libicv/tests/icv_read_write.c: classic bug, getopt returns an int. assuming it's a char because it usually stores a char will result in an infinite loop. |
| 07:02.30 | *** join/#brlcad Ch3ck_ (~Shadownet@195.24.220.16) |
| 07:34.05 | Ch3ck | brlcad: looking into it ;) |
| 08:45.38 | *** join/#brlcad KimK (~Kim__@wsip-184-176-200-171.ks.ks.cox.net) |
| 10:04.45 | *** join/#brlcad curatrix (~curatrix@124-168-38-24.dyn.iinet.net.au) |
| 10:28.17 | Notify | 03BRL-CAD Wiki:IIIzzzaaakkk * 6190 /wiki/User:Izak/GSOC_2013_logs: /* GSoC 2013 summary */ |
| 11:59.05 | Notify | 03BRL-CAD:tbrowder2 * 57975 brlcad/trunk/src/libbu/vls_vprintf.c: remove const specifier for proper later use |
| 12:18.15 | brlcad | Ch3ck: I fixed them, but you might want to look over whether the fix is right, what your intent was in the code |
| 12:18.52 | brlcad | Ch3ck: you should check all of the variables and initialize them to zero, null, -1, 1, whatever they need to be |
| 12:28.22 | Ch3ck_ | well brlcad, they are to be initialized to Identity |
| 12:28.35 | Ch3ck_ | so that they could be multiplied correctly moving up the tree |
| 12:30.22 | *** join/#brlcad Izak__ (~Izak@195.24.220.16) |
| 12:31.23 | Ch3ck_ | well brlcad, I need some clarification with the rt_db_get_internal, the 4th argument requires a 4x4 matrix I wish to know if this correctly returns the 4x4 matrix representation for the combination or object? |
| 12:32.46 | Ch3ck | I just wish to know what the 4th argument actually does, looked at rt_db_get_internal() but code still looks complicated ;) |
| 12:45.11 | ``Erik | *read* yeah, looks complicated... every import function has a "mat" parameter, but I believe it's generally ignored |
| 12:47.03 | ``Erik | hrm, yeh, if that matrix is not identity when a torus is loaded, it'll throw a warning and ignore the primitive... |
| 12:47.53 | ``Erik | so I'd assume it expect identity and is there to provide future capability |
| 12:48.33 | ``Erik | does that help? |
| 12:50.07 | ``Erik | neat, netflix was a big presenter at eurobsdcon, they're a huge fbsd user |
| 12:58.59 | *** join/#brlcad Gaganjyot (~gagan@106.192.38.30) |
| 12:59.30 | *** part/#brlcad Gaganjyot (~gagan@106.192.38.30) |
| 13:26.00 | Notify | 03BRL-CAD:carlmoore * 57976 (brlcad/trunk/src/compat/README.compat brlcad/trunk/src/conv/step/g-step/Comb_Tree.cpp): remove trailing blanks |
| 13:28.18 | brlcad | Ch3ck: no it does not, that matrix parameter applies a matrix immediately upon reading an object from disk... as mentioned before, primitives have no notion of a matrix |
| 13:28.27 | brlcad | so there is no matrix to "return" |
| 13:30.59 | brlcad | a combination is aware of a matrix, but the 'mat' parameter of rt_db_get_internal() is still one that is APPLIED (i.e., mulitipled) when the object is read from disk |
| 13:36.10 | *** join/#brlcad Izak__ (~Izak@195.24.220.16) |
| 13:36.27 | *** join/#brlcad Ch3ck_ (~Shadownet@195.24.220.16) |
| 13:47.17 | brlcad | Ch3ck_: did you see the response? |
| 13:47.31 | Notify | 03BRL-CAD:brlcad * 57977 (brlcad/trunk/include/ged.h brlcad/trunk/src/libged/CMakeLists.txt): start bringing this all together. stub in a new (empty) constraint command. |
| 13:48.04 | Notify | 03BRL-CAD:brlcad * 57978 brlcad/trunk/src/mged/setup.c: Add constraint stub to mged |
| 13:50.13 | Notify | 03BRL-CAD:brlcad * 57979 brlcad/trunk/src/libtclcad/tclcad_obj.c: Add constraint to archer |
| 13:50.20 | *** join/#brlcad Gaganjyot (~gagan@106.192.56.247) |
| 14:06.14 | Ch3ck_ | brlcad, seen it ;) |
| 14:06.19 | Ch3ck_ | will fix the bugs |
| 14:11.37 | Ch3ck_ | thanks `Erik, :) |
| 14:13.56 | Ch3ck_ | ``Erik, I'm having problems here compiling code on bzflag, seeing an error "__GNUC__MINOR__ : is not defined" could anyone help me fix that? |
| 14:16.30 | brlcad | Ch3ck_: sure, I can help |
| 14:16.36 | Ch3ck_ | ok |
| 14:16.49 | Ch3ck_ | I don't really know how to fix this. |
| 14:17.05 | brlcad | okay, so lets break it down |
| 14:17.59 | Ch3ck_ | well, I was compiling but it failed with the error "tcl8.6/tcl.h:171:47: error: "__GNUC__MINOR__" is not defined" |
| 14:18.28 | Ch3ck_ | well I don't know if this a problem i've caused or its something with the server |
| 14:18.45 | brlcad | first to understand the error itself |
| 14:18.51 | brlcad | that error is saying "SOME_SYMBOL : is not defined" ... |
| 14:18.58 | brlcad | that's a compilation error about some symbol |
| 14:19.31 | brlcad | looking at that line in that file looks like what? |
| 14:19.31 | Ch3ck_ | yes |
| 14:21.17 | brlcad | (hint: the file is /usr/local/include/tcl8.6/tcl.h) |
| 14:22.11 | ``Erik | the issue is that tcl8.6 is on bz but not compatible with BRL-CAD and our cmake doesn't check that detail :/ |
| 14:22.30 | Ch3ck_ | well looking at the file now |
| 14:22.34 | Ch3ck_ | on bzflag |
| 14:22.34 | ``Erik | force tcl/tk to compile instead of using system as a workaround |
| 14:23.02 | brlcad | aaand a learning opportunity is lost :P |
| 14:23.33 | Ch3ck_ | well I want to learn here |
| 14:23.57 | Ch3ck_ | so what do I do? well seems I can open file only with Vi which i'm not really familiar with ;) |
| 14:24.10 | ``Erik | heh, srry :D it's one of those 'minor glitches' that is turning into a 'major issue', but we're not dealing with... |
| 14:24.42 | ``Erik | Ch3ck_: bz should have vim, emacs, nano, and a handful of others... if your editor of choice isn't on the machine, make a case for it and it might get installed |
| 14:24.43 | brlcad | if you run "less /usr/local/include/tcl8.6/tcl.h" and just type "170", it will jump to line 171 (counts from zero, not one) |
| 14:25.22 | Ch3ck_ | that sounds better |
| 14:25.40 | brlcad | ``Erik: sure minor issue, all the more reason he should be able to understand that error and instantly recognize what's wrong |
| 14:25.52 | Izak__ | Have always preferred emacs to vi |
| 14:26.21 | ``Erik | aight, my bad :) been spending more time in xcode than irc, so still catching up :) |
| 14:26.42 | brlcad | Izak__: good answer ;) (it's more powerful for coding imho, but the learning curve is steeper) |
| 14:27.02 | starseeker | really, best solution would be to get things working with tcl 8.6 |
| 14:27.24 | starseeker | doesn't know what's involved, haven't looked into it |
| 14:27.26 | ``Erik | favors emacs for lisp and vim for C *shrug* but has a long history in sysadmin |
| 14:27.38 | brlcad | Ch3ck_: so looking at line 171 what kind of symbol is that? a C symbol or a pre-processor symbol? |
| 14:28.18 | ``Erik | wanders off to clean the engine grease from his hands, spent the morning under the hood of the truck O.o |
| 14:28.36 | Ch3ck_ | brlcad, its a preprocessor directive |
| 14:28.49 | Izak__ | <PROTECTED> |
| 14:29.12 | starseeker | prefers vim - fewest keystrokes per action, but as a consequence of that design it is a frustrating experience for newbies... |
| 14:29.38 | starseeker | can't claim to be a true vim power user even now |
| 14:29.51 | Ch3ck_ | which is part of the flag values passed to tcl_GetRegExpFromObj |
| 14:31.20 | Ch3ck_ | brlcad, bt what I see here is probably the fact that the comment for TCL_REG_EXPANDED continues to the next line in a weird way |
| 14:31.25 | *** part/#brlcad Gaganjyot (~gagan@106.192.56.247) |
| 14:31.54 | ``Erik | Izak__: no, but my dad was an auto mechanic before his career as a jet mechanic, so I learned to work on my own cars with I guess a fair amount of competence :) |
| 14:32.35 | Izak__ | ``Erik : Good to know :) |
| 14:32.41 | Ch3ck_ | ``Erik, well thats a great skill to have here which could earn you some fast cash :) like 20 dollars daily |
| 14:33.01 | Ch3ck_ | converted from our currency XAF |
| 14:33.04 | brlcad | that fewest keystrokes is highly debatable, especially when modality errors are tracked and/or one is constantly needing to switch modes |
| 14:34.01 | Ch3ck_ | don't really admire the mode aspects of vim |
| 14:34.28 | brlcad | starseeker: without those errors and sticking to few modes, I'd probably agree .. but the few usability studies on the matter showed the modality errors dominate over time |
| 14:35.02 | brlcad | ends up being a "cost overhead" that one doesn't even realize |
| 14:35.38 | Ch3ck_ | thinks we're escaping from a problem here, could pick up the vim/emacs war later ;) |
| 14:35.40 | brlcad | Ch3ck_: so that's good -- it's a preprocessor symbol .. that should tell you a lot about that error message then |
| 14:35.56 | brlcad | do you see why it's an error? |
| 14:36.01 | brlcad | what it's actually complaining about? |
| 14:36.23 | Ch3ck_ | well I think its the commenting |
| 14:36.31 | brlcad | nope |
| 14:36.32 | Ch3ck_ | part which has a problem |
| 14:36.43 | brlcad | comments owuld not be a symbol error |
| 14:37.03 | brlcad | it's a problem with code .. you just identified that it's preprocessor code, not C code that has a problem |
| 14:37.36 | brlcad | the error stated that __GNUC__MINOR__ is not defined |
| 14:38.14 | brlcad | so it should be very obvious that a line saying #if whatever && whatever < else && __GNUC__MINOR__ < 4 ... is an error if __GNUC__MINOR__ is not defined anywhere |
| 14:39.39 | brlcad | do you see that? |
| 14:39.49 | Ch3ck_ | I see |
| 14:40.20 | brlcad | so what to do about that? |
| 14:41.37 | Ch3ck_ | so __GNUC__ is to be changed to __GNU__MINOR__ |
| 14:41.45 | brlcad | nope |
| 14:41.51 | brlcad | that's a completely different symbol |
| 14:42.15 | brlcad | the first question you should be asking is "whose code is this?" |
| 14:42.22 | brlcad | did you write it? is it part of brl-cad? |
| 14:42.47 | Ch3ck_ | well its not part of brlcad |
| 14:42.58 | brlcad | good, but whose is it? |
| 14:43.02 | Ch3ck_ | and it actually has to do with the compiler |
| 14:43.10 | Ch3ck_ | for tcl |
| 14:43.14 | brlcad | right |
| 14:43.36 | brlcad | so on the surface, you could look at this as "there's a bug in one of tcl 8.6's header files" |
| 14:44.00 | Ch3ck_ | yeah |
| 14:44.03 | brlcad | and either don't use 8.6 ... or see if they have an update ... or |
| 14:44.41 | brlcad | if you were paying really close attention, you'd see a discrepancy with the preceding line (169) |
| 14:44.59 | Notify | 03BRL-CAD:starseeker * 57980 brlcad/trunk/src/conv/step/g-step/Assembly_Product.cpp: Hook up the shape representations. |
| 14:45.53 | Notify | 03BRL-CAD:starseeker * 57981 brlcad/trunk/src/conv/step/g-step/Assembly_Product.cpp: remove obsolete comment |
| 14:45.55 | brlcad | not using 8.6 is the "official" position, as we do not own that file and it's a problem in their header .. and they've probably LONG since already fixed this issue |
| 14:46.11 | brlcad | this is done by simply turning on our BUNDLED build option (see INSTALL) |
| 14:46.29 | Ch3ck_ | aight |
| 14:47.00 | brlcad | the second option would involve updating and installing a newer 8.6, which you don't have direct access to, but could request a sysadmin look into |
| 14:47.13 | brlcad | to update /usr/local/include/tk8.6 |
| 14:47.29 | brlcad | the THRID option, however, is the fun one |
| 14:47.37 | brlcad | what's wrong with __GNUC__MINOR__? |
| 14:47.43 | brlcad | why is it not defined? |
| 14:48.15 | brlcad | look at the preceding line |
| 14:48.25 | brlcad | why didn't it complain about that line? |
| 14:48.26 | Ch3ck_ | OK |
| 14:55.46 | brlcad | do you see the preceding line? |
| 14:56.42 | Ch3ck_ | well the preceding line is about DLLIMPORT right? |
| 14:56.49 | brlcad | no |
| 14:56.51 | brlcad | what's line 171? |
| 14:56.59 | brlcad | paste it here |
| 14:59.08 | Ch3ck_ | <PROTECTED> |
| 15:00.15 | brlcad | that's not line 171 |
| 15:00.51 | brlcad | not even close... :) |
| 15:01.32 | brlcad | 171 is the line that it was complaining about __GNUC__MINOR__ ... so it better say __GNUC__MINOR__ on that line ;) |
| 15:02.40 | Ch3ck_ | aight |
| 15:02.53 | brlcad | don't guess, use tools that take you to that line ... basic coding 101, you need to be able to jump to specific lines in files quickly |
| 15:03.35 | Ch3ck_ | thats what I did |
| 15:03.46 | Ch3ck_ | and gave you the results above using less |
| 15:03.55 | brlcad | M-x goto-line in emacs |
| 15:03.58 | brlcad | :171 in vim |
| 15:04.02 | Ch3ck_ | there is no way vim even tells me the current like with the cursor here |
| 15:04.46 | brlcad | you're not understanding 'less' |
| 15:05.01 | brlcad | typing 171 will take you to line 172 and that will be the very top-most line |
| 15:05.17 | brlcad | define DLLEXPORT would be somewhere in the middle of your screen probably, but that still means you guessed |
| 15:05.36 | Ch3ck_ | "# if (__GNUC__ > 4) || ((__GNUC__ == 4) && (__GNUC__MINOR__ >= 5)) |
| 15:05.37 | Ch3ck_ | " |
| 15:05.45 | Ch3ck_ | here is the line with emacs, its better |
| 15:05.48 | Ch3ck_ | ;) |
| 15:05.49 | brlcad | good |
| 15:05.55 | brlcad | and the preceding line? |
| 15:06.43 | Ch3ck_ | #if defined(__GNUC__) &&((__GNUC__>= 4) || ((__GNUC__ == 3) && ( __GNUC_MINOR__>= 1))) |
| 15:07.05 | brlcad | so what's the difference? |
| 15:07.21 | brlcad | there's clearly MINOR on both lines, but it complains about 171 but not 170 |
| 15:07.51 | Ch3ck_ | 171 talks about GNUC being >= 4 |
| 15:08.13 | Ch3ck_ | while the preceding like talks of GNUC being defined or ==3 or >= 4 |
| 15:08.23 | brlcad | good thinking, but not it |
| 15:08.32 | brlcad | it complains about the symbol being not DEFINED |
| 15:08.43 | brlcad | if it's not defined, then 170 would be an error too |
| 15:08.50 | brlcad | why isn't it |
| 15:08.52 | Ch3ck_ | yeah |
| 15:09.41 | Ch3ck_ | because if its not defined line 171 would not be processed |
| 15:09.54 | Ch3ck_ | since its already failed the if defined condition |
| 15:10.23 | brlcad | interesting, but no .. compilers generally always warn on the very first occurance of an error |
| 15:10.51 | brlcad | and indeed the compiler is right |
| 15:11.23 | Ch3ck_ | so what's the real cause of the problem here? |
| 15:11.31 | brlcad | you should ALWAYS assume the compiler is right, at least until you've been actively coding for a decade or have written your own compiler ;) |
| 15:11.38 | brlcad | attention to detail |
| 15:11.45 | brlcad | what's the most common error in programming |
| 15:12.31 | Ch3ck_ | compilation error |
| 15:12.32 | brlcad | how can it possibly be true that line 171 has an unknown symbol yet the preceding line seemingly has that symbol |
| 15:13.03 | Ch3ck_ | well it looks like its been deprecated somewhere in between |
| 15:13.06 | brlcad | too general, it's a specific type of compilation error, a specific cause |
| 15:13.11 | brlcad | it has not |
| 15:13.19 | brlcad | and that word means something else |
| 15:14.38 | brlcad | read very carefully |
| 15:14.42 | brlcad | those two lines |
| 15:14.52 | Ch3ck_ | sorry, just wanted to say its been removed some how |
| 15:15.23 | Ch3ck_ | the first line says |
| 15:15.33 | Ch3ck_ | if GNUC is defined |
| 15:15.37 | Ch3ck_ | check if its >= 4 |
| 15:15.52 | Ch3ck_ | else if its == 3 and GNUC__ MINOR >= 1 |
| 15:16.00 | Ch3ck_ | THEN move to the next line and |
| 15:16.14 | brlcad | that is not what 170 said |
| 15:16.39 | Ch3ck_ | well its what it says |
| 15:16.53 | brlcad | it's the intent of what it was trying to say, but you can't summarize it that generically when looking at any error |
| 15:17.04 | brlcad | a compiler will do exactly and only what it is told |
| 15:17.17 | brlcad | so you need to be exact in describing it |
| 15:17.25 | brlcad | "GNUC__ MINOR >= 1" is not the expression |
| 15:17.31 | brlcad | what is the expression involving MINOR? |
| 15:17.52 | brlcad | you're going to kick yourself when you finally see it |
| 15:17.59 | brlcad | at least you should :) |
| 15:19.17 | Ch3ck_ | well i see a typo |
| 15:19.29 | Ch3ck_ | error with GNUC_MINOR |
| 15:19.38 | Ch3ck_ | they're different |
| 15:19.59 | brlcad | bingo |
| 15:20.04 | Ch3ck_ | "GNUC__MINOR" AND GNUC_MINOR |
| 15:20.21 | brlcad | you're missing the preceding and trailing underscores, but YES! |
| 15:20.26 | Ch3ck_ | its tiny but has caused alot of damage :) |
| 15:20.30 | brlcad | simple typo |
| 15:20.34 | brlcad | it's the most common error |
| 15:20.42 | brlcad | so you always have to be on the look-out for them |
| 15:21.05 | brlcad | "how can it possibly be true that line 171 has an unknown symbol yet the preceding line seemingly has that symbol" ... it CANNOT .. they are DIFFERENT symbols |
| 15:21.23 | Ch3ck_ | yeah they're different ;) |
| 15:21.23 | brlcad | and the latter is clearly a typo once you see that |
| 15:21.37 | brlcad | a one-character typo at that |
| 15:21.44 | Ch3ck_ | yeah |
| 15:21.52 | brlcad | i've fixed the header file, so it should get past that specific error |
| 15:23.37 | Ch3ck_ | ok thanks ;) |
| 15:33.04 | Notify | 03BRL-CAD:brlcad * 57982 brlcad/trunk/src/libged/attr.c: fix a bug introduced in the r57241 refactoring that broke the 'attr get' subcommand. the output format is not the same as attr show and max_attr_name/value_len are not yet computed (so attr get output nothing). lucky, caught in time. |
| 15:36.35 | Ch3ck_ | brlcad, tk.h:21:3: error: #error Tk 8.6 must be compiled with tcl.h from Tcl 8.6 or bettter |
| 15:36.49 | Ch3ck_ | this is still another error I get while compiling |
| 15:37.52 | Notify | 03BRL-CAD:brlcad * 57983 brlcad/branches/RELEASE/src/libged/attr.c: merge just r43219 from trunk since it fixes an unreleased attr get command bug, restores behavior |
| 15:38.55 | brlcad | Ch3ck_: if it's telling you that, it undoubtedly encountered a tcl.h NOT from tcl 8.6+ |
| 15:39.39 | Ch3ck_ | so how do I fix that? |
| 15:40.25 | brlcad | that's a problem with build system paths |
| 15:40.53 | brlcad | unless your object is to get the build working with tcl/tk 8.6 (which would be great), the simple solution is the BUNDLED option I mentioned6 |
| 15:41.01 | brlcad | s/object/objective/ |
| 15:41.43 | Ch3ck_ | ok |
| 15:41.52 | Ch3ck_ | was building in debug mode |
| 15:43.05 | brlcad | irrelevant |
| 15:43.23 | brlcad | (i.e., can/should keep building in debug mode) |
| 15:44.08 | Ch3ck_ | yeah just added the bundled option |
| 15:49.42 | *** join/#brlcad Gaganjyot (~gagan@106.192.60.236) |
| 15:53.14 | *** part/#brlcad Gaganjyot (~gagan@106.192.60.236) |
| 15:56.28 | Notify | 03BRL-CAD:brlcad * 57984 brlcad/trunk/src/libged/attr.c: we don't need the database until we check the version |
| 16:07.03 | Notify | 03BRL-CAD:brlcad * 57985 brlcad/trunk/src/libged/attr.c: too many database open checks |
| 16:52.39 | Notify | 03BRL-CAD:brlcad * 57986 brlcad/trunk/src/libged/attr.c: by convention, the ged command API should be case-insensitive. make attr's subcommands insensitive. |
| 16:54.46 | Notify | 03BRL-CAD:brlcad * 57987 brlcad/trunk/src/libged/attr.c: the pretty print function need not be private API, mark HIDDEN and rename with attr_ prefix |
| 17:00.53 | Notify | 03BRL-CAD:brlcad * 57988 brlcad/trunk/src/libged/attr.c: more hiding of implementation functions, prefixing with the attr_ group name |
| 17:00.58 | ``Erik | Ch3ck_: if you're lost in vi, ^g will post some handy info across the bottom status bar |
| 17:04.27 | Ch3ck_ | ah thanks, ``Erik |
| 17:04.31 | Notify | 03BRL-CAD:brlcad * 57989 brlcad/trunk/src/libged/attr.c: ws indent cleanup |
| 17:24.24 | Notify | 03BRL-CAD:brlcad * 57990 brlcad/trunk/src/libged/ged.c: applying refactoring rule-of-three (Ro3) instead of DRY for the attribute qsort() callback. it's only called twice and requires private API to make it span attr.c for little value and hinders encapsulation. this caller should probably be calling ged_attr() anyways but the format is slightly different, warrants testing. |
| 17:25.00 | Notify | 03BRL-CAD:brlcad * 57991 brlcad/trunk/src/libged/attr.c: make all of the new sorting functions also hidden |
| 17:27.02 | Notify | 03BRL-CAD:brlcad * 57992 brlcad/trunk/src/libged/ged_private.h: and here's the cost we can eliminate. no longer need _ged_cmpattr() published. |
| 17:30.32 | *** join/#brlcad Ch3ck_ (~Shadownet@195.24.220.16) |
| 17:31.46 | Notify | 03BRL-CAD:brlcad * 57993 brlcad/trunk/src/libged/constraint/constraint.c: start hashing out the primary commands and the user interface. this is roughly the approach of the attr command. |
| 17:38.18 | *** join/#brlcad Ch3ck_ (~Shadownet@195.24.220.16) |
| 17:40.50 | Notify | 03BRL-CAD:starseeker * 57994 brlcad/trunk/src/librt/search.c: Fix option ordering for search - -bool wasn't being found by bsearch |
| 17:46.41 | Ch3ck_ | goes out ;) |
| 17:55.20 | Notify | 03BRL-CAD:mohitdaga * 57995 (brlcad/trunk/src/libicv/tests/icv_crop.c brlcad/trunk/src/libicv/tests/icv_fade.c and 6 others): bu_getopt has integer return type. |
| 18:05.55 | brlcad | huh, I made that change last night but I guess I didn't commit it |
| 18:14.07 | Notify | 03BRL-CAD:starseeker * 57996 (brlcad/trunk/src/conv/step/g-step/Assembly_Product.cpp brlcad/trunk/src/conv/step/g-step/ON_Brep.cpp and 2 others): Tone down the debugging output, use nurbs curves for a couple more curve types. |
| 18:16.10 | *** join/#brlcad merzo (~merzo@154-80-132-95.pool.ukrtel.net) |
| 18:25.23 | *** join/#brlcad fethio (~user@78.173.77.60) |
| 18:28.24 | Notify | 03BRL-CAD:starseeker * 57997 brlcad/trunk/src/conv/step/g-step/ON_Brep.cpp: Write out nurbs form of unconverted surfaces |
| 18:41.06 | Notify | 03BRL-CAD:carlmoore * 57998 brlcad/trunk/src/shapes/fence.c: eliminate 'Command-line argument assistance' message and begin directly with 'Usage' |
| 18:48.58 | Notify | 03BRL-CAD:brlcad * 57999 brlcad/trunk/src/shapes/fence.c: don't leave dead code lying around |
| 18:53.29 | Notify | 03BRL-CAD:brlcad * 58000 brlcad/trunk/src/libged/constraint/constraint.c: use a bu command table. provides a cleaner callback interface than using a data-driven type id method. |
| 18:55.19 | Notify | 03BRL-CAD Wiki:Fethiokyar * 0 /wiki/User:Fethiokyar: |
| 18:57.04 | Notify | 03BRL-CAD:starseeker * 58001 brlcad/trunk/src/conv/step/g-step/Assembly_Product.cpp: Set names for positioning objects. |
| 19:09.35 | Notify | 03BRL-CAD:brlcad * 58002 (brlcad/trunk/include/bu.h brlcad/trunk/include/cmd.h): move bu_cmdtab from bu.h to cmd.h |
| 19:11.14 | brlcad | hello fethio |
| 19:25.58 | kanzure | brlcad: hey, i'm having trouble loading .lib files on windows with python + ctypes. are there dll files for brlcad? |
| 19:26.15 | *** join/#brlcad ParahSailin (~ParahSail@50-194-178-148-static.hfc.comcastbusiness.net) |
| 19:27.05 | kanzure | brlcad: there's no mechanism to load .lib files, so i guess that means we need dll files. |
| 19:28.09 | ParahSailin | build error on cygwin: https://gist.github.com/rcallahan/bac483d8685431107305 |
| 19:50.35 | Notify | 03BRL-CAD:carlmoore * 58003 brlcad/trunk/src/shapes/handle.c: implement h? (changing previous h to H), and provide a Usage statement |
| 20:09.25 | Notify | 03BRL-CAD:tbrowder2 * 58004 brlcad/trunk/include/sysv.h: correct strchr signature to avoid C99 error--CMake tests may be causing problems |
| 20:15.52 | *** join/#brlcad DarkCalf (~DarkCalf@173.231.40.99) |
| 20:18.36 | Notify | 03BRL-CAD:carlmoore * 58005 brlcad/trunk/src/shapes/handle.c: add program exit for failed file-open |
| 20:41.57 | brlcad | kanzure: yes, there are dll files (at least there should be, in the bin dir) |
| 20:42.10 | kanzure | ParahSailin: ping |
| 20:50.01 | ParahSailin | pong |
| 20:50.20 | ParahSailin | ah, derp yeah i see them |
| 20:53.20 | Notify | 03BRL-CAD:starseeker * 58006 brlcad/trunk/include/tclcad.h: Looks like tclcad needs cmd.h now. |
| 21:02.55 | Notify | 03BRL-CAD:starseeker * 58007 brlcad/trunk/src/conv/step/g-step/CMakeLists.txt: Ignore all the files for distcheck |
| 21:02.59 | kanzure | ParahSailin: do they work when you use those paths? |
| 21:16.44 | starseeker | brlcad: what are our blockers now for a release? |
| 21:34.24 | zero_level | hi brlcad, ``Erik |
| 22:27.40 | brlcad | ParahSailin: we've not had a complete cygwin build in quite a while, so work there is to be expected |
| 22:28.18 | brlcad | shouldn't be anything major, just build system tweaks and preprocessor work, but hasn't been a priority and cygwin tends to be a moving target |
| 22:29.06 | brlcad | starseeker: just a few commit reviews to go to ensure NEWS is complete, but no known blockers otherwise that I'm aware of |
| 22:31.24 | brlcad | ParahSailin: the build should succeed with the free msvc express, of if you're interested in getting cygwin working, we can walk through issues one at a time, but I'll need a more complete log |
| 22:33.24 | ParahSailin | hm well thats the first place it dies |
| 22:44.36 | maths22 | brlcad: mediawiki is now updated |
| 23:03.56 | maths22 | I also updated gallery |
| 23:44.48 | zero_level | brlcad : Are we plannning for a new release ? |
| 23:46.07 | zero_level | brlcad : Can I help in some way ? |
| 23:46.26 | zero_level | I think there are few news to be updated for the tools in util. |
| 23:46.48 | zero_level | I will ensure I will do it today. |