| 00:00.17 | Notify | 03BRL-CAD:ejno * 62370 brlcad/branches/bullet/src/libged/CMakeLists.txt: remove the simulate/refactoring subdirectory |
| 00:18.45 | Notify | 03BRL-CAD:ejno * 62371 brlcad/branches/bullet/src/libtclcad/tclcad_obj.c: fix assignment outside of array bounds |
| 00:24.21 | Notify | 03BRL-CAD:starseeker * 62372 (brlcad/trunk/src/other/poly2tri/poly2tri/common/shapes.cc brlcad/trunk/src/other/poly2tri/poly2tri/common/shapes.h and 3 others): I suspect there is more to do here to properly propagate return codes up the call stack, but get a start on removing code from poly2tri that will exit on failure. As a library, poly2tri shouldn't be deciding to quite - that's up to the parent application. |
| 00:48.36 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 01:20.09 | Notify | 03BRL-CAD:ejno * 62373 (brlcad/trunk/src/libtclcad/tclcad_eval.c brlcad/trunk/src/libtclcad/tclcad_obj.c brlcad/trunk/src/libtclcad/tclcad_private.h): make tclcad_eval_var() non-variadic; vls has a nicer syntax but it isn't type-safe |
| 01:35.39 | Notify | 03BRL-CAD:starseeker * 62374 (brlcad/trunk/src/other/poly2tri/poly2tri/common/shapes.cc brlcad/trunk/src/other/poly2tri/poly2tri/common/shapes.h and 6 others): Start shifting towards using pointers... will most likely need to handle null cases if we're not going to quite mid-process. |
| 01:49.15 | Notify | 03BRL-CAD:ejno * 62375 (brlcad/trunk/src/libtclcad/cmdhist_obj.c brlcad/trunk/src/libtclcad/tclcad.c and 4 others): revert some of r62358 (work on escaping tcl commands) |
| 02:55.05 | brlcad | starseeker: interesting change .. what's the shift towards using pointers for? |
| 02:55.57 | andrei__ | brlcad: I'll send an email related to geometric kernel and what I can do from now on these days, I've been busy writing my thesis |
| 03:16.10 | brlcad | andrei__: thanks -- a brief summary of your overall gsoc accomplish, particularly for this second half, would be greatly appreciated |
| 03:18.18 | andrei__ | brlcad: that I can do, probably even today. Where should I put it, tho? |
| 03:18.28 | andrei__ | is brlcad wiki ok? |
| 03:19.07 | brlcad | a summary on/near your log or on your project page, yeah that works |
| 03:19.30 | brlcad | to persist that information |
| 03:19.38 | brlcad | but a couple paragraphs to the mailing list would be good too for the immediate audiences |
| 03:41.08 | mihaineacsu | I'm working on binary attributes and something doesn't add up here http://goo.gl/lQiGhV . This is from db5_export_attributes and I get it that it's trying to follow the format aname1 NULL value1 NULL but it seems the name's null padding is placed a byte too far and it's written over anyways by the value string. |
| 04:01.21 | brlcad | hi mihaineacsu |
| 04:01.30 | mihaineacsu | hi brlcad! |
| 04:02.15 | brlcad | the snippet you show looks right to me |
| 04:03.26 | brlcad | len in the number of chars (without a nul byte), so cp should go to len+1 for writing the nul byte |
| 04:03.40 | mihaineacsu | yeah, agreed |
| 04:03.48 | brlcad | the format is "key\0value\0"0 |
| 04:03.56 | brlcad | oops, "key\0value\0" |
| 04:04.22 | brlcad | (note NULL is not technically the same as a nul byte or |
| 04:04.26 | brlcad | \0 |
| 04:06.13 | mihaineacsu | uhhm, but isn't the second peformed memcpy writing over the '\0' ? |
| 04:09.19 | mihaineacsu | I was thinking the right way is cp += len; *cp = '\0'; ++cp; and now write the value |
| 04:11.18 | *** join/#brlcad Zhao_Anqing (~clouddrif@183.157.160.21) |
| 04:16.41 | mihaineacsu | brlcad: correct me if I'm wrong |
| 04:31.05 | *** join/#brlcad Zhao_Anqing (~clouddrif@183.157.160.21) |
| 04:32.44 | brlcad | mihaineacsu: you might not be wrong, that's not very old code and any issue would be fully masked with zero-initialized data (which it is almost certainly using) |
| 04:33.08 | brlcad | did you try running in a debugger or adding a print statement to confirm/check? |
| 04:34.27 | mihaineacsu | I haven't, I'm rewritting binary attributes, it was crashing after a series of import/exports so I'm guessing I messed up the format somewhere |
| 04:34.30 | brlcad | also, though, would need to check our v5 spec if that's the file i/O layer reading from the on-disk memory buffer |
| 04:37.15 | mihaineacsu | that's the file indeed. I've lost count how many times I've checked the spec file. I'm following Tom's proposal notes |
| 04:41.34 | mihaineacsu | by "rewritting binary attributes", I mean I reverted the changes I made and started over again; print statements pointed it crashes after a series of import/exports (after creating a material object with float density and listing it with 'l') |
| 04:41.35 | brlcad | it does indeed look like it's going too far, so just have to confirm in a debugger and check what the spec says |
| 04:49.54 | brlcad | mihaineacsu: so looking back through that code snippet's history, I see where it went wrong |
| 04:50.16 | mihaineacsu | forgot to run blame |
| 04:51.58 | brlcad | code was converted from bcopy to memset, and in the process the +1 was distributed |
| 04:52.22 | brlcad | basicaly, it should be len = strlen() + 1; |
| 04:52.50 | brlcad | so it memsets the nul byte, increments past the nul for the value |
| 04:53.13 | *** join/#brlcad vladbogo (~vlad@86.121.96.194) |
| 04:54.13 | brlcad | the code is actually just getting lucky .. results in the same byte pattern one wants, but only because the cp buf starts out as all zero's |
| 04:54.14 | mihaineacsu | yeah, I mean it couldn't have worked if it hadn't operated on previously zero-initialized data |
| 04:54.24 | mihaineacsu | exactly |
| 04:54.55 | brlcad | so name is "key" and len is 3 and cp buf is "key\0\\0\0\0\0\0... |
| 04:55.42 | mihaineacsu | right |
| 04:56.28 | brlcad | rather, [k][e][y][\0][\0] .. cp is updated to point to that 5th slot, sets it to nul, and then immediately overwrites the nul with value and another double-nul |
| 04:57.29 | mihaineacsu | yeah, I was nitpicking because I thought I'm not following the format right |
| 04:57.32 | brlcad | so both the old and the new end up with [k][e][y][\0][v][a][l][\0][\0][...] |
| 04:57.43 | brlcad | well, that's worth checking :) |
| 04:58.33 | brlcad | but just looking through the history itself, there's no mention and that would be somewhat unusual |
| 04:58.41 | brlcad | good catch |
| 04:58.53 | brlcad | going to fix it? that's make a fine isolated patch |
| 04:59.09 | mihaineacsu | yeah, it's part of the binary attributes |
| 04:59.39 | brlcad | I mean not connected to any other changes, the code is (presumably) wrong on trunk sources |
| 05:00.07 | brlcad | patches ideally change one and only one thing when they have to be manually applied |
| 05:00.08 | mihaineacsu | aah, okay, I'll submit a separate patch for it |
| 05:00.38 | mihaineacsu | what about features? |
| 05:00.48 | brlcad | patches are so you can get commit, which is frankly more important than your entire project ;) |
| 05:00.53 | Notify | 03BRL-CAD Wiki:Madcoder3753 * 0 /wiki/User:Madcoder3753: |
| 05:01.04 | brlcad | what about features? |
| 05:01.50 | mihaineacsu | well, I realize the patch for material objects is a pain to go through because it's over a thousand lines |
| 05:02.13 | mihaineacsu | should it be submitted differently? |
| 05:02.18 | brlcad | indeed |
| 05:03.32 | brlcad | so this is really a community devmanship issue |
| 05:03.40 | brlcad | we don't want you submitting patches |
| 05:03.44 | brlcad | you don't want to submit patches |
| 05:03.55 | brlcad | they're tiresome and exhausting to review |
| 05:04.28 | brlcad | and not an effective way to share code over a long period of time (repeatedly to the level of granularity we like to speak) |
| 05:04.45 | brlcad | we require patches to ensure adherence to our dev principles |
| 05:05.13 | brlcad | so patches should be short, sweet, and simple -- easy to review -- and most of all PERFECT |
| 05:06.30 | brlcad | new devs have to have a couple perfect patches before they're granted commit, but then they do usually get that right/responsibility if they're interested in contributing or working on a project |
| 05:06.35 | brlcad | anyone can do that |
| 05:07.15 | brlcad | the trick is what is meant by "perfect" .. that means absolutely no issues that would incur time on another dev to clean up after your patch is applied |
| 05:08.09 | brlcad | which can be egregious issues like the patch not even compiling and blatant logic errors, or more subtle issues like bad names or (most common) not following our code conventions and/or style |
| 05:09.09 | brlcad | so yeah, find something really simple and isolated to change (more than a few lines, the patch does still have to be a meaningful and substantive improvement to code), and submit that as a patch |
| 05:10.02 | brlcad | your big material patch shouldn't be submitted differently unless there's one or two simple things in it that can be broken out, reviewed independently as some small but real improvement, and is ... flawless |
| 05:10.59 | brlcad | ideally, you'd hold off on that one until you got commit access, then you'd proceed to turn that beast into dozens of commits, commenting as you go along with log messages |
| 05:11.05 | brlcad | make sense? |
| 05:11.17 | mihaineacsu | it makes perfect sense |
| 05:11.56 | brlcad | apologies if that wasn't clear .. HACKING mentions these points in a variety of ways, but often what it really means is lost on the reader |
| 05:12.14 | mihaineacsu | I'm more familiar with git and for me at least it's a bit easier to track pull requests there |
| 05:12.30 | brlcad | we like LOTS and lots of small commits |
| 05:12.40 | brlcad | so yeah, we want you working just like you would with git |
| 05:13.30 | brlcad | just it's not your git repo, it's someone else's .. so there are measures in place to make sure you aren't disruptive |
| 05:14.31 | mihaineacsu | I'll finish the binary attributes and review the material objects again this weekends. Do you think you can look over them next week? |
| 05:14.49 | brlcad | so instead of you doing your own thing and sending pulls, you're actually empowered to just make the changes (effectively pulling them yourself into our main master) |
| 05:14.55 | brlcad | yep |
| 05:16.09 | brlcad | it forces communication and lets us ensure adherence to our code standards (which are undeniably much higher than most projects) |
| 05:17.13 | brlcad | have you worked with any centralized / master repo before that you didn't own but you could directly pull / commit into? |
| 05:17.27 | mihaineacsu | yes |
| 05:17.41 | brlcad | anything I might recognize? :) |
| 05:17.42 | mihaineacsu | but they were all git repos |
| 05:18.17 | mihaineacsu | it's not a public repo unfortunately, it was for work |
| 05:18.44 | brlcad | git doesn't really change anything in this regard (I can set up a centralized git repo just fine) |
| 05:18.52 | mihaineacsu | otherwise, just small projects, some I even shared with andrei |
| 05:19.36 | brlcad | it's whether someone else is integrating your work into a main branch or whether you are tightly having to coordinate your activity with others (on that main master) |
| 05:21.27 | brlcad | anyways, .. so yeah, lets get you going quickly -- if/when you have a perfect patch ready to go, send me the link |
| 05:22.29 | brlcad | being careful about following style is usually the hardest for new devs not familiar with the myriad of possible coding styles there are out there and how to adjust their dev environment |
| 05:22.40 | mihaineacsu | ok, I'll look over ones I already submitted and make sure they're presentable. |
| 05:23.01 | brlcad | we still use mixed tabs+spaces, which is unusual |
| 05:23.55 | mihaineacsu | right |
| 05:23.58 | brlcad | yeah, see if there is *anything* about your patch that can be improved without increasing the scope of what the patch changes (better != doing more) |
| 05:25.02 | brlcad | proper braces, tabs, function names, var names, no compile warnings, applies cleanly to trunk checkout, nothing in the patch that is a temporary "work in progress" that actually makes the code worse before it makes it better,e tc |
| 05:27.43 | brlcad | if you see anything, I can almost guarantee you that I'll see it too ... the trick is making it an unambiguous improvement that is downright trivially easy to review and accept (should be absolutely no reason to not accept it) |
| 05:27.56 | brlcad | and once you get to that point, you work on making every commit just like that ;) |
| 05:33.56 | mihaineacsu | yep |
| 05:46.16 | Notify | 03BRL-CAD:zhaoanqing * 62376 (brlcad/branches/nmgreorg/include/raytrace.h brlcad/branches/nmgreorg/src/libged/bev.c and 16 others): change the name of NMG functions in librt from nmg_XXX to rt_nmg_XXX. |
| 05:53.32 | *** join/#brlcad mihaineacsu_ (~mihaineac@92.85.193.65) |
| 07:07.39 | Notify | 03BRL-CAD:zhaoanqing * 62377 (brlcad/branches/nmgreorg/src/adrt/load_g.c brlcad/branches/nmgreorg/src/conv/dxf/g-dxf.c and 20 others): update the calling of rt functions after change their name. program is avaliable on Linux. |
| 07:11.30 | *** join/#brlcad chick_ (~chick@41.205.22.96) |
| 07:13.00 | *** join/#brlcad ries (~ries@D979EA84.cm-3-2d.dynamic.ziggo.nl) |
| 07:40.05 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) |
| 07:51.46 | *** join/#brlcad chick_ (~chick@41.205.22.96) |
| 08:41.34 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
| 08:46.02 | *** join/#brlcad Izakey (~Isaac@195.24.220.134) |
| 09:57.06 | *** join/#brlcad chick_ (~chick@41.205.22.96) |
| 10:09.05 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
| 10:20.34 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
| 10:48.12 | starseeker | brlcad: eventually, i'd like to push that algorithm down into libbn |
| 10:51.25 | starseeker | (i.e., into C) |
| 10:52.10 | starseeker | I also have vague notions that pointer NULL testing will be useful handling bad states, but we'll see |
| 10:53.45 | starseeker | doubt I'll end up with a libbn conversion at the end of this particular push, but you never know - and even if I don't hopefully the next stage in that direction will be easier after this |
| 11:47.48 | *** join/#brlcad Izakey (~Isaac@195.24.220.16) |
| 12:00.39 | *** join/#brlcad clock (~clock@77-58-143-135.dclient.hispeed.ch) |
| 12:39.11 | Notify | 03BRL-CAD:iiizzzaaakkk * 62378 brlcad/trunk/src/librt/primitives/hrt/hrt.c: rt_hrt_plot() function to draw the wire frame of the heart |
| 12:41.34 | *** join/#brlcad clock (~clock@77-58-143-135.dclient.hispeed.ch) |
| 12:41.58 | *** join/#brlcad Zhao_Anqing (~clouddrif@183.157.160.21) |
| 12:43.38 | Izakey | brlcad, ``Erik, starseeker You can take a look at some images of the heart's wire frame (rendered using mged) http://brlcad.org/~Izak/Heart_Wireframe_right.png, http://brlcad.org/~Izak/Heart_Wireframe_front.png and http://brlcad.org/~Izak/Heart_Wireframe_Top.png |
| 13:13.49 | ``Erik | nice, apple sandbox uses tinyscheme http://reverse.put.as/wp-content/uploads/2011/06/The-Apple-Sandbox-BHDC2011-Paper.pdf |
| 13:23.02 | Notify | 03BRL-CAD:starseeker * 62379 brlcad/trunk/src/other/poly2tri/poly2tri/sweep/sweep.cc: Avoid crashing if null points come back - this gets the 'bad' step import of the neo1973 with the old step-g from a couple weeks ago drawing. |
| 13:26.09 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
| 13:31.24 | Notify | 03BRL-CAD:starseeker * 62380 brlcad/trunk/src/other/poly2tri/poly2tri/sweep/sweep.cc: More null checks. |
| 13:52.28 | Notify | 03BRL-CAD:starseeker * 62381 (brlcad/trunk/src/other/poly2tri/poly2tri/sweep/sweep.cc brlcad/trunk/src/other/poly2tri/poly2tri/sweep/sweep.h and 2 others): Used Node pointers for some functions. |
| 14:18.00 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 14:18.09 | Notify | 03BRL-CAD:starseeker * 62382 (brlcad/trunk/src/other/poly2tri/poly2tri/sweep/sweep.cc brlcad/trunk/src/other/poly2tri/poly2tri/sweep/sweep.h): ws, more null checking |
| 14:21.23 | *** join/#brlcad clock (~clock@77-58-143-135.dclient.hispeed.ch) |
| 14:42.57 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 15:00.05 | *** join/#brlcad Izakey (~Isaac@195.24.220.16) |
| 15:12.53 | ``Erik | http://www.miaumiau.cat/2014/08/gpu-marching-cubes-in-webgl/ |
| 15:48.00 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
| 15:53.51 | *** join/#brlcad ashank (~ashank@115.250.31.229) |
| 16:07.58 | Notify | 03BRL-CAD:starseeker * 62383 (brlcad/trunk/src/other/poly2tri/README.md brlcad/trunk/src/other/poly2tri.dist): Scrub unnecessary files out of poly2tri. |
| 16:08.39 | *** join/#brlcad chick_ (~chick@41.205.22.96) |
| 16:20.49 | Notify | 03BRL-CAD Wiki:Shishir1972 * 0 /wiki/User:Shishir1972: |
| 16:22.32 | *** join/#brlcad Izakey (~Isaac@195.24.220.134) |
| 16:28.18 | *** join/#brlcad ashank (~ashank@115.250.31.229) |
| 16:39.10 | *** join/#brlcad Ch3ck_ (~localhost@195.24.220.134) |
| 16:46.44 | *** join/#brlcad vladbogo (~vlad@86.124.248.31) |
| 18:01.17 | Notify | 03BRL-CAD:carlmoore * 62384 brlcad/trunk/doc/docbook/system/man1/en/g-nmg.xml: remove some underscores & a comma; more serious -- remove fake -( item |
| 18:04.12 | mihaineacsu | http://www.cs.cmu.edu/~om3d/ |
| 18:12.13 | Notify | 03BRL-CAD:carlmoore * 62385 (brlcad/trunk/doc/docbook/system/man1/en/g-obj.xml brlcad/trunk/doc/docbook/system/man1/en/g-raw.xml): do what has become my routine touching-up |
| 18:13.53 | Notify | 03BRL-CAD:bob1961 * 62386 (brlcad/trunk/src/libfb/if_ogl.c brlcad/trunk/src/libfb/if_wgl.c): Updates to libfb's ogl_clear(), ogl_refresh(), wgl_clear() and wgl_refresh() that relate to being controlled externally. |
| 18:39.14 | Notify | 03BRL-CAD:ejno * 62387 brlcad/branches/bullet/src/libged/CMakeLists.txt: revert r62359 |
| 19:04.13 | Izakey | brlcad ``Erik Seen the images of the heart's wire frame ? |
| 19:12.34 | *** join/#brlcad clock (~clock@77-58-143-135.dclient.hispeed.ch) |
| 20:02.49 | *** join/#brlcad clock (~clock@77-58-143-135.dclient.hispeed.ch) |
| 20:12.26 | *** join/#brlcad FreezingCold (~FreezingC@CPE602ad06bea2a-CM602ad06bea27.cpe.net.cable.rogers.com) |
| 20:29.50 | Notify | 03BRL-CAD:carlmoore * 62388 (brlcad/trunk/doc/docbook/system/man1/en/g-shell-rect.xml brlcad/trunk/doc/docbook/system/man1/en/g-step.xml and 2 others): touchup; problem in that I could not completely eliminate the indentation in the g-tankill EXAMPLE |
| 20:37.52 | Notify | 03BRL-CAD:carlmoore * 62389 brlcad/trunk/doc/docbook/system/man1/en/g-var.xml: for g-var, reduce use of boldface; do the routine underscore fix as well |
| 21:21.09 | Notify | 03BRL-CAD:carlmoore * 62390 (brlcad/trunk/doc/docbook/system/man1/en/g-vrml.xml brlcad/trunk/doc/docbook/system/man1/en/g-x3d.xml and 5 others): touchup |
| 21:37.12 | *** join/#brlcad FreezingCold (~FreezingC@CPE602ad06bea2a-CM602ad06bea27.cpe.net.cable.rogers.com) |
| 21:44.25 | Notify | 03BRL-CAD:carlmoore * 62391 brlcad/trunk/doc/docbook/system/man1/en/gif-fb.xml: I do NOT use boldface for the command name in an EXAMPLE |
| 21:46.55 | *** join/#brlcad chick_ (~chick@41.205.22.96) |
| 22:27.09 | *** join/#brlcad clock (~clock@77-58-143-135.dclient.hispeed.ch) |
| 23:03.10 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
