perlsgml-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Perlsgml-dev] [FYI/RFC] SGML::Parser::OpenSP and SGML::Parser...


From: Terje Bless
Subject: Re: [Perlsgml-dev] [FYI/RFC] SGML::Parser::OpenSP and SGML::Parser...
Date: Mon, 7 Apr 2003 11:09:38 +0200

Yann Dirson <address@hidden> wrote:

>On Mon, Apr 07, 2003 at 10:14:57AM +0200, Terje Bless wrote:
>>Heh! Therein lies some of the problem; the code is about as far from
>>structured as you could imagine. This project was started partially so
>>I could learn C++ and XS; I started out with pretty much zero knowledge
>>of either, or even of plain C. The code looks pretty much as you'd
>>expect from that.
>
>Have you looked at SWIG[1] to create bindings ?  It really avoids diving
>into XS specificities, and additionally allows to create bindings for
>other languages (python, java, guile, ...).

Well, SWIG looked to require the learning of Yet Another Meta-Syntax (for
the *.i files) while still requiring me to learn C++, and produce
non-optimal code out. I decided it was better to do this in XS, which gives
me a chance to learn it and C++ which has wider applicability and,
presumably, is more widespread so is more likely to generate contributions
from users.


>>Also, the "generic" API to OpenSP is rather limited -- I'm not sure yet
>>whether it can even get close to match what SGML::Parser provides
>>today! -- and I don't even implement "bindings" to it, just some
>>functions that happen to /use/ that API.
>
>Maybe openjade's libospgrove would be closer to what you need than
>libosp ?

Possibly. I wrote the first version of this module in a fit of inspiration
based on some code from Nick Kew that used the generic API to libosp. I
haven't found any docs for libospgrove anywhere; is it part of OpenSP or is
it in OpenJade? Would it require me to wrap my brane around "Groves" or
would a vague idea of what a "grove" is suffice? :-)


>>[0] - OpenSP uses ca. 1996-era C++ and it shows; all datatypes are
>>internal hacks instead of using the STL. Strings are "unsigned char*",
>>attribute values are returned as chunked "CharString*s" etc. Even I can
>>see that this stuff is _crufty_!
>
>Well, many people would love to see someone volunteering to cleanup all
>of this :)

Yeah, the thought had occurred to me, but it's quite too ambitious a
project for me to tackle (at least alone). I've been meaning to investigate
how far I can get with just replacing CharString*s with std::wstrings but I
feel nowhere near confident enough to make a serious attempt at this. Not
only because I have very limited knowledge of C++, but also because I'm
having big problems understanding all the ways OpenSP uses strings
internally (e.g. in view of BCTF and internal wide character support and
character encoding/repertoire handling).

IMO the most valuable contribution to the OpenSP project would be
commenting (copiously!) all the userland executables (onsgmls, spam, etc.)
as a first cut at documenting the native API to libosp; closely followed by
copiously commenting the source implementing the library itself.

I couldn't navigate the OpenSP source if my life depended on it! :-(




BTW, the last test version I released to my one tester (Nick Kew) is at
<http://mail.tj.unn.no/SGML-Parser-OpenSP-0.16.tar.gz>. It's not quite
current and as mentioned there is a plethora of caveats attached to it.

-- 
Now Playing "Work Song" by "Nina Simone"",
 from the album "Feeling Good - The Very Best Of".




reply via email to

[Prev in Thread] Current Thread [Next in Thread]