How insensitive ear to a by we try something a teeny-weeny deprecating this without linger ?

as the tiff may be something like this ?

http://www.groundtube.com

thanks for the feedback. I agree that the exact wording of the paragraph in question might not be optimal, and we will look into clarifying it, but rest assured that you do not need to create and execute a test plan for SmartInspect in order to use it.

The mentioned test routine merely states that you should make sure that our software is not causing any problems in combination with other software programs installed on the same machine/used in combination with it. As we cannot test our programs in combination with all other existing software out there (and cannot exclude liability for just ANY damage like most other EULAs do), we have to protect us in case any side effects of other software programs is causing any damage/problems.

However, the important part is that failing to do so will “only” limit our liability in regards to this kind of problems - something that other EULAs also do, but in a lot more general/aggressive wording. You do NOT lose your usage rights for SmartInspect if you fail to test it in combination with other programs. I hope this clears it up. Again, I understand that the exact wording can be improved, and we will try to do this in the coming months.

If you are still concerned that this paragraph is causing you problems, please contact me directly (dg@gurock.com) so we can discuss this further. Thanks!

Some parts of your license are just a restatement of what’s in other licenses; and while some of those are scary, they’re also not news. And yes, I should certainly test your code before I ship it in my product. But yours is the first license I’ve ever seen that contractually obligates me to test your code. Think about how that looks from a marketing perspective. Imagine if tax software had that kind of disclaimer. They’d never sell a single copy.

Your license also creates requirements I would not have expected. Yes, I should test your code before I ship it to my customers, but you’re obligating me to test your code before I *use it in production*, which is not the same thing as shipping it.

Suppose I want to use SmartInspect to debug a painting problem in my code. I’m just using it on my workstation, and I plan to remove all the SmartInspect logging before I check in my code. (That’s the sort of thing we bought it for. Shipping it is a possibility we might consider later, if we find someplace it would be helpful.)

In that scenario, I’m putting SmartInspect to its intended use, and (assuming I do track down that bug) I’m getting real benefit out of it. So that would qualify as “production use”.

I wouldn’t expect to need to form and execute a full test plan before being allowed to do local debugging, but your license requires exactly that.

(Actually, if I bought SmartInspect, and then later bought CodeSite as well, the SmartInspect license would obligate me to create a test plan for CodeSite too, since it falls under “programs of this kind”. Now, that’s *really* over the top!)

I do appreciate your transparency, and it’s good to hear your response. And yes, some of the terms are great (I should probably blog about them too, especially the “three computers” thing, since that means interesting things in our shop). But I’m concerned that you got pretty overzealous with this “you must test our code” thing, and I’m pretty sure you didn’t think through the same consequences that I’m noticing.

sorry for the late response. We currently do not have a logging library for C/C++, but this is certainly something we would love to have in the future (probably a debug-only version at the beginning).

There is also the possibility to write your own mini library in the meantime. Here are all the docs you need in case you would like to take a look. Additionally, the PHP library is a good starting point for a minimum library implementation.

http://www.gurock.com/products/smartinspect/articles/smartinspect-logging-performance-and-benchmarks/

This is cool. Can you suggest a way of doing the same using C++ using VS 2008 and linux GNU.

Thanks

Ajay

While the producer adds an item to the queue, the whole section is locked and the client cannot enter the same lock. Once the item has been added, the mutex is unlocked and the consumer can enter the critical section. Since the condition is true, it shouldn’t matter if the producer is preempted right before signaling the condition variable because the consumer does not wait anyway.

Being able to signal the condition variable after releasing the lock seems to be an implementation specific feature since in Java and .NET, for example, you are required to hold the lock while signaling the condition variable. The new condition variable API which ships with Windows Vista, on the other hand, supports this feature as well (See SleepConditionVariableCS and WakeConditionVariable):

You can wake other threads using WakeConditionVariable or WakeAllConditionVariable either inside or outside the lock associated with the condition variable. It is usually better to release the lock before waking other threads to reduce the number of context switches.

As a side note, I just learned that the new Delphi 2009 finally got support for condition variables with a new TMonitor record. Also, if you are developing against Windows Vista, it’s probably a better idea to directly use their new condition variable API.