| 00:18.58 | *** join/#brlcad xth1 (~thiago@187.106.53.123) | |
| 00:24.56 | *** join/#brlcad jbschw (~jbschw@ool-4355ee10.dyn.optonline.net) | |
| 00:26.54 | *** join/#brlcad crdueck (~cdk@d173-238-127-19.home4.cgocable.net) | |
| 00:31.20 | CIA-65 | BRL-CAD: 03Cprecup 07http://brlcad.org * r3753 10/wiki/User:Cprecup/GSoC2012_progress: 27-28/05/2012 |
| 01:19.29 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) | |
| 02:32.34 | CIA-65 | BRL-CAD: 03brlcad * r50724 10/brlcad/trunk/src/librt/primitives/ell/ell.c: (log message trimmed) |
| 02:32.36 | CIA-65 | BRL-CAD: apply sf patch 3530033 from Al_Da_Best ( aldabest ) - 'Adding centroid and |
| 02:32.36 | CIA-65 | BRL-CAD: surface area for ellipsoid primitive' though the patch now only adds surface |
| 02:32.36 | CIA-65 | BRL-CAD: area since someone else beat him to the centroid function. the patch was |
| 02:32.36 | CIA-65 | BRL-CAD: slightly modified for strict compilation and still has a problem using fabs() |
| 02:32.36 | CIA-65 | BRL-CAD: and a hard-coded 0.0001 magic tolerance value, but can't fault him too much for |
| 02:32.36 | CIA-65 | BRL-CAD: that error since someone else apparently introduced that bad practice in the |
| 02:34.17 | brlcad | starseeker: looks like you're the culprit there.. :) |
| 02:39.02 | CIA-65 | BRL-CAD: 03brlcad * r50725 10/brlcad/trunk/src/librt/primitives/revolve/revolve_brep.cpp: the plane isn't used (or deallocated), so remove it (and quell the compilation verbage) |
| 02:44.15 | CIA-65 | BRL-CAD: 03brlcad * r50726 10/brlcad/trunk/src/librt/primitives/ell/ell.c: remove the 0.0001 magic tolerance values. instead, use the default tolerance used within EQUAL(), which should be near what the hardware is capable of distinguishing. better would probably be to use a bn_tol->dist. |
| 02:48.08 | CIA-65 | BRL-CAD: 03brlcad * r50727 10/brlcad/trunk/src/librt/primitives/sph/sph.c: since they're not documented, remove the 0.0001 magic tolerance values with tighter hardware-centric tolerances via EQUAL() testing. |
| 02:58.49 | CIA-65 | BRL-CAD: 03brlcad * r50728 10/brlcad/trunk/AUTHORS: credit alex taylor for his code contribution applied from sf patch 3530033 related to his gsoc participation. note the other recent gsoc/socis students too. |
| 03:30.15 | CIA-65 | BRL-CAD: 03Crdueck 07http://brlcad.org * r3754 10/wiki/User:Crdueck/log: |
| 03:30.35 | CIA-65 | BRL-CAD: 03Eunice 07http://brlcad.org * r3755 10/wiki/Main_Page: |
| 03:36.15 | CIA-65 | BRL-CAD: 03Sean 07http://brlcad.org * r3756 10/wiki/Main_Page: Reverted edits by [[Special:Contributions/Eunice|Eunice]] ([[User talk:Eunice|Talk]]); changed back to last version by [[User:Sean|Sean]] |
| 03:36.31 | CIA-65 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Eunice]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites |
| 03:55.45 | CIA-65 | BRL-CAD: 03brlcad * r50729 10/brlcad/trunk/AUTHORS: |
| 03:55.45 | CIA-65 | BRL-CAD: credit mesut (aka kane) with his sf patch 3527658 (refactor and manage libbn |
| 03:55.45 | CIA-65 | BRL-CAD: tolerance uses by providing an interface default (e.g., an init macro) and |
| 03:55.45 | CIA-65 | BRL-CAD: making everyone use that where it is hardcoded to 0.0005 presently). comes to |
| 03:55.45 | CIA-65 | BRL-CAD: brl-cad from gsoc. |
| 04:07.57 | brlcad | fg |
| 05:15.53 | CIA-65 | BRL-CAD: 03phoenixyjll * r50730 10/brlcad/trunk/sh/conversion.sh: change the suffix brep2 to brep |
| 05:54.45 | *** join/#brlcad Jak_o_Shadows (~Fake@unaffiliated/jak-o-shadows/x-0479135) | |
| 06:31.28 | *** join/#brlcad ksuzee (~ksu@46.149.82.166) | |
| 06:31.29 | *** join/#brlcad ksuzee_ (~ksu@46.149.82.166) | |
| 06:37.16 | *** part/#brlcad ksuzee_ (~ksu@46.149.82.166) | |
| 06:50.22 | CIA-65 | BRL-CAD: 03Ksuzee 07http://brlcad.org * r3757 10/wiki/User:Ksuzee/Reports: |
| 07:02.20 | CIA-65 | BRL-CAD: 03Ksuzee 07http://brlcad.org * r3758 10/wiki/User:Ksuzee/Reports: |
| 07:03.09 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 07:12.07 | *** join/#brlcad yiyus (1242712427@je.je.je) | |
| 07:14.38 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 08:31.03 | *** join/#brlcad Jak_o_Shadows (~Fake@unaffiliated/jak-o-shadows/x-0479135) | |
| 08:48.10 | *** join/#brlcad merzo (~merzo@96-14-132-95.pool.ukrtel.net) | |
| 08:58.43 | CIA-65 | BRL-CAD: 03Phoenix 07http://brlcad.org * r3759 10/wiki/User:Phoenix/GSoc2012/Reports: /* Week 2 */ |
| 09:06.09 | *** join/#brlcad stas (~stas@82.208.133.12) | |
| 10:11.52 | *** join/#brlcad anuragmurty (~anurag@14.139.128.11) | |
| 10:25.15 | anuragmurty | d_rossberg : hi! i had a query.. |
| 10:25.45 | anuragmurty | d_rossberg: for the voxelize command i had tries a basic program that just shoots rays from 3 different directions |
| 10:26.10 | anuragmurty | Like you said it is not useful, but i was just tryin something out |
| 10:26.43 | anuragmurty | i used a bounding box from struct rt_i.. |
| 10:27.57 | anuragmurty | for , let us say, a grid of rays, should i still use a grid of rays shot uniformly on the face of the bounding box? or is this incorrect? |
| 10:51.07 | *** join/#brlcad Jak_o_Shadows (~Fake@unaffiliated/jak-o-shadows/x-0479135) | |
| 11:03.24 | d_rossberg | anuragmurty: that sounds reasonable (a grid of rays shot uniformly on the face of the bounding box) |
| 11:05.32 | anuragmurty | thanks! |
| 11:06.51 | d_rossberg | for your further progress I would recommend to choose a name and place for the program that writes the voxel into a file to be used by other programs (e.g. hydrocodes) |
| 11:08.14 | d_rossberg | there you can develop your code without interfering with other libraries and programs |
| 11:09.25 | anuragmurty | ok.. src/libanalyze was suggested to me.. |
| 11:10.20 | d_rossberg | if you have found your algorithm you can transfer it into an appropriate library, write mged-functions etc. |
| 11:11.03 | d_rossberg | libanalyse would be the "appropriate library" |
| 11:11.27 | anuragmurty | ok.. |
| 11:13.13 | d_rossberg | but it is easier to develop the code in an own program without recompilind a library (and the depending libraries and programs) again and again |
| 11:14.56 | anuragmurty | ok.. |
| 11:16.28 | anuragmurty | and eventually it should find its place in a library? (if all goes well) |
| 11:16.29 | anuragmurty | ? |
| 11:18.37 | d_rossberg | the basic algorithm should find it's place in a library |
| 11:19.53 | d_rossberg | then there are mged/TCL scripts (libged?) and at least one stand-alone program using this algorithm |
| 11:22.11 | d_rossberg | this program could be a converter "g-voxel-file" |
| 11:22.34 | d_rossberg | or simply g-voxel |
| 11:23.19 | anuragmurty | ok.. |
| 11:24.18 | anuragmurty | thank you d_rossberg.. i will proceed with the work then.. |
| 11:24.46 | *** join/#brlcad Jak_o_Shadows (~Fake@unaffiliated/jak-o-shadows/x-0479135) | |
| 11:32.52 | *** join/#brlcad bhinesley (~bhinesley@108.220.113.189) | |
| 11:43.50 | *** part/#brlcad anuragmurty (~anurag@14.139.128.11) | |
| 12:14.13 | CIA-65 | BRL-CAD: 03phoenixyjll * r50731 10/brlcad/trunk/src/libged/brep.c: Check whether brep is converted successfully. (A failure will return a NULL pointer like the conversion of old.s82 and old.s79 in m35.g) |
| 12:17.39 | CIA-65 | BRL-CAD: 03phoenixyjll * r50732 10/brlcad/trunk/src/ (librt/primitives/brep/brep_debug.cpp proc-db/csgbrep.cpp): Use BN_DIST_TOL to replace the hard coded 0.0005. And set revolve.r and revolve.ang in csgbrep.cpp. |
| 12:19.25 | CIA-65 | BRL-CAD: 03Phoenix 07http://brlcad.org * r3760 10/wiki/User:Phoenix/GSoc2012/Reports: /* Week 2 */ |
| 12:45.57 | CIA-65 | BRL-CAD: 03phoenixyjll * r50733 10/brlcad/trunk/src/librt/primitives/eto/eto_brep.cpp: eto_endvertex_pt was set but not used before. |
| 12:48.07 | CIA-65 | BRL-CAD: 03erikgreenwald * r50734 10/brlcad/trunk/ (NEWS sh/CMakeLists.txt sh/Makefile.am sh/ios-icons.sh): Add shell script to generate icons suitable for IOS (Apple mobile) applications |
| 12:54.27 | *** join/#brlcad jbschw (~jbschw@ool-4355ee10.dyn.optonline.net) | |
| 13:13.39 | *** join/#brlcad ksuzee (~ksu@46.149.82.166) | |
| 13:16.12 | *** join/#brlcad bhinesley (~bhinesley@108.220.113.189) | |
| 13:16.12 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 13:16.12 | *** mode/#brlcad [+o brlcad] by wolfe.freenode.net | |
| 13:57.33 | CIA-65 | BRL-CAD: 03erikgreenwald * r50735 10/brlcad/trunk/src/rt/view.c: fix call to icv writepixel where x and y were swapped. This fixes the bug where 'just changing the size' rotated the image 90 degrees, with -s <= 96 switching to MODE_UNBUF and touching this line. |
| 13:58.58 | CIA-65 | BRL-CAD: 03erikgreenwald * r50736 10/brlcad/trunk/NEWS: mention rotate bug being fixed |
| 14:13.10 | ``Erik | http://elfga.com/~erik/app1.png |
| 14:13.21 | ``Erik | http://elfga.com/~erik/app2.png |
| 14:13.24 | ``Erik | :D |
| 14:41.13 | brlcad | ``Erik: heh |
| 14:43.18 | DarkCalf | waves to brlcad |
| 14:43.24 | brlcad | moo |
| 14:56.28 | CIA-65 | BRL-CAD: 03starseeker * r50737 10/brlcad/trunk/CMakeLists.txt: |
| 14:56.28 | CIA-65 | BRL-CAD: As it turns out, umask settings do have some impact on CMake/CPack builds. |
| 14:56.28 | CIA-65 | BRL-CAD: While CMake's install process does not directly make use of umask, the temporary |
| 14:56.28 | CIA-65 | BRL-CAD: files staged in the build directory do. The install process in turn makes use |
| 14:56.28 | CIA-65 | BRL-CAD: of the permissions set on those files. It does not appear to be possible to set |
| 14:56.29 | CIA-65 | BRL-CAD: umask from the CMake build itself, so instead warnings are generated if the |
| 14:56.30 | CIA-65 | BRL-CAD: umask setting looks problematic. |
| 15:03.46 | brlcad | starseeker: instead of worrying about the umask, the real test would be to see what is installed |
| 15:04.38 | brlcad | see Makefile.am:345 |
| 15:05.41 | brlcad | umask 000 would be fine, for example, or 002 even -- both of which will fail your test |
| 15:05.44 | starseeker | nods - I still prefer to check the umask up front, since it avoids the time waste of installing something that will be using the wrong settings |
| 15:05.46 | CIA-65 | BRL-CAD: 03Plussai 07http://brlcad.org * r3761 10/wiki/User:Plussai/GSoC_2012_log: /* 23 May 2012 */ |
| 15:05.55 | brlcad | as will 0222, which is bad but will pass your test |
| 15:06.12 | starseeker | brlcad: ok, I'll make an explicit OK settings list then |
| 15:06.18 | CIA-65 | BRL-CAD: 03Plussai 07http://brlcad.org * r3762 10/wiki/User:Plussai/GSoC_2012_log: /* 27 May 2012 */ |
| 15:06.19 | starseeker | I want to catch it without having to build and install |
| 15:06.39 | CIA-65 | BRL-CAD: 03Plussai 07http://brlcad.org * r3763 10/wiki/User:Plussai/GSoC_2012_log: /* 27 May 2012 */ |
| 15:07.00 | starseeker | I'm also not familiar with how to trigger a post-install rule with CMake (and how that plays in to things like RPM) |
| 15:07.07 | CIA-65 | BRL-CAD: 03Plussai 07http://brlcad.org * r3764 10/wiki/User:Plussai/GSoC_2012_log: /* 27 May 2012 */ |
| 15:07.24 | CIA-65 | BRL-CAD: 03Plussai 07http://brlcad.org * r3765 10/wiki/User:Plussai/GSoC_2012_log: /* 27 May 2012 */ |
| 15:08.08 | brlcad | sure, good thing to check -- just going to be a relatively fragile check given variability in the umask tool across platforms |
| 15:08.26 | starseeker | it's not a fatal error, just a warning |
| 15:09.29 | brlcad | so then it doesn't avoid the time waste of installing something that will be using the wrong settings ... :) |
| 15:09.44 | brlcad | there will just be a few lines in their log that they can shake their fist at later :) |
| 15:09.53 | starseeker | yes it does, if it warns me I forgot about umask before I type make install |
| 15:10.17 | starseeker | or even make, for that matter |
| 15:10.24 | brlcad | unless I'm building a package with distcheck |
| 15:10.43 | starseeker | you still have to configure before you can use distcheck |
| 15:11.00 | brlcad | ah, cool, okay |
| 15:12.09 | starseeker | I'll take a look at post-install rules too having been bitten once, I'll make it as bullet proof as I can figure out how |
| 15:15.09 | brlcad | the posix portable way would be to run umask -S and parse |
| 15:15.30 | starseeker | winces |
| 15:15.34 | brlcad | that avoids the sticky bit |
| 15:16.16 | brlcad | and other upper-bit issues, and is a specific format, unlike the default output which is merely "a mask that can be fed back to umask" |
| 15:16.18 | starseeker | OK - let me finish this tweak and I'll look at that |
| 15:16.36 | brlcad | not saying to do that, just a thought |
| 15:17.59 | brlcad | supporting the posix interface would be better behaved on unix systems, but then might not work on systems like haiku or qnx (dunno) |
| 15:18.48 | brlcad | using the old 3-or-4-digit output from umask is just as likely to work or not work, just harder to actually not get a false positive and catch the other valid masks |
| 15:19.05 | CIA-65 | BRL-CAD: 03starseeker * r50738 10/brlcad/trunk/CMakeLists.txt: Check a variety of known 'OK' umask settings - avoids invalid matches to the regex like 0222 (thanks Sean.) |
| 15:20.17 | *** join/#brlcad anuragmurty (~anurag@14.139.128.12) | |
| 15:20.21 | *** join/#brlcad npcdoom (~npcdoom@gugve/developer/npcdoom) | |
| 15:20.25 | brlcad | before you go thanking me... :) |
| 15:20.38 | brlcad | actually, 0222 would have been fine -- that just means the owner can't write |
| 15:20.57 | starseeker | humph |
| 15:21.18 | starseeker | with a umask like that, how would they do anything? |
| 15:21.53 | brlcad | they can read and run everything, just not modify it |
| 15:22.09 | brlcad | also depends whether we're talking about files here or directories -- what exactly is/was the problem? |
| 15:22.33 | starseeker | rpm package got created with bad directory settings |
| 15:22.49 | ``Erik | rpm decided to do chmod 700 /usr |
| 15:23.20 | ``Erik | (via cpio extraction) |
| 15:23.54 | brlcad | presumably because of a 077 mask? |
| 15:24.01 | starseeker | yep |
| 15:24.38 | brlcad | OR because it was told to pack /usr/brlcad and that directory was already 700 |
| 15:24.54 | starseeker | shakes his head - we confirmed it's the rpm |
| 15:25.05 | brlcad | both those will "be the rpm" |
| 15:25.37 | starseeker | it's packing from the build directory, not from /usr/brlcad |
| 15:25.44 | brlcad | okay |
| 15:26.34 | ``Erik | if I grok, /home/starseeker/rpmbuild/brlcad-7.20.6/usr was created with 700 due to umask, cpio'd up into the rpm, then rpm -i 'updated' /usr with that mode |
| 15:26.37 | jordisayol | sorry, I'm lost... :-/ Are you talking about the rpm packages from download page? |
| 15:26.55 | starseeker | jordisayol: no - this is the one created by the CMake/CPack make package command |
| 15:28.33 | brlcad | sounds like the real issue is making sure there's an exec bit set |
| 15:28.43 | brlcad | since there are valid use cases for not having read/write on user, group, other |
| 15:29.07 | brlcad | you just need "read" and "exec" on one of the three |
| 15:29.57 | CIA-65 | BRL-CAD: 03starseeker * r50739 10/brlcad/trunk/CMakeLists.txt: Whoops, stray line |
| 15:30.07 | brlcad | for a cpacked package, I'd expect exec on all three |
| 15:30.38 | *** join/#brlcad anuragmurty1 (~anurag@14.139.128.12) | |
| 15:31.52 | brlcad | for the directories, that is |
| 15:32.12 | brlcad | maybe checking the root or the bin dir, since you only need to check one of them |
| 15:32.32 | brlcad | that would have caught the case you ran into here |
| 15:33.01 | jordisayol | starseeker: aha. How can I generate/test it? |
| 15:33.30 | *** join/#brlcad anuragmurty (~anurag@14.139.128.12) | |
| 15:33.53 | starseeker | jordisayol: make package |
| 15:34.10 | jordisayol | starseeker: ok :-[ |
| 15:35.01 | *** join/#brlcad anuragmurty1 (~anurag@14.139.128.12) | |
| 15:36.08 | brlcad | if test "x`umask -S | sed 's/[^x]//g'`" != "xxxx" ; then echo WARNING ; fi |
| 15:38.22 | brlcad | that extracts all the 'x' bits from umask -S, making sure there are three "xxx" |
| 15:38.47 | brlcad | similarly could check that there's at least one "r" bit |
| 15:39.59 | brlcad | if test "x`umask -S | sed 's/[^r]//g'`" == "x" ; then echo WARNING ; fi |
| 15:43.57 | *** join/#brlcad anuragmurty (~anurag@14.139.128.12) | |
| 15:49.00 | *** join/#brlcad jbschw (~jbschw@ool-4355ee10.dyn.optonline.net) | |
| 15:58.32 | starseeker | brlcad: hmm - that's an idea |
| 16:10.14 | CIA-65 | BRL-CAD: 03starseeker * r50740 10/brlcad/trunk/CMakeLists.txt: Alter umask test to use POSIX -S output, per suggestion from Sean. |
| 16:36.23 | *** join/#brlcad Stattrav_ (~Stattrav@61.12.114.82) | |
| 16:48.15 | *** join/#brlcad ksuzee (~ksu@193.151.107.42) | |
| 16:59.22 | *** join/#brlcad jbschw (~jbschw@ool-4355ee10.dyn.optonline.net) | |
| 17:01.16 | brlcad | starseeker: that looks good, hopefully portable enough :) |
| 17:01.33 | brlcad | but then we can at least shake a posix finger at non-conforming platforms |
| 17:01.39 | starseeker | heh |
| 17:02.00 | *** join/#brlcad anuragmurty (~anurag@14.139.128.12) | |
| 17:10.10 | jordisayol | starseeker: is this packaging way to replace the actual rpm/deb? |
| 17:10.44 | starseeker | jordisayol: not sure what you mean - it's a way to generate an RPM (and a deb, although that's not supported in our build yet) |
| 17:13.23 | jordisayol | starseeker: I mean that actually there are two scripts to create rpm and deb packages. will cpack replace these scripts? |
| 17:13.36 | starseeker | oh. In principle, yes |
| 17:14.43 | starseeker | there's a fair bit of work that would probably be needed to get there though |
| 17:14.57 | starseeker | most of what you've done with the scripts would need to be replicated in CMake/CPack logic |
| 17:18.11 | jordisayol | starseeker: ok, when you think it will be ready? |
| 17:18.27 | starseeker | jordisayol: hard to say |
| 17:18.43 | jordisayol | more than a half year? |
| 17:18.45 | starseeker | jordisayol: it's not a major focus for me at the moment - interested? |
| 17:19.30 | jordisayol | starseeker: I've no idea about cpack |
| 17:19.59 | starseeker | jordisayol: it's not terribly tricky - mostly involves setting a bunch of variables |
| 17:20.26 | starseeker | jordisayol: you're using the spec file in misc? |
| 17:20.48 | jordisayol | starseeker: in misc? |
| 17:21.06 | starseeker | misc/brlcad.spec.in or something like that in the source tree |
| 17:22.42 | jordisayol | starseeker: nope, sh/make_rpm.sh creates its own spec file depending on os and arch |
| 17:22.43 | *** join/#brlcad anuragmurty (~anurag@14.139.128.12) | |
| 17:23.16 | starseeker | jordisayol: ah - so the thing to do would be to make a template spec file with variables for the things that make_rpm.sh fills in |
| 17:23.30 | starseeker | then there would be more things CMake could fill in, which would also become variables |
| 17:24.49 | jordisayol | starseeker: due to dependencies, I just allow to build them into fedora and opensuse |
| 17:25.13 | starseeker | what do you mean? |
| 17:25.26 | *** join/#brlcad anuragmurty (~anurag@14.139.128.12) | |
| 17:26.02 | jordisayol | starseeker: fedora and opensuse share the same packaging system (rpm), but they do not share the same nomenclator for packages names |
| 17:26.11 | starseeker | jordisayol: you can see some of the CPack/RPM documentation here: http://www.vtk.org/Wiki/CMake:CPackPackageGenerators#RPM_.28Unix_Only.29 |
| 17:26.30 | starseeker | jordisayol: ah - that's something to be detected then and set as a variable in CMake |
| 17:26.49 | jordisayol | starseeker: so a package build for opensuse can become uninstallable on fedora/centos os |
| 17:27.14 | *** join/#brlcad anuragmurty (~anurag@14.139.128.12) | |
| 17:27.41 | starseeker | nods |
| 17:29.02 | *** join/#brlcad anuragmurty1 (~anurag@14.139.128.12) | |
| 17:30.00 | *** join/#brlcad malav (~Anoop@223.189.48.176) | |
| 17:33.43 | jordisayol | starseeker: brlcad.spec is generated in sh/make_rpm.sh (190:264) |
| 17:33.56 | *** join/#brlcad anuragmurty (~anurag@14.139.128.12) | |
| 17:37.01 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 17:37.35 | brlcad | jordisayol: the main difference would be translating everything that the shell script is doing to cmake/cpack syntax |
| 17:38.03 | brlcad | probably could even make it be just one or two cmake macros that do all the work, nearly the same work that is being done now, just without /bin/sh |
| 17:38.55 | brlcad | it wouldn't replace it until it's equivalent, but it might be easier to maintain in the long run since we could hook it in with the rest of the build logic more closely |
| 17:39.25 | jordisayol | brlcad: understood and agree |
| 17:40.39 | ``Erik | does rpm allow 'or' in the dependancy specifications? that'd allow a workaround to the nomenclature issue |
| 17:42.34 | jordisayol | ``Erik: if I don't misremembering, it's not allowed |
| 17:43.09 | jordisayol | deb allows this |
| 17:50.37 | *** join/#brlcad yukonbob (~bch@methodlogic.net) | |
| 17:50.41 | yukonbob | hello, #brlcad |
| 17:51.33 | _fkr | Word. |
| 17:54.47 | jordisayol | ``Erik: BTW I use rpmbuild command to generate rpm packages. rpmbuild auto-detects the dependencies, and they change depending on host system you're building it |
| 17:57.24 | *** join/#brlcad Al_DC_Best (~Al_Da_Bes@elvyn-248-109.halls.student.lut.ac.uk) | |
| 17:59.01 | jordisayol | with |
| 17:59.01 | jordisayol | $ rpm -qpR brlcad-7.20.6-0.fedora.i386.rpm |
| 17:59.01 | jordisayol | You'll get rpm requiring list |
| 18:10.18 | jordisayol | I just add "xorg-x11-fonts-ISO8859-1-75dpi" dependency on fedora because is needed by archer (somebody in fedora decided to remove it as installed by default) |
| 18:16.46 | brlcad | malav: what are you working on? |
| 18:17.49 | brlcad | ksuzee: crdueck: you both have patches pending some response |
| 18:17.55 | brlcad | got to a lot of them over the weekend |
| 18:20.06 | ksuzee | brlcad: thanks, Sean. I've already correct a couple of them |
| 18:21.47 | malav | src/shapes |
| 18:21.58 | malav | trying to write a patch |
| 18:23.37 | jordisayol | starseeker: well, I've installed last opensuse rpm into fedora without problems... :-/ |
| 18:24.03 | jordisayol | starseeker: I can assure you that this was not been like this in the past |
| 18:37.24 | brlcad | malav: trying? :) do you have a goal? |
| 18:37.46 | brlcad | ksuzee: okay -- you had several patches, and I think they all had some issue |
| 18:38.13 | brlcad | so I was just noting that there are more pending since patches are #1 priority |
| 18:41.06 | malav | I should say working |
| 18:41.25 | malav | I am going through code |
| 18:41.32 | ksuzee | my are #5 only) I corrected two of them yesterday |
| 18:42.38 | malav | for example there is a function in fence.c createWire |
| 18:43.10 | malav | so i was looking if there is any similarity between this function and wire.c |
| 18:43.20 | malav | or they are completely different |
| 18:45.06 | *** join/#brlcad yukonbob (~bch@methodlogic.net) | |
| 18:52.11 | malav | And also while converting main functions into library functions passing of parameters need to be taken care of |
| 19:06.34 | CIA-65 | BRL-CAD: 03n_reed * r50741 10/brlcad/trunk/src/other/step/src/cleditor/ (STEPfile.cc STEPfile.h STEPfile.inline.cc): Have STEPfile::schemaName return std::string instead of writing char* arg. SCL git b8fc557. |
| 19:11.41 | *** join/#brlcad jbschw (~jbschw@ool-4355ee10.dyn.optonline.net) | |
| 19:30.45 | CIA-65 | BRL-CAD: 03crdueck * r50742 10/brlcad/trunk/src/mged/animedit.c: removed unused 'joint test' subcommand |
| 19:35.51 | brlcad | Maloeran: they are completely different |
| 19:36.00 | brlcad | oops, Maloeran -- never mind :) |
| 19:36.09 | brlcad | malav left |
| 19:40.50 | CIA-65 | BRL-CAD: 03crdueck * r50743 10/brlcad/trunk/src/mged/animedit.c: removed references to f_jtest(), fixing r50742 |
| 19:46.36 | crdueck | <PROTECTED> |
| 19:55.21 | brlcad | it's not so much a preference as it is a different style of collaboration |
| 19:55.56 | _fkr | Perhaps there were issues with CVS that SVN helped to fix? |
| 19:56.30 | *** join/#brlcad anuragmurty (~anurag@14.139.128.12) | |
| 19:56.33 | brlcad | if you perform centralized development with integrated development, using a distributed system only adds a little bit of complexity with mostly subjective technical gain |
| 19:57.26 | brlcad | you also tend to get isolated sandbox activity which makes integration that much more work, with a distributed system |
| 19:57.53 | brlcad | it's fine when you have a LOT of devs and can spend more time on integration, linux kernel being a prime example |
| 19:58.14 | crdueck | brlcad: good point, i wasnt thinking about brlcad originally being developed by the US military |
| 19:58.40 | brlcad | for small teams, it tends to lead towards antisocial development behaviors where problems are addressed later rather than sooner and people work together |
| 19:59.15 | brlcad | that has little to do with it really, the military origins |
| 19:59.29 | brlcad | it's more about the size of the dev team and style of interaction desired |
| 20:00.17 | _fkr | So the size of the dev team is considered to be a small one? |
| 20:00.31 | brlcad | relatively speaking, yes |
| 20:00.54 | brlcad | it's a communication network scalability problem |
| 20:01.56 | brlcad | you have N nodes and a desire to communicate a change to some number of nodes equal or near N |
| 20:02.06 | _fkr | So what has real life experience shown so far, afer the move? Did it help to change things in the wishful direction? Or perhaps it didnt help to change much? |
| 20:02.31 | brlcad | that obviously increases exponentially and at some point becomes more of a burden than a savings, a productivity tipping point |
| 20:02.51 | brlcad | _fkr: after what move? we didn't move to git |
| 20:03.04 | _fkr | CVS to SVN |
| 20:03.14 | brlcad | that was more technical than architectural |
| 20:03.25 | brlcad | they're both centralized |
| 20:03.47 | brlcad | svn fixes a lot of the technical problems of cvs, so that's a really obvious migration |
| 20:04.41 | brlcad | if you have very infrequent or one-way commits, there's not really a compelling argument of centralized versus distributed |
| 20:05.04 | brlcad | gits overhead is offset with other efficiencies in merging and offline commits, for example |
| 20:05.42 | brlcad | svn at low volume is conflict free and simple with infrequent commits too, no favor either way |
| 20:06.25 | brlcad | once you start to collaborate and coordinate development, your commit and communication architecture begin to matter substantially |
| 20:07.17 | brlcad | crdueck: so using git, for example, you would not necessarily have had to learn our style or worry about breaking the build |
| 20:07.34 | brlcad | if that's something we wanted, we just as easily could have set everyone up in their own branch |
| 20:08.16 | brlcad | it's an issue *because* it's something we want all developers to be cognisent of sooner rather than later, regardless of revision control system |
| 20:08.56 | brlcad | akin to requiring a push/pull with every git commit, still would be a problem |
| 20:10.53 | _fkr | I think it's reasonable if people have their own branches and hacks and stuff on their own machine and then commit to some main/central branch as seems to be reasonable by the team. |
| 20:11.41 | brlcad | in my experience, the productivity threshold for distributed commits is somewhere around 40-80 *active* developers, depending on the velocity of source code changes dependent on other code |
| 20:12.26 | brlcad | _fkr: sure, reasonable -- but then they can do that anyways |
| 20:12.52 | brlcad | the question is WHEN they communicate that change to other devs |
| 20:13.46 | brlcad | for GSoC, for example, we track progress daily for a variety of reasons and needs, so they're required to be committing/merging daily |
| 20:14.25 | brlcad | with that setup, committing to your own branch/repo offers nothing better than a local backup and at an overhead cost |
| 20:17.16 | *** part/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 20:17.20 | brlcad | we've had devs try that before, committing to their own git-svn repo, only to quickly realize it's pure overhead when you need to integrate that frequently |
| 20:17.45 | _fkr | The communication problem. I think that's just a completely separate thing from a versioning system. Wheteher to use SVN or whatever. Communication is important and there are lots of tools and stuff for that. |
| 20:18.07 | brlcad | except it's not |
| 20:18.11 | brlcad | a commit is a communication |
| 20:18.46 | brlcad | when it comes to integration, the smaller the better as they're faster and easier to review and integrate |
| 20:19.45 | _fkr | Someone might get an half-baked idea, keep it in their system, go on a vacation for a month and not tell anyone... later e comes back and tries to remember eirself, what it was about in order to explain others... |
| 20:20.37 | brlcad | exactly, that actually happens more often with distributed systems because no communication is required |
| 20:20.39 | _fkr | Keeping things simple... |
| 20:20.43 | _fkr | Less parts to break |
| 20:21.04 | brlcad | with frequent commits, that half-baked idea is called out within the first couple commits |
| 20:21.16 | brlcad | they don't waste their time now and others later |
| 20:21.35 | brlcad | you literally don't allow people to be hermits like that |
| 20:22.19 | _fkr | People who spend a lot of time behind keyboard lose social skills too and might not want to interact with humans too much, specially face-to-face... |
| 20:22.48 | brlcad | and that's supposed to be a good thing? encouraged? I think not (as does most of the open source industry) |
| 20:23.04 | _fkr | Also the lazyness factor of writing a short message or a few lines about a change or commenting code so others could understand it more quickly and so on. |
| 20:23.45 | brlcad | that's why centralized is often favored, due to that communication requirement it implies on a technical level |
| 20:23.54 | _fkr | I'm not saying it's a good thing. Just trying to understand reality and the problem. Hard to tackle a problem, if you have not exactly figured out, what it is or where to look for it |
| 20:24.09 | brlcad | if you have so many devs that you don't care what most of the other devs are doing, then they can be hermits and only communicate at specific points/levels in the group |
| 20:24.17 | brlcad | again, linux kernel being a prime example |
| 20:24.40 | _fkr | Learn from other peoples mistakes... |
| 20:24.42 | brlcad | that's where my point about it being dependent on the size of active devs |
| 20:25.08 | brlcad | at some point, the communication switches from being informative to being "noise" that slows the group down |
| 20:26.03 | brlcad | lazyness factor is not addressed by centralized or distributed, that's a social problem that is fought by social pressures |
| 20:27.08 | brlcad | code that survives must be understood by other developers |
| 20:27.40 | brlcad | someone committing a change that is not understood by others is a net negative in the long run, so laziness on their part costs the project |
| 20:28.53 | _fkr | Sure, the more people, the more diff opinions... that's how it's always been and it's like that in most areas of life. Get married and you'll have at least 2 diff opinions in your small familiy. Get kids and have even more... That's just the way it is, but it just comes down to emotional intelligence of the participants whether there will be effective team-work or not. |
| 20:29.54 | _fkr | You have coding and committing rules of some sort, they can be helpful in eliminating that kind of situation. |
| 20:30.29 | _fkr | some just are not team-workers and that should be taken in to consideration... |
| 20:30.59 | _fkr | they might become team-workers later |
| 20:31.48 | brlcad | that's the point, though (or at least one of them) |
| 20:32.26 | brlcad | if they're not a team worker, they're not well suited (yet) to open source development because it's an inherently community-oriented development model |
| 20:32.45 | _fkr | One needs to accept that things will never be ideal anyways and not let that distract, but instead move ahead even if it seems difficult. |
| 20:33.00 | brlcad | and their antisocial tendencies don't just affect them, they slow down the project because of the pains others have to go through in the long run |
| 20:34.05 | brlcad | i'm not sure that's a useful statement as it merely implies inaction at some subjective level of difficulty |
| 20:34.28 | _fkr | Exactly, and that means someone needs to understand that and filter accordingly in order to improve the overall quality. Open communication about concerns might help too, because people are not mind readers and someone might not be aware that they are dragging others down... |
| 20:34.56 | brlcad | I am perfectly willing to accept that not everyone is a team player and committing frequently and communicating changes will be difficult for them |
| 20:35.00 | brlcad | that's their cost of participation |
| 20:35.22 | brlcad | pushing that cost onto other developers is fundamentally unacceptable |
| 20:35.26 | *** join/#brlcad anuragmurty (~anurag@14.139.128.12) | |
| 20:36.17 | *** join/#brlcad anuragmurty (~anurag@14.139.128.12) | |
| 20:36.44 | _fkr | What have you done to change that situation? Have you at least expressed your thoughts about this issue in some newcomer-intro or coding-rules or whatever document new people are supposed to read? |
| 20:36.56 | brlcad | contributions are not worth integrating if the contributing developer is not willing to communicate and collaborate throughout development |
| 20:37.08 | brlcad | absolutely, in several places and forms |
| 20:37.36 | brlcad | and in architectural decisions like using a centralized repository and setting expectations consistently |
| 20:37.56 | ``Erik | puts his halfbacked ideas straight into svn, no biggie :D |
| 20:38.27 | *** join/#brlcad anuragmurty1 (~anurag@14.139.128.12) | |
| 20:39.41 | _fkr | Things are good then with brl-cad development, I assume? |
| 20:39.48 | brlcad | anyways, it's mostly an issue for people that are new to open source, corporate developers being some of the worst since they tend to be more entrenched having developed for decades without having to be talk about what they're doing or why |
| 20:39.49 | *** join/#brlcad anuragmurty (~anurag@14.139.128.12) | |
| 20:39.52 | brlcad | or students only used to doing homework assignments |
| 20:40.44 | brlcad | _fkr: just about any developer would be biased to answer that, no? of course I tend to believe so and our year-over-year increasing development activity seems to concur |
| 20:41.05 | brlcad | ohloh stats ftw ;) |
| 20:41.20 | ``Erik | svn is good for BRL-CAD right, the only big where git would be substantially better is if someone were coding on an airplane or other place without internet connectivity *shrug* and in that case, git init . and do git diffs to build a patch set for svn when ya land O.o |
| 20:41.24 | _fkr | Corporate people always think that this kind of information usually costs a lot of money. I can not just tell you that for free... |
| 20:41.24 | *** join/#brlcad anuragmurty1 (~anurag@14.139.128.12) | |
| 20:41.30 | ``Erik | s/right/& now/ |
| 20:41.51 | brlcad | at least until svn folks finish implementing support for offline commits |
| 20:42.27 | *** join/#brlcad anuragmurty2 (~anurag@14.139.128.12) | |
| 20:42.48 | brlcad | there's no inherent reason you can't do offline commits with a centralized repo, just wasnt' something someone thought to do way back when (what's offline?) |
| 20:42.56 | ``Erik | thinks the secrecy behavior may be less about team playing and protecting assets tahn it is about fear... a commit that's not absolutely perfect and polished is skeery for some folk |
| 20:44.12 | brlcad | same people have trouble with the basic concept of tweeting or posting fb status updates to actually convey anything important |
| 20:44.34 | brlcad | you don't belabor it, you just do it and move on quickly to the next thing (and everyone has been informed) |
| 20:45.11 | _fkr | for not polished or tested code there can be a -current or -test or some similar branch... Just to get the idea quickly around and see what others think. |
| 20:45.12 | brlcad | and try not to make the post be about you dumping that burrito from last night |
| 20:45.37 | *** join/#brlcad anuragmurty (~anurag@14.139.128.12) | |
| 20:46.37 | brlcad | that is basically what trunk is defined as, just making sure that stuff still compiles (which everyone should be doing all the time anyways) |
| 20:47.59 | brlcad | and that's not even "compiles for everybody" |
| 20:48.52 | brlcad | anuragmurty: your svn client is crap |
| 20:49.09 | brlcad | what is that? |
| 20:49.27 | brlcad | blah s/svn/irc/ |
| 20:49.58 | _fkr | I can understand the polishing and perfectionism thing too.. I guess there are people like that who like to polish and polish and polish and think and analyze and polish a bit more before putting anything to use. Hard to break habits. |
| 20:51.25 | ``Erik | Le mieux est l'ennemi du bien (voltaire, best is the enemy of good) |
| 20:51.54 | brlcad | you can polish and polish and polish, just commit every time you save the file :) |
| 20:53.36 | _fkr | noo, but others would see my possibly imperfect creation. Everytime I commit, I find a spot that needs cleaning and then I just bang my head against the wall and beat myself and am embarrassed, which makes it even harder to concentrate on other issues... |
| 20:53.52 | _fkr | laughs evilly |
| 20:57.55 | _fkr | At least that's how I _think_ some might think. Humans are the same, but still a bit different. How to motivate people to put their issues aside for a moment and commit to team-work for a moment? I guess that's a nice question. |
| 21:01.41 | Stattrav_ | ``Erik: didn't people who specifically wanted local commits already move to git ? |
| 21:23.29 | brlcad | Stattrav_: I'd love to have local commits |
| 21:23.41 | brlcad | at least, offline commits |
| 21:23.43 | brlcad | but not at the expense of communication :) |
| 21:24.29 | brlcad | an auto-commit-push setup does that, but then not really any different than svn other than some could weasel out of the push |
| 21:25.10 | brlcad | and that's the point, you can't and that's a good thing |
| 21:25.15 | brlcad | (at least, worth the cost of not being able to commit offline) |
| 21:28.53 | brlcad | _fkr: one of the best ways to break a habit is to start a new one |
| 21:28.55 | brlcad | which is exactly what we require of new devs not accustomed to open source collaboration |
| 21:29.24 | _fkr | couldnt you set up your own CVS/SVN server at home or something like that and then play there with your own branches and what not? But yeah, perhaps it's better if it's not too easily done. |
| 21:29.38 | Stattrav_ | brlcad: so is svn planning to have offline commits or that was just a wishlist ? |
| 21:31.04 | _fkr | There are ways anyways and people who want something like that can figure out their own solution. |
| 21:35.21 | _fkr | And what if someone had a similar idea and already made similar changes. You are offline and doing work that has been done. Need to communicate someohow. |
| 21:39.54 | _fkr | What is the offline commit's point? As soon as I am on-line - synchronize automatically? I think it could be dangerous. If one was away for a while, one should check what has changed first and then think again whether it's still a good idea to commit. No? |
| 21:44.21 | _fkr | Perhaps we just have different ideas, what an offline commit means? |
| 21:53.01 | _fkr | I'll rest now for a while. |
| 21:59.11 | *** join/#brlcad ksuzee (~ksuzee91@193.151.107.42) | |
| 21:59.57 | brlcad | Stattrav_: they're working towards that, yes |
| 22:00.35 | brlcad | it was actively being worked on a year or so ago, but then they've been spending a lot more time on improving merging and commit metadata |
| 22:02.33 | brlcad | looks like their roadmap lists 1.9 as having some of the starting infrastructure for it with checkpointing |
| 22:08.54 | brlcad | the issue of what it means to "commit offline" is also why svn is implementing checkpointing first, that's much more straightforward -- it's basically local undo |
| 22:09.32 | brlcad | which you could then replay and commit as one or individually later when you're back online |
| 22:17.09 | CIA-65 | BRL-CAD: 03crdueck * r50744 10/brlcad/trunk/src/mged/animedit.c: 'joint holds' no longer crashes MGED, reports error message instead. still doesnt work properly though |
| 22:17.51 | Stattrav_ | nice |
| 22:17.52 | *** join/#brlcad yiyus (1242712427@je.je.je) | |
| 22:23.52 | brlcad | crdueck: if it's NULL, printing it via Tcl_AppendResult() won't do anything useful will it? :) |
| 22:24.13 | brlcad | next to try is the 'list' subcommand |
| 22:24.16 | CIA-65 | BRL-CAD: 03n_reed * r50745 10/brlcad/trunk/src/other/step/src/ (3 files in 3 dirs): Remove a few unnecessary extern declarations. SCL git aef6e73, 5c8c5aa, 15f9c40. |
| 22:24.46 | brlcad | if that also crashes with a similar failure, it might be more obvious what is going wrong during load |
| 22:25.38 | crdueck | brlcad: i wasnt sure how Tcl_AppendResult() worked, I couldnt find a helpful function definition so i just took from another use of Tcl_App... in the function. |
| 22:26.38 | crdueck | the list command works fine, its printing all the joints defined in art.j |
| 22:32.21 | crdueck | from what i gather, mged is calling f_jhold, f_jhold is creating a hold struct but i cant see if it initializes any of its fields, then a hold_point struct is passed from the bad hold struct to hold_point_location where it crashes. to me it looks like the problem starts in f_jhold. |
| 22:32.45 | ``Erik | would imagine that 'offline commit' evaluates to 'dvcs'... |
| 22:41.18 | CIA-65 | BRL-CAD: 03crdueck * r50746 10/brlcad/trunk/src/librt/primitives/tor/tor.c: adds surface area function to tor |
| 22:43.20 | brlcad | crdueck: excellent analysis of the crash then, and it sounds like you're probably right on the mark |
| 22:43.32 | brlcad | more importantly, if list works, you have a way to test your lex change now |
| 22:43.54 | brlcad | you can apply your patch, recompile, see if list is the same |
| 22:44.12 | brlcad | if it is, that's a 'good enough' sanity check that your cleanup didn't introduce a subtle parsing error |
| 22:45.12 | crdueck | will do. also, should i 'bundle' commits related to the same thing (like adding a volume and surface area function to a primitive) into one commit, or commit them seperately? |
| 22:45.19 | brlcad | crdueck: when you commit -- be sure to note your sf patch #, your name as the submitter, and the patch title along with any other details you care |
| 22:46.03 | brlcad | if you can logically break up a change into separate commits, that's usually best |
| 22:46.31 | brlcad | I've yet to have to tell someone that they're committing too small or too frequently |
| 22:46.46 | *** join/#brlcad louipc (~louipc@archlinux/fellow/louipc) | |
| 22:47.36 | brlcad | just make sure the commit message summarizes, justifies, explains, or otherwise documents what the code itself doesn't obviously say |
| 22:51.18 | CIA-65 | BRL-CAD: 03crdueck * r50747 10/brlcad/trunk/src/ (libbu/fgets.c libbu/lex.c librt/primitives/tor/tor.c): adds volume function to tor |
| 22:51.56 | crdueck | oh no, apologies. looks like i'll be taking a look at the "ammending commits" wiki page that just went up :( |
| 22:58.42 | CIA-65 | BRL-CAD: 03crdueck * r50748 10/brlcad/trunk/src/libbu/ (fgets.c lex.c): accidently added to many files in r50747 |
| 22:59.18 | crdueck | well, at least I've learned some new features of svn today haha |
| 23:02.00 | brlcad | heh |
| 23:03.47 | CIA-65 | BRL-CAD: 03crdueck * r50749 10/brlcad/trunk/src/librt/primitives/tor/tor.c: adds centroid function to tor |
| 23:21.50 | *** join/#brlcad stas (~stas@82.137.13.214) | |
| 23:22.48 | *** part/#brlcad ksuzee (~ksuzee91@193.151.107.42) | |
| 23:57.27 | CIA-65 | BRL-CAD: 03tbrowder2 * r50750 10/brlcad/trunk/ (6 files in 2 dirs): rename vls regression script and test_vls to vls_vprintf and test_vls_vprintf,respectively, to reflect true scope of this regression test |
| 23:58.16 | CIA-65 | BRL-CAD: 03tbrowder2 * r50751 10/brlcad/trunk/ (regress/vls.sh src/libbu/test_vls.c): old files disappear |
