| 03:04.48 | CIA-28 | BRL-CAD: 03brlcad * r34641 10/brlcad/trunk/src/tclscripts/lib/Command.tcl: |
| 03:04.48 | CIA-28 | BRL-CAD: protect the gets rename the same way mged/text.tcl does it by making sure the |
| 03:04.48 | CIA-28 | BRL-CAD: proc has a body/exists first. the s2 folks reported that they're getting an |
| 03:04.48 | CIA-28 | BRL-CAD: error about gets not existing which would be consistent with the Command.tcl |
| 03:04.48 | CIA-28 | BRL-CAD: constructor getting read multiple times. |
| 03:17.01 | brlcad | teh awesome, http://brlcad.org/tmp/goliath.png |
| 03:18.41 | brlcad | took 60 cores to crunch that image out in about 3 hours :) |
| 03:18.53 | brlcad | granted it was running at less than half-speed with all the verbose overlap logging |
| 03:19.01 | Ralith | top's a little overexposed |
| 03:19.26 | Ralith | but yeah, very nice |
| 03:19.35 | brlcad | and there are something like 16 spotlight light sources, 128 shadow rays, texturing, bump-mapping, .. lots of reflectivity |
| 03:19.53 | brlcad | pretty "expensive" picture |
| 03:20.09 | Ralith | pretty subtle bumpmapping/texturing. |
| 03:20.15 | brlcad | yep, intentionally |
| 03:20.25 | Ralith | I dunno, it might've been a bit underboard, so to speak |
| 03:20.41 | Ralith | I have a hard time telling it apart from a flat gray untextured model without looking very close |
| 03:20.42 | brlcad | it's closer to what it actually looks like |
| 03:20.57 | Ralith | okay |
| 03:21.09 | Ralith | I guess it actually looks like an untextured model :P |
| 03:21.47 | brlcad | untextured looks much different |
| 03:21.52 | brlcad | way too 'perfect'/clean |
| 03:22.33 | Ralith | I guess it's the lack of a comparison that dose it |
| 03:22.42 | Ralith | does* |
| 03:25.05 | brlcad | and to 'finish' it off, a 2x2 subsampling to eliminate the aliasing and rendering edges cleanly .. |
| 03:25.08 | brlcad | http://brlcad.org/tmp/goliath2.png |
| 03:27.53 | brlcad | 4x4 would be better, but that would take all night and there are other scenes of the goliath also worth rendering |
| 03:28.46 | brlcad | was nice if only just to sort out how remrt/rtsrv work once again, been a couple years |
| 03:29.30 | brlcad | calls it and heads out |
| 03:53.37 | *** join/#brlcad jdoliner (n=jdoliner@c-98-227-157-38.hsd1.il.comcast.net) | |
| 04:30.25 | *** join/#brlcad IriX64 (n=IriX64@bas2-sudbury98-1178015440.dsl.bell.ca) | |
| 04:59.49 | brlcad | howdy jdoliner |
| 05:00.06 | starseeker | that is an awesome goliath |
| 05:00.53 | brlcad | it finished shortly after you left |
| 05:00.58 | starseeker | heh figures |
| 05:01.07 | starseeker | scowls at cat |
| 05:01.42 | brlcad | s/sc/throws b/ |
| 05:02.06 | starseeker | nah, enough broken glass here for one night |
| 05:02.17 | starseeker | she's a good enough cat most of the time |
| 05:02.23 | brlcad | glass? :) |
| 05:02.40 | brlcad | was thinking more the stone or metal variety ;) |
| 05:02.49 | starseeker | she knocked over a lamp with an old style neon light bulb in it (you know, the big round ones) |
| 05:02.59 | starseeker | ah :-) |
| 05:06.08 | brlcad | thinks these will make a nice set of renderings for the museum |
| 05:09.24 | starseeker | indeed, they'll love it |
| 05:10.34 | starseeker | still would prefer to be sure the texture images are something we can include in the repository |
| 05:11.19 | brlcad | now that it's clear how it'll turn out, should have remrt quell overlaps, quell liboptical light overlap reporting, and render an 8k x 8k for a poster print |
| 05:11.34 | starseeker | :-) |
| 05:12.53 | brlcad | that's about 48 hours at the same settings and cpus, could probably triple the cpu horsepower to have it done overnight |
| 05:13.42 | brlcad | should do the other 2k's of the other 3 or so scenes first though |
| 05:13.54 | brlcad | then pick one to posterfy |
| 05:14.11 | starseeker | heh - museum could sell copies |
| 05:18.25 | CIA-28 | BRL-CAD: 03brlcad * r34642 10/brlcad/trunk/src/liboptical/photonmap.c: quell overlap reporting for the non-primary photonmapping rays |
| 05:32.32 | CIA-28 | BRL-CAD: 03brlcad * r34643 10/brlcad/trunk/src/liboptical/photonmap.c: ws style consistency cleanup, fix crazy equal alignment |
| 05:34.08 | starseeker | brlcad: can you leave irc messages for people? |
| 05:34.18 | starseeker | for when they reappear? |
| 05:34.21 | brlcad | memoserv |
| 05:38.10 | starseeker | thanks |
| 05:38.24 | starseeker | 's brain gives out |
| 05:40.54 | CIA-28 | BRL-CAD: 03brlcad * r34644 10/brlcad/trunk/src/liboptical/refract.c: propagate the same overlap logging behavior on refracted rays as on the originating ray |
| 05:43.56 | CIA-28 | BRL-CAD: 03brlcad * r34645 10/brlcad/trunk/src/liboptical/sh_air.c: utilize the same overlap logging when shooting rays via the (incomplete) 'textured mist' shader. |
| 05:44.23 | CIA-28 | BRL-CAD: 03brlcad * r34646 10/brlcad/trunk/src/liboptical/photonmap.c: ws indent |
| 05:55.43 | CIA-28 | BRL-CAD: 03brlcad * r34647 10/brlcad/trunk/src/liboptical/sh_toyota.c: propagate the overlap reporting callback for reflected texture rays |
| 05:56.04 | CIA-28 | BRL-CAD: 03brlcad * r34648 10/brlcad/trunk/src/liboptical/ (refract.c sh_light.c): ws, style, indent, consistency cleanup |
| 05:59.32 | CIA-28 | BRL-CAD: 03brlcad * r34649 10/brlcad/trunk/src/liboptical/sh_light.c: the biggest offenders of all when there are many light sources and/or lots of shadow calsbs. shoot an abundance of shadow rays but now utilizing the same overlap verbosity as the primary application ray. |
| 06:01.31 | *** join/#brlcad hippieindamakin8 (n=hippiein@202.3.77.38) | |
| 06:03.42 | CIA-28 | BRL-CAD: 03brlcad * r34650 10/brlcad/trunk/NEWS: |
| 06:03.42 | CIA-28 | BRL-CAD: all of the raytracers should now respect an application-defined overlap callback |
| 06:03.42 | CIA-28 | BRL-CAD: including (most importantly) the ability to have a lot of light sources with |
| 06:03.42 | CIA-28 | BRL-CAD: shadows and not have overlaps profusely reported particularly when the ray |
| 06:03.42 | CIA-28 | BRL-CAD: tracer is told to be quiet. |
| 07:24.11 | *** join/#brlcad IriX64 (n=IriX64@bas2-sudbury98-1178015440.dsl.bell.ca) | |
| 07:56.23 | *** join/#brlcad _clock_ (n=_sushi_@84-72-91-14.dclient.hispeed.ch) | |
| 08:55.30 | *** join/#brlcad archivist (n=archivis@host81-149-119-172.in-addr.btopenworld.com) | |
| 09:03.26 | *** part/#brlcad jdoliner (n=jdoliner@c-98-227-157-38.hsd1.il.comcast.net) | |
| 10:28.24 | d-lo | mernin all! |
| 10:30.56 | d-lo | brlcad: Heh, so what prompted the rt/light fix in r34650 ? =D |
| 10:38.49 | d-lo | brlcad: Kudos on the lighting Wiki page! +1 Digg |
| 10:52.11 | *** join/#brlcad Elrohir (n=kvirc@p5B14DA3A.dip.t-dialin.net) | |
| 11:43.07 | starseeker | staggers back to an awake state |
| 11:46.51 | d-lo | Staggers? heh, have a good night then eh? |
| 11:51.42 | starseeker | nope. Cat knocked over a lamp with an old style circular bulb in it (think office celing light, just curved into a circle) so I got to get home and spend time on glass cleanup and laundry |
| 11:52.07 | starseeker | tried hard to get some NURBS work done but brain shut down just before 2am |
| 11:52.57 | starseeker | is surprised indianlarry isn't in yet |
| 11:53.31 | d-lo | I think he is here.... |
| 11:53.46 | d-lo | here, as in at work, if not on irc |
| 11:53.48 | starseeker | indianlarry: online? |
| 11:55.03 | indianlarry | yes sorry |
| 11:55.08 | starseeker | np - morning! |
| 11:55.16 | indianlarry | how it go |
| 11:55.43 | starseeker | 's brain thinks it should still be in the OFF setting - I'm convincing it otherwise |
| 11:55.57 | starseeker | had a couple questions on the trimming code |
| 11:56.04 | indianlarry | sure |
| 11:56.31 | starseeker | if I've got it right, the CurveTree is being built in the preprocess-trims stage, and does not persist beyond that stage currently? |
| 11:56.49 | starseeker | i.e., when we get to the utah_isTrimmed stage the tree isn't present? |
| 11:57.14 | indianlarry | the curves should be attached to each 3d subdivision |
| 11:57.27 | starseeker | ok - where are they stored? |
| 11:59.16 | starseeker | knows that's embarassingly basic - sorry |
| 12:00.27 | indianlarry | in the top surfacetree object there's an xsorted list of all curve segments 'm_sortedX' ad an y sorted list 'm_sortedY' |
| 12:00.41 | indianlarry | sorry probably need to change to U,V references |
| 12:00.47 | starseeker | ah, ok |
| 12:00.52 | indianlarry | then in each subdivision |
| 12:01.50 | indianlarry | there is an 'm_trims_above' and an 'm_trims_right' list |
| 12:02.30 | indianlarry | so far it looks like i can remove the right and ysorted list |
| 12:02.32 | starseeker | does it being private mean we won't be able to get at it from brep.cpp? |
| 12:03.02 | starseeker | indianlarry: I'd leave them for the moment |
| 12:03.20 | indianlarry | just intend to access through member functions like isTrimmed(u,v) |
| 12:03.22 | starseeker | at least, until we hit it with some tougher geometry |
| 12:03.51 | starseeker | Oh, I see |
| 12:04.01 | indianlarry | i'll put the quick linear is in test should get us one step closer before newton |
| 12:04.07 | starseeker | cool |
| 12:04.16 | indianlarry | you all stay up too late |
| 12:04.27 | starseeker | heh |
| 12:04.52 | indianlarry | i'll get crackin and try to clean it up a bit |
| 12:05.24 | starseeker | np - I saw that TODO about finding multiple overlapping boxes and figured that was needed for the more "detailed" trimming |
| 12:05.50 | starseeker | opennurbs_ext.h line 909 currently |
| 12:06.41 | indianlarry | yea should only happen in special cases but can happen (sharp edge turned back on self) |
| 12:07.19 | starseeker | thought we were going to make a list of all overlapping trim segments and store that for an isTrimmed test, but perhaps the above+right method gives us a subset that contains that subset and is "close enough" without doing the extra work of identifying the actually overlapping line segments |
| 12:08.18 | starseeker | is the set of above+right guaranteed to contain all possible intersecting trim line segments? |
| 12:08.28 | indianlarry | actually just the above should give us everything i'll probably remove the right |
| 12:08.35 | starseeker | really |
| 12:08.42 | starseeker | huh |
| 12:09.08 | indianlarry | i think so |
| 12:09.46 | starseeker | oh, right - do the brain experiment of trying to construct a trim line that intersects, has a line segment to the right, and NOT a line segment in or above (both of which should show up as "above"?) |
| 12:10.04 | indianlarry | you got it |
| 12:10.25 | starseeker | <Windows NT booting noise> |
| 12:10.28 | starseeker | brain coming up |
| 12:10.34 | indianlarry | heh |
| 12:11.15 | indianlarry | do you try openbook? |
| 12:11.27 | starseeker | yeah - it actually looks impressive! |
| 12:11.37 | indianlarry | how long in prep |
| 12:11.49 | starseeker | because it has so many small nurbs surfaces, it actually gets startlingly close |
| 12:11.56 | starseeker | not too long |
| 12:12.02 | starseeker | Sean wasn't at all bothered |
| 12:12.09 | indianlarry | cool we're on the way |
| 12:15.14 | starseeker | indianlarry: so for the IsTrimmed test, you will take the list of above line segments from the m_trims_above subdivision entry, check each segment bounding box to see if it truly is above or inside, and if inside find the box with the closest linear approximation based closest point to the hit point? |
| 12:15.49 | starseeker | then if we need to, inside that last box we can go from the linear approx. based test to an actual closest point test? |
| 12:17.29 | indianlarry | yes |
| 12:17.48 | starseeker | ok, I get it now :-) |
| 12:18.00 | indianlarry | i'm thinkang about carrying the vdot to bound the iteration |
| 12:18.38 | indianlarry | and precomputed slope |
| 12:18.39 | starseeker | might be a good idea |
| 12:19.32 | starseeker | is glad he didn't muck with the code too much last night - would have done waaaay more work for less benefit |
| 12:19.56 | starseeker | was mentally stuck on getting a list of JUST overlapping sections, not overlapping plus above |
| 12:20.26 | starseeker | when the correct answer is probably "meh, we can sort that out cheaply and quickly at IsTrimmed" |
| 12:21.20 | *** join/#brlcad Elrohir (n=kvirc@p5B14DA3A.dip.t-dialin.net) | |
| 12:21.31 | indianlarry | hopefully i'll have something before you get in |
| 12:21.37 | starseeker | thinks some ascii-art uv space pictures might be in order for code documentation of these structures... |
| 12:21.48 | starseeker | indianlarry: probably - I've got to get it together here :-) |
| 12:21.55 | starseeker | indianlarry: awesome, awesome work |
| 12:23.40 | indianlarry | starseeker: your idea |
| 12:25.24 | starseeker | not so much with how do deal with the trimming curves and boxes |
| 12:25.33 | starseeker | er to deal with |
| 12:26.06 | starseeker | hunts for a way to ascii art output vector drawings... |
| 12:29.07 | starseeker | maybe create by hand, we'll see |
| 13:17.41 | *** join/#brlcad madant (n=madant@117.196.130.89) | |
| 13:24.44 | starseeker | here are some text versions of the uv parameter space: http://bzflag.bz/~starseeker/uvfig.txt |
| 13:24.52 | madant | brlcad: can i have access to a decent computer somewhere :) something which has lesser than 2 hour build time i mean |
| 13:49.58 | *** join/#brlcad _clock_ (n=_sushi_@84-72-91-14.dclient.hispeed.ch) [NETSPLIT VICTIM] | |
| 13:55.39 | *** join/#brlcad _clock_ (n=_sushi_@84-72-91-14.dclient.hispeed.ch) [NETSPLIT VICTIM] | |
| 14:16.04 | brlcad | starseeker: what are the vertical lines? |
| 14:47.26 | starseeker | 2D raytrace paths |
| 14:58.43 | ``Erik | why, is that a metaball on that lighting page? :D |
| 15:00.16 | brlcad | because it's what I snarfed from wikipedia |
| 15:00.27 | ``Erik | doh |
| 15:02.37 | ``Erik | then you should probably do something to note where it came from or something to comply with the gfdl |
| 15:06.36 | brlcad | i did |
| 15:06.43 | brlcad | feel free to make it better :P |
| 15:17.36 | ``Erik | oh, click to follow, okie |
| 15:17.46 | ``Erik | you're not in today? (at least, not in the next 13 minutes?) |
| 15:33.05 | *** join/#brlcad elena (n=elena@89.136.118.141) | |
| 15:43.33 | *** join/#brlcad elena (n=elena@89.136.118.141) | |
| 15:48.16 | elena | hi |
| 16:19.21 | starseeker | hey elena |
| 16:19.33 | elena | hi starseeker |
| 16:19.35 | starseeker | how's it going? |
| 16:19.52 | elena | almost ready with the theme. |
| 16:20.01 | elena | i've worked locally until now |
| 16:20.09 | elena | and soon will start to use svn. |
| 16:20.21 | starseeker | yeah, you need to be using svn throughout |
| 16:20.30 | starseeker | need an intro to it? |
| 16:20.33 | elena | brlcad said i should use it and commit frequent. |
| 16:20.42 | starseeker | he's right |
| 16:21.02 | elena | i read about it and i checkout the more folder |
| 16:21.05 | starseeker | if you're not set up for that, that's definitely the next thing to do |
| 16:21.08 | elena | which is empty now. |
| 16:21.23 | starseeker | uh, I thought it was web |
| 16:21.29 | starseeker | checks |
| 16:21.38 | elena | web/htdocs/more |
| 16:22.01 | starseeker | ok. you're working in that directory? |
| 16:22.22 | elena | i guess so. isn't that where I should? |
| 16:22.39 | starseeker | sure. just need to commit |
| 16:22.54 | elena | aha. |
| 16:23.05 | elena | i was expecting to find the drupal code in d folder. |
| 16:23.16 | elena | but only has the site settings. |
| 16:23.33 | elena | in the more may i commit the drupal code? |
| 16:23.41 | elena | or it goes in some other place? |
| 16:24.37 | starseeker | go ahead and commit - we can always undo |
| 16:24.46 | starseeker | put it where it works, we can fix it if we need to |
| 16:24.46 | elena | ok. |
| 16:24.59 | elena | this is the theme i started with http://drupal-5x.themebot.org/?theme=fireflystreamcom |
| 16:25.31 | elena | but i made some changes to it. |
| 16:26.04 | elena | i liked the colors. |
| 16:26.06 | elena | :) |
| 16:26.35 | starseeker | don't worry about the theme much - first order of business is the core functionality |
| 16:26.42 | starseeker | themes later |
| 16:26.47 | elena | ok. |
| 16:27.21 | elena | i'll get an preview version this week. |
| 16:28.10 | starseeker | sounds good :-) |
| 16:28.19 | elena | can you check is the svn tags are ok? |
| 16:28.21 | starseeker | you can check in without being finished |
| 16:28.39 | starseeker | tags? |
| 16:28.40 | elena | brlcad said you could make sure they are "set properly". |
| 16:28.51 | elena | i don't know exactly how to do that. |
| 16:29.02 | elena | maybe he did it when added more to the svn. |
| 16:30.09 | starseeker | OK, I'll check with him and do what needs doing |
| 16:30.13 | starseeker | if anything |
| 16:30.14 | elena | i believe that is what he said "tags set properly". sorry, I don't remember exactly :( |
| 16:30.25 | elena | thank you. |
| 16:30.36 | elena | ~log |
| 16:30.37 | ibot | well, log is http://ibot.rikers.org/%23wowhead/ |
| 16:30.37 | starseeker | you can commit? |
| 16:31.23 | elena | i didn't try yet. i have the code in another folder. |
| 16:31.23 | starseeker | I think it's actually http://ibot.rikers.org/%23brlcad/ |
| 16:31.45 | starseeker | might as well give it a whirl and see :-) |
| 16:31.55 | elena | ok. i will. |
| 16:32.09 | starseeker | Don't be shy - we're here to help :-) |
| 16:32.18 | elena | :) |
| 16:32.34 | starseeker | I've committed any number of embarassingly bad things |
| 16:33.47 | starseeker | and I can't spell :-P |
| 16:35.11 | elena | i found it. he said: "the basics are pretty simple, perhaps starseeker can help walk you through setting up a new repository module with the trunk/branches/tags set up properly" |
| 16:35.31 | elena | but then asked for my sf username and maybe he did it. |
| 16:35.51 | elena | http://ibot.rikers.org/%23brlcad/20090601.html.gz |
| 16:36.16 | starseeker | kinda looks like there are branches and tags directories, but I doubt we'll need them yet |
| 16:36.26 | elena | ok. |
| 16:36.37 | starseeker | unless he's got something specific in mind, I would expect you'd work in trunk |
| 16:36.52 | starseeker | checks log |
| 16:37.47 | starseeker | well, maybe... |
| 16:39.07 | starseeker | ah, yeah - we're using the "web" module so we don't need to set up a new one |
| 16:39.21 | elena | ok. |
| 16:39.30 | elena | module == folder ? |
| 16:39.56 | starseeker | kinda |
| 16:40.04 | starseeker | functionally that's about it |
| 16:41.11 | starseeker | basically work you do won't impact work in the iBME, brlcad or jbrlcad efforts (which have their own build systems, etc.) |
| 16:41.30 | elena | aha. |
| 17:31.52 | *** join/#brlcad jdoliner (n=jdoliner@c-98-227-157-38.hsd1.il.comcast.net) | |
| 17:50.32 | elena | i get: |
| 17:50.38 | elena | svn: Commit failed (details follow): |
| 17:50.45 | elena | Commit blocked by pre-commit hook (exit code 1) with output: |
| 17:50.59 | elena | /var/local/mastertree/host/sfp-svn/hook-scripts/check-mime-type.pl: |
| 17:51.15 | elena | then for each file says: svn:mime-type is not set |
| 17:51.48 | elena | in the end it suggests to use svn propset svn:mime-type for each file. |
| 17:53.02 | elena | or : You may want to consider uncommenting the auto-props section in your ~/.subversion/config file. |
| 17:53.28 | elena | oh. obvious. :) |
| 17:53.40 | d-lo | righto. If you are trying to commit code, then use 'svn propset svn:mime-type text/plain' |
| 17:53.49 | d-lo | or whatever mime-type is needed. |
| 17:54.17 | elena | i'll uncomment that line since there are too many files to do it manually. |
| 17:54.42 | elena | i didn't understand what it says until I pasted it. :) |
| 17:57.40 | d-lo | irc will eventually solve the world's problems. :) |
| 17:59.21 | ``Erik | by removing humans from it? :D |
| 18:07.31 | *** join/#brlcad indianlarry (n=indianla@bz.bzflag.bz) | |
| 18:11.21 | d-lo | ``Erik: only certain humans |
| 18:12.04 | ``Erik | namely; those that use irc? :D |
| 18:14.04 | d-lo | that cyclic logic just made my nose bleed.... :/ |
| 18:14.23 | brlcad | madant: still working on it, but you might have to just go with slow (and learn how to only do subbuilds) .. |
| 18:14.35 | brlcad | haven't had the time to get things set up |
| 18:16.35 | ``Erik | "how not to hummer your business" ow O.o |
| 18:17.50 | brlcad | elena: yeah, by using the existing 'web' module, the trunk/branches/tags was already set up, then I further cleaned up the checkout by putting in the more pertinent config files |
| 18:18.26 | elena | ok. thank you. |
| 18:20.40 | brlcad | elena: that's your own box of sand to work in, though, you can put what you want/need into there |
| 18:21.18 | elena | i'm about to. |
| 18:21.26 | elena | still fighting svn :) |
| 18:21.35 | starseeker | elena: this is helpful http://brlcad.org/wiki/Mime-types |
| 18:21.39 | elena | i'll commit drupal first. |
| 18:21.54 | elena | i think i got it. |
| 18:22.00 | elena | commiting now. |
| 18:22.02 | elena | thanks. |
| 18:22.18 | starseeker | the subversion config there saves a LOT of the propset stuff |
| 18:22.23 | elena | it doesn't seem hard, it's just the first time. |
| 18:23.42 | brlcad | the example config file on the wiki will auto-set props on a lot of file types |
| 18:23.44 | starseeker | you will grow to love svn, especially after your first major accidental overwrite/save disaster ;-) |
| 18:23.56 | brlcad | because you want mime types to be set as wel as eol-style |
| 18:24.44 | starseeker | for large commits of lots of new files, that config file is all but essential |
| 18:25.02 | starseeker | REALLY suggest getting it set up |
| 18:25.31 | elena | ok. i got it. |
| 18:25.41 | elena | i'll add drupal specific files, too |
| 18:35.25 | elena | goes to get dinner |
| 18:41.43 | brlcad | happy hunting |
| 18:43.46 | brlcad | elena: and you really must commit before doing any more work :) |
| 18:44.28 | brlcad | same goes for everyone really |
| 18:45.40 | brlcad | hardest new dev behavior, antisocial, actually counterproductive in the long run the longer time between/until commits |
| 18:56.44 | *** join/#brlcad samrose (n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) | |
| 18:59.20 | louipc | could they set up a personal repo and merge their work in? |
| 19:01.19 | *** join/#brlcad SWPadnos (n=Me@dsl107.esjtvtli.sover.net) | |
| 19:01.46 | brlcad | louipc: only if they're doing so several times a day |
| 19:02.16 | brlcad | the point isn't so much the revision control as it is the communication of how and why development occurs to others, throughout the whole process |
| 19:02.26 | brlcad | not just some checkpointed end-result |
| 19:02.42 | brlcad | it's a communication mechanism |
| 19:02.47 | louipc | yeah |
| 19:03.23 | louipc | I was thinking it could help wean new devs on the idea of frequent commits. |
| 19:04.05 | brlcad | usually happens best when they just dive in head first |
| 19:04.13 | louipc | haha good stuff |
| 19:04.20 | brlcad | so the benefits become evident more quickly |
| 19:04.21 | brlcad | seriously |
| 19:04.46 | brlcad | if it's only partial, the opposite occurs -- they'll wean themselves into less and less frequent commits eventually into isolation |
| 19:06.03 | brlcad | happens nearly universal, particular when they're new or insecure or (intentionally or unintentionally) subversive and generally 'afraid' of being open about their development process |
| 19:06.08 | brlcad | and activities |
| 19:06.28 | louipc | I guess it depends on the person really |
| 19:07.45 | brlcad | it does, but the tendency is pretty universal particularly for new developers |
| 19:07.52 | starseeker | typically the fear is betray of inexperience/inability - everybody starts out that way, but none of us like to admit it ;-) |
| 19:08.05 | louipc | yeah |
| 19:08.17 | brlcad | nobody wants to show their mistakes |
| 19:08.23 | starseeker | the point isn't don't make mistakes - the point is figure them out and fix 'em |
| 19:08.39 | brlcad | want everything to be "just perfect" before they share it, like working on a piece of art that is finally unveiled |
| 19:09.23 | brlcad | unfortunately, these are living works of art that have to be worked on by others if they are to survive, long after their contribution |
| 19:09.32 | starseeker | this trend can be encouraged by environments that a) punish mistakes and b) take a silly mistake as evidence of incompetence |
| 19:09.39 | louipc | that's why I like the idea of patches and reviewing them with others, they don't need to go into the working code until they're right |
| 19:09.55 | louipc | but you still get the communication and everything |
| 19:10.17 | starseeker | good project management has to be very constructive - work to solve problems and improve people's skills |
| 19:10.26 | brlcad | code is easily read 10 times more than it is written, communicating intention and process throughout the development becomes critical, otherwise it's actually 'cheaper' to throw their contribution out the window and rewrite it from scratch |
| 19:11.09 | brlcad | (openly) |
| 19:11.27 | louipc | yep |
| 19:12.32 | starseeker | the only times when there is justification for working long on code in isolation is something like a mathematical algorithm in a CAS system where it is easy to get code that produces AN answer and it's (very) difficult to be sure it's the RIGHT answer just by looking at the answer. In that case, releasing code that gives "an" answer is an invitation to misuse. But such cases are EXTREMELY rare |
| 19:13.46 | starseeker | I don't think BRL-CAD really has any such cases - the closest is probably analytical ray tracing for things like weight or surface area, but even there the answer itself serves as a sanity check - it has physical meaning |
| 19:16.09 | ``Erik | of course, releasing code that gives "an" answer may invite people to review and possibly correct or ask useful questions |
| 19:16.55 | starseeker | my experience with mathematical software suggests it's far more likely to be used by people to solve pratical problems than to be reviewed with the care necessary to detect subtle errors |
| 19:17.27 | starseeker | there is a reason mathematical problems drive formal methods in coding ;-) |
| 19:17.45 | louipc | just make sure you put a disclaimer |
| 19:17.51 | ``Erik | heh, and there's a reason that copy&paste coding is considered harmful :D |
| 19:18.26 | starseeker | copy/paste in what sense? |
| 19:18.36 | louipc | I copy paste |
| 19:18.47 | ``Erik | people who grab code without understanding what it does and shove it in |
| 19:19.34 | starseeker | ah. I was thinking more along the lines of people solving engineering problems and plugging their values into a "solver" for their particular equation |
| 19:20.48 | ``Erik | so like a copy&paste coder who uses a library without knowing what it does underneath and doesn't care to learn because it's already there? :D |
| 19:21.30 | ``Erik | we were actually having a discussion about which sorting algorithm to use for the nurb trimming this morning, heh :D |
| 19:22.16 | louipc | haha I was taught the virtues of not knowing/caring what a library's function was doing, only what you put in and got out |
| 19:22.32 | starseeker | ``Erik: in commercial coding, they probably won't LET you see the code behind the library |
| 19:22.36 | louipc | kind of bad I guess... |
| 19:22.58 | ``Erik | well, I'm thinking basic operations, like the set and sort stuff in jabba |
| 19:23.16 | ``Erik | *shrug* |
| 19:23.28 | starseeker | basic operations are more likely to be correct, just statistically speaking |
| 19:23.43 | starseeker | simpler, more use cases that will shake out errors |
| 19:23.44 | ``Erik | one of the neat things about STL was that it explicitely defined the asymptotic behavior |
| 20:06.11 | *** join/#brlcad andax (n=andax__@d213-102-41-16.cust.tele2.ch) | |
| 20:18.34 | CIA-28 | BRL-CAD: 03indianlarry * r34651 10/brlcad/trunk/ (3 files in 3 dirs): started second level of NURB trimming using linear approximation |
| 20:38.19 | CIA-28 | BRL-CAD: 03ebautu * r34652 10/web/trunk/htdocs/more/ (327 files in 52 dirs): Initial commit. Drupal 5.18 |
| 20:38.39 | brlcad | woot :) |
| 20:38.44 | brlcad | ~elena++ |
| 20:38.50 | starseeker | excellent |
| 20:39.55 | brlcad | starseeker: even when working on a mathematical algorithm, you're not necessarily releasing that effort into production -- committing doesn't mean it has to be enabled for end-user use |
| 20:41.02 | brlcad | quite the contrary, you can get some synergy where someone instantly recognizes a flaw early that saves the would-be-isolationist from going down the wrong path with bad assumptions/axioms for hours/days/weeks on end |
| 20:41.19 | brlcad | or help with testing the implementation or documenting right away, etc |
| 20:42.28 | elena | hurray. it finished. |
| 20:42.31 | brlcad | most of what you refer to is a matter of making it user-visible and announced or at least active for use |
| 20:42.39 | brlcad | elena: hurrah! :) |
| 20:42.46 | elena | it turns out i had to remove everything and svn add them again. |
| 20:42.58 | brlcad | yeah, props will do that |
| 20:43.08 | brlcad | (wiki page mentioned that) ;) |
| 20:43.27 | elena | :( |
| 20:43.28 | starseeker | brlcad: true - I guess the problem with some of those projects is the line between "user visible" and "commited to public repository" isn't really there |
| 20:43.48 | brlcad | project infrastructure |
| 20:43.56 | starseeker | elena: It will get better - commiting large amounts of other code generally causes the most trouble with props |
| 20:44.12 | starseeker | shudders at the memory of the docbook commits... |
| 20:44.14 | brlcad | have to provide some way for code to develop openly but distinguished from vetted algorithms |
| 20:44.17 | elena | btw, you should change the room title... |
| 20:45.12 | elena | now that config is set, the following adds/commits should work ok. |
| 20:46.04 | elena | now i'll checkout on the server :) |
| 20:46.45 | ``Erik | find . -name .whatever -print0 | xargs -0 svn propset ... |
| 20:46.58 | ``Erik | *.whatever, even |
| 20:47.05 | ``Erik | :D |
| 20:48.06 | *** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || Release 7.14.8 posted (20090511) || GSoC2009 Next Step: code code, type type, commit! commit frequently (multiple times daily) while you work. update wiki daily on progress. | |
| 20:54.44 | *** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || Release 7.14.8 posted (20090511) || GSoC2009 Next Step: code code, type type, commit frequently while you work! update wiki/blog on daily progress. | |
| 20:55.29 | CIA-28 | BRL-CAD: 03ebautu * r34653 10/web/trunk/htdocs/more/.htaccess: Initial commit. Drupal 5.18 (cont) |
| 20:57.34 | elena | i forgot some (hidden) files. |
| 20:57.54 | CIA-28 | BRL-CAD: 03ebautu * r34654 10/web/trunk/htdocs/more/profiles/default/ (. default.profile): Initial commit. Drupal 5.18 (cont) |
| 21:00.26 | elena | may I create a database/user? |
| 21:03.00 | *** join/#brlcad andax (n=andax__@d213-102-41-187.cust.tele2.ch) | |
| 21:06.37 | CIA-28 | BRL-CAD: 03ebautu * r34655 10/web/trunk/htdocs/more/sites/: Added more.brlcad.org but svn:ignored. |
| 21:11.51 | CIA-28 | BRL-CAD: 03ebautu * r34656 10/web/trunk/htdocs/more/sites/all/themes/ (33 files in 3 dirs): Added fireflystream theme (initial commit) |
| 21:16.50 | ``Erik | ahhh hhhhaaaaaaaaaa |
| 21:22.20 | brlcad | elena: sure |
| 21:22.26 | brlcad | let me know if you need a hand |
| 21:22.31 | elena | thanks. |
| 21:22.47 | brlcad | just shouldn't allow remote connections |
| 21:22.57 | elena | ok. |
| 21:24.45 | brlcad | elena: you didn't have to use 5.x simply because the current site is |
| 21:24.56 | brlcad | don't know if that was why or just because it's more stable |
| 21:25.21 | elena | i like it better than 6. |
| 21:25.32 | brlcad | PrezKennedy: you there? |
| 21:30.19 | elena | brlcad I can't create it. i don't have the rights. |
| 21:30.52 | elena | can you help me? |
| 21:36.21 | *** join/#brlcad _sushi_ (n=_sushi_@80-219-40-111.dclient.hispeed.ch) | |
| 21:53.16 | brlcad | yup, send me user/pass in pm |
| 22:22.56 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-117.sbndin.btas.verizon.net) | |
| 23:18.29 | *** join/#brlcad indianlarry (n=indianla@bz.bzflag.bz) [NETSPLIT VICTIM] | |
| 23:19.31 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) [NETSPLIT VICTIM] | |
| 23:20.22 | Ralith | anyone else having lots of [near-]timeouts? |
| 23:44.11 | brlcad | Ralith: I was, but not now |
| 23:48.32 | CIA-28 | BRL-CAD: 03starseeker * r34657 10/brlcad/trunk/ (include/opennurbs_ext.h src/librt/primitives/brep/brep.cpp): |
| 23:48.32 | CIA-28 | BRL-CAD: closest NURBS trimming curve shouldn't ever be NULL - assign closest to the |
| 23:48.32 | CIA-28 | BRL-CAD: first curve in all cases, then check for anything better. Visual artifacts now |
| 23:48.32 | CIA-28 | BRL-CAD: more consistent with that expected for stage 2 trimming - activating and |
| 23:48.32 | CIA-28 | BRL-CAD: committing. |
