On 04/14/2013 06:13 PM, Diogo Kastrup wrote:
A long time ago I started working on a different implementation for
YASim static friction. With help from Csaba and Mathias Fröhlich the
patch worked but I never finished polishing it to submit a final
version.
Vivian poked me about this one, so I
On 10/05/2012 05:53 AM, Vivian Meazza wrote:
Andy is still around, but inactive. It might be possible to run stuff by him
once in a while.
He even reads the mailing list (but not the forums) on occasion. :)
Indeed, I'm busy with other things these days, but am still broadly
happy to answer
On 07/05/2012 02:41 PM, Viktor Radnai wrote:
Thanks for that! So just to clarify -- this is a bug in Yasim code (or
more like a missing feature) and I'm welcome to fix it?:)
I'm just an absentee hacker, so I can't say what is or isn't
acceptable any more. But it seems like a sane enhancement
On 05/23/2012 12:04 AM, Erik Hofman wrote:
Hi Andy, how's life?
I did already search for a new release of Nasal on your site but I
believe flightgear already uses the latest version.
The most recent code (except for a few modules that were never imported)
is in SimGear. I threw my copy up on
On 05/20/2012 10:17 AM, James Turner wrote:
This is interesting - as far as I know, the current GC does not
include a maximum delay and restart facility. If it did, that would
entirely satisfy the current issues. At least by my understanding.
Equally, I've looked at the current GC code and
On 05/20/2012 11:37 AM, Stefan Seifert wrote:
Generational garbage collection is not that difficult. When you have a working
mark sweep GC, extending it to be generational is rather straight forward
and can greatly reduce GC runtime
Runtime, yes, but not latency bounds. You still have to
On 03/29/2011 11:31 PM, thorsten.i.r...@jyu.fi wrote:
for (var i =0; i 30; i=i+1) # number of objects is 30
is superior to
var number_of_objects = 30;
for (var i = 0; i number_of_objects; i = i+1)
No it isn't. Variable references aren't garbage (well, they aren't
heap blocks, though they
On 02/22/2011 04:09 PM, Ryan M wrote:
I am not a 777 pilot in real life, but I certainly agree with Jack that
the FDM seems unrealistic to the casual pilot.
For those interested (Curt made me look at a YASim file last week for
the first time in over a year, so my head happened to be in the
On 02/11/2011 11:54 AM, Alasdair wrote:
You will note in all further dicussions that I will refer to nasal
as NASAL (Not Another Scripting Language), which denies its very
existentence through a lie in its own nomenclature. cf GNU which
makes no such assertion, but was probably dreamed up by a
On 02/08/2011 11:04 AM, Anders Gidenstam wrote:
Backing it out might be a bit tricky, but you can rename your messed up
branch out of the way easily with git branch -m oldname newname.
It's worth experimenting with git reflog in situations like this.
That tracks a list of HEAD references in
On 02/09/2011 12:02 AM, Tim Moore wrote:
Backing out is done with git reset --hard last_good_commit. Often the name
of the last good commit is HEAD^, the last commit. However, after a botched
merge it is good to verify that with git log or graphically with gitk.
Actually, unless I've
[saw this in time to de-lurk]
On 01/25/2011 11:22 AM, Anders Gidenstam wrote:
I suspect the option --local to git clone might be useful.
I have not tried myself, though.
Yeah, this is the best answer for this kind of problem.
The .git directory ends up being near-zero size (so long as the
On 12/08/2010 02:14 PM, Roland Haeder wrote:
And the temperature at EDDL can now really be at 0 deg. Celsius because
of winter time. :)
Just happened to see this come by.
That function takes temperatures in kelvin. And the pressure (absolute
also) was likewise passed in as zero. This is an
Thought I'd chime in here, as I've been going through the git
transition pains myself recently, and the other answers have been all
about the what and not the why of the task.
Git adds an extra level of indirection that you're not used to: the
cvs/svn model of the world had only one repository.
On 05/26/2010 12:44 AM, James Turner wrote:
This is a wild guess, but from memory (of discussions here), and reinforced
by the code snippet above, effectiveness is a hack/tweak to account for
surfaces/controls that work better/worse than YASim predicts. So
effectiveness of 1.1 makes the
Oh, man -- giant Nasal flame war and I totally missed it. Melchior
just now pointed me here. Sadly (or, well, not at all, actually)
Andy's been doing a lot more of the daddy thing than the hacker thing
recently. Some quick shots after the fact:
Nicolas Quijano wrote:
It's also brilliant,
Frederic Bouvier wrote:
I get memory corruption caused by writing outside an malloc'ated memory
bloc. I tracked the problem down to the recsize() function ( in hash.c )
computing a memory size that is not enough for subsequent initialization
in resize()
Wow, good catch. This was also
Note that a reasonably big Nasal change just went into SimGear.
Melchior had a chance to test it out first, so hopefully not too much
will have broken. The documentation for the new syntax is below.
There's also been some work done to reduce the memory footprint for
strings (store short strings
Sven Almgren wrote:
But is this really needed? How does M$ flightsim extensions do? You
have to trust the source somewhat, We could sneak in bad code in
fgfs too, and ppl would run it anyway... Can the addoncreators be
trustet as much as we can?
Sure. FlightGear is a local program, and
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
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
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
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
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
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++
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
, 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
.
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
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
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
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
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
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
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
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
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,
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.
1 - 100 of 119 matches
Mail list logo