Re: [Catalyst] Bug in old Advent example of async/websockets code?
It's worth noting that when I started stashing the $hd variable into
somewhere, I started getting a connection holding open.
However, attempts to CLOSE the websocket now seemed to hang on the
browser side, and were unreported on the server side.
Code follows:
has 'clients' => (
is => 'rw',
default => sub { +{} },
);
sub ws : Path('/ws') {
my ($self, $c) = @_;
$c->stash->{is_websocket} = 1;
my $io = $c->req->io_fh;
my $hs = Protocol::WebSocket::Handshake::Server->new_from_psgi($c->req->env);
$hs->parse($io);
my $hd = AnyEvent::Handle->new(fh => $io);
$self->clients->{$hd} = 1;
$hd->push_write($hs->to_string);
$hd->push_write($hs->build_frame(buffer => "Echo Initiated")->to_bytes);
my $error_cb = sub {
my ($handle, $fatal, $message) = @_;
if (defined $message) {
warn "ws error: $message\n";
}
delete $self->clients->{$handle};
return;
};
$hd->on_eof($error_cb);
$hd->on_error($error_cb);
$hd->on_read(sub {
(my $frame = $hs->build_frame)->append($_[0]->rbuf);
while (my $msg = $frame->next) {
warn "ws: frame contained: $msg\n";
$hd->push_write($hs->build_frame(buffer => "Hello $msg")->to_bytes);
}
});
}
On 23 February 2015 at 12:08, Toby Corkindale wrote:
> Hi,
> I've been trying to replicate the use of WebSockets in Catalyst, by
> following the example from the Advent calendar a year and a bit ago.
> ie.
> https://github.com/perl-catalyst/2013-Advent-Staging/blob/master/Websocket-Echo/lib/MyApp/Controller/Root.pm
>
> In my experience, it isn't actually working properly -- I get the
> "Echo Initiated" message, but then an instant disconnect.
>
> Looking at the code, I'm highly suspicious of the $hd variable -- it
> doesn't get stored anywhere, and according to the AnyEvent docs, I
> think that means it will get DESTROYed once it goes out of scope. ie.
> Immediately.
>
> That fits the behaviour I'm seeing, although I think I've had it work
> for me randomly at times as well, so... I don't know.
>
> I wondered if anyone here has thoughts on the matter?
>
> Cheers,
> Toby
--
Turning and turning in the widening gyre
The falcon cannot hear the falconer
Things fall apart; the center cannot hold
Mere anarchy is loosed upon the world
___
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] Bug in old Advent example of async/websockets code?
Hi, I've been trying to replicate the use of WebSockets in Catalyst, by following the example from the Advent calendar a year and a bit ago. ie. https://github.com/perl-catalyst/2013-Advent-Staging/blob/master/Websocket-Echo/lib/MyApp/Controller/Root.pm In my experience, it isn't actually working properly -- I get the "Echo Initiated" message, but then an instant disconnect. Looking at the code, I'm highly suspicious of the $hd variable -- it doesn't get stored anywhere, and according to the AnyEvent docs, I think that means it will get DESTROYed once it goes out of scope. ie. Immediately. That fits the behaviour I'm seeing, although I think I've had it work for me randomly at times as well, so... I don't know. I wondered if anyone here has thoughts on the matter? Cheers, Toby ___ 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] Providing a REST API from behind Apache/FastCGI?
On 9 November 2013 07:54, Dan Lowe wrote: > When I move this from dev to test, which means it goes behind mod_fastcgi, it > stops working. Every request gets back 401 Unauthorized. As far as I can > tell, the Authorization header is not being passed through to Catalyst. > > Has anyone had this problem and knows of some solution? I'm out of ideas at > this point... I know this isn't very helpful, but have you tried switching to using apache (or preferably nginx) to reverse-proxy through to starman, rather than using FastCGI? I think that's the current "best practice" and would prove more reliable. At the very least, it provides more ways to inspect and debug what is going on. If you're out of ideas, it might be quicker to just give up on fastcgi and move on. ___ 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] Mocking PSGI layers in Test WWW Mechanize Catalyst
On 2 November 2013 02:39, John Napiorkowski wrote: > Catalyst::Test uses Plack::Test under the hood. That mangle_response stuff > is mostly evil :) > > Sounds like you are saying you'd like to apply Plack Middleware during > testing. The latest dev release on CPAN lets you configure middleware via > configuration, so you could have some middleware in your test configuration. > This use case is one of the reasons I added this feature, so that we could > manage middleware for catalyst inside of catalyst configuration. That's correct -- I'd like to apply some plack middleware, which is a mocked-up-for-testing version of some middleware we run in production. Since the app now depends upon it, being able to specify it in the catalyst config would be fine. > If you don't like that approach, I could be talked into a patch to > Catalyst::Test that would let you declare additional middleware in the test > case. > > I'd prefer this over messing with Catalyst::Test internals. One of the hard > things about trying to move Catalyst forward is that we've expose a ton of > API that we fear to change since we don't know who is overriding what in the > Darkpan. Ideally I'd like to see people use Plack Middleware for jobs > involving modifying the request and response, since that is something its > great at, and the API is just a code ref, so its very well decoupled (could > even be used outside of Catalyst). Thanks John. I'll keep an eye out for the new release! (but will be hacking up something nasty and temporary until then so I can get some unit tests passing again..) Cheers, Toby ___ 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] Mocking PSGI layers in Test WWW Mechanize Catalyst
On 1 November 2013 12:29, Kieren Diment wrote: > On 01/11/2013, at 12:26 PM, Toby Corkindale wrote: >> On 1 November 2013 12:01, Kieren Diment wrote: >>> You mean you want two apps interacting with each other in the same script >>> using WWW::MEchanize? Eden and I were working some docs up on that topic >>> until real life intervened. >>> >>> This was the start of it: >>> >>> http://paste.scsys.co.uk/273844 >> >> Not exactly -- in this case I have a PSGI layer that is supposed to >> inject some extra information into the env for consumption by the >> application. >> >> A simple example would be if you had a PSGI layer providing, say, >> Basic HTTP auth, and setting the REMOTE_USER variable. >> Although in my case, there's a bit more to it than that. >> >> T > > Does the paste set you in the right direction? It's helpful for showing how to build a test-www-mechanize-psgi :) -- Turning and turning in the widening gyre The falcon cannot hear the falconer Things fall apart; the center cannot hold Mere anarchy is loosed upon the world ___ 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] Mocking PSGI layers in Test WWW Mechanize Catalyst
On 1 November 2013 12:01, Kieren Diment wrote: > You mean you want two apps interacting with each other in the same script > using WWW::MEchanize? Eden and I were working some docs up on that topic > until real life intervened. > > This was the start of it: > > http://paste.scsys.co.uk/273844 Not exactly -- in this case I have a PSGI layer that is supposed to inject some extra information into the env for consumption by the application. A simple example would be if you had a PSGI layer providing, say, Basic HTTP auth, and setting the REMOTE_USER variable. Although in my case, there's a bit more to it than that. T > On 01/11/2013, at 11:39 AM, Toby Corkindale wrote: > >> Umm, not that I know of. >> >> I suppose another way to phrase the question is: Is there a way to >> manipulate the $c->engine->env in the Catalyst application, from >> within unit tests neatly? >> >> On 1 November 2013 08:35, John Napiorkowski wrote: >>> Not sure what you mean, is there an example in another framework you can >>> point to? >>> >>> johnn >>> >>> >>> On Thursday, October 31, 2013 12:55 AM, Toby Corkindale >>> wrote: >>> Hi, >>> I wondered if there's any prior art around on inserting (mocked) PSGI >>> layers into Test::WWW::Mechanize:Catalyst? >>> >>> Cheers, >>> Toby >>> >>> -- >>> Turning and turning in the widening gyre >>> The falcon cannot hear the falconer >>> Things fall apart; the center cannot hold >>> Mere anarchy is loosed upon the world >>> >>> ___ >>> 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/ >>> >> >> >> >> -- >> Turning and turning in the widening gyre >> The falcon cannot hear the falconer >> Things fall apart; the center cannot hold >> Mere anarchy is loosed upon the world >> >> ___ >> 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/ -- Turning and turning in the widening gyre The falcon cannot hear the falconer Things fall apart; the center cannot hold Mere anarchy is loosed upon the world ___ 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] Mocking PSGI layers in Test WWW Mechanize Catalyst
It looks like there is an undocumented feature in Catalyst::Test, a
callback to let you modify the request.
$args->{mangle_request}->($request) if $args->{mangle_request};
Or alternatively I can subclass the module and extend
_customize_request() to add more to the PSGI environment.
On 1 November 2013 11:39, Toby Corkindale wrote:
> Umm, not that I know of.
>
> I suppose another way to phrase the question is: Is there a way to
> manipulate the $c->engine->env in the Catalyst application, from
> within unit tests neatly?
>
> On 1 November 2013 08:35, John Napiorkowski wrote:
>> Not sure what you mean, is there an example in another framework you can
>> point to?
>>
>> johnn
>>
>>
>> On Thursday, October 31, 2013 12:55 AM, Toby Corkindale
>> wrote:
>> Hi,
>> I wondered if there's any prior art around on inserting (mocked) PSGI
>> layers into Test::WWW::Mechanize:Catalyst?
>>
>> Cheers,
>> Toby
>>
>> --
>> Turning and turning in the widening gyre
>> The falcon cannot hear the falconer
>> Things fall apart; the center cannot hold
>> Mere anarchy is loosed upon the world
>>
>> ___
>> 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/
>>
>
>
>
> --
> Turning and turning in the widening gyre
> The falcon cannot hear the falconer
> Things fall apart; the center cannot hold
> Mere anarchy is loosed upon the world
--
Turning and turning in the widening gyre
The falcon cannot hear the falconer
Things fall apart; the center cannot hold
Mere anarchy is loosed upon the world
___
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] Mocking PSGI layers in Test WWW Mechanize Catalyst
Umm, not that I know of. I suppose another way to phrase the question is: Is there a way to manipulate the $c->engine->env in the Catalyst application, from within unit tests neatly? On 1 November 2013 08:35, John Napiorkowski wrote: > Not sure what you mean, is there an example in another framework you can > point to? > > johnn > > > On Thursday, October 31, 2013 12:55 AM, Toby Corkindale > wrote: > Hi, > I wondered if there's any prior art around on inserting (mocked) PSGI > layers into Test::WWW::Mechanize:Catalyst? > > Cheers, > Toby > > -- > Turning and turning in the widening gyre > The falcon cannot hear the falconer > Things fall apart; the center cannot hold > Mere anarchy is loosed upon the world > > ___ > 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/ > -- Turning and turning in the widening gyre The falcon cannot hear the falconer Things fall apart; the center cannot hold Mere anarchy is loosed upon the world ___ 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] Mocking PSGI layers in Test WWW Mechanize Catalyst
Hi, I wondered if there's any prior art around on inserting (mocked) PSGI layers into Test::WWW::Mechanize:Catalyst? Cheers, Toby -- Turning and turning in the widening gyre The falcon cannot hear the falconer Things fall apart; the center cannot hold Mere anarchy is loosed upon the world ___ 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] Stupid error with C::Authentication
On 27 August 2013 02:07, Alex Povolotsky wrote:
> In a quite simple application
[snip]
> I get
>
> [error] Caught exception in Admin::Controller::Root->index "Can't use string
> ("Catalyst::Authentication::Store:"...) as a HASH ref while "strict refs" in
> use at accessor Catalyst::Authentication::Store::DBIx::Class::User::_user
> (defined at
> /usr/local/lib/perl5/site_perl/5.14/Catalyst/Authentication/Store/DBIx/Class/User.pm
> line 12) line 5, line 1003."
>
> My password class has nothing to get wrong, and replacing it with default
> C::A::Credential::Password does not change anything
Hi Alex,
I've seen this particular error come up (with exactly that message)
when the user running the application was not able to connect to the
database successfully.
I don't know why that would vary depending on you using perl -d or
just perl though, but I thought I'd mention it.
-Toby
___
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] /Depreci?ate/ message
I noticed that the recent Catalyst release has added a Depreciation warning to the Regex class. Are you sure you meant depreciate? I think old features are normally deprecated. Cheers, Toby -- Turning and turning in the widening gyre The falcon cannot hear the falconer Things fall apart; the center cannot hold Mere anarchy is loosed upon the world ___ 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] Progress bar
I meant to follow this up, a long time ago. Just to say: I ported my app to use an HTML5-based upload progress thingy. I wrote it from scratch, it's made of awesome, haven't looked back. (Except to the poor suckers on Internet Explorer who, despite finally getting to version 8 or 9, still can't use it!) On 24 October 2012 15:33, Toby Corkindale wrote: > I was just investigating why the upload progress bar was broken on one > of my apps.. came here to make a post and discovered this thread. > Well, at least that's the first question answered! > > Given the caveats around Starman and WebKit browsers, are there any > other suggestions for how to do upload progress indicators? > Is this something we can do via HTML5 neater? Are there any > open-source Flash implementations? > > Cheers, > Toby > > On 22 October 2012 09:42, Bill Moseley wrote: >> >> On Sat, Oct 20, 2012 at 1:51 PM, Tomas Doran wrote: >>> >>> And UploadProgress is shipped, should be available once it's reindexed >>> (permissions cock up), which should be shortly :) >> >> >> So, when running under Starman the uploads are buffered before chunked to >> Catalyst, which means the progress bar data isn't updated until the upload >> has completed. This renders the upload progress bar pretty useless with >> Starman. >> >> The progress bar works fine running the app under mod_perl. >> >> I suppose using something like Nginx or Perlbal in front of the app would >> work (because those do cache uploads but also provide a hook for reading >> upload progress). But, we already have hardware load balancers in front of >> the app, so don't really need an extra proxy in front of every web server. >> >> Any other options? Using a upload/request caching proxy is probably THE >> correct answer since don't really want to tie up the app with slow uploads. >> >> I guess I should test, but I wonder if there's a limit on what Starman will >> buffer -- I assume it's buffering in memory. >> >> >> >> >> -- >> Bill Moseley >> mose...@hank.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/ >> > > > > -- > Turning and turning in the widening gyre > The falcon cannot hear the falconer > Things fall apart; the center cannot hold > Mere anarchy is loosed upon the world -- Turning and turning in the widening gyre The falcon cannot hear the falconer Things fall apart; the center cannot hold Mere anarchy is loosed upon the world ___ 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] Moose's make_immutable in Catalyst classes
Hi,
In modern Catalyst apps, we tend to create packages like this with Moose:
package MyApp::Controller::Foo;
use Moose;
use namespace::autoclean;
BEGIN { extends 'Catalyst::Controller'; }
...
1;
I was just wondering.. should we be adding Moose's make_immutable call
to the end of these classes?
ie. __PACKAGE__->meta->make_immutable;
Cheers,
Toby
--
Turning and turning in the widening gyre
The falcon cannot hear the falconer
Things fall apart; the center cannot hold
Mere anarchy is loosed upon the world
___
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] Progress bar
I was just investigating why the upload progress bar was broken on one of my apps.. came here to make a post and discovered this thread. Well, at least that's the first question answered! Given the caveats around Starman and WebKit browsers, are there any other suggestions for how to do upload progress indicators? Is this something we can do via HTML5 neater? Are there any open-source Flash implementations? Cheers, Toby On 22 October 2012 09:42, Bill Moseley wrote: > > On Sat, Oct 20, 2012 at 1:51 PM, Tomas Doran wrote: >> >> And UploadProgress is shipped, should be available once it's reindexed >> (permissions cock up), which should be shortly :) > > > So, when running under Starman the uploads are buffered before chunked to > Catalyst, which means the progress bar data isn't updated until the upload > has completed. This renders the upload progress bar pretty useless with > Starman. > > The progress bar works fine running the app under mod_perl. > > I suppose using something like Nginx or Perlbal in front of the app would > work (because those do cache uploads but also provide a hook for reading > upload progress). But, we already have hardware load balancers in front of > the app, so don't really need an extra proxy in front of every web server. > > Any other options? Using a upload/request caching proxy is probably THE > correct answer since don't really want to tie up the app with slow uploads. > > I guess I should test, but I wonder if there's a limit on what Starman will > buffer -- I assume it's buffering in memory. > > > > > -- > Bill Moseley > mose...@hank.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/ > -- Turning and turning in the widening gyre The falcon cannot hear the falconer Things fall apart; the center cannot hold Mere anarchy is loosed upon the world ___ 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 5.9007 / memcache /high cpu
Ah, I don't know then. Was just going to say that Cache::Memcached uses AnyEvent under the hood, and maybe that was interfering with apache's event loop if you were using that model. On 17 February 2012 12:48, Todd Benge wrote: > We're using PreFork. > > Sent from my iPhone > > On Feb 16, 2012, at 6:29 PM, Toby Corkindale wrote: > >> On 17 February 2012 11:16, Todd Benge wrote: >>> Hi, >>> >>> We recently updated our web servers to Catalyst 5.9007 with Perl 5.12. >>> >>> After the upgrade, we've consistently seen very high cpu on the machines > >>> 90%. After much looking, it appears that the apache threads are stuck in >>> Cache::Memcached disconnecting. >> >> Which Apache model are you using? Prefork, worker threads, events? >> >> ___ >> 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/ -- Turning and turning in the widening gyre The falcon cannot hear the falconer Things fall apart; the center cannot hold Mere anarchy is loosed upon the world ___ 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 5.9007 / memcache /high cpu
On 17 February 2012 11:16, Todd Benge wrote: > Hi, > > We recently updated our web servers to Catalyst 5.9007 with Perl 5.12. > > After the upgrade, we've consistently seen very high cpu on the machines > > 90%. After much looking, it appears that the apache threads are stuck in > Cache::Memcached disconnecting. Which Apache model are you using? Prefork, worker threads, events? ___ 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] Re: Accesing PSGI 'env' from in a controller
Answering my own question here..
Stuff was hidden in:
$c->engine->env->{...};
I know this isn't very portable, but it's for an internal app where
being able to pass some extra info through from the plack middleware
will be very helpfu.
I'm curious though - How would you suggest such stuff is handled?
cheers,
Toby
On 21 October 2011 17:11, Toby Corkindale wrote:
> Hi,
>
> Is there a way to access values set in the PSGI "env" store, once
> you're operating inside a catalyst controller method?
>
> Catalyst::Engine::PSGI looks like it is passing the $env variable
> along, but I haven't worked out how to access it.
> I thought $c->request->env would do the trick, but that method (->env)
> doesn't exist.
>
> Any hints? Or is this something I should be leaving alone? ;)
>
> Cheers,
> Toby
>
>
> --
> Turning and turning in the widening gyre
> The falcon cannot hear the falconer
> Things fall apart; the center cannot hold
> Mere anarchy is loosed upon the world
>
--
Turning and turning in the widening gyre
The falcon cannot hear the falconer
Things fall apart; the center cannot hold
Mere anarchy is loosed upon the world
___
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] Accesing PSGI 'env' from in a controller
Hi, Is there a way to access values set in the PSGI "env" store, once you're operating inside a catalyst controller method? Catalyst::Engine::PSGI looks like it is passing the $env variable along, but I haven't worked out how to access it. I thought $c->request->env would do the trick, but that method (->env) doesn't exist. Any hints? Or is this something I should be leaving alone? ;) Cheers, Toby -- Turning and turning in the widening gyre The falcon cannot hear the falconer Things fall apart; the center cannot hold Mere anarchy is loosed upon the world ___ 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: Recommended caching back-ends
On 7 October 2011 18:22, Stephen Clouse wrote: > On Fri, Oct 7, 2011 at 12:05 AM, Toby Corkindale wrote: >> >> Is there a Plugin::CHI or a CHI driver for Plugin::Cache anywhere? > > CHI works fine with C::P::Cache out of the box, nothing extra required. > > Just specify class => 'CHI' in the backend config and pass CHI configuration > as documented. Oh! Right. Thanks. Out of interest, how was I supposed to know I could do that? I thought I needed to pick modules which had existing catalyst::plugin::cache::store::X modules. (where X is the backend name) cheers, Toby -- Turning and turning in the widening gyre The falcon cannot hear the falconer Things fall apart; the center cannot hold Mere anarchy is loosed upon the world ___ 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] Re: Recommended caching back-ends
Is there a Plugin::CHI or a CHI driver for Plugin::Cache anywhere? On 7 October 2011 12:52, Toby Corkindale wrote: > Hey all, > I noticed today that Catalyst::Plugin::Cache::FastMmap has been > DEPRECATED for some now. (With dire warnings about it segfaulting or > discarding data randomly) > > I just wondered what the recommended caching backend is now, to use > with Catalyst::Plugin::Cache. > > (In my case, cached data doesn't need to be consistent between app > servers.. it's more just for performance so simple local-disk is fine > for caching, rather than memcached or database based solutions.) > > Cheers, > Toby > > -- > Turning and turning in the widening gyre > The falcon cannot hear the falconer > Things fall apart; the center cannot hold > Mere anarchy is loosed upon the world > -- Turning and turning in the widening gyre The falcon cannot hear the falconer Things fall apart; the center cannot hold Mere anarchy is loosed upon the world ___ 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] Recommended caching back-ends
Hey all, I noticed today that Catalyst::Plugin::Cache::FastMmap has been DEPRECATED for some now. (With dire warnings about it segfaulting or discarding data randomly) I just wondered what the recommended caching backend is now, to use with Catalyst::Plugin::Cache. (In my case, cached data doesn't need to be consistent between app servers.. it's more just for performance so simple local-disk is fine for caching, rather than memcached or database based solutions.) Cheers, Toby -- Turning and turning in the widening gyre The falcon cannot hear the falconer Things fall apart; the center cannot hold Mere anarchy is loosed upon the world ___ 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] Git conversions
On 17 May 2011 12:41, fREW Schmidt wrote: > Hey guys, > > So I've converted all of the DBIC repos from bast (our svn repo) that will > see new dev, and I got most of the Catalyst-Authentication modules > converted, as t0m had said he'd appreciate it. If you'd like to see the > converted repos take a look at github.com/frioux. That is not their > permanent home, just where I can keep them till people agree that I didn't > miss anything w/ the history. > > Now, I'd go ahead and just convert the rest of the repos in the Catalyst > svn, but first off, I don't really know what's likely to get more dev and > second, I don't want to offend people by moving their projects from > underneath them. > > So, if you are interested in having your repo converted, I am totally > willing to do it. All I need from you is an email saying you are interested > and I need to you be willing to check the converted repo to ensure that it's > good. I've gotten to the point that I can usually find missing merges, > correctly recreate tags, etc, but I'm not perfect and I'm not taking the > blame if you miss it :-) For what it's worth, some of the trouble can be saved by using something like svn2git: https://github.com/nirvdrum/svn2git Cheers, Toby ___ 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] Allow Expires and Cache-control headers in Static::Simple
On 1 February 2011 23:28, Tomas Doran wrote:
> On 1 Feb 2011, at 02:17, Toby Corkindale wrote:
>> I'd like to see it as an option on Static::Simple; I could mod that
>> and send a patch over if you liked?
>
> Sure, or just commit into a branch (you already have a commit bit, right)?
I cannot for the life of me remember my auth details, sorry :(
(Or perhaps I just don't have a commit bit on that module)
Have sent separate email regarding them.
Regardless, here is the patch..
---
Changes |4
lib/Catalyst/Plugin/Static/Simple.pm | 32 +---
2 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/Changes b/Changes
index aea5423..71d2367 100644
--- a/Changes
+++ b/Changes
@@ -1,5 +1,9 @@
Revision history for Perl extension Catalyst::Plugin::Static::Simple
+0.30 2011-02-xx hh:mm:00
+- Add Cache-Control:public header
+- Optionally provide Expires header
+
0.29 2010-02-01 18:45:00
- Switch from override to around, because really, wtf
diff --git a/lib/Catalyst/Plugin/Static/Simple.pm
b/lib/Catalyst/Plugin/Static/Simple.pm
index ca3412c..91cef4a 100644
--- a/lib/Catalyst/Plugin/Static/Simple.pm
+++ b/lib/Catalyst/Plugin/Static/Simple.pm
@@ -8,7 +8,7 @@ use MIME::Types ();
use MooseX::Types::Moose qw/ArrayRef Str/;
use namespace::autoclean;
-our $VERSION = '0.29';
+our $VERSION = '0.30';
has _static_file => ( is => 'rw' );
has _static_debug_message => ( is => 'rw', isa => ArrayRef[Str] );
@@ -172,6 +172,7 @@ sub _locate_static_file {
sub _serve_static {
my $c = shift;
+my $config = $c->config->{static} ||= {};
my $full_path = shift || $c->_static_file;
my $type = $c->_ext_to_type( $full_path );
@@ -180,6 +181,12 @@ sub _serve_static {
$c->res->headers->content_type( $type );
$c->res->headers->content_length( $stat->size );
$c->res->headers->last_modified( $stat->mtime );
+# Tell Firefox & friends its OK to cache, even over SSL:
+$c->res->headers->header('Cache-control' => 'public');
+# Optionally, set a fixed expiry time:
+if ($config->{expires}) {
+$c->res->headers->expires(time() + $config->{expires});
+}
my $fh = IO::File->new( $full_path, 'r' );
if ( defined $fh ) {
@@ -307,7 +314,7 @@ the operation by adding various configuration
options. In a production
environment, you will probably want to use your webserver to deliver
static content; for an example see L, below.
-=head1 DEFAULT BEHAVIOR
+=head1 DEFAULT BEHAVIOUR
By default, Static::Simple will deliver all files having extensions
(that is, bits of text following a period (C<.>)), I files
@@ -450,6 +457,23 @@ module, you may enter your own extension to MIME
type mapping.
},
);
+=head2 Controlling caching with Expires header
+
+The files served by Static::Simple will have a Last-Modified header set,
+which allows some browsers to cache them for a while. However if you want
+to explicitly set an Expires header, such as to allow proxies to cache your
+static content, then you can do so by setting the "expires" config option.
+
+The value indicates the number of seconds after access time to allow caching.
+So a value of zero really means "don't cache at all", and any higher values
+will keep the file around for that long.
+
+MyApp->config(
+static => {
+expires => 3600, # Caching allowed for one hour.
+},
+);
+
=head2 Compatibility with other plugins
Since version 0.12, Static::Simple plays nice with other plugins. It no
@@ -572,6 +596,8 @@ Justin Wheeler (dnm)
Matt S Trout,
+Toby Corkindale,
+
=head1 THANKS
The authors of Catalyst::Plugin::Static:
@@ -586,7 +612,7 @@ For the include_path code from Template Toolkit:
=head1 COPYRIGHT
-Copyright (c) 2005 - 2009
+Copyright (c) 2005 - 2011
the Catalyst::Plugin::Static::Simple L and L
as listed above.
--
1.7.3.5
___
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
On 2 February 2011 13:43, Andrew Rodland wrote: > 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. Which neatly loops around to my original post! :D My suggestion being to continue to use Static::Simple, but with cache-related headers added so that the reverse-proxy in front of Starman will cache-and-serve them itself. It's simple, and IMHO, ends up as the fastest, most light-weight way to serve those static files too. -T -- Turning and turning in the widening gyre The falcon cannot hear the falconer Things fall apart; the center cannot hold Mere anarchy is loosed upon the world ___ 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
On 2 February 2011 00:08, Aristotle Pagaltzis wrote: > * Toby Corkindale [2011-02-01 03:25]: >> The case that I find having the headers enabled is as follows: >> >> Front end load-balancing proxies, talking to app servers >> running starman, running catalyst apps. >> If you use Static::Simple, this does make the pipeline >> configuration nice and simple. >> I like simplicity. >> If you enable caching on your static content, then your >> reverse-proxies at the front will cache things, and take the >> load of static content off Catalyst at the back. >> >> I'd like to see it as an option on Static::Simple; I could mod >> that and send a patch over if you liked? > > You may be interested in my setup: > http://blogs.perl.org/users/aristotle/2011/01/some-nifty-things-you-can-do-with-catalyst-on-plack.html Thanks - that's a really good example setup. 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? I might have to borrow the bit about auto-extending expiry times for versioned static files :) cheers, Toby ___ 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] Opinions on static::simple - with caching
On 31 January 2011 19:04, Tomas Doran wrote: > On 31 Jan 2011, at 07:17, Toby Corkindale wrote: > >> However, I suppose in situations where that matters, you shouldn't be >> serving files via Static::Simple.. >> And the regular Static::Simple still provides Last-Modified headers, >> which do allow browsers to perform some caching. >> >> What do you think? > > Pretty much that - Static::Simple is really meant for development only, and > in such a situation, you really want to not serve cache headers, as you > don't want things cached when you're developing. > > That said, this isn't the first time someone has suggested this recently, so > maybe it's worth just adding as an option in Static::Simple directly (with > suitable warnings about production use in the documentation). The case that I find having the headers enabled is as follows: Front end load-balancing proxies, talking to app servers running starman, running catalyst apps. If you use Static::Simple, this does make the pipeline configuration nice and simple. I like simplicity. If you enable caching on your static content, then your reverse-proxies at the front will cache things, and take the load of static content off Catalyst at the back. I'd like to see it as an option on Static::Simple; I could mod that and send a patch over if you liked? Toby ___ 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] Opinions on static::simple - with caching
I'm wondering if the following plugin I've written is misguided..
It enables proxy caches and browsers to better cache the files served
by Static::Simple..
However, I suppose in situations where that matters, you shouldn't be
serving files via Static::Simple..
And the regular Static::Simple still provides Last-Modified headers,
which do allow browsers to perform some caching.
What do you think?
To enable this plugin, you need:
use Catalyst qw(
...
Static::Simple
Static::Caching
);
-Caching.pm--
package Catalyst::Plugin::Static::Caching;
use Moose::Role;
requires '_serve_static'; # From Catalyst::Plugin::Static::Simple
after _serve_static => sub {
my $c = shift;
# Avoid setting an expires if the parent never found the file..
return unless (defined $c->response->body
and ref($c->response->body) eq 'IO::File');
# Tell browsers they can cache files for a couple of hours:
$c->res->headers->expires(time() + 7200);
# Tell Firefox it's OK to cache, even over SSL:
$c->res->headers->header('Cache-control' => 'public');
};
1;
___
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] FormHandler -- pro or con?
On 13 December 2010 21:07, Octavian Rasnita wrote:
> From: "Toby Corkindale"
>
> On 9 December 2010 19:24, Octavian Rasnita wrote:
>>> Using Moose Roles for forms is awesome.
>>
>> I also agree with this idea, but the fact that the most used constraints,
>> filters and validators should be also manually specified using Perl code is
>> not so nice.
>> It would be nice to have a form processor like H::FF that provides many
>> default HTML elements, constraints, filters and validators, and to be able
>> to create custom elements, constraints, filters and validators using Moose
>> roles, then to specify that those roles are used... using config files.
>
>> But.. That's what the custom fields, widgets, roles etc are there for.
>> Eg. If you need a field that can, say, only accept four characters and
>> they have to be a-d, then go in and make a custom field type that does
>> the check.. Then tell your designers to just say "type =>
>> 'mySpecialField'" when they need to use it.
>>
>> Or even better, develop entire classes of grouped widgets and their
>> validations, then get them to just incorporate those.
>> (Eg. an "Address" role, which brings in street, suburb, borough,
>> state, postcode, zip code, whatever.. and does all the validation..
>> You'll reuse that one a lot!)
>
>
> Yes, I wasn't very clear. The most important part is not the one that allow
> creating custom fields, constraints or filters, but the one that talks about
> using pre-defined very common fields.
> For example, if I just want to validate an email address, or some numbers, or
> other simple things like these, I don't want to write any kind of code if
> with H::FF I can just write a short code in a configuration file.
> It is more simple to write
>
>
> type Email
>
>
> ...than to write Perl code and apply a Moose role to a certain field.
It's not that hard, it's just:
has_field 'email_address'=> ( type => 'Email' );
>> Actually, I guess that is possible to create them using Moose with H::FF
>> although I am not sure.
>>
>> Ideally, the web designers that don't know Perl at all should be able to
>> change the design of the forms at least.
>
>> Agreed, and this is where neither FormFu or FormHandler succeeds.
>
> True, but for simple layouts, H::FF requires less effort for coding.
> I became interested in H::FH for using it in the case of more complex forms,
> especially after I heard that it is faster than H::FF, but it is not
> acceptable at all to use html code as strings in Perl code.
>
> The development version of H::FF also uses Moose, so only the fact that H::FH
> uses moose is not a relevant advantage.
>
>
>> FormFu's yaml syntax ends up being horribly complicated, and
>> FormHandler's Perl code is not much clearer.
>
>
> True, but FormFu can also use Config::General code which is much clearer (or
> other config formats accepted by Config::Any).
>
> It would be OK if H::FH would allow creating custom elements and validators,
> filters... using Moose, but only generic elements, not related with any form,
> and then allow us to use configuration files for using those elements and
> constraints. It is not nice at all to need writing Perl code using Moose for
> just creating an HTML form, but each one with his preferences. :-)
But you can do that if you want..
If you're just doing simple stuff, like name-of-field + type-of-field,
then you could do something like this:
my $form = HTML::FormHandler->new(
item => $c->model('DB::User')->find($id),
field_list => YAML::Load("form.yaml")
);
Where form.yaml looks a bit like:
---
username:
- type: Text
- required: 1
email_address:
- type: Email
- required: 1
favourite_colour:
- type: Select
- options:
- blue
- red
- green
- orange
- yellow
___
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] FormHandler -- pro or con?
On 9 December 2010 19:24, Octavian Rasnita wrote: >> Using Moose Roles for forms is awesome. > > I also agree with this idea, but the fact that the most used constraints, > filters and validators should be also manually specified using Perl code is > not so nice. > It would be nice to have a form processor like H::FF that provides many > default HTML elements, constraints, filters and validators, and to be able to > create custom elements, constraints, filters and validators using Moose > roles, then to specify that those roles are used... using config files. But.. That's what the custom fields, widgets, roles etc are there for. Eg. If you need a field that can, say, only accept four characters and they have to be a-d, then go in and make a custom field type that does the check.. Then tell your designers to just say "type => 'mySpecialField'" when they need to use it. Or even better, develop entire classes of grouped widgets and their validations, then get them to just incorporate those. (Eg. an "Address" role, which brings in street, suburb, borough, state, postcode, zip code, whatever.. and does all the validation.. You'll reuse that one a lot!) > Actually, I guess that is possible to create them using Moose with H::FF > although I am not sure. > > Ideally, the web designers that don't know Perl at all should be able to > change the design of the forms at least. Agreed, and this is where neither FormFu or FormHandler succeeds. FormFu's yaml syntax ends up being horribly complicated, and FormHandler's Perl code is not much clearer. ___ 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] FormHandler -- pro or con?
On 7 December 2010 18:03, Octavian Rasnita wrote: > From: "Toby Corkindale" > >> On 1 December 2010 02:34, will trillich wrote: >>> Anybody else *dissing* FormHandler? We've started developing based on >>> FormHandler lately and haven't had troubles... yet? >> >> I'm running it, and have been very happy with it. >> It's nice that you can put all your common form elements into roles >> and then combine them. >> I'm familiar with Moose, so HFH's syntax came fairly naturally to me, >> but I guess it could be confusing to others? >> >> Performance is reasonable - and a lot faster compared to FormFu. >> >> Cheers, >> Toby > > > Is there a way of making H::FH beeing more elegant? > > I mean, is there a way of doing something to not need using Perl code for > creating the forms, but only using some configuration files like in H::FF's > case? I guess there is more than one way to do everything.. I didn't like having to write YAML for H:FF, since YAML is ugly, and then one needed to take multiple YAML files and merge them a lot, and.. ugh. Using Moose Roles for forms is awesome. But, that said, you could write your forms in some kind of DB or config file and load them up, but you miss out on the best bits of HFH that way. (I do have some code that programmatically generates the form config based on the object you're editting, although I use a precreated base for it) Toby ___ 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] Which Form Validation Libs?
On 30 November 2010 22:26, Shlomi Fish wrote: > On Tuesday 30 November 2010 11:31:56 David Schmidt wrote: >> another great module which from my perception is used the most lately is >> >> HTML::FormHandler >> http://search.cpan.org/~gshank/HTML-FormHandler-0.32005/ >> > > I can recommend *against* HTML-FormHandler. > > For my day job's Perl and Catalyst project, we initially decided to go with > HTML-FormHandler, only to discover it was buggy, quirky and had severe memory > leaks. We ended up doing many workarounds and recently made a transition from > it to HTML-FormFu, which while by no means perfect, is much saner. > > My co-worker "nothingmuch" who has done many of the workarounds can provide > further comments on it. Recently I had to over-ride a role in the login form > (for which we need to use HTML-FormHandler due to CatalystX::SimpleLogin) that > will accept an empty string as the 'action=""' attribute because it only > placed true values of the attribute there, which ruled out empty strings. But > I recall many other fun hours debugging HTML-FormHandler. I hit issues with FormHandler and HFH::Model::DBIC having issues with empty strings vs definedness too, but it was a few months ago. I submitted some patches that were accepted a few versions back and it's been pretty good for me since. The code is reasonably logical and easy to work with, I felt. By comparison, a major app I built on FormFu earlier in the year resulted in epic debugging and terribly complex and not-at-all-logical forms, and the problems seemed more deeply ingrained. (That was a medium version number at least ago.) They both have their weaknesses, but having used both, I definitely think HFH is the way to go at the moment. Both modules have good authors who are helpful and actively developing. Cheers, Toby ___ 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] FormHandler -- pro or con?
On 1 December 2010 02:34, will trillich wrote: > Anybody else *dissing* FormHandler? We've started developing based on > FormHandler lately and haven't had troubles... yet? I'm running it, and have been very happy with it. It's nice that you can put all your common form elements into roles and then combine them. I'm familiar with Moose, so HFH's syntax came fairly naturally to me, but I guess it could be confusing to others? Performance is reasonable - and a lot faster compared to FormFu. Cheers, Toby ___ 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] Running system commands under FastCGI with IPC::Cmd / IPC::Run
On 22 October 2010 05:43, Ian Sillitoe wrote: > I have a Catalyst model that runs a system command as part of a search > facility. The system call only takes a fraction of a second so is processed > inline and this all works fine when tested outside of Catalyst and when > called under the Catalyst standalone server. However, when I deploy it to my > FastCGI environment I have problems - everything seems to work fine apart > from the results of the system call. > > The system call is (give or take): > > IPC::Cmd::run( > command => [qw/ blastall -d sequences.db -i input.fa -o > output.results /], > verbose => 0, > timeout => 10, > ); I recall that IPC::Run certainly has known-issues when used under FastCGI, and I'm guessing they extend to IPC::Cmd too. Have a look at IPC::Run::SafeHandles which I think got around it. Toby ___ 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] Handling long-running processes (was Re: Logging is not immediate)
On 20/10/10 09:19, Chris wrote: I'm curious to know how other people approach this issue. Also, what do you think about the polling approach vs a (background) connection that stays connected waiting for the completion signal? I've found polling much simpler to implement (and test) as it doesn't require anything particularly special on either client or server-side. It means a bit more delay - the polling period - before the user gets the result, but for our use-case (generating reports and download files) this hasn't been an issue. I've seen some stuff suggesting that polling leads to higher server load, but again it hasn't been an issue in our low-traffic web-apps. I still haven't played with Comet-style server-push much. Anyone else using it? What is support like for either multi-part or partial-update in browsers like now? Although HTML5 will clean it all up, since it actually defines some proper transports. Then we just have to wait for HTML5 support to be prevalent! :) -Toby ___ 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] Handling long-running processes (was Re: Logging is not immediate)
On 19/10/10 11:05, Bill Moseley wrote: On Mon, Oct 18, 2010 at 4:46 PM, Ken Beal mailto:kb...@crosscountry-auto.com>> wrote: The issue is that when I call $c->log(), it doesn’t output anything until the “URL call” completes. This makes it difficult to watch a long-running process, because I don’t see anything until it’s done, and I don’t know if it’s hung up on something because I can’t see the log output. maybe try this: $c->log->_flush; Or try: warn "I'm stuck in a loop and the web user is wondering why I'm taking so long and will likely hit reload any second now!\n"; As a follow-up to Ken's message.. If you have long-running processes in a web server, then I suspect you are Doing It Wrong. (Or, naybe you're not, and have some kind of RPC system under Catalyst, in which case ignore what I'm about to say.) Can I suggest you look at a different model of serving these long-running things to the web users? Consider having them hit a page which says "Your request is being processed..", which then kicks off the actual work in another process, and returns a token of some sort to the user's browser. (eg. Cookie or URI parameter) You then have the browser either reload the page (including the token mentioned above), or better yet, use javascript to do it in the background. You have two options here - first option is for this request to get hung on the server, waiting for the process to complete, or you can have it return quickly with the status or progress info to display in the meantime. Once this background request detects the long-running process has completed, it then directs the browser to reload, and collects the final information. This has several advantages. 1) If the user keeps hitting reload, you can detect their work token, and avoid starting more long-running processes. 2) The user doesn't get stuck with a blank screen and a loading status bar. Instead they can get progress info, or at least a message saying "we're working on it, hang in there..." 3) You don't have your web server tied up with long-running processes, holding open sockets and using memory. 4) Logging for your long-running processes is independent of your web server messages. So the URLs the user would see would be something like: /report/megasize # server kicks off background process, redirects user onto.. /report/megasize?token=d11a1658f614401782e8 # which says "please wait while we prepare your report". # The user's browser waits for completion by polling: /report/progress.json?token=d11a1658f614401782e8 # ..and eventually reloads: /report/megasize?token=d11a1658f614401782e8 # which now displays the contents of their report at least, this is the way I think it should be done. I'm curious to know how other people approach this issue. Also, what do you think about the polling approach vs a (background) connection that stays connected waiting for the completion signal? Cheers, Toby ___ 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] Logging is not immediate
On 19/10/10 10:46, Ken Beal wrote: Hi, I’m running Catalyst via the scripts\myapp_server.pl script. I have never configured it to run under a web server, and perhaps that’s the answer to my question. The issue is that when I call $c->log(), it doesn’t output anything until the “URL call” completes. This makes it difficult to watch a long-running process, because I don’t see anything until it’s done, and I don’t know if it’s hung up on something because I can’t see the log output. Has anyone else experienced this, and found a useful workaround or fix? Like I said, if I have to run it under Apache or IIS in order for this to work, I’ll do so. Hi Ken, You will find the same behaviour when running under a web server. ie. Log messages are saved up and then emitted all at once at the end of the request. I'm pretty sure this is By Design in Catalyst's default logger. However there is nothing stopping you from installing a different logging module into $c->log. I've used a Syslog one in the past. Toby ___ 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 and FormBuilder vs. IExplorer 8
On 07/10/10 03:36, Moritz Onken wrote:
Sounds like a trailing comma in the javascript somewhere.
The trailing-comma problem occurs in IE6/7, but not in IE8. (Thank you,
Microsoft).
I think Will's problem *doesn't* occur on IE6/7, but just IE8, if I
understand the situation correctly:
>> On 06/10/10 14:00, will trillich wrote:
>> Short version: Catalyst/Formbuilder uploads work fine in firefox and
>> chrome, works fine in IE 6... but not IE 8, where it throws an
>> "object expected" error.
I looked around our code a bit, and our own "object expected" errors
here were being caused by some javascript assuming that a certain object
would always have an object returned from a method, when in fact
sometimes it didn't in older versions of IE :/
Not so helpful for you, if this issue only appears on recent IE versions
though.. confusing!
Will, can you check to see if you're getting Internet Explorer 8 running
in "IE8 standards mode", or if it's falling back to the older quirks
mode or IE7 mode?
Try this:
alert("Document mode = " + document.documentMode);
___
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 and FormBuilder vs. IExplorer 8
On 06/10/10 14:00, will trillich wrote:
Short version: Catalyst/Formbuilder uploads work fine in firefox and
chrome, works fine in IE 6... but not IE 8, where it throws an "object
expected" error.
Ugh, I hit this a little while ago, but have forgotten the details already.
I think you are looking in the right direction with the "this" though;
try validating it in your function to ensure it contains what you're
expecting perhaps?
Also, can you verify that jquery is actually getting loaded OK?
ie. In your document, put something like:
$(function() { alert("jquery has loaded!"); });
and check to see that you get an alert box when you load the page. If
not, fire up Chrome's developer tools, or Firefox's Firebug, and see
they mention any warnings or errors.
-Toby
___
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] Ann: Cat-Auth-Credential-YubiKey
Hi, I've created a Catalyst::Authentication module that supports Yubico's YubiKey system. It's uploaded to PAUSE, so should be hitting CPAN mirrors soon as Catalyst::Authentication::Credential::YubiKey Info on the YubiKeys is available at http::/yubico.com/ They're a USB key that provides one-time-passwords; you can either use Y's own webservice, or you can download and run your own system internally. Cheers, Toby ___ 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] Handling expired sessions gracefully
On 09/07/10 00:53, Steve wrote:
I've looked in the archives and tutorials but can't seem to find
examples of handling expired sessions gracefully. I'm admittedly weak in
the area of error checking, but I'm working on it :) Here are my questions:
In what controller (Root.pm or MyApp.pm) and action should I check for
an expired session? Should I check $c->user_exists or
$c->session_expired (not sure if I have the correct accessor)? Once
detected, do I forward, redirect, etc.?
How about something like this?
sub auto :Private { # or the head of your chain
my ($self, $c) = @_;
if (not $c->user_exists) {
$c->stash->{destination} = $c->request->path;
$c->detach('/login');
}
}
Then in your login method, redirect them back to {destination} if they
successfully authenticate; make sure to validate the path though, to
avoid exploits. (eg. Another site crafting a redirect link like
http://yoursite.com/login?destination=/confirm_payment/to/evil/hacker)
___
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 caching issue
On 07/07/10 07:35, Steve wrote: The reference to $cachetime was found on the Catalyst Wiki: http://wiki.catalystframework.org/wiki/adventcalendararticles/2007/11-making_your_catalyst_app_cache-friendly In that instance, it's a variable used in some example code - it only has any meaning within that example. If you're using that whole end() block, then cool, but just setting $cachetime=0; on its own won't do anything. The way you put it, it sounds like you're considering doing that. I'd say it shouldn't be your first concern; everyone else tends to have things like forms and pages work fine without needing to tweak that - browsers already have some smarts in them to try and avoid caching dynamic data. As of my last post, I had not implemented/acted on the $cachetime, but since then I've successfully set the http response header 'Cache-Control' to 'no-cache'. This has not solved the problem - Yes, I restarted my httpd server. At present, my cohort and I suspect that we are up against a database caching problem, but haven't completely ruled out anything. Am I better off asking the DBIC list? Well, you haven't told us a whole lot about what the problem is, so it's hard for us to agree or disagree with your diagnosis. I'm still a little confused/concerned by your comment that "my session seems to 'cross' over to other fastCGI processes"; it sounds a bit like you are misunderstanding what the session is *meant* to do, and thus, perhaps the problem lies there. Run your app with Debug mode enabled, and watch the logs - you will be able to see if you're hitting the app, or getting a cached copy. If you add some debug statements in your form handling, you can also see what data you're getting back from the database. You might also want to enable DBIC_TRACE in your environment, to get a /lot/ of SQL dumped out too. Best of luck, Toby Steve On 7/6/2010 4:23 PM, Tomas Doran wrote: On 6 Jul 2010, at 19:26, Steve wrote: however my session seems to 'cross' over to other fastCGI processes (I've got 3 fastCGI processes running). Yes, they'll do that. I've googled around and even tried to set $cachetime = 0 in my Root.pm controller's END action. Er, what is $cachetime? What are you expecting it to effect. Can anyone point me in the direction of a fix? If I've not provided enough background info let me know and I'll expand. Please expand. If you suspect code, please attach code. 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/
Re: [Catalyst] Contributing code
On 23/06/10 01:03, Tomas Doran wrote: On 22 Jun 2010, at 08:55, Toby Corkindale wrote: I think I asked about this last time (to great silence), but.. what's the correct base path for the Git repos there? ie. git clone http://git.shadowcat.co.uk//Catalyst-Devel.git Like the CPAN search page says, it is git://git.shadowcat.co.uk/catagits/Catalyst-Devel.git (from http://search.cpan.org/dist/Catalyst-Devel/) Cheers - can I suggest that URL is added to the Contributing Code wiki page that was originally linked in this email thread? ___ 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] Contributing code
On 22/06/10 00:19, Ævar Arnfjörð Bjarmason wrote: On Mon, Jun 21, 2010 at 13:48, Sir Robert Burbridge wrote: Out of a discussion last week, I have some code to contribute (largely to Catalyst::Helper). Two quick questions: 1) I've never contributed code to a project outside my work before. How do I go about it? Have you read http://wiki.catalystframework.org/wiki/contrib ? I think I asked about this last time (to great silence), but.. what's the correct base path for the Git repos there? ie. git clone http://git.shadowcat.co.uk//Catalyst-Devel.git ___ 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 Catalyst ?
On 29/04/10 19:06, Oleg Pronin wrote: Maybe it is not the bottleneck, but how many places do we have like this that are "not a bottleneck" ? maybe the sum of all these "mini" mistakes is the bottleneck ? Hi Oleg, Do you have an application which *has* a bottleneck at the moment? If so, can you demonstrate it? Quite a lot of people on this list are trying to tell you that Catalyst runs some very big sites quite successfully, and my own experience backs that up. Whenever I've hit a bottleneck in a site, it has turned out to be: * Database calls (usually with expensive queries) * Poorly designed TT templates * Stupid blocking calls in a controller (eg. sleep, system, waitpid, etc) * Network bandwidth But NOT the speed of accessor methods in Catalyst. They really are not an issue. If you *do* have a performance issue yourself, then please feel free to bring up a specific example, but otherwise, quit worrying. If you are concerned that you're not squeezing the absolute most performance out of every clock cycle on your CPU, then you should go back to coding in raw assembler instead of Perl, but it's not worth hassling us about. Cheers, Toby ___ 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: Alternatives to Catalyst ?
On 23/04/10 09:10, Lyle wrote: Aristotle Pagaltzis wrote: You should switch to PHP. PHP is pronounced "poop", and there is far too much poop on the web already. There's also too much noise and not enough signal on the mailing list. Can we all try and resist cheap shots, name-calling, me-too's and other childish behaviour on here? ___ 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] Distributing and updating Cat apps
On 09/04/10 23:11, Bill Moseley wrote: On Thu, Apr 1, 2010 at 12:51 AM, Toby Corkindale We package things up into Debian-style packages, and then upload those to a local repository of packages. Then servers can just be updated using the standard system tools (apt). Hi Toby, This is really the direction I'm heading now (although it's looking like CentOS and RPMs). Can you answer a few general questions? Are you using Template Toolkit? How (or really where) are the templates managed? Where do they get installed, how does the TT View know where to find them, etc? Do they end up in /usr/share// for example? Yes, I'm using Template Toolkit, although due to the apparently-unfixable crashes in the XS stash, I've also built some packaged with Template Alloy too. I just put my templates into the 'root' directory, as per the Catalyst standard layout. After installation, they end up under your distro's Perl directory, in site_perl or vendor_perl, under a 'root' directory in your Module's namespace. Eg. if you have MyApp.pm, then your templates end up in /site_perl/5.10.1/MyApp/root/ I'm sure you never have to roll-back a release, but I also assume you are prepared to roll-back if needed. How does that process work? If you're using the Debian tools, then you can specify a version number when giving a package to "upgrade", which can also be used to downgrade. (This requires you to configure your company's local .deb package repository to hang on to N many old versions; how many for N is up to you.) The debian tools seem really quite good at noticing if you've, say, made changes to the local configuration file for your app, but that there are also changes to it coming down in the new version, and it'll prompt you about this. It's worth noting that by default, the debian package tools will put your myapp.conf into site_perl/5.10.1/MyApp/ as well.. I dislike this, and so over-ride the debian/rules file to move it into /etc/ where it makes more sense. What about your static content (css, js, images)? Where do those get installed? As above, under site_perl; however you can override this in the debian/rules files to put it in /var/www/ or somesuch; I'm lazy and tend to just use Static::Simple; if you have a reverse proxy in front of your app (as you should if performance is a concern) then you can just cache the static stuff there instead. Any special tricks when using an app in "development" vs. production? (For example, under "dev" I use source css, js, but otherwise the app uses combined and compresses css and js. When in development, I run it on a different server altogether, and do not have it installed into the global perl path at all. And I run it with the "myapp/script/myapp_server.pl" rather than via a standalone webserver+appserver(+ optional proxy) stack. For your example, I would put the command to combine-and-compress the CSS and JS into the debian/rules file. However you need a staging server which mirrors the production environment and stack in order to properly test it prior to release. You have a choice of either packaging up every single Perl dependency into a Debian package too (which is a world of pain), or installing all your dependencies into a local directory that you ship with the application. I recommend the latter.. (you'll still need to include dependencies on things like the C libraries for your database client, etc though, in the debian control file.) We are doing a mix. But, for the most part we are creating single modules (packages). Mostly that was to encourage inclusions of unit tests and just more fine-grained management. But, it is more work, true. I disliked having to use the relatively primitive and time-consuming Debian/Gentoo/RedHat tools to manage CPAN modules, when CPANPLUS exists. Why use a plastic trowel when you have a pneumatic digger available? :) I should point out that this does then require keeping the entire installed Perl tree in source control though, so that one can tag exactly which modules were used (and bundled with) an application. Toby ___ 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"?
On 08/04/10 22:49, Daniel Pittman wrote: Toby Corkindale writes: On 08/04/10 16:21, Andrew Rodland wrote: * 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. I'd like to follow up that last point, regarding the DB being compromised. Is that definitely a requirement for the vulnerability? Unless you are passing the hashed passwords around as authentication tokens, yes. Plus, at that point you have already lost. I ask because, in many cases, if your DB is compromised, then the horse has already bolted. I understand that isn't the case for everyone, such as payment processors, online shops, etc. where actions can be carried out by logged in users that cause external effects.. but in some cases, the database IS the website, and if you've stolen it, then there's no point logging in as another user artificially. ...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?) From the app-dev perspective, though, you already lost. :) But, yes, it's still worth looking into fixing then I think. *nod* Unix did, decades back, for much the same reasons other people have given here. Daniel Although Unix had the problem that the /etc/passwd file was visible to all users on the machine, prior to the introduction of the shadowed version, and thus anyone could try and brute-force the password hashes. In most (all) websites today, the authentication database is not user-visible. ___ 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"?
On 08/04/10 16:21, Andrew Rodland wrote: * 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. I'd like to follow up that last point, regarding the DB being compromised. Is that definitely a requirement for the vulnerability? I ask because, in many cases, if your DB is compromised, then the horse has already bolted. I understand that isn't the case for everyone, such as payment processors, online shops, etc. where actions can be carried out by logged in users that cause external effects.. but in some cases, the database IS the website, and if you've stolen it, then there's no point logging in as another user artificially. But, yes, it's still worth looking into fixing then I think. ___ 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"?
So, a while back there was some.. slightly heated.. discussion about security issues with C-P-A-Password.. or perhaps one of the modules it uses internally.. in certain cases, if certain options are, or are not, set. Then it quietened down without any apparent conclusion being reached. Now that some time has passed, I wondered if someone could provide a synopsis of the outcome of these investigations and discussions? In short: * In what circumstances was an attack possible? ie. What combination of modules, options, auth methods. * Which versions were vulnerable, and if any, at what version were they fixed, if any? * What mitigating factors can be applied to existing systems to reduce their vulnerability to the attack? Thanks, Toby ___ 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] Distributing and updating Cat apps
On 30/03/10 19:32, Tomáš Znamenáček wrote: Hello! I have a Catalyst application that I would like to upload from the development box to the production server. Is there some kind of best practice to do that? My requirements: 1) The process should take care of the dependencies and run the tests before installing. (Let’s say the deps are declared in Makefile.PL or Build.PL.) 2) It would be nice to keep the application isolated in one directory so that I can keep several instances under the same account to do primitive staging. Right now I am updating the application using Git. I push from the development box to a headless repository on the production server and there is a hook that updates the working copy. This fails (1). I’ve read something about local::lib, but I’m still not sure about how to put things together. This has to be a common scenario, isn’t it? When you are finished updating the development version, what do you call to upload the update to the production server and what exactly happens along the way? We package things up into Debian-style packages, and then upload those to a local repository of packages. Then servers can just be updated using the standard system tools (apt). This works quite well. You have a choice of either packaging up every single Perl dependency into a Debian package too (which is a world of pain), or installing all your dependencies into a local directory that you ship with the application. I recommend the latter.. (you'll still need to include dependencies on things like the C libraries for your database client, etc though, in the debian control file.) ___ 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
On 02/03/10 17:07, 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? Also Apache CouchDB. I'm curious to know how these things work out for what I see as "real world" cases, where you do actually want to do searches on correlated data. For instance, say you wanted to make a phpbb-style forum. You have several forum areas, and within each there are many threads, each containing many posts. Would every post in a thread be a new document, or would the entire thread be one big document? How would they be linked to the forums, by an ID in the document, or do we get into some kind of mega-document encapsulating everything on the board? Say I wanted to do a search for all posts made by users named John in the forum called Linux, what would the syntax look like? cheers, Toby ___ 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] on the topic of PAR file distribution.
On 26/02/10 13:04, Tomas Doran wrote: On 26 Feb 2010, at 01:34, Toby Corkindale wrote: On 26/02/10 11:27, Tommy Butler wrote: What's the downside of this? How is this going to pose a problem for me? Installing from subversion and then CPANning all the required libs into the system via the makefile is terribly slow and error prone. There's an obvious negative there. What's the negative with using PAR when compared to this other method of deployment? [snip] Secondly, PAR is a nightmare. It's meant to automatically locate all your dependencies, but in practice this never finds all of them. Eg. Building a catalyst_par for a fastcgi-based app is broken out of the box. (It doesn't pick up Catalyst::ScriptRunner) Patches to require the appropriate modules in Catalyst.pm so that Catalyst does work out the box would be welcome. Is requiring the modules in Catalyst.pm the correct way to do this? I was thinking it'd be in Module::Install::Catalyst, with some automatically-added -M options to par. Speaking of M-I-C, is there a good reason why STDERR is redirected to /dev/null, as well as __WARN__? I ask, because it makes debugging catalyst_par builds a PITA.. I always go in and edit MIC to undo that stuff now, and can't see a good reason not to take it out. I tried to fix this (and made a branch which you'll find in our svn), but this just made PAR shit itself on my mac, and given I'm not a PAR user and nobody else was showing any interest, I gave up. If there is an active PAR user out there who would like to get this fixed - come chat to someone in #catalyst-dev, as that can totally happen. I'm trying to checkout the git repo, but despite following http://wiki.catalystframework.org/wiki/contrib I am getting an error when trying to clone http://git.shadowcat.co.uk/catagits/Catalyst-Devel.git Is the contrib page out of date perhaps? The gitweb still seems to work, but I can't clone from it. ta, Toby ___ 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] on the topic of PAR file distribution, why is it frowned upon?
On 26/02/10 11:27, Tommy Butler wrote: Hello all, I will be deploying a catalyst app onto several dozens of servers in the next months, which will probably turn into more than that eventually. It is a year in the making, and quite complex in terms of all the things it requires to run (libraries). Given that, a PAR distribution file seems like a great way to go. Yet my co-worker told me that this has been frowned on as of late-- that there has been a shift in opinion about deploying cat apps as PARs. What's the downside of this? How is this going to pose a problem for me? Installing from subversion and then CPANning all the required libs into the system via the makefile is terribly slow and error prone. There's an obvious negative there. What's the negative with using PAR when compared to this other method of deployment? The main problems are that PAR doesn't actually work very well. Firstly, it is severely broken on perl 5.10.0, so you'll either need to stick with perl 5.8.x or go to perl 5.10.1. (Or backport fixes from perl 5.10.1 to .0, but there lies insanity.) Secondly, PAR is a nightmare. It's meant to automatically locate all your dependencies, but in practice this never finds all of them. Eg. Building a catalyst_par for a fastcgi-based app is broken out of the box. (It doesn't pick up Catalyst::ScriptRunner) So you'll need to go through a long cycle of * build par * attempt to run it, and discover which modules are missing * add those modules to list of extras * Repeat. A lot. You'll also need to explicitly list all the /var/lib/* things you need, like libpq.so, libxml.so, etc as those aren't picked up.. and all their dependencies manually too. I really don't like deployment methods that are based on trial-and-error. It doesn't give me any confidence that we did manage to find all the extra modules to list as inclusions.. and so you can bet that there's one more missing, that won't be discovered until your app is crashing in production. So, there are some negatives for PAR. The question is, do they outweigh the negatives for using CPAN to install random, latest-and-possibly-broken packages via the Makefile every time? Some shops have a rule that you must only use the versions of modules that are available pre-packaged for the operating system. This gets around the problems of having to install everything by hand, and also means you get consistent versions of modules.. However it also means you're stuck with a small subset of CPAN, and usually very old versions as well. (For eg, Debian is still on Catalyst 5.7 I believe.) My own solution was a fourth option: Build your own Perl, and all the required modules, installed into a custom directory - and then ship this with your application. It'll blow the size out by a hundred meg or so, but at least you know it'll work, and it's using known-good versions of CPAN modules. -Toby ___ 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::Manual 5.8004
On 19/02/10 04:30, hkcl...@gmail.com wrote: Hi Everyone, Just wanted to let everyone know that I pushed an updated Catalyst Manual to CPAN yesterday. Almost all of the changes pertained to the tutorial. A big thanks to Caelum for doing most of the SQLite foreign key work. Also thanks to xenoterracide for a variety of edits to early chapters. "Full" set of changes listed below (with a summary of prior changes below that). Thank you, I really appreciate it when developers spend time improving documentation. So much that I'll say thanks twice. :) Thanks, Toby ___ 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
On 15/02/10 15:59, Steve Rippl wrote: Hi, I have a small Catalyst app, the production version of which has been running pretty well using the built in server as there haven't been too many user at once. I'm trying to anticipate higher concurrent usage and switch to FastCGI (as that seems to be recommended in the book) and I have the following running in Apache FastCgiServer /srv/WsdSis/script/wsdsis_fastcgi.pl -processes 5 Alias / /srv/WsdSis/script/wsdsis_fastcgi.pl/ ServerName sis.woodlandschools.org ServerAdmin webmas...@woodlandschool.org DocumentRoot /srv/WsdSis/root Alias /static /srv/WsdSis/root/static Now this works, it's serving up the application, but each request is really slow to complete! The obvious effect of this is that a page with JavaScript waiting for a complete page before it does it's thing looks dreadful for a while, the html has arrived but the browser is still spinning, then eventually the page completes and the JS runs. (I know about graceful failure for JS, but I have an app that is going to depend on it!). 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). This is running on a Debian 5 machine using libapache2-mod-fastcgi. You can get good performance out of catalyst by just running the PREFORK standalone server*, with a reverse-proxy cache sitting in front of it. (eg. Varnish http://varnish-cache.org/) [* http://search.cpan.org/dist/Catalyst-Engine-HTTP-Prefork/ ] I've never been satisfied by either of the FastCGI implementations available to Apache. I do like the one for Lighttpd, but some other aspects of lighty can be annoying. ___ 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] C-P-UploadProgress (converted away from NEXT)
Hey Andy, and general Catalyst guys.
Attached is a patch to convert Catalyst::Plugin::UploadProgress into
using Moose::Role instead of NEXT, since the latter is deprecated as of
Cat-Runtime .18.
Could you have a look over it? I'm not 100% sure the first function is
"good" since it's never calling super() from inside prepare_body_chunk.
But hey, that's just how the original code worked too..
Cheers,
Toby
>From 95e1d77a555dcc1caae2ab29cbbd843450e8e337 Mon Sep 17 00:00:00 2001
From: Toby Corkindale
Date: Thu, 21 Jan 2010 15:59:03 +1100
Subject: [PATCH] Remove NEXT, replace with Moose::Role
---
lib/Catalyst/Plugin/UploadProgress.pm | 32 +---
1 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/lib/Catalyst/Plugin/UploadProgress.pm b/lib/Catalyst/Plugin/UploadProgress.pm
index ee97eb3..c0910f3 100644
--- a/lib/Catalyst/Plugin/UploadProgress.pm
+++ b/lib/Catalyst/Plugin/UploadProgress.pm
@@ -2,11 +2,12 @@ package Catalyst::Plugin::UploadProgress;
use strict;
use warnings;
-use NEXT;
+use Moose::Role;
-our $VERSION = '0.04';
+our $VERSION = '0.10';
-sub prepare_body_chunk {
+# I'm concerned that this doesn't call super() at all..
+override 'prepare_body_chunk' => sub {
my ( $c, $chunk ) = @_;
my $body = $c->request->{_body};
@@ -33,9 +34,9 @@ sub prepare_body_chunk {
$c->cache->set( 'upload_progress_' . $id, $progress );
}
}
-}
+};
-sub prepare_body {
+override 'prepare_body' => sub {
my $c = shift;
# Detect if the user stopped the upload, prepare_body will die with an invalid
@@ -49,7 +50,7 @@ sub prepare_body {
$croaked = shift;
};
-$c->NEXT::prepare_body(@_);
+super;
}
if ( $croaked ) {
@@ -67,9 +68,9 @@ sub prepare_body {
# rethrow the error
Catalyst::Exception->throw( $croaked );
}
-}
+};
-sub dispatch {
+override 'dispatch' => sub {
my $c = shift;
# if the URI query string is ?progress_id= intercept the request
@@ -79,20 +80,18 @@ sub dispatch {
return $c->upload_progress_output( $1 );
}
-return $c->NEXT::ACTUAL::dispatch(@_);
-}
+return super;
+};
-sub setup {
+after 'setup' => sub {
my $c = shift;
-$c->NEXT::setup(@_);
-
unless ( $c->can('cache') ) {
Catalyst::Exception->throw(
message => 'UploadProgress requires a cache plugin.'
);
}
-}
+};
sub upload_progress {
my ( $c, $upload_id ) = @_;
@@ -279,6 +278,9 @@ JSON output from C.
Andy Grundman,
+NEXT to Moose::Role conversion by Toby Corkindale, , blame him
+for any faults there..
+
=head1 THANKS
The authors of L, for the progress.js and
@@ -292,4 +294,4 @@ progress.css code:
This program is free software, you can redistribute it and/or modify it under
the same terms as Perl itself.
-=cut
\ No newline at end of file
+=cut
--
1.6.6
___
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] Enabling debug mode with fastcgi..
On 19/01/10 21:45, Tomas Doran wrote:
On 19 Jan 2010, at 00:26, Toby Corkindale wrote:
As I said, I've tried the -e (same as -keeperr) options in combination
with the *_DEBUG environment variables.
That should (and does) work here..
Hmm. That's interesting to know.. I swear it isn't working on the
machines I was testing this on the other day. Many things are old on
them, so maybe it's something in a fastcgi library or other.
I'll investigate some more.
(The front-end apache servers aren't logging any catalyst debug output
anywhere; possibly this is a config error there, or possibly
intentional on the part of sysadmins - however either way it's not
something I'm about to change.)
Yeah, that's got to be config of some sort, Catalyst does log down the
fcgi socket by default..
For what it's worth, or anyone reading this in the archives in the
future - this is still on Catalyst Runtime 5.8.16.
(.17 was busted, .18 doesn't work out of the box in our environment
due to some of the changes and so isn't
considered production ready by us just yet.)
I don't see a bug report for this anywhere? Did I miss it?
"make catalyst_par" doesn't produce a working PAR, as the
Catalyst::ScriptRunner modules is not included inside the PAR.
Introduced in 5.8.17. Reported 15 Dec 2009.
Temporary fix is to add to Makefile.PL:
catalyst_par_classes('Catalyst::ScriptRunner');
catalyst_par_classes('Catalyst::Script::FastCGI');
..etc..
but of course if you do that, the package will fail to build on older
pre-version-17 setups, and I didn't really want to get into the
Makefile.PL complexity of optionally including them based on revisions
of modules..
Cheers,
Toby
___
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] Enabling debug mode with fastcgi..
On 19/01/10 06:54, Adam Mackler wrote: Hi Toby: The output might be going to your web server log. Try starting your fastcgi script with a -e option (with CATALYST_DEBUG set as well). Looking at the previous posts that Wallace directed me to, it sounds like the debug options with fastcgi have been a little broken for some time now.. As I said, I've tried the -e (same as -keeperr) options in combination with the *_DEBUG environment variables. I have a vague recollection of having this trouble before, and resorting to overriding Catalyst::Log to send things to syslog or a standalone log file. (The front-end apache servers aren't logging any catalyst debug output anywhere; possibly this is a config error there, or possibly intentional on the part of sysadmins - however either way it's not something I'm about to change.) Hmm, thanks for looking guys. For what it's worth, or anyone reading this in the archives in the future - this is still on Catalyst Runtime 5.8.16. (.17 was busted, .18 doesn't work out of the box in our environment due to some of the changes and so isn't considered production ready by us just yet.) So I'm not sure if the new Cat ScriptRunner code will have fixed the issue there. cheers, Toby. On Mon, Jan 18, 2010 at 05:03:23PM +1100, Toby Corkindale wrote: Hi guys, If you're running a Catalyst app with the fastcgi script (as found in scripts/myapp_name_fastcgi.pl), then is there a way to enable the debug mode. (eg. like running scripts/myapp_server.pl -d) I've tried setting CATALYST_DEBUG and MYAPP_DEBUG in the shell environment, but that doesn't seem to work. Either that or else fastcgi is discarding the output somewhere in our case. (I've messed with the -keeperr option too) Cheers, Toby ___ 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] Enabling debug mode with fastcgi..
Hi guys, If you're running a Catalyst app with the fastcgi script (as found in scripts/myapp_name_fastcgi.pl), then is there a way to enable the debug mode. (eg. like running scripts/myapp_server.pl -d) I've tried setting CATALYST_DEBUG and MYAPP_DEBUG in the shell environment, but that doesn't seem to work. Either that or else fastcgi is discarding the output somewhere in our case. (I've messed with the -keeperr option too) Cheers, Toby ___ 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::View::JSON sends a file
Tomas Doran wrote: On 11 Jan 2010, at 23:29, Christoph Friedrich wrote: just worked a little with Catalyst::View::JSON. But when I call some action via Firefox that uses this View Firefox gives me a file to download and don't show the json directly. Is there a way to change this behavior? I want to see what I would get as JSON and not download it ^^ Your browser will do whatever it normally does with the mime type you're sending. By changing settings or mime types you'll probably be able to convince it to display the JSON. You could also adjust the $c->response->content_type() to be 'text/plain'. But watch out, as some javascript libraries decide what to do with the response based on it's content-type, and will not JSON-decode what it thinks is html or plain text. However, why not write a JSON debug view that pretty prints JSON responses inside an HTML page? Definitely the better option. Or learn to get into the Firefox or Chrome javascript debuggers.. well worth having that skill. Toby ___ 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.80017
Has anyone else had trouble getting this installed, due to the dependency on Class::MOP 0.97? I can't get class mop to install in my local lib - keeps dying with: Not a HASH reference at /usr/share/perl/5.10/ExtUtils/Install.pm line 557. make: *** [pure_site_install] Error 2 I'll report back on whether the "make catalyst_par" bug from 5.8.16 is still present once I get it installed.. ta, Toby Florian Ragwitz wrote: I'm happy to announce the next release of Catalyst-Runtime (5.80017). This release mainly cures all issues reported with upgraded scripts (or applications generated with the latest release of Catalyst::Devel) and makes Catalyst compatible with upcomming versions of Moose. This release also started being more strict about the deprecated usage of NEXT. We're not surpressing any Class::C3::Adopt::NEXT warnings anymore. See the changelog for details. Full changelog included below as always. Cheers rafl -- 5.80017 2010-01-10 02:27:29 Documentation: - Fix docs for ->forward method when passed a class name - this should be a component name (e.g. View::HTML, not a full class name, like MyApp::View::HTML). Bug fixes: - --daemon and -d options to Catalyst::Script::FastCGI are fixed. - Fix the debug dump for applications which use Catalyst::Plugin::Session (RT#52898) - Fix regression in the case where mod_rewrite is being used to rewrite requests into a path below your application base introduced with the %2F related fixes in 5.80014_02. - Do not crash on SIGHUP if Catalyst::Engine::HTTP->run is not passed the argv key in the options hash. - Correctly pass the arguments to Catalyst::Script::Server through to Catalyst::Engine::HTTP->run so that the server can restart itself with the correct options on SIGHUP. - Require new MooseX::MethodAttributes to be compatible with Moose versions >= 0.93_01 - Require new MooseX::Role::WithOverloading to be compatible with Moose versions >= 0.93_01 Cleanups: - Stop suppressing warnings from Class::C3::Adopt::NEXT now that most plugins have been updated to not use NEXT. If you get warnings then please upgrade your components or log a bug with the component author if an upgrade is not available. The Class::C3::Adopt::NEXT documentation contains information about how to suppress the warnings in your application if you need to. ___ 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/ -- Strategic Data Pty Ltd Ph: 03 9340 9000 ___ 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] Catalyst::Script::FastCGI ignores --daemon option (internally it is --detach)
As of Catalyst::Runtime 5.8.16, Catalyst::Script::FastCGI is buggy and ignores the --daemon option. Looking at the source, I think it is mistakenly looking for --detach, although it is documented as wanting --daemon. -Toby ___ 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] Cat-Runtime 5.8.16 broke with catalyst_par
Hey guys,
Catalyst::Runtime 5.80016 introduced a bug with catalyst_par.
Various modules are now required for the scripts in /script/, however
when building your application with "make catalyst_par" these are not
included.
Temporary fix is to add to Makefile.PL:
catalyst_par_classes('Catalyst::ScriptRunner');
catalyst_par_classes('Catalyst::Script::FastCGI');
..etc..
-Toby
___
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 - new test
Tomas Doran wrote: Toby Corkindale wrote: It's interesting to note the headline figures have 5.71 performing 316 tps, vs 5.80 making only 283 tps. The very important thing you haven't noted (unless I missed it) is what perl version this benchmark was conducted under. Some benchmarking was done before 5.8 was released, and it showed that Catalyst 5.7 was (marginally) quicker on perl 5.8 and that Catalyst 5.8 was (marginally) quicker on perl 5.10 :) So I'd be very interested to see the benchmark repeated with two different perls, giving 4 results to compare and contrast. Catalyst 5.80 on Perl 5.8.8, same VM hardware, same test app, testing methodology, but against Debian 4.5 rather than Ubuntu 9.04. Result: 191 tps. (ie. Significantly slower than catalyst 5.80 on Perl 5.10, which was 282 tps) -Toby ___ 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
Carl Johnstone wrote: Toby Corkindale wrote: (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/ ) Was patched last year - stop spreading FUD. OK, well do you want to get CentOS to close the bug on it then? :P http://bugs.centos.org/view.php?id=2357 (I sent an email to some CentOS-using friends asking them what's up and I see they added a note to the bottom of the bug just yesterday..) For those of us not using Centos, but helping others, we can only go on what we read. It IS the official bugtracker for centos, isn't it? If we can't trust it, what CAN we trust?) The RHEL/CentOS perl build isn't the best one is the world but it's adequate enough for most uses. Too much FUD will just scare decision makers who don't understand the technical details and just see perl + RHEL = fail. Well, that pretty much WAS the case for quite a long time :( Glad to hear it's finally fixed up though. tjc ___ 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 - new test
Tomas Doran wrote: Toby Corkindale wrote: It's interesting to note the headline figures have 5.71 performing 316 tps, vs 5.80 making only 283 tps. The very important thing you haven't noted (unless I missed it) is what perl version this benchmark was conducted under. Ah, sorry, I didn't mention it. I benchmarked it on Perl 5.10.0, using the standard system Perl on Ubuntu Jaunty. (With updates applied) I was benchmarking the two Catalyst's on otherwise-identical setups, as I thought that was fairer.. Just about *everything* OO performs faster on Perl 5.010 vs 5.008, doesn't it? Some benchmarking was done before 5.8 was released, and it showed that Catalyst 5.7 was (marginally) quicker on perl 5.8 and that Catalyst 5.8 was (marginally) quicker on perl 5.10 :) My test app is very simple; If there's some official test app available I'd be interesting in re-running my tests. I pushed my little test app and some siege scripts out to github, but I don't think they'd be happy with 2GB of virtual machine images being added :) So I'd be very interested to see the benchmark repeated with two different perls, giving 4 results to compare and contrast. I'll see if I get some more time to try that; building Perl from scratch takes quite a bit longer than using the system perl.. and if I start comparing with totally different OS versions then the tests aren't really so valid, are they? -- Strategic Data Pty Ltd Ph: 03 9340 9000 ___ 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 - new test
Toby Corkindale wrote: It's interesting to note the headline figures have 5.71 performing 316 tps, vs 5.80 making only 283 tps. Memory usage (for this small app) has increased by 4MB, but is presumably shared. I guess I should look into that more. Here are some new analysis of memory usage on my test app. 5.7 5.8 Rss: 35260 38768 Private: 82449620 Shared: 27016 29148 So 5.8 is 3500kB larger, but 2000kB is shared. So we're only looking at 1500Kb more per process. -Toby ___ 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 - new test
Fayland Lam wrote: I'm wondering if someone here did a benchmark between Catalyst 5.7 and 5.8 I have a vested interest in knowing the difference between the two versions as well, so knocked up a "proper" test. I have two identical virtual machines, only on one I installed Catalyst::Runtime 5.71001 and the other with 5.80013. Running the exact same app, I hit them up with Siege for a while, results follow at the end of this email. If you want to replicate the test or examine my extremely-simple test app, see: http://github.com/TJC/Catalyst-Performance-Test (Patches gleefully accepted ;) It's interesting to note the headline figures have 5.71 performing 316 tps, vs 5.80 making only 283 tps. Memory usage (for this small app) has increased by 4MB, but is presumably shared. I guess I should look into that more. The same system can serve small static pages from the webserver at about 1900 tps. A real-world application there on Cat 5.8 gets 90 tps. I don't see that performance difference (5.71 vs 5.80) as significant, since most of your time ends up being spent in application code, rather than the Catalyst framework itself. ie. If you want to make your code go faster, look at optimising your templating and database queries before you worry about downgrading Catalyst. -Toby --= results =-- Running 10 second warmup on 5.7.. Running main test on 5.7.. Transactions: 94796 hits Availability: 100.00 % Elapsed time: 300.00 secs Data transferred: 77.35 MB Response time: 0.03 secs Transaction rate: 315.99 trans/sec Throughput: 0.26 MB/sec Concurrency: 10.00 Successful transactions: 94796 Failed transactions: 0 Longest transaction:0.98 Shortest transaction: 0.00 Process size: 101m VIRT, 34m RES Running 10 second warmup on 5.8.. Running main test on 5.8.. Transactions: 84805 hits Availability: 100.00 % Elapsed time: 300.00 secs Data transferred: 69.20 MB Response time: 0.04 secs Transaction rate: 282.68 trans/sec Throughput: 0.23 MB/sec Concurrency:9.99 Successful transactions: 84805 Failed transactions: 0 Longest transaction:1.07 Shortest transaction: 0.00 Process size: 103m VIRT, 38m RES ___ 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
(Apologies for top-posting.. have momentarily lost the option to change quoting styles it seems..) 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/ ) Cheers, Toby - Original Message - From: Fayland Lam To: catalyst@lists.scsys.co.uk Sent: Mon, 28 Sep 2009 15:56:36 +1000 (EST) Subject: [Catalyst] Catalyst benchmark 5.7 VS 5.8 I'm wondering if someone here did a benchmark between Catalyst 5.7 and 5.8 here is the result from our server: http://scsys.co.uk:8001/34323 the background is Catalyst 5.7011 VS Catalyst 5.80013 CPU: Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.33GHz RAM: 4G OS: Centos5 from the top, each httpd takes 20M more RAM in 5.8 compared with 5.7 5.7 PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 22979 apache16 0 167m 142m 4248 S 17.0 3.5 0:06.07 httpd 5.8 PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 24813 apache15 0 190m 165m 4000 S 15.6 4.1 0:02.56 httpd in this case, I really can't let my boss agree me to upgrade the Catalyst. is it normal? any thoughts? Thanks. -- Fayland Lam // http://www.fayland.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/ ___ 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] Re: Catalyst 5.800013 - missing dependency version
Marcus Ramberg wrote:
Another day, another Catalyst 5.8 maintainance release. This time,
lucky number 13. The main reason for this release is a change in the
guts of the most recent Class::MOP. Thus, this release depends on the
latest Moose/Class-MOP, see the changelog attached below for details.
There are also some minor documentation/refactoring changes, and
removal of the -short option to catalyst.pl, which generated a
deprecated style Catalyst namespace.
I am running the latest stable versions of Moose/Class-MOP and their
dependencies.
to...@arya:~$ pmvers Moose
0.91
to...@arya:~$ pmvers Class::MOP
0.93
When installing Catalyst::Runtime 5.800013 the tests were (eventually)
successful - however they output a vast amount of warnings from Moose.
The following dump is just the output from a single unit test!
(In this case, t/unit_metaclass_compat_non_moose_controller.t, since it
was the last one in the log that produced the warnings. The following
t/unit*.t ones were quiet.)
However I then upgraded MooseX::Types to 0.20, and the warnings went away.
Thus I'm guessing MooseX::Types needs to have a higher required version
in Makefile.PL?
--
Trying to export undefined sub MooseX::Types::CheckedUtilExports::type
at /usr/share/perl5/Moose/Exporter.pm line 210
Moose::Exporter::_sub_from_package('Moose::Exporter',
'MooseX::Types::CheckedUtilExports', 'type') called at
/usr/share/perl5/Moose/Exporter.pm line 145
Moose::Exporter::_make_sub_exporter_params('Moose::Exporter',
'ARRAY(0x120ad48)', 'HASH(0x120ad18)') called at
/usr/share/perl5/Moose/Exporter.pm line 40
Moose::Exporter::build_import_methods('Moose::Exporter', 'with_caller',
'ARRAY(0x19af398)', 'exporting_package',
'MooseX::Types::CheckedUtilExports', 'install', 'ARRAY(0x120aca0)')
called at /usr/share/perl5/Moose/Exporter.pm line 23
Moose::Exporter::setup_import_methods('Moose::Exporter', 'with_caller',
'ARRAY(0x19af398)') called at
/usr/share/perl5/MooseX/Types/CheckedUtilExports.pm line 48
require MooseX/Types/CheckedUtilExports.pm called at
/usr/share/perl5/MooseX/Types.pm line 15
MooseX::Types::BEGIN() called at
/usr/share/perl5/MooseX/Types/CheckedUtilExports.pm line 0
eval {...} called at
/usr/share/perl5/MooseX/Types/CheckedUtilExports.pm line 0
require MooseX/Types.pm called at
/usr/share/perl5/MooseX/Types/Moose.pm line 12
MooseX::Types::Moose::BEGIN() called at
/usr/share/perl5/MooseX/Types/CheckedUtilExports.pm line 0
eval {...} called at
/usr/share/perl5/MooseX/Types/CheckedUtilExports.pm line 0
require MooseX/Types/Moose.pm called at
/usr/share/perl5/MooseX/MethodAttributes/Role/Meta/Map.pm line 7
MooseX::MethodAttributes::Role::Meta::Map::BEGIN() called at
/usr/share/perl5/MooseX/Types/CheckedUtilExports.pm line 0
eval {...} called at
/usr/share/perl5/MooseX/Types/CheckedUtilExports.pm line 0
require MooseX/MethodAttributes/Role/Meta/Map.pm called at
/usr/lib/perl5/Class/MOP.pm line 129
eval {...} called at /usr/lib/perl5/Class/MOP.pm line 129
Class::MOP::_try_load_one_class('MooseX::MethodAttributes::Role::Meta::Map')
called at /usr/lib/perl5/Class/MOP.pm line 90
Class::MOP::load_first_existing_class('MooseX::MethodAttributes::Role::Meta::Map')
called at /usr/lib/perl5/Class/MOP.pm line 135
Class::MOP::load_class('MooseX::MethodAttributes::Role::Meta::Map')
called at /usr/share/perl5/Moose/Util.pm line 99
Moose::Util::_apply_all_roles('Moose::Meta::Role=HASH(0x193abf8)',
undef, 'MooseX::MethodAttributes::Role::Meta::Map') called at
/usr/share/perl5/Moose/Util.pm line 84
Moose::Util::apply_all_roles('Moose::Meta::Role=HASH(0x193abf8)',
'MooseX::MethodAttributes::Role::Meta::Map') called at
/usr/share/perl5/Moose/Role.pm line 26
Moose::Role::with('Moose::Meta::Role=HASH(0x193abf8)',
'MooseX::MethodAttributes::Role::Meta::Map') called at
/usr/share/perl5/Moose/Exporter.pm line 288
Moose::Role::with('MooseX::MethodAttributes::Role::Meta::Map') called
at /usr/share/perl5/MooseX/MethodAttributes/Role/Meta/Role.pm line 15
require MooseX/MethodAttributes/Role/Meta/Role.pm called at
/usr/share/perl5/MooseX/MethodAttributes/Inheritable.pm line 8
MooseX::MethodAttributes::Inheritable::BEGIN() called at
/usr/share/perl5/MooseX/Types/CheckedUtilExports.pm line 0
eval {...} called at
/usr/share/perl5/MooseX/Types/CheckedUtilExports.pm line 0
require MooseX/MethodAttributes/Inheritable.pm called at
/usr/lib/perl5/Class/MOP.pm line 129
eval {...} called at /usr/lib/perl5/Class/MOP.pm line 129
Class::MOP::_try_load_one_class('MooseX::MethodAttributes::Inheritable')
called at /usr/lib/perl5/Class/MOP.pm line 90
Class::MOP::load_first_existing_class('MooseX::MethodAttributes::Inheritable')
called at /usr/lib/perl5/Class/MOP.pm line 135
Class::MOP::load_class('MooseX::MethodAttributes::Inheritable') called
at /usr/share/perl5/Moose/Meta/Class.pm line 234
Moose::Meta::Class::superclasses('Moose::Meta::Cl
[Catalyst] [POD] Doc patch for ConfigLoader
Hi, This patch fixes a minor error in the ConfigLoader documentation. (It refered to myapp.local when it meant myapp_local.conf) Also reported as RT#48823 ta, Toby commit eb6a0cfc82bd57c2ad0f4eab3d08257b43628ea1 Author: Toby Corkindale Date: Wed Aug 19 15:33:51 2009 +1000 [POD] Fix mistake in documentation. diff --git a/lib/Catalyst/Plugin/ConfigLoader/Manual.pod b/lib/Catalyst/Plugin/ConfigLoader/Manual.pod index 5772207..d3f6bfb 100644 --- a/lib/Catalyst/Plugin/ConfigLoader/Manual.pod +++ b/lib/Catalyst/Plugin/ConfigLoader/Manual.pod @@ -216,10 +216,10 @@ Each developer, and the web server, would set the environment variable to load their proper configuration file. All of the configurations can be stored properly in source control. -If there is no C, and the individual configuration files contain -something required to start the application, such as the Model's data source -definition, the applicaton won't start unless the environment variable -is set properly. +If there is no C (where .ext is a supported extension), and +the individual configuration files contain something required to start the +application, such as the Model's data source definition, the applicaton won't +start unless the environment variable is set properly. =cut ___ 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 action attributes
Tomas Doran wrote:
On 13 Jul 2009, at 07:50, Toby Corkindale wrote:
Devin Austin wrote:
Check this out:
http://search.cpan.org/~hkclark/Catalyst-Manual-5.8000/lib/Catalyst/Manual/ExtendingCatalyst.pod#Attributes
and
http://search.cpan.org/~hkclark/Catalyst-Manual-5.8000/lib/Catalyst/Manual/ExtendingCatalyst.pod#Action_classes
Thanks, although I had already read that before posting.
As far as I can see, there is no way to pass parameters to the
ActionClass. Have I missed something?
The action class is passed the attributes when it is constructed in its
arguments.
However - before we get into this, I recommend you write an ActionRole
(ala Catalyst::Controller::ActionRole) instead of an action class, as
you can use multiple actionroles together (which is not the case with
action classes).
Simple example of some prior art you can steal to get you going:
http://search.cpan.org/~bobtfish/Catalyst-ActionRole-FindViewByIsa-0.02/lib/Catalyst/ActionRole/FindViewByIsa.pm
Thanks, that's great.
So to summarise, the "best practice" way of passing parameters to these
attribute-handlers is by using more attributes, that you *don't*
specifically handle, but access via $c->action->attributes->{..}
I think that's right?
Cheers,
Toby
___
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 action attributes
Devin Austin wrote:
Check this out:
http://search.cpan.org/~hkclark/Catalyst-Manual-5.8000/lib/Catalyst/Manual/ExtendingCatalyst.pod#Attributes
and
http://search.cpan.org/~hkclark/Catalyst-Manual-5.8000/lib/Catalyst/Manual/ExtendingCatalyst.pod#Action_classes
Thanks, although I had already read that before posting.
As far as I can see, there is no way to pass parameters to the
ActionClass. Have I missed something?
On Mon, Jul 13, 2009 at 12:27 AM, Toby Corkindale
<mailto:toby.corkind...@strategicdata.com.au>> wrote:
Toby Corkindale wrote:
Hi,
I wondered if anyone could point me towards a working example of
creating custom action attribute handlers for Catalyst?
eg. The contents of Catalyst::Controller::SecretAgent in the
example below:
package MyApp::Controller::M;
use parent 'Catalyst::Controller::SecretAgent';
# Provides Vehicle() and Gimmick() actions.
sub bond : Vehicle('Aston Martin') {
my ($self, $c) = @_;
# ...
}
sub maxwell_smart : Gimmick('Shoe-phone') {
My ($self, $c) = @_;
#...
}
1;
I should clarify what I'm after..
I'd still like to be able to specify regular DispatchType attributes
against the routines (eg. Local, Chained, etc), but I'd also like to
have my own methods called against the other attributes I've specified.
The first method I tried was:
package Catalyst::Controller::SecretAgent;
use strict / use warnings
use parent 'Catalyst::Controller';
use attributes __PACKAGE__ => \&set_vehicle, "Vehicle";
sub set_vehicle { # do something }
...
but I think that messes up catalyst's own handling of attributes.
___
List: Catalyst@lists.scsys.co.uk <mailto: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/
--
Devin Austin
http://www.codedright.net
http://www.dreamhost.com/r.cgi?326568/hosting.html - Host with DreamHost!
___
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/
--
Strategic Data Pty Ltd
Ph: 03 9340 9000
___
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 action attributes
Toby Corkindale wrote:
Hi,
I wondered if anyone could point me towards a working example of
creating custom action attribute handlers for Catalyst?
eg. The contents of Catalyst::Controller::SecretAgent in the example below:
package MyApp::Controller::M;
use parent 'Catalyst::Controller::SecretAgent';
# Provides Vehicle() and Gimmick() actions.
sub bond : Vehicle('Aston Martin') {
my ($self, $c) = @_;
# ...
}
sub maxwell_smart : Gimmick('Shoe-phone') {
My ($self, $c) = @_;
#...
}
1;
I should clarify what I'm after..
I'd still like to be able to specify regular DispatchType attributes
against the routines (eg. Local, Chained, etc), but I'd also like to
have my own methods called against the other attributes I've specified.
The first method I tried was:
package Catalyst::Controller::SecretAgent;
use strict / use warnings
use parent 'Catalyst::Controller';
use attributes __PACKAGE__ => \&set_vehicle, "Vehicle";
sub set_vehicle { # do something }
...
but I think that messes up catalyst's own handling of attributes.
___
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] Catalyst action attributes
Hi,
I wondered if anyone could point me towards a working example of
creating custom action attribute handlers for Catalyst?
eg. The contents of Catalyst::Controller::SecretAgent in the example below:
package MyApp::Controller::M;
use parent 'Catalyst::Controller::SecretAgent';
# Provides Vehicle() and Gimmick() actions.
sub bond : Vehicle('Aston Martin') {
my ($self, $c) = @_;
# ...
}
sub maxwell_smart : Gimmick('Shoe-phone') {
My ($self, $c) = @_;
#...
}
1;
___
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] Re: [Dbix-class] Cat Model DBIC Schema fails test if *optional* prereq isn't installed
Toby Corkindale wrote: Hi, Catalyst::Model::DBIC::Schema lists Catalyst::Devel as an *optional* dependency. However if you do not have Catalyst::Helper installed (via Catalyst::Devel) then C-M-DBIC-Schema fails its unit tests and won't install via CPAN. Fix committed to trunk. Cheers, Toby ___ 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] Cat Model DBIC Schema fails test if *optional* prereq isn't installed
Hi, Catalyst::Model::DBIC::Schema lists Catalyst::Devel as an *optional* dependency. However if you do not have Catalyst::Helper installed (via Catalyst::Devel) then C-M-DBIC-Schema fails its unit tests and won't install via CPAN. -Toby ___ 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 much RAM do your Catalyst apps use up?
- kakim...@tpg.com.au wrote: > Hi, guys, > > I have a virtual machine with 256MB of ram. When I run my catalyst > app > (ie myapp_server.pl) in the day, it's fine. NEvertheless, when I run > my > app from 6pm onwards til midnight, a few clicks on the app to > retrieve > some data (the same way I use it in the mornings), and the whole > machine > hangs up on me. I have a few Ubuntu Server virtual machines with 256 MB of ram allocated, which use Postgres 8.3 and Catalyst (under apache w/mod_perl), and they run fine for single-user usage of the application. (They're for testing.. I also have some catalyst+postgres apps running on live sites, but I've never tried those on so little ram!) I'm surprised the entire machine locks up -- have you tried diagnosing what is going on when that happens? (eg. checking log files) Is it defnitely an OOM problem, or something else manifesting? -Toby ___ 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] FormFu edit form problem
Toby Corkindale wrote: [snip] > I might be able to get around this, and the other show-stopper bug[1], by building a custom DBIC pseudo-resultset that aggregates several resultsets into one to avoid the problems FormFu has with relationships.. [snip] Ah, bother, this didn't work. FormFu's introspection of the model doesn't work if some of the columns have been brought in via the 'proxy' attribute of a DBIC relationship, and FF attempts to call resultset methods on a row object. Oh well, was worth a try. ___ 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] FormFu edit form problem
Moritz Onken wrote: Am 29.05.2009 um 07:43 schrieb Toby Corkindale: Moritz Onken wrote: Do you run the latest version of DBIC? I was running on 0.08012, however I have updated to 0.08103 and still have the same problem. -Toby The problem is that there is no good way to decide whether a given relationship is a has_one or belongs_to relationship. at least this is what DBIC people say. SO if you set is_foreign_key_constraint to 0, FormFu assumes that it is a has_one relationship and not a belongs_to relationship. Right now I have no idea how to fix it! Ah, oh well, thanks for explaining the problem at least. I'm rather regretting using FormFu on my current project by now; it looks like I've rather wasted my time. I might be able to get around this, and the other show-stopper bug[1], by building a custom DBIC pseudo-resultset that aggregates several resultsets into one to avoid the problems FormFu has with relationships.. but I don't like increasing the complexity of my application, just so that I can use a module which was supposed to *reduce* the complexity! :) I feel like FormFu would be great for doing simple forms, if you don't mind the lack of useful documentation, but it seems very.. fragile.. once you start trying to use the more complicated use-cases that the documentation suggests it should handle. I say "fragile", because I think that FormFu does hold it together if you obey all the caveats; however there's just no way for a new user to know what all those caveats are in advance. ta, Toby [1: Repeated nested_name blocks ignore every instance except the first] ___ 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] Bug with re-occuring nested related tables with CP FormFu?
Hi, I'm using FormFu in Catalyst, with a DBIC schema, and have a problem with a particular usage of nested relationships in the form. The table in question has a might_have relationship with another table, let's say like: book (id, title, blurb) book_extra (book_id, num_pages, in_stock) Now, I setup a form like: --- elements: - name: title type: Text - type: Block tag: div nested_name: book_extra elements: - name: num_pages type: Text - name: blurb type: Textarea - type: Block tag: div nested_name: book_extra elements: - name: in_stock type: Checkbox - The idea being that num_pages and in_stock are sent to the related table instead. This *does* work for the first nested item, in this case num_pages. However the second time it comes up, it doesn't do anything - ie. in_stock is never saved to the DB. If I move the in_stock element higher up, in the same Block as num_pages, then it does work. Is this a known bug/limitation, or is this supposed to work? Am I doing something wrong? thanks, Toby ___ 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] FormFu edit form problem
Moritz Onken wrote:
Do you run the latest version of DBIC?
I was running on 0.08012, however I have updated to 0.08103 and still
have the same problem.
-Toby
Hi Carl,
The patched version of 0.04004 seemed to work fine, however the
released 0.05000 only works on some, but not all, of my tables.
I tracked the issue down to part of HTML::FormFu::Model::DBIC around
line 534, where you do:
---
if ( exists $info->{attrs}{is_foreign_key_constraint} ) {
$fk_constraint = $info->{attrs}{is_foreign_key_constraint};
}
...
else {
$fk_constraint = not
$dbic->result_source->compare_relationship_keys( \...@keys, \...@fpkey );
}
next if($fk_constraint);
...
croak 'The primary key and the foreign key may not be the same column
in class '.$fclass if $fpkey eq $fkey;
---
The tables that break FormFu have relationships defined where the
is_foreign_key_constraint attribute is set to false. If I change it to
true, everything seems to work fine.
Eg.
__PACKAGE__->belongs_to(
gp => 'My::Schema::Result::GP',
{ id => 'gp' },
{ is_foreign_key_constraint => 0 }
);
I didn't write the DB schema so I'm not sure why they indicated these
weren't foreign keys, when they are, but I still don't think FormFu
should barf on them.
What do you think?
Thanks,
Toby
___
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/
___
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] FormFu edit form problem
Carl Franks wrote:
2009/5/26 Toby Corkindale :
And after applying the patch linked above, the problem went away. Presto!
I'm looking forward to that being included in a 0.04004 release soon..
Thanks - that patch had gotten past my radar!
It's now applied, and new releases of HTML-FormFu and
HTML-FormFu-Model-DBIC have been uploaded to pause, and should be
available on cpan within a couple of hours.
Hi Carl,
The patched version of 0.04004 seemed to work fine, however the released
0.05000 only works on some, but not all, of my tables.
I tracked the issue down to part of HTML::FormFu::Model::DBIC around
line 534, where you do:
---
if ( exists $info->{attrs}{is_foreign_key_constraint} ) {
$fk_constraint = $info->{attrs}{is_foreign_key_constraint};
}
...
else {
$fk_constraint = not
$dbic->result_source->compare_relationship_keys( \...@keys, \...@fpkey );
}
next if($fk_constraint);
...
croak 'The primary key and the foreign key may not be the same column in
class '.$fclass if $fpkey eq $fkey;
---
The tables that break FormFu have relationships defined where the
is_foreign_key_constraint attribute is set to false. If I change it to
true, everything seems to work fine.
Eg.
__PACKAGE__->belongs_to(
gp => 'My::Schema::Result::GP',
{ id => 'gp' },
{ is_foreign_key_constraint => 0 }
);
I didn't write the DB schema so I'm not sure why they indicated these
weren't foreign keys, when they are, but I still don't think FormFu
should barf on them.
What do you think?
Thanks,
Toby
___
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] FormFu edit form problem
Moritz Onken wrote: Am 20.05.2009 um 00:37 schrieb Greg Coates: I'm using HTML::FormFu::Model::DBIC version 0.04002, and this problem is still there. Do we know when a patch might be available? Greg Hi Greg, which problem are you referring to? Can you provide some code? moritz I'm not sure, but they might be referring to this post: http://www.mail-archive.com/html-for...@lists.scsys.co.uk/msg01528.html (For the record, I'm hitting the same error message about "The primary key and the foreign key may not be the same column" with version 0.04002 of HFM-DBIC) Toby ___ 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] FormFu edit form problem
Toby Corkindale wrote: Moritz Onken wrote: Am 20.05.2009 um 00:37 schrieb Greg Coates: I'm using HTML::FormFu::Model::DBIC version 0.04002, and this problem is still there. Do we know when a patch might be available? Greg Hi Greg, which problem are you referring to? Can you provide some code? moritz I'm not sure, but they might be referring to this post: http://www.mail-archive.com/html-for...@lists.scsys.co.uk/msg01528.html (For the record, I'm hitting the same error message about "The primary key and the foreign key may not be the same column" with version 0.04002 of HFM-DBIC) ... And after applying the patch linked above, the problem went away. Presto! I'm looking forward to that being included in a 0.04004 release soon.. -T ___ 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::Plugin::Captcha
Emmanuel Quevillon wrote: Octavian Râsnita wrote: From: "Emmanuel Quevillon" Better use Catalyst::Controller::HTML::FormFu. You can easy add reCAPTCHA with it. reCAPTCHA also creates an audio file so more human beeings would be able to pass it. Sure, but reCAPTCHA needs that you regsiter to get an api key from their web site. I wanted to use C::P::Captcha because it does not require that kind of thing. I'm guessing it's a font issue; I think it uses, erm, either GD or ImageMagick to generate the image. Try forcing it to use the other library from whatever it's using now? Check that you can manually create an image with GD/IM in the same way.. I'd guess that something has gone wrong though, and its falling back to some kind of default-size / unscaleable font. Toby ___ 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] Building a PAR file
Octavian Râşniţă wrote: Hello, I've tried to create a PAR archive from a Catalyst app and I've done: 1. Put catalyst_par(); in Makefile.PL. 2. Run perl Makefile.PL 3. Run nmake catalyst_par But it gave the following error: Writing PAR "acces.par" NMAKE : fatal error U1077: 'E:\perl510\bin\perl.exe' : return code '0x2' Stop. Do you have any idea what could be the problem? PAR? Catalyst? Can't a PAR archive of a Catalyst app be built under Windows? Hi Octavian, I use PAR to package some apps under Win32, which work fine, so I thought I'd give it a short with Catalyst as I know the PAR system is known-good on that win32 VM. I used cpanplus to install Catalyst::Devel, then ran 'catalyst MyApp', then added catalyst_par(); to the Makefile, then ran dmake catalyst_par.. I received this error: ... Writing PAR "myapp.par" dmake: Error code 130, while making 'catalyst_par' Erm. So no, it doesn't seem to work here either. Tested on Strawberry Perl 5.10, with current stable releases of PAR, PAR::Packer, Module::ScanDeps, and Catalyst::Devel. (and most of its dependencies, as most were freshly installed, except for dbic) ___ 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 confirm before deleting
Trevor Phillips wrote: On Thu, Jan 22, 2009 at 3:12 PM, Toby Corkindale wrote: But what happens when your site gets spidered by a search engine, that follows all links? Whoops. There's a good reason state-modification-actions should be POST (or rather, non-GET, if you want to go with PUT, DELETE, etc) Surely such an action would be behind some form of authentication, ergo blocking any random web crawler? An app that allowed you to delete records with no security checks has bigger issues. ^_^ Yeah.. can't actually remember what the actions were, but indeed, 'twas misguided. After posting that, I realised other people had already posted warnings about not using GET for state-change anyway. ___ 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 confirm before deleting
Kieren Diment wrote: Yeah, 98% of your browsers have javascript enabled and a big chunk of the remainder are bots ... On the other hand you might want a non-javascript undo option at the other end if you go that route. Oh, and watch out for a Classic Error I saw in someone's code a little while ago.. They had entered a bunch of state-modifying buttons like this: src="/static/trashcan.gif" alt="Delete"/> But what happens when your site gets spidered by a search engine, that follows all links? Whoops. There's a good reason state-modification-actions should be POST (or rather, non-GET, if you want to go with PUT, DELETE, etc) On 22/01/2009, at 3:06 PM, Jonathan Rockway wrote: * On Wed, Jan 21 2009, Dave Howorth wrote: Paul Falbe wrote: That works thank you very much. Don't know how many google searchs I did trying to find that out! Rodrigo-51 wrote: Paul, how about a javascript confirm() box? ... and if the user has Javascript disabled? Please enable Javascript. It's Two Thousand Fucking Nine. ___ 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 Fix Test-Harness-3.14?
Robert L Cochran wrote: I'm trying to install Catalyst-Runtime-5.7015 using cpan inside a CentOS 5.2 virtual machine (running under VMWare, fully updated to current CentOS patches) and one of the reasons installation is failing is because Test-Harness-3.14 is failing it's own tests. I'm not very good with Perl at this time and I figure there are people here who understand why Test-Harness fails. Here is the output I have from 'make test'. Can anyone suggest what the problem is? The output below suggests the problem is not related to Test::Harness, but is from List::Util.. it looks like you have two versions of LU installed at once, one is version 1.18 and the other 1.19. Can you look into that? -Toby ___ 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] Newbie help
Diego M. Vadell wrote: Hi everybody, I'm making a nice little webapp in Catalyst: metheorology models run via crontab and catalyst shows the data and graphs that they produce. Im very happy how it's working so far. Now I have been asked if I could make a "Run the model now" button, that would run a script (the model) and show it's output in a popup window. The process may run for about 15 minutes, so I have to handle , somehow, the browser timing out because of lack of output. I thought about making the script output to a tmp file and using ajax to query that file. What is the best way to do that? Is there a nice, magical CPAN module out there? :) You don't really need one.. Simplest way to handle this would be for the web page to kick off the model running in another process, and then immediately display a web page that says "Please wait, model running.." That page then either uses javascript or a http-refresh mechanism to check back every 30 seconds to see if the model is ready yet. -Toby -- Strategic Data Pty Ltd Ph: 03 9340 9000 ___ 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] Attention Australian Catalystarati (or anyone else with an interest in internet activism)
Kieren Diment wrote: On 13/01/2009, at 12:17 PM, Gavin Carr wrote: On Mon, Jan 12, 2009 at 08:16:46PM +1100, Kieren Diment wrote: Open Australia (http://openaustralia.org) are trying to digitise the parliamentary register of members interest to improve transparrency in the federal parliament.The register at the moment is only available in the basement of the federal parliament in a locked filing cabinet in a disused toilet behind a sign which says beware of the tiger ... you get the idea. One of our ilk has kindly started rigging up a prototype which is available at github from http://github.com/TJC/openaustralia-rmidet/tree/master If you're an Australian Catalyst coder with a few tuits, or of you're not Australian, but you want to get some practical experience with crowdsourcing document transcription, please fork the git repository and have a play. Are you looking for contributors, Kieren, or just for general feedback? If the former, is there a TODO list somewhere, or a dev mailing list or something people can join? Unfortunately I'm pretty low on tuits for a couple of months, but I'd love to see this succeed - the openaustralia is pretty high visibility in Australia, and I'd like to see more perl and catalyst programmers doing interesting stuff in this space. As far as I can see the problem that needs to be solved here is how to efficiently provide crowdsourced document transcription. Toby's got a prototype that does document display, next up I guess is getting it transcribed. I had some good free time over the Xmas break (aren't family wonderful? ;) but am also fairly busy during January.. should improve by the end of the month though. My short-term plans for the prototype are: * Include the recently-released per-senator PDFs into the pdf-to-jpeg conversion stream. * Create a DBIC schema that represents the data we need to capture. * Create login/logout pages, and admin pages to manage users. * Create pages to allow you to select a senator or minister to work upon, and then uses JQuery tabs for all the different info that can be recorded. Uses type-ahead searching for company names, suburbs, ASX stock symbols, etc. * Create review pages for admins to compare what users have done vs the pages it allegedly was transcribed from. -Toby ___ 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] Attention Australian Catalystarati (or anyone else with an interest in internet activism)
Gavin Carr wrote: On Mon, Jan 12, 2009 at 08:16:46PM +1100, Kieren Diment wrote: Open Australia (http://openaustralia.org) are trying to digitise the parliamentary register of members interest to improve transparrency in the federal parliament.The register at the moment is only available in the basement of the federal parliament in a locked filing cabinet in a disused toilet behind a sign which says beware of the tiger ... you get the idea. One of our ilk has kindly started rigging up a prototype which is available at github from http://github.com/TJC/openaustralia-rmidet/tree/master If you're an Australian Catalyst coder with a few tuits, or of you're not Australian, but you want to get some practical experience with crowdsourcing document transcription, please fork the git repository and have a play. Are you looking for contributors, Kieren, or just for general feedback? If the former, is there a TODO list somewhere, or a dev mailing list or something people can join? http://groups.google.com/group/openaustralia-dev is the discussion list for development. Cheers, Toby ___ 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] Catalys & TheSchwartz, was Catalyst modperl - child process segmentation fault
Matija Grabnar wrote:
> afaict, you should let dbic / cat-model handle the connection to the
database.
That reminds me. Does anybody have experience submitting TheSchwartz
jobs from a Catalyst?
> TheSchwartz uses it's own system of allocating DB handles, and I have no
> idea how it interacts with
> Catalyst's.
>
> I *think* I'm safe because I'm not allocating any schwatz connections
> until I'm actually serving a
> Catalyst request, but I'd like to hear from anybody who has actual
> experience...
*nods*
In fact, I've just finished ripping out every reference to TheSchwartz I
could find in my codebase, as it ended up being more trouble than it was
worth :/
(Although I'm sure it works well enough for some people. Livejournal.com
for instance, not that they're exactly a bastion of five-nines uptime.)
One thing to watch out for is that it handles its own database
connections, so if you're using the same database as for the rest of
your model, then you can potentially deadlock if you're using a
sufficiently brain-dead SQL database.
Eg:
$c->model('DB')->txn_do(sub {
my $foo = $c->model('DB::Foo')->find(1);
$foo->bar(999);
$foo->update;
$c->model('Schwartz')->insert('DoFoo', { id => $foo->id });
});
will deadlock on SQLite.
(Which is more SQLite's fault than theSchwartz's though.)
-Toby
___
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] Problem with the order of action
José Castro wrote:
Hi.
Let's say I have (and I do) something like this in one controller:
sub create : Path('/users/new') {
and something like this in another controller:
sub attribute : Regex('^([^/]+)/([^/]+)(?:/page/(\d+))?$') {
My goal here is to try to match the url with /users/new and, that
failing, try matching with that regex up there.
My problem, as many of you will have figured out, if that /users/new is
bumping into the attribute sub (which makes sense, as it does match the
regex).
Is there any way of tampering with the order the methods in the
controllers are tried? (other than changing the names of the
controllers, hopefully)
I think here you should look at what you're trying to do, and map it
onto Catalyst a little differently. That Regex is worrying me.
Have you read the documentation on the "Chained" method of dispatching?
I think it could be the right way to do that.
Cheers,
Toby
___
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
Terence Monteiro wrote: Toby Corkindale wrote: Terence Monteiro wrote: Toby Corkindale wrote: Terence Monteiro wrote: I'm running my Catalyst application on apache2 using modperl with mysql database accessed by DBIx::SearchBuilder. I'm getting the message in the apache2 error logs: child pid 1140 exit signal Segmentation fault (11), possible core dump in /tmp ]snip] Ugh.. Dumping core? That's rather drastic! What versions of DBI and DBD::mysql are you running? And is DBD::mysql linked against the same mysql client libraries as mod_php? Thanks, Toby DBD::mysql version: 4.008 DBI version:1.607 libapache2-mod-php5 version: 5.2.0-8+etch10 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. Could you humour me, and try disabling PHP in Apache, and then seeing if> that stops the Catalyst app crashing? I think you can do it by 'rm /etc/apache/mods-enabled/*php*.load' or something very similar? Thanks for the reply. I have switched to fastcgi deployment and so far have not had any segfaults. I will try what you're saying tonight, since being a production environment, I get downtime only after 7:30pm IST (0100 UTC). To check the actual versions of libraries used, you can do: ldd /usr/lib/apache2/modules/mod_php*.so ldd /usr/lib/perl5/auto/DBD/mysql/mysql.so (At least I'm pretty sure that's where the files should be on debian etch) But if you've recompiled dbd::mysql from source, and not mod_php, then I'll bet this IS the problem. Sorry. I installed both DBD::mysql and mod_php from debian packages (libdbd-mysql-perl and libapache2-mod-php5). I did not compile DBD::mysql (never have before). Ah, sorry, I mistook something. But I do think you said you installed the DBD::Mysql from a debian backports, whereas the mod_php was from etch stable? So, the Debian crew have done the compiling for you, but still, the DBD::mysql is linked against mysqlclient from backports, while mod_php is linked against the stable mysql client libraries. Another test would be to update all of perl, apache, mod_php, dbd::mysql, mod_perl etc from backports, so at least everything is from the same source. tjc ___ 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
Terence Monteiro wrote: Toby Corkindale wrote: Terence Monteiro wrote: I'm running my Catalyst application on apache2 using modperl with mysql database accessed by DBIx::SearchBuilder. I'm getting the message in the apache2 error logs: child pid 1140 exit signal Segmentation fault (11), possible core dump in /tmp ]snip] Ugh.. Dumping core? That's rather drastic! What versions of DBI and DBD::mysql are you running? And is DBD::mysql linked against the same mysql client libraries as mod_php? Thanks, Toby DBD::mysql version: 4.008 DBI version:1.607 libapache2-mod-php5 version: 5.2.0-8+etch10 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. Could you humour me, and try disabling PHP in Apache, and then seeing if that stops the Catalyst app crashing? I think you can do it by 'rm /etc/apache/mods-enabled/*php*.load' or something very similar? To check the actual versions of libraries used, you can do: ldd /usr/lib/apache2/modules/mod_php*.so ldd /usr/lib/perl5/auto/DBD/mysql/mysql.so (At least I'm pretty sure that's where the files should be on debian etch) But if you've recompiled dbd::mysql from source, and not mod_php, then I'll bet this IS the problem. Sorry. -Toby -- Strategic Data Pty Ltd Ph: 03 9340 9000 ___ 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
Terence Monteiro wrote: I'm running my Catalyst application on apache2 using modperl with mysql database accessed by DBIx::SearchBuilder. I'm getting the message in the apache2 error logs: child pid 1140 exit signal Segmentation fault (11), possible core dump in /tmp Following are the package versions: apache2 2.2.9-10 apache2-dbg 2.2.9-11 apache2-mpm-prefork 2.2.9-11 apache2-utils 2.2.3-4+etch6 apache2.2-common2.2.9-11 libapache2-mod-auth-pam 1.1.1-6.1 libapache2-mod-auth-sys-group 1.1.1-6.1 libapache2-mod-fastcgi 2.4.6-1 libapache2-mod-perl22.0.4-4 libapache2-mod-php5 5.2.0-8+etch10 libapache2-reload-perl 0.10-2 Catalyst and Perl module versions are: Catalyst5.7014 DBIx::SearchBuilder 1.54 mysql-server-5.05.0.32-7etch5 I did a backtrace, which I posted to the modperl mailing list. One reply said that the cause may be initializing a DB handle at startup and using it in the child process. What needs to be done differently to ensure this does not happen? I am initializing the database connection in a Controller. Is there any problem in this, though it may not be the best design. Will putting the database initialization code in the Model help? I have included the backtrace for your information. Have I missed anything? #0 0xb6038590 in mysql_ping () from /usr/lib/libmysqlclient.so.15 #1 0xb61e9d93 in XS_DBD__mysql__db_ping () from /usr/lib/perl5/auto/DBD/mysql/mysql.so #2 0xb6e03088 in XS_DBI_dispatch () from /usr/lib/perl5/auto/DBI/DBI.so #3 0xb7686975 in Perl_pp_entersub () from /usr/lib/libperl.so.5.10 #4 0xb7684d91 in Perl_runops_standard () from /usr/lib/libperl.so.5.10 #5 0xb767ed08 in Perl_call_sv () from /usr/lib/libperl.so.5.10 #6 0xb774ebfc in modperl_callback () from /usr/lib/apache2/modules/mod_perl.so #7 0xb774f2d3 in modperl_callback_run_handlers () from /usr/lib/apache2/modules/mod_perl.so #8 0xb774f9ca in modperl_callback_per_dir () from /usr/lib/apache2/modules/mod_perl.so #9 0xb77486ef in modperl_response_init () from /usr/lib/apache2/modules/mod_perl.so #10 0xb77488a3 in modperl_response_handler_cgi () from /usr/lib/apache2/modules/mod_perl.so #11 0x0807a179 in ap_run_handler (r=0xa42b298) at /tmp/buildd/apache2-2.2.9/server/config.c:159 #12 0x0807d591 in ap_invoke_handler (r=0xa42b298) at /tmp/buildd/apache2-2.2.9/server/config.c:373 #13 0x0808aff6 in ap_process_request (r=0xa42b298) at /tmp/buildd/apache2-2.2.9/modules/http/http_request.c:258 #14 0x08088128 in ap_process_http_connection (c=0x927c208) at /tmp/buildd/apache2-2.2.9/modules/http/http_core.c:190 #15 0x080815a9 in ap_run_process_connection (c=0x927c208) at /tmp/buildd/apache2-2.2.9/server/connection.c:43 #16 0x0808fc0c in child_main (child_num_arg=) at /tmp/buildd/apache2-2.2.9/server/mpm/prefork/prefork.c:672 #17 0x0808ff63 in make_child (s=0x80ab908, slot=0) at /tmp/buildd/apache2-2.2.9/server/mpm/prefork/prefork.c:769 #18 0x08090d68 in ap_mpm_run (_pconf=0x80a70c8, plog=0x80d9190, s=0x80ab908) at /tmp/buildd/apache2-2.2.9/server/mpm/prefork/prefork.c:904 #19 0x08066f10 in main (argc=Cannot access memory at address 0x0 ) at /tmp/buildd/apache2-2.2.9/server/main.c:732 Ugh.. Dumping core? That's rather drastic! What versions of DBI and DBD::mysql are you running? And is DBD::mysql linked against the same mysql client libraries as mod_php? I've definitely seen that cause segfaults in apache, when perl and php are linked to different versions of the mysql library. -Toby -- Strategic Data Pty Ltd Ph: 03 9340 9000 ___ 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: Use the CPAN, Luke?
Jonathan Rockway wrote: * On Sun, Nov 30 2008, Toby Corkindale wrote: If the automated install fails, people are likely to say "bah, this Perl thing sucks, let's go for that similar app written in PHP/Java/Ruby instead - at least it's simple to install!" Why do you care about what other people do? If these people can't even install a CPAN module, it's unlikely that they were going to become active contributors. Because not everyone is a contributor. In fact, *most* people are not contributors. Contributors come from being users first. If we lose the users, we will lose contributors in the long run, and Perl will disappear. PAR goes a little way to solving this, but then one needs to distribute multiple versions for all the platforms you support, and hope they have a decent PAR version too. (Again, Debian stable has issues.) This says more about Debian than PAR. I know :( But sysadmins seem to love the bloody thing, no matter how ancient and broken its so-called "stable" version is. It needs a tagline, like: "Debian - Stifling innovation since 1993" (Although really, they were quite innovative at first, so that's mean of me. I should point out that I understand that having a consistent, static base is very important to a lot of people.) Toby -- I probably need a .sig that says my opinions are not those of my employers :) ___ 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: Use the CPAN, Luke?
Lars Balker Rasmussen wrote: On Thu, Nov 27, 2008 at 03:55:54AM +0100, Aristotle Pagaltzis wrote: Case in point, Mouse is essentially Moose Light. Since Catalyst itself is becoming Moose-based, is there *any* reason to use Mouse instead? I suppose if it automatically stubs itself into a Moose loader where Moose is available, that would be not *too* bad, but it???s still a pointlessly added dependency. While Data::Visitor depends on Mouse, it actually uses Squirrel (which is in the Mouse dist), which will fall back to the Moose already loaded by Catalyst. I assume most Mouse-users are smart enough to do this. And Data::Visitor isn't just for Catalyst-use, so our problem isn't theirs. It kind of is still our problem, since if one writes an application for Catalyst, one hopes that the intended users can easily install it.. which they can't on supposed "Stable" Linux installs, using Debian, RHEL, etc. If the automated install fails, people are likely to say "bah, this Perl thing sucks, let's go for that similar app written in PHP/Java/Ruby instead - at least it's simple to install!" PAR goes a little way to solving this, but then one needs to distribute multiple versions for all the platforms you support, and hope they have a decent PAR version too. (Again, Debian stable has issues.) Toby ___ 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/
