| 00:33.06 | *** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net) | |
| 01:15.35 | *** join/#brlcad punkrockgirl (n=Pandora@c-69-247-220-102.hsd1.mo.comcast.net) | |
| 02:08.53 | *** join/#brlcad Ralith_ (n=ralith@216.162.199.202) | |
| 02:40.36 | starseeker | gets annoyed and runs MeshLab under wine |
| 02:42.13 | Ralith | heh |
| 03:28.25 | starseeker | filed bug report of crash, although I may have caught their svn trunk in a state of flux |
| 03:29.16 | starseeker | gets more interested the more he sees of Meshlab... |
| 03:29.35 | starseeker | GPL, so can't be tied into BRL-CAD directly, but may be a useful companion program |
| 03:29.42 | starseeker | on the mesh side at least |
| 03:41.27 | *** join/#brlcad SWPadnos_ (n=Me@dsl107.esjtvtli.sover.net) | |
| 03:48.33 | starseeker | erm. ls of the pnts test case is crashing because the rt_functab[id].ft_describe being called at wdb_obj.c 9396 is set to 0 |
| 03:48.38 | starseeker | does clean rebuild |
| 03:48.44 | starseeker | that can't be right |
| 03:48.49 | starseeker | er, l not ls |
| 04:11.57 | starseeker | Ah, HA - http://bzflag.bz/~starseeker/meshlab.png |
| 04:12.22 | starseeker | what a difference a few days makes |
| 04:12.27 | starseeker | (in revision history) |
| 04:26.00 | starseeker | really should get back to automake, but is for some reason possessed by a fit of temporary interest in the image and point cloud/mesh aspects of all this... |
| 05:11.28 | CIA-62 | BRL-CAD: 03homovulgaris * r33158 10/brlcad/trunk/src/libpc/pcMathGrammar.h: Different closures for MathVM expressions |
| 06:31.58 | starseeker | OK, clean rebuild of latest trunk on gentoo, running l on the point object causes a seg fault |
| 06:32.33 | starseeker | grr |
| 06:32.38 | starseeker | sleeps on it |
| 07:00.11 | CIA-62 | BRL-CAD: 03brlcad * r33159 10/brlcad/trunk/src/libged/wdb_obj.c: prevent primitives that don't have describe() implemented from crashing. this was happening with the new point primitive. the real fix is for all primitives to define all functions, but this shouldn't crash regardless. |
| 07:52.23 | brlcad | stops coding on pnts for a bit |
| 08:36.55 | *** join/#brlcad clock_ (n=clock@84-72-91-240.dclient.hispeed.ch) | |
| 08:36.59 | *** join/#brlcad clock__ (n=clock@84-72-91-240.dclient.hispeed.ch) | |
| 11:32.52 | claymore | Mornin all. |
| 11:48.00 | claymore | brlcad: So I have been doing lots of thinking about the UUName implimentation. What about using a URI? Nearly the same thing. Well, actually, I cannot find a difference between the two concepts actually :) |
| 11:48.36 | claymore | Erik and I had a decent talk last week and he brought up a good point about potiential file system issues should we attempt to spawn too many small files. |
| 11:49.55 | claymore | So since a brlcad db file is really just another filesystem, but only 'in a can' then why not abstract the URI away from both the Computer's File system AND the brlcad File system? |
| 11:50.11 | claymore | for instance: |
| 11:50.17 | claymore | given the URI of: |
| 11:51.05 | claymore | cad://dloman@sassyhost/hardware/fasteners/bolts.g/9.16th/3inch/aluminum/dwaynesbolt/bolt01.s |
| 11:51.28 | claymore | from the actual storage aspect of it: |
| 11:51.53 | claymore | 'hardware' and 'fasteners' are directories on the computer's Filesystem |
| 11:52.11 | claymore | 'bolts.g' is a file (duh) |
| 11:52.49 | claymore | '9.16th', '3inch' and 'aluminum' are all combinations inside the db file. |
| 11:53.00 | claymore | 'dwaynesbolt' is a region (in the db file) |
| 11:53.14 | claymore | and 'bolt01.s' is a solid (in the db file) |
| 11:53.32 | claymore | BUT, as seen by the user of iBME: |
| 11:54.22 | claymore | 'hardware', 'fasteners', 'bolts.g', '9.16th', '3inch' and 'aluminum' are all combinations. |
| 11:54.30 | claymore | 'dwaynesbolt' is a region. |
| 11:54.44 | claymore | > and 'bolt01.s' is a solid . |
| 11:55.47 | claymore | Note that the 'bolts.g' need not have the .g extention. I just put it there to make it obvious where the switch from OS-FS to BRLCAD-DB occured. |
| 11:56.36 | claymore | This would allow the admin of a given iBME installation to place the 'FS-transition point' anywhere in the heirarchy of storage on their system. |
| 11:57.47 | claymore | this should address the problems of: 1) Too many small files will eat up the inodes too fast. 2) Fewer ginormous files might impact performance and be the source of more SVN conflicts |
| 11:58.03 | claymore | breaths finally. |
| 11:58.28 | claymore | Comments? ;) |
| 12:08.10 | *** join/#brlcad elite01 (n=omg@unaffiliated/elite01) | |
| 12:24.54 | *** join/#brlcad geekgirl (i=Pandora@c-69-247-220-102.hsd1.mo.comcast.net) | |
| 13:10.42 | *** join/#brlcad mafm (n=mafm@elnet-111.lip.pt) | |
| 13:12.13 | mafm | hi |
| 13:12.29 | claymore | hai! |
| 13:45.37 | brlcad | claymore: using a URI isn't much different than what I was talking about last week about using a URL (as a URL is a URI) |
| 13:46.05 | claymore | righto. Was thinking of using URI in place or a UUNAME |
| 13:46.11 | claymore | in place of |
| 13:46.18 | brlcad | really don't want to get stuck in the weeds, though as both those issues are optimization issues |
| 13:46.32 | brlcad | and as the saying goes, premature optimization is the root of all evil |
| 13:47.04 | claymore | ...right, but how we look up resources is a foundation.... need to pick *something* |
| 13:47.24 | brlcad | sure, but that doesn't have anything to do with what actually happens on the data store side |
| 13:47.36 | claymore | so I picked a URI, but not necessarily a Unique uri quite yet. |
| 13:47.43 | brlcad | they could be tied together, but they certainly don't need to |
| 13:49.25 | brlcad | the only (hard) problem to be solved with using a URL (I don't see the need to use URNs at this point so we really should already be limited to URLs, URI is the superset) is uniqueness across the DAG |
| 13:50.23 | claymore | thats why I was asking about the whole 'Is a dag still a dag when its laid out like a tree, but just references other branches' |
| 13:50.41 | brlcad | or more perhaps more importantly, non-uniqueness .. how to identify that the same object is used in different contexts but also has its own context |
| 13:51.31 | claymore | I am pretty sure that how I have it laid out will be able to handle using a single object in multiple contexts. |
| 13:52.48 | claymore | thats all brlcad does now in its db is use refernces & matricies..... single object multiple contexts... |
| 13:53.05 | brlcad | referentially, it's representable by a DAG regardless of how it's encoded -- the DAG is only "broken" if you replicate data (e.g. turn it into a binary tree) |
| 13:53.43 | claymore | don't quite understand the 'replicate data' statement. |
| 13:53.45 | brlcad | sure, but the only way we get away with that now is through a file-scoped namespace |
| 13:54.37 | brlcad | we're not going to have a file-scope any more so we're either stuck implementing some scoping mechanism or finding a better uniqueness identification scheme not based on scope |
| 13:54.52 | claymore | Exactly, file scoped namespace can be synonymous to a system using truely Unique URI's....right? |
| 13:56.41 | brlcad | it's not clear what you mean by 'using truely unique URIs' -- before going down that path, do you get the difference between URIs, URLs, and URNs? |
| 13:57.04 | claymore | URI and URL yes... not familiar with URNs |
| 13:57.24 | brlcad | you can't really understand uri's without urn's :) |
| 13:58.00 | claymore | so I see. :) Yes I get the differences. |
| 13:58.02 | brlcad | they're simple -- it's sort of like the difference between your postal address and your name |
| 13:58.29 | brlcad | both urls and urns are uris |
| 13:59.13 | brlcad | uri is just "handle on something", url is "here's a location for this thing", urn is "here is the name of something" |
| 13:59.46 | claymore | Okay, so we can use URNs as what I was calling UUName, and URL's as the mechanism to look up these resources..... |
| 14:00.37 | brlcad | and the line between the two is pretty fuzzy, but for talking point purposes, urn is probably equivalent to some cad://UUID protocol, url would be how objects are located in the object store, uri is just a generic term that refers to finding something |
| 14:02.59 | brlcad | fwiw, UUID is not /path/to/some/object, UUID is http://en.wikipedia.org/wiki/UUID -- that's the thing that I was talking about that if we use them, they shouldn't be exposed anywhere |
| 14:03.19 | claymore | understood the UUID concepts. |
| 14:03.51 | brlcad | hence the discussion lending towards using a URL scheme that manages the scoping issues (but again has little/nothing to do with the implementation) |
| 14:03.57 | claymore | But the more I look over and plan things out, the less I see the need for a UUID since a good URL will give us what we need anyways... |
| 14:04.33 | brlcad | absolutely, that will be a good feature as it'd reduce complexity |
| 14:04.44 | brlcad | and I'm all about keeping things as simple as possible for starters :) |
| 14:05.00 | claymore | Sorry its taking me so long to finally come around to what you have been saying all along lol :) |
| 14:05.23 | brlcad | but I do think (for better or worse) that it probably will eventually be needed to really solve the referencing problems |
| 14:05.43 | claymore | ... what will be needed? "URL's" ? |
| 14:05.44 | brlcad | i'd be happy to be wrong on that point, though :) |
| 14:05.50 | brlcad | uuid's |
| 14:06.30 | claymore | Hrm. Guess i dont see the referencing problem then... |
| 14:08.01 | claymore | if the URL's used are truely Unique, then having any combination refer to another object is as simple as using the URL.... |
| 14:08.08 | claymore | ...and a matrix :) |
| 14:08.27 | brlcad | hm, how to describe |
| 14:08.45 | claymore | lol, slowly appreantly. |
| 14:08.54 | brlcad | you can have two unique URLs that refer to the same object in different contexts or in the same context even |
| 14:09.02 | claymore | tries to make his brain more receptive. |
| 14:10.09 | claymore | Okay, got that part... |
| 14:10.43 | brlcad | it's like how many ways can I describe your address -- there are lots of paths to get there, but for our purposes we need to know that paths /A/B/C and /D/E/C both lead to the same C for the purposes of applying operations and managing the geometry effectively |
| 14:11.12 | brlcad | and "C" is not a unique key, so we can't just use that |
| 14:12.23 | claymore | True. But here's what I thought: |
| 14:12.29 | brlcad | also don't really want to enforce a global namespace on all object names (e.g. I cannot name my sphere "sph" because there is already one 'somewhere' in the system) |
| 14:12.48 | claymore | 'c' is the object, which isn't unique. |
| 14:12.53 | brlcad | objects are initially created context-less too |
| 14:12.57 | brlcad | s/less/free/ |
| 14:13.29 | claymore | a/b/c is the URL, which IS unique and differs from all other things because a/b/c is NOT d/e/c |
| 14:13.54 | starseeker | does happy dance - got cell data converted to a mesh in Meshlab and loaded into mged as a dxf |
| 14:14.12 | claymore | gives starseeker a 'good game' |
| 14:14.19 | claymore | :) |
| 14:14.46 | starseeker | we now return you to your regularly scheduled URL lesson :-P |
| 14:15.19 | brlcad | starseeker: I applied a patch for the l crash, but haven't tested it |
| 14:15.39 | claymore | brlcad: so, having 'c' by itself really doen't mean much, because on can only refer to an object by using its URL. |
| 14:15.51 | starseeker | brlcad: works |
| 14:16.01 | brlcad | "because on can" hm? |
| 14:16.02 | starseeker | cell.s: list support unimplemented |
| 14:16.08 | brlcad | ah, one |
| 14:16.27 | claymore | laughs and points at himself. Bad engrish day... as usual. |
| 14:16.46 | starseeker | cheers engrish |
| 14:17.34 | starseeker | brlcad: unfortunately, for some reason I still don't get anything with e cell.s |
| 14:18.14 | starseeker | yet the .g is over a meg, so there's clearly something in there |
| 14:18.40 | brlcad | starseeker: hrm, you sure they're not just dots the same color as your background or something? |
| 14:19.15 | starseeker | I doubt it - I'm using my custom tanish background color |
| 14:19.22 | starseeker | tweaks just to be sure |
| 14:19.55 | starseeker | nope |
| 14:20.37 | brlcad | try a db get |
| 14:20.41 | starseeker | when I add a weight factor I get one sphere, without it I get one xyz coordinate |
| 14:20.45 | brlcad | try manually creating just two points :) |
| 14:20.58 | starseeker | seg fault |
| 14:21.04 | starseeker | on the dbget |
| 14:21.17 | brlcad | hrm, sounds like another place that needs patching |
| 14:21.21 | brlcad | ah right |
| 14:21.58 | starseeker | creating just two points, I get one sphere |
| 14:21.58 | brlcad | that calls _adjust() which probably isn't implemented |
| 14:22.18 | brlcad | and probably not protected like _describe() .. you should apply a similar fix :) |
| 14:22.31 | starseeker | ok |
| 14:22.36 | starseeker | makes note |
| 14:22.36 | brlcad | they're crashes that should only occur with incomplete primitives, but good to fix regardless |
| 14:23.09 | brlcad | did you create it interactively or as one long in line? |
| 14:23.14 | starseeker | interactively |
| 14:23.26 | brlcad | hrm |
| 14:23.31 | starseeker | claymore: sorry |
| 14:23.36 | brlcad | well no matter, I've rewritten most of that already |
| 14:23.40 | starseeker | :-) |
| 14:23.55 | claymore | no worries:) Brain Neaing Capacity warning light was on anyways. |
| 14:24.01 | starseeker | brlcad: is it OK to post screenshots with that cell data or is that a no-no? |
| 14:24.04 | claymore | Nearing |
| 14:24.32 | louipc | |
| 14:24.41 | brlcad | adding support for normals/vectors, per-point scaling, per-point colors, adds quite a bit of complexity |
| 14:24.53 | starseeker | eeep. |
| 14:24.58 | starseeker | can see how it would |
| 14:25.12 | brlcad | isn't sure what cell data you're referring to |
| 14:25.25 | starseeker | the one you bounced to me a few days ago as a points example |
| 14:25.30 | starseeker | in with the presentations |
| 14:25.51 | brlcad | the engine? |
| 14:26.12 | starseeker | don't think so - it's just a point cloud from a scan of a blackberry or some such |
| 14:26.53 | starseeker | nevermind |
| 14:26.57 | starseeker | not all that exciting |
| 14:27.00 | brlcad | I've not seen that yet, but afaik, there's nothing you have you can't show that crowd |
| 14:28.03 | starseeker | ok |
| 14:28.04 | brlcad | and if it's a phone, especially .. that's probably someone's personal phone |
| 14:28.12 | starseeker | sure |
| 14:29.19 | starseeker | moot point anyway as yet - I doubt they'd care about Meshlab screenshots |
| 14:29.25 | starseeker | needs MGED :-) |
| 14:29.35 | starseeker | I'll try again at work on the Mac |
| 14:30.08 | starseeker | speaking of which... |
| 14:30.12 | brlcad | I don't get why it wouldn't work for you -- the last revision was working before release |
| 14:30.26 | starseeker | For some reason it's never worked on this box |
| 14:30.26 | brlcad | maybe something didn't get committed, or something did that shouldn't have, dunno |
| 14:30.37 | starseeker | hasn't tested at work yet |
| 14:30.49 | brlcad | should just fix it regardless of the cause ;) |
| 14:31.03 | starseeker | probably you already have :-) |
| 14:31.08 | brlcad | implement 'l' so you can at least see the data |
| 14:31.20 | brlcad | i've not implemented l |
| 14:31.30 | starseeker | is guessing whatever walks the pnts data to draw it is just hanging up somehow on the first point |
| 14:31.36 | starseeker | right |
| 14:31.57 | starseeker | l should be easy enough |
| 14:33.21 | starseeker | hits the road and hopes the road won't hit back |
| 14:33.53 | claymore | loves pineapple... yum! |
| 14:34.11 | brlcad | does similar though with probably a lot more pitstops |
| 14:35.05 | claymore | brlcad: lee has been in twice and looked at your desk each time. Just a heads up :) |
| 14:35.50 | brlcad | claymore: okay |
| 14:55.45 | claymore | erik: you alive? |
| 15:00.32 | *** join/#brlcad Elrohir (n=kvirc@p5B14F075.dip.t-dialin.net) | |
| 15:17.02 | *** join/#brlcad Elrohir (n=kvirc@p5B14F075.dip.t-dialin.net) | |
| 15:31.10 | *** join/#brlcad Elrohir (n=kvirc@p5B14F075.dip.t-dialin.net) | |
| 16:04.52 | *** join/#brlcad ``Erik___ (i=erik@c-68-54-174-162.hsd1.md.comcast.net) | |
| 16:51.21 | ``Erik | at times, yes, 'sup? |
| 17:15.53 | claymore | Just havent heard anything from ya in a bit. |
| 17:43.57 | ``Erik | was down sick :/ fortunately, rdo+holiday covered me on that *sigh* still feeling like crap, but far less bad |
| 17:44.32 | claymore | well glad to hear you're feeling better then. just the standard cold? |
| 17:46.33 | ``Erik | not sure, stuffed sinus, nausea, headache, deep cough, fever, delirium, bad interplay between it all and the alcohol :( |
| 17:47.20 | claymore | hell that sounds horrid. were you well enough to at least get some good mmo time in? |
| 17:47.41 | ``Erik | no, I couldn't even be assed to reset my cable modem or dick with a 'puter |
| 17:47.59 | ``Erik | I got my new macbook monday, it's sitting on my floor halfway through the initial configuration |
| 17:48.18 | claymore | sassy :) |
| 17:49.30 | ``Erik | and someone scrapped my fleet, plundered the tr's and got the derbs while I was down, effin' lame |
| 17:49.49 | claymore | whoa... which planet? |
| 17:50.04 | ``Erik | one in 65, I'll post br when I'm caught up on some stuff |
| 17:50.12 | claymore | kk. |
| 17:50.36 | claymore | there is a serious buildup of 7E in E37:44, so watch out. That 'nick' guy is pulling about about 1.6 mil. |
| 17:50.57 | ``Erik | I'd moved fighters and stuff off to my newest for growth cover intending to cycle them back up quickly, but I stopped focusing on it all :( |
| 17:53.17 | claymore | yeah, I have lost a bit of focus also. Mostly simming now ;) |
| 18:09.05 | CIA-62 | BRL-CAD: 03davidloman * r33160 10/rt^3/trunk/src/geometryService/cpp/docs/ (BME.eap GS.eap): Continuing Architecture Work. |
| 20:19.34 | mafm | I go home, see you! |
| 20:57.03 | *** join/#brlcad Elrohir (n=kvirc@p5B14F075.dip.t-dialin.net) | |
| 21:29.11 | *** join/#brlcad ``Erik_ (n=erik@ftp.brlcad.org) | |
| 21:42.39 | *** join/#brlcad geocalc (n=geocalc@91-171-205-31.rev.libertysurf.net) [NETSPLIT VICTIM] | |
| 21:46.48 | *** join/#brlcad AFK-claymore (n=claymore@bz.bzflag.bz) | |
| 21:46.48 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) | |
| 21:46.48 | *** join/#brlcad yukonbob (i=1000@s142-179-54-198.bc.hsia.telus.net) | |
| 21:46.48 | *** join/#brlcad starseeker (n=starseek@bz.bzflag.bz) | |
| 21:46.56 | *** join/#brlcad ChanServ (ChanServ@services.) | |
| 21:46.56 | *** mode/#brlcad [+o ChanServ] by irc.freenode.net | |
| 22:56.15 | *** join/#brlcad ``Erik___ (i=erik@c-68-54-174-162.hsd1.md.comcast.net) | |
| 23:58.33 | CIA-62 | BRL-CAD: 03brlcad * r33161 10/brlcad/trunk/src/util/Makefile.am: old automake can't deal with per-product CPPFLAGS so make bombardier use CFLAGS instead |
