Improvements for VA Assist Pro and Code Assist

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

Improvements for VA Assist Pro and Code Assist

jtuchel
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

--
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 http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Improvements for VA Assist Pro and Code Assist

Louis LaBrunda
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

--
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 http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Improvements for VA Assist Pro and Code Assist

Seth Berman
Hello Joachim and Louis,

Exclamation Marks
I agree that they need to refresh in all open windows once a change is made that alters the situation.  I will add an item for this.
The kinds of editor visualizations you speak of have been handled and will be seen at ESUG.

CodePro AnalytiX
Yes, I've used this product in a past life as a java developer.  I think you will see, in the not to distant future (ESUG), that
dynamic code analysis, reporting and repairing is about to become a reality in VA.

Underline Problems sometimes disappear
The source analysis engine is so very different these days that all I can say is, I don't see this happening.
Source analysis runs in the background now, not in the UI process like in 8.6.  So refreshing all browsers (kinda like the exclamation point issue)
is no longer an issue.  I can only assume this was the cause.

Random scrolling in config map
Yes...I've seen this.  Also in the application browser.  It is annoying and I'll see if I can fix 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?

-- Seth

On Tuesday, June 24, 2014 9:42:35 AM UTC-4, Louis LaBrunda wrote:
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

--
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 http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Improvements for VA Assist Pro and Code Assist

Louis LaBrunda

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

--
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 http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Improvements for VA Assist Pro and Code Assist

Seth Berman
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

--
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 http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Improvements for VA Assist Pro and Code Assist

Louis LaBrunda

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

--
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 http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Improvements for VA Assist Pro and Code Assist

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

--
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 http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Improvements for VA Assist Pro and Code Assist

Louis LaBrunda

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

 

--
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 http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Improvements for VA Assist Pro and Code Assist

Seth Berman
Hi Lou,

I think that was my fault...I pressed "Reply to author" when I really meant post....so I was baffled when my post didn't show up...but now I understand.
Thank you for your explanation...I enjoy understanding all the different viewpoints on the matter.
Appreciate the feedback, too.

-- Seth

On Tuesday, June 24, 2014 4:38:10 PM UTC-4, Louis LaBrunda wrote:

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

 

--
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 http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Improvements for VA Assist Pro and Code Assist

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

--
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 http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Improvements for VA Assist Pro and Code Assist

Marten Feldtmann-2
In reply to this post by Seth Berman
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

--
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 http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Improvements for VA Assist Pro and Code Assist

Seth Berman
Hi Marten,

I think you are right on.  I was having a similar kind of discussion recently and we basically seem to be inline on so many of these.  It's nice to know I'm not out of touch:)
Thank you for taking the time to elaborate...this was helpful.

-- Seth

On Wednesday, June 25, 2014 5:42:09 AM UTC-4, Marten Feldtmann wrote:
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

--
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 http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Improvements for VA Assist Pro and Code Assist

Seth Berman
In reply to this post by jtuchel
Thanks Joachim!

-- Seth

On Wednesday, June 25, 2014 2:47:04 AM UTC-4, Joachim Tuchel wrote:
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

--
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 http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Improvements for VA Assist Pro and Code Assist

Instantiations mailing list
In reply to this post by Seth Berman
Hi Seth,

usually I do it a lot but lately I didn't talk with Marten about this ;-) but I can only share his thoughts.

I just want to add one thought. Just a few days ago I optimized a pice of software introducing/using the ValueModel approach [1].
Compared with Associations one could implement a nice performant base framework for such "distributed" system.

I once dabbled around with share memory mapped files with VAST. Unfortunately Windows somehow took over the memory management time over time and my implementation turned out too instable.
The data bandwidth for data exchange amoung images based on mmf and asynch queues seemed very promissing.
I can't find it anymore but having a stable supported implementation like this [2] in VAST would perhaps open new doors for data analysis implementations.

[1] http://st-www.cs.illinois.edu/users/brant/papers/ValueModel/ValueModels.htm
[2]http://www.codeproject.com/Articles/14740/Fast-IPC-Communication-Using-Shared-Memory-and-Int

Sebastian



Am 25.06.2014 11:23, schrieb Seth Berman:
Hi Marten,

I think you are right on.  I was having a similar kind of discussion recently and we basically seem to be inline on so many of these.  It's nice to know I'm not out of touch:)
Thank you for taking the time to elaborate...this was helpful.

-- Seth

On Wednesday, June 25, 2014 5:42:09 AM UTC-4, Marten Feldtmann wrote:
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
--
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 http://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 http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Improvements for VA Assist Pro and Code Assist

Seth Berman
In reply to this post by jtuchel
"Do others also see the behavior 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."

Yes...the Application manager, too.  I have captured two scenarios where this could happen.  The first I have fixed for the next release, the second is native widget behavior on windows and I probably won't be messing with that.
Scenario 1:
1. Open an application manager.
2. Select the first application from the left-most widget.
3. Click on another window like the Transcript (the point being to remove focus)
4. Come back to the application manager, but do not click on it directly.  Instead, drag the scrollbar from the applications list all the way to the bottom and release the mouse button
Result: It will automatically scroll all the way back to the top.
This has been fixed in our dev builds
Case 57652: Fix forced list reselection when application managers and config browsers regain focus by scrollbar dragging

Scenario 2:
1. Open an application manager.
2. Begin dragging the applications list scrollbar down
3. While still dragging by keeping the mouse button down, begin moving the mouse leftward instead of downward.
Result: At about halfway into the application list widget from the leftward drag..it will reset back to the top.
This seem to be native behavior, as I can recreate in windows file explorer.

- Seth

On Tuesday, June 24, 2014 at 6:10:03 AM UTC-4, Joachim Tuchel wrote:
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

--
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 http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Improvements for VA Assist Pro and Code Assist

jtuchel
Hi Seth,

good to hear you are after that problem and we'll see improvements.

I am not sure #1 describes the effect I am seeing, but I couldn't describe it in detail. Every time it happens, it interrupts my train of thoughts so abruptly that I never managed to recreate it willingly ;-)

I am sure what I have been seeing for years now is not #2, because I usually do not hold mouse buttons down when working in VAST (this is a lead-in for drag&drop standards behaviour in VAST Browsers, but let's keep that aside).

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



Am Dienstag, 7. April 2015 22:33:17 UTC+2 schrieb Seth Berman:
"Do others also see the behavior 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."

Yes...the Application manager, too.  I have captured two scenarios where this could happen.  The first I have fixed for the next release, the second is native widget behavior on windows and I probably won't be messing with that.
Scenario 1:
1. Open an application manager.
2. Select the first application from the left-most widget.
3. Click on another window like the Transcript (the point being to remove focus)
4. Come back to the application manager, but do not click on it directly.  Instead, drag the scrollbar from the applications list all the way to the bottom and release the mouse button
Result: It will automatically scroll all the way back to the top.
This has been fixed in our dev builds
Case 57652: Fix forced list reselection when application managers and config browsers regain focus by scrollbar dragging

Scenario 2:
1. Open an application manager.
2. Begin dragging the applications list scrollbar down
3. While still dragging by keeping the mouse button down, begin moving the mouse leftward instead of downward.
Result: At about halfway into the application list widget from the leftward drag..it will reset back to the top.
This seem to be native behavior, as I can recreate in windows file explorer.

- Seth

On Tuesday, June 24, 2014 at 6:10:03 AM UTC-4, Joachim Tuchel wrote:
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

--
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 http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Improvements for VA Assist Pro and Code Assist

Louis LaBrunda
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

--
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 http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Improvements for VA Assist Pro and Code Assist

Seth Berman
Hi Lou,

I will have to ask around about your first one concerning the organizer.  I can't recreate that, but I'm not as familiar with the organizer so I'll check with some others.

I'm going to have to guess on the second because I think I may know what you are saying, but not completely sure.
I'm assuming you are referring to code completion and auto-paren insertion?
If so, there could be multiple suggestions with the same name in the completion list.  Each suggestion will insert the same name, but at a different precedence level.  The parens will insert differently (or not at all) depending on the precedence level you are intending.  Perhaps you are consistently making the same precedence level choice and so the parens consistently go in the inappropriate location for the precedence level you were actually intending?
Just a guess....you could mean something else entirely but I'm not sure what that would be.

-- Seth

On Wednesday, April 8, 2015 at 11:23:25 AM UTC-4, Louis LaBrunda wrote:
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

--
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 http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Improvements for VA Assist Pro and Code Assist

Wayne Johnston
In reply to this post by Louis LaBrunda
I think unrelated to the title of this thread, I am happy that Louis LaBrunda wrote:
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.

That reminds me of an obscure problem in our application which as far as I know may be caused by the same thing.

We have a window 'A' which lists several objects as rows in a table (WkPacketingTableWidgetView).  Double click on a row and window 'B' comes up on the selected object.  Window B has a small pane with a WkTableWidgetView where either of its two columns can be sorted by clicking on the column heading.

Well, if you happen to double click in a certain place in window A, window B comes up and the data in its table is sorted by whichever column your mouse pointer is over, as if you clicked the column heading.  We debugged this as far as seeing that #processButton1Release: gets hit.

 

--
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 http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Improvements for VA Assist Pro and Code Assist

Louis LaBrunda
In reply to this post by Seth Berman
Hi Seth,

On Wednesday, April 8, 2015 at 12:44:01 PM UTC-4, Seth Berman wrote:
Hi Lou,

I will have to ask around about your first one concerning the organizer.  I can't recreate that, but I'm not as familiar with the organizer so I'll check with some others.

I'm going to have to guess on the second because I think I may know what you are saying, but not completely sure.
I'm assuming you are referring to code completion and auto-paren insertion?
If so, there could be multiple suggestions with the same name in the completion list.  Each suggestion will insert the same name, but at a different precedence level.  The parens will insert differently (or not at all) depending on the precedence level you are intending.  Perhaps you are consistently making the same precedence level choice and so the parens consistently go in the inappropriate location for the precedence level you were actually intending?
Just a guess....you could mean something else entirely but I'm not sure what that would be.

-- Seth

Thanks for the reply.  I think you may be right.  I will have to pay more attention to what I select from now on.  I have probably been lazy and just selected the first thing that looked good if not just the first thing.

Lou

--
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 http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
12