Michael hall wrote:
You make me sound ancient :-) When I started at the UofM (1971) it was
Fortran 77 [...]
^^
Eh? :-)
Fortran IV, maybe.
theory, algorithms, style, etc., just dry examples out of text books.
Lot of good any of that
On Sun, 7 May 2000, Frank Mayhar wrote:
Perl does have some good constructs for Web work, too. I've been writing
a webstore and some stuff is really convenient that would be inconvenient
in C. On the other hand, there's some stuff that I just wouldn't use Perl
for, like, say, a system
John D Groenveld wrote:
-Xa is a Sun WorkShop Compiler C 4.2 option,
-X[a|c|s|t]
Specifies the degree of conformance to the ANSI C stan-
dard. Specifies one of the following:
a (ANSI)
ANSI C plus KR C compatibility extensions, with
On Sun, 7 May 2000, Jeff Stuart wrote:
[...rest of message deleted...]
Every language has it use, the truly knowledgeable understand when to
use each language:)
Sam
Amen to that!!! I think that this point and the point about writing GOOD
algorithms are VERY important ones and I think
At 08:55 AM 5/8/00 +0100, Matt Sergeant wrote:
On Sun, 7 May 2000, Jeff Stuart wrote:
[...rest of message deleted...]
Every language has it use, the truly knowledgeable understand when to
use each language:)
Sam
Amen to that!!! I think that this point and the point about writing
On Mon, May 08, 2000 at 08:55:56AM +0100, Matt Sergeant wrote:
On Sun, 7 May 2000, Jeff Stuart wrote:
[...rest of message deleted...]
Every language has it use, the truly knowledgeable understand when to
use each language:)
Sam
Amen to that!!! I think that this point and the
At 01:44 AM 5/8/00 +, [EMAIL PROTECTED] wrote:
On Mon, May 08, 2000 at 08:55:56AM +0100, Matt Sergeant wrote:
On Sun, 7 May 2000, Jeff Stuart wrote:
[...rest of message deleted...]
Every language has it use, the truly knowledgeable understand when to
use each language:)
For GUI programming, I think a "beautiful" object design is
exceptionally important. But once you leave the GUI space, you've
left the area where "beautiful" object designs add much benefit. Most
of us programmers are relagated to things that are less beautiful, but
rather functional.
-Original Message-
From: Doug MacEachern [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 05, 2000 6:22 PM
To: Geoffrey Young
Cc: 'Pierre J. Nicolas'; [EMAIL PROTECTED]
Subject: RE: Newbie Question -
mod_perl overrides the perl print() function - print()ing to STDOUT
Take a look at the updated graph of the mod_perl growth:
http://perl.apache.org/netcraft/
Pay attention to the ramp!
BTW, Apache holds 61.53% of the server market share!!!
http://www.netcraft.co.uk/survey/
__
Stas Bekman
Stas Bekman wrote:
Take a look at the updated graph of the mod_perl growth:
http://perl.apache.org/netcraft/
Pay attention to the ramp!
BTW, Apache holds 61.53% of the server market share!!!
http://www.netcraft.co.uk/survey/
guess accuracy=wild
Does this have as much to do with the
Hi,
How do I get ENV variables values in my PerlTransHandler. I want to
know
the HTTP_USER_AGENT in my PerlTransHandler.
Please suggest me.
Get Your Private, Free E-mail from MSN Hotmail
Hi Stas,
On Mon, 8 May 2000, Stas Bekman wrote:
Take a look at the updated graph of the mod_perl growth:
http://perl.apache.org/netcraft/
Pay attention to the ramp!
BTW, Apache holds 61.53% of the server market share!!!
So it's gone down a bit then??
73,
Ged.
Does this have as much to do with the growth of the 'net as with the
popularity of mod_perl
/guess
Unless the growth of websites has doubled in 2000, no. Which is
well..., unlikely. The number of sites that netcraft surveyed might
have doubled in the last 4 months though..., that is
On Mon, 8 May 2000, G.W. Haywood wrote:
Hi Stas,
On Mon, 8 May 2000, Stas Bekman wrote:
Take a look at the updated graph of the mod_perl growth:
http://perl.apache.org/netcraft/
Pay attention to the ramp!
BTW, Apache holds 61.53% of the server market share!!!
So it's
Tim:
Mod_perl isn't going to grow if Apache doesn't grow if the Web doesn't
grow if the Internet doesn't grow... at least, not until technologies
start eating into each other's pre-installed base. And that's a hard
thing to do.
However, what Stas was pointing out was the explosive growth of
Suddenly, Tim Sweetman uttered:
Stas Bekman wrote:
Take a look at the updated graph of the mod_perl growth:
http://perl.apache.org/netcraft/
Pay attention to the ramp!
BTW, Apache holds 61.53% of the server market share!!!
http://www.netcraft.co.uk/survey/
guess
I don't mean to rain on the parade, but...
The more important number would be to look at the number of unique IPs,
which has only moderately grown. I installed mod_perl this weekend on my
main server to start testing it, etc. Netcraft, of course, reports that
I've got mod_perl, which may be
On Mon, 8 May 2000, Mark D Wolinski wrote:
I don't mean to rain on the parade, but...
The more important number would be to look at the number of unique IPs,
which has only moderately grown. I installed mod_perl this weekend on my
main server to start testing it, etc. Netcraft, of
Stas Bekman wrote:
Cool! I guess it's a non-documented feature :)
it's documented in ch9 of the eagle book :)
If it is, consider it documented in the next version of the Guide :)
I'm looking at page 456 right now, and from my newbie perspective, I
conclude it's mostly documented. :-)
Adi wrote:
Jim Winstead wrote:
On May 05, Adi wrote:
You can still use CGI.pm from within mod_perl (and you should). There is
nothing better at handling data passed from a browser via HTTP POST and/or
GET. If you currently use CGI.pm, I think you'll find that a lot of your
This is a new one on me. mod_perl is built with APXS and perl is built
with -DDL_UNLOAD_ALL_AT_EXIT, so it isn't coredumping during startup,
but it cores the first time an access is made. Anyone have any
suggestions?
=[1] perl_header_parser(0xd9480, 0xff16ca04, 0xa, 0xd9480, 0x2f707269,
Matt Sergeant wrote:
On Sun, 7 May 2000, Frank Mayhar wrote:
Perl does have some good constructs for Web work, too. I've been writing
a webstore and some stuff is really convenient that would be inconvenient
in C. On the other hand, there's some stuff that I just wouldn't use Perl
for,
I apologize immediately if this is not the proper forum for this
question, however I have a Perl CGI I am running on a Apache based
server, and the script is known to work properly however when I look at
the file it has a size of ZERO...meaning the file name appears in the
directory it
We have a setup where an Alpha provided DBMS and
content services to the actual web server front-ends.
What I would like to know is how I can get all these 4
web servers to write to one log file? Would using something
apache DBILogger be the way to go?
-ar
Angel R. Rivera, [EMAIL PROTECTED]
http://www.virtualschool.edu/lang/perl/CuteTricksPerlApache.html#Logging_to_
syslog
o _
/|/ | Jerrad Pierce \ | __|_ _|
/||/ http://pthbb.org . | _| |
\|| _.-~-._.-~-._.-~-._@" _|\_|___|___|
According to Jeffrey W. Baker:
I keep meaning to write this up as an Apache:: module, but it's pretty trivial
to cons up an application-specific version. The only thing this doesn't
provide is a way to deal with large data structures. But generally if the
application is big enough to
I've been tyring for the past several days to stop the
infamous "Undefined Subroutine" messages. I implemented
"solution 2" by adding a "require" statement in all of my scripts.
That still didn't do it.
However, I just started using "do" and everything is working fine now.
I know that "do"
Hi,
I am building an apache web server for serveral operating
systems: Solaris, HPUX, AIX and Windows NT.
My apache is based on:
apache_1.3.12/
openssl-0.9.4/
mod_ssl-2.6.2-1.3.12/
ApacheJServ-1.1/
I'm running into something kind of strange...
On a fresh restart of apache, my processes are about 20 ~ 25 MB each, which is
about normal for mod_perl (as far as I know). However, within a few hours
(with little use except by our development team), the size is up to 40MB, and
by the end of the
I've avoided session management like the plague until now (intranets
let you get away with that sort of thing :)) but rolling out web-based
LDAP is forcing session management upon me.
Other than Apache::Session what are my choices?
Build your own...
How well do any of
these play with
We are using HTML::Mason and Apache::Session with great results.
Apache::Session::DBI was killing us for some reason but moving it to
our network appliance box and Apache::Session:File has really pumped
up our performance. When you really start using sessions you can get
some cool stuff out
On Mon, May 08, 2000 at 11:41:39AM -0700, Stephen Zander wrote:
I've avoided session management like the plague until now (intranets
let you get away with that sort of thing :)) but rolling out web-based
LDAP is forcing session management upon me.
Other than Apache::Session what are my
On Mon, 8 May 2000, Steve Bauer wrote:
I have apache 1.3.12, and mod_perl 1.23. both apache and mod_perl build
successfully, but make test fails. the output from "make test" is:
cp t/conf/mod_perl_srm.conf t/conf/srm.conf
../apache_1.3.12/src/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t
The file t/logs/error_log is never created. httpd fails because
/t/conf/httpd.conf looks more like a pod file than a httpd.conf.
How is the correct httpd.conf file supposed to be created?
What can I do to determine why the creation is not happening??
Steve Bauer
Stas Bekman wrote:
On
The URL
http://www.masonhq.com/download/HTML-Mason-0.85.tar.gz
has entered CPAN as
file: $CPAN/authors/id/J/JS/JSWARTZ/HTML-Mason-0.85.tar.gz
size: 256559 bytes
md5: 430067fc80d7194292b4e5c00f01da2b
Mason is a component-based web site development system with caching,
On Mon, 8 May 2000, Steve Bauer wrote:
The file t/logs/error_log is never created. httpd fails because
/t/conf/httpd.conf looks more like a pod file than a httpd.conf.
That's fine.
How is the correct httpd.conf file supposed to be created?
What can I do to determine why the creation is
I've expirienced similar problems on Solaris (2.6). After a weeks worth of
hours I feel confidant saying that the instability is from perl 5.6.0 NOT
from mod_perl(1.23)
Problems resulting from the Sys::Syslog created problems for other modules
that relied on things like Net::Daemon and PlRPC
On Mon, 8 May 2000, Leslie Mikesell wrote:
According to Jeffrey W. Baker:
I keep meaning to write this up as an Apache:: module, but it's pretty trivial
to cons up an application-specific version. The only thing this doesn't
provide is a way to deal with large data structures. But
On 08-May-2000 [EMAIL PROTECTED] wrote:
I AM NOT AN EXPERT. Which is why I didn't post to the list.
I just happened to notice your question, and since everyone
seems to be out to lunch, I though I'd give it a whack.
Thanks... I'm a quite new to mod_perl as well, and on some of the things I
CN=Jeff [EMAIL PROTECTED] on 05/08/2000 03:43:00 PM
Sent by: [EMAIL PROTECTED]
Sent From the mail file of: Jeff Bulley
To: [EMAIL PROTECTED]
cc:
Subject: Re: apache1.3.12, modperl1.23, perl5.6, ApacheJServ1.1,
OpenSSL0.9.4, modssl
Hmm.
We've had very different relations
: On Mon, 8 May 2000, Leslie Mikesell wrote:
:
: According to Jeffrey W. Baker:
:
:I keep meaning to write this up as an Apache:: module, but it's
pretty trivial
:to cons up an application-specific version. The only thing this
doesn't
:provide is a way to deal with large data
Some more info: I've rebuilt everything with debug, and the SEGV is
happening in mod_perl.c in the following code:
#ifdef PERL_HEADER_PARSER
int PERL_HEADER_PARSER_HOOK(request_rec *r)
{
dSTATUS;
dPPDIR;
#ifdef PERL_INIT
PERL_CALLBACK("PerlInitHandler",
On Mon, 8 May 2000, Leslie Mikesell wrote:
On my sites, I use the session as a general purpose data sink. I find
that I can significantly improve user experience by keeping things in the
session related to the user-site interaction. These session object
contain way more information
On Mon, 8 May 2000, Wim Kerkhoff wrote:
On a fresh restart of apache, my processes are about 20 ~ 25 MB each,
which is about normal for mod_perl (as far as I know). However,
within a few hours (with little use except by our development team),
the size is up to 40MB, and by the end of the day
On Mon, 8 May 2000, Pierre J. Nicolas wrote:
I've been tyring for the past several days to stop the
infamous "Undefined Subroutine" messages. I implemented
"solution 2" by adding a "require" statement in all of my scripts.
That still didn't do it.
Why do you have this problem in the first
You're probably doing something that is causing certain variables to have
temporarily large values. As always, start with the guide:
http://perl.apache.org/guide/performance.html#Memory_leakage
You should also make sure you're doing the usual pre-loading and other
suggestions from this
At 10:13 PM 5/8/00 +0100, Greg Cope wrote:
: On Mon, 8 May 2000, Leslie Mikesell wrote:
:
: According to Jeffrey W. Baker:
:
:I keep meaning to write this up as an Apache:: module, but it's
pretty trivial
:to cons up an application-specific version. The only thing this
doesn't
:
Hi,
As far as I knew Apache::Session has never even had anything to
do with cookies. It is a persistent storage mechanism where the
session "handle" is uniquely generated ID.
and where do you think the session ID is kept?
yup. right. in a cookie.
Rgds,
Tfr
--== [EMAIL PROTECTED] ==
49 matches
Mail list logo
