Alec leamas a écrit :
Ah, we got a discussion :-)
Yes :-)
Summarizing advantages: Aurelien sees the config file and the
more fine grained phapi logging, Andreas the console logging
and I an established design pattern.
I don't understand what you mean with "console logging" being an
adva
Ah, we got a discussion :-)
Summarizing advantages: Aurelien sees the config file and the
more fine grained phapi logging, Andreas the console logging
and I an established design pattern.
And the basic con: That this is a big change, not an
incremental path. After reading Dave's article I th
Vadim Lebedev a écrit :
Aurélien Gâteau wrote:
I see two advantages to your work:
- It's now possible to configure the logging from a configuration file.
- You can configure phapi logging in a more fine grained way.
What I don't see is why these changes couldn't have been implemented
witho
Aurélien Gâteau wrote:
I see two advantages to your work:
- It's now possible to configure the logging from a configuration file.
- You can configure phapi logging in a more fine grained way.
What I don't see is why these changes couldn't have been implemented
without rewriting everything.
Alec leamas a écrit :
With this said, it's really hard for me to see an incremental
path leading from today's logging system to something which
works along the lines I think we need. After all, it's kind of
a refactoring, and such things can't really be done in that
many steps. I *have* divid
Alec leamas a écrit :
With this said, it's really hard for me to see an incremental
path leading from today's logging system to something which
works along the lines I think we need. After all, it's kind of
a refactoring, and such things can't really be done in that
many steps. I *have* divid
Alec leamas a écrit :
With this said, it's really hard for me to see an incremental
path leading from today's logging system to something which
works along the lines I think we need. After all, it's kind of
a refactoring, and such things can't really be done in that
many steps. I *have* divid
Hi,
Alec leamas wrote:
> With this said, it's really hard for me to see an incremental
> path leading from today's logging system to something which
> works along the lines I think we need. After all, it's kind of
> a refactoring, and such things can't really be done in that
> many steps. I
Painful? Not really :-) As I said, earlier: you should not
apologize for doing our job. And at the moment you are taking a
code review personally, you are in deep trouble. I certainly
don't :-)
With this said, it's really hard for me to see an incremental
path leading from today's logging sys
Hi Alec,
Alec leamas wrote:
> I posted a message about logging some days ago. Basically,
> I've done a patch, and needs a decision on if it should be
> included or not.
I haven't tried your patch yet - is this the patch attached to ticket #1856?
> In short, the patch can be described like th
Alec leamas a écrit :
I posted a message about logging some days ago. Basically,
I've done a patch, and needs a decision on if it should be
included or not. There was no remarks on my previous message,
question is how to interpret this: that everybody agrees, or
that no one cares ? ;-)
Aure
>
>> - Using the log4j/log4cc model means that the conceptual
>> model is a well established design pattern. So things
>> tends to fit. This spans from the new patch actually
>> implementing the large commentary in our logging
>> header, to that the phapi interface fits other frame-
>>
Alec leamas wrote:
> I posted a message about logging some days ago. Basically,
> I've done a patch, and needs a decision on if it should be
> included or not. There was no remarks on my previous message,
> question is how to interpret this: that everybody agrees, or
> that no one cares ? ;-)
I posted a message about logging some days ago. Basically,
I've done a patch, and needs a decision on if it should be
included or not. There was no remarks on my previous message,
question is how to interpret this: that everybody agrees, or
that no one cares ? ;-)
Aurelien feels that this re
Although recent imrovements, I think there is a need to enhance
the logging system. Logging is kind of boring, but the
importance should not be underestimated. Specifically, working
the open source way with users out there doing the testing, we
need better logging than we we have had. And possi
Aurélien Gâteau wrote:
> I just committed my logging changes, as well as support for OWLOGGER_DEFAULT
> environment variable. I also documented the usage of the environment
> variables in a new file named DEBUGGING.txt.
Great work, thanks!
-- andreas
>
> Aurélien
> ___
I just committed my logging changes, as well as support for OWLOGGER_DEFAULT
environment variable. I also documented the usage of the environment
variables in a new file named DEBUGGING.txt.
Aurélien
___
Wengophone-devel mailing list
Wengophone-devel@l
On Thursday 18 October 2007 16:00:52 Dave Neary wrote:
> Hi,
>
> Aurélien Gâteau wrote:
> > Attached patches implement this. It would be nice to have your opinion on
> > them. Note that it will cause a big recompile, since it changes Logger.h
> > :-/
> >
> > One thing I would like to add is support
Hi,
Aurélien Gâteau wrote:
> Attached patches implement this. It would be nice to have your opinion on
> them. Note that it will cause a big recompile, since it changes Logger.h :-/
>
> One thing I would like to add is support for a OWLOGGER_DEFAULT environment
> variable, which would define t
On Monday 15 October 2007 15:57:40 Alec leamas wrote:
> First of all. logging is important, a primary tool to find out
> and handle problems. It's worth some time.
>
> Secondly, I think we need to implement the specified ways to
> limit and route the output.
Agreed.
> And, this is the complicated
I've been thinking about logging for some time, while doing
other things. Basically, I see some issues
- Far to much output for end users (isn't there a ticket
about this?), so
- End users are likely to miss important messages.
- Developers also suffers from to much output, it's a bit
har
21 matches
Mail list logo
