ntire guide anymore...
>>> You can get a PDF of single pages (of which I don't know the
>>> reason?), but the guide itself is quite hard.
>>
>>
>> eh? what do you mean? it's all there, go to:
>> http://perl.apache.org/docs/1.0/guide/index.html
my 23 hour
>>flight to the USA (to read on the flight) and was dismayed to find hours
>>before my flight that it is impossible to get a full HTML or full PDF
>>download of the entire guide anymore...
>>You can get a PDF of single pages (of which I don't know the rea
> Wouldn't it thus be simpler and more convenient
> for 1st times like myself if the guide download were
> simply the already created html pages which appear
> online.
Frankly, hardly anyone does that. Most people refer to the guide
on-line. I've used mod_perl for
.
I conclude that the guide is built from the PODs
(Plain Old Documents). pod2hpp is thus needed to
convert the pods to html. The online guide is no doubt
created the same way.
Wouldn't it thus be simpler and more convenient
for 1st times like myself if the guide download were
simpl
I actually tried to send this directly to Sats -
twice. But mail seemed to be bouncing, so I suppose I'll have to do this
through the list...
Firstly - the typo:
the mod_perl porting page contains info
about setting HTTP headers - but the guide says to do $r->headers_out, w
> Perhaps we have a misunderstanding here. I would NEVER flock(UN) without
> having just previously untie()d the database. And I would ALWAYS acquire a
> lock immediately before tie()ing the database.
That's the point. We have to write down all the assumptions or people will
do the wrong thing. I
(I apologize in advance for the horrible line wrapping my mailer will do.)
Stas Bekman [mailto:[EMAIL PROTECTED]] wrote:
> > Now you have a concern with upgrading locks from shared to exclusive:
> >
> > > David, please consider this scenario:
> > >
> > > ... At some point in time, processes A an
On Fri, 23 Mar 2001, David Harris wrote:
> Stas,
>
> Sounds like you agree with me that downgrading locks from exclusive to
> shared is not a problem with the method I described in the last e-mail.
That's correct.
> Now you have a concern with upgrading locks from shared to exclusive:
>
> > Dav
t; the first 4k)
David Harris
President, DRH Internet Inc.
[EMAIL PROTECTED]
http://www.drh.net/
-Original Message-
From: Stas Bekman [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 22, 2001 10:22 PM
To: David Harris
Cc: mod_perl list
Subject: RE: dbm locking info in the guide
On Thu, 2
On Thu, 22 Mar 2001, David Harris wrote:
> Two points about switching from exclusive mode to shared mode:
>
> (1) When downgrading from EX to SH, no other processes need to have cached
> data invalidated because no one else can have the database open. There is no
> cache in other processes, there
Stas Bekman [mailto:[EMAIL PROTECTED]] wrote:
> On Thu, 22 Mar 2001, David Harris wrote:
> > If you want to downgrade a lock from exclusive to shared, sync the
database
> > and change the lock status. This will allow other readers access to a
> > fully-written database. No one else will be allowe
On Thu, 22 Mar 2001, David Harris wrote:
Thanks, David!
> I have done some investigation of the sync method in DB_File and this is
> what I have determined: the sync method only writes cached information out
> to disk. Information already cached in the process is not invalidated
> causing a re-r
Stas Bekman [mailto:[EMAIL PROTECTED]] wrote:
> As the person who has discovered this bad flaw in DB_File docs and made
> sure that the right thing will be done, may be David will have a time to
> go further and check up on this issue. I would definitely do it myself,
> but there so many things I
On Wed, 21 Mar 2001, Perrin Harkins wrote:
> > Ok, what about calling sync before accesing the database? (read and write)
> > Will it force the process to sync its data with the disk, or will it cause
> > the corruption of the file on the disk, as the process might have a stale
> > data?
>
> Well
> Ok, what about calling sync before accesing the database? (read and write)
> Will it force the process to sync its data with the disk, or will it cause
> the corruption of the file on the disk, as the process might have a stale
> data?
Well, that's what we don't know. As David Harris pointed o
On Tue, 20 Mar 2001, Perrin Harkins wrote:
> Stas Bekman wrote:
> > So basically what you are saying is that sync() is broken and shouldn't be
> > used at all. Something fishy is going on. The purpose of sync() is to
> > flush the modifications to the disk.
>
> Saving changes to disk isn't the pr
Stas Bekman wrote:
> So basically what you are saying is that sync() is broken and shouldn't be
> used at all. Something fishy is going on. The purpose of sync() is to
> flush the modifications to the disk.
Saving changes to disk isn't the problem. The issue is that some of the
database gets cac
On Tue, 20 Mar 2001, David Harris wrote:
>
> Perrin Harkins [mailto:[EMAIL PROTECTED]] wrote:
> > I think you'll still have problems with this technique, unless you
> > tie/untie every time. I'm looking at the perldoc for DB_File version
> > 1.76, at the section titled "Locking: the trouble with
On Tue, 20 Mar 2001, Perrin Harkins wrote:
> On Wed, 21 Mar 2001, Stas Bekman wrote:
> > > You mean with DB_File? There's a big warning in the current version
> > > saying not to do that, because there is some initial buffering that
> > > happens when opening a database.
> >
> > The warning says
Perrin Harkins [mailto:[EMAIL PROTECTED]] wrote:
> I think you'll still have problems with this technique, unless you
> tie/untie every time. I'm looking at the perldoc for DB_File version
> 1.76, at the section titled "Locking: the trouble with fd". At the very
> least, you'd have to call sync
On Wed, 21 Mar 2001, Stas Bekman wrote:
> > You mean with DB_File? There's a big warning in the current version
> > saying not to do that, because there is some initial buffering that
> > happens when opening a database.
>
> The warning says not to lock on dbm fd but an external file!
I think y
On Tue, 20 Mar 2001, Perrin Harkins wrote:
> On Tue, 20 Mar 2001, Stas Bekman wrote:
> > > Is anyone aware of a safe to way to do multi-process read/write access
> > > through a dbm module other than BerkeleyDB.pm without tie-ing and
> > > untie-ing every time? I thought that was the only safe t
On Tue, 20 Mar 2001, Joshua Chamas wrote:
> I know the tie/untie MLDBM::Sync strategy with DB_File is
> slow, but what size data are you caching?
I'm not. Well, actually I am, but I use BerkeleyDB which handles its
own locking. I just noticed this in the Guide and figured that ei
Perrin Harkins wrote:
>
> Is anyone aware of a safe to way to do multi-process read/write access
> through a dbm module other than BerkeleyDB.pm without tie-ing and
> untie-ing every time? I thought that was the only safe thing to do
> because of buffering issues, but this seems to be implying th
On Tue, 20 Mar 2001, Stas Bekman wrote:
> > Is anyone aware of a safe to way to do multi-process read/write access
> > through a dbm module other than BerkeleyDB.pm without tie-ing and
> > untie-ing every time? I thought that was the only safe thing to do
> > because of buffering issues, but this
On Mon, 19 Mar 2001, Perrin Harkins wrote:
> While working on adding info on Berkeley DB to the Guide, I came across
> this statement:
>
> "If you need to access a dbm file in your mod_perl code in the read only
> mode the operation would be much faster if you keep the dbm fi
While working on adding info on Berkeley DB to the Guide, I came across
this statement:
"If you need to access a dbm file in your mod_perl code in the read only
mode the operation would be much faster if you keep the dbm file open
(tied) all the time and therefore ready to be used. This
I've gotten in touch with Stas, and the 'scaling mod_perl' site will
eventually be folded into the Guide. woohoo!
I'm going to spend several weeks fleshing it out and cleaning it up before
it goes in, though.
-Ed
-Original Message-
From: Perrin Harkins [mailto:[EM
Hi,
Yandex engine also can highlight words and can be customized the
way you want. But I think you are right and the guide does not
need so complex and powerfull engine.
Vlad.
> -Original Message-
> From: Stas Bekman [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 23, 2000 1:2
age-
> > From: Stas Bekman [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, May 04, 2000 2:10 PM
> > To: Matt Sergeant
> > Cc: mod_perl list
> > Subject: Re: search engine for the Guide
> >
> >
> > > On Thu, 4 May 2000, Stas Bekman wrote:
> &g
t
> Subject: Re: search engine for the Guide
>
>
> > On Thu, 4 May 2000, Stas Bekman wrote:
> >
> > > On Wed, 3 May 2000, Matt Sergeant wrote:
> > >
> > > > On Wed, 3 May 2000, Stas Bekman wrote:
> > > >
> > > > > Yeah,
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, 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
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
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 ...!!
ml which is also able to search under
> perl.apache.org, but if you enter mod_perl, doesn't find anything :-(. Don't
> know if this is of any use and who is maintaining (or not maintaining) this
> page.
Heh, look at the bottom of the http://perl.apache.org/guide/index.html
>
> 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
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
On Thu, 18 May 2000, Jeremy Howard wrote:
> Stas Bekman <[EMAIL PROTECTED]> wrote:
> > Ok, We have a preview ready for you. Randy Kobes worked hard to prepare
> > this one. So your comments are very welcome. If you like it we'll put this
> > into production.
> >
> > Please keep either the list
Stas Bekman <[EMAIL PROTECTED]> wrote:
> Ok, We have a preview ready for you. Randy Kobes worked hard to prepare
> this one. So your comments are very welcome. If you like it we'll put this
> into production.
>
> Please keep either the list CC'ed or if you reply to me in person, make
> sur
On Fri, 19 May 2000, Stas Bekman wrote:
> On Thu, 18 May 2000, Matt Sergeant wrote:
>
> > One more point... The indexer or the searcher (or both) has a broken
> > tokenizer for anything involving perl. Try searching for
> > Apache::Constants, for example.
>
> That's right. It's broken :( After
On Thu, 18 May 2000, Matt Sergeant wrote:
> Looks cool, except can we take the guide splitting back 1 level? It
> seems to be split on =head2's, and should be split (IMO) on =head1's.
The reason for splitting on any =head level lies in fact that there are
huge sections under =
On Fri, 19 May 2000, Stas Bekman wrote:
> Ok, We have a preview ready for you. Randy Kobes worked hard to prepare
> this one. So your comments are very welcome. If you like it we'll put this
> into production.
>
> Please keep either the list CC'ed or if you reply to me in person, make
> sure yo
me in person, make
> sure you keep Randy CC'ed -- all the kudos should go his way :)
>
> So:
>
> The search is at:
>
> http://theoryx5.uwinnipeg.ca/cgi-bin/guide-search
>
> and the split guide is at:
>
> http://theoryx5.uwinnipeg.ca/guide/
Looks cool, exce
Ok, We have a preview ready for you. Randy Kobes worked hard to prepare
this one. So your comments are very welcome. If you like it we'll put this
into production.
Please keep either the list CC'ed or if you reply to me in person, make
sure you keep Randy CC'ed -- all the kudos should go his way
Stas Bekman wrote:
> Yeah, it's a nice trick. The thing that defeats it a search engine, is
> it's freshness. We cannot tell google to rehash the Guide when there is a
> new version, and searching the outdated version is a bad idea.
Google is _very_ good at visiting frequen
On Fri, 5 May 2000, Jeremy Howard wrote:
> At 01:28 PM 5/4/00 +0300, Stas Bekman wrote:
> >Two things:
> >
> >1) I'd better concentrate on improving the content and structure of the
> >Guide and will leave this search engine task to someone who needs to use
&
eeps its search contents up to
> > date, you
> > > > > can leverage their engine. IIRC either Randall or Lincoln did a
> > > > > WebTechniques article about this a few months ago.
> > > >
> > > > Oh, I see.
> > > >
> > > &g
At 01:28 PM 5/4/00 +0300, Stas Bekman wrote:
>Two things:
>
>1) I'd better concentrate on improving the content and structure of the
>Guide and will leave this search engine task to someone who needs to use
>the Guide but find it unusable without the proper search engine.
&
Randall or Lincoln did a
> > > > WebTechniques article about this a few months ago.
> > >
> > > Oh, I see.
> > >
> > > But I want to stress these 2 points:
> > >
> > > 1) Currently each chapter in the Guide is a huge document, so doi
On May 04, 2000 at 10:37:05 +0100, Matt Sergeant twiddled the keys to say:
> On Thu, 4 May 2000, Stas Bekman wrote:
>
> > On Wed, 3 May 2000, Matt Sergeant wrote:
> >
> > > On Wed, 3 May 2000, Stas Bekman wrote:
> > >
> > > > Yeah, I've been thinking about it. There was one site that has offere
On Thu, 4 May 2000, Stas Bekman wrote:
> On Wed, 3 May 2000, Matt Sergeant wrote:
>
> > On Wed, 3 May 2000, Stas Bekman wrote:
> >
> > > Yeah, I've been thinking about it. There was one site that has offered me
> > > to provide a good search engine and they did, but the problem is that they
> >
ong as AltaVista keeps its search contents up to date, you
> > > can leverage their engine. IIRC either Randall or Lincoln did a
> > > WebTechniques article about this a few months ago.
> >
> > Oh, I see.
> >
> > But I want to stress these 2 points:
&
> > need a search engine not the API to it. Did I miss something?
>
> Yes. On some of the search engines (AltaVista springs to mind) you can
> search for things on particular web sites, or even links to particular web
> sites. So as long as AltaVista keeps its search contents up to da
> can leverage their engine. IIRC either Randall or Lincoln did a
> > WebTechniques article about this a few months ago.
>
> Oh, I see.
>
> But I want to stress these 2 points:
>
> 1) Currently each chapter in the Guide is a huge document, so doing search
> and having
On Wed, 3 May 2000, Matt Sergeant wrote:
> On Wed, 3 May 2000, Stas Bekman wrote:
>
> > Yeah, I've been thinking about it. There was one site that has offered me
> > to provide a good search engine and they did, but the problem is that they
> > didn't keep up with new releases, so people were se
On Wed, 3 May 2000, Stas Bekman wrote:
> Yeah, I've been thinking about it. There was one site that has offered me
> to provide a good search engine and they did, but the problem is that they
> didn't keep up with new releases, so people were searching the outdated
> version, which is quite bad -
> > > Stas Bekman wrote:
> > > the guide is getting so big these days, it's hard to keep up with all the
> > > new developments. Or maybe that entered a few versions ago :) It's along
> > > way from the mini-guide that got me started...
> ___c
On Sun, 9 Apr 2000, Matt Sergeant wrote:
> For similar exception handling techniques, see the Try module, the
> Exception module and the Error module, all on CPAN.
There is no Exception module on CPAN? If you're referring to my code,
it's not yet on CPAN because I don't think I can justify atte
This is the 2nd attempt, at Stas' request I'm pasting the whole thing
here so you can reply and/or edit.
=head1 Exception Handling for mod_perl
Provided here are some guidelines for S exception handling
for mod_perl usage, although the technique presented here applies to
all of your perl program
On Sat, 8 Apr 2000, Autarch wrote:
> On Sat, 8 Apr 2000, Matt Sergeant wrote:
>
> > I've written a short document on exception handling for the guide, even
> > though it's not particularly mod_perl specific, Stas thinks it would be a
> > good addition. Tak
er languages.
On Sat, 8 Apr 2000, Autarch wrote:
> N; charset=US-ASCII
> X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N
> Status: U
>
> On Sat, 8 Apr 2000, Matt Sergeant wrote:
>
> > I've written a short document on exception handling for the guide, even
> > tho
On Sat, 8 Apr 2000, Matt Sergeant wrote:
> I've written a short document on exception handling for the guide, even
> though it's not particularly mod_perl specific, Stas thinks it would be a
> good addition. Take a look at it, and let me know if there is anything you
> wo
I've written a short document on exception handling for the guide, even
though it's not particularly mod_perl specific, Stas thinks it would be a
good addition. Take a look at it, and let me know if there is anything you
would change before it's added:
http://modperl.ser
found this while looking through the guide:
quot guide>>Safe Code Updates on a Live Production Server
-- snip --
think I'm ready I do:
% cd /home/httpd/perl
% mv rel old; mv beta rel; stop; sleep 3; restart; err
<
69 matches
Mail list logo
