ggt-devel — Development discussion list

[ggt-devel] [ ggt-Bugs-1067185 ] conversion from 'const double' to 'const float' warning

[SourceForge.net <no...@so...>]

Bugs item #1067185, was opened at 2004-11-16 09:54
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=437247&aid=1067185&group_id=43735

Category: GMTL
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: trigras (trigras)
Assigned to: Nobody/Anonymous (nobody)
Summary: conversion from 'const double' to 'const float' warning

Initial Comment:
while trying to use gmtl with Matrix44d VS2003 produces
warnings:
..\..\..\..\3rdparty\gmtl\gmtl\Generate.h(791) :
warning C4244: 'initializing' : conversion from 'const
double' to 'const float', possible loss of data

Shoudn't there be a DATA_TYPE instead of float in lines
790-792 of Generate.h? And maybe in lines 795-797 also?


All warnings:

..\..\..\..\3rdparty\gmtl\gmtl\Generate.h(790) :
warning C4244: 'initializing' : conversion from 'const
double' to 'const float', possible loss of data
        ..\..\..\..\3rdparty\gmtl\gmtl\Generate.h(851)
: see reference to function template instantiation
'gmtl::Matrix<DATA_TYPE,ROWS,COLS>
&gmtl::setRot<double,4,4,gmtl::XYZ>(gmtl::Matrix<DATA_TYPE,ROWS,COLS>
&,const gmtl::EulerAngle<DATA_TYPE,ROTATION_ORDER> &)'
being compiled
        with
        [
            DATA_TYPE=double,
            ROWS=4,
            COLS=4,
            ROTATION_ORDER=gmtl::XYZ
        ]
       
\work\projects\medint_checkout\robotics\code\base\robotdata\src\paths\PathPoint.cpp(114)
: see reference to function template instantiation
'gmtl::Matrix<DATA_TYPE,ROWS,COLS>
&gmtl::set<double,4,4,gmtl::XYZ>(gmtl::Matrix<DATA_TYPE,ROWS,COLS>
&,const gmtl::EulerAngle<DATA_TYPE,ROTATION_ORDER> &)'
being compiled
        with
        [
            DATA_TYPE=double,
            ROWS=4,
            COLS=4,
            ROTATION_ORDER=gmtl::XYZ
        ]
..\..\..\..\3rdparty\gmtl\gmtl\Generate.h(791) :
warning C4244: 'initializing' : conversion from 'const
double' to 'const float', possible loss of data
..\..\..\..\3rdparty\gmtl\gmtl\Generate.h(792) :
warning C4244: 'initializing' : conversion from 'const
double' to 'const float', possible loss of data

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=437247&aid=1067185&group_id=43735

[ggt-devel] [ ggt-Bugs-1066681 ] Quat::get() should be const

[SourceForge.net <no...@so...>]

Bugs item #1066681, was opened at 2004-11-15 08:11
Message generated for change (Settings changed) made by allenb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=437247&aid=1066681&group_id=43735

Category: GMTL
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: trigras (trigras)
>Assigned to: Allen Bierbaum (allenb)
Summary: Quat::get() should be const

Initial Comment:
void Quat::get( DATA_TYPE& x, DATA_TYPE& y, DATA_TYPE&
z, DATA_TYPE& w ) should be const so it could be used
in cases like:

void foo( const gmtl::Quatd& q) 
{
  double x, y, z, w;
  q.get( x, y, z, w);
}



----------------------------------------------------------------------

>Comment By: Allen Bierbaum (allenb)
Date: 2004-11-15 11:42

Message:
Logged In: YES 
user_id=4961

Fixed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=437247&aid=1066681&group_id=43735

[ggt-devel] [ ggt-Bugs-1066681 ] Quat::get() should be const

[SourceForge.net <no...@so...>]

Bugs item #1066681, was opened at 2004-11-15 16:11
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=437247&aid=1066681&group_id=43735

Category: GMTL
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: trigras (trigras)
Assigned to: Nobody/Anonymous (nobody)
Summary: Quat::get() should be const

Initial Comment:
void Quat::get( DATA_TYPE& x, DATA_TYPE& y, DATA_TYPE&
z, DATA_TYPE& w ) should be const so it could be used
in cases like:

void foo( const gmtl::Quatd& q) 
{
  double x, y, z, w;
  q.get( x, y, z, w);
}



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=437247&aid=1066681&group_id=43735

[ggt-devel] Uneeded asserts patch

[Daniel E. S. <dsh...@vr...>]

mail being weird....hope this isn't a dupe

I am tired of all the warnings I get about asserting that a unsigned is
greater than or equal to 0 since it can't being unsigned and all...
gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3) is the one who really
complains about it.


patches follow..

-d

[ggt-devel] StaticAssert Patch

[Johnathan G. <joh...@gm...>]

Greetings,

I'm not sure if this is something you would be interested in, but I
have made some modifications to GMTL_STATIC_ASSERT; instead of
borrowing the StaticAssert from boost, I switched it to the Static
Assert featured in Loki.  The Loki static assert attempts to spit out
a message to the programmer in the form of an undefined identifier.  I
have also modified Vec.h to use static asserts instead of gmtlAssert
for the Vec constructors.  Finally, the patch contains an update to
Coord.h reflecting this.

Regards,


Johnathan Gurley

Re: [ggt-devel] GMTL: Vector expression template code checked in

[Patrick H. <pa...@in...>]

Patrick Hartling wrote:
> Patrick Hartling wrote:
> 
>> Another problem with this is that it doesn't compile with Visual C++ 7.0.
> 
> 
> Since I haven't found any viable workarounds for this problem, I started
> working on patches to GMTL that make the vector expression code optional
> based on whether the compiler supports the language features used [*]. 
> Fortunately for me, Allen's tendency to leave old code in comments
> has paid off in a lot of places in terms of the speed at which I can
> apply #ifdef's.  This means that users of compilers that can't handle
> the more advanced template code won't be able to get the performance
> boost of the expression templates, but at least their code will work.

I have finished the patches that allow the metaprogramming features to 
be conditionally disabled at compile time.  With my changes, the 
metaprogramming stuff is only disabled with Visual C++ 7.0 as I have not 
encountered any other compilers that cannot handle the code.

I have attached the patches for review purposes.  As I noted in my 
previous message, most of the old code was still there, just commented 
out.  That made fixing the Visual C++ 7.0 problems quite simple.  I have 
done my best to strip out all the new metaprogramming code in the Visual 
C++ 7.0 case, but the test suite is not really set up for use with 
Visual C++ 7.0.  I made my patches incrementally by building VR Juggler 
from CVS and all of its sample and test applications (except osgNav and 
OpenSGNav).

> [*] I am also concerned that the MIPSpro C++ Compiler 7.3.1.x may not be
> able to handle this code, but I haven't tried it yet due to time
> constraints.  I have no idea about how well the Sun or HP compilers
> handle any of GMTL.

I am happy to report that the MIPSpro C++ Compiler 7.3.1.3m has no 
problems with the latest GMTL code.

So, are there any objections to me committing the attached patch?

  -Patrick

>> Allen Bierbaum wrote:
>>
>>> I just merged my work on expression templates from the work branch 
>>> into the CVS head of GMTL.
>>>
>>> This is a *major* feature addition and re-working of the VecBase (Vec 
>>> & Point) classes and all operators that work on them.
>>>
>>> This change uses expression templates to remove temporary objects 
>>> from expression evaluation and potentially allow compilers to better 
>>> optimize the code.
>>>
>>> For example, with the previous code:
>>>
>>> vec1 = vec2 + vec3 + (vec4 * 6)
>>>
>>> that would have created 3 temporary vectors.  In the new code the 
>>> expression templates output code that directly computes the final 
>>> value from the given operands.  This has shown at least a 2x 
>>> performance increase in my tests.
>>>
>>> The code is far from perfect though and could definitely be optimized 
>>> much further.  (especially by someone that knows intel assembly and 
>>> has some patience)
>>>
>>> There is one common compiler error to be aware of.  It is not 
>>> possible to pass expression templates where VecBase/Vec/Point objects 
>>> are expected.
>>>
>>> Details:
>>>
>>> GMTL makes extensive use of expression templates.  These templates 
>>> come into play when evaluating statement such as:
>>>
>>> gmtl::Vec3f vec1, vec2, vec3;
>>> vec1 = vec2 + (vec3 * 6.0);
>>>
>>> When evaluating the expression on the second line, GMTL creates an 
>>> expression template tree to fully evaluate this expression when = is 
>>> called.  The details of this process are normally hidden from the 
>>> user, but can come to the forefront when a method expects a Vec or 
>>> Point argument and is passed an expression.  For example:
>>>
>>> void myMethod(gmtl::Vec3f vec)
>>> { ... }
>>>
>>> gmtl::Vec3f vec1, vec2;
>>>
>>> myMethod(vec1);           // Works correctly
>>> myMethod(vec1 + vec2);    // Fails to compile
>>>
>>> The reason the second line fails to compile is that the type for 
>>> "vec1 + vec2" is not a Vec3f.  It is an expression template that 
>>> describes how to sum two Vec3f's. (You may expect an autoconversion 
>>> to happen, but it does not because of template argument deduction 
>>> rules).
>>>
>>> There are two solutions to this, either explicitly construct a temporary
>>> object to pass to the method (which is what an auto conversion would 
>>> do anyway) or write the method to handle expression templates.  This 
>>> second option is not difficult, but does require a further 
>>> understanding of GMTL then is documented here.
>>>
>>> Here is how the first option could be used:
>>>
>>> myMethod(gmtl::Vec3f(vec1 + vec2));     // Creates a temporary to 
>>> pass in
>>>
>>>
>>>
>>> In closing: Give the code and try and let me know what you think. :)
>>>
>>>
>>> -Allen


-- 
Patrick L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2msw3          | http://www.infiscape.com/

Re: [ggt-devel] GMTL: Vector expression template code checked in

[Patrick H. <pa...@in...>]

Patrick Hartling wrote:
> Another problem with this is that it doesn't compile with Visual C++ 
> 7.0.

Since I haven't found any viable workarounds for this problem, I started
working on patches to GMTL that make the vector expression code optional
based on whether the compiler supports the language features used [*]. 
Fortunately for me, Allen's tendency to leave old code in comments
has paid off in a lot of places in terms of the speed at which I can
apply #ifdef's.  This means that users of compilers that can't handle
the more advanced template code won't be able to get the performance
boost of the expression templates, but at least their code will work.

I am concerned, however, about this approach.  It has the same pitfalls
as anything that uses #ifdef's; viz., some code won't be compiled all
the time.  The only other alternative I can think of is to tell users of
GMTL and Visual C++ 7.0 that they have to use 0.3.5.  Of course, if
there are ever any API changes (I don't think that 0.4.0 introduced any
interface changes), then those users could face writing code that
supports both GMTL 0.3.5 and whatever the current version is at the time.

Not being a GMTL author, I can't really say what's good or what's bad
for GMTL, but IMHO, I think that there needs to be something in place
for allowing users of partially compliant C++ compilers to utilize GMTL. 
  I am still inclined to follow the #ifdef approach in the event that
compilers besides VC++ 7.0 have trouble with GMTL.  Are there any other
suggestions?

    -Patrick


[*] I am also concerned that the MIPSpro C++ Compiler 7.3.1.x may not be
able to handle this code, but I haven't tried it yet due to time
constraints.  I have no idea about how well the Sun or HP compilers
handle any of GMTL.

> Allen Bierbaum wrote:
> 
>>I just merged my work on expression templates from the work branch into 
>>the CVS head of GMTL.
>>
>>This is a *major* feature addition and re-working of the VecBase (Vec & 
>>Point) classes and all operators that work on them.
>>
>>This change uses expression templates to remove temporary objects from 
>>expression evaluation and potentially allow compilers to better optimize 
>>the code.
>>
>>For example, with the previous code:
>>
>>vec1 = vec2 + vec3 + (vec4 * 6)
>>
>>that would have created 3 temporary vectors.  In the new code the 
>>expression templates output code that directly computes the final value 
>>from the given operands.  This has shown at least a 2x performance 
>>increase in my tests.
>>
>>The code is far from perfect though and could definitely be optimized 
>>much further.  (especially by someone that knows intel assembly and has 
>>some patience)
>>
>>There is one common compiler error to be aware of.  It is not possible 
>>to pass expression templates where VecBase/Vec/Point objects are expected.
>>
>>Details:
>>
>>GMTL makes extensive use of expression templates.  These templates come 
>>into play when evaluating statement such as:
>>
>>gmtl::Vec3f vec1, vec2, vec3;
>>vec1 = vec2 + (vec3 * 6.0);
>>
>>When evaluating the expression on the second line, GMTL creates an 
>>expression template tree to fully evaluate this expression when = is 
>>called.  The details of this process are normally hidden from the user, 
>>but can come to the forefront when a method expects a Vec or Point 
>>argument and is passed an expression.  For example:
>>
>>void myMethod(gmtl::Vec3f vec)
>>{ ... }
>>
>>gmtl::Vec3f vec1, vec2;
>>
>>myMethod(vec1);           // Works correctly
>>myMethod(vec1 + vec2);    // Fails to compile
>>
>>The reason the second line fails to compile is that the type for "vec1 + 
>>vec2" is not a Vec3f.  It is an expression template that describes how 
>>to sum two Vec3f's. (You may expect an autoconversion to happen, but it 
>>does not because of template argument deduction rules).
>>
>>There are two solutions to this, either explicitly construct a temporary
>>object to pass to the method (which is what an auto conversion would do 
>>anyway) or write the method to handle expression templates.  This second 
>>option is not difficult, but does require a further understanding of 
>>GMTL then is documented here.
>>
>>Here is how the first option could be used:
>>
>>myMethod(gmtl::Vec3f(vec1 + vec2));     // Creates a temporary to pass in
>>
>>
>>
>>In closing: Give the code and try and let me know what you think. :)
>>
>>
>>-Allen
> 
> 
> 


-- 
Patrick L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2msw3          | http://www.infiscape.com/

Re: [ggt-devel] GMTL: Vector expression template code checked in

[Patrick H. <pa...@13...>]

Another problem with this is that it doesn't compile with Visual C++=20
7.0.  For example, the following (from gmtl/Util/Meta.h) is not=20
supported by VC++ 7.0:

// ------ LOOP UnRolling ------------ //
template<int ELT, typename T>
struct AssignVecUnrolled
{
    static void func(T& lVec, const T& rVec)
    {
       AssignVecUnrolled<ELT-1,T>::func(lVec, rVec);
       lVec[ELT] =3D rVec[ELT];
    }
};

template<typename T>
struct AssignVecUnrolled<0,T>
{
    static void func(T& lVec, const T& rVec)
    { lVec[0] =3D rVec[0]; }
};

The error is this:
...\include\gmtl\Util\Meta.h(107): error C2687: cannot define a nested=20
UDT of a template class out of line

Searching for this error turns up some confirmation that this is a problem:

http://www.gamedev.net/community/forums/topic.asp?topic_id=3D274966
http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/dndeepc/=
html/deep07092002.asp

I haven't had a chance to read through the (long) MSDN article, but is=20
there any hope of working around this?

  -Patrick

Allen Bierbaum wrote:
> I just merged my work on expression templates from the work branch into=20
> the CVS head of GMTL.
>=20
> This is a *major* feature addition and re-working of the VecBase (Vec &=20
> Point) classes and all operators that work on them.
>=20
> This change uses expression templates to remove temporary objects from=20
> expression evaluation and potentially allow compilers to better optimize=20
> the code.
>=20
> For example, with the previous code:
>=20
> vec1 =3D vec2 + vec3 + (vec4 * 6)
>=20
> that would have created 3 temporary vectors.  In the new code the=20
> expression templates output code that directly computes the final value=20
> from the given operands.  This has shown at least a 2x performance=20
> increase in my tests.
>=20
> The code is far from perfect though and could definitely be optimized=20
> much further.  (especially by someone that knows intel assembly and has=20
> some patience)
>=20
> There is one common compiler error to be aware of.  It is not possible=20
> to pass expression templates where VecBase/Vec/Point objects are expected=
.
>=20
> Details:
>=20
> GMTL makes extensive use of expression templates.  These templates come=20
> into play when evaluating statement such as:
>=20
> gmtl::Vec3f vec1, vec2, vec3;
> vec1 =3D vec2 + (vec3 * 6.0);
>=20
> When evaluating the expression on the second line, GMTL creates an=20
> expression template tree to fully evaluate this expression when =3D is=20
> called.  The details of this process are normally hidden from the user,=20
> but can come to the forefront when a method expects a Vec or Point=20
> argument and is passed an expression.  For example:
>=20
> void myMethod(gmtl::Vec3f vec)
> { ... }
>=20
> gmtl::Vec3f vec1, vec2;
>=20
> myMethod(vec1);           // Works correctly
> myMethod(vec1 + vec2);    // Fails to compile
>=20
> The reason the second line fails to compile is that the type for "vec1 +=20
> vec2" is not a Vec3f.  It is an expression template that describes how=20
> to sum two Vec3f's. (You may expect an autoconversion to happen, but it=20
> does not because of template argument deduction rules).
>=20
> There are two solutions to this, either explicitly construct a temporary
> object to pass to the method (which is what an auto conversion would do=20
> anyway) or write the method to handle expression templates.  This second=20
> option is not difficult, but does require a further understanding of=20
> GMTL then is documented here.
>=20
> Here is how the first option could be used:
>=20
> myMethod(gmtl::Vec3f(vec1 + vec2));     // Creates a temporary to pass in
>=20
>=20
>=20
> In closing: Give the code and try and let me know what you think. :)
>=20
>=20
> -Allen


--=20
Patrick L. Hartling                     | Research Assistant, VRAC
http://www.137.org/patrick/             | 2274 Howe Hall Room 2624
PGP: http://tinyurl.com/2oum9           | http://www.vrac.iastate.edu/

Re: [ggt-devel] gmtl-config error

[Patrick H. <pa...@13...>]

On Wed, 2004-09-22 at 16:26 -0500, Allen Bierbaum wrote:
> I have fixed this bug in the build.  I was able to simplify the=20
> dependency tracking for gmtl-config by just using an SCons Value() node=20
> to track the value of all items that are substituted into gmtl-config.=20
> The long and short of what this means is that if anything changes that=20
> is used for the creation of gmtl-config, the file will be re-created.

Nice.  Thanks.

 -Patrick

> Patrick Hartling wrote:
> > On Mon, 2004-09-20 at 16:50 -0500, Daniel E. Shipton wrote:
> >=20
> >>I install gmtl by
> >>scons
> >>scons install prefix=3D$HOME/tmp/gmtl-0.4
> >=20
> >=20
> > I could be wrong, but I don't think that this is a valid way to install
> > GMTL as the SCons build is currently written.  The gmtl-config script i=
s
> > generated as part of the first call to scons, and since there is no
> > prefix set, it uses a default value.  When I install GMTL, I just go
> > straight for the install step.  AFAIK, SCons ensures that everything is
> > built before installing.  If you're not building PyGMTL, there is
> > nothing to build aside from gmtl-config.  Of course, PyGMTL doesn't get
> > installed by SCons anyway, so there is a different sort of problem
> > there.
> >=20
> >  -Patrick
> >=20
> >=20
> >>the generated gmtl-config script output=20
> >>/usr/local/include for the CXXFLAGS
> >>which is obviously wrong.
> >=20
> >=20
> >=20
>=20
>=20
--=20
Patrick L. Hartling                     | Research Assistant, VRAC
http://www.137.org/patrick/             | 2274 Howe Hall Room 2624
PGP: http://tinyurl.com/2oum9           | http://www.vrac.iastate.edu/

Re: [ggt-devel] gmtl-config error

[Allen B. <al...@vr...>]

I have fixed this bug in the build.  I was able to simplify the 
dependency tracking for gmtl-config by just using an SCons Value() node 
to track the value of all items that are substituted into gmtl-config. 
The long and short of what this means is that if anything changes that 
is used for the creation of gmtl-config, the file will be re-created.

-Allen

Patrick Hartling wrote:
> On Mon, 2004-09-20 at 16:50 -0500, Daniel E. Shipton wrote:
> 
>>I install gmtl by
>>scons
>>scons install prefix=$HOME/tmp/gmtl-0.4
> 
> 
> I could be wrong, but I don't think that this is a valid way to install
> GMTL as the SCons build is currently written.  The gmtl-config script is
> generated as part of the first call to scons, and since there is no
> prefix set, it uses a default value.  When I install GMTL, I just go
> straight for the install step.  AFAIK, SCons ensures that everything is
> built before installing.  If you're not building PyGMTL, there is
> nothing to build aside from gmtl-config.  Of course, PyGMTL doesn't get
> installed by SCons anyway, so there is a different sort of problem
> there.
> 
>  -Patrick
> 
> 
>>the generated gmtl-config script output 
>>/usr/local/include for the CXXFLAGS
>>which is obviously wrong.
> 
> 
> 


-- 
-- Allen Bierbaum                         al...@vr...
-- Research Assistant and PhD Candidate
-- VR Juggler Team                              www.vrjuggler.org
-- Virtual Reality Applications Center       www.vrac.iastate.edu

[ggt-devel] Re: [vrjuggler-info] GMTL: Vector expression template code checked in

[Allen B. <al...@vr...>]

Chad Austin wrote:
> Allen Bierbaum wrote:
> 
>> I just merged my work on expression templates from the work branch 
>> into the CVS head of GMTL.
>>
>> This is a *major* feature addition and re-working of the VecBase (Vec 
>> & Point) classes and all operators that work on them.
>>
>> This change uses expression templates to remove temporary objects from 
>> expression evaluation and potentially allow compilers to better 
>> optimize the code.
>>
>> [snip]
> 
> 
> Really cool, Allen!
> 
>> The code is far from perfect though and could definitely be optimized 
>> much further.  (especially by someone that knows intel assembly and 
>> has some patience)
>>
>> There is one common compiler error to be aware of.  It is not possible 
>> to pass expression templates where VecBase/Vec/Point objects are 
>> expected.
>>
>> Details:
>>
>> GMTL makes extensive use of expression templates.  These templates 
>> come into play when evaluating statement such as:
>>
>> gmtl::Vec3f vec1, vec2, vec3;
>> vec1 = vec2 + (vec3 * 6.0);
>>
>> When evaluating the expression on the second line, GMTL creates an 
>> expression template tree to fully evaluate this expression when = is 
>> called.  The details of this process are normally hidden from the 
>> user, but can come to the forefront when a method expects a Vec or 
>> Point argument and is passed an expression.  For example:
>>
>> void myMethod(gmtl::Vec3f vec)
>> { ... }
>>
>> gmtl::Vec3f vec1, vec2;
>>
>> myMethod(vec1);           // Works correctly
>> myMethod(vec1 + vec2);    // Fails to compile
>>
>> The reason the second line fails to compile is that the type for "vec1 
>> + vec2" is not a Vec3f.  It is an expression template that describes 
>> how to sum two Vec3f's. (You may expect an autoconversion to happen, 
>> but it does not because of template argument deduction rules).
> 
>  >
> 
>> There are two solutions to this, either explicitly construct a temporary
>> object to pass to the method (which is what an auto conversion would 
>> do anyway) or write the method to handle expression templates.  This 
>> second option is not difficult, but does require a further 
>> understanding of GMTL then is documented here.
>>
>> Here is how the first option could be used:
>>
>> myMethod(gmtl::Vec3f(vec1 + vec2));     // Creates a temporary to pass in
> 
> 
> Hm, that's really annoying...  do other math libraries that support 
> expression templates suffer from this limitation as well?  (In fact, 
> it's so annoying that I can't yet try the new gmtl out.  I don't have 
> time to update all of th places I use vectors in exactly the way that 
> breaks.)
> 

The couple that I have looked at do have this problem.  That said, if 
someone can point me at a way to work around this I would greatly 
appreciated it.

One note: Some people have found (and I have yet to test) that the above 
method doesn't have this problem unless it is templated.  (which does 
make sense).

So:

void myMethod(gmtl::Vec3f arg)

may work while

template<unsigned SIZE>
void myMethod(gmtl::Vec<SIZE,float> arg)

will not work.  So, summary: you mileage may vary right now.

-Allen





-- 
-- Allen Bierbaum                         al...@vr...
-- Research Assistant and PhD Candidate
-- VR Juggler Team                              www.vrjuggler.org
-- Virtual Reality Applications Center       www.vrac.iastate.edu

Re: [ggt-devel] gmtl-config error

[Patrick H. <pa...@13...>]

On Mon, 2004-09-20 at 16:50 -0500, Daniel E. Shipton wrote:
> I install gmtl by
> scons
> scons install prefix=3D$HOME/tmp/gmtl-0.4

I could be wrong, but I don't think that this is a valid way to install
GMTL as the SCons build is currently written.  The gmtl-config script is
generated as part of the first call to scons, and since there is no
prefix set, it uses a default value.  When I install GMTL, I just go
straight for the install step.  AFAIK, SCons ensures that everything is
built before installing.  If you're not building PyGMTL, there is
nothing to build aside from gmtl-config.  Of course, PyGMTL doesn't get
installed by SCons anyway, so there is a different sort of problem
there.

 -Patrick

> the generated gmtl-config script output=20
> /usr/local/include for the CXXFLAGS
> which is obviously wrong.


--=20
Patrick L. Hartling                     | Research Assistant, VRAC
http://www.137.org/patrick/             | 2274 Howe Hall Room 2624
PGP: http://tinyurl.com/2oum9           | http://www.vrac.iastate.edu/

[ggt-devel] gmtl-config error

[Daniel E. S. <dsh...@vr...>]

I install gmtl by
scons
scons install prefix=$HOME/tmp/gmtl-0.4

the generated gmtl-config script output 
/usr/local/include for the CXXFLAGS
which is obviously wrong.

-dan
-- 
Daniel E. Shipton <dsh...@vr...>
Virtual Reality Applications Center

Re: [ggt-devel] SCons installation slow and messy

[Patrick H. <pa...@13...>]

On Wed, 2004-09-08 at 23:04 -0500, Ben Scott wrote:
> Well, the .sconsign problem can be solved by adding a line containing
> SConsignFile() to the SConstruct to force SCons to use a single file for
> all the cached data in the same directory as the SConstruct.

This does work, but the install process still runs for a long, long
time.

> As for MD5 summing the entire installation tree, that is a problem. I'm
> not entirely sure what's going on there. However, we might be able to mak=
e
> that problem go away by adding the following line to the SConstruct:
>=20
> SetOption('implicit-deps-unchanged', 1)
>=20
> Give that a shot and see if that improves your install time.

Adding the above gives me this error with SCons 0.96.1:

AttributeError: 'module' object has no attribute 'Error':
  File "SConstruct", line 11:
    SetOption('implicit-deps-unchanged', 1)
  File "/usr/lib/scons/SCons/Script/SConscript.py", line 581:
    return apply(method, args, kw)
  File "/usr/lib/scons/SCons/Script/SConscript.py", line 516:
    SCons.Script.ssoptions.set(name, value)
  File "/usr/lib/scons/SCons/Script/__init__.py", line 742:
    raise SCons.Error.UserError, "This option is not settable from a
SConscript file: %s"%name

 -Patrick

> > I just performed an installation of GMTL 0.3.5 in a freshly created use=
r's
> > home directory, and the process took three full minutes--probably becau=
se
> > SCons was pooping .sconsign files throughout the user's *entire* home
> > directory.  I ran the GMTL build+install as follows:
> >
> >    % scons install prefix=3D$HOME
> >
> > Is it really necessary for SCons to do its MD5 summing over the entire
> > installation tree?  (I am assuming that SCons is doing this because of =
the
> > 'prefix' setting above and not just out of general confusion during the
> > build phase.)  For a sufficiently large directory tree, this wouild mak=
e
> > the GMTL build+install appear to hang for no obvious reason.  I can
> > definitely say that I have cancelled many a GMTL installation thinking
> > that SCons had gotten stuck on some step or another.
> >
> > Lastly, I realize that this is really an SCons question and not a GMTL
> > question.  In my (limited) experience with SCons, it seems like SCons
> > usually does the right thing, and it's the SConstruct file that has the
> > problem.  If this is an SCons problem (feature?), then I will redirect =
my
> > discontent to their mailing list.
> >
> >  -Patrick


--=20
Patrick L. Hartling                     | Research Assistant, VRAC
http://www.137.org/patrick/             | 2274 Howe Hall Room 2624
PGP: http://tinyurl.com/2oum9           | http://www.vrac.iastate.edu/

[ggt-devel] Some GMTL headers not installed

[Patrick H. <pa...@13...>]

I noticed this morning that several GMTL headers are not installed when
GMTL's installation procedure is run.  They are as follows:

   gmtl/Config.h
   gmtl/Fit/GaussPointsFit.h
   gmtl/Helpers.h
   gmtl/Numerics/Eigen.h
   gmtl/OOBox.h
   gmtl/VecB.h

Are these headers not installed on purpose, or is it an oversight?  I
haven't tried compiling against this new GMTL installation yet, so I
can't say whether the installation is broken.

 -Patrick


--=20
Patrick L. Hartling                     | Research Assistant, VRAC
http://www.137.org/patrick/             | 2274 Howe Hall Room 2624
PGP: http://tinyurl.com/2oum9           | http://www.vrac.iastate.edu/

Re: [ggt-devel] GMTL: Vector expression template code checked in

[Patrick H. <pa...@13...>]

On Thu, 2004-09-16 at 16:05 -0500, Allen Bierbaum wrote:
> Patrick Hartling wrote:
> > What is the fix for this:
> >=20
> > gmtl/TriOps.h:60: error: no match for 'operator*' in 'gmtl::operator
> > +(const
> >    gmtl::VecBase<T, SIZE, R1>&, const gmtl::VecBase<T, SIZE, R2>&) [wit=
h
> > T =3D
> >    double, unsigned int SIZE =3D 3, R1 =3D
> >    gmtl::meta::VecBinaryExpr<gmtl::VecBase<double, 3,
> >    gmtl::meta::DefaultVecTag>, gmtl::VecBase<double, 3,
> >    gmtl::meta::DefaultVecTag>, gmtl::meta::VecPlusBinary>, R2 =3D
> >    gmtl::meta::DefaultVecTag]((+(+tri)->gmtl::Tri<DATA_TYPE>::operator[=
]
> > [with
> >    DATA_TYPE =3D double](2))) * one_third'
> >=20
> > The code that is not compiling is this (from gmtl/TriOps.h modified to
> > include gmtl/VecOps.h):
> >=20
> > template< class DATA_TYPE >
> > Point<DATA_TYPE, 3> center( const Tri<DATA_TYPE>& tri )
> > {
> >    const float one_third =3D (1.0f/3.0f);
> >    return (tri[0] + tri[1] + tri[2]) * one_third;
> > }
> >=20
> > It seems as though the operator* overload in gmtl/VecOps.h isn't
> > matching the above for some reason, but I can't figure out why.  I've
> > tried calling the gmtl::Point<DATA_TYPE,3> constructor explicitly insid=
e
> > the parentheses performing the point addition, but that doesn't help.
> > Based on what you say below, the above shouldn't be affected at all by
> > the changes you just checked in, but I don't have a very good
> > understanding of this stuff in general.
>=20
> Strange, try using:
>=20
> DATA_TYPE(one_third) and see what happens.

Ah, that did it.  I was hunting around through the gmtl::meta namespace
for a hard-coded float type (there was no error with a gmtl::Tri<float>)
and completely overlooked the one in the function in question.

> Teh strange part of this is the operator* above seems to have two=20
> VecBase params.  This should not be allowed.

I'll take your word for it on this one.

 -Patrick

> > On Thu, 2004-09-16 at 14:51 -0500, Allen Bierbaum wrote:
> >=20
> >>I just merged my work on expression templates from the work branch into=
=20
> >>the CVS head of GMTL.
> >>
> >>This is a *major* feature addition and re-working of the VecBase (Vec &=
=20
> >>Point) classes and all operators that work on them.
> >>
> >>This change uses expression templates to remove temporary objects from=20
> >>expression evaluation and potentially allow compilers to better optimiz=
e=20
> >>the code.
> >>
> >>For example, with the previous code:
> >>
> >>vec1 =3D vec2 + vec3 + (vec4 * 6)
> >>
> >>that would have created 3 temporary vectors.  In the new code the=20
> >>expression templates output code that directly computes the final value=
=20
> >>from the given operands.  This has shown at least a 2x performance=20
> >>increase in my tests.
> >>
> >>The code is far from perfect though and could definitely be optimized=20
> >>much further.  (especially by someone that knows intel assembly and has=
=20
> >>some patience)
> >>
> >>There is one common compiler error to be aware of.  It is not possible=20
> >>to pass expression templates where VecBase/Vec/Point objects are expect=
ed.
> >>
> >>Details:
> >>
> >>GMTL makes extensive use of expression templates.  These templates come=
=20
> >>into play when evaluating statement such as:
> >>
> >>gmtl::Vec3f vec1, vec2, vec3;
> >>vec1 =3D vec2 + (vec3 * 6.0);
> >>
> >>When evaluating the expression on the second line, GMTL creates an=20
> >>expression template tree to fully evaluate this expression when =3D is=20
> >>called.  The details of this process are normally hidden from the user,=
=20
> >>but can come to the forefront when a method expects a Vec or Point=20
> >>argument and is passed an expression.  For example:
> >>
> >>void myMethod(gmtl::Vec3f vec)
> >>{ ... }
> >>
> >>gmtl::Vec3f vec1, vec2;
> >>
> >>myMethod(vec1);           // Works correctly
> >>myMethod(vec1 + vec2);    // Fails to compile
> >>
> >>The reason the second line fails to compile is that the type for "vec1 =
+=20
> >>vec2" is not a Vec3f.  It is an expression template that describes how=20
> >>to sum two Vec3f's. (You may expect an autoconversion to happen, but it=
=20
> >>does not because of template argument deduction rules).
> >>
> >>There are two solutions to this, either explicitly construct a temporar=
y
> >>object to pass to the method (which is what an auto conversion would do=
=20
> >>anyway) or write the method to handle expression templates.  This secon=
d=20
> >>option is not difficult, but does require a further understanding of=20
> >>GMTL then is documented here.
> >>
> >>Here is how the first option could be used:
> >>
> >>myMethod(gmtl::Vec3f(vec1 + vec2));     // Creates a temporary to pass =
in
> >>
> >>
> >>
> >>In closing: Give the code and try and let me know what you think. :)
> >>
> >>
> >>-Allen
>=20
>=20
--=20
Patrick L. Hartling                     | Research Assistant, VRAC
http://www.137.org/patrick/             | 2274 Howe Hall Room 2624
PGP: http://tinyurl.com/2oum9           | http://www.vrac.iastate.edu/

Re: [ggt-devel] GMTL: Vector expression template code checked in

[Allen B. <al...@vr...>]

Patrick Hartling wrote:
> What is the fix for this:
> 
> gmtl/TriOps.h:60: error: no match for 'operator*' in 'gmtl::operator
> +(const
>    gmtl::VecBase<T, SIZE, R1>&, const gmtl::VecBase<T, SIZE, R2>&) [with
> T =
>    double, unsigned int SIZE = 3, R1 =
>    gmtl::meta::VecBinaryExpr<gmtl::VecBase<double, 3,
>    gmtl::meta::DefaultVecTag>, gmtl::VecBase<double, 3,
>    gmtl::meta::DefaultVecTag>, gmtl::meta::VecPlusBinary>, R2 =
>    gmtl::meta::DefaultVecTag]((+(+tri)->gmtl::Tri<DATA_TYPE>::operator[]
> [with
>    DATA_TYPE = double](2))) * one_third'
> 
> The code that is not compiling is this (from gmtl/TriOps.h modified to
> include gmtl/VecOps.h):
> 
> template< class DATA_TYPE >
> Point<DATA_TYPE, 3> center( const Tri<DATA_TYPE>& tri )
> {
>    const float one_third = (1.0f/3.0f);
>    return (tri[0] + tri[1] + tri[2]) * one_third;
> }
> 
> It seems as though the operator* overload in gmtl/VecOps.h isn't
> matching the above for some reason, but I can't figure out why.  I've
> tried calling the gmtl::Point<DATA_TYPE,3> constructor explicitly inside
> the parentheses performing the point addition, but that doesn't help.
> Based on what you say below, the above shouldn't be affected at all by
> the changes you just checked in, but I don't have a very good
> understanding of this stuff in general.

Strange, try using:

DATA_TYPE(one_third) and see what happens.

Teh strange part of this is the operator* above seems to have two 
VecBase params.  This should not be allowed.

-Allen

> 
>  -Patrick
> 
> 
> On Thu, 2004-09-16 at 14:51 -0500, Allen Bierbaum wrote:
> 
>>I just merged my work on expression templates from the work branch into 
>>the CVS head of GMTL.
>>
>>This is a *major* feature addition and re-working of the VecBase (Vec & 
>>Point) classes and all operators that work on them.
>>
>>This change uses expression templates to remove temporary objects from 
>>expression evaluation and potentially allow compilers to better optimize 
>>the code.
>>
>>For example, with the previous code:
>>
>>vec1 = vec2 + vec3 + (vec4 * 6)
>>
>>that would have created 3 temporary vectors.  In the new code the 
>>expression templates output code that directly computes the final value 
>>from the given operands.  This has shown at least a 2x performance 
>>increase in my tests.
>>
>>The code is far from perfect though and could definitely be optimized 
>>much further.  (especially by someone that knows intel assembly and has 
>>some patience)
>>
>>There is one common compiler error to be aware of.  It is not possible 
>>to pass expression templates where VecBase/Vec/Point objects are expected.
>>
>>Details:
>>
>>GMTL makes extensive use of expression templates.  These templates come 
>>into play when evaluating statement such as:
>>
>>gmtl::Vec3f vec1, vec2, vec3;
>>vec1 = vec2 + (vec3 * 6.0);
>>
>>When evaluating the expression on the second line, GMTL creates an 
>>expression template tree to fully evaluate this expression when = is 
>>called.  The details of this process are normally hidden from the user, 
>>but can come to the forefront when a method expects a Vec or Point 
>>argument and is passed an expression.  For example:
>>
>>void myMethod(gmtl::Vec3f vec)
>>{ ... }
>>
>>gmtl::Vec3f vec1, vec2;
>>
>>myMethod(vec1);           // Works correctly
>>myMethod(vec1 + vec2);    // Fails to compile
>>
>>The reason the second line fails to compile is that the type for "vec1 + 
>>vec2" is not a Vec3f.  It is an expression template that describes how 
>>to sum two Vec3f's. (You may expect an autoconversion to happen, but it 
>>does not because of template argument deduction rules).
>>
>>There are two solutions to this, either explicitly construct a temporary
>>object to pass to the method (which is what an auto conversion would do 
>>anyway) or write the method to handle expression templates.  This second 
>>option is not difficult, but does require a further understanding of 
>>GMTL then is documented here.
>>
>>Here is how the first option could be used:
>>
>>myMethod(gmtl::Vec3f(vec1 + vec2));     // Creates a temporary to pass in
>>
>>
>>
>>In closing: Give the code and try and let me know what you think. :)
>>
>>
>>-Allen


-- 
-- Allen Bierbaum                         al...@vr...
-- Research Assistant and PhD Candidate
-- VR Juggler Team                              www.vrjuggler.org
-- Virtual Reality Applications Center       www.vrac.iastate.edu

Re: [ggt-devel] GMTL: Vector expression template code checked in

[Patrick H. <pa...@13...>]

What is the fix for this:

gmtl/TriOps.h:60: error: no match for 'operator*' in 'gmtl::operator
+(const
   gmtl::VecBase<T, SIZE, R1>&, const gmtl::VecBase<T, SIZE, R2>&) [with
T =3D
   double, unsigned int SIZE =3D 3, R1 =3D
   gmtl::meta::VecBinaryExpr<gmtl::VecBase<double, 3,
   gmtl::meta::DefaultVecTag>, gmtl::VecBase<double, 3,
   gmtl::meta::DefaultVecTag>, gmtl::meta::VecPlusBinary>, R2 =3D
   gmtl::meta::DefaultVecTag]((+(+tri)->gmtl::Tri<DATA_TYPE>::operator[]
[with
   DATA_TYPE =3D double](2))) * one_third'

The code that is not compiling is this (from gmtl/TriOps.h modified to
include gmtl/VecOps.h):

template< class DATA_TYPE >
Point<DATA_TYPE, 3> center( const Tri<DATA_TYPE>& tri )
{
   const float one_third =3D (1.0f/3.0f);
   return (tri[0] + tri[1] + tri[2]) * one_third;
}

It seems as though the operator* overload in gmtl/VecOps.h isn't
matching the above for some reason, but I can't figure out why.  I've
tried calling the gmtl::Point<DATA_TYPE,3> constructor explicitly inside
the parentheses performing the point addition, but that doesn't help.
Based on what you say below, the above shouldn't be affected at all by
the changes you just checked in, but I don't have a very good
understanding of this stuff in general.

 -Patrick


On Thu, 2004-09-16 at 14:51 -0500, Allen Bierbaum wrote:
> I just merged my work on expression templates from the work branch into=20
> the CVS head of GMTL.
>=20
> This is a *major* feature addition and re-working of the VecBase (Vec &=20
> Point) classes and all operators that work on them.
>=20
> This change uses expression templates to remove temporary objects from=20
> expression evaluation and potentially allow compilers to better optimize=20
> the code.
>=20
> For example, with the previous code:
>=20
> vec1 =3D vec2 + vec3 + (vec4 * 6)
>=20
> that would have created 3 temporary vectors.  In the new code the=20
> expression templates output code that directly computes the final value=20
> from the given operands.  This has shown at least a 2x performance=20
> increase in my tests.
>=20
> The code is far from perfect though and could definitely be optimized=20
> much further.  (especially by someone that knows intel assembly and has=20
> some patience)
>=20
> There is one common compiler error to be aware of.  It is not possible=20
> to pass expression templates where VecBase/Vec/Point objects are expected=
.
>=20
> Details:
>=20
> GMTL makes extensive use of expression templates.  These templates come=20
> into play when evaluating statement such as:
>=20
> gmtl::Vec3f vec1, vec2, vec3;
> vec1 =3D vec2 + (vec3 * 6.0);
>=20
> When evaluating the expression on the second line, GMTL creates an=20
> expression template tree to fully evaluate this expression when =3D is=20
> called.  The details of this process are normally hidden from the user,=20
> but can come to the forefront when a method expects a Vec or Point=20
> argument and is passed an expression.  For example:
>=20
> void myMethod(gmtl::Vec3f vec)
> { ... }
>=20
> gmtl::Vec3f vec1, vec2;
>=20
> myMethod(vec1);           // Works correctly
> myMethod(vec1 + vec2);    // Fails to compile
>=20
> The reason the second line fails to compile is that the type for "vec1 +=20
> vec2" is not a Vec3f.  It is an expression template that describes how=20
> to sum two Vec3f's. (You may expect an autoconversion to happen, but it=20
> does not because of template argument deduction rules).
>=20
> There are two solutions to this, either explicitly construct a temporary
> object to pass to the method (which is what an auto conversion would do=20
> anyway) or write the method to handle expression templates.  This second=20
> option is not difficult, but does require a further understanding of=20
> GMTL then is documented here.
>=20
> Here is how the first option could be used:
>=20
> myMethod(gmtl::Vec3f(vec1 + vec2));     // Creates a temporary to pass in
>=20
>=20
>=20
> In closing: Give the code and try and let me know what you think. :)
>=20
>=20
> -Allen
--=20
Patrick L. Hartling                     | Research Assistant, VRAC
http://www.137.org/patrick/             | 2274 Howe Hall Room 2624
PGP: http://tinyurl.com/2oum9           | http://www.vrac.iastate.edu/

[ggt-devel] GMTL: Vector expression template code checked in

[Allen B. <al...@vr...>]

I just merged my work on expression templates from the work branch into 
the CVS head of GMTL.

This is a *major* feature addition and re-working of the VecBase (Vec & 
Point) classes and all operators that work on them.

This change uses expression templates to remove temporary objects from 
expression evaluation and potentially allow compilers to better optimize 
the code.

For example, with the previous code:

vec1 = vec2 + vec3 + (vec4 * 6)

that would have created 3 temporary vectors.  In the new code the 
expression templates output code that directly computes the final value 
from the given operands.  This has shown at least a 2x performance 
increase in my tests.

The code is far from perfect though and could definitely be optimized 
much further.  (especially by someone that knows intel assembly and has 
some patience)

There is one common compiler error to be aware of.  It is not possible 
to pass expression templates where VecBase/Vec/Point objects are expected.

Details:

GMTL makes extensive use of expression templates.  These templates come 
into play when evaluating statement such as:

gmtl::Vec3f vec1, vec2, vec3;
vec1 = vec2 + (vec3 * 6.0);

When evaluating the expression on the second line, GMTL creates an 
expression template tree to fully evaluate this expression when = is 
called.  The details of this process are normally hidden from the user, 
but can come to the forefront when a method expects a Vec or Point 
argument and is passed an expression.  For example:

void myMethod(gmtl::Vec3f vec)
{ ... }

gmtl::Vec3f vec1, vec2;

myMethod(vec1);           // Works correctly
myMethod(vec1 + vec2);    // Fails to compile

The reason the second line fails to compile is that the type for "vec1 + 
vec2" is not a Vec3f.  It is an expression template that describes how 
to sum two Vec3f's. (You may expect an autoconversion to happen, but it 
does not because of template argument deduction rules).

There are two solutions to this, either explicitly construct a temporary
object to pass to the method (which is what an auto conversion would do 
anyway) or write the method to handle expression templates.  This second 
option is not difficult, but does require a further understanding of 
GMTL then is documented here.

Here is how the first option could be used:

myMethod(gmtl::Vec3f(vec1 + vec2));     // Creates a temporary to pass in



In closing: Give the code and try and let me know what you think. :)


-Allen
-- 
-- Allen Bierbaum                         al...@vr...
-- Research Assistant and PhD Candidate
-- VR Juggler Team                              www.vrjuggler.org
-- Virtual Reality Applications Center       www.vrac.iastate.edu

Re: [ggt-devel] SCons installation slow and messy

[Patrick H. <pa...@13...>]

On Wed, 2004-09-08 at 23:04 -0500, Ben Scott wrote:
> Well, the .sconsign problem can be solved by adding a line containing
> SConsignFile() to the SConstruct to force SCons to use a single file for
> all the cached data in the same directory as the SConstruct.

I am familiar with this function call.  Are there aspects of it that
make its use undesirable?  I guess having the cached data spread out
allows many SCons builds to make use of it.  I just don't understand why
those files are ending up in directories that have nothing at all to do
with compiling the software--which doesn't even have a compile phase in
this case.

> As for MD5 summing the entire installation tree, that is a problem.

It's something I have seen over and over again for many months.
Finding .sconsign files in my ~/.mozilla and ~/.gnome2 directories (for
example) is really frustrating.

> I'm
> not entirely sure what's going on there. However, we might be able to mak=
e
> that problem go away by adding the following line to the SConstruct:
>=20
> SetOption('implicit-deps-unchanged', 1)
>=20
> Give that a shot and see if that improves your install time.

Okay, thanks for the suggestions.

 -Patrick

> > I just performed an installation of GMTL 0.3.5 in a freshly created use=
r's
> > home directory, and the process took three full minutes--probably becau=
se
> > SCons was pooping .sconsign files throughout the user's *entire* home
> > directory.  I ran the GMTL build+install as follows:
> >
> >    % scons install prefix=3D$HOME
> >
> > Is it really necessary for SCons to do its MD5 summing over the entire
> > installation tree?  (I am assuming that SCons is doing this because of =
the
> > 'prefix' setting above and not just out of general confusion during the
> > build phase.)  For a sufficiently large directory tree, this wouild mak=
e
> > the GMTL build+install appear to hang for no obvious reason.  I can
> > definitely say that I have cancelled many a GMTL installation thinking
> > that SCons had gotten stuck on some step or another.
> >
> > Lastly, I realize that this is really an SCons question and not a GMTL
> > question.  In my (limited) experience with SCons, it seems like SCons
> > usually does the right thing, and it's the SConstruct file that has the
> > problem.  If this is an SCons problem (feature?), then I will redirect =
my
> > discontent to their mailing list.
> >
> >  -Patrick
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by BEA Weblogic Workshop
> > FREE Java Enterprise J2EE developer tools!
> > Get your free copy of BEA WebLogic Workshop 8.1 today.
> > http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=BFick
> > _______________________________________________
> > ggt-devel mailing list
> > ggt...@li...
> > https://lists.sourceforge.net/lists/listinfo/ggt-devel
> >
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=3D5047&alloc_id=3D10808&op=3Dclick
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel
--=20
Patrick L. Hartling                     | Research Assistant, VRAC
http://www.137.org/patrick/             | 2274 Howe Hall Room 2624
PGP: http://tinyurl.com/2oum9           | http://www.vrac.iastate.edu/

[ggt-devel] [ ggt-Bugs-1026050 ] SCons install broken

[SourceForge.net <no...@so...>]

Bugs item #1026050, was opened at 2004-09-10 14:30
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=437247&aid=1026050&group_id=43735

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Chad Austin (aegis)
Assigned to: Nobody/Anonymous (nobody)
Summary: SCons install broken

Initial Comment:
The SCons install doesn't install VecOpsMeta.h.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=437247&aid=1026050&group_id=43735

Re: [ggt-devel] SCons installation slow and messy

[Ben S. <bs...@ga...>]

Well, the .sconsign problem can be solved by adding a line containing
SConsignFile() to the SConstruct to force SCons to use a single file for
all the cached data in the same directory as the SConstruct.

As for MD5 summing the entire installation tree, that is a problem. I'm
not entirely sure what's going on there. However, we might be able to make
that problem go away by adding the following line to the SConstruct:

SetOption('implicit-deps-unchanged', 1)

Give that a shot and see if that improves your install time.

cheers,
-ben

> I just performed an installation of GMTL 0.3.5 in a freshly created user's
> home directory, and the process took three full minutes--probably because
> SCons was pooping .sconsign files throughout the user's *entire* home
> directory.  I ran the GMTL build+install as follows:
>
>    % scons install prefix=$HOME
>
> Is it really necessary for SCons to do its MD5 summing over the entire
> installation tree?  (I am assuming that SCons is doing this because of the
> 'prefix' setting above and not just out of general confusion during the
> build phase.)  For a sufficiently large directory tree, this wouild make
> the GMTL build+install appear to hang for no obvious reason.  I can
> definitely say that I have cancelled many a GMTL installation thinking
> that SCons had gotten stuck on some step or another.
>
> Lastly, I realize that this is really an SCons question and not a GMTL
> question.  In my (limited) experience with SCons, it seems like SCons
> usually does the right thing, and it's the SConstruct file that has the
> problem.  If this is an SCons problem (feature?), then I will redirect my
> discontent to their mailing list.
>
>  -Patrick
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_idP47&alloc_id808&op¿ick
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>

[ggt-devel] SCons installation slow and messy

[<pa...@13...>]

I just performed an installation of GMTL 0.3.5 in a freshly created user'=
s
home directory, and the process took three full minutes--probably because
SCons was pooping .sconsign files throughout the user's *entire* home
directory.  I ran the GMTL build+install as follows:

   % scons install prefix=3D$HOME

Is it really necessary for SCons to do its MD5 summing over the entire
installation tree?  (I am assuming that SCons is doing this because of th=
e
'prefix' setting above and not just out of general confusion during the
build phase.)  For a sufficiently large directory tree, this wouild make
the GMTL build+install appear to hang for no obvious reason.  I can
definitely say that I have cancelled many a GMTL installation thinking
that SCons had gotten stuck on some step or another.

Lastly, I realize that this is really an SCons question and not a GMTL
question.  In my (limited) experience with SCons, it seems like SCons
usually does the right thing, and it's the SConstruct file that has the
problem.  If this is an SCons problem (feature?), then I will redirect my
discontent to their mailing list.

 -Patrick

Re: [ggt-devel] Building the Python bindings

[John H. <jo...@co...>]

On Mon, 16 Aug 2004, Patrick Hartling wrote:

> On Mon, 2004-08-16 at 17:34 +0100, John Hodrien wrote:
>> On Mon, 16 Aug 2004, Patrick Hartling wrote:
>>
>>> John Hodrien wrote:
>>>> How do you build the python bindings?  I'm currently running:
>>>>
>>>> scons EnablePython=True BoostPythonDir=/blah/
>>>>
>>>> But I'm not getting anything sensible built.  What should I be running to
>>>> get
>>>> the python bindings out?
>>>
>>> That is the correct way to build the bindings.  What results are you
>>> getting?
>>
>> Right, I'm clearly not understanding what I'm doing enough, so I'll be more
>> verbose.  I'm not a python coder, that's something I'm needing to learn, so
>> bear with any idiocy I put across.  Sadly things are being done a little
>> backwards.
>>
>> I've downloaded gmtl, untarred, and run
>> scons EnablePython=True BoostPythonDir=/blah/
>>
>> What should I expect to be created?  I get a gmtl.so which is mammoth (161Mb)
>> and nothing else I can see of merit.
>
> That's exactly what you should expect.  That .so file can be loaded by
> Python as an extension.  You just need to put it somewhere (/usr/lib/
> pythonX.Y/site-packages is a likely place) that Python can find it at
> run time.  You can also set the $PYTHONPATH environment variable to
> extend Python's module search path.

Hmm, it was failing to pick it up, and was complaining about no module name
gmtl.  I'll have another attack at it.

Cheers,

jh

-- 
"I mean, if 10 years from now, when you are doing something quick and dirty,
  you suddenly visualize that I am looking over your shoulders and say to
  yourself, "Dijkstra would not have liked this", well that would be enough
  immortality for me."                                -- Edsgar Wybe Dijkstra

Re: [ggt-devel] Building the Python bindings

[Patrick H. <pa...@13...>]

On Mon, 2004-08-16 at 17:34 +0100, John Hodrien wrote:
> On Mon, 16 Aug 2004, Patrick Hartling wrote:
>=20
> > John Hodrien wrote:
> >> How do you build the python bindings?  I'm currently running:
> >>=20
> >> scons EnablePython=3DTrue BoostPythonDir=3D/blah/
> >>=20
> >> But I'm not getting anything sensible built.  What should I be running=
 to=20
> >> get
> >> the python bindings out?
> >
> > That is the correct way to build the bindings.  What results are you
> > getting?
>=20
> Right, I'm clearly not understanding what I'm doing enough, so I'll be mo=
re
> verbose.  I'm not a python coder, that's something I'm needing to learn, =
so
> bear with any idiocy I put across.  Sadly things are being done a little
> backwards.
>=20
> I've downloaded gmtl, untarred, and run
> scons EnablePython=3DTrue BoostPythonDir=3D/blah/
>=20
> What should I expect to be created?  I get a gmtl.so which is mammoth (16=
1Mb)
> and nothing else I can see of merit.

That's exactly what you should expect.  That .so file can be loaded by
Python as an extension.  You just need to put it somewhere (/usr/lib/
pythonX.Y/site-packages is a likely place) that Python can find it at
run time.  You can also set the $PYTHONPATH environment variable to
extend Python's module search path.

 -Patrick


--=20
Patrick L. Hartling                     | Research Assistant, VRAC
http://www.137.org/patrick/             | 2274 Howe Hall Room 2624
PGP: http://tinyurl.com/2oum9           | http://www.vrac.iastate.edu/