| 00:13.58 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 00:43.31 | starseeker | brlcad: openvrml is LGPLv3 - would that pose a problem for us? (just checking to be sure) |
| 01:41.09 | *** join/#brlcad teepee (~teepee@gateway/tor-sasl/teepee) |
| 02:59.49 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) |
| 03:10.22 | Notify | 03BRL-CAD:brlcad * 62624 brlcad/trunk/doc/docbook/system/man1/en/CMakeLists.txt: cliff eliminated the orle tools post deprecation in r61124, so remove their manual pages as well |
| 03:16.43 | Notify | 03BRL-CAD:brlcad * 62625 (brlcad/trunk/src/conv/CMakeLists.txt brlcad/trunk/src/fb/CMakeLists.txt brlcad/trunk/src/util/CMakeLists.txt): ORLE is dead, but remnants remained. remove the unset orle include dir. |
| 03:20.25 | Notify | 03BRL-CAD:brlcad * 62626 brlcad/trunk/include/CMakeLists.txt: liborle is gone, orle.h is obsolete (deprecated 7.20) |
| 03:21.22 | Notify | 03BRL-CAD:brlcad * 62627 brlcad/trunk/CHANGES: note that the orle.h header was part of liborle |
| 03:21.50 | brlcad | starseeker: thinking about it from GCV perspective, plug-in style |
| 03:23.53 | brlcad | we could use but not derive from them and probably not appropriate or a good idea to have it in src/other, but something that could be leveraged when available |
| 03:25.14 | brlcad | if there's another lib, that would be awesome ... heck the fact that it's lgpl is a good motivation if someone wants to try and write one from scratch (ideally using a lemon(!) and mit-licensed) |
| 03:25.55 | brlcad | it's been a while since I last looked, but if you know of another lib with a better license, please do tell him ;) |
| 03:26.46 | brlcad | kanzure: implementing the intersections is actually one of the easier parts .. it's doing N surfaces against M surfaces and stitching it all together that's the really hard part :) |
| 03:28.19 | kanzure | ah. hm. |
| 03:31.02 | brlcad | you do need PP and PC and CC and PS and CS and SS intersections are reasonably reliable and work well so you can just focus on stitching |
| 03:31.22 | brlcad | so it'd be interesting to compare his routines against our implementations |
| 03:31.55 | kanzure | the one huge advantage of his source code is that it's all written by what seems to be a single person |
| 03:32.15 | brlcad | yeah, consistent and neat |
| 03:34.05 | brlcad | wish we had more emphasis and rigor on our public APIs, to keep things streamlined and not organically growing on individual whims .. but it's a hard balance with progress getting made too |
| 03:35.01 | kanzure | i get the feeling that opennurbs was a single person originally, but then later not so much :) |
| 03:35.10 | brlcad | I say that as I try to figure out where to add a new function myself encapsulating something I've been working on... |
| 03:35.44 | kanzure | yeah being clean about it has high costs |
| 03:35.51 | kanzure | moral anguish etc |
| 03:36.15 | brlcad | there are tools to help with this that I've pondered |
| 03:36.20 | brlcad | architecture management |
| 03:36.54 | kanzure | personally i still have trouble rejecting code contributions that are a little on the sloppy side, but otherwise functional and good |
| 03:37.00 | kanzure | i know i should... |
| 03:37.14 | brlcad | you end up defining what libraries should depend on what other libraries, for example, and they'll tell you the XXX places you have violations, so you can work to weed them out and fix them, refactor |
| 03:37.54 | brlcad | that's where I like to set the bar so far as we can automate it |
| 03:39.03 | kanzure | can't the army just clone you or something at this point |
| 03:39.07 | kanzure | is that option off the table? |
| 03:39.33 | Stragus | I'm sure they have, and the clones just aren't grown up yet :) |
| 03:40.30 | brlcad | I dunno, we'd be a team of refactoring monkeys |
| 03:40.43 | brlcad | probably end up flinging poo at each other |
| 03:40.53 | kanzure | hey whatever it takes to write good c |
| 03:40.59 | brlcad | hehe |
| 03:41.43 | kanzure | i'm not sure what i want to do about verbnurbs. i could either contribute, or port it to something else. |
| 03:41.52 | brlcad | you should see my refactoring to-do list ... tasks I try to work on in idle time to clean up the code |
| 03:42.14 | kanzure | i have written lots of javascript, so i'm certainly capable of contributing, but do i really want to be locked into node and the browser for cad stuff? |
| 03:42.48 | Stragus | Eh, all that talk of cleaning up code... and I had spent weeks recently applying serious anti-debugging techniques on some code, that was the ugliest mess I ever made. I accept weird jobs sometimes (that wasn't SURVICE stuff). |
| 03:43.04 | brlcad | categorized easy, medium, hard .. it's currently 93 items ... each requiring anywhere from a couple hours to a couple days effort |
| 03:43.13 | kanzure | browser has the benefit of being a widely distributed platform, and node isn't completely awful i suppose |
| 03:44.09 | brlcad | Stragus: "anti-debugging"? is that where you intentionally inject bugs for job security? |
| 03:44.37 | Stragus | Not quite, that's where you make it as difficult as possible for someone to run the code in a debugger and figure things out |
| 03:44.59 | brlcad | kanzure: most of the major CAD companies have web interfaces to their products (some like autodesk are exceptionally complex) |
| 03:45.13 | brlcad | varying degrees of success, but a lot of "meh" from the industry |
| 03:46.08 | brlcad | most real modeling tasks still require as fast as hardware with as much memory as is available, so while pretty, a web interface just tends to be overhead given a comparable client app |
| 03:46.10 | kanzure | you wouldn't sell a cad tool in a browser, it would be for other reasons |
| 03:46.49 | kanzure | i think it's cheaper to send nurbs over the wire than triangles for rendering |
| 03:49.42 | brlcad | certainly, it's generally an order of magnitude less data for "roughly comparable levels of detail" |
| 03:51.43 | kanzure | the one use case that i can see for cad in a browser is that sharing a modeling problem with a colleague is easier since they don't need the cad tool already installed locally yet |
| 03:51.48 | kanzure | but i admit this is a very niche case heh |
| 03:52.50 | kanzure | oh, and it may be useful for cad users in big companies that have super locked down computing environments, who are otherwise allowed to use the interwebs |
| 04:41.48 | mihaineacsu | kanzure: are there any plans for web projects build on node for brlcad? |
| 04:42.51 | kanzure | no node bindings |
| 04:43.05 | kanzure | there's a libffi node thing if you wanted to play around with that |
| 04:44.36 | mihaineacsu | I'd like to get involved in something that's javascript related as well. anybody can write javascript, but so few can write actual good javascript. |
| 04:45.04 | kanzure | did you look at verbnurbs? |
| 04:45.20 | mihaineacsu | sorry, I have to go print my thesis. I'll catch you later |
| 05:04.53 | *** join/#brlcad mihaineacsu (~mihaineac@109.166.134.18) |
| 05:06.19 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 06:04.32 | *** join/#brlcad ``Erik (~erik@pool-74-103-94-19.bltmmd.fios.verizon.net) |
| 06:19.04 | *** join/#brlcad mihaineacsu (~mihaineac@109.166.131.60) |
| 07:02.28 | *** join/#brlcad ``Erik (~erik@pool-74-103-94-19.bltmmd.fios.verizon.net) |
| 07:29.11 | Notify | 03BRL-CAD:brlcad * 62628 brlcad/trunk/src/librt/CMakeLists.txt: add an initial routine (not yet in use anywhere) that takes a given string with a boolean operation and returns the boolean operation in a canonical -+u char form. it converts various ascii/utf-8 alternatives as well as many utf-16 and various utf-24 symbols (e.g., encountered via copy-paste) including an exact match for the proper union/difference |
| 07:29.13 | Notify | symbols. |
| 07:34.34 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
| 07:47.06 | *** join/#brlcad konrado (~konro@41.205.22.54) |
| 07:48.09 | *** part/#brlcad konrado (~konro@41.205.22.54) |
| 07:48.23 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
| 08:07.31 | *** join/#brlcad ries (~ries@D979EA84.cm-3-2d.dynamic.ziggo.nl) |
| 09:06.18 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
| 09:26.25 | *** join/#brlcad luca79 (~luca@net-37-117-178-104.cust.vodafonedsl.it) |
| 09:37.42 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
| 09:42.13 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
| 09:56.12 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
| 10:19.34 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
| 10:57.03 | *** join/#brlcad gurwinder (75c76841@gateway/web/freenode/ip.117.199.104.65) |
| 11:01.55 | gurwinder | brlcad: Hello, I am trying to read .g file. One way is by using g2asc. It shows how the entities information is written. Is there another way to read .g file so as to understand how information is stored in it? |
| 11:40.41 | ``Erik | gurwinder: open it in mged and do 'tops' and 'ls' |
| 11:46.54 | starseeker | winces a little at the characterization of BRL-CAD devs as "refactoring monkeys", but can't really argue... |
| 11:48.35 | starseeker | ``Erik: did you get a chance to try the new git conversion process? |
| 11:56.21 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
| 11:57.17 | starseeker | brlcad: unfortunately, I don't know of a better lib myself - X3DToolKit is LGPLv2, but we'd need to get the Qt bits out of it and I don't actually know how close VRML really is to X3D: http://artis.imag.fr/Software/X3D/install_unix.html |
| 12:01.30 | starseeker | if I were starting it myself, I'd probably look at what the assimp guys did with their COLLADA importer and try to extract that, then customize it for VRML - IIRC, COLLADA is also XML based. |
| 12:03.43 | starseeker | actually, it might be a fun project to try and implement an "assimp-based" convertor that used them for any formats they support - most of them we don't really care about, but they do list Collada, Blender 3D, a couple 3ds max formats, Wavefront Obj, IFC/Step (??) etc... |
| 12:04.30 | ``Erik | starseeker: no, ya refactor monkey, I haven't... is there a url? I was running a 'git svn rebase' (previously triggered, now in cron), but the svn checksum mismatch issue has that wedged |
| 12:04.49 | starseeker | ``Erik: it's in misc/svn2git |
| 12:04.54 | starseeker | start with the README |
| 12:05.31 | starseeker | it's only good for mirroring - if you start actually working with the git repo and wanting to merge in changes from svn as you go you'll need your older process |
| 12:05.48 | starseeker | but it should get things set up and ready to roll quite quickly |
| 12:06.51 | starseeker | supposes you might be able to get away with the "mirror svn" git repo being its own thing, having your own clone where you do actual work, and do pulls from the mirror to get changes |
| 12:07.09 | starseeker | wouldn't let you push back to the svn repo through the git mirror though |
| 12:07.40 | ``Erik | I'll have to take a look when I get some time O.o :) |
| 12:13.33 | starseeker | yeah - assimp doesn't do threading without boost, but otherwise is buildable as a stand-alone. If nothing else, an importer that used their lib to load stuff into BRL-CAD would be useful as something to compare our own home-grown converters to, and a useful fallback if someone happens to care about a format we're never likely to support on our own (i.e. most game formats) |
| 12:14.23 | starseeker | doesn't help the VRML import problem though, except insofar as studying how they handle XML based formats like Collada |
| 13:13.08 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
| 13:27.21 | *** join/#brlcad luca79 (~luca@net-37-117-178-104.cust.vodafonedsl.it) |
| 13:29.48 | brlcad | starseeker: the comment was about cloning me several times .. we'd be a team of monkeys |
| 13:30.45 | Notify | 03BRL-CAD:starseeker * 62629 (brlcad/branches/dm-work/src/mged/chgview.c brlcad/branches/dm-work/src/mged/dodraw.c and 2 others): For the moment, do the same thing in MGED we did in libged to eliminate the solid list global. If this is still necessary for performance on today's hardware, need to hide it in gedp or somewhere similar so it's not a global and not exposed to the application except as some sort of |
| 13:30.47 | Notify | dl_free_mem function call. |
| 13:33.11 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 13:34.26 | brlcad | starseeker: and for the geometry conversion, vrml was intently the goal for a variety of reasons ... x3d is obviously related as the successor but it's not a superset or subset or anything where you could massage an xml parser to read the vrml - you need a vrml parser |
| 13:35.51 | brlcad | assimp would certainly be interesting for getting all those other formats, and had them in mind for GCV for some of the content/asset formats that are merely of periphery interest |
| 13:43.28 | Notify | 03BRL-CAD:starseeker * 62630 (brlcad/branches/dm-work/include/ged.h brlcad/branches/dm-work/src/libged/ged_private.h brlcad/branches/dm-work/src/mged/buttons.c): Start to use some of the dl functions from libged in mged. |
| 13:56.32 | Notify | 03BRL-CAD:starseeker * 62631 (brlcad/branches/dm-work/include/ged.h brlcad/branches/dm-work/src/libged/ged_private.h and 2 others): Clear a few FOR_ALL_SOLIDS uses, remove duplicate polybinout logic |
| 13:57.25 | starseeker | brlcad: ah :-) |
| 14:02.44 | starseeker | nods - my other bright idea for VRML then would be to look at Coin3D |
| 14:03.45 | starseeker | they're actually based directly on VRML, if I'm understanding their docs correctly - don't know how hard it would be to extract the I/O bits from all the other Coin3D stuff, but it might be a good place to start |
| 14:04.23 | starseeker | https://bitbucket.org/Coin3D/coin/src/90465eec46422931aff11ad6f5c8430c82298771/include/Inventor/VRMLnodes/?at=default |
| 14:07.23 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
| 14:15.41 | starseeker | there's http://ftp.vim.org/ibiblio/devel/lang/c++/QvLib-1.0.tar.gz which was in turn extracted from OpenInventor, but I'm not sure what to make of its license and it's VRML 1.0 only |
| 14:19.50 | starseeker | hmm. OpenVRML is 27 megs out of the box, and Coin3D is 40 megs |
| 14:20.07 | starseeker | takes a quick look at Coin3D to see if it can be quickly trimmed... |
| 14:21.56 | starseeker | ah - there's a vrml97 subdirectory in Coin3d/src |
| 14:22.07 | starseeker | that's probably the place to start |
| 14:22.55 | brlcad | coin3d would work, freewrl is another |
| 14:23.15 | starseeker | looks like there's a precident from the VTK world for using Coin: http://public.kitware.com/pipermail/vtkusers/2004-May/024206.html |
| 14:23.33 | brlcad | doesn't want to do konrado's project for him, he can figure it all out ;) |
| 14:23.41 | starseeker | heh |
| 14:24.43 | brlcad | as long as it's not a gpl code, I think we can make just about anything else that's available work if we have to |
| 14:25.00 | starseeker | nods |
| 14:25.07 | brlcad | the nuances of the various libs are quite muddy in terms of what might actually save substantial dev time |
| 14:25.45 | brlcad | and heck, if he really wanted to write a parser himself and he sticks with it, more power to him ... it is tractable, just not recommended |
| 14:26.04 | starseeker | nods |
| 14:26.38 | teepee- | shakes head |
| 14:26.40 | teepee- | ;) |
| 14:26.48 | starseeker | is seriously tempted to make a gconv tool using assimp, just for grins... |
| 14:27.45 | starseeker | would love to compare the results to our polygonal conversion toolset - might replace several of them in one swoop |
| 14:28.41 | brlcad | I'd probably give coin3d a try myself, it looks fairly contained and it's quite active |
| 14:28.58 | starseeker | if I'm not mistaken, it's used by the FreeCAD team |
| 14:28.58 | brlcad | that's the point of GCV, though, that we should be able to have N plugins using these different implementations, and we can compare them |
| 14:29.11 | brlcad | it is, so we'd share similar problems ;) |
| 14:30.06 | starseeker | nods - once the gcv API is stubbed in, we should be able to go to town |
| 14:31.59 | brlcad | teepee-: so you want to write a parser yourself you say? :) |
| 14:33.10 | starseeker | hehehe |
| 14:33.23 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
| 14:34.17 | teepee- | nope, I'd say writing parsers yourself is widely underestimated |
| 14:34.30 | teepee- | especially in case of XML based formats :) |
| 14:35.05 | Stragus | It's generally not too hard either, if you have done some and can reuse a bunch of code... |
| 14:35.30 | teepee- | it's not _hard_ but it's very hard to get it complete |
| 14:35.42 | starseeker | it's also a nightmare to debug |
| 14:36.06 | teepee- | like namespaces / xml-include and all the fancy stuff not everybody uses everyday in case of XML |
| 14:36.53 | Stragus | Ow. Yes right, I meant the basic syntax, never heard of XML namespaces or includes |
| 14:36.53 | teepee- | more examples... hand-made OpenSCAD script parser (very bad error handling, can't provide correct line numbers with includes) |
| 14:37.16 | teepee- | or the DXF parser which only supports part of the entities |
| 14:38.00 | teepee- | Stragus: that's exactly the point. the basic stuff is easy indeed. but someone might want to use the extended features... it's in the spec, so it's possible to use, right? |
| 14:38.22 | teepee- | for grins, just have a look at SVG files exported by Inkscape |
| 14:38.26 | Stragus | Right, I got your point now :) |
| 14:38.48 | Stragus | I wrote a XML parser and didn't implement anything beyond what I could see in the files I deal with |
| 14:38.53 | starseeker | still wants to look at https://bitbucket.org/Coin3D/dime to see what it can do with DXF... that would definitely be one to compare with assimp and our own DXF abilities. |
| 14:39.02 | Stragus | (and a JSON parser, and a parser for my own little programming language, etc.) |
| 14:39.30 | kintel | starseeker: FYI, I was on the Coin3D dev team |
| 14:39.49 | teepee- | fun example https://openclipart.org/people/liftarn/splat.svg |
| 14:39.54 | kintel | starseeker: ..but itâs not actively developed any longer, so it |
| 14:39.59 | kintel | âs a bit risky IMO |
| 14:40.05 | brlcad | good to know |
| 14:40.43 | kintel | But I know that a number of projects have used it for the VRML parser alone ;) |
| 14:40.46 | starseeker | kintel: in that situation my approach would be to try and isolate the I/O aspects that pertain to reading/writing VRML files, and make a new library based on those |
| 14:41.00 | starseeker | sort of "dime for VRML" |
| 14:41.46 | starseeker | kintel: how is the code, in that respect? Would that be a major effort? |
| 14:41.50 | kintel | starseeker: depends on which subset of VRML you want to support I guess, but the core geometry nodes should be easy |
| 14:42.21 | kintel | not sure how easy it would be to rip out the parser, as youâd need all the nodes |
| 14:42.32 | starseeker | what do the nodes depend on? |
| 14:42.51 | kintel | ..and the nodes depend on traversals, which again offer a bunch of virtual functions for GL rendering etc. |
| 14:42.57 | kintel | ..but you could probably stub away most of that |
| 14:43.31 | kintel | It was never designed to be separate. Itâs been half a decade since I looked at the code though : / |
| 14:44.18 | kintel | the far easiest would be to build and use the lib as is I think |
| 14:44.18 | starseeker | nods - the other approach in that situation is to just start ripping out anything that isn't necessary to the VRML I/O and boil it down, rather than trying to extract a subset |
| 14:44.53 | kintel | as long as FreeCAD is alive and using Coin, it should be relatively safe |
| 14:46.16 | kintel | but once starting on vrml, there is VRML1.0. VRML97, X3D etc. - didnât the X3D guys release some software for parsing them all - or at least converting VRML97 into the VRML-compatible subset of X3D ? |
| 14:46.30 | brlcad | openvrml does them all iirc |
| 14:47.30 | brlcad | think freewrl does too |
| 14:47.45 | brlcad | both seem pretty active and are listed on the x3d resources page |
| 14:51.25 | starseeker | libgcv should give us the opportunity to try out different libs (or, even better, have lots of student projects try out different libs ;-) and do an objective assessment of relative merits |
| 14:51.25 | brlcad | still, this is all over-eager problem solving of a new dev's coding problem ... |
| 14:51.31 | brlcad | he should be the one to figure out what will work and be interesting to him |
| 14:51.48 | brlcad | don't want to kill his motivation, which thinking through a lot of this for him easily could |
| 14:52.00 | starseeker | fair enough |
| 14:52.15 | brlcad | it's not a priority format to say the least, that's why it really doesn't matter in many ways |
| 14:52.27 | starseeker | braces his own motivation and heads back into MGED's drawing code... |
| 14:52.39 | brlcad | which by the way is looking awesome |
| 14:52.48 | brlcad | you're eliminating really old drawing code cruft... |
| 14:53.49 | starseeker | brlcad: thanks :-). I'm still leading up to the real challenge though - some parts of MGED's actual feature set are built around the "bu_list of solid objects", and reworking those is going to be more than just a refactor |
| 14:54.41 | starseeker | may end up just having to figure out what the feature actually *is* as step one... ugh |
| 15:08.50 | brlcad | is it possible to hold off changing something that fundamental until the branch is merged? |
| 15:09.23 | Notify | 03BRL-CAD:starseeker * 62632 (brlcad/branches/gct/doc/docbook/system/man1/en/gdiff2.xml brlcad/branches/gct/doc/docbook/system/man1/en/pixinterp2x.xml and 97 others): Sync with trunk up to r62573 |
| 15:09.51 | brlcad | the further down the rabbit hole you get, the messier the divergence |
| 15:10.56 | brlcad | much of what you're doing now could have been on trunk, for example, but it's intertwined with the dm work |
| 15:12.35 | starseeker | urm. the difficulty is I need to get this direct manipulation of individual solids out of all the apps |
| 15:13.08 | brlcad | sure |
| 15:13.11 | brlcad | I know that pain well actually |
| 15:13.18 | starseeker | brlcad: what about this? if we branch now for 7.26.0 and cherrypick the key updates between now and then, I could merge after that |
| 15:14.19 | starseeker | then we avoid the massive breakage of everything external for 7.26.0, which is the main reason I'm in the branch to begin with |
| 15:16.03 | starseeker | well, that and the fairly high risk of breaking a feature or hurting performance or something like that with such major changes... |
| 15:16.22 | starseeker | both of which argue for needing a 7.26.0 branch before I pile back into trunk |
| 15:16.36 | brlcad | it's not so much about merging the branch as it is having the branch changing N things at once instead of 1 thing |
| 15:16.44 | brlcad | plus, that'd really violates how a release branch is supposed to function |
| 15:16.53 | brlcad | and I think that's not helpful for a variety of reasons |
| 15:17.21 | brlcad | and there are other things playing into what makes 7.26 by the end-of-FY |
| 15:18.00 | Notify | 03BRL-CAD:carlmoore * 62633 brlcad/trunk/doc/docbook/system/man1/en/pixscale.xml: some of my 'routine' fixes, and also remove -h, which has already been removed for high-res in the program |
| 15:18.11 | brlcad | you're definitely right about affecting performance, though, so maybe it should just wait anyways |
| 15:18.29 | brlcad | at least I saw when you removed the vlist pooling... yikes :) |
| 15:18.32 | starseeker | brlcad: I guess I didn't really see my changes as hitting mulitple things - to me, it's all rolled up into the same task of making our code "scenegraph ready" |
| 15:18.37 | brlcad | that's one of the targets for my memory allocator |
| 15:19.01 | starseeker | I expect to add that back in, but I'll be doing it in a way that doesn't involve globals in libged |
| 15:20.28 | brlcad | making our code "scenegraph ready" is incredibly vague and open to debate and creep without really defining what that means, otherwise any you could just about justify any code change that interacts, no? :) |
| 15:21.21 | Stragus | That sounds like two words management would say :) |
| 15:21.22 | brlcad | I'm just looking at it from an architecture perspective, and there are now about a half-dozen signficant changes coming down the pipeline in that branch |
| 15:21.47 | starseeker | well, sort of - my specific interpretation was that libdm takes as inputs a set of db_full_paths and view_objects (vlists and text for the latter) and leaves the details to the backend |
| 15:22.04 | brlcad | they're all good, but it's a LOT of change and not strictly all "necessary", just good stuff that "should" get changed |
| 15:24.51 | starseeker | brlcad: so you'd prefer that I wait until I can merge back into trunk before diverging further? |
| 15:25.14 | starseeker | I could figure out how to put the vlist pooling back in in the meantime... |
| 15:27.28 | brlcad | I think the divergence pendulum has already swung pretty damn far (not saying that's a good thing or bad thing, but it's probably a great thing) ... I mean how many lines are you at now if you diff trunk ... you're probably pushing 50k lines |
| 15:28.38 | Notify | 03BRL-CAD:starseeker * 62634 (brlcad/branches/gct/CHANGES brlcad/branches/gct/doc/docbook/system/man1/en/CMakeLists.txt and 19 others): Sync with trunk up to r62631 |
| 15:29.03 | brlcad | that's invariably high risk and lots of issues (rule of bugs), so it's really just trying to keep diverging further "to as much a minimum as you can manage without halting your progress" |
| 15:29.41 | starseeker | yeah, it's probably a big diff |
| 15:29.54 | brlcad | if you HAVE to change something, you have to change it ... this is all the right direction to be going in regardless, it's just risky from a change management perspective to have such a huge branch go for this long without a mergeback |
| 15:30.17 | brlcad | is there anything you're working on that could be done on trunk and pulled to your branch? |
| 15:30.31 | starseeker | hmm |
| 15:30.33 | brlcad | one way to keep it to a minimum |
| 15:30.46 | brlcad | again, if you can't .. carry on and we'll deal |
| 15:32.03 | starseeker | yeah, I kinda shot myself in the foot in that respect by switching dm and fb to hidden structs with accessor functions up front |
| 15:32.12 | starseeker | oppsie |
| 15:32.14 | brlcad | but if you can ... I think it's worth it as the risk and impact does increase exponentially as time increases (invariably, you're already doing the best you can) |
| 15:33.09 | starseeker | I could try to introduce those changes (hide fb and dm) in trunk now - that would greatly reduce the divergence in lines of code |
| 15:33.27 | starseeker | unfortunately, that's also guaranteed to break external dm/fb users :-) |
| 15:33.51 | brlcad | hmmm |
| 15:34.02 | brlcad | what about all the display list changes from the past several days |
| 15:34.20 | brlcad | most of that was updating our tools to do things differently |
| 15:34.44 | starseeker | I could try - the key there is how much the code I moved around was accessing dm/fb |
| 15:34.55 | brlcad | nods |
| 15:35.10 | starseeker | if it wasn't (I'll have to check) then I might be able to do most of it ('cept for the vlist pooling stuff) |
| 15:35.46 | brlcad | the vlist pooling is another issue altogether, that might end up being a conflict if the branch lives too long |
| 15:36.37 | brlcad | like I said, that's a specific place I was looking at to put the new allocator to use, so I wouldn't worry about it either way |
| 15:37.06 | starseeker | the only real reason I ripped that out was to avoid the explicit solids list exposure - I can try being more careful and putting it in gedp as a void or something like that |
| 15:37.11 | brlcad | I didn't do it on trunk yet because of 7.26 |
| 15:38.40 | brlcad | nods, and really a lot of place that was used, they didn't actually need the vlist data .. they needed the paths |
| 15:39.29 | brlcad | maybe the best path to not waste time is just to check your diff and see what, if anything can be merged now, cherry picked or otherwise massaged to reduce the trunk diff |
| 15:40.05 | starseeker | I'll take a look |
| 15:40.25 | brlcad | if that list is zero, so be it, that'd due diligence |
| 15:40.32 | starseeker | brlcad: so I know better next time, what would have been the better way to approach something like this? |
| 15:40.35 | brlcad | s/due/be due/ |
| 15:43.42 | brlcad | probably just narrowing the scope of the branch ... which is hard here because there is so much research that was going on simultaneously |
| 15:43.51 | starseeker | hmm - I might be able to add in the bu_structparse changes without too much disruption. That amounts to adding a NULL to anything not using the new passthru, IIRC. |
| 15:44.11 | brlcad | it's a lot like the nmg branch in that respect, depth first instead of breadth first changes |
| 15:44.28 | brlcad | for example, all the dm API hiding / changing probably should have been last not first |
| 15:46.33 | starseeker | can see that... main idea there was to get all the X/ogl/whatever specific logic stuffed as far down as I could so I wouldn't have to introduce and then remove the equalivents for osg, but it did toss me off into the wilderness changeset wise |
| 15:48.55 | Notify | 03BRL-CAD:starseeker * 62635 (brlcad/branches/gecode/CHANGES brlcad/branches/gecode/doc/docbook/system/man1/en/CMakeLists.txt and 19 others): Sync with trunk up to r62631 |
| 15:50.23 | Notify | 03BRL-CAD:starseeker * 62636 (brlcad/branches/bullet/CHANGES brlcad/branches/bullet/doc/docbook/system/man1/en/CMakeLists.txt and 19 others): Sync with trunk up to r62631 |
| 15:50.40 | Notify | 03BRL-CAD:starseeker * 62637 (brlcad/branches/osg/CHANGES brlcad/branches/osg/doc/docbook/system/man1/en/CMakeLists.txt and 19 others): Sync with trunk up to r62631 |
| 15:51.01 | Notify | 03BRL-CAD:starseeker * 62638 (brlcad/branches/rel8/CHANGES brlcad/branches/rel8/doc/docbook/system/man1/en/CMakeLists.txt and 19 others): Sync with trunk up to r62631 |
| 15:51.25 | Notify | 03BRL-CAD:starseeker * 62639 (brlcad/branches/dm-work/CHANGES brlcad/branches/dm-work/doc/docbook/system/man1/en/CMakeLists.txt and 19 others): Sync with trunk up to r62631 |
| 15:53.08 | brlcad | yeah, architecture change-wise -- and mostly just thinking out loud -- there was the addition of a new dm, changed dm API / hidden structs, new dm API (better way of doing things), changed object display management, new display methods, updated tools to new display method, ... probably a few other things I'm missing |
| 15:54.50 | starseeker | come to think of it - in principle, ripping out dg.h and friends might be doable in trunk |
| 15:55.09 | brlcad | yeah, the elimination of the obj stuff .. that sh!t can go |
| 15:55.27 | starseeker | main ugly bit is needing to stuff wdb_obj.c in mged so it's Tcl commands still work - didn't have time to boil that down into a cleaner solution |
| 15:55.41 | brlcad | nods |
| 15:55.57 | starseeker | still, hard to claim it's more ugly than leaving all the rest of it there... |
| 15:56.11 | brlcad | anyways, not second-guessing your progress, like I said -- this is all great stuff I'm seeing |
| 15:56.40 | brlcad | I'm just shuddering at the branch on the whole from a risk management perspective, it's definitely in the "medium-high" category now :) |
| 15:57.11 | starseeker | heh - that doesn't even count the openscenegraph stuff in the other branches, if you really want nightmares :-P |
| 15:57.23 | starseeker | fortunately, most of that shouldn't have to merge at all |
| 15:57.43 | starseeker | it'll just guide the "real" implementation |
| 16:01.13 | starseeker | brlcad: actually, what I might be able to do is introduce the new dm (and maybe even fb) API functions and calls and such, but not hide the dm and fb structs themselves |
| 16:01.44 | starseeker | I'll have to look into that a bit, but what should really cause the breakage for external codes is not being able to access struct members directly |
| 16:02.10 | starseeker | adding new members is nothing new - Bob's done it several times - so if I do everything but the final "hide" it might still fly |
| 16:24.36 | brlcad | nods, sounds great |
| 16:32.57 | Stragus | I'm actually surprised you went the OpenSceneGraph route. I thought that was a bad decision when... another unnamed piece of software took that route. |
| 16:33.27 | Stragus | It's really just a big and very heavy wrapper around legacy OpenGL, with gaps and giant holes in terms of modern functionalities |
| 16:35.04 | Stragus | still can't believe that library needs 240000 active malloc() calls to render a cube |
| 16:42.37 | starseeker | Stragus: a lot of the work that is being done is to get our codebase ready to work with an external scenegraph - in that sense, it doesn't really matter what backend we're looking at |
| 16:43.31 | starseeker | OpenSceneGraph does at least hide the platform ugliness - as matters stand right now, we have one dm/fb implementation for glx, another for wgl, and we don't work at all on native Apple OpenGL |
| 16:44.48 | starseeker | it's also fairly easy to embed in BRL-CAD's build. |
| 16:45.20 | Stragus | Right, glfw is a great alternative to hide the platform ugliness |
| 16:45.40 | starseeker | my hope is that once this gigantic code scrubbing is done, it will be *much* easier for us to put <new shiny solution> under BRL-CAD, however that may change from year to year |
| 16:45.43 | Stragus | And it's a lot more flexible and complete to create contexts with modern functionalities |
| 16:46.38 | starseeker | nods - I'm familiar with glfw, and actually used it at one point. It doesn't provide a scenegraph, however |
| 16:47.57 | starseeker | we need to get our API to the point where applications aren't expected to micromanage their drawing the way MGED currently does. Even if all that just moves down to a library, it will allow for the future insertion of other drawing managers instead of completely locking us out of that space |
| 16:49.56 | Stragus | Indeed. Having your own drawing manager would seem appropriate to me (on top of glew/glfw3 to hide the ugly stuff) |
| 16:53.21 | Notify | 03BRL-CAD:starseeker * 62640 (brlcad/trunk/include/bu/magic.h brlcad/trunk/include/bu/parse.h and 60 others): Merge in all libbu changes and related tweaks from dm-work@r62639 to trunk, and make local alterations to trunk code to work with the libbu changes. The new magic numbers are harmless, as is the bu_struct_parse change if NULL is passed for the new parameter. Right now these updates aren't in use by any code |
| 16:53.23 | Notify | in trunk, but they help reduce the size of the diff between the branches. |
| 16:57.00 | starseeker | Stragus: practically speaking, BRL-CAD isn't in a position yet to take advantage of any of the "modern" stuff when it comes to OpenGL - we're still doing wireframes and, if you're lucky, shaded bots. Our NURBS shading is coming online, which is the game changer, but that's still being shaken out in testing at the moment. |
| 16:58.32 | starseeker | Stragus: you know quite a lot about this - do you have any familiarity with this work? http://www.cs.columbia.edu/~keenan/Projects/SpinTransformations/ |
| 17:00.09 | starseeker | once we can do shaded displays for everything, textures become more interesting... |
| 17:00.32 | Stragus | I'm not familiar with that paper at first glance, reading it may reveal common techniques |
| 17:00.39 | Stragus | Indeed |
| 17:01.11 | starseeker | if it's as cool as the figures suggest, the open source implementation makes it of real interest for quick testing... |
| 17:01.41 | Stragus | Also, eventually, one day, it could be nice to render CSG geometry directly by running the raytracer on CUDA/OpenCL |
| 17:03.56 | starseeker | that would be cool - I know brlcad and some students have looked into that a bit |
| 17:04.27 | starseeker | iirc, it pretty much involves doing on the raytracing side what I'm working on now on the graphics side (i.e., lots of changes to data flows) |
| 17:05.10 | Stragus | Regarding that URL: The screenshots make it a lot clearer and simpler than what the abstract and introduction suggest. I have implemented something similar once, although most probably not as fancy |
| 17:06.37 | Stragus | My technique was just stretching the texture to try to maintain a same "scale" everywhere, converging on some solution |
| 17:11.47 | starseeker | cool |
| 17:12.30 | starseeker | once we're through all this grunt work, I'm really hoping we'll be more easily able to play with that sort of cool, immediately user visible niftyness |
| 17:15.10 | starseeker | unfortunately, that point is probably after the Tk->Qt migration too (speaking of grunt work) |
| 17:21.31 | Notify | 03BRL-CAD:starseeker * 62641 (brlcad/trunk/include/CMakeLists.txt brlcad/trunk/include/ged.h and 46 others): Remove dg.h and friends, per dm-work branch commit 62532. Things to note - this removes the old gdiff tool - while the new one should functionally do what is needed, testing and user feedback are in order. Also mged gets a modified wdb_obj.c stuffed into it to define its tcl commands until someone can come |
| 17:21.33 | Notify | in and clean that up properly. |
| 17:27.44 | Notify | 03BRL-CAD:starseeker * 62642 (brlcad/branches/gecode/doc/docbook/system/man1/en/pixscale.xml brlcad/branches/gecode/include/CMakeLists.txt and 104 others): Sync with trunk up to r62641 |
| 17:28.21 | Notify | 03BRL-CAD:starseeker * 62643 (brlcad/branches/bullet/doc/docbook/system/man1/en/pixscale.xml brlcad/branches/bullet/include/CMakeLists.txt and 104 others): Sync with trunk up to r62641 |
| 17:28.43 | Notify | 03BRL-CAD:starseeker * 62644 (brlcad/branches/osg/doc/docbook/system/man1/en/pixscale.xml brlcad/branches/osg/include/CMakeLists.txt and 103 others): Sync with trunk up to r62641 |
| 17:29.31 | Notify | 03BRL-CAD:starseeker * 62645 (brlcad/branches/rel8/doc/docbook/system/man1/en/pixscale.xml brlcad/branches/rel8/include/CMakeLists.txt and 104 others): Sync with trunk up to r62641 |
| 17:34.39 | Notify | 03BRL-CAD:starseeker * 62646 (brlcad/branches/dm-work/doc/docbook/system/man1/en/pixscale.xml Property Changed: and 2 others): Sync with trunk up to r62641 |
| 17:35.32 | Notify | 03BRL-CAD:starseeker * 62647 (brlcad/branches/gct/doc/docbook/system/man1/en/pixscale.xml brlcad/branches/gct/include/CMakeLists.txt and 104 others): Sync with trunk up to r62641 |
| 17:36.28 | *** join/#brlcad mihaineacsu (~mihaineac@109.166.131.174) |
| 18:07.22 | *** join/#brlcad mihaineacsu (~mihaineac@92.81.155.32) |
| 18:32.46 | Notify | 03BRL-CAD:starseeker * 62648 (brlcad/trunk/doc/docbook/system/man3/en/libfb.xml brlcad/trunk/doc/html/ReleaseNotes/email4.0.html and 188 others): Sync dm-work efforts through 62497, plus fix to tclcad_obj.c from 62580, into trunk. This is the 'hide dm and fb' effort. In order to make this work in trunk, we need to temporarily rework the updates to still allow struct dm and struct fb to be part of the public API so |
| 18:32.48 | Notify | code explicitly accessing struct members can still do so (that mechanism will go away after 7.26). Rather than compliate this commit with those struct changes, they will be done in a follow-on commit. |
| 18:35.40 | Notify | 03BRL-CAD:carlmoore * 62649 brlcad/trunk/src/util/pixscale.c: add 'h' to comment |
| 18:38.44 | Notify | 03BRL-CAD:carlmoore * 62650 (brlcad/trunk/doc/docbook/system/man1/en/obj-g.xml brlcad/trunk/src/conv/obj-g.c): rearrange the options in Usage and manpage; change -h, which is not for hi-res, to -H; shut off a redundant bu_log |
| 18:44.52 | Notify | 03BRL-CAD:carlmoore * 62651 brlcad/trunk/doc/docbook/system/man1/en/obj-g.xml: oops, -h was referred to in 2 other places, so change those occurrences to -H |
| 18:46.24 | Notify | 03BRL-CAD:starseeker * 62652 (brlcad/trunk/include/dm.h brlcad/trunk/include/fb.h): Expose the internal headers for the structs. This may still require changing struct definitions from struct dm to either just dm or struct dm_internal... |
| 18:47.46 | Notify | 03BRL-CAD:brlcad * 62653 brlcad/trunk/CHANGES: tighten up the wording on the three change types and note that dg.h is now obsolete (it wasn't documented here but was documented in the file itself as deprecated) |
| 18:52.13 | starseeker | brlcad: if that or some variation on it will work, it's most of the pre-display-list work in the dm-work branch. Unless there's trouble I'll get a preserve-the-freesolid-lists version of the libged refactor in next |
| 18:53.15 | Notify | 03BRL-CAD:brlcad * 62654 brlcad/trunk/NEWS: the bug fix is supplanted with the removal of gdiff. annotate the rewrite of gdiff (still need to move the files/rename the binary) by cliff to improve an overhauled geometry diffing capability. |
| 18:56.08 | brlcad | i'm seeing some minor issuse in the 62648 merge |
| 18:56.20 | brlcad | doc files that got updated erroneously |
| 18:56.46 | starseeker | I think there were a couple that got FBIO changed... |
| 18:57.41 | starseeker | yeah - email4.0.html and libfb.xml. I guess the former at least shouldn't have been changed? |
| 18:59.06 | brlcad | well they both look wrong, but yeah definitely not the e-mail :) |
| 18:59.31 | brlcad | no rewriting history to suit your evil plans |
| 19:00.02 | starseeker | I'll put that one back - libfb.xml should have been updated but I probably didn't do it right |
| 19:00.45 | brlcad | so reviewing public API changes, fbio.h elimination ... where did RGBpixel end up? |
| 19:01.02 | starseeker | fb.h |
| 19:01.04 | Notify | 03BRL-CAD:starseeker * 62655 brlcad/trunk/doc/html/ReleaseNotes/email4.0.html: Historical documentation, not living documentation - restore |
| 19:02.04 | brlcad | can you annotate that in CHANGES, minimally impacting change of #include fbio.h to fb.h (so anything that might have been construed as non-struct public is now provided by fb.h) |
| 19:02.18 | starseeker | ah, sure |
| 19:03.55 | brlcad | I'm basing the struct changes on the notion that we've never actually published or documented that anywhere, but I'm pretty sure I've seen some of the little tidbits like RGBpixel in use |
| 19:04.06 | starseeker | brlcad: minor nitnoid - how come the minor changes go low->high release number down the page, but the deprecated/obsolete sections go the other way? |
| 19:04.14 | brlcad | so structs can go on whim, but still good to note the entire header going poof |
| 19:05.25 | brlcad | starseeker: frankly, for efficiency |
| 19:05.41 | brlcad | new items only have to get added to the top, so no searching to add |
| 19:05.46 | starseeker | nods |
| 19:05.52 | brlcad | can jump to the bottom to add minimally impacting |
| 19:05.59 | starseeker | ah :-) |
| 19:06.26 | starseeker | makes sense - caught me off guard, initially though you would have gone for uniform ordering ;-) |
| 19:06.32 | brlcad | makes them inconsistent with each other, but I figure we will spend FAR more time editing that file than others will reading it to notice that |
| 19:06.37 | starseeker | so this will be the first 7.26 change? |
| 19:06.55 | brlcad | er, shouldn't be... |
| 19:07.08 | starseeker | sees only 7.24 at the bottom... |
| 19:07.15 | brlcad | ahh, yeah, the marker is missing |
| 19:07.19 | brlcad | is goes somewhere in there... |
| 19:07.42 | starseeker | after the last 7.23? |
| 19:07.49 | brlcad | yeah |
| 19:07.54 | brlcad | i think right before bu_kill_parallel |
| 19:07.57 | brlcad | but lemme check |
| 19:09.24 | brlcad | yep, that looks like where it goes |
| 19:09.52 | starseeker | k - regex coming up |
| 19:10.00 | brlcad | and all those 7.24's should be 7.25 |
| 19:10.39 | brlcad | (the three or so minimally impacting in the 7.26 cat should be 7.25) |
| 19:10.50 | starseeker | and the ones above the new 7.26 should be 7.23? |
| 19:11.42 | brlcad | no, they were changed in 7.24 |
| 19:12.14 | Notify | 03BRL-CAD:starseeker * 62656 brlcad/trunk/CHANGES: Add the 7.26 header, update release numbers, add fbio.h -> fb.h regex |
| 19:12.25 | starseeker | there we go :-) |
| 19:12.32 | brlcad | the [] reflect what was in include/conf when the change was made, the label reflects which release that was published |
| 19:13.30 | starseeker | generally speaking, should I try to add CHANGES lines in branches for merging, or add them in trunk after the merge? |
| 19:14.05 | brlcad | probably best to do them in the branch as you make the changes so there's less chance they get overlooked |
| 19:14.22 | brlcad | and they get merged as the change is merged |
| 19:14.39 | brlcad | same with news |
| 19:16.36 | Notify | 03BRL-CAD:starseeker * 62657 brlcad/trunk/doc/docbook/system/man3/en/libfb.xml: Fix fb_NULL search-and-replace fail. |
| 19:31.27 | starseeker | brlcad: if you prefer to play save with gdiff we can add it back in for 7.26 - I was mostly being lazy in the branch, but since we're merging in at this point I can go back and have a go at unraveling it. |
| 19:46.58 | Notify | 03BRL-CAD:n_reed * 62658 (brlcad/branches/brep-debug/AUTHORS brlcad/branches/brep-debug/CHANGES and 393 others): sync from trunk through r62657 |
| 20:10.52 | brlcad | starseeker: your call, I'm good with replacing if you think the new is stable enough and featured for use |
| 20:11.45 | brlcad | maybe try a little script that gdiff's all our sample dbs against all others with all the various gdiff options just to see if you can get bad behavior |
| 20:17.45 | *** join/#brlcad vladbogo (~vlad@188.25.101.43) |
| 20:25.49 | *** join/#brlcad vladbogo (~vlad@188.25.101.43) |
| 20:49.48 | starseeker | vladbogo: howdy! |
| 20:51.11 | vladbogo | starseeker: hi |
| 20:52.35 | starseeker | vladbogo: apologies if I managed to break any of the Qt code with that last batch of commits - I'll try to remedy any errors tonight |
| 20:53.34 | vladbogo | starseeker: no worries, I only saw a duplicate case in tclcad_obj |
| 20:54.49 | starseeker | vladbogo: had a chance to see what's involved with replacing the Tk window with a Qt version? |
| 20:55.15 | starseeker | is (over)optimistically thinking that could be as simple as window creation logic and key bindings... |
| 20:56.32 | starseeker | brlcad: hmm, good idea (script) |
| 20:58.29 | Notify | 03BRL-CAD:carlmoore * 62659 brlcad/trunk/doc/docbook/system/man1/en/nirt.xml: use <command>nirt</command> more often |
| 20:59.27 | vladbogo | starseeker: I've taken a brief look and it shouldn't involve much more than, as you said, keybindings and event processing |
| 20:59.38 | starseeker | cool |
| 21:00.17 | vladbogo | so I was thinking about giving a try in the next few weeks to see what it comes up |
| 21:00.27 | starseeker | awesome |
| 21:01.07 | vladbogo | so I'll create a new branch and start working and come back with updates |
| 21:01.56 | starseeker | sounds good - if any of the dm/fb shuffle that's going on with my stuff starts causing trouble (bad interactions with Qt, whatever) don't hesitate to let me know |
| 21:02.30 | vladbogo | ok, I will |
| 21:04.25 | starseeker | proceeds to diff everything with everything... |
| 21:04.35 | vladbogo | since I haven't worked with branches in svn, is svn copy all I need in order to create a new branch? |
| 21:04.44 | starseeker | yep - very easy |
| 21:05.16 | starseeker | http://svnbook.red-bean.com/en/1.7/svn.branchmerge.using.html |
| 21:05.42 | starseeker | main trick for BRL-CAD is to put the branch in the right place |
| 21:06.06 | vladbogo | thanks |
| 21:06.39 | starseeker | so for this it'd be https://svn.code.sf.net/p/brlcad/code/brlcad/branches/qtged (or whatever you wanted to name it) |
| 21:08.11 | vladbogo | that's what I thought that the location will be |
| 21:08.13 | vladbogo | thanks |
| 21:08.37 | starseeker | most people get it right - I'm the only one in recent memory who put his in the wrong place ;-) |
| 21:10.13 | starseeker | and whadya know, gdiff did crash... let's see why... |
| 21:15.16 | starseeker | dsp... figures... |
| 21:17.58 | Notify | 03BRL-CAD:n_reed * 62660 brlcad/branches/brep-debug/src/libbrep/boolean.cpp: fix copy-paste error |
| 21:20.35 | Notify | 03BRL-CAD:vladbogo * 62661 (svn:ignore ## -0,0 +1,2 ## and 2 others): Created a Qt branch. |
| 22:04.46 | Notify | 03BRL-CAD:carlmoore * 62662 brlcad/trunk/doc/docbook/system/man1/en/nirt.xml: touch up, and add a missing right bracket |
| 22:29.41 | Notify | 03BRL-CAD:starseeker * 62663 (brlcad/trunk/NEWS brlcad/trunk/src/librt/primitives/dsp/dsp.c): Fix bug in g2asc/asc2g handling of dsp primitive - round trip wasn't working previously. |
| 22:38.34 | starseeker | brlcad: when I gdiff2 goliath.g with itself, I'm getting some sort of weird corrupted memory crash that seems to be mixed up with db_dircheck and bu_log |
| 22:40.28 | starseeker | I'm thinking that diffing a file with itself isn't going to be a big thing, and it's not clear to me this is gdiff2's fault... |
| 23:03.19 | Notify | 03BRL-CAD:starseeker * 62664 brlcad/trunk/src/gtools/gdiff2/gdiff2.c: Free search results from diff |
| 23:10.57 | Notify | 03BRL-CAD:starseeker * 62665 brlcad/trunk/src/gtools/gdiff2/gdiff2.c: Catch cases of identical files up front for gdiff2 |
| 23:11.04 | starseeker | hooray for input validation |
| 23:38.20 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
