Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
User name:
Password:
Save Password
Forgot your password?

 All Forums
 Visual Assist
 Technical Support
 Syntax highlighting completely broken
 New Topic  Reply to Topic
 Printer Friendly
Author Previous Topic Topic Next Topic  

MrDoomMaster
Tomato Guru

251 Posts

Posted - Apr 17 2007 :  7:01:31 PM  Show Profile  Reply with Quote
Below I have posted a screenshot of some obvious syntax coloring issues. The issues have a pink rectangle around them. You'll notice class object names being colored in Gray, and function names being colored in Blue. I'm using the default settings for syntax coloring in VAX build 1553. My IDE is Visual Studio 2005 Professional. These issue arise on a daily basis, I encounter them every day. Just wondering when/if you guys plan to fix this?

feline
Whole Tomato Software

United Kingdom
18939 Posts

Posted - Apr 18 2007 :  07:17:24 AM  Show Profile  Reply with Quote
Obviously this is not right, but the first step is to try and reproduce this problem.

Is this a new problem in 1553, or have you been seeing this effect for a while?

Taking the first example, the line:

m_characterInventory.clear();

if you place the caret in "clear" what does VA show in the context and definition fields?
does alt-g take you to the correct place?
what happens if you hover the mouse over "clear" while VAView is showing, I am interested in what VA shows in the bottom section, the HCB.

And the same questions about "m_characterInventory"

It is possible VA is simply confused about this type.

zen is the art of being at one with the two'ness
Go to Top of Page

MrDoomMaster
Tomato Guru

251 Posts

Posted - Apr 18 2007 :  12:25:19 PM  Show Profile  Reply with Quote
quote:
Originally posted by feline

Is this a new problem in 1553, or have you been seeing this effect for a while?


Yes, I've seen this problem ever since I started using VAX's syntax highlighting feature, which has been ages ago. Probably through the last 5-7 builds.
quote:
Originally posted by feline

Taking the first example, the line:

m_characterInventory.clear();

if you place the caret in "clear" what does VA show in the context and definition fields?


it shows:
std.vector< CharacterInfo >.clear
void clear(){...}

quote:
Originally posted by feline

does alt-g take you to the correct place?

Yes. It actually gives me the option of going to 2 different 'clear' functions in the vector header. One on line 2162 and one on line 1033.

quote:
Originally posted by feline

what happens if you hover the mouse over "clear" while VAView is showing, I am interested in what VA shows in the bottom section, the HCB.

VA View doesn't work for me, remember? I hover over ANYTHING and the bottom half of the window doesn't show anything. This has been a problem since the past 2 builds I know for a fact. It did, at one point, work properly. I never use VA View so that's why you haven't heard me mention anything about it on the forum. Just curious, is it variable names, function names, class names, etc. that causes the bottom half of the VA View to show something? I'm not really 100% sure on that. Since it shows member listings, I assume it works only on class objects/names. Not sure what it would do if you hover over a function like std::vector::clear(), for example.

quote:
Originally posted by feline

And the same questions about "m_characterInventory"

You mean 'm_missionInventory', correct? Same results for that one as well.

I hope that answers your questions. Let me know if there's anything else you need. Thanks for your excellent and continued support Feline.

Edited by - MrDoomMaster on Apr 18 2007 12:28:15 PM
Go to Top of Page

MrDoomMaster
Tomato Guru

251 Posts

Posted - Apr 18 2007 :  12:55:30 PM  Show Profile  Reply with Quote
Okay I just saw something weird...

I just tried rebuilding the symbol database AND clearing the cache. When I reopened my project, the STL Vector functions were coloring properly during the parsing process. Once the parsing process was done (status was set to 'Ready' at the bottom), they magically decided to turn BLUE again! Very weird. However, the "const std::vector< const Mission* >" line, the word "Mission" was still being colored gray. It's a class name, it should be blue. Although the STL Vector functions showed a change in color, the second case has never shown a change.

Note that boost, fmod, tinyxml, and many other third party libraries are being parsed (including windows stl, crt, platform sdk, etc) by VAX because they are used in the project. I'm not sure what conflicts may occur with those libraries.

Edited by - MrDoomMaster on Apr 18 2007 12:56:56 PM
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
18939 Posts

Posted - Apr 18 2007 :  1:44:57 PM  Show Profile  Reply with Quote
I loose track quite quickly of what works of fails for different people. So many bug reports, so many variables, it all sort of blurs together after a while

VA View not working is a slight worry, it suggests VA just has no idea what it is looking at in your code base. This may be a good line of attack later on.

Some form of library conflict on "vector" makes sense, and could be a little difficult to pin down. Going back to the screen shot:

the 2nd highlighted item gives:

const std::vector< const Character* >& chars = camp->m_locked->characters;

and the 4th highlighted item gives:

const std::vector< const Skyblade* >& skyvec = m_shipyard.GetAllSkyblades();

Are "Character" or "Skyblade" library classes, or your classes? I can see "Character" existing in a library you are using, but given the other names in this code "Skyblade" looks like one of your classes.

If it is, what colouring do you get for the code:

static void testColourOfVariable()
{
    Skyblade foo;
}


I am wondering if VA is always confused about Skyblade, or if it is only confused when using this around templates.

The colouring change you saw is normal. While VA is doing the its first major pass it does not apply any of its own syntax colouring to your code. Only once it has finished, and it knows what is what, does this happen, so you will see your code go from "bland" to "nice" suddenly.

This confirms that VA's parsing is responsible for this colouring, as expected, but good to be sure.

zen is the art of being at one with the two'ness
Go to Top of Page

MrDoomMaster
Tomato Guru

251 Posts

Posted - Apr 18 2007 :  2:44:37 PM  Show Profile  Reply with Quote
quote:
Originally posted by feline

I loose track quite quickly of what works of fails for different people. So many bug reports, so many variables, it all sort of blurs together after a while

Understandable :)

quote:
Originally posted by feline

Are "Character" or "Skyblade" library classes, or your classes?

Both are my classes.

quote:
Originally posted by feline

static void testColourOfVariable()
{
    Skyblade foo;
}


I get correct coloring for 'Skyblade' here, it's blue.

quote:
Originally posted by feline

The colouring change you saw is normal. While VA is doing the its first major pass it does not apply any of its own syntax colouring to your code. Only once it has finished, and it knows what is what, does this happen, so you will see your code go from "bland" to "nice" suddenly.

I know what you're talking about here but this is not the case. I have a button on one of my toolbars for 'reparse current file' (the VAX feature). If I click this, the file actually shows VAX syntax highlighting DURING the parsing process. Also, I can't quite tag the exact trigger for the second case, but sometimes scrolling through the document or flipping through document tabs in Visual Studio causes the VAX syntax coloring to appear as well.
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
18939 Posts

Posted - Apr 19 2007 :  10:16:54 AM  Show Profile  Reply with Quote
Clearly something is going on here, but I am not sure what, yet. I wonder if this second update to the colouring is related to VA evaluating some template class somewhere...

Can you try copy / pasting the following function please, and see what happens to the colouring of Skyblade? I am trying to pin down the trigger, in the hopes we can move forward from there, one step at a time.

template<typename T>
class felineTemplate
{
private:
    T *m_pStored;

public:
    const T *getStoredItem() const	{ return m_pStored; }
    void setStoredItem(T *pStore)	{ m_pStored = pStore; }
}

static void testColourOfVariable()
{
    Skyblade foo1;
    const Skyblade &foo2 = foo1;
    felineTemplate<Skyblade> foo3;
    felineTemplate< const Skyblade* > foo3;
    felineTemplate< const Skyblade* >& foo4 = foo3;
    std::vector< Skyblade > foo5;
    std::vector< Skyblade* > foo6;
    std::vector< const Skyblade* > foo7;
    std::vector< const Skyblade* >& foo8 = foo7;
    const std::vector< const Skyblade* >& foo9 = foo7;

    const std::vector< const Skyblade* >& skyvec = m_shipyard.GetAllSkyblades();
}


Where does the colouring break?
Does commenting out certain lines change where the colouring breaks?

zen is the art of being at one with the two'ness
Go to Top of Page

MrDoomMaster
Tomato Guru

251 Posts

Posted - Apr 19 2007 :  6:29:50 PM  Show Profile  Reply with Quote
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
18939 Posts

Posted - Apr 20 2007 :  08:25:32 AM  Show Profile  Reply with Quote
*um*

Can you try commenting out most of the function, keeping only the first two lines? I am rather bothered by the invalid colouring on:

    const Skyblade &foo2 = foo1;


I am hoping this is some form of cascade error from further down the function, or from something else. Otherwise this seems to suggest something has confused the meaning of either "const" or "&"

zen is the art of being at one with the two'ness
Go to Top of Page

MrDoomMaster
Tomato Guru

251 Posts

Posted - Apr 20 2007 :  11:18:48 AM  Show Profile  Reply with Quote
Note that I'm just appending the code you gave me to the end of some random source file in my project. This way the definition for Skyblade can be found. Having said this, we can't rule out the fact that there's library parsing conflicts causing these issues, and centralizing focus on this small code sample may not help find the issue. However, I understand you're trying to pin down the issue by various tests, so I'm not complaining. Just making sure you knew that I didn't create an entirely new project for your sample code. Let me know if this is what you intended.


Edited by - MrDoomMaster on Apr 20 2007 11:19:27 AM
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
18939 Posts

Posted - Apr 20 2007 :  1:31:31 PM  Show Profile  Reply with Quote
We may need to try a whole new project, but I suspect the problem will not show up there.

This is not what I expected to see at all. Can you try:

static void testColourOfVariableTwo()
{
Skyblade bar1;
const Skyblade bar2;
Skyblade &bar3 = bar1;
Skyblade& bar4 = bar1;
Skyblade & bar5 = bar1;
const Skyblade &bar6 = bar1;
const Skyblade& bar7 = bar1;
const Skyblade & bar8 = bar1;
}

Do the context and definition fields show the same information when you place the caret into a blue "Skyblade" and a grey "Skyblade"?

Does alt-g work correctly for both blue and grey lines?

zen is the art of being at one with the two'ness
Go to Top of Page

MrDoomMaster
Tomato Guru

251 Posts

Posted - Apr 20 2007 :  1:37:46 PM  Show Profile  Reply with Quote
Update:

I did my own little test. I took boost out of my project include paths and found that by not parsing the boost library, visual assist is actually able to:

1) Find a definition for std::vector::push_back()
2) Color a couple of STL container related methods (begin(), end(), resize(), push_back(), etc). However, std::vector::size() seems to not color properly in various places (it appears gray, look at my initial screenshot). Other places size() appears the correct color.

I can zip up the boost library I have and send it to you guys if you want, but I can't guarantee it will be a small file. I'd have to probably put it on rapid-share for you to download.

Although removing boost from the VAX parsing path fixed a FEW problems, most of them still persist.
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
18939 Posts

Posted - Apr 20 2007 :  2:49:02 PM  Show Profile  Reply with Quote
I have the standard boost library already installed on a couple of my machines. Are you using a standard version, or have you modified your version?

There are some known problems with specific boost headers, but from memory nothing quite like this.

std::vector::size(), does this colour consistently in files?
Is it always wrong in file "foo1.cpp" and always right in file "foo2.cpp"?

If your #include statements are always at the top of the file (most people do this, but not everyone) then if this problem (there are probably several *sigh*) is being triggered by one or more problem header files then the colouring should be consistent, and comparing the files, and perhaps even just commenting out #include lines and waiting for VA to reparse and update the colouring will tell you which file is causing the problems.

If this works then I stand a chance of reproducing this problem here.

zen is the art of being at one with the two'ness
Go to Top of Page

MrDoomMaster
Tomato Guru

251 Posts

Posted - Apr 20 2007 :  3:11:05 PM  Show Profile  Reply with Quote
quote:
Originally posted by feline

I have the standard boost library already installed on a couple of my machines. Are you using a standard version, or have you modified your version?

Modified version, has some libraries in it that don't come with the publicly available version of boost. This is why I offered to send it to you, possibly so you may pass it on to QA or the developers for testing. Just let me know.

quote:
Originally posted by feline

std::vector::size(), does this colour consistently in files?

No. Some files color correctly, others it appears gray (like in the example screenshot in my first post in this thread).

quote:
Originally posted by feline

Is it always wrong in file "foo1.cpp" and always right in file "foo2.cpp"?

Not sure what you are asking here. If you're asking if I can use the size() function multiple times in a single file and get consistent results for *that file only*, then yes I do get some consistency there. For example, if in one file size() appears wrong, all other occurrences of it will appear wrong as well (having the same wrong color too). If it appears correctly once in a different file, all other occurrences are correct as well.

quote:
Originally posted by feline

If your #include statements are always at the top of the file (most people do this, but not everyone) then if this problem (there are probably several *sigh*) is being triggered by one or more problem header files then the colouring should be consistent, and comparing the files, and perhaps even just commenting out #include lines and waiting for VA to reparse and update the colouring will tell you which file is causing the problems.

Commenting out the includes doesn't seem to help, since VAX will still find symbols regardless of your includes (assuming it was included in *some* file at *some* point so that it was parsed), at least in my experience. I tried commenting out various boost related and other major 3rd party API includes with no luck. Too many files in the code-base include the very same files, so it would be very time consuming to ensure the respective files weren't parsed.
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
18939 Posts

Posted - Apr 20 2007 :  5:14:02 PM  Show Profile  Reply with Quote
I have just emailed you via the forum, if you reply to the email with a zip of your Boost library attached it should reach me without any problems.

Can you include a list of the main headers you are including from your boost library? This way I can try including them here. Otherwise the entire library is quite a lot of code to consider

I have seen some problems where commenting out a #include line fixes the problem, but they were in simpler projects.

zen is the art of being at one with the two'ness
Go to Top of Page

MrDoomMaster
Tomato Guru

251 Posts

Posted - Apr 23 2007 :  12:40:06 PM  Show Profile  Reply with Quote
Email was sent to you last Friday, just to make it known.
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
18939 Posts

Posted - Apr 23 2007 :  3:14:37 PM  Show Profile  Reply with Quote
I have the email, I just took the weekend off I should have replied to say it arrived, sorry about that. I will try and get to this later today or tomorrow.

zen is the art of being at one with the two'ness
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
18939 Posts

Posted - Apr 24 2007 :  07:56:11 AM  Show Profile  Reply with Quote
I have had a look at this, but so far I am not seeing any signs of problems. Using VS2005 and VA 1554 and my test project I have extracted your boost library, placed it on my C:, and then edited:

Project properties -> C/C++ -> General -> Additional Include Directories

so that it read:

C:\\mini-boost\\COMMON;C:\\mini-boost\\WIN;C:\\WTL75\\include

Following a quick sort and unique on the include files you sent I added the following code to a CPP file:

#include <boost/bind.hpp>
#include <boost/cstdint.hpp>
#include <boost/fusion/sequence/container/map.hpp>
#include <boost/fusion/sequence/intrinsic/at_key.hpp>
#include <boost/lexical_cast.hpp>
// #include <boost/mpl/meassert.hpp>
#include <boost/next_prior.hpp>
#include <boost/pool/pool_alloc.hpp>
#include <boost/scoped_array.hpp>
#include <boost/scoped_ptr.hpp>
#include <boost/static_assert.hpp>
#include <boost/tokenizer.hpp>
#include <boost/type_traits/is_float.hpp>
#include <boost/type_traits/is_integral.hpp>
#include <boost/type_traits/is_pod.hpp>
#include <boost/utility/enable_if.hpp>

class Skyblade {};

static void testColourOfVariableTwo()
{
	Skyblade bar1;
	const Skyblade bar2;
	Skyblade &bar3 = bar1;
	Skyblade& bar4 = bar1;
	Skyblade & bar5 = bar1;
	const Skyblade &bar6 = bar1;
	const Skyblade& bar7 = bar1;
	const Skyblade & bar8 = bar1;
}


I had to comment out one of the include lines since I do not have that file. Having commented that out this code compiles quite happily, and all instances of "Skyblade" are coloured correctly.

This seems to mean we can eliminate Boost from our investigations, which is something.


If you add the new test function:

class FelineSky {};

static void testColourOfVariableThree()
{
	FelineSky bar1;
	const FelineSky bar2;
	FelineSky &bar3 = bar1;
	FelineSky& bar4 = bar1;
	FelineSky & bar5 = bar1;
	const FelineSky &bar6 = bar1;
	const FelineSky& bar7 = bar1;
	const FelineSky & bar8 = bar1;
}


do you now get the correct colour for all instances of "FelineSky"?

I am wondering if this problem is somehow related to the class Skyblade, or if it is independent of the class being used.

zen is the art of being at one with the two'ness
Go to Top of Page

MrDoomMaster
Tomato Guru

251 Posts

Posted - Apr 24 2007 :  12:07:23 PM  Show Profile  Reply with Quote
Interesting!



The Skyblade class doesn't seem to color properly when a & symbol appears to the right of it. Maybe this is the problem? Not sure...

Anyhow, I'll provide the class interface to Skyblade. I am not sure at this point if the implementation has anything to do with it:

	class Skyblade
	{
	public:
		ResourceId id;
		std::wstring name;
		ResourceId iconID;
		u32 cost;
		std::wstring description;
		ResourceId entityID;
		u32 numWeaponSlots;
		std::pair< fx24_8, fx24_8 > speedRange;
		std::pair< u32, u32 > healthRange;
		std::pair< method::aabb2<fx24_8>, method::aabb2<fx24_8> > collisionRange;
		bool isCustom;
		ResourceId preloadId;

	public:
		Skyblade( ResourceStream& stream );
	};


The class isn't that big, I can't imagine what's confusing it.

Let me know what else I can do to help. Thanks a ton for your help Feline!

::EDIT::

If I put:

class Skyblade {};


in front of the header for testColourOfVariableFour(), just like the one for FelineSky, all of the 'Skyblade' words color properly in the function. If I take it away, however, some of them start coloring gray.

Even when I comment out the Skyblade class (pasted above) completely out, it STILL colors the same as in the screenshot above. I've actually commented out the class, it shouldn't be able to find Skyblade! I've even commented out all of the forward declarations. At the moment, there's no such thing as 'class Skyblade' anywhere in the code! Why would it still be coloring blue/gray?

Edited by - MrDoomMaster on Apr 24 2007 12:24:36 PM
Go to Top of Page

MrDoomMaster
Tomato Guru

251 Posts

Posted - Apr 24 2007 :  12:29:11 PM  Show Profile  Reply with Quote
I did some more testing:

I copy/pasted the testColorOfVariableFour() function in my previous screen shot to different files. I have tested the following files:

Engine.cpp - Colors properly
Obsoletes.cpp - Defective coloring
Shipyard.h (source of the Skyblade class) - Colors properly
Shipyard.cpp (contains implementations for Skyblade class) - Defective Coloring

See, it depends on what file I paste the function in. Odd eh?
Go to Top of Page

MrDoomMaster
Tomato Guru

251 Posts

Posted - Apr 24 2007 :  2:43:28 PM  Show Profile  Reply with Quote
I found the source of the coloring problem and have taken the time to create a test project that can be used to see the issue. An email has been dispatched to Feline with the project attached.
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
18939 Posts

Posted - Apr 24 2007 :  3:52:39 PM  Show Profile  Reply with Quote
I have the email, many thanks for this!

I was sitting here, reading this thread, thinking "why did I go into computer programming again?" I am glad you figured this out, since I was just about out of ideas.

I see exactly what you describe, running VA 1554. It is very unexpected, but 100% consistent.

case=6182

zen is the art of being at one with the two'ness
Go to Top of Page

MrDoomMaster
Tomato Guru

251 Posts

Posted - Apr 24 2007 :  5:11:49 PM  Show Profile  Reply with Quote
No problem :)

One thing to note, however, is that the class definition (or in the case of the sample I sent you, 'FooClass') must be in a DIFFERENT file. If you place the definition for FooClass in main.cpp, it will color properly regardless of 'const' being in front of the template parameter or not. To break the syntax coloring, the class must not be in main.cpp.

I apologize for not having this documented in the source I sent you.

There may be other issues causing coloring to become defective, but I cannot determine how many coloring issues will be solved until that bug is fixed. Unlike the sample I sent you, the original code base uses tons of templates, most of which follow the same pattern in the sample project that breaks the syntax highlighting. We'll see what else breaks when it's fixed.

Take care.

Edited by - MrDoomMaster on Apr 24 2007 5:14:05 PM
Go to Top of Page

MrDoomMaster
Tomato Guru

251 Posts

Posted - Aug 09 2007 :  5:23:02 PM  Show Profile  Reply with Quote
Hi,

I'm posting on this thread to bring the issue back to life again. I'm always looking at new builds as they come out to see if any syntax highlighting issues have been resolved. Unfortunately, I'm always disappointed in that even to this day build 1559 still has the very same issues.

For the longest time, syntax highlighting in VAX has had problems. The very mere fact that the coloring bugs are unpredictable and that the cause for these problems is not apparent nor does it follow any certain pattern says to me that the underlying code implementation for this feature is "hacky", to say the least.

While I do feel a bit impatient about the fact that it remains broken, I'm also very understanding that it will come in time. The development team for VAX I'm sure is very busy solving many more "important" bugs. I'm not going to rush the issue; I'm just posting to bring this issue once again to everyone's attention to remind them that while this issue may not be the definition of important to the company, it is definitely one that has survived many many months and many many VAX builds. So, what is the better decision? Prioritizing more severe bugs, or letting minor (yet annoying) bugs survive endlessly?

Perhaps an update on where this issue stands in production and on the roadmap for VAX would suffice. While this issue does not interrupt my day-to-day activities with VAX, it does make me think about how VAX syntax coloring is so very broken every day.

I hope things are going well on your end. Take care and great job on a great product!
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
18939 Posts

Posted - Aug 10 2007 :  12:54:46 PM  Show Profile  Reply with Quote
I certainly agree that VA's syntax highlighting has problems, but to be honest I am not really aware of that many problems with it. The fact that you are seeing unpredictable problems is a concern, certainly this is not my every day experience of VA's syntax highlighting, and I spend quite a lot of time trying to break VA.

There are a few things working against us when it comes to syntax highlighting. Perhaps the biggest is a combination of "context" and speed. Syntax highlighting has to run very fast, since it it took several seconds to apply the highlighting every time you pressed page up / page down then clearly this would be very little use.

For a speed comparison, assuming you still have VS2005's intellisense enabled and have left the IDE's colouring of inactive code turned on wrap some lines of code in #if 0, #endif and then see how long it takes before the IDE works out it has to change the colour.

Certainly this colouring is nothing like "real time".

So VA's colouring has to run quickly, but I also referenced context. Consider the code:

static int foo() { return -1; }

static void useFoo()
{
    int foo = foo();
}

now this does not actually compile, so it is an unfair example, but it does illustrate the basic point of "context", since symbols are often re-used in different contexts, and have totally different meanings, which require different colouring. VA has to apply the colouring in the order the IDE dictates, since VA has to colour the text after the IDE draws it, not before it draws it.

So VA has to rely on educated guess work to figure out the symbols context, in order to work out the correct colouring to apply, in order to comply with the the IDE's drawing order and the speed requirement.

So in one sense you are quite right, the whole feature is one big "hack", since I really hope no one who wrote their own editor from scratch would try to do it like this

Now having said all of this, nearly all of the current bugs with colouring are "well defined". By this I mean I can give you a set of steps to reproduce them on demand. Plus once you understand the trigger they are normally clear, consistent and make sense. A good example of this type of bug is:

class CTestColor
{
    void colouredAsFunction();
    CTestColor();
}

here there are two functions in the class, but only one will be coloured as a function.

I am not sure how much of this actually helps, but hopefully it gives some background

Given the problems I had reproducing this specific bug I think it is fair to say that case=6182 only happens under fairly "odd" conditions, otherwise it would have been easier to reproduce.

I have bumped the priority on this for you, since this specific bug may actually be the root cause of most, if not all, of the random colouring problems you are seeing.

At the very least it would be good to remove the word "random", so you are seeing bugs, but at least they are predictable and to a degree "reasonable". I am happy to try and get to the bottom of some of these with you, if you are interested.

As for which bugs to fix first, and where to allocate resources, this is a difficult question. Cast an eye over the suggestions section of the forum, and we get enough feature requests to keep a good number of programmers busy full time

Bug reports, what is "trivial" for one person (it never bothers them) is critical for another person (the IDE crashes, random code is edited, etc).

One factor we use is how many people are asking for a feature, or complaining about a bug. This is not everything, but it is one element, since a bug that everyone is bothered by is probably more urgent than a bug that effects 2 users.

A second factor is how interested someone is in "their bug". If the bug was reported 4 years ago and no one has mentioned it since this is probably not a "critical" issue.

A third factor is how hard the change is.

Somehow we have to juggle these various elements. We may not always get it exactly right, but I hope we do fairly well, and we are trying to improve.

zen is the art of being at one with the two'ness
Go to Top of Page

MrDoomMaster
Tomato Guru

251 Posts

Posted - Aug 10 2007 :  1:30:18 PM  Show Profile  Reply with Quote
Thank you for your reply. You've definitely explained a lot I was wondering about. I've never had a problem being patient. However, sometimes I allow myself to become impatient so that I persist to check the status on a bug fix or perhaps something else, if that makes sense. As I said before, the syntax coloring issue is not interrupting my daily activities. This makes it even easier to be patient. I guess we'll see what the future holds. Thanks again feline.
Go to Top of Page
  Previous Topic Topic Next Topic  
 New Topic  Reply to Topic
 Printer Friendly
Jump To:
© 2023 Whole Tomato Software, LLC Go To Top Of Page
Snitz Forums 2000