> // ParseManual: int yylex(void)
[...]
// InlineParse: ON
int yylex(void) {
// InlineParse: OFF
...
I've been using
Inline(Parse|Code)(Start|Stop)
InlineDont(Parse|Code)
The first four control multi-line processing.
The last two control single lines.
Any excised text is replaced by shaped whitespace to preserve line and
character positions (ie, $txt =~ s/[^\n]/ /g;).
Inline(Parse|Code)(Start|Stop) wipe out their entire line.
So commenting "/* InlineParseStop */" works for when you want it.
One can be implicit (beginning-of-code ... start ...),
or explicit (beginning-of-code stop ... start ...).
The code selection and parse selection are independent.
class illustration {
InlineParseStop
void dont_export_me_to_perl () {}
void inline_doesnt_understand(templates<int> var) {}
InlineParseStart
int normal () { return 42; }
InlineDontParse Frob* get_Frob (); // C++ code given Frob pointers,
InlineDontCode void* get_Frob (); // which I dont want to explain to Inline.
}
2 lines instead of one, remembering to set something on then off (just for
If one wants one liners, one might use InlineDoParse.
I dropped the InlineDo's at some point, as I was rarely/never using them.
Mitchell Charity
Date: Tue, 22 Oct 2002 17:54:57 -0700
To: nadim <nadim[at]khemir.net>
Cc: Inline Mailing List <inline[at]perl.org>
Subject: Re: Some Inline Benchmarks
Message-ID: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
From: ingy[at]ttul.org (Brian Ingerson)
On 23/10/02 01:05 +0200, nadim wrote:
> On Saturday 12 October 2002 01:07, Brian Ingerson wrote:
> > At least on my machine, the parsing isn't the real culprit. I'm eager to
> > see Nadim's results. ;)
>
> Hi all, I finally got tired of this parsing non sense. Why should I parse
> hundreds of KB of code to find the one function I know will be there since
> I put it there in the first place.
>
> ParseRecDescent and ParseRegExp are fine as long as the code is unknown or
> not too difficult to parse (ParseRegExp fails on flex generated code (you
> can't blame it for that ;-))
>
> With ParseManual you must declare the function you want to be exposed, in
> my case (works with whatever comment type you have);
> %{
> // ParseManual: int yylex(void)
> %}
Cool.
I have been thinking of something a little more flexible:
// InlineParse: ON
int yylex(void) {
// InlineParse: OFF
...
I think having a standard way of telling Inline what to parse, and what not
to is a fine idea. I'd be glad to start discussing this in the next release.
In the mean time, I think your hack is a great way to do it.
Cheers, Brian