[ic] Call for testers

Gert van der Spoel gert at 3edge.com
Sat Jun 20 23:58:06 UTC 2009


> -----Original Message-----
> From: interchange-users-bounces at icdevgroup.org [mailto:interchange-
> users-bounces at icdevgroup.org] On Behalf Of David Christensen
> Sent: Thursday, June 18, 2009 3:41 PM
> To: interchange-users at icdevgroup.org
> Subject: Re: [ic] Call for testers
> 
> 
> On Jun 17, 2009, at 3:47 PM, Gert van der Spoel wrote:
> 
> >> -----Original Message-----
> >> From: interchange-users-bounces at icdevgroup.org [mailto:interchange-
> >> users-bounces at icdevgroup.org] On Behalf Of David Christensen
> >> Sent: Wednesday, April 29, 2009 5:27 PM
> >> To: interchange-users at icdevgroup.org
> >> Subject: Re: [ic] Call for testers
> >>
> >>
> >> On Apr 29, 2009, at 8:18 AM, Jon Jensen wrote:
> >>
> >>> On Wed, 29 Apr 2009, Stefan Hornburg (Racke) wrote:
> >>>
> >>>> The most recent change bails out with:
> >>>>
> >>>> Unrecognized/unsupported MV_HTTP_CHARSET: 'utf-8'.
> >>>> ulisses config error: Unrecognized/unsupported MV_HTTP_CHARSET:
> >>>> 'utf-8'.
> >>>>
> >>>> Any idea why?
> >>>
> >>> Wild guess, but have you tried "utf8" instead of "utf-8"? They're
> >>> not the
> >>> same in Perl. But if you were using "utf-8" before and it worked, I
> >>> don't
> >>> know.
> >>
> >>
> >> No, this definitely is a regression.  I suspect this may be due to
> >> the
> >> Global::UTF8 variable logic introduced when I merged upstream CVS,
> >> but
> >> I'll have to hunt it down to be sure.  Either utf-8 or utf8 are
> >> acceptable here, one gets resolved to "strict" utf8, but both are
> >> valid.  (And any aliasable encoding works here; this message is what
> >> appears when we can't resolve the alias.  (An artifact of require/
> >> import vs use, perhaps?)
> >
> > I have the following variables in my catalog.cfg:
> > Variable MV_HTTP_CHARSET UTF-8
> > Variable MV_UTF8 1
> 
> [snip]
> 
> > Anyway patch attached, no thoroughly tested today .. tomorrow is
> > another
> > day.
> > In the patch also a no strict subs ... but that one I am not sure if
> > that is
> > the cure or removing symptoms ...
> 
> 
> Gert,
> 
> Thanks for the patch and explanation; I've made a few minor changes
> (basically handle the case that find_encoding() fails), and applied to
> my repo, giving you the authorship credit.

Thanks David .. That seems to do the trick ... 

I have been looking at the GDBM problems and have been able to solve them in
my particular case
 ... I only am not able to rationalize the changes, which is annoying hehe..


The patches regarding GDBM are :
Common.pm.patch  (lib/Vend/Table/Common.pm)
GDBM.pm.patch    (lib/Vend/Table/GDBM.pm)

For the Util.pm.patch, I'm not sure if that is needed, but I think with each
File IO you should be setting the utf8 flag when in utf8 modus, right?

What I am not sure about/don't like is that the .structure file shows text
that should be properly displayed as UTF8 in my xterm as:
\x{3bc}\x{3ad}\x{3b8}\x{3bf}\x{3b4}\x{3bf}\x{3c2}
\x{3b1}\x{3c0}\x{3bf}\x{3c3}\x{3c4}\x{3bf}\x{3bb}\x{3ae}\x{3c2}  etc ...

When I fiddle with some lines with regard to the apply UTF8 filter stuff
etc, I am able to make the .structure file to show normal text, but then it
does not anymore in the page ... 

Before I go totally nuts, I hope someone else can shed some light on this
... It has been fun ping-ponging through the code again :)

Frederic, did you ever get things sorted? 
I remember you were having particular issues with GDBM .. Perhaps the above
will also work in your case.

CU,

Gert















-------------- next part --------------
A non-text attachment was scrubbed...
Name: Util.pm.patch
Type: application/octet-stream
Size: 426 bytes
Desc: not available
Url : http://www.icdevgroup.org/pipermail/interchange-users/attachments/20090621/226628b0/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GDBM.pm.patch
Type: application/octet-stream
Size: 444 bytes
Desc: not available
Url : http://www.icdevgroup.org/pipermail/interchange-users/attachments/20090621/226628b0/attachment-0001.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Common.pm.patch
Type: application/octet-stream
Size: 620 bytes
Desc: not available
Url : http://www.icdevgroup.org/pipermail/interchange-users/attachments/20090621/226628b0/attachment-0002.obj 


More information about the interchange-users mailing list