Hey
Have anybody heard of
<:& ''some
perl
code''
> or
<:
''some perl
code''
>
tags ?
If so, what module is
responsible for handling those ?
I think it looks somethin
with porting straight from Mason?
Part two would be to replace the inline code with tt2 directives- thought
it was worth mentioning this before getting flamed. :)
I'm just after evaluation with
On Mon, 8 Apr 2002, Rafiq Ismail (ADMIN) wrote:
> Converting Mason to TT2 stuff
Hi.
May I suggest you repost this to the template toolkit list?
http://www.template-toolkit.org/mailman/listinfo/templates
Sounds like you're getting confused between [% %] for template code
and [% PERL %] ... [%
Mark Fowler wrote:
> Sounds like you're getting confused between [% %] for template code
> and [% PERL %] ... [% END %] for actual real perl code
Agreed. Also, any significant Mason component is likely to use Mason's
built-in object model, which is not part of TT. You will probably have
to p
. perl
and inline perl based than it is custom mason. Other than the fact that
it gets rendered by mason, it is pretty independent.
It's just the fact that in spite of my specifying that it should use
inline_perl, it didn't interpolate the inline code which uses custom
modules in mas
Rafiq Ismail (ADMIN) wrote:
> It's just the fact that in spite of my specifying that it should use
> inline_perl, it didn't interpolate the inline code which uses custom
> modules in mason tags. I've got it to try and interpolate now, however it
> seems to warn that &
I'm having problems with Embperl 1.2.0. It core dumps
when calling Execute() with $fdat and $ffld params on
input files with tags that contain value params
, eg. . Embperl 1.2b4 has no problem
with it though.
A sample cgi script:
#!/usr/local/bin/perl
use strict;
use HTML::Embperl ()
Hi,
which part of an Apache/mod_perl setup is responsible for extracting META
tags from generated HTML and adding them as HTTP headers (even with
PerlSendHeaders Off)? In the case of META NAME='Blah' tags, it adds
X-Meta-Blah headers, which are harmless but probably mostly a waste of
> I'm having problems with Embperl 1.2.0. It core dumps
> when calling Execute() with $fdat and $ffld params on
> input files with tags that contain value params
> , eg. . Embperl 1.2b4 has no problem
> with it though.
>
There where serveral changes in the option handlin
'
Gerald Richter wrote:
>
> > I'm having problems with Embperl 1.2.0. It core dumps
> > when calling Execute() with $fdat and $ffld params on
> > input files with tags that contain value params
> > , eg. . Embperl 1.2b4 has no problem
> > with it thou
> I got embperl_19991229171455_tar from CVS but still have the
> same problem. Make test also fails on lists.htm (see below).
Does the test also fail for 1.2.0?
> I'll try to run a stacktrace in gdb tomorrow.
>
Great! I like to fix it before 1.2.1
>
> Summary of my perl5 (5.0 patchlevel 4 su
Here's the info you asked for:
Gerald Richter wrote:
>
> > I got embperl_19991229171455_tar from CVS but still have the
> > same problem. Make test also fails on lists.htm (see below).
>
> Does the test also fail for 1.2.0?
Yes, same error.
$ make test
PERL_DL_NONLAZY=0 /projects/perl.dev/bin
>
> Here's a gdb stacktrace. I compiled embperl with -g (but
> not the perl executable).
Looks like you forgot to link with debug infos (see
http://perl.apache.org/embperl/Faq.pod.1.html#How_do_I_build_Embperl_with_de
bu )
> I had to set heuristic-fence-post
> to a large value and run the trace
At 01:20 AM 01/19/02 +0100, Markus Wichitill wrote:
>which part of an Apache/mod_perl setup is responsible for extracting META
>tags from generated HTML and adding them as HTTP headers (even with
>PerlSendHeaders Off)?
That's lwp doing that, not Apache or mod_perl.
> HEAD http
01:20 AM 01/19/02 +0100, Markus Wichitill wrote:
> >which part of an Apache/mod_perl setup is responsible for extracting META
> >tags from generated HTML and adding them as HTTP headers (even with
> >PerlSendHeaders Off)?
>
> That's lwp doing that, not Apache or mod_per
At 04:46 PM 01/18/02 -0800, ___cliff rayman___ wrote:
>hmmm - you are still using lwp.
Right. But lwp-request sends a GET request where HEAD sends, well, a HEAD
request. So, even though LWP's default is to parse the section,
there's no content to parse in a HEAD request, and thus the headers
Stas wrote:
> Matthew, can you please repost it to the mod_perl list?
> There are many more people who can followup on this.
> Thanks.
I won't be subscribed long enough to read any replies to this mesg, but
am posting here at Stas' suggestion. Hopefully someone here will be able
to update the doc
17 matches
Mail list logo