Re: caching questions
On Tue, 22 Jul 2003 13:05:00 +0300, Stas Bekman wrote: > Peter Haworth wrote: > > Cache::Mmap (which I wrote) isn't threadsafe, but should work OK in a > > forking MPM. If anyone wants to contribute code to make it threadsafe > > (preferably without impacting single-threaded performance too much), > > I'll be very grateful. I'd do it myself, but I've never used threads, so > > I'm bound to get it wrong. > > I haven't looked at the module's implementation, but if you have a C-level > thread-safety issues, you may consider using libapr which provides a > thread-safe mmap API. No, it's perl-level stuff at the point that matters. Currently, it uses fine grained file locking to prevent concurrent accesses from other processes, but as far as I understand it, this won't prevent concurrent accesses from other threads in the same process. -- Peter Haworth [EMAIL PROTECTED] "Do you expect me to implement it?" "No, Mister Schwern, I expect you to DIE!" -- Michael G Schwern in p5p
Re: caching questions
On 22 Jul 2003 08:13:43 +0200, Tom Schindl wrote: > Am Mon, 2003-07-21 um 21.45 schrieb Perrin Harkins: > > On Sun, 2003-07-20 at 15:47, Patrick Galbraith wrote: > > > I know there's IPC, and also memcached. I've used IPC::Shareable > > > before, but don't know if that's the route I'd wanna go. > > > > It's not. IPC::Shareable is very slow. If you want to share data, use > > Cache::FileCache, Cache::Mmap, MLDBM::Sync, or IPC::MM. > > Sorry to step in here, but could I use any of the caching modules you > mentionned in mod_perl2? Cache::Mmap (which I wrote) isn't threadsafe, but should work OK in a forking MPM. If anyone wants to contribute code to make it threadsafe (preferably without impacting single-threaded performance too much), I'll be very grateful. I'd do it myself, but I've never used threads, so I'm bound to get it wrong. -- Peter Haworth [EMAIL PROTECTED] "[That sentence] occupied the table running through the middle of the middle room in a half-way house. It was so equidistant that it managed to find a patch of gravitic stability, a Lagrange of Reason, within which it set up a giant tubular space station of the type that NASA were hoping to build by 2010." -- Ashley Pomeroy
ANNOUNCE: Cache::Mmap 0.07
Anyone running 0.05 on perl 5.6.0 or later should upgrade to this version, unless they are absolutely sure that none of their cached data contains UTF8 encoded characters. I didn't think my data did, but my caches were exhibiting some very peculiar behaviour because of it. >From the README: This module provides a shared cache, using a memory mapped file. Very useful for mod_perl applications. If routines are provided which interact with the underlying data, access to the cache is completely transparent, and the module handles all the details of refreshing cache contents, and updating underlying data, if necessary. Changes since version 0.05 Add a check for super-sized entries (those which extend past the bucket end) Make zero-sized check message include cache filename and key Add t/03corrupt.t to check that the corruption checks are working Deal with utf8 properly (and add t/04utf8.t) This changes the file format, so added format version number to file header Existing files which aren't cache files are not overwritten From: PAUSE <[EMAIL PROTECTED]> To: "Peter Haworth" <[EMAIL PROTECTED]> Subject: CPAN Upload: P/PM/PMH/Cache-Mmap-0.07.tar.gz Date: Tue, 17 Jun 2003 20:54:32 +0200 The uploaded file Cache-Mmap-0.07.tar.gz has entered CPAN as file: $CPAN/authors/id/P/PM/PMH/Cache-Mmap-0.07.tar.gz size: 19897 bytes md5: 1288f95fa9a86a83c0884602b69597f1 No action is required on your part Request entered by: PMH (Peter Haworth) Request entered on: Tue, 17 Jun 2003 18:52:52 GMT Request completed: Tue, 17 Jun 2003 18:54:32 GMT Thanks, -- paused, v343 -- Peter Haworth [EMAIL PROTECTED] "i like Sample A because it tastes great and is less typing." -- brian d foy in c.l.p.misc
Re: [OT] Better Linux server platform: Redhat or SuSe?
On Wed, 3 Jul 2002 11:40:44 +0100, Jean-Michel Hiver wrote: > > perl: Any iussues with perl/modperl? Besides modperl I will be running a > > perl application with a few hundred thousend lines of code... > > Wow. For reference last time I looked at slashcode it was about 25.000 > lines I think. I wonder what kind of application would require more than > that amount of Perl code :-) I'm sure someone else will post a bigger number, but my application (IOP Electronic Journals) has 55000 lines of code (including the odd blank line and comment, of course). And we're always adding new stuff, so it only ever gets bigger. -- Peter Haworth [EMAIL PROTECTED] "We don't care how they do it in New York."
Re: Commercial use of mod_perl / modules]
On 29 Jun 2002 01:46:00 +0400, Ilya Martynov wrote: > >>>>> On Fri, 28 Jun 2002 16:38:25 -0500, Stephen Clouse > >>>>> <[EMAIL PROTECTED]> said: > > SC> On Fri, Jun 28, 2002 at 01:09:21PM +0100, Peter Haworth wrote: > >> The GPL doesn't restrict use, only distribution. > > SC> I believe you need to read it again. Its whole purpose of > SC> existence is to restrict use by non-free software. Link GPL code > SC> into your non-free app at your own risk. > > AFAIK it is OK as long as you do not distribute the result. Admittedly, it has been some time since I read it. However, I've just done so. Here are some quotes: > 0. Activities other than copying, distribution and modification are not > covered by this License; they are outside its scope. The act of running > the Program is not restricted, and the output from the Program is covered > only if its contents constitute a work based on the Program Running the program, and it's output are not restricted. Otherwise, everything compiled by gcc would be under GPL, which it isn't. > 2. You may modify your copy or copies of the Program or any portion of it, >thus forming a work based on the Program, and copy and distribute such >modifications or work under the terms of Section 1 above, provided that >you also meet all of these conditions: > b) You must cause any work that you distribute or publish, that in whole > or in part contains or is derived from the Program or any part thereof, > to be licensed as a whole at no charge to all third parties under the > terms of this License. This is the only condition in section 2 which mentions distribution. It doesn't say you have to distribute; only what applies if you do. These are from the GPL FAQ: > A system incorporating a GPL-covered program is an extended version of > that program. The GPL says that any extended version of the program must > be released under the GPL if it is released at all. But from my reading (which could be wrong, of course), it doesn't say that you have to release it. > What the GPL requires is that [someone with a copy of a GPL'ed program] > must have the freedom to distribute a copy to you if he wishes to. -- Peter Haworth [EMAIL PROTECTED] "Who is General Failure and why is he reading my disk?"
[ANNOUNCE] Cache::Mmap 0.04
file: $CPAN/authors/id/P/PM/PMH/Cache-Mmap-0.04.tar.gz size: 14113 bytes md5: 649bdb9816f4177c0eb81c077fd7614c Much to my dismay and embarrassment, the serious bug fix in version 0.03 introduced a serious bug of it's own. You'll be pleased to hear that I've added a test suite (currently only one file) to the distribution, so this sort of thing should happen less in the future. Again, I strongly advise all users to upgrade to this version. I've also removed all the older versions from CPAN, just in case. This version also does the file locking in XS, thus removing the assumptions about struct flock's layout. It also does its own mmap()ing in XS, removing the dependency on Malcom Beattie's Mmap.pm. This means that people don't need to figure out Malcom's slightly strange distribution name, and it compiles on 5.6 without any problems (I've tested it on 5.004_05 too). >From the README: This module provides a shared cache, using a memory mapped file. Very useful for mod_perl applications. If routines are provided which interact with the underlying data, access to the cache is completely transparent, and the module handles all the details of refreshing cache contents, and updating underlying data, if necessary. -- Peter Haworth [EMAIL PROTECTED] "I don't know what kinds of evil I've done in the past. I don't even want to know. I just want that evil to carry on having its good effects" -- Damian Conway on his use of pack/unpack/vec
[ANNOUNCE] Cache::Mmap 0.03
file: $CPAN/authors/id/P/PM/PMH/Cache-Mmap-0.03.tar.gz
size: 9454 bytes
md5: f28df3400f28b54034a8a684a8e1e923
I strongly advise all users of this module to upgrade to this version if
they are using the write() method, and at least version 0.02 otherwise.
The next version should come out within the next week or so, and will remove
the dependency on Mmap.pm, and use more portable file locking.
>From the README:
This module provides a shared cache, using a memory mapped file. Very useful
for mod_perl applications. If routines are provided which interact with the
underlying data, access to the cache is completely transparent, and the module
handles all the details of refreshing cache contents, and updating underlying
data, if necessary.
Changes since version 0.02
Fixed serious bug in write(), which corrupted the cache file when replacing
already existing entries
Changes since version 0.01
Fixed serious bug in read(), which didn't update the current bucket content
size when expiring entries. This caused infinite loops in _find() and
_insert(), which have also been fixed, should anything else ever go wrong
in a similar way
--
Peter Haworth [EMAIL PROTECTED]
"Besides, I wasn't trying to help them understand.
I was only trying to help them think they understand."
-- Larry Wall
[ANNOUNCE] HTML::StickyForms 0.05
>From the README:
This a lightweight form generation module, which can be used with either
CGI.pm (version 2 or 3), or (inside mod_perl) Apache::Request.
The module provides similar facilities to CGI.pm's HTML tag generation
routines, but is restricted to form field generation tags, with sticky values.
Also, the interface is not so flexible as CGI.pm's, in order to keep the code
size down.
Changes since version 0.04:
Added set_sticky() method, useful if you ad parameters after creation
Added values_as_labels() method, to allow labels to default to their values
Added values_as_labels attribute to checkbox_group()/radio_group()/select()
The uploaded file
HTML-StickyForms-0.05.tar.gz
has entered CPAN as
file: $CPAN/authors/id/P/PM/PMH/HTML-StickyForms-0.05.tar.gz
size: 5663 bytes
md5: 18406762bcd4657064ce7f026ee93adb
--
Peter Haworth [EMAIL PROTECTED]
"We do not have to cater to the Windows 95 level of user-obsequiousness"
-- Kai MacTane
[ANNOUNCE] Cache::Mmap 0.02
This release contains a bug fix for an infinite loop which could occur in version 0.01 when automatic expiry of cache entries was enabled. The cause and symptoms have both been fixed. Cache::Mmap - Shared cache using memory mapped file Cache::Mmap allows you to treat your cache much like a hash. When the cache is set up with read (and write/delete) sub refs, the user just fetches (and stores/deletes) data from it. Cache::Mmap automatically loads new entries into the cache as necessary, expires stale cache entries, deletes least recently used entries when space is needed and allows for writethrough as well as delayed write behaviour. The uploaded file Cache-Mmap-0.02.tar.gz has entered CPAN as file: $CPAN/authors/id/P/PM/PMH/Cache-Mmap-0.02.tar.gz size: 9208 bytes md5: 0dde9fb797f2001a6bdea9549ebba186 No action is required on your part Request entered by: PMH (Peter Haworth) Request entered on: Thu, 07 Jun 2001 17:26:01 GMT Request completed: Thu, 07 Jun 2001 17:26:57 GMT Virtually Yours, Id: paused,v 1.74 2001/05/20 14:59:52 k Exp k -- Peter Haworth [EMAIL PROTECTED] `I wouldn't quite call it "mark-and-sweep", it's more like "nuke-and-pave"' -- Matthias Neeracher, talking about perl garbage collection
Re: Lightweight CGI.pm for PerlHandlers
On Fri, 18 May 2001 23:28:06 -0400, Neil Conway wrote: > I'd like to be able to use something similar to CGI.pm's HTML > generation methods in a PerlHandler I'm writing. Since I'm > not ever going to be using CGI directly (and also, the HTML > I'm doing is pretty simple), CGI.pm seems like overkill -- > and from looking at some basic memory usage data, it seems > like you pay for this complexity/flexibility. > > Is there a simple (fast, light) module that generates HTML > in a similar style to CGI.pm, for use with mod_perl? If you just care about CGI.pm's "stickiness", my HTML::StickyForms module in combination with Apache::Request will generate form elements. You'll have to do the other elements yourself, though. -- Peter Haworth [EMAIL PROTECTED] "This seems dangerously close to COBOL, something difficult to argue in favor of." -- Tom Christiansen
RE: dynamic vs. mostly static data
It might have been my Cache::Mmap module, which is ideal for this kind of thing. It depends on what your data looks like though, of course. On Thu, 2 Nov 2000 16:48:24 -0500 , Jerrad Pierce said: > There is a query caching module someone posted here redently... > Or was it proposed and beta-ish? > > Another thing you might consider doing is having a cron job do your periodic > (10 min.) > fetch and store it as a file somewhere... Then use SSI or some more > mod_perl-ish means of including this static content... > > >-Original Message- > >From: Neil Conway [mailto:[EMAIL PROTECTED]] > >Sent: Thursday, November 02, 2000 4:45 PM > >To: ModPerl List > >Subject: dynamic vs. mostly static data > > > > > >I'm writing a web app in mod_perl, using a PostgreSQL database > >backend and HTML::Template. In looking for ways to optimize > >performance, I noticed that although my code is doing several > >(say, 4-5) database queries per handler/webpage, a large part > >of the data (~2 queries) is mostly static (it will change > >perhaps once per week, or once per month). It's obviously > >inefficient to run these queries on the database for every > >single request. > > > >How can I 'cache' this data so that all Apache children can > >access it quickly? Is there a way to automatically update > >this cache periodically (say every 10 minutes)? Also, this > >solution should work on any reasonably modern UNIX system > >(Win32 is not important for now). > > > >I couldn't find this anywhere, but if someone tells me where, > >I'd be happy to RTFM. Ask me if you need more info. -- Peter Haworth [EMAIL PROTECTED] "Writing for a penny a word is ridiculous. If a man really wants to make a million dollars, the best way would be to start his own religion." -- L. Ron Hubbard
[ANNOUNCE] Cache::Mmap 0.01
[This is a repost, but I can't find any record of my original message]
I've finally got round to releasing my shared cache module, which uses a
memory mapped file to hold the cache entries. This module handles all logic
dealing with fetching and refreshing cache entries. It also allows cache
entries to be stored manually, with the option of updating the original data
store (writethrough or write-on-demand).
You can find it at $CPAN/authors/id/P/PM/PMH/Cache-Mmap-0.01.tar.gz
I'm giving a talk about the module at yapc::Europe this weekend.
--
Peter Haworth [EMAIL PROTECTED]
"2 + 2 = 5 for extremely large values of 2."
[ANNOUNCE] HTML-StickyForms-0.03.tar.gz
This is an important upgrade for anyone using HTML::StickyForms with Apache::Request 0.31. Previously, trim_params() was subject to a bug in Apache::Request::param(), which doesn't seem to allow setting of multi-valued fields. This version of StickyForms works around the bug. --- Forwarded Message --- From: [EMAIL PROTECTED] To: "Peter Haworth" <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Sent: Wed, 30 Aug 2000 12:05:14 +0200 Subject: CPAN Upload: P/PM/PMH/HTML-StickyForms-0.03.tar.gz The uploaded file HTML-StickyForms-0.03.tar.gz has entered CPAN as file: $CPAN/authors/id/P/PM/PMH/HTML-StickyForms-0.03.tar.gz size: 4838 bytes md5: 2d1a6c9f05d2cc70afdd3cd1887152a9
ANNOUNCE: HTML::StickyForms 0.02
OK, this time I've remembered to say what the module actually does:
This a lightweight form generation module, which can be used with either
CGI.pm, or (inside mod_perl) Apache::Request. The module provides similar
facilities to CGI.pm's HTML tag generation routines, but is restricted to
form field generation tags, with sticky values. Also, the interface is not
so flexible as CGI.pm's, in order to keep the code size down.
Changes since version 0.01:
Added select()
Combined checkbox_group() and radio_group()
Added documentation
--- Begin Forwarded Message ---
The uploaded file
HTML-StickyForms-0.02.tar.gz
has entered CPAN as
file: $CPAN/authors/id/P/PM/PMH/HTML-StickyForms-0.02.tar.gz
size: 4716 bytes
md5: c2c216faba385af3186a3e5d83923700
No action is required on your part
Request entered by: PMH (Peter Haworth)
Request entered on: Tue, 27 Jun 2000 13:42:55 GMT
Request completed: Tue, 27 Jun 2000 13:43:58 GMT
Virtually Yours,
Id: paused,v 1.68 1999/10/22 14:39:12 k Exp k
--- End Forwarded Message ---
--
Peter Haworth [EMAIL PROTECTED]
Duck!
Where?
Re: my && param
>
> How should I correctly make "Param" assignments availble to function_2
> and NOT to function_1 ???
>
> #---
> sub function_1 {
> blah
> blah
> }
>
> sub function_2 {
> my @array = param('This_Param');
>
> foreach (@array) {
> my @{$_} = param($_); # ASSIGNMENT IN QUESTION
> }
>
> # HERE I NEED TO USE THE "@whatever" ARRAYS
> # BUT I DONT THINK THEY EXIST OUTSIDE THE "foreach (@array)" SCOPE
> }
> #---
Try putting them in a hash:
sub function_2{
my @array=param('This_Param');
my %params;
foreach(@array){
@{$params{$_}}=param($_);
}
# Now, instead of print @whatever, do this:
print @{$params{whatever}};
}
--
Peter Haworth [EMAIL PROTECTED]
"C++ gives me the willies. Physical willies. I take medication for it."
-- Kurt Starsinic on p6p
Re: Crazy browser issues
On 21-Jun-00 at 17:59, J. J. Horner ([EMAIL PROTECTED]) wrote: > In Netscape (and probably IE), if a handler returns AUTH_REQUIRED, the > user can just hit 'Ok' on the password dialogue without typing in a > password and the browser will resend the original information again. > If the password in cache is still valid, it will > reauthenticate without prompting the user again. This can't be > cool. I've found that I have to make sure that the $sent_pw in > > my ($res, $sent_pw) = $r->get_basic_auth_pw; > > isn't null or 0. > > Also, IE doesn't always give a user the password dialog when given an > AUTH_REQUIRED response. If IE sends a username/password because of an > AUTH_REQUIRED response, and gets an AUTH_REQUIRED response in return, it > will resend the information again, this makes it really difficult to deal > with different browsers during the Authentication phase. Are you calling $r->note_basic_auth_failure when you return AUTH_REQUIRED? I see something even stranger on occassion. Sometimes, when I connect to a pasword-protected area using the unqualified name of the server, the browser just sends the request *without* asking for a username, repeatedly, until I hit STOP. This never happens when using the fully qualified server name. Something else about authen handlers confuses me: does $r->get_basic_auth_pw call $r->note_basic_auth_failure when it returns AUTH_REQUIRED? -- Peter Haworth [EMAIL PROTECTED] "Please wait while I fill up a random disk partition to test whether print returns the correct error code..." -- Larry Wall in a hypothetical perl test suite
Re: [ANNOUNCE] HTML::StickyForms 0.01
Jeff Stuart wrote:
> Small rant here. :) Ok Peter, this looks interesting. WHAT does it
> do :) And please, to ALL module developers, when you post an
> announcement, even if it's an upgrade, please include a brief description of
> what the module does. :) Your module may JUST be the thing that I'm looking
> for but if there's no description of what it does I may not know that. :)
Ack, oops!
OK, HTML::StickyForms provides a consistent interface for CGI and mod_perl
programs to generate HTML forms with "sticky" values. This is much like what
CGI.pm does, but with a much smaller remit.
The interface is pretty straightforward:
sub handler{
my($r)=@_;
$r=Apache::Request->new($r);
my $f=HTML::StickyForms->new($r);
$r->send_http_header;
print
"",
"Field 1:",
$f->text(name => field1, value => "default value"),
"Radio buttons:",
$f->radio_group(name => field2, values => [1,2,3],
labels => {1=>'one', 2=>'two', 3=>'three'}, default => 3),
"",
;
return OK;
}
The argument to new() can be one of: an Apache::Request (or subclass) instance,
a CGI (or subclass) instance (CGI 2.x, 3.x), a CGI::State (or subclass)
instance (CGI 3.x), or you can leave it out completely, in which case, there
won't be any sticky values.
This will all get documented very soon, and I promise to at least hint at it in
the next release announcement.
--
Peter Haworth [EMAIL PROTECTED]
"People get annoyed when you try to debug them"
-- Larry Wall
[ANNOUNCE] HTML::StickyForms 0.01
I've finally released my sticky forms module on CPAN. There's currently no user
documentation, but the interface should be fairly self explanatory. I'd
appreciate some comments on the interface, and I'll start working on the docs
for the next release.
The uploaded file
HTML-StickyForms-0.01.tar.gz
has entered CPAN as
file: $CPAN/authors/id/P/PM/PMH/HTML-StickyForms-0.01.tar.gz
size: 2804 bytes
md5: a52d669328840c0314309d3e615a540a
No action is required on your part
Request entered by: PMH (Peter Haworth)
Request entered on: Thu, 15 Jun 2000 13:49:15 GMT
Request completed: Thu, 15 Jun 2000 13:49:26 GMT
Virtually Yours,
Id: paused,v 1.68 1999/10/22 14:39:12 k Exp k
--
Peter Haworth [EMAIL PROTECTED]
"To define recursion, we must first define recursion."
Re: Form generation libraries
On 24-May-00 at 18:50, Jeffrey W. Baker ([EMAIL PROTECTED]) wrote:
> On Wed, 24 May 2000, Peter Haworth wrote:
> > Jeffrey W. Baker wrote:
> > > On Wed, 24 May 2000, Peter Haworth wrote:
> > > > Jeffrey W. Baker wrote:
> > > > > myInput = hfTextInputNew();
> > > > > myInput->addAttr(myInput, "name", "first_name");
> > > > > myInput->addAttr(myInput, "value", "Jeffrey");
> > > > > printf("%s\n", myInput->render(myInput));
> > > > > myInput->destroy(myInput);
> >
> > Is this C or C++? If C, do you have a member for each function in the
> > struct, and if it's C++, why are you passing myInput twice? Or maybe you
> > just got carried away with your example.
>
> It's C with function pointers as struct members.
That seems a little excessive to me spacewise, but I guess it means you can
keep the functions static, and not confuse users with differently named
functions to do the same thing with different types of input.
> > > Actually, there is another way, and that is to simply build a linked
> > > list of attributes. It doesn't matter what order you put the
> > > attributes in, so I just add them to the head of the list for
> > > performance. Adding to the head of a list is faster than hashing
> > > anyway. If you use the setAttr(self *, char *, char *) method, the list
> > > has to be scanned, but is is likely to be so short as to not matter.
> >
> > OK, that seems sensible. There's no reason to go overboard to get more
> > hash-like semantics, when you'll generally just be stuffing things in,
> > then reading them all out.
>
> Exactly. The mainstream use case is to add things and then render. The
> capability to remove and change things exists, but doesn't need to be as
> streamlined.
>
> > > The other advantage here is storage space. An attribute in this
> > > implementation takes up only 4*sizeof(void *) + strlen(name) +
> > > strlen(value) + 2.
> >
> > Is it a doubly linked list, or are you storing something other than name,
> > value, next?
>
> Doubly-linked. You aren't sweating those extra 32 bits are you? ;)
It's just that you said you were adding at the list head for performance. I
can't see the need for a doubly linked list if you don't have a pointer to the
tail.
> > Well, personally, I'd have sorted my options before setting them up.
> > Otherwise you need unnecessarily complicated comparison functions to
> > keep your "Please select something" option at the top. ALthough, if it
> > works that way, adding options to a select has to add to the tail of the
> > list, or you'd have to add your options in reverse order.
>
> If the options are sorted before adding, then you just wouldn't call the
> sort() method. Or maybe it would be sortByValue() and
> sortByLabel(). That sounds more flexible.
Not sorting still gets my vote. There are too any cases where you can't sort on
just the value or just the label.
Anyway, I'd still like to see the code. In the meantime, HTML::StickyForm will
probably start off in pure perl. The internals can always be rewritten to use
your library at some point in the future.
--
Peter Haworth [EMAIL PROTECTED]
The world is coming to an end. Please log off.
Re: Form generation libraries
Jeffrey W. Baker wrote:
> On Wed, 24 May 2000, Peter Haworth wrote:
> > Jeffrey W. Baker wrote:
> > > myInput = hfTextInputNew();
> > > myInput->addAttr(myInput, "name", "first_name");
> > > myInput->addAttr(myInput, "value", "Jeffrey");
> > > printf("%s\n", myInput->render(myInput));
> > > myInput->destroy(myInput);
> > >
> > > I would expect a similar interface with more methods for a select box,
> > > e.g. mySelect->addOption(mySelect, myOption), and myOption->select.
Is this C or C++? If C, do you have a member for each function in the struct,
and if it's C++, why are you passing myInput twice? Or maybe you just got
carried away with your example.
> > Where do you store those attributes before you do the rendering? If you
> > tie yourself to Apache, you could use tables. If you tie yourself to perl,
> > you can use hashes. Otherwise you have to do your own hashes. Blech,
> > especially if you then use the library with Apache and/or perl - wasted
> > effort.
>
> Actually, there is another way, and that is to simply build a linked list
> of attributes. It doesn't matter what order you put the attributes in, so
> I just add them to the head of the list for performance. Adding to the
> head of a list is faster than hashing anyway. If you use the
> setAttr(self *, char *, char *) method, the list has to be scanned, but is
> is likely to be so short as to not matter.
OK, that seems sensible. There's no reason to go overboard to get more
hash-like semantics, when you'll generally just be stuffing things in, then
reading them all out.
> The other advantage here is storage space. An attribute in this
> implementation takes up only 4*sizeof(void *) + strlen(name) +
> strlen(value) + 2.
Is it a doubly linked list, or are you storing something other than name,
value, next?
> > Bear in mind that it's nice to be able to support arbitrary attributes for
> > things like onMouseClick and the like, horrible though they are. This
> > means that you can't just define structs with members dedicated to
> > specific attributes.
>
> Done. The same approach is also used for adding options to a select box,
> although a select box will have an additional sort() method.
Well, personally, I'd have sorted my options before setting them up. Otherwise
you need unnecessarily complicated comparison functions to keep your "Please
select something" option at the top. ALthough, if it works that way, adding
options to a select has to add to the tail of the list, or you'd have to add
your options in reverse order.
--
Peter Haworth [EMAIL PROTECTED]
"Well, let's just say, 'if your VCR is still blinking 12:00, you don't
want Linux'". --Bruce Perens, Debian's Fearless Leader
Re: Form generation libraries
Jeffrey W. Baker wrote:
> I have read all of the messages in regarding the zygotic
> HTML::Forms/FormGen project, and I like the idea. However, I hope that
> the inplementation of such a beast isn't in Perl. To ensure that a
> quality product results, I propose that this library be written in C, and
> also in an object-oriented fashion.
>
> What I propose is an object interface to the various form input types, as
> well as some higher level functionality that encapsulated what people
> frequently do with HTML forms. For example, I would expect the C
> interface to look something like this:
>
> myInput = hfTextInputNew();
> myInput->addAttr(myInput, "name", "first_name");
> myInput->addAttr(myInput, "value", "Jeffrey");
> printf("%s\n", myInput->render(myInput));
> myInput->destroy(myInput);
>
> I would expect a similar interface with more methods for a select box,
> e.g. mySelect->addOption(mySelect, myOption), and myOption->select.
Where do you store those attributes before you do the rendering? If you tie
yourself to Apache, you could use tables. If you tie yourself to perl, you can
use hashes. Otherwise you have to do your own hashes. Blech, especially if you
then use the library with Apache and/or perl - wasted effort.
Bear in mind that it's nice to be able to support arbitrary attributes for
things like onMouseClick and the like, horrible though they are. This means
that you can't just define structs with members dedicated to specific
attributes.
> The Perl wrapper around this library is pretty obvious, and can use the
> object-oriented approach also. We can build upon that with an
> enhanced-for-mod_perl interface.
>
> I expect that a C implementation will be ideal from the standpoint of
> speed and also memory. I have taken the liberty of implementing the
> neccessary code for the text input type, and the object code is a whopping
> 2116 bytes, which is mostly base class logic that won't be duplicated for
> the other types. The implementation is also quite fast, rendering 10
> simple text inputs to /dev/null in .78 seconds, without optimizations.
Sounds good.
> If people think this is the way to go, I will write up a Makefile and
> release the code.
I'd like to see it, or at least an explanation of the issues mentioned above.
--
Peter Haworth [EMAIL PROTECTED]
Everything can be filed under "miscellaneous."
--Dilbert's Laws
Re: RFC: Apache::Request::Forms (or something similar)
Vivek Khera wrote: > >>>>> "PH" == Peter Haworth <[EMAIL PROTECTED]> writes: > > >> > >> HTML::Form? :) > > PH> Well, duh! Why didn't I think of that? Unfortunately though, > PH> HTML::Form already exists, and doesn't really do the same kind of > PH> thing. How about HTML::FormGen? > > How 'bout HTML::StickyForms ? OK, that's two votes, and I like it as well. HTML::StickyForms (or possibly HTML::StickyForm) it is then. -- Peter Haworth [EMAIL PROTECTED] A host is a host from coast to coast & no one will talk to a host that's close Unless the host (that isn't close) is busy, hung or dead
Re: RFC: Apache::Request::Forms (or something similar)
brian moseley wrote: > On Mon, 22 May 2000, Peter Haworth wrote: > > In light of the non-dependency on mod_perl, the > > Apache::Request::Form name is also out. I'd still rather > > not use the CGI::Form name, in case there are any > > current users whose interface would change, which is a > > shame, because that seems like the most appropriate > > name. Erk, any ideas, or proof that no-one uses the > > existing CGI::Form? > > HTML::Form? :) Well, duh! Why didn't I think of that? Unfortunately though, HTML::Form already exists, and doesn't really do the same kind of thing. How about HTML::FormGen? > > I'd prefer to stick with one style of interface, to keep > > things small and simple. Named parameters as above seem > > most flexible, and allow for unexpected things like > > omMouseOver attributes to be added easily. I'm inclined > > to only allow method style calls, although I suppose > > there's nothing wrong with allowing people to import the > > methods and call them like this: > > > > print textfield($form,name => 'name', ...); > > agree all the way. Good. Anyone disagree? -- Peter Haworth [EMAIL PROTECTED] "The day Microsoft makes something that doesn't suck is the day they start making vacuums"
Re: RFC: Apache::Request::Forms (or something similar)
brian moseley wrote: > On Wed, 17 May 2000, Vivek Khera wrote: > > > I think the name CGI::Form is appropriate, since the > > forms are part of the CGI protocol, not anything > > mod_perl or Apache sepecific. CGI::Form seems to be an > > abandoned module, so I'm sure you can get permission to > > adopt it and extend it. > > actually forms are specified in HTML, not CGI. > > peter: i question why you want to subclass Apache::Request, > rather than provide a helper class that maybe maintains a > reference to an Apache::Request object, or some other weaker > type of relationship. Thanks to all the discussion, I'm coming round to the helper class idea. It was really only that I hadn't thought of it myself, and that I thought I'd found an omission in Apache::Request which didn't exist, which I could fix at the same time. > consider writing your forms library to depend on an > interface, not a specific class, so that users can provide > either a CGI object or an Apache::Request object. perhaps > the only interface you need is $obj->param? That's fairly likely. How about this kind of interface? my $form=CGI::Form->new($r); # Except for the name. See below # Or: my $form=CGI::Form->new($cgi); print $form->textfield(name => 'name', size => '60', default => 'Peter'); In light of the non-dependency on mod_perl, the Apache::Request::Form name is also out. I'd still rather not use the CGI::Form name, in case there are any current users whose interface would change, which is a shame, because that seems like the most appropriate name. Erk, any ideas, or proof that no-one uses the existing CGI::Form? I'd prefer to stick with one style of interface, to keep things small and simple. Named parameters as above seem most flexible, and allow for unexpected things like omMouseOver attributes to be added easily. I'm inclined to only allow method style calls, although I suppose there's nothing wrong with allowing people to import the methods and call them like this: print textfield($form,name => 'name', ...); -- Peter Haworth [EMAIL PROTECTED] "The Feynman Problem 1) Write down the problem. Solving Algorithm:2) Think real hard. 3) Write down the answer."
Re: RFC: Apache::Request::Forms (or something similar)
Drew Taylor wrote: > Doug MacEachern wrote: > > > > personally, i'd like to see Apache::HTML for generating html, written in > > c. something simple along the lines of HTML::AsSubs, then another class > > to glues it and Apache::Request together that provides CGI.pm features, > > like 'sticky forms'. but, i haven't given that much thought. > Well, I wouldn't mind doing it in C (since the raison d'etre is to be as > absolutely fast & lean as possible), but I don't know C. :-( I'd have no problem writing it in C, but I'm not convinced that the generality is helpful with something intended to be small and fast. That wouldn't stop us from rewriting the internals to a hypothetical Apache::HTML at some point in the future, though. I'm getting more confident about calling it Apache::Request::Form (no "s", for name similarity with CGI::Form) now. It is dependent on Apache::Request, after all, and reusing the CGI::Form name makes it look more general than it really is, not to mention any strange version skew effects CPAN.pm might introduce when people try to install things. -- Peter Haworth [EMAIL PROTECTED] "Where a computer like the ENIAC is equipped with 18,000 vacuum tubes and weighs 30 tons, computers in the future may have only 1,000 vacuum tubes and weigh only 1 1/2 tons." -- Popular Mechanics, March 1949
Re: RFC: Apache::Request::Forms (or something similar)
Autarch wrote: > On Wed, 17 May 2000, Peter Haworth wrote: > > > Drew Taylor and I are about to write a subclass of Apache::Request which > > includes form element generation methods, a la CGI.pm. The current > > favourite name is Apache::Request::Forms, but we'd like to know if > > anyone has a better one. > > There's going to be a new version of CGI some time in the future which > will allow you to only use the parts of it you need without all the memory > bloat. There's an alpha on Lincoln's page at > > http://stein.cshl.org/WWW/software/CGI/CGI.pm-3.01tar.gz > > With this and Apache::Request I'm not sure I see the need for what you > guys are working on. Without looking at the new CGI.pm, I'd say that the benefit of our new module would be that it's targetted specifically at mod_perl, so it should hopefully be smaller, and ideally it would be faster. The non-backwards compatible nature of the new interface also allows us to cut down on some of the overhead of CGI.pm's need to figure out which calling style is used. -- Peter Haworth [EMAIL PROTECTED] "Who needs horror movies when we have Microsoft"? -- Christine Comaford, PC Week, 27/9/95
RFC: Apache::Request::Forms (or something similar)
Drew Taylor and I are about to write a subclass of Apache::Request which
includes form element generation methods, a la CGI.pm. The current favourite
name is Apache::Request::Forms, but we'd like to know if anyone has a better
one.
The module is currently planned to be fairly bare-boned, only adding form
element generation methods for methods which will benefit from CGI.pm-style
sticky values, and the parameters these methods take are likely to be a lot
more restricted than CGI.pm's (not difficult, really). However, this could
change in the unlikely event that we get deluged with feature requests.
--
Peter Haworth [EMAIL PROTECTED]
"We're sorry. The brain you have mailed has been disconnected or is no longer
in service. Please re-check the address and send your message again.
If you feel you have reached this recording in error, JUST STOP CREATING EVIL
PUNCTUATION OPERATORS, SO CHIP'S BRAIN WILL STOP EXPLODING. Thank you."
-- Chip Salzenberg
Re: Newbie Question -
Drew Taylor wrote: > What I would really like is a module which subclasses Apache::Request, > and has the popup_menu, scrolling_list, and checkbox group methods > available. That way I can use the smaller (faster) Apache::Request and > still have the few HTML generation methods that I need. This would be > similar to Apache::RequestNotes. One day I'll actually do it when I > convert my CGI scripts to perl handlers... I've written one, but to get it released on CPAN would mean months of legal wrangling, which I'm already going through with my shared cache module. It's easy enough to write for yourself though. Plus you get to restrict the API to one style which makes your code much simpler and faster than CGI.pm -- Peter Haworth [EMAIL PROTECTED] "Psychos do not explode when sunlight hits them. I don't give a f**k how crazy they are." -- Seth Gecko, _From Dusk Till Dawn_
Re: Caching DB queries amongst multiple httpd child processes
Peter Skipworth wrote: > Does anyone have any experience in using IPC shared memory or similar in > caching data amongst multiple httpd daemons ? We run a large-ish database > dependent site, with a mysql daemon serving many hundreds of requests a > minute. While we are currently caching SQL query results on a per-process > basis, it would be nice to share this ability across the server as a > whole. > > I've played with IPC::Shareable and IPC::ShareLite, but both seem to be a > little unreliable - unsurprising as both modules are currently still under > development. Our platform is a combination of FreeBSD and Solaris servers > - speaking of which, has anyone taken this one step further again and > cached SQL results amongst multiple web servers ? I've written my own solution to this, called Tie::MmapCache, which implements an LRU cache of data in a memory mapped file, which can be shared by an arbitrary number of processes. Unfortunately, it's not publically available yet, but I hope to get it released soon. -- Peter Haworth [EMAIL PROTECTED] "The warts in a language tend to be more orthogonal than the features" -- Larry Wall, at the Perl Conference 2.0
Re: squid performance
Gerald Richter wrote: > > > No, that's the size of the system call buffer. It is not an > > > application buffer. > > > > So how one should interpret the info at: > > http://www.apache.org/docs/mod/mod_proxy.html#proxyreceivebuffersize > > > > > > The ProxyReceiveBufferSize directive specifies an explicit network buffer > > size for outgoing HTTP and FTP connections, for increased throughput. It > > has to be greater than 512 or set to 0 to indicate that the system's > > default buffer size should be used. > > > > > > So what's the application buffer parameter? A hardcoded value? > > > > Yes, as Joshua posted today morning (at least it was morning in germany > :-), the application buffer size is hardcoded, the size is 8192 (named > IOBUFSIZE). You will find it in proxy_util.c:ap_proxy_send_fb(). > > The ProxyReceiveBufferSize set the receive buffer size of the socket, so > it's an OS issue. I've patched my frontend server so that there are two buffer sizes: ProxyReceiveBufferSize sets the socket buffer size ProxyInternalBufferSize sets the application buffer size This meant renaming ap_breate() to ap_bcreate_size() and adding a size parameter, which defaults to IOBUFSIZE if 0 is passed. Then add #define ap_bcreate(p,flags) ap_bcreate(p,flags,0) and add a new ap_bcreate() which calls ap_bcreate_size() for binary compatibility (actually I haven't added the new ap_bcreate() yet, and I never got round to sending this to the Apache development group). This is all necessary because some of the proxied pages on my site are large PDF and PS files which can't be cached due to security resaons. I have the socket buffer set to the max allowed 64K (on Solaris), with a 1M application buffer. In my opinion, ProxyReceiveBufferSize should be called ProxySocketBufferSize, leaving the old name free for my new use. This would also remove some of the confusion about what it actually does. -- Peter Haworth [EMAIL PROTECTED] "Save the whales. Feed the hungry. Free the mallocs."
Re: [Re: [Re: again - more then one PerlTransHandler]]
Doug MacEachern wrote:
> > At least that's what I thought !
> >
> > In fact now Apache lets me use more then one
> > PerlTransHandler, but it doesn't care
> > of what is the return codes are!!!
> >
> > Even I return OK, it still calls
> > next registered handlers. Really weird!
>
> mod_perl does care. but, mod_perl stacked handlers are not quite the same
> as Apache C handlers. unless the return status from a Perl handler is
> something other than OK or DECLINED, mod_perl propagates the status code
> of the last handler run back up to Apache.
> originally, stacked handlers were introduced for chaining multiple content
> handlers. if the OK status from the first handler was propagated back to
> Apache, there would be no chain, and little use for stacked handlers.
>
> you can always override this behavior by using a single Perl*Handler which
> decides what path to take based on the return status, or use a
> PerlDispatchHandler, or PerlDirectiveHandlers, to name a few.
I've got round this by having a module which adds a JournalsTrans directive,
which says which trans handlers to apply, then have just one PerlTransHandler,
which processes them all:
httpd.conf:
PerlTransHandlerJournals::Frontend::handle_trans
JournalsTrans /EJ Journals::EJ::handle_trans
JournalsTrans /EJ/Admin Journals::EJ::Admin::handle_trans
JournalsTrans /Journals Journals::Info::handle_trans
sub Journals::Frontend::handle_trans{
my($r)=@_;
# Fetch handlers configured by Journals::Config
if(my $cfg=Apache::ModuleConfig->get($r,'Journals::Config')){
if(my $trans=$cfg->{JournalsTrans}){
my $uri=$r->uri;
foreach(@$trans){
my($test_uri,$uri_sub,$sub)=@$_;
if($uri_sub->($uri)){
my $code=$sub->($r,$test_uri);
return $code
if $code!=DECLINED;
}
}
$r->log->error("No handler matching $uri found");
}else{
$r->log->crit('No JournalsTrans module config found');
}
}else{
$r->log->crit("Can't retrieve module config");
}
return DECLINED;
}
--
Peter Haworth [EMAIL PROTECTED]
If a packet hits a pocket on a socket on a port
& the bus is interrupted as a very last resort
& the memory address makes your processes abort
then the socket packet pocket has an error to report!
Re: eval'ed Apache::Session tie panics with POPSTACK?
Tobias Hoellrich wrote:
> I wanted to trap non-existant session-id's by bracketing the
>
> tie %{$href}, 'Apache::Session::DBI', $id,
> {
>DataSource => 'dbi:mysql:sessions',
>UserName => 'db_user',
>Password => 'db_passwd'
> };
>
> with an eval { }; block. Once I've done this and send a non-existant
> session-id I get the following in my error_log:
>
> panic: POPSTACK
> Callback called exit.
This is a bug in perl, caused by Carp::croak being called inside eval. It's
fixed in 5.005_62, but you might not want to go to a development version.
Unfortunately, I've never used Apache::Session, so I don't know how you can
avoid the call to croak.
--
Peter Haworth [EMAIL PROTECTED]
"I think that's very legible. If you don't, you need to read more perl."
-- Tom Christiansen
