| 01:30.19 | starseeker | ``Erik: the context for me is passing in an argv-style array as an argument to a function (an array of path names, specifically) - if I stipulate that the input has to be a null-terminated char ** array, I should be OK without needing an explicit path count variable in addition |
| 01:30.31 | starseeker | (unless I'm missing something - hence my question) |
| 01:41.51 | ``Erik | if this is for a libged func, I'd think you'd be ok... (mebbe use the argc as a sanity check?) |
| 02:49.29 | starseeker | ``Erik: actually, librt |
| 02:49.47 | starseeker | considering how to define a saner librt search API |
| 02:50.46 | starseeker | db_search(const char *plan, const char *paths[], <database stuff>) seemed intuitive |
| 02:52.31 | starseeker | considering whether to have multiple functions for different search types, or just add a flag to indicate search type and always return a bu_ptbl (with the type of the pointer in the table dependent on the type of search requested) |
| 02:53.13 | starseeker | so struct bu_ptbl * db_search(int search_type, const char *plan, const char *paths[], etc.) |
| 02:53.50 | starseeker | which could (I think) handle most scenarios |
| 02:57.09 | starseeker | current API for search evolved accidently while chopping up find code (Sean pointed out that everything shouldn't live in src/libged/search.c, and my first cut was... crude and quick.) |
| 02:57.53 | starseeker | trying to fix that now, since I'm actually starting to use the librt API for other commands (long been a goal, just hadn't come up until the comb options last week.) |
| 02:58.45 | starseeker | dbfind can go now (deprecated a while back) so also time to make sure search covers those features |
| 02:59.13 | starseeker | (or functionality at least - don't care much for how dbfind does output...) |
| 07:31.33 | *** join/#brlcad caen23 (~caen23@92.85.83.158) | |
| 09:52.57 | *** join/#brlcad Ch3ck_ (~Ch3ck@195.24.220.16) | |
| 10:37.23 | *** join/#brlcad caen23 (~caen23@92.85.83.158) | |
| 10:56.48 | *** join/#brlcad kesha (~kesha@14.139.122.114) | |
| 11:29.36 | *** join/#brlcad kesha (~kesha@14.139.122.114) | |
| 11:33.41 | kesha | tofu: did u give an application on behalf of BRL-CAD for doc camp ? |
| 11:34.04 | kesha | Deadline is approaching .. |
| 12:19.41 | Ch3ck_ | calm down... |
| 12:40.35 | *** join/#brlcad kesha (~kesha@14.139.122.114) | |
| 13:13.47 | *** join/#brlcad kesha (~kesha@14.139.122.114) | |
| 16:10.42 | Notify | 03BRL-CAD:brlcad * 56506 brlcad/trunk/src/libbn/tests/bn_poly_multiply.c: the copyright statement is misleading, pull the explanation comment down closer to the values inline. |
| 16:32.12 | tofu | zero_level: so the lesson from that rtweight mess is to make sure that you run "make regress" and "make test" for ALL of your changes |
| 16:33.05 | tofu | if another dev has to fix a bug you introduce, that's bad (net negative) |
| 16:34.17 | tofu | so you must take time to 1) prevent introducing errors in the first place, 2) NOTICE problems that have been introduced (by being aware of commits and testing all the time), and 3) stop work to fix any issues introduced completely |
| 16:35.27 | tofu | zero_level: and good call on the shrink question, using more memory is usually fine within reason |
| 16:41.39 | brlcad | starseeker: it depends how you intend to change the librt interface to search, but it is a published API change and it wasn't introduced just last release |
| 16:42.20 | brlcad | so yeah, the previous interface should be deprecated (and perhaps more thought into the new interface so it survives longer) |
| 16:48.10 | *** join/#brlcad kesha (~kesha@14.139.122.114) | |
| 16:52.05 | brlcad | starseeker: there isn't a need to pass argc, but it does make it so we don't have to manually calculate it in every program and you can do things like argv[argc-1] to get the last arg, etc |
| 16:52.49 | brlcad | afaik, argv has always been null-terminated (since the 70's) and even the c90 standard specified it |
| 16:54.07 | *** join/#brlcad Izak_ (~Izak@66-118-151-70.static.sagonet.net) | |
| 16:55.23 | *** join/#brlcad Izak__ (~Izak@195.24.220.16) | |
| 17:08.23 | brlcad | 14:12 < Izak__> Well I have already written prep,shot,bbox,print,vshot and curretly on norm |
| 17:08.31 | brlcad | if you're written prep and shot, we should be seeing pictures... |
| 17:18.00 | *** join/#brlcad vladbogo (~vlad@188.25.239.5) | |
| 17:22.52 | Notify | 03BRL-CAD:brlcad * 56507 brlcad/trunk/regress/testlib.c: the regex is out of date and 'invalid' as preprocessor-disabled code |
| 17:23.10 | Notify | 03BRL-CAD:brlcad * 56508 brlcad/trunk/src/bwish/input.c: no if 0 case, remove the if 1 wrappage. |
| 17:26.27 | Ch3ck_ | brlcad: just finished writing the unit tests for poly.c |
| 17:26.35 | Ch3ck_ | awaiting your reviews. |
| 17:30.08 | Notify | 03BRL-CAD:brlcad * 56509 brlcad/trunk/src/conv/asc/g2asc.c: combine the commentary on previous value with the new zero value for the comgeom region #. |
| 17:32.07 | Notify | 03BRL-CAD:brlcad * 56510 (brlcad/trunk/src/conv/g-dot.c brlcad/trunk/src/conv/ply-g.c): remove dead code |
| 17:35.27 | zero_level | brlcad : I was later able to do it without using extra memory. :-) |
| 17:38.39 | Notify | 03BRL-CAD:brlcad * 56511 (brlcad/trunk/src/external/ProEngineer/proe-brl.c brlcad/trunk/src/external/Unigraphics/ug-g.c and 2 others): remove dead code from our external plugin modules. they're updated far too infrequently for any reference code to have more utility than just figuring out what needs to be done going forward should a need arise. |
| 17:43.17 | brlcad | zero_level: at what cost? |
| 17:43.27 | brlcad | code complexity? |
| 17:43.51 | brlcad | if an algorithm can be done 2x as fast by using 2x memory, it's usually worth it |
| 17:43.55 | brlcad | memory is cheap |
| 17:44.22 | zero_level | I used the same buffer and wrote it in. |
| 17:44.27 | zero_level | later used realloc. |
| 17:44.54 | brlcad | is there a specific commit that shows what you did? |
| 17:45.10 | *** join/#brlcad Notify (~notify@66-118-151-70.static.sagonet.net) | |
| 17:45.12 | zero_level | check decimate.c and shrink_image(..) |
| 17:45.38 | Notify | 03BRL-CAD:brlcad * 56512 (brlcad/trunk/src/libdm/dm-ogl.c brlcad/trunk/src/libdm/dm-rtgl.c and 3 others): more dead code elimination |
| 17:47.07 | zero_level | well i could give u a revision number. But that doenst come from a specific rev. Its sort of combinations. |
| 17:47.55 | Notify | 03BRL-CAD:brlcad * 56513 brlcad/trunk/src/libdm/knob.c: de-k&r and remove dead code |
| 17:48.06 | zero_level | check r56498 |
| 17:48.32 | zero_level | but it has been modified in r56505 |
| 17:50.29 | zero_level | Indeed its same complexity |
| 17:52.33 | zero_level | also i modified pixshrink.c and bwshrink.c . They were sort of adding bits redundantly. Modified it to correctly implement Box Averaging for shrinking the image. |
| 18:09.44 | *** join/#brlcad merzo (~merzo@45-66-133-95.pool.ukrtel.net) | |
| 18:09.58 | Notify | 03BRL-CAD:brlcad * 56514 brlcad/trunk/src/libged/arb.c: the more I dig, the worse it looks. this begs for refactoring. |
| 18:10.43 | ``Erik | http://arcanis.github.io/sparkle/example/ |
| 18:14.18 | Notify | 03BRL-CAD:brlcad * 56515 brlcad/trunk/TODO: leave a todo for the bounding box mess |
| 18:25.48 | zero_level | brlcad : i am trying to rename decimate.c to scale.c |
| 18:26.12 | zero_level | used svn mv src/libicv/decimate.c src/libicv/scale.c |
| 18:26.35 | zero_level | But on svn diff i see only deletion and not addition |
| 18:28.47 | Notify | 03BRL-CAD Wiki:Harman052 * 5920 /wiki/User:Harman052/GSoc2013/Logs: |
| 18:30.05 | Notify | 03BRL-CAD Wiki:Harman052 * 5921 /wiki/User:Harman052/GSoc2013/Logs: |
| 18:31.23 | brlcad | zero_level: shrink_image() needs some work |
| 18:32.00 | brlcad | several issues, some I'm sure were in the originals but some you've introduced |
| 18:33.23 | brlcad | looks like most of the issues I'm seeing you didn't introduce though |
| 18:33.40 | brlcad | zero_level: "facsq,x,y,py,px,c;" is your doing ;) |
| 18:35.10 | brlcad | the biggest issue is parameter validation, making sure that factor is > 0.0 and <= 1.0 |
| 18:35.51 | brlcad | and making sure facsq > 0.0 |
| 18:36.26 | brlcad | zero_level: svn status src/libicv will tell you what it plans to do |
| 18:36.47 | brlcad | you should see an A and a D for a move |
| 18:37.11 | brlcad | otherwise, you'll need to revert and figure out what you did wrong |
| 18:38.12 | Notify | 03BRL-CAD:brlcad * 56516 (brlcad/trunk/src/libged/bigE.c brlcad/trunk/src/libged/bot_dump.c): more dead code elimination |
| 18:47.25 | Notify | 03BRL-CAD:brlcad * 56517 brlcad/trunk/src/libged/bot_dump.c: make the date string be auto-formatted to correspond with the actual runtime date/time |
| 18:48.47 | Notify | 03BRL-CAD:brlcad * 56518 brlcad/trunk/src/libged/bot_dump.c: it's the length of the string minus the newline character |
| 18:50.09 | Notify | 03BRL-CAD:brlcad * 56519 brlcad/trunk/src/libged/bot_dump.c: don't lie, we're not always NT |
| 18:53.32 | Notify | 03BRL-CAD Wiki:Vladbogolin * 5922 /wiki/User:Vladbogolin/GSoC2013/Logs: /* Week 7 */ |
| 18:57.27 | Notify | 03BRL-CAD:brlcad * 56520 brlcad/trunk/src/libged/bot_dump.c: document the SAT header |
| 19:04.39 | Notify | 03BRL-CAD:brlcad * 56521 brlcad/trunk/src/libged/bot_dump.c: there's nothing special about the 'produce ID' and many (non-Solidworks) examples are abound online, so use our name. keep the ACIS version identifier though since they probably key off of that for the file format. |
| 19:18.16 | Notify | 03BRL-CAD:brlcad * 56522 brlcad/trunk/src/libged/bot_dump.c: nothing temporary about it, but it's clear why the old version didn't work (the product ID strlen is wrong) |
| 19:26.13 | Notify | 03BRL-CAD:brlcad * 56523 brlcad/trunk/src/libged/bot_dump.c: refactor the SAT header writing into a static function since it's used in three places |
| 19:29.15 | Notify | 03BRL-CAD:erikgreenwald * 56524 brlcad/trunk/src/libbrep/intersect.cpp: change NULL to false in boolean default |
| 19:33.42 | Notify | 03BRL-CAD:brlcad * 56525 brlcad/trunk/src/libged/bot_dump.c: rename all of these functions so they're consistently fmt_verb_noun() with the format prefixing the function name so it's clear what groups with what. |
| 19:50.42 | Notify | 03BRL-CAD:brlcad * 56526 brlcad/trunk/src/libged/brep.c: comment why these export lines are here |
| 19:51.28 | Notify | 03BRL-CAD:brlcad * 56527 brlcad/trunk/src/libged/dg_obj.c: remove dead deprecated code |
| 19:51.53 | *** join/#brlcad merzo (~merzo@45-66-133-95.pool.ukrtel.net) | |
| 19:55.21 | zero_level | brlcad : factor is an integer value there. |
| 19:55.33 | zero_level | If Factor is 2.this halves the images. |
| 19:56.12 | zero_level | Also you must have notice this is hidden function. |
| 19:56.27 | zero_level | there is a wrapper function comming. |
| 19:56.37 | zero_level | which will validate the data. |
| 20:16.57 | Notify | 03BRL-CAD:brlcad * 56528 brlcad/trunk/src/libged/loadview.c: that remark was made in 1996... there's nothing temporary about this (or literally everything could be called temporary), so update the code accordingly. |
| 20:25.57 | brlcad | zero_level: good point about it being an int, but the comments still hold |
| 20:27.08 | brlcad | functions being introduced should always validate their parameters for expected valuesd unless there's a specific reason not to (usually performance or size) |
| 20:27.41 | brlcad | if the factor is always positive, then it should be an unsigned int and then one only needs to test that facsq is not zero |
| 20:28.00 | brlcad | I take that back, still have to check 'factor' too |
| 20:28.12 | brlcad | (height could be zero) |
| 20:28.46 | brlcad | a wrapper doesn't address this concern (it actually compounds the issue) |
| 20:29.37 | brlcad | a wrapper won't necessarily know that shrink_image is going to perform a division, which is where there is a risk here of an application crash |
| 20:31.48 | Notify | 03BRL-CAD:brlcad * 56529 brlcad/trunk/src/libged/png.c: unclear to me why there's padding on this allocation |
| 20:37.54 | Notify | 03BRL-CAD:brlcad * 56530 brlcad/trunk/src/libged/view_obj.c: bad assumptions in there with the magical 1.0e10 but this is a deprecated interface |
| 20:50.51 | Notify | 03BRL-CAD:brlcad * 56531 (brlcad/trunk/src/libfb/if_X.c brlcad/trunk/src/liboptical/sh_gauss.c and 3 others): remove dead code |
| 20:55.13 | Notify | 03BRL-CAD:brlcad * 56532 brlcad/trunk/src/libwdb/mater.c: not implemented for v4 and probably never will be. remove the regionid-based-coloring implication for v4. |
| 21:09.34 | Notify | 03BRL-CAD:brlcad * 56533 brlcad/trunk/src/mged/dm-generic.c: bye bye dead code |
| 21:11.33 | Notify | 03BRL-CAD:brlcad * 56534 brlcad/trunk/src/mged/clone.c: call cmd_redraw_vlist() instead of drawtrees() after calling 'tracker' to replot the wireframes. |
| 21:22.20 | Notify | 03BRL-CAD:brlcad * 56535 brlcad/trunk/src/mged/clone.c: looks like we can keep it even simpler and go through libged by calling redraw_visible_objects(). |
| 21:23.47 | Notify | 03BRL-CAD:brlcad * 56536 brlcad/trunk/src/mged/dodraw.c: eliminate 545 lines of code no longer in use by eliminating the old drawtrees() mged function. this functionality was migrated to libged/draw.c a long while back. |
| 22:21.44 | Notify | 03BRL-CAD:brlcad * 56537 brlcad/trunk/src/libwdb/mater.c: mp is no longer used |
| 22:25.42 | Notify | 03BRL-CAD:brlcad * 56538 (brlcad/trunk/CHANGES brlcad/trunk/doc/docbook/system/mann/en/CMakeLists.txt and 7 others): eliminate the 'redraw_vlist' command completely in favor of just re-issuing the 'draw' command again. looks like it might not even be working any more, but lets even more code get consolidated. |
| 22:27.33 | Notify | 03BRL-CAD:brlcad * 56539 (brlcad/trunk/src/mged/edarb.c brlcad/trunk/src/mged/scroll.c): more dead code |
| 22:39.04 | Notify | 03BRL-CAD:brlcad * 56540 (brlcad/trunk/src/mged/CMakeLists.txt brlcad/trunk/src/mged/cmd.h brlcad/trunk/src/mged/setup.c): pjt never finished import_body/export_body, commands for low-level reading/writing of geometry to files. doesn't seem like a great idea to me. say buh bye. as the main reason for db5_types.c, there may be other related code needing to go under the hatchet. |
| 23:45.41 | ``Erik | zero_level: you seem to have issues in libicv/operations.c : you frequently do if(img->flags && ICV_OPERATIONS_MODE) which will always be true... I think you mean img->flags & ICV_OPERATIONS_MODE to do a bitwise AND? |