Curtis L. Olson wrote:
Is there a way in nasal to read the contents of a file or list the
contents of a directory?
Ideally I would like to list all the contents of a directory and build
an array of file names found (and do this in nasal.)
Is there a way to do this?
I have a
I wrote:
Maybe someone could hook the plib directory stuff into NasalSys.cxx?
My build tree is ancient, so I don't quite have enough time to test
this (or even try to compile it). But this is the basics of how it
would work: insert this into NasalSys.cxx and add an entry to the
funcs[] table
Vance Souders wrote:
Microsoft has made major changes to the standard C++ and C
runtime libraries under Visual Studio 2005. When compiling
Flightgear 0.9.9 under VS 2005, you get about 2500 deprecated
function warnings because of these changes. So, to build FG
under VS 05 with zero errors
Frederic Bouvier wrote:
It says that strcpy ( for instance ) is not secure and one should
use strcpy_s that is the secured version. Maybe I missed something,
but I don't thing strcpy_s is available outside the MS world.
They couldn't just implement strncpy ... ? Still, that's a good
example
Drew wrote:
If I may elaborate on this problem, most of the string handling
routines (strcpy, strcat, sprintf...etc.) have a more 'managed'
alternative that Microsoft encourages programmers to use. These
have the '_s' after them (strcpy_s, strcat_s, sprintf_s), and
contain an additional
Josh Babcock wrote:
We use one prop /controls/gear/gear-down to denote when gear is down
and locked. does YASim just turn on the extra drag when that changes
to 1 or does it slowly increase it over the time of extension?
It's smoothly interpolated across the extension.
Andy
Melchior FRANZ wrote:
I've yesterday committed a Nasal class that helps to display log
information in a scrolling transparent window. This can be used for
ATC message type of information and whatever info you want to
display.
This is really slick. How about porting the existing screenPrint()
alexis bory wrote:
Did anybody asked about a way to keep the hud's marks inside the hud
screen ?
There isn't a good way to do it right now. The current HUD code is
very old, and predates the 3D cockpits. It just draws directly to the
screen (with a matrix hack to make it appear in the correct
Justin Smithies wrote:
I'm using a dual nvidia 5200 and i have setup twin view. If i run
FG in a window i can get it to fill the 2 screens but i want to use
full screen and if i do that it only goes on the 1st screen.
That's more of a Glut/SDL limitation. Choosing full screen just
forwards
Justin Smithies wrote:
I would like an option to be added to the FG command line that would
remove so much of the screen on the right so where my two monitors
join its like having the window strut seperators.
You'd be better off just running a separate FlightGear instance on the
second monitor
Melchior FRANZ wrote:
My little Nasal console:
http://members.aon.at/mfranz/nasal-console.jpg [23 kB]
Nice. :) I get all teary-eyed when I see stuff like this.
Andy
---
This SF.net email is sponsored by: Splunk Inc. Do you grep
dene maxwell wrote:
Doesn't make the least sense sorry don't understand this
... Telenet being a application layer protocol requires alot more details as
to recipient and also alot higher overhead to implement...whereas UDP being
a trasport layer protocol is less distinct in is
Frederic Bouvier wrote:
Melchior FRANZ wrote:
Why the #ifdef? Is there a reasonable case where CONFIG_H is *not*
available?
It has always been the practice to enclose #include config.h by
#ifdef HAVE_CONFIG_H from the beginning of autoconf/automake.
That's not really an answer to the
Mathias Frölich wrote:
Because that is the way automake is supposed to work. You can
either include all defines autoconf generates in the compilers
commandline, then HAVE_CONFIG_H is not defined or autoconf puts the
defines into config.h and defines HAVE_CONFIG_H ...
What's wrong with just
Christian Mayer wrote:
So to stay portable it's a must - you are including a file that does
not exist otherwise.
Again: just stub out an empty config.h and check it in. Will this not
work on MSVC for some reason? Note that all other platforms are Unix
and use autotools, MSVC is the only one
syd sandy wrote:
Does yasims 'approach aoa ' mean angle of decsent path or pitch of
the aircraft? Ive always assumed it the angle of approach path.
Neither. The acronym AoA is used in place of angle of attack,
which is a technical term referring to the angle with which the airflow
meets the
Melchior FRANZ wrote:
If the object is removed from memory, then a variable is changed in
the object's namespace, so that the code can stop itself.
Rather than set this from C++ code, why not use:
An optional destructor part can be used for further cleanup (remove
listeners etc.)
Which can
Dave Perry wrote:
I would like to add a voltage check before moving the flaps or
landing gear in data/Nasal/controls.nas. The proposed changes are
underlined.
Adding aircraft-specific code to the generic control mappings is a bad
idea; that file is for Nasal code that is globally useful for
Justin Smithies wrote:
I seem to have the {} () ; wrong somewhere and maybe some other
little errors.
You didn't close the parentheses in the setlistener() call. Every (
must be matched with a ) of course. Programmers use indentation
conventions (and usually special editors) to help with
Josh Babcock wrote:
OK, I seem to have made nasal produce an infinite loop. It
SIGSEGVs when I hit 'v', which is tied to the standard change
view function. Here's how I did it:
This isn't a Nasal issue: you're trying to make changes to a
property node while under a listener for the same node.
Ima Sudonim wrote:
I'm not defending what this person is doing,
For the record: there's absolutely nothing wrong with what this person
is doing. Providing duplication services for free software is a
useful service (although apparently not useful enough to get a bid) and
one worth supporting.
David Megginson wrote:
Collision detection and explosion animation are two different things.
With JSBSim, better collision detection is, if I remember correctly,
simply a matter of defining more contact points around the aircraft
body (e.g. in the nose, the end of the empennage, the wingtips,
Jon S. Berndt wrote:
Can anyone tell me what the name of the routines is that allows one
to determine the performance details of a Linux application?
It's probably best to start with gprof. Add a -pg argument to the
compiler flags for the application, run it, and then use the gprof
program to
Mathias Frölich wrote:
On flightgear-devel was yesterday a short discussion about YASims agl value.
It would be nice if YASim could behave like the other FDM's do and like one
would naive expect, in the sense that
ground elevation + agl = altitude
Currently YASim uses the models reference
Lee Elliott wrote:
I've been looking in to the INCIDENCE control-axis in YASim and
although it's there and appears to function, it appears to be
normalised and I can't see what angle it's normalised to - 90
deg, 360 deg ?
I'd have to look at the code to check, but I can guarantee you
that if
Josh Babcock wrote:
The ch-53e has a pretty odd empenage, so I need to make sure I
know what I am doing here. If I define a vstab with a dihedral
of 110, ahich side will it be on? Can I control which side it
is on?
The vstab is a left wing with a dihedral of 90 degrees. Making
it 110 degrees
For those interested, there is now a Nasal-specific discussion list at:
http://plausible.org/cgi-bin/mailman/nasal
Every time I announce a release, a few people pop up who are
interested in Nasal for their own projects or just as a language worth
discussing. It seems that there are (or have
Andy Ross wrote:
For those interested, there is now a Nasal-specific discussion list at:
http://plausible.org/cgi-bin/mailman/nasal
Sorry folks, Josh and Curt pointed out that I typo'ed the URL. It's really:
http://plausible.org/cgi-bin/mailman/listinfo/nasal
Or just follow the link
Melchior FRANZ wrote:
1. YASim delivers a positive /velocities/airspeed-kt on backward
flight.
This strikes me as correct behavior. If you stick a pitot tube
into an airstream backwards, you will get exactly the same
reading as forward (well, modulo viscosity and mach effects). If
what you
Maik Justus wrote:
for my part the update of the yasim heli simulation is ready for
cvs. Andy: therefore I want to ask you for a review of the patch
and your agreement to add this to cvs or a list of necessary
modifications or (hopefully not) a clear no.
OK, here's a quick review of the
.
Andy Ross wrote:
The boundary changes in Wing.cpp don't make any sense to me.
Therefore for an wing without flap, spoiler and slat [...] no surface
element is generated.
Ah, OK. Yes, this was indeed a bug; I'm kinda shocked that we never
noticed this before, it's been there since the code
, but less able to achieve high AoA's at full
elevator). I'd be appreciative if everyone could take their favorite
aircraft out for a spin and report changes -- some may need re-tuning.
Maik Justus wrote:
Andy Ross wrote:
Maik Justus wrote:
Therefore for an wing without flap, spoiler and slat
Martin Spott wrote:
This might be a typical case where someone wanted to avoid
division-by-zero cases ;-)
I don't understand. Is that a snipe? Don't.
Andy
-
Using Tomcat but need to do more? Need to support web
Maik Justus wrote:
Andy Ross wrote:
As I read the code, you would get 1N of force per fuselage surface
No, it's 1 multiplied with 0.5f*rho*vel*vel*_c0.
Heh, so it is. You'd think I'd remember this stuff better. Well, at
least it's being checked in along with another potentially
aircraft
alexis bory wrote:
Well, as not being enough skilled to propose a patch to YASim,
I humbly ask Andy, and the community, to implement a tap on
each jet engine fuel arrival and make the starter start the
stopped engine (it may be allready working :)
If I understand you correctly, it is. YASim
I hit a CVS permissions issue while commiting a new harrier version from
shavlir. These are all new directories; is it possible that the setgid
bit on the archive is missing?
Andy
cvs commit: ERROR: cannot write file
/var/cvs/FlightGear-0.9/data/Aircraft/harrier/Panel/Hud/NTPS.xml,v:
Permission
For those interested, the Fuel Weight dialog just grew a new
feature. The new Harrier modifications from shavlir (which are
really, really nice) needed to be able to turn external stores on and
off in order to correctly draw the 3D model. To do this, he wrote a
nice selector GUI in Nasal and
Jon S. Berndt wrote:
Hmm. I'm not sure how this interacts with JSBSim weight and balance
properties. I just got back from Keystone (AIAA Modeling and
Simulation Conference) and need to take a good look at this more
closely, but does anyone know how this interacts with all FDMs?
The dialog is
Lee Elliott wrote:
The real a/c has steering on both front and rear sets of wheels
so that it can make a crabbed landing and this is where the
first aspect of the problem lies - there only seems to be a
single STEER control axis available.
No, one per gear. You can map them to different
Maik Justus wrote:
You can add more than one control to one gear. If you specify more
than one, the sum of them is used. Normally used for trimming or for
the no-pedals-patch for the bo, which adds a fraction of the
collective input to the pedals.
But there's still one STEER input axis per
Syd wrote:
Hi guys , I'm not sure what indentation style you are referring to ,
and I have warned everyone it's been a long time since I have done
any programming
The purpose behind coding styles is to make the code easy to read.
Melchior wasn't talking about anything specific, just the
Finally, please make sure you remove *all* traces of FlightGear and
SimGear from you system before doing a
Durk Talsma wrote:
Lou Sanchez-Chopitea wrote:
I have assembled a box based on a Tyan MB with two Athlon MP 2000+
with 2GB of ram, running Fedora Core 5. I get segfaults in both
I wrote:
Finally, please make sure you remove *all* traces of FlightGear and
SimGear from you system before doing a
Sorry, an editor goof pasted the first sentence of this into the wrong
place and dropped the rest of the paragraph. Should have read:
Finally, please make sure you remove
flying.toaster wrote:
Is there anywhere a list of work in progress just to avoid duplicates?
Even if there were, the best advice would be to ignore it. :)
This is a volunteer project done (mostly) for the enjoyment of the
developers, and as such many of the subprojects that are announced
here
Martin Spott wrote:
Andy Ross wrote:
flying.toaster wrote:
Is there anywhere a list of work in progress just to avoid duplicates?
Even if there were, the best advice would be to ignore it. :)
Teamwork is not one of your favourites, is it !? ;-)
In what way is refusing to work
Trasca Virgil wrote:
I am intersted in contributing with some bug fixing to flightgear
project. How should I start for that?
To start with, you need to find some bugs you want fixed. :)
If you have a CVS version built and running (this is step one,
obviously), you should have no trouble
Didier Fabert wrote:
anybody have a runable flightgear CVS with a 64bits processor (linux) ?
Yes, CVS as of yesterday afternoon on Ubuntu Edgy amd64. The OSG
build was, er, painful to get working in my setup (I like to build
out-of-tree into a custom --prefix). But it works.
i hear that
Martin Spott wrote:
I had to make the following change in order to get the 'fgfs' binary
linked on FreeBSD. 'libosgSim' apparently references some functions
like osgText::readFontFile which areimplemented in 'libosgText'
Which begs the question: why on earth does OSG insist on installing
Martin Spott wrote:
I guess the intention is to allow developers to link only the libraries
whose functions they actually call. Think of some application that
needs - just as a stupid example - only functions from libosgText but
none from libosgSim ?
What would be the benefit of that if
Martin Spott wrote:
Think of some application that needs - just as a stupid example -
only functions from libosgText but none from libosgSim ?
Actually, here's a better explanation: let's call that application
FlightGear and say that it requires functions from osgUtil, osgSim
and osgDB, but
I'm new to aircraft model animating, I'm trying to understand what does
control the gear/gear[0]/position-norm property in the A-10 aircraft ...
This is a property output from the YASim FDM. In the A-10-yasim.xml
file you will find the following line in the nose gear tag:
control-output
I would like to restrict that a bit. For bugfixes and non
developers this might be a good idea. But please do not develop
new features on the branch. I know how many problems this will
give. And to be honest, Olaf I believe You know what I am
talking about ...
No offense, but the
Ooh, it's a bona fide flame war. :)
Look, the points wasn't that plib is great. The point wasn't that OSG
has no advantages. The point was that we've taken working software
and regressed its feature set pretty severely, and that's a serious
problem that needs to be fixed now. Stopping
Curtis L. Olson wrote:
Andy Ross wrote:
Look, the points wasn't that plib is great. The point wasn't that
OSG has no advantages.
I'll just jump in here with a couple quick comments. OSG does have
advantages that we should be able to realize pretty quickly, it is not
completely
People apparently got used to the state that FlightGear typically
has a CVS tree that you can compile at the end of a development day
and 'fly'.
Remember that people doing aircraft models and scenery are also
developers, and need to be able to run the development version to do
their work
Douglas Campos wrote:
but content developers can't just stick with plib branch? afaik
we'll only making the porting work at trunk, right?
No, they can't; not if (by Mathias's suggestion) new features are
added only to the head and not to the plib branch. See his post a few
messages up.
That
Frederic Bouvier wrote:
Sorry, but I only understood that Mathias is not willing to backport
new features. He never said no one should do.
It's possible that I misinterpreted, and maybe Mathias would like to
clarify. But FWIW I thought he was pretty unambiguous:
: I would like to restrict
I whish there were more NASAL tutorials around.
This page is a little out of date, but it should be linked to from
wiki.flightgear.org (where there is lots more good information):
http://plausible.org/nasal/flightgear.html
It has reference docs on most of the core interface, but not the more
Arnt Karlsen wrote:
..moot, he disregards the GPL _completely_ and is hit by copyright
law, plus possibly for fraud, in representing himself as a fully
licensed reseller. Abiding by the GPL, he would have been.
I should jump in here: your logic is flawed. You might just as
well argue taht
Arnt Karlsen wrote:
..since redlinedit's eBay site in no way contains a notice placed
by the copyright holder saying it may be distributed under the terms
of this General Public License.
Here is your confusion: redlinedit's eBay site is not FlightGear.
It is copyrighted by redlineedit* not
Torsten Dreyer wrote:
Is there an issue with 64 bit linux or dual core/smp that I am not
aware of?
Nope, I'm running FlightGear on a x86_64 Ubuntu Edgy on a Core 2 Duo
without problem. As Melchior pointed out, this was just a plain old
script bug.
Note that FlightGear's main loop (which
Josh Babcock wrote:
foreach(light; lights) {
propertyPath = 'some/path/'~light;
# do magic to the hash lightNodes here
# So that a node linked to propertyPath
# with a key of light gets added to lightNodes
}
The hash/vector index expression is an lvalue that can be
Maik Justus wrote:
there is a minor bug in YASim in the gear code. The sfric and dfric
tags in the aircrafts .xml are ignored.
I didn't even know those were tunable. Actual tires have a very
narrow range of friction coefficients, except for special cases like
knobby off-road tires or special
John Denker wrote:
Ron Jensen wrote:
The step tag effectively truncates the property, 29.9199
becomes 29.91, so a (3D) readout reads off one number.
I am proposing an new tag, bias, that will act like offset but be
applied before step and scroll
While the bias tag
I wrote:
The patch itself looks sane and easy. But I think I agree with
John, this is a workaround for a design flaw in the step animation
that we should just fix.
Nope, it turns out we really do want truncation. The reason is that
the input property to the animation, at least in Ron's
A big heads up. I just updated the Nasal interpreter to sync it with
Nasal CVS:
Sync with Nasal CVS (soon to become Nasal 1.1). Notable new features:
Nasal now supports calls to subcontexts and errors can be thrown
across them, leading to complete stack traces when call() is used,
instead
Stuart Buchanan wrote:
Functionally, it seems reasonable to force all IO access through a
wrapper .nas file in $FG_ROOT/Nasal that could attempt to restrict
dangerous activities.
This is actually possible, albeit obtuse. In the existing io.nas file
(which currently adds the soft-coded
Harald JOHNSEN wrote:
I've added this to the two file where func is used (seen on the interweb)
/* Try to get a reasonable __func__ substitute in place. */
#if defined(_MSC_VER)
/* MSVC compilers before VC7 don't have __func__ at all; later ones call it
* __FUNCTION__. */
#if _MSC_VER 1300
Durk Talsma wrote:
Back in January, right before my Canadian adventure, I reported a
compile error related to yasim-test. [...] I found that the following
modification to src/FDM/Yasim/Makefile.am works:
[...]
I basically added the -losg* linker directives to ensure that the correct
Durk Talsma wrote:
Gear.cpp includes:
#include simgear/scene/material/mat.hxx
Not in CVS it doesn't. It makes a type declaration for class
SGMaterial so it can pass a pointer to it only. Do you have some
local changes or patches from someone else applied?
Andy
Durk Talsma wrote:
Looking at the CVS browser, it seems like this dependency on SimGear
was added on January 17, as part of a patch contributed by Maik
Justus:
Sorry, but I honestly don't know what you're looking at. There are no
SimGear includes in the HEAD of Gear.hpp in my tree. There is
Oh, wait a second: I now see you are talking about the header (.hpp) file,
whereas I was referring to the (.cpp) source file, Gear.cpp. You are right
that the former (the hpp) contains (only) the SGmaterial reference. The
latter, the Gear.cpp source file is the one containing the additional
Ladislav Michnovič wrote:
Hello.
Compilation on ppc machines crashed on unknown CPU in
simgear/nasal/naref.h file.
I've changed __ppc__ to uppercase and detection works fine.
Can you provide more details about your platform? I was under the
impression that OS X on PowerPC used the __ppc__
Joacim Persson wrote:
README.yasim says the semi-deprecated transition-time is Time in
seconds to slew through input range. I'm not quite sure what it is,
but it's not that. ;)
It's coded to assume that the input range is 0-1. It was really
written for landing gear. If you want to model
Ladislav Michnovič wrote:
2007/5/24, Andy Ross [EMAIL PROTECTED]:
Can you provide more details about your platform? I was under the
impression that OS X on PowerPC used the __ppc__ symbol, but I don't
have a box to test against. If your compiler is gcc, can you post the
results of:
echo
Thomas Förster wrote:
which reminds me of:
The Zen of Python (by Tim Peters)
Probably a bunch of good ideas for every language.
Yup, great advice. Pity python forgot about it:
There should be one-- and preferably only one --obvious way to do it.
If the implementation is hard to explain,
John Denker wrote:
Compare:
http://www.av8n.com/fly/fgfs/weather.xmlworks
http://www.av8n.com/fly/fgfs/weather.xmlbroken
The difference between them is simple, and is attached below.
The working file contains a working colspan. The broken
file contains a second colspan that
John Denker wrote:
Andy Ross wrote:
Here's the problem. You're giving your dialog a fixed size, then
asking it to display something that doesn't quite fit.
On my syste, with the default style, it should fit with room left
over. The working version makes this particularly clear.
Why do
John Denker wrote:
Yes, I tried it. It looks terrible.
It still appears to be miscalculating by a factor of 3 the required column
width.
A factor of 3? Dunno, it looks fine to me, and I can verify that it
fixes your problem with shrinking columns. Whether you choose to
believe me or not
John Denker wrote:
4) I did not snipe. I did not sneer. I reported the facts as I
observed them. If observations conflict with your expectations,
what should I do?
John, please. You asked for a new feature that already exists, and
when corrected immediately reported that it doesn't work
Stewart Andreason wrote:
Is there a preference for how variables are declared and used in nasal?
between the global type:
var some_name = 0;
which can be accessed and changed from any function,
That's a Nasal variable. It's not global in the sense that all
users will see the same value for
Stewart Andreason wrote:
If accessing temp1 _is_ faster than .getValue, then at 2 or 3
accesses, I imagine it becomes faster to do the above?
Yes, it's definitely faster, because there's less work to do.
Evaluating the expression temp1 requires pushing the symbol value (a
string) onto the
Frederic Bouvier wrote:
I think stutter comes from the threaded scenery tile
loader. When you change view direction, you ask the loader to
load more tiles, and when all required tiles are loaded for a
given position, the stutter stops.
That seems unlikely. The tile loader is very old code,
olaf flebbe wrote:
Durk Talsma wrote:
SimGear require plib-1.8.4, but this version no longer builds on my
box
There is still an patch for MSVC8 waiting to be applied.
Looking at that patch, it seems entirely typecast stuff. Those are
warning conditions; I don't see any changes that would
olaf flebbe wrote:
You may be wrong. They are writing to const char *. I had to strdup().
A const char* is exactly the same thing as a regular pointer at
the level of CPU instructions. Writing to it does exactly the
same thing as writing to a non-const pointer. The difference
exists at
John Denker wrote:
2) It seems vacuous to compare writing via a const char* to
writing via a non-const char*, because AFAIK there is no such
thing as writing via a const char*. No compiler AFAIK will
generate any CPU instructions for it.
Oh, good grief:
$ echo 'void foo(const char*
Csaba Halász wrote:
Note that literal string constants may be allocated in read-only
data section, thus causing segmentation fault at runtime. Try
calling your foo function passing a literal string,
What does this have to do with the discussion? We are talking about
const pointers, not linker
SydSandy wrote:
Hi all , is there a way to format a double and output that to a
string property with writing the double to a property first . Should
be doable but it escapes me at the moment ...
Example : (double) 2.30 to (string) 2:30
Nasal numbers will convert directly to strings
Hans Fugal wrote:
I could be wrong, but I think you missed his point. I don't think he
was arguing that you couldn't cast a const char* to a char*. The
argument was that without the cast it doesn't work, and the cast is
bad form and leads to bugs.
A point, you will note, I never disagreed
SydSandy wrote:
No its not a typo , I want a single string property to hold
groundspeed ,TTG and ET , depending on which mode is selected for
display on the Primus PFD
OK. You might want to make that property a string, though, or at
least an integer. Storing a fracional number there and
olaf flebbe wrote:
As a side note: The gcc does not enforce const-correctness very
much.
Sigh, and the flames continue... Your basis for that statement is
what, exactly? Of course gcc enforces const correctness. I suspect
what's happening here is that plib, which is using string.h and not
olaf flebbe wrote:
Please do not mix the terms compiles o.k. and works for me with
the code is correct.
I did no such thing. The issue here is whether or not the code is the
*same* as the one we are shipping on other platforms. Yours is not,
and therefore really shouldn't be packaged up into
olaf flebbe wrote:
If my memory serves, VC8 shipped with a new runtime that won't work
on XP without an update, right?
Wrong.
Can you elaborate? I'm all but certain that default builds want to
link against MSVCR80.DLL (or whatever) at runtime, no? Are we set up
to install that in our
Csaba Halász wrote:
Don't know if Melchior and Andy have arrived at anything while I was
away, but here is what I found.
Yup, that's exactly it. New nasal objects are added to a temporary
bin when they are created, because further allocation might cause a
garbage collection to happen before
So it's only missing #include which should
be in the code. See the attachments.
[...]
#include math.h
+#include stdlib.h
+#include cstring
Surely that should be string.h, no? It's just a style thing, but if
you're modifying code that is already using ANSI C headers, and not
Standard C++
Curtis Olson wrote:
I just committed a patch that should fix this configure.ac problem.
Guys, it looks like no one tested this patch before committing it
It worked for me. Probably because my LD_LIBRARY_PATH is set such
that the resulting configure-generated programs can run?
The genesis of
Ove Kaaven wrote:
It looks like there are some portability issues in the current
code...
On three platforms which don't have the CPU power (or GPU support!) to
actually, y'know, run the software. :)
Steve Langasek wrote:
So this assumes the kernel will never expose more than 48bits of
Ove Kaaven wrote:
It's not just him being cranky about his own pet issues, it's
about policy and the pursuit of high software standards.
High standards for software you (literally!) can't run?
Please. This is pedantry and egotism at its worst. I'm terribly
sorry my software isn't good enough
till busch wrote:
* f_interpolate in NasalSys was leaky (valgrind)
This leak is real, but the patch isn't legal C++, at least as of the
last time I read the standard. You can't initialize a stack array
with a dynamic value, it has to be known at compile time. This is a
gcc extension. Better
Torsten Dreyer wrote:
While the YASim engines don't warm up the burned air at all (egt
equals ambient air temperature)
That's almost certainly because something is wrong in the engine
configuration, probably displacement or compression ratio (which
wouldn't otherwise cause problems if they were
1 - 100 of 119 matches
Mail list logo
