IRC log for #brlcad on 20090713

02:15.03*** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6)
02:50.12CIA-32BRL-CAD: 03indianlarry * r35080 10/brlcad/trunk/src/librt/primitives/brep/brep.cpp:
02:50.12CIA-32BRL-CAD: added adjacent face code to curve trims, also added cleanup of face hitlist
02:50.14CIA-32BRL-CAD: for cases where multiple INs/OUTs of faces encountered
02:53.22CIA-32BRL-CAD: 03indianlarry * r35081 10/brlcad/trunk/include/opennurbs_ext.h: add adjacent face code to curve trims
02:54.49CIA-32BRL-CAD: 03indianlarry * r35082 10/brlcad/trunk/src/librt/opennurbs_ext.cpp: add adjacent face code to trim curves
02:56.12CIA-32BRL-CAD: 03indianlarry * r35083 10/brlcad/trunk/src/ (libged/brep.c librt/primitives/brep/brep_debug.cpp): added more debugging code/options to mged brep command
06:53.34Ralithbrlcad: I'd like to discuss the possibility of just not rendering Qt into the OpenGL context, at least for now; most of the rest of what I proposed to work on can be completed with Qt simply sitting on *top* of the context, although some parts might not be quite as shiny as would otherwise be possible.
06:54.43Ralithand I don't think it would take much rewriting to modify said work to operate inside a GL context when a way is (hopefully) eventually found.
06:55.24Ralithconsidering how standard Qt widgets and even entire windows can be literally dropped directly in with little or no special consideration.
06:56.25RalithI can produce much more visible and interesting work this way, and continue conversations with more Ogre- and Qt-knowledgable people to work out the GL issue in the background.
07:02.54*** join/#brlcad LarsG (n=lars@dial208-53.dialup.nus.edu.sg)
07:03.01*** part/#brlcad LarsG (n=lars@dial208-53.dialup.nus.edu.sg)
07:25.07*** join/#brlcad _clock_ (n=_sushi_@77-58-151-159.dclient.hispeed.ch)
11:59.00d-loMernin all!!
12:19.45*** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-7.sbndin.btas.verizon.net)
12:36.47*** join/#brlcad docelic_ (n=docelic@78.134.200.170)
13:01.37``Erik*burp*
13:03.04``Erikany news on the injector/server project, d-lo?
13:36.17CIA-32BRL-CAD: 03brlcad * r35084 10/brlcad/trunk/src/other/step/src/cleditor/STEPfile.inline.cc:
13:36.19CIA-32BRL-CAD: apply a simple patch that should hopefully fix sf bug 2820579, reported by Jeff
13:36.21CIA-32BRL-CAD: Meldrum (jspaces) regarding a const to non-const conversion. according to a
13:36.23CIA-32BRL-CAD: handful of online sources, c++ apparently changes the signature of strrchr from
13:36.25CIA-32BRL-CAD: the posix C decl with two overloaded possibilities, both input and return are
13:36.27CIA-32BRL-CAD: either const or non-const.
13:54.40CIA-32BRL-CAD: 03irpguardian * r35085 10/brlcad/trunk/src/proc-db/human.c: Changed the torso parts to use a TGC instead of a RCC to make it less bulkly looking, and more human shaped.
14:26.55*** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz)
14:30.19d_rossbergd-lo: to have a header file with defines for the version numbers appears to be an issue of its own
14:36.17d_rossbergd-lo: because of the common.h issue i need to have a look at my linux build at home ...
14:39.05d-loah!  minimized the irc window.  Sorry.
14:39.36d-lofyi a simple rename of common.h to cicommon.h worked like a champ.
14:40.14d-loLooking through things, I see that in order to generate {RT3}/include/brlcad/brlcadversion.h, you have to have the source from the BRLCAD module.
14:41.00d-loOne of the assumptions I am making for the CMake build system in the rt^3 module is that, at a minimum, there is a BRLCAD install on the machine.  Not necessarily the source.
14:41.24d-loso I suppose I need to find out if there is a way to extract versioning information from a BRLCAD install.
14:41.28d-lo.... anyone know?
14:42.02d_rossbergthis would have been my next question :)
14:42.23*** join/#brlcad mafm (n=mafm@83.42.152.74)
14:42.32d-loi remember running across it somewheres.... just gotta find it :/
14:43.27d-loThere is a string reference to the package version on line 412 in brlcad_config.h
14:44.35d-loheh, I don't even know if its possible to do string parsing with CMake....
14:45.31_clock_d-lo: if it's turing equivalent then definitely yes :)
14:48.35d_rossbergmy philosophy with the core Interface is something different from yours:
14:48.50d_rossbergthe core interface is the interface for external programs
14:49.13d_rossbergthere shouldn't be any other include/brlcad
14:50.07d_rossbergand, to be honest we don't have such a directory at the moment
14:50.21d-loHrm, then, I suppose, the question is:  Why are there coreInterface include files in rt3? By that philosphy, shouldn't they be in the brlcad module?
14:50.40d_rossbergthe include/brlcad from the installation has to be added explicitely (i hink) to the inlude paths
14:50.56d_rossbergd-lo: yes
14:51.03d-lothe include/brlcad from the BRLCAD installation?
14:51.10d_rossberghowever, that's my opinion
14:51.25d_rossbergthe one you have the problem with
14:52.59d_rossbergnow i remember: i added only the include/brlcad directory from the installation to the include paths
14:53.08d-loHeh, well, if its your opinion that they should be in the BRLCAD module... put em there :)  They're your babies, store them wherever you want :)  don't let that BRLCAD guy tell you otherwise :)
14:53.29d_rossbergi.e. not the inlude directory alone
14:54.22d-loah, so {BRLCAD_INSTALL_PATH}/include/brlcad/ and not {BRLCAD_INSTALL_PATH}/include/ ?
14:54.35d_rossbergthis way i didn't get the confusion between the two common.h
14:54.46d_rossbergd-lo: yes
14:55.53d-loAnother question then:  What is stopping you from moving the coreInterface files into the brlcad module?
14:57.44d-lodoesn't want to sound offensive. Just trying to get rt^3 whipped into shape.
14:58.07d_rossbergthere are still some incompatibilities: e.g. which files should be copied into the installation directory at include/brlcad ? :)
14:59.38d-lowhy not put all your headers into include/brlcad/ci/ ?
14:59.46d-loresolves a lot of problems...
15:00.15d_rossbergno, they are intended for include/brlcad
15:00.50d_rossbergon the other side, d-lo, you have a point ther with the common.h issue
15:01.15d-loheh, well I am good at causing, er, finding problems.
15:01.42d_rossbergthe core interface should be usable in virtually every program
15:02.20d-loRight, but how does having the includes in include/brlcad/ci/ change that?  *confused*
15:03.19d_rossbergi.e. we may solve the issue with our own includes, but it could be wise to have a prefix for the BRL-CAd headers
15:03.53d_rossberg... i see the ci as the only interface, so why should it be in a subdirectory?
15:04.32d-loOrganizational reason only.  
15:05.03d-loAs far as I can tell, common.h is the only conflict.  all the rest of the coreInterface headers don't conflict.
15:05.34d-loAnd for organizational reasons, you are thinking that there should be prefixes on headers?   Did I understand that correctly?
15:06.57d_rossbergat the moment it is only an idea, i thought brlcad/ is already prefix enough ...
15:07.16d-loah, okay.  I see what you mean.
15:07.52d-loI haven't looked at the difference in the files, but is there a way to merge the two common.h's or should it be solved by a rename of one of them?
15:08.31d_rossbergyou could rename it to brlcadcommon.h
15:08.44d_rossbergthis name would match with brlcadversion.h
15:09.30d-loso rt^3/include/brlcad/common.h -> rt^3/include/brlcad/brlcadcommon.h ?
15:09.39d_rossbergyes
15:10.10d-loand then once that rename is done, would there be any other problems moving the coreInterface files to the brlcad module?
15:10.14d_rossbergand maybe rt^3/include/brlcad/globals.h ->
15:10.28d_rossbergrt^3/include/brlcad/brlcadglobals.h
15:10.39d-lookay, the globals makes sense also.
15:11.01d_rossbergthe other file names start with a capital letter
15:11.07d_rossbergi.e. are unique
15:11.42d_rossberg(at least fot *IX)
15:12.10d-loright on.
15:13.03d-loIf you would like, I can move the coreInterface files over to the BRLCAD module... or I can just leave them where they are and unwire them from the CMake build system I am making.  Your choice, whatever you feel like. :)
15:16.29CIA-32BRL-CAD: 03davidloman * r35086 10/rt^3/trunk/cmake/FindBRLCAD.cmake: Fixing some bugs in FindBRLCAD.cmake
15:21.38d_rossberghow does this go together with your plans with the "Geometry Engine"?
15:22.34d-loI am working on changing the whol rt3 module over to CMake, and since coreInterface is in the rt3 module, I assumed I needed to work it in to the build also.
15:24.46d_rossbergi meant you wanted to make the coreInterface part of your GE
15:26.35d_rossberghas to go now
15:51.00brlcad~seen madant
15:51.01ibotmadant <i=cb7baf0f@gateway/web/freenode/x-a32eed164597bd06> was last seen on IRC in channel #brlcad, 9d 19h 29m 7s ago, saying: 'nothing more disastrous than non-cooperative softwares ;)'.
15:51.30d-lowow... 9 days
15:58.40CIA-32BRL-CAD: 03davidloman * r35087 10/rt^3/trunk/src/ (3 files in 3 dirs): Unwiring coreInterface from CMake for now. There is a dependancy that requires the brlcad source to be present on the computer instead of just the installation.
15:58.41d-lohowdy brlcad !
16:08.45d-lohates having an ogre<->boost dep.
16:08.49d-lobangs head on wall.
16:18.15d-loRalith:  based on what I have read, I think your current approach is the best.  You may have to modify your GSoC goals though.
16:20.22brlcadboost is an easy dep, just a bunch of header files :)
16:20.59d-loright, but ogre isn't building without it.  Even when i set OGRE_USE_BOOST to OFF, it still tries to link against it :/
16:21.21brlcadso? .. don't turn it off..
16:21.46d-lonot to mention, when it IS properly linking, its claiming that boost::thread::hardware_concurrency() doesn't exist... when it does.  grrr.
16:22.01brlcador you mean they don't provide it and our subset doesn't provide what they need either?
16:22.05d-loRight, I have tried it both ways, both have compile problems.
16:22.21d-loI have boost installed in its entirety.
16:22.27brlcadboost threading is in the core, which brlcad module provides
16:22.47d-loEven with that, ogre is failing
16:23.00brlcadthen that's a problem with ogre, not boost
16:23.08d-loright.
16:23.16d-lonever said it wasn't. :)
16:23.50brlcadwell the "hate" is still somewhat misplaced :)
16:24.19brlcadi mean you're free to hate whatever you want, of course :)
16:24.27d-loI was gonna say...
16:24.33d-loits MY hate not yours.
16:24.35d-loget your own
16:24.41brlcadi hate you!
16:24.48d-lo*GASP*
16:24.59d-loDon't me hatin
16:25.14brlcadhates d-lo's ogre<->boost hate
16:25.41d-loI figure since Ogre loves boost so much, I *MUST* hate boost.  Seems natural.
16:27.18brlcadaside: you do know that most/many of the core (tr1) components of boost are going to become part of the c++ standard, yes?
16:27.18d-lowhen I build BRLCAD and install it, does libboostcore get installed also>
16:27.20d-lo?
16:27.53d-loYeah, you mentioned that.  I figure that will be a good time to become a pure C Zealot.  ;)
16:28.09brlcadheh
16:29.26brlcadlibboostcore??
16:30.05d-loyes, boost's core lib that you said is in the brlcad module.
16:30.17brlcadit's not a lib, it's headers
16:30.24d-lowell, whateveritsactuallycalled.
16:30.53d-loso it gets installed then?
16:31.22brlcadif you mean do we install the headers, I don't believe so at the moment as there was no need
16:32.00brlcadwould be trivial to install, but if we do that, we probably should bundle more than we are bundling so it's a complete dependency
16:32.06brlcadnot a subset like it presently is
16:32.15d-loWell hell.  How am I going to make Ogre behave then..... hrm
16:32.23brlcador you make rt^3's build require having a brlcad source tree as well
16:32.39brlcador you just require folks install all of boost first, old school
16:33.53d-loI was wondering about that...  what would be your opinion of 'best practice'?  Linking rt3 to a brlcad install or making rt3 dependant on the brlcad source?
16:38.21brlcadplenty of projects do both, the latter tends to suck more as it's just mostly dev convenience
16:38.36brlcadrt3 already requires a brlcad install, that's inevitable
16:39.21brlcadand our project practice is towards dependency management, not user-required actions (having them install boost would be a user-required dependency action)
16:39.44brlcadshort term, though, doesn't really matter -- so, they have to install qt+boost
16:40.18brlcadlong term, can probably upgrade the boost dep in brlcad module to a full copy and have it fully managed like other deps
16:41.44d-loalrighty then.
16:41.58d-loHave you read up on what Dr Rossberg and I were yaking about?
16:42.18starseekerthinks cracking proper Qt/OGRE integration would be very useful, even if it produces less visible result...
16:43.46d-lostarseeker: when I get install permission failures concerning tkhtml3, do i need to --disable-documentation to bypass that?
16:44.11brlcadnot yet, working on evals
16:44.11starseekerno, that's a mistake in the make file
16:44.24starseekeris that that nroff thing?
16:44.25d-lobrlcad: okie.
16:44.30starseekerhuts
16:44.34starseekerer, hunts even
16:44.42brlcadhas indianlarry done his eval yet?
16:44.53brlcadhe hadn't as of this morning
16:45.00brlcadonly has an hour or so before the deadline
16:45.05starseekerI'll ask
16:49.19starseekerd-lo: what's the specific failure on the permission?
16:49.44d-loI don't have access to /usr
16:49.50d-loerr write access
16:51.45starseekerhmm.
16:52.02starseekerI remember seeing that, and it had something to do with tkhtml.n
17:05.21CIA-32BRL-CAD: 03starseeker * r35088 10/brlcad/trunk/src/other/tkhtml3/Makefile.in: Don't set DESTDIR to empty in tkhtml3 Makefile.in
17:05.28starseekerd-lo: does that help?
17:05.43d-lolemme check.
17:09.42*** join/#brlcad jdoliner (n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net)
17:09.53d-lo*buildbuildbuild*
17:13.04d-lostarseeker:  Nope :(   still getting:  mkdir: cannot create directory `/usr/lib/Tkhtml3.0': Permission denied when trying to install to /home/dloman/
17:13.24starseekerhmm
17:16.55starseekergrr
17:21.58brlcadcould be some DESTDIR problem if there are custom install rules (not that there should be custom install rules)
17:22.40starseekeris wondering if the TEA extensions are getting into the act
17:22.50brlcadhm, could be
17:22.57brlcadloooks like they do have DESTDIR properly
17:23.20starseekerthat's why I nuked the empty DESTDIR line - thought perhaps that was killing the DESTDIR feed from configure
17:23.42starseekerwonder why it doesn't happen on all platforms...
17:24.19starseekerponders a pleading email to the TEA devs to integrate with autoconf/automake out of the box...
17:24.24brlcadmaybe it does
17:24.41starseekerjust did a make install on the mac - went to my local directory
17:24.52brlcadhave him send you his Makefile that was generated, compare it to yours
17:25.45d-lostarseeker: do you have write permissions to /usr/lib/ ?
17:25.54starseekerI shouldn't
17:26.14starseekernope
17:26.21d-lostarseeker: FYI, just got same error.
17:27.01d-lowhere is the brlcad.org pastbin again?
17:27.19starseeker~pastebin
17:27.20ibot[~pastebin] A "pastebin" is a web-based service where you can paste anything over 3 lines without flooding the channel. Here are links to a few : http://www.pastebin.com , http://pastebin.ca , http://channels.debian.net/paste , http://paste.lisp.org , http://www.rafb.net/paste
17:28.02starseekerwell, I don't see ours there...
17:29.00d-loah ha:  http://pastebin.bzflag.bz/
17:30.29d-lostarseeker: http://pastebin.bzflag.bz/m94c45f1
17:33.18``Erik*readreadread*
17:33.54brlcadd-lo: you can tell rain that I made her some ceviche de camarones
17:33.56brlcadi'll bring some in for everyone to try tomorrow
17:34.07d-lokk
17:34.08``Erikthat sounds... so.. wrong...
17:34.35brlcadso yummy!
17:34.47d-lofrom Rain:  Spicy
17:34.48d-lo?
17:35.04d-lo'Rain's Spicy' that is.
17:43.54*** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-7.sbndin.btas.verizon.net)
17:52.19CIA-32BRL-CAD: 03erikgreenwald * r35089 10/isst/trunk/src/main.c: set database and master hostnames in main()
17:53.31CIA-32BRL-CAD: 03erikgreenwald * r35090 10/isst/trunk/src/gui.c: extract attach code out of validation function
17:57.38CIA-32BRL-CAD: 03erikgreenwald * r35091 10/isst/trunk/ (8 files in 2 dirs): indent.
18:02.07CIA-32BRL-CAD: 03erikgreenwald * r35092 10/isst/trunk/src/main.c: fix wrong variable being set. woops.
18:02.18CIA-32BRL-CAD: 03erikgreenwald * r35093 10/isst/trunk/src/gui.c: have .g loading automatically attach to the master daemon.
18:06.38CIA-32BRL-CAD: 03starseeker * r35094 10/brlcad/trunk/src/librt/opennurbs_cleanup.cpp: Ooops - add in the check to ensure bounding box dimensions are not degenerate in x, y or z
18:17.43brlcadnot so spicy
18:17.57brlcadI made it pretty mild
18:18.21brlcadshe'll probably still think it's hot, but it's not anywhere near what I usually do
18:18.39brlcadonly used a few habaneros for nearly 2lbs of shrimp
18:21.44brlcadstarseeker: any reason to not just increment the amount you tested against?
18:22.13brlcadpushing both max and min will make it 2x that value, should be enough
18:22.22brlcadand a lot tighter
18:23.34starseekerbrlcad: That's an option - right now I'm just trying to reproduce the bounding box behavior of the original code
18:23.41starseekerstill not there yet :-(
18:24.46starseekerOnce I do, I can go back and tighten it to the tolerance and see what that does :-)
18:25.00*** join/#brlcad samrose (n=samrose@c-24-11-214-181.hsd1.mi.comcast.net)
18:29.45CIA-32BRL-CAD: 03erikgreenwald * r35095 10/brlcad/trunk/src/adrt/slave/load_g.c: join slave_load_g() and some_intermediate_function()
18:33.27*** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-7.sbndin.btas.verizon.net)
18:35.37``Erik*snrkt* wells fargo sueing itself, grand
18:37.39starseekerso when lawyers run out of targets, they start suing themselves?
18:38.02``Erikit's on /.
18:38.54``Erikcomments seem to indicate the combination of wells fargo having two mortgages on a house and florida law are forcing it to happen *shrug*
18:41.14starseekertalk about poetic justice...
18:47.35*** join/#brlcad louipc (n=louipc@archlinux/trusteduser/louipc)
18:52.29``Erikhere's a better one, deep purple is paying fines for playing their own songs
18:52.34``Erikhttp://techdirt.com/articles/20090710/0340345512.shtml
18:59.50d-lo``Erik: heres SimStapler http://www.freeverse.com/games/game/?id=7022
19:27.01``Eriknice
19:29.33*** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-160.sbndin.btas.verizon.net)
19:33.05``Erikwhat're the build instructions for the gs thingymajigger?
19:35.41d-lo1)  cmake .
19:35.45d-lo2) make
19:35.58d-loQt needs to be in your PATH
19:35.58``Erikok, so I gotta figure out how to get cmake installed
19:36.01``Erikand qt
19:36.19d-loautomake is still working btw.
19:36.28d-loerr autotools build still works.
19:36.54``Erikhm, thought I ran into issues with auto*
19:47.15``Erikhrm, are you building 64b?
19:47.42d-loyes.  whats up?
19:48.06``ErikGS/tests/streamSerialTests.cxx makes some bad assumptions... "unsigned long" being 64b where it's 32 on a 32 bit system
19:48.21``Erikuint64_t might be better for that
19:48.57d-lorighto, its on the lists of things to fix.  That was an ooooooold hack that I never got around to working on yet. ;)
19:49.41d-loWell, I out.  Peace.
19:55.39CIA-32BRL-CAD: 03erikgreenwald * r35096 10/rt^3/trunk/src/tests/streamSerialTests.cxx: use types with explicit widths. Change 'long' to 64b int. Change magic #s to hex (should it be stdint.h INTX_MAX?).
20:10.27CIA-32BRL-CAD: 03irpguardian * r35097 10/brlcad/trunk/src/proc-db/human.c:
20:10.29CIA-32BRL-CAD: Completly redone all functions to take human data structure, as opposed to numerous variables.
20:10.31CIA-32BRL-CAD: However, currently does not build anything, as it bus-fails when attempting to put information into
20:10.33CIA-32BRL-CAD: the human_data->torso->torsoLength location.
20:38.57*** join/#brlcad stevegt_ (n=stevegt@cislunar.TerraLuna.Org)
20:50.25Ralithd-lo: I don't see anything particularly critical about rendering Qt *in* OpenGL.  I mean, it has nice parts and is certainly desirable, but it's quite possible to get by without it—look at the competition.
20:51.51CIA-32BRL-CAD: 03irpguardian * r35098 10/brlcad/trunk/src/proc-db/human.c: Fixed it to where the human builds, but some parts are not in their correct locations
20:58.18*** part/#brlcad jdoliner (n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net)
20:58.53CIA-32BRL-CAD: 03irpguardian * r35099 10/brlcad/trunk/src/proc-db/human.c:
20:58.55CIA-32BRL-CAD: Fixed everything, so now it's a human generator with all variables stored in the human_data_t struct.
20:58.58CIA-32BRL-CAD: Even works with all poses.
21:50.19*** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-160.sbndin.btas.verizon.net)
22:13.25``Erik"fixed everything" hehehe, if only
22:23.26*** join/#brlcad BigAToo1 (n=BigAToo@pool-96-230-124-207.sbndin.btas.verizon.net)
22:48.03``Eriknice, my alma mater made collegehumor.com http://www.freeverse.com/games/game/?id=7022
22:48.07``Erikwoops
22:48.36``Erikhttp://www.collegehumor.com/picture:1916488
22:53.27*** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-207.sbndin.btas.verizon.net)
23:23.01*** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-207.sbndin.btas.verizon.net)
23:28.46``Erik*omnomnom* mm bourbon steak strips
23:29.24*** join/#brlcad BigAToo1 (n=BigAToo@pool-96-230-124-207.sbndin.btas.verizon.net)
23:37.18*** join/#brlcad BigAToo2 (n=BigAToo@pool-96-230-124-207.sbndin.btas.verizon.net)
23:39.05*** join/#brlcad BigAToo3 (n=BigAToo@pool-96-230-124-207.sbndin.btas.verizon.net)
23:39.56*** join/#brlcad BigAToo4 (n=BigAToo@pool-96-230-124-207.sbndin.btas.verizon.net)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.