On Sat, 20 May 2000, Thomas wrote:
> hi,
> I've run into some oddities..
> running nmake test causes to seriously crash
> at "internal/table" while the same test with 1.22 passes fine.
> Test "internal/api" FAILS for both 1.22 / 1.24
>
> Both are compiled with identical setups using VC6 / WinN
hi,
I've run into some oddities..
running nmake test causes to seriously crash
at "internal/table" while the same test with 1.22 passes fine.
Test "internal/api" FAILS for both 1.22 / 1.24
Both are compiled with identical setups using VC6 / WinNT
with the 1.3.12 / 5.00503 libs .
suggestions, a
I am having a problem getting mod_perl to actually load under apache (as a
DSO) on BSDi/4.1... it appears that (even though the file exists in the
proper location) it cannot find libperl.so. I double/triple checked that
libperl.so is in the proper location, and I have followed the recommendation
> "Edgardo" == Edgardo Szulsztein <[EMAIL PROTECTED]> writes:
Edgardo> Then, I tried to use FileStore, and it worked
Edgardo> fine. However, it stores the sessions files in the /tmp
Edgardo> directory. How could I change the location of the sessions
Edgardo> file in the httpd
On Fri, 19 May 2000, David Larkin wrote:
> Can anyone help explain why PERL gives such a large memory
> footprint & advise how to get around it.
Your array might be smaller if you pre-extend it to the size you need (see
perldata). You could also look at some of the sneaky bit vector modules
on C
On Fri, 19 May 2000, David Larkin wrote:
> Can anyone help explain why PERL gives such a large memory
> footprint & advise how to get around it.
>
> Running the simple script below, I get a footprint of 63 MB
> about 22 bytes per int.
>
> The C program only 11748 K ... 4 bytes per int
>
>
> #
Can anyone help explain why PERL gives such a large memory
footprint & advise how to get around it.
Running the simple script below, I get a footprint of 63 MB
about 22 bytes per int.
The C program only 11748 K ... 4 bytes per int
#!/usr/local/bin/perl
for ( $i=0 ; $i< 300 ; $i++ )
{
Charles Dalsass wrote:
>
> Hey dudes, new poster here.
>
> I've got a project which the client has said 'no mod perl' but only cgi
> and perl. They've got a really powerful machine, but are 'afraid' of
> using mod_perl (because of memory issues, administration etc).
> Performance should not be a
Are there any gotchas to using mod_perl on HP-UX? I seem to remember
somewhere in the Apache documentation something about HP-UX implemented
shared memory in a weird way...
Hey dudes, new poster here.
I've got a project which the client has said 'no mod perl' but only cgi
and perl. They've got a really powerful machine, but are 'afraid' of
using mod_perl (because of memory issues, administration etc).
Performance should not be an issue.
I also have an employee who
I work with David... and figured you guys might like to see what version's
we're running... (which is already partially explained by the 1.23 comment
below)
(Apache)
Server Version: Stronghold/2.4.2 Apache/1.3.6 C2NetEU/2410 (Unix)
mod_perl/1.21 ApacheJServ/1.0
(Perl)
Summary of my perl5 (5.0 pa
> So the PerlFreshRestart is still an issue.
yep.
> I thought it was resolved as well.
one issue was resolved, that was triggered by MIME::foo messing with %INC
while mod_perl was iterating over it.
and, as vivek mentioned, dso mod_perl does a complete teardown
(perl_destruct), but it leaks a
On Fri, 19 May 2000, Vivek Khera wrote:
> > "SB" == Stas Bekman <[EMAIL PROTECTED]> writes:
>
> SB> Huh? Wasn't the mod_perl 1.23 supposed to fix this problem with DSO? I
> SB> thought to remove this item from the Guide. Are there still problems with
> SB> DSO?
>
> DSO works great for me n
On Fri, 19 May 2000, Matt Sergeant wrote:
>
> Damn - forgot smiley. Sorry :-)
doh. your reponse combined with my jetlag == foncusion :-)
On Fri, 19 May 2000, Doug MacEachern wrote:
> On Fri, 19 May 2000, Stas Bekman wrote:
>
> > Huh? Wasn't the mod_perl 1.23 supposed to fix this problem with DSO? I
> > thought to remove this item from the Guide. Are there still problems with
> > DSO?
> >
> > If I remember correctly the problem w
On Fri, 19 May 2000, Stas Bekman wrote:
> Huh? Wasn't the mod_perl 1.23 supposed to fix this problem with DSO? I
> thought to remove this item from the Guide. Are there still problems with
> DSO?
>
> If I remember correctly the problem was of broken internal pointers when
> the DSO code was relo
> "SB" == Stas Bekman <[EMAIL PROTECTED]> writes:
SB> Huh? Wasn't the mod_perl 1.23 supposed to fix this problem with DSO? I
SB> thought to remove this item from the Guide. Are there still problems with
SB> DSO?
DSO works great for me now with the fixes in place of mod_perl 1.23.
However,
> At 01:22 PM 5/19/00 -0400, Geoffrey Young wrote:
> >I think the title says it best:
> >http://perl.apache.org/guide/troubleshooting.html#Evil_things_might_happen
> _when_us
>
> Sweet. Thanks. So the problem is probably any number of weak module
> issues. That's enough for me right now...
On Fri, 19 May 2000, Doug MacEachern wrote:
> > I would say that the bigger picture is definitely not generating HTML with
> > functions - use templates or stylesheets.
>
> you're probably right. but that's not what i was getting at.
> i was trying to make points about the bigger picture in gen
Matt,
All I'm looking for is the fastest way to print sticky form elements. I
already use HTML::Template for the page templating engine (and it works
very well!). I need to take a look at CGI v.3 beta to see if it answers
some of my concerns about memory usage.
Matt Sergeant wrote:
>
> On Fri,
At 01:22 PM 5/19/00 -0400, Geoffrey Young wrote:
>I think the title says it best:
>http://perl.apache.org/guide/troubleshooting.html#Evil_things_might_happen
_when_us
Sweet. Thanks. So the problem is probably any number of weak module
issues. That's enough for me right now... turning it of
On Fri, May 19, 2000 at 06:08:41PM +0100, Matt Sergeant wrote:
>
> I would say that the bigger picture is definitely not generating HTML with
> functions - use templates or stylesheets.
At the very moment, I have a problem to find arguments to persuate my
colleagues to accept this vision. Do you
> I would say that the bigger picture is definitely not generating HTML with
> functions - use templates or stylesheets.
you're probably right. but that's not what i was getting at.
i was trying to make points about the bigger picture in general. trying
to answer "why write something in c that's
> -Original Message-
> From: David Veatch [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 19, 2000 11:48 AM
> To: [EMAIL PROTECTED]
> Subject: PerlFreshRestart Question/Problem
>
>
> Greetings,
>
> [i sent this once, but think it got hung up at the mail server... my
> apologies if thi
> "MS" == Matt Sergeant <[EMAIL PROTECTED]> writes:
MS> I would say that the bigger picture is definitely not generating HTML with
MS> functions - use templates or stylesheets.
Templates (especially ones that let you iterate over arrays) are the
way to go, in my book, for generating regular
I've been fooling around with the nextrieve engine for several sites I
maintain, and I figured I'd give it a whirl on the mod_perl guide.
Since the guide is a bunch of very large pages, this search also uses
the split-up version that Randy's search has. Thanks to Randy for
providing the script t
On Fri, 19 May 2000, Doug MacEachern wrote:
> personally, i like to have generic things written in c, things that won't
> change much or at all after they are first implemented (not including bug
> shaking). e.g. Apache::Request. both c and Perl are great languages and
> blend very well togethe
On Fri, 19 May 2000, Autarch wrote:
> Well, my point was that the decision to code something in C should be done
> because it offers an overwhelming (orders of magnitude) improvement,
> preferably on more than one front (speed, memory, ease of maintenance
> (haha) ).
small savings here and ther
This release of AxKit adds XSP support. XSP is a script embedded XML
language that is language and output agnostic. All big words, translated
to: You can write XSP pages in Perl, Java or Javascript (*).
http://xml.sergeant.org/axkit/
Details on XSP: http://xml.apache.org/cocoon/xsp.html
On Fri, 19 May 2000, Randy Kobes wrote:
> On Fri, 19 May 2000, Stas Bekman wrote:
>
> > On Fri, 19 May 2000, raptor wrote:
> >
> > > hi,
> > >
> > > very interesting. Search for : "statinc" returns nothing and the box get filled
> > > with "tatinc" instead "statinc" ?!?!:")
> > >
> > > this u
On Fri, 19 May 2000, Doug MacEachern wrote:
> > C seems like serious overkill for something to simply generate plain text
> > output. How slow is making a string in perl compared to doing it in C?
> > I can't imagine there's to much of a difference.
>
> more like Perl is serious overkill :)
>
On Fri, 19 May 2000, Stas Bekman wrote:
> On Fri, 19 May 2000, raptor wrote:
>
> > hi,
> >
> > very interesting. Search for : "statinc" returns nothing and the box get filled
> > with "tatinc" instead "statinc" ?!?!:")
> >
> > this under KDE viewer, now will try netscape ...!!
>
> it's not
Greetings,
[i sent this once, but think it got hung up at the mail server... my
apologies if this already went through]
I've run into some interesting behaviors with the PerlFreshRestart
directive. If I understand correctly, this directive is supposed to force
modules to reload when you exec
On Fri, 19 May 2000, Jeremy Howard wrote:
> Thanks heaps, Doug--moving require Apache::DB/Apache::DB->init to the
> top fixed it!
kool!
> Previously I had 'use Apache' 1st, which worked fine under the "old"
> version... It's funny the things that change between versions, isn't it?
> In fact, A
> i am able to set breakpoints no problem with 5.6.0 (perl-current,
> actually). i would suggest stripping back your Perl config to something
> simple (i tested with b Apache::Status::handler) and make sure
> require Apache::DB/Apache::DB->init is the first piece of Perl code to
> run.
>
T
On Fri, 19 May 2000, raptor wrote:
> hi,
>
> very interesting. Search for : "statinc" returns nothing and the box get filled
> with "tatinc" instead "statinc" ?!?!:")
>
> this under KDE viewer, now will try netscape ...!!
it's not the client -- it's a bug.
This happened after Randy has made
i hadn't tried Apache::DB with newer Perl since 5.005_6x-ish, there was a
fix that went into version 0.06 for that, are you using 0.06?
i am able to set breakpoints no problem with 5.6.0 (perl-current,
actually). i would suggest stripping back your Perl config to something
simple (i tested with
hi,
very interesting. Search for : "statinc" returns nothing and the box get filled
with "tatinc" instead "statinc" ?!?!:")
this under KDE viewer, now will try netscape ...!!
On Fri, 19 May 2000, Gunther Birznieks wrote:
> eg I think there was a thread on this list way back about OO method calls
> versus direct package references... and people said that OO method calls
> have a lot of overhead, but I think in later versions of Perl, OO method
> call paths are cach
On Thu, 18 May 2000, brian moseley wrote:
> On Thu, 18 May 2000, Jeffrey W. Baker wrote:
>
> > .= concatenation is way faster
>
> i don't have any results to back up my claim. therefore,
> my words are eaten :)
>
> i was convinced tho, even way back before you came to cp. i
> wonder what convi
On Thu, 18 May 2000, ___cliff rayman___ wrote:
> legitimate job offers from a reputable company are never spam.
>
especially if your salary is not more than ~$150-$200 per month :"(
sorry for the off-topic
iVAN
[EMAIL PROTECTED]
On Thu, 18 May 2000, Autarch wrote:
> C seems like serious overkill for something to simply generate plain text
> output. How slow is making a string in perl compared to doing it in C?
> I can't imagine there's to much of a difference.
more like Perl is serious overkill :)
SV's are BIG, noti
On Thu, 18 May 2000, Matt Sergeant wrote:
> On Thu, 18 May 2000, Kenneth Lee wrote:
>
> > modperlers,
> >
> > does it make sense if i put some mod_perl specific codes inside
> > an eval() so that the code runs on machines that have or haven't
> > mod_perl installed?
> >
> > eval <<'MOD_PER
> i do think that doug's separation of responsibilities into
> classes is the right one. your widget toolkit probably
> shouldn't be named Apache::HTML tho, unless it's actually
> using the apache api in some fashion.
one reason i was thinking Apache::HTML is so we can use ap_pool for
allocations
On Thu, 18 May 2000, Vivek Khera wrote:
> > "DM" == Doug MacEachern <[EMAIL PROTECTED]> writes:
>
> DM> On Wed, 17 May 2000, Matt Sergeant wrote:
> >> Well, this may be true, but if you load IO::File before startup then it's
> >> not too big a deal...
>
> DM> but it still adds a great deal
> > That would be nice to see. I'm afraid I'll continue on working on guide.
> > So if there anyone with a few free minutes on his hands, he/she might like
> > to contribute something back to community ;)
> >
> > Ideally, when we complete the tuning of the search engine, we will be able
> > to hav
>
> That would be nice to see. I'm afraid I'll continue on working on guide.
> So if there anyone with a few free minutes on his hands, he/she might like
> to contribute something back to community ;)
>
> Ideally, when we complete the tuning of the search engine, we will be able
> to have the whol
On Fri, 19 May 2000, Matt Sergeant wrote:
> On Thu, 18 May 2000, Randy Kobes wrote:
>
> > Another thing that was configured in is that words have
> > to be at least 3 characters long, which seems reasonable,
> > and also there's some stopwords that don't get indexed,
> > as they're too common. T
On Fri, 19 May 2000, Ged Haywood wrote:
> Hi all,
>
> On Thu, 18 May 2000, Randy Kobes wrote:
>
> > > The :: are stripped on the fly, since these cannot be used in index, so
> > > when you look for Foo::Bar you are actually looking for 'Foo && Bar'.
> >
> > That's a limitation of swish-e - you
On Thu, 18 May 2000, Randy Kobes wrote:
> On Fri, 19 May 2000, Stas Bekman wrote:
>
> > On Thu, 18 May 2000, Vivek Khera wrote:
> >
> > > looks good... one minor issue with the stickyness of the next search
> > > feature:
> > >
> > > type "lexical file handles" in your original search. the "e
I have my own module for doing this job, sorry I missed many
posts of this thread but here is what I do:
- The target is automatically : add , update, select data
from a table reading data typed by the user.
- I didn't want to use the Apache api, so it even can be
used out of apache, so I ca
--
Raphaël Grandjean
FI SYSTEM
Tél:0147615331
On Thu, 18 May 2000, Randy Kobes wrote:
> Another thing that was configured in is that words have
> to be at least 3 characters long, which seems reasonable,
> and also there's some stopwords that don't get indexed,
> as they're too common. This list of stopwords is built
> by hand - so far it on
Hi all,
On Thu, 18 May 2000, Randy Kobes wrote:
> > The :: are stripped on the fly, since these cannot be used in index, so
> > when you look for Foo::Bar you are actually looking for 'Foo && Bar'.
>
> That's a limitation of swish-e - you can configure it to
> index characters like $, !, ... as
54 matches
Mail list logo
