Front page | perl.bootstrap |
Postings from July 2000
Re: The 0.5 Release of Sapphire Is Available
From: John Tobey
July 29, 2000 12:34
Re: The 0.5 Release of Sapphire Is Available
Message ID: m13IbGs-000FOJC@feynman.localnet
Simon Cozens <email@example.com> wrote:
> I said I'd announce what I'd be hacking on on Friday, and this is it.
> This is the last I will say on the subject of Glib or other external
I would like to explore the idea of porting (a subset of) Pickle to
Sapphire. I describe Pickle as "a C++ interface to the Perl language
with a Perl 5 backend". Pickle 0.5 is at
http://search.cpan.org/search?dist=pickle - but in the week since I
uploaded it, its internals have changed almost beyond recognition.
(I'm moving away from perlapi and towards direct pp function calls.)
My intent for Pickle is to replace the perlguts/XS/perlembed APIs as
the standard interface between perl and external C/C++ code. Pickle's
advantages are vastly improved ease of use and the potential for
binary compatibility across Perl configurations and implementations.
I am kinda hoping to get it into the 5.8 distribution, since it could
provide a nice upgrade path to Perl 6.
> I wasn't able to hack on this as much as I wanted to over the past few days,
> with the result that a few features that I wanted in there have not been
> implemented yet. But, however, the 0.5 release of Sapphire is available.
> OK, but what on earth is Sapphire?
> It's important first of all to note what Sapphire is not. Sapphire is
> emphatically NOT an attempt at Perl 6. Perl 6 will, hopefully, have a very
> different architecture internally. With Sapphire, I have very deliberately
> tried not to break any new ground at all. This is purely a proof-of-concept.
> Sapphire is an implementation of the Perl 5 API using the Glib
> library. I gave myself one week to see how far I could get, and to be
> honest I didn't get as far as I liked. The following things are in:
> * SVs, including conversion between PV/IV/NV
> * AVs are defined in terms of g_pointer_array
> * glib version 1.3, if you have it, will give you UTF8 support to
> the level of Perl 5.6.0
> I wanted to put hashes in there, but did not have the time. The SV/AV
> stuff is separated out into libsvar - I sincerely hope that Perl 6
> will take an extremely modular approach to internals design in the
> same way as I have done here. This has allowed me to create a C test
> suite test.c for the scalar/array library, completely distinct from
> the rest of the API implementation. Since I've renamed a bunch of
> internal functions, test_compat.c tests the compatibility interface to
> the real Perl 5 API; this is another area in which I hope Perl 6 will
> draw from Sapphire - breaking internal APIs is always avoidable while
> wrapper functions and macros exist.
> You'll notice that libre is empty. This is because glib 2.0 is aiming
> to provide a complete Unicode-aware Perl-compatible regular expression
> engine. To implement this, I need do precisely nothing.
> In some places, Perl 5.6.0 is ahead of glib 1.3.0's Unicode support.
> I'll be fixing that by contributing patches to glib to allow
> character-level manipulation.
> Another cool design feature to note is inline.pl. It's a very tortuous
> piece of code, but what it does is transform inline functions into
> macros. The idea is that you may then compile the code as macros
> normally, or compile with -DEXPAND and have them expanded into inline
> functions. This should give you debugging benefits without eliminating
> any performance worries. Also, compiling with -DEXPAND can check for
> syntax errors that compilation with macros can't; it means you can't
> have lvalue macros, but that's a disgustingly confusing thing anyway,
> so who cares?
> It should be stressed that Sapphire doesn't do much. It's a proof of
> concept, and proud of it. It's proving the usefulness of a modular
> design. It's proving the usefulness of using existing libraries
> instead of living in a vacuum. It's proving that glib rocks my world.
> What am I going to do with Sapphire now? To implement the entire API,
> I'd have to have a working Perl interpreter, which is not a small
> challenge. Well, I may hack on it some more now for fun, but I'm not
> sure what the point would be. It would teach me more about the Perl 5
> internals, but they're about to go away. It would teach me more about
> glib, which is certainly useful.
> But the main point is, it's a proof of concept. It took me one week to
> get to somewhere around the point that Topaz was at after two years. And
> that's because I didn't try and reinvent every single wheel. There's good
> software out there, folks. Let's use it.
> SM is fun. ADSM is not.
> "Safe, Sane, Consensual"... three words that cannot used to describe
> - Graham Reed, sdm.
John Tobey, late nite hacker <firstname.lastname@example.org>
]]] With enough bugs, all eyes are shallow. [[[