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 part of
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 only
--
Raphaël Grandjean
FI SYSTEM
Tél:0147615331
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
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 "es" at the
end
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 can configure
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. This list
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 whole
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 whole
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 of bloat to the
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, 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_PERL_CODE' if
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, notice
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, 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 convinced me!
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
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 ...!!
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
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 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.
Thanks
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,
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
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 the client --
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 :)
SV's
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 there
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 together.
"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 HTML.
-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 this already
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
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 off
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
"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, note that
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 reloaded.
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 was of
On Fri, 19 May 2000, Matt Sergeant wrote:
Damn - forgot smiley. Sorry :-)
doh. your reponse combined with my jetlag == foncusion :-)
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
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
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
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 an
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
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
"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.conf
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,
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 / WinNT
cholet 00/05/19 09:01:24
Modified:.Changes
Log:
document the fact that I fixed what I'd just broken
Revision ChangesPath
1.488 +3 -0 modperl/Changes
Index: Changes
===
RCS file:
46 matches
Mail list logo
