Re: [ANNOUNCE] Apache::Dispatch-0.03

2000-08-09 Thread Barrie Slaymaker

Roger Espel Llima wrote:
 
  @{"${class}::ISA"}
 
 Incidentally, does anyone know of a way to do this that works under
 strict?  The above requires a "no strict 'refs'" to work.

Something like this we3nt by on p5p a while ago (IIRCC):

   @{$main::{"$class\::"}-{ISA}}

but that's a lot more cryptic that

   {
  no strict 'refs' ;
  @{"${class}::ISA"} ;
   }

- Barrie



RE: [ANNOUNCE] Apache::Dispatch-0.03

2000-08-08 Thread Matt Sergeant

On Mon, 7 Aug 2000, Geoffrey Young wrote:

 ok, here's a pre-PAN 
 
 http://morpheus.laserlink.net/~gyoung/modules/Apache-Dispatch-0.04.tar.gz
 
 I borrowed some code from Apache::StatINC to add a single module reload.  
 
 Unfortunately, this doesn't cover inherited circumstances, although I don't
 know how important that is going to be to folks.
 
 I really wanted to have DispatchStat be On, Off, or ISA, where ISA reloaded
 the asked for module and all it's parents  - since given Class-method(),
 method() might not actually be in Class.  Basically, I wasn't able to find a
 way to get to @Class::ISA where Class is unknown until run-time (that is,
 it's held in $class).  I figured I should be able to use some symbolic
 referencing or something, but I couldn't get it to work.

@{"${class}::ISA"}

-- 
Matt/

Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org




Re: [ANNOUNCE] Apache::Dispatch-0.03

2000-08-08 Thread Roger Espel Llima

Matt Sergeant wrote:
  I really wanted to have DispatchStat be On, Off, or ISA, where ISA reloaded
  the asked for module and all it's parents  - since given Class-method(),
  method() might not actually be in Class.  Basically, I wasn't able to find a
  way to get to @Class::ISA where Class is unknown until run-time (that is,
  it's held in $class).  I figured I should be able to use some symbolic
  referencing or something, but I couldn't get it to work.

 @{"${class}::ISA"}

Yep, that's one weird bit of syntax.  I just needed this recently to
write a test.pl, and it took quite a bit of testing to get it working. :)

Incidentally, does anyone know of a way to do this that works under
strict?  The above requires a "no strict 'refs'" to work.

-- 
Roger Espel Llima, [EMAIL PROTECTED]
http://www.iagora.com/~espel/index.html



RE: [ANNOUNCE] Apache::Dispatch-0.03

2000-08-08 Thread Geoffrey Young



 -Original Message-
 From: Roger Espel Llima [mailto:[EMAIL PROTECTED]]
 Sent: Tuesday, August 08, 2000 12:52 PM
 To: [EMAIL PROTECTED]
 Subject: Re: [ANNOUNCE] Apache::Dispatch-0.03
 
[snip]
 
 Yep, that's one weird bit of syntax.  I just needed this recently to
 write a test.pl, and it took quite a bit of testing to get it 
 working. :)

this showed up in p5p in late june...
  $foo = "bar";
  @$foo = (1,2,3);
  $foo-[1] = 4;
  print @bar;

wicked cool...

--Geoff

 
 Incidentally, does anyone know of a way to do this that works under
 strict?  The above requires a "no strict 'refs'" to work.
 
 -- 
 Roger Espel Llima, [EMAIL PROTECTED]
 http://www.iagora.com/~espel/index.html
 



Re: [ANNOUNCE] Apache::Dispatch-0.03

2000-08-08 Thread ___cliff rayman___

Geoffrey Young wrote:

  -Original Message-
  From: Roger Espel Llima [mailto:[EMAIL PROTECTED]]
  Sent: Tuesday, August 08, 2000 12:52 PM
  To: [EMAIL PROTECTED]
  Subject: Re: [ANNOUNCE] Apache::Dispatch-0.03
 
 [snip]
 
  Yep, that's one weird bit of syntax.  I just needed this recently to
  write a test.pl, and it took quite a bit of testing to get it
  working. :)

 this showed up in p5p in late june...
   $foo = "bar";
   @$foo = (1,2,3);
   $foo-[1] = 4;
   print @bar;

 wicked cool...

standard symbolic referencing.



 --Geoff

 
  Incidentally, does anyone know of a way to do this that works under
  strict?  The above requires a "no strict 'refs'" to work.

nope.  purposely does not work under strict.


--
___cliff [EMAIL PROTECTED]http://www.genwax.com/





Re: [ANNOUNCE] Apache::Dispatch-0.03

2000-08-08 Thread Matt Sergeant

On Tue, 8 Aug 2000, Roger Espel Llima wrote:

  @{"${class}::ISA"}
 
 Yep, that's one weird bit of syntax.  I just needed this recently to
 write a test.pl, and it took quite a bit of testing to get it working. :)
 
 Incidentally, does anyone know of a way to do this that works under
 strict?  The above requires a "no strict 'refs'" to work.

No, thats a standard thing that is disabled under strict. Of course you'd
only be doing that in some neat hack, so locally disabling strict isn't a
big deal (strict is a lexical pragma, so it only applies in the current
scope).

-- 
Matt/

Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org




RE: [ANNOUNCE] Apache::Dispatch-0.03

2000-08-07 Thread Geoffrey Young

for anyone who is interested (apparently not many :) I ran a quick "hello
world" LWP::Simple based benchmark using Apache::Registry (with
RegistryLoader), a normal PerlHandler, and Apache::Dispatch...

Benchmark: timing 5000 iterations of dispatch, handler, registry...
  dispatch: 108 wallclock secs (24.21 usr +  5.73 sys = 29.94 CPU) @
167.00/s (n=5000)
   handler: 91 wallclock secs (22.88 usr +  5.71 sys = 28.59 CPU) @ 174.89/s
(n=5000)
  registry: 98 wallclock secs (23.77 usr +  5.45 sys = 29.22 CPU) @ 171.12/s
(n=5000)

and also uncovered a small bug:

--- Dispatch.pm 2000/08/04 15:36:32 1.8
+++ Dispatch.pm 2000/08/07 12:00:41
@@ -105,9 +105,8 @@
 # since the uri is dispatchable, check each of the extras
 #-
 
-  my @extras  = $dcfg-{_extras} ? 
-  @{$dcfg-{_extras}} : 
-  @{$scfg-{_extras}};
+  my @extras  = $dcfg-{_extras} ? @{$dcfg-{_extras}} :
+$scfg-{_extras} ? @{$scfg-{_extras}} : undef;
 
   foreach my $extra (@extras) {
 if ($extra eq "PRE") {


just FYI...

--Geoff





RE: [ANNOUNCE] Apache::Dispatch-0.03

2000-08-07 Thread Matt Sergeant

On Mon, 7 Aug 2000, Geoffrey Young wrote:

 for anyone who is interested (apparently not many :) I ran a quick "hello
 world" LWP::Simple based benchmark using Apache::Registry (with
 RegistryLoader), a normal PerlHandler, and Apache::Dispatch...
 
 Benchmark: timing 5000 iterations of dispatch, handler, registry...
   dispatch: 108 wallclock secs (24.21 usr +  5.73 sys = 29.94 CPU) @
 167.00/s (n=5000)
handler: 91 wallclock secs (22.88 usr +  5.71 sys = 28.59 CPU) @ 174.89/s
 (n=5000)
   registry: 98 wallclock secs (23.77 usr +  5.45 sys = 29.22 CPU) @ 171.12/s
 (n=5000)

Does Dispatch stat() the module on every hit? It might be useful to
provide a switch to turn that off, if so.

-- 
Matt/

Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org




RE: [ANNOUNCE] Apache::Dispatch-0.03

2000-08-07 Thread Geoffrey Young



 -Original Message-
 From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
 Sent: Monday, August 07, 2000 8:57 AM
 To: Geoffrey Young
 Cc: '[EMAIL PROTECTED]'
 Subject: RE: [ANNOUNCE] Apache::Dispatch-0.03
 
 
 On Mon, 7 Aug 2000, Geoffrey Young wrote:
 
  for anyone who is interested (apparently not many :) I ran 
 a quick "hello
  world" LWP::Simple based benchmark using Apache::Registry (with
  RegistryLoader), a normal PerlHandler, and Apache::Dispatch...
  
  Benchmark: timing 5000 iterations of dispatch, handler, registry...
dispatch: 108 wallclock secs (24.21 usr +  5.73 sys = 29.94 CPU) @
  167.00/s (n=5000)
 handler: 91 wallclock secs (22.88 usr +  5.71 sys = 
 28.59 CPU) @ 174.89/s
  (n=5000)
registry: 98 wallclock secs (23.77 usr +  5.45 sys = 
 29.22 CPU) @ 171.12/s
  (n=5000)
 
 Does Dispatch stat() the module on every hit? It might be useful to
 provide a switch to turn that off, if so.

here's the only strace fragment with stat calls (with PerlSendHeaders Off)

read(3, "GET /Dispatch/foo HTTP/1.0\r\nConn"..., 4096) = 854
rt_sigaction(SIGUSR1, {SIG_IGN}, {SIG_IGN}, 8) = 0
time(NULL)  = 965653681
gettimeofday({965653681, 395188}, NULL) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [RT_0], 8) = 0
stat("/usr/local/apache/spinnaker/Dispatch/foo", 0xb7cc) = -1 ENOENT (No
such file or directory)
stat("/usr/local/apache/spinnaker/Dispatch", 0xb7cc) = -1 ENOENT (No
such file or directory)
stat("/usr/local/apache/spinnaker", {st_mode=S_IFDIR|0755, st_size=1024,
...}) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [RT_0], 8) = 0
rt_sigaction(SIGALRM, NULL, {0x40099490, [], SA_INTERRUPT|0x400}, 8) = 0
dup2(15, 2) = 2

which I would guess is just apache doing apache translation things, right?  

After determining the proper class-method() by parsing the uri and making
some assumptions, Dispatch.pm calls class-can(method), which does magic
things, of which I know little about the inner workings...

I was interested in somehow trying to cache known methods to avoid
successive can() calls, but I wasn't quite sure how to go about that one
yet...

does that help?

--Geoff
 
 -- 
 Matt/
 
 Fastnet Software Ltd. High Performance Web Specialists
 Providing mod_perl, XML, Sybase and Oracle solutions
 Email for training and consultancy availability.
 http://sergeant.org | AxKit: http://axkit.org
 



RE: [ANNOUNCE] Apache::Dispatch-0.03

2000-08-07 Thread Matt Sergeant

On Mon, 7 Aug 2000, Geoffrey Young wrote:

  Does Dispatch stat() the module on every hit? It might be useful to
  provide a switch to turn that off, if so.
 
 which I would guess is just apache doing apache translation things, right?  

Yes, as the guide says, you could install an Apache::OK trans handler to
get rid of those.

 After determining the proper class-method() by parsing the uri and making
 some assumptions, Dispatch.pm calls class-can(method), which does magic
 things, of which I know little about the inner workings...
 
 I was interested in somehow trying to cache known methods to avoid
 successive can() calls, but I wasn't quite sure how to go about that one
 yet...
 
 does that help?

No, because it's not what I meant :-)

Assuming you're in a development stage, I might expect Dispatch to stat
the module that it's loading, like StatINC does, to check if it needs
reloading again. And I'd turn that off for development. This gives you
the advantage that Apache::Registry has of re-loading new scripts (except
in Dispatch's case, its a module not a script). And it won't stat _all_
the modules installed on every hit, like StatINC does, so the overhead
should be reasonable.

-- 
Matt/

Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org




RE: [ANNOUNCE] Apache::Dispatch-0.03

2000-08-07 Thread Geoffrey Young



 -Original Message-
 From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
 Sent: Monday, August 07, 2000 9:29 AM
 To: Geoffrey Young
 Cc: '[EMAIL PROTECTED]'
 Subject: RE: [ANNOUNCE] Apache::Dispatch-0.03
 
 
 On Mon, 7 Aug 2000, Geoffrey Young wrote:
 
   Does Dispatch stat() the module on every hit? It might be 
 useful to
   provide a switch to turn that off, if so.
  
  which I would guess is just apache doing apache translation 
 things, right?  
 
 Yes, as the guide says, you could install an Apache::OK trans 
 handler to
 get rid of those.
 
  After determining the proper class-method() by parsing the 
 uri and making
  some assumptions, Dispatch.pm calls class-can(method), 
 which does magic
  things, of which I know little about the inner workings...
  
  I was interested in somehow trying to cache known methods to avoid
  successive can() calls, but I wasn't quite sure how to go 
 about that one
  yet...
  
  does that help?
 
 No, because it's not what I meant :-)

oh :)

 
 Assuming you're in a development stage, I might expect 
 Dispatch to stat
 the module that it's loading, like StatINC does, to check if it needs
 reloading again. And I'd turn that off for development. This gives you
 the advantage that Apache::Registry has of re-loading new 
 scripts (except
 in Dispatch's case, its a module not a script). And it won't 
 stat _all_
 the modules installed on every hit, like StatINC does, so the overhead
 should be reasonable.

well, I had assumed that for development, one could just install StatINC and
have that work, but I didn't actually try it. until now, that is, and yes,
it works...

so, you are desiring a StatINC like feature within Dispatch itself?  sounds
like overkill to me - after all, you're in development, so stat()ing
everything shouldn't be a big deal...  

--Geoff


 
 -- 
 Matt/
 
 Fastnet Software Ltd. High Performance Web Specialists
 Providing mod_perl, XML, Sybase and Oracle solutions
 Email for training and consultancy availability.
 http://sergeant.org | AxKit: http://axkit.org
 



RE: [ANNOUNCE] Apache::Dispatch-0.03

2000-08-07 Thread Matt Sergeant

On Mon, 7 Aug 2000, Geoffrey Young wrote:

  Assuming you're in a development stage, I might expect 
  Dispatch to stat
  the module that it's loading, like StatINC does, to check if it needs
  reloading again. And I'd turn that off for development. This gives you
  the advantage that Apache::Registry has of re-loading new 
  scripts (except
  in Dispatch's case, its a module not a script). And it won't 
  stat _all_
  the modules installed on every hit, like StatINC does, so the overhead
  should be reasonable.
 
 well, I had assumed that for development, one could just install StatINC and
 have that work, but I didn't actually try it. until now, that is, and yes,
 it works...
 
 so, you are desiring a StatINC like feature within Dispatch itself?  sounds
 like overkill to me - after all, you're in development, so stat()ing
 everything shouldn't be a big deal...  

OK, so take development out of the picture, and put in there a server that
you can't restart, but would like to be able to tweak your scripts on...

-- 
Matt/

Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org




RE: [ANNOUNCE] Apache::Dispatch-0.03

2000-08-07 Thread Geoffrey Young



 -Original Message-
 From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
 Sent: Monday, August 07, 2000 9:45 AM
 To: Geoffrey Young
 Cc: '[EMAIL PROTECTED]'
 Subject: RE: [ANNOUNCE] Apache::Dispatch-0.03
 

  
  so, you are desiring a StatINC like feature within Dispatch 
 itself?  sounds
  like overkill to me - after all, you're in development, so stat()ing
  everything shouldn't be a big deal...  
 
 OK, so take development out of the picture, and put in there 
 a server that
 you can't restart, but would like to be able to tweak your 
 scripts on...

yeah, yeah... :)

actually, someone else asked me off the list for the same type of thing - I
wasn't so sure about it, but I guess now I'm out numbered...

DispatchStat On|Off
coming soon to a server near you...

--Geoff

 
 -- 
 Matt/
 
 Fastnet Software Ltd. High Performance Web Specialists
 Providing mod_perl, XML, Sybase and Oracle solutions
 Email for training and consultancy availability.
 http://sergeant.org | AxKit: http://axkit.org
 



RE: [ANNOUNCE] Apache::Dispatch-0.03

2000-08-07 Thread Geoffrey Young

ok, here's a pre-PAN 

http://morpheus.laserlink.net/~gyoung/modules/Apache-Dispatch-0.04.tar.gz

I borrowed some code from Apache::StatINC to add a single module reload.  

Unfortunately, this doesn't cover inherited circumstances, although I don't
know how important that is going to be to folks.

I really wanted to have DispatchStat be On, Off, or ISA, where ISA reloaded
the asked for module and all it's parents  - since given Class-method(),
method() might not actually be in Class.  Basically, I wasn't able to find a
way to get to @Class::ISA where Class is unknown until run-time (that is,
it's held in $class).  I figured I should be able to use some symbolic
referencing or something, but I couldn't get it to work.

other than that, it seems to work ok...

suggestions welcome :)

--Geoff