Re: [Catalyst] DNS as a Catalyst Model
mia wrote: >Matt S Trout wrote: >> On Wed, Jun 06, 2007 at 02:18:33PM -0700, mla wrote: >>> Matt S Trout wrote: On Wed, Jun 06, 2007 at 12:29:12PM -0700, mla wrote: > Is it not possible to offer the current Catalyst instance through > a class method? Something analogous to Apache->request, rather than > having to do the whole ACCEPT_CONTEXT prototype object thing? Not without limiting ourselves in terms of planned future features. Jifty does this because they're explicitly one app per process. We aren't. >>> When you say "per process," you mean operating system process? >>> You're talking about threading issues? >> >> Threading, forking, and OS-level COW. > >Forking and COW would apply just as much to instances though. > >Assuming I'm not using threads, how would I hurt myself by >subclassing Catalyst and supplying a MyApp->context that returns >the current catalyst context? Yes, I'd like to know more about this too please. Mason has a similar construct - HTML::Mason::Request->instance() - and it works fine with Mason subrequests or recursive calls to an entirely different Mason interpreter. It just returns the value of a dynamically scoped variable that is set at the beginning of a Mason request. I dislike the fact that anything that needs to access the current context object has to be written as a component, and thus have a completely different calling signature than just a plain extension. Jon ___ 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] DNS as a Catalyst Model
Sorry, wrong subject...reposting... On Jun 7, 2007, at 3:53 AM, Jonathan Swartz wrote: mia wrote: >Matt S Trout wrote: >> On Wed, Jun 06, 2007 at 02:18:33PM -0700, mla wrote: >>> Matt S Trout wrote: >>>> On Wed, Jun 06, 2007 at 12:29:12PM -0700, mla wrote: >>>>> Is it not possible to offer the current Catalyst instance through >>>>> a class method? Something analogous to Apache->request, rather than >>>>> having to do the whole ACCEPT_CONTEXT prototype object thing? >>>> Not without limiting ourselves in terms of planned future features. Jifty >>>> does this because they're explicitly one app per process. We aren't. >>> When you say "per process," you mean operating system process? >>> You're talking about threading issues? >> >> Threading, forking, and OS-level COW. > >Forking and COW would apply just as much to instances though. > >Assuming I'm not using threads, how would I hurt myself by >subclassing Catalyst and supplying a MyApp->context that returns >the current catalyst context? Yes, I'd like to know more about this too please. Mason has a similar construct - HTML::Mason::Request->instance() - and it works fine with Mason subrequests or recursive calls to an entirely different Mason interpreter. It just returns the value of a dynamically scoped variable that is set at the beginning of a Mason request. I dislike the fact that anything that needs to access the current context object has to be written as a component, and thus have a completely different calling signature than just a plain extension. Jon ___ 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] plugins; was Re: debug mode
mia wrote: >Matt S Trout wrote: >> On Wed, Jun 06, 2007 at 02:18:33PM -0700, mla wrote: >>> Matt S Trout wrote: On Wed, Jun 06, 2007 at 12:29:12PM -0700, mla wrote: > Is it not possible to offer the current Catalyst instance through > a class method? Something analogous to Apache->request, rather than > having to do the whole ACCEPT_CONTEXT prototype object thing? Not without limiting ourselves in terms of planned future features. Jifty does this because they're explicitly one app per process. We aren't. >>> When you say "per process," you mean operating system process? >>> You're talking about threading issues? >> >> Threading, forking, and OS-level COW. > >Forking and COW would apply just as much to instances though. > >Assuming I'm not using threads, how would I hurt myself by >subclassing Catalyst and supplying a MyApp->context that returns >the current catalyst context? Yes, I'd like to know more about this too please. Mason has a similar construct - HTML::Mason::Request->instance() - and it works fine with Mason subrequests or recursive calls to an entirely different Mason interpreter. It just returns the value of a dynamically scoped variable that is set at the beginning of a Mason request. I dislike the fact that anything that needs to access the current context object has to be written as a component, and thus have a completely different calling signature than just a plain extension. Jon ___ 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] TT2 + CP::Authentication + DBIC gotcha
On Jul 13, 2007, at 12:13 PM, Perrin Harkins wrote: On 7/13/07, J. Shirley <[EMAIL PROTECTED]> wrote: As anecdotal evidence to its insidious behavior, I've personally been involved in a 5 man debugging effort that took 13 days (not full days, but probably an average of 3-4 hours a day * 5 people * 13 days) to finally find the bug. Which was simply "my $foo = $bar if $baz;" The reason why it was so hard to track down was because ot he wonderful undefined behavior. I had a similar experience, which is why I always mention when I see it in other people's code now. It's a real problem and very hard to track down if you haven't heard of it before. I have the same experience every few years, and I've never been able to understand why this can't simply be detected and at least flagged as an error or warning in the Perl compiler. Does anyone know? It's one of the few things about Perl that gets me angry. :) Jon ___ 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] Should CATALYST_DEBUG suppress manual calls to $c->log->debug()?
On Aug 25, 2007, at 3:17 PM, Matt S Trout wrote: On Fri, Aug 24, 2007 at 10:15:37PM +0100, Will Hawes wrote: I've been trying unsuccessfully to disable all debug messages while running tests on my app with prove. Setting CATALYST_DEBUG=0 eliminates all the test server debug output such as the list of loaded actions, but i am still seeing the output of every call made to $c->log->debug by my controller code. As far as I can see the docs regarding CATALYST_DEBUG=0 don't make any distinction about where debug messages originate, only that they are suppressed, which presumably means I shouldn't be seeing any debug output at all. Is my mistake in misunderstanding how $c->log->debug() is supposed to work? Yes. That logs a message of level 'debug'. The internal Catalyst debugging aid stuff checks $c->debug and if so logs messages with the debug level. But that doesn't mean turning off the internal debugging changes the configuration of your logger whatsoever. But what's the point of using $c->debug to gate debug messages when you could just check $log->is_debug? It is confusing to have some debug log messages in the system gated on $c->debug, and others just on $log->is_debug. The advantage of $log->is_debug is that some logging systems (e.g. Log4perl) will allow you to switch debugging on and off at runtime, without a server restart, even in production. Jonathan suggests that it might be for performance, but method calls like $c->debug cannot be optimized away at compile time. And in any case, the performance gains would be pretty small potatoes. Jon ___ 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/
