| 00:13.44 | starseek1r | hmm https://github.com/memononen/libtess2 |
| 00:16.09 | starseek1r | might be handy if we ever want to compare the GLU algorithm to poly2tri |
| 01:47.31 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 02:19.22 | *** join/#brlcad witness___ (uid10044@gateway/web/irccloud.com/x-eqywjjcekbxokgno) |
| 03:52.50 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 04:06.13 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 04:09.01 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) |
| 04:28.36 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 05:49.29 | *** join/#brlcad clock (~clock@77-58-143-135.dclient.hispeed.ch) |
| 05:59.55 | *** join/#brlcad piyushparkash (~piyushpar@117.205.72.30) |
| 07:10.51 | *** join/#brlcad d_rossberg (~rossberg@66-118-151-70.static.sagonet.net) |
| 07:19.40 | *** join/#brlcad Zhao_Anqing (~clouddrif@183.157.160.10) |
| 07:25.53 | Zhao_Anqing | d_rossberg: hi, I see your E-mail. Yes, I use ~/SVN/nmgreorg_build/src/mged$ make |
| 07:26.04 | Zhao_Anqing | it is successful. |
| 07:26.15 | Zhao_Anqing | then, I execute mged. |
| 07:26.36 | Zhao_Anqing | It displays 'attach (nu|txt)[nu]?' |
| 07:27.37 | Zhao_Anqing | I input nu, then the console become 'mged> ', but there is no graphics window like Windows OS. |
| 07:35.10 | d_rossberg | this means that it couldn't find the X libraries |
| 07:38.56 | Zhao_Anqing | OK. I see. Let me have a try. |
| 07:40.41 | d_rossberg | see http://brlcad.org/wiki/Compiling for a list of neccessary libraries (it don't know if this list is complete) |
| 07:44.20 | d_rossberg | or you could use this: http://sourceforge.net/projects/brlcad/files/BRL-CAD%20for%20Virtual%20Machines/ |
| 07:45.18 | Zhao_Anqing | OK. Thank you, I will try these. |
| 08:03.06 | Notify | 03BRL-CAD:d_rossberg * 61478 brlcad/trunk/include/pstdint.h: for Microsoft Visual Studio version 9 (2008) and lower(?): if _UINTPTR_T_DEFINED/_INTPTR_T_DEFINED the types are defined but not the other macros (UINTPTR_MAX etc.)prevent redefinition of uintptr_t/intptr_t for these casesit should be a valid assumption for every system that if _UINTPTR_T_DEFINED/_INTPTR_T_DEFINED is defined the type uintptr_t/intptr_t |
| 08:03.08 | Notify | exists |
| 08:24.10 | *** join/#brlcad piyushparkash (~piyushpar@117.205.72.30) |
| 08:47.08 | Zhao_Anqing | d_rossberg: I install 'libx11-dev libxi-dev libxt-dev libxau-dev libxext-dev libxmu-dev libxmu-headers' according to the wiki/compiling. but the situation is the same. |
| 08:48.44 | Zhao_Anqing | by the way, the system on my VM is Ubuntu. |
| 08:49.30 | Zhao_Anqing | but it's no problem for me to check the compiling errors. Maybe I can do the main job on Visual Studio, then use 'make' in Linux to ensure it can be compiled. |
| 08:54.00 | d_rossberg | maybe you should try the vn image spexcially prepared for BRL-CAD; you could find out what's missing by analysing the cmake output where it complains about missing headers or libraries but this isn't easy |
| 08:56.54 | Zhao_Anqing | Thank you, I will try again. |
| 08:58.07 | Zhao_Anqing | I should 'make' all BRL-CAD or just MGED? |
| 09:07.53 | d_rossberg | it should build (almost) all |
| 09:09.01 | Zhao_Anqing | OK. Thanks. |
| 10:24.18 | *** join/#brlcad brlcad (~sean@66-118-151-70.static.sagonet.net) |
| 10:49.12 | *** join/#brlcad andrei_ (~IceChat77@188.26.183.113) |
| 10:49.50 | andrei_ | hello |
| 10:50.10 | andrei_ | <PROTECTED> |
| 10:50.28 | andrei_ | a) Ok, I should merge Face and Triangle, but keep which one of the names? Triangle sounds more intuitive, imho |
| 10:50.34 | andrei_ | b) Does the interface look ok? |
| 10:50.35 | andrei_ | Thanks! |
| 10:57.26 | d_rossberg | a) to me too, b) you should work on the mode/orientation/flags methods, the interface has to be self-explanatory |
| 11:00.34 | andrei_ | they are char fields, you mean I should have methods separate for each mode, or that can expose that in some manner? |
| 11:04.16 | *** join/#brlcad mihaineacsu (~mihaineac@92.85.193.175) |
| 11:11.32 | d_rossberg | whot does the char mean? |
| 11:12.10 | d_rossberg | go through the coe and find out |
| 13:12.40 | *** join/#brlcad hsrai (~hsrai@202.164.53.122) |
| 14:16.02 | *** join/#brlcad clock (~clock@77-58-143-135.dclient.hispeed.ch) |
| 14:25.32 | Notify | 03BRL-CAD:ejno * 61479 (brlcad/trunk/src/conv/3dm/3dm-g.cpp brlcad/trunk/src/conv/3dm/conv3dm-g.cpp): import shader settings |
| 14:44.59 | Notify | 03BRL-CAD:starseeker * 61480 (brlcad/branches/openscenegraph/include/dm.h brlcad/branches/openscenegraph/include/ged.h and 37 others): Complete the first stage of dm extraction from libged - mged and archer build and run again. Still a great deal more extraction/rationalization to do before starting to rework the libdm API towards a scene graph approach, but this was the first stage. |
| 14:48.14 | Notify | 03BRL-CAD:starseeker * 61481 brlcad/branches/openscenegraph/include/ged.h: ged_vclip is no more - was just a copy of a libdm function. |
| 15:08.28 | Notify | 03BRL-CAD:starseeker * 61482 (brlcad/branches/openscenegraph/include/dm.h brlcad/branches/openscenegraph/src/adrt/isst_tcltk.c and 5 others): More winnowing of libdm pieces - plot and postscript should be outputs of displays, not full-fledged display managers. |
| 15:12.54 | brlcad | starseeker: interesting conundrum with the libdm/libged refactoring work, and don't know if you've got any ideas on how to get there or if it's already in your plans, but from an architecture-standpoint it'd be good to have libged not depend (directly) on libdm |
| 15:20.38 | brlcad | starseeker: also (reading backlog) the freetype requirement on downstream is the same as on us: no mixing of sources, no derivative work, and must retain credit statements |
| 15:22.18 | brlcad | starseeker: it is gpl-incompatible due to the advert clause which is why you can't mix the sources, but still doesn't mean one can't use the library |
| 15:23.07 | brlcad | I can clearly fulfill all the terms of the FTL and LGPL/GPL if they're kept separate, and that's what matters for our particular use |
| 15:24.59 | brlcad | integrating something even more minimal like fontstash or whatever sounds good, but just shouldn't discount freetype because of the license |
| 15:47.18 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 15:47.38 | starseeker | brlcad: OK, sounds good |
| 15:47.58 | starseeker | (freetype license) |
| 15:48.47 | starseeker | as far as libged/libdm goes - at this point, libged pretty much 'de-facto' required libdm and was duplicating things and holding a lot of logic that libdm (imho anyway) should be handling |
| 15:49.33 | starseeker | while I've now introduced an explicit libdm dependency in libged, I've gotten libged at least partially out of the libdm business and hope to get it further out |
| 15:50.40 | starseeker | the real trick seems to be that a lot of "libged" commands have explicit notions of interacting with the display |
| 16:09.43 | starseeker | my long term plan would be to split the commands acting on the view out of libged altogether, but that shifts the responsibility of updating the display to the application using both libged and libdm |
| 16:09.51 | starseeker | (i.e. more than a little invasive) |
| 16:34.52 | Zhao_Anqing | brlcad:hi, excuse me, do you know why there is no graphics window when I run mged on Linux. |
| 16:35.20 | Zhao_Anqing | it prompt 'attach (nu|txt)?[nu]' |
| 16:35.44 | Zhao_Anqing | there isn't such problem on Windows. |
| 16:37.43 | brlcad | starseeker: it was not a good thing, but it was doing all that duplication explicitly to avoid requiring libdm |
| 16:38.44 | brlcad | bob just found it easier to copy the code instead of creating a proper interface that hides libdm being registered by a libged caller (i.e., mged/archer) |
| 16:40.09 | brlcad | the problem is one of encapsulation -- binding to libdm (and libfb, similar issues) makes it practically impossible to create a self-contained libged that apps could download and use (which is a goal) |
| 16:40.58 | brlcad | makes libged intimately aware of a lot that isn't necessarily (probably isn't) relevant to app developers |
| 16:41.25 | starseeker | nods |
| 16:41.35 | brlcad | the other issue is that we're really coupling libdm to libged for the sake of .. 3 commands? |
| 16:41.44 | starseeker | not sure |
| 16:42.00 | starseeker | a lot of them seem to want to update the view after their work is done |
| 16:42.13 | brlcad | sure |
| 16:42.45 | brlcad | "most" of the commands need to or should update the view after they're done working .. really any command that affects whatever is considered the active working set |
| 16:43.21 | starseeker | right - and right now, that means they all need to know about the display |
| 16:43.23 | brlcad | decoupling libdm is a CS-architecture issue, not a behavior/functionality issue |
| 16:44.07 | starseeker | brlcad: for me, at the moment, I'm trying to get to a point where more of the details of how the display manager does what it does are hidden from the user libraries and apps |
| 16:44.37 | starseeker | hopefully, that will also set up a longer term general improvement in the API design, but I don't know if I have the time/resources to tackle the whole thing right now |
| 16:44.46 | brlcad | "that means they all need to know about the display" -> does not mean they need to know about libdm |
| 16:44.58 | brlcad | and technically they don't need to know about the display, the app does |
| 16:45.03 | starseeker | sure |
| 16:45.15 | brlcad | the app needs to know that the command has changed something |
| 16:45.36 | starseeker | would have expected to have something in the ged struct that gets set that the app can check to know whether or not to update the view |
| 16:45.58 | brlcad | heh, THAT's the point :) |
| 16:46.07 | brlcad | something like that should exist, and is the issue |
| 16:46.18 | brlcad | and it's certainly not more work |
| 16:46.37 | starseeker | brlcad: what I'm doing right now should help set the stage for that |
| 16:47.14 | starseeker | it *is* more work in that all the calling applications have to change both their libdm and libged interaction paradigm |
| 16:47.18 | brlcad | I'm not seeing how that is true from the commits, but okay |
| 16:47.37 | starseeker | I need to get the libdm-esque functionality out of libged |
| 16:48.38 | brlcad | adding a dm architecture linkage does the exact opposite of that :) |
| 16:48.57 | starseeker | it was already there, just "implicit" in all the copied code |
| 16:49.02 | starseeker | that's cheating |
| 16:49.12 | brlcad | I know it's a work in progress, but that linkage really does defeat one of the central usages for how that library was architected |
| 16:49.48 | starseeker | brlcad: I'm aiming to get libdm out of libged altogether, but do so while keeping everything working |
| 16:50.23 | Notify | 03BRL-CAD:ejno * 61483 (brlcad/trunk/src/conv/3dm/conv3dm-g.cpp brlcad/trunk/src/conv/3dm/conv3dm-g.hpp): fix invalid color generation and check validity of m_material_index |
| 16:50.52 | brlcad | so then we're in violent agreement? why is this so difficult to discuss? :) |
| 16:51.05 | brlcad | if you're getting it out, then entirely moot point |
| 16:51.16 | brlcad | my only concern is shipping a libged that needs libdm |
| 16:51.19 | starseeker | I guess it just doesn't look like that's what I'm doing from the commits |
| 16:51.25 | starseeker | hence working in a branch :-) |
| 16:51.29 | brlcad | if that happens, I think we have a big problem and have regressed |
| 16:52.14 | brlcad | well the context you're maybe missing is that libdm was initially added the way you just reverted it |
| 16:52.20 | brlcad | and it was changed because that is a greater problem |
| 16:52.39 | Notify | 03BRL-CAD:ejno * 61484 brlcad/trunk/src/conv/3dm/conv3dm-g.cpp: fix missing const |
| 16:53.06 | brlcad | so now it's back to where it was, even more spread throughout ged because there are one or two additional commands ... so in all -- at the current state of the branch code -- it's a regression of the architecture further away |
| 16:53.17 | starseeker | nods - but if libdm is to be radically reworked to take on a lot more of the responsibility of the details of scene management, those management codes need to come out of everywhere else |
| 16:53.18 | brlcad | if that's you're method for making progress forward, okay great |
| 16:53.56 | starseeker | if I understood correctly what happened in libged, the way it avoided depending on libdm was simply snarfing in large parts of it |
| 16:54.44 | brlcad | yes, that is basically what happened |
| 16:55.06 | brlcad | it sucked, but it DID technically fix the architecture regression |
| 16:55.46 | starseeker | still think's it's cheating - it doesn't really address the issue unless libged is reworked to not *need* those pieces |
| 16:55.56 | starseeker | which is where I'm headed |
| 16:56.21 | *** join/#brlcad Darshpreet (~Darsh@202.164.53.117) |
| 16:56.50 | starseeker | pretty much forced to do it, since if libdm + scene graph works the way I'm hoping it will the libraries/apps *can't* micromanage at that level |
| 16:56.51 | brlcad | I can't nod any more vigorously in agreement that it sucked and was bad |
| 16:57.08 | brlcad | making libdm explicit (and shipping it that way) is just worse |
| 16:57.14 | brlcad | only by a hair |
| 16:57.40 | brlcad | turns it from being an implementation detail to something apps have to deal with |
| 16:57.43 | starseeker | nods |
| 16:58.30 | starseeker | don't worry - I won't fold those commits back into trunk |
| 16:58.43 | *** part/#brlcad Darshpreet (~Darsh@202.164.53.117) |
| 16:59.17 | starseeker | is actually more concerned that once he gets done with this the libged API may end up looking rather... different |
| 16:59.28 | starseeker | at least, in terms of immediate backwards compatibility |
| 17:01.37 | brlcad | front-end API or back-end API? |
| 17:02.04 | starseeker | probably both... |
| 17:02.08 | brlcad | ged's front-end API should consist of very very little... |
| 17:02.58 | brlcad | what really should happen is ged have absolutely no awareness of a display |
| 17:03.20 | brlcad | it should know about active sets of geometry and changes to geometry |
| 17:03.28 | starseeker | right. That means large swatchs of ged.h (like a lot of what I already grabbed out of it) won't return |
| 17:03.32 | brlcad | views on that geometry |
| 17:03.47 | starseeker | even views are a bit iffy... |
| 17:04.01 | brlcad | I see ged a lot like gcv .. it should be less than probably a dozen functions on the public API side of things |
| 17:04.08 | starseeker | 'view' - to me at least - is a display concept |
| 17:04.16 | brlcad | "run this command" .. call the event callbacks |
| 17:04.25 | starseeker | information deduced from the view might be fed to libged... |
| 17:05.19 | brlcad | possibly, I toyed with that idea years ago, but there are several commands that I think may be impossible without at least a notional view concept |
| 17:05.30 | brlcad | view may even be not the best word to use |
| 17:05.41 | brlcad | or have to at least think about it in more abstract terms |
| 17:05.45 | starseeker | brlcad: well, libged doesn't necessarily need to be the source of all application commands |
| 17:06.06 | starseeker | was actually thinking that's a bad idea... "geometry editing" is a specific focus |
| 17:06.43 | brlcad | maybe, but I'm not convinced it can't be architectured to support most if not all in a plugin style |
| 17:06.54 | starseeker | commands manipulating the display it seems to me should come from libdm |
| 17:07.13 | starseeker | "open" -> dm_open, etc. |
| 17:07.19 | brlcad | having to ask "well, what kind of command is that" already sucks for pure tcl vs C tcl vs mged C vs GED C ... |
| 17:08.17 | brlcad | a command like "select" is a good example of one that really begs awareness of some "view" concept |
| 17:08.19 | starseeker | double edged sword - when I go looking for the aet command, my first instinct is to go looking in the display manager code |
| 17:09.00 | *** join/#brlcad hcurtis (4ab29bcf@gateway/web/freenode/ip.74.178.155.207) |
| 17:09.03 | brlcad | instincts are a dangerous notion .. that's just familiarity which can be highly biased ;) |
| 17:09.05 | starseeker | select too, actually - that has to do with "geometry editing" only in the sense of preparing a list of object on which to operate |
| 17:09.20 | brlcad | speaking of double-edged swords :) |
| 17:09.45 | starseeker | "command manipulating the display is the responsibility of the display library" |
| 17:10.07 | starseeker | maybe funneled through libtclcad for the Tcl wrappings |
| 17:10.35 | brlcad | that is entirely the purpose of select, prepare lists of objects ... so there is some interaction with the view but I don't see that interaction as being at all dependent upon how a display manager is implemented |
| 17:10.58 | starseeker | it isn't. but it doesn't (necessariliy) have anything to do with actually editing the geometry |
| 17:10.59 | brlcad | or whether one even exists .. I can use it in console mode just as well |
| 17:11.42 | brlcad | I'm not following what your point is .. to remove select from libged? |
| 17:11.57 | brlcad | I see it as quite fundamental |
| 17:13.12 | starseeker | not specifically select - anything that interacts with a notion of "view" (in this case, the NULL display manager is just a view without rendering) either to manipulate the view or to extract information from it that is in turn fed to other libraries (like libged) I see as separate from actually changing/editing the geometry objects themselves |
| 17:15.15 | brlcad | and separate then means what? doesn't belong in libged? |
| 17:15.24 | starseeker | right - libdm handles views |
| 17:15.35 | brlcad | except select is specifically a command that extracts information from "some notion of a display/view/context/set", so how does it fit in that view? |
| 17:15.53 | starseeker | I would put it in libdm, but that's me |
| 17:16.23 | starseeker | select generates a list of objects, which is then supplied as libged input |
| 17:16.25 | brlcad | yeah ... that makes no sense to me :) |
| 17:18.34 | brlcad | select is ALSO view agnostic .. so I can say "select all objects that start with the letter J with a regionID attribute" .. that would have absolutely no basis for being in libdm |
| 17:18.36 | starseeker | well, like you said, select "begs awareness of some "view" concept" |
| 17:19.16 | brlcad | trying to fully characterize commands as being "display commands" and "editing commands" was already attempted |
| 17:19.19 | brlcad | twice |
| 17:19.20 | brlcad | both failed |
| 17:19.34 | starseeker | that example actually sounds like a search command, but anyway... |
| 17:19.37 | brlcad | actually three times if you count back when they were up in librt |
| 17:19.52 | brlcad | sure, might even be built on the search API |
| 17:20.00 | brlcad | all the more reason it wouldn't belong in libdm |
| 17:20.52 | starseeker | might hinge on what the notion of select's responsibilities are - I see it as defining some constraint in the view and collecting the objects that satisfy those constraints (drawn, within distance X of this line, etc.) |
| 17:21.15 | brlcad | or even more twisted .. someone begs for something like a search -isDisplayed option |
| 17:21.28 | brlcad | so you can search only the hierarchy of things being displayed |
| 17:21.50 | brlcad | would that suddenly make it libdm's responsibility? ... yikes! |
| 17:21.56 | starseeker | would implement that as an application level filter that collects the output of a view command and passes it to search |
| 17:23.17 | brlcad | so now I'm an application developer like openscad that is just hooked into libged .. and I either don't get search or I don't get that option |
| 17:23.32 | brlcad | saying it's the apps problem is just punting on the problem |
| 17:24.20 | starseeker | but openscad will have its own notion of what is being displayed/drawn, and unless it's using our display manager our libraris won't know what's displayed |
| 17:24.28 | starseeker | s/libraris/libraries |
| 17:24.38 | brlcad | not true |
| 17:24.54 | starseeker | ? |
| 17:26.25 | brlcad | there are several possible ways that I could implement a search -isDisplayed without needing to know about libdm and without needing to know what openscad's drawing notions are |
| 17:26.51 | starseeker | and without libged needing a notion of view? |
| 17:26.56 | brlcad | it's an API design question, encapsulation and bindings |
| 17:28.41 | brlcad | to answer isDisplayed, sure I don't need a notion of a view .. I need some simple container notion |
| 17:29.16 | starseeker | you mean a list of what is active at the moment? |
| 17:29.17 | brlcad | that one app might use to imply "these things are displayed" or "these are hidden" or "these are wireframe and these are shaded" .. whatever, app specific |
| 17:29.30 | brlcad | it's just a set of something |
| 17:30.05 | brlcad | that's basic API query-request management that it needs to be doing anyways |
| 17:30.37 | starseeker | right... I was thinking that the application maintains its sets and passes them in to libged calls as arguments - "operate on this set" |
| 17:31.20 | brlcad | that's certainly one way, but then we'll end up with fragmented commands |
| 17:31.38 | starseeker | thought that was a way to keep state out of libged... |
| 17:31.54 | brlcad | commands that only exist on the application front-end because they needed something from there, and again needing to know where a command was stashed limiting its utility elsewhere |
| 17:32.34 | brlcad | commands are implemented stateless -- they're passed the state in the ged struct |
| 17:32.56 | starseeker | wouldn't libtclcad or something like it be the place to define commands needing pieces from multiple places? |
| 17:33.35 | brlcad | if I were only writing a tcl application, maybe |
| 17:33.42 | brlcad | libtclcad shouldn't even need to exist |
| 17:34.07 | starseeker | ok, so a libcadcmd or some such |
| 17:35.04 | brlcad | and when you're done implementing it that generically, fully encapsulated .. you'd have exactly what libged was intended to be |
| 17:35.05 | starseeker | maybe part of my reluctance is just that a lot of libged stuff needs to be pushed lower |
| 17:35.54 | brlcad | why does needing to push some things lower make you reluctant for having all commands in one place ?? |
| 17:36.27 | brlcad | I should not have to go to more than one place to find the implementation for any command |
| 17:36.28 | starseeker | wants conceptual separation between view manipulation and geometry editing (changing objects on disk) |
| 17:36.43 | brlcad | anything else is really just bad architecture, encapsulation fail |
| 17:37.12 | brlcad | but that doesn't work!! :) |
| 17:37.15 | starseeker | that doesn't necessarily need to be at the command level, but if the commands are going to know about views then I don't see how we keep libdm out of the command mix |
| 17:37.33 | brlcad | and was attempted VERY unsuccessfuly multiple times before |
| 17:37.50 | starseeker | isn't convinced it doesn't work, but I suppose I'm just not smart enough to see it. |
| 17:38.15 | brlcad | see the _obj commands in libged (which came from mged and librt prior) |
| 17:38.47 | brlcad | dg_obj ... "drawable geometry commands" .. commands that supposedly only affect the display of objects |
| 17:39.16 | brlcad | view_obj ... commands that supposedly only manipulate the view |
| 17:39.24 | brlcad | wdb_obj .. commands that modify geometry |
| 17:39.57 | brlcad | it's a royal clusterfudge in terms of encapsulation, because useful commands invariably and often have aspects of all three to make them more useful |
| 17:40.40 | brlcad | that's why a plugin-style one-stop shop was architected for libged, everything I need for a command in one place (one dir, one file, whatever) |
| 17:40.47 | starseeker | brlcad: then I'm having a really hard time reconsiling that with the drive to keep libdm out of libged |
| 17:41.01 | brlcad | maybe this will help |
| 17:41.13 | starseeker | at least, libdm as I'm imagining it (which is more than a device wrapper) |
| 17:41.34 | brlcad | a command can be written to intimately USE libdm without libged api ever knowing that it existed |
| 17:42.04 | brlcad | that's not an ideal end-state, but it's better than type exposure |
| 17:42.36 | brlcad | e.g., say you have a command that needs to know what is drawn, and libdm somehow statefully was aware of that information |
| 17:43.22 | brlcad | the app could register a "here's what's displayed" function with the ged struct that is passed to ged_whatever() .. which that function calls |
| 17:44.13 | brlcad | call that "simple method A" |
| 17:45.08 | starseeker | so functab style callbacks? |
| 17:45.38 | brlcad | "ideal method B" would be to have ged have API that has some label->set notion so the app could create a set called "active geometry" and provide either a callback or provide identifiers |
| 17:46.37 | starseeker | that has to be synced with the display manager (intimately - any change to the libged list would have to pass immediately to the display manager) |
| 17:46.49 | brlcad | yes, method A would be akin to functab ... libged still relies on libdm from a library dependency standpoint, but the app created that dependency |
| 17:47.31 | brlcad | ideally the API for method A would expose no libdm types, so libged could remain dependency-free symbolwise |
| 17:47.43 | brlcad | i.e., no libdm headers on the implementation |
| 17:48.11 | brlcad | method B is far better, but just a little bit more work to define the ged api |
| 17:49.35 | starseeker | I'm not sure how to proceed then. I need to radically rework how libdm does business, and as matters stand right now that means anywhere display lists (libged, mged, whatever) are in play I need to rework how they're handled |
| 17:49.36 | brlcad | ideal method C" would be to have ged API fully contain some notion of display sets (in agnostic terms, i.e., predefined containers), views on those display sets (in fully generalized terms), and geometry associated with each |
| 17:50.57 | brlcad | method C was the original design plan |
| 17:51.06 | brlcad | it's documented somewhere, but don't recall exactly where .. maybe a header |
| 17:52.02 | brlcad | method C lets you really capture any action I could conceive an application performing, whether GUI or command-based, embedded or otherwise |
| 17:52.03 | starseeker | but how do we guarantee thay any change to the display sets also updates the display manager? Does all access to the geometry list go through functions? |
| 17:52.43 | brlcad | the app sets up the ged context |
| 17:53.33 | brlcad | so the ged API is either "these events happened, handle them" or we make it explicit where the app registers handlers for given events |
| 17:54.16 | starseeker | doesn't that constrain us to a fixed set of event types? |
| 17:54.37 | brlcad | could be as simple as "the geometry in the ged context I got back is different than the one I gave you, so update the display" and we'd avoid events and callbacks, but that's a loose guarantee |
| 17:55.43 | brlcad | there is nothing that precludes having dynamic events, but a very limited set of event types does cover everything we currently do |
| 17:56.22 | brlcad | especially with method C, you end up basically covering display, view, and geometry events ... the only thing you're missing is any GUI events that are already fully in the app's domain |
| 17:57.53 | starseeker | There's a "Conceptual Documentation for LIBGED" in ged.h - is that it? |
| 17:59.57 | starseeker | so under method C, libdm would take the view struct and operate on that? |
| 18:00.25 | starseeker | and it would be the applications responsibility to do so? |
| 18:00.53 | starseeker | or is the libdm call embedded as a callback in the view update() concept by the application? |
| 18:02.39 | brlcad | that looks like a simplified version of it in ged.h |
| 18:03.42 | brlcad | making libdm take the view struct would make libged a libdm dependency, which would similarly be as undesirable as the reverse from an encapsulation perspective |
| 18:03.54 | brlcad | I'd expect the application to set up what it wants |
| 18:05.36 | brlcad | if it's going to use libdm to display things, it's going to be the one responsible for wiring it up |
| 18:06.07 | starseeker | is fine with that, if we can figure out what we need to define and set up to make it work |
| 18:06.58 | brlcad | what will probably work best and most automatic would be for libged to define an update callback interface that the app would register, that callback has front-end state (e.g., pointers to Qt data structures or libdm std::maps or whatever) so it would do the work to update based on the response |
| 18:07.24 | brlcad | or more generally, an event callback interface where "update" is just one of many possible events |
| 18:18.01 | Notify | 03BRL-CAD:carlmoore * 61485 brlcad/trunk/doc/docbook/system/mann/en/picket_fence.xml: add comma, use boldface for -r in paragraph, and rearrange/reword Example; also put space between 2 arguments in the Example |
| 18:26.19 | Notify | 03BRL-CAD:n_reed * 61486 (brlcad/branches/brep-debug/src/libbrep/debug_plot.cpp brlcad/branches/brep-debug/src/libbrep/debug_plot.h): simplify surface plots to include only the knot isocurves used during overlap detection |
| 18:48.14 | hcurtis | These questions are for anyone and everyone: 1) Since I'm a beginner, what should I do to become a better programmer? 2) What helped you when you were first getting started in programming? I know I need to keep reading, taking classes, and writing code, but maybe you would have additional suggestions I'm not yet aware of. |
| 18:55.29 | brlcad | hcurtis: what you know is really 95% of the effort |
| 18:55.41 | brlcad | write code (every day) |
| 18:56.01 | brlcad | lots and lots of code |
| 18:56.07 | brlcad | as much as you can, with specific goals in mind |
| 18:56.13 | brlcad | and once you are proficient with the basic syntax, read code (every day) |
| 18:57.27 | brlcad | how do you get proficient building furniture? you build furniture. the more the better. |
| 18:57.53 | hcurtis | Ok |
| 19:00.05 | brlcad | of course you have to have place to begin (example code, tutorials, classes, reading websites) and you'll make lots of mistakes |
| 19:00.46 | brlcad | but that's to be expected, we've all spent hours hunting down some problem only to find it was a single character typo at some point in the learning adventure |
| 19:01.29 | hcurtis | True |
| 19:02.08 | brlcad | really, though, you shouldn't obsess on those beginning points -- reading and writing code is how you will mostly learn how to read and write code |
| 19:03.28 | brlcad | I suggest thinking up the simplest smallest possible application that would be interesting to you, and working towards that as a goal |
| 19:04.01 | hcurtis | That's a good idea. |
| 19:04.11 | clock | brlcad, "you shouldn't obsess" - I think telling someone what mental states to have is generally considered disrespectful |
| 19:07.01 | brlcad | clock: I don't see it that way when someone asks for advice, as considering how to mentally frame and approach a learning problem can very much influence the outcome |
| 19:08.00 | brlcad | perhaps "my suggestion for anyone wanting to learn something would be to not spend a lot of relative time reading about learning that thing, but actually doing that thing" |
| 19:09.40 | brlcad | someone suggested to me to not worry about making coding mistakes when I was younger, and I like to think it was helpful -- especially contrasted with other students I knew that had an overwhelming sense of defeat after making mistake after mistake, seemingly endlessly |
| 19:13.15 | brlcad | wonders if Douglas Adams considered how disrespectful he was being telling everyone "Don't Panic" :) |
| 19:19.47 | clock | "Don't Panic" is another example yes |
| 19:33.32 | hcurtis | brlcad: Thanks |
| 19:48.02 | Notify | 03BRL-CAD:starseeker * 61487 brlcad/trunk/src/other/libgdiam/gdiam.cpp: Start trying to use the Monotone chain hull approach for libgdiam, in the hope that it will provide a more robust convex hull. Right now, the code is imperfectly adapted to the libgdiam structures so it's not clear if it will work. |
| 19:50.21 | n_reed | I think this two-part animated video is a friendly summary of the typical programming advice: https://www.youtube.com/watch?v=WCuUWGmatpU |
| 19:59.49 | brlcad | n_reed: that's pretty awesome, thanks for sharing that video -- hadn't seen it before |
| 20:10.10 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 20:14.06 | Notify | 03BRL-CAD Wiki:Sean * 7439 /wiki/An_Introduction_To_New_Developers: link to a pair of good videos on being a dev |
| 20:21.29 | *** join/#brlcad mihaineacsu (~mihaineac@92.81.55.66) |
| 20:27.54 | mihaineacsu | brlcad: in order to link rtweight and gqa with libcurl, I probably need to modify cmakelists. Any advice on how to that? |
| 20:28.38 | mihaineacsu | I managed to compile rtweight by adding -lcurl flag in link.txt in the build folder; tested it out and it worked fine with a remote density file. |
| 20:32.04 | n_reed | brlcad: glad you like it. now if only I actually followed all of that advice =) |
| 20:41.25 | hcurtis | n_reed: I agree with Sean. Great videos. Thanks for posting that link. |
| 20:45.40 | Notify | 03BRL-CAD:n_reed * 61488 brlcad/branches/brep-debug/src/libtclcad/tclcad_obj.c: have dplot only trigger an autoview after the first draw to an empty display |
| 21:14.31 | Notify | 03BRL-CAD:ejno * 61489 (brlcad/trunk/src/conv/3dm/conv3dm-g.cpp brlcad/trunk/src/conv/3dm/conv3dm-g.hpp brlcad/trunk/src/conv/CMakeLists.txt): import textures using libicv (in progress) |
| 22:03.58 | Notify | 03BRL-CAD Wiki:Ankeshanand * 7440 /wiki/User:Ankeshanand/GSoC14/logs: /* Week 6 */ |
| 22:06.50 | Notify | 03BRL-CAD Wiki:Albertcoder * 7441 /wiki/User:Albertcoder/GSoC2014/logs: /* Week 6 */ |
| 23:03.06 | *** join/#brlcad KimK (~Kim__@ip68-102-30-143.ks.ok.cox.net) |