| 00:32.55 | *** join/#brlcad IriX64 (n=IriX64@bas2-sudbury98-1128564968.dsl.bell.ca) | |
| 03:14.05 | *** join/#brlcad IriX64 (n=mariodot@bas2-sudbury98-1128564968.dsl.bell.ca) | |
| 03:54.55 | *** join/#brlcad madant (n=d@117.196.135.231) | |
| 05:21.55 | *** join/#brlcad jdoliner (n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) | |
| 06:01.14 | *** join/#brlcad IriX64 (n=IriX64@bas2-sudbury98-1128564968.dsl.bell.ca) | |
| 07:25.15 | *** join/#brlcad _clock_ (n=_sushi_@84-72-91-14.dclient.hispeed.ch) | |
| 08:12.31 | *** join/#brlcad madant_ (n=d@117.196.131.167) | |
| 09:21.57 | *** join/#brlcad mafm (n=mafm@199.Red-88-26-141.staticIP.rima-tde.net) | |
| 12:16.56 | *** join/#brlcad madant (n=d@117.196.135.130) | |
| 12:58.59 | *** join/#brlcad madant (n=d@117.196.136.141) | |
| 13:09.21 | brlcad | starseeker: only the basics, nice relatively quiet town, especially towards the north end (but not too close to NP) |
| 13:11.39 | brlcad | ow...seriously need to tag and release asap |
| 13:45.32 | ``Erik | and migrate to the new machine *cough* O:-) |
| 13:46.51 | *** join/#brlcad jdoliner (n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) | |
| 13:48.33 | jdoliner | sean if you don't like the idea of a VCROSS_INIT macro |
| 13:48.48 | jdoliner | can I just make an INIT macro |
| 13:49.00 | ``Erik | why not just make 2 lines? |
| 13:49.07 | jdoliner | that just sets a vector up to initialize another macro |
| 13:49.29 | jdoliner | I guess I just have a compulsion to save it because I have to do it so many times |
| 13:50.18 | jdoliner | like the lines required for the macro will be much few than how many I need to make every initilization to a cross two lines instead of one |
| 13:54.59 | ``Erik | mebbe do it at the top of your cxx file? |
| 13:55.26 | ``Erik | doesn't think it warrants modifying a core header like vmath.h :) |
| 13:56.26 | indianlarry | jdoliner: hey joe it was my call on the INIT macro but most here are in agreement |
| 13:57.25 | jdoliner | okay, two lines it is ;-) |
| 14:30.12 | brlcad | jdoliner: consistency is king |
| 14:30.15 | brlcad | general practice in C is towards static initialization on declaration, which contrasts with the more natural dynamic init you often find with C++ |
| 14:30.58 | jdoliner | i see, that would explain my compulsion |
| 14:31.03 | brlcad | so pretty common to find separation between decl and init, and in this specific situation even, it'd still be preferred |
| 14:31.08 | jdoliner | I'm a C programmer at heart :) |
| 14:32.45 | brlcad | particularly with really old compilers, but even with modern ones, you can get some craptastic behavior during the dynamic init when there is a memory problem with the stack frame being close |
| 14:33.37 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-203.sbndin.btas.verizon.net) | |
| 14:34.01 | brlcad | the bigger issue in terms of maintainability is what indianlarry mentioned about pretty much then needing a similar init function for every macro, which would be ineffective to maintain |
| 14:34.44 | brlcad | there would also be code consistency problems with some code using the init calls, most not -- it expands the API with non-functional additions of logic/complexity |
| 14:35.16 | jdoliner | I see |
| 14:35.23 | brlcad | also, you might not have covered in classes yet, but your VZERO macro is just wrong :) |
| 14:35.44 | ``Erik | on two counts |
| 14:36.56 | ``Erik | (floating point fuzz and the 'z' argument is mucked) |
| 14:37.40 | jdoliner | yeah there's the typo whoops |
| 14:38.10 | jdoliner | in breplicator.c we use all of the equality functions with tolerances of 0.0 |
| 14:38.17 | jdoliner | does that create similar problems? |
| 14:38.29 | ``Erik | for fuzz, yes |
| 14:38.50 | ``Erik | try using FLT_EPSILON or DBL_EPSILON or something to compare |
| 14:39.14 | ``Erik | if ( fabs(x) < DBL_EPSILON ) instead of if ( x == 0.0 ) |
| 14:40.26 | jdoliner | I've actually left tol open to be passed down by higher functions |
| 14:40.32 | jdoliner | by just using the VNEAR_ZERO macro |
| 14:40.38 | jdoliner | do you think that's a good idea? |
| 14:47.08 | ``Erik | shells in and kill -9's indianlarry's irc process because he's thinking too hard about that book he's writing :> |
| 14:47.26 | indianlarry | your call joe - if the usage doesn't require the DBL_EPSILON and is something that may change across invocations then pass in from higher |
| 14:48.13 | jdoliner | hmm |
| 14:50.33 | jdoliner | yeah at least for lower level stuff that's going to be called in a number of different places I want them passed down |
| 14:51.13 | indianlarry | erik suggest checking tolerance passed in to make sure not less than DBL_EPSILON ... |
| 14:53.36 | jdoliner | yeah that makes sense |
| 14:53.36 | jdoliner | also you probably already saw this but in case you didn't I submitted a revised patch :) |
| 14:54.40 | brlcad | instead of using *_EPSILON, vmath abstracts out two tolerance types if you basically want/need hardware limit (whatever that may be) and not application limited |
| 14:54.54 | brlcad | unitize tolerance and division tolerance |
| 14:55.39 | brlcad | division tolerance is generally the hardware's ability to differentiate two fastf_t values (i.e., DBL_EPSILON) |
| 15:00.57 | brlcad | unitize tolerance is a couple orders higher as the minimum delta required to distinguish two vectors (you naturally lose a lot of precision after the sqrt and multiplies) |
| 15:05.58 | brlcad | jdoliner: also more specific to your two patch files, when you respond to comments with an update, you can delete/replace the existing files with a new one |
| 15:06.45 | brlcad | we might have to iterate a couple times just to make sure we discuss all the issues (there are still a variety of minor whitespace, indentation, comment, footer issues to sort out) |
| 15:30.06 | *** join/#brlcad madant (n=d@117.196.134.22) | |
| 16:22.22 | *** join/#brlcad elena (n=elena@89.136.118.141) | |
| 16:30.19 | starseeker | hey elena |
| 16:30.57 | elena | hi starseeker. |
| 16:31.23 | elena | :) |
| 16:33.58 | starseeker | elena: oh, ment to ask - where's your wiki page or whatnot with your daily work log? |
| 16:34.25 | starseeker | makes note to make irc logs searchable... |
| 16:34.54 | elena | wiki is here http://brlcad.org/wiki/User:EBautu |
| 16:35.15 | elena | should I keep a daily log? |
| 16:39.33 | starseeker | yep |
| 16:39.44 | elena | ok. i'll start one. |
| 16:40.02 | elena | should it be on the that wiki page or in someplace else? |
| 16:40.11 | starseeker | wiki is fine |
| 16:40.24 | elena | perfect :) |
| 16:40.25 | starseeker | doesn't need to be long, just a note on what was done each workday |
| 16:40.41 | elena | ok. sure. |
| 16:41.44 | elena | may I start it tomorow? today I've been all day at a conference and didn't get much done. |
| 16:43.51 | starseeker | ok. |
| 16:43.57 | elena | thank you. |
| 16:44.01 | starseeker | need to keep up with it though |
| 16:44.11 | elena | ok. i will. |
| 16:52.57 | *** join/#brlcad madant_ (n=d@117.196.134.35) | |
| 17:04.26 | *** join/#brlcad docelic (n=docelic@78.134.195.193) | |
| 17:17.42 | *** join/#brlcad madant (n=d@117.196.132.238) | |
| 17:25.02 | jdoliner | where are unit tests located? |
| 17:29.28 | starseeker | unit tests? you mean what units a database is using? |
| 17:35.44 | jdoliner | no, I mean like do you have one place where you keep all of the tests for different pieces of code |
| 17:35.51 | CIA-28 | BRL-CAD: 03starseeker * r34725 10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: Add mechanism to do corner evals for nurbs solving only when the ray is 'close' to parallel with the surface normal plane - still need to base 'close' on some function of the flatness criteria. |
| 18:02.01 | starseeker | jdoliner: we don't have a unit test framework as such |
| 18:02.17 | jdoliner | i see |
| 18:02.21 | jdoliner | when you say as such |
| 18:02.35 | jdoliner | is there some sort of equivalent thing? |
| 18:05.17 | starseeker | it depends - there are regression tests for various bits of functionality |
| 18:05.46 | starseeker | but no function level testing in the "unit test framework" sense |
| 18:06.30 | starseeker | I've had discussions with other team members about it in the past, but the consensus is it would involve a HUGE amount of work for fairly minimal gain, at least at this point |
| 18:08.44 | ``Erik | there are a couple small ad hoc tests when a piece of code becomes prone to issues, but we mostly rely on large integration tests (namely our benchmark pixcmp stuff) |
| 18:09.07 | ``Erik | but, for example, libbu has 'htester' |
| 18:09.17 | jdoliner | yeah I guess to make comprehensive tests for such a large project would take forever and we know it works |
| 18:09.19 | jdoliner | I see |
| 18:09.30 | jdoliner | well I'm writing some tests right now |
| 18:09.59 | jdoliner | and I was asking because I would have included them in the framework |
| 18:10.50 | starseeker | np - just keep them in with your code, keep them organzied, and comment them out when you're "done" with that part of the code |
| 18:11.41 | ``Erik | if it helps, you could make an executable with them as an explicit target? *shrug* |
| 18:14.08 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-203.sbndin.btas.verizon.net) | |
| 18:21.25 | jdoliner | Erik: yeah I'm doing it as a seperate executable |
| 18:21.25 | jdoliner | but I should include the tests? |
| 18:58.02 | CIA-28 | BRL-CAD: 03bob1961 * r34726 10/brlcad/trunk/src/libged/find.c: Modified ged_find_ref (i.e. added a space after appending name to ged_result_str). |
| 19:03.27 | *** join/#brlcad jdoliner (n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) | |
| 19:46.00 | brlcad | jdoliner: there are system, regression, and integration tests in the regress/ directory -- the issue with unit tests is another case of maintainability |
| 19:46.17 | brlcad | unit tests are relatively high-maintenance (compared to other types of tests like integration tests) |
| 19:48.43 | jdoliner | sry what do you mean by integration tests? |
| 19:49.21 | brlcad | not to mention the sheer size of writing unit tests for a 1M sized codebase .. one that has complete coverage, that's another massive project in itself, and one that increases the code complexity (anything changed requires changing it at least twice) causing change resistance or tests that fall out of sync |
| 19:49.41 | brlcad | http://en.wikipedia.org/wiki/Integration_testing |
| 19:50.48 | brlcad | instead of testing whether routing foo_blah() computes a foo and returns 0 for A and non-0 for B inputs, you test whether the pix-png conversion tool (which hypothetically uses foo_blah()) actually works for a given set of "high-level" tests |
| 19:51.34 | brlcad | s/routing/routine/ |
| 19:52.38 | jdoliner | okay I understand |
| 19:54.10 | brlcad | regression, system, and integration tests are (much) lower maintenance than unit tests as they should only fail on select user-visible changes, not any API change (which is good and bad, but overall good in terms of effectiveness) |
| 19:55.02 | jdoliner | right actually I think my project lends itself pretty well to integrative tests |
| 19:55.05 | jdoliner | overall |
| 19:55.15 | jdoliner | but while I make it I still of course have to test module by module |
| 19:55.36 | brlcad | yeah.. you're quite welcome to write tests for your code, especially throughout your development |
| 19:55.57 | brlcad | I almost always write test harness applications when writing new API routines like you're doing regardless |
| 19:57.13 | brlcad | if the test harness is "useful" by the time i'm done, it gets added in somewhere .. but more often than not, it's just development throw-away code that wouldn't add value even if it had full-coverage on that snippet |
| 19:57.52 | brlcad | so just use your judgement, or commit if unsure (easy to remove later) :) |
| 19:58.36 | jdoliner | will do |
| 19:58.47 | jdoliner | have you taken a look at my most recent patch? |
| 19:59.08 | brlcad | jdoliner: remember to focus on cleaning up that patch first though -- getting commit sorted out is more important than getting the code implemented right now |
| 19:59.35 | jdoliner | I'm actually unclear right now what still needs to be cleaned up in it still |
| 19:59.37 | brlcad | i hadn't, was hoping indianlarry would take a stab at it first ;) |
| 19:59.46 | jdoliner | ok cool |
| 19:59.48 | jdoliner | I'm sure he will |
| 20:01.27 | brlcad | looking now |
| 20:01.46 | brlcad | okay several minor points at a glance |
| 20:02.29 | brlcad | all files should have our standard header and footer -- you added the footer but not the header |
| 20:02.41 | brlcad | there are scripts in sh/ for adding header/footer or both (template) |
| 20:03.25 | brlcad | another, consistency point on comment style, include a space after your *'s in comments /* like this */ and /*not like this*/ |
| 20:03.50 | *** join/#brlcad madant (n=d@117.196.128.159) | |
| 20:04.06 | brlcad | if you have a blocking editor like emacs, vi, studio, etc, you should be able to auto-indent paragraphs (column 70) |
| 20:09.17 | *** join/#brlcad andax (n=andax__@d213-102-40-182.cust.tele2.ch) | |
| 20:09.20 | brlcad | pretty minor, but else should be on the } line, not after |
| 20:12.05 | brlcad | ah, yes -- your indent whitespace also is inconsistent with our HACKING guidelines -- what editor are you using? |
| 20:12.53 | jdoliner | vim |
| 20:12.57 | brlcad | space between ){ |
| 20:13.28 | brlcad | so there's a setting in vim you can enable and it'll auto-configure itself based on the comment footer |
| 20:13.30 | jdoliner | should an else if be on the } line too? |
| 20:13.44 | jdoliner | oh please tell me that command |
| 20:13.49 | brlcad | I forget the exact magic keystroke incantations, maybe erik knows |
| 20:13.58 | brlcad | yes, } else { |
| 20:14.26 | jdoliner | "} else if {" too? |
| 20:14.35 | brlcad | it's standard K&R / Stroustrup style |
| 20:14.39 | brlcad | yes |
| 20:16.15 | brlcad | the HACKING file talks about most of this with some examples, so please do read it in full (and *not* just skim it) |
| 20:17.57 | brlcad | the style plays heavily into the consistency and maintainability of the code you add, so it's more about uniformity across the source code |
| 20:18.31 | brlcad | not N styles from N contributors, regardless of personal preferences or familiarity, for better or worse -- changes to style are intentional amongst the group (and applied across the entire code) |
| 20:19.22 | brlcad | there's actually a long-standing effort to continually clean up the inconsistencies that exist, but as mentioned in the guide, it's not an excuse for new code and not an excuse to not make the existing code consistent ;) |
| 20:23.15 | brlcad | looks like that covers it for the patch, the only other thing noticed would be for authorship/contact info to move to the AUTHORS file instead of per-source. files are invariably multi-authored if they survive any useful length of time -- the docs provide credit better |
| 20:38.53 | *** join/#brlcad jdoliner1 (n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) | |
| 21:01.26 | jdoliner1 | I don't see what's inconsistent about my indent whitespace |
| 21:01.37 | jdoliner1 | should it be exanded to spaces? |
| 21:11.22 | brlcad | no.. |
| 21:11.32 | brlcad | did you read HACKInG? |
| 21:11.47 | jdoliner1 | yes many times |
| 21:12.03 | jdoliner1 | and it really seems like its right |
| 21:12.04 | brlcad | and, then in the section on whitespace |
| 21:12.22 | jdoliner1 | but maybe im missing something obvious |
| 21:12.23 | brlcad | Indents are 4 characters, tabs are 8 characters. |
| 21:12.48 | brlcad | which for vi is what the "ex: shiftwidth=4 tabstop=8" declaration means |
| 21:12.56 | brlcad | that's a "vi-line" |
| 21:13.06 | brlcad | equivalent to "vi: shiftwidth=4 tabstop=8" |
| 21:13.46 | brlcad | means first indent is 4 chars, second is a tab, third is a tab+4chars, fourth is 2tabs, etc |
| 21:14.22 | brlcad | if you set those two vi variables, it should indent correctly |
| 21:15.32 | jdoliner1 | i'm was pretty sure that's what I set them too... |
| 21:23.27 | jdoliner1 | okay I think I got everything |
| 21:23.35 | jdoliner1 | **crosses fingers |
| 23:10.50 | *** join/#brlcad samrose (n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) | |