On Mon, Apr 15, 2013 at 09:42:21PM -0700, David Strauss wrote:
> I thought he did that in this thread:
> [systemd-devel] [PATCH] python-systemd: Reader return special fields
> and _Reader changes
Oh, I missed that.
> Also, feel free to commit. I don't have my home machine set up for
> committing e
I thought he did that in this thread:
[systemd-devel] [PATCH] python-systemd: Reader return special fields
and _Reader changes
Also, feel free to commit. I don't have my home machine set up for
committing emails from this list.
On Mon, Apr 15, 2013 at 7:53 PM, Zbigniew Jędrzejewski-Szmek
wrote:
On Tue, Apr 16, 2013 at 01:40:44AM +0200, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Apr 15, 2013 at 01:52:48PM -0700, David Strauss wrote:
> > In other words, let's commit this today. :-)
> I concur. I haven't actually applied the patch and tested, just looked
> at it. It would be great to final
On Mon, Apr 15, 2013 at 4:40 PM, Zbigniew Jędrzejewski-Szmek
wrote:
> Do you want to apply it, or should I?
I haven't run it, either, but I trust Steven's own evaluation enough
for this change. A test suite is a good goal for longer-term.
--
David Strauss
| [email protected]
| +1 512
On Mon, Apr 15, 2013 at 01:52:48PM -0700, David Strauss wrote:
> In other words, let's commit this today. :-)
I concur. I haven't actually applied the patch and tested, just looked
at it. It would be great to finally have some test suite. Do you want
to apply it, or should I?
Zbyszek
_
In other words, let's commit this today. :-)
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Oh, okay. Sounds good.
On Apr 15, 2013 12:28 AM, "Steven Hiscocks"
wrote:
> On 15/04/13 04:05, David Strauss wrote:
>
>> Maybe I'm missing something in the Gist patch, but won't
>> Reader.get('__REALTIME_**TIMESTAMP') fail with "field name is not
>> valid"?
>>
>> You're right, but `get` is chang
On 15/04/13 04:05, David Strauss wrote:
Maybe I'm missing something in the Gist patch, but won't
Reader.get('__REALTIME_TIMESTAMP') fail with "field name is not
valid"?
You're right, but `get` is changed to `_get`, so is "private". Use
`get_next` and `get_previous` does on the traversal and get
Maybe I'm missing something in the Gist patch, but won't
Reader.get('__REALTIME_TIMESTAMP') fail with "field name is not
valid"?
On Sun, Apr 14, 2013 at 10:49 AM, Zbigniew Jędrzejewski-Szmek
wrote:
> On Sun, Apr 14, 2013 at 03:28:31PM +0100, Steven Hiscocks wrote:
>> On 14/04/13 03:36, David Stra
On Sun, Apr 14, 2013 at 03:28:31PM +0100, Steven Hiscocks wrote:
> On 14/04/13 03:36, David Strauss wrote:
> >I keep writing lengthy emails about how we can use this as an
> >opportunity to reduce redundancy and improve consistency, but I should
> >probably ping you on #systemd IRC to hash it out.
On 14/04/13 03:36, David Strauss wrote:
I keep writing lengthy emails about how we can use this as an
opportunity to reduce redundancy and improve consistency, but I should
probably ping you on #systemd IRC to hash it out. I can't think of
anything elegant that doesn't involve altering the existi
I keep writing lengthy emails about how we can use this as an
opportunity to reduce redundancy and improve consistency, but I should
probably ping you on #systemd IRC to hash it out. I can't think of
anything elegant that doesn't involve altering the existing journal.py
or _reader.c code.
What's y
On 13/04/13 23:47, Steven Hiscocks wrote:
On 13/04/13 23:00, David Strauss wrote:
If seems like we should put the conditional special handling for
__REALTIME_TIMESTAMP and __MONOTONIC_TIMESTAMP in either _reader.c or
right in get().
Here's why:
* With the code above, calling Reader.get('__REA
On 13/04/13 23:00, David Strauss wrote:
If seems like we should put the conditional special handling for
__REALTIME_TIMESTAMP and __MONOTONIC_TIMESTAMP in either _reader.c or
right in get().
Here's why:
* With the code above, calling Reader.get('__REALTIME_TIMESTAMP')
results in the wrong type
If seems like we should put the conditional special handling for
__REALTIME_TIMESTAMP and __MONOTONIC_TIMESTAMP in either _reader.c or
right in get().
Here's why:
* With the code above, calling Reader.get('__REALTIME_TIMESTAMP')
results in the wrong type (if anything, I'd need to check), but
Read
Hi,
In the python journal Reader, the splitting out of monotonic and
realtime stamps, has affected `get_next` function as timestamp values
are no longer present in the dictionary returned. Also the new
`get_monotonic` and `get_realtime` functions are not run through the
converters. Equally,
16 matches
Mail list logo