Discussion:
gb.logging API change
(too old to reply)
Sebastian Kulesz
2013-12-16 03:14:48 UTC
Permalink
I just commited an update to the gb.logging component. Please note that a
call to Logger.Begin() is no longer necessary and will fail. The log is
automatically opened for writing when creating the logger.

A recent change, too, is the ability to use the component without creating
a Logger instance. If you call Logger.Log(...) a new, hidden instance will
be created for you. This is useful if you only need one Logger and use it
in multiple Modules/Classes of you application. It will save you a public
variable and a few LOC.

Also, it is now possible to redirect the Logger output to stderr ;)

Hope you like it! Please let me know any thoughts!
Bruce
2013-12-16 06:15:24 UTC
Permalink
Post by Sebastian Kulesz
I just commited an update to the gb.logging component. Please note that a
call to Logger.Begin() is no longer necessary and will fail. The log is
automatically opened for writing when creating the logger.
A recent change, too, is the ability to use the component without creating
a Logger instance. If you call Logger.Log(...) a new, hidden instance will
be created for you. This is useful if you only need one Logger and use it
in multiple Modules/Classes of you application. It will save you a public
variable and a few LOC.
Grraaaaaagh! I just spent several hours working up a solution for
logging to a single log across multiple components/libraries.

One question, is there any change to the parameters? AKA where does the
log info get sent to when using the hidden instance?
Post by Sebastian Kulesz
Also, it is now possible to redirect the Logger output to stderr ;)
Hope you like it! Please let me know any thoughts!
I have been thinking (hard to believe!) about some kind of scheme for
logging to multiple files. Some ideas were to
a) use the cron approach i.e. 3 logs "error", "info" and "warning" but
probably "error", "info" and "debug" would be better suited to a
development system like Gambas.
b) similar to a) but allow configuration as to what level message goes
to which log.

Here on our production stuff we really need to keep errors & warnings
very separate from the info log(s) as they need high visibility (i.e. if
error.log is not empty then everyone panic!), the "info" logs are of two
types, general "this got done and that got done and this is what came
out" data and audit data (bluh!) and we really need the "debug.log" on
the dev/fix side of things.

The other thing I would like to see is a way to increase the number of
levels of detail once we get down to the "debug" level. This would be on
an application basis.

cheers
Bruce
Sebastian Kulesz
2013-12-16 13:16:48 UTC
Permalink
Post by Sebastian Kulesz
Post by Sebastian Kulesz
I just commited an update to the gb.logging component. Please note that a
call to Logger.Begin() is no longer necessary and will fail. The log is
automatically opened for writing when creating the logger.
A recent change, too, is the ability to use the component without
creating
Post by Sebastian Kulesz
a Logger instance. If you call Logger.Log(...) a new, hidden instance
will
Post by Sebastian Kulesz
be created for you. This is useful if you only need one Logger and use it
in multiple Modules/Classes of you application. It will save you a public
variable and a few LOC.
Grraaaaaagh! I just spent several hours working up a solution for
logging to a single log across multiple components/libraries.
One question, is there any change to the parameters? AKA where does the
log info get sent to when using the hidden instance?
The first time you use it, it will create the hidden instance with the
default values. As it was standing, it was impossible to change the output
of the logger, as it could only be set when creating an instance and by
default it was Stdout.

So, in the new revision you can change the format, level and output using
the logger properties. I was forced to add the Begin() call again (Sorry
about that). Once this function is called, Logger.Output can't be changed.
Post by Sebastian Kulesz
Post by Sebastian Kulesz
Also, it is now possible to redirect the Logger output to stderr ;)
Hope you like it! Please let me know any thoughts!
I have been thinking (hard to believe!) about some kind of scheme for
logging to multiple files. Some ideas were to
a) use the cron approach i.e. 3 logs "error", "info" and "warning" but
probably "error", "info" and "debug" would be better suited to a
development system like Gambas.
b) similar to a) but allow configuration as to what level message goes
to which log.
Here on our production stuff we really need to keep errors & warnings
very separate from the info log(s) as they need high visibility (i.e. if
error.log is not empty then everyone panic!), the "info" logs are of two
types, general "this got done and that got done and this is what came
out" data and audit data (bluh!) and we really need the "debug.log" on
the dev/fix side of things.
Remember you can output wherever you want and set a custom format. What i
recommend you, depending on your setup, is to either output to a file and
monitor it for changes. When one is found you look for the debug name using
regexp (remember, custom format) and copy that line to another file of your
choice. Or to pipe the output of your application to a bash script which
will scan the log for it's level name and append it to a file of your
choice.
Post by Sebastian Kulesz
The other thing I would like to see is a way to increase the number of
levels of detail once we get down to the "debug" level. This would be on
an application basis.
Done! Level can now be greater than Logger.Debug. The $(levelname) tag will
now be replaced by CUSTOM DEBUG in this case. You can use it in conjunction
with $(levelno) to describe the debug level.
Post by Sebastian Kulesz
cheers
Bruce
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gambas-user mailing list
https://lists.sourceforge.net/lists/listinfo/gambas-user
Bruce
2013-12-17 00:55:09 UTC
Permalink
Sebastian,

With the new version the $(callLocation) is always returning the same
location ("Logger._call.95").

I stuck some debug in the Formatter to print the stack backtrace, here's
what I get when using the Logger from "outside":

Formatter.GetCallLocation.10: Formatter.GetCallLocation.10
Formatter._call.45
Logger.Log.87
Logger._call.95
Application._init.57

i.e. I think you should be using System.Backtrace[4] instead of [3]

hth
Bruce
Sebastian Kulesz
2013-12-17 03:48:56 UTC
Permalink
My bad. It should be fixed in rev #6010. Please let me know!
Post by Bruce
Sebastian,
With the new version the $(callLocation) is always returning the same
location ("Logger._call.95").
I stuck some debug in the Formatter to print the stack backtrace, here's
Formatter.GetCallLocation.10: Formatter.GetCallLocation.10
Formatter._call.45
Logger.Log.87
Logger._call.95
Application._init.57
i.e. I think you should be using System.Backtrace[4] instead of [3]
hth
Bruce
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gambas-user mailing list
https://lists.sourceforge.net/lists/listinfo/gambas-user
Sebastian Kulesz
2014-12-29 04:22:07 UTC
Permalink
So, i have changed the API again. Now, each logger has an associated array
of handlers, each of which takes care of storing the data in a specific
way. Right now, the component only includes a console handler to output
logs to stdout or stderr. And a file handler to output logs to files.
Each logger can have an arbitrary amount of loggers, and they even can be
shared across loggers.
This way a several loggers can output to the same file by sharing a
handler, or a logger can output to several files, all depending on the
logging level.

Take a look at the following example:
<---------
Dim aHandler, bHandler As LogHandler

Dim bLogger As Logger

aHandler = New ConsoleHandler(ConsoleHandler.STDOUT)
bHandler = New FileHandler("~/Desktop")

bLogger = New Logger(Null, aHandler)

bLogger.Begin()

bLogger.Log("This goes to the stdout stream")

bLogger.addHandler(bHandler)
bHandler.Open

bLogger.Log("I can read this in the console or at a file stored in my
Desktop folder.")

Logger.Log("There is no need to use handlers. You can use the Logger
anonymously.")
---------->

bLogger outputs to 2 locations simultaneously. If you want, both handlers
could use a different level of severity ;)

I will be adding some more handlers in the following days.

Enjoy!
Post by Sebastian Kulesz
My bad. It should be fixed in rev #6010. Please let me know!
Post by Bruce
Sebastian,
With the new version the $(callLocation) is always returning the same
location ("Logger._call.95").
I stuck some debug in the Formatter to print the stack backtrace, here's
Formatter.GetCallLocation.10: Formatter.GetCallLocation.10
Formatter._call.45
Logger.Log.87
Logger._call.95
Application._init.57
i.e. I think you should be using System.Backtrace[4] instead of [3]
hth
Bruce
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gambas-user mailing list
https://lists.sourceforge.net/lists/listinfo/gambas-user
Benoît Minisini
2014-12-29 13:50:58 UTC
Permalink
Post by Sebastian Kulesz
So, i have changed the API again.
...
Just to warn you that you must be backward-compatible: a program using
gb.logger with Gambas 3.6 must work with the gb.logger of Gambas 3.7
without changing or recompiling anything.

If you can't be backward compatible, you must create a new component
'gb.logger2', and tell me if I should make 'gb.logger' deprecated.

Regards,
--
Benoît Minisini
Continue reading on narkive:
Loading...