Quantcast

Interesting - and unexpected - error in VA 8.6.2

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Interesting - and unexpected - error in VA 8.6.2

Richard Sargent
Administrator
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 the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Interesting - and unexpected - error in VA 8.6.2

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

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 the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Interesting - and unexpected - error in VA 8.6.2

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

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 the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Interesting - and unexpected - error in VA 8.6.2

Richard Sargent
Administrator
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 the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Interesting - and unexpected - error in VA 8.6.2

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

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 the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Interesting - and unexpected - error in VA 8.6.2

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.

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 the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Interesting - and unexpected - error in VA 8.6.2

Louis LaBrunda
In reply to this post by Seth Berman
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 the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Interesting - and unexpected - error in VA 8.6.2

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

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 the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Interesting - and unexpected - error in VA 8.6.2

Richard Sargent
Administrator
In reply to this post by Seth Berman
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 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 https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Interesting - and unexpected - error in VA 8.6.2

Richard Sargent
Administrator
In reply to this post by Seth Berman
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 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 https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Interesting - and unexpected - error in VA 8.6.2

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

On Tuesday, December 20, 2016 at 2:00:30 PM UTC-5, Richard Sargent wrote:
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.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Interesting - and unexpected - error in VA 8.6.2

Seth Berman
In reply to this post by Richard Sargent
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

On Tuesday, December 20, 2016 at 1:51:45 PM UTC-5, Richard Sargent wrote:
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.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Interesting - and unexpected - error in VA 8.6.2

Richard Sargent
Administrator
On Tue, Dec 20, 2016 at 11:03 AM, Seth Berman <[hidden email]> 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. :-)

 

-- Seth

On Tuesday, December 20, 2016 at 1:51:45 PM UTC-5, Richard Sargent wrote:
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 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 https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Loading...