Re: [Catalyst] Bug in old Advent example of async/websockets code?

2015-02-22 Thread Toby Corkindale
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?

2015-02-22 Thread Toby Corkindale
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?

2013-11-10 Thread Toby Corkindale
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

2013-11-03 Thread Toby Corkindale
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

2013-10-31 Thread Toby Corkindale
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

2013-10-31 Thread Toby Corkindale
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

2013-10-31 Thread Toby Corkindale
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

2013-10-31 Thread Toby Corkindale
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

2013-10-30 Thread Toby Corkindale
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

2013-09-17 Thread Toby Corkindale
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

2013-05-21 Thread Toby Corkindale
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

2013-01-31 Thread Toby Corkindale
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

2012-10-23 Thread Toby Corkindale
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

2012-10-23 Thread Toby Corkindale
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

2012-02-19 Thread Toby Corkindale
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

2012-02-16 Thread Toby Corkindale
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

2011-10-20 Thread Toby Corkindale
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

2011-10-20 Thread Toby Corkindale
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

2011-10-13 Thread Toby Corkindale
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

2011-10-06 Thread Toby Corkindale
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

2011-10-06 Thread Toby Corkindale
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

2011-06-20 Thread Toby Corkindale
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

2011-02-02 Thread Toby Corkindale
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

2011-02-01 Thread Toby Corkindale
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

2011-02-01 Thread Toby Corkindale
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

2011-01-31 Thread Toby Corkindale
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

2011-01-30 Thread Toby Corkindale
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?

2010-12-14 Thread Toby Corkindale
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?

2010-12-12 Thread 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!)

> 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?

2010-12-08 Thread Toby Corkindale
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?

2010-12-06 Thread Toby Corkindale
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?

2010-12-06 Thread 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

___
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

2010-10-21 Thread Toby Corkindale
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)

2010-10-19 Thread Toby Corkindale

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)

2010-10-18 Thread Toby Corkindale

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

2010-10-18 Thread Toby Corkindale

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

2010-10-10 Thread Toby Corkindale

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

2010-10-05 Thread Toby Corkindale

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

2010-08-18 Thread Toby Corkindale

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

2010-07-08 Thread Toby Corkindale

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

2010-07-06 Thread Toby Corkindale

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

2010-06-22 Thread Toby Corkindale

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

2010-06-22 Thread Toby Corkindale

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 ?

2010-04-29 Thread Toby Corkindale

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 ?

2010-04-22 Thread Toby Corkindale

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

2010-04-12 Thread Toby Corkindale

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"?

2010-04-08 Thread Toby Corkindale

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"?

2010-04-08 Thread Toby Corkindale

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"?

2010-04-07 Thread Toby Corkindale
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

2010-04-01 Thread Toby Corkindale

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

2010-03-01 Thread Toby Corkindale

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.

2010-02-28 Thread Toby Corkindale

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?

2010-02-25 Thread Toby Corkindale

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

2010-02-18 Thread Toby Corkindale

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

2010-02-15 Thread Toby Corkindale

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)

2010-01-20 Thread Toby Corkindale

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..

2010-01-19 Thread Toby Corkindale

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..

2010-01-18 Thread Toby Corkindale

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..

2010-01-17 Thread Toby Corkindale

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

2010-01-11 Thread Toby Corkindale

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

2010-01-11 Thread Toby Corkindale
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)

2009-12-14 Thread Toby Corkindale
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

2009-12-14 Thread Toby Corkindale

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

2009-09-29 Thread Toby Corkindale

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

2009-09-29 Thread Toby Corkindale

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

2009-09-29 Thread Toby Corkindale

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

2009-09-28 Thread Toby Corkindale

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

2009-09-28 Thread Toby Corkindale

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

2009-09-28 Thread Toby Corkindale
(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

2009-09-22 Thread Toby Corkindale

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

2009-08-18 Thread Toby Corkindale

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

2009-07-13 Thread Toby Corkindale

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

2009-07-12 Thread Toby Corkindale

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

2009-07-12 Thread Toby Corkindale

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

2009-07-12 Thread Toby Corkindale

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

2009-06-30 Thread Toby Corkindale

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

2009-06-29 Thread Toby Corkindale

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?

2009-06-24 Thread toby . corkindale

- 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

2009-05-31 Thread Toby Corkindale

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

2009-05-31 Thread Toby Corkindale

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?

2009-05-29 Thread Toby Corkindale

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

2009-05-28 Thread 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


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

2009-05-28 Thread Toby Corkindale

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

2009-05-26 Thread Toby Corkindale

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

2009-05-26 Thread Toby Corkindale

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

2009-03-17 Thread Toby Corkindale

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

2009-02-26 Thread Toby Corkindale

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

2009-01-21 Thread Toby Corkindale

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

2009-01-21 Thread Toby Corkindale

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?

2009-01-15 Thread Toby Corkindale

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

2009-01-14 Thread Toby Corkindale

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)

2009-01-12 Thread Toby Corkindale

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)

2009-01-12 Thread Toby Corkindale

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

2009-01-08 Thread Toby Corkindale

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

2008-12-09 Thread Toby Corkindale

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

2008-12-08 Thread Toby Corkindale

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

2008-12-08 Thread Toby Corkindale

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

2008-12-07 Thread Toby Corkindale

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?

2008-11-30 Thread Toby Corkindale

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?

2008-11-30 Thread Toby Corkindale

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/


  1   2   >