| 00:04.44 | *** join/#brlcad dtidrow (~dtidrow@c-71-238-51-148.hsd1.mi.comcast.net) | |
| 00:06.53 | *** join/#brlcad Nohla (~Nohla@168.226.179.90) | |
| 01:00.35 | *** join/#brlcad Nohla (~Nohla@168.226.179.90) | |
| 01:17.22 | CIA-93 | BRL-CAD: 03brlcad * r39733 10/brlcad/trunk/src/ (4 files in 3 dirs): more lscon references to be eliminated |
| 01:22.24 | ``Erik | *snrkt* http://www.collegehumor.com/picture:1940268 |
| 01:22.47 | ``Erik | "contains 10% seawater" on a gas pump |
| 01:29.38 | *** join/#brlcad Nohla (~Nohla@168.226.179.184) | |
| 01:37.00 | starseeker | ../../../brlcad/src/libged/wdb_obj.c:298: error: âged_lsconâ undeclared here (not in a function) |
| 01:38.31 | starseeker | ah, nevermind |
| 01:38.32 | starseeker | sorry |
| 01:38.41 | starseeker | note to self - read scrollback |
| 02:10.30 | luke-jr | brlcad: would be nice if the custom units could have an abbreviation (eg 'tm') specified, as well as a rendering style (eg, decimal, hexadecimal, tonal) |
| 02:31.53 | *** join/#brlcad mafm (~mafm@3.Red-88-11-184.dynamicIP.rima-tde.net) | |
| 03:21.54 | brlcad | luke-jr: if you care to specify what exactly you're wanting into a feature request, it would be good to add it to our tracker on sf.net |
| 03:24.50 | luke-jr | :) |
| 03:28.36 | CIA-93 | BRL-CAD: 03starseeker * r39734 10/brlcad/branches/cmake/ (3248 files in 420 dirs): Update cmake branch to trunk rev 39733 |
| 04:38.25 | *** join/#brlcad yukonbob (~svs@S0106001125477e9c.ok.shawcable.net) | |
| 05:34.11 | CIA-93 | BRL-CAD: 03starseeker * r39735 10/brlcad/branches/rel8/ (2750 files in 420 dirs): Update rel8 branch to trunk rev 39733 |
| 05:37.55 | starseeker | wee that was fun |
| 07:57.19 | *** join/#brlcad Stattrav (~Stattrav@117.192.143.194) | |
| 10:02.41 | *** join/#brlcad mafm (~mafm@3.Red-88-11-184.dynamicIP.rima-tde.net) | |
| 10:04.23 | *** join/#brlcad mafm (~mafm@3.Red-88-11-184.dynamicIP.rima-tde.net) | |
| 10:06.09 | *** join/#brlcad mafm (~mafm@3.Red-88-11-184.dynamicIP.rima-tde.net) | |
| 10:08.00 | *** join/#brlcad mafm (~mafm@3.Red-88-11-184.dynamicIP.rima-tde.net) | |
| 10:09.47 | *** join/#brlcad mafm (~mafm@3.Red-88-11-184.dynamicIP.rima-tde.net) | |
| 10:11.32 | *** join/#brlcad mafm (~mafm@3.Red-88-11-184.dynamicIP.rima-tde.net) | |
| 10:13.35 | *** join/#brlcad mafm (~mafm@3.Red-88-11-184.dynamicIP.rima-tde.net) | |
| 10:15.20 | *** join/#brlcad mafm (~mafm@3.Red-88-11-184.dynamicIP.rima-tde.net) | |
| 10:21.02 | *** join/#brlcad mafm (~mafm@98.Red-80-26-129.dynamicIP.rima-tde.net) | |
| 11:06.34 | d-lo | Mernin all! |
| 11:20.51 | Ralith | mernen |
| 11:38.47 | d-lo | How goes it man? |
| 11:42.39 | Ralith | sleepily |
| 11:48.59 | *** join/#brlcad Stattrav (~Stattrav@117.192.139.87) | |
| 11:49.11 | *** join/#brlcad luke-jr (~luke-jr@2002:62b3:1d4c:0:20e:a6ff:fec4:4e5d) | |
| 12:20.10 | *** join/#brlcad mafm_ (~mafm@245.Red-88-23-77.staticIP.rima-tde.net) | |
| 15:10.07 | brlcad | starseeker: nice merging .. those look like pretty big jumps |
| 15:22.05 | ``Erik | now when do we start making rel8 our primary dev area? or do a pivot and make trunk 8 and have rel7 for maintenance while figuring the new file format? :D |
| 16:12.20 | *** join/#brlcad jam555 (~on_Chatzi@99.110.121.103) | |
| 16:12.40 | *** part/#brlcad jam555 (~on_Chatzi@99.110.121.103) | |
| 16:14.08 | louipc | trunk should always be the primary dev area shouldn't it? |
| 16:15.03 | starseeker | louipc: it's a bit tricky - rel8 will involve a lot of incompatible changes, so once we start making those changes any pure fixes independent of rel8 work will get harder to merge back |
| 16:16.00 | starseeker | we're trying to shake out some long-standing bugs in the 7* line currently |
| 16:16.02 | louipc | maintenance would be in a separate branch, no? |
| 16:16.27 | starseeker | it would, but that implies a considerably increased overhead in merging things between branches |
| 16:17.07 | starseeker | not to mention all the extra testing |
| 16:17.36 | starseeker | and there can be situations where you essentially have to develop the fix twice, if the code has split far enough |
| 16:17.58 | louipc | so how long do you support rel7 for? |
| 16:18.07 | louipc | yeah |
| 16:18.34 | louipc | I haven't really worked with svn branches before |
| 16:18.44 | starseeker | also, some of the rel8 issues will require a good deal of careful thought - particularly when it comes to v6 database format stuff |
| 16:18.46 | louipc | but git makes it really easy |
| 16:19.17 | starseeker | you want to be VERY careful when doing that design to be as future proof as possible, since every time you have to do a new v* format update it's good for a lot of headaches |
| 16:19.47 | louipc | of course |
| 16:19.49 | starseeker | w still have a lot of v4 vs v5 specific functions littering the code, for example |
| 16:20.18 | starseeker | ideally, we'd get that cleaned up before adding yet another round of v6 stuff in... |
| 16:20.36 | louipc | hehe |
| 16:20.49 | louipc | sounds like quite the buffet |
| 16:22.12 | louipc | is there some kind of roadmap for these development efforts? |
| 16:23.54 | starseeker | brlcad is the map ;-) |
| 16:24.20 | louipc | hmm might be a good idea to put it in writing |
| 16:25.05 | starseeker | we may have some stuff in the rel8 branch - let me look |
| 16:30.01 | starseeker | hmm... don't see it offhand |
| 16:31.43 | louipc | no prob |
| 16:57.13 | starseeker | nevermind, Sean pointed it out - at the bottom of the TODO file |
| 16:58.09 | starseeker | I think the "BREAK PROTOCOL OR ARE BACKWARDS-INCOMPATIBLE" section |
| 17:07.19 | CIA-93 | BRL-CAD: 03starseeker * r39736 10/brlcad/branches/rel8/TODO: Toss a couple notes into the rel8 TODO file |
| 17:09.50 | starseeker | idly wonders if we could do an XML based .g file format description for archival use, then realizes ``Erik would probably kill him... |
| 17:13.44 | brlcad | rel8 can become trunk when at least half of our activity is on rel8 work, which it's nowhere near |
| 17:14.44 | brlcad | there's no value putting the cart ahead of the horse on that one, it'd just make the monthly releases and support that'd still need to happen in the meantime more clumsy |
| 17:17.22 | brlcad | louipc: maintaining the branch itself isn't a problem, it's keeping a consistent scope and definition of the branches in order, all while maintaining a release schedule |
| 17:18.29 | brlcad | I've seen all too many times, devs treating a compatibility break as a time to go completely half-hazard on breaking API and turning stability into a disaster |
| 17:19.05 | brlcad | there is absolurely nothing preventing anyone from working on rel8 today |
| 17:22.56 | ``Erik | grabs his 6shooter and cowboy boots and prepares to go off halfhazard (halfcocked? halfbrained?) |
| 17:23.24 | ``Erik | I'd be afraid to do any dev in rel8 at the risk of causing serious merging difficulties |
| 17:23.44 | ``Erik | (now I'll read backlog) |
| 17:25.16 | ``Erik | trunk as zomfg dev and stable as a branch is what I'm familiar with, that's why I'll say things like "mfc" instead of merging to a branch, I'm used to the freebsd shtuff (which is well tested and well documented) |
| 17:26.22 | brlcad | that makes complete sense when most of the dev work is happening on trunk |
| 17:26.23 | ``Erik | (and xmlg-g g-xmlg seems somewhat reasonable, if vrml is simply inferior *shrug*) :) |
| 17:26.29 | brlcad | that's not presently the case, so it doesn't make sense |
| 17:27.05 | ``Erik | most of the dev work IS happening on trunk, but trunk is 'the old one' |
| 17:27.08 | brlcad | trying to force it sounds counterproductive and would probably just make releases a pita |
| 17:27.20 | brlcad | that's my point |
| 17:27.27 | brlcad | nothing stopping anyone from working on rel8 now |
| 17:27.47 | brlcad | if most were, heck if even 25% of commits were going to rel8, it might make sense |
| 17:28.18 | ``Erik | wonders how upset starseeker would be if he made rel8 his main working branch O.o |
| 17:28.29 | brlcad | right now, it might as well be named the "magical_spagetti_monster_branch", and argue it should be trunk |
| 17:28.49 | ``Erik | rel-pastafarian |
| 17:29.33 | ``Erik | my argument is that development will be focused on trunk... if we want that to be 7, then we're set... if we want that to be 8, we're backwards right now... 'sall |
| 17:39.21 | louipc | yeap |
| 17:39.48 | louipc | especially for people that don't understand the devel plans |
| 17:40.46 | louipc | but it seems that rel8 is experimental rather |
| 17:40.58 | louipc | so the current layout seems appropriate |
| 17:41.01 | brlcad | no argument there |
| 17:43.34 | brlcad | yeah, rel8 is a lot more like EXPERIMENTAL at this point, with no activity |
| 17:43.41 | brlcad | pushing it to trunk at this point would just be a "fuck ya'll" to those wanting/expecting monthly releases on rel7 |
| 17:44.02 | brlcad | I don't think there's any value in doing that at least until rel8 has something compelling going on there |
| 17:45.38 | starseeker | ah ha, thought so - there is a standard for MIlSPEC standards |
| 17:45.44 | starseeker | |
| 17:45.54 | starseeker | http://www.assistdocs.com/search/document_details.cfm?ident_number=36064 |
| 17:47.50 | brlcad | looks like we're averaging about 400 commits a month for the past year |
| 17:48.10 | louipc | haha a standard for standards |
| 17:49.06 | starseeker | hunts in vain for a Docbook or LaTeX pre-define style guide for this sucker... |
| 17:50.06 | brlcad | worth considering a swap when it increases to around 100-200 a month |
| 17:50.14 | brlcad | from the current 3 per month |
| 17:50.34 | ``Erik | starseeker: ms word template? :D *duck* |
| 17:50.43 | starseeker | louipc: that's not actually uncommon - OASIS has some nice templates for their standards (they're the guys who do the Open Document thing that OpenOffice uses...) |
| 17:51.06 | starseeker | ``Erik: yeah, probably... urk |
| 17:52.14 | starseeker | I actually like such guides - they tend to have a lot of useful rules that help organize and clarify things - but it's a whole lot easier when the hard work is automated |
| 17:53.58 | louipc | doesn't oasis do docbook too? |
| 17:54.20 | starseeker | yeah - if we wanted to do an OASIS spec, their templates are actually quite helpful |
| 17:55.19 | louipc | ok |
| 17:55.42 | starseeker | problem with that is our .g format isn't likely to be any sort of official spec anytime soon, so I need formatting guidelines I can use without running afowl of (say) the OASIS copyright and restrictions on said template |
| 17:56.13 | brlcad | starseeker: shooting for oasis spec sounds like a good goal though |
| 17:56.48 | brlcad | even if only to leverage their templates, but we could try to push for making it an open standard |
| 17:57.16 | starseeker | nods - it would be awesome if we could be officially blessed as the open CAD format |
| 17:59.16 | starseeker | yeah, here we go: http://docs.oasis-open.org/templates/ |
| 18:02.10 | starseeker | main issue would probably be whether they require an exclusive copyright assignment of all the spec contents, or just the spec contents + OASIS boilerplate |
| 18:02.32 | starseeker | recalls a little of that from his research into the ANSI Common Lisp spec... |
| 18:03.11 | starseeker | ah well, if we start to get close to something useful I suppose we could talk to them... |
| 18:07.01 | starseeker | gah - their fees are not pretty |
| 18:11.02 | starseeker | wonders if we'd need a better format name than .g |
| 18:11.35 | d-lo | what, like ".omfgAwesomeG" ? |
| 18:13.02 | starseeker | heh |
| 18:13.13 | starseeker | that oughta crash some Windows boxes |
| 18:13.14 | louipc | g8 hahaha |
| 18:14.56 | starseeker | was thinking more like "Open Computer Aided Design Data Storage and Exchange Format" or something that sounds all impressive and official |
| 18:15.05 | CIA-93 | BRL-CAD: 03erikgreenwald * r39737 10/brlcad/branches/rel8/configure.ac: add tkhtml3 to the list so the Makefile.in is generated. |
| 18:15.25 | starseeker | ``Erik: oh, sorry |
| 18:15.35 | starseeker | huh - merge must not have gone quite right |
| 18:16.26 | ``Erik | it's not in the original, either |
| 18:16.50 | ``Erik | probably accidently added the Makefile.in to the repo at one point and no one's done a completely clean co since? *shrug* |
| 18:17.18 | starseeker | probably - originally, it was JUST the Makefile.in, IIRC |
| 18:17.47 | starseeker | wait a minute... |
| 18:17.51 | starseeker | checks commit... |
| 18:18.15 | starseeker | ``Erik: uh, yeah that shouldn't need to be there - tkhtml3 is supposed to be its own subconfigure |
| 18:18.32 | ``Erik | yeah, it doesn't autogen right, and tcl and tk do the same but have entries *shrug* |
| 18:19.51 | starseeker | grr |
| 18:19.57 | ``Erik | config.status: error: cannot find input file: `Makefile.in' |
| 18:19.57 | ``Erik | configure: error: ./configure failed for src/other/tkhtml3 |
| 18:20.09 | ``Erik | before the change, after, it works *shrug* |
| 18:20.15 | starseeker | k |
| 18:20.56 | starseeker | eyes the list of Technical Committee participants on the Open Document Format project and winces |
| 18:22.52 | starseeker | looks like we'd have to satisfy a lot of people before anything could become an OASIS spec |
| 18:22.57 | louipc | what's wrong with STEP as the standard format? |
| 18:23.19 | starseeker | costs a LOT of $$$ just to get the docs |
| 18:23.29 | starseeker | and it's not well suited to in-memory representation, IIRC |
| 18:23.36 | starseeker | brlcad knows more details |
| 18:35.23 | brlcad | tcl/tk's AC_OUTPUT Makefile is ours, generated from our Makefile.am -- that makefile calls their unix/Makefile that their configure generates from their unix/Makefile.in |
| 18:35.40 | brlcad | tkhtml is a little different, trying to do double-duty (which it probably shouldn't), iirc |
| 18:37.10 | brlcad | for sub configures, you need to have a Makefile.am declare everything needed for dist, separate from the build logic |
| 18:42.22 | CIA-93 | BRL-CAD: 03starseeker * r39738 10/brlcad/trunk/src/libged/red.c: OK, get the tree change now. Need to fix _ged_save_comb and friends - apparently red is not the only thing using them. |
| 18:44.02 | ``Erik | I think the problem may actually be a lack of AM_AUTOMAKE_INIT in src/other/tkhtml3/configure.in ... doing a fresh co to test |
| 18:58.17 | CIA-93 | BRL-CAD: 03erikgreenwald * r39739 10/brlcad/branches/rel8/src/librt/primitives/sketch/sketch_brep.cpp: migrate changes that didn't seem to make it over |
| 18:59.11 | starseeker | ``Erik: if it looks like the merge really didn't do well, check the rel8 commit history - you might just be able to re-branch |
| 19:01.38 | ``Erik | it says it was updated, diff against the trunk revision seemed sane... I wonder if they were tweaked in the branch and svn felt that the change should stick :/ |
| 19:02.30 | ``Erik | nifty, msvc crashed |
| 19:14.10 | CIA-93 | BRL-CAD: 03starseeker * r39740 10/brlcad/trunk/src/libged/red.c: Sigh - other commands are using ged_save_comb, so can't gut this stuff yet. |
| 19:15.36 | CIA-93 | BRL-CAD: 03erikgreenwald * r39741 10/brlcad/branches/rel8/src/adrt/librender/camera.c: wrap plugin unloading in HAVE_DLFCN_H |
| 19:41.59 | CIA-93 | BRL-CAD: 03starseeker * r39742 10/brlcad/trunk/src/libged/red.c: Try enabling the new red command - this should, in principle, work. |
| 19:44.24 | starseeker | confound it |
| 19:45.29 | ``Erik | hm, there's a tesla "dealership" in dc |
| 19:47.35 | CIA-93 | BRL-CAD: 03starseeker * r39743 10/brlcad/trunk/src/libged/red.c: Still not working right - turn it back off for now. |
| 20:03.18 | starseeker | that's lovely - I can update the attributes or the tree, but not both??? |
| 20:03.20 | starseeker | grrrr |
| 20:03.22 | starseeker | digs |
| 20:14.36 | starseeker | oh |
| 20:16.00 | *** join/#brlcad mafm (~mafm@245.Red-88-23-77.staticIP.rima-tde.net) | |
| 20:19.07 | ``Erik | huh, small world |
| 20:27.58 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 20:38.19 | CIA-93 | BRL-CAD: 03starseeker * r39744 10/brlcad/trunk/src/libged/red.c: This particular set of voodo get the attributes updated, but needs more study as to why... appears fragile. |
| 21:01.37 | CIA-93 | BRL-CAD: 03starseeker * r39745 10/brlcad/trunk/src/libged/red.c: Finally - this appears to work. Have to respect some things being changed by various commands. |
| 21:06.38 | *** join/#brlcad Stattrav (~Stattrav@117.192.130.49) | |
| 22:36.44 | CIA-93 | BRL-CAD: 03starseeker * r39746 10/brlcad/trunk/src/librt/db5_types.c: Need to get the d_flags here too - is that all or are there more? |