IRC log for #brlcad on 20140808

01:01.04*** join/#brlcad Zhao_Anqing (clouddrift@222.205.19.237)
01:17.40Notify03BRL-CAD:zhaoanqing * 62036 NIL: create a new dictionary for NMG codes alone.
01:25.01Notify03BRL-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.24Notify03BRL-CAD:zhaoanqing * 62038 brlcad/branches/nmgreorg/src/CMakeLists.txt: update CMakeLists.txt in src to config for new-created libnmg.
01:51.17Notify03BRL-CAD:zhaoanqing * 62039 (brlcad/branches/nmgreorg/src/libnmg/CMakeLists.txt =================================================================== and 119 others): move files from librt into libnmg.
01:57.02Notify03BRL-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.40Notify03BRL-CAD:zhaoanqing * 62041 brlcad/branches/nmgreorg/include/raytrace.h: update raytrace.h to fit the movement from librt to libnmg.
03:12.56Notify03BRL-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.43Notify03BRL-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.30riesany mentors here going to GSoC?
12:45.32Notify03BRL-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.28Notify03BRL-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.58Notify03BRL-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.48tofu_ries: going
14:40.03brlcadalong with three others for brl-cad
14:40.05riesbrlcad: Hey Sean
14:40.21riesbrlcad: it would be nice to meet
14:43.22brlcadabsolutely, it'll be kind of hard to miss each other actually :)
14:44.26riessounds like a date?
14:45.08brlcadsure
14:45.42riesgreat.. I will confirm to GSoC that I am going
14:46.17brlcadthis year is going to be very different from past years, so it'll be interesting
14:50.02riesbrlcad: I wouldn’t know.. but I would be very intersted to see some faces behind the names
14:50.13riesmeet 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.26Notify03BRL-CAD:ejno * 62046 brlcad/trunk/src/conv/3dm/conv3dm-g.cpp: use ONX_Model::WireframeColor() rather than looking up colors
15:33.57brlcadries: it's a really interesting event, one of my favorite I look forward to every year
15:35.19brlcadyou do get to meet lots of interesting people across a huge spectrum of software development, but all open source proponents
15:35.34brlcadjust about every major project represented in some form, often with the leads of those projects there
15:37.18Notify03BRL-CAD:ejno * 62047 brlcad/trunk/src/libgcv/bot_solidity.h: use __BEGIN_DECLS/__END_DECLS in bot_solidity.h
15:48.11Notify03BRL-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.05Notify03BRL-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.07riesbrlcad: great! We are working here at home to make it happen
16:02.50Notify03BRL-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.30brlcadstarseeker: a struct containing a magic number and a void* should work for open_existing
16:04.54Notify03BRL-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.05brlcadthe 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.58brlcadis excited by the libfb cleanup
16:08.47starseekerbrlcad: so we just have separate definitions of the container structs that get fed to the void* in libdm and libfb?
16:09.18starseekerkeep them in sync so everthing works, but internal to each lib and not part of the public API?
16:09.56brlcadsounds reasonable for something low level like this
16:10.00brlcadwould 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.15starseekernods
16:10.18brlcadcould even make libdm depend on libfb (but not the other way around)
16:10.25brlcadso it could use the same struct
16:10.38brlcadif dm needs to know about fb's then that make sense
16:10.39starseekeryou mean allow libdm to use libfb's private API?
16:10.56brlcadno, this would be public fb api
16:11.17starseekeris trying not to have any platform specific details in either public API (that's the goal, anyway...)
16:11.26brlcadright
16:11.32brlcadthat's the point of the magic+void*
16:11.52starseekerright, but the container struct by definition will have platform specific details
16:12.05brlcadit's a public struct in libfb like struct fb_platform_specific { int32_t magic; void *interface; }
16:12.07starseekerif it's part of libfb's public API too (so libdm can use the same definition) we're back in the soup
16:12.25brlcadthen open_existing takes a struct fb_platform_specific*
16:12.50starseekerbut the interface has to have the right X11/ogl/whatever voodo, and both libdm and libfb have to know about that voodo
16:13.03starseeker(internally)
16:13.14brlcadwhen 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.28brlcadonly each interface needs to know about their type
16:13.36starseekerbrlcad: it's not one X11 thing though, as near as I can tell - it's a set
16:14.39brlcadbut that's fine .. the void* can be anything
16:14.56brlcadthe if_* defines what that void*interface is expected to be
16:15.06brlcadcould be a struct with 1000 pointers specific to that interface
16:15.07starseekersure, 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.26starseekerbut not expressed explicitly in the libfb API
16:15.41brlcadbingo
16:16.01brlcadit's all about hiding the type .. obviously at some point they need to know and  have platform specific types to work with
16:16.07brlcadno way around that :)
16:16.37brlcadthis 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.15starseekernods
16:17.34brlcadso long as the app is creating the context, and not the lib, there's no way around it
16:17.40brlcads/the lib/a lib/
16:18.04starseekerthat's what I thought
16:18.22brlcadbut you can entirely hide that type
16:18.25starseekerso we add the magic number for validation, and the void* hids the messy details for libfb to unpack
16:18.33brlcadby just making it "data"
16:19.02starseekerOK, I think I see now
16:19.08brlcadthe 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.23starseekerand sets the magic so libfb knows what to do
16:19.25brlcadthe app WILL need to know what the fb interface is expecting
16:19.29brlcadthat's the point of the magic number
16:19.47brlcadif it's not the right magic number, then something is WAY off... :)
16:20.44starseekerbut 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.21brlcadit's called out in libfb in terms of data, not API
16:22.05starseekerdoesn't quite follow - do (for example) the Display and Window types specific to X11 need to be visible anywhere in fb.h?
16:23.11starseekeris hoping not, even though that does make "syncing" the libdm and libfb communications expectations more difficult...
16:23.12brlcadso 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.32brlcad0x1234aabb being a magic number
16:23.46starseekermaybe fb/X11.h, which is included by libdm's dm-X.c but not by fb.h?
16:24.33brlcadmy gut says make it part of the doxygen comment for fb_open_existing() with a list of the currently known mappings
16:24.52brlcador whatever function, whereever it ends up
16:25.39brlcadit'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.49brlcadso it could even be in a man page
16:26.46brlcadit 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.06starseekeris 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.08brlcadit's not great, but it's really one of only a few ways possible without exposting the type
16:28.42brlcadthat sort of / technically makes it public fb API though
16:28.50brlcadthe 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.17brlcadby itself, not an issue, but it's not very dissimilar from what we currently do
16:29.28starseekerbrlcad: 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.56starseekerfb.h wouldn't have it, so someone would have to dive for it specifically
16:30.14brlcadif 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.30brlcadgive it a try
16:30.32starseekerideally, we'd be the only ones who ever need open_existing
16:31.15brlcadnah, that's a *really* common operation if you're building an application
16:31.20starseekerif someone else *does* need open_existing, then they're presumably doing their on "libdm-ish" work
16:31.28brlcadat least if you work with more than one toolkit
16:31.38brlcad(e.g., Qt and OGRE) ..
16:32.03brlcadboth 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.13brlcadgranted, not always a polished interface, lots of caveats
16:32.28starseekerwill do some experimenting - obviously, my goal is to make the openscenegraph framebuffer/display manager integration a bit easier
16:32.47brlcadfairly certain the known embeddings of libdm in 4-5 other apps use the open_existing interface today
16:32.52starseekersince I had to understand how all this works anyway, figured I'd start by trying some clean-up
16:33.14brlcadespecially those java apps
16:33.21starseekernods
16:34.03starseekerbrlcad: 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.23brlcadalmost certainly :)
16:34.47``Erikyeesh, activity explosion when ya'll should be at lunch O.o :)
16:35.04brlcadto 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.48starseekercan't wait to see how this goes... merge from framebuffer branch to osg branch, then merge that whole thing into trunk (eventually)
16:35.53starseekerbrlcad: makes sense
16:35.55brlcada header would be convenient, but then have to take steps to make sure those are never included
16:36.03starseekernods
16:36.06starseeker``Erik: howdy stranger
16:36.12starseekerhow's life?
16:36.28brlcad"the safe way" is to just put it in a comment and let apps "fill out their format string correctly"
16:37.01``Erikticking 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.26starseekerlcd?
16:37.32``Eriklowest common denominator
16:37.34starseekerah
16:38.17``Eriknote that every time something like c++ creeps into the api, ffi gets at least an order of mangitude uglier/trickier :)
16:38.37starseekernods - shouldn't be any C++ at the fb.h/dm.h level
16:39.18``Erikit's an example, take it as such :)
16:39.33starseeker``Erik: do void pointers to data also cause trouble?
16:39.47starseekerdoesn't see a way around that here
16:40.14starseekeris there an ffi routine in swig that takes a text description of how to unpack a C struct from a void?
16:40.25starseekeror parse a doxygen comment even?
16:40.27``Erikif 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``Erikhand waves some over that statement to reduce his queasiness
16:41.16starseekerthat should only come up if someone wants to replace either the libfb or the libdm component with their own foreign language replacement
16:41.24starseekerspeaking of feeling queasy
16:41.29``Erikswig 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.45starseeker``Erik: the solution is obvious - re-code openNURBS as a C library ;-)
16:44.05starseekereven have the libnurbs sourceforge project page
16:44.38``Erikheh, 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.19starseekermight 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.59Notify03BRL-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``ErikI rememeber the good old days when ya just had triangles... sometimes tristrips and trifans...
16:49.16starseekerheh
16:49.18``ErikI also remember a thing called lunch, might be worth scheduling in the next couple of weeks
16:49.24starseekeragrees
16:49.29``Erikcuz ya'll don't seem to be doing it anymore
16:53.25starseekerheeds ``Erik's prodding and goes to hunt down lunch
16:57.53``Eriknot today, of course... I have taters baking in the oven :D
16:58.29``Erikor rather, no with me today
17:07.02Notify03BRL-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.29brlcad``Erik: possibly/probably another offsite week of the 18th
17:27.02Notify03BRL-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.23konradobrlcad: 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.12Notify03BRL-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.49Notify03BRL-CAD Wiki:Vladbogolin * 7651 /wiki/User:Vladbogolin/GSoC2014/Logs: /* Week 12 */
23:33.59*** join/#brlcad ankesh11 (sid8015@gateway/web/irccloud.com/x-lucrjkqshsybwqgn)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.