[Catalyst] Catalyst vs Rails vs Django Cook off
I really don't want to start a bashing session, but I have some concerns that those much more knowledgeable than me should hopefully be able to clarify. Recently, I saw this article via Catalyst Planet: http:// letsgetdugg.com/feed/view/Catalyst_vs_Rails_vs_Django_Cook_off Essentially, according to his test, which doesn't take into account ORM performance, Rails Django knock the socks of Catalyst. In victori's remarks, he calls for a change in Catalyst and points to the other advantages to to this framework, mostly related to ease of coding. While the whole reason I came to Catalyst is because I'm comfortable with Perl and don't want to learn Ruby, I'm worried that my Catalyst application won't perform as well when/if my app usage becomes very significant. Should I be concerned? Again, I'm not interesting in hearing about how Rails/Ruby/Django/ Python sucks, but in facts about real performance of Catalyst. Many thanks, Conan. ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Non-real world irrelevant benchmarks
[EMAIL PROTECTED] wrote: In victori's remarks, he calls for a change in Catalyst and points to the other advantages to to this framework, mostly related to ease of coding. While the whole reason I came to Catalyst is because I'm comfortable with Perl and don't want to learn Ruby, I'm worried that my Catalyst application won't perform as well when/if my app usage becomes very significant. Should I be concerned? No. Six apart certainly aren't, given http://vox.com/ is a Catalyst app. Again, I'm not interesting in hearing about how Rails/Ruby/Django/Python sucks, but in facts about real performance of Catalyst. The reality is that victori's benchmark successfully measures only the base overhead of a request in an app with very few URL endpoints; Catalyst's dispatch mechanism is optimised for speed of dispatch for large applications and for allowing complex dispatch logic elegantly. Besides which, I've never yet seen a production application (and between Shadowcat's client portfolio I've seen not a small number thereof) where the dispatch overhead was even statistically significant to the overall performance - the bottleneck has always been either data retrieval or template rendering. -- Matt S Trout Offering custom development, consultancy and support Technical Directorcontracts for Catalyst, DBIx::Class and BAST. Contact Shadowcat Systems Ltd. mst (at) shadowcatsystems.co.uk for more information + Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ + ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: Re: [Catalyst] Catalyst vs Rails vs Django Cook off
On 11/16/06, Carl Franks [EMAIL PROTECTED] wrote: On 16/11/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Essentially, according to his test, which doesn't take into account ORM performance, Rails Django knock the socks of Catalyst. snip The first thing I noticed was that the content length of the document served by catalyst was longer than that served by rails. He doesn't seem to have tried very hard to test apples for apples (his words) Also see the very good comment by JayK as to why it's not a very good real-world test at all. http://letsgetdugg.com/view/Catalyst_vs_Rails_vs_Django_Cook_off I'm not saying Catalyst's performance couldn't be improved, or that it's not slower than Rails - just that a bad benchmark is worthless. I agree with all your points Carl. I have not been present in teh IRC for a few days to see any discussions related to this thread. I'm sure some optimizations were discussed and some things will be implemented because of it. So with the precondition that I haven't kept up with the state of affairs I'd like to thank victori for spending his time and effort to create _something_. It's more than his naysayers have to done to show us how fast Catalyst is. I respectfully suggest that those who criticize his work should use their energies to /improve/ his test rather than merely dismissing it as worthless. Using his code as a base, couldn't one create a test that was more fair? Then someone would have a test that shows results that are more 'real' and give potential users more information with which to make a decision. Catalyst doesn't have to be the fastest in such a test. That's probably never been the One True Goal of the core devs. But providing people with information as to why Catalyst is good (or bad) should be high on the list. -- Cory 'G' Watson http://www.onemogin.com ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Non-real world irrelevant benchmarks
On 11/16/06, Matt S Trout [EMAIL PROTECTED] wrote: Besides which, I've never yet seen a production application (and between Shadowcat's client portfolio I've seen not a small number thereof) where the dispatch overhead was even statistically significant to the overall performance - the bottleneck has always been either data retrieval or template rendering. This makes me wonder if these high traffic Catalyst sites are using TT or another templating solution. If they are using TT, it should be very helpful if someone published a sort of TT performance guide. Or at least a bulleted list with things not to do because I'm probably doing them all, given the current (lack of) speed from my applications without that much traffic. Any complex (or just plain big) page will take around 3-4 seconds to render with 90% of that time being spent with TT. The best work around was to use one of the caching plugins where I could, but users still have to experience crappy load times whenever something is updated on the database. Thankfully, it's an internal system - so it's not *that* critical. -Nilson Santos F. Jr. ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst vs Rails vs Django Cook off
Carl Franks wrote: On 16/11/06, Cory Watson [EMAIL PROTECTED] wrote: On 11/16/06, Carl Franks [EMAIL PROTECTED] wrote: On 16/11/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Essentially, according to his test, which doesn't take into account ORM performance, Rails Django knock the socks of Catalyst. snip The first thing I noticed was that the content length of the document served by catalyst was longer than that served by rails. He doesn't seem to have tried very hard to test apples for apples (his words) Also see the very good comment by JayK as to why it's not a very good real-world test at all. http://letsgetdugg.com/view/Catalyst_vs_Rails_vs_Django_Cook_off I'm not saying Catalyst's performance couldn't be improved, or that it's not slower than Rails - just that a bad benchmark is worthless. I agree with all your points Carl. I have not been present in teh IRC for a few days to see any discussions related to this thread. I'm (me either) sure some optimizations were discussed and some things will be implemented because of it. So with the precondition that I haven't kept up with the state of affairs I'd like to thank victori for spending his time and effort to create _something_. It's more than his naysayers have to done to show us how fast Catalyst is. I respectfully suggest that those who criticize his work should use their energies to /improve/ his test rather than merely dismissing it as worthless. Using his code as a base, couldn't one create a test that was more fair? Then someone would have a test that shows results that are more 'real' and give potential users more information with which to make a decision. From the off-list discussion I've already had, I know my use of the word 'worthless' will haunt me ;) If a benchmark reveals something in the framework core which could be optimised, then that's great. If it helps teach more effective idioms, or highlights something that shouldn't be used, then that's great. But other than that, I don't think any application benchmark will have much worth other than for that specific application. If I wanted to serve static pages (as the benchmark did), I wouldn't use a framework and then pipe them through TT. The reason I use a framework, is because I want to write a big application with lots of pages, and have things like sessions, ORM, templates. I don't see /how/ the benchmark can be improved. Once you start getting into something that complicated, all you're testing is the way 1 person writes the application in perl compared to how they write it in ruby. Someone else might use a different session storage-backend, which would have different results, and your 'fastest' framework now isn't. Catalyst doesn't have to be the fastest in such a test. That's probably never been the One True Goal of the core devs. But providing people with information as to why Catalyst is good (or bad) should be high on the list. Carl /me puts on flame suit. I agree overall. However... I think the fact still remains that new end users will see three frameworks [all of which were destined for serving more than static pages] where 2 of them serve the static content fast, and one doesn't [Catalyst]. Regardless of whether the test is 'real world', and regardless of whether the frameworks 'were meant to serve more complicated things', Catalyst is slower in this instance. All things being unequal, if I tell my boss we have 3 frameworks to choose from, and one is flexible, and the others are fast, he's going to choose fast every time...even knowing the testing may be faulty. Yes, I know better. He probably does too. But that's how the world works. I always fall on the side of the non majority it seems, and this is another example. [The list, not you specifically] Stop being defensive that the test is bogus. It's not. It shows that in one circumstance, Catalyst is sadly slow. Let's fix that. Explaining why the test may be invalid, or why it's bunk still won't change that fact that in this circumstance, it sucks. /me removes suit and goes back to writing tests -=Chris signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst vs Rails vs Django Cook off
On 16/11/06, Christopher H. Laco [EMAIL PROTECTED] wrote: Carl Franks wrote: On 16/11/06, Cory Watson [EMAIL PROTECTED] wrote: On 11/16/06, Carl Franks [EMAIL PROTECTED] wrote: On 16/11/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Essentially, according to his test, which doesn't take into account ORM performance, Rails Django knock the socks of Catalyst. snip The first thing I noticed was that the content length of the document served by catalyst was longer than that served by rails. He doesn't seem to have tried very hard to test apples for apples (his words) Also see the very good comment by JayK as to why it's not a very good real-world test at all. http://letsgetdugg.com/view/Catalyst_vs_Rails_vs_Django_Cook_off I'm not saying Catalyst's performance couldn't be improved, or that it's not slower than Rails - just that a bad benchmark is worthless. I agree with all your points Carl. I have not been present in teh IRC for a few days to see any discussions related to this thread. I'm (me either) sure some optimizations were discussed and some things will be implemented because of it. So with the precondition that I haven't kept up with the state of affairs I'd like to thank victori for spending his time and effort to create _something_. It's more than his naysayers have to done to show us how fast Catalyst is. I respectfully suggest that those who criticize his work should use their energies to /improve/ his test rather than merely dismissing it as worthless. Using his code as a base, couldn't one create a test that was more fair? Then someone would have a test that shows results that are more 'real' and give potential users more information with which to make a decision. From the off-list discussion I've already had, I know my use of the word 'worthless' will haunt me ;) If a benchmark reveals something in the framework core which could be optimised, then that's great. If it helps teach more effective idioms, or highlights something that shouldn't be used, then that's great. But other than that, I don't think any application benchmark will have much worth other than for that specific application. If I wanted to serve static pages (as the benchmark did), I wouldn't use a framework and then pipe them through TT. The reason I use a framework, is because I want to write a big application with lots of pages, and have things like sessions, ORM, templates. I don't see /how/ the benchmark can be improved. Once you start getting into something that complicated, all you're testing is the way 1 person writes the application in perl compared to how they write it in ruby. Someone else might use a different session storage-backend, which would have different results, and your 'fastest' framework now isn't. Catalyst doesn't have to be the fastest in such a test. That's probably never been the One True Goal of the core devs. But providing people with information as to why Catalyst is good (or bad) should be high on the list. Carl /me puts on flame suit. I agree overall. However... I think the fact still remains that new end users will see three frameworks [all of which were destined for serving more than static pages] where 2 of them serve the static content fast, and one doesn't [Catalyst]. Regardless of whether the test is 'real world', and regardless of whether the frameworks 'were meant to serve more complicated things', Catalyst is slower in this instance. All things being unequal, if I tell my boss we have 3 frameworks to choose from, and one is flexible, and the others are fast, he's going to choose fast every time...even knowing the testing may be faulty. Yes, I know better. He probably does too. But that's how the world works. I always fall on the side of the non majority it seems, and this is another example. [The list, not you specifically] Stop being defensive that the test is bogus. It's not. I agree with everything up to here. It shows that in one circumstance, Catalyst is sadly slow. Let's fix that. Matt has just pointed out that Cat's optimised for large applications with lots of paths, and for flexible programming. Only fix it if that doesn't compromise this, which is more important than looking good in one flawed benchmark. Explaining why the test may be invalid, or why it's bunk still won't change that fact that in this circumstance, it sucks. Catalyst sucks because it doesn't come with a pony, so let's hope the next benchmark to hit the web doesn't benchmark against that ;) /me removes suit and goes back to writing tests Um, shouldn't you leave the suit on until you've received the replies? I hope it wasn't needed anyway Carl ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst vs Rails vs Django Cook off
Carl Franks wrote: On 16/11/06, Christopher H. Laco [EMAIL PROTECTED] wrote: Carl Franks wrote: On 16/11/06, Cory Watson [EMAIL PROTECTED] wrote: On 11/16/06, Carl Franks [EMAIL PROTECTED] wrote: On 16/11/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Essentially, according to his test, which doesn't take into account ORM performance, Rails Django knock the socks of Catalyst. snip The first thing I noticed was that the content length of the document served by catalyst was longer than that served by rails. He doesn't seem to have tried very hard to test apples for apples (his words) Also see the very good comment by JayK as to why it's not a very good real-world test at all. http://letsgetdugg.com/view/Catalyst_vs_Rails_vs_Django_Cook_off I'm not saying Catalyst's performance couldn't be improved, or that it's not slower than Rails - just that a bad benchmark is worthless. I agree with all your points Carl. I have not been present in teh IRC for a few days to see any discussions related to this thread. I'm (me either) sure some optimizations were discussed and some things will be implemented because of it. So with the precondition that I haven't kept up with the state of affairs I'd like to thank victori for spending his time and effort to create _something_. It's more than his naysayers have to done to show us how fast Catalyst is. I respectfully suggest that those who criticize his work should use their energies to /improve/ his test rather than merely dismissing it as worthless. Using his code as a base, couldn't one create a test that was more fair? Then someone would have a test that shows results that are more 'real' and give potential users more information with which to make a decision. From the off-list discussion I've already had, I know my use of the word 'worthless' will haunt me ;) If a benchmark reveals something in the framework core which could be optimised, then that's great. If it helps teach more effective idioms, or highlights something that shouldn't be used, then that's great. But other than that, I don't think any application benchmark will have much worth other than for that specific application. If I wanted to serve static pages (as the benchmark did), I wouldn't use a framework and then pipe them through TT. The reason I use a framework, is because I want to write a big application with lots of pages, and have things like sessions, ORM, templates. I don't see /how/ the benchmark can be improved. Once you start getting into something that complicated, all you're testing is the way 1 person writes the application in perl compared to how they write it in ruby. Someone else might use a different session storage-backend, which would have different results, and your 'fastest' framework now isn't. Catalyst doesn't have to be the fastest in such a test. That's probably never been the One True Goal of the core devs. But providing people with information as to why Catalyst is good (or bad) should be high on the list. Carl /me puts on flame suit. I agree overall. However... I think the fact still remains that new end users will see three frameworks [all of which were destined for serving more than static pages] where 2 of them serve the static content fast, and one doesn't [Catalyst]. Regardless of whether the test is 'real world', and regardless of whether the frameworks 'were meant to serve more complicated things', Catalyst is slower in this instance. All things being unequal, if I tell my boss we have 3 frameworks to choose from, and one is flexible, and the others are fast, he's going to choose fast every time...even knowing the testing may be faulty. Yes, I know better. He probably does too. But that's how the world works. I always fall on the side of the non majority it seems, and this is another example. [The list, not you specifically] Stop being defensive that the test is bogus. It's not. I agree with everything up to here. It shows that in one circumstance, Catalyst is sadly slow. Let's fix that. Matt has just pointed out that Cat's optimised for large applications with lots of paths, and for flexible programming. Only fix it if that doesn't compromise this, which is more important than looking good in one flawed benchmark. Agreed. Explaining why the test may be invalid, or why it's bunk still won't change that fact that in this circumstance, it sucks. Catalyst sucks because it doesn't come with a pony, so let's hope the next benchmark to hit the web doesn't benchmark against that ;) Google has a pony, why can't I? http://googleblog.blogspot.com/2006/10/yes-you-can-have-pony.html /me removes suit and goes back to writing tests Um, shouldn't you leave the suit on until you've received the replies? Nope. That's what filters to Trash are for. :-P I hope it wasn't
Re: [Catalyst] Non-real world irrelevant benchmarks
On 11/16/06, Nilson Santos Figueiredo Junior [EMAIL PROTECTED] wrote: On 11/16/06, Matt S Trout [EMAIL PROTECTED] wrote: Besides which, I've never yet seen a production application (and between Shadowcat's client portfolio I've seen not a small number thereof) where the dispatch overhead was even statistically significant to the overall performance - the bottleneck has always been either data retrieval or template rendering. This makes me wonder if these high traffic Catalyst sites are using TT or another templating solution. If they are using TT, it should be very helpful if someone published a sort of TT performance guide. Or at least a bulleted list with things not to do because I'm probably doing them all, given the current (lack of) speed from my applications without that much traffic. Any complex (or just plain big) page will take around 3-4 seconds to render with 90% of that time being spent with TT. The best work around was to use one of the caching plugins where I could, but users still have to experience crappy load times whenever something is updated on the database. Thankfully, it's an internal system - so it's not *that* critical. If template rendering speed might be a bottleneck for you, you may want to investigate ClearSilver. I haven't tried it yet myself, but I've heard good things about its performance, and there's already a Cat View for it. Its a bit different than other systems though, in that you explicitly define the structure of all of the data going to your template in an external file. -- Brandon ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: [Perl Plat_Form] Geneva team confirmed for the plat_form contest
Hi all, This might be a shameless plugin - but I wander if you consider using Catalyst::Example::InstantCRUD for fast bootstrapping a bare bones app. I imagine that in the limited time it should be usefull. -- Zbyszek On 11/16/06, Dami Laurent (PJ) [EMAIL PROTECTED] wrote: Hi all, This is to confirm that I have the agreement of my organization for submitting a Geneva team for the plat_form contest (http://www.plat-forms.org/). The deadline for submission is in 2 weeks, so other teams, please wake up, so that we can show to the world that Perl is alive! Our proposal will be based on : IDE : Emacs / Vim Source control : Subversion Web framework : Catalyst on Apache/mod_perl ORM : DBIx::DataModel Templating : Template Toolkit Validation : Data::Domain Javascript : prototype+scriptaculous+openrico+Jemplate Best regards, Laurent Dami Conseiller en systèmes d'information Palais de Justice - Etat de Genève Case postale 3966 Place du Bourg-de-Four 3, 1211 Genève 3 +41 (22) 327 20 64 (direct), +41 (22) 327 20 37 (service) http://cui.unige.ch/~dami ___ Perl-platform mailing list [EMAIL PROTECTED] https://lists.odem.org/mailman/listinfo/perl-platform -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: Re: [Catalyst] Catalyst vs Rails vs Django Cook off
On 11/16/06, Carl Franks [EMAIL PROTECTED] wrote: snip It shows that in one circumstance, Catalyst is sadly slow. Let's fix that. Matt has just pointed out that Cat's optimised for large applications with lots of paths, and for flexible programming. Only fix it if that doesn't compromise this, which is more important than looking good in one flawed benchmark. My original intent was to prod someone that is knowledgable enough of Catalyst's internals to criticize this benchmark's methods to create a benchmark that is more friendly to Catalyst's strengths. We've established that serving static content is not a fitting use. We've established that a single action is also not an approptiate use of Catalyst's dispatcher. So we include some content directly in the response body. But how many actions must be present for the dispatcher to shine? Then we modify the test to use a more realistic number and excercise the dispatcher a bit. This may not make Catalyst run any faster, but it should allow it show it's strengths and is by no means clipping the wings of the other benchmark participants. -- Cory 'G' Watson http://www.onemogin.com ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst vs Rails vs Django Cook off
On 11/16/06, Christopher H. Laco [EMAIL PROTECTED] wrote: Regardless of whether the test is 'real world', and regardless of whether the frameworks 'were meant to serve more complicated things', Catalyst is slower in this instance. All things being unequal, if I tell my boss we have 3 frameworks to choose from, and one is flexible, and the others are fast, he's going to choose fast every time...even knowing the testing may be faulty. Yes, I know better. He probably does too. But that's how the world works. What world is this? The world that doesn't realise programmers are far more expensive than hardware? The world where bosses don't realise the cost of inflexibility? The ability not to adapt fast is a concern that's been hammered long and hard in business circles since forever so this nominal boss would have to be really particularly shortsighted to blindly choose speed over flexibility. Post a rebuttal, suggest better benchmarks, leave a trackback, move on. This doesn't seem like getting wound up about. Paul ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst vs Rails vs Django Cook off
Paul Makepeace wrote: On 11/16/06, Christopher H. Laco [EMAIL PROTECTED] wrote: Regardless of whether the test is 'real world', and regardless of whether the frameworks 'were meant to serve more complicated things', Catalyst is slower in this instance. All things being unequal, if I tell my boss we have 3 frameworks to choose from, and one is flexible, and the others are fast, he's going to choose fast every time...even knowing the testing may be faulty. Yes, I know better. He probably does too. But that's how the world works. What world is this? The world that doesn't realise programmers are far more expensive than hardware? The world where bosses don't realise the cost of inflexibility? The ability not to adapt fast is a concern that's been hammered long and hard in business circles since forever so this nominal boss would have to be really particularly shortsighted to blindly choose speed over flexibility. Post a rebuttal, suggest better benchmarks, leave a trackback, move on. This doesn't seem like getting wound up about. Paul It's a world where PHBs often look at web stats and ask What the hell is this slow a lot more than they ask Why isn't the system flexible. -=Chris signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst vs Rails vs Django Cook off
Christopher H. Laco wrote: Paul Makepeace wrote: On 11/16/06, Christopher H. Laco [EMAIL PROTECTED] wrote: Regardless of whether the test is 'real world', and regardless of whether the frameworks 'were meant to serve more complicated things', Catalyst is slower in this instance. All things being unequal, if I tell my boss we have 3 frameworks to choose from, and one is flexible, and the others are fast, he's going to choose fast every time...even knowing the testing may be faulty. Yes, I know better. He probably does too. But that's how the world works. What world is this? The world that doesn't realise programmers are far more expensive than hardware? The world where bosses don't realise the cost of inflexibility? The ability not to adapt fast is a concern that's been hammered long and hard in business circles since forever so this nominal boss would have to be really particularly shortsighted to blindly choose speed over flexibility. Post a rebuttal, suggest better benchmarks, leave a trackback, move on. This doesn't seem like getting wound up about. Paul It's a world where PHBs often look at web stats and ask What the hell is this slow a lot more than they ask Why isn't the system flexible. -=Chris And a world where customers don't bitch that your framework is inflexibly, but will bitch if it's slow. signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Cannot create a cache
I am trying to implement a cache with a Catalyst app running under Apache2 mod-perl and as far as I can tell the cache is clear at the start of each request. I have a hash which is acting as my cache but even if I put values into it, on the next request the hash is empty. Have I configured my Apache2 config file correctly for Catalyst or am I missing something more basic? Regards Ian C. Docherty (ICD) ### package Catalyst::Plugin::MyPlugin; use vars qw (%cached); My apache2 config is as follows. NameVirtualHost *:8000 Perl use lib qw(/var/sandbox/myapp/lib); /Perl PerlModule Horivert::MyApp VirtualHost *:8000 ServerName sprint.mydomain.com ErrorLog /var/sandbox/myapp/error_log Alias /static/ /var/sandbox/myapp/root/static/ Location / SetHandler modperl PerlResponseHandler Horivert::MyApp /Location /VirtualHost ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst vs Rails vs Django Cook off
Paul Makepeace wrote:
What world is this? The world that doesn't realise programmers are far
more expensive than hardware? The world where bosses don't realise the
cost of inflexibility?
Bad programmers are cheap. Mediocre, unmaintainable, and inflexible
applications are what the market demands. 90% of the features for 10% of
the cost is a winning prospect for many people.
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)-config(name = do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
;$;]-[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;-setup;
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst vs Rails vs Django Cook off
Cory Watson wrote:
My original intent was to prod someone that is knowledgeable enough of
Catalyst's internals to criticize this benchmark's methods to create a
benchmark that is more friendly to Catalyst's strengths. We've
established that serving static content is not a fitting use. We've
established that a single action is also not an appropriate use of
Catalyst's dispatcher. So we include some content directly in the
response body. But how many actions must be present for the
dispatcher to shine? Then we modify the test to use a more realistic
number and exercise the dispatcher a bit.
This doesn't really solve any problems, though. I think you're
confusing liking something with it being the best. The fact that you
(we) like Catalyst doesn't mean it's faster than anything else.
(Admittedly perl itself is faster than python/ruby in a number of areas,
but not in the areas Catalyst's dispatcher uses.)
The benchmarks we have now do point out two important things -- multiple
inheritance and method calls are slow. These are weaknesses of perl5's
design, and there's not a whole lot we can do to make them faster.
There's a reason perl5 is being scrapped in favor of perl6 (there are
two, actually -- method calls are slow and the OO system is showing its
age ;).
In the interim, I suggest writing your web applications in C if you want
raw performance. You have to ask yourself, though -- do you really need
the speed? (Or do you want some pseudo-scientific number on someone's blog?)
Regards,
Jonathan Rockway
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)-config(name = do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
;$;]-[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;-setup;
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: Re: [Catalyst] Catalyst vs Rails vs Django Cook off
On 11/16/06, Jonathan Rockway [EMAIL PROTECTED] wrote: Cory Watson wrote: My original intent was to prod someone that is knowledgeable enough of Catalyst's internals to criticize this benchmark's methods to create a benchmark that is more friendly to Catalyst's strengths. We've established that serving static content is not a fitting use. We've established that a single action is also not an appropriate use of Catalyst's dispatcher. So we include some content directly in the response body. But how many actions must be present for the dispatcher to shine? Then we modify the test to use a more realistic number and exercise the dispatcher a bit. This doesn't really solve any problems, though. I think you're confusing liking something with it being the best. The fact that you (we) like Catalyst doesn't mean it's faster than anything else. (Admittedly perl itself is faster than python/ruby in a number of areas, but not in the areas Catalyst's dispatcher uses.) It solves the problem that the benchmark in question is a poor representation of Catalyst's performance. Rather than make an exhaustive reply to your response I'll attempt to put this to bed by merely stating that I think providing the Intarweb with a 'better' way to measure Catalyst's pefromance is more constructive than dismissing the way that results that were proffered. -- Cory 'G' Watson http://www.onemogin.com ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Non-real world irrelevant benchmarks
On 11/16/06, Brandon Black [EMAIL PROTECTED] wrote: If template rendering speed might be a bottleneck for you, you may want to investigate ClearSilver. I haven't tried it yet myself, but I've heard good things about its performance, and there's already a Cat View for it. Its a bit different than other systems though, in that you explicitly define the structure of all of the data going to your template in an external file. I've already looked at ClearSilver but it's probably too inflexible for me. Also, the way it handles data just seems really ackward. Anyone knows how Mason compares to TT, performance-wise? -Nilson Santos F. Jt. ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst vs Rails vs Django Cook off
Cory Watson wrote:
Rather than make an exhaustive reply to your response I'll attempt to
put this to bed by merely stating that I think providing the Intarweb
with a 'better' way to measure Catalyst's pefromance is more
constructive than dismissing the way that results that were proffered.
Fixing the slow code is the solution.
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)-config(name = do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
;$;]-[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;-setup;
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
[Catalyst] uri_for (or lack thereof) in static pages
I have a ѕimple yet thorny problem, which I expect most of you also have or had. It has several possible solutions, but I'm chiefly interested in knowing how *you* would solve it and why. We're developing a Catalyst application. It serves HTML, CSS, JavaScript, and images. HTML is the output of TT2, but CSS, images and JavaScript are static. We have them served by C::P::Static::Simple on the built-in server, and we use a Location the have them directly served by Apache/mod_perl, one the production server. Under mod_perl, the application's root is not the server's root, i.e., it is http://server/myapp, whereas it is http://localhost:3000 on the built-in test server. This would not be a problem if the CSS were not linking to images. And because CSS pages are static, they cannot make use of uri_for(), and therefore get the links to the pictures wrong. Several solutions come to mind, and I cannot choose which one I like best (or I dislike the least): - have CSS served through TT2. I'm wondering about the extra load it would put on the Catalyst engine. Maybe it's completely negligeable, maybe not... Is it worth the effort to cache them? If so, what are the recommended best practices? - make all links in CSS relative. This makes it harder to spread the stylesheets in a deep directory structure, unless one is willing to tediously count the ../../.. (or was it ../..?) and count them again when a stylesheet moves. - insist that MyApp be installed at the server's root, bribing the sysadmin if need be (or threatening, or loudly shouting at, or blackmailing, or sacking, torturing...) - use some black magic involving mod_rewrite or even HTTP::Proxy to modify the broken links on the fly... Hmmm, blackmailing the sysadmin should be easier than having him tweak mod_rewrite... - Pre-process the CSS at install time, with some sort of ttree, and then serve them as static content. Any war stories worth telling, Gentlemen, Ladies? -- C é d r i c B o u v i e r signature.asc Description: Digital signature ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] [ANNOUNCE] DBIx-Class-0.07003
I'm pleased to announce that a new bugfix release of DBIx::Class is on its way to CPAN. Until it's indexed, you can grab the tarball at: http://pause.perl.org/incoming/DBIx-Class-0.07003.tar.gz http://files.danieltwc.com/DBIx-Class-0.07002.tar.gz This release contains the following changes from 0.07002: - fix for rt.cpan.org #22740 (use $^X instead of hardcoded perl) - Tweaks to resultset to allow inflate_result to return an array - Fix UTF8Columns to work under Perl = 5.8.0 - Fix up new_result in ResultSet to avoid alias-related bugs - Made new/update/find handle 'single' rel accessor correctly - Fix NoBindVars to be safer and handle non-true bind values - Don't blow up if columns_info_for returns useless results - Documentation updates Enjoy! -Brian Cassidy ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] uri_for (or lack thereof) in static pages
Something I have done and will probably do again (but I'm not using right now) is having static pages like that served by Catalyst the first time they are requested and then writing them to disk (as part of the end handler to let apache serve) them as static going forward. To update files, erase them. Catalyst will rewrite them on the next request and only the first one will have any kind of performance hit. A semi- permanent disk cache, really. You need apache to serve static files that alrady exist instead of asking Catalyst for them. MST put up some htaccess instructions for that in one of the fastcgi set up pages. Also, the webuser needs to have file/dir write permissions which isn't always possible (bride admin scenario again) or recommended. -Ashley On Thursday, Nov 16, 2006, at 13:47 US/Pacific, Cédric Bouvier wrote: I have a ѕimple yet thorny problem, which I expect most of you also have or had. It has several possible solutions, but I'm chiefly interested in knowing how *you* would solve it and why. We're developing a Catalyst application. It serves HTML, CSS, JavaScript, and images. HTML is the output of TT2, but CSS, images and JavaScript are static. We have them served by C::P::Static::Simple on the built-in server, and we use a Location the have them directly served by Apache/mod_perl, one the production server. Under mod_perl, the application's root is not the server's root, i.e., it is http://server/myapp, whereas it is http://localhost:3000 on the built-in test server. This would not be a problem if the CSS were not linking to images. And because CSS pages are static, they cannot make use of uri_for(), and therefore get the links to the pictures wrong. Several solutions come to mind, and I cannot choose which one I like best (or I dislike the least): - have CSS served through TT2. I'm wondering about the extra load it would put on the Catalyst engine. Maybe it's completely negligeable, maybe not... Is it worth the effort to cache them? If so, what are the recommended best practices? - make all links in CSS relative. This makes it harder to spread the stylesheets in a deep directory structure, unless one is willing to tediously count the ../../.. (or was it ../..?) and count them again when a stylesheet moves. - insist that MyApp be installed at the server's root, bribing the sysadmin if need be (or threatening, or loudly shouting at, or blackmailing, or sacking, torturing...) - use some black magic involving mod_rewrite or even HTTP::Proxy to modify the broken links on the fly... Hmmm, blackmailing the sysadmin should be easier than having him tweak mod_rewrite... - Pre-process the CSS at install time, with some sort of ttree, and then serve them as static content. Any war stories worth telling, Gentlemen, Ladies? -- C é d r i c B o u v i e r signature.asc___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] uri_for (or lack thereof) in static pages
Cédric Bouvier wrote: I have a ѕimple yet thorny problem, which I expect most of you also have or had. It has several possible solutions, but I'm chiefly interested in knowing how *you* would solve it and why. We're developing a Catalyst application. It serves HTML, CSS, JavaScript, and images. HTML is the output of TT2, but CSS, images and JavaScript are static. We have them served by C::P::Static::Simple on the built-in server, and we use a Location the have them directly served by Apache/mod_perl, one the production server. Under mod_perl, the application's root is not the server's root, i.e., it is http://server/myapp, whereas it is http://localhost:3000 on the built-in test server. This would not be a problem if the CSS were not linking to images. And because CSS pages are static, they cannot make use of uri_for(), and therefore get the links to the pictures wrong. Are the images static? If so then your problem isn't a problem. Judging on your possible suggestions I'd guess not, but just checking. Ash ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: Catalyst vs Rails vs Django Cook off
* Cory Watson [EMAIL PROTECTED] [2006-11-16 14:40]: I respectfully suggest that those who criticize his work should use their energies to /improve/ his test rather than merely dismissing it as worthless. Using his code as a base, couldn't one create a test that was more fair? Then someone would have a test that shows results that are more 'real' and give potential users more information with which to make a decision. Sorry, come again? If I say “I’m afraid this pasta tastes so awful I just can’t eat it”, would you respond “well at least [the cook] did prepare something! maybe you should stop mouthing off and do it better”? The fact that a benchmark does not measure something interesting stands on its own. There is *no* need for anyone to provide a better benchmark before they can state that a bad one is bad. The onus is on the benchmark writer to show that his measurements are meaningful and useful. It’s called science. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Cannot create a cache
Ian Docherty wrote: I have a hash which is acting as my cache but even if I put values into it, on the next request the hash is empty. Are you aware that apache runs multiple processes and that each process has a different copy of your %cache variable? You will not get the same process each time. If you want to share between processes, you need something like Cache::FastMmap. - Perrin ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: Catalyst vs Rails vs Django Cook off
* Christopher H. Laco [EMAIL PROTECTED] [2006-11-16 16:45]: It's a world where PHBs often look at web stats and ask What the hell is this slow a lot more than they ask Why isn't the system flexible. If he decides it’s because the framework is slow and makes you switch, that means two things: 1. He has no idea of programming or benchmarks. 2. He insists on making decisions about things he clearly knows nothing about. No wait, it means three things: 1. He has no idea of programming or benchmarks. 2. He insists on making decisions about things he clearly knows nothing about, instead of deferring to the competence of people he hired for their competence and trusting their judgement. Of course, since he is incompetent in this are, he has no way of knowing how competent his underlings are. A certain Paul Graham has written at length about this problem. 3. You are doomed. Even if you used the best-performing framework ever, he will force other boneheaded decisions on you. Float your resume. * Christopher H. Laco [EMAIL PROTECTED] [2006-11-16 16:50]: And a world where customers don't bitch that your framework is inflexibly, but will bitch if it's slow. No, they will bitch that the *application* is slow. Customers couldn’t give a flying monkey about how you implement it. And the framework is almost assuredly not going to be where you’re wasting all your cycles. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Non-real world irrelevant benchmarks
Nilson Santos Figueiredo Junior wrote: Anyone knows how Mason compares to TT, performance-wise? There are some very old benchmarks here: http://chamas.com/bench/#2000 These are not ideal though, because they compare the cost of using Mason as your controller and templating system to the cost of a simple mod_perl handler plus TT. What you really want is a benchmark comparing them through Catalyst. Regarding your TT performance issues, there are some common things to do, which you can find in the TT list archives. I'd still like to see your dprof output sorted by real time, since it seems impossible that a TT template could take 4 seconds unless it's doing something like fetching from a database or the TT cache is turned off. - Perrin ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: using Plugin::Singleton and testing
* Daniel McBrearty [EMAIL PROTECTED] [2006-11-16 01:35]: a wonderful rant. except : he doesn't answer one basic question - what do you do when you genuinely do want only one instance to ever exist? A singleton is nothing but a global variable, except the identifier comes from the class namespace rather than the variable namespace. Put it in a global variable already. print spooler is a crap example. A much better one is an audio player - you can only listen to one audio track at a time, you really don't want a second one to EVER happen. This is a reasonabvle design decision to make early for some systems. If you want to change the behaviour one day, that's irrelevant. I still wouldn’t want to place the knowledge that there can only be one audio stream in the audio stream class itself. That is knowledge that belongs in the app, at least one level higher than the audio stream class. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: Catalyst vs Rails vs Django Cook off
On 11/16/06, A. Pagaltzis [EMAIL PROTECTED] wrote: * Cory Watson [EMAIL PROTECTED] [2006-11-16 14:40]: I respectfully suggest that those who criticize his work should use their energies to /improve/ his test rather than merely dismissing it as worthless. Using his code as a base, couldn't one create a test that was more fair? Then someone would have a test that shows results that are more 'real' and give potential users more information with which to make a decision. Sorry, come again? If I say I'm afraid this pasta tastes so awful I just can't eat it, would you respond well at least [the cook] did prepare something! maybe you should stop mouthing off and do it better? That depends. Am I part of collection of individuals who's goal is to collaboratively create better pasta or am I someone who paid money for someone to prepare me pasta? I think the answer to that question points out why I bothered to originally respond to this message. I tire of being repeatedly berated for thinking it would be cool for someone to create a benchmark based on the criticisms of those of you that can lend advice. Since I'm not putting my money where my mouth is, I'll take my ball and go home. ;) -- Cory 'G' Watson http://www.onemogin.com ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: Catalyst vs Rails vs Django Cook off
* Cory Watson [EMAIL PROTECTED] [2006-11-17 03:20]: On 11/16/06, A. Pagaltzis [EMAIL PROTECTED] wrote: If I say I'm afraid this pasta tastes so awful I just can't eat it, would you respond well at least [the cook] did prepare something! maybe you should stop mouthing off and do it better? That depends. Am I part of collection of individuals who's goal is to collaboratively create better pasta or am I someone who paid money for someone to prepare me pasta? Note that the analogon to the pasta in this case is the benchmark, not Catalyst. I tire of being repeatedly berated for thinking it would be cool for someone to create a benchmark based on the criticisms of those of you that can lend advice. Oh, no doubt that would be cool. Ponies are also cool. ;-) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: using Plugin::Singleton and testing
On Thursday 16 November 2006 20:08, A. Pagaltzis wrote:
A singleton is nothing but a global variable, except the
identifier comes from the class namespace rather than the
variable namespace. Put it in a global variable already.
Not entirely true. Try this:
$global = Oops, accidentally overwrote the instance with garbage.;
vs.
Singleton-get_instance() = Oops, accidentally overwrote the instance.;
One will cause an error at some indeterminable time after the mistake, the
other throws an error immediately, at the line where the mistake was made.
Which do you prefer?
The point is, a Singleton isn't just a global variable, it's an encapsulated
piece of data that your program can easily access anywhere. Compare this
code:
package Foo;
sub new { my $global = shift; bless {global = $global} = 'Foo' }
sub Bar { Bar-new($self-{global}) }
sub something { $self-{global}-something(...) }
package Bar;
sub new { my $global = shift; bless { global = $global} = 'Foo' }
sub Baz { Baz-new($self-{global}) }
sub another { $self-{global}-something(...) }
# etc.
to:
package Foo;
sub new { bless {} = 'Foo' }
sub Bar { Bar-new }
sub something { Global-instance-something }
package Bar;
sub new { bless {} = 'Foo' }
sub Baz { Baz-new }
sub another { Global-instance-something }
# etc.
In cases where many classes need the same data, a Singleton really helps
simplify the code. There are always coupling issues to worry about, of
course (Singletons can be evil if you use them that way), but there are some
things that you can really only have one of. The log file, the file
descriptor 2 (STDERR), the database password, etc.
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)-config(name = do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
;$;]-[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;-setup;
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: using Plugin::Singleton and testing
On 17/11/2006, at 4:37 PM, Jonathan Rockway wrote:
On Thursday 16 November 2006 20:08, A. Pagaltzis wrote:
A singleton is nothing but a global variable, except the
identifier comes from the class namespace rather than the
variable namespace. Put it in a global variable already.
Not entirely true. Try this:
$global = Oops, accidentally overwrote the instance with garbage.;
vs.
Singleton-get_instance() = Oops, accidentally overwrote the
instance.;
Not really, because ...
use Readonly;
Readonly my $global = Warming;
print Before = $global\n\n;
eval {
$global = Oops, accidentally overwrote the instance with
garbage.;
};
if ($@) { print Error (would have died if uneval'd) = [EMAIL PROTECTED];
};
print After = $global\n;
produces ...
Before = Warming
Error (would have died if uneval'd) = Modification of a read-
only value attempted at t.pl line 8
After = Warming
No matter what my prime minister says.
Cheers
--
Adam Clarke
www.strategicdata.com.au
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
