On Wed, Jun 14, 2017 at 07:21:21PM +0200, Christophe de Dinechin wrote:
> > At this point, I would say that any of the 2 approaches are an
> > improvement over the current code. I'm also unconvinced that we have to
> > have support for tweaks,
>
> But do you have any good argument for depriving
Hi
- Original Message -
>
> > (fwiw, I prefer the shorter version…)
>
> Remember that the dump only shows up in case of crash.
>
> Are you arguing problems are easier to debug with less data?
Yes, less noise, but relevant data. Saying that becuase your short version is
already full of
> On 14 Jun 2017, at 19:53, Marc-André Lureau
> wrote:
>
> Hi
>
> - Original Message -
c) Bugs which we have to be able to reproduce, because there is no
useful information in the debug log, e.g.
Hi
- Original Message -
> >> c) Bugs which we have to be able to reproduce, because there is no
> >> useful information in the debug log, e.g.
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1017261. Here, we know an
> >> assertion failed, but nothing about what happened to get there, so
> On 14 Jun 2017, at 17:06, Christophe Fergeau wrote:
>
> On Wed, Jun 14, 2017 at 10:44:49AM +0200, Christophe de Dinechin wrote:
>>
>>> On 13 Jun 2017, at 12:17, Marc-André Lureau
>>> wrote:
>>>
>>
- Better memory locality (not
On Wed, Jun 14, 2017 at 10:44:49AM +0200, Christophe de Dinechin wrote:
>
> > On 13 Jun 2017, at 12:17, Marc-André Lureau
> > wrote:
> >
>
> >> - Better memory locality (not wasting a whole cache line for a single flag)
> >
> > minor, because log is not for hot
Hi,
On Wed, Jun 14, 2017 at 10:44:49AM +0200, Christophe de Dinechin wrote:
>
> > On 13 Jun 2017, at 12:17, Marc-André Lureau
> > wrote:
>
> >> - Better memory locality (not wasting a whole cache line for a single flag)
> >
> > minor, because log is not for hot
> On 13 Jun 2017, at 12:17, Marc-André Lureau
> wrote:
>
>> - Better memory locality (not wasting a whole cache line for a single flag)
>
> minor, because log is not for hot traces.
My experience differs from yours, and as a result, the idea that “log is not
> On 13 Jun 2017, at 11:41, Christophe Fergeau wrote:
>
> On Tue, Jun 13, 2017 at 11:26:46AM +0200, Christophe de Dinechin wrote:
>>>
Let's first see if we manage to add useful debug logs to both the client
and the server, then we can look into adding this :)
>>
Hi
- Original Message -
> Global declarations pros:
> - Obeys the DRY principle, as opposed to WET category declarations
> (e.g. SPICE_LOG_CATEGORY_DECLARE vs. SPICE_LOG_CATEGORY)
True, but SPICE_LOG_CATEGORY_DECLARE should not be needed, I'd rather remove it.
> - Makes it possible to
Hi,
On Tue, Jun 13, 2017 at 04:42:27AM -0400, Marc-André Lureau wrote:
> Hi
>
> - Original Message -
> > On Tue, Jun 13, 2017 at 09:45:20AM +0200, Christophe de Dinechin wrote:
> > > > 5. The spice_log_init deals with hard-coded variables in a
> > > > hard-coded way. I purposely had a
> On 13 Jun 2017, at 09:59, Frediano Ziglio wrote:
>
> I have strange feelings about this series.
>
> First you removed most of logging test and change the entirely logging.
> This is for me an enough reason for a nack. Usually the test define
> the behaviour of the API (in
On Tue, Jun 13, 2017 at 11:26:46AM +0200, Christophe de Dinechin wrote:
> >
> >> Let's first see if we manage to add useful debug logs to both the client
> >> and the server, then we can look into adding this :)
>
> I agree. I was explaining why I had made a choice to have a dedicated
>
> On 13 Jun 2017, at 10:42, Marc-André Lureau
> wrote:
>
> Hi
>
> - Original Message -
>> On Tue, Jun 13, 2017 at 09:45:20AM +0200, Christophe de Dinechin wrote:
5. The spice_log_init deals with hard-coded variables in a
hard-coded way. I
Hi
- Original Message -
> I have strange feelings about this series.
>
> First you removed most of logging test and change the entirely logging.
> This is for me an enough reason for a nack. Usually the test define
> the behaviour of the API (in this case logging) and the fact you have
>
On Tue, Jun 13, 2017 at 03:59:06AM -0400, Frediano Ziglio wrote:
> I have strange feelings about this series.
>
> First you removed most of logging test and change the entirely logging.
> This is for me an enough reason for a nack. Usually the test define
> the behaviour of the API (in this case
On Tue, Jun 13, 2017 at 09:45:20AM +0200, Christophe de Dinechin wrote:
> > 5. The spice_log_init deals with hard-coded variables in a
> > hard-coded way. I purposely had a function taking a string, and
> > called either with env vars or command line options. I was thinking
> > long-term about
On Mon, Jun 12, 2017 at 09:32:38PM +, Marc-André Lureau wrote:
> Hi
>
> On Mon, Jun 12, 2017 at 9:11 PM Christophe de Dinechin
> wrote:
>
> >
> > > On 12 Jun 2017, at 10:19, marcandre.lur...@redhat.com wrote:
> > >
> > > From: Marc-André Lureau
I have strange feelings about this series.
First you removed most of logging test and change the entirely logging.
This is for me an enough reason for a nack. Usually the test define
the behaviour of the API (in this case logging) and the fact you have
to change a lot means that the new one is
> On 12 Jun 2017, at 10:19, marcandre.lur...@redhat.com wrote:
>
> From: Marc-André Lureau
>
> Hi,
>
> This is a RFC series to clean-up Spice logging infrastructure to fully
> rely on glib g_log & g_log_structured if available, and add logging
> categories. It is
20 matches
Mail list logo