2008Q3 Grant Proposal: Libperl++

| 10 Comments
  • Author: Leon Timmermans
  • Title: Libperl++ (but see project details for more information on a naming issue)
  • Synopsis: Currently embedding perl is too complicated. The API requires too much knowledge of internals to use and is too incompatible with other libraries (mainly due to the usage of macros). Therefore I've started a project to ease the embedding of Perl. Though the code works, it is not ready for public consumption yet. In this proposal I want to make it ready for widespread adoption.

Author
Leon Timmermans

Title
Libperl++
(but see project details for more information on a naming issue)

Synopsis
Currently embedding perl is too complicated. The API requires too much knowledge of internals to use and is too incompatible with other libraries (mainly due to the usage of macros). Therefore I've started a project to ease the embedding of Perl. Though the code works, it is not ready for public consumption yet. In this proposal I want to make it ready for widespread adoption.

Benefits to the Perl Community
Currently perl is only embedded in a handful of application (Apache's mod_perl is the best known example of this). This library could lead to increased adoption of perl as an embedded language, a role it currently isn't particularly strong in.

Deliverables

  • Document the whole API
  • Generate broad unit testing
  • Port the code to perl 5.10
  • Add regexp support (may not be workable on perl 5.8)
  • Make build process portable
  • Make exporting of functions, methods and constructors robust enough for real usage.

Project Details
libperl++ is a C++ library that provides a more friendly interface for the perl API. It makes use of advanced features of C++ to make both embedding and extending perl as easy as possible. I guess an example is worth more than a description.

Interpreter universe;
Package dbi = universe.use("DBI");
Ref foo = dbi.call("connect", "dbi:SQLite:dbname=dbfile", "", "");
Array bar = foo.call_array("selectrow_array", "SELECT * FROM test WHERE name = ?", universe.undef(), "a");
bar2 = "c";
String packed = bar.pack("a*");

// These two do the same
std::foreach(bar.begin(), bar.end(), print);
bar.each(print);

Ref sub = universe.eval("sub { print \"@_\n\"}");
sub(bar);

Ref baz = bar.take_ref();

universe.export_sub("atan", atan);
Scalar angle = universe.eval("atan(1)");

Issues left:

Not all of the API has been documented, nor is there a proper tutorial. This obviously needs to be rectified.

Another major issue is that there is no unit testing yet. This is mainly because there is no proper C++ testing framework that outputs TAP. I've started writing just that, but I still have to make the tests themselves.

The code was written using PERL_NO_SHORT_NAMES on perl 5.8. However this has generated some incompatibilities with perl 5.10. These need to be fixed.

Regexp support is currently a rather notable missing feature in the library. This is because perl 5.8 is somewhat resistant to that. I'm having the impression it won't be too much work to add it with perl 5.10, and it can probably be wrapped into 5.8.

Currently the building process is a simple makefile. That obviously isn't a very portable or maintainable solution. Currently neither ExtUtils::MakeMaker nor Module::Build seem to be capable of making shared libraries. I'm planning to move to a better solution.

I have implemented exportation of C++ functions, methods and constructors to perl, but (specially the latter two) still have some issues left to make them more usable in real projects.

Naming issue:
There already is a library with a similar purpose and name. It's implementation is quite old and unmaintained, but of the name collision is too much of a hassle I can always rename it.

Project Schedule
I can start in September. I think I can do the work spread out over a period of 3 or 4 months.

Biography
I'm a 23 years old Dutch university student who has been programming perl for some 8 years. ve As the author of this project I am the most logical person to do it.

Amount Requested
Since this is a big project I'd like to request the maximal amount of $3000.

10 Comments

I see this as a valuable project for two reasons: (1) C++ programmers who want to dabble with a bit of Perl to see how it works can do so without really leaving the C++; and (2) programmers who are already experienced in Perl can use it to make their life easier when doing some C++ projects. I'm fairly certain the second reason is better than the first, and farther reaching, but I know that it would help me persuade at least one of my C++ friends to consider Perl.

I have opposite experience - perl has fine embedding API, especially when you're talking about C or C++ (it is written in C, unsurprisingly).

Also there were accepted patches on P5P for building Perl with C++

I, personally, have experience of some 8-10 years ago embedding Perl into C++ application - in my case this was GUI application written in Borland CBuilder - perl was Active-state-built, myself-built (with Borland or MSVC) - all was smooth - and I even have not used SWIG!

I am sure I was not alone in embedding Perl into C++.

Writing yet another library is a waste of effort, IMO.

Well, if you think it is easy I'd like to challenge you to write the small program in my example using the perl API. It is not as simple as you say and it's definitely not as easy as it should be IMO.

you didn't convince me.

I will not take your challenge to embed Perl into your C++ program, although I did quite a lot of miscellaneous embeddings (for example see my CPAN module, but I did much more for my particular tasks)


my experience of Perl embedding for C++ was easy, your embedding was hard

I guess you're trying to solve a task from the wrong end.

Also I could believe that you want to create come C++ classes to solve your particular task, but I fail to see why it is useful for the community - the API is already easy to use, see "perldoc perlembed", "perldoc perlguts", etc.

I really wish I had this right now. I am trying to embed an interpreter in a large commercial monte-carlo C++ simulation system. I would like to use Perl, but it became clear from experimentation that to use it in any remotely encapsulated way (not litter the whole project namespace with perl stuff) I would have to write my own abstraction layer, like this grant proposal.

I would like to add that Python and TCL have Boost.Python and C++/Tcl respectively.

Perl should follow suite and get good C++ bindings.

I would like to support Leon. I did a small embedding project (Perl inside STAF) and I found the experience... challenging. Really had to understand a lot of internal details, memorize a whole pack of functions, and wad through a sea of API.

A normal C++ interface is welcome.

Shmuel.

Seems a sensible enough goal.

Joining in, I say c++ interface would be really help alot; I support this proposal.

Please help me with Libperl++ using. I have a problem. This simple code has errors on linking stage:

#include
#include "perl-glue.hh"

int main(){
wPerl p;
p.eval("$hash = {'a' => 1,'b' => 2, 'c' => 3};foreach $key(keys %$hash){print $hash{$key};}");
return 1;
}

Errors:
Linking...
1>perl+c.obj : error LNK2019: unresolved external symbol "public: virtual __thiscall wPerl::~wPerl(void)" (??1wPerl@@UAE@XZ) referenced in function _main
1>perl+c.obj : error LNK2019: unresolved external symbol "public: __thiscall wPerlScalar::~wPerlScalar(void)" (??1wPerlScalar@@QAE@XZ) referenced in function _main
1>perl+c.obj : error LNK2019: unresolved external symbol "public: class wPerlScalar __thiscall wPerl::eval(char const *)" (?eval@wPerl@@QAE?AVwPerlScalar@@PBD@Z) referenced in function _main
1>perl+c.obj : error LNK2019: unresolved external symbol "public: __thiscall wPerl::wPerl(void)" (??0wPerl@@QAE@XZ) referenced in function _main
1>C:\Users\123\Documents\Visual Studio 2008\Projects\perl+c\Debug\perl+c.exe : fatal error LNK1120: 4 unresolved externals
1>Build log was saved at "file://c:\Users\123\Documents\Visual Studio 2008\Projects\perl+c\perl+c\Debug\BuildLog.htm"
1>perl+c - 5 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Please answer me on my email if it is possible to solve this errors.

Leave a comment

About this Entry

This page contains a single entry by Alberto Simões published on August 1, 2008 12:00 PM.

2008Q3 Grant Proposal: Bavl was the previous entry in this blog.

2008Q3 Grant Proposal: Improve POE::Component::IRC is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.