Interesting - and unexpected - error in VA 8.6.2

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.

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

On Monday, December 19, 2016 at 7:19:00 PM UTC-5, Richard Sargent wrote:

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.

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

On Monday, December 19, 2016 at 8:12:00 PM UTC-5, Louis LaBrunda wrote:

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

On Monday, December 19, 2016 at 7:19:00 PM UTC-5, Richard Sargent wrote:

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.

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

On Tuesday, December 20, 2016 at 12:02:50 PM UTC-5, Richard Sargent wrote:

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

On Monday, December 19, 2016 at 8:12:00 PM UTC-5, Louis LaBrunda wrote:

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

On Monday, December 19, 2016 at 7:19:00 PM UTC-5, Richard Sargent wrote:

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.

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

On Tuesday, December 20, 2016 at 12:02:50 PM UTC-5, Richard Sargent wrote:

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

On Monday, December 19, 2016 at 8:12:00 PM UTC-5, Louis LaBrunda wrote:

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

On Monday, December 19, 2016 at 7:19:00 PM UTC-5, Richard Sargent wrote:

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.

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

On Tuesday, December 20, 2016 at 1:14:21 PM UTC-5, Seth Berman wrote:

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

On Tuesday, December 20, 2016 at 12:02:50 PM UTC-5, Richard Sargent wrote:

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

On Monday, December 19, 2016 at 8:12:00 PM UTC-5, Louis LaBrunda wrote:

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

On Monday, December 19, 2016 at 7:19:00 PM UTC-5, Richard Sargent wrote:

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.

On Tue, Dec 20, 2016 at 10:37 AM, Seth Berman <[hidden email]> 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. :-)

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

On Tuesday, December 20, 2016 at 1:30:20 PM UTC-5, Louis LaBrunda wrote:

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

On Tuesday, December 20, 2016 at 1:14:21 PM UTC-5, Seth Berman wrote:

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

On Tuesday, December 20, 2016 at 12:02:50 PM UTC-5, Richard Sargent wrote:

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

On Monday, December 19, 2016 at 8:12:00 PM UTC-5, Louis LaBrunda wrote:

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

On Monday, December 19, 2016 at 7:19:00 PM UTC-5, Richard Sargent wrote:

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.

--
You received this message because you are subscribed to a topic in the Google Groups "VA Smalltalk" group.
To unsubscribe from this topic, visit <a href="https://groups.google.com/d/topic/va-smalltalk/JxP48A8K3Uo/unsubscribe" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/topic/va-smalltalk/JxP48A8K3Uo/unsubscribe&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/topic/va-smalltalk/JxP48A8K3Uo/unsubscribe&#39;;return true;">https://groups.google.com/d/topic/va-smalltalk/JxP48A8K3Uo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at <a href="https://groups.google.com/group/va-smalltalk" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;">https://groups.google.com/group/va-smalltalk.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

I hear you!!!

On Tue, Dec 20, 2016 at 10:14 AM, Seth Berman <[hidden email]> wrote:

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

On Tuesday, December 20, 2016 at 12:02:50 PM UTC-5, Richard Sargent wrote:

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

On Monday, December 19, 2016 at 8:12:00 PM UTC-5, Louis LaBrunda wrote:

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

On Monday, December 19, 2016 at 7:19:00 PM UTC-5, Richard Sargent wrote:

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.

--
You received this message because you are subscribed to a topic in the Google Groups "VA Smalltalk" group.
To unsubscribe from this topic, visit <a href="https://groups.google.com/d/topic/va-smalltalk/JxP48A8K3Uo/unsubscribe" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/topic/va-smalltalk/JxP48A8K3Uo/unsubscribe&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/topic/va-smalltalk/JxP48A8K3Uo/unsubscribe&#39;;return true;">https://groups.google.com/d/topic/va-smalltalk/JxP48A8K3Uo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at <a href="https://groups.google.com/group/va-smalltalk" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;">https://groups.google.com/group/va-smalltalk.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.