log4perl-devel — Ongoing log4perl development

Re: [log4perl-devel] Can't call method "PRINT" on an undefined value

[Kevin G. <ke...@go...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tony Bowden wrote:

| With some fiddling around it seems that the problem is that my
| Log4perl::init() in the test gets clobbered by the one in the code that
| I'm testing and so doesn't actually log to the TestBuffer at all.

No doubt.  When you initialize Log4perl it's initialized for the entire
perl interpreter.  With that in mind you don't need to call init()
inside your new() method, just put it in the body of the module so that
it loads once.  Then make sure the test's init() method gets called
after the module's init method, like it does in your code sample.  See
the patch below.

Mike, please correct me if my understanding of easy_init() is wrong.


- --- test.old.pl Fri Jan  9 08:23:35 2004
+++ test.pl     Fri Jan  9 08:18:24 2004
@@ -2,9 +2,10 @@

~ use Log::Log4perl ':easy';

+Log::Log4perl->easy_init($INFO);

~ sub new {
- -Log::Log4perl->easy_init($INFO);
+
~   bless {} => shift
~ }



- --
Happy Trails . . .

Kevin M. Goess
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQE//tZY4g4/Tl71vUkRAqfpAKDOZ001BOHxXTYrzJAgOV2LFaoO+gCfVpHH
DEe4yOSCk2NLEWcafv5lxPw=
=Ockr
-----END PGP SIGNATURE-----

Re: [log4perl-devel] Can't call method "PRINT" on an undefined value

[Tony B. <log...@tm...>]

On Tue, Jan 06, 2004 at 09:12:17AM -0800, Mike Schilli wrote:
> Absolutely, that's the way to go -- changing where logged message of a 
> system are going is just a matter of configuring l4p.
> Just use a Log::Log4perl::Appender::File appender or 
> Log::Log4perl::Appender::TestBuffer at initialization time. 

I think I'm missing something quite fundamental here because I can't get
this to work.

With some fiddling around it seems that the problem is that my
Log4perl::init() in the test gets clobbered by the one in the code that
I'm testing and so doesn't actually log to the TestBuffer at all.

Take the below example, which doesn't work. If I create a $foo before
calling the Log4perl::init, everything works fine. But in the app I'm
testing, there's no sensible place to hook in like this that I can find.

Suggestions?

Thanks,

Tony


------ BEGIN EXAMPLE -------

package My::Foo;

use Log::Log4perl ':easy';

sub new {
  Log::Log4perl->easy_init($INFO);
  bless {} => shift
}

sub do_it {
  my ($self, $info) = @_;
  get_logger()->info("do_it needs args") unless $info;
  return;
}

package main;

use Test::More tests => 1;

Log::Log4perl::init(\q{
  screen = Log::Log4perl::Appender::TestBuffer
  log4perl.category = INFO, BufferApp
  log4perl.appender.BufferApp = ${screen}
  log4perl.appender.BufferApp.layout = \
      Log::Log4perl::Layout::PatternLayout
  log4perl.appender.BufferApp.layout.ConversionPattern = %d %F{1} %L> %m %n
});


{
  my $log = Log::Log4perl::Appender::TestBuffer->by_name("BufferApp");
  My::Foo->new->do_it(1);
  is $log->buffer, "", "No log if args";
}

{
  my $log = Log::Log4perl::Appender::TestBuffer->by_name("BufferApp");
  My::Foo->new->do_it();
  like $log->buffer, qr/needs args/, "Logged if no args";
}

------ END EXAMPLE -------

Re: [log4perl-devel] Can't call method "PRINT" on an undefined value

[Mike S. <msc...@ao...>]

Tony Bowden wrote on 1/6/2004, 3:16 AM:

 > My guess would be that in my test I would tell log4perl to use a
 > different
 > method of logging that's easier to test. It's not quite the same, but
 > it's probably good enough.
 >
 > Is this a sensible approach, or is there a better way? If it's sensible,
 > where's the best place to hook in to do that?

Absolutely, that's the way to go -- changing where logged message of a 
system are going is just a matter of configuring l4p.

Just use a Log::Log4perl::Appender::File appender or 
Log::Log4perl::Appender::TestBuffer at initialization time. Something like:

  use Log::Log4perl qw(:easy);

  my $conf = q(
  log4perl.category         = DEBUG, Logfile
  log4perl.appender.Logfile = Log::Log4perl::Appender::File
  log4perl.appender.Logfile.filename = test.log
  log4perl.appender.Logfile.layout = \
         Log::Log4perl::Layout::PatternLayout
  log4perl.appender.Logfile.layout.ConversionPattern = %d %F{1} %L> %m %n
     );

     Log::Log4perl::init(\$conf);

  DEBUG "wibble";

-- 
-- Mike
Mike Schilli
m...@pe...

Re: [log4perl-devel] Can't call method "PRINT" on an undefined value

[Kevin G. <ke...@go...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tony Bowden wrote:
| On Tue, Jan 06, 2004 at 10:59:13AM +0000, Tony Bowden wrote:
| While I try to discover why that is, perhaps someone could tell
| me a better way to actually write this sort of test. Basically I
| need to test my application is issuing debugging messages correctly
| to STDERR.

For testing log4perl itself, we use the TestBuffer appender, grep the
tests under t/*.t for 'TestBuffer' for examples.  You can log to a
TestBuffer and then look at it to see what got logged.





- --
Happy Trails . . .

Kevin M. Goess
(and Anne and Frank)
904 Carmel Ave.
Albany, CA  94706
(510) 525-5217
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQE/+uQk4g4/Tl71vUkRAtxAAKCpAJrL0mq3f4VzgbcD5jPhYpaqrACgv10k
xz0nQ9zgJe9EwUtA7e7YNME=
=Hubm
-----END PGP SIGNATURE-----

Re: [log4perl-devel] log4perl enhancement request ?

[Kevin G. <ke...@go...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Pete Siemsen wrote:
| Thanks for the replies (see below).

And thanks for the great summary, Pete! Holy cow, that's good.


- --
Happy Trails . . .

Kevin M. Goess
(and Anne and Frank)
904 Carmel Ave.
Albany, CA  94706
(510) 525-5217
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQE/+uMa4g4/Tl71vUkRAsH3AJwN7wQrRsgPwWn8IgySEy5ftIRPaQCcD3f0
vebjVjtqiVVPGS1pKZkTl2c=
=0xos
-----END PGP SIGNATURE-----

Re: [log4perl-devel] Can't call method "PRINT" on an undefined value

[Tony B. <log...@tm...>]

On Tue, Jan 06, 2004 at 10:59:13AM +0000, Tony Bowden wrote:
> I'm getting a strange test failure in our framework on one machine and
> not on another:
> Can't call method "PRINT" on an undefined value at 
>   /usr/share/perl5/Log/Log4perl/Appender/Screen.pm line 27.

Hmmm. I doubt this has anything to do with Log4perl. I can reduce it now
to:

  use IO::Scalar;
  local *STDERR = new IO::Scalar \my $data;
  print STDERR "Wibble wibble wibble\n";
  print "Data = $data\n";


This seems to work on 5.8.1 and fail on 5.8.2.

While I try to discover why that is, perhaps someone could tell
me a better way to actually write this sort of test. Basically I
need to test my application is issuing debugging messages correctly
to STDERR. Previously I was just grabbing STDERR to a scalar and then
testing that normally, but now that that's not working I should probably
find a better way!

My guess would be that in my test I would tell log4perl to use a different
method of logging that's easier to test. It's not quite the same, but
it's probably good enough.

Is this a sensible approach, or is there a better way? If it's sensible,
where's the best place to hook in to do that?

Thanks,

Tony

[log4perl-devel] Can't call method "PRINT" on an undefined value

[Tony B. <log...@tm...>]

I'm getting a strange test failure in our framework on one machine and
not on another:

Can't call method "PRINT" on an undefined value at 
  /usr/share/perl5/Log/Log4perl/Appender/Screen.pm line 27.

Both machines have the latest log4perl, and major difference is that
the machine that's fine is perl 5.8.1 and the one that's not is perl
5.8.2. However I have no idea whether that's relevant or not, or whether
something else is going on.

At this point I can't get a simple failing test case: the error messages
don't even point me sensibly to where the problem is, and putting some
debug messages make the error report itself as happening somewhere
completely differently.

Before I go mad digging into this, has anyone seen this, or have any
ideas what it could be?

Thanks,

Tony

Re: [log4perl-devel] log4perl enhancement request ?

[Pete S. <si...@uc...>]

Thanks for the replies (see below).  Basically, Mike Schilli and Kevin
Goess provided the same solution, based on using the "caller" function.
This solution works perfectly for me.  Jim Cromie answered in depth, and
expressed concern that the solution would be prohibitively expensive.  I
tested the expense and found it to be minor (see below).

Thanks again, guys!  I got just what I wanted.


  Pete> I'd like log4perl to indent messages to show caller depth in the
  Pete> call stack.  A sample of this style is
  Pete>
  Pete> main: starting
  Pete> function1: called with arg1, arg2
  Pete> function1: returning value1
  Pete> function2: called
  Pete> function3: called
  Pete> function4: called with arg4
  Pete> function4: returning
  Pete> function3: returning
  Pete> function2: returning
  Pete> main: ending
  Pete>
  Pete> For years, I've been doing this by passing around a scalar named
  Pete> $CallDepth, and incrementing/decrementing it at function
  Pete> entry/exit.  I pass around a second scalar named $DbgLevel that
  Pete> works sorta like the levels in log4perl, but with more levels.


  Mike> If you don't mind the expense of a bunch of caller() calls per
  Mike> logged message, here's a solution:
  Mike>
  Mike> use Log::Log4perl qw(get_logger);
  Mike>
  Mike> ####################
  Mike> sub level {
  Mike> ####################
  Mike>      my $i = 0;
  Mike>      $i++ while caller($i);
  Mike>      return $i-6;
  Mike> }
  Mike>
  Mike> my $conf = q(
  Mike> log4perl.PatternLayout.cspec.Y = sub { "  " x level() }
  Mike> log4perl.category                  = WARN, Logfile
  Mike> log4perl.appender.Logfile          = Log::Log4perl::Appender::Screen
  Mike> log4perl.appender.Logfile.layout   = PatternLayout
  Mike> log4perl.appender.Logfile.layout.ConversionPattern = %Y%m%n
  Mike> );
  Mike>
  Mike> Log::Log4perl::init(\$conf);
  Mike>
  Mike> my $logger = get_logger("");
  Mike> $logger->error("first");
  Mike> bar();
  Mike> $logger->error("first");
  Mike>
  Mike> sub bar { $logger->error("second"); foo(); }
  Mike> sub foo { $logger->error("third"); }
  Mike>
  Mike> __END__
  Mike>
  Mike> The $i-6 expression might need to be adapted if caller_level is
  Mike> set to anything but 0. Here's the output:
  Mike>
  Mike> first
  Mike>    second
  Mike>      third
  Mike> first
  Mike>
  Mike> -- Mike

Thanks!

  Kevin> | sub level {
  Kevin> |      my $i = 0;
  Kevin> |      $i++ while caller($i);
  Kevin> |      return $i-6;
  Kevin> | }
  Kevin> 
  Kevin> The $i-6 expression might need to be adapted if caller_level is
  Kevin> set to anything but 0.
  Kevin>
  Kevin> It seems like we should make that magic number 6 a log4perl
  Kevin> constant or something, doesn't it?  It's the number of levels
  Kevin> between an application and a cspec, is it?
  Kevin>
  Kevin> Kevin M. Goess

I agree that the "6" should be a constant.  I suggest that the above
subroutine be added to the documentation of Log4perl as an example of
how to use custom cspecs.

  Jim> I have several reactions:
  Jim>
  Jim> 1. Not gonna happen - using caller() on every invocation would be
  Jim>    the only way to get stack depth, and is horrifically expensive
  Jim>    for an application-wide logging facility.  I once proposed
  Jim>    that caller(1) be used to provide more info to filtering
  Jim>    operations, and that was deemed infeasible due to efficiency
  Jim>    concerns.  Your idea would require N times as many (log2(N) if
  Jim>    you're clever) uses of caller in order to get the depth of the
  Jim>    stack.

Within reason, I don't care if the application slows down when I turn on
logging.

I wrote a small test: 100000 calls to a function that logs a message and
calls a second function that logs a message.  I used a
"Log::Dispatch::File" appender and a PatternLayout of "%m%n".  It took
58 seconds on my 1.2Ghz Pentium under Linux with Perl 5.6.1.  To make
the same program use caller, I changed the PatternLayout to "%Z%m%n" and
added

Log::Log4perl::Layout::PatternLayout::add_global_cspec('Z',
						       sub {
							 my $lvl = 0;
							 $lvl++ while caller($lvl);
							 return '  ' x ($lvl-6);
						       }
						      );

The output file had the indentation, and it took only 62 seconds to run.
A surprisingly small hit!

  Jim> 2. I didn't really like that answer, but it was true.  So I went
  Jim>    digging into optimizer.pm, and eventually wrote
  Jim>    Log::Log4perl::Autocategorize.  In this package, AUTOLOAD
  Jim>    catches all logging calls, uses caller() to figure out who
  Jim>    called, consults L4perl to determine whether to log it, and
  Jim>    does so.
  Jim>
  Jim>      my $predicate = "is_$level";
  Jim>      eval { $runnable = $log->$predicate() };
  Jim>
  Jim>    Now, here's the tricky part - because I used optimizer to
  Jim>    munge the method-name into a new, unique name (ex: from debug
  Jim>    to debug_$somevalue), I could create a custom subroutine to do
  Jim>    the right thing FOR THAT CALL-POINT.  Thereafter - calls to
  Jim>    that subroutine (ie FROM THAT CALLER) were handled at
  Jim>    full-speed, and with full customized behavior.
  Jim>
  Jim>    It would not be hard to extend to accommodate your desires,
  Jim>    WITH SOME CAVEATS
  Jim>
  Jim>    a. Depth must be perfectly correlated to the invoker.
  Jim>
  Jim>       The simplest explanation is by way of a counter-example: a
  Jim>       debug_print() utility would likely be used from dozens of
  Jim>       places, and from different depths of the code.  These
  Jim>       differences would not be seen by my package, since the
  Jim>       logging call is coming from debug_print, not from its many
  Jim>       users. To amplify this point - indent-level could easily be
  Jim>       wrong, and undetectably so.

I don't think this is a scheme to pursue, especially since "caller"
seems efficient enough.  This adds even more complexity to an
already-complex system.

  Jim>    b. L4P has no way to express filtering based on call-stack.
  Jim>
  Jim>       I extended the meaning of 'logging category' to carry all
  Jim>       the info that caller() provides, thus you can filter on
  Jim>       class, subroutine, line number.
  Jim>
  Jim>     log4perl.category.Frob.nicate.debug = INFO        # 2
  Jim>     log4perl.category.Frob.nicate.debug.118 = DEBUG    # 3
  Jim>     #log4perl.category.Frob.Vernier.twiddle.debug = DEBUG    # 4
  Jim>
  Jim>       But this runs out of gas after 1st caller level.  There's
  Jim>       no obvious/clean way to extend this to operate on results
  Jim>       of caller(N).  I discuss some options in my POD, please
  Jim>       read there, but here's a strawman:
  Jim>
  Jim>     log4perl.caller(2).Frob.nicate.debug = INFO        # 2
  Jim>
  Jim>       There are problems with this - its hard (impossible?) to
  Jim>       know whether is_debug() says yes/no due to an exact match
  Jim>       or a bubble-up match, hence its hard to know whether a
  Jim>       level-N filter is even pertinent.  And it would be silly to
  Jim>       invoke caller(42) to check for filters speced at that level
  Jim>       - on average, there won't be.

I don't think this is a path to pursue.

  Jim>    c. your idea could/should extend to nested lexical scopes
  Jim>       within subroutines, but that's a whole nuther can of worms.

I disagree that it could/should be extended, and I agree that to do so
would be a whole nuther can of worms.  Lexical scopes are not a runtime
thing, so I think it would get confusing fast.

  Jim>    d. I'm unwilling to extend Autocat in ways that appear to be
  Jim>       incompatible with L4P.  And since L4P strives to be
  Jim>       compatible with L4J, Id expect some reluctance there to do
  Jim>       whats needed to the configs.  Hopefully L4J has reserved
  Jim>       some part of the config-space to accomodate special
  Jim>       needs/features (such as 'log4perl.caller(2)' above)

Actually, this brings up a problem for me.  I have big Java projects and
big Perl projects.  I hope to standardize on a logging framework that I
can use in both languages.  I have no idea (yet) whether L4J can be
coaxed to offer indented log messages.

  Jim> 3.  Have you looked at Hook::Scope ?   Its more deep magic that I
  Jim>     done't understand well, but it can hang/hook actions on scope
  Jim>     entry/exit that you could use in a wrapper class.

I got/unpacked it, and I confess it's deeper magic than I want to
use.  I am still struggling with the OO paradigm!

  Jim> 4. IIRC, Log::Agent can represent enter, exits via indentation

I used Log::Agent for a while before I learned about Log4perl.
Log::Agent worked fine, and I could do the indenting, but I still had to
manage a $CallDepth variable.  Log::Agent has the advantage that it has
simple numeric levels, which I miss in Log4perl - I haven't yet learned
how to translate a simple numeric command-line option into Log4perl
categories.  Log::Agent made me think about the difference between
tracing messages, debug messages and log messages, which was good.  I'm
now investing in Log4perl because I want to use the same logging
framework in Perl and Java.  And there's a book about log4j, which
applies to Log4perl.  And it's powerful.

Thanks again!

-- Pete

[log4perl-devel] Log::Log4perl PPD updated

[Mike S. <msc...@ao...>]

Hi Dave,

the *.ppd file and the tarfile on log4perl.sourceforge.net have been 
updated to not require File::Spec anymore -- hope that'll fix the 
problem with the ActiveState install you experienced earlier.

-- 
-- Mike
Mike Schilli
m...@pe...

[log4perl-devel] resend: Log::Dispatch-2.08 on win32

[Viner, D. <dv...@ya...>]

hi all,

I've been trying to reach dave rolsky with this question... it seems like
log::dispatch version 2.07 and 2.08 fail on windows ...
http://testers.cpan.org/show/Log-Dispatch.html#Log-Dispatch-2.08

anyone here have the inside scoop on log::dispatch? 

thanks
dave

>  -----Original Message-----
> From: 	Viner, David  
> Sent:	Tuesday, December 23, 2003 10:56 AM
> To:	'au...@ur...'
> Subject:	Log::Dispatch-2.08 on win32
> 
> Hi,
> 
> I've been trying to build and run the tests for Log::Dispatch-2.08 on
> win32, but it fails.   The problem is in test 128 in t/01-basic.t which
> tests the chmodded permissions of a log file.  The problem is that on
> windows 0777 is equivalent to 0666 ( i think ).  In other words, this
> script:
> 
> #!/usr/local/bin/perl -w
> use strict;
> umask(0000);
> my $f= "test-chmod.tmp";
> open(F,">$f") or die("Can't open $f");
> print F "HI";
> close(F);
> 
> my $mode = (stat($f))[2]
>         or die "Cannot stat $f: $!";
> my $mode_string = sprintf( '%04o', $mode & 07777 );
> print "MODE: $mode_string\n";
> 
> chmod(0777,$f);
> 
> my $mode2 = (stat($f))[2]
>         or die "Cannot stat $f: $!";
> my $mode_string2 = sprintf( '%04o', $mode2 & 07777 );
> print "MODE: $mode_string2\n";
> 
> 
> exit;
> 
> Will output the following:
> MODE: 0666
> MODE: 0666
> 
> I'm not a win32 expert, but this small change to the test file will make
> it work:
> # 129 - 131 - would_log
> {
>     my $dispatch = Log::Dispatch->new;
> 
>     $dispatch->add( Log::Dispatch::File->new( name => 'file1',
> 					      min_level => 'warning',
> 					      filename => './would_test.log'
> ) );
> 
>     ok( !$dispatch->would_log('foo'),
>         "will not log 'foo'" );
> 
>     ok( ! $dispatch->would_log('debug'),
>         "will not log 'debug'" );
> 
>     ok( $dispatch->would_log('crit'),
>         "will log 'crit'" );
> 
>     unlink './would_test.log'
> 	or diag( "Can't remove ./would_test.log: $!" );
> }
> 
> 
> What do you think?
> 
> dave

Re: [log4perl-devel] log4perl enhancement request ?

[Kevin G. <ke...@go...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

| sub level {
|      my $i = 0;
|      $i++ while caller($i);
|      return $i-6;
| }
|
| The $i-6 expression might need to be adapted if caller_level is set to
| anything but 0.

It seems like we should make that magic number 6 a log4perl constant or
something, doesn't it?  It's the number of levels between an application
and a cspec, is it?

- --
Happy Trails . . .

Kevin M. Goess
(and Anne and Frank)
904 Carmel Ave.
Albany, CA  94706
(510) 525-5217
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQE/8aS94g4/Tl71vUkRAvlCAKCr3X5Y9EVO8H5rvIuJyYIrG01FBwCgovCa
DPtotXUKyceNmgjnztf2L1Q=
=tPT9
-----END PGP SIGNATURE-----

Re: [log4perl-devel] log4perl enhancement request ?

[Mike S. <msc...@ao...>]

Pete Siemsen wrote on 12/29/2003, 4:37 PM:

 > It seems like "Custom Cspecs" in PatternLayouts is the way to do
 > this in log4perl.

If you don't mind the expense of a bunch of caller() calls per logged 
message, here's a solution:

use Log::Log4perl qw(get_logger);

####################
sub level {
####################
     my $i = 0;
     $i++ while caller($i);
     return $i-6;
}

my $conf = q(
log4perl.PatternLayout.cspec.Y = sub { "  " x level() }
log4perl.category                  = WARN, Logfile
log4perl.appender.Logfile          = Log::Log4perl::Appender::Screen
log4perl.appender.Logfile.layout   = PatternLayout
log4perl.appender.Logfile.layout.ConversionPattern = %Y%m%n
);

Log::Log4perl::init(\$conf);

my $logger = get_logger("");
$logger->error("first");
bar();
$logger->error("first");

sub bar { $logger->error("second"); foo(); }
sub foo { $logger->error("third"); }

__END__

The $i-6 expression might need to be adapted if caller_level is set to 
anything but 0. Here's the output:

first
   second
     third
first

-- 
-- Mike
Mike Schilli
m...@pe...

Re: [log4perl-devel] log4perl enhancement request ?

[Jim C. <jc...@di...>]

Pete Siemsen wrote:

>I'd like log4perl to indent messages to show caller depth in the call
>stack.  A sample of this style is
>
>  main: starting
>    function1: called with arg1, arg2
>    function1: returning value1
>    function2: called
>      function3: called
>        function4: called with arg4
>        function4: returning
>      function3: returning
>    function2: returning
>  main: ending
>
>For years, I've been doing this by passing around a scalar named
>$CallDepth, and incrementing/decrementing it at function entry/exit.  I
>pass around a second scalar named $DbgLevel that works sorta like the
>levels in log4perl, but with more levels.
>


I have several reactions:

1. Not gonna happen - using caller() on every invocation would bethe 
only way to get stack depth,
and is horrifically expensive for an application-wide logging facility.  
I once proposed that
caller(1) be used to provide more info to filtering operations, and that 
was deemed infeasable
due to efficiency concerns.  Your idea would require N times as many 
(log2(N) if youre clever)
uses of caller in order to get the depth of the stack.

2. I didnt really like that answer, but it was true.  So I went digging 
into optimizer.pm, and eventually
wrote Log::Log4perl::Autocategorize.  In this package, AUTOLOAD catches 
all logging calls,
uses caller() to figure out who called, consults L4perl to determine 
whether to log it, and does so.

     my $predicate = "is_$level";
     eval { $runnable = $log->$predicate() };

Now, heres the tricky part - because I used optimizer to munge the 
method-name into a new, unique
name (ex: from debug to debug_$somevalue), I could create a custom 
subroutine to do the right thing
FOR THAT CALL-POINT.  Thereafter - calls to that subroutine (ie FROM 
THAT CALLER)
were handled at full-speed, and with full customized behavior.

It would not be hard to extend to accommodate your desires, WITH SOME 
CAVEATS

a. Depth must be perfectly correlated to the invoker.

The simplest explanation is by way of a counter-example:  a 
debug_print() utility would likely be
used from dozens of places, and from different depths of the code.  
These differences would
not be seen by my package, since the logging call is coming from 
debug_print, not from its
many users. To amplify this point - indent-level could easily be wong, 
and undetectably so.

b. L4P has no way to express filtering based on call-stack.

I extended the meaning of 'logging category' to carry all the info that 
caller() provides,
thus you can filter on class, subroutine, line number.

    log4perl.category.Frob.nicate.debug = INFO        # 2
    log4perl.category.Frob.nicate.debug.118 = DEBUG    # 3
    #log4perl.category.Frob.Vernier.twiddle.debug = DEBUG    # 4

But this runs out of gas after 1st caller level.  Theres no 
obvious/clean way to extend this
to operate on results of caller(N).  I discuss some options in my POD, 
please read there,
but heres a strawman:

log4perl.caller(2).Frob.nicate.debug = INFO        # 2

There are problems with this - its hard (impossibl?) to know whether 
is_debug()
says yes/no due to an exact match or a bubble-up match, hence its hard 
to know
whether a level-N filter is even pertinent.  and it would be silly to 
invoke caller(42)
to check for filters speced at that level - on average, there wont be.

c. your idea could/should extend to nested lexical scopes within 
subroutines, but
thats a whole nuther can of worms.

d. Im unwilling to extend Autocat in ways that appear to be incompatible 
with L4P.
And since L4P strives to be compatible with L4J, Id expect some 
reluctance there to
do whats needed to the configs.   Hopefully L4J has reserved some part 
of the config-space
to accomodate special needs/features (such as 'log4perl.caller(2)' above)

3.  Have you looked at Hook::Scope ?   Its more deep magic that I dont 
understand well,
but it can hang/hook actions on scope entry/exit that you could use in a 
wrapper class.

4. IIRC, Log::Agent can represent enter,exits via indentation


WRT

The $caller_level variable is especially intriguing, as it's *almost*
what I need.  Instead of being "how many levels back up the call stack
you have to go to find the caller", which isn't very useful, I want it
to be "how many levels back up the call stack you have to go to find the



do you mean caller_depth ?  If so, that doesnt mean what you think it means.
Basically, it allows a wrapper class to tell L4P that "Im just a 
middleman!, caller(N) is
the end-customer".    The levels up to main is a run-time entity - its 
always changing.

hope this helps, and creates discussion..

Re: [log4perl-devel] l4p and win32

[Jim C. <jc...@di...>]

Viner, David wrote:

>yes, File::Spec was installed by default.  However, PPM wanted to install it
>anyway.  I'm not sure how exactly ppm decides what it needs to install.
>But, once I installed the File-Spec, all was well in the world.
>  
>

File-Spec recently got a version bump.  Maybe this triggered the upgrade 
- either explicitly
(by package require-ing latest), or by accidental PPM feature (hey 
theres a new one - get that too!)

[log4perl-devel] log4perl enhancement request ?

[Pete S. <si...@uc...>]

I'd like log4perl to indent messages to show caller depth in the call
stack.  A sample of this style is

  main: starting
    function1: called with arg1, arg2
    function1: returning value1
    function2: called
      function3: called
        function4: called with arg4
        function4: returning
      function3: returning
    function2: returning
  main: ending

For years, I've been doing this by passing around a scalar named
$CallDepth, and incrementing/decrementing it at function entry/exit.  I
pass around a second scalar named $DbgLevel that works sorta like the
levels in log4perl, but with more levels.  In the above sample, setting
it to 1 shows only the "main" lines, and 2 shows only "main" and
"function1" and "function2", etc.  I set the DbgLevel with a
command-line option, so I can produce logs with shallow or deep
hierarchies.  This scheme has been extremely useful for me, though a bit
cumbersome.  It even handles recursion nicely.

It seems like "Custom Cspecs" in PatternLayouts is the way to do this in
log4perl.  It's described at
http://log4perl.sourceforge.net/releases/Log-Log4perl/docs/html/Log/Log4perl/Layout/PatternLayout.html#9af52
The $caller_level variable is especially intriguing, as it's *almost*
what I need.  Instead of being "how many levels back up the call stack
you have to go to find the caller", which isn't very useful, I want it
to be "how many levels back up the call stack you have to go to find the
main program".  Perhaps "main program" could be defined by a new
function to mark the "zero" depth of the stack.

I confess to being a little lost as to how to do this, but I think it's
possible.  Am I crazy?

-- Pete

RE: [log4perl-devel] l4p and win32

[Viner, D. <dv...@ya...>]

yes, File::Spec was installed by default.  However, PPM wanted to install it
anyway.  I'm not sure how exactly ppm decides what it needs to install.
But, once I installed the File-Spec, all was well in the world.

if i'm the only person having this issue, then perhaps it's something weird
about my setup... or my uninstall/reinstall...

maybe the archive of this email will be sufficient... dunno....

dave

-----Original Message-----
From: Mike Schilli [mailto:msc...@ao...]
Sent: Friday, December 26, 2003 11:46 AM
To: Viner, David
Cc: Log4perl-Devel (E-mail)
Subject: RE: [log4perl-devel] l4p and win32


Viner, David wrote on 12/23/2003, 9:40 AM:

 > One thing we might consider... the ppd file requires File::Spec to be
 > available.  However, its not always appropriately available.

Sorry for the slow response -- trying to catch up ...

I'm surprised File::Spec isn't available, it should be a core module. 
Does 5.8.2 come without?

-- 
-- Mike
Mike Schilli
m...@pe...

RE: [log4perl-devel] l4p and win32

[Mike S. <msc...@ao...>]

Viner, David wrote on 12/23/2003, 9:40 AM:

 > One thing we might consider... the ppd file requires File::Spec to be
 > available.  However, its not always appropriately available.

Sorry for the slow response -- trying to catch up ...

I'm surprised File::Spec isn't available, it should be a core module. 
Does 5.8.2 come without?

-- 
-- Mike
Mike Schilli
m...@pe...

Re: [log4perl-devel] File Rollover

[Mike S. <msc...@ao...>]

Mark Pfeiffer wrote on 12/23/2003, 3:26 PM:

 > We handle multiple writers using flock().

Thanks for clarifying that, Mark. It seems like you're synchronizing 
every logged message via flock(), though (sub logit()) -- is that 
intended? I would guess this has a major performance impact.

-- 
-- Mike
Mike Schilli
m...@pe...

[log4perl-devel] Agenda 2004

[<age...@ci...>]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta http-equiv="" content="text/html; charset=iso-8859-1">
</head>
<body link="#000000" vlink="#000000" alink="#000000">
<table border="0" cellspacing="0" cellpadding="0" width="549">

  <tr> 

    <td width="595"><img src="http://www.bergman.com.ar/erivas/Agendas2004.gif" width="576" height="480" border="0" usemap="#Map"></td>

  </tr>

</table>

<table border="0" width="596" cellspacing="0" cellpadding="0" height="29">
  <tr>
    <td width="100%" height="29">
      <p align="center"><FONT size=-5 face="Arial">Est&aacute; recibiendo este 
        mensaje porque se ha suscripto en uno de nuestros sitios asociados. Respetamos 
        su privacidad y prometemos no abusar de este medio. Para ser removido 
        responda este mail con el asunto &quot;remover&quot;.</FONT></td>
  </tr>
</table>

<map name="Map">
  <area shape="rect" coords="144,370,436,389" href="mailto:age...@ci...">
</map>
</body>

</html>

Re: [log4perl-devel] File Rollover

[Mark P. <ma...@ml...>]

On Dec 15, Mike Schilli's good news was:

>=20
> King, James X -ND wrote on 12/15/2003, 11:50 AM:
>=20
>  > I=E2=80=99m looking into using the Log::Dispatch to do file rollover o=
n UNIX.
>  > I see that it supports file rollover into backup file(s) based on
>  > MaxFileSize; daily, weekly or monthly log files based on a DatePattern
>  > or defaults. I read your Readme file:
>=20
> I would suspect that Mark's rotator might get into trouble if several
> instances of the rolling logfile appender are doing their thing :).
> Mark, do you support (or plan on supporting) synchronization techniques?
> James could certainly use l4p's Synchronized composite appender to
> synchronize all output, but that's probably more than is really needed
> here. Is there a way to just synchronize the rollover process from
> within the rolling logfile appender?
>=20

Sorry for the slow response.

I think it handles synchonised rollovers from memory. Just let me take
a look...

If you have multiple writers that were started at different times you
will find each writer will try to rotate the log file at a recurrence
calculated from its start time. To sync all the writers just use a config
file and update it after starting your last writer. This will cause
Log::Dispatch::FileRotate->new() to be called by each of the writers
close to the same time, and if your recurrences aren't too close together
all should sync up just nicely.

We handle multiple writers using flock().

If you open up FileRotate.pm and search for:
=09Dan Waldheim

you'll see some coments regarding locking/forks and the like. This may
shed more light on what the code provides.

Hope that helps a little.

BTW, I am off the air until 12/1/04 (that's the 12th of Jan).

cheers
markpf
*** Merry whatever takes your fancy ***
Perception is reality - now you percieve me, now you don't

---------------------------------------------------------------------------=
-
       Mark Pfeiffer        |Email : Mar...@ml...
 Computer Systems Engineer  |Snail : PO Box 334,  Oatley, NSW, 2223, Austra=
lia
 MLP Consulting  Pty. Ltd   |Phone : 0417 447 538
---------------------------------------------------------------------------=
-

RE: [log4perl-devel] l4p and win32

[Viner, D. <dv...@ya...>]

after an evening of messing with my win32 installation, i got l4p to work.
i had to remove my perl5.6.1 installation, and reinstall 5.8.2.  Then i
followed the directions from 

	
http://log4perl.sourceforge.net/releases/Log-Log4perl/docs/html/Log/Log4perl
/FAQ.html#how_can_i_install_log__log4perl_on_microsoft_windows

One thing we might consider... the ppd file requires File::Spec to be
available.  However, its not always appropriately available.  I had to
download the zip archive from
http://ppm.activestate.com/PPMPackages/zips/8xx-builds-only/Windows/ ...
NOTE: that's for 5.8.2 Build 8xx ...for Builds 6xx (623), it'd be from
http://ppm.activestate.com/PPMPackages/zips/6xx-builds-only/, and for Build
5xx (522) it _should_ be from
http://ppm.activestate.com/PPMPackages/zips/5xx-builds-only/ but it's not
listed.

Even if you don't want to keep a copy of the archives in the l4p repository,
we should strongly consider adding some notes to the FAQ about this.

dave

-----Original Message-----
From: Viner, David [mailto:dv...@ya...]
Sent: Monday, December 22, 2003 2:59 PM
To: Log4perl-Devel (E-mail)
Subject: [log4perl-devel] l4p and win32


Hi,

I just upgraded my win32 perl installation from 5.6.1 to 5.8.2.  Now when I
run nmake test on the Log4perl tests, the following tests fail:

t\006Config-Java.....dubious
        Test returned status 5 (wstat 1280, 0x500)
DIED. FAILED test 2
        Failed 1/2 tests, 50.00% okay
t\007LogPrio.........ok
t\008ConfCat.........ok
t\009Deuce...........ok
t\010JConsole........dubious
        Test returned status 5 (wstat 1280, 0x500)
DIED. FAILED test 1
        Failed 1/1 tests, 0.00% okay
t\011JFile...........dubious
        Test returned status 5 (wstat 1280, 0x500)
DIED. FAILED test 1
        Failed 1/1 tests, 0.00% okay
t\012Deeper..........dubious
        Test returned status 5 (wstat 1280, 0x500)
DIED. FAILED tests 1-3
        Failed 3/3 tests, 0.00% okay
t\037JWin32Event.....dubious
        Test returned status 5 (wstat 1280, 0x500)


is this a known issue?

dave


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
log4perl-devel mailing list
log...@li...
https://lists.sourceforge.net/lists/listinfo/log4perl-devel

[log4perl-devel] l4p and win32

[Viner, D. <dv...@ya...>]

Hi,

I just upgraded my win32 perl installation from 5.6.1 to 5.8.2.  Now when I
run nmake test on the Log4perl tests, the following tests fail:

t\006Config-Java.....dubious
        Test returned status 5 (wstat 1280, 0x500)
DIED. FAILED test 2
        Failed 1/2 tests, 50.00% okay
t\007LogPrio.........ok
t\008ConfCat.........ok
t\009Deuce...........ok
t\010JConsole........dubious
        Test returned status 5 (wstat 1280, 0x500)
DIED. FAILED test 1
        Failed 1/1 tests, 0.00% okay
t\011JFile...........dubious
        Test returned status 5 (wstat 1280, 0x500)
DIED. FAILED test 1
        Failed 1/1 tests, 0.00% okay
t\012Deeper..........dubious
        Test returned status 5 (wstat 1280, 0x500)
DIED. FAILED tests 1-3
        Failed 3/3 tests, 0.00% okay
t\037JWin32Event.....dubious
        Test returned status 5 (wstat 1280, 0x500)


is this a known issue?

dave

[log4perl-devel] Tech Sector - Barcharts say 100 Percent to the Upside...claudette

[Jacklyn D. <y23...@ya...>]

Here you go.  The technicals are perfect.  I hear NMMG is going to unveil =
its new technology in February.

http://quotes.barchart.com/texpert.asp?sym=3DNMMG































nfv  gbhwu ymcrqw
ppiyhtmn sq no ii fr xu zmlyplss
utv

Re: [log4perl-devel] Automatic new logfiles for new packages.

[Marco A. V. C. <mav...@bi...>]

Hi MIke,

  I've decide go with add_appender() sugestion, since all Adaptors has to 
inherit from a Adaptor class I've put the code on my construtor. This will make 
the impact on my maintainability be very small. Since others may have the same 
problem I'm posting the relevant part of my code for reference.

Thanks.
Marco.

in Adaptor class, which is parent of all Adaptors here is the constructor 
(comments are in portuguese):

sub new {
     my($caller,$parent) = @_;
     $logger->logconfess("Missing parent reference") unless $parent;
     #Load info...
     $logger->info($caller."->new(".ref($parent).") Version: ".
         $caller->VERSION." ".$__PACKAGE__::REVISION);

     # Definindo um arquivo de log separado para cada
     # adaptador.
     # # Recuperando o logger do adaptador.
     my $adpt_logger = Log::Log4perl->get_logger($caller);

     # Isolando apenas o nome do adaptador.
     $caller=~m/::([^:]+)$/;
     my $adpt_name = $1;

     # Definindo um novo appender para este adaptador.
     my $file_appender = Log::Log4perl::Appender->new(
         "Log::Dispatch::File",
         mode      => "append",
         name      => "$adpt_name",
         filename  => "/tmp/biti_$adpt_name.log"
     );

     # Agora o layout deste appender...
     my $layout = Log::Log4perl::Layout::PatternLayout->new("%d %C %m %n");

     $file_appender->layout($layout);
     $adpt_logger->add_appender($file_appender);

     # Creating new object...
     my $self = bless{}, ref($caller) || $caller;
     $self->{INTER_REF} = $parent; # Our reference to Inter parent.
     return $self;
}



Mike Schilli wrote:
> Marco Aurelio Valtas Cunha wrote on 12/12/2003, 2:24 AM:
> 
>  > I was thinking in have one file for each
>  > Adaptor, but this means write one more Appender configuration for each
>  > Adaptor.
>  > But I expect more and more Adaptors and as a programmer I'm very lazy,
>  > the
>  > result I want is that each new adaptor added in my conf file will
>  > imply a nre
>  > log file with it's name.
> 
> The file appenders that come with Log::Log4perl and Log::Dispatch 
> require that the name of the file they're logging to is specified as a 
> property -- this leaves you with the manual approach: Define an appender 
> for every file and assign each of them to a different logger (but watch 
> out for messages bubbling up, see the FAQ).
> 
> If you want to automate the creation of these appenders, you could 
> (somewhat at the expense of the maintainability of your script/config 
> file) leave your config file like it is and use l4p's add_appender() 
> method in your code like this:
> 
>           my $logger = Log::Log4perl->get_logger("My.Component");
>           $logger->add_appender($app);
> 
> to add a previously defined appender $app to this logger.
> 
> Or, you could automate creating the l4p conf file with a script.
> 

-- 
Marco A Valtas Cunha     http://scarecrow.fmrp.usp.br/~mavcunha/
Lab de Bioinformatica    http://bit.fmrp.usp.br
Hemocentro de Rib Preto  http://ctc.fmrp.usp.br
Fax: 55 16 3963-9309     Tel: 55 16 3963-9300 R:9603

[log4perl-devel] TECH SECTOR - Technology Breakthrough - Patents Filed...ganit

[Seth T. <ws...@ya...>]

TECHNOLOGY SECTOR - TECHNOLOGY BREAKTHROUGH - PATENTS FILED

Symbol: NMMG
Market: OTC.BB
Sector: L.E.D. TECHNOLOGY


Barcharts Rate NMMG an 80% BUY - http://quotes.barchart.com/texpert.asp?sy=
m=3DNMMG


BREAKING NEWS in technology - New Millennium Media International (OTCBB: N=
MMG) announces that it has officially filed its patents---with over 50 cla=
ims---protecting its revolutionary technology, a breakthrough in (LED) arc=
hitecture.  The OnScreen=99 LED Display Architecture is a radical new type=
 of Bright LED video display architecture that is expected to revolutioniz=
e the 1.5 billion dollar LED display market.  This breakthrough technology=
 will give NMMG great potential to capture significant market share in the=
 the 19 billion dollar outdoor advertising market.

With all the new initiatives in Homeland Security and the Amber Alert, Int=
elligent Message Signs (IMS) are the future, and with the recent signing o=
f new laws and federally mandated funds in the billions of dollars, NMMG a=
nd its patent-pending OnScreen technology is poised to lead the way.  NMMG=
 currently has the only technology that allows it to build onto exisiting =
infrastructure, i.e. road signs, billboards, etc.  Imagine one day you are=
 driving home on the freeway past a road sign you have seen a thousand tim=
es before--but this time you notice something different.  This time you se=
e a WARNING lit up--truck overturned 1 mile ahead--hazardous chemicals spi=
lled.  The sign advises you to exit immediately and to safety.  Such a war=
ning was broadcast instantly and using NMMG's OnScreen technology.  You ne=
ver noticed, as you drove by the roadside every day, that OnScreen was dra=
ped over the sign all this time.  Now it has sprung into action by the pun=
ch of a button on a PC from a central station--instantly and just in the n=
ick of time.  You have just experienced OnScreen technology.  And that is =
just one example.  The possibilities are limitless.  And because OnScreen =
can be applied to existing structures like road signs or billboards, its c=
ost-effectiveness makes it far and away the technology choice.

NMMG will unveil its breakthrough technology at the STRATEGIES IN LIGHT co=
nference on February 2-4, 2004 at the San Mateo Marriott Hotel in San Mate=
o, California. This unique event is considered to be the premier annual fo=
rum for addressing commercial developments in high-brightness LEDs, as wel=
l as an unparalleled networking opportunity for suppliers and users of the=
se devices. The growing interest in, and expanding attendance at, this eve=
nt, reflects the excitement associated with a market that has grown by 50=
% since 2000, while other semiconductor and optical component industries h=
ave stagnated or experienced large declines.



ON-SCREEN=99 TECHNOLOGY

OnScreen=99 is expected to create a broad-range of products with much bett=
er resolution and brighter pictures than the current generation of display=
s. OnScreen=99 will be visible in direct sunlight yet avoid many of the is=
sues associated with current displays including sun-loading, wind-loading =
and excessive weight.  In addition, the new LED architecture produces an a=
dvantage that is not available in today's marketplace: a more lightweight,=
 pliable display that can fit any application.  These are important advant=
ages as the High Brightness LED market is expected to grow from 1.2 billio=
n dollars in 2000 to 4 billion in 2006.  In addition, according to Stanfor=
d Resources, the LED sign market value alone is expected to exceed 1 billi=
on by 2006. These projections are made based on existing technology and do=
 not take into account emerging technologies, such as OnScreen=99, that ca=
n rapidly alter the size and shape of this market.



COMMERCIAL MARKET & STRATEGY

NMMG's initial marketing strategy revolves around licensing intellectual p=
roperty (IP) to worldwide manufacturers of LED display products and compon=
ents. The LED sign market is projected to reach over 1 billion dollars by =
2006. Lumiled's projects that high brightness LED's, used in LED signs alo=
ne, will exceed 1.2 billion by 2007. If these projections hold, the fully =
manufactured signs would represent a $5 billion market. Whichever number i=
s accurate, they both point towards a robust market for these new LED disp=
lays. Many projections don't take into account emerging high growth applic=
ations such as the Amber Alert project, Homeland Security and roadway =93i=
ntelligent message transfer=94.



THE MARKET

An article in Media Post's Media Daily News in March of 2003 noted that th=
e outdoor industry has successfully weathered the recession and that =93ou=
r large members say they're having a great first quarter=94 in 2003. They =
go on to note that technology is expected to transform both the display an=
d measurement of outdoor advertising. According to Media Daily the most ex=
citing news is coming on the display side, where =93Lamar Advertising is c=
onverting their key boards to LED units whose messages can be changed at w=
ill and sold in day-parts by the hour or even the minute.=94 They added th=
at =93Clear Channel's backlit subway panels in stairwells are being conver=
ted to LED as well=94. Together these companies represent two of the three=
 largest outdoor US advertisers.  

Recent Federal Government legislation has also placed a spotlight on expan=
ding the =93Amber Alert=94 network nationwide. The highly publicized succe=
ss in locating a number of kidnapped children shortly after their abductio=
n in California has now triggered federal funding for U.S.-wide expansion =
of these variable-message signs.  Homeland Security issues have also incre=
ased the number of early warning signs being planned and funded as part of=
 an overall information sharing network. Traffic safety is also becoming a=
 much higher priority in the U.S.. It is estimated that just over 60,000 r=
oadway dynamic message signs are in operation in the United States. In Jap=
an alone there are over 1.5 million of these signs. The United States repr=
esents a huge growth market for LED displays.



GROWTH OPPORTUNITES

In addition to the outdoor television market, another interesting and exci=
ting application for OnScreen=99 arrays is artistic lighting in dramatic c=
urved and shaped displays in places like Las Vegas, New York City or reall=
y virtually any venue. The tensile, flexible structure of OnScreen=99 prov=
ides unlimited opportunity for creativity. 

The anticipated cost reductions of OnScreen=99 will also provide ample opp=
ortunity for growth of the large-scale LED display market itself. OnScreen=
=99's unique architecture opens the door for new applications such as curv=
ed implementations, billboards on the sides of buildings where tenants can=
 still see out, and lower cost mobile applications on the sides of existin=
g vehicles. 

Homeland Security, Amber Alert variable message signage and instant messag=
e transfer applications can also benefit significantly from the advantages=
 of OnScreen=99. Reduced wind-loading and weight can significantly lower t=
he cost of the superstructures required to support these signs and also re=
duce the cost to install and maintain them.




JUST LOOK WHO IS ALREADY ON BOARD

New Millennium has established a Technology Breakthroughsentific Advisory =
Board comprised of leading experts in key categories in the research and m=
arketing of LED technology.

David Pelka, Ph.D.- Chairman =96 Well known expert in physics, founded TIR=
 Technologies Inc. to pursue patents for his LED lighting systems and LCD =
backlits.  Dr. Pelka secured more than $2 million in venture capital and l=
icensing for TIR before it was acquired by Teledyne Electronic Technologie=
s (NYSE:TDY).  Since the buyout, Dr. Pelka has served as Director of Produ=
ct Development for Teledyne Lighting and Display Products.  Dr. Pelka's ac=
colades include fellowships and awards from the Smithsonian, National Defe=
nse, Northrop University and Ebell Fellowship, as well as countless articl=
es published in both classified (the U.S. Air Force and Army) publications=
 and various non-classified publications.  He has founded several technolo=
gy companies, which he successfully expanded by building strong revenue st=
reams and securing venture capital investments and government contracts. 
 
 
Robert V. Steele, Ph.D. =96 Director of Optoelectronics Programs and Chair=
man of the annual conference =93Strategies in Light=94 for Strategies Unli=
mited.  Steele is responsible for all of Strategies Unlimited's activities=
 in the area of optoelectronic components, for which the 23-year-old marke=
t research firm has specialized in providing market research reports and c=
onsulting services.  Co-author of =93Solid-State Lighting: New Growth Oppo=
rtunities for High-Brightness LED's=94, Dr. Steele writes regularly for in=
dustry publications on high-brightness LED markets and applications such a=
s Forbes, The Wall Street Journal, The Economist and more. 
 
 
John Biondo =96 Owner and President of Silicon Robotics Corporation, which=
 provides various product development services including electronic and el=
ectromechanical design, software development, optics, and project manageme=
nt.  Biondo also has extensive patent-process experience.  In 1980, Biondo=
 launched Electric Filmworks, which produced computer-generated visual eff=
ects for the television and motion picture industry.  He also designed an =
apparatus using newly available and inexpensive microcomputers, which allo=
wed the company to compete successful against older, more established firm=
s.  To transfer from the service-sector into manufacturing, Biondo sold El=
ectric Filmworks in 1989 and co-founded Amazing Photos.  Amazing Photos de=
signed, manufactured and sold a variety of innovative coin-operated photo =
booths.  Polaroid Corporation licensed and marketed the two most popular a=
nd cost effective booths under their own name. 
 
 
Richard Reis, Ph.D. =96 Executive Director of the Alliance for Innovative =
Manufacturing at Stanford and Director for Academic Partnerships in the St=
anford Learning Laboratory.  Dr. Reis' impressive career includes serving =
as; the Executive director of the Stanford Center for integrated Systems, =
a major research partnership between Stanford and 15 industrial companies;=
 a Consulting Professor in both the Stanford University Electrical and Mec=
hanical Engineering departments; professor of a year-round seminar that is=
 part of the Stanford University Future Professors of Manufacturing progra=
m; a professor of astronomy at the College of San Mateo, Calif.; and a cur=
riculum consultant at Menlo College, Calif. 
 
 
Ben Jacobson, Ph.D. =96 Dr. Jacobson has worked on numerous impressive LED=
 projects that have exponentially increased beam density and brightness an=
d reduced system costs. Additionally, these projects have improved power r=
equirements, heat load and LED count, while improving compactness, efficie=
ncy and performance over competitors' products.  Dr. Jacobson was instrume=
ntal in positioning Illumitech as a new company developing high-performanc=
e LED lighting systems with thermal packaging.  Dr. Jacobson has over a de=
cade of experience developing and marketing new technology for the display=
 industry, both in his previous positions and currently at Illumitech.  Pr=
ior to Illumitech, Dr. Jacobson held various executive and research direct=
orial positions at EG Controls Inc., ARCH Venture Partners, NiOptics Corpo=
ration and the University of Chicago.  He has seven U.S. patents, and has =
published 13 research articles and seven conference presentations. 
 
 
Joseph D. Tajnai, Ph.D. =96 Dr. Tajnai is a consultant in Optical Radiatio=
n Safety, LED's & Applications and Optics & Optical Measurement Training. =
He was an engineer, Technology Breakthroughsentist and technical manager f=
or 23 years at Hewlett-Packard and Agilent Technologies. He has focused on=
 fiber optic development, LED development and measurements, new product pr=
ocesses, mathematical modeling and international and US standards and regu=
lations. He also worked with GE Sylvania for nine years and contributed he=
avily to their YAG laser development. Dr. Tajnai received his BS, MS and P=
h.D. from California Institute of Technology in Electrical Engineering and=
 Applied Physics. 











Please note that NMMG had absolutley nothing to do with this report and is=
 not a participant in any way.









No more advertisements: www.inet-notification.com/away.html









Technology Breakthroughs is an independent research firm. This report is b=
ased on Technology Breakthroughs's independent analysis but also relies on=
 information supplied by sources believed to be reliable. This report may =
not be the opinion of NMMG management. Technology Breakthroughs has also b=
een retained to research and issue reports on NMMG. Technology Breakthroug=
hs may from time to time purchase or sell NMMG common shares in the open m=
arket without notice. The information contained in this report shall not c=
onstitute, an offer to sell or solicitation of any offer to purchase any s=
ecurity. It is intended for information only. Some statements may contain =
so-called "forward-looking statements". Many factors could cause actual re=
sults to differ. Investors should consult with their Investment Advisor co=
ncerning NMMG. Copyright 2003 =A9 Technology Breakthroughs. All Rights Res=
erved. Technology Breakthroughs was paid eight thousand dollars to distrib=
ute this report. Technology Breakthroughs is not affiiated with Technology=
 Breakthroughs and is not responsible for newsletter content.  All informa=
tion in this report can be obtained on the world wide web at www.nmmimedia=
com.  New Millenimum Media was not a participant in this newsletter in an=
y way.



























obzhke nyuna   bgvui
kaqcdm   dd zvop j ckowlptahk zwvydb