Re: The 0.5 Release of Sapphire Is Available

Simon Cozens <[email protected]> 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
> libraries.
> 
> http://perlhacker.org/~simon/sapphire-0.5.tar.gz

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.

Best
-John

>    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
> ADSM.
>     - Graham Reed, sdm.
> 
> 

-- 
John Tobey, late nite hacker <[email protected]>
\\\                                                               ///
]]]             With enough bugs, all eyes are shallow.           [[[
///                                                               \\\