| 00:03.25 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 00:14.18 | starseeker | to my considerable surprise, that actually seems to have worked |
| 00:26.08 | CIA-52 | BRL-CAD: 03starseeker * r44144 10/geomcore/trunk/tests/svntest/main.c: whoops, double free |
| 01:11.32 | *** join/#brlcad crazy_imp (~mj@a89-182-208-175.net-htp.de) | |
| 01:23.40 | CIA-52 | BRL-CAD: 03starseeker * r44145 10/geomcore/trunk/src/other/uuid/CMakeLists.txt: This should probably be sleep, not Sleep? need to check |
| 01:24.30 | CIA-52 | BRL-CAD: 03starseeker * r44146 10/geomcore/trunk/src/GS/testclient/gstestclient.c: Don't need pkg.h here anymore |
| 01:28.43 | CIA-52 | BRL-CAD: 03starseeker * r44147 10/geomcore/trunk/src/ (4 files in 2 dirs): |
| 01:28.44 | CIA-52 | BRL-CAD: Start setting up for a library to handle subversion like we need it to be |
| 01:28.44 | CIA-52 | BRL-CAD: handled. Lots more to do here that a test program didn't have to worry about - |
| 01:28.44 | CIA-52 | BRL-CAD: svn error handling and making sure memory handling is sane are high on the list. |
| 01:36.20 | CIA-52 | BRL-CAD: 03starseeker * r44148 10/geomcore/trunk/src/libgeomsvn/breakout.c: Add a few more notes on things that need to be done. |
| 01:42.58 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096601295.dsl.bell.ca) | |
| 01:44.40 | starseeker | ok, yeah - there's quite a bit of work here |
| 02:01.10 | CIA-52 | BRL-CAD: 03starseeker * r44149 10/geomcore/trunk/src/libgeomsvn/breakout.c: There's going to be a fair bit of sanity checking needed... |
| 02:29.16 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 03:03.09 | *** join/#brlcad juan_man (~quassel@unaffiliated/juanman) | |
| 03:05.24 | brlcad | kunigami: libicv but they work with image.c (and that file may need to move to libicv) |
| 03:06.34 | brlcad | kunigami: #2 yes |
| 03:07.18 | brlcad | kunigami: #3 yes, that probably being the most important aspect of the library and important to "get it right" |
| 03:08.17 | brlcad | considerably time should be allotted to design, review, and critique of the API for libicv (e.g., writing all the headers before any implementation code, having a plan for how to plug in new formats) |
| 03:09.16 | brlcad | s/considerably/considerable/! |
| 03:33.48 | *** join/#brlcad WhiteCalf (MK@2607:f0d0:3001:68::2) | |
| 03:34.38 | brlcad | STUDENTS: you really should try to get draft versions of your applications uploaded to google by friday so mentors can review and comment on them before next week |
| 03:36.17 | bhinesley | Hi, brlcad. I'm working on a proposal for the MGED to Archer Command Migration project. I'm still figuring out how things work, but so far it seems that much of the migration should be pretty straightforward. |
| 03:36.27 | bhinesley | I'm trying to ascertain what level of detail would be appropriate for the proposal. For the section in which I'm explaining my migration "plan", am I just supposed to tell you what you need to understand what I plan to do, or should I elaborate to show that I know what I'm doing? |
| 03:36.43 | bhinesley | s/am I/should I |
| 03:37.13 | bhinesley | */ |
| 04:22.56 | brlcad | "yes" |
| 04:23.33 | *** join/#brlcad bhinesley (~bhinesley@adsl-99-30-66-238.dsl.bkfd14.sbcglobal.net) | |
| 04:23.40 | brlcad | bhinesley: "yes" |
| 04:24.06 | bhinesley | yes, I should elaborate? |
| 04:24.07 | brlcad | the more detail the better but if you like, you can put up what is needed to understand the plan |
| 04:24.21 | brlcad | then if more detail is needed, someone will ask for it |
| 04:24.53 | brlcad | more important to have good testable milestons defined |
| 04:25.17 | bhinesley | Okay, sounds good. By having a draft up tomorrow, do you mean on the wiki or submitted to Google? |
| 04:25.27 | bhinesley | n/m |
| 04:25.37 | bhinesley | reread it |
| 04:25.45 | brlcad | yeah, would get it up to google by this point |
| 04:25.54 | brlcad | just to have the app "in" |
| 04:26.30 | bhinesley | Alright, thank you, that's all I needed to know. |
| 07:43.44 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 08:31.37 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 08:31.37 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:39.53 | *** part/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 10:06.24 | *** join/#brlcad crazy_imp (~mj@a89-182-208-175.net-htp.de) | |
| 10:37.30 | *** join/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net) | |
| 11:36.28 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 12:40.58 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 13:01.14 | kunigami | hi, one more question: is there any possibility to rewrite image library in c++? |
| 13:19.06 | brlcad | kunigami: can't be rewritten because it's not written yet |
| 13:22.50 | brlcad | kunigami: you'd have to sell your case design-wise, what the benefits would be, what that design would look like |
| 13:23.21 | brlcad | libicv could be designed with a c++ implementation backend, but the front-end API (i.e., the public headers) needs to provide a pure C interface so C codes don't have to turn into C++ codes during refactoring |
| 13:24.51 | brlcad | that'd basically be like implementing full libicv in C++, then wrapping the whole library with a C API .. which may or may not actually be beneficial depending on how strong your C and C++ magic are ;) |
| 13:24.53 | starseeker | notes to take a look at this if he needs mph code for C++ someday... https://github.com/sile/mphf |
| 13:26.44 | brlcad | starseeker: interesting in itself that it's a simple hash container .. might make for a good libbu bu_hash generic bucket container |
| 13:27.00 | kunigami | hmm, perfect. I'll include that as a possibility on my proposal. I think we can delay this decision when designing |
| 13:27.15 | kunigami | ... the proposed library |
| 13:29.20 | brlcad | it'd basically be doubling the amount of design work, so it might not be worth it (or doable) for the timeframe given |
| 13:29.53 | brlcad | most of the time is really going to be spent refactoring and moving code around .. and API design |
| 13:30.31 | brlcad | (better to get a solid design with only one or two concepts refactored than to get a half-assed design with 100 concepts factored in |
| 13:30.47 | kunigami | haha ok :) |
| 13:31.53 | kunigami | hmm... could you tell me for which reason you want to unit all those stand-alone applications into a single library? |
| 13:32.46 | kunigami | doesn't it go against the philosophy that programs should do one thing and do it well? |
| 13:58.05 | ``Erik | those programs would still exist, but there's been demand for our image generating tools to output to a variety of formats, and we'd like to reduce the duplication of read/write code |
| 13:58.47 | ``Erik | (so pix-png would turn into 'bu_image *b = read_pix; write_png(b);', etc) |
| 14:14.30 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 14:18.09 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 14:36.18 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 14:45.36 | CIA-52 | BRL-CAD: 03erikgreenwald * r44150 10/geomcore/trunk/src/interfaces/cl/gsserver.lisp: implement reading the file and sending it as a chunk msg |
| 15:12.58 | kunigami | ok, thanks for the clarification |
| 15:15.57 | *** join/#brlcad adityag1 (~ADITYA@182.237.144.88) | |
| 16:13.07 | CIA-52 | BRL-CAD: 03bob1961 * r44151 10/brlcad/trunk/ (9 files in 2 dirs): Added the dm_reshape function to struct dm. This splits out the bits of code in dm-ogl and dm-wgl that reconfigure the openGL window after a resize. |
| 16:56.48 | willdye | Job openings at Google! http://www.google.com/intl/en/jobs/uslocations/mountain-view/autocompleter/index.html |
| 16:57.25 | willdye | And for fans of object-oriented programming: http://blog.mezeske.com/?p=377 |
| 17:17.17 | kunigami | ouch, I'm having a bad time with melange auto-formatting "feature" :P |
| 17:27.47 | kunigami | I've submitted my first proposal. Please, let me know if it's accessible for mentors. Suggestions are mostly welcome :) Thanks |
| 17:38.15 | *** part/#brlcad adityag1 (~ADITYA@182.237.144.88) | |
| 17:47.02 | CIA-52 | BRL-CAD: 03starseeker * r44152 10/geomcore/trunk/src/libgeomsvn/ (CMakeLists.txt geomsvn.h repo.c): Checkpoint again - got a ways to go here. Take Sean's suggestion and work on the API/header first. |
| 17:52.44 | kunigami | I'm working on the proposal of http://brlcad.org/wiki/Vector_output_from_raytracing project. |
| 17:55.24 | kunigami | If I understood the information well, it's possible to calculate vector forms from models *with* raytracing |
| 17:58.05 | kunigami | ... but not with rtedge not. So an alternative is to interpolate rtedge output into splines since splines would be vector representation. Is that right? |
| 18:28.09 | *** join/#brlcad Ralith (~ralith@d142-058-173-143.wireless.sfu.ca) | |
| 19:03.50 | CIA-52 | BRL-CAD: 03bob1961 * r44153 10/brlcad/trunk/ (18 files in 4 dirs): Begin refactoring relevant code in libtclcad and libdm to live in libged. |
| 19:13.48 | CIA-52 | BRL-CAD: 03bob1961 * r44154 10/brlcad/trunk/src/libtclcad/ (Makefile.am ged_obj.c tclcad_obj.c): Move ged_obj.c to tclcad_obj.c in libtclcad. |
| 19:13.50 | CIA-52 | BRL-CAD: 03starseeker * r44155 10/geomcore/trunk/src/libgeomsvn/geomsvn.h: List out some more possible functions, tweak structures, etc... |
| 19:41.07 | *** part/#brlcad willdye (~willdye@fern.dsndata.com) | |
| 20:03.04 | *** part/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 20:15.24 | *** join/#brlcad b0ef (~b0ef@226.27.202.84.customer.cdi.no) | |
| 20:24.00 | CIA-52 | BRL-CAD: 03erikgreenwald * r44156 10/brlcad/trunk/src/libged/red.c: quell uninitialized variable warning |
| 20:33.08 | CIA-52 | BRL-CAD: 03starseeker * r44157 10/geomcore/trunk/src/libgeomsvn/geomsvn.h: Checkpoint again. |
| 20:35.26 | CIA-52 | BRL-CAD: 03starseeker * r44158 10/geomcore/trunk/src/ (8 files in 2 dirs): Stake the claim - Geometry Version Management library - libgvm |
| 20:36.27 | CIA-52 | BRL-CAD: 03erikgreenwald * r44159 10/geomcore/trunk/ (src/libNet/CMakeLists.txt tests/libNet/CMakeLists.txt): add libge info |
| 20:36.32 | CIA-52 | BRL-CAD: 03starseeker * r44160 10/geomcore/trunk/src/libgvm/ (geomsvn.h gvm.h): rename the header before we change anything else (conflicts suck) |
| 20:54.24 | CIA-52 | BRL-CAD: 03starseeker * r44161 10/geomcore/trunk/src/libgvm/gvm.h: De-svnify gvm.h |
| 20:58.56 | CIA-52 | BRL-CAD: 03starseeker * r44162 10/geomcore/trunk/src/libgvm/gvm_svn.h: Add the specific subversion bits as a private header. |
| 21:02.38 | CIA-52 | BRL-CAD: 03erikgreenwald * r44163 10/geomcore/trunk/src/interfaces/cl/gsnet.lisp: add info message. fix manifest message off by 1 bug. |
| 21:05.10 | CIA-52 | BRL-CAD: 03starseeker * r44164 10/geomcore/trunk/src/libgvm/gvm.h: repository, not svn |
| 21:08.58 | CIA-52 | BRL-CAD: 03erikgreenwald * r44165 10/geomcore/trunk/src/interfaces/cl/gsnet.lisp: cleanup |
| 21:26.21 | CIA-52 | BRL-CAD: 03erikgreenwald * r44166 10/geomcore/trunk/src/interfaces/cl/gsserver.lisp: use read-sequence instead of looping with read-byte |
| 21:55.20 | CIA-52 | BRL-CAD: 03erikgreenwald * r44167 10/geomcore/trunk/src/interfaces/cl/gsnet.lisp: fix warnings, use read-sequence instead of iterating bytes |
| 21:58.26 | CIA-52 | BRL-CAD: 03erikgreenwald * r44168 10/geomcore/trunk/src/interfaces/cl/gsclient.lisp: fix handshake. use write-sequence instead of looping on write-byte. |
| 21:59.02 | CIA-52 | BRL-CAD: 03erikgreenwald * r44169 10/geomcore/trunk/src/interfaces/cl/gsserver.asd: force serial loading, since gsserver depends on gsnet |
| 23:33.09 | *** join/#brlcad bhinesley (~bhinesley@adsl-99-30-66-238.dsl.bkfd14.sbcglobal.net) | |