| 00:05.28 | Notify | 03BRL-CAD:starseeker * 69053 (brlcad/trunk/src/librt/primitives/bspline/nurb_basis.c brlcad/trunk/src/librt/primitives/bspline/nurb_bezier.c and 21 others): Start backing down the include headers in the nurbs code. |
| 00:18.20 | Notify | 03BRL-CAD:starseeker * 69054 (brlcad/trunk/include/rt/nmg.h brlcad/trunk/src/librt/primitives/nmg/nmg.c brlcad/trunk/src/librt/primitives/nmg/nmg_plot.c): start pecking away at removing RT_ADD_VLIST from the nmg code. |
| 00:46.19 | Notify | 03BRL-CAD:brlcad * 69055 (brlcad/trunk/src/conv/jack/g-jack.c brlcad/trunk/src/conv/off/g-off.c brlcad/trunk/src/libged/draw.c): nmg_r_to_vlist() apparently needs a vlfree list now. lacking an alternative, passing the global. |
| 00:51.51 | Notify | 03BRL-CAD:brlcad * 69056 brlcad/trunk/src/proc-db/tea_nmg.c: nmg_m_to_vlist is taking vlfree list too |
| 00:53.37 | *** join/#brlcad rlahaeowhdtuemdl (~armin@dslb-092-074-236-082.092.074.pools.vodafone-ip.de) | |
| 06:54.07 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) | |
| 07:24.18 | *** join/#brlcad merzo (~merzo@91.217.179.122) | |
| 08:11.23 | *** join/#brlcad teepee] (bc5c2133@gateway/web/freenode/ip.188.92.33.51) | |
| 09:19.02 | *** join/#brlcad Caterpillar (~caterpill@unaffiliated/caterpillar) | |
| 11:17.17 | *** join/#brlcad Ch3ck (~Ch3ck@154.70.99.219) | |
| 12:57.50 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 13:32.06 | Notify | 03BRL-CAD:brlcad * 69057 brlcad/trunk/src/tab/CMakeLists.txt: don't emit warnings we can't do anything about |
| 13:46.33 | *** join/#brlcad yorik (~yorik@2804:431:f720:93f1:290:f5ff:fedc:3bb2) | |
| 13:52.11 | *** join/#brlcad kintel_ (~kintel@unaffiliated/kintel) | |
| 14:08.25 | starseeker | brlcad: thanks - forgot to do a full build before commit |
| 14:09.00 | brlcad | no worries, you fixed mine yesterday too ... and I DID do a full build before commit .. no idea how it passed |
| 14:09.49 | starseeker | I think I'm starting to get fairly close to ready for a libnmg split, once I get the rest of those RT_* macros |
| 14:10.07 | starseeker | I'm figuring that should probably be after 7.26.2 |
| 14:10.30 | starseeker | theoretically it could be done with minimal disruption, but in practice... |
| 14:10.47 | brlcad | nods, cool |
| 14:12.14 | starseeker | been looking into the stat stuff a bit - I'm having a hard time finding anything that indicates explicit attribute reporting via stat |
| 14:14.07 | starseeker | brlcad: oh, one though on the nmg vlfree refactor - do we need to construct regex expressions for all of those functions to append the RTG global in order to be minimally impacting? |
| 14:15.13 | starseeker | that'll be really nasty (worse since like an idiot I didn't always put the new vlfree parameter at the end of the function param lists) but I'm not sure how "public" we want to consider the nmg calls |
| 14:15.39 | *** join/#brlcad amarjeet (~amarjeet@169.149.170.121) | |
| 14:20.25 | brlcad | starseeker: I don't consider the nmg_ and rt_nmg_ to be documented public API |
| 14:20.45 | brlcad | other rt_* functions are a different story |
| 14:21.26 | brlcad | what stat stuff? |
| 14:42.55 | starseeker | we had decided to look into how BFS/HFS/etc. handled attribute reporting in their stat command |
| 14:43.35 | starseeker | for design discussions for the BRL-CAD stat functionality - wanted to dig that back out of the archives before it gets too hard to re-apply |
| 14:52.23 | *** join/#brlcad merzo (~merzo@93-195-113-92.pool.ukrtel.net) | |
| 14:56.09 | Notify | 03BRL-CAD:starseeker * 69058 (brlcad/trunk/include/rt/nmg.h brlcad/trunk/src/libged/draw.c and 4 others): Remove the rest of the RT_ADD_VLIST calls from nmg_plot |
| 14:56.18 | Notify | 03BRL-CAD:brlcad * 69059 brlcad/trunk/misc/CMake/BRLCAD_Targets.cmake: bit again. remove dead symlinks so removed/renamed files don't mess with the build (e.g., when a tclIndex needs to be regenerated). if it globs but doesn't exist, it's a dead link and useless in the build tree regardless. copies are left to fend for themselves (and don't exhibit the same problems). |
| 15:03.05 | brlcad | ahh, gotcha .. note that they don't call them attributes |
| 15:03.43 | brlcad | e.g., HFS calls them user defined flags |
| 15:04.19 | brlcad | quick look at man stat indicates they use stat -f "format" to get at them |
| 15:05.03 | brlcad | using a printf-style formatter with pre-defined awareness of some file properties |
| 15:05.18 | brlcad | looks like "ls -lO" will list them via ls |
| 15:06.17 | Notify | 03BRL-CAD:starseeker * 69060 brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c: Normally this isn't a good idea, but given how embedded rt_in_rpp is in the core shotlining logic we break the nmg/librt coupling here by making an nmg version of this function to minimize any unintended side effects of things like the previous attempt to move rt_in_rpp to libbg. Once libnmg is a separate library we can revisit this, |
| 15:06.19 | Notify | but for now go with the least risk minimal impact solution. |
| 15:06.21 | Notify | ... |
| 15:06.28 | brlcad | according to http://befs-driver.sourceforge.net/about.php, looks like be called them extended attributes |
| 15:06.46 | starseeker | ah, I see |
| 15:08.11 | starseeker | got distracted by statfs - pondering some ideas on treating full paths as statfs rather than stat calls... |
| 15:08.28 | brlcad | this looks like the haiku interface, https://www.haiku-os.org/docs/userguide/en/attributes.html |
| 15:08.33 | starseeker | brlcad: I've got a few design thoughts - should I jot them down for discussion next week? |
| 15:09.14 | starseeker | listattr... hmm |
| 15:10.02 | brlcad | according to https://api.haiku-os.org/fs__modules.html, their stat interface supports accessing attributes, but still digging to find something like a manual page |
| 15:10.26 | brlcad | yeah, their other useland tools are essentially our attr command |
| 15:10.41 | brlcad | mac hfs is similar with the chflags command |
| 15:11.15 | brlcad | starseeker: just curious, what was the problem moving rt_in_rpp to bg? |
| 15:11.44 | starseeker | brlcad: I just got jittery - didn't know what performance implications might be of moving that function call to another lib |
| 15:12.03 | starseeker | plus it's just so core to the librt shotlining logic I was reluctant to monkey with it |
| 15:12.14 | brlcad | performance wouldn't change simply by moving it |
| 15:12.27 | starseeker | the library change isn't an issue? |
| 15:12.36 | brlcad | why would it? |
| 15:12.39 | starseeker | thought he remembered you expressing concerns about that some years back... |
| 15:13.01 | brlcad | introducing a function call where one didn't exist or changing the function to generalize it |
| 15:13.19 | brlcad | those can have impact, in some rare cases |
| 15:13.38 | starseeker | ah. OK, perhaps I was mis-remembering |
| 15:14.39 | starseeker | brlcad: the bg breakout is in the history a few commits back - can resurrect that |
| 15:14.40 | brlcad | but simply moving a symbol _abc from libA to libB isn't going to change anything except the time to load appZ if it didn't previously rely on libB, and that would usually be measured in startup microseconds |
| 15:15.33 | brlcad | the bigger deal was introducing a new data type to libbg, the notion of a ray ... don't know if it already had/has that notion |
| 15:16.00 | starseeker | libbg doesn't have a lot yet - we haven't had the scoping discussion :-) |
| 15:16.34 | starseeker | 69060 should be fairly harmless - we can easly refactor from there to call a common function later once things are sorted |
| 15:17.03 | brlcad | a "half line" defined by a point and vector is almost certainly fair game imo, just good to consciously expand scope to include it if that's the direction it goes |
| 15:18.13 | starseeker | brlcad: I'm game either way - mostly just looking for the lowest impact way to break coupling at this point |
| 15:18.36 | brlcad | heck, I think even libbn might already introduce a ray, but that'd probably be something to weed out of bn and up into bg |
| 15:18.43 | starseeker | nods |
| 15:19.05 | starseeker | bn's got a number of things in it that should probably move up, imho... planes, for example |
| 15:19.41 | brlcad | we should itemize data types for the b* libraries |
| 15:19.55 | starseeker | nods |
| 15:19.57 | brlcad | I think that will greatly help define their scope and point out clear outlier scope violations |
| 15:20.24 | brlcad | good future agenda topic |
| 15:20.32 | starseeker | brlcad: in the short term, should I revert 69060 and go with the libbg breakout? |
| 15:20.33 | brlcad | after we get through the cmd listings |
| 15:20.39 | starseeker | grins - agreed |
| 15:21.41 | brlcad | whatever gets you there, don't see a problem eithe rway |
| 15:22.31 | starseeker | 69060 is simpler for now then - I'll add a comment as a reminder that we need to revisit it (and probably a lot of things in NMG, actually - polygon tessellation is one where I'm not sure if it should be in libnmg or libbg...) |
| 15:22.36 | brlcad | the intent of bg already included awareness of some basic shapes like sphere iirc, and a box (rpp) fits in that view too |
| 15:23.56 | brlcad | yeah, that gets into whether bg should include sets of things, which is what we need to sort through |
| 15:24.03 | brlcad | (polygons) |
| 15:25.16 | brlcad | if bg has sets of polygons, then that could potentially heavily overlap with nmg and be a mess to resolve |
| 15:25.47 | Notify | 03BRL-CAD:starseeker * 69061 brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c: We eventually need to decide how to merge rt_in_rpp and ray_in_rpp - add a comment so that is clear. Needs a bit of design work first so we know what the 'correct' solution will be - libbg, or something else... |
| 15:26.08 | starseeker | nods - the distinction would probably be connected edges (topology) vs bare polygons, but I don't know for sure if that's sensible |
| 15:26.19 | brlcad | good point, maybe |
| 15:27.08 | brlcad | except if you end up with a whole slew of the same functionality, and most can be implemented with/without topology (e.g., re-tessellation), that might still be a mess |
| 15:27.39 | starseeker | nods - the idea would be to have libnmg call libbg for anything that didn't require topology |
| 15:28.30 | starseeker | (say, libnmg would introduce shared points on edges to constrain a tessellation to mate up on edges, and then libbg would tessellate the individual faces as polygons |
| 15:28.56 | starseeker | that undercuts libnmg as a self contained stand-alone library though |
| 15:29.58 | starseeker | in that scenario, libnmg's primrary concern becomes the radial edge data structures and logic associated with those, with the "lower level" operations being passed down |
| 15:31.10 | brlcad | yeah |
| 15:31.22 | brlcad | if you always need both, then they probably belong together in some form |
| 15:31.49 | brlcad | if one often only needed one or the other, that would be good reason for separateion |
| 15:32.35 | brlcad | right now, we clearly have separation bot vs nmg and natural progression is a lib containing both sets |
| 15:32.53 | brlcad | rather a lib for each, or a lib with both |
| 15:36.14 | starseeker | noes |
| 15:36.18 | starseeker | nods even |
| 15:37.18 | starseeker | as long as we have both libnmg and openNURBS/libbrep, we'll have two separate users that will want tessellation |
| 15:38.45 | brlcad | is unable to find the haiku stat man page, sees if he has a disk image available |
| 15:39.43 | brlcad | decimation might be a better example for those too :) |
| 15:44.34 | starseeker | is checking the Haiku source tree - so far I can't find any man pages... |
| 15:46.02 | starseeker | hrm. https://www.haiku-os.org/community/forum/haiku_man_equivalent |
| 15:51.31 | starseeker | https://github.com/haiku/haiku/blob/b65adbdfbc322bb7d86d74049389c688e9962f15/src/system/libroot/posix/sys/stat.c |
| 15:53.23 | starseeker | ah: https://github.com/haiku/haiku/blob/master/headers/posix/sys/stat.h |
| 15:53.55 | brlcad | yeah, I already read the C api, it has hooks to the attribute data |
| 15:54.12 | brlcad | the question is how, if at all, this is exposed via the stat command-line tool |
| 15:59.46 | brlcad | okay, got haiku running -- it's just standard gnu coreutils stat, so they don't address it |
| 16:00.31 | starseeker | ok, that leaves OSX as the guide so far. ZFS was the other one I think? |
| 16:00.44 | starseeker | checks if FreeBSD has a ZFS aware stat... |
| 16:00.56 | brlcad | well haiku's guide is go with "attr" ;) |
| 16:01.03 | starseeker | heh |
| 16:02.13 | brlcad | looks like zfs calls them properties and provides an attr-style "zfs" command |
| 16:02.15 | brlcad | https://docs.oracle.com/cd/E18752_01/html/819-5461/gayns.html |
| 16:02.50 | brlcad | nice, they handle inheritance |
| 16:03.37 | starseeker | so now we have two areas of interest - stat, and what the varios OS attr commands do that ours doesn't ;-) |
| 16:05.28 | brlcad | http://stackoverflow.com/questions/27828585/posix-analog-of-coreutils-stat-command has good info, basically stat -f or -c |
| 16:05.59 | brlcad | or incorporate into ls and make scriptable |
| 16:06.45 | starseeker | kinda views ls as a bit "higher level", but that my just reflect the bias of my own usage patterns |
| 16:07.46 | starseeker | s/my/may |
| 16:08.43 | brlcad | looks like ext2/3/4 has lsattr/chattr, but don't allow user-defined attributes |
| 16:45.43 | brlcad | starseeker: the more I think about it, the more I'm convincing myself that stat/exists should get the axe |
| 16:46.14 | brlcad | there's so much overlap with several other commands that I have to imagine we can incorporate that shorthand easily into a command roadmap in some other way |
| 17:05.10 | starseeker | ok |
| 17:05.33 | starseeker | so for the short term should I just add a -size option to search? |
| 17:06.20 | starseeker | wanted some way to answer the question "what are the large objects in this .g" - that's what originally drove the stat command |
| 17:06.55 | starseeker | it's correlary would be nice too "how big is the keep of this object?" |
| 17:07.38 | starseeker | supposes an option to ls is a possiblity... |
| 18:37.39 | *** join/#brlcad amarjeet (~Amarjeet@169.149.150.129) | |
| 18:46.57 | *** join/#brlcad starseek1r (~starseeke@104.225.5.10) | |
| 18:55.11 | *** join/#brlcad ries (~ries@D979C7EF.cm-3-2d.dynamic.ziggo.nl) | |
| 18:56.43 | *** join/#brlcad LordOfBikes (~armin@dslb-092-074-236-082.092.074.pools.vodafone-ip.de) | |
| 18:59.08 | brlcad | starseek1r: I think all the standard 'find' options are fair game, which includes a -size option: http://pubs.opengroup.org/onlinepubs/009695399/utilities/find.html |
| 19:02.02 | brlcad | the only issue will be standardizing how to get at other "size" information since search should probably just report some standarzied notion of object size like the db5_raw_internal.object_length |
| 19:03.22 | brlcad | (course stat is that too, ls or summary would be good for higher-level constructs) |
| 19:27.01 | Notify | 03BRL-CAD:starseeker * 69062 brlcad/trunk/src/libbu/tests/bu_basename.c: There's no point in failing the bu_basename tests on a platform without its own basename. |
| 19:29.26 | Notify | 03BRL-CAD:brlcad * 69063 brlcad/trunk/src/libanalyze/CMakeLists.txt: ignore, but list the headers for distcheck |
| 19:29.55 | starseeker | brlcad: if we're ditching stat/exists, what did you have in mind as a replacement |
| 19:30.12 | starseeker | kinda liked the notion of the cad stat being analogous to the filesystem stat... |
| 19:30.41 | Notify | 03BRL-CAD:brlcad * 69064 brlcad/trunk/src/libanalyze/CMakeLists.txt: include the right relative path |
| 19:32.24 | brlcad | which problem / feature are we talking about? :) getting a list of the biggest objects would be well handled with ls -S and/or search -size options |
| 19:33.09 | brlcad | knowing, for example, which bot has the most triangles or which brep the most surfaces (or edges or vertices, etc) is more problematic |
| 19:34.49 | brlcad | original idea for 'exists' was a corollary to the 'test' built-in, not stat per se |
| 19:36.11 | starseeker | I guess I was thinking ahead to if we add timestamp info to objects |
| 19:36.36 | starseeker | and the printf-style reporting of stat had some possibilities for scripting reports of db info |
| 19:37.05 | starseeker | sure, I can see ditching exists |
| 19:39.04 | brlcad | find/ls both have timestamp options too :) |
| 19:39.08 | starseeker | brlcad: before we reject the idea of a stat command, can I write up my notions of what it would look like for discussion |
| 19:39.16 | brlcad | uses ls -lart all the time |
| 19:40.39 | starseeker | it may be that find/ls encompass everything we need, but I'd like to lay out the features I have in mind to make sure they will map |
| 19:40.58 | brlcad | sure, go for it |
| 19:41.35 | starseeker | cool - thanks. I'll try to do so in the next week or so |
| 19:41.50 | starseeker | scowls at the Windows unit test results |
| 19:42.02 | brlcad | note that this also doesn't preclude having stat in some other form, like if we retain a "db" command for lower-level database inspection, "db stat ..." might make sense |
| 19:42.12 | starseeker | ah |
| 19:42.23 | starseeker | that actually does make sense |
| 19:42.29 | brlcad | but I think we need a bigger picture view |
| 19:42.42 | starseeker | nods |
| 19:44.09 | starseeker | OK, after shutting up bu_basename, we've got 1 bu_bitv_master fail, 1 bu_booleanize_nullptr fail, 1 bu_progname_tests fail, 3 bu_vls_vprintf fails, 5 bn_list_2d fails and 5 bn_list_3d fails |
| 19:44.59 | brlcad | loves having the Blue Angels flying overhead while he works |
| 19:45.07 | starseeker | heh - cool :-) |
| 19:45.41 | brlcad | apparently my side street is directly on their flight path for several runs |
| 19:46.21 | brlcad | shutting up basename?? |
| 19:47.11 | brlcad | I just check regressions a day ago and was all passing |
| 19:47.42 | starseeker | not on Windows - no basename, no testie |
| 19:47.51 | brlcad | oooh, heh |
| 19:48.00 | starseeker | other failures are all Windows specific |
| 19:48.03 | brlcad | you're still worrying about that? :) |
| 19:48.29 | starseeker | what, unit testing on Windows? it's so close to working fully... |
| 19:48.30 | brlcad | good on you, Windows needs some love |
| 19:49.03 | starseeker | suspects all the bn_list failures are related... something about temp files, buffers, and fread unhappyness... |
| 19:49.17 | starseeker | need to step through it on Linux to figure what it is supposed to do... |
| 19:49.32 | brlcad | https://msdn.microsoft.com/en-us/library/e737s6tf.aspx |
| 19:49.48 | brlcad | (for basename testing if you want to get it working) |
| 19:50.43 | starseeker | blegh - figures there would be a solution |
| 19:50.53 | starseeker | makes a TODO note |
| 19:52.03 | brlcad | here's actual code, pretty trivial: https://github.com/fastbot3d/firmware/blob/master/pru_sw/utils/pasm_src/path_utils.c |
| 19:52.30 | Notify | 03BRL-CAD:starseeker * 69065 brlcad/trunk/src/libbu/tests/bu_basename.c: Note that there is a Windows system option that offers basename functionality we should use to test this with. |
| 19:52.56 | starseeker | hah, not bad |
| 19:52.57 | starseeker | thanks |
| 19:53.14 | brlcad | something like _makepath(base, NULL, NULL, path, ext); |
| 19:54.27 | brlcad | equiv to base = basename(path); |
| 19:55.15 | brlcad | ahh, just pass NULL for ext, not needed |
| 19:56.18 | brlcad | huh, never mind .. that example doesn't jive with the docs on quick look |
| 19:57.38 | starseeker | isn't splitpath what we want? |
| 19:58.07 | brlcad | yeah, think so |
| 19:59.06 | brlcad | that snippet intentionally uses both, just read it wrong |
| 19:59.34 | brlcad | split path gets fname and ext, then it's composed back into a filename with _makepath (into the "base" var) |
| 20:03.05 | Notify | 03BRL-CAD:starseeker * 69066 brlcad/trunk/CMakeLists.txt: Add test for _splitpath, which we will need on Windows to do basename testing. |
| 20:56.30 | Notify | 03BRL-CAD:brlcad * 69067 brlcad/trunk/regress/repository.sh: down to 194 |
| 20:56.44 | Notify | 03BRL-CAD:brlcad * 69068 (brlcad/trunk/src/libanalyze/MeshHealing/Geometry.cpp brlcad/trunk/src/libanalyze/MeshHealing/Geometry.h and 8 others): header cleanup, ensure common.h comes before all system headers. |
| 21:29.48 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 21:45.43 | *** join/#brlcad merzo_ (~merzo@93-195-113-92.pool.ukrtel.net) | |
| 22:05.38 | Notify | 03BRL-CAD:starseeker * 69069 brlcad/trunk/src/libbu/tests/bu_basename.c: Update bu_basename test to use a combination of compatibility wrapper logic and Windows APIs to emulate basename system functionality. |