[Glass] case insensitive search broken for Unicode7?

This was reported (by me!) as bug #43773 just a few weeks ago and there will be a fix in 3.2 (coming soon!).

James

On Mar 5, 2014, at 7:28 AM, Mariano Martinez Peck <[hidden email]> wrote:

Hi guys,

I am in Gemstone 3.0.1.4 and look at the result of this expression:

('Newmont' asUnicodeString _findString: 'newm' startingAt: 1 ignoreCase: true) > 0

-> false

while

('Newmont'  _findString: 'newm' startingAt: 1 ignoreCase: true) > 0

-> true

All this started because a #matches: was failing...

I am missing something? 

Thanks,

--
Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

On Wed, Mar 5, 2014 at 3:51 PM, James Foster <[hidden email]> wrote:

On Wed, Mar 5, 2014 at 1:47 PM, James Foster <[hidden email]> wrote:

I added ‘asUppercase’ to both the receiver and the argument in my code (with a note to remove it later).

But the problem is that lots of methods will be broken....because it is all senders of all senders of all senders.. of _findString: subString startingAt: startIndex ignoreCase: aBoolean  of Unicode7.

What about this instead:

Unicode7 >> _findString: subString startingAt: startIndex ignoreCase: aBoolean

  ^ super _findString: subString startingAt: startIndex ignoreCase: aBoolean

I am not aware of any suggested changes to the base classes to fix this but I’ve indicated on the internal bug tracking system that publishing a workaround would be appreciated.

Thanks James. Indeed, a workaround is deeply appreciated. Please let me know if someone pushes one in the bug tacker. Is it public? Because I don't see anything in http://gemtalksystems.com/index.php/community/gss-support/resources/bug-notes/

That is where the bug-note would appear when/if it is written.

James

Thanks James.

The side effects of this issue is huge, isn't it? I have been debugging issues and problems related to this. Because it's not only #matches: but #includesSubstring:caseSensitive: (when send with false) and many more. I should stop my production system because some load of data etc depends in this type of message and does X or Y depending on the answer of such a message :(

thanks in advance,

 

On Wed, Mar 5, 2014 at 4:25 PM, James Foster <[hidden email]> wrote:

On Wed, Mar 5, 2014 at 3:51 PM, James Foster <[hidden email]> wrote:

On Wed, Mar 5, 2014 at 1:47 PM, James Foster <[hidden email]> wrote:

I added ‘asUppercase’ to both the receiver and the argument in my code (with a note to remove it later).

But the problem is that lots of methods will be broken....because it is all senders of all senders of all senders.. of _findString: subString startingAt: startIndex ignoreCase: aBoolean  of Unicode7.

What about this instead:

Unicode7 >> _findString: subString startingAt: startIndex ignoreCase: aBoolean

  ^ super _findString: subString startingAt: startIndex ignoreCase: aBoolean

I am not aware of any suggested changes to the base classes to fix this but I’ve indicated on the internal bug tracking system that publishing a workaround would be appreciated.

Thanks James. Indeed, a workaround is deeply appreciated. Please let me know if someone pushes one in the bug tacker. Is it public? Because I don't see anything in http://gemtalksystems.com/index.php/community/gss-support/resources/bug-notes/

That is where the bug-note would appear when/if it is written.

James

--
Mariano
http://marianopeck.wordpress.com

On Tue, Mar 11, 2014 at 3:41 PM, Mariano Martinez Peck <[hidden email]> wrote:

Hi,

Can anyone confirm a workaround that works from the deepest point so that nothing is broken? Because I am finding new problems which seem related...so if we can find a workaround from the seed of the problem we likely fix all. 

Please? 

Thanks!

 

Thanks,

On Wed, Mar 5, 2014 at 4:31 PM, Mariano Martinez Peck <[hidden email]> wrote:

Thanks James.

The side effects of this issue is huge, isn't it? I have been debugging issues and problems related to this. Because it's not only #matches: but #includesSubstring:caseSensitive: (when send with false) and many more. I should stop my production system because some load of data etc depends in this type of message and does X or Y depending on the answer of such a message :(

thanks in advance,

 

On Wed, Mar 5, 2014 at 4:25 PM, James Foster <[hidden email]> wrote:

On Wed, Mar 5, 2014 at 3:51 PM, James Foster <[hidden email]> wrote:

On Wed, Mar 5, 2014 at 1:47 PM, James Foster <[hidden email]> wrote:

I added ‘asUppercase’ to both the receiver and the argument in my code (with a note to remove it later).

But the problem is that lots of methods will be broken....because it is all senders of all senders of all senders.. of _findString: subString startingAt: startIndex ignoreCase: aBoolean  of Unicode7.

What about this instead:

Unicode7 >> _findString: subString startingAt: startIndex ignoreCase: aBoolean

  ^ super _findString: subString startingAt: startIndex ignoreCase: aBoolean

I am not aware of any suggested changes to the base classes to fix this but I’ve indicated on the internal bug tracking system that publishing a workaround would be appreciated.

Thanks James. Indeed, a workaround is deeply appreciated. Please let me know if someone pushes one in the bug tacker. Is it public? Because I don't see anything in http://gemtalksystems.com/index.php/community/gss-support/resources/bug-notes/

That is where the bug-note would appear when/if it is written.

James

--
Mariano
http://marianopeck.wordpress.com

--
Mariano
http://marianopeck.wordpress.com

--
Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Mariano,

I'm afraid that there is no simple answer ...for 3.2 we ended up making pretty significant changes at both the primitive level and the Smalltalk level and the things we did (mainly at the primitive level ... as Marten has observed) to solve the problem are not easily backported to 3.1.x.

It's looking like we will be releasing 3.2 "real soon now" so you might not have to wait long for relief.

Dale

On Mon, Mar 17, 2014 at 1:41 PM, Mariano Martinez Peck <[hidden email]> wrote:

On Tue, Mar 11, 2014 at 3:41 PM, Mariano Martinez Peck <[hidden email]> wrote:

Hi,

Can anyone confirm a workaround that works from the deepest point so that nothing is broken? Because I am finding new problems which seem related...so if we can find a workaround from the seed of the problem we likely fix all. 

Please? 

Thanks!

 

Thanks,

On Wed, Mar 5, 2014 at 4:31 PM, Mariano Martinez Peck <[hidden email]> wrote:

Thanks James.

The side effects of this issue is huge, isn't it? I have been debugging issues and problems related to this. Because it's not only #matches: but #includesSubstring:caseSensitive: (when send with false) and many more. I should stop my production system because some load of data etc depends in this type of message and does X or Y depending on the answer of such a message :(

thanks in advance,

 

On Wed, Mar 5, 2014 at 4:25 PM, James Foster <[hidden email]> wrote:

On Wed, Mar 5, 2014 at 3:51 PM, James Foster <[hidden email]> wrote:

On Wed, Mar 5, 2014 at 1:47 PM, James Foster <[hidden email]> wrote:

I added ‘asUppercase’ to both the receiver and the argument in my code (with a note to remove it later).

But the problem is that lots of methods will be broken....because it is all senders of all senders of all senders.. of _findString: subString startingAt: startIndex ignoreCase: aBoolean  of Unicode7.

What about this instead:

Unicode7 >> _findString: subString startingAt: startIndex ignoreCase: aBoolean

  ^ super _findString: subString startingAt: startIndex ignoreCase: aBoolean

I am not aware of any suggested changes to the base classes to fix this but I’ve indicated on the internal bug tracking system that publishing a workaround would be appreciated.

Thanks James. Indeed, a workaround is deeply appreciated. Please let me know if someone pushes one in the bug tacker. Is it public? Because I don't see anything in http://gemtalksystems.com/index.php/community/gss-support/resources/bug-notes/

That is where the bug-note would appear when/if it is written.

James

--
Mariano
http://marianopeck.wordpress.com

--
Mariano
http://marianopeck.wordpress.com

--
Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Mariano,

In the shower, after writing the above message, I realized that I am not an expert in the specific area where you are having problems ... the revamping that I was referring occurred in the area related to mixed comparison of Strings and Unicode and not specifically in the area of "case insensitive search", although I'm pretty sure that we've done extensive work in other areas of unicide support ... 

I am still buried so I don't really have the time to research this area, but if you supply me with some test cases I can run them against 3.2 and determine whether we've addressed your problems in 3.2 ... 

I'm from the land of "it doesn't work until I see it work" so your test cases are important in case they happen to fall into the cracks in the implementation... also it's possible that the GLASS layer is getting in the way as well (as I said, I do not have the time to actually look into this) ...

If you give me test cases, I will run them against 3.2 and let you know what I find out ...

Dale

On Tue, Mar 18, 2014 at 8:21 AM, Dale Henrichs <[hidden email]> wrote:

Mariano,

I'm afraid that there is no simple answer ...for 3.2 we ended up making pretty significant changes at both the primitive level and the Smalltalk level and the things we did (mainly at the primitive level ... as Marten has observed) to solve the problem are not easily backported to 3.1.x.

It's looking like we will be releasing 3.2 "real soon now" so you might not have to wait long for relief.

Dale

On Mon, Mar 17, 2014 at 1:41 PM, Mariano Martinez Peck <[hidden email]> wrote:

On Tue, Mar 11, 2014 at 3:41 PM, Mariano Martinez Peck <[hidden email]> wrote:

Hi,

Can anyone confirm a workaround that works from the deepest point so that nothing is broken? Because I am finding new problems which seem related...so if we can find a workaround from the seed of the problem we likely fix all. 

Please? 

Thanks!

 

Thanks,

On Wed, Mar 5, 2014 at 4:31 PM, Mariano Martinez Peck <[hidden email]> wrote:

Thanks James.

The side effects of this issue is huge, isn't it? I have been debugging issues and problems related to this. Because it's not only #matches: but #includesSubstring:caseSensitive: (when send with false) and many more. I should stop my production system because some load of data etc depends in this type of message and does X or Y depending on the answer of such a message :(

thanks in advance,

 

On Wed, Mar 5, 2014 at 4:25 PM, James Foster <[hidden email]> wrote:

On Wed, Mar 5, 2014 at 3:51 PM, James Foster <[hidden email]> wrote:

On Wed, Mar 5, 2014 at 1:47 PM, James Foster <[hidden email]> wrote:

I added ‘asUppercase’ to both the receiver and the argument in my code (with a note to remove it later).

But the problem is that lots of methods will be broken....because it is all senders of all senders of all senders.. of _findString: subString startingAt: startIndex ignoreCase: aBoolean  of Unicode7.

What about this instead:

Unicode7 >> _findString: subString startingAt: startIndex ignoreCase: aBoolean

  ^ super _findString: subString startingAt: startIndex ignoreCase: aBoolean

I am not aware of any suggested changes to the base classes to fix this but I’ve indicated on the internal bug tracking system that publishing a workaround would be appreciated.

Thanks James. Indeed, a workaround is deeply appreciated. Please let me know if someone pushes one in the bug tacker. Is it public? Because I don't see anything in http://gemtalksystems.com/index.php/community/gss-support/resources/bug-notes/

That is where the bug-note would appear when/if it is written.

James

--
Mariano
http://marianopeck.wordpress.com

--
Mariano
http://marianopeck.wordpress.com

--
Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

This should work at least:

(Unicode7 withAll: String new) includesString: 'abc' 

(Unicode7 withAll: '') includesString: 'abc' 

Gerhard

On Tue, Mar 18, 2014 at 4:54 PM, Dale Henrichs <[hidden email]> wrote:

Mariano,

In the shower, after writing the above message, I realized that I am not an expert in the specific area where you are having problems ... the revamping that I was referring occurred in the area related to mixed comparison of Strings and Unicode and not specifically in the area of "case insensitive search", although I'm pretty sure that we've done extensive work in other areas of unicide support ... 

I am still buried so I don't really have the time to research this area, but if you supply me with some test cases I can run them against 3.2 and determine whether we've addressed your problems in 3.2 ... 

I'm from the land of "it doesn't work until I see it work" so your test cases are important in case they happen to fall into the cracks in the implementation... also it's possible that the GLASS layer is getting in the way as well (as I said, I do not have the time to actually look into this) ...

If you give me test cases, I will run them against 3.2 and let you know what I find out ...

Dale

On Tue, Mar 18, 2014 at 8:21 AM, Dale Henrichs <[hidden email]> wrote:

Mariano,

I'm afraid that there is no simple answer ...for 3.2 we ended up making pretty significant changes at both the primitive level and the Smalltalk level and the things we did (mainly at the primitive level ... as Marten has observed) to solve the problem are not easily backported to 3.1.x.

It's looking like we will be releasing 3.2 "real soon now" so you might not have to wait long for relief.

Dale

On Mon, Mar 17, 2014 at 1:41 PM, Mariano Martinez Peck <[hidden email]> wrote:

On Tue, Mar 11, 2014 at 3:41 PM, Mariano Martinez Peck <[hidden email]> wrote:

Hi,

Can anyone confirm a workaround that works from the deepest point so that nothing is broken? Because I am finding new problems which seem related...so if we can find a workaround from the seed of the problem we likely fix all. 

Please? 

Thanks!

 

Thanks,

On Wed, Mar 5, 2014 at 4:31 PM, Mariano Martinez Peck <[hidden email]> wrote:

Thanks James.

The side effects of this issue is huge, isn't it? I have been debugging issues and problems related to this. Because it's not only #matches: but #includesSubstring:caseSensitive: (when send with false) and many more. I should stop my production system because some load of data etc depends in this type of message and does X or Y depending on the answer of such a message :(

thanks in advance,

 

On Wed, Mar 5, 2014 at 4:25 PM, James Foster <[hidden email]> wrote:

On Wed, Mar 5, 2014 at 3:51 PM, James Foster <[hidden email]> wrote:

On Wed, Mar 5, 2014 at 1:47 PM, James Foster <[hidden email]> wrote:

I added ‘asUppercase’ to both the receiver and the argument in my code (with a note to remove it later).

But the problem is that lots of methods will be broken....because it is all senders of all senders of all senders.. of _findString: subString startingAt: startIndex ignoreCase: aBoolean  of Unicode7.

What about this instead:

Unicode7 >> _findString: subString startingAt: startIndex ignoreCase: aBoolean

  ^ super _findString: subString startingAt: startIndex ignoreCase: aBoolean

I am not aware of any suggested changes to the base classes to fix this but I’ve indicated on the internal bug tracking system that publishing a workaround would be appreciated.

Thanks James. Indeed, a workaround is deeply appreciated. Please let me know if someone pushes one in the bug tacker. Is it public? Because I don't see anything in http://gemtalksystems.com/index.php/community/gss-support/resources/bug-notes/

That is where the bug-note would appear when/if it is written.

James

--
Mariano
http://marianopeck.wordpress.com

--
Mariano
http://marianopeck.wordpress.com

--
Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Gerhard,

Well, those two expressions are still failing in 3.2 so I'll submit a bug and it should be fixed when 3.2 is released ... "real soon now".

Thanks!

Dale

On Sat, Mar 22, 2014 at 7:56 AM, Gerhard Obermann <[hidden email]> wrote:

This should work at least:

(Unicode7 withAll: String new) includesString: 'abc' 

(Unicode7 withAll: '') includesString: 'abc' 

Gerhard

On Tue, Mar 18, 2014 at 4:54 PM, Dale Henrichs <[hidden email]> wrote:

Mariano,

In the shower, after writing the above message, I realized that I am not an expert in the specific area where you are having problems ... the revamping that I was referring occurred in the area related to mixed comparison of Strings and Unicode and not specifically in the area of "case insensitive search", although I'm pretty sure that we've done extensive work in other areas of unicide support ... 

I am still buried so I don't really have the time to research this area, but if you supply me with some test cases I can run them against 3.2 and determine whether we've addressed your problems in 3.2 ... 

I'm from the land of "it doesn't work until I see it work" so your test cases are important in case they happen to fall into the cracks in the implementation... also it's possible that the GLASS layer is getting in the way as well (as I said, I do not have the time to actually look into this) ...

If you give me test cases, I will run them against 3.2 and let you know what I find out ...

Dale

On Tue, Mar 18, 2014 at 8:21 AM, Dale Henrichs <[hidden email]> wrote:

Mariano,

I'm afraid that there is no simple answer ...for 3.2 we ended up making pretty significant changes at both the primitive level and the Smalltalk level and the things we did (mainly at the primitive level ... as Marten has observed) to solve the problem are not easily backported to 3.1.x.

It's looking like we will be releasing 3.2 "real soon now" so you might not have to wait long for relief.

Dale

On Mon, Mar 17, 2014 at 1:41 PM, Mariano Martinez Peck <[hidden email]> wrote:

On Tue, Mar 11, 2014 at 3:41 PM, Mariano Martinez Peck <[hidden email]> wrote:

Hi,

Can anyone confirm a workaround that works from the deepest point so that nothing is broken? Because I am finding new problems which seem related...so if we can find a workaround from the seed of the problem we likely fix all. 

Please? 

Thanks!

 

Thanks,

On Wed, Mar 5, 2014 at 4:31 PM, Mariano Martinez Peck <[hidden email]> wrote:

Thanks James.

The side effects of this issue is huge, isn't it? I have been debugging issues and problems related to this. Because it's not only #matches: but #includesSubstring:caseSensitive: (when send with false) and many more. I should stop my production system because some load of data etc depends in this type of message and does X or Y depending on the answer of such a message :(

thanks in advance,

 

On Wed, Mar 5, 2014 at 4:25 PM, James Foster <[hidden email]> wrote:

On Wed, Mar 5, 2014 at 3:51 PM, James Foster <[hidden email]> wrote:

On Wed, Mar 5, 2014 at 1:47 PM, James Foster <[hidden email]> wrote:

I added ‘asUppercase’ to both the receiver and the argument in my code (with a note to remove it later).

But the problem is that lots of methods will be broken....because it is all senders of all senders of all senders.. of _findString: subString startingAt: startIndex ignoreCase: aBoolean  of Unicode7.

What about this instead:

Unicode7 >> _findString: subString startingAt: startIndex ignoreCase: aBoolean

  ^ super _findString: subString startingAt: startIndex ignoreCase: aBoolean

I am not aware of any suggested changes to the base classes to fix this but I’ve indicated on the internal bug tracking system that publishing a workaround would be appreciated.

Thanks James. Indeed, a workaround is deeply appreciated. Please let me know if someone pushes one in the bug tacker. Is it public? Because I don't see anything in http://gemtalksystems.com/index.php/community/gss-support/resources/bug-notes/

That is where the bug-note would appear when/if it is written.

James

--
Mariano
http://marianopeck.wordpress.com

--
Mariano
http://marianopeck.wordpress.com

--
Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Dale, the problem is deeper than the #includesSubstring:

The first test of this thread is an example:

('Newmont' asUnicodeString _findString: 'newm' startingAt: 1 ignoreCase: true) > 0

that should answer true, as well as:

((Unicode7 withAll: 'Newmont') _findString: 'newm' startingAt: 1 ignoreCase: true) > 0

And not only Unice7 but all Unicode classes.

In my case, what I did is to take all Unicode classes and override # _findString:startingAt:ignoreCase:  to this:

Unicode7 >> _findString: subString startingAt: startIndex ignoreCase: aBoolean

^ super _findString: subString startingAt: startIndex ignoreCase: aBoolean

simple...avoid using the icu collector.

Thanks, 

On Sat, Mar 22, 2014 at 1:33 PM, Dale Henrichs <[hidden email]> wrote:

Gerhard,

Well, those two expressions are still failing in 3.2 so I'll submit a bug and it should be fixed when 3.2 is released ... "real soon now".

Thanks!

Dale

On Sat, Mar 22, 2014 at 7:56 AM, Gerhard Obermann <[hidden email]> wrote:

This should work at least:

(Unicode7 withAll: String new) includesString: 'abc' 

(Unicode7 withAll: '') includesString: 'abc' 

Gerhard

On Tue, Mar 18, 2014 at 4:54 PM, Dale Henrichs <[hidden email]> wrote:

Mariano,

In the shower, after writing the above message, I realized that I am not an expert in the specific area where you are having problems ... the revamping that I was referring occurred in the area related to mixed comparison of Strings and Unicode and not specifically in the area of "case insensitive search", although I'm pretty sure that we've done extensive work in other areas of unicide support ... 

I am still buried so I don't really have the time to research this area, but if you supply me with some test cases I can run them against 3.2 and determine whether we've addressed your problems in 3.2 ... 

I'm from the land of "it doesn't work until I see it work" so your test cases are important in case they happen to fall into the cracks in the implementation... also it's possible that the GLASS layer is getting in the way as well (as I said, I do not have the time to actually look into this) ...

If you give me test cases, I will run them against 3.2 and let you know what I find out ...

Dale

On Tue, Mar 18, 2014 at 8:21 AM, Dale Henrichs <[hidden email]> wrote:

Mariano,

I'm afraid that there is no simple answer ...for 3.2 we ended up making pretty significant changes at both the primitive level and the Smalltalk level and the things we did (mainly at the primitive level ... as Marten has observed) to solve the problem are not easily backported to 3.1.x.

It's looking like we will be releasing 3.2 "real soon now" so you might not have to wait long for relief.

Dale

On Mon, Mar 17, 2014 at 1:41 PM, Mariano Martinez Peck <[hidden email]> wrote:

On Tue, Mar 11, 2014 at 3:41 PM, Mariano Martinez Peck <[hidden email]> wrote:

Hi,

Can anyone confirm a workaround that works from the deepest point so that nothing is broken? Because I am finding new problems which seem related...so if we can find a workaround from the seed of the problem we likely fix all. 

Please? 

Thanks!

 

Thanks,

On Wed, Mar 5, 2014 at 4:31 PM, Mariano Martinez Peck <[hidden email]> wrote:

Thanks James.

The side effects of this issue is huge, isn't it? I have been debugging issues and problems related to this. Because it's not only #matches: but #includesSubstring:caseSensitive: (when send with false) and many more. I should stop my production system because some load of data etc depends in this type of message and does X or Y depending on the answer of such a message :(

thanks in advance,

 

On Wed, Mar 5, 2014 at 4:25 PM, James Foster <[hidden email]> wrote:

On Wed, Mar 5, 2014 at 3:51 PM, James Foster <[hidden email]> wrote:

On Wed, Mar 5, 2014 at 1:47 PM, James Foster <[hidden email]> wrote:

I added ‘asUppercase’ to both the receiver and the argument in my code (with a note to remove it later).

But the problem is that lots of methods will be broken....because it is all senders of all senders of all senders.. of _findString: subString startingAt: startIndex ignoreCase: aBoolean  of Unicode7.

What about this instead:

Unicode7 >> _findString: subString startingAt: startIndex ignoreCase: aBoolean

  ^ super _findString: subString startingAt: startIndex ignoreCase: aBoolean

I am not aware of any suggested changes to the base classes to fix this but I’ve indicated on the internal bug tracking system that publishing a workaround would be appreciated.

Thanks James. Indeed, a workaround is deeply appreciated. Please let me know if someone pushes one in the bug tacker. Is it public? Because I don't see anything in http://gemtalksystems.com/index.php/community/gss-support/resources/bug-notes/

That is where the bug-note would appear when/if it is written.

James

--
Mariano
http://marianopeck.wordpress.com

--
Mariano
http://marianopeck.wordpress.com

--
Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

--
Mariano
http://marianopeck.wordpress.com

Reading this - please, please make all ICU primitives available to the
user .... and perhaps it would also be nice to know, which ICU is
delivered with the product ... and perhaps this makes it even possible
to exchange the ICU packages needed ...

Marten

 Am 22.03.2014 17:45, schrieb Mariano Martinez Peck:

> Dale, the problem is deeper than the #includesSubstring:
>
> The first test of this thread is an example:
>
> ('Newmont' asUnicodeString _findString: 'newm' startingAt: 1 ignoreCase:
> true) > 0
>
> that should answer true, as well as:
>
> ((Unicode7 withAll: 'Newmont') _findString: 'newm' startingAt: 1
> ignoreCase: true) > 0
>
> And not only Unice7 but all Unicode classes.
>

--
Marten Feldtmann

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass