|
I love Chasing Cars, despite having some bad memories to it (which all turned out alright).
This one sounds really good too.
I guess I have me some Snow Patrol to listen to 
|
|
|
|
|
Our products generate a "diagnostic report" which lists all of the system and Windows information you could ever want to know about a machine. We're testing a new model of industrial PC, and the diagnostic report was failing while it was enumerating the device drivers installed.
The Intel chip-set drivers for this new, fancy-schmancy motherboard (dual Xeon's, 64GB RAM, 10GB ethernet) report creation dates in... 1968(*). Yes ladies and gentlemen, these drivers were written under the influence of some really trippy acid during the Summer of Love  .
(*) A FILETIME value passed to a CTime constructor, which promptly throws an exception because the date/time is out of range for the underlying time_t value, based on the UNIX 1/1/1970 epoch date.
Software Zen: delete this;
|
|
|
|
|
At Intel they must be di-agnostic 
|
|
|
|
|
Maybe it wasn't broken.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Hi,
Gary Wheeler wrote: The Intel chip-set drivers for this new, fancy-schmancy motherboard (dual Xeon's, 64GB RAM, 10GB ethernet) report creation dates in... 1968
I just looked at all of the possible epochs. I can't even come up with any conversion math that would cause a 50 year offset.
What date are you looking at? NTFS file creation date? Code signing date? PE VERSIONINFO block date?
Best Wishes,
-David Delaune
|
|
|
|
|
oh hell. that must have been fun to track down.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Running under the debugger it was easy. A CTime constructor was throwing an exception. The date/time value was of the type FILETIME, which has a much broader range than that allowed by the time_t (32-bit) that underlies CTime.
Unfortunately since this is C++ code most of my bugs are far more difficult to find. Our application is multiple processes (a UI app and some services) and each process is heavily multithreaded. Even the UI app has 50+ threads running. This means that there can be significant differences in behavior between debug compiles at my desk vs. release compiles in the product due to timing, heap checking, and so on.
Software Zen: delete this;
|
|
|
|
|
> Even the UI app has 50+ threads running
That seems... not okay.
But I'm sure you have your reasons.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
It does sound unusual but... Obviously, we have a main application thread running the UI window itself and the corresponding message loop. There are several threads handling network communications with underlying services and our tracing/diagnosis tool. Any number of background threads in the UI app and the services may be performing or monitoring external physical processes. Over the last 20 years, our programming model for our products has become quite adept at handling a multi-process/multi-threaded implementation. It's relatively rare that we find a bug arising from a deadlock or resource contention issue. Our bugs now tend to be problems in the physical processes and our control/monitoring of them.
Software Zen: delete this;
|
|
|
|
|
That's impressive, although I have to wonder about the efficiency of creating all those threads. I'm curious if you pool - but not surprised if NDA prevents you from discussing it further.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
honey the codewitch wrote: I have to wonder about the efficiency of creating all those threads.
Many of the threads are spun up once and run continuously, although they spend the majority of their time waiting on events or semaphores.honey the codewitch wrote: I'm curious if you pool
In one product line, the UI app is C#/.NET/WPF and almost all of the threads are pooled.
Software Zen: delete this;
|
|
|
|
|
that makes sense. If they're sleeping it's not a huge deal. It's just, man, you like to keep the scheduler busy. 
I get it though. If you're waiting on a bunch of low level hardware, you have to have threads spun up and ready to handle their events.
Normally you'd do that at the driver level, but not always. i guess it would depend if you need the privileges or not.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
That’s a weird one.
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
1969 I would have understood
|
|
|
|
|
Gary Wheeler wrote: these drivers were written under the influence of some really trippy acid during the Summer of Love
Way cool, dude; do they have a faint aroma of sea-salt filtered through the eucalyptus trees in Golden Gate Park ?
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
|
|
|
|
|
He was walking along the road
And I asked him, Tell me, where are you going
This he told me
Said, I'm going down to Yasgur's Farm
Gonna join in a rock and roll band
Got to get back to the land and set my soul free
We are stardust, we are golden
We are billion year old carbon
And we got to get ourselves back to the garden
Well, then can I roam beside you?
I have come to lose the smog,
And I feel myself a cog in somethin' turning
And maybe it's the time of year
Yes and maybe it's the time of man
And I don't know who I am
But life is for learning
We are stardust, we are golden
We are billion year old carbon
And we got to get ourselves back to the garden
We are stardust, we are golden
We are billion year old carbon
And we got to get ourselves back to the garden
By the time we got to Woodstock
We were half a million strong
And everywhere was a song and a celebration
And I dreamed I saw the bomber death planes
Riding shotgun in the sky,
Turning into butterflies
Above our nation
We are stardust, we are golden
We are caught in the devils bargain
And we got to get ourselves back to the garden
Software Zen: delete this;
|
|
|
|
|
Nice to be reminded of this "anthem" that resonates with those halcyon years in the late sixties => seventies when American identity turned itself inside out  How lovely Joni is, and was: [^].
By the time Joni wrote that song (1970) I was well beyond my wilder daze
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
|
|
|
|
|
I'm familiar with the song from the Crosby, Stills, & Nash version. It's one of my favorites from their canon.
Software Zen: delete this;
|
|
|
|
|
Gary Wheeler wrote: these drivers were written under the influence of some really trippy acid during the Summer of Love
You forgot to mention that the developper wrote the code using his teeth, and that hardware has been destroyed by fire after compilation, because, you know, coding is awesome.
"Five fruits and vegetables a day? What a joke!
Personally, after the third watermelon, I'm full."
|
|
|
|
|
|
|
Quote: What do you get if you multiply six by nine?
Yep. Close enough for government work.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
9 x 6 = 42
Base 13
"Time flies like an arrow. Fruit flies like a banana."
|
|
|
|
|
Base 13 would explain why government projects always run way over budget...
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I can now breath easier knowing that a solution has been found...but I don't see or feel any change yet.
Technician
1. A person that fixes stuff you can't.
2. One who does precision guesswork based on unreliable data provided by those of questionable knowledge.
JaxCoder.com
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
