Compilation messages on Transcript

Adding the following method to Object:

     testMethod
        ^#(##(7/5) ##(14/5) ##(21/5) ##(28/5) 7 ##(42/5) ##(49/5)
                ##(56/5) ##(63/5) 14 ##(77/5) ##(84/5))

results in the following message being written to the transcript:

     Error 40 on line 2 of Object>>testMethod -> 'no period at end of
statement'

The method is accepted OK and produces the expected result, but I
don't think the message should be written to the Transcript.

Bob Jarvis wrote:

Yes, the parser in D5 appears to have a few issues in this area that D4
didn't have. This will show up just by selecting existing methods in a
browser...

Select AXPropertyBagErrorLog>>supportedInterfaces
        ^#(##(IErrorLog) ##(IEnumErrorInfo))
Error 40 on line 4 of AXPropertyBagErrorLog>>supportedInterfaces -> 'no
period at end of statement'

Select NPApplet>>supportedInterfaces
        ^#(##(INPApplet))
Error 35 on line 4 of NPApplet>>supportedInterfaces -> 'nonsense at end
of method'

I particularly like that last error message.  I'm just surprised that it
hasn't shown up more often on the code that I write. <g>

-------------------------------------------
Bill Dargel            [hidden email]
Shoshana Technologies
100 West Joy Road, Ann Arbor, MI 48105  USA

"Bill Dargel" <[hidden email]> wrote in message
news:[hidden email]...
Actually the main compiler in D5 is almost exactly the same as that in D4 -
it has one or two minor bug fixes, and can inline #ifNil:[#ifNotNil:]
messages, but that is about it. The messages are coming from the
SmalltalkParser, a modified version of the RBParser that emits error
messages that have almost exactly the same form as the Dolphin compiler, and
which can parse Dolphin's external method (FFI) syntax. SmalltalkParser is
unable to parse many ##() expressions. When you select a method in the
browser's the SmalltalkParser is run against it in order to build a parse
tree to assist with the creation of the dynamic refactoring menus.

Unfortunately fixing the RB parser to correct this involves quite
significant changes, and we simply ran out of time. On the whole it should
not cause problems, although it may prevent certain refactorings from
working since the refactoring engine will not be able to rewrite some
methods containing ##() expressions.

>...
> Error 35 on line 4 of NPApplet>>supportedInterfaces -> 'nonsense at end
> of method'
>
> I particularly like that last error message.  I'm just surprised that it
> hasn't shown up more often on the code that I write. <g>

:-).

Regards

Blair

Blair McGlashan wrote:

Thanks for the explanation. Just what's going on, and how the problem got there
in the first place, now makes a whole lot more sense.

Having the RB in the system is great. I really appreciate the work you guys have
done in including it. But, being one of those pesky customers that's never
satisfied ;-) I'm looking forward to any further integration that you might have
planned. Is it in the plans? This parsing of ##() expressions would be one
example.

Another that I noticed is the [in]ability (unless I'm missing something) to
place the cursor on one keyword of a multi-keyword message within a method's
text, and via a context menu immediately go to, for example, the Definitions.
This is something that I really liked in the RB in VW. The alternative here is
to go to the context menu up in the methods list, go to Definitions and then
find the message selector in the presented list. I find this to be a somewhat
distracting break, in that though I'm already focused at the message I'm
interested in, I have to go off and find it again in a list. I guess this is
just one of the perks that could be added now that a parse tree is already
lurking behind the method text.

BTW, while I think of it, finding Definitions of single keyword messages isn't
too bad. Double click on it to highlight the word, shift-right-arrow to include
the ":" and then F12, Enter, and you're there. Is there some place one could
hack the definition of what constitutes a word to include the ":"? Or is it
buried somewhere in a Windows method? Which reminds me, is there any way to fix
the irritating selection behavior when double clicking on the last word in a
String?

Sorry for sounding like a rant toward the end. I really began answering simply
to thank you for the explanation of the parser issue. :-)

-------------------------------------------
Bill Dargel            [hidden email]
Shoshana Technologies
100 West Joy Road, Ann Arbor, MI 48105  USA