Re: flush problem
I've heard that American Standard makes an excellent flusher. --Jon R. Udlei Nattis wrote: > $r->rflush() doesnt work too > > you have other idea? > bye > > nattis > > Stas Bekman wrote: > >> >> Yup, this doesn't work yet. Use $r->rflush() for now. >> >> >> __ >> Stas BekmanJAm_pH --> Just Another mod_perl Hacker >> http://stason.org/ mod_perl Guide ---> http://perl.apache.org >> mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com >> http://modperlbook.org http://apache.org http://ticketmaster.com >> >> >> > >
WebSphere and mod_perl
Has anyone run mod_perl apps on websphere yet? --Jon R.
Re: odd behavior of localtime
Without any real testing, may I suggest that the $date in the localtime
call be surrounded in parens? Whenever I have dealt with localtime, I
have found it to be finicky about that. Probably won't fix your current
problem, but can save you headaches later.
--Jon R.
Dermot Paikkos wrote:
> Hi
> I have the following sub in a script:
>
> use Apache::Constants qw(OK NOT_FOUND);
> use Apache::Request;
> use Apache::Template;
> use strict;
>
> 131 sub week {
> 132my $date = time();
> 133my ($monthday,$weekday,$yearday)=(localtime $date)[3,6,7];
> 134(my $weeknum) = int($yearday / 7) + 1;
> 135return ($weeknum,$yearday,$date,$monthday);
> 136 }
>
> I confess I stole it straight out of the perl cookbook - bighorn sheep -
> and it should return the week number of the year. It doesn't. $date is
> set but all the other vars are uninitialized (expect the + 1 of course)
> so I end up with the week as 1.
>
> I tried this as a snippet on its own and it works. I can't figure out why
> it doesn't with mod_perl. I was a bit unsure of whether $date =
> time(); should be scalar or an array but neither work.
>
> I have a feeling I am doing something (Dooh) stupid here. Can
> anyone spot a mistake?
> Thanx.
> Dp.
>
>
> ~~
> Dermot Paikkos * [EMAIL PROTECTED]
> Network Administrator @ Science Photo Library
> Phone: 0207 432 1100 * Fax: 0207 286 8668
>
>
>
Hiding perl code
Anyone know offhand a good way to hide your perl code when using mod_perl? Acme::Bleach isn't doing it - httpd is failing to start on initial test, and then on second test I find that httpd.conf suddenly got a 'use Acme::Bleach' inserted at line 1 and the whole thing is bleached. Perhaps perl2exe? --Jon R
Multiple apache servers/diff Ports
I am trying to create multiple instances of a large program we are working on. The apache server loads upwards of 10 modperl modules upon startup. I have duplicated all the modperl modules into a new directory structure with a new name, etc. and created a seperate set of confs for apache. The port I chose at random is 10010. The original copy was ALSO changed to include a version number, etc. in the dir structure. The one on port 80 works. The one on port 10010 does not. The only error I continually get is a permissions error. "You do not have permission to access http://localhost/dir/action"; (note the lack of port number) and a signature telling me the error is generated by Apache 1.13.x on Port 10010. (BTW - the 'action' is not a real file, but a command to be read by a handler module and interpreted - this system has no html files). Is it possible that the apache request object, etc. isn't passing the port number? I'm really stumped. If anyone has experience running multiple apache's loading modules, please let me know. The only thing the conf's share is an aliased directory. All the conf's are versioned, as well as the htdocs and perl modules. Jon Robison __ Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/
Re: Not embedding SQL in perl
I can see your arguement regarding SQL within one's code, but doesn't your arguement fail to hold up if we assume that the SQL is fully "compliant"? In other words, if the makers of WWWThreads had stuck with standard SQL, rather than using any non-standard features of MySQL like last inserted ID, wouldn't their code be useable on Oracle, for example (assuming we changed the correct var to tell DBI we are using Oracle now) ? Just trying to make sure I understand what all the fuss is about. Jon R. [EMAIL PROTECTED] wrote: > > > Original Message > Subject: Re: Not embedding SQL in perl > Date: Wed, 01 Aug 2001 15:56:00 -0400 > From: kyle dawkins <[EMAIL PROTECTED]> > To: Henrik Edlund <[EMAIL PROTECTED]> > References: <[EMAIL PROTECTED]> > > > > Henrik Edlund wrote: > >> And while we are discussing "not cutting corners", those who still use >> MySQL should switch to a real DBMS before they even think of abstracting >> the SQL away from their Perl code. >> >> That people still use MySQL really shows how many lusers there are with >> computers that try to develop real software. I said _try_. >> >> *sigh* >> > > Henrik > > Not sure if you're aware of it, but that argument is pretty old. We're > onto a much more interesting, new argument now. :-) > > Seriously though, you're right, MySQL is not a "real" RDBMS. No > transactions, no foreign key constraints, no stored procedures. It is, > however, free, and in use in a lot of places. And interestingly enough, > in a way that makes the current argument even MORE important; writing > SQL into your code (as per the current thread of discussion) will make > it exponentially more difficult for you to move to a "real" RDBMS as > Henrik urges you to. If you abstract DB access into a middleware layer, > you will have a much, much easier time. By placing SQL into your > application code, you are removing the flexibility of changing your > persistence mechanism at a later date. And believe it or not, that's > not as uncommon as you might think. > > I cite the example of wwwthreads here... it's a great BBS, runs under > mod_perl, is fast, and has a DB backend. However, the source is > LITTERED with SQL, and everywhere there's a line of SQL, the dude has to > put an "if" conditional around it to check if the installation is using > MySQL or something else, because MySQL has numerous features that are > not found elsewhere (last inserted id, REPLACE command, LIMIT m,n)... > so, twice the number of SQL statements in code that (in my opinion) > should not have any SQL in it at all... > > It's all food for thought (I hope). > > Kyle > Software Engineer > Central Park Software > http://www.centralparksoftware.com
