ANNOUNCE: Mason 1.23
1.23 [ ENHANCEMENTS ] - Lots of enhancements to the Apache.pm emulation when using the CGIHandler module. Implemented by David Wheeler. - The fact that autohandlers or dhandlers can be turned off by setting autohandler_name or dhandler_name to has now been documented, and we explicitly check for this in the code. Task id #499. - The ApacheHandler module now catches exceptions thrown from the Interp class's make_request method. With the default Mason Interp Request classes, this will never happen. However, subclasses may want to throw exceptions when constructing a request. Implemented by David Wheeler. [ BUG FIXES ] - If any code type parameters were set in the httpd.conf file, Mason died trying to read them. This bug was introduced in version 1.20. Task id #496. Reported by David Wheeler. - $m-caller, $m-callers and $m-caller_args now return undef or an empty list instead of crashing when the specified stack level does not exist. Task id #495. Reported by Bernhard Schmalhofer. - The busy_lock option to $m-cache-get did not accept did not accept string values for durations, like 4m. Task id #484. Reported by Igor Muratov. - When generating the HTML error message page, we now only use basic HTML escaping. This fixes two problems. One is that if HTML::Entities is not installed, using the |h escape flag in the error display component causes an endless loop. The other is that the |h flag can mangle non-Latin-1 characters. Task ids #497 and #494. Reported by Harmen and Oleg Bartunov respectively. - If a component generated output, then called another component via $m-scomp, and that other component attempted to clear the buffer and then abort, any output generated before the call to $m-scomp was still sent to the client. This broke calling $m-redirect inside an $m-scomp call. Task id #498. Reported by Kim Alexander Hansen. -- Forwarded message -- Date: Mon, 8 Sep 2003 18:45:01 +0200 From: PAUSE [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: Dave Rolsky [EMAIL PROTECTED] Subject: CPAN Upload: D/DR/DROLSKY/HTML-Mason-1.23.tar.gz The uploaded file HTML-Mason-1.23.tar.gz has entered CPAN as file: $CPAN/authors/id/D/DR/DROLSKY/HTML-Mason-1.23.tar.gz size: 326918 bytes md5: b1029cc9dce53d5a9a58275e24f96625 No action is required on your part Request entered by: DROLSKY (Dave Rolsky) Request entered on: Mon, 08 Sep 2003 16:43:12 GMT Request completed: Mon, 08 Sep 2003 16:45:01 GMT Thanks, -- paused, v441
Re: Templating system opinions (CGI::Application in connection witheither HTML::Template or Template::Toolkit)
On Wed, 23 Jul 2003, Eric wrote: do it all type of system. That is what made me avoid Mason, it just blew my head off for complexity. Now it is true, I am looking for a bit more than There's a fine book about it. www.masonbook.com Just an unbiased opinion ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: templating system opinions
On Mon, 21 Jul 2003, Drew Taylor wrote: I personally have not seen an official announcement, but if you look at all their postings on jobs.perl.org you'll notice that nearly every one of them mentions Mason. I'm sure Dave will have more to say on the subject... :-) Not too much more. But hopefully more will be forthcoming from people closer to Amazon than I. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: templating system opinions
On Mon, 21 Jul 2003, Patrick Galbraith wrote: I'm guessing they use it for IMDB, although they may have other projects as well that use it. I do know that their core app is C++/apache, with some sort of perl glue to talk to the app. I believe IMDB uses mod_perl, but I don't know about Mason. I know Amazon is using Mason for _Amazon_, not things they've bought. They're using it for the their apparel shop, among other things. I don't want to say too much more because I'm hoping for a bigger announcement from more reputable sources, but I can't promise anything ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: templating system opinions
On Mon, 21 Jul 2003, Sam Tregar wrote: On Sun, 20 Jul 2003, Dave Rolsky wrote: OTOH, if you were to try to replicate some of Mason's more powerful features with H::T, like autohandlers, inheritance, etc., then I'm sure that'd bring H::T's speed down to Mason's level ;) I wouldn't be too sure. I implemented a lot of that stuff to add HTML::Template support to Bricolage and it's still much faster than Mason. A lot as in _all_ of it, or a lot as in autohandlers and dhandlers? I'll believe it when I see it. There's nothing about Mason that's particularly slow except the code that implements the features. In other words, I don't think one could do all of the same stuff, or even most, and achieve a huge speed increase. There would have to be something sacrificed. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: templating system opinions
On Sun, 20 Jul 2003, Jamie Lawrence wrote: H::T is much more programmer-centric. In a lot of contexts, that makes sense. Informally (as in, I haven't done a systematic comparison), it is also faster than Mason. Mason isn't slow, but if you need every last gram of performance, well, you probably shouldn't be using a general framework anyway. And yes, they're all RAM-intensive. I don't actually care that much - RAM is cheap for general purpose servers. Actually, H::T is almost certainly _much_ faster and less RAM-intensive than Mason, at least when you measure the time it takes to serve a single page/component. OTOH, if you were to try to replicate some of Mason's more powerful features with H::T, like autohandlers, inheritance, etc., then I'm sure that'd bring H::T's speed down to Mason's level ;) In other words, you generally get what you pay for. The most powerful and flexible systems are generally slower and more RAM-hungry. One exception to this might be Embperl, which has large chunks written in C. In that case, the cost is paid for in development time. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: templating system opinions
On Sun, 20 Jul 2003, Patrick Galbraith wrote: I've been working at Classmates.com for a couple months contracting, and they use Text::Forge. I've been impressed by the performance, and wish it was a big player. Part of the reason it isn't is guys like me should contribute to it and make it a bigger player. I'd say the big reason it's not a big player is that it doesn't offer anything new. It also doesn't seem to be very actively developed and has very little documentation. I really like the syntax - it looks a lot like JSP. Yeah, just like Apache::ASP ;) All of this said, what is the most commonly used system out there? The biggest players are Mason and Template Toolkit, judging from big companies that have used them, as well as job posting. HTML::Template, Embperl, and Apache::ASP all seem to have reasonably active user bases as well. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: templating system opinions
On Sun, 20 Jul 2003, Jamie Lawrence wrote: Mason isn't fast. It is, however, fast enough for high volume sites - that I will assert. Sure, amazon.com among them. From my view, the utility of autohandlers and dhandlers, in terms of code written vs. cost and time, is an enormous win. Add to that the flexibility between library developmers and HTML coders, in that there's a constant feedback loop that enforces reasonable development and interaction to ensure that all roles are working for the same goal. I'm not gonna disagree with you. I consider Mason's features well worth the speed/memory costs. That's why I use it and develop it ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: templating system opinions
On Fri, 18 Jul 2003, Patrick Galbraith wrote: TT was ok, but it did use a bunch of ram ;) So does Mason. HTML::Template is no doubt much leaner, but it's also lean on features. Nothing wrong with that if it suits your needs, though. Most Perl templating systems are probably slower and/or bulkier than PHP. The best counter for PHP folks is one word, CPAN ;) Also, Mason at least provides lots of features beyond templating, and is as much of an app framework as anything. This may be true of TT and the others, I'm not really sure. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
ANNOUNCE: Mason 1.22
1.22 July 14, 2003
[ ENHANCEMENTS ]
- Added $m-has_content to check for content without evaluating it.
- Comments are now allowed on separate lines inside %attr and
%flags blocks. Task id #475.
- $m-subexec and $m-make_subrequest now accept relative paths which
are interpreted relative to the current component directory, like
$m-comp.
- Documented potential problems if call to $m-redirect is trapped in
an eval block, and then output is generated before the exception is
rethrown. Task id #477.
[ BUG FIXES ]
- If a component with a filter section called abort, the filter was
run twice. Task id #473.
- If an exception was thrown when creating a request, memory was
leaked. This can happen when the top-level component cannot be
found (e.g. 404) or if there is an error in compiling the top-level
component. Task id #478. Reported by Doug Treder.
- Removed the use of alarm() and SIG{ALRM} to trap rare infinite loops
inside the compilation of components. It interfered with Mason
environments that use alarm() for their own purposes, and the
associated test would crash in certain Perl environments. If you find
that Mason sometimes enters an infinite loop, see the
Hanging Processes: Detection and Diagnostics section of the mod_perl
guide for hints on diagnosing the problem. Task id #472.
- Mason allowed a component to define two subcomponents or methods
with the same name. Task id #476. Reported by John Michael Mars.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: must I use mod-perl
On Sun, 13 Jul 2003, Oskar wrote: Install it if you have a lot of time. It took me week to config it and month for rewritting scripts. If you're using a system that has some sort of packages, then there are probably mod_perl packages for it. Installing mod_perl on a Debian GNU/Linux systems takes about as long as the download plus 1 minute. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: [ANNOUNCE] libapreq-1.1 is out
On Tue, 28 Jan 2003, Joe Schaefer wrote: libapreq-1.1 is now available on CPAN, and also through the Apache website at http://www.apache.org/dist/httpd/libapreq/libapreq-1.1.tar.gz What are the difference between this version and 1.05? The changelog ends at 1.05. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
[JOB SEEKER]: Looking for consulting work
Hello, mod_perl folks, I've recently decided it's time to go the consulting route and I'm looking for consulting gigs. I have quite a bit of experience with mod_perl, and Mason especially, plus database design, application design, and much more. I'm open to short or long term projects, including design, coding, code review, and training. I have a spiffy web site at http://www.houseabsolute.com/, which has more details on what I can do, as well as my resume and a list of some previous clients. Outright gifts of cash, bearer bonds, brand new cars, or other valuables are also welcome. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
RE: OSCON ideas - missing proceedings
On Thu, 9 Jan 2003, Nathan Torkington wrote: Mark Schoonover writes: Any chance they will bring it back to San Diego?? :) Not for two years at least (the duration of the contract with the Portland hotel). The San Diego hotel was much more expensive and remote, compared to the Portland hotel. I think people are really going to enjoy being in the middle of a city at this year's OSCON. Hallelujah to that, brother! San Diego was gorgeous, and the hotel was nice, but I didn't rent a car, and just doing stuff like getting to the city for lunch (on the days when lunch wasn't served) was a giant PITA, compounded by the fact that I'm vegan, so I can't go just anywhere and be guaranteed that they'll have something I'd want. And a less-expensive place is also a good thing. The San Diego Sheraton was _expensive_, and since I'll be footing the bill (hopefully only partially if I can get a tutorial accepted ;) cheaper is good! -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: OSCON ideas
On Thu, 9 Jan 2003, Jonathan M. Hollin wrote: Perrin Harkins wrote: (http://conferences.oreillynet.com/cs/os2003/create/e_sess). I'm thinking about possible talks to submit and I want a little feedback on what people are most interested in. Here are two options I'mconsidering: I would be extremely interested in talks covering any work that our Perl gurus have done using Bayesian Rules. I am particularly interested in the usage of Bayesian rules for search-engines, spam management, log analysis, firewalling and encryption - has anybody ever covered any of these fields? Ken Williams has. Ken? -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: [OT] Re: OSCON ideas
On Thu, 9 Jan 2003, Larry Leszczynski wrote: But even if Perrin's OSCON talk (hint hint) gave me some valuable ammunition to show that I could just as easily design on top of a Perl-based application framework as on J2EE, we still come back around to the perception that it's easier to find Java programmers. My theory is that it takes a heck of a lot more bodies to build a J2EE app than it does to build a Perl app. So maybe you just need more Java programmers to get anything done at all in Java ;) Seriously, I think there is some truth to this. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: development techniques
On Thu, 9 Jan 2003, Thomas Bolioli wrote: I use my debugging module (http://cpan.perl.org/authors/id/T/TB/TBOLIOLI/Log-AndError-0.99.tar.gz) which prints to stderr (hence I got bit by the mod_cgi issues with read/write deadlocks on pipes) while tailing the logs, etc. I am looking to include a syslog and other output drivers to my mod which should allow for more fancy versions of the tail -f method. Rather than re-inventing that wheel why not take a look at Log::Dispatch and Log4Perl. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: OSCON ideas - MVC talk
On Thu, 9 Jan 2003, Stas Bekman wrote: Stas Bekman wrote: Since the submission deadline is one week that certainly would not happen. For some reason I thought the deadline was Jan 15th, I see that it's Feb 15th. Wow, you scared the crap out of me for a second. I want to submit some talks but it would have been a scramble to submit some for next week! -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Internal redirect to method handler bug?
A user on the Mason list reported a problem when the used an internal redirect pointed at a location handled by Mason. What was happening is that the HTML::Mason::ApacheHandler module, which has a _method_ handler sub (sub handler ($$)) was being called without a package name (just $r) because of the internal redirect. I tried to make a bare bones config that duplicated the problem, but my really simple config worked just fine. Does this bug ring any bells? -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Internal redirect to method handler bug?
On Fri, 3 Jan 2003, Dave Rolsky wrote: A user on the Mason list reported a problem when the used an internal redirect pointed at a location handled by Mason. What was happening is that the HTML::Mason::ApacheHandler module, which has a _method_ handler sub (sub handler ($$)) was being called without a package name (just $r) because of the internal redirect. I tried to make a bare bones config that duplicated the problem, but my really simple config worked just fine. Does this bug ring any bells? Aha! I just found this in the archives (which I looked at before posting, but not carefully enough): http://marc.theaimsgroup.com/?l=apache-modperlm=101236133418008w=2 The above message says this happened with version 1.25 1.26, but the Mason user who reported the problem is using 1.27, so it hasn't been fixed yet. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
ANNOUNCE: HTML::Mason 1.16
This is the latest action-packed release of HTML::Mason, with more bloody fights, steamy sex, and outrageous laughs than ever before. Thrill ... as an autohandler calls the next component in the chain. Tremble ... at the awesome might of the wicked dhandler. Cry ... for the humble subcomponent. This release fixes a bunch of bugs, including one potentially serious memory leak (if you created many Interp objects). It also includes a much rewritten version of the Admin Guide. Comments and suggestions on this are welcome for future releases. Have fun. Changes 1.16 December 13, 2002 [ ENHANCEMENTS ] - Documented behavior of $m-flush_buffer when a filter is present. - Turned off nowrap for error message on HTML error page. No more horizontal scrolling! - Substantially rewrote portions of the Admin Guide, in order to improve and clarify the portions related to configuring and customizing Mason under mod_perl. - Added back raw error on HTML error page. - Replaced FilesMatch with LocationMatch in docs and FAQ, because using FilesMatch means you can't use dhandlers. - Reduced memory usage when compiling large components. Memory usage for smaller components hasn't changed much, but they weren't really a problem in the first place. - Added a cgi_request method to the CGIHandler::Request object, which parallels the apache_req method offered by the ApacheHandler::Request object. [ BUG FIXES ] - When using the code cache within an Interp, a circular reference was created which prevented the Interp object from ever being destroyed. With Perl 5.6.0+, this will be automatically prevented by using weak references as needed. With Perl 5.00503, you will need to call the new Interp-flush_code_cache method in order to break the circular reference. This bug could cause memory leaks with code that created new Interp objects over time, though most uses of Mason do not do this. Reported by Kate Porter. - Fixed bad parsing of % $foo || 50 %. Mason was interpreting this as an escape flag. Escape flags now much match /^[[:alpha:]_]\w+/ and Mason specifically looks for || in a substitution as well. Reported by Kwindla Kramer. - If a dhandler one subdirectory down (like /foo/dhandler) called $m-decline, Mason threw a bogus exception. Fixed by Harmen. - Running the test suite caused an error in the shell on Win32 with newer versions of MakeMaker. Reported by Murat Unalan. (We _think_ this is fixed but we'd like confirmation from a Win32 user). - It was not possible to set the data_cache_defaults parameter from the httpd.conf file. Now it is. - Mason was using Apache::Request-new instead of Apache::Request-instance. This meant that if you had a handler that ran earlier (like a TransHandler) and that handler created an Apache::Request object, then the one Mason created would be missing any POST arguments. Reported by Ray Zimmerman. - Several different places in the docs said that Cache::Cache accepts a username option, but there is no such thing. - alter_superclass didn't work with CGIHandler because CGIHandler didn't define a $VERSION variable. Reported by Nadine and Harry Laxen. - Made CGIHandler merge together POST and query string arguments in order to be consistent with ApacheHandler. Reported by Nadine and Harry Laxen. - The CGIHandler module was overriding any out_method provided by the user. Reported by Nadine and Harry Laxen.
Mason book is available
According to various online retailers, the book is now actually shipping. Check out http://www.masonbook.com/ and http://www.oreilly.com/catalog/perlhtmlmason/ for more info. The latter URL includes the TOC, index, and a sample chapter. -dave /*== www.urth.org we await the New Sun ==*/
Re: Random broken images when generating dynamic images
On Thu, 24 Oct 2002, Paolo Campanella wrote: On a page with 5 different dynamic images (all generated by the same chunk of code, it's a set of graphs), I'll often see 1 or 2 as a broken image, but the rest work. Sometimes all 5 are ok. Unlikely to be your problem, but I had something similar once when running too few backend mod_perl httpds on a development box. I don't think this is it because I've seen this when testing on a system with plenty of backend httpds (MaxClients at 50 or so). -dave /*== www.urth.org we await the New Sun ==*/
Random broken images when generating dynamic images
So here's the situation. I have some code that generates images dynamically. It works, mostly. Sometimes the image will show up as a broken image in the browser. If I reload the page once or twice, the image comes up fine. On a page with 5 different dynamic images (all generated by the same chunk of code, it's a set of graphs), I'll often see 1 or 2 as a broken image, but the rest work. Sometimes all 5 are ok. I tried out a scheme of writing them to disk with dynamically generated files, but since I still need to do some auth checking, they end up being served dynamically and I have the same problem. To make it even weirder, I just took a look at one of the image files that showed up as broken, and it's fine (I can't view it directly in my browser). I can't for the life of me figure out what the heck is going on. It seems that the image data is just fine. Could the browser be timing out for some reason? This has been seen in multiple browsers too (Galeon and IE, at least) so it's not browser-specific. I'd love to fix the root cause, but a workaround would be fine too. The fundamental problem is that there's no way to not have some code involved in this process because there needs to be some auth checking before the image is served. Any help would be much appreciated. -dave /*== www.urth.org we await the New Sun ==*/
Re: Random broken images when generating dynamic images
On Wed, 23 Oct 2002, Dave Rolsky wrote: I have some code that generates images dynamically. It works, mostly. Sometimes the image will show up as a broken image in the browser. If I reload the page once or twice, the image comes up fine. I should mention that I'm using Mason, and I haven't yet tried playing with a non-Mason based solution, but I am making sure to clear Mason's buffers before serving the image, and I abort the (Mason) request immediately after the image data is sent, so I don't think Mason is causing the problem. -dave /*== www.urth.org we await the New Sun ==*/
Re: Apache Hello World Benchmarks Updated
On Tue, 15 Oct 2002, Perrin Harkins wrote: Josh Chamas wrote: Set MaxRequestsPerChild to 100 for applications that seem to leak memory which include Embperl 2.0, HTML::Mason, and Template Toolkit. This is a more typical setting in a mod_perl type application that leaks memory, so should be fairly representative benchmark setting. Maybe I'm more careful about memory growth than some people, but 100 sounds a bit on the low side to me. I use Apache::SizeLimit instead of MaxRequestsPerlChild, but I'm pretty sure every child serves more requests than that. Did it seem to affect the performance numbers much? Incidentally, I hate to call this stuff memory leaks, since it's usually just normal growth as memory gets used. Calling it leaks implies that memory is being wasted as a result of mistakes with pointers or some such. When people hear memory leaks they go running for stuff like Apache::Leak, thinking they can find some problem and fix it, which is usually not the case. I'm fairly sure, FWIW, that Mason does not have any memory leaks, as of 1.12. Pre-1.10 versions do have a _very_ slow memory leak, and 1.10 and 1.11 had that leak plus another, much nastier one. Also FWIW, running Joshua's tests on my machine uniformly used about 1/3 to 1/4 as much RAM, with Mason, Template Toolkit and Apache::ASP. I too am running GNU/Linux, with a 2.4 kernel, on i386 hardware. The only difference in software was that I have Perl 5.8.0 installed, but I'd be incredibly shocked if that explained the difference. I've used Mason on a lot of machines, and I've found that processed between 15-30MB (with mod_perl are relatively normal. While this isn't tiny, it isn't nearly as bad as the 60MB monster Josh found. I'm actually pretty comfortable with Mason's memory usage because I think that certain features it offers explain its memory use. Basically, any framework that offers filtering features on generated output will need to store the entire output in memory before sending it, and I suspect this is one thing I think has a big impact on Mason's memory usage. -dave /*== www.urth.org we await the New Sun ==*/
Re: Apache Hello World Benchmarks Updated
On Mon, 14 Oct 2002, Josh Chamas wrote: This is interesting. I should look into upgrading to perl 5.8 on these tests see what difference there may be. You might also see if it makes a difference if you run the tests for a long enough time. I run them at least 60 seconds for these benchmarks which may make a difference. I ran the Mason 2000 test for 60 seconds and it only used about 20MB. I think that is how Gerald achieves his low memory footprints generally in Embperl, since he is doing most of his stuff in C it seems, and still offering all the advanced features we have in the other application frameworks. It might be worth trying to implement a few parts of Mason in C, particularly the Buffer class, though I'm not really sure I'm the one to do it, given my weak (and without honor) C skills. -dave /*== www.urth.org we await the New Sun ==*/
ANNOUNCE: Mason 1.15
This release is all about bug fixes. Basically, %filter blocks have been a bit borked in various ways (different in different releases) since 1.10, and now they should be in good shape. There were a number of test failures reported over the past several releases, almost of which were actually problems with the tests, and we think we've now taken care of those too (although I'm sure someone using Win32 will find some new weird bug for us ;) Finally, the docs in 1.14 had a number of bad links in the HTML versions, as well as some buglets in the POD. This should also be resolved. The goal for 1.1x is now to become as stable and well-documented as possible. We will not be adding any new large features, and small ones will have to either extremely well-contained or extremely well-justified. The next couple releases will aim to A) improve the docs, particularly focusing on a revamp of the Admin guide in regards to configuring Masona and B) improve performance wherever possible, and of course C) fix any remaining bugs. Eventually, we'll fork the code base again and start breaking things in preparation for an eventual 1.20 (or maybe some other version number cause we might get to 1.20 just by small bugfix/doc/performance releases), which will incorporate new features such as .NET compliance, full support for _all_ XML specs, and a special NP-problem solving module, plus a brand new set of ginsu knives. 1.15 October 14, 2002 [ BUG FIXES ] - Fixed a number of problems with filters: -- They didn't see changes made to %ARGS (they were seeing a copy). -- They couldn't see any variables declared in %args blocks. -- The presence of a filter caused a call to $m-flush_buffer, breaking redirects. - Added a number of tests for filters (*cough*). - Fixed broken links and other bugs in the POD and HTML versions of the docs. - Fixed test failures when running as root. These failures were not reflective of bugs in Mason, simply problems in the tests or test setup. Now we skip the tests for end user installs (we still run them during development, never fear). - HTML::Mason::Request contained code that caused an error when using the CPAN shell's r command. -dave (whose mind is apparently blown after several hours too many of Dance Dance Revolution earlier this evening) /*== www.urth.org we await the New Sun ==*/
ANNOUNCE: Mason 1.14
This release has lots of fun new stuff. It's _more_ backwards compatible
than 1.10-1.13, particularly as far as caching is concerned, which should
help those who are interested in upgrading. It has a brand new spiffy
user-defined escapes feature, which among other things allows you to
easily HTML-escape something besides ISO-8859-1 (or UTF8) text.
Plus a bunch of bug fixes, improved docs, and it's less filling (uses less
memory).
1.14 October 7, 2002
[ BACKWARDS COMPATIBILITY ]
- Added compatibility layer for 1.0x cache API. It is now possible to
use $m-cache and $m-cache_self in the old way by setting the
data_cache_api parameter to '1.0'. L{Params/data_cache_api}
- Added back $comp-create_time, which was renamed as $comp-load_time
in 1.09_02, as a deprecated method.
- Added back $interp-time and $m-current_time, which were removed in
1.09_01, as deprecated methods.
[ ENHANCEMENTS ]
- Implemented the long requested user-defined escapes feature. It is
now possible to define your own escape flags, as well as overriding
Mason's own 'h' and 'u' flags. L{Devel/Escaping expressions}
- Implemented expire_if and busy_lock options in new $m-cache-get
API. These retain the essence of the 1.0x options although both
work a little differently. L{Devel/Data Caching}
- Added new module to implement caching extensions,
HTML::Mason::Cache::BaseCache, with accompanying documentation.
- Enhanced Params.pod with TOC and full descriptions of all
parameters. Standardized rest of documentation to link to Params.pod
when referring to a parameter.
- When a component path is not found, but that path matches a file on
disk, we now print an extra warning, because this indicates that the
user does not understand the distinction between component paths and
filesystem paths.
- The Request object's redirect() method now accepts an optional
additional argument, allowing users to use a status code other than
302 for the redirect.
- Mason should now work on a box with a fresh mod_perl 2/Apache 2
install. Previously, Mason unconditionally tried to load
Apache::Status, which comes with mod_perl 1.x, but not (yet?) with
mod_perl 2.
[ BUG FIXES ]
- Installation was failing when Exception::Class wasn't installed.
- Calling %def subcomponents no longer changes base_comp, which is
important in autohandlers. (reported by Ian Robertson)
- The documentation incorrectly indicated that you could create an
ApacheHandler object during server startup without providing a
component root. This will also shown incorrectly in the sample
handler.pl in the eg/ directory.
- Reduced Mason's memory usage when compiling and serving components.
This is particularly noticeable with very large components (1-2MB or
greater). Work on this will continue for future versions. (reported
by Todd Holbrook)
- %ARGS and %shared variables could not be accessed from %filter.
(reported by Adam Roth)
- Switch.pm did not work in file-based components. (reported by Gert
Thiel)
- use_strict could not be turned off. (reported by Viacheslav
Voytovich)
- $m-clear_buffer (and $m-redirect) did not work inside a component
call with content. (reported by Manuel Capinha)
- Some tests were failing on Windows, because they assumed Unix style
filesystem paths. This was a problem with the tests, not the core
code, but still worth fixing. (reported by Adam Rinehart).
- $m-caller() was inadvertently left out of the documentation - fixed.
- Fixed a small documentation error about what kinds of things are
valid keys in %flags and %attr blocks.
- Configuring multiple component roots via the httpd.conf file failed
silently (as opposed to releases 1.10 - 1.12, where this failed with
an error).
- Unreadable component source files caused the confusing error message
source callback returned no source. This will now throw a much more
helpful exception.
- Errors occuring in subrequests would cause error output to be mixed
with regular output when the error_mode was output (the default with
ApacheHandler and CGIHandler). Errors in subrequests should now look
the same as errors in the top request.
/*==
www.urth.org
we await the New Sun
==*/
Re: passing an object to a handler
On Wed, 2 Oct 2002, william ross wrote:
I did have it set up that way at one point. it worked quite nicely as
long as I made the singleton in a subclass of the main Factory (which
might be shared by several applications with different configurations).
i gave up on it in the end because it seemed a bit overheated, but if
you approve, i shall reconsider.
I'm not quite following you. Overheated?
so, rehearsing: all it should take is a Factory::Subclass-new(config
blah) in the startup script and a Factory::Subclass-instance() in the
handler? it does sound good if you put it like that.
incidentally I made the singleton like this (yes, more poop):
use base qw (Class::DBI::Factory Class::Singleton);
...
sub _new_instance { shift-new(_) }
but it felt rather naughty to subclass the private _new_instance. if
anyone knows a better way, I'd be very glad to hear it.
Check out Class::Singleton.
-dave
/*==
www.urth.org
we await the New Sun
==*/
RedHat RPM for apache+mod_perl?
Has anyone here come up with an RPM for apache+mod_perl, with the following caveats: 1. mod_perl is statically compiled 2. I don't want SSL. This will be backend server. Only the frontend needs SSL. 3. can co-exist with a non-mod_perl Apache on the same system, meaning that it has its own config dir, pid file, logs, etc. 4. Including mod_rpaf would be a nice bonus, but adding this probably wouldn't be too hard. In other words, is there anything like the excellent apache-perl Debian package, but for Red Hat. ARGH, I really hate Red Hat. But in this case I'm stuck with it. I've been working on this myself for a few hours but I realized I should ask about it here first. -dave /*== www.urth.org we await the New Sun ==*/
Re: Apache::Session - What goes in session?
On Tue, 20 Aug 2002 [EMAIL PROTECTED] wrote:
Currently we are working on a 'per machine' cache so all
children can benefit for each childs initial database read
of the translated string, the differential between
children is annoying in the 'per child cache' strategy.
Sounds like you want BerkeleyDB.pm (not DB_File), which is quite fast and
handles locking/concurrent access internally (when set up properly).
See the Alzabo::ObjectCache::{Store,Sync}::BerkeleyDB modules for
examples.
For Alzabo, I also have a caching system that caches data in a database,
for cross-machine caching/syncing. I haven't really benchmarked it yet
but I imagine it could be a win in some situations. For example, you
could set up the cache as a separate machine running MySQL and still pull
your data from another machine, possibly running a different RDBMS.
-dave
/*==
www.urth.org
we await the New Sun
==*/
Re: ANNOUNCE: Mason 1.12
On 1 Aug 2002, Vivek Khera wrote: Cool... I just updated one system from 1.05 to 1.1201 and cpan says that HTML::Mason::ApacheHandler is now older than the version in 1.05: Package namespace installedlatest in CPAN file HTML::Mason::ApacheHandler 1.242 1.68 J/JS/JSWARTZ/HTML-Mason-1.05.tar.gz ... Can the version number for ApacheHandler get fixed up so CPAN doesn't think it is old? It can, but I'm not sure what to update it to. Frankly, I think CPAN is more at fault here given that _many_ people use CVS for this sort of stuff and this quite normal when using CVS. But we'll come up with something. -dave /*== www.urth.org we await the New Sun ==*/
Re: ANNOUNCE: Mason 1.12
On Thu, 1 Aug 2002, David Wheeler wrote: No, CVS is kind-of brain-dead about this. I suggest you use sprintf to properly format the version number with appropriate number of 0s. Although, with those version numbers, it might be a little late. See, that's the problem. We're up in the hundreds. Maybe we should've started formatting these with '%04d' way back when but that certainly wouldn't help now. We _could_ just jack up the first number, but that'd be a bit odd given that Mason itself is only at 1.1201. Or we could just use the CVS revision as an integer, not a float. That is weirder in some ways, but will just work right forever. -dave /*== www.urth.org we await the New Sun ==*/
ANNOUNCE: Mason 1.12
This release has a number of important improvements and it is highly recommended that anyone use Mason 1.10 or 1.11 upgrade immediately in order to fix a nasty memory leak in ApacheHandler. 1.12 is also quite a bit faster than previous 1.1x versions. Those folks still using 1.0x or earlier should upgrade if they want to play with new features, but should not that there are a number of backwards incompatibilities in the newest versions, so if you have working code in production that you don't want to change, don't upgrade! With that said, here are the changes for 1.12: 1.12 [ ENHANCEMENTS ] - Various optimizations have been added to this release in order to address the fact that Mason 1.11 is quite a bit slower than 1.05. One major factor was optimizing Params::Validate and Class::Container, so for that reason this version of Mason requires Params::Validate 0.24 and Class::Container 0.07. With these modules installed, this release shows improvements of up to 50-60% in benchmarks that stress Mason's weaknesses, with other benchmarks showing up to a 100% improvement. - Made subclassing CGIHandler more useful by breaking out its arg processing into a request_args method, just like ApacheHandler. - Added alter_superclass method to Request class, for use by Request subclasses. See the HTML::Mason::Subclassing document for details. [ BUG FIXES ] - Fix HTML generated for error messages so that tags balance out. Unbalanced table tags caused this page to not display properly with Netscape 4.x. - Fix nasty memory leaks in ApacheHandler.
[OT] Re: Hiding perl code
On Mon, 22 Jul 2002, Andreas J. Koenig wrote:
On Mon, 22 Jul 2002 13:10:25 +1000, Iain Truskett [EMAIL PROTECTED] said:
As far as I know, there's no good way to do it. It is Perl after all.
And with mod_perl things just get trickier.
Filter::decrypt does that. It's very hard to break as you compile a
self-made key statically into your perl. Filter::decrypt also disables
the debugger within that perl. Can also be done for mod_perl. The
encrypted modules look like this:
use Filter::decrypt ;
ÿ £j¨tBÓavð@¥£hK6' {'Þ^z'
[]
Of course, perl itself (or mod_perl) sees the cleartext, so a good
hacker will find a way to break it.
perl -MO=Deparse /path/to/encrypted/file(s)
-dave
/*==
www.urth.org
we await the New Sun
==*/
Re: [ANNOUNCE] Petal 0.1
On Wed, 17 Jul 2002, Rob Nagler wrote: Petal lets me do that. If that's not of any use to you, fine. The world is full of excellent 'inline style' modules such as HTML::Mason, HTML::Embperl and other Apache::ASP. These all work on the assumption that the template is written in HTML. Actually, neither Mason nor Embperl are HTML-specific these days. Mason never really was, and Embperl has become much more generic with version 2, which is in fact now simply called Embperl. Mason will probably changes its name eventually as well. -dave /*== www.urth.org we await the New Sun ==*/
Re: Propogating Errors / E-Toys
On Wed, 10 Jul 2002, Matt Sergeant wrote: Ah, in that case I'm recommending Dave's stuff. It's more flexible and doesn't use that irritating -param stuff. Though I have to do a little more research to be certain some things are possible (like turning on stack traces globally). Actually, traces are now _always_ created. And by default they're shown when stringifying the exception object. To turn this off you do: Exception::Class::Base-Trace(0); To turn it off for one branch of the hierarchy, do: My::Exception::Subclass-Trace(0); to turn it back on for a branch below that, do: My::Exception::Subclass::SubSubClass-Trace(1); I'm also planning to add some more features to it. One is something we're using with Mason, where we create convenience subs for throwing exceptions so we can do: param_error Missing 'foo' in call to new; instead of: HTML::Mason::Exception::Params-throw( error = Missing 'foo' in call to new ); plus as an added bonus the first version gets compile time checking of the sub name, versus runtime checking of the class name in the second. -dave /*== www.urth.org we await the New Sun ==*/
Re: leaks with Apache::Request?
On 8 Jul 2002, Joe Schaefer wrote: Write that like this, and I think your leak will disappear: my $r = Apache::Request-new( shift ); AFAICT, Apache::Request::new is NOT leaking here, since the REFCNT of its returned object IS 1. There might be some magic-related bug in perl that causes the assignment to bump $r's refcount to 2. This MIGHT be circumventable with some better code in Request.xs, but I really don't know how to fix it. Until some perl guru enlightens us, as a personal rule I try hard to avoid expressions like $foo = make_something_out_of($foo); I realize that this isn't always possible, but it often/usually is. Such advice would serve you well in this case; you could even get away with this my $r = shift; my $apr = Apache::Request-new($r); That's not going to leak, either. At least I hope not :-) I ended up using something like this and the leak went away. It seems to me that this might actually be a Perl bug. If I do this: my $x = shift; $x = make_something_from($x); then it seems like the original $x should go out of scope when it is assigned to, so its refcount should stay at 1. -dave /*== www.urth.org we await the New Sun ==*/
leaks with Apache::Request?
It looks like there may be a memory leak with Apache::Request. I'm using
version 1.0 with Perl 5.6.1, mod_perl 1.26, and Apache 1.3.26. mod_perl
is statically compiled into Apache.
Here's some code that I think demonstrates the leak:
package My::APRTest;
use strict;
use Apache::Request;
sub Apache::Request::DESTROY{warn DEAD: $_[0]\n}
sub handler
{
my $r = shift;
$r = Apache::Request-new($r);
$r-send_http_header;
$r-print('apr test');
return 200;
}
1;
When I run this, the DESTROY method is not called until the server shuts
down.
Watching memory using with top (against a server running as httpd -X) I
can see that memory usage is growing a little less the 500K every 5000
requests.
This isn't catastrophic but fixing it would be a good thing.
-dave
/*==
www.urth.org
we await the New Sun
==*/
Re: leaks with Apache::Request?
On Mon, 8 Jul 2002, Richard Clarke wrote: During the child exit phase, mod_perl invokes the Perl API function perl_destruct( ) to run the contents of END blocks and to invoke the DESTROY method for any global objects that have not gone out of scope already. Notice where it says ... for any global objects that have not gone out of scope already. In the code I posted, $r goes out of scope at the end of the handler subroutine. So I think i'm right in saying that, When I run this, the DESTROY method is not called until the server shuts down. is perfectly normal behaviour. I don't know how you are actually testing your memory Well, creating an Apache::DESTROY method works and shows the Apache object going out of scope on a per-request basis. usage, but I might suggest that if you are sending larger amounts of data than previously, just once per 5000 requests then this memory is gonna be consumed by apache forever (at least until httpd is killed). I tested with ab sending the same request thousands of times in a row. -dave /*== www.urth.org we await the New Sun ==*/
Re: errors installing libapreq
On Tue, 25 Jun 2002, Tim Bolin wrote: ok, im at the end of my proverbial rope on this one and dont know how to proceed... i am trying to install libapreq for Apache::Request, and when i try to run make the thing just pukes up a huge long string of errors like: You forgot to mention (though you did in your message to the Mason list) that you're using mod_perl 1.99_something, with which Apache::Request will not compile. -dave /*== www.urth.org we await the New Sun ==*/
Re: separating C from V in MVC
On Fri, 14 Jun 2002, kyle dawkins wrote: bigger system, but I would also caution people to say that if you find yourself doing joins across up to 6 tables, you're almost certainly doing something wrong from the start and, basically, you're fooked because of shitty design, and O/R or R/O won't help you. This is one of the sillier statements I've seen on this list. If you have complex data with many entities (and thus many tables) and you have complex queries then you can easily find yourself joining many tables. This is hardly a sign of bad design. In fact, it may be a sign of good (normalized) design. If _all_ of your queries are against 1 table at a time, that seems a lot more worrisome to me (because it suggests insufficient or non-existent normalization). -dave /*== www.urth.org we await the New Sun ==*/
Re: separating C from V in MVC
On Thu, 13 Jun 2002, Perrin Harkins wrote: As you can see it gets messy fast, and I didn't even cover the Mastercard part. It would probably have terruble performance too. This is why people usually just write this kind of report as a big SQL query instead. You can make a model object called ConcertSeatSearch: seats = Model::ConcertSeatSearch-findSeats( reserved_after = $date, payment_type = $card, user_state = $state, ); Just be careful that you don't end up making this into something that mirrors the SQL exactly. There might be 4 tables involved in finding out what kind of credit card the user had, but that gets hidden behind this API. If you find yourself writing classes that take options like where = 'date ' . $date you are reinventing SQL, and you've lost your abstraction. This approach works for some things, but I think it falls down when it comes to doing complex database searches, particularly searches generated ad-hoc on multiple columns in multiple tables. This is why Alzabo is much lower-level than what you have above. I needed something where I could easily construct queries that might include 1+ tables, with various types of searches of individual columns in those tables (equal to, between, less than, like, etc.) with dynamic sorting (again, on any of the columns in any of the tables, ascending or descending). With what you're proposing, I think you could easily end up with either: A) a ridiculously flexible interface that looks sort of like SQL, except where it is SQL, except where it's only sort of like SQL, etc. B) a ridiculous profusion of classes, methods, or both. SQL has its place, and Alzabo merely provides a thin layer on top of it. Trying to jam a thick layer of OO-goodness over relational data is asking for a mess. OO has its place, but if your application is primarily about the database, I don't think that a heavy OO layer on top of that will do you much good. And OO has a huge impedance mismatch with relational data (irregardless of SQL or not). -dave /*== www.urth.org we await the New Sun ==*/
Re: separating C from V in MVC
On Thu, 13 Jun 2002, Rob Nagler wrote: Most OLTP applications share a lot in common. The user inputs data in forms. The fields they edit often correspond one-to-one with database fields, and certainly their types. The user wants reports which are usually closely mapped to a table/view/join, i.e. an ordered list of tuples. A reasonable O/R mapping can solve this problem easily. Like Perl, it makes the easy things easy and the hard things possible. The bOP Pet Shop demostrates how you can build a simple application with only a couple of custom SQL queries. The rest are simple joins and CRUD. If you need more complex queries, there are escapes. You still probably end up with a list of tuples for your reports. The key we have found is avoiding indirection by naming fields and models the same in SQL and Perl objects. This allows you to seamlessly switch between the two. The Pet Shop has a grand total of 13 tables. How well does this approach work with 90 tables? How does it handle arbitrary queries that may join 1-6 tables, with conditionals and sorting of arbitrary complexity? We've found the O/R mapping to be an indispensable part of the system. Since all data is contained in objects, the views/widgets don't need to how the data is populated. They access all data through a single interface. I'm not a big fan of O/R. I prefer R/O. But to each their own. -dave /*== www.urth.org we await the New Sun ==*/
Re: separating C from V in MVC
On Fri, 14 Jun 2002, Gunther Birznieks wrote: Would one of you mind providing a 1 paragraph definition of each? I am afraid that I am starting to get lost in the semantic differences of controllers and actions and O/R, R/O? Well, here's my take on it. An Object-Relational mapper takes objects and stores them in a relational database, as transparently as possible. I think the most pure example of this I've seen in the Perl world is Tangram (www.tangram-persistence.org). SPOPS is also an O-R mapper (actually, its a generic Object persistence mechanism but it seems to most feature-rich when used with an RDBMS). A Relational-Object takes a relational database, and provides access to it (select, insert, update, delete) via objects. Class::DBI, Alzabo, and DBIx::RecordSet are examples of such a beast. I think what it comes down to is how do you start thinking your project? If the first thing you think about is classes, objects, hierarchies, delegation, etc., then an O-R mapper may be for you. Most applications need some sort of persistent data storage, and if you think of your app solely as a collection of objects, then an O-R mapper is a natural fit. However, if you're like me, and given an app, the first thing you think about is _data_ and relationships, then a R-O mapper may be better. I for one start a project by designing a relational schema for the data. Then I want some nice programmatic way to get at it so Alzabo is key for me. Of course, all this assumes some large amount of persistent data, as is the case with many (but not all) web apps. OTOH, if you don't have much (or any) persistent data, this is all meaningless. For example, when I work on Mason I think objects. But when I work on my Hong Kong movie DB project, I think about tables. I have 90-some tables and I don't really want to create 90-some individual classes, plus some ungodly number of query classes (as proposed by Perrin) to deal with it. Thanks, but no thanks. OTOH, I hate writing raw SQL and I hate generating SQL dynamically even more. Alzabo provides a nice layer over SQL, provides a multitude of convenience methods, has hook/trigger support, supports caching, transactions, and facilitates writing additional canned query methods as needed, and much much more ;) -dave /*== www.urth.org we await the New Sun ==*/
Re: separating C from V in MVC
On Fri, 14 Jun 2002, Fran Fabrizio wrote: How well does this approach work with 90 tables? How does it handle arbitrary queries that may join 1-6 tables, with conditionals and sorting of arbitrary complexity? I'd have to agree, most of the real-world scenarios I have run across do not consist of these neat 1-to-1 field to attribute type of mappings where the majority of the queries are simple inserts or selects from a single table or simple joins. Most of the apps I work on quickly evolve to the point of many (in my current case, 120+) tables and where most of the queries are gathering data for reports/views that bring data together from several tables. Joins of 5+ tables, unions, excepts, subselects, self-joins, complex sorting/grouping rules, etc are all commonplace and this is where I think overzealous attempts to abstract the queries away fall apart. I guess I'm more of the Perrin school of thought, where I prefer crafting all the SQL directly. I never said I like to actually write SQL directly. See below ... I don't typically find apps that just mirror some subset of one of the db tables to be all that interesting. After all, it's the relationships between the data that make the data interesting, and by necessity this means your queries will be complex. And looking over the stuff outlined at poop.sourceforge.net, there's not too many models/frameworks out there that can accurately abstract ALL of SQL, and if it only does a subset, I feel like that's shooting myself in the foot. Well, I'm the author of both that doc _and_ Alzabo, which of the R-O tools described in that document supports the most of SQL except for DBIx::RecordSet, which is quite a bit lower-level, but basically can be used for _any_ SQL (I think). Alzabo supports enough for me and my 90-table database. So far I haven't needed unions, excepts, or difference, nor have I needed subselects (Alzabo actually has some support for subselects, though not the first three). I do need complex joins, self-joins, joins with aliases, complex sorting grouping (though it doesn't support HAVING yet), outer joins, and all conditionals. Alzabo does support all of this, and frankly I find it easier to do this, particularly when it needs to be done on the fly, then I could by just generating SQL in the app itself. I'm all for _some_ abstraction. The eternal question is how much? -dave /*== www.urth.org we await the New Sun ==*/
Re: Can't set multiple cookies?
On Fri, 7 Jun 2002, Ken Miller wrote: Ok, so continuing down the path of a single sign-on system, I've completed a rough framework, and it works fine. However, I thought it might be nice to segregate the various bits of information into different cookies. Unfortunately, setting multiple cookies doesn't seem to be working. Here are the outbound headers obtained via $r-as_string: Set-Cookie: ACS_UID=miller; path=/ Set-Cookie: ACS_Test=blah; path=/ Set-Cookie: ACS_Ticket=stuff; path=/ on the next request, here's the Cookie header: Cookie: ACS_Ticket=stuff; RC_Creds=miller%2C I suspect you're using a 2-tier Apache setup with Apache 1.3.23 on the frontend, right? This is a bug in mod_proxy with 1.3.23. I _think_ its fixed in 1.3.24. If you're using 1.3.24 try reverting to 1.3.22 (which I know works) and see if that fixes it. -dave /*== www.urth.org we await the New Sun ==*/
Re: separating C from V in MVC
On Fri, 31 May 2002, Barry Hoggard wrote:
Do you have a favorite approach for writing the Model objects? At
Investorama we created a class called TableObject that would deal with
getting/setting values from the database, plus doing data verification
like checking for values being present and well-formed XML in fields
that needed it. I still use that approach on my consulting projects.
It's not a very complex object, and it doesn't do things recursively,
like mapping an attribute to an object and handling that object as well.
TableObject doesn't act as a base class. It just becomes one of the
attributes of the object.
A typical invocation is something like this:
my %fields = (
id = { type = 'num', pkey = 1, sequence = 'seq_users' },
email = { type = 'string', required = 1 },
password = { type = 'string', required = 1 },
first_name = { type = 'string', required = 1 },
last_name = { type = 'string', required = 1 },
valid = { type = 'num', required = 1},
member_id = { type = 'num' },
);
my $table = NAIC::TableObject-new(DBH = $self-dbh,
OBJECT = $self,
TABLE = 'users',
FIELDS = \%fields,
VERIFY = 1);
$table is then put into $self as an attribute called '_table'.
Storing/retrieving/verifying are done with $self-_table-store etc. It
expects that the attributes of an object like $self-email match the
database columns.
Alzabo could handle a _lot_ of this for you. Class::DBI could handle some
of it (though less).
People should use one of those (and check out poop.sf.net for more
options) rather than re-inventing the wheel.
-dave
/*==
www.urth.org
we await the New Sun
==*/
Re: MVC advice..?
On Wed, 29 May 2002, Perrin Harkins wrote: There's no good reason to do an eval 'use'. Use require instead, and import if you need to (but most people don't). Actually, there is. This code: my $module = 'Foo::Bar'; require $module; is not the same as this: require Foo::Bar; If require is given a string, it looks for a filename _matching_ that string. If it's given a bareword, it converts '::' to filesystem path separators first. -dave /*== www.urth.org we await the New Sun ==*/
Re: PerlRequire -mod_perl-2 - Apache 2.0.35
On Tue, 16 Apr 2002, Perrin Harkins wrote: [EMAIL PROTECTED] wrote: I am a newbie and had developed a proof-of-concept application on Apache 1.3.23/Mod_Perl-1.26-dev. We are researching into moving away from ASP/IIS Webapplications to Apache/Mod_Perl. I am stuck with the latest Apache 2.0.35 with the following problems. Do you really need to use Apache 2 and mod_perl 2? Why not use the proven 1.x series? It's still pretty early to be using the new stuff. If he's on Windows, he'd probably want to use Apache 2 for performance reasons. -dave /*== www.urth.org we await the New Sun ==*/
mod_perl 1.99 and Apache::compat
Well, here be a bug report I compiled Apache 2.0.35 with mod_perl 1.99 as a DSO. The server will start just fine with that. I'm running on GNU/Linux with Perl 5.6.1. If I add this: PerlModule Apache2 PerlModule Apache::compat The server simply will not start. If I comment out all the 'use' statements, except for mod_perl and Symbol, from Apache/compat.pm, then the server starts. If I load all the modules I just commented out via PerlModule in the config file and I _don't_ load Apache::compat, the server starts. If I load all the modules I commented out and try to load Apache::compat (with those use statements still commented out), the server will not start. I also found a few tiny bugs in Apache::compat. - The read() call in send_fd_length needs to be CORE::read. - In the last elsif in size_string, the size variable is missing its dollar sign ($). -dave /*== www.urth.org we await the New Sun ==*/
Re: mod_perl 1.99 and Apache::compat
On Sun, 7 Apr 2002, Dave Rolsky wrote:
I also found a few tiny bugs in Apache::compat.
- The read() call in send_fd_length needs to be CORE::read.
- In the last elsif in size_string, the size variable is missing its
dollar sign ($).
Here's a patch:
--- compat.pm.~1.35.~ Sat Mar 23 20:38:01 2002
+++ compat.pm Sun Apr 7 14:19:46 2002
-259,7 +259,7
$len = IOBUFSIZE;
}
-while (read($fh, $buff, $len)) {
+while (CORE::read($fh, $buff, $len)) {
$total_bytes_sent += $r-puts($buff);
}
-369,7 +369,7
elsif ($size 1048576) {
$size = sprintf %4dk, ($size + 512) / 1024;
}
-elsif (size 103809024) {
+elsif ($size 103809024) {
$size = sprintf %4.1fM, $size / 1048576.0;
}
else {
Re: modperl and SQL db select
On Thu, 21 Mar 2002, Jay Thorne wrote: The first one I noted was that he assumes that a high performance app has several joins. I think everyone here who's developed a few db apps will tell you that joins are hugely costly and should be avoided for an application's most common cases. Actually, I've developed _more_ than a few DB apps and I'd tell you that joins are not only _not_ hugely costly, but can sometimes be a performance improvement. It really depends on a lot of factors including what RDBMS you are using, how many connections you have, ratio of reads to writes, how complicated the joins are. But a blanket statement like that is flat out wrong. I recoded a mysql/mod_perl web app with a couple of joins to a slightly but not horridly denormalized db structure and realized some huge performance gains. You removed denormalization, thereby increasing the amount of work necessary to maintain data integrity so the reads may be faster but the writes are definitely slower and more prone to screwing things up. Even worse, you denormalized in favor of _one_ app, obviously, which means any new app you write on top of this denormalized db in the future may suffer because the denormalization doesn't serve it well. Further on, he was discussing threaded discussion forums and assumed a recursive query. While recursing the DATA is probably (though provabably not always) necessary, there is no need to storm the db with that many queries, since query setup time, queing, and results extraction have noticable time penalties. Extracting the data with a single query and recursing it in RAM is a much more db and cpu friendly idea. This I can agree on, though it is more a limitation of SQL, which provides no meaningful way to do a recursive query. As for performance, mysql and postgresql are getting pretty similar results, _these_ days. With aggressive app level caching of db data, and the innodb table handler, I was able to push mysql and mod_perl to 80+ 50kbyte page views per second on bog standard 650 mhz intel hardware. Again, that will depend on a number of things including complexity of your queries and ratio of reads vs. writes, etc. It's worth noting that MySQL's query optimizer pretty much stinks and will often not use indexes because it simply gives up when queries have an 'OR' in them, for example. What it comes down to is that except for _extremely_ demanding applications, either one is likely to be perfectly suitable so pick the one that you like best, or that has the features you need, or that your sysadmins can support most easily, or whatever. -dave /*== www.urth.org we await the New Sun ==*/
Re: modperl and SQL db select
On Thu, 21 Mar 2002, Rafiq Ismail (ADMIN) wrote: Mysql:+we all start with it. +Bench marks much faster. +/-Can allow nested queries (subselects again) though this is a relatively new feature. Eh? Subselects aren't scheduled for implementation until 4.1. The current version is 4.0.2. +People say it's less relational. Isn't really - but has fewer features (see above) I'm not sure what less relational means. -less reliable under heavy load. I'm not sure where you get that from either. MySQL is used under some very heavy loads (read the MySQL users list). Wow, this thread is really bringing out the fiction! /*== www.urth.org we await the New Sun ==*/
Re: [MASON] Using GD for dynamic graphics
On Wed, 20 Mar 2002, Nicolai Schlenzig wrote: When I create a new GD::Image drawing whatever on it and trying to print it - it will be prepended to my html header for the page. I then tried to put it in $m-out to have in printed within Mason, but that simply printed the raw PNG in all its glory as text on screen. I tried fiddeling with content_type, but I guess that wont work if I set this after I have already printed something on the page - hence the content_type will not even be effective for that page. What I still miss doing/trying is making a seperate file/component which only job will be to make the PNG, but I don't really see what I would gain from that, because that will pretty much also just print a PNG within my HTML page. First of all, there's a mason users list (http://www.masonhq.com/resources/mailing_lists.html). Second, you don't seem to understand how images in a web page works. When your browser sees img src=foo it makes a _seperate_ request for foo from the web server. The image is not somehow magically inlined in the page and served with the request for the page itself. What you need is a seperate top-level Mason component that generates the image. Use this as the value for the src attribute like img src=foo.comp?size=2. Then make sure that foo.comp prints the correct headers. And yes, you need to use $m-out, not print (this is documented in the Mason docs). /*== www.urth.org we await the New Sun ==*/
Re: here is a good modperl question on perlmonk
On Tue, 5 Mar 2002, Medi Montaseri wrote: My suggestion would be to install a Linux on your developer's PC and keep with the distributed model Now everyone can use a common web tree and at integeration, bring all of them to a staging box, QC it and ship it to production Giving everyone their own Apache daemon, which uses their checked out tree of code, on a central dev server is really not a problem either -dave /*== wwwurthorg we await the New Sun ==*/
Re: here is a good modperl question on perlmonk
On Tue, 5 Mar 2002, Medi Montaseri wrote: Truebut I'm thinking full control to the developer Developer can now mis-configure httpdconf as much as he/she wants and all the paths; virtual or not are consistant, instead of a dev path vs production path Right, every developer can run their own Apache daemon, each on a different port, mess with httpdconf, etc Whether or not those Apache daemons run on individual workstations or a central dev box is not a big issue -dave /*== wwwurthorg we await the New Sun ==*/
Re: Custom Logging and User Tracking
On Wed, 13 Feb 2002, Ryan Parr wrote:
The code follows:
sub handler {
my $r = shift;
return DECLINED unless($r-is_main());
# Same behavior when:
# return DECLINED unless($r-is_initial_req());
open TRACK, /usr/local/www/usertracker.txt or die Couldn't open
log: $!;
print TRACK
join(\t,($r-hostname,$r-uri,scalar(localtime))),\n;
close TRACK;
return DECLINED;
}
Hmm, no file locking for something being used by multiple processes?
Could be problematic. Is print atomic? Better be sure.
Also, if you just open the filehandle once (not in the handler) this'd
probably be a bit quicker. And for increased perceived speed have the
writing occur in a cleanup handler.
-dave
/*==
www.urth.org
we await the New Sun
==*/
Re: [WOT] Google Programming Contest.
On 7 Feb 2002, Randal L. Schwartz wrote: No, they say must use our C++ interface routines, and no closed-source solutions. If you provide an open source package, you must tell where and how to download and build. Thus, Perl is fine. In the Slashdot discussion, there's a link to a usenet posting by a Google employee which explicitly says only C++ or Java, no Perl or Lisp. -dave /*== www.urth.org we await the New Sun ==*/
Re: [OT] modperl growth (installers)
On Tue, 5 Feb 2002, Ed Grimm wrote: That's a good strategy (assuming a missing if in there somewhere). It can be augmented with the tactic of check for a running apache, see where it gets its config file from, and parse the config file to get the initial guess. (Note that I wouldn't want this to be a final guess; I'm using mod_perl in a virtual host config; the main apache config doesn't use it, and has a completely unrelated docroot (/usr/local/apache/htdocs as opposed to /home/appname/public_html)) Yep, been there, done that ;) The installer I mentioned for WeBoard UX was really pretty smart. It would look for the Apache binary (and ask if it couldn't find it), figure out if it had mod_perl (and ask for a different one if that binary didn't have mod_perl), check the Apache version, check the mod_perl version, find that Apache binary's config file (and ask...), figure out what user group that Apache ran as (to change certain permissions), tweak the Apache and config file to load WebBoard. And that's just what it did for Apache. It did a lot of other install/config tasks as well. Hmm, I really feel that this has gotten quite off-topic. Maybe I should create a Perl installer project on Sourceforge that'd attempt to take these types of things and create various useful modules for them, like Installer::Apache, Installer::Alzabo, Installer::RDBMS::MySQL, etc. -dave /*== www.urth.org we await the New Sun ==*/
Re: [OT] Re: mod_perl Developer's Cookbook (and Amazon)
On Mon, 4 Feb 2002, Joe Brenner wrote: so BookPool is my vendor of choice currently for price-conscious book shopping. Thanks, I'll look into that one. Or better yet, go to www.booksense.com, enter your zip code, and shop online at an independent local book-seller near you. It might be a little more expensive but chances are they'll carry whatever book you want and it will ship quickly. And you'll be supporting a locally owned small business, owned by actual human beings, not some giant corporate machine. -dave /*== www.urth.org we await the New Sun ==*/
Re: modperl growth
On 4 Feb 2002, Dave Hodgkinson wrote: And if the Slashcode were as easy to install and customise as phpnuke... For OSCON (and hopefully YAPC too), I've submitted a talk on using Module::Build (an ExtUtils::MakeMaker replacement) for modules and using it to build an application installer. Its not _that_ hard, and using Module::Build makes it a lot easier. When Matt Sergeant and I were working on (formerly) O'Reilly's WebBoard for Unix, we built an interactive command-line installer that could do the following: - Install Apache and mod_perl, or use an existing installation. - Install all the needed modules, template files, images, etc. - Set up a new database in your RDBMS of choice (MySQL, Postgres, Sybase, or Oracle) though the Sybase and Oracle choices weren't 100% automated (they are just too complex). Nowadays, I'd use Alzabo, which can also intelligently handle upgrading old versions of a schema (its not quite 100% perfect but its pretty good). - Insert various default values into your DB, if they weren't already there. At this point, you simply (re-)started your Apache w/mod_perl and you were ready to go. You had an admin account you logged in with and could start creating boards and such. It was a lot of work but its not _that_ hard. Perl definitely needs more out of tarball/box/whatever install-able apps and I'd like to help people get there. Alzabo is pretty close, though it still requires you to hand-modify your httpd.conf. I'm not sure how on-topic this is anymore, though I don't think creating a separate list would exactly help at this point. -dave /*== www.urth.org we await the New Sun ==*/
Re: [OT] RE: modperl growth
On Mon, 4 Feb 2002, Andrew Ho wrote: One last thing that is hard is where is your DocumentRoot? This is a huge problem for web applications being installable out of the box. Perl can't necessarily figure that out by itself, either. You take a guess and then ask the user to confirm. And you can't guess you just ask. There's nothing wrong with an interactive installer. What kills mod_perl apps is they simply have a README or INSTALL that says Copy all the template files to a directory called 'app-root' under your document root. I guess my point is that installation is hard. Rather than trying to make it work for everybody out of the box, you should make it work for the typical case out of the box, and then provide hooks for installing it in custom places. I think the best installer is an interactive installer that tries really hard to provide good defaults. -dave /*== www.urth.org we await the New Sun ==*/
mod_proxy bug in Apache 1.3.23
Since a lot of folks end up using mod_proxy in a dual-server setup, I thought I'd let people know of this bug (which I discovered after several hours of pounding my head against a brick wall). The version of mod_proxy shipped with Apache 1.3.23 will silently drop multiple Set-Cookie headers, leaving only the last one. So if your mod_perl app (on a backend server) tries to set multiple cookies, only the last one makes it through. This will break your app, for obvious reasons. Its already been reported in the Apache bug DB: http://bugs.apache.org/index.cgi/full/9595 http://bugs.apache.org/index.cgi/full/9655 -dave /*== www.urth.org we await the New Sun ==*/
[OT] Re: mod_perl Developer's Cookbook (and Amazon)
On Fri, 1 Feb 2002, Joe Brenner wrote: Spend only $4 more, and you too can show your disgust for software patents. Patents are bad. But don't forget that Amazon has also engaged in union-busting, which is several orders of magnitude worse, IMO. -dave /*== www.urth.org we await the New Sun ==*/
[JOB SEEKER]: Give me a job, please ;)
Hi, all, I just wanted to make a point of saying that I am available for work of a (mod)Perl-ish nature. I have a lot of expertise in mod_perl, Mason, databases, and Perl in general. I can add two and two. I can bake a cake. I can leap over _extremely_ tiny buildings in a single bound. Larger buildings may take more bounds. My resume is at http://www.urth.org/resume/. I'm interested in contract or full-time employment but I am not willing to relocate. I live in Minneapolis, where I'm currently enjoying the snow and below-freezing temperatures. Thanks, -dave /*== www.urth.org we await the New Sun ==*/
Re: ANNOUNCE: HTTP::TestEngine v0.02
On Tue, 29 Jan 2002, Chris Brooks wrote: I have released version 0.02 of HTTP::TestEngine to sourceforge. TestEngine acts as an http session recorder. After setting a cookie, a user can record a session by simply clicking links in their browser: filenames, paths and parameters are written to the filesystem for recall in the future. Session data is stored in test harness-independent format, and a second module, HTTP::SessionConfig is responsible for converting the session data into a data structure that is appropriate for play-back. HTTP::Monkeywrench is currently supported, with plans for HTTP::WebTest support in the future. This is funny. I was working on something very similar recently. It was designed to be able to work with both vanilla CGI and mod_perl (via Apache::Filter). It's more cross-platform that your current code and also records a lot more info. Maybe we can work together to integrate our code. We can probably talk more off the list. -dave /*== www.urth.org we await the New Sun ==*/
Re: PerlAddVar alternative in v1.21
On Fri, 25 Jan 2002, Geoffrey Young wrote:
I think I just read in the eagle book the other day that suggested something like
PerlSetVar MasonCompRoot foo:bar
my @roots = split :, $r-dir_config('MasonCompRoot');
or whatever...
Except that the code that read the dir_config is part of the Mason core.
Of course, changing it is entirely possible but it doesn't fix the problem
that Mason, by default, has certain features which are not available on
older mod_perl versions. But we can live with that.
-dave
/*==
www.urth.org
we await the New Sun
==*/
Re: Exception::Handler
On Fri, 11 Jan 2002, Jay Lawrence wrote:
For what it is worth - I would encourage you to check out the Error package
as well.
Rather than:
eval { };
if ($@-isa('FooException')) {
# ...
} elsif ($@-isa('BarException')) {
# ...
} else {
# ...
}
You would have:
try {
code;
} catch FooException with {
code for FooExceptions;
} catch BarException with {
code for BarExceptions;
} otherwise {
};
And the fun potential for memory leaks with nested closures.
And you can throw exceptions with details on the nature of the exception:
throw FooException ( -text = You foo'ed at line bar, -value =
$line );
You can do that without using Error.pm's try/catch stuff by simply using
Error's exception objects or the Exception::Class provided exception
objects.
AFAICT, Tatsuhiko's module is designed to work with either of those types
of objects transparently, but it provides an alternate mechanism for
catching exceptions.
And anything inspired by my Sig::PackageScoped module scares me, but its
an interesting idea ;)
-dave
/*==
www.urth.org
we await the New Sun
==*/
Re: Fast template system
On Sun, 30 Dec 2001, Ryan Thompson wrote: Any thoughts? There's quite a number of HTML template systems on CPAN which have been under development for years and are well supported. Use one of those and save yourself the hassle. I like Mason (but then again, I'm one of the developers ;) but also check out Embperl, HTML::Template, Apache::ASP, and Template Toolkit. Those are, IMHO, the major players in the text templating space, and are the most widely used. -dave
Re: What phase am I in?
On 21 Dec 2001, Vivek Khera wrote: DR == Dave Rolsky [EMAIL PROTECTED] writes: It's called current_callback(). DR Grr, its not documented when I do 'perldoc Apache'. There's a lot of stuff not so documented. The mod_perl book has much more complete docs. Which is nice for ORA and the books authors, but fairly irritating for folks like myself. Hell, I have the book but I don't always have it with me. I'd submit patches for this but I'm figuring 1.2x will be out of date soon enough with 2.0 in the works. Hopefully that will be better documented and if not, I can always help out. -dave
What phase am I in?
I've looked through the mod_perl docs and guide and am unable to find something that I can use in a handler to figure out what the current phase is. This seems like such an obvious thing that I can't believe it doesn't exist. Therefore I will conclude that I'm completely blind. Anyone care to open my eyes? -dave /*== www.urth.org We await the New Sun ==*/
Re: What phase am I in?
On Thu, 20 Dec 2001, Perrin Harkins wrote: I've looked through the mod_perl docs and guide and am unable to find something that I can use in a handler to figure out what the current phase is. This seems like such an obvious thing that I can't believe it doesn't exist. Therefore I will conclude that I'm completely blind. Anyone care to open my eyes? http://mathforum.org/epigone/modperl/liphortwa/Pine.LNX.4.10.9909211217510.5 [EMAIL PROTECTED] It's called current_callback(). Grr, its not documented when I do 'perldoc Apache'. -dave /*== www.urth.org We await the New Sun ==*/
Re: mod_perl site challenge: proposal to use ASF site design
On Mon, 17 Dec 2001, David Harris wrote: (a) See if others also think that the three alternatives for a mod_perl site are not very desirable. If you agree, please speak up and say that you agree. I thought Thomas' was fine but I think I actually prefer the ASF one. (b) See if others also think that using the ASF generic site design (even though it's not cool and distinctive) would be a good idea. If you agree, please speak up and say that you agree. I agree. Also, lets keep in mind something that Stas pointed out to me: most anything is a step up from our existing site design. So, if we go with one of the three existing options it's still a step up. Damn straight. -dave /*== www.urth.org We await the New Sun ==*/
Re: Comparison of different caching schemes
On Fri, 14 Dec 2001, Perrin Harkins wrote: The thing you were missing is that on an OS with an aggressively caching filesystem (like Linux), frequently read files will end up cached in RAM anyway. The kernel can usually do a better job of managing an efficient cache than your program can. Plus for some reason IPC overhead seems to seriously degrade as the size of the overall shared memory segment increases. I'm not sure why this is but I think the docs for IPC::Shareable mention this. Maybe for _very_ small amounts of data, shared memory might still be a win. -dave /*== www.urth.org We await the New Sun ==*/
RE: mod_perl vs. C for high performance Apache modules
On Fri, 14 Dec 2001, Thomas Moore wrote: I spoke to the technical lead at Yahoo who said mod_perl will not scale as well as c++ when you get to their level of traffic, but for a large ecommerce site mod_perl is fine. Well, Yahoo is _extremely_ atypical. And they do a lot of stuff that involves custom coded Apache modules (in C, I think, not C++, though maybe both). Amazon reportedly uses a similar approach. Jeremy Zawodny is a frequent contributor on the MySQL list and a Perl guy so if you're really curious you could probably email him a polite question for more details. He's a nice guy. -dave /*== www.urth.org We await the New Sun ==*/
Re: [OT] Re: Seeking Legal help
On Thu, 22 Nov 2001, Rodent of Unusual Size wrote: Um, no, it's spelt waylaid. :-) As you and everybody else has pointed out (mostly in private email). I was so eager and excited to give Matt some shit that I somehow incorporated part of his mistake. Oh well, that's what I get for teasing. -dave /*== www.urth.org We await the New Sun ==*/
Re: [OT] Re: Seeking Legal help
On Wed, 21 Nov 2001, Matt Sergeant wrote: Maybe they weighlayed your invoice. Or don't have the money just yet but ^^^??? You folks may have invented the language but its still spelled waylayed! Step three: Once you've given them 90 days after date of invoice, get a solicitor (not a barrister) to draft a threatening letter. It'll cost you about $100. I'm afraid you'll have to give them another 30 days at this point. We just have lawyers. There's no distinction between solicitors and barristers. Actually, I'd start by seeing a lawyer since you want this as expedited as possible. A lawyer might tell you that you only have to wait 30 days after the invoice (or something like that). You never know. It won't cost all that much to simply make an appointment and talk to a lawyer for an hour or so (probably $100-200) and it'll be probably be worth it to talk to something with contract law experience in your state. -dave /*== www.urth.org We await the New Sun ==*/
Re: Excellent article on Apache/mod_perl at eToys
On Tue, 23 Oct 2001, Nathan Torkington wrote: Of course, we couldn't call it a Java bean. They'd have to be Camel droppings. :-) Perl Jewels (Joules?) -dave /*== www.urth.org We await the New Sun ==*/
Re: Mod_perl component based architecture
On Wed, 17 Oct 2001, Gunther Birznieks wrote: I would venture to say that some of the mod_perl-only toolkits have some cases of being better designed than ours, but they are mostly mod_perl only. In fact, I don't know if I know any other toolkits than ours that are not mod_perl only of the ones that were advertised on the list. I don't know if Mason counts as a full toolkit (its not really an app server) but you can certainly run Mason as a vanilla CGI, and if you can do that I'm sure you can run it in FastCGI and whatnot. -dave /*== www.urth.org We await the New Sun ==*/
Re: ANN/RFC: Apache::Session::Generate variants
On Thu, 11 Oct 2001, Jeffrey W. Baker wrote: Well, you guys are touchy lot! My releases are no less frequent than releases of DBI or even mod_perl. So just chill out, I sometimes have other things on my mind. I don't know about touchy so much as frustrated. Apache::Session is very widely used but it doesn't feel well supported. Comparing it to DBI or mod_perl seems a bit silly. It is not as widely used as either and is far less complex. My big concern is that there is a fatal error in Apache::Session::Flex that makes it completely unusable. You've known about this for at least 9-12 months but you haven't bothered to release a simple bugfix release for it. Its a 3-4 line change! The only way around it is to constantly patch my local copies or use a hack work-around code which subclasses Flex to fix the populate method. This is stupid. I don't really want to reinvent the wheel or tell people not to use Apache::Session, but its getter harder to avoid either. If you have other things on your mind, that's fine. That's why I suggested you should consider letting someone else maintain it. I know I'm not the only person frustrated by the current state of affairs. -dave /*== www.urth.org We await the New Sun ==*/
Re: ANN/RFC: Apache::Session::Generate variants
On Thu, 11 Oct 2001, Tatsuhiko Miyagawa wrote: Wow, I did almost half a year ago :-) http://aspn.activestate.com/ASPN/Mail/Message/modperl/532294 Yeah, and I think I sent one a year ago, at least. Jeff, if you're still maintaining this package it'd be nice to put out a new release. If not, it'd be good to give it to someone else. Hell, I'll volunteer if no one more interested comes along. I don't have any big plans for it but I can at least integrate patches and such. Apache::Session is in use in a lot of places and it would be good to have an active maintainer. -dave /*== www.urth.org We await the New Sun ==*/
Apache::Cookie bug with value = undef
If I do this:
Apache::Cookie-new( $r,
-name = 'foo',
-value = { will_break = '', completely_borked = 1 } )-bake;
and then I later try to read the cookie in and do this:
my %c = Apache::Cookie-fetch;
my %cookie = $c{foo}-value;
print $cookie{will_break};
It will print 'completely_borked'!
The cookie's value looks something like this when sent to the browser:
will_breakcompletely_borked1
The problem is here in apache_cookie.c
while (*pair (val = ap_getword(r-pool, pair, ''))) {
ap_unescape_url((char *)val);
ApacheCookieAdd(c, val);
}
Here's a line from the ap_getword docs.
Copies everything from line up to stop to a new string. line is updated
to point to the first character after stop. Multiple occurrences of stop
are skipped if present.
It's that multiple occurrences are skipped bit that's causing the trouble.
I tried to fix it but I am a C gimp and don't know WTF I am doing.
-dave
/*==
www.urth.org
We await the New Sun
==*/
Re: Apache::Cookie bug with value = undef
On Mon, 8 Oct 2001, Ged Haywood wrote:
Have you tried doing
Apache::Cookie-new( $r,
-name = 'foo',
-value = { wont_break = '1', not_at_all_borked = '' } )-bake;
instead?
I can hardly control the order in which values are written out to the
cookie via a hash! Unless instead of an anonymous hash, I passed in a
reference to a tied hash or something.
I tried to fix it but I am a C gimp and don't know WTF I am doing.
Please don't modify the function ap_getword() in src/main/util.c as
that will probably break all sorts of things.
No, I was trying to fix it in apache_cookie.c It could simply check if
the next char was '' before calling ap_getword.
I'd leave this new function in the same file (util.c) for a quick hack
but if you leave it like that then ten to one you'll forget it's in
there and have to do it all over again next time you upgrade Apache.
It's still better to find a way around the problem than to do
something nasty like this.
I was trying to patch Apache::Cookie, not Apache. Apache is doing what it
says, and is therefore correct. Its simply not desirable to use that
function in that particular place in the apache_cookie.c file.
-dave
/*==
www.urth.org
We await the New Sun
==*/
Re: modperl 2.0
On Sun, 12 Aug 2001, The Doctor wrote: On Sun, Aug 12, 2001 at 05:51:22PM -0400, Barrie Slaymaker wrote: On Sun, Aug 12, 2001 at 03:47:09PM -0600, The Doctor wrote: perl 5.6.1 calling itself perl 5.6.0 Come off of it! I don't know where you got that idea. When I ran perl 5.6.1 it was identifying itself as perl 5.6.0 . Identity crisis?? A) This is fairly OT at this point. B) You have a broken Perl installation. This is neither the fault of Perl nor mod_perl. It _may_ be the fault of the BSD packaging folks, or someone may have simply screwed up your install on the machine you're using. The easiest thing might be to download the 5.6.1 tarball and install from scratch. Or you could continue being obnoxious on an unrelated list and giving Barrie shit when he's just trying to help you. -dave /*== www.urth.org We await the New Sun ==*/
Re: [OT] Inspired by closing comments from the UBB thread.
On Thu, 2 Aug 2001, Tim Bunce wrote: I think DBIx::AnyDBD is a pretty good compromise. Well, I worked with Matt on the project for which it was developed (WebBoard for Unix) and I still felt like there was just way too much stuff to deal with. Just too much SQL. I wanted a more abstract way to do things like outer joins, which are different in syntax across multiple platforms. It's definitely better than nothing, but I think for a larger project you'll still end up with a huge amount of very similar SQL statements in your modules. I guess that's why I've been working on Alzabo (though I had actually started that well before working on WBUX). -dave /*== www.urth.org We await the New Sun ==*/
Re: Just while we are so nicely [OT]: SQL Search Results in pages
On Thu, 2 Aug 2001, Perrin Harkins wrote: I've had great success with Select and cache only the row keys, fetch full rows as needed. We were also caching the individual records (in BerkeleyDB), so some pages never needed to hit Oracle at all after the initial query. A good way to go, if your data is not too volatile. This is more or less how Alzabo works (but you can tweak it). When it fetches row objects, its really just fetching primary keys that match your query. As you request other columns they are fetched and cached. You can also specify some columns to be fetched with the primary key and specify that others should be considered a group (when A is fetched, get B C too). Actually, I stole a lot of this from Michael Schwern's Class::DBI and got some more ideas from your talk at ApacheCon, Perrin. So if people are interested in implementing this, they may want to just consider using Alazbo (or you can rip out the caching code and use that separately if you want). -dave /*== www.urth.org We await the New Sun ==*/
Re: Ultimate Bulletin Board? Jezuz.
On Wed, 1 Aug 2001, Kyle Dawkins wrote: having said all that, it's much cheaper than UBB, far superior in overall design, and DB-driven... and it works beautifully, so i can't complain too much. :-) And has at least one major security hole (at least the 3.51 version did, which was the last free version). Do a search at Security Focus for details. Patching it is relatively easy. -dave /*== www.urth.org We await the New Sun ==*/
Re: [OT] Inspired by closing comments from the UBB thread.
On Wed, 1 Aug 2001, Ray Zimmerman wrote: One of the tools that is not mentioned in Dave's write-up (probably because it didn't exist then) is SPOPS, mentioned earlier in this thread. No, I just hadn't had a chance to get around to it yet. I really need to finish that thing someday. Of course, if people want to write up their favorite system (along the lines of the ones I've already done) I could just use that and it'd be done much quicker ;) -dave /*== www.urth.org We await the New Sun ==*/
Re: [OT] Inspired by closing comments from the UBB thread.
On Wed, 1 Aug 2001, Kyle Dawkins wrote: I've taken a look at many of them (Tangram? a few others) and haven't been impressed with any of them. I think part of the problem is that they're all being developed in a bit of a vacuum. But let's capitalise on the interest that this thread has generated to start a push for something that we can all use. I think even the dudes who embed their SQL in perl could be made to realise the benefits if we all started using a common framework. Thoughts? Well, people are starting to use my tool, Alzabo (alzabo.sourceforge.net) and I'm getting feedback. More feedback about what people want it always welcome. FWIW, Alzabo gives you a reasonable amount of control over the SQL that is generated, if you need it. It doesn't yet allow optimizer hints but that will change in a future version. OTOH, if you really _need_ to get into the nitty gritty details of SQL its hard to imagine that any abstraction layer would ever be satisfactory. -dave /*== www.urth.org We await the New Sun ==*/
Re: Object - RDBMS mapping tools and mod_perl
On Fri, 11 May 2001, Chris Winters wrote: Anyone (including Chris) done a comparison of the two (SPOPS and Tangram) and willing to comment on strengths, weaknesses, differences, etc? That is an excellent idea and would be quite useful. I'll see what I can do in the (relatively) near future. I started working on such a thing (comparing various persistence solutions for Perl) a long time ago. You can see where I was at if you look at: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/poop/documents/poop-comparison.pod?rev=1.2content-type=text/vnd.viewcvs-markup If you want to help it'd be much appreciated. The goal is to finish it, turn it into HTML and stick it somewhere that people will see it (poop.perl.org?) -dave /*== www.urth.org We await the New Sun ==*/
Re: [Mason] Object - RDBMS mapping tools and mod_perl
On Thu, 10 May 2001, Ray Zimmerman wrote: I'm aware of Tangram, Alzabo and SPOPS (not sure all these do what I need) ... are there any others? Any particular reasons why any of these may not play with with mod_perl/Mason? Well, I wrote Alzabo and it plays just fine with mod_perl and Mason. In fact, the schema creation interface is a set of Mason components. The caching/syncing architecture was specifically created to allow syncing of objects between multiple processes (ala mod_perl) and I will be creating a syncing module sometime that sync between multiple machines as well. I think the author of SPOPS is also a mod_perl user (I'm pretty sure he's posted to the mod_perl list in the past) so I'd expect it to play nice. Tangram I don't know much about in relation to mod_perl. However, these are all fairly different systems. I often descrive Alzabo as the opposite of Tangram, for instance. Alzabo is an RDBMS-OO mapper and Tangram is an OO-RDBMS mapper. Tangram is aimed at letting you have transparent OO persistence in an RDBMS without worrying about the schema too much. Alzabo is about taking an RDBMS and giving you access to it through convenient object methods. I'm not sure exactly what the goal of SPOPS is, so I'll let the author speak for himself. -dave /*== www.urth.org We await the New Sun ==*/
Re: Must restart Apache when any .pm changes?
On Sat, 21 Apr 2001, Steve Leibel wrote: I believe the way this works is that the first time any Apache child process sees "use Foo" that is the version of Foo.pm that will be used by that process. No subsequent "use Foo" within components will have any effect during the life of that Apache process. Am I understanding this correctly? Yes, mostly. Check out the Apache::Reload module though. It does what I think you want. -dave /*== www.urth.org We await the New Sun ==*/
Apachecon folks
Anyone here want to get together? I'm in room 945 and bored. I think matt Sergeant is here too but I couldn't find him at the bar. -dave /*== www.urth.org We await the New Sun ==*/
mod_perl BOF
Why was this scheduled during Matt Sergeant's AxKit presentation? Why not during a time slot when there are no mod_perl presentations? This is not rocket science here. -dave /*== www.urth.org We await the New Sun ==*/
RE: mod_perl BOF
On Wed, 28 Mar 2001, Geoffrey Young wrote: Absolutely. I've CC'd the ApacheCon planners so hopefully they can step in and fix things. Doh, I should've done this in the first place. I ended up mailing Stewart Quealy separately. Sorry for everyone who's seeing this multiple times. -dave /*== www.urth.org We await the New Sun ==*/
Charset?
Is there a mod_perl way to set the character set besides doing:
$r-content_type('text/html; charset=foo');
???
That'd be handy for a future version. I can't find anything in the
Apache.pm docs (1.24) or the guide for this.
-dave
/*==
www.urth.org
We await the New Sun
==*/
[OT] ApacheCon BOF shirts
So as not to be a total spoilsport, I would like to point out that I thought Randal's idea (Mcmod_perl?) was rather clever and I think it'd be cool (though I don't know if there are trademark issues). -dave /*== www.urth.org We await the New Sun ==*/
RE: [OT] ApacheCon BOF
On Tue, 20 Mar 2001, Geoffrey Young wrote: If you get a really good artist, put the lamp/bottle into the hands of a well-built Native American figure (a warrior-type is great, but an "indian princess" has subliminal appealok, ok, but think about it, lol!) I think the graphics house we'll be using is pretty capable :) I for one would appreciate a design that doesn't fetishize a culture and people that have already had enough abuse at the hands of 'American' people. Can we please keep the design more focused on technology and geekiness? -dave /*== www.urth.org We await the New Sun ==*/
