Re: [Catalyst] trouble with LocationMatch
Hironori Yoshida wrote: -$base_path = $location; +$self-apache-path_info =~ m/$location/msx; +$base_path = $;# I know this is the match-vars Programming Perl, Third Edition 24.2.1. Time Efficiency Avoid $ and its two buddies, $` and $'. Any occurrence in your program causes all matches to save the searched string for possible future reference. (However, once you've blown it, it doesn't hurt to have more of them.) Cheers, Dave ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: trouble with LocationMatch
* Dave Howorth [EMAIL PROTECTED] [2006-10-30 11:40]: Hironori Yoshida wrote: -$base_path = $location; +$self-apache-path_info =~ m/$location/msx; +$base_path = $;# I know this is the match-vars Programming Perl, Third Edition 24.2.1. Time Efficiency Avoid $ and its two buddies, $` and $'. Any occurrence in your program causes all matches to save the searched string for possible future reference. (However, once you've blown it, it doesn't hurt to have more of them.) Besides the trivial fact that it’s buggy because it doesn’t `quotemeta` the `$location` before using it as a regex. Sincerely, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] packaging and porting Catalyst
On Sun, Oct 29, 2006 at 06:55:54PM -0500, Jonathan Rockway wrote: If you're interested, reply to the dev list indicating which distro/OS you'd like to work on. I've claimed OpenBSD, and there is a gentoo portage tree in SVN. However, Debian is quite out of date, and the other Linuxes seem to be suffering from the same problem -- the Catalyst team and the distros would surely appreciate your help. One disadvantage of generating packages for distributions is that users without root access (such as on shared hosting) cannot install the packages. I have a tarball I used for on Debian Stable that I unpack into $HOME/local. It has the additional advantage that I'm not relying on system-installed packages which could change -- perhaps breaking my application. The tarball was created using CPAN to install modules and their dependencies. As a result, I'm sure the tarball is bloated with modules that are never touched by my application. $ du -hs local 34M local $ find local -type f | wc -l 2211 $ find local -name \*.pm | wc -l 1330 $ find local -name \*.so | wc -l 26 A tarball of the pure-perl modules could be installed on any system, right? So that would avoid the need to maintain that for many platforms (in each distribution's package system). Then it would be a matter of hand-installing the modules with binary components or providing those as tarballs targeted for a specific platform. $ find local -name \*.so local/lib/i386-linux-thread-multi/auto/version/vxs/vxs.so local/lib/perl/5.8.4/auto/Cache/FastMmap/CImpl/CImpl.so local/lib/perl/5.8.4/auto/Clone/Clone.so local/lib/perl/5.8.4/auto/Compress/Zlib/Zlib.so local/lib/perl/5.8.4/auto/Cwd/Cwd.so local/lib/perl/5.8.4/auto/DBD/Pg/Pg.so local/lib/perl/5.8.4/auto/DBD/SQLite/SQLite.so local/lib/perl/5.8.4/auto/DBI/DBI.so local/lib/perl/5.8.4/auto/Data/UUID/UUID.so local/lib/perl/5.8.4/auto/DateTime/DateTime.so local/lib/perl/5.8.4/auto/Encode/Byte/Byte.so local/lib/perl/5.8.4/auto/Encode/CN/CN.so local/lib/perl/5.8.4/auto/Encode/EBCDIC/EBCDIC.so local/lib/perl/5.8.4/auto/Encode/JP/JP.so local/lib/perl/5.8.4/auto/Encode/KR/KR.so local/lib/perl/5.8.4/auto/Encode/Symbol/Symbol.so local/lib/perl/5.8.4/auto/Encode/TW/TW.so local/lib/perl/5.8.4/auto/Encode/Unicode/Unicode.so local/lib/perl/5.8.4/auto/Encode/Encode.so local/lib/perl/5.8.4/auto/FCGI/FCGI.so local/lib/perl/5.8.4/auto/HTML/Tidy/Tidy.so local/lib/perl/5.8.4/auto/IPC/ShareLite/ShareLite.so local/lib/perl/5.8.4/auto/MIME/Base64/Base64.so local/lib/perl/5.8.4/auto/Params/Validate/Validate.so local/lib/perl/5.8.4/auto/Template/Stash/XS/XS.so local/lib/perl/5.8.4/auto/Time/Piece/Piece.so -- Bill Moseley [EMAIL PROTECTED] ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: packaging and porting Catalyst
* Bill Moseley [EMAIL PROTECTED] [2006-10-30 16:00]: One disadvantage of generating packages for distributions is that users without root access (such as on shared hosting) cannot install the packages. I have a tarball I used for on Debian Stable that I unpack into $HOME/local. It has the additional advantage that I'm not relying on system-installed packages which could change -- perhaps breaking my application. For admins rolling out stuff to many machines in a controlled envirvonment, unpacking tarballs is a stupid idea. Both approaches have their merits, neither is to be favoured. Sincerely, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: packaging and porting Catalyst
On Mon, Oct 30, 2006 at 04:04:09PM +0100, A. Pagaltzis wrote: * Bill Moseley [EMAIL PROTECTED] [2006-10-30 16:00]: One disadvantage of generating packages for distributions is that users without root access (such as on shared hosting) cannot install the packages. I have a tarball I used for on Debian Stable that I unpack into $HOME/local. It has the additional advantage that I'm not relying on system-installed packages which could change -- perhaps breaking my application. For admins rolling out stuff to many machines in a controlled envirvonment, unpacking tarballs is a stupid idea. But, who is the target of this effort? I thought it was to help get past the often difficult process of installing Catalyst via CPAN. Or is it to get providers, like Dreamhost, to include Catalyst in their offerings to their users? Actually, for Dreamhost it might be more likely for them to offer it as one of their one-click installs which would likely be better as a tarball than a deb. -- Bill Moseley [EMAIL PROTECTED] ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: packaging and porting Catalyst
I'm also interested in getting an EC2 (Amazon's grid computing) image for Catalyst up and running. I've been playing around with it a bit, if there is more of a desire for this let me know. I'm still trying to come up with some good use cases as to why an EC2 image is worth the work getting there (aside from the fact Catalyst kicks ass, and it should merely be there just because) -J On 10/30/06, Bill Moseley [EMAIL PROTECTED] wrote: On Mon, Oct 30, 2006 at 04:04:09PM +0100, A. Pagaltzis wrote: * Bill Moseley [EMAIL PROTECTED] [2006-10-30 16:00]: One disadvantage of generating packages for distributions is that users without root access (such as on shared hosting) cannot install the packages. I have a tarball I used for on Debian Stable that I unpack into $HOME/local. It has the additional advantage that I'm not relying on system-installed packages which could change -- perhaps breaking my application. For admins rolling out stuff to many machines in a controlled envirvonment, unpacking tarballs is a stupid idea. But, who is the target of this effort? I thought it was to help get past the often difficult process of installing Catalyst via CPAN. Or is it to get providers, like Dreamhost, to include Catalyst in their offerings to their users? Actually, for Dreamhost it might be more likely for them to offer it as one of their one-click installs which would likely be better as a tarball than a deb. -- Bill Moseley [EMAIL PROTECTED] ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: packaging and porting Catalyst
* Bill Moseley [EMAIL PROTECTED] [2006-10-30 16:25]: But, who is the target of this effort? Everyone. The more people can be catered to, the better. If you want to maintain a batteries-included tarball, go ahead. If others want to provide OS-specific packages, great. If people want to build ready-built VM images, awesome. The more the merrier. See also: Elaine’s Law. Sincerely, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: packaging and porting Catalyst
Bill Moseley wrote:
But, who is the target of this effort? I thought it was to help get
past the often difficult process of installing Catalyst via CPAN.
Or is it to get providers, like Dreamhost, to include Catalyst in
their offerings to their users? Actually, for Dreamhost it might be
more likely for them to offer it as one of their one-click installs
which would likely be better as a tarball than a deb.
You bring up a good point, packages are irrelevant to people without
root. I'm thinking that people rolling out exciting new Web 2.0 sites
are probably only a small portion of the Catalyst userbase. To be
honest, I don't see Catalyst catching on in the $10/month hosting
category simply because the $10/month can't pay for the memory a
persistent process (like myapp_fastcgi.pl or mod_perl) requires. You
might be able to get away with it on a case-by-case basis, but $10
hosting won't stay that price if Catalyst becomes a service that the
hosting company provides and supports. (For $20/month, though, you can
get a dedicated virtual server and be fine. In that case, you can
install packages, though, and that's what I/we are targeting.)
Of course, for every Dreamhost user there are many, many more users that
are creating Catalyst applications either for internal use or for paying
clients. In this case, they have a sysadmin that runs their (on-site or
colocated) servers, and installing CPAN modules might not be something
the sysadmin is good at. apt-get install Catalyst or make install
means that the sysadmin can have a known-good, supported environment for
deployment (and the developers can have the same environment on their
desktop). Trust me, copying CPAN modules between machines is not fun.
It involves a little too much cross your fingers and hope for the best
for my tastes.
Anyway, my personal goal is to make it easy to deploy Catalyst apps on
OpenBSD, since I do that anyway :) If your goals are different, then I
look forward to your feedback and contributions. If you need svn space,
just ask on the -dev list.
Regards,
Jonathan Rockway
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)-config(name = do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
;$;]-[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;-setup;
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
[Catalyst] Chained actions usage and DBIC performance
Lately I've been using chained actions a lot, since it ends up making
everything look cleaner and more organized.
I tend to structure things in a way that I've got some Catalyst
actions that load some items from the database which are the root of
the chain and then I've got another set of Catalyst actions that
actually do things with those loaded items (e.g. /item/12/view,
/item/12/edit, and so on).
Sometimes, those items also have subitems and those might even have
another set of subitems. In these cases, when using Catalyst and
DBIx::Class it can be useful to prefetch stuff for performance
reasons. But, using my setup it's not currently possible to do that,
so I end up issuing lots of queries to the database since the initial
root item didn't prefetch anything, because it couldn't know in
advance what would be needed by the chained actions.
Most of the item loading code I've previously mentioned looks like
this (simplified):
sub load : Chained('/item') PathPart('') CaptureArgs(1) {
my ($self, $c, $id) = @_;
$c-stash-{item} = $c-model('DB')-find($id);
}
The only work around I could think of is to prefetch everything and
hope that it would result in a performance gain, at least on average.
But, honestly, I find it a kind of crappy solution so I didn't even
implement it.
I'd like to know how people usually handle this because there must a
better way than ignoring performance concerns at all.
The only better way I could think of would be if DBIC's -find()
worked in a similar way to -search() and only actually fetched the
values when they were needed. So I could add prefetch conditions
arbitrarily using stacked find() calls. Maybe this should be suggested
on DBIC mailing list? Or am I just complicating a trivial situation
and there's a simple way around this problem?
-Nilson Santos F. Jr.
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Chained actions usage and DBIC performance
--- Nilson Santos Figueiredo Junior [EMAIL PROTECTED]
wrote:
Lately I've been using chained actions a lot, since
it ends up making
everything look cleaner and more organized.
I tend to structure things in a way that I've got
some Catalyst
actions that load some items from the database
which are the root of
the chain and then I've got another set of Catalyst
actions that
actually do things with those loaded items (e.g.
/item/12/view,
/item/12/edit, and so on).
Sometimes, those items also have subitems and those
might even have
another set of subitems. In these cases, when using
Catalyst and
DBIx::Class it can be useful to prefetch stuff for
performance
reasons. But, using my setup it's not currently
possible to do that,
so I end up issuing lots of queries to the database
since the initial
root item didn't prefetch anything, because it
couldn't know in
advance what would be needed by the chained actions.
Most of the item loading code I've previously
mentioned looks like
this (simplified):
sub load : Chained('/item') PathPart('')
CaptureArgs(1) {
my ($self, $c, $id) = @_;
$c-stash-{item} = $c-model('DB')-find($id);
}
The only work around I could think of is to prefetch
everything and
hope that it would result in a performance gain, at
least on average.
But, honestly, I find it a kind of crappy solution
so I didn't even
implement it.
I'd like to know how people usually handle this
because there must a
better way than ignoring performance concerns at
all.
The only better way I could think of would be if
DBIC's -find()
worked in a similar way to -search() and only
actually fetched the
values when they were needed. So I could add
prefetch conditions
arbitrarily using stacked find() calls. Maybe this
should be suggested
on DBIC mailing list? Or am I just complicating a
trivial situation
and there's a simple way around this problem?
-Nilson Santos F. Jr.
I do something very similar to what you are talking
about but I don't issue a find until the endpoint.
You can do search anywhere you do find to get
resultsets. That why you can drill down and keep
adding conditions to the query down the chain. I find
this works pretty well, I only ever see a single
dtabase call.
--john
___
List: Catalyst@lists.rawmode.org
Listinfo:
http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive:
http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Want to start your own business? Learn how on Yahoo! Small Business
(http://smallbusiness.yahoo.com)
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
RE: [Catalyst] Re: template comparison
On Sun, 2006-10-29 at 18:05 +, Jon Warbrick wrote: If considering Mason as a templating language for Catalyst, it's worth looking at Text::MicroMason (and Catalyst::View::MicroMason). Agreed. Mason is not just a templating system but rather a full web development framework, and you will have no use for most of the code it's loading if all you want is templates. You could also look at other in-line perl solutions like the Embperl view modules (there are two of them). It would be easy to make one for Text::Template as well, if you prefer it, but no one seems to have made one yet. - Perrin ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] catalyst + embedded systems?
Anyone try anything like this:
http://bec-systems.com/web/content/view/46/9/
with Perl5 and Catalyst? I'd be interested in hearing how it performs.
Regards,
Jonathan Rockway
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)-config(name = do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
;$;]-[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;-setup;
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] catalyst + embedded systems?
Jonathan Rockway wrote: Anyone try anything like this: http://bec-systems.com/web/content/view/46/9/ with Perl5 and Catalyst? I'd be interested in hearing how it performs. Regards, Jonathan Rockway I've got an embedded nix device that i've been doing some other work for, and will have to put together a web config for it, so timer permitting i'll give it a go Ash ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
