| 00:44.38 | CIA-48 | BRL-CAD: 03n_reed * r49211 10/brlcad/trunk/src/libbu/sscanf.c: s/bu_exit/bu_bomb; accept 0 as a valid width for string conversions |
| 08:41.27 | *** join/#brlcad ibot (~ibot@rikers.org) |
| 08:41.27 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.22.0 is forthcoming || fixing all our Coverity Scan Initiative defects |
| 08:45.58 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) |
| 09:37.19 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) |
| 09:58.41 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) |
| 10:20.46 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) |
| 10:21.30 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) |
| 10:26.29 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) |
| 10:39.05 | *** join/#brlcad hackrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) |
| 10:52.16 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) |
| 10:59.25 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) |
| 11:02.29 | *** join/#brlcad hackrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) |
| 11:20.43 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) |
| 11:43.53 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) |
| 11:55.18 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) |
| 12:11.01 | *** join/#brlcad juan_man (~quassel@unaffiliated/juanman) |
| 13:21.10 | CIA-48 | BRL-CAD: 03Sean 07http://brlcad.org * r3276 10/wiki/Help:Searching: Reverted edits by [[Special:Contributions/46.151.43.197|46.151.43.197]] ([[User talk:46.151.43.197|Talk]]); changed back to last version by [[User:Sean|Sean]] |
| 13:21.17 | CIA-48 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:46.151.43.197]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 13:43.37 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) |
| 13:47.53 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) |
| 16:35.18 | CIA-48 | BRL-CAD: 03starseeker * r49214 10/brlcad/trunk/src/other/re2c/README: |
| 16:35.18 | CIA-48 | BRL-CAD: If we're using the template for the re2c README file (maybe worthwhile, maybe |
| 16:35.18 | CIA-48 | BRL-CAD: not...) don't stash the generated output in the src tree. Would need a |
| 16:35.18 | CIA-48 | BRL-CAD: mechanism like that used for our INSTALL and configure scripts to make that work |
| 16:35.18 | CIA-48 | BRL-CAD: 'properly' |
| 16:38.53 | CIA-48 | BRL-CAD: 03starseeker * r49215 10/brlcad/trunk/src/other/libz/ (CMakeLists.txt zconf.h zconf.h.in): Enough of the zconf.h.in nonsense. We've already had to modify zlib anyway. |
| 16:40.00 | CIA-48 | BRL-CAD: 03starseeker * r49216 10/brlcad/trunk/src/other/libz.dist: sync libz.dist |
| 16:41.51 | CIA-48 | BRL-CAD: 03starseeker * r49217 10/brlcad/trunk/src/other/re2c.dist: sync re2c.dist |
| 16:54.46 | CIA-48 | BRL-CAD: 03starseeker * r49218 10/brlcad/trunk/ (8 files in 8 dirs): (log message trimmed) |
| 16:54.47 | CIA-48 | BRL-CAD: Make a stab at logic to clean out all files generated by CMake. This is |
| 16:54.47 | CIA-48 | BRL-CAD: currently a bit too aggressive in that it will completely nuke the bin, lib, and |
| 16:54.47 | CIA-48 | BRL-CAD: share output directories, but it's a step in the right direction and seems to be |
| 16:54.47 | CIA-48 | BRL-CAD: able to restore a checkout to clean status after an in-src-dir CMake configure |
| 16:54.47 | CIA-48 | BRL-CAD: (although that's only tested on one platform and isn't yet portable - assumes |
| 16:54.48 | CIA-48 | BRL-CAD: Makefiles, for example.) Not hooked into the build proper yet - it generates a |
| 16:55.40 | starseeker | that's getting closer to a "real" distclean ability, except for also nuking all the "final output" directories |
| 16:58.06 | starseeker | If most development work these days is taking place with CMake, we may want to consider removing the svn ignore property globally. |
| 16:58.37 | starseeker | for myself (most of the time) I want to know precisely what is in the source tree without ignoring anything |
| 17:02.00 | starseeker | brlcad: if you can take a look at that distclean attempt and let me know precisely how you want it to behave, I can give it a round of polishing, make it portable and hook it in |
| 17:03.39 | starseeker | I think that approach should be more robust than the Distclean.cmake approach, although it may require a bit more logic |
| 18:45.49 | brlcad | starseeker: that file wasn't intended to get you to spend time on a distclean impl.. :) |
| 19:07.43 | brlcad | there are some aspects to both approaches that will probably be desireable |
| 19:07.52 | brlcad | that, at least, is my at-a-glance understanding |
| 19:09.36 | brlcad | like the global list that gets appended to, just want to make sure the caller only has to specify items cmake doesn't already know about and doesn't duplicate what the clean rule already does |
| 19:11.18 | brlcad | the distclean shell script looks like the only/main turd that I'd do away with |
| 19:11.37 | brlcad | no big deal if you can't time the distclean |
| 19:30.58 | starseeker | the clean rule removes things generated by make, not things generated by CMake |
| 19:31.27 | starseeker | the distclean logic as defined is intended to remove things generated by CMake |
| 19:33.17 | starseeker | the distclean shell script is a temporary measure - eventually there will be a cmake_distclean.cmake file generated that will be invoked by a "make distclean" target |
| 19:34.33 | starseeker | was i wasn't sure of was whether you wanted me to be able to nuke the files in bin, lib, etc that are produced by CMake *without* removing the files coming from the actual build |
| 19:39.02 | brlcad | it's the latter I was referring to, nuking bin/lib/etc |
| 19:39.23 | brlcad | at most, it could inspect and, if empty, delete the dir in the distclean portion of the rule |
| 19:39.42 | brlcad | but not nuke it outright since that then makes lots of assumptions |
| 19:45.02 | brlcad | what's the cmake_distclean.cmake file for? seems unnecessarily complicated to have a distclean rule writing out anything |
| 19:45.40 | brlcad | just needs a list of things to delete, the most important ones being the ones it already knows about |
| 19:46.24 | brlcad | adding the extra files list ability for the caller becomes the secret sauce that should be sufficient (yet still simple) |
| 20:08.31 | starseeker | brlcad: I'll play with it a bit and run some tests |
| 20:08.46 | starseeker | what do you think about nuking the svn:ignore property? |
| 20:14.13 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) |
| 20:40.30 | brlcad | starseeker: not all of the svn:ignore files are build-system related, if I recall correctly |
| 20:40.46 | brlcad | so probably not at least without doing a review of what's there and why |
| 20:40.47 | starseeker | true - some of them relate to ignoring temporary files from editors |
| 20:41.11 | starseeker | prefers to know when editors are leaving turds behind too, but that's just me... |
| 20:41.13 | brlcad | right, I'm not sure there's any value seeing those listed |
| 20:42.05 | brlcad | I know very well what is left around .. but having svn tell me provides no useful information |
| 20:42.24 | starseeker | doesn't always know ;-) |
| 20:42.38 | brlcad | on the contrary, can dilute the listing, make it harder to see important files |
| 20:43.18 | starseeker | must be a workflow difference |
| 20:43.36 | starseeker | prefers to stay close to the svn tree state, doesn't leave modified or unknown files in the src tree much |
| 20:44.23 | brlcad | a little workflow, a little difference in tools perhaps, a little familiarity |
| 20:44.46 | brlcad | if I were working with xcode regularly, I wouldn't want the xcode build dirs listed for example |
| 20:44.56 | brlcad | they're always there |
| 20:45.10 | starseeker | why is why out-of-dir builds are good |
| 20:46.31 | brlcad | a benefit sure, but mostly a different case altogether |
| 20:47.22 | brlcad | just picked xcode out by example, could just as well be some other random ide that places information with the input/sources |
| 20:47.51 | starseeker | if the IDE is putting information in the source tree when the build is not taking place in-src, that's a bug in the IDE |
| 20:47.55 | brlcad | not uncommon to say the least, point is more just that there are *some* files that are of no value to have svn report |
| 20:48.35 | brlcad | i don't think that holds water -- you may be using an ide that has little or nothing to do with building |
| 20:48.52 | brlcad | a source indexing browser, for example |
| 20:48.57 | brlcad | for code reviews |
| 20:49.07 | brlcad | nothing to do with any concept of a build dir |
| 20:49.24 | starseeker | hmm. OK, I suppose... |
| 20:53.01 | starseeker | would probably try to set that up such that the index file(s) were stored out of the src dir, but that's admittedly not something to expect from most devs |
| 20:53.42 | brlcad | if that's supported by the tool |
| 20:54.40 | brlcad | i've used several indexers over the years that would write an index for each directory containing sources |
| 20:55.05 | starseeker | nods. If it weren't I'd set up two copies of the src tree, but your point remains - it's a situation that is a reasonable argument for retaining at least some use of svn:ignore |
| 20:55.15 | brlcad | good ol' ctags comes to mind, though now there's an output option |
| 20:55.50 | brlcad | still even if you wrote to some other dir, then you loose the nifty automatic integration that you'd get in vim, ex, emacs, etc |
| 20:56.25 | brlcad | since they defaulted to the source dir too, and you'd have to tell it (hopefully it has a way) about that random other place |
| 20:57.56 | starseeker | nods - yeah, I'd probably end up having a separate copy of the src for that |
| 20:58.16 | brlcad | it all boils down to usability (and maintainability) since that's really the only reason svn:ignore exists |
| 20:58.48 | brlcad | maintainence cost is practically nil now that build dir is a separate concept |
| 20:59.20 | brlcad | usability of having vs not having entries for items of no value to "svn status" is then pretty simple |
| 20:59.23 | starseeker | nods - the main annoyance from my standpoint is when we ignore things like Makefile files, .tcl files, etc |
| 21:00.11 | brlcad | sure, those items could get yanked |
| 21:00.15 | starseeker | but a comprehensive selective review to get rid of just those would be a bit time consuming (unless it's scriptable in some fashion) |
| 21:02.24 | brlcad | *shrug* maybe an hour or two at best.. it's under 200 props |
| 21:02.59 | starseeker | ok - s/time consuming/mind numbing ;-) |
| 21:04.06 | brlcad | with a workflow going, it'd probably be about 30s per prop, a lil over an hour |
| 21:04.38 | brlcad | I find those are great tasks to do while watching movies :) |
| 21:07.34 | brlcad | 200 "files" is nothing ... |
| 21:07.46 | starseeker | heh |
| 21:07.48 | brlcad | I've done a half-dozen refactorings in the last 12 months alone that involved 1000+ file edits each (all unautomatable, hand edits) :) |
| 21:08.17 | brlcad | one category of new build warning hits more files than that :) |
| 21:11.22 | brlcad | I find it starts to get numbing when you can't get through the whole list in a single day |
| 21:11.37 | brlcad | 12 hours or less ftw .. if it's gonna take more, that's a real chore |
| 21:11.49 | starseeker | envies brlcad's threshold of boredom |
| 21:12.37 | brlcad | it's reading code, that can be very rewarding in itself |
| 21:13.48 | brlcad | when I was just starting to make my way through brl-cad years ago, I found that to be one of the best and absolutely fastest ways to become familiarized with what's there |
| 21:14.52 | brlcad | you start to see the bigger picture of how to restructure, where there are weaknesses, good and bad practices, and more... |
| 21:16.26 | brlcad | "oh yeah .. there's already a tool that does that" |
| 21:17.03 | CIA-48 | BRL-CAD: 03bob1961 * r49219 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl ArcherCore.tcl): Added a preference for display lists. |
| 22:03.07 | brlcad | n_reed: if I've been following the commits, it looks like you've included functionality akin to ms's sscanf_s()? |
| 22:08.41 | CIA-48 | BRL-CAD: 03starseeker * r49220 10/brlcad/trunk/ (11 files in 11 dirs): |
| 22:08.41 | CIA-48 | BRL-CAD: Getting closer - this leaves bin, lib and share in place but they should be |
| 22:08.41 | CIA-48 | BRL-CAD: nothing but a collection of empty directories for a bare configure. Just need |
| 22:08.41 | CIA-48 | BRL-CAD: to teach distclean to check them for empty dirs and recursively remove any empty |
| 22:08.41 | CIA-48 | BRL-CAD: dirs until we've whittled it down to the minimum (for a pure configure with no |
| 22:08.42 | CIA-48 | BRL-CAD: build step on a clean checkout, back to the checkout configuration.) |
| 22:13.04 | brlcad | starseeker: very minor, but can it be aware of only the dirs it adds? |
| 22:13.18 | brlcad | so it only potentially deletes ones it added, not just empty ones |
| 22:13.26 | starseeker | urm... |
| 22:13.39 | brlcad | in case someone happens to mkdir lib/whatever for example .. |
| 22:13.51 | brlcad | minor and no big deal if it can't |
| 22:14.25 | starseeker | tricky - if it's putting a file into a deep dir location, it will automatically create all the dirs it needs to get it there (iirc) |
| 22:15.24 | starseeker | I might be able to get it to track all that - I have to do something similar for distcheck... |
| 22:16.13 | brlcad | like I said, VERY minor .. just wondering really |
| 22:16.17 | starseeker | but if it does that and half the dirs listed in the path are already present and half aren't, that could get really tricky |
| 22:16.27 | starseeker | in principle - maybe |
| 22:16.36 | starseeker | but probably too hard to justify at this point |
| 22:16.53 | starseeker | let me get a "make distcheck" target working first |
| 22:17.02 | starseeker | I should be fairly close now |
| 22:17.19 | brlcad | as long as it's only removing empty dirs recursively, probably no harm |
| 22:17.34 | n_reed | brlcad: wasn't referencing sscanf_s, but similar in requiring width for %s and %[...]. |
| 22:17.44 | starseeker | that's the last trick - how to get it to do the directory removal |
| 22:17.56 | starseeker | I have a few ideas, but need to do some experimentation |
| 22:18.36 | brlcad | n_reed: what is the width for a %s defined as? |
| 22:18.54 | brlcad | does it include / require space for the null? |
| 22:19.39 | starseeker | brlcad: should the "make distclean" target perform the make clean step too? or just remove the files CMake is responsible for? |
| 22:20.20 | brlcad | following traditional distclean, yeah -- it should perform make clean (first) |
| 22:20.50 | brlcad | could separate into a makeclean and distclean rule |
| 22:21.41 | starseeker | ah, nuts - there's a gotcha - when I remove the CMakeFiles directories, I'm removing all the object files too |
| 22:22.16 | starseeker | is that acceptable, or should I try to introspect into those and leave the .o files? |
| 22:23.00 | brlcad | cmake made them and filled them, so it should be fine to just remove them .. but then the clean rule already does that, no? |
| 22:23.18 | brlcad | if so, then distclean can just check if dir is empty, remove |
| 22:24.29 | brlcad | that'd probably be safer |
| 22:24.38 | starseeker | I'll check - I was under the impression just the .o files are removed... |
| 22:25.29 | starseeker | if we're always doing clean with distclean it won't matter, but if we want a "cmake-clean" rule that just removes CMake's output it get dicey |
| 22:26.52 | brlcad | right, clean just removes the .o, so distclean itself won't have to |
| 22:27.13 | brlcad | it just checks the dir |
| 22:29.07 | starseeker | (right now) distclean is removing the whole CMakeFiles directory and all its contents - CMakeFiles directories hold more files generated by CMake |
| 22:29.10 | brlcad | cmake-clean would be introducing a different naming scheme, "cmakeclean" or "buildclean" would be more apropros |
| 22:29.19 | brlcad | where distclean=clean+cmakeclean |
| 22:29.40 | starseeker | or maybe configureclean |
| 22:30.03 | brlcad | configclean? |
| 22:30.14 | brlcad | buildsysteminfrastructureclean ;) |
| 22:30.37 | starseeker | yeah, we may have to live with configclean nuking the individual object files, unless we want to get smarter about the structure contained in that directory |
| 22:31.18 | brlcad | probably fine |
| 22:31.54 | starseeker | If a configclean is performed, everything's getting rebuilt anyway because all the Makefiles will be newer than the object files anyway |
| 22:32.11 | brlcad | the install dirs are where things get more interesting, or even the top-level build dir probably being the most common case |
| 22:32.38 | brlcad | where someone just has datafiles and/or source snippets being run against uninstalled bin/* tools |
| 22:33.16 | starseeker | uh... I'm not doing anything with the install dirs - am I supposed to? |
| 22:33.18 | brlcad | configclean would end up nuking the Makefiles, no? |
| 22:33.24 | starseeker | yep |
| 22:34.15 | brlcad | once you run even a partial distclean (assuming it gets past the "clean" phase and is working on the "configclean" phase), it's a point of no return |
| 22:34.23 | starseeker | yep |
| 22:34.26 | brlcad | you have to run cmake again |
| 22:34.35 | starseeker | just like Autotools, iirc |
| 22:34.38 | brlcad | yep |
| 22:34.41 | starseeker | (kinda in the nature of a distclean) |
| 22:34.56 | n_reed | brlcad: %1s means read 1 char max from input; dest string must be at least 2 chars |
| 22:35.01 | n_reed | is there something i need to fix? |
| 22:35.50 | starseeker | configclean would actually have fairly minimal utility, except possibly in debugging scenarioes |
| 22:36.58 | starseeker | wonders if there is even a equalivent to "make clean" in MSVC... |
| 22:37.16 | brlcad | n_reed: just thinking aloud, the reason why strlcpy exists when there was a strncpy a decade preceding is due to that size parameter |
| 22:37.29 | brlcad | off-by-one errors due to usability weakness |
| 22:39.00 | brlcad | I don't think it matters for the %#s case since that (to me) clearly implies number of chars and the #+1 == '\0' seems evident |
| 22:39.33 | brlcad | it may matter more for size parameters, I think, ala sscanf_s |
| 22:39.41 | brlcad | do you have size parameters? |
| 22:40.04 | brlcad | bu_sscanf("%s", my_string, size) |
| 22:40.15 | brlcad | or did you stick with sscanf's sig |
| 22:40.15 | n_reed | nope |
| 22:40.34 | brlcad | okay, so you're just requiring that if there's an %s that there must be a %###s in there? |
| 22:42.46 | n_reed | yes. %Vs %Vc %V[...] can handle cases where size is only known at run-time |
| 22:43.34 | brlcad | V is for vls? |
| 22:43.43 | n_reed | yes |
| 22:44.03 | brlcad | interesting, that's somewhat opposite bu_log()'s meaning |
| 22:44.44 | n_reed | you can pick any letter you want |
| 22:45.21 | brlcad | V isn't a width specifier to bu_log(), it's the type (ala %s) |
| 22:45.27 | brlcad | that's all |
| 22:45.34 | brlcad | not sure that it's a problem or not, just interesting |
| 22:45.54 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) |
| 22:46.19 | brlcad | so then it handles the unknown "size" by reading into an unsized/unbounded vls |
| 22:46.53 | brlcad | %Vc means what then? a double-byte char gets stored into a vls as two bytes? |
| 22:49.23 | n_reed | only tested with ordinary chars. now code always truncates vls then uses bu_vls_putc |
| 22:49.33 | CIA-48 | BRL-CAD: 03brlcad * r49221 10/brlcad/trunk/src/libged/get_comb.c: a benefit of using BU_VLS_INIT_ZERO instead of bu_vls_init() is that the compiler can actually detect an unused vls such as this one |
| 22:49.51 | n_reed | %Vc would copy one char and you'd have a '\0' after it still, unlike %c |
| 22:50.03 | brlcad | ah, okay |
| 22:50.14 | brlcad | why truncate? |
| 22:50.32 | brlcad | seems you could preserve the read-one-char behavior while ensuring null termination |
| 22:51.52 | brlcad | so you could do something like while(bu_sscanf(input, "%Vc", &myvls))) ; to read from input one char at a time into myvls |
| 22:53.42 | brlcad | probably doesn't matter since it'd be a dumb thing to do, but I think it's something you can effectively set up with sscanf() if you're going for parity |
| 22:56.10 | CIA-48 | BRL-CAD: 03brlcad * r49222 10/brlcad/trunk/src/shapes/coil.c: conversion to using BU_VLS_INIT_ZERO instead of bu_vls_init() where there's simple local use. detected another unused vls (coil_type). |
| 22:56.36 | n_reed | not sure I understand. I thought always overwriting vls would be best keeping with sscanf semantics. |
| 22:57.05 | n_reed | if you want to append a char at a time, just use %c and concat yourself |
| 23:00.34 | brlcad | right, but that's partially my point :) |
| 23:01.16 | brlcad | that would take a few lines of code, so making the semantic meaning append-char-to-vls would turn two steps into one |
| 23:01.52 | brlcad | whereas for the truncate case, where's the use case where using a vls saves someone a step over %c to a char |
| 23:02.24 | brlcad | could be one, haven't thought it through that exhaustively |
| 23:04.09 | brlcad | could be my own bias too .. I'm maybe envisioning something I'd expect from %*V and %1V |
| 23:36.32 | n_reed | i don't think |
| 23:37.41 | n_reed | i can't think of that many good use cases either way; simple enough to change it to append |