| 03:17.42 | *** join/#brlcad ejno_ (~ejno@unaffiliated/kazaik) | |
| 03:46.32 | Notify | 03BRL-CAD:brlcad * 59803 brlcad/trunk/NEWS: credit cezar with a number of the memory leaks he fixed in r54118 as part of fixing clang static analysis defects. |
| 04:01.59 | starseeker | prods Notify |
| 04:02.11 | Notify | 03BRL-CAD:starseeker * 59804 (brlcad/trunk/include/raytrace.h brlcad/trunk/src/conv/step/g-step/Trees.cpp and 4 others): And this is why the search API was still flagged as WIP. Consolidate plan testing, flat vs. tree-aware searching, single dp vs dp array inputs, and full_path vs. unique dp return types into a single db_search function that accepts flags to control its behavior and a db_free_search_tbl function |
| 04:02.14 | Notify | that can handle either result type. Code reduction and simplification overall - barring some major missing considerations, this is most likely the final form of the C search API. Needs a fair bit of testing, as the change was a bit invasive - particularly when it comes to things like hidden objects. |
| 04:02.21 | starseeker | ah, there we go |
| 04:02.43 | starseeker | yawns - time to sleep on it, but that feels like it may well be the right solution |
| 04:35.49 | *** join/#brlcad KimK (~Kim__@ip24-255-223-153.ks.ks.cox.net) | |
| 04:36.45 | *** join/#brlcad _ff (29cac42b@gateway/web/freenode/ip.41.202.196.43) | |
| 04:38.16 | _ff | hello any one there?? |
| 04:39.23 | _ff | hey guys i really need help |
| 04:40.54 | brlcad | hello _ff |
| 04:40.57 | brlcad | ~ask |
| 04:40.57 | infobot | Questions in the channel should be specific, informative, complete, concise, and on-topic. Don't ask if you can ask a question first. Don't ask if a person is there; just ask what you intended to ask them. Better questions more frequently yield better answers. We are all here voluntarily or against our will. |
| 04:42.13 | _ff | thanks for that! |
| 04:42.35 | brlcad | sure |
| 04:43.45 | _ff | i am a newbie in programming and with the skills i've aquired in C i wish to work on a project on brlcad! looking at the ideas proposal i fell on the adding the exec function to the search! |
| 04:44.22 | _ff | though i have no idea on how to start the project i wish to have some materials wish can help me start the project |
| 04:54.16 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) | |
| 05:04.24 | *** join/#brlcad _ff (29cac42b@gateway/web/freenode/ip.41.202.196.43) | |
| 05:07.20 | _ff | --brlcad-- any proposal ?? |
| 05:16.36 | *** join/#brlcad _ff (29cac42b@gateway/web/freenode/ip.41.202.196.43) | |
| 05:56.27 | *** join/#brlcad FOSScookie (~brian@107-200-34-31.lightspeed.tulsok.sbcglobal.net) | |
| 06:13.28 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) | |
| 06:31.15 | *** join/#brlcad luca79 (~luca@net-37-117-72-79.cust.vodafonedsl.it) | |
| 06:44.45 | *** join/#brlcad Anaphaxeton (~george@unaffiliated/anaphaxeton) | |
| 08:46.59 | *** join/#brlcad luca79 (~luca@net-37-117-72-79.cust.vodafonedsl.it) | |
| 08:56.06 | *** join/#brlcad merzo (~merzo@user-94-45-58-138-1.skif.com.ua) | |
| 09:18.09 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 09:36.40 | *** join/#brlcad inspired (c318dc10@gateway/web/freenode/ip.195.24.220.16) | |
| 09:38.30 | inspired | hello! just heard about brl-cad and i wich to know where and how to download the software to install on my pc. operating system-linux |
| 10:12.33 | *** join/#brlcad caen23 (~caen23@92.81.213.198) | |
| 12:04.40 | *** join/#brlcad luca79 (~luca@net-37-117-72-79.cust.vodafonedsl.it) | |
| 12:48.20 | Notify | 03BRL-CAD:tbrowder2 * 59805 (brlcad/trunk/include/bu.h brlcad/trunk/src/libbu/bitv.c): change two functions to return success/failure; change decls accordingly and add explanation in bu.h |
| 12:53.25 | *** join/#brlcad caleb (c318dc10@gateway/web/freenode/ip.195.24.220.16) | |
| 13:07.08 | *** join/#brlcad caen23 (~caen23@92.81.213.198) | |
| 13:09.54 | *** join/#brlcad KimK (~Kim__@ip24-255-223-153.ks.ks.cox.net) | |
| 13:40.34 | mpictor | Anyone have experience with operator= behaving differently on windows than linux? We removed a pure virtual operator= in STEPcode due to msvc linker errors, and it triggered a regression on Linux. |
| 13:40.56 | mpictor | https://github.com/stepcode/stepcode/issues/284 |
| 13:44.04 | *** join/#brlcad gaganjyot (~gagan@124.253.230.99) | |
| 13:50.37 | gaganjyot | hello there, |
| 13:51.02 | gaganjyot | is librecad participating under BRL-CAD this year for GSoC ? |
| 14:00.33 | *** join/#brlcad jasleen (~chatzilla@117.253.230.220) | |
| 14:13.08 | Notify | 03BRL-CAD:starseeker * 59806 brlcad/trunk/NEWS: Keith implemented improvements in handling NURBS surfaces where edges and trims 'wrap around' from one side of the UV domain to the other. |
| 14:20.12 | brlcad | gaganjyot: that is the intention, though still some details to sort out |
| 14:27.46 | Notify | 03BRL-CAD:starseeker * 59807 brlcad/trunk/src/conv/step/g-ap214/Add_Tree.cpp: Update search calls in g-ap214 |
| 14:30.42 | gaganjyot | brlcad: thanks :) |
| 14:32.25 | *** join/#brlcad gaganjyot (~gagan@124.253.230.99) | |
| 14:33.21 | Notify | 03BRL-CAD:starseeker * 59808 (brlcad/trunk/include/raytrace.h brlcad/trunk/src/conv/step/g-ap214/Add_Tree.cpp brlcad/trunk/src/libged/comb.c): Add a more meaningful label for the default or 0 flag to allow devs to make it more explicit what type of search is being performed. |
| 14:38.12 | gaganjyot | brlcad: is there any ideas page for gsoc 14 ? |
| 15:12.21 | Notify | 03BRL-CAD:carlmoore * 59809 (brlcad/trunk/src/libbn/vert_tree.c brlcad/trunk/src/librt/search.c): fix spellings, and adjust (not change) a comment so it more closely resembles a comment which I didn't change |
| 15:18.35 | *** join/#brlcad gaganjyot (~gagan@124.253.230.99) | |
| 15:43.30 | starseeker | mpictor: sorry, that one is beyond my experience :-/ |
| 16:06.09 | ``Erik | I have recollection of game developers bitching that linux "just didn't work right" with c++ overloads, a long time ago... my assessment at the time was that windows sucked and windows coders were self-absorbed idiots... these days, I'd recommend a microtest and would assume the spec is ... imperfect and ambiguous? |
| 16:12.24 | *** join/#brlcad KimK (~Kim__@ip24-255-223-153.ks.ks.cox.net) | |
| 16:23.35 | *** join/#brlcad gaganjyot (~gagan@124.253.230.99) | |
| 16:27.37 | Notify | 03BRL-CAD:starseeker * 59810 brlcad/trunk/include/raytrace.h: Actually use rt/defines.h - removes about 10 lines of duplication |
| 16:32.33 | Notify | 03BRL-CAD:starseeker * 59811 brlcad/trunk/include/dm.h: Set up a similar subdir and header file for dm |
| 16:50.03 | Notify | 03BRL-CAD:starseeker * 59812 (brlcad/trunk/include/CMakeLists.txt brlcad/trunk/src/libdm/color.c and 24 others): Move the dm-*.h headers into the dm subdirectory. |
| 17:05.30 | *** join/#brlcad gaganjyot (~gagan@124.253.230.99) | |
| 17:08.42 | Notify | 03BRL-CAD:starseeker * 59813 (brlcad/trunk/include/CMakeLists.txt brlcad/trunk/include/raytrace.h brlcad/trunk/include/rt/defines.h): Break search header definitions out into rt/search.h |
| 17:14.32 | starseeker | O.O http://www.opencascade.org/getocc/license/ |
| 17:14.48 | starseeker | Holy cow - OpenCascade went LGPL 2.1! |
| 17:17.32 | starseeker | Back in December |
| 17:17.53 | starseeker | Version 6.7.0 (not retro-active to earlier versions) |
| 17:19.59 | starseeker | wonders how he missed that... |
| 17:25.12 | gaganjyot | starseeker: LGPL v2.1 with one condition |
| 18:33.19 | *** join/#brlcad sod (737c2942@gateway/web/freenode/ip.115.124.41.66) | |
| 18:34.43 | sod | hi all |
| 18:34.43 | gcibot | sod, hey! |
| 18:35.09 | sod | i'm new here in brlcad |
| 18:35.23 | sod | and need some help to start |
| 18:35.55 | sod | hi all |
| 18:35.56 | gcibot | sod, hey! |
| 19:20.47 | brlcad | starseeker: yep, mid-dec |
| 19:22.14 | brlcad | shame that wasn't 10 years ago or it might have been an interesting consideration for incorporation |
| 19:22.26 | brlcad | though bsd/mit would have been better |
| 19:27.48 | brlcad | it does mean we can probably "look" at their code now without too much concern, but I'd stil be disinclined to directly incorporate any of their code |
| 19:28.14 | starseeker | nods - was thinking more along the lines of using features they have that we don't have implemented yet |
| 19:28.16 | brlcad | I'd really like to see us move to a more flexible and permissive license |
| 19:28.33 | starseeker | sort of a "plug in opencascade until we get our version working" sort of approach |
| 19:29.19 | brlcad | how would that'd be accomplished without incorporating their code, using a system version or something? |
| 19:29.25 | starseeker | yep |
| 19:29.37 | starseeker | "if opencascade found, enable goodies" |
| 19:29.39 | brlcad | would be a digression from src/other |
| 19:29.52 | brlcad | sort of like X11, but .. not really |
| 19:30.01 | starseeker | like bullet and adaptagrams |
| 19:30.10 | brlcad | yeah, better analogy |
| 19:30.26 | brlcad | what feature would be useful that way? |
| 19:30.51 | brlcad | step conversion would have been the main thing that came to my mind, and I think our support is probably approaching better if not there already |
| 19:31.25 | starseeker | first thing that came to my mind was drawing support, i.e. http://freecadweb.org/wiki/index.php?title=File:FreeCAD011.png |
| 19:31.59 | starseeker | they also have a constraint solving 2D sketcher |
| 19:32.30 | brlcad | ironically, I think that was one of the things they suggested for a possible gsoc project because it wasn't very good (recollection is vague, could be wrong) |
| 19:32.42 | *** join/#brlcad cain_ (c318dc10@gateway/web/freenode/ip.195.24.220.16) | |
| 19:35.02 | starseeker | brlcad: we could try hooking into their boolean support... |
| 19:36.37 | brlcad | dunno, those both seem like a stretch to me ... we'd end up integrating and it'd either suck (in which case nobody would/should use it and it would have been a waste of time) ... OR ... it works great and we've painted ourselves into a dependency corner for the foreseeable future |
| 19:37.50 | brlcad | IF it worked great, that'd be even LESS incentive to invest development time and effort, meaning it simply wouldn't happen |
| 19:38.53 | brlcad | that's very much a lose-lose situation unless we're willing to adopt OC as a dependency (and that seems like a very bad idea to me, but I'd want to do a full cost/benefit analysis) |
| 19:39.08 | starseeker | it may be worth waiting a bit to see what happens, but this license change is potentially a seismic event for the open source CAD world... |
| 19:39.29 | starseeker | the old license on opencascade was a blocker to an effective community forming |
| 19:39.48 | starseeker | without that hangup, things could get interesting |
| 19:40.15 | brlcad | the company is still not encouraging or supportive to that happening |
| 19:41.02 | brlcad | this was almost entirely a prlonged delayed response to the problems from those codes (10 years ago!) trying to integrate into debian and other repos, getting declared non-free |
| 19:41.29 | brlcad | those that wanted to use it already are |
| 19:41.38 | brlcad | that community is freecad |
| 19:41.52 | starseeker | the company may not be able to build a community around the code, but FreeCAD is another story, especially in partnership with the OCE crowd |
| 19:41.53 | brlcad | (there's a couple others in fairness, but they don't interoperate) |
| 19:42.47 | starseeker | isn't proposing to hop on the bandwagon and abandon our efforts - from some of the comments I've seen, the opencascade code is... difficult to work with |
| 19:43.12 | brlcad | that's probably an understatement |
| 19:43.14 | brlcad | I've been talking with several in their community over the past couple weeks |
| 19:43.53 | brlcad | mentioned my longer term plans to produce a viable stand-alone open source kernel that would replace the likes of acis, granite, parasolid, opencascade, etc |
| 19:44.03 | brlcad | several were actually rather excited by that notion |
| 19:44.09 | starseeker | cool :-) |
| 19:45.05 | brlcad | some of their gsoc hesitation was because OC was simply too complicated for someone to get into in that short amount of time (a summer) |
| 19:46.00 | starseeker | actually isn't opposed to the notion of "proper" open source competition between BRL-CAD and FreeCAD/opencascade - from a broader perspective, not being totally dependent on one solution is almost invariably a good thing |
| 19:46.29 | brlcad | I don't mind competition at all, I think it's a good thing that we do things in somewhat different ways |
| 19:46.37 | brlcad | we address different needs, have different communities |
| 19:46.53 | brlcad | we can still bridge various collaboration points, like STEPcode or ray tracing |
| 19:47.41 | brlcad | one of their devs noted that our development activity is 10-20 times theirs |
| 19:48.05 | starseeker | will be interesting in the longer term to see if BRL-CAD can be slotted in "under" their GUI, which is undeniably snazzier than even Archer (much less MGED) |
| 19:48.34 | brlcad | we're still pretty much the only de-facto open source CAD in production use that I know of, so having them help expand open source CAD activity is a good thing |
| 19:49.12 | starseeker | last time I checked they were getting something like 3 times our download rate on sf |
| 19:49.44 | brlcad | we're not very good at pumping out releases, our interface and usability suck |
| 19:49.56 | brlcad | using OC doesn't do ANYTHING for that |
| 19:50.12 | brlcad | so yeah, busy work |
| 19:50.19 | starseeker | er, correction - 6 times our download rate |
| 19:50.33 | brlcad | what are they at per month? |
| 19:50.45 | brlcad | we were around 10k/month when we had consistent releases |
| 19:50.48 | starseeker | let's see... 13,731 per week... |
| 19:51.10 | brlcad | good to know |
| 19:51.35 | starseeker | we're at 2069 per week right now according to the "3d modeling" listing |
| 19:51.50 | brlcad | so we've gone down a bit, not too suprising given our lack of releases |
| 19:52.01 | brlcad | every time we release, that number jumps way up |
| 19:52.07 | starseeker | nods |
| 19:52.21 | starseeker | I need to quit fiddling with the search API and get back to learning Qt :-P |
| 19:53.25 | brlcad | we should all quit what we're doing to work on interface, but "that'd be bad" for other reasons... ;) |
| 19:53.43 | brlcad | I think we'll have a ton of momentum come this summer |
| 19:53.58 | brlcad | enough infrastructure finally in place to modularize the front-end development |
| 19:54.37 | starseeker | brlcad: is moving the dm headers to the subdir a problem? I figured it came under the heading of minimally impacting... |
| 19:54.37 | brlcad | we really need boolean evaluation (what nick's working on) and clean import/export (what you and keith are doing) |
| 19:54.47 | brlcad | nope, looked good to me |
| 19:55.07 | starseeker | should probably remove the dm- prefixes, they're pretty redundant now |
| 19:55.17 | brlcad | those dm-*.h are actually "private" and shouldn't be in include but they are exposed in a few places right now |
| 19:55.31 | starseeker | mged, tclcad, and a couple utils iirc |
| 19:55.35 | brlcad | don't, several of those will conflict with system headers |
| 19:55.41 | starseeker | blegh |
| 19:55.42 | starseeker | ok |
| 19:55.49 | brlcad | annoying, I know |
| 19:56.24 | brlcad | but yeah, I think our first step is to simply categorize all the include/ headers into subdirs |
| 19:56.57 | brlcad | once we do that, we can focus on the build system and any header file breakups needed, then removing the private ones |
| 19:57.50 | brlcad | so we'll end up with nothing except common.h, bio.h, bin.h, and conf/ in the include directory (plus one dir per lib) |
| 19:58.37 | starseeker | ah, so "raytrace.h" would be inside rt/ ? Or were you thinking to modularize what is included at a finer level? |
| 20:00.58 | starseeker | i.e. no "raytrace.h" at all, just including the necessary pieces? |
| 20:01.45 | brlcad | both |
| 20:02.08 | brlcad | there'd all live inside a subdir |
| 20:02.26 | brlcad | some like raytrace.h would simply #include all of the sub-modules that form the ray tracing API |
| 20:02.36 | starseeker | nods |
| 20:02.42 | starseeker | make sense |
| 20:02.44 | brlcad | lib/lib.h would include everything for lib |
| 20:02.58 | starseeker | so... raytrace.h -> rt.h? |
| 20:03.11 | *** join/#brlcad witness___ (uid10044@gateway/web/irccloud.com/x-pynwrjlokdcycoyt) | |
| 20:03.13 | brlcad | "maybe" .. that's probably the most complicated header of all |
| 20:03.50 | starseeker | was/is contemplating splitting more pieces out of it a.l.a. rt/search.h |
| 20:03.57 | brlcad | there's 943 public functions in raytrace.h now |
| 20:04.04 | starseeker | just for readability it helps |
| 20:04.10 | brlcad | right, that's the idea |
| 20:04.13 | starseeker | wines |
| 20:04.16 | starseeker | winces |
| 20:04.18 | starseeker | grr |
| 20:04.30 | brlcad | so imagine separating everything out that groups into some set of sub-functionality |
| 20:04.56 | starseeker | I take it defines.h is intended to hold all the #define type things, not just the DLL foo? |
| 20:05.07 | brlcad | basically the lib_group_function() would imply there's a lib/lib.h you could include or a lib/group.h you could include |
| 20:05.22 | brlcad | no no |
| 20:05.29 | brlcad | modular per group |
| 20:05.44 | starseeker | so defines.h was just a stub? |
| 20:06.03 | brlcad | defines.h is global to the lib |
| 20:06.20 | brlcad | it ideally would just live in that lib/lib.h file, but every header will need it |
| 20:06.28 | brlcad | and every header cannot include lib/lib.h ... cyclic dep |
| 20:06.39 | starseeker | ah, so lib/group.h would include lib/defines.h |
| 20:06.42 | brlcad | so the common/global aspects get their own header necessarily |
| 20:06.46 | brlcad | right |
| 20:06.56 | brlcad | every header would include exactly and only what it needs |
| 20:07.09 | brlcad | should actually speed up compilation substantially |
| 20:07.12 | starseeker | sounds good |
| 20:07.58 | starseeker | brlcad: sorry if I'm "jumping the gun" on that but after one too many times digging db_search out of raytrace.h I figured I might as well go for it... |
| 20:09.46 | brlcad | no jumping the gun, it's all good |
| 20:09.51 | brlcad | as you can tell, I'd already started it |
| 20:09.56 | brlcad | long term low priority |
| 20:10.07 | brlcad | I peck at it when I can think clearly |
| 20:10.12 | brlcad | which isn't very often |
| 20:10.20 | starseeker | heh |
| 20:10.37 | brlcad | just have to make sure it's cleaner and not a work-in-progress mess, complete every step along the way |
| 20:11.22 | starseeker | every time I have to think long and hard about an API like search, I always think about doxygen documtation... which leads to headers |
| 20:11.32 | *** join/#brlcad zxq9 (~ceverett@FL9-125-199-207-150.okn.mesh.ad.jp) | |
| 20:11.38 | brlcad | there is one issue of managing the includes, whether we want to update all caller codes to lib/whatever.h (particularly third-party codes) or whether we'll rely on brlcad-config or pkg_config to set per-lib include dirs |
| 20:12.22 | brlcad | won't matter so long as the "lib.h" header is the LAST to move (staying in include/ for now) |
| 20:12.26 | starseeker | to be honest, that was the primary reason I figured raytrace.h would continue to live in include and the sub-headers would be in rt/ |
| 20:12.45 | starseeker | er, right |
| 20:12.51 | brlcad | that makes the most sense for now |
| 20:13.32 | brlcad | just thinking once EVERYTHING is broken out into lib/module.h and other headers, those top-levels will be inconsistent with some established conventions |
| 20:13.50 | brlcad | but yeah, breakouts first whenever |
| 20:14.53 | starseeker | sweet. When I get a little time I'll try to make sure the doxygen stuff is handling it correctly |
| 20:16.30 | *** join/#brlcad zxq9 (~ceverett@FL9-125-199-207-150.okn.mesh.ad.jp) | |
| 20:21.33 | *** join/#brlcad zxq9 (~ceverett@FL9-125-199-207-150.okn.mesh.ad.jp) | |
| 20:26.22 | *** join/#brlcad zxq9 (~ceverett@FL9-125-199-207-150.okn.mesh.ad.jp) | |
| 20:34.21 | starseeker | jots a note to himself to prod the fossil devs and see if libfossil (http://fossil.wanderinghorse.net/repos/libfossil) is still active |
| 20:35.37 | starseeker | depending on how it's done, that has the potential to be an almost ideal backend for libgvm |
| 20:36.44 | Notify | 03BRL-CAD:tbrowder2 * 59814 (brlcad/trunk/include/bu.h brlcad/trunk/src/libbu/tests/CMakeLists.txt and 2 others): add new function 'bu_vls_substr'; add tests for it |
| 20:37.52 | starseeker | brlcad: what do you think about moving libgvm from geomcore into BRL-CAD proper? |
| 20:40.04 | brlcad | what's in the lib? |
| 20:40.51 | starseeker | mostly the incantations to split a .g file up into a subversion repo and put it back together again |
| 20:41.04 | brlcad | ahh |
| 20:41.07 | *** join/#brlcad luca79 (~luca@net-37-117-72-79.cust.vodafonedsl.it) | |
| 20:41.25 | starseeker | header (gvm.h) is generic (credit to you for instisting on that) |
| 20:41.47 | brlcad | C API? |
| 20:41.50 | starseeker | yep |
| 20:42.54 | starseeker | brlcad: http://sourceforge.net/p/brlcad/code/HEAD/tree/geomcore/trunk/src/libgvm/ |
| 20:52.53 | brlcad | suppose it's be alright, but not sure I'd see that being anything but a useful distraction right now |
| 20:53.27 | brlcad | having our progs call that lib directly wasn't ever in the tea leaves |
| 20:54.08 | brlcad | even mged is supposed to be going through the GS so we can properly manage the notion of a checkout |
| 20:54.38 | brlcad | if no tool or lib in our checkout calls it, becomes unusal to have there |
| 20:54.41 | starseeker | OK, just a thought |
| 20:54.53 | brlcad | sure, it's an interesting thought |
| 20:55.51 | brlcad | I think I'd just expect some way it to get put to use and I can't think of one right this second except maybe some low-level command-line interface |
| 20:56.29 | starseeker | nods - yeah, I think I've got some basic commands for working with .g files and that's about it |
| 20:56.35 | starseeker | plus needs svn libs |
| 20:57.13 | brlcad | yeah |
| 20:57.34 | starseeker | libfossil would be *awesome* but it doesn't look like it has much momentum |
| 20:58.43 | brlcad | is having trouble getting his head around the 500 public functions in the nmg API |
| 20:58.57 | starseeker | isn't surprised |
| 20:59.05 | brlcad | at a glance, more than half of those simply shouldn't be public |
| 20:59.28 | brlcad | and it's just lazy declaration |
| 20:59.39 | brlcad | wonder how many are actually directly used |
| 20:59.48 | starseeker | that sounds like a rather massive addition to the CHANGES deprecation list |
| 20:59.52 | brlcad | how big/complicated the API really is |
| 21:00.37 | brlcad | afaik, nmg was never "published", documented in a manner that others could use it |
| 21:01.02 | starseeker | given my druthers, I'd probably stub out a "clean" API for NMG as the first step in digging it out of librt, then work from there... |
| 21:01.19 | brlcad | easy enough to leave the decls public for a deprecation phase, but not sure it'd technically be required |
| 21:07.27 | mpictor | reads discussion from last few hours |
| 21:08.04 | mpictor | starseeker: as of a couple years ago, OCC's boolean operations were slow and had a lot of bugs |
| 21:08.49 | starseeker | mpictor: ah, good to know |
| 21:08.52 | mpictor | has fond memories of solids with negative volume and/or invisible faces |
| 21:08.57 | starseeker | heh |
| 21:09.27 | mpictor | I think I have a whitepaper from where SALOME wrote their own boolean ops with more modern algos |
| 21:11.02 | starseeker | this one? http://docs.salome-platform.org/salome_7_3_0/gui/GEOM/SALOME_BOA_PA.pdf |
| 21:11.53 | mpictor | heh, I was about to mail you v 6.3.0 of that :) |
| 21:12.35 | starseeker | <spock voice>fascinating</spock voice> |
| 21:14.07 | mpictor | I remember the OCC sources being in french - at least the old parts. the comments were too technical for google translate to work on, as well :/ |
| 21:16.22 | starseeker | they've put quite a lot of work into documenting SALOME, based on that example |
| 21:16.55 | kanzure | hello |
| 21:17.09 | starseeker | kanzure: howdy |
| 21:17.21 | kanzure | i think OCC's boolean operations still have bugs |
| 21:17.33 | kanzure | i wasn't aware that SALOME has a separate implementation |
| 21:17.38 | kanzure | finding code inside of OCC is impossible enough as it is |
| 21:17.48 | mpictor | heh no kidding :) |
| 21:17.48 | kanzure | some parts are in french, others in russian, and some more in english |
| 21:17.59 | kanzure | it is entirely hopeless and should be abandoned |
| 21:21.46 | starseeker | kanzure: so you don't think the OCE team is inclined to try and save it? |
| 21:23.38 | kanzure | i have spent a lot of time trying to work through OCC's source code to see how i could start to clean things up |
| 21:23.46 | kanzure | and honestly i wasn't able to make up any actionable plan |
| 21:24.06 | kanzure | like, in theory, there are these 100+ modules that can be reused, but they seem to call each other a lot, and i'm never really sure where the actual boolean operations are really truly implemented.. |
| 21:24.33 | kanzure | i think that the OCC team upstream might not have the talent necessary to fix their situation |
| 21:24.58 | kanzure | large refactor initiatives from the OCE people would be interesting.. but brlcad is way cleaner :) |
| 21:26.24 | mpictor | kanzure: do they still use WOK to generate container classes, or have they moved to templates? |
| 21:27.22 | kanzure | i haven't looked in the past ~2 years so i would guess WOK |
| 21:27.44 | mpictor | bleh |
| 21:28.40 | kanzure | oh wait, hi, nice to see you around :) |
| 21:28.45 | kanzure | i know who you are. heh. |
| 21:29.35 | mpictor | you're brian bishop, right? |
| 21:30.54 | kanzure | hi yes |
| 21:33.07 | mpictor | don't think I've talked to you since I used to frequent #cam |
| 21:33.17 | starseeker | kanzure: it would be interesting if the FreeCAD/OCE folks could look at BRL-CAD and itemize what is missing from their point of view to make BRL-CAD viable for their applications |
| 21:34.05 | starseeker | we know the obvious ones (booleans, shaded displays, 2D drawings/dimensioning) |
| 21:34.13 | kanzure | booleans? |
| 21:34.33 | starseeker | subracting one Brep from another to form a new shape |
| 21:34.45 | starseeker | i.e. use a cylindar to punch holes in a plate |
| 21:36.34 | kanzure | oh, i wasn't aware that this was missing at the moment. |
| 21:37.07 | starseeker | we're working on it - one of last years GSoC projects did quite a bit of work on that topic |
| 21:37.51 | starseeker | http://brlcad.org/wiki/User:Phoenix/GSoc2013/Reports |
| 21:38.09 | kanzure | my biggest suggestion would be something about decoupling releases of individual components/sub libraries or something, and especially separating the gui-related releases, but i dunno if the freecad person cares about that |
| 21:38.17 | kanzure | yeah, i remember User:Phoenix |
| 21:39.00 | starseeker | kanzure: so separating a "libbrlcad" backend from the GUI front-ends? |
| 21:39.40 | kanzure | that sounds nice |
| 21:39.44 | kanzure | have you looked at python-brlcad? |
| 21:39.58 | starseeker | unfortunately I haven't had time recently |
| 21:39.59 | kanzure | https://github.com/kanzure/python-brlcad |
| 21:40.15 | mpictor | starseeker: did you mention a constraints solver as something you don't have? https://code.google.com/p/sketchsolve/ (BSD) was used in the now-defunct heekscad |
| 21:40.41 | starseeker | nods - I looked at that a bit, but apparently FreeCAD did too and they wound up implementing their own |
| 21:41.24 | starseeker | is curious as to whether gecode could be used as a foundation on which to define and solve such constraints - they seem to do well in the open source constraint solving arena |
| 21:41.47 | starseeker | not to mention a nice license and good documentation |
| 21:42.36 | mpictor | there's also psketcher, which has fewer constraints but includes 2d sketching https://code.google.com/p/psketcher/ |
| 21:42.44 | mpictor | had not heard of gecode |
| 21:42.58 | starseeker | mpictor: unfortunately, psketcher is GPL |
| 21:43.07 | mpictor | oh yea :/ |
| 21:43.15 | starseeker | http://www.gecode.org/doc-latest/reference/classCartesianHeart.html |
| 21:45.34 | starseeker | that example is promising when you consider our problem domain :-) |
| 21:46.56 | starseeker | main question I have is how to approach a runtime specification of and rebuilding of the constraints - from what I can tell, we basically will need to construct GECODE models "on the fly", destroying them and creating new ones when the geometry changes (not parameters changing per say, but new geometry and/or constraints being added or removed) |
| 21:48.08 | mpictor | oh, so you'd have their model, as well as one of your own? |
| 21:49.07 | starseeker | in essence - we would have a series of conceptual constraints (like psketcher's list for 2D, for example) and we would need to express those in terms of how GECODE defines a system |
| 21:49.28 | mpictor | yea |
| 21:50.42 | starseeker | so we would take (say) sketch, define the notion of angles between edges as a constraint, and then for each specific set of edges that had an angle constraint we would create and insert into the "space" GECODE defines those specific constraints |
| 21:51.24 | starseeker | ditto for distance, horizontal/vertical edges, etc. |
| 21:52.46 | starseeker | I suspect once certain conceptual hurdles and basic setups are in place, it would be fairly straightforward to get at least some basic solves going - the trick would be making sure we are using the right techniques for specification and solving to make it *fast* |
| 21:54.02 | *** join/#brlcad merzo (~merzo@181-27-132-95.pool.ukrtel.net) | |
| 21:54.05 | starseeker | doesn't know if "implement a 2D constrained sketcher using GECODE" is a viable GSoC project or not, but it sure would be interesting |
| 21:54.19 | mpictor | yes, it would |
| 21:54.45 | mpictor | speaking of which, we need to figure out gsoc projects for stepcode |
| 21:55.09 | mpictor | thread safety is one that someone was asking about recently |
| 21:55.22 | starseeker | do you think that's doable for a student in a summer? |
| 21:55.44 | mpictor | I was about to ask what you thought :) |
| 21:56.09 | starseeker | well, the new file breakout will probably help debugging quite a lot |
| 21:56.34 | mpictor | yes |
| 21:56.52 | starseeker | I guess it's a question of how deep the changes would really have to go |
| 21:57.10 | mpictor | but that made me think of all the assignment operators (etc) which copy pointers rather than creating new objs |
| 21:57.22 | starseeker | winces |
| 21:58.04 | starseeker | I almost wanted to suggest as a project getting really nice doxygen documentation generating for the STEPcode sources and maybe even the schema files |
| 21:58.56 | starseeker | that might help all future projects (and us) navigate the labyrinth |
| 22:00.08 | starseeker | mpictor: assuming you want to go with doxygen, of course... |
| 22:00.38 | mpictor | I've wondered about that |
| 22:00.42 | mpictor | there is a doxyfile |
| 22:01.13 | mpictor | I guess the docs could be greatly improved by using more of the doxygen commands |
| 22:01.25 | starseeker | mpictor: that's kinda what I was thinking |
| 22:01.50 | starseeker | would include a component to generate html from express files, complete with graphviz diagrams of component relationships |
| 22:02.04 | mpictor | I've been meaning to re-generate and upload the docs ever since v0.7 :/ |
| 22:02.07 | mpictor | nice! |
| 22:02.31 | starseeker | that might not be doxygen per say (might even be a code-writing project) but it would be a vast help in making sense of what the schemas are trying to tell us |
| 22:02.34 | mpictor | maybe they could take SCView and hook it into libexpress instead of using the sdai libs |
| 22:02.43 | mpictor | yes |
| 22:03.15 | starseeker | even the AP203 practical guide had just a few black and white diagrams - color coding and/or node shape could be used to convey a lot more information |
| 22:04.18 | starseeker | perhaps in addtion to exp2cxx we would have exp2html |
| 22:04.29 | mpictor | hmmm |
| 22:04.45 | mpictor | good idea |
| 22:05.01 | mpictor | and a 'make doxygen' target, of course |
| 22:05.06 | starseeker | right |
| 22:05.30 | starseeker | whether it was an actual doxygen run or called exp2html under the hood instead, the end result would be detailed, useful docs |
| 22:05.42 | starseeker | (actually, it'd probably call both) |
| 22:05.58 | mpictor | yea |
| 22:06.28 | starseeker | the steptools folks do have their hyperlinked pages generated from the schema, and they're quite useful, but I've always thought there might be a way to do better |
| 22:06.32 | mpictor | in a folder adjacent to p21read, there is code to generate html - but it uses the sdai libs rather than libexpress |
| 22:06.41 | starseeker | hmm |
| 22:06.50 | starseeker | is the output any good? |
| 22:07.02 | mpictor | looks a lot like steptools :) |
| 22:07.06 | starseeker | heh |
| 22:07.17 | starseeker | should have guessed |
| 22:07.25 | starseeker | ok, that's a good starting point then |
| 22:07.46 | mpictor | I looked into https://readthedocs.org/ for documentation once, but they require reStructuredText |
| 22:07.53 | mpictor | not compatible with doxygen :/ |
| 22:08.26 | starseeker | nods - especially for a summer project, my instinct would be to have them get familiar with what's there and how it works, then build from that |
| 22:08.37 | mpictor | yes |
| 22:09.31 | mpictor | and I think I looked for programs that could turn c/c++ into rst and didn't see any, so we'd lose a lot |
| 22:10.23 | starseeker | ultimately we'd probably want doxygen for src code and the direct schema documentation to reference each other - I'd love to be able to click on a link in the schema docs and go to the header that defines its corresponding C++ type |
| 22:11.17 | starseeker | anyway, something to think about - "what would our preferred generated documentation look like" |
| 22:12.56 | mpictor | I've wondered from time to time about a gui app with searchable, clickable express |
| 22:13.01 | starseeker | actually, rather than exp2html would probably want exp2doc with a --format option to specify options - would start with html, but in the future we could add rst, docbook, etc |
| 22:13.22 | starseeker | mpictor: could html be generated to produce that result? |
| 22:13.33 | starseeker | or did you have something more like a graph navigator in mind? |
| 22:13.47 | mpictor | hmmm. guess we could do the search in javascript |
| 22:14.00 | mpictor | I was actually thinking of something a lot like SCView |
| 22:14.13 | mpictor | just using libexpress so it would have more info than present in the libs |
| 22:14.21 | starseeker | nods |
| 22:15.27 | mpictor | now that exppp is in use on official schemas, we can be pretty confident that the parser understands all the express currently used in step schemas |
| 22:16.05 | mpictor | actually, its formatted, clickable express could be html |
| 22:16.15 | mpictor | I think that Qt supports html natively |
| 22:16.51 | mpictor | so we could use the same output for the gui app and for the www documentation |
| 22:18.57 | starseeker | nods |
| 22:19.18 | kanzure | have either of you used swagger |
| 22:19.29 | mpictor | never heard ofit |
| 22:19.30 | kanzure | it is a marginally not awful way of rendering schema documentation |
| 22:19.43 | kanzure | http://swagger.wordnik.com/ |
| 22:20.18 | kanzure | anyway i mention it because it takes a schema and generates documentation (i don't think it is directly usable in this context) |
| 22:20.40 | kanzure | the ui is generated from http://petstore.swagger.wordnik.com/api/api-docs/pet |
| 22:21.04 | mpictor | what kind of schema does it take? xml? |
| 22:21.08 | kanzure | json |
| 22:21.34 | mpictor | oic |
| 22:25.00 | *** join/#brlcad merzo (~merzo@181-27-132-95.pool.ukrtel.net) | |
| 22:25.38 | starseeker | was thinking maybe something like D3 could be used to design a navigation widget for a schema view... |
| 22:29.48 | starseeker | but even graphiz rendered images would be a great start |
| 22:30.16 | mpictor | you mean d3js.org? |
| 22:30.27 | mpictor | I always thought chord diagrams looked pretty cool http://bl.ocks.org/mbostock/1046712 |
| 22:31.20 | mpictor | searches for a schema hammer, to pound on a schema until it fits perfectly ;) |
| 22:33.01 | mpictor | speaking of graphs, I wonder what would happen if we ran doxygen on the code from a schema |
| 22:34.21 | starseeker | ponders what size of explosion would make a good analogy... |
| 22:34.57 | mpictor | heh |
| 22:35.16 | starseeker | but actually, that was one of the things I was wondering - whether we wanted to add comments to schema and have them end up as doxygen comments in the generated code |
| 22:35.31 | mpictor | if exp2cxx printed doxygen comments on some things and not others, we could set doxygen to only document commented things |
| 22:35.46 | starseeker | nods |
| 22:35.56 | mpictor | guess I should have read your comment before finishing what I was typing :) |
| 22:36.06 | starseeker | maybe listing undocumented entries upon request |
| 22:36.12 | mpictor | yea |
| 22:36.17 | starseeker | do the schemas allow comments? |
| 22:36.26 | mpictor | oic |
| 22:36.43 | mpictor | (* this is an EXPRESS comment *) --and so is this |
| 22:36.53 | starseeker | sweet |
| 22:37.34 | starseeker | adding comments to those beasts will be a years long process, but if we do it as we go it will end up being a very valuable resource |
| 22:37.46 | mpictor | I was thinking of having exp2cxx write comments for every class stating which entity it came from (for example) and listing ancestors as "see also"'s |
| 22:37.53 | starseeker | our generated schema docs will get progressively more valuable :-) |
| 22:38.16 | mpictor | at least some of the schema tools (such as exppp) strip comments out |
| 22:38.17 | starseeker | nods - then adding any "additional" comments that have been manually added to the output |
| 22:38.23 | mpictor | heh |
| 22:38.50 | starseeker | time to bugfix exppp :-P - GSoC task #1 |
| 22:38.57 | mpictor | lol |
| 22:39.28 | starseeker | seriously though, that would be worthwhile. Remember how useful that old schema with comments was that you dug up a while back |
| 22:39.54 | starseeker | if we can do a more modern version of that, our .exp files will begin to become goto resources instead of just copies |
| 22:40.08 | starseeker | or rather, our generated docs will be the goto point |
| 22:40.13 | mpictor | true |
| 22:40.33 | mpictor | it would require changing the parser though, and probably adding onto the data structures |
| 22:40.42 | starseeker | in exppp you mean? |
| 22:40.46 | mpictor | libexpress ignores comments and has no facility to save them |
| 22:40.50 | starseeker | ah |
| 22:41.03 | starseeker | what do you think - doable for a summer project? |
| 22:41.26 | mpictor | for the right student, I guess |
| 22:41.32 | mpictor | parsers aren't my strong point |
| 22:41.36 | starseeker | (has the advantage of letting them work on something useful while learning and (hopefully) not hurting working functionality) |
| 22:41.52 | mpictor | yes |
| 23:25.53 | starseeker | ``Erik: did Notify get taken out again? |
