Hello,
I hope someone can help me as I cannot find any info on how to solve my issue.
I'll try to make this short and sweet
I have a website which has french accents (i.e. é) and I noticed that
when a page uses mod perl in a cgi, the french accents are all messed
up in my browser.
But if I
Hi,
From: "Perrin Harkins" <[EMAIL PROTECTED]>
>
> I suspect you had one of the following problems:
>
> - Incorrectly configured template caching
I don't know too much about caching, but I have just configured TT to create
cached templates, so I have used cache.
> - Heavy use of method calls in
--- Geoffrey Young <[EMAIL PROTECTED]> wrote:
>
> DBD::Oracle needs these variables when DBD::Oracle
> is loaded. which means
> they need to be in %ENV _before_ the script that
> first use()s DBD::Oracle is
> loaded. httpd.conf is generally too late if you
> preload your modules via a
> startup.
> I've tried setting every standard Oracle environment
> variable in both httpd.conf (even using both SetEnv
> and PerlSetEnv) and in the script itself (NLS_LANG,
> ORACLE_HOME, LD_LIBRARY_PATH, ORACLE_SID). What am I
> missing?
DBD::Oracle needs these variables when DBD::Oracle is loaded. whi
--- Perrin Harkins <[EMAIL PROTECTED]> wrote:
>
> See PerlPassEnv:
>http://perl.apache.org/docs/1.0/guide/config.html#PerlSetEnv_and_PerlPassEnv
This didn't help, as expected since I already had the
PerlSetEnv in my httpd.conf file. PerlSetEnv sets and
passes the environment variables; but I did
--- "Philip M. Gollucci" <[EMAIL PROTECTED]> wrote:
> Thomas Hilbig wrote:
> >
>
$ENV{ORACLE_HOME}='/home/oracle/product/10.2.0/db_1';
> > $ENV{'ORACLE_SID'}="tomdb1";
> >
> >
>
$ENV{'LD_LIBRARY_PATH'}="/home/oracle/product/10.2.0/db_1/lib";
> > $ENV{'LD_ASSUME_KERNEL'} = "2.4.1" ;
> > $
On 7 Sep 2005, at 21:07, Perrin Harkins wrote:
On Wed, 2005-09-07 at 20:41 +0300, Octavian Rasnita wrote:
I have used Template-Toolkit, and the time used for parsing those
templates
used to double the whole time the program needed to run, so the
speed of
template parsing could be importan
On Wed, 2005-09-07 at 20:41 +0300, Octavian Rasnita wrote:
> I have used Template-Toolkit, and the time used for parsing those templates
> used to double the whole time the program needed to run, so the speed of
> template parsing could be important.
I suspect you had one of the following problems
I think %ENV is particular to each apache child, so you might be
"loosing" it because you're going to another
child process.
There are several modules that can help do this for you. I'm sure
someone here can help you with some names.
Otherwise you can look at using a database or flat file to s
I have used Template-Toolkit, and the time used for parsing those templates
used to double the whole time the program needed to run, so the speed of
template parsing could be important.
Teddy
- Original Message -
From: "Jonathan Vanasco" <[EMAIL PROTECTED]>
To: "mod_perl List"
Sent: We
Just to reiterate - the difference in templating time is very likely
negligible when you factor in your application logic.
ie:
on my tests a HTML::Template file interpolated in .00x, while a
HTML::Template::JIT interpolated in .000y
but my application logic takes .025 to work
.25x
and 3.07 is the most recent that handles the
>> latest mod_perl API changes.
>
> Since when, ... I thought it was 3.08 and some other stuff was fixed in
> 3.10.
oops :)
>
> Also, 3.11 is out :)
which is why I was a bit lazy about checking my versions :0
--Geoff
Geoffrey Young wrote:
Philip M. Gollucci wrote:
this feels like the start of a chunked response. something is awry
with the
buffering in the response... or somesuch IIRC :)
For reference the relevant code is: $query is a CGI.pm object
ah! make sure that CGI.pm is a recent version, then
Hola,
We're using apache/1.3.33 and mod_perl/1.29.
the problem is, a personal ENV variable is set in my
environment and read from a script like .
my $ENVNAME = $ENV{MY_PERSONAL_ENV} || 'STHELSE';
When the server is started a fresh, I can display my
ENV on my webpage but when I press refre
Philip M. Gollucci wrote:
>> this feels like the start of a chunked response. something is awry
>> with the
>> buffering in the response... or somesuch IIRC :)
>
> For reference the relevant code is: $query is a CGI.pm object
ah! make sure that CGI.pm is a recent version, then - versions less
On 9/7/05 11:28 AM, "raja agireddy" <[EMAIL PROTECTED]> wrote:
> Hello!
>
> I have modepler2.0,Apache2.0.53 ,Perl5.8 on Sun OS 5.9.
> I have successfully installed DBI 1.48 and currently in the process of
> installing DBD-Oracle-1.16.
>
> I am getting the following error while running "make test
raja agireddy wrote:
Hello!
I have modepler2.0,Apache2.0.53 ,Perl5.8 on Sun OS 5.9.
I have successfully installed DBI 1.48 and currently in the process of
installing DBD-Oracle-1.16.
You'd probably have better luck on dbi-users (at) perl.org
END
-
this feels like the start of a chunked response. something is awry with the
buffering in the response... or somesuch IIRC :)
For reference the relevant code is: $query is a CGI.pm object
sub guesscharset ($) {
my($html) = @_;
my $charset = undef;
local($`, $&, $', $1, $2, $3);
#
Hello!
I have modepler2.0,Apache2.0.53 ,Perl5.8 on Sun OS 5.9.
I have successfully installed DBI 1.48 and currently in the process of
installing DBD-Oracle-1.16.
I am getting the following error while running "make test" during
DBD::Oracle installation.
PERL_DL_NONLAZY=1 /home/gaccr1/fdmg/web2/
Joshua Ferraro wrote:
> Perrin et al,
>
> Thanks for the help thusfar. I upgraded MP2 to 2.0.1 from source.
> I'm still getting the same problems with statuses not working
> and header errors. Here's a snip from the log:
>
> [Tue Sep 06 17:10:34 2005] [error] [client 192.168.2.59] malformed he
On Tue, 2005-09-06 at 20:01 -0700, Thomas Hilbig wrote:
> It does not appear to be a permissions problem (I've
> run the httpd as User oracle), but turning on DBI
> tracing the problem does look like an environment
> variable problem. The ORACLE_HOME and other
> environment variables are not gettin
On Wed, 2005-09-07 at 15:34 +0300, Octavian Rasnita wrote:
> HTML::Template::Compiled also has some added features that HTML::Template
> and HTML::Template::JIT don't have.
>
> Unfortunately, HTML::Template::Compiled is not very well finished, so it
> doesn't give very helpful errors telling about
I have tested HTML::Template::Compiled and I found it as the fastest
templating system.
It is much much faster than Template-Toolkit, much faster than
HTML::Template, and faster than HTML::Template::JIT.
I have made the tests under Windows 2000.
I didn't use the Benchmark module for making this
> I removed your original patch and added this one then tested it under
> the two systems above. Looks good.
committed.
--Geoff
I would think that HTML::Template is faster, for the simple argument that it
does not need to parse the XSLT and XHTML, though the library may be
C-compiled.
- Original Message -
From: "Perrin Harkins" <[EMAIL PROTECTED]>
To: "Praveen Ray" <[EMAIL PROTECTED]>
Cc:
Sent: Tuesday, September
25 matches
Mail list logo
