RFC for new module Inline::C

[Brian Ingerson]

I am preparing the next major release of Inline.pm. One important
features of this release is to provide support for easily adding new
languages to Inline. In doing so, I needed to separate the rather
hard-wired workings of C support from the generic Inline code. 

This has left me with a new module Inline::C. There is a simple API
between Inline and Inline::C which allows for the addition of new
language support from other programmers, without needing to change the
base Inline.pm module. Inline::CPP and Inline::Python have already been
written by Neil Watkiss. Also there is nothing preventing others from
reimplementing the C, C++ or Python modules to suit their own needs.

Inline::C will be distributed along with Inline.pm (in the Inline-0.30
distribution) to prevent any confusion. I think this makes the more
sense than distributing Inline::C as its own package, because C is so
closely tied to Perl, and will probably be the most popular language by
far.

I am writing this to make sure that Inline::C still gets added to the
big modules list. It will look strange if people see Inline::Python and
not Inline::C.

Brian


-- 
perl -le 'use Inline C=>q{SV*JAxH(char*x){return newSVpvf
("Just Another %s Hacker",x);}};print JAxH+Perl'

RFC for new module Inline::C

[Brian Ingerson]

Sorry. Clicked 'send' too soon. Here's the DSLI info:

Inline::C   bdpO  Write C extensions in Perl the easy way INGY

See:
http://www.xray.mpe.mpg.de/mailing-lists/modules/2000-11/msg00463.html

Thanks, Brian

RFC for new module Inline::CPR

[Brian Ingerson]

Inline.pm makes it easy to *extend* Perl with C. But what about
embedding Perl in C? As I thought about this problem I came up with an
entirely new programming language: CPR (C Perl Run). CPR is just like C
except that you have access to the entire internals of Perl using either
the Perl5 API, or the CPR API. Here is a 'Hello World' program in CPR:

---8<
#!/usr/bin/cpr

int main(void) {
printf("Hello World, I'm running under Perl version %s\n",
   CPR_eval("use Config; $Config{version}"));
return 0;
}
---8< 

Yup, you guessed it, run the code under the CPR interpreter (hashbang
style or not) and your C code gets compiled/run seamlessly just like
with Inline!

This is embedding turned inside out. You run 'cpr' which execs 'perl'
which uses 'Inline::CPR' which binds and invokes 'main'. So your whole C
program is really just a Perl extension. By rights, this gives you full
access to the Perl5 API. And if you wrap that with a nice clean 'CPR_'
set of macros, you kind of get a new language. Don't you? :-)

I wish to distribute this as Inline::CPR. Here is the DSLI info:

Inline::CPR  adpO  Simple way to embed Perl in C ala Inline  INGY

-- 
perl -le 'use Inline C=>q{SV*JAxH(char*x){return newSVpvf
("Just Another %s Hacker",x);}};print JAxH+Perl'

Re: XML::Driver::Elemental? XML::Filter::Validator?

[Ken MacLeod]

barries <[EMAIL PROTECTED]> writes:

> Also planning to writing XML::Filter::Validator, to do the same
> validation as XML::ValidWriter, unless someone's got one (also
> searched CPAN for that).  Throwing a validation step on the
> XML output chain has been quite useful to us in development,
> highlighting glitches in DTDs or code.

Just wanted to note that SAX2 modules should go in the namespaces
SAXDriver::*, SAXFilter::*, and SAXHandler::*.  This gives them a
consistent new home, and also helps to distinguish them from SAX1
modules already under XML::*.

Summarizing past discussion: the Perl module list maintainers
recommended multiple top-levels for this particular type of naming (so
populating the top-level namespace in this way is intentional).  And
they specifically recommended against three-level naming of modules
that go on a module list (thus deprecating any type of
SAX::*::ModuleName or XML::*::ModuleName scheme).

(XML specific notes follow.)

Otherwise the modules look great.  I didn't see mention of reference
to XML::Writer, which also has a nice script interface for generating
XML, and excellent well-formedness checking too.  XML::Writer with
SAX2 output would likely be what you're thinking of with
XML::Driver::Elemental.

A feature you might want consider, to more easily support namespaces,
is to let the caller register prefixes for method and attribute names
(like 'prefix_local_name'), then output the declarations on the first
element or as they are defined, and then substitute ':' for the first
underscore in the element or attribute name.

  -- Ken

Cc'd to [EMAIL PROTECTED] just to make sure that's still the case ;-)

The perl 5 module list

I noticed that there is a module in the list called Term::Scraper, the link to it is 
dead. Do you know of where I can get a copy of it?