| 00:52.44 | brlcad | starseeker: looks like you introduced a bug in r57663, changed the loop meaning |
| 00:53.04 | *** join/#brlcad kesha_ (~kesha@49.249.16.137) |
| 00:58.28 | brlcad | Ch3ck: bn_mat_is_equal() |
| 02:55.50 | Notify | 03BRL-CAD:starseeker * 57680 brlcad/trunk/src/libicv/ppm.c: revert 57663 |
| 02:57.05 | starseeker | brlcad: reverted until a proper fix is made |
| 03:18.03 | *** join/#brlcad kesha__ (~kesha@49.249.16.137) |
| 03:26.28 | *** join/#brlcad kesha__ (~kesha@49.249.16.137) |
| 03:29.51 | brlcad | starseeker: cool, I think it just needed to be do { c = getc(); } while (c != '\n'); so that the loop wasn't empty |
| 03:30.24 | brlcad | that's all it was complaining about the while () ; where that semi is "do nothing" which was intended |
| 03:30.46 | brlcad | the perils of having an expression that does more than evaluate to a value, but performs some work |
| 03:31.24 | brlcad | why I prefer to separate them whenever possible even if it means a couple more lines of code, it's explicitly clear what each line does |
| 03:32.38 | brlcad | starseeker: been thinking about the directly ** return as well and I think the way to handle it closer to how you originally had it ... basically we need an alternative to NULL for both the dpv and argv when they are set/returned |
| 03:33.42 | kesha__ | hi brlcad.. For the previous compilation error, I ran it from the main directory and here's the paste- http://paste.kde.org/pe1a69e09/ . It gives error #69 |
| 03:36.15 | brlcad | starseeker: and I think there's already a pattern there, we can and should always return a struct directory for each argv .. they just may be RT_DIR_PHONY_ADDR with zero len, but even that is still incredibly useful |
| 03:38.43 | brlcad | kesha__: and? |
| 03:38.50 | brlcad | you've shown that error before |
| 03:39.02 | brlcad | nothing has changed about how you were told to handle it |
| 03:39.26 | kesha__ | brlcad: and its not fixing .. |
| 03:39.41 | brlcad | how would it get fixed, you didn't change anything... :) |
| 03:40.04 | kesha__ | change what ? :) |
| 03:40.25 | brlcad | going back over a week when you first showed that lib.exp error |
| 03:40.26 | kesha__ | compiling dependencies in other ? |
| 03:40.35 | brlcad | I said you can either investigate and fix the cause of that build error |
| 03:40.45 | brlcad | or note that version as a failed compile |
| 03:41.01 | brlcad | hoping that there are huge important sections that result like that |
| 03:41.29 | kesha__ | Thats not the only version that failed compile with this error. there are about 2 dozens which give same compiling error. |
| 03:41.37 | brlcad | I don't have a quick fix answer for that bug, it has to be inspected by someone and diagnosed |
| 03:42.01 | brlcad | bug isn't even the right word, it's some peculiar mix of old sources and newer tools |
| 03:42.20 | brlcad | right, not the only one |
| 03:42.36 | brlcad | so then what are you telling me by having me look at a pastebin of it ?? |
| 03:42.59 | kesha__ | How do I go about investigating make ? |
| 03:43.22 | brlcad | that's almost as generic as asking how you might go about writing code |
| 03:43.26 | brlcad | you investigate |
| 03:43.45 | brlcad | read the sources, read the makefile that you're running |
| 03:43.53 | brlcad | understand the error for starters, go from there |
| 03:44.52 | brlcad | still, I think we're hitting diminishing returns on this path |
| 03:45.12 | brlcad | you've at least not been able to thusfar confirm any version working better than current head |
| 03:45.57 | kesha__ | 7.21 is somewhat 1% better .. But thats not sufficient . |
| 03:46.15 | brlcad | where are you coming up with that number? |
| 03:46.43 | kesha__ | I searched for lib.exp in Makefile and other directories, but its not called from there. |
| 03:47.17 | brlcad | it is somewhere |
| 03:47.33 | brlcad | maybe not as "lib.exp" directly, as is often the case with code |
| 03:48.00 | kesha__ | some revision abt 50k ,I tested and in the current head the lines like structure( like falling rain has been converted to an ellipse) |
| 03:48.05 | brlcad | for example, it could be"${something}.exp" |
| 03:49.23 | brlcad | diminishing returns |
| 03:49.25 | brlcad | lets change the focus these last remaining days to either improving current trunk head step-g importer (make some entity that is failing not fail) or improve/complete the step regression test |
| 03:50.35 | kesha__ | In regression test, next is find area, volume and other quantities |
| 03:50.48 | kesha__ | and check if >0 |
| 03:51.13 | brlcad | no we don't need to find a bunch of quantities |
| 03:51.18 | brlcad | we need A quantity |
| 03:51.24 | brlcad | just to make sure it made something |
| 03:51.44 | kesha__ | just Volume.. fine ? |
| 03:51.46 | brlcad | and to make sure that something is valid for some marginal notion of valid |
| 03:52.10 | kesha__ | *marginal notion of valid* as in ? |
| 03:52.46 | brlcad | you tell me |
| 03:54.18 | kesha__ | something boundary related ? :) |
| 03:54.27 | brlcad | re-read my e-mail |
| 03:54.31 | brlcad | I'm not sure what you mean by that |
| 03:55.42 | kesha__ | being sure of its geometry |
| 03:56.14 | brlcad | starseeker: r57657 .. smells bad |
| 03:57.19 | kesha__ | " Make sure the conversion worked (zero return code, .g file exists, >0 file size, etc). Then you'll need to perform some sort of validation. Maybe calculate a volume (gqa -Av) and make sure the volume is >0 for each file. " |
| 03:58.12 | brlcad | kesha__: and? |
| 03:58.39 | brlcad | all that tells me is that you received what I wrote and you know how to copy-paste |
| 03:58.43 | brlcad | that's not useful |
| 03:58.50 | brlcad | show me you understand what that meant |
| 03:59.45 | brlcad | you were on the right track, you just missing my original point perhaps -- it was very specific |
| 04:00.09 | kesha__ | 1. checking for step-g and the existance of both files and then checking geometry of .g file |
| 04:00.13 | brlcad | you said "next is find area, volume and other quantities" .. i said ... "no ..." |
| 04:00.54 | brlcad | well, your script that you sent also runs "touch file.g" so checking existence with that seems meaningless |
| 04:01.48 | kesha__ | if the file is not there, then it creates, but eventually we are seeing if something is there in file or it was made by touch.. |
| 04:03.22 | Notify | 03BRL-CAD:brlcad * 57681 brlcad/trunk/src/libicv/ppm.c: make no-statement while loops more obvious |
| 04:07.51 | brlcad | why create it (empty)? |
| 04:10.47 | kesha__ | I had used touch script earlier, so I thought that strategy can be used over here also. I will try to modify directly if it exists or not without creating empty file. |
| 04:11.00 | starseeker | brlcad: re:r57657 I'm open to suggestions or just not supporting that at all... |
| 04:12.16 | kesha__ | Btw is there any issue in creating it ? |
| 04:12.46 | starseeker | had to get something working to move forward... Even the feature I was working on today may have to get shelved, if I can't get it working in a few more hours |
| 04:13.28 | starseeker | can probably do what he needs for g-step now, so replacing dbfind get's shoved back again... |
| 04:16.01 | Notify | 03BRL-CAD:brlcad * 57682 brlcad/trunk/src/libicv/ppm.c: handle ppm files a little more gracefully, supporting mac, unix, windows line ending headers just in case. since we don't do anything with them, just add a function that skips to the next line. |
| 04:17.12 | brlcad | kesha__: the issue is it begs the question why a file is being touched. must a .g file exist for something, even if it is completely invalid. if it serves no purpose, the code becomes unnecessary unhelpful distracting complexity that obfuscates what really matters |
| 04:17.28 | brlcad | so again I ask you, "why are you making the script touch the file" |
| 04:17.55 | brlcad | this isn't a question of can or can't, it's should or shouldn't .. i.e., it needs for some reason or it does not |
| 04:18.51 | brlcad | if you cannot answer that (and you wrote the script), then the answer is probably that it doesn't do anything useful and this is just bloat to make it seem like more is going on than really is |
| 04:21.10 | brlcad | starseeker: yeah, my inclination would be to not support that feature (caller's can 'or' the data themselves ... or use the search API) |
| 04:21.14 | brlcad | keeps it simple |
| 04:22.29 | brlcad | lets db_ls() doing one thing simple/well too I think, give a list of geometry of given type(s) |
| 04:31.13 | kesha__ | brlcad: touch as such serves no *special* meaningful purpose, it can be replaced by directly checking existance of file and also resulting would be lesser complex. :) |
| 04:36.12 | Notify | 03BRL-CAD:phoenixyjll * 57683 brlcad/trunk/src/libged/brep.c: Add an "--no-evaluation" option, using the old routine of converting comb without NURBS evaluations (CSG tree + brep). |
| 04:36.56 | Notify | 03BRL-CAD:phoenixyjll * 57684 brlcad/trunk/src/librt/comb/comb_brep.cpp: Mark conv_tree() with HIDDEN. |
| 04:48.42 | zero_level | brlcad : Thanks for the ppm files. |
| 04:50.23 | zero_level | is analyzing the changes made. |
| 04:59.26 | zero_level | ok. |
| 06:12.26 | *** join/#brlcad yiyus (1242712427@je.je.je) |
| 06:13.04 | *** join/#brlcad n_reed__ (~molto_cre@66-118-151-70.static.sagonet.net) |
| 06:13.12 | *** join/#brlcad kesha__ (~kesha@49.249.17.64) |
| 06:14.06 | *** join/#brlcad witness___ (uid10044@gateway/web/irccloud.com/session) |
| 06:15.59 | *** join/#brlcad quantumkat (~kat@ip70-171-0-190.ga.at.cox.net) |
| 06:34.03 | *** join/#brlcad kesha__ (~kesha@49.249.199.55) |
| 06:40.22 | Notify | 03BRL-CAD Wiki:Eduardolalla * 0 /wiki/User:Eduardolalla: |
| 06:53.09 | *** join/#brlcad cogitokat (~kat@ip70-171-0-190.ga.at.cox.net) |
| 06:53.37 | *** join/#brlcad witness__ (uid10044@gateway/web/irccloud.com/x-xsamscszvskldbnl) |
| 07:39.30 | kanzure | brlcad: any hints on how i can pick which parts to wrap first? i've been working on bu and wdb but maybe i should be looking at other things too? are there a pile of tests i could re-implement into python? |
| 07:48.32 | *** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net) |
| 08:06.42 | *** join/#brlcad kimzzzz (~AndChat31@1.38.31.154) |
| 08:13.33 | *** join/#brlcad AndChat|317009 (~AndChat31@1.38.31.154) |
| 08:15.19 | *** join/#brlcad kimzzzz (~AndChat31@1.38.31.154) |
| 08:22.31 | *** join/#brlcad kimzzzz (~AndChat31@1.38.31.154) |
| 08:28.34 | *** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net) |
| 08:42.33 | *** join/#brlcad d_rossberg (~rossberg@66-118-151-70.static.sagonet.net) |
| 08:43.54 | *** join/#brlcad kimzzzz (~AndChat31@1.38.31.154) |
| 09:34.02 | *** join/#brlcad Ch3ck_ (~Shadownet@195.24.220.16) |
| 09:48.30 | *** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net) |
| 09:59.25 | Notify | 03BRL-CAD:tbrowder2 * 57685 brlcad/trunk/include/bu.h: not sure what was intended, but this should suffice until something better appears |
| 10:07.53 | *** join/#brlcad Ch3ck_ (~Shadownet@195.24.220.16) |
| 10:11.26 | Notify | 03BRL-CAD Wiki:NandlalPael * 0 /wiki/User:NandlalPael: |
| 10:15.05 | Notify | 03BRL-CAD:tbrowder2 * 57686 brlcad/trunk/include/bu.h: correct glob expression |
| 10:49.48 | *** join/#brlcad kesha__ (~kesha@14.139.122.114) |
| 11:06.26 | *** join/#brlcad Izak__ (~Izak@195.24.220.16) |
| 11:12.41 | *** join/#brlcad kimzzzz (~AndChat31@1.38.31.154) |
| 11:26.08 | Izak__ | brlcad: ``Erik: I'm working on rt_hrt_plot() which depends on a private helper function rt_hrt_24pts().When testing in archer, this error ( see http://paste.kde.org/pfa8a5da8/) shows up. Can anyone help me out with possible clarifications on how to approach this error ? This is the rt_hrt_plot() code http://paste.kde.org/p75413ef1/ |
| 12:09.19 | Notify | 03BRL-CAD:indianlarry * 57687 (brlcad/branches/nurbs/include/bu.h brlcad/branches/nurbs/include/icv.h and 11 others): Merging trunk into branch 'nurbs' r:57668:57686 |
| 12:13.19 | *** join/#brlcad Gaganjyot (~gagan@125.62.105.4) |
| 12:18.40 | Notify | 03BRL-CAD Wiki:KeshaSShah * 6145 /wiki/User:KeshaSShah/GSoC13/Reports: /* Week 14 */ |
| 12:24.36 | *** join/#brlcad kesha__ (~kesha@14.139.122.114) |
| 13:00.55 | *** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net) |
| 13:18.29 | *** part/#brlcad Gaganjyot (~gagan@125.62.105.4) |
| 13:49.39 | brlcad | kanzure: I'd suggest libged next ... that'd let someone basically write an entire editor if they really wanted |
| 13:59.57 | Notify | 03BRL-CAD:brlcad * 57688 brlcad/trunk/TODO: mirror command needs some tlc. the offset value looks like a translation after mirror instead of before. |
| 14:05.56 | Notify | 03BRL-CAD:carlmoore * 57689 brlcad/trunk/include/icv.h: remove trailing blanks/tabs |
| 15:08.09 | kanzure | brlcad: thanks, i'll do that |
| 15:17.58 | Izak__ | brlcad: can you help me with the concern I last posted ? |
| 15:57.15 | Notify | 03BRL-CAD:carlmoore * 57690 brlcad/trunk/src/conv/tankill/g-tankill.c: add P to the usage, which was split in 2 due to warning about string length |
| 16:06.41 | *** join/#brlcad kesha__ (~kesha@14.139.122.114) |
| 16:33.31 | *** join/#brlcad Gaganjyot (~gagan@125.62.105.4) |
| 17:08.02 | *** join/#brlcad kimzzzz (~AndChat31@1.38.31.154) |
| 17:09.15 | *** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net) |
| 18:06.33 | brlcad | Izak_: what do you need? |
| 18:06.51 | brlcad | it gave you a line number and there should be a stack trace saved in that log file |
| 18:07.27 | brlcad | that's a memory validation error, one of the *_CK_*() checks to make sure something is properly initialized is failing, saying it's zero (i.e, unset) |
| 19:12.39 | *** join/#brlcad AndChat|317009 (~AndChat31@1.38.31.154) |
| 19:15.24 | Ch3ck_ | runs home |
| 19:57.01 | *** join/#brlcad mpictor (~mark@c-67-177-102-131.hsd1.in.comcast.net) |
| 20:01.08 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 20:05.46 | brlcad | mpictor: since you apparently already have it set up somewhere, how might I entice you to run stack on brl-cad ? :) |
| 20:06.47 | brlcad | i've kicked it on three systems now and they all have a problem .. need to install llvm from scratch so I can compile stack cleanly, unfortunately not in a ports repository anywhere |
| 20:11.31 | mpictor | brlcad: can I wait until winter? Then I can turn my furnace off for a few days while my computer heats the place :P |
| 20:12.23 | mpictor | do you think it needs llvm at runtime? If not, I could send you a tarball |
| 20:16.54 | mpictor | If I can force it to only run on some cores, I guess I can let it run in the background for a few days |
| 20:30.41 | mpictor | ls |
| 20:30.44 | mpictor | ack |
| 20:33.31 | mpictor | brlcad: ldd shows no dependencies on llvm, so it ought to work if I tar it up |
| 20:34.17 | mpictor | first, I'll see if I'm using a debug build or an optimized build |
| 20:52.17 | Notify | 03BRL-CAD:starseeker * 57691 (brlcad/trunk/src/librt/search.c brlcad/trunk/src/librt/search.h): OK, don't have the performance optimizations in yet but this looks like it gets -below working with the >=, <= and = optional addtions to limit returns. |
| 20:55.18 | *** join/#brlcad urubu (96a102c8@gateway/web/freenode/ip.150.161.2.200) |
| 21:15.02 | mpictor | brlcad: it *does* require llvm at runtime, unfortunately. I just updated to r57691 and started a build |
| 21:19.23 | urubu | hello. It is possible to use brl-cad to "dump" a set of mathematical formulas that represent an object? |
| 21:28.29 | brlcad | mpictor: no idea, willing to try a tarball |
| 21:29.08 | brlcad | ah, mpictor never mind -- see that you're running it .. awesome |
| 21:29.18 | brlcad | urubu: i'm not sure what that means |
| 21:30.15 | *** part/#brlcad Gaganjyot (~gagan@125.62.105.4) |
| 21:30.38 | mpictor | brlcad: if you do run it at some point, it's pretty easy to change bin/poptck to limit the number of cores used |
| 21:30.56 | brlcad | urubu: i mean, i get describing an object with formulas, but they are rarely sufficient for describing an object (and no we do not have a generalized primitive that takes arbitrary equations) |
| 21:31.40 | brlcad | mpictor: good to know |
| 21:35.42 | *** join/#brlcad urubu (96a102c8@gateway/web/freenode/ip.150.161.2.200) |
| 21:37.13 | brlcad | urubu: if you didn't get my reply, feel free to elaborate what you meant |
| 21:37.19 | Notify | 03BRL-CAD:brlcad * 57692 brlcad/trunk/NEWS: cliff improved the search command so that you can now specify >= <= and = depth options |
| 21:37.26 | brlcad | starseeker: is it only -below or doing -above and -depth too? |
| 21:37.33 | Notify | 03BRL-CAD:starseeker * 57693 brlcad/trunk/src/librt/search.c: Also get -above working with the >=, <= and = optional addtions to limit returns. |
| 21:37.38 | urubu | brlcad: hmm, okay. I was looking for examples/benchmarks to use in a project (volume computation with monte carlo). |
| 21:38.25 | brlcad | ooh, I get it now |
| 21:38.26 | starseeker | brlcad: -below and -above so far |
| 21:38.41 | starseeker | could do depth too... hadn't thought about it, but logical |
| 21:38.44 | starseeker | one sec... |
| 21:38.46 | urubu | I saw that is possible to calculate volume of objects with brl-cad |
| 21:38.46 | brlcad | starseeker: cool |
| 21:39.06 | brlcad | urubu: yes, the gqa/g_qa command is made for that (-Av option) |
| 21:39.23 | starseeker | needed a way to replace dbfind's trick of reporting combs that include a particular object |
| 21:39.35 | brlcad | if it's a really simple object, like a single sphere or box, the 'analyze' command will directly calculate many mathematical properties |
| 21:39.51 | urubu | so I thought that maybe it would be possible to convert an object to a set of mathematical constraints |
| 21:40.42 | brlcad | you're not really "converting" anything |
| 21:41.02 | starseeker | brlcad: urm. Should I replace -maxdepth and -mindepth with just -depth and the ><= logic? |
| 21:41.05 | brlcad | just evaluating/describing that intrinsic characteristic |
| 21:41.16 | starseeker | suppose I'd have to deprecate those other two options... |
| 21:41.34 | brlcad | starseeker: no, I'd match 'find' |
| 21:41.48 | brlcad | leverage the familiarity as much as possible |
| 21:42.08 | brlcad | it's got all three |
| 21:42.27 | Notify | 03BRL-CAD:starseeker * 57694 brlcad/trunk/doc/docbook/system/mann/en/search.xml: Add example using results from search with tcl, explain new path syntax. |
| 21:42.27 | urubu | yeah, "convert" is not the best word |
| 21:42.27 | starseeker | nods |
| 21:42.34 | urubu | anyway, thanks for the help |
| 21:42.37 | urubu | bye o/ |
| 21:42.40 | brlcad | urubu: cya |
| 21:43.23 | starseeker | ok, I'll add depth |
| 21:43.53 | brlcad | I'd try to support find's syntax exactly if possible first, just for usability |
| 21:44.02 | brlcad | then can be expanded with a more rich syntax too |
| 21:44.19 | brlcad | like "-depth 5" and "-depth >5" |
| 21:45.07 | brlcad | the latter is synonymous with -mindepth 6, I think |
| 21:45.40 | starseeker | sure - that's a little different than what I've done for above and below, since they don't require an argument, but if -depth can require an argument that'll work fine |
| 21:47.09 | brlcad | hm, manpage seems to indicate gnu find supports both, but unclear what -depth by itself means |
| 21:47.33 | starseeker | votes for requiring a numerical or inequality argument |
| 21:48.20 | brlcad | ahh, I see |
| 21:48.42 | brlcad | -d/-depth implies a depth-first traversal with bsd find, which gnu find ignores |
| 21:48.49 | brlcad | so yeah, no worries requiring it |
| 21:50.15 | brlcad | or something like that |
| 21:50.45 | starseeker | you're OK with doing something different in search with it? |
| 21:51.05 | starseeker | doesn't have the first idea how to do a depth-first search of our db hierarchy... |
| 21:51.44 | starseeker | nor any idea of when/why a user would want that... |
| 21:52.18 | brlcad | boolean evaluation is usually depth-first |
| 21:53.19 | brlcad | you traverse depth-first all the way to a leaf, get polys, come up, go down next path to leaf, get polys, come up, apply operator, etc |
| 21:53.44 | starseeker | oh, right - I guess we see that in the facetize output, don't we |
| 21:54.01 | brlcad | almost everything that calls db_walk_tree() |
| 21:54.15 | starseeker | forgot how much *fun* it is to add a new search option. *rolls up sleeves* |
| 21:54.29 | brlcad | just with no reg_start func |
| 21:56.07 | brlcad | looks like db_functree() is also a depth-first traversal |
| 21:56.41 | Notify | 03BRL-CAD:carlmoore * 57695 brlcad/trunk/src/conv/g-var.c: remove some unneeded braces and 1 'break'; implement h? |
| 21:56.55 | brlcad | and looks like db_preorder_traverse() is not |
| 21:57.31 | brlcad | db_walk_tree() depends on which callbacks are specified |
| 22:00.12 | brlcad | looks like db_recurse() also depends on callbacks |
| 22:17.56 | Notify | 03BRL-CAD:starseeker * 57696 (brlcad/trunk/src/librt/search.c brlcad/trunk/src/librt/search.h): Add a -depth option to search that supports ><= modifiers to a numerical depth. |
| 22:18.00 | starseeker | brlcad: there we go |
| 22:19.27 | brlcad | cool |
| 22:19.31 | brlcad | what's the syntax? |
| 22:20.03 | brlcad | -depth 4 -depth >4 -depth <4 -depth >=4 -depth <=4? |
| 22:22.08 | starseeker | yeah |
| 22:22.15 | Notify | 03BRL-CAD:starseeker * 57697 brlcad/trunk/src/librt/search.c: MUCH simpler way to do the min and max depth tests. |
| 22:22.20 | starseeker | -depth 0 wil lgive toplevel |
| 22:22.46 | starseeker | oh, -depth =4 will also work (just falls out from string handling) |
| 22:23.10 | brlcad | -depth ==4 too? :) |
| 22:23.16 | starseeker | -above and -below don't have the space, because they need to work without arguments |
| 22:23.19 | starseeker | uh... |
| 22:23.26 | brlcad | not needed, just wondering |
| 22:23.39 | starseeker | no, actually |
| 22:23.52 | starseeker | option parsing is too simple minded for that |
| 22:24.05 | brlcad | presumably then => and =< also will not work |
| 22:24.24 | starseeker | right |
| 22:24.55 | starseeker | we could make it work, would need to add more logic to the string_to_name_and_val function |
| 22:25.31 | starseeker | needs to update the man page first though :-) |
| 22:26.05 | starseeker | and make sure all the NEWS worth stuff is in - don't remember if the new path specifier modifier |
| 22:26.08 | starseeker | made it in |
| 22:30.50 | Notify | 03BRL-CAD:starseeker * 57698 brlcad/trunk/doc/docbook/system/mann/en/search.xml: Update search man page to document -depth |
| 22:35.23 | Notify | 03BRL-CAD:starseeker * 57699 brlcad/trunk/NEWS: Add the ability for either a generic toplevel search specifier or a specific object path supplied to the search command to specify it wishes to be treated as a 'flat' object - in other words, every object in the database (or, for specific objects, every object below that object) is added as a top level search starting point. |
| 22:37.48 | Notify | 03BRL-CAD:starseeker * 57700 brlcad/trunk/NEWS: Add a -depth command to search that allow specification of either absolute or relative depth limits. |
| 22:41.01 | Notify | 03BRL-CAD:starseeker * 57701 (brlcad/trunk/include/raytrace.h brlcad/trunk/src/librt/ls.c): Remove the additive version of the db_ls flags - per Sean's suggestion, keep the function logic simple and focused. |
| 22:41.29 | Notify | 03BRL-CAD:brlcad * 57702 brlcad/trunk/NEWS: (reword r56478 and expand name for post-processing) Cliff added -l option to comb command that 'lifts' the region flag to the top level (specified) comb and clears all region flags in the tree below that comb. Has some advanced features, like automatically wrapping regions that are used elsewhere in the .g file and referencing the comb created by the wrap, and refusing to |
| 22:41.31 | Notify | perform the operation if it cannot be done without changing assembly definitions used elsewhere in the tree (see the comb man page for examples.) |
| 22:41.49 | brlcad | notes search is not specific to mged |
| 22:41.53 | starseeker | brlcad: do you want me to yank the argv to dpv and vice versa functions until we've settled on their final form? |
| 22:41.59 | starseeker | er, right |
| 22:42.44 | starseeker | sorry, was distracted trying to distinguish the -depth option from the additons to -above and -below in the other NEWS item... hard to avoid being confusing in one line... |
| 22:42.48 | brlcad | yank? no, but I think the previous state you had them (before the argc/count additions) was better |
| 22:43.15 | starseeker | actually ended up not needing to convert an argv array in the end, so those functions actually aren't needed (yet) |
| 22:43.20 | brlcad | my point about NULL dp's was flawed |
| 22:43.32 | starseeker | O.o? |
| 22:43.56 | starseeker | I thought it made sense... |
| 22:44.06 | starseeker | a failed lookup would result in a NULL dp... |
| 22:44.54 | brlcad | 23:36 < brlcad> starseeker: and I think there's already a pattern there, we can and should always return a struct directory for each argv .. they just may be RT_DIR_PHONY_ADDR with zero len, but even that is still incredibly useful |
| 22:45.10 | starseeker | oh, gotcha |
| 22:45.13 | brlcad | it may result in a null lookup |
| 22:45.17 | brlcad | but that doesn't mean we return null |
| 22:45.31 | brlcad | could be pretty powerful actually |
| 22:45.31 | starseeker | sorry - brain trying to hold too much in too small a space today ;-) |
| 22:45.55 | starseeker | fishes out the old form from the commit history |
| 22:45.55 | brlcad | submit a list of names, get back a set of dps for them, fill in their details, write them to a db |
| 22:48.46 | starseeker | will stub back in the old form, but suggests we keep it out of raytrace.h for this release... |
| 23:08.04 | mpictor | wow, stack only took 46 minutes on brlcad! |
| 23:08.31 | mpictor | I wonder if the big generated files slowed it down on stepcode |
| 23:12.04 | mpictor | stack output here: http://pastebin.com/jc3B3G00 |
| 23:14.05 | mpictor | oh, I did rebuild it with -O3 -march=native instead of the default -O2 |
| 23:14.22 | mpictor | I'm sure that made some difference |