Skip Menu |

This queue is for tickets about the Log-StdLog CPAN distribution.

Report information
The Basics
Id: 15842
Status: new
Priority: 0/
Queue: Log-StdLog

People
Owner: Nobody in particular
Requestors: tmahoney [...] verisign.com
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: (no value)
Fixed in: (no value)



Subject: cannot pass in filename
ok, I tried all afternoon, all day to pass in the filename. This does not work. I am running "This is perl, v5.8.0 built for i386-linux-thread-multi ". I have installed this "good idea" into my own space (PERL5LIB), not into system (linux EL 4.0). When I look at some of the tester notes, I see that they have not had success with this. When I look at the *.t files, I cannot find an example where you pass in a filename "as your documentation suggests". good idea, poorly done. My friend, waste of time. I spent all afternoon, all day, trying to debug the package. silly me. try for the next. :flame off.
Date: Wed, 16 Nov 2005 09:16:02 +1100
To: bug-Log-StdLog [...] rt.cpan.org
Subject: Re: [cpan #15842] cannot pass in filename
From: Damian Conway <thoughtstream [...] gmail.com>
RT-Send-Cc:
Show quoted text
> ok, I tried all afternoon, all day to pass in the filename. This does not work.
Yes, it does work. It may not work on your version of perl, on your system. But the module does work. Show quoted text
> I am running "This is perl, v5.8.0 built for i386-linux-thread-multi > ". I have installed this "good idea" into my own space (PERL5LIB), not into system (linux EL 4.0). > When I look at some of the tester notes, I see that they have not had
success with this. Yes. Modules that interact with the tester's filesystem are often prone to failing automated tests. Show quoted text
> When I look at the *.t files, I cannot find an example where you pass in a filename > "as your documentation suggests".
t/01read.t Damian
[damian@conway.org - Tue Nov 15 17:16:28 2005]: Show quoted text
> > ok, I tried all afternoon, all day to pass in the filename. This
> does not work. > > Yes, it does work. It may not work on your version of perl, on your > system. > But the module does work. > >
> > I am running "This is perl, v5.8.0 built for i386-linux-thread-multi > > ". I have installed this "good idea" into my own space (PERL5LIB),
> not into system (linux EL 4.0).
> > When I look at some of the tester notes, I see that they have not
> had > success with this. > > Yes. Modules that interact with the tester's filesystem are often > prone to > failing automated tests. > >
> > When I look at the *.t files, I cannot find an example where you
> pass in a filename
> > "as your documentation suggests".
> > t/01read.t > > > Damian > >
Damian suggests that it does work; I beg to differ. he suggests that the example is in t/01read.t; This file is not listed in the manifest. The file also was not in the installation package. :-) "please advise" :-) The messages in the "discussion forum" by "sanug" also point to difficulty with passing in the "filename"; He also asks if there is another level of documentation. This module was written up in the "Perl Best Practices" book. pity. Is this an example of best practices?
[guest - Tue Nov 15 18:22:03 2005]: Here are the examples: use Log::StdLog; # writes logs to $0.log file. As per spec. use Log::StdLog { file => "$logfile"}; (from lazy print: logfile: /tmp/getarchlogs1.pl.tmplog.27976) result: Unable to open log file '' at ./getarchlogs1.pl line 187 use Log::StdLog { file => $logfile, level => $log_level}; result: Use of uninitialized value in hash element at /home/tmahoney/perl/lib/Log/StdLog.pm line 57. ... Use of uninitialized value in open at /home/tmahoney/perl/lib/Log/StdLog.pm line 90. Use of uninitialized value in concatenation (.) or string at /home/tmahoney/perl/lib/Log/StdLog.pm line 90. Unable to open log file '' at ./getarchlogs2.pl line 187 use Log::StdLog { file => "$logfile", level => "$log_level"}; result: Unable to open log file '' at ./getarchlogs3.pl line 187 use Log::StdLog { file => \$logfile, level => $log_level}; result: Use of uninitialized value in hash element at /home/tmahoney/perl/lib/Log/StdLog.pm line 57. "apparently" normal return code. No file is written anywhere. (bit bucket?) regards, guest (by the way, line 187 is: print {*STDLOG} $log_level => "@message"; as per spec. Show quoted text
> [damian@conway.org - Tue Nov 15 17:16:28 2005]: >
> > > ok, I tried all afternoon, all day to pass in the filename. This
> > does not work. > > > > Yes, it does work. It may not work on your version of perl, on your > > system. > > But the module does work. > > > >
> > > I am running "This is perl, v5.8.0 built for i386-linux-thread-
> multi
> > > ". I have installed this "good idea" into my own space
> (PERL5LIB),
> > not into system (linux EL 4.0).
> > > When I look at some of the tester notes, I see that they have not
> > had > > success with this. > > > > Yes. Modules that interact with the tester's filesystem are often > > prone to > > failing automated tests. > > > >
> > > When I look at the *.t files, I cannot find an example where you
> > pass in a filename
> > > "as your documentation suggests".
> > > > t/01read.t > > > > > > Damian > > > >
> > > Damian suggests that it does work; I beg to differ. > he suggests that the example is in t/01read.t; This file is not > listed > in the manifest. The file also was not in the installation package. > :-) "please advise" :-) > The messages in the "discussion forum" by "sanug" also point to > difficulty with passing in the "filename"; He also asks if there is > another level of documentation. > > This module was written up in the "Perl Best Practices" book. pity. > Is this an example of best practices?
From: MichaelRWolf [...] att.net
[guest - Tue Nov 15 17:00:56 2005]: I think the problem is that the filename cannot be specified at *run* time. I'm running into this problem at a client site as I try to get them to adopt some of the PBP recommendations. They want the log to be relative to a data directory that's passed in at *run* time, but that's too late for the advertised *load* time configuration. Could you provide a Log::StdLog::config() method that takes the file, level, and formatter options at run time? I'll work on providing a test file that fails so that you can add it to the test suite.
From: MichaelRWolf [...] att.net
[guest - Tue Nov 15 17:00:56 2005]: I think the problem is that the filename cannot be specified at *run* time. I'm running into this problem at a client site as I try to get them to adopt some of the PBP recommendations. They want the log to be relative to a data directory that's passed in at *run* time, but that's too late for the advertised *load* time configuration. Could you provide a Log::StdLog::config() method that takes the file, level, and formatter options at run time? I'll work on providing a test file that fails so that you can add it to the test suite.
From: MichaelRWolf [...] att.net
[guest - Tue Nov 15 17:00:56 2005]: The attached file will illustrate the problem. I wasn't clever enough (Don't be clever - pg 453) to figure out how to cascade a compile-time error to Test::More, and I wasn't able to figure out how to use the tied hashes in IO::FILE (Don't tie variables or filehandles - pg 451) enough to suggest a work-around. (P.S. Thanks for counterindicating tieing. I never dug into it enough to understand, or use, it. I now have a good reason not to.) In the mean time, this file can illustrate how compile-time configuration does work, but run-time configuration does *not* work. Let me know if there's more assistance I can provide. Thanks, Michael Wolf
#! /usr/bin/perl use warnings; use strict; use Test::More tests => 8; use File::stat; use File::Temp qw(tempfile); my($fh, $filename) = tempfile(); ok($filename, "File name is populated as '$filename'..."); ok(-f $filename, "...and it's a file"); ok(-w $filename, "...and it's writable."); ok($fh, "File handle is populated..."); ok(-f $fh, "...and it's a file"); ok(-w $fh, "...and it's writable."); my $statref; $statref = stat($filename); cmp_ok($statref->size, '==', 0, "File is initally empty checking file name."); $statref = stat($fh); cmp_ok($statref->size, '==', 0, "File is initally empty checking file handle."); # Uncomment one, and only one, of the following. # #use Log::StdLog; # OK use Log::StdLog { file => "$0.log" }; # OK #use Log::StdLog { file => $filename }; # NOT OK my $print_rc = print {*STDLOG} warn => "warn"; ok($print_rc, "Meessage was logged as warn level."); flush STDLOG; $statref = stat($filename); cmp_ok($statref->size, '!=', 0, "File is initally empty checking file name."); $statref = stat($fh); cmp_ok($statref->size, '!=', 0, "File is initally empty checking file handle."); close $fh; unlink $filename;
[guest - Wed Nov 30 14:07:29 2005]: The following is a"workaround" that I use to specify the filename path at runtime. use Log::StdLog; # at compile time $file = "$config{dir}". basename($0) .".log.$$"; # at run time $level = 'warn'; # specify file at runtime (below). Log::StdLog->import ({ level => $level, file => $file } ); # works, runtime explanation: cf. Camel book, 2nd ed, p 287 cf. perldoc perlmod search with '/^ *Because' (not using the quotes, takes you to the lines copied below: Because the "use" statement implies a "BEGIN" block, the importing of semantics happens as soon as the "use" statement is compiled, before the rest of the file is compiled.... The Camel book expands this: Because the use declaration (in any form) implies a BEGIN block, the module is loaded (and any executable initialization code in it run) as soon as the use declaration is compiled, >before< the rest of the file is compiled.... My apologies to all for my previous flames.