| 00:00.36 | ``Erik_ | well, I've poked code here and there, but my gf kinda ruined me :D *duck* |
| 00:01.13 | punkrockgirl | no, you cant play wotlk until you do some other things... |
| 00:01.23 | punkrockgirl | and um, i ruined you? |
| 00:01.28 | punkrockgirl | :( |
| 00:01.36 | ``Erik_ | :D |
| 00:01.40 | punkrockgirl | :~( |
| 00:06.50 | ``Erik_ | lovely |
| 01:01.49 | brlcad | bah, you're an independently reasoning being -- your actions are your own doing, personal responsibility for ones own actions and all that :) |
| 01:03.10 | brlcad | you could be productive if you wanted to be, it's at least not lack of hours in the day or someone keeping your fingers off the keyboard |
| 01:07.07 | brlcad | needs more hours and more fingers! muahaha |
| 01:26.23 | CIA-62 | BRL-CAD: 03davidloman * r33182 10/rt^3/trunk/src/geometryService/cpp/docs/BME.eap: Continuing Architecture Work. |
| 01:26.38 | ``Erik_ | more hours, definitely, d'no about more fingers |
| 01:27.10 | ``Erik_ | I think I was able to get about 2 hours of coding done today, the rest was rife with special requests, questions, etc |
| 01:27.35 | ``Erik_ | needs to build himself a secret office |
| 01:30.43 | ``Erik_ | now that's irritating |
| 01:31.00 | ``Erik_ | leopard has lost rosetta? |
| 01:36.54 | ``Erik_ | hrm, probably just weird rsync behavior |
| 02:23.45 | punkrockgirl | a secret office in my basement? ;) |
| 04:31.42 | yukonbob | hello, cadheads |
| 07:10.09 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) |
| 07:42.28 | *** join/#brlcad louipc_ (n=louipc@76-10-163-20.dsl.teksavvy.com) |
| 07:54.34 | *** join/#brlcad elite01 (n=omg@unaffiliated/elite01) |
| 08:20.06 | *** join/#brlcad clock_ (n=clock@84-72-91-240.dclient.hispeed.ch) |
| 09:27.32 | *** join/#brlcad Elrohir (n=kvirc@p5B14F065.dip.t-dialin.net) |
| 10:01.38 | *** join/#brlcad archivist_emc (n=archivis@host81-149-119-172.in-addr.btopenworld.com) |
| 10:11.47 | *** join/#brlcad Elrohir (n=kvirc@p5B14F065.dip.t-dialin.net) |
| 10:25.29 | *** join/#brlcad Elrohir (n=kvirc@p5B14F065.dip.t-dialin.net) |
| 10:49.32 | *** join/#brlcad mafm (n=mafm@elnet-111.lip.pt) |
| 11:27.59 | dloman | norning all |
| 11:35.32 | claymore | mafm: Hey, did you just check in some changes to /rt^3/src/coreInterface/ ? |
| 11:39.21 | CIA-62 | BRL-CAD: 03davidloman * r33183 10/rt^3/trunk/src/geometryService/cpp/docs/BME.eap: Continuing Architecture Work: Core 3 levels of objects defined: Geometry Engine <- Geometry Service <- iBME |
| 11:40.39 | mafm | hi |
| 11:40.45 | mafm | no claymore, no idea about that |
| 11:41.01 | mafm | I never touched anything in rt3 besides src/g3d, AFAICR |
| 11:41.07 | mafm | or data related to g3d |
| 11:43.51 | claymore | is /src/g3d the prototype gui you were working on? |
| 11:50.18 | mafm | yes |
| 11:50.26 | mafm | so in rt3 I didn't touch anything else |
| 11:50.35 | claymore | I still blame you. |
| 11:50.40 | claymore | laughs |
| 11:50.44 | claymore | just kidding. |
| 11:50.50 | mafm | I did some not-completely-successful incursions in trunk, but... :) |
| 11:51.10 | claymore | trying to learn the lay of the land in rt^3 since I am prolly going to be making major changes to the structure. |
| 11:51.15 | mafm | so unless OMG I've been hax0red, no it wasn't me :D |
| 11:52.37 | claymore | since I will be doing some re-org in the near future, I want to feel out who all is actively in rt^3 so I don't step on toes. :/ |
| 11:55.10 | mafm | well, so no problem for me |
| 11:55.24 | mafm | unless you touch g3d, then I would have to kill you :) |
| 11:55.53 | claymore | rolls up his sleeves, ready to come out swinging :) |
| 11:55.54 | mafm | well, you can change that also, if you want |
| 11:56.17 | mafm | I never though much about the location |
| 11:56.45 | mafm | sean suggested in there because it was in line with the ideas in there, and was mainly independent from the rest of the code anyway |
| 11:56.59 | claymore | I will be putting up organization on the brlcad.org/wiki |
| 11:57.36 | claymore | to evoke comments that I will most likely igonre >8-) |
| 12:00.44 | claymore | ...that too was a joke. :P |
| 12:02.53 | mafm | xD |
| 12:03.05 | mafm | ignoring wiki comments in common practice anyway |
| 12:07.03 | claymore | where did you stash the Orge libraries? |
| 12:07.48 | claymore | anyone: haven't looked, but are the boost libraries in the BRLCAD src the FULL library set, or a stripped down set? |
| 12:13.21 | CIA-62 | BRL-CAD: 03davidloman * r33184 10/rt^3/trunk/src/geometryService/cpp/docs/BME.eap: (log message trimmed) |
| 12:13.21 | CIA-62 | BRL-CAD: Continuing Architecture Work (GeometryEngine Namespace): |
| 12:13.21 | CIA-62 | BRL-CAD: 1) Architected GeometryManager: provides a high level interface for retrieving, |
| 12:13.21 | CIA-62 | BRL-CAD: caching and saving Geometry. Considering a rename to ResourceManager since |
| 12:13.24 | CIA-62 | BRL-CAD: 'Geometry' no longer accurately describes ALL data types handled by |
| 12:13.26 | CIA-62 | BRL-CAD: GeometryManager. |
| 12:13.28 | CIA-62 | BRL-CAD: 2) Architected AbstractResourceSource: a fully virtual base class that |
| 12:13.33 | brlcad | yay, more detailed comments :) |
| 12:13.44 | brlcad | claymore: they're stripped down |
| 12:13.55 | brlcad | there's a boost tool that will pull the subset in use |
| 12:14.02 | claymore | knows not what you mean. ;) |
| 12:14.21 | claymore | pull it from the boost website? |
| 12:14.28 | brlcad | hm? |
| 12:15.10 | claymore | 'there's a boost tool that will pull the subset in use' I dont understand this statement. There is a tool on their website, in our src, ??? |
| 12:15.14 | brlcad | there is a tool in boost that will look at source code (that uses boost) and determine what headers exactly are needed for that code to compile |
| 12:15.45 | brlcad | and it will extract that portion of the boost headers so you can bundle them |
| 12:16.10 | claymore | This scan & extraction happens at compile time? |
| 12:16.38 | brlcad | no, this happens sometime before manually by a developer looking to figure out what portions of boost they need |
| 12:16.54 | claymore | okay, i understand. |
| 12:17.00 | brlcad | so you don't pull too much, don't include the kitchen sink, etc |
| 12:17.08 | brlcad | boost is too big to include *everything* |
| 12:17.26 | claymore | so.. .back to the original question... anyone know which portions of boost are already in our src tree? |
| 12:17.27 | brlcad | and they have a tool that determines the exact subset you need anyways |
| 12:18.12 | brlcad | erhm, we have exactly what we need -- it's not like it even exactly breaks it out by packages, it's actual header use |
| 12:18.34 | brlcad | so if you add something new that uses boost, have to rerun the tool and/or evaluate the new usage |
| 12:19.04 | brlcad | it was mostly portions of spirit in use by the constraint and parametric equation support |
| 12:19.23 | claymore | this tool: it writes a specific header for us? Or just downloads the headers we need? |
| 12:19.42 | claymore | Okay, that answers my Q. I was wondering if BoostThreads is in there already. |
| 12:19.46 | brlcad | just downloads the headers we use |
| 12:20.03 | brlcad | take a look, src/other/boost |
| 12:20.44 | brlcad | there are threading headers in there now, so maybe/probably at least a subset if not the whole thing |
| 12:21.46 | claymore | alright neat. I was wondering if I was going to need boost libs for iBME but it seems that brlcad already has it. Excellent. |
| 12:22.59 | brlcad | there's a configuration management issue there -- presently compiling rt^3 only requires a binary install (and the boost headers are treated private) |
| 12:23.39 | brlcad | so for you to use them, they either need to be installed or rt^3 build system needs to know where brlcad sources are or they need to include their own copy of (exactly) what is used |
| 12:24.38 | brlcad | my feeling would be for it to *not* rely on having both source sets around, so either installing or having a separate copy |
| 12:25.57 | *** join/#brlcad Elrohir (n=kvirc@p5B14F065.dip.t-dialin.net) |
| 12:25.58 | claymore | :/ Okay, fair enough. I figured since iBME will need the BRL-CAD source or Libs anyways, getting the boost libs from the brlcad src tree wouldn't be an issue. |
| 12:26.24 | brlcad | it needs the libs and headers |
| 12:26.39 | brlcad | which should all be available during install |
| 12:28.12 | claymore | would having the BRL-CAD libs rely on a different copy of boost than iBME create a maintenance headache later down the road? |
| 12:28.33 | brlcad | that should really help keep the two interfaces independent (so there is no C/C++ crossover) allowing the interfaces to be developed as an interface-using application (which should help shore up the interfaces being provided too) |
| 12:28.57 | brlcad | only if they're incompatibly out of sync at a binary level |
| 12:29.04 | claymore | you use the term 'interface' in what context? |
| 12:29.06 | brlcad | most of boost is compile-time static |
| 12:29.35 | claymore | takes notes about keeping things in sync. |
| 12:30.04 | brlcad | well there are the C libs, libbu, libbn, librt, etc .. that are in use by the GE and new G3D/iBME/SS (this thing is getting a lot of names) :) |
| 12:31.29 | brlcad | the chance of incompatibility is pretty low though, I wouldn't worry about it -- and if you really want to make it a non-issue, we can just have an option to install the headers we used |
| 12:32.01 | brlcad | the issue then will just be when rt^3 sources uses more than brlcad module uses and needs additions |
| 12:32.01 | claymore | As for the names, they will make sence when I get a chance to offload my info on ya. I can try to do that here in irc, but the UML pics i have help wonders. You in at a decent hour today? ;) |
| 12:33.07 | brlcad | I'm only referring to G3D vs iBME vs SS .. they all basically refer to the same thing and are just a label really |
| 12:34.44 | claymore | 'just a label'.... well kinda. I am seeing them more as elements and levels of an architecture. |
| 12:34.54 | brlcad | that's having three people name pretty much the exact same concept, not a surprise that everyone has a different one |
| 12:35.46 | claymore | for instance: GeometryEngine will be the C++ library that incorporates ged, svn, and a few other things to form the core funtionality |
| 12:36.08 | brlcad | and iBME is where it all comes together into a graphical inteface that the user interacts with, yes? :) |
| 12:36.45 | claymore | GeometryService is the runnable bin that uses the GE libs, but adds in the Session Management, Access Controls, Network link, blah blah blah blah.... |
| 12:37.02 | brlcad | no surprises there :) |
| 12:37.58 | claymore | and Integrated BrlCad Modeling Environment (iBME) is a runnable bin that has/uses a GS but adds an abstract GUI element... in this case, the first AbstractGui subclass will be g3d |
| 12:37.58 | brlcad | and I think that's a wonderful! separation of responsibilities btw ;) |
| 12:38.26 | claymore | so yeah, its a lot of names, but that makes it sound neater and thus impresses Bosses more :) |
| 12:38.35 | brlcad | i.e. where it all comes together into a graphical inteface ;) |
| 12:38.58 | claymore | right, you had it type before I did, but i couldn't bring myself to delete all my hard typing :P |
| 12:39.00 | brlcad | i'm just saying that's what g3d means/meant as well as SS too |
| 12:39.13 | claymore | oh, whats SS ? |
| 12:41.08 | brlcad | it hints at the name that I arrived at after having many years to think of a good name that caters to the marketing aspect, documentation, community, competition, connotations, .. |
| 12:41.17 | brlcad | has had a long time to think about all of this over the years |
| 12:41.44 | brlcad | not that I'm stuck on using it, I'm also not willing to unveil it before it's actually needed or can be formally documented |
| 12:42.17 | brlcad | naming something often has the tendancy of making people make (false) assumptions about the project that take years to recover from (RIVA anyone) |
| 12:42.57 | claymore | so we should call this project Fred until a few years from now? |
| 12:43.16 | claymore | thinks SS stands for SuperSexy. Just admit it. |
| 12:43.18 | brlcad | nah, iBME is a great name too, that works |
| 12:43.31 | brlcad | thinks SS is super sexy, but no doesn't stand for that :) |
| 12:44.30 | claymore | i was trying to manhandle the acronym into iBEAM, but it ended up being nearly ebonic, so i just went with iBME and will pronounce it I-Beam. |
| 12:44.46 | brlcad | even if iBME has two strong connotations (for me at least) .. BME is like EE or CE in a university context |
| 12:44.47 | claymore | besides, an Ibeam icon is super easy to do :) |
| 12:45.14 | brlcad | BME is the shorthand for biomedical engineering |
| 12:45.27 | claymore | ah, didn't know that. |
| 12:45.29 | brlcad | so everytime I see it, that is what jumps to mind :) |
| 12:46.08 | claymore | I am not stuck on it either, just you mentioned the 'integrated brlcad modeling enviornment' term once and it made sence to me. |
| 12:46.24 | brlcad | BRL-CAD M.E. sounds kinda kinky albeit kinda microsoftish too :) |
| 12:46.38 | claymore | Project iBME untill a SS-ier name can be found |
| 12:46.38 | brlcad | did I? that's funny |
| 12:46.51 | claymore | yeah, BRLCADme made me cringe. |
| 12:46.52 | brlcad | i do see it as an integrated modeling environment, so it does suit |
| 12:47.35 | brlcad | no matter what we call it, the binary will (finally) probably just be called 'brlcad' when it's worthy to have that name |
| 12:47.49 | brlcad | since that is what 99% of most new users expect |
| 12:48.25 | brlcad | but not before it's ready .. till then it can have code name(s) |
| 12:48.44 | claymore | damn them all, break the mold! Fred is the new BRLCAD so they just need to deal with it. |
| 12:48.50 | brlcad | even ss wasn't meant to be the command line, that's just a different expansion of the full title |
| 12:49.27 | claymore | SS has Nazi Connotations to me ;) |
| 12:49.34 | brlcad | something that really should cater exactly to what we do and the ways geometry is managed |
| 12:49.53 | brlcad | that's why it's not the actual name, just my version of "fred" since I've not said what it is :) |
| 12:50.12 | brlcad | though I would have thought SS had navy connotations to you :) |
| 12:50.44 | claymore | SSN baby! SS = ww2, ssn = nuklar ;) |
| 12:51.05 | brlcad | Happy Sailing on the SS BRL-CAD |
| 12:51.22 | claymore | should we have it crash after a '3 hour tour' ? |
| 12:52.04 | brlcad | and make them reboot |
| 12:52.11 | brlcad | wonders what CVN stands for |
| 12:52.31 | claymore | Carrier Vessel Nuclear |
| 12:52.42 | claymore | ;) |
| 12:52.53 | brlcad | ah |
| 12:53.13 | claymore | aka CVN-65 = USS Enterprize, aka Mobile Cherynobl |
| 12:53.43 | brlcad | notes that you shouldn't need/use html markup on the wiki outside of style decls on tables, you can use " " and/or newlines in place of br's |
| 12:54.44 | brlcad | stops chattering so he *can* make it in at a decent time for once |
| 12:55.10 | claymore | didn't know that a line starting with whitespace could be used as a newline. Defaulted on what I knew:) |
| 12:55.19 | claymore | brlcad's wiki-fu is strong. |
| 12:57.14 | claymore | have a safe trip. |
| 12:57.56 | claymore | oh, and in media wiki, multiple newlines are truncated to just one. :/ |
| 13:05.24 | mafm | damn brlcad |
| 13:05.31 | mafm | you talk too much! |
| 13:05.41 | mafm | now I have to read all the log... :P |
| 13:05.50 | claymore | sneaks out of sight. |
| 13:05.58 | mafm | claymore: OGRE & Co. at src/other |
| 13:06.42 | claymore | excellent, thanks mafm! |
| 13:07.03 | claymore | mafm: Do you have documentation on your gui design? |
| 13:10.05 | mafm | not proper documentation, no |
| 13:10.26 | mafm | it's a kind of prototype |
| 13:11.24 | mafm | in src/other I put: OGRE (3D rendering only), OIS (input libs), Mocha (helper library for RBGui), RBGui |
| 13:11.34 | claymore | did you architect your GUI so that it consists of a single 'root' object? |
| 13:11.51 | brlcad | thinks it's a successful prototype, start at least .. the only part I'm still not convinced is doing us anything useful is rbgui |
| 13:12.15 | brlcad | claymore: find main() go from there ;) |
| 13:12.23 | mafm | RBGui stalled at this point maybe not :| |
| 13:12.42 | mafm | it'll begin to be a maintainance issue |
| 13:12.47 | brlcad | there was a great poster at siggraph for a new gui toolkit |
| 13:12.55 | mafm | but I don't know if there are new alternatives yet |
| 13:13.32 | brlcad | done by the guy that worked on G3D (no, the 'other' G3D) ironically :) |
| 13:13.43 | mafm | claymore: I created a set of managers, so to speak, taking care of camera modes, creating and acessing windows, etc |
| 13:14.17 | mafm | so in example there's the camera manager, and classes for camera/input modes |
| 13:14.33 | CIA-62 | BRL-CAD: 03davidloman * r33185 10/rt^3/trunk/src/geometryService/cpp/docs/BME.eap: (log message trimmed) |
| 13:14.33 | CIA-62 | BRL-CAD: Continuing Architecture Work (GeometryService Namespace): |
| 13:14.33 | CIA-62 | BRL-CAD: 1) Created AccessManager Class stub. Will provide access controls for Sessions. |
| 13:14.33 | CIA-62 | BRL-CAD: 2) Architected SessionManager and Session classes: Will provide persistence information for remote and local connections to the GeometryService. |
| 13:14.34 | mafm | the manager takes care of switching between modes and similar tasks |
| 13:14.36 | CIA-62 | BRL-CAD: 3) Architected CommunicationsManager and AbstractPortal: Provides |
| 13:14.38 | CIA-62 | BRL-CAD: interconnectivity via multiple means. AbstractPortal is a purely virtual base |
| 13:14.40 | CIA-62 | BRL-CAD: class that will provide/mandate the essential attributes and operations required |
| 13:16.20 | claymore | mafm: so it sounds like it would be relatively easy to aggregate all those managers in to a single, simple, highlevel G3D object? |
| 13:16.37 | brlcad | also probably worth mentioning that it's presently hooked directly into libged since GS nor GE were ready, but that hooking those in are next step |
| 13:17.28 | brlcad | claymore: your java teachings are starting to show :) |
| 13:17.37 | brlcad | s/teachings/learnings/ |
| 13:17.47 | mafm | claymore: well, there's the Application class, I think that it's a kind of root object, now that I think of it |
| 13:18.15 | claymore | nah, not java teachings :P |
| 13:18.19 | mafm | because it takes care of initializing the graphics, has functions to quit, etc? |
| 13:18.43 | claymore | Basic OO abstraction techniques :( |
| 13:19.49 | claymore | mafm: I ask because in the architecture I am working up, there is a GUI object that is purely virtual, ment to be either a full abstract Base class or an Interface to implement, that all gui's coded for iBME will need to adhere to. |
| 13:20.40 | claymore | mafm: that way, it would be very easy to document the GUI API and thus, make it easy for someone to write their own GUI. |
| 13:21.03 | mafm | I guess that it could be adapted to work that way |
| 13:21.21 | brlcad | the tendency to organize everything into single-rooted hierarchies is often a tendency found with 'pure' OO design (which you find a lot of in Java) -- nothing wrong with it, just slightly different perspective as C++ is rarely implemented pure (for various reasons) |
| 13:22.36 | claymore | mafm: SO if it would be possible to seggregate the GUI aspects from the application aspects of g3d, then it would be easy to abstract the trival stuff (aka application stuff) away from your GUI, thus making everything a bit more clean and streamlined. |
| 13:23.10 | mafm | I think that all Gui-like stuff stays in Gui-named files and classes |
| 13:23.14 | claymore | brlcad: Sure is... BUT thats not what I am doing :P so leave me alone with your Java slander! |
| 13:23.27 | claymore | mafm: Then it already is segregated :) |
| 13:23.31 | brlcad | heh |
| 13:23.45 | mafm | it was done that way, apart from the general idea of separating view and logic, because of the uncertainties of RBGui |
| 13:24.02 | mafm | Also I think that it's not very dependent of OGRE |
| 13:24.15 | claymore | what is not very dependant on ogre? |
| 13:24.20 | mafm | the application |
| 13:24.33 | brlcad | isn't slander, I'm actually quite fond of Java actually .. for a whole variety of uses and applications, it solves a lot of problems you have to fight with other languages |
| 13:24.55 | mafm | that is, doesn't relay on anything of OGRE besides launching it |
| 13:24.55 | claymore | mafm: I need to take a look at your code ;) |
| 13:25.26 | mafm | The way to handle commands, console history and similar functionalities implemented, are independent |
| 13:25.39 | mafm | or mostly, I think |
| 13:25.59 | claymore | brlcad; Just teasing you a bit :) |
| 13:26.10 | claymore | I like Java quite a bit. |
| 13:26.44 | brlcad | knows :) |
| 13:26.50 | claymore | but it has/doesn't have a few things that piss me off. Multiple inheritence being one of them.... |
| 13:27.01 | mafm | I like Java as a language, not java as a running thing :D |
| 13:27.18 | claymore | mafm: Sounds like you dun did it smart. |
| 13:28.34 | claymore | brlcad: So much for 'stopping chattering' eh? :P |
| 13:28.58 | brlcad | not really, I got dressed and shaved and groomed all the while :) |
| 13:29.22 | brlcad | socks...where be those things... |
| 13:29.27 | mafm | :D |
| 13:31.02 | mafm | What Java has that bothers me a lot is integrated stuff in core libs like sockets, GUIs, threads... it's so easy to bootstrap simple applications! |
| 13:31.39 | claymore | why does that bother you? |
| 13:31.49 | claymore | thats a *feature* ;) |
| 13:31.52 | mafm | also, for ( e: coll ) loops are niiiice |
| 13:31.56 | mafm | bothers me in C++ |
| 13:32.09 | mafm | What Java has and not C++ |
| 13:32.38 | CIA-62 | BRL-CAD: 03davidloman * r33186 10/rt^3/trunk/src/geometryService/cpp/docs/iBME_14NOV08_0800.png: Graphical View of the current iBME architecture. |
| 13:32.44 | mafm | 's favourite C++0x feature will be "auto" things, most probably |
| 13:33.07 | brlcad | c++ is getting lots of great new additions (threads, java-style loops, automatic typing) soon |
| 13:33.11 | brlcad | yeah |
| 13:33.14 | mafm | no insane syntax for iterators anymore :) |
| 13:33.54 | brlcad | was excited to read through some of the SC22 that was resolved last month |
| 13:33.58 | mafm | well, Boost makes a good job for things like threads, but it's got a bit too late to the party I think |
| 13:34.18 | mafm | and in example the network/socket lib, which was a GSoC project this year |
| 13:34.30 | brlcad | yeah, networking will be sorely missing |
| 13:34.51 | brlcad | they did at least agree on some basic threading intrinsics though.. that was going to get left out |
| 13:34.55 | brlcad | http://www.open-std.org/JTC1/SC22/WG21/ |
| 13:35.29 | brlcad | std::thread ftw |
| 13:36.32 | CIA-62 | BRL-CAD: 03d_rossberg * r33187 10/rt^3/trunk/src/coreInterface/ (ConstDatabase.cpp Object.cpp): replaced some deprecated defines |
| 13:36.35 | brlcad | er, s/SC22/SC22 disagreements!/ |
| 13:36.43 | mafm | other than those differences in basic libraries, I tend to program similarly in both languages I think |
| 13:38.14 | mafm | hopefully C++0x will be out in 2009, otherwise the very nickname will be confusing :D |
| 13:38.18 | claymore | mafm: really? interesting. One of the biggest PITA's I ran into in java was the whole 'El Camino' thing of Multiple Inheritence. If you want to use MI in java, then at least ONE of the super classes has to be 100% virtual/abstract.... and thats abnoxious! |
| 13:39.02 | mafm | I don't use MI a lot, but well, my java experience is mostly with smallish projects |
| 13:39.05 | *** join/#brlcad elite01 (n=omg@unaffiliated/elite01) |
| 13:39.10 | brlcad | claymore: there's a big portion that also needs to get integrated (in a way that they can continue to work on it too, collaboration is a good thing) .. src/coreInterface was pretty much designed as the start of the GE |
| 13:41.04 | brlcad | that's some momentum that really would hate to just loose or ignore and they've got it already working for I/O and some set of operations |
| 13:43.21 | brlcad | by the way, if you guys don't know about it already .. http://stackoverflow.com/ <-- great site for getting answers to coding/design/practice questions or even for passively learning if you don't know about it already |
| 13:43.43 | brlcad | is repeating himself, so he hits the road, so he hits the road |
| 13:43.45 | claymore | brlcad: Thats on the todo list ;) I have seen some emails and had conversations recently that have clued me into the need for some pretty pictures and documentation to show progress ;) |
| 13:45.18 | brlcad | claymore: I'm mostly saying it needs to be a two-way collaboration, not just one-way 'here is how this idea was designed, is better, is different, etc' (not to imply that you were or weren't doing that) |
| 13:46.07 | brlcad | he's done a lot of good work there, it should be integrated in a way they're good with too so they can keep using it and contributing |
| 13:46.40 | claymore | Its one bigass, ginormous learning experience for me :) As I learn exactly what is *in* rt^3/src already, I can add/append/alter etc. |
| 13:46.48 | brlcad | he documented some of it on the wiki already too |
| 13:47.03 | claymore | But I will talk PM stuff with ya when you get here :) |
| 13:47.11 | claymore | on the wiki eh? aye aye. |
| 13:47.12 | brlcad | http://brlcad.org/wiki/Developer_Documents |
| 13:47.40 | brlcad | core C++ interface |
| 13:48.53 | claymore | righto, thanks for the link. |
| 14:03.41 | CIA-62 | BRL-CAD: 03bob1961 * r33188 10/brlcad/trunk/src/libged/get_type.c: Fleshed out get_type |
| 14:04.07 | *** join/#brlcad ``Erik (i=erik@c-68-54-174-162.hsd1.md.comcast.net) |
| 14:07.12 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) |
| 14:08.49 | claymore | Greetings Daniel! Did you get my SourceForge email? |
| 14:09.20 | ``Erik | heh "mobile chernobyl", hadn't heard that one before |
| 14:09.37 | ``Erik | ss... screenshot? secret service? :D |
| 14:10.04 | claymore | erik: The 'Prize' is an ELT's nightmare (Engineering Lab Tech,aka water chem guys) |
| 14:10.19 | d_rossberg | claymore: that's why i'm here :) |
| 14:10.40 | claymore | erik: hence the 'Prize' and 'Mobile Cherynobl' nicknames :) |
| 14:11.05 | claymore | d: Excellent. I just started reading through your code and wiki entries. |
| 14:11.09 | clock_ | mobile chernobyl? |
| 14:11.24 | clock_ | That recommends me since yesterday evening I have a wonderful russian oscilloscope at home |
| 14:11.30 | d_rossberg | currently i'm working on a C++ inteface "as i need it" |
| 14:11.36 | clock_ | 16.5kg, 150W, 100 MHz |
| 14:12.11 | clock_ | recommends -> reminds |
| 14:12.19 | ``Erik | neat, old crt/analog dealie? |
| 14:12.22 | clock_ | yes |
| 14:12.37 | clock_ | This one http://rw6ase.narod.ru/s/s/s1_99_.jpg |
| 14:12.38 | claymore | d: If i read your docs correctly, you are striving to attain a completely self suffiecient C++ Brlcad library...right? |
| 14:12.44 | CIA-62 | BRL-CAD: 03bob1961 * r33189 10/brlcad/trunk/src/libged/grid.c: Added code to return help string if no args were specified. |
| 14:13.00 | *** join/#brlcad elite01 (n=omg@unaffiliated/elite01) |
| 14:13.13 | d_rossberg | claymore: right |
| 14:13.16 | ``Erik | other than the letters being all wrong, looks quite similar to what I used in highschool and college |
| 14:13.32 | mafm | going home earlier today, see you! |
| 14:13.43 | claymore | d: Are you familiar with the work on 'ged' that is being done in brlcad currently? |
| 14:13.45 | ``Erik | (or secondary school and university for those who use that terminology) |
| 14:13.51 | clock_ | ``Erik: it's not theyre wrong it's called CYRILLIC! :) |
| 14:14.01 | ``Erik | :D |
| 14:14.10 | clock_ | Mine has a split screen zoom function! |
| 14:14.14 | d_rossberg | it should be independent from the implementation of the kernel ... |
| 14:14.29 | d_rossberg | i know what ged is for |
| 14:14.37 | ``Erik | I don't care of they're ceramic or silkscreen or marker, they're backwards! it's like a first grader made it! :> *duck* *run* |
| 14:14.46 | claymore | erik : lol |
| 14:14.58 | clock_ | L0lz!!111 |
| 14:15.18 | clock_ | Actually I thought for a long time the scope is called C1-99 |
| 14:15.33 | clock_ | But it's actually called S1-99 because C is S in Russian alphabet |
| 14:15.43 | claymore | d: alright cool. Well, it seems that your initiative and ged go hand in hand, unless I read thngs wrong, since ged is supposed to wrap up ALL of mged's current functionality. |
| 14:15.47 | clock_ | What can S stand for? |
| 14:16.06 | clock_ | Scope? |
| 14:16.17 | clock_ | Superb? |
| 14:16.23 | clock_ | Soviet? |
| 14:16.48 | claymore | d: So, the approach I was looking at was to simply write a C++ class called GED and then just wrap all of GED functionality in function calls. |
| 14:17.07 | clock_ | let's fuse BRL-CAD and gEDA together |
| 14:17.09 | ``Erik | given that russian language has no real historic heritage tracing back to teutonic or romance languages to my knowledge, I wouldn't expect to see that kinda similarity to engrish |
| 14:17.19 | clock_ | make a universal circuit and 3D design tool called mgEDA |
| 14:17.33 | ``Erik | unless they hijacked the german word for scope for that specific purpose *shrug* :) |
| 14:17.43 | claymore | d: Are you taking a different approach? |
| 14:20.04 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) |
| 14:20.42 | d_rossberg | claymore: i don't like ged's parameters |
| 14:21.08 | d_rossberg | this is something for a high level inteface as a gui or shell |
| 14:21.19 | CIA-62 | BRL-CAD: 03erikgreenwald * r33190 10/brlcad/trunk/src/proc-db/metaball.c: stack save the thoughts in progress, have other stuff to do first |
| 14:21.39 | d_rossberg | but i wouldn't use argc/argv on system level |
| 14:22.40 | d_rossberg | i'm looking for something closer to the kernel |
| 14:22.44 | claymore | d: Agreed, I don't particularly like that interface either. |
| 14:23.02 | claymore | d: 'kernel' of what... the OS? |
| 14:23.18 | d_rossberg | no, BRL-CAD's kernel |
| 14:23.25 | d_rossberg | (librt) |
| 14:23.27 | claymore | d: ah, I see now. |
| 14:23.37 | ``Erik | and libged, now |
| 14:23.48 | claymore | ponders. |
| 14:24.37 | d_rossberg | libged is an interface to a shell build on librt (mainly) |
| 14:25.18 | claymore | d: I am wondering if establishing a OO system that sits on top of libged but still coming to a focalpoint of a 'master' GED object would solve both our needs. |
| 14:26.47 | ``Erik | surposedly, librt is supposed to evolve to holding and interrogating (viewing crud as immutable) where libged will be the editing kernel, no? :) given that it's a modeler and not a model viewer, I'd believe that librt/libged construct the kernel |
| 14:26.57 | ``Erik | *shrug* I need more tea, at least this cough is dying down |
| 14:27.20 | claymore | Hrm, I was of the mind that libged was closer to an API that involved ALL of the brlcad libs... |
| 14:27.29 | d_rossberg | i would like to see something in between librt and libged |
| 14:28.03 | d_rossberg | i.e. implementing libged's functionality but with "real" parameters |
| 14:28.26 | d_rossberg | maybe with the help of an OO layer |
| 14:28.52 | ``Erik | #!~@! stupid fop crap, popping java crap off and stealing window focus |
| 14:29.19 | d_rossberg | however, i would recommend to develop the C++ inteface independently from ged at the moment |
| 14:29.35 | claymore | d: righto. I think we are speaking the same thing now. By using the term 'implementing' are you talking about re-writing libged's functionality, or putting an OO layer (with *real* parameters) that utilizes libged's existing code? |
| 14:30.04 | ``Erik | oh wow, it's all argv/argc crap (I hadn't looked at libged before) |
| 14:30.27 | claymore | its not crap, just not the way I would like it :) |
| 14:30.46 | claymore | besides, its the first step towards a more unified codebase :) |
| 14:31.11 | d_rossberg | at the moment i'm working on a layer right on top of librt's functionality |
| 14:31.26 | d_rossberg | i.e. ged's functionality will not be included |
| 14:31.27 | ``Erik | yeh, but I grok herr dannies argument now :) |
| 14:33.51 | claymore | Hrm, I will need to study libged and see just how comprehensive its coverage of the underlying libraries is... |
| 14:34.46 | ``Erik | I think I have an idea of exactly what it is, how it's migrating and why... but if I tried to state it, I'd be wrong, I'm sure :D |
| 14:35.13 | claymore | I dunno if making a different API to the libs will be worth the duplication of effort.... :/ |
| 14:35.55 | claymore | Erik: go for it. if you know you are already wrong then you shouldn't be surprized nor hurt if its pointed out that you are :D |
| 14:36.43 | d_rossberg | libged came from mged, now it's an independent shell-like interface to BRL-CAD |
| 14:37.25 | d_rossberg | this is really nice, but it's not applicable for all applications |
| 14:38.07 | ``Erik | heh, aight, mged has a simple capture widget which cranks things through the tcl engine and has a bunch of wrappers for C things exposed to the interpreter FFI style, so'z the 'export to tcl' stuff is being wholesale lifted and moved, libged is looking like a brlcad/tcl ffi lib at the moment |
| 14:38.39 | ``Erik | if you write in tcl, swank... but in C, you have to build things up to look like the tcl interpreter before using it |
| 14:39.07 | ``Erik | don't quote me, boy, I ain't said nothin' :) |
| 14:39.27 | claymore | takes a screenshot. |
| 14:39.43 | clock_ | claymore: Polroid |
| 14:40.39 | ``Erik | mocks up a display of claymore making socially unacceptable statements and takes a screenshot (or polaroid) :D hardly proof |
| 14:41.47 | clock_ | can you give an example of a socially acceptable statement? :) |
| 14:42.18 | claymore | d: Cool. thanks for the info. I will need to chat with a few people before making the descision to build a new interface directly on top of the libs or building one ontop of libged. I think it will come down to a shortterm longterm tradeoff. |
| 14:42.47 | ``Erik | 60 eco, time for prings on that astro O.o |
| 14:44.02 | claymore | erik Nice :) My las wave of dreads should be finishing soon and I will have completed the removal of ft's from all or my bases... that gives me 53K fts in my mobile... once I get all the FCs to move them all :/ |
| 14:47.00 | d_rossberg | claymore: do you have an idea how an interface on top of libged will look like? (TCL?) |
| 14:47.57 | d_rossberg | on the other side: i try to design the C++ interface really fast, e.g. no unnecessary malloc or new |
| 14:48.41 | d_rossberg | (this is the reason for the odd looking callbacks in the Get methods) |
| 14:49.20 | claymore | d: for the purposes of the iBME/GS, the interface to libged would be completely OO, with as many *real* parameters as would make sence. |
| 14:49.53 | claymore | d: so you are trying to do everything on the stack? |
| 14:50.08 | d_rossberg | as much as possible |
| 14:50.37 | claymore | d: cool. What size data files are you working with? If you don't mind me asking... |
| 14:52.31 | d_rossberg | the files on my computer aren't so big, 20MB max |
| 14:53.03 | claymore | d: no issue loading those completely into stack space? |
| 14:55.21 | d_rossberg | at the the moment: no; however the class can be changed to work with a file or it could be created a new class derived from the existing ones which works with a file |
| 14:55.32 | d_rossberg | it is all in development :) |
| 14:56.04 | d_rossberg | the in-memory database was a test for me too |
| 14:56.13 | d_rossberg | i've never used it before |
| 14:57.51 | claymore | d: sweet. FWIW, i would love to ultimately have a pure 00 layer ontop of the libs, but time contraints may make me impliment an 00 layer ontop of libged initially :/ |
| 14:58.14 | d_rossberg | the point in my applications is the ray-trace: it has to be fast |
| 15:00.21 | claymore | d: understood. Ultimately, in the iBME/GS, it will be a priority also. |
| 15:00.24 | ``Erik | should have a titan in the queue in about a week O.O |
| 15:00.46 | claymore | awesomeness. They take *forever* to build :( |
| 15:01.50 | d_rossberg | i try to build a basis where it is easy to add a new interface to a feature or primitive |
| 15:02.26 | claymore | d: I like your approach thus far and can definetly see the potential for expansion. |
| 15:03.28 | d_rossberg | having this it could be a task in next years GSoC to add some features to this interface (for example) |
| 15:03.53 | claymore | d: I just need to feelout how *firm* some of my deadlines are :) |
| 15:04.26 | claymore | d: so you can currently load a database file without any touble? |
| 15:05.18 | d_rossberg | yes |
| 15:05.51 | d_rossberg | and change the database's title and the object's names |
| 15:06.11 | d_rossberg | + ray-trace etc. |
| 15:09.02 | claymore | Excellent thanks :) |
| 15:09.25 | clock_ | xray-trrace |
| 15:10.49 | *** join/#brlcad louipc (n=louipc@archlinux/trusteduser/louipc) |
| 16:27.08 | louipc | brlcad: I got an interesting error when building 7.14.0 |
| 16:27.19 | louipc | brlcad: looks like you left your mark in there :D http://louipc.yi.org/brlcad/brlcad-7.14.0-build-error |
| 16:46.58 | *** join/#brlcad elite01 (n=omg@unaffiliated/elite01) |
| 18:23.13 | ``Erik | garth marenghi's darkplace |
| 18:31.59 | CIA-62 | BRL-CAD: 03davidloman * r33191 10/rt^3/trunk/src/geometryService/cpp/docs/BME.eap: Continuing Architecture Work: Refactored AbstractResource and Subclasses. |
| 18:56.50 | *** join/#brlcad archivist_emc (n=archivis@host81-149-119-172.in-addr.btopenworld.com) |
| 18:57.03 | *** join/#brlcad archivist (n=archivis@host81-149-119-172.in-addr.btopenworld.com) |
| 19:19.46 | brlcad | claymore: tab-completion (reading backlog d:'s) is nice for others too so your messages are hilighted to their attention ;) |
| 19:28.02 | brlcad | louipc: not too surprising, I leave dents all over the place ;) |
| 19:28.17 | brlcad | that url correct though? |
| 19:28.27 | brlcad | I get no server there |
| 19:28.46 | brlcad | ah, it's blocked, I got it now |
| 19:29.38 | brlcad | louipc: bah .. yeah, that sucks.. tcl is annoying embedding full paths somewhere -- you have to rerun autogen.sh and configure to clear them out |
| 19:45.10 | CIA-62 | BRL-CAD: 03davidloman * r33192 10/rt^3/trunk/src/geometryService/cpp/docs/ (4 files): Image generation to support documentation effort at http://brlcad.org/wiki/IBME_Main |
| 19:56.21 | *** join/#brlcad clock_ (n=clock@77-56-87-140.dclient.hispeed.ch) |
| 21:46.39 | *** join/#brlcad Elrohir (n=kvirc@p5B14F065.dip.t-dialin.net) |
| 22:01.19 | *** join/#brlcad elite01 (n=omg@unaffiliated/elite01) |
| 22:26.28 | *** join/#brlcad smurfette (i=Pandora@c-69-247-220-102.hsd1.mo.comcast.net) |
| 22:26.43 | smurfette | http://forums.beyond.ca/st/240856/i-do-not-have-any-money-so-am-sending-you-this-drawing-i-did-of-a-spider-instead |
| 22:26.43 | smurfette | <PROTECTED> |
| 22:26.47 | smurfette | oops ;P |
| 22:27.06 | smurfette | http://forums.beyond.ca/st/240856/i-do-not-have-any-money-so-am-sending-you-this-drawing-i-did-of-a-spider-instead-/ |
| 22:27.10 | smurfette | there :P my bad |
