This reminds me of a something that happened in London a few years ago. A rail bridge (The hungerford bridge), over the Thames, was being expanded to add footbridges along each side.
The builders had to spend a huge amount of money to redesign the bridge to ensure that pilings driven into the river bed could not detonate WW2 bombs (worries that they may breach an underground tunnel running nearby).
60 years on and we still have issues with unexploded ordinance. An this is ordinance that was never designed to be hidden or hard to find.
But anti-tank mines can be detonated by things that are not tanks such as busses and lorries and even cars if the mines become unstable (as most explosives do) due to age.
Fom this statementI take it that you only write unit tests after you have found a problem. After all unitll your code fails there is no problem therefore no reason to write unit tests. - that's a pretty bizarre inference. No, I write unit tests either before or during development of the actual business code. But these bug detectors don't make much sense if normal testing and operations show no problem.
It was taken directly from your statement: I say don't bother unless there is a problem.
that you shouldn't invest in preventative measures, as they are an expense, without reason to do so. You write unit tests. Why?. Becuase they can help rule out some bugs before they end up in the wild. I presume you also write integration and regression tests. These catch different kinds of errors to unit tests. Running static checkers can catch other categories of problem. Why not use them. Admittedly I would not put them into the normal build system (our codebases take too long to commit as it is) but why not in the nightly build along with your code coverage metrics?
Obviously my arguments havn't convinced you so I shall leave you in peace.
Profilers are very usefull. Unit tests are very usefull. Static code checkers are also usefull. Try one. Unless your codebase is perfect they will find issues with it. Many of the issues will not be bugs (depending on the options you set on the checker) but will likely indicate a poor or overly complex coding style. It will likey take 30 mins of your time to assess the utility of the checker. It may save you far more time then that. I partially agree with you that the checkers are not as good as some of thier proponents make them out to be but they do serve a useful purpose. I still have not integrated any into the build system I use (a big task for us) however I have run a few and they have found problems in our code. Note that they have not found all problems in our code. We still have bugs even after copious unit tests, profiling, static analysis. They can rule out some issues that unit tests cannot, they can rule out some issues before you need to take a debugger/profiler to your code. They can find some issues that you are remarkably unlikely to find by other means.
As for halting, the theory sates that you cannot come up with a general algorithm that will prove all code/input pairs halt. This does not mean that a generic algorithm cannot prove that halting occurs for a specific code/input pair. Event if, for the pair you are using, the general algorithm cannot prove the code halts it does not mean that the code fails to halt. It only means that the algorithm used cannot prove that it halts. This would be a reason to investigate the code further.
help with what? You are giving a blanket statement here that the tools will help with something. I say don't bother unless there is a problem. Sure, if there is a problem do what you want, load these tools, try them. I bet at the end you will end up debugging by hand. Fom this statementI take it that you only write unit tests after you have found a problem. After all unitll your code fails there is no problem therefore no reason to write unit tests. It is a blanket statement I made and I made it for the following reason: Even if the static checker finds no issues with the code that is failing it has just ruled out a large number of code issue categories. Is there a downside to this?
I can only suggest that you try one and see what it does for you.
J2EE is a framework that tries to hide multithreading issues from the coder. As such (and per recomendation by sun) you should try to avoid creating your own threads. However threading issues still affect you. Perhaps it is a cache you need all servlets/beans/whatever to use. You may be able to use a third party library you may not. Even if you do use a third party library are you 100% confident that it has no synchronization/threading issues? These tools can help.
I have noticed that many coders do not understand all of the issues presented by thread handling, concurrency and re-entrent behaviour. I don't have time to check all code and even if I could I do not have a memory that enables me to correlate all calls to an entity. These checkers can check all of your code and they can remember all useages of an entity. They are thorough in a way that humans can not be. Give it a try you may be surprised.
Unfortunately you cannot write unit tests that will find all race conditions. They may find some (common one that will occur often) but unless they can run forever they will not find all. These detectors are a useful tool, nothing more, nothing less. They are not supposed to replace good unit tests. However they can find issues that units tests cannot. Even if your unit tests give you 100% coverage that only means that they exercise all of your code. It does not mean they excersie all of your code in all situations. These code checkers can help a bit. Since most are fully automated there is little reason not to use them (i.e. no coding required for you to use them)
Most are trivial to run on your code, in a one off fashion. Try one or two and see what results they give you. If they find a lot of issues then it may be worth your while investing the time to integrate one, or more, of them into your build system. If they don't then don't use them.
Many of these checkers are basically advanced pattern matchers. They contain a set of pattern templates that will match code (or bytecode) that contains bugs. They check for, as an example, a variable that is used without a check (if(null!=bla)) but may not be assigned. The compiler does not catch this because the variable is not marked final. Its a trivial pattern to check for.
They can also perform some concurrency checks. Such as looking for a pair of locks that are obtained in different order in different parts of your code. Or for waiting threads that can never be woken up (i.e. nothing calls notify on the lock). Note that in java the second example is not necessarily a bug.
Some of the patterns have high false positives, some are almost guarenteed to find a bug. Unfortunately these tests can be quite expensive to perform and are not guarenteed to find issues. I think this is why they are not in the compiler. The compiler tells you about everything that can be guarenteed to be a problem. In java the compiler tells you if you break the language specification. It does not tell you if you do stupid things that the language spec allows you to do.
There is nothing in the consitution regarding religion. Freedom of religion was the first amendment, ratified in 12/15/1791 France abolished its state and therefore the role of religion in it on Aug 4th 1789. By July 1790 religious orders where being suppressed and the clergy where required to swear to adhere to the state-controlled Civil Constitution of the Clergy. Note there was no freedom of religion in france but there was a definate seperation of chruch from the state (and the state from it's head)
They beat america to it, admittedly on a technicality:P
As for The UK having a State religion. It does, however as I said in my earlier post; in the UK the government IS NOT THE STATE. There is no government endorsed religion (which is what having a state religion normally means).
UK, france and many other countries have seperation of church and state.
In the UK its a peculiar seperation in the the head of state, the queen, is the head of the church of england. However the government of the UK is not beholden to the head of state in any real way. In theory the queen could sack the prime minister or any other member of parliment. She also has the right to refuse to apoint the prime minister (and therefore the government) however doing this would remove her as head of state. There is along standing agreement that the monarchy keeps its nose out of government.
A social contract does not require Government. What the founding fathers did is set up a social contract and then explicity stop the Government from modifying specific aspects of it. The idea that anybody has "automatic" rights is silly without a society that allows everybody to have those rights. Admittedly you could claim those rights if you did not live in a society but you would not have any protection of them.
In the UK there is no explicit limitation on the government wrt allowing/denying rights and little written down to "grant" anything to anyone. There is instead a huge pile of law that supports the edifice.
Turing did not say "you cannot prove a algorithm will terminate" he said "you cannot prove that all arbitrary algorithms will terminate on a turing machine" First, computers are NOT turing machines. They are bounded in storage (although the bounds are pretty high nowadays). Second. It is possible to prove that a given algorithm will terminate. Just not all algorithms. Therefore a tool can prove that your algorithm terminates. If it does terminate you are set. If it cannot be proven to terminate it does not mean that it won't terminate it just means that it cannot be proven to terminate. (termination is a good thing in this context)
Shared dependencies are a problem if you don't use classlaoders properly. Classloaders are dificult to use correctly but are very very powerful.
And VM's CAN unload code that is no longer referenced if you use classloaders correctly. Once the classloader becomes unreachable then all classes it was responsible for loading can be collected. Note that this does not mean they WILL be collected. Collection occurs if GC thinks it needs more space in the perm generation to load more classes.
I suggest you read this http://www.w3.org/Addressing/URL/url-spec.txt and look at who wrote/edited it. The committee could have defined URL's in pretty much any way he wished. As long as they provided a mechanism to map the authority of the URL to DNS there would have been no problem.
Big and little endian host/domain names are trivial to convert between.
All the house of loards has the power to do is send bills back to the House of commons or let them pass. They don't get to make law and they don't get to permenently stop a from passing. The most they can do is slow the process down and bring it to the attention of the public. This is a very valuable role.
Most cars that offer integration with ipod players actually integrate with any USB mass storage device. They just advertise ipod compatibility as ipod has about 80% market share. Cars don't provide you with the ipods user interface and since it is generally stuffed in a draw its looks don't matter much either in this situation.
I bought a Q-BE (I think they are called Mobiblue or some such in the states). Its smaller, lighter, cheaper, has a longer lasting battery and better sound quality than the ipod nano. Its not in bondage to itunes, has no DRM and more importantly its interesting. People ask about it.
It competes with the nano. 2, 4, 6 gig. You don't get 200 albums in that amount of space. You are more likely to get somwhere in the 20 - 60 album range (depending on capacity and encoding). Different spec == different requirements for the UI.
fsfs seems quite reliable for us (we use it in one of our products), however it can grind to a halt on some filesystems.
Some bright spark thought it would be a good idea for each revision to be stored as a seperate file in a single directory. Most file systems don't take kindly to 40,000 files in a single dir. It, for some odd reason, really hurts thier performance.
JSF is an attempt to produce a componentised development envoironment. You use it a bit like a widget library. It can theoretically render to anything although must come with a basic html implementation. We are currently using it with facelets (a light weight templating system).
Its not bad but its component abstraction does not go far enough in my opinion. You still spend too much time fiddling with tags to make it work (its lousy at reporting any kind of meaning full errors. Facelets helps alot).
A big problem we have is with the lack of namespaces in javascript. Myfaces and other third party ajaxified components bring in thier own JS and can cause hard to find locations.
It works well for most stuff. Knocking up prototypes is very fast and easy.
Slashdot Mirror
The acidic contents are not in contact with the metal. The cans are lined with plastic. I'm not saying they do use alloy or not I don't know
This reminds me of a something that happened in London a few years ago. A rail bridge (The hungerford bridge), over the Thames, was being expanded to add footbridges along each side.
The builders had to spend a huge amount of money to redesign the bridge to ensure that pilings driven into the river bed could not detonate WW2 bombs (worries that they may breach an underground tunnel running nearby).
60 years on and we still have issues with unexploded ordinance. An this is ordinance that was never designed to be hidden or hard to find.
But anti-tank mines can be detonated by things that are not tanks such as busses and lorries and even cars if
5 .htm
the mines become unstable (as most explosives do) due to age.
http://www.alertnet.org/thenews/newsdesk/BKK16856
Fom this statementI take it that you only write unit tests after you have found a problem. After all unitll your code fails there is no problem therefore no reason to write unit tests. - that's a pretty bizarre inference. No, I write unit tests either before or during development of the actual business code. But these bug detectors don't make much sense if normal testing and operations show no problem.
It was taken directly from your statement:
I say don't bother unless there is a problem.
that you shouldn't invest in preventative measures, as they are an expense, without reason to do so. You write unit tests. Why?. Becuase they can help rule out some bugs before they end up in the wild. I presume you also write integration and regression tests. These catch different kinds of errors to unit tests. Running static checkers can catch other categories of problem. Why not use them. Admittedly I would not put them into the normal build system (our codebases take too long to commit as it is) but why not in the nightly build along with your code coverage metrics?
Obviously my arguments havn't convinced you so I shall leave you in peace.
matfud
Profilers are very usefull. Unit tests are very usefull. Static code checkers are also usefull. Try one. Unless your codebase is perfect they will find issues with it. Many of the issues will not be bugs (depending on the options you set on the checker) but will likely indicate a poor or overly complex coding style. It will likey take 30 mins of your time to assess the utility of the checker. It may save you far more time then that. I partially agree with you that the checkers are not as good as some of thier proponents make them out to be but they do serve a useful purpose. I still have not integrated any into the build system I use (a big task for us) however I have run a few and they have found problems in our code. Note that they have not found all problems in our code. We still have bugs even after copious unit tests, profiling, static analysis. They can rule out some issues that unit tests cannot, they can rule out some issues before you need to take a debugger/profiler to your code. They can find some issues that you are remarkably unlikely to find by other means.
As for halting, the theory sates that you cannot come up with a general algorithm that will prove all code/input pairs halt. This does not mean that a generic algorithm cannot prove that halting occurs for a specific code/input pair. Event if, for the pair you are using, the general algorithm cannot prove the code halts it does not mean that the code fails to halt. It only means that the algorithm used cannot prove that it halts. This would be a reason to investigate the code further.
help with what? You are giving a blanket statement here that the tools will help with something. I say don't bother unless there is a problem. Sure, if there is a problem do what you want, load these tools, try them. I bet at the end you will end up debugging by hand.
Fom this statementI take it that you only write unit tests after you have found a problem. After all unitll your code fails there is no problem therefore no reason to write unit tests. It is a blanket statement I made and I made it for the following reason: Even if the static checker finds no issues with the code that is failing it has just ruled out a large number of code issue categories. Is there a downside to this?
matfud
I can only suggest that you try one and see what it does for you.
J2EE is a framework that tries to hide multithreading issues from the coder. As such (and per recomendation by sun) you should try to avoid creating your own threads. However threading issues still affect you. Perhaps it is a cache you need all servlets/beans/whatever to use. You may be able to use a third party library you may not. Even if you do use a third party library are you 100% confident that it has no synchronization/threading issues? These tools can help.
I have noticed that many coders do not understand all of the issues presented by thread handling, concurrency and re-entrent behaviour. I don't have time to check all code and even if I could I do not have a memory that enables me to correlate all calls to an entity. These checkers can check all of your code and they can remember all useages of an entity. They are thorough in a way that humans can not be. Give it a try you may be surprised.
matfud
Unfortunately you cannot write unit tests that will find all race conditions. They may find some (common one that will occur often) but unless they can run forever they will not find all. These detectors are a useful tool, nothing more, nothing less. They are not supposed to replace good unit tests. However they can find issues that units tests cannot. Even if your unit tests give you 100% coverage that only means that they exercise all of your code. It does not mean they excersie all of your code in all situations. These code checkers can help a bit. Since most are fully automated there is little reason not to use them (i.e. no coding required for you to use them)
matfud
Most are trivial to run on your code, in a one off fashion. Try one or two and see what results they give you. If they find a lot of issues then it may be worth your while investing the time to integrate one, or more, of them into your build system. If they don't then don't use them.
Many of these checkers are basically advanced pattern matchers. They contain a set of pattern templates that will match code (or bytecode) that contains bugs. They check for, as an example, a variable that is used without a check (if(null!=bla)) but may not be assigned. The compiler does not catch this because the variable is not marked final. Its a trivial pattern to check for.
They can also perform some concurrency checks. Such as looking for a pair of locks that are obtained in different order in different parts of your code. Or for waiting threads that can never be woken up (i.e. nothing calls notify on the lock). Note that in java the second example is not necessarily a bug.
Some of the patterns have high false positives, some are almost guarenteed to find a bug. Unfortunately these tests can be quite expensive to perform and are not guarenteed to find issues. I think this is why they are not in the compiler. The compiler tells you about everything that can be guarenteed to be a problem. In java the compiler tells you if you break the language specification. It does not tell you if you do stupid things that the language spec allows you to do.
matfud
The most efficient ICE in the world at the moment manages over 50 percent thermal efficiency
http://www.bath.ac.uk/~ccsshb/12cyl/
You'd need a fooking big SUV to put it in though
matfud
There is nothing in the consitution regarding religion. Freedom of religion was the first amendment, ratified in 12/15/1791
:P
France abolished its state and therefore the role of religion in it on Aug 4th 1789. By July 1790 religious orders where being suppressed and the clergy where required to swear to adhere to the state-controlled Civil Constitution of the Clergy. Note there was no freedom of religion in france but there was a definate seperation of chruch from the state (and the state from it's head)
They beat america to it, admittedly on a technicality
As for The UK having a State religion. It does, however as I said in my earlier post; in the UK the government IS NOT THE STATE. There is no government endorsed religion (which is what having a state religion normally means).
matfud
Nope,
UK, france and many other countries have seperation of church and state.
In the UK its a peculiar seperation in the the head of state, the queen, is the head of the church of england. However the government of the UK is not beholden to the head of state in any real way. In theory the queen could sack the prime minister or any other member of parliment. She also has the right to refuse to apoint the prime minister (and therefore the government) however doing this would remove her as head of state. There is along standing agreement that the monarchy keeps its nose out of government.
Not quite true.
A social contract does not require Government. What the founding fathers did is set up a social contract and then explicity stop the Government from modifying specific aspects of it. The idea that anybody has "automatic" rights is silly without a society that allows everybody to have those rights. Admittedly you could claim those rights if you did not live in a society but you would not have any protection of them.
In the UK there is no explicit limitation on the government wrt allowing/denying rights and little written down to "grant" anything to anyone. There is instead a huge pile of law that supports the edifice.
You should read more about the halting problem.
Turing did not say "you cannot prove a algorithm will terminate" he said "you cannot prove that all arbitrary algorithms will terminate on a turing machine"
First, computers are NOT turing machines. They are bounded in storage (although the bounds are pretty high nowadays).
Second. It is possible to prove that a given algorithm will terminate. Just not all algorithms. Therefore a tool can prove that your algorithm terminates. If it does terminate you are set. If it cannot be proven to terminate it does not mean that it won't terminate it just means that it cannot be proven to terminate. (termination is a good thing in this context)
matfud
Shared dependencies are a problem if you don't use classlaoders properly. Classloaders are dificult to use correctly but are very very powerful.
And VM's CAN unload code that is no longer referenced if you use classloaders correctly. Once the classloader becomes unreachable then all classes it was responsible for loading can be collected. Note that this does not mean they WILL be collected. Collection occurs if GC thinks it needs more space in the perm generation to load more classes.
But they sell crude oil
i l-Set-From-Iraq-Arabia_W0QQitemZ9506292438QQcatego ryZ3491QQssPageNameZWDVWQQrdZ1QQcmdZViewItem
http://cgi.ebay.com/Middle-East-Petroleum-Crude-O
I suggest you read this
http://www.w3.org/Addressing/URL/url-spec.txt
and look at who wrote/edited it. The committee could have defined URL's in pretty much any way he wished. As long as they provided a mechanism to map the authority of the URL to DNS there would have been no problem.
Big and little endian host/domain names are trivial to convert between.
> You, for instance, could be fooled by
Very good choice of words.
>You see, different people, different demands.
Yep different people, different demands but everybody can be fooled.
All the house of loards has the power to do is send bills back to the House of commons or let them pass. They don't get to make law and they don't get to permenently stop a from passing. The most they can do is slow the process down and bring it to the attention of the public. This is a very valuable role.
Most cars that offer integration with ipod players actually integrate with any USB mass storage device. They just advertise ipod compatibility as ipod has about 80% market share. Cars don't provide you with the ipods user interface and since it is generally stuffed in a draw its looks don't matter much either in this situation.
I bought a Q-BE (I think they are called Mobiblue or some such in the states). Its smaller, lighter, cheaper, has a longer lasting battery and better sound quality than the ipod nano. Its not in bondage to itunes, has no DRM and more importantly its interesting. People ask about it.
http://www.mobibluamerica.com/
It competes with the nano. 2, 4, 6 gig. You don't get 200 albums in that amount of space. You are more likely to get somwhere in the 20 - 60 album range (depending on capacity and encoding). Different spec == different requirements for the UI.
Thats about $3500 per person in the US
fsfs seems quite reliable for us (we use it in one of our products), however it can grind to a halt on some filesystems.
Some bright spark thought it would be a good idea for each revision to be stored as a seperate file in a single directory. Most file systems don't take kindly to 40,000 files in a single dir. It, for some odd reason, really hurts thier performance.
JSF is an attempt to produce a componentised development envoironment. You use it a bit like a widget library. It can theoretically render to anything although must come with a basic html implementation. We are currently using it with facelets (a light weight templating system).
Its not bad but its component abstraction does not go far enough in my opinion. You still spend too much time fiddling with tags to make it work (its lousy at reporting any kind of meaning full errors. Facelets helps alot).
A big problem we have is with the lack of namespaces in javascript. Myfaces and other third party ajaxified components bring in thier own JS and can cause hard to find locations.
It works well for most stuff. Knocking up prototypes is very fast and easy.
Thier absence isn't curious. The UN has no figures for them (actually they do for india in 1994 but its not in the tablethat was linked to).
China is thought to be the second largest producer of CO2 eqivs but claim to have reduced emissions in the late 90's
http://news.bbc.co.uk/1/hi/sci/tech/3143798.stm