I'm pleased to make public my Google Summer of Code project: Verrazano.
Verrazano is the C++ bindings generator formerly known as Fetter. The
project page can be found at http://common-lisp.net/project/fetter. The
development mailing list, where all discussion regarding the project is
taking place, can be found at
http://common-lisp.net/mailman/listinfo/fetter-devel.
The objectives of the project are as follows:
1) To allow easy integration of C++ libraries into Lisp programs. Using
a C++ library in Lisp code should be almost as easy as using a regular
Lisp package.
2) To offer robust C++ support through the use of GCC-XML. GCC-XML
offers us the full power of the GNU C++ parser, and gives the program a
level of header file compatibility that custom parsers cannot easily
match.
3) To ease the creation of language-specific backends by performing
most of the complicated language-independent transformations in the
frontend.
4) To be easy to maintain and extend, through reuse of existing code
whenever possible as well as the use of a formal, documented,
intermediate representation.
Currently, Verrazano targets UFFI, but over the next few days the
backend will be moved over to C-FFI, which is being improved by
Hello-C, Verrazano's sister Google SoC project. In the next month
leading up to the Google SoC deadline, C++ support will be implemented
on top of the existing C infrastructure, and the ease-of-use of the
program will be improved.
I welcome everybody interested in the project to send an email to the
development list. You can also browse the website, download the
initially available documentation, take a look at the code in CVS, or
tune in to my weekly progress reports on the mailing list. I would
greatly appreciate any feedback the people on this list have,
especially of the following sort:
- Design suggestions
- Wishlist items or features
- Comments on how to Lisp-ify generated bindings, both for C and C++.
My goal is to make Verrazano a useful programming tool, so the feedback
of real programmers is an invaluable resource to me.
--- Rayiner Hashem
On Mon, 08 Aug 2005 16:10:27 -0700, rayiner wrote:
> I'm pleased to make public my Google Summer of Code project: Verrazano.
> Verrazano is the C++ bindings generator formerly known as Fetter. The
> project page can be found at http://common-lisp.net/project/fetter. The
> development mailing list, where all discussion regarding the project is
> taking place, can be found at
> http://common-lisp.net/mailman/listinfo/fetter-devel.
>
Hello Rayiner,
I just tried to check-out the code but my cvs client reports:
Fatal error, aborting.
anonymous: no such user
Looks like the CVS repository has some problems.
TIA Ralf Mattes
·······@gmail.com wrote:
> I'm pleased to make public my Google Summer of Code project: Verrazano.
> Verrazano is the C++ bindings generator formerly known as Fetter. The
> project page can be found at http://common-lisp.net/project/fetter. The
> development mailing list, where all discussion regarding the project is
> taking place, can be found at
> http://common-lisp.net/mailman/listinfo/fetter-devel.
>
> The objectives of the project are as follows:
>
> 1) To allow easy integration of C++ libraries into Lisp programs. Using
> a C++ library in Lisp code should be almost as easy as using a regular
> Lisp package.
>
> 2) To offer robust C++ support through the use of GCC-XML. GCC-XML
> offers us the full power of the GNU C++ parser, and gives the program a
> level of header file compatibility that custom parsers cannot easily
> match.
>
> 3) To ease the creation of language-specific backends by performing
> most of the complicated language-independent transformations in the
> frontend.
>
> 4) To be easy to maintain and extend, through reuse of existing code
> whenever possible as well as the use of a formal, documented,
> intermediate representation.
>
> Currently, Verrazano targets UFFI, but over the next few days the
> backend will be moved over to C-FFI, which is being improved by
> Hello-C, Verrazano's sister Google SoC project. In the next month
> leading up to the Google SoC deadline, C++ support will be implemented
> on top of the existing C infrastructure, and the ease-of-use of the
> program will be improved.
>
> I welcome everybody interested in the project to send an email to the
> development list. You can also browse the website, download the
> initially available documentation, take a look at the code in CVS, or
> tune in to my weekly progress reports on the mailing list. I would
> greatly appreciate any feedback the people on this list have,
> especially of the following sort:
>
> - Design suggestions
> - Wishlist items or features
> - Comments on how to Lisp-ify generated bindings, both for C and C++.
>
> My goal is to make Verrazano a useful programming tool, so the feedback
> of real programmers is an invaluable resource to me.
>
> --- Rayiner Hashem
Sounds great!
<dreaming>
Maybe some lispers might start a project for creating QT-bindings
</dreaming>
regards
oni
--
(+::+) oni (+::+)
(I already try to be as amusing as possible, my master!)
Onay Urfalioglu wrote:
> ·······@gmail.com wrote:
>
>
>>I'm pleased to make public my Google Summer of Code project: Verrazano.
>>Verrazano is the C++ bindings generator formerly known as Fetter. The
>>project page can be found at http://common-lisp.net/project/fetter. The
>>development mailing list, where all discussion regarding the project is
>>taking place, can be found at
>>http://common-lisp.net/mailman/listinfo/fetter-devel.
>>
>>The objectives of the project are as follows:
>>
>>1) To allow easy integration of C++ libraries into Lisp programs. Using
>>a C++ library in Lisp code should be almost as easy as using a regular
>>Lisp package.
>>
>>2) To offer robust C++ support through the use of GCC-XML. GCC-XML
>>offers us the full power of the GNU C++ parser, and gives the program a
>>level of header file compatibility that custom parsers cannot easily
>>match.
>>
>>3) To ease the creation of language-specific backends by performing
>>most of the complicated language-independent transformations in the
>>frontend.
>>
>>4) To be easy to maintain and extend, through reuse of existing code
>>whenever possible as well as the use of a formal, documented,
>>intermediate representation.
>>
>>Currently, Verrazano targets UFFI, but over the next few days the
>>backend will be moved over to C-FFI, which is being improved by
>>Hello-C, Verrazano's sister Google SoC project. In the next month
>>leading up to the Google SoC deadline, C++ support will be implemented
>>on top of the existing C infrastructure, and the ease-of-use of the
>>program will be improved.
>>
>>I welcome everybody interested in the project to send an email to the
>>development list. You can also browse the website, download the
>>initially available documentation, take a look at the code in CVS, or
>>tune in to my weekly progress reports on the mailing list. I would
>>greatly appreciate any feedback the people on this list have,
>>especially of the following sort:
>>
>>- Design suggestions
>>- Wishlist items or features
>>- Comments on how to Lisp-ify generated bindings, both for C and C++.
>>
>>My goal is to make Verrazano a useful programming tool, so the feedback
>>of real programmers is an invaluable resource to me.
>>
>> --- Rayiner Hashem
>
>
>
> Sounds great!
> <dreaming>
> Maybe some lispers might start a project for creating QT-bindings
> </dreaming>
Well, the whole point of Vzn is to eliminate binding "projects". You
just feed it a C header or two and start using the library. If
successful, half of common-lisp.net can be eliminated. :)
btw, QT rings a bell. I think that might be one of Rayiner's test targets.
--
Kenny
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"I've wrestled with reality for 35 years, Doctor, and I'm happy to state
I finally won out over it."
Elwood P. Dowd, "Harvey", 1950
Kenny Tilton wrote:
>> Sounds great! <dreaming>
>> Maybe some lispers might start a project for creating QT-bindings
>> </dreaming>
>
> Well, the whole point of Vzn is to eliminate binding "projects". You
> just feed it a C header or two and start using the library. If
> successful, half of common-lisp.net can be eliminated. :)
>
> btw, QT rings a bell. I think that might be one of Rayiner's test targets.
I've never used it, but doesn't Qt deviate from standard C++ a lot, with
its own preprocessor etc.?
--
I believe in Karma. That means I can do bad things to people
all day long and I assume they deserve it.
Dogbert
Ulrich Hobelmann wrote:
> Kenny Tilton wrote:
>>> Sounds great! <dreaming>
>>> Maybe some lispers might start a project for creating QT-bindings
>>> </dreaming>
>>
>> Well, the whole point of Vzn is to eliminate binding "projects". You
>> just feed it a C header or two and start using the library. If
>> successful, half of common-lisp.net can be eliminated. :)
>>
>> btw, QT rings a bell. I think that might be one of Rayiner's test
>> targets.
>
> I've never used it, but doesn't Qt deviate from standard C++ a lot, with
> its own preprocessor etc.?
Unfortunately, you are right. QT uses a special non-standard 'connections'
with 'SIGNAL' and 'SLOT', ... keywords, so the source code has to be
preprocessed by a qt prog...
Nevertheless, Vzn could help speed up a potential QT-binding-project...
Onay Urfalioglu wrote:
> Unfortunately, you are right. QT uses a special non-standard
> 'connections' with 'SIGNAL' and 'SLOT', ... keywords, so the source
> code has to be preprocessed by a qt prog...
> Nevertheless, Vzn could help speed up a potential
> QT-binding-project...
Note that a hacked "kdoc" had been used in the past by the KDE crowd to
mostly-autogenerate Qt bindings for several languages, AFAIK.
I think that SMOKE is now the umbrella under which such developments
happen - the Perl and Ruby bindings both use SMOKE, apparently:
http://developer.kde.org/language-bindings/smoke/index.html
From page:
"
SMOKE is a introspective wrapper around the Qt and KDE frameworks
The legend says it stands for Scripting Meta Object Kompiler Engine
Not only does it provide wrappers for every function in every class, but
it also contains meta-information allowing queries of what functions
are available and their arguments and return-types.
All classes, all methods, with all arguments, along with various flags
reflecting staticness, virtuality, etc. are stored into
cross-referencing arrays for fast lookups. One can thus read (and call)
the whole Qt API by simply reading/searching these arrays.
The main purpose of SMOKE is to make it possible to write bindings from
scripting languages to Qt and KDE - with an emphasis on ease of use and
flexibility.
You can find out more about SMOKE by checking out the kdebindings module
of KDE's SVN.
At the time of writing, both the Perl bindings and Ruby bindings are
known to use it, you might find valuable usage information there.
"
Onay Urfalioglu <·····@gmx.net> writes:
[...]
> Unfortunately, you are right. QT uses a special non-standard 'connections'
> with 'SIGNAL' and 'SLOT', ... keywords, so the source code has to be
> preprocessed by a qt prog...
> Nevertheless, Vzn could help speed up a potential QT-binding-project...
wxwidgets is presumably another possible target, presumably an
attractive one if it could be achieved.
On 2005-08-11, Bruce Stephens <············@cenderis.demon.co.uk> wrote:
> wxwidgets is presumably another possible target, presumably an
> attractive one if it could be achieved.
Yes, that would be very nice indeed.
Ulrich Hobelmann wrote:
> Kenny Tilton wrote:
>
>>> Sounds great! <dreaming>
>>> Maybe some lispers might start a project for creating QT-bindings
>>> </dreaming>
>>
>>
>> Well, the whole point of Vzn is to eliminate binding "projects". You
>> just feed it a C header or two and start using the library. If
>> successful, half of common-lisp.net can be eliminated. :)
>>
>> btw, QT rings a bell. I think that might be one of Rayiner's test
>> targets.
>
>
> I've never used it, but doesn't Qt deviate from standard C++ a lot, with
> its own preprocessor etc.?
>
I dug up some mail. Yep, Rayiner was leery of the preprocessor and
retargeted to FLTK (but sounded like QT was still something he wanted to
tackle.)
--
Kenny
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"I've wrestled with reality for 35 years, Doctor, and I'm happy to state
I finally won out over it."
Elwood P. Dowd, "Harvey", 1950
·······@gmail.com writes:
>2) To offer robust C++ support through the use of GCC-XML. GCC-XML
>offers us the full power of the GNU C++ parser, and gives the program a
>level of header file compatibility that custom parsers cannot easily
>match.
Does that mean it can only be used with g++, or is g++ only required
for producing the initial interface?
mkb.
Matthias Buelow wrote:
> ·······@gmail.com writes:
>
>
>>2) To offer robust C++ support through the use of GCC-XML. GCC-XML
>>offers us the full power of the GNU C++ parser, and gives the program a
>>level of header file compatibility that custom parsers cannot easily
>>match.
>
>
> Does that mean it can only be used with g++, or is g++ only required
> for producing the initial interface?
Yes. :)
One runs gcc_xml once to produce the bindings. But Rayiner's plans for
runtime C++ (but not C) interaction requires compiler-specific support.
I, Mentor, have encouraged support for VC++ as well as GCC, and Rayiner
was amenable to that, last I heard.
--
Kenny
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"I've wrestled with reality for 35 years, Doctor, and I'm happy to state
I finally won out over it."
Elwood P. Dowd, "Harvey", 1950
Kenny Tilton <·······@nyc.rr.com> writes:
>But Rayiner's plans for
>runtime C++ (but not C) interaction requires compiler-specific
>support.
I guess that's mainly because of C++ name mangling?
mkb.
> I guess that's mainly because of C++ name mangling?
>
Just for reference, though any people who care about such things
probably already know, there was an effort at standardising
a C++-on-linux ABI based [1] on an Itanium defined ABI that
proved more widely applicable. It defines the standard
name mangling for C++ on linux [2]
[1] http://www.gnu.org/software/gcc/gcc-3.2/c++-abi.html
[2] http://www.codesourcery.com/cxx-abi/abi-examples.html#mangling
Effectively, the de-facto standard for C++ linux binary compatibility is
"whatever GCC does, you better be bug-compatible with it". But net
result is your stuff will probably work with intel and portland C++ on
linux as well, though there's a fun "which c++ stdlib am I linking
against" can of worms (see GCC info file, section "compatibility").
David Golden wrote:
> > I guess that's mainly because of C++ name mangling?
>
>
> Just for reference, though any people who care about such things
> probably already know, there was an effort at standardising
> a C++-on-linux ABI based [1] on an Itanium defined ABI that
> proved more widely applicable. It defines the standard
> name mangling for C++ on linux [2]
>
> [1] http://www.gnu.org/software/gcc/gcc-3.2/c++-abi.html
> [2] http://www.codesourcery.com/cxx-abi/abi-examples.html#mangling
>
> Effectively, the de-facto standard for C++ linux binary compatibility is
> "whatever GCC does, you better be bug-compatible with it". But net
> result is your stuff will probably work with intel and portland C++ on
> linux as well, though there's a fun "which c++ stdlib am I linking
> against" can of worms (see GCC info file, section "compatibility").
Thanks for the input. I, Mentor, freely confess to being not up to speed
on the C++ angle. I had been hoping for just autogeneration of C
bindings when rayiner came along with the more ambitious C/C++ proposal.
Interested parties should head for the c-l.net Fetter mailing lists
(where the VZN project is discussed).
--
Kenny
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"I've wrestled with reality for 35 years, Doctor, and I'm happy to state
I finally won out over it."
Elwood P. Dowd, "Harvey", 1950
Kenny Tilton wrote:
> Thanks for the input. I, Mentor, freely confess to being not up to
> speed on the C++ angle.
Heh. Well, having now read the Fetter preliminary design document, I see
the ABI spec I linked to is reference [3] in it anyway... so, as
predicted, those who care about such things did already know it...
David Golden <············@oceanfree.net> writes:
>Just for reference, though any people who care about such things
>probably already know, there was an effort at standardising
>a C++-on-linux ABI based [1] on an Itanium defined ABI that
>proved more widely applicable. It defines the standard
>name mangling for C++ on linux [2]
Well, gcc runs on a whole lot more platforms than just Linux, and it
tends to support the vendor's compiler conventions, at least
to some degree..
mkb.
Matthias Buelow wrote:
> Well, gcc runs on a whole lot more platforms than just Linux, and it
> tends to support the vendor's compiler conventions, at least
> to some degree..
>
Oh certainly, I was just throwing in a vaguely topical link (which
applied to linux and most bsds, AFAIK) - means that on platforms where
gcc IS the closest thing to a "vendor's C++ compiler", there is an
allegedly somwewhat stable ABI for C++ on those platforms.
Matthias Buelow wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> >But Rayiner's plans for
> >runtime C++ (but not C) interaction requires compiler-specific
> >support.
>
> I guess that's mainly because of C++ name mangling?
>
> mkb.
C++ name mangling is taken care of by GCC-XML, which gives you the
mangled name of every symbol. However, any Lisp code that needs to make
a C++ virtual function call needs to know the virtual-table offsets of
each function, and the layout of the virtual tables varies between C++
compilers.
Kenny Tilton <·······@nyc.rr.com> writes:
> One runs gcc_xml once to produce the bindings. But Rayiner's plans for
> runtime C++ (but not C) interaction requires compiler-specific
> support. I, Mentor, have encouraged support for VC++ as well as GCC,
> and Rayiner was amenable to that, last I heard.
Can Verrazzano generate bindings also for plain C libraries?
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools:
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
Paolo Amoroso wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>One runs gcc_xml once to produce the bindings. But Rayiner's plans for
>>runtime C++ (but not C) interaction requires compiler-specific
>>support. I, Mentor, have encouraged support for VC++ as well as GCC,
>>and Rayiner was amenable to that, last I heard.
>
>
> Can Verrazzano generate bindings also for plain C libraries?
Yes.
--
Kenny
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"I've wrestled with reality for 35 years, Doctor, and I'm happy to state
I finally won out over it."
Elwood P. Dowd, "Harvey", 1950
Verrazano can generate bindings for C libraries to the extent that the
C header file is valid C++ code within an extern "C" block. Since most
C libraries have headers designed to by #include-able by C++ code, this
should not be a problem.