Re: [Catalyst] Using URL for /search/parameters: bad idea?

[Andrew Rodland]

On Mon, Sep 26, 2011 at 5:29 PM, Marius Olsthoorn  wrote:

> Hi,
>
> Consider using the query part of the URI to represent the search.
> Browsers are very good at bookmarking these :)
>

What in the world is that supposed to mean? Are browsers *bad* at saving
bookmarks for other kinds of URLs?
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Re: Multiple applications (some cat based) on the same server

[Andrew Rodland]

There's a Plack::App::FCGIDispatcher that will let you mount an external
FastCGI app as part of a Plack app, and it's possible to run PHP as an
external FastCGI app using php5-fcgi and spawn-fcgi. Maybe not the easiest
thing in the world, but totally doable. Or you could just set up a PHP app
in Apache on a high port and then point a Plack::App::Proxy at that.

On Sat, Aug 27, 2011 at 3:37 AM, Peter Edwards wrote:

>
> On 27 August 2011 08:07, Aristotle Pagaltzis  wrote:
>
>> If they all have Plack integration it’s trivially easy, something
>> like
>>
>>use Plack::Builder;
>>builder {
>>mount '/cat'   => $cat_app;
>>mount '/mouse' => $other_cat_app;
>>mount '/foo'   => $ledgersmb_app;
>>mount '/'  => $shinycms_app;
>>}
>>
>>
> Can you integrate PHP apps with Plack?
>
> Regards, Peter
>
> ___
> List: Catalyst@lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive:
> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/
>
>
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Configuring Apache for mod_perl Catalyst and php via mod_proxy

[Andrew Rodland]

Another solution, less ugly (IMO) than mod_proxy, is removing mod_php by
setting up PHP behind mod_fastcgi. In fact, if you remove mod_perl as well
by putting your Catalyst apps behind mod_fastcgi, you can have all the
threading you desire.

On Fri, Jul 29, 2011 at 8:15 AM, Tomas Doran  wrote:

>
> On 29 Jul 2011, at 12:25, matthew couchman (JIC) wrote:
>
>  Thanks for your reply. Perhaps it was too sweeping a statement but I can
>> only say that for my setup mod_perl works fine through Apache alone as does
>> php but when I combine them it crashes with memory corruption errors.
>>
>
> (At a guess), don't use the threaded MPM.
>
> Use prefork and everything will be fine.
>
>
> Cheers
> t0m
>
>
> __**_
> List: Catalyst@lists.scsys.co.uk
> Listinfo: 
> http://lists.scsys.co.uk/cgi-**bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/**
> catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/
>
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] error while starting my dev enviroment

[Andrew Rodland]

On Sunday, July 10, 2011 01:36:55 AM Charlie Gonzalez wrote:
> Hello,
> 
> I am receiving the following error message while starting my dev server
> enviroment:
> 
> 
> cgonzalez@cgonzalez-laptop:~/Addressit/script$ perl Addressit_server.pl -r
> The alias and excludes options for role application have been renamed
> -alias and -excludes (CatalystX::Component::Traits is consuming
> MooseX::Traits::Pluggable - do you need to upgrade
> CatalystX::Component::Traits?) at

"CatalystX::Component::Traits is consuming MooseX::Traits::Pluggable - do you 
need to update CatalystX::Component::Traits?"

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] DBI Models Question.

[Andrew Rodland]

On Saturday, June 11, 2011 07:54:46 PM John Karr wrote:
> The mistake in my  code brings up the other  question (which applies to ORM
> models as well): How to get the model to take its parameters from
> .conf instead of having to input them directly in the model.

Do absolutely nothing. It already works that way. That's what Catalyst::Model 
(really Catalyst::Component) provides.

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] living without Apache 'deflate'

[Andrew Rodland]

On Monday, April 04, 2011 06:11:39 PM John M. Dlugosz wrote:
> Since fastcgi doesn't get along with the deflate module, I've turned it
> off, per the installation instructions and Catalyst tutorials.
> 
> But I'm wondering about SVG images.  Can I pre-compress the files on disk
> and have the browser see the same thing as the deflate wrapper around the
> actual content type?  That's certainly better for the server anyway,
> instead of deflating it on every request.

For starters: you don't need to do without mod_deflate. Just install a non-
broken version of mod_fastcgi (version SNAP-0811090952, from 2008, or newer).

But if somehow that's not an option, you can load 
Catalyst::Plugin::Compress::Deflate (of course you'd also need to use 
Catalyst::Plugin::Static::Simple as well, instead of allowing apache to serve 
those files directly).

Precompressing the files on disk *is* possible but there's a difficulty 
involved with the headers, since you can't send a deflated body without an 
appropriate Content-Transfer-Encoding, and you can't do it at all unless the 
client has sent an appropriate Accept header. Doing this right is a matter of 
a bit of programming, unless you can find a module that already does it for 
you.

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Force the session to be saved.

[Andrew Rodland]

On Tuesday, March 29, 2011 12:46:32 PM Duncan Garland wrote:
> Hi,
> 
> We've been having some peculiar behaviour from our system. I think it's
> because the controller which produces the HTML page stores data in the
> session for retrieval by the controller which produces the associated
> javascript file.
> 
> The client begins processing the HTML page as soon as it starts to arrive.
> When it reaches the script tag it requests the javascript page.
> Occasionally the first controller hasn't written the session to the
> database when the javascript controller tries to retrieve it.
> (Catalyst::Plugin::Session::Store::DBIC).
> 
> I can move the script tag down the page a bit, but what I really need is a
> way to force the session to be written before the HTML template is
> rendered.
> 
> Something like:
> 
> $c->session->{javascript}->{$template}  = { one = 1, two => 2};
> $c->session->save;
> 
> Is there such a method?
> 
> Regards
> 
> Duncan

finalize_session (which writes the session to the DB) runs before 
finalize_body (which writes the response to the client), so Catalyst already 
does what you would like it to, and forcing a session write before running the 
view is unlikely to help anything. I suspect either your database isn't 
guaranteeing ordering, or the problem is somewhere other than where you're 
looking.

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Encoding UTF8 ?

[Andrew Rodland]

On Monday, March 28, 2011 12:50:00 PM John M. Dlugosz wrote:
> I don't understand why
> 
> |Catalyst::Plugin::Unicode::Encoding|
> 
> is necessary, based on the writup: it takes request arguments and converts
> them from whatever they came in to Perl's native encoding, and likewise
> for the response.
> 
> But Perl is using UTF-8 in its strings anyway.  So what's it have to do
> with the engine error I noticed before?

What engine error you noticed before? You broke threading.

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Requesting example code for postfix and Email::Sender

[Andrew Rodland]

On Monday, March 21, 2011 09:12:52 PM John M. Dlugosz wrote:
> On 3/21/2011 4:46 PM, Dave Rolsky autarch-at-urth.org |Catalyst/Allow to 
home| wrote:
> > Usually, this will be implemented as something that just writes a file to
> > the server's mail queue, without relying on the server actually running.
> > The server will pick it up when it runs, and will handle it from there.
> > 
> > TL;DR - Use Email::Sender::Transport::Sendmail unless you have a really
> > good reason to use something else.
> 
> Ah, that's very good to know.
> 
> However, I don't seem to have a program called 'sendmail' on the path.
> I had installed Postfix via the Debian package.

The postfix debian package installs sendmail as /usr/sbin/sendmail which isn't 
on the path for non-root users by default. Not sure why, exactly.

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Requesting example code for postfix and Email::Sender

[Andrew Rodland]

On Monday, March 21, 2011 08:56:55 PM John M. Dlugosz wrote:
> On 3/21/2011 1:37 PM, will trillich will.trillich-at-serensoft.com
> |Catalyst/Allow to
> 
> home| wrote:
> > $c->stash->{*email*} = {
> > 
> >  from   =>  $c->config->{email_from},
> >  'reply-to' =>  $c->user->email_name,
> >  to =>  $c->user->email_name,
> >  cc =>  join(',', @cc),
> >  subject=>  $subj,
> >  body   =>  $message,
> > 
> > };
> > $c->forward( $c->view('Email') );
> 
> I didn't like that one (the mail view) because I don't follow: if your
> function sends email instead of generating a web page, what happens to the
> UA on the other end of the network who triggered that URL?

There doesn't need to be any "instead of". The email view doesn't set any 
response body, so the default view will still run later on by whatever means 
usually runs it (i.e. RenderView).

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Quick question on forward porting versus retaining existing code

[Andrew Rodland]

On Thursday, March 17, 2011 02:51:59 PM Joe Landman wrote:
> Hi folks
> 
>We have a Catalyst app we've developed since about 2005 or so.  We
> put it aside in late 2008, and haven't touched it until now.
> 
>I wanted to see if it would still work (as it turns out, we can reuse
> this for a new project).
> 
>Before we get into this in depth, are there any pointers/blog
> posts/articles about forward porting an application (this was
> pre-Moose), or whether or not the app would work without forward porting?
> 
>Basically we don't want to have to redevelop everything we put into
> that (login/authentication, views, etc.), and simply add to the existing
> app with a limited set of changes to make it current would be ideal.
> 
>Thanks!
> 
> Joe

It's the intention of the Catalyst dev team that new releases don't break 
existing apps. The 5.7 to 5.8 transition broke that promise *slightly* more 
than most releases (mostly due to the C3 MRO), but a great many apps written 
for 5.7 will still run without any changes on 5.8, and of the remainder, 99% 
will only need very small changes. Rewriting your code to make explicit use of 
Moose is *not* required. Just deploy the app with the current version of 
Catalyst and current versions of any plugins it uses, and if there are any 
errors or warnings on startup, use them as guidance. If you run into a nut you 
can't crack, please feel free to come back for advice, but you should start 
out by just trying to run the app.

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Catalyst

[Andrew Rodland]

Run "package-stash-conflicts", it will probably tell you that you need to 
upgrade namespace::clean. Do that. :)

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Unicode::Encoding - utf8 "\xBA" does not map to Unicode

[Andrew Rodland]

On Friday, March 11, 2011 05:50:22 PM ryan lauterbach wrote:
> Hi,
> 
> I've read some threads about unicode, utf8 and query parameters but I
> don't understand it enough to fix on my own, so apologies for beating
> a dead horse.
> 
> When a URL contains a utf8 character in the query string such as
> ?first_name=K%E9vyn  (where %E9 is é, latin small e with acute),
> Unicode::Encoding barfs with  utf8 "\xE9" does not map to Unicode.

%E9 is not "a UTF-8 character". A properly encoded UTF-8 URL representation of 
'first_name=Kévyn' would be 'first_name=K%C3%A9vyn', which C::P::U::E will 
accept.

$ perl -MURI::Escape -Mutf8 -le 'my $str = "K\xe9vyn"; utf8::encode($str); 
print uri_escape($str)'
K%C3%A9vyn

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] How to get uri_for something with a fragment?

[Andrew Rodland]

On Sunday, March 06, 2011 05:07:25 AM John M. Dlugosz wrote:
>   How do I call uri_for_action and pass it the '#id' part?  It's not an arg
> and it's not part of the query string.  This is called the fragment
> identifier in the final URL.

uri_for returns a URI object, so you can always

my $uri = $c->uri_for_action(...);
$uri->fragment('id');
# Use $uri

Or, since you know that what it generates *doesn't* have a fragment you could 
always just $c->uri_for_action(...) . '#id' which will be perfectly valid 
(although no longer a URI object).

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Catalyst-Manual now on git

[Andrew Rodland]

On Wednesday, February 16, 2011 03:03:43 AM Kieren Diment wrote:
> Thanks to frew++, Catalyst-Manual is now no longer on svn and has moved to
> shadowcat's[1]  git hosting.  You can get a copy of the manual with the
> tutorial attached.
> 
> Grab a fork with:
> 
> git clone catag...@git.shadowcat.co.uk:Catalyst-Manual
> 
> If you have patches, please contact this list with patches, or join
> #catalyst-dev on irc.perl.org for further instructions.

The publicly-accessible read-only URL for the repository is actually:

git  clone git://git.shadowcat.co.uk/catagits/Catalyst-Manual.git

The URL in Kieren's email only works for those with commit bits on catagits. 
For those who do not have commit bits but think they should, please visit 
#catalyst-dev and we'll take care of you as quickly as we can.

If you're afraid of asking for a commit bit: don't be! But if it's your first 
time contributing, then create a patch with git and bring it to the mailing 
list, or push a branch to github and let us know about it on IRC, and we will 
take it from there. We want your contributions. We'll only bug you to accept a 
commit bit *afterwards* :)

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Re: Opinions on static::simple - with caching

[Andrew Rodland]

On Tuesday, February 01, 2011 08:06:08 PM Toby Corkindale wrote:
> How do you find Plack at serving static files (via Middleware::Static
> / App::Static)? Compared to Static::Simple, and compared to native
> HTTPD. I guess it sits in between the two in terms of performance, but
> wondered how much of an improvement it was?
> 
All of them will give perfectly acceptable throughput -- even Static::Simple 
isn't *slow*. The real concern is that with Static::Simple or with 
Plack::App::File, you're tying up one of your webapp processes to serve the 
file -- and your webapp processes are usually fairly limited in number, and 
fairly memory-hungry (which prevents you from just making more). On the other 
hand, if you let the frontend httpd serve the file, the cost of serving a 
static file ranges from one lightweight httpd thread (for a threaded model) to 
nearly nothing at all (with an async model). Either way, it's not tying up a 
process that could be running Catalyst.

If you're serving up a fairly small number of fairly small files, then this 
probably doesn't make any difference to you, but if you're serving a larger 
number of larger files (that will take several seconds or more to transfer) 
then you should probably be thinking about ways to do it outside of your 
webapp process.

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] [ANNOUNCE] Catalyst-Runtime-5.89000-TRIAL PSGI Catalyst - first development release.

[Andrew Rodland]

On Monday, January 24, 2011 05:12:58 PM Tomas Doran wrote:
> Hi
> 
> It gives me great pleasure to announce the first development release
> of the next major version of Catalyst.
> 
> This is a development release, and we need people to start trying to
> use it _NOW_, and to tell us about the issues you find with your real
> world applications. Otherwise we're going to be unable to fix those
> issues before a final release.
> 
> There are still some known problems with the current release, and the
> upgrading documentation is at this stage anything but complete.
> However, we have been working hard to keep this release as compatible
> as possible with previous versions, and the documentation for
> upgrading will greatly improve before the final version..
> 
> Known issues:
>   * -l argument to myapp_fastcgi.pl script is broken (this is already
> fixed in subversion)

Actually *all* arguments to the _fastcgi script are broken in 5.89000-TRIAL 
(incl. -l/--listen, -n/--nproc, -d/--detach, -e/--keeperr, and -M/--manager). 
If you need to launch with the _fastcgi script, you will need to wait for the 
next trial release, or build from svn (Catalyst-Runtime/5.80/branches/psgi) or 
at least get Catalyst::Script::FastCGI from there.

You can still test with _server.pl though, or with your own choice of Plack 
server and .psgi file, or test apps with Catalyst::Test and TWMC.

If you maintain any modules that interface with Catalyst, give them a quick 
check to make sure that they don't assume the existence of 
Catalyst::Engine::CGI -- if they do, they will break with the removal of 
Catalyst::Engine::* !

Thanks,

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] FastCgiServer: redefinition of a previously defined FastCGI server error when adding SSL VHost

[Andrew Rodland]

On Sunday, December 12, 2010 09:55:33 pm Eric Berg wrote:
> This may be more of a FCGI question, but since it's happening with my
> Catalyst app, I'll ask you folks.
> 
> I got my SSL cert installed and generally am configured for Apache 2.2
> to serve up my site via SSL, but when I enable the FCGI config for the
> SSL site, I get the following error:
> 
> FastCgiServer: redefinition of a previously defined FastCGI server error
> when adding SSL VHost
> 
[snip] 
> I would think that the different VHosts had different contexts for FCGI,
> but when this config appears in both ssl and non-ssl vhosts, I get that
> error.
> 
> Anyone have any solutions for this?

No, FastCgiServer declarations are global, and the namespace for the "mount 
points" is global. Apache lets you place the config lines inside of a vhost, 
but that doesn't actually do anything different than if you'd placed them 
outside of a vhost.

The good thing is that now that you know this, you probably don't have to do 
anything besides remove one of the conflicting lines. I find that the best 
organization is to have three different stanzas in three included files (in 
the sites-available/ directory of a debian-based config in my case, but you 
can adjust to taste): a file called "sitename-run-fcgi" only contains the 
FastCgiServer, FastCgiOptions, or any other config relevant to making the 
FastCGI available; a file called "sitename" contains the nonsecure vhost, and 
a file called "sitename-secure" contains the SSL vhost. Both of the latter 
files use the FastCGI mountpoint set up by the first file.

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Transferring control via root/auto

[Andrew Rodland]

On Wednesday, December 08, 2010 07:31:42 am Tomas Doran wrote:
> On 7 Dec 2010, at 16:11, Ben van Staveren wrote:
> > You want to $c->detach('end') -- unless that's the default these
> > days. I use this pattern a lot and the only difference I see is that
> 
> > I do:
> The end action will _always_ be run, there is no need to detach to the
> end action.
> 
> However I'm not sure what doing $c->detach in auto will do (I guess
> the same as returning 0 - i.e. stop further actions from running), but
> I'm not sure - you should probably return 0 (to stop further dispatch)
> rather than detaching in the auto action..

Since auto is internally just another step in _DISPATCH (Catalyst gets to it 
by calling forward and everything) detaching from it behaves as you'd expect 
-- the action you detach to is run, and so is end, and the current dispatch 
(including the rest of auto and running $c->action) is abandoned. So, possibly 
there are *cleaner* ways to deal with situations like that (often involving 
Chained), but if you want to do it, it shouldn't break on you.

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Defining ARRAY in Config::General config

[Andrew Rodland]

On Tuesday, September 21, 2010 08:30:43 am Pavel A. Karoukin wrote:
> On Tue, Sep 21, 2010 at 8:06 AM, Emanuele Zeppieri  wrote:
> > On Tue, Sep 21, 2010 at 2:14 PM, Octavian Rasnita
> > my $conf = Config::General->new( -ConfigFile => 'config.conf',
> > -ForceArray => 1 );
> 
> How I can pass this -ForceArray to Config::General in my catalyst app?
> 
By having the current version of Config::Any installed, like I said in the 
first place. :)

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Defining ARRAY in Config::General config

[Andrew Rodland]

On Tuesday, September 21, 2010 02:52:52 am Octavian Rasnita wrote:
> The problem appears when the array should have just a single item, because
> in that case Config::General reports it as a scalar value.
> 
> I don't know if there is a better way of defining a single-item array with
> Config::General, but I found a workaround that may work. We can use
> something like:

With Config::General >= 2.47 and Config::Any >= 0.20, you can use the syntax 
"foo [ bar ]" or "foo = [ bar ]" to set the key "foo" to an arrayref 
containing the single value "bar". The latest version of 
Catalyst::Plugin::ConfigLoader will ensure that you're up to date.

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Instruction for SSL configuration for Apache and fastcgi

[Andrew Rodland]

On Thursday, August 05, 2010 04:26:52 pm Kutbuddin Doctor wrote:
> Can someone provide apache config scripts for this situation? Do I need
> Port 443 for the FastCgiServer command in Apache? Will these 2 VH's use
> separate Session FastMmap files? Log files?

No, No, and only if you ask for it.

Really there's nothing to it, just do it. Write one virtualhost with


ServerName foo
[ ... other crap ...]
Alias / /path/to/fcgi/


and one with


ServerName foo
SSLEngine On
[... other crap ...]
Alias / /path/to/fcgi/


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Question on Perl versions with Catalyst

[Andrew Rodland]

On Wednesday, July 07, 2010 06:07:39 am Joe Landman wrote:
> Hi folks
> 
>We are redoing one of our applications, and I wanted a quick sync
> against which Perl versions are currently "blessed".  I remember that
> 5.10.0 did not work due to a bug in the Perl base.  Are there any issues
> we need to be aware of for 5.12.0 or should we stick with 5.10.x (x
> greater than or equal to 1)?

5.12.x are all great and very solid, and 5.10.1 is fine too. Many of the 
versions of 5.10.0 that vendors build are also patched to remove the horrible 
bugs, but you should run 5.10.1+ anyway because it's better. :)

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Alternatives to DBIx?

[Andrew Rodland]

On Sunday, April 18, 2010 12:14:55 am Eden Cardim wrote:
> On Sat, Apr 17, 2010 at 8:04 PM, John Karr  wrote:
> > Both Fey and SQLDB are a nativist approach to SQL (much like TT is to
> > html)
> 
> TT isn't a native approach to html, by far. In fact, it has quite a
> few things going against it's use to generate html. Besides what
> jshirley already said, it doesn't produce streamable output and once
> your documents get complex, it's not very easy to produce nicely
> indented code with it. For a "native approach" to html, try
> HTML::Zoom.

Very true. In fact, ignoring the fact that it ships with a couple default 
plugins that know how to do HTML-compatible string encoding, TT doesn't 
actually know anything about HTML. It's not actually an HTML tool at all; it's 
a tool for pasting strings together. It's entirely possible for those strings 
to be HTML tags, but since TT is agnostic, it's equally good at producing 
completely mangled, invalid HTML as it is at producing useful HTML (note: not 
a value judgment, just a simple fact!) If that's what "nativist" means, and 
you're looking for a tool that takes a string-schlepping approach to *SQL*, 
then you need look no further than a hundred thousand shitty PHP apps ;)

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Alternatives to DBIx?

[Andrew Rodland]

On Saturday, April 17, 2010 06:04:58 pm John Karr wrote:
> In my own analysis the Time and Effort to learn DBIx is greater than the
> Time wasted writing repetitious DBI code, the time I've already invested
> on DBIx has shown that there is a better way than DBI, but for me it isn't
> DBIx.

In my own analysis the fact that you still think that there is a thing called 
DBIx proves that the time and effort you've spent learning _DBIC_ is zero.

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Outcome of the "Security issue with hashed passwords in C:P:A:Password"?

[Andrew Rodland]

Please, make some more public insults. I would be even further entertained if 
you would make more sweeping declarations about modules you didn't even read 
the documentation for and have never used in your life, and submitted some 
more patches that duplicate functionality poorly. 

You can put on a show all you like for these people. If you keep it up, you 
can even get me to quit just to avoid your toxic presence. But I know you far 
too well. You'll never convince me that you're doing anything but trolling.

On that topic, when did you stop being banned on this list? I'm guessing 
"never".

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Outcome of the "Security issue with hashed passwords in C:P:A:Password"?

[Andrew Rodland]

On Saturday 10 April 2010 11:21:27 am Evan Carroll wrote:

> Also, I should point out that Crypt::SaltedHash permits the same
> stupid idea of a static, non-random salt set up in the constructor.
> This makes it slightly more fishy: why would you ever want to use this
> module to do what I just did without it?
> 
> # salt: You can specify your on salt. You can either specify it as a
> sequence of charactres or as a hex encoded string of the form
> "HEX{...}". If the argument is missing, a random seed is provided for
> you (recommended).

That's not why that argument exists, that's not how it gets used, and that's 
not how C::A::Cred::Password uses it. If you'd thought for half a second, it 
might have occurred to you that that calling convention actually exists to 
support exactly what you're asking for -- storing the hash and salt separately 
for some bizarre reason despite that each is entirely useless without the 
other.

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Outcome of the "Security issue with hashed passwords in C:P:A:Password"?

[Andrew Rodland]

On Friday 09 April 2010 09:49:24 am Evan Carroll wrote:
> The vulnerability was never against salted_hash. I've since learned
> what Crypt::SaltedHash is I just don't believe I have a reason to use
> it. Why would I want to use something that serializes the hash and
> password into one database column when I can simply store them
> separately?

Why would you want the complexity of storing them separately when you could do 
it the way every other system on the planet does it? Why would you add 
duplicate functionality that's inferior to what it duplicates?

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Re: Outcome of the "Security issue with hashed passwords in C:P:A:Password"?

[Andrew Rodland]

On Thursday 08 April 2010 08:12:24 pm Toby Corkindale wrote:
> On 08/04/10 22:49, Daniel Pittman wrote:
> > ...but your lost database *also* exposed user account/password pairs,
> > which can now be tried against other services, since people usually use
> > the same weak password and username all over the place.
> 
> .. if they are using sufficiently weak passwords, such that they're
> present in a rainbow table? (Or do such rainbow tables contain every
> single possible SHA-1 value, ie. from random-looking strings that happen
> to correspond to the same sha-1 as the actual password?)

Or weak enough to brute-force. Not using salt reduces the difficulty of brute-
forcing passwords by an order of magnitude (well, some number of orders of 
magnitude depending on the number of users you have) because you can make a 
single cracking run against *all users' passwords in parallel* rather than 
attacking each account individually.

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Outcome of the "Security issue with hashed passwords in C:P:A:Password"?

[Andrew Rodland]

>   * In what circumstances was an attack possible?
> ie. What combination of modules, options, auth methods.

* You use Catalyst::Authentication::Credential::Password.
* With the "hashed" password_type.
* And your database is compromised.

>   * Which versions were vulnerable, and if any, at what version were
> they fixed, if any?

All versions. "hashed" shouldn't be used except by those who have broken and 
stupid user databases; fixing it isn't possible. What we perhaps *should* do 
is warn when it's used, and do a better job of marking it as unsuitable for 
use in the perldoc.

>   * What mitigating factors can be applied to existing systems to reduce
> their vulnerability to the attack?
> 

* Use password_type = "salted_hash" to get salted hashes.
* Or use password_type = "self_check" and a store that provides secure 
password handling via the user object, e.g. 
Catalyst::Authentication::Store::DBIx::Class w/ DBIx::Class::EncodedColumn on 
the user table, or Catalyst::Authentication::Store::LDAP (plus a suitable 
configuration on your LDAP server; some of them will allow you to do stupid 
things like plaintext passwords, but we can't help that).
* If you have a user database that uses plain hashed passwords, start figuring 
out how to change over to a proper method and how to force all of your users 
to reset their passwords.

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Security issue with hashed passwords in C:P:A:Password

[Andrew Rodland]

On Tuesday 23 March 2010 03:17:17 pm Evan Carroll wrote:
> This is broken implementation.

It would be if anything you said were true; fortunately it's not, and both 
available methods of doing salted passwords with 
Catalyst::Plugin::Authentication do salt entirely the correct way.

Your unncecessary and condescending lectures are, however, greatly appreciated 
as usual.

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] KiokuDB, MongoDB and the NoSQL thing

[Andrew Rodland]

On Tuesday 02 March 2010 12:07:23 am S.A. Kiehn wrote:
> I have a couple of production Catalyst/DBIx::Class sites on Debian stable,
> and then on my personal hobby site I use local::lib to try out new
> things.  Recently I split out my users for this site into a separate model
> and I thought it a good exercise to learn and use KiokuDB.  It was just a
> couple of simple objects, users & roles, but I believe I have a better
> understanding of how a schema-less data model would work.  All I do are
> lookups based on ID or indexed object values, but doing any type of
> ordering by dates or titles is a mystery.  It seems that the Search::GIN
> is to provide this sort of functionality, but it is under-documented and
> has not had an update for awhile.
> 
> I do
>  not see many posts
>  regarding uses of KiokuDB within Catalyst so I was curious about the
> opinion of the community in regards to its usage.  Is it still to early
> within development?
> 
> Also, I have been reading more about the increase in the NoSQL interest,
> with a particular interest in the MongoDB database (it seems to be similar
> in some respects to KiokuDB), but I do not find Perl people in the
> discussion as much as others (Ruby, PHP).  Are there developers in the
> Catalyst community who lean toward NoSQL concepts over traditional RDMS's,
> or is best to view as a tool to use at times?
> 
> How about MongoDB?  Am I being suckered by another bandwagon?
> 
Kioku is a really beautiful idea. I was hoping to use it on a recent project 
but unfortunately it wasn't the right fit -- one of the most common access 
patterns I would have to support for this app was unduly difficult in Kioku at 
this time so I decided to put it off. So, no real first-hand advice from me.

Might I suggest hitting #catalyst and #kiokudb on irc.perl.org? I know that 
there's at least one person using MongoDB with Catalyst on #catalyst, so you 
can probably get some words of wisdom.

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] How to read the performance information

[Andrew Rodland]

On Thursday 18 February 2010 11:14:46 pm Julien Sobrier wrote:
> The time don't add up. Form the timing under Action. it took less than 1
> second. But the line before says 8.27s. Does it mean 7+ seconds were spend
> doing something else? Doing what?
> 
There are two things that spring to mind:

1. Time spent reading the request from the user (after the connection is made 
but before the full request is received) is accounted to the "Request took" 
time but not to any action. Normally this should be a very small amount of 
time for a GET, but in case of very bad network conditions it could be longer. 
This wouldn't be any indication of the performance of your app.

2. Your system could have had a major I/O stall between the beginning of 
request handling and the beginning of action dispatch, or between the end of 
action dispatch and the end of request handling. You would probably know if 
this was happening. :)

3. Any other suggestions?

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] FastCGI deployment - slow to complete request

[Andrew Rodland]

On Monday 15 February 2010 10:47:45 am Steve Rippl wrote:
> Andrew Rodland wrote:
> > Fix: Use a current snapshot version of mod_fastcgi. Source tarballs can
> > be found in http://www.fastcgi.com/dist/ or if you'd like a deb, I've
> > built
> > http://cleverdomain.org/libapache2-mod-fastcgi_2.4.6.99~snap20081109_i38
> > 6.deb (for Debian 5.0 i386).
> > 
> > Andrew
> 
> Thanks for providing this, but when I install it and restart apache I get
> 
> wsdsis:~# /etc/init.d/apache2 start
> Starting web server: apache2apache2: Syntax error on line 185 of
> /etc/apache2/apache2.conf: Syntax error on line 1 of
> /etc/apache2/mods-enabled/fastcgi.load: Cannot load
> /usr/lib/apache2/modules/mod_fastcgi.so into server:
> /usr/lib/apache2/modules/mod_fastcgi.so: wrong ELF class: ELFCLASS64
>  failed!
> 
> and I'm on a 32bit kernel (in case that's what ELFCLASS64 is referring to?)

Apologies, somehow I had uploaded a bad build -- it says i386 in the filename 
but it was actually amd64. Fixed one is uploaded (at the same address, so just 
pull it again and install it again).

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] FastCGI deployment - slow to complete request

[Andrew Rodland]

On Sunday 14 February 2010 10:59:54 pm Steve Rippl wrote:
> If I switch this back to the built in server then the page is
> completed faster than I can notice and the page renders correctly
> immediately.  Back on FastCGI and even a simple page request is taking
> ~10 seconds to complete (again, that html arrives straight away, but
> then the browser keeps spinning as if it's still waiting on something).

It's a bug in mod_fastcgi that mangles the Content-Length header when it's 
used together with output filters (almost always mod_deflate), and there are a 
couple of ways to deal with it.

Workaround: Disable mod_deflate, or at least prevent it from activating on 
anything that might come from mod_fastcgi.

Fix: Use a current snapshot version of mod_fastcgi. Source tarballs can be 
found in http://www.fastcgi.com/dist/ or if you'd like a deb, I've built 
http://cleverdomain.org/libapache2-mod-fastcgi_2.4.6.99~snap20081109_i386.deb 
(for Debian 5.0 i386).

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] myapp_fastcgi.pl does not run in background

[Andrew Rodland]

On Tuesday 05 January 2010 06:28:36 am Emmanuel Quevillon wrote:
> On 01/05/2010 12:51 PM, Андрей П. Ковбович wrote:
> > Hi,
> >
> > try this option: --detach
> 
> Hi,
> 
> That solved my problem. But it could be good to change it from the help
> message which is still :
> 

The correct option is --daemon; this is a bug in 5.80016. It's been fixed in 
svn (r12387) but not released yet.

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Accessing $self in a plugin?

[Andrew Rodland]

On Wednesday 23 December 2009 03:40:37 am Octavian Râşniţă wrote:
> Hi,
> 
> I use Catalyst::Controller::HTML::FormFu but in some actions I don't want
>  to use the FormConfig attribute because it would automaticly generate and
>  process a form, which takes much time. I want to do that only if the
>  already generated template and data was not found in the cache.
> [...]

> > First, is this correct? (or it might appear some issues). I know that the
> plugins are not recommended, but it is not a Catalyst plugin for public
>  use, but only one for my app.

Maybe you should extend C::C::HTML::FormFu to have the caching behavior you 
want, and then just use *that* as a controller base class?


> And if it is ok, is it possible to get $self in the plugin in order to do
> $self->form?
> 
> Or I will need to send it explicitly using:
> 
> $ff($self, 'path/to/config_file');
> 

When running an action, the '$self' is the Controller. Outside of the action, 
you can get the controller for the dispatched action with $c->controller() (no 
argument).

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Help with weird client: POST without Content-Type

[Andrew Rodland]

On Friday 18 December 2009 05:11:56 am Alex Povolotsky wrote:
> Hello!
> 
> I'm (still) working with weird client-weird server-weird DB system, and
> I need some more help from community.
> 
> Weird self-written client sends POST request without setting
> Content-Type at all.
> 
> Client will be fixed, but until then I have to force Catalyst to parse
> that request as if it's type was application/x-www-form-urlencoded.
> 
> How do I do that?
> 
Here's a suggestion -- not sure if it's the best one, but it should work. In 
your app class (MyApp.pm or whatever) do:

before 'prepare_body' => sub {
my $c = shift;
if ($c->req->method eq 'POST' && !defined $c->req->content_type) {
$c->req->content_type('application/x-www-form-urlencoded');
}
};

The actual decision on how to parse the body is done by HTTP::Body, not by 
Catalyst, so it can't easily be overridden, but using this trick we hook into 
Catalyst after the headers are parsed but before HTTP::Body is invoked, and 
fool it into thinking that the Content-Type actually is what you want it to 
be.

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] namespace problem

[Andrew Rodland]

On Saturday 21 November 2009 02:34:07 am gutta wrote:
> Hi,
> 
> I tried to use "use parent 'MyApp::Controller::Root';"
> 
> instead of use parent 'Catalyst::Controller'; in all my other
> controllers(for ex: User.pm).
> 
> The reason is that Root.pm is already inheriting Catalyst::Controller.
> 
> But when i do this catalyst dispatcher is considerting all controller
> actions in my other controllers under namespace ''.
> 
> But if i declare __PACKAGE__->config->{namespace} = 'user'; its working as
> expected.
> 
> my server debug logs are here http://scsys.co.uk:8001/36484
> 
> Do i need to explicitly define namespace in each and every controllers in
> that case or is there any other way to achieve it?
> 
For the sake of sanity, what you need to do is stop inheriting from a concrete 
controller. It really doesn't make a lot of sense and there are a lot of ways 
it could break something. As Moritz writes, if you need a controller base 
class, write a controller base class and inherit from that.

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] does detach cancel forward

[Andrew Rodland]

On Saturday 07 November 2009 05:30:27 pm Andrew Rodland wrote:
>  out, detach throws an extension that unwinds that whole stack.

Being tired makes me type words that *sound* similar to the one I meant. 
Exception. Not extension. Exception. :)

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] does detach cancel forward

[Andrew Rodland]

On Saturday 07 November 2009 01:08:33 pm Steve Rippl wrote:
> it's just that I had started thinking
> in terms of "nested" flow control because that's what I wanted (wishful
> thinking...).  I thought perhaps each forward created a separate
> nest/level I could detach out of and previous forwards were
> "remembered", but obviously this isn't the case.

No, this *is* the case, 100%. Forward is nothing more than a function call, so 
you can nest it and you get a call stack. It's just that, as I pointed out, 
detach throws an extension that unwinds that whole stack.

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] does detach cancel forward

[Andrew Rodland]

On Wednesday 04 November 2009 04:19:42 pm Ovid wrote:
> Think of detach as "game over", if that helps (probably doesn't).  From the
>  docs, detach() is described as:
> 
> The same as forward, but doesn't return to the previous action when
>  processing is finished.
> 
> I think that description might be a bit confusing for some, as your
>  question suggests.
> 

Yeah, there are at least two big shortcomings.

1. I think that we should stop trying to over-simplify things here, or at 
least stop *only* providing a simplified version and tell the truth: detach 
forwards, and then it throws an exception. That exception propagates up until 
the whole stack of running actions is unwound, and then Catalyst catches it 
and continues processing as usual, calling any 'end' action and then doing 
'finalize'.

2. There's a "Flow Control" section in Catalyst::Manual::Intro that paints a 
better picture than perldoc Catalyst, but someone going directly to the docs 
for forward, detach, etc. can easily miss the pointers to 
Catalyst::Manual::Intro. The whole Manual::Intro business is a mess that 
nobody wants to touch. I don't know what to do with it either. :)

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] auto method never triggered

[Andrew Rodland]

On Sunday 01 November 2009 08:07:32 pm Julien Sobrier wrote:
> Thank you
> 
> Shoudl It put __PACKAGE__->config->{namespace} = ''root;, or simply remove
> this line?
> 
You should leave it how it is in the root controller, and remove it in the 
admin controller.

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Debian recommendation

[Andrew Rodland]

On Tuesday 27 October 2009 07:14:02 pm Evan Carroll wrote:
> > Then I suppose it's a good thing that no such thing happens.
> 
> Sure it happens;

Taking the world's most goddamn *stupid*, unpredictable, and un-packageable 
code and turning it into something that's actually *maintainable* and meets 
the most minimum guidelines for a well-behaved package is not "taking 
something and knowingly breaking it", it's saving me from having to do violent 
things to people.

And the changes don't break anything unless you do something fundamentally 
stupid, like touching the files with the big NOT YOURS signs on them. (i.e. 
running CPAN as root.)

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Debian recommendation

[Andrew Rodland]

On Tuesday 27 October 2009 05:18:32 pm Evan Carroll wrote:
> I simply disapprove of taking
> something knowingly breaking it, and publishing it as if nothing
> happened.

Then I suppose it's a good thing that no such thing happens.

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Catalyst::Test configuration questions

[Andrew Rodland]

On Monday 26 October 2009 04:51:57 pm Evan Carroll wrote:
> My latest project, a Craigslist posting tool, is configured through
> the applications yaml conf file. I'm looking for a way to test based
> the conf file with Catalyst::Test. Any idea of how to accomplish this?
> 
You're gonna need some 
http://dl.getdropbox.com/u/129905/specialized-hardware.jpg for that.

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Debian recommendation

[Andrew Rodland]

On Saturday 17 October 2009 03:20:49 pm Octavian Râşniţă wrote:
> Is it really possible to install locally perl modules using the module
> local::lib if this module is installed in the default location by root?
> 
Yes, you just need to not have a CPAN config that has /root/.cpan has a 
"cpan_home". If you have a ~/.cpan/CPAN/MyConfig.pm then edit that file (using 
a text editor or CPAN.pm) and fix the cpan_home, build_dir, hist_file, and 
keep_source_where options so that they point somewhere you can actually write 
to. If you don't (if the CPAN/Config.pm in effect is global), then just cp it 
into your local PERL5LIB and then edit it as such.

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Catalyst benchmark 5.7 VS 5.8

[Andrew Rodland]

On Tuesday 29 September 2009 03:44:33 am Carl Johnstone wrote:
> What everybody else in this thread is referring to as "shared" memory is
> actually the amount of memory that hasn't needed to be duplicated because
> of the copy-on-write semantics within the Linux kernel. Unfortunately
> there's currently no easy way I know of to get these figures on Linux.

In my experience with linux+perl+fastcgi, "VmHWM - (VmExe + VmLib)" (stats 
from /proc/*/status) gives a reasonable upper bound on the incremental cost of 
a process -- that is, how much your "free memory" total will go up or down if 
you add or remove one process. It's a loose upper bound because the stuff that 
it knows to subtract is quite unlikely to become unshared, but there's a bunch 
of data that's probably being shared that it doesn't know about. For an 
example: the formula above gives 14,900kB when applied to an instance of a 
beta app that I happen to have at hand; actually killing an instance gives an 
increase in free memory (as reported by "free") of 11,400kB, so the error is 
3,500kB. The error depends on the app, but it's otherwise pretty consistent, 
which makes this a good enough tool to use for a "kill processes that start 
chewing memory" script.

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Catalyst benchmark 5.7 VS 5.8

[Andrew Rodland]

On Monday 28 September 2009 12:56:36 am Fayland Lam wrote:
> I'm wondering if someone here did a benchmark between Catalyst 5.7 and 5.8

Benchmark, as requested. View this message at http://p3m.org/pfn/3499 if your 
mailer is too high-tech for fixed-width text.


The Setup:

Linux 2.6 OpenVZ, on Quad 2.2GHz Opteron.
Perl 5.10.0 + debian patches.
FastCGI via Apache 2.2, mpm_event, mod_fastcgi.
The two test instances were running on the same machine, with the same perl
and the same checkout of the app, but different local::lib directories.

FastCGI was set to 10 processes. The page I was hitting was from a real
checkout of a real production app, however it was the front page of the
site, which is fairly light on dynamic content. I figured this was
appropriate since it would better show any differences in Catalyst rather
than spending a lot of time in the backend. The code still hits several
models, 3 actions, and a view, but perhaps it was a little too fast since,
as you'll see below, my throughput was ultimately limited by the number of
running processes. Each instance was given a "warmup" run (the results of
which were discarded) before the following tests were run. My tool collects
statistics on the return status, but for all tests the returns were all 200
(success) so I've left out that row. 

|| 20 requests/second (20 threads) for 60s
| Metric|| Catalyst 5.7010  || Catalyst 5.8011
|===||==||==
| Hits  || 1200 || 1200
| Throughput|| 20.00 req/s  || 20.00 req/s
| Latency (mean)|| 0.072s   || 0.074s
| Latency (SD)  || 0.013s   || 0.017s
| Latency (Q1-Q3)   || 0.064 - 0.078s   || 0.066 - 0.080s

|| 40 requests/second (40 threads) for 60s
| Metric|| Catalyst 5.7010  || Catalyst 5.8011
|===||==||==
| Hits  || 2400 || 2400
| Throughput|| 40.00 req/s  || 40.00 req/s
| Latency (mean)|| 0.083s   || 0.088s
| Latency (SD)  || 0.020s   || 0.024s
| Latency (Q1-Q3)   || 0.069 - 0.095s   || 0.072 - 0.100s

|| 80 requests/second (80 threads) for 60s
| Metric|| Catalyst 5.7010  || Catalyst 5.8011
|===||==||==
| Hits  || 4675 || 4637
| Throughput|| 77.92 req/s  || 77.28 req/s
| Latency (mean)|| 0.688s   || 0.708s
| Latency (SD)  || 0.178s   || 0.187s
| Latency (Q1-Q3)   || 0.617 - 0.800s   || 0.726 - 0.811s

The difference between 5.7 and 5.8 in these results is consistently in favor
of 5.7, but by a margin of between 0% and 5% which is not a whole lot in my
book. By my unscientific measure (i.e. looking at "top") of memory usage,
5.7 used 138MB of RAM (for fcgi-pm + 10x fcgi children) whereas 5.8 used
184MB, so that's a 33% expansion, which is a more significant issue. I have
a feeling that most of that is shared, and so the difference wouldn't
increase much with an increase in the number of processes, but I haven't
investigated that yet.

Questions?

Andrew "hobbs" Rodland

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Re: Catalyst benchmark 5.7 VS 5.8

[Andrew Rodland]

On Monday 28 September 2009 09:31:13 pm Fayland Lam wrote:
> Toby Corkindale wrote:
> > Fayland, I was looking at the benchmarks that you linked, and was just
> > wondering which version of Perl you're running against?
> >
> > (CentOS 5 was one of the operating systems that came with the
> > badly-patched Perl with the slow bless performance.. although I'm sure
> > it's been patched by now?
> > ie. http://blog.vipul.net/2008/08/24/redhat-perl-what-a-tragedy/
> > )
>
> Thanks for your update. but it doesn't help on the benchmark since they
> are run on the same condition. so 5.7 is really better than 5.8 under
> siege.
>
That doesn't follow. If your perl is broken and very slow at doing something 
that 5.8 does much more often, then 5.8 can be slower for you without being 
slower for everyone else.

I have a real app and a suitable test system at hand -- I'll run some benches 
of my own and at least add a few more data points to the mix.

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] FastMmap.pm error while writing sessions file to shared file system

[Andrew Rodland]

On Wednesday 05 August 2009 01:27:11 am gutta wrote:
> could anyone let me know what the problem here?

The problem is that what you're trying to do is impossible. You can't mmap a 
file on a non-local fs, so Cache::FastMmap won't work. I wouldn't expect any 
other file-based cache (or SQLite) to be consistent either. If you need to 
distribute your session store across multiple backend machines you want a DB 
store or memcached.

Andrew


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] passwordless LDAP authentication

[Andrew Rodland]

On Monday 27 July 2009 04:38:35 am Rodrigo wrote:
> Hi all,
> I'm using Catalyst::Authentication::Store::LDAP to authenticate users, but
> now I need to allow some of them to single-signon without a password, like
> this:
> [...]
> > I'm looking at the authentication internals and it seems to be missing a
> per-user flag to disable password checking. Only a global realm-based
> password_type=>'none' exists. Am I correct?
>
That's not auth in general, it's Credential::Password. You can write your own 
credential that implements your own policy and have it do whatever you like.

> To make matters worse, LDAP::User::check_password also checks user roles
> since it needs the password to bind to the ldap server. That could make it
> more difficult to implement a passwordless flag at any level on the
> authenticate chain.
>
Store::LDAP has an option for whether or not to rebind as the given user when 
doing role searches. If it's off, and if your LDAP permissions are set 
appropriately, you shouldn't need the user's password at any phase.

Andrew


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] More up-to-date version of Perl 5.10 ...

[Andrew Rodland]

On Monday 20 July 2009 02:42:51 pm Kiffin Gish wrote:
> Hi there.
>
> Installed Catalyst and at the end it said that because of a bug in Perl
> 5.10 I need to update to a newer version. Which version do you recommend
> that is the most stable for Catalyst?

If you build your own perl, then take 5.10.0 and patch it for RT#488088 before 
you compile. If you get perl from a vendor, then you should hope that they 
patched their version a year ago, and if not you should start yelling loudly 
at them.

Either way, 5.10.0 (until 5.10.1 arrives).

Andrew





___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] more description for FAST CGI deployment in catalyst cookbook?

[Andrew Rodland]

On Wednesday 15 July 2009 06:23:24 pm kakim...@tpg.com.au wrote:
>
> Again, my question is, where do I put the configuration above in?
> apache.conf ? httpd.conf? Doesn't say :(
>
Wherever it needs to be for your setup; apache configurations differ quite a 
bit by vendor, and this is the Catalyst cookbook, not the Apache instructions.

Andrew


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] how to implement Transactions (over different db tables) in a Catalyst project

[Andrew Rodland]

On Monday 06 July 2009 05:37:49 pm kakim...@tpg.com.au wrote:
> > Did you even look for this in the manual?
> >
> > http://search.cpan.org/~ribasushi/DBIx-Class-0.08107/lib/DBIx/Class/
> > Storage.pm#txn_do
> >
> > If not, why not. If so, how is this not clear?
>
> Well, it's really clear now . I suppose someone has updated the
> documentation since I posted this thread up.
>
That's the same version of the same doc as you mentioned in the first post of 
the thread :)

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Potential query string pollution vulnerability?

[Andrew Rodland]

On Tuesday 16 June 2009 04:11:19 am Tobias Kremer wrote:
> To me, this never looked like a potential security threat because
> $c->req->param('name') is correctly inserted/quoted via bind
> parameters, right? Well, let's see what happens, if we "pollute" the
> query string a bit:
>
> /crashme?name=Foo&name=Bar
>
Using $c->req->param for this kind of purpose (or, if you ask certain people, 
for any purpose) is discouraged, and has been discouraged as long as I can 
remember, for this reason. Use $c->req->params and validate your input. 
(Incidentally, if you'd used $c->req->params->{name} the behavior you would 
have gotten would have been "WHERE name='Foo' OR name='Bar'" which can be a 
really useful behavior straight out of the box -- but the point stands that 
you have to know what your data is, know what your data needs to be, and make 
sure that the two are reconcileable before you do anything :)

Andrew



___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Notes on installing lighttpd and FastCGI for Catalyst

[Andrew Rodland]

On Saturday 06 June 2009 04:04:08 am kakim...@tpg.com.au wrote:
> hi guys,
>
>  I'm facing some problems with
> http://dev.catalyst.perl.org/wiki/deployment/lighttpd_fastcgi.

This message looks oddly familiar.

Andrew



___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Re: error when using Authentication::Store::Minimal

[Andrew Rodland]

You shouldn't be using the login method to begin with, you want authenticate. 
Pay less attention to the book (which has very little to do with anything) and 
more to the docs.

Andrew


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Looking for a working example using DBIC and Authentication

[Andrew Rodland]

On Thursday 28 May 2009 07:36:29 pm Simon Baird wrote:
> > Thanks for the advice. I might start fresh and see if I can pinpoint
> > where things went wrong.
>
> Ok, so just now I have:
>
> * Googled and ended up here:
> http://search.cpan.org/~mramberg/Catalyst-Runtime-5.7000/lib/Catalyst/Manua
>l/Tutorial/Authentication.pod
>
Google is not to be trusted: that's 3 years old. Its advice was reasonably 
good three years ago, but not so much today.

The current version is at http://search.cpan.org/~hkclark/Catalyst-
Manual-5.8000/lib/Catalyst/Manual/Tutorial/05_Authentication.pod .

Andrew



___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Mason + DBI + Catalyst?

[Andrew Rodland]

On Monday 25 May 2009 05:35:45 pm Daniel Carrera wrote:
> Is there any good documentation for Catalyst that is based on Mason?
>
Catalyst is Perl. Catalyst apps are Perl apps. All the docs you need on Mason 
are in perldoc Mason and all the docs you need on DBI are in perldoc DBI. The 
info you need on how things get glued together is in perldoc 
Catalyst::View::Mason and perldoc Catalyst::Model::DBI.

And incidentally, you're wrong about DBIC. As soon as you get into queries for 
related tables, DBIC will be reducing the amount of code you need to write 
(and the number of potential screwups) tenfold. Then throw in "bonus" features 
like txn_do and the deployment goodies... it ends up being worthwhile pretty 
often ;)

Andrew


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Strange RenderView error

[Andrew Rodland]

On Sunday 24 May 2009 03:51:47 pm Ivan Wills wrote:
> If I understand it correctly the :Arg attribute takes extra path parameters
> and converts them to method parameters so I can't see why the problem would
> occur.
>
1. That happens by default.
2. :Args(0) says that there are _no_ extra args on the path and the dispatcher 
shouldn't match them.
3. :Arg(0) does nothing (at least, it should do nothing) because it's not 
:Args(0).

Andrew


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Who wants to be rid of the "Unknown Error" w/attributes bug on 5.10?

[Andrew Rodland]

On Monday 11 May 2009 05:45:01 pm Jonathan Rockway wrote:
> Or, you can use Debian, which fixed this bug in its Perl a while ago:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=488088
>
Not everyone uses Debian, and I, for one, would much rather be able to tell 
people "get 5.10.1" than to have to explain what "patch" is or try to convince 
them to switch their operating system. A fix from upstream is long overdue. :)

Andrew


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Forward to view question

[Andrew Rodland]

On Wednesday 06 May 2009 09:01:43 am Dennis Daupert wrote:
> On Tue, May 5, 2009 at 7:24 PM, Tomas Doran  wrote:
> > my $output = delete $c->res->{body};
> > opem(FH, ">file") or die;
> > print FH $output;
> > close(FH);
> >
> > will do what you want...

> There are some things that aren't so obvious to me. Where would I place the
> code represented in your snippet?  I can't just hang it out in the main
> body of package hde::View::TTprint, 

In that example you don't *have* a View::TTprint. Or if you do, it's just 
another subclas of C::V::TT with a different config and search path. No 
overloading, no OUTPUT. You forward to the view, it writes into $c->res->body 
like it always does. You take the data out of $c->res->body and write it to a 
file, then null out $c->res->body so that RenderView will fill it in later 
using your default_view.

Andrew


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Forward to view question

[Andrew Rodland]

On Tuesday 05 May 2009 09:54:17 am Dennis Daupert wrote:
> I've created a view that's intended to write a couple of files to the file
> system.
>
> The output filename needs to be dynamically set. I'm having a bit of a go
> figuring out how to do that.
>
> The TT configuration documentation speaks of an output subroutine:
>
> OUTPUT => \&output,
>
> Later on in the view base class...
>
> sub output {
>   my $filename = shift;
>   # do stuff
> }
>
> Here's my question:
> How do I get the $filename into sub output when I forward to the view?
>
>
This is kind of lazy lousy code because I hate trying to squeeze real code 
into an email. Hopefully it demonstrates the technique. :)


package MyApp::View::TTtoFile;
use strict;
use base 'Catalyst::View::TT';

my $outfile;

sub output {
  # do stuff to $outfile
}

sub process {
  my $self = shift;
  (undef, $outfile) = @_; # Ignoring $c
  return $self->next::method(@_);
}

__PACKAGE__->config( ... etc. etc. ...);


And then in your app you can just 

$c->forward('View::TTtoFile', '/var/ham/sandwich.txt');

Andrew



___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Local action in controller not mapping to template (retry)

[Andrew Rodland]

On Monday 20 April 2009 08:42:16 am Anne Brown wrote:
> t0m,
>
>
> My development environment is a Windoze VISTA 64-bit OS, running Apache
> 2.2.11,
> and perl 5.8.8 and plain old CGI.   My other development environment is the
> same except for a Linux OS and is having the same problem.
>
>
> You said that :Private makes an action not dispatchable, however, the line:
>
>
>  sub index : Private {}
>
>
> in my root controller renders the main template.

That's legacy and you shouldn't do it. It should be

  sub index :Path Args(0) { ... }

Having index be a private action made no sense, which is why nothing does that 
anymore -- the helper scripts don't generate it, and the tutorial doesn't show 
it. It only still _works_ so that old apps aren't broken.

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] C::Engine::HTTP taking very long

[Andrew Rodland]

On Monday 20 April 2009 06:26:57 am Ian Wells wrote:
> 2009/4/20 Andrew Rodland :
> > The time spent in inet_ntoa
> > is your system DNS resolver choking while trying to reverse-lookup the
> > source IP address of the request. Most likely situation: you're using
> > RFC1918 addresses and your network is set up improperly to do DNS for
> > these. If you can't fix this, hosts file entries might alleviate the
> > problem.
>
> I wouldn't necessarily assume that everyone has reverse lookup DNS on
> their test network.  (Mine certainly doesn't, and I've been bitten by
> this slowing things down in the last few days.)  Is there any chance
> we could make this lookup configurable?

You don't need to have reverse DNS, you just need to not have a _broken_ DNS 
setup. Queries for RFC1918 addresses should fail NXDOMAIN instantly (or return 
success, of course). It's only when things are misconfigured that you get a 
slow SERVFAIL, in which case you can patch it up by setting up some (non-
broken) local DNS or fooling with hosts.

Anyway, looking at the source of 5.8001 it looks like reverse-lookup on the 
remote address has already been removed from Catalyst::Engine::HTTP::_sockaddr 
-- the remote hostname is produced lazily only when $c->req->hostname is 
called. Engine::HTTP only calls gethostbyaddr on the local bind address, which 
in all fairness really ought to work -- although perhaps an exception could be 
made to force "localhost" without actually doing (and failing) the lookup in 
the case of INADDR_ANY?

Andrew


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] C::Engine::HTTP taking very long

[Andrew Rodland]

On Monday 20 April 2009 04:35:05 am Terence Monteiro wrote:
> I'm getting very high times when running my Catalyst application in
> standalone mode. I used Devel::NYTProf and zeroed in on a few subs in
> Catalyst::Engine::HTTP which take long:
>

The times for accept are because accept is the function that waits for a new 
incoming connection -- not a bug, 100% expected. The time spent in inet_ntoa 
is your system DNS resolver choking while trying to reverse-lookup the source 
IP address of the request. Most likely situation: you're using RFC1918 
addresses and your network is set up improperly to do DNS for these. If you 
can't fix this, hosts file entries might alleviate the problem.

Andrew


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] about catalyst authentication

[Andrew Rodland]

On Saturday 18 April 2009 01:28:30 am Malloy wrote:
> After restart apache, user must login again. I find $c->user_existsis not
> true.
>
> Why?

Because you're using Session::Store::FastMmap and the session cache file 
didn't exist before your app started, so Cache::FastMmap deletes it on exit?

Andrew



___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Including a submenu

[Andrew Rodland]

On Monday 06 April 2009 10:06:52 am toppe...@gmail.com wrote:
> However, when I load the page,I get the following error:
> Couldn't render template "file error - /menu.tt2: absolute paths are
> not allowed (set ABSOLUTE option)"
>
> Am I going missing something obvious, or going about this in the wrong
> way?

Set 'page' to something that doesn't start with a slash?

Andrew


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Browser still waiting after completed transfer

[Andrew Rodland]

On Saturday 21 March 2009 04:12:48 pm Christian Lackas wrote:
> Hi Everybody,
>
> currently have a strange problem with a Catalyst app, which I developed
> on Gentoo Linux and now try to deploy on Debian/Lenny. On Debian, the
> browser (Firefox) waits a couple of seconds (~10s) after it has already
> received all content (as shown by Firebug), apparently still waiting for
> something (but Firebug does not show anything else).
> Is it possible that I get a wrong Content-Length header and thus the
> browser waits for the web page to be completely transferred too long?
> Don't see this on Gentoo.
>
> Apache/2.2.9 (Debian) mod_fastcgi/2.4.6 PHP/5.2.6-1+lenny2 with
> Suhosin-Patch This is perl, v5.10.0 built for x86_64-linux-gnu-thread-multi
> Module  = Catalyst::Runtime (MRAMBERG/Catalyst-Runtime-5.71000.tar.gz)

Are you running mod_deflate as well? There's a known bug in mod_fastcgi that 
causes exactly this kind of problem if mod_deflate is in front of it. It can 
be solved by disabling mod_deflate or ensuring that it won't process any 
content that mod_fastcgi serves, or by building and installing mod_fastcgi-
SNAP-0811090952.tar.gz

Andrew


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Accessing a Controller from ~/script

[Andrew Rodland]

On Monday 09 March 2009 12:54:34 pm Dermot wrote:
> 2009/2/19 Kieren Diment :
> > On 19/02/2009, at 11:58 PM, Dermot wrote:
> >> Wow! that works but I am not sure where ACCEPT_CONTEXT comes into it.
> >
> > That'd be if you needed to pass stuff from $c into the model to get it
> > working properly.
>
> I'd like to allow my stand alone model access to the configuration
> values contained in MyApp->config. It seems like the tidy way to do
> things. Does the ACCEPT_CONTEXT method allow me to do this? Is there
> some kinda SUPER way I can grab config and make an accessor of it?

Your Model has its own bit of config space, and this config info is passed to 
its constructor. The advisable thing to do here is to have your config there, 
and have your Model class pass that info along to your backend model class. 
If you need some more complex interaction then you can have more glue in your 
Model class (and ACCEPT_CONTEXT as necessary), but the goal here is not to 
influence your backend class. If the backend class depends on any class 
with 'Catalyst' in the name, or it depends on your app being around so it can 
rummage around in the config structure, then you can't really instantiate it 
outside of Catalyst, so what's the point of splitting it out? "Loose 
coupling" is the word.

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Base URI breakdown

[Andrew Rodland]

On Friday 06 March 2009 09:02:01 pm Trevor Phillips wrote:
> In a Catalyst app, I need to break down the base request URL to
> extract hostname, port, etc separately.
>
> I could do this with a regexp on $c->request->base, or I could use the
> URI perl lib, but is there already a way to access this within
> Catalyst?
>
> The docs say that $c->request->base is a string only, whereas I'd like
> to access separately bits like $c->request->base->host and
> $c->request->base->port.

$c->req->base is a URI object under all of the Engine types that I'm aware of. 
The docs don't promise this, but they don't say it's not either. Anyway 
there's no reason you couldn't do URI->new($c->req->base) which will be a 
perfectly good URI object whether base is a URI or an unblessed string. :)

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] catamoose now or when?

[Andrew Rodland]

On Wednesday 04 March 2009 07:52:56 pm Elliot Finley wrote:
> Hello,
>
>   I'm starting a new web app project that I need to deploy in about
> 2 months.  There will be ongoing updates to this app as time goes by.
> I'm new to catalyst/moose/dbic but a long time Perl hacker.
>
>   Considering the above, would I be better off starting with 5.71 or
> 5.8?

The 5.7 - 5.8 transition should require little to no rewriting of 
application-level code, so I'd suggest sticking with the released 5.7 for 
serious production. If you're inclined, though, and you have the resources, 
you could set up a box with 5.8000_06 in parallel for testing -- that would 
let you know about any hassles you might have upgrading in the future, as 
well as letting you contribute bug reports on 5.8 to avoid said hassles. :)

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Requirements for Catalyst

[Andrew Rodland]

On Saturday 21 February 2009 05:04:54 pm Jonathan Rockway wrote:
> * On Sat, Feb 21 2009, Octavian Râşniţă wrote:
> > Hello,
> >
> > It is very clear that a Catalyst app can't run on a shared host, but
> > it requires either a dedicated server or a VPS.
> > I am searching for web space providers that offer VPS and I've seen
> > that they use to set their tariff plans mainly on the guaranteed
> > memory, but I don't know which would be the necessary memory for a VPS
> > that runs an OS like Fedora or CentOS, Apache, Perl and Catalyst.
> >
> > Could be 256 MB of memory enough? Or 512? Or I would need 1 GB or more
> > if I would like to run a Catalyst app?
>
> We run lots of Catalyst apps on the smallest Linode.  I think they give
> us something like 340M of RAM.  This is enough.
>
> I use a 512M Slicehost for jrock.us, which runs my mail server and a few
> Catalyst applications.
>
> Anyway, nearly every VPS provider I know of lets you add more memory
> easily.  Buy the small one, and if you need more memory, upgrade.
>
Seconded. I run prod stuff for $WORK on Xen VMs with 512MB of RAM. Light-duty 
stuff should work well enough on 256MB and Linode's 360 deal is just about 
ideal. And any _good_ provider should let you instantly add more RAM with 
nothing more than a reboot, and prorate the bill appropriately, so growing 
shouldn't be a huge source of concern.

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] RFC: The paradox of choice in web development

[Andrew Rodland]

On Thursday 19 February 2009 09:12:36 am Matt Pitts wrote:
> In today's world of software that is cross-platform and OS agnostic at
> its core, Perl 5 is showing its age. Still love it though.
>

This isn't as much a Perl problem as it seems to be -- it's the rule all 
around that writing code that works on _everything but Windows_ is ten times 
easier than writing code that works on everything including Windows. Perl is 
just in a unique place to show this. In C, which is hardly more than a 
portable(-ish) layer on top of assembler, and which has a small standard 
library, code isn't portable at all without significant work (and even still, 
Windows is usually the hardest target to hit.) In Java, portability is 
considered paramount, so OS facilities are exposed through thick 
compatibility layers or else not at all. Perl sits in the middle ground. 
Sufficiently "pure perl" code will run on a million and one platforms, but at 
the same time Perl was never afraid to expose OS facilities (like stat or 
SysV IPC) more or less directly, to allow more powerful code. This has made 
it easy to write code that, even though it doesn't use XS as all, is 
platform-specific enough to crash and burn on windows. But if it's a 
shortcoming in Perl, how do we fix it? By taking all the goodies away from 
the Unix folks so everyone has to write to the least common denominator?

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] RFC: The paradox of choice in web development

[Andrew Rodland]

On Sunday 15 February 2009 03:04:04 am Dan Dascalescu wrote:
> > First:  Perl jobs are not decreasing.  While there is not a ton of 'Buzz'
> > around perl anymore... If you look at actual jobs stats:
> >
> > http://tiny.cc/kkcCM
> >
> > Perl is above all the others by some margin.
>
> Short version: that graph is misleading. Click the "Relative" link.
>
> Longer version: Yes, Perl is above the rest by some margin, thanks to its
> history. There are existing Perl applications that need to be maintained,
> and some momentum that keeps the demand for Perl jobs going. But click the
> "Relative" link in the graph, and see the percentage growth for Ruby jobs.
> It skyrockets when compared with both PHP and Perl.

Of course it does. Look at the "absolute" graph. The 2005 figure for Ruby is, 
to within the resolution of the graph, zero. It's not hard to have ten 
thousand percent growth from zero! The absolute graph would have you believe 
that the huge "threat" is from Ruby which has gone from zero to perhaps a 
quarter as big as perl, while the absolute graph makes it clear that the 
real "competition" is from the black line representing PHP. And yet if 
everyone were to abandon PHP tomorrow in favor of Perl it *still* wouldn't 
make a blip on the relative graph. Why? Because the relative graph is 
braindead.

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] DBIx makes Catalyst startup painfully slow

[Andrew Rodland]

On Tuesday 10 February 2009 04:53:32 am Neo [GC] wrote:
> Hello people,
>
> I'm working on a rather big CRM system using Catalyst with all bells and
> whistles. For database, we use DBIx::Class::Schema and this drives me
> crazy...
>
> Apart from Catalyst being really resource hungry, the startup time for
> the application (testserver oder fastcgi) is ok, about 4 seconds on my
> development-system (CentOS on VMware Fusion on MacOS X Leopard, Core 2
> Duo 2.2GHz). It's not perfect for developing, but it is completely
> acceptable.
> But as soon as I activate my DBIx schemas, the startup time multiplies:
> 12 seconds with my first (and most important) schema, 25 seconds when
> using all schemas. 

Just to be clear, since you mention startup time, are you using a fixed 
DBIx::Class::Schema, or DBIx::Class::Schema::Loader at runtime? If the 
latter, a slow startup is to be expected, and the solution is largely "don't 
do that then". If the former, then I suspect Nigel has you headed in the 
right direction.

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] template design issue: varibales stand-alone components

[Andrew Rodland]

On Wednesday 04 February 2009 05:25:41 pm Gene Selkov wrote:
> On Wed, 4 Feb 2009, J. Shirley wrote:
> > The Catalyst method is quite simple, since it tries to adhere to the
> > MVC design patterns.
> >
> > You would not set the variable in your templates, instead in the
> > controller.
> >
> > sub action_name : Local {
> >my ( $self, $c ) = @_;
> >   $c->stash->{surname} = $c->model('LDAP')->get_ldap_surname($id);
> > }
> >
> > Then your template gets 'surname' and you can just do:
> >
> > Hello <% $surname %>!
>
> I understood as much. The problem I am grappling with is the complexity of
> the web pages I have to present, with many different states and
> transitions. There is no way I can code for that with a single template.
>
There's no "single template" implied. By default you're probably going to have 
a template per-action, though that's completely up to you, and TT provides 
tools such as WRAPPER, INCLUDE, and BLOCK to let you organize and reuse your 
code. I'd suggest spending a little time with the Template::Manual as well as 
having a look at some real-life Catalyst apps.

Andrew



___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] [PATCH] [RFC] Seed the RNG in Catalyst::Engine::FastCGI

[Andrew Rodland]

On Tuesday 03 February 2009 11:45:07 am Jonathan Rockway wrote:
> * On Mon, Feb 02 2009, Andrew Rodland wrote:
> > I've thought over the problem and decided that the only appropriate place
> > for a fix is in Engine::FastCGI. A srand anyplace else (including the app
> > code) would run either too early (not solving the "shared state" problem)
> > or too late (re-seeding on every request is Bad.)
>
> Wait, is there a reason why we can't do this in FCGI::ProcManager
> instead?  This is something that affects everyone using FCGI, not just
> Catalyst.
>
A reasonable question. I'll see if I can get gbjk's thoughts on the matter.

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

[Catalyst] [PATCH] [RFC] Seed the RNG in Catalyst::Engine::FastCGI

[Andrew Rodland]

Due to the way FastCGI does its business, when running as an "external" 
FastCGI, the perl interpreter and the Catalyst app are initialized before the 
FCGI process manager does its forking. Since modern versions of Perl seed 
rand() "eagerly" on startup, this leads to all of the FastCGI children 
inheriting the same RNG state, and very nonrandom behavior (such as CAPTCHAs 
that appear to get "stuck").

I've thought over the problem and decided that the only appropriate place for 
a fix is in Engine::FastCGI. A srand anyplace else (including the app code) 
would run either too early (not solving the "shared state" problem) or too 
late (re-seeding on every request is Bad.)

Attached is a patch that does an srand in each child immediately after 
invoking pm_manage, if we are running our own process manager. I can't think 
at the moment how to write a test for it, but a behavior test shows that it 
completely solved the randomness problem on my end, and I ran an instrumented 
version to make sure that it's not srand'ing more than once per child -- it's 
not. Patch applies against Catalyst-Runtime/5.80/trunk and 
Catalyst-Runtime/5.70/trunk (with negligible fuzz).

Index: lib/Catalyst/Engine/FastCGI.pm
===
--- lib/Catalyst/Engine/FastCGI.pm  (revision 9173)
+++ lib/Catalyst/Engine/FastCGI.pm  (working copy)
@@ -130,6 +130,8 @@
 $self->daemon_detach() if $options->{detach};
 
 $proc_manager->pm_manage();
+# Give each child its own RNG state.
+srand;
 }
 elsif ( $options->{detach} ) {
 $self->daemon_detach();

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Re: Detach won't detach?

[Andrew Rodland]

On Tuesday 27 January 2009 05:33:46 pm Jonathan Rockway wrote:
> * On Tue, Jan 27 2009, pie3...@comcast.net wrote:
> > Why not
> >
> > sub auto :Private {
> > my $c = pop;
> > return user_logged_in || $c->res->redirect( ... );
> > }
>
> Because now the correctness of your application depends on undocumented
> behavior (the return value of $c->res->redirect).

|| 0 doesn't fix that any. Did you want && 0? :)

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Tool for rendering web pages consistently though time ?

[Andrew Rodland]

On Wednesday 21 January 2009 07:10:15 pm lanas wrote:
> That would be over two years.  This is for the making and updating of a
> user guide.  Currently the procedure is to take screenshots but then,
> it so happen that the original workstation witht he original resolution
> and fonts no longer exists, so the screenshots of the web pages are no
> longer exactly the same.  It'd be possible to dedicate a "do not touch"
> workstation for that purpose only but I'm looking for a more elegant
> solution which do not rely on any workstation hardware/resolution/fonts.
>

A unix box, Xvfb, firefox, a "page saver" extension, and a little automation? 
Then all the config details are under your control, and the "hands off" bit 
becomes less of a factor. Just a thought.

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] [Announce] Catalyst::Runtime 5.7099_04. IMPORTANT; PLEASE TEST!

[Andrew Rodland]

On Tuesday 13 January 2009 09:03:24 pm Oleg Kostyuk wrote:
> 2009/1/14 Andrew Rodland :
> > On Tuesday 13 January 2009 08:31:07 pm Greg Matheson wrote:
> >> On Tue, 13 Jan 2009, Oleg Kostyuk wrote:
> >> > 2) added ru and ua translations (see in attachment)
> >>
> >> So that's where those messages are!
> >> Here's some non-native Chinese and Japanese ones.
> >
> > I don't know if it was a mistake or a really subtle joke, but all
> > non-Latin text in your email was sent as question-marks.
>
> You mean my email also, or only email from Greg?

Yours was just fine (except it was mangled when Greg quoted it).

Andrew


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] [Announce] Catalyst::Runtime 5.7099_04. IMPORTANT; PLEASE TEST!

[Andrew Rodland]

On Tuesday 13 January 2009 08:31:07 pm Greg Matheson wrote:
> On Tue, 13 Jan 2009, Oleg Kostyuk wrote:
> > 2) added ru and ua translations (see in attachment)
> >
> So that's where those messages are!
> Here's some non-native Chinese and Japanese ones.

I don't know if it was a mistake or a really subtle joke, but all non-Latin 
text in your email was sent as question-marks.

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Catalyst modperl - child process segmentation fault

[Andrew Rodland]

On Tuesday 09 December 2008 12:05:13 am Terence Monteiro wrote:
> The only .so file I can find on libapache2-mod-php5 deb package is
> /usr/lib/apache2/modules/libphp5.so, but running ldd on it does not yield
> any mysql client libraries. The output is:


That's dynamically loaded too, sorry for misleading you. The relevant file, on 
debian, would appear to be /usr/lib/php5/*/mysql.so

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Catalyst modperl - child process segmentation fault

[Andrew Rodland]

On Monday 08 December 2008 02:20:38 am Terence Monteiro wrote:
> How can I find out the mysql client libraries DBD::mysql and mod_php are
> linked with? What you say is possible because I upgraded DBD::mysql from
> the latest debian sources in unstable, but not (yet) mod_php. But I don't
> understand why mod_php should matter.

(answering just this part)

because, assuming you use mod_php, and your PHP is built to support mysql (it 
almost always is), then PHP will be linked against libmysqlcient, and apache 
will link in mod_php at runtime, bringing in mysql by reference. Then your 
mod_perl app uses DBI, which also dlopens libmysqlclient, and hilarity 
ensues. To answer your question of "how?", I'd suggest ldd'ing the 
appropriate components -- mod_php.so and auto/DBD/mysql/mysql.so.

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Advent calendar

[Andrew Rodland]

On Monday 01 December 2008 07:22:48 pm Dan Dascalescu wrote:
> > And of course I forgot the URL: 
> > http://www.catalystframework.org/calendar
>
> I'd like to suggest hosting the Advent Calendar articles on the Catalyst
> Wiki: http://dev.catalyst.perl.org/wiki/adventcalendararticles

When you have a project with an internet presence, and you don't have time to 
do a proper job, you put up a wiki and hack it into doing what you want. When 
you have a bunch of web developers, and your project is web development, and 
you need something done that's really not wiki-ish at all, you _do it right_. 
If Advent sucks (yes, organization could be better, and markdown has its 
pros, as well as its cons that you seem to be ignoring), then help improve 
it. Schlepping it onto the wiki has its own set of problems, and isn't in 
itself a _solution_ to anything.

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] OT Apache question

[Andrew Rodland]

On Thursday 27 November 2008 08:45:16 pm Jesse Sheidlower wrote:
>
> However my document root is at /usr/local/www/data, which
> obviously does not include /usr/local/www/modules. So, if I
> try to follow the Static::Simple suggestion of adding, say,
>
> 
>   SetHandler default-handler
> 
>
> this obviously won't work because /Incomings/static isn't in
> fact under my document root, it's in the filesystem at
> /usr/local/www/modules/Incomings/root/static/. Trying this
> just gives me 404's for all of the static stuff (CSS, images,
> JS).
>
> How do I configure Apache to serve these files, without
> reorganizing what is by now a rather complicated directory
> structure?

Alias /incomings/static /yada/yada/root/static

SetHandler default-handler


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Making subrequests in views

[Andrew Rodland]

On Sunday 23 November 2008 03:29:11 am Alexander Tamm wrote:
> Hi,
>
> I'm pretty new to Catalyst and new to this mailing list. In other words,
> my apologies if this question has been frequently answered or if I've
> missed the relevant documentation.
>
> My basic setup is a Catalyst application running under FastCGI, using
> View::Mason for my views. I need to include a navigation component in
> most - not all - views, so I'm thinking about what strategy I should use
> to populate the stash with the correct data. As I see it, I have at
> least three options, but I'm not sure how smart they are.
>
> 1) I could always populate the stash in auto() and call the
> corresponding Mason component when needed. This means fetching some data
> even if it isn't needed.

This version, except that instead of doing it in auto, you do it in end or in 
an ActionClass, only when you know you're going to need it (that is, you're 
actually sending back a page that includes the menu, and not a redirect or a 
downloadable file or whatever else).

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: Off Topic: Re: [Catalyst] [Announce] MojoMojo 0.999021 has been released to CPAN

[Andrew Rodland]

On Sunday 02 November 2008 02:10:21 am Ali M. wrote:
> There is another project by Sebastien Riedel, and its called Mojo,
> just one Mojo.
>
> I think the people working on MojoMojo, should contact Sebastien and
> work out the naming thing, because it sometimes gets confusing
> following the news about either.
>
>

Get Jim Morrison in here too, while you're at it.

Andrew



___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Re: Feature Request: Parameter Junctions

[Andrew Rodland]

On Thursday 30 October 2008 03:23:40 am Oleg Kostyuk wrote:
> 2008/10/22 Aristotle Pagaltzis <[EMAIL PROTECTED]>:
> > I outlined a proposal a long time ago of two different methods
> > like the current `param`, one which always returned a single
> > value (the last one if there are multiple) and one which always
> > returned an arrayref. Then there could be no confusion and code
> > would always get exactly what it was written to expect. Matt
> > agreed but punted to volunteers, and none stepped up, me
> > included, so it has yet to happen.
>
> Could you please give link to your original thread ?

I think perhaps this was the thread -- 
http://thread.gmane.org/gmane.comp.web.catalyst.general/15862

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] PDF creation in Catalyst?

[Andrew Rodland]

On Wednesday 22 October 2008 01:08:45 pm Kirby Krueger wrote:
> Somewhat less snippishly, I've been trying to figure out the state of
> PDF generation from Catalyst.  I don't need to do anything super fancy
> - mostly get a report so it can print on paper that's perforated into
> thirds, without worrying about browsers, telling users how to turn off
> browser print header/footer lines, and the like.  I've seen several
> options:
>

Yeah, PDF generation is just unpleasant IMO, Catalyst or not. None of the 
tools available in Perl are high-level enough to make me happy. $WORK has a 
system using Apache FOP for report generation. It works, and the output is 
good, but creating the templates is a grind, and the code to invoke fop is 
ugly (and it's Java)... and that's the best thing I know of ;)

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] [PATCH] [RFC] Override base URI

[Andrew Rodland]

On Friday 10 October 2008 02:04:44 pm Andrew Rodland wrote:
> On Friday 10 October 2008 01:21:14 pm Jason Kuri wrote:
> > Great work.  I was looking into this yesterday.   I'm glad you beat me
> > to it. :-)
> >
> > To follow up on Tomas' comment - Why not make the override_base_uri /
> > override_base_uri_secure include the schema?  So if you want the URI's
> > to include https:// even if the request is coming in not-secure, you
> > can do that.
> >
> > Without this functionality it would be hard to do SSL accelerators and
> > such properly.
>
> I was trying to be clever and make it so that you only needed one config
> key in the case where your secure and nonsecure bases only differed in the
> scheme. I guess it was too clever. I'll go back and make them entirely
> separate -- it'll be less code anyway. :)

New version based on input from t0m and jayk and karpet.

 lib/Catalyst/Engine/CGI.pm |   23 +++--
 t/unit_engine_cgi.t|   86 +++
 2 files changed, 105 insertions(+), 4 deletions(-)

Andrew
Index: t/unit_engine_cgi.t
===
--- t/unit_engine_cgi.t	(revision 0)
+++ t/unit_engine_cgi.t	(revision 0)
@@ -0,0 +1,86 @@
+use strict;
+use warnings;
+
+use Test::More tests => 6;
+use URI;
+
+use_ok('Catalyst');
+
+my $http_request = Catalyst::Request->new( { secure => 0 } );
+my $https_request = Catalyst::Request->new( { secure => 1 } );
+
+$ENV{HTTP_HOST} = "127.0.0.1";
+$ENV{SERVER_PORT} = 80;
+$ENV{SCRIPT_NAME} = '/catalyst.fcgi';
+
+my $context = Catalyst->new( {
+request => $http_request,
+namespace => 'yada',
+  } );
+$context->setup_engine('CGI');
+$context->prepare_path;
+
+is (
+  Catalyst::uri_for( $context, '/pants' )->as_string,
+  'http://127.0.0.1/catalyst.fcgi/pants',
+  'Base URI'
+);
+
+$context = Catalyst->new( {
+request => $http_request,
+namespace => 'yada',
+  } );
+$context->config->{override_base_uri} = "http://127.1.2.3/";;
+$context->setup_engine('CGI');
+$context->prepare_path;
+
+is (
+  Catalyst::uri_for( $context, '/pants' )->as_string,
+  'http://127.1.2.3/pants',
+  'Overriden base URI'
+);
+
+$context = Catalyst->new( {
+request => $https_request,
+namespace => 'yada',
+  } );
+$context->config->{override_base_uri_secure} = "https://127.1.2.3/";;
+$context->setup_engine('CGI');
+$context->prepare_path;
+
+is (
+  Catalyst::uri_for( $context, '/pants' )->as_string,
+  'https://127.1.2.3/pants',
+  'Overriden base URI for HTTPS'
+);
+
+$context = Catalyst->new( {
+request => $http_request,
+namespace => 'yada',
+  } );
+$context->config->{override_base_uri} = "https://127.1.2.3/";;
+$context->setup_engine('CGI');
+$context->prepare_path;
+
+is (
+  Catalyst::uri_for( $context, '/pants' )->as_string,
+  'https://127.1.2.3/pants',
+  'Override nonsecure base URI to HTTPS'
+);
+
+$context = Catalyst->new( {
+request => $http_request,
+namespace => 'yada',
+  } );
+$context->config->{override_base_uri} = "dev.catalyst.perl.org";
+$context->setup_engine('CGI');
+eval {
+  $context->prepare_path;
+};
+
+like (
+  $@,
+  qr/Invalid/,
+  'Handle invalid override_base_uri'
+);
+  
Index: lib/Catalyst/Engine/CGI.pm
===
--- lib/Catalyst/Engine/CGI.pm	(revision 8518)
+++ lib/Catalyst/Engine/CGI.pm	(working copy)
@@ -160,12 +160,27 @@
 $c->request->uri( bless \$uri, $uri_class );
 
 # set the base URI
+
+my $base_uri;
+
+if (defined $c->config->{override_base_uri} && ! $c->request->secure) {
+  # Use an overridden base URI.
+  $base_uri = $c->config->{override_base_uri};
+} elsif (defined $c->config->{override_base_uri_secure} && $c->request->secure) {
+  # For HTTPS requests.
+  $base_uri = $c->config->{override_base_uri_secure};
+} else {
+  # Use the server-provided (default) base path.
+  $base_uri = $scheme . '://' . $host . $base_path;
+}
+
 # base must end in a slash
-$base_path .= '/' unless $base_path =~ m{/$};
+$base_uri .= '/' unless $base_uri =~ m{/$};
+# Ref. URI.pm
+$base_uri =~ /^([A-Za-z][A-Za-z0-9.+-]*):/ or die "Invalid base URI";
+my $base_scheme = $1;
 
-my $base_uri = $scheme . '://' . $host . $base_path;
-
-$c->request->base( bless \$base_uri, $uri_class );
+$c->request->base( bless \$base_uri, "URI::$base_scheme" );
 }
 
 =head2 $self->prepare_query_parameters($c)
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] [PATCH] [RFC] Override base URI

[Andrew Rodland]

On Friday 10 October 2008 01:21:14 pm Jason Kuri wrote:
> Great work.  I was looking into this yesterday.   I'm glad you beat me
> to it. :-)
>
> To follow up on Tomas' comment - Why not make the override_base_uri /
> override_base_uri_secure include the schema?  So if you want the URI's
> to include https:// even if the request is coming in not-secure, you
> can do that.
>
> Without this functionality it would be hard to do SSL accelerators and
> such properly.
>

I was trying to be clever and make it so that you only needed one config key 
in the case where your secure and nonsecure bases only differed in the 
scheme. I guess it was too clever. I'll go back and make them entirely 
separate -- it'll be less code anyway. :)

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

[Catalyst] [PATCH] [RFC] Override base URI

[Andrew Rodland]

 I've put something like that in a sub prepare before now
 we should maybe have a config option to override base
 patches would be welcome :)

Here's an attempt. I've never really hacked on the core before, so please go 
easy. Also I know that POD isn't included, but that's because I can't figure 
out where it belongs. I'll write it, given a place to put it.

Anyway, this is a patch to create a pair of config keys tell 
Engine::CGI "ignore what the server thinks the base path is, and use these 
instead". It's useful in the case that someone has their application 
port-forwarded, load-balanced, proxied, etc. through some sort of device that 
doesn't set X-Forwarded-Host.

How it works: If no config is provided, life continues as it always has. If 
the request is HTTP and $c->config->{override_base_uri} is set, we use that 
as $c->req->base. If the request is HTTPS and 
$c->config->{override_base_uri_secure} is set, we use that as $c->req->base. 
If the request is HTTPS and override_base_uri_secure isn't set, but 
override_base_uri is, we use override_base_uri and switch its scheme to https 
(hopefully it doesn't have a port).

Patch against Catalyst-Runtime/5.80/trunk which I hope is the right thing.

Comments appreciated,
Andrew
Index: t/unit_engine_cgi.t
===
--- t/unit_engine_cgi.t	(revision 0)
+++ t/unit_engine_cgi.t	(revision 0)
@@ -0,0 +1,71 @@
+use strict;
+use warnings;
+
+use Test::More tests => 5;
+use URI;
+
+use_ok('Catalyst');
+
+my $http_request = Catalyst::Request->new( { secure => 0 } );
+my $https_request = Catalyst::Request->new( { secure => 1 } );
+
+$ENV{HTTP_HOST} = "127.0.0.1";
+$ENV{SERVER_PORT} = 80;
+$ENV{SCRIPT_NAME} = '/catalyst.fcgi';
+
+my $context = Catalyst->new( {
+request => $http_request,
+namespace => 'yada',
+  } );
+$context->setup_engine('CGI');
+$context->prepare_path;
+
+is (
+  Catalyst::uri_for( $context, '/pants' )->as_string,
+  'http://127.0.0.1/catalyst.fcgi/pants',
+  'Base URI'
+);
+
+$context = Catalyst->new( {
+request => $http_request,
+namespace => 'yada',
+  } );
+$context->config->{override_base_uri} = "http://127.1.2.3/";;
+$context->setup_engine('CGI');
+$context->prepare_path;
+
+is (
+  Catalyst::uri_for( $context, '/pants' )->as_string,
+  'http://127.1.2.3/pants',
+  'Overriden base URI'
+);
+
+$context = Catalyst->new( {
+request => $https_request,
+namespace => 'yada',
+  } );
+$context->config->{override_base_uri} = "http://127.1.2.3/";;
+$context->setup_engine('CGI');
+$context->prepare_path;
+
+is (
+  Catalyst::uri_for( $context, '/pants' )->as_string,
+  'https://127.1.2.3/pants',
+  'Overriden base URI for HTTPS'
+);
+
+$context = Catalyst->new( {
+request => $https_request,
+namespace => 'yada',
+  } );
+$context->config->{override_base_uri} = "http://127.1.2.3/";;
+$context->config->{override_base_uri_secure} = "https://127.1.2.4/";;
+$context->setup_engine('CGI');
+$context->prepare_path;
+
+is (
+  Catalyst::uri_for( $context, '/pants' )->as_string,
+  'https://127.1.2.4/pants',
+  'Overriden base URI for HTTPS'
+);
+
Index: lib/Catalyst/Engine/CGI.pm
===
--- lib/Catalyst/Engine/CGI.pm	(revision 8518)
+++ lib/Catalyst/Engine/CGI.pm	(working copy)
@@ -160,11 +160,25 @@
 $c->request->uri( bless \$uri, $uri_class );
 
 # set the base URI
+
+my $base_uri;
+
+if (defined $c->config->{override_base_uri_secure} && $c->request->secure) {
+  # Config gives us an override base for HTTPS. Use it directly.
+  $base_uri = $c->config->{override_base_uri_secure};
+} elsif (defined $c->config->{override_base_uri}) {
+  # Use an overriden base. If we're secure, but there's no separate HTTPS
+  # base URI, then just change the scheme on the standard one.
+  $base_uri = $c->config->{override_base_uri};
+  $base_uri =~ s,^([^:]+)://,${scheme}://,;
+} else {
+  # Use the server-provided (default) base path.
+  $base_uri = $scheme . '://' . $host . $base_path;
+}
+
 # base must end in a slash
-$base_path .= '/' unless $base_path =~ m{/$};
+$base_uri .= '/' unless $base_uri =~ m{/$};
 
-my $base_uri = $scheme . '://' . $host . $base_path;
-
 $c->request->base( bless \$base_uri, $uri_class );
 }
 
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Success stories please

[Andrew Rodland]

On Sunday 05 October 2008 06:16:57 pm Mark Keating wrote:
> On 6 Oct 2008, at 00:01, J. Shirley wrote:
> > Andy apparently just wanted to start a flamewar.  This "article" is
> > idiotic, the reasons more so.  I'm disappointed in perlbuzz in general
> > as it now holds the same amount of respect as getting my news from The
> > National Inquirer.
> >
> > I'd encourage people to rather blog about finding the article to be in
> > poor taste, then post their success stories.  Commenting here or on
> > that blog entry is going to be buried.
>
> ++ to this

Thirdeded. The best cure for Andy is to ignore him.

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Multiple DB, single instance of Cat

[Andrew Rodland]

On Thursday 11 September 2008 05:58:31 pm Nigel Stuckey wrote:
> Matt
>
> I stand corrected on DBIx! Yes, indeed I mean DBIx::Class.
>
> The code is in and works, but has a couple of issues. Firstly, it
> creates new classes and carries out a DB connect every time there is
> a request. Is there a way to make it more efficient by caching the
> classes and DB connects once there is a successful authentication?
>
If you know what all of the possible "organizations" are, then write a model 
that instantiates all the DB connections (schemas, whatever) at 'new' time, 
then returns the appropriate one at ACCEPT_CONTEXT time. It's the "here's one 
we prepared earlier" approach. If that's not feasible, it should be obvious 
how to change it to doing nothing at startup, creating connections on demand, 
and "caching" them for the life of the process.

Andrew


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Apache2::RequestIO::read problem

[Andrew Rodland]

On Tuesday 29 July 2008 12:07:31 am Chris Dolan wrote:
> [error] Caught exception in engine "Apache2::RequestIO::read: (104)
> Connection reset by peer at /home/foo/perl/lib/perl5/site_perl/5.8.8/
> Catalyst/Engine/Apache.pm line 187"
> [Mon Jul 28 16:14:36 2008] [error] [client xxx.xxx.xxx.xxx] File does
> not exist: /home/foo/MyApp/root/student, referer: http://example.com/
> student
> [snip]
> I'm seeing the problem with URLs other than just /
> student too, but all of these problems are infrequent and only after
> reset connections.  I have not been able to reproduce the problem
> with my own web browser.

I've seen more-or-less the same thing using C::P::Server::XMLRPC when it gets 
some data it really doesn't like. I don't understand it any more than you do 
but it seems harmless enough. As Bill Moseley said it seems that something is 
failing in a way that makes apache retry with the default-handler. Makes no 
sense to me, but it does fit hte bill.

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] process stand alone css file with TT?

[Andrew Rodland]

On Thursday 24 July 2008 03:11:26 pm Kyle Godbold wrote:
> Is there any way to use Template Toolkit to render a stand alone
> css page that can be linked in with  ? I've
> tried rendering it through its own function and it will render the
> css but the output isn't recognized and used by any page when its linked.
> I'm not sure if its the header thats sent or the fact that it has no .css
> extention in the filename when its downloaded.
>
> sub style :Local {
> my ( $self, $c ) = @_;
> $c->stash->{template} = "style.css"; }

$c->res->content_type('text/css'); perhaps?

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Users hierarchy

[Andrew Rodland]

On Friday 06 June 2008 10:46:53 pm Jonathan Rockway wrote:
> * On Fri, Jun 06 2008, [EMAIL PROTECTED] wrote:
> > Gulp, that should have been 0 :)
>
> Actually, it should have been "!" as in "if(!$found ...)".  Perl has a
> variety of "false" values including 0, undef, and the empty string.
> Perl's built-in boolean operators return "undef" or "1" as false or
> true, but other libraries use other values ("" and "hey, it worked!",
> for example).

Actually (0==1) is "" and defined, while we're picking nits. The point stands 
that if you want to test for truth you should simply test for truth.

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/