Re: [Flightgear-devel] static friction patch
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 got here in time for a change. :) Can I be a jerk and kick this back for patch formatting reasons? I think I get the idea here: it's detecting the stopped condition and replacing the existing friction mechanism with a spring model around a fixed point. And that makes sense to me. But it's really hard to review: there's no commit message explaining what's happening; lots and lots of the modifications are just whitespace changes to existing code that I have to prune out to read the real changes; some things just don't make sense, like the apparent addition of tmul33() and family to Math.hpp which I swear was there before... Would it be too much to ask for Diogo (or anyone else) to do a cleanup pass on this? Andy -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim and documentation
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 questions if posed (as long as I remember enough to come up with a meaningful answer). Just cc: me if you do, because my latencies here are measured in weeks. But I would in general worry about mucking about with such a critical part of FG, unless I was very sure about what I was doing. Bugs can always be fixed. What YASim needs is a maintainer, not really expertise per se. The latter comes from the former. Andy -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Yasim static friction?
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 to me. But broadly yes: it's free software. The whole point is to make it do what you want. Andy -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal performance
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 github a while back if there is any question about variants: https://github.com/andyross/nasal Andy -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal performance
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 didn't notice any code to support this feature. Does anyone else have any further information about this? Since it would be far simpler and more robust than any other solution thus suggested. I was lucky enough to notice this come by. I wouldn't hold your breath. :) This was an experiment, and honestly I have no idea why I put it in the docs. The idea was to do the GC normally, check timestamps periodically, and then longtmp() out of it past some threshold, leaving the intermediate sweep stuff in place. But that's not enough, because now you need to track all mutated reference-storing objects in a separate list so they can be swept again. And you need to have some kind of heuristic for when it's OK to restart the sweep. I have a vague memory of being sure I'd cleverly solved this, but I never got it working and at this point, frankly, I suspect I was wrong. In my advancing age, I've come to believe that low-latency GC is just a pipe dream. You can have a realtime GC or you can have a production system, but you can't have both at the same time. Every managed runtime in the modern world has latency bugs in some application or another, every one of them. Andy -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal performance
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 touch the whole heap eventually. But you're right: allocating objects into generations and only mark/reaping from the most recent one on most iterations is a straightforward optimization and will definitely make things faster. Andy -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Efficient Nasal coding (was: Stuttering at 1 Hz rate)
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 do get traced). The things they point to are
garbage, and a number isn't a reference in Nasal. The 30 in the
second example gets stored (as a double) directly in the hash record
in place of the pointer that would be there if it were a reference.
The var syntax has no meaning as far as allocation. It's about scoping,
it says make this a local variable in the current function no matter what
outer scope it might also be in.
The operations in Nasal that create heap blocks/garbage are:
1. String composition with the . operator
2. Vector creation with a [...] expression
3. Hash creation with a {...} expression
4. Function calls (which create a hash for the namespace)
5. Closure binding with a func ... expression.
I believe that's all of it, though I may have forgotten something.
Andy
--
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself;
WebMatrix provides all the features you need to develop and
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default Aircraft Candidates
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 right place), I took a peek at why this would be: The 777-200 configuration I see in HEAD on gitorious has an approach setting that says it can stay in the air with 7 degrees of AoA (about half of the available lift) at 120 kts with 80% of its fuel and a full load. That strikes me as more than a little optimistic. This is a long haul jet, its fuel is a big fraction of its maximum weight, and typical landings for jet like this are made at what, 15% fuel or less? (It can stay in the air for 11 hours, and you only need 45 minutes of reserve fuel, right?) So some quick math says that if you take this aircraft which can produce 1G at 120kias and reduce its mass by a factor of 1.74x by dropping the passengers and using 10% fuel, and pull it up to a stall AoA, you'll get 3G of acceleration. Speed up to just 207 kias, and you can pull 9G in this plane. Yeah, that's a fighter jet. I'd suggest 131 kts (which matches the landing speed in the coments) and 10% fuel and see how that works. Andy -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sinking feeling - c172 on gravel runway
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 brainy recursionist like Csaba. Yeah. That guy was a serious egghead. What happened to him? Andy -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] urgent git help requested
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 strict chronological order (i.e. what has HEAD been in the past, not what commits were done). In cases where you've completely mucked up the revision history, you can look at this to see what you were doing before, recover the commit ID, and do a reset --hard to that. Andy -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] urgent git help requested
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 misunderstood your point, this won't work: the commit history following a merge is an interleaved mix of two branches. You can't just walk back to before the merge. Doing that gets to to the equivalent of git merge-base, which is the last version that includes *none* of the changes in *either* branch. I don't think that's what Curt wants. See my comment to Anders about git reflog. (and yes, I've made exactly this mistake in the past, heh) Andy -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git work flow question
[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 deltas between trees are small), and you pay only for the copy of the active tree. So resource consumption is more or less the same as having two checkouts of a remote tree. You do have to manage the extra steps required to push/pull/merge between the trees though. Andy -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FPE in yasim::Atmosphere::calcStdDensity
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 initialization bug, those aren't numbers the physics can deal with. Andy -- This SF Dev2Dev email is sponsored by: WikiLeaks The End of the Free Internet http://p.sf.net/sfu/therealnews-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] dumb git question
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. So when you wanted to forget a modified file you would just remove it and issue the command (update) that copies changes from the repository to your working directory. The act of forgetting a change was identical with fetching new changes from upstream, so you used the same command. With git, those are two different tasks! The command to pull changes (not current data, just changes against what you already have) from another repository is pull*. If it happens that someone else has pushed a change to the file you want restored, this will actually do what you want, but only by accident. The command to copy stored versions in your local (!) repository, which is what you want to do, is (unfortunately, IMHO**) named checkout. This will by default copy from whatever the head your current branch is, and you can specify file or directory names. Andy * Which is really the combination of two lower-level commands: fetch simply copies in the branch data but doesn't touch your current working area, and merge which merges changes from another branch into your working tree. ** It's only checking out of a local repo you control. Originally the term was a metaphor for library borrowing: you checked out a SCCS/RCS file the same way you did a book, and gave it back when you were done. The git usage implies that it's touching shared data somewhere, when it's not. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim effectiveness tag
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 flaps 10% more effective. I would assume it's a tweak so you can say, well, the model is basically okay, but it doesn't respond to xyz quite right. Heh, I actually noticed my name on the list in time to respond this time! Yes, this is exactly right. The effectiveness is just a scalar multiple on all force produced by the component which is otherwise (mostly) linear with surface area. It's a useful lever for tuning, but if you find you need to go beyond a factor of two (i.e. 0.5 - 2.0) I'd look elsewhere for the problem. Andy -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal alternatives : possible, of course,
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, smaller (runs on cellphones) and faster than nasal (that's an opinion, but I really can't see how anyone says Nasal is fast, at least from my experience so far) While Lua is pleasingly small, it's certainly not smaller than Nasal, either in code size or size of runtime data (especially at runtime: Lua lacks anything like the vector type Nasal has and can't represent packed arrays). And I also had Nasal running on various phones* back in 2004/5 when I was doing that stuff for my day job. [* Not, by the way, that phones are particularly small any more. Sure they can run Lua and Nasal: also Javascript, one or more JVMs, a .NET CLR interpreter, often a flash interpreter, bash, perl, python, VB, ...] As far as speed goes, the last time I was doing any benchmarking Nasal was about as fast as Perl 5 or Python 2.2 at most things. It's garbage collector was faster, its symbol lookup about the same or slightly faster, and its bytecode interpreter somewhat slower. I'm not aware of any FlightGear usage where Nasal's performance is an issue, but I'm willing to take bug reports. And I'm amused that you feel free to express an opinion about a quantitative subject. Either Nasal is or is not faster or smaller than Lua; I'm not sure what your opinion is coming from if not measurements. :) And I won't mention that is has no adequate documentation and no debugger. Period. (-- that's very serious) If you say so. I've been writing script code in perl and python for a decade and a half and haven't ever felt the need to use a debugger in either environment. That's very much a taste thing. If you can't handle the need to call print() or write an if() to inspect or trigger on runtime state and want to type into a command window instead, that's cool. Just don't pretend that everyone feels the same way. The documentation thing sounds more like a cheap shot than a real complaint -- is there something you'd like to see documented that isn't? We don't have books on Nasal. We certainly do have docs. So as far as flames go, some stuff off the top of my head that was, I think, true at some point in the past. I'm not 100% confident on all this, because my Lua knowledge is pretty stale. + Nasal is threadsafe. Lua has a global interpreter lock. + Nasal is stackless for interpreted code. Lua recurses on the CPU stack. + Nasal is a true functional language, with lexical scoping, runtime binding and true closures. Lua has a clunky global namespace. + Nasal has complete programmatic control over the runtime namespace for any piece of code, making modules a question of script coding and allowing a bunch of neat metaprogramming tricks along the lines of what the Ruby folks do with their monkey patching. Take a look at the (non-FlightGear) Gtk library for some examples. Lua, again, has a clunky global namespace. + Nasal's data model matches what you are used to from perl, python and javascript. Lua's is ... odd. + Nasal has a true garbage collector. Lua has a reference counter that can't handle circular references. + Nasal has syntax that makes sense in the modern world and to programmers exposed to other languages like Javascript. Lua looks like PL/1. But hell, there's really nothing (other than cosmetics) wrong with Lua. As you mention, it's grown into a large community with lots of documentation and libraries and professional-looking trappings. None of that was true in 2003/4 when Nasal was in its infancy, but it is now, and I can see why it would be attractive. If you want to do the integration work and maintain it (remember, there's a ton of code outside the interpreter you need to write to be able to do useful things inside the simulator), feel free. Why was Nasal chosen in the first place ? Wasn't it to supplement a fledgling FDM module at the time, yasim, that was lagging behind jsbsim and its property system ? Or so I've inferred and been told Ooh, a YASim flame too. Bring it on. :) Andy -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory corruption in Nasal with MSVC
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 reported on the nasal list as a difference
between optimized and non-optimized builds on 32 bit linux. I tracked it
down as far as recsize() returning the wrong value, but then wrote it off
as a compiler bug and didn't investigate further. I missed the alignment
issue completely.
Try the following patch, which will force the alignment but still allow the
use of the (IMHO) clever trick to get the memory block size in a single line:
Index: hash.c
===
RCS file: /home/nasal-cvs/nasal/src/hash.c,v
retrieving revision 1.51
diff -u -r1.51 hash.c
--- hash.c 26 Sep 2008 17:53:29 - 1.51
+++ hash.c 25 Nov 2008 17:18:02 -
@@ -96,9 +96,12 @@
static int recsize(int lgsz)
{
-HashRec hr;
-hr.lgsz = lgsz;
-return (int)((char*)TAB(hr)[POW2(lgsz+1)] - (char*)hr);
+/* Union with the pointer for alignment purposes, to guarantee
+ * that the dummy HashRec has the same alignment as the malloc
+ * block that will eventually contain the real one. */
+union { void* align; HashRec hr; } u;
+u.hr.lgsz = lgsz;
+return (int)((char*)TAB(u.hr)[POW2(lgsz+1)]) - (char*)u.hr);
}
static HashRec* resize(struct naHash* hash)
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] New nasal drop, new syntax
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 inside the structure), hashes (about a
60% overhead reduction) and function closure objects (about 100 bytes
each).
As always, let me know what broke.
New syntax:
1. Call-by-name function arguments. You can specify a hash literal in
place of ordered function arguments, and it will become the local
variable namespace for the called function, making functions with many
arguments more readable. Ex:
view_manager.lookat(heading:180, pitch:20, roll:0, x:X0, y:Y0, z:Z0,
time:now, fov:55);
Declared arguments are checked and defaulted as would be expected:
it's an error if you fail to pass a value for an undefaulted argument,
missing default arguments get assigned, and any rest parameter
(e.g. func(a,b=2,rest...){}) will be assigned with an empty vector.
2. Vector slicing. Vectors (lists) can now be created from others
using an ordered list of indexes and ranges. For example:
var v1 = [a,b,c,d,e]
var v2 = v1[3,2]; # == [d,c];
var v3 = v1[1:3]; # i.e. range from 1 to 3: [b,c,d];
var v4 = v1[1:];# no value means to the end: [b,c,d,e]
var i = 2;
var v5 = v1[i]; # runtime expressions are fine: [c]
var v6 = v1[-2,-1]; # negative indexes are relative to end: [d,e]
The range values can be computed at runtime (e.g. i=1; v5=v1[i:]).
Negative indices work the same way the do with the vector functions
(-1 is the last element, -2 is 2nd to last, etc...).
3. Multi-assignment expressions. You can assign more than one
variable (or lvalue) at a time by putting them in a parenthesized
list:
(var a, var b) = (1, 2);
var (a, b) = (1, 2); # Shorthand for (var a, var b)
(var a, v[0], obj.field) = (1,2,3) # Any assignable lvalue works
var color = [1, 1, 0.5];
var (r, g, b) = color; # works with runtime vectors too
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [SECURITY] Nasal: io.open() restricted
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 software it loads from the local drive can certainly do local I/O if it wants without breaking typical security models. That's the whole idea behind being able to download software from the internet in the first place. :) My historical fear has been the interaction with the MP environment: the MP code can write to the property tree, and arbitrary property nodes have on various occasions be hooked to execute Nasal code. Being able to execute arbitrary Nasal code on another machine over the network would be a security disaster if that code could do I/O or spawn programs, etc... What Melchior has done is fine with me, architecturally. Ideally, I guess I'd prefer a sandbox on the other side: an architecture that expressly prevents network data from being executed somehow, probably by strictly limiting the areas in the property tree it can write to. But this kind of architecture can work too: it just requires that every potentially unsafe operation be sandboxed in the same way as I/O. Andy - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flying on the EDGE
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 wrong). The clamping to ambient is done as a safety valve only. The relevant code is in PistonEngine.cpp:244 if you want to take a look. Andy - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] valgrind diff no 2 and 3
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 just to delete the arrays. Fixed in CVS.
--- src/Scripting/NasalSys.cxx5 Dec 2007 10:57:51 - 1.97
+++ src/Scripting/NasalSys.cxx21 Jan 2008 21:30:11 -
@@ -317,8 +317,8 @@ static naRef f_interpolate(naContext c,
naRef curve = argc 1 ? args[1] : naNil();
if(!naIsVector(curve)) return naNil();
int nPoints = naVec_size(curve) / 2;
-double* values = new double[nPoints];
-double* deltas = new double[nPoints];
+double values[nPoints];
+double deltas[nPoints];
for(int i=0; inPoints; i++) {
values[i] = naNumValue(naVec_get(curve, 2*i)).num;
deltas[i] = naNumValue(naVec_get(curve, 2*i+1)).num;
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug#461399: simgear_1.0.0-1 (alpha/unstable): FTBFS: Unrecognized CPU architecture
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 for you, I really am. But you can either work with me to fix it or take potshots about trivial build problems and Heisenberg bugs that can't actually be exhibited. You and Steve picked the latter. I think he already provided the requisite defines, though somewhat buried in his mail. Beyond that, perhaps this web page would be of interest: http://predef.sourceforge.net/prearch.html No, someone needs to *run* this and *test* it on those architectures.* I'm not going to commit blind changes to either Nasal or SimGear. Since you can't actually run the code you are complaining about, someone needs to work with the command line Nasal interpreter from http://plausible.org/nasal to do the test. [* Something, I will point out yet again, that no one has done. Do either you or Steve have console access to a s390, Alpha, or PA-RISC box with 3D hardware? Has *anyone* ever run the Debian fgfs binary on those architectures?] And I'd very much prefer the gcc output I asked for to anything that comes out of a single individual's brain. This stuff is too easy to get wrong, and it's literally one command to run. Just run it and send me the output. Or don't, I guess. Your call. Andy - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug#461399: simgear_1.0.0-1 (alpha/unstable): FTBFS: Unrecognized CPU architecture
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 address space to userspace processes -- a short-sighted and groundless assumption, the reason Linux hasn't documented this rigorously is because there is no such guarantee. The NASAL_NAN64 option should be thrown out for all Linux variants. This is in the Nasal interpreter. Language interpreters routinely enjoy making some platform assumptions in the name of performance. In this case, that union trick chops the size of a naRef (and therefore the memory footprint of almost everything Nasal does) in half. I'm more than prepared to pay for this benefit in the form of the occasional dispeptic rant from uninformed distribution folks who are more interested in wagging their fingers at developers than they are in actually running the software [How's that for tone, Steve? I can flame with the best of them if you really want to throw down. Try a little less presumption next time.] As explained very clearly in the comments, all known platforms support this code just fine, and the benefits are very large. And I'm even conservative about refusing to compile on platforms on which I can't test, thus the #error (it's a feature, not a bug!). I'm happy to take patches, though. This support is trivially really easy to add, if Mr. Langasek is actually willing to help out a little. Just the output of echo | gcc -dM -E - on each of the platforms is sufficient. ... which is a cop-out, and a serious regression because the old code built and ran fine on all architectures. On all *debian* architectures. I had a ton of trouble getting the original stuff to work for everyone who wanted to use it. Manually enumerating architectures was the overwhelmingly simpler choice. I'm sorry you disagree. Andy - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] BUG: FG HEAD fails to compile after recent changes to configure.ac (reverting fixes it)
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 the commit was a complaint on the IRC channel by Hans that the OS X build had been broken for a long time, and that patches to fix that (the whole point here was to use the Apple-specific AC_CHECK_FRAMEWORK macro for the OSG libraries on OS X) had been ignored for weeks. I read it, nodded, tried it and committed. IMHO, it's better to have a little grief on the development list than leave an important user platform broken like that. Andy - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear prerelease; RPMs available + PATCH
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++ headers, you should stay with the existing convention. It's especially weird to add one of each. :) Andy - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Stutter/Nasal issue resolved (was: FlightGear/Plib periodic stutter notes)
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 the code that created the object can store a reference to it where the garbage collector can find it. For performance and simplicity, this list is stored per-context. When the context next executes code, it clears this list. Here's the problem: we do a lot of our naNewXX() calls in FlightGear using the old global context object that is created at startup. But this context is no longer used to execute scripts* at runtime, so as Csaba discovered, it's temporaries are never flushed. That essentially causes a resource leak: those allocations (mostly listener nodes) will never be freed. And all the extra reachable Nasal data floating around causes the garbage collector to take longer and longer to do a full collection as time goes on, causing stutter. And scripts that use listeners extensively (the cmdarg() they use was one of the affected allocations) will see the problem more seriously. * That's a feature, not a bug. Once listeners were added, scripts could be recursive: (script A sets property X which causes listener L to fire and cause script B to run) We need two or more contexts on the stack to handle that; a single global one won't work. I didn't like the fix though. Exposing the temporary bin as part of the Nasal public API is ugly; it's an internal design feature, not something users should tune. Instead, I just hacked at the FlightGear code to reinitialize this context every frame, thus cleaning it up. A proper fix would be to remove the global context entirely, but that would touch a bunch of code. Andy - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The Release
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* p){*(char*)p=0;}' tmp.c
$ gcc -S -c -o - tmp.c
Look! Instructions! I await your further pedantry about this
not really being a const pointer because of the cast, to which
I will reply that casts like this are precicely the subject of
discussion (hint: see olaf's patch)...
If it really concerns you, take it to plib-devel. It's not our
code. The question was whether the constness issues in the
released plib code are blocking bugs for a new FlightGear
release. As far as I can see, they are not. Plib's behavior in
the lines touched by this patch is platform independent.
Andy
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The Release
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 segments. And in any case I already mentioned (and dismissed) this possibility. From three posts above: I wrote: Are you maybe trying to say that plib is writing to a static string constant? That would be a pretty serious bug if true, but as far as I can see it's not. This flame war might be a whole lot more productive if people would stop trying to show off about their C knowledge and trying harder to figure out what the appropriate way to get plib to build under MSVC is... Andy - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] formatting in nasal
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 according to fairly standard representations. Just use them directly, no conversion is neccessary: var val = 2.3; var msg = The value of 'val' is: ~ val; If you need fancy formatting, like for example limiting the output precision, there is a sprintf() function available that works just like the ANSI one: var msg = sprintf(The value of 'val' is: %.2f, val); I'm not sure if the colon in 2:30 is a typo or not, but that's possible too with a bit of work: var frac = math.mod(val, 1); sprintf(Formatted: %d:%2.2d, val-frac, 100*frac); Andy - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The Release
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 with. Nonetheless we use plib. And plib's code has bad form and even the occasional bug. Since we use it, we need to build it. It was remarked at the top of this thread that plib 1.8.4 required a patch to build. I noted first that the patch seemed unnecessary (and only later noticed it was wrong), and suggested that the problem (in plib's code, not ours) could be fixed via adjustment of the warning level of the compiler instead. At which point all you guys in the peanut gallery jumped on me about bad form and I started swinging back. I think it's a reasonable argument, not one that needs derision. It is not a reasonable argument in this context, as it involves source code we don't control. And I'd argue the derision started in John's message, for what it's worth, but I suppose that's an issue of taste. The goal here, I will point out yet again, isn't to decide how best to develop plib, but to decide how best to get it built under windows for a FlightGear release. I'd argue that building our released version against an inconsistent library dependency constitutes significantly *worse* form than tolerating some const-incorrectness that has already been vetted out on other platforms. Andy - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] formatting in nasal
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 extracting things via math is going to cause precision glitches. As it happens, your example is affected by this: 2.3 is not exactly representable as an IEEE double. So you can get different results depending on code path. My example of multiplying it 100 actually doesn't work, because 100*2.3 comes out as 229.9. But if you really do have more than one value, don't be afraid of putting them into separate property nodes. They're cheap. Andy - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The Release
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 string, is getting the C implementation declared. I'm not sure where the C++ standard requires here. Arbitrary libc headers obviously need to pass through compatibly, but maybe there are special requirements for the ANSI headers. Unfortunatly they still miss MSVC8. Is the problem simply that VC8 has trouble? Isn't the obvious solution then to build with VC7 instead? If my memory serves, VC8 shipped with a new runtime that won't work on XP without an update, right? We probably want to build with the compatible compiler anyway. Regardless, you need to fix that patch if you want to see it used. Andy - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The Release
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 a release. But you're absolutely right: this looks like a plib bug to me too. You should re-submit that fix to the plib folks, not us. (And not as a MSVC8 build patch -- I wasn't looking for bugs in it, for example, and missed this one entirely). We can't fix plib bugs here, and if this isn't a showstopper for the release (it's not) posting it to a thread titled The Release and demanding that it be applied is probably going to confuse things more than help. And I still think that flightgear-devel is an inappropriate forum for discussion plib problems. Our goal here should be to get it building for the release, only. Note that all of this code has *already* been obsoleted in the CVS trunk anyway. After this release, it simply isn't possible for us to hit this bug, or any other problem with ssg, ever again. Andy - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The Release
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 distributables? Is such an arrangement GPL compatible? I know other projects have had to deal with this issue, but don't know the details. It does strike me as simpler to just use the older compiler. Andy - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The Release
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 affect the generated code. Sure, it would be good to get plib to fix their typing conventions, but I can't see why it would stop it from building, and in for the purpose of our release the distinction is meaningless. Andy - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The Release
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 *compile* time only. If MSVC is complaining about it, just adjust the warning level. Are you maybe trying to say that plib is writing to a static string constant? That would be a pretty serious bug if true, but as far as I can see it's not. Your use of strdup() is just adding an extra (and needless) step. Have you tried just adding a typecast instead? Again, the point here isn't whether or not plib's code is clean and will compile without warnings on MSVC. The point is whether it works the same as it does on our other platforms. Build issues are plib's problem, not ours. Andy - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Bug-Report] Stutterer and pauses withdynamic-view
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, and this is a new symptom. It's also, as you point out, threaded precicely for the purpose of *not* blocking the main rendering thread. Andy - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal variables
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 stack, and executing OP_LOCAL which does a hash table lookup to find the value in the namespace list and leave it on the stack for the next bit of code to use. Evaluating node.getValue() requires: Pushing the symbol node onto the stack Executing OP_LOCAL to look it up Pushing the symbol getValue onto the stack Executing OP_MEMBER to look it up in the object Executing OP_CALL to call it as a function Finally (!) calling the C++ property node function Turn the output node into a Nasal object and leave it on the stack. That said, you really don't want to be designing your scripts around raw, low-level performance issues. Write your code to be readable, not blazingly fast. In general altitude is more readable than altNode.getValue(). Andy - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal variables
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 name. It's part of the namespace of the executing function (which might be the whole file), and is visible only to the current function, and other func expressions assigned during that execution. and using the nodes var name = props.globals.getNode(/sim/model/aircraftName/someDirectory/name,1); and accessing with .getValue and .setValue. That's *also* a Nasal variable, but it holds a reference to a property node instead of an actual value. Interestingly, the property node, unlike the variable above, *is* a global thing (i.e. every part of FlightGear sees the same node for /sim/model/.../name). The advantage to Nasal-space data is that it's fast and simple. If the only thing that will care about the value is your script, they are good choices. The property tree is a inter-subsystem communication thing. This is what you want if you want to share data with the C++ world (for example, YASim control-output tags write to properties -- they don't understand Nasal), or read in via configuration files. Andy - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Programming Style
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, it's a bad idea. Read and internalize those, and then teach list comprehensions to a C programmer. The more curmudgeonly I get, the more I think everyone should just be coding in Nasal... Andy - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] spanning multiple columns in gui layout
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 significantly distorts the table. Here's the problem. You're giving your dialog a fixed size, then asking it to display something that doesn't quite fit. So it's shrinking the columns evenly, and things look wrong: !-- Control the weather -- nameweather/name width840/width height570/height Putting one word in each column only happens looks better because of the details of your layout and the length of your strings. Let the layout manager pick the size, that's what it's there for. Just remove the width and height lines and all will be well. Andy - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] spanning multiple columns in gui layout
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 you say it doesn't quite fit? Because I ran layout-test and watch it shrinking the size of the columns, then wondered why and discovered that you are giving the dialog an explicit size. That's just plain wrong in a layout dialog, unless you are attempting to do something fancy. An explicit width means make the dialog exactly this big. If you happen to give your table more content than it can fit, it takes the difference and subtracts it equally from each column. The working version just happens to look better because of the details of your layout; the extra width gets sunk into columns that happen not to need it, instead of spread evenly across the colspan range. The table code doesn't understand any of that and just shrinks all columns equally. Had you picked different strings to put in those columns, it might have looked equally bad or worse. Have you actually tried removing those two lines yet? I promise you it works. Andy - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] spanning multiple columns in gui layout
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 is, of course, up to you. I suspect this is a now a new bug report. Can you explain this problem for me (maybe with a screenshot or two) so that I can help you? Or are you happier to sneer and snipe and make me beg for details? Basically: check the ego at the door, John. Most of us here would actually like to help you (evening if helping you means encouranging you to use the layout manager instead of 1984-era hand-drawn dialogs). Spitting in our faces and playing ridiculous semantic games just isn't productive. Andy - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] spanning multiple columns in gui layout
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 and isn't used, despite the fact that it does and is. You even hid behind (no joke) a grammar excuse (as if colspan and rowspan are so different that one couldn't possibly be an example of the other, or that you couldn't think to grep for just span). When told that the core of the columns too small problem was your use of an explicit width and height, you bizarrely claimed that it wasn't, in clear contradiction to reality. At any of those steps, an appropriate response might have plausibly included the phrase thank you, or at least OK, but Instead, it's been one one redirection after another. I tell you one thing (*correct* advice, it should be noted) and am immediately hit back with a counterclaim. Basically, you've been a jerk from the beginning to end of this process and frankly I don't really want to work with you. Your contributions aren't valuable enough to be worth the emotional effort. Some jerks can prosper in collaborative projects because of the utility of their work (c.f. Melchior, Mathias, maybe me if I still count as a core developer). You aren't in that league, honestly, and you might find that a little humility would produce better service. But, all that being said: yes, you found a bug. The spans-are-too-wide problem* is caused by a sign bug when calculating the extra amount to distribute between spanned cells. Fixed in CVS. Andy * As distinct from the layout-is-too-narrow problem you reported earlier, or the there are no spans non-problem you originally reported. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] PATCH: building 0.9.11-pre1 on ppc
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 | gcc -E -dM - Yes I can. I'm building RPM on SUSE Linux. Ah, OK. Apparently GCC/linux and the OS X folks picked a different set of architecture symbols. Should be fixed in CVS (both branches, and in the Nasal upstream). Andy - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] PATCH: building 0.9.11-pre1 on ppc
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__ symbol, but I don't have a box to test against. If your compiler is gcc, can you post the results of: echo | gcc -E -dM - Thanks, Andy - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] AN-225 patch
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 hydraulic delays (which is what I think is happening here) you'd probably be happier with some Nasal anyway. Thus the semi-deprecated note: this feature still works as intended, but there are far more robust ways to solve the same problem in the modern environment. Andy - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG yasim-test build error - Possible Solution
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 libraries are known to the linker. This looks wrong to me. The yasim command line tool doesn't require anything from the FlightGear tree at all, and only the XML parser from SimGear. So far as I can tell, it builds for me without problem. I think you may have a library pollution issue; maybe a local change to one of your SimGear libraries is suddenly pulling in OSG code where before it stood alone? Andy - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG yasim-test build error - Possible Solution
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 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG yasim-test build error - Possible Solution
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 no revision 1.8 of that file in the cvs log AT ALL. When I do: cvs -d :pserver:[EMAIL PROTECTED]:/var/cvs/FlightGear-0.9 co source/src/FDM/YASim/Gear.hpp ... I get a file with no SimGear headers at all, just a class SGMaterial; declaration at the top. This is bizarre. Curt? Are there separate trees for this stuff? Andy - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG yasim-test build error - Possible Solution
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 SimGear include, as shown in the url to the cvs log in my previous mail. Indeed. Nonetheless, from a build just completed: $ ldd ./yasim libdl.so.2 = /lib/libdl.so.2 (0x2ac79e774000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x2ac79e878000) libm.so.6 = /lib/libm.so.6 (0x2ac79ea78000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x2ac79ebf9000) libc.so.6 = /lib/libc.so.6 (0x2ac79ed07000) /lib64/ld-linux-x86-64.so.2 (0x2ac79e657000) Those extra SimGear libraries don't require anything from OSG, except perhaps the compile-time headers. Are you doing anything fancy like building SimGear as a shared library? Andy - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Nasal in CVS
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 #define __func__ ??? #else #define __func__ __FUNCTION__ #endif #endif What version of the toolchain are you using? I was under the impression that that had already been vetted against MSVC, but might be wrong. compiles ok, but link fails Some functions defined in thread-posix.c (and used) are not defined in thread-win32.c I've forced the use of thread-posix, compile and link is ok now. That sounds wrong, a pthreads library shouldn't be required on windows. Can you provide the exact linker error you are seeing? Andy - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal iolib security
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 readfile() function to the module) you can write a loop that inspects all the local variables for functions (you can get the local variable hash as caller(0)[0]), and replace each one with a wrapper version that checks the calling file (again using caller()) against a blessed list. Then the problem becomes one of maintaining the blessing rules such that they are secure. We can try to handle the issue from the other side too: identify all the spots where strings come in from outside the $FG_ROOT directory and audit these to make sure they can never be used as a script. One *really* easy way to do this would be to override the compile() function in globals.nas with a non-functional version. But compile() is really useful in practice... Another option, obviously, would be to just disable the io module again. But I enabled it this time because a new release is still well-off, and this seemed like a good time for experimentation. Andy - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] New Nasal in CVS
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 of the truncated ones we now see. Vectors can now be concatenated using the ~ operator that used to work only for strings. Better runtime error messages in general due to a fancier naRuntimeError() implementation A big data size shrink on 64 bit systems; the size of a naRef dropped by a factor of two. Braceless code blocks have been added to the parser, so you can write expressions like if(a) b(); just like in C. Note that there's still a parser bug in there that fails when you nest a braced block within a braceless one. Character constants that appear in Nasal source code can now be literal multibyte UTF8 characters (this was always supported for string literals, but character constants were forced to be a single byte). New modules: bits, thread, utf8 and (gulp...) io. The bits library might be useful to FlightGear, the utf8 one probably not as Plib does not support wide character text rendering. The thread library will work fine for spawning threads to do Nasal stuff, but obviously contact with the rest of FlightGear must be hand-synchronized as FlightGear isn't threadsafe. The io library is no doubt the most useful, as it exposes all the basic stdio.h facilities; it's also frighteningly dangerous when combined with networked code... This almost certainly broke something, somewhere. Please be on the lookout for anything that looks like it might be an interpreter bug or new behavior. Likewise, let me know if any platform builds broke -- at the very least, MSVC project files are going to need to be updated for the new files. Andy - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textranslate Step and Scroll
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 seems reasonable enough, the *first* step
should be to repair the step feature so that it performs
rounding rather than truncation.
This subject came up on the IRC channel (which increasingly seems like
the only contact I have with you guys -- I'm not dead, really!) and
Ron sent me his bias patch for commit.
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. Can someone (ideally people who, unlike me, know
where to look for lots of step animations) try this completely
untested patch to simgear/scene/model/animation.cxx? It just
rewrites apply_mods() to do rounding (and IMHO to be clearer and
simpler):
--- simgear/scene/model/animation.cxx 2 Feb 2007 07:00:54 - 1.63
+++ simgear/scene/model/animation.cxx 7 Feb 2007 18:18:32 -
@@ -107,27 +107,14 @@
static double
apply_mods(double property, double step, double scroll)
{
-
- double modprop;
- if(step 0) {
-double scrollval = 0.0;
-if(scroll 0) {
- // calculate scroll amount (for odometer like movement)
- double remainder = step - fmod(fabs(property), step);
- if (remainder scroll) {
-scrollval = (scroll - remainder) / scroll * step;
- }
-}
- // apply stepping of input value
- if(property 0)
- modprop = ((floor(property/step) * step) + scrollval);
- else
- modprop = ((ceil(property/step) * step) + scrollval);
- } else {
- modprop = property;
- }
- return modprop;
-
+if(step == 0)
+return property;
+double bias = (property 0) ? 0.5 : -0.5;
+double result = step * (int)(bias + (property / step));
+double diff = result - property;
+if(fabs(diff) scroll)
+result = property + step * (diff / scroll);
+return result;
}
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textranslate Step and Scroll
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 case, isn't a single digit, it's the whole value. So you want to pass in the floating point value 29.92 and a step of 10 and get back 2, and *not* round up to 3. You want truncation for everything but the final digit, where rounding is more appropriate and the bias value is a useful workaround. So if there's a design flaw here, it's at a higher level. Maybe what's really needed is a digit extractor animation instead. Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] small bug in YASim-gears
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 surfaces like ice or water. Did I add this code? But I agree, taking those lines out looks right to me. Maybe this helps to solve the slipping of parked aircrafts (by adjusting sfric). Very unlikely. The slipping is a numerics effect, not a modeling one. The only way to get the gear jitter to produce a stable solution over time is to push the coefficients *down*. But that will produce more slipping, not less. The solution to this problem is a rewrite of the static gear friction to use a damped spring model around a stuck point. But that's hard for the case of rolling gear. Andy - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal hash question
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 assigned as
well as inspected. So it's just:
foreach(light; lights) { lightNodes[light] = propertyPath; }
Andy
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal problems on dual core cpu/64 bit linux
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 includes all possible Nasal paths) is single-threaded. So whatever synchronization bugs might live in the interpreter, we wouldn't be able to exercise them under the current architecture. Andy - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPL Violation?
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 he *is* a fully licensed reseller because he in in 100% compliance with the GPL. You are taking GPL incompliance as a postulate and then using that to argue that the fully licensed clause is a violation of copyright law. But you need to *prove* that incompliance first, otherwise this argument has no meaning. Seriously, folks: this is shady, but it's not illegal. The only problem I can see (which isn't itself a GPL violation) is that he doesn't recognize the copyright holders in the auction. Likewise, we should be sure that he's distributing the full source code (or the required written offer) along with the packages he offers for download. And relax, everyone: he's certainly not getting rich, and he's distributing FlightGear to people who might otherwise not have noticed us. That's a *good* thing for us, ecologically. Just send him a nice note asking that he put a link to flightgear.org in the auction, and make sure he's distributing the source. If he refuses, then let eBay know that he is distributing software without the permission of the copyright holder and refusing to accept the (very reasonable) terms we ask for. And let eBay make the decision as to whether this is legal or not. Andy - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPL Violation?
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 us, and is not licensed under the GPL. The GPL covers the software, not the page used to advertise it. Your interpretation would make *any* advertisement of GPL software illegal if it wasn't done by the copyright holder, and that's clearly non-sensical. Take a look at the ad banners on Slashdot, for example. Andy * Except, arguably, for the screenshots. But even there, I think you could make a very valid fair use argument that as long as your distribution is licensed, making screenshots for the purpose of advertising is fine. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] What does control gear/gear[0]/position-norm property in A-10?
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 elaborate nasal extensions; interpolate() is in there, for example. Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG Performance on WIndows
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 development on other parts of the system simply because you want to advocate OSG over plib isn't acceptable IMHO. If it's not ready yet for public consumption by the other developers (and, judging especially from the folks on IRC, it isn't) then it needs to live in a development branch until it *is* ready. This is too much, too soon, and with too little warning. + I don't like the OSG build system at all. Well every one of us should be allowed to have personal preferences, don't we ? ;-) Stop flaming. You cut out all the text where I explained *why* I don't like the build system. Building out of tree, en/disabling shared library support, and installing into a custom prefix aren't personal preferences. They are concrete software features, ones that I happen to use to build FlightGear, and ones that are lacking from OSGs makefiles. There are other nits too, like the fact that it wants to pass either -g or -O2 to gcc, and not both, or the fact that make static only works for the example programs. Certain things in FlightGear simply don't work with the latest PLIB release My point was that FlightGear will build and run successfully with a released version of Plib that you download from www.plib.org. This is not true of OSG. There is currently *no* version of OSG you can get from www.openscenegraph.com that will work with FlightGear. This is especially problematic because OSG ships only as shared libraries. If you happen to have a release version already installed on your system, then you can't build or run FlightGear *at* *all* without hacking with your runtime linker configuration. I accept that you don't like the move to OSG maybe simply because it's not your invention, I'll see your ad hominem and raise you three: You just don't like YASim! Thbbt! Neener neener poo poo! Flame on, I guess, Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG Performance on WIndows
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 without advantages. Let's have a little patience before we jump too far to conclusions. I, er, don't think you interpreted what I wrote correctly; check the double negative. :) And sure, patience is good and panic is bad. But at the same time: recognize that patience is limited, and there's a point at which panic is justified. It's already been almost two weeks since the OSG code started going in, and there still remain many issues. Performance under windows (but not linux, at least not my box) has suffered a serious 20-50% regression that can't be ignored. Several aircraft look just awful right now due to missing features. FlightGear can't be built easily by non-coders (at least those who can apply a patch to a CVS checkout) and can't be run at all on a system with OSG already installed (again, by a regular user). These are all regressions, not just bugs. They are things (important things, often) that used to work. Now, no one understands better than I do that you can't improve things without breaking stuff sometimes. But there's a limit. Stuff that's broken needs to be fixed, and it needs to be fixed very soon. The masses are restive out there. Honestly: I would have suggested putting the OSG code (and not the plib fallback) into a CVS branch and working on it as an experiment for a while. Doing in on the head* was too much breakage to absorb cleanly. Andy * And especially then trying to refuse new features on the plib branch, which is what got me into this fight. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG Performance on WIndows
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 (for example, to pick up bug fixes and new features -- this kind of back and forth happens every day on the IRC channel). The CVS head isn't just for code jockeys like us, and treating it like it is is a sure way to cheese off our content developers, as witnessed by this thread. Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG Performance on WIndows
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 issue is, in fact, exactly what got me into this thread. I'm fine with maintaining two branches in parallel while one stabilizes. But cutting off the working branch when the new one is still stabilizing is just wrong. Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG Performance on WIndows
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 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 will port changes that are checked : in to the branch to HEAD as long as these are only bugfixes. And, as I've said, I find this attitude unfair and counterproductive. And I'm clearly not alone. It's just not acceptable to break things and refuse to allow folks to see the fixes on their (working!) branch. Sure, someone could do it if they wanted. But hiding behind collaboration seems unfair to me, as if you guys are saying You want it to work? Fix it yourself. The content developers didn't break it. Look, this whole argument will go away if OSG starts working for everyone. If you want the complaints to stop, then get it fixed. If it's not, I can guarantee they're only going to get worse over time. I'll just say it: the OSG port is, as of today, an unmitigated disaster that should *never* have been applied to CVS in the state it is in. Apologies in advance if that offends someone. Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Linking 'fgfs' on FreeBSD
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 twelve (12!) distinct, inter-dependent shared libraries instead of just one? That's a huge waste of runtime linker cycles, and a big pain for developers. Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Linking 'fgfs' on FreeBSD
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 libosgText requires libosgSim anyway? It's just dumb, no one else does it, and it implies to me that the OSG developers don't know much about how to write shared libraries. Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Linking 'fgfs' on FreeBSD
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 not osgText. It should be able to link successfully without referencing osgText, right? Except that, as you discovered, it doesn't. That OSG insists on shipping C++ shared libraries is dumb enough. That they broke it down into 12 inter-dependent parts is just ridiculous. Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] What does control gear/gear[0]/position-norm property in A-10?
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 control=EXTEND prop=/gear/gear[0]/position-norm/ This instructs YASim to place the result/output value of the EXTEND axis of the gear object (not the same as the axis input -- it can be scaled or offset, and interpolated through a transition-time period) into the specified proprty. Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG Performance on WIndows
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 proper way to prevent people from wanting to use the Plib branch is to *fix* the OSG code. Whining about it is kinda bad form. People want to use the plib branch because it works better than the OSG branch, and they shouldn't be denied features just because it makes developers' jobs harder. This is a big, disruptive change, and I'm sympathetic to you, really. YASim and Nasal were big and disruptive too. But so far, OSG has produced literally zero benefit for anyone. People's experience has been anywhere between it seems to work OK to everything is slow and ugly to I can't get it to build!. For myself: + I don't like the OSG build system at all. Getting the equivalent of --prefix requires 5 non-standard environment variables to be set, and it doesn't support building out-of-tree. + It's freakin' huge! Takes longer to compile than the rest of FlightGear put together. + C++ shared libraries (12 of them). Enough said. I tried the make static option, but it didn't install the libraries properly. And the biggest complaint: + No released version of OSG works with FlightGear, nor does their CVS head. Technically, we're porting onto a *fork* of OSG right now. We never did this with plib: if we needed features from CVS plib, we'd still have compatibility code in place that work work with their releases. Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flightgear CVS and amd64
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 nvidia driver must be on 32bits . is it true? No. They have versions for both architectures. With a little care (or the appropriate distro package), you can even have them installed simultaneously to run 32 bit OpenGL apps (Google Earth) on a 64 bit desktop. Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Contribute with fixes
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 finds a few misfeatures that you hate. Then just start pulling things apart to see how they work, ask questions here or on the IRC channel, and have fun. Andy - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D model for the F-15
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 on a task in deference to someone else who will never finish it teamwork?. Teamwork requires that people actual *do* what they claim to be doing. This point was, I think, fairly well explained in the following paragraph to which you conveniently did not reply. :) Andy - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D model for the F-15
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 end up abandoned or stillborn. Just do your best, try not to blatantly step on anyone's toes, let people know what you are doing, and don't worry too much about duplicated work. Think of it as a darwinian development model: the fittest work survives. I want to release the models with a license that would prevent any commercial or military use. I think Creative Commons can do that but if you know anything else better ... Note that this will preclude shipping it with FlightGear, which is released under the GNU GPL. See the COPYING file in your data directory to see if those terms are acceptable to you. If not, you will have to distribute the files yourself, unfortunately. FWIW, the Creative Commons license (like the GPL) does not prohibit any particular users of the work either. It only covers the restrictions that the recipient can place upon further distribution. Andy - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] memory and smp
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 the yum installed FG and a local version built from sources. Has anyone encountered problems (or success) on dual processor systems? About two weeks ago, I posted a valgrind error log on the list, which you can find here: http://durktalsma.xs4all.nl/valgrind.log Note that both the X11 libraries and NVIDIA libGL implementation generate a huge stream of (apparently benign) uninitialized memory reads. You will need to filter them out if you want to get any use out of valgrind. But the general answer to your question is no: because of FlightGear's interactive nature and the performance hit from running under valgrind, we don't tend to run it on the fgfs binary*. So there are almost certainly some good bugs living in there for someone with the energy to find them. * Although some subsystems can be run independently. I did a valgrind round on the YASim solver a while back and plugged a few leaks, for example. Also, what video hardware and driver are you using, Lou? Note that there is a known issue with the X.org indirect OpenGL drivers that causes a crash on startup (not that indirect rendering will work anyway, but if you are seeing the crash you may not know this). As to SMP, it works fine. I'm now building and running FlightGear on a Core 2 Duo in 64 bit mode (Ubuntu Dapper amd64) without problems. FlightGear makes very poor use of the second CPU (our only extra thread is just doing I/O), but it runs correctly. Andy - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] memory and smp
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 *all* traces of FlightGear and SimGear from you system before doing a build from CVS. Version skew problems are probably the single most reported build error we see. :) Andy - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] coding style...
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 general rules that all styles adhere to. Most important in this case is indentation, your submitted file had none. Code in all modern programming languages has a recursive structure; some code blocks live inside other code blocks. It is a long-standing tradition that this structure be reflected in the indentation of each line of code: + Inner structures should have more whitespace at the beginning of the line than their enclosing blocks. + Lines that are siblings in the structure of the file should have exactly the same amount of whitespace. If you follow no other rule, follow this one. It's common to every sane programming style out there. Andy - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim feature request
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 gear, which was the source of the question, I believe. Yes, you can obviously sum multiple property inputs to that axis. Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim feature request
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 properties. For example, map the rear gear to /controls/flight/rudder, but use the src/dst mapping to invert the sense. The second aspect of the problem is that I can't find a reference property to use. Perhaps there's already something there and I'm not aware of it but even if there is, how would I relate it to the normalised steering control input? Here, you're off on your own. The default controls only give you aileron, elevator, rudder, throttle, mixture and advance as actual control axes. You can wire up a key mapping or cockpit control to drive any other property you want, of course, or you can modify your personal joystick mappings to redirect an unused axis (the Saitek robo-sticks tend to have a few rotary dials available, for example). Note, by the way, that the STEER input is in radians (1 radian ~= 53 degrees). Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fuel Weight dialog changes docs
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 currently disabled for JSBSim, but the interface is really very simple. The weight interface is trivial: if you can import a point mass into the FDM from a property named in configuration file (specifically /sim/weight[n]/weight-lb at the moment) then you can use this without change. The fuel stuff is only a little more complicated; the docs are at the top of Nasal/fuel.nas. But the essence is that the tank capacity and current fill need to be settable from script space via the /consumables/fuel/tank[n]/... property trees, and the engines need to export their consumption (currently YASim sets a fuel-consumed accumulator value, but we could make this work with a flow rate with some extra nasal). Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] CVS permissions issue in base package
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 denied cvs commit: ERROR: cannot write file /var/cvs/FlightGear-0.9/data/Aircraft/harrier/Panel/Hud/hud.nas,v: Permission denied /var/cvs/FlightGear-0.9/data/Aircraft/harrier/Panel/alt/alt.xml,v -- Panel/alt/alt.xml new revision: 1.2; previous revision: 1.1 cvs [commit aborted]: could not open lock file `/var/cvs/FlightGear-0.9/data/Aircraft/harrier/Panel/alt/,alt.xml,': Permission denied cvs commit: saving log message in /tmp/cvsLT83vx - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Fuel Weight dialog changes docs
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 hooked to the tab key. This seemed to overlap pretty badly with the existing Fuel Weight dialog, though, which was also intended to manage external stores from the GUI. So I spent a few hours and added the functionality to the existing dialog. This feature seems to be pretty underutilized, even for a lot of the aircraft for which it was intended. So in case anyone isn't aware of how it works, here are some docs: The FW subsystem is entirely property driven. In your -set.xml file you add a bunch of /sim/weight[n] definitions like: weight n=0 nameLeft Rear Passenger/name weight-lb0/weight-lb !-- initial/runtime value -- max-lb300/max-lb min-lb60/min-lb !-- optional, defaults to zero -- /weight This will get you a slider labeled Left Rear Passenger that you can tweak at runtime from the dialog. The FDM configuration would obviously read /sim/weight[0]/weight-lb to get the weight at runtime. You can also (this is the new feature) include a list of options and a initial selected property under the weight tag. This will cause the dialog to show a selectable combo box with only the named options you want: weight n=5 nameRight Wingroot/name weight-lb0/weight-lb selectednone/selected optnamenone/namelbs0/lbs/opt optnameAIM-9L Sidewinder/name lbs155.2/lbs/opt optnameAIM-120 AMRAAM/name lbs335/lbs /opt optnameALARM Anti-radar Missile/namelbs590/lbs /opt optname500lb Laser Guided Bomb/name lbs606/lbs /opt optnameExternal Fuel Tank/name lbs190/lbs /opt /weight Each opt property has a name and lbs sub-property. You set the selected proprty to the appropriate default (in this case none) and the subsystem code ensures that the weight-lb property is filled in correctly for the selected option. And now, the model animations can use the /sim/weight[5]/selected property to choose which model animations to draw at runtime. Anyway, as always let me know if I broke something or if there's something that needs to be added for it to be useful. A bunch of the existing aircraft could productively use this feature, I think. Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim feature request
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 engines honor their out-of-fuel properties the way you would expect. The default behavior, obviously, is to set this from current fuel state in fuel.nas, but that can be modified in a script. Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] YASim fixes from Maik / compatibility warning
Note to all YASim aircraft authors: the first fix discussed below is correct and has to be applied, but will (or at least may) have the effect of modifying the solution results of all YASim aircraft (tails are likely to be more effective: that means aircraft will be more stable on the whole, 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 [...] 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 was written. Here it (the patch) is. Applied. But before testing it with any YASim aircraft: I probably found another bug in surface.cpp. For general lift and flap-lift the effect of stall is calculated in stallFunc() resp FlapLift(). Yup, that looks correct to me. Applied. I'm not sure what the points was of the extra 1.0 in the return value; maybe a holdover from an earlier version where this function returned a scalar coefficient, and not a force? If the fuselage is large in comparison to the wing, this amount can be rather high. I don't think that's correct. As I read the code, you would get 1N of force per fuselage surface (of which there are maybe a few dozen across a large aircraft). The first bug is a whopper. This one is pretty much noise unless you're modeling an R/C aircraft; I'm not surprised it stayed hidden for so long. Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim fixes from Maik / compatibility warning
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 services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim fixes from Maik / compatibility warning
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-breaking solver change. :) andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] heli simulation update ready for cvs?
Maik Justus wrote: my impression was, that a stab is not producing forces perpendicular to its surface, when the wind is blowing perpendicular to its surface You have misinterpreted the code, I think. The stallLift value is only one contribution to the transverse force from the surface. Regular drag forces still apply, and I assure you they work. If they did not, YASim aircraft would not be stable when placed in zero-velocity situations like a hammerhead stall or similar situation where AoA goes through 90. The fuselage is simulated as a open tube and in the bo the resulting drag was to small I think. Therefore I added a vertical stab to close the tube at the beginning. This vertical slab I realized by an stab with 90 deg. incidence. There should be many other ways to do this without a vertical stab, but this way was self-evident for me. OK, I understand. But this is a hack. Your problem has nothing to do with surface incidence: your problem is that the fuselage drag is too low. Since the solver isn't run for helicopters, that isn't surprising. Why not investigate solutions that address the actual problem* and don't involve putting trig operations into the inner loop of the simulator? If you *really* need this feature and don't want to use one of the IMHO more general features above, can you provide it to me as a separate patch with change comments? It really isn't related to helicopters. The performance cost here is rather high, this code gets hit at 400 Hz for every surface in the aircraft (and there can be hundreds on a big plane). The small angle trick was being used for a reason, basically. * Suggestion A: an effectiveness parameter for fuselage tags that works like it does for wings, so you can tune it per-aircraft. Suggestion B: a new spheroid type that creates surfaces distributed in 3D around a center point instead of the 1D distribution you get from a fuselage tag. This would probably still need an effectiveness tunable, but will be much easier for authors of helicopters and airships to use than vstab objects. 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 was written. And unfortunately it affects *all* wings with segments that like between a control position and an edge. Which means that we're going to need to retest the solution results for basically every YASim aircraft once this goes in. Ick. :( As always, it's nicer to hear about bugs as bug reports, and not as anonymous changes in a 120k patch file. :) Can you (1) split this out into a separate patch as above, (2) add a comment explaining the two new entries in the table, and (3) write 10 instead of 8+2 (or BOUND_COUNT or sizeof(bounds)/sizeof(bounds[0]), etc...). Yes, I will change this. The lines [...] will be replaced by one function call. OK. But why must this be in Model.cpp? That class is a top-level wrapper that contains a bunch of sub-objects to do the real simulation; it doesn't have any aircraft-specific logic. Shouldn't this be part of a Rotor? If not, maybe you need another abstraction? (RotorShaft, maybe, by analogy to PropEngine?) The immediate complaint was that this was a lot of very special-purpose code inside my a small, general function. But the proximate issue remains: this seems like a lot of special-purpose code without an obvious home in the design. Abstraction is nice: it lets your changes go into files that you own (like Rotor*.?pp) without being torn apart by viscious folk like me. :) Of course I didn't want to change your comment. Yes, there is some integration done [...] the compensation of the rotation of the fuselage. The rotor does not follow the rotation of the fuselage. Therefore its rotation must be subtracted from the orientation of the rotor. I think, one could call this unstiff problems. Leaving a comment in place above your code that you disagree with seems kinda silly; I don't care if I wrote it or not. Pull it out and replace it with the above explanation of why this code is OK inside of initIteration() and does not need to be in calcForces(). A more general suggestion: isn't this a design bug with your choice of coordinates? The body is an accelerated reference frame. Wouldn't it be better to store the rotor orientation as a matrix in the global frame instead, the same way aircraft orientations are stored? Not only would you be able to skip this step, you would be immune to physics bugs caused by rapid rotations of the helicopter body. For debugging the rotor code I had switched the floating point exceptions on. But I got floating point exceptions exactly in the modified functions directly after starting the program, probably due to uninitialized variables somewhere else. OK
Re: [Flightgear-devel] heli simulation update ready for cvs?
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 stuff I don't like. There are no comments here on the Rotor* files. Those are 100% yours and really not my business to complain about. :) Explain why the changes to Surface.cpp are needed? The comments about stall lift are incorrect -- YASim does not attenuate lift at stall to zero. And why do you need incidence values to be non-small angles? If that's the requirement, then it would be better to have an implementation that can rotate the surface orientation instead. Doing it here loks like a hack. Do you actually need these changes for the helicopter code? Why? The boundary changes in Wing.cpp don't make any sense to me. You are adding two entries, but don't map them to anything. How is this change not a complete (and hard to understand) no-op? The changes to Model::calcForces() are just not acceptable. This routine should be a short, top-level wrapper for the force calculation (i.e. for each surface, set up parameters and calculate forces, then do the same for each engine, etc...). You have dumped a *TON* of quite clearly helicopter-specific logic right into the middle of this function. (Amusingly, you also broke my comment that reads end of engine stuff -- it now comes something like 100+ lines after the end of the engines). Can't this go into one of the Rotor* files? At the very least, get it out of calcForces(). Also, I notice that I had a nit-picky comment at the top of Model::initRotorIteration(). I know you read this comment, because you modified the function. But you don't seem to have addressed the concern. Either remove the comment if it is incorrect, explain to me why it's not a problem, or fix the code. :) The changes to RigidBody.cpp are just plain wrong. You appear to be trying to handle a divide-by-zero condition by testing the denominator. Which is sort of OK, if clumsy (AFAICT, neither of these situations can occur in practice -- please explain why you needed to fix these; I suspect you had some other bug). Unfotrunately, your fallback cases treat the infinity that gets produced as being EQUAL TO ONE! And, just in general, I wouldn't mind a little code cleanup. There are several spots where you have commented code out instead of removing it; I see a few places where you have more than one blank line in a row; your brace/whitespace/naming conventions don't always match the surrounding code, etc... I'm not a big zealot about this stuff, though (except for the commented-out-code issue -- that drives me nuts). Andy - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ASI: YASim Systems/pitot bug ?
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 want are the actual airstream velocity with direction, those are provided as a 3 element vector. If the gauge in the actual aircraft is bidirectional, it's probably because it's a special design and you'll need to model that separately. Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Nasal mailing list
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 been) enough of these folks over the past few years that it would be worth having an archived mailing list where they could discuss things without my having to intermediate and inject my opinions*. Anyway, those interested can subscribe at the above URL. Obviously, FlightGear-specific questions can still be targeted here, or to the IRC channel, etc... Andy * I've now explained why adding ++ and -- operators is too hard for the fourth or fifth time. With more folks to argue, someone might show me an easier way. :) Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal mailing list
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 at plausible.org/nasal Andy Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim vstab question
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 will tilt it 30 degrees to the right of vertical, but (and this is important) the up/down sense of its flap surfaces will be reversed. Andy Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Incidence in YASim
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 I picked a non-degree angle unit, it would be in radians. Andy Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim altitude agl
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 point for the altitude and the lowest contact point value of the gears as the agl value. That was intended as a feature, actually. The value you want can, obviously, be gotten by a single subtraction. But if you want to implement, for example, a cockpit altitude enunciator or radar altimeter, you will need the value computed from the gear position. I have no problems with the proposed patch, although I'd strongly suggest keeping the current value and setting it into a gear-agl-m property or somesuch. Someone will no doubt want it. Andy ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance monitoring
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 eamine the resulting gmon.out file. Note that performance tuning is a black art, and that the numbers you see are going to be lying to you in subtle ways, especially if you have the optimizer turned on. And you probably aren't going to be able to use it to profile a real time application (like FlightGear) very well at all. Andy --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OT: ebay
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. So long as the seller doesn't misrepresent the item (the pictures of physical cockpits in the listing had me a little worried) or claim authorship, then this is entirely within the bounds of the license. The only suggestion I would have is that they be more active and let us know about this sort of thing; it's normally considered courteous to let someone know before trying to sell their software. :) Andy --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] collision detection.
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, etc.). I don't remember how it works in YASim. Pretty much the same, except that you get contact points generated for you at the tips of all the surface and fuselage objects. It's been my experience that this works really well, so there's no configuration file hook for adding your own. I think the original report might have been that you can bury a fast moving aircraft under the ground. The 100 Hz granularity of the FDM computations isn't able to detect the exact moment of collision. That's a much harder issue to solve; you'd have to extrapolate backwards to make it work. Andy --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal infinite loop?
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. Property node state variables are almost certainly on the stack in the code above the listener call, and your changes are making them inconsistent with the actual node in memory. It's possible, but difficult and error-prone, to write code that permits this sort of thing. But almost certainly a better design would be to separate the nodes that are changed by a listenener from the nodes whose change causes a listener to fire. Andy --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
