> On Sun, Jan 01, 2006 at 11:39:17PM -0000, Andy Hassall wrote: >> >> Under Cygwin there are additional Unicode-related failures. > > Other will have to scratch that itch.
I'd like to scratch, since I've written a Perl+Oracle tool at the office (an Oracle schema documentation tool) that is easier to distribute to other departments using Cygwin than ActiveState Perl because it has quite a few module dependencies that aren't all up-to-date using ActiveState PPM. Although the main one was DBD::Oracle itself, but it seems ActiveState have recently started building that again with their version that also bundles Oracle Instant Client, so ActiveState might again be a feasible option. I'd feel more confident with the Cygwin route if DBD::Oracle Unicode support was 100% under Cygwin in case anyone enters non-ISO-8859-15 data into it (which so far they haven't - but it does use NVARCHAR2 columns just in case). However, realistically I don't think I'll have the time to look into it for this release, since 1.17 seems pretty close to ready. This may be something I can try and help with for 1.18. At the moment I'm not quite sure at which layer to start looking - it's apparently something specific to the Cygwin build of Perl, or a lower-level library within Cygwin on which its Perl is based, as neither the Windows-native nor Linux nor Solaris builds exhibit the problem. The output data in all the failing tests is shorter than the expected result, so it looks like something along the line is translating the data through a character set encoding with a smaller répertoire, such as a single-byte encoding, or it's corrupting it by trying to force it to UTF-8 and failing in some way - but these are just guesses so far - more investigation is clearly needed. -- Andy Hassall :: [EMAIL PROTECTED] :: http://www.andyh.co.uk http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool
