Interesting - and unexpected - error in VA 8.6.2

[Richard Sargent]

I was conducting some simple tests to verify how other implementations handled #asArrayOfKeywords (or equivalent). For hte most part, the results matched my expectations.

#~= asArrayOfKeywords ('~=')
#foo asArrayOfKeywords ('foo')
#foo: asArrayOfKeywords ('foo:')
#aa:bb asArrayOfKeywords ==> MNU 'Symbol does not understand bb'!!
#'aa:bb' asArrayOfKeywords ('aa:' 'bb')
#'a:b:' asArrayOfKeywords ('a:' 'b:')
#'a:b c:d d' asArrayOfKeywords ('a:' 'b c:' 'd d')

The message not understood error was a complete surprise. #aa:bb may not be a valid method selector, but it should be a valid symbol.

[Louis LaBrunda]

Hi Richard,

I think it is a valid symbol but the compiler doesn't seem to parse it or others with some special characters in them like ";" and such.

Lou

[Seth Berman]

Hi Richard,

I see VA and VW parse this differently than Squeak/Pharo.
I also see in EsScanner>>nextToken that the colon after the #[a-zA-Z]+ pattern will send it down a special path called nextToken374 which is why this is parsed as a receiver/message.
Separately, there is also a nextToken380.

Perhaps this is compatibility logic for Smalltalk versions (74, 80) or completely unrelated, I can't really say at this point.

-- Seth

[Richard Sargent]

On Monday, December 19, 2016 at 8:31:56 PM UTC-8, Seth Berman wrote:

Hi Richard,

I see VA and VW parse this differently than Squeak/Pharo.
I also see in EsScanner>>nextToken that the colon after the #[a-zA-Z]+ pattern will send it down a special path called nextToken374 which is why this is parsed as a receiver/message.
Separately, there is also a nextToken380.

Perhaps this is compatibility logic for Smalltalk versions (74, 80) or completely unrelated, I can't really say at this point.

[Off topic]
One of these days, you need to de-obfusticate that code! :-)

 

[Seth Berman]

Hi Richard,

You are right in principle, though it would take a long time to reverse engineer the rationale of some of the decisions in there (or really, what happens when those are removed).

In my head I'm just doing the rough calculation of doing this and it looks something like:

LOE = Med - High,

Risk of breakage = High

Expected cost of subsequent support fallout = High

Reward = Of all the things customers want..this isn't one of them (Probably none), However, combat technical debt (future reward...maybe...this area is pretty much never touched)

ROI summary = A slightly cleaner codebase in an area very few touch for which we probably expended lots of engineering dollars either coding it and/or fixing it.  And while we are fixing it, having customers asking us why we did this?

Incentive = :(

Newer stuff we can do this with, because we are more test-driven these days and can pick up on how a small change broke some corner case (or perhaps everything) very quickly.

For the most part, we don't have those kinds of tests for the deep parts of the product that were written in 1996 and, in some cases, we no longer have the rationale for why things are the way they are.

That's why, in general, I'm more amenable to changing recent things and less for older things.  There are exceptions some though.

- Seth

[Louis LaBrunda]

Hi Seth,

A slightly off topic question, I think that in the Squeak world the compiler can be replaced by some magic that says that the methods of a class are to be compiled with a different compiler.  Is that true and is there anything like it in VA Smalltalk?

Lou

[Seth Berman]

On second thought, I should amend my previous statement with:

We do have lots of core subsystem tests for @1996ish code that are decent and would catch quite a bit of stuff.
But the coverage is much lower...so it would be questionable if we could refactor things way down low and have assurance that we have not broken things.

[Seth Berman]

Hi Lou,

Yes, I think Richard could probably expound on this more since I think he makes use of this capability.
Or at least, I think I remember removing a hard coded reference to EsCompiler on his behalf at some point.

See EsCompiler class>>initializeAfterLoad.
The global Compiler can be set with a different Compiler (by default, EsCompiler).
And, at least if your using the EsCompiler...it can be set with a different ParserClass (by default, EsParser)

-- Seth

[Richard Sargent]

I hear you!!!

--
You received this message because you are subscribed to a topic in the Google Groups "VA Smalltalk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/va-smalltalk/JxP48A8K3Uo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to va-smalltalk+unsubscribe@googlegroups.com.
To post to this group, send email to va-sma...@googlegroups.com.
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.

[Richard Sargent]

On Tue, Dec 20, 2016 at 10:37 AM, Seth Berman <sbe...@instantiations.com> wrote:

Hi Lou,

Yes, I think Richard could probably expound on this more since I think he makes use of this capability.
Or at least, I think I remember removing a hard coded reference to EsCompiler on his behalf at some point.

The Behavior hierarchy defines a #compiler method which classes can override to their particular need. In 8.6.2, there were a number of places where the use of EsCompiler was hard-coded, thus interfering with the intent of that mechanism.

I haven't yet looked at 8.6.3 to see if I can get rid of my hacks. I've been busy on other tasks, so this project has landed on a back burner. (To be precise, a back back burner.)

But, I am confident that, if Seth says he removed them, they have been removed. :-)

[Seth Berman]

I'm still glad you bring them up, though:)

We have a bucket list of nice-to-do's in our case management system...I add these ideas.
They may get done or they may lead to other ideas...so it's appreciated.

-- Seth

[Seth Berman]

Hmmm...I remember removing it from 'A' location in some scintilla-based area.  Not sure I did a complete sweep.
I still got a case open on "References to EsCompiler should be replaced with Compiler for intended pluggability"
It hasn't been scheduled yet...but I'll look into why I held off...and if feasible...work it in.

-- Seth

[Richard Sargent]

On Tue, Dec 20, 2016 at 11:03 AM, Seth Berman <sbe...@instantiations.com> wrote:

I'm still glad you bring them up, though:)

We have a bucket list of nice-to-do's in our case management system...I add these ideas.
They may get done or they may lead to other ideas...so it's appreciated.

De-obfuscating old, rarely touched code definitely ranks in the "we have nothing else to do" category. :-)