Small formatting error in 9.2

[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

[Mariano Martinez Peck]

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, 

--
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 va-smalltalk...@googlegroups.com.
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.

Email: mp...@instantiations.com

Twitter: https://twitter.com/MartinezPeck

LinkedIn: www.linkedin.com/in/mariano-martinez-peck

Blog: https://marianopeck.wordpress.com/

[Joachim Tuchel]

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

[Julian Ford]

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

[Stephan Henke]

I just observed:

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

I think I used the autocompletion for the last method.

[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

[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]

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