| 00:00.20 | starseeker | anyhow, enough for 1 day |
| 00:00.23 | starseeker | packs it in |
| 00:06.33 | *** join/#brlcad gcibot (~gcibot@unaffiliated/ignaciouy/bot/gcibot) | |
| 00:38.40 | Notify | 03BRL-CAD Wiki:Tbrowder * 6424 /wiki/Main_page: /* Tutorials */ |
| 00:48.07 | *** join/#brlcad KimK (~Kim__@ip24-255-223-153.ks.ks.cox.net) | |
| 01:05.41 | *** join/#brlcad FreezingAlt (~FreezingC@135.0.41.14) | |
| 01:37.46 | Notify | 03BRL-CAD Wiki:Sean * 6425 /wiki/Main_page: dev topic, belongs in dev doc section |
| 02:07.44 | brlcad | ``Erik: guess what I got up and running? |
| 02:07.58 | brlcad | (assuming you didn't see my earlier note) |
| 02:09.01 | brlcad | starseeker: we detect it in a couple places, but I don't know of an API means to detect it |
| 02:10.52 | brlcad | about all I recall on the topic is that it is intentionally not prevented, long time since I've thought about a cyclic DAG |
| 02:11.27 | brlcad | (it isn't prevente, but it IS a modeling error) |
| 02:16.01 | Notify | 03BRL-CAD:brlcad * 59769 brlcad/trunk/src/rt/opt.c: instead of introducing another _WIN32 that breaks regression, pull it down to where it's used. |
| 02:32.52 | Notify | 03BRL-CAD:brlcad * 59770 brlcad/trunk/src/libbu/tests/test_funcs.c: stdio.h isn't needed when we include bio.h, but bio does belong up with the system headers as a convenience wrapper. |
| 02:51.39 | Notify | 03BRL-CAD:brlcad * 59771 (brlcad/trunk/src/liboptical/sh_stxt.c brlcad/trunk/src/liboptical/sh_text.c and 3 others): prefer API simplicity over an inconsequential division instruction reduction since there are no other pertinent, preventive, or semantic benefits and it's an odd one-off API symbol |
| 03:09.26 | starseeker | brlcad: problem for me is it can result in an infinite loop in search |
| 03:09.49 | starseeker | was hoping there was an easy way to spot the issue... |
| 03:10.09 | Notify | 03BRL-CAD:brlcad * 59772 brlcad/trunk/src/liboptical/sh_text.c: division is not associative, wrap in parens |
| 03:11.47 | starseeker | there is _db_detect_cycle, but it's not public |
| 03:12.19 | starseeker | should I just duplicate the logic? |
| 03:12.26 | starseeker | pretty simple, actually... |
| 03:13.27 | starseeker | or could make a public function and have _db_detect_cycle call it... |
| 03:18.41 | Notify | 03BRL-CAD:brlcad * 59773 brlcad/trunk/src/liboptical/sh_wood.c: another BN_INV255 going bye bye |
| 03:24.41 | Notify | 03BRL-CAD:brlcad * 59774 brlcad/trunk/include/bn.h: remove the BN_INV255 symbol from bn API as it was the sole remaining global conversion that got preserved (and wasn't a math constant). serves no useful purpose so prefer API simplicity. |
| 03:24.47 | brlcad | starseeker: ditto for a number of other commands too |
| 03:25.31 | brlcad | heh .. you didn't just ask if you should duplicate logic....... |
| 03:28.26 | Notify | 03BRL-CAD:brlcad * 59775 brlcad/trunk/CHANGES: no more bn_inv255/BN_INV255, unnecessary |
| 03:31.31 | starseeker | brlcad: it's a dinky little function to make a public API out of |
| 03:31.57 | starseeker | plus, to *really* do a general function, it should do a full inspection of the path |
| 03:32.14 | starseeker | or maybe allow the user to specify how far back from the end... |
| 03:32.14 | starseeker | hmm |
| 03:38.42 | Notify | 03BRL-CAD:starseeker * 59776 brlcad/trunk/src/librt/search.c: This fixes the infinite loop in search on cyclic paths - need to make the cycle detection into a librt function. |
| 03:41.30 | brlcad | starseeker: the fact that the same logic is needed in two places means "it's now time to refactor" |
| 03:42.07 | starseeker | brlcad: it just seemed like something that would have been needed in a large number of places a long time ago, if cyclic paths are allowed... |
| 03:42.25 | starseeker | suggesting there was some reason it hadn't already been attended to ;-) |
| 03:42.34 | starseeker | no matter - give me a few minutes |
| 03:42.40 | starseeker | this shouldn't be too hard |
| 03:42.57 | brlcad | not preventing != allowed |
| 03:43.37 | brlcad | you're not prevented from shooting yourself ... doesn't mean it's allowed |
| 03:43.40 | starseeker | <snort> fair enough, but if the *can* exist then we should be making sure they don't turn into poison pills... |
| 03:44.28 | starseeker | can I delete all these D B _ F U L L _ P A T H... strings in the header? |
| 03:44.48 | starseeker | thought he recalled you saying they were out in the headers but not the C files... |
| 03:45.44 | brlcad | the spaced out titles can be eliminated |
| 03:45.50 | starseeker | huzza |
| 03:46.01 | brlcad | they're not supposed to reside in headers either |
| 03:47.47 | brlcad | starseeker: note that you can avoid publishing it as public API, just expose a common function and put it in librt_private.h |
| 03:48.06 | brlcad | just without rt_ or db_ or similar public api prefix |
| 03:48.16 | starseeker | brlcad: sure, if only librt ever cares |
| 03:48.20 | brlcad | right |
| 03:48.33 | starseeker | wouldn't libged, mged, etc. have a potential interest in that question? |
| 03:48.35 | brlcad | the time something outside needs it, it'll be time to sort out the public API |
| 03:48.44 | brlcad | don't know that |
| 03:49.01 | brlcad | could be the case that it's really the rt_/db_ functions that always need to check so it's never an issue |
| 03:49.11 | starseeker | nods |
| 03:49.24 | brlcad | would need a case |
| 03:50.06 | starseeker | would think Archer's tree display would like to know... |
| 03:50.16 | brlcad | wouldn't expose it on hypothetical alone, we can expand/publish as needed without issue so long as the visibility is as constrained as possible |
| 03:51.20 | brlcad | sure, but still would it be a db_detect_cycles function or even something like it? I'd guess probably not |
| 03:53.58 | brlcad | e.g., you'd probably want to do more than boolean detect, for example, you'd want a list of paths where a cycle exists, or a list of object names that begin a cycle, or ... who knows what else |
| 03:57.32 | brlcad | really looks like db_cyclic_path() should get merged with _db_detect_cycle() (probably shouldn't have that prefix too) |
| 03:58.11 | starseeker | yeah, I know they should be merged - just didn't want to scrap the change when it did fix the bug |
| 03:58.39 | starseeker | is working on it - I'll put it in the private header to start |
| 03:58.49 | brlcad | coo |
| 03:58.56 | brlcad | so you actually encountered one? |
| 03:59.03 | brlcad | or created one to test? |
| 03:59.06 | starseeker | wonders if there are any tree walking operations where we *don't* want to make that check? |
| 03:59.09 | starseeker | made one by accident |
| 03:59.15 | brlcad | ahh |
| 03:59.28 | starseeker | was making screwy combs to test the assembly checking logic, and *kaboom* |
| 03:59.36 | starseeker | hellow infinite loop |
| 04:02.39 | Notify | 03BRL-CAD:starseeker * 59777 brlcad/trunk/include/raytrace.h: Remove some of the spaced-out names in raytrace.h - this isn't all of them. Deliberately left some where there was no other comment as an indication that we should add something, but even without those still plenty to go. |
| 04:02.49 | brlcad | it's not our "new era" methodology, but the old mantra was you make that kind of mistake, you deal with it ;) |
| 04:02.59 | starseeker | heh |
| 04:03.00 | brlcad | you want to shoot yourself, that's your business |
| 04:03.12 | starseeker | oddly enough, I *am* dealing with it :-P |
| 04:03.16 | brlcad | whether by accident or not, no coddling |
| 04:08.14 | brlcad | starseeker: if you want a fun exercise, you could try to automate the elimination of the S P A C E D out names and the blank line that follows in comments |
| 04:09.11 | starseeker | nods - I know I should script it. Just got into a vim cycle of removing them "just one more..." |
| 04:09.53 | brlcad | can probably do it with one regex |
| 04:09.55 | starseeker | is it a good rule of thumb that all public API functions should have some sort of explanatory comment? |
| 04:10.07 | starseeker | shudders at the mere mention of regex... |
| 04:10.22 | brlcad | names will have at least three chars if not many more |
| 04:10.37 | brlcad | that's what makes it a great (learning) exercise |
| 04:10.58 | starseeker | would rather merge the cycle tests ;-) |
| 04:11.00 | brlcad | not really that hard, you just need to look up how to do a multiline match, then find your pattern |
| 04:11.05 | brlcad | heh |
| 04:11.10 | brlcad | just a suggestion |
| 04:11.29 | brlcad | would have made a good gci task |
| 04:11.34 | brlcad | simple enough |
| 04:12.10 | starseeker | has occasionally done regexes of that type - it's how I invented Yapp's First Law of Regex Expressions - There are ALWAYS untended consequences when doing regex matches |
| 04:12.32 | starseeker | s/untended/unintended |
| 04:12.40 | brlcad | that just means you haven't done enough of them to think through all the cases! |
| 04:12.40 | starseeker | apparently can't code and talk at the same time... |
| 04:13.10 | brlcad | it's a good assumption to make regardless, but it does get easier |
| 04:16.31 | starseeker | "if shooting your foot still hurts, it just means you haven't done it enough!" |
| 04:17.22 | starseeker | knows brlcad is right, but still has a hunch he needed to be exposed to some fundamental "prepare the brain for regexes" program at age 3 and wasn't.. |
| 04:17.32 | starseeker | even pointers aren't as bad |
| 04:18.14 | Notify | 03BRL-CAD:brlcad * 59778 brlcad/trunk/src/sig/d2-c.c: this is why bio.h exists |
| 04:32.10 | Notify | 03BRL-CAD:starseeker * 59779 (brlcad/trunk/src/librt/db_fullpath.c brlcad/trunk/src/librt/db_tree.c and 2 others): Consolidate the cyclic tests |
| 04:37.11 | Notify | 03BRL-CAD:starseeker * 59780 brlcad/trunk/src/librt/search.c: Go ahead and return the cyclic path itself - it's the traversal that's the problem. |
| 07:01.37 | brlcad | couldn't resist after talking about it |
| 07:04.56 | Notify | 03BRL-CAD:brlcad * 59781 (brlcad/trunk/doc/html/ReleaseNotes/email3.0.html brlcad/trunk/doc/html/ReleaseNotes/email4.0.html and 457 others): Eliminate our historic F U N C _ H E A D E R S in comments. They're a development nuisance with a maintenance cost and their original purpose is no longer relevant. There's no longer a need to distinguish public API comments from implementation function comments since all API |
| 07:04.57 | Notify | comments are getting migrated to the include/ directory. Moreovere, we have automatic tools (e.g., Doxygen) that can stylize and headerize automatically.Done with two easy one-liners:find . -type f \( -not -regex '.*other.*' -not -regex '.*svn.*' \) -exec perl -0777 -pi -e 's/ \*[[:space:]]*([[:alnum:]_] )+[[:alnum:]_]([[:space:]]*\([[:space:]]*\))*(\n \*[[:space:]]*)*\n//g' {} \;find . -type f \( -not -regex |
| 07:05.00 | Notify | '.*other.*' -not -regex '.*svn.*' \) -exec perl -0777 -pi -e 's/\/\*+[[:space:]]*(\n[[:space:]]*\*[[:space:]]*)*\n[[:space:]]*\*\/[[:space:]]*\n//g' {} \;5900 lines eliminated including empty comment blocks. |
| 07:09.48 | brlcad | took about 15 minutes to write them, and an hour to review them |
| 07:50.55 | *** join/#brlcad ARNOLD-TELECOM (~ARNOLD-TE@195.24.220.134) | |
| 07:51.15 | ARNOLD-TELECOM | hi Ch3ck |
| 07:51.28 | ARNOLD-TELECOM | help |
| 07:52.54 | ARNOLD-TELECOM | -? |
| 07:53.12 | ARNOLD-TELECOM | --help |
| 07:54.05 | *** join/#brlcad ARNOLD-TELECOM (~ARNOLD-TE@195.24.220.134) | |
| 07:55.39 | ARNOLD-TELECOM | whois ChanServ |
| 08:02.16 | *** join/#brlcad ARNOLD-TELECOM_ (~ARNOLD-TE@195.24.220.134) | |
| 08:02.20 | *** join/#brlcad Anaphaxet0n (~george@unaffiliated/anaphaxeton) | |
| 08:02.51 | *** join/#brlcad kesha (~kesha@14.139.122.114) | |
| 09:03.29 | *** join/#brlcad gaganjyot (~gagan@124.253.224.225) | |
| 09:28.49 | *** join/#brlcad merzo (~merzo@user-94-45-58-138-1.skif.com.ua) | |
| 09:40.04 | *** join/#brlcad gaganjyot (~gagan@124.253.225.115) | |
| 09:48.26 | *** join/#brlcad Anaphaxeton (~george@unaffiliated/anaphaxeton) | |
| 10:00.52 | *** join/#brlcad Anaphaxeton (~george@unaffiliated/anaphaxeton) | |
| 11:03.43 | *** join/#brlcad zxq9 (~ceverett@FL9-125-199-207-150.okn.mesh.ad.jp) | |
| 11:06.54 | *** join/#brlcad Ch3ck (~Ch3ck@195.24.220.134) | |
| 11:13.14 | *** join/#brlcad merzo (~merzo@user-94-45-58-138-1.skif.com.ua) | |
| 11:33.34 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 11:50.53 | *** join/#brlcad KimK (~Kim__@ip24-255-223-153.ks.ks.cox.net) | |
| 12:02.52 | *** join/#brlcad kesha (~kesha@14.139.122.114) | |
| 12:05.59 | *** join/#brlcad caen23 (~caen23@92.81.213.198) | |
| 12:10.47 | ``Erik | brlcad: ? |
| 12:30.08 | starseeker | brlcad: this word "easy" - I don't think it means what you think it means :-P |
| 12:30.18 | starseeker | nice little line count reduction |
| 12:57.50 | starseeker | we are keeping the spaced-out file name at the top of the headers? |
| 12:59.36 | starseeker | brlcad: while I'm thinking about it, you have mentioned in the past an interest in breaking the large headers in include up into smaller headers (which are then presumably #included back into the parent file for compatiblity) |
| 13:00.11 | starseeker | what would be the scheme you would use to structure that? include/librt/*.h and friends? |
| 13:00.31 | starseeker | (or include/raytrace/*.h I suppose...) |
| 13:05.55 | brlcad | ``Erik: ? |
| 13:06.50 | starseeker | I think he's asking about your "guess what I got working" remark earlier? |
| 13:06.52 | brlcad | starseeker: heh, well it's really not that complicated |
| 13:07.09 | brlcad | it's just a shorthand notation for a very very simple program |
| 13:07.35 | brlcad | especially if you eliminate all of the character classes (the [:whatever:] bit) |
| 13:08.12 | brlcad | s/eliminate/reduce/ |
| 13:09.18 | ``Erik | brlcad: you got something running? |
| 13:09.25 | brlcad | ah yes .. yes I did :) |
| 13:09.43 | brlcad | it's about the size of a breadbox |
| 13:09.47 | brlcad | it's blue |
| 13:09.55 | ``Erik | oh, the o2? |
| 13:09.58 | brlcad | yup |
| 13:10.02 | ``Erik | saw something about that a few days ago |
| 13:10.07 | brlcad | took a bit to figure out how to root it |
| 13:10.16 | brlcad | none of the old roots worked |
| 13:10.26 | ``Erik | heh, running irix 7.something from 1998? :D |
| 13:10.51 | brlcad | 7?? |
| 13:10.58 | brlcad | what is this mythical beast you speak of? |
| 13:11.02 | brlcad | it's an old 6.5 |
| 13:11.06 | ``Erik | ah |
| 13:11.20 | ``Erik | 6.5.30 was the last release in '06 |
| 13:11.32 | ``Erik | was never much of an irix guy, was more at home with solaris |
| 13:11.32 | brlcad | yeah |
| 13:12.07 | ``Erik | but the o2 was an absolutely brilliant bookend, good weight, solid rubber feet, visually pleasing shape |
| 13:12.08 | brlcad | it was frozen in time, circa 2002 |
| 13:12.33 | brlcad | it's up and running and have been slowly making progress on a compile all week |
| 13:12.44 | ``Erik | (and, um, the o2 creator and the o3, iirc, minor updates with color changes) |
| 13:12.52 | brlcad | has cad 6.0 installed already |
| 13:13.02 | ``Erik | cool, did a cmake work, or still auto? |
| 13:13.15 | brlcad | cmake worked without fuss |
| 13:13.29 | brlcad | biggest issues so far are C++-related |
| 13:13.34 | ``Erik | swank |
| 13:14.03 | brlcad | put mipspro on halt after it had no stl to work with |
| 13:14.18 | brlcad | but then the gcc installed is 2.95 so it's all kinds of special too |
| 13:14.52 | ``Erik | um, iirc, sgi put out stl as an optional add-on (in the late 90's, it was common for msvc users to grab the sgi stl, because it was the least bad out there) |
| 13:14.54 | brlcad | just burnt a 3.3 and stl to put on there for next week, but it will mean starting over |
| 13:15.11 | brlcad | nods, got that |
| 13:15.22 | brlcad | their stl used to be my go-to stl documentation (sometimes still is) |
| 13:15.43 | brlcad | I made a wget copy of their site years ago when the company started crumbling |
| 13:15.58 | brlcad | fortunately haven't needed to use it |
| 13:16.25 | ``Erik | heh, "hey, I'm a new ceo! forget this mips crap, the money is in nt! let's make a basic NT workstation and try selling it for 10x everyone elses rate! it'll be awesome!" *cough* |
| 13:16.39 | brlcad | yeah.. |
| 13:18.22 | ``Erik | the mips isa was awesome, did some asm using 'spim' http://pages.cs.wisc.edu/~larus/spim.html back in college, soooo much nicer than x86 |
| 13:19.29 | starseeker | leaves off on yet another API reduction re-design of the db_search stuff to emissions test a car... |
| 13:19.31 | ``Erik | aaaanyway, as neat as the o2 is, not sure the time wouldn't be better spent bumping from c90 to c99 or updating to tcl 86 |
| 13:27.47 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 13:45.27 | brlcad | ``Erik: this isn't just for fun, I'm evaluating where our performance stands compared to where it was a decade before |
| 13:45.53 | brlcad | to see if we're significantly faster or slower |
| 14:56.47 | ``Erik | no old #'s for something like xon/xoff to do an easier comparison? :) |
| 14:58.35 | ``Erik | I kinda feel compelled to point out that using a different compiler can yeild radically different performance profiles, 2.95 was very micro-optimized for x86, 3 was significantly slower code, but by 3.4, it was tromping 2.95 on x86 as well as other platforms... :) |
| 14:59.06 | ``Erik | (and the 2.95 egcs branch was even crazier) |
| 15:03.19 | *** join/#brlcad kesha (~kesha@14.139.122.114) | |
| 15:24.35 | *** join/#brlcad gaganjyot (~gagan@124.253.225.70) | |
| 16:34.29 | *** join/#brlcad gaganjyot (~gagan@124.253.225.70) | |
| 17:12.27 | *** join/#brlcad gaganjyot (~gagan@124.253.225.70) | |
| 17:16.51 | *** join/#brlcad javampire (~ncsaba@p4FF7294D.dip0.t-ipconnect.de) | |
| 17:38.53 | javampire | kanzure: I have some questions regarding python-brlcad... |
| 18:10.20 | *** join/#brlcad kesha (~kesha@14.139.122.114) | |
| 18:34.20 | kanzure | javampire: sup |
| 18:35.53 | javampire | kanzure: first I would like to ask if you had any reason to use '_bindings' instead of just 'bindings' ? |
| 18:36.35 | javampire | the '_' suggests it's a private package, but it's actually not, applications will need to use it |
| 18:36.59 | kanzure | in python _ just means "please pretend it is private" |
| 18:37.06 | kanzure | i don't see why applications would need to use it |
| 18:37.18 | kanzure | supposedly python-brlcad would wrap _bindings into something else that would be consumable by humans |
| 18:37.35 | javampire | aha, now that's a good reason :-) |
| 18:38.25 | javampire | but for the moment that's unfortunately not true, and I think it will take quite some time to get there... |
| 18:38.52 | kanzure | which application needs to access brlcad._bindings? |
| 18:39.21 | javampire | anyway, I tried to silence my IDEs warnings by adding those packages directly under the "brlcad" package, but I will revert that then |
| 18:39.44 | kanzure | i recommend not using an IDE because it complicates things |
| 18:39.53 | kanzure | but i wont insist.. |
| 18:40.16 | javampire | well I have different experience with IDEs, for now it helps me do things faster |
| 18:40.38 | javampire | I also have quite extensive experience using IntelliJ, and Pycharm is just it's python variant |
| 18:41.38 | javampire | it's warnings did actually help me find quite some bugs |
| 18:42.31 | javampire | OK, the "_" question is answered with that, thanks |
| 18:42.48 | javampire | I have another one related to building combinations |
| 18:42.50 | kanzure | are you still manually testing by reinstalling the package? |
| 18:42.59 | kanzure | let me see what i can do about this |
| 18:43.08 | javampire | well it's not a big deal |
| 18:43.21 | kanzure | it is :) |
| 18:43.27 | javampire | I run the "setup.py", takes a few seconds :-) |
| 18:43.33 | javampire | what can be done about it ? |
| 18:43.42 | kanzure | installing the python package is secondary from testing the binding generation stuff |
| 18:43.51 | kanzure | well it's important to have a separation of concerns |
| 18:44.00 | javampire | well binding generation is working now, I don't need to test it |
| 18:44.11 | kanzure | updating bindings shouldn't require a programmer to know anything about python packaging magic (which, by the way, is universally terrible and awful) |
| 18:44.21 | kanzure | (except maybe for wheels, but i haven't looked into this much) |
| 18:44.55 | kanzure | ctypesgen.txt seems weird- what is this |
| 18:45.04 | javampire | well the bindings are re-generated only because the wrapper package is the same as the bindings package |
| 18:45.29 | javampire | ah, that one was only to record my finding about the ctypes-gen bug |
| 18:45.49 | kanzure | you could just submit changes upstream to https://github.com/kanzure/ctypesgen and then we bump the dependency/version in requirements.txt |
| 18:46.27 | javampire | ctypes-gen can wrongly include some unsupported typedefs if there are circular dependencies |
| 18:46.53 | javampire | but once the "no-python-types" option is set to False, that won't affect anymore python-brlcad |
| 18:46.57 | kanzure | what is the difference between test/ and tests/ |
| 18:48.03 | javampire | tests is the unit tests created by you, test is the one created by me with some scripts I check for running at all |
| 18:48.11 | javampire | and I used for debugging |
| 18:48.24 | kanzure | yes but what is the actual difference |
| 18:48.32 | kanzure | like why should there be two? |
| 18:48.46 | javampire | once things stabilize, it can be either moved to tests as unit tests, or just dropped altogether, or perhaps moved to the examples |
| 18:49.08 | javampire | unit tests are simple things which test one element |
| 18:49.20 | javampire | the tests has a full round-trip |
| 18:49.43 | javampire | I mean the test/test_wdb.py for example |
| 18:50.37 | javampire | everything is mostly work in progress for the moment, I experiment a lot |
| 18:50.57 | javampire | but yes, i'm glad for any questions/comments ! |
| 18:51.56 | javampire | before I will go ahead with implementing more primitive wrappers, I want to get combination read/write working well, because the actual details there can influence how the rest needs to be implemented |
| 18:53.28 | javampire | when creating a combination a tree of boolean operations will need to be created |
| 18:54.22 | javampire | that can be done in many ways, but I would prefer to use expressions involving primitive instances connected by properly overloaded operators |
| 18:55.04 | javampire | and the actual question is: do you have preferences for which operators to assign to which boolean operation |
| 18:56.47 | javampire | if I would use the operators overloaded by set operations in python, it would mean: '|' -> union; '&' -> intersection; '-' -> difference; '^' -> xor |
| 19:20.11 | brlcad | ``Erik: yep, that's why recompiling 6.0 is already in order, but the existing install still gives me a known baseline |
| 19:20.37 | brlcad | compiling 6.0 should be a snap |
| 19:30.58 | Notify | 03BRL-CAD:brlcad * 59782 (brlcad/trunk/doc/html/ReleaseNotes/email4.0.html brlcad/trunk/include/bn.h and 82 others): eliminate some more of the decorated t i t l e outliers that were inconsistent with the majority, ones on the main line or single line. |
| 19:47.19 | Notify | 03BRL-CAD:brlcad * 59783 brlcad/trunk/src/conv/conv-vg2g.c: omg, don't be so f-ing bossy and condescending |
| 19:49.51 | Notify | 03BRL-CAD:brlcad * 59784 (brlcad/trunk/src/conv/comgeom/f2a.c brlcad/trunk/src/conv/conv-vg2g.c): ws, style cleanup |
| 19:51.05 | Notify | 03BRL-CAD:brlcad * 59785 brlcad/trunk/src/conv/conv-vg2g.c: mat_pr is unused, remove |
| 19:52.40 | Notify | 03BRL-CAD:brlcad * 59786 brlcad/trunk/src/conv/conv-vg2g.c: eliminate globals |
| 20:31.55 | *** join/#brlcad Anaphaxeton (~george@unaffiliated/anaphaxeton) | |
| 20:58.42 | kanzure | javampire: i probably prefer written out operators, as methods/functions like union, difference, intersect, etc.. |
| 20:59.05 | javampire | yes, that will be provided too |
| 21:00.05 | javampire | look at the unit test I added for "combination", something similar will be supported |
| 21:01.14 | javampire | but I would also add some overloaded operators too, in some occasions that could look better |
| 21:01.28 | javampire | at least the '-' for subtraction is looking much better |
| 21:02.02 | Notify | 03BRL-CAD:brlcad * 59787 (brlcad/trunk/include/bn.h brlcad/trunk/include/nmg.h and 45 others): clean up the remainder of non-conformant comment header expansions, removed |
| 21:13.51 | *** join/#brlcad kesha (~kesha@14.139.122.114) | |
| 23:47.20 | Notify | 03BRL-CAD:tbrowder2 * 59788 (brlcad/trunk/include/bu.h brlcad/trunk/src/libbu/CMakeLists.txt and 3 others): move bit twiddle literals to a new, private header; rename with BU_ prefix |