| 00:01.09 | brlcad | yeah, once you start making a little progress, your commits (and your commit messages) will be just as important if not more important than progress updates .. good stuff |
| 00:01.58 | bhinesley | nods |
| 00:02.03 | bhinesley | there will be a lot going through today |
| 00:10.31 | *** join/#brlcad Stattrav (~Stattrav@117.192.142.216) | |
| 00:10.31 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 00:26.32 | *** join/#brlcad crazy_imp (~mj@a89-182-166-16.net-htp.de) | |
| 01:09.43 | *** join/#brlcad Stattrav (~Stattrav@117.192.142.216) | |
| 01:09.43 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 01:24.13 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 01:41.07 | CIA-61 | BRL-CAD: 03bhinesley * r44769 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl ArcherCore.tcl): (log message trimmed) |
| 01:41.07 | CIA-61 | BRL-CAD: This was an incremental step towards: 1) adding the man command to archer 2) |
| 01:41.07 | CIA-61 | BRL-CAD: creating a megawidget for the manual page browser, to eliminate code duplication |
| 01:41.07 | CIA-61 | BRL-CAD: among Archer and MGED. Progress already made on the actual megawidget will be |
| 01:41.07 | CIA-61 | BRL-CAD: added in a bit. |
| 01:41.07 | CIA-61 | BRL-CAD: -Man command now works in Archer |
| 01:41.08 | CIA-61 | BRL-CAD: -Changed the method of adding commands to the Manual Page Browser ToC from "insert end" to using -listvariable as recommended here: http://www.tkdocs.com/tutorial/morewidgets.html |
| 02:44.55 | CIA-61 | BRL-CAD: 03bhinesley * r44770 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Removed doarcherMan, and set Help->Man Pages to call the man command directly |
| 03:22.01 | brlcad | woot |
| 03:31.18 | bhinesley | :-P |
| 03:31.36 | CIA-61 | BRL-CAD: 03brlcad * r44771 10/brlcad/trunk/NEWS: brandon added the 'man' command to archer. |
| 03:33.03 | bhinesley | ah |
| 03:33.19 | bhinesley | shall I make an effort to keep that updated? |
| 03:33.28 | starseeker | it's usually easier |
| 03:33.39 | starseeker | add user-visible stuff |
| 03:34.00 | bhinesley | ok |
| 03:34.52 | starseeker | brlcad: what plans did you have for the architecture of libgcv? I've been reading up on the issue indianla1ry ran into with trying to turn the step-g factory mechanism into a library - the whole "compiler removing static" thing |
| 03:35.12 | starseeker | there appears to be No Good Solution if you stick to straight C++ |
| 03:35.44 | starseeker | not compiler, linker stripping out static rather |
| 03:35.46 | CIA-61 | BRL-CAD: 03brlcad * r44772 10/brlcad/trunk/NEWS: |
| 03:35.47 | CIA-61 | BRL-CAD: brandon also improved the manual page browser gui behavior with improved |
| 03:35.47 | CIA-61 | BRL-CAD: performance (using listbox variable binding instead of adding items manually) |
| 03:35.47 | CIA-61 | BRL-CAD: and adding a ListboxSelect event binding so keys, clicking, and dragging work. |
| 03:36.15 | brlcad | bhinesley: yeah, any time you make a change that is *user* visible, it warrants a one-line entry in the NEWS file |
| 03:37.10 | brlcad | the file has a specific format (described at the bottom) and the commit message per line is important |
| 03:38.01 | starseeker | is getting desperate enough to consider embedding scheme or lisp to escape the limits of C++/C... |
| 03:38.02 | brlcad | the svn log is automatically parsed with a script that pulls each commit message for each feature line which we use to review features, so try to only commit one line at a time and make your commit message as descriptive as needed |
| 03:38.39 | brlcad | starseeker: not sure what you're referring to |
| 03:39.01 | brlcad | step-g's factory mechanism isn't a very good way to do things.. |
| 03:39.18 | starseeker | erm. what's the better way? |
| 03:39.45 | brlcad | first, what's the goal? :) |
| 03:39.45 | starseeker | was under the impression the factory design was the recommend approach to that sort of problem... |
| 03:39.50 | brlcad | factory sure |
| 03:39.57 | brlcad | there's lots of ways to make factory |
| 03:40.06 | bhinesley | brlcad: I'm not sure I follow... you're saying keep commit messages brief? |
| 03:40.32 | starseeker | architect the library in such a way that you can write one file per format, add it to the library without changing anything else, and have the conversion routines be able to find it when some program using the library asks for it |
| 03:40.50 | brlcad | bhinesley: no no, the messages can/should be any details not encoded in the 70-char news line, like why or bug report numbers or who reported a bug or who requested the feature, ets |
| 03:41.09 | bhinesley | oh okay |
| 03:41.13 | brlcad | starseeker: one file per format is probably not feasible |
| 03:41.15 | bhinesley | that's what I figured |
| 03:41.25 | starseeker | growl |
| 03:41.39 | brlcad | i mean, there'd be just one set of function hooks per format |
| 03:41.49 | brlcad | ala src/librt/primitives |
| 03:41.55 | brlcad | but it's a set of funcs that you'd need |
| 03:42.08 | brlcad | probably not just read and write |
| 03:42.26 | brlcad | but even those two, rather different requirements |
| 03:44.30 | brlcad | starseeker: as for the rest (add it to the library without changing anything else, and have the conversion routines be able to find) .. that's pretty easy |
| 03:44.48 | brlcad | even a simple freshman textbook factory implementation will do that |
| 03:45.02 | brlcad | or dynamic loaded library snippets |
| 03:45.42 | starseeker | what's the problem with step-g's implementation then? |
| 03:45.55 | starseeker | I was under the impression indianla1ry designed it fairly carefully |
| 03:46.58 | brlcad | it's using the sdai (app interface) from the step class libraries |
| 03:47.28 | starseeker | I'm not sure that's the reason it wouldn't work as a lib though... |
| 03:47.29 | brlcad | it static-initializes variables, then searches at runtime for those classes |
| 03:47.48 | starseeker | right - most of the C++ Factory discussions I can find do something like that |
| 03:47.55 | brlcad | the problem was there was some compiler (erroneously) optimizing away those static classes so they didn't exist iirc |
| 03:48.08 | brlcad | not the way sdai did it |
| 03:48.14 | brlcad | it was a nit pick detail |
| 03:48.15 | starseeker | shakes his head - that's not a compiler error, according to everything that I can find |
| 03:48.25 | brlcad | the overall approach they intended was 'okay' |
| 03:49.12 | brlcad | it relied on static variable initialization ordering, which isn't guaranteed |
| 03:49.33 | starseeker | http://programmerjoe.com/2007/03/18/the-abstract-factory-pattern-in-c/ |
| 03:49.51 | starseeker | that article mentions the linker stripping out "unreferenced" static variables |
| 03:50.01 | brlcad | they needed to require an init point other than main() (like loading a library or an explicit init() method) |
| 03:51.01 | brlcad | right off the bad, that write-up isn't entirely accurate |
| 03:51.22 | brlcad | lack of an ability to instantiate an object at runtime given the name of a class .. you can, it's just complicated |
| 03:52.29 | starseeker | it must be, I can't find anything so far telling me how to do it |
| 03:52.57 | brlcad | he states the problem: "you won't be referencing these classes and objects directly, so you have to force the linker to include them by adding references" |
| 03:53.32 | brlcad | it's all in how you build up the factory, and there are lots of ways to go about it |
| 03:53.47 | brlcad | sdai's method was a little sucky, but a simple reference fixes the optimization problem |
| 03:54.02 | brlcad | actual code example I wrote a few years ago: https://bzflag.svn.sourceforge.net/svnroot/bzflag/branches/experimental/v2_99continuing/bzflag/src/include/Factory.h |
| 03:55.02 | brlcad | that's the abstract factory, here showing a real factory: https://bzflag.svn.sourceforge.net/svnroot/bzflag/branches/experimental/v2_99continuing/bzflag/src/bzfs/SpawnPolicyFactory.h |
| 03:55.34 | brlcad | and then the 'simple fix' that lets the linker know that you don't want it to optimize away: https://bzflag.svn.sourceforge.net/svnroot/bzflag/branches/experimental/v2_99continuing/bzflag/src/bzfs/SpawnPolicyFactory.cpp |
| 03:55.45 | brlcad | (see the _init() function) |
| 03:56.32 | starseeker | yes |
| 03:56.41 | brlcad | if I wanted to avoid the explicit list of types (which isn't all that bad really, factory lists don't really tend to change that frequently) |
| 03:57.01 | brlcad | I'd just have made loadable library modules, and load / register them all in _init() |
| 03:57.32 | brlcad | think dlopen() style |
| 03:58.02 | starseeker | um... wouldn't that get rather messy if you started to have hundereds of types floating around? |
| 03:58.39 | brlcad | not really, it's still just an entity list |
| 03:58.43 | starseeker | also, is that portable? (loadable library modules) |
| 03:58.56 | brlcad | pretty much, but I'd start with an explicit list |
| 03:59.51 | starseeker | so is that _init call in a library or an executable? |
| 04:00.04 | ``Erik | might be worth seeing how OS's deal with, say, network cards... I think that might be somewhat analogous. FBSD has a set of common functions and some macro fu to 'register' |
| 04:00.18 | brlcad | starseeker: an exectuable in that case, but it could go into a lib too |
| 04:01.53 | brlcad | the libgcv api should get written down first before getting mired in implementation detail like this, issues that might screw up the api if done poorly |
| 04:02.00 | ``Erik | my concern is that different formats hold different kinds of data, so your intermediate format is either a massive superset or a minimal subset :/ |
| 04:02.47 | brlcad | .g or .step are both fairly massive supersets |
| 04:02.55 | brlcad | or at least have arbitrary storage capability |
| 04:03.23 | starseeker | massive superset doesn't worry me - a pivot format in a conversion library of this nature will be conceptually broad of necessity |
| 04:03.33 | brlcad | in-mem .g ftw imnsho ;) |
| 04:03.47 | starseeker | we we need is a technically sound way to manage that complexity and extend it cleanly |
| 04:03.51 | brlcad | that's how most of the code is already written anyways, least effort |
| 04:04.19 | brlcad | best performing too, of known options |
| 04:04.55 | starseeker | if we focus on just what .g supports, yeah that's the simple route. But it means the conversion library will remain special purpose, because there are a LOT of things we don't support now in the .g format |
| 04:04.58 | brlcad | but the api shouldn't care -- it's more "import from X" .. then "export as Y" |
| 04:05.14 | brlcad | using in-mem .g or whatever else is just the in-between implementation detail |
| 04:05.25 | starseeker | sure, but the devil's in the details |
| 04:05.54 | brlcad | nothing says we have to only focus on what .g supports |
| 04:06.11 | brlcad | just need a mechanism for storing and recovering |
| 04:06.16 | starseeker | uh... if we're using .g as the in-mem pivot format... |
| 04:06.17 | brlcad | which .g has |
| 04:06.27 | brlcad | example |
| 04:06.57 | ``Erik | bones, keyframes, animation stuff, programmable definition (povray), ... |
| 04:07.17 | ``Erik | v5 has deficiencies |
| 04:07.30 | brlcad | I can store opengl-style pixel shader information into a .g file along with textures and texture mapping data ... even though brl-cad can't use it |
| 04:08.05 | brlcad | just need to know that's what was stored so when an exporter wants the data, it can pull it |
| 04:08.41 | starseeker | but if you need to convert that to format FOO pixel shader information for three other export formats, where does that logic live? |
| 04:09.02 | ``Erik | you can shove lightwave objects and scenes in an attribute, but without knowledge of the magic black box, conversion is impossible |
| 04:09.05 | starseeker | I doubt we want each exporter to implement all of its own conversion logic for that sort of thing |
| 04:09.12 | starseeker | there will be lots of overlap |
| 04:09.50 | brlcad | starseeker: how's that different than asking "if you need to convert that sphere to format FOO, where does that logic live?" |
| 04:10.01 | brlcad | it lives in format FOO's converter |
| 04:11.22 | brlcad | the only thing an underlying format is going to give you is structure, not necessarily easier access or reduction of export logic |
| 04:11.36 | brlcad | *memory* structure |
| 04:12.25 | brlcad | so .g doesn't have a memory structure for pixel shaders, boo hoo .. don't care really .. libgcv defines a structure and shoves it in, knows the structure, so it can pull it out |
| 04:13.11 | brlcad | this isn't unique to .g in the least .. there's not a single format that doesn't have this issue and would need a similar 'fix' |
| 04:14.22 | brlcad | step would be the closest to being a format that has in-memory structure for almost everything, but it's still NOT everything and you pay for the complexity |
| 04:14.47 | brlcad | can see either working, though, easily enough (step or .g) |
| 04:14.54 | starseeker | 's instinct is that the complexity might be worth paying for... |
| 04:15.36 | brlcad | write a complet g-step and say that again :) |
| 04:16.23 | starseeker | fair enough - but that gets back to trying to understand how to Do It Right - and explicit lists get long fast when we're talking about STEP |
| 04:16.34 | ``Erik | d'no, starseeker... it's not our job to be a zomfg utility conversion toolkit... we do better than most already, but that's a hell of a calling |
| 04:16.48 | brlcad | it's not? :) |
| 04:16.53 | starseeker | ``Erik: I'm not saying we need to be that overnight, but I'd like to architect so that we can grow into that |
| 04:17.04 | brlcad | we do better than everyone at this point (open source) |
| 04:17.37 | starseeker | thinks the best way to get other interests on board is to position ourselves to do it better than ANYONE, closed or open |
| 04:17.50 | brlcad | my thoughts were to leverage existing code as much as possible, because it really is a huge task once you involve more than a couple formats |
| 04:18.38 | ``Erik | some commercial packages do a very impressive job of importing and exporting, but they have tons of resources to throw at satisfying their customers |
| 04:19.06 | brlcad | take the converters main() as they stand now, rewrite them so that stl-g's main is something like stl2g() but the g is opened as an in-mem db and a context is preserved |
| 04:19.12 | starseeker | sure. That's why it's so important we be able to grow incrementally, being clean from the start and gradually expanding our abilities |
| 04:19.36 | brlcad | repeat for all formats, and you have a slew of conversion funcs from files to in-mem .g with very very minimal code change |
| 04:19.40 | CIA-61 | BRL-CAD: 03bhinesley * r44773 10/brlcad/trunk/src/tclscripts/ (archer/Archer.tcl man_browser.tcl pkgIndex.tcl): Added the ManBrowser mega-widget (nonfunctional). This will eliminate code duplication of the Manual Page Browsers among Archer and MGED. |
| 04:20.07 | ``Erik | many conv/ files can be simplified by migrating them to the existing libgcv tesselation functions |
| 04:20.08 | brlcad | register all of those funtions into a table in libgcv and bingo, universal converter |
| 04:20.13 | starseeker | brlcad: My understanding was that we were going to have a lot of code changes anyway as we reduced the duplication of logic during the libgcv conversion |
| 04:20.19 | ``Erik | triangles are a good lcd |
| 04:20.21 | brlcad | ``Erik: yeah they can.... |
| 04:20.26 | brlcad | but it's a royal pita |
| 04:20.32 | brlcad | i've tried a couple times |
| 04:20.52 | ``Erik | I've made an attempt, as well :) |
| 04:20.53 | brlcad | almost all of them have slight tweaks, write out different data at random points in the output, etc |
| 04:21.48 | ``Erik | I threw in a generalized tesselation function into the new stuff I'm doing that'll return a full tree of BoTs, it might be the change we need to migrate |
| 04:22.24 | brlcad | starseeker: ideally, but not necessarily .. reducing the code duplication there is not nearly as trivial as what I described |
| 04:22.58 | brlcad | ``Erik: I saw .. by trying to tessellate from scratch with a different algo... good luck with that ;) |
| 04:23.22 | brlcad | even if it works reliably, that's still 100k lines of code to refactor |
| 04:23.31 | ``Erik | have a working java example, surprisingly small |
| 04:23.32 | brlcad | even if it reduces 10-fold, that's weeks of work |
| 04:23.38 | ``Erik | nmg is just plain horrible |
| 04:23.57 | brlcad | because it guarantees topology |
| 04:24.13 | brlcad | what's the approach you're using do for that? |
| 04:24.27 | ``Erik | there's a trick in the latest approach that kinda surprises me, slicing all intersecting triangles before catagorizing |
| 04:25.16 | ``Erik | the original '86 paper has a whole chain of refinements, UnNBoolean seems to be the latest real example. I think the NMG stuff was originally based on that old '86 paper, then prematurely abstracted and implemented... poorly. |
| 04:25.31 | brlcad | there's only three or four methods I'm aware of that preserve topology |
| 04:26.10 | ``Erik | at the heart, this is still the same approach that nmg was supposed to be |
| 04:26.54 | ``Erik | lee admitted that he didn't know what he was doing and screwed it up, daytona noted that too much information was thrown away at the beginning of the pass, ... *shrug* we'll see |
| 04:27.00 | ``Erik | and I think my cat just farted at me |
| 04:27.28 | brlcad | nmg is the radial-edge method, there's winged-edge, half-edge, quad-edge, doubly linked faces, .. |
| 04:28.37 | ``Erik | most of those assume arbitrary polygons, i'm sticking to pure triangles |
| 04:29.06 | brlcad | I'm not defending nmg as much as saying it's hard to do it while still guaranteeing topology, preserving the manifold property |
| 04:29.36 | ``Erik | http://unbboolean.sourceforge.net/ |
| 04:30.07 | ``Erik | s/N/B/ |
| 04:31.08 | louipc | huh replace N with B? |
| 04:31.33 | ``Erik | yeh, louis, I said unnboolean, shoulda been unbboolean :) |
| 04:31.38 | brlcad | ``Erik: fwiw, the polyhedral paper they reference came *before* radial-edge |
| 04:31.56 | ``Erik | erm, the portugeuse 2008 paper? |
| 04:32.06 | louipc | ah cool |
| 04:32.34 | louipc | new competitions? |
| 04:32.46 | brlcad | by a couple years |
| 04:32.54 | brlcad | he states it: Constructive Solid Geometry for Polyhedral Objects, by D. H. Laidlaw, W. B. Trumbore, and J. F. Hughes |
| 04:33.19 | ``Erik | there's a chain of papers that go from 86 to 08 |
| 04:33.35 | brlcad | the portuguese paper he wrote :) |
| 04:33.38 | CIA-61 | BRL-CAD: 0399.144.90.118 07http://brlcad.org * r2908 10/wiki/User:Bhinesley: /* Log */ Yesterday, today, and plan for tomorrow. |
| 04:34.21 | brlcad | I have trumbore's paper around here somewhere |
| 04:34.35 | brlcad | it's decent, simple |
| 04:35.08 | ``Erik | *grouse* pine frequently crashes on brlcad.org, and mutt won't even run. need to migrate |
| 04:35.12 | brlcad | definitely wouldn't declare the approach better (or worse) |
| 04:35.59 | louipc | what os? |
| 04:36.00 | brlcad | iirc, the method also attempts to preserve manifold, but fails for some n-manifold cases that radial solved |
| 04:36.41 | brlcad | radial solved the problem, but with complexity .. the failure in nmg isn't the method but the implementation |
| 04:38.54 | ``Erik | there seems to be a lot of success with the KISS deviation from what nmg tried, shouldn't take too long to implement and would bump up a couple 9's on success rate for real geometry |
| 04:40.01 | ``Erik | I'll read up on radial edge, but the task as stated is pretty low investment |
| 04:40.48 | brlcad | done again from scratch, I'd probably be looking at winged edge or radial |
| 04:40.58 | brlcad | the bigger issue for CAD is the manifold property |
| 04:41.48 | brlcad | if something has three holes, it should preserve those three holes through conversion, not some other number .. or catastrophic for analysis, turn into a non-manifold |
| 04:42.19 | brlcad | the latter is the biggest problem and the hardest to guarantee without structure |
| 04:44.41 | ``Erik | I'd love to just use nurbs as the intermediary and focus effort now, but several people want visual tesselations to shove in ogl, that's what I'm working towards... not serious interrogation, just quick visualization |
| 04:45.24 | brlcad | except the very next thing they'll want is to dump that to something other than opengl and shoot rays at it, pretending it means something |
| 04:45.29 | brlcad | you know it as well as I |
| 04:47.32 | ``Erik | unfortunately, they'll try... so we call BoT's an approximation and push 'em towards nurbs |
| 04:48.08 | ``Erik | time for sleep, catch ya'll later :) |
| 04:48.16 | brlcad | hey, it's your seconds ticking by |
| 04:48.21 | brlcad | I just think it's a waste of time |
| 04:49.34 | brlcad | and I'll annongly keep saying it .. we should be focusing on robust solid modeling and geometry managemenet |
| 04:50.06 | brlcad | anything else is outside our domain, a distraction, wasted divergent resources and wasted effort |
| 04:50.59 | ``Erik | dude, I agree... I tried to pitch putting my funded time to nurbs... but was told I had to have improved tesselation by the end of the fy, it's on my objectives, need something for accomplishments in late sept... :/ process is screwing product yet again |
| 04:51.51 | louipc | I'd say UI is the most important at this point :P |
| 04:51.55 | brlcad | so give them g-egg ;) |
| 04:52.07 | brlcad | louipc: it is to the community at large |
| 04:52.31 | ``Erik | they were trying to put me on tweaking marching cubes, which is simply wrong for our kind of geometry, so I think I managed a small victory in changing that direction |
| 04:52.37 | brlcad | but not to the elephant contributor that pays to get what they think is most important :) |
| 04:52.53 | louipc | hehe |
| 04:53.07 | louipc | name the price ;) |
| 04:53.54 | ``Erik | after all the overhead (equipment, facilities, mgmt, support staff), I think it's in the neighborhood of 240000usd/year |
| 04:54.01 | brlcad | louipc: nominally, http://www.ohloh.net/p/brlcad/estimated_cost |
| 04:54.58 | brlcad | heh, that's probably missing a digit |
| 04:55.22 | louipc | waow |
| 04:55.59 | brlcad | or did you mean per year per person |
| 04:56.13 | ``Erik | disturbingly, I'm pretty sure that the failbomb upstairs has already cost more than all of BRL-CAD |
| 04:56.17 | ``Erik | I meant per person per year |
| 04:57.28 | ``Erik | so yeh, sleep. hasta la pasta |
| 04:57.43 | louipc | nite |
| 04:57.50 | brlcad | still thinks the easiest path forward is unit testing libbn then libnmg, evaluating robust up the call hierarchy |
| 04:57.56 | brlcad | cheers |
| 05:02.36 | CIA-61 | BRL-CAD: 03brlcad * r44774 10/brlcad/trunk/NEWS: cliff and erik developed a tcl/tk version of isst made available through the cmake build for 64-bit platforms. recommit for docs. |
| 05:02.59 | brlcad | starseeker: did you see the bug report about the bindings? |
| 05:03.25 | brlcad | said both mouse buttons now zoom out, probably related to "zoom out keybinding fixed on Linux/*BSD" made prior to release |
| 05:05.26 | CIA-61 | BRL-CAD: 03brlcad * r44775 10/brlcad/trunk/NEWS: |
| 05:05.26 | CIA-61 | BRL-CAD: cliff fixed the zoom-out mouse binding on linux/bsd that probably stopped |
| 05:05.26 | CIA-61 | BRL-CAD: working after I made a fix for Mac bindings. problem may need revisiting, |
| 05:05.26 | CIA-61 | BRL-CAD: though, becuase there's already a report that both left/right mouse now zoom out |
| 05:05.26 | CIA-61 | BRL-CAD: for some platform. |
| 05:08.45 | CIA-61 | BRL-CAD: 03brlcad * r44776 10/brlcad/trunk/BUGS: both mouse buttons zoom in now on some common platform |
| 05:10.25 | CIA-61 | BRL-CAD: 03brlcad * r44777 10/brlcad/trunk/NEWS: cliff improved the mged 'search' command so you can specify multiple paths now and it will report them appropriately. recommit for docs. |
| 05:13.46 | CIA-61 | BRL-CAD: 03brlcad * r44778 10/brlcad/trunk/NEWS: richard reportedly fixed a segment splitting bug that would affect all tessellation and polygonal conversions. recommit for docs. |
| 05:15.14 | CIA-61 | BRL-CAD: 03brlcad * r44779 10/brlcad/trunk/NEWS: richard fixed a crash that was occuring during facetization/conversion of large models. bad book keeping? recommit for docs. |
| 05:18.03 | CIA-61 | BRL-CAD: 03brlcad * r44780 10/brlcad/trunk/NEWS: bob fixed a bug introduced in asc2g where the new standard attribute logic was causing the color tables and other attribute data to not get converted properly. recommit for docs. |
| 05:20.41 | brlcad | starseeker: "improve path resolution logic for search paths" means what? |
| 05:22.01 | CIA-61 | BRL-CAD: 03brlcad * r44781 10/brlcad/trunk/NEWS: remove items that weren't user-visible. annotate is not yet 'published', attribute standardization is all under the hood, libtie was already announced in 7.18.4 |
| 05:23.18 | CIA-61 | BRL-CAD: 03brlcad * r44782 10/brlcad/trunk/NEWS: cliff added a -q quiet lookup option tot he ls command so that the lookup failure message can be suppressed (particularly important for scripting) |
| 05:28.00 | CIA-61 | BRL-CAD: 03brlcad * r44783 10/brlcad/trunk/NEWS: multiple names separated by commas for parsing, using past tense |
| 05:33.05 | CIA-61 | BRL-CAD: 03brlcad * r44784 10/brlcad/trunk/NEWS: |
| 05:33.05 | CIA-61 | BRL-CAD: cliff and I addressed numerous stability and robustness issues in the red |
| 05:33.05 | CIA-61 | BRL-CAD: command. now should handle standard attributes more consistently, be robust to |
| 05:33.05 | CIA-61 | BRL-CAD: bogus user input, be robust to empty/null input, and correctly preserve values |
| 05:33.06 | CIA-61 | BRL-CAD: creating a copy if the name is changed. |
| 05:40.01 | CIA-61 | BRL-CAD: 03brlcad * r44785 10/brlcad/trunk/NEWS: (log message trimmed) |
| 05:40.02 | CIA-61 | BRL-CAD: previously undocumented keith's modification because the change wasn't expected |
| 05:40.02 | CIA-61 | BRL-CAD: to be user-visible, but it turns out it was (for pixel accurate grazing |
| 05:40.02 | CIA-61 | BRL-CAD: selection), so credit us both for changing the spatial partition traversal |
| 05:40.02 | CIA-61 | BRL-CAD: ordering. keith originally fixed a traversal 'bug' where it was walking cut |
| 05:40.02 | CIA-61 | BRL-CAD: planes something like XYXYXYXYX (missing Z). he changed it to traverse |
| 05:40.03 | CIA-61 | BRL-CAD: YZXYZXYZX, but that caused a different cell to get selected first and |
| 05:44.07 | CIA-61 | BRL-CAD: 03brlcad * r44786 10/brlcad/trunk/NEWS: |
| 05:44.07 | CIA-61 | BRL-CAD: I added a LIBRT_BOT_MINTIE environment variable override that lets the user |
| 05:44.07 | CIA-61 | BRL-CAD: specify at what level libtie is used to evaluate a bot. lets you override |
| 05:44.07 | CIA-61 | BRL-CAD: during database loads affecting subsequent raytrace calls (better suited to |
| 05:44.07 | CIA-61 | BRL-CAD: repeat single-ray shots ala muves). |
| 05:46.00 | CIA-61 | BRL-CAD: 03brlcad * r44787 10/brlcad/trunk/NEWS: cliff changed the search output order to list shallow items prior to deeply nested items. |
| 05:48.20 | CIA-61 | BRL-CAD: 03brlcad * r44788 10/brlcad/trunk/NEWS: cliff extended search's power by adding support for '.' relative path search results where object lists are returned instead of full paths |
| 05:52.34 | CIA-61 | BRL-CAD: 03brlcad * r44789 10/brlcad/trunk/NEWS: |
| 05:52.35 | CIA-61 | BRL-CAD: I added a -f flag to the red command to force overwriting any existing |
| 05:52.35 | CIA-61 | BRL-CAD: combinations. if you run red, change the object name while editing, yet that |
| 05:52.35 | CIA-61 | BRL-CAD: new name already exists, it will abort. with the -f flag, it will overwrite. |
| 05:56.21 | CIA-61 | BRL-CAD: 03brlcad * r44790 10/brlcad/trunk/NEWS: technically, many of our items are verbless clauses as the action verb is implied (usually 'added'). |
| 05:58.43 | CIA-61 | BRL-CAD: 03brlcad * r44791 10/brlcad/trunk/src/tclscripts/ (CMakeLists.txt Makefile.am): add the new man_browser.tcl file to the dist |
| 06:15.46 | CIA-61 | BRL-CAD: 03brlcad * r44792 10/brlcad/trunk/NEWS: reword the intro description with details about the new cmake build and additional reasoning for the migration. |
| 07:30.11 | *** join/#brlcad Stattrav (~Stattrav@117.202.24.91) | |
| 07:30.11 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:08.49 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 08:08.49 | *** topic/#brlcad is 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.4 is posted! (20110412) | |
| 08:22.01 | *** join/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com) | |
| 09:17.57 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 09:17.57 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:37.38 | starseeker | brlcad: the search path thing is the whole "make sense out of .././.././" type paths |
| 11:38.13 | starseeker | there's another new zoom bug? I thought the only zoom bug was the one introduced by the mac keybinding change |
| 11:54.07 | starseeker | that report was 7.18.4 - I think thats the mac thing |
| 11:54.28 | starseeker | will check later |
| 12:03.50 | CIA-61 | BRL-CAD: 03davidloman * r44793 10/geomcore/trunk/: Add /Debug to svn:ignore (Build byproduct) |
| 12:06.30 | CIA-61 | BRL-CAD: 03davidloman * r44794 10/geomcore/trunk/src/interfaces/java/: Add /bin to svn:ignore (Build byproduct) |
| 12:45.19 | kunigami_ | hi, do I already have an SVN account for commit? If so, which is my password? |
| 12:49.49 | ``Erik | it's your sourceforge account |
| 12:50.15 | ``Erik | you should have uploaded ssh keys |
| 12:51.28 | kunigami_ | hmm how do I do that? |
| 12:53.36 | ``Erik | log into the web page at sourceforge, click account at the top right, click services, click edit ssh keys |
| 12:54.29 | ``Erik | https://sourceforge.net/apps/trac/sourceforge/wiki/Subversion is the help page for all of that |
| 12:55.02 | ``Erik | (might be able to do https with your sf password, but I think ssh is the recommended route) |
| 12:59.28 | kunigami_ | thank you! I seems that there may be a delay when updating the ssh-keys. I still don't have acess, so I'll wait a bit |
| 13:03.39 | brlcad | starseeker: I must have missed that the report was for 7.18.4 |
| 13:03.55 | brlcad | that would be more promising, I'll follow up |
| 13:04.23 | brlcad | kunigami_: your sf.net username/password should work just fine too |
| 13:05.17 | kunigami_ | I'm getting the following error: |
| 13:05.20 | kunigami_ | svn: Commit blocked by pre-commit hook (exit code 1) with output: |
| 13:06.01 | kunigami_ | <PROTECTED> |
| 13:06.32 | kunigami_ | brlcad/trunk/include/osl-renderer.h : svn:mime-type is not set |
| 13:07.09 | ``Erik | you have to do a propset, it should tell you exactly what to do in the error msg |
| 13:07.39 | kunigami_ | oops. you're right. sorry for that |
| 13:08.57 | ``Erik | http://brlcad.org/wiki/Cvs2svn has an example autoprop file to avoid that in the future |
| 13:13.26 | CIA-61 | BRL-CAD: 03Paydayway 07http://brlcad.org * r2909 10/wiki/Forex_Trading-_How_To_Understand_FOREX_Market_Sentiment: New page: Investors can trade almost any currency in the world. Investors, as individuals, countries, and corporations, may trade in the forex if they have enough financial capital to get started an... |
| 13:13.55 | CIA-61 | BRL-CAD: 03kunigami * r44795 10/brlcad/trunk/ (6 files in 2 dirs): This is my first commit. It adds a ols shader as well as a osl-renderer which by now just sets a color |
| 13:14.12 | ``Erik | w00t, grats |
| 13:14.27 | kunigami_ | yay! cool! |
| 13:25.39 | brlcad | woohoo |
| 13:27.10 | CIA-61 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/protect: protected "[[Forex Trading- How To Understand FOREX Market Sentiment]]": [edit=sysop:move=sysop] |
| 13:27.22 | CIA-61 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 13:27.22 | CIA-61 | BRL-CAD: deleted "[[Forex Trading- How To Understand FOREX Market Sentiment]]": content |
| 13:27.22 | CIA-61 | BRL-CAD: was: 'Investors can trade almost any currency in the world. Investors, as |
| 13:27.22 | CIA-61 | BRL-CAD: individuals, countries, and corporations, may trade in the forex if they have |
| 13:27.22 | CIA-61 | BRL-CAD: enou...' (and the only contributor was |
| 13:27.22 | CIA-61 | BRL-CAD: '[[Special:Contributions/Paydayway|Paydayway]]') |
| 13:27.45 | CIA-61 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Paydayway]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites |
| 13:47.39 | ``Erik | brlcad: is sf backend 1.5 now? |
| 13:48.04 | brlcad | kunigami_: http://brlcad.org/wiki/Mime-types |
| 13:48.27 | brlcad | ``Erik: I haven't migrated it, so unless they did for us, probably not |
| 13:48.39 | brlcad | could be something to work on today |
| 13:49.03 | CIA-61 | BRL-CAD: 03kunigami * r44796 10/brlcad/trunk/ (4 files in 2 dirs): Changed .c to .cpp and now I'm exporting the osl-renderer functions so that C code can call them |
| 13:54.25 | CIA-61 | BRL-CAD: 03erikgreenwald * r44797 10/brlcad/trunk/TODO: Remove the LIBRT_BOT_MINTIE task. Bump bottie crash and repo backend to next release. |
| 14:21.43 | brlcad | woot, another logo submission |
| 14:35.45 | CIA-61 | BRL-CAD: 03brlcad * r44798 10/brlcad/trunk/NEWS: |
| 14:35.45 | CIA-61 | BRL-CAD: in retrospect, my addition of the LIBRT_BOT_MINTIE variable was during prep, |
| 14:35.45 | CIA-61 | BRL-CAD: which erik replaced with override during database load, so credit him on the |
| 14:35.45 | CIA-61 | BRL-CAD: change that toggles tie BoT raytrace optimization on/off as an environment |
| 14:35.45 | CIA-61 | BRL-CAD: variable override. |
| 16:03.55 | CIA-61 | BRL-CAD: 03tbrowder2 * r44799 10/brlcad/trunk/NEWS: correct spelling |
| 17:02.52 | *** join/#brlcad Stattrav (~Stattrav@117.192.154.39) | |
| 17:02.52 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:21.43 | kunigami_ | a question regarding the macro BRLCAD_ADDLIB(libname srcs libs) |
| 17:22.25 | kunigami_ | when I pass libs as "abc.dylib;def.dylib" is does not call target_link_libraries |
| 17:23.07 | kunigami_ | but when I pass libs as "abc.dylib def.dylib", that is, replacing ";" for " " , it does call target_link_libraries |
| 17:23.55 | kunigami_ | that's strange because there's a replacement: STRING(REGEX REPLACE " " ";" libslist1 "${libs}") right on the beginning of the macro |
| 17:33.02 | CIA-61 | BRL-CAD: 03tbrowder2 * r44800 10/brlcad/trunk/doc/README.Linux: correct relative path typo for 32-bit configuration |
| 18:33.38 | brlcad | that wasn't a question :) |
| 18:36.27 | kunigami_ | hehe, let me complete :) Is that true or am I missing something? |
| 18:39.48 | brlcad | 'yes' |
| 18:40.08 | brlcad | those aren't mutually exclusive options ;) |
| 18:40.17 | brlcad | that said, sounds like a starseeker question |
| 18:52.00 | CIA-61 | BRL-CAD: 03kunigami * r44801 10/brlcad/trunk/ (5 files in 2 dirs): Moved osl-renderer.h from /include to /src/liboptical. there's no need to such headers to be public |
| 18:55.11 | brlcad | ~kunigami++ |
| 18:55.20 | brlcad | was going to comment on that yesterday |
| 18:56.11 | brlcad | you should also change the #include to be a relative path reference so it's "private" status is clear (e.g., #include "./osl-renderer.h") |
| 18:56.33 | kunigami_ | ok! |
| 18:56.57 | brlcad | kunigami_: have you been able to make a (brl-cad) shader do anything yet? |
| 18:58.15 | kunigami_ | I made the polka dot shader: http://kuniga.files.wordpress.com/2021/05/goblet1.png it's very ugly, but I think I got the idea |
| 19:30.12 | starseeker | ``Erik: were you refering to the kernel module loading process? (kldload and friends?) |
| 20:10.56 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 20:10.56 | *** topic/#brlcad is 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.4 is posted! (20110412) | |
| 20:11.32 | ``Erik | gets some popcorn |
| 20:13.04 | starseeker | brlcad: I guess it comes down to what we consider immediate needs to be |
| 20:13.15 | brlcad | if dynamic loading becomes desirable, that can be added *very easily* using any number of methods |
| 20:13.47 | brlcad | so what is the immediate need? what is dynamic loading fixing? |
| 20:13.54 | brlcad | (again, forget step-g for a minute) |
| 20:14.40 | starseeker | for me the immediate question is "can we design an API/library that can expand to handle arbitrary geometry files" |
| 20:15.47 | starseeker | step-g aside, it's quite clear there are an awesome number of object times we *potentially* will want/need to convert |
| 20:15.50 | brlcad | case in point .. you can design an *API* to handle arbitrary geometry files with or without dynamic |
| 20:16.07 | starseeker | s/times/types |
| 20:16.46 | starseeker | if the api design can be considered fully independent of the implementation, we can start with the api - I wasn't sure that was a practical reality |
| 20:16.48 | brlcad | right, and if it's going to be "arbitrary", you don't even really know what all the types are |
| 20:17.24 | starseeker | right. which is why flexible and general mechanisms for expanding what types the library can handle are so important |
| 20:17.38 | brlcad | right |
| 20:17.40 | brlcad | but mind you, the API is agnostic to the implementation |
| 20:18.10 | brlcad | the library *architecture* is not necessarily agnostic, as that's basically the implementation detail nuts and bolts |
| 20:18.34 | brlcad | but if you don't have the API nailed down yet, you don't really have a grasp on requirements to be designing architecture anyways |
| 20:18.51 | brlcad | whereas you can easily come up with an architecture that might mess up your API |
| 20:19.08 | brlcad | horse -> cart ;) |
| 20:20.09 | starseeker | was worried that the issue with Factory classes and C++ (which is by no means unique to step-g) meant that a good mechanism for generality might be problematic |
| 20:20.43 | starseeker | hence my interest in learning enough about the approaches to implementing that generality to be sure it wasn't a complete and total blind alley |
| 20:21.13 | brlcad | sure, but that's where a lil knowledge is leading to fear .. there are hundreds of other proof-positive implementations of factories and c++ that do this just fine |
| 20:21.33 | brlcad | and of dynamic loading and of scripted loading and of network loading .... etc |
| 20:23.00 | starseeker | brlcad: the existence of the Apache mod system I guess I can accept as proof that it can be done |
| 20:23.12 | brlcad | if you really want to make it type AWARE and type extensible, that will definitely affect the API |
| 20:23.31 | brlcad | just about every single commercial game loads data modularly ;) |
| 20:23.43 | starseeker | uh... don't we want it to be type aware? |
| 20:23.44 | brlcad | heck, even liboptical does it .. we just don't have any |
| 20:24.15 | brlcad | I haven't thought about an API too much yet (which is really what's needed first), but my inclination would be no |
| 20:24.26 | starseeker | O.o |
| 20:24.31 | brlcad | there are too many entity types, and there will always be some entity type you don't recognize |
| 20:24.44 | brlcad | basically akin to keeping it as a typeless system |
| 20:24.57 | starseeker | so we handle the ones we do recognize, and gracefully fail on the ones we don't |
| 20:25.02 | brlcad | interactors know what they can interact with (and they are types in themselves) |
| 20:25.29 | brlcad | each geometry format module can handle the ones they recognize |
| 20:25.50 | brlcad | we have some abstract way for registering annotated "data" |
| 20:27.00 | starseeker | I guess what I need to do is lay out my notion of an API |
| 20:27.06 | starseeker | maybe that'll clarify it for me |
| 20:27.08 | brlcad | yeah |
| 20:27.54 | brlcad | try to write the public header, or a main() that shows how the API might be used in simple terms |
| 20:28.18 | starseeker | at this point I don't agree that it should be typeless, so I guess I need to run head-first into why it should be |
| 20:28.26 | brlcad | there you answer questions like, do you allow iterating over individual objects |
| 20:28.28 | starseeker | nods - will do |
| 20:28.40 | brlcad | how to deal with hierarchy information |
| 20:28.45 | brlcad | what to do with metadata, etc |
| 20:29.00 | brlcad | "typeless" is being used very loosely here |
| 20:29.45 | brlcad | typeless in the language sense .. if it were C, there wouldn't be a sphere struct; if c++, there would not be a sphere class .. that's what I mean by typeless |
| 20:30.17 | starseeker | yeah... I'm not seeing that, but let me play with the API thing for a day or two and I'll see |
| 20:30.18 | brlcad | there'd be some bundle data saying "I'm a sphere and I have these parameters and these values" |
| 20:31.36 | brlcad | it's the difference between librt reading objects off disk and knowing "this is a sphere entity with some data" and having an actual rt_ell_internal object with sphere data in it |
| 20:32.05 | brlcad | the latter is going to be a veritable hell for a conversion library, and I'd argue probably unnecessary |
| 20:32.42 | starseeker | well, let me crunch on it |
| 20:32.48 | brlcad | it'd just make the library way more complex when you can perform the same work, turn that sph into a set of polygons and write out stl *without* an rt_ell_internal in memory |
| 20:33.00 | starseeker | how? |
| 20:33.26 | brlcad | just like how librt does it now |
| 20:34.04 | starseeker | uh... don't the tessellation routines need to know the details of the sphere? |
| 20:34.51 | brlcad | yep |
| 20:35.01 | brlcad | they don't necessarily need an rt_ell_internal though |
| 20:36.11 | brlcad | data-driven object-oriented design |
| 20:36.31 | brlcad | I think one of my game programming gems has a relevant article, I'll see if I can dig it up |
| 20:37.33 | starseeker | nods - that might be helpful |
| 20:37.47 | starseeker | I'll try and cook up an API |
| 20:40.35 | CIA-61 | BRL-CAD: 03erikgreenwald * r44805 10/brlcad/trunk/ (6 files in 4 dirs): add/use dlfcn wrapper |
| 20:43.57 | CIA-61 | BRL-CAD: 03erikgreenwald * r44806 10/brlcad/trunk/src/liboptical/material.c: remove the HAVE_DLOPEN stuff, since that's handle in bu now |
| 20:45.36 | CIA-61 | BRL-CAD: 03erikgreenwald * r44807 10/brlcad/trunk/src/liboptical/sh_stack.c: more HAVE_DLOPEN removal |
| 20:48.10 | brlcad | starseeker: if you haven't yet, I'd suggest looking briefly into both liboptical and librt, how they deal with extensible types |
| 20:49.02 | brlcad | not what I'd suggest going with for gcv, but they are about as simple as it gets, scalable to hundreds of entities, and should be understood (how their types relate to the *API*) |
| 20:59.36 | CIA-61 | BRL-CAD: 03erikgreenwald * r44808 10/brlcad/trunk/src/libbu/dlfcn.c: take a whack at porting these functions to windows |
| 21:07.32 | CIA-61 | BRL-CAD: 03erikgreenwald * r44809 10/brlcad/trunk/include/bu.h: add dlfcn.h for RTLD_* |
| 21:26.21 | starseeker | hah, cool: http://deviceguru.com/worlds-first-open-source-flashlight/ |
| 21:27.40 | kunigami_ | I'm getting compilation error for material.c -- âRTLD_NOWâ undeclared. |
| 21:28.08 | kunigami_ | I'll check later, but that could have been introduced by r44806 |
| 21:28.18 | kunigami_ | I'm off by today |
| 21:28.23 | ``Erik | which os? |
| 21:28.28 | kunigami_ | mac os |
| 21:28.53 | ``Erik | that'd be the one fixed in 44809 :) |
| 21:29.54 | kunigami_ | oops sorry. I did update from src/ dir |
| 21:31.19 | *** join/#brlcad kunigami_ (~kunigami@loco-gw.ic.unicamp.br) | |
| 21:52.11 | *** join/#brlcad crazy_imp (~mj@a89-182-166-16.net-htp.de) | |
| 21:52.46 | CIA-61 | BRL-CAD: 03erikgreenwald * r44810 10/brlcad/trunk/src/ (10 files in 5 dirs): Apple includes stdbool.h in dlfcn.h, so change our various typedefs of bool to their actual type. |
| 22:47.11 | *** join/#brlcad DarkCalf (DC@173.231.40.98) | |
| 23:01.17 | ``Erik | aw man, I can't compete in the logo contest? shucks |
| 23:12.13 | CIA-61 | BRL-CAD: 03erikgreenwald * r44811 10/brlcad/trunk/AUTHORS: Keith and Richard probably qualify as developers instead of contributors at this point. |
| 23:30.52 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
