Re: [Catalyst] Catalyst::Plugin::Prototype: current state?
From: Charlie Garrison garri...@zeta.org.au The fix is given in the warning message, eg: __PACKAGE__-config(default_view = 'TT'); # or whatever the name of your view is. Then you have a 'default' view for your app and Catalyst doesn't need to choose one at random. AutoCRUD is adding another view and Catalyst doesn't know which one to use by default. Many thanks to you and Denny for clearing this up for me. I'm using Catalyst::Controller::ActionRole and a custom role to ensure that certain urls can only be accessed by those with admin privileges. I can't tell how to hook this into AutoCRUD. I suppose I could write a custom subclass of the plugin, so this is the least of my issues. How about using C::P::Authorization::ACL, eg: __PACKAGE__-deny_access_unless( /autocrud, [qw/admin/], # user must have role 'admin' ); Actually, after some discussion with the AutoCRUD author, it was generally agreed it would be safer to not integrate AutoCRUD directly into my app. A different app running on a different domain/subdomain and setting security at the server level seems more appropriate. This is because the author made it clear that authz was not a design concern and the internal URLs vary widely. Rather than risk opening up a hole to the database, separating this is much safer. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://blogs.perl.org/users/ovid/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst::Plugin::Prototype: current state?
Good evening, On 22/03/10 at 3:09 AM -0700, Ovid publiustemp-catal...@yahoo.com wrote: Actually, after some discussion with the AutoCRUD author, it was generally agreed it would be safer to not integrate AutoCRUD directly into my app. A different app running on a different domain/subdomain and setting security at the server level seems more appropriate. This is because the author made it clear that authz was not a design concern and the internal URLs vary widely. Rather than risk opening up a hole to the database, separating this is much safer. I'd really like to get more info on that. Looking at all the actions for my app in the debug output on startup, I can see lots of private and chained actions for AutoCRUD, and they are all under the /autocrud path. What part of AutoCRUD is accessed outside the /autocrud path? AutoCRUD is very nice convenience, but it's not so nice to warrant running a separate app for it. To me, *having* to run a separate app indicates a design flaw. And if that's the case then I need to look at alternate solutions. (Note, I'm not against server-level auth, and I use it for other things outside my app, but within the app.) Is the author on this list? Can you provide any further insight into why authz for the /autocrud path is not sufficient? I'm somewhat baffled that a tool which effectively allows full access to the DBIC model doesn't at least consider authz as part of the design. Sorry, there's lots of red flags waving around and I'm not sure whether I should pay attention to them. Thanks, Charlie -- Ꮚ Charlie Garrison ♊ garri...@zeta.org.au 〠 PO Box 141, Windsor, NSW 2756, Australia O ascii ribbon campaign - stop html mail - www.asciiribbon.org http://www.ietf.org/rfc/rfc1855.txt ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst::Plugin::Prototype: current state?
- Original Message From: Charlie Garrison garri...@zeta.org.au I'd really like to get more info on that. Looking at all the actions for my app in the debug output on startup, I can see lots of private and chained actions for AutoCRUD, and they are all under the /autocrud path. What part of AutoCRUD is accessed outside the /autocrud path? AutoCRUD is very nice convenience, but it's not so nice to warrant running a separate app for it. To me, *having* to run a separate app indicates a design flaw. And if that's the case then I need to look at alternate solutions. (Note, I'm not against server-level auth, and I use it for other things outside my app, but within the app.) I can't answer these questions. I can only refer you to the rt queue discussion: https://rt.cpan.org/Ticket/Display.html?id=55742 I didn't see creating a separate app and securing it at the server level as being a big deal (for me, your mileage may vary). It seemed easy enough that I wasn't terribly inclined to look further at potential security holes by integrating AutoCRUD directly (I'm very concerned about security for this app and if I see an easy route to better security, I'm going to take it). If you want all or nothing AutoCRUD, this may not be an issue. If you desperately need fine-grained control, it could be complicated. Again, see the RT discussion. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog - http://blogs.perl.org/users/ovid/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst::Plugin::Prototype: current state?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Charlie, I'm the author of AutoCRUD, and fully support the route Ovid has taken, indeed it's how we use AutoCRUD at my workplace: under its own Apache Location with specific Apache ACLs for admin staff. On 22/03/2010 11:32, Charlie Garrison wrote: What part of AutoCRUD is accessed outside the /autocrud path? You might be misunderstanding how AutoCRUD works. The /autocrud base is just a default - you can set this to something else or even . That means I cannot tell you what paths to protect, you need to work it out for yourself, although they will be self-contained. If you want to control access on a per-table basis, then your ACLs are based on path parts which are constructed on the fly from your DB schema and table names, and there is a risk you will get it wrong. It's not even easy for me to document, because schema and table names are not transposed literally into the path. To me, *having* to run a separate app indicates a design flaw. And if that's the case then I need to look at alternate solutions. I'm somewhat baffled that a tool which effectively allows full access to the DBIC model doesn't at least consider authz as part of the design. I think you're a little wide of the mark here. There are many CRUD solutions for Catalyst/DBIC, each with strengths and weaknesses. As t0m put it very well in another thread: AutoCRUD is very simple and easy to use, works like a charm and also gives you absolutely no configurability. If you want tight control over how your CRUD works then build the CRUD yourself using one of the other frameworks[1]. Please don't criticize AutoCRUD for not addressing a given feature - there are any number of use cases where the plugin is perfectly adequate. regards, oliver. [1] e.g. CatalystX::CRUD, CatalystX::CRUD::YUI or Catalyst::Manual - -- Oliver Gorwits, Network and Telecommunications Group, Oxford University Computing Services -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkunYoIACgkQ2NPq7pwWBt5IcwCdE24XYlBpYzDF3oBJsnhcJw6Y jY0AoOTN/N6JXedk+qNjWmtQoxgW1ljy =FY4w -END PGP SIGNATURE- ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst::Plugin::Prototype: current state?
Good evening, On 22/03/10 at 4:41 AM -0700, Ovid publiustemp-catal...@yahoo.com wrote: I can't answer these questions. I can only refer you to the rt queue discussion: https://rt.cpan.org/Ticket/Display.html?id=55742 Thanks, that answered some things, but also just made others even more confusing. Your comment: This is because the author made it clear that authz was not a design concern and the internal URLs vary widely. Rather than risk opening up a hole to the database, separating this is much safer. But the author says in the RT ticket: Having said that, you should be able to match on the AutoCRUD paths within your custom ACL role because they are quite predictable: /autocrud/* - obviously just your admins /autocrud/db-name/table will be the page for any table So, while the URLs may vary widely, they are quite predictable. Maybe this discussion went off track about being able to specify different authz for different portions of AutoCRUD. I'm happy with a simple 'any admin can access the whole db' approach. In which case the ACL for /autocrud should be sufficient. Or am I missing something? In that ticket the AutoCRUD author also states: This has more to do with the philosophy of AutoCRUD. It's meant as a tool for the application developer more than the end user, so I have never focused on authZ. And that sort of makes sense, but who is the end-user? Is it my $customer, or is it their users of the site? For me, the end-user is my $customer and I want to give them full access to the database. And AutoCRUD seems like a simple way to achieve that. For the app developer, AutoCRUD seems like a toy; I need much better/direct db access than is available via AutoCRUD. So, for the developer, AutoCRUD is a weak tool, and for the end-user there is no 'proper' support for authz. There seems to be a big gap. Anyway, for now I'm going with the comment AutoCRUD paths ... are quite predictable, and rely on the ACL plugin to give the desired authz. I didn't see creating a separate app and securing it at the server level as being a big deal (for me, your mileage may vary). Between the different devs ( even some developers), the test server, production server, etc. it's not trivial to simply add another app. Of course it's doable, but I'd prefer to spend my efforts on app development than helping designers install/configure a second app. So, thanks for bringing up this issue. It has made me aware of some limitations that I hadn't looked at before. And if anyone thinks that using the Auth::ACL plugin for protecting direct db access (eg. /autocrud) is a bad idea, please share your thoughts. Thanks, Charlie -- Ꮚ Charlie Garrison ♊ garri...@zeta.org.au 〠 PO Box 141, Windsor, NSW 2756, Australia O ascii ribbon campaign - stop html mail - www.asciiribbon.org http://www.ietf.org/rfc/rfc1855.txt ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst::Plugin::Prototype: current state?
Good morning, Thanks for the reply, and that means much of my previous message can be ignored. On 22/03/10 at 12:28 PM -, Oliver Gorwits oliver.gorw...@oucs.ox.ac.uk wrote: On 22/03/2010 11:32, Charlie Garrison wrote: What part of AutoCRUD is accessed outside the /autocrud path? You might be misunderstanding how AutoCRUD works. The /autocrud base is just a default - you can set this to something else or even . That means I cannot tell you what paths to protect, you need to work it out for yourself, although they will be self-contained. The self-contained part is what I really wanted to know. I'm aware the base can change to something else; I'm fine with that. If you want to control access on a per-table basis, then your ACLs are based on path parts which are constructed on the fly from your DB schema and table names, and there is a risk you will get it wrong. It's not even easy for me to document, because schema and table names are not transposed literally into the path. Thanks, but I'm just looking for a shotgun (all or nothing) approach. I think you're a little wide of the mark here. There are many CRUD solutions for Catalyst/DBIC, each with strengths and weaknesses. As t0m put it very well in another thread: AutoCRUD is very simple and easy to use, works like a charm and also gives you absolutely no configurability. The easy to use part is why I chose it. I wanted something easy for my customers to use, and easy for me to implement. And AutoCRUD meets those criteria *very* well. If you want tight control over how your CRUD works then build the CRUD yourself using one of the other frameworks[1]. Please don't criticize AutoCRUD for not addressing a given feature - there are any number of use cases where the plugin is perfectly adequate. Sorry, it was not meant as a criticism. Apologies if it came across that way. It was my confusion on what the target audience for it is. I honestly don't see the benefit as a 'developers tool'. That is only my opinion. I do see great benefit for end-users though. I can see lots of work has gone into AutoCRUD it's great for what it does. So, apologies if I wasn't clear; it's really been one of those days. I like AutoCRUD; I just want to make sure I'm using it the right way. And there seemed to be conflicting information which just confused me. Thanks again for your reply, hopefully I've cleared up why I made my comments. Charlie -- Ꮚ Charlie Garrison ♊ garri...@zeta.org.au 〠 PO Box 141, Windsor, NSW 2756, Australia O ascii ribbon campaign - stop html mail - www.asciiribbon.org http://www.ietf.org/rfc/rfc1855.txt ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] application broke once installed under other than the web root directory
Could anyone point me to docs that say what needs to be changed to get the app to work when installed as an application in a pre-existing apache setup? my app is installed under http://myurl.com/myapp and can't run directly from / as this app is just one of many tools running on the webserver. Thanks, C --- On Sun, 3/21/10, Charles cshtr...@yahoo.com wrote: From: Charles cshtr...@yahoo.com Subject: [Catalyst] application broke once installed under other than the web root directory To: Catalyst@lists.scsys.co.uk Date: Sunday, March 21, 2010, 1:18 PM I have finished development of my app using the built in server in the scripts dir. I have installed it and configured apache to let it run under http://myurl.com/myapp . The Root.pm index controller get's called and works ( fetches db table data and returns via TT ) when I visit http://myurl.com/myapp. And the debug output is here: [debug] GET request for / from x.x.x.x [debug] Path is / [debug] Rendering template welcome.tt2 However, when I try to go to http://myurl.com/myapp/foo/bar/2 , I get page not found, and my debug output shows: [debug] GET request for myapp/foo/bar/2 from x.x.x.x [debug] Path is / [debug] Arguments are myapp/foo/bar/2 I tried setting __PACKAGE__-config( path = '/myapp' ); But that doesn't seem to have any effect. So, I guess I'd like to know how to set the Path above so that it will ( hopefully ) map to the correct controllers. This all worked just dandy when run via the server in the scripts dir. I'm currently running Catalyst 5.80020 and my working apache config contains: Perl use lib qw ( /usr/local/myapp/lib ); /Perl PerlModule myapp Alias /myapp /usr/local/myapp Directory /usr/local/myapp SetHandler perl-script PerlResponseHandler myapp /Directory Any hlp apprec, -C ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] application broke once installed under other than the web root directory
On 22 March 2010 17:04, Charles cshtr...@yahoo.com wrote: Could anyone point me to docs that say what needs to be changed to get the app to work when installed as an application in a pre-existing apache setup? my app is installed under http://myurl.com/myapp and can't run directly from / as this app is just one of many tools running on the webserver. Thanks, C Does this help? http://search.cpan.org/~hkclark/Catalyst-Manual-5.8004/lib/Catalyst/Manual/Cookbook.pod#Non-root_location Dp. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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] Configuring individual models via config file with DBIx::Class:Schema
I have an application using DBIx::Class::Schema. In the
application config file, I have:
Model::DB
schema_class MyApp::Schema
connect_info
...various necessary stuff here...
/connect_info
/Model::DB
Controller::One
someattribute value
/Controller::One
DB::Two
anotherattribute anothervalue
/DB::Two
The first two of these blocks do what I expect -- my models
get build from the Schema/Result files, I get connections, etc.
And in Controller/One.pm, I can access $self-{someattribute}
But I can't for the life of my figure out how I can get anotherattribute
into the config for an individual model based on the schema.
That is, I'd like methods in DB::Two objects to have access
to $self-{anotherattribute}
In addition to the above, I have tried:
* Variations on the config block (myapp::Model::DB::Two, Model::DB::Two,
Two, even MyApp::Schema::Result::Two)
* Putting that block within the Model::DB block, again with all
those variations
I haven't found the answer so far in searching this mailing list
or the web. Is this possible? What am I missing here?
Thanks in advance!
- Alan
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/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] Slow Makefile.PL
Hi all, I'm not sure what I did, but recently, my perl Makefile.PL run time dropped from 4 minutes down to about 40 seconds. The latter still seems rather slow. A generic Makefile.PL on my box (generated with catalyst.pl MyApp) takes about 1.5 seconds to run. The slowdown appears to be when the Makefile.PL hits the catalyst; line. Devel::NYTProf shows it's I/O slowing things down (sorry for the rubbish formatting): Top 15 Subroutines — ordered by exclusive time Calls P F Exclusive Time Inclusive Time Subroutine 2556 1 2 20.0s 20.0s File::Copy::CORE:sysread (opcode) 1274 1 2 5.19s 5.19s File::Copy::CORE:syswrite (opcode) 2636 3 2 1.87s 1.87s File::Copy::CORE:close (opcode) 142 1 2 796ms 796ms Cwd::CORE:backtick (opcode) 2708 2 2 781ms 781ms File::Copy::CORE:open (opcode) 36 1 1 749ms 5.78s Module::AutoInstall::_load 2844 3 2 463ms 463ms File::Copy::Recursive::CORE:chmod (opcode) 26 2 2 303ms 303ms Module::Install::Admin::CORE:close (opcode) 1 1 1 208ms 214ms MooseX::Types::be...@11 1354 1 1 205ms 28.1s File::Copy::copy 14 1 2 181ms 181ms DynaLoader::dl_load_file (xsub) 72 2 1 172ms 236ms Module::Install::__ANON__[inc/Module/Install.pm:324] 1 1 1 155ms 254ms Module::Install::Admin::Metadata::dump_meta 28 1 1 155ms 2.52s Class::MOP::__ANON__[Class/MOP.pm:103] 5706 6 2 153ms 153ms File::Copy::Recursive::CORE:stat (opcode) Does this look familiar to anyone? You can see right away that File::Copy::CORE::sysread is taking 20 seconds. Is a total runtime of 40 seconds a *normal* response time on running Makefile.PL? This is a relatively new project and I'm often rebuilding from scratch. That extra 40 seconds seems like a lot. This is perl 5.10.1 (OS X Snow Leopard) and there are currently only 36 .pm files in the lib/ directory. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog - http://blogs.perl.org/users/ovid/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Slow Makefile.PL
Wow, is that on an NFS-mounted partition or something? Something is very wrong. Cheers, Peter On Mar 22, 2010 7:24 PM, Ovid publiustemp-catal...@yahoo.com wrote: Hi all, I'm not sure what I did, but recently, my perl Makefile.PL run time dropped from 4 minutes down to about 40 seconds. The latter still seems rather slow. A generic Makefile.PL on my box (generated with catalyst.plMyApp) takes about 1.5 seconds to run. The slowdown appears to be when the Makefile.PL hits the catalyst; line. Devel::NYTProf shows it's I/O slowing things down (sorry for the rubbish formatting): Top 15 Subroutines — ordered by exclusive time Calls P F Exclusive Time Inclusive Time Subroutine 2556 1 2 20.0s 20.0s File::Copy::CORE:sysread (opcode) 1274 1 2 5.19s 5.19s File::Copy::CORE:syswrite (opcode) 2636 3 2 1.87s 1.87s File::Copy::CORE:close (opcode) 142 1 2 796ms 796ms Cwd::CORE:backtick (opcode) 2708 2 2 781ms 781ms File::Copy::CORE:open (opcode) 36 1 1 749ms 5.78s Module::AutoInstall::_load 2844 3 2 463ms 463ms File::Copy::Recursive::CORE:chmod (opcode) 26 2 2 303ms 303ms Module::Install::Admin::CORE:close (opcode) 1 1 1 208ms 214ms MooseX::Types::be...@11 1354 1 1 205ms 28.1s File::Copy::copy 14 1 2 181ms 181ms DynaLoader::dl_load_file (xsub) 72 2 1 172ms 236ms Module::Install::__ANON__[inc/Module/Install.pm:324] 1 1 1 155ms 254ms Module::Install::Admin::Metadata::dump_meta 28 1 1 155ms 2.52s Class::MOP::__ANON__[Class/MOP.pm:103] 5706 6 2 153ms 153ms File::Copy::Recursive::CORE:stat (opcode) Does this look familiar to anyone? You can see right away that File::Copy::CORE::sysread is taking 20 seconds. Is a total runtime of 40 seconds a *normal* response time on running Makefile.PL? This is a relatively new project and I'm often rebuilding from scratch. That extra 40 seconds seems like a lot. This is perl 5.10.1 (OS X Snow Leopard) and there are currently only 36 .pm files in the lib/ directory. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog - http://blogs.perl.org/users/ovid/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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] Slow Makefile.PL
From: Peter Edwards pe...@dragonstaff.co.uk To: The elegant MVC web framework catalyst@lists.scsys.co.uk Sent: Mon, 22 March, 2010 19:30:13 Subject: Re: [Catalyst] Slow Makefile.PL Wow, is that on an NFS-mounted partition or something? Something is very wrong. Nope. It's on my Macbook Pro's hard drive. I've been meaning to dig into it more, but I was hoping someone might magically *know* what this issue is and save me the trouble :) Cheers, Ovid-- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog - http://blogs.perl.org/users/ovid/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Slow Makefile.PL
On Mon, Mar 22, 2010 at 3:20 PM, Ovid publiustemp-catal...@yahoo.com wrote: Does this look familiar to anyone? I don't use the Makefile.PL all that often so I hadn't noticed, but my 10.6.2 box reports similar results: Total Elapsed Time = 50.86615 Seconds User+System Time = 48.08246 Seconds Exclusive Times %Time ExclSec CumulS #Calls sec/call Csec/c Name 93.5 44.96 44.967441 0.1020 0.1020 File::Copy::copy 2.55 1.228 1.229 13 0.0944 0.0945 Module::Install::Admin::copy 1.76 0.846 45.744 1042 0.0008 0.0439 File::Copy::Recursive::__ANON__ [...] If I move this out of my home directory and into /tmp it's as fast as you'd expect. My guess is that FileVault is slowing things down. k. -- kevin montuori ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Slow Makefile.PL
- Original Message From: kevin montuori montu...@gmail.com I don't use the Makefile.PL all that often so I hadn't noticed, but my 10.6.2 box reports similar results: Total Elapsed Time = 50.86615 Seconds If I move this out of my home directory and into /tmp it's as fast as you'd expect. My guess is that FileVault is slowing things down. Yeah, I'm using FileVault. I've had a couple of issues with it already. I think it's time for me to rethink things. Cheers for that! Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog - http://blogs.perl.org/users/ovid/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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] stress testing catalyst apps
Hi, we have an app working under apache/mod_perl (and behind a reverse proxy) that we would like to optimize. We're currently evaluating performance, checking memory usage, etc. For this we thought about using some stress testing package that would be flexible in allowing us to specify a number of specific actions (in the form of URIs) corresponding to a standard user session. Any software you'd recommend for this task? Something from CPAN? Ideally we'd like something that would also provide us with some report on what happened ... Thanks in advance, -- fernan ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/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: Which C::View::PDF should I use?
On Tue, Mar 16, 2010 at 2:53 PM, Aristotle Pagaltzis pagalt...@gmx.dewrote: * Gabriel Andrade gabi...@gmail.com [2010-03-16 16:50]: http://code.google.com/p/wkhtmltopdf/ That looks interesting, thanks! * Adam Sjøgren a...@koldfront.dk [2010-03-16 18:15]: An alternative could perhaps be CutyCapt: * http://cutycapt.sourceforge.net/ It requires an X11 server, so it isn’t. Xvfb has been the solution to this forever. -Wade The wkhtmltopdf doesn’t make it easy either: it requires a patched Qt for that. But at least it’s possible at all. Regards, -- Aristotle Pagaltzis // http://plasmasturm.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::Plugin::Prototype: current state?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Charlie, On 22/03/2010 13:08, Charlie Garrison wrote: The self-contained part is what I really wanted to know. I'm aware the base can change to something else; I'm fine with that. I'm just looking for a shotgun (all or nothing) approach. In which case yes, I would leave the default path base of /autocrud (or set it to something else), and then place a single ACL on that - all AutoCRUD operations will be protected. regards, oliver. - -- Oliver Gorwits, Network and Telecommunications Group, Oxford University Computing Services -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkun8ZkACgkQ2NPq7pwWBt4ZrQCfU3XNNn2m7Uf+EKHTpPsCUH7z T4UAoJGYKXRMoUh5RYnMVO0YhMf0j0Go =faIi -END PGP SIGNATURE- ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
