| 02:43.27 | *** join/#brlcad ibot (~ibot@rikers.org) |
| 02:43.27 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! |
| 05:33.42 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) |
| 05:58.31 | CIA-28 | BRL-CAD: 03brlcad * r47767 10/brlcad/trunk/src/mged/CMakeLists.txt: apparently doing seomthing wrong, so document the FIXME accordingly mged needs to depend on the tclscripts or it won't work for non default and make install target builds (e.g., make regress) |
| 06:04.45 | brlcad | wonders what he's doing wrong given that's what looks like the documented way to do it |
| 06:06.15 | CIA-28 | BRL-CAD: 03brlcad * r47768 10/brlcad/trunk/src/tclscripts/mged/CMakeLists.txt: ws |
| 12:00.51 | *** join/#brlcad merzo (~merzo@193.254.217.44) |
| 15:22.33 | brlcad | n_reed: it's not inconceivable that the solids test image is flawed, but would be a little bit surprising |
| 15:24.00 | brlcad | the regression scripts used to use mater "plastic var=val var2=val2" prior to release 7.0 (open sourcing) |
| 15:25.21 | brlcad | they were all yanked at 7.0 since a couple had problems (unrelated), but then later returned a few months later in their current form |
| 15:26.12 | brlcad | presumably butler was specifically testing whether the mater "plastic {var val var2 val}" syntax worked as that was when that change was made |
| 15:31.05 | n_reed | I agree that the presence of the brace syntax suggests an intent to test said syntax |
| 15:32.41 | n_reed | still, all my testing thus far suggests that the syntax, at least recently, has not worked as intended |
| 15:34.02 | n_reed | it could be that the ineffectiveness of the brace syntax simply went unnoticed because it didn't generate any obvious errors (the raytrace and test still succeed) |
| 15:34.27 | n_reed | of course i could be wrong, and would be happying to continue investigating |
| 15:35.36 | n_reed | but honestly i think it's best if you look into it yourself, because if your not convinced one way or another, I'm not going to bother with any changes |
| 15:37.42 | n_reed | s/happying/happy/ |
| 15:37.59 | n_reed | s/your/you're |
| 15:38.38 | n_reed | need's more caffeine |
| 15:41.10 | n_reed | NEEDS more sleep too x/ |
| 15:46.54 | brlcad | I just pulled up the "original" solids reference image from before it was tclified |
| 15:47.25 | brlcad | looks like a bug |
| 15:48.04 | brlcad | OR he was intentionally testing to make sure {} syntax fails ;) |
| 15:48.49 | brlcad | that there be funny |
| 15:52.53 | brlcad | I bet I see what happened. he also added a new dsp primitive to the test, so the image already changed/needed to change |
| 15:53.16 | brlcad | so a pixdiff would have already been reporting changes, even more easy to overlook those four others that changed due to syntax |
| 15:54.50 | brlcad | n_reed: looks like you're good to un-revert your fix back in |
| 15:54.58 | brlcad | just update the reference while you're at it ;) |
| 15:55.38 | brlcad | the old one doesn't have a dsp or I'd just drop it in, needs a new reference |
| 15:56.31 | brlcad | cross-check it with a couple platforms to make sure you get no off-by errors .. |
| 15:57.13 | brlcad | wishes we had a simh vgr |
| 15:58.30 | n_reed | what is a simh vgr? |
| 15:58.53 | brlcad | vgr was the name of the original baseline reference computer |
| 15:59.24 | brlcad | the numerics were stable and rather well-understood for "correctness" |
| 16:00.39 | brlcad | the benchmark reference images were mostly all created on vgr, so then if you were on a different computer and got pixel values that were ever so slightly off, you could investigate |
| 16:01.20 | brlcad | off by more than one rgb value, and you were looking at a bug (either in code, or compiler, or hardware ... all encountered over the years) |
| 16:02.32 | brlcad | simh is the "simulation hardware" project where they simulate various legacy systems (including a couple systems very similar to vgr's hardware) |
| 16:02.54 | brlcad | basically, it's a VM for really old hardware |
| 16:03.39 | brlcad | if we could simulate vgr, we could regenerate new baseline images with a fair amount of confidence that they're "correct" |
| 16:04.32 | brlcad | two of our benchmark images frequently results in a handful of off-by-one differences -- those were the two not generated on vgr |
| 17:13.25 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) |
| 17:38.52 | CIA-28 | BRL-CAD: 03n_reed * r47769 10/brlcad/trunk/regress/solidspix.asc: changed solids-regress reference image to agree with change in output-pix caused by fix in r47659 |
| 17:47.07 | CIA-28 | BRL-CAD: 03n_reed * r47770 10/brlcad/trunk/src/libbu/parse.c: revert to previous revision |
| 19:33.03 | *** join/#brlcad merzo (~merzo@131-179-132-95.pool.ukrtel.net) |
| 19:50.00 | *** join/#brlcad Forth (~Forth@92.242.118.253) |
| 20:10.54 | brlcad | starseeker: how do you rebuild a specific object file? |
| 20:12.10 | brlcad | I just modified vls.c, want to make sure it still compiles, but don't want to relink libbu or some other binary .. is there some/any way to do that? |
| 20:12.49 | brlcad | old school makefile would have been a simple "make vls.o" |
| 20:22.42 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) |
| 20:24.19 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) |
| 20:28.45 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) |
| 21:45.35 | starseeker | brlcad: not sure you can :-( |
| 22:03.34 | CIA-28 | BRL-CAD: 03n_reed * r47771 10/brlcad/trunk/src/other/perplex/scanner_template.c: allow name of lexer routine and app data parameter to be specified with defines |
| 22:04.06 | CIA-28 | BRL-CAD: 03starseeker * r47772 10/brlcad/trunk/src/ (mged/CMakeLists.txt tclscripts/CMakeLists.txt): Make mged depend on all pkgIndex/tclIndex targets. Probably should do the same for archer... |
| 22:05.02 | starseeker | ah HAH! |
| 22:05.13 | starseeker | brlcad: try this: make vls.c.o |
| 22:05.58 | starseeker | I think that'll do what you want |
| 22:07.35 | starseeker | scratch that - only need to do that for archer if we make archer into a binary target ala mged |
| 22:08.12 | starseeker | unless we fake an archer build target just to hang those dependencies off of... |
| 22:08.14 | starseeker | hmm... |
| 22:16.58 | CIA-28 | BRL-CAD: 03starseeker * r47773 10/brlcad/trunk/src/archer/CMakeLists.txt: Make a stab at switching archer over to a real live build target instead of just a configure-time copy. Untested on Windows. |
| 22:20.21 | CIA-28 | BRL-CAD: 03starseeker * r47774 10/brlcad/trunk/src/archer/CMakeLists.txt: Now that we have an archer target, hang the tclscript dependencies off of it. |
| 22:21.15 | starseeker | re-reads his channel comments and realizes they're a bit mixed - brlcad, in my testing the make vls.c.o worked |
| 22:25.57 | CIA-28 | BRL-CAD: 03starseeker * r47775 10/brlcad/trunk/src/CMakeLists.txt: checking clean configure - need tclscripts target lists defined before archer and mged targets are defined so a one-shot configure gets the right information. |
| 22:39.26 | CIA-28 | BRL-CAD: 03starseeker * r47776 10/brlcad/trunk/src/archer/CMakeLists.txt: |
| 22:39.27 | CIA-28 | BRL-CAD: Archer needs some more dependencies called out (mostly tcl/tk packages it uses). |
| 22:39.27 | CIA-28 | BRL-CAD: 'make archer' now does more or less what you expect - the only exception being |
| 22:39.27 | CIA-28 | BRL-CAD: the Docbook man pages. Not sure whether to make those dependencies... |
| 22:41.45 | brlcad | starseeker: hm, looks like that'll only work if I'm in the cmake subdir for that .o, yes? |
| 22:41.48 | brlcad | should work |
| 22:42.11 | brlcad | libbu/tcl.c.o would have been cool |
| 22:44.10 | brlcad | starseeker: and what was wrong with my ADD_DEPENDENCIES() line? from my reading of the target names, that should have at least gotten the top-level tclscripts/tclIndex and pkgIndex.tcl files |
| 22:45.45 | starseeker | I think there was a capitalization error somewhere... anyway, the new logic should get 'em all |
| 22:46.05 | starseeker | tclindex vs tclIndex, I think... |
| 22:46.05 | brlcad | wouldn't it have given me an error about an unknown dep though? |
| 22:46.32 | starseeker | um. not sure - let me do a quick test |
| 22:47.08 | brlcad | and for that same reason, I added the one for pkgindex too -- or did it also have some case problem? |
| 22:47.27 | starseeker | nope - no error. It's probably figuring it will be defined later or something... |
| 22:48.11 | starseeker | not sure - as soon as I saw what you were trying to do I knew something more... energetic would be needed, so I just dove into the macro logic |
| 22:48.38 | brlcad | I knew something more generic was needed |
| 22:48.50 | starseeker | we *should* be good now |
| 22:48.50 | brlcad | more questioning why that simple test wasn't working |
| 22:49.15 | starseeker | unless you want all the docbook man pages added as dependencies of archer/mged when they're turned on |
| 22:49.20 | starseeker | ah |
| 22:49.45 | starseeker | looks again... |
| 22:49.49 | brlcad | yeah, i wasn't just trying to get past it, trying to understand what was going on |
| 22:49.53 | starseeker | yeah, it was pkgindex not pkgIndex |
| 22:49.57 | brlcad | makes sense if it's case sensitive |
| 22:50.43 | brlcad | means I DID understand everything, just a pedantic detail missing from the auto-target naming that the macro was doing |
| 22:50.46 | starseeker | must confess it's kinda cool to be able to do "make archer" and have it jsut work... |
| 22:50.49 | starseeker | right |
| 22:50.57 | brlcad | test confirmed here |
| 22:51.57 | brlcad | make regress from a new build was failing due to the scripts dep |
| 22:52.45 | brlcad | a nice side effect now is that you can "make regress", have it compile everything the regress suite uses, then make and see what else is likely not being exercised by the testing |
| 22:52.52 | starseeker | yeah, make libbu/tcl.c.o doesn't work work... at a guess, they didn't want to populate all the parent make files with all child targets... |
| 22:55.34 | starseeker | yeah, that makes sense - I was probably always running "make regress" *after* doing make all |
| 22:55.45 | starseeker | oops |
| 22:55.56 | brlcad | likewise, I just happened to have a fresh build and was testing nick's discovery |
| 22:56.06 | brlcad | s/build/checkout/ |
| 22:56.33 | starseeker | talk about an oldie... |
| 22:56.46 | brlcad | that's not old, less than 10 years ;) |
| 22:57.05 | starseeker | well, true, but I mean as part of the regression logic/data |
| 22:57.11 | starseeker | eeep |
| 22:58.19 | starseeker | brlcad: how do you want me to handle it with the thrid party packages/options? I can just document all 3rd party options in the file, or I can set it up to only document the subset that are already documented for configure.ac... |
| 22:58.25 | starseeker | third even... |
| 22:58.42 | starseeker | instructs fingers to get with the program... |
| 23:12.49 | brlcad | what do you mean? options such as? |
| 23:13.41 | brlcad | what was documented by configure? it autodocumented subconfigures and we didn't directly document anything that I'm aware of other than the enable/disable-build options |
| 23:13.45 | starseeker | well, for example, right now there aren't any descriptions for re2c, lemon, tkhtml, tkpng, etc. in INSTALL |
| 23:14.19 | brlcad | the documenting stopped when cmake docs were rolled in, those mostly all came after |
| 23:14.23 | starseeker | we do have zlib, png, opennurbs, utahrle, etc. |
| 23:14.32 | starseeker | right - so what are my criteria for adding things? |
| 23:14.34 | brlcad | so more enable/disable options |
| 23:14.52 | starseeker | vs. ignoreing 'em |
| 23:15.25 | brlcad | if they're significant enough to warrant a src/other building, they should be listed |
| 23:15.40 | starseeker | alrightie |
| 23:15.59 | brlcad | all the more reason to be cautious about adopting new deps, they have overhead to be consistent |
| 23:16.34 | brlcad | can ignore any that are going away in the next 3-6 months (like jove) |
| 23:17.33 | starseeker | won't be too bad once I get up and rolling, just wanted to be sure I wasn't wasting my time on things you didn't want documented |
| 23:18.59 | brlcad | could put re2c, lemon, and perplex into their own subdir in src/other, all toggled off just one flag |
| 23:19.34 | starseeker | really? arrgh :-) after all that nice find logic too... |
| 23:19.58 | brlcad | don't have to |
| 23:20.01 | brlcad | it's fine separate |
| 23:20.08 | brlcad | it's if you wanted to consolidate logic |
| 23:20.38 | starseeker | nods - worth keeping in mind for later, but right now I'd say leave it as-is, since it's functional |
| 23:20.46 | brlcad | similarly with hv3 under tkhtml, similarly minor |
| 23:21.50 | starseeker | nods |
| 23:22.14 | brlcad | aside from hv3 being a versioned-dir tsker |
| 23:22.35 | starseeker | should bug bob about trying that shiny new accordian widget out on the new-improved help browser |
| 23:27.39 | CIA-28 | BRL-CAD: 03starseeker * r47777 10/brlcad/trunk/src/tclscripts/CMakeLists.txt: mind the advanced markings... |
| 23:28.03 | CIA-28 | BRL-CAD: 03starseeker * r47778 10/brlcad/trunk/CMakeLists.txt: Add some aliases for the strict flags. |
| 23:43.52 | starseeker | isn't entirely sure if he cares for the idea of enable/disable options for word size |
| 23:46.20 | CIA-28 | BRL-CAD: 03brlcad * r47779 10/brlcad/trunk/src/libfb/fb_obj.c: reorder to avoid the need for forward declarations. make the command table internal to the function (yet still static so it persists). |
| 23:52.40 | CIA-28 | BRL-CAD: 03starseeker * r47780 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: build the disable options list in a different way. |
| 23:54.01 | CIA-28 | BRL-CAD: 03starseeker * r47781 10/brlcad/trunk/CMakeLists.txt: Add docs for 32/64 bit BRLCAD_WORD_SIZE |
| 23:57.52 | brlcad | they don't really make sense for word size |
| 23:58.16 | brlcad | word size is just that, unless you change it back to configure's meaning being a flag for 64-bit on/off |