Re: [brlcad-devel] New bu_opt_parse handling

2013-09-22 Thread Christopher Sean Morrison
On Sep 22, 2013, at 6:14 PM, Tom Browder wrote: > We find that the hypot function is a C99 function (see man hypot). > > So what is the approved solution for that? Macro guards? If we test for the function in CMakeLists.txt, it will almost certainly pass a function test but will fail a header

Re: [brlcad-devel] New bu_opt_parse handling

2013-09-22 Thread Christopher Sean Morrison
On Sep 22, 2013, at 5:06 PM, Tom Browder wrote: > Okay, I added this to misc/CMake/CompilerFlags.cmake: > > BRLCAD_CHECK_C_FLAG("std=c89" BUILD_TYPES Debug) > BRLCAD_CHECK_C_FLAG("pedantic" BUILD_TYPES Debug) > > Should that do the trick with a Debug build? The conformance flags should be bu

Re: [brlcad-devel] New bu_opt_parse handling

2013-09-22 Thread Tom Browder
On Sun, Sep 22, 2013 at 4:06 PM, Tom Browder wrote: > On Thu, Sep 12, 2013 at 11:37 AM, Christopher Sean Morrison> > wrote: >> Still, the measure for migrating to C99 has been demonstrating >> (and making the accommodations for) a strict C89 posix compilation baseline. > Okay, I added this to mi

Re: [brlcad-devel] New bu_opt_parse handling

2013-09-22 Thread Tom Browder
On Thu, Sep 12, 2013 at 11:37 AM, Christopher Sean Morrison wrote: > Still, the measure for migrating to C99 has been demonstrating > (and making the accommodations for) a strict C89 posix compilation baseline. > Basically, it's a matter of setting the compilation flags to strict C89 mode > and fi

Re: [brlcad-devel] Qt display manager

2013-09-22 Thread Vlad Bogolin
Hi, As a conclusion to your GSoC project you should write down what was > achieved and what's still open ("not implemented" functions, frame > buffer, ...) > > I have made a summary wiki page of my project that can be found here: http://brlcad.org/wiki/User:Vladbogolin/GSoC2013/qt-display-manager

Re: [brlcad-devel] New bu_arg handling: another idea

2013-09-22 Thread Tom Browder
On Sun, Sep 22, 2013 at 11:48 AM, Tom Browder wrote: > On Sun, Sep 22, 2013 at 11:22 AM, Tom Browder wrote: >> On Fri, Sep 20, 2013 at 8:13 AM, Tom Browder wrote: > .. > However, maybe a macro can hide the arg type flag from the user on the > C side. Something like: ... Okay, I think I have a

Re: [brlcad-devel] New bu_arg handling: another idea

2013-09-22 Thread Tom Browder
On Sun, Sep 22, 2013 at 11:22 AM, Tom Browder wrote: > On Fri, Sep 20, 2013 at 8:13 AM, Tom Browder wrote: .. > Ref different structs for different arg types: The arg type flag > would still be required AFAIK unless we can use some C++ magic (will > RTTI work?) on that side to disambiguate the

Re: [brlcad-devel] New bu_arg handling: another idea

2013-09-22 Thread Tom Browder
On Fri, Sep 20, 2013 at 8:13 AM, Tom Browder wrote: > One problem with static initialization that's been bothering me is how > to get info back from the C++ side without a pointer. > > Couldn't we use a pipe or read/write data to a tmp file? (Or shared memory?) I just committed a new static API

[brlcad-devel] Summary of my GSoC experience.

2013-09-22 Thread Kesha Shah
Hi all, This is the first year in which I was eligible for GSoC program and was selected by the highly esteemed open source community BRL-CAD. Before joining the project, I had just the glimpse of how large code bases are maintained, but had never got hands on experience with them. I used git vers