| 01:18.52 | *** join/#brlcad cadman (40b2b147@gateway/web/freenode/ip.64.178.177.71) |
| 01:19.03 | starseeker | brlcad: the temptation to try what I was originally planning with the libnurbs sf site is growing, so probably easier to avoid conflicts ahead of time in case that does happen |
| 01:19.40 | starseeker | plus, it matches the brep.h header name we were already using everywhere |
| 01:27.44 | Notify | 03BRL-CAD:starseeker * 54596 (brlcad/trunk/configure.ac brlcad/trunk/misc/win32-msvc/Dll/CMakeLists.txt and 3 others): Tell autotools and Dll about name change too. |
| 01:41.31 | Notify | 03BRL-CAD Wiki:Gudaoshupi * 0 /wiki/User:Gudaoshupi: |
| 01:47.48 | Notify | 03BRL-CAD:brlcad * 54597 (brlcad/trunk/src/other/openNURBS/CMakeLists.txt brlcad/trunk/src/other/openNURBS/Makefile.am and 9 others): re-re-revert to r54338 before I started causing damage. apparently two different versions of opennurbs came out one month after the other, both labeled as v5.0 and the latter removing substantial functionality (3 functions) that we utilize. there are some files to get a closer sync |
| 01:47.50 | Notify | with the latest sources, but we'll need to either keep a *much* bigger patch set or implement even more functionality in our libraries going forward. |
| 01:54.08 | *** join/#brlcad merzo (~merzo@106-51-133-95.pool.ukrtel.net) |
| 05:49.04 | brlcad | starseeker: sure, it's merely whether to align the name with opennurbs or librt .. it was intently set up to not rely on librt, so the name made sense |
| 05:49.32 | brlcad | I guess I saw it evolving into what you had planned for the sf site |
| 05:50.37 | brlcad | because if it really is just for librt's brep, then it's pointless as a top-level library and should get buried back under librt |
| 06:26.03 | Notify | 03BRL-CAD:brlcad * 54598 (brlcad/trunk/src/other/openNURBS/CMakeLists.txt brlcad/trunk/src/other/openNURBS/Makefile.am and 10 others): redo the merging of additional updates, adding in some overlooked changes from the previous v5.0 update, without all the mess. adds back the deleted opennurbs_brep_kinky.cpp and opennurbs_brep_changesrf.cpp for reference since they seem highly relevant to our needs (along with code |
| 06:26.05 | Notify | in opennurbs_brep so they'll compile). remerges r54573 (partial), r54576 (partial), r54577, r54580, and r54589. |
| 06:26.20 | brlcad | that should do it |
| 07:52.50 | *** join/#brlcad caen23 (~cezar@92.83.186.143) |
| 11:30.36 | ``Erik | 'dark corners of C' https://docs.google.com/presentation/d/1h49gY3TSiayLMXYmRMaAEMl05FaJ-Z6jDOWOz3EsqqQ/edit?usp=sharing |
| 13:36.39 | *** join/#brlcad merzo (~merzo@59-223-201-46.pool.ukrtel.net) |
| 15:27.40 | starseeker | brlcad: my sf libnurbs ambitions may not jibe well with the direction you'd want to take though - I was planning to add more primitives, for example, similar to the torus and sphere they already have |
| 15:27.59 | starseeker | If I can figure out how, I may convert the source code comments to doxygen format |
| 15:29.22 | starseeker | my take would be more to turn it into what I would want in the library, then merge in changes from opennurbs releases as appropriate - which I know is not how you want to go at it <shrug> |
| 15:33.05 | *** join/#brlcad Black_Rabbit (~Black_Rab@115.248.130.148) |
| 15:33.28 | *** join/#brlcad Blackrabbit (~Black_Rab@115.248.130.148) |
| 15:34.12 | brlcad | starseeker: "which I know is not how you want to go at it" ... non sequitor? :) |
| 15:34.39 | starseeker | eh? You've argued consistently in favor of keeping opennurbs vanilla and working with that |
| 15:34.59 | brlcad | adding more prims, converting docs, merging opernurbs releases, .. none of that is really concerning |
| 15:35.18 | starseeker | except it starts to involve extensive changes to the opennurbs code |
| 15:35.25 | brlcad | and I wouldn't necessarily have to agree with what you're wanting to do for it to be useful or good for you, right? |
| 15:35.57 | starseeker | sure, but I'm not going to oppose you on something like that within BRL-CAD - the bests interest of the BRL-CAD project are what's important for its component libraries |
| 15:36.23 | starseeker | my approach would fairly quickly result in a de-facto fork, in the sense that a system opennurbs wouldn't be compatible |
| 15:36.25 | brlcad | actually, I layed out two or three ways to work with opennurbs and only one involved keeping vanilla, but still that's not exactly opposition to anything |
| 15:37.02 | brlcad | I knew you had other ambitions and directions, that's great frankly |
| 15:37.30 | brlcad | it's whether both needs can be fit, so it gets more eyes an invovlement from my perspective |
| 15:37.39 | starseeker | um. OK. I may have gotten the wrong impression - my distinct memory was you were very keen on keeping compatibility with a hypothetical system opennurbs, but I could have misunderstood |
| 15:38.24 | brlcad | example in point, I don't see the practical point of doing incremental loading (at this point) in stepCODE, and would probably voice entirely different priorities |
| 15:38.32 | brlcad | but that doesn't mean I'm actually against it |
| 15:38.39 | brlcad | python bindings another great example |
| 15:38.55 | brlcad | just doesn't solve my problems, but then it's not supposed to -- just not a concern |
| 15:39.36 | starseeker | nods |
| 15:39.37 | brlcad | I am keep on keeping compatibility, but that doesn't mean I'd be opposed to something else either |
| 15:39.47 | brlcad | s/keep on/keen on/ |
| 15:40.49 | brlcad | if you think it's too much work (or work you don't care about) to try and fit your goals with our needs, that's fine but I generally like to press for more active collaboration, not less ;) |
| 15:41.08 | starseeker | hmm. looking at it from that perspective, perhaps it doesn't make sense in any case for us to expose the brep/nurbs API as a top-level BRL-CAD api |
| 15:42.06 | starseeker | brlcad: I was more concerned that I was going to hare off in directions that quickly diverged from the opennurbs vanilla goal, and I thought that was a non-starter |
| 15:42.44 | brlcad | it would entirely depend on how that direction affects our integration |
| 15:43.28 | brlcad | you written down plans or a road map any where? easy enough to go over something and see if there are concerns |
| 15:43.56 | starseeker | only a few early thoughts - I'll write up a little more of what I'm thinking this evening |
| 15:43.57 | brlcad | I mean I think I get what you're thinking, turning it into some stand-alone framework for working with nurbs geometry |
| 15:44.06 | starseeker | right |
| 15:44.21 | starseeker | but I wouldn't be shy about adding things like mesh-related algorithms if they look useful |
| 15:44.29 | brlcad | but that statement by itself doesn't say much of anything about integration concerns |
| 15:45.25 | brlcad | and if you did add algorithms, I wouldn't exactly care either -- would start to treat it like any other src/other with features we may or may not use |
| 15:45.34 | starseeker | nods |
| 15:45.38 | brlcad | it starts to matter when it's not algorithms |
| 15:45.47 | starseeker | ... api changes? |
| 15:46.12 | brlcad | when it's code and 3rd party depdencies or implicit platform requirements, etc |
| 15:46.18 | starseeker | oh, gotcha |
| 15:46.41 | brlcad | you know, you decide that meshlab is pefect for what you need |
| 15:46.47 | brlcad | *that* becomes a non-starter |
| 15:46.52 | starseeker | winces |
| 15:46.59 | starseeker | I wouldn't blame you a bit |
| 15:47.33 | brlcad | or more realistic, like if you relied on opengl tessellation because it's fast and awesome, but we're not yet ready to require it or some similar coupling |
| 15:48.08 | starseeker | I'll jot some notes down - it hadn't been very high on my list lately, but opennurbs yanking working functionality sort of makes the issue loom back above the radar horizon |
| 15:48.21 | brlcad | that's my concern |
| 15:48.38 | brlcad | they're actually making it a lot easier |
| 15:48.52 | starseeker | O.o ? |
| 15:49.19 | brlcad | with the functions no longer stubbed empty, it's a lot easier to either do an inheritance overlay or sister API that adds functionality back in |
| 15:49.49 | brlcad | my concern is retaining our ray tracing ability with as little effort as possible first, and later preserving our ability to edit |
| 15:50.14 | brlcad | to me, that's just where does that code live and how often will we have to do something to maintain it |
| 15:51.23 | brlcad | in going through all the changes that were needed to preserve our tracing in this latest update, it's at least 3 functions that would need to be extracted (in my view, there are certainly other approaches) |
| 15:51.44 | starseeker | nods - fair enough. I've got some errands to run, but I'll work on what I'm thinking this afternoon |
| 15:51.58 | brlcad | I'm going to assume that they'll keep releasing updates, keep adding new features and fixing bugs, and keep removing anything in the API not related to 3dm conversion |
| 15:52.20 | starseeker | yeah, which is a real problem if we want to use things like opennurbs_x.h |
| 15:52.34 | brlcad | it took me the better part of a day to go through that last update, and I don't see that as viable to repeat the further they divert |
| 15:52.49 | brlcad | if you have a plan for that, I'd love to hear it ;) |
| 15:53.09 | brlcad | I see that functionality simply migrating as functions in libnurbs |
| 15:53.33 | brlcad | one for each they removed frankly, and some additional functionality |
| 15:54.56 | starseeker | nods - I may need to do some experiments with git to see how difficult it's going to be |
| 15:55.34 | starseeker | my hope was that as they get simplier, if we retain a more complete set of APIs the merge areas where we actually need to make real changes will become more constrained |
| 15:55.55 | starseeker | but that may not be possible, since we may *need* to add functionality they don't provide to preserve those APIs |
| 15:57.57 | starseeker | I have the 20120914 tarball of opennurbs, so I'll study the changes and see what we're up against |
| 15:58.51 | brlcad | they mostly are just cutting out methods |
| 15:59.17 | starseeker | growl |
| 15:59.19 | brlcad | so it is certainly possible to readd those methods and classes back in |
| 15:59.48 | starseeker | we'd need an inheritance API to do that right though, correct? |
| 15:59.55 | brlcad | not necessarily |
| 16:00.08 | brlcad | like I said way back, there are like three different ways to go about it |
| 16:00.30 | brlcad | inherit, replace, or supplant |
| 16:01.04 | starseeker | inherit == define our own classes that inherit from theirs, correct? |
| 16:01.24 | brlcad | yep, arguably the most work, almost certainly the most code |
| 16:02.06 | starseeker | replace == define new functions that provide the capabilities yanked from the original code? |
| 16:02.27 | brlcad | you have to create nearly as many classes as there are in opennurbs to provide an inheritance API |
| 16:03.01 | starseeker | not to mention every time they change their classes we have to keep up... |
| 16:03.13 | brlcad | the downsides/upsides are your users would have to adopt and use your API classes, not opennurbs, and you'd have to track any class changes |
| 16:03.41 | brlcad | replace is defining new/old functions and putting that code BACK into opennurbs, e.g., patches |
| 16:03.51 | starseeker | a quick grep identifies 370 class ON_CLASS definitions |
| 16:04.19 | brlcad | that method lets users stick to opennurbs API and basically becomes more and more of a free open source rhinosdk implementation |
| 16:04.50 | starseeker | but gets progressively more difficult the further we want to be from what the latest opennurbs provides |
| 16:04.51 | brlcad | the downside is of course they can make it arbitrarily hard to keep up patches |
| 16:05.03 | brlcad | but that's probably the only downside |
| 16:05.22 | starseeker | that's a potentially significant one though - they have an incentive to make that approach difficult |
| 16:05.32 | brlcad | another approach for "replace" is an outright fork |
| 16:05.46 | brlcad | instead of patches, just track their releases and integrate what you care about as they update |
| 16:05.46 | starseeker | thought that's what you ment by supplant... |
| 16:05.57 | brlcad | supplant is what I saw libnurbs being |
| 16:06.11 | brlcad | a sister library that works with opennurbs |
| 16:06.41 | starseeker | ah - no, I was thinking fork and merge what we care about |
| 16:06.54 | starseeker | at least for the sourceforge project |
| 16:07.02 | brlcad | when you see them yank, ON_Curve::GetLength(...), the sister library implements a GetLength(ON_Curve, ...) |
| 16:08.16 | brlcad | yeah, supplant might not be the best word, maybe delegation or partnering |
| 16:08.30 | starseeker | a downside there is the collective API of the two libraries gets trickier to navigate |
| 16:08.40 | brlcad | but still, creating a library that works beside or on top of opennurbs |
| 16:08.54 | starseeker | where do I look for functionality, mixing API styles, etc. |
| 16:09.16 | brlcad | that's where my thought was to literally just implement the methods they remove -- they identify them neatly in opennurbs_basic |
| 16:10.04 | brlcad | so you could follow the full rhinosdk, and if you found something that didn't link, there would be a function |
| 16:10.49 | brlcad | "overlay" .. that's the word I was looking for |
| 16:11.20 | brlcad | inherit, restore, fork, or overlay |
| 16:11.32 | brlcad | all have merit and all are lots of work :) |
| 16:12.08 | starseeker | you said based on you work with the 5.0 changes you though reviewing the changes and merging would be a prohibitive amount of work? |
| 16:12.18 | brlcad | with your idea to add functionality not even covered, that would undoubtedly influence the approach taken |
| 16:13.26 | brlcad | not prohibitive, but *I* wouldn't want to do it very frequently, I'd probably end up forking and implementing a free rhinosdk |
| 16:13.45 | brlcad | easier to merge their changes than restore our needs |
| 16:14.07 | brlcad | they're not going to change the API faster than we can manage, because of their users/business |
| 16:14.41 | brlcad | but that's also politically the most impolite, so I'd "want" to try one of the others first |
| 16:14.54 | brlcad | overlay seemed to be the route we were going |
| 16:15.26 | brlcad | to me that really is, then, a "libnurbs" that proides what they don't (and then some if you do what you're thinking) |
| 16:15.27 | starseeker | in the BRL-CAD tree, yes - it wasn't actually my own preference, but I had gotten the impression that that was what I needed to do when working inside BRL-CAD |
| 16:16.50 | brlcad | so whatever you have in mind, even towards becoming a bigger "nurbs" framework .. somewhere/somehow you're going to need to get the length of a curve |
| 16:16.59 | brlcad | where were/are you seeing that happening? |
| 16:17.25 | starseeker | yes. If we want to keep they API style consistent, that would involve putting GetLength back where they had it |
| 16:17.26 | brlcad | given they yanked ON_Curve::GetLength(), that becomes a perfect simple case |
| 16:17.42 | brlcad | so you'd go for "restore" |
| 16:17.54 | starseeker | any thing else means we can't ask an ON_Curve object for its length with GetLength, which means the API has become that much less consistent |
| 16:18.07 | starseeker | my instinct would be to restore, yet |
| 16:18.12 | starseeker | s/yet/yes |
| 16:18.20 | starseeker | but I can't claim I've thought that all the way through |
| 16:18.20 | brlcad | any one of inherit, restore, fork, or overlay let you get a length |
| 16:18.32 | brlcad | three of them let you actually call a GetLength() method even |
| 16:19.01 | starseeker | correct |
| 16:19.30 | starseeker | I was figuring enough "restore" becomes "fork" by default |
| 16:19.59 | brlcad | inherit would be Cliff_Curve::GetLength(), restore would be ON_Curve::GetLength(), fork would be ON_Curve::GetLength(), overlay would be GetLength(ON_Curve) |
| 16:20.36 | starseeker | right. So restore and fork preserve the API as designed - is that a worthwhile goal? |
| 16:20.43 | brlcad | meh |
| 16:21.08 | brlcad | to me, it's more about the long term maintainability |
| 16:21.31 | starseeker | on the other hand, a consistent API plays into long term *usability*... |
| 16:21.34 | brlcad | fast forward 20 releases later to opennurbs v9.4 |
| 16:21.41 | brlcad | what have you had to do |
| 16:21.56 | brlcad | and where did you end up |
| 16:22.35 | brlcad | again, I'm not apposed to any approach, especially if I'm not doing it ;) |
| 16:22.58 | starseeker | what has to be done depends on how radical the changes are in openNURBS |
| 16:23.07 | brlcad | I care about preserving our raytracing ability with the least amount of effort (because we have a hell of a lot of other things to worry about) |
| 16:23.49 | brlcad | given enough time, it becomes radical |
| 16:24.09 | brlcad | even if the API isn't, they're a business with momentum |
| 16:24.27 | starseeker | precisely - why is why I was thinking it might make sense to encapsulate just what our raytracing abilities need in a special purpose BRL-CAD library and let the libnurbs project try the risker, higher effort stuff |
| 16:24.57 | starseeker | or even encapsulate them in librt, for that matter |
| 16:25.29 | starseeker | because BRL-CAD isn't in the business of general purpose NURBS library development, we have specific needs that we need to satisfy |
| 16:28.53 | starseeker | so make it the business of src/librt/primitives/brep to either a) talk to openNURBS or b) supply the minimal pieces necessary for BRL-CAD's needs - that's probably the safest, most focused approach we could take (the overlay option, but only as librt internals and not an exposed, public API) |
| 16:30.06 | starseeker | that may not be entirely practical when it comes to things like the step converter, though |
| 16:31.03 | starseeker | so the minimal overlay library is probably the most efficient way to get what we need to preserve our own features |
| 16:32.41 | Notify | 03BRL-CAD:n_reed * 54599 brlcad/trunk/src/libged/draw.c: use smarter point spacing calculation for tgcs |
| 16:33.06 | starseeker | for the libnurbs project though, I'd be hovering between restore and fork |
| 20:38.51 | *** join/#brlcad merzo (~merzo@22-8-133-95.pool.ukrtel.net) |
| 20:50.38 | *** join/#brlcad merzo (~merzo@160-120-132-95.pool.ukrtel.net) |
| 21:17.04 | starseeker | brlcad: do you happen to have any archived sources of opennurbs older than the version 4 we have in the repository? |
| 21:26.00 | *** join/#brlcad ``Erik (~erik@pool-74-103-121-45.bltmmd.fios.verizon.net) |
| 23:27.30 | starseeker | brlcad: I'm collecting what I can scare up as far as opennurbs versions here, fwiw - http://brlcad.org/~starseeker/opennurbs/ |
| 23:28.11 | starseeker | http://brlcad.org/~starseeker/opennurbs/README has the background - I may have a few more old original opennurbs vanilla sources stashed away somewhere, but that's what I've been able to locate or reconstruct to date |