"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:cgcv4n$2fsf$1@digitaldaemon.com...
> Following Ben's mention of ICU, I've been checking out what it does and
doesn't
> do. Basically, it does EVERYTHING. There is the work of years there. Not
just
> Unicode stuff, but a whole swathe of classes for internationalization and transcoding. It would take me a very long time to duplicate that. It's
also
> free, open source, and with a license which basically says there's no
problem
> with our using it.
>
> So I'm thinking seriously about ditching the whole etc.unicode project and replacing it with a wrapper around ICU.
>
> It's not completely straightforward. ICU is written in C++ (not C), and so
we
> can't link against it directly. It uses classes, not raw functions. So,
I'd have
> to write a C wrapper around ICU which gave me a C interface, and /then/
I'd have
> to write a D wrapper to call the C wrapper - at which point we could get
the
> classes back again (and our own choice of architecture, so plugging into
std or
> mango streams won't suffer).
>
> But the outermost (D) wrapper can, at least, be composed of D classes.
>
> If we want D to be the language of choice for Unicode, we would need all
this
> functionality. So, if we went the ICU route, we'd need to bundle ICU
(currently
> a ten megabyte zip file) with DMD, along with whatever wrapper I come up
with.
> (etc.unicode is not likely to be smaller).
>
> I'd like to see some discussion on this. Read this page to inform
yourself:
> http://oss.software.ibm.com/icu/userguide/index.html

It sounds pretty cool. It being a very large library, is only what you use linked in? Or does using anything tend to pull in the whole shebang? I hope it's the former!

In article <cghofr$202k$3@digitaldaemon.com>, Walter says...

>It sounds pretty cool. It being a very large library, is only what you use linked in? Or does using anything tend to pull in the whole shebang? I hope it's the former!

No idea (yet). I worried about that myself, but it's a library not an indivisibile object file, so it must have /some/ granularity.

But the functionality of ICU goes way beyond what I was even planning to achieve - there's even stuff for font rendering in there for feck's sake! (Unicode allows you to put any accent over any glyph, ligate any two glyphs into one, etc. Font rendering engines have a fair bit of work to do). So ICU is hard to beat. Therefore, I'm inclining to the view that we'd be better off trying to plumb ICU into D than to reject it because it fails to meet any one single D requirement.

So, if it won't split into sufficiently small chunks on linking, I'd say that was as good an argument as any for improving D's DLL support. ICU would clearly be an excellent candidate for a DLL (assuming we can have classes in DLLs).

Jill

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:cghrn3$21dg$1@digitaldaemon.com...
> In article <cghofr$202k$3@digitaldaemon.com>, Walter says...
>
> >It sounds pretty cool. It being a very large library, is only what you
use
> >linked in? Or does using anything tend to pull in the whole shebang? I
hope
> >it's the former!
>
> No idea (yet). I worried about that myself, but it's a library not an indivisibile object file, so it must have /some/ granularity.
>
> But the functionality of ICU goes way beyond what I was even planning to
achieve
> - there's even stuff for font rendering in there for feck's sake! (Unicode allows you to put any accent over any glyph, ligate any two glyphs into
one,
> etc. Font rendering engines have a fair bit of work to do). So ICU is hard
to
> beat. Therefore, I'm inclining to the view that we'd be better off trying
to
> plumb ICU into D than to reject it because it fails to meet any one single
D
> requirement.
>
> So, if it won't split into sufficiently small chunks on linking, I'd say
that
> was as good an argument as any for improving D's DLL support. ICU would
clearly
> be an excellent candidate for a DLL (assuming we can have classes in
DLLs).

The ICU has a C API, you want to port the C++ API to D, why not
compile a DLL with the C API, and a lib with the ported D API?
This would also be good for minimum disturbance between the ICU source
and the D API.

Roald

In article <cgi7f6$25qf$1@digitaldaemon.com>, Roald Ribe says...

>The ICU has a C API, you want to port the C++ API to D, why not
>compile a DLL with the C API, and a lib with the ported D API?
>This would also be good for minimum disturbance between the ICU source
>and the D API.

This is possibly the best idea yet, but I'm going to have to study the ICU source before I know how feasible that is.

Some fundamentals:
(1) ICU's C API requires you to acquire and release (memory) resources. D
programmers are accustomed to letting the garbage collector do the releasing.
(2) ICU's C++ API requires classes to have a copy constructor and an assignment
operator. This isn't possible with D.

The above two points mean that the D API is probably going to look more like the Java API than the C++ API. Exactly how much of it can be done via a wrapper around C I'm not sure (yet).

But yes - if the C-based core can be put into a DLL, and a D-API built which calls it, I guess that would work a treat.

Arcane Jill

In article <cgi8jj$26dr$1@digitaldaemon.com>, Arcane Jill says...
>
>Some fundamentals:
>(1) ICU's C API requires you to acquire and release (memory) resources. D
>programmers are accustomed to letting the garbage collector do the releasing.
>(2) ICU's C++ API requires classes to have a copy constructor and an assignment
>operator. This isn't possible with D.

What are those two operators used for?  Could the functionality be worked around somehow?


Sean

In article <cgifct$29kf$1@digitaldaemon.com>, Sean Kelly says...
>
>In article <cgi8jj$26dr$1@digitaldaemon.com>, Arcane Jill says...
>>
>>Some fundamentals:
>>(1) ICU's C API requires you to acquire and release (memory) resources. D
>>programmers are accustomed to letting the garbage collector do the releasing.
>>(2) ICU's C++ API requires classes to have a copy constructor and an assignment
>>operator. This isn't possible with D.
>
>What are those two operators used for?  Could the functionality be worked around somehow?

I'm sure it can be worked around, as there is a Java interface to ICU already
available.  ( http://oss.software.ibm.com/icu4j/download/ ) ;)

This table ( http://oss.software.ibm.com/icu4j/comparison/index.html ) is about as close an indicator as we're going to get for what D would need to do to compete with what's already out there.

-Pragma
[[ EricAnderton at (code it, and they will come) yahoo.com ]]

In article <cgifct$29kf$1@digitaldaemon.com>, Sean Kelly says...
>
>In article <cgi8jj$26dr$1@digitaldaemon.com>, Arcane Jill says...
>>
>>Some fundamentals:
>>(1) ICU's C API requires you to acquire and release (memory) resources. D
>>programmers are accustomed to letting the garbage collector do the releasing.
>>(2) ICU's C++ API requires classes to have a copy constructor and an assignment
>>operator. This isn't possible with D.
>
>What are those two operators used for?

I don't know. I'm still looking into it all. Fortunately, I don't think it matters.


>Could the functionality be worked around somehow?

Obviously yes, since there is a Java API.

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:cgihb5$2aub$1@digitaldaemon.com...
> In article <cgifct$29kf$1@digitaldaemon.com>, Sean Kelly says...
> >
> >In article <cgi8jj$26dr$1@digitaldaemon.com>, Arcane Jill says...
> >>
> >>Some fundamentals:
> >>(1) ICU's C API requires you to acquire and release (memory) resources.
D
> >>programmers are accustomed to letting the garbage collector do the
releasing.
> >>(2) ICU's C++ API requires classes to have a copy constructor and an
assignment
> >>operator. This isn't possible with D.
> >
> >What are those two operators used for?
>
> I don't know. I'm still looking into it all. Fortunately, I don't think it matters.
>
>
> >Could the functionality be worked around somehow?
>
> Obviously yes, since there is a Java API.

The Java API would likely be the best starting point. IBM is no slouch in its support of Java, and the Java interface will have solved the issues with interfacing to a GC language.