Re: Patterns of Bugs
On 28/01/2011 12:41, Daniel Gibson wrote: Am 28.01.2011 13:33, schrieb Bruno Medeiros: On 08/01/2011 09:14, Walter Bright wrote: Jonathan M Davis wrote: On Saturday 08 January 2011 00:16:13 Walter Bright wrote: Jérôme M. Berger wrote: When I built my latest PC, I saw in the MB manual that it would use speech synthesis on the PC speaker to report errors. So I tried to power on the PC without having plugged either CPU or RAM and it started to say NO CPU FOUND! NO CPU FOUND! in a loop with a hilarious Asian accent and the kind of rasping voice that used to characterized old DOS games. Pretty fun ;) That's a heckuva lot better than an undocumented beep pattern which is what I got. LOL. The beeps for mine are documented in the motherboadr manual, but the beeps are so hard to distinguish from one another, that it borders on useless. A voice would certainly be better. Yes, what is the difference between a slow beep and a fast beep? While I'm ranting, does anyone else have trouble remembering which of O and | is on, and which is off? What's the matter with on and off? Hum, I never had problems with that: I always assumed the | meant a closed electrical circuit (ie, you closed the circuit with the switch), thus naturally it meant on. O looks like a *closed* circle to me so this isn't that helpful IMHO ;) In my mental model (where the | means a closed circuit, or rather the part of the circuit that closes it and makes electricity pass through), the O doesn't fit well into that model, indeed, it makes no sense. But just for the purposes of remembering which one is on or off, that doesn't matter at all: I just think of is the | pressed or not?. -- Bruno Medeiros - Software Engineer
Re: Patterns of Bugs
On 08/01/2011 09:14, Walter Bright wrote: Jonathan M Davis wrote: On Saturday 08 January 2011 00:16:13 Walter Bright wrote: Jérôme M. Berger wrote: When I built my latest PC, I saw in the MB manual that it would use speech synthesis on the PC speaker to report errors. So I tried to power on the PC without having plugged either CPU or RAM and it started to say NO CPU FOUND! NO CPU FOUND! in a loop with a hilarious Asian accent and the kind of rasping voice that used to characterized old DOS games. Pretty fun ;) That's a heckuva lot better than an undocumented beep pattern which is what I got. LOL. The beeps for mine are documented in the motherboadr manual, but the beeps are so hard to distinguish from one another, that it borders on useless. A voice would certainly be better. Yes, what is the difference between a slow beep and a fast beep? While I'm ranting, does anyone else have trouble remembering which of O and | is on, and which is off? What's the matter with on and off? Hum, I never had problems with that: I always assumed the | meant a closed electrical circuit (ie, you closed the circuit with the switch), thus naturally it meant on. -- Bruno Medeiros - Software Engineer
Re: Patterns of Bugs
Am 28.01.2011 13:33, schrieb Bruno Medeiros: On 08/01/2011 09:14, Walter Bright wrote: Jonathan M Davis wrote: On Saturday 08 January 2011 00:16:13 Walter Bright wrote: Jérôme M. Berger wrote: When I built my latest PC, I saw in the MB manual that it would use speech synthesis on the PC speaker to report errors. So I tried to power on the PC without having plugged either CPU or RAM and it started to say NO CPU FOUND! NO CPU FOUND! in a loop with a hilarious Asian accent and the kind of rasping voice that used to characterized old DOS games. Pretty fun ;) That's a heckuva lot better than an undocumented beep pattern which is what I got. LOL. The beeps for mine are documented in the motherboadr manual, but the beeps are so hard to distinguish from one another, that it borders on useless. A voice would certainly be better. Yes, what is the difference between a slow beep and a fast beep? While I'm ranting, does anyone else have trouble remembering which of O and | is on, and which is off? What's the matter with on and off? Hum, I never had problems with that: I always assumed the | meant a closed electrical circuit (ie, you closed the circuit with the switch), thus naturally it meant on. O looks like a *closed* circle to me so this isn't that helpful IMHO ;)
Re: Patterns of Bugs
On Sat, 08 Jan 2011 20:53:20 +, Iain Buclaw wrote: == Quote from Ellery Newcomer (ellery-newco...@utulsa.edu)'s article On 01/08/2011 02:37 PM, Iain Buclaw wrote: Never let indentation fool you, the else clause will be assumed to be for the first condition. :o) I don't believe you Are you saying it *isn't* interpreted as: if (i) if (j) printf(J true\n); else printf(I false\n); :o From the grammar: The 'dangling else' parsing problem is solved by associating the else with the nearest if statement. http://www.digitalmars.com/d/2.0/statement.html#IfStatement -Lars
Re: Patterns of Bugs
Jonathan M Davis wrote: On Friday, January 07, 2011 11:06:23 Andrej Mitrovic wrote: On 1/7/11, Walter Bright newshou...@digitalmars.com wrote: Some of them, like the hard drive LED, don't even indicate the polarity on the connector.. I hate those things. There's bunch of LEDs on the PC case - USB indicators, power LEDs, etc, and they all have this super-tiny connector and they have to be put together in a really tight place on the motherboard. I leave the PC speaker disconnected though, who needs that thing anyway? :p It's useful for informing you that the computer is starting correctly and gives you an idea of what's wrong if it isn't (though you can live without that if the computer seems to be okay). It's also useful for things like for when your CPU is getting too warm. However, I think that it's horrific that anything in the OS or any program on the computer at all uses the PC speaker. It is _annoying_ when the command-line of all things starts beeping at you because you hit backspace too many times or something like that. At the moment, I haven't been configuring my kernel recently (which is _not_ a fun thing to have to keep doing on every kernel update IMHO), but when I was, I specifically did _not_ compile in the PC speaker driver. I wish that that were the norm. Which reminds me, while the PC speaker is disabled in KDE, I really need to go and track down which change I need to make where to silence it when I've booted to the console rather than all the way into KDE... When I built my latest PC, I saw in the MB manual that it would use speech synthesis on the PC speaker to report errors. So I tried to power on the PC without having plugged either CPU or RAM and it started to say NO CPU FOUND! NO CPU FOUND! in a loop with a hilarious Asian accent and the kind of rasping voice that used to characterized old DOS games. Pretty fun ;) Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: Patterns of Bugs
Jérôme M. Berger wrote: When I built my latest PC, I saw in the MB manual that it would use speech synthesis on the PC speaker to report errors. So I tried to power on the PC without having plugged either CPU or RAM and it started to say NO CPU FOUND! NO CPU FOUND! in a loop with a hilarious Asian accent and the kind of rasping voice that used to characterized old DOS games. Pretty fun ;) That's a heckuva lot better than an undocumented beep pattern which is what I got.
Re: Patterns of Bugs
On Saturday 08 January 2011 00:16:13 Walter Bright wrote: Jérôme M. Berger wrote: When I built my latest PC, I saw in the MB manual that it would use speech synthesis on the PC speaker to report errors. So I tried to power on the PC without having plugged either CPU or RAM and it started to say NO CPU FOUND! NO CPU FOUND! in a loop with a hilarious Asian accent and the kind of rasping voice that used to characterized old DOS games. Pretty fun ;) That's a heckuva lot better than an undocumented beep pattern which is what I got. LOL. The beeps for mine are documented in the motherboadr manual, but the beeps are so hard to distinguish from one another, that it borders on useless. A voice would certainly be better. - Jonathan M Davis
Re: Patterns of Bugs
Jonathan M Davis wrote: On Saturday 08 January 2011 00:16:13 Walter Bright wrote: Jérôme M. Berger wrote: When I built my latest PC, I saw in the MB manual that it would use speech synthesis on the PC speaker to report errors. So I tried to power on the PC without having plugged either CPU or RAM and it started to say NO CPU FOUND! NO CPU FOUND! in a loop with a hilarious Asian accent and the kind of rasping voice that used to characterized old DOS games. Pretty fun ;) That's a heckuva lot better than an undocumented beep pattern which is what I got. LOL. The beeps for mine are documented in the motherboadr manual, but the beeps are so hard to distinguish from one another, that it borders on useless. A voice would certainly be better. Yes, what is the difference between a slow beep and a fast beep? While I'm ranting, does anyone else have trouble remembering which of O and | is on, and which is off? What's the matter with on and off?
Re: Patterns of Bugs
On Saturday 08 January 2011 01:14:41 Walter Bright wrote: Jonathan M Davis wrote: On Saturday 08 January 2011 00:16:13 Walter Bright wrote: Jérôme M. Berger wrote: When I built my latest PC, I saw in the MB manual that it would use speech synthesis on the PC speaker to report errors. So I tried to power on the PC without having plugged either CPU or RAM and it started to say NO CPU FOUND! NO CPU FOUND! in a loop with a hilarious Asian accent and the kind of rasping voice that used to characterized old DOS games. Pretty fun ;) That's a heckuva lot better than an undocumented beep pattern which is what I got. LOL. The beeps for mine are documented in the motherboadr manual, but the beeps are so hard to distinguish from one another, that it borders on useless. A voice would certainly be better. Yes, what is the difference between a slow beep and a fast beep? While I'm ranting, does anyone else have trouble remembering which of O and | is on, and which is off? What's the matter with on and off? I didn't even find out that the sign on many power switches was a 1 inside a 0 until recently, so the symbols meant nothing to me. I would _assume_ that 1 means on and 0 means off since a bit that's 1 is on/true and a bit that's 0 is off/false (and looking at the power switch on my computer right now, that does indeed appear to be the case), but I normally have to just guess whether something is on or off if you can't tell from something other than the power switch. On and Off would be much better, but I suspect that it's one of those things where they chose symbols instead so that they didn't have to worry about internationalization. That way, it confuses _everyone_ instead of just non- English speakers. ;) - Jonathan M Davis
Re: Patterns of Bugs
Jonathan M Davis wrote: On and Off would be much better, but I suspect that it's one of those things where they chose symbols instead so that they didn't have to worry about internationalization. That way, it confuses _everyone_ instead of just non- English speakers. ;) I suspect as much, too, but at least on and off can be looked up in a dictionary. There's no hope for O and |.
Re: Patterns of Bugs
Walter Bright wrote: Jonathan M Davis wrote: On and Off would be much better, but I suspect that it's one of those things where they chose symbols instead so that they didn't have to worry about internationalization. That way, it confuses _everyone_ instead of just non- English speakers. ;) I suspect as much, too, but at least on and off can be looked up in a dictionary. There's no hope for O and |. I always assumed they meant 0 and 1. Then it's easy, just put it in an if() statement :)
Re: Patterns of Bugs
The Reddit thread about this little article shows some interesting sub-threads: http://www.reddit.com/r/programming/comments/exfnb/patterns_of_bugs/ So I add some more comments to my first answer to the article: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=126262 I too miss (a b c) in D, it's short, its meaning comes from mathematics and it gives no confusion, it's more DRY than the D way and it evaluates the 'b' variable only once. So it's a complete win across the whole line. But given the original design decision of D, I agree that the D choice of disallowing it is correct. The design to prevent mistakes from entering the system is called Mistake Proofing and was turned into a rigorous engineering practice by Shigeo Shingo. See: http://en.wikipedia.org/wiki/Poka-yoke It is ironic that the company that created the technique that is a guiding inspiration for Agile software, didn't use their own physical manufacturing techniques when it came to writing their software. Right :-] Maybe they think they are just a hardware firm, or they don't understand that software is way more complex than hardware, etc. I don't know the causes. The problem here is that writing code is a creative thinking process. Bolting things to an airplane is not. This is an important insight that I think Walter article misses. This nice video talk about software engineering practice explains what that means: http://confreaks.net/videos/282-lsrc2010-real-software-engineering Among other things, the talk explains an important difference between software engineering and other engineering fields where an engineer draws a project and then some people build it. In software engineering the program is the project, the people that build it are the computer languages, and the final result is the software running for the user. If in software engineering the program is the project, then writing a program is the equivalent of creating the project. According to the talk programming is like the design stage of an aeroplane, so comparing programming to bolting things to an aeroplane is the wrong analogy for writing software. If this is true, then a language has to be designed to help the design stage, that probably is better done Agile. Over in the D newsgroups, there are often impassioned debates about whether particular patterns should be justifiably banned as being more trouble than they are worth. More than a few suggest I set the bar unreasonably high - in that D allows things that many suggest are fatally error prone (an example is the default fall-through on switch case statements). This was written by Walter and I don't understand what he is trying to say. But I'd like to improve the D switch, as we have discussed: http://d.puremagic.com/issues/show_bug.cgi?id=4349 In general, this strategy works, but there's this odd thing that happens in the other direction also. Sometimes a bit less checking can lead to more diligence. We see this with dynamic typing. People often consider it inherently unsafe, but programmers adjust and often end up without worse runtime error rates. It's sort of like this: http://www.wired.com/wired/archive/12.12/traffic.html We can design away the possibility of some errors, but we can also design in situations which demand diligence. People react in many subtle ways. That gives us a very large design space. This is another exceptionally good comment. This may partially explain why my Python programs are not more buggy than my D code (quite the opposite in truth) despite I am using D for years, and D has consts, a static type system and I write equally unit-tests in D and Python, and in D I also use Design By Contracts, etc (it explains the situation just partially. Surely Python multi-precision numbers on default avoid several troubles normally present in D code). Here we are probably talking about Risk homeostasis or Risk compensation in programming and language design: http://en.wikipedia.org/wiki/Risk_homeostasis http://en.wikipedia.org/wiki/Risk_compensation The hypothesis of risk homeostasis holds that everyone has his or her own fixed level of acceptable risk. When the level of risk in one part of the individual's life changes, there will be a corresponding rise or fall in risk elsewhere to bring the overall risk back to that individual's equilibrium. Wilde argues that the same is true of larger human systems, e.g. a population of drivers. The idea here is that D offers more built-in safeties, but programmers often just program more sloppily, producing at the end about as many bugs. Surely Python programs are more precise in their code formatting (because indentations are part of the syntax), the result is that Python code is often formatted better than D code and it's more uniform across different programmers. This kills some useless discussions (where to put braces?) and allows people to put
Re: Patterns of Bugs
== Quote from Lutger Blijdestijn (lutger.blijdest...@gmail.com)'s article Walter Bright wrote: Jonathan M Davis wrote: On and Off would be much better, but I suspect that it's one of those things where they chose symbols instead so that they didn't have to worry about internationalization. That way, it confuses _everyone_ instead of just non- English speakers. ;) I suspect as much, too, but at least on and off can be looked up in a dictionary. There's no hope for O and |. I always assumed they meant 0 and 1. Then it's easy, just put it in an if() statement :) On the note of if statements. One pattern of bugs I see on the odd occasion are else statements written like this: if (condition1) if (condition2) statement1; else statement2; Always takes a moment or two to look again and realise it wouldn't work as expected without the missing braces added. ;)
Re: Patterns of Bugs
Iain Buclaw: On the note of if statements. One pattern of bugs I see on the odd occasion are else statements written like this: if (condition1) if (condition2) statement1; else statement2; Always takes a moment or two to look again and realise it wouldn't work as expected without the missing braces added. ;) See: http://d.puremagic.com/issues/show_bug.cgi?id=4375 http://d.puremagic.com/issues/show_bug.cgi?id=4924 http://d.puremagic.com/issues/show_bug.cgi?id=4283 Bye, bearophile
Re: Patterns of Bugs
== Quote from bearophile (bearophileh...@lycos.com)'s article Iain Buclaw: On the note of if statements. One pattern of bugs I see on the odd occasion are else statements written like this: if (condition1) if (condition2) statement1; else statement2; Always takes a moment or two to look again and realise it wouldn't work as expected without the missing braces added. ;) See: http://d.puremagic.com/issues/show_bug.cgi?id=4375 Yep, that's the one. :) http://d.puremagic.com/issues/show_bug.cgi?id=4924 I don't see that as a bug, and that enforces a certain coding style onto the end programmer (does no one give thought/praise to obfuscation anymore? ;) http://d.puremagic.com/issues/show_bug.cgi?id=4283 That's certainly a nice looking bug there. But not related in the slightest. Regards
Re: Patterns of Bugs
Iain Buclaw: http://d.puremagic.com/issues/show_bug.cgi?id=4924 I don't see that as a bug, and that enforces a certain coding style onto the end programmer I agree that's a bit controversial, but a known C lint finds that problem, and every strategy is good against bugs :-) (does no one give thought/praise to obfuscation anymore? ;) You are right, we have to create a contest site like this for IODCC (International Obfuscated D Code Contest): http://www.ioccc.org/ This contest has also caused the creation of that fine piece of software that is the TCC (Tiny C compiler). http://d.puremagic.com/issues/show_bug.cgi?id=4283 That's certainly a nice looking bug there. But not related in the slightest. It's related in a sense, it shows an example of a dangling else bug done by the language too :-) Bye, bearophile
Re: Patterns of Bugs
Am 08.01.2011 08:57, schrieb Jérôme M. Berger: Jonathan M Davis wrote: On Friday, January 07, 2011 11:06:23 Andrej Mitrovic wrote: On 1/7/11, Walter Brightnewshou...@digitalmars.com wrote: Some of them, like the hard drive LED, don't even indicate the polarity on the connector.. I hate those things. There's bunch of LEDs on the PC case - USB indicators, power LEDs, etc, and they all have this super-tiny connector and they have to be put together in a really tight place on the motherboard. I leave the PC speaker disconnected though, who needs that thing anyway? :p It's useful for informing you that the computer is starting correctly and gives you an idea of what's wrong if it isn't (though you can live without that if the computer seems to be okay). It's also useful for things like for when your CPU is getting too warm. However, I think that it's horrific that anything in the OS or any program on the computer at all uses the PC speaker. It is _annoying_ when the command-line of all things starts beeping at you because you hit backspace too many times or something like that. At the moment, I haven't been configuring my kernel recently (which is _not_ a fun thing to have to keep doing on every kernel update IMHO), but when I was, I specifically did _not_ compile in the PC speaker driver. I wish that that were the norm. Which reminds me, while the PC speaker is disabled in KDE, I really need to go and track down which change I need to make where to silence it when I've booted to the console rather than all the way into KDE... When I built my latest PC, I saw in the MB manual that it would use speech synthesis on the PC speaker to report errors. So I tried to power on the PC without having plugged either CPU or RAM and it started to say NO CPU FOUND! NO CPU FOUND! in a loop with a hilarious Asian accent and the kind of rasping voice that used to characterized old DOS games. Pretty fun ;) Jerome This is kinda cool. What kind of MB is that?
Re: Patterns of Bugs
On 08.01.2011 15:13, Iain Buclaw wrote: On the note of if statements. One pattern of bugs I see on the odd occasion are else statements written like this: if (condition1) if (condition2) statement1; else statement2; Always takes a moment or two to look again and realise it wouldn't work as expected without the missing braces added. ;) But that one would actually work as expected, wouldn't it? ;) The else belongs to the second if, which matches your indentation.
Re: Patterns of Bugs
Daniel Gibson wrote: Am 08.01.2011 08:57, schrieb Jérôme M. Berger: When I built my latest PC, I saw in the MB manual that it would use speech synthesis on the PC speaker to report errors. So I tried to power on the PC without having plugged either CPU or RAM and it started to say NO CPU FOUND! NO CPU FOUND! in a loop with a hilarious Asian accent and the kind of rasping voice that used to characterized old DOS games. Pretty fun ;) Jerome This is kinda cool. What kind of MB is that? It is an Asus A7N8X. Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: Patterns of Bugs
Jérôme M. Berger jeber...@free.fr wrote in message news:igaasf$rd...@digitalmars.com... It is an Asus A7N8X. Unless I'm just out-of-date, Asus does tend to be pretty good.
Re: Patterns of Bugs
I wonder if you can hack the thing to say whatever you want.
Re: Patterns of Bugs
== Quote from Andrej Mitrovic (andrej.mitrov...@gmail.com)'s article I wonder if you can hack the thing to say whatever you want. If you'd could I'd program it to say Good Afternoon Michael every time I turn it on.
Re: Patterns of Bugs
== Quote from torhu (n...@spam.invalid)'s article On 08.01.2011 15:13, Iain Buclaw wrote: On the note of if statements. One pattern of bugs I see on the odd occasion are else statements written like this: if (condition1) if (condition2) statement1; else statement2; Always takes a moment or two to look again and realise it wouldn't work as expected without the missing braces added. ;) But that one would actually work as expected, wouldn't it? ;) The else belongs to the second if, which matches your indentation. Never let indentation fool you, the else clause will be assumed to be for the first condition. :o)
Re: Patterns of Bugs
On 01/08/2011 02:37 PM, Iain Buclaw wrote: Never let indentation fool you, the else clause will be assumed to be for the first condition. :o) I don't believe you
Re: Patterns of Bugs
== Quote from Ellery Newcomer (ellery-newco...@utulsa.edu)'s article On 01/08/2011 02:37 PM, Iain Buclaw wrote: Never let indentation fool you, the else clause will be assumed to be for the first condition. :o) I don't believe you Are you saying it *isn't* interpreted as: if (i) if (j) printf(J true\n); else printf(I false\n); :o
Re: Patterns of Bugs
Am 08.01.2011 21:53, schrieb Iain Buclaw:
== Quote from Ellery Newcomer (ellery-newco...@utulsa.edu)'s article
On 01/08/2011 02:37 PM, Iain Buclaw wrote:
Never let indentation fool you, the else clause will be assumed to be for the
first condition. :o)
I don't believe you
Are you saying it *isn't* interpreted as:
if (i)
if (j)
printf(J true\n);
else
printf(I false\n);
:o
(D1 code):
import std.stdio;
void main(string[] args) {
if(args.length 1)
if(args.length 2)
writefln(foo);
else
writefln(bar);
}
cae...@mancubus:/tmp $ ./test
cae...@mancubus:/tmp $ ./test a
bar
cae...@mancubus:/tmp $ ./test a b
foo
Re: Patterns of Bugs
bearophile wrote: The problem here is that writing code is a creative thinking process. Bolting things to an airplane is not. This is an important insight that I think Walter article misses. Not at all. Most of software engineering work consists of plugging in subassemblies. In this case, designing the grammar such that the subassemblies of the grammar won't fit together in ways that don't make sense is perfectly analogous.
Re: Patterns of Bugs
Walter: Not at all. Most of software engineering work consists of plugging in subassemblies. In this case, designing the grammar such that the subassemblies of the grammar won't fit together in ways that don't make sense is perfectly analogous. I see and I agree. That real-software-engineering video is probably a bit extreme, the truth is probably more mixed, this means that software engineering is not 100% design work, there's some bolting too :-) Bye, bearophile
Re: Patterns of Bugs
On 01/06/2011 09:38 PM, Walter Bright wrote: http://www.drdobbs.com/blog/archives/2011/01/patterns_of_bug.html (dedicated to bearophile!) Anyone want to post it on reddit? Good points. However, computer hardware analogies are a bit outdated. For example, USB is prevalent nowadays. You connect a USB keyboard, mouse or whatever to a slot, which is closest to you and forget about it. Also, memory module connectors are incompatible starting from I believe DDR. You won't be able to stick DDR2 module into DDR slot. Actually, this applies to almost any modern PC component. I'm afraid the principles you are describing are not something new in the software industry. I can't remember the first time I heard the term fool-proof software.
Re: Patterns of Bugs
JMRyan nos...@nospam.com wrote in message news:ig6cjg$u8...@digitalmars.com... Nick Sabalausky a...@a.a wrote in news:ig5860$231...@digitalmars.com: long-time hardcore fan of the classic book Writing Solid Code, the Although the book is justifiably a classic, its subtitle is the very definition of the expression unintentionally hilarious. Heh, that is an excellent point. Although more seriously, there's no doubt in my mind that at least a few programmers must have avoided the book out of the skepticism of A book about code reliability...from *Microsoft* Press???
Re: Patterns of Bugs
Max Samukha spam...@d-coding.com wrote in message news:ig7jqi$1mf...@digitalmars.com... On 01/06/2011 09:38 PM, Walter Bright wrote: http://www.drdobbs.com/blog/archives/2011/01/patterns_of_bug.html (dedicated to bearophile!) Anyone want to post it on reddit? Good points. However, computer hardware analogies are a bit outdated. For example, USB is prevalent nowadays. You connect a USB keyboard, mouse or whatever to a slot, which is closest to you and forget about it. Also, memory module connectors are incompatible starting from I believe DDR. You won't be able to stick DDR2 module into DDR slot. Actually, this applies to almost any modern PC component. Also, I'm pretty sure that, quite a while ago, the PS/2 ports did start getting made to work with either keyboard or mouse even though they often still got labeled as being just one or the other. And I can't think of a component in my system that isn't keyed but should be. Even IDE ports/plugs started getting keyed a long time ago. But yea, audio-in versus audio-out is still one notable case where you can put the wrong thing in the wrong place. Although, most speakers/headphones do actually work as low-quality microphones :)
Re: Patterns of Bugs
Max Samukha wrote: On 01/06/2011 09:38 PM, Walter Bright wrote: http://www.drdobbs.com/blog/archives/2011/01/patterns_of_bug.html (dedicated to bearophile!) Anyone want to post it on reddit? Good points. However, computer hardware analogies are a bit outdated. For example, USB is prevalent nowadays. You connect a USB keyboard, mouse or whatever to a slot, which is closest to you and forget about it. Yes, USB is a big improvement. So is SATA. Also, memory module connectors are incompatible starting from I believe DDR. You won't be able to stick DDR2 module into DDR slot. Actually, this applies to almost any modern PC component. I put together a new box a couple weeks ago. The memory card would fit in one of 4 slots. The first one I tried it in resulted in a computer that just beeped at me. No help from the manual at all, I was ready to RMA the mobo back, until I had the idea of putting the card in a different slot. The second one I tried worked. You're right that many things in the computer hardware are better. But still, many connections to the mobo can be done wrong. For example, all the pins coming from the front panel. Some of them, like the hard drive LED, don't even indicate the polarity on the connector, and you have to try it both ways until you figure out which one works. I'm afraid the principles you are describing are not something new in the software industry. I can't remember the first time I heard the term fool-proof software. I'm not saying they are new - heck, trying to eliminate buggy code patterns goes back to trying to get rid of goto. And, of course, many static analysis tools attempt to identify obviously buggy but legal C patterns.
Re: Patterns of Bugs
Nick Sabalausky wrote: Also, I'm pretty sure that, quite a while ago, the PS/2 ports did start getting made to work with either keyboard or mouse even though they often still got labeled as being just one or the other. Last time I tried that, it didn't work.
Re: Patterns of Bugs
On 1/7/11, Walter Bright newshou...@digitalmars.com wrote: Some of them, like the hard drive LED, don't even indicate the polarity on the connector.. I hate those things. There's bunch of LEDs on the PC case - USB indicators, power LEDs, etc, and they all have this super-tiny connector and they have to be put together in a really tight place on the motherboard. I leave the PC speaker disconnected though, who needs that thing anyway? :p AFAIK most of the new motherboards use a different color for the PS/2 keyboard vs mouse connectors, so it's not as if the PC industry is ignoring those problems.
Re: Patterns of Bugs
On Fri, 07 Jan 2011 13:47:43 -0500, Walter Bright newshou...@digitalmars.com wrote: Max Samukha wrote: Also, memory module connectors are incompatible starting from I believe DDR. You won't be able to stick DDR2 module into DDR slot. Actually, this applies to almost any modern PC component. I put together a new box a couple weeks ago. The memory card would fit in one of 4 slots. The first one I tried it in resulted in a computer that just beeped at me. No help from the manual at all, I was ready to RMA the mobo back, until I had the idea of putting the card in a different slot. The second one I tried worked. That is not because the slot doesn't support the dimm, it is because many chipsets require you populate memory in a specific order. Usually the slots are color coded (blue and black for instance) to indicate which slots should go together (some chipsets require pairs of dimms), they are usually labeled with silkscreen to indicate the order. I think I've even seen silkscreened instructions on which to populate first. It sucks that the manual doesn't help you. BTW, the beep is usually an indicator of a POST code. It's because it cannot access the memory, so it can't run the graphics card, the beep is the only way it can communicate ;) I think (but I'm not sure) that the beeps convey the code, but the easiest way to figure out the code is to plug in a POST card. You're right that many things in the computer hardware are better. But still, many connections to the mobo can be done wrong. For example, all the pins coming from the front panel. Some of them, like the hard drive LED, don't even indicate the polarity on the connector, and you have to try it both ways until you figure out which one works. Typically, those are not keyed because it's not expected for a normal user to be accessing those cables. Removing the cover of a PC is like casting in D :) -Steve
Re: Patterns of Bugs
Walter Bright Wrote: Nick Sabalausky wrote: Also, I'm pretty sure that, quite a while ago, the PS/2 ports did start getting made to work with either keyboard or mouse even though they often still got labeled as being just one or the other. Last time I tried that, it didn't work. You can't just try it on the same old hardware... It works for me, though I don't have a PS/2 mouse anymore to try it this instant. I know many laptops have come with a single PS/2 slot which accepts either.
Re: Patterns of Bugs
On Friday, January 07, 2011 11:06:23 Andrej Mitrovic wrote: On 1/7/11, Walter Bright newshou...@digitalmars.com wrote: Some of them, like the hard drive LED, don't even indicate the polarity on the connector.. I hate those things. There's bunch of LEDs on the PC case - USB indicators, power LEDs, etc, and they all have this super-tiny connector and they have to be put together in a really tight place on the motherboard. I leave the PC speaker disconnected though, who needs that thing anyway? :p It's useful for informing you that the computer is starting correctly and gives you an idea of what's wrong if it isn't (though you can live without that if the computer seems to be okay). It's also useful for things like for when your CPU is getting too warm. However, I think that it's horrific that anything in the OS or any program on the computer at all uses the PC speaker. It is _annoying_ when the command-line of all things starts beeping at you because you hit backspace too many times or something like that. At the moment, I haven't been configuring my kernel recently (which is _not_ a fun thing to have to keep doing on every kernel update IMHO), but when I was, I specifically did _not_ compile in the PC speaker driver. I wish that that were the norm. Which reminds me, while the PC speaker is disabled in KDE, I really need to go and track down which change I need to make where to silence it when I've booted to the console rather than all the way into KDE... - Jonathan M Davis
Re: Patterns of Bugs
On Friday, January 07, 2011 11:07:54 Steven Schveighoffer wrote: Typically, those are not keyed because it's not expected for a normal user to be accessing those cables. Removing the cover of a PC is like casting in D :) LOL. Yeah. Every time that I build a box, I think about how it would really be nice if they standardized them better and made it much easier to just plug stuff in without all of the cables floating around in the box. But that would make them cost more money, and since you don't actually have to mess with them that often, it just isn't worth it. It sure would be nice though. - Jonathan M Davis
Re: Patterns of Bugs
On Fri, Jan 07, 2011 at 11:27:14AM -0800, Jonathan M Davis wrote: is getting too warm. However, I think that it's horrific that anything in the OS or any program on the computer at all uses the PC speaker. I *love* the pc speaker. It is the only kind of application alert sound I actually want to use. Of course, I want it to be only when I command it, not other people, but it is still amazingly awesome. My computer uses different tones of beeps to tell me about IMs, emails, and other quick alerts. speaker is disabled in KDE, I really need to go and track down which change I need to make where to silence it when I've booted to the console rather than all Try rmmod pcspkr to turn it off and modprobe pcspkr to turn it back on.
Re: Patterns of Bugs
Walter Bright newshou...@digitalmars.com wrote in message news:ig7n8o$1t3...@digitalmars.com... Max Samukha wrote: On 01/06/2011 09:38 PM, Walter Bright wrote: http://www.drdobbs.com/blog/archives/2011/01/patterns_of_bug.html (dedicated to bearophile!) Anyone want to post it on reddit? Good points. However, computer hardware analogies are a bit outdated. For example, USB is prevalent nowadays. You connect a USB keyboard, mouse or whatever to a slot, which is closest to you and forget about it. Yes, USB is a big improvement. So is SATA. IDE's been keyed for a long time too. Wasn't originally, but has been for a long time now.
Re: Patterns of Bugs
On Fri, 07 Jan 2011 14:44:10 -0500, Nick Sabalausky a...@a.a wrote: Walter Bright newshou...@digitalmars.com wrote in message news:ig7n8o$1t3...@digitalmars.com... Max Samukha wrote: On 01/06/2011 09:38 PM, Walter Bright wrote: http://www.drdobbs.com/blog/archives/2011/01/patterns_of_bug.html (dedicated to bearophile!) Anyone want to post it on reddit? Good points. However, computer hardware analogies are a bit outdated. For example, USB is prevalent nowadays. You connect a USB keyboard, mouse or whatever to a slot, which is closest to you and forget about it. Yes, USB is a big improvement. So is SATA. IDE's been keyed for a long time too. Wasn't originally, but has been for a long time now. SATA is better not because of the keyed nature of it. How many times I have tried to twist around my IDE cables so they would be the right way to plug into two components! That small cable makes a world of difference. Same thing with HDMI -- instead of 3-5 clunky cables that hopefully are color coded correctly, you get one cable transmitting all data. -Steve
Re: Patterns of Bugs
Steven Schveighoffer schvei...@yahoo.com wrote in message news:op.voyerqyseav...@steve-laptop... On Fri, 07 Jan 2011 14:44:10 -0500, Nick Sabalausky a...@a.a wrote: Walter Bright newshou...@digitalmars.com wrote in message news:ig7n8o$1t3...@digitalmars.com... Max Samukha wrote: On 01/06/2011 09:38 PM, Walter Bright wrote: http://www.drdobbs.com/blog/archives/2011/01/patterns_of_bug.html (dedicated to bearophile!) Anyone want to post it on reddit? Good points. However, computer hardware analogies are a bit outdated. For example, USB is prevalent nowadays. You connect a USB keyboard, mouse or whatever to a slot, which is closest to you and forget about it. Yes, USB is a big improvement. So is SATA. IDE's been keyed for a long time too. Wasn't originally, but has been for a long time now. SATA is better not because of the keyed nature of it. How many times I have tried to twist around my IDE cables so they would be the right way to plug into two components! That small cable makes a world of difference. Same thing with HDMI -- instead of 3-5 clunky cables that hopefully are color coded correctly, you get one cable transmitting all data. I thought Walter was talking specifically about the keying. Also, I use these on my IDE drives which have been around for quite a few years: http://www.microcenter.com/single_product_results.phtml?product_id=0285984 (They do something special with the shielding inside so that the wires don't have to be in a big ribbon). Granted, SATA cables are even better still, but these are still a huge improvement over the older-style IDE cables.
Patterns of Bugs
http://www.drdobbs.com/blog/archives/2011/01/patterns_of_bug.html (dedicated to bearophile!) Anyone want to post it on reddit?
Re: Patterns of Bugs
On 2011-01-06 21:38:38 +0200, Walter Bright said: http://www.drdobbs.com/blog/archives/2011/01/patterns_of_bug.html (dedicated to bearophile!) Anyone want to post it on reddit? http://www.reddit.com/r/programming/comments/exfnb/patterns_of_bugs/ done!
Re: Patterns of Bugs
Walter Bright newshou...@digitalmars.com wrote in message news:ig55s4$1uc...@digitalmars.com... http://www.drdobbs.com/blog/archives/2011/01/patterns_of_bug.html (dedicated to bearophile!) Anyone want to post it on reddit? I noticed that C-style octal literals were conspicuously absent from the examples ;) Great article, though. Having been in D-land for so long, and being a long-time hardcore fan of the classic book Writing Solid Code, the principles seem fairly obvious to me. But it's definitely something to pass along to other people.
Re: Patterns of Bugs
On 06/01/11 19:38, Walter Bright wrote: http://www.drdobbs.com/blog/archives/2011/01/patterns_of_bug.html (dedicated to bearophile!) Anyone want to post it on reddit? It's too bad there doesn't seem to be an online repository of them. They would make for great research material for programming language designers. Every one you can design out of existence will incrementally improve the productivity of programmers. Perhaps someone here would like to volunteer for this? I guess some kind of moderated bugzilla would do the trick, it'd be awesome to have some table of languages and how many of the types bugs they prevent/kind of prevent as well. If no one else volunteers I guess I could hack something crude together, it would still need people to volunteer bugs for it, as well as sources/proof for each bug (links to changesets/projects that have encountered this issue etc). -- Robert http://octarineparrot.com/
Re: Patterns of Bugs
Nick Sabalausky wrote: I noticed that C-style octal literals were conspicuously absent from the examples ;) Everyone has their favorite pattern. I could literally list thousands of them. Great article, though. Having been in D-land for so long, and being a long-time hardcore fan of the classic book Writing Solid Code, the principles seem fairly obvious to me. But it's definitely something to pass along to other people. I think it's obvious, too, but it ain't. Just work on a car for a while, and you'll see!
Re: Patterns of Bugs
On Thu, Jan 6, 2011 at 6:25 PM, Robert Clipsham rob...@octarineparrot.comwrote: On 06/01/11 19:38, Walter Bright wrote: http://www.drdobbs.com/blog/archives/2011/01/patterns_of_bug.html (dedicated to bearophile!) Anyone want to post it on reddit? It's too bad there doesn't seem to be an online repository of them. They would make for great research material for programming language designers. Every one you can design out of existence will incrementally improve the productivity of programmers. Perhaps someone here would like to volunteer for this? I guess some kind of moderated bugzilla would do the trick, it'd be awesome to have some table of languages and how many of the types bugs they prevent/kind of prevent as well. If no one else volunteers I guess I could hack something crude together, it would still need people to volunteer bugs for it, as well as sources/proof for each bug (links to changesets/projects that have encountered this issue etc). -- Robert http://octarineparrot.com/ I loved the idea, but I personally dislike Bugzilla and I wonder if it would work for something like that. Anyway a voting system would be mandatory. In any case, isn't there something like this already? -- Atenciosamente / Sincerely, Guilherme (n2liquid) Vieira
Re: Patterns of Bugs
Walter:
http://www.drdobbs.com/blog/archives/2011/01/patterns_of_bug.html
(dedicated to bearophile!)
Thank you Walter :-)
The article is simple but nice. Few comments:
The possible mechanic's mistake is designed out of the system.
In the first books written by Donald Norman there are many examples of wrong
design, foolproof design, etc:
http://en.wikipedia.org/wiki/Donald_Norman
(!E !E-fld)
is a nonsense expression, and what was probably meant was:
(!E || !E-fld)
What's the process fix for this bug pattern?
Even the correct version is not nice code :-)
In the D programming language, we didn't wish to mess with the operator
precedences in order to avoid behavior that would be surprising to experienced
programmers.
Experienced _C_ programmers (as you written below) :-)
A common pattern is the classic fencepost bug:
int A[10];
for (int i = 0; i = 10; i++)
... = A[i];
This little C99 program:
#include stdio.h
int main() {
int A[10] = {0,1,2,3,4,5,6,7,8,9};
int total = 0;
for (int i = 0; i = 10; i++)
total += A[i]; // line 6
printf(%d\n, total);
return 0;
}
The good Gimpel lint catches the bug statically:
diy.c 6 Warning 661: Possible access of out-of-bounds pointer (1 beyond end
of data) by operator '[' [Reference: file diy.c: lines 5, 6]
It's able to catch more complex situations too (but not all situations).
Bye,
bearophile
Re: Patterns of Bugs
Guilherme Vieira Wrote: On Thu, Jan 6, 2011 at 6:25 PM, Robert Clipsham rob...@octarineparrot.comwrote: If no one else volunteers I guess I could hack something crude together, it would still need people to volunteer bugs for it, as well as sources/proof for each bug (links to changesets/projects that have encountered this issue etc). I loved the idea, but I personally dislike Bugzilla and I wonder if it would work for something like that. Anyway a voting system would be mandatory. In any case, isn't there something like this already? I don't see much benefit in building a crude prototype for such a system. If it is going to be done the person should really run with the idea; research what tools are out their for managing a system and doing what it takes to make a usable, friendly, and meaningful implementation. Modifications to analysis tools could be made which would crawl public repositories looking for known patterns (not to claim it is a bug), similar to Ohloh and its crawling tools.
Re: Patterns of Bugs
Am 06.01.2011 21:37, schrieb Guilherme Vieira: On Thu, Jan 6, 2011 at 6:25 PM, Robert Clipsham rob...@octarineparrot.com mailto:rob...@octarineparrot.com wrote: On 06/01/11 19:38, Walter Bright wrote: http://www.drdobbs.com/blog/archives/2011/01/patterns_of_bug.html (dedicated to bearophile!) Anyone want to post it on reddit? It's too bad there doesn't seem to be an online repository of them. They would make for great research material for programming language designers. Every one you can design out of existence will incrementally improve the productivity of programmers. Perhaps someone here would like to volunteer for this? I guess some kind of moderated bugzilla would do the trick, it'd be awesome to have some table of languages and how many of the types bugs they prevent/kind of prevent as well. If no one else volunteers I guess I could hack something crude together, it would still need people to volunteer bugs for it, as well as sources/proof for each bug (links to changesets/projects that have encountered this issue etc). -- Robert http://octarineparrot.com/ I loved the idea, but I personally dislike Bugzilla and I wonder if it would work for something like that. Anyway a voting system would be mandatory. In any case, isn't there something like this already? I don't think Bugzilla would be appropriate, because such a repository should collect bugs from many different projects. Something that allows to sort the bugs into categories etc is needed IMHO. So you'd have rough categories of bugs, sub-(sub-sub-)categories of that and at some point links to the actual bugs in the respective bugtrackers of the monitored projects. Of course support for that in various bugtrackers would be great, so the bugfixer could just select the appropriate (sub)category of the bug and it would automatically be submitted to the repository. Cheers, - Daniel
Re: Patterns of Bugs
Nick Sabalausky a...@a.a wrote in news:ig5860$231...@digitalmars.com: long-time hardcore fan of the classic book Writing Solid Code, the Although the book is justifiably a classic, its subtitle is the very definition of the expression unintentionally hilarious.
