and again... encoding

Since a few weeks I experience problems while using the find... -> selector option in GemTools. I get an DNU

DoubleByteSymbol>>#isValidSelector

in ClassOrganizer>>#findMethodNamesMatching:

But I'm sure I didn't try to force a method name including non-ascii characters. So I don't know where it comes from. What is worth a ticket in the bug tracker will be the handling of unicode method names.

Norbert

Norbert Hartl wrote: Norbert,

Yes please submit an issue and include the specifics to reproduce the
problem ... I am certain that there are a number of issues out there
waiting to bite us when it comes to multi-byte characters and code ...

Monticello is not (yet) designed to deal correctly with multi-byte
characters (that's the source of WideStrings in GemStone). See glassdb
Issue 145 (http://code.google.com/p/glassdb/issues/detail?id=145) and
Pharo Issue 2697 (http://code.google.com/p/pharo/issues/detail?id=2697),
so it's a bit dicey using multi-byte characters in your code, especially
if you intend to share the code between Pharo and GemStone...

I talked to Henrik Johanssen at ESUG. He and Bert Freudenberg were
looking at modifying Monticello so that it would use UTF8 encoded
strings, which are critical to avoiding "corruption" in mcz files.

Dale

On 23.09.2010, at 20:14, Dale Henrichs wrote:

> Norbert Hartl wrote:
>> Since a few weeks I experience problems while using the find... -> selector option in GemTools. I get an DNU
>> DoubleByteSymbol>>#isValidSelector
>> in ClassOrganizer>>#findMethodNamesMatching: But I'm sure I didn't try to force a method name including non-ascii characters. So I don't know where it comes from. What is worth a ticket in the bug tracker will be the handling of unicode method names. Norbert
> Norbert,
>
> Yes please submit an issue and include the specifics to reproduce the problem ... I am certain that there are a number of issues out there waiting to bite us when it comes to multi-byte characters and code ...
>
Ah, ok, somehow I thought only you can submit issues :)

> Monticello is not (yet) designed to deal correctly with multi-byte characters (that's the source of WideStrings in GemStone). See glassdb Issue 145 (http://code.google.com/p/glassdb/issues/detail?id=145) and Pharo Issue 2697 (http://code.google.com/p/pharo/issues/detail?id=2697), so it's a bit dicey using multi-byte characters in your code, especially if you intend to share the code between Pharo and GemStone...
>
> I talked to Henrik Johanssen at ESUG. He and Bert Freudenberg were looking at modifying Monticello so that it would use UTF8 encoded strings, which are critical to avoiding "corruption" in mcz files.

I talked to him, too. There is even a practical solution to this. Although it will break backward compatibility for package containing non-ascii stuff. But these are rare.

Norbert

Norbert Hartl wrote:
I'm hoping that everyone can submit issues:)

>
>> Monticello is not (yet) designed to deal correctly with multi-byte characters (that's the source of WideStrings in GemStone). See glassdb Issue 145 (http://code.google.com/p/glassdb/issues/detail?id=145) and Pharo Issue 2697 (http://code.google.com/p/pharo/issues/detail?id=2697), so it's a bit dicey using multi-byte characters in your code, especially if you intend to share the code between Pharo and GemStone...
>>
>> I talked to Henrik Johanssen at ESUG. He and Bert Freudenberg were looking at modifying Monticello so that it would use UTF8 encoded strings, which are critical to avoiding "corruption" in mcz files.
>
> I talked to him, too. There is even a practical solution to this. Although it will break backward compatibility for package containing non-ascii stuff. But these are rare.

That's true ... for the Squeak/Pharo side, there may need to be a
"classic" switch that turns of decoding, so that a new version can be
written to with the correct encoding ...

Dale