Formatting tracing?

Is there any easy way of reformatting trace information?

I'd like a trace exactly like what DBI->trace(2) creates, except that
I'd like the timestamp (as precise as possible) and pid (ie $$) to be
included in the trace.

So far the best solution that I can think of is to create a named pipe
per process that adds the pid and timestamp then saves it elsewhere.=20
But that's kind of ugly. OK, not just kind of. *Very* ugly. Lots of
things can go wrong with named pipes, which could cause me to hang. I
wouldn't want that.

The second best solution is to do a per process trace and then
regularly execute a useless query with a timestamp as a bind
parameter. That avoids the risks of named pipes and gets timestamps
into the trace, but doesn't timestamp everything (and means tracking
down every application to be able to add their timestamps). The
output is worse, but the approach feels safer.

I thought of giving it a filename that is a pipe command, but it just
creates an oddly named file.

I thought of using DBI::PurePerl and hacking with that (eg setting
$DBI::tfh), but using DBI::PurePerl caused an immediate segfault in
the application that I didn't try to track down.

Any other ideas?

Cheers,
Ben

Re: Formatting tracing?

I think $h->trace($level, $filehandle) works now so I think you can
used a tied filehandle - certainly that's my intention.

Then the PRINT method of your tied filehandle class can do whatever you
want.

Tim.

On Fri, Feb 10, 2006 at 08:55:30PM -0800, Ben Tilly wrote:
> Is there any easy way of reformatting trace information?
>
> I'd like a trace exactly like what DBI->trace(2) creates, except that
> I'd like the timestamp (as precise as possible) and pid (ie $$) to be
> included in the trace.
>
> So far the best solution that I can think of is to create a named pipe
> per process that adds the pid and timestamp then saves it elsewhere.
> But that's kind of ugly. OK, not just kind of. *Very* ugly. Lots of
> things can go wrong with named pipes, which could cause me to hang. I
> wouldn't want that.
>
> The second best solution is to do a per process trace and then
> regularly execute a useless query with a timestamp as a bind
> parameter. That avoids the risks of named pipes and gets timestamps
> into the trace, but doesn't timestamp everything (and means tracking
> down every application to be able to add their timestamps). The
> output is worse, but the approach feels safer.
>
> I thought of giving it a filename that is a pipe command, but it just
> creates an oddly named file.
>
> I thought of using DBI::PurePerl and hacking with that (eg setting
> $DBI::tfh), but using DBI::PurePerl caused an immediate segfault in
> the application that I didn't try to track down.
>
> Any other ideas?
>
> Cheers,
> Ben

Re: Formatting tracing?

That would be perfect. I will attempt that on Monday.

If it works but I can't use a tied filehandle, that's still OK. I'll
just open a pipe.

Thanks,
Ben

On 2/11/06, Tim Bunce wrote:
> I think $h->trace($level, $filehandle) works now so I think you can
> used a tied filehandle - certainly that's my intention.
>
> Then the PRINT method of your tied filehandle class can do whatever you
> want.
>
> Tim.
>
> On Fri, Feb 10, 2006 at 08:55:30PM -0800, Ben Tilly wrote:
> > Is there any easy way of reformatting trace information?
> >
> > I'd like a trace exactly like what DBI->trace(2) creates, except that
> > I'd like the timestamp (as precise as possible) and pid (ie $$) to be
> > included in the trace.
> >
> > So far the best solution that I can think of is to create a named pipe
> > per process that adds the pid and timestamp then saves it elsewhere.
> > But that's kind of ugly. OK, not just kind of. *Very* ugly. Lots of
> > things can go wrong with named pipes, which could cause me to hang. I
> > wouldn't want that.
> >
> > The second best solution is to do a per process trace and then
> > regularly execute a useless query with a timestamp as a bind
> > parameter. That avoids the risks of named pipes and gets timestamps
> > into the trace, but doesn't timestamp everything (and means tracking
> > down every application to be able to add their timestamps). The
> > output is worse, but the approach feels safer.
> >
> > I thought of giving it a filename that is a pipe command, but it just
> > creates an oddly named file.
> >
> > I thought of using DBI::PurePerl and hacking with that (eg setting
> > $DBI::tfh), but using DBI::PurePerl caused an immediate segfault in
> > the application that I didn't try to track down.
> >
> > Any other ideas?
> >
> > Cheers,
> > Ben
>

Re: Formatting tracing?

What $VERSION was this implemented at?

I just tried it on a machine at $VERSION 1.48 and it didn't work. :-(

(This with a filehandle pointing at a pipe, I was going to try a tied
filehandle if that worked.)

Thanks,
Ben

On 2/11/06, Tim Bunce wrote:
> I think $h->trace($level, $filehandle) works now so I think you can
> used a tied filehandle - certainly that's my intention.
>
> Then the PRINT method of your tied filehandle class can do whatever you
> want.
>
> Tim.
>
> On Fri, Feb 10, 2006 at 08:55:30PM -0800, Ben Tilly wrote:
> > Is there any easy way of reformatting trace information?
> >
> > I'd like a trace exactly like what DBI->trace(2) creates, except that
> > I'd like the timestamp (as precise as possible) and pid (ie $$) to be
> > included in the trace.
> >
> > So far the best solution that I can think of is to create a named pipe
> > per process that adds the pid and timestamp then saves it elsewhere.
> > But that's kind of ugly. OK, not just kind of. *Very* ugly. Lots of
> > things can go wrong with named pipes, which could cause me to hang. I
> > wouldn't want that.
> >
> > The second best solution is to do a per process trace and then
> > regularly execute a useless query with a timestamp as a bind
> > parameter. That avoids the risks of named pipes and gets timestamps
> > into the trace, but doesn't timestamp everything (and means tracking
> > down every application to be able to add their timestamps). The
> > output is worse, but the approach feels safer.
> >
> > I thought of giving it a filename that is a pipe command, but it just
> > creates an oddly named file.
> >
> > I thought of using DBI::PurePerl and hacking with that (eg setting
> > $DBI::tfh), but using DBI::PurePerl caused an immediate segfault in
> > the application that I didn't try to track down.
> >
> > Any other ideas?
> >
> > Cheers,
> > Ben
>

Re: Formatting tracing?

On Mon, Feb 13, 2006 at 02:03:22PM -0800, Ben Tilly wrote:
> What $VERSION was this implemented at?

I didn't say it was for sure. Just that I intended it and thought it was.
Now I look at the code I see it's not:
/* XXX need to support file being a filehandle object */

I'll get to it at some point but, as always, patches welcome!

Tim.

> I just tried it on a machine at $VERSION 1.48 and it didn't work. :-(
>
> (This with a filehandle pointing at a pipe, I was going to try a tied
> filehandle if that worked.)
>
> Thanks,
> Ben
>
> On 2/11/06, Tim Bunce wrote:
> > I think $h->trace($level, $filehandle) works now so I think you can
> > used a tied filehandle - certainly that's my intention.
> >
> > Then the PRINT method of your tied filehandle class can do whatever you
> > want.
> >
> > Tim.
> >
> > On Fri, Feb 10, 2006 at 08:55:30PM -0800, Ben Tilly wrote:
> > > Is there any easy way of reformatting trace information?
> > >
> > > I'd like a trace exactly like what DBI->trace(2) creates, except that
> > > I'd like the timestamp (as precise as possible) and pid (ie $$) to be
> > > included in the trace.
> > >
> > > So far the best solution that I can think of is to create a named pipe
> > > per process that adds the pid and timestamp then saves it elsewhere.
> > > But that's kind of ugly. OK, not just kind of. *Very* ugly. Lots of
> > > things can go wrong with named pipes, which could cause me to hang. I
> > > wouldn't want that.
> > >
> > > The second best solution is to do a per process trace and then
> > > regularly execute a useless query with a timestamp as a bind
> > > parameter. That avoids the risks of named pipes and gets timestamps
> > > into the trace, but doesn't timestamp everything (and means tracking
> > > down every application to be able to add their timestamps). The
> > > output is worse, but the approach feels safer.
> > >
> > > I thought of giving it a filename that is a pipe command, but it just
> > > creates an oddly named file.
> > >
> > > I thought of using DBI::PurePerl and hacking with that (eg setting
> > > $DBI::tfh), but using DBI::PurePerl caused an immediate segfault in
> > > the application that I didn't try to track down.
> > >
> > > Any other ideas?
> > >
> > > Cheers,
> > > Ben
> >

Re: Formatting tracing?

On 2/13/06, Tim Bunce wrote:
> On Mon, Feb 13, 2006 at 02:03:22PM -0800, Ben Tilly wrote:
> > What $VERSION was this implemented at?
>
> I didn't say it was for sure. Just that I intended it and thought it was.
> Now I look at the code I see it's not:
> /* XXX need to support file being a filehandle object */
>
> I'll get to it at some point but, as always, patches welcome!

I haven't done any XS code, but looking at it, the 80/20 rule might be
to say that if PerlIO_fileno thinks that the passed in file has a
fileno, then use that fileno.

This would *not* support tied filehandles. But it would allow people
to pass in opened filehandles (and allows you to drop STDERR and
STDOUT). In my case I could open a pipe and pass in the pipe. Taking
that to 90% of the way, if it doesn't have a filehandle, pass it to
Perl's open function rather than a lower-level version of the same.=20
That way the first thing that I tried (passing in a filename of "|
perl -ne 'print scalar localtime(), qq(: )'") would have worked.

In any case for my project it will probably be sufficient to use the
named pipe workaround. (That avoids having to create a site-specific
version of DBI that has to be installed on all company machines.)

Cheers,
Ben