| 01:00.15 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) |
| 01:45.21 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) |
| 01:53.11 | starseeker | ``Erik: unless BSD has done some serious hacking, APR and APR-util are mandatory for subversion |
| 02:01.49 | *** join/#brlcad dli (~dli@66.49.141.114) |
| 02:07.28 | dli | hi, I wonder whether it's possible to add openGL support for brlcad, so rendering, can be in real time |
| 02:11.30 | starseeker | that depends on what you mean by rendering |
| 02:11.51 | starseeker | if you mean 3D shaded display, the hard part is converting our geometry to the triangles needed to feed OpenGL |
| 02:12.15 | starseeker | if you mean raytracing, you may want to take a look at adrt |
| 02:12.55 | dli | starseeker, raytracing is still slow, I know this part. I just mean to use more features from modern video cards |
| 02:13.35 | starseeker | robust tessellation is a foundation for any shaded display using OpenGL, unless you're talking about raytracing using the GPL |
| 02:13.39 | starseeker | er GPU |
| 02:13.59 | starseeker | we haven't done much in the raytracing with GPU direction |
| 02:14.22 | dli | starseeker, no, I don't expect raytracing on GPU, too much work :( |
| 02:15.21 | dli | starseeker, so, you think it's possible. if true, it would very much exciting, CAD can be a real time simulator then |
| 02:15.50 | starseeker | it's certainly possible, but robust tessellation of CSG geometry is not a simple problem |
| 02:17.04 | dli | starseeker, which level is the cause of problems? conceptual, algorithm, or just have to rewrite a lot? |
| 02:19.07 | CIA-53 | BRL-CAD: 03starseeker * r43150 10/geomcore/trunk/src/other/subversion/COPYING: Whoops - add the subversion COPYING file |
| 02:19.22 | starseeker | dli: both algorithmic and lot of code to wrangle |
| 02:19.33 | starseeker | take a look at the nmg code in librt to get an idea |
| 02:20.47 | dli | starseeker, I will try. I hope I can understand something first |
| 02:21.23 | starseeker | dli: brlcad may be able to give you a better overview of the various options and where a good starting point is |
| 02:21.53 | starseeker | most of the issues I'm familiar with involving tessellation and shaded displays involve "diving off the deep end" |
| 02:22.44 | dli | starseeker, yes, long time ago, I wanted to contribute to this project, but too busy at that time. now, I have should have some time for algorithm and coding |
| 02:23.22 | dli | starseeker, thanks a lot, I will talk to brlcad later |
| 02:23.33 | starseeker | dli: awesome :-) |
| 02:24.09 | starseeker | dli: one good starting point might be to look at one of the convertors in src/conv |
| 02:24.21 | starseeker | most of them invoke tessellation logic |
| 02:24.50 | dli | starseeker, sure, I will try to read as much as possible, to help understanding |
| 02:33.36 | starseeker | looks at the apr configure process and turns white |
| 02:36.56 | starseeker | checks the subversion code a little... |
| 02:41.07 | starseeker | ``Erik: yeah, there's no way they've avoided requiring apr - the entire code base is thick with apr types and calls |
| 02:41.20 | starseeker | removing apr would amount to a total rewrite |
| 03:35.52 | brlcad | dli: technically, we already have opengl support -- you can see it in action with a private debug setting on an opengl-enabled build |
| 03:36.54 | brlcad | the problem is that the way it's currently implemented is at least np-hard, error-prone to numeric drift, slow as balls, and not robust (because it's np-hard) |
| 03:37.25 | dli | brlcad, I see, so, it's not really useful as is |
| 03:37.32 | brlcad | so you can either work on making it more robust (which would be fantastic, but hard) then make it faster (probably the easiest part) |
| 03:38.10 | brlcad | the problem is mostly algorithmic |
| 03:39.12 | brlcad | consider two overlapping spheres, for example, simply defined by a point and a radius, unioned together |
| 03:39.16 | dli | brlcad, I will read the code first :) |
| 03:40.21 | brlcad | current approach basically turns each of the two spheres into a set of polygons (trivial) then evaluates interior, exterior, and overlapping polygons |
| 03:40.36 | starseeker | reluctantly concludes libgit2 is too immature feature wise to be an option for some time, even if we could switch horses now (which we can't) |
| 03:40.36 | brlcad | that's also trivial/easy |
| 03:41.04 | dli | brlcad, how could this be NP? |
| 03:41.06 | brlcad | since it's a union, it throws away the interior polygons, keeps the exterior, and stitches together the overlapping ones trimming away and splicing together correctly |
| 03:41.33 | brlcad | dli: I'm showing you one of the very most simple cases just for understanding of the basic algorithm |
| 03:42.00 | brlcad | it's actually a relatively simple algorithm, but the devil is in the details |
| 03:42.53 | dli | brlcad, because we build the geometry part by part, I suppose the complexity of adding one more primitive is O(N), for N existing primitives |
| 03:42.57 | brlcad | it's not robust for a variety of problems, including floating point drift during the trimming/splicing stage but also because we're evaluating the boolean AFTER tessellating all primitives where we're no longer matching the original surface |
| 03:43.30 | brlcad | that'd be linear complexity, which it is not :) |
| 03:43.52 | brlcad | it's exponential to evaluate the N+1 primitive against the previous N set |
| 03:45.24 | brlcad | there are tons of optimizations possible, you could get the performance down to reasonable levels with some basic space partitioning -- in fact the current code does this for some cases |
| 03:45.31 | dli | brlcad, the complexity of voronoi cell analysis is N log(N), I feel it's similar |
| 03:45.57 | brlcad | the problem with the approach, however, is that it's still basically a lossy approach |
| 03:46.47 | brlcad | so even if you solved the robustness problem with careful numerics and consistently handling all edge cases, there are STILL going to be some comparisons that fundamentally cannot be solved without making a blind guess |
| 03:47.00 | brlcad | that's where NURBS comes in |
| 03:47.26 | brlcad | it's the new approach that will eventually make the current approach obsolete -- the boolean is evaluated prior to tessellation |
| 03:48.49 | brlcad | instead of converting each primitive to a mesh, each is converted to a spline surface, surface-surface intersection calculations are performed (just like done with meshes, marking interior/exterior/overlapping surfaces), surfaces are trimmed according to the boolean, and the resulting *evaluated* surfaces are then trivially tessellated |
| 03:48.51 | dli | brlcad, sounds very interesting to me, I feel I could contribute something here. I did molecular dynamics, genetic aglorithm, voronoi cells, and have some time for coding now |
| 03:49.54 | brlcad | dli: that's fantastic, there are plenty of places you could jump in |
| 03:50.47 | dli | brlcad, give me some clues :) |
| 03:51.12 | brlcad | basically you can either work on our mesh support (i.e., the current approach, which will still be needed even with nurbs, for polygonal surfaces) or.. |
| 03:51.37 | brlcad | you can work on the various outstanding issues with our new nurbs support |
| 03:52.36 | brlcad | surface-surface intersection calculations to derive an intersection curve is one problem still TBD -- robustly tessellating a nurbs surface is another |
| 03:53.07 | dli | brlcad, under src/others/openNURBS/ ? |
| 03:53.10 | brlcad | the mesh processing is much more approachable but will require systematically reviewing thousands and thousands of lines of code, hundreds of functions |
| 03:53.46 | brlcad | depends what your exact goal is :) |
| 03:54.33 | brlcad | I'd set a specific small goal and then it'll be easier to point you in the right direction towards implementing that goal |
| 03:55.09 | dli | brlcad, I think I would try the surface-surface intersection first |
| 03:55.59 | brlcad | okay |
| 03:56.34 | brlcad | then your starting point is probably: http://en.wikipedia.org/wiki/Surface-to-surface_intersection_problem |
| 03:57.13 | brlcad | there are tons of approaches and research on the subject, but that's a good primer |
| 03:57.55 | starseeker | dli: I have a few links to papers I can dig up tomorrow |
| 03:57.57 | brlcad | code-wise, src/other/openNURBS is a good starting point along with where we hook openNURBS into our code for ray-tracing at src/librt/primitives/brep |
| 03:58.24 | dli | starseeker, thanks |
| 03:58.54 | brlcad | you're basically writing a function that takes two ON_Brep objects and returns an ON_Curve |
| 03:59.11 | brlcad | or an ON_Surface or similar "intersection result" |
| 03:59.19 | starseeker | dli: ah, wait - found it :-) http://www.cs.berkeley.edu/~hling/research/paper/intersection.htm |
| 03:59.47 | dli | brlcad, nice, quite specific at this stage |
| 04:00.13 | brlcad | dli: you can start with src/proc-db/brep_simple.cpp |
| 04:00.29 | brlcad | that shows how one manually creates a b-rep box using openNURBS |
| 04:01.04 | brlcad | you could easily extend that example to just create two surfaces, then evaluate their intersection |
| 04:02.03 | brlcad | a summer student attempt this about a year and a half ago, their effort is in src/proc-db/surfaceintersect.cpp |
| 04:02.20 | CIA-53 | BRL-CAD: 03starseeker * r43151 10/geomcore/trunk/src/other/subversion/CMake/ThirdParty.cmake: |
| 04:02.20 | CIA-53 | BRL-CAD: Chop third party macro stuff down to just autoconf - need to sync with the newer |
| 04:02.20 | CIA-53 | BRL-CAD: one in BRL-CAD, but this has specific improvements to the autoconf routines that |
| 04:02.20 | CIA-53 | BRL-CAD: will need to be merged back into the main version (BRL-CAD trunk no longer does |
| 04:02.20 | CIA-53 | BRL-CAD: third party builds with autoconf, but apr and friends look to be very difficult |
| 04:02.21 | CIA-53 | BRL-CAD: conversion prospects for CMake.) |
| 04:03.09 | dli | brlcad, good enough :) so, I will read the brep_simple.cpp, and figure out the data structures, then, write a function to to find intersection of two ON_Brep objects |
| 04:03.30 | starseeker | brlcad: we may have to settle for building apr using their Visual Studio files on Windows as a precursor to building our subversion stuff - I don't know that I've found any successful examples of external projects in Visual Studio, although I can't yet say that for certain |
| 04:08.55 | brlcad | more info at http://mae.ucdavis.edu/~farouki/foils.pdf or with more rigor ftp://ftp.cs.unc.edu/pub/users/manocha/PAPERS/INTERSECT/IJCGA.pdf (he's published an update in 1997, but don't have a link for it) |
| 04:09.53 | brlcad | starseeker: not worried about external deps for GS until it's fully implemented -- dev rule can simply be "install it first" in the meantime |
| 04:10.06 | dli | brlcad, got them. some reading time now |
| 04:10.26 | brlcad | run cmake test(s), if not found -- print a message saying they need to install it |
| 04:11.30 | brlcad | build system integration isn't an issue until it's time for public deployment (which isn't on the table this year) |
| 04:11.38 | brlcad | dli: great |
| 04:17.37 | brlcad | dli, if you start making progress on code, let me know and we can get you set up with commit access so your efforts can be incrementally visible to others, traceable, and easier to understand the end-result |
| 04:18.31 | dli | brlcad, sure, we will see :) |
| 04:25.55 | *** join/#brlcad jmoore (~jmoore@cpe-184-57-8-75.columbus.res.rr.com) |
| 04:25.55 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) |
| 04:25.55 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) |
| 04:25.55 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) |
| 04:25.55 | *** join/#brlcad poolio (~poolio@BZ.BZFLAG.BZ) |
| 04:25.55 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
| 04:25.55 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) |
| 04:25.55 | *** join/#brlcad cosurgi (~cosurgi@atak.bl.pg.gda.pl) |
| 04:25.55 | *** join/#brlcad piksi (piksi@pi-xi.net) |
| 04:30.27 | *** join/#brlcad IriX64 (~IriX64@70.52.228.89) |
| 04:32.38 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) |
| 05:26.40 | CIA-53 | BRL-CAD: 03brlcad * r43152 10/brlcad/trunk/NEWS: include write-up highlights for 7.18.2 emphasizing the v4 compatibility work along with the platform integration efforts from new contributor jordi sayol. |
| 05:28.08 | CIA-53 | BRL-CAD: 03brlcad * r43153 10/brlcad/trunk/NEWS: jordi also improved platform support on Fedora, so call it out. leave openSUSE for the next release since it's not as well-tested. |
| 05:31.51 | CIA-53 | BRL-CAD: 03brlcad * r43154 10/brlcad/trunk/include/conf/PATCH: bump patch to .2 for release 7.18.2, final stages |
| 05:32.23 | CIA-53 | BRL-CAD: 03brlcad * r43155 10/brlcad/trunk/ChangeLog: update ChangeLog for release 7.18.2 |
| 05:42.04 | CIA-53 | BRL-CAD: 03Sean 07http://brlcad.org * r2463 10/wiki/Community_Publication_Portal: initial notes for 7.18.2 |
| 05:44.38 | CIA-53 | BRL-CAD: 03Sean 07http://brlcad.org * r2464 10/wiki/Community_Publication_Portal: not a pre section |
| 06:09.59 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) |
| 06:15.41 | CIA-53 | BRL-CAD: 03Sean 07http://brlcad.org * r2465 10/wiki/Community_Publication_Portal: /* Sean Morrison: Release 7.18.2 */ expand, reorganize, and reword accordingly |
| 06:15.58 | brlcad | gah, svn: Revision 43155 doesn't match existing revision 43150 in 'src/other/togl' |
| 06:17.28 | brlcad | that's why it's bad to delete and readd directories, even when updating revisions -- they have to be merged |
| 06:20.06 | CIA-53 | BRL-CAD: 03Sean 07http://brlcad.org * r2466 10/wiki/Community_Publication_Portal: /* Sean Morrison: Release 7.18.2 */ |
| 06:27.01 | CIA-53 | BRL-CAD: 03Sean 07http://brlcad.org * r2467 10/wiki/Community_Publication_Portal: final draft, ready for posting as soon as merge completes |
| 06:37.07 | brlcad | apparently a problem that was fixed in a later 1.4 version of subversion |
| 06:40.09 | *** join/#brlcad jmoore (~jmoore@cpe-184-57-8-75.columbus.res.rr.com) |
| 11:47.51 | dloman | Merning all! |
| 11:57.01 | dloman | *readreadread* |
| 12:10.52 | dloman | starseeker / ``Erik either of you good with threading? I just remembered that GS's JobManagement system is backed by QThread objects |
| 12:37.48 | CIA-53 | BRL-CAD: 03davidloman * r43156 10/jbrlcad/trunk/libs/ (. jscience-4.3.1.jar junit-4.1.jar): Added a libs dir with the two required .jars for compilation. jScience 4.3.1 is antiquated and no longer available to the general public but we still want the average jBRLCAD to be able to jump in, compile and help out. |
| 12:38.53 | CIA-53 | BRL-CAD: 03davidloman * r43157 10/jbrlcad/trunk/src/test/java/org/brlcad/ShootTest.java: Add in missing package statement. |
| 12:40.33 | CIA-53 | BRL-CAD: 03davidloman * r43158 10/jbrlcad/trunk/src/test/java/org/brlcad/geometry/HitTest.java: Import cleanup. |
| 12:54.23 | starseeker | dloman: probably want to look at pthread-win32 + system pthreads on other platforms |
| 12:54.38 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) |
| 13:10.42 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) |
| 13:37.19 | dloman | Yeah, but isn't that swapping the dep on QT for a dep on something else? |
| 13:38.35 | dloman | hangs a Chicken Bone Necklace on his monitor. |
| 13:38.40 | dloman | go go slow network! |
| 13:41.31 | dloman | finishes 1.5 hours of timesheets and other red tape :/ |
| 14:02.42 | brlcad | finishes resolving his first tree conflict |
| 14:04.11 | brlcad | at least one of the new svn 1.6 variety |
| 14:05.17 | starseeker | dloman: pthread-win32 is much smaller than Qt |
| 14:07.15 | brlcad | dloman: you know that jbrlcad doesn't have support for all object / primitive types? |
| 14:07.24 | brlcad | it has support for just four of them |
| 14:07.29 | dloman | yuppers :) |
| 14:07.50 | brlcad | k |
| 14:08.07 | dloman | the OCD in me couldn't stand the fact that jbrlcad is linked against libraries that are only stored in 'their' private repositories |
| 14:08.46 | dloman | so i pulled the antiquated version of jScience (4.3.1) and checked it into the jBRLCAD module. |
| 14:09.02 | brlcad | saw that but was more referring to a commit I saw yesterday |
| 14:09.08 | dloman | this way, 'anyone' can compile jbrlcad properly. |
| 14:09.10 | dloman | which one? |
| 14:09.15 | brlcad | looked like you're using jbrlcad in the java bridge to GS? |
| 14:09.36 | dloman | ...not to my knowledge. That's not my intent. Likely bad wordage on my part then. |
| 14:09.46 | dloman | Im not very good at engrish |
| 14:10.29 | brlcad | r43125 |
| 14:10.38 | brlcad | "Keep it simple and, rather than copy classes that are under development, make jBRLCAD an dependency. Hopefully this will change in the near future." |
| 14:11.31 | dloman | was talking about the interface that Ron created in jbrlcad/src/geometryservice |
| 14:11.47 | dloman | thats the 'interface' we are both coding to. |
| 14:12.10 | dloman | since its likely going to change, i figured copy/paste from jbrlcad into rt3 was a maintenance issue. |
| 14:12.30 | dloman | I need to work with Ron on getting all the java source into one place. |
| 14:13.03 | brlcad | where the java code lives isn't really a major concern |
| 14:13.34 | dloman | true, but if its living in two places, that's annoying and makes life harder. But that's my problem =D |
| 14:13.36 | brlcad | it's the reliance on there basically needing to be a librt written in java (which is basically what jbrlcad is) |
| 14:14.37 | dloman | ... that's 'their' issue... right? |
| 14:15.55 | brlcad | well, yes and no -- more than likely a misuse of the geometry service since it's supposed to avoid managing geometry on their end |
| 14:16.05 | brlcad | geomcore/trunk/src/interfaces/java |
| 14:16.12 | brlcad | is that what ron is working on? |
| 14:16.24 | brlcad | or is that the bridge you're working on? |
| 14:21.38 | dloman | sorry, got attacked by red tape again |
| 14:21.52 | dloman | geomcore/trunk/src/interfaces/java is what I/we are working on |
| 14:22.16 | dloman | Ron checked his 'bridge definition' into jbrlcad |
| 14:22.31 | brlcad | so r43125 applied to that path and is where you have the comment about it using jbrlcad |
| 14:23.05 | dloman | correct. in jbrlcad/src/main/org/brlcad/geometryservice |
| 14:23.27 | dloman | there is a java Interface (aka pure virtual class) called GeometryService.java |
| 14:23.31 | brlcad | if it's using jbrlcad, then it sounds like there's a problem -- what's it using? |
| 14:24.20 | dloman | rather than copying that file over to geomcore/src/interfaces/java, i chose to simply make jbrlcad an ext dep untill we can get all the java code into one place. |
| 14:24.22 | brlcad | the issue is the dev path forward -- if it's using it for geometry management, while only supporting 10% of geometry, then there's a future cost that will have to be realized before it's complete |
| 14:24.29 | dloman | its a temporary thing for now. |
| 14:24.46 | dloman | heh, you're way over thinking it :) |
| 14:24.52 | brlcad | probably |
| 14:25.13 | dloman | i just need that file and don't want to (possibly) dev against antiquated Interface |
| 14:25.29 | brlcad | just trying to understand what's going on, since this is potentially a low risk / high risk changer that I'd have to report on and/or address |
| 14:25.41 | dloman | its a non-factor |
| 14:25.48 | brlcad | so if it's just that one interface, why not move it? |
| 14:26.11 | dloman | cause 'they' need it to, and 'they' are developing in jbrlcad module |
| 14:26.19 | dloman | s/to/too/ |
| 14:29.02 | brlcad | sounds like something that will need to be discussed in more detail |
| 14:29.19 | brlcad | that's their perrogative, but implies the GS isn't doing something they need |
| 14:30.32 | brlcad | or that they're crossing over into geometry management land on the java side, which they're not supposed to be doing |
| 14:31.53 | brlcad | either way -- a "GeometryService" class makes no sense in jbrlcad other than as a commit location for all java code |
| 14:32.52 | brlcad | it'd imply either moving the java code you're working on over to the jbrlcad module or moving that class out of jbrlcad into where you're using it and providing it as an interface from there |
| 14:33.32 | brlcad | I suspect it was just added just as a dumping ground for all geometry-related java code, not because it made sense |
| 14:34.57 | dloman | naming-wise, I agree. GeometryService is a rather incorrect name for an Interface that will be sitting in their code base |
| 14:36.05 | dloman | GSAccessPoint perhaps |
| 14:36.45 | brlcad | even with that name, that doesn't really have anything to do with "jbrlcad" |
| 14:36.54 | dloman | true :) |
| 14:37.08 | brlcad | it's a GS thing so it should live with the GS code |
| 14:37.57 | dloman | i think i am going to 'out-dev' them rather rapidly, so I'll likely just take any/all GS related java code out of jBRLCAD module anyways. |
| 14:38.58 | brlcad | it's basic "separation of concerns" |
| 14:39.18 | brlcad | sounds like a communication needing to be had regardless |
| 14:39.42 | dloman | agreed. I'll zip an email up to Ron John (*snicker*) or walk up there later |
| 14:40.24 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) |
| 14:41.43 | CIA-53 | BRL-CAD: 03brlcad * r43159 10/brlcad/trunk/misc/debian/application-x-brlcad-extension.xml: set eol-style |
| 14:42.02 | brlcad | 15 minute commit ruined by a single line ending failure |
| 14:42.52 | dloman | http://assets.head-fi.org/f/fd/fd9be1b5_fuuuuuuuu.jpg =D |
| 14:43.50 | CIA-53 | BRL-CAD: 03davidloman * r43160 10/geomcore/trunk/src/interfaces/java/.settings/ (. org.eclipse.jdt.ui.prefs): Putting in Eclipse .settings directory. Contains project settings that are not machine specific, but allows for auto insertion of BRLCAD header. |
| 14:45.21 | dloman | FYI, Ed's in today. |
| 14:47.04 | CIA-53 | BRL-CAD: 03davidloman * r43161 10/geomcore/trunk/src/interfaces/java/auto-props.cfg: Update sample auto-props file with more mime-types. |
| 14:49.53 | CIA-53 | BRL-CAD: 03davidloman * r43162 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/ (9 files in 3 dirs): Clean up existing and add missing headers. |
| 14:59.35 | brlcad | dloman: heh, what's with the sample auto-props? |
| 15:00.47 | dloman | getting autoprops on winderz is a PITA, especially here at work. so i figgered i'd put in a file to help |
| 15:00.52 | brlcad | much more extensive "sample" on the website: http://brlcad.org/wiki/Mime-types |
| 15:01.55 | dloman | kk, i'll link that. danke. |
| 15:03.48 | brlcad | begins final release distcheck |
| 15:04.37 | dloman | the word 'distcheck' still makes me take look twice |
| 15:06.33 | brlcad | you have to look twice to find it? |
| 15:06.45 | brlcad | oh SNAP! no he didn't |
| 15:07.17 | dloman | ohnoe u dint! (repeat x4) |
| 15:09.23 | CIA-53 | BRL-CAD: 03brlcad * r43163 10/brlcad/branches/STABLE/ (4855 files in 354 dirs): merge trunk to STABLE from r41558 to HEAD r43158 |
| 15:18.04 | starseeker | brlcad: heh - ruined commits due to prop issues suck - I still wish svn let us check that before we go through the network process... |
| 15:18.18 | starseeker | especially fun when upgrading tcl/tk |
| 15:21.55 | ``Erik | *readreadread* np my ass |
| 15:23.39 | dloman | eh? |
| 15:25.03 | ``Erik | dlo: I think, uh, we'll move GS to bu, then fix win32 bu threading |
| 15:25.20 | dloman | okie. |
| 15:25.33 | dloman | I was just thinking about all the areas that QT is in |
| 15:25.41 | dloman | and realized its in the threading also. |
| 15:25.51 | ``Erik | jbrlcad is, uh, ... probably not very relevant |
| 15:28.42 | ``Erik | aight, all caught up |
| 15:29.10 | ``Erik | yeh, I'm de-qt'ing it pretty heavily, it winds all up and down, but we'll get there :) 'sall good |
| 15:30.22 | ``Erik | (the np comment was about tesselation, I'm fairly certain it's not np, I'm thinking more in the n^2 or nlgn if done right... we have a feeble implementation) |
| 15:38.58 | CIA-53 | BRL-CAD: 03starseeker * r43164 10/geomcore/trunk/src/other/sqlite/ (CMake/ CMake/ResolveCompilerPaths.cmake CMakeLists.txt): Try looking for dl for sqlite |
| 15:41.26 | starseeker | dloman: does that help? |
| 15:41.33 | dloman | one sec |
| 15:42.43 | dloman | Sure does! *thumbs up* |
| 15:47.52 | CIA-53 | BRL-CAD: 03starseeker * r43165 10/geomcore/trunk/cmake/FindTCL.cmake: |
| 15:47.52 | CIA-53 | BRL-CAD: Ironically, our new FindTCL isn't suitable for finding BRL-CAD's tcl/tk, since |
| 15:47.52 | CIA-53 | BRL-CAD: it requires the .sh config files from Tcl and the new CMake build isn't |
| 15:47.52 | CIA-53 | BRL-CAD: generating or installing them (did our autotools build, for that matter?). Need |
| 15:47.52 | CIA-53 | BRL-CAD: to have the CMake build for tcl/tk generate those .sh files |
| 15:55.38 | ``Erik | heh |
| 16:08.03 | CIA-53 | BRL-CAD: 03Dloman 07http://brlcad.org * r2468 10/wiki/NetMsgTypes: Update MsgType chart with accurate info. |
| 16:09.12 | CIA-53 | BRL-CAD: 03erikgreenwald * r43166 10/geomcore/trunk/ (89 files in 9 dirs): removal of some unnecessary QT-isms |
| 16:09.17 | CIA-53 | BRL-CAD: 03Dloman 07http://brlcad.org * r2469 10/wiki/NetMsgTypes: Changed verbage and added 8byte generic msgtype |
| 16:34.09 | CIA-53 | BRL-CAD: 03Dloman 07http://brlcad.org * r2470 10/wiki/NetMsgTypes: Typo fix |
| 16:39.52 | CIA-53 | BRL-CAD: 03davidloman * r43167 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/ (NetMsgFactory.java msg/NetMsgTypes.java): Sync msgTypes with GeomCore module. |
| 17:15.22 | *** join/#brlcad jay_ (~jay@212.96.10.253) |
| 17:18.00 | jay_ | hello |
| 17:19.35 | jay_ | you guys know of any linux architectural CAD app? |
| 17:55.36 | starseeker | jay_: depends on what you're after - commercially, there's this http://www.cycas.de/ |
| 17:56.24 | starseeker | maybe this is of interest? http://sourceforge.net/projects/sweethome3d/ |
| 17:59.16 | CIA-53 | BRL-CAD: 03erikgreenwald * r43168 10/geomcore/trunk/src/utility/DataStreamUtils.cxx: fix ambiguous overload error |
| 18:03.28 | brlcad | ``Erik: with floating point math, solving boolean evaluation for polygonal topology is not just n^2 even though the core algorithm is |
| 18:03.31 | starseeker | ``Erik: that's got it on the mac |
| 18:04.45 | brlcad | it becomes a search problem, you have to make blind guess decisions at which point there's no longer a single "final solution" .. there's a set of solutions and you're looking for a valid solution, which is not easy |
| 18:05.19 | starseeker | still one in Linux - GenericEightBytesMsg.c:31: prototype not matching |
| 18:05.45 | starseeker | error: prototype for 'GenericEightBytesMsg::GenericEightBytesMsg(uint32_t, quint64)' does not match any in class 'GenericEightBytesMsg' |
| 18:06.33 | starseeker | few others... |
| 18:07.55 | brlcad | consider the simple example of the subset sum problem, which is np-complete -- it states given a set of integers, do any non-empty subset of them add up to zero |
| 18:08.49 | brlcad | that same characterization can be made of vertices during evaluation, given a set of points, do any non-empty subset of them coincide (i.e., are the same point) |
| 18:09.55 | brlcad | that and other hard questions get repeatedly asked, a decision is made, and the underlying O(N^2) algorithm continues to the next edge/vertex/face/shell/object |
| 18:12.58 | CIA-53 | BRL-CAD: 03davidloman * r43169 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/RemoteNodeNameSetMsg.java: Implement RemoteNodeNameSetMsg in java. |
| 18:14.54 | jay_ | starseeker: thnx |
| 18:21.01 | dli | brlcad, do you mean any repeated point? |
| 18:21.22 | dli | brlcad, or give a list of subsets, any repeated? |
| 18:21.30 | CIA-53 | BRL-CAD: 03erikgreenwald * r43170 10/geomcore/trunk/src/libNet/PortalManager.cxx: add missing parameter |
| 18:25.05 | CIA-53 | BRL-CAD: 03erikgreenwald * r43171 10/geomcore/trunk/src/ (3 files in 2 dirs): snprintf type fixes |
| 18:32.49 | brlcad | dli: given a set of points, which are equal to other points within a given tolerance |
| 18:34.45 | brlcad | even with exact non-floating point computation, if you add a "within tolerance" qualifier, you suddenly have np-hard decision searching |
| 18:35.04 | brlcad | floating point just adds an implicit tolerance on top of a geometric tolerance |
| 18:36.03 | dli | brlcad, partition the coordinates according the tolerance, so, from real x -> integer i_x = [ x/dr +0.5], now, you only have to search within i_x plus/minus 1, j_y plus/minus 1, etc. O(N) |
| 18:40.16 | dli | brlcad, if we can waste on memory, partition points to a 3d array, search is still O(N) |
| 18:42.19 | CIA-53 | BRL-CAD: 03erikgreenwald * r43172 10/geomcore/trunk/ (40 files in 9 dirs): switch from QT typedefs to standard typedefs |
| 18:43.12 | dli | brlcad, suppose the wanted tolerance is tiny, partitioning to 1/dr is impractical, we can simply use an intermediate (dr0), now, only have to search within neighbours of (dr0), divide and conquer |
| 18:57.11 | CIA-53 | BRL-CAD: 03starseeker * r43173 10/geomcore/trunk/cmake/ (10 files): Clean out some of the unneeded .cmake files - may be more scrubbing to do here. |
| 18:57.28 | brlcad | dli: the tolerance is generally very very tiny in relation to the value |
| 18:57.53 | brlcad | moreover, depending on how you group points will affect the resulting decision |
| 18:57.58 | dli | brlcad, then, use a reasonable intermediate dr0 |
| 18:58.29 | brlcad | there is no definition of reasonable that applies to arbitrary geometry |
| 18:58.36 | dli | brlcad, only search within neighborhood of dr0 |
| 18:58.46 | CIA-53 | BRL-CAD: 03starseeker * r43174 10/geomcore/trunk/ (12 files in 9 dirs): Start working on getting the tests running again - leave them off for now, as there's a fair bit of work to do. |
| 18:58.47 | brlcad | define neighborhood |
| 18:58.55 | dli | brlcad, no, but as far as it's fast for most cases |
| 18:59.13 | brlcad | so you get a wrong answer fast .. that's not very useful :) |
| 18:59.31 | dli | brlcad, no, this algorithm doesn't get any wrong answer |
| 18:59.41 | brlcad | this is a problem best explained with a white board |
| 18:59.50 | dli | brlcad, anything outside of dr0 wont be within dr |
| 19:00.17 | brlcad | if you have a proof, then you'd have a ground-breaking research paper -- the geometry is nowhere near as rigorous or clean as it sounds like you're presuming |
| 19:00.46 | brlcad | the tolerance has to be big enough so points will merge together, this is a good thing |
| 19:01.01 | brlcad | but too big, and it'll join topology that should not be joined |
| 19:01.34 | brlcad | in practice that is a weighted local tolerance that might take curvature, topology, and other factors into account |
| 19:01.48 | brlcad | just assuming a hard 0.000# tolerance just doesn't work |
| 19:01.56 | brlcad | no matter how small you make it |
| 19:03.07 | brlcad | and it STILL doesn't address the impact of deciding a coinciding point that are within tolerance |
| 19:03.22 | brlcad | consider three points: A, B, C |
| 19:03.24 | dli | brlcad, http://num-meth.srcc.msu.ru/english/zhurnal/tom_2010/v11r135.html |
| 19:03.42 | brlcad | A is within tolernace of B, B is within tolerance of C, but A is not within tolerance of C |
| 19:04.37 | brlcad | how you join those will result in different topology, and there is no knowledge about which choice is right other than the final geometry being considered "valid" or not |
| 19:04.49 | dli | brlcad, I'm still not clear whether voronoi cell is relevant here, voronoi is n log(n), more robust than neighbor searching algorithms |
| 19:06.37 | brlcad | dli: not sure what you're trying to show with that paper, but at a glance it looks like a simple spatial partitioning of your comparisons -- that's merely optimization (and not particularly relevant since you're generally not comparing that many neighboring points) |
| 19:07.17 | dli | brlcad, neighbor searching is not robust, I know that, but voronoi is robust |
| 19:07.19 | brlcad | it's the same problem even if you try to carve up voronoi neighborhoods |
| 19:07.47 | brlcad | you have to decide where to split and there is no definition of how/where to split |
| 19:07.58 | brlcad | take that three-point example -- that's about as basic as it gets |
| 19:08.34 | dli | brlcad, original voronoi problem doesn't require definition of neighbors, http://en.wikipedia.org/wiki/Voronoi_diagram |
| 19:09.14 | brlcad | how is that helping? |
| 19:09.24 | dli | brlcad, it will generate voronoi diagram on any 3 points on plane, I'm not clear how the algorithm with behavior with repeated points |
| 19:09.42 | brlcad | how is that helping? |
| 19:09.59 | dli | brlcad, let's suppose no repeated points, all points a different by tiny distance |
| 19:10.24 | brlcad | sure |
| 19:10.31 | dli | brlcad, then, generate voronoi cells, find the small cells, test the points with its neighbors (as defined by voronoi) |
| 19:11.02 | brlcad | test them for what? |
| 19:11.31 | brlcad | take the simple ABC case, what's being tested? |
| 19:11.32 | dli | brlcad, for each point, get the distance to its voronoi neighbors |
| 19:11.46 | brlcad | okay, that's distance AB, BC, and AC |
| 19:11.54 | brlcad | now what? |
| 19:12.10 | dli | brlcad, now, decide whether within tolerance |
| 19:12.26 | brlcad | okay, AB are within tol, BC are within tol, AC are not |
| 19:12.26 | dli | brlcad, the good thing is that, after voronoi, it's O(N) |
| 19:12.28 | brlcad | now what? |
| 19:12.54 | dli | brlcad, oh, that's another question :( |
| 19:13.12 | brlcad | follow this through, you're still not getting the problem -- I know what voronoi are and do, but finding neighbors isn't the problem |
| 19:13.44 | dli | brlcad, I thought the problem is finding neighbor, now, it's the definition of neighbor |
| 19:13.52 | brlcad | bingo |
| 19:15.28 | brlcad | topologically with A, B, and C, you might want to join A+B and keep C separate .. or join B+C and leave A separate .. or loosen the tolerance and join A+B+C |
| 19:15.34 | dli | so, what about just give it tighter tolerance? then, just randomly combine points, until no overlap exists |
| 19:16.07 | brlcad | tighten the tolerance, and you avoid joining A B and C altogether, and your topology is broken/invalid |
| 19:16.52 | brlcad | in practice, you'll want either [A+B, C] or [A, B+C] .. but you just don't know which one is right (or if either of them is right) |
| 19:17.13 | brlcad | generally one of them is right, the other is not but it becomes a decision tree |
| 19:17.20 | dli | brlcad, no, I don't understand this. tighter tolerance shouldn't break anything |
| 19:17.56 | brlcad | understandable, hard to see with just three points |
| 19:18.17 | brlcad | topologically, you're stitching together geometry -- polygon faces or spline surfaces |
| 19:18.37 | brlcad | you're trying to decide whether polygon 1 attaches to polygon 2 |
| 19:18.53 | brlcad | so you might compare the vertices of 1 with the vertices of 2 |
| 19:19.35 | brlcad | for solid geometry, all meshes must enclose space |
| 19:19.44 | brlcad | otherwise they are just infinitely thin dangling faces |
| 19:20.37 | dli | brlcad, yes, I see the rough picture now |
| 19:20.41 | brlcad | if you tightened your tolerance to .. 0 .. then only vertices that are exact-exact matches join (which isn't practical with floating point), so it basically won't think those two faces are topologically connected when they should be |
| 19:21.18 | brlcad | loosen the tolerance too much and you end up joining faces that are "close" but shouldn't be joined _toplogically_ |
| 19:21.52 | brlcad | it really is a pretty fucking hard problem (pardon my language) to make robust |
| 19:22.29 | dli | brlcad, I suppose to write a function to generate intersection, so, I have to handle this problem |
| 19:22.47 | brlcad | in an ideal world, you'd keep track of your decision tree as you progress through the evaluations, use a floating/variable tolerance that adjusts to topology, and have a means to unroll back through decisions when you end up with invalid results |
| 19:23.22 | brlcad | strictly speaking yes you will, but it's not nearly as bad for surface surface evaluations |
| 19:23.53 | brlcad | it's a problem for the code that will USE your surface-surface function :) |
| 19:24.30 | dli | brlcad, let try and see how it works out |
| 19:24.35 | CIA-53 | BRL-CAD: 03starseeker * r43175 10/geomcore/trunk/tests/GS/GeometryServiceTest.cxx: Make a stab at GeometryServiceTest |
| 19:25.48 | brlcad | dli: mind you, in practice, you can generally find a "sweet spot" tolerance or set of tolerances that will make it all work and evaluate correctly for a given input -- my ranting is merely addressing the np-hardness of the underlying decision problem |
| 19:26.06 | brlcad | you can make AB/BC/AC decisions for 99% of geometry just fine |
| 19:26.48 | brlcad | the issue is usually error accumulation, that's where NMG (our polygon library) has problems |
| 19:27.10 | dli | brlcad, if so, can we use integer instead? |
| 19:27.14 | brlcad | like I said earlier with the [A+B, C] or [A, B+C] decision case, you'll probably pick one of those two results |
| 19:27.32 | brlcad | but whether you join A+B or B+C .. what value do you actually use? |
| 19:27.48 | dli | brlcad, 64bit integer would be good enough |
| 19:27.52 | brlcad | A+B -> A's value? B's value? the midpoint of A+B? |
| 19:28.09 | brlcad | all three options results in point drift |
| 19:28.54 | dli | brlcad, still error accumulating |
| 19:31.52 | CIA-53 | BRL-CAD: 03erikgreenwald * r43176 10/geomcore/trunk/tests/ (libEvent/BasicEventTest.cxx utility/configTest.cxx): de-QT some more |
| 19:34.05 | brlcad | dli: yep, the all _potentially_ accumulate error |
| 19:34.55 | brlcad | if "A" is right, then C won't be merged ... if you pick B's value or midpoint of A+B, then you might actually even now be within tolerance of C .. which effectively collapses to A+B+C |
| 19:36.13 | brlcad | whether you use floating point or integer comparisons won't really make much of a difference is my gut feeling. it might give you locally stable behavior but not algorithmic stability |
| 19:36.56 | brlcad | the best results I've seen use interval arithmetic, which can be done with floating just fine |
| 19:37.12 | brlcad | it's basically a way to track the error |
| 19:38.30 | brlcad | you can get the same result by recording a ULP and the local per-vertex error |
| 19:44.17 | dli | brlcad, instead of seeing error accumulating, I feel it can be self-healing, to adjust points according to the direction/side of solid |
| 19:45.03 | dli | brlcad, whatever the adjustment, it never gives broken topology |
| 19:46.30 | CIA-53 | BRL-CAD: 03erikgreenwald * r43177 10/geomcore/trunk/tests/utility/CMakeLists.txt: copy test config file to bin dir |
| 19:51.01 | CIA-53 | BRL-CAD: 03starseeker * r43178 10/geomcore/trunk/ (6 files in 4 dirs): Gets the tests almost building, although not sure how correct the changes are. |
| 19:51.19 | brlcad | dli: that's not a bad idea, and probably possible, but definitely not easy |
| 19:51.41 | brlcad | our NMG library does something like that now, trying to make sure it's never broken as evaluation progresses |
| 19:52.34 | dli | brlcad, nice, good enough for me to try |
| 19:52.40 | brlcad | the problem is that it's still a decision tree and there are invalid decision nodes that might lead to valid (desireable) final states, or numerous competing valid states ( like [A+B, C] or [A, B+C] ) |
| 19:53.55 | CIA-53 | BRL-CAD: 03starseeker * r43179 10/geomcore/trunk/tests/libEvent/BasicEventTest.cxx: There we go - get BasicEventTest compiling too. |
| 19:56.49 | CIA-53 | BRL-CAD: 03davidloman * r43180 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/ (AbstractNetMsg.java RemoteNodeNameSetMsg.java): Updated AbstractNetMsg's deserial cstr to take the msg type. Type will be deserialized in order to determine how to construct an AbstractNetMsg object anyways, so it needs to be set by a subclass. |
| 19:59.43 | CIA-53 | BRL-CAD: 03brlcad * r43181 10/brlcad/trunk/src/libfb/if_ogl.c: linux is using __USE_BSD and __USE_XOPEN_EXTENDED in order to get to the getpagesize() declaration. |
| 20:00.35 | CIA-53 | BRL-CAD: 03davidloman * r43182 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/GSStatics.java: Add a static for libpkg's header size. |
| 20:00.55 | starseeker | GenericEightBytesMsg.cxx:44: error: no match for 'operator>>' in '* ds >> ((GenericEightBytesMsg*)this)->GenericEightBytesMsg::data' |
| 20:01.55 | CIA-53 | BRL-CAD: 03brlcad * r43183 10/brlcad/branches/STABLE/src/libfb/if_ogl.c: merge r43181 from trunk |
| 20:02.26 | CIA-53 | BRL-CAD: 03erikgreenwald * r43184 10/geomcore/trunk/src/utility/Config.cxx: simplify and correct line parsing logic |
| 20:03.26 | brlcad | bah |
| 20:20.56 | CIA-53 | BRL-CAD: 03brlcad * r43185 10/brlcad/trunk/src/libfb/if_ogl.c: it actually needs __USE_XOPEN and __USE_BSD to get to the decl, so add them both with ifndef protection. this suckage belongs in libbu. |
| 20:21.54 | CIA-53 | BRL-CAD: 03brlcad * r43186 10/brlcad/branches/STABLE/src/libfb/if_ogl.c: merge r43183 from trunk for the getpagesize() fix when compiling with ogl enabled on linux |
| 20:22.23 | epileg | I want to improve the brlcad mime type on Linux. It appears that all geometry db files begin with "76 01 00 00 00 00 01 35 76". Is this correct? |
| 20:24.02 | CIA-53 | BRL-CAD: 03davidloman * r43187 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/NewSessionReqMsg.java: Implement NewSessionReqMsg in java. |
| 20:26.29 | ``Erik | not necessarily... 0x76 is the magic for our version 5 db, but the second byte is flag information |
| 20:26.38 | ``Erik | um, include/db5.h shows the on disk header |
| 20:26.56 | brlcad | the first 8 bytes should be right |
| 20:27.22 | CIA-53 | BRL-CAD: 03davidloman * r43188 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/SessionInfoMsg.java: Implement SessionInfoMsg in java. |
| 20:27.28 | brlcad | but yeah, that only applies v5 too -- v4 looks rather different |
| 20:28.43 | epileg | but the db version is so variant? |
| 20:29.28 | epileg | and what's the header bytes on v4? |
| 20:30.00 | brlcad | don't worry about v4, they're older files |
| 20:30.58 | epileg | just for people who has some db v4 files |
| 20:32.45 | brlcad | if you really want to be flexible, you can only count on the first byte being 76 and the eigth byte being 35 for v5 |
| 20:35.12 | ``Erik | I don't think there is head magic for v4 |
| 20:35.31 | epileg | hmmmm, I'll try just for v5. |
| 20:37.46 | brlcad | v4 files start with an 'ident' record |
| 20:38.12 | brlcad | so it'll be something like 'I?v4' 49 01 76 34 |
| 20:38.44 | brlcad | version key again being 76 and 34 |
| 20:39.22 | ``Erik | should probably have a bit more magic for v6 O.o |
| 20:39.22 | epileg | aha |
| 20:40.35 | brlcad | yeah, [0]==76 [7]==36 :) |
| 20:41.02 | epileg | for v4? |
| 20:41.09 | brlcad | that'd be "v6" :) |
| 20:41.14 | brlcad | which doesn't exist yet |
| 20:41.33 | epileg | ops, ok |
| 20:43.52 | CIA-53 | BRL-CAD: 03davidloman * r43189 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/GSConnection.java: |
| 20:43.52 | CIA-53 | BRL-CAD: Implement first pass at a GSConnection object. GSConnection contains a static |
| 20:43.53 | CIA-53 | BRL-CAD: factory method that will create a GSConnection, handshake and authenticate with |
| 20:43.53 | CIA-53 | BRL-CAD: a GS Server. Socketing is blocking as the responsibility for polling/selecting |
| 20:43.53 | CIA-53 | BRL-CAD: is tossed to the user of this interface. |
| 20:47.16 | brlcad | initial release build seems to work |
| 20:47.57 | brlcad | funkyness in archer (rt crashes, display doesn't update on start) but rtwizard and mged seem to be doing alright |
| 20:57.08 | CIA-53 | BRL-CAD: 03starseeker * r43190 10/brlcad/branches/cmake/include/config_win_cmake.h: This should be coming from src/other now... |
| 21:37.19 | CIA-53 | BRL-CAD: 03brlcad * r43191 10/brlcad/tags/rel-7-18-2/: tagging release 7.18.2 |
| 21:53.26 | CIA-53 | BRL-CAD: 03brlcad * r43192 10/brlcad/trunk/include/conf/PATCH: release is tagged, bump to 7.18.3 |
| 21:53.57 | CIA-53 | BRL-CAD: 03brlcad * r43193 10/brlcad/trunk/ (NEWS README): prepare for next expected 7.18.4 release |
| 21:58.55 | brlcad | would someone else mind sanity testing the 7.18.2 tag? |
| 21:59.11 | brlcad | BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.2 is posted (20110209) |
| 22:06.56 | brlcad | have at it ``Erik |
| 22:07.09 | starseeker | brlcad: I'm compiling now |
| 22:09.43 | brlcad | thx |
| 22:15.38 | ``Erik | hm, solids.sh regress 3 off by many |
| 22:15.55 | ``Erik | on 32b fbsd, but not on 64b linux |
| 22:16.00 | ``Erik | interesting |
| 22:17.42 | brlcad | yeah, I've seen that one before too |
| 22:18.33 | brlcad | I put a note in the BUGS file for it, been failing with an (one) off-by-many error on an optimized mac build |
| 22:18.57 | brlcad | iirc it was grazing the edge of an arb8 |
| 22:22.18 | CIA-53 | BRL-CAD: 03starseeker * r43194 10/brlcad/branches/cmake/src/other/ (tcl/CMakeLists.txt tk/CMakeLists.txt): Looks like these flags may be causing trouble - comment out for now... |
| 22:27.38 | starseeker | urm. Getting Itcl_Init ERROR |
| 22:28.30 | starseeker | looks like libitcl3.4.la is there, but not the .so |
| 22:31.13 | starseeker | installed version does OK though |
| 22:31.17 | starseeker | just build dir |
| 22:31.43 | ``Erik | does a fresh checkout to see how bad he broke it |
| 22:32.13 | *** join/#brlcad CIA-62 (~CIA@208.69.182.149) |
| 22:43.19 | CIA-62 | BRL-CAD: 03starseeker * r43196 10/brlcad/branches/cmake/src/other/ (tcl/CMakeLists.txt tk/CMakeLists.txt): Let's try this again without nuking all the TK_FLAGS in the process... |
