plib-devel

RE: [Plib-devel] Olivier's js code

[LAVIGNE,ERIC <la...@uf...>]

When I submit this to cvs, I will be giving credit to Olivier as 
the author. With that in mind, I would prefer to use Olivier's 
version of the files from
http://perso.wanadoo.fr/oliver77-htm/plib/liste.htm.

I found two problems with Olivier's version: (1) Steve Baker made 
a change to jsMacOSX.cxx on Mar 18, 2004, and that change is not 
reflected in Olivier's file. (2) Most plib files have an 18 line 
copyright/license comment at the top. Olivier's jsMacOSX.cxx does 
not, and neither does the CVS version.

John Fay's version of jsMacOSX.cxx does not have either of these 
problems and is otherwise very similar to Olivier's version. I 
propose committing John Fay's version of jsMacOSX.cxx and 
Olivier's version of everything else.

I will commit the files on Saturday evening if there are no 
objections before that time.

Eric Lavigne


On Fri Aug 13 09:53:16 EDT 2004, Fay John F Contr AAC/WMG 
<joh...@eg...> wrote:

> Folks,
> 
> 	To provide more info on the compiler error, here is what I got 
> from
> Mr. Jones:
> 
> <begin quote>
> Black flag on the first lap...
> 
> jsLinuxOld.cxx: In constructor `jsJoystick::jsJoystick(int)':
> jsLinuxOld.cxx:97: error: `num_hats' undeclared (first use this
> function)
> jsLinuxOld.cxx:97: error: (Each undeclared identifier is reported 
> only
> once for
>    each function it appears in.)
> make: *** [jsLinuxOld.o] Error 1
>  (undoubtedly a simple fix, but I'll look at it after checking in 
> your
> other dozen changes. ;) )
> <end quote>
> 
> If you look at line 97 of "jsLinuxOld.cxx", you will find that 
> the variable
> "num_hats" does not appear there.  In fact, it does not appear 
> anywhere in
> the file!  So I do not think the problem was with Olivier's code.
> 
> 	I've checked Olivier's code against what I submitted and there 
> are a
> few differences, some formatting and some significant.  I can 
> forward a copy
> of what I have to any interested parties.
> 
> John F. Fay
> joh...@eg...
> 
> 
> 
> -----Original Message-----
> From: pli...@li...
> [mailto:pli...@li...]On Behalf Of 
> LAVIGNE,ERIC
> Sent: Thursday, August 12, 2004 4:47 PM
> To: pli...@li...
> Subject: [Plib-devel] Olivier's js code
> 
> 
> 
> I am willing and able to commit the files from
> http://perso.wanadoo.fr/oliver77-htm/plib/liste.htm
> 
> I'm holding off for now, though, because it's not clear that
> we're done discussing it. John and Ima seem certain that it's
> an improvement, but JC couldn't even compile it (more details
> on that anyone?).
> 
> Eric Lavigne
> 
> <snip>
> 

RE: [Plib-devel] Olivier's js code

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

Folks,

	To provide more info on the compiler error, here is what I got from
Mr. Jones:

<begin quote>
Black flag on the first lap...

jsLinuxOld.cxx: In constructor `jsJoystick::jsJoystick(int)':
jsLinuxOld.cxx:97: error: `num_hats' undeclared (first use this
function)
jsLinuxOld.cxx:97: error: (Each undeclared identifier is reported only
once for
   each function it appears in.)
make: *** [jsLinuxOld.o] Error 1
 
(undoubtedly a simple fix, but I'll look at it after checking in your
other dozen changes. ;) )
<end quote>

If you look at line 97 of "jsLinuxOld.cxx", you will find that the variable
"num_hats" does not appear there.  In fact, it does not appear anywhere in
the file!  So I do not think the problem was with Olivier's code.

	I've checked Olivier's code against what I submitted and there are a
few differences, some formatting and some significant.  I can forward a copy
of what I have to any interested parties.

John F. Fay
joh...@eg...



-----Original Message-----
From: pli...@li...
[mailto:pli...@li...]On Behalf Of LAVIGNE,ERIC
Sent: Thursday, August 12, 2004 4:47 PM
To: pli...@li...
Subject: [Plib-devel] Olivier's js code



I am willing and able to commit the files from
http://perso.wanadoo.fr/oliver77-htm/plib/liste.htm

I'm holding off for now, though, because it's not clear that
we're done discussing it. John and Ima seem certain that it's
an improvement, but JC couldn't even compile it (more details
on that anyone?).

Eric Lavigne

<snip>

[Plib-devel] Olivier's js code

[LAVIGNE,ERIC <la...@uf...>]

I am willing and able to commit the files from
http://perso.wanadoo.fr/oliver77-htm/plib/liste.htm

I'm holding off for now, though, because it's not clear that
we're done discussing it. John and Ima seem certain that it's
an improvement, but JC couldn't even compile it (more details
on that anyone?).

Eric Lavigne

On Thu Aug 12 05:59:26 EDT 2004, ima...@ve... wrote:

> 
> On Aug 11, 2004, at 11:33 PM, John F. Fay wrote:
> 
>> 
>> (1) The "js" library changes didn't make it in.  I asked JC to 
>> put them in
>> but when he tried compiling them he got an error in 
>> "jsLinuxOld.cxx".
> 
> Could one ask: what error and where in jsLinuxOld.cxx? 8-)
> 
>> The
>> line he quoted wasn't in the source that I have, and I am not 
>> sure what has
>> gone wrong.  The changes are the long-awaited JS rewrite that 
>> Olivier did
>> (last March?)
> 
> It's actually worse than March, my first version was from 
> February! 8-(
> 
> Yes, long, long awaited!
> 
>> and it works fine on my Windows system, but it hasn't (after
>> five months) gotten into CVS yet.  Really, this is a scandal!
> 
> Olivier's new JS code works great on my systems (both Mac os X 
> and Cygwin on win2k), fixing an OFTEN ENCOUNTERED bus error 
> problem on mac os x, and getting hats and other things to work on 
> both systems.
> 
> My version came from Olivier A.'s web site:   
> <http://perso.wanadoo.fr/oliver77-htm/plib/liste.htm>. The site 
> is still active as of 11:00 GMT Thursday.
> 
> This is the directory listing that I've got on my systems:
> 
> plib/src/js] ima% ls -l *.cxx *.h
> -rw-r--r--  1 ima  staff   2328  9 May 06:54 js.cxx
> -rw-r--r--  1 ima  staff   3091  9 May 06:54 js.h
> -rw-r--r--  1 ima  staff  12009  9 May 06:54 jsBSD.cxx
> -rw-r--r--  1 ima  staff   4250  9 May 06:54 jsLinux.cxx
> -rw-r--r--  1 ima  staff   2999  9 May 06:54 jsLinuxOld.cxx
> -rw-r--r--  1 ima  staff   7765  9 May 06:54 jsMacOS.cxx
> -rw-r--r--  1 ima  staff  12133  9 May 06:54 jsMacOSX.cxx
> -rw-r--r--  1 ima  staff   1392  9 May 06:54 jsNone.cxx
> -rw-r--r--  1 ima  staff   7291  9 May 06:54 jsWindows.cxx
> 
> Thank you Olivier, wherever you are, and thank you whoever 
> actually both has the authority to add this new js code and is 
> willing to do so!
> 
> (And thanks John for reminding us all that this great js code 
> isn't in yet.)
> 
> Ima
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank 
> Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel
> 
> 

[Plib-devel] Re: more PLIB changes

[<ima...@ve...>]

On Aug 11, 2004, at 11:33 PM, John F. Fay wrote:

>
> (1) The "js" library changes didn't make it in.  I asked JC to put 
> them in
> but when he tried compiling them he got an error in "jsLinuxOld.cxx".

Could one ask: what error and where in jsLinuxOld.cxx? 8-)

> The
> line he quoted wasn't in the source that I have, and I am not sure 
> what has
> gone wrong.  The changes are the long-awaited JS rewrite that Olivier 
> did
> (last March?)

It's actually worse than March, my first version was from February! 8-(

Yes, long, long awaited!

> and it works fine on my Windows system, but it hasn't (after
> five months) gotten into CVS yet.  Really, this is a scandal!

Olivier's new JS code works great on my systems (both Mac os X and 
Cygwin on win2k), fixing an OFTEN ENCOUNTERED bus error problem on mac 
os x, and getting hats and other things to work on both systems.

My version came from Olivier A.'s web site:   
<http://perso.wanadoo.fr/oliver77-htm/plib/liste.htm>. The site is 
still active as of 11:00 GMT Thursday.

This is the directory listing that I've got on my systems:

plib/src/js] ima% ls -l *.cxx *.h
-rw-r--r--  1 ima  staff   2328  9 May 06:54 js.cxx
-rw-r--r--  1 ima  staff   3091  9 May 06:54 js.h
-rw-r--r--  1 ima  staff  12009  9 May 06:54 jsBSD.cxx
-rw-r--r--  1 ima  staff   4250  9 May 06:54 jsLinux.cxx
-rw-r--r--  1 ima  staff   2999  9 May 06:54 jsLinuxOld.cxx
-rw-r--r--  1 ima  staff   7765  9 May 06:54 jsMacOS.cxx
-rw-r--r--  1 ima  staff  12133  9 May 06:54 jsMacOSX.cxx
-rw-r--r--  1 ima  staff   1392  9 May 06:54 jsNone.cxx
-rw-r--r--  1 ima  staff   7291  9 May 06:54 jsWindows.cxx

Thank you Olivier, wherever you are, and thank you whoever actually 
both has the authority to add this new js code and is willing to do so!

(And thanks John for reminding us all that this great js code isn't in 
yet.)

Ima

RE: [Plib-devel] On First Looking Into Baker's SSG (with apologie s to John Keats)

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

We will need puValue functionality in every non-group widget, and possibly
in group widgets as well.  I'll have to go look at the PUI compound widgets
again.

It has been a while since I looked at compound widgets, but I think I made
them inherit from "puGroup" because if I didn't, there would be confusion
over things like traversing them and deleting them in the widget tree.  Each
PUI widget is automatically added to its parent "puGroup" widget's "dlist"
at creation, and if I have a compound widget that contains other widgets
then the subwidgets are added to the parent (compound) widget's parent group
widget's dlist.  There are ways around it, but I either need guidance or
need to do some thinking.

Regarding multiple inheritance, what do we do in a case where two widgets
are in some ways quite similar but in other ways quite different?  For
example, the "puInput" and the "puLargeInput" have a lot of input functions
in common.  I put them into a common "puInputBase" class and had the
"puInput" and "puLargeInput" use multiple inheritance.  Is there a better
way?

John F. Fay
joh...@eg...



-----Original Message-----
From: pli...@li...
[mailto:pli...@li...]On Behalf Of Steve Baker
Sent: Monday, August 09, 2004 7:28 PM
To: pli...@li...
Subject: Re: [Plib-devel] On First Looking Into Baker's SSG (with
apologies to John Keats)


Fay John F Contr AAC/WMG wrote:

<snip>

> Under the heading of real issues:
> (11) How would we implement the "puValue" functionality in SSG?  Should 
> we just add it to "ssgBase" or should it remain separate?  If the 
> latter, should we use multiple inheritance in the SSG widgets?

I dislike multiple inheritance - it causes no end of problems in complex
inheritance trees - so let's not do *that*.

Do we need puValue functionality in every node?   Seems to me that it's
really only needed in leaf nodes - so I'd probably think in terms of
creating a derived class of ssgLeaf.

<snip>
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

[Plib-devel] More PLIB changes

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

Gentlemen,

	I downloaded a new tarball this morning and would like to run down
the differences between it and my personal version.

(1) The "js" library changes didn't make it in.  I asked JC to put them in
but when he tried compiling them he got an error in "jsLinuxOld.cxx".  The
line he quoted wasn't in the source that I have, and I am not sure what has
gone wrong.  The changes are the long-awaited JS rewrite that Olivier did
(last March?) and it works fine on my Windows system, but it hasn't (after
five months) gotten into CVS yet.  Really, this is a scandal!

(2) In "puAux.h" on line 813, I have the "puaChooser" widget's destructor
declared as virtual while in CVS it is not.  I'm not sure what difference it
makes in this case but merely note the difference.

(3) The SSG notes that I spoke of on Monday aren't in.  I don't really
expect them to be since I don't think we're done discussing them yet.

John F. Fay
joh...@eg...

Re: [Plib-devel] On First Looking Into Baker's SSG (with apologies to John Keats)

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

Fay John F Contr AAC/WMG wrote:

> (1) There are several places where tabs are used for indentation instead 
> of spaces. (ssg.cxx:404,405; ssg.h:357-358, 450)

Should be spaces - tabs are not portable.

> (5) In "ssg.h" starting around line 133 there is a rather complex series 
> of functions that set type data.  The PUI version is considerably more 
> efficient, but I think I remember there being a discussion about doing 
> SSG this way so as to avoid a hard limitation on 32 bits.  I would like 
> to suggest adding a comment to this effect.

The problem is that lots of SSG programs use the present system and it's
hard to fix without breaking them.  Nobody was using the PUI flags when it
was changed.

> (6) From what I gather from "ssg.cxx", we do not have writers for the 
> "dof", "md2", "strip", "mdl", or "xpl" file formats and we do not have 
> loaders for the "asc" or "pov" file formats (the latter is commented out 
> entirely).  Do we need them? Do we want them?

We want as many loaders and writers as we can get.  Few people are interested
in creating writers though because most SSG applications read data files - but
don't write them.

> (7) The file "ssgBase.cxx" has a variable "next_unique_id" that starts 
> at 1 and is incremented every time a new "ssgBase" object is created.  
> The operation used for this is a postfix "++".  I am told that a prefix 
> "++" is ever-so-slightly faster because you don't have to save the 
> return value before incrementing the variable.

I didn't know that.  Oh well, object creation is not exactly a high bandwidth
operation and compared to the memory allocation cost, it's likely to be a
VERY tiny percentage of the overall time.

>  Do we want to initialize 
> the variable to 0 (on line 27) and increment it (on line 68) with a 
> prefix "++"?

Feel free!

> (8) In the "ssgBase::print" function, do we want to print out the unique 
> ID as well?  Just asking ... and not pretending to have any knowledge in 
> the area.

That function is really just for debug...I've never felt a need to know
the unique ID.

> (9) In the "ssgList::removeAllEntities" function (ssgList.cxx:94), the 
> function removes entity 0 repeatedly until the list is empty.  This is a 
> lot like unpiling a stack of bricks by removing the bottom one each 
> time; the "removeEntity" involves a "memmove" call each time.  Why 
> doesn't the "removeAllEntities" function simply set "total" and "next" 
> to zero?  At the very least, we can speed up the "memmove" calls by 
> invoking "removeEntity" with an argument of "total-1" instead of "0".

Yes.

> (10) Do we want to implement PUI-type RTTI in the SSG functions?

We talked about it - but see my answer to (5) above.

> Under the heading of real issues:
> (11) How would we implement the "puValue" functionality in SSG?  Should 
> we just add it to "ssgBase" or should it remain separate?  If the 
> latter, should we use multiple inheritance in the SSG widgets?

I dislike multiple inheritance - it causes no end of problems in complex
inheritance trees - so let's not do *that*.

Do we need puValue functionality in every node?   Seems to me that it's
really only needed in leaf nodes - so I'd probably think in terms of
creating a derived class of ssgLeaf.

> (12) How do we handle multiple windows in SSG?  I surmise that we would 
> have a separate scene-graph tree for each window.

Yes - I think so.  SSG works well with multiple windows - so that should
be OK.

> I daresay there will be many more issues as I continue to dig.

Keep 'em coming!

---------------------------- 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] On First Looking Into Baker's SSG (with apologies to John Keats)

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

On Mon, 9 Aug 2004, Fay John F Contr AAC/WMG wrote:

> (7) The file "ssgBase.cxx" has a variable "next_unique_id" that starts at 1
> and is incremented every time a new "ssgBase" object is created.  The
> operation used for this is a postfix "++".  I am told that a prefix "++" is
> ever-so-slightly faster because you don't have to save the return value
> before incrementing the variable.  Do we want to initialize the variable to
> 0 (on line 27) and increment it (on line 68) with a prefix "++"?

I always learned that trying to save a single CPU tick is incompatible
with writing in C++ :-)

For what it's worth, any compiler worth its salt will know if the
original value will eventually be discarded and not bother so save it in
that case. I'd be tremendously surprised if either MSVC for i386 or GCC
for i386 got this wrong.

I have actually seen code breaking over such optimizations. A far better
argument for making the change is to establish a common idiom for a
project.

Cheers,

				-- Bert

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

[Plib-devel] On First Looking Into Baker's SSG (with apologies to John Keats)

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

MUCH have I travell'd in the realms of gold,  
And many goodly states and kingdoms seen;  
Round many western islands have I been  
Which bards in fealty to Apollo hold.  
Oft of one wide expanse had I been told
That deep-brow'd Homer ruled as his demesne;  
Yet did I never breathe its pure serene  
Till I heard Chapman speak out loud and bold:  
Then felt I like some watcher of the skies  
When a new planet swims into his ken;
Or like stout Cortez when with eagle eyes  
He star'd at the Pacific-and all his men  
Look'd at each other with a wild surmise-  
Silent, upon a peak in Darien. 

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

Frankly, I feel that anything I try to write after quoting the above is an
anticlimax.  But here goes.

I printed out the SSG files (except for all the loaders and writers) and
started digging through them over the weekend.  I have a few notes and
questions so far, some trivial and some not trivial.

In the realm of the trivial:
(1) There are several places where tabs are used for indentation instead of
spaces. (ssg.cxx:404,405; ssg.h:357-358, 450)
(2) The variable "sgebug" (ssg.h:43) seems not to be used anywhere.
(3) In "ssgconf.h" on line 35, the word "and" should be "an" ("to an
#undef").
(4) Also in "ssgconf.h" on lines 42-43, I think the instruction to
"un-comment the following line" should be changed to something like "change
the 'undef' on the following like to a 'define'."
(5) In "ssg.h" starting around line 133 there is a rather complex series of
functions that set type data.  The PUI version is considerably more
efficient, but I think I remember there being a discussion about doing SSG
this way so as to avoid a hard limitation on 32 bits.  I would like to
suggest adding a comment to this effect.

In the realm of the not-so-trivial:
(6) From what I gather from "ssg.cxx", we do not have writers for the "dof",
"md2", "strip", "mdl", or "xpl" file formats and we do not have loaders for
the "asc" or "pov" file formats (the latter is commented out entirely).  Do
we need them? Do we want them?
(7) The file "ssgBase.cxx" has a variable "next_unique_id" that starts at 1
and is incremented every time a new "ssgBase" object is created.  The
operation used for this is a postfix "++".  I am told that a prefix "++" is
ever-so-slightly faster because you don't have to save the return value
before incrementing the variable.  Do we want to initialize the variable to
0 (on line 27) and increment it (on line 68) with a prefix "++"?
(8) In the "ssgBase::print" function, do we want to print out the unique ID
as well?  Just asking ... and not pretending to have any knowledge in the
area.
(9) In the "ssgList::removeAllEntities" function (ssgList.cxx:94), the
function removes entity 0 repeatedly until the list is empty.  This is a lot
like unpiling a stack of bricks by removing the bottom one each time; the
"removeEntity" involves a "memmove" call each time.  Why doesn't the
"removeAllEntities" function simply set "total" and "next" to zero?  At the
very least, we can speed up the "memmove" calls by invoking "removeEntity"
with an argument of "total-1" instead of "0".
(10) Do we want to implement PUI-type RTTI in the SSG functions?

Under the heading of real issues:
(11) How would we implement the "puValue" functionality in SSG?  Should we
just add it to "ssgBase" or should it remain separate?  If the latter,
should we use multiple inheritance in the SSG widgets?
(12) How do we handle multiple windows in SSG?  I surmise that we would have
a separate scene-graph tree for each window.  I believe Steve would have
done something like that for PUI except that I put in the multiple-window
support first and didn't ask him.  This time I am asking first.

I daresay there will be many more issues as I continue to dig.

John F. Fay
joh...@eg...

RE: [Plib-devel] Tarball Problems

[Norman V. <nh...@ca...>]

Tarball ProblemsJohn,

Seems like there is something going on with my cron job
at SourceForge.

Don't know what yet but am investigating

I forced the tarball creation scripts so there should be
updated tarballs now.

Norman

  Fay John F Contr AAC/WMG  writes         Two days ago JC Jones kindly put
into CVS for me a series of small changes to "freeglut" and PLIB.  I have
just tried downloading the nightly tarball from "freeglut" and the changes
are not in it.  They are, however, in the CVS repository itself.  The same
is true for the PLIB changes, although the last time I downloaded them was
this morning.  (The CVS changes are some 42 hours old as of this writing.)
Does anybody have any ideas?
  John F. Fay

[Plib-devel] Tarball Problems

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

Gentlemen,

	Two days ago JC Jones kindly put into CVS for me a series of small
changes to "freeglut" and PLIB.  I have just tried downloading the nightly
tarball from "freeglut" and the changes are not in it.  They are, however,
in the CVS repository itself.  The same is true for the PLIB changes,
although the last time I downloaded them was this morning.  (The CVS changes
are some 42 hours old as of this writing.)  Does anybody have any ideas?

John F. Fay
joh...@eg...

Re: [Plib-devel] "ifdef" vs. "if defined"

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

Fay John F Contr AAC/WMG wrote:
> Gentlemen,
> 
>         Is there a PLIB standard for using "#ifdef" rather than "#if 
> defined" in the code?

No there is no standard.  Both work - neither is harder to understand or
more or less portable.

---------------------------- 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] "ifdef" vs. "if defined"

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

Gentlemen,

	Is there a PLIB standard for using "#ifdef" rather than "#if
defined" in the code?  The former occurs 274 times while the latter occurs
57 times.  The latter has the advantage that you can say "#if defined (x) ||
defined(y)" while I don't think the former supports that.

John F. Fay
joh...@eg...

Re: What, no eclipses? (was RE: [Plib-devel] Re: [Fwd: Plib 2.0])

[Nick M. <nic...@ds...>]

Fay John F Contr AAC/WMG wrote:

> Gentlemen,
>
>         In the interests of learning SSG, I have compiled and am 
> currently running the "Sky" SSG example program.  Quite frankly, I am 
> amazed.  Phases of the moon, stars, sunlight, clouds, wow!
>
All thanks go to the FlightGear (SimGear) project.

>         If somebody could help me by implementing a PUI widget in SSG, 
> I could try my hand at importing some others.  I would suggest that 
> the "puAux" widgets be moved over into a separate "ssgWidgets" library 
> and not be put into the core "ssg" library.
>
>         Incidentally, ...
>                 - the "Sky" example is not part of the "Examples" 
> workspace.
>
If someone could add it that would be great.   :-)

>                 - there are 33 compiler warnings under MSVC -- mostly 
> double-to-float conversions
>
hmmm ... that needs to be fixed.

>                 - I got a run-time warning about "null star data 
> passed to ssgaStars::build()".
>
Its just a warning ... it can be ignored ... eh maybe the warning should 
just be removed ... its not very useful really.

*If* I get some spare time I'll might fix these issues up.

Cheers,
Nick

[Plib-devel] Random JS test

[James 'J.C.' J. <jc...@uf...>]

I had opportunity to plug in a Saitek Cyborg USB stick this evening and
run the js_demo test with it. All 16 buttons and 6 axes work just fine.

Cheers,

--=20
 James 'J.C.' Jones - <jc...@uf...> - http://pug.ibu02.com/
  "All the passions make us commit faults; love makes us commit
   the most ridiculous ones."
    -- La Rochefoucauld

What, no eclipses? (was RE: [Plib-devel] Re: [Fwd: Plib 2.0])

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

Gentlemen,

	In the interests of learning SSG, I have compiled and am currently
running the "Sky" SSG example program.  Quite frankly, I am amazed.  Phases
of the moon, stars, sunlight, clouds, wow!

	If somebody could help me by implementing a PUI widget in SSG, I
could try my hand at importing some others.  I would suggest that the
"puAux" widgets be moved over into a separate "ssgWidgets" library and not
be put into the core "ssg" library.

	Incidentally, ...
		- the "Sky" example is not part of the "Examples" workspace.
		- there are 33 compiler warnings under MSVC -- mostly
double-to-float conversions
		- I got a run-time warning about "null star data passed to
ssgaStars::build()".

John F. Fay
joh...@eg...



-----Original Message-----
From: pli...@li...
[mailto:pli...@li...]On Behalf Of Steve Baker
Sent: Tuesday, July 13, 2004 8:34 AM
To: Erik Hofman; pli...@li...
Subject: [Plib-devel] Re: [Fwd: Plib 2.0]

<snip>

Hence, in addition to SSG shader support, there are other drastic changes
that PLIB needs:

<snip>

2) PUI is converging on SSG.

    Both API's are tree structured data with branches and leaves. Leaf nodes
    cause rendering to happen and branch nodes control behavior with state
    nodes doing stuff like colour and texture.  Collision detection and
    figuring out which button was clicked are also very similar activities.

    PUI is in dire need of state management to allow it to use texture
    and such like more cleanly.   Merging those two systems into a single
    API brings in very interesting possibilities for both API's and saves
    us a bunch of maintenance (because both could share the same state
    management and cull routines - you could even do things like building
    your GUI pages in a 3D modeller).

<snip>

Re: [Plib-devel] Indirect rendering contexts in PW

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

Fay John F Contr AAC/WMG wrote:
> The screen savers are somewhat slower (I assume they're largely 
> OpenGL-based) but the terminal windows that I use don't seem to have any 
> performance hit.

Yeah - I meant OpenGL stuff.

I don't know which screen savers you are referring to - there are a
few of the standard set that use OpenGL.

---------------------------- 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] Indirect rendering contexts in PW

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

The screen savers are somewhat slower (I assume they're largely
OpenGL-based) but the terminal windows that I use don't seem to have any
performance hit.

John F. Fay
joh...@eg...



-----Original Message-----
From: pli...@li...
[mailto:pli...@li...]On Behalf Of Steve Baker
Sent: Friday, July 30, 2004 3:58 PM
To: pli...@li...
Subject: Re: [Plib-devel] Indirect rendering contexts in PW


Fay John F Contr AAC/WMG wrote:

>         I'm not sure whether this is germane, but my new Linux box (with 
> Fedora Core 2) has two displays.  When I enable "Dual-Head" monitors, PW 
> gives me an indirect rendering context.  When I disable "Dual-Head" 
> monitors, I get a direct rendering context.  (I get identical behaviour 
> with "freeglut" as well, by the way.)  No recompilation or anything is 
> needed.

I kinda doubt there is anything we can do about that.

If you are getting a direct rendering context some of the time - then our
code is clearly requesting a direct rendering context if one is available.

When we don't get one, then something in the GLX stuff is saying that we
can't have one.  Dunno why that would be - but it's a driver issue.

Do things run more slowly in dual-head mode?

---------------------------- 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-----



-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] Indirect rendering contexts in PW

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

Fay John F Contr AAC/WMG wrote:

>         I'm not sure whether this is germane, but my new Linux box (with 
> Fedora Core 2) has two displays.  When I enable "Dual-Head" monitors, PW 
> gives me an indirect rendering context.  When I disable "Dual-Head" 
> monitors, I get a direct rendering context.  (I get identical behaviour 
> with "freeglut" as well, by the way.)  No recompilation or anything is 
> needed.

I kinda doubt there is anything we can do about that.

If you are getting a direct rendering context some of the time - then our
code is clearly requesting a direct rendering context if one is available.

When we don't get one, then something in the GLX stuff is saying that we
can't have one.  Dunno why that would be - but it's a driver issue.

Do things run more slowly in dual-head mode?

---------------------------- 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] Make Local for PLIB?

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

Wonderful!  Thank you very much.  Your instructions have worked perfectly.

John F. Fay
joh...@eg...



-----Original Message-----
From: pli...@li...
[mailto:pli...@li...]On Behalf Of Bert
Driehuis
Sent: Wednesday, July 28, 2004 7:24 PM
To: pli...@li...
Subject: Re: [Plib-devel] Make Local for PLIB?


<snip>

I do something like that, using something like this:

#!/bin/sh
[ -d ~/fgfs-install ] || mkdir ~/fgfs-install
inst_root=`cd ~/fgfs-install;pwd`
cd ~/cvs/plib	# where I check out plib
./configure --prefix=$inst_root
gmake install
cd ~/cvs/SimGear
./configure --prefix=$inst_root
gmake install
  ...

<snip>

[Plib-devel] Indirect rendering contexts in PW

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

Gentlemen,

	I'm not sure whether this is germane, but my new Linux box (with
Fedora Core 2) has two displays.  When I enable "Dual-Head" monitors, PW
gives me an indirect rendering context.  When I disable "Dual-Head"
monitors, I get a direct rendering context.  (I get identical behaviour with
"freeglut" as well, by the way.)  No recompilation or anything is needed.

John F. Fay
joh...@eg...

Re: [Plib-devel] Make Local for PLIB?

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

On Wed, 28 Jul 2004, Fay John F Contr AAC/WMG wrote:

> 	I have been trying to implement PLIB on my upgraded Linux box and
> have run into a bit of a snag.  I would like to make the PLIB libraries as a
> user (rather than as root) and keep them in a local user directory rather
> than installing them.  Would it be possible to add a "local" option to the
> Makefiles so that I could say "make local" and have all the header files and
> library files wind up in a local directory?  We do exactly that under
> Windows right now and I find it quite handy.

I do something like that, using something like this:

#!/bin/sh
[ -d ~/fgfs-install ] || mkdir ~/fgfs-install
inst_root=`cd ~/fgfs-install;pwd`
cd ~/cvs/plib	# where I check out plib
./configure --prefix=$inst_root
gmake install
cd ~/cvs/SimGear
./configure --prefix=$inst_root
gmake install
  ...

(off the top off my head, but you get the idea).

I occasionally even use a trick like this to compare the functionality
of different releases, e.g. I might do

mkdir ~/fgfs-gcc33
inst_root=`cd ~/fgfs-gcc33;pwd`
cd ~/cvs/plib   # where I check out plib
CC=gcc33 CXX=g++33 ./configure --prefix=$inst_root
 [...]

Isn't this what you want to achieve?

Cheers,

				-- bert


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

[Plib-devel] Make Local for PLIB?

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

Gentlemen,

	I have been trying to implement PLIB on my upgraded Linux box and
have run into a bit of a snag.  I would like to make the PLIB libraries as a
user (rather than as root) and keep them in a local user directory rather
than installing them.  Would it be possible to add a "local" option to the
Makefiles so that I could say "make local" and have all the header files and
library files wind up in a local directory?  We do exactly that under
Windows right now and I find it quite handy.

John F. Fay
joh...@eg...

Re: [Plib-devel] errors when compiling plib: autogen.sh problems with automake 1.8.0

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

Oliver C. wrote:

> It needed to delete all files that where generated with the auto tools.
> But the macro warnings stay. They are still there.

Changes over the last few revisions of the auto-tools make it
VERY difficult to have things build without warnings and still be
compatible with a few older versions of that software.

---------------------------- 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] errors when compiling plib: autogen.sh problems with automake 1.8.0

[Oliver C. <kre...@gm...>]

On Saturday 24 July 2004 02:10, Oliver C. wrote:
> Hello,
>
>
> i upgraded my linux distribution to Slackware 10.0 that
> ships with automake version 1.8.0 and tried to compile
> the cvs version of plib but i get the following errors after
> running ./autogen.sh
>
>
>
> ************************************************************
> $ ./autogen.sh
> Running aclocal
> /usr/share/aclocal/xmms.m4:17: warning: underquoted definition of
> XMMS_TEST_VERSION
>   run info '(automake)Extending aclocal'
>   or see
> http://sources.redhat.com/automake/automake.html#Extending%20aclocal
> /usr/share/aclocal/xmms.m4:62: warning: underquoted definition of
> AM_PATH_XMMS /usr/share/aclocal/vorbis.m4:9: warning: underquoted
> definition of XIPH_PATH_VORBIS
> /usr/share/aclocal/pkg.m4:5: warning: underquoted definition of
> PKG_CHECK_MODULES
> /usr/share/aclocal/pilot-link.m4:1: warning: underquoted definition of
> AC_PILOT_LINK_HOOK
> /usr/share/aclocal/ogg.m4:8: warning: underquoted definition of
> XIPH_PATH_OGG /usr/share/aclocal/nspr.m4:8: warning: underquoted definition
> of AM_PATH_NSPR /usr/share/aclocal/libmikmod.m4:11: warning: underquoted
> definition of AM_PATH_LIBMIKMOD
> /usr/share/aclocal/libOggFLAC.m4:7: warning: underquoted definition of
> AM_PATH_LIBOGGFLAC
> /usr/share/aclocal/libOggFLAC++.m4:8: warning: underquoted definition of
> AM_PATH_LIBOGGFLACPP
> /usr/share/aclocal/libIDL.m4:6: warning: underquoted definition of
> AM_PATH_LIBIDL
> /usr/share/aclocal/libFLAC.m4:7: warning: underquoted definition of
> AM_PATH_LIBFLAC
> /usr/share/aclocal/libFLAC++.m4:8: warning: underquoted definition of
> AM_PATH_LIBFLACPP
> /usr/share/aclocal/imlib.m4:9: warning: underquoted definition of
> AM_PATH_IMLIB
> /usr/share/aclocal/imlib.m4:167: warning: underquoted definition of
> AM_PATH_GDK_IMLIB
> /usr/share/aclocal/gtk.m4:7: warning: underquoted definition of AM_PATH_GTK
> /usr/share/aclocal/gnet-2.0.m4:8: warning: underquoted definition of
> AM_PATH_GNET_2_0
> /usr/share/aclocal/glib.m4:8: warning: underquoted definition of
> AM_PATH_GLIB /usr/share/aclocal/gimpprint.m4:8: warning: underquoted
> definition of AM_PATH_GIMPPRINT
> /usr/share/aclocal/gdk-pixbuf.m4:12: warning: underquoted definition of
> AM_PATH_GDK_PIXBUF
> /usr/share/aclocal/audiofile.m4:12: warning: underquoted definition of
> AM_PATH_AUDIOFILE
> /usr/share/aclocal/ao.m4:9: warning: underquoted definition of XIPH_PATH_AO
> /usr/share/aclocal/ac_find_motif.m4:21: warning: underquoted definition of
> AC_FIND_MOTIF
> /usr/share/aclocal/ac_find_motif.m4:223: warning: underquoted definition of
> AC_FIND_LIBXP
> /usr/share/aclocal/aalib.m4:12: warning: underquoted definition of
> AM_PATH_AALIB
> /usr/share/aclocal/ORBit.m4:4: warning: underquoted definition of
> AM_PATH_ORBIT
> Can't locate object method "path" via package "Request"
> at /usr/share/autoconf/Autom4te/C4che.pm line 69, <GEN1> line 94.
> aclocal: autom4te failed with exit status: 1
> Running automake
> Can't locate object method "path" via package "Request"
> at /usr/share/autoconf/Autom4te/C4che.pm line 69, <GEN1> line 94.
> automake: autoconf failed with exit status: 1
> Running autoconf
> Can't locate object method "path" via package "Request"
> at /usr/share/autoconf/Autom4te/C4che.pm line 69, <GEN1> line 94.
> ======================================
> Now you are ready to run './configure'
> ======================================
> $./configure
> configure: error: cannot find install-sh or install.sh in . ./.. ./../..
> $
> ************************************************************
>

Ok, now plib compiles.
It needed to delete all files that where generated with the auto tools.
But the macro warnings stay. They are still there.


Best Regards,
 Oliver C.