On Fri, 17 May 2002, Doug MacEachern wrote:
> On Fri, 17 May 2002, Dave Rolsky wrote:
>
> > And code:
> >
> > package HTML::Mason::FileEcho;
>
> works fine here. can you use $r->anything? $r->uri, $r->hostname or
> $r->the_request for example? perl -V might shed some light.
Nope, looks like a
On Fri, 17 May 2002, Dave Rolsky wrote:
> And code:
>
> package HTML::Mason::FileEcho;
works fine here. can you use $r->anything? $r->uri, $r->hostname or
$r->the_request for example? perl -V might shed some light.
-
T
On Fri, 17 May 2002, Doug MacEachern wrote:
> actually, 5.6.1 would have had the same issue. its 5.6.0 where G_METHOD
> is not implemented. if you give a whirl with cvs, it should be working
> now.
Yep, that part seems to work fine.
> ok, i'd need a test case to reproduce to figure out the pr
On Fri, 17 May 2002, Dave Rolsky wrote:
> Nope, I'm using 5.6.1. Perhaps that explains the problem?
actually, 5.6.1 would have had the same issue. its 5.6.0 where G_METHOD
is not implemented. if you give a whirl with cvs, it should be working
now.
> > > FWIW, a non-method handler seems t
On Fri, 17 May 2002, Doug MacEachern wrote:
> On Fri, 17 May 2002, Dave Rolsky wrote:
>
> > Defining a "sub handler : method" does not seem to be working.
>
> you are using bleedperl, yes? this should be fixed now. we had been
> passing the G_METHOD flag to call_sv(), which does nothing with 5.
On Fri, 17 May 2002, Doug MacEachern wrote:
> > It's in /usr/lib instead.
>
> that is bogus. why do they do that?
I dunno. I can file a bug against the package.
> > Is this a problem with the assumptions in the Apache::Build code or is it
> > a Debian problem?
>
> debian. we could probably a
On Fri, 17 May 2002, Dave Rolsky wrote:
> Defining a "sub handler : method" does not seem to be working.
you are using bleedperl, yes? this should be fixed now. we had been
passing the G_METHOD flag to call_sv(), which does nothing with 5.6.1, but
broke bleedperl. there no need for us to us
On Fri, 17 May 2002, Dave Rolsky wrote:
> I noticed that this is set via this code in Apache::Build ...
>
>
> print $fh $self->canon_make_attr('libperl',
> join '/',
> $self->perl_config('archlibexp'),
>
I'm playing with the latest CVS version in order to make sure that Mason
will work with the backwards compatibility layer.
Defining a "sub handler : method" does not seem to be working.
If I do this:
sub handler : method
{
my ($package, $r) = @_;
my $ah = $AH || $package->make_ah();
I noticed that this is set via this code in Apache::Build ...
print $fh $self->canon_make_attr('libperl',
join '/',
$self->perl_config('archlibexp'),
'CORE',
On Sat, 18 May 2002, Stas Bekman wrote:
> err_header_out() is not available in 2.x. We sugest to use
> err_headers_out() instead. but we don't have it in the compat layer.
>
> Should we implement it in Apache::compat similar to header_out()?
yes.
> $r->content() was dropped. should we provid
On Fri, 17 May 2002, Stas Bekman wrote:
> Currently we have a problem with Constants in 1.x and 2.x which don't
> map 1:1, since in 2.0 some constants are gone, some are renamed. See the
> report below.
REDIRECT and the like have been deprecated in apache for years, in favor
of the HTTP_* nam
I'm working on completing the compat.pod doc:
http://perl.apache.org/release/docs/2.0/user/compat/compat.html
and have a few questions:
---
err_header_out() is not available in 2.x. We sugest to use
err_headers_out() instead. but we don't have it in the compat layer.
Should we implement it in
Currently we have a problem with Constants in 1.x and 2.x which don't
map 1:1, since in 2.0 some constants are gone, some are renamed. See the
report below.
How should we deal with that? Currently Apache::compat only forwards the
symbols to Apache::Const, so this doesn't always work.
Do we ne
14 matches
Mail list logo
