Comment #1 on issue 3439 by [hidden email]: Compiler error 'subscript is out of bounds: ...' http://code.google.com/p/pharo/issues/detail?id=3439 Seriously, debugging this part of the Parser is a nightmare... There isn't a single comment, there isn't a single SUnit TestCase, there are plenty of variables holding source position states, and plenty of methods with side effects mutating these states. How anyone correcting a bug concerning hereMark could reasonably think he didn't create another one? Such code is caviar to functional programming guys, so that they can tell us stateful is evil! From what I see here, I just can't tell the contrary. _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #2 on issue 3439 by [hidden email]: Compiler error 'subscript is out of bounds: ...' http://code.google.com/p/pharo/issues/detail?id=3439 I've found an acid test which usually works for me: Could I write a sensible comment for this without the chance of accidentally uttering "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn"? If not, mark as CANTFIX _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #3 on issue 3439 by [hidden email]: Compiler error 'subscript is out of bounds: ...' http://code.google.com/p/pharo/issues/detail?id=3439 OK, I posted a proof of concept last night in Squeak inbox http://source.squeak.org/inbox/Tests-nice.144.mcz See http://permalink.gmane.org/gmane.comp.lang.smalltalk.squeak.general/161056 It does apply to interactive notifications inserted in TextEditor, but a subclass could easily handle case of SyntaxError (notifying: nil). The TestCase documents what we could wish (after agreement), not necessarily what does really happen in current Compiler state, so some tests are failing already. Anyone can now try to hack the instance variables mark/hereMark/prevMark/hereEnd/prevEnd or the messages endOfLastToken , offEnd: , expected: , notify: , notify:at: and their senders and measure his own improvements / regressions score. Good luck, my score so far is quite low ;) _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #4 on issue 3439 by [hidden email]: Compiler error 'subscript is out of bounds: ...' http://code.google.com/p/pharo/issues/detail?id=3439 Ah Ah, I posted previous comment too fast, because I just remembered one simple clean-up idea I had tonight that produces just the effects I would have expected :) Together with a protection of insertion point in SyntaxError, that should solve the issue once ported to Pharo (despite the old compiler might be a few versions off). Nicolas Cellier uploaded a new version of Compiler to project The Trunk: http://source.squeak.org/trunk/Compiler-nice.225.mcz ==================== Summary ==================== Name: Compiler-nice.225 Author: nice Time: 22 February 2012, 2:57:07.872 pm UUID: 77bbb3ac-e939-4975-a139-f785dc94c17a Ancestors: Compiler-nice.224 Remove the ugly hack in Parser>>expected: which was modifying the error message insertion mark depending on the fact that we were at end of token stream a,d/or end of source character stream. Replace it with a proper mark in Scanner>>scanToken that correctly take into account the two step of advance handled by the Scanner (stateful is harmful and require high precision surgery). While at it, set the error insertion mark after the $ character when offended by Scanner>>xDollar. This efficiently reduce the number of failures reported by CompilerNotifyngTest in its Tests-nice.144 version. =============== Diff against Compiler-nice.224 =============== Item was changed: ----- Method: Parser>>expected: (in category 'error handling') ----- expected: aString "Notify a problem at token 'here'." - tokenType == #doIt ifTrue: [hereMark := hereMark + 1]. - hereType == #doIt ifTrue: [hereMark := hereMark + 1]. ^ self notify: aString , ' expected' at: hereMark + requestorOffset! Item was changed: ----- Method: Scanner>>scanToken (in category 'expression types') ----- scanToken [(tokenType := self typeTableAt: hereChar) == #xDelimiter] whileTrue: [self step]. "Skip delimiters fast, there almost always is one." mark := aheadChar == DoItCharacter + ifTrue: [hereChar == DoItCharacter + ifTrue: [source position + 1] + ifFalse: [source position]] - ifTrue: [source position] ifFalse: [source position - 1]. (tokenType at: 1) == $x "x as first letter" ifTrue: [self perform: tokenType "means perform to compute token & type"] ifFalse: [token := self step asSymbol "else just unique the first char"]. ^token! Item was changed: ----- Method: Scanner>>xDollar (in category 'multi-character scans') ----- xDollar "Form a Character literal." + aheadChar == DoItCharacter + ifTrue: + [mark := mark + 1. "Let the notification lie behind the dollar" + ^self offEnd: 'A Character was expected']. - aheadChar == DoItCharacter ifTrue: [^self offEnd: 'A Character was expected']. self step. "pass over $" token := self step. tokenType := #character! _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #5 on issue 3439 by [hidden email]: Compiler error 'subscript is out of bounds: ...' http://code.google.com/p/pharo/issues/detail?id=3439 With above changes, Squeak trunk can now safely evaluate Object compile: 'self foo. [' without requiring any additional defensive guard in SyntaxError. So I'll try a port to Pharo 1.4. Backporting to previous Pharo is another subject, but is it vital? _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #6 on issue 3439 by [hidden email]: Compiler error 'subscript is out of bounds: ...' http://code.google.com/p/pharo/issues/detail?id=3439 Unfortunately, these changes would conflict with Issue 4650. I will thus defer resolution after integration of above issue. _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Updates:
Status: FixReviewNeeded Labels: Type-Bug Milestone-1.4 Comment #7 on issue 3439 by [hidden email]: Compiler error 'subscript is out of bounds: ...' http://code.google.com/p/pharo/issues/detail?id=3439 Name: SLICE-Issue-3439-Compiler-error-subscript-is-out-of-bounds-nice.1 Dependencies: Compiler-nice.317, CompilerTests-nice.100 This solves the issue http://code.google.com/p/pharo/issues/detail?id=3439 and provides a bunch of test documenting our expectations about Compiler notifications - what is the expected notification text - where it should be inserted in source This SLICE also includes the fix for http://code.google.com/p/pharo/issues/detail?id=4650 because the changes are overlapping. _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #8 on issue 3439 by [hidden email]: Compiler error 'subscript is out of bounds: ...' http://code.google.com/p/pharo/issues/detail?id=3439 I posted a second slice because the first had an accidental TestCase subclass removal _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #9 on issue 3439 by [hidden email]: Compiler error 'subscript is out of bounds: ...' http://code.google.com/p/pharo/issues/detail?id=3439 Of course, this solve only one part of the problem, because there is another bug in issue 5366 _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #10 on issue 3439 by [hidden email]: Compiler error 'subscript is out of bounds: ...' http://code.google.com/p/pharo/issues/detail?id=3439 Issue 4650 has been merged into this issue. _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Updates:
Status: Integrated Comment #11 on issue 3439 by [hidden email]: Compiler error 'subscript is out of bounds: ...' http://code.google.com/p/pharo/issues/detail?id=3439 in 14353 _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Free forum by Nabble | Edit this page |