[Catalyst] Re: Catalyst 5.800013 - missing dependency version
Marcus Ramberg wrote:
Another day, another Catalyst 5.8 maintainance release. This time,
lucky number 13. The main reason for this release is a change in the
guts of the most recent Class::MOP. Thus, this release depends on the
latest Moose/Class-MOP, see the changelog attached below for details.
There are also some minor documentation/refactoring changes, and
removal of the -short option to catalyst.pl, which generated a
deprecated style Catalyst namespace.
I am running the latest stable versions of Moose/Class-MOP and their
dependencies.
to...@arya:~$ pmvers Moose
0.91
to...@arya:~$ pmvers Class::MOP
0.93
When installing Catalyst::Runtime 5.800013 the tests were (eventually)
successful - however they output a vast amount of warnings from Moose.
The following dump is just the output from a single unit test!
(In this case, t/unit_metaclass_compat_non_moose_controller.t, since it
was the last one in the log that produced the warnings. The following
t/unit*.t ones were quiet.)
However I then upgraded MooseX::Types to 0.20, and the warnings went away.
Thus I'm guessing MooseX::Types needs to have a higher required version
in Makefile.PL?
--
Trying to export undefined sub MooseX::Types::CheckedUtilExports::type
at /usr/share/perl5/Moose/Exporter.pm line 210
Moose::Exporter::_sub_from_package('Moose::Exporter',
'MooseX::Types::CheckedUtilExports', 'type') called at
/usr/share/perl5/Moose/Exporter.pm line 145
Moose::Exporter::_make_sub_exporter_params('Moose::Exporter',
'ARRAY(0x120ad48)', 'HASH(0x120ad18)') called at
/usr/share/perl5/Moose/Exporter.pm line 40
Moose::Exporter::build_import_methods('Moose::Exporter', 'with_caller',
'ARRAY(0x19af398)', 'exporting_package',
'MooseX::Types::CheckedUtilExports', 'install', 'ARRAY(0x120aca0)')
called at /usr/share/perl5/Moose/Exporter.pm line 23
Moose::Exporter::setup_import_methods('Moose::Exporter', 'with_caller',
'ARRAY(0x19af398)') called at
/usr/share/perl5/MooseX/Types/CheckedUtilExports.pm line 48
require MooseX/Types/CheckedUtilExports.pm called at
/usr/share/perl5/MooseX/Types.pm line 15
MooseX::Types::BEGIN() called at
/usr/share/perl5/MooseX/Types/CheckedUtilExports.pm line 0
eval {...} called at
/usr/share/perl5/MooseX/Types/CheckedUtilExports.pm line 0
require MooseX/Types.pm called at
/usr/share/perl5/MooseX/Types/Moose.pm line 12
MooseX::Types::Moose::BEGIN() called at
/usr/share/perl5/MooseX/Types/CheckedUtilExports.pm line 0
eval {...} called at
/usr/share/perl5/MooseX/Types/CheckedUtilExports.pm line 0
require MooseX/Types/Moose.pm called at
/usr/share/perl5/MooseX/MethodAttributes/Role/Meta/Map.pm line 7
MooseX::MethodAttributes::Role::Meta::Map::BEGIN() called at
/usr/share/perl5/MooseX/Types/CheckedUtilExports.pm line 0
eval {...} called at
/usr/share/perl5/MooseX/Types/CheckedUtilExports.pm line 0
require MooseX/MethodAttributes/Role/Meta/Map.pm called at
/usr/lib/perl5/Class/MOP.pm line 129
eval {...} called at /usr/lib/perl5/Class/MOP.pm line 129
Class::MOP::_try_load_one_class('MooseX::MethodAttributes::Role::Meta::Map')
called at /usr/lib/perl5/Class/MOP.pm line 90
Class::MOP::load_first_existing_class('MooseX::MethodAttributes::Role::Meta::Map')
called at /usr/lib/perl5/Class/MOP.pm line 135
Class::MOP::load_class('MooseX::MethodAttributes::Role::Meta::Map')
called at /usr/share/perl5/Moose/Util.pm line 99
Moose::Util::_apply_all_roles('Moose::Meta::Role=HASH(0x193abf8)',
undef, 'MooseX::MethodAttributes::Role::Meta::Map') called at
/usr/share/perl5/Moose/Util.pm line 84
Moose::Util::apply_all_roles('Moose::Meta::Role=HASH(0x193abf8)',
'MooseX::MethodAttributes::Role::Meta::Map') called at
/usr/share/perl5/Moose/Role.pm line 26
Moose::Role::with('Moose::Meta::Role=HASH(0x193abf8)',
'MooseX::MethodAttributes::Role::Meta::Map') called at
/usr/share/perl5/Moose/Exporter.pm line 288
Moose::Role::with('MooseX::MethodAttributes::Role::Meta::Map') called
at /usr/share/perl5/MooseX/MethodAttributes/Role/Meta/Role.pm line 15
require MooseX/MethodAttributes/Role/Meta/Role.pm called at
/usr/share/perl5/MooseX/MethodAttributes/Inheritable.pm line 8
MooseX::MethodAttributes::Inheritable::BEGIN() called at
/usr/share/perl5/MooseX/Types/CheckedUtilExports.pm line 0
eval {...} called at
/usr/share/perl5/MooseX/Types/CheckedUtilExports.pm line 0
require MooseX/MethodAttributes/Inheritable.pm called at
/usr/lib/perl5/Class/MOP.pm line 129
eval {...} called at /usr/lib/perl5/Class/MOP.pm line 129
Class::MOP::_try_load_one_class('MooseX::MethodAttributes::Inheritable')
called at /usr/lib/perl5/Class/MOP.pm line 90
Class::MOP::load_first_existing_class('MooseX::MethodAttributes::Inheritable')
called at /usr/lib/perl5/Class/MOP.pm line 135
Class::MOP::load_class('MooseX::MethodAttributes::Inheritable') called
at /usr/share/perl5/Moose/Meta/Class.pm line 234
Moose::Meta::Class::superclasses('Moose::Meta::Cl
Re: [Catalyst] Catalyst benchmark 5.7 VS 5.8
(Apologies for top-posting.. have momentarily lost the option to change quoting styles it seems..) Fayland, I was looking at the benchmarks that you linked, and was just wondering which version of Perl you're running against? (CentOS 5 was one of the operating systems that came with the badly-patched Perl with the slow bless performance.. although I'm sure it's been patched by now? ie. http://blog.vipul.net/2008/08/24/redhat-perl-what-a-tragedy/ ) Cheers, Toby - Original Message - From: Fayland Lam To: catalyst@lists.scsys.co.uk Sent: Mon, 28 Sep 2009 15:56:36 +1000 (EST) Subject: [Catalyst] Catalyst benchmark 5.7 VS 5.8 I'm wondering if someone here did a benchmark between Catalyst 5.7 and 5.8 here is the result from our server: http://scsys.co.uk:8001/34323 the background is Catalyst 5.7011 VS Catalyst 5.80013 CPU: Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.33GHz RAM: 4G OS: Centos5 from the top, each httpd takes 20M more RAM in 5.8 compared with 5.7 5.7 PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 22979 apache16 0 167m 142m 4248 S 17.0 3.5 0:06.07 httpd 5.8 PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 24813 apache15 0 190m 165m 4000 S 15.6 4.1 0:02.56 httpd in this case, I really can't let my boss agree me to upgrade the Catalyst. is it normal? any thoughts? Thanks. -- Fayland Lam // http://www.fayland.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst benchmark 5.7 vs 5.8 - new test
Fayland Lam wrote: I'm wondering if someone here did a benchmark between Catalyst 5.7 and 5.8 I have a vested interest in knowing the difference between the two versions as well, so knocked up a "proper" test. I have two identical virtual machines, only on one I installed Catalyst::Runtime 5.71001 and the other with 5.80013. Running the exact same app, I hit them up with Siege for a while, results follow at the end of this email. If you want to replicate the test or examine my extremely-simple test app, see: http://github.com/TJC/Catalyst-Performance-Test (Patches gleefully accepted ;) It's interesting to note the headline figures have 5.71 performing 316 tps, vs 5.80 making only 283 tps. Memory usage (for this small app) has increased by 4MB, but is presumably shared. I guess I should look into that more. The same system can serve small static pages from the webserver at about 1900 tps. A real-world application there on Cat 5.8 gets 90 tps. I don't see that performance difference (5.71 vs 5.80) as significant, since most of your time ends up being spent in application code, rather than the Catalyst framework itself. ie. If you want to make your code go faster, look at optimising your templating and database queries before you worry about downgrading Catalyst. -Toby --= results =-- Running 10 second warmup on 5.7.. Running main test on 5.7.. Transactions: 94796 hits Availability: 100.00 % Elapsed time: 300.00 secs Data transferred: 77.35 MB Response time: 0.03 secs Transaction rate: 315.99 trans/sec Throughput: 0.26 MB/sec Concurrency: 10.00 Successful transactions: 94796 Failed transactions: 0 Longest transaction:0.98 Shortest transaction: 0.00 Process size: 101m VIRT, 34m RES Running 10 second warmup on 5.8.. Running main test on 5.8.. Transactions: 84805 hits Availability: 100.00 % Elapsed time: 300.00 secs Data transferred: 69.20 MB Response time: 0.04 secs Transaction rate: 282.68 trans/sec Throughput: 0.23 MB/sec Concurrency:9.99 Successful transactions: 84805 Failed transactions: 0 Longest transaction:1.07 Shortest transaction: 0.00 Process size: 103m VIRT, 38m RES ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst benchmark 5.7 vs 5.8 - new test
Toby Corkindale wrote: It's interesting to note the headline figures have 5.71 performing 316 tps, vs 5.80 making only 283 tps. Memory usage (for this small app) has increased by 4MB, but is presumably shared. I guess I should look into that more. Here are some new analysis of memory usage on my test app. 5.7 5.8 Rss: 35260 38768 Private: 82449620 Shared: 27016 29148 So 5.8 is 3500kB larger, but 2000kB is shared. So we're only looking at 1500Kb more per process. -Toby ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst benchmark 5.7 vs 5.8 - new test
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
Carl Johnstone wrote: Toby Corkindale wrote: (CentOS 5 was one of the operating systems that came with the badly-patched Perl with the slow bless performance.. although I'm sure it's been patched by now? ie. http://blog.vipul.net/2008/08/24/redhat-perl-what-a-tragedy/ ) Was patched last year - stop spreading FUD. OK, well do you want to get CentOS to close the bug on it then? :P http://bugs.centos.org/view.php?id=2357 (I sent an email to some CentOS-using friends asking them what's up and I see they added a note to the bottom of the bug just yesterday..) For those of us not using Centos, but helping others, we can only go on what we read. It IS the official bugtracker for centos, isn't it? If we can't trust it, what CAN we trust?) The RHEL/CentOS perl build isn't the best one is the world but it's adequate enough for most uses. Too much FUD will just scare decision makers who don't understand the technical details and just see perl + RHEL = fail. Well, that pretty much WAS the case for quite a long time :( Glad to hear it's finally fixed up though. tjc ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst benchmark 5.7 vs 5.8 - new test
Tomas Doran wrote: Toby Corkindale wrote: It's interesting to note the headline figures have 5.71 performing 316 tps, vs 5.80 making only 283 tps. The very important thing you haven't noted (unless I missed it) is what perl version this benchmark was conducted under. 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/
[Catalyst] Cat-Runtime 5.8.16 broke with catalyst_par
Hey guys,
Catalyst::Runtime 5.80016 introduced a bug with catalyst_par.
Various modules are now required for the scripts in /script/, however
when building your application with "make catalyst_par" these are not
included.
Temporary fix is to add to Makefile.PL:
catalyst_par_classes('Catalyst::ScriptRunner');
catalyst_par_classes('Catalyst::Script::FastCGI');
..etc..
-Toby
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
[Catalyst] Catalyst::Script::FastCGI ignores --daemon option (internally it is --detach)
As of Catalyst::Runtime 5.8.16, Catalyst::Script::FastCGI is buggy and ignores the --daemon option. Looking at the source, I think it is mistakenly looking for --detach, although it is documented as wanting --daemon. -Toby ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] [ANNOUNCE] Catalyst-Runtime 5.80017
Has anyone else had trouble getting this installed, due to the dependency on Class::MOP 0.97? I can't get class mop to install in my local lib - keeps dying with: Not a HASH reference at /usr/share/perl/5.10/ExtUtils/Install.pm line 557. make: *** [pure_site_install] Error 2 I'll report back on whether the "make catalyst_par" bug from 5.8.16 is still present once I get it installed.. ta, Toby Florian Ragwitz wrote: I'm happy to announce the next release of Catalyst-Runtime (5.80017). This release mainly cures all issues reported with upgraded scripts (or applications generated with the latest release of Catalyst::Devel) and makes Catalyst compatible with upcomming versions of Moose. This release also started being more strict about the deprecated usage of NEXT. We're not surpressing any Class::C3::Adopt::NEXT warnings anymore. See the changelog for details. Full changelog included below as always. Cheers rafl -- 5.80017 2010-01-10 02:27:29 Documentation: - Fix docs for ->forward method when passed a class name - this should be a component name (e.g. View::HTML, not a full class name, like MyApp::View::HTML). Bug fixes: - --daemon and -d options to Catalyst::Script::FastCGI are fixed. - Fix the debug dump for applications which use Catalyst::Plugin::Session (RT#52898) - Fix regression in the case where mod_rewrite is being used to rewrite requests into a path below your application base introduced with the %2F related fixes in 5.80014_02. - Do not crash on SIGHUP if Catalyst::Engine::HTTP->run is not passed the argv key in the options hash. - Correctly pass the arguments to Catalyst::Script::Server through to Catalyst::Engine::HTTP->run so that the server can restart itself with the correct options on SIGHUP. - Require new MooseX::MethodAttributes to be compatible with Moose versions >= 0.93_01 - Require new MooseX::Role::WithOverloading to be compatible with Moose versions >= 0.93_01 Cleanups: - Stop suppressing warnings from Class::C3::Adopt::NEXT now that most plugins have been updated to not use NEXT. If you get warnings then please upgrade your components or log a bug with the component author if an upgrade is not available. The Class::C3::Adopt::NEXT documentation contains information about how to suppress the warnings in your application if you need to. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ -- Strategic Data Pty Ltd Ph: 03 9340 9000 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst::View::JSON sends a file
Tomas Doran wrote: On 11 Jan 2010, at 23:29, Christoph Friedrich wrote: just worked a little with Catalyst::View::JSON. But when I call some action via Firefox that uses this View Firefox gives me a file to download and don't show the json directly. Is there a way to change this behavior? I want to see what I would get as JSON and not download it ^^ Your browser will do whatever it normally does with the mime type you're sending. By changing settings or mime types you'll probably be able to convince it to display the JSON. You could also adjust the $c->response->content_type() to be 'text/plain'. But watch out, as some javascript libraries decide what to do with the response based on it's content-type, and will not JSON-decode what it thinks is html or plain text. However, why not write a JSON debug view that pretty prints JSON responses inside an HTML page? Definitely the better option. Or learn to get into the Firefox or Chrome javascript debuggers.. well worth having that skill. Toby ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Enabling debug mode with fastcgi..
Hi guys, If you're running a Catalyst app with the fastcgi script (as found in scripts/myapp_name_fastcgi.pl), then is there a way to enable the debug mode. (eg. like running scripts/myapp_server.pl -d) I've tried setting CATALYST_DEBUG and MYAPP_DEBUG in the shell environment, but that doesn't seem to work. Either that or else fastcgi is discarding the output somewhere in our case. (I've messed with the -keeperr option too) Cheers, Toby ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Enabling debug mode with fastcgi..
On 19/01/10 06:54, Adam Mackler wrote: Hi Toby: The output might be going to your web server log. Try starting your fastcgi script with a -e option (with CATALYST_DEBUG set as well). Looking at the previous posts that Wallace directed me to, it sounds like the debug options with fastcgi have been a little broken for some time now.. As I said, I've tried the -e (same as -keeperr) options in combination with the *_DEBUG environment variables. I have a vague recollection of having this trouble before, and resorting to overriding Catalyst::Log to send things to syslog or a standalone log file. (The front-end apache servers aren't logging any catalyst debug output anywhere; possibly this is a config error there, or possibly intentional on the part of sysadmins - however either way it's not something I'm about to change.) Hmm, thanks for looking guys. For what it's worth, or anyone reading this in the archives in the future - this is still on Catalyst Runtime 5.8.16. (.17 was busted, .18 doesn't work out of the box in our environment due to some of the changes and so isn't considered production ready by us just yet.) So I'm not sure if the new Cat ScriptRunner code will have fixed the issue there. cheers, Toby. On Mon, Jan 18, 2010 at 05:03:23PM +1100, Toby Corkindale wrote: Hi guys, If you're running a Catalyst app with the fastcgi script (as found in scripts/myapp_name_fastcgi.pl), then is there a way to enable the debug mode. (eg. like running scripts/myapp_server.pl -d) I've tried setting CATALYST_DEBUG and MYAPP_DEBUG in the shell environment, but that doesn't seem to work. Either that or else fastcgi is discarding the output somewhere in our case. (I've messed with the -keeperr option too) Cheers, Toby ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Enabling debug mode with fastcgi..
On 19/01/10 21:45, Tomas Doran wrote:
On 19 Jan 2010, at 00:26, Toby Corkindale wrote:
As I said, I've tried the -e (same as -keeperr) options in combination
with the *_DEBUG environment variables.
That should (and does) work here..
Hmm. That's interesting to know.. I swear it isn't working on the
machines I was testing this on the other day. Many things are old on
them, so maybe it's something in a fastcgi library or other.
I'll investigate some more.
(The front-end apache servers aren't logging any catalyst debug output
anywhere; possibly this is a config error there, or possibly
intentional on the part of sysadmins - however either way it's not
something I'm about to change.)
Yeah, that's got to be config of some sort, Catalyst does log down the
fcgi socket by default..
For what it's worth, or anyone reading this in the archives in the
future - this is still on Catalyst Runtime 5.8.16.
(.17 was busted, .18 doesn't work out of the box in our environment
due to some of the changes and so isn't
considered production ready by us just yet.)
I don't see a bug report for this anywhere? Did I miss it?
"make catalyst_par" doesn't produce a working PAR, as the
Catalyst::ScriptRunner modules is not included inside the PAR.
Introduced in 5.8.17. Reported 15 Dec 2009.
Temporary fix is to add to Makefile.PL:
catalyst_par_classes('Catalyst::ScriptRunner');
catalyst_par_classes('Catalyst::Script::FastCGI');
..etc..
but of course if you do that, the package will fail to build on older
pre-version-17 setups, and I didn't really want to get into the
Makefile.PL complexity of optionally including them based on revisions
of modules..
Cheers,
Toby
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
[Catalyst] [PATCH] C-P-UploadProgress (converted away from NEXT)
Hey Andy, and general Catalyst guys.
Attached is a patch to convert Catalyst::Plugin::UploadProgress into
using Moose::Role instead of NEXT, since the latter is deprecated as of
Cat-Runtime .18.
Could you have a look over it? I'm not 100% sure the first function is
"good" since it's never calling super() from inside prepare_body_chunk.
But hey, that's just how the original code worked too..
Cheers,
Toby
>From 95e1d77a555dcc1caae2ab29cbbd843450e8e337 Mon Sep 17 00:00:00 2001
From: Toby Corkindale
Date: Thu, 21 Jan 2010 15:59:03 +1100
Subject: [PATCH] Remove NEXT, replace with Moose::Role
---
lib/Catalyst/Plugin/UploadProgress.pm | 32 +---
1 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/lib/Catalyst/Plugin/UploadProgress.pm b/lib/Catalyst/Plugin/UploadProgress.pm
index ee97eb3..c0910f3 100644
--- a/lib/Catalyst/Plugin/UploadProgress.pm
+++ b/lib/Catalyst/Plugin/UploadProgress.pm
@@ -2,11 +2,12 @@ package Catalyst::Plugin::UploadProgress;
use strict;
use warnings;
-use NEXT;
+use Moose::Role;
-our $VERSION = '0.04';
+our $VERSION = '0.10';
-sub prepare_body_chunk {
+# I'm concerned that this doesn't call super() at all..
+override 'prepare_body_chunk' => sub {
my ( $c, $chunk ) = @_;
my $body = $c->request->{_body};
@@ -33,9 +34,9 @@ sub prepare_body_chunk {
$c->cache->set( 'upload_progress_' . $id, $progress );
}
}
-}
+};
-sub prepare_body {
+override 'prepare_body' => sub {
my $c = shift;
# Detect if the user stopped the upload, prepare_body will die with an invalid
@@ -49,7 +50,7 @@ sub prepare_body {
$croaked = shift;
};
-$c->NEXT::prepare_body(@_);
+super;
}
if ( $croaked ) {
@@ -67,9 +68,9 @@ sub prepare_body {
# rethrow the error
Catalyst::Exception->throw( $croaked );
}
-}
+};
-sub dispatch {
+override 'dispatch' => sub {
my $c = shift;
# if the URI query string is ?progress_id= intercept the request
@@ -79,20 +80,18 @@ sub dispatch {
return $c->upload_progress_output( $1 );
}
-return $c->NEXT::ACTUAL::dispatch(@_);
-}
+return super;
+};
-sub setup {
+after 'setup' => sub {
my $c = shift;
-$c->NEXT::setup(@_);
-
unless ( $c->can('cache') ) {
Catalyst::Exception->throw(
message => 'UploadProgress requires a cache plugin.'
);
}
-}
+};
sub upload_progress {
my ( $c, $upload_id ) = @_;
@@ -279,6 +278,9 @@ JSON output from C.
Andy Grundman,
+NEXT to Moose::Role conversion by Toby Corkindale, , blame him
+for any faults there..
+
=head1 THANKS
The authors of L, for the progress.js and
@@ -292,4 +294,4 @@ progress.css code:
This program is free software, you can redistribute it and/or modify it under
the same terms as Perl itself.
-=cut
\ No newline at end of file
+=cut
--
1.6.6
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] FastCGI deployment - slow to complete request
On 15/02/10 15:59, Steve Rippl wrote: Hi, I have a small Catalyst app, the production version of which has been running pretty well using the built in server as there haven't been too many user at once. I'm trying to anticipate higher concurrent usage and switch to FastCGI (as that seems to be recommended in the book) and I have the following running in Apache FastCgiServer /srv/WsdSis/script/wsdsis_fastcgi.pl -processes 5 Alias / /srv/WsdSis/script/wsdsis_fastcgi.pl/ ServerName sis.woodlandschools.org ServerAdmin webmas...@woodlandschool.org DocumentRoot /srv/WsdSis/root Alias /static /srv/WsdSis/root/static Now this works, it's serving up the application, but each request is really slow to complete! The obvious effect of this is that a page with JavaScript waiting for a complete page before it does it's thing looks dreadful for a while, the html has arrived but the browser is still spinning, then eventually the page completes and the JS runs. (I know about graceful failure for JS, but I have an app that is going to depend on it!). If I switch this back to the built in server then the page is completed faster than I can notice and the page renders correctly immediately. Back on FastCGI and even a simple page request is taking ~10 seconds to complete (again, that html arrives straight away, but then the browser keeps spinning as if it's still waiting on something). This is running on a Debian 5 machine using libapache2-mod-fastcgi. You can get good performance out of catalyst by just running the PREFORK standalone server*, with a reverse-proxy cache sitting in front of it. (eg. Varnish http://varnish-cache.org/) [* http://search.cpan.org/dist/Catalyst-Engine-HTTP-Prefork/ ] I've never been satisfied by either of the FastCGI implementations available to Apache. I do like the one for Lighttpd, but some other aspects of lighty can be annoying. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] [ANNOUNCE] Catalyst::Manual 5.8004
On 19/02/10 04:30, hkcl...@gmail.com wrote: Hi Everyone, Just wanted to let everyone know that I pushed an updated Catalyst Manual to CPAN yesterday. Almost all of the changes pertained to the tutorial. A big thanks to Caelum for doing most of the SQLite foreign key work. Also thanks to xenoterracide for a variety of edits to early chapters. "Full" set of changes listed below (with a summary of prior changes below that). Thank you, I really appreciate it when developers spend time improving documentation. So much that I'll say thanks twice. :) Thanks, Toby ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] on the topic of PAR file distribution, why is it frowned upon?
On 26/02/10 11:27, Tommy Butler wrote: Hello all, I will be deploying a catalyst app onto several dozens of servers in the next months, which will probably turn into more than that eventually. It is a year in the making, and quite complex in terms of all the things it requires to run (libraries). Given that, a PAR distribution file seems like a great way to go. Yet my co-worker told me that this has been frowned on as of late-- that there has been a shift in opinion about deploying cat apps as PARs. What's the downside of this? How is this going to pose a problem for me? Installing from subversion and then CPANning all the required libs into the system via the makefile is terribly slow and error prone. There's an obvious negative there. What's the negative with using PAR when compared to this other method of deployment? The main problems are that PAR doesn't actually work very well. Firstly, it is severely broken on perl 5.10.0, so you'll either need to stick with perl 5.8.x or go to perl 5.10.1. (Or backport fixes from perl 5.10.1 to .0, but there lies insanity.) Secondly, PAR is a nightmare. It's meant to automatically locate all your dependencies, but in practice this never finds all of them. Eg. Building a catalyst_par for a fastcgi-based app is broken out of the box. (It doesn't pick up Catalyst::ScriptRunner) So you'll need to go through a long cycle of * build par * attempt to run it, and discover which modules are missing * add those modules to list of extras * Repeat. A lot. You'll also need to explicitly list all the /var/lib/* things you need, like libpq.so, libxml.so, etc as those aren't picked up.. and all their dependencies manually too. I really don't like deployment methods that are based on trial-and-error. It doesn't give me any confidence that we did manage to find all the extra modules to list as inclusions.. and so you can bet that there's one more missing, that won't be discovered until your app is crashing in production. So, there are some negatives for PAR. The question is, do they outweigh the negatives for using CPAN to install random, latest-and-possibly-broken packages via the Makefile every time? Some shops have a rule that you must only use the versions of modules that are available pre-packaged for the operating system. This gets around the problems of having to install everything by hand, and also means you get consistent versions of modules.. However it also means you're stuck with a small subset of CPAN, and usually very old versions as well. (For eg, Debian is still on Catalyst 5.7 I believe.) My own solution was a fourth option: Build your own Perl, and all the required modules, installed into a custom directory - and then ship this with your application. It'll blow the size out by a hundred meg or so, but at least you know it'll work, and it's using known-good versions of CPAN modules. -Toby ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] on the topic of PAR file distribution.
On 26/02/10 13:04, Tomas Doran wrote: On 26 Feb 2010, at 01:34, Toby Corkindale wrote: On 26/02/10 11:27, Tommy Butler wrote: What's the downside of this? How is this going to pose a problem for me? Installing from subversion and then CPANning all the required libs into the system via the makefile is terribly slow and error prone. There's an obvious negative there. What's the negative with using PAR when compared to this other method of deployment? [snip] Secondly, PAR is a nightmare. It's meant to automatically locate all your dependencies, but in practice this never finds all of them. Eg. Building a catalyst_par for a fastcgi-based app is broken out of the box. (It doesn't pick up Catalyst::ScriptRunner) Patches to require the appropriate modules in Catalyst.pm so that Catalyst does work out the box would be welcome. Is requiring the modules in Catalyst.pm the correct way to do this? I was thinking it'd be in Module::Install::Catalyst, with some automatically-added -M options to par. Speaking of M-I-C, is there a good reason why STDERR is redirected to /dev/null, as well as __WARN__? I ask, because it makes debugging catalyst_par builds a PITA.. I always go in and edit MIC to undo that stuff now, and can't see a good reason not to take it out. I tried to fix this (and made a branch which you'll find in our svn), but this just made PAR shit itself on my mac, and given I'm not a PAR user and nobody else was showing any interest, I gave up. If there is an active PAR user out there who would like to get this fixed - come chat to someone in #catalyst-dev, as that can totally happen. I'm trying to checkout the git repo, but despite following http://wiki.catalystframework.org/wiki/contrib I am getting an error when trying to clone http://git.shadowcat.co.uk/catagits/Catalyst-Devel.git Is the contrib page out of date perhaps? The gitweb still seems to work, but I can't clone from it. ta, Toby ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] KiokuDB, MongoDB and the NoSQL thing
On 02/03/10 17:07, S.A. Kiehn wrote: I have a couple of production Catalyst/DBIx::Class sites on Debian stable, and then on my personal hobby site I use local::lib to try out new things. Recently I split out my users for this site into a separate model and I thought it a good exercise to learn and use KiokuDB. It was just a couple of simple objects, users & roles, but I believe I have a better understanding of how a schema-less data model would work. All I do are lookups based on ID or indexed object values, but doing any type of ordering by dates or titles is a mystery. It seems that the Search::GIN is to provide this sort of functionality, but it is under-documented and has not had an update for awhile. I do not see many posts regarding uses of KiokuDB within Catalyst so I was curious about the opinion of the community in regards to its usage. Is it still to early within development? Also, I have been reading more about the increase in the NoSQL interest, with a particular interest in the MongoDB database (it seems to be similar in some respects to KiokuDB), but I do not find Perl people in the discussion as much as others (Ruby, PHP). Are there developers in the Catalyst community who lean toward NoSQL concepts over traditional RDMS's, or is best to view as a tool to use at times? How about MongoDB? Am I being suckered by another bandwagon? Also Apache CouchDB. I'm curious to know how these things work out for what I see as "real world" cases, where you do actually want to do searches on correlated data. For instance, say you wanted to make a phpbb-style forum. You have several forum areas, and within each there are many threads, each containing many posts. Would every post in a thread be a new document, or would the entire thread be one big document? How would they be linked to the forums, by an ID in the document, or do we get into some kind of mega-document encapsulating everything on the board? Say I wanted to do a search for all posts made by users named John in the forum called Linux, what would the syntax look like? cheers, Toby ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Distributing and updating Cat apps
On 30/03/10 19:32, Tomáš Znamenáček wrote: Hello! I have a Catalyst application that I would like to upload from the development box to the production server. Is there some kind of best practice to do that? My requirements: 1) The process should take care of the dependencies and run the tests before installing. (Let’s say the deps are declared in Makefile.PL or Build.PL.) 2) It would be nice to keep the application isolated in one directory so that I can keep several instances under the same account to do primitive staging. Right now I am updating the application using Git. I push from the development box to a headless repository on the production server and there is a hook that updates the working copy. This fails (1). I’ve read something about local::lib, but I’m still not sure about how to put things together. This has to be a common scenario, isn’t it? When you are finished updating the development version, what do you call to upload the update to the production server and what exactly happens along the way? We package things up into Debian-style packages, and then upload those to a local repository of packages. Then servers can just be updated using the standard system tools (apt). This works quite well. You have a choice of either packaging up every single Perl dependency into a Debian package too (which is a world of pain), or installing all your dependencies into a local directory that you ship with the application. I recommend the latter.. (you'll still need to include dependencies on things like the C libraries for your database client, etc though, in the debian control file.) ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Outcome of the "Security issue with hashed passwords in C:P:A:Password"?
So, a while back there was some.. slightly heated.. discussion about security issues with C-P-A-Password.. or perhaps one of the modules it uses internally.. in certain cases, if certain options are, or are not, set. Then it quietened down without any apparent conclusion being reached. Now that some time has passed, I wondered if someone could provide a synopsis of the outcome of these investigations and discussions? In short: * In what circumstances was an attack possible? ie. What combination of modules, options, auth methods. * Which versions were vulnerable, and if any, at what version were they fixed, if any? * What mitigating factors can be applied to existing systems to reduce their vulnerability to the attack? Thanks, Toby ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Outcome of the "Security issue with hashed passwords in C:P:A:Password"?
On 08/04/10 16:21, Andrew Rodland wrote: * In what circumstances was an attack possible? ie. What combination of modules, options, auth methods. * You use Catalyst::Authentication::Credential::Password. * With the "hashed" password_type. * And your database is compromised. I'd like to follow up that last point, regarding the DB being compromised. Is that definitely a requirement for the vulnerability? I ask because, in many cases, if your DB is compromised, then the horse has already bolted. I understand that isn't the case for everyone, such as payment processors, online shops, etc. where actions can be carried out by logged in users that cause external effects.. but in some cases, the database IS the website, and if you've stolen it, then there's no point logging in as another user artificially. But, yes, it's still worth looking into fixing then I think. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: Outcome of the "Security issue with hashed passwords in C:P:A:Password"?
On 08/04/10 22:49, Daniel Pittman wrote: Toby Corkindale writes: On 08/04/10 16:21, Andrew Rodland wrote: * In what circumstances was an attack possible? ie. What combination of modules, options, auth methods. * You use Catalyst::Authentication::Credential::Password. * With the "hashed" password_type. * And your database is compromised. I'd like to follow up that last point, regarding the DB being compromised. Is that definitely a requirement for the vulnerability? Unless you are passing the hashed passwords around as authentication tokens, yes. Plus, at that point you have already lost. I ask because, in many cases, if your DB is compromised, then the horse has already bolted. I understand that isn't the case for everyone, such as payment processors, online shops, etc. where actions can be carried out by logged in users that cause external effects.. but in some cases, the database IS the website, and if you've stolen it, then there's no point logging in as another user artificially. ...but your lost database *also* exposed user account/password pairs, which can now be tried against other services, since people usually use the same weak password and username all over the place. .. if they are using sufficiently weak passwords, such that they're present in a rainbow table? (Or do such rainbow tables contain every single possible SHA-1 value, ie. from random-looking strings that happen to correspond to the same sha-1 as the actual password?) From the app-dev perspective, though, you already lost. :) But, yes, it's still worth looking into fixing then I think. *nod* Unix did, decades back, for much the same reasons other people have given here. Daniel Although Unix had the problem that the /etc/passwd file was visible to all users on the machine, prior to the introduction of the shadowed version, and thus anyone could try and brute-force the password hashes. In most (all) websites today, the authentication database is not user-visible. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Distributing and updating Cat apps
On 09/04/10 23:11, Bill Moseley wrote: On Thu, Apr 1, 2010 at 12:51 AM, Toby Corkindale We package things up into Debian-style packages, and then upload those to a local repository of packages. Then servers can just be updated using the standard system tools (apt). Hi Toby, This is really the direction I'm heading now (although it's looking like CentOS and RPMs). Can you answer a few general questions? Are you using Template Toolkit? How (or really where) are the templates managed? Where do they get installed, how does the TT View know where to find them, etc? Do they end up in /usr/share// for example? Yes, I'm using Template Toolkit, although due to the apparently-unfixable crashes in the XS stash, I've also built some packaged with Template Alloy too. I just put my templates into the 'root' directory, as per the Catalyst standard layout. After installation, they end up under your distro's Perl directory, in site_perl or vendor_perl, under a 'root' directory in your Module's namespace. Eg. if you have MyApp.pm, then your templates end up in /site_perl/5.10.1/MyApp/root/ I'm sure you never have to roll-back a release, but I also assume you are prepared to roll-back if needed. How does that process work? If you're using the Debian tools, then you can specify a version number when giving a package to "upgrade", which can also be used to downgrade. (This requires you to configure your company's local .deb package repository to hang on to N many old versions; how many for N is up to you.) The debian tools seem really quite good at noticing if you've, say, made changes to the local configuration file for your app, but that there are also changes to it coming down in the new version, and it'll prompt you about this. It's worth noting that by default, the debian package tools will put your myapp.conf into site_perl/5.10.1/MyApp/ as well.. I dislike this, and so over-ride the debian/rules file to move it into /etc/ where it makes more sense. What about your static content (css, js, images)? Where do those get installed? As above, under site_perl; however you can override this in the debian/rules files to put it in /var/www/ or somesuch; I'm lazy and tend to just use Static::Simple; if you have a reverse proxy in front of your app (as you should if performance is a concern) then you can just cache the static stuff there instead. Any special tricks when using an app in "development" vs. production? (For example, under "dev" I use source css, js, but otherwise the app uses combined and compresses css and js. When in development, I run it on a different server altogether, and do not have it installed into the global perl path at all. And I run it with the "myapp/script/myapp_server.pl" rather than via a standalone webserver+appserver(+ optional proxy) stack. For your example, I would put the command to combine-and-compress the CSS and JS into the debian/rules file. However you need a staging server which mirrors the production environment and stack in order to properly test it prior to release. You have a choice of either packaging up every single Perl dependency into a Debian package too (which is a world of pain), or installing all your dependencies into a local directory that you ship with the application. I recommend the latter.. (you'll still need to include dependencies on things like the C libraries for your database client, etc though, in the debian control file.) We are doing a mix. But, for the most part we are creating single modules (packages). Mostly that was to encourage inclusions of unit tests and just more fine-grained management. But, it is more work, true. I disliked having to use the relatively primitive and time-consuming Debian/Gentoo/RedHat tools to manage CPAN modules, when CPANPLUS exists. Why use a plastic trowel when you have a pneumatic digger available? :) I should point out that this does then require keeping the entire installed Perl tree in source control though, so that one can tag exactly which modules were used (and bundled with) an application. Toby ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: Alternatives to Catalyst ?
On 23/04/10 09:10, Lyle wrote: Aristotle Pagaltzis wrote: You should switch to PHP. PHP is pronounced "poop", and there is far too much poop on the web already. There's also too much noise and not enough signal on the mailing list. Can we all try and resist cheap shots, name-calling, me-too's and other childish behaviour on here? ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
On 29/04/10 19:06, Oleg Pronin wrote: Maybe it is not the bottleneck, but how many places do we have like this that are "not a bottleneck" ? maybe the sum of all these "mini" mistakes is the bottleneck ? Hi Oleg, Do you have an application which *has* a bottleneck at the moment? If so, can you demonstrate it? Quite a lot of people on this list are trying to tell you that Catalyst runs some very big sites quite successfully, and my own experience backs that up. Whenever I've hit a bottleneck in a site, it has turned out to be: * Database calls (usually with expensive queries) * Poorly designed TT templates * Stupid blocking calls in a controller (eg. sleep, system, waitpid, etc) * Network bandwidth But NOT the speed of accessor methods in Catalyst. They really are not an issue. If you *do* have a performance issue yourself, then please feel free to bring up a specific example, but otherwise, quit worrying. If you are concerned that you're not squeezing the absolute most performance out of every clock cycle on your CPU, then you should go back to coding in raw assembler instead of Perl, but it's not worth hassling us about. Cheers, Toby ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Contributing code
On 22/06/10 00:19, Ævar Arnfjörð Bjarmason wrote: On Mon, Jun 21, 2010 at 13:48, Sir Robert Burbridge wrote: Out of a discussion last week, I have some code to contribute (largely to Catalyst::Helper). Two quick questions: 1) I've never contributed code to a project outside my work before. How do I go about it? Have you read http://wiki.catalystframework.org/wiki/contrib ? I think I asked about this last time (to great silence), but.. what's the correct base path for the Git repos there? ie. git clone http://git.shadowcat.co.uk//Catalyst-Devel.git ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Contributing code
On 23/06/10 01:03, Tomas Doran wrote: On 22 Jun 2010, at 08:55, Toby Corkindale wrote: I think I asked about this last time (to great silence), but.. what's the correct base path for the Git repos there? ie. git clone http://git.shadowcat.co.uk//Catalyst-Devel.git Like the CPAN search page says, it is git://git.shadowcat.co.uk/catagits/Catalyst-Devel.git (from http://search.cpan.org/dist/Catalyst-Devel/) Cheers - can I suggest that URL is added to the Contributing Code wiki page that was originally linked in this email thread? ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] FastCGI caching issue
On 07/07/10 07:35, Steve wrote: The reference to $cachetime was found on the Catalyst Wiki: http://wiki.catalystframework.org/wiki/adventcalendararticles/2007/11-making_your_catalyst_app_cache-friendly In that instance, it's a variable used in some example code - it only has any meaning within that example. If you're using that whole end() block, then cool, but just setting $cachetime=0; on its own won't do anything. The way you put it, it sounds like you're considering doing that. I'd say it shouldn't be your first concern; everyone else tends to have things like forms and pages work fine without needing to tweak that - browsers already have some smarts in them to try and avoid caching dynamic data. As of my last post, I had not implemented/acted on the $cachetime, but since then I've successfully set the http response header 'Cache-Control' to 'no-cache'. This has not solved the problem - Yes, I restarted my httpd server. At present, my cohort and I suspect that we are up against a database caching problem, but haven't completely ruled out anything. Am I better off asking the DBIC list? Well, you haven't told us a whole lot about what the problem is, so it's hard for us to agree or disagree with your diagnosis. I'm still a little confused/concerned by your comment that "my session seems to 'cross' over to other fastCGI processes"; it sounds a bit like you are misunderstanding what the session is *meant* to do, and thus, perhaps the problem lies there. Run your app with Debug mode enabled, and watch the logs - you will be able to see if you're hitting the app, or getting a cached copy. If you add some debug statements in your form handling, you can also see what data you're getting back from the database. You might also want to enable DBIC_TRACE in your environment, to get a /lot/ of SQL dumped out too. Best of luck, Toby Steve On 7/6/2010 4:23 PM, Tomas Doran wrote: On 6 Jul 2010, at 19:26, Steve wrote: however my session seems to 'cross' over to other fastCGI processes (I've got 3 fastCGI processes running). Yes, they'll do that. I've googled around and even tried to set $cachetime = 0 in my Root.pm controller's END action. Er, what is $cachetime? What are you expecting it to effect. Can anyone point me in the direction of a fix? If I've not provided enough background info let me know and I'll expand. Please expand. If you suspect code, please attach code. Cheers t0m ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Handling expired sessions gracefully
On 09/07/10 00:53, Steve wrote:
I've looked in the archives and tutorials but can't seem to find
examples of handling expired sessions gracefully. I'm admittedly weak in
the area of error checking, but I'm working on it :) Here are my questions:
In what controller (Root.pm or MyApp.pm) and action should I check for
an expired session? Should I check $c->user_exists or
$c->session_expired (not sure if I have the correct accessor)? Once
detected, do I forward, redirect, etc.?
How about something like this?
sub auto :Private { # or the head of your chain
my ($self, $c) = @_;
if (not $c->user_exists) {
$c->stash->{destination} = $c->request->path;
$c->detach('/login');
}
}
Then in your login method, redirect them back to {destination} if they
successfully authenticate; make sure to validate the path though, to
avoid exploits. (eg. Another site crafting a redirect link like
http://yoursite.com/login?destination=/confirm_payment/to/evil/hacker)
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
[Catalyst] Ann: Cat-Auth-Credential-YubiKey
Hi, I've created a Catalyst::Authentication module that supports Yubico's YubiKey system. It's uploaded to PAUSE, so should be hitting CPAN mirrors soon as Catalyst::Authentication::Credential::YubiKey Info on the YubiKeys is available at http::/yubico.com/ They're a USB key that provides one-time-passwords; you can either use Y's own webservice, or you can download and run your own system internally. Cheers, Toby ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst and FormBuilder vs. IExplorer 8
On 06/10/10 14:00, will trillich wrote:
Short version: Catalyst/Formbuilder uploads work fine in firefox and
chrome, works fine in IE 6... but not IE 8, where it throws an "object
expected" error.
Ugh, I hit this a little while ago, but have forgotten the details already.
I think you are looking in the right direction with the "this" though;
try validating it in your function to ensure it contains what you're
expecting perhaps?
Also, can you verify that jquery is actually getting loaded OK?
ie. In your document, put something like:
$(function() { alert("jquery has loaded!"); });
and check to see that you get an alert box when you load the page. If
not, fire up Chrome's developer tools, or Firefox's Firebug, and see
they mention any warnings or errors.
-Toby
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst and FormBuilder vs. IExplorer 8
On 07/10/10 03:36, Moritz Onken wrote:
Sounds like a trailing comma in the javascript somewhere.
The trailing-comma problem occurs in IE6/7, but not in IE8. (Thank you,
Microsoft).
I think Will's problem *doesn't* occur on IE6/7, but just IE8, if I
understand the situation correctly:
>> On 06/10/10 14:00, will trillich wrote:
>> Short version: Catalyst/Formbuilder uploads work fine in firefox and
>> chrome, works fine in IE 6... but not IE 8, where it throws an
>> "object expected" error.
I looked around our code a bit, and our own "object expected" errors
here were being caused by some javascript assuming that a certain object
would always have an object returned from a method, when in fact
sometimes it didn't in older versions of IE :/
Not so helpful for you, if this issue only appears on recent IE versions
though.. confusing!
Will, can you check to see if you're getting Internet Explorer 8 running
in "IE8 standards mode", or if it's falling back to the older quirks
mode or IE7 mode?
Try this:
alert("Document mode = " + document.documentMode);
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Logging is not immediate
On 19/10/10 10:46, Ken Beal wrote: Hi, I’m running Catalyst via the scripts\myapp_server.pl script. I have never configured it to run under a web server, and perhaps that’s the answer to my question. The issue is that when I call $c->log(), it doesn’t output anything until the “URL call” completes. This makes it difficult to watch a long-running process, because I don’t see anything until it’s done, and I don’t know if it’s hung up on something because I can’t see the log output. Has anyone else experienced this, and found a useful workaround or fix? Like I said, if I have to run it under Apache or IIS in order for this to work, I’ll do so. Hi Ken, You will find the same behaviour when running under a web server. ie. Log messages are saved up and then emitted all at once at the end of the request. I'm pretty sure this is By Design in Catalyst's default logger. However there is nothing stopping you from installing a different logging module into $c->log. I've used a Syslog one in the past. Toby ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Handling long-running processes (was Re: Logging is not immediate)
On 19/10/10 11:05, Bill Moseley wrote: On Mon, Oct 18, 2010 at 4:46 PM, Ken Beal mailto:kb...@crosscountry-auto.com>> wrote: The issue is that when I call $c->log(), it doesn’t output anything until the “URL call” completes. This makes it difficult to watch a long-running process, because I don’t see anything until it’s done, and I don’t know if it’s hung up on something because I can’t see the log output. maybe try this: $c->log->_flush; Or try: warn "I'm stuck in a loop and the web user is wondering why I'm taking so long and will likely hit reload any second now!\n"; As a follow-up to Ken's message.. If you have long-running processes in a web server, then I suspect you are Doing It Wrong. (Or, naybe you're not, and have some kind of RPC system under Catalyst, in which case ignore what I'm about to say.) Can I suggest you look at a different model of serving these long-running things to the web users? Consider having them hit a page which says "Your request is being processed..", which then kicks off the actual work in another process, and returns a token of some sort to the user's browser. (eg. Cookie or URI parameter) You then have the browser either reload the page (including the token mentioned above), or better yet, use javascript to do it in the background. You have two options here - first option is for this request to get hung on the server, waiting for the process to complete, or you can have it return quickly with the status or progress info to display in the meantime. Once this background request detects the long-running process has completed, it then directs the browser to reload, and collects the final information. This has several advantages. 1) If the user keeps hitting reload, you can detect their work token, and avoid starting more long-running processes. 2) The user doesn't get stuck with a blank screen and a loading status bar. Instead they can get progress info, or at least a message saying "we're working on it, hang in there..." 3) You don't have your web server tied up with long-running processes, holding open sockets and using memory. 4) Logging for your long-running processes is independent of your web server messages. So the URLs the user would see would be something like: /report/megasize # server kicks off background process, redirects user onto.. /report/megasize?token=d11a1658f614401782e8 # which says "please wait while we prepare your report". # The user's browser waits for completion by polling: /report/progress.json?token=d11a1658f614401782e8 # ..and eventually reloads: /report/megasize?token=d11a1658f614401782e8 # which now displays the contents of their report at least, this is the way I think it should be done. I'm curious to know how other people approach this issue. Also, what do you think about the polling approach vs a (background) connection that stays connected waiting for the completion signal? Cheers, Toby ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Handling long-running processes (was Re: Logging is not immediate)
On 20/10/10 09:19, Chris wrote: I'm curious to know how other people approach this issue. Also, what do you think about the polling approach vs a (background) connection that stays connected waiting for the completion signal? I've found polling much simpler to implement (and test) as it doesn't require anything particularly special on either client or server-side. It means a bit more delay - the polling period - before the user gets the result, but for our use-case (generating reports and download files) this hasn't been an issue. I've seen some stuff suggesting that polling leads to higher server load, but again it hasn't been an issue in our low-traffic web-apps. I still haven't played with Comet-style server-push much. Anyone else using it? What is support like for either multi-part or partial-update in browsers like now? Although HTML5 will clean it all up, since it actually defines some proper transports. Then we just have to wait for HTML5 support to be prevalent! :) -Toby ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Running system commands under FastCGI with IPC::Cmd / IPC::Run
On 22 October 2010 05:43, Ian Sillitoe wrote: > I have a Catalyst model that runs a system command as part of a search > facility. The system call only takes a fraction of a second so is processed > inline and this all works fine when tested outside of Catalyst and when > called under the Catalyst standalone server. However, when I deploy it to my > FastCGI environment I have problems - everything seems to work fine apart > from the results of the system call. > > The system call is (give or take): > > IPC::Cmd::run( > command => [qw/ blastall -d sequences.db -i input.fa -o > output.results /], > verbose => 0, > timeout => 10, > ); I recall that IPC::Run certainly has known-issues when used under FastCGI, and I'm guessing they extend to IPC::Cmd too. Have a look at IPC::Run::SafeHandles which I think got around it. Toby ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] FormHandler -- pro or con?
On 1 December 2010 02:34, will trillich wrote: > Anybody else *dissing* FormHandler? We've started developing based on > FormHandler lately and haven't had troubles... yet? I'm running it, and have been very happy with it. It's nice that you can put all your common form elements into roles and then combine them. I'm familiar with Moose, so HFH's syntax came fairly naturally to me, but I guess it could be confusing to others? Performance is reasonable - and a lot faster compared to FormFu. Cheers, Toby ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Which Form Validation Libs?
On 30 November 2010 22:26, Shlomi Fish wrote: > On Tuesday 30 November 2010 11:31:56 David Schmidt wrote: >> another great module which from my perception is used the most lately is >> >> HTML::FormHandler >> http://search.cpan.org/~gshank/HTML-FormHandler-0.32005/ >> > > I can recommend *against* HTML-FormHandler. > > For my day job's Perl and Catalyst project, we initially decided to go with > HTML-FormHandler, only to discover it was buggy, quirky and had severe memory > leaks. We ended up doing many workarounds and recently made a transition from > it to HTML-FormFu, which while by no means perfect, is much saner. > > My co-worker "nothingmuch" who has done many of the workarounds can provide > further comments on it. Recently I had to over-ride a role in the login form > (for which we need to use HTML-FormHandler due to CatalystX::SimpleLogin) that > will accept an empty string as the 'action=""' attribute because it only > placed true values of the attribute there, which ruled out empty strings. But > I recall many other fun hours debugging HTML-FormHandler. I hit issues with FormHandler and HFH::Model::DBIC having issues with empty strings vs definedness too, but it was a few months ago. I submitted some patches that were accepted a few versions back and it's been pretty good for me since. The code is reasonably logical and easy to work with, I felt. By comparison, a major app I built on FormFu earlier in the year resulted in epic debugging and terribly complex and not-at-all-logical forms, and the problems seemed more deeply ingrained. (That was a medium version number at least ago.) They both have their weaknesses, but having used both, I definitely think HFH is the way to go at the moment. Both modules have good authors who are helpful and actively developing. Cheers, Toby ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] FormHandler -- pro or con?
On 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] FormHandler -- pro or con?
On 9 December 2010 19:24, Octavian Rasnita wrote: >> Using Moose Roles for forms is awesome. > > I also agree with this idea, but the fact that the most used constraints, > filters and validators should be also manually specified using Perl code is > not so nice. > It would be nice to have a form processor like H::FF that provides many > default HTML elements, constraints, filters and validators, and to be able to > create custom elements, constraints, filters and validators using Moose > roles, then to specify that those roles are used... using config files. But.. That's what the custom fields, widgets, roles etc are there for. Eg. If you need a field that can, say, only accept four characters and they have to be a-d, then go in and make a custom field type that does the check.. Then tell your designers to just say "type => 'mySpecialField'" when they need to use it. Or even better, develop entire classes of grouped widgets and their validations, then get them to just incorporate those. (Eg. an "Address" role, which brings in street, suburb, borough, state, postcode, zip code, whatever.. and does all the validation.. You'll reuse that one a lot!) > Actually, I guess that is possible to create them using Moose with H::FF > although I am not sure. > > Ideally, the web designers that don't know Perl at all should be able to > change the design of the forms at least. Agreed, and this is where neither FormFu or FormHandler succeeds. FormFu's yaml syntax ends up being horribly complicated, and FormHandler's Perl code is not much clearer. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] FormHandler -- pro or con?
On 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/
[Catalyst] Opinions on static::simple - with caching
I'm wondering if the following plugin I've written is misguided..
It enables proxy caches and browsers to better cache the files served
by Static::Simple..
However, I suppose in situations where that matters, you shouldn't be
serving files via Static::Simple..
And the regular Static::Simple still provides Last-Modified headers,
which do allow browsers to perform some caching.
What do you think?
To enable this plugin, you need:
use Catalyst qw(
...
Static::Simple
Static::Caching
);
-Caching.pm--
package Catalyst::Plugin::Static::Caching;
use Moose::Role;
requires '_serve_static'; # From Catalyst::Plugin::Static::Simple
after _serve_static => sub {
my $c = shift;
# Avoid setting an expires if the parent never found the file..
return unless (defined $c->response->body
and ref($c->response->body) eq 'IO::File');
# Tell browsers they can cache files for a couple of hours:
$c->res->headers->expires(time() + 7200);
# Tell Firefox it's OK to cache, even over SSL:
$c->res->headers->header('Cache-control' => 'public');
};
1;
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Opinions on static::simple - with caching
On 31 January 2011 19:04, Tomas Doran wrote: > On 31 Jan 2011, at 07:17, Toby Corkindale wrote: > >> However, I suppose in situations where that matters, you shouldn't be >> serving files via Static::Simple.. >> And the regular Static::Simple still provides Last-Modified headers, >> which do allow browsers to perform some caching. >> >> What do you think? > > Pretty much that - Static::Simple is really meant for development only, and > in such a situation, you really want to not serve cache headers, as you > don't want things cached when you're developing. > > That said, this isn't the first time someone has suggested this recently, so > maybe it's worth just adding as an option in Static::Simple directly (with > suitable warnings about production use in the documentation). The case that I find having the headers enabled is as follows: Front end load-balancing proxies, talking to app servers running starman, running catalyst apps. If you use Static::Simple, this does make the pipeline configuration nice and simple. I like simplicity. If you enable caching on your static content, then your reverse-proxies at the front will cache things, and take the load of static content off Catalyst at the back. I'd like to see it as an option on Static::Simple; I could mod that and send a patch over if you liked? Toby ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: Opinions on static::simple - with caching
On 2 February 2011 00:08, Aristotle Pagaltzis wrote: > * Toby Corkindale [2011-02-01 03:25]: >> The case that I find having the headers enabled is as follows: >> >> Front end load-balancing proxies, talking to app servers >> running starman, running catalyst apps. >> If you use Static::Simple, this does make the pipeline >> configuration nice and simple. >> I like simplicity. >> If you enable caching on your static content, then your >> reverse-proxies at the front will cache things, and take the >> load of static content off Catalyst at the back. >> >> I'd like to see it as an option on Static::Simple; I could mod >> that and send a patch over if you liked? > > You may be interested in my setup: > http://blogs.perl.org/users/aristotle/2011/01/some-nifty-things-you-can-do-with-catalyst-on-plack.html Thanks - that's a really good example setup. How do you find Plack at serving static files (via Middleware::Static / App::Static)? Compared to Static::Simple, and compared to native HTTPD. I guess it sits in between the two in terms of performance, but wondered how much of an improvement it was? I might have to borrow the bit about auto-extending expiry times for versioned static files :) cheers, Toby ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: Opinions on static::simple - with caching
On 2 February 2011 13:43, Andrew Rodland wrote: > On Tuesday, February 01, 2011 08:06:08 PM Toby Corkindale wrote: >> How do you find Plack at serving static files (via Middleware::Static >> / App::Static)? Compared to Static::Simple, and compared to native >> HTTPD. I guess it sits in between the two in terms of performance, but >> wondered how much of an improvement it was? >> > All of them will give perfectly acceptable throughput -- even Static::Simple > isn't *slow*. The real concern is that with Static::Simple or with > Plack::App::File, you're tying up one of your webapp processes to serve the > file -- and your webapp processes are usually fairly limited in number, and > fairly memory-hungry (which prevents you from just making more). On the other > hand, if you let the frontend httpd serve the file, the cost of serving a > static file ranges from one lightweight httpd thread (for a threaded model) to > nearly nothing at all (with an async model). Either way, it's not tying up a > process that could be running Catalyst. > > If you're serving up a fairly small number of fairly small files, then this > probably doesn't make any difference to you, but if you're serving a larger > number of larger files (that will take several seconds or more to transfer) > then you should probably be thinking about ways to do it outside of your > webapp process. Which neatly loops around to my original post! :D My suggestion being to continue to use Static::Simple, but with cache-related headers added so that the reverse-proxy in front of Starman will cache-and-serve them itself. It's simple, and IMHO, ends up as the fastest, most light-weight way to serve those static files too. -T -- Turning and turning in the widening gyre The falcon cannot hear the falconer Things fall apart; the center cannot hold Mere anarchy is loosed upon the world ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] [PATCH] Allow Expires and Cache-control headers in Static::Simple
On 1 February 2011 23:28, Tomas Doran wrote:
> On 1 Feb 2011, at 02:17, Toby Corkindale wrote:
>> I'd like to see it as an option on Static::Simple; I could mod that
>> and send a patch over if you liked?
>
> Sure, or just commit into a branch (you already have a commit bit, right)?
I cannot for the life of me remember my auth details, sorry :(
(Or perhaps I just don't have a commit bit on that module)
Have sent separate email regarding them.
Regardless, here is the patch..
---
Changes |4
lib/Catalyst/Plugin/Static/Simple.pm | 32 +---
2 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/Changes b/Changes
index aea5423..71d2367 100644
--- a/Changes
+++ b/Changes
@@ -1,5 +1,9 @@
Revision history for Perl extension Catalyst::Plugin::Static::Simple
+0.30 2011-02-xx hh:mm:00
+- Add Cache-Control:public header
+- Optionally provide Expires header
+
0.29 2010-02-01 18:45:00
- Switch from override to around, because really, wtf
diff --git a/lib/Catalyst/Plugin/Static/Simple.pm
b/lib/Catalyst/Plugin/Static/Simple.pm
index ca3412c..91cef4a 100644
--- a/lib/Catalyst/Plugin/Static/Simple.pm
+++ b/lib/Catalyst/Plugin/Static/Simple.pm
@@ -8,7 +8,7 @@ use MIME::Types ();
use MooseX::Types::Moose qw/ArrayRef Str/;
use namespace::autoclean;
-our $VERSION = '0.29';
+our $VERSION = '0.30';
has _static_file => ( is => 'rw' );
has _static_debug_message => ( is => 'rw', isa => ArrayRef[Str] );
@@ -172,6 +172,7 @@ sub _locate_static_file {
sub _serve_static {
my $c = shift;
+my $config = $c->config->{static} ||= {};
my $full_path = shift || $c->_static_file;
my $type = $c->_ext_to_type( $full_path );
@@ -180,6 +181,12 @@ sub _serve_static {
$c->res->headers->content_type( $type );
$c->res->headers->content_length( $stat->size );
$c->res->headers->last_modified( $stat->mtime );
+# Tell Firefox & friends its OK to cache, even over SSL:
+$c->res->headers->header('Cache-control' => 'public');
+# Optionally, set a fixed expiry time:
+if ($config->{expires}) {
+$c->res->headers->expires(time() + $config->{expires});
+}
my $fh = IO::File->new( $full_path, 'r' );
if ( defined $fh ) {
@@ -307,7 +314,7 @@ the operation by adding various configuration
options. In a production
environment, you will probably want to use your webserver to deliver
static content; for an example see L, below.
-=head1 DEFAULT BEHAVIOR
+=head1 DEFAULT BEHAVIOUR
By default, Static::Simple will deliver all files having extensions
(that is, bits of text following a period (C<.>)), I files
@@ -450,6 +457,23 @@ module, you may enter your own extension to MIME
type mapping.
},
);
+=head2 Controlling caching with Expires header
+
+The files served by Static::Simple will have a Last-Modified header set,
+which allows some browsers to cache them for a while. However if you want
+to explicitly set an Expires header, such as to allow proxies to cache your
+static content, then you can do so by setting the "expires" config option.
+
+The value indicates the number of seconds after access time to allow caching.
+So a value of zero really means "don't cache at all", and any higher values
+will keep the file around for that long.
+
+MyApp->config(
+static => {
+expires => 3600, # Caching allowed for one hour.
+},
+);
+
=head2 Compatibility with other plugins
Since version 0.12, Static::Simple plays nice with other plugins. It no
@@ -572,6 +596,8 @@ Justin Wheeler (dnm)
Matt S Trout,
+Toby Corkindale,
+
=head1 THANKS
The authors of Catalyst::Plugin::Static:
@@ -586,7 +612,7 @@ For the include_path code from Template Toolkit:
=head1 COPYRIGHT
-Copyright (c) 2005 - 2009
+Copyright (c) 2005 - 2011
the Catalyst::Plugin::Static::Simple L and L
as listed above.
--
1.7.3.5
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Git conversions
On 17 May 2011 12:41, fREW Schmidt wrote: > Hey guys, > > So I've converted all of the DBIC repos from bast (our svn repo) that will > see new dev, and I got most of the Catalyst-Authentication modules > converted, as t0m had said he'd appreciate it. If you'd like to see the > converted repos take a look at github.com/frioux. That is not their > permanent home, just where I can keep them till people agree that I didn't > miss anything w/ the history. > > Now, I'd go ahead and just convert the rest of the repos in the Catalyst > svn, but first off, I don't really know what's likely to get more dev and > second, I don't want to offend people by moving their projects from > underneath them. > > So, if you are interested in having your repo converted, I am totally > willing to do it. All I need from you is an email saying you are interested > and I need to you be willing to check the converted repo to ensure that it's > good. I've gotten to the point that I can usually find missing merges, > correctly recreate tags, etc, but I'm not perfect and I'm not taking the > blame if you miss it :-) For what it's worth, some of the trouble can be saved by using something like svn2git: https://github.com/nirvdrum/svn2git Cheers, Toby ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Recommended caching back-ends
Hey all, I noticed today that Catalyst::Plugin::Cache::FastMmap has been DEPRECATED for some now. (With dire warnings about it segfaulting or discarding data randomly) I just wondered what the recommended caching backend is now, to use with Catalyst::Plugin::Cache. (In my case, cached data doesn't need to be consistent between app servers.. it's more just for performance so simple local-disk is fine for caching, rather than memcached or database based solutions.) Cheers, Toby -- Turning and turning in the widening gyre The falcon cannot hear the falconer Things fall apart; the center cannot hold Mere anarchy is loosed upon the world ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: Recommended caching back-ends
Is there a Plugin::CHI or a CHI driver for Plugin::Cache anywhere? On 7 October 2011 12:52, Toby Corkindale wrote: > Hey all, > I noticed today that Catalyst::Plugin::Cache::FastMmap has been > DEPRECATED for some now. (With dire warnings about it segfaulting or > discarding data randomly) > > I just wondered what the recommended caching backend is now, to use > with Catalyst::Plugin::Cache. > > (In my case, cached data doesn't need to be consistent between app > servers.. it's more just for performance so simple local-disk is fine > for caching, rather than memcached or database based solutions.) > > Cheers, > Toby > > -- > Turning and turning in the widening gyre > The falcon cannot hear the falconer > Things fall apart; the center cannot hold > Mere anarchy is loosed upon the world > -- Turning and turning in the widening gyre The falcon cannot hear the falconer Things fall apart; the center cannot hold Mere anarchy is loosed upon the world ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: Recommended caching back-ends
On 7 October 2011 18:22, Stephen Clouse wrote: > On Fri, Oct 7, 2011 at 12:05 AM, Toby Corkindale wrote: >> >> Is there a Plugin::CHI or a CHI driver for Plugin::Cache anywhere? > > CHI works fine with C::P::Cache out of the box, nothing extra required. > > Just specify class => 'CHI' in the backend config and pass CHI configuration > as documented. Oh! Right. Thanks. Out of interest, how was I supposed to know I could do that? I thought I needed to pick modules which had existing catalyst::plugin::cache::store::X modules. (where X is the backend name) cheers, Toby -- Turning and turning in the widening gyre The falcon cannot hear the falconer Things fall apart; the center cannot hold Mere anarchy is loosed upon the world ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Accesing PSGI 'env' from in a controller
Hi, Is there a way to access values set in the PSGI "env" store, once you're operating inside a catalyst controller method? Catalyst::Engine::PSGI looks like it is passing the $env variable along, but I haven't worked out how to access it. I thought $c->request->env would do the trick, but that method (->env) doesn't exist. Any hints? Or is this something I should be leaving alone? ;) Cheers, Toby -- Turning and turning in the widening gyre The falcon cannot hear the falconer Things fall apart; the center cannot hold Mere anarchy is loosed upon the world ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: Accesing PSGI 'env' from in a controller
Answering my own question here..
Stuff was hidden in:
$c->engine->env->{...};
I know this isn't very portable, but it's for an internal app where
being able to pass some extra info through from the plack middleware
will be very helpfu.
I'm curious though - How would you suggest such stuff is handled?
cheers,
Toby
On 21 October 2011 17:11, Toby Corkindale wrote:
> Hi,
>
> Is there a way to access values set in the PSGI "env" store, once
> you're operating inside a catalyst controller method?
>
> Catalyst::Engine::PSGI looks like it is passing the $env variable
> along, but I haven't worked out how to access it.
> I thought $c->request->env would do the trick, but that method (->env)
> doesn't exist.
>
> Any hints? Or is this something I should be leaving alone? ;)
>
> Cheers,
> Toby
>
>
> --
> Turning and turning in the widening gyre
> The falcon cannot hear the falconer
> Things fall apart; the center cannot hold
> Mere anarchy is loosed upon the world
>
--
Turning and turning in the widening gyre
The falcon cannot hear the falconer
Things fall apart; the center cannot hold
Mere anarchy is loosed upon the world
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst 5.9007 / memcache /high cpu
On 17 February 2012 11:16, Todd Benge wrote: > Hi, > > We recently updated our web servers to Catalyst 5.9007 with Perl 5.12. > > After the upgrade, we've consistently seen very high cpu on the machines > > 90%. After much looking, it appears that the apache threads are stuck in > Cache::Memcached disconnecting. Which Apache model are you using? Prefork, worker threads, events? ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst 5.9007 / memcache /high cpu
Ah, I don't know then. Was just going to say that Cache::Memcached uses AnyEvent under the hood, and maybe that was interfering with apache's event loop if you were using that model. On 17 February 2012 12:48, Todd Benge wrote: > We're using PreFork. > > Sent from my iPhone > > On Feb 16, 2012, at 6:29 PM, Toby Corkindale wrote: > >> On 17 February 2012 11:16, Todd Benge wrote: >>> Hi, >>> >>> We recently updated our web servers to Catalyst 5.9007 with Perl 5.12. >>> >>> After the upgrade, we've consistently seen very high cpu on the machines > >>> 90%. After much looking, it appears that the apache threads are stuck in >>> Cache::Memcached disconnecting. >> >> Which Apache model are you using? Prefork, worker threads, events? >> >> ___ >> List: Catalyst@lists.scsys.co.uk >> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst >> Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ >> Dev site: http://dev.catalyst.perl.org/ > > ___ > List: Catalyst@lists.scsys.co.uk > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ > Dev site: http://dev.catalyst.perl.org/ -- Turning and turning in the widening gyre The falcon cannot hear the falconer Things fall apart; the center cannot hold Mere anarchy is loosed upon the world ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Progress bar
I was just investigating why the upload progress bar was broken on one of my apps.. came here to make a post and discovered this thread. Well, at least that's the first question answered! Given the caveats around Starman and WebKit browsers, are there any other suggestions for how to do upload progress indicators? Is this something we can do via HTML5 neater? Are there any open-source Flash implementations? Cheers, Toby On 22 October 2012 09:42, Bill Moseley wrote: > > On Sat, Oct 20, 2012 at 1:51 PM, Tomas Doran wrote: >> >> And UploadProgress is shipped, should be available once it's reindexed >> (permissions cock up), which should be shortly :) > > > So, when running under Starman the uploads are buffered before chunked to > Catalyst, which means the progress bar data isn't updated until the upload > has completed. This renders the upload progress bar pretty useless with > Starman. > > The progress bar works fine running the app under mod_perl. > > I suppose using something like Nginx or Perlbal in front of the app would > work (because those do cache uploads but also provide a hook for reading > upload progress). But, we already have hardware load balancers in front of > the app, so don't really need an extra proxy in front of every web server. > > Any other options? Using a upload/request caching proxy is probably THE > correct answer since don't really want to tie up the app with slow uploads. > > I guess I should test, but I wonder if there's a limit on what Starman will > buffer -- I assume it's buffering in memory. > > > > > -- > Bill Moseley > mose...@hank.org > > ___ > List: Catalyst@lists.scsys.co.uk > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ > Dev site: http://dev.catalyst.perl.org/ > -- Turning and turning in the widening gyre The falcon cannot hear the falconer Things fall apart; the center cannot hold Mere anarchy is loosed upon the world ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Moose's make_immutable in Catalyst classes
Hi,
In modern Catalyst apps, we tend to create packages like this with Moose:
package MyApp::Controller::Foo;
use Moose;
use namespace::autoclean;
BEGIN { extends 'Catalyst::Controller'; }
...
1;
I was just wondering.. should we be adding Moose's make_immutable call
to the end of these classes?
ie. __PACKAGE__->meta->make_immutable;
Cheers,
Toby
--
Turning and turning in the widening gyre
The falcon cannot hear the falconer
Things fall apart; the center cannot hold
Mere anarchy is loosed upon the world
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Progress bar
I 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] /Depreci?ate/ message
I noticed that the recent Catalyst release has added a Depreciation warning to the Regex class. Are you sure you meant depreciate? I think old features are normally deprecated. Cheers, Toby -- Turning and turning in the widening gyre The falcon cannot hear the falconer Things fall apart; the center cannot hold Mere anarchy is loosed upon the world ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Stupid error with C::Authentication
On 27 August 2013 02:07, Alex Povolotsky wrote:
> In a quite simple application
[snip]
> I get
>
> [error] Caught exception in Admin::Controller::Root->index "Can't use string
> ("Catalyst::Authentication::Store:"...) as a HASH ref while "strict refs" in
> use at accessor Catalyst::Authentication::Store::DBIx::Class::User::_user
> (defined at
> /usr/local/lib/perl5/site_perl/5.14/Catalyst/Authentication/Store/DBIx/Class/User.pm
> line 12) line 5, line 1003."
>
> My password class has nothing to get wrong, and replacing it with default
> C::A::Credential::Password does not change anything
Hi Alex,
I've seen this particular error come up (with exactly that message)
when the user running the application was not able to connect to the
database successfully.
I don't know why that would vary depending on you using perl -d or
just perl though, but I thought I'd mention it.
-Toby
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
[Catalyst] Mocking PSGI layers in Test WWW Mechanize Catalyst
Hi, I wondered if there's any prior art around on inserting (mocked) PSGI layers into Test::WWW::Mechanize:Catalyst? Cheers, Toby -- Turning and turning in the widening gyre The falcon cannot hear the falconer Things fall apart; the center cannot hold Mere anarchy is loosed upon the world ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Mocking PSGI layers in Test WWW Mechanize Catalyst
Umm, not that I know of. I suppose another way to phrase the question is: Is there a way to manipulate the $c->engine->env in the Catalyst application, from within unit tests neatly? On 1 November 2013 08:35, John Napiorkowski wrote: > Not sure what you mean, is there an example in another framework you can > point to? > > johnn > > > On Thursday, October 31, 2013 12:55 AM, Toby Corkindale > wrote: > Hi, > I wondered if there's any prior art around on inserting (mocked) PSGI > layers into Test::WWW::Mechanize:Catalyst? > > Cheers, > Toby > > -- > Turning and turning in the widening gyre > The falcon cannot hear the falconer > Things fall apart; the center cannot hold > Mere anarchy is loosed upon the world > > ___ > List: Catalyst@lists.scsys.co.uk > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ > Dev site: http://dev.catalyst.perl.org/ > > > > ___ > List: Catalyst@lists.scsys.co.uk > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ > Dev site: http://dev.catalyst.perl.org/ > -- Turning and turning in the widening gyre The falcon cannot hear the falconer Things fall apart; the center cannot hold Mere anarchy is loosed upon the world ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Mocking PSGI layers in Test WWW Mechanize Catalyst
It looks like there is an undocumented feature in Catalyst::Test, a
callback to let you modify the request.
$args->{mangle_request}->($request) if $args->{mangle_request};
Or alternatively I can subclass the module and extend
_customize_request() to add more to the PSGI environment.
On 1 November 2013 11:39, Toby Corkindale wrote:
> Umm, not that I know of.
>
> I suppose another way to phrase the question is: Is there a way to
> manipulate the $c->engine->env in the Catalyst application, from
> within unit tests neatly?
>
> On 1 November 2013 08:35, John Napiorkowski wrote:
>> Not sure what you mean, is there an example in another framework you can
>> point to?
>>
>> johnn
>>
>>
>> On Thursday, October 31, 2013 12:55 AM, Toby Corkindale
>> wrote:
>> Hi,
>> I wondered if there's any prior art around on inserting (mocked) PSGI
>> layers into Test::WWW::Mechanize:Catalyst?
>>
>> Cheers,
>> Toby
>>
>> --
>> Turning and turning in the widening gyre
>> The falcon cannot hear the falconer
>> Things fall apart; the center cannot hold
>> Mere anarchy is loosed upon the world
>>
>> ___
>> List: Catalyst@lists.scsys.co.uk
>> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
>> Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
>> Dev site: http://dev.catalyst.perl.org/
>>
>>
>>
>> ___
>> List: Catalyst@lists.scsys.co.uk
>> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
>> Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
>> Dev site: http://dev.catalyst.perl.org/
>>
>
>
>
> --
> Turning and turning in the widening gyre
> The falcon cannot hear the falconer
> Things fall apart; the center cannot hold
> Mere anarchy is loosed upon the world
--
Turning and turning in the widening gyre
The falcon cannot hear the falconer
Things fall apart; the center cannot hold
Mere anarchy is loosed upon the world
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Mocking PSGI layers in Test WWW Mechanize Catalyst
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
On 1 November 2013 12:29, Kieren Diment wrote: > On 01/11/2013, at 12:26 PM, Toby Corkindale wrote: >> On 1 November 2013 12:01, Kieren Diment wrote: >>> You mean you want two apps interacting with each other in the same script >>> using WWW::MEchanize? Eden and I were working some docs up on that topic >>> until real life intervened. >>> >>> This was the start of it: >>> >>> http://paste.scsys.co.uk/273844 >> >> Not exactly -- in this case I have a PSGI layer that is supposed to >> inject some extra information into the env for consumption by the >> application. >> >> A simple example would be if you had a PSGI layer providing, say, >> Basic HTTP auth, and setting the REMOTE_USER variable. >> Although in my case, there's a bit more to it than that. >> >> T > > Does the paste set you in the right direction? It's helpful for showing how to build a test-www-mechanize-psgi :) -- Turning and turning in the widening gyre The falcon cannot hear the falconer Things fall apart; the center cannot hold Mere anarchy is loosed upon the world ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Mocking PSGI layers in Test WWW Mechanize Catalyst
On 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] Providing a REST API from behind Apache/FastCGI?
On 9 November 2013 07:54, Dan Lowe wrote: > When I move this from dev to test, which means it goes behind mod_fastcgi, it > stops working. Every request gets back 401 Unauthorized. As far as I can > tell, the Authorization header is not being passed through to Catalyst. > > Has anyone had this problem and knows of some solution? I'm out of ideas at > this point... I know this isn't very helpful, but have you tried switching to using apache (or preferably nginx) to reverse-proxy through to starman, rather than using FastCGI? I think that's the current "best practice" and would prove more reliable. At the very least, it provides more ways to inspect and debug what is going on. If you're out of ideas, it might be quicker to just give up on fastcgi and move on. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Bug in old Advent example of async/websockets code?
Hi, I've been trying to replicate the use of WebSockets in Catalyst, by following the example from the Advent calendar a year and a bit ago. ie. https://github.com/perl-catalyst/2013-Advent-Staging/blob/master/Websocket-Echo/lib/MyApp/Controller/Root.pm In my experience, it isn't actually working properly -- I get the "Echo Initiated" message, but then an instant disconnect. Looking at the code, I'm highly suspicious of the $hd variable -- it doesn't get stored anywhere, and according to the AnyEvent docs, I think that means it will get DESTROYed once it goes out of scope. ie. Immediately. That fits the behaviour I'm seeing, although I think I've had it work for me randomly at times as well, so... I don't know. I wondered if anyone here has thoughts on the matter? Cheers, Toby ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Bug in old Advent example of async/websockets code?
It's worth noting that when I started stashing the $hd variable into
somewhere, I started getting a connection holding open.
However, attempts to CLOSE the websocket now seemed to hang on the
browser side, and were unreported on the server side.
Code follows:
has 'clients' => (
is => 'rw',
default => sub { +{} },
);
sub ws : Path('/ws') {
my ($self, $c) = @_;
$c->stash->{is_websocket} = 1;
my $io = $c->req->io_fh;
my $hs = Protocol::WebSocket::Handshake::Server->new_from_psgi($c->req->env);
$hs->parse($io);
my $hd = AnyEvent::Handle->new(fh => $io);
$self->clients->{$hd} = 1;
$hd->push_write($hs->to_string);
$hd->push_write($hs->build_frame(buffer => "Echo Initiated")->to_bytes);
my $error_cb = sub {
my ($handle, $fatal, $message) = @_;
if (defined $message) {
warn "ws error: $message\n";
}
delete $self->clients->{$handle};
return;
};
$hd->on_eof($error_cb);
$hd->on_error($error_cb);
$hd->on_read(sub {
(my $frame = $hs->build_frame)->append($_[0]->rbuf);
while (my $msg = $frame->next) {
warn "ws: frame contained: $msg\n";
$hd->push_write($hs->build_frame(buffer => "Hello $msg")->to_bytes);
}
});
}
On 23 February 2015 at 12:08, Toby Corkindale wrote:
> Hi,
> I've been trying to replicate the use of WebSockets in Catalyst, by
> following the example from the Advent calendar a year and a bit ago.
> ie.
> https://github.com/perl-catalyst/2013-Advent-Staging/blob/master/Websocket-Echo/lib/MyApp/Controller/Root.pm
>
> In my experience, it isn't actually working properly -- I get the
> "Echo Initiated" message, but then an instant disconnect.
>
> Looking at the code, I'm highly suspicious of the $hd variable -- it
> doesn't get stored anywhere, and according to the AnyEvent docs, I
> think that means it will get DESTROYed once it goes out of scope. ie.
> Immediately.
>
> That fits the behaviour I'm seeing, although I think I've had it work
> for me randomly at times as well, so... I don't know.
>
> I wondered if anyone here has thoughts on the matter?
>
> Cheers,
> Toby
--
Turning and turning in the widening gyre
The falcon cannot hear the falconer
Things fall apart; the center cannot hold
Mere anarchy is loosed upon the world
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] advise on data processing in Cat/DBIC/Model
On Mon, Nov 26, 2007 at 07:04:24PM +, Matt S Trout wrote:
> On Mon, Nov 26, 2007 at 04:33:02PM +0100, Rainer Clasen wrote:
> > Hello,
> >
> > within my current project, some value is collected up to once a day:
> >
> > CREATE TABLE a_value {
> > day date PRIMARY KEY,
> > other_values integer NOT NULL,
> > value integer
> > another_value integer
> > );
> >
> > Data comes in a bit sporadic - so I cannot rely each day having an entry.
> > Actually there also be longer periods (weeks/month/??) without data.
> >
> > I'm currently a bit at a loss on how to "properly" cook up this data to
> > easily display it in fixed time steps. I'm thinking of a list of *all*
> > days/weeks/month/... in a certain timerange. Such a list would allow the
> > view easy access to present the data (say as html table with one row per
> > time step or as input for GD::Graph).
> >
> > This means there are basically two tasks:
> > - aggregate the data for each time step: No-brainer with DBIx::Class.
> > - get NULL entries for time steps without data: The intersting part.
> >
> > I can come up the following solutions to generate the NULL entries:
> >
> > - use a SQL stored procedure or temp table with the start-dates of the
> > desired time-steps, do an outer join and stuff this in a DBIC
> > result_source as described in the DBIC cookbook under "arbitrary SQL".
> >
> > example query for ->name():
> > SELECT
> > d.id,
> > steps AS day,
> > d.value,
> > COALESCE( d.other_value, $4 ) AS other_value
> > FROM
> > timeseries( $1, $2, $3) AS steps
> > LEFT JOIN ( SELECT * FROM data WHERE other_value = $4 ) d
> > ON ( d.day >= $2 AND d.day + $1 < $3;
> > $1 = time steps. eg. '1 day'
> > $2 = start date. eg. '2007-11-1'
> > $3 = end date. eg '2007-11-30'
> > $4 = other_value to filter on.
> > timeseries(step,start,end) = stored procedure that returns the
> > start-dates of the time-steps within the specified time-range.
>
> I tend to do -sort- of this.
>
> Except that instead of using a function like timeseries() I'll create a
> pivot table with a 'date' column that I prepopulated with all dates from
> now to say 2020 (and make sure one of my cron jobs extends this when we
> reach say 2019 or so). Then I put function indexes on the various DATE_PART
> or equivalent functions that I might use to pull the month, year etc.
>
> That way I can query the pivot as "just another DBIC class" and everything
> gets simpler.
I believe that's the method Joe Celko recommends as well.
You can extend it later with public holidays or some other metadata, too.
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/[EMAIL PROTECTED]/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] utf8 in mysql
>> On Sun, 2007-12-02 at 16:41 +0200, Angel Kolev wrote:
>>> Hi again :) I found a solution i think. With Encode::Detect i can do:
>>> use Encode;
>>> require Encode::Detect;
>>> my $utf8 = decode("Detect", $data);
>>
>> Looks like this module uses Mozilla's encoding detector, which does a
>> pretty good job in my experience. If you're trying to guess the
>> encoding of small pieces of text, though, this method probably won't
>> work. The best thing to do is to ask the user what encoding he's using,
>> or mandate UTF-8.
Angel,
Where are you getting the input from?
Is it just form submissions on web pages, or are you accepting file uploads or
emails or I dunno, CDs sent by post, or files-on-flash-sticks or something?
I just ask because there are standard ways to deal with encodings for some of
those methods - for websites it's mostly a solved problem, although there are
always caveats for people using antique browsers.
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/[EMAIL PROTECTED]/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Web hosting?
On Fri, Jan 04, 2008 at 02:05:17PM +0800, Martin Ellison wrote: > OK, I am discussing this with DreamHost, and hope to be able to resolve the > issue. But... when I originally started this thread, several posters > suggested various hosting companies at around the USD 50-100/month level, > which was good, but not in the same category as DreamHost (about > USD6/month). > > So, what I would like to ask in this post is for a Plan B in case DreamHost > fall through: can anyone recommend another good hosting company that > supports Catalyst at around the USD 10 / month level, more or less? I was running some Cat apps off a host on ASmallOrange, who were $15 for three months, or $5/month. They seemed alright. tjc > On 04/01/2008, Martin Ellison <[EMAIL PROTECTED]> wrote: > > > > The refusal email was (on face) from a human, and did not state any > > reason. I've replied asking for an explanation. > > > > On 04/01/2008, Jon Schutz < [EMAIL PROTECTED]> wrote: > > > > > > On Fri, 2008-01-04 at 09:28 +0800, Martin Ellison wrote: > > > > Dreamhost have refused to accept our site on the grounds of their > > > > "frad detection system". No explanation given, and I have no idea why > > > > as this is a legitimate business. > > > > > > Did you contact a human at Dreamhost and ask why? In contrast to some > > > hosting providers, I have found Dreamhost's humans to be reasonable > > > people. > > > > > > -- > > > Jon SchutzMy tech notes http://notes.jschutz.net > > > Chief Technology Officer > > > http://www.youramigo.com > > > YourAmigo > > > > > > > > > > > > > > > ___ > > > List: Catalyst@lists.scsys.co.uk > > > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > > > Searchable archive: > > > http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ > > > Dev site: http://dev.catalyst.perl.org/ > > > > > > > > > > > -- > > Regards, > > Martin > > ([EMAIL PROTECTED]) > > IT: http://methodsupport.com Personal: http://thereisnoend.org > > > > > > -- > Regards, > Martin > ([EMAIL PROTECTED]) > IT: http://methodsupport.com Personal: http://thereisnoend.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] Gentoo Catalyst overlay: repository moved!
On Wed, Jan 09, 2008 at 06:06:05PM +0100, Michele Beltrame wrote:
> Hello!
>
> The Catalyst-related ebuilds (along with some others) are now part of the
> perl-exprimental Gentoo overlay.
>
> Old repository and overlay will not be maintained any more.
Hi Michele,
Are you still maintaining the relevant bits of the overlay?
I attach a couple of ebuilds for the overlay for your (or anyone else's)
consideration.
Cheers,
Toby
# Copyright 1999-2006 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
inherit perl-module
S=${WORKDIR}/WWW-Facebook-API-v0.4.10
DESCRIPTION="Perl interface to Facebook Platform API"
HOMEPAGE="http://search.cpan.org/search?query=WWW-Facebook-API&mode=dist";
SRC_URI="mirror://cpan/authors/id/U/UN/UNOBE/WWW-Facebook-API-v0.4.10.tar.gz"
IUSE=""
SLOT="0"
LICENSE="|| ( Artistic GPL-2 )"
KEYWORDS="alpha amd64 arm hppa ia64 m68k mips ppc ppc64 ppc-macos s390 sh sparc
sparc-fbsd x86 x86-fbsd"
DEPEND="dev-perl/libwww-perl
dev-perl/Crypt-SSLeay
dev-perl/JSON-Any
dev-lang/perl"
# Copyright 1999-2006 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
inherit perl-module
S=${WORKDIR}/Catalyst-Plugin-Facebook-0.1
DESCRIPTION="Catalyst plugin for Facebook Platform API integration"
HOMEPAGE="http://search.cpan.org/search?query=Catalyst-Plugin-Facebook&mode=dist";
SRC_URI="mirror://cpan/authors/id/S/SO/SOCK/Catalyst-Plugin-Facebook-0.1.tar.gz"
IUSE=""
SLOT="0"
LICENSE="|| ( Artistic GPL-2 )"
KEYWORDS="alpha amd64 arm hppa ia64 m68k mips ppc ppc64 ppc-macos s390 sh sparc
sparc-fbsd x86 x86-fbsd"
DEPEND="dev-perl/WWW-Facebook-API
dev-lang/perl"
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/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] Detecting Incorrectly Displayed Page (Generating and Visiting URLS automatically ?)
On Mon, Feb 04, 2008 at 03:58:54PM +0900, [EMAIL PROTECTED] wrote:
> Hi,
>
> I am currently doing some tests with my application and I am wondering if
> there is any efficient and effective way to know if pages which should be
> displayed correctly are actually being redirected to another page, such as
> "404 - Data Not Found", because of some logic or data mismatches ?
>
> One idea that came to my mind is by generating URLs and visiting generated
> URLs by our program, and check the used template file. For example, if we
> have 3 records, with '1','2','3' as their ids, we want to do a loop to visit
> each generated URL and look if they are displayed correctly by
> generating an output such as this:
>
> URLID Used Template
> --- --
> localhost/key/1 1index.tt2
> localhost/key/2 2.error.tt2
> localhost/key/3 3.index.tt2
>
> But I am not sure if that is even possible. Any ideas ?
Well, you could edit every template file and put:
.. but that seems, erm, Not Good.
Have you considered checking the status code of the pages in your tests?
eg.
for (1..3) {
is( request("localhost/key/$_")->code, 200, 'Request succeeded' );
}
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/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] ModPerl catapp and SSLVerifyClient
On Fri, Feb 08, 2008 at 03:50:19PM -0500, John Lifsey - Contractor - wrote: > This is really more of an Apache question, but I was hoping one of you guys > may have run into it in the past. I have a MP Cat application running in > The application needs for Clients to identify themselves via > > SSLVerifyClient require > > but the monitoring system needs to be able to access the site via SSL but > without a client certificate. Is there a way to change the configuration > based on the client's IP range, or some other semi-clever apache config > that will allow the application to stay in a Location / block? It's been a while since I've used one, but I believe you can attach mod_perl handlers to various stages of the Apache pipeline, including authentication, so you might be able to write some logic there. See http://www.modperl.com/book/chapters/ch6.html Although I don't know if you can fire one of those off early enough for SSL. 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] cookies!
On Tue, Feb 12, 2008 at 03:44:44PM -0800, Jennifer Ahn wrote:
> hello!
>
> how does one implement cookies in catalyst?
>
> jennifer
You can access the cookie jar with:
$c->request->cookie('myCookie');
or
$c->request->cookies->{'myCookie'}->value;
To set cookies, use $c->response instead, like:
$c->response->cookies->{'newCookie'} = {
value => '123',
path => '/',
domain => 'foobar.com',
expires => '+8h',
};
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] Doing work inside the DBIx::Class model
On Wed, Feb 20, 2008 at 01:10:12PM +1000, Cian Barclay wrote:
> Hello Catalysters,
>
> I'm using Catalyst with a DBIx::Class model generated by
> DBIx::Class::Schema::Loader.
>
> I want to make my model do more work, rather than having my
> controllers fiddling around with model objects doing things to them.
> But I'm stuck on the bit where I want to get a resultset inside the
> model's subroutines. In a controller I use $c->model("Foo::Bar") to
> get the resultset. How can I get a resultset when I'm in the model?
>
> I could pass $c in to the model, but then the model wouldn't be
> usable without Catalyst. I'd like to be able to use the model
> for other things, but from reading the DBIx::Class manual, it
> seems like I'd need the $schema object to get resultsets.
>
> Since I'm stuck, I thought it would be a good time to ask for some
> help on this please. Is there a way to make a DBIx::Class model
> which is usable both for Catalyst and something else? How do you
> get resultsets inside the model which could either be from the
> Catalyst model, or from the database connection if Catalyst wasn't
> being used?
I think you're looking for the $self->resultsource->schema method, inside your
Model?
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] CatalystSites.org
On Fri, Apr 11, 2008 at 02:06:49PM -0700, Ashley wrote: > On Apr 11, 2008, at 1:33 PM, Christopher H. Laco wrote: >> /tag/name/ >> /tag/id/ >> >> The greatness of future possibilities is expanded to much happiness. >> Chained/sub instance() make all the code behind either option JustWork. > > claco (I just like writing it) ++. This is mostly how I do it and for admin > functions I redirect to the id version. /tag/name/ going to its id at > /tag/id//edit as only the id is immutable for the record. Well, tags > are a bad example for this but an article name can certainly change. I quite like using a regex to determine if it's a number or a word, and then searching on the appropriate column (ie. Id vs Name). The computer does the work so we don't have to. Eg: http://eventbot.dryft.net/people/view/13 == http://eventbot.dryft.net/people/view/pir (It's an old site of mine written in an afternoon; if/when I refactor it, those URLs would be more REST-like, ie. http://eventbot.dryft.net/people/(pir|13)/view ) This has the disadvantage that you can't have tags, people, or whatever which are numbers.. but hey, tough. I'm making my rules around here :) 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: CatalystSites.org
On Wed, Apr 16, 2008 at 11:20:40AM +0200, Aristotle Pagaltzis wrote: > * Toby Corkindale <[EMAIL PROTECTED]> [2008-04-16 09:10]: > > Eg: > > http://eventbot.dryft.net/people/view/13 > > == > > http://eventbot.dryft.net/people/view/pir > > > > (It's an old site of mine written in an afternoon; if/when > > I refactor it, those URLs would be more REST-like, ie. > > http://eventbot.dryft.net/people/(pir|13)/view ) > > 1. Why is the `/view` bit necessary at all? It's not! Whoops, yeah, that's another hangover from the "old style" way I coded the site. >(Note: Chained is absolutely *grreat* for taking full >control of your URI space.) I love it and have been using it in all my newer projects. I had a difficult time explaining it to some colleagues though. I mean, they were still struggling to understand how the other attributes worked, and then Chained works so differently from Local that their minds exploded. > 2. URI design is important, but not because it has anything to do >with REST. > >Your URIs could be /aslkdjsad42 and /xyzzysd-291kk1 for all >REST cares. REST is about decoupling server and client from >each other by keeping client state on the client and resource >state on the server and passing representations of resources >back and forth to affect the state on each end. > >In all this, URIs serve purely as identifiers that the client >is expected not to try to interpret in any way at all. Only >the server which has minted a URI is allowed to ascribe any >meaning to it. Really? I thought good URI design was part of "best practices" for REST. *Tries to find the REST book that was on his desk last week* Not that REST is a standard, beyond the requirement to adhere to existing standards :) 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] modperl 1.3 wierdness
Hi guys, I have an application that runs well on modperl 2.0, fcgi and the standalone server.. but due to some stubborn/paranoid sysadmins[1] we are going to have to run it under modperl 1.3. This has resulted in some wierdness I haven't seen before, and I wondered if anyone else had hit it? I'll try and make a working mock-up I can post to the list to demonstrate the problem IF no-one else has seen it before. Given that I have: My::Schema (DBIx::Class::Schema) --> My::Schema::OneTable --> My::Schema::TableTwo and My::App (Catalyst) --> My::App::Model::DB (Catalyst::Model::DBIC::Schema) During Apache start-up I see: - Subroutine My::App::Model::DB::OneTable::ACCEPT_CONTEXT redefined at lib/My/App/Model/DB.pm Subroutine My::App::Model::DB::TableTwo::ACCEPT_CONTEXT redefined at lib/My/App/Model/DB.pm Syntax error on line 7 of apache.conf: Can't locate My/App/Model/DB/OneTable.pm in @INC ([snip]). Compilation failed in require. - This is weird - why is it trying to load the *schema*'s subclasses under the Catalyst's model? (Which of course fails..) 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] modperl 1.3 wierdness
On Mon, Apr 21, 2008 at 04:54:00PM +1000, Toby Corkindale wrote: > Hi guys, > I have an application that runs well on modperl 2.0, fcgi and the standalone > server.. but due to some stubborn/paranoid sysadmins[1] we are going to have > to run it under modperl 1.3. Footnotes: 1) This is their job, to be paranoid and stubborn. 2) We're actually running mod perl 1.29. Ick. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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] modperl 1.3 wierdness
On Mon, Apr 21, 2008 at 04:54:00PM +1000, Toby Corkindale wrote: > Hi guys, > I have an application that runs well on modperl 2.0, fcgi and the standalone > server.. but due to some stubborn/paranoid sysadmins[1] we are going to have > to run it under modperl 1.3. > > This has resulted in some wierdness I haven't seen before, and I wondered if > anyone else had hit it? [snip] > During Apache start-up I see: > - > Subroutine My::App::Model::DB::OneTable::ACCEPT_CONTEXT redefined at > lib/My/App/Model/DB.pm > Subroutine My::App::Model::DB::TableTwo::ACCEPT_CONTEXT redefined at > lib/My/App/Model/DB.pm > Syntax error on line 7 of apache.conf: > Can't locate My/App/Model/DB/OneTable.pm in @INC ([snip]). > Compilation failed in require. > - The above problem was solved by changing the apache config. Before: use lib qw(/my/home/dir); PerlModule My::App After: use lib qw(/my/home/dir); use My::App; I'm still seeing some problems indicating the Plugin::ConfigLoader isn't, well, loading anything, though. Odd. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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] modperl 1.3 wierdness
On Mon, Apr 21, 2008 at 07:23:44PM +0100, Matt S Trout wrote: > On Mon, Apr 21, 2008 at 07:09:26PM +1000, Toby Corkindale wrote: > > The above problem was solved by changing the apache config. > > Before: > > > >use lib qw(/my/home/dir); > > > > PerlModule My::App > > > > After: > > > >use lib qw(/my/home/dir); > >use My::App; > > > > Yep. PerlModule will do double-loading, as documented, which Catalyst can't > handle (and shouldn't need to). > > I suspect you'd've found changing PerlModule to PerlRequire would have done > the trick as well, though my MP1's rusty. As is mine.. I wish we'd move away from it here :( > > I'm still seeing some problems indicating the Plugin::ConfigLoader isn't, > > well, loading anything, though. Odd. > > If you didn't make install it and deleted the Makefile.PL, it's not going to. > > Catalyst uses the presence of Makefile.PL to check if it's running in an > unpacked dist versus running installed; since obviously an unpacked dist > -must- have a Makefile.PL otherwise it's not a valid dist[0] Aaah yes, I remember hitting this way back! That magic Makefile-detection.. Unfortunately due to somewhat unusual app deployment tactics here, apps get "installed" manually, into their own little area, along with their required perl dependencies, thus losing the Makefile.PL, but also requiring that the config file lived in the same non-standard location. (it does kind of make sense..) > Choose one option :) Erm, does stripping out ConfigLoader and replacing it with a similarly operating plugin that knows to look in our company-specific locations count? :) Thanks for the help! -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] Dispatching with Chained vs HTTP method
just looking for some advice on the best way to do something..
So I wrote a controller class using Chained that basically auto-converts any
DBIx::Schema (which includes a tiny extra base class itself) into a REST API..
Well, a simple one anyway - it supports find and search so far, and foreign
keys in the objects get serialised into hashes of the URIs to fetch them.
All working nicely so far, but this is all for GET queries.
But the behaviour should be different depending upon whether you
GET /item/1234
or
DELETE /item/1234
etc.
I was thinking something like this: (Abbreviated code below)
sub item_by_id : Chained CaptureArgs(2) {
my ($self, $c, $type, $id) = @_;
$c->stash->{item} = $c->model("DB:$type")->find($id);
}
sub delete : Chained('item_by_id') Args ActionClass('MethodDELETE') {
my ($self, $c) = @_;
$c->stash->{item}->delete;
}
sub modify : Chained('item_by_id') Args ActionClass('MethodPUT') {
my ($self, $c) = @_;
$c->stash->{item}->update($c->request->params);
}
Then the appropriate ActionClasses would check if the $c->req->method eq 'GET'
or 'DELETE' or whatever.
But I was just wondering if you had other ideas, and if using ActionClasses
with Chained actions is crackfuelled and going to lead to a world of misery and
pain.
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] Dispatching with Chained vs HTTP method
On Wed, Apr 30, 2008 at 11:24:36AM +0200, Zbigniew Lukasiak wrote:
> Hi Toby,
>
> I don't know if you are aware - but building a REST-like CRUD
> interface to DBIx::Schema is my long term goal (started with
> Catalyst::Example::InstantCRUD). Do you think we could collaborate?
Sure, if you liked.
I'm not sure I want to aim for total DBIx::Class:Schema emulation, as I think
there are many corner cases which could start getting hard to implement /well/.
I'd rather approach creating something which does a sub-set of the features,
but does them well. For instance, how would you handle transactions? Or
specifying complex searches with aggregate clauses and self-joins? Those would
seem to be more suited to an RPC protocol rather than an object-based REST
situation. I think?
The system I have so far works quite well for find and search, and I have a
client library which re-vivifies stuff back into Perl DBIC-like objects..
So in theory you can have an application which can operate upon a local
database, OR a remote database, transparently. (As long as it only uses the
simpler DBIC methods)
I'm learning more about the innards of Catalyst and DBIx::Class in the process
too :)
Toby
> On Wed, Apr 30, 2008 at 10:26 AM, Toby Corkindale <[EMAIL PROTECTED]> wrote:
> > just looking for some advice on the best way to do something..
> >
> > So I wrote a controller class using Chained that basically auto-converts
> > any
> > DBIx::Schema (which includes a tiny extra base class itself) into a REST
> > API..
> > Well, a simple one anyway - it supports find and search so far, and foreign
> > keys in the objects get serialised into hashes of the URIs to fetch them.
> >
> > All working nicely so far, but this is all for GET queries.
> >
> > But the behaviour should be different depending upon whether you
> > GET /item/1234
> > or
> > DELETE /item/1234
> > etc.
> >
> > I was thinking something like this: (Abbreviated code below)
> >
> >
> > sub item_by_id : Chained CaptureArgs(2) {
> > my ($self, $c, $type, $id) = @_;
> > $c->stash->{item} = $c->model("DB:$type")->find($id);
> > }
> >
> > sub delete : Chained('item_by_id') Args ActionClass('MethodDELETE') {
> > my ($self, $c) = @_;
> > $c->stash->{item}->delete;
> > }
> >
> > sub modify : Chained('item_by_id') Args ActionClass('MethodPUT') {
> > my ($self, $c) = @_;
> > $c->stash->{item}->update($c->request->params);
> > }
> >
> > Then the appropriate ActionClasses would check if the $c->req->method eq
> > 'GET'
> > or 'DELETE' or whatever.
> >
> > But I was just wondering if you had other ideas, and if using ActionClasses
> > with Chained actions is crackfuelled and going to lead to a world of
> > misery and
> > pain.
> >
> > 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] modperl 1.3 wierdness
On Sat, May 03, 2008 at 11:22:49PM +0100, Matt S Trout wrote:
> On Mon, Apr 28, 2008 at 11:30:53AM +1000, Toby Corkindale wrote:
> > Unfortunately due to somewhat unusual app deployment tactics here, apps get
> > "installed" manually, into their own little area, along with their required
> > perl dependencies, thus losing the Makefile.PL, but also requiring that the
> > config file lived in the same non-standard location.
>
> How about using
>
> __PACKAGE__->config(
> 'Plugin::ConfigLoader' => {
> file => __PACKAGE__->path_to(...)
> }
> );
>
> or setting an environment variable?
The location varies depending on build version and status, but could have been
solved with the env variable part combined with the loader options..
But at the time it was 8pm at night and I wanted to go home, and hacking up a
little DIY loader was quicker than trying to figure out what was going wrong
with the plugin.. You know how it gets sometimes?
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/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] Dispatching with Chained vs HTTP method
On Thu, May 01, 2008 at 08:41:26AM +0200, Zbigniew Lukasiak wrote: > On Thu, May 1, 2008 at 6:23 AM, Toby Corkindale <[EMAIL PROTECTED]> wrote: > > On Wed, Apr 30, 2008 at 11:24:36AM +0200, Zbigniew Lukasiak wrote: > > > Hi Toby, > > > > > > I don't know if you are aware - but building a REST-like CRUD > > > interface to DBIx::Schema is my long term goal (started with > > > Catalyst::Example::InstantCRUD). Do you think we could collaborate? > > > > Sure, if you liked. > > > > I'm not sure I want to aim for total DBIx::Class:Schema emulation, as I > > think there are many corner cases which could start getting hard to > > implement /well/. > > > > I'd rather approach creating something which does a sub-set of the > > features, but does them well. For instance, how would you handle > > transactions? Or > > My understanding is that you can nest transactions in DBIC - so my > plan is just add a transaction wherever I think it is needed. Ah, I was thinking of transactions vs a REST API, eg: PUT /user/1234/account_balance?subtract=1 POST /user/4567/account_balance?add=1 Since those are two separate HTTP requests, and REST specifically states you cannot maintain state on the server, how would you perform those two operations inside a transaction? (My "solution" is to implement it in one request, like: PUT /user/1234/money_transfer?user=4567;amount=1 However that is not CRUD-like, nor a direct mapping of DBIC functionality to REST) > > specifying complex searches with aggregate clauses and self-joins? Those > > would seem to be more suited to an RPC protocol rather than an > > object-based REST situation. I think? > > I admit that my main goal is mostly a kind of browser-REST (but with > the option for 'real' REST) - so I start with HTML forms (for now I > discovered Rose::HTML::Form - and I like it) that would define the > available searches. I guess this might look restricting for you. By > the way have you seen my Advent article: > http://catalyst.perl.org/calendar/2007/16 ? Oh, right. I'm definitely making a 'real' REST interface; I'm basing it around a DBIC Schema for the moment, but I'm not attempting to provide 100% of the DBIC features via REST; I figure if you want that, you can just use a real DB connection. Instead I'm trying to provide a simple set of basic REST calls, and a framework for dealing with foreign keys, and then allow extensions on top of that for things such as the example above where you can't use simple calls. I think it sounds like we're really working towards fairly different goals at the moment. Whereas you're looking at using forms and validation there, I'm more interested in having a DB which provides the validation via constraints and stored procedures, and using Catalyst as a fairly thin layer to access it and provide extensions via the DBIC-SChema class. The REST API has proven quite cute when used against a quickly hacked-up pure javascript web UI though; it's blindingly fast compared to having pages built and served and rendered! 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] Dispatching with Chained vs HTTP method
Hi Adam, On Wed, May 07, 2008 at 03:30:12PM +1000, Adam Clarke wrote: > On 07/05/2008, at 11:05 AM, Toby Corkindale wrote: > >> Ah, I was thinking of transactions vs a REST API, eg: >>PUT /user/1234/account_balance?subtract=1 >>POST /user/4567/account_balance?add=1 >> Since those are two separate HTTP requests, and REST specifically states >> you >> cannot maintain state on the server, how would you perform those two >> operations inside a transaction? >> >> (My "solution" is to implement it in one request, like: >>PUT /user/1234/money_transfer?user=4567;amount=1 >> However that is not CRUD-like, nor a direct mapping of DBIC functionality >> to >> REST) > > The solution suggested in "Restful Web Services" is to POST to a "factory" > resource which creates you with a transaction resource. e.g. "POST > /transactions/account-transfer" returns "Location: > /transactions/account-transfer/11a5", where the 11a5 is a unique > transaction identifier. > > Then "PUT /transactions/account-transfer/11a5/accounts/checking/11", where > 11 is the account identifier. The body carries the transaction details, in > the example the balances are adjusted absolutely, i.e. "balance=150". A > similar PUT is sent for the other account. > > Once the required components of the transaction have been PUT it is > possible to rollback by DELETEing the transaction resource or commit it by > putting "committed=true" to the resource. > > While seeming a bit fiddly, it does keep the state on the client and allows > the client to make (at least some of) the commit / rollback decision rather > than (only) the server. I've read parts of RESTful Web Services, but not that bit.. I'll have to go back and look. I wonder how one goes about implementing such a transaction on the server side.. One would not want to lock DB rows indefinitely, waiting for the client to finally complete the transaction. But if one just recorded the queries and then executed them all (internally) at the end, then other risks exist, eg: $id = POST transaction $amount = GET /user/1/account_balance $amount2 = GET /user/2/account_balance PUT /user/1/account_balance/$amount-1 PUT /user/2/account_balance/$amount+1 PUT transaction/$id?completed In that example, user one might receive their paycheque after you've queried their account balance, but before you've written the new amount. Hmm. I suppose one could try for the method of actually locking the DB rows until the REST completed the transaction, and putting some kind of timeout on it; but anything that does long DB locks scares me with the potential of deadlocks. Have you implemented anything like this? I'm curious to know how well it might work (or not work) in practice. Toby (Who likes REST but still isn't sure about doing double-entry bookkeeping with it) ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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] Dispatching with Chained vs HTTP method
On Wed, May 07, 2008 at 03:57:07PM +1000, Toby Corkindale wrote: [snip] > $id = POST transaction > $amount = GET /user/1/account_balance > $amount2 = GET /user/2/account_balance > PUT /user/1/account_balance/$amount-1 > PUT /user/2/account_balance/$amount+1 Whoops, that should read: > PUT /user/2/account_balance/$amount2+1 Go me and my badly named example variables :/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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] Dispatching with Chained vs HTTP method
On Wed, May 07, 2008 at 09:55:10AM +0200, Zbigniew Lukasiak wrote: > On Wed, May 7, 2008 at 7:57 AM, Toby Corkindale <[EMAIL PROTECTED]> wrote: [snip] > > I wonder how one goes about implementing such a transaction on the server > > side.. One would not want to lock DB rows indefinitely, waiting for the > > client to finally complete the transaction. But if one just recorded the > > queries and then executed them all (internally) at the end, then other > > risks exist, eg: > > > > $id = POST transaction > > $amount = GET /user/1/account_balance > > $amount2 = GET /user/2/account_balance > > PUT /user/1/account_balance/$amount-1 > > PUT /user/2/account_balance/$amount+1 > > PUT transaction/$id?completed > > How about: > > $id = POST transaction > PUT /transaction/$id/payer/1 > PUT /transaction/$id/receiver/2 > PUT /transaction/$id/amount/1 > PUT /transaction/$id?completed > > or even > > $id = POST transaction > PUT /transaction/$id?payer=1;receiver=2;amount=1 > PUT /transaction/$id?completed There are other ways of doing it that would avoid the problem, but I'm just trying to demonstrate potential flaws in any transaction that does not do locking to prevent other things accessing it at the same time. Perhaps I should try another example if the other wasn't clear. Given this series of calls: 1) get value of item 2) get users bank balance if balance > item-value, then: 3) subtract value from bank balance 4) assign item to user What if the internet connection died for 30 seconds between step (2) and (4), and in that 30 seconds, the user bought something elsewhere, thus reducing his or her balance to below the value? That's the sort of race condition that real databases can avoid, because they'll basically stop anyone else modifying the balance after you've checked it, until you commit or rollback the transaction. We could do that too.. But imagine if we locked the user's DB row at step (2).. but then imagine if the internet connection to the person who started the transaction died.. for hours.. and during that time no other transactions could be made! That's not so good either. 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] Dispatching with Chained vs HTTP method
On Wed, May 07, 2008 at 06:02:46PM +1000, Adam Clarke wrote: > On 07/05/2008, at 3:57 PM, Toby Corkindale wrote: >> On Wed, May 07, 2008 at 03:30:12PM +1000, Adam Clarke wrote: >>> >>> The solution suggested in "Restful Web Services" is to POST to a >>> "factory" >>> resource which creates you with a transaction resource. e.g. "POST >>> /transactions/account-transfer" returns "Location: >>> /transactions/account-transfer/11a5", where the 11a5 is a unique >>> transaction identifier. >>> >>> Then "PUT /transactions/account-transfer/11a5/accounts/checking/11", >>> where >>> 11 is the account identifier. The body carries the transaction details, >>> in >>> the example the balances are adjusted absolutely, i.e. "balance=150". A >>> similar PUT is sent for the other account. >>> >>> Once the required components of the transaction have been PUT it is >>> possible to rollback by DELETEing the transaction resource or commit it >>> by >>> putting "committed=true" to the resource. >>> >>> While seeming a bit fiddly, it does keep the state on the client and >>> allows >>> the client to make (at least some of) the commit / rollback decision >>> rather >>> than (only) the server. >> >> I've read parts of RESTful Web Services, but not that bit.. I'll have to go >> back and look. >> >> I wonder how one goes about implementing such a transaction on the server >> side.. One would not want to lock DB rows indefinitely, waiting for the >> client to finally complete the transaction. But if one just recorded the >> queries and then executed them all (internally) at the end, then other risks >> exist, eg: > > I haven't done this before, but I have thought about it a bit. I think I > would handle this as a two-phase commit. PostgreSQL has "PREPARE > TRANSACTION" which allows you to start a transaction and assign it a > "transaction_id" for use with a subsequent "COMMIT TRANSACTION". I would > also use Multi-Version Concurrency Control (MVCC) rather than any kind of > blocking locks to minimise the impact of the longer transaction lifetime. I'm not sure the former command does what we'd like it to - after running it, I don't think you can add any further commands to it; it's merely held in stasis until you commit/rollback it, and you can start another transaction meanwhile. I *think* but I haven't used it either. Regarding the MVCC; that's a rather good idea, although my understanding of postgres is that it will start blocking in conditions where you're updating the same thing. (Edit: Just tested - it seems to) That said, I don't know how other systems handle it, or if in fact the SET SERIALISATION parameter to psql can alter this behaviour.. Are there other MVCC implementations which manage it? You seem to have a good idea about using that rather than locking. Something else occured to me - Have you had any experience at trying to get DB transactions to span connections? Since the HTTP requests could hit different processes for each request (or possibly even different servers in a farm).. I suppose one could push the DB requests to a back-end processing daemon that could ensure a consistent connection was used, but again seems to be tieing up resources if there's a network drop-out. I haven't looked into that at all really though. I was just assuming one might have to use locks as they would span, but that would be ugly, and breaks the concept of not storing state on the server for REST. > This would at least keep a good deal of the hard work in the DB. *nods* I agree that's the best option. I'm mainly familiar with Postgres (and a little of MySQL) so I don't know if the commercial DBs have added features to help with these issues already? ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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] Solved - curious Catalyst/DBIx:Class bug
Found and solved an interesting little bug in someone else's application today.
Their unit tests ran fine, but the application itself always died instantly,
with an error from Class::C3::XS.. so they thought the bug was in DBIx::Class,
or rather their use of it, and we spent a lot of time hunting around there..
and it was really annoying me that we just couldn't reproduce the problem
in unit tests though.. just on an actual apache-based server.
Eventually, hit upon the server's startup.pl.. Turns out that inside it was
a (global) $SIG{__DIE__} handler.. Aargh!
They were using this to try and catch fatal errors in their applications..
Except of course these handlers are completely broken and get called by deaths
in eval{} blocks, thus preventing ANY eval{} code from working.. including the
ones in DBIx::Class and Catalyst. *rolls eyes*
I can't believe their major application has NOT hit this problem before!
I just thought I'd mention it, in case anyone else has to debug something where
cat/dbic is mysteriously dieing - grep for __DIE__!
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] How to display a "Please Wait" page
On Sun, Aug 10, 2008 at 09:22:40PM -0500, Collin Condray wrote:
> I am in the process of creating a website using catalyst. I have a check out
> page that processes payment information and performs some automated tasks
> for the client that takes several seconds to complete. I'd like to display a
> "Please Wait" graphic while these actions are occurring.
>
> I my initial attempt was something like this:
>
> $c->response->redirect( $c->uri_for("/checkout/pleasewait") );
>
> # Do action and payment process
>
> $c->response->redirect( $c->uri_for("/checkout/receipt") );
>
> But that was unsuccessful. I definitely think I'm misunderstanding how
> redirect works. Has anyone else done anything like this before and if so
> what are the steps that need to be taken to make it work?
Do you understand how HTTP redirect works? If so, then understand that the
catalyst response->redirect is essentially exactly the same.
As a result, you can only send one, and when the client receives it, they will
leave the current page.
Perhaps try making pleasewait(), do_payment_process() and receipt() actions.
Send the user to the pleasewait one, which just displays a "Please wait.."
page, and kicks off the payment processing in the background. Have it set up to
move the user over to the receipt() page once things are complete. (You can do
this via javascript, but remember to have a fixed old-school http redirect with
a time-out too, in case the user has an antique browser, or something goes
wrong).
Cheers, Toby
--
Turning and turning in the widening gyre/The falcon cannot hear the falconer;
Things fall apart, the centre cannot hold/Mere anarchy is loosed upon the world
(gpg --recv-key B1CCF88E)
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/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 + DBIC + DBD-Pg + mpm_worker
Hi, I know the Cat cookbook suggests one should use mod_perl only with the preforking MPM.. but I wanted to try with the worker (ie. threaded) MPM anyway. DBD-Pg had some thread-safety work done years ago, and I meant to be fine.. However I'm seeing errors like this one: Couldn't render template "undef error - DBD::Pg::db STORE failed: handle 2 is owned by thread 84e5bf0 not current thread 8fe48f8 (handles can't be shared between threads and your driver may need a CLONE method added) at /usr/lib/perl5/vendor_perl/5.8.8/DBIx/Class/Storage/DBI.pm line 723. I've checked, and I am running a recent version of DBD-Pg, that does indeed have the required CLONE function. (Ver 2.8.6) Are there any known issues with Cat+DBIC+DBD-Pg here? Or maybe I just have screwed something else up.. thanks, Toby PS. I've used DBI, Pg and mpm_worker with modperl some years ago successfully, I'm sure.. but in more recent years I've used lighttpd+fastcgi app servers instead. However I figure it's worth checking back to see how things are going with threaded apache again.. -- Turning and turning in the widening gyre/The falcon cannot hear the falconer; Things fall apart, the centre cannot hold/Mere anarchy is loosed upon the world (gpg --recv-key B1CCF88E) ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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] Cat + DBIC + DBD-Pg + mpm_worker -- Solution
On Tue, Aug 12, 2008 at 02:03:56PM +1000, Toby Corkindale wrote: > Hi, > I know the Cat cookbook suggests one should use mod_perl only with the > preforking MPM.. but I wanted to try with the worker (ie. threaded) MPM > anyway. > > DBD-Pg had some thread-safety work done years ago, and I meant to be fine.. > However I'm seeing errors like this one: > Couldn't render template "undef error - DBD::Pg::db STORE failed: > handle 2 is owned by thread 84e5bf0 not current thread 8fe48f8 (handles > can't > be shared between threads and your driver may need a CLONE method added) at > /usr/lib/perl5/vendor_perl/5.8.8/DBIx/Class/Storage/DBI.pm line 723. > > I've checked, and I am running a recent version of DBD-Pg, that does indeed > have the required CLONE function. (Ver 2.8.6) > > Are there any known issues with Cat+DBIC+DBD-Pg here? Or maybe I just have > screwed something else up.. Following up on this after some more investigation last night.. I was previously using DBIx::Class::Schema::Loader. I swapped to a static DBIx::Class::Schema setup, and the problem vanished.. I had a google around for anyone else with this issue, and found a japanese site I can't understand which looks to be mentioning it too, including a fix. http://d.hatena.ne.jp/holidays-l/20070126/p1 I haven't tried the fix myself, being happy to use a static schema defn. (I prefer those anyway).. but thought I'd pass it on in case it can be applied to the mainline version. Cheers, Toby -- Turning and turning in the widening gyre/The falcon cannot hear the falconer; Things fall apart, the centre cannot hold/Mere anarchy is loosed upon the world (gpg --recv-key B1CCF88E) ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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] GENTOO ebuilds: important change in keywords
Michele Beltrame wrote: Hello all! Gentoo overlays management made the following changes to the ebuilds in the perl-experimental overlay: 1 - All ebuilds in dev-perl are now marked as unstable (~arch). 2 - All archs have been removed except for ~x86 and ~amd64 All packages in the overlays are not intended as stable, so they can't be marked as such. If you use amd64 or x86 you can unmask the ebuilds by adding them to /etc/package.keywords. Yes, they're a lot, so (unless you're using paludis instead of portage) you'll likely want to use autounmask. Thanks for the heads-up.. What a PITA this is :( 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, MVCs and other MVCs
Matt S Trout wrote: On Tue, Nov 04, 2008 at 05:56:51PM +1100, Adam Clarke wrote: Our first experiences of trying to use it were quite frustrating - there were zillions of dependencies to be met and this could take a fair bit of perseverance since they would often fail to install for reasons which were difficult to determine. I believe this situation has improved significantly. If you have a rig capable of installing both XS and non-XS CPAN modules at all, Catalyst -should- install cleanly. If it doesn't, we want to hear about it. Or at least I do. Data::ObjectDriver fails on perl 5.10 - RT #30941 Not sure if that's a requirement of Core catalyst or just one of the Models I was using, though. ... (Doesn't look like a direct dependency according to cpandeps, hmm..) -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/
[Catalyst] Catalyst install failure due to Mouse.pm on Debian Etch
Hi guys, I'm having trouble getting Catalyst to install (via CPAN) on a fresh Debian Etch install. The problem is the dependency Mouse (0.11) fails its unit tests there. (I'd guess due to the older versions of some core packages). I've raised http://rt.cpan.org/Ticket/Display.html?id=41254. Catalyst::Action::RenderView (first module which was wanting Mouse) itself seems to pass its own unit tests after Mouse is force-installed, though. 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?
Aristotle Pagaltzis wrote: * Toby Corkindale <[EMAIL PROTECTED]> [2008-11-27 01:55]: The problem is the dependency Mouse (0.11) fails its unit tests there. Thatâs really the sole solid argument against a flamboyant use-the-CPAN attitude: you end up pulling in heaps of bloat because none of the stuff was written to form a coherent whole: every author uses their own favourite way of doing some common thing so you get four different OO frameworks of varying heft, two different YAML modules, every JSON module there is, etc., all loaded into the same perl process. What a waste. 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. According to the Mouse docs, Mouse supports the most commonly used features of Moose, but runs in 25% of the time. I'm happy if the Catalyst crowd has decided to use a performance-optimised version of a module, but it seems like Mouse has had less testing exposure to "production" systems. (ie. The ancient Perl/CPAN modules running on debian, rhel, etc) (I note that Moose itself passes tests on Debian stable) 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/
