Thanks for the hint Timothy.


My suggestion is to collect all encoding names manually in Grease 
instead of using TextEncoder class>>allEncodingNames. Despite its name, 
this method only answers the "default" name of each encoding. I don't 
think that's the intended use case we want to support with 
GRGenericPharoEncoder. There, I imagine we'd like to match both 
'mac-roman' and 'macroman'. Manually collecting the encoding names 
allows us to do that.

PR: https://github.com/SeasideSt/Grease/pull/71

BTW: There should really be a message for that on TextEncoder...


Cheers,
Max

On 8 Dec 2018, at 13:00, squeak-dev-request at lists.squeakfoundation.org 
wrote:

> my applogies I accidentally hit send with a control key while 
> attempting to format the chain of reasoning. What this test does is 
> loop through each subclass of GRCodec and asks each one if they 
> support the encoding 'mac-roman' those classes are: GRNullCodec 
> GRPharoGenericCodec GRPharoUtf8Codec GRPharoLatin1Codec The subclasses 
> either hard-code their encodings in the class side 
> supportedEncodingNames method or they define it as a subset of 
> TextConverter allEncodingNames TextConverter allEncodingNames inspect 
> TextConverter allEncodingNames select:[:element | element asString 
> beginsWith:'mac'] Like GRCodec, TextConverter loops through all its 
> subclasses and asks them what to populate its set of names with. The 
> one we want is: MacRomanTextConverter encodingNames If you print that, 
> you see two: #('macroman' 'mac-roman') The issue, is in the 
> TextConverte allEncodingNames method allEncodingNames "TextConverter 
> allEncodingNames" | encodingNames | encodingNames := Set new. self 
> allSubclasses do: [:each | | names | names := each encodingNames. 
> names notEmpty ifTrue: [encodingNames add: names first asSymbol]]. 
> ^encodingNames looking at the ifTrue: block you see it only adds the 
> FIRST name to the set. This could be a bug in TextConverter. Since 
> 'mac-roman' and 'macroman' both point to the same 
> MacRomanTextConverter, it stands to reason that changing the test from 
> 'mac-roman' to 'macroman' is safe. Do that, and the test passes. 
> cheers, t ---- On Wed, 05 Dec 2018 08:33:02 -0500 David T. Lewis 
> <lewis at mail.msen.com> wrote ---- Replying on the squeak-dev list to 
> get some more eyes on the issue. Dave On Tue, Dec 04, 2018 at 
> 10:17:17PM +0100, Johan Brichau wrote: > Hi, > > Two tests are 
> currently still failing for Squeak [1]. > - testNamedTempAt -> fails 
> on travis but works in an interactive image??? dunno what???s going on 
> but it???s an expected failure in Pharo for a long time as well??? > - 
> testGenericCodecMacRoman -> it seems the preferential name for the 
> Mac-Roman encoding became ???macroman??? in Squeak instead of 
> ???mac-roman???. Not sure what to think about this one??? > > Anybody 
> from the Squeak community who wants to step in and check on these? > > 
> cheers > Johan > > > [1] 
> https://travis-ci.org/SeasideSt/Seaside/jobs/463542906 >