| 01:15.56 | ``Erik | *yawn* |
| 02:08.49 | CIA-5 | BRL-CAD: 03johnranderson * 10brlcad/src/conv/iges/trimsurf.c: Convtrimsurfs() was calling nmg_km() when it shouldn't |
| 02:11.52 | CIA-5 | BRL-CAD: 03johnranderson * 10brlcad/src/librt/g_nmg.c: rt_nmg_export5() broke out of loop too early. Changed "break" into an if block |
| 02:57.07 | *** join/#brlcad PrezKennedy (n=Apathy@pcp0011645240pcs.aberdn01.md.comcast.net) | |
| 05:11.15 | *** join/#brlcad DTRemenak (n=DTRemena@DHCP-170-143.caltech.edu) | |
| 05:43.13 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/NEWS: john fixed bug in dxf-g and nmg export |
| 06:23.14 | pra5ad | well then |
| 06:23.18 | pra5ad | lil john was a hit |
| 06:23.26 | pra5ad | need to bug ppl for pix |
| 14:57.18 | *** join/#brlcad ``Erik (i=erik@pcp0011474399pcs.chrchv01.md.comcast.net) | |
| 15:09.45 | ``Erik | *yawn* |
| 17:26.21 | *** join/#brlcad PrezKennedy (n=Apathy@pcp0011645240pcs.aberdn01.md.comcast.net) | |
| 17:26.51 | *** join/#brlcad AchiestDragon (n=dave@whipy.demon.co.uk) | |
| 18:22.17 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/NEWS: added los and material name support to librtserver |
| 18:35.34 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/NEWS: point parsing/import interface to mged |
| 18:37.46 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/other/Makefile.am: jove must come after termlib (fixes sf bug 1342352 from nohn) |
| 20:36.07 | AchiestDragon | :( |
| 20:36.10 | AchiestDragon | config.status: error: cannot find input file: src/conv/comgeom/Makefile.in |
| 20:38.33 | AchiestDragon | after cvs up |
| 20:39.08 | AchiestDragon | the dir src/conv/comgeom is present in the tree but empty |
| 20:42.49 | brlcad | AchiestDragon: update -dP ? |
| 20:44.46 | brlcad | if you did update -dP, then anonymous is just lagging, but it should have those updates by now |
| 20:45.51 | AchiestDragon | did >cvs up first ,, just tryed > cvs up -dP ,, and still get same error on ./configure |
| 20:46.26 | brlcad | did cvs update -dP update files? |
| 20:46.47 | AchiestDragon | yes |
| 20:47.05 | AchiestDragon | the up is to update isnt it |
| 20:47.09 | brlcad | good, then you'll need to ./autogen.sh again since there are new/modified Makefile.ams |
| 20:47.28 | brlcad | yes up == update |
| 20:52.07 | AchiestDragon | :) |
| 20:54.18 | brlcad | you have to run autogen.sh or autoreconf anytime a Makefile.am is added or changes |
| 20:54.56 | AchiestDragon | is used to kde where its > make -f Makefile.cvs |
| 20:55.31 | ``Erik | o.O |
| 20:56.04 | brlcad | heh |
| 20:56.28 | brlcad | i suppose we could add such a makefile, but it's generally more common to just reautogen in projects |
| 20:57.02 | ``Erik | heh, or gmake and let it autoregen for you |
| 20:58.55 | brlcad | gmake doesn't run it for you.. the makefile has rules to update them if configure/autoconf detected a gnu make |
| 20:59.23 | brlcad | and detected the tools necessary |
| 20:59.42 | ``Erik | meh, functionally equivelant |
| 21:00.02 | ``Erik | update Makefile.am, run gmake, automake is run *shrug* |
| 21:00.17 | AchiestDragon | np as long as theres a way , |
| 21:00.46 | ``Erik | automake-1.9, for example, does nto exist on fbsd, it's automake19 ... |
| 21:01.29 | ``Erik | and i'm not quite sure who to shake my fist at... gnu for sucking, or fbsd for cockblocking |
| 21:01.50 | ``Erik | heh |
| 21:01.59 | brlcad | either/both should be a little more accommodating |
| 21:02.02 | ``Erik | indeed |
| 21:02.42 | ``Erik | the gnu guys imagine that everyone is using gnu/linux, and the fbsd guys consider autoconf an unnecessary burden, since everyone should be using fbsd |
| 21:02.44 | AchiestDragon | prefer the ./configure ,, make ,, make install, way its what im used to , if its ./autogen.sh first then fine |
| 21:03.12 | brlcad | AchiestDragon: it's only autogen.sh first because you are working out of CVS |
| 21:03.16 | ``Erik | "configure && make && make install" is a post-developer type setup... if you grab the tarball of brlcad, it's that way |
| 21:03.24 | brlcad | if you download a source tarball, it's just ./configure make make install |
| 21:03.39 | AchiestDragon | yes understand that |
| 21:03.52 | ``Erik | and it's a whole hell of a lot better than "cake" imho |
| 21:03.54 | brlcad | all configure-based projects are that way |
| 21:04.10 | brlcad | yep |
| 21:04.41 | ``Erik | *sigh* I used to do valuable things before this damn m3 project. :( |
| 21:05.10 | ``Erik | and I can't convince justin to step out and say "I need erik's help for blah |
| 21:13.22 | ``Erik | o.O |
| 21:15.44 | AchiestDragon | getting alot of :- |
| 21:15.56 | AchiestDragon | <PROTECTED> |
| 21:17.57 | brlcad | not important |
| 21:35.14 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/configure.ac: see if they have sched.h (aix fix) |
| 21:35.26 | ``Erik | heh |
| 21:38.01 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/libbu/parallel.c: include sched.h if it's available instead of sys/sched.h (aix fix) |
| 21:53.24 | AchiestDragon | well compiled and now running ok |
| 21:53.39 | AchiestDragon | still no archer for linux |
| 21:57.05 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/NEWS: fixed jove compilation issues |
| 21:59.27 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/ (14 files in 9 dirs): remove C++-style // comments as there's no assumption of c99 compiler compliance yet, only c89 (mostly aix compiler though other old compilers too) |
| 21:59.45 | brlcad | AchiestDragon: when you see commit messages about merging bobWinPort to HEAD will be when archer starts to appear ;) |
| 21:59.57 | AchiestDragon | k :) |
| 22:14.53 | AchiestDragon | another bug ? |
| 22:15.39 | AchiestDragon | http://www.whipy.demon.co.uk/snapshot11.png < graphics window does not update while error message is beeing displayed |
| 22:17.15 | brlcad | not exactly a bug, but certainly bad/undesirable behavior |
| 22:40.20 | ``Erik | I'm under the impression that nmg stuff is ass buggy |
| 22:41.04 | brlcad | some bugs |
| 22:41.07 | brlcad | lots of complexity |
| 22:41.24 | ``Erik | it's the part that handles facetization, right? |
| 22:41.33 | brlcad | the complexity gets it more than anything, lots of cases not accounted for (as they were never encountered during development) |
| 22:42.03 | brlcad | so they are encountered finally, and then bad things happen "sometimes" (sometimes not too) |
| 22:42.15 | brlcad | yeah, that's what handles facetization |
| 22:42.26 | ``Erik | which is ass slow and buggy... :D *duck* |
| 22:43.40 | ``Erik | O.o |
| 22:44.01 | ``Erik | and losing half your geometry during teh 2nmg pass is uncool |
| 22:44.19 | ``Erik | if only someone had the time to fix it... |
| 22:46.05 | brlcad | well, the alternative in those cases is abort or crash |
| 22:46.23 | brlcad | since it was something unknown |
| 22:46.40 | brlcad | it is ass slow and buggy |
| 22:47.06 | ``Erik | personally, I'd favor noise abort, with a flag to force 'bad data' to be allowed |
| 22:47.10 | ``Erik | noisey, even |
| 22:47.23 | ``Erik | loss of data is a cardinal sin o.O |
| 22:47.49 | brlcad | it's not bad data though - just don't know how to handle it (yet) |
| 22:48.10 | brlcad | and not converting anything is generally even less useful than converting something :) |
| 22:48.14 | ``Erik | well, it's a loss of data |
| 22:48.46 | ``Erik | if I convert object X to object Y, and Y is missing big honkin' chunks, what use was the conversion? |
| 22:48.49 | brlcad | data's already being "lost" because we're going from an implicit model to an explicit one |
| 22:49.20 | ``Erik | true, it's coarser by necessity, but when entire regions simply vanish...? |
| 22:49.39 | brlcad | the use is that you can always convert subportions when a higher level might fail |
| 22:50.06 | brlcad | so even if a portion is missing, I could figure out which that was, and export that one individually |
| 22:50.40 | brlcad | (which was the process in the past when there wasn't time to debug) |
| 22:50.50 | ``Erik | *shrug* i'm still brlcad illiterate, so'z all I can see is "lots of shit is missing" |
| 22:54.04 | brlcad | maybe i'll beat mike to reimplementing a new tesselator *cough* |
| 22:54.16 | ``Erik | <-- looks at the clock |
| 22:54.17 | brlcad | he's somewhat tasked with that indirectly via meshing |
| 22:54.24 | ``Erik | better step to that, you only have, um |
| 22:54.26 | ``Erik | 20 or so years |
| 22:54.53 | ``Erik | I thought he was tasked with a voxel generator? |
| 22:55.24 | ``Erik | extracting voxel info from brlcad geometry might take a whole 2 hours? the hard part is writing to the "common" format |
| 22:55.47 | brlcad | depends who you ask and for what |
| 22:56.05 | brlcad | fem analysis is the base need |
| 22:56.08 | ``Erik | what's the voxel format lee decided is necessary? starts with n? |
| 22:56.26 | brlcad | voxels is stuff lee's thinking is sufficient |
| 22:56.49 | brlcad | though hardly _any_ fem codes prefer regularly gridded meshes |
| 22:57.15 | ``Erik | heh |
| 22:57.19 | brlcad | you just don't get good energy simulation/propagation with regularlized voxel grids |
| 22:57.34 | brlcad | most use adaptive tetrahedral meshes |
| 22:57.42 | ``Erik | cutting edge is mixed tetrahedron and hexahedron mesh with an active wall |
| 22:57.50 | brlcad | yeah |
| 22:58.18 | ``Erik | I tried to tell wendy that I'd be perfect for the fem shit |
| 22:58.20 | ``Erik | o.O |
| 22:59.02 | brlcad | i don't think the direction he's suggesting is a good one at all, rather nieve direction really but who knows, it might be sufficient |
| 22:59.08 | brlcad | even if it's inherintly wrong |
| 22:59.14 | brlcad | or utterly inefficient |
| 22:59.27 | ``Erik | who, lee? |
| 22:59.44 | brlcad | who else |
| 22:59.52 | ``Erik | <-- swigs more flammable shit |
| 22:59.53 | ``Erik | o.O |
| 23:00.11 | ``Erik | hm, "chronicles of riddick" is on tv |
| 23:00.30 | ``Erik | sometimes lee has a good idea, but I think they may be diamonds in a turd pile |
| 23:00.44 | brlcad | there were several excellent meshing papers at solid modeling, he's totally ignoring current research |
| 23:00.55 | ``Erik | but at least when proven wrong, he's willing to admit he was wrong, no? |
| 23:01.01 | ``Erik | unlike... many.... |
| 23:01.02 | ``Erik | :) |
| 23:01.10 | brlcad | :) |
| 23:01.30 | brlcad | also not that the person tasked will be able to implement any of the latest ideas |
| 23:01.53 | brlcad | or even what's currently being suggested |
| 23:01.59 | ``Erik | he also provides an effective and astonishing level of protection for those under him, I didn't realize to what extent until after the 'team split' |
| 23:01.59 | brlcad | without lots of help |
| 23:02.29 | ``Erik | if by "help" you mean someone doing for him... :D |
| 23:03.20 | ``Erik | he might actually have some ability, I've just never seen him actually produce |
| 23:03.47 | brlcad | he's good at fast solutions to a specific problem |
| 23:03.54 | ``Erik | (he who? I mean mg) |
| 23:04.01 | brlcad | might not be maintainable, or readable, or extensible |
| 23:04.13 | brlcad | but it usually works, and works well enough for what was needed at the time ;) |
| 23:04.26 | brlcad | and didn't take too long to implement |
| 23:04.37 | brlcad | at least if we're talking code |
| 23:05.16 | brlcad | ahh, i didnt mean him of course if it wasn't obvious.. ;) |
| 23:06.41 | ``Erik | figured, heh |
| 23:07.12 | ``Erik | <-- watches chronicles of riddick and waits for his tamales and margarita |
| 23:51.29 | AchiestDragon | given current situation here , going to have to spend some time securing the firewall , and getting up to date on net securaty |
| 23:52.08 | AchiestDragon | and find out what legal action i can take against yahoo :( |
| 23:52.57 | AchiestDragon | dam spammers |
