Re: [OT] Re: Yahoo is moving to PHP ??
On Wed, 30 Oct 2002, Richard Clarke wrote: > List, > You are probably not the best people to ask for an answer which > might advocate PHP, > but. > Can someone who is more proficient in PHP than I (I have used it > for 5 minutes) explain to me why it is quicker to prototype things in PHP? ---> it isn't. PHP blows.
Re: Yahoo is moving to PHP ??
On Thu, 31 Oct 2002, Gunther Birznieks wrote: > You would think if they want an anal scripting language they would move > to python not PHP. :) Python isn't anal--it's a very clean, interesting, flexible language on par with perl--perhaps superior in some ways and not as good in others but, overall, on a similar scale. In respect to the article, to me, anyway, most of the arguments weren't particularly compelling from my outside viewpoint. The one point they made was true--PHP was developed specifically for the web and doesn't have the wide variability of perl (they seem to equate extensive flexibility, as a trouble point leading to great variance in the code -- stylistically and logically). I don't think this problem is neccessarily eliminated comprehensively by switching to a crappy language like PHP. Some standardization could be achieved via coding guidelines, approved practices, code reviews etc. while still retaining the power and flexibility of a perl. Many of the problems they associated with perl aren't neccessarily eliminated by using PHP, including the issues with code variance. They still stated that perl would fuel many things on the backend, though, so they haven't gone completely mad. -mj > John Saylor wrote: > > >Hi > > > >( 02.10.30 03:22 -0500 ) Perrin Harkins: > > > > > >>They didn't make their decision on performance though. They seem to > >>have been most influenced by the idea that perl allows too much > >>flexibility in coding style, although I can't see how PHP is going to > >>help with that. > >> > >> > > > >Wow, I'd like what *they* had for lunch! > > > >Quasi-seriously, as someone who has had to maintain mountains of bad > >perl code, I know TMTOWTDI can have a downside; but the openness of the > >language is what has lead to its greatness ... > > > > > > >
Re: Prototypes and $r
What does MasonHandler actually look like?
-mj
On Tue, 24 Sep 2002, Ken Miller wrote:
> Got a phone call yesterday from a user who was complaining that every few
> times a link was clicked on they were getting an "Internal Server Error".
> They could click back, try again, and be successful. Further investigation
> led me to find that one of the instances of my back end server was always
> generating an error.
>
> Restarts would not fix the problem - one or two of the app servers would
> always throw errors
>
> The error was this:
>
> [Mon Sep 23 19:12:21 2002] [error] Can't call method "dir_config" on an
> undefined value at /webroot/lib/Husky/Web/Apache
> /MasonHandler.pm line 68.
>
> The line in question is this:
>
> my $appl_id = $r->dir_config( 'ApplID' );
>
> So, you can see that '$r' was undefined.
>
> The interesting thing is that the handler that's invoked for this request
> has a prototype:
>
> sub handler( $$ ) { my $class = shift; my $r = shift; ... }
>
> and the handler is either invoked by Apache directly, or from internal logic
> when a request is passed off. The handler is invoked in one of two ways:
>
> __PACKAGE__->a_method_name( $r );
>
> or
>
> Foo::Bar::Bah->a_method_name( $r );
>
> Now, it appears that every now and then the class reference is NOT being
> sent; hence, $class actually contains $r, and $r is undefined. This is
> obviously bad, since $r->dir_config dies a horrible death.
>
> Has anyone had a problem with this? Is there something that might give me a
> clue as to why this is failing? In the meantime, I've when back to
> referencing the sub directly, as opposed to going through the class. It
> works, but it's not as nice as a class method...
>
> Cheers!
>
> -klm.
>
> +-+-+
> | Kenneth (Ken) L. Miller | There are 10 kinds of people in the |
> | Shetland Software Services Inc. | world: Those who understand binary, |
> | [EMAIL PROTECTED]| and those who don't. (unknown) |
> +-+-+
>
RE: FreeBSD Apache/mod_perl/OpenSRS/expat problem + solution
Yeh, it does apply on other BSD platforms--but I don't think it's specific to BSD(s). I use the same args on Net and Open on Apaches I've built on those platforms. I came across this issue with AxKit. There's tons of references on the web as well: http://www.google.com/search?hl=en&ie=UTF8&oe=UTF8&q=disable-rule%3Dexpat -Original Message- From: Bill O'Hanlon [mailto:[EMAIL PROTECTED]] Sent: Sunday, June 09, 2002 7:31 AM To: [EMAIL PROTECTED] Subject: FreeBSD Apache/mod_perl/OpenSRS/expat problem + solution Hi folks, I just ran down a problem that was somewhat hard to find, and I didn't see any mention of anything like it in the archives anywhere. I thought it might be helpful to mention the details in case someone else is ever in the same situation. I'm running FreeBSD 4.5, with perl 5.6.1 and Apache 1.3.24. I had a working installation of the regular OpenSRS perl code via cgi-bin, but I thought I'd get it running under Apache::Registry in mod_perl. To my surprise, the Apache daemons would dump core whenever I tried to log in with manage.cgi. It turns out that the current FreeBSD port of Apache uses it's own internal version of "expat", which is an XML library of some kind. This internal version doesn't connect up well with the version that XML::Parser is expecting to find. Turning this off in the Apache build fixed the problem, and the OpenSRS code runs very nicely under mod_perl now. At this point, I don't understand what functionality I've lost by not having the expat code built into the Apache binary. The configure option to leave out expat is "--disable-rule=EXPAT". In the FreeBSD port, that's easily added to the CONFIGURE_ARGS variable in the Makefile. I don't know if this applies to any other platform. My guess is that it could, since I think the default for Apache is to use the internal version of expat. Hope this helps someone! -Bill -- Bill O'Hanlon [EMAIL PROTECTED] Professional Network Services, Inc. 612-379-3958 http://www.pro-ns.net
