From: Matthew G. <mat...@gm...> - 2007-06-22 03:30:39
|
What's the deal with the command window running in the Windows release? I assume this is because SDL used to write to stdout.txt and stderr.txt. I think a better approach would be to write console output to a log file in the user directory. On Linux it could be a copy of stdout & stderr (I find output on the tty useful when coding). Matthew |
From: Johannes G. <joh...@gm...> - 2007-06-22 19:34:37
|
On 2007.06.22 05:30:23 CEST, Matthew Gates wrote: > What's the deal with the command window running in the Windows release? I > assume this is because SDL used to write to stdout.txt and stderr.txt. Fabien has just forgotten the -mwindows compilation option. > I think a better approach would be to write console output to a log file in > the user directory. On Linux it could be a copy of stdout & stderr (I > find output on the tty useful when coding). We should get rid of the generated files: Some users have contaced me because they use stellarium installed on an USB stick. And they fear that continuous writing on the USB stick will harm it, which is true as far as I know. Johannes |
From: Matthew G. <mat...@gm...> - 2007-06-22 19:47:19
|
On Friday 22 June 2007, Johannes Gajdosik wrote: > On 2007.06.22 05:30:23 CEST, Matthew Gates wrote: > > What's the deal with the command window running in the Windows release? > > I assume this is because SDL used to write to stdout.txt and > > stderr.txt. > > Fabien has just forgotten the -mwindows compilation option. > > > I think a better approach would be to write console output to a log > > file in the user directory. On Linux it could be a copy of stdout & > > stderr (I find output on the tty useful when coding). > > We should get rid of the generated files: Some users have contaced me > because they use stellarium installed on an USB stick. And they fear that > continuous writing on the USB stick will harm it, which is true as far as > I know. If we use this -mwindows compilation option, do we see stdout and stderr when Stellarium is started from the command window? If so, we still have a method for people to send us the output. If not, then I would suggest turning off the creation of a log file by default, but enabling it with a command line option. |
From: Johannes G. <joh...@gm...> - 2007-06-22 20:20:21
|
On 2007.06.22 21:47:09 CEST, Matthew Gates wrote: > On Friday 22 June 2007, Johannes Gajdosik wrote: > > On 2007.06.22 05:30:23 CEST, Matthew Gates wrote: > > > What's the deal with the command window running in the Windows release? > > > I assume this is because SDL used to write to stdout.txt and > > > stderr.txt. > > > > Fabien has just forgotten the -mwindows compilation option. > > > > > I think a better approach would be to write console output to a log > > > file in the user directory. On Linux it could be a copy of stdout & > > > stderr (I find output on the tty useful when coding). > > > > We should get rid of the generated files: Some users have contaced me > > because they use stellarium installed on an USB stick. And they fear that > > continuous writing on the USB stick will harm it, which is true as far as > > I know. > > If we use this -mwindows compilation option, do we see stdout and stderr > when Stellarium is started from the command window? If so, we still have a > method for people to send us the output. No there is no command window, no stdout and stderr. This is the usual way for windows programs. Windows programs usually have no commandline arguments, eigther. > If not, then I would suggest turning off the creation of a log file by > default, but enabling it with a command line option. This would mean replacing all occurrences of cout, cerr in the code with something different. I suggest a macros (COUT,CERR), which then would be defined according to architecture. #ifndef WIN32 #define COUT cout #define CERR cerr #else ... Johannes |
From: <fab...@go...> - 2007-06-25 12:56:58
|
On 6/22/07, Johannes Gajdosik <joh...@gm...> wrote: > > On 2007.06.22 21:47:09 CEST, Matthew Gates wrote: > > On Friday 22 June 2007, Johannes Gajdosik wrote: > > > On 2007.06.22 05:30:23 CEST, Matthew Gates wrote: > > > > What's the deal with the command window running in the Windows > release? > > > > I assume this is because SDL used to write to stdout.txt and > > > > stderr.txt. > > > > > > Fabien has just forgotten the -mwindows compilation option. > > > > > > > I think a better approach would be to write console output to a log > > > > file in the user directory. On Linux it could be a copy of stdout > & > > > > stderr (I find output on the tty useful when coding). > > > > > > We should get rid of the generated files: Some users have contaced me > > > because they use stellarium installed on an USB stick. And they fear > that > > > continuous writing on the USB stick will harm it, which is true as far > as > > > I know. > > > > If we use this -mwindows compilation option, do we see stdout and stderr > > when Stellarium is started from the command window? If so, we still > have a > > method for people to send us the output. > > No there is no command window, no stdout and stderr. This is the usual way > for > windows programs. Windows programs usually have no commandline arguments, > eigther. > > > If not, then I would suggest turning off the creation of a log file by > > default, but enabling it with a command line option. > > This would mean replacing all occurrences of cout, cerr in the code with > something different. > I suggest a macros (COUT,CERR), which then would be defined according to > architecture. > > #ifndef WIN32 > #define COUT cout > #define CERR cerr > #else > ... No way. This would be very very messy. Anyway I think it is just fine to have a log window for windows users, it would probably improve the average bug reports quality. Now if we want to have SDL like files, we should look in SDL code how they did that. Maybe we could save those files into the /.stellarium/ directory which will also be better for the USB stick problem (which is not very critical anyway) Fabien |
From: Johannes G. <joh...@gm...> - 2007-06-25 20:13:50
|
On 2007.06.25 14:56:56 CEST, Fabien Chéreau wrote: > > #ifndef WIN32 > > #define COUT cout > > #define CERR cerr > > #else > > ... > > > No way. This would be very very messy. I have no personal interest in this matter. Just for curiosity, no fighting: what is so messy about writing COUT instead of cout? Johannes |
From: Matthew G. <mat...@gm...> - 2007-06-25 16:29:42
|
On Monday 25 June 2007, Fabien Ch=C3=A9reau wrote: > No way. This would be very very messy. > > Anyway I think it is just fine to have a log window for windows users, it > would probably improve the average bug reports quality.=20 I don't agree. Several people have complained about it in the forums, and= =20 several people have mentioned it in bug reports for other problems, one=20 even opening a bug report for this issue specifically. It is not expected= =20 behaviour for Windows programs. Also, when Stellarium crashes, the cmd window closes, and so people cannot= =20 use this method to get output when they have the most serious problems. > Now if we want to=20 > have SDL like files, we should look in SDL code how they did that. Maybe > we could save those files into the /.stellarium/ directory which will > also be better for the USB stick problem (which is not very critical > anyway) As for the mechanism, I feel there must be a better way than using the=20 pre-processor to re-define cout & cerr. I imagine using one of two methods (for Windows): 1. At program start, internally changing the file handles for stdin, stdout= =20 and stderr to be connected to a log file rather than the console. The main= =20 body of code with calls to cout, printf and so on need not be changed. 2. Running Stellarium using a wrapper .bat file, which re-directs the outpu= t=20 (his insults my sense of style somehow, but I think it would work, and it's= =20 easy to implement). Matthew |
From: Johannes G. <joh...@gm...> - 2007-06-25 20:17:36
|
On 2007.06.25 18:29:24 CEST, Matthew Gates wrote: > As for the mechanism, I feel there must be a better way than using the > pre-processor to re-define cout & cerr. > > I imagine using one of two methods (for Windows): > > 1. At program start, internally changing the file handles for stdin, stdout > and stderr to be connected to a log file rather than the console. The main > body of code with calls to cout, printf and so on need not be changed. Can you explain how this works? I know how to do in in unix, but I would be interested in a portable way that works for windows, too. Just personal interest, nothing to do with stellarium. Johannes |
From: Matthew G. <mat...@gm...> - 2007-06-25 21:16:24
|
On Monday 25 June 2007, Johannes Gajdosik wrote: > On 2007.06.25 18:29:24 CEST, Matthew Gates wrote: > > As for the mechanism, I feel there must be a better way than using the > > pre-processor to re-define cout & cerr. > > > > I imagine using one of two methods (for Windows): > > > > 1. At program start, internally changing the file handles for stdin, > > stdout and stderr to be connected to a log file rather than the > > console. The main body of code with calls to cout, printf and so on > > need not be changed. > > Can you explain how this works? I know how to do in in unix, but I would > be interested in a portable way that works for windows, too. > Just personal interest, nothing to do with stellarium. Wouldn't this work under windows? #include <iostream> #include <cstdio> const char* outputFile = "output.log"; using namespace std; int main(int argc, char** argv) { FILE* fptr = freopen(outputFile,"w",stdout); if(!fptr){ cerr << "Could not freopen stdout for: " << outputFile << endl; } fptr = freopen(outputFile,"a",stderr); if(!fptr){ cerr << "Could not freopen stderr for: " << outputFile << endl; } cout << "This is output using cout" << endl; cerr << "This is output using cerr" << endl; return 0; } |
From: Johannes G. <joh...@gm...> - 2007-06-28 12:44:55
|
On 2007.06.25 23:15:58 CEST, Matthew Gates wrote: > On Monday 25 June 2007, Johannes Gajdosik wrote: > > On 2007.06.25 18:29:24 CEST, Matthew Gates wrote: > > > As for the mechanism, I feel there must be a better way than using the > > > pre-processor to re-define cout & cerr. > > > > > > I imagine using one of two methods (for Windows): > > > > > > 1. At program start, internally changing the file handles for stdin, > > > stdout and stderr to be connected to a log file rather than the > > > console. The main body of code with calls to cout, printf and so on > > > need not be changed. > > > > Can you explain how this works? I know how to do in in unix, but I would > > be interested in a portable way that works for windows, too. > > Just personal interest, nothing to do with stellarium. > > Wouldn't this work under windows? > > #include <iostream> > #include <cstdio> > > const char* outputFile = "output.log"; > using namespace std; > > int main(int argc, char** argv) > { > FILE* fptr = freopen(outputFile,"w",stdout); > if(!fptr){ > cerr << "Could not freopen stdout for: " << outputFile << endl; > } > > fptr = freopen(outputFile,"a",stderr); > if(!fptr){ > cerr << "Could not freopen stderr for: " << outputFile << endl; > } > > cout << "This is output using cout" << endl; > cerr << "This is output using cerr" << endl; > > return 0; > } > Thank you. Do you also have a solution that does not mix C++ streams with C stdio.h? As far as I know mixing is discouraged, although I often do it by myself. My unix-solution would have been even more lowlevel: close(1);close(2); and dup(...). By the way: Thanks for the file manager feature! It is much more conveniant to have configuration and data files in the home directory, so that they get not ruined by make install. It is just a pity it has to be implemented for each file seperately. For instance for ssystem.ini it does not yet work. Johannes |
From: Matthew G. <mat...@gm...> - 2007-06-28 13:26:14
|
On Thursday 28 June 2007, Johannes Gajdosik wrote: > On 2007.06.25 23:15:58 CEST, Matthew Gates wrote: > > Wouldn't this work under windows? > > > > #include <iostream> > > #include <cstdio> > > > > const char* outputFile = "output.log"; > > using namespace std; > > > > int main(int argc, char** argv) > > { > > FILE* fptr = freopen(outputFile,"w",stdout); > > if(!fptr){ > > cerr << "Could not freopen stdout for: " << outputFile << endl; > > } > > > > fptr = freopen(outputFile,"a",stderr); > > if(!fptr){ > > cerr << "Could not freopen stderr for: " << outputFile << endl; > > } > > > > cout << "This is output using cout" << endl; > > cerr << "This is output using cerr" << endl; > > > > return 0; > > } > > Thank you. > Do you also have a solution that does not mix C++ streams with C stdio.h? > As far as I know mixing is discouraged, although I often do it by myself. There may well be one. This is the first thing I could find. If we really do want to use a method like this for writing to a log file instead of the cmd window, I'd be happy to search for a more C++ solution. Having said that, Stellarium still has quite a mixture of stdio and iostream throughout the code, so I doubt it's too much to worry about. > My unix-solution would have been even more lowlevel: close(1);close(2); > and dup(...). > > By the way: Thanks for the file manager feature! It is much more > conveniant to have configuration and data files in the home directory, so > that they get not ruined by make install. I can't take credit for the idea - it was a person called Lippo who suggested it, although he vanished after I mailed him a few times, so I completed the implementation myself. > It is just a pity it has to be implemented for each file seperately. I think I changed it for all existing files, so there is only work for new files now. > For instance for ssystem.ini it does not yet work. Strange, it works for me. Did you place your modified file in the data sub-directory of your ~/.stellarium directory? The only other reason I can think of for a failure to find the file is incorrect permissions on the file. > Johannes > Matthew |