Inline::SWIG

Mitchell N Charity

unread,

Oct 1, 2002, 12:16:26 AM10/1/02

to inl...@perl.org, sw...@cs.uchicago.edu

SWIG (http://www.swig.org/) does some nice parsing and glue generation.
In particular, it has rather broader coverage of C++ than Inline::CPP
(templates, operators, etc).

Perl's Inline (http://www.perldoc.com/cpan/Inline.html) is sometimes
more convenient. Particularly for small bits of code. Glue generation,
compilation, caching, and linking, all happen automagically. And it
facilitates run-time code generation.

So I wrote an Inline::SWIG
http://www.vendian.org/mncharity/dir3/inline/swig/
SWIG's glue inside Inline's process support.

It's a kludge. A concept demo. But I've found it useful.

Like other Perl Inline modules, one should be able to use it from
Python via zope-perl (http://www.zope.org/Wikis/zope-perl/FrontPage).

Fyi,
Mitchell Charity

Brian Ingerson

unread,

Oct 2, 2002, 3:03:17 AM10/2/02

to Mitchell N Charity, inl...@perl.org, sw...@cs.uchicago.edu

On 01/10/02 00:16 -0400, Mitchell N Charity wrote:
> SWIG (http://www.swig.org/) does some nice parsing and glue generation.
> In particular, it has rather broader coverage of C++ than Inline::CPP
> (templates, operators, etc).
>
> Perl's Inline (http://www.perldoc.com/cpan/Inline.html) is sometimes
> more convenient. Particularly for small bits of code. Glue generation,
> compilation, caching, and linking, all happen automagically. And it
> facilitates run-time code generation.
>
> So I wrote an Inline::SWIG
> http://www.vendian.org/mncharity/dir3/inline/swig/

Mitchell, This sounds awesome. You're a genius. Any chance of putting it
on CPAN? I could help you there.

I'm wondering, is it abstract enough so that we could just make it part of
Inline? We could let people pick what type of glue code they want.

I was thinking of writing my own glue code, sans XS, so that we could get rid
of XS altogether. We could do it without Makefile.PL too which I think would
make code generation/compiling very fast. Just:

- Parse using your regex parser (instead of RecDescent)
- Generate pure C glue
- Feed it right to gcc

So now we'd have three different gluing options

- SWIG
- XS
- IngyLine

Don't worry folks, I won't throw out the XS for good. It's way too stable.
But a faster option might be good for some applications.

Cheers, Brian

Mitchell N Charity

unread,

Oct 2, 2002, 2:03:25 PM10/2/02

to Brian Ingerson, inl...@perl.org

Any chance of putting [Inline::SWIG] on CPAN?

If there is interest. I was planning to wait.

Thinking of this -0.00 version as an alpha pre-release, to catch
newborn infant issues, and determine popular interest. More
fundamentally, its parasitation of SWIG (and Inline::C) is rather
fragile, so the version's life expectancy is not large. I would be
surprised (unhappiliy so) if it were still working a year from now.
So CPAN seemed a later step.

I'm wondering, is it abstract enough so that we could just make it part of
Inline? We could let people pick what type of glue code they want.

[Architecture discussion taken offline...]

Cheers,
Mitchell

Date: Wed, 2 Oct 2002 00:03:17 -0700
From: Brian Ingerson <in...@ttul.org>
To: Mitchell N Charity <mcha...@vendian.org>
Cc: inl...@perl.org, sw...@cs.uchicago.edu
Subject: Re: Inline::SWIG
Message-ID: <2002100200...@ttul.org>
References: <200210010416...@vendian.org>
In-Reply-To: <200210010416...@vendian.org>;
from mcha...@vendian.org on Tue, Oct 01, 2002 at 12:16:26AM -0400

Brian Ingerson

unread,

Oct 7, 2002, 9:29:25 PM10/7/02

to Inline Mailing List

NOTE: This is from an offline thread with Mitchell that I am forwarding with
his permission.

On 06/10/02 19:15 -0400, Mitchell N Charity wrote:
> Hi Brian,
>
> Wow, lots of things happening with Inline.
> Awesome.

Yes. It is pretty cool. Inline is exciting for me again. Last year it was
YAML. But I have enough people to carry that along for a while. And YAML is
only 1/3rd my ideas. This is Inline part two. Inline gets serious. Well,
hopefully.

> A couple of thoughts:
>
> GLUE vs PARSER vs WRAPPER --
>
> A possible set of definitions is
>
> PARSER takes code to types. There are two existing examples, the
> recdescent and regexp-based versions.
>
> WRAPPER takes types and generates stubs. There is the current XS
> based version, and the proposed non-XS version you mentioned.
>
> GLUE takes code and generates stubs.

PREPROCESSOR or FILTER is another possible step.

>
> Two complications:
>
> The non-XS wrapper will probably also be messing with the build
> details (no Makefile.PL, etc). So it might need a {BUILD} var to
> alter.
>
> One might perhaps get by with only a "ui simple" GLUE => mumble
> flag, if one could specify multiple GLUE's, and Inline could figure
> out what was being asked for. If can($glue_argument,'compile') etc.
> The upside of this complication is that the UI is smaller (1 flag
> vs 3), and perhaps more easily extensible (if we need to add more
> than the 3). Perhaps a general VARIANT mechanism?

I like a multiple inheritance mechanism like OVERRIDES. One keyword
specifying one or more classes to inherit the various parts from. And I
like keeping it all one directory below the Language Module. Example:

use Inline C => DATA =>
OVERRIDES => [ParserRegexp, GlueSwig];

This would of course inherit methods from:

Inline::C::ParserRegexp
Inline::C::GlueSwig
Inline::C::GlueDefault

in that order. GlueDefault would contain all the default methods.
Any variant module would contain one or more overrides. This would
scale nicely.

> Installing swig via CPAN --
>
> My initial reaction is "Please no". :)
>
> I don't know of any CPAN packages which take this approach, and many
> which take the much simpler "if you try to install the module, but
> the underlying libraries/programs are not available, then fail and
> suggest they be installed".
>
> I think simplicity should trump making it easier for folks to play
> with substituting SWIG for the standard Inline parser/stubbers.
>
> At least in the near term.
> It's not like there isn't lots of other stuff to do.
>
> No?

No! This is my initial reaction. :-)

I can count on zero hands how many CPAN modules use SWIG. SWIG will
never make any impact on the CPAN unless it can be installed as a
prerequisite module. Some modules require non CPAN components, like
XML::Parser. That's justified because, "What else are you going to do?".
But SWIG is just a glue layer and XS is available on every Perl
installation. To build over SWIG would be the kiss of death.

But if SWIG were just a module prereq, it might have a fighting chance.
I suppose we'd have to coordinate with Dave Beazley. I'm pretty good at
creating CPAN software distributions that don't just contain Perl
modules. I think putting SWIG on CPAN is doable. We should at least
give it a try.

> Naming parsers --
>
> One possibility to bear in mind is a naming convention without
> subdirectories. Something like
> Inline::C::ParseRecDecent.pm
> Inline::C::ParseRegex.pm
> rather than
> Inline::C::Parse::RecDecent.pm
>
> The possible advantage being that parsers may be a best-case in
> terms of clean-ness of partitioning. Other modules may be messier
> mixes of tasks. If there is a Inline::C::Parse directory, and an
> Inline::C::Wrap, etc, where does one put modules which do more than
> one of these?

+1 Good idea. I think this is coming together. Can you think of a better
keyword than OVERRIDES or VARIANTS?

Cheers, Brian