[brailleblaster] Re: Debugging
- From: "qubit" <lauraeaves@xxxxxxxxx>
- To: <brailleblaster@xxxxxxxxxxxxx>
- Date: Mon, 28 Feb 2011 09:20:31 -0600
On the subject of debugging logs, one of the compiler projects I used to
work on started with a general log that could be turned on and off, and
evolved into something like what you are talking about, with debugging
levels, only in our case the user could specify not just the verbosity, but
recorded what phase of compilation was being performed. For example, on the
command line it was -DDEBUG to conditionally compile the debugging code into
the compiler, and also add flags to bump the level counter for verbosity of
debugging for a specified part of the compiler (parsing, type checking, code
generation, inline expansion, etc etc).
If the command line created too much unuseful verbage, the user could also
turn the debugging flags on and off in comments inside the compiler, or as
commands in the interpreter.
(I know most of the software I worked on was batch commands, but the perhaps
some of the coding strategies are useful.
--le
----- Original Message -----
From: "Michael Whapples" <mwhapples@xxxxxxx>
To: <brailleblaster@xxxxxxxxxxxxx>
Sent: Monday, February 28, 2011 7:39 AM
Subject: [brailleblaster] Re: Debugging
Logging should not always be on as this can affect performance due to
outputting all the messages and the volume of output. As for where
logging information goes, probably a sensible default might be a log
file, possibly in the brailleblaster directory, although another
location may be better as BrailleBlaster potentially may be in a read
only location. May be near where the user's BrailleBlaster configuration is.
Both of those choices should be controlled by a configuration, you are
simply providing a default (IE. a configuration file being provided not
controlled from BrailleBlaster code). However it may be desirable for
BrailleBlaster to be able to adjust the logging level and so provide an
easy way for the user to alter the level.
As for what should be logged, possibly a question with no definite
answer. Remember the various levels, certain people may only want to see
certain information.
While orca is written in python and not java, I think the debug module
of orca may provide a suitable example which I have to hand. It defines
the following levels like so:
# Used to describe events of considerable importance and which will prevent
# normal program execution.
#
LEVEL_SEVERE = 1000
# Used to decribe events of interest to end users or system managers or
which
# indicate potential problems, but which Orca can deal with without
crashing.
#
LEVEL_WARNING = 900
# Used to indicate reasonably significant messages that make sense to
end users
# and system managers.
#
# For the purposes of Orca, LEVEL_INFO means display the text being sent to
# speech and braille.
#
LEVEL_INFO = 800
# Used to indicate static configuration information to assist in debugging
# problems that may be associated with a particular configuration.
#
# For the purposes of Orca, LEVEL_CONFIGURATION means display the various
# apsects of whether a particular feature (e.g., speech, braille, etc.)
# is enabled or not as well as details about that feature.
#
LEVEL_CONFIGURATION = 700
# Used for lowest volume of detailed tracing information.
#
# For the purposes of Orca, this is braille and keyboard input, script
# activation and deletion, locus of focus changes, and visual changes
# to the locus of focus.
#
LEVEL_FINE = 600
# Used for medium volume of detailed tracing information.
#
# For the purposes of Orca, this is for debugging speech and braille
# generators and tracking the synthesis of device events.
#
LEVEL_FINER = 500
# Used for maximum volume of detailed tracing information.
#
# For the purposes of Orca, this is for tracking all AT-SPI object
# events. NOTE that one can up the debug level of AT-SPI object
# events by setting the eventDebugLevel. In addition, one can filter
# events by setting eventDebugFilter to a regular expression that
# matches event type names.
#
LEVEL_FINEST = 400
Michael Whapples
On 28/02/11 13:23, John J. Boyer wrote:
> Sounds good. How do I know what to log? Should the logger be always on?
> Where should it put its files?
>
> John
>
> On Mon, Feb 28, 2011 at 12:57:35PM +0000, Michael Whapples wrote:
>> Of course its still useful for a GUI application. Think of the support
>> request:
>> "I do something and it does something unusual"
>> You cannot reproduce what they report, what do you do to help them? If
>> logging is implemented then a log file can be produced and sent to you.
>>
>> Logging is great in this respect as internally in the application you
>> just use a logger, the configuration tells it what should be done with
>> the logging information.
>>
>> Michael Whapples
>> On 28/02/11 12:56, John J. Boyer wrote:
>>> I'm wondering how important logging is for an application that is
>>> primarily a GUI. Of course it also has command-line functions. Lotting
>>> might be nice to use with CLI.
>>>
>>> John
>>>
>>> On Mon, Feb 28, 2011 at 07:29:52AM -0500, Sina Bahram wrote:
>>>> Log4j is really easy to use though, and is rather wonderful for
>>>> logging,
>>>> if that's what's necessary of course.
>>>>
>>>> Take care,
>>>> Sina
>>>>
>>>> -----Original Message-----
>>>> From: brailleblaster-bounce@xxxxxxxxxxxxx
>>>> [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Michael
>>>> Whapples
>>>> Sent: Monday, February 28, 2011 5:36 AM
>>>> To: brailleblaster@xxxxxxxxxxxxx
>>>> Subject: [brailleblaster] Re: Debugging
>>>>
>>>> Might you really be wanting logging?
>>>>
>>>> The java logging API in the JDK will probably be sufficient although
>>>> there are alternatives like log4j, etc.
>>>>
>>>> Logging has much finer control over what error messages get output and
>>>> where they go (eg. levels like finest, finer, fine, config, info,
>>>> warning and severe). I think extra custom levels can be defined
>>>> although
>>>> the documentation seems to advise against that unless really needed.
>>>>
>>>> Also logging allows you to have multiple loggers which can be set to
>>>> log
>>>> at different levels (eg. the documentation suggests a logger per
>>>> class).
>>>>
>>>> Also it is worth noting the following usage:
>>>>
>>>> if (logger.isLoggable(Level.FINE)) {
>>>> logger.log(Level.FINE, "Message to be logged");
>>>> }
>>>>
>>>> While the log method of the Logger class will test if the level allows
>>>> logging out, the additional if statement may improve performance as it
>>>> saves any preparation to construct the message (eg. concatenation of
>>>> strings).
>>>>
>>>> Configuration of the logging API can be done using system properties or
>>>> a properties file.
>>>>
>>>> Also logging was mentioned before to you. Generally logging is easiest
>>>> to implement at the time of writing the code rather than to add it in
>>>> later.
>>>>
>>>> Michael Whapples
>>>> On 28/02/11 08:09, John J. Boyer wrote:
>>>>> First, in response to Michael's last message, BrailleBlaster will
>>>>> present the user with a dialog box asking if she wants to continue,
>>>>> change settings read a startup tutorial, see a quick-start guide, etc.
>>>>> Finallyt it will have a checkbox with the message "Do not show me this
>>>>> message again."
>>>>>
>>>>> On to debugging. Can I call BrailleBlaster with the command:
>>>>>
>>>>> java -Ddebug=yes -jar brailleblaster.jar
>>>>>
>>>>> and later have the code
>>>>>
>>>>> String debug System.getProperty ("debug")
>>>>>
>>>>> The immediate reason for this is that I catch the UnsatisfiedLinkError
>>>>> exception if the liblouisutdml library is not found and set a boolean
>>>>> for the rest of the program. However this error could also be caused
>>>>> if
>>>>> one of its dependencies is not found. In this case I want to see the
>>>>> message. There will certainly be other reasons for wanting a debug
>>>>> flag.
>>>>>
>>>>> Thanks,
>>>>> John
>>>>>
>>>>
Other related posts:
