Improvements for VA Assist Pro and Code Assist

Hi Joachim,

I agree with all that you said and in particular with this:

* I personally really passionately hate the fact that pressing del on a non-matching bracket deletes the character after the bracket (Scintilla) and only backspace deletes the bracket - not sure if others agree here: opinions?

I assume by bracket you also mean parenthesis and such.  I don't understand the logic behind this behavior, if there is any.  If there is a miss-match the solution is either to add another somewhere or remove one.  Why would anyone want to remove the next character?  Either we are missing something or this is a bug.

Lou

Hi Seth,

Thanks for all your great work on this.

Delete on a non-matching bracket

Now we come to the one I don't understand...and I think we have talked about it before.

Can you give me an example of an editor/IDE that provides the behavior you are looking for?

As far as I know, the editor is just handling the delete key in the way that it normally does...which is to delete the current

character thereby shifting the next characters back.

So if your caret sits on the position of a mismatched bracket and you press 'Delete'....then it should delete the bracket.  If you caret sits after the position of a mismatched bracket,

then why would one expect the delete key to perform the non-standard behavior of what is effectively a backspace?

Do I have this issue correct?  I understand the visualization of a non-matching bracket only requires that the caret is adjacent to the bracket...is this the issue?

After playing with mismatches a bit I have figured out what is going on.  You are correct the behavior is proper.  The problem is that one can't always see where the caret (cursor) sits.  If it is to the right of the mismatch and you press delete, the next character is removed.  If it is to the left of the mismatch and you press backspace the previous character is removed.  We need some way of clearing seeing where the cursor is when it is on or to one side or the other of the mismatch.

I feel your pain here Seth, this choice may not be easy, maybe underling the mismatch instead of the reverse video.

Lou

Hey Seth,

Sounds wonderful!  As much as I think a 64 bit and multi-threaded VA Smalltalk is important (and I do) these improvements to the development environment are just as important.  Thanks for keeping this stuff coming.

Lou

On Tuesday, June 24, 2014 1:55:28 PM UTC-4, Seth Berman wrote:

Hi Lou,

Great points....and I believe the next release will provide the solution to all of these.

In the next release:

1. The caret is a pixel larger by default, giving the flavor of the native text edit control and easier to see.

    One can even use a different color for the caret these days if they desire.

     The caret size is actually a scintilla API and easily configurable, but I'm not sure yet if those kind of config

     items will be available in a UI, but I'm trying.

2. The bracket matching default styling now uses indicators that underlay the text.  Since they are indicators,

    you can use subtle to not so subtle effects to show matches and mis-matches.  You also still have the option to 

    stylize the character instead like was done in 8.6

-- Seth

On Tuesday, June 24, 2014 1:46:28 PM UTC-4, Louis LaBrunda wrote:

Hi Seth,

Thanks for all your great work on this.

Delete on a non-matching bracket

Now we come to the one I don't understand...and I think we have talked about it before.

Can you give me an example of an editor/IDE that provides the behavior you are looking for?

As far as I know, the editor is just handling the delete key in the way that it normally does...which is to delete the current

character thereby shifting the next characters back.

So if your caret sits on the position of a mismatched bracket and you press 'Delete'....then it should delete the bracket.  If you caret sits after the position of a mismatched bracket,

then why would one expect the delete key to perform the non-standard behavior of what is effectively a backspace?

Do I have this issue correct?  I understand the visualization of a non-matching bracket only requires that the caret is adjacent to the bracket...is this the issue?

After playing with mismatches a bit I have figured out what is going on.  You are correct the behavior is proper.  The problem is that one can't always see where the caret (cursor) sits.  If it is to the right of the mismatch and you press delete, the next character is removed.  If it is to the left of the mismatch and you press backspace the previous character is removed.  We need some way of clearing seeing where the cursor is when it is on or to one side or the other of the mismatch.

I feel your pain here Seth, this choice may not be easy, maybe underling the mismatch instead of the reverse video.

Lou

Hi Seth,

I'm not sure how but I got an email about this off-line, so I responded off-line.  Since, you also asked here I will repeat my response here.

On Tuesday, June 24, 2014 4:15:45 PM UTC-4, Seth Berman wrote:

Hi Lou,

Thanks....we feel the same.

Out of curiosity, what exactly do you mean when you say "multi-threaded VA Smalltalk".  Do you literally mean you would like to see a native threading model exposed in smalltalk like java has. Or are you simply suggesting we need a better solution to more easily allow the user to take advantage of multiple processors?

-- Seth

Well, I'm not exactly sure. I'm not a Java guy so I don't know what Java
offers. Probably the later. I think that if multiple processors are
present and more than one Smalltalk fork could run at the same time (each
on a processor) that would be great.

I know the VM uses more than one thread when it makes calls to the OS for
stuff like database calls and maybe sockets (things that would block the VM
and all forks otherwise). But only one fork runs at a time in only one
thread.

To my mind this is more important than 64 bit VA Smalltalk, not that 64 bit
VA Smalltalk isn't important. Being able to use more processors at the
same time will speed up all programs. Unless you really need the greater
memory access, 64 bits doesn't buy you much. Although, today if you aren't
64 bit, people think you are behind the times and that can be a problem in
and of itself.

If you guys work on multiple processors, take a look at the Delay/Dispatch
code.

1) Delays of less than 100 milliseconds are problematic.
2) Delays of less than ~15 milliseconds are almost impossible.

There are a couple reasons for this that I can go into more if you like.

Anyway, keep of the great work.

Lou

 

Native Threading

* Actually I believe (now) that native Smalltalk-code threading brings more problems than solving problems - and this is simply due to the grown Smalltalk product infrastructure (speak: the over year grown library). I believe, that out of the box only SstSharedQueue and the SstActor classes are thread safe - the rest is more or less not thread safe. Introducing multithreading brings the same problems as under other languages - using Semaphores and Mutexes all over the code .... making the situation not much better

* The better way is to offer support for multiprocessing multi-images programming - and I still think, that VA has most of the stuff needed for such a programming model already on board with SST. But nothing had happened here over the last 10 years ...

-> the programming model should work within one image - for testing purposes - and simple stuff.

-> the programming model should work with multiple images within ONE computer

-> the programming model may work with multiple images on several computers

And it must support the highly interactive programming model of smalltalk - all of that is difficult to achieve.

Integration with other languages

-> I gave up the idea of having a tighter support for C# or Java - but C should be still a main target and here some stuff is still missing (also to support the multithreading support above):

 --> asynchronous (!) callbacks (in cdecl and stdcall)
 --> synchronous callback support (stdcall in Windows)


Deployment

-> together with the CI support below: make deployment simpler and fast and NOT UI dependent.

-> introduce a stripping mode where nothing is stripped out of the packaged applications - this makes the application larger, but you get more easily a first deployment system.


Integration Support

* One should consider CI support for Hudson/Jenkins - bringing Smalltalk again into the mainstream development line. The problem here is the visual oriented development idea of VA. More headless support in building images/IC's is a must here.

64bit

* Some customers may have reached the 2 GB address range and need more. Especially under Windows the 32 bit versions works pretty nice. The bigger problem comes under Linux (and all the hosted computers ...). 64Bit Ubuntu's/Suse's/Fedora's are becoming more and more the default installation base. Yes, one can add the 32 bit library support - but that brings additional problems sometimes and makes the whole system more difficult to maintain. Administrators may get mad, when they hear to install 32 bit library support - for a tool in an unkown language named VASmalltalk.

GUI and IDE improvements

* Nice to have - without any questions. But one has also to say, that Seth is now doing the work, which should have be done years before - and VA reaches the point where Dolphin was 5 years ago ... but I love the very good work Seth brings into the product.

Other points

* Unicode support
* Superior table widget


Some of my ideas ....



Am Dienstag, 24. Juni 2014 22:15:45 UTC+2 schrieb Seth Berman:

Hi Lou,

Thanks....we feel the same.

Out of curiosity, what exactly do you mean when you say "multi-threaded VA Smalltalk".  Do you literally mean you would like to see a native threading model exposed in smalltalk like java has. Or are you simply suggesting we need a better solution to more easily allow the user to take advantage of multiple processors?

-- Seth

On Tuesday, June 24, 2014 3:43:57 PM UTC-4, Louis LaBrunda wrote:

Hey Seth,

Sounds wonderful!  As much as I think a 64 bit and multi-threaded VA Smalltalk is important (and I do) these improvements to the development environment are just as important.  Thanks for keeping this stuff coming.

Lou

On Tuesday, June 24, 2014 1:55:28 PM UTC-4, Seth Berman wrote:

Hi Lou,

Great points....and I believe the next release will provide the solution to all of these.

In the next release:

1. The caret is a pixel larger by default, giving the flavor of the native text edit control and easier to see.

    One can even use a different color for the caret these days if they desire.

     The caret size is actually a scintilla API and easily configurable, but I'm not sure yet if those kind of config

     items will be available in a UI, but I'm trying.

2. The bracket matching default styling now uses indicators that underlay the text.  Since they are indicators,

    you can use subtle to not so subtle effects to show matches and mis-matches.  You also still have the option to 

    stylize the character instead like was done in 8.6

-- Seth

On Tuesday, June 24, 2014 1:46:28 PM UTC-4, Louis LaBrunda wrote:

Hi Seth,

Thanks for all your great work on this.

Delete on a non-matching bracket

Now we come to the one I don't understand...and I think we have talked about it before.

Can you give me an example of an editor/IDE that provides the behavior you are looking for?

As far as I know, the editor is just handling the delete key in the way that it normally does...which is to delete the current

character thereby shifting the next characters back.

So if your caret sits on the position of a mismatched bracket and you press 'Delete'....then it should delete the bracket.  If you caret sits after the position of a mismatched bracket,

then why would one expect the delete key to perform the non-standard behavior of what is effectively a backspace?

Do I have this issue correct?  I understand the visualization of a non-matching bracket only requires that the caret is adjacent to the bracket...is this the issue?

After playing with mismatches a bit I have figured out what is going on.  You are correct the behavior is proper.  The problem is that one can't always see where the caret (cursor) sits.  If it is to the right of the mismatch and you press delete, the next character is removed.  If it is to the left of the mismatch and you press backspace the previous character is removed.  We need some way of clearing seeing where the cursor is when it is on or to one side or the other of the mismatch.

I feel your pain here Seth, this choice may not be easy, maybe underling the mismatch instead of the reverse video.

Lou

Hi Seth, Louis,

first of all: I really am eager to see all that you tell us about the next VAST release. Sounds as if this will again be a great leap forward for VAST users. I really like the fact that you are constantly improving the coding experience, and the steps we've seen so far are really appreciated and promising.

As Louis pointed out, my bracket-mismatch-character-deletion complaint is probably about the fact that it is visually hard (or impossible) to tell if you are seeing a selected bracket or an unmatched bracket (or parentheses), so I am always surprised by the fact that DEL didn't delete the "selected" character, which wasn't selected, but marked as unmatched. So I take your word for it that we're seeing improvements on this with the next release.

All I know is that I keep being bitten by this several times a day and I seem to be unable to adapt myself to the existing behavior ;-)

Thanks for all the good work spent on Scintilla and Code Assist and such. 

And thanks for Louis for taking the time to describe my ill-formulated problems in a more approachable manner ;-) Together we're strong ;-))

Joachim

Hi,

VA Assist pro has the nice feature of displaying a yellow exclamation mark for methods with Compile Errors. This could be improved a lot:

* It would be good if I could ask that exclamation mark what's wrong in the method ( a minimum solution could be an extra exclamation mark in the column where you put the breakpoints in the line where the error is - I know I can also look for red underlines, but that is an extra mental step)
* The exclamation mark doesn't get updated in Browsers if a compile error was solved in another browser (like I implemented a method on some other class)
* What would be nice is if I could ask VA Assist for all methods in the image that currently have an exclamation mark (with an error dscription)

I'm dreaming of a Smalltalk incarnation of Instantiations' former product called CodePro AnalytiX. It was a great (in capital letters!) Eclipse plugin. Just imagine what a VAST with only a fraction of the functionality of CodePro AnalytiX would be like....

A few more remarks about the current browsers in VAST 8.6:

* underlined problems sometimes only disappear if you click on another method and come back or reformat a method (Scintilla) - this points towards some more updating/refreshing in browsers combined with the exclamation mark stuff I mentioned before ( I know I am asking for trouble because we would see more library accesses all over the place)
* I personally really passionately hate the fact that pressing del on a non-matching bracket deletes the character after the bracket (Scintilla) and only backspace deletes the bracket - not sure if others agree here: opinions?
* Do others also see the behaviour that you click on a Map in the Conf Map Browser and the Browser suddenly scrolls somewhere else and selects completely different maps than the one I clicked onto? Very annoying.


Joachim

Thanks for keeping an eye on such "small" issues besides working in more important and rewarding stuff. Every annoyance taken out of VAST makes it a little more friendly to new users and returners. And for me ;-)

Joachim

Hi Seth & Joachim,

Thanks for keeping an eye on such "small" issues besides working in more important and rewarding stuff. Every annoyance taken out of VAST makes it a little more friendly to new users and returners. And for me ;-)

Joachim

I second this sentiment of Joachim.  With that in mind I will point out two small things that trouble me.

If I double click on a part in the organizer window to open an editor for it, when the window opens if a widget is under the spot where the part was double clicked, the widget is selected.  This doesn't really hurt but it is a little odd that a click or two is passed to the newly opened window.  You never know what might end up receiving the click and doing something unintended.

The other has to do with code assist (which I love and keeps getting better and better).  When adding parenthesis to wrap boolean operations like "&" (especially if an existing statement is being edited) the added right parenthesis ")" is in the wrong place.  It is often not just wrong but way out of wack.

Lou