| 00:28.21 | starseeker | brlcad: sounds good |
| 01:09.49 | brlcad | woo hoo, got a full-blown red regression test working |
| 01:12.22 | *** join/#brlcad crazy_imp (~mj@a89-182-220-92.net-htp.de) | |
| 02:04.40 | brlcad | the bad news is that it's failing the regression test pretty hard |
| 02:58.02 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 03:55.13 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 04:18.30 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 04:43.40 | ``Erik | *readreadread* git? bah, darcs ftw |
| 05:51.25 | CIA-105 | BRL-CAD: 03brlcad * r44309 10/brlcad/trunk/regress/red.sh: add an extensive test of the mged 'red' command due to repeat failures. regression unveils at least 11 other bugs, quality, and robustness issues still remaining. |
| 05:52.10 | CIA-105 | BRL-CAD: 03brlcad * r44310 10/brlcad/trunk/regress/Makefile.am: add a 'red' rule to run the new red regression test, but don't add it to the release regression due to all of the bugs |
| 05:57.47 | CIA-105 | BRL-CAD: 03brlcad * r44311 10/brlcad/trunk/src/libged/red.c: add a -f force flag to forcibly overwrite a pre-existing comb if the new name would result in an existing object getting overwritten. also fixed a memory free crash bug if final_name is NULL. |
| 06:09.46 | CIA-105 | BRL-CAD: 03brlcad * r44312 10/brlcad/trunk/src/libged/red.c: blather a strong warning since several data-destructive bugs are now confirmed, but not enough time to fix before release. hopefully better to warn than disable since some use cases are fine. |
| 06:10.54 | CIA-105 | BRL-CAD: 03brlcad * r44313 10/brlcad/trunk/TODO: red no longer show-stopper, but still needs to be fixed. |
| 06:11.51 | *** join/#brlcad Stattrav (~Stattrav@122.172.5.31) | |
| 06:11.52 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:14.11 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 06:17.45 | CIA-105 | BRL-CAD: 03brlcad * r44314 10/brlcad/trunk/src/libged/red.c: one sec is probably plenty |
| 07:20.34 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 08:31.32 | *** join/#brlcad mafm (~mafm@85.Red-83-50-132.dynamicIP.rima-tde.net) | |
| 09:36.07 | starseeker | brlcad: nice work on the red regression |
| 09:36.22 | starseeker | sigh - at this rate, I should get to NURBS around August |
| 10:54.47 | *** join/#brlcad mafm_ (~mafm@85.Red-83-50-132.dynamicIP.rima-tde.net) | |
| 13:51.51 | CIA-105 | BRL-CAD: 03starseeker * r44315 10/geomcore/trunk/src/libgvm/files.c: Yes. Handle the global attribute values. |
| 14:24.35 | *** join/#brlcad crazy_imp (~mj@a89-182-220-92.net-htp.de) | |
| 14:30.13 | CIA-105 | BRL-CAD: 03starseeker * r44316 10/geomcore/trunk/src/libgvm/TODO: |
| 14:30.13 | CIA-105 | BRL-CAD: Undoubtedly there's a lot of polishing, API refactoring, and error checking to |
| 14:30.13 | CIA-105 | BRL-CAD: do still - however, the core features of .g file breakup, committing, |
| 14:56.28 | starseeker | dloman: if you're around, could you take a look at the current state of libgvm? |
| 14:57.40 | starseeker | It needs robustness testing (with near-certain bug repairs), error handling, etc. but the key abilities are there now, so if it doesn't look too daunting I'd like to toss it over to you and tackle some helpdesk stuff (search, etc...) |
| 15:16.44 | CIA-105 | BRL-CAD: 03erikgreenwald * r44317 10/geomcore/trunk/src/interfaces/cl/ (gvm.asd gvm.lisp): libgvm cffi |
| 15:32.38 | brlcad | starseeker: did you run it? |
| 15:33.24 | brlcad | starseeker: as long as you get to (and finish) nurbs before october, we're good ;) |
| 15:40.46 | dloman | starseeker: Im kinda around today. I'll take it from here if you need/want to get moving back to NURBs. |
| 16:27.00 | CIA-105 | BRL-CAD: 03brlcad * r44318 10/brlcad/trunk/ (NEWS include/conf/PATCH): beginning final release steps for 7.18.4, bump patch |
| 16:31.22 | CIA-105 | BRL-CAD: 03brlcad * r44319 10/brlcad/trunk/ChangeLog: update changelog for 7.18.4 |
| 16:51.13 | starseeker | brlcad: run the regression? not yet |
| 16:51.41 | brlcad | ok, just wondering |
| 16:56.05 | starseeker | dloman: cool, thanks - let me know if you have any questions |
| 16:56.32 | starseeker | brlcad: I'll take a poke at it today - wanted to get those last two things working for dloman |
| 17:01.47 | starseeker | brlcad: did you want to revert the search changes for the release? I'm not using them in the gvm code anymore so we could probably get away with that |
| 17:05.38 | CIA-105 | BRL-CAD: 03brlcad * r44320 10/brlcad/trunk/NEWS: typo |
| 17:19.45 | CIA-105 | BRL-CAD: 03starseeker * r44321 10/brlcad/branches/cmake/ (31 files in 15 dirs): MFC r44320 |
| 17:28.12 | CIA-105 | BRL-CAD: 03Kunigami 07http://brlcad.org * r2833 10/wiki/User:Kunigami: Initial load |
| 17:30.05 | CIA-105 | BRL-CAD: 03Kunigami 07http://brlcad.org * r2834 10/wiki/User:Kunigami: |
| 17:30.55 | CIA-105 | BRL-CAD: 03Kunigami 07http://brlcad.org * r2835 10/wiki/User:Kunigami: |
| 17:38.44 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 17:45.53 | brlcad | starseeker: I'm about to tag, so probably not :P |
| 17:46.10 | starseeker | ah, k :-) |
| 17:55.12 | brlcad | http://www.siam.org/meetings/gdspm11/ |
| 17:55.18 | brlcad | deadlines approaching for submission |
| 17:55.27 | CIA-105 | BRL-CAD: 03erikgreenwald * r44322 10/brlcad/trunk/src/other/libpng/Makefile.am: add an empty depends rule |
| 17:57.55 | CIA-105 | BRL-CAD: 03brlcad * r44323 10/brlcad/branches/STABLE/ (30 files in 15 dirs): merge trunk to STABLE from r to HEAD r |
| 17:59.26 | brlcad | that wasn't very informative |
| 18:00.15 | starseeker | has flashbacks |
| 18:04.58 | CIA-105 | BRL-CAD: 03brlcad * r44324 10/brlcad/trunk/HACKING: requesting a specific log revision, -rHEAD, results in empty output so don't use it |
| 18:15.30 | CIA-105 | BRL-CAD: 03brlcad * r44325 10/brlcad/branches/STABLE/ (7 files in 5 dirs): merge trunk to STABLE from r44240 to HEAD r44324 ... not really, but previous branch commit had bad log message. should be up-to-date wrt r44324 |
| 18:23.27 | CIA-105 | BRL-CAD: 03brlcad * r44326 10/brlcad/tags/rel-7-18-4/: tag release 7.18.4 |
| 18:26.28 | CIA-105 | BRL-CAD: 03brlcad * r44327 10/brlcad/trunk/HACKING: add diagnostic lines to echo the PREV and CURR values so we know if anything changes |
| 18:36.49 | CIA-105 | BRL-CAD: 03starseeker * r44328 10/brlcad/branches/cmake/ (HACKING src/CMakeLists.txt src/other/libpng/Makefile.am): MFC r44327 |
| 18:41.00 | CIA-105 | BRL-CAD: 03brlcad * r44329 10/brlcad/trunk/ (NEWS README include/conf/PATCH): final testing of source tarball under way, bump to 7.18.5 in anticipation of 7.18.6 next month. |
| 18:55.20 | starseeker | blinks... can it be that simple?? |
| 18:56.23 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 18:58.31 | CIA-105 | BRL-CAD: 03starseeker * r44330 10/brlcad/trunk/src/libged/search.c: This needs more testing, but search . and the conversion.sh script seem to run with this change... |
| 19:02.59 | starseeker | brlcad: looks like search . and search / are back |
| 19:04.40 | starseeker | when you say "relative searching" in the search TODO item, how is search ./havoc -type r different from search . havoc -type r ? |
| 19:08.29 | brlcad | well the latter is invalid syntax, for one ;) |
| 19:11.02 | brlcad | "search ./havoc -type r" is the same as "search havoc -type r" as they are both relative paths, but different from "search /havoc -type r" |
| 19:13.38 | brlcad | fortuantely, any string of ./ and ../ prefixes can probably be ignored since the top-level namespace scope has no parent |
| 19:14.35 | brlcad | the more imporant feature is being able to specify relative subpaths at all, "search havoc/weapons -type r" to get a list of regions under weapons |
| 19:15.05 | brlcad | operationally equivalent to "search weapons -type r" unless/until operators are added that are matrix-sensitives |
| 19:16.24 | brlcad | so it should be possible to just determine if it's absolute (starts with /) or not, if it's not, then walk the basename object |
| 19:19.47 | *** topic/#brlcad by brlcad -> 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.18.4 is posted! (20110412) | |
| 19:19.56 | brlcad | that was a painful release |
| 19:22.33 | starseeker | how is it invalid syntax? search uses . and / to select whether to report a list of objects or full paths |
| 19:22.41 | ``Erik | hm, should "search . havoc -blah" invalid? if we model on find, it'd be silly but valid... I could see wanting to specify several trees in one line.. "search leftwing rightwing -name *fuel*' |
| 19:23.00 | starseeker | the latter will work now |
| 19:23.04 | starseeker | but will return full paths |
| 19:24.08 | starseeker | oh, conceptual mismatch. The way I have it implemented now, the leading . and / have nothing to do with the paths |
| 19:24.32 | starseeker | they might as well be -l and -f (list and fullpath) |
| 19:26.11 | starseeker | um. I'm not sure how matrix sensitive operations would work with the current find logic |
| 19:27.29 | starseeker | brlcad: if I understand you, you're expecting search havoc -type r to return a list, not full paths? |
| 19:39.01 | brlcad | oh, my bad -- I actually didn't know/remember that search/find supported multiple paths .. nifty! |
| 19:40.08 | brlcad | and yes, I'd expect a relative path (including plain object names) to return a list, not paths .. prefix it with a / and you get paths |
| 19:40.12 | brlcad | consistent, simple |
| 19:40.16 | brlcad | no new options |
| 19:41.18 | starseeker | erm |
| 19:42.03 | starseeker | that introduces a new problem - if I mix them, e.g. seach /obj1 obj2 do I then get back a mixed full path/list result? |
| 19:42.38 | starseeker | the . and / have the merit of being unambiguous in that respect |
| 19:42.39 | brlcad | that'd be the impliciation -- if technically infeasible, could just detect and abort |
| 19:44.39 | brlcad | with 'find', having '.' and '/' return paths (relative and absolute respectively), everything works out fine because we're working with a hierarchy and paths are paths |
| 19:45.39 | brlcad | for search, it's a bit more complicated since we're searching over a graph -- there would be no useful difference between '.' and '/' like there is with find since a "relative" geometry path means nothing useful |
| 19:46.21 | brlcad | that's the motivation for "make it useful" since the most common operation is "i'm looking for a list of objects matching my criteria" |
| 19:46.38 | brlcad | not paths, lists -- so hijack the otherwise useless relative option on search |
| 19:48.15 | starseeker | ponders... |
| 19:48.17 | brlcad | I mean, you could make them both work identically, but post-process each path set afterwards (basename+uniq for relative path sets) |
| 19:48.43 | starseeker | the simplest way to mix results would be to run one search per path and accumulate the results, but that means n searchs for n arguments |
| 19:49.04 | brlcad | sounds reasonable |
| 19:49.26 | brlcad | lets you sort/filter each path set independently so you can return paths and non-pathed lists as one set |
| 19:49.59 | brlcad | if they ran "search . /" you'd basically get a list of all objects followed by a list of all paths |
| 19:52.36 | starseeker | do we have any kind of "canonicalization" routine for db paths? |
| 19:53.12 | starseeker | e.g. /havoc/. -> /havoc? |
| 20:08.19 | *** join/#brlcad crazy_imp (~mj@a89-182-220-92.net-htp.de) | |
| 20:10.13 | brlcad | the default posix / bsd one should work |
| 20:10.27 | brlcad | it just looks at the string, not the filesystem |
| 20:10.40 | brlcad | we call it in a couple places to reduce paths |
| 20:11.44 | brlcad | supports harder cases like /havoc/weapons/../fuel_system/lt_fuel/../../fuel_system/. -> /havoc/fuel_system |
| 20:12.11 | brlcad | release is now posted and notified |
| 21:17.50 | starseeker | excellent! |
| 21:18.15 | starseeker | pwd |
| 21:18.17 | starseeker | whoops |
| 21:20.53 | CIA-105 | BRL-CAD: 03starseeker * r44331 10/brlcad/trunk/src/libged/search.c: Take a stab at using . and / prefixes to denote lists or full paths. This is a significant change to the search syntax and functionality, needs testing. Doesn't yet use the canonical logic to simplify paths. |
| 21:27.28 | CIA-105 | BRL-CAD: 03erikgreenwald * r44332 10/geomcore/trunk/src/interfaces/cl/gvm.lisp: add test function |
| 21:28.08 | starseeker | brlcad: let me know if that does what you want |
| 21:29.49 | CIA-105 | BRL-CAD: 03erikgreenwald * r44333 10/geomcore/trunk/src/interfaces/cl/brlcad.lisp: add some callback stuff. Start a facetize function. |
| 21:33.00 | CIA-105 | BRL-CAD: 03starseeker * r44334 10/brlcad/trunk/src/libged/search.c: While I'm at it, fix the print order of the results - toplevel first, then children. |
| 21:43.20 | *** join/#brlcad bhinesley (~bhinesley@adsl-99-104-170-214.dsl.bkfd14.sbcglobal.net) | |
| 22:39.17 | CIA-105 | BRL-CAD: 03starseeker * r44335 10/brlcad/branches/cmake/ (5 files in 4 dirs): MFC r44334 |
| 23:44.51 | CIA-105 | BRL-CAD: 03starseeker * r44336 10/brlcad/trunk/ (include/bu.h src/libbu/vls.c src/libged/search.c): Try some scrubbing on user supplied paths. Not sure this is correct yet, but it does handle some cases. |
| 23:48.29 | starseeker | brlcad: ok, I think the search command is ready for you to see what's still broken :-P |