| 05:32.11 | *** join/#brlcad elite01 (n=omg@unaffiliated/elite01) | |
| 06:24.26 | *** join/#brlcad PrezKennnedy (i=Matthew@whitecalf.net) | |
| 08:20.48 | *** join/#brlcad clock_ (n=clock@84-72-91-240.dclient.hispeed.ch) | |
| 09:34.44 | *** join/#brlcad Bariton (n=Bary@p5B14FC70.dip.t-dialin.net) | |
| 11:19.44 | *** join/#brlcad mafm (n=mafm@elnet-111.lip.pt) | |
| 11:20.42 | mafm | hai pplz |
| 12:00.43 | AFK-claymore | Mornin! |
| 12:09.46 | claymore | has a titan to play with now... MUWAHAHAHAHAHA. |
| 12:13.59 | *** join/#brlcad Bariton (n=Bary@p5B14FC70.dip.t-dialin.net) | |
| 12:14.21 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) | |
| 12:56.08 | *** join/#brlcad geocalc (n=geocalc@91-171-212-221.rev.libertysurf.net) | |
| 13:41.32 | claymore | brlcad: You in today? |
| 13:43.41 | CIA-24 | BRL-CAD: 03bob1961 * r33106 10/brlcad/trunk/src/conv/bot_dump.c: Print out what's in the result string. |
| 14:47.55 | brlcad | claymore: I take it you see your note |
| 14:48.14 | claymore | From Ed? |
| 14:48.18 | brlcad | yea |
| 14:48.29 | brlcad | or you asking for some other reason? |
| 14:48.35 | claymore | Yea, I was in for a bit on Friday. Took care of all that. |
| 14:49.05 | claymore | General BRLCAD coding questions ;) reading through libged, trying to get a handle on things. |
| 14:49.36 | brlcad | well ask away! :) |
| 14:49.43 | claymore | I have a good class layout for the GS, just need to start getting the specifics worked out now. |
| 14:50.09 | ``Erik_ | the blue pill |
| 14:50.42 | claymore | but, I need to see how deep the rabit hole goes. |
| 14:50.43 | ``Erik_ | if y ou just have the descriptor and want the handle, use fdopen() :D *duck* |
| 14:51.49 | claymore | get his 11 peice set and performs a rimshot... badoom ching. |
| 14:57.10 | ``Erik_ | interesting, http://pastebin.bzflag.bz/d6384593 |
| 15:11.52 | *** join/#brlcad elmom (n=elmom@hoasnet-ff04dd00-187.dhcp.inet.fi) | |
| 15:11.54 | *** join/#brlcad ``Erik_ (i=erik@c-68-54-174-162.hsd1.md.comcast.net) [NETSPLIT VICTIM] | |
| 15:14.15 | louipc | yeah tkhtml3 isn't installing in the brlcad directory |
| 15:32.19 | *** join/#brlcad elite01 (n=omg@unaffiliated/elite01) | |
| 15:35.26 | *** join/#brlcad ``Erik_ (i=erik@c-68-54-174-162.hsd1.md.comcast.net) [NETSPLIT VICTIM] | |
| 16:00.31 | CIA-24 | BRL-CAD: 03bob1961 * r33107 10/brlcad/trunk/ (19 files in 9 dirs): Moved g_qa functionality to libged. Port g_qa to windows. |
| 16:22.58 | clock_ | "you'll have enough sleep in the grave" - brlcad is a tough guy |
| 16:23.08 | clock_ | likes this reckless aggressive creativity |
| 16:28.46 | brlcad | doesn't think it's reckless |
| 16:29.40 | clock_ | Recklessness (psychology), a state of mind in which a persons acts without caring what the consequences may be |
| 16:29.45 | clock_ | Doesn't apply for this case>? |
| 16:35.23 | claymore | brlcad: When it comes to the Geometry Service: What had you invisioned for the in-memory representation of geometry? Using the existing c structs? |
| 16:35.55 | claymore | If so, would the svn store then be full of mini-.g files? |
| 16:35.57 | brlcad | claymore: yes, librt already manages geometry |
| 16:36.43 | brlcad | there's some value wrapping them in objects, but still the actual geometry still being via librt |
| 16:36.47 | claymore | I am trying to find the line between librt and a GeometryManager/CachManager is.... |
| 16:37.06 | claymore | CacheManager even. |
| 16:39.18 | brlcad | yeah, svn store consists of .g files broken out |
| 16:40.00 | claymore | Now, is that also a long term solution? Or would we want a slightly more efficient binary format for the geometry fragments in the svn store? |
| 16:40.58 | brlcad | for now it is, our format is actually really compact and efficient as it is |
| 16:41.30 | brlcad | doesn't get much more streamlined than a straight-up binary serialization of the exact data |
| 16:41.49 | claymore | Right, understood. I was just wondering how much could be gained by slimming down the header/footer for the future bin format... thats all ;) |
| 16:42.28 | brlcad | actually for long-term, there would likely be more benefits by using a more flexible non-binary backend store .. but that's a long ways out and would require a lot of testing |
| 16:42.47 | brlcad | current header/footer is like 100 *bytes* |
| 16:43.14 | claymore | pure wastefulness. tsk tsk. A byte is a byte no matter how small. ;) |
| 16:43.15 | brlcad | add a text attribute on an object and you use up more space than that |
| 16:44.05 | clock_ | PDP had like 9 bit bytes didn't |
| 16:45.23 | claymore | Different question then: Since I am relatively unfamiliar with librt, does librt contain the list/tree of db_internals or is that managed external to librt? |
| 16:47.54 | brlcad | I'm expecting our average "object" size to be around 1k for implicits, 10k for spline breps, and 100k for polygonal breps (includes attribute and revision changeset data) |
| 16:48.38 | brlcad | so the .1k wrapper isn't going to amount to much, less than 99% of the data being stored -- and if it is a problem, it can of course be looked into then |
| 16:54.59 | claymore | Different question then: Since I am relatively unfamiliar with librt, does librt contain the list/tree of db_internals or is that managed external to librt? |
| 16:57.38 | brlcad | no, it provides it -- when you open a .g file, you get back a "database instance" |
| 16:57.44 | claymore | 1k for implicits.... really? Are you talking on average? Seems to me that a sphere would be much smaller than 1k |
| 16:58.14 | brlcad | that dbi gives you a handle on a variety of routines, one being a "directory" that you can lookup |
| 16:58.36 | claymore | thinks. |
| 16:59.16 | claymore | I dunno how well that is going to translate to a the way I am envisioning the 'shared geometry' concepts... |
| 17:00.02 | claymore | .... perhaps the cachemanager will simply be holding an array/list/set of db instances? |
| 17:01.31 | brlcad | hm, it could but I didn't envision the GS talking much to librt directly |
| 17:01.48 | brlcad | almost entirely via libged and (even moreso) the GE |
| 17:02.36 | claymore | My current design is that the GE wraps up all of libged functionality and the GE also contains the GeometryManager |
| 17:03.08 | starseeker | ``Erik: You're specifying your tcl and tk in /usr/local - tkhtml3 is a tcl/tk package, so it's going to try to install in the "correct" place for tcl/tk packages on that system - I'm assuming that's the TEA behavior |
| 17:03.17 | claymore | the GeometryManager is what is doing all the caching and IO of the geomtery, regardless of its source or destination. |
| 17:03.34 | starseeker | as I understand it, that behavior is necessary for package require ... to function correctly |
| 17:03.35 | brlcad | that sounds reasonable |
| 17:04.51 | claymore | brlcad: now, besides the fact that we will be using libged, we will still need a way to store (cache) and correlate the bits of geometry so as to provide multi-user access. So, I am stuck on what data struct the GeometryManager (GeoMan) will be caching... db internals? |
| 17:05.52 | brlcad | Geometry objects -- enter data containers that GE needs to have |
| 17:05.59 | starseeker | growls at his email |
| 17:06.27 | brlcad | those geometry objects utilize db internals |
| 17:07.25 | claymore | starseeker: I think i figured out what was wrong with the way we were doing the email thing. Swing by and I think we can make it work! |
| 17:08.22 | claymore | brlcad: So a GeometryObject will: a) replace everthing a db internal has/can do, or b) have a db internal as an aggregate and just add some extra fields? |
| 17:08.42 | brlcad | some mix of b) and c) |
| 17:08.44 | starseeker | claymore: thanks! on my way |
| 17:09.19 | brlcad | it has a handle on the geometry via librt representation |
| 17:09.41 | brlcad | we might add extra fields, but all I/O should still be going through librt so I'm not sure they'd be extra |
| 17:10.40 | brlcad | two things that are useful to read up on are what's already in rt^3 for the geometry engine that daniel's worked on as well as what is in the jbrlcad module and how it structures object management |
| 17:11.12 | *** join/#brlcad geocalc (n=geocalc@91-171-212-221.rev.libertysurf.net) | |
| 17:11.17 | brlcad | I've not been able to review daniel's latest work in detail, but what I've seen quickly looking has been good |
| 17:11.39 | brlcad | I have read john's jbrlcad layout in detail and *really* like it |
| 17:11.52 | brlcad | it's an outstanding OO organization of librt |
| 17:12.02 | brlcad | just incomplete |
| 17:12.12 | brlcad | and in the wrong language :) |
| 17:18.37 | claymore | brlcad: Okay, I looked at jbrlcad about a year ago, but I need to refresh my memory. I'll look at what daniel has done. |
| 17:19.48 | brlcad | from your perspective, I think the take-home point is just going to be that there's going to be "some" object that represents/links/is geometry and it is that object that you could cache |
| 17:19.58 | claymore | also, we will need a way to keep all the geomitry bits unique, so I was thinking of using a long for the OID... which we would have to piggyback as an attribute for now. |
| 17:20.43 | brlcad | yeah, something like that |
| 17:20.43 | claymore | understood, just trying to find the logical point in which to plan to so I am not re-creating work :/ |
| 17:20.52 | brlcad | though longs aren't probably going to be long enough for a UUID |
| 17:21.26 | brlcad | and UUID's are possibly/probably the way to go -- not that they'd get exposed at the GS level though |
| 17:21.52 | claymore | ... why not at the GS level? |
| 17:22.19 | claymore | oh, when I say long, I am referring to an int64 (sorry) |
| 17:23.55 | claymore | I am thinking that 18,446,744,073,709,551,615 unique peices of geometry should be enough.... don't you? |
| 17:24.32 | brlcad | one of the problems i'm hoping to resolve with the new geometry interfaces is having a unified handle system without having the problems of id->name mappings |
| 17:25.07 | brlcad | the difference between uuid's and urls and what they imply on referencing as a system of content management |
| 17:26.22 | claymore | not sure what you are trying to say besides: each geometry bit needs to be able to be universally and uniquely identified.... |
| 17:26.52 | brlcad | claymore: perhaps, but UUID's are 128-bit -- even less chance for collision and can be used as auto-generated hashes |
| 17:27.16 | brlcad | claymore: yeah, I'm saying that -- but there are ways you can do that |
| 17:27.28 | brlcad | take for example how regions are presently identified |
| 17:27.45 | brlcad | there is an integer that is attached to an object |
| 17:28.14 | claymore | What did you have in mind for the uuid control? Centralized worldwide server? or will the UUID's only be Unique and Universal inside the bounds of the an SVN store? |
| 17:28.16 | brlcad | that integer is then reported by our engine and referenced by the analysis codes to identify objects |
| 17:29.29 | claymore | stares in horror at his use of ingrish. |
| 17:29.31 | brlcad | don't need/want a centralized server for uuid's -- there are plenty of algorithms that allow for distributed ID generation |
| 17:31.31 | brlcad | even if you used purely random generation, the chance for collision is something on the order of 2^122 probability |
| 17:31.39 | claymore | Okay, back to my question of "why wouldn't the uuid be exposed at the GS level?" I don't see how it couldn't be exposed. If we are going to not want any ID<->Name mappings, then aren't we going to use the uuid as the sole means of object Lookup and Identification? |
| 17:31.56 | claymore | those are good odds ;) |
| 17:32.20 | brlcad | pretty damn good odds, and if there is a conflict, you'd probably know about it :) |
| 17:32.26 | brlcad | and you could just ask for another |
| 17:32.54 | brlcad | or you'd be just as likely to never run into the duplicate |
| 17:33.33 | brlcad | right, we'd either have to solely use UUID's as the sole means (when just isn't user friendly) or use the name as the sole means (which I'm much more inclined to sort out) |
| 17:34.27 | brlcad | sorting out a global resource identifier that localizes and can map 1-1 with a UUID on the backend (but only on the backend, e.g. svn-level) |
| 17:34.51 | claymore | Why not have the code use the UUID as the sole means while any User Interactive aspect just calls the MyGeoObject.getName() function and displays the string? |
| 17:35.24 | brlcad | that's entirely possible .. just less than ideal |
| 17:35.35 | brlcad | i mean it's the same problem of region idents now |
| 17:35.40 | brlcad | they were meant to be used that way |
| 17:35.43 | brlcad | but they're not |
| 17:35.59 | claymore | But region id's are not unique.... |
| 17:36.07 | brlcad | they crept into common use through most tools, exposed everywhere through the ui's |
| 17:36.08 | claymore | so, I think thats a different case. |
| 17:36.55 | brlcad | it is a different case, but the fact that there's a non 1-1 mapping is part of the problem |
| 17:37.40 | claymore | In existing BRLCAD databases, the string Name is unique, but the Region ID isn't. I am proposing that each bit of geometry has a UUID as its 'global' identifier and the Name is just an attribute to be accessed whenever needed. |
| 17:37.50 | brlcad | if the 1-1 problem is taken care of, then there's a lot less incentive for ui creeping |
| 17:38.55 | claymore | just to understand: the 1-1 problem is: We can have to things named 'Bolt' but with different UUIDs. |
| 17:39.10 | brlcad | right |
| 17:39.53 | brlcad | and I get what you're suggesting -- that's certainly doable, but it doesn't address the problem and has a lot to be desired for data management |
| 17:40.05 | claymore | Further: From a user perspective, the only way to ditinguish between both 'Bolt's is to look at the UUID... and thats the 'creep' you are speaking of? |
| 17:40.15 | brlcad | all I'm suggesting that'd be different, actually is a name that includes context so that the names are also unique |
| 17:40.41 | brlcad | right, that'd be one way |
| 17:40.48 | brlcad | there are other ways for that uuid to creep in |
| 17:41.28 | brlcad | but then if you can make the "name" actually include context (think URL context or namespace context in code) then you have a 1-1 mapping |
| 17:41.52 | claymore | Hrm, what about this: |
| 17:41.54 | brlcad | and possible don't even need the uuid, but it's a really efficient hash |
| 17:42.53 | claymore | Each and every peice of geometry will exist stand alone, but sorted into categories and subcategories. Think of a large parts wherehouse. |
| 17:44.47 | claymore | THe next werehouse over contains lots of 'parts lists' that refer to the individual parts in the first werehouse |
| 17:45.37 | claymore | so, a 'bolt' isnt a bolt, but rather: '/hardware/faseners/9.16th/3in/aluminum/bolt.g' |
| 17:46.08 | brlcad | that's exactly the url context I was referring to :) |
| 17:46.27 | claymore | well then.... GOOD IDEA ;) |
| 17:46.48 | brlcad | there are still problems to be solved with that, though |
| 17:47.02 | claymore | doesn't like the amount of effort it will take to populate the initial parts werehouse :/ |
| 17:47.02 | brlcad | uniqueness guarantees are a problem, but potentially minimized |
| 17:47.32 | claymore | problems like? |
| 17:50.23 | brlcad | well that works well for stuff that gets organized as such down the road, but for uniqueness you still want to be able to distinguish between my bolt and your bolt |
| 17:51.01 | brlcad | or even at a very basic level -- I make a sphere, you make a sphere -- how can I refer to one vs the other (and potentially still call them both 'sph') |
| 17:52.10 | brlcad | that's where the rest of a URL comes into the picture, there's an implicit username, working host, and port that are part of every url |
| 17:52.16 | claymore | but if each object that is checked into the parts werehouse is issued a UUID, then shouldn't that take care of the 'my /hardware/faseners/9.16th/3in/aluminum/bolt.g' vs 'your /hardware/faseners/9.16th/3in/aluminum/bolt.g' ? |
| 17:53.04 | brlcad | that would, but then it's not 1-1 and you are back to the same problem of having an insufficient context to distinguish objects |
| 17:55.49 | claymore | So, to capture yor thoughts, you are ideally thinking that a GeoObject will have a UUID for speed of lookup AND a UUname for easy human identification? |
| 17:55.51 | brlcad | it's not a huge issue, the problem has been pretty much solved for distributed cms and distributed scm's |
| 17:56.12 | brlcad | yeah, basically |
| 17:57.04 | claymore | Just to re-inforce my understanding.... |
| 17:57.56 | brlcad | even if only a portion of the UUname is displayed most of the time (e.g. "bolt" instead of "cad://loman@fe80::21b:63ff:fe03:3cdf%en1/hardware/faseners/9.16th/3in/aluminum/bolt") |
| 17:59.25 | claymore | Okay, I understand that. But how/where will the svn side look when its all checked in? Where will the username and host be stored? |
| 18:00.25 | claymore | in a /hardware/faseners/9.16th/3in/aluminum/versions.file' ? |
| 18:05.52 | brlcad | that's all TBD, but the UUID could be useful there |
| 18:06.13 | brlcad | e.g. using a non-hierarchical or simple two-level hierarchy instead of having the entire hierarchy on disk as a hierarchy (because it's technically not a hierarchy, it's a graph) |
| 18:07.57 | brlcad | I think that'll be more apparent once we start hooking in the svn libs |
| 18:09.15 | claymore | Hrm, okay. Got time for more Brain picking? |
| 18:10.50 | brlcad | is just coding, been coding non-stop since friday |
| 18:11.16 | brlcad | unfortunately in a non-compile state that entire time, or there would have been dozens of commits .. but just about to start the flow back up :) |
| 18:12.20 | claymore | far be it for me to slow your roll, but I'll keep firing Q's then ;) |
| 18:12.55 | brlcad | sings, "it's a small world" .. http://www.flickr.com/photos/36383814@N00/2989996039/sizes/o/in/pool-930035@N21/ |
| 18:15.37 | claymore | I see two troublemakers.... |
| 18:16.20 | louipc | wow that's trippy |
| 18:16.58 | claymore | actually feels like throwing up now. |
| 18:18.02 | claymore | not enough chicks imo. |
| 18:18.11 | brlcad | indeed |
| 18:18.16 | brlcad | http://www.flickr.com/photos/halostatue/2996087302/sizes/o/in/pool-930035@N21/ |
| 18:18.18 | claymore | wonders when he gets to go to a conference..... |
| 18:18.47 | brlcad | http://www.flickr.com/photos/halostatue/2996023060/sizes/o/in/pool-930035@N21/ |
| 18:20.18 | claymore | well hell, did you all do anything else besides take pictures?! |
| 18:22.01 | claymore | brlcad: where was that held? |
| 18:24.21 | brlcad | at the googleplex |
| 18:24.32 | brlcad | mountain view, CA |
| 18:24.53 | brlcad | there are a bunch of other pictures on flickr from others |
| 18:25.30 | brlcad | http://www.flickr.com/photos/tags/googlesummerofcode/ |
| 18:26.28 | brlcad | there are other better tags, but that's a jumping point |
| 18:28.17 | brlcad | http://www.flickr.com/groups/930035@N21/ |
| 18:29.05 | claymore | Looks like fun. Big of a sausage fest, but still fun :P |
| 18:29.16 | claymore | big = bit. |
| 18:29.35 | brlcad | yeah, huge sausage fest |
| 18:30.39 | brlcad | actually above industry average .. I think it was quoted as around 6% at the summit, but average for OSS is something like 2.5% |
| 18:31.27 | louipc | more guys into open source? |
| 18:31.40 | brlcad | yeah, a lot more |
| 18:31.55 | brlcad | average for CS is in the low teens iirc |
| 18:37.38 | *** join/#brlcad MB3 (i=Matthew@whitecalf.net) | |
| 18:37.42 | claymore | brlcad: Back to the GS: To simplify things, would making the .g file name the same as the object in it be a smart thing to do? aka Bolt.g has /Bolt.s inside it? |
| 18:39.05 | ``Erik_ | *burp* |
| 18:41.37 | brlcad | claymore: hm, why does that matter? :) |
| 18:42.19 | claymore | You're right. If we are going to do it stupid, we're going to do it MY WAY. MUWAHAHAHA. |
| 18:43.03 | claymore | Also, how are we going to represent combinations and regions? Text files? |
| 18:44.01 | brlcad | objects like all others, they way they presently are |
| 18:44.36 | claymore | I ment how in the svn repository? |
| 18:44.44 | brlcad | does too :) |
| 18:45.26 | brlcad | they have most of the same requirements as any other objects |
| 18:45.37 | claymore | so, a region will be its own .g, with no geometry in it? If thats the case, how do we link the Region members to the geometry, via the UUID or the UUName? |
| 18:47.03 | brlcad | it is "geometry", just potentially without an evaluated form (or maybe it does exist) |
| 18:47.56 | brlcad | they way it presently works is via locally scoped (file-scoped) name references -- that would have to change to a UUName |
| 18:48.45 | claymore | Will the current character-rules allow us to use all the characters in the 'url' in an BRL-CAD object name? |
| 18:50.09 | brlcad | oh, there may be some things that need slight changing, but there aren't any at the moment that jump out as being a problem |
| 18:51.30 | claymore | Okay. Now when it comes to the svn 'heirarchy' were you saying that there shouldn't be a heirarchy? I got confused with what you were saying. |
| 18:52.12 | brlcad | they get stored as plan c-strings, so pretty much anything goes at the storage level -- it'd only be places in the processing that might need to be changed |
| 18:52.28 | *** join/#brlcad elite01 (n=omg@unaffiliated/elite01) | |
| 18:52.50 | brlcad | there isn't exactly a geoemtry hierarchy, so representing geometry hierarchically in the revision store is problematic |
| 18:53.28 | brlcad | if we required a filestore that supported hard links of directories, that might be possible, or if we stash some form of soft links it might work |
| 18:53.47 | claymore | soft link? |
| 18:53.54 | brlcad | we talk about it as a hierarchy, but it's really an acyclic graph |
| 18:55.21 | claymore | 'what' is a dag? |
| 18:55.26 | brlcad | soft links are probably the way to go, just because it'll be really cool to check out entire subtree categories of geometry .. but it'll be tricky |
| 18:55.47 | brlcad | hm? |
| 18:56.00 | brlcad | directed acyclic graph .. |
| 18:56.09 | claymore | thinking heirarchially (is that a word?): |
| 18:56.23 | brlcad | http://en.wikipedia.org/wiki/Directed_acyclic_graph |
| 18:56.32 | claymore | I am seeing two top level groups: /parts and /models |
| 18:56.59 | claymore | inside parts are mere organizational subdirectories... as many as are needed. |
| 18:57.16 | claymore | at the bottom level of the /parts 'tree' are the actual .g files. |
| 18:57.29 | claymore | and all the vairous versions of individual .g files. |
| 18:57.37 | brlcad | the line between parts and models is really context-driven |
| 18:57.44 | claymore | exactly. |
| 18:57.59 | mafm | I go home, take care |
| 18:58.56 | brlcad | for one domain, it's one level, for another it's entirely different -- so I'm really not inclined to say "that line is here" in the geometry or even to prescribe an organization -- that can be up to users to a large extent |
| 18:59.26 | claymore | now inside '/models' are all the subdirectorys to organize however the 'company in question' wants to organize it. |
| 18:59.28 | brlcad | from a geometry management perspective, the issues worth tracking are when something goes from being a shape to representing something solid |
| 18:59.48 | brlcad | and whether the geometry is fully-resolved, fully-constrained, etc |
| 19:01.44 | claymore | the problem is, I see a 'chicken or the egg' scenario here. We can't fully abstract the data store methodolgy. There has to be some standards set down. |
| 19:02.19 | brlcad | "We can't fully abstract the data store methodolgy" .. means what? |
| 19:02.29 | brlcad | we're using a fully abstracted data store for the revision control |
| 19:02.56 | brlcad | so by default that would extend to us, we only constrain it on our end via what we support or don't support |
| 19:03.05 | claymore | is thinking... |
| 19:04.48 | claymore | Okay, Understanding that SVN will do whatever we want... |
| 19:05.24 | claymore | and that we intend to store Combination.g's Region.g's and Solid.g's |
| 19:05.46 | claymore | in what ever heirarchy we want. |
| 19:05.48 | brlcad | don't think of them in that regard -- they're just "objects" |
| 19:05.55 | brlcad | we have geometry objects and non-geometry objects |
| 19:06.30 | brlcad | those objects become files (or maybe directories) in the revision store |
| 19:07.14 | brlcad | but yeah, any hierarchy or non-hierarhy we want -- I mean we could store absolutely everything in one massive .g file, all revisions, all data, and that would actually work |
| 19:07.29 | brlcad | it's just unclean and would be ill-constructed (particularly for revision tracking) |
| 19:07.42 | claymore | BrlcadObj is the abstract then. GeoObj isa BrlcadObj, NonGeoObj isa BrlcadObj, Comb isa GeoObj, etc, etc... |
| 19:08.35 | brlcad | s/Brlcad/Database/ I believe is how it's been referred to thusfar |
| 19:08.54 | brlcad | but yeah, sorta |
| 19:09.12 | brlcad | that's where a lot of that is already sorted out (or at least should be sorted out) on the GE side of things |
| 19:09.13 | claymore | ' s/Brlcad/Database/' = ??? |
| 19:09.31 | brlcad | ah, s/// is a substitution pattern :) |
| 19:09.42 | brlcad | substitute this for that |
| 19:10.03 | claymore | you just lost me. |
| 19:10.07 | brlcad | echo "substitute this for that" | sed 's/this/that/' |
| 19:10.12 | brlcad | substitute that for that |
| 19:10.31 | claymore | got that, just failing to see how it applied :/ |
| 19:10.58 | brlcad | common ircism -- means referring to some previous statement, apply the replacement |
| 19:11.20 | ``Erik_ | vi ftw |
| 19:11.30 | claymore | is fixing the train of thought derailment in is head.... one moment please :) |
| 19:11.33 | brlcad | your statement in that case -- they've been referred to as DatabaseObject's |
| 19:12.00 | claymore | who reffered to them as that? |
| 19:12.01 | brlcad | there's little value in using our name over saying what we think it is |
| 19:12.10 | brlcad | librt refers to them as that |
| 19:12.47 | claymore | ah, okay. |
| 19:12.56 | brlcad | jbrlcad does as well, don't recall whether daniel preserved that |
| 19:13.05 | claymore | where is daniels work? |
| 19:13.56 | brlcad | just saying from a nomenclature perspective, really should avoid pronouns in the name where they describe a more general concept |
| 19:14.42 | brlcad | that's a general point of rule for any system really, they usually end up being turds or opaque objects an external viewer |
| 19:14.47 | ``Erik_ | class Thing :: Stuff { |
| 19:14.54 | brlcad | e.g. our few "MUVES" routines in librt.. very turdish |
| 19:15.21 | brlcad | there is an underlying concept that they represent, that should have been used to name them instead of "the way those guys do it" |
| 19:16.57 | brlcad | thinks he should push a tarball before merging his changes |
| 19:17.08 | claymore | okay, back on track: Pertaining to the svn store, if all the combination and region objects contain references to other UUNames (aka fully qualified paths) then is it still a dag? |
| 19:17.28 | claymore | reword: |
| 19:17.39 | claymore | okay, back on track: Pertaining to the svn store, if all the combination and region objects contain references to other objects via UUNames (aka fully qualified paths) then is it still a dag? |
| 19:18.29 | brlcad | yep, it still represents the same thing |
| 19:19.34 | claymore | recap: Svn lookup should be via the UUName but inmemory referencing should be via the UUID for speed? |
| 19:19.56 | brlcad | CSG construction is (usually) inherintly described by a DAG, when can be restructured or displayed as a tree, even a binary tree -- but they're non-unique nodes |
| 19:21.12 | brlcad | probably, but i don't think that's a decision that has to be made now really |
| 19:21.19 | brlcad | just more designing it such that the user never has to see/know that there's a UUID as a constraint |
| 19:22.02 | brlcad | solving local naming (i.e. UUnames) for the usability aspects |
| 19:22.22 | brlcad | and then using UUIDs where it makes sense (for performance or ease of management, etc) |
| 19:24.18 | claymore | where is Daniels GE work? |
| 19:24.29 | brlcad | he checked it in |
| 19:25.06 | claymore | brlcad, rt^3 ? |
| 19:25.11 | brlcad | yes |
| 19:27.26 | claymore | just not used to the layout of directories yet... difficult to see where one aspect starts and the other stops.... |
| 19:28.21 | brlcad | it's not cleaned up yet, it's rather lacking unification |
| 19:29.53 | brlcad | it's common "nibm"itiz .. everyone that's been committing has been ignoring what everyone else does |
| 19:36.50 | claymore | needs caffine..... |
| 19:40.03 | claymore | In relation to the GS: Could you compare/contrast a single proces, multithreaded approach to a multiprocess approach? |
| 19:41.27 | brlcad | for what we're doing, the difference is pretty insignficant (and if either is done well, it becomes even less important) |
| 19:41.59 | brlcad | multiprocess is easier to stab up on *nix platforms, but interprocess communication is a pita |
| 19:42.54 | brlcad | multithreaded is easier to intercommunicate if needed and better for portability, but can quickly get mired in deadlock and obscure bugs |
| 19:47.00 | brlcad | pervasive multithreaded is usually *very* hard to do well and even harder to maintain, high-level parallelism is usually a lot easier to manage over a long haul |
| 19:49.03 | claymore | if you had a choice, whats yoru pick? |
| 19:55.03 | brlcad | high-level parallelism where it's useful, where you have fairly independent tasks |
| 19:56.04 | brlcad | if it's high-level, it doesn't really matter if you use threads or forked processes |
| 19:56.29 | brlcad | e.g. bu_parallel is meant for such a level of parallelism during ray-tracing |
| 19:57.08 | brlcad | the backend implementation uses both threads and procs, depending on the platform, performance, simplicity, etc |
| 20:07.23 | CIA-24 | BRL-CAD: 03bob1961 * r33108 10/brlcad/trunk/src/libtclcad/ged_obj.c: Turn init routines for the older tcl interfaces back on for now. |
| 20:20.58 | claymore | what is the advantage to having both db internal and db external structs? |
| 20:22.37 | CIA-24 | BRL-CAD: 03brlcad * r33109 10/brlcad/trunk/src/libgcv/: ignore generated files/dirs |
| 20:23.55 | brlcad | external is fully serialized, 1-1 mapping with disk data |
| 20:24.30 | brlcad | internal is uncracked just enough to serve as an object directory so you can see what is on disk |
| 20:25.00 | brlcad | big impact on performance |
| 20:25.00 | claymore | so External is a 'bookmark' of sorts? |
| 20:25.15 | brlcad | mm, doesn't sound right |
| 20:25.28 | brlcad | more of an opaque bag of bytes |
| 20:25.43 | claymore | can a dbExternal write to disk? |
| 20:26.05 | brlcad | i don't know what you're looking at |
| 20:26.25 | brlcad | in general for librt, though, a db_external is (exactly) what is written to disk |
| 20:26.46 | claymore | I am correlating jBrlcad with brlcad |
| 20:27.25 | brlcad | it only correlates with (a small portion) of librt, but okay :) |
| 20:27.53 | claymore | So in an OO setting, a DB_external *could* write itself to disk, but in straight C, something writes the the db_external to disk. |
| 20:28.08 | brlcad | right |
| 20:28.34 | brlcad | librt being procedural and data-driven, there are structures and collections of routines that work on those structures and go to/from other structures |
| 20:28.53 | brlcad | so there are a slew of routines that deal with db_externals .. and another set that deal with db_internals |
| 20:30.39 | claymore | I am just wondering, in an OO setting like jBrlcad, wouldn't it make sense to combine db_internals and db_externals? They are very close to being the same.... |
| 20:33.29 | brlcad | they're just as close to being the same on the procedural side |
| 20:33.38 | brlcad | being OO doesn't change that one bit |
| 20:34.31 | claymore | okay.. regardless, wouldn't it simplifiy things a bit? |
| 20:34.54 | brlcad | removing functionality usually does |
| 20:35.24 | claymore | how would merging the two structs remove functionality? |
| 20:36.31 | brlcad | well, let me ask you -- why do you suppose the effort would have been taken to separate them out in the first place? |
| 20:38.05 | claymore | I don't know, thats why I am asking you. They could have been seperate by design from the begining and have just never been refactored due to time required... |
| 20:39.11 | brlcad | nah, v5 databases are the fifth major refactoring of the geometry I/O layer |
| 20:39.44 | brlcad | the performance impact is really substantial, you only unpack exactly what is needed when you need it |
| 20:40.40 | claymore | So, at any given time, there is a db_internal instance and a db_external instance for every object in the db? |
| 20:40.41 | brlcad | the alternate is usually unpacking everything or storing data unserialized |
| 20:41.26 | brlcad | no, internals only if they're actively being used for something |
| 20:42.04 | claymore | ah, now *that* makes sense. thanks ;) |
| 20:42.19 | brlcad | externals are the pointers to the disk records |
| 20:42.52 | brlcad | and can actually be the exact bytes on disk, you could memory map a file, point some pointers to the data, and they'll be valid externals |
| 20:45.34 | claymore | has thought/learned himself into a headache. Time for home. |
| 20:45.37 | claymore | lata |
| 20:45.42 | brlcad | cya! |
| 20:54.18 | starseeker | brlcad: Are you building a release tarball? |
| 20:54.35 | starseeker | doesn't know if he should commit more man1 pages right now... |
| 21:01.50 | ``Erik_ | three hundred forty undecillion two hundred eighty-two decillion three hundred sixty-six nonillion nine hundred twenty octillion nine hundred thirty-eight septillion four hundred sixty-three sextillion four hundred sixty-three quintillion three hundred seventy-four quadrillion six hundred seven trillion four hundred thirty-one billion seven hundred sixty-eight million two hundred eleven thousand four hundred and fifty-six is sufficient, |
| 21:02.17 | starseeker | sufficient what? hard disk space? |
| 21:02.30 | ``Erik_ | unique pieces of geometry |
| 21:02.36 | starseeker | ah |
| 21:05.44 | *** join/#brlcad clock_ (n=clock@77-56-69-135.dclient.hispeed.ch) | |
| 21:16.23 | brlcad | starseeker: trying to |
| 21:16.27 | brlcad | doing testing now |
| 21:18.31 | starseeker | OK - should I hold commits for a bit? |
| 21:19.59 | CIA-24 | BRL-CAD: 03brlcad * r33110 10/brlcad/trunk/src/ (conv/dxf/ libgcv/): more ignores |
| 21:20.34 | brlcad | starseeker: ideally |
| 21:20.36 | CIA-24 | BRL-CAD: 03brlcad * r33111 10/brlcad/trunk/src/proc-db/: ignore metaball product |
| 21:20.41 | starseeker | ok |
| 21:20.45 | starseeker | will do |
| 21:20.47 | brlcad | unless they're cleanup/fixes |
| 21:20.55 | starseeker | did you suck in bob's g_qa changes? |
| 21:21.11 | brlcad | yeah :/ |
| 21:21.15 | brlcad | had to start all over |
| 21:21.41 | starseeker | that should probably be a NEWS item unless you want to back up to the revision before that |
| 21:21.51 | starseeker | apparently he ported it to Windows |
| 21:22.30 | CIA-24 | BRL-CAD: 03brlcad * r33112 10/brlcad/trunk/src/other/tkhtml3/: ignore Makefile |
| 21:22.57 | brlcad | depends if the tests pass |
| 21:45.17 | brlcad | aaand, fail |
| 21:45.23 | brlcad | gqa crashes |
| 21:45.28 | brlcad | fails basic regression test |
| 22:13.36 | *** join/#brlcad Bariton (n=Bary@p5B14FC70.dip.t-dialin.net) | |
| 22:15.40 | brlcad | sighs |
| 22:43.05 | CIA-24 | BRL-CAD: 03brlcad * r33113 10/brlcad/trunk/ (18 files in 9 dirs): revert the g_qa port to windows and addition to g_qa until after this release (revert r33107). it's crashing and infinite looping on at least Mac and Linux (and the regression tests are epic fail). |
| 23:03.54 | ``Erik_ | http://fc47.deviantart.com/fs14/f/2007/005/e/0/The_Simpsonzu_by_spacecoyote.jpg O.o |
| 23:11.44 | ``Erik | do we guarantee acyclicity of the graph? O.o |
| 23:38.05 | CIA-24 | BRL-CAD: 03brlcad * r33114 10/brlcad/trunk/src/librt/wdb.c: wdb_fflush is unnecessary. all db io operations are automatically flushed all the time after every db_write and during db_close. |
| 23:39.34 | ``Erik_ | poo |
