[Catalyst] Re: [Dbix-class] Cat Model DBIC Schema fails test if *optional* prereq isn't installed
Toby Corkindale wrote: Hi, Catalyst::Model::DBIC::Schema lists Catalyst::Devel as an *optional* dependency. However if you do not have Catalyst::Helper installed (via Catalyst::Devel) then C-M-DBIC-Schema fails its unit tests and won't install via CPAN. Fix committed to trunk. Cheers, Toby ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: Incorrect $c-req-base using Catalyst::Engine::SCGI on Win32
2009/6/28 Orlando Vazquez ovazq...@gmail.com:
Ok, just to make sure I understand the root cause of this problem:
apache...@win32 sets SCRIPT_NAME to /action (or whatever PATH_INFO
is), when it should really be something like , / or undef, is this
correct? I assume this only happens when the application is mounted
under /, and it does do the right this when mounted under say,
something like /myapp?
That's correct, the problem only happens when mounted at / - things
behave as expected when mounted elsewhere.
I'm the one who was responsible for removing the prepare_path method
from the SCGI engine. I did this because it was overriding with an
outdated verbatim copy of the prepare_path method in C::E::CGI, which
::SCGI inherits from. Hmmm, ::FastCGI seems to include its own
additional path fixes :\ Does it make sense to unify these tweaks in
one place?
Almost certainly, although if you are in agreement I'd settle for
getting it working within C::E::SCGI in the first instance and
worrying about that later when I have some more time ;)
Do you know if this problem manifests itself under the same webserver
but different Catalyst engine?
Without having tested extensively, I think it's SCGI specific - I
don't see the problem with the CGI engine, at least.
I appreciate the suggested fix but I don't think it's quite safe, as
it would break something like /tags/tags where your app is mounted
under /tags and you're calling the /tags action (you know, for
whatever reason).
But at the end of the day we have to get this to
work well for you, so I'm not thrilled about but also not opposed to
escaping this behaviour for this particular webserver since I know
there's a few different servers that get it wrong.
Could you check out how C::E::FastCGI::_fix_env for how to escape this
for your particular webserver platform + version, and patch/commit a
unittest+fix? I don't have a windows machine handy to test this
appropriately, but you could probably fix this in a couple of minutes.
Good point, I'd not thought of the /tags/tags scenario.
Having played around with this a little more it looks as though when
things are working properly, REQUEST_URI is the same as SCRIPT_NAME
concatenated with PATH_INFO. With that in mind, perhaps revising the
suggested fix to something like this:
sub prepare_path { # or _fix_env?
my( $self, $c ) = @_;
my $env = $self-env;
my $path_info = $env-{PATH_INFO} || '';
my $script_name = $env-{SCRIPT_NAME} || '';
my $request_uri = $env-{REQUEST_URI} || '';
unless( $request_uri eq $script_name . $path_info ) {
delete $env-{SCRIPT_NAME};
}
return $self-next::method( $c );
}
To be absolutely safe we could limit it to just this OS/web server as
you suggest:
if( $^O eq 'MSWin32' $env-{SERVER_SOFTWARE} =~ m{^Apache/2\.0\.63} ) {
...
}
Let me know your thoughts on the above and I'll get to work on it.
P.S.
I got your doc bug report - it's been fixed and pushed up to the
Catalyst git repo :)
Thanks :)
___
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] Use of uninitialized value $buffer error
On 20 Jun 2009, at 15:32, Jesse Sheidlower wrote: I'm having a hell of a time trying to track down the reasons for this error. I'm getting an error that looks like: Use of uninitialized value $buffer in concatenation (.) or string at /usr/share/perl5/Catalyst/Engine/CGI.pm line 220. For the benefit of the list, this is now fixed. http://dev.catalystframework.org/svnweb/Catalyst/revision?rev=10745 http://dev.catalystframework.org/svnweb/Catalyst/revision?rev=10746 Merlyn was exactly right, write was being called with undef, due to FillInForm setting the response body to undef. New release of FillInForm will follow shortly, and this will be fixed in the general case in the next Catalyst. What are people's thoughts about adding a specific warning if you try to write undef? (As you could still cause this warning by doing that explicitly) Cheers t0m ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Warnings when upgrading Catalyst
On 25 Jun 2009, at 10:57, Ovid wrote:
--- On Wed, 24/6/09, Tomas Doran bobtf...@bobtfish.net wrote:
From: Tomas Doran bobtf...@bobtfish.net
Also, you're in debug mode.. Do you get the
warnings when debug mode is disabled?
Cool! When I disable debug mode, the warnings go away. Never
thought to look at that. This makes me feel much more confident
that we don't have a bug in our code. Still, we run tests in debug
mode and we don't want our test suite spewing warnings lest we
start ignoring them.
So, looking back into your Dumper output, I guess that you're seeing
this as you're using Catalyst::Action::REST, and you're doing a
forward from an action_METHOD type sub?
If so, here's your fixes:
http://github.com/bobtfish/catalyst-action-rest/commit/
679978b1f8a1f309ff7c11ea0a744f8b1fe22d5a
http://github.com/bobtfish/catalyst-action-rest/tarball/
fixes_5_80_forward_stats_warnings
Please confirm if I'm right in my guessing and this works for you, or
if not - I think the next thing to do is get a stack trace so we can
better guess why we're getting there..
Can you do something cheesy like:
BEGIN: { $SIG{__WARN__} = Carp::cluck };
in MyApp.pm and give us the stack trace and debug output for a hit
which warns?
Cheers
t0m
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
[Catalyst] RenderView install problem
apologies if this has been reported elsewhere.
fresh perl 5.8.9 install under ubuntu. latest of everything installed
from cpan, but install of Catalyst::Action::RenderView fails with:
t/04live...Could not load class (TestApp) because : Can't use
string (TestApp) as a HASH ref while strict refs in use at accessor
_application defined at
/home/pkarman/perl/lib/site_perl/5.8.9/Catalyst/Component/ApplicationAttribute.pm
line 8.
Compilation failed in require at
/home/pkarman/perl/lib/site_perl/5.8.9/x86_64-linux/Class/MOP.pm line
135.
at /home/pkarman/perl/lib/site_perl/5.8.9/x86_64-linux/Class/MOP.pm
line 120
Class::MOP::load_first_existing_class('TestApp') called at
/home/pkarman/perl/lib/site_perl/5.8.9/x86_64-linux/Class/MOP.pm line
141
Class::MOP::load_class('TestApp') called at
/home/pkarman/perl/lib/site_perl/5.8.9/Catalyst/Test.pm line 23
Catalyst::Test::__ANON__('Catalyst::Test', 'all',
'HASH(0x1400530)', 'HASH(0x13f2d50)') called at
/home/pkarman/perl/lib/site_perl/5.8.9/Sub/Exporter.pm line 493
Sub::Exporter::_expand_group('Catalyst::Test',
'HASH(0x13fffb0)', 'ARRAY(0x14000a0)', 'HASH(0x13f2d50)',
'HASH(0x1400580)', 'HASH(0x13f2920)') called at
/home/pkarman/perl/lib/site_perl/5.8.9/Sub/Exporter.pm line 424
Sub::Exporter::_expand_groups('Catalyst::Test',
'HASH(0x13fffb0)', 'ARRAY(0x1400080)', 'HASH(0x13f2d50)') called at
/home/pkarman/perl/lib/site_perl/5.8.9/Sub/Exporter.pm line 742
Sub::Exporter::__ANON__('Catalyst::Test', '-all',
'HASH(0x7f54b0)') called at
/home/pkarman/perl/lib/site_perl/5.8.9/Catalyst/Test.pm line 106
Catalyst::Test::import('Catalyst::Test', 'TestApp') called at
t/04live.t line 10
main::BEGIN() called at
/home/pkarman/perl/lib/site_perl/5.8.9/Catalyst/Test.pm line 10
eval {...} called at
/home/pkarman/perl/lib/site_perl/5.8.9/Catalyst/Test.pm line 10
BEGIN failed--compilation aborted at t/04live.t line 10.
--
Peter Karman . http://peknet.com/ . pe...@peknet.com
gpg key: 37D2 DAA6 3A13 D415 4295 3A69 448F E556 374A 34D9
___
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] RenderView install problem
On Tue, Jun 30, 2009 at 05:04:36PM -0500, Peter Karman wrote: apologies if this has been reported elsewhere. That was a regression iN Catalyst-Runtime 5.80006. It's fixed in 5.80007. -- BOFH excuse #129: The ring needs another token signature.asc Description: Digital 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/
[Catalyst] [ANNOUNCE] Catalyst-Runtime-5.80007
The Catalyst core team is pleased to announce the availability of the
latest maintenance release of Catalyst-Runtime, version 5.80007.
This fixes an important regression with actions on the application
class which have custom attributes (for example, end : ActionClass
('RenderView')). Whilst putting actions into your application class
is deprecated, a number of extensions test suites (such as Action-
RenderView) rely on it.
Full changelog for this release:
Bug fixes:
- Don't mangle query parameters passed to uri_for
- Tests for this (Byron Young + Amir Sadoughi)
- Inherited controller methods can now be specified in
config-{action(s)}
- Assigning an undef response body no longer produces warnings
- Fix C3 incompatibility bug caused if you use Moose in
MyApp.pm and
add Catalyst to the right hand side of this in @ISA.
- Make Catalyst.pm implement the Component::ApplicationAttribute
interface so defining actions in MyApp.pm works again, if the
actions have attributes that cause $self-_application to
be used
(like ActionClass).
New features:
- Add optional second argument to uri_with which appends to
existing
params rather than replacing them. (foo=1 becomes
foo=1foo=2 when
uri_with({ foo = 2 }, { mode = 'append' }) is called on a
foo=1
URI.
Cheers
t0m
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
