Hm, in our kernel, when we need to do floating point, we just set a flag on the thread control block which preserves the floating registers on context switch, and then do our floating point operations. Maybe there is some API abstraction hiding the messy details :).
Assuming you care about the distinction between null and no such key (for many applications you can avoid storing null, IMO), you can actually perform the containsKey() after the get() for only keys which get() returns null. I think that see all of the perf overhead of a single lookup if most values are non-null.
I didn't get this error here, however I recieved the exact same error when I used my german "..@googlemail.com" mail address to register on appengine. After changing it to "..@gmail.com" it worked. If you are german, you could try that as well.
ok makes sense but i wouldnt write every change to the disk anyway. The server state can well be kept inside memory and only be saved once in a while, but nevertheless doing that in a different thread would make sense.
How many people make < $100,000 (required for the 1040EZ), withhold the "default," and get a $10,000 refund?
(And re: "default", I've looked and looked, and can't find such a thing. How do you determine a "default" withholding from a W-4 other than just taking your expected income tax for the year and dividing by pay days? If you do that, you shouldn't have a $10,000 refund...)
For what it's worth, in 2012 I made less than $100,000 in AGI, withheld the W-4 default for my filing status (Single, Independent), and my refund was $650. More or less right on the mark.
Edit: Aha! Found it. $100k biweekly is $1923/week of gross pay; let's ignore medicare and social security, etc. For Single/HoH, that's $344.20 + 28% of 1923-1732 = $397.68 weekly or $20679.36 / year. Since our expected total tax is $18,500, we get back $2,100 in refund. Big-ish, but not $10,000. And only 2% of $100k.
I didn't mean "just" in that sense, I mean "just" as in "solely dedicated to".
Most apps have error handling code taking up what? 20-30% of the code at the most? For some reason I imagine this stuff being almost 70% error handling but I am not sure if that is realistic.
So, assuming there are shed loads of error handling that knocks on to everything else about the system. How do they test it? How do they spec out all the possible conditions? What do they do differently to someone writing a SaaS, Desktop app or IOS app?
It looks like it would be a very different world which is not really written about (Apart from the old articles posted in one of the above comments)
> Most apps have error handling code taking up what? 20-30% of the code at the most? For some reason I imagine this stuff being almost 70% error handling but I am not sure if that is realistic.
I work in a FreeBSD-derived kernel in areas related to the buf / caching subsystem, which probably has a lot of similarities to pre-2.6 linux (they have diverged more since the 90s). I don't know that I can quantify it, but 20-30% feels like a low number.
> So, assuming there are shed loads of error handling that knocks on to everything else about the system. How do they test it?
One thing we use to test error-case handling is "fail points" — sysctls usable from unit tests that trigger some fault condition. These aren't perfect — they are manually added to code, and because of this, coverage is fairly low — but they're a start.
> How do they spec out all the possible conditions? What do they do differently to someone writing a SaaS, Desktop app or IOS app?