Re: [Flightgear-devel] Windows Problem with the Latest GUI Code
From: "Jonathan Polley" <[EMAIL PROTECTED]>
> I updated to the latest CVS for both FlightGear and the base packages
> and am having a problem under Windows (MacOS X is working correctly).
> The module src/new_gui.cxx runs and starts reading the XML files but
> starts getting into trouble. I get the following errors printed to the
> screen
>
> Error parsing GUI file c:\fgdev\fgfsbase\gui\dialogs\.
> GUI file c:\fgdev\fgfsbase\gui\dialogs\. has no name; skipping.
> Error parsing GUI file c:\fgdev\fgfsbase\gui\dialogs\..
> GUI file c:\fgdev\fgfsbase\gui\dialogs\.. has no name; skipping.
> Error parsing GUI file c:\fgdev\fgfsbase\gui\dialogs\CVS\.
> GUI file c:\fgdev\fgfsbase\gui\dialogs\CVS\. has no name; skipping.
> Error parsing GUI file c:\fgdev\fgfsbase\gui\dialogs\CVS\..
> GUI file c:\fgdev\fgfsbase\gui\dialogs\CVS\.. has no name; skipping.
>
> and reach a fatal error (access violation) when trying to process the
> following directory.
>
> c:\fgdev\fgfsbase\gui\dialogs\cvs\Entries
>
> Unfortunately, the trace back that MSVC gives me is not helpful (it
> complains about readXML, but the stack is very short and not useful).
> Can someone give me some guidance as to how I can track this down? Are
> other Windows developers seeing this?
For those like me who use directly the base package CVS repository,
I have this mod in my local workspace :
D:\FlightGear\cvs\FlightGear\src>cvs -z3 -q diff -u GUI/new_gui.cxx
Index: GUI/new_gui.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/GUI/new_gui.cxx,v
retrieving revision 1.11
diff -u -r1.11 new_gui.cxx
--- GUI/new_gui.cxx 19 Jan 2003 12:54:26 - 1.11
+++ GUI/new_gui.cxx 20 Jan 2003 07:38:19 -
@@ -120,7 +120,9 @@
ulMakePath(subpath, path, dirEnt->d_name);
-if (dirEnt->d_isdir && dirEnt->d_name[0] != '.') {
+if (dirEnt->d_isdir && strcmp(dirEnt->d_name,"CVS") == 0) {
+ // skip
+} else if (dirEnt->d_isdir && dirEnt->d_name[0] != '.') {
readDir(subpath);
} else {
SGPropertyNode_ptr props = new SGPropertyNode;
Cheers,
-Fred
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Windows Problem with the Latest GUI Code
I updated to the latest CVS for both FlightGear and the base packages and am having a problem under Windows (MacOS X is working correctly). The module src/new_gui.cxx runs and starts reading the XML files but starts getting into trouble. I get the following errors printed to the screen Error parsing GUI file c:\fgdev\fgfsbase\gui\dialogs\. GUI file c:\fgdev\fgfsbase\gui\dialogs\. has no name; skipping. Error parsing GUI file c:\fgdev\fgfsbase\gui\dialogs\.. GUI file c:\fgdev\fgfsbase\gui\dialogs\.. has no name; skipping. Error parsing GUI file c:\fgdev\fgfsbase\gui\dialogs\CVS\. GUI file c:\fgdev\fgfsbase\gui\dialogs\CVS\. has no name; skipping. Error parsing GUI file c:\fgdev\fgfsbase\gui\dialogs\CVS\.. GUI file c:\fgdev\fgfsbase\gui\dialogs\CVS\.. has no name; skipping. and reach a fatal error (access violation) when trying to process the following directory. c:\fgdev\fgfsbase\gui\dialogs\cvs\Entries Unfortunately, the trace back that MSVC gives me is not helpful (it complains about readXML, but the stack is very short and not useful). Can someone give me some guidance as to how I can track this down? Are other Windows developers seeing this? Thanks, Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Translucent Dialogs
David Luff writes: >> > A couple of points I noticed are that when sliding the mouse sideways > across the menubar at the top, the original submenu is not replaced by the > next ones, I believe that this is a dsign decision in PLIB It is related to being able to keep focus on a slider or a dial widget when outside of the widgets bounding box if the mouse button remains depressed > and pressing escape when a dialog with a cancel box is displayed > still brings up the exit sim dialog instead of clearing the current one. This requires a more sophisticated key mapping system then what we currently have. PLIB purposefully leaves almost all keyhandling to the application using it. It could be that the easiest way to remap the 'esc key' when a dialog is active is to have the fgDialog class explicitly check for an 'esc' key < abory event > before passing the key onto the properties key resolution mechanism. Another way is to derive a new base dialog class from puDialog that handles the esc key and use it as the base of all our dialogs Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Translucent Dialogs
David Megginson writes: > > David Luff writes: > > > A couple of points I noticed are that when sliding the mouse sideways > > across the menubar at the top, the original submenu is not replaced by the > > next ones, and pressing escape when a dialog with a cancel box is displayed > > still brings up the exit sim dialog instead of clearing the current one. > > The first issue is almost certainly Plib related I should think, but could > > we be at fault for the second one? > > It may have to do with whether or not the dialog is modal. I'll have > to experiment a bit. > > Did the old dialogs close when you pressed ESC? No We discussed this several years ago Now as then I advocate having a stack of 'keybinding sets' where you associate a set of bindings for a 'mode'. On entering a 'mode' its' set bindings is pushed onto the stack on leaving the mode the stack is popped. A key press is resolved by walking the sets on the stack returning the first binding found This is quite easy to do in 'C' where the stack is actually an array of stacks, one for each possible key combination, and a 'mode set' is a just a list of the key bindings for that mode I think that a variation of a C++ MultiMap could probably be used for this as well Regards Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Translucent Dialogs
On 1/19/03 at 7:51 PM David Megginson wrote: >It may have to do with whether or not the dialog is modal. I'll have >to experiment a bit. > >Did the old dialogs close when you pressed ESC? No, the old behaviour was just the same, it was something I never got round to mentioning... Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Translucent Dialogs
David Luff writes: > A couple of points I noticed are that when sliding the mouse sideways > across the menubar at the top, the original submenu is not replaced by the > next ones, and pressing escape when a dialog with a cancel box is displayed > still brings up the exit sim dialog instead of clearing the current one. > The first issue is almost certainly Plib related I should think, but could > we be at fault for the second one? It may have to do with whether or not the dialog is modal. I'll have to experiment a bit. Did the old dialogs close when you pressed ESC? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Translucent Dialogs
On 1/19/03 at 7:01 PM David Megginson wrote: >Michael Basler writes: > > > Could we draw the menu line over the full width, independent of > > resolution? This is common for nearly all programs on all > > platforms I know. > >Right now we're using the higher-level PUI menubar widget, so we have >to take what we get. To change its appearance, we'd have to implement >our own menubar from low-level widgets. > >In fact, we probably will have to do that sooner or later, since the >PUI menubar is not all that feature-rich, but I don't want to dive >into it right now. A couple of points I noticed are that when sliding the mouse sideways across the menubar at the top, the original submenu is not replaced by the next ones, and pressing escape when a dialog with a cancel box is displayed still brings up the exit sim dialog instead of clearing the current one. The first issue is almost certainly Plib related I should think, but could we be at fault for the second one? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory corruption solved
From: "Frederic Bouvier" <[EMAIL PROTECTED]> > I am fighting against a memory corruption for 2 hours and I solved it. > Not enought room was allocated in ATCmgr.cxx and auto_gui.cxx to store > strings. > Here is the patch, hoping it will solve Curt's and Michael's problems : Dave already patched ATCmgr.cxx. Can someone patch auto_gui.cxx and prop_picker.cxx ? Thanks, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Translucent Dialogs
Michael Basler writes: > Could we draw the menu line over the full width, independent of > resolution? This is common for nearly all programs on all > platforms I know. Right now we're using the higher-level PUI menubar widget, so we have to take what we get. To change its appearance, we'd have to implement our own menubar from low-level widgets. In fact, we probably will have to do that sooner or later, since the PUI menubar is not all that feature-rich, but I don't want to dive into it right now. > PS: Are the recent CVS submits supposed to solve the OK/Cancel memory leak > issue? It should be fixed now. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Translucent Dialogs
Curtis L. Olson writes: > > How would people feel about going opaque? > > What about 90% opaque? Just enough to say, "yeah, we're cool" but for > all practical purposes, they are opaque ... (?) Sounds like a good compromise. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Translucent Dialogs
David, After getting recent CVS updates the menu crash is gone for me too. Great Work you guys! Regards, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Translucent Dialogs
David, > The translucent dialogs we've been using look very spiffy, but it > turns out that they're not all that practical once you start using > things like pop-up menus in combo boxes. Take a look at the clouds > dialog in the latest CVS (FlightGear and base package) to see why. > > How would people feel about going opaque? I am not that definit on this one, maybe personally would leave it as is, but as we are on this: Could we draw the menu line over the full width, independent of resolution? This is common for nearly all programs on all platforms I know. We just would fill it with the main menu entries as far as they go. Perhaps the Help menu (maybe including an "About" button with a link the Home page and GPL) might be on the very right, but this is not mandatory. PS: Are the recent CVS submits supposed to solve the OK/Cancel memory leak issue? Regards, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Translucent Dialogs
David Megginson writes: > The translucent dialogs we've been using look very spiffy, but it > turns out that they're not all that practical once you start using > things like pop-up menus in combo boxes. Take a look at the clouds > dialog in the latest CVS (FlightGear and base package) to see why. > > How would people feel about going opaque? Ok, your latest changes eliminate my crash. Thanks! I now see what you mean about the translucency. The popup menus at least need to be opaque. But since we probably can't control this at that fine of detail we do probably need to go opaque ... I'm not all that attached to the translucency other than it was a bit of eye candy, I'm willing to give it up if everyone else is. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Translucent Dialogs
On 1/19/03 at 6:06 PM David Megginson wrote: >The translucent dialogs we've been using look very spiffy, but it >turns out that they're not all that practical once you start using >things like pop-up menus in combo boxes. Take a look at the clouds >dialog in the latest CVS (FlightGear and base package) to see why. > >How would people feel about going opaque? Opaque is good for dialogs where the sim is paused, but translucent is better for non-paused dialogs, such as selecting an ATC communication from a list whilst flying, IMHO. Could this not be made user definable though? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Translucent Dialogs
David Megginson writes: > The translucent dialogs we've been using look very spiffy, but it > turns out that they're not all that practical once you start using > things like pop-up menus in combo boxes. Take a look at the clouds > dialog in the latest CVS (FlightGear and base package) to see why. > > How would people feel about going opaque? What about 90% opaque? Just enough to say, "yeah, we're cool" but for all practical purposes, they are opaque ... (?) Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Translucent Dialogs
The translucent dialogs we've been using look very spiffy, but it turns out that they're not all that practical once you start using things like pop-up menus in combo boxes. Take a look at the clouds dialog in the latest CVS (FlightGear and base package) to see why. How would people feel about going opaque? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FreeBSD autoconf fixes
Curtis L. Olson writes:
> I still haven't figured out the code, but is one of the call backs
> deleting the dialog box?
That might be it -- try dropping this in instead:
/**
* Action callback.
*/
static void
action_callback (puObject * object)
{
GUIInfo * info = (GUIInfo *)object->getUserData();
NewGUI * gui = (NewGUI *)globals->get_subsystem("gui");
gui->setCurrentWidget(info->widget);
int nBindings = info->bindings.size();
for (int i = 0; i < nBindings; i++) {
info->bindings[i]->fire();
if (gui->getCurrentWidget() == 0)
break;
}
gui->setCurrentWidget(0);
}
All the best,
David
--
David Megginson, [EMAIL PROTECTED], http://www.megginson.com/
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] OT - Interesting link (Wright Flyer)
Exhibition of mock-up wooden Wright Flyer cockpit attached to MSFS visuals: http://www.eaa.org/communications/eaanews/030117_simulator.html Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FreeBSD autoconf fixes
Curtis L. Olson writes: > For what it's worth, the "Apply" button seems to work (and triggers > one "fire()" call, but the "OK" button triggers 2 fire() calls and > then the size of the vector get's corrupted. > > The "Cancel" button also causes a crash. It makes 1 fire() call, > corrupts the vector and then segfaults. > > Could there be something related to deleting the dialog box that is > corrupting memory? I still haven't figured out the code, but is one of the call backs deleting the dialog box? Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory corruption solved
Frederic Bouvier writes: > My new option parsing function is also working. You will receive it > soon. I've got it, and will take a look as soon as I'm done rebuilding with 3.2. Thanks, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FreeBSD autoconf fixes
David Megginson writes: > Curtis L. Olson writes: > > > What compiler options do you build with? I usually override the > > default and build with -Wall -O2, I'll do a rebuild with default > > options and see if that helps. > > With 3.2, I usually build with > > -g -O1 -finline-limit=6 -finline-functions > > For the 2.95 test, however, I just used vanilla ./configure and didn't > mess with the options at all. For what it's worth, the "Apply" button seems to work (and triggers one "fire()" call, but the "OK" button triggers 2 fire() calls and then the size of the vector get's corrupted. The "Cancel" button also causes a crash. It makes 1 fire() call, corrupts the vector and then segfaults. Could there be something related to deleting the dialog box that is corrupting memory? Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory corruption solved
On 1/19/03 at 10:09 PM Frederic Bouvier wrote: >I am fighting against a memory corruption for 2 hours and I solved it. >Not enought room was allocated in ATCmgr.cxx and auto_gui.cxx to store >strings. >Here is the patch, hoping it will solve Curt's and Michael's problems : > Oops, sorry. I've commited the changes to ATCmgr.cxx Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory corruption solved
From: "David Megginson" <[EMAIL PROTECTED]> > Frederic Bouvier writes: > > > I am fighting against a memory corruption for 2 hours and I solved it. > > Not enought room was allocated in ATCmgr.cxx and auto_gui.cxx to store > > strings. > > I'll cross my fingers. > > Frederic -- are the XML dialogs still working OK for you? Yes, it still works. My new option parsing function is also working. You will receive it soon. Cheers, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Memory corruption solved
Frederic Bouvier writes: > I am fighting against a memory corruption for 2 hours and I solved it. > Not enought room was allocated in ATCmgr.cxx and auto_gui.cxx to store > strings. I'll cross my fingers. Frederic -- are the XML dialogs still working OK for you? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Possible G++ 2.95 fix; checkboxes
Curtis L. Olson writes: > I think that something is stomping on the memory occupied by the > vector. That's the only way I can explain it's size getting > corrupted. There's so many levels of indirection though it's > difficult to trace back what's going on where. I'm willing to help > track this down, but I might need some help tracing through the flow > and a bit of direction for what to look at. The extra indirection was my first attempt to fix the 2.95 problem, by explicitly allocating vectors instead of having them created automatically. Since that didn't work, I should probably put things back to make the code more transparent. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FreeBSD autoconf fixes
Curtis L. Olson writes: > What compiler options do you build with? I usually override the > default and build with -Wall -O2, I'll do a rebuild with default > options and see if that helps. With 3.2, I usually build with -g -O1 -finline-limit=6 -finline-functions For the 2.95 test, however, I just used vanilla ./configure and didn't mess with the options at all. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Memory corruption solved
I am fighting against a memory corruption for 2 hours and I solved it.
Not enought room was allocated in ATCmgr.cxx and auto_gui.cxx to store
strings.
Here is the patch, hoping it will solve Curt's and Michael's problems :
D:\FlightGear\cvs\FlightGear\src>cvs -z3 -q diff -u ATC/ATCmgr.cxx
Autopilot/auto_gui.cxx GUI/prop_picker.cxx
Index: ATC/ATCmgr.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/ATC/ATCmgr.cxx,v
retrieving revision 1.5
diff -u -r1.5 ATCmgr.cxx
--- ATC/ATCmgr.cxx 7 Jan 2003 13:11:00 - 1.5
+++ ATC/ATCmgr.cxx 19 Jan 2003 21:06:39 -
@@ -113,15 +113,15 @@
char *s;
// Option lists hardwired per ATC type
- towerOptions[0] = new char[strlen(t0)];
+ towerOptions[0] = new char[strlen(t0)+1];
strcpy(towerOptions[0], t0);
- towerOptions[1] = new char[strlen(t1)];
+ towerOptions[1] = new char[strlen(t1)+1];
strcpy(towerOptions[1], t1);
- towerOptions[2] = new char[strlen(t2)];
+ towerOptions[2] = new char[strlen(t2)+1];
strcpy(towerOptions[2], t2);
towerOptions[3] = NULL;
- approachOptions[0] = new char[strlen(a0)];
+ approachOptions[0] = new char[strlen(a0)+1];
strcpy(approachOptions[0], a0);
approachOptions[1] = NULL;
Index: Autopilot/auto_gui.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Autopilot/auto_gui.cxx,v
retrieving revision 1.3
diff -u -r1.3 auto_gui.cxx
--- Autopilot/auto_gui.cxx 5 Jan 2003 00:10:36 - 1.3
+++ Autopilot/auto_gui.cxx 19 Jan 2003 21:06:39 -
@@ -722,7 +722,7 @@
WPList = new char* [ WPListsize + 1 ];
for (i = 0; i < globals->get_route()->size(); i++ ) {
sprintf(WPString, "%5s %3.2flon %3.2flat",
globals->get_route()->get_waypoint(i).get_id().c_str(), globals->
get_route()->get_waypoint(i).get_target_lon(),
globals->get_route()->get_waypoint(i).get_target_lat());
- WPList [i] = new char[ strlen(WPString) ];
+ WPList [i] = new char[ strlen(WPString)+1 ];
strcpy ( WPList [i], WPString );
}
} else {
Index: GUI/prop_picker.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/GUI/prop_picker.cxx,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 prop_picker.cxx
--- GUI/prop_picker.cxx 10 Sep 2002 01:14:04 - 1.1.1.1
+++ GUI/prop_picker.cxx 19 Jan 2003 21:06:40 -
@@ -448,15 +448,15 @@
values = new char* [ num_files+1 ] ;
dflag = new char [ num_files+1 ] ;
stdString line = ".";
-files [ 0 ] = new char[ strlen(line.c_str())+2 ];
+files [ 0 ] = new char[ strlen(line.c_str())+1 ];
strcpy ( files [ 0 ], line.c_str() );
names [ 0 ] = new char[ 2 ];
values[ 0 ] = new char[ 2 ] ;
line = "..";
dflag[ 0 ] = 1;
-files [ 1 ] = new char[ strlen(line.c_str())+2 ];
+files [ 1 ] = new char[ strlen(line.c_str())+1 ];
strcpy ( files [ 1 ], line.c_str() );
-names [ 1 ] = new char[ strlen(line.c_str())+2 ];
+names [ 1 ] = new char[ strlen(line.c_str())+1 ];
values[ 1 ] = new char[ 2 ] ;
strcpy ( names [ 1 ], line.c_str() );
@@ -480,25 +480,25 @@
for (i = 0; i < nChildren; i++) {
SGPropertyNode * child = children[i];
stdString name = child->getDisplayName(true);
- names[ pi ] = new char[ strlen(name.c_str())+2 ] ;
+ names[ pi ] = new char[ strlen(name.c_str())+1 ] ;
strcpy ( names [ pi ], name.c_str() ) ;
if ( child->nChildren() > 0 ) {
dflag[ pi ] = 1 ;
-files[ pi ] = new char[ strlen(name.c_str())+2 ] ;
+files[ pi ] = new char[ strlen(name.c_str())+1 ] ;
strcpy ( files [ pi ], name.c_str() ) ;
strcat ( files [ pi ], "/" ) ;
values[ pi ] = new char[ 2 ] ;
} else {
dflag[ pi ] = 0 ;
stdString value = child->getStringValue();
- values[ pi ] = new char[ strlen(value.c_str())+2 ] ;
+ values[ pi ] = new char[ strlen(value.c_str())+1 ] ;
strcpy ( values [pi], value.c_str() );
stdString line = name + " = '" + value + "' " + "(";
line += getValueTypeString( child );
line += ")";
// truncate entries to plib pui limit
if (line.length() > (PUSTRING_MAX-1)) line[PUSTRING_MAX-1]
= '\0';
-files[ pi ] = new char[ strlen(line.c_str())+2 ] ;
+files[ pi ] = new char[ strlen(line.c_str())+1 ] ;
strcpy ( files [ pi ], line.c_str() ) ;
}
// printf("files->%i of %i %s\n",pi, node->nChildren(), files
[pi]);
Cheers,
-Fred
___
Flightgear-
Re: [Flightgear-devel] FreeBSD autoconf fixes
Bert Driehuis writes: > On Sun, 19 Jan 2003, David Megginson wrote: > > > > So, I can report the current CVS snapshot works on FreeBSD 4.7 with the > > > autoconf patches in my previous post. > > > > Excellent. Which version of G++ did you use? > > Sorry for not mentioning that -- I specifically checked it with the > intent of sharing it in the light of the discussion w.r.t. versions > going on. It's the 2.95.4 that comes with FreeBSD 4.7. David, What compiler options do you build with? I usually override the default and build with -Wall -O2, I'll do a rebuild with default options and see if that helps. Often building with -g (the default) masks buffer overruns because there's a better chance when you overrun your buffer you copy over debugging infrastructure, and not actually code/data. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Possible G++ 2.95 fix; checkboxes
David Megginson writes: > OK, guess #1 is down the tubes. I'm going to need help with this one, > because the bug does not occur with G++ 3.2 no matter how many times I > try it, and it apparently does not occur with MSVC++ either. > > Curt and Michael: has either of you tried a > > make clean; make > > just in case the dependencies got screwed up somehow? Yup, but didn't help in my case ... > We use vectors a lot in FlightGear, and they're not giving us trouble > anywhere else. I think that something is stomping on the memory occupied by the vector. That's the only way I can explain it's size getting corrupted. There's so many levels of indirection though it's difficult to trace back what's going on where. I'm willing to help track this down, but I might need some help tracing through the flow and a bit of direction for what to look at. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] G++ 2.95/Cygwin problem?
Norman Vine writes:
> What I would like is a way to define menus something like
>
> myMenu = (
> ('&File',
> ('New', (ALT, 'N'), self.OnFileNew),
> ('Open', (ALT, 'O'), self.OnFileOpen),
> ('Close', (ALT, 'C'), self.OnFileClose)),
> ('&Edit',
> ('Cut', (CTRL, 'X'), self.OnEditCut),
> ('Copy', (CTRL, 'C'), self.OnEditCopy),
> ('Paste', (CTRL, 'V'), self.OnEditPaste)))
>
> It should be possible to come up with generator program
> that can take the above, or something like it, that will write the
> xml configuration files
I haven't looked into adding keyboard accelerators yet. It's a tricky
problem, because we'll have to try to figure out at runtime what keys
are bound to do the same things as drop-down menus.
All the best,
David
--
David Megginson, [EMAIL PROTECTED], http://www.megginson.com/
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FreeBSD autoconf fixes
On Sun, 19 Jan 2003, David Megginson wrote: > > So, I can report the current CVS snapshot works on FreeBSD 4.7 with the > > autoconf patches in my previous post. > > Excellent. Which version of G++ did you use? Sorry for not mentioning that -- I specifically checked it with the intent of sharing it in the light of the discussion w.r.t. versions going on. It's the 2.95.4 that comes with FreeBSD 4.7. Cheers, -- Bert -- Bert Driehuis -- [EMAIL PROTECTED] -- +31-20-3116119 If the only tool you've got is an axe, every problem looks like fun! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] G++ 2.95/Cygwin problem?
Assuming you just changed i++ to ++i, no difference.
Curt.
Norman Vine writes:
> Curtis L. Olson writes:
> >
> > I put in a printf and I see that, well, ok, this is strange (or I
> > haven't had enough caffeine yet ...)
> >
> > I added the following cout's:
> >
> > cout << "size = " << info->bindings.size() << endl;
> > for (int i = 0; i < info->bindings.size(); i++) {
> > cout << i << "(" << info->bindings.size() << ")" << " " <<
> > info->bindings[i] << endl;
> > info->bindings[i]->fire();
> > }
> > gui->setCurrentWidget(0);
> >
> > And the printed output I get is:
> >
> > 0(2) 0xb02ddd8
> > 1(2) 0xb030d88
> > 2(76708068) 0x99340b0
> > Segmentation fault
>
> Hmm... what happens if you change that to
>
> cout << "size = " << info->bindings.size() << endl;
> for (int i = 0; i < info->bindings.size(); ++i {
> cout << i << "(" << info->bindings.size() << ")" << " " <<
> info->bindings[i] << endl;
> info->bindings[i]->fire();
> }
> gui->setCurrentWidget(0);
>
>
> ___
> Flightgear-devel mailing list
> [EMAIL PROTECTED]
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
--
Curtis Olson IVLab / HumanFIRST Program FlightGear Project
Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED]
Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Built with G++ 2.95, still no crash
I just did a very time-consuming rebuild plib, Metakit, SimGear, and FlightGear from scratch with G++ 2.95 instead of 3.2, and I'm still not having any problem with the XML-configured dialog boxes. In case it's helpful, here's an ldd from the 2.95-built binary: libmk4.so.0 => /usr/local/lib/libmk4.so.0 (0x4001c000) libz.so.1 => /lib/libz.so.1 (0x40067000) libglut.so.3 => /usr/lib/libglut.so.3 (0x40075000) libGLU.so.1 => /usr/X11R6/lib/libGLU.so.1 (0x400b) libGL.so.1 => /usr/lib/libGL.so.1 (0x4012c000) libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x40179000) libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x4018d000) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x401d8000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x401e) libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x401f6000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x401fe000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4020b000) libpthread.so.0 => /lib/libpthread.so.0 (0x402c5000) libm.so.6 => /lib/libm.so.6 (0x40315000) libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0x40336000) libc.so.6 => /lib/libc.so.6 (0x4037f000) libGLcore.so.1 => /usr/lib/libGLcore.so.1 (0x4048f000) libdl.so.2 => /lib/libdl.so.2 (0x40921000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) Could the people having trouble with the XML dialog boxes please take the following steps? 1. Do a CVS update on FlightGear and the base package. 2. Do a 'make clean; make' in the FlightGear source directory. 3. Try running src/Main/fgfs and see if the XML dialogs still crash the program. Thanks, and all the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] G++ 2.95/Cygwin problem?
David Megginson writes:
>
> map > _bindings;
>
> p.s. Now why do I prefer coding in Java, again?
What I would like is a way to define menus something like
myMenu = (
('&File',
('New', (ALT, 'N'), self.OnFileNew),
('Open', (ALT, 'O'), self.OnFileOpen),
('Close', (ALT, 'C'), self.OnFileClose)),
('&Edit',
('Cut', (CTRL, 'X'), self.OnEditCut),
('Copy', (CTRL, 'C'), self.OnEditCopy),
('Paste', (CTRL, 'V'), self.OnEditPaste)))
It should be possible to come up with generator program
that can take the above, or something like it, that will write the
xml configuration files
anyone have any thoughts ?
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FreeBSD autoconf fixes
Bert Driehuis writes: > So, I can report the current CVS snapshot works on FreeBSD 4.7 with the > autoconf patches in my previous post. Excellent. Which version of G++ did you use? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] G++ 2.95/Cygwin problem?
Curtis L. Olson writes:
>
> I put in a printf and I see that, well, ok, this is strange (or I
> haven't had enough caffeine yet ...)
>
> I added the following cout's:
>
> cout << "size = " << info->bindings.size() << endl;
> for (int i = 0; i < info->bindings.size(); i++) {
> cout << i << "(" << info->bindings.size() << ")" << " " <<
> info->bindings[i] << endl;
> info->bindings[i]->fire();
> }
> gui->setCurrentWidget(0);
>
> And the printed output I get is:
>
> 0(2) 0xb02ddd8
> 1(2) 0xb030d88
> 2(76708068) 0x99340b0
> Segmentation fault
Hmm... what happens if you change that to
cout << "size = " << info->bindings.size() << endl;
for (int i = 0; i < info->bindings.size(); ++i {
cout << i << "(" << info->bindings.size() << ")" << " " <<
info->bindings[i] << endl;
info->bindings[i]->fire();
}
gui->setCurrentWidget(0);
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FreeBSD autoconf fixes
Follow up to self: > Todays CVS snapshot of FlightGear crashes in the new XML menu stuff; > haven't investigated yet where menubar.xml is supposed to come from > (just joined the list). Hm. It helps to not just download, but also install, the updated fgfs_base :-) So, I can report the current CVS snapshot works on FreeBSD 4.7 with the autoconf patches in my previous post. Cheers, -- Bert -- Bert Driehuis -- [EMAIL PROTECTED] -- +31-20-3116119 If the only tool you've got is an axe, every problem looks like fun! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] FreeBSD autoconf fixes
The attached diffs (relative to todays CVS) detect pthreads on FreeBSD.
Even when the app itself doesn't need threading, any app linked against
Mesa must by compile with "g++ -pthread" (otherwise, "gssInit called
without valid rendering context" rears its ugly but helpful head).
The checks only kick in when pthread.h is present but pthread_exit can't
be found. This seems to me to be the more "generic" way of testing it in
autoconf. Needless to say, testing to see if ${host} matches *freebsd*
would be a quicker way to stuff -pthread into C{,XX}FLAGS :-)
Todays CVS snapshot of FlightGear crashes in the new XML menu stuff;
haven't investigated yet where menubar.xml is supposed to come from
(just joined the list). That said, with the attached patches it pops up
the splash screen, whereas without it, it would die early on.
For what it's worth, the flightgear patch also applies cleanly to
0.9.1-release and makes it work on FreeBSD.
Cheers,
-- Bert
--
Bert Driehuis -- [EMAIL PROTECTED] -- +31-20-3116119
If the only tool you've got is an axe, every problem looks like fun!
Index: configure.ac
===
RCS file: /var/cvs/SimGear-0.3/SimGear/configure.ac,v
retrieving revision 1.15
diff -c -r1.15 configure.ac
*** configure.ac30 Dec 2002 21:33:56 - 1.15
--- configure.ac19 Jan 2003 18:19:47 -
***
*** 147,152
--- 147,169
CXXFLAGS="$CXXFLAGS -D_REENTRANT"
CFLAGS="$CFLAGS -D_REENTRANT"
fi
+ if test "x$ac_cv_lib_pthread_pthread_exit" != "xyes" -a "x$ac_cv_header_pthread_h" =
+"xyes"; then
+ dnl See if we need -pthread instead of -lpthread
+ save_CXXFLAGS="$CXXFLAGS"
+ save_CFLAGS="$FLAGS"
+ CXXFLAGS="-pthread $CXXFLAGS"
+ CFLAGS="-pthread $FLAGS"
+ save_LIBS=$LIBS
+ AC_CHECK_LIB(c_r, pthread_exit)
+ if test "x$ac_cv_lib_c_r_pthread_exit" != "xyes"; then
+ CXXFLAGS=$save_CXXFLAGS
+ CFLAGS=$save_CFLAGS
+ else
+ dnl This is cheating a bit. pthread_exit comes with using -pthread, not
+-lpthread
+ ac_cv_lib_pthread_pthread_exit="yes"
+ fi
+ LIBS=$save_LIBS
+ fi
AM_CONDITIONAL(HAVE_THREADS, test "x$ac_cv_lib_pthread_pthread_exit" = "xyes" -a
"x$ac_cv_header_pthread_h" = "xyes")
AC_CHECK_LIB(socket, socket)
Index: configure.ac
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/configure.ac,v
retrieving revision 1.22
diff -c -r1.22 configure.ac
*** configure.ac18 Jan 2003 17:36:59 - 1.22
--- configure.ac19 Jan 2003 18:27:35 -
***
*** 98,105
AC_DEFINE([ENABLE_THREADS], 1, [Define to enable threaded tile paging])
CXXFLAGS="$CXXFLAGS -D_REENTRANT"
CFLAGS="$CFLAGS -D_REENTRANT"
- AC_CHECK_HEADER(pthread.h)
fi
AM_CONDITIONAL(WITH_THREADS, test "x$with_threads" = "xyes")
# specify the plib location
--- 98,105
AC_DEFINE([ENABLE_THREADS], 1, [Define to enable threaded tile paging])
CXXFLAGS="$CXXFLAGS -D_REENTRANT"
CFLAGS="$CFLAGS -D_REENTRANT"
fi
+ AC_CHECK_HEADER(pthread.h)
AM_CONDITIONAL(WITH_THREADS, test "x$with_threads" = "xyes")
# specify the plib location
***
*** 204,209
--- 204,223
dnl Thread related checks
AC_CHECK_LIB(pthread, pthread_exit)
+ if test "x$ac_cv_lib_pthread_pthread_exit" != "xyes" -a "x$ac_cv_header_pthread_h" =
+"xyes"; then
+ dnl See if we need -pthread instead of -lpthread
+ save_CXXFLAGS="$CXXFLAGS"
+ save_CFLAGS="$FLAGS"
+ CXXFLAGS="-pthread $CXXFLAGS"
+ CFLAGS="-pthread $FLAGS"
+ save_LIBS=$LIBS
+ AC_CHECK_LIB(c_r, pthread_exit)
+ if test "x$ac_cv_lib_c_r_pthread_exit" != "xyes"; then
+ CXXFLAGS=$save_CXXFLAGS
+ CFLAGS=$save_CFLAGS
+ fi
+ LIBS=$save_LIBS
+ fi
AC_CHECK_LIB(socket, socket)
dnl check for glut location
RE: [Flightgear-devel] Possible G++ 2.95 fix; checkboxes
Michael Basler writes: > I updated to the latest CVS and rebuilt, but it still dies in the > dialogue with "OK" etc.. > > Sorry, Michael OK, guess #1 is down the tubes. I'm going to need help with this one, because the bug does not occur with G++ 3.2 no matter how many times I try it, and it apparently does not occur with MSVC++ either. Curt and Michael: has either of you tried a make clean; make just in case the dependencies got screwed up somehow? We use vectors a lot in FlightGear, and they're not giving us trouble anywhere else. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Possible G++ 2.95 fix; checkboxes
David, I updated to the latest CVS and rebuilt, but it still dies in the dialogue with "OK" etc.. Sorry, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Possible G++ 2.95 fix; checkboxes
I've checked in a possible fix for G++ 2.95 -- please let me know if it works. I've also made some GUI enhancements: 1. Added checkboxes for boolean properties. 2. Automatically update after "apply" to see what really got into the property tree. 3. Use plib's ability to beautify numbers. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: New Menu Bar; dialogs for clouds, winds, and air
Norman Vine writes: > It would be nice if had a 'lint' like XML checker for all of the > 'properties' We get an error if the XML document is not well-formed, but not if there is an unrecognized property. There are lots of good reasons for keeping it that way. > Anyone know of an OpenSource alternative to XMLSpy Tons -- nearly all good XML software is open source. The problem would be writing and maintaining DTDs or schemas for all our possible information variants. I've worked on a lot of SGML and XML systems, and I've seen people spend a lot of money on that approach, but I've never seen them get any substantial benefit from it. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Missing return value in menubar.cxx
Frederic Bouvier writes: > > Would you like to take a stab at it? > > OK, I'll take this one. Great -- thanks. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] G++ 2.95/Cygwin problem?
Curtis L. Olson writes: > So this looks wierd ... something in the fire() method appears to be > stomping on the bindings vector? The size jumps from 2 up to > 767087068. This smells a little like some sort of memory corruption > or buffer overrun someplace The fire() method has no access to the parent vector, though -- it just gets the pointer that the vector holds. I suspect some 2.95 wierdness, since all reports of problems come from 2.95 or Cygwin/2.95. I'll check in a slightly different version to see if it helps. In a year or so, when the distros catch up, it would be nice to require G++ 3.* so that we don't have to worry about kludging around 2.95. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: New Menu Bar; dialogs for clouds, winds, and air
David Megginson writes: > > There was a typo "bindings" instead of "binding" -- it's fixed now. > It would be nice if had a 'lint' like XML checker for all of the 'properties' Anyone know of an OpenSource alternative to XMLSpy Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Missing return value in menubar.cxx
From: "David Megginson" <[EMAIL PROTECTED]> > Frederic Bouvier writes: > > > I also have a problem where options.cxx has too many levels of imbrication > > in parse_option (max is 128). There are too many 'else if' construct. > > Can we think about another scheme to parse options (iterating on an array or > > an XML file) ? > > The 128 hard-coded limit is ridiculous, but I also agree that this > isn't exactly brilliant coding. A lookup table mapped to functions > would be an OK solution; also, since so many of the options are just > simple mappings to property values, we could probably make those > configurable and just hard-code the special cases. > > Would you like to take a stab at it? OK, I'll take this one. Cheers, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] 100 years of radio
FYI While some were marching yesterday I helped celebrate one of man's greatest gadgets http://dev.communicom.net/marconi/index.html Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] G++ 2.95/Cygwin problem?
David Megginson writes:
> I've been trying to hunt down why G++ 2.95/Cygwin might be having a
> runtime problem with menubar.[ch]xx. Could this line from menubar.hxx
> be causing the problem?
>
> map > _bindings;
>
> It is proper ANSI C++, and neither G++ 3.2 nor MSVC++ seems to have
> any problem with it, but perhaps G++ 2.95 in Linux or Cygwin isn't
> initializing the vector properly (I seem to recall that its C++
> support is a bit marginal). I could always change it to
>
> map *> _bindings;
>
> I'd need to add a bit more code for allocators and destructors, but it
> wouldn't be a big deal. Before I do this, though, can anyone confirm
> whether this is likely to be the problem?
I believe I've seen some odd things at times when it comes to vector
initialization. I've always chalked it up to not depending on the
memory contents of any newly created item unless I've otherwise
explicitely initialized it. You might try doing a vector.clear() (or
is it erase() right after creating it just to make sure it starts out
empty. That's probably not it though ...
I put in a printf and I see that, well, ok, this is strange (or I
haven't had enough caffeine yet ...)
I added the following cout's:
cout << "size = " << info->bindings.size() << endl;
for (int i = 0; i < info->bindings.size(); i++) {
cout << i << "(" << info->bindings.size() << ")" << " " <<
info->bindings[i] << endl;
info->bindings[i]->fire();
}
gui->setCurrentWidget(0);
And the printed output I get is:
0(2) 0xb02ddd8
1(2) 0xb030d88
2(76708068) 0x99340b0
Segmentation fault
So this looks wierd ... something in the fire() method appears to be
stomping on the bindings vector? The size jumps from 2 up to
767087068. This smells a little like some sort of memory corruption
or buffer overrun someplace
Regards,
Curt.
--
Curtis Olson IVLab / HumanFIRST Program FlightGear Project
Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED]
Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animation glitches
On 1/19/03 at 8:37 AM Curtis L. Olson wrote: >With recent code changes, I'm seeing a significant pause in the >animation about every 2 seconds. This is enough to create a break in >the audio with every pause. I don't think this is just my machine. >Is any one else seeing this in the latest CVS? If it's not just me, >we need to track down where it is coming from because it is immensely >annoying! I see pauses in the audio, but not the animation, if I have too many sounds simultaneously playing. Takeoff with engine noise, runway noise, wind noise, VOR ident + audio ATIS is sometimes enough to trigger intermittant sound pauses, adding a second ATIS channel on top of all that always triggers them. This is on windows with an onboard sound chip. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: New Menu Bar; dialogs for clouds, winds, and air
David Megginson writes: > > Do the > > LatLonFormatToggle > > or the > > AutoPilotAdjuster > > > > Work for anybody ??? > > I'll try to hunt down the problem with these. There was a typo "bindings" instead of "binding" -- it's fixed now. Thanks, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Missing return value in menubar.cxx
Frederic Bouvier writes: > I also have a problem where options.cxx has too many levels of imbrication > in parse_option (max is 128). There are too many 'else if' construct. > Can we think about another scheme to parse options (iterating on an array or > an XML file) ? The 128 hard-coded limit is ridiculous, but I also agree that this isn't exactly brilliant coding. A lookup table mapped to functions would be an OK solution; also, since so many of the options are just simple mappings to property values, we could probably make those configurable and just hard-code the special cases. Would you like to take a stab at it? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animation glitches
> With recent code changes, I'm seeing a significant pause in the > animation about every 2 seconds. This is enough to create a break in > the audio with every pause. I don't think this is just my machine. > Is any one else seeing this in the latest CVS? If it's not just me, > we need to track down where it is coming from because it is immensely > annoying! I've seen this before, in the last few days, but I can't reproduce it. It never affected the picture though, only the sound. I'm running CVS with gcc 2.95.4 on Debian sid on Athlon XP1800+ and Radeon 8500 with ATI's fglrx driver 2.5.1. Damn, my X server crash symptom has just returned, despite the "mem=nopentium" option, and I haven't changed anything else. Even worse, if I remember correctly, I never had a crash with the older version of the driver, so it MUST be the ATI stuff that freezes. Andras === Major Andras e-mail: [EMAIL PROTECTED] www:http://andras.webhop.org/ === ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] G++ 2.95/Cygwin problem?
David Megginson writes: >> > It is proper ANSI C++, and neither G++ 3.2 nor MSVC++ seems to have > any problem with it, but perhaps G++ 2.95 in Linux or Cygwin isn't > initializing the vector properly It is quite easy to check code for portability between libStdC++ versions http://gcc.gnu.org/fom_serv/cache/14.html On current Cygwin installations one need only do c++ test.cxx // calls 3.2 compiler uses libstdc++-3 c++-2 test.cxx // calls 2.95 compiler uses libstdc++-2 Regards Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: New Menu Bar; dialogs for clouds, winds, and air
Norman Vine writes: > Do the > LatLonFormatToggle > or the > AutoPilotAdjuster > > Work for anybody ??? I'll try to hunt down the problem with these. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ANN: New Menu Bar; dialogs for clouds, winds, and air
Michael Basler writes: > > What versions of plib and G++ are you using? > > PLIB CVS as of today. GCC 2.95. I have a guess about what the problem might be -- it could be an STL problem in 2.95. If so, I should be able to work around it. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Missing return value in menubar.cxx
From: "David Megginson" <[EMAIL PROTECTED]> > Frederic Bouvier writes: > > > MSVC says that 'FGMenuBar::fireItem (puObject * item)' in menubar.cxx(335) > > is missing a return value and I am afraid it is right. > > Quite right -- I'll change its return value to void and check in a > fixed version of menubar.[ch]xx. > > Unfortunately, that problem wouldn't explain the crash Curt is seeing. BTW, checking my actual local mods, there is also a missing value in panel.cxx in the doMouseAction function line 586. I also have a problem where options.cxx has too many levels of imbrication in parse_option (max is 128). There are too many 'else if' construct. Can we think about another scheme to parse options (iterating on an array or an XML file) ? Cheers, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] G++ 2.95/Cygwin problem?
I've been trying to hunt down why G++ 2.95/Cygwin might be having a runtime problem with menubar.[ch]xx. Could this line from menubar.hxx be causing the problem? map > _bindings; It is proper ANSI C++, and neither G++ 3.2 nor MSVC++ seems to have any problem with it, but perhaps G++ 2.95 in Linux or Cygwin isn't initializing the vector properly (I seem to recall that its C++ support is a bit marginal). I could always change it to map *> _bindings; I'd need to add a bit more code for allocators and destructors, but it wouldn't be a big deal. Before I do this, though, can anyone confirm whether this is likely to be the problem? Thanks, David p.s. Now why do I prefer coding in Java, again? -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ANN: New Menu Bar; dialogs for clouds, winds, and air
David, > What versions of plib and G++ are you using? PLIB CVS as of today. GCC 2.95. Regards, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: New Menu Bar; dialogs for clouds, winds, and air
Do the
LatLonFormatToggle
or the
AutoPilotAdjuster
Work for anybody ???
FWIW I added some printfs() and it does not appear if either
of their 'launchers' is ever fired()
Note:
The AddWayPoint and PopWayPoint 'launchers' do print
their debug messages
Norman
extern void AddWayPoint (puObject *);
static bool
do_ap_add_waypoint_dialog (const SGPropertyNode * arg)
{
cout << "do_ap_add_waypoint_dialog" << endl;
AddWayPoint(0);
return true;
}
extern void PopWayPoint (puObject *);
static bool
do_ap_pop_waypoint_dialog (const SGPropertyNode * arg)
{
cout << "do_ap_pop_waypoint_dialog" << endl;
PopWayPoint(0);
return true;
}
extern void fgAPAdjust (puObject *);
static bool
do_ap_adjust_dialog (const SGPropertyNode * arg)
{
cout << "do_ap_adjust_dialog" << endl;
fgAPAdjust(0);
return true;
}
extern void fgLatLonFormatToggle (puObject *);
static bool
do_lat_lon_format_dialog (const SGPropertyNode * arg)
{
cout << "do_lat_lon_format_dialog" << endl;
fgLatLonFormatToggle(0);
return true;
}
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Missing return value in menubar.cxx
Frederic Bouvier writes: > MSVC says that 'FGMenuBar::fireItem (puObject * item)' in menubar.cxx(335) > is missing a return value and I am afraid it is right. Quite right -- I'll change its return value to void and check in a fixed version of menubar.[ch]xx. Unfortunately, that problem wouldn't explain the crash Curt is seeing. Thanks, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: New Menu Bar; dialogs for clouds, winds, and air
From: "Michael Basler" <[EMAIL PROTECTED]> > Curt, > > > With the new "Air" dialog box, I'm running into a segfault. What I do > > to trigger the crash is first bringe up the "Air" dialog box, then I > > examine the data and decide I don't want to change anything, then I > > click ok. > ... > > Seems to double my observation. Obviously it's not a Cygwin thingy, as I > supposed at first. I am not seeing that with my MSVC build. I can see the weather boxes and click on OK without problems. But (see my previous post) there is a function that needs a return value. I added 'return false;' to fireItem in FGMenuBar and perhaps this is your problem with gcc. Cheers, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Animation glitches
Michael Basler writes: > > With recent code changes, I'm seeing a significant pause in the > > animation about every 2 seconds. This is enough to create a break in > > the audio with every pause. I don't think this is just my machine. > > Is any one else seeing this in the latest CVS? If it's not just me, > > we need to track down where it is coming from because it is immensely > > annoying! > > Not me. Neither animation nor sound pauses (at least none I can perceive). Ditto -- if anything, things are running smoother than before. I haven't added anything that runs every frame; perhaps you should look at some of the recent ATC audio changes in case they're interacting badly with your system. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ANN: New Menu Bar; dialogs for clouds, winds, and air
Michael Basler writes: > > With the new "Air" dialog box, I'm running into a segfault. What I do > > to trigger the crash is first bringe up the "Air" dialog box, then I > > examine the data and decide I don't want to change anything, then I > > click ok. > ... > > Seems to double my observation. Obviously it's not a Cygwin thingy, as I > supposed at first. What versions of plib and G++ are you using? Thanks, and all the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animation glitches
From: "Curtis L. Olson" <[EMAIL PROTECTED]> > With recent code changes, I'm seeing a significant pause in the > animation about every 2 seconds. This is enough to create a break in > the audio with every pause. I don't think this is just my machine. > Is any one else seeing this in the latest CVS? If it's not just me, > we need to track down where it is coming from because it is immensely > annoying! I am not seeing that with my fresh MSVC build Cheers, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: New Menu Bar; dialogs for clouds,winds, and air
Curtis L. Olson writes: > With the new "Air" dialog box, I'm running into a segfault. What I do > to trigger the crash is first bringe up the "Air" dialog box, then I > examine the data and decide I don't want to change anything, then I > click ok. > > > The back trace lists a bunch of internal PUI calls and then dies in > GUI/dialog.cc:action_callback(), specifically at line #24. I'm > guessing that info->bindings[i] doesn't have a valid object so when it > tries to call the fire() method it segfaults. > > Is that enough for you to go on, or should I dig deeper and find > additional info for you? > > I'm getting this exact same behavior all three weather dialog boxes. I can guess at a couple of possibilities -- first, if you're using G++ 2.95, the STL stuff could be broken somehow; and second, if you're using plib 1.6 rather than the CVS head, there could be a bug with the userdata that was fixed later. Could you add a few print statements around the problem line and let me know what you see? Thanks, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Missing return value in menubar.cxx
MSVC says that 'FGMenuBar::fireItem (puObject * item)' in menubar.cxx(335) is missing a return value and I am afraid it is right. Cheers, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Animation glitches
Curt, > With recent code changes, I'm seeing a significant pause in the > animation about every 2 seconds. This is enough to create a break in > the audio with every pause. I don't think this is just my machine. > Is any one else seeing this in the latest CVS? If it's not just me, > we need to track down where it is coming from because it is immensely > annoying! Not me. Neither animation nor sound pauses (at least none I can perceive). Regards, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Animation glitches
With recent code changes, I'm seeing a significant pause in the animation about every 2 seconds. This is enough to create a break in the audio with every pause. I don't think this is just my machine. Is any one else seeing this in the latest CVS? If it's not just me, we need to track down where it is coming from because it is immensely annoying! Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ANN: New Menu Bar; dialogs for clouds, winds, and air
Curt, > With the new "Air" dialog box, I'm running into a segfault. What I do > to trigger the crash is first bringe up the "Air" dialog box, then I > examine the data and decide I don't want to change anything, then I > click ok. ... Seems to double my observation. Obviously it's not a Cygwin thingy, as I supposed at first. Regards, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: New Menu Bar; dialogs for clouds,winds, and air
David, With the new "Air" dialog box, I'm running into a segfault. What I do to trigger the crash is first bringe up the "Air" dialog box, then I examine the data and decide I don't want to change anything, then I click ok. The back trace lists a bunch of internal PUI calls and then dies in GUI/dialog.cc:action_callback(), specifically at line #24. I'm guessing that info->bindings[i] doesn't have a valid object so when it tries to call the fire() method it segfaults. Is that enough for you to go on, or should I dig deeper and find additional info for you? I'm getting this exact same behavior all three weather dialog boxes. Thanks, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: New Menu Bar; dialogs for clouds,winds, and air
Curtis L. Olson writes: > I'm not sure your thinking on this, but the "Reset" option has > disappeared. That's kind of nice if you want to do a complete reset > of everything. I put the support in C++, but left it out of the XML by accident. It's there now. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: New Menu Bar; dialogs for clouds,winds, and air
Bernie Bright writes: > The weather dialogs are not found unless the FG_ROOT environment variable is > set. Shouldn't this really be globals->get_fg_root() ? Good catch, thanks. It's fixed now. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Question about Mac os X 10.2 fg development
Ima Sudonim writes: > Is the new version of PLIB required or optional for the fg source > downloaded from cvs by the latest changes? Are there any changes to > the SL directory that are required by flightgear? The CVS version of plib is optional, but you won't get scripting support without it (that will matter only to developers right now). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
