Re: [Flightgear-devel] Big Nasal Changes

2005-05-06 Thread Martin Spott
Andy Ross wrote:

 More practically, this site seems to have good info, albeit not always
 complete:
 
   http://predef.sourceforge.net/

Good enough for me  ;-)

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

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Big Nasal Changes

2005-05-05 Thread Martin Spott
Andy Ross wrote:

 - #elif defined( _MSC_VER ) || defined(__MINGW32__)
 + #elif defined( _MSC_VER ) || defined(__MINGW32__) || defined(__solaris__)

Can anyone give me a hint on how to determine the defines that are
set by the compiler itself ?

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

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Big Nasal Changes

2005-05-05 Thread Andy Ross
Martin Spott wrote:
 Can anyone give me a hint on how to determine the defines that are
 set by the compiler itself ?

With a gcc variant, you can do something like:

   echo | gcc -E -dM -

This is kinda fun, you can watch how the built-in defines changes as
you vary the optimization switches and language (g++/gcc).

More practically, this site seems to have good info, albeit not always
complete:

  http://predef.sourceforge.net/

Andy

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Big Nasal Changes

2005-04-21 Thread Jim Wilson
 From: Curtis L. Olson

  Frederic Bouvier wrote:
  
 I am not here to endorse Microsoft choices, but I see little point to use C
 syntax when C++ is available and is the language of choice for the overall
 FlightGear project. However, the link below should clarify Microsoft point of
 view :
 
 http://www.dotnet247.com/247reference/msgs/56/280444.aspx
 
snip
 
 Sounds like Microsoft is just trying to be customer oriented...
 

Ah...you mean cu$tomer oriented, right?  The closed source democracy: majority 
rules, money talks. :-)

Best regards,

Jim



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Big Nasal Changes

2005-04-20 Thread Vivian Meazza
Andy Ross wrote

 
 Vivian Meazza wrote:
  It won't compile under Cygwin using gcc either. Fails with:
 
  NasalSys.cxx:292: error: invalid conversion from `naRef (*)(Context*,
 naRef,
 int, naRef*)' to `naRef (*)(Context*, naRef)'
 
 You forgot to update your SimGear, or have an old one still
 installed somewhere.  The API for extensions has changed with
 this version, and your compilation is picking up the older
 version of nasal.h.
 

Quite right - I hadn't rebuilt SimGear correctly, and the compilation was
still picking up the older version of nasal.h.

I also had a few local difficulties in FlightGear, but all fixed, and
everything compiles correctly

Thanks for your help.

Vivian



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Big Nasal Changes

2005-04-20 Thread Erik Hofman
Andy Ross wrote:
Basically: please be constructive.  Singing about SGI's wonderful Unix
or flaming GCC for failing to warn about correct (!) code isn't
improving Nasal or FlightGear.
Excuse me? You started accusing other compilers about not being standard 
compliant and now I am the one who started this?

Here is a small subset from the IRIX man pages for MIPSpro:
The following list summarizes some of the major differences between
the GNU cc compiler and the MIPSpro C compiler.  The wording gcc
allows or g++ allows in the following paragraphs indicates that the
GNU compiler is providing more flexible constructs beyond what is
allowed in the standard.  The MIPSpro compilers adhere more closely to
standards requirements.
 * The gcc compiler allows variadic macros; the MIPSpro 7.4 compilers
   support these macros in c99 mode.  If you have code that uses
   ellipses (...) as part of a macro definition and you are not
   compiling with c99, you will need to rewrite the macro. Two possible
   approaches are to replace the macro with a new variadic function, or
   to create a family of macros, each taking different (fixed) numbers
   of arguments.
 * gcc allows the non-standard __FUNCTION__ and __PRETTY_FUNCTION__
   pseudo-macros.  These are not true macros, so you must use _GNUC__
   to test for them. As of IRIX 6.5.18, the c99 func macro is
   available, which expands to a function name.
 * By default gcc allows C++ style double slash (//) comments in C
   code.  To obtain this behavior with the MIPSpro C compilers you must
   specify the -Xcpluscomm command line option or use c99, which
   defines a double slash (//) to be a comment.
But leave it at this, it might be better to spent our time hunting 
problems like this one:

When I start FlightGear I get the following list of errors on IRIX 
(bug-Endian) (Linux doesn't have this problem):

Nasal runtime error: non-objects have no members
  at /opt/share/FlightGear/data/Nasal/view.nas, line 24
Nasal runtime error: non-objects have no members
  at /opt/share/FlightGear/data/Nasal/gui.nas, line 40
Nasal runtime error: non-objects have no members
  at /opt/share/FlightGear/data/Nasal/autopilot.nas, line 29
Nasal runtime error: non-objects have no members
  at /opt/share/FlightGear/data/Nasal/controls.nas, line 17
Nasal runtime error: non-objects have no members
  at /opt/share/FlightGear/data/Nasal/fuel.nas, line 17
After that, every key I press generates this error:
Nasal runtime error: no such member
  at command, line 1
Failed to execute command nasal
Do you have any clue where to search for this?
Erik

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Big Nasal Changes

2005-04-20 Thread Andy Ross
Erik Hofman wrote:
 When I start FlightGear I get the following list of errors on IRIX
 (big-Endian) (Linux doesn't have this problem):

This looks like the GC is cleaning up objects incorrectly.  On the
assumption that this is an endianness issue: Is this for a 32 or 64
bit target (Nasal has three structure layouts* for the naRef -- both
endiannesses for 32 bit and just one layout for 64 bit)?

Can you verify that nothing has broken with the endian detection stuff
at the top of nasal.h (building for the wrong layout will mostly
work but might produce issues like this), maybe by just deleting
everything that isn't part of a NASAL_BIG_ENDIAN_32_BIT block?

Can anyone else on a big endian system (Mac, Sparc) see the same or
similar problem?

Oddly, the structure layout stuff has not changed in this version, so
I'm out of ideas as to what might have happened.  I'll see if I can
find a BE system at work (we have a few old suns running linux) to
test on.

Andy

* At some point I'll start using my laptop in 64 bit mode full time
  and work more on the 64 bit version; right now it stores 12 bytes
  per naRef, but it could be shrunk down to 8 by unioning the pointer
  and the double by setting the NaN bits of the pointer.


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Big Nasal Changes

2005-04-20 Thread Martin Spott
Andy Ross wrote:

 Can anyone else on a big endian system (Mac, Sparc) see the same or
 similar problem?

I would do if I could - I'm still busy with digging through Port me!
Platforms that don't have stdint.h  errors in
src/FDM/ExternalNet/ on Solaris,

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

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Big Nasal Changes

2005-04-20 Thread Andy Ross
Martin Spott wrote:
 Andy Ross wrote:
  Can anyone else on a big endian system (Mac, Sparc) see the same
  or a similar problem?

 I would do if I could - I'm still busy with digging through Port
 me!  Platforms that don't have stdint.h  errors in
 src/FDM/ExternalNet/ on Solaris,

The typedefs in net_crtls.hxx should be correct for Sparc32 too.  Have
you tried something like this in src/Network/net_ctrls.hxx:

- #elif defined( _MSC_VER ) || defined(__MINGW32__)
+ #elif defined( _MSC_VER ) || defined(__MINGW32__) || defined(__solaris__)

You will also need to add the following above that test to make sure
the (windows-specific) __int64 type is defined (someone correct me if
I'm wrong: long long exists and is 64 bits wide on both sparc32 and
sparc64, right?)

#ifdef __solaris__
typedef long long __int64
#endif

Andy

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Big Nasal Changes

2005-04-20 Thread Erik Hofman
Andy Ross wrote:
Erik Hofman wrote:
When I start FlightGear I get the following list of errors on IRIX
(big-Endian) (Linux doesn't have this problem):
This looks like the GC is cleaning up objects incorrectly.  On the
assumption that this is an endianness issue: Is this for a 32 or 64
bit target (Nasal has three structure layouts* for the naRef -- both
endiannesses for 32 bit and just one layout for 64 bit)?
Ah, yes now I remember. It's for 32-bit big-endian.
Can you verify that nothing has broken with the endian detection stuff
at the top of nasal.h (building for the wrong layout will mostly
work but might produce issues like this), maybe by just deleting
everything that isn't part of a NASAL_BIG_ENDIAN_32_BIT block?
This seems to work correctly, it detects it has to define 
NASAL_BIG_ENDIAN_32_BIT

Oddly, the structure layout stuff has not changed in this version, so
I'm out of ideas as to what might have happened.  I'll see if I can
find a BE system at work (we have a few old suns running linux) to
test on.
It's getting late here so I won't do any testing today but I'll start to 
look at it tomorrow morning again.

Erik
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Big Nasal Changes

2005-04-19 Thread Frederic Bouvier
Selon Andy Ross [EMAIL PROTECTED]:

 I wrote:
  4. I have a warning on a non standard extension used on
  naRef array[];
 
  This one is new, but I honestly thought it was a standard C89 feature.
  Can you post the warning?  Or is there a #pragma I can use to turn it
  off?

 I just looked it up.  This one is actually a C99 feature, not C89.  If
 MSVC (or the SGI or Sun compilers) doesn't support it, I can use a
 slightly more complicated variant by declaring it as an array of one
 member and diddling the allocation math.

 I strongly suspect that it does work, though, since your compiler
 called it a non-standard* extension and not a parse error.  In which
 case it ought to be sufficient to find the #pragma that disables the
 warning.

 * Which is silly, because what is ISO C99 if not a standard? :)

This is only a warning. Maybe I am too strict on the warning level. But this is
the least of the problem.

-Fred

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Big Nasal Changes

2005-04-19 Thread Frederic Bouvier
Selon Andy Ross:
 Please try again, this time in C, and let me know the error you are
 seeing.  I strongly suspect you've been fooled by a much simpler
 issue.

OK, I backed out all my changes and restart the compilation. I found where it is
not C : you don't always declare local variables at the beginning of functions
but you have the C++ habit to declare them as you need them. So the change
below are needed and they are much simpler than yesterday evening ;-) With them
the compilation is seamless and the warning on empty arrays disappeared as other
C++ oddness ;-) Then change in GC_HEADER is required though.

cvs -z4 -q diff -u code.c data.h lib.c misc.c (in directory
I:\FlightGear\cvs\SimGear\simgear\nasal\)
Index: code.c
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/nasal/code.c,v
retrieving revision 1.8
diff -u -r1.8 code.c
--- code.c  18 Apr 2005 19:48:47 -  1.8
+++ code.c  19 Apr 2005 06:18:24 -
@@ -107,13 +107,14 @@

 static void initGlobals()
 {
+int i;
+struct Context* c;
 globals = (struct Globals*)naAlloc(sizeof(struct Globals));
 naBZero(globals, sizeof(struct Globals));

 globals-sem = naNewSem();
 globals-lock = naNewLock();

-int i;
 globals-allocCount = 256; // reasonable starting value
 for(i=0; iNUM_NASAL_TYPES; i++)
 naGC_init((globals-pools[i]), i);
@@ -124,7 +125,7 @@
 // Initialize a single context
 globals-freeContexts = 0;
 globals-allContexts = 0;
-struct Context* c = naNewContext();
+c = naNewContext();

 globals-symbols = naNewHash(c);
 globals-save = naNewVector(c);
@@ -140,11 +141,12 @@
 struct Context* naNewContext()
 {
 int dummy;
+struct Context* c;
 if(globals == 0)
 initGlobals();

 LOCK();
-struct Context* c = globals-freeContexts;
+c = globals-freeContexts;
 if(c) {
 globals-freeContexts = c-nextFree;
 c-nextFree = 0;
Index: data.h
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/nasal/data.h,v
retrieving revision 1.3
diff -u -r1.3 data.h
--- data.h  18 Apr 2005 19:48:47 -  1.3
+++ data.h  19 Apr 2005 06:10:30 -
@@ -33,7 +33,7 @@
 // implementing objects to pack in 16 bits worth of data for free.
 #define GC_HEADER \
 unsigned char mark; \
-unsigned char type; \
+unsigned char type

 struct naObj {
 GC_HEADER;
Index: lib.c
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/nasal/lib.c,v
retrieving revision 1.6
diff -u -r1.6 lib.c
--- lib.c   18 Apr 2005 19:48:47 -  1.6
+++ lib.c   19 Apr 2005 06:17:09 -
@@ -49,8 +49,9 @@

 static naRef setsize(naContext c, naRef me, int argc, naRef* args)
 {
+int sz;
 if(argc  2) return naNil();
-int sz = (int)naNumValue(args[1]).num;
+sz = (int)naNumValue(args[1]).num;
 if(!naIsVector(args[0])) return naNil();
 naVec_setsize(args[0], sz);
 return args[0];
Index: misc.c
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/nasal/misc.c,v
retrieving revision 1.4
diff -u -r1.4 misc.c
--- misc.c  18 Apr 2005 19:48:47 -  1.4
+++ misc.c  19 Apr 2005 06:17:09 -
@@ -49,10 +49,11 @@

 naRef naNew(struct Context* c, int type)
 {
+naRef result;
 if(c-nfree[type] == 0)
 c-free[type] = naGC_get(globals-pools[type],
  OBJ_CACHE_SZ, c-nfree[type]);
-naRef result = naObj(type, c-free[type][--c-nfree[type]]);
+result = naObj(type, c-free[type][--c-nfree[type]]);
 naVec_append(c-temps, result);
 return result;
 }

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Big Nasal Changes

2005-04-19 Thread Erik Hofman
Frederic Bouvier schreef:
OK, I backed out all my changes and restart the compilation. I found where it is
not C : you don't always declare local variables at the beginning of functions
but you have the C++ habit to declare them as you need them. So the change
below are needed and they are much simpler than yesterday evening ;-) With them
the compilation is seamless and the warning on empty arrays disappeared as other
C++ oddness ;-) Then change in GC_HEADER is required though.
The same problem happened for MIPSpro. Since I have a bulk of patches to 
wade through I have committed this one to get a clean CVS tree.

Erik
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Big Nasal Changes

2005-04-19 Thread Andy Ross
Frederic Bouvier wrote:
 I found where it is not C : you don't always declare local
 variables at the beginning of functions but you have the C++
 habit to declare them as you need them.

... which is a well-established feature of the (now 6-year-old!)
C99 standard.  It's not a C++ thing.  And GCC stopped warning
about this (in C mode, under -Wall) several years ago.  You need
to engage -ansi and disable --std=c99 to see stuff like this.

Erik Hofman wrote:
 The same problem happened for MIPSpro.

Sigh.  I guess six years isn't enough for SGI and Microsoft.  Has
anyone had a chance to try the Sun compiler, which (I think) is
the only other one we use.

Andy

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Big Nasal Changes

2005-04-19 Thread Martin Spott
Andy Ross wrote:

 Sigh.  I guess six years isn't enough for SGI and Microsoft.  Has
 anyone had a chance to try the Sun compiler, which (I think) is
 the only other one we use.

I use GCC-3.4.2 on Sun because I didn't manage to get a different one,

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

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Big Nasal Changes

2005-04-19 Thread Frederic Bouvier
Selon Andy Ross:

 Frederic Bouvier wrote:
  I found where it is not C : you don't always declare local
  variables at the beginning of functions but you have the C++
  habit to declare them as you need them.

 ... which is a well-established feature of the (now 6-year-old!)
 C99 standard.  It's not a C++ thing.  And GCC stopped warning
 about this (in C mode, under -Wall) several years ago.  You need
 to engage -ansi and disable --std=c99 to see stuff like this.

I am not here to endorse Microsoft choices, but I see little point to use C
syntax when C++ is available and is the language of choice for the overall
FlightGear project. However, the link below should clarify Microsoft point of
view :

http://www.dotnet247.com/247reference/msgs/56/280444.aspx

Not speaking about the fact that a lot of people are still using the v6 version
that was released in 1998.

Thanks for committing the patch.

-Fred

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Big Nasal Changes

2005-04-19 Thread Curtis L. Olson
Frederic Bouvier wrote:
I am not here to endorse Microsoft choices, but I see little point to use C
syntax when C++ is available and is the language of choice for the overall
FlightGear project. However, the link below should clarify Microsoft point of
view :
http://www.dotnet247.com/247reference/msgs/56/280444.aspx
Not speaking about the fact that a lot of people are still using the v6 version
that was released in 1998.
Thanks for committing the patch.
 

Sounds like Microsoft is just trying to be customer oriented...
Curt.
--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Big Nasal Changes

2005-04-19 Thread Terry Reinert




I am still using VC++ 6.0 from 98 myself. I have been thinking of
upgrading to either 2003 or 2005 but hesitant to do so until I find out
whether I can still code the same way as I do now in those
environments. I did some reading on the MS website last night and it
seemed to imply that I do not need to program in .NET or the other
fancy stuff they implimented but being Microsoft I am leary to
believe them. 

So, anyone out there with VC++ 2003 that could shed some light on this?
Will the programs I use now still compile without any modifications
under the 2003 / 2005 IDE? 

Frederic Bouvier wrote:

  Selon Andy Ross:

  
  
Frederic Bouvier wrote:


  I found where it is not C : you don't always declare local
variables at the beginning of functions but you have the C++
habit to declare them as you need them.
  

... which is a well-established feature of the (now 6-year-old!)
C99 standard.  It's not a "C++" thing.  And GCC stopped warning
about this (in C mode, under -Wall) several years ago.  You need
to engage -ansi and disable --std=c99 to see stuff like this.

  
  
I am not here to endorse Microsoft choices, but I see little point to use C
syntax when C++ is available and is the language of choice for the overall
FlightGear project. However, the link below should clarify Microsoft point of
view :

http://www.dotnet247.com/247reference/msgs/56/280444.aspx

Not speaking about the fact that a lot of people are still using the v6 version
that was released in 1998.

Thanks for committing the patch.

-Fred

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

  



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Big Nasal Changes

2005-04-19 Thread Frederic Bouvier
Selon Terry Reinert:

 I am still using VC++ 6.0 from 98 myself. I have been thinking of
 upgrading to either 2003 or 2005 but hesitant to do so until I find out
 whether I can still code the same way as I do now in those environments.
 I did some reading on the MS website last night and it seemed to imply
 that I do not need to program in .NET or the other fancy stuff they
 implimented but being Microsoft I am leary to believe them.

 So, anyone out there with VC++ 2003 that could shed some light on this?
 Will the programs I use now still compile without any modifications
 under the 2003 / 2005 IDE?

You still can do traditional C++ with VC++ 7.1 aka .NET 2003. This is called
unmanaged code in Microsoft terminology. This version is a lot more compliant
to standards C++ wise, but C seems to be locked on ansi with additionnal
features that are borrowed to newer specs.

If you use C++ templates, you should prefer the last version because VC6 is
notoriously buggy in that area.

I tried beta 1 of VC++ 2005. I managed to compile FG but the runtime was not
happy with / as path separators so FG crashed very early. Beta 2 is out and
available for download but I don't had a chance to try it yet.

-Fred

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Big Nasal Changes

2005-04-19 Thread Erik Hofman
Andy Ross wrote:
Erik Hofman wrote:
The same problem happened for MIPSpro.

Sigh.  I guess six years isn't enough for SGI and Microsoft.  Has
anyone had a chance to try the Sun compiler, which (I think) is
the only other one we use.
It is, in fact MIPSpro supported c99 before gcc did, but you need a 
compiler option to enable it which is the only valid way to enable it. 
Just face it, gcc behaved bad (again).

Erik
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Big Nasal Changes

2005-04-19 Thread Andy Ross
Erik Hofman wrote:
 It is, in fact MIPSpro supported c99 before gcc did, but you need a
 compiler option to enable it which is the only valid way to enable
 it.  Just face it, gcc behaved bad (again).

I don't follow the logic.  If that were the true, then the only
valid result of running a C compiler would be a pre-struct KR
thing, no? :)

You don't bother to turn on a switch to enable structs or function
prototypes, you just expect them to be there.  Similarly you didn't
need to to enable other non-C89 features like // comments or the
empty array declaration.  So why isn't MIPSpro behaving badly in
*exactly* the same way by supporting these things without requiring a
command line extension?

I can fix the code to match compiler limitations.  But I'm at a loss for
why you think it is somehow GCC's fault for generating correct output
for correct source code by default...

Andy



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Big Nasal Changes

2005-04-19 Thread Vandewalle, David E



For what this is worth:

For work, I build flightgear with some custom modsusing 2003 
.NET
It builds with pretty much zero code changes. 
I dohave to munge around with the project files and add a bunch of 
include paths, lib paths, lib refs,etc. to get a clean 
build.

However, the interesting part of 2003 .NET is the debugger. I have 
nothing but problems with it. It is just plain not as stable as the VC6 
debugger. Constant crashes with large applications like FlightGear. 
I've been told that this is a install specific thing and that our messed up 
workstation config is the cause (our network IS/mgmt people are quite 
inept.) Other people tell me "no, it just sucks like that for any 
install." So I'm not sure where the truth lies. Probably somewhere in the 
middle. Many people in our company that are forced to do windows 
development refuse to upgrade to 2003 .NET even though the development 
environment is nicer than VC6.

Hope this helps you at least somewhat.


  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Terry 
  ReinertSent: Tuesday, April 19, 2005 8:25 AMTo: 
  FlightGear developers discussionsSubject: Re: [Flightgear-devel] 
  Big Nasal Changes
  I am still using VC++ 6.0 from 98 myself. I have been thinking of 
  upgrading to either 2003 or 2005 but hesitant to do so until I find out 
  whether I can still code the same way as I do now in those environments. I did 
  some reading on the MS website last night and it seemed to imply that I do not 
  need to program in .NET or the other fancy stuff they implimented but being 
  Microsoft I am leary to believe them. So, anyone out there with 
  VC++ 2003 that could shed some light on this? Will the programs I use now 
  still compile without any modifications under the 2003 / 2005 IDE? 
  Frederic Bouvier wrote: 
  Selon Andy Ross:

  
Frederic Bouvier wrote:

  I found where it is not C : you don't always declare local
variables at the beginning of functions but you have the C++
habit to declare them as you need them.
  ... which is a well-established feature of the (now 6-year-old!)
C99 standard.  It's not a "C++" thing.  And GCC stopped warning
about this (in C mode, under -Wall) several years ago.  You need
to engage -ansi and disable --std=c99 to see stuff like this.

I am not here to endorse Microsoft choices, but I see little point to use C
syntax when C++ is available and is the language of choice for the overall
FlightGear project. However, the link below should clarify Microsoft point of
view :

http://www.dotnet247.com/247reference/msgs/56/280444.aspx

Not speaking about the fact that a lot of people are still using the v6 version
that was released in 1998.

Thanks for committing the patch.

-Fred

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

  
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Big Nasal Changes

2005-04-19 Thread Erik Hofman
Andy Ross wrote:
I don't follow the logic.  If that were the true, then the only
valid result of running a C compiler would be a pre-struct KR
thing, no? :)
You don't bother to turn on a switch to enable structs or function
prototypes, you just expect them to be there.  Similarly you didn't
need to to enable other non-C89 features like // comments or the
empty array declaration.  So why isn't MIPSpro behaving badly in
*exactly* the same way by supporting these things without requiring a
command line extension?
I can fix the code to match compiler limitations.  But I'm at a loss for
why you think it is somehow GCC's fault for generating correct output
for correct source code by default...
It's quite simple, SGI has the zero warning compiling philosophy; No 
build will be shipped if it generates a warning. It has gained them the 
reputation of being one of the most stable UNIX variants available.

Now, c89 and c99 are incompatible in that way, you can't compile c89 
code without warnings on a c99 compiler, or visa versa.

Erik
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Big Nasal Changes

2005-04-19 Thread Andy Ross
Erik Hofman wrote:
 It's quite simple, SGI has the zero warning compiling philosophy; No
 build will be shipped if it generates a warning. It has gained them
 the reputation of being one of the most stable UNIX variants
 available.

Now I'm even more confused.  What warning are you talking about?  The
one that the SGI compiler does not generate for // comments?  The
one that gcc does not generate for inline variable declarations?  The
one that the MSVC compiler generates for empty array members in a
struct?

If you want me to fix a warning condition in Nasal, I'm happy to.
Just point me to where.  If you want the GCC people to add a warning,
please be more specific (and maybe consider posting to a more
appropriate forum).  If you actually think the SGI compiler catches
all possible errors with its magical warning-fu, then I have a bridge
to sell you. :)

Seriously, Erik.  Think more about the problem.  There are no easy
answers here; I think you've misunderstood* something.

* Example: You seem to think that an inline declaration is a bad
  thing, and worth warning about.  But you seem to be fine with
  comments that begin with //, a non-C89 feature about which the SGI
  compiler is silent.  Both are useful features, part of C99, and
  worth supporting, so why does your opinion of the two differ?  My
  guess is it's only because your favorite compiler writers toss a
  warning for one and not the other. :)

Basically: please be constructive.  Singing about SGI's wonderful Unix
or flaming GCC for failing to warn about correct (!) code isn't
improving Nasal or FlightGear.

Andy

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Big Nasal Changes

2005-04-19 Thread Frederic Bouvier
Andy Ross wrote :
Erik Hofman wrote:
 

It's quite simple, SGI has the zero warning compiling philosophy; No
build will be shipped if it generates a warning. It has gained them
the reputation of being one of the most stable UNIX variants
available.
   

Now I'm even more confused.  What warning are you talking about?  The
one that the SGI compiler does not generate for // comments?  The
one that gcc does not generate for inline variable declarations?  The
one that the MSVC compiler generates for empty array members in a
struct?
 

Just a precision and I will stop here : MSVC is not emitting a warning 
on empty (no size, [] ) array members in C mode, just in C++ mode. The 
problem with MSVC is the same than with MIPSpro : inline variable 
definition in C mode and this is an error for it. The other problem I 
had with recent Nasal code was that a construct like this :

struct naObj {
   unsigned char mark;
   unsigned char type;
   ;
};
with an empty member ( double ; ) induced by the use of the macro 
GC_HEADER produce a syntax error. I am not arguing here that MSVC is 
free of bugs but we have to cope with them, and the situation with VC 
7.1 is much better than with older VC 6.

FYI, I also have this kind of warnings :
simgear\nasal\string.c(200) : warning C4244: 'function' : conversion 
from 'double' to 'int', possible loss of data
simgear\nasal\string.c(261) : warning C4244: 'function' : conversion 
from 'double' to 'int', possible loss of data

and :
simgear\nasal\hash.c(37) : warning C4018: '' : signed/unsigned mismatch
simgear\nasal\hash.c(71) : warning C4018: '' : signed/unsigned mismatch
simgear\nasal\hash.c(176) : warning C4018: '' : signed/unsigned mismatch
simgear\nasal\hash.c(203) : warning C4018: '' : signed/unsigned mismatch
I can live with these warning, and they are a bunch in other sections of 
FG code.

-Fred

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Big Nasal Changes

2005-04-19 Thread Vivian Meazza
Andy Ross wrote:

 
 Frederic Bouvier wrote:
  2. MSVC use file extensions to choose the right language to
  compile. So in misc.c the syntax of C not C++ apply. This file
  should definitively be named misc.cxx, like lib.c should be lib.cxx.
 
 Definitely not.  I promise you that it's a C file.  The only C99
 feature that gets used is the // comment convention.  None of this has
 changed from the last version, either, and several FlightGear releases
 have been made against the MSVC compiler.  Are you sure you aren't
 over-diagnosing a simpler error by switching to C++ mode?
 
  3. the word 'namespace' is used as a name of a struct member in
  naFunc in data.h. 'namespace' is definitively reserved keyword in
  C++.
 
 Yet more evidence that this is not, in fact, C++ code. :)
 
  4. I have a warning on a non standard extension used on
 naRef array[];
 
 This one is new, but I honestly thought it was a standard C89 feature.
 Can you post the warning?  Or is there a #pragma I can use to turn it
 off?
 
  5. 'delete' is a reserved keyword in C++ ( in lib.c that needs to be
  compiled with the C++ language )
 
 OK, get this out of your head now.  It's not C++, it doesn't compile
 with a C++ compiler, and it never has. :)
 
  6. can't convert void * to char * without a cast.
 
 Hrm... now that I thought definitely *was* part of the C89 standard,
 otherwise every malloc() invocation needs its own cast.  Are you sure
 this isn't yet another C++ side effect?
 
 Please try again, this time in C, and let me know the error you are
 seeing.  I strongly suspect you've been fooled by a much simpler
 issue.
 

It won't compile under Cygwin using gcc either. Fails with:

NasalSys.cxx:292: error: invalid conversion from `naRef (*)(Context*, naRef,
   int, naRef*)' to `naRef (*)(Context*, naRef)'

I'm afraid that with my limited knowledge I don't think I can offer a
tentative solution.

Regards,

Vivian 





___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Big Nasal Changes

2005-04-19 Thread Andy Ross
Vivian Meazza wrote:
 It won't compile under Cygwin using gcc either. Fails with:

 NasalSys.cxx:292: error: invalid conversion from `naRef (*)(Context*, naRef,
int, naRef*)' to `naRef (*)(Context*, naRef)'

You forgot to update your SimGear, or have an old one still
installed somewhere.  The API for extensions has changed with
this version, and your compilation is picking up the older
version of nasal.h.

Andy

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Big Nasal Changes

2005-04-18 Thread Andy Ross
I wrote:
 Here's a quick overview of the changes (or at least all of the ones
 I can remember at the moment):

Yup, forgot one:

The C syntax for conditional expressions (A ? B : C) now works in
Nasal like you expect.  This is 100% identical to writing
if(A){B}else{C}, and I had originally planned not to include it.  But
honestly, it's just more readable in many cases.

Andy



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Big Nasal Changes

2005-04-18 Thread Frederic Bouvier
Andy Ross a écrit :
Scream really loudly if something breaks and you want this patch reverted.
 

I don't really want to see this patch reverted, but here is my first 
experience with MSVC.

1. empty struct member ( ;; ) seems to be disallowed. So I changed :
--- data.h18 Apr 2005 19:48:47 -1.3
+++ data.h18 Apr 2005 21:20:58 -
@@ -33,7 +33,7 @@
// implementing objects to pack in 16 bits worth of data for free.
#define GC_HEADER \
unsigned char mark; \
-unsigned char type; \
+unsigned char type
struct naObj {
GC_HEADER;
to avoid that.
2. MSVC use file extensions to choose the right language to compile. So 
in misc.c the syntax of C not C++ apply. This file should definitively 
be named misc.cxx, like lib.c should be lib.cxx. In C, MSVC doesn't 
seems to like union assignment, but I may be wrong. It's ok in C++, but 
there is a lot of subsequent problems induced by this change of 
language. See below :

3. the word 'namespace' is used as a name of a struct member in naFunc 
in data.h. 'namespace' is definitively reserved keyword in C++.

4. I have a warning on a non standard extension used on
 naRef array[];
( empty array in struct )
5. 'delete' is a reserved keyword in C++ ( in lib.c that needs to be 
compiled with the C++ language )

6. can't convert void * to char * without a cast.
--- lib.c18 Apr 2005 19:48:47 -1.6
+++ lib.c18 Apr 2005 21:42:18 -
@@ -219,7 +219,7 @@
va_list va;
int len = 16;
while(1) {
-buf = naAlloc(len);
+buf = (char *)naAlloc(len);
va_start(va, f);
if(vsnprintf(buf, len, f, va)  len) {
va_end(va);
and it's late here so I can't continue but there is a lot of other 
messages ( I have the french version of MSVC so the error messages are 
in french )

-Fred

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Big Nasal Changes

2005-04-18 Thread Andy Ross
Frederic Bouvier wrote:
 2. MSVC use file extensions to choose the right language to
 compile. So in misc.c the syntax of C not C++ apply. This file
 should definitively be named misc.cxx, like lib.c should be lib.cxx.

Definitely not.  I promise you that it's a C file.  The only C99
feature that gets used is the // comment convention.  None of this has
changed from the last version, either, and several FlightGear releases
have been made against the MSVC compiler.  Are you sure you aren't
over-diagnosing a simpler error by switching to C++ mode?

 3. the word 'namespace' is used as a name of a struct member in
 naFunc in data.h. 'namespace' is definitively reserved keyword in
 C++.

Yet more evidence that this is not, in fact, C++ code. :)

 4. I have a warning on a non standard extension used on
naRef array[];

This one is new, but I honestly thought it was a standard C89 feature.
Can you post the warning?  Or is there a #pragma I can use to turn it
off?

 5. 'delete' is a reserved keyword in C++ ( in lib.c that needs to be
 compiled with the C++ language )

OK, get this out of your head now.  It's not C++, it doesn't compile
with a C++ compiler, and it never has. :)

 6. can't convert void * to char * without a cast.

Hrm... now that I thought definitely *was* part of the C89 standard,
otherwise every malloc() invocation needs its own cast.  Are you sure
this isn't yet another C++ side effect?

Please try again, this time in C, and let me know the error you are
seeing.  I strongly suspect you've been fooled by a much simpler
issue.

Andy

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Big Nasal Changes

2005-04-18 Thread Andy Ross
I wrote:
 4. I have a warning on a non standard extension used on
 naRef array[];

 This one is new, but I honestly thought it was a standard C89 feature.
 Can you post the warning?  Or is there a #pragma I can use to turn it
 off?

I just looked it up.  This one is actually a C99 feature, not C89.  If
MSVC (or the SGI or Sun compilers) doesn't support it, I can use a
slightly more complicated variant by declaring it as an array of one
member and diddling the allocation math.

I strongly suspect that it does work, though, since your compiler
called it a non-standard* extension and not a parse error.  In which
case it ought to be sufficient to find the #pragma that disables the
warning.

* Which is silly, because what is ISO C99 if not a standard? :)

Andy

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d