| 00:35.27 | *** join/#brlcad phreak4257 (n=phreak@70-56-18-93.eugn.qwest.net) | |
| 00:48.17 | *** join/#brlcad phreak4257 (n=phreak@70-56-18-93.eugn.qwest.net) | |
| 02:21.12 | louipc | |
| 02:21.16 | louipc | kjk |
| 02:41.33 | *** join/#brlcad ilya (n=asus@87.118.102.154) | |
| 02:42.14 | ilya | starseeker: so what? Is it possible to arrange tags that way? |
| 05:57.41 | *** join/#brlcad clock_ (n=clock@77-56-89-241.dclient.hispeed.ch) | |
| 07:33.18 | brlcad | yawns |
| 07:35.40 | *** part/#brlcad pacman87 (n=Timothy@resnet-45-219.dorm.utexas.edu) | |
| 10:26.48 | *** join/#brlcad mafm (n=mafm@elnet-111.lip.pt) | |
| 10:27.17 | mafm | hi |
| 10:32.09 | claymore | Mornin all |
| 10:45.25 | alex_joni | is it possible to import a pro-e solid from brlcad? |
| 10:45.41 | alex_joni | is interested in converting it to STEP or IGES |
| 10:46.01 | claymore | From Pro/E to BRLCAD or from BRLCAD to Pro/E ? |
| 10:47.27 | alex_joni | from PRO/E to BRLCAD |
| 10:48.09 | claymore | Yes, there is a Pro/E to BRL-CAD converter that comes with the BRLCAD source.... although you need to have the Pro-Toolkit to be able to compile the converter. |
| 10:48.38 | claymore | Other routes are Pro/E->IGES->BRL-CAD and Pro/E-> DXF -> BRLCAD |
| 10:48.54 | alex_joni | actually Pro/E->IGES would be enough for me |
| 10:49.01 | alex_joni | but I don't have acces to Pro/E atm |
| 10:49.15 | alex_joni | I only have a model I need as IGES or STEP |
| 10:49.44 | claymore | Oh, are you asking if BRLCAD can perform the Pro/E->IGES conversion? Because if you are, then no, we don't do that ;) |
| 10:50.15 | alex_joni | ok, thanks |
| 11:27.42 | *** join/#brlcad elite01 (n=elite01@unaffiliated/elite01) | |
| 11:31.52 | *** join/#brlcad ``Erik (i=erik@c-68-54-174-162.hsd1.md.comcast.net) | |
| 11:34.51 | claymore | Mernin Erik! |
| 11:46.32 | brlcad | alex_joni: i just read that and am not sure what exactly you were asking wrt conversion |
| 11:47.02 | brlcad | we're not the pro/e folks so I don't see why you'd be asking about proe->iges .. |
| 11:49.47 | claymore | Well, brlcad, when you need 'spert advice about conversions... gotta go to the 'sperts ;) |
| 11:58.38 | claymore | brlcad: you in today? How goes the 'hunting' ? |
| 12:04.08 | alex_joni | brlcad: I was wondering if there is a pro/w->brlcad->iges way |
| 12:04.26 | alex_joni | and claymore is right about the 'spert advice ;) |
| 12:07.06 | claymore | Darn tootin. |
| 13:28.23 | *** join/#brlcad Bariton (n=Bary@p5B14DBA7.dip.t-dialin.net) | |
| 13:48.31 | brlcad | claymore: cept we have more than enough in our own hands to be providing support to commercial cad packages that folks have *paid* them to answer their questions :-) |
| 13:50.11 | brlcad | harmless in this instance, but don't want it to become a habit in general -- focus is selfishly and shamelessly on our stuff |
| 13:50.51 | brlcad | alex_joni: so yeah, in that instance, there'd be no point with the intermediary, just dump pro/e->iges directly |
| 13:55.38 | *** join/#brlcad mafm_ (n=mafm@elnet-111.lip.pt) | |
| 13:59.55 | CIA-24 | BRL-CAD: 03mafm * r32996 10/brlcad/trunk/src/libpc/solver_test.cpp: Avoiding compiler complaint: solver_test.cpp:98: warning: deprecated conversion from string constant to 'char*' |
| 14:11.50 | mafm_ | brlcad: you around? |
| 14:12.44 | mafm | well, any other experienced developer might chime in |
| 14:13.07 | mafm | the supposed fix of my commit above triggers compiler errors |
| 14:13.41 | mafm | because some statically defined C-string is ending up in some struct with char** |
| 14:14.10 | mafm | so I don't know if the proper fix is to modify the struct, revert the change, or what :) |
| 14:18.37 | *** join/#brlcad pacman87 (i=500@resnet-46-165.dorm.utexas.edu) | |
| 14:25.28 | mafm | hi pacman87 |
| 14:27.47 | pacman87 | howdy |
| 14:31.09 | CIA-24 | BRL-CAD: 03mafm * r32997 10/brlcad/trunk/src/libfb/fb_obj.c: Avoiding compiler complaint: fb_obj.c:102: warning: passing argument 4 of 'bu_cmd' from incompatible pointer type |
| 14:46.03 | CIA-24 | BRL-CAD: 03mafm * r32998 10/brlcad/trunk/src/libged/ (get_obj_bounds.c how.c): Including stdlib.h which declares free(), to avoid warning: incompatible implicit declaration of built-in function 'free' |
| 14:46.15 | CIA-24 | BRL-CAD: 03mafm * r32999 10/brlcad/trunk/src/conv/bot_dump.c: Avoid warning: passing argument 3 of 'ged_bot_dump' from incompatible pointer type |
| 15:09.41 | *** join/#brlcad ``Erik (i=erik@c-68-54-174-162.hsd1.md.comcast.net) | |
| 15:10.00 | claymore | hai erik! |
| 15:10.04 | ``Erik | says some impolite things concerning his service provider. |
| 15:10.44 | ``Erik | 'sup, jgkillingvacationboy? |
| 15:12.18 | claymore | not much getyourowndamnjgsfoo, en you? |
| 15:13.05 | ``Erik | I have a few jg's, but I've been building defenses more, being that I can borrow other peoples jg's :D my big jg is gonna be in 65 I think |
| 15:14.24 | claymore | cool. You can have mine when quitting time comes ;) I can prolly hang on another month or so.... |
| 15:15.01 | ``Erik | yeah, I might only last that long, too heh |
| 15:15.37 | ``Erik | I got a DN this weekend and ... well, *shrug* yeah, now I have one, big whup |
| 15:15.45 | ``Erik | game lacks depth :( |
| 15:16.27 | claymore | ah, first dread eh? I am building them up and will do some smashage when I have enough.... takes too long though :/ |
| 15:16.37 | claymore | 580 hours on the next level of photon |
| 15:16.42 | ``Erik | close to my first titan |
| 15:16.42 | claymore | vomits |
| 15:16.49 | claymore | really? NICE |
| 15:16.57 | ``Erik | one more research and a couple structures |
| 15:17.44 | claymore | oh hell. didnt even realize I can make titans now! *slams head on desk* DOH |
| 15:17.48 | ``Erik | and 4 prings in the queue, one already out |
| 15:17.58 | ``Erik | :D it's the 22(3) that's gonna hurt me I think |
| 15:18.05 | claymore | Nice. Prings act as a pretty good deterrant. |
| 15:18.17 | ``Erik | pshields on everything, too, plus 10 dizzies |
| 15:18.20 | claymore | yeah... its PITA. it took soo long I forgot about them. lol |
| 15:18.29 | claymore | hence why I didn't even see them complete lol. |
| 15:19.11 | claymore | Sounds like you have some nice fleet blender planets :) |
| 15:19.23 | ``Erik | <-- not sure how people are spending 4 years with multiple accounts on that game though |
| 15:20.00 | ``Erik | I d'no, how keen would you be to jump http://epsilon.astroempires.com/base.aspx?base=136910 ? :D |
| 15:21.24 | claymore | get those CCs up! otherwise pretty tight :) |
| 15:21.40 | claymore | and no, 4 years on multiple accounts.... can't fathom |
| 15:38.21 | mafm | kicks CIA-24 |
| 15:38.21 | CIA-24 | ow |
| 15:53.44 | mafm | does anybody know if bu_lob / bu_vls_printf support 64 bit pointers? :) |
| 16:55.46 | brlcad | mafm: they should work just fine |
| 16:55.52 | brlcad | we do 64-bit builds |
| 16:57.27 | brlcad | mafm: regarding the static c-string, haven't looked at the patch yet but I would expect a static c-string to be const or well-defined via the api |
| 16:58.25 | mafm | brlcad: does %p work with bu_vls_vprintf? |
| 16:58.52 | brlcad | hm |
| 16:59.03 | brlcad | looks |
| 16:59.31 | mafm | theoretically there's a "case 'p':" but dunno if works with 64 bits |
| 16:59.42 | mafm | that was mostly my question |
| 16:59.44 | brlcad | looks like it should work |
| 17:00.07 | mafm | since some "%x, (unsigned int)pointer" looks like a bad idea for portability |
| 17:00.12 | mafm | and it issues some warnings :) |
| 17:00.21 | mafm | so is it OK if I change them for %p, right? |
| 17:00.24 | brlcad | just sprintf's as an int, which would be 64-bit |
| 17:01.07 | brlcad | every instance of %p and %x that is used I can think of is actually developer/debug statements, nothing incredibly important |
| 17:01.22 | mafm | yes, they're logs |
| 17:01.37 | mafm | in converters |
| 17:01.49 | brlcad | I thought there was some significant portability problem with %p, but I'm not remembering at the moment |
| 17:02.14 | mafm | so do I change them or not? |
| 17:02.40 | brlcad | commit a few and I can run some portability tests |
| 17:03.02 | brlcad | or commit them all as one chunk and I can do the same, either way |
| 17:03.05 | mafm | they're only 4 of them :) |
| 17:04.20 | brlcad | there are more than that -- you probably just found them in one file somewhere :) |
| 17:04.35 | brlcad | there's probably a couple dozen spread throughout where pointer addresses are printed |
| 17:05.11 | CIA-24 | BRL-CAD: 03mafm * r33001 10/brlcad/trunk/src/conv/ (dxf/dxf-g.c dxf/g-dxf.c fast4-g.c): Avoiding warning: cast from pointer to integer of different size -- Using format %p for pointers instead of '%x, (unsigned int)pointer', which should work with bu_vls_vprintf() |
| 17:05.11 | mafm | I mean the ones that I'm intending to shut off |
| 17:05.34 | brlcad | what was the warning? |
| 17:06.07 | mafm | it's in the commit message |
| 17:06.13 | mafm | just printed above |
| 17:06.29 | brlcad | ah, gotit |
| 17:06.30 | mafm | cast from pointer to integer of different size |
| 17:06.52 | mafm | so, pointer is 64 bits and (unsigned int) 32 |
| 17:07.05 | brlcad | ooh, that should have been "unsigned long" for the usual trick, printing to an %lx |
| 17:07.27 | brlcad | the dxf convs are old code |
| 17:08.35 | mafm | but if %p is supported, it's better that way, isn't it? |
| 17:09.09 | brlcad | sure, why not |
| 17:39.00 | mafm | brlcad: FMAX(a, b) is redefined in nirt/interact.c, having it in common.h (same code except for not casting it to double) |
| 17:39.32 | mafm | and it's used for a path length, with doesn't need casting to double at all |
| 17:40.25 | mafm | I'm removing it, if there are no objections :) |
| 17:43.13 | *** join/#brlcad ``Erik (i=erik@c-68-54-174-162.hsd1.md.comcast.net) | |
| 17:43.34 | ``Erik | ... |
| 17:44.24 | brlcad | mafm: no objections here.. |
| 17:44.50 | mafm | wb ``Erik |
| 17:46.03 | mafm | good |
| 17:46.58 | mafm | flaming ``Erik: not using fmax() it's because of the BSD hippies anyway :þ |
| 17:47.16 | brlcad | heh |
| 17:47.39 | ``Erik | huh? |
| 17:47.57 | mafm | it's because of a FMAX macro |
| 17:48.18 | mafm | you would see the commit, but SF's SVN servers are down or something |
| 17:48.43 | ``Erik | which file? |
| 17:48.50 | ``Erik | er, wait, you haven't committed yet |
| 17:48.56 | ``Erik | quit confusin' me, boy :D |
| 17:49.03 | mafm | lol |
| 17:49.05 | mafm | sorry :) |
| 17:50.00 | mafm | it's in nirt/interact.c, redifining the macro in common.h, but the comment says that BRL-CAD uses FMAX() even if it's in c99 because BSDs don't implement it |
| 17:51.34 | mafm | kicks CIA-24 again |
| 17:52.05 | mafm | kicks CIA-24 |
| 17:52.05 | CIA-24 | ow |
| 17:52.12 | mafm | now :P |
| 17:53.35 | ``Erik | hrm, it was sucked in at some point, dun remember when |
| 17:55.59 | ``Erik | july of '04 |
| 17:56.42 | mafm | what does that mean, that some BSD folks removed them from their libc? if so, why? |
| 17:57.29 | ``Erik | june, rather |
| 17:57.41 | brlcad | mafm: sf is still dropping them (or there's a problem with the procmailer) |
| 17:57.58 | brlcad | and will probably continue to drop them until me or another guy can investigate |
| 17:58.08 | brlcad | it's only a few projects |
| 17:58.13 | brlcad | we're "lucky" |
| 17:58.37 | ``Erik | um, sunos 5.1 implemented them as a macro, fbsd has been using suns math.h, which predates c99... it's been slowly pulled into spec |
| 17:58.53 | mafm | brlcad: ok, no problem... it works intermittently anyway |
| 17:59.08 | ``Erik | http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/msun/src/math.h.diff?r1=1.36;r2=1.37;f=h |
| 18:00.02 | ``Erik | I d'no about obsd or nbsd |
| 18:00.41 | ``Erik | should only effect fbsd before 5.0 *shrug* |
| 18:01.09 | mafm | well, it's good to have in common.h then |
| 18:01.20 | mafm | just not duplicated for no purpose :) |
| 18:05.51 | ``Erik | ooh, some neato CPP macro fu for that one |
| 18:06.29 | mafm | huh? |
| 18:07.00 | ``Erik | in gcc's source |
| 18:07.14 | mafm | ah |
| 18:07.16 | mafm | :D |
| 18:07.36 | brlcad | starseeker: somewhere in the manpages, you've got Introduction.html listed as a built_source (which causes it to be deleted) |
| 18:07.42 | mafm | you take the "use the Source, Luke" quite seriously |
| 18:07.45 | brlcad | yet it's also svn managed |
| 18:08.14 | starseeker | oopd |
| 18:08.36 | starseeker | that's just a "here's the help browser" page |
| 18:08.52 | ``Erik | mmx_smaxv2sf3 wow, that's a useful name :D heh |
| 18:08.59 | starseeker | wants it installed, but probably did it wrong |
| 18:10.03 | ``Erik | best I can tell, there is an sse/3dnow op that does basically fmax(), and gcc 4.0 and later will attempt to use it if possible. If FMAX() is used in a tight loop, that's a case for trying to use it :) |
| 18:11.45 | mafm | probably |
| 18:12.11 | mafm | doesn't dare to dive into GCC source code |
| 18:12.38 | ``Erik | it's far less horrible than the 2.7.2.3 days |
| 18:12.53 | mafm | so here I have the last-but-one of the compiler complaints, the one that I unsuccessfully tried to shut before |
| 18:13.00 | ``Erik | even the versioning is far less horrible :D |
| 18:13.28 | mafm | homovulgaris used some struct with char** args for his constraints |
| 18:14.01 | ``Erik | yes, "char **" vs "const char **", which seem sto have been fixed in the last hour or so |
| 18:14.03 | mafm | then in some part of the code is doing: char* args[] = { "whatever", "other" } |
| 18:14.46 | mafm | and the compiler warns because those are "static" c-strings |
| 18:15.24 | mafm | so what's the proper way to deal this kind of things? doing nothing, changing the struct, ...? |
| 18:16.27 | ``Erik | args[0] = "whatever"; args[1] = "other"; ? possibly? |
| 18:16.54 | ``Erik | args = (char **)malloc(sizeof(char *) * 2); before those |
| 18:17.17 | ``Erik | "stop building solver_test by default" :D |
| 18:17.18 | brlcad | mafm: declare them as const char* args[] = ... |
| 18:17.54 | mafm | ``Erik: I thought about that too, probably the best thing to do anyway |
| 18:17.56 | ``Erik | noo, it's being automatically coerced, it's when it's passed to the function, it's trying to convert the const char to char |
| 18:18.12 | mafm | brlcad: that was my first attempt, but then gives a compiler error, not just a warning |
| 18:18.21 | mafm | as erik says |
| 18:18.53 | ``Erik | this is src/libpc/sol<tab> line 98 or so |
| 18:18.57 | mafm | I don't know if the test is related with testing the software or waht |
| 18:19.12 | mafm | I mean, the one running with "make tests" |
| 18:19.29 | mafm | in that case probably it shouldn't be disabled |
| 18:19.41 | ``Erik | no, solver_test is not executed at all from the build system |
| 18:21.06 | mafm | so I just disable it in Makefile.am then |
| 18:21.16 | mafm | phone |
| 18:21.56 | ``Erik | personally, I'd add the .cpp file to EXTRA_DIST and provide an explicit rule to compile it correctly, but not put it in noinst_PROGRAMS, but that's just me |
| 18:30.40 | CIA-24 | BRL-CAD: 03starseeker * r33003 10/brlcad/trunk/doc/docbook/system/man1/en/ (Introduction.html Introduction.xml Makefile.am): Use docbook for intro page too |
| 18:30.48 | starseeker | brlcad: That should work better |
| 18:30.53 | brlcad | mafm: ah, then it sounds like it's getting passed to a routine declared as non-const |
| 18:31.12 | brlcad | which is probably the "problem" .. the constness probably needs to extend throughout libpc |
| 18:33.23 | ``Erik | drops his pants and runs around the building screaming |
| 18:33.44 | ``Erik | (now if only I were to jog down the hall screaming, that'd freak a couple people out, methinks) |
| 18:35.27 | ``Erik | holy crap, it's been a long time since I've logged into a linux machine, heh |
| 18:37.21 | mafm | lol |
| 18:37.34 | mafm | totally freaked out by ``erik |
| 18:38.03 | ``Erik | sanity is overrated |
| 18:38.39 | mafm | brlcad: the question is if from a desgin point of view, this kind of args should be overridable (?) or not |
| 18:39.00 | mafm | I don't think that there's much point in modifying an argument |
| 18:39.28 | mafm | and if in main() is non const, it's because of a special reason |
| 18:39.39 | ``Erik | we have a lot of code that should probably wear the const attribute O.o |
| 18:39.51 | CIA-24 | BRL-CAD: 03brlcad * r33004 10/brlcad/trunk/NEWS: reword cliffs efforts to 'mged help menu is restructured for improved usability' since lowercase mged is used on the one-liners |
| 18:39.56 | ``Erik | you can coerce to const, it's bad to coerce FROM const |
| 18:40.07 | brlcad | mafm: I didn't (at least immediately) see a reason why the API would need to modify that arg |
| 18:40.15 | brlcad | which means const needs to propagate |
| 18:40.38 | brlcad | with that done, it doesn't matter if the caller is const or not |
| 18:41.12 | mafm | good |
| 18:41.28 | mafm | propagates down to the struct or only other function args? |
| 18:42.22 | ``Erik | recursively make the callee const |
| 18:43.39 | ``Erik | int alpha(int x){} int beta(int x){alpha(x);} int gamma(const int x){beta(x);} /* make beta take const int x, then make alpha take const int x */ |
| 18:45.00 | mafm | yup |
| 18:45.20 | mafm | but alpha is using a struct with "char** args" |
| 18:45.50 | mafm | so I guess if I should do that a const, in the struct already -- I think so |
| 18:46.05 | mafm | because of brlcad's explanation about APIs |
| 18:46.56 | CIA-24 | BRL-CAD: 03erikgreenwald * r33005 10/brlcad/trunk/src/other/openNURBS/Makefile.am: no such file: opennurbs.xcodeproj |
| 18:47.10 | brlcad | doesn't recall explaining much about APIs :) |
| 18:47.31 | mafm | [19:40:07] <brlcad> mafm: I didn't (at least immediately) see a reason why the API would need to modify that arg |
| 18:47.39 | ``Erik | um, but the args field is being addressed immediately, the struct itself is not being passed? it's good to coerce TO const, you should do it every time it makes sense O.o :D |
| 18:47.41 | brlcad | if alpha is using a char **args, yes it would need to be made const |
| 18:48.12 | mafm | args is a member of "pc_constrnt" struct really |
| 18:48.23 | brlcad | mafm: I know, I just wouldn't call that explaining much -- just a statement of perception :) |
| 18:48.26 | mafm | so if args shouldn't need to be modified, it can be const there too |
| 18:48.44 | ``Erik | int alpha(char **x); int beta(char **x); int gamma(struct *poo) { beta(poo->x); } /* still cast to const */ |
| 18:49.17 | mafm | :þ |
| 18:49.19 | brlcad | mafm: whether the struct needs to have it set const is a slightly different matter -- it could go either way |
| 18:49.22 | mafm | you'll see the diff |
| 18:49.29 | ``Erik | int alpha(const char **x); int beta(const char **x){alpha(x);} int gamma(struct *poo) { beta((const char **)poo->x); } |
| 18:49.39 | brlcad | if something uses struct->args and it complains about constness, that's where you would need to cast the const potentially |
| 18:49.52 | brlcad | yeah, like that |
| 18:50.16 | ``Erik | yay, tkhtml3 breaks on make distcheck, no rule to make target `distdir' |
| 18:51.29 | brlcad | hm, it does have a dist rule, so hopefully something simple can be done |
| 18:53.04 | ``Erik | hm, since it's fresh from starseeker, should this be, um, more education for him? :D |
| 18:54.17 | brlcad | sounds like an outstanding idea |
| 18:54.27 | brlcad | though I did just hack a fix |
| 18:54.46 | starseeker | drags himself out of the g_qa source code |
| 18:54.51 | PrezKennedy | continuing to teach the padawan the ways of the Farce? |
| 18:54.52 | PrezKennedy | ;) |
| 18:54.52 | ``Erik | :D |
| 18:55.09 | ``Erik | and here I was, all ready to go around the corner and do a major dramatic finger posing pose |
| 18:55.13 | ``Erik | pointing |
| 18:55.58 | CIA-24 | BRL-CAD: 03brlcad * r33006 10/brlcad/trunk/src/other/Makefile.am: totally hack the tkhtml3 dist inclusion. don't even both with logic. someone(tm) should test or make DIST_SUBDIRS actually work. |
| 18:56.11 | brlcad | didn't madonna do finger posing poses? |
| 18:56.19 | brlcad | i remember a song about that |
| 18:56.51 | ``Erik | thought it was more about finger hiding poses |
| 18:56.53 | ``Erik | vogues |
| 18:58.01 | mafm | lol |
| 18:59.11 | mafm | hmm, I don't know if some code of homovulgaris is leaking |
| 18:59.15 | mafm | I will put a note |
| 19:00.45 | mafm | or wait... free() free memory assigned to ** pointers, no need to say the size or anything? or arrays ala delete[] in C++? |
| 19:01.01 | CIA-24 | BRL-CAD: 03brlcad * r33007 10/brlcad/trunk/misc/ (win32-msvc8/Makefile.am win32-msvc9/Makefile.am): bot2raw no longer exists, renamed to bot_dump (with no build file) |
| 19:01.18 | brlcad | mafm: no, there's not delete[] semantic |
| 19:01.25 | brlcad | you delete the elements, then you delete the container |
| 19:01.44 | brlcad | depending on the allocation sorts, assuming dynamic allocation |
| 19:02.23 | mafm | thinks that he didn't use C for far too long :/ |
| 19:02.27 | brlcad | so free()'ing a ** pointer is perfectly fine .. but if it's a container, there is potentially more to free |
| 19:03.33 | mafm | it's the args (char*), not another container |
| 19:04.46 | mafm | goody |
| 19:04.57 | mafm | so yet another complaint removed! |
| 19:06.21 | brlcad | that's the fun with constness .. it's like a vine that grows throughout the code.. once you plant a seed, it has to propagate |
| 19:06.51 | mafm | it's odd in C |
| 19:07.14 | mafm | at least for me in C++ is much more natural when you do it for objects and since the beginning |
| 19:07.15 | brlcad | that mess all started last weekend when I was working on getting c++ compilation mode working |
| 19:07.22 | ``Erik | 2damnit |
| 19:07.40 | ``Erik | brlcad beat me to the msvc files, sucks to be me, testing a distcheck before commiting |
| 19:08.25 | brlcad | the rules are really the same for C++ .. it's just the same sort of issues you'd have if you try to retroactively make class functions const that weren't originally |
| 19:08.36 | brlcad | har har :) |
| 19:11.20 | CIA-24 | BRL-CAD: 03mafm * r33008 10/brlcad/trunk/ (4 files in 2 dirs): const'ifying arguments for constraints (they don't seem to need to be modified), and additionally in this way we avoid yet another compiler warning |
| 19:11.44 | mafm | well, yes, but since you usually take responsibility for each class to manage itself, it's less prone to let anybody access the stuff when it doesn't need it |
| 19:12.03 | mafm | at least it was my major mind-shift when starting to use C++ from C |
| 19:12.14 | brlcad | that can be said of "neat" simple C functions too |
| 19:12.34 | brlcad | it's really just a matter of the guy writing the prototype and remembering to say "oh, this should be const" |
| 19:13.12 | brlcad | which you can forget or do with either -- the language really has nothing to do with it, not even towards encouraging/discouraging you to think about it up front imho |
| 19:13.20 | mafm | yep, but what I'm saying is that in my case, C++ (or OOP in general) makes me to remind that part much more easily |
| 19:13.34 | brlcad | because that's how you learned C++ |
| 19:13.57 | brlcad | I also learned C that way, it's odd for me to not think about it in exactly the same way |
| 19:14.22 | mafm | ``Erik: you can work your automake trickery with solver_test if you want, I'm a bit scared of using that |
| 19:14.44 | brlcad | object encapsulation doesn't change that -- it changes the data, giving me a bunch of "static's" to play with and store things in |
| 19:14.46 | mafm | brlcad: you use const in C all the time? |
| 19:15.04 | brlcad | as much as I remember to do so with C++, sure :) |
| 19:15.20 | brlcad | for new code, it's usually one of a half dozen things I try to ensure |
| 19:16.07 | mafm | :D |
| 19:16.11 | mafm | nice |
| 19:16.19 | brlcad | consistent style, constness, proper scope of functionality, right data types, consistent return values, good readability, etc |
| 19:16.20 | mafm | I've never saw that too much in C code |
| 19:16.37 | CIA-24 | BRL-CAD: 03mafm * r33009 10/brlcad/trunk/src/libpc/pc_constraints.c: Moving doxygen comment to the proper place |
| 19:20.24 | starseeker | works on puzzling out the requirements of distdir |
| 19:21.30 | brlcad | starseeker: while you're at it, doc/docbook dist building is busted too ;) |
| 19:21.53 | starseeker | ok |
| 19:22.15 | mafm | gtoos/solshoot.c gives another (last!) warning at line 158, when assigning a callback |
| 19:22.30 | mafm | "assignment from incompatible pointer type" |
| 19:23.18 | mafm | there are other places with the same assignation and declaration of functions which doesn't give the warning |
| 19:24.07 | mafm | (something in mged I think, grepping for it right now) |
| 19:24.42 | CIA-24 | BRL-CAD: 03brlcad * r33010 10/brlcad/trunk/src/gtools/solshoot.c: ws cleanup |
| 19:25.23 | mafm | mged/solids_on_ray.c 225, in example |
| 19:25.50 | CIA-24 | BRL-CAD: 03brlcad * r33011 10/brlcad/trunk/src/gtools/solshoot.c: remove unused parameter |
| 19:26.08 | brlcad | if they both declare parameter lists, they need to match |
| 19:26.12 | brlcad | in that case, they didn't |
| 19:26.20 | brlcad | but fortunately, the extra arg wasn't even used |
| 19:27.12 | mafm | brlcad: but then the one of mged/solids_on_ray has the same problem |
| 19:28.14 | mafm | gonna compile and test it, but haven't read a warning from it before... |
| 19:28.50 | brlcad | not surprising -- almost everything used to use k&r style declarations |
| 19:29.04 | brlcad | which didn't require argument lists, so the compiler didn't care |
| 19:29.33 | brlcad | the argument lists are continually added over time, causing propagation of warnings where funcs are set and passed around that have to get fixed |
| 19:29.38 | brlcad | kinda like constness propagation |
| 19:29.51 | brlcad | just not as deep |
| 19:30.17 | mafm | hmm |
| 19:30.28 | CIA-24 | BRL-CAD: 03brlcad * r33012 10/brlcad/trunk/src/gtools/beset/ (beset.c population.c): quell extra compilation warnings |
| 19:31.13 | mafm | but what was the difference between both declarations then? I don't see the one of mged having k&r style |
| 19:31.51 | mafm | oh wait, it's inside ifdef |
| 19:32.10 | mafm | so most certainly it wasn't copiled, that's the difference :D |
| 19:35.05 | mafm | well, going home now |
| 19:35.13 | CIA-24 | BRL-CAD: 03mafm * r33013 10/brlcad/trunk/src/mged/solids_on_ray.c: Propagating modification to another file (r33011)) using the same code, the extra parameter didn't match the callback declaration |
| 19:35.30 | mafm | take care :) |
| 20:12.11 | starseeker | blinks has his distcheck fails at tk itself |
| 20:42.36 | starseeker | growls at distcheck |
| 20:49.22 | starseeker | uh-oh - It's giving me tar: brlcad-7.13.0/doc/docbook/lessons/mged/assigning_material_properties_and_raytracing_images/commandwindow.png: file name is too long (max 99); not dumped |
| 20:50.55 | starseeker | brlcad: I take it I need to do some r enaming? |
| 21:17.24 | CIA-24 | BRL-CAD: 03brlcad * r33014 10/brlcad/trunk/src/gtools/ (g_diff.c g_lint.c g_qa.c testfree.c): quell variety of compilation warnings |
| 21:20.54 | brlcad | yeah, looks like posix says 100 is the max |
| 21:21.05 | brlcad | with optional behavior to bump it up to 256 |
| 21:21.15 | brlcad | but portably/practically it drops to 100 |
| 21:21.24 | starseeker | ok |
| 21:21.28 | starseeker | will redo |
| 21:21.47 | brlcad | gnu tar does their own thing to extend it even farther, but even they'll obey the limit if posix mode is set |
| 21:22.30 | brlcad | looks like it's mainly so you don't end up with a tar file that old tar can't open up |
| 21:23.12 | brlcad | aside from "assigning_material_properties_and_raytracing_images" being rediculously long :) |
| 21:26.29 | starseeker | yeah, yeah ;-) |
| 21:26.47 | *** join/#brlcad Gariton (n=kvirc@p54996157.dip.t-dialin.net) | |
| 21:27.02 | CIA-24 | BRL-CAD: 03brlcad * r33015 10/brlcad/trunk/src/gtools/ (Makefile.am testfree.c): get rid of testfree. it's apparently just a trivial test of libbu memory management. really unnecessary. |
| 21:33.58 | brlcad | starseeker: here's a simple fix to g_qa you can make to get ya started into the code |
| 21:34.04 | brlcad | rip out the conversion tables |
| 21:34.08 | brlcad | make it use libbu |
| 21:34.25 | brlcad | that's a hundred lines of waste as it is |
| 21:34.46 | starseeker | unit conversions? |
| 21:35.55 | brlcad | yep |
| 21:36.03 | starseeker | can do |
| 21:36.03 | brlcad | it's all manually hard-coded in there |
| 21:36.13 | brlcad | there are libbu routines to help with that |
| 21:36.18 | CIA-24 | BRL-CAD: 03brlcad * r33016 10/brlcad/trunk/src/gtools/ (g_diff.c g_lint.c g_qa.c g_transfer.c): style/consistency cleanup |
| 21:36.19 | starseeker | humph. A lot of the tools seem to have that coded in |
| 21:36.46 | starseeker | was it rtweight that had that really bad case that was causing incorrect unit printouts? |
| 21:36.47 | brlcad | he has it handling more than linear units, so you might have to keep the other two smaller tables (or add them to libbu) |
| 21:36.55 | starseeker | nods |
| 21:37.00 | brlcad | yeah, they all really need to be refactored |
| 21:37.34 | brlcad | yeah, rtweight's had a bug -- perfect example why that sort of hard-codedness is bad maintainability |
| 21:37.49 | brlcad | gets fixed in one place, and nobody knows about or fixes the other N places |
| 21:40.17 | CIA-24 | BRL-CAD: 03starseeker * r33017 10/brlcad/trunk/doc/docbook/Makefile.am: Try this for docbook build logic - it seems to allow the make distcheck to proceed (wipes out for other reasons, will fix those next.) |
| 21:40.31 | starseeker | OK, I gotta run right now - will retool the lessons subdirectory tonight. |
| 21:59.14 | CIA-24 | BRL-CAD: 03brlcad * r33018 10/brlcad/trunk/src/gtools/ (Makefile.am solshoot.c): |
| 21:59.14 | CIA-24 | BRL-CAD: remove the also mostly useless solshoot test program. looks like it fires a |
| 21:59.14 | CIA-24 | BRL-CAD: hard-coded ray at specified geometry with debugging getting turned on/off for |
| 21:59.14 | CIA-24 | BRL-CAD: redblack tree testing. either way, doesn't do anything useful and has been a |
| 21:59.14 | CIA-24 | BRL-CAD: maintenance burden. bye. |
| 22:07.56 | CIA-24 | BRL-CAD: 03brlcad * r33019 10/brlcad/trunk/src/other/tkhtml3/Makefile.in: don't generate the tkhtml3 documentation every time we run make (nor by default). |
| 22:28.18 | *** join/#brlcad louipc (n=louipc@archlinux/trusteduser/louipc) | |
| 22:54.04 | CIA-24 | BRL-CAD: 03brlcad * r33020 10/brlcad/trunk/src/rt/viewarea.c: |
| 22:54.04 | CIA-24 | BRL-CAD: temporarily revert the center of presented area changes to rtarea since they |
| 22:54.04 | CIA-24 | BRL-CAD: break the output formatting (and the computations still had yet to be |
| 22:54.04 | CIA-24 | BRL-CAD: peer-reviewed by someone for correctness) which would detrimentally affect the |
| 22:54.04 | CIA-24 | BRL-CAD: S2 folks. |
| 22:57.18 | *** join/#brlcad ``Erik (i=erik@c-68-54-174-162.hsd1.md.comcast.net) | |
| 22:59.21 | CIA-24 | BRL-CAD: 03brlcad * r33021 10/brlcad/trunk/src/rt/viewarea.c: emphasize the output formatting deprecation (even if it does risk breaking the S2 tools, it'll prepare folks for the bigger change coming). |
| 23:01.02 | CIA-24 | BRL-CAD: 03brlcad * r33022 10/brlcad/trunk/TODO: rtarea is reverted so the only release issue remaining is to fix the distcheck failures. |
| 23:55.09 | ``Erik | hah, "nailin' paylin", so wrong |