Two of my users regularly still get BSODs. I do know exactly why though for these two machines. Whenever M$ update their handling of graphic devices, the vendor provided drivers for the graphic devices on these two (out of 20 odd physical machines) shut down and bang BSOD. Of course, what we see on the screen gives absolutely no clue that this is the reason, just learnt the hard way. Management asked me if we could invoice M$ for the several hundred hours of research I had to do to find the issue and document it sufficiently that someone else can recover these machines if I am not on-site. I suggested that this would only cause amusement in the the house of small soft things.

I am a dev and I read the article (I did not go as far as downloading more) and still know 1/10th of SFA about parsers. Fortunately I guess I have never needed to know. In an earlier post one of our cohort was describing his trouble getting to sleep. With no disrespect intended to you for your stellar work, if he knows nothing of parsers (like myself) I suggest he go to your page and completely concentrate on your documentation. I am sure he will either render himself safely asleep or get overly enthused on parsers and algorithms such that he forgets that he is tired. :)

Or on the High C's?

I find it somewhat quicker to load but intellisense seems a little slower. It still finds my bugs pretty quick but since I type eyes on keyboard and only stop to look at what I have actually typed and how much the intellisense has modified my typing when I run out of typing steam this might also be perception. Additionally, they gone broke how good EF used to was. Often I have to use the custom tool to propogate the database changes. OR WORSE, if I use .NET CORE I gotta scaffold the buggers in the package manager console every time I make a small DB change.

Nope, only got a fiver in my pocket.

If it is old enough for a battery change then it is possible that the older components on mother boards are flaky in more ways than 1. I have seen soldered in capacitors and transistors and resistors which have lost part of their physical being (in fact if you rubbed your fingers over a transistor it actually dusted down to nothing) and have thus changed their characteristics affecting such things as the real-time clock (slowing down / speeding up/ unreliable). Since the boot process does a timer check routine, if it fails then by even a couple nanosecs it says nogo (obviously because timers are heavily used for interrupt control along with the real time clock). In other words, hi ho, hi ho, its off to the shops we go.

I learnt debugging back in the early 80s for R/Basic, an interpretive language from an OS called Pick. There was no such thing as an IDE back then, pretty much a suck-it-and-see approach. That's where I also learned that what I really did was 85% plan, 5% code and 10% debug. I also learnt that I could move those goalposts to as much as 93% plan, 5% code and 2% debug. Debug back then was embedding print and input statements to step through the code throwing the values of variables to my screen (or lineprinter) as I went. Now, with all the wondrous tools I am probably doing 45% plan 10% code and 45% debug because the tools have made it easy. I think they try and rephrase what I do as 'Agile'. I simply call it lazy (and, yes, I know that infers I am lazy, lets remove the inference. I am http://codeproject.cachefly.net/script/Forums/Images/smiley\_wink.gif )

I would think that persons aspires to your tagline :-)

Always thrush reading these

What date is your PC clock set to?

layers come FROM eggs