On Fri, Mar 21, 2014 at 2:42 PM, Zubin Mithra wrote:
> On Thu, Mar 20, 2014 at 3:38 AM, Dmitry V. Levin wrote:
>> Hi,
>>
>> On Tue, Mar 18, 2014 at 09:20:25PM +0530, Zubin Mithra wrote:
>>> Hey everyone,
>>>
>>> Based on the valuable discussion above, I've written out a first draft
>>> of the pro
On Thu, Mar 20, 2014 at 3:38 AM, Dmitry V. Levin wrote:
> Hi,
>
> On Tue, Mar 18, 2014 at 09:20:25PM +0530, Zubin Mithra wrote:
>> Hey everyone,
>>
>> Based on the valuable discussion above, I've written out a first draft
>> of the proposal for the ideas related to path decoding and structured
>>
Hi,
On Tue, Mar 18, 2014 at 09:20:25PM +0530, Zubin Mithra wrote:
> Hey everyone,
>
> Based on the valuable discussion above, I've written out a first draft
> of the proposal for the ideas related to path decoding and structured
> output.
>
> Please find the initial draft here[1] -- any opinions
On Wed, Mar 19, 2014 at 7:17 PM, Zubin Mithra wrote:
> Hey guys,
> On Tue, Mar 18, 2014 at 9:20 PM, Zubin Mithra wrote:
>> Based on the valuable discussion above, I've written out a first draft
>> of the proposal for the ideas related to path decoding and structured
>> output.
>>
>> Please find t
Hey guys,
On Tue, Mar 18, 2014 at 9:20 PM, Zubin Mithra wrote:
> (resending with the correct sender email address, sorry for any confusion!)
>
> Hey everyone,
>
> Based on the valuable discussion above, I've written out a first draft
> of the proposal for the ideas related to path decoding and s
(resending with the correct sender email address, sorry for any confusion!)
Hey everyone,
Based on the valuable discussion above, I've written out a first draft
of the proposal for the ideas related to path decoding and structured
output.
Please find the initial draft here[1] -- any opinions and
Hey everyone,
Based on the valuable discussion above, I've written out a first draft of
the proposal for the ideas related to path decoding and structured output.
Please find the initial draft here[1] -- any opinions and feedback would be
invaluable.
Thanks,
Zubin
[1]
https://docs.google.com/do
On Thu 13 Mar 2014 09:15:16 enh wrote:
please do not top post
> i'm not sure using numbers rather than strings is a good idea, given
> that Javascript's stupid "everything's a double" belief leaked into
> JSON (and from there into JSON parsers). that's fine for int32_t but
> not int64_t.
yeah, i
i'm not sure using numbers rather than strings is a good idea, given
that Javascript's stupid "everything's a double" belief leaked into
JSON (and from there into JSON parsers). that's fine for int32_t but
not int64_t.
On Thu, Mar 13, 2014 at 2:02 AM, Mike Frysinger wrote:
> On Tue 11 Mar 2014 15
On Tue 11 Mar 2014 15:10:12 Philippe Ombredanne wrote:
> On Tue, Mar 11, 2014 at 12:44 PM, Mike Frysinger wrote:
> > the format will need some way of marking suspended/resumed calls
>
> This would apply only when you follow processes with -f right? -ff has
> no unfinished/resumed business.
> So we
On Tue, Mar 11, 2014 at 12:44 PM, Mike Frysinger wrote:
> the format will need some way of marking suspended/resumed calls
This would apply only when you follow processes with -f right? -ff has
no unfinished/resumed business.
So we could limit support for a structured output to a -ff output onl
On Tue 11 Mar 2014 12:31:39 Philippe Ombredanne wrote:
> On Tue, Mar 11, 2014 at 6:36 AM, Mike Frysinger wrote:
> > On Mon 03 Mar 2014 10:26:22 Philippe Ombredanne wrote:
> >> or possibly (not sure which form I like best) using a more compact
> >> entirely and positional list of lists:
> >> [
> >>
On Tue, Mar 11, 2014 at 6:36 AM, Mike Frysinger wrote:
> On Mon 03 Mar 2014 10:26:22 Philippe Ombredanne wrote:
>> or possibly (not sure which form I like best) using a more compact
>> entirely and positional list of lists:
>> [
>> "open",
>> "-1",
>>[
>> "/usr/lib/locale/UTF-8
On Mon 03 Mar 2014 10:26:22 Philippe Ombredanne wrote:
> or possibly (not sure which form I like best) using a more compact
> entirely and positional list of lists:
> [
> "open",
> "-1",
>[
> "/usr/lib/locale/UTF-8/LC_CTYPE",
> "O_RDONLY|O_CLOEXEC"
> ]
> ]
that's a
On Fri, Mar 7, 2014 at 2:15 PM, Philippe Ombredanne
wrote:
> On Fri, Mar 7, 2014 at 3:38 AM, eQuiNoX wrote:
>>> On Tue, Mar 4, 2014 at 1:59 PM, Zubin Mithra wrote:
> [...]
>> Perfect, sounds good to me! I'll modify my GSoC proposal to reflect
>> these changes, thank you!
>> Thanks!
>> zm
>
> Jus
On Fri, Mar 7, 2014 at 3:38 AM, eQuiNoX wrote:
>> On Tue, Mar 4, 2014 at 1:59 PM, Zubin Mithra wrote:
[...]
> Perfect, sounds good to me! I'll modify my GSoC proposal to reflect
> these changes, thank you!
> Thanks!
> zm
Just to make sure I understand: are Zubin and eQuiNoX the same human ;) ?
I
On Thu, Mar 6, 2014 at 8:01 PM, Philippe Ombredanne
wrote:
> On Tue, Mar 4, 2014 at 1:59 PM, Zubin Mithra wrote:
>> Hey Philippe,
>>
>>> Just curious, why would you use call_one? and arg1,arg2 v.s using lists?
>>
>> I was just wondering if information related to the call sequence might
>> be use
On Tue, Mar 4, 2014 at 1:59 PM, Zubin Mithra wrote:
> Hey Philippe,
>
>> Just curious, why would you use call_one? and arg1,arg2 v.s using lists?
>
> I was just wondering if information related to the call sequence might
> be useful. In quite a few languages, JSON data directly maps to
> dictiona
On Mon, Mar 3, 2014 at 6:26 PM, Dmitry V. Levin wrote:
> On Mon, Mar 03, 2014 at 10:52:48AM +0530, Zubin Mithra wrote:
>> >> I believe that the first step would be to document and note down the
>> >> system
>> >> calls that belong to one or more of the above categories and their system
>> >> call
Hey Philippe,
> Just curious, why would you use call_one? and arg1,arg2 v.s using lists?
I was just wondering if information related to the call sequence might
be useful. In quite a few languages, JSON data directly maps to
dictionary representations(eg:- Python) -- but upon doing that we'd
lose
On Mon, Mar 03, 2014 at 10:52:48AM +0530, Zubin Mithra wrote:
> >> I believe that the first step would be to document and note down the system
> >> calls that belong to one or more of the above categories and their system
> >> call numbers, and if the -yy flag is used, check the tcp->scno against
>
On Mon, Mar 3, 2014 at 6:18 AM, Zubin Mithra wrote:
> On Sun, Mar 2, 2014 at 4:30 PM, Philippe Ombredanne
> wrote:
>> On Tue, Feb 25, 2014 at 5:57 PM, Zubin Mithra wrote:
>>> Hey all,
>>> I'm Zubin and I love low level systems programming! :)
>> [...]
>>> I had a look at the ideas list here[1] a
On Sun, Mar 2, 2014 at 4:30 PM, Philippe Ombredanne
wrote:
> On Tue, Feb 25, 2014 at 5:57 PM, Zubin Mithra wrote:
>> Hey all,
>> I'm Zubin and I love low level systems programming! :)
> [...]
>> I had a look at the ideas list here[1] and found the idea on improved path
>> decoding quite interesti
>> I believe that the first step would be to document and note down the system
>> calls that belong to one or more of the above categories and their system
>> call numbers, and if the -yy flag is used, check the tcp->scno against
>> these numbers and act accordingly.
>>
>> Is there something I'm mi
Hey Philippe and Dmitry,
On Sun, Mar 2, 2014 at 4:30 PM, Philippe Ombredanne
wrote:
> On Tue, Feb 25, 2014 at 5:57 PM, Zubin Mithra wrote:
>> Hey all,
>> I'm Zubin and I love low level systems programming! :)
> [...]
>> I had a look at the ideas list here[1] and found the idea on improved path
>
On Sun, Mar 02, 2014 at 01:18:57PM +0100, Philippe Ombredanne wrote:
> On Sun, Mar 2, 2014 at 12:44 PM, Dmitry V. Levin wrote:
[...]
> > The exact output format may vary, but the general idea of strace decoding
> > is to mimic C syntax. From this PoV, path names should always be enclosed
> > in d
On Sun, Mar 2, 2014 at 12:44 PM, Dmitry V. Levin wrote:
> On Sun, Mar 02, 2014 at 11:54:57AM +0100, Philippe Ombredanne wrote:
>> On Wed, Feb 26, 2014 at 2:28 AM, Dmitry V. Levin wrote:
>>
>> > Fourth, I think -yy should also "canonicalize" socket descriptors, i.e.
>> > print their addresses in <
On Sun, Mar 02, 2014 at 11:54:57AM +0100, Philippe Ombredanne wrote:
> On Wed, Feb 26, 2014 at 2:28 AM, Dmitry V. Levin wrote:
>
> > Fourth, I think -yy should also "canonicalize" socket descriptors, i.e.
> > print their addresses in <> form, resembling lsof(8) output. This would
> > be a really
On Wed, Feb 26, 2014 at 6:35 PM, eQuiNoX wrote:
>> On Tue, Feb 25, 2014 at 10:27:37PM +0530, Zubin Mithra wrote:
>> > Hey all,
>> > I'm Zubin and I love low level systems programming! :)
> Also, is there an IRC channel for strace dev?
Not for now, but it could make sense to have one at least for
On Tue, Feb 25, 2014 at 5:57 PM, Zubin Mithra wrote:
> Hey all,
> I'm Zubin and I love low level systems programming! :)
[...]
> I had a look at the ideas list here[1] and found the idea on improved path
> decoding quite interesting and was hoping we could discuss it further on the
> mailing list.
On Wed, Feb 26, 2014 at 2:28 AM, Dmitry V. Levin wrote:
> Fourth, I think -yy should also "canonicalize" socket descriptors, i.e.
> print their addresses in <> form, resembling lsof(8) output. This would
> be a really nice feature.
Indeed that would be awesome and help a lot with tracing networ
Thank you for your reply, Dmitry!
On Wed, Feb 26, 2014 at 6:58 AM, Dmitry V. Levin wrote:
> Hi,
>
> On Tue, Feb 25, 2014 at 10:27:37PM +0530, Zubin Mithra wrote:
> > Hey all,
> >
> > I'm Zubin and I love low level systems programming! :)
>
> Great! :)
>
> > A little about myself, I program prim
Hi,
On Tue, Feb 25, 2014 at 10:27:37PM +0530, Zubin Mithra wrote:
> Hey all,
>
> I'm Zubin and I love low level systems programming! :)
Great! :)
> A little about myself, I program primarily in C and Python, have systems
> programming experience with Minix(filesystem development) and Linux and
33 matches
Mail list logo
