Re: Exception modules
On Mon, 30 Apr 2001, Perrin Harkins wrote: > I've tried that, but last time I went with more general > classes of exceptions containing unique error IDs > (defined in a constants module) to indicate the exact > type. Not as Java-like, but it did save me from > creating dozens of classes with no unique properties > except their names. yeah. the only really cool thing about having separate exception classes is that they can add their own methods. sometimes that's useful. > I suppose it's a matter of debate whether or not bad > user input should be handled with exceptions at all, but i prefer them cos then i can have lots of methods with "void return type". then i can call lots of methods in a single eval black and never have to check any return values. just a stylistic preference i guess.
Re: Exception modules
on 4/30/01 8:47 PM, brian moseley at [EMAIL PROTECTED] wrote: > On Mon, 30 Apr 2001, Jeffrey W. Baker wrote: > >> type of exception. Right now I cannot in fact think of >> any program I have written that branches on the type of >> exception. Java encourages this with multiple catch > > in CP Web Mail, the underlying libraries throw typed > exceptions so that the application layer can display the > correct error notification to the user. for instance, if the > library throws CP::InvalidMailboxNameException, Web Mail can > display 'the mailbox name you suggested contains an illegal > character. it must correspond to the format thus-and-such. > try again.', whereas if the library throws CP::Exception > (the generic exception), Web Mail will handle it as a > service problem and display that godawful WM page. I've tried that, but last time I went with more general classes of exceptions containing unique error IDs (defined in a constants module) to indicate the exact type. Not as Java-like, but it did save me from creating dozens of classes with no unique properties except their names. I've also tried making separate hierarchies of exceptions for user errors (illegal input) vs. system errors (can't connect to database). In those cases, you usually do switch based on exception class, because the user errors need to be handled differently. I suppose it's a matter of debate whether or not bad user input should be handled with exceptions at all, but since I like to keep the controller code simple and let the data model objects do the input checking, you have to bubble it back up somehow. I'm still kind of unsatisfied with how difficult some of the user exception handling turned out to be, and I'll probably try something different next time - Perrin
PerlAccessHandler -- struggling and drowning
Eeyore here, again, less happy than ever. S.O.S.
okay. i try to use the Ticket*.pm modules from the book
(chapter 6) verbatim and they work well for well-behaved
browsers.
to widen the workability (i.e. to make it functional for
badly-mannered browsers*) i'm trying some workarounds.
this is a PerlAccessHandler, which should check for the existence
of a cookie in the incoming headers, and if not there (or
expired) it should redirect the browser to a login area that
takes name/password pair, and if valid, would then return the
browser to the original URL. to do that, as we issue the
'redirect to the login area' we set a cookie containing the URL
to return to.
problem: some browsers see 'redirect' and ignore all other
headers, so the cookies aren't set. when the browser arrives at
the login area, there's no cookie to send there, to formulate
a return-to address from.
man CGI says 'we don't do http-equiv "meta" headers because you
can do those in header_out instead'. what's the politically
correct way to do this?
this also doesn't work (PerlAccessHandler)-- what would need to
be bent to make this function properly?
my $ticketTool = Apache::TicketTool->new($r);
#...
my $cookie = $ticketTool->make_return_address($r);
# (so we can get back to where user wanted to be)
my $login_uri = $r->dir_config("TicketLogin");
# instead of book's "ErrorDocument 403" example
use CGI '-autoload';
# note: PerlAccessHandler
print
header(-refresh => "1; URL=$login_uri", -cookie => $cookie),
start_html(-title => 'Redirecting to login', -bgcolor => 'white'),
h1('Please log in'),
p("You're being redirected to ",
a({-href=>$login_uri},$login_uri),
" in just a moment."),
h2("Please stand by..."),
end_html();
# return WHAT?
* note that the manners-ability of the browsers, being the
problem, is something i'm accepting on faith. if there's
another explanation (with a workaround that i might have a
chance at understanding) i'd love to hear it.
--
don't visit this page. it's bad for you. take my expert word for it.
http://www.salon.com/people/col/pagl/2001/03/21/spring/index1.html
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Re: Exception modules
On Mon, Apr 30, 2001 at 05:47:03PM -0700, brian moseley wrote:
> On Mon, 30 Apr 2001, Jeffrey W. Baker wrote:
>
> > type of exception. Right now I cannot in fact think of
> > any program I have written that branches on the type of
> > exception. Java encourages this with multiple catch
>
> in CP Web Mail, the underlying libraries throw typed
> exceptions so that the application layer can display the
> correct error notification to the user. for instance, if the
> library throws CP::InvalidMailboxNameException, Web Mail can
> display 'the mailbox name you suggested contains an illegal
> character. it must correspond to the format thus-and-such.
> try again.', whereas if the library throws CP::Exception
> (the generic exception), Web Mail will handle it as a
> service problem and display that godawful WM page.
On a related note, does anyone anywhere still use
Experimental::Exception?
Has anyone compared the performance and features of the various
exception packages? I'd like to move to something that is a bit
better supported than Experimental::Exception, and don't feel like
converting thousands of lines of try {} catch {} to eval {}; if
Thanks.
--
Paul Lindner
[EMAIL PROTECTED]
Re: Exception modules
On Mon, 30 Apr 2001, Jeffrey W. Baker wrote: > type of exception. Right now I cannot in fact think of > any program I have written that branches on the type of > exception. Java encourages this with multiple catch in CP Web Mail, the underlying libraries throw typed exceptions so that the application layer can display the correct error notification to the user. for instance, if the library throws CP::InvalidMailboxNameException, Web Mail can display 'the mailbox name you suggested contains an illegal character. it must correspond to the format thus-and-such. try again.', whereas if the library throws CP::Exception (the generic exception), Web Mail will handle it as a service problem and display that godawful WM page.
Re: forbidden vs. cookie
On Mon, Apr 30, 2001 at 07:54:24PM -0400, Robert Landrum wrote:
> >On Mon, Apr 30, 2001 at 03:46:03PM -0400, Geoffrey Young wrote:
> >> > From: will trillich [mailto:[EMAIL PROTECTED]]
> >> > Sent: Monday, April 30, 2001 3:31 PM
> >> > To: [EMAIL PROTECTED]
> >> > Subject: forbidden vs. cookie
> >> [snip]
> >> > # this don't work so hot, neither:
> >> > $r->header_out(-cookie=>$cookie);
> >> > $r->header_out(-location=>$login_uri);
> >> > return REDIRECT;
> >> > # neither header is sent.
> >>
> >> you probably want $r->err_headers_out instead of $r->headers_out
> >
> >example on p. 125 doesn't -- but since success is zero for me
> >their way, i also tried your method, this way for thoroughness:
> >
> > # called as a "PerlAccessHandler", don't forget--
> > $r->header_out(Cookie=>$cookie);
> > $r->err_header_out(Cookie=>$cookie);
>
> Shouldn't these be
>
> $r->header_out('Set-Cookie'=>$cookie);
> $r->err_header_out('Set-Cookie'=>$cookie);
yep. i caught that right after i posted (as usual).
> > $r->header_out(Location=>$login_uri);
> > $r->err_header_out(Location=>$login_uri);
> > return REDIRECT;
so that part works -- meaning, the Set-Cookie header is sent, and
so is the Location redirector.
linux lynx ignores set-cookie in this case.
mac netscape does too.
g*ddamb*stardfu*kers, is all i'd like to add on that subject, at
the moment. (ask me in a minute, and i'll be glad to repeat it.)
so i'll fall back to
http://stupid-frogging-browser-compatibility-garbage/crapola.html";>
and try that *(&%^(*)($@#*((* method instead.
(are we having fun yet? some of us sure aren't! grr...)
--
don't visit this page. it's bad for you. take my expert word for it.
http://www.salon.com/people/col/pagl/2001/03/21/spring/index1.html
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Re: Exception modules
At 03:24 PM 4/30/01 -0700, Jeffrey W. Baker wrote: >On Mon, 30 Apr 2001, Matt Sergeant wrote: > > > On Mon, 30 Apr 2001, Jeffrey W. Baker wrote: > > > > > Yes precisely. It used to be that you could only die() with a > string, but > > > 5. gave us die() with a reference to an object and at that moment > > > the system was complete. The creation of a rational exception object > type > > > is left to the discretion of the system designer (thankfully). > > > > Well actually I personally would prefer proper exception semantics, but > > unless someone re-writes Error.pm (or whatever) to be implemented using > > Filter, then we're stuck with closures, which I'll avoid thank you. > > > > The things I don't like are: > > > > You currently have to do two blocks, one if ($@), and then > > if($@->isa(...)) inside that. That's too much typing, when Perl is so > > renouned for it's succinctness (is that a word?). > > > > The second thing is no finalize/always clause (you can sort of emulate it, > > but it's not quite guaranteed like it is in languages that implement it > > properly - we discussed this yonks ago on perl-friends, I'll try and dig > > up the discussion if you want). > > > > The whole $@->isa() thing, it's just plain ugly, and doesn't really look > > like exception handling - it looks like botched up OO code. It can/should > > be more structured IMHO. > > > > It's also another case of far too many ways to do it, causing people's > > perl code to look different everywhere, which is bad for maintainence. > >Well, the nice thing about the way Perl does it is that you can have your >way, and boy am I glad I don't have to do it that way, too. > >I have learned that errors from down in the call stack are very rarely >conditionally recoverable. If I call obj->method(), and it throws an >exception, there are few situations where the cause of the exception >matters at all. In most cases I will just not handle the exception, and >it will bubble up. In some cases I might want to log. In others I might >want to retry, or try plan B. But, very rarely do I want to branch on the >type of exception. Right now I cannot in fact think of any program I have >written that branches on the type of exception. Java encourages this with >multiple catch blocks, but I think it is stupid and anyway the catcher >usually is not the primary source of knowledge about what the hell >happened. Think of it: the called program had to make a decision about >what exception to throw, and now the caller is trying to decode that >exception. I believe that decisions should be made at the place in the >program that has the most relevant information about the decision. If you >try to encode information into the exception object, you are encouraging >some other part of the program to make a less-informed opinion. This is why there is a difference between a runtime exception and a regular exception in Java. The regular exception encourages catching the exception and doing something with it as close to the original calling code as possible. >My coding style dictates that a function or method will always do >everything in its power to succeed. If it returns an error code or throws >an exception, that means permanent failure as far as that function is >concerned. In my C code, I usually find that I only need two values for >my return value: FAILURE and SUCCESS. I rarely need anything beyond that. > >The explicit exception declarations in Java piss me off, because they >cause maintenance headaches. Say you have a twenty level call stack. At >depth 0, you catch Exception, at depth 5, you catch FooException. Let's >say that a package API changes and depth 15 now need to throw >BarException. At some level, you now have to explicitly handle >BarException. You either have to do it at depth 14, or you have to change >the declaration of every method up the call stack to the depth that *does* >handle BarException. This is more work than it needs to be. If you really have something that convoluted, then the design of the error handling seems a bit odd. I've never had to deal with a depth of 14 exception handling in my Java code yet. And as you say, the designer of the code should catch the exception close to the source -- the exception in my mind is an aggregate exception collector for logging errors at different levels of the app. But that's discussed below. Generally if it's a caught exception, I try to do something with it right away. If it's something that I intend to log rather than catch so far up the tree, then I can convert it to a runtime exception which can bubble up the trace. I would agree -- I don't know why you would do something with an exception in a place in code that knows less about why the exception occured. Except in a few cases: 1) Of course you catch certain exceptions at the caller level. But if you take your analogy of wanting to catch the exception at the exact time of error, then this would ar
Re: forbidden vs. cookie
>On Mon, Apr 30, 2001 at 03:46:03PM -0400, Geoffrey Young wrote:
>> > From: will trillich [mailto:[EMAIL PROTECTED]]
>> > Sent: Monday, April 30, 2001 3:31 PM
>> > To: [EMAIL PROTECTED]
>> > Subject: forbidden vs. cookie
>> [snip]
>> ># this don't work so hot, neither:
>> >$r->header_out(-cookie=>$cookie);
>> >$r->header_out(-location=>$login_uri);
>> >return REDIRECT;
>> ># neither header is sent.
>>
>> you probably want $r->err_headers_out instead of $r->headers_out
>
>example on p. 125 doesn't -- but since success is zero for me
>their way, i also tried your method, this way for thoroughness:
>
> # called as a "PerlAccessHandler", don't forget--
> $r->header_out(Cookie=>$cookie);
> $r->err_header_out(Cookie=>$cookie);
Shouldn't these be
$r->header_out('Set-Cookie'=>$cookie);
$r->err_header_out('Set-Cookie'=>$cookie);
> $r->header_out(Location=>$login_uri);
> $r->err_header_out(Location=>$login_uri);
> return REDIRECT;
>
>wouldn't you think that would do the trick? i sure did...
>
> Trying ##.##.##.##
> Connected to i-think-this-may-never-work-for-me.com.
> Escape character is '^]'.
> GET /secured HTTP/1.1
>
> HTTP/1.1 302 Found
> Date: Mon, 30 Apr 2001 23:27:46 GMT
> Server: Apache/1.3.9
> Location: http://www.i-think-this-may-never-work-for-me.com/login
> Transfer-Encoding: chunked
> Content-Type: text/html; charset=iso-8859-1
>
>
>
> 302 Found
>
> Found
> The document has moved HREF="http://www.i-think-this-may-never-work-for-me.com/login";>here >.
>
>
>the Location: header made it through, but the set-cookie: header
>got lost in the blast furnace somewhere.
>
>objective: return "set-cookie:" header while redirecting the
>largest number of browsers possible, getting around
>incompatibility problems with various browser implementations on
>varying platforms.
>
>any more rough nudges anybody would care to impinge?
>
>--
>don't visit this page. it's bad for you. take my expert word for it.
>http://www.salon.com/people/col/pagl/2001/03/21/spring/index1.html
>
>[EMAIL PROTECTED]
>http://sourceforge.net/projects/newbiedoc -- we need your brain!
>http://www.dontUthink.com/ -- your brain needs us!
--
As soon as you make something foolproof, someone will create a better fool.
Re: forbidden vs. cookie
On Mon, Apr 30, 2001 at 03:46:03PM -0400, Geoffrey Young wrote: > > From: will trillich [mailto:[EMAIL PROTECTED]] > > Sent: Monday, April 30, 2001 3:31 PM > > To: [EMAIL PROTECTED] > > Subject: forbidden vs. cookie > [snip] > > # this don't work so hot, neither: > > $r->header_out(-cookie=>$cookie); > > $r->header_out(-location=>$login_uri); > > return REDIRECT; > > # neither header is sent. > > you probably want $r->err_headers_out instead of $r->headers_out example on p. 125 doesn't -- but since success is zero for me their way, i also tried your method, this way for thoroughness: # called as a "PerlAccessHandler", don't forget-- $r->header_out(Cookie=>$cookie); $r->err_header_out(Cookie=>$cookie); $r->header_out(Location=>$login_uri); $r->err_header_out(Location=>$login_uri); return REDIRECT; wouldn't you think that would do the trick? i sure did... Trying ##.##.##.## Connected to i-think-this-may-never-work-for-me.com. Escape character is '^]'. GET /secured HTTP/1.1 HTTP/1.1 302 Found Date: Mon, 30 Apr 2001 23:27:46 GMT Server: Apache/1.3.9 Location: http://www.i-think-this-may-never-work-for-me.com/login Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-1 302 Found Found The document has moved http://www.i-think-this-may-never-work-for-me.com/login";>here. the Location: header made it through, but the set-cookie: header got lost in the blast furnace somewhere. objective: return "set-cookie:" header while redirecting the largest number of browsers possible, getting around incompatibility problems with various browser implementations on varying platforms. any more rough nudges anybody would care to impinge? -- don't visit this page. it's bad for you. take my expert word for it. http://www.salon.com/people/col/pagl/2001/03/21/spring/index1.html [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
Re: forbidden vs. cookie
On Mon, Apr 30, 2001 at 03:46:17PM -0400, Ken Y. Clark wrote:
> Here is some code I've used in the past in a mod_perl app to
> set a cookie and do a redirect at the same time. I believe it
> works for most browsers -- or at least this code has been
> working for over a year and I haven't heard too many complaints
> about this piece (that I can think of).
>
> my $cookie = Apache::Cookie->new($apr,
> -name=> 'foo',
> -value => 'bar',
> -expires => '+30m',
> -domain => '.domain.com',
> -path=> '/',
> );
> $cookie->bake;
>
> $apr->method_number(M_GET);
> $apr->method('GET');
> $apr->headers_in->unset('Content-length');
> $apr->headers_out->add('Location' => '/foo');
> $apr->status(REDIRECT);
> $apr->send_http_header;
> return OK;
i presume $apr is as in "sub handler { my $apr = shift; ... " ?
and is this in PerlAuthhandler?
after seeing the 'expires' dilemma brought about by poorly
configured client system clocks, what advice should we follow?
(what's the Official Party Line on expiring cookies?)
--
[EMAIL PROTECTED]
Re: Exception modules
On Mon, 30 Apr 2001, Jeffrey W. Baker wrote: > I have learned that errors from down in the call stack are very rarely > conditionally recoverable. If I call obj->method(), and it throws an > exception, there are few situations where the cause of the exception > matters at all. In most cases I will just not handle the exception, and > it will bubble up. In some cases I might want to log. In others I might > want to retry, or try plan B. But, very rarely do I want to branch on the > type of exception. Right now I cannot in fact think of any program I have > written that branches on the type of exception. Java encourages this with > multiple catch blocks, but I think it is stupid and anyway the catcher > usually is not the primary source of knowledge about what the hell > happened. Think of it: the called program had to make a decision about > what exception to throw, and now the caller is trying to decode that > exception. I believe that decisions should be made at the place in the > program that has the most relevant information about the decision. If you > try to encode information into the exception object, you are encouraging > some other part of the program to make a less-informed opinion. [snip] Right, this is standard exceptions stuff. You should never catch exceptions anywhere but your main() (or in mod_perl's case, handler()) routine, unless you have to, and when you have to be *very* careful about what you're doing, and why you're doing it. I'll try and cover this in my talk. -- /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
RE: Exception modules
Title: RE: Exception modules
unsubscribe please- thanks
-Original Message-
From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 30, 2001 4:29 PM
To: Jeffrey W. Baker
Cc: [EMAIL PROTECTED]
Subject: Re: Exception modules
On Mon, 30 Apr 2001, Jeffrey W. Baker wrote:
>
>
> On Mon, 30 Apr 2001, Matt Sergeant wrote:
>
> >
> > > [1] for my Perl exception package (yes, another one :) which, in its
> > > development version, now mostly does the Right Thing for mod_perl. See
> > > http://sourceforge.net/projects/perlexception/ for the curious.
> >
> > Since I'm doing the mod_perl exception handling talk at TPC, I feel
> > obligated to ask about this...
> >
> > It doesn't seem any different from Error.pm to me, except in syntax. Maybe
> > you could expand on why/where it is different?
>
> I tried using some different exception packages in the past. What I
> realized is, die() and eval {} ARE Perl's exception handling mechanism.
> die() and eval {}, together, have complete exception throwing and handling
> functionality. As a bonus, they lack Java's exception bondage and
> discipline.
>
> So, what's wrong with die() and eval {}?
Nothing, IMHO. In fact I've now switched away from using Error.pm's
try/catch syntax, because it creates closures and it's really easy to
generate memory leaks that way with mod_perl. But I still use Error.pm's
exception object structure...
Without some sort of structured exception handling, you don't know exactly
what type of exception was thrown. For example, in AxKit I need to know in
certain places if an IO exception occured, or if it was some other kind of
exception. I could do this with regexps, but then I'm relying on people
using the right strings in their error messages. Plus exception objects
can give you a stack trace, which eval catching a string can't (well, it
kinda can in a few ways, but not in quite as clean a manner).
Try it though, you might be surprised you like it. (unless by die() and
eval{} you mean you're already using exception objects, in which case I'm
preaching to the choir ;-)
--
/|| ** Founder and CTO ** ** http://axkit.com/ **
//|| ** AxKit.com Ltd ** ** XML Application Serving **
// || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** mod_perl news and resources: http://take23.org **
\\//
//\\
// \\
Re: Exception modules
On Mon, 30 Apr 2001, Matt Sergeant wrote: > On Mon, 30 Apr 2001, Jeffrey W. Baker wrote: > > > Yes precisely. It used to be that you could only die() with a string, but > > 5. gave us die() with a reference to an object and at that moment > > the system was complete. The creation of a rational exception object type > > is left to the discretion of the system designer (thankfully). > > Well actually I personally would prefer proper exception semantics, but > unless someone re-writes Error.pm (or whatever) to be implemented using > Filter, then we're stuck with closures, which I'll avoid thank you. > > The things I don't like are: > > You currently have to do two blocks, one if ($@), and then > if($@->isa(...)) inside that. That's too much typing, when Perl is so > renouned for it's succinctness (is that a word?). > > The second thing is no finalize/always clause (you can sort of emulate it, > but it's not quite guaranteed like it is in languages that implement it > properly - we discussed this yonks ago on perl-friends, I'll try and dig > up the discussion if you want). > > The whole $@->isa() thing, it's just plain ugly, and doesn't really look > like exception handling - it looks like botched up OO code. It can/should > be more structured IMHO. > > It's also another case of far too many ways to do it, causing people's > perl code to look different everywhere, which is bad for maintainence. Well, the nice thing about the way Perl does it is that you can have your way, and boy am I glad I don't have to do it that way, too. I have learned that errors from down in the call stack are very rarely conditionally recoverable. If I call obj->method(), and it throws an exception, there are few situations where the cause of the exception matters at all. In most cases I will just not handle the exception, and it will bubble up. In some cases I might want to log. In others I might want to retry, or try plan B. But, very rarely do I want to branch on the type of exception. Right now I cannot in fact think of any program I have written that branches on the type of exception. Java encourages this with multiple catch blocks, but I think it is stupid and anyway the catcher usually is not the primary source of knowledge about what the hell happened. Think of it: the called program had to make a decision about what exception to throw, and now the caller is trying to decode that exception. I believe that decisions should be made at the place in the program that has the most relevant information about the decision. If you try to encode information into the exception object, you are encouraging some other part of the program to make a less-informed opinion. My coding style dictates that a function or method will always do everything in its power to succeed. If it returns an error code or throws an exception, that means permanent failure as far as that function is concerned. In my C code, I usually find that I only need two values for my return value: FAILURE and SUCCESS. I rarely need anything beyond that. The explicit exception declarations in Java piss me off, because they cause maintenance headaches. Say you have a twenty level call stack. At depth 0, you catch Exception, at depth 5, you catch FooException. Let's say that a package API changes and depth 15 now need to throw BarException. At some level, you now have to explicitly handle BarException. You either have to do it at depth 14, or you have to change the declaration of every method up the call stack to the depth that *does* handle BarException. This is more work than it needs to be. Regards, jwb
Re: Exception modules
Matt Sergeant <[EMAIL PROTECTED]> wrote:
> It doesn't seem any different from Error.pm to me, except in syntax.
> Maybe you could expand on why/where it is different?
OK, yes, it *is* very similar in principle - I would perhaps have been
better to have added to Graham's code, but I suffer from False Hubris :)
My code coexists better with CGI and, in particular, mod_perl
(Apache::Registry and Apache::PerlRun) - adding code for HTML output is
trivial, and I at least attempt to cope with exceptions raised within
exception handlers and "finally" blocks, but apart from that there are
minor advantages either way: I prefer my syntax (but then I would :) and
allow matching of exceptions by regexp against error text and exception
name as well as class; Error.pm allows try {} to return lists as well as
scalars (something I may add), has an "otherwise" clause for which I can
see no particular use at all and I haven't (yet) subclassed Exception.pm
to provide the sort of functionality Error::IO provides.
The implementations are, of course, significantly different internally;
which is better I leave up to the reader - I do trap $SIG{__DIE__} which
many would regard as a hanging offence (but then so does Apache::Debug).
/Pete/
Re: Exception modules
On Mon, 30 Apr 2001, Jeffrey W. Baker wrote: > Yes precisely. It used to be that you could only die() with a string, but > 5. gave us die() with a reference to an object and at that moment > the system was complete. The creation of a rational exception object type > is left to the discretion of the system designer (thankfully). Well actually I personally would prefer proper exception semantics, but unless someone re-writes Error.pm (or whatever) to be implemented using Filter, then we're stuck with closures, which I'll avoid thank you. The things I don't like are: You currently have to do two blocks, one if ($@), and then if($@->isa(...)) inside that. That's too much typing, when Perl is so renouned for it's succinctness (is that a word?). The second thing is no finalize/always clause (you can sort of emulate it, but it's not quite guaranteed like it is in languages that implement it properly - we discussed this yonks ago on perl-friends, I'll try and dig up the discussion if you want). The whole $@->isa() thing, it's just plain ugly, and doesn't really look like exception handling - it looks like botched up OO code. It can/should be more structured IMHO. It's also another case of far too many ways to do it, causing people's perl code to look different everywhere, which is bad for maintainence. -- /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
Re: Installation issue
Hmm.. i just got it to build ok on RH 7.0.. I'll see if I can just use those binaries... oh.. i did forget to mention the 6.1 box was an SMP kernel. Not sure if that could be an issue, but thought it could be important /a alan arbizu wrote: > > Hi folks... > > I've got an issue here that all the rtfm'ing on my part has not > been able to resolve :/ > > Here's the setup > > RH 6.1 > Apache 1.3.19 > mod_ssl 2.8.1 > mod_perl 1.25 > php 4.0.4pl1 > > building all from source > > So... > > I first configured mod_ssl by pointing it at the apache source... > Then I configured mod_perl similarly and had it build apache for me. > After apache was built/installed, I compiled/installed php4 > independently. > > Now... the only way i've been able to start apache is to uncomment > the Load Module/Add Module directives for mod_perl in the > httpd.conf file. PHP and SSL seem to coexist fine. But if I try > to enable mod_perl the httpd process exits without spawning the > specified number of apache processes. > > I tried to debug it, but gdb shows pretty much the same thing: > > $gdb httpd > GNU gdb 4.18 > Copyright 1998 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and > you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "i386-redhat-linux"... > (gdb) break main > Breakpoint 1 at 0x8061312 > (gdb) run > Starting program: /usr/sbin/httpd > > Breakpoint 1, 0x8061312 in main () > (gdb) n > Single stepping until exit from function main, > which has no line number information. > > Program exited normally. > (gdb) > > Any ideas? > > no core file, no nothing :( > > thanks in advance for any ideas/tips > > /a > > -- > Alan E. Arbizu / http://www.arbizu.org > SW Design Engineer, CSO-eCSL > Hewlett-Packard > Cupertino, CA, 47L/J6-L6 > TN-447-0240 -- Alan E. Arbizu / http://www.arbizu.org SW Design Engineer, CSO-eCSL Hewlett-Packard Cupertino, CA, 47L/J6-L6 TN-447-0240
Re: Exception modules
On Mon, 30 Apr 2001, Matt Sergeant wrote:
> On Mon, 30 Apr 2001, Jeffrey W. Baker wrote:
>
> >
> >
> > On Mon, 30 Apr 2001, Matt Sergeant wrote:
> >
> > >
> > > > [1] for my Perl exception package (yes, another one :) which, in its
> > > > development version, now mostly does the Right Thing for mod_perl. See
> > > > http://sourceforge.net/projects/perlexception/ for the curious.
> > >
> > > Since I'm doing the mod_perl exception handling talk at TPC, I feel
> > > obligated to ask about this...
> > >
> > > It doesn't seem any different from Error.pm to me, except in syntax. Maybe
> > > you could expand on why/where it is different?
> >
> > I tried using some different exception packages in the past. What I
> > realized is, die() and eval {} ARE Perl's exception handling mechanism.
> > die() and eval {}, together, have complete exception throwing and handling
> > functionality. As a bonus, they lack Java's exception bondage and
> > discipline.
> >
> > So, what's wrong with die() and eval {}?
>
> Nothing, IMHO. In fact I've now switched away from using Error.pm's
> try/catch syntax, because it creates closures and it's really easy to
> generate memory leaks that way with mod_perl. But I still use Error.pm's
> exception object structure...
>
> Without some sort of structured exception handling, you don't know exactly
> what type of exception was thrown. For example, in AxKit I need to know in
> certain places if an IO exception occured, or if it was some other kind of
> exception. I could do this with regexps, but then I'm relying on people
> using the right strings in their error messages. Plus exception objects
> can give you a stack trace, which eval catching a string can't (well, it
> kinda can in a few ways, but not in quite as clean a manner).
>
> Try it though, you might be surprised you like it. (unless by die() and
> eval{} you mean you're already using exception objects, in which case I'm
> preaching to the choir ;-)
Yes precisely. It used to be that you could only die() with a string, but
5. gave us die() with a reference to an object and at that moment
the system was complete. The creation of a rational exception object type
is left to the discretion of the system designer (thankfully).
-jwb
Installation issue
Hi folks... I've got an issue here that all the rtfm'ing on my part has not been able to resolve :/ Here's the setup RH 6.1 Apache 1.3.19 mod_ssl 2.8.1 mod_perl 1.25 php 4.0.4pl1 building all from source So... I first configured mod_ssl by pointing it at the apache source... Then I configured mod_perl similarly and had it build apache for me. After apache was built/installed, I compiled/installed php4 independently. Now... the only way i've been able to start apache is to uncomment the Load Module/Add Module directives for mod_perl in the httpd.conf file. PHP and SSL seem to coexist fine. But if I try to enable mod_perl the httpd process exits without spawning the specified number of apache processes. I tried to debug it, but gdb shows pretty much the same thing: $gdb httpd GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) break main Breakpoint 1 at 0x8061312 (gdb) run Starting program: /usr/sbin/httpd Breakpoint 1, 0x8061312 in main () (gdb) n Single stepping until exit from function main, which has no line number information. Program exited normally. (gdb) Any ideas? no core file, no nothing :( thanks in advance for any ideas/tips /a -- Alan E. Arbizu / http://www.arbizu.org SW Design Engineer, CSO-eCSL Hewlett-Packard Cupertino, CA, 47L/J6-L6 TN-447-0240
Re: Exception modules
On Mon, 30 Apr 2001, Jeffrey W. Baker wrote:
>
>
> On Mon, 30 Apr 2001, Matt Sergeant wrote:
>
> >
> > > [1] for my Perl exception package (yes, another one :) which, in its
> > > development version, now mostly does the Right Thing for mod_perl. See
> > > http://sourceforge.net/projects/perlexception/ for the curious.
> >
> > Since I'm doing the mod_perl exception handling talk at TPC, I feel
> > obligated to ask about this...
> >
> > It doesn't seem any different from Error.pm to me, except in syntax. Maybe
> > you could expand on why/where it is different?
>
> I tried using some different exception packages in the past. What I
> realized is, die() and eval {} ARE Perl's exception handling mechanism.
> die() and eval {}, together, have complete exception throwing and handling
> functionality. As a bonus, they lack Java's exception bondage and
> discipline.
>
> So, what's wrong with die() and eval {}?
Nothing, IMHO. In fact I've now switched away from using Error.pm's
try/catch syntax, because it creates closures and it's really easy to
generate memory leaks that way with mod_perl. But I still use Error.pm's
exception object structure...
Without some sort of structured exception handling, you don't know exactly
what type of exception was thrown. For example, in AxKit I need to know in
certain places if an IO exception occured, or if it was some other kind of
exception. I could do this with regexps, but then I'm relying on people
using the right strings in their error messages. Plus exception objects
can give you a stack trace, which eval catching a string can't (well, it
kinda can in a few ways, but not in quite as clean a manner).
Try it though, you might be surprised you like it. (unless by die() and
eval{} you mean you're already using exception objects, in which case I'm
preaching to the choir ;-)
--
/||** Founder and CTO ** ** http://axkit.com/ **
//||** AxKit.com Ltd ** ** XML Application Serving **
// ||** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** mod_perl news and resources: http://take23.org **
\\//
//\\
// \\
Re: Exception modules
On Mon, 30 Apr 2001, Matt Sergeant wrote:
>
> > [1] for my Perl exception package (yes, another one :) which, in its
> > development version, now mostly does the Right Thing for mod_perl. See
> > http://sourceforge.net/projects/perlexception/ for the curious.
>
> Since I'm doing the mod_perl exception handling talk at TPC, I feel
> obligated to ask about this...
>
> It doesn't seem any different from Error.pm to me, except in syntax. Maybe
> you could expand on why/where it is different?
I tried using some different exception packages in the past. What I
realized is, die() and eval {} ARE Perl's exception handling mechanism.
die() and eval {}, together, have complete exception throwing and handling
functionality. As a bonus, they lack Java's exception bondage and
discipline.
So, what's wrong with die() and eval {}?
-jwb
Exception modules
> [1] for my Perl exception package (yes, another one :) which, in its > development version, now mostly does the Right Thing for mod_perl. See > http://sourceforge.net/projects/perlexception/ for the curious. Since I'm doing the mod_perl exception handling talk at TPC, I feel obligated to ask about this... It doesn't seem any different from Error.pm to me, except in syntax. Maybe you could expand on why/where it is different? -- /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
Apache::Registry - a thought
I've been off this list for over a year, so I may be covering ground that
I've failed to find in the archives, but whatever...
I've had occasion to examine the internals of Apache::Registry recently[1]
and have been reminded of the unfeasably long package names that it
generates for scripts.
It occurs to me that there would be no overhead to speak of in using a
sequence number, given that Apache::Registry already maintains a hash for
its generated package names for mtime checks. Something like:
my $script=
$Apache::Registry->{$script_name}||=
{seq => ++$Apache::Registry::seq, mtime => $mtime+1};
my $package=sprintf "Apache::MAIN::S%04d", $script->{seq};
$r->log_error("Apache::Registry::handler package $package")
if $Debug && $Debug & 4;
$r->chdir_file;
unless ($script->{mtime} <= $mtime) {
$script->{mtime}=$mtime;
$package=sprintf "Apache::MAIN::S%04d", $script->{seq};
# compile into $package
}
my $old_status = $r->status;
my $cv = \&{"$package\::handler"};
eval { &{$cv}($r, @_) } if $r->seqno;
# and so on...
Seems a lot clearer to me than what we now have (particularly if a script
directory is way down the directory hierarchy), gets round the need for
name mangling, and the real script name is still there in the file field
of stack frames for diagnostic purposes.
Pete Jordan
[1] for my Perl exception package (yes, another one :) which, in its
development version, now mostly does the Right Thing for mod_perl. See
http://sourceforge.net/projects/perlexception/ for the curious.
Re: Help -- Internal Server Error after mod_perl and new apache insta ll on HP-UX 10.20.
Hi there, On Sat, 28 Apr 2001, MCALLISTER,RONAN (HP-FtCollins,ex1) wrote: > HP-UX 10.20 > and compiling from source. Did you compile your Perl? > my httpd.conf Where? Have you looked in the archives for HP-UX? I believe there have been successes in the recent past, and it may have been a bit fiddly. 73, Ged.
Re: forbidden vs. cookie
Here's another option which may not be exactly what you're looking for, but
it will work: Once you've performed all validation and are ready to
redirect them with the cookie, rather than attempting the redirect with http
headers, just output a simple "processing" page with the redirect url in an
http-equiv meta tag. The cookie will get set on the processing page and
then the browser will request the redirect itself.
Thanks,
Tim Tompkins
--
Staff Engineer / Programmer
http://www.arttoday.com/
--
- Original Message -
From: "will trillich" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, April 30, 2001 12:31 PM
Subject: forbidden vs. cookie
> i could really use some dumbed-down tips on setting cookies
> during a redirect. boy, this is really getting to me.
>
> using apache 1.3.9 on debian 2.2/potato
>
> in trying to implement the concept of the Apache::Ticket*.pm
> modules from the Apache Modules (eagle) book in chapter 6
> (on pages 304+) i'm running into browser compatibility problems.
> SOME browsers (differs among platforms, too) see the forbidden or
> redirect codes and take action immediately, ignoring any
> set-cookie headers that are also sent.
>
> as a workaround, i was trying to change TicketAccess.pm to
>
> # the munged version trying to accomodate rude browsers:
> package Apache::TicketAccess;
>
> use strict;
> use Apache::Constants qw(OK FORBIDDEN REDIRECT);
> use Apache::TicketTool ();
>
> sub handler {
> my $r = shift;
> my $ticketTool = Apache::TicketTool->new($r);
> my($result, $msg) = $ticketTool->verify_ticket($r);
> unless ($result) {
> $r->log_reason($msg, $r->filename);
> my $cookie = $ticketTool->make_return_address($r);
>
> #the original code that works for SOME browsers:
> # $r->err_headers_out->add('Set-Cookie' => $cookie);
> # return FORBIDDEN;
>
> my $login_uri = $r->dir_config("TicketLogin");
>
> # as AccessHandler, this was very much a bad idea:
> # use CGI '-autoload';
> # print
> # header(-refresh => "1; URL=$login_uri", -cookie => $cookie),
> # start_html(-title => 'Redirecting to login', -bgcolor => 'white'),
> # h1('Gotta log in, first'),
> # p("You're being redirected to ",
> # a({-href=>$login_uri},$login_uri),
> # " in just a moment."),
> # h2("Please stand by..."),
> # end_html();
> # return OK;
> # it does manage to redirect the browser but there's lots
> # of duplicated headers and garbage (plus just hitting the
> # BACK button bypassed the need to log in)
>
> # this don't work so not, neither:
> $r->header_out(-cookie=>$cookie);
> $r->header_out(-location=>$login_uri);
> return REDIRECT;
> # neither header is sent.
>
> }
> return OK;
> }
>
> 1;
> __END__
>
> i've spent hours flipping back and from from the index to the
> text, slapping postit notes on every other page, scanning
> Apache::*.pm source code -- and it's still not sinking in... a
> little help would be appreciated!
>
> AAUGH!
>
> --
> [EMAIL PROTECTED]
>
Re: forbidden vs. cookie
On Mon, 30 Apr 2001, will trillich wrote:
> Date: Mon, 30 Apr 2001 14:31:02 -0500
> From: will trillich <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: forbidden vs. cookie
>
> i could really use some dumbed-down tips on setting cookies
> during a redirect. boy, this is really getting to me.
>
> using apache 1.3.9 on debian 2.2/potato
>
> in trying to implement the concept of the Apache::Ticket*.pm
> modules from the Apache Modules (eagle) book in chapter 6
> (on pages 304+) i'm running into browser compatibility problems.
> SOME browsers (differs among platforms, too) see the forbidden or
> redirect codes and take action immediately, ignoring any
> set-cookie headers that are also sent.
>
> as a workaround, i was trying to change TicketAccess.pm to
>
> # the munged version trying to accomodate rude browsers:
> package Apache::TicketAccess;
>
> use strict;
> use Apache::Constants qw(OK FORBIDDEN REDIRECT);
> use Apache::TicketTool ();
>
> sub handler {
> my $r = shift;
> my $ticketTool = Apache::TicketTool->new($r);
> my($result, $msg) = $ticketTool->verify_ticket($r);
> unless ($result) {
> $r->log_reason($msg, $r->filename);
> my $cookie = $ticketTool->make_return_address($r);
>
> #the original code that works for SOME browsers:
> # $r->err_headers_out->add('Set-Cookie' => $cookie);
> # return FORBIDDEN;
>
> my $login_uri = $r->dir_config("TicketLogin");
>
> # as AccessHandler, this was very much a bad idea:
> # use CGI '-autoload';
> # print
> # header(-refresh => "1; URL=$login_uri", -cookie =>
>$cookie),
> # start_html(-title => 'Redirecting to login', -bgcolor
>=> 'white'),
> # h1('Gotta log in, first'),
> # p("You're being redirected to ",
> # a({-href=>$login_uri},$login_uri),
> # " in just a moment."),
> # h2("Please stand by..."),
> # end_html();
> # return OK;
> # it does manage to redirect the browser but there's lots
> # of duplicated headers and garbage (plus just hitting the
> # BACK button bypassed the need to log in)
>
> # this don't work so not, neither:
> $r->header_out(-cookie=>$cookie);
> $r->header_out(-location=>$login_uri);
> return REDIRECT;
> # neither header is sent.
>
> }
> return OK;
> }
>
> 1;
> __END__
>
> i've spent hours flipping back and from from the index to the
> text, slapping postit notes on every other page, scanning
> Apache::*.pm source code -- and it's still not sinking in... a
> little help would be appreciated!
>
> AAUGH!
Will,
Here is some code I've used in the past in a mod_perl app to set a
cookie and do a redirect at the same time. I believe it works for
most browsers -- or at least this code has been working for over a
year and I haven't heard too many complaints about this piece (that I
can think of).
my $cookie = Apache::Cookie->new($apr,
-name=> 'foo',
-value => 'bar',
-expires => '+30m',
-domain => '.domain.com',
-path=> '/',
);
$cookie->bake;
$apr->method_number(M_GET);
$apr->method('GET');
$apr->headers_in->unset('Content-length');
$apr->headers_out->add('Location' => '/foo');
$apr->status(REDIRECT);
$apr->send_http_header;
return OK;
HTH,
ky
Re: forbidden vs. cookie
>i could really use some dumbed-down tips on setting cookies >during a redirect. boy, this is really getting to me. > >using apache 1.3.9 on debian 2.2/potato > >in trying to implement the concept of the Apache::Ticket*.pm >modules from the Apache Modules (eagle) book in chapter 6 >(on pages 304+) i'm running into browser compatibility problems. >SOME browsers (differs among platforms, too) see the forbidden or >redirect codes and take action immediately, ignoring any >set-cookie headers that are also sent. > [snip] I stopped sending Set-Cookie headers... It became too confusing. I found that Javascript worked 99% of the time on every browser and operating system with the exception of Lynx... But if you're using cookies anyway, you probably developing for the more common NS and IE users. Good luck, Rob -- As soon as you make something foolproof, someone will create a better fool.
RE: forbidden vs. cookie
> -Original Message- > From: will trillich [mailto:[EMAIL PROTECTED]] > Sent: Monday, April 30, 2001 3:31 PM > To: [EMAIL PROTECTED] > Subject: forbidden vs. cookie > [snip] > > # this don't work so not, neither: > $r->header_out(-cookie=>$cookie); > $r->header_out(-location=>$login_uri); > return REDIRECT; > # neither header is sent. you probably want $r->err_headers_out instead of $r->headers_out HTH --Geoff
forbidden vs. cookie
i could really use some dumbed-down tips on setting cookies
during a redirect. boy, this is really getting to me.
using apache 1.3.9 on debian 2.2/potato
in trying to implement the concept of the Apache::Ticket*.pm
modules from the Apache Modules (eagle) book in chapter 6
(on pages 304+) i'm running into browser compatibility problems.
SOME browsers (differs among platforms, too) see the forbidden or
redirect codes and take action immediately, ignoring any
set-cookie headers that are also sent.
as a workaround, i was trying to change TicketAccess.pm to
# the munged version trying to accomodate rude browsers:
package Apache::TicketAccess;
use strict;
use Apache::Constants qw(OK FORBIDDEN REDIRECT);
use Apache::TicketTool ();
sub handler {
my $r = shift;
my $ticketTool = Apache::TicketTool->new($r);
my($result, $msg) = $ticketTool->verify_ticket($r);
unless ($result) {
$r->log_reason($msg, $r->filename);
my $cookie = $ticketTool->make_return_address($r);
#the original code that works for SOME browsers:
# $r->err_headers_out->add('Set-Cookie' => $cookie);
# return FORBIDDEN;
my $login_uri = $r->dir_config("TicketLogin");
# as AccessHandler, this was very much a bad idea:
# use CGI '-autoload';
# print
# header(-refresh => "1; URL=$login_uri", -cookie =>
$cookie),
# start_html(-title => 'Redirecting to login', -bgcolor
=> 'white'),
# h1('Gotta log in, first'),
# p("You're being redirected to ",
# a({-href=>$login_uri},$login_uri),
# " in just a moment."),
# h2("Please stand by..."),
# end_html();
# return OK;
# it does manage to redirect the browser but there's lots
# of duplicated headers and garbage (plus just hitting the
# BACK button bypassed the need to log in)
# this don't work so not, neither:
$r->header_out(-cookie=>$cookie);
$r->header_out(-location=>$login_uri);
return REDIRECT;
# neither header is sent.
}
return OK;
}
1;
__END__
i've spent hours flipping back and from from the index to the
text, slapping postit notes on every other page, scanning
Apache::*.pm source code -- and it's still not sinking in... a
little help would be appreciated!
AAUGH!
--
[EMAIL PROTECTED]
Re: CORE::format() and CORE::write() under 5.6.x
On Mon, 30 Apr 2001, Ken Williams wrote: > [EMAIL PROTECTED] (Stas Bekman) wrote: > >On Mon, 30 Apr 2001, Matt Sergeant wrote: > >> On Mon, 30 Apr 2001, Stas Bekman wrote: > >> > cool, but this section in the guide was stating the CORE::format() doesn't > >> > work. And it's still doesn't under mod_perl. So doesn't CORE::write(). > >> > >> Right, but it would be nice to point to an alternative. The module is > >> called Text::Reform, by the way. > > > >True. Thanks. > > > >Does it have any problems with working under mod_perl? looks like a pure > >perl to me. > > > Damian claims to only ever write code in pure Perl. I was told by quite a few people that this is because of Damian academic background. With all the respect to Damian, it seems that the functionality has a higher preference than performance at his code. I've to admit though that the functionality is great :) One of the people I had a bad luck to be in touch with, wrote an app using Parse::RecDescent as a grammar parser. It was taking *only* a few minutes to parse a big file. Which was quite innacceptible for the web app. I'm imagine that if some of memory mangling parts of Parse::RecDescent were rewritten in XS/C, it'll run much faster. But that might be not true. Anyway, I don't see any reason why won't it work under mod_perl. It doesn't have BEGIN/END blocks (e.g. FindBin doesn't work under mod_perl for because it relies on BEGIN block to be recompiled on each request), not tie, no globals (other than the standard ones). _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: an unusual [job request] + taking mod_perl to the commercial world
> Often quite a number of developers are all > at work, and they don't all merit the kind of trust that mod_perl > requires. See Phillippe Chiasson's talk @ ApacheCon. Lots of developers checking out release controlled Apache, perl, and application. Neat stuff. John [EMAIL PROTECTED]
Re: CORE::format() and CORE::write() under 5.6.x
[EMAIL PROTECTED] (Stas Bekman) wrote: >On Mon, 30 Apr 2001, Matt Sergeant wrote: >> On Mon, 30 Apr 2001, Stas Bekman wrote: >> > cool, but this section in the guide was stating the CORE::format() doesn't >> > work. And it's still doesn't under mod_perl. So doesn't CORE::write(). >> >> Right, but it would be nice to point to an alternative. The module is >> called Text::Reform, by the way. > >True. Thanks. > >Does it have any problems with working under mod_perl? looks like a pure >perl to me. Damian claims to only ever write code in pure Perl. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: CORE::format() and CORE::write() under 5.6.x
On Tue, 1 May 2001, Stas Bekman wrote: > On Mon, 30 Apr 2001, Matt Sergeant wrote: > > > On Mon, 30 Apr 2001, Stas Bekman wrote: > > > > > cool, but this section in the guide was stating the CORE::format() doesn't > > > work. And it's still doesn't under mod_perl. So doesn't CORE::write(). > > > > Right, but it would be nice to point to an alternative. The module is > > called Text::Reform, by the way. > > True. Thanks. > > Does it have any problems with working under mod_perl? looks like a pure > perl to me. I doubt it has problems because it's not magical (well, it's only magical in the Damian Conway sense, not in the Larry Wall sense :-) But I haven't tried it either, so don't take my word for it :-) -- /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
Re: CORE::format() and CORE::write() under 5.6.x
On Mon, 30 Apr 2001, Matt Sergeant wrote: > On Mon, 30 Apr 2001, Stas Bekman wrote: > > > cool, but this section in the guide was stating the CORE::format() doesn't > > work. And it's still doesn't under mod_perl. So doesn't CORE::write(). > > Right, but it would be nice to point to an alternative. The module is > called Text::Reform, by the way. True. Thanks. Does it have any problems with working under mod_perl? looks like a pure perl to me. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: an unusual [job request] + taking mod_perl to the commercial world
On Sun, 29 Apr 2001 13:52:05 +0800 Gunther Birznieks <[EMAIL PROTECTED]> wrote: I completely agree with the assertion that applications sell the underlying technology. History teaches us that to be indisputable. Also while applications should be an overall part of the vision, it may not have to be there right from the start. I have been peeking in at Enhydra from time to time and I remeber in the beginning all they had was the framework consisting of the multi-server, xmlc and perhaps DODS. Now i see they have complete apps like Brock, jFAQ, and the fairly complete golf store application all of which could be, as YABW (yet another buzz word) says, "repurposed". Same is true of Zope where apps are emerging only now. The tutorial is a terrific example of a zope app. Perhaps the roadmaps followed by these two opensource camps will have great lessons for mod_perl. As the technology catches on the core-developers could form a company for support, training etc as shown by Lutris for Enhydra and Digital Creations for Zope. That seems like the validation corporations look for. moral: lay a great foundation and they will build :) -bakki > I would like to restate that while I think these engines are cool and > useful, that they are not the things that bring the masses to your > platform. This was the point I was making. I am not naysaying projects > like Enhydra, but just stated that they are not as directly useful for > bringing the masses to the platform. > > While it is true that an "Enhydra" type of engine makes writing > application > easier, what you really still always need in order to gain a critical > mass > is something more concrete that the masses can hook onto. > > I am not talking about techies loving mod_perl or Enhydra or AxKit. But > everyday webmasters and CIOs saying "XYZ platform has so many > applications > for it I can see them demoed, my tech staff can install them within > a > day" so let's use it. > > There are just certain things that are harder to market than others. > Applications make platforms easier to market because it shows off the > power. > > I was not at the meeting, but I heard Stas convinced one of our clients > to > go with mod_perl by showing them a site he created called SinglesHeaven > in > CGI and then in mod_perl. "Look how fast it is and you can see it's a > real > application". Showing the same people benchmarks of hello world and > template renderings generally do not have the same effect. > -- .-.| Bakki Kudva__Open Source EDMS__ oo|| Navaco ph: 814-833-2592 /`'\| 420 Pasadena Drive fax: 603-947-5747 (\_;/) | Erie, PA 16505 http://www.navaco.com/
[DIGEST] mod_perl digest 04/28/01
--
mod_perl digest
April 22, 2001 - April 28, 2001
--
Recent happenings in the mod_perl world...
Features
o mod_perl status
o cvs patches
o module announcements
o mailing list highlights
o links
mod_perl status
o mod_perl
- stable: 1.25 (released January 29, 2001) [1]
- development: 1.25_01-dev [2]
o Apache
- stable: 1.3.19 (released February 28, 2001) [3]
- development: 1.3.20-dev [4]
o Perl
- stable: 5.6.1 (released April 9, 2001) [5]
- development: 5.7.1 [6]
cvs patches
o fix double-loading bug of Perl{Require,Module}s at startup time [7]
o adding PERL_SSI PERL_SECTIONS to MyConfig generator [8]
o some win32 fixes [9]
o 39 patches to 2.0 this week [10]
module announcements
o Cache::Cache 0.08 - successor to File::Cache and IPC::Cache [11]
o A new version of the mod_perl Guide was released this week -
read it and prosper [12]
mailing list highlights
o There was some discussion on the dev list about whether the new
2.0 perl interpreter model will make it unnecessary to have
separate light and heavy mod_perl servers [13]
o If you have had problem using redir() under mod_perl, here are a
few suggestions [14]
o Some tips on getting cookies to work with redirects [15]
o A patch was submitted to add an Apache->dso_module method. While
it remains unintegrated, the part of the reason for needing it was
to avoid double loading of modules, which was addressed in a patch
by Doug [16] [17]
o Long thread of the week goes to discussion of corporate
sponsorship of mod_perl core development, among other things [18]
links
o The Apache/Perl Integration Project [19]
o mod_perl documentation [20]
o mod_perl modules on CPAN [21]
o mod_perl homepage [22]
o mod_perl news and advocacy [23]
o mod_perl list archives [24] [25]
happy mod_perling...
--Geoff
[EMAIL PROTECTED]
--
[1] http://perl.apache.org/dist/
[2] http://perl.apache.org/from-cvs/modperl/
[3] http://www.apache.org/dist/
[4] http://dev.apache.org/from-cvs/apache-1.3/
[5] http://www.cpan.org/src/stable.tar.gz
[6] http://www.cpan.org/src/devel.tar.gz
[7] http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=98826305918853&w=2
[8] http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=98817232005321&w=2
[9] http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=98839151427941&w=2
[10] http://marc.theaimsgroup.com/?l=apache-modperl-cvs&r=1&w=2&b=200104
[11] http://forum.swarthmore.edu/epigone/modperl/zhulphofran
[12] http://forum.swarthmore.edu/epigone/modperl/gaxsoxblul
[13] http://marc.theaimsgroup.com/?t=9880794232&w=2&r=1
[14] http://forum.swarthmore.edu/epigone/modperl/dephayclang
[15] http://forum.swarthmore.edu/epigone/modperl/prolrumwhu
[16] http://forum.swarthmore.edu/epigone/modperl/phuncherdcrimp
[17] http://forum.swarthmore.edu/epigone/modperl/lelswyskix
[18] http://marc.theaimsgroup.com/?t=9883870024&w=2&r=1
[19] http://perl.apache.org
[20] http://perl.apache.org/#docs
[21] http://www.cpan.org/modules/by-module/Apache/
[22] http://www.modperl.com
[23] http://www.take23.org
[24] http://forum.swarthmore.edu/epigone/modperl/
[25] http://marc.theaimsgroup.com/?l=apache-modperl&r=1&w=2
mod_perl/IPC feedback needed
Folks, I'm looking for some feedback regarding what IPC techniques are being used in conjunction with mod_perl. I know about IPC::Shareable, IPC::ShareLite. What other IPC modules/techniques are you using? Or not using because they don't work/aren't stable/whatever. I'm interested in any experience with IPC, good or bad. Please reply privately. If there is interest I'll post a digest of the replies. Thanks, -- Eric Cholet
Re: IPC:Open3 does not work under mod_perl/1.25, perl5.6.0?
Thanks! This works for me, I don't have Apache::Filter loaded, but the effect is the same. My new code: my $stdin = tied *STDIN; my $stdout = tied *STDOUT; untie *STDIN; untie *STDOUT; my $child = open3 ($cgi_in, $cgi_out, $cgi_error, $filename); tie *STDIN, ref $stdin, $stdin; tie *STDOUT, ref $stdout, $stdout;
Re: Environment variables in startup.pl
Scott Alexander ([EMAIL PROTECTED]) said something to this effect on
04/27/2001:
> Should this work in a startup.pl file
>
> my $hostname = $ENV{"HOSTNAME"} ;
>
> from the prompt I can write echo $HOSTNAME and get the correct
> hostname of the server.
>
> But from within startup.pl I don't get it.
>
> Scott
use Sys::Hostname;
$host = hostname;
(darren)
--
vi, vi, vi - the Editor of the Beast
Re: CORE::format() and CORE::write() under 5.6.x
On Mon, 30 Apr 2001, Stas Bekman wrote: > cool, but this section in the guide was stating the CORE::format() doesn't > work. And it's still doesn't under mod_perl. So doesn't CORE::write(). Right, but it would be nice to point to an alternative. The module is called Text::Reform, by the way. -- /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
unsubscribe sam@omatis.com
unsubscribe [EMAIL PROTECTED] -- Samuel Lellouche - Omatis Expert Systèmes, réseaux et securité E-mail: [EMAIL PROTECTED] Tel: 01 53 14 59 14 / 01 53 14 59 31
