On Sunday 26 February 2006 09:23, Melchior FRANZ wrote:
> Could have been introduced recently with ssgSharedPtr<>.
No!
> Around
> the time when we got random objects it was desirable not to have
> thousand separate tree objects etc. in memory. So the
> SGModelLib::load_model() function was introd
I tried to use and
in the Instruments-3d/vor.xml file and it has no affect. I
followed the syntax from the Model-How-To file; also the same as the
syntax used in ai.xml. Here is the relevant chunk of the new vor.xml file.
GlidescopeNeedleTransform
rotate
GlidescopeNeedle
/ins
> From: "David Megginson"
>
> On 27/02/06, Curtis L. Olson <[EMAIL PROTECTED]> wrote:
>
> > If you dig up a utility called "sloc" (source lines of code) it suggests
> > that we are sitting on a body of code that would have cost 10's of
> > millions of dollars to produce had we done it in a tradit
On Monday 27 February 2006 18:53, Curtis L. Olson wrote:
> In TerraGear we avoid the polygon rendering problems you are seeing by
> doing a delauney triangulation ourselves and throwing away everything
> outside the polygon boundary. It would likely be a lot of effort on
> your part to do the sam
> From: Dave Perry
>
> I asked David Megginson off list this question and he suggests I ask the
> developers.
>
> I tried to use and
> in the Instruments-3d/vor.xml file and it has no affect. I
> followed the syntax from the Model-How-To file; also the same as the
> syntax used in ai.xml.
When I did the dual nav for the pa24-250, I created a vor2.xml that
could be eliminated by using params and property alias. If I edit
vor.xml and use params and property alias to specify which nav in the
calling model, and remove vor2.xml, will I break any models. I will
make the small change
I asked David Megginson off list this question and he suggests I ask the
developers.
I tried to use and
in the Instruments-3d/vor.xml file and it has no affect. I
followed the syntax from the Model-How-To file; also the same as the
syntax used in ai.xml. Here is the relevant chunk of the n
On Monday 27 February 2006 10:50, David Megginson wrote:
> Why stop there, though? The base package contains about 95,000 (!!!)
> lines of XML and nearly 30,000 lines of NASAL scripts. Of course, we
> should also count the raster graphics, sound samples, 3D models,
> non-XML data files, etc. etc.
On 27/02/06, Curtis L. Olson <[EMAIL PROTECTED]> wrote:
> If you dig up a utility called "sloc" (source lines of code) it suggests
> that we are sitting on a body of code that would have cost 10's of
> millions of dollars to produce had we done it in a traditional
> commercial environment. It mak
Hello Jon
"Jon S. Berndt" writes
Can you email me the file? As soon as I get FG to build I'll try it out -
maybe in the JSBSim standalone. As AJ mentions, there may be a problem
reading tabs in some locations. I also need an example of where this
happens
so I can try and fix that.
Because t
Julien Pierru wrote:
Tiago and I have been working on a svg to ac converter to create
airports from pdf files.
Most of it is done, however we still have 2 problems, the first is
that the code can't at the moment produce the accurate location of the
origin (lat/long) and the second is that most
David Megginson wrote:
It's not all that useful a metric -- I'd prefer to count methods,
functions, etc. -- but FlightGear checks in at roughly 215,000 lines
of C/C++ code, and SimGear checks in at close to 75,000 lines.
Why stop there, though? The base package contains about 95,000 (!!!)
line
> I found a spot where I can put a tab and make it fail. I'll work
> on that. I think I also must still hav eyour file - thanks for
> reminding me.
>
> Jon
I've committed a fix to JSBSim CVS for the situation where tabs or spaces
appear in element data - for instance, in tables. Tabs and/or sp
On Mon, 27 Feb 2006 17:43:55 +
Justin Smithies <[EMAIL PROTECTED]> wrote:
> Hi all,
> I've just tested the mk-viii instrument on the 737-300 and it works
> great.
> I have the files required for addition to the FG cvs and it compiles fine.
> All thanks have to go to Jean-Yves Lefort
On Monday 27 February 2006 16:50, David Megginson wrote:
> On 27/02/06, Jon S. Berndt <[EMAIL PROTECTED]> wrote:
> > Has anyone ever checked to see how many lines of code are involved in
> > plib/simgear/flightgear?
>
> It's not all that useful a metric -- I'd prefer to count methods,
> functions,
Hi all,
I've just tested the mk-viii instrument on the 737-300 and it works
great.
I have the files required for addition to the FG cvs and it compiles fine.
All thanks have to go to Jean-Yves Lefort for this excellent bit of coding.
Email me and i'll send the files for you to test.
Thi
> Another metric: there are ~1500 files
> in the plib/simgear/flightgear codebase.
>
> Jon
Here's a clarification (before I get called on this), there are ~1500 .c,
.h, .cpp, .cxx, and .hxx files.
Jon
---
This SF.Net email is sponsored by xP
> It's not all that useful a metric -- I'd prefer to count methods,
> functions, etc. -- but FlightGear checks in at roughly 215,000 lines
> of C/C++ code, and SimGear checks in at close to 75,000 lines.
>
> Why stop there, though? The base package contains about 95,000 (!!!)
> lines of XML and ne
> Has anyone ever checked to see how many lines of code are involved in
> plib/simgear/flightgear?
>
> Jon
This:
wc `find . -name "*.[ch]??";find . -name "*.[ch]"`
results in a finding that there are 420,000+ lines in the source and header
files. That's not lines-of-code, but just lines.
Jon
> At the suggestion of an email, I seem to be getting much farther
> by putting this:
My build was successful.
Jon
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile
On 27/02/06, Jon S. Berndt <[EMAIL PROTECTED]> wrote:
> Has anyone ever checked to see how many lines of code are involved in
> plib/simgear/flightgear?
It's not all that useful a metric -- I'd prefer to count methods,
functions, etc. -- but FlightGear checks in at roughly 215,000 lines
of C/C++
You know, as I am building FlightGear right now, I am really amazed that
such a large application - a collection of so many source files - builds and
runs successfully on so many platforms. Thinking of all the dependencies -
it's a huge undertaking that has carried us this far.
Has anyone ever che
Melchior FRANZ wrote:
> I suggest we put that in every single file in sg and fg, with an
> #ifdef around, just like those sophisticated #include .
> That way the likeliness of omissions and typos is vastly reduced. :-}
>
> m.
At the suggestion of an email, I seem to be getting much farther by pu
* Mathias Fröhlich -- Monday 27 February 2006 14:31:
> Would it be possible that we add that to CPPFLAGS in configure.ac if we find
> a
> *win32*) host?
I suggest we put that in every single file in sg and fg, with an
#ifdef around, just like those sophisticated #include .
That way the likelines
Thanks Norman,
I knew that there is something like that in windows, but I can never remember
in which header which define could be used to switch it off ...
On Monday 27 February 2006 14:24, Norman Vine wrote:
> You need to make sure to #define NOMINMAX
>
> or else includes conflicting stuff
You need to make sure to #define NOMINMAX
or else includes conflicting stuff
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Jon S.
> Berndt
> Sent: Monday, February 27, 2006 7:57 AM
> To: flightgear-devel@lists.sourceforge.net
> Subject: RE: [Flightg
> To be honest, I've completely forgotten all the details since
> then, but if you
> have since ditched that email and can't break JSBSim with tabs,
> I'll have a
> go again myself ;-)
>
> AJ
I found a spot where I can put a tab and make it fail. I'll work on that. I
think I also must still
Jon,
try to look at the preprocessed files and see what is there when the compiler
gets the preprocessed sources from the preprocessor.
I bet there is a macro somewhere ...
Greetings
On Monday 27 February 2006 14:19, Jon S. Berndt wrote:
> > > Here's the offensive code in /usr/local/include/s
> > Here's the offensive code in /usr/local/include/simgear/math/SGMisc.hxx
> >
> > === start ===
> >
> > static T min(const T& a, const T& b)
> >
> > === end ===
> >
> > The last line, above, is the culprit. As before, the errors are:
> >
> > SGMisc.hxx:28: error: expected unqualified-id before
On Monday 27 February 2006 12:05, Jon S. Berndt wrote:
> It is a priority for fixing. Can you tell me where I can put a tab to break
> the JSBSim parser? I'll take a look at that ASAP.
Hi Jon,
I should be clear that I'm not shouting at anyone to fix this right now (I
quite appreciate that you ha
> > Here's the offensive code in /usr/local/include/simgear/math/SGMisc.hxx
> >
> > === start ===
> >
> > static T min(const T& a, const T& b)
> >
> > === end ===
> >
> > The last line, above, is the culprit. As before, the errors are:
> >
> > SGMisc.hxx:28: error: expected unqualified-id before
> One thing to watch out for is that JSBSim can choke on TABs in certain parts
> of the config file for some reason. It seems perfectly happy with them in
> some places (as indeed it ought to be), but if they exist in other parts, it
> crashes.
>
> If this problem is not a priority for fixing,
> Opening it in a browser shows no errors and the file opens correctly.
> It seems strange that just commenting out a section of the file and then
> uncommenting it again would cause FG to abort.I have changed
> the old JSBSIM file without any problem.
> I only commented on this because some one el
Hello Jon
"Jon S. Berndt"writes
Another thing you can do is to open the aircraft config file in a browser.
That *should* display the XML file using the style sheet specified in the
processing instruction at the top of JSBSim aircraft config files. There is
a style sheet (JSBSim.xsl) at the J
On Monday 27 February 2006 01:43, Innis Cunningham wrote:
> files without problem.Could there be something in the new XML format that
> my worpad
> does not handle leading to corruption of the FDM file?.
One thing to watch out for is that JSBSim can choke on TABs in certain parts
of the config f
On Monday 27 February 2006 03:37, Vivian Meazza wrote:
> Hi,
>
> I'm experiencing an odd bug when using Festival and Cygwin. Sometimes, not
> consistently and not repeatable reliably, FG quits when the message
> "Foxtrot Golf Sierra you are leaving my airspace ." is spoken. There is no
> error mess
* Melchior FRANZ -- Saturday 25 February 2006 23:08:
> Is everyone aware that we *never* free model branches? They are
> only accumulated until fgfs is exited.
The flush1() function was meant to remove unused models from the map.
It's functional, but not used. The comment suggests that it wouldn't
"dene maxwell" wrote:
> I regret any offence I may have caused you. Given that this not the first
> time I have caused you personal offence. After careful consideration I feel
> it is prudent that I hang up the keyboard on the developer lists, at least
> until such time as I can afford hardware
Hi,
I'm experiencing an odd bug when using Festival and Cygwin. Sometimes, not
consistently and not repeatable reliably, FG quits when the message "Foxtrot
Golf Sierra you are leaving my airspace ." is spoken. There is no error
message or other fault indication. It doesn't seem that any other ATC
39 matches
Mail list logo
