| 00:00.55 | starseeker | brlcad: There we go - this is a combination of the cottbus.de improvements and my own tweaks: http://bzflag.bz/~starseeker/scl-3.2.tar.gz |
| 00:03.34 | starseeker | I don't know about the make being triggered by configure, but presumably it can be made to do what is needed for a subconfigure |
| 00:03.47 | starseeker | humbly chews on crow... |
| 00:05.47 | ``Erik | chews on his salsbury steak |
| 00:05.50 | ``Erik | I think mine tastes better |
| 00:05.50 | ``Erik | :D |
| 00:13.40 | starseeker | probably :-) |
| 00:14.28 | starseeker | wonders if brlcad has tried crow meat on his far reaching culinary adventures |
| 00:14.43 | starseeker | somebody must have tried eating one at some point |
| 00:14.58 | starseeker | woot - builds on linux successfully too |
| 00:34.16 | louipc | I had pidgeon |
| 00:41.00 | starseeker | how was it? |
| 00:41.06 | ``Erik | DOVE MURDERER! |
| 00:52.20 | louipc | oh it was good, tasted like chicken |
| 00:53.05 | louipc | you can probably find it in an authentic chinese restaurant. it might depend on the time of year |
| 01:12.14 | starseeker | ah, there we go |
| 01:12.37 | starseeker | ./configure and make now behave (by default anyway) as expected: http://bzflag.bz/~starseeker/scl-3.3.tar.gz |
| 01:16.42 | starseeker | makes note to figure out needed targets for install, distclean, etc. and heads home |
| 01:17.17 | ``Erik | looks at the clock and shakes his head |
| 01:17.48 | starseeker | was in one of his frustrated moods today and wanted to get SOMETHING useful done |
| 01:19.08 | ``Erik | productivity is over-rated |
| 01:19.28 | ``Erik | go home before your wench selects other body parts for the pickle-jar, boy :D |
| 01:19.38 | starseeker | winces and logs out |
| 03:21.51 | starseeker | grinds his teeth as the scl bundle that succeeded on OSX and Linux fails immediately on his home box |
| 03:24.39 | louipc | just building? |
| 03:33.41 | starseeker | yeah - the lex scanner is throwing out c code with two statics in it |
| 03:41.43 | starseeker | actually, there are several steps to the final expscan.c |
| 03:48.51 | ``Erik | is the compilation host specific? |
| 03:50.08 | ``Erik | if it's not, I'd argue that it's acceptable to put the compiled .c file output into the repo to avoid the yacc/lex chain |
| 04:07.31 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) |
| 04:30.37 | starseeker | ``Erik: not sure |
| 06:26.47 | CIA-40 | BRL-CAD: 03homovulgaris * r33951 10/brlcad/trunk/src/libpc/pcMathGrammar.h: adding various operators to the expression grammar |
| 07:26.05 | *** join/#brlcad _sushi_ (n=_sushi_@77-58-225-235.dclient.hispeed.ch) |
| 08:18.59 | *** join/#brlcad _sushi_ (n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 08:33.15 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) |
| 09:22.04 | CIA-40 | BRL-CAD: 03homovulgaris * r33952 10/brlcad/trunk/src/libpc/ (pcMathGrammar.h pcMathLF.h pcMathVM.h): pcMath VariableGrammar completely defined also taking into account closures |
| 09:52.48 | brlcad | woot |
| 10:49.20 | *** join/#brlcad madant (n=madant@117.196.149.246) |
| 12:42.09 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-241.sbndin.btas.verizon.net) |
| 12:44.46 | *** join/#brlcad Elrohir (n=kvirc@p5B14DB64.dip.t-dialin.net) |
| 13:08.35 | *** join/#brlcad madant_ (n=madant@117.196.140.81) |
| 13:15.11 | *** part/#brlcad madant_ (n=madant@117.196.140.81) |
| 13:15.18 | *** join/#brlcad madant_ (n=madant@117.196.140.81) |
| 13:21.04 | *** join/#brlcad elite01 (n=omg@unaffiliated/elite01) |
| 13:55.39 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-241.sbndin.btas.verizon.net) |
| 14:15.39 | *** join/#brlcad madant_ (n=madant@117.196.130.236) |
| 14:21.12 | CIA-40 | BRL-CAD: 03brlcad * r33953 10/brlcad/trunk/NEWS: bob added centroids and moments of intertia to the gqa command |
| 14:24.38 | CIA-40 | BRL-CAD: 03brlcad * r33954 10/brlcad/trunk/NEWS: bob fixed a handful of smp bugs in gqa where there were critical sections that were not being semaphore-protected. |
| 14:28.00 | CIA-40 | BRL-CAD: 03brlcad * r33955 10/brlcad/trunk/NEWS: bob make gqa handle reading in density files better. now handles arbitrary blank lines and comment lines. also fixed a bug where it was writing past the end of an array. |
| 14:34.34 | CIA-40 | BRL-CAD: 03brlcad * r33956 10/brlcad/trunk/NEWS: |
| 14:34.34 | CIA-40 | BRL-CAD: bob fixed doing a copy action on Windows, and doing a paste for any platform. |
| 14:34.34 | CIA-40 | BRL-CAD: previously, pasting would wipe out whatever was selected (which would normally |
| 14:34.34 | CIA-40 | BRL-CAD: make sense but not for read-only command console selections). this addresses sf |
| 14:34.34 | CIA-40 | BRL-CAD: bug 2278235 reported by lbutler (Can't cut-and-paste under Windows) |
| 14:38.50 | CIA-40 | BRL-CAD: 03brlcad * r33957 10/brlcad/trunk/NEWS: |
| 14:38.51 | CIA-40 | BRL-CAD: bob fixed a bug in mged where the last character would end up getting ignored. |
| 14:38.51 | CIA-40 | BRL-CAD: the only key combination he found that produced that behavior was a |
| 14:38.51 | CIA-40 | BRL-CAD: control-key-slash binding. overriding the binding (to do nothing) fixed the |
| 14:38.51 | CIA-40 | BRL-CAD: issue for bob. no word yet from peter_gillissen that reported this bug as sf |
| 14:38.53 | CIA-40 | BRL-CAD: bug 2555653 (Neglecting last character command-line). |
| 14:39.13 | brlcad | there, that should do it |
| 14:44.22 | CIA-40 | BRL-CAD: 03brlcad * r33958 10/brlcad/trunk/ChangeLog: update the changelog with changes since the last release, 2009-02-06. preparing for release 7.14.4 |
| 14:48.18 | CIA-40 | BRL-CAD: 03brlcad * r33959 10/brlcad/trunk/ (NEWS include/conf/PATCH): bump it! 2009-03-06 is release day for 7.14.4 |
| 15:04.28 | CIA-40 | BRL-CAD: 03bob1961 * r33960 10/brlcad/trunk/src/tclscripts/lib/Command.tcl: This applies the same bug fixes that were applied to MGED (i.e. bug #2555653 - the command line has an extra character at the end that is not used and cannot be removed; bug #2278235 - can't cut-n-paste under Windows) |
| 15:04.35 | *** join/#brlcad Ralith_ (n=ralith@216.162.199.202) |
| 15:05.19 | *** join/#brlcad samrose (n=samrose@adsl-99-147-180-206.dsl.lgtpmi.sbcglobal.net) |
| 15:31.28 | *** join/#brlcad Elrohir (n=kvirc@p5B14DB64.dip.t-dialin.net) |
| 15:37.11 | *** join/#brlcad Elrohir (n=kvirc@p5B14DB64.dip.t-dialin.net) |
| 15:41.03 | *** join/#brlcad Elrohir (n=kvirc@p5B14DB64.dip.t-dialin.net) |
| 15:44.16 | CIA-40 | BRL-CAD: 03bob1961 * r33961 10/brlcad/trunk/src/tclscripts/ (lib/Command.tcl mged/text.tcl): Disallow cut operation in command windows. |
| 15:46.20 | *** join/#brlcad Elrohir (n=kvirc@p5B14DB64.dip.t-dialin.net) |
| 16:13.48 | *** join/#brlcad Elrohir (n=kvirc@p5B14DB64.dip.t-dialin.net) |
| 16:40.47 | *** join/#brlcad Don__ (n=Don@c-68-62-76-34.hsd1.mi.comcast.net) |
| 16:44.23 | *** join/#brlcad Dr_Phreakenstein (n=phreak@216.151.24.198) [NETSPLIT VICTIM] |
| 16:46.00 | *** join/#brlcad Don_ (n=Don@c-68-62-76-34.hsd1.mi.comcast.net) [NETSPLIT VICTIM] |
| 16:46.00 | *** join/#brlcad ewilhelm (n=ewilhelm@pool-71-111-78-159.ptldor.dsl-w.verizon.net) [NETSPLIT VICTIM] |
| 16:47.53 | *** join/#brlcad astrobear (n=ib@unaffiliated/ibuffy) |
| 16:48.14 | *** join/#brlcad samrose (n=samrose@adsl-99-147-180-206.dsl.lgtpmi.sbcglobal.net) |
| 16:51.23 | *** join/#brlcad ``Erik_ (i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 16:55.53 | *** join/#brlcad astrobear (n=ib@unaffiliated/ibuffy) |
| 17:23.21 | *** join/#brlcad madant__ (n=madant@117.196.133.187) |
| 17:48.38 | *** join/#brlcad astrobear (n=ib@unaffiliated/ibuffy) |
| 17:51.47 | CIA-40 | BRL-CAD: 03bob1961 * r33962 10/brlcad/trunk/src/mged/setup.c: Fixed typo. |
| 17:53.01 | CIA-40 | BRL-CAD: 03bob1961 * r33963 10/brlcad/trunk/src/mged/rtif.c: Modify f_nirt and f_vnirt to strip _mged_ prefix before calling libged. |
| 17:57.23 | CIA-40 | BRL-CAD: 03bob1961 * r33964 10/brlcad/trunk/src/ (mged/setup.c tclscripts/mged/ray.tcl): This fixes the "Pick Edit-Primitive" mode in MGED. |
| 18:05.00 | *** join/#brlcad astrobear (n=ib@unaffiliated/ibuffy) |
| 18:05.29 | *** join/#brlcad _sushi_ (n=_sushi_@77-58-232-153.dclient.hispeed.ch) |
| 18:30.56 | brlcad | heh, bears in space |
| 18:39.23 | brlcad | wow. trunk passes distcheck but stable doesn't (from the last release) |
| 18:39.36 | brlcad | sounds like someone didn't follow through! :) |
| 18:39.52 | starseeker | uh oh |
| 18:39.57 | starseeker | did I mess up again? |
| 18:40.11 | brlcad | no worries |
| 18:40.22 | starseeker | what was busted?? |
| 18:40.24 | brlcad | does rtwizard work for you? |
| 18:41.02 | starseeker | hmm - not popping up a window here |
| 18:41.11 | starseeker | oh, there it goes |
| 18:41.18 | brlcad | don't know how extensive, just distcheck for the 7.14.2 stable merge didn't go well (or released with a failing distcheck) .. bunch of regress/mged files missing from the dist |
| 18:41.32 | brlcad | starseeker: oh, that reminds me |
| 18:41.36 | brlcad | specific feature request there |
| 18:41.48 | brlcad | should be a really quick change |
| 18:41.52 | starseeker | sure |
| 18:42.34 | starseeker | blast it, rtwizard is busted |
| 18:42.35 | brlcad | adding a button to rtwizard that saves a shell script of what it would do instead of running the steps |
| 18:42.53 | starseeker | "unrecognized unit type - Unknown_unit |
| 18:43.04 | brlcad | rutroh |
| 18:43.28 | brlcad | archer not working isn't a show-stopper but rtwizard is |
| 18:45.37 | *** join/#brlcad ``Erik (n=erik@ftp.brlcad.org) |
| 18:45.48 | starseeker | seeks the Wisdom of Bob |
| 18:46.08 | starseeker | It's an error on db load... |
| 18:46.12 | brlcad | try first :) |
| 19:35.54 | CIA-40 | BRL-CAD: 03brlcad * r33965 10/brlcad/trunk/HACKING: update the merge steps to allow for a little more copy-pasting love next time. probably could make this into a script using propsets to track the last merged revision id. something to think about next month. |
| 19:44.01 | starseeker | That's.... really weird |
| 19:45.35 | brlcad | hm, I just ran into the "slow framebuffer" bug, hum. |
| 19:46.47 | starseeker | brlcad: rtwizard does not appear to be busted after all, at least not in the way I was thinking |
| 19:47.13 | starseeker | I was getting Unknown_unit on failure, but I just checked the database and it is an unknown unit |
| 19:47.21 | starseeker | very strange |
| 19:47.31 | starseeker | with a "normal" unit it is working fine |
| 19:47.39 | brlcad | okay, good |
| 19:47.55 | brlcad | was about to just comment that it seems to be working for me here |
| 19:48.00 | brlcad | just aweful slow |
| 19:49.36 | starseeker | probably shouldn't wipe out on Unknown_unit, but I don't suppose it's a common sitution |
| 19:50.25 | brlcad | probably not |
| 19:50.55 | brlcad | i'd say leave it be unless you plan on writing a new wizard rendering interface |
| 19:51.32 | brlcad | someone should do that.. it'd probably end up being the most utilized tool by the analysts |
| 19:53.33 | CIA-40 | BRL-CAD: 03brlcad * r33966 10/brlcad/trunk/NEWS: annotate the last-minute injection by bob to fix Pick Edit-Primitive mouse interaction mode. he fixed it so it works again. |
| 19:57.40 | starseeker | is still pissed at himself for somehow messing up on the last release... |
| 19:57.46 | starseeker | somehow this isn't my week |
| 19:57.49 | brlcad | aha, the delay only happens with remote fbserv's |
| 19:58.13 | starseeker | so the question is whether it's the network's fault or fbserv's? |
| 19:58.18 | brlcad | starseeker: heh, it was minor, forget about it |
| 19:58.21 | brlcad | oh, it's fbserv's |
| 19:58.39 | brlcad | there's no reason it can't shovel a 1024x1024 image in an instant |
| 19:58.45 | starseeker | hrm |
| 19:58.49 | brlcad | it's taking 15sec or so |
| 19:58.53 | starseeker | ow |
| 19:59.02 | brlcad | see if you get it: |
| 19:59.04 | starseeker | sounds like a job for Shark |
| 19:59.10 | brlcad | fbserv 1 /dev/X & |
| 19:59.14 | brlcad | oops |
| 19:59.19 | brlcad | fbserv -s1024 1 /dev/X & |
| 19:59.46 | brlcad | rt -F1 -s1024 db/moss.g all.g |
| 20:00.37 | brlcad | nasty |
| 20:00.52 | starseeker | yeah, it's slower no question |
| 20:01.01 | starseeker | hauls out shark |
| 20:03.04 | brlcad | it's all I/O waiting, you'll be hard pressed to find it with shark, but maybe |
| 20:03.32 | starseeker | ah, so more up dtrace's alley? |
| 20:04.04 | brlcad | actually, old-school gprof might help since it has a wallclock counter iirc |
| 20:04.43 | brlcad | you need something that checks wallclock time, not just cputime -- maybe a way to get shark to show system i/o |
| 20:05.16 | brlcad | oh, or maybe better yet |
| 20:05.23 | brlcad | run shark on fbserv |
| 20:05.48 | brlcad | that'll probably say blitting, but should lead to the calls on the server side that are responding |
| 20:06.07 | brlcad | which maybe help point to where on the client, and who's problem it is |
| 20:07.22 | brlcad | yet another option, recompile and/or enable libpkg debugging to see what the chatter looks like |
| 20:08.15 | starseeker | Hmm - profiling fbserv, 50.5% was X24_blit |
| 20:08.34 | brlcad | "that'll probably say blitting" ;) |
| 20:09.02 | starseeker | yep, you were right :-) |
| 20:09.45 | *** join/#brlcad samrose (n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 20:11.03 | brlcad | there's probably a way to get at the libpkg debug vars through rt |
| 20:11.55 | brlcad | my suspicion is that it's sending one pixel per packet, and is just busy waiting on the network to send 1024x1024 packets |
| 20:12.01 | *** join/#brlcad BigAToo (n=BigAToo@64.74.225.82) |
| 20:12.21 | starseeker | what does bu_bitv_clear do? |
| 20:12.26 | brlcad | wow, even rt -i is slow |
| 20:12.33 | brlcad | actually, even slower |
| 20:12.51 | brlcad | bu_bitv_clear() erases a bit vector |
| 20:13.32 | starseeker | ok, part of ray shooting |
| 20:13.43 | brlcad | right |
| 20:13.48 | brlcad | at least, that'd be my guess |
| 20:13.57 | brlcad | several primitives use bit vectors for their book keeping |
| 20:19.06 | *** join/#brlcad ibot (i=ibot@rikers.org) |
| 20:19.06 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || GSoC 2008 Highlight: new prototype gui, check it out! || Source Release 7.14.2 is posted (20080207) |
| 20:19.38 | brlcad | with the fb at 1024x1024, any rt -i > -s512 runs dog slow, yet smaller is fine |
| 20:19.56 | brlcad | without -i though, any rt > 600 runs slow, yet 600 is fine |
| 20:20.15 | starseeker | on remote display? |
| 20:20.23 | brlcad | yeah, same fbserv as above example |
| 20:20.42 | brlcad | -i will make it 8x slower |
| 20:20.51 | brlcad | because it's multiple passes |
| 20:22.21 | brlcad | which is fine, I'd expect that -- it's either fbserv's processing, the packetsize/mode from rt, the network transfer itself, or something in libpkg |
| 20:23.22 | CIA-40 | BRL-CAD: 03brlcad * r33967 10/brlcad/trunk/BUGS: |
| 20:23.22 | CIA-40 | BRL-CAD: was finally able to pin down a reproducible-yet-previously just rumored bug |
| 20:23.22 | CIA-40 | BRL-CAD: about 'slow renderings' to some problem with remove fbserv's. Problem minimally |
| 20:23.22 | CIA-40 | BRL-CAD: occurs with an fbserv running a /dev/X interface >512 pixels wide for -i or |
| 20:23.22 | CIA-40 | BRL-CAD: (more interestingly) >600 without -i. |
| 20:23.50 | starseeker | blinks - profiling of the interactive rt -i results in 46% time spent in ml_set_interrupts_enabled |
| 20:24.02 | *** join/#brlcad hippieindamakin8 (n=hippiein@202.3.77.38) |
| 20:24.06 | brlcad | gprof? |
| 20:24.20 | brlcad | what's calling that? |
| 20:24.24 | starseeker | shark |
| 20:24.27 | starseeker | not sure yet |
| 20:24.41 | brlcad | click the little arrow |
| 20:25.01 | starseeker | seems to have something to do with semaphore_wait_signal_trap |
| 20:25.18 | brlcad | that'd be thread contention |
| 20:25.20 | brlcad | tests |
| 20:25.33 | starseeker | find_user_regs is the last entry |
| 20:25.39 | starseeker | for that subtree at least |
| 20:25.45 | brlcad | nope, still slow with -P1 |
| 20:26.26 | brlcad | I still suspect it's some buffering packet size issue |
| 20:26.32 | starseeker | yeah, probably |
| 20:26.40 | starseeker | hunts gprof docs |
| 20:27.06 | ``Erik | <PROTECTED> |
| 20:27.30 | brlcad | --enable-profiling |
| 20:27.43 | brlcad | (which just adds the -pg to the right places |
| 20:27.56 | starseeker | ah, build time |
| 20:27.57 | starseeker | k |
| 20:28.15 | brlcad | yeah, complete recompile |
| 20:28.34 | brlcad | then you run the app(s) and they'll leave little gmon.out file turds everywhere |
| 20:28.58 | brlcad | then when you run gprof, it reads the turds and the binary and produces the call tree |
| 20:29.15 | ``Erik | sometimes app.gmon iirc, depends on the os |
| 20:33.15 | starseeker | hrm - is rem_write the remote write command? |
| 20:35.56 | starseeker | If shark's Time Profile (All Thread States) is getting close to wall clock capture, rt is spending virtually all its time in rem_write and fbserve is in libSystem.B.dylib's select, called by fbserve main |
| 20:39.02 | starseeker | is somewhat confused - why would rem_write be slow but pkg_2send be fast? |
| 20:40.00 | starseeker | oh, wait - pkg_2send is the top call |
| 20:40.54 | starseeker | ok, that's odd but makes more sense |
| 20:43.40 | starseeker | brlcad: just curious - are the hardcoded numbers at pkg.c:1103 of any concern? |
| 20:48.27 | starseeker | notices the HAVE_WRITEV flag - nevermind |
| 21:22.16 | brlcad | starseeker: hard-coded numbers are always a concern, but much harder to avoid with networking code |
| 21:22.51 | brlcad | easy enough buck-shot test though |
| 21:23.43 | brlcad | ah, no matter, that's in an else block that isn't reached |
| 21:24.49 | brlcad | finishes reading what starseeker said and realizes you realized that too |
| 21:31.42 | starseeker | gprof has most of the calls going to _pkg_glong, __pkg_inget, and _pkg_gshort |
| 21:31.48 | starseeker | for rt |
| 21:32.28 | starseeker | didn't do a time breakdown though |
| 21:34.18 | starseeker | oh, I see |
| 21:34.39 | brlcad | oh, that is cool .. libpkg debugging is turned on if you just touch a file or set an ENV var |
| 21:36.05 | brlcad | okay, so eliminated that thought -- it is just sending one packet per scanline |
| 21:36.16 | brlcad | not per pixel |
| 21:44.23 | starseeker | sees story about idea of API for congressional data and cheers |
| 21:44.28 | starseeker | has had that idea for quite a while |
| 21:44.38 | starseeker | doubt it will ever happen though |
| 21:49.03 | brlcad | tries for the fifth time to successfully merge without getting a connection abort |
| 21:55.42 | starseeker | interesting - the files generated for the step class library build on the Mac do NOT have the double static instances |
| 21:56.55 | starseeker | wonders what is foobared on his home box this time |
| 21:57.08 | brlcad | user error |
| 21:57.57 | starseeker | for a fully automated build process? Well, maybe, but I don't know that my week has been THAT bad... |
| 21:58.45 | brlcad | there's no such thing as fully automated ;) |
| 21:59.15 | brlcad | ours is "fully automated" for many configurations and we could/do? document it as such, but there are still plenty of configurations that cannot be accounted for |
| 21:59.29 | starseeker | true |
| 21:59.31 | brlcad | a few flags, a few settings |
| 21:59.48 | starseeker | suspects flex/yacc setup is wonky... |
| 22:00.22 | brlcad | usually |
| 22:00.41 | brlcad | that's neat.. breaking on rem_write |
| 22:00.51 | brlcad | c to render one line at a time :) |
| 22:00.53 | starseeker | at least it's working on OSX and Linux here if it comes to that |
| 22:00.55 | brlcad | click click click |
| 22:01.00 | starseeker | heh - cool :-) |
| 22:01.13 | starseeker | are you seeing what I was with performance bottlenecks? |
| 22:01.30 | brlcad | i'm not looking at that, figured you were |
| 22:01.36 | starseeker | ah |
| 22:01.52 | brlcad | no sense doing things twice ;) |
| 22:02.45 | starseeker | heh - well, I'm trying at least. If it's sending one scan line at a time... hmm... |
| 22:04.25 | starseeker | is spoiled by Shark and blinks at gprof's output |
| 22:07.33 | starseeker | brlcad: any idea why gprof isn't giving me any % time? |
| 22:07.49 | starseeker | or rather, possible causes of it not doing so? |
| 22:09.02 | brlcad | it's all in the opts, I don't remember my gprof foo |
| 22:09.22 | brlcad | -F, looks like it |
| 22:10.03 | brlcad | hah, did not know about -E mcount |
| 22:10.10 | brlcad | that would have been useful a few years ago |
| 22:10.16 | brlcad | shakes fist |
| 22:10.22 | starseeker | what is moncount I wonder |
| 22:11.00 | brlcad | some thing |
| 22:11.07 | brlcad | it's their monitor counter |
| 22:11.34 | brlcad | basically it's spending a lot of time in the profiler code itself because of a lot of calls, so it shows up |
| 22:11.40 | starseeker | ah |
| 22:11.44 | brlcad | -E moncount would make it go away |
| 22:11.51 | brlcad | so will -F though, if you use it |
| 22:12.10 | ``Erik | schrödinger's profiler |
| 22:12.43 | brlcad | if this last merge fails, I'm going to give up doing it from yonder busted network |
| 22:13.02 | *** join/#brlcad astrobear (n=ib@unaffiliated/ibuffy) |
| 22:13.25 | brlcad | hugs the stellar bear |
| 22:13.26 | starseeker | usually has to do it in sub-directory merges |
| 22:14.40 | *** join/#brlcad astrobear (n=ib@unaffiliated/ibuffy) |
| 22:14.57 | brlcad | so far, a very clean merge, but the net keeps dropping out |
| 22:15.10 | starseeker | fun |
| 22:15.43 | starseeker | does subdirs to make "bite sized" chunks that can slip between network outages |
| 22:16.10 | starseeker | wonder if they can make the subversion commit routine more robust to network drops somehow... |
| 22:16.52 | brlcad | I'm not sure if doing subdirs will make an impact on what revision sets it will attempt to apply |
| 22:17.05 | starseeker | hmm, that's a point |
| 22:31.00 | *** join/#brlcad smurfette (n=user@c-69-242-189-29.hsd1.mo.comcast.net) |
| 23:16.00 | *** join/#brlcad ``Erik_ (i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 23:21.34 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-241.sbndin.btas.verizon.net) |
| 23:29.48 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) |
| 23:34.49 | *** join/#brlcad samrose (n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |