plib-devel

[Plib-devel] New CVS of PLIB pre-1.3.1

[Steve B. <sjb...@ai...>]

I've committed code into the PLIB 1.3 CVS tree that turns the 'UL'
(Utility Library) from a somewhat invisible header file into something
that the application code has to be aware of.

Previously, SSG used the src/util/ul.h header with a rather nasty
trick to get the non-inlined functions compiled into the SSG library.

That was necessary for backwards compatibility of application's
Makefiles.

Well, it's time to make libplibul.a and plib/ul.h into a 'real'
utility library.

So, from the current CVS (which will soon be PLIB 1.3.1) onwards,
applications must (at the very least) add '-lplibul' to their
link lines (after all the other plib libraries is best).

This library will grow to include a number of functions that are
traditionally Operating System functions - but which wouldn't be
portable if you called the OS directly.  Other similar utility
stuff that doesn't obviously belong anywhere else in PLIB will
end up in libutil.

So far, there is a simple error handler (which is already in
use within SSG's file loaders) and a fast, portable realtime
timer class.

[ PPE is currently using 'guClock' from the TuxKart sources,
this class exists in UL - but it's called 'ulClock', it includes
member functions to set and get the maximum clock delta and has
Windoze code to cater for systems that don't support the Performance
Counter - it falls back to using the multimedia timer. ]

Right now, no PLIB applications will work with this new CVS version.

That's not a suprise - this is version 1.3.xx and it's expected to
be unstable, etc.  If you need stability, use PLIB 1.2.0.

Ideally, one should add code into your configure.in to detect the
presence of /usr/lib/libplibul.a and to add it to the link line
if it exists.

Programs that don't use SSG don't need libplibul - but that will
certainly change as I use UL's error handler throughout PLIB.

If you want to call UL functions your code, you should:

1)  #include <plib/ul.h>

2)  Call 'ulInit()' before any other UL function.

3)  Link with -lplibul.a

I hate non-reverse-compatible changes - but this one was unavoidable.
We may possible add another PLIB library - for SSG utilities - but
that will be truly optional.  UL is not because PLIB itself needs
to use it.

Windoze users: Please don't get confused and look in the 'src/UL'
directory for UL source code - that was a mistake that CVS isn't
capable of fixing.  The correct place for UL code is src/util

If anyone out there could test ulClock under Windoze - and especially
on a Windoze machine that *doesn't* have a Performance counter - that
would be most welcome...I don't know whether the code even compiles
right now.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [Plib-devel] New CVS of PLIB pre-1.3.1

[Wolfram K. <w_...@rz...>]

Steve Baker wrote:

>[ PPE is currently using 'guClock' from the TuxKart sources,
>this class exists in UL - but it's called 'ulClock', it includes
>member functions to set and get the maximum clock delta and has
>Windoze code to cater for systems that don't support the Performance
>Counter - it falls back to using the multimedia timer. ]

Great, thanks!

BTW, why is there an 
void ulInit ( void )
in both ul.cxx and ulError.cxx? Should one not use ul.cxx?

Bye bye,
Wolfram Kuss.

Re: [Plib-devel] New CVS of PLIB pre-1.3.1

[Steve B. <sjb...@ai...>]

Wolfram Kuss wrote:
> 
> Steve Baker wrote:
> 
> >[ PPE is currently using 'guClock' from the TuxKart sources,
> >this class exists in UL - but it's called 'ulClock', it includes
> >member functions to set and get the maximum clock delta and has
> >Windoze code to cater for systems that don't support the Performance
> >Counter - it falls back to using the multimedia timer. ]
> 
> Great, thanks!
> 
> BTW, why is there an
> void ulInit ( void )
> in both ul.cxx and ulError.cxx? Should one not use ul.cxx?

Oops!  I didn't notice the on in ulError - I'll fix it now.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [Plib-devel] New CVS of PLIB pre-1.3.1

[Steve B. <sjb...@ai...>]

Steve Baker wrote:
> 
> Wolfram Kuss wrote:
> >
> > Steve Baker wrote:
> >
> > >[ PPE is currently using 'guClock' from the TuxKart sources,
> > >this class exists in UL - but it's called 'ulClock', it includes
> > >member functions to set and get the maximum clock delta and has
> > >Windoze code to cater for systems that don't support the Performance
> > >Counter - it falls back to using the multimedia timer. ]
> >
> > Great, thanks!
> >
> > BTW, why is there an
> > void ulInit ( void )
> > in both ul.cxx and ulError.cxx? Should one not use ul.cxx?
> 
> Oops!  I didn't notice the on in ulError - I'll fix it now.

OK - that's committed - sorry!

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [Plib-devel] New CVS of PLIB pre-1.3.1

[Curtis L. O. <cu...@me...>]

Steve,

Is there any way that you can engineer things on the plib end to
generate some sort of helpful error when a current application that is
expecting plib-1.2.x (and doesn't remember to call ulInit() for
instance) suddenly is compiled against plib-1.3.x.  My fear is that 6
months down the line when plib-1.3.x transitions to the stable tree,
I'll have completely forgotten this message and will end up wasting a
lot of time.  :-)

Steve Baker writes:
> I've committed code into the PLIB 1.3 CVS tree that turns the 'UL'
> (Utility Library) from a somewhat invisible header file into something
> that the application code has to be aware of.
> 
> Previously, SSG used the src/util/ul.h header with a rather nasty
> trick to get the non-inlined functions compiled into the SSG library.
> 
> That was necessary for backwards compatibility of application's
> Makefiles.
> 
> Well, it's time to make libplibul.a and plib/ul.h into a 'real'
> utility library.
> 
> So, from the current CVS (which will soon be PLIB 1.3.1) onwards,
> applications must (at the very least) add '-lplibul' to their
> link lines (after all the other plib libraries is best).
> 
> This library will grow to include a number of functions that are
> traditionally Operating System functions - but which wouldn't be
> portable if you called the OS directly.  Other similar utility
> stuff that doesn't obviously belong anywhere else in PLIB will
> end up in libutil.
> 
> So far, there is a simple error handler (which is already in
> use within SSG's file loaders) and a fast, portable realtime
> timer class.
> 
> [ PPE is currently using 'guClock' from the TuxKart sources,
> this class exists in UL - but it's called 'ulClock', it includes
> member functions to set and get the maximum clock delta and has
> Windoze code to cater for systems that don't support the Performance
> Counter - it falls back to using the multimedia timer. ]
> 
> Right now, no PLIB applications will work with this new CVS version.
> 
> That's not a suprise - this is version 1.3.xx and it's expected to
> be unstable, etc.  If you need stability, use PLIB 1.2.0.
> 
> Ideally, one should add code into your configure.in to detect the
> presence of /usr/lib/libplibul.a and to add it to the link line
> if it exists.

Is there a good function in libplibul.a that we can test for?
Autoconf has the AC_CHECK_LIB( lib, function) macro that will test for
a library and add it to the link line if it exists.

> Programs that don't use SSG don't need libplibul - but that will
> certainly change as I use UL's error handler throughout PLIB.
> 
> If you want to call UL functions your code, you should:
> 
> 1)  #include <plib/ul.h>
> 
> 2)  Call 'ulInit()' before any other UL function.
> 
> 3)  Link with -lplibul.a
> 
> I hate non-reverse-compatible changes - but this one was unavoidable.
> We may possible add another PLIB library - for SSG utilities - but
> that will be truly optional.  UL is not because PLIB itself needs
> to use it.
> 
> Windoze users: Please don't get confused and look in the 'src/UL'
> directory for UL source code - that was a mistake that CVS isn't
> capable of fixing.  The correct place for UL code is src/util
> 
> If anyone out there could test ulClock under Windoze - and especially
> on a Windoze machine that *doesn't* have a Performance counter - that
> would be most welcome...I don't know whether the code even compiles
> right now.

Curt.
-- 
Curtis Olson   Human Factors Research Lab       Flight Gear Project
Twin Cities    cu...@hf...                cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

Re: [Plib-devel] New CVS of PLIB pre-1.3.1

[Steve B. <sjb...@ai...>]

"Curtis L. Olson" wrote:

> Is there any way that you can engineer things on the plib end to
> generate some sort of helpful error when a current application that is
> expecting plib-1.2.x (and doesn't remember to call ulInit() for
> instance) suddenly is compiled against plib-1.3.x.

Well, apart from anything else, a PLIB 1.2 application is going to
fail to link against 1.3.1 (or 1.4 more importantly) because SSG
needs UL and a 1.2 application won't be linking to libplibul.a

>  My fear is that 6
> months down the line when plib-1.3.x transitions to the stable tree,
> I'll have completely forgotten this message and will end up wasting a
> lot of time.  :-)

Right now, ulInit() is an empty function - but I can certainly put some
'traps' into the code to check that it was called before any future
hypothetical function that might need it.
 
> Is there a good function in libplibul.a that we can test for?

  ulInit()

   :-P

> Autoconf has the AC_CHECK_LIB( lib, function) macro that will test for
> a library and add it to the link line if it exists.

Right - and I'm putting that into all my application's configure.in's
as we speak.
 
You'll also need:

#if WE_DETECTED_A_VALID_ulInit_IN_THE_CONFIGURE_SCRIPT

  ulInit () ;

#endif

...uck!  Messy!

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net