| Author |
 Topic  |
|
|
draza
Senior Member
France
48 Posts |
 Posted - Jan 18 2005 : 02:45:41 AM
|
Hi,
I finally got my copy of 10.0.1246 (last mainstream build before 10.1 beta cycle) and I can confirm there are some regressions from that build to almost any 10.1 build (I noticed it about 10.1.1270+).
Here is the list, more important/annoying items listed first:
1. Basic rendering seems to have changed significantly speed wise. 1246 would mostly color everything correctly as soon as I opened the file (particularly methods), then there would be small delay until the parsing is done and then everything would look OK. Builds 1270+ do not color methods at first, then after parsing is done sometimes they are still not colored, and finally when I click near the code that is not colored yet, after up to 3-5 seconds it gets colored. Even worse, as soon as I start scrolling, all this gets "forgotten" and we go back again... Most annoying is not coloring methods correctly, sometimes even after I click into the method itself - nothing happens. 1246 works reliably all the time.
2. Namespaces with more than one word (like System.Collections.Specialized) are not colored correctly. In 90% of the cases, only the first word is colored correctly, others are not colored (local variable(s) color is used whenever VA does not know how to color something). Needless to say, 1246 works just fine.
3. Sometimes a method would be colored as type, and I just saw a case where a method is colored as enum. I can see it in the case of Set and Get methods of BitArray class (colored as type) and String.Append (colored as enum), but there were other examples as well. 1246 works fine.
4. Both versions have problems when a property has the same name as a type, then it gets colored as type (and not member variable/local variable). 1246 is confused much less often then 1270+, and I find it's confusion tolerable since it most likely comes from fast parser not seeing the context correctly (even though it does not appear to be unsolvable, I'm willing to ignore it).
Going through the list I can see that basically it boils down to two things - methods are colored in strange "lazy" fashion, have coloring errors, and namespaces are not colored correctly.
Until these errors are fixed, I am going to stay with 1246. I hate to do it, as I always have latest and greatest installed, but I have no choice - 1293 is inferior in basic behavior and new features do not compensate for these regressions.
Note that I did post all of these bugs separately in several of my posts in private beta/public beta forums, but they were apparently not important enough to be taken care of. |
This problem when solved will be simple |
|
|
WannabeeDeveloper
Tomato Guru
Germany
775 Posts |
Posted - Jan 18 2005 : 03:09:32 AM
|
quote:
Originally posted by draza
Note that I did post all of these bugs separately in several of my posts in private beta/public beta forums, but they were apparently not important enough to be taken care of.
No way! It's not that they were not important enough, they were not reproducable enough!
How shall I enter a bug into the Bugbase when I am not able to test if the bug is resolved/fixed in a new version? Shall I guess? Ask someone else? Tell me...
I have not looked closer at your mentioned problems, but I believe (I may be wrong here) that you are the only one that has these problems, as no-one else seems to have confirmed them (as I said, this is just a guess, since I have not had the time to check your report)...
As soon as one of us is able to reproduce (step by step instructions help us a lot here) you will get a case=xxx assigned. Whenever this happens, your report is filed in the bugbase. There, it won't be overseen or forgotten. It will be fixed as soon as one of the developers fixes all the other bugs he already has on his list... maybe he rates the importance of your reports higher and fixes them asap...
So if you already have such case-numbers assigned to your topics, your accusation is baseless...
And if your reports are about problems with C#:
VAX still has teething problems with C#, which are Priority #1 on the list.
We really appreciate your help, we really appreciate your input, but do not think bugs are "ignored" due to unimportance...
|
 |
 |
|
|
draza
Senior Member
France
48 Posts |
Posted - Jan 18 2005 : 5:15:23 PM
|
quote:
Originally posted by WannabeeDeveloper
quote:
Originally posted by draza
Note that I did post all of these bugs separately in several of my posts in private beta/public beta forums, but they were apparently not important enough to be taken care of.
No way! It's not that they were not important enough, they were not reproducable enough!
How shall I enter a bug into the Bugbase when I am not able to test if the bug is resolved/fixed in a new version? Shall I guess? Ask someone else? Tell me...
Oh they are reproducible just fine. Imagine this - two different machines, two different set of settings, two different sets of applications installed etc. Both exhibit exactly the same behavior. I have provided color coded examples of what happened. I have provided hints as to why these problems occur. None of my reports had bugs assigned. I was not asked for additional info, though.
quote:
I have not looked closer at your mentioned problems, but I believe (I may be wrong here) that you are the only one that has these problems, as no-one else seems to have confirmed them (as I said, this is just a guess, since I have not had the time to check your report)...
I may be the only one, but the cases are valid and show that something is badly broken. If you need code snippets that show the behavior, I can provide them.
quote:
So if you already have such case-numbers assigned to your topics, your accusation is baseless...
Hey, lighten up. Devs have every right to ignore some of the problems. They might loose a customer, but that's fine. There are other products on the market, I don't have to use this one. I want to as I've been using it for years, and that's why I'm spending time on this board reporting bugs. But I am not mad at support or you for ignoring "my" bugs. I am just noting that they were ignored.
quote:
And if your reports are about problems with C#:
VAX still has teething problems with C#, which are Priority #1 on the list.
Strange. I thought stable builds are supposed to have all important things fixed. This looks like important regression for C#, yet we got builds 129x that were marked as "final".
quote:
We really appreciate your help, we really appreciate your input, but do not think bugs are "ignored" due to unimportance...
Some bugs have to be. Even though these look like they are stupid and cosmetic (coloring) especially the first one to me looks more like bad architectural change was done along the way. But I know they might look like a cosmetic thing and as such get low priority.
I suggest we progress constructively from here.
Except for the strange coloring delay which you may or may not see (even though it's the most serious problem in the bunch) the rest is really easy to reproduce. If you can't reproduce some/all, please let me know which and what else should I provide.
Note that problems are very consistent in the sense that no kind of reinstall/clean/manual delete or anything else changes the situation even a little bit. Installing 1246 does fix 90% of the listed problems.
Drazen |
This problem when solved will be simple |
|
|
|
draza
Senior Member
France
48 Posts |
Posted - Jan 20 2005 : 02:35:09 AM
|
OK, here are some screenshots and explanations. I opened a solution with just one C# source file (all the code is on the screenshot) and waited until all parsing is done (note that I have "Parse all headers when opening a project" turned on). File was opened immediately upon opening the solution (I left it that way when I closed the solution before) and most of the coloring looked correct. Look what happened when I clicked at the end of line initializing arr2:
This is the only thing I did. I just clicked at the end of the arr2 initialization. If I now click into the AquireReaderLock method, both Aquire... and Release... methods get colored OK, after a half-second delay.
Let me describe my settings further, this is my "Fonts and colors" section:
Furthermore, "Get content from default Intellisense" is OFF, practically all other settings are ON. Now onto the problems discussion:
1. Basic rendering is definitely changed from 1246. I don't know what you did to change the default behavior, but it's not good. I never had any delays when coloring source code, and now whenever I scroll up or down methods' color is lost and I have to click into them to get the correct color.
2. I know why "using" statements are not colored. VA does not like when I wrap everything into "namespace ....". If I move "using" statements out of the namespace Exercise (a the very top of the file for example) then it gets colored correctly.
3. I said this before - some methods, usually with short names (like "Set" in the example) get colored as types probably because there is a type with the same name. However, the context here is ba.Set where ba is of BitArray type so I don't see how even without knowing which methods this type has you would not color "Set" as method??
4. I tried but could not reproduce the "property colored as type" in this small example. However, I know that for fast parser is almost impossible to distinguish between these two cases so I do not insist.
Is this better? Are you going to enter some of this into the bug base now? If not, what else do I need to provide?
If you want to enter the code as is, note that it does not compile, but you can fix it by deleting the line with "BlockCopy" or by changing it to System.Buffer.BlockCopy(arr1, 0, arr2, 0, 2); (I forgot to test if it compiles and was too lazy to take screenshots again). |
This problem when solved will be simple |
|
|
|
draza
Senior Member
France
48 Posts |
Posted - Jan 20 2005 : 03:08:56 AM
|
Finally, in order to literally show you how the weirdest problem of them all looks like, here is a screen capture of me clicking around and what the results are:
http://img26.exs.cx/my.php?loc=img26&image=vassistdelay1bq.swf
I get the same on another computer, so it's not my video card or drivers or whatever else. |
This problem when solved will be simple |
Edited by - draza on Jan 20 2005 03:09:52 AM |
|
|
|
WannabeeDeveloper
Tomato Guru
Germany
775 Posts |
Posted - Jan 20 2005 : 03:32:21 AM
|
 |
|
|
|
|
draza
Senior Member
France
48 Posts |
Posted - Jan 20 2005 : 04:07:34 AM
|
Save the project, close and reopen Visual Studio and the project. Also, make sure your settings are the same as mine (see previous posts for details).
|
This problem when solved will be simple |
|
|
|
WannabeeDeveloper
Tomato Guru
Germany
775 Posts |
Posted - Jan 21 2005 : 11:33:44 AM
|
Re-opening does show the same behaviour you describe:
First, the two Method-calls (rwl.AcquireReaderLock(-1) and rwl.ReleaseReaderLock()) are colored blue, then finally (you can actually watch VAX recolor them) in maroon. So it is not your color-scheme...
case=491
I have attached a project showing that behaviour to the case, together with a copy of the Flash-Animation...
I hope this info is enough to help the devs reproduce the wrong coloring...
|
|
Edited by - WannabeeDeveloper on Jan 21 2005 11:38:52 AM |
|
|
|
Qwertie
Junior Member
Canada
17 Posts |
Posted - Jun 28 2005 : 12:58:45 PM
|
quote:
I have not looked closer at your mentioned problems, but I believe (I may be wrong here) that you are the only one that has these problems, as no-one else seems to have confirmed them (as I said, this is just a guess, since I have not had the time to check your report)...
Just so draza isn't alone... I've noticed various coloring problems in C# myself--sometimes delayed coloring, sometimes permanently incorrect-- I hope the latest release fixes them (haven't tried it yet) |
|
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Jun 28 2005 : 7:42:47 PM
|
| This problem should be fixed in build 1418. |
|
|
|
draza
Senior Member
France
48 Posts |
Posted - Jun 29 2005 : 02:46:38 AM
|
quote:
Originally posted by support
This problem should be fixed in build 1418.
I haven't tried it yet with VAssist only, but a combination of VAssist and ReSharper is a killer combo.
ReSharper handles C# very well and VAssist is great at handling C++ so I get the best from both tools. I am really happy that you guys made the decision and decided to "play nice" with ReSharper. I am extremely happy to find out that I can now use suggestion lists from VAssist while having the rest handled by ReSharper.
Great work, guys! |
This problem when solved will be simple |
|
|
|
draza
Senior Member
France
48 Posts |
Posted - Jun 29 2005 : 5:23:10 PM
|
quote:
Originally posted by draza
I haven't tried it yet with VAssist only, but a combination of VAssist and ReSharper is a killer combo.
I found some time and tried with pure VAssist. Unfortunately, the news is not good. Most of the old problems still persist. What's even more annoying though is that C++ coloring is also whimsical, just in a different way than before.
Ah well, you get some you loose some... |
This problem when solved will be simple |
|
|
|
feline
Whole Tomato Software
United Kingdom
18939 Posts |
Posted - Jun 30 2005 : 5:13:00 PM
|
i cannot reproduce the bug from:
case=491
using the sample project. i have not noticed any C++ colouring problems using VC 2003 + VAX 1418. any clues on how i could reproduce this? i take it you have ReSharper installed  any other plugin's or variables? |
zen is the art of being at one with the two'ness |
|
|
|
draza
Senior Member
France
48 Posts |
Posted - Jun 30 2005 : 5:22:46 PM
|
quote:
Originally posted by feline
i cannot reproduce the bug from:
case=491
using the sample project. i have not noticed any C++ colouring problems using VC 2003 + VAX 1418. any clues on how i could reproduce this? i take it you have ReSharper installed any other plugin's or variables?
Like I said, the coloring problems are slightly different now than before, and they occur with VAX only - no ReSharper. It's hard to extract the code from several million lines of source we have ;) but it's not a big deal for me anymore. I've lost hope that language as complex as C++ can be reliably parsed when a lot of it is in question.
It used to annoy me that the same problem showed up in C# (that I spend more time with now) but since VAX let ReSharper do its thing, I am happy. |
This problem when solved will be simple |
|
|
|
feline
Whole Tomato Software
United Kingdom
18939 Posts |
Posted - Jul 01 2005 : 3:15:42 PM
|
i know what you mean about C++. now and then, especially when reading some of the strange code that gets posted here, i stop and wonder how you can expect anything short of a full blown compiler to make sense of the code.
certainly if you come across any specific cases i will look at them and put in a bug report if i can reproduce. |
zen is the art of being at one with the two'ness |
|
|
| |
Topic |
|
|
|
Topic Locked
