| 00:03.08 | *** join/#brlcad ries (~ries@190.9.171.121) |
| 01:17.59 | *** join/#brlcad ries (~ries@190.9.171.121) |
| 01:38.54 | *** join/#brlcad ries (~ries@190.9.171.121) |
| 01:59.26 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 02:13.06 | *** join/#brlcad hoiji (671b082a@gateway/web/cgi-irc/kiwiirc.com/ip.103.27.8.42) |
| 02:14.52 | *** join/#brlcad ries (~ries@190.9.171.121) |
| 02:44.46 | *** join/#brlcad ries (~ries@190.9.171.121) |
| 02:49.42 | *** join/#brlcad stevegt_ (~stevegt@50.242.72.226) |
| 02:56.09 | hcurtis | brlcad: Sean, are you available? |
| 03:37.52 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) |
| 03:46.22 | Notify | 03BRL-CAD:starseeker * 60387 brlcad/branches/openscenegraph/CMakeLists.txt: Gah. Ubuntu is apparently adding --as-needed to ld linking by default now (http://stackoverflow.com/questions/8814707/shared-library-mysteriously-doesnt-get-linked-to-application) which in turn messed up the openscenegraph linking for BRL-CAD. Better solution here is to figure out *why* it's concluding it doesn't need those libraries, but |
| 03:46.24 | Notify | until then here's a temporary work-around... |
| 03:49.01 | starseeker | what the hey... |
| 04:41.51 | *** join/#brlcad merzo (~merzo@42-25-132-95.pool.ukrtel.net) |
| 05:08.11 | Notify | 03BRL-CAD Wiki:Krajkreddy * 7015 /wiki/User:Krajkreddy/GSOC14/proposal: /* Update Timeline. Remove Primitives which are not used. Also add a detailed plan for BREP. */ |
| 05:10.34 | Notify | 03BRL-CAD Wiki:Krajkreddy * 7016 /wiki/User:Krajkreddy/GSOC14/proposal: /* Refactor style */ |
| 05:14.35 | Notify | 03BRL-CAD Wiki:Krajkreddy * 7017 /wiki/User:Krajkreddy/GSOC14/proposal: |
| 05:23.58 | brlcad | hcurtis: note this: |
| 05:24.00 | brlcad | ~ask |
| 05:24.00 | infobot | Questions in the channel should be specific, informative, complete, concise, and on-topic. Don't ask if you can ask a question first. Don't ask if a person is there; just ask what you intended to ask them. Better questions more frequently yield better answers. We are all here voluntarily or against our will. |
| 05:27.26 | *** join/#brlcad ries (~ries@190.9.171.121) |
| 05:36.12 | brlcad | starseeker: if you had to add -no-as-needed, then the build flags are wrong somewhere |
| 05:37.26 | brlcad | that stackoverflow is a little bit misguiding (not just because of LD_PRELOAD, but the command-line args are ordered wrong) |
| 05:37.44 | brlcad | https://wiki.gentoo.org/wiki/Project:Quality_Assurance/As-needed |
| 05:39.49 | brlcad | basically, it's linking an exe that doesn't use OSG (which is true, probably only libdm is using it OSG) |
| 05:42.31 | brlcad | so the lib gets the symbols but the app should not, nor should libs using the lib (unless they directly have osg symbols being referenced) |
| 05:43.13 | brlcad | it's like our headers -- each lib and exec link line is supposed to only list exactly what is actually used |
| 06:11.13 | *** join/#brlcad caen23 (~caen23@92.81.212.37) |
| 07:23.10 | *** join/#brlcad caen23 (~caen23@92.81.212.37) |
| 07:59.02 | FreezingCold | I'm thinking of writing/paying for a project that generates and simulates the path of a cartesian robot, would brlcad be a decent base to start off of? |
| 08:01.03 | archivist | FreezingCold, vismach in linuxcnc |
| 08:04.07 | FreezingCold | that seems to only be a visual simulator |
| 08:04.13 | FreezingCold | not a path generator or anything |
| 08:07.16 | archivist | path generation depends on use |
| 08:20.50 | *** join/#brlcad luca79 (~luca@host12-111-dynamic.5-87-r.retail.telecomitalia.it) |
| 08:59.31 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 11:11.50 | brlcad | FreezingCold: what are the outputs o your simulation? |
| 11:13.47 | brlcad | certainly wouldn't be hard at all with brl-cad as a base to set up a model and performs route/path planning (e.g., using ray tracing to find paths) |
| 11:17.48 | brlcad | in fact, I had high school students with very little experience that wrote a very similar program -- the created maze geometry and an automatic path finder that would find a route from a defined start and end point |
| 12:17.49 | *** join/#brlcad ries (~ries@190.9.171.121) |
| 12:40.34 | *** join/#brlcad drv_ (~smuxi@dynamic-78-8-246-104.ssp.dialog.net.pl) |
| 13:33.04 | starseeker | brlcad: I didn't have to add it to successfully build, but the osg display manager crashed unless I built with it |
| 13:33.36 | starseeker | which probably indicates I'm doing something else wrong, but I can't imagine what |
| 13:34.23 | *** join/#brlcad infinite__ (~infinite@14.139.122.114) |
| 13:34.38 | *** join/#brlcad infinite__ (~infinite@14.139.122.114) |
| 13:35.02 | *** join/#brlcad caen23 (~caen23@92.81.212.37) |
| 13:41.34 | *** join/#brlcad Denis_ (~denisilie@141.85.0.116) |
| 13:54.04 | starseeker | brlcad: we may be dealing with that "Initializers and Deconstructors" case, although I'm not sure yet - src/other/openscenegraph/src/osg/GraphicsContext.cpp:47 in a debugger shows that s_WindowingSystemInterface is non-NULL without the --as-needed, and NULL with it |
| 14:06.20 | *** join/#brlcad gaganjyot__ (~gagan@27.255.252.57) |
| 14:19.57 | *** join/#brlcad luca79 (~luca@ge-19-100-237.service.infuturo.it) |
| 14:36.28 | *** join/#brlcad infinite__ (~infinite@14.139.122.114) |
| 14:38.40 | brlcad | starseeker: it's the "Failure in execution, undefined symbols" case |
| 14:39.37 | brlcad | that init and destructor case is very specific -- you'd have to only create objects and not make any other function calls, and that's clearly not what you've written |
| 14:40.26 | brlcad | the problem is described in that section: "a directly-linked library did not link one of its dependencies" |
| 14:41.36 | brlcad | in this case, you're linking libosg or some library, but their build system is not properly specifying a library that it's using (demonstrated by your debugging find) |
| 14:47.15 | *** join/#brlcad caen23 (~caen23@92.81.212.37) |
| 14:47.40 | starseeker | brlcad: OK, I'll experiment |
| 14:48.17 | brlcad | just looked through their sources and that does look to be the point where they bind to the host interface graphics system |
| 14:48.50 | brlcad | and they're doing it through some obfuscating reference pointer masking, which is almost certainly why it's a getting lost as a runtime crash |
| 14:51.35 | starseeker | is a trifle confused - the windowing specific stuff is in osgViewer, but that requires osg (not the other way around) |
| 14:53.14 | starseeker | is tempted just to build all these pieces into one big osg library... |
| 14:53.48 | starseeker | but I suppose that wouldn't address the problem if we use a system version of osg, which will be set up similarly |
| 14:54.35 | starseeker | looks at the original CMake build for osg - perhaps I mistranslated something |
| 14:55.06 | brlcad | what about just adding --no-as-needed to their build? |
| 14:55.15 | brlcad | or did I misread and that's what you did? |
| 14:55.26 | brlcad | thought it was to our build |
| 14:55.34 | starseeker | yeah, added it to our build |
| 14:55.41 | starseeker | I can try it in theirs and see if that fixes it |
| 14:55.46 | brlcad | it should |
| 14:56.05 | brlcad | they're the one not specifying their own lib breakout fully and that's almost certainly the cause |
| 14:56.29 | brlcad | i mean, they have 20 libs and they'd have to fully specify all of them IN THE PROPER ORDER |
| 14:56.41 | brlcad | get just one dep wrong and you'd see this issue |
| 14:58.01 | brlcad | building our stuff with as-needed is actually a pretty good test of our build logic .. that was hard to get working right with autotools too |
| 14:59.12 | brlcad | there are some platforms where there is no concept of --no-as-needed, so you HAVE to fix the linkages (aix I think is like this) |
| 15:00.37 | starseeker | joy |
| 15:00.50 | starseeker | wonder if osg will accept patches |
| 15:02.46 | brlcad | well, they should fix their build by not using no-as-needed |
| 15:03.18 | brlcad | but that's going to be more tricky and likely require one of their devs that is more familiar with their symbols and deps |
| 15:03.20 | starseeker | would be surprised if they specify that... probably just "getting away with it" |
| 15:04.04 | starseeker | growls... was having enough fun without this on top of it... |
| 15:04.25 | starseeker | nope, didn't do it |
| 15:05.46 | starseeker | libdm's ldd output is still showing only libosg.so |
| 15:05.52 | starseeker | didn't bring in the others |
| 15:06.42 | brlcad | eh? you call other symbols? |
| 15:07.06 | brlcad | libdm should only show libs that it directly calls symbols on |
| 15:07.46 | starseeker | well, somehow (not clear to me how) when MGED starts up some of osgViewer's routines are used to initialize things |
| 15:08.13 | starseeker | if that doesn't work, that seems to be what results in s_WindowingSystemInterface being NULL |
| 15:08.44 | brlcad | sure, but it's whether dm actually calls osgViewer functions or whether it calls an osg symbol that calls osgViewer symbols |
| 15:09.01 | brlcad | my quick look seemed like the latter was going on |
| 15:09.02 | starseeker | but osg will never pull in osgViewer, since osgViewer depends on osg |
| 15:09.10 | starseeker | per the build system |
| 15:09.58 | brlcad | well that would likely be an issue, perhaps the issue |
| 15:10.09 | brlcad | if there's a cyclic lib dependency for example |
| 15:10.28 | brlcad | they both depend on each other is a valid state they could be in |
| 15:10.30 | starseeker | that's going to be a problem even with a system version of the libs |
| 15:11.12 | starseeker | so... should libdm do something to make sure osgViewer is brought on-board somehow? |
| 15:11.56 | brlcad | I'd only expect that if it calls osgViewer functions |
| 15:12.04 | starseeker | growl... |
| 15:12.08 | brlcad | what happens if you just tell their build that osg depends on osgViewer? |
| 15:12.19 | starseeker | then the build system has a cyclic dependency |
| 15:12.22 | brlcad | or not depends, but actually add it to osg's link line |
| 15:12.33 | brlcad | so? |
| 15:12.39 | starseeker | which one does Make build first? |
| 15:13.50 | brlcad | I would expect osgViewer and their depends is wrong |
| 15:14.18 | starseeker | tries osgViewer without osg to see what happens... |
| 15:15.24 | brlcad | could also test what happens if libdm is told to link both osg and osgViewer |
| 15:16.01 | brlcad | but I suspect it's the way that osg is linked that is the problem |
| 15:16.22 | starseeker | is telling libdm to link both now - it's not enough |
| 15:16.33 | starseeker | the as-needed thing seems to be striping it out |
| 15:20.32 | brlcad | right, that's what I figured |
| 15:21.04 | brlcad | that s_WindowingSystemInterface is problematic, it's untyped |
| 15:21.28 | brlcad | so the linker needed to know when osg was built what it needed to be |
| 15:21.56 | brlcad | you did specify them in the right order, yes? :) |
| 15:22.07 | brlcad | (when testing libdm linking both) |
| 15:22.32 | starseeker | no idea |
| 15:23.18 | starseeker | ok, even when I built osg after osgVIewer and explicitly added osgViewer to osg's library list, ldd *still* doesn't show osgViewer as hooked up to libosg |
| 15:24.23 | brlcad | ldd shouldn't matter -- libosg becomes resolved |
| 15:25.30 | brlcad | maybe a relatable example: I could build a librt that does NOT depend on libbu/libbn/etc, fully resolving all of the symbols when I build librt |
| 15:26.11 | starseeker | erm. Wouldn't that take some special options to make happen? |
| 15:26.23 | starseeker | kinda thought that's what static libraries were all about |
| 15:27.27 | starseeker | continuing with build to test and see... |
| 15:28.09 | brlcad | it's very similar to static libs, but you can actually construct a lib that resolves it's symbols without colliding symbols (at least on some platforms) |
| 15:28.24 | brlcad | and that are not static libs |
| 15:28.41 | ``Erik | -F/dev/osg ? does this mean no ogre or mged-v3? |
| 15:28.58 | brlcad | so you write an app that uses -lrt .. and you can't call bu_log without adding -lbu, but all of the bu_log's in -lrt are fully resolved |
| 15:29.00 | starseeker | ``Erik: right now, trying openscenegraph |
| 15:29.18 | starseeker | brlcad: ah, gotcha |
| 15:29.37 | starseeker | ``Erik: doesn't impact 3rd gen interface |
| 15:30.18 | ``Erik | hm, gonna try to wedge BRL-CAD in under VSL if this dm pans out? :D |
| 15:30.35 | starseeker | VSL's use of it is one of the factors |
| 15:30.38 | brlcad | which is basically what you're doing .. you've got an -losg and you're saying it needs symbols from osgViewer but they're not resolved so you're getting a runtime crash |
| 15:30.48 | brlcad | ``Erik: of course that's exactly what he's doing :) |
| 15:31.22 | starseeker | still crashing |
| 15:31.26 | starseeker | let me commit what I tried |
| 15:31.39 | ``Erik | heh, and watch it become the new tcl/s2 problem down the road O:-) |
| 15:32.10 | brlcad | starseeker: well if this goes much longer, can just try at least isolating --no-as-needed to libdm instead of everything |
| 15:32.37 | brlcad | yay, black box found |
| 15:32.54 | Notify | 03BRL-CAD:starseeker * 60388 (brlcad/branches/openscenegraph/src/other/openscenegraph/CMakeLists.txt brlcad/branches/openscenegraph/src/other/openscenegraph/src/CMakeLists.txt and 2 others): Try to get osg to be aware of osgViewer from the get-go (didn't seem to work...) |
| 15:32.55 | ``Erik | the malaysian flights? |
| 15:33.15 | brlcad | yeah, http://www.telegraph.co.uk/news/worldnews/asia/china/10746529/Malaysia-Airlines-MH370-black-box-ping-detected-reports.html?fb |
| 15:33.56 | brlcad | starseeker: note that this is all predicated on your assertion that osg needs osgViewer ... which I didn't directly see |
| 15:34.19 | starseeker | let me pastebin the backtraces |
| 15:34.25 | starseeker | maybe I'm reading it wrong |
| 15:34.36 | brlcad | i mean it fits the symptoms that there are symbols in one of their other libs, but unclear which |
| 15:35.17 | starseeker | nods - I'll put together the path I've been following |
| 15:35.27 | starseeker | wouldn't surprise me at all if I'm off in the weeds |
| 15:37.35 | brlcad | starseeker: I'm REALLY surprised that adding --no-as-needed to CMAKE_SHARED_LINKER_FLAGS didn't do the trick on a clean rebuild |
| 15:38.03 | brlcad | did you confirm that it was 1) a clean build and 2) actually using no-as-needed when linking libosg and friends? |
| 15:38.06 | Notify | 03BRL-CAD:starseeker * 60389 (brlcad/branches/openscenegraph/src/other/openscenegraph/CMakeLists.txt brlcad/branches/openscenegraph/src/other/openscenegraph/src/CMakeLists.txt and 2 others): Put things back for now, since osgGA seems to be a requirement for osgViewer... |
| 15:38.42 | starseeker | brlcad: I'll double check in a few minutes - let me get my initial setup reproduced before I rework it again |
| 15:39.43 | brlcad | also know that as a C++ API, they very well could have the constructor/initailization problem that you first suspected .. very unlikely but possible with all their reference pointer hiding |
| 15:40.24 | brlcad | but still, adding --no-as-needed in their build really *should* work... |
| 15:42.01 | brlcad | this shows --as-needed working: http://forums.gentoo.org/viewtopic-p-7480400.html |
| 15:42.48 | brlcad | looks like they specifically added it in 3.0.0-2 |
| 15:43.36 | starseeker | maybe it's how I'm calling it then... |
| 15:44.27 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 15:45.43 | *** join/#brlcad gaganjyot__ (~gagan@27.255.252.57) |
| 15:45.54 | starseeker | it's possible too if the library ordering is critical I might have messed it up when I reworked the build |
| 15:46.44 | starseeker | can't help thinking that such ordering *really* shouldn't be necessary - that's very difficult to track in some situations... |
| 15:47.05 | brlcad | heh, it's most definitely necessary |
| 15:47.55 | brlcad | gnu didn't do anyone favors by making their ld search for symbols anywhere on the link line, so much badness |
| 15:48.24 | brlcad | used to be more common to encounter a system where ordering was required for proper resolution |
| 15:49.05 | brlcad | so in a way, kind of refreshing to see --as-needed getting enforced |
| 15:49.38 | brlcad | it'll be easy to tell if you have the ordering right -- what's libdm's link line look like? |
| 15:50.39 | brlcad | should be all the .o's followed by a bunch of our -llibs followed by -l's for system libs (and there should be -losg near the end) |
| 15:51.26 | starseeker | here's the initialization backtrace: http://pastebin.mozilla.org/4764810 |
| 15:54.32 | starseeker | link line: http://pastebin.mozilla.org/4764815 |
| 15:56.36 | brlcad | and that link line works, yes? |
| 15:56.44 | starseeker | yes |
| 15:56.55 | *** join/#brlcad Denis_ (~denisilie@141.85.0.116) |
| 15:56.57 | starseeker | as long as --no-as-needed is present |
| 15:57.31 | brlcad | right, can you try manually running that link without no-as-needed and remove the first instance of libosg (there are two) |
| 15:57.39 | starseeker | one second... |
| 16:00.29 | starseeker | hmm |
| 16:00.37 | starseeker | that *seemed* to have worked |
| 16:00.47 | starseeker | so the question is where that first osg is coming from |
| 16:10.05 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 16:12.22 | starseeker | doesn't work when I take the --no-as-needed out of the toplevel |
| 16:12.33 | starseeker | growl... |
| 16:14.15 | starseeker | huh, *that's* interesting... - when I add it back in to libdm, I see the debug message from the plug-in dir setting but it still doesn't work |
| 16:15.28 | brlcad | this is more and more looking like it's almost certainly an ordering issue |
| 16:15.31 | brlcad | try eliminating all of the osg libs and just add -losg to the end |
| 16:16.26 | brlcad | all of their libs must be ordered correctly if it's actually needing them all |
| 16:17.17 | brlcad | ordering issue would also explain why adding --no-as-needed to osg didn't do anything (and the fact that they've been building with --as-needed for a long time now without others running into this problem) |
| 16:17.17 | Notify | 03BRL-CAD:starseeker * 60390 (brlcad/branches/openscenegraph/CMakeLists.txt brlcad/branches/openscenegraph/src/libdm/CMakeLists.txt and 2 others): Getting closer - don't need the toplevel set |
| 16:17.32 | starseeker | nods |
| 16:17.57 | brlcad | just a matter of binary searching the lib ordering now ;) |
| 16:19.01 | starseeker | still thinks requiring that is a FAIL on the part of the tool chain - at the very least there should be some tool that takes a list of libs and does that testing automatically to generate the right ordering |
| 16:19.08 | starseeker | or, worst case, report why its impossible |
| 16:19.10 | brlcad | also, if this is the first --as-needed compile, keep an eye out for ordering of our libs that could be wrong .. might recheck the stack trace periodically |
| 16:19.49 | brlcad | you can have the same symbol in multiple libs, which should it use? |
| 16:20.36 | starseeker | nods - that's fine if it can't decide (that would in fact be one of the undecidable cases) but a detailed report on what symbols and which libs would be a big help |
| 16:21.13 | starseeker | assuming the dev has full knowledge of all such issues from all libs they're using in this day and age is likely to be a Bad Assumption |
| 16:21.33 | brlcad | but it can decide |
| 16:21.44 | starseeker | based on ordering, sure |
| 16:21.44 | brlcad | and decide determinisitically |
| 16:23.04 | starseeker | but if I've got too 3rd party libs, both of which define FOO and BAR, and I want FOO from the first one and BAR from the second, I've got a problem |
| 16:23.08 | brlcad | the problem is that it can pick libA .. and linking that libA comes with it's own set of symbols that it has to hunt down .. and so on recursively |
| 16:23.38 | brlcad | and it's not strictly a tree, it's any possible network topology |
| 16:23.47 | brlcad | cycles are valid |
| 16:23.55 | starseeker | winces |
| 16:23.58 | brlcad | undesirable, but valid |
| 16:24.20 | brlcad | and with runtime loading, you can't even know when you have certain topologies |
| 16:25.53 | starseeker | wouldn't a coverity-style analysis of the code allow a tool to investigate the runtime possibilities? |
| 16:27.04 | Notify | 03BRL-CAD:starseeker * 60391 (brlcad/branches/openscenegraph/CMakeLists.txt brlcad/branches/openscenegraph/src/other/openscenegraph/CMakeLists.txt): OK, it's down to libfb and libdm |
| 16:27.36 | starseeker | doens't buy it that there exists a situation where the developer can keep track of such interrelatedness and the computer can't... there must be some solution |
| 16:35.13 | brlcad | as long as you prohibit loading a library at runtime by filename, yeah sure .. and some plaforms do that |
| 16:35.56 | brlcad | if you're going to allow runtime symbol insertion, you have to have deterministic symbol resolution ... which is ordering or some explicit table or some other method (all of which exist too) |
| 16:36.15 | brlcad | gets off the dead horse :) |
| 16:36.22 | starseeker | brlcad: narrowing down - libfb is what's providing the first set of osg libs |
| 16:36.38 | starseeker | can turn off libdm's and still work, so that's were the problem can be resolved |
| 16:41.26 | Notify | 03BRL-CAD:starseeker * 60392 (brlcad/branches/openscenegraph/src/libdm/CMakeLists.txt brlcad/branches/openscenegraph/src/libfb/CMakeLists.txt): Narrow down on the problem - libfb is providing the first set of osg libs, and libdm doesn't have to factor in - solve the issue in libfb, and we've got it. |
| 16:50.14 | Notify | 03BRL-CAD:starseeker * 60393 (brlcad/branches/openscenegraph/src/libfb/CMakeLists.txt brlcad/branches/openscenegraph/src/other/CMakeLists.txt): Try adding other osg libraries explicitly in case the ordering needs to be explicit... |
| 16:54.23 | starseeker | brlcad: osg by itself doesn't work. osgViewer by itself does, but only if I keep the no-as-needed |
| 16:59.44 | Notify | 03BRL-CAD:starseeker * 60394 brlcad/branches/openscenegraph/src/libfb/CMakeLists.txt: I can get away at this stage with supplying *ONLY* osgViewer as a library, but I still need the no-as-needed flag or the initialization changes (I don't see my debugging line indicating the plugin directory has been loaded when starting MGED.) |
| 17:00.15 | starseeker | I tried including osg before and after osgViewer, doesn't seem to make a difference... |
| 17:04.29 | starseeker | brlcad: thanks for taking the time to help me work through it |
| 17:05.08 | starseeker | will keep digging, but at least worst case that linker flag can be confined to libfb/libdm |
| 17:11.34 | starseeker | brlcad: another data point, fwiw - windowingSystemInterfaceRef is called even before main in MGED in the working scenario, and never called at all otherwise |
| 17:12.04 | starseeker | can that happen as a consequence of ordering? |
| 17:13.14 | starseeker | or, perhaps a better question, if there *is* in fact a change in initialization per that gentoo page, is there any to make a definitive test for it that will either confirm it or rule it out? |
| 17:26.49 | starseeker | wait a minute... |
| 17:36.36 | starseeker | AH HAH! |
| 17:39.08 | Notify | 03BRL-CAD:starseeker * 60395 (brlcad/branches/openscenegraph/src/libdm/CMakeLists.txt brlcad/branches/openscenegraph/src/libdm/dm-osg.cpp and 2 others): Went too low level in the APIs and wasn't getting the initialization code I needed to call. Short term, create and delete a viewer to make sure all the right setup is called. Longer term, study how the osgviewerFLTK example works in osg and find out if it makes |
| 17:39.10 | Notify | sense to retool how we are embedding osg in Tk. |
| 17:39.35 | starseeker | does happy dance |
| 17:39.42 | starseeker | brlcad: thanks for your help! |
| 18:15.03 | *** join/#brlcad richa (uid11933@gateway/web/irccloud.com/x-uhgiarqtvssdzbao) |
| 18:19.43 | *** join/#brlcad infinite__ (~infinite@14.139.122.114) |
| 18:22.18 | infinite__ | brlcad: Hi! Just wish to enquire if this task www.google-melange.com/gci/task/view/google/gci2012/8095204 is open, because bu_semaphore.c already exists. |
| 18:33.47 | *** join/#brlcad infinite__ (~infinite@14.139.122.114) |
| 18:52.01 | *** join/#brlcad devinder (~chatzilla@202.164.53.117) |
| 19:24.12 | *** join/#brlcad hcurtis (b82d2950@gateway/web/freenode/ip.184.45.41.80) |
| 19:36.07 | infinite__ | can anyone explain what does the argument stand for in nirt -e {fmt r "start (%g %g %g)\n" x_orig y_orig z_orig} |
| 20:06.37 | *** join/#brlcad raj12lnm (6ad889c2@gateway/web/freenode/ip.106.216.137.194) |
| 20:19.17 | *** join/#brlcad Rich80 (~androirc@host86-157-13-66.range86-157.btcentralplus.com) |
| 20:20.24 | *** join/#brlcad infinite__ (~infinite@14.139.122.114) |
| 20:21.37 | Rich80 | Hi, I am a newbie progra |
| 21:05.02 | *** join/#brlcad Rich80 (~androirc@host86-157-13-66.range86-157.btcentralplus.com) |
| 21:10.15 | Rich80 | I am new to programming however I would like to develop a geometry converter between .g files and an XML format called Geometry Description Markup Language. Any help/guidance would be much appreciated. |
| 21:22.00 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) |
| 21:28.53 | *** part/#brlcad gaganjyot__ (~gagan@27.255.252.57) |
| 21:50.47 | *** join/#brlcad merzo (~merzo@42-25-132-95.pool.ukrtel.net) |
| 21:52.10 | *** join/#brlcad infinite (~infinite@14.139.122.114) |
| 22:08.40 | hcurtis | brlcad: Hi, Sean. Thanks to your and starseeker's guidance, I have come a long way. Incidentally, I've made additional improvements to my proposal on Melange, and I'm working on a patch. |
| 22:10.33 | *** join/#brlcad infinite (~infinite@14.139.122.114) |
| 23:20.33 | hcurtis | brlcad: Hi, Sean. I'm working on this as a first patch. http://www.google-melange.com/gci/task/view/google/gci2013/4932878790033408 Do words like “funcs” and “args” count as spelling mistakes? |
| 23:31.58 | *** join/#brlcad merzo (~merzo@42-25-132-95.pool.ukrtel.net) |
| 23:37.54 | *** join/#brlcad ries_nicked (~ries@190.9.171.121) |
| 23:57.43 | *** join/#brlcad Denis (~denisilie@141.85.0.116) |