gobo-eiffel-develop — Development discussions

Re: [gobo-eiffel-develop] Next release of Gobo

[Paul C. <pac...@gm...>]

Hi,

On 10/30/07, Eric Bezault <er...@go...> wrote:
> One more question: It is the most recent version of Gobo
> that you are using with ISE 5.6, or an older version?
> If it's an older version, then there is no need to still
> support ISE 5.6. If you intend to use the most recent versions
> of Gobo in your production systems with ISE 5.6, then
> I'll make sure that the new release of Gobo still works
> with ISE 5.6.

We are using currently ISE 5.6 with Gobo 3.4. So you are right. we
could stick with that and later upgrade to ISE 6.1 and Gobo 3.7.

/Paul

Re: [gobo-eiffel-develop] Next release of Gobo

[Eric B. <er...@go...>]

Paul Cohen wrote:
> Hi,
> 
> On 10/26/07, Eric Bezault <er...@go...> wrote:
>> I plan to make a new release to Gobo sometime next week
>> so that it is ready for the release of EiffelStudio 6.1.
>>
>> I know that I've been asking this question many times in
>> the past, but let me ask it again. Does someone still use
>> Gobo with ISE 5.6?
> 
> Yes. We do. And for production systems. I'd very much appreciate if
> you could make sure the new release works with ISE 5.6

One more question: It is the most recent version of Gobo
that you are using with ISE 5.6, or an older version?
If it's an older version, then there is no need to still
support ISE 5.6. If you intend to use the most recent versions
of Gobo in your production systems with ISE 5.6, then
I'll make sure that the new release of Gobo still works
with ISE 5.6.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Next release of Gobo

[Eric B. <er...@go...>]

Paul Cohen wrote:
>> I know that I've been asking this question many times in
>> the past, but let me ask it again. Does someone still use
>> Gobo with ISE 5.6?
> 
> Yes. We do. And for production systems. I'd very much appreciate if
> you could make sure the new release works with ISE 5.6

OK.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Next release of Gobo

[Paul C. <pac...@gm...>]

Hi,

On 10/26/07, Eric Bezault <er...@go...> wrote:
> I plan to make a new release to Gobo sometime next week
> so that it is ready for the release of EiffelStudio 6.1.
>
> I know that I've been asking this question many times in
> the past, but let me ask it again. Does someone still use
> Gobo with ISE 5.6?

Yes. We do. And for production systems. I'd very much appreciate if
you could make sure the new release works with ISE 5.6, though I am
aware it is extra work for you and I understand that at some point in
time you have to stop supporting older compiler versions.

/Paul

Re: [gobo-eiffel-develop] svn:eol-style property not set

[Colin A. <col...@go...>]

I've checked these changes in, along with a large number of others,
but svn has managed to delete at least one of my classes, so it won't
compile now.

I don't know how long it will take me to remember what the code was.

On 23/10/2007, Colin Adams <col...@go...> wrote:
> The problem that I am seeing is that the file character_map6.out also
> needs the same treatment. And I think the qname_results.out too. It
> looks like I have managed to fix the other two,
>
> So this is a reminder to myself to do that this weekend.
>
> On 22/10/2007, Eric Bezault <er...@go...> wrote:
> > Colin Paul Adams wrote:
> > > I am going to have to debug this under windows sometime, to find out
> > > exactly what is happening. I don't want to have to do this on my
> > > laptop - are you intending to refresh Gobo at AXAR soon?
> >
> > Not before the next official release of Gobo. I'd like to have a
> > release of Gobo before the November release of ISE 6.1. Because
> > there is an ECMA meeting around that time, I plan to release Gobo
> > just before, in about 2 weeks.
> >
> > However, you can check-out Gobo on your computer at AXAR if you
> > want. I did it as anonymous with TortoiseSVN and it worked. If
> > you don't have SVN or Tortoise installed, just let me know and
> > I'll check it out for you.
> >
> > --
> > Eric Bezault
> > mailto:er...@go...
> > http://www.gobosoft.com
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems?  Stop.
> > Now Search log events and configuration files using AJAX and a browser.
> > Download your FREE copy of Splunk now >> http://get.splunk.com/
> > _______________________________________________
> > gobo-eiffel-develop mailing list
> > gob...@li...
> > https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
> >
>

[gobo-eiffel-develop] Next release of Gobo

[Eric B. <er...@go...>]

Hello,

I plan to make a new release to Gobo sometime next week
so that it is ready for the release of EiffelStudio 6.1.

I know that I've been asking this question many times in
the past, but let me ask it again. Does someone still use
Gobo with ISE 5.6?

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] svn:eol-style property not set

[Colin A. <col...@go...>]

The problem that I am seeing is that the file character_map6.out also
needs the same treatment. And I think the qname_results.out too. It
looks like I have managed to fix the other two,

So this is a reminder to myself to do that this weekend.

On 22/10/2007, Eric Bezault <er...@go...> wrote:
> Colin Paul Adams wrote:
> > I am going to have to debug this under windows sometime, to find out
> > exactly what is happening. I don't want to have to do this on my
> > laptop - are you intending to refresh Gobo at AXAR soon?
>
> Not before the next official release of Gobo. I'd like to have a
> release of Gobo before the November release of ISE 6.1. Because
> there is an ECMA meeting around that time, I plan to release Gobo
> just before, in about 2 weeks.
>
> However, you can check-out Gobo on your computer at AXAR if you
> want. I did it as anonymous with TortoiseSVN and it worked. If
> you don't have SVN or Tortoise installed, just let me know and
> I'll check it out for you.
>
> --
> Eric Bezault
> mailto:er...@go...
> http://www.gobosoft.com
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> gobo-eiffel-develop mailing list
> gob...@li...
> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
>

Re: [gobo-eiffel-develop] svn:eol-style property not set

[Eric B. <er...@go...>]

Colin Paul Adams wrote:
> I am going to have to debug this under windows sometime, to find out
> exactly what is happening. I don't want to have to do this on my
> laptop - are you intending to refresh Gobo at AXAR soon?

Not before the next official release of Gobo. I'd like to have a
release of Gobo before the November release of ISE 6.1. Because
there is an ECMA meeting around that time, I plan to release Gobo
just before, in about 2 weeks.

However, you can check-out Gobo on your computer at AXAR if you
want. I did it as anonymous with TortoiseSVN and it worked. If
you don't have SVN or Tortoise installed, just let me know and
I'll check it out for you.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] svn:eol-style property not set

[Colin P. A. <co...@co...>]

>>>>> "Eric" == Eric Bezault <er...@go...> writes:

    Eric> Colin Paul Adams wrote:
    >>>>>>> "Colin" == Colin Paul Adams <co...@co...>
    >>>>>>> writes:
    >> 
    >>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
    Eric> col...@us... wrote:
    >> 
> >> gobo/trunk/test/xml/xslt/data/character_map2.out >>>
    >> gobo/trunk/test/xml/xslt/data/character_map4.out
    >> 
    Eric> These files don't have the property svn:eol-style set.
    >> 
    Colin> I don't know what to do about this. I tried making the
    Colin> results verbatim manifest strings. The tests then fail as
    Colin> the embedded CR characters (which show up as ^M in Emacs)
    Colin> are not being read from the verbatim string (using "{ }"
    Colin> delimiters) into the STRING object.  (Eiffel Studio 6.0).
    >> 
    >> I reverted to using the output files for comparing test
    >> results.  I added the svn:needs-lock property to make them
    >> read-only (so you will not be tempted to edit them on Windows -
    >> these are generated output - that is I invoke gexslt on the
    >> test input files, and divert standard output to the file. Then
    >> I inspect the output to check it is correct).
    >> 
    >> I then set the svn:eol-style property to LF, combined with
    >> reading the files as binary files, in a effort to avoid the
    >> different results problem.

    Eric> There is something I don't understand. Neither:

    Eric>   gobo/trunk/test/xml/xslt/data/character_map2.out
    Eric> gobo/trunk/test/xml/xslt/data/character_map4.out

    Eric> have the properties svn:needs-lock and svn:eol-style LF
    Eric> despite what you described above, but now the file:

    Eric>   gobo/trunk/test/xml/xslt/xm_xslt_test_character_map.e

    Eric> has the property svn:eol-style LF. This does not look right
    Eric> to me.

I must have mis-typed the commands, as I now find I am not allowed to
set the *.out files to have LF as the eol-style, as it is inconsistent
with the data.

So instead I set svn:mime-type to application/xml, so subversion
treats them as binary files, which has the desired effect.

Unfortunately the tests still fail under windows.

I am going to have to debug this under windows sometime, to find out
exactly what is happening. I don't want to have to do this on my
laptop - are you intending to refresh Gobo at AXAR soon?
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] AP_OPTIONS - typo

[Bernd S. <ber...@in...>]

Fixed and test-case added.

Thanks for the report,
Bernd

On Fri, 19 Oct 2007 16:01:12 +0200, CRISMER Paul-Georges  =

<Pau...@gr...> wrote:
>
> 	disable_mandatory is
> 			-- Make the option not mandatory.
> 		do
>>>>> 			is_mandatory :=3D True
> 		ensure
> 			not_mandatory: not is_mandatory
> 		end
>
>  is_mandatory should be set to True
>
> Best regards,
>
> Paul G. Crismer

[gobo-eiffel-develop] AP_OPTIONS - typo

[CRISMER Paul-G. <Pau...@gr...>]

	disable_mandatory is
			-- Make the option not mandatory.
		do
>>>>			is_mandatory :=3D True
		ensure
			not_mandatory: not is_mandatory
		end

 is_mandatory should be set to True

Best regards,

Paul G. Crismer

***** Disclaimer *****
http://www.groupes.be/1_mail-disclaimer.htm

Re: [gobo-eiffel-develop] gobo/trunk/example/xml/xslt/serializer/doc.xml

[Colin P. A. <co...@co...>]

    Colin> That makes sense.
    Colin> On 15/10/2007, Eric Bezault <er...@go...> wrote:

    > Added Paths:
    > -----------
    >     gobo/trunk/example/xml/xslt/serializer/doc.xml

    >Since the only purpose of this file is to be used in the
    >test XM_ETEST_SERIALIZER, I would rather move it to:

    >   gobo/test/example/xml/data

I've done this locally. I hope I haven't messed it up (I issued some
incorrect command at first).

I can't check in yet, as I am re-factoring some XSLT code, so I can't
test the example still works.
-- 
Colin Adams
Preston Lancashire

[gobo-eiffel-develop] New serializer for XML

[Colin A. <col...@go...>]

I have completed re-factoring the code for the XSLT 2.0/ XQuery 1.0
serializer, and checked that it passes all the tests from the W3C test
suite.

This serializer can be used without running an XSLT transformation.
There is full (I believe) documentation (as part of the XSLT library
documentation), and an example of feeding the output from
XM_EIFFEL_PARSER direct to the serializer. In a similar way you could
serialize an XM_DOCUMENT.

Re: [gobo-eiffel-develop] EDP -- The Eiffel Developer's Project

[Eric B. <er...@go...>]

Howard Thomson wrote:
> As I thought, the Gobo tools compilation results in a call to gevoid() from 
> the callback from the C glue code, whereas the previously functional 
> compilation was by SmartEiffel which does not do such an analysis.
> 
> I have made available a new executable with that bug fixed ...

I downloaded edp.exe again and I still get a call-on-void-target.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] EDP -- The Eiffel Developer's Project

[Howard T. <how...@di...>]

Hi Lothar,

As I thought, the Gobo tools compilation results in a call to gevoid() from 
the callback from the C glue code, whereas the previously functional 
compilation was by SmartEiffel which does not do such an analysis.

I have made available a new executable with that bug fixed ...

Regards,

Howard

On Sunday 14 October 2007 11:33, Lothar Scholz wrote:
> Hello Howard,
>
> Saturday, October 13, 2007, 10:47:53 PM, you wrote:
>
>
> HT> It is very much alpha status,
>
> Indeed gives an immediately "Call on Void target!".
>
> How i love the smarteiffel stack traces - one reason to never purchase
> Eiffel Studio.

-- 
Howard Thomson

--
"Only two things are infinite, the universe and human stupidity,
and I'm not sure about the former." -- Albert Einstein 

Re: [gobo-eiffel-develop] svn:eol-style property not set

[Colin A. <col...@go...>]

Something went wrong then.
I'll take a look next weekend.

On 15/10/2007, Eric Bezault <er...@go...> wrote:
>
> Colin Paul Adams wrote:
> >>>>>> "Colin" == Colin Paul Adams <co...@co...> writes:
> >
> >>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> >     Eric> col...@us... wrote:
> >
> >     >> gobo/trunk/test/xml/xslt/data/character_map2.out
> >     >>> gobo/trunk/test/xml/xslt/data/character_map4.out
> >
> >     Eric> These files don't have the property svn:eol-style set.
> >
> >     Colin> I don't know what to do about this. I tried making the
> >     Colin> results verbatim manifest strings. The tests then fail as
> >     Colin> the embedded CR characters (which show up as ^M in Emacs)
> >     Colin> are not being read from the verbatim string (using "{ }"
> >     Colin> delimiters) into the STRING object.
> >     Colin> (Eiffel Studio 6.0).
> >
> > I reverted to using the output files for comparing test results.
> > I added the svn:needs-lock property to make them read-only (so you
> > will not be tempted to edit them on Windows - these are generated
> > output - that is I invoke gexslt on the test input files, and divert
> > standard output to the file. Then I inspect the output to check it is
> > correct).
> >
> > I then set the svn:eol-style property to LF, combined with reading the
> > files as binary files, in a effort to avoid the different results
> problem.
>
> There is something I don't understand. Neither:
>
>    gobo/trunk/test/xml/xslt/data/character_map2.out
>    gobo/trunk/test/xml/xslt/data/character_map4.out
>
> have the properties svn:needs-lock and svn:eol-style LF despite what
> you described above, but now the file:
>
>    gobo/trunk/test/xml/xslt/xm_xslt_test_character_map.e
>
> has the property svn:eol-style LF. This does not look right
> to me.
>
> --
> Eric Bezault
> mailto:er...@go...
> http://www.gobosoft.com
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> gobo-eiffel-develop mailing list
> gob...@li...
> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
>

Re: [gobo-eiffel-develop] gobo/trunk/example/xml/xslt/serializer/doc.xml

[Colin A. <col...@go...>]

That makes sense.

On 15/10/2007, Eric Bezault <er...@go...> wrote:
>
> col...@us... wrote:
> > Added Paths:
> > -----------
> >     gobo/trunk/example/xml/xslt/serializer/doc.xml
>
> Since the only purpose of this file is to be used in the
> test XM_ETEST_SERIALIZER, I would rather move it to:
>
>    gobo/test/example/xml/data
>
> --
> Eric Bezault
> mailto:er...@go...
> http://www.gobosoft.com
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> gobo-eiffel-develop mailing list
> gob...@li...
> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
>

[gobo-eiffel-develop] gobo/trunk/example/xml/xslt/serializer/doc.xml

[Eric B. <er...@go...>]

col...@us... wrote:
> Added Paths:
> -----------
>     gobo/trunk/example/xml/xslt/serializer/doc.xml

Since the only purpose of this file is to be used in the
test XM_ETEST_SERIALIZER, I would rather move it to:

   gobo/test/example/xml/data

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] svn:eol-style property not set

[Eric B. <er...@go...>]

Colin Paul Adams wrote:
>>>>>> "Colin" == Colin Paul Adams <co...@co...> writes:
> 
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
>     Eric> col...@us... wrote:
> 
>     >> gobo/trunk/test/xml/xslt/data/character_map2.out
>     >>> gobo/trunk/test/xml/xslt/data/character_map4.out
> 
>     Eric> These files don't have the property svn:eol-style set.
> 
>     Colin> I don't know what to do about this. I tried making the
>     Colin> results verbatim manifest strings. The tests then fail as
>     Colin> the embedded CR characters (which show up as ^M in Emacs)
>     Colin> are not being read from the verbatim string (using "{ }"
>     Colin> delimiters) into the STRING object.
>     Colin> (Eiffel Studio 6.0).
> 
> I reverted to using the output files for comparing test results.
> I added the svn:needs-lock property to make them read-only (so you
> will not be tempted to edit them on Windows - these are generated
> output - that is I invoke gexslt on the test input files, and divert
> standard output to the file. Then I inspect the output to check it is
> correct).
> 
> I then set the svn:eol-style property to LF, combined with reading the
> files as binary files, in a effort to avoid the different results problem.

There is something I don't understand. Neither:

   gobo/trunk/test/xml/xslt/data/character_map2.out
   gobo/trunk/test/xml/xslt/data/character_map4.out

have the properties svn:needs-lock and svn:eol-style LF despite what
you described above, but now the file:

   gobo/trunk/test/xml/xslt/xm_xslt_test_character_map.e

has the property svn:eol-style LF. This does not look right
to me.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] EDP -- The Eiffel Developer's Project

[Howard T. <how...@di...>]

Hi Lothar,

You don't say whether you tried the Linux version or the Win32 version ?

The Win32 version uses a lot more C glue code, and the Gobo tools need some 
persuading (i.e. kludges) to establish the correct type-set returned from an 
external "C" call. I have also made some changes to the interface between 
Eiffel and C since it (the Win32 version) was last working ...

I have'nt had a crash on the Linux version for quite a while (months).

Regards,

Howard

On Sunday 14 October 2007 11:33, Lothar Scholz wrote:
> Hello Howard,
>
> Saturday, October 13, 2007, 10:47:53 PM, you wrote:
>
>
> HT> It is very much alpha status,
>
> Indeed gives an immediately "Call on Void target!".
>
> How i love the smarteiffel stack traces - one reason to never purchase
> Eiffel Studio.

-- 
Howard Thomson

--
"Only two things are infinite, the universe and human stupidity,
and I'm not sure about the former." -- Albert Einstein 

Re: [gobo-eiffel-develop] EDP -- The Eiffel Developer's Project

[Lothar S. <ll...@we...>]

Hello Howard,

Saturday, October 13, 2007, 10:47:53 PM, you wrote:


HT> It is very much alpha status,

Indeed gives an immediately "Call on Void target!".

How i love the smarteiffel stack traces - one reason to never purchase
Eiffel Studio.

-- 
Best regards,
 Lothar                            mailto:ll...@we...

Re: [gobo-eiffel-develop] UTF-8 strings changing to Latin-1 strings

[Colin A. <col...@go...>]

The solution I have adopted is to change the signatures for
as/to_nfc/nfd/nfkc/nfkd to return a UC_UTF8_STRING, even in the case of
Latin-1 strings which were already in the requested normalized forms.

Re: [gobo-eiffel-develop] EDP -- The Eiffel Developer's Project

[Howard T. <how...@di...>]

Hi Colin,

Yes, that is a deficiency, which I will be fixing in the near future ...

Howard

On Saturday 13 October 2007 17:14, you wrote:
> I just tried the Linux executable, and I get:
>
> Xlib: connection to ":0.0" refused by server
> Xlib: Invalid MIT-MAGIC-COOKIE-1 key
> Exception no 11
> Printing ge_stack ...
> gestack_ptr = bf9d4184
>    Current->id = 78
> gestack_ptr = bf9d41cc
>    Current->id = 78
> gestack_ptr = bf9d420c
>    Current->id = 21
> gestack_ptr = bf9d425c
>    Current->id = 21
> gestack_ptr = bf9d42b4
>    Current->id = 21
> gestack_ptr = bf9d42e8
>    Current->id = 21
>
> The DISPLAY environment variable is set to :1.0 here - looks like it is
> ignoring it for some reason.

-- 
Howard Thomson

--
"Only two things are infinite, the universe and human stupidity,
and I'm not sure about the former." -- Albert Einstein 

Re: [gobo-eiffel-develop] EDP -- The Eiffel Developer's Project

[Colin A. <col...@go...>]

I just tried the Linux executable, and I get:

Xlib: connection to ":0.0" refused by server
Xlib: Invalid MIT-MAGIC-COOKIE-1 key
Exception no 11
Printing ge_stack ...
gestack_ptr = bf9d4184
   Current->id = 78
gestack_ptr = bf9d41cc
   Current->id = 78
gestack_ptr = bf9d420c
   Current->id = 21
gestack_ptr = bf9d425c
   Current->id = 21
gestack_ptr = bf9d42b4
   Current->id = 21
gestack_ptr = bf9d42e8
   Current->id = 21

The DISPLAY environment variable is set to :1.0 here - looks like it is
ignoring it for some reason.

[gobo-eiffel-develop] UTF-8 strings changing to Latin-1 strings

[Colin P. A. <co...@co...>]

I have just worked out the problem with an interesting bug in the XSLT
library.

The problem occurs with the following transformation:

<?xml version="1.0"?> 
<xsl:transform xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" version="2.0">

<xsl:output method="xhtml" indent="no" encoding="UTF-8" normalization-form="NFC"/>

<xsl:template match="/">
  <html>
        <body>&#x41;&#x301;</body>
  </html>
</xsl:template>

</xsl:transform>

The code-point sequence x41,x301 consists of the characters A followed
by combining acute accent. This is represent internally within thw
XSLT engine as a UC_UTF8_STRING of 3 bytes, (count = 2).

The request to normalize to normalization form NFC converts this
sequence to a single composed character, an A with an acute accent.

The process by which this is done finishes with a single INTEGER which
is then converted to a STRING using
{UC_UNICODE_ROUTINES}.code_to_string.

But this routine returns a Latin-1 STRING (not a UC_UTF8_STRING), when
the code is small enough.

But the actually process of encoding the string for writing to a file
is expecting UC_UTF8_STRINGs. Since in this case the requested output
is UTF-8, class XM_XSLT_UTF8_ENCODER passes the STRING through
unchanged to the XM_OUTPUT object for efficiency.

There are several ways I can fix this bug.

One is to change the XM_XSLT_UTF8_ENCODER (and other encoders) so that
they test the dynamic type of STRING and convert as necessary.

Another is to change the Unicode normalization routines to always
create UC_UTF8_STRINGs either by writing a variant on
{UC_UNICODE_ROUTINES}.code_to_string, or changing it so as to always
produce UC_UTF8_STRINGs.

But I can think of other possibilities. What if the input string is a
STRING_32? I think that I would want to see STRING_32 output in that
case, so neither UC_UTF8_STRING or plain Latin-1 STRING_8 would be
very acceptable.

So my instinct is to change the normalization routines so
that the dynamic type of the input string is preserved. This will work
for NFC and NFKC (composition), but it won't work for NFD or NFKD, as
given non-ASCII Latin-1 input, they will produce codes beyond 255.

Also, the routines as_nfc and as_nfd (as opposed to to_nfc and to_nfd)
return (by design) the input object if it is already in the desired
normalization form. So a solution that always produced UC_UTF8_STRING
when given ASCII or Latin-1 STRING input is undesirable.

All opinions welcome.
-- 
Colin Adams
Preston Lancashire