On Mon, Apr 25, 2016 at 4:03 AM, Stephan Eggermont <step...@stack.nl> 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. cheers -ben
