[IMPORTANT] Is there a bug in Tonel with category:

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

[IMPORTANT] Is there a bug in Tonel with category:

Stephane Ducasse-3
Hi

I was working in cleaning the users of asLayoutFrame and when I commit I see

- #category : 'Morphic-Base-Layouts'
+ #category : #Morphic-Base-Layouts

but #category : #Morphic-Base-Layouts
is not a valid symbol.

So is it a bug?

Stef

Reply | Threaded
Open this post in threaded view
|

Re: [IMPORTANT] Is there a bug in Tonel with category:

Stephan Eggermont-3
On 05-11-17 22:05, Stephane Ducasse wrote:
> I was working in cleaning the users of asLayoutFrame and when I commit I see
>
> - #category : 'Morphic-Base-Layouts'
> + #category : #Morphic-Base-Layouts
>
> but #category : #Morphic-Base-Layouts
> is not a valid symbol.

In Metacello we use the quoted symbol form exactly because different
smalltalks have different ideas of what a valid symbol is.

Stephan



Reply | Threaded
Open this post in threaded view
|

Re: [IMPORTANT] Is there a bug in Tonel with category:

Dale Henrichs-3
...also note that I have seen a number of baselines where symbols are
used in places where Strings are required ... of course with Pharo's
implementation of Symbol it is not practical to use asString nor type
checks - things that are not necessary in other Smalltalk
implementations ... In Metacello the only "legal" place to use a Symbol
is for a symbolic version ...

Of course this is really only an issue for cross platform projects and
the issue shows up as a problem real fast ... it's just painful for the
uninitiated to debug ...

Dale


On 11/6/17 1:51 AM, stephan wrote:

> On 05-11-17 22:05, Stephane Ducasse wrote:
>> I was working in cleaning the users of asLayoutFrame and when I
>> commit I see
>>
>> - #category : 'Morphic-Base-Layouts'
>> + #category : #Morphic-Base-Layouts
>>
>> but #category : #Morphic-Base-Layouts
>> is not a valid symbol.
>
> In Metacello we use the quoted symbol form exactly because different
> smalltalks have different ideas of what a valid symbol is.
>
> Stephan
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: [IMPORTANT] Is there a bug in Tonel with category:

Sven Van Caekenberghe-2


> On 6 Nov 2017, at 15:43, Dale Henrichs <[hidden email]> wrote:
>
> of course with Pharo's implementation of Symbol it is not practical to use asString nor type checks - things that are not necessary in other Smalltalk implementations

How so ?

What is the problem with Symbol>>#asString ?

#foo asString => 'foo'
#'foo-bar' asString => 'foo-bar'

Sven
Reply | Threaded
Open this post in threaded view
|

Re: [IMPORTANT] Is there a bug in Tonel with category:

Dale Henrichs-3


On 11/6/17 7:07 AM, Sven Van Caekenberghe wrote:
>
>> On 6 Nov 2017, at 15:43, Dale Henrichs <[hidden email]> wrote:
>>
>> of course with Pharo's implementation of Symbol it is not practical to use asString nor type checks - things that are not necessary in other Smalltalk implementations
> How so ?
>
> What is the problem with Symbol>>#asString ?
I am not going to go to every field in the api that is supposed to be a
String and add asString. There are too many places to worry about ... I
would prefer that Pharo be ANSI compliant:)

It's not just Metacello.

It's an annoying issue that has to be dealt with every time a Pharo
application is ported to another dialect of Smalltalk and an annoying
barrier for folks running on other dialects to move their application to
Pharo - in this case the bugs that are introduced by Pharo's behavior
with respect to Symbols can be very hard to diagnose --

Making things harder to share code between dialects is a bad thing for
Smalltalk overall -- just another reason for non-Smalltalk programmers
to question the whether they should use Smalltalk or not...

And I don't need to hear about how Pharo is not Smalltalk:)

Dale

Reply | Threaded
Open this post in threaded view
|

Re: [IMPORTANT] Is there a bug in Tonel with category:

Sven Van Caekenberghe-2


> On 6 Nov 2017, at 17:13, Dale Henrichs <[hidden email]> wrote:
>
>
>
> On 11/6/17 7:07 AM, Sven Van Caekenberghe wrote:
>>
>>> On 6 Nov 2017, at 15:43, Dale Henrichs <[hidden email]> wrote:
>>>
>>> of course with Pharo's implementation of Symbol it is not practical to use asString nor type checks - things that are not necessary in other Smalltalk implementations
>> How so ?
>>
>> What is the problem with Symbol>>#asString ?
> I am not going to go to every field in the api that is supposed to be a String and add asString. There are too many places to worry about ... I would prefer that Pharo be ANSI compliant:)
>
> It's not just Metacello.
>
> It's an annoying issue that has to be dealt with every time a Pharo application is ported to another dialect of Smalltalk and an annoying barrier for folks running on other dialects to move their application to Pharo - in this case the bugs that are introduced by Pharo's behavior with respect to Symbols can be very hard to diagnose --
>
> Making things harder to share code between dialects is a bad thing for Smalltalk overall -- just another reason for non-Smalltalk programmers to question the whether they should use Smalltalk or not...
>
> And I don't need to hear about how Pharo is not Smalltalk:)
>
> Dale

So there is nothing 'wrong', you just want Pharo to remain the same as every other non-changing Smalltalk out there.

From one perspective you are right, it makes some cross platform porting in either direction harder. Seaside has many rules to help portability. Not mixing Strings and Symbol is probably one of them.

But you know very well that Pharo was started so that we would be able to make changes, in any area or aspect of the system, without the burden of backwards or cross platform compatibility, even if some of these changes are taste based.

And I happen to like the ability to mix and match Strings and Symbols (we discussed about this before).

Sven



Reply | Threaded
Open this post in threaded view
|

Re: [IMPORTANT] Is there a bug in Tonel with category:

Nicolas Cellier


2017-11-06 17:23 GMT+01:00 Sven Van Caekenberghe <[hidden email]>:


> On 6 Nov 2017, at 17:13, Dale Henrichs <[hidden email]> wrote:
>
>
>
> On 11/6/17 7:07 AM, Sven Van Caekenberghe wrote:
>>
>>> On 6 Nov 2017, at 15:43, Dale Henrichs <[hidden email]> wrote:
>>>
>>> of course with Pharo's implementation of Symbol it is not practical to use asString nor type checks - things that are not necessary in other Smalltalk implementations
>> How so ?
>>
>> What is the problem with Symbol>>#asString ?
> I am not going to go to every field in the api that is supposed to be a String and add asString. There are too many places to worry about ... I would prefer that Pharo be ANSI compliant:)
>
> It's not just Metacello.
>
> It's an annoying issue that has to be dealt with every time a Pharo application is ported to another dialect of Smalltalk and an annoying barrier for folks running on other dialects to move their application to Pharo - in this case the bugs that are introduced by Pharo's behavior with respect to Symbols can be very hard to diagnose --
>
> Making things harder to share code between dialects is a bad thing for Smalltalk overall -- just another reason for non-Smalltalk programmers to question the whether they should use Smalltalk or not...
>
> And I don't need to hear about how Pharo is not Smalltalk:)
>
> Dale

So there is nothing 'wrong', you just want Pharo to remain the same as every other non-changing Smalltalk out there.

From one perspective you are right, it makes some cross platform porting in either direction harder. Seaside has many rules to help portability. Not mixing Strings and Symbol is probably one of them.

But you know very well that Pharo was started so that we would be able to make changes, in any area or aspect of the system, without the burden of backwards or cross platform compatibility, even if some of these changes are taste based.

And I happen to like the ability to mix and match Strings and Symbols (we discussed about this before).

Sven



Note that it's not entirely Pharo's fault.
#foo = 'foo' in Squeak too.

Reply | Threaded
Open this post in threaded view
|

Re: [IMPORTANT] Is there a bug in Tonel with category:

Ben Coman
In reply to this post by Dale Henrichs-3
Can this be dealt with by Quality Assistant?  Special rules when in a particular group of classes? i.e. BaselineXXXXX

cheers -ben

On Mon, Nov 6, 2017 at 10:43 PM, Dale Henrichs <[hidden email]> wrote:
...also note that I have seen a number of baselines where symbols are used in places where Strings are required ... of course with Pharo's implementation of Symbol it is not practical to use asString nor type checks - things that are not necessary in other Smalltalk implementations ... In Metacello the only "legal" place to use a Symbol is for a symbolic version ...

Of course this is really only an issue for cross platform projects and the issue shows up as a problem real fast ... it's just painful for the uninitiated to debug ...

Dale



On 11/6/17 1:51 AM, stephan wrote:
On 05-11-17 22:05, Stephane Ducasse wrote:
I was working in cleaning the users of asLayoutFrame and when I commit I see

- #category : 'Morphic-Base-Layouts'
+ #category : #Morphic-Base-Layouts

but #category : #Morphic-Base-Layouts
is not a valid symbol.

In Metacello we use the quoted symbol form exactly because different smalltalks have different ideas of what a valid symbol is.

Stephan






Reply | Threaded
Open this post in threaded view
|

Re: [IMPORTANT] Is there a bug in Tonel with category:

Sven Van Caekenberghe-2
In reply to this post by Nicolas Cellier


> On 6 Nov 2017, at 17:25, Nicolas Cellier <[hidden email]> wrote:
>
>
>
> 2017-11-06 17:23 GMT+01:00 Sven Van Caekenberghe <[hidden email]>:
>
>
> > On 6 Nov 2017, at 17:13, Dale Henrichs <[hidden email]> wrote:
> >
> >
> >
> > On 11/6/17 7:07 AM, Sven Van Caekenberghe wrote:
> >>
> >>> On 6 Nov 2017, at 15:43, Dale Henrichs <[hidden email]> wrote:
> >>>
> >>> of course with Pharo's implementation of Symbol it is not practical to use asString nor type checks - things that are not necessary in other Smalltalk implementations
> >> How so ?
> >>
> >> What is the problem with Symbol>>#asString ?
> > I am not going to go to every field in the api that is supposed to be a String and add asString. There are too many places to worry about ... I would prefer that Pharo be ANSI compliant:)
> >
> > It's not just Metacello.
> >
> > It's an annoying issue that has to be dealt with every time a Pharo application is ported to another dialect of Smalltalk and an annoying barrier for folks running on other dialects to move their application to Pharo - in this case the bugs that are introduced by Pharo's behavior with respect to Symbols can be very hard to diagnose --
> >
> > Making things harder to share code between dialects is a bad thing for Smalltalk overall -- just another reason for non-Smalltalk programmers to question the whether they should use Smalltalk or not...
> >
> > And I don't need to hear about how Pharo is not Smalltalk:)
> >
> > Dale
>
> So there is nothing 'wrong', you just want Pharo to remain the same as every other non-changing Smalltalk out there.
>
> From one perspective you are right, it makes some cross platform porting in either direction harder. Seaside has many rules to help portability. Not mixing Strings and Symbol is probably one of them.
>
> But you know very well that Pharo was started so that we would be able to make changes, in any area or aspect of the system, without the burden of backwards or cross platform compatibility, even if some of these changes are taste based.
>
> And I happen to like the ability to mix and match Strings and Symbols (we discussed about this before).
>
> Sven
>
>
>
> Note that it's not entirely Pharo's fault.
> #foo = 'foo' in Squeak too.

It is neither Squeak's 'fault'.

It is a choice, just like you prefer #<=> over our #threeWayCompareTo:

There are valid reasons for such choices, if a community choses or prefers one way or the other it is not a fault, it is a feature.
Reply | Threaded
Open this post in threaded view
|

Re: [IMPORTANT] Is there a bug in Tonel with category:

Nicolas Cellier


2017-11-06 18:20 GMT+01:00 Sven Van Caekenberghe <[hidden email]>:


> On 6 Nov 2017, at 17:25, Nicolas Cellier <[hidden email]> wrote:
>
>
>
> 2017-11-06 17:23 GMT+01:00 Sven Van Caekenberghe <[hidden email]>:
>
>
> > On 6 Nov 2017, at 17:13, Dale Henrichs <[hidden email]> wrote:
> >
> >
> >
> > On 11/6/17 7:07 AM, Sven Van Caekenberghe wrote:
> >>
> >>> On 6 Nov 2017, at 15:43, Dale Henrichs <[hidden email]> wrote:
> >>>
> >>> of course with Pharo's implementation of Symbol it is not practical to use asString nor type checks - things that are not necessary in other Smalltalk implementations
> >> How so ?
> >>
> >> What is the problem with Symbol>>#asString ?
> > I am not going to go to every field in the api that is supposed to be a String and add asString. There are too many places to worry about ... I would prefer that Pharo be ANSI compliant:)
> >
> > It's not just Metacello.
> >
> > It's an annoying issue that has to be dealt with every time a Pharo application is ported to another dialect of Smalltalk and an annoying barrier for folks running on other dialects to move their application to Pharo - in this case the bugs that are introduced by Pharo's behavior with respect to Symbols can be very hard to diagnose --
> >
> > Making things harder to share code between dialects is a bad thing for Smalltalk overall -- just another reason for non-Smalltalk programmers to question the whether they should use Smalltalk or not...
> >
> > And I don't need to hear about how Pharo is not Smalltalk:)
> >
> > Dale
>
> So there is nothing 'wrong', you just want Pharo to remain the same as every other non-changing Smalltalk out there.
>
> From one perspective you are right, it makes some cross platform porting in either direction harder. Seaside has many rules to help portability. Not mixing Strings and Symbol is probably one of them.
>
> But you know very well that Pharo was started so that we would be able to make changes, in any area or aspect of the system, without the burden of backwards or cross platform compatibility, even if some of these changes are taste based.
>
> And I happen to like the ability to mix and match Strings and Symbols (we discussed about this before).
>
> Sven
>
>
>
> Note that it's not entirely Pharo's fault.
> #foo = 'foo' in Squeak too.

It is neither Squeak's 'fault'.

It is a choice, just like you prefer #<=> over our #threeWayCompareTo:

There are valid reasons for such choices, if a community choses or prefers one way or the other it is not a fault, it is a feature.

Agree, the POV is: Symbol are just special String optimized for space.
But then one must assume the cost of hischoices and provide appropriate transforms for communicating with external world.
If a file exchange format or cross platform package specification requires a String, it's his responsability to provide a String...
I shouldn't change the ston format just because it would ease some implementation in Squeak, should I?
Reply | Threaded
Open this post in threaded view
|

Re: [IMPORTANT] Is there a bug in Tonel with category:

Dale Henrichs-3
In reply to this post by Sven Van Caekenberghe-2


On 11/06/2017 08:23 AM, Sven Van Caekenberghe wrote:

>
>> On 6 Nov 2017, at 17:13, Dale Henrichs <[hidden email]> wrote:
>>
>>
>>
>> On 11/6/17 7:07 AM, Sven Van Caekenberghe wrote:
>>>> On 6 Nov 2017, at 15:43, Dale Henrichs <[hidden email]> wrote:
>>>>
>>>> of course with Pharo's implementation of Symbol it is not practical to use asString nor type checks - things that are not necessary in other Smalltalk implementations
>>> How so ?
>>>
>>> What is the problem with Symbol>>#asString ?
>> I am not going to go to every field in the api that is supposed to be a String and add asString. There are too many places to worry about ... I would prefer that Pharo be ANSI compliant:)
>>
>> It's not just Metacello.
>>
>> It's an annoying issue that has to be dealt with every time a Pharo application is ported to another dialect of Smalltalk and an annoying barrier for folks running on other dialects to move their application to Pharo - in this case the bugs that are introduced by Pharo's behavior with respect to Symbols can be very hard to diagnose --
>>
>> Making things harder to share code between dialects is a bad thing for Smalltalk overall -- just another reason for non-Smalltalk programmers to question the whether they should use Smalltalk or not...
>>
>> And I don't need to hear about how Pharo is not Smalltalk:)
>>
>> Dale
> So there is nothing 'wrong', you just want Pharo to remain the same as every other non-changing Smalltalk out there.
Did I say that?

I support the direction that Pharo is going, but I reserve the right to
disagree with some of the details.

This is just one detail ... nothing more nothing less ... For those of
us that work in multiple dialects, it IS annoying and I take an
opportunity every year or so to remind you guys of the things that I
find annoying, just to keep you guys honest:)

>
>  From one perspective you are right, it makes some cross platform porting in either direction harder. Seaside has many rules to help portability. Not mixing Strings and Symbol is probably one of them.
... and as I mentioned, this problem can be one of the more annoying
issues to track down, when a developer is not careful ... Honestly there
are two sides to the issue ... when developers use Symbols in tests to
drive an API that is supposed to use Strings (this happens the most
often) things break pretty quickly and the tests can be fixed pretty
easily ... but when the code itself is written with mixed Symbols and
Strings, the tests might actually pass after the port, and the bugs will
only show up in subtle cases ... I've hit a handful of these over the
years and they are hard to track down...
>
> But you know very well that Pharo was started so that we would be able to make changes, in any area or aspect of the system, without the burden of backwards or cross platform compatibility, even if some of these changes are taste based.
Agree with your statement -- most of the changes that Pharo has made
have not been difficult to accommodate, but Symbol/String is at a
fundamental level and I'm not sure that it would be "illegal" to make
this accommodation --- I AM pretty certain that it would cause some
short term pain, but probably no more pain (and likely less pain) than
is caused by  trying to move an application to a new version of Pharo:)
> And I happen to like the ability to mix and match Strings and Symbols (we discussed about this before).
>
I won't argue with taste, it's is simply the portability for this
particular problem that I am highlighting ...

Dale

Reply | Threaded
Open this post in threaded view
|

Re: [IMPORTANT] Is there a bug in Tonel with category:

Stephane Ducasse-3
Esteban told me that this is because he uses STON for the class definition.
Now a simple question may be we could use a string instead of a symbol
because this is strange
to have a class definitino that does not respect Pharo syntax.

Stef

On Mon, Nov 6, 2017 at 8:15 PM, Dale Henrichs
<[hidden email]> wrote:

>
>
> On 11/06/2017 08:23 AM, Sven Van Caekenberghe wrote:
>>
>>
>>> On 6 Nov 2017, at 17:13, Dale Henrichs <[hidden email]>
>>> wrote:
>>>
>>>
>>>
>>> On 11/6/17 7:07 AM, Sven Van Caekenberghe wrote:
>>>>>
>>>>> On 6 Nov 2017, at 15:43, Dale Henrichs
>>>>> <[hidden email]> wrote:
>>>>>
>>>>> of course with Pharo's implementation of Symbol it is not practical to
>>>>> use asString nor type checks - things that are not necessary in other
>>>>> Smalltalk implementations
>>>>
>>>> How so ?
>>>>
>>>> What is the problem with Symbol>>#asString ?
>>>
>>> I am not going to go to every field in the api that is supposed to be a
>>> String and add asString. There are too many places to worry about ... I
>>> would prefer that Pharo be ANSI compliant:)
>>>
>>> It's not just Metacello.
>>>
>>> It's an annoying issue that has to be dealt with every time a Pharo
>>> application is ported to another dialect of Smalltalk and an annoying
>>> barrier for folks running on other dialects to move their application to
>>> Pharo - in this case the bugs that are introduced by Pharo's behavior with
>>> respect to Symbols can be very hard to diagnose --
>>>
>>> Making things harder to share code between dialects is a bad thing for
>>> Smalltalk overall -- just another reason for non-Smalltalk programmers to
>>> question the whether they should use Smalltalk or not...
>>>
>>> And I don't need to hear about how Pharo is not Smalltalk:)
>>>
>>> Dale
>>
>> So there is nothing 'wrong', you just want Pharo to remain the same as
>> every other non-changing Smalltalk out there.
>
> Did I say that?
>
> I support the direction that Pharo is going, but I reserve the right to
> disagree with some of the details.
>
> This is just one detail ... nothing more nothing less ... For those of us
> that work in multiple dialects, it IS annoying and I take an opportunity
> every year or so to remind you guys of the things that I find annoying, just
> to keep you guys honest:)
>
>>
>>  From one perspective you are right, it makes some cross platform porting
>> in either direction harder. Seaside has many rules to help portability. Not
>> mixing Strings and Symbol is probably one of them.
>
> ... and as I mentioned, this problem can be one of the more annoying issues
> to track down, when a developer is not careful ... Honestly there are two
> sides to the issue ... when developers use Symbols in tests to drive an API
> that is supposed to use Strings (this happens the most often) things break
> pretty quickly and the tests can be fixed pretty easily ... but when the
> code itself is written with mixed Symbols and Strings, the tests might
> actually pass after the port, and the bugs will only show up in subtle cases
> ... I've hit a handful of these over the years and they are hard to track
> down...
>>
>>
>> But you know very well that Pharo was started so that we would be able to
>> make changes, in any area or aspect of the system, without the burden of
>> backwards or cross platform compatibility, even if some of these changes are
>> taste based.
>
> Agree with your statement -- most of the changes that Pharo has made have
> not been difficult to accommodate, but Symbol/String is at a fundamental
> level and I'm not sure that it would be "illegal" to make this accommodation
> --- I AM pretty certain that it would cause some short term pain, but
> probably no more pain (and likely less pain) than is caused by  trying to
> move an application to a new version of Pharo:)
>>
>> And I happen to like the ability to mix and match Strings and Symbols (we
>> discussed about this before).
>>
> I won't argue with taste, it's is simply the portability for this particular
> problem that I am highlighting ...
>
> Dale
>

Reply | Threaded
Open this post in threaded view
|

Re: [IMPORTANT] Is there a bug in Tonel with category:

Sven Van Caekenberghe-2


> On 6 Nov 2017, at 20:52, Stephane Ducasse <[hidden email]> wrote:
>
> Esteban told me that this is because he uses STON for the class definition.
> Now a simple question may be we could use a string instead of a symbol
> because this is strange
> to have a class definitino that does not respect Pharo syntax.

It might be a bit confusing at first sight, but it is correct, IMHO.

It is STON syntax, not Pharo.

Yes, STON is a bit more liberal with Symbols than normal Smalltalk, but it is totally consistent with itself.

STON fromString: (STON toString: #'My Strange Symbol').
STON fromString: (STON toString: #'foo-bar').

If a Symbol consists only of characters in 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_./' then the Symbol does not need to be quoted in STON.

I see no problem there.

> Stef
>
> On Mon, Nov 6, 2017 at 8:15 PM, Dale Henrichs
> <[hidden email]> wrote:
>>
>>
>> On 11/06/2017 08:23 AM, Sven Van Caekenberghe wrote:
>>>
>>>
>>>> On 6 Nov 2017, at 17:13, Dale Henrichs <[hidden email]>
>>>> wrote:
>>>>
>>>>
>>>>
>>>> On 11/6/17 7:07 AM, Sven Van Caekenberghe wrote:
>>>>>>
>>>>>> On 6 Nov 2017, at 15:43, Dale Henrichs
>>>>>> <[hidden email]> wrote:
>>>>>>
>>>>>> of course with Pharo's implementation of Symbol it is not practical to
>>>>>> use asString nor type checks - things that are not necessary in other
>>>>>> Smalltalk implementations
>>>>>
>>>>> How so ?
>>>>>
>>>>> What is the problem with Symbol>>#asString ?
>>>>
>>>> I am not going to go to every field in the api that is supposed to be a
>>>> String and add asString. There are too many places to worry about ... I
>>>> would prefer that Pharo be ANSI compliant:)
>>>>
>>>> It's not just Metacello.
>>>>
>>>> It's an annoying issue that has to be dealt with every time a Pharo
>>>> application is ported to another dialect of Smalltalk and an annoying
>>>> barrier for folks running on other dialects to move their application to
>>>> Pharo - in this case the bugs that are introduced by Pharo's behavior with
>>>> respect to Symbols can be very hard to diagnose --
>>>>
>>>> Making things harder to share code between dialects is a bad thing for
>>>> Smalltalk overall -- just another reason for non-Smalltalk programmers to
>>>> question the whether they should use Smalltalk or not...
>>>>
>>>> And I don't need to hear about how Pharo is not Smalltalk:)
>>>>
>>>> Dale
>>>
>>> So there is nothing 'wrong', you just want Pharo to remain the same as
>>> every other non-changing Smalltalk out there.
>>
>> Did I say that?
>>
>> I support the direction that Pharo is going, but I reserve the right to
>> disagree with some of the details.
>>
>> This is just one detail ... nothing more nothing less ... For those of us
>> that work in multiple dialects, it IS annoying and I take an opportunity
>> every year or so to remind you guys of the things that I find annoying, just
>> to keep you guys honest:)
>>
>>>
>>> From one perspective you are right, it makes some cross platform porting
>>> in either direction harder. Seaside has many rules to help portability. Not
>>> mixing Strings and Symbol is probably one of them.
>>
>> ... and as I mentioned, this problem can be one of the more annoying issues
>> to track down, when a developer is not careful ... Honestly there are two
>> sides to the issue ... when developers use Symbols in tests to drive an API
>> that is supposed to use Strings (this happens the most often) things break
>> pretty quickly and the tests can be fixed pretty easily ... but when the
>> code itself is written with mixed Symbols and Strings, the tests might
>> actually pass after the port, and the bugs will only show up in subtle cases
>> ... I've hit a handful of these over the years and they are hard to track
>> down...
>>>
>>>
>>> But you know very well that Pharo was started so that we would be able to
>>> make changes, in any area or aspect of the system, without the burden of
>>> backwards or cross platform compatibility, even if some of these changes are
>>> taste based.
>>
>> Agree with your statement -- most of the changes that Pharo has made have
>> not been difficult to accommodate, but Symbol/String is at a fundamental
>> level and I'm not sure that it would be "illegal" to make this accommodation
>> --- I AM pretty certain that it would cause some short term pain, but
>> probably no more pain (and likely less pain) than is caused by  trying to
>> move an application to a new version of Pharo:)
>>>
>>> And I happen to like the ability to mix and match Strings and Symbols (we
>>> discussed about this before).
>>>
>> I won't argue with taste, it's is simply the portability for this particular
>> problem that I am highlighting ...
>>
>> Dale
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: [IMPORTANT] Is there a bug in Tonel with category:

Denis Kudriashov
In reply to this post by Stephane Ducasse-3

2017-11-06 20:52 GMT+01:00 Stephane Ducasse <[hidden email]>:
Esteban told me that this is because he uses STON for the class definition.
Now a simple question may be we could use a string instead of a symbol
because this is strange
to have a class definitino that does not respect Pharo syntax.

But anyway we are not able to use definition from Tonel in playground. So what the difference?
 

Stef

On Mon, Nov 6, 2017 at 8:15 PM, Dale Henrichs
<[hidden email]> wrote:
>
>
> On 11/06/2017 08:23 AM, Sven Van Caekenberghe wrote:
>>
>>
>>> On 6 Nov 2017, at 17:13, Dale Henrichs <[hidden email]>
>>> wrote:
>>>
>>>
>>>
>>> On 11/6/17 7:07 AM, Sven Van Caekenberghe wrote:
>>>>>
>>>>> On 6 Nov 2017, at 15:43, Dale Henrichs
>>>>> <[hidden email]> wrote:
>>>>>
>>>>> of course with Pharo's implementation of Symbol it is not practical to
>>>>> use asString nor type checks - things that are not necessary in other
>>>>> Smalltalk implementations
>>>>
>>>> How so ?
>>>>
>>>> What is the problem with Symbol>>#asString ?
>>>
>>> I am not going to go to every field in the api that is supposed to be a
>>> String and add asString. There are too many places to worry about ... I
>>> would prefer that Pharo be ANSI compliant:)
>>>
>>> It's not just Metacello.
>>>
>>> It's an annoying issue that has to be dealt with every time a Pharo
>>> application is ported to another dialect of Smalltalk and an annoying
>>> barrier for folks running on other dialects to move their application to
>>> Pharo - in this case the bugs that are introduced by Pharo's behavior with
>>> respect to Symbols can be very hard to diagnose --
>>>
>>> Making things harder to share code between dialects is a bad thing for
>>> Smalltalk overall -- just another reason for non-Smalltalk programmers to
>>> question the whether they should use Smalltalk or not...
>>>
>>> And I don't need to hear about how Pharo is not Smalltalk:)
>>>
>>> Dale
>>
>> So there is nothing 'wrong', you just want Pharo to remain the same as
>> every other non-changing Smalltalk out there.
>
> Did I say that?
>
> I support the direction that Pharo is going, but I reserve the right to
> disagree with some of the details.
>
> This is just one detail ... nothing more nothing less ... For those of us
> that work in multiple dialects, it IS annoying and I take an opportunity
> every year or so to remind you guys of the things that I find annoying, just
> to keep you guys honest:)
>
>>
>>  From one perspective you are right, it makes some cross platform porting
>> in either direction harder. Seaside has many rules to help portability. Not
>> mixing Strings and Symbol is probably one of them.
>
> ... and as I mentioned, this problem can be one of the more annoying issues
> to track down, when a developer is not careful ... Honestly there are two
> sides to the issue ... when developers use Symbols in tests to drive an API
> that is supposed to use Strings (this happens the most often) things break
> pretty quickly and the tests can be fixed pretty easily ... but when the
> code itself is written with mixed Symbols and Strings, the tests might
> actually pass after the port, and the bugs will only show up in subtle cases
> ... I've hit a handful of these over the years and they are hard to track
> down...
>>
>>
>> But you know very well that Pharo was started so that we would be able to
>> make changes, in any area or aspect of the system, without the burden of
>> backwards or cross platform compatibility, even if some of these changes are
>> taste based.
>
> Agree with your statement -- most of the changes that Pharo has made have
> not been difficult to accommodate, but Symbol/String is at a fundamental
> level and I'm not sure that it would be "illegal" to make this accommodation
> --- I AM pretty certain that it would cause some short term pain, but
> probably no more pain (and likely less pain) than is caused by  trying to
> move an application to a new version of Pharo:)
>>
>> And I happen to like the ability to mix and match Strings and Symbols (we
>> discussed about this before).
>>
> I won't argue with taste, it's is simply the portability for this particular
> problem that I am highlighting ...
>
> Dale
>


Reply | Threaded
Open this post in threaded view
|

Re: [IMPORTANT] Is there a bug in Tonel with category:

Dale Henrichs-3
In reply to this post by Dale Henrichs-3
Poster child for the porting pain[1] of symbols and strings - from this
morning:)

The dictionary was created using symbols as the keys, but the code that
I had to change used mixed symbols and strings as keys ... and of course
I was left wondering why the class vars weren't being defined properly ...

Dale

[1]
https://github.com/GsDevKit/tonel/commit/b00565685586630452a9de3d4f90f16571428019#diff-bf8f5ba630dc8c679c3c68668bc76a5e


On 11/6/17 11:15 AM, Dale Henrichs wrote:

>
>
> On 11/06/2017 08:23 AM, Sven Van Caekenberghe wrote:
>>
>>> On 6 Nov 2017, at 17:13, Dale Henrichs
>>> <[hidden email]> wrote:
>>>
>>>
>>>
>>> On 11/6/17 7:07 AM, Sven Van Caekenberghe wrote:
>>>>> On 6 Nov 2017, at 15:43, Dale Henrichs
>>>>> <[hidden email]> wrote:
>>>>>
>>>>> of course with Pharo's implementation of Symbol it is not
>>>>> practical to use asString nor type checks - things that are not
>>>>> necessary in other Smalltalk implementations
>>>> How so ?
>>>>
>>>> What is the problem with Symbol>>#asString ?
>>> I am not going to go to every field in the api that is supposed to
>>> be a String and add asString. There are too many places to worry
>>> about ... I would prefer that Pharo be ANSI compliant:)
>>>
>>> It's not just Metacello.
>>>
>>> It's an annoying issue that has to be dealt with every time a Pharo
>>> application is ported to another dialect of Smalltalk and an
>>> annoying barrier for folks running on other dialects to move their
>>> application to Pharo - in this case the bugs that are introduced by
>>> Pharo's behavior with respect to Symbols can be very hard to
>>> diagnose --
>>>
>>> Making things harder to share code between dialects is a bad thing
>>> for Smalltalk overall -- just another reason for non-Smalltalk
>>> programmers to question the whether they should use Smalltalk or not...
>>>
>>> And I don't need to hear about how Pharo is not Smalltalk:)
>>>
>>> Dale
>> So there is nothing 'wrong', you just want Pharo to remain the same
>> as every other non-changing Smalltalk out there.
> Did I say that?
>
> I support the direction that Pharo is going, but I reserve the right
> to disagree with some of the details.
>
> This is just one detail ... nothing more nothing less ... For those of
> us that work in multiple dialects, it IS annoying and I take an
> opportunity every year or so to remind you guys of the things that I
> find annoying, just to keep you guys honest:)
>
>>
>>  From one perspective you are right, it makes some cross platform
>> porting in either direction harder. Seaside has many rules to help
>> portability. Not mixing Strings and Symbol is probably one of them.
> ... and as I mentioned, this problem can be one of the more annoying
> issues to track down, when a developer is not careful ... Honestly
> there are two sides to the issue ... when developers use Symbols in
> tests to drive an API that is supposed to use Strings (this happens
> the most often) things break pretty quickly and the tests can be fixed
> pretty easily ... but when the code itself is written with mixed
> Symbols and Strings, the tests might actually pass after the port, and
> the bugs will only show up in subtle cases ... I've hit a handful of
> these over the years and they are hard to track down...
>>
>> But you know very well that Pharo was started so that we would be
>> able to make changes, in any area or aspect of the system, without
>> the burden of backwards or cross platform compatibility, even if some
>> of these changes are taste based.
> Agree with your statement -- most of the changes that Pharo has made
> have not been difficult to accommodate, but Symbol/String is at a
> fundamental level and I'm not sure that it would be "illegal" to make
> this accommodation --- I AM pretty certain that it would cause some
> short term pain, but probably no more pain (and likely less pain) than
> is caused by  trying to move an application to a new version of Pharo:)
>> And I happen to like the ability to mix and match Strings and Symbols
>> (we discussed about this before).
>>
> I won't argue with taste, it's is simply the portability for this
> particular problem that I am highlighting ...
>
> Dale


Reply | Threaded
Open this post in threaded view
|

Re: [IMPORTANT] Is there a bug in Tonel with category:

Stephane Ducasse-3
In reply to this post by Sven Van Caekenberghe-2
Sven

I understand but it is SUPER strange to save the code in a format that
does not respect the syntax of the language.
I think that we should write a parser for the class definition or save
category as strings.

I do not want to have to explain to people. Yes and no this is not the
pharo syntax.

Sorry I'm fed up.

Stef

On Mon, Nov 6, 2017 at 10:25 PM, Sven Van Caekenberghe <[hidden email]> wrote:

>
>
>> On 6 Nov 2017, at 20:52, Stephane Ducasse <[hidden email]> wrote:
>>
>> Esteban told me that this is because he uses STON for the class definition.
>> Now a simple question may be we could use a string instead of a symbol
>> because this is strange
>> to have a class definitino that does not respect Pharo syntax.
>
> It might be a bit confusing at first sight, but it is correct, IMHO.
>
> It is STON syntax, not Pharo.
>
> Yes, STON is a bit more liberal with Symbols than normal Smalltalk, but it is totally consistent with itself.
>
> STON fromString: (STON toString: #'My Strange Symbol').
> STON fromString: (STON toString: #'foo-bar').
>
> If a Symbol consists only of characters in 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_./' then the Symbol does not need to be quoted in STON.
>
> I see no problem there.
>
>> Stef
>>
>> On Mon, Nov 6, 2017 at 8:15 PM, Dale Henrichs
>> <[hidden email]> wrote:
>>>
>>>
>>> On 11/06/2017 08:23 AM, Sven Van Caekenberghe wrote:
>>>>
>>>>
>>>>> On 6 Nov 2017, at 17:13, Dale Henrichs <[hidden email]>
>>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 11/6/17 7:07 AM, Sven Van Caekenberghe wrote:
>>>>>>>
>>>>>>> On 6 Nov 2017, at 15:43, Dale Henrichs
>>>>>>> <[hidden email]> wrote:
>>>>>>>
>>>>>>> of course with Pharo's implementation of Symbol it is not practical to
>>>>>>> use asString nor type checks - things that are not necessary in other
>>>>>>> Smalltalk implementations
>>>>>>
>>>>>> How so ?
>>>>>>
>>>>>> What is the problem with Symbol>>#asString ?
>>>>>
>>>>> I am not going to go to every field in the api that is supposed to be a
>>>>> String and add asString. There are too many places to worry about ... I
>>>>> would prefer that Pharo be ANSI compliant:)
>>>>>
>>>>> It's not just Metacello.
>>>>>
>>>>> It's an annoying issue that has to be dealt with every time a Pharo
>>>>> application is ported to another dialect of Smalltalk and an annoying
>>>>> barrier for folks running on other dialects to move their application to
>>>>> Pharo - in this case the bugs that are introduced by Pharo's behavior with
>>>>> respect to Symbols can be very hard to diagnose --
>>>>>
>>>>> Making things harder to share code between dialects is a bad thing for
>>>>> Smalltalk overall -- just another reason for non-Smalltalk programmers to
>>>>> question the whether they should use Smalltalk or not...
>>>>>
>>>>> And I don't need to hear about how Pharo is not Smalltalk:)
>>>>>
>>>>> Dale
>>>>
>>>> So there is nothing 'wrong', you just want Pharo to remain the same as
>>>> every other non-changing Smalltalk out there.
>>>
>>> Did I say that?
>>>
>>> I support the direction that Pharo is going, but I reserve the right to
>>> disagree with some of the details.
>>>
>>> This is just one detail ... nothing more nothing less ... For those of us
>>> that work in multiple dialects, it IS annoying and I take an opportunity
>>> every year or so to remind you guys of the things that I find annoying, just
>>> to keep you guys honest:)
>>>
>>>>
>>>> From one perspective you are right, it makes some cross platform porting
>>>> in either direction harder. Seaside has many rules to help portability. Not
>>>> mixing Strings and Symbol is probably one of them.
>>>
>>> ... and as I mentioned, this problem can be one of the more annoying issues
>>> to track down, when a developer is not careful ... Honestly there are two
>>> sides to the issue ... when developers use Symbols in tests to drive an API
>>> that is supposed to use Strings (this happens the most often) things break
>>> pretty quickly and the tests can be fixed pretty easily ... but when the
>>> code itself is written with mixed Symbols and Strings, the tests might
>>> actually pass after the port, and the bugs will only show up in subtle cases
>>> ... I've hit a handful of these over the years and they are hard to track
>>> down...
>>>>
>>>>
>>>> But you know very well that Pharo was started so that we would be able to
>>>> make changes, in any area or aspect of the system, without the burden of
>>>> backwards or cross platform compatibility, even if some of these changes are
>>>> taste based.
>>>
>>> Agree with your statement -- most of the changes that Pharo has made have
>>> not been difficult to accommodate, but Symbol/String is at a fundamental
>>> level and I'm not sure that it would be "illegal" to make this accommodation
>>> --- I AM pretty certain that it would cause some short term pain, but
>>> probably no more pain (and likely less pain) than is caused by  trying to
>>> move an application to a new version of Pharo:)
>>>>
>>>> And I happen to like the ability to mix and match Strings and Symbols (we
>>>> discussed about this before).
>>>>
>>> I won't argue with taste, it's is simply the portability for this particular
>>> problem that I am highlighting ...
>>>
>>> Dale
>>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [IMPORTANT] Is there a bug in Tonel with category:

Sven Van Caekenberghe-2


> On 8 Nov 2017, at 21:29, Stephane Ducasse <[hidden email]> wrote:
>
> Sven
>
> I understand but it is SUPER strange to save the code in a format that
> does not respect the syntax of the language.
> I think that we should write a parser for the class definition or save
> category as strings.
>
> I do not want to have to explain to people. Yes and no this is not the
> pharo syntax.
>
> Sorry I'm fed up.

Tonel is a mix of different formats. Parts are custom to Tonel (the overall structure), parts are Pharo syntax (the method's source code), parts are STON (the contents of the meta data sections).

Even if we make a change to how the Symbols are represented, it would still not make the meta sections Pharo syntax.

But I do agree it is a bit confusing.

Either we make them all Strings, or I could add an option to STON that allows STONWriter to control what constitutes a 'simple' or 'literal' Symbol.

And we could err on the safe side (like only allow 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789'), because I dare you to look at String>>#isLiteralSymbol it is way more ugly than STON's simple definition (which allows all characters from 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_./').

What is the opinion of the original Tonel designers ?

> Stef
>
> On Mon, Nov 6, 2017 at 10:25 PM, Sven Van Caekenberghe <[hidden email]> wrote:
>>
>>
>>> On 6 Nov 2017, at 20:52, Stephane Ducasse <[hidden email]> wrote:
>>>
>>> Esteban told me that this is because he uses STON for the class definition.
>>> Now a simple question may be we could use a string instead of a symbol
>>> because this is strange
>>> to have a class definitino that does not respect Pharo syntax.
>>
>> It might be a bit confusing at first sight, but it is correct, IMHO.
>>
>> It is STON syntax, not Pharo.
>>
>> Yes, STON is a bit more liberal with Symbols than normal Smalltalk, but it is totally consistent with itself.
>>
>> STON fromString: (STON toString: #'My Strange Symbol').
>> STON fromString: (STON toString: #'foo-bar').
>>
>> If a Symbol consists only of characters in 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_./' then the Symbol does not need to be quoted in STON.
>>
>> I see no problem there.
>>
>>> Stef
>>>
>>> On Mon, Nov 6, 2017 at 8:15 PM, Dale Henrichs
>>> <[hidden email]> wrote:
>>>>
>>>>
>>>> On 11/06/2017 08:23 AM, Sven Van Caekenberghe wrote:
>>>>>
>>>>>
>>>>>> On 6 Nov 2017, at 17:13, Dale Henrichs <[hidden email]>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 11/6/17 7:07 AM, Sven Van Caekenberghe wrote:
>>>>>>>>
>>>>>>>> On 6 Nov 2017, at 15:43, Dale Henrichs
>>>>>>>> <[hidden email]> wrote:
>>>>>>>>
>>>>>>>> of course with Pharo's implementation of Symbol it is not practical to
>>>>>>>> use asString nor type checks - things that are not necessary in other
>>>>>>>> Smalltalk implementations
>>>>>>>
>>>>>>> How so ?
>>>>>>>
>>>>>>> What is the problem with Symbol>>#asString ?
>>>>>>
>>>>>> I am not going to go to every field in the api that is supposed to be a
>>>>>> String and add asString. There are too many places to worry about ... I
>>>>>> would prefer that Pharo be ANSI compliant:)
>>>>>>
>>>>>> It's not just Metacello.
>>>>>>
>>>>>> It's an annoying issue that has to be dealt with every time a Pharo
>>>>>> application is ported to another dialect of Smalltalk and an annoying
>>>>>> barrier for folks running on other dialects to move their application to
>>>>>> Pharo - in this case the bugs that are introduced by Pharo's behavior with
>>>>>> respect to Symbols can be very hard to diagnose --
>>>>>>
>>>>>> Making things harder to share code between dialects is a bad thing for
>>>>>> Smalltalk overall -- just another reason for non-Smalltalk programmers to
>>>>>> question the whether they should use Smalltalk or not...
>>>>>>
>>>>>> And I don't need to hear about how Pharo is not Smalltalk:)
>>>>>>
>>>>>> Dale
>>>>>
>>>>> So there is nothing 'wrong', you just want Pharo to remain the same as
>>>>> every other non-changing Smalltalk out there.
>>>>
>>>> Did I say that?
>>>>
>>>> I support the direction that Pharo is going, but I reserve the right to
>>>> disagree with some of the details.
>>>>
>>>> This is just one detail ... nothing more nothing less ... For those of us
>>>> that work in multiple dialects, it IS annoying and I take an opportunity
>>>> every year or so to remind you guys of the things that I find annoying, just
>>>> to keep you guys honest:)
>>>>
>>>>>
>>>>> From one perspective you are right, it makes some cross platform porting
>>>>> in either direction harder. Seaside has many rules to help portability. Not
>>>>> mixing Strings and Symbol is probably one of them.
>>>>
>>>> ... and as I mentioned, this problem can be one of the more annoying issues
>>>> to track down, when a developer is not careful ... Honestly there are two
>>>> sides to the issue ... when developers use Symbols in tests to drive an API
>>>> that is supposed to use Strings (this happens the most often) things break
>>>> pretty quickly and the tests can be fixed pretty easily ... but when the
>>>> code itself is written with mixed Symbols and Strings, the tests might
>>>> actually pass after the port, and the bugs will only show up in subtle cases
>>>> ... I've hit a handful of these over the years and they are hard to track
>>>> down...
>>>>>
>>>>>
>>>>> But you know very well that Pharo was started so that we would be able to
>>>>> make changes, in any area or aspect of the system, without the burden of
>>>>> backwards or cross platform compatibility, even if some of these changes are
>>>>> taste based.
>>>>
>>>> Agree with your statement -- most of the changes that Pharo has made have
>>>> not been difficult to accommodate, but Symbol/String is at a fundamental
>>>> level and I'm not sure that it would be "illegal" to make this accommodation
>>>> --- I AM pretty certain that it would cause some short term pain, but
>>>> probably no more pain (and likely less pain) than is caused by  trying to
>>>> move an application to a new version of Pharo:)
>>>>>
>>>>> And I happen to like the ability to mix and match Strings and Symbols (we
>>>>> discussed about this before).
>>>>>
>>>> I won't argue with taste, it's is simply the portability for this particular
>>>> problem that I am highlighting ...
>>>>
>>>> Dale
>>>>
>>>
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: [IMPORTANT] Is there a bug in Tonel with category:

Martin McClure-2
On 11/08/2017 01:15 PM, Sven Van Caekenberghe wrote:
> What is the opinion of the original Tonel designers ?

Well, Esteban did the largest part of the work, but I guess I am *one*
of the original designers, in that various design proposals were floated
back and forth, starting with one of mine and ending with Tonel.

My intent is that Tonel, as a declarative cross-platform format, should
use strings exclusively, never Symbols. I *think* I discussed this with
Esteban during ESUG, and I *think* he agreed, so it seems likely that
the current behavior with class definitions is unintentional.

Regards,

-Martin


Reply | Threaded
Open this post in threaded view
|

Re: [IMPORTANT] Is there a bug in Tonel with category:

Nicolas Cellier


2017-11-09 0:52 GMT+01:00 Martin McClure <[hidden email]>:
On 11/08/2017 01:15 PM, Sven Van Caekenberghe wrote:
What is the opinion of the original Tonel designers ?

Well, Esteban did the largest part of the work, but I guess I am *one* of the original designers, in that various design proposals were floated back and forth, starting with one of mine and ending with Tonel.

My intent is that Tonel, as a declarative cross-platform format, should use strings exclusively, never Symbols. I *think* I discussed this with Esteban during ESUG, and I *think* he agreed, so it seems likely that the current behavior with class definitions is unintentional.

Regards,

-Martin


Ah you remind me there's one thing I don't like in this format:
Tonel must be aware of all possible syntax tricks in order to parse the method body...
And that ain't easy


I found that while accidentally reading the code due to




Reply | Threaded
Open this post in threaded view
|

Re: [IMPORTANT] Is there a bug in Tonel with category:

Sven Van Caekenberghe-2
In reply to this post by Martin McClure-2


> On 9 Nov 2017, at 00:52, Martin McClure <[hidden email]> wrote:
>
> On 11/08/2017 01:15 PM, Sven Van Caekenberghe wrote:
>> What is the opinion of the original Tonel designers ?
>
> Well, Esteban did the largest part of the work, but I guess I am *one* of the original designers, in that various design proposals were floated back and forth, starting with one of mine and ending with Tonel.
>
> My intent is that Tonel, as a declarative cross-platform format, should use strings exclusively, never Symbols. I *think* I discussed this with Esteban during ESUG, and I *think* he agreed, so it seems likely that the current behavior with class definitions is unintentional.
>
> Regards,
>
> -Martin

Thanks for your reply, Martin.

Ah, OK, I didn't know that.

Still, since the current Tonel implementation in Pharo uses a custom STONWriter subclass, it is easy to change Symbol printing (not that it is needed, but it would help in appearance).

TonelSTONWriter>>#isSimpleSymbol: symbol
        "Customize STON to only consider very clean symbols as literal,
        for all others err on the safe side and quote them."
       
        symbol isEmpty
                ifTrue: [ ^ false ].
        ('abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ' includes: symbol first)
                ifFalse: [ ^ false ].
        ^ symbol allSatisfy: [ :each |
                'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789' includes: each ]

I would also make the following change

TonelWriter>>#toSTON: anObject
        ^ String streamContents: [ :out |
                        (TonelSTONWriter on: out)
                                newLine: self newLine;
                                nextPut: anObject ]

Sven


12