two strings with same constituents compare as not equal

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

two strings with same constituents compare as not equal

Paul DeBruicker
Why would two strings in a test method compare as not equal when, if you
explore them they have the same characters and are of the same class?
Reply | Threaded
Open this post in threaded view
|

Re: two strings with same constituents compare as not equal

Dale Henrichs
Paul,

That shouldn't happen ...

I'd like to get my hands on one of those boys...

I have seen cases when porting tests from Pharo where Strings and Symbols get used interchangeably (Strings and Symbols compare #= in Pharo and not in GemStone ... according to ANSI String and Symbols should not compare #=) causing the tests to fail miserably ...  

Dale

----- Original Message -----
| From: "Paul DeBruicker" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Friday, February 22, 2013 7:48:16 AM
| Subject: [GS/SS Beta] two strings with same constituents compare as not equal
|
| Why would two strings in a test method compare as not equal when, if you
| explore them they have the same characters and are of the same class?
|
Reply | Threaded
Open this post in threaded view
|

Re: two strings with same constituents compare as not equal

Paul DeBruicker
Hi Dale,

I uploaded an extent here:
http://dl.dropbox.com/u/4460862/ical-test-for-dale.dbf

Its from a 3.1.0.1 extent from the install script on
seaside.gemstone.com with no updates to GLASS applied.


One test that exhibits the issue is this one:
ICConversion>>testParseString

some of the others also have the same problem including:
ICVCardTest>>testParseSurendar
ICVCardTest>>testParseOscar

Also I have some squeak compatability methods I'll upload soon.


Thanks for taking a look.


Paul



On 02/22/2013 07:58 AM, Dale Henrichs wrote:

> Paul,
>
> That shouldn't happen ...
>
> I'd like to get my hands on one of those boys...
>
> I have seen cases when porting tests from Pharo where Strings and Symbols get used interchangeably (Strings and Symbols compare #= in Pharo and not in GemStone ... according to ANSI String and Symbols should not compare #=) causing the tests to fail miserably ...  
>
> Dale
>
> ----- Original Message -----
> | From: "Paul DeBruicker" <[hidden email]>
> | To: "GemStone Seaside beta discussion" <[hidden email]>
> | Sent: Friday, February 22, 2013 7:48:16 AM
> | Subject: [GS/SS Beta] two strings with same constituents compare as not equal
> |
> | Why would two strings in a test method compare as not equal when, if you
> | explore them they have the same characters and are of the same class?
> |
>

Reply | Threaded
Open this post in threaded view
|

Re: two strings with same constituents compare as not equal

Paul DeBruicker
Hi Dale,

If you want to load all that stuff into a clean extent you'll need the
Squeak package I uploaded to Gemsource here:

http://seaside.gemstone.com/ss/monticello/


and the configuration from

http://www.squeaksource.com/ical

then

ConfigurationOfICal project stableVersion load:'Tests'

and proceed through a warning about True/False classes not existing.




On 02/22/2013 09:05 AM, Paul DeBruicker wrote:

> Hi Dale,
>
> I uploaded an extent here:
> http://dl.dropbox.com/u/4460862/ical-test-for-dale.dbf
>
> Its from a 3.1.0.1 extent from the install script on
> seaside.gemstone.com with no updates to GLASS applied.
>
>
> One test that exhibits the issue is this one:
> ICConversion>>testParseString
>
> some of the others also have the same problem including:
> ICVCardTest>>testParseSurendar
> ICVCardTest>>testParseOscar
>
> Also I have some squeak compatability methods I'll upload soon.
>
>
> Thanks for taking a look.
>
>
> Paul
>
>
>
> On 02/22/2013 07:58 AM, Dale Henrichs wrote:
>> Paul,
>>
>> That shouldn't happen ...
>>
>> I'd like to get my hands on one of those boys...
>>
>> I have seen cases when porting tests from Pharo where Strings and Symbols get used interchangeably (Strings and Symbols compare #= in Pharo and not in GemStone ... according to ANSI String and Symbols should not compare #=) causing the tests to fail miserably ...  
>>
>> Dale
>>
>> ----- Original Message -----
>> | From: "Paul DeBruicker" <[hidden email]>
>> | To: "GemStone Seaside beta discussion" <[hidden email]>
>> | Sent: Friday, February 22, 2013 7:48:16 AM
>> | Subject: [GS/SS Beta] two strings with same constituents compare as not equal
>> |
>> | Why would two strings in a test method compare as not equal when, if you
>> | explore them they have the same characters and are of the same class?
>> |
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: two strings with same constituents compare as not equal

Dale Henrichs
In reply to this post by Paul DeBruicker
Paul,

The problem has to do with differences between the line end character used in Gemstone and Pharo...

Strings in methods will typically end up a Character lf in GemStone and a Character cr in Pharo while the generated Streams will end up Character cr (since it is explictly added by the code) ... at some level it is just happenstance that the tests work in Pharo ...

I'm a bit surprised to see that the inspector reported Character cr, but explicitly grabbing the characters and comparing the integer values revealed the problem (when I saw that the String was embedded in the method I knew that the line end character had to be the culprit):

  | x y z |
  y := Array new.
  z := Array new.
  expected do: [:each |y add:  each asInteger].
  actual do: [:each | z add: each asInteger].
  x := {y. z. }.

The fact that the debugger showed Character cr is a new bug ... in the past I didn't have to resort to the asInteger trick to identify the problem, so I'll have to dig around a bit to see who's lying ...

I wish tODE was ready as a replacement for GemTools, but it's not quite ready yet ...

Dale

----- Original Message -----
| From: "Paul DeBruicker" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Friday, February 22, 2013 9:05:22 AM
| Subject: Re: [GS/SS Beta] two strings with same constituents compare as not equal
|
| Hi Dale,
|
| I uploaded an extent here:
| http://dl.dropbox.com/u/4460862/ical-test-for-dale.dbf
|
| Its from a 3.1.0.1 extent from the install script on
| seaside.gemstone.com with no updates to GLASS applied.
|
|
| One test that exhibits the issue is this one:
| ICConversion>>testParseString
|
| some of the others also have the same problem including:
| ICVCardTest>>testParseSurendar
| ICVCardTest>>testParseOscar
|
| Also I have some squeak compatability methods I'll upload soon.
|
|
| Thanks for taking a look.
|
|
| Paul
|
|
|
| On 02/22/2013 07:58 AM, Dale Henrichs wrote:
| > Paul,
| >
| > That shouldn't happen ...
| >
| > I'd like to get my hands on one of those boys...
| >
| > I have seen cases when porting tests from Pharo where Strings and Symbols
| > get used interchangeably (Strings and Symbols compare #= in Pharo and not
| > in GemStone ... according to ANSI String and Symbols should not compare
| > #=) causing the tests to fail miserably ...
| >
| > Dale
| >
| > ----- Original Message -----
| > | From: "Paul DeBruicker" <[hidden email]>
| > | To: "GemStone Seaside beta discussion" <[hidden email]>
| > | Sent: Friday, February 22, 2013 7:48:16 AM
| > | Subject: [GS/SS Beta] two strings with same constituents compare as not
| > | equal
| > |
| > | Why would two strings in a test method compare as not equal when, if you
| > | explore them they have the same characters and are of the same class?
| > |
| >
|
Reply | Threaded
Open this post in threaded view
|

Re: two strings with same constituents compare as not equal

Dale Henrichs
Paul,

When I tried it again, I got the right answer in GemTools, so I may have been dreaming that the inspector lied to me ... When a test string is embedded in a method I use #withSqueakLineEndings or (#withGemstoneLineEndings) to coerce both strings to use the same line ending convention ...

Dale

----- Original Message -----
| From: "Dale Henrichs" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Friday, February 22, 2013 2:39:49 PM
| Subject: Re: [GS/SS Beta] two strings with same constituents compare as not equal
|
| Paul,
|
| The problem has to do with differences between the line end character used in
| Gemstone and Pharo...
|
| Strings in methods will typically end up a Character lf in GemStone and a
| Character cr in Pharo while the generated Streams will end up Character cr
| (since it is explictly added by the code) ... at some level it is just
| happenstance that the tests work in Pharo ...
|
| I'm a bit surprised to see that the inspector reported Character cr, but
| explicitly grabbing the characters and comparing the integer values revealed
| the problem (when I saw that the String was embedded in the method I knew
| that the line end character had to be the culprit):
|
|   | x y z |
|   y := Array new.
|   z := Array new.
|   expected do: [:each |y add:  each asInteger].
|   actual do: [:each | z add: each asInteger].
|   x := {y. z. }.
|
| The fact that the debugger showed Character cr is a new bug ... in the past I
| didn't have to resort to the asInteger trick to identify the problem, so
| I'll have to dig around a bit to see who's lying ...
|
| I wish tODE was ready as a replacement for GemTools, but it's not quite ready
| yet ...
|
| Dale
|
| ----- Original Message -----
| | From: "Paul DeBruicker" <[hidden email]>
| | To: "GemStone Seaside beta discussion" <[hidden email]>
| | Sent: Friday, February 22, 2013 9:05:22 AM
| | Subject: Re: [GS/SS Beta] two strings with same constituents compare as not
| | equal
| |
| | Hi Dale,
| |
| | I uploaded an extent here:
| | http://dl.dropbox.com/u/4460862/ical-test-for-dale.dbf
| |
| | Its from a 3.1.0.1 extent from the install script on
| | seaside.gemstone.com with no updates to GLASS applied.
| |
| |
| | One test that exhibits the issue is this one:
| | ICConversion>>testParseString
| |
| | some of the others also have the same problem including:
| | ICVCardTest>>testParseSurendar
| | ICVCardTest>>testParseOscar
| |
| | Also I have some squeak compatability methods I'll upload soon.
| |
| |
| | Thanks for taking a look.
| |
| |
| | Paul
| |
| |
| |
| | On 02/22/2013 07:58 AM, Dale Henrichs wrote:
| | > Paul,
| | >
| | > That shouldn't happen ...
| | >
| | > I'd like to get my hands on one of those boys...
| | >
| | > I have seen cases when porting tests from Pharo where Strings and Symbols
| | > get used interchangeably (Strings and Symbols compare #= in Pharo and not
| | > in GemStone ... according to ANSI String and Symbols should not compare
| | > #=) causing the tests to fail miserably ...
| | >
| | > Dale
| | >
| | > ----- Original Message -----
| | > | From: "Paul DeBruicker" <[hidden email]>
| | > | To: "GemStone Seaside beta discussion" <[hidden email]>
| | > | Sent: Friday, February 22, 2013 7:48:16 AM
| | > | Subject: [GS/SS Beta] two strings with same constituents compare as not
| | > | equal
| | > |
| | > | Why would two strings in a test method compare as not equal when, if
| | > | you
| | > | explore them they have the same characters and are of the same class?
| | > |
| | >
| |
|
Reply | Threaded
Open this post in threaded view
|

Re: two strings with same constituents compare as not equal

Paul DeBruicker
Thanks Dale.  It was odd to me that they had the same integer value and
didn't compare as equal.  But I could easily have just been misreading it.




On 02/22/2013 03:07 PM, Dale Henrichs wrote:

> Paul,
>
> When I tried it again, I got the right answer in GemTools, so I may have been dreaming that the inspector lied to me ... When a test string is embedded in a method I use #withSqueakLineEndings or (#withGemstoneLineEndings) to coerce both strings to use the same line ending convention ...
>
> Dale
>
> ----- Original Message -----
> | From: "Dale Henrichs" <[hidden email]>
> | To: "GemStone Seaside beta discussion" <[hidden email]>
> | Sent: Friday, February 22, 2013 2:39:49 PM
> | Subject: Re: [GS/SS Beta] two strings with same constituents compare as not equal
> |
> | Paul,
> |
> | The problem has to do with differences between the line end character used in
> | Gemstone and Pharo...
> |
> | Strings in methods will typically end up a Character lf in GemStone and a
> | Character cr in Pharo while the generated Streams will end up Character cr
> | (since it is explictly added by the code) ... at some level it is just
> | happenstance that the tests work in Pharo ...
> |
> | I'm a bit surprised to see that the inspector reported Character cr, but
> | explicitly grabbing the characters and comparing the integer values revealed
> | the problem (when I saw that the String was embedded in the method I knew
> | that the line end character had to be the culprit):
> |
> |   | x y z |
> |   y := Array new.
> |   z := Array new.
> |   expected do: [:each |y add:  each asInteger].
> |   actual do: [:each | z add: each asInteger].
> |   x := {y. z. }.
> |
> | The fact that the debugger showed Character cr is a new bug ... in the past I
> | didn't have to resort to the asInteger trick to identify the problem, so
> | I'll have to dig around a bit to see who's lying ...
> |
> | I wish tODE was ready as a replacement for GemTools, but it's not quite ready
> | yet ...
> |
> | Dale
> |
> | ----- Original Message -----
> | | From: "Paul DeBruicker" <[hidden email]>
> | | To: "GemStone Seaside beta discussion" <[hidden email]>
> | | Sent: Friday, February 22, 2013 9:05:22 AM
> | | Subject: Re: [GS/SS Beta] two strings with same constituents compare as not
> | | equal
> | |
> | | Hi Dale,
> | |
> | | I uploaded an extent here:
> | | http://dl.dropbox.com/u/4460862/ical-test-for-dale.dbf
> | |
> | | Its from a 3.1.0.1 extent from the install script on
> | | seaside.gemstone.com with no updates to GLASS applied.
> | |
> | |
> | | One test that exhibits the issue is this one:
> | | ICConversion>>testParseString
> | |
> | | some of the others also have the same problem including:
> | | ICVCardTest>>testParseSurendar
> | | ICVCardTest>>testParseOscar
> | |
> | | Also I have some squeak compatability methods I'll upload soon.
> | |
> | |
> | | Thanks for taking a look.
> | |
> | |
> | | Paul
> | |
> | |
> | |
> | | On 02/22/2013 07:58 AM, Dale Henrichs wrote:
> | | > Paul,
> | | >
> | | > That shouldn't happen ...
> | | >
> | | > I'd like to get my hands on one of those boys...
> | | >
> | | > I have seen cases when porting tests from Pharo where Strings and Symbols
> | | > get used interchangeably (Strings and Symbols compare #= in Pharo and not
> | | > in GemStone ... according to ANSI String and Symbols should not compare
> | | > #=) causing the tests to fail miserably ...
> | | >
> | | > Dale
> | | >
> | | > ----- Original Message -----
> | | > | From: "Paul DeBruicker" <[hidden email]>
> | | > | To: "GemStone Seaside beta discussion" <[hidden email]>
> | | > | Sent: Friday, February 22, 2013 7:48:16 AM
> | | > | Subject: [GS/SS Beta] two strings with same constituents compare as not
> | | > | equal
> | | > |
> | | > | Why would two strings in a test method compare as not equal when, if
> | | > | you
> | | > | explore them they have the same characters and are of the same class?
> | | > |
> | | >
> | |
> |
>

Reply | Threaded
Open this post in threaded view
|

Re: two strings with same constituents compare as not equal

Dale Henrichs
I might have to try harder to find the bug in GemTools...or better yet get tODE in shape for general use ...

Dale

----- Original Message -----
| From: "Paul DeBruicker" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Friday, February 22, 2013 3:26:34 PM
| Subject: Re: [GS/SS Beta] two strings with same constituents compare as not equal
|
| Thanks Dale.  It was odd to me that they had the same integer value and
| didn't compare as equal.  But I could easily have just been misreading it.
|
|
|
|
| On 02/22/2013 03:07 PM, Dale Henrichs wrote:
| > Paul,
| >
| > When I tried it again, I got the right answer in GemTools, so I may have
| > been dreaming that the inspector lied to me ... When a test string is
| > embedded in a method I use #withSqueakLineEndings or
| > (#withGemstoneLineEndings) to coerce both strings to use the same line
| > ending convention ...
| >
| > Dale
| >
| > ----- Original Message -----
| > | From: "Dale Henrichs" <[hidden email]>
| > | To: "GemStone Seaside beta discussion" <[hidden email]>
| > | Sent: Friday, February 22, 2013 2:39:49 PM
| > | Subject: Re: [GS/SS Beta] two strings with same constituents compare as
| > | not equal
| > |
| > | Paul,
| > |
| > | The problem has to do with differences between the line end character
| > | used in
| > | Gemstone and Pharo...
| > |
| > | Strings in methods will typically end up a Character lf in GemStone and a
| > | Character cr in Pharo while the generated Streams will end up Character
| > | cr
| > | (since it is explictly added by the code) ... at some level it is just
| > | happenstance that the tests work in Pharo ...
| > |
| > | I'm a bit surprised to see that the inspector reported Character cr, but
| > | explicitly grabbing the characters and comparing the integer values
| > | revealed
| > | the problem (when I saw that the String was embedded in the method I knew
| > | that the line end character had to be the culprit):
| > |
| > |   | x y z |
| > |   y := Array new.
| > |   z := Array new.
| > |   expected do: [:each |y add:  each asInteger].
| > |   actual do: [:each | z add: each asInteger].
| > |   x := {y. z. }.
| > |
| > | The fact that the debugger showed Character cr is a new bug ... in the
| > | past I
| > | didn't have to resort to the asInteger trick to identify the problem, so
| > | I'll have to dig around a bit to see who's lying ...
| > |
| > | I wish tODE was ready as a replacement for GemTools, but it's not quite
| > | ready
| > | yet ...
| > |
| > | Dale
| > |
| > | ----- Original Message -----
| > | | From: "Paul DeBruicker" <[hidden email]>
| > | | To: "GemStone Seaside beta discussion" <[hidden email]>
| > | | Sent: Friday, February 22, 2013 9:05:22 AM
| > | | Subject: Re: [GS/SS Beta] two strings with same constituents compare as
| > | | not
| > | | equal
| > | |
| > | | Hi Dale,
| > | |
| > | | I uploaded an extent here:
| > | | http://dl.dropbox.com/u/4460862/ical-test-for-dale.dbf
| > | |
| > | | Its from a 3.1.0.1 extent from the install script on
| > | | seaside.gemstone.com with no updates to GLASS applied.
| > | |
| > | |
| > | | One test that exhibits the issue is this one:
| > | | ICConversion>>testParseString
| > | |
| > | | some of the others also have the same problem including:
| > | | ICVCardTest>>testParseSurendar
| > | | ICVCardTest>>testParseOscar
| > | |
| > | | Also I have some squeak compatability methods I'll upload soon.
| > | |
| > | |
| > | | Thanks for taking a look.
| > | |
| > | |
| > | | Paul
| > | |
| > | |
| > | |
| > | | On 02/22/2013 07:58 AM, Dale Henrichs wrote:
| > | | > Paul,
| > | | >
| > | | > That shouldn't happen ...
| > | | >
| > | | > I'd like to get my hands on one of those boys...
| > | | >
| > | | > I have seen cases when porting tests from Pharo where Strings and
| > | | > Symbols
| > | | > get used interchangeably (Strings and Symbols compare #= in Pharo and
| > | | > not
| > | | > in GemStone ... according to ANSI String and Symbols should not
| > | | > compare
| > | | > #=) causing the tests to fail miserably ...
| > | | >
| > | | > Dale
| > | | >
| > | | > ----- Original Message -----
| > | | > | From: "Paul DeBruicker" <[hidden email]>
| > | | > | To: "GemStone Seaside beta discussion" <[hidden email]>
| > | | > | Sent: Friday, February 22, 2013 7:48:16 AM
| > | | > | Subject: [GS/SS Beta] two strings with same constituents compare as
| > | | > | not
| > | | > | equal
| > | | > |
| > | | > | Why would two strings in a test method compare as not equal when,
| > | | > | if
| > | | > | you
| > | | > | explore them they have the same characters and are of the same
| > | | > | class?
| > | | > |
| > | | >
| > | |
| > |
| >
|
Reply | Threaded
Open this post in threaded view
|

Re: two strings with same constituents compare as not equal

bprior
Hi Dale,

I have tried tODE and found it fascinating. Here is my vote for "getting it in shape for general use."

Bruce Prior

On 2013-02-22 4:28 PM, Dale Henrichs wrote:
I might have to try harder to find the bug in GemTools...or better yet get tODE in shape for general use ...

Dale

----- Original Message -----
| From: "Paul DeBruicker" [hidden email]
| To: "GemStone Seaside beta discussion" [hidden email]
| Sent: Friday, February 22, 2013 3:26:34 PM
| Subject: Re: [GS/SS Beta] two strings with same constituents compare as not equal
| 
| Thanks Dale.  It was odd to me that they had the same integer value and
| didn't compare as equal.  But I could easily have just been misreading it.
| 
| 
| 
| 
| On 02/22/2013 03:07 PM, Dale Henrichs wrote:
| > Paul,
| > 
| > When I tried it again, I got the right answer in GemTools, so I may have
| > been dreaming that the inspector lied to me ... When a test string is
| > embedded in a method I use #withSqueakLineEndings or
| > (#withGemstoneLineEndings) to coerce both strings to use the same line
| > ending convention ...
| > 
| > Dale
| > 
| > ----- Original Message -----
| > | From: "Dale Henrichs" [hidden email]
| > | To: "GemStone Seaside beta discussion" [hidden email]
| > | Sent: Friday, February 22, 2013 2:39:49 PM
| > | Subject: Re: [GS/SS Beta] two strings with same constituents compare as
| > | not equal
| > | 
| > | Paul,
| > | 
| > | The problem has to do with differences between the line end character
| > | used in
| > | Gemstone and Pharo...
| > | 
| > | Strings in methods will typically end up a Character lf in GemStone and a
| > | Character cr in Pharo while the generated Streams will end up Character
| > | cr
| > | (since it is explictly added by the code) ... at some level it is just
| > | happenstance that the tests work in Pharo ...
| > | 
| > | I'm a bit surprised to see that the inspector reported Character cr, but
| > | explicitly grabbing the characters and comparing the integer values
| > | revealed
| > | the problem (when I saw that the String was embedded in the method I knew
| > | that the line end character had to be the culprit):
| > | 
| > |   | x y z |
| > |   y := Array new.
| > |   z := Array new.
| > |   expected do: [:each |y add:  each asInteger].
| > |   actual do: [:each | z add: each asInteger].
| > |   x := {y. z. }.
| > | 
| > | The fact that the debugger showed Character cr is a new bug ... in the
| > | past I
| > | didn't have to resort to the asInteger trick to identify the problem, so
| > | I'll have to dig around a bit to see who's lying ...
| > | 
| > | I wish tODE was ready as a replacement for GemTools, but it's not quite
| > | ready
| > | yet ...
| > | 
| > | Dale
| > | 
| > | ----- Original Message -----
| > | | From: "Paul DeBruicker" [hidden email]
| > | | To: "GemStone Seaside beta discussion" [hidden email]
| > | | Sent: Friday, February 22, 2013 9:05:22 AM
| > | | Subject: Re: [GS/SS Beta] two strings with same constituents compare as
| > | | not
| > | | equal
| > | | 
| > | | Hi Dale,
| > | | 
| > | | I uploaded an extent here:
| > | | http://dl.dropbox.com/u/4460862/ical-test-for-dale.dbf
| > | | 
| > | | Its from a 3.1.0.1 extent from the install script on
| > | | seaside.gemstone.com with no updates to GLASS applied.
| > | | 
| > | | 
| > | | One test that exhibits the issue is this one:
| > | | ICConversion>>testParseString
| > | | 
| > | | some of the others also have the same problem including:
| > | | ICVCardTest>>testParseSurendar
| > | | ICVCardTest>>testParseOscar
| > | | 
| > | | Also I have some squeak compatability methods I'll upload soon.
| > | | 
| > | | 
| > | | Thanks for taking a look.
| > | | 
| > | | 
| > | | Paul
| > | | 
| > | | 
| > | | 
| > | | On 02/22/2013 07:58 AM, Dale Henrichs wrote:
| > | | > Paul,
| > | | > 
| > | | > That shouldn't happen ...
| > | | > 
| > | | > I'd like to get my hands on one of those boys...
| > | | > 
| > | | > I have seen cases when porting tests from Pharo where Strings and
| > | | > Symbols
| > | | > get used interchangeably (Strings and Symbols compare #= in Pharo and
| > | | > not
| > | | > in GemStone ... according to ANSI String and Symbols should not
| > | | > compare
| > | | > #=) causing the tests to fail miserably ...
| > | | > 
| > | | > Dale
| > | | > 
| > | | > ----- Original Message -----
| > | | > | From: "Paul DeBruicker" [hidden email]
| > | | > | To: "GemStone Seaside beta discussion" [hidden email]
| > | | > | Sent: Friday, February 22, 2013 7:48:16 AM
| > | | > | Subject: [GS/SS Beta] two strings with same constituents compare as
| > | | > | not
| > | | > | equal
| > | | > | 
| > | | > | Why would two strings in a test method compare as not equal when,
| > | | > | if
| > | | > | you
| > | | > | explore them they have the same characters and are of the same
| > | | > | class?
| > | | > | 
| > | | > 
| > | | 
| > | 
| > 
| 


Reply | Threaded
Open this post in threaded view
|

Re: two strings with same constituents compare as not equal

Dale Henrichs
Bruce,

The tODE that you probably tried was running in a web browser?

The current incarnation of tODE is an outgrowth of a project called topez[1] (screenshot and Smalltalks 2012 talk video). Instead of using a web browser, I'm using Pharo1.4, so as a developer, you can have a multi-window environment ... there's also an "object shell" (the topez bit) where all of the "files" are actually objects and the scripting language is Smalltalk ... it's a shell because you run commands with a CLI ....

With this incarnation I really feel that I've been able to accomplish a number of the goals that I set out to achieve with the web-based variants....

I would say that tODE is currently in a pre-alpha state ... I'm using it daily in my development but it needs a handful of features to make it complete.

Dale

[1] https://github.com/dalehenrich/topez/blob/master/README.md

----- Original Message -----
| From: "Bruce Prior" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Cc: "Dale Henrichs" <[hidden email]>
| Sent: Saturday, February 23, 2013 12:01:53 PM
| Subject: Re: [GS/SS Beta] two strings with same constituents compare as not equal
|
| Hi Dale,
|
| I have tried tODE and found it fascinating. Here is my vote for "getting
| it in shape for general use."
|
| Bruce Prior
|
| On 2013-02-22 4:28 PM, Dale Henrichs wrote:
| > I might have to try harder to find the bug in GemTools...or better yet get
| > tODE in shape for general use ...
| >
| > Dale
| >
| > ----- Original Message -----
| > | From: "Paul DeBruicker" <[hidden email]>
| > | To: "GemStone Seaside beta discussion" <[hidden email]>
| > | Sent: Friday, February 22, 2013 3:26:34 PM
| > | Subject: Re: [GS/SS Beta] two strings with same constituents compare as
| > | not equal
| > |
| > | Thanks Dale.  It was odd to me that they had the same integer value and
| > | didn't compare as equal.  But I could easily have just been misreading
| > | it.
| > |
| > |
| > |
| > |
| > | On 02/22/2013 03:07 PM, Dale Henrichs wrote:
| > | > Paul,
| > | >
| > | > When I tried it again, I got the right answer in GemTools, so I may
| > | > have
| > | > been dreaming that the inspector lied to me ... When a test string is
| > | > embedded in a method I use #withSqueakLineEndings or
| > | > (#withGemstoneLineEndings) to coerce both strings to use the same line
| > | > ending convention ...
| > | >
| > | > Dale
| > | >
| > | > ----- Original Message -----
| > | > | From: "Dale Henrichs" <[hidden email]>
| > | > | To: "GemStone Seaside beta discussion" <[hidden email]>
| > | > | Sent: Friday, February 22, 2013 2:39:49 PM
| > | > | Subject: Re: [GS/SS Beta] two strings with same constituents compare
| > | > | as
| > | > | not equal
| > | > |
| > | > | Paul,
| > | > |
| > | > | The problem has to do with differences between the line end character
| > | > | used in
| > | > | Gemstone and Pharo...
| > | > |
| > | > | Strings in methods will typically end up a Character lf in GemStone
| > | > | and a
| > | > | Character cr in Pharo while the generated Streams will end up
| > | > | Character
| > | > | cr
| > | > | (since it is explictly added by the code) ... at some level it is
| > | > | just
| > | > | happenstance that the tests work in Pharo ...
| > | > |
| > | > | I'm a bit surprised to see that the inspector reported Character cr,
| > | > | but
| > | > | explicitly grabbing the characters and comparing the integer values
| > | > | revealed
| > | > | the problem (when I saw that the String was embedded in the method I
| > | > | knew
| > | > | that the line end character had to be the culprit):
| > | > |
| > | > |   | x y z |
| > | > |   y := Array new.
| > | > |   z := Array new.
| > | > |   expected do: [:each |y add:  each asInteger].
| > | > |   actual do: [:each | z add: each asInteger].
| > | > |   x := {y. z. }.
| > | > |
| > | > | The fact that the debugger showed Character cr is a new bug ... in
| > | > | the
| > | > | past I
| > | > | didn't have to resort to the asInteger trick to identify the problem,
| > | > | so
| > | > | I'll have to dig around a bit to see who's lying ...
| > | > |
| > | > | I wish tODE was ready as a replacement for GemTools, but it's not
| > | > | quite
| > | > | ready
| > | > | yet ...
| > | > |
| > | > | Dale
| > | > |
| > | > | ----- Original Message -----
| > | > | | From: "Paul DeBruicker" <[hidden email]>
| > | > | | To: "GemStone Seaside beta discussion" <[hidden email]>
| > | > | | Sent: Friday, February 22, 2013 9:05:22 AM
| > | > | | Subject: Re: [GS/SS Beta] two strings with same constituents
| > | > | | compare as
| > | > | | not
| > | > | | equal
| > | > | |
| > | > | | Hi Dale,
| > | > | |
| > | > | | I uploaded an extent here:
| > | > | | http://dl.dropbox.com/u/4460862/ical-test-for-dale.dbf
| > | > | |
| > | > | | Its from a 3.1.0.1 extent from the install script on
| > | > | | seaside.gemstone.com with no updates to GLASS applied.
| > | > | |
| > | > | |
| > | > | | One test that exhibits the issue is this one:
| > | > | | ICConversion>>testParseString
| > | > | |
| > | > | | some of the others also have the same problem including:
| > | > | | ICVCardTest>>testParseSurendar
| > | > | | ICVCardTest>>testParseOscar
| > | > | |
| > | > | | Also I have some squeak compatability methods I'll upload soon.
| > | > | |
| > | > | |
| > | > | | Thanks for taking a look.
| > | > | |
| > | > | |
| > | > | | Paul
| > | > | |
| > | > | |
| > | > | |
| > | > | | On 02/22/2013 07:58 AM, Dale Henrichs wrote:
| > | > | | > Paul,
| > | > | | >
| > | > | | > That shouldn't happen ...
| > | > | | >
| > | > | | > I'd like to get my hands on one of those boys...
| > | > | | >
| > | > | | > I have seen cases when porting tests from Pharo where Strings and
| > | > | | > Symbols
| > | > | | > get used interchangeably (Strings and Symbols compare #= in Pharo
| > | > | | > and
| > | > | | > not
| > | > | | > in GemStone ... according to ANSI String and Symbols should not
| > | > | | > compare
| > | > | | > #=) causing the tests to fail miserably ...
| > | > | | >
| > | > | | > Dale
| > | > | | >
| > | > | | > ----- Original Message -----
| > | > | | > | From: "Paul DeBruicker" <[hidden email]>
| > | > | | > | To: "GemStone Seaside beta discussion"
| > | > | | > | <[hidden email]>
| > | > | | > | Sent: Friday, February 22, 2013 7:48:16 AM
| > | > | | > | Subject: [GS/SS Beta] two strings with same constituents
| > | > | | > | compare as
| > | > | | > | not
| > | > | | > | equal
| > | > | | > |
| > | > | | > | Why would two strings in a test method compare as not equal
| > | > | | > | when,
| > | > | | > | if
| > | > | | > | you
| > | > | | > | explore them they have the same characters and are of the same
| > | > | | > | class?
| > | > | | > |
| > | > | | >
| > | > | |
| > | > |
| > | >
| > |
| >
|
|
Reply | Threaded
Open this post in threaded view
|

Re: two strings with same constituents compare as not equal

bprior
Hi Dale,

Yes, I was running tODE in a web browser. But I have now watched your 2012 talk video and can see that there's another perhaps better way. I'll have a look at it. Thanks for all your effort; you have expanded the scope of my thinking about smalltalk.

Bruce
 
On 2013-02-24 8:01 AM, Dale Henrichs wrote:
Bruce,

The tODE that you probably tried was running in a web browser? 

The current incarnation of tODE is an outgrowth of a project called topez[1] (screenshot and Smalltalks 2012 talk video). Instead of using a web browser, I'm using Pharo1.4, so as a developer, you can have a multi-window environment ... there's also an "object shell" (the topez bit) where all of the "files" are actually objects and the scripting language is Smalltalk ... it's a shell because you run commands with a CLI .... 

With this incarnation I really feel that I've been able to accomplish a number of the goals that I set out to achieve with the web-based variants....

I would say that tODE is currently in a pre-alpha state ... I'm using it daily in my development but it needs a handful of features to make it complete.

Dale

[1] https://github.com/dalehenrich/topez/blob/master/README.md

----- Original Message -----
| From: "Bruce Prior" [hidden email]
| To: "GemStone Seaside beta discussion" [hidden email]
| Cc: "Dale Henrichs" [hidden email]
| Sent: Saturday, February 23, 2013 12:01:53 PM
| Subject: Re: [GS/SS Beta] two strings with same constituents compare as not equal
| 
| Hi Dale,
| 
| I have tried tODE and found it fascinating. Here is my vote for "getting
| it in shape for general use."
| 
| Bruce Prior
| 
| On 2013-02-22 4:28 PM, Dale Henrichs wrote:
| > I might have to try harder to find the bug in GemTools...or better yet get
| > tODE in shape for general use ...
| >
| > Dale
| >
| > ----- Original Message -----
| > | From: "Paul DeBruicker" [hidden email]
| > | To: "GemStone Seaside beta discussion" [hidden email]
| > | Sent: Friday, February 22, 2013 3:26:34 PM
| > | Subject: Re: [GS/SS Beta] two strings with same constituents compare as
| > | not equal
| > |
| > | Thanks Dale.  It was odd to me that they had the same integer value and
| > | didn't compare as equal.  But I could easily have just been misreading
| > | it.
| > |
| > |
| > |
| > |
| > | On 02/22/2013 03:07 PM, Dale Henrichs wrote:
| > | > Paul,
| > | >
| > | > When I tried it again, I got the right answer in GemTools, so I may
| > | > have
| > | > been dreaming that the inspector lied to me ... When a test string is
| > | > embedded in a method I use #withSqueakLineEndings or
| > | > (#withGemstoneLineEndings) to coerce both strings to use the same line
| > | > ending convention ...
| > | >
| > | > Dale
| > | >
| > | > ----- Original Message -----
| > | > | From: "Dale Henrichs" [hidden email]
| > | > | To: "GemStone Seaside beta discussion" [hidden email]
| > | > | Sent: Friday, February 22, 2013 2:39:49 PM
| > | > | Subject: Re: [GS/SS Beta] two strings with same constituents compare
| > | > | as
| > | > | not equal
| > | > |
| > | > | Paul,
| > | > |
| > | > | The problem has to do with differences between the line end character
| > | > | used in
| > | > | Gemstone and Pharo...
| > | > |
| > | > | Strings in methods will typically end up a Character lf in GemStone
| > | > | and a
| > | > | Character cr in Pharo while the generated Streams will end up
| > | > | Character
| > | > | cr
| > | > | (since it is explictly added by the code) ... at some level it is
| > | > | just
| > | > | happenstance that the tests work in Pharo ...
| > | > |
| > | > | I'm a bit surprised to see that the inspector reported Character cr,
| > | > | but
| > | > | explicitly grabbing the characters and comparing the integer values
| > | > | revealed
| > | > | the problem (when I saw that the String was embedded in the method I
| > | > | knew
| > | > | that the line end character had to be the culprit):
| > | > |
| > | > |   | x y z |
| > | > |   y := Array new.
| > | > |   z := Array new.
| > | > |   expected do: [:each |y add:  each asInteger].
| > | > |   actual do: [:each | z add: each asInteger].
| > | > |   x := {y. z. }.
| > | > |
| > | > | The fact that the debugger showed Character cr is a new bug ... in
| > | > | the
| > | > | past I
| > | > | didn't have to resort to the asInteger trick to identify the problem,
| > | > | so
| > | > | I'll have to dig around a bit to see who's lying ...
| > | > |
| > | > | I wish tODE was ready as a replacement for GemTools, but it's not
| > | > | quite
| > | > | ready
| > | > | yet ...
| > | > |
| > | > | Dale
| > | > |
| > | > | ----- Original Message -----
| > | > | | From: "Paul DeBruicker" [hidden email]
| > | > | | To: "GemStone Seaside beta discussion" [hidden email]
| > | > | | Sent: Friday, February 22, 2013 9:05:22 AM
| > | > | | Subject: Re: [GS/SS Beta] two strings with same constituents
| > | > | | compare as
| > | > | | not
| > | > | | equal
| > | > | |
| > | > | | Hi Dale,
| > | > | |
| > | > | | I uploaded an extent here:
| > | > | | http://dl.dropbox.com/u/4460862/ical-test-for-dale.dbf
| > | > | |
| > | > | | Its from a 3.1.0.1 extent from the install script on
| > | > | | seaside.gemstone.com with no updates to GLASS applied.
| > | > | |
| > | > | |
| > | > | | One test that exhibits the issue is this one:
| > | > | | ICConversion>>testParseString
| > | > | |
| > | > | | some of the others also have the same problem including:
| > | > | | ICVCardTest>>testParseSurendar
| > | > | | ICVCardTest>>testParseOscar
| > | > | |
| > | > | | Also I have some squeak compatability methods I'll upload soon.
| > | > | |
| > | > | |
| > | > | | Thanks for taking a look.
| > | > | |
| > | > | |
| > | > | | Paul
| > | > | |
| > | > | |
| > | > | |
| > | > | | On 02/22/2013 07:58 AM, Dale Henrichs wrote:
| > | > | | > Paul,
| > | > | | >
| > | > | | > That shouldn't happen ...
| > | > | | >
| > | > | | > I'd like to get my hands on one of those boys...
| > | > | | >
| > | > | | > I have seen cases when porting tests from Pharo where Strings and
| > | > | | > Symbols
| > | > | | > get used interchangeably (Strings and Symbols compare #= in Pharo
| > | > | | > and
| > | > | | > not
| > | > | | > in GemStone ... according to ANSI String and Symbols should not
| > | > | | > compare
| > | > | | > #=) causing the tests to fail miserably ...
| > | > | | >
| > | > | | > Dale
| > | > | | >
| > | > | | > ----- Original Message -----
| > | > | | > | From: "Paul DeBruicker" [hidden email]
| > | > | | > | To: "GemStone Seaside beta discussion"
| > | > | | > | [hidden email]
| > | > | | > | Sent: Friday, February 22, 2013 7:48:16 AM
| > | > | | > | Subject: [GS/SS Beta] two strings with same constituents
| > | > | | > | compare as
| > | > | | > | not
| > | > | | > | equal
| > | > | | > |
| > | > | | > | Why would two strings in a test method compare as not equal
| > | > | | > | when,
| > | > | | > | if
| > | > | | > | you
| > | > | | > | explore them they have the same characters and are of the same
| > | > | | > | class?
| > | > | | > |
| > | > | | >
| > | > | |
| > | > |
| > | >
| > |
| >
| 
| 


Reply | Threaded
Open this post in threaded view
|

Re: two strings with same constituents compare as not equal

NorbertHartl
In reply to this post by Dale Henrichs

Am 24.02.2013 um 17:01 schrieb Dale Henrichs <[hidden email]>:

> Bruce,
>
> The tODE that you probably tried was running in a web browser?
>
> The current incarnation of tODE is an outgrowth of a project called topez[1] (screenshot and Smalltalks 2012 talk video). Instead of using a web browser, I'm using Pharo1.4, so as a developer, you can have a multi-window environment ... there's also an "object shell" (the topez bit) where all of the "files" are actually objects and the scripting language is Smalltalk ... it's a shell because you run commands with a CLI ....
>
> With this incarnation I really feel that I've been able to accomplish a number of the goals that I set out to achieve with the web-based variants....
>
> I would say that tODE is currently in a pre-alpha state ... I'm using it daily in my development but it needs a handful of features to make it complete.
>
Dale,

how does topez/tode compare to gemtools when it comes to roundtrip times (windows et. al)? You know the Omnibrowser stuff takes away the fun of using gemtools being sooo chatty.

Norbert

> Dale
>
> [1] https://github.com/dalehenrich/topez/blob/master/README.md
>
> ----- Original Message -----
> | From: "Bruce Prior" <[hidden email]>
> | To: "GemStone Seaside beta discussion" <[hidden email]>
> | Cc: "Dale Henrichs" <[hidden email]>
> | Sent: Saturday, February 23, 2013 12:01:53 PM
> | Subject: Re: [GS/SS Beta] two strings with same constituents compare as not equal
> |
> | Hi Dale,
> |
> | I have tried tODE and found it fascinating. Here is my vote for "getting
> | it in shape for general use."
> |
> | Bruce Prior
> |
> | On 2013-02-22 4:28 PM, Dale Henrichs wrote:
> | > I might have to try harder to find the bug in GemTools...or better yet get
> | > tODE in shape for general use ...
> | >
> | > Dale
> | >
> | > ----- Original Message -----
> | > | From: "Paul DeBruicker" <[hidden email]>
> | > | To: "GemStone Seaside beta discussion" <[hidden email]>
> | > | Sent: Friday, February 22, 2013 3:26:34 PM
> | > | Subject: Re: [GS/SS Beta] two strings with same constituents compare as
> | > | not equal
> | > |
> | > | Thanks Dale.  It was odd to me that they had the same integer value and
> | > | didn't compare as equal.  But I could easily have just been misreading
> | > | it.
> | > |
> | > |
> | > |
> | > |
> | > | On 02/22/2013 03:07 PM, Dale Henrichs wrote:
> | > | > Paul,
> | > | >
> | > | > When I tried it again, I got the right answer in GemTools, so I may
> | > | > have
> | > | > been dreaming that the inspector lied to me ... When a test string is
> | > | > embedded in a method I use #withSqueakLineEndings or
> | > | > (#withGemstoneLineEndings) to coerce both strings to use the same line
> | > | > ending convention ...
> | > | >
> | > | > Dale
> | > | >
> | > | > ----- Original Message -----
> | > | > | From: "Dale Henrichs" <[hidden email]>
> | > | > | To: "GemStone Seaside beta discussion" <[hidden email]>
> | > | > | Sent: Friday, February 22, 2013 2:39:49 PM
> | > | > | Subject: Re: [GS/SS Beta] two strings with same constituents compare
> | > | > | as
> | > | > | not equal
> | > | > |
> | > | > | Paul,
> | > | > |
> | > | > | The problem has to do with differences between the line end character
> | > | > | used in
> | > | > | Gemstone and Pharo...
> | > | > |
> | > | > | Strings in methods will typically end up a Character lf in GemStone
> | > | > | and a
> | > | > | Character cr in Pharo while the generated Streams will end up
> | > | > | Character
> | > | > | cr
> | > | > | (since it is explictly added by the code) ... at some level it is
> | > | > | just
> | > | > | happenstance that the tests work in Pharo ...
> | > | > |
> | > | > | I'm a bit surprised to see that the inspector reported Character cr,
> | > | > | but
> | > | > | explicitly grabbing the characters and comparing the integer values
> | > | > | revealed
> | > | > | the problem (when I saw that the String was embedded in the method I
> | > | > | knew
> | > | > | that the line end character had to be the culprit):
> | > | > |
> | > | > |   | x y z |
> | > | > |   y := Array new.
> | > | > |   z := Array new.
> | > | > |   expected do: [:each |y add:  each asInteger].
> | > | > |   actual do: [:each | z add: each asInteger].
> | > | > |   x := {y. z. }.
> | > | > |
> | > | > | The fact that the debugger showed Character cr is a new bug ... in
> | > | > | the
> | > | > | past I
> | > | > | didn't have to resort to the asInteger trick to identify the problem,
> | > | > | so
> | > | > | I'll have to dig around a bit to see who's lying ...
> | > | > |
> | > | > | I wish tODE was ready as a replacement for GemTools, but it's not
> | > | > | quite
> | > | > | ready
> | > | > | yet ...
> | > | > |
> | > | > | Dale
> | > | > |
> | > | > | ----- Original Message -----
> | > | > | | From: "Paul DeBruicker" <[hidden email]>
> | > | > | | To: "GemStone Seaside beta discussion" <[hidden email]>
> | > | > | | Sent: Friday, February 22, 2013 9:05:22 AM
> | > | > | | Subject: Re: [GS/SS Beta] two strings with same constituents
> | > | > | | compare as
> | > | > | | not
> | > | > | | equal
> | > | > | |
> | > | > | | Hi Dale,
> | > | > | |
> | > | > | | I uploaded an extent here:
> | > | > | | http://dl.dropbox.com/u/4460862/ical-test-for-dale.dbf
> | > | > | |
> | > | > | | Its from a 3.1.0.1 extent from the install script on
> | > | > | | seaside.gemstone.com with no updates to GLASS applied.
> | > | > | |
> | > | > | |
> | > | > | | One test that exhibits the issue is this one:
> | > | > | | ICConversion>>testParseString
> | > | > | |
> | > | > | | some of the others also have the same problem including:
> | > | > | | ICVCardTest>>testParseSurendar
> | > | > | | ICVCardTest>>testParseOscar
> | > | > | |
> | > | > | | Also I have some squeak compatability methods I'll upload soon.
> | > | > | |
> | > | > | |
> | > | > | | Thanks for taking a look.
> | > | > | |
> | > | > | |
> | > | > | | Paul
> | > | > | |
> | > | > | |
> | > | > | |
> | > | > | | On 02/22/2013 07:58 AM, Dale Henrichs wrote:
> | > | > | | > Paul,
> | > | > | | >
> | > | > | | > That shouldn't happen ...
> | > | > | | >
> | > | > | | > I'd like to get my hands on one of those boys...
> | > | > | | >
> | > | > | | > I have seen cases when porting tests from Pharo where Strings and
> | > | > | | > Symbols
> | > | > | | > get used interchangeably (Strings and Symbols compare #= in Pharo
> | > | > | | > and
> | > | > | | > not
> | > | > | | > in GemStone ... according to ANSI String and Symbols should not
> | > | > | | > compare
> | > | > | | > #=) causing the tests to fail miserably ...
> | > | > | | >
> | > | > | | > Dale
> | > | > | | >
> | > | > | | > ----- Original Message -----
> | > | > | | > | From: "Paul DeBruicker" <[hidden email]>
> | > | > | | > | To: "GemStone Seaside beta discussion"
> | > | > | | > | <[hidden email]>
> | > | > | | > | Sent: Friday, February 22, 2013 7:48:16 AM
> | > | > | | > | Subject: [GS/SS Beta] two strings with same constituents
> | > | > | | > | compare as
> | > | > | | > | not
> | > | > | | > | equal
> | > | > | | > |
> | > | > | | > | Why would two strings in a test method compare as not equal
> | > | > | | > | when,
> | > | > | | > | if
> | > | > | | > | you
> | > | > | | > | explore them they have the same characters and are of the same
> | > | > | | > | class?
> | > | > | | > |
> | > | > | | >
> | > | > | |
> | > | > |
> | > | >
> | > |
> | >
> |
> |

Reply | Threaded
Open this post in threaded view
|

Re: two strings with same constituents compare as not equal

Dale Henrichs
Norbert,

topez/tode is built from the ground up to be frugal with round trips.

topez/tode over the WAN feels like GemTools over the LAN...topez/tode over the LAN is pretty snappy ...

Dale

----- Original Message -----
| From: "Norbert Hartl" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Monday, February 25, 2013 12:53:16 AM
| Subject: Re: [GS/SS Beta] two strings with same constituents compare as not equal
|
|
| Am 24.02.2013 um 17:01 schrieb Dale Henrichs <[hidden email]>:
|
| > Bruce,
| >
| > The tODE that you probably tried was running in a web browser?
| >
| > The current incarnation of tODE is an outgrowth of a project called
| > topez[1] (screenshot and Smalltalks 2012 talk video). Instead of using a
| > web browser, I'm using Pharo1.4, so as a developer, you can have a
| > multi-window environment ... there's also an "object shell" (the topez
| > bit) where all of the "files" are actually objects and the scripting
| > language is Smalltalk ... it's a shell because you run commands with a CLI
| > ....
| >
| > With this incarnation I really feel that I've been able to accomplish a
| > number of the goals that I set out to achieve with the web-based
| > variants....
| >
| > I would say that tODE is currently in a pre-alpha state ... I'm using it
| > daily in my development but it needs a handful of features to make it
| > complete.
| >
| Dale,
|
| how does topez/tode compare to gemtools when it comes to roundtrip times
| (windows et. al)? You know the Omnibrowser stuff takes away the fun of using
| gemtools being sooo chatty.
|
| Norbert
|
| > Dale
| >
| > [1] https://github.com/dalehenrich/topez/blob/master/README.md
| >
| > ----- Original Message -----
| > | From: "Bruce Prior" <[hidden email]>
| > | To: "GemStone Seaside beta discussion" <[hidden email]>
| > | Cc: "Dale Henrichs" <[hidden email]>
| > | Sent: Saturday, February 23, 2013 12:01:53 PM
| > | Subject: Re: [GS/SS Beta] two strings with same constituents compare as
| > | not equal
| > |
| > | Hi Dale,
| > |
| > | I have tried tODE and found it fascinating. Here is my vote for "getting
| > | it in shape for general use."
| > |
| > | Bruce Prior
| > |
| > | On 2013-02-22 4:28 PM, Dale Henrichs wrote:
| > | > I might have to try harder to find the bug in GemTools...or better yet
| > | > get
| > | > tODE in shape for general use ...
| > | >
| > | > Dale
| > | >
| > | > ----- Original Message -----
| > | > | From: "Paul DeBruicker" <[hidden email]>
| > | > | To: "GemStone Seaside beta discussion" <[hidden email]>
| > | > | Sent: Friday, February 22, 2013 3:26:34 PM
| > | > | Subject: Re: [GS/SS Beta] two strings with same constituents compare
| > | > | as
| > | > | not equal
| > | > |
| > | > | Thanks Dale.  It was odd to me that they had the same integer value
| > | > | and
| > | > | didn't compare as equal.  But I could easily have just been
| > | > | misreading
| > | > | it.
| > | > |
| > | > |
| > | > |
| > | > |
| > | > | On 02/22/2013 03:07 PM, Dale Henrichs wrote:
| > | > | > Paul,
| > | > | >
| > | > | > When I tried it again, I got the right answer in GemTools, so I may
| > | > | > have
| > | > | > been dreaming that the inspector lied to me ... When a test string
| > | > | > is
| > | > | > embedded in a method I use #withSqueakLineEndings or
| > | > | > (#withGemstoneLineEndings) to coerce both strings to use the same
| > | > | > line
| > | > | > ending convention ...
| > | > | >
| > | > | > Dale
| > | > | >
| > | > | > ----- Original Message -----
| > | > | > | From: "Dale Henrichs" <[hidden email]>
| > | > | > | To: "GemStone Seaside beta discussion"
| > | > | > | <[hidden email]>
| > | > | > | Sent: Friday, February 22, 2013 2:39:49 PM
| > | > | > | Subject: Re: [GS/SS Beta] two strings with same constituents
| > | > | > | compare
| > | > | > | as
| > | > | > | not equal
| > | > | > |
| > | > | > | Paul,
| > | > | > |
| > | > | > | The problem has to do with differences between the line end
| > | > | > | character
| > | > | > | used in
| > | > | > | Gemstone and Pharo...
| > | > | > |
| > | > | > | Strings in methods will typically end up a Character lf in
| > | > | > | GemStone
| > | > | > | and a
| > | > | > | Character cr in Pharo while the generated Streams will end up
| > | > | > | Character
| > | > | > | cr
| > | > | > | (since it is explictly added by the code) ... at some level it is
| > | > | > | just
| > | > | > | happenstance that the tests work in Pharo ...
| > | > | > |
| > | > | > | I'm a bit surprised to see that the inspector reported Character
| > | > | > | cr,
| > | > | > | but
| > | > | > | explicitly grabbing the characters and comparing the integer
| > | > | > | values
| > | > | > | revealed
| > | > | > | the problem (when I saw that the String was embedded in the
| > | > | > | method I
| > | > | > | knew
| > | > | > | that the line end character had to be the culprit):
| > | > | > |
| > | > | > |   | x y z |
| > | > | > |   y := Array new.
| > | > | > |   z := Array new.
| > | > | > |   expected do: [:each |y add:  each asInteger].
| > | > | > |   actual do: [:each | z add: each asInteger].
| > | > | > |   x := {y. z. }.
| > | > | > |
| > | > | > | The fact that the debugger showed Character cr is a new bug ...
| > | > | > | in
| > | > | > | the
| > | > | > | past I
| > | > | > | didn't have to resort to the asInteger trick to identify the
| > | > | > | problem,
| > | > | > | so
| > | > | > | I'll have to dig around a bit to see who's lying ...
| > | > | > |
| > | > | > | I wish tODE was ready as a replacement for GemTools, but it's not
| > | > | > | quite
| > | > | > | ready
| > | > | > | yet ...
| > | > | > |
| > | > | > | Dale
| > | > | > |
| > | > | > | ----- Original Message -----
| > | > | > | | From: "Paul DeBruicker" <[hidden email]>
| > | > | > | | To: "GemStone Seaside beta discussion"
| > | > | > | | <[hidden email]>
| > | > | > | | Sent: Friday, February 22, 2013 9:05:22 AM
| > | > | > | | Subject: Re: [GS/SS Beta] two strings with same constituents
| > | > | > | | compare as
| > | > | > | | not
| > | > | > | | equal
| > | > | > | |
| > | > | > | | Hi Dale,
| > | > | > | |
| > | > | > | | I uploaded an extent here:
| > | > | > | | http://dl.dropbox.com/u/4460862/ical-test-for-dale.dbf
| > | > | > | |
| > | > | > | | Its from a 3.1.0.1 extent from the install script on
| > | > | > | | seaside.gemstone.com with no updates to GLASS applied.
| > | > | > | |
| > | > | > | |
| > | > | > | | One test that exhibits the issue is this one:
| > | > | > | | ICConversion>>testParseString
| > | > | > | |
| > | > | > | | some of the others also have the same problem including:
| > | > | > | | ICVCardTest>>testParseSurendar
| > | > | > | | ICVCardTest>>testParseOscar
| > | > | > | |
| > | > | > | | Also I have some squeak compatability methods I'll upload soon.
| > | > | > | |
| > | > | > | |
| > | > | > | | Thanks for taking a look.
| > | > | > | |
| > | > | > | |
| > | > | > | | Paul
| > | > | > | |
| > | > | > | |
| > | > | > | |
| > | > | > | | On 02/22/2013 07:58 AM, Dale Henrichs wrote:
| > | > | > | | > Paul,
| > | > | > | | >
| > | > | > | | > That shouldn't happen ...
| > | > | > | | >
| > | > | > | | > I'd like to get my hands on one of those boys...
| > | > | > | | >
| > | > | > | | > I have seen cases when porting tests from Pharo where Strings
| > | > | > | | > and
| > | > | > | | > Symbols
| > | > | > | | > get used interchangeably (Strings and Symbols compare #= in
| > | > | > | | > Pharo
| > | > | > | | > and
| > | > | > | | > not
| > | > | > | | > in GemStone ... according to ANSI String and Symbols should
| > | > | > | | > not
| > | > | > | | > compare
| > | > | > | | > #=) causing the tests to fail miserably ...
| > | > | > | | >
| > | > | > | | > Dale
| > | > | > | | >
| > | > | > | | > ----- Original Message -----
| > | > | > | | > | From: "Paul DeBruicker" <[hidden email]>
| > | > | > | | > | To: "GemStone Seaside beta discussion"
| > | > | > | | > | <[hidden email]>
| > | > | > | | > | Sent: Friday, February 22, 2013 7:48:16 AM
| > | > | > | | > | Subject: [GS/SS Beta] two strings with same constituents
| > | > | > | | > | compare as
| > | > | > | | > | not
| > | > | > | | > | equal
| > | > | > | | > |
| > | > | > | | > | Why would two strings in a test method compare as not equal
| > | > | > | | > | when,
| > | > | > | | > | if
| > | > | > | | > | you
| > | > | > | | > | explore them they have the same characters and are of the
| > | > | > | | > | same
| > | > | > | | > | class?
| > | > | > | | > |
| > | > | > | | >
| > | > | > | |
| > | > | > |
| > | > | >
| > | > |
| > | >
| > |
| > |
|