[Pharo 5] Symbol #'distance_2pts' not accepted at package installation

> On 24 Apr 2016, at 12:10, Hilaire <[hidden email]> wrote:
>
> Hi Nicolai,
>
> http://smalltalkhub.com/#!/~HilaireFernandes/DrGeo
>
> You can't use the installation procedure described in the wiki, because
> Pharo5 also got stuck when loading a dependent package (gettext package
> to name it).
> You should manually load the DrGeoII-Core package, then DrGeoII-Polymoprh
>
> The problem occurs when loading DrGeoII-Core.
>
> Hilaire
>
>
>
> Le 24/04/2016 11:41, Nicolai Hess a écrit :
>>
>> Hi Hilaire,
>>
>> can you point me to the repository where this DrGeo package is.
>>
>>
>
> --
> Dr. Geo
> http://drgeo.eu
>
>

> You should manually load the DrGeoII-Core package, then DrGeoII-Polymoprh
>
> The problem occurs when loading DrGeoII-Core.
>
> Hilaire
>
>
>
> Le 24/04/2016 11:41, Nicolai Hess a écrit :
>> Hi Hilaire,
>>
>> can you point me to the repository where this DrGeo package is.
>>
>>  

>
>
> Le 24/4/16 à 12:10, Hilaire a écrit :
>> Hi Nicolai,
>>
>> http://smalltalkhub.com/#!/~HilaireFernandes/DrGeo
>>
>> You can't use the installation procedure described in the wiki, because
>> Pharo5 also got stuck when loading a dependent package (gettext package
>> to name it).
> From where do you load gettext because I can have a look.
> Your work is important to me :)

> On 24-04-16 21:35, stepharo wrote:
>>
>>
>>
>> Le 24/4/16 à 12:10, Hilaire a écrit :
>>>
>>> Hi Nicolai,
>>>
>>> http://smalltalkhub.com/#!/~HilaireFernandes/DrGeo
>>>
>>> You can't use the installation procedure described in the wiki, because
>>> Pharo5 also got stuck when loading a dependent package (gettext package
>>> to name it).
>>
>> From where do you load gettext because I can have a look.
>> Your work is important to me :)
>
>
> It is a simple, but annoying problem. A symbol with whitespace between the
> # and the literal is no longer accepted by RBScanner>scanLiteral

>
> scanLiteral
>     "Do not allow whitespace between # and the literal."
>
>     "Do not allow number literals after the #"
>
>     self step.
>     characterType = #alphabetic
>         ifTrue: [ ^ self scanSymbol ].
>     characterType = #binary
>         ifTrue:
>             [ ^ (self scanBinary: RBLiteralToken)
>                 stop: self previousStepPosition ].
>     currentCharacter = $'
>         ifTrue: [ ^ self scanStringSymbol ].
>     (currentCharacter = $( or: [ currentCharacter = $[ ])
>         ifTrue: [ ^ self scanLiteralArrayToken ].
>     "Accept multiple #."
>     currentCharacter = $#
>         ifTrue: [ ^ self scanLiteral ].
>     ^ self scanError: 'Expecting a literal type'
>
> vs
>
> scanLiteral
>     self step.
>     self stripSeparators.
>     characterType = #alphabetic
>         ifTrue: [ ^ self scanSymbol ].
>     characterType = #binary
>         ifTrue: [ ^ (self scanBinary: RBLiteralToken) stop: self
> previousStepPosition ].
>     currentCharacter = $'
>         ifTrue: [ ^ self scanStringSymbol ].
>     (currentCharacter = $( or: [ currentCharacter = $[ ])
>         ifTrue: [ ^ self scanLiteralArrayToken].
>     "Accept some strange literals like '#1', '# species' and '##species:'"
>     characterType = #digit
>         ifTrue: [ ^ self scanNumber ].
>     currentCharacter = $#
>         ifTrue: [ ^ self scanLiteral ].
>     ^self scanError: 'Expecting a literal type' translated.
>
> The problem is that recovering from that while loading code asks for
> rather well-developed debugging skills... It is faster to just load the code
> in an old Pharo image, fix it there and commit a new version

> On Mon, Apr 25, 2016 at 4:03 AM, Stephan Eggermont <[hidden email]> wrote:
>> On 24-04-16 21:35, stepharo wrote:
>>>
>>>
>>>
>>> Le 24/4/16 à 12:10, Hilaire a écrit :
>>>>
>>>> Hi Nicolai,
>>>>
>>>> http://smalltalkhub.com/#!/~HilaireFernandes/DrGeo
>>>>
>>>> You can't use the installation procedure described in the wiki, because
>>>> Pharo5 also got stuck when loading a dependent package (gettext package
>>>> to name it).
>>>
>>> From where do you load gettext because I can have a look.
>>> Your work is important to me :)
>>
>>
>> It is a simple, but annoying problem. A symbol with whitespace between the
>> # and the literal is no longer accepted by RBScanner>scanLiteral
>
> That seems a bad regression, to break loading code that
> loads fine with Pharo 4, and could be a common scenario.
>
>>
>> scanLiteral
>>     "Do not allow whitespace between # and the literal."
>>
>>     "Do not allow number literals after the #"
>>
>>     self step.
>>     characterType = #alphabetic
>>         ifTrue: [ ^ self scanSymbol ].
>>     characterType = #binary
>>         ifTrue:
>>             [ ^ (self scanBinary: RBLiteralToken)
>>                 stop: self previousStepPosition ].
>>     currentCharacter = $'
>>         ifTrue: [ ^ self scanStringSymbol ].
>>     (currentCharacter = $( or: [ currentCharacter = $[ ])
>>         ifTrue: [ ^ self scanLiteralArrayToken ].
>>     "Accept multiple #."
>>     currentCharacter = $#
>>         ifTrue: [ ^ self scanLiteral ].
>>     ^ self scanError: 'Expecting a literal type'
>>
>> vs
>>
>> scanLiteral
>>     self step.
>>     self stripSeparators.
>>     characterType = #alphabetic
>>         ifTrue: [ ^ self scanSymbol ].
>>     characterType = #binary
>>         ifTrue: [ ^ (self scanBinary: RBLiteralToken) stop: self
>> previousStepPosition ].
>>     currentCharacter = $'
>>         ifTrue: [ ^ self scanStringSymbol ].
>>     (currentCharacter = $( or: [ currentCharacter = $[ ])
>>         ifTrue: [ ^ self scanLiteralArrayToken].
>>     "Accept some strange literals like '#1', '# species' and '##species:'"
>>     characterType = #digit
>>         ifTrue: [ ^ self scanNumber ].
>>     currentCharacter = $#
>>         ifTrue: [ ^ self scanLiteral ].
>>     ^self scanError: 'Expecting a literal type' translated.
>>
>> The problem is that recovering from that while loading code asks for
>> rather well-developed debugging skills... It is faster to just load the code
>> in an old Pharo image, fix it there and commit a new version
>
> Wouldn't you then have the problem of manually tracking down
> that space in your codebase ?
>
> Is it feasible to have a setting for compatibility so old code can at
> least be loaded in Pharo 5? Then a re-compilation with setting
> disabled would directly identify the error to be fixed.   Maybe even
> Monticello could always temporarily enable the setting while loading -
> with that behaviour removed for Pharo 6.