On Thu, 20 May 2004, Geoffrey Young wrote:
> a release candidate for mod_perl 1.99_14 is now available for testing.
>
> please grab the candidate from
>
> http://perl.apache.org/~geoff/mod_perl-1.99_14-dev.tar.gz
>
> and report back successes or failures. when reporting
> failures, please see t
On May 19, 2004, at 9:02 PM, Geoffrey Young wrote:
a release candidate for Apache-Test 1.11 is now available.
http://perl.apache.org/~geoff/Apache-Test-1.11-dev.tar.gz
please take the time to excercise the candidate through all your
existing
applications that use Apache-Test and report back succ
Good news, Jamie Lokier reported a speed problem with perl_clone, and he and
Dave Mitchell now have a speedup fix for interpreter cloning.
Not sure how significant the speedup is, but any speedup counts in the current
situation where perl_clone is painfully slow. Hopefully the fix will make it
i
blargh - cut and paste error. the subject should read Apache-Test-1.11.
--Geoff
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
a release candidate for Apache-Test 1.11 is now available.
http://perl.apache.org/~geoff/Apache-Test-1.11-dev.tar.gz
please take the time to excercise the candidate through all your existing
applications that use Apache-Test and report back successes or failures.
--Geoff
Changes since 1.10:
a release candidate for mod_perl 1.99_14 is now available for testing.
please grab the candidate from
http://perl.apache.org/~geoff/mod_perl-1.99_14-dev.tar.gz
and report back successes or failures. when reporting failures, please see
the bug reporting guidelines at
http://perl.apache.org/
On Wed, 2004-05-19 at 18:53, Dave Boodman wrote:
> PK wasn't the problem. If you don't define it, it uses the first col.
And that is the correct primary key for this table?
> The return from the ->search looks like
>
> $VAR1 = \bless( {
> 'sysid' => '158'
>
On Wed, 2004-05-19 at 18:08, Dave Boodman wrote:
> breakthrough!
Cool!
> focusing on the view code here:
>
> this doesn't work:
>
> foreach my $obj (Lib::Systems->search(cid=>$cid)) {
> my %e = map { $_ => $obj->$_ } Lib::Systems->columns;
> push @out, \%e;
> }
>
>
sorry, I meant Class:DBI's search function.
At 03:08 PM 5/19/2004, Dave Boodman wrote:
breakthrough!
focusing on the view code here:
this doesn't work:
foreach
my $obj (Lib::Systems->search(cid=>$cid)) {
my %e = map { $_ => $obj->$_ } Lib::Systems->columns;
push @out, \%e;
breakthrough!
focusing on the view code here:
this doesn't work:
foreach my $obj (Lib::Systems->search(cid=>$cid)) {
my %e = map { $_ => $obj->$_ }
Lib::Systems->columns;
push @out, \%e;
}
this does:
my
$db = Lib::Systems->dbh;
my $sth = $db->prepare("select *
On Wed, 2004-05-19 at 14:28, Dave Boodman wrote:
> Only a small % of the children consistently get it wrong. The rest,
> including the one that made the insert, get it right. Restarting the server
> always sets all children straight.
That makes it sound like you have a scoping issue in your code
Joshua Keroes wrote:
I'm having some trouble getting the MasonHQ SiteSource code to run.
This is what happens when I fire up Apache.
[EMAIL PROTECTED]:/usr/local/anansi$ sudo bin/svrctl start dev
Password:
starting dev
[Wed May 12 09:40:17 2004] [error] Can't call method
"register_cleanup"
on an
[EMAIL PROTECTED] wrote:
Hi
Perl Version: Any version after 5.005 (Tested on 5.8.0)
mod_perl Version: 1.27
Apache Version: 1.3.27
With the assistance of IBM we may have highlighted a possible bug within mod_perl/perl.
The problem started as we could not load the IBM Websphere 5 Apache plugin if mo
Randy Kobes wrote:
On Wed, 19 May 2004, Joel wrote:
[...]
waiting 120 seconds for server to start: .Syntax error on line 704 of
/usr/local/src/mod_perl-1.99_13/t/conf/httpd.conf:
Invalid command 'SetEnv', perhaps mis-spelled or defined by a module not
included in the server configuration
So the rel
Rob Mueller wrote:
Ok, I've tracked this down a bit more, and I think it's a perl problem.
Basically it seems tainted variables and utf-8 don't work together. I did
find one example of someone posting the same problem:
http://groups.google.com/groups?q=taint+group:perl.unicode&hl=en&lr=&ie=UTF-8&gr
Good, you're narrowing it down. If a different child handles the edit and
the view, is it always wrong? You can simulate this when running in -X by
doing the edit, then stopping and restarting the server, then doing the view.
Only a small % of the children consistently get it wrong. The rest,
Ok, I've tracked this down a bit more, and I think it's a perl problem.
Basically it seems tainted variables and utf-8 don't work together. I did
find one example of someone posting the same problem:
http://groups.google.com/groups?q=taint+group:perl.unicode&hl=en&lr=&ie=UTF-8&group=perl.unicode&s
On Wed, May 19, 2004 at 09:40:41AM -0400, Geoffrey Young wrote:
> my $dbh = DBI->connect('dbi:Oracle:HELM', 'user', 'password');
>
>
>
> local $dbh->{AutoCommit} = 0;
> local $dbh->{PrintError} = 0;
>
One good use for local as if you just set the attribute the handle gets corrupted for
i
On Wed, 19 May 2004, Joel wrote:
> Forgive me if this has already been reported. I could not find any
> references to it in the archives.
>
> --Joel
>
> -8<-- Start Bug Report 8<--
> 1. Problem Description:
>
> 'make test' fails while initializing the apache
Perrin Harkins wrote:
> Geoffrey Young wrote:
>
>> as for the the different DBI strings, are you using a post 5.8.0 perl? I
>> have suspected that the random hash foo in 5.8.1 (or whenever it was
>> added,
>> I forget) would muck up Apache::DBI's caching mechanism.
>
>
> No, the hash keys are
Geoffrey Young wrote:
as for the the different DBI strings, are you using a post 5.8.0 perl? I
have suspected that the random hash foo in 5.8.1 (or whenever it was added,
I forget) would muck up Apache::DBI's caching mechanism.
No, the hash keys are sorted.
- Perrin
--
Report problems: http://perl
please keep responses on list so everyone can benefit from the archives :)
[EMAIL PROTECTED] wrote:
> I am exploring this right now. The problem though is the explosion of
> connections. we go from 100->600 in about 2 minutes. We can't
> correlate it to the load, and I can't find anywhere that
[EMAIL PROTECTED] wrote:
> We are having a problem with the oracle sessions running wild. We
> have five web servers that run 6 servers.
> StartServers 6
> MaxClients 32
according to the your settings you _start_ 6 servers (well, child
processes). you allow up to 32 processes (each with it'
Forgive me if this has already been reported. I could not find any
references to it in the archives.
--Joel
-8<-- Start Bug Report 8<--
1. Problem Description:
'make test' fails while initializing the apache server for testing. Here
are the results of the
Hi
Perl Version: Any version after 5.005 (Tested on 5.8.0)
mod_perl Version: 1.27
Apache Version: 1.3.27
With the assistance of IBM we may have highlighted a possible bug within mod_perl/perl.
The problem started as we could not load the IBM Websphere 5 Apache plugin if mod_perl
was enabled. (
Hello!
You are right! Double copy is a bad idea and mod_xslt should be fixed.
I can't provide path for mod_xslt now because it's already hacked for my
needs. May be later. The author of mod_xslt didn't answer at all.
Best regards,
/grig
-Original Message-
From: Stas Bekman [mailto:[EMAIL
Rob Mueller wrote:
[...]
Ok, so to summarise, I think I see two problems here:
1. Assigning an untainted value to a value that was previously tainted
leaves the new value tainted
It's hard to tell or even try to reproduce that, since you didn't show a real
test case. What kind of variable is that?
Hello,
I am comming back on the client IP address problem that I have.
On my HPux system, I could reproduce the problem with a small program that listen on a socket and try to print remote address.
Depending on compilation mode, the field that store the address length doesnt have the same type.
28 matches
Mail list logo