| 00:29.23 | *** join/#brlcad bhinesley (~bhinesley@adsl-99-104-170-214.dsl.bkfd14.sbcglobal.net) | |
| 01:11.40 | *** join/#brlcad crazy_imp (~mj@a89-182-208-255.net-htp.de) | |
| 03:26.39 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 03:33.43 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177680483.dsl.bell.ca) | |
| 04:36.10 | *** join/#brlcad stevegt` (~stevegt@cislunar.TerraLuna.Org) | |
| 07:31.23 | *** join/#brlcad Stattrav (~Stattrav@122.172.5.31) | |
| 07:31.23 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:49.21 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 09:09.48 | *** join/#brlcad mafm (~mafm@132.Red-81-35-69.dynamicIP.rima-tde.net) | |
| 09:25.05 | CIA-105 | BRL-CAD: 03jordisayol * r44293 10/brlcad/trunk/sh/ (make_deb.sh make_rpm.sh): Properly handle errors during GNU/Linux packages building. |
| 13:09.49 | dloman | yawns |
| 13:10.03 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 13:22.32 | brlcad | resists the yawn |
| 13:23.00 | brlcad | totally bummed though |
| 13:23.03 | brlcad | no furlough |
| 13:23.33 | dloman | had two big brown eyes staring at me starting at 0100. Youngest wouldn't sleep! |
| 13:23.59 | dloman | heh, speak for your self. I still have a paying job because of 'no furlough' ;) |
| 13:37.38 | ``Erik | vacation woulda been nice O.o |
| 13:37.57 | dloman | still a chance for it :) |
| 13:37.59 | ``Erik | brlcad: migration? accounts? |
| 13:54.32 | dloman | brlcad: was looking at VLB over the weekend and saw that a bu_vlb_write() call could potentially trigger a bu_realloc(). In order to know this ahead of time, the caller would need to know both the vlb's 'nextByte' and 'capacity'. bu_vlb_buflen serves to get the 'nextByte' but there's nothing for capacity. I was thinking about adding a bu_vlb_capacity() and/or bu_vlb_remaining() functions. Comments/concerns/tips ? |
| 13:58.40 | ``Erik | the struct is public and the math is trivial O.o |
| 14:00.00 | ``Erik | iirc, vlb's default to 4k 'chunks', so that's a straight up page mapping, quick and cheap on linux (not on fbsd/mac) |
| 14:01.20 | brlcad | dloman: sounds good to me |
| 14:01.36 | brlcad | should make the function name mirror the vls api, though |
| 14:01.46 | dloman | nods |
| 14:04.51 | brlcad | very curious that you'd need to know the size, though -- the mechanism by which the bytes are stored is supposed t be a black box |
| 14:05.14 | brlcad | could be a bu_list of individual bytes, for example, or some c++ construct or a static buffer |
| 14:05.33 | dloman | was looking at vlb_write and saw that there is a possiblity of a realloc |
| 14:05.55 | dloman | and without knowing capacity a head of time, you'll never know if that realloc will happen or not. |
| 14:06.01 | brlcad | so? |
| 14:06.07 | brlcad | anything that adds bytes is going to be a potential realloc |
| 14:06.18 | brlcad | part of the black box |
| 14:06.36 | dloman | would exposing the capacity break the black box mindset? |
| 14:06.54 | brlcad | pretty much |
| 14:07.04 | dloman | okie |
| 14:07.15 | brlcad | still, what does the realloc matter? |
| 14:07.17 | ``Erik | I think it's more "why do you care?" O.o reallocs aren't terribly slow on occasion |
| 14:07.27 | ``Erik | premature optimization? O.o |
| 14:08.14 | dloman | just trying to think ahead ;) |
| 14:08.37 | brlcad | or "a little knowledge is dangerous" |
| 14:09.05 | brlcad | std::string foo = "hello"; foo += "world"; may or may not cause a realloc too |
| 14:09.16 | brlcad | you don't know, shouldn't care -- vlb is the same |
| 14:09.23 | dloman | okie |
| 14:10.28 | ``Erik | (no forward motion on the server? I'm out today, thought maybe I could start a system update and get some stuff installed) |
| 14:10.59 | dloman | is bug fixing and generally de-stupifying things. |
| 14:12.44 | brlcad | ``Erik: noted, i'll create your account |
| 14:13.01 | brlcad | context switch thrashing a bit at the moment |
| 14:19.49 | brlcad | ``Erik: gmail |
| 14:20.45 | brlcad | was leaving those default passwords until accounts got migrated |
| 14:22.27 | brlcad | so the coverity scan is really frelling awesome |
| 14:33.41 | CIA-105 | BRL-CAD: 03starseeker * r44294 10/geomcore/trunk/src/libgvm/ (files.c objects.c): Hrm. Something strange - simply calling gvm_obj_in_model was enough to cause a crash - reorganizing the initializations in gvm_object_in_model was enough to make things work. |
| 15:03.58 | brlcad | if anyone is interested in actually working on fixing coverity bugs, let me know with an e-mail address to provide so I can get an account created (let me know via e-mail or PM) |
| 15:05.00 | brlcad | please don't bother if you're just interested or want to peek at results, rather not waste david's time |
| 15:05.09 | brlcad | or mine for that matter |
| 15:05.33 | brlcad | here's what some of the results look like, though: |
| 15:06.17 | brlcad | http://brlcad.org/tmp/cov1.png <-- detected potential null dereference |
| 15:06.31 | brlcad | http://brlcad.org/tmp/cov2.png <-- security issues |
| 15:07.20 | brlcad | http://brlcad.org/tmp/cov3.png <-- more elaborate (and awesome) detection of potentially uninitialized data being used |
| 15:07.44 | dloman | neato. |
| 15:07.47 | dloman | that a pay service? |
| 15:07.54 | brlcad | just a sample of the 2k or so issues reported |
| 15:08.12 | brlcad | it's paid for, but not something we're paying for |
| 15:08.52 | brlcad | DHS funded an initiative a few years ago to evaluate (and improve) security of open source software |
| 15:09.03 | dloman | =D |
| 15:09.04 | dloman | nice |
| 15:09.40 | dloman | so its "free" =D |
| 15:10.47 | brlcad | I applied and we were one of the first to get added to the scan ladder (when there were only a couple dozen being scanned), but our scan (of an old version) got stuck on a build failure in src/other |
| 15:11.05 | brlcad | wasn't fully resolved until the past friday |
| 15:11.55 | dli | brlcad, I can have a look on the coverity bugs, not sure how hard it is to fix them, without collateral damage at least |
| 15:12.28 | dli | brlcad, do you have some examples for me to digest |
| 15:12.39 | brlcad | dli: just screenshotted three :) |
| 15:13.36 | dli | brlcad, too bad. :( no text report? |
| 15:14.04 | brlcad | dli: what do you mean? |
| 15:14.41 | brlcad | there's a full-blown website around the report generated, pretty sure there are export options too -- but the website lets you manage the issues so you know which ones are fixed and which are not |
| 15:15.10 | brlcad | dli: can you not view images at the moment or something? |
| 15:15.39 | dli | brlcad, of course, I can view images |
| 15:16.26 | brlcad | then what's the "too bad"? |
| 15:17.34 | dli | brlcad, I expected a list with file locations, line numbers, and explanation of findings, etc. |
| 15:20.17 | dli | http://scan.coverity.com/all-projects.html |
| 15:20.26 | dli | not found |
| 15:21.28 | brlcad | dli: it has that list of files, explanations and a lot more |
| 15:21.36 | brlcad | the screenshots show three specific bugs |
| 15:22.37 | brlcad | I can dump out the various reports (there are many, all configurable) as csv, but that's not really effective for fixing them collaboratively |
| 15:22.49 | dli | brlcad, found, 178,135 lines, that will take ages to fix :( |
| 15:23.10 | brlcad | dli: that's the stalled scan |
| 15:23.18 | brlcad | that webpage hasn't been updated in years |
| 15:23.39 | brlcad | it found 690,667 lines |
| 15:23.41 | dli | brlcad, so, I have to sign in to get updated |
| 15:24.00 | brlcad | that's lines of code analyzed, not # issues |
| 15:24.15 | brlcad | it found 1892 issues, 700 of which are like cov2.png |
| 15:24.24 | CIA-105 | BRL-CAD: 03starseeker * r44295 10/geomcore/trunk/ (4 files in 2 dirs): Ah, there we go - got changes committed to the repository. Approaching full parity with the old svnTest example. |
| 15:25.05 | dli | brlcad, a link for cov2.png? |
| 15:25.26 | brlcad | points up |
| 15:26.45 | brlcad | those where the screenshots I mentioned |
| 15:27.50 | dli | brlcad, to fix like sscanf(), we use atof(), etc., right? |
| 15:33.13 | brlcad | dli: it depends, strtol/strtod with manual string parsing or regexp parsing are generally more robust to sanitizing input |
| 15:33.55 | starseeker | brlcad: in that case, should we pre-package some regex logic for the common parsing cases? |
| 15:33.56 | brlcad | preferred over the ato*() family of functions because they don't report error |
| 15:35.41 | dli | brlcad, but the idea is to replace all sscanf(), rather than trying to keep sscanf() safe by limiting buffer size, etc |
| 15:35.44 | brlcad | starseeker: bu routines that get values from strings would be useful (however the underlying mechanism does it) |
| 15:36.41 | brlcad | dli: to best solve the problem, yes |
| 15:36.56 | brlcad | the quickest solution is to just add precision specifiers like the comment states |
| 15:37.33 | brlcad | depending on how many there are, that could be a first step or could be skipped in leu of an API solution |
| 15:39.47 | dli | brlcad, I think I can help fixing the issues here |
| 15:40.12 | brlcad | e-mail me a username and an e-mail to give the coverity guys |
| 15:41.18 | dli | brlcad, using the sean address in topic? |
| 15:43.15 | dli | brlcad, sent |
| 15:45.37 | brlcad | thx |
| 15:47.50 | dli | brlcad, I will ask about ideas before actually fixing anything, my biggest fear is still the collateral damages :) |
| 15:48.19 | brlcad | okay, no worries |
| 15:49.25 | brlcad | i'll mostly be concerned with people actually using the coverity website when bugs are fixed so we don't get people wasting time looking into issues that have already been solved |
| 15:49.35 | brlcad | so using the various status markers they provide |
| 15:49.41 | brlcad | inspected, uninspected, fixed, etc |
| 15:51.31 | dli | brlcad, right, with so many lines to check, need an way to assign/partition |
| 15:54.07 | CIA-105 | BRL-CAD: 03starseeker * r44296 10/geomcore/trunk/src/libgvm/gvm.h: Nevermind these functions - handled in a couple for loops. Add them later if needed. |
| 15:54.07 | brlcad | nods |
| 15:54.41 | brlcad | some are downright trivial to fix, some are downright tricky logic |
| 16:09.00 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 16:26.24 | CIA-105 | BRL-CAD: 03starseeker * r44297 10/geomcore/trunk/src/libgvm/ (files.c gvm.h objects.c): Clear out a few more functions of dubious utility, assing some names to the commit actions. |
| 16:37.35 | CIA-105 | BRL-CAD: 03starseeker * r44298 10/geomcore/trunk/tests/func/gvmtest/main.c: |
| 16:37.35 | CIA-105 | BRL-CAD: Add a test to create an empty repo. May need to add one additional parameter to |
| 16:37.35 | CIA-105 | BRL-CAD: all these functions - the ability to pass a local subpool (presumably as a void |
| 16:47.56 | CIA-105 | BRL-CAD: 03Sean 07http://brlcad.org * r2821 10/wiki/Main_Page: add a section on code cleanup |
| 16:55.19 | CIA-105 | BRL-CAD: 03Sean 07http://brlcad.org * r2822 10/wiki/Code_Cleanup: stub in initial page, link to HACKING |
| 17:01.01 | CIA-105 | BRL-CAD: 03Sean 07http://brlcad.org * r2823 10/wiki/Code_Cleanup: coverity section |
| 17:05.19 | CIA-105 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded "[[Image:CoverityExample1.png]]": Example Coverity scan issue showing a potential (albeit unlikely) NULL dereference |
| 17:25.24 | CIA-105 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded "[[Image:CoverityExample2.png]]": Coverity analysis showing secure coding practice suggestions |
| 17:27.48 | CIA-105 | BRL-CAD: 03starseeker * r44299 10/geomcore/trunk/src/libgvm/objects.c: Er, oops - need a textdelta if we're going to add content... |
| 17:27.49 | CIA-105 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded "[[Image:CoverityExample3.png]]": Coverity analysis showing an elaborate detection of a variable being used that was potentially uninitialized |
| 17:28.47 | CIA-105 | BRL-CAD: 03Sean 07http://brlcad.org * r2827 10/wiki/Code_Cleanup: link in the images and site |
| 17:29.55 | CIA-105 | BRL-CAD: 03starseeker * r44300 10/geomcore/trunk/src/libgvm/objects.c: Use the gvm_info_clear_objects function |
| 17:31.18 | CIA-105 | BRL-CAD: 03Sean 07http://brlcad.org * r2828 10/wiki/Code_Cleanup: add a section on code reduction and using simian |
| 17:31.19 | CIA-105 | BRL-CAD: 03Sean 07http://brlcad.org * r2829 10/wiki/Code_Cleanup: swap the order so lays out better |
| 17:33.14 | CIA-105 | BRL-CAD: 03Sean 07http://brlcad.org * r2830 10/wiki/Code_Cleanup: add an example of the output |
| 17:35.46 | CIA-105 | BRL-CAD: 03Sean 07http://brlcad.org * r2831 10/wiki/Code_Cleanup: break the long line |
| 17:46.46 | CIA-105 | BRL-CAD: 03Sean 07http://brlcad.org * r2832 10/wiki/Code_Cleanup: add one more section on strict compilation, yay TOC |
| 17:50.47 | CIA-105 | BRL-CAD: 03davidloman * r44301 10/geomcore/trunk/CMake/FindCppUnit.cmake: Check in a quick n dirty cmake find module for finding CppUnit |
| 17:53.48 | CIA-105 | BRL-CAD: 03davidloman * r44302 10/geomcore/trunk/ (4 files in 4 dirs): Setup cmake to find CppUnit if the UnitTests are enabled. Split out subdirectory addition for Functional and Unit test dirs. Stub in unit test dir CMakeList.txt |
| 18:06.05 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177680483.dsl.bell.ca) | |
| 18:10.32 | *** join/#brlcad Stattrav (~Stattrav@117.192.144.22) | |
| 18:10.32 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:04.39 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177680483.dsl.bell.ca) | |
| 19:14.17 | *** join/#brlcad mafm (~mafm@132.Red-81-35-69.dynamicIP.rima-tde.net) | |
| 19:27.46 | starseeker | hah - Manassas, Virginia |
| 19:43.47 | CIA-105 | BRL-CAD: 03davidloman * r44303 10/geomcore/trunk/tests/unit/ (4 files in 2 dirs): Wire in CppUnit to cmake build. Added a sample cmake unit test that will eventually be ByteBuffer's Unit Test. |
| 19:47.33 | CIA-105 | BRL-CAD: 03davidloman * r44304 10/geomcore/trunk/ (3 files in 2 dirs): Implement ByteBuffer. Combines the functionality of ByteArray and DataStream, since those were mostly redundant. ByteBuffer is backed by a bu_vlb and, at this point, is completely untested. |
| 19:57.19 | CIA-105 | BRL-CAD: 03starseeker * r44305 10/geomcore/trunk/src/libgvm/TODO: Add a TODO for libgvm |
| 20:16.54 | ``Erik | hrm? |
| 20:26.21 | starseeker | ``Erik: Tcl/Tk conference this year is in Virginia |
| 20:30.30 | ``Erik | ah, roger |
| 20:40.14 | *** join/#brlcad Stattrav (~Stattrav@117.192.144.22) | |
| 20:40.14 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:41.17 | brlcad | perfect nearby location for a presentation or three |
| 20:44.34 | brlcad | ``Erik: login worked? |
| 21:03.31 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 21:05.53 | brlcad | starseeker: did you make red delete or keep the original if the user edits the object name? |
| 21:06.28 | starseeker | uh... I thoght I made it delete the original, but not sure |
| 21:06.48 | brlcad | okay |
| 21:07.18 | brlcad | i was thinking about the usability implications of both and intent |
| 21:09.01 | brlcad | given cases where both might be expected, I'm thinking it'll be safer to err on keeping the original |
| 21:09.32 | starseeker | make it a cp, instead of a mv? |
| 21:09.43 | brlcad | basically |
| 21:09.50 | starseeker | that kind of violates the paradigm of "changing this object" we're using with red |
| 21:10.03 | starseeker | the fact we use a temp copy is an implementation detail, after all |
| 21:11.00 | brlcad | the tradeoff is make those expecting copies having to cp first vs. those expecting rename having to rm after |
| 21:12.19 | brlcad | that's only if you expect red to "change this object" ... I can just as easily see someone pulling up the text editor, and expecting the name change to mean "give me a copy using that object's values" |
| 21:12.55 | brlcad | more than likely with some value(s) changed |
| 21:13.12 | starseeker | as opposed to every other parameter in the text editor changing the original object? dunno, seems a bit inconsistent (not to say someone wouldn't expect it...) |
| 21:13.16 | brlcad | basically boils down to cp+ed vs ed+rm |
| 21:14.05 | brlcad | i'm not sure someone wouldn't expect it frankly |
| 21:14.10 | brlcad | there are good use cases for both |
| 21:14.41 | brlcad | and every other param wouldn't change the original, it applies to that copy |
| 21:15.18 | brlcad | you wouldn't edit the original AND make a copy .. that'd just be wrong |
| 21:15.39 | CIA-105 | BRL-CAD: 03starseeker * r44306 10/geomcore/trunk/ (3 files in 2 dirs): Grrrrr. Can't get recursive assembly to function. Am I hitting some issue with pool memory size or something? |
| 21:15.55 | starseeker | oh, I agree - I just was thinking in the paradigm of "if you red an object, you're working on that one object. Period" |
| 21:16.06 | brlcad | it's the intent of changing the object name, did they mean rename or did they mean make me a new one based on the original |
| 21:17.22 | brlcad | the other consideration is that even if they are thinking that way, that it should rename the original .. the only surprise is that the original object is still there and they have to manually delete it |
| 21:18.13 | brlcad | if they're thinking the other way, that it should make a copy .. then much to their surprise, the original is deleted (along with the destruction of any original values they maybe still wanted) |
| 21:19.26 | starseeker | could make two commands - red and rcp |
| 21:19.27 | brlcad | that alone is pretty strong case for not deleting, maybe adding a flag to red to force one behavior |
| 21:20.09 | starseeker | yeah, I suppose until we have undo support not deleting is safer |
| 21:23.15 | brlcad | of course, copy or move behavior will have to check if that object name already exists, and similarly abort (unless there's a force flag) |
| 21:24.21 | brlcad | ah, and I see you already have code for that, excellent |
| 21:27.05 | brlcad | hm, what's a similar command that has cp/mv options |
| 21:36.25 | *** join/#brlcad yiyus (1242712427@je.je.je) | |
| 21:42.42 | CIA-105 | BRL-CAD: 03starseeker * r44307 10/geomcore/trunk/src/libgvm/ (files.c models.c): OK, that worked. Wasn't cleaning up after myself. See if I can put the content assignment back. |
| 21:45.18 | CIA-105 | BRL-CAD: 03starseeker * r44308 10/geomcore/trunk/src/libgvm/ (files.c models.c): Yep, that was it - just needed to clear the list. |
| 22:24.29 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 22:40.06 | brlcad | hello KimK |
| 22:40.39 | KimK | Hi brlcad, how's it going? |
| 22:40.47 | brlcad | pretty great! |
| 22:41.00 | KimK | Ha, excellent |
| 22:44.21 | KimK | You might be interested to know that I have now managed to install BRL-CAD on several machines, one defeated me, I'll look into that one again on a return visit there. Unfortunately, I'm no smarter on operating BRL-CAD yet, but I have stumbled across some tutorials, I hope to have time to work on those. |
| 22:48.16 | brlcad | KimK: outstanding |
| 22:48.30 | brlcad | yeah, the tutorials on the main website (under Documentation) is really the place to begin |
| 22:48.49 | brlcad | several of the documents listed there are very helpful for learning the basics |
| 22:55.40 | KimK | I have been trying to get the Ubuntu menu to start BRL-CAD. The LibreOffice-dev group has a similar problem, they start scripts to start the locally-built development versions. A developer friend gave me a little bash trick to put in the Ubuntu menu command to start them, example: bash -c 'cd /home/username/libo/install/program; ./swriter' But I haven't been able to apply it in the expected ways to start mged, I don't know what's up with that |
| 22:55.40 | KimK | . |
| 22:56.00 | KimK | Bah, flooded by one, need a character counter, lol! |
| 22:57.56 | brlcad | KimK: hm.. in more recent versions jordi sayol has menu and icons working for fedora and debian |
| 22:58.23 | brlcad | might check out the .deb to see how he did it |
| 22:58.41 | brlcad | (it's not in apt, it's up on the website) |
| 23:00.15 | KimK | More recent as in your development version? OK, no problem, I only installed from the 7.18 tarball. Do you guys have a git repo yet? |
| 23:00.32 | brlcad | 7.18.2 |
| 23:00.43 | KimK | OK, 7.18.2 |
| 23:00.51 | brlcad | no plans to move from svn to git any time soon |
| 23:01.46 | KimK | Oh, you're on svn? Maybe I can use "git svn". (Git is really nice.) |
| 23:01.58 | brlcad | quite familiar with git |
| 23:03.01 | KimK | Excellent, maybe git will be an option someday and you can advocate for it? |
| 23:04.57 | brlcad | if a revision control system needs advocating, then it's not mature enough yet for our use |
| 23:06.01 | brlcad | didn't advocate for cvs when switched from rcs, didn't advocate for svn when switched from svn ... the benefits were clear and downsides non-existent |
| 23:06.22 | brlcad | git doesn't have that case yet, several downsides |
| 23:06.44 | brlcad | maybe someday, but then maybe svn will have those features by then too or maybe some other system will have stepped up |
| 23:08.00 | KimK | What do you see as the downsides of git? Is svn in the group of one-repo cvs's, is that the issue? |
| 23:08.31 | brlcad | don't understand the second question |
| 23:09.29 | KimK | well, some are bothered by the idea that there's no "official central repo" in git (except by agreement or convention). |
| 23:09.53 | KimK | Any repo is equal to any other repo. |
| 23:09.58 | brlcad | that could be seen as a downside (or a benefit), depending on the community |
| 23:11.57 | brlcad | there are social impacts that are pretty extensively discussed, potential for community fragmentation, potentially increase in antisocial behavior (comparitively, since collaboration isn't forced) |
| 23:12.14 | brlcad | practical downside is the windows support, but that's improving |
| 23:13.12 | brlcad | the fact that it's a relatively new version control system, not nearly as extensively tested due to age alone |
| 23:14.21 | KimK | The EMC2 group hasn't had fragmentation problems that I have observed. They do have an agreed central repo. I would put decentralization in the benefit category, especially when there are internet connectivity issues, as might be expected more frequently now. (Earthquakes, tsunamis, sunspots, disasters, emp, what-have-you.) |
| 23:14.40 | brlcad | size of repo clone compared to checkout requires increased disk (particularly for large histories) |
| 23:15.09 | brlcad | that's a bit ridiculous imho :) |
| 23:15.21 | KimK | Ease of anyone browsing full history might be helpful? |
| 23:15.24 | brlcad | "might be expected more frequently now" .. no more or less than before unless people are just ignorant of the planet :) |
| 23:16.16 | brlcad | I think I can count on one hand how many times I've been offline and needing to commit over the past five years |
| 23:16.40 | brlcad | that would be a benefit, but it's minor (and it's also something that svn is working to implement too) |
| 23:16.52 | brlcad | in the end, I think the systems will become so hybridized that it just won't matter |
| 23:17.47 | brlcad | in which case, a central repo that can be distributed would win over a distributed repo pretending to be central |
| 23:18.01 | brlcad | but that's many many years out, of course |
| 23:18.52 | KimK | Well, git does have an impressive array of projects, even if you discount the Linux kernel one. (Admittedly some bias there, lol.) |
| 23:19.05 | brlcad | the point about switching, though, was that up until now, it's been very clear and strong benefits with NO downsides ... that's simply not the case quite yet |
| 23:19.12 | brlcad | popularity means nothing |
| 23:19.56 | brlcad | git tends to be the most vocal but by far not the most popular yet, last estimate I saw had it at maybe 20% (across industry) |
| 23:20.16 | brlcad | course stats can be fudged to show just about anything :) |
| 23:20.49 | KimK | Well, not completely nothing, it means that some groups saw an advantage to switching (to whatever). |
| 23:21.12 | brlcad | the fact that the benefits and downsides have to be weighed means it's closer to a wash .. which would simply be busy work right now |
| 23:21.19 | brlcad | not solving any specific problem we're having |
| 23:21.36 | KimK | Yes, well, you guys do have your hands full. |
| 23:21.54 | KimK | Hope it's going well, generally? |
| 23:22.01 | brlcad | it solves a big problem when the dev team scales beyond a communication point |
| 23:22.05 | brlcad | git, that is |
| 23:22.40 | brlcad | that point is around 50-100 active developers, if I recall correctly |
| 23:23.41 | KimK | Due to its history, are most brlcad developers in the US? I think that makes a difference too. |
| 23:23.42 | brlcad | I did the math a couple years ago, but it's basically the point at which NxM communication points slow down development where having a distributed infrastructure lets you have islands of communication |
| 23:24.33 | KimK | Not in the US, but in the same time zone, makes chatting difficult, or at least delays email. |
| 23:24.34 | brlcad | i don't think that makes any difference -- same issue with other communities I work with that are predominantly non-US |
| 23:25.24 | brlcad | if you have active devs, then the method and time of communication plays only a minor part .. they're reading logs, mailing lists, whatever |
| 23:25.28 | brlcad | impact is minimal |
| 23:25.53 | brlcad | it's the point at which there is too much activity, too many devs to have centralized communication |
| 23:26.08 | brlcad | that's the 50-100 dev metric |
| 23:26.19 | brlcad | that's why it was dead-obvious for linux |
| 23:26.27 | brlcad | hundreds of active devs |
| 23:27.40 | KimK | OK. Well, hopefully brlcad will continue to grow and you'll have more developers too. |
| 23:27.55 | brlcad | yeah, that's a problem I'd LIKE to have ;) |
| 23:28.42 | KimK | Haha, you'll get there. |
| 23:37.55 | brlcad | starseeker: on further inspection, red will also *create* a new combination (from nothing) .. so that seems even more pertinent that the editing intent is "write an object I've named with these values" and the in-editor object name might simply be them changing their mind on that name |
