| 00:06.54 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 00:38.22 | *** join/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net) | |
| 00:38.43 | *** join/#brlcad alex_jon1 (~alex_joni@81.196.65.201) | |
| 00:39.38 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 01:11.52 | *** join/#brlcad crazy_imp (~mj@89.182.223.38) | |
| 02:55.29 | *** join/#brlcad vtts_ (~vytautas@diz.ktu.lt) | |
| 02:55.51 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 03:01.45 | *** join/#brlcad kanzure_ (~kanzure@bioinformatics.org) | |
| 03:01.45 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 03:01.45 | *** join/#brlcad alex_jon1 (~alex_joni@81.196.65.201) | |
| 03:01.45 | *** join/#brlcad indianla1ry (~indianlar@BZ.BZFLAG.BZ) | |
| 03:01.45 | *** join/#brlcad poolio_ (~poolio@BZ.BZFLAG.BZ) | |
| 03:04.51 | *** join/#brlcad dloman (~claymore@BZ.BZFLAG.BZ) | |
| 03:44.43 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 03:44.43 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 ETA 20110401 || Welcome GSoC 2011 Students! Speak up, ask questions, start here: http://brlcad.org/wiki/Google_Summer_of_Code/2011 | |
| 04:04.54 | *** join/#brlcad poolio (~poolio@BZ.BZFLAG.BZ) | |
| 04:06.15 | *** join/#brlcad kanzure__ (~kanzure@bioinformatics.org) | |
| 04:07.11 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 04:07.17 | *** join/#brlcad indianlarry (~indianlar@BZ.BZFLAG.BZ) | |
| 04:20.17 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 04:38.50 | *** join/#brlcad kasuga5 (~kasuga5@wlnt-02-042.dsl.netins.net) | |
| 05:43.33 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 07:00.00 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 07:25.28 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 07:25.57 | *** join/#brlcad kasuga5 (~kasuga5@wlnt-02-042.dsl.netins.net) | |
| 07:46.25 | *** join/#brlcad kasuga5 (~kasuga5@wlnt-02-042.dsl.netins.net) | |
| 08:23.38 | *** join/#brlcad adityag1 (~ADITYA@182.237.144.88) | |
| 08:23.38 | *** join/#brlcad CIA-105 (~CIA@208.69.182.149) | |
| 08:23.38 | *** join/#brlcad dtidrow__ (~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net) | |
| 08:23.38 | *** join/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net) | |
| 08:23.39 | *** join/#brlcad kasuga5 (~kasuga5@wlnt-02-042.dsl.netins.net) | |
| 08:23.39 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 08:23.39 | *** join/#brlcad indianlarry (~indianlar@BZ.BZFLAG.BZ) | |
| 08:23.39 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 08:23.39 | *** join/#brlcad kanzure__ (~kanzure@bioinformatics.org) | |
| 08:23.39 | *** join/#brlcad poolio (~poolio@BZ.BZFLAG.BZ) | |
| 08:23.39 | *** join/#brlcad dloman (~claymore@BZ.BZFLAG.BZ) | |
| 08:23.39 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 08:23.39 | *** join/#brlcad vtts (~vytautas@diz.ktu.lt) | |
| 08:23.39 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 08:23.39 | *** join/#brlcad bhinesley (~bhinesley@adsl-99-104-170-214.dsl.bkfd14.sbcglobal.net) | |
| 08:23.39 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 08:23.39 | *** join/#brlcad WhiteCalf (MK@whitecalf.net) | |
| 08:23.39 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 08:23.39 | *** join/#brlcad yiyus (1242712427@je.je.je) | |
| 08:23.39 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 08:23.39 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 08:23.39 | *** join/#brlcad hyarion (c05ben@peppar.cs.umu.se) | |
| 08:23.39 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 08:23.39 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 08:23.39 | *** join/#brlcad ChanServ (ChanServ@services.) | |
| 08:23.39 | *** mode/#brlcad [+o ChanServ] by verne.freenode.net | |
| 08:45.14 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 09:11.20 | dloman | reads GSOC proposals..... |
| 09:17.18 | dloman | Whoa, a Head System Admin for a university doesn't know what IRC is? oh dear..... |
| 09:35.05 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 09:37.36 | dloman | okay, now that's done. |
| 09:37.39 | dloman | interesting reads |
| 09:39.14 | dloman | needs about 10 more cores in my laptop :) |
| 09:44.00 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 09:44.41 | *** join/#brlcad vtts (~vytautas@diz.ktu.lt) | |
| 09:45.06 | *** join/#brlcad yiyus (1242712427@je.je.je) | |
| 10:46.35 | kunigami | hi, any comments on my proposals? thanks :) |
| 10:47.46 | CIA-105 | BRL-CAD: 03davidloman * r44170 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/GSConnection.java: GSConnection need not extend Thread. Limits implementation and restricts the end user's design. |
| 10:51.56 | CIA-105 | BRL-CAD: 03davidloman * r44171 10/geomcore/trunk/src/interfaces/java/test/org/brlcad/geometryservice/ (LoginTest.java SerialTest.java UUIDSerialResearch.java): Add in some tests and research. These were created some time ago but were never committed. |
| 10:53.34 | CIA-105 | BRL-CAD: 03davidloman * r44172 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/GSJavaInterface.java: Update for starting of worker thread. |
| 11:06.46 | dloman | kunigami: other than the lisencing issues starseeker mentioned, I'd offer the idea of providing a detailed list of the standalone apps you are consolodating. |
| 11:07.41 | kunigami | ok! could you confirm that my proposal for 'shader enhancements' is visible for you? |
| 11:08.23 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 11:08.33 | dloman | i can see it yes. |
| 11:09.19 | kunigami | ok, thanks. I'll edit my proposal ASAP |
| 11:10.34 | dloman | a detailed list of apps provided in the begining gives you a better way to gauge your progress and, overall, helps to more definitively determine success or not. |
| 11:10.38 | dloman | just an idea |
| 11:12.00 | kunigami | perfect, I agree |
| 11:13.09 | *** join/#brlcad kasuga5 (~kasuga5@wlnt-02-042.dsl.netins.net) | |
| 11:37.36 | *** join/#brlcad kasuga5_ (~kasuga5@wlnt-02-042.dsl.netins.net) | |
| 11:40.16 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 11:43.36 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 11:56.21 | *** part/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 11:57.56 | *** part/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 12:17.08 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:33.25 | CIA-105 | BRL-CAD: 03brlcad * r44173 10/brlcad/trunk/src/libged/screengrab.c: |
| 12:33.25 | CIA-105 | BRL-CAD: identify that this is a major encapsulation problem. this introduced a new |
| 12:33.25 | CIA-105 | BRL-CAD: dependency on libdm/libfb, which totally sucks and blows library encapsulation. |
| 12:34.55 | CIA-105 | BRL-CAD: 03brlcad * r44174 10/brlcad/trunk/src/libged/Makefile.am: gah, as expected, this introduced a new dependency. regression fail. maybe need a test to prevent this from occurring on all the core libraries (making calls to libraries that shouldn't be linked. |
| 12:39.43 | brlcad | is really in disbelief ... seriously? there shouldn't have to be training wheels to prevent this sort of crap coding |
| 12:52.01 | CIA-105 | BRL-CAD: 03brlcad * r44175 10/brlcad/trunk/TODO: cliff added support for name changes on red (needs NEWS). still need to indep test matrix edit. more importantly, need to undo the mess added to libged. |
| 12:59.28 | ``Erik | O.o |
| 13:08.44 | brlcad | wonders how libged is even compiling without a libdm link, is it all really header macros? |
| 13:10.01 | brlcad | begs for further separation of include into subdirs, so you can't get away with this so easily |
| 13:10.56 | ``Erik | <-- has always been a fan of keeping the headers with the source, src/libbu/bu.h etc |
| 13:11.13 | brlcad | but then you can't distinguish public from private |
| 13:11.53 | brlcad | at least without making it stupid obvious like bu_private.h or bu_don_t_use_me.h |
| 13:11.58 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 13:12.06 | ``Erik | not without having a convention in naming or looking at the .am, but *shrug* hasn't bothered me |
| 13:12.31 | brlcad | then someone just renames the file or worse, just includes it |
| 13:12.45 | ``Erik | heh, tieprivate.h librt_private.h ged_private.h :D |
| 13:13.02 | brlcad | exactly, taking double measures to make it stupid obvious |
| 13:13.29 | ``Erik | so what're you thinking, include/bu/bu.h ? |
| 13:13.43 | brlcad | and how many of those are STILL bing included where they shouldn't be .. #include "../librt/librt_private.h" |
| 13:14.52 | ``Erik | *ponder* #ifndef BUILDING_LIBRT #error "Stopit." #endif |
| 13:15.17 | brlcad | yeah, exactly that, then adding include/bu to the cppflags so "bu.h" still works, maybe BU_CPPFLAGS |
| 13:15.51 | brlcad | might have to do something that obtuse really |
| 13:16.37 | brlcad | seriously, I totally expect better .. that sort of training wheels shouldn't be needed |
| 13:17.55 | brlcad | there's only one or two commiters that might not know better and they're not even the ones doing this |
| 13:20.23 | CIA-105 | BRL-CAD: 03brlcad * r44176 10/brlcad/trunk/TODO: need to group together library headers into public subdirs. will need to set up proper cppflags as well similar to the LIBS flags. |
| 13:21.07 | ``Erik | know anything about, uh, .dot and graphviz? I wonder if we could use the DEPENDS line to generate a map |
| 13:21.40 | CIA-105 | BRL-CAD: 03brlcad * r44177 10/brlcad/trunk/TODO: help cliff not go bald. |
| 13:21.42 | ``Erik | (assuming that line is generally correct... it's manual, so it does get out of sync on occasion) |
| 13:21.56 | brlcad | yes, I used graphviz to visualize the CSG graph before .. pretty awesome for small models |
| 13:22.17 | brlcad | had a g-dot script I wrote up (didn't commit it) |
| 13:22.24 | brlcad | havoc was insane |
| 13:23.00 | brlcad | a graphviz of the libs would be interesting |
| 13:23.05 | ``Erik | so when is the cmake merge? I've been using his branch on fbsd mac and win32 without issue |
| 13:23.17 | brlcad | after release |
| 13:23.38 | brlcad | which was today, but now have to undo bob's junk and mabye move screengrab |
| 13:27.54 | CIA-105 | BRL-CAD: 03brlcad * r44178 10/brlcad/trunk/TODO: if we do the subdir, then there's risk of people going lazy and including via subdir. add a regression to make sure it's clean code using CPPFLAGS. |
| 13:36.16 | CIA-105 | BRL-CAD: 03brlcad * r44179 10/brlcad/trunk/ (10 files in 2 dirs): (log message trimmed) |
| 13:36.16 | CIA-105 | BRL-CAD: I get it. It was an April Fool's Joke, right?? Revert to r44152 since it makes |
| 13:36.16 | CIA-105 | BRL-CAD: all sorts of calls to LIBDM macros and the dm struct, requires libdm header. |
| 14:04.00 | *** part/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 14:04.33 | ``Erik | ahm, that commit removed struct tclcad_obj, which is flipping out libtclcad/tclcad_obj.c |
| 14:14.50 | brlcad | hrm,k |
| 14:15.35 | brlcad | ah, I apparently wasn't up to date |
| 14:17.59 | brlcad | now to hunt down a couple tires before I blow out my slicks |
| 14:18.18 | ``Erik | heh, noticed that :) I need to order a full set, myself :/ |
| 14:20.17 | CIA-105 | BRL-CAD: 03brlcad * r44180 10/brlcad/trunk/src/libdm/ (Makefile.am adc.c axes.c grid.c labels.c rect.c scale.c): rest of revert to r44152. helps to be fully up-to-date during merge. continuation of r44179. |
| 14:27.52 | CIA-105 | BRL-CAD: 03bob1961 * r44181 10/brlcad/trunk/src/libged/ged.c: typo in comment |
| 14:39.51 | CIA-105 | BRL-CAD: 03Erik 07http://brlcad.org * r2815 10/wiki/NetMsgTypes: add bot geometry request |
| 14:45.27 | CIA-105 | BRL-CAD: 03erikgreenwald * r44182 10/geomcore/trunk/ (3 files in 3 dirs): add GeometryBoTReqMsg |
| 14:53.03 | CIA-105 | BRL-CAD: 03erikgreenwald * r44183 10/geomcore/trunk/src/interfaces/cl/ (gsclient.lisp gsnet.lisp gsserver.lisp): add geombotreqmsg |
| 15:18.34 | Ralith | there's a CL API? awesome |
| 15:19.17 | ``Erik | it's just me dorking around with the protocol, it's a keen test bed :) |
| 15:24.15 | CIA-105 | BRL-CAD: 03erikgreenwald * r44184 10/geomcore/trunk/src/interfaces/cl/gsserver.lisp: break the connection loop out so it can be updated with a live session going |
| 15:25.25 | *** mode/#brlcad [+o brlcad] by ChanServ | |
| 15:58.49 | dloman | feels like garbage. might have to take the rest of the day as leave .... |
| 16:10.40 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 16:27.54 | brlcad | kunigami: which of those two proposals is your main interest? |
| 16:31.13 | kunigami | brlcad: I prefer shader enhancement! |
| 16:31.42 | brlcad | oh really? |
| 16:31.51 | brlcad | wouldn't have guessed that from the proposals :) |
| 16:32.06 | brlcad | you plan on filling out the rest of the details you'd left out then? |
| 16:32.38 | kunigami | :P I think I mentioned somewhere on "shader enhancement" that this one would have the greatest priority. let me check |
| 16:33.13 | brlcad | you may have, hadn't gotten to reading it word-for-word yet |
| 16:34.09 | kunigami | hmm ok. And yes, I'm planning to filling out the details. I just wanted to submit the draft for possible reviews. I've been studying rt's code this weekend and I already learned something to add on there :) |
| 16:34.33 | brlcad | as they currently stand written, at a glance, the image processing is much more clearly composed with goals, scope, integration, plan of attack, etc |
| 16:34.41 | brlcad | okay, good to know |
| 16:36.26 | kunigami | oh yes, I had a much clearer idea on what to do on image processing. I think I had the necessary knowledge to write the proposal. For the shader enhancement one, I have some research to do yet :) |
| 16:37.57 | kunigami | but anyway, I think that the shader enhancement is more challenging. Since I'm not sure if will be able to write a compelling proposal for this one, I also did one for the image processing. |
| 16:40.07 | brlcad | it definitely is more challenging :) |
| 16:40.47 | brlcad | so part of the reason is so that we scope to the summer timeframe accordingly so you can actually make progress and enjoy what you're working on :) |
| 16:41.33 | brlcad | wouldn't want you to get accepted to work on a hard task and then spend all summer flailing about in liboptical not making any progress, getting frustrated in a sea of code :) |
| 16:42.05 | brlcad | you won't likely keep working on that code after the money stops, and that's not something either of us benefits from :) |
| 16:47.53 | brlcad | bhinesley: comments posted |
| 16:50.40 | kunigami | hmm my idea was actually to keep working (there are a couple of other rt-related projects that I got interested), but unfortunately I don't know how will be my time after I finish my masters. |
| 16:51.23 | kunigami | but let us see what can I offer until the end of the week so you can better judge if I'll be able to do that in a summer |
| 16:52.52 | brlcad | application deadline is friday so we'll have the following two weeks to review and elaborate |
| 16:55.03 | kunigami | cool! I din't notice that during after deadline we could add further details to the proposal! |
| 16:56.05 | brlcad | it's supposed to be more to elaborate, but yes -- there is still some time to elaborate but at that point it should be in response to our questions |
| 16:56.49 | brlcad | I wouldn't bank on it -- your proposal should be substantially "done" (i.e. fully written) by Friday from your perspective |
| 16:57.18 | brlcad | no telling what sort of restrictions the new google-melange interface may impose after the deadline |
| 16:59.00 | kunigami | hmm ok! |
| 17:03.53 | CIA-105 | BRL-CAD: 03erikgreenwald * r44185 10/geomcore/trunk/src/interfaces/cl/gsserver.lisp: Enable multi-threading. New 'stop' function. Hoist session loop. Use specified dir for geometry instead of cwd. |
| 17:05.22 | brlcad | kunigami: have you read the shaders presentation? |
| 17:05.30 | brlcad | it's on the website somewhere |
| 17:15.42 | brlcad | kunigami: in order to get a quick grasp on shaders for your proposal, I'd recommend taking the following steps: |
| 17:15.59 | *** join/#brlcad adityag1 (~ADITYA@182.237.144.88) | |
| 17:16.04 | brlcad | 1) download http://brlcad.org/w/images/c/cf/Introduction_to_MGED.pdf and perform at least lessons 1 through 4 |
| 17:17.31 | brlcad | 1a) through lesson 7 to get to some basic (phong) shader options |
| 17:17.41 | brlcad | 2) download and read http://brlcad.org/w/images/2/2c/Optical_Shaders.pdf |
| 17:19.01 | brlcad | 3) download and read appendix B in http://brlcad.com/downloads/documentation/BRLCAD_VolumeIII.pdf |
| 17:22.29 | brlcad | that should give a pretty good survey of what's presently available, should help reading the code |
| 17:23.25 | kunigami | wow, thanks for the links! I'll surely read them! I've already taken exactly lessons 1 to 4 on /doc/lessons and learned how to use the basics of mged and rt :) I'll read the other ASAP |
| 17:24.14 | CIA-105 | BRL-CAD: 03Sean 07http://brlcad.org * r2816 10/wiki/Shader_Enhancements: add documentation references |
| 17:26.21 | brlcad | the shaders are unfortunately some of our least documented portions of the code (because being a content modeling and rendering system are completely secondardy concerns) |
| 17:27.06 | brlcad | that said, we have support for quite a lot .. some of more hacked and research quality than other portions, but most all working for a specific purpose at some point in time |
| 17:29.01 | brlcad | OSL has the ability to replace our current shader string with a more formal and descriptive shader parameterization, with the description living as either as a new database object or keeping the string and passing through to a new liboptical shader |
| 17:30.41 | kunigami | hmm interesting |
| 17:31.36 | brlcad | shader objects are the way to go :) |
| 17:31.49 | brlcad | how to deal with them is the bigger question |
| 17:36.44 | *** part/#brlcad adityag1 (~ADITYA@182.237.144.88) | |
| 17:45.33 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 17:46.07 | dli | do we still need openNURBS then? |
| 17:46.16 | brlcad | what? |
| 17:48.07 | dli | brlcad or you mean shader is only for displaying, ray-tracing. |
| 17:48.37 | brlcad | shaders only pertain to optics, displaying geometry via raytracing |
| 17:49.26 | dli | brlcad, I was thinking to save all internal geometry as shaders and leave some computation to GPU |
| 17:49.50 | dli | that sounds too ambitious anyway |
| 17:50.28 | brlcad | I'm not sure you're using the same terminology or there is a big misunderstanding of some concept |
| 17:50.38 | brlcad | "I don't think that means what you think it means" :) |
| 17:51.40 | dli | brlcad, don't worry, I don't understand the 'shader' part anyway |
| 17:51.47 | brlcad | even if you're thinking of a GPU shader, you still have to have a geometric representation that goes with it |
| 17:52.07 | brlcad | shading merely answers "how" to draw .. not what |
| 17:52.09 | dloman | dli: How many fingers do you have on your right hand? |
| 17:52.23 | brlcad | six! |
| 17:52.36 | dloman | egads. |
| 17:52.42 | dli | 101 |
| 17:53.43 | brlcad | dli: speaking of 101, http://en.wikipedia.org/wiki/Shader ;) |
| 17:54.24 | brlcad | or even better, http://en.wikipedia.org/wiki/Shading |
| 17:55.32 | dli | brlcad, I thought shader also includes manipulating objects |
| 17:55.48 | brlcad | you have to have objects to manipulate in the first place |
| 17:55.55 | CIA-105 | BRL-CAD: 03Sean 07http://brlcad.org * r2817 10/wiki/Shader_Enhancements: |
| 17:56.16 | CIA-105 | BRL-CAD: 03erikgreenwald * r44186 10/geomcore/trunk/src/interfaces/cl/ (gsclient.lisp gsnet.lisp gsserver.lisp): fix off by one weirdness in chunk request |
| 17:56.21 | brlcad | and it doesn't modify the object, it only modifies how it's displayed |
| 17:57.55 | dli | brlcad, thanks |
| 18:04.33 | CIA-105 | BRL-CAD: 03erikgreenwald * r44187 10/geomcore/trunk/src/interfaces/cl/gsserver.lisp: remove packet type display |
| 18:04.55 | CIA-105 | BRL-CAD: 03erikgreenwald * r44188 10/geomcore/trunk/src/interfaces/cl/ (gsclient.lisp gsnet.lisp): fix malformed expressions |
| 18:06.28 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 18:09.03 | *** join/#brlcad adityag1 (~ADITYA@182.237.144.88) | |
| 18:21.34 | bhinesley | brlcad: cool, I responded |
| 18:21.50 | brlcad | bhinesley: do you get e-mail notification? |
| 18:22.02 | bhinesley | brlcad: oops, not to you. page must have cached... |
| 18:22.15 | bhinesley | no, how do I enable that? I was looking everywhere... |
| 18:23.47 | brlcad | I just mean if we post a comment, do they notify you |
| 18:23.49 | brlcad | might not be a feature |
| 18:24.04 | brlcad | was in the past, but it's a new interface this year |
| 18:24.04 | bhinesley | unfortunately, they don't |
| 18:24.10 | brlcad | k |
| 18:25.34 | bhinesley | it seems like setting up a end-user editable plain text file with command aliases might not be a bad idea |
| 18:25.57 | bhinesley | not for the project, but in the future |
| 18:26.47 | brlcad | users can (and do) do that now with their .mgedrc file |
| 18:27.07 | bhinesley | oh alright, I had no idea (obviously) |
| 18:27.14 | brlcad | it would be nice to formalize that into specific packages, though |
| 18:27.28 | brlcad | it's basically akin to using the alias command and your .profile now |
| 18:28.09 | bhinesley | ah |
| 18:28.15 | brlcad | more useful would be command alias "packages" for things like "legacy mode commands", "dwayne's extensions", etc |
| 18:28.36 | starseeker | thinks that's the way to go if we "clean up" our existing commands - a "legacy.tcl" file or some such |
| 18:29.33 | brlcad | they should register as plugins, though, and then get enabled via the options gui |
| 18:30.13 | brlcad | so we can ship multiple configurations that you can just checkbox on/off, or they can toss in their own subdir into an install or homedir and get listed too |
| 18:30.25 | bhinesley | that sounds good |
| 18:30.32 | bhinesley | is it just the alias token, or is there a way to change the default command names? |
| 18:30.48 | brlcad | there's a way to change the default names |
| 18:31.02 | bhinesley | okay, that's what I was getting at |
| 18:31.08 | brlcad | so in theory these packages could override everthing |
| 18:31.27 | bhinesley | sounds like a good GSoC project ;) |
| 18:31.43 | brlcad | getting libged cleaned up is more important right now :) |
| 18:31.48 | bhinesley | sure |
| 18:32.18 | brlcad | that establishes the command baseline, one reusable across applications |
| 18:32.48 | bhinesley | yeah, I see that it makes sense to do that first |
| 18:33.53 | brlcad | that gets at the command registration I was referring to in my comment, so commands would register themselves with libged as an extension of the library, describe their capability, implement functionality -- then each command would get mapped to one or more names for scripting purposes, various GUI widgets, and into the help system |
| 18:35.48 | bhinesley | that would be ideal |
| 18:35.54 | bhinesley | highly modular |
| 18:36.12 | brlcad | that's the long-term goal |
| 18:36.27 | brlcad | so lots of cleanup, LOTS of refactoring to get there |
| 18:37.54 | bhinesley | so the idea is to keep things as contained as possible, for now |
| 18:38.05 | bhinesley | ? |
| 18:38.22 | brlcad | what do you mean? |
| 18:38.39 | brlcad | the idea is to move towards that completely modular goal :) |
| 18:39.20 | CIA-105 | BRL-CAD: 03starseeker * r44189 10/brlcad/branches/cmake/ (19 files in 6 dirs): MFC r44188 |
| 18:39.25 | brlcad | getting the command logic all in one place, making the two main apps (archer and mged) call through to libged to get at that command -- ideally without being aware of that command directly |
| 18:41.57 | *** join/#brlcad Ralith (~ralith@d142-058-173-143.wireless.sfu.ca) | |
| 18:42.03 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 18:42.07 | bhinesley | I thought that you were implying that these capabilities were not yet possible |
| 18:42.54 | bhinesley | nevermind... |
| 18:47.55 | CIA-105 | BRL-CAD: 03starseeker * r44190 10/brlcad/branches/cmake/src/libtclcad/CMakeLists.txt: Update libtclcad CMakeLists.txt file |
| 18:48.02 | brlcad | which is where your gsoc proposal comes in .. |
| 18:48.58 | brlcad | you can override commands and do things to them now, but there's no system in place for managing them and the commands are listed all over the place |
| 18:50.05 | CIA-105 | BRL-CAD: 03starseeker * r44191 10/brlcad/branches/cmake/src/libtclcad/CMakeLists.txt: Ah, right - add tclcad_obj.c |
| 18:50.44 | kunigami | brlcad: I commented on your question about my time during the summer. Could you see what do you think? thanks |
| 18:59.24 | bhinesley | brlcad: at this point, I would feel more comfortable starting with the command migration. Perhaps after the GSoC I could take on the goal of highly modular commands. |
| 19:01.45 | brlcad | kunigami: sure, it'll be a while though |
| 19:02.08 | brlcad | bhinesley: fair enough -- even working on command migration is moving towards modular commands |
| 19:09.57 | sachinjain | brlcad : how to upload a patch on sourceforge |
| 19:11.37 | brlcad | sachinjain: I suggest searching the web, there are LOTS of tutorials on how to create a patch using subversion, and how to upload to our patches tracker should be outright obvious (search for it) |
| 19:16.21 | CIA-105 | BRL-CAD: 03bob1961 * r44192 10/brlcad/trunk/ (include/ged.h include/tclcad.h src/libtclcad/tclcad_obj.c): Mods to get libtclcad compiling again. |
| 19:27.20 | bhinesley | brlcad: okay, comment posted now. I'm leaving for class. |
| 19:27.26 | CIA-105 | BRL-CAD: 03starseeker * r44193 10/brlcad/branches/cmake/ (include/ged.h include/tclcad.h src/libtclcad/tclcad_obj.c): MFC r44192 |
| 19:30.09 | CIA-105 | BRL-CAD: 03starseeker * r44194 10/geomcore/trunk/src/libgvm/gvm.h: Add a few more possible gvm header entries. |
| 19:30.13 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 19:34.09 | *** part/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 19:44.09 | CIA-105 | BRL-CAD: 03starseeker * r44195 10/geomcore/trunk/src/libgvm/gvm.h: will probably want to populate lists from repositories to have an easy format to send over the wire. |
| 19:49.52 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 20:08.33 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 20:25.25 | starseeker | wonders wy db_update_ident is used to update both title and units - why not just one function for title and another for units? or even just have _GLOBAL use normal bu_avs pairs? |
| 20:33.50 | starseeker | or does it... |
| 20:33.51 | starseeker | hmm |
| 20:36.55 | brlcad | _GLOBAL is just an attribute object |
| 20:38.10 | CIA-105 | BRL-CAD: 03erikgreenwald * r44196 10/geomcore/trunk/src/interfaces/cl/ (brlcad.asd brlcad.lisp): start up a cffi wrapper for librt |
| 20:38.27 | brlcad | db_update_ident() is historic behavior, combining title and units together was that way in all previous db versions iirc |
| 20:39.14 | brlcad | maybe even to reduce two i/o operations to one, but only speculative |
| 20:39.47 | *** part/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 20:39.48 | brlcad | separating them would make sense now |
| 21:02.12 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 21:02.12 | *** join/#brlcad yiyus (1242712427@je.je.je) | |
| 21:02.12 | *** join/#brlcad CIA-105 (~CIA@208.69.182.149) | |
| 21:02.12 | *** join/#brlcad kanzure__ (~kanzure@bioinformatics.org) | |
| 21:02.12 | *** join/#brlcad poolio (~poolio@BZ.BZFLAG.BZ) | |
| 21:06.01 | CIA-105 | BRL-CAD: 03erikgreenwald * r44197 10/geomcore/trunk/src/interfaces/cl/brlcad.lisp: Fix magic sizes (this may be a bug in librt?). Fix up the rt-open func. |
| 22:46.38 | CIA-105 | BRL-CAD: 03bob1961 * r44198 10/brlcad/trunk/src/libged/title.c: Should be using local2base instead of base2local here. |
| 23:45.37 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |