Small formatting error in 9.2

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Small formatting error in 9.2

Long Haired David
Hi Everyone.

Does anyone else see this?

Since I have moved to 9.2 I am getting a formatting error.

I enter

self currentCount = self memberItems size 

and the auto format turns it into 

(self currentCount = self) memberItems size 

which is no help at all.

If it made it

(self currentCount = self memberItems size) that would help but it puts the right bracket in as I type, not at the end of the line.

David
Totally Objects

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/681a1ea9-c201-4537-81cf-42374a989794%40googlegroups.com.
David
Totally Objects
Doing Smalltalk since 1989
Reply | Threaded
Open this post in threaded view
|

Re: Small formatting error in 9.2

Mariano Martinez Peck-2
Hi David,

We tried your example like this:

1) Create a method:

foo
     self currentCount = self memberItems size 

2) Load ENV:QA and do a "Format Text" (or Ctrl+w)

But the result is correct to me. See attached. 

How can we reproduce it?

Best, 


On Tue, Jan 21, 2020 at 8:04 AM Totally Objects <[hidden email]> wrote:
Hi Everyone.

Does anyone else see this?

Since I have moved to 9.2 I am getting a formatting error.

I enter

self currentCount = self memberItems size 

and the auto format turns it into 

(self currentCount = self) memberItems size 

which is no help at all.

If it made it

(self currentCount = self memberItems size) that would help but it puts the right bracket in as I type, not at the end of the line.

David
Totally Objects

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/681a1ea9-c201-4537-81cf-42374a989794%40googlegroups.com.


--
Mariano Martinez Peck
Software Engineer, Instantiations Inc.

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/CAOUkibEGOnqpj5Q8hj1G8kWBdwU9NNUtJ2%3D3f%3D_s_zXKEz0rPg%40mail.gmail.com.

Screen Shot 2020-01-23 at 12.45.38 PM.png (177K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Small formatting error in 9.2

jtuchel
In reply to this post by Long Haired David
David,

are you sure it is happing when you autoformat?

I only know this from autocompletion when you select the option with a backpointing yellow arrow (if I remember correctly). I've been bitten by this quite often ever since autocompletion was added to VAST. And I mostly "select" this option when it turns out wrong. But that is me pressing enter before my brain starts thinking ,-)

Joachim








Am Dienstag, 21. Januar 2020 12:04:37 UTC+1 schrieb Totally Objects:
Hi Everyone.

Does anyone else see this?

Since I have moved to 9.2 I am getting a formatting error.

I enter

self currentCount = self memberItems size 

and the auto format turns it into 

(self currentCount = self) memberItems size 

which is no help at all.

If it made it

(self currentCount = self memberItems size) that would help but it puts the right bracket in as I type, not at the end of the line.

David
Totally Objects

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/a2ba1ad2-2f9c-48b4-a8f5-dd60867f5157%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Small formatting error in 9.2

rjuli...@gmail.com
In reply to this post by Long Haired David
I just wanted to add my $0.02....

I have actually seen this very same behaviour in 9.1.
It is not reliably reproduceable, which is why I did not report it.
It does not happen often, and I am yet to isolate the specifics....but if I do, I will report it.

Regards,
Julian


On Tuesday, January 21, 2020 at 6:04:37 AM UTC-5, Totally Objects wrote:
Hi Everyone.

Does anyone else see this?

Since I have moved to 9.2 I am getting a formatting error.

I enter

self currentCount = self memberItems size 

and the auto format turns it into 

(self currentCount = self) memberItems size 

which is no help at all.

If it made it

(self currentCount = self memberItems size) that would help but it puts the right bracket in as I type, not at the end of the line.

David
Totally Objects

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/b337b50b-f3d5-430c-9e5e-4d8f67a0c90f%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Small formatting error in 9.2

stepha...@etas.com
I just observed:

^(self exportFileExtension, ';', self) exportFileExtension64

I think I used the autocompletion for the last method.

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/068de10e-d6d2-426d-b67e-6aba83438da3%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Small formatting error in 9.2

Seth Berman
Greetings Stephan,

Are we talking about the autocompletion behavior, or the original formatting issue?

If its the autocompletion behavior, there should be multiple "exportFileExtension64" in the list with arrows to indicate the precedence.
This is described more in detail in the documentation under the Code Completion Suggestions -> Method Suggestions: section
https://www.instantiations.com/docs/92/wwhelp/wwhimpl/js/html/wwhelp.htm#href=vaast/vaast-3cc.html

The simple answer is the expression that you show is highly ambiguous in terms of what is meant by 'self exportFileExtension, ';', self' followed by a completion request.
Its simply can't possibly know what part of the expression you are referring to.  This makes the smalltalk syntax tougher than any C language with regards to code completion.
There are settings to change how precedence is presented if the way your "brain" works differs from that of the author "me".
Those settings should be described on that same page in the documentation as well.

- Seth

On Wednesday, February 19, 2020 at 4:10:45 AM UTC-5, Stephan Henke wrote:
I just observed:

^(self exportFileExtension, ';', self) exportFileExtension64

I think I used the autocompletion for the last method.

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/964fad85-4aaf-41cc-ab00-e9d496570a9d%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Small formatting error in 9.2

stepha...@etas.com
Hey Seth,
sorry for the late reply, but now I have a concrete example of the problem for reproduction.
I am talking about auto completion here and I also think that the problem of the thread creator also is with auto completion and not formatting.

If you enter by hand:
Float emax = Float emax
and if you use autocompletion for the last method it turns into
(Float emax = Float) emax
This happens within a hierarchy browser on 9.2.2 but I also checked on 10.0.0 ecap and there I do not see this.
Maybe it got fixed but maybe the settings are just different. But I would prefer to not get brackets at all instead of wrong ones.

Stephan

Seth Berman schrieb am Mittwoch, 19. Februar 2020 um 16:22:11 UTC+1:
Greetings Stephan,

Are we talking about the autocompletion behavior, or the original formatting issue?

If its the autocompletion behavior, there should be multiple "exportFileExtension64" in the list with arrows to indicate the precedence.
This is described more in detail in the documentation under the Code Completion Suggestions -> Method Suggestions: section
https://www.instantiations.com/docs/92/wwhelp/wwhimpl/js/html/wwhelp.htm#href=vaast/vaast-3cc.html

The simple answer is the expression that you show is highly ambiguous in terms of what is meant by 'self exportFileExtension, ';', self' followed by a completion request.
Its simply can't possibly know what part of the expression you are referring to.  This makes the smalltalk syntax tougher than any C language with regards to code completion.
There are settings to change how precedence is presented if the way your "brain" works differs from that of the author "me".
Those settings should be described on that same page in the documentation as well.

- Seth

On Wednesday, February 19, 2020 at 4:10:45 AM UTC-5, Stephan Henke wrote:
I just observed:

^(self exportFileExtension, ';', self) exportFileExtension64

I think I used the autocompletion for the last method.

--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/9246c874-fc73-4537-8688-c91efaf8e0c4n%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Small formatting error in 9.2

Seth Berman
Greetings Stephan,

This is actually a very interesting example.  Well, interesting to me anyway (which I guess explains the length of this post).
I can repeat what you are showing, but its not that 9.2.2 is incorrect...its just that 10.0.0 has new type reconstruction capability that allows it to know exactly the types involved.

When I do the following in 9.2.2
Float emax = Float em<code completion request>
what I see are a listing of entries...some with precedence arrows...Some without.
I see 2 entries for emax.  Look near the bottom and you will see the one without the precedence arrow.  That is the one that applies to the Float receiver.  The other one applies to the (Float emax = Float) expression receiver.

When I do this in 10.0.0, I only see a single #emax entry for the Float receiver.
Why?

The answer starts all the way back at the first instance of 'Float emax'.
In 9.2.2, the type of the expression 'Float emax' is unresolved...so its going to show you all possible suggestions.
The reason the type is unresolved is that there isn't any logic that would tell it how to look inside the method Float>>emax and then attempt to figure out what the return type is.
In 10.0.0...there is. Its using bytecode analysis.

10.0.0 has 2 additional type reconstruction/analysis features.  Bytecode analysis and Type annotations.
Bytecode Analysis
If you look inside Float>>emax you see a very simple ^308.
Therefore, the return type of Float>>emax is <SmallInteger>.
This seems like a pretty easy method to type using the existing machinery which uses a combination of token and parse-tree analysis.
However, these types of analysis require source code. It turns out that its not a great idea to have the tooling go around loading up CompiledMethod source from ENVY in a recursive manner as it tries to type expressions.
Therefore, if we branch out and start peering inside compiled methods...its better to analyze the already loaded bytecodes rather than make ENVY requests for source code.
As of 10.0.0, we introduced a bytecode analyzer that can identify patterns of bytecodes and, if required, type analyze arguments encoded in the bytecodes or as literals which the bytecode indirectly refer to.

So in 10.0.0, if you request code completion for the 'Float emax' expression, you will see that it is resolved as the type <SmallInteger>.
Since it knows 'Float emax' is of type <SmallInteger>, it then goes on to type the expression 'Float emax = Float'.
And it knows this means it must bytecode analyze the method SmallInteger>>=.
By doing so it sees a primitive call to <VMprSmallIntegerEqual> inside that method which it knows is of return type <Boolean>.

Now back to our original example
Float emax = Float <code completion request>.
Instead of resolving it to the aggregate type <Unresolved, Float> that was in 9.2.2
10.0.0 considers that expression to be the aggregate type <Boolean, Float>.
And emax is only implemented (normally) in Float and not Boolean...so the choice is obvious because there is only one.

The bottom line is that typing information flows through the expressions in a method. Typing things successfully as early as possible
can give great information later that almost seems like magic (as some have put it to me).  Well its not magic...its just a lot of analysis that
is all connected.  Its great for code completion but its also great for analyzers that are looking to see if the types are still flowing feasibly as
you refactor your methods.  I've been saved many times earlier by such refactorings that would have gone out the door as DoNotUnderstand errors.
Most I might have caught thought SUnit tests...but its questionable for some and the goal is always to fail early.

Type Annotations
EsAsynchronousSupport is a new application that has type annotations for EsFuture and EsPromise.
Type Annotations describe return types and argument types. This is connected to both code completion and type analysis
and will help the type resolver out if it knows which method(s) are involved because it knows how to peer
inside and extract that type information.

Hope that this explanation helps.

- Seth

On Wednesday, March 17, 2021 at 10:56:21 AM UTC-4 [hidden email] wrote:
Hey Seth,
sorry for the late reply, but now I have a concrete example of the problem for reproduction.
I am talking about auto completion here and I also think that the problem of the thread creator also is with auto completion and not formatting.

If you enter by hand:
Float emax = Float emax
and if you use autocompletion for the last method it turns into
(Float emax = Float) emax
This happens within a hierarchy browser on 9.2.2 but I also checked on 10.0.0 ecap and there I do not see this.
Maybe it got fixed but maybe the settings are just different. But I would prefer to not get brackets at all instead of wrong ones.

Stephan

Seth Berman schrieb am Mittwoch, 19. Februar 2020 um 16:22:11 UTC+1:
Greetings Stephan,

Are we talking about the autocompletion behavior, or the original formatting issue?

If its the autocompletion behavior, there should be multiple "exportFileExtension64" in the list with arrows to indicate the precedence.
This is described more in detail in the documentation under the Code Completion Suggestions -> Method Suggestions: section
https://www.instantiations.com/docs/92/wwhelp/wwhimpl/js/html/wwhelp.htm#href=vaast/vaast-3cc.html

The simple answer is the expression that you show is highly ambiguous in terms of what is meant by 'self exportFileExtension, ';', self' followed by a completion request.
Its simply can't possibly know what part of the expression you are referring to.  This makes the smalltalk syntax tougher than any C language with regards to code completion.
There are settings to change how precedence is presented if the way your "brain" works differs from that of the author "me".
Those settings should be described on that same page in the documentation as well.

- Seth

On Wednesday, February 19, 2020 at 4:10:45 AM UTC-5, Stephan Henke wrote:
I just observed:

^(self exportFileExtension, ';', self) exportFileExtension64

I think I used the autocompletion for the last method.

--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/bb38aaf2-db4e-447d-b0c1-9d818ee2358bn%40googlegroups.com.