plib-devel

[Plib-devel] ssgaSpheres?

[Bram S. <br...@sa...>]

Hello,

I'm doing intersections tests of spheres against scenegraphs.
To aide debugging, I want to visualize the sgSphere I use for
testing, with ssgaSpheres. Strangely enough, I cannot make them
scale to the same size.

I suspect a bug in ssgaSphere.
At the very least, the different lat-long styles are broken,
because this code:

  ssgaSphere sphere0;
  ssgaSphere sphere1;

  sphere0.setLatLongStyle(FALSE);
  sphere0.setSize(1.0);
  sgSphere *bounds0=3Dsphere0.getBSphere();
  const float *c0 =3D bounds0->getCenter();
  printf("bounds0: center=3D%f,%f,%f radius=3D%f\n", c0[0],c0[1],c0=20
[2],bounds0->getR
adius());

  sphere1.setLatLongStyle(TRUE);
  sphere1.setSize(1.0);
  sgSphere *bounds1=3Dsphere1.getBSphere();
  const float *c1 =3D bounds1->getCenter();
  printf("bounds1: center=3D%f,%f,%f radius=3D%f\n", c1[0],c1[1],c1=20
[2],bounds1->getR
adius());

gives this output:

  bounds0: center=3D-0.124761,0.005011,0.317507 radius=3D1.860521
  bounds1: center=3D0.000000,0.000000,-0.000000 radius=3D0.947555

...which looks wrong for three reasons:

1) radius of non latlong sphere is roughly twice as big
2) radii are not 1.0
3) center of bounding sphere for non latlong sphere is not 0,0,0

Now, it is not just a bounds-only bug, because when rendering them,
switching styles clearly affects the size of the sphere I see on-=20
screen.

Any ideas?
This is on linux, from CVS.

  Bram

Re: [Plib-devel] Problems with sound under Windows XP.

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

Wolfram Kuss wrote:
> FWIW, there was a thread "Error in SlDSP" started on 12.3.2002 about
> this.It seems it is a timing issue with some sound cards.

Aha!

> From: Paul Deppe <paul@ve...>
> RE: Error in SlDSP  
> 2002-03-12 10:43
> 
>  > When running the PLIB/SL example programs on Cygwin/Win2k, I get
>  > the following error:
>  >
>  > WARNING: SlDSP: Cannot perform this operation while media data is
>  > still playing.
>  >   Reset the device, or wait until the data is finished playing. (33)
>  >
>  > ...and the sound stops playing.  Ctrl-C is needed to abort the program.
>  >
>  > Therer are no other programs running at the time.  I have played
>  > with the settings for my sound driver (i.e. turned off HW
>  > acceleration, etc.), but the error still occurs.  Interestingly
>  > the error still occurs with all sounds muted.
>  >
>  > Does anyone else see this error on their Windoze or other system?
>  
>  More info:  The example program runs fine on my older PC with a
>  SoundBlaster-compatible sound card.  It does not work on my Dell 8100 Laptop
>  with ESS Maestro PCI Audio.
>  
>  The symptoms are these:  After running ./example.exe from the Cygwin command
>  line, the WARNING message (see above) appears and the first sound plays 3
>  1/2 times, then stops.  The same thing happens with mod_demo.exe, only a few
>  seconds of music are played.
>  
>  I am trying to track this down with gdb but am not very familiar with sound
>  card programming on Windoze (yet!) so if anyone has any ideas I"m all ears.
>  
>  Thanks,
>  
>  Paul

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

Re: [Plib-devel] Problems with sound under Windows XP.

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

=46WIW, there was a thread "Error in SlDSP" started on 12.3.2002 about
this.It seems it is a timing issue with some sound cards.

Bye bye,
Wolfram.

[Plib-devel] Problems with sound under Windows XP.

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

A friend of mine is helping me get a PLIB application running under Windows XP.
Everything works except for the audio.

Here is what he says:

David Lenihan wrote:

 > I hear sound for a fraction of a second at startup and then it abruptly turns
 > off.  This is what the console says:
 >
 > Data files will be fetched from: '.'
 > Playing 'audio/song06.mod'
 > WARNING: SlDSP: Cannot perform this operation while media data is still
 > playing.
 >   Reset the device, or wait until the data is finished playing. (33)

Can anyone shed any light on this?

The text of that message isn't inside PLIB but the 'WARNING: SlDSP' part
must come from PLIB...so I think it must be coming from:

plib/src/sl/slDSP.cxx:

Line 170:

static  void    wperror(MMRESULT num)
{
    char buffer[0xff];  // yes, this is hardcoded :-)

    waveOutGetErrorText( num, buffer, sizeof(buffer)-1);

    ulSetError ( UL_WARNING, "SlDSP: %s (%d)", buffer, num );
}

....that's called in three places - all of them in slDSP::open which
is a Windows-specific chunk of code containing a bunch of 'waveOut...()'
stuff that I don't understand!

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

[Plib-devel] Patch: 3DS loader, ssgaShapes

[Paolo L. <p.l...@ci...>]

Dear all,

I'd like to submit the following patches to the 3DS loader and to the
ssgaShapes:

ftp://ftp.cira.it/download/lepa069/ssgLoad3ds.diff
ftp://ftp.cira.it/download/lepa069/ssg3ds.diff
ftp://ftp.cira.it/download/lepa069/ssgaShapes.diff

Files will be there for a couple of days, yet I can renew the post.

What is new in this version:

- 3DS loader: a further way to describe hierarchy is now managed, namely
the mechanism based on the $$$DUMMY object name;

- 3DS loader: a global flag variable _3DS_use_smoothing_groups is
exposed to control wether using smoothing group information found in the
3DS file or not. It's desirable to route such flag and the crease angle
value to the 3DS and the other loaders through the ssgLoaderOptions
mechanism;

- ssgaShapes: ssgaCube::regenerate() has been completely rewritten since
the previous version showed sort of smooth normals between some couple
of faces due to the reuse of some vertices, and texture coords were
broken for some faces;

- ssgaShapes: I have inverted normals in ssgaCylinder::regenerate() -
now lighting seems in the correct way.


If agreed on the modifications I kindly ask somebody to commit them for
me. Thanks in advance.

Greetings -

Paolo Leoncini


------------------------------------------------------------------------
-
Paolo Leoncini     phone:  +39 (0823) 623134
Visualization & Virtual Reality   fax:    +39 (0823) 623126
CIRA - Italian Center for Aerospace Researches mailto:p.l...@ci...

Via Maiorise - 81043 Capua (CE) Italy  http://www.cira.it

[Plib-devel] FlightGear in AIAA Magazine

[Fay J. F C. AAC/W. <joh...@eg...>]

Gentlemen,

	The American Institute of Aeronautics and Astronautics has a monthly
trade magazine called _Aerospace America_.  The most recent issue (January
2005) contains an article in the "Systems and Software" department:  "More
than games for flying planes."  The article spends a bit of time on
Microsoft's Flight Simulator program and then has a heading "Open source
solution."  The article then concludes:

"The use of COTS (commercial off the shelf) software such as FS brings up a
critical matter in the aerospace and defense industry:  the open source
issue.  At the AIAA's recent Modeling and Simulation Technologies
Conference, a panel discussion raised an important question:  How can
engineers use and modify COTS tools to best meet their needs?  There are a
number of approaches to solving this problem, but for each approach, someone
has to give up some control, revenue, or features.  Software vendors and
customers must find a way to develop procedures to keep enhancing the state
of technology, provide engineers with the tools they need, and allow the
software vendors to make money so they can continue to grow.

"An example of how this has worked involves the software product FlightGear,
an open-source, multiplatform, cooperative flight simulator development
project.  Source code for the entire project is available and licensed under
the GNU General Public License.

"The goal of the FlightGear project is to create a sophisticated flight
simulator framework for use in research or academic environments, for the
development and pursuit of other interesting flight simulation ideas, and as
an end-user application.  This loosely organized group is developing a
sophisticated, open simulation framework that can be expanded and improved
by anyone interested in contributing.

"The idea for FlightGear was born out of dissatisfaction with current
commercial PC flight simulators.  A big problem with the COTS simulators is
their lack of extensibility and the proprietary attitude of their
manufacturers.  There are so many people across the world with great ideas
for enhancing these simulators--people who have the ability to write code,
and who have a desire to learn and contribute.  Many people in education and
research could use a spiffy flight simulator framework on which to build
their own projects; but commercial simulators do not lent themselves to
modification and enhancement.  The FlightGear project is striving to fill
this gap.

"Commercial organizations must find ways to incorporate their proprietary
products or features as extensions to lower cost product solutions.  Control
simulation software companies such as MathWorks, National Instruments, and
others should provide low-level extensions to these existing products or
open their algorithms so that others can use the technology to solve the
technical aerospace and defense problems that engineers are working on
today."

Bravissimo!

John F. Fay
joh...@eg...
850-729-6330 

[Plib-devel] Documentation for PLIB-1.8.4 missing

[Gerald F. <gf...@tu...>]

Dear plib developers,

I still cannot find the documentation included in the examples 
tarball. To my mind it should be located at plib_examples.1-8-4/doc
I only find there a CVS directory. The same for plib_examples.1-8-4/data .

It would be nice if this could be fixed for the upcoming release.

Best regards
Gerald

Re: [Plib-devel] Portability - policy suggestion

[Martin S. <Mar...@un...>]

Steve Baker wrote:

> Well, it's not the end of the world - [...]

You don't have any idea on how much people depend on PLIB releases  ;-))

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

Re: [Plib-devel] Portability - policy suggestion

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

Martin Spott wrote:

> Maybe with so many so loosely coupled contributors such a tight timing
> is probably not the best way to go,

Well, it's not the end of the world - we can just make another release
within a week or two.

Once we've gotten the thing to the point where it's basically releasable,
doing a new version is a 10 minute job - and version numbers are a very
cheap commodity.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

Re: [Plib-devel] Portability - policy suggestion

[Martin S. <Mar...@un...>]

I'm sorry, folks, for the unbaken posting. Here's the complete one:

Bert Driehuis wrote:

> Hrrrm, with 20/20 hindsight it is obvious that I screwed this one up. 

There's no problem about doing something wrong - we are human beings
and everyone is at fault sometime. It's just that the timing was very
bad. Steven announced he'd go for a release on the 11th, you added one
patch on the 12th, I repeated that one patch was still missing on the
13th, including a copy of the patch (and everyone ignored it), Steven
did the release on the 15th - and we recieve your comment on the 16th.

Maybe with so many so loosely coupled contributors such a tight timing
is probably not the best way to go,

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

Re: [Plib-devel] Portability - policy suggestion

[Martin S. <Mar...@un...>]

Bert Driehuis wrote:
> On Sat, 15 Jan 2005, Alex Perry wrote:

>> Steve, maybe we could have a policy that, for every apparently-supported
>> target architecture, at least one of the developers with write access
>> must be able to build and run code on that architecture.  If that is not
>> the case, either none of the relevant contributors meets the project's
>> criteria for write access or (more likely) they need to be added ...

> Hrrrm, with 20/20 hindsight it is obvious that I screwed this one up. 
> Let me share what I did.

> I reviewed all patches Martin had pointed me to, applied the good ones 
> one by one on my development machine, and reported the ones I would not 
> take ownership of to this list. After applying a patch, I do a build in 
> the development tree to verify that the problem has gone before I commit 
> it (for a build problem, that's verifying that the build proceeds, for a 
> crash, it's running the appropriate test code, etc).

> If I don't have a perfect explanation for why something fixes it, I even 
> go as far as temporarily backing out the change in a scratch build tree 
> to check that the problem comes back without the fix.

> When I'm done, I go back and do a cvs -q diff over the whole tree. I 
> obviously borked this step (probably by not running it over the entire 
> tree), as the uncommitted patch was happily staring at me when I diffed 
> it this morning.

> I usually catch such goofs by building a test straight from anon-cvs, 
> but that day anon-cvs was a bit backlogged so I couldn't do it at home. 
> I did a test build at $ORKPLACE under FreeBSD 4.10 the next day, and as 
> fate would have it, the 4.10 has both 
> /usr/include/{sys,machine}/soundcard.h, so the patch isn't required 
> there.

> Anyway, I apologize for the goof. If you can think of procedural changes 
> to prevent reoccurance I'm all ears.

> For what it's worth, just applying all patches that are available isn't 
> the answer. Patch trackers, like the one on Sourceforge, only work when 
> patches that are below par get rejected immediately. I've payed dearly 
> for keeping patches because they "contain good ideas" -- they linger and 
> realistically, if the submitter doesn't find the time to do them right, 
> what is the chance that you as a maintainer will?

> Cheers,

>  				-- Bert

> -- 
> Bert Driehuis -- dri...@pl... -- +31-20-3116119
> If the only tool you've got is an axe, every problem looks like fun!


> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel



-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

Re: [Plib-devel] Portability - policy suggestion

[Bert D. <dri...@pl...>]

On Sat, 15 Jan 2005, Alex Perry wrote:

> Steve, maybe we could have a policy that, for every apparently-supported
> target architecture, at least one of the developers with write access
> must be able to build and run code on that architecture.  If that is not
> the case, either none of the relevant contributors meets the project's
> criteria for write access or (more likely) they need to be added ...

Hrrrm, with 20/20 hindsight it is obvious that I screwed this one up. 
Let me share what I did.

I reviewed all patches Martin had pointed me to, applied the good ones 
one by one on my development machine, and reported the ones I would not 
take ownership of to this list. After applying a patch, I do a build in 
the development tree to verify that the problem has gone before I commit 
it (for a build problem, that's verifying that the build proceeds, for a 
crash, it's running the appropriate test code, etc).

If I don't have a perfect explanation for why something fixes it, I even 
go as far as temporarily backing out the change in a scratch build tree 
to check that the problem comes back without the fix.

When I'm done, I go back and do a cvs -q diff over the whole tree. I 
obviously borked this step (probably by not running it over the entire 
tree), as the uncommitted patch was happily staring at me when I diffed 
it this morning.

I usually catch such goofs by building a test straight from anon-cvs, 
but that day anon-cvs was a bit backlogged so I couldn't do it at home. 
I did a test build at $ORKPLACE under FreeBSD 4.10 the next day, and as 
fate would have it, the 4.10 has both 
/usr/include/{sys,machine}/soundcard.h, so the patch isn't required 
there.

Anyway, I apologize for the goof. If you can think of procedural changes 
to prevent reoccurance I'm all ears.

For what it's worth, just applying all patches that are available isn't 
the answer. Patch trackers, like the one on Sourceforge, only work when 
patches that are below par get rejected immediately. I've payed dearly 
for keeping patches because they "contain good ideas" -- they linger and 
realistically, if the submitter doesn't find the time to do them right, 
what is the chance that you as a maintainer will?

Cheers,

 				-- Bert

-- 
Bert Driehuis -- dri...@pl... -- +31-20-3116119
If the only tool you've got is an axe, every problem looks like fun!

Re: [Plib-devel] Portability - policy suggestion

[Frederic B. <fre...@fr...>]

Frederic Bouvier a =E9crit :

> Steve Baker a =E9crit :
>
>> Alex Perry wrote:
>>
>>> Steve, maybe we could have a policy that, for every=20
>>> apparently-supported
>>> target architecture, at least one of the developers with write access
>>> must be able to build and run code on that architecture.
>>
>>
>>
>> I have never yet refused a request for developer privilages.  If someo=
ne
>> wants to do that, they only have to ask.  I believe I gave one of the=20
>> BSD
>> guy's access only a week or two ago.
>
>
> It could help to use a central patch submission repository like the=20
> one provided by sourceforge, so patches are not lost in the bulk of=20
> the list. I see the 'Patches' option is not enabled for the Plib=20
> project but it is available to project admin. As an example, here is=20
> the patch submission form from the fgsd project :
> http://sourceforge.net/tracker/?func=3Dadd&group_id=3D45131&atid=3D4419=
62
>
> A list of categories could help too, beginning with the list of=20
> currently supported OS, and an assigned maintainer that could refer to=20
> the list just *before* a release if he follow the list loosely.

May I also suggest that any new ( or already registered ) developer be=20
assigned a specific task/category so that it is clear who is doing what=20
and no one wait the other do the job.

I am volunteering to maintain the windows build. My sourceforge account=20
is 'fredb'.

Regards,
-Fred

Re: [Plib-devel] Portability - policy suggestion

[Frederic B. <fre...@fr...>]

Steve Baker a =E9crit :

> Alex Perry wrote:
>
>> Steve, maybe we could have a policy that, for every apparently-support=
ed
>> target architecture, at least one of the developers with write access
>> must be able to build and run code on that architecture.
>
>
> I have never yet refused a request for developer privilages.  If someon=
e
> wants to do that, they only have to ask.  I believe I gave one of the B=
SD
> guy's access only a week or two ago.

It could help to use a central patch submission repository like the one=20
provided by sourceforge, so patches are not lost in the bulk of the=20
list. I see the 'Patches' option is not enabled for the Plib project but=20
it is available to project admin. As an example, here is the patch=20
submission form from the fgsd project :
http://sourceforge.net/tracker/?func=3Dadd&group_id=3D45131&atid=3D441962

A list of categories could help too, beginning with the list of=20
currently supported OS, and an assigned maintainer that could refer to=20
the list just *before* a release if he follow the list loosely.

-Fred

Re: [Plib-devel] Portability; Was: Minor Issues with PLIB Release

[Martin S. <Mar...@un...>]

Steve Baker wrote:

> That change is now committed.

Thanks,
	Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

Re: [Plib-devel] Portability - policy suggestion

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

Alex Perry wrote:
> Steve, maybe we could have a policy that, for every apparently-supported
> target architecture, at least one of the developers with write access
> must be able to build and run code on that architecture.

I have never yet refused a request for developer privilages.  If someone
wants to do that, they only have to ask.  I believe I gave one of the BSD
guy's access only a week or two ago.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

Re: [Plib-devel] Portability; Was: Minor Issues with PLIB Release Candidate

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

Steve Baker wrote:
> Frederic Bouvier wrote:
> 
>> The patch against src/sl/slPortability.h is still missing:
>>
>> --- ./src/sl/slPortability.h.orig    Sat Sep  7 17:54:59 2002
>> +++ ./src/sl/slPortability.h    Sat Sep  7 17:55:22 2002
>> @@ -74,7 +74,7 @@
>> #  if defined(__linux__)
>> #    include <linux/soundcard.h>
>> #  elif defined(__FreeBSD__)
>> -#    include <machine/soundcard.h>
>> +#    include <sys/soundcard.h>
>> #  else
>>     /*
>>       Tom thinks this file may be <sys/soundcard.h> under some

That change is now committed.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

Re: [Plib-devel] Portability; Was: Minor Issues with PLIB Release

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

Martin Spott wrote:
> Steve Baker wrote:
> 
> 
>>Well, someone needs to commit that change.  I said several days
>>ago that we were going for a release - it's not like there wasn't
>>any warning.
> 
> 
> What else please should I do besides pointing at this missing fix in
> order to get it committed ? I _did_ post an appropriate comment on this
> list recently after you anounced you'd go for a release and I already
> did so some time before. Don't blame me for staying silent,

OK - well let's just make sure we get it in *NOW* and get another
release out in a week or so.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

[Plib-devel] Portability - policy suggestion

[Alex P. <ale...@ie...>]

Steve, maybe we could have a policy that, for every apparently-supported
target architecture, at least one of the developers with write access
must be able to build and run code on that architecture.  If that is not
the case, either none of the relevant contributors meets the project's
criteria for write access or (more likely) they need to be added ...

Re: [Plib-devel] Portability; Was: Minor Issues with PLIB Release

[Martin S. <Mar...@un...>]

Steve Baker wrote:

> Well, someone needs to commit that change.  I said several days
> ago that we were going for a release - it's not like there wasn't
> any warning.

What else please should I do besides pointing at this missing fix in
order to get it committed ? I _did_ post an appropriate comment on this
list recently after you anounced you'd go for a release and I already
did so some time before. Don't blame me for staying silent,

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

Re: [Plib-devel] Portability; Was: Minor Issues with PLIB Release Candidate

[Frederic B. <fre...@fr...>]

Steve Baker wrote :

> Frederic Bouvier wrote:
>
>> The patch against src/sl/slPortability.h is still missing:
>>
>> --- ./src/sl/slPortability.h.orig    Sat Sep  7 17:54:59 2002
>> +++ ./src/sl/slPortability.h    Sat Sep  7 17:55:22 2002
>> @@ -74,7 +74,7 @@
>> #  if defined(__linux__)
>> #    include <linux/soundcard.h>
>> #  elif defined(__FreeBSD__)
>> -#    include <machine/soundcard.h>
>> +#    include <sys/soundcard.h>
>> #  else
>>     /*
>>       Tom thinks this file may be <sys/soundcard.h> under some
>
>
> Well, someone needs to commit that change.  I said several days
> ago that we were going for a release - it's not like there wasn't
> any warning.
>
> I plan to do another release as soon as John Fay can get his
> PUI changes in - let's make sure we catch this one next time.

The problem here is often that people needing these changes don't have 
write access and those who have seems to don't bother or just wait 
someone else do the job. And this project has 24 registered developers :-(

-Fred

Re: [Plib-devel] Portability; Was: Minor Issues with PLIB Release Candidate

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

Frederic Bouvier wrote:

> The patch against src/sl/slPortability.h is still missing:
> 
> --- ./src/sl/slPortability.h.orig    Sat Sep  7 17:54:59 2002
> +++ ./src/sl/slPortability.h    Sat Sep  7 17:55:22 2002
> @@ -74,7 +74,7 @@
> #  if defined(__linux__)
> #    include <linux/soundcard.h>
> #  elif defined(__FreeBSD__)
> -#    include <machine/soundcard.h>
> +#    include <sys/soundcard.h>
> #  else
>     /*
>       Tom thinks this file may be <sys/soundcard.h> under some

Well, someone needs to commit that change.  I said several days
ago that we were going for a release - it's not like there wasn't
any warning.

I plan to do another release as soon as John Fay can get his
PUI changes in - let's make sure we catch this one next time.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

Re: [Plib-devel] Portability; Was: Minor Issues with PLIB Release Candidate

[Frederic B. <fre...@fr...>]

Steve Baker a =E9crit :

> Martin Spott wrote:
>
>> Steve Baker wrote:
>>
>>
>>> These relatively new C++ features are always tricky - we should
>>> avoid them in software like PLIB where portability is a key feature.
>>
>>
>>
>> While you are talking about portability: Is there any significant
>> reason why the fix that is required to build PLIB on FreeBSD is being
>> silently ignored ?
>
>
> I thought all but one of the changes were in there?
>
> Certainly the fixes for the joystick library are.
>
> The only fix I'm aware of that wasn't committed was the one about
> removing glIsValidContext.   That isn't a bug in PLIB - it's a bug
> elsewhere.  You need to be complaining (or helping with a fix) in
> some other part of the system rather than breaking this library to
> cover up a bug in some other library.
>
> If glIsValidContext is broken, it's almost certainly just the first
> symptom of a BUNCH of other things that are broken that you just
> haven't noticed yet.
>
I guess Martin was writting about this one :

The patch against src/sl/slPortability.h is still missing:

--- ./src/sl/slPortability.h.orig	Sat Sep  7 17:54:59 2002
+++ ./src/sl/slPortability.h	Sat Sep  7 17:55:22 2002
@@ -74,7 +74,7 @@
 #  if defined(__linux__)
 #    include <linux/soundcard.h>
 #  elif defined(__FreeBSD__)
-#    include <machine/soundcard.h>
+#    include <sys/soundcard.h>
 #  else
     /*
       Tom thinks this file may be <sys/soundcard.h> under some




-Fred

Re: [Plib-devel] Portability; Was: Minor Issues with PLIB Release Candidate

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

Martin Spott wrote:
> Steve Baker wrote:
> 
> 
>>These relatively new C++ features are always tricky - we should
>>avoid them in software like PLIB where portability is a key feature.
> 
> 
> While you are talking about portability: Is there any significant
> reason why the fix that is required to build PLIB on FreeBSD is being
> silently ignored ?

I thought all but one of the changes were in there?

Certainly the fixes for the joystick library are.

The only fix I'm aware of that wasn't committed was the one about
removing glIsValidContext.   That isn't a bug in PLIB - it's a bug
elsewhere.  You need to be complaining (or helping with a fix) in
some other part of the system rather than breaking this library to
cover up a bug in some other library.

If glIsValidContext is broken, it's almost certainly just the first
symptom of a BUNCH of other things that are broken that you just
haven't noticed yet.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

[Plib-devel] Portability; Was: Minor Issues with PLIB Release Candidate

[Martin S. <Mar...@un...>]

Steve Baker wrote:

> These relatively new C++ features are always tricky - we should
> avoid them in software like PLIB where portability is a key feature.

While you are talking about portability: Is there any significant
reason why the fix that is required to build PLIB on FreeBSD is being
silently ignored ?

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------