
Dear all, I redirect stdout and stderr to a file when running mkgmap, and then incorporate the file in a build log file that holds the output from my whole build process. I redirect using > mkgmap.log 2>& 1 at the end of the command line, however, I seem to get a few files of the form mkgmap.log.0, mkgmap.log.1 etc each containing just a few lines of echotags output. I suspect that this is due to System.out.println not being thread safe, and if two threads try to write at the same time, one of them ends up creating a separate file. I therefore suggest that we might consider using logging, which is thread safe, rather than System.out.println. There are also a number of other instances of error and warning messages being written using System.out.println, and System.err.println, but most use logging. I think we should standardise on one mechanism for outputting messages. Replacing all the calls to System.out.println and System.err.println would allow proper control using the -Dlog.config switch, which doesn't affect System.out.println and System.err.println calls, and allow all output to be directed to a file directly with that switch, instead of having to use redirection. Because the log.config file allows multiple handlers, this would not prevent the splitting of basic information to stdout with debug information going to a file, if that is required. Thoughts? Regards, Mike

Hi Mike, I don't understand what you mean. We already have Logger.java and the typical usage is that a class starts with private static final Logger log = Logger.getLogger(WrongAngleFixer.class); and usage is like log.error("boundary node is replaced by node with non-equal coordinates at", toRepl.toOSMURL()); See also https://wiki.openstreetmap.org/wiki/Mkgmap/dev#Enabling_Debugging What I don't like is that there is no hint about this functionality, even when user adds --verbose. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Donnerstag, 15. März 2018 10:32:48 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] stdout, stderr and logging Dear all, I redirect stdout and stderr to a file when running mkgmap, and then incorporate the file in a build log file that holds the output from my whole build process. I redirect using > mkgmap.log 2>& 1 at the end of the command line, however, I seem to get a few files of the form mkgmap.log.0, mkgmap.log.1 etc each containing just a few lines of echotags output. I suspect that this is due to System.out.println not being thread safe, and if two threads try to write at the same time, one of them ends up creating a separate file. I therefore suggest that we might consider using logging, which is thread safe, rather than System.out.println. There are also a number of other instances of error and warning messages being written using System.out.println, and System.err.println, but most use logging. I think we should standardise on one mechanism for outputting messages. Replacing all the calls to System.out.println and System.err.println would allow proper control using the -Dlog.config switch, which doesn't affect System.out.println and System.err.println calls, and allow all output to be directed to a file directly with that switch, instead of having to use redirection. Because the log.config file allows multiple handlers, this would not prevent the splitting of basic information to stdout with debug information going to a file, if that is required. Thoughts? Regards, Mike _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Mike, sorry, that was too fast. Of course you already know the logging functionality. I think one reason for using system.err.println() instead of log.error() is that log.error() adds a prefix which is not always wanted. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Donnerstag, 15. März 2018 10:41:29 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] stdout, stderr and logging Hi Mike, I don't understand what you mean. We already have Logger.java and the typical usage is that a class starts with private static final Logger log = Logger.getLogger(WrongAngleFixer.class); and usage is like log.error("boundary node is replaced by node with non-equal coordinates at", toRepl.toOSMURL()); See also https://wiki.openstreetmap.org/wiki/Mkgmap/dev#Enabling_Debugging What I don't like is that there is no hint about this functionality, even when user adds --verbose. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Donnerstag, 15. März 2018 10:32:48 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] stdout, stderr and logging Dear all, I redirect stdout and stderr to a file when running mkgmap, and then incorporate the file in a build log file that holds the output from my whole build process. I redirect using > mkgmap.log 2>& 1 at the end of the command line, however, I seem to get a few files of the form mkgmap.log.0, mkgmap.log.1 etc each containing just a few lines of echotags output. I suspect that this is due to System.out.println not being thread safe, and if two threads try to write at the same time, one of them ends up creating a separate file. I therefore suggest that we might consider using logging, which is thread safe, rather than System.out.println. There are also a number of other instances of error and warning messages being written using System.out.println, and System.err.println, but most use logging. I think we should standardise on one mechanism for outputting messages. Replacing all the calls to System.out.println and System.err.println would allow proper control using the -Dlog.config switch, which doesn't affect System.out.println and System.err.println calls, and allow all output to be directed to a file directly with that switch, instead of having to use redirection. Because the log.config file allows multiple handlers, this would not prevent the splitting of basic information to stdout with debug information going to a file, if that is required. Thoughts? Regards, Mike _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

HI Gerd, what I mean is that most of the code uses logger, but there are some bits of code that don't use it, using System.out.println or System.err.println, fairly arbitrarily instead. I was suggesting that these move to use logger. e.g. in imgfmt.app.typ.TypData.java: System.out.println("WARNING: SortCode in TYP txt file different from" + " command line setting"); in mkgmap.build.LocatorConfig.java: System.out.println(fileName + "contains invalid root tag " + rootNode.getNodeName()); in mkgmap.osmstyle.actions.EchoAction.java System.err.println(className + (FakeIdGenerator.isFakeId(el.getId()) ? " generated from " : " ") + el.getOriginalId() + " " + e); Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 15 March 2018 09:41 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] stdout, stderr and logging Hi Mike, I don't understand what you mean. We already have Logger.java and the typical usage is that a class starts with private static final Logger log = Logger.getLogger(WrongAngleFixer.class); and usage is like log.error("boundary node is replaced by node with non-equal coordinates at", toRepl.toOSMURL()); See also https://wiki.openstreetmap.org/wiki/Mkgmap/dev#Enabling_Debugging What I don't like is that there is no hint about this functionality, even when user adds --verbose. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Donnerstag, 15. März 2018 10:32:48 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] stdout, stderr and logging Dear all, I redirect stdout and stderr to a file when running mkgmap, and then incorporate the file in a build log file that holds the output from my whole build process. I redirect using > mkgmap.log 2>& 1 at the end of the command line, however, I seem to get a few files of the form mkgmap.log.0, mkgmap.log.1 etc each containing just a few lines of echotags output. I suspect that this is due to System.out.println not being thread safe, and if two threads try to write at the same time, one of them ends up creating a separate file. I therefore suggest that we might consider using logging, which is thread safe, rather than System.out.println. There are also a number of other instances of error and warning messages being written using System.out.println, and System.err.println, but most use logging. I think we should standardise on one mechanism for outputting messages. Replacing all the calls to System.out.println and System.err.println would allow proper control using the -Dlog.config switch, which doesn't affect System.out.println and System.err.println calls, and allow all output to be directed to a file directly with that switch, instead of having to use redirection. Because the log.config file allows multiple handlers, this would not prevent the splitting of basic information to stdout with debug information going to a file, if that is required. Thoughts? Regards, Mike _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (2)
-
Gerd Petermann
-
Mike Baggaley