[kris]

Update: Mango.icu now requires ICU v3.2 libraries

Mango has a set of bindings to the extensive ICU project at http://www-306.ibm.com/software/globalization/icu/started.jsp. This effort does not have any reliance whatsoever on other Mango classes, so could easily live elsewhere (mango.icu is just a convenient place to host the files for now).

Currently included:
Character classification
Conversion to and from UTF16, via all the supported transcoders
Preliminary Locale support
Number formatting, and parsing
Resource bundles
UnicodeString class
Message formatting
Numeric spellout
Calendars
Date & time formatting, and parsing
Preliminary time zone support
Character properties
String searching
Text-boundary analysis
Transliteration (with issues)
Normalization
StringPrep
International domain names
Collation
Unicode Set
Regular Expressions

Under way:
(none)

To do:
Character Iteration
Bidi text
Arabic shaping
Universal Timescale (ICU 3.2)


It would be great if some of you good folks have an interest in working on these, since many can be wrapped in isolation (given a few basic classes).

The 'adoption' itself is actually quite mechanical:

1) take a look at the C code and headers, and decide whether to wrap the functionality or expose it directly. Many C functions will be wrapped individually; however, character classification (for example) forgoes the notion of individual wrappers. It's useful to look at the C++ classes to get some ideas too.

2) setup a bunch of class members to hold a pointer to the relevant C function. These are effectively function pointers, and are necessary to support using the ICU dll's on windows (due to the lib format mismatches)

3) for Win32, provide a set of static mappings for a dll-method-loader to bind the appropriate dll methods. For linux, provide a different set of static mappings for a shared-lib loader to munge.

You don't need to wholly understand any of the ICU library to do this, so it's not a huge learning curve. It's perfectly reasonable to take a stab at any particular area, and expose only the ICU methods that appear to be most useful

Testing would also be a great asset! Anyone up for that? Some ongoing compilations by someone with a linux box would also be really helpful ...

Lastly, I will be updating these lists to reflect progress.

[kris]

Thinking about this some more, it should probably be completely isolated from Mango from the start ~ I'll ask Brad to create a new project for it.

[teqdruid]

I though AJ was working on this project? Although I don't believe we've heard from her lately...

[kris]

I thought so too. Have tried a number of times to contact her regarding progress over the last couple of months (after we had some initial discussions), but there's been no response. Others have apparently tried also, with a similar result. Sometimes people just move on to different things.

I don't much care for letting time slip away, so picked this one up myself. Some help would be very much appreciated though! And, if AJ still has interest in this arena, it would be great to collaborate.

[JJR]

[JJR]

One other question...

This project appears more of a ICU "interface" than an ICU "port." Do you think it would be possible to create an actual D port of ICU or would that amount to being a gargantuan project?

For example, perhaps many of the ICU C functions and types could be rapidly ported to D or remodeled as D class members.

This would cut down on a lot of the C++ baggage that the current dll's or so's are carrying. Of course, if there already are ready-made libraries that are practically bug free, maybe such an effort would be totally pointless.

[kris]

[kris]

[JJR]

Kris,

Thanks for all the info. We can continue this via email. I've done an svn update on my system for mango, so I now see your D ICU files.

I'll look at how you've got it structured.

Looks like Mango could grow into quite the swiss army knife. Good show!

I'm still waiting to get my Linux up and running, but I should have it working next week. I've got a bit of fiddling to do with Derelict also.

- John

[JJR]

[JJR]

Ha ha.... I guess I must have been a little off.... Looks like a "Monty Python" quip.

Just a little off...

[kris]

[kris]

Checked-in these two wrappers:

Number formatting and parsing
Resource bundles

Also changed the design a bit, which noticably cleaned up some code and will make it simpler to hook up the shared-libs on a linux platform. The ULocale module was reworked, and is now a struct instead of a class.

Tomorrow should see MessageFormat and a bit of Calendar done ...

[kris]

Split part of UString into UText, for immutable references. Added read-only support to UString, so it'll operate faster in many cases. Also added toHash(), opCmp() and friends, along with remove() and extract() methods.

The UResourceBundle now returns immutable UText objects.

[kris]

UMessageFormat is checked-in. I ran into a problem with this one, where the module-dtor was being invoked before all object-dtors had been invoked. The result was a method being called in a DLL that had already been unloaded.

For now, I've disabled all library unloads for this package. Win32 seems to handle the refcount appropriately anyway (even for explicitly loaded DLLs) so perhaps it's not really an issue. What's of more concern is the complete lack or order inherent in the D dtor design ...

Also reorganized some methods in UString to make them more uniform and more helpful for other modules which format content into them.