Re: [Flightgear-devel] [flightgear-devel]
Behlül UÇAR wrote: Is there an exact version of newmat library which i need to download? Maybe i need to download it. The 'newmat11.tar.gz' should be fine (240888 bytes). Behlül UÇAR wrote: By the way, i'm trying to compile terragear-cs which i downloaded from cvs of flightgear. I also installed simgear-cs for it. Are you certain that you've got both of them via CVS ? As far as I can tell, they're available via GIT only. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [flightgear-devel]
U're correct i meant git, http://mapserver.flightgear.org/git/ 2009/9/2 Martin Spott martin.sp...@mgras.net Behlül UÇAR wrote: Is there an exact version of newmat library which i need to download? Maybe i need to download it. The 'newmat11.tar.gz' should be fine (240888 bytes). Behlül UÇAR wrote: By the way, i'm trying to compile terragear-cs which i downloaded from cvs of flightgear. I also installed simgear-cs for it. Are you certain that you've got both of them via CVS ? As far as I can tell, they're available via GIT only. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Looking around while paused (FGViewMgr)
James Turner wrote: A good lesson in how different people use different interfaces to the same functionality, and see different things :) plus an interesting lesson about one and the same feature behaving differently depending on which control you use ;-) Chheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [flightgear-devel] cmdarg() function
Hi, I'm trying to create a route manager GUI which will store unlimited number of points with some extra parameters. For this reason, I've investigated $FG_ROOT/data/gui/dialogs/route-manager.xml file. At line 28 column 36, I saw a function named cmdarg(). I couldn't find any information about this function in the documentation. Can someone help me understand what it is for? By the way, it would be perfect if there was a good nasal library documentation which explains all the functions defined for flightgear :) Greetings -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [flightgear-devel] cmdarg() function
On 2 Sep 2009, at 13:45, Behlül UÇAR wrote: Hi, I'm trying to create a route manager GUI which will store unlimited number of points with some extra parameters. Hmm, what are you planning? I have some C++ changes to route-manager (almost a re-write) which make it work quite differently (but closer to how route/leg navigation works in real-world devices such as FMSs). The code works locally but it's not really suitable to commit to CVS, since it breaks the existing GPS functionality for some popular aircraft. I made some modifications to the route-manager dialog myself, but I found some limitations in the PUI widgets that make creating a good interface difficult, so I stopped working on that part. Cheers, James -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [flightgear-devel] cmdarg() function
Actually I'm planning on making a GUI which the user can enter unlimited number of points and 3 extra parameters with that points. After storing that points I want to make two controls. First control is a route control between the points (one-by-one, every point is appended the last point in the chain). Second control is the vertical and airspeed control on those entered points. For this reason, I thought first I have to store all the points like route-manager does but my storage system will be a little different because i need some extra parameters too. I'm open to any ideas and any help in this issue. Greetings. 2009/9/2 James Turner zakal...@mac.com On 2 Sep 2009, at 13:45, Behlül UÇAR wrote: Hi, I'm trying to create a route manager GUI which will store unlimited number of points with some extra parameters. Hmm, what are you planning? I have some C++ changes to route-manager (almost a re-write) which make it work quite differently (but closer to how route/leg navigation works in real-world devices such as FMSs). The code works locally but it's not really suitable to commit to CVS, since it breaks the existing GPS functionality for some popular aircraft. I made some modifications to the route-manager dialog myself, but I found some limitations in the PUI widgets that make creating a good interface difficult, so I stopped working on that part. Cheers, James -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Source code control systems
Source code control systems are close to religious topics for many people so I want to avoid potential panic here. I understand that due to the diversity of opinions within our developer community, it will be impossible to reach any kind of consensus for any action. Even the default of no action is controversial. :-) My goal here is to not debate the final solution, but hopefully find some agreement so we can move a step forward, and from that new position, we will be in a better position to discuss future options. So to start out, I think most of us agree that CVS is old and clunky and there are a variety of better options available. In addition, I am self hosting our master CVS repository which means that if my machine breaks, I personally am on the hook to drop everything else and do whatever it takes (ranging from hardware, to OS, to security, to whatever ...) to find and fix the problem before we can get our repository back online. What if I happen to be on vacation or on a work trip or get hit by the proverbial beer truck and then a problem develops with the server? To add new developers, I personally need to manually create accounts, adjust group membership, etc. again if I'm out of town or in the midst of some crazy work deadline, there could be substantial delays. In addition, I have a remote backup system in place for our CVS server, but that is another self managed system and earlier this summer the backup system failed and all the backup data was completely lost, leaving us with just a single primary copy of the main repository until I could get the backup system back up and running again (which it is now.) These are all things that could be improved on and streamlined. From my perspective, these administrative issues are of equal importance to discussing which specific version control system we might step to. All of these things need to be considered together when determining a route forward. What I propose is that we migrate our self hosted CVS repository to code.google.com and in the process convert to SVN. 1. This gives us professional management of the servers, regular professional backups, and an automatec access control system for adding new developers. Google has a tremendous amount of bandwidth and compute power behind their systems, way more than I could ever offer on any self hosted system. When something breaks on a google server, there is a pool of people available and qualified to fix the problem. On any self hosted system (no matter how well run) there is usually only one person who could jump in and fix a potential problem. 2. We need to move away from CVS somehow. SVN is a big improvement (but yes, I realize many of our developers think that going direct to some other system will be an even bigger improvement.) Let me just offer that this doesn't have to be the final destination. It may just be a step forward in our journey. Please, please don't panic! I suspect that building a gateway between SVN and other systems should be easier and more transparent than a gateway between CVS and the other system given that SVN has more capabilities than CVS. 3. I have prototyped the migration system with the SimGear repository and I think it went pretty smoothly. Here is the link: http://code.google.com/p/simgear/ 4. code.google.com also offers a bug tracking system that we could begin to use. 5. SourceForge offers many of these same things, however, it is awfully slow. Google seems to be so much leaner and faster to do everything. After navigating the google site for a while, it's really tough to go back and try to plow through sourceforge which seems so much slower and clunkier in comparison. I think that when balancing both the administrative and technical aspects of the issues, code.google.com offers a pretty good step forward and enables us to cleanly step away from the old CVS-based, self-hosted system, so that is what I would like to do. It would be great if some of our developers could look through the simgear projects site on code.google.com: http://code.google.com/p/simgear/ Run through the process of checking out the code. Browse the changes, browse the repository tree layout, browse the revision history etc. Does the conversion process look like it worked well? Is everything there? The one thing I don't yet have is support for a changelog mailing list, but I suspect there are easy hooks for setting this up, and in addition, google provides several RSS feeds for monitoring changes to different aspects of the project (including source code changes.) I think this will be a good step forward for our project. I think once the transition is complete we'll be in a more solid position to be able to debate possible further moves forward at that time. I do expect a diversity of responses to this, but there's nothing wrong with diversity, right? :-) Thanks, Curt -- Curtis Olson: http://baron.flightgear.org/~curt/
Re: [Flightgear-devel] Source code control systems
Curtis Olson wrote: What I propose is that we migrate our self hosted CVS repository to code.google.com and in the process convert to SVN. 1. This gives us professional management of the servers, regular professional backups, and an automatec access control system for adding new developers. I'm very much convinced that we're able to perform proper administration of 'our' repository via a selected group of admins. Just look at OSGeo where only a small group of volunteers is successfully maintaining quite a couple of critical services over years !! without depending on so-called professional management. Not the lack of ressources is holding us back from maintaining the repository ourselves, instead this is nothing but a mental 'issue' (TM). The most obvious drawback of your current approach with setting things up at Google is the simple fact that you're making an unbiased decision about FlightGear's future SCM almost impossible. Only a fool would expect a chance to change things after they're set up and running. 2. We need to move away from CVS somehow. SVN is a big improvement (but yes, I realize many of our developers think that going direct to some other system will be an even bigger improvement. Thats quite belitteling. The fact is that a lot of developers are already _using_ some other system right now ! [...] I suspect that building a gateway between SVN and other systems should be easier and more transparent than a gateway between CVS and the other system given that SVN has more capabilities than CVS. Well said especially given that SVN is much less prone to silent transission errors compared to CVS ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] navradio.cxx
Is this good? It seems to be :) I had problems with GPSes before, as the CDI would just reset to zero and even if the CDI course is the same as the GPS bearing, the A/P won't follow the course, instead following the heading bug. Which is strange, because if NAV1 isn't set to be slaved to GPS, the A/P follows the VOR course normally. I've just committed a large patch to the navradio code, which re- structures the code, with the aim of increasing the readability (and maintainability) significantly. This is in preparation for some other changes, especially making the 'NAV/GPS switch' function more explicit, and hopefully removing any knowledge of GPS-type systems from the nav-radio proper. I've tested this locally for several days, but the code is full of conditionals - for GPS-coupled operation, ILS/LOC operation with and without glide-slopes, and many other similar things. Working on the basis that I will only encounter a subset of cases myself, I'm committing it with the promise to fix any problems that crop up ASAP. Note that some things which were subtly broken before, are now more obviously broken: notably GPS-slaved-glideslopes (which has a prior FIXME). Similarly, I've made no attempt to fix any particular behaviour of the code - if it behaved a certain way before, it should be exactly the same now, for better or worse! Regards, James -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Source code control systems
Hi Curt My only concern with SVN is that it stores every file twice in the local file system, so it's not ideal for the 'data' portion of FlightGear. For example, right now a complete checkout of Aircraft is ~ 2 GB, and it would double overnight. I know, disk space is cheap in these days, but the double-write also results in slower checkouts. In other words, I think we should import FlightGear as well into code.google.com and see if we are happy with the performance before jumping. Apart from this concern, I've used CVS, SVN and GIT and I'm not religious about the choice. In the end, any tool will work as long as it's: - fast - easy to use - well integrated with other tools like bug tracking SW - and this is very important IMHO (you have bugs referring to check-ins, check-ins referring to bugs, RSS feeds of changes, etc ...) Tom Curtis Olson wrote: Source code control systems are close to religious topics for many people so I want to avoid potential panic here. I understand that due to the diversity of opinions within our developer community, it will be impossible to reach any kind of consensus for any action. Even the default of no action is controversial. :-) My goal here is to not debate the final solution, but hopefully find some agreement so we can move a step forward, and from that new position, we will be in a better position to discuss future options. So to start out, I think most of us agree that CVS is old and clunky and there are a variety of better options available. In addition, I am self hosting our master CVS repository which means that if my machine breaks, I personally am on the hook to drop everything else and do whatever it takes (ranging from hardware, to OS, to security, to whatever ...) to find and fix the problem before we can get our repository back online. What if I happen to be on vacation or on a work trip or get hit by the proverbial beer truck and then a problem develops with the server? To add new developers, I personally need to manually create accounts, adjust group membership, etc. again if I'm out of town or in the midst of some crazy work deadline, there could be substantial delays. In addition, I have a remote backup system in place for our CVS server, but that is another self managed system and earlier this summer the backup system failed and all the backup data was completely lost, leaving us with just a single primary copy of the main repository until I could get the backup system back up and running again (which it is now.) These are all things that could be improved on and streamlined. From my perspective, these administrative issues are of equal importance to discussing which specific version control system we might step to. All of these things need to be considered together when determining a route forward. What I propose is that we migrate our self hosted CVS repository to code.google.com http://code.google.com and in the process convert to SVN. 1. This gives us professional management of the servers, regular professional backups, and an automatec access control system for adding new developers. Google has a tremendous amount of bandwidth and compute power behind their systems, way more than I could ever offer on any self hosted system. When something breaks on a google server, there is a pool of people available and qualified to fix the problem. On any self hosted system (no matter how well run) there is usually only one person who could jump in and fix a potential problem. 2. We need to move away from CVS somehow. SVN is a big improvement (but yes, I realize many of our developers think that going direct to some other system will be an even bigger improvement.) Let me just offer that this doesn't have to be the final destination. It may just be a step forward in our journey. Please, please don't panic! I suspect that building a gateway between SVN and other systems should be easier and more transparent than a gateway between CVS and the other system given that SVN has more capabilities than CVS. 3. I have prototyped the migration system with the SimGear repository and I think it went pretty smoothly. Here is the link: http://code.google.com/p/simgear/ 4. code.google.com http://code.google.com also offers a bug tracking system that we could begin to use. 5. SourceForge offers many of these same things, however, it is awfully slow. Google seems to be so much leaner and faster to do everything. After navigating the google site for a while, it's really tough to go back and try to plow through sourceforge which seems so much slower and clunkier in comparison. I think that when balancing both the administrative and technical aspects of the issues, code.google.com http://code.google.com offers a pretty good step forward and enables us to cleanly step away from the old CVS-based, self-hosted system, so that is what I would like to do. It would be
Re: [Flightgear-devel] Source code control systems
On Wed, Sep 2, 2009 at 2:02 PM, Tom P zomm...@gmail.com wrote: Hi Curt My only concern with SVN is that it stores every file twice in the local file system, so it's not ideal for the 'data' portion of FlightGear. For example, right now a complete checkout of Aircraft is ~ 2 GB, and it would double overnight. A quick check of the 'data' repository reports it's size is about 5Gb. Presumably with a distributed source code control system, each end user would be downloading this much data + the disk space foot print would be at least this much (+ maybe the extra 2Gb for a working copy?) Is this an argument to stay with CVS for the data portion of the project? This is a good point to bring up though in advance. The default project quota at code.google.com (is there a shorter abbreviation?) is 1Gb so we'd be fine for SimGear and FlightGear code, but we'd blow way over that for data. I know, disk space is cheap in these days, but the double-write also results in slower checkouts. In other words, I think we should import FlightGear as well into code.google.com and see if we are happy with the performance before jumping. Part of the goal of my original post was to have people take a look at SimGear in google/svn form to see if there were any major oversights in the migration process before we make any actual move. But certainly the large size of the data is an additional dimension to test. Apart from this concern, I've used CVS, SVN and GIT and I'm not religious about the choice. In the end, any tool will work as long as it's: - fast - easy to use - well integrated with other tools like bug tracking SW - and this is very important IMHO (you have bugs referring to check-ins, check-ins referring to bugs, RSS feeds of changes, etc ...) I noticed google has an interesting system (which I haven't explored in detail) that allows users to rate individual commits as positive, neutral, or negative, with the option to leave comments. Any changes to the tools also implies some changes to the typical workflow, but code.google.com has some nice features. It also supports mercurial (hg) which might be an option for the future if we decide a distributed source code management system is the better way to go. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Source code control systems
On Wed, Sep 2, 2009 at 4:02 PM, Tom P zomm...@gmail.com wrote: Hi Curt My only concern with SVN is that it stores every file twice in the local file system, so it's not ideal for the 'data' portion of FlightGear. For example, right now a complete checkout of Aircraft is ~ 2 GB, and it would double overnight. I know, disk space is cheap in these days, but the double-write also results in slower checkouts. In other words, I think we should import FlightGear as well into code.google.com and see if we are happy with the performance before jumping. Apart from this concern, I've used CVS, SVN and GIT and I'm not religious about the choice. In the end, any tool will work as long as it's: - fast - easy to use - well integrated with other tools like bug tracking SW - and this is very important IMHO (you have bugs referring to check-ins, check-ins referring to bugs, RSS feeds of changes, etc ...) I've used a few as well, though not Mercurial (the other available system on Google Code). I'm partial to git, and if mercurial is similar (which I believe it is), it's a lot more robust than SVN. It might make sense to go directly to Mercurial (maybe going through SVN, then Mercurial, if the tools are better for that). Even if the distriguted aspect were not an issue (I believe it is!), SVN is lacking in some aspects. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] pilot list error
As I mentioned before , I've been looking for the missing player in the
pilot list and model view.
If I comment out the 2 lines below foreach , in multiplayer.nas at line
374 ...
foreach (var n; props.globals.getNode(ai/models,
1).getChildren(multiplayer)) {
#if (!n.getNode(valid, 1).getValue())
# continue;
... I then get the correct num-players in /ai/models, and I can now step
through ALL the players in model view ,
and they all appear in the pilot list.
I don't consider this a fix since I dont know why the above lines would
cause a problem,but it's a start.
Cheers
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Source code control systems
Curtis Olson wrote: Is this an argument to stay with CVS for the data portion of the project? I've been loosely monitoring the 'quality' of CVS checkouts for some time now and to my experience the number of silent transmission errors is most significant with the data repository. Therefore I don't think that staying with CVS for the data repo is a good choice. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Source code control systems
On Wed, Sep 2, 2009 at 4:19 PM, Curtis Olson curtol...@gmail.com wrote: On Wed, Sep 2, 2009 at 2:02 PM, Tom P zomm...@gmail.com wrote: Hi Curt My only concern with SVN is that it stores every file twice in the local file system, so it's not ideal for the 'data' portion of FlightGear. For example, right now a complete checkout of Aircraft is ~ 2 GB, and it would double overnight. A quick check of the 'data' repository reports it's size is about 5Gb. Presumably with a distributed source code control system, each end user would be downloading this much data + the disk space foot print would be at least this much (+ maybe the extra 2Gb for a working copy?) Is this an argument to stay with CVS for the data portion of the project? When using a distributed system it's not necessary to download the entire history, it's just fine to download just the last revision and work from there. In any case, I would bet Hg is more space efficient than CVS. This is a good point to bring up though in advance. The default project quota at code.google.com (is there a shorter abbreviation?) is 1Gb so we'd be fine for SimGear and FlightGear code, but we'd blow way over that for data. I'm not sure how well Hg can handle binary data, it might be a good idea to keep that elsewhere anyway for other reasons. All current SCCM allow for separate servers for different parts. Matias D'Ambrosio -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Source code control systems
On Wednesday 02 September 2009 22:44:56 Tom P wrote: Yes, I agree, a distributed system is overkill for the data portion. I would disagree... 1) data is handled well by a lightweight client-server model (either CVS or SVN) that: - allows users and developers to synchronize their local data set, simply and quickly With the data tree, we frequently have several people working on the same area (aircraft models, in particular) - not only that, but many of the people working on aircraft models have historically not had any kind of commit access to the main repository. The line between user and developer is very blurred in the data tree... which is why something like git seems to me to be perfectly suited to the job. As I see it, switching to a distributed model such as Git would allow people like me who have no commit access to the main repo to maintain their own work under a nice version control system, greatly improve the ease of collaboration with other people working on the same models, and reduce the need for each individual modeller to have full commit rights (by making merging so much easier for those who do have them). I switched to using the mapserver git repo for the data tree quite some time ago, and the improvements for a modeller like me were massive. No more lost work (I often had CVS completely botch my local changes), and all my own local changes nicely version controlled with an easy to follow history. - doesn't need advanced support for branching and merging I would strongly disagree with that, from several years' experience collaborating on models for FG... In case it wasn't clear by now... I think we should be using git for both source and data - as previously mentioned, many (if not most) FG developers are already using it (though missing many benefits that would arise from the main repo being git). Cheers, AJ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] navradio.cxx
On 2 Sep 2009, at 19:55, Victhor Foster wrote: Is this good? It seems to be :) I had problems with GPSes before, as the CDI would just reset to zero and even if the CDI course is the same as the GPS bearing, the A/P won't follow the course, instead following the heading bug. Which is strange, because if NAV1 isn't set to be slaved to GPS, the A/P follows the VOR course normally. GPS integration at the moment is confused - some aircraft (especially those done by Syd), the GPS works, sometimes with some Nasal scripts to provide / work-around features the C++ code lacks. I've got a re-write of the GPS code locally, which needs testing, and works in *one* aircraft (with some minor modifications to that aircraft's data files) - the problem is making it work in enough aircraft that people don't complain. Autopilot integration is part of that, although mostly the NAV autopilot modes slave to the CDI course, which the GPS can drive (when the NAV/GPS switch is set to 'GPS', naturally). Regards, James -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Source code control systems
Tom P wrote: Well, it's more an argument in favor of splitting the data and source code, like it's already the case for the Scenery http://code.google.com/p/terrascenery/ Terrascenery is a somewhat special case in that it has almost just one single, automated feed, it is destined to never require any review before commit, will likely never see a branch and therefore doesn't fit well as a comparison in the context of the current discussion. Just for the record: Pulling Scenery from an SVN repository requires a little bit more than twice the local disk space compared to the net size of the respective content - which is almost the same ratio as with GIT, at least for stuff like the Base Package. And here's a page comparing SVN, GIT and Mercurial. It's light on details but might help a bit with the decision: http://www.russellbeattie.com/blog/distributed-revision-control-systems-git-vs-mercurial-vs-svn Well, this article was written more than two years before now, when GIT as well as Mercurial had been quite young projects. Much has changed until now. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Source code control systems
Hi, In case it wasn't clear by now... I think we should be using git for both source and data - as previously mentioned, many (if not most) FG developers are already using it (though missing many benefits that would arise from the main repo being git). Cheers, AJ I can only agree to AJ- CVS is often a pain, I use GIT for my aircraft develope and I'm happy with it. I was forced to use CVS again after my HD crash- what a pain to use... Regards HHS -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Source code control systems
Hi AJ, hi Martin
I see the advantages of GIT, no need to be convinced of that.
And I've had a look at the GIT projects on mapserver, very nice, and
it's already split into source and data!!!
But let's say that the project switched completely to GIT, would there
be a way to support streaming scenery ('terrasync') to the user without
him/her needing to clone the entire fgdata repository ?
Something like git-svnserve?!?
Tom
AJ MacLeod wrote:
On Wednesday 02 September 2009 22:44:56 Tom P wrote:
Yes, I agree, a distributed system is overkill for the data portion.
I would disagree...
1) data is handled well by a lightweight client-server model (either CVS
or SVN) that:
- allows users and developers to synchronize their local data set,
simply and quickly
With the data tree, we frequently have several people working on the same area
(aircraft models, in particular) - not only that, but many of the people
working on aircraft models have historically not had any kind of commit
access to the main repository. The line between user and developer is very
blurred in the data tree... which is why something like git seems to me to be
perfectly suited to the job.
As I see it, switching to a distributed model such as Git would allow people
like me who have no commit access to the main repo to maintain their own work
under a nice version control system, greatly improve the ease of
collaboration with other people working on the same models, and reduce the
need for each individual modeller to have full commit rights (by making
merging so much easier for those who do have them).
I switched to using the mapserver git repo for the data tree quite some time
ago, and the improvements for a modeller like me were massive. No more lost
work (I often had CVS completely botch my local changes), and all my own
local changes nicely version controlled with an easy to follow history.
- doesn't need advanced support for branching and merging
I would strongly disagree with that, from several years' experience
collaborating on models for FG...
In case it wasn't clear by now... I think we should be using git for both
source and data - as previously mentioned, many (if not most) FG developers
are already using it (though missing many benefits that would arise from the
main repo being git).
Cheers,
AJ
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Source code control systems
On Thu, Sep 3, 2009 at 12:17 AM, AJ MacLeodaj-li...@adeptopensource.co.uk wrote: In case it wasn't clear by now... I think we should be using git for both source and data - as previously mentioned, many (if not most) FG developers are already using it (though missing many benefits that would arise from the main repo being git). I agree completely. Moving to an intermediate svn would hinder that progress again. -- Csaba/Jester -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [DRAFT] generic input devices and hotplug support
Hi, Attached is a patch for FGMacOSXEventInput.[ch]xx Torsten, Could you commit it with the following comments: - Fixed: wrong event name for abs-hat0-y Modified: let AxisElement to generate normalized input (-1.0 to 1.0). This can be temporal and can be removed when AxisEvent normalizes its value. Modified: clean up code Added: some comments so other Mac developers can see what's going on - By the way, I found some differences between Linux and Mac OS X implementation, and want to hear some idea on how to eliminate the differences. 1. button index in FGLinuxEventInput.cxx the button index for misc usage begins from 0, but in USB specification, the index for button (on Button Usage Page) begins from 1 (same in FGMacOSXEventInput.cxx) This difference affects the compatibility (among OSs) of event configuration files. So I'm wondering which way we should follow. Maybe we should follow the linux way since it's easier to convert the existing joystick configuration files into new event configuration files. (button index in a joystick configuration file also begins from 0) What do you guys think? 2. event names for buttons of mice, joysticks (for generic desktop page), and gamepads At this moment, there's no button-left, button-right, etc in Mac OS X implementation. The same is applied for gamepad buttons, and joystick buttons. Instead, the button events are named like button-N regardless of device type. I guess it is easier to assign names in button-N format, but if we really need to clearly state button-left, or button-right, button-a, or button-trigger instead of button-N, then I'll add some code to generate these. I want to note that it is doable on Mac OS X by checking CA type of HID usage, but I'm not so sure if it is one-to-one relationship among HID usage and button names in all devices. if not, we must not use the linux way. We also needs to consider the possible Windows implementation. Any idea on this? Thanks in advance, Tat FGMacOSXEventInput.diff Description: Binary data -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
