Perl Configured VirtualHost question
Typically my manually configured vhosts look like this : NameVirtualHost 10.0.0.20:80 VirtualHost 10.0.0.20:80 ServerName BladeBla.com DocRoot ... ... /VirtualHost VirtualHost 10.0.0.20:80 ... /VirtualHost This works great for my statically configured hosts. How do you accomplish this same VHost scheme wheh configuring via perl? Each %VirtualHost key is a single server and I am so far unable to assign multiple values ( array ref? ) to a single key (the IP assigned in NameVirtualHost). Any tips or pointers would be nice. I am trying to move a machine and in its new home the perl configured vhosts ( About 1100 of them ) are resolving to a the _default_ host since this particular system is using the older style name based hosts and not the newer (to me) NameVirtualHost directive syntax. John-
Yahoo is moving to PHP ??
http://public.yahoo.com/~radwin/talks/yahoo-phpcon2002.htm If nothing else this should be atleast generate some thoughts ?? It does show the mod_perl logo so I assume the comments are applying to mod_perl and not perl/cgi. Mithun -- Cons Theres More Than One Way To Do It poor sandboxing, easy to screw up server wasnt designed as web scripting language __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
Re: Yahoo is moving to PHP ??
Mithun Bhattacharya wrote: http://public.yahoo.com/~radwin/talks/yahoo-phpcon2002.htm If nothing else this should be atleast generate some thoughts ?? It does: hooray! Yahoo is moving from a proprietary server-side scripting tool to an open source one. Great news for all of us, since they will help legitimize open source (the largest site in the world runs on it) and maybe feed good ideas back to the open source world. (Of course Yahoo has used other open source tools forever.) If you look at the performance graphs they made, mod_perl comes in neck and neck with PHP. We always see mod_perl go faster than PHP in Joshua's tests, but Yahoo was testing with this Ioncube cache that keeps PHP code in memory (like mod_perl). The performance tests were so close that a little optimization on the mod_perl side might actually turn it around. 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. They also say they plan to continue using lots of perl in all the places they use it now: off-line processing, filling in the includes and dbm files that the server-side script assembles. Perl is not being removed. - Perrin
Quota module for Perl
Hi, i am trying to install the Quota module for Perl, but following error occurs: I´ve installed RedHat 7.1 mod_perl 1.24_01-2 perl 5.6.0-12 Has anyone got an idea? Regards Peter cpan install Quota Running install for module Quota Running make for T/TO/TOMZO/Quota-1.4.6.tar.gz CPAN: Digest::MD5 loaded ok Checksum for /root/.cpan/sources/authors/id/T/TO/TOMZO/Quota-1.4.6.tar.gz ok Scanning cache /root/.cpan/build for sizes Quota-1.4.6/ Quota-1.4.6/CHANGES Quota-1.4.6/INSTALL Quota-1.4.6/MANIFEST Quota-1.4.6/Makefile.PL Quota-1.4.6/Quota.pm Quota-1.4.6/Quota.xs Quota-1.4.6/README Quota-1.4.6/hints/ Quota-1.4.6/hints/solaris_2.h Quota-1.4.6/hints/sunos_4_1.h Quota-1.4.6/hints/none.h Quota-1.4.6/hints/linux.h Quota-1.4.6/hints/irix_6.h Quota-1.4.6/hints/irix_5.h Quota-1.4.6/hints/aix_4_1.h Quota-1.4.6/hints/hpux.h Quota-1.4.6/hints/dec_osf.h Quota-1.4.6/hints/bsd.h Quota-1.4.6/test.pl Quota-1.4.6/contrib/ Quota-1.4.6/contrib/README Quota-1.4.6/contrib/report-quota Quota-1.4.6/contrib/quotamgmt/ Quota-1.4.6/contrib/quotamgmt/Author Quota-1.4.6/contrib/quotamgmt/config Quota-1.4.6/contrib/quotamgmt/quotamgmt Quota-1.4.6/contrib/test-group.pl Quota-1.4.6/contrib/mount-list.pl Quota-1.4.6/contrib/mount-list-qcarg.pl Quota-1.4.6/include/ Quota-1.4.6/include/rquota.h Quota-1.4.6/include/afsquota.h Quota-1.4.6/include/stdio_wrap.h Quota-1.4.6/include/vxquotactl.h Quota-1.4.6/include/quotaio_xfs.h Quota-1.4.6/stdio_wrap.c Quota-1.4.6/afsquota.c Quota-1.4.6/vxquotactl.c Quota-1.4.6/linuxapi.c Removing previously used /root/.cpan/build/Quota-1.4.6 CPAN.pm: Going to build T/TO/TOMZO/Quota-1.4.6.tar.gz Using hints/linux.h for myconfig.h Checking if your kit is complete... Looks good Configured without AFS support Writing Makefile for Quota cp Quota.pm blib/lib/Quota.pm AutoSplitting blib/lib/Quota.pm (blib/lib/auto/Quota) /usr/local/bin/perl /usr/local/lib/perl5/5.8.0/ExtUtils/xsubpp -typemap /usr/local/lib/perl5/5.8.0/ExtUtils/typemap Quota.xs Quota.xsc mv Quota.xsc Quota.c rm -f myconfig.h ln -s hints/linux.h myconfig.h cc -c -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\1.4.5\ -DXS_VERSION=\1.4.5\ -fpic -I/usr/local/lib/perl5/5.8.0/i686-linux/CORE Quota.c In file included from Quota.xs:11: myconfig.h:21:27: rpcsvc/rquota.h: Datei oder Verzeichnis nicht gefunden make: *** [Quota.o] Fehler 1 /usr/bin/make -- NOT OK Running make test Can't test without successful make Running make install make had returned bad status, install seems impossible cpan
Re: Yahoo is moving to PHP ??
--- Perrin Harkins [EMAIL PROTECTED] wrote: Mithun Bhattacharya wrote: http://public.yahoo.com/~radwin/talks/yahoo-phpcon2002.htm They also say they plan to continue using lots of perl in all the places they use it now: off-line processing, filling in the includes and dbm files that the server-side script assembles. Perl is not being removed. No it is not being removed but this could have been a very big thing for mod_perl. Can someone find out more details as to why PHP was preferred over mod_perl it cant be just on a whim. I might be biased but considering the fact that PHP and mod_perl were neck to neck the cons should have made up for any slipup in performance. Also how does one go about justifying the fact that Ioncube cache is doing a better cacheing than any mod_perl based solution ?? I am assuming when Yahoo did their research they optimized everything to the maximum possible they werent out to do a marketting propaganda now were they Mithun __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
Re: Same $dbh under different pids?
On Tue, Oct 29, 2002 at 09:06:45PM +, Richard Clarke wrote:
Moi,
a quick question: is it possible to have the 'same' dbh across the apache
children even if you do your best not to?
This minimalistic handler:
use strict;
package Foo;
use Apache::DBI;
use DBI;
use Apache::Constants qw':common';
my $dbh;
You haven't initialised this, so each request will get the same object
that is made below.
$Apache::DBI::DEBUG = 1;
This should be in a start up file really.
sub handler {
my $r = shift;
$r-send_http_header;
$r-print(ok);
You could just put,
print ok;
$dbh ||= DBI-connect(dbi:mysql: ... etc);
Apache::DBI takes care of pooling connections.
Use,
my $dbh = DBI-connect(CONNECT);
and get rid of the global $dbh above.
Richard,
thanks for your suggestions. The problem is not so much in the code (I know
the code above isn`t the 'best' way) but in the fact I seem to get the same
$dbh across children. I`m just curious if that is to be expected:
okdbh: Apache::DBI::db=HASH(0x8269a7c) (85799)
okdbh: Apache::DBI::db=HASH(0x8269a7c) (85800)
okdbh: Apache::DBI::db=HASH(0x8269a7c) (85801)
okdbh: Apache::DBI::db=HASH(0x8269a7c) (85802)
okdbh: Apache::DBI::db=HASH(0x8269a7c) (85803)
okdbh: Apache::DBI::db=HASH(0x8261424) (85799)
okdbh: Apache::DBI::db=HASH(0x8261424) (85800)
(Each line is a reload with the code after your suggestions)
Thanks,
Harmen
--
The Moon is Waning Crescent (37% of Full)
RE: Yahoo is moving to PHP ??
-Original Message- From: Mithun Bhattacharya [mailto:inzoik;yahoo.com] Sent: 30 October 2002 09:17 To: [EMAIL PROTECTED] Subject: Re: Yahoo is moving to PHP ?? No it is not being removed but this could have been a very big thing for mod_perl. Can someone find out more details as to why PHP was preferred over mod_perl it cant be just on a whim. I might be biased but considering the fact that PHP and mod_perl were neck to neck the cons should have made up for any slipup in performance. err did you look at the same slides as me? in all performance tests, YSP(perl) performed better than PHP, with the exception of memory usage. and there is a slide explaining why not Perl - the main objection seemed to be: QUOTE There's More Than One Way To Do It so many different Perl styles everyone's code looks different problematic for development when many people working on single codebase /QUOTE While there were Pros/Cons for Perl and the other rejectees, there were no Pros/Cons for PHP unless you count the gotchas mentioned after four months of using PHP: QUOTE Shallow learning curve - very easy to get some pages up quickly But mixed app/presentation problematic - PHP code and HTML forever intertwined - coding conventions help *.inc for function and class libraries *.php for web pages (call functions, echo $vars) - use Smarty to enforce separation? The drawback of using a code in template system, is that your code and HTML output quickly become forever intertwined. This makes changing the appearance of your pages difficult. For example, if you check the user cookie and load user database data in the common-header moving around where you include this template will change where you retrieve the database information for the user, possibly breaking other parts of the page which rely on that data. http://www.clearsilver.net/docs/apples_to_oranges.hdf The implement twice problem - much offline processing done in Perl - example: tax/shipping calculation for Shopping PEAR != CPAN - installer doesn't work in PHP 4.2.x - repository smaller, less mature than CPAN Surprises for people used to coding Perl /QUOTE Interestingly our experience was/is similar - we chose PHP 2.5 years ago for the development of our dynamic ASP interactive pages, and Perl for all our data-processing and server management etc. Hindsight shows us that it was the right decision at the time - we gained an 18 month lead on the competition. After 2.5 years, the 'have to write everything twice' problem has lead us to plan a gradual migration from PHP to Perl. All our new pages and products are being developed in mod_perl. I wonder if they will consider a similar change? Unlikely give the number of developers and the disruption? There is one con for PHP that I disagree with - you don't have to mix your HTML and application logic - just as in Perl, you can separate them if you want to - we work extensively in PHP ordered hashes and isolate the formatting and HTML generation in a few included utility collections, making it easy to change the HTML we generate without changing any of the underlying business information. Regards Jeff
Re: Same $dbh under different pids?
On Wed, Oct 30, 2002 at 06:05:51PM +0800, Philippe M. Chiasson wrote:
For the same reason that running this:
$ perl -e'fork; { $foo = {}; print $$:$foo\n}'
1984:HASH(0x804c00c)
1987:HASH(0x804c00c)
produces this for me, every single time I run this program
You are assuming that if (0x804c00c) is equal in different processes,
they must be pointers(or references, or handles) to the same thing. And
it is not the case ;-)
Ok, that was what I was looking for! Explains it all.
Thanks,
Harmen
--
The Moon is Waning Crescent (37% of Full)
reverse_proxy ?
Hi, In a test environment I have a apache front_end server and a apache mod_perl server both are on two physical different machines, plus another machine for the database. Our production server is one machine running only one instance of apache/mod_perl and another machine for the database. Users can upload documents, set rights as to who can download/update the documents. The documents are kept in a directory outside of the document root. I use Transhandler to rewrite the uri to the correct file location. A http_referer also has to be present for the user to get the file. I want to put all the documents on the front_end which is not running mod_perl (here is a copy from the installation ./configure --prefix=/usr/local/apache --enable-module=ssl --enable-module=rewrite --enable-module=proxy --disable-module=cgi) Then as far as I can see the documents would have to be under documentroot which means anyone can have access to them just by guessing the url. Any ideas how I can have the documents on the front_end and still maintain some level of security. /Scott
Re: Perl Configured VirtualHost question
On Wed, 30 Oct 2002 at 02:24, [EMAIL PROTECTED] opined:
:Typically my manually configured vhosts look like this :
:
:NameVirtualHost 10.0.0.20:80
:
:VirtualHost 10.0.0.20:80
: ServerName BladeBla.com
: DocRoot
: ...
: ...
:/VirtualHost
:VirtualHost 10.0.0.20:80
:...
:/VirtualHost
:
:This works great for my statically configured hosts. How
:do you accomplish this same VHost scheme wheh configuring
:via perl? Each %VirtualHost key is a single server and I
:am so far unable to assign multiple values ( array ref? )
:to a single key (the IP assigned in NameVirtualHost).
do you have the eagle book? how to do this is documented on page 418.
you are correct, use an array ref, with each value being a hash ref, one
for each virtual host:
my @config = (
{ ServerName = 'one.fish.net',
ServerAdmin = '[EMAIL PROTECTED]',
etc },
{ ServerName = 'red.fish.net',
ServerAdmin = '[EMAIL PROTECTED]',
etc }
);
$VirtualHost{'192.168.2.5'} = \@config;
Re: reverse_proxy ?
Hi there, On Wed, 30 Oct 2002, Scott Alexander wrote: [snip] Our production server is one machine running only one instance of apache/mod_perl and another machine for the database. [snip] Any ideas how I can have the documents on the front_end and still maintain some level of security. This isn't really a mod_perl question then? :) Best have a look at access control with Apache, you can for example use .htaccess files. I believe it's in the Apache documentation, and there are quite a few books on the subject. My favourite is Professional Apache, I think the ISBN is 1861003021. 73, Ged.
Re: Yahoo is moving to PHP ??
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: Yahoo is moving to PHP ??
You would think if they want an anal scripting language they would move to python not PHP. :) 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 ...
[OT] Re: Yahoo is moving to PHP ??
If they are going to inherently mangle their php and perl and lose that abstraction layer I think in 2 years they will look back and wish TMTOWTDI was their only problem That said, Kudo's to yahoo for being this public about it. These are the sorts of publically available presentations that give those of us trying to justify our existence some teeth. Walking into a management meeting and saying 'Look, even yahoo disdains Java and they have 4500+ servers and are the biggest internet portal and have a lot of geeks programming and even they admit modperl is awesome and fast and they are only not using it becuase its TO powerful' is a potent weapon. Cheesy yes, needed, yes.. John- On Thu, 31 Oct 2002 00:12:02 +0800 Gunther Birznieks [EMAIL PROTECTED] wrote: You would think if they want an anal scripting language they would move to python not PHP. :) 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 ...
[OT] Re: Yahoo is moving to PHP ??
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? I can't understand this statement. Surely this is only applicable to people who are not proficient with mod_perl [% my_templating_engine %]? Much of the code from PHP based websites which I have read has seemed to take this prototyping idea too much to heart. It looks more like an overly complex prototype than a well working application. /me doesn't get it.
RE: Yahoo is moving to PHP ??
Hi John -- 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 ... This doesn't have to be as big a problem as it often is. Having coding standards makes a big difference no matter WHICH language you use. Have you ever seen bad Java code? Java has reached parity with Perl in that area, for sure! This is a problem in ANY language. You just can't hire smart people and send them out there without direction. At my company we base all our work on CGI::Application and HTML::Template to solve exactly this problem. CGI-App and HTML-Tmpl (or Template Toolkit -- TT is compatible with C::A) strongly suggest a standard way of writing the uninteresting bits of a web application -- namely, state management and HTML separation. They go beyond what is provided by simply making a decision to use a particular API, such as CGI, mod_perl, PHP, Mason, etc. No software library will factor this problem out entirely. This is really a human problem -- not a software problem. However, choosing a specific tactic is a good start. TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
AuthCookie Frames
I'm having a slight problem using AuthCookie in our app because our app
(unfortunately) is a frames-based interface. To summarize the problem and
efforts I've made to date, my goal is to be able to display a message on the
login page telling them why they are seeing the login page. Options are:
'Login Incorrect', 'Previous Session Timed Out', 'Session Deactivated Due To
Login From Another Location', etc...
My first attempt was to try to just set values in the subprocess_env, and
since AuthCookie works by removing a user's cookie and then doing redirects
to the login page if a user is not validly logged in, I could always just
look at $r-prev-subprocess_env('login_error_msg') for the cause. However,
since I am using frames, this doesn't work in all cases.
If for example a user is currently at a part of the site that has three
frames, and then walks to his co-workers office and uses that computer to
log in, we have invalidated his old session back at his desk. If he goes
back to his own desk and tries to navigate in the app, we want to redirect
to a login page with the message 'Session Deactivated Due To Login From
Another Location'. However, what happens is that he goes to click on
something, javascript gets called that changes the contents of all three
frames, so all three frames try to load new content. This means 3 new
requests, and 3 passes through AuthCookie. Well the first pass through
works exactly like I would expect and
$r-prev-subprocess_env('login_error_msg') has the proper error message.
The problem is that the other two requests also go through AuthCookie, and
since the first one already removed the cookie, the other two just see that
the user doesn't have a cookie and also redirect to the login page. So what
the user is seeing is really the third redirect to the login page, which no
longer has any useful info in $r-prev-subprocess_env.
So my next thought was that we need some sort of global login messages
object that could be shared across children and requests and could hold
login failure messages. Since I'm already using Apache::Session, I thought
following the cookbook's recipe on how to use A::S for global data would be
good. So I set up a session with a known key (_loginmsgs) but then
realized there's no piece of info I can use to uniquely identify a
particular user/browser so that I can store a message for him. I can't use
the session key since by the time it comes to look up if there are any
messages I should be displaying on the login page, there's no longer a
session key to reference (the cookie has been removed). I then thought I
could just try the IP address but firewalls could make multiple users look
to be coming from the same IP. I never really came up with something I
thought would work and was clean. So, finally, the question is has anyone
solved this same problem, or does anyone have any ideas of what I should
try?
Thanks,
Fran
RE: [OT] Re: Yahoo is moving to PHP ??
The first thing to note is that our working definition of intuitive here translates
to: based on prior knowledge.
PHP is a tag based language and places relatively complex functions at the fingertips
of your average joe newbie. It is therefore more intuitive and remarkably faster to
develop with when you are employing a pool of bell-curve skilled programmers.
It is for this same reason that we offer cold fusion for the dynamic sites we host: if
you have a bit of experience with HTML, a one day class in cold fusion lets you work
with cookies and databases, et cetera. In our evaluation of what to support in terms
of web application languages, we selected perl for its power and Cold Fusion for its
speed of deployment; the latter over PHP because of its maturity { security,
stability, features, IDE support }. I laugh at the Java bashing because as time wore
on, you guessed it, we were asked to write an enterprise calendar in Java.
Derrick Stone
Internet Specialist
Web Development Center
UVa Health System
ICQ# 1464194
-Original Message-
From: Richard Clarke [mailto:ric;likewhoa.com]
Sent: Wednesday, October 30, 2002 11:34 AM
To: [EMAIL PROTECTED]
Subject: [OT] Re: Yahoo is moving to PHP ??
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?
I can't understand this statement. Surely this is only
applicable to people who are not proficient with mod_perl [%
my_templating_engine %]?
Much of the code from PHP based websites which I have read has
seemed to take this prototyping idea too much to heart. It looks more
like an overly
complex prototype than a well working application.
/me doesn't get it.
RE: Yahoo is moving to PHP ??
At 11:39 30/10/2002 -0500, Jesse Erlbaum wrote: Hi John -- 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 ... This doesn't have to be as big a problem as it often is. Having coding standards makes a big difference no matter WHICH language you use. Have you ever seen bad Java code? Java has reached parity with Perl in that area, for sure! This is a problem in ANY language. You just can't hire smart people and send them out there without direction. I completely agree. Bad code is bad code in any languaje (well, perhaps with perl you can write the most encrypted code, but only if you are looking for it). I don't really know the ability of PHP to work with templates, but since I discovered Template Toolkit 2, I've never written (nor will I) more web applications without it. I cannot understand why don't want them to use HTML templates. I suspect, the propietary languaje the were using was similar in concept to PHP or ASP not allowing templates. Oscar Serrano. At my company we base all our work on CGI::Application and HTML::Template to solve exactly this problem. CGI-App and HTML-Tmpl (or Template Toolkit -- TT is compatible with C::A) strongly suggest a standard way of writing the uninteresting bits of a web application -- namely, state management and HTML separation. They go beyond what is provided by simply making a decision to use a particular API, such as CGI, mod_perl, PHP, Mason, etc. No software library will factor this problem out entirely. This is really a human problem -- not a software problem. However, choosing a specific tactic is a good start. TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
Re: Yahoo is moving to PHP ??
On Wed, 30 Oct 2002 11:39:07 -0500 Jesse Erlbaum wrote: Hi John -- 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 ... This doesn't have to be as big a problem as it often is. Having coding standards makes a big difference no matter WHICH language you use. Have you ever seen bad Java code? Java has reached parity with Perl in that area, for sure! This is a problem in ANY language. You just can't hire smart people and send them out there without direction. Amen. I came to Perl from a language called IDL (Interactive Data Language, not Interface Definition Language). It's an array-based language that has inspired PerlDL (though I've not used PerlDL). I came to IDL from Ada and C. Ada and C are strongly typed, whereas Perl is loosely typed, though nowehere near as loose as IDL. The variable a in IDL can be changed between an array, scalar, function, etc., with no indication, or even concern, about how it's being used from line to line in your program. TMTOWTDI applies to IDL even more than it does to Perl. After trying to follow some IDL-based NASA code years ago, I posted an IDL Style Guide on my site that's seen some use in the IDL community. If nothing else, it keeps me from stepping all over myself when I'm coding in IDL. It's also easier to figure out when I've accidentally assigned a string to a variable when I planned to use it for an array, or whatever. At my company we base all our work on CGI::Application and HTML::Template to solve exactly this problem. And I'm moving towards the same thing as I've spent a lot of time developing CGI code in the last couple of years. Mike Schienle Interactive Visuals, Inc. http://www.ivsoftware.com - This message sent using EMUmail -- http://www.emumail.com - Jumping through hoops to get E-mail on the road? You've got two choices: Join the circus, or use MollyMail. Molly Mail -- http://www.mollymail.com
What's wrong on the line 149 of registery.pm from Apache 1.3.26
Hi there, There is an error in the error.log that appears the line 149 of registery.pm from Apache 1.3.26 when I am running a CGI. Is it a bug for this type of error to appear so often? Thanks, Willy
[OT] Re: Yahoo is moving to PHP ??
Check out their online map site, they do use Python for that. snippet o' URL: http://maps.yahoo.com/py/maps.py?BFCat=. You know you're going to have a bad day when you see the sun come up. Over the curb. Brian Nilsen [EMAIL PROTECTED] 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. :) 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: [OT] Re: Yahoo is moving to PHP ??
Tom Servo wrote: Check out their online map site, they do use Python for that. I'm actually surprised they didn't go with Python, because the people I know there love it. If their backend data processing ever gets moved from Perl to something else, it would probably be moved to Python. - Perrin
Re: Yahoo is moving to PHP ??
Mithun Bhattacharya wrote: No it is not being removed but this could have been a very big thing for mod_perl. Can someone find out more details as to why PHP was preferred over mod_perl it cant be just on a whim. Think about what they are using it for. Yahoo is the most extreme example of a performance-driven situation. They have so much volume that they are willing to write things in C++ just to get the speed that is required. They pre-process and cache things as much as they possibly can. The server-side scripting language they use is basically a glorified include processor. They pull in pre-built include files and read things out of dbms with it. That's all. The real application stuff is built in other languages. (At least this is the impression I get from the paper and from talking to people there.) Given that, PHP is a reasonable fit. It's fast, has a less flexible syntax, and uses less memory than mod_perl. They also have more of a need than most people to integrate with C/C++, and I've been told that it's easier to hack those into PHP. Think about the implications of the memory graph. If they can run 5 more apache children at once on PHP because of its lower memory consumption, 5 * 4500 = 22500 more users they can handle at any given moment! Also how does one go about justifying the fact that Ioncube cache is doing a better cacheing than any mod_perl based solution ?? Sorry, I read that wrong. It was actually mod_perl that had the best performance. The cache they use works just the same as Perl's normal operation, i.e. once some code is compiled it stays in memory and doesn't need to be compiled again. You don't have to do anything to get that in Perl. - Perrin
Re: Same $dbh under different pids?
harm wrote:
On Wed, Oct 30, 2002 at 06:05:51PM +0800, Philippe M. Chiasson wrote:
For the same reason that running this:
$ perl -e'fork; { $foo = {}; print $$:$foo\n}'
1984:HASH(0x804c00c)
1987:HASH(0x804c00c)
produces this for me, every single time I run this program
You are assuming that if (0x804c00c) is equal in different processes,
they must be pointers(or references, or handles) to the same thing. And
it is not the case ;-)
Wait, ins't it the case? That number is supposed to be the location in
memory. It seems like these are all pointing to the same hash. I can't
explain how that would happen though, based on the code shown here.
- Perrin
Re: Yahoo is moving to PHP ??
At 02:50 PM 10/30/02 -0500, Perrin Harkins wrote: Mithun Bhattacharya wrote: No it is not being removed but this could have been a very big thing for mod_perl. Can someone find out more details as to why PHP was preferred over mod_perl it cant be just on a whim. Think about what they are using it for. Yahoo is the most extreme example of a performance-driven situation. I also wonder if it's cheaper/easier to hire and train PHP programmers that Perl programmers. -- Bill Moseley mailto:moseley;hank.org
Re: Yahoo is moving to PHP ??
Perrin Harkins writes: The real application stuff is built in other languages. (At least this is the impression I get from the paper and from talking to people there.) I think Yahoo Stores is written in Lisp. I also believe it handles the front and back end. Would be interesting to know why this was left out of the discussion. Rob
Re: Same $dbh under different pids?
On Wed, 2002-10-30 at 14:52, Perrin Harkins wrote:
harm wrote:
On Wed, Oct 30, 2002 at 06:05:51PM +0800, Philippe M. Chiasson wrote:
For the same reason that running this:
$ perl -e'fork; { $foo = {}; print $$:$foo\n}'
1984:HASH(0x804c00c)
1987:HASH(0x804c00c)
produces this for me, every single time I run this program
You are assuming that if (0x804c00c) is equal in different processes,
they must be pointers(or references, or handles) to the same thing. And
it is not the case ;-)
Wait, ins't it the case? That number is supposed to be the location in
memory. It seems like these are all pointing to the same hash. I can't
explain how that would happen though, based on the code shown here.
You're confusing virtual memory with physical memory. Given an SMP
system where pid 1984 and 1987 can both actually run at the same time
(thus ensuring neither is swapped out) address 0x804c00c actually
occupies two completely distinct blocks of physical memory.
$ perl -e '$foo = {}; fork; print $$:$foo\n;'
18161:HASH(0x80fd254)
18162:HASH(0x80fd254)
$ perl -e 'fork; $foo = {}; print $$:$foo\n;'
18163:HASH(0x80fd254)
18164:HASH(0x80fd254)
The effects are entirely expected. Perl takes up so much memory, and
that amount doesn't increase or decrease unless I recompile perl. So the
first allocation for a hash seems bound to occur at the same address in
virtual-memory every single time.
$ perl -e '$foo = {bar = 1};fork;print $$:$foo . $foo-{bar} . \n;'
That works like you'd expect, doesn't it? Now consider this:
#!/usr/bin/perl
$foo = {};
if (fork == 0) {
sleep(1);
} else {
$foo-{bar} = 1;
}
print $$:$foo: . $foo-{bar} . \n;'
All this serves to demonstrate is that the parent cannot modify the
child's memory map. While both exist in the same place in virtual
memory, the values obviously contain different values, and the physical
memory itself is different.
It's difficult to fully appreciate this in Perl... Maybe someone will
make a proper mmap() someday.
Re: Same $dbh under different pids?
Perrin Harkins [EMAIL PROTECTED] wrote:
harm wrote:
On Wed, Oct 30, 2002 at 06:05:51PM +0800, Philippe M. Chiasson wrote:
For the same reason that running this:
$ perl -e'fork; { $foo = {}; print $$:$foo\n}'
1984:HASH(0x804c00c)
1987:HASH(0x804c00c)
produces this for me, every single time I run this program
You are assuming that if (0x804c00c) is equal in different processes,
they must be pointers(or references, or handles) to the same thing. And
it is not the case ;-)
Wait, ins't it the case? That number is supposed to be the location in
memory. It seems like these are all pointing to the same hash. I can't
explain how that would happen though, based on the code shown here.
The same address in two different applications doesn't always point
to the same place in physical memory. Virtual memory address !=
physical memory address on most `modern' processors. This is what
allows copy-on-write to work for Apache children -- all the addresses
are the same, but the data is different.
--
James Smith [EMAIL PROTECTED], 979-862-3725
Texas AM CIS Operating Systems Group, Unix
Re: Yahoo is moving to PHP ??
I'm sure it is. This has been discussed on this list before: PHP in safe mode is much more likely to be found on the offerings of virtual hosting companies, which tend to use control panel things like Plesk, Ensim, or RAQ boxes. If you do get mod_perl you don't get to play with everything, it usually just means you get to run stuff in Registry. Therefore most people will get to play in PHP and do projects for real customers in PHP at an earlier stage in their careers. And inside of a year you'll have built some fairly solid applications that work, and you'll be looking for work as a website programmer because it was so easy to satisfy your customer, who really just wanted to be able to update his real-estate listings without phoning you twice a week.. Ooops, that's a lot of people right now. Jobs for PHP guys are fewer and farther between than for Perl guys. Supply/demand would tend to drive the price for PHP guys down, one would think. Later of course you'll try to differentiate yourself from the masses, and try to find out what Perl can do for your career and for your applications. Sometimes, and this is not me, you'll find that you NEED to look at some speed enhancement because your stupid website actually became popular. Tweaking PHP, refining your queries, adding hardware, and doing stuff like output caching would probably last you an awful long time before you had to switch languages. I also wonder if it's cheaper/easier to hire and train PHP programmers that Perl programmers. -- Bill Moseley mailto:moseley;hank.org
Re: What's wrong on the line 149 of registery.pm from Apache 1.3.26
Richard,
Thanks for your comment.
The error appears frequently, i.g. sometime works sometime not. Here is
error message:
Apache::ROOTapmoneywire_2emm_2eap_2eorg::qq::quickquote_2ecgi::handler
('Apache=SCALAR(0x3715f4)') called at
/opt/apache/lib/site_perl/5.6.0/sun4-solaris/Apache/Registry.pm line 149
require 0 called at
/opt/apache/lib/site_perl/5.6.0/sun4-solaris/Apache/Registry.pm line 149
Willy
Richard Clarke
[EMAIL PROTECTED]To: [EMAIL PROTECTED]
cc:
Subject: Re: What's wrong on the line
149 of registery.pm from Apache 1.3.26
10/30/2002 02:00
PM
Willy,
[EMAIL PROTECTED] wrote:
Hi there,
There is an error in the error.log that appears the line 149 of
registery.pm from Apache 1.3.26 when I am running a CGI. Is it a bug for
this type of error to appear so often?
It might be more useful to paste this error to the list.
Thanks,
Willy
Ric.
Bricolage in eWeek
This weeks print version of eWeek as well as the online version have an article on Bricolage. article - http://www.eweek.com/article2/0,3959,652977,00.asp Bricolage - http://bricolage.thepritgroup.com Aaron Johnson
Re: Same $dbh under different pids?
Mrs. Brisby wrote:
$ perl -e '$foo = {}; fork; print $$:$foo\n;'
18161:HASH(0x80fd254)
18162:HASH(0x80fd254)
$ perl -e 'fork; $foo = {}; print $$:$foo\n;'
18163:HASH(0x80fd254)
18164:HASH(0x80fd254)
I expected the first. I didn't expect the second. Thanks for the
explanation.
- Perrin
Apache::Peek and perl 5.8.0
Does anyone have Apache::Peek working with perl 5.8.0? I can't get it to build, and I can't find the symbols it's (apparently) missing anywhere in perl 5.8.0's header files. Example: --- CPAN.pm: Going to build D/DO/DOUGM/Apache-Peek-0.9501.tar.gz Checking if your kit is complete... Looks good Writing Makefile for Apache::Peek cp Peek.pm blib/lib/Apache/Peek.pm /usr/local/bin/perl /Library/Perl/ExtUtils/xsubpp -typemap /Library/Perl/ExtUtils/typemap Peek.xs Peek.xsc mv Peek.xsc Peek.c Please specify prototyping behavior for Peek.xs (see perlxs manual) cc -c -I/Library/Perl/darwin/auto/Apache/include -I/Library/Perl/darwin/auto/Apache/include/modules/perl -I/Library/Perl/darwin/auto/Apache/include/include -I/Library/Perl/darwin/auto/Apache/include/regex -I/Library/Perl/darwin/auto/Apache/include/os/unix -I/usr/include/httpd -pipe -fno-common -no-cpp-precomp -fno-strict-aliasing -O3 -DVERSION=\0.9501\ -DXS_VERSION=\0.9501\ -I/Library/Perl/darwin/CORE -DMOD_PERL Peek.c Peek.xs: In function `DumpOP': Peek.xs:316: `GVOP' undeclared (first use in this function) Peek.xs:316: (Each undeclared identifier is reported only once Peek.xs:316: for each function it appears in.) Peek.xs:316: parse error before ')' token Peek.xs:318: parse error before ')' token ... --- ...and so on. Anyway, I can't even find GVOP in /Library/Perl/darwin/CORE/*.h, which makes me wonder if it's just plain incompatible with 5.8.0 (the docs don't seem to mention anything about it) -John
[OTish] Version Control?
Does anyone in the list use any kind of version control (e.g. CVS) for the perl/template codebase of their website? Now that my code base is growing I feel the increasing need to provide better version/backup control than my current hourly crontab tar. I don't however feel that the organizational logic of a websites code base fits well into the CVS paradigm. Am I being to short sighted in this assumption? Does anyone have any recommended method? I don't use version numbers at all? Does anyone? Richard.
Re: [OTish] Version Control?
We felt the same way but once we went to CVS we never looked back and can not imagine going with out source control. It may seem like the web doesnt fit that paradigm but if you break your modules up properly it works like a champ. We broke out into 'html','components', 'Libs','external_tools','internal_tools','perlinstall'. This gave us good control over each different area. For our development team its more about consistency then versioning. If you go all the way with it like we did you can give each developer a sandbox that they work in and CVS merges for you, it is a huge benefit. Its to the point now where you check out all the modules and run one script. That script builds all the perl dependancies, rebuilds your http daemon, rebuilds the proxies, configures the server for the platform its on based on hostname and installs all the relevant files. Every so often we bundle everything up into a tagged 'Release' and send it on its way to production. This works really well. A case in point was when we did our I18N conversion. We had one version of the code that was being entirely hacked apart to accomodate our changes but we still had to actively support bug fixes on the release. Without CVS[insert favorite source system here] this would have been impossible. So, without good CVS things like our I18N effort, our auto-install systems etc would have not been possible or been a LOT more painful. As it was we busted through it in record time. John- On Wed, 30 Oct 2002 21:09:05 + Richard Clarke [EMAIL PROTECTED] wrote: Does anyone in the list use any kind of version control (e.g. CVS) for the perl/template codebase of their website? Now that my code base is growing I feel the increasing need to provide better version/backup control than my current hourly crontab tar. I don't however feel that the organizational logic of a websites code base fits well into the CVS paradigm. Am I being to short sighted in this assumption? Does anyone have any recommended method? I don't use version numbers at all? Does anyone? Richard.
Re: [OTish] Version Control?
Richard, What's your operation system? Solaris or Linux? I use Solaris with CVS as the version control. It is very useful tool. You can also consider to use Solaris Package that is for installation and also the version control as well. Willy Richard Clarke [EMAIL PROTECTED]To: [EMAIL PROTECTED] cc: Subject: [OTish] Version Control? 10/30/2002 04:09 PM Does anyone in the list use any kind of version control (e.g. CVS) for the perl/template codebase of their website? Now that my code base is growing I feel the increasing need to provide better version/backup control than my current hourly crontab tar. I don't however feel that the organizational logic of a websites code base fits well into the CVS paradigm. Am I being to short sighted in this assumption? Does anyone have any recommended method? I don't use version numbers at all? Does anyone? Richard.
RE: [OTish] Version Control?
CVS is easy to use but confusing at first. Once you get used to it, you should not complain. I don't quite get your saying I don't however feel that the organizational logic of a websites code base fits well into the CVS paradigm. Isn't your files hierarchical? If so, why is CVS not fitting your purpose? Chang-Ping Hsiao -Original Message- From: Richard Clarke [mailto:ric;likewhoa.com] Sent: Wednesday, October 30, 2002 1:09 PM To: [EMAIL PROTECTED] Subject: [OTish] Version Control? Does anyone in the list use any kind of version control (e.g. CVS) for the perl/template codebase of their website? Now that my code base is growing I feel the increasing need to provide better version/backup control than my current hourly crontab tar. I don't however feel that the organizational logic of a websites code base fits well into the CVS paradigm. Am I being to short sighted in this assumption? Does anyone have any recommended method? I don't use version numbers at all? Does anyone? Richard. .
RE: [OTish] Version Control?
I've wondered about this too. Mainly, if you have multiple developers working with the same web server, how would you test your scripts without running into each other? it seems like CVS would work well if everyone was developing on his/her own box. Nate -Original Message- From: Hsiao, Chang-Ping [mailto:CHsiao;corp.untd.com] Sent: Wednesday, October 30, 2002 4:29 PM To: 'Richard Clarke'; [EMAIL PROTECTED] Subject: RE: [OTish] Version Control? CVS is easy to use but confusing at first. Once you get used to it, you should not complain. I don't quite get your saying I don't however feel that the organizational logic of a websites code base fits well into the CVS paradigm. Isn't your files hierarchical? If so, why is CVS not fitting your purpose? Chang-Ping Hsiao -Original Message- From: Richard Clarke [mailto:ric;likewhoa.com] Sent: Wednesday, October 30, 2002 1:09 PM To: [EMAIL PROTECTED] Subject: [OTish] Version Control? Does anyone in the list use any kind of version control (e.g. CVS) for the perl/template codebase of their website? Now that my code base is growing I feel the increasing need to provide better version/backup control than my current hourly crontab tar. I don't however feel that the organizational logic of a websites code base fits well into the CVS paradigm. Am I being to short sighted in this assumption? Does anyone have any recommended method? I don't use version numbers at all? Does anyone? Richard. .
Re: [OTish] Version Control?
Just give each developer their own sandbox. We have gone from : 1 Apache proxy/1 modperl server to 1 apache proxy / 1 modperl per developer running out of their homedirs to each developer gets their own proxy and modperl. If you tune your apache min/max server stuff this is quite doable. Sandboxes are key though, everyone works on their own stuff. John- On Wed, 30 Oct 2002 16:34:24 -0500 Nathan Hardt [EMAIL PROTECTED] wrote: I've wondered about this too. Mainly, if you have multiple developers working with the same web server, how would you test your scripts without running into each other? it seems like CVS would work well if everyone was developing on his/her own box. Nate -Original Message- From: Hsiao, Chang-Ping [mailto:CHsiao;corp.untd.com] Sent: Wednesday, October 30, 2002 4:29 PM To: 'Richard Clarke'; [EMAIL PROTECTED] Subject: RE: [OTish] Version Control? CVS is easy to use but confusing at first. Once you get used to it, you should not complain. I don't quite get your saying I don't however feel that the organizational logic of a websites code base fits well into the CVS paradigm. Isn't your files hierarchical? If so, why is CVS not fitting your purpose? Chang-Ping Hsiao -Original Message- From: Richard Clarke [mailto:ric;likewhoa.com] Sent: Wednesday, October 30, 2002 1:09 PM To: [EMAIL PROTECTED] Subject: [OTish] Version Control? Does anyone in the list use any kind of version control (e.g. CVS) for the perl/template codebase of their website? Now that my code base is growing I feel the increasing need to provide better version/backup control than my current hourly crontab tar. I don't however feel that the organizational logic of a websites code base fits well into the CVS paradigm. Am I being to short sighted in this assumption? Does anyone have any recommended method? I don't use version numbers at all? Does anyone? Richard. .
Re: [OTish] Version Control?
John, [EMAIL PROTECTED] wrote: We felt the same way but once we went to CVS we never looked back and can not imagine going with out source control. It may seem like the web doesnt fit that paradigm but if you break your modules up properly it works like a champ. We broke out into 'html','components', 'Libs','external_tools','internal_tools','perlinstall'. This gave us good control over each different area. For our development team its more about consistency then versioning. If you go all the way with it like we did you can give each developer a sandbox that they work in and CVS merges for you, it is a huge benefit. Its to the point now where you check out all the modules and run one script. That script builds all the perl dependancies, rebuilds your http daemon, rebuilds the proxies, configures the server for the platform its on based on hostname and installs all the relevant files. Every so often we bundle everything up into a tagged 'Release' and send it on its way to production. This works really well. A case in point was when we did our I18N conversion. We had one version of the code that was being entirely hacked apart to accomodate our changes but we still had to actively support bug fixes on the release. Without CVS[insert favorite source system here] this would have been impossible. Do you use CVS checkouts to upgrade the live system or do you this manually. i.e. stop apache, tar and remove old code, untar new code, start apache et voila? So, without good CVS things like our I18N effort, our auto-install systems etc would have not been possible or been a LOT more painful. As it was we busted through it in record time. John- Ric.
RE: [OTish] Version Control?
Hi Richard -- Does anyone in the list use any kind of version control (e.g. CVS) for the perl/template codebase of their website? Every time! My team has been developing web sites with CVS for years now. I can't imagine doing a web project without it! It would be like.. Oh... Skydiving without a parachute? Now that my code base is growing I feel the increasing need to provide better version/backup control than my current hourly crontab tar. I don't however feel that the organizational logic of a websites code base fits well into the CVS paradigm. Am I being to short sighted in this assumption? Does anyone have any recommended method? I don't use version numbers at all? Does anyone? Web development projects can map very nicely into CVS. We have a very mature layout for all web projects. In a nutshell, it boils down to this: project/ + apache/ + bin/ + cron/ + devdocs/ + htdocs/ + modules/ + templates/ The project/ directory is the CVS module, and is an identifier for the project on which we are working. So, if we were hired to re-develop all of Yahoo! in mod_perl (*grin*), the project directory might be yahoo/. A developer might check out a copy of the project with one command: $ cvs co yahoo All the other directories reflect the fact that every web site has meta content beyond htdocs -- Perl modules, template files, etc. Here is a run-down on the purpose of each directory: apache/- This directory contains a compiled Apache binary tree, complete with configuration files, shared libraries, etc. This, combined with CVS' branching and merging, has made upgrading Apache for our client's sites a breeze. bin/ - A directory for executable scripts and binaries related to the project. These may be sys-admin utilities for managing bits of the project or production web site. Every project ends up with a tool box of these. cron/ - Similar to bin/, this contains scripts and executables. Files in this directory are expected to be accessed via cron. I also put a copy of the crontab file here so that it, too, can be version controlled. Very useful. devdocs/ - Documentation! You have some of that, right? :-) Also included, any installation files (RPMs, packages, external source tarballs, etc.) needed by the project. htdocs/- The hypertext documents directory. This is the directory is mapped as the document root in your web server config. modules/ - Project Perl modules. Via the web server configuration, the PERL5LIB environment variable publishes the path to this directory so that your code can find what it needs. Besides the code we write for a given project, we also include *ALL* the CPAN Perl modules used for the project. It has been a long time since I've had to figure out which Perl modules are required for a web site. templates/ - We use HTML::Template, and this path contains all the external template files. (TT users can also use this structure.) Via the web server configuration, the environment variable HTML_TEMPLATE_ROOT publishes the path to this directory so that your code can find what it needs. Our environment is specifically designed to allow every developer, designer, QA specialist, project manager, and client to have their own completely independent, concurrent environment. CVS provides the glue for connecting these environments. Other than the occasional FTP binary/ASCII mode upload snafu, it is rare that developers on my projects step on each others' feet. FYI, we work exclusively on UNIX. Our work is split roughly 80/20, Linux/Solaris. Warmest regards, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
Re: [OTish] Version Control?
We use CVS to do in-place upgrades on the live system for smaller updates. For the big stuff we bring the boxes out of their pools one at a time and upgrade them. In both cases, the worse case is that a user might see two versions of the same page in the span of 60 seconds if they catch us in mid-update. John- On Wed, 30 Oct 2002 21:47:01 + Richard Clarke [EMAIL PROTECTED] wrote: John, [EMAIL PROTECTED] wrote: We felt the same way but once we went to CVS we never looked back and can not imagine going with out source control. It may seem like the web doesnt fit that paradigm but if you break your modules up properly it works like a champ. We broke out into 'html','components', 'Libs','external_tools','internal_tools','perlinstall'. This gave us good control over each different area. For our development team its more about consistency then versioning. If you go all the way with it like we did you can give each developer a sandbox that they work in and CVS merges for you, it is a huge benefit. Its to the point now where you check out all the modules and run one script. That script builds all the perl dependancies, rebuilds your http daemon, rebuilds the proxies, configures the server for the platform its on based on hostname and installs all the relevant files. Every so often we bundle everything up into a tagged 'Release' and send it on its way to production. This works really well. A case in point was when we did our I18N conversion. We had one version of the code that was being entirely hacked apart to accomodate our changes but we still had to actively support bug fixes on the release. Without CVS[insert favorite source system here] this would have been impossible. Do you use CVS checkouts to upgrade the live system or do you this manually. i.e. stop apache, tar and remove old code, untar new code, start apache et voila? So, without good CVS things like our I18N effort, our auto-install systems etc would have not been possible or been a LOT more painful. As it was we busted through it in record time. John- Ric.
RE: [OTish] Version Control?
Hi Richard -- Do you use CVS checkouts to upgrade the live system or do you this manually. i.e. stop apache, tar and remove old code, untar new code, start apache et voila? On single-server web sites (as opposed to a site running in a clustered environment) a CVS checkout works just fine. Once you get into a situation where you need to update multiple servers simultaneously you need another system. For sites with a modest amount of traffic and a smallish cluster, NFS works very well. For high-volume sites with a large cluster of servers I would use rsync. FYI, I used to be adverse to having a checked out CVS working directory on a production website, but I changed my tune on that years ago. Using CVS for distribution of changes into production is far easier, less prone to mistakes and downright efficient than distributing static files. CVS over SSH is also encrypted and secure. Just make sure to configure your web server to block access to CVS/ directories! TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
Re: Bricolage in eWeek
On Wednesday, October 30, 2002, at 12:53 PM, Aaron Johnson wrote: This weeks print version of eWeek as well as the online version have an article on Bricolage. article - http://www.eweek.com/article2/0,3959,652977,00.asp Bricolage - http://bricolage.thepritgroup.com Holy shit! This is the first I've heard of it! Nice article! I just have to write them to thank them and tell them the new URL... David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: [OTish] Version Control?
Hsiao, Chang-Ping wrote: CVS is easy to use but confusing at first. This could be the root of my reservations. Once you get used to it, you should not complain. I don't quite get your saying I don't however feel that the organizational logic of a websites code base fits well into the CVS paradigm. Isn't your files hierarchical? If so, why is CVS not fitting your purpose? Indeed, I don't get what I'm saying either. My organisation is something like (slightly over-simplified), _lib/Example/Control/section_a.pm _lib/Example/Control/section_b.pm _lib/Example/Control/section_c.pm _lib/Example/Config/section_a.pm _lib/Example/Config/section_b.pm _lib/Example/Config/section_c.pm _lib/Example/Model/section_c.pm _lib/Example/Model/section_c.pm _lib/Example/Model/section_c.pm _tmpl/section_a/view1.html _tmpl/section_a/view2.html _tmpl/section_a/view3.html _tmpl/section_b/view1.html _tmpl/section_b/view2.html _tmpl/section_b/view3.html _tmpl/section_c/view1.html _tmpl/section_c/view2.html _tmpl/section_c/view3.html I though CVS was more suited for something which looks more like _lib/Example/Section_a/Control _lib/Example/Section_a/Model _lib/Example/Section_a/View/1 _lib/Example/Section_a/View/2 _lib/Example/Section_a/View/3 etc i.e. more suited to a procedural orangisation than an object organisation Then again, like i said... perhaps my assumptions were too short sighted. Ric.
Re: Yahoo is moving to PHP ??
Rob Nagler wrote: I think Yahoo Stores is written in Lisp. I also believe it handles the front and back end. Would be interesting to know why this was left out of the discussion. Yahoo store was originally ViaWeb and was written in Common Lisp. It was one of the first large applications made available over the web. Paul Graham has an article about it at http://www.paulgraham.com/paulgraham/avg.html ViaWeb was deployed using clisp, a very portable, but somewhat incomplete, common lisp implementation that compiles lisp to bytecode. I believe (take this with a grain of salt, as it's third hand) that ViaWeb only presented dynamic content to the merchant, not to the user of the merchant's site- it was a web application that built static web sites. Each merchant had their own dedicated lisp listener to nteract with. This probably isn't the model that Yahoo had in mind, and it might not have occured to them that the commercial Lisps have native threads. Using clisp would also obscure one of the big advantages to using lisp- many lisp implementations compile to native code, so they're very efficient. Also, I'd imagine that you can hire just about any programmer to work on a PHP system; even if they haven't seen PHP before they'll pick it up quickly (once they get used to the weird reference semantics), and most of the work will be in learning the libraries. Graham's system uses macros extensively, and from other code of his that I've read (Graham wrote a couple of books about Lisp), I'd bet that he uses recursion and mapping functions a lot as well. I think it would be harder to hire people to work on his system (of course you'd probably also get more experienced people, so that might not be such a bad thing). Tagore Smith
Re: [OTish] Version Control?
On Oct 30 Richard Clarke wrote: Does anyone in the list use any kind of version control (e.g. CVS) for the perl/template codebase of their website? Using cvs, I'm not sure of an elegant way to update. I'm worried about CVS subdirectories sitting under htdocs, to be specific. Perhaps I just am not familiar enough with cvs. Perhaps there is an option that will supress the CVS that will ease rollouts. The specific comments given so far are great. On Oct 30 Jesse Erlbaum wrote: SSH is also encrypted and secure. Just make sure to configure your web server to block access to CVS/ directories! Also, Randal Schwartz wrote about cvs is a slightly more general setting: http://www.linux-mag.com/2002-07/perl_01.html Jim
Re: [OTish] Version Control?
Hear hear! We're using AxKit for our development and everyone has a copy of the entire site (many thousand files) in their home directories on the development machine and its been great! No more I didn't touch it but it stopped working problems :) It also allows everyone to experiment with features without messing up what anyone else is working on. Combine that with a series of perl scripts (also in cvs) which generate our bulk content (i.e. massive database dumps into xml files), Every so often we run a cvs update on our production machine to keep things in sync (we treat it just like another client). Go for it...its worth the trouble...especially the first time someone breaks something and you can determine who and when it was broken. Brian Wheeler [EMAIL PROTECTED] On Wed, 2002-10-30 at 16:30, [EMAIL PROTECTED] wrote: We felt the same way but once we went to CVS we never looked back and can not imagine going with out source control. It may seem like the web doesnt fit that paradigm but if you break your modules up properly it works like a champ. We broke out into 'html','components', 'Libs','external_tools','internal_tools','perlinstall'. This gave us good control over each different area. For our development team its more about consistency then versioning. If you go all the way with it like we did you can give each developer a sandbox that they work in and CVS merges for you, it is a huge benefit. Its to the point now where you check out all the modules and run one script. That script builds all the perl dependancies, rebuilds your http daemon, rebuilds the proxies, configures the server for the platform its on based on hostname and installs all the relevant files. Every so often we bundle everything up into a tagged 'Release' and send it on its way to production. This works really well. A case in point was when we did our I18N conversion. We had one version of the code that was being entirely hacked apart to accomodate our changes but we still had to actively support bug fixes on the release. Without CVS[insert favorite source system here] this would have been impossible. So, without good CVS things like our I18N effort, our auto-install systems etc would have not been possible or been a LOT more painful. As it was we busted through it in record time. John- On Wed, 30 Oct 2002 21:09:05 + Richard Clarke [EMAIL PROTECTED] wrote: Does anyone in the list use any kind of version control (e.g. CVS) for the perl/template codebase of their website? Now that my code base is growing I feel the increasing need to provide better version/backup control than my current hourly crontab tar. I don't however feel that the organizational logic of a websites code base fits well into the CVS paradigm. Am I being to short sighted in this assumption? Does anyone have any recommended method? I don't use version numbers at all? Does anyone? Richard.
Re: [OTish] Version Control?
Jim Martinez wrote: On Oct 30 Richard Clarke wrote: Does anyone in the list use any kind of version control (e.g. CVS) for the perl/template codebase of their website? Using cvs, I'm not sure of an elegant way to update. I'm worried about CVS subdirectories sitting under htdocs, to be specific. Perhaps I just am not familiar enough with cvs. Perhaps there is an option that will supress the CVS that will ease rollouts. The specific comments given so far are great. On Oct 30 Jesse Erlbaum wrote: SSH is also encrypted and secure. Just make sure to configure your web server to block access to CVS/ directories! Also, Randal Schwartz wrote about cvs is a slightly more general setting: http://www.linux-mag.com/2002-07/perl_01.html Jim I should have known better. Is there any topic he *hasn't* written an article on? Ric
RE: [OTish] Version Control?
Hey Jim -- Also, Randal Schwartz wrote about cvs is a slightly more general setting: http://www.linux-mag.com/2002-07/perl_01.html The system we use goes a bit beyond even what Randal describes (although, he is on a similar track). In a nutshell, the Apache httpd.conf file is templatized to replace elements such as the IP address, host name and path names with variables. To start the server for a particular environment the developer runs a Perl program which creates a custom httpd.conf
Re: [OTish] Version Control?
Hey Jim -- Also, Randal Schwartz wrote about cvs is a slightly more general setting: http://www.linux-mag.com/2002-07/perl_01.html The system we use goes a bit beyond even what Randal describes (although, he is on a similar track). In a nutshell, the Apache httpd.conf file is templatized to replace elements such as the IP address, host name and path names with variables. To start the server for a particular environment the developer runs a Perl program which creates a custom httpd.conf This is so close to what I recently put together one would have to worry about plagarism :-) I took it one step further, in that my setup script will configure not only the base http config files (for both proxy and app server), but also all the database configuration scripts, and application configurations. I did an install for a fellow developer today in about 5 minutes - complete proxy/app server config, build and populate database tables. I had to edit one file, which in turn was used to create the customized configuration files. I don't keep the base config files in CVS - yet. All source is in CVS, but I haven't got around to moving the config into CVS. Regarding deployment, I wrote a tool which goes into CVS and extracts tagged modules. The extracted code is placed into a tar archive with a few other files which indicate where the code is to be installed, plus a few other goodies. I can then give this deployment archive to our sysadmin who can simply type deploy --install the-file.dar and the code gets installed. We have separate deployment files for the perl libs, the Mason components, images, and a few other odds and ends. It works well, and it's very easy. Why a custom deploy tool? I didn't like the idea of using CVS on the production server, which is in a very tightly controlled environment. I doubt if I could have enticed the network folks to open the firewall to let CVS traffic through in any case Cheers! -klm.
Re: [OTish] Version Control?
Who needs network guys, reverse pop the ssh tunnel ;) I find it amazing that so many of us are doing the exact same thing in terms of managing our large site installs yet its nowhere to be found in any FAQ, knowledge base or general forum. I know on our side we developed these solutions over months and months on our own, dealing with problems at every step. Had there been a nice little FAQ on it, well, it would have saved us a ton of time :) I sense some writing.. John- On Wed, 30 Oct 2002 15:40:45 -0700 Ken Miller [EMAIL PROTECTED] wrote: doubt if I could have enticed the network folks to open the firewall to let CVS traffic through in any case Cheers! -klm.
hangs on $ENV{'QUERY_STRING'}
My apologies in advance if this is something that's been described
solved before... I can't seem to find the answer in archival searches
(maybe I'm just using the wrong terms).
At any rate, I have a fairly large script that I wrote when operating
under Apache 1.3, perl 5.8.0, Redhat 7.3. I'm now running Apache 2.0,
perl 5.8.0, and Redhat 8.0... and it stopped working when I performed
the upgrade.
Anywhere, what's happening is that the code below this paragraph is just
hanging...(on the second line, I've inserted a few print
'debugBR\n'; lines in the real thing to make sure.) it does finally
time out, without producing any output.
here's the relevant code:
$pass = /cgi-bin/plaintextresult.cgi?$ENV{'QUERY_STRING'};
print TD WIDTH='33%' ALIGN='CENTER' BGCOLOR='#22'A
HREF=\$pass\ target='printerfriendly'Plain text version/A/TD\n;
Thanks in advance, and again, sorry if this is a FAQ, I just couldn't
find the answer anywhere.
-Mike Forbes
[EMAIL PROTECTED]
RE: [OTish] Version Control?
Hi Jesse, I really like your approach, and appreciate your explanation. I'm wondering how you handle the packaging and installation; do you just use a shell script to put the different pieces where they belong, or have you devised something else? Right now I'm also using CVS for my web development, and have the modules built around ExtUtils::ModuleMaker. The server gets updated via the standard perl Makefile.PL make make test make install. My htdocs and templates are in their own dirs but in the same overall hierarchy as what ModuleMaker generates, and they get installed during the 'make install' part through some extra rules in the Makefile.PL files. Devdocs are all in POD, but I don't really have the bin and cron types of things from your system well integrated; they seem too peripheral to include with the 'make install' stuff. Of course another consideration is that I'm developing for an intranet, not deploying to external customers, so I have a lot more control of the production server. Wes Sheldahl Jesse Erlbaum [EMAIL PROTECTED] on 10/30/2002 04:47:41 PM To:[EMAIL PROTECTED] cc: Subject:RE: [OTish] Version Control? small excerpt from original post follows Web development projects can map very nicely into CVS. We have a very mature layout for all web projects. In a nutshell, it boils down to this: project/ + apache/ + bin/ + cron/ + devdocs/ + htdocs/ + modules/ + templates/ Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
DBD::Oracle/Windows2000 OK from prompt, not mod_perl?
Hi -
I'm having a problem on Windows 2000 where DBD::Oracle works fine from
perl on the command prompt but not from inside mod_perl. I think it is a
problem loading DLLs but I can't figure out what's different running under
mod_perl. The machine is running:
ActiveState perl 5.6.1 build 633
Apache 1.3.26 (prebuilt)
mod_perl 1.27_01-dev (Randy Kobe's build)
DBD-Oracle8 (ActiveState ppm)
From perl -de 0 on the command line (abbreviated output):
DB1 use DBI;
DB2 $dbh = DBI-connect(dbi:Oracle:db,user,passwd);
DB3 @rows = $dbh-selectrow_array(select * from dual);
DB4 x @rows
0 'X'
DB5 x $ENV{PATH}
0 'C:\\Perl\\bin\\;C:\\WINNT\\system32;C:\\WINNT;
C:\\WINNT\\System32\\Wbem;
C:\\Program Files\\Common Files\\Adaptec Shared\\System;
C:\\apps\\orant\\bin'
When I do the same thing in my handler (nothing in startup.pl), the first
request generates this error log message:
[Wed Oct 30 17:15:00 2002] [error] install_driver(Oracle) failed: Can't
load 'C:/Perl/site/lib/auto/DBD/Oracle/Oracle.dll' for module DBD::Oracle:
load_file:The specified module could not be found at
C:/Perl/lib/DynaLoader.pm line 206. Compilation failed in require at (eval
14) line 3.
Perhaps a required shared library or dll isn't installed where expected
and all subsequent requests generate these error log messages:
Use of inherited AUTOLOAD for non-method DBD::Oracle::ORA_OCI() is
deprecated at C:/Perl/site/lib/DBD/Oracle.pm line 48.
[Wed Oct 30 17:16:21 2002] [error] DBD::Oracle initialisation failed:
Can't locate auto/DBD/Oracle/ORA_OCI.al in @INC (@INC contains:
C:/Perl/lib C:/Perl/site/lib c:/apache/ c:/apache/lib/perl) at
C:/Perl/site/lib/DBD/Oracle.pm line 48
I've verified that the PATH in my handler matches what I see at the
prompt, and I know Oracle.dll exists. Occasionally (but not consistently)
Apache.exe will pop up an error dialog saying it couldn't find OCI.dll or
OCIW32.dll in my PATH, but the PATH it shows me in that dialog includes
C:\apps\orant\bin and those DLLs are in there.
Any help appreciated!
Thanks!
Larry Leszczynski
[EMAIL PROTECTED]
Re: Yahoo is moving to PHP ??
Tagore Smith writes: I think it would be harder to hire people to work on his system (of course you'd probably also get more experienced people, so that might not be such a bad thing). This raises the $64 question: If you could hire 10 PHP programmers at $50/hour or 4 Perl programmers at $125/hour, which team would deliver more business value over the life of the site? Graham's system uses macros extensively, and from other code of his that I've read (Graham wrote a couple of books about Lisp), I'd bet that he uses recursion and mapping functions a lot as well. His On Lisp book is a classic on macros--which are similar to closures in Perl. You can download it for free: http://www.paulgraham.com/onlisp.html My guess is that Graham's answer to the above question would be: Hire two Lisp programmers at $250/hour. :-) Rob
Re: DBD::Oracle/Windows2000 OK from prompt, not mod_perl?
Larry Leszczynski wrote: I'm having a problem on Windows 2000 where DBD::Oracle works fine from perl on the command prompt but not from inside mod_perl. I think it is a problem loading DLLs but I can't figure out what's different running under mod_perl. The machine is running: ActiveState perl 5.6.1 build 633 Apache 1.3.26 (prebuilt) mod_perl 1.27_01-dev (Randy Kobe's build) DBD-Oracle8 (ActiveState ppm) You can't just mix and match like that. Modules that you want to use under mod_perl have to be built against the same perl that mod_perl was built with. If there is a DBD::Oracle with Randy's distro, use it. Otherwise, you need to build DBD::Oracle with the same perl he used, or build mod_perl with ActiveState 633. - Perrin
RE: [OTish] Version Control?
At 04:47 PM 10/30/02 -0500, Jesse Erlbaum wrote: Web development projects can map very nicely into CVS. We have a very mature layout for all web projects. In a nutshell, it boils down to this: project/ + apache/ + bin/ That requires binary compatibility, though. I have a similar setup, but the perl and Apache are built separately on the target machine since my machines are linux and the production machine is Solaris. I only work on single servers, so things are a bit easier. I always cvs co to a new directory on the production machine and start up a second set of servers on high ports. That lets me (and the client) test on the final platform before going live. Then it's apache stop mv live old mv new live apache start kind of thing, which is a fast way to update. I'd love to have the Perl modules in cvs, though. Especially mod_perl modules. It makes me nervous upgrading mod_perl on the live machine's perl library. Should make more use of PREFIX, I suppose. Speaking of cvs, here's a thread branch: I have some client admin features that they update via web forms -- some small amount of content, templates, and text-based config settings. I currently log a history of changes, but it doesn't have all the features of cvs. Is anyone using cvs to manage updates made with web-based forms? -- Bill Moseley mailto:moseley;hank.org
RE: [OTish] Version Control?
Hi Richard -- Thanks for the extensive info, I am curious Assuming your website is made up different sections, would I be correct in assuming that the files this section depends on are finite? e.g. bin/section_a.sh cron/section_a.crontab template/section_a.html htdocs/section_a.pm Does CVS provide any ability to checkout the corresponding file from each section? I figure this would require a certain amount of developer supplied meta data so that CVS knew which files we part of which sections. Is this kind of thing supported. I'm not sure if I understand how you are using the word section here. The way I use CVS, I always check out ALL the files related to a project -- even those not related to the immediate task at hand. There is no advantage (at least not one I can see) for checking out only certain files. Finally, going completely off topic, does your choice of editor reflect your extensive usage of CVS say emacs with a cvs module? I don't think so. I actually use pico. (Don't bother making fun of me -- I've already been roasted by the best of 'em!) A number of my developers are emacs nuts, one uses vi (ouch!), and one uses a Windows-based editor and FTP. I imagine emacs has some sort of special CVS tie-in (it ties in everything else!), but it obviously isn't really important for basic CVS usage. TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
RE: [OTish] Version Control?
This could be the root of my reservations. Why do you think people always talk about re-organize? :-) Indeed, I don't get what I'm saying either. My organisation is something like (slightly over-simplified), _lib/Example/Control/section_a.pm _lib/Example/Control/section_b.pm _lib/Example/Control/section_c.pm _lib/Example/Config/section_a.pm _lib/Example/Config/section_b.pm _lib/Example/Config/section_c.pm _lib/Example/Model/section_c.pm _lib/Example/Model/section_c.pm _lib/Example/Model/section_c.pm _tmpl/section_a/view1.html _tmpl/section_a/view2.html _tmpl/section_a/view3.html _tmpl/section_b/view1.html _tmpl/section_b/view2.html _tmpl/section_b/view3.html _tmpl/section_c/view1.html _tmpl/section_c/view2.html _tmpl/section_c/view3.html I though CVS was more suited for something which looks more like _lib/Example/Section_a/Control _lib/Example/Section_a/Model _lib/Example/Section_a/View/1 _lib/Example/Section_a/View/2 _lib/Example/Section_a/View/3 etc i.e. more suited to a procedural orangisation than an object organisation In fact, CVS doesn't complain about how you organize your files. As long as they are in directories, CVS seems to work fine! Of course your organization needs to fit your needs -- for you to easily find what you want, but that's out of the scope of the CVS discussion. Chang-Ping .
Re: [OTish] Version Control?
We check in all of our perl modules into CVS and its a _MAJOR_ life saver. Keeps everyone on the same path so to speak. I don't believe in transfering _any_ binaries around, every binary recompiles on its new platform at install time. All modules, apache, external software etc. This eliminates those pesky little problems that pop up when you start pushing binaries. John- On Wed, 30 Oct 2002 14:58:01 -0800 Bill Moseley [EMAIL PROTECTED] wrote: At 04:47 PM 10/30/02 -0500, Jesse Erlbaum wrote: Web development projects can map very nicely into CVS. We have a very mature layout for all web projects. In a nutshell, it boils down to this: project/ + apache/ + bin/ That requires binary compatibility, though. I have a similar setup, but the perl and Apache are built separately on the target machine since my machines are linux and the production machine is Solaris. I only work on single servers, so things are a bit easier. I always cvs co to a new directory on the production machine and start up a second set of servers on high ports. That lets me (and the client) test on the final platform before going live. Then it's apache stop mv live old mv new live apache start kind of thing, which is a fast way to update. I'd love to have the Perl modules in cvs, though. Especially mod_perl modules. It makes me nervous upgrading mod_perl on the live machine's perl library. Should make more use of PREFIX, I suppose. Speaking of cvs, here's a thread branch: I have some client admin features that they update via web forms -- some small amount of content, templates, and text-based config settings. I currently log a history of changes, but it doesn't have all the features of cvs. Is anyone using cvs to manage updates made with web-based forms? -- Bill Moseley mailto:moseley;hank.org
RE: [OTish] Version Control?
Hi Wes -- I really like your approach, and appreciate your explanation. I'm wondering how you handle the packaging and installation; do you just use a shell script to put the different pieces where they belong, or have you devised something else? Something else! Files don't get installed all over the system -- they all stay together. We use environment variables (PERL5LIB, HTML_TEMPLATE_ROOT, etc.) set by the web server configuration to point to where the assets are stored. This assures that installing and upgrading doesn't involve managing a spider web of files all over the operating system. FYI, in production we typically create a UNIX user who owns all project files, and put all these files in that user's home directory. This simplifies management enormously. Right now I'm also using CVS for my web development, and have the modules built around ExtUtils::ModuleMaker. The server gets updated via the standard perl Makefile.PL make make test make install. Very cool! If you make conscience use of the built-in mechanism for regression testing for your web apps you will really have a fantastic software development factory. I don't really have the bin and cron types of things from your system well integrated; they seem too peripheral to include with the 'make install' stuff. Of course another consideration is that I'm developing for an intranet, not deploying to external customers, so I have a lot more control of the production server. The only difference here is that your job continues beyond the project, where our job (as contractors) generally scales down. IOW, if something unplanned comes up, you are probably going to be available to answer questions. If you can isolate all project related files to a single UNIX user you will have a tremendously portable and maintainable environment. For example, even the cron-processes on our sites run as the user who owns the project files. TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
Re: [OTish] Version Control?
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) [31 Oct 2002 09:47]: [...] I find it amazing that so many of us are doing the exact same thing in terms of managing our large site installs yet its nowhere to be found in any FAQ, knowledge base or general forum. I suspect a lot of us are so used to having everything in some sort of VCS that we take it for granted =) (RCS at work; CVS at home; both at uni; experimenting with perforce [which, so far, appears nicer than CVS] ) cheers, -- Iain.
RE: [OTish] Version Control?
Hi Bill -- project/ + apache/ + bin/ That requires binary compatibility, though. I have a similar setup, but the perl and Apache are built separately on the target machine since my machines are linux and the production machine is Solaris. Binary incompatibility is not a problem for us because we generally develop on the same platform on which the final code will run. I've been bitten enough times that I don't like to wait until the proverbial last minute to test my code on the target platform. Part of our job is to make sure that *all* the parts of the system work -- even those developed by the Apache Software Foundation. ;-) After all, my client isn't going to accept the excuse that our code is perfect -- it's that OTHER code! At the end of the day, if we recommend Apache (or any other third-party code), we are expected to stand by it. That said, if you have to support multiple platforms for any reason (a Solaris to Linux migration, for instance... Hehe) you are right -- extra work is involved. Perl has a nice structure for dealing with multiple architectures (arch library paths i686/, sun4/, etc.) but you will have to devise something else for application like Apache. I only work on single servers, so things are a bit easier. I always cvs co to a new directory on the production machine and start up a second set of servers on high ports. That lets me (and the client) test on the final platform before going live. Then it's apache stop mv live old mv new live apache start kind of thing, which is a fast way to update. I don't like any system which requires you to make any last minute changes. If you test on port 8080, there is no proof that you won't have problems when you move to port 80. What happens if a developer has clumsily hard-coded :8080 into a link to solve a problem in testing? I've seen it happen a thousand times, even to very smart programmers. If you have root access on the server you would be better off binding an additional IP address and running the stage server there, IMHO. I'd love to have the Perl modules in cvs, though. Especially mod_perl modules. It makes me nervous upgrading mod_perl on the live machine's perl library. Should make more use of PREFIX, I suppose. That is more or less how you do it. I have a module build process which allows me to build ALL modules in user space, isolated from the host operating system. If you put CPAN modules (including mod_perl) in CVS you will even be able to select versions. I've had forward-compatibility problems with CPAN modules in the past. Being able to run an old version of a library for one site, and a different version on the host machine is a really helpful thing. Note that if you want to put mod_perl in CVS you *have* to also put an Apache binary in mod_perl. There is no way around it. I've created an Apache mod_perl build process which automates compiling in user space: http://www.erlbaum.net/Apache-Perl-SSL/ HTH! Speaking of cvs, here's a thread branch: I have some client admin features that they update via web forms -- some small amount of content, templates, and text-based config settings. I currently log a history of changes, but it doesn't have all the features of cvs. Is anyone using cvs to manage updates made with web-based forms? Humm... You're talking about revision control on databases. That's a really difficult thing. In short, it's not possible to revision control a SQL database. If you have data which needs to be revision controlled put it in XML or in a Perl module. Another thing to add: Only files which are directly managed by a developer can be effectively managed in CVS. Files which are changed through a web form or an automated process are not candidates for CVS because the automation can't usually do important things like commit changes and resolve merge conflicts. I actually create a directory hierarchy outside of CVS, generally called EXTERNALS/, to store files which are managed through automation. TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
Re: [OTish] Version Control?
At 03:21 PM 10/30/02 -0800, [EMAIL PROTECTED] wrote: We check in all of our perl modules into CVS and its a _MAJOR_ life saver. Keeps everyone on the same path so to speak. I think I confused two different things: perl module source vs. installed modules. Do you check in the source or the installed modules? I keep the source of my perl modules under cvs, but not the perl library i.e. the files generated from make install, which might include binary components. I use a PREFIX for my own modules, but I tend to install CPAN modules in the main perl library. My own modules get installed in the application directory tree so that there's still a top level directory for the entire application/site. It does worry me that I'll update a CPAN module (or Apache::*) in the main Perl library and break something some day. (Although on things like updating mod_perl I have copied /usr/local/lib/perl5 before make install.) -- Bill Moseley mailto:moseley;hank.org
Re: DBD::Oracle/Windows2000 OK from prompt, not mod_perl?
Hi Perrin - I'm having a problem on Windows 2000 where DBD::Oracle works fine from perl on the command prompt but not from inside mod_perl. I think it is a problem loading DLLs but I can't figure out what's different running under mod_perl. The machine is running: ActiveState perl 5.6.1 build 633 Apache 1.3.26 (prebuilt) mod_perl 1.27_01-dev (Randy Kobe's build) DBD-Oracle8 (ActiveState ppm) You can't just mix and match like that. Modules that you want to use under mod_perl have to be built against the same perl that mod_perl was built with. If there is a DBD::Oracle with Randy's distro, use it. Otherwise, you need to build DBD::Oracle with the same perl he used, or build mod_perl with ActiveState 633. Hmmm, I was hoping that was not the case - all my other mod_perl stuff works fine, including libapreq stuff and SOAP::Lite, but maybe just by coincidence... Hey Randy, do you happen to have a DBD-Oracle build? (Btw, Randy deserves major kudos for maintaining his stuff at theory5x.winnipeg.ca!) Thanks, Larry Leszczynski [EMAIL PROTECTED]
Re: Yahoo is moving to PHP ??
Perrin Harkins wrote: They also have more of a need than most people to integrate with C/C++, and I've been told that it's easier to hack those into PHP. What a joke.
Re: Yahoo is moving to PHP ??
Cristóvão Dalla Costa wrote: Perrin Harkins wrote: They also have more of a need than most people to integrate with C/C++, and I've been told that it's easier to hack those into PHP. What a joke. Have you written C extensions for both Perl and PHP and think Perl is easier? Most people complain about XS being challenging. The picture might be different when SWIG and Inline::C are taken into account, but I've never used them so I couldn't say. In general, it makes sense that a simple language would be simple to extend with C. That's why people like TCL. - Perrin
Re: Yahoo is moving to PHP ??
* Perrin Harkins ([EMAIL PROTECTED]) [31 Oct 2002 14:26]: [...] Have you written C extensions for both Perl and PHP and think Perl is easier? I've only written XS for Perl. Not touched PHP with any C stuff. While I must admit that my early XS was crap, that's mostly my fault. Last time I looked at PHP, a while ago I admit, to extend it with C you had to recompile the lot. Has that changed? Most people complain about XS being challenging. XS isn't that challenging if you read the documentation. In particular, that shiny new Jenness and Cozens book Extending and Embedding Perl. The picture might be different when SWIG and Inline::C are taken into account, but I've never used them so I couldn't say. I find it's useful to know XS to use Inline::C. SWIG, since it's not Perl oriented, is possibly easiest. I'm not sure since I've not used it to any extent. In general, it makes sense that a simple language would be simple to extend with C. That's why people like TCL. They do? =) cheers, -- Iain.
Re: Yahoo is moving to PHP ??
Iain 'Spoon' Truskett wrote: In general, it makes sense that a simple language would be simple to extend with C. That's why people like TCL. They do? =) Sure. That's why Vignette used TCL: adding your own C commands to the language is easy. Probably the same story for AOLServer. - Perrin
Re: Yahoo is moving to PHP ??
Perrin Harkins wrote: Have you written C extensions for both Perl and PHP and think Perl is easier? Most certainly, using SWIG. I didn't have to recompile Perl two or three times, or read Perl's source to figure out what to do. The PHP docs on the subject were misleading and innacurate and wrong. That was about a year ago, I do hope things have improved.
Re: [OTish] Version Control?
Richard == Richard Clarke [EMAIL PROTECTED] writes: Richard Does anyone in the list use any kind of version control (e.g. CVS) for Richard the perl/template codebase of their website? Yup. Even wrote a column about it: http://www.stonehenge.com/merlyn/LinuxMag/col38.html -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
newbie:How to get form input in mod_perl 2 since Apache::request is not implemented yet ?
Hi all, I am a newbie to mod_perl and going straight to mod_perl 2. Have successfully written basic handler (API). Have not installed mod_perl 1.x Not using Apache::compat. ( Donot intend to use CGI.pm either ) In this case how to use methods from Apache::Request like $q-param() etc? I can get form data thru $r-read() but how to parse it ? Please point me to some documentation. have already checked perl.apache.org. Thanks in advance. Sumitro Chowdhury.Do you Yahoo!? HotJobs - Search new jobs daily now
[O] Re: Yahoo is moving to PHP ??
Let's prey that those PHP geeks quickly discover the true joy of working with functionnals (map and al.). I have often wondered about the ratio of Perl programmers still using the C-like for construct. I guess it's rather low. Franck. On Wed, 30 Oct 2002, Tagore Smith wrote: Rob Nagler wrote: I think Yahoo Stores is written in Lisp. I also believe it handles the front and back end. Would be interesting to know why this was left out of the discussion. Yahoo store was originally ViaWeb and was written in Common Lisp. It was one of the first large applications made available over the web. Paul Graham has an article about it at http://www.paulgraham.com/paulgraham/avg.html ViaWeb was deployed using clisp, a very portable, but somewhat incomplete, common lisp implementation that compiles lisp to bytecode. I believe (take this with a grain of salt, as it's third hand) that ViaWeb only presented dynamic content to the merchant, not to the user of the merchant's site- it was a web application that built static web sites. Each merchant had their own dedicated lisp listener to nteract with. This probably isn't the model that Yahoo had in mind, and it might not have occured to them that the commercial Lisps have native threads. Using clisp would also obscure one of the big advantages to using lisp- many lisp implementations compile to native code, so they're very efficient. Also, I'd imagine that you can hire just about any programmer to work on a PHP system; even if they haven't seen PHP before they'll pick it up quickly (once they get used to the weird reference semantics), and most of the work will be in learning the libraries. Graham's system uses macros extensively, and from other code of his that I've read (Graham wrote a couple of books about Lisp), I'd bet that he uses recursion and mapping functions a lot as well. I think it would be harder to hire people to work on his system (of course you'd probably also get more experienced people, so that might not be such a bad thing). Tagore Smith -- ESSENTIAL SOFTWARE - Ingénierie Informatique Solutions Linux Open Source en Polynésie française http://www.esoft.pf/ Tél: (689) 562 395 / 508 288-289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Lassé des virus? Osez Linux, le choix moderne des gouvernements et des entreprises Fortune 500
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: [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.
