|
Sander Rossel wrote: Once had an issue with a rather unstable connection that often made it fail the first time.
This reminds me of a funny story where a customer kept having intermittent issues with our software...database connections kept timing out. 
Every time the guy would call having problems, I would remote in, and the problem wouldn't happen. Luckily, they were within driving distance, so I went onsite to try and sort it out.
The end user's office was across the driveway to a shipping dock and warehouse. The database server was located in the warehouse office, and the network connection between the two offices was a p2p (line of sight) wireless setup. (apparently a short term solution while they were constructing new offices) When I arrived, there wasn't a lot going on...the software worked without fail. After a while, a truck arrived and began backing into the dock...and suddenly, the database connection was gone! 
For weeks, the customer never made the 'connection'! Luckily, the fix was simply raising the p2p units by a few more feet.
"Go forth into the source" - Neal Morse
|
|
|
|
|
Customers do that 
I have a similar story with a printer.
The user pressed the print button to print somewhere around 100 to 150 invoices.
It often happened that the printing stopped after 50 or so invoices.
And always at the end of the day (because that's when they printed invoices).
So I was testing my software, looking for bugs, writing "fixes" for "what could be it", added additional logging, everything, but I was never able to find the problem.
And when I visited it didn't happen, of course.
This went on for weeks.
Then my manager visited them, for completely unrelated business, and called me "Is that print problem fixed already? I'm about to leave, but they're going to print invoices so I can check on them now."
He checked and you'll never believe what their issue was.
They clicked the print button and SHUT DOWN THEIR COMPUTER TO GO HOME!!!   
Never did it occur to them that shutting down the computer would stop it from printing.
I can tell you I felt like driving a truck over their computers!
|
|
|
|
|
True story.
Some users seems to assume that printers have internal memory which would keep our queued documents.
This assumption comes from a fact that printer keeps printing even when they closed our software.
They don't know that these queued documents are stored on operating system's printer spooler service.
Some colleagues once asked me, why did her printer stop printing? I who was in the middle of serious work mode, glanced over at her desk and yelled, you turned off your computer, that's why!
|
|
|
|
|
We have a networked printer that very much does have an internal queue, so different people may have had different experiences.
(At first I found it unsettling, as jobs disappeared from the queue on my PC almost immediately every time).
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
My very first paid job was working with a mainframe at British Rail, in the 1970s. We used a TSO (Time Sharing System) and a few terminals in a dedicated room. I had a train to catch home so usually was one of the first to leave. Very often the next morning I'd find my colleagues scratching their heads - seems the mainframe had crashed the previous evening. This happened pretty much every day for a couple of weeks. Eventually I came in late one day (train delayed) and my boss had noticed my terminal was powered off. How or why turning off the terminal crashed the mainframe I never understood, but crash it it did. If only they'd told me, a keen young "Energy Studies" student eager to not waste electricity...
At that job too we received mag.tape data, sent up from HQ in London. Usually it arrived fine, but on occasions all the data was wiped. This was at the Railway Technical Centre at Derby where all sorts of testing went on. Turns out the tapes came up, for convenience, on one of the test trains, right into the RTC, and on some days the coaches were shunted onto one of the tracks they were doing overhead power line testing... oops.
|
|
|
|
|
Probably not much help when a parachute does that.
Arguing with a woman is like reading the Software License Agreement. In the end, you ignore everything and click "I agree".
Anonymous
|
|
|
|
|
If "try again!" always was silly coding practice, the the concept of "busy waiting" would not be known. Busy waiting does have its place, especially in embedded systems where the processor has nothing else to do.
Another situation is where several activities are competing for the same resource, but they hold the resource comparatively briefly. As long as you can modify all the competitors, you could program the queueing mechanism, where a process trying to access a busy resource is sent to sleep in a queue and woken up when it gets its turn. Often you can only modify some of the competitors. The effort of implementing a queue mechanism may be high. If the risk of collision is small, it simply doesn't pay.
I have fairly recently programmed a couple "try again" cases: On a quite heavily loaded file system, the number of exceptions due to confliciting accesses was higher than desired. So, when making modifications to a set of files, I make one try for each. Those failing are put into a list for retrying, and a second attempt is made once the first round was completed. Only after a second try, the user is notified. We went from too many access collisions to almost none. Sometimes, the second try came too fast, and the file was still busy. So I added a 5 ms sleep before starting a second round, and after that I haven't seen a single collision.
This "try again" code is next to trivial, and it does solve a real problem. So I cannot agree that the strategy is silly in every case. Sometimes it makes perfect sense.
|
|
|
|
|
Member 7989122 wrote: So I cannot agree that the strategy is silly in every case. Sometimes it makes perfect sense.
 Great examples but not quite the same as the OP where it doesn't make sense to try the same command again right away.
This also brought to mind a program I have to migrate database objects...those having a dependency yet to be created fail and get put into a recursive 'try again' queue. 
"Go forth into the source" - Neal Morse
|
|
|
|
|
Member 7989122 wrote: I have fairly recently programmed a couple "try again" cases: On a quite heavily loaded file system, the number of exceptions due to confliciting accesses was higher than desired. So, when making modifications to a set of files, I make one try for each. Those failing are put into a list for retrying, and a second attempt is made once the first round was completed. Only after a second try, the user is notified. We went from too many access collisions to almost none. Sometimes, the second try came too fast, and the file was still busy. So I added a 5 ms sleep before starting a second round, and after that I haven't seen a single collision.
So, you just assumed that whoever/whatever else had been writing to the file had been doing nothing worthwhile? Personally, if I detect any changes to a file I would avoid writing to it, and notify the user. Better still, open it for exclusive write.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
|
Try try until you succeed !!!
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
DM's Esoteric Programming Languages - Petrovich[^]
What.
The.
F***.
Was.
That.
Guy.
Smoking?
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???
|
|
|
|
|
|
David Morgan-Mar wrote: And in case you think this is entirely a joke, imagine a Petrovich layer over another operating system, such as Microsoft Windows (TM). Every time Windows does something you don't like, you could punish it, and it would never do it again...
Windows is performing automatic updates. After 6 million arbitrary files have been downloaded and applied your machine will reboot.
Petrovich> punish punish punish
Edit: oh, and in answer to your question. Probably half a page load of lsd-25 or stronger.
|
|
|
|
|
Patch 1.05 Combo Damage Table : MECoOp[^]
Appearently the Multiplayer Damage stuff is taken from the host's Singleplayer data tables.
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???
|
|
|
|
|
I remember this bug from single/multi player games...in the 90's.
The last time I saw this you needed a dial-up modem to pwn the plebs.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
I have a few SQL scripts as embedded resources in my app, for EF seeding. To make sure other coders, or me much later, don't go looking for these scripts, I added the following comment to the first line of each one:
-- This file is used as an embedded resource and not included in the build output.
Then I build a little ResourceManager that for now just reads embedded files, and when I tried it out:
var script = ResourceManager.ReadEmbeddedTextFile("SeedIdTypes.sql");
and hovered over the script destination var, I never saw past the comment, which I had forgotten about, saying This file is used as an embedded resource and not included in the build output, and I assumed it was the CLR complaining about my build settings for the script file. A wasted half hour later, I looked closer, and saw the SQL, realised the script was being read, and the "error message" was my own comment. 
Immanentize the Eschaton!
|
|
|
|
|
|
Ouch.
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???
|
|
|
|
|
Brady Kelly wrote: and I assumed it was the CLR complaining
That's what happens when you create professional looking comments. If you'd written "hey, dumb*ss, you can't do this!" you would have figured it out right away!
Marc
Latest Article - Merkle Trees
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
Immanentize the Eschaton!
|
|
|
|
|
How is it you've lucked out and never had an IDE call you a dumb*ss?
Software Zen: delete this;
|
|
|
|
|
Brady Kelly wrote: comment
... not if I can't see them ...
|
|
|
|
|
Ouch!
I have been bitten in the rear with similar comments. Now I sign my comments with my initials and data. An added benefit, I can search for my comments.
-- This file is used as an embedded resource and not included in the build output. [BK 20170418]
|
|
|
|
|
I used to do exactly the same, but I so seldom work on shared code-based these days, it's all my own, so that sort of ell by the wayside.
Except I used to put the [BK 20170418] first, so it's always in the same left side of the sreen, regardless of comment length.
Immanentize the Eschaton!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
