| 01:01.04 | *** join/#brlcad Zhao_Anqing (clouddrift@222.205.19.237) | |
| 01:17.40 | Notify | 03BRL-CAD:zhaoanqing * 62036 NIL: create a new dictionary for NMG codes alone. |
| 01:25.01 | Notify | 03BRL-CAD:zhaoanqing * 62037 (brlcad/branches/nmgreorg/src/librt/CMakeLists.txt brlcad/branches/nmgreorg/src/librt/bbox.c and 8 others): remove some files from librt. They will be added into libnmg. |
| 01:26.24 | Notify | 03BRL-CAD:zhaoanqing * 62038 brlcad/branches/nmgreorg/src/CMakeLists.txt: update CMakeLists.txt in src to config for new-created libnmg. |
| 01:51.17 | Notify | 03BRL-CAD:zhaoanqing * 62039 (brlcad/branches/nmgreorg/src/libnmg/CMakeLists.txt =================================================================== and 119 others): move files from librt into libnmg. |
| 01:57.02 | Notify | 03BRL-CAD:zhaoanqing * 62040 (brlcad/branches/nmgreorg/src/libnmg/primitives/bspline/nurb_basis.c =================================================================== and 117 others): move nmg/bspline parts from librt into libnmg. |
| 01:58.40 | Notify | 03BRL-CAD:zhaoanqing * 62041 brlcad/branches/nmgreorg/include/raytrace.h: update raytrace.h to fit the movement from librt to libnmg. |
| 03:12.56 | Notify | 03BRL-CAD Wiki:Inderpreet * 7650 /wiki/User:Inderpreet/GSoC14/logs: /* Week 12 */ |
| 04:06.59 | *** join/#brlcad Zhao_Anqing (~clouddrif@183.157.160.15) | |
| 05:00.43 | Notify | 03BRL-CAD:zhaoanqing * 62042 (brlcad/branches/nmgreorg/include/raytrace.h brlcad/branches/nmgreorg/src/librt/comb/comb.c): remove some tree/rt_comb functions which are not used. |
| 06:21.59 | *** join/#brlcad devinder (~chatzilla@122.173.165.174) | |
| 06:22.38 | *** join/#brlcad devinder (~chatzilla@122.173.165.174) | |
| 06:53.19 | *** join/#brlcad konrado (~konrado@195.24.209.22) | |
| 07:12.20 | *** join/#brlcad pandrei (~pandrei@86.121.194.74) | |
| 07:19.32 | *** join/#brlcad mihaineacsu (~mihaineac@92.85.29.79) | |
| 09:23.08 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) | |
| 10:24.00 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) | |
| 10:30.11 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) | |
| 10:51.39 | *** join/#brlcad zxq9 (~ceverett@FL9-125-199-207-150.okn.mesh.ad.jp) | |
| 11:21.30 | *** join/#brlcad clock (~clock@77-58-143-135.dclient.hispeed.ch) | |
| 11:43.53 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) | |
| 12:13.00 | *** join/#brlcad vladbogo (~vlad@86.121.97.131) | |
| 12:13.53 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) | |
| 12:30.30 | ries | any mentors here going to GSoC? |
| 12:45.32 | Notify | 03BRL-CAD:vladbogo * 62043 brlcad/trunk/src/libfb/if_qt.cpp: Implemented the qt_read, qt_readrect and qt_writerect functions. |
| 12:54.31 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 13:09.28 | Notify | 03BRL-CAD:vladbogo * 62044 brlcad/trunk/src/libfb/if_qt.cpp: Handle mouse events |
| 13:19.15 | *** join/#brlcad vladbogo (~vlad@86.121.97.131) | |
| 13:25.58 | Notify | 03BRL-CAD:zhaoanqing * 62045 brlcad/branches/nmgreorg/src/libnmg/primitives/nmg/nmg_plot.c: remove a sentence of test code. |
| 13:50.30 | *** join/#brlcad Izakey (~Izakey@195.24.220.16) | |
| 13:59.18 | *** join/#brlcad konrado (~konrado@195.24.209.21) | |
| 13:59.34 | *** join/#brlcad teepee (~teepee@gateway/tor-sasl/teepee) | |
| 14:16.15 | *** join/#brlcad clock (~clock@77-58-143-135.dclient.hispeed.ch) | |
| 14:30.07 | *** join/#brlcad teepee (~teepee@gateway/tor-sasl/teepee) | |
| 14:39.48 | tofu_ | ries: going |
| 14:40.03 | brlcad | along with three others for brl-cad |
| 14:40.05 | ries | brlcad: Hey Sean |
| 14:40.21 | ries | brlcad: it would be nice to meet |
| 14:43.22 | brlcad | absolutely, it'll be kind of hard to miss each other actually :) |
| 14:44.26 | ries | sounds like a date? |
| 14:45.08 | brlcad | sure |
| 14:45.42 | ries | great.. I will confirm to GSoC that I am going |
| 14:46.17 | brlcad | this year is going to be very different from past years, so it'll be interesting |
| 14:50.02 | ries | brlcad: I wouldnât know.. but I would be very intersted to see some faces behind the names |
| 14:50.13 | ries | meet some smart people... |
| 14:55.46 | *** join/#brlcad Zhao_Anqing (~clouddrif@183.157.160.9) | |
| 15:03.27 | *** join/#brlcad clock (~clock@77-58-143-135.dclient.hispeed.ch) | |
| 15:20.26 | Notify | 03BRL-CAD:ejno * 62046 brlcad/trunk/src/conv/3dm/conv3dm-g.cpp: use ONX_Model::WireframeColor() rather than looking up colors |
| 15:33.57 | brlcad | ries: it's a really interesting event, one of my favorite I look forward to every year |
| 15:35.19 | brlcad | you do get to meet lots of interesting people across a huge spectrum of software development, but all open source proponents |
| 15:35.34 | brlcad | just about every major project represented in some form, often with the leads of those projects there |
| 15:37.18 | Notify | 03BRL-CAD:ejno * 62047 brlcad/trunk/src/libgcv/bot_solidity.h: use __BEGIN_DECLS/__END_DECLS in bot_solidity.h |
| 15:48.11 | Notify | 03BRL-CAD:starseeker * 62048 (brlcad/branches/framebuffer-experiment/include/fb.h brlcad/branches/framebuffer-experiment/src/libdm/dm_obj.c and 5 others): do a bit of refactoring, start thinking about interface to replace the open_existing setup... |
| 15:53.05 | Notify | 03BRL-CAD:starseeker * 62049 (brlcad/branches/framebuffer-experiment/include/fb.h brlcad/branches/framebuffer-experiment/src/libdm/dm_obj.c and 5 others): Whoops, broke something - revert |
| 16:00.07 | ries | brlcad: great! We are working here at home to make it happen |
| 16:02.50 | Notify | 03BRL-CAD:carlmoore * 62050 (brlcad/trunk/doc/docbook/system/man1/en/pixtile.xml brlcad/trunk/src/util/pixtile.c): remove -h highresolution in pixtile; implement -h and -? for help; touch up the man page (and remove -h usage from it) |
| 16:04.30 | brlcad | starseeker: a struct containing a magic number and a void* should work for open_existing |
| 16:04.54 | Notify | 03BRL-CAD:starseeker * 62051 brlcad/branches/framebuffer-experiment/src/libfb/fb_generic.c: Consolidate the lists - needed to offset to account for the /dev/ in the if_name for string comparison. |
| 16:05.05 | brlcad | the implementation can validate that the right type of data was passed with the magic number, cast it from void to a proper type to work with it |
| 16:05.58 | brlcad | is excited by the libfb cleanup |
| 16:08.47 | starseeker | brlcad: so we just have separate definitions of the container structs that get fed to the void* in libdm and libfb? |
| 16:09.18 | starseeker | keep them in sync so everthing works, but internal to each lib and not part of the public API? |
| 16:09.56 | brlcad | sounds reasonable for something low level like this |
| 16:10.00 | brlcad | would suggest on the fb vs. fb_s to make fb be the public instead of fb_s, and the former fbio/fb struct becoming something obvious like fb_impl or fb_private |
| 16:10.15 | starseeker | nods |
| 16:10.18 | brlcad | could even make libdm depend on libfb (but not the other way around) |
| 16:10.25 | brlcad | so it could use the same struct |
| 16:10.38 | brlcad | if dm needs to know about fb's then that make sense |
| 16:10.39 | starseeker | you mean allow libdm to use libfb's private API? |
| 16:10.56 | brlcad | no, this would be public fb api |
| 16:11.17 | starseeker | is trying not to have any platform specific details in either public API (that's the goal, anyway...) |
| 16:11.26 | brlcad | right |
| 16:11.32 | brlcad | that's the point of the magic+void* |
| 16:11.52 | starseeker | right, but the container struct by definition will have platform specific details |
| 16:12.05 | brlcad | it's a public struct in libfb like struct fb_platform_specific { int32_t magic; void *interface; } |
| 16:12.07 | starseeker | if it's part of libfb's public API too (so libdm can use the same definition) we're back in the soup |
| 16:12.25 | brlcad | then open_existing takes a struct fb_platform_specific* |
| 16:12.50 | starseeker | but the interface has to have the right X11/ogl/whatever voodo, and both libdm and libfb have to know about that voodo |
| 16:13.03 | starseeker | (internally) |
| 16:13.14 | brlcad | when X11_open_existing gets that "fpsp", it makes sure fpsp->magic is an X11 magic, casts interface to whatever X11 thingy it needs |
| 16:13.28 | brlcad | only each interface needs to know about their type |
| 16:13.36 | starseeker | brlcad: it's not one X11 thing though, as near as I can tell - it's a set |
| 16:14.39 | brlcad | but that's fine .. the void* can be anything |
| 16:14.56 | brlcad | the if_* defines what that void*interface is expected to be |
| 16:15.06 | brlcad | could be a struct with 1000 pointers specific to that interface |
| 16:15.07 | starseeker | sure, but my point is both libfb and libdm need to know about what's inside the void - that needs to be shared info |
| 16:15.26 | starseeker | but not expressed explicitly in the libfb API |
| 16:15.41 | brlcad | bingo |
| 16:16.01 | brlcad | it's all about hiding the type .. obviously at some point they need to know and have platform specific types to work with |
| 16:16.07 | brlcad | no way around that :) |
| 16:16.37 | brlcad | this just makes both api's type-agnostic to any platform-specific detail while letting the front-end application do back-end work for the library |
| 16:17.15 | starseeker | nods |
| 16:17.34 | brlcad | so long as the app is creating the context, and not the lib, there's no way around it |
| 16:17.40 | brlcad | s/the lib/a lib/ |
| 16:18.04 | starseeker | that's what I thought |
| 16:18.22 | brlcad | but you can entirely hide that type |
| 16:18.25 | starseeker | so we add the magic number for validation, and the void* hids the messy details for libfb to unpack |
| 16:18.33 | brlcad | by just making it "data" |
| 16:19.02 | starseeker | OK, I think I see now |
| 16:19.08 | brlcad | the app creates a context, turns it into data (casts to void and stashes it in a struct or a struct in a struct) |
| 16:19.23 | starseeker | and sets the magic so libfb knows what to do |
| 16:19.25 | brlcad | the app WILL need to know what the fb interface is expecting |
| 16:19.29 | brlcad | that's the point of the magic number |
| 16:19.47 | brlcad | if it's not the right magic number, then something is WAY off... :) |
| 16:20.44 | starseeker | but what it's expecting (the platform specific details) aren't called out in libfb's public API but are internal to each backend, and it's the responsibility of the libdm front-end to check that and handle it |
| 16:20.44 | *** join/#brlcad konrado (~konrado@195.24.209.20) | |
| 16:21.21 | brlcad | it's called out in libfb in terms of data, not API |
| 16:22.05 | starseeker | doesn't quite follow - do (for example) the Display and Window types specific to X11 need to be visible anywhere in fb.h? |
| 16:23.11 | starseeker | is hoping not, even though that does make "syncing" the libdm and libfb communications expectations more difficult... |
| 16:23.12 | brlcad | so somewhere, it'll be written .. whether in a text file or some header or some comment that 0x1234aabb means that void* is a struct containing an X11 Display* and Window* |
| 16:23.32 | brlcad | 0x1234aabb being a magic number |
| 16:23.46 | starseeker | maybe fb/X11.h, which is included by libdm's dm-X.c but not by fb.h? |
| 16:24.33 | brlcad | my gut says make it part of the doxygen comment for fb_open_existing() with a list of the currently known mappings |
| 16:24.52 | brlcad | or whatever function, whereever it ends up |
| 16:25.39 | brlcad | it's like documenting that printf's first parameter is a format string ... and there's this wierd set of "%" symbols followed by characters that it understands |
| 16:25.49 | brlcad | so it could even be in a man page |
| 16:26.46 | brlcad | it only needs to live in one place as documentation, and any time someone changes an interface, they should also change the magic number |
| 16:27.06 | starseeker | is having an fb/X11.h header that's included locally in libdm's individual back-end implementations not a good approach then? was liking that, since the compiler can still check that the libfb and libdm backends are correct even though the struct definition isn't part of the public fb.h... |
| 16:27.08 | brlcad | it's not great, but it's really one of only a few ways possible without exposting the type |
| 16:28.42 | brlcad | that sort of / technically makes it public fb API though |
| 16:28.50 | brlcad | the issue there is that it exposes the X11 types in the header if you actually declare the struct anywhere besides the front-end or back-end |
| 16:29.17 | brlcad | by itself, not an issue, but it's not very dissimilar from what we currently do |
| 16:29.28 | starseeker | brlcad: what if we wrap the header (like how we're talking about doing for the individual bu/bn/etc. headers) so inclusion fails outside of BRL-CAD? |
| 16:29.56 | starseeker | fb.h wouldn't have it, so someone would have to dive for it specifically |
| 16:30.14 | brlcad | if it's useful to us, then it'd be just as useful to anyone else wanting to make use of an open_existing interface, no? |
| 16:30.30 | brlcad | give it a try |
| 16:30.32 | starseeker | ideally, we'd be the only ones who ever need open_existing |
| 16:31.15 | brlcad | nah, that's a *really* common operation if you're building an application |
| 16:31.20 | starseeker | if someone else *does* need open_existing, then they're presumably doing their on "libdm-ish" work |
| 16:31.28 | brlcad | at least if you work with more than one toolkit |
| 16:31.38 | brlcad | (e.g., Qt and OGRE) .. |
| 16:32.03 | brlcad | both have means to get at the context so you can work with it instead of having to go through them for that very reason |
| 16:32.13 | brlcad | granted, not always a polished interface, lots of caveats |
| 16:32.28 | starseeker | will do some experimenting - obviously, my goal is to make the openscenegraph framebuffer/display manager integration a bit easier |
| 16:32.47 | brlcad | fairly certain the known embeddings of libdm in 4-5 other apps use the open_existing interface today |
| 16:32.52 | starseeker | since I had to understand how all this works anyway, figured I'd start by trying some clean-up |
| 16:33.14 | brlcad | especially those java apps |
| 16:33.21 | starseeker | nods |
| 16:34.03 | starseeker | brlcad: I'm almost dead certain this will break external codes, so should I hold off merging back to trunk until after the 7.26.0 release? |
| 16:34.23 | brlcad | almost certainly :) |
| 16:34.47 | ``Erik | yeesh, activity explosion when ya'll should be at lunch O.o :) |
| 16:35.04 | brlcad | to me, the point is to make the interface-specfic construct "data" and pass it blindly to the library .. where/how the construct is documented almost doesn't matter as long as it's separate from what we'd call public libfb API |
| 16:35.48 | starseeker | can't wait to see how this goes... merge from framebuffer branch to osg branch, then merge that whole thing into trunk (eventually) |
| 16:35.53 | starseeker | brlcad: makes sense |
| 16:35.55 | brlcad | a header would be convenient, but then have to take steps to make sure those are never included |
| 16:36.03 | starseeker | nods |
| 16:36.06 | starseeker | ``Erik: howdy stranger |
| 16:36.12 | starseeker | how's life? |
| 16:36.28 | brlcad | "the safe way" is to just put it in a comment and let apps "fill out their format string correctly" |
| 16:37.01 | ``Erik | ticking along O.o with the api, keep ffi in the back of your mind, lcd may not feel great, but ffi likes it |
| 16:37.26 | starseeker | lcd? |
| 16:37.32 | ``Erik | lowest common denominator |
| 16:37.34 | starseeker | ah |
| 16:38.17 | ``Erik | note that every time something like c++ creeps into the api, ffi gets at least an order of mangitude uglier/trickier :) |
| 16:38.37 | starseeker | nods - shouldn't be any C++ at the fb.h/dm.h level |
| 16:39.18 | ``Erik | it's an example, take it as such :) |
| 16:39.33 | starseeker | ``Erik: do void pointers to data also cause trouble? |
| 16:39.47 | starseeker | doesn't see a way around that here |
| 16:40.14 | starseeker | is there an ffi routine in swig that takes a text description of how to unpack a C struct from a void? |
| 16:40.25 | starseeker | or parse a doxygen comment even? |
| 16:40.27 | ``Erik | if the api ever views the void* as anything other than a magic box, yes... if it's never cast to anything, no |
| 16:40.53 | ``Erik | hand waves some over that statement to reduce his queasiness |
| 16:41.16 | starseeker | that should only come up if someone wants to replace either the libfb or the libdm component with their own foreign language replacement |
| 16:41.24 | starseeker | speaking of feeling queasy |
| 16:41.29 | ``Erik | swig 2 is actually pretty good at dealing with basic c++ |
| 16:42.41 | ``Erik | (opennurbs is not basic c++, and has been an issue recently here) |
| 16:43.45 | starseeker | ``Erik: the solution is obvious - re-code openNURBS as a C library ;-) |
| 16:44.05 | starseeker | even have the libnurbs sourceforge project page |
| 16:44.38 | ``Erik | heh, obviously :D or wrap it in a C interface, as that's still the lingua franca of computer interfaces |
| 16:45.35 | ``Erik | <-- kinda thought libbrep was working towards being a C wrapper for opennurbs |
| 16:46.19 | starseeker | might evolve that way - right now, it's the holding container for all the NURBS bits we need to write that openNURBS yanked out or otherwise doesn't provide |
| 16:47.59 | Notify | 03BRL-CAD:carlmoore * 62052 (brlcad/trunk/doc/docbook/system/man1/en/pixuntile.xml brlcad/trunk/src/util/pixuntile.c): make similar changes for pixuntile program & man page; also, change 'chucks' to 'chunks' |
| 16:48.03 | ``Erik | I rememeber the good old days when ya just had triangles... sometimes tristrips and trifans... |
| 16:49.16 | starseeker | heh |
| 16:49.18 | ``Erik | I also remember a thing called lunch, might be worth scheduling in the next couple of weeks |
| 16:49.24 | starseeker | agrees |
| 16:49.29 | ``Erik | cuz ya'll don't seem to be doing it anymore |
| 16:53.25 | starseeker | heeds ``Erik's prodding and goes to hunt down lunch |
| 16:57.53 | ``Erik | not today, of course... I have taters baking in the oven :D |
| 16:58.29 | ``Erik | or rather, no with me today |
| 17:07.02 | Notify | 03BRL-CAD:starseeker * 62053 brlcad/branches/framebuffer-experiment/include/fb.h: Stub in Sean's idea of an fb_platform_specific container with magic number. |
| 17:15.29 | brlcad | ``Erik: possibly/probably another offsite week of the 18th |
| 17:27.02 | Notify | 03BRL-CAD:zhaoanqing * 62054 (brlcad/branches/nmgreorg/include/raytrace.h brlcad/branches/nmgreorg/src/CMakeLists.txt and 11 others): reverting changes back to 62036 in order to preserve the file histories |
| 19:03.56 | *** join/#brlcad andrei_ (~IceChat77@188.25.162.94) | |
| 19:07.45 | *** join/#brlcad konrado (~konrado@195.24.209.22) | |
| 19:09.23 | konrado | brlcad: hello |
| 19:10.54 | *** join/#brlcad clock (~clock@77-58-143-135.dclient.hispeed.ch) | |
| 19:13.14 | *** join/#brlcad konrado_ (~konrado@195.24.209.22) | |
| 19:19.40 | *** join/#brlcad konrado (~konrado@195.24.209.22) | |
| 19:36.12 | Notify | 03BRL-CAD:carlmoore * 62055 (brlcad/trunk/doc/docbook/system/man1/en/bw3-pix.xml brlcad/trunk/doc/docbook/system/man1/en/pix-bw3.xml): for bw3-pix and pix-bw3, use <command> when the text references the command being described |
| 20:21.34 | *** join/#brlcad konrado (~konrado@195.24.209.22) | |
| 20:58.22 | *** join/#brlcad konrado (~konrado@195.24.209.22) | |
| 21:44.38 | *** join/#brlcad konrado (~konrado@195.24.209.22) | |
| 22:59.45 | *** join/#brlcad konrado (~konrado@195.24.209.22) | |
| 23:14.49 | Notify | 03BRL-CAD Wiki:Vladbogolin * 7651 /wiki/User:Vladbogolin/GSoC2014/Logs: /* Week 12 */ |
| 23:33.59 | *** join/#brlcad ankesh11 (sid8015@gateway/web/irccloud.com/x-lucrjkqshsybwqgn) | |