In nearly every case where the files aren't semantically related and hard-linkable, deduplication is silly due to storage costs. That's already covered by many others' comments. Do your own thinking.
Just encapsulate that file in its own class and realize how crazy OO can become.
try {
MyConfiguration config = new MyConfigFile().readConfig();
config.read(); } catch {/* we don't have a config file, lets die. */ }
Then in your MyConfigFile class, you can check if the file exists, if not, create one, enter default config values, etc. and push all that horrible file handling garbage into its own neat package...
Edge case? Looping over millions of records is pretty common, from data processing to log files to file sorting...
Even seemingly simple situations like your file browser trying to show you thumbnails of each picture in a directory can be riddled with exceptions which would slow down the whole process dramatically.
I suppose you've never tried to open a file before.
In a multitasking multi-threaded multi-user environment, even doing a stat() check on a file before trying to open it doesn't guarantee its still there by the time the next line is executed.
I have a piece of code that relies on several complex regular expressions. Taking unit testing a bit far because I know random changes might get made to the code, I threw in a function that tests the regex's against various edge cases I've run into. That few wasted CPU cycles in this type of situation has saved me accidentally shipping bad code several times, which is much more valuable than the cycles themselves.
Pattern regex1 = Pattern.compile(REGEX1); for (String regex1test: REGEX1TESTS) {
if (regex1.matcher(regex1test).groupcount() != 1) {
throw...
} }
That's why you do a FileWriter.flush() inside your exception handled code and put the close() in the finally block where it will essentially never throw now.
One of the reasons I've always liked DJB's code is that his C style is to check every return and just die on errors. The philosophy being that its much more secure to stop doing everything when a real error happens than to hobble along and pretend it wasn't one. Unfortunately, that ends up looking a lot like this:
int readclose_append(int fd,stralloc *sa,unsigned int bufsize) {
int r;
for (;;) {
if (!stralloc_readyplus(sa,bufsize)) { close(fd); return -1; }
r = read(fd,sa->s + sa->len,bufsize);
if (r == -1) if (errno == error_intr) continue;
if (r len += r;
} }
As someone who's written many thousands of lines of code for a living, I've often sat down and looked at a piece of code and realized there was a better way to divide up my classes and functions that I didn't think of initially and wonder if its worth the effort to refactor it intelligently or leave it as-is for the sake of maintenance.
I nearly always write down those thoughts in my code though, so they can be found later./* TODO (LAZY): yes this should be a generator and func_y() should be private */
For the TL;DR people out there, Python has both strings of characters and sequences of bytes, and they are not the same things. C on the other hand only has sequences of bytes.
Platformers don't bother me on a phone/tablet. In fact, Temple Run is a good example of using swipe actions.
I meant first-person shooters, and no, the thumb-on-screen system is nowhere near being a mouse and keyboard, because my fingers can't find the exact placements to use at a moment's notice... no physical keyboard after all, have to look periodically to make sure your thumb is centered...
As to accelerometers, they're not perfect. I prefer buttons for steering... mostly because of the lack of auto-centering like on a joystick or with buttons. That is to say, if I hold the tablet perfectly level, its not perfectly level, its off by a bit and the car slowly bends left or right.
In the very long run, the Steam on-sale games are cheaper, and have lower hardware requirements than current games too (saving a bit of money). Last time I did the math on it though, I bought a PS3 instead of a video card of the same price.
And now that my PS3 is getting a bit long in the tooth, I could upgrade my PC to handle 1920x1080x60fps + 5.1 audio gaming on my TV... but not for $250. So technically my PS3 is still doing better.
And for the inevitable critics, yes I play several *Actual* AAA titles at 1080p. I never got into console cross-platform titles because they're rendered way below HD and upscaled on all the consoles. Very annoyingly blurry.
Wait, you think testing C and C++ against possible exploits is easier than using an interpreted language like Python or Perl? I wouldn't go back to writing my CGI with C unless there was a no-lawsuits clause.
Slashdot Mirror
Just finished updating my Streak5 ... great devices, too bad they thought a custom interface was the way to go.
In nearly every case where the files aren't semantically related and hard-linkable, deduplication is silly due to storage costs.
That's already covered by many others' comments. Do your own thinking.
To be fair, having a long-term visionary on staff is just as important as having good engineers.
There are much more efficient hashes than MD5 that would work as well for fewer clock cycles. http://cr.yp.to/hash127.html comes to mind.
When you have a filesystem that understands hard links, deduplication is redundant.
Totally aside from your main point, what does the spindle count have to do with your VG naming?
pvcreate /dev/sda1 /dev/sdb1 /dev/sdc1
pvcreate
pvcreate
vgcreate LotsOfDrives /dev/sda1 /dev/sdb1 /dev/sdc1
Now if you want spindle-specific LVs: /dev/sdb1 /dev/sdc1
lvcreate -n dbdata LotsOfDrives
lvcreate -n logdata LotsOfDrives
Funny, even my home box uses LVM over dm-crypt over RAID on Linux just fine. And that's with Ext4 file systems.
LVM lets me create a snapshot for consistent backups any time I want.
Just encapsulate that file in its own class and realize how crazy OO can become.
try {
MyConfiguration config = new MyConfigFile().readConfig();
config.read();
} catch {
}
Then in your MyConfigFile class, you can check if the file exists, if not, create one, enter default config values, etc. and push all that horrible file handling garbage into its own neat package ...
Edge case? Looping over millions of records is pretty common, from data processing to log files to file sorting ...
Even seemingly simple situations like your file browser trying to show you thumbnails of each picture in a directory can be riddled with exceptions which would slow down the whole process dramatically.
I suppose you've never tried to open a file before.
In a multitasking multi-threaded multi-user environment, even doing a stat() check on a file before trying to open it doesn't guarantee its still there by the time the next line is executed.
Nearly all my BASH scripts are long sequences of &&
cd $LOCATION \
&& tar -cvf $TARFILE $PATTERN \
&& xz $TARFILE \
&& scp "${TARFILE}.xz" remotehost: \
&& exit 0
echo "Error"
I have a piece of code that relies on several complex regular expressions. Taking unit testing a bit far because I know random changes might get made to the code, I threw in a function that tests the regex's against various edge cases I've run into. That few wasted CPU cycles in this type of situation has saved me accidentally shipping bad code several times, which is much more valuable than the cycles themselves.
Pattern regex1 = Pattern.compile(REGEX1);
for (String regex1test: REGEX1TESTS) {
if (regex1.matcher(regex1test).groupcount() != 1) {
throw
}
}
That's why you do a FileWriter.flush() inside your exception handled code and put the close() in the finally block where it will essentially never throw now.
One of the reasons I've always liked DJB's code is that his C style is to check every return and just die on errors. The philosophy being that its much more secure to stop doing everything when a real error happens than to hobble along and pretend it wasn't one. Unfortunately, that ends up looking a lot like this:
int readclose_append(int fd,stralloc *sa,unsigned int bufsize)
{
int r;
for (;;) {
if (!stralloc_readyplus(sa,bufsize)) { close(fd); return -1; }
r = read(fd,sa->s + sa->len,bufsize);
if (r == -1) if (errno == error_intr) continue;
if (r len += r;
}
}
As someone who's written many thousands of lines of code for a living, I've often sat down and looked at a piece of code and realized there was a better way to divide up my classes and functions that I didn't think of initially and wonder if its worth the effort to refactor it intelligently or leave it as-is for the sake of maintenance.
I nearly always write down those thoughts in my code though, so they can be found later. /* TODO (LAZY): yes this should be a generator and func_y() should be private */
I have a lot of situations like this where I simply do error counters in a helper function like this:
for (int attempt = 1; attempt <= MAX_RETRIES; attempt++) {
try {
return something_that_might_fail();
} except (expectederror e) {
log_error(attempt);
}
return null;
}
I implied nothing of the sort, so I'll just ignore the rest of your comment for being completely irrelevant.
Only because the MPG rating allows comparisons with US ratings often published in Canada as well.
Meanwhile, the USA has officially been metric for years but posts speeds in mph.
Recommended platformers? None.
Side-scrollers, yes -- JetPack Joyride ... because it only has one control (press screen or don't press screen).
Look up DJB's stralloc.c sometime, its the closest C has ever gotten to having real strings.
Now for comparison, look at Python's handling of strings: http://getpython3.com/diveintopython3/strings.html
For the TL;DR people out there, Python has both strings of characters and sequences of bytes, and they are not the same things. C on the other hand only has sequences of bytes.
Platformers don't bother me on a phone/tablet. In fact, Temple Run is a good example of using swipe actions.
I meant first-person shooters, and no, the thumb-on-screen system is nowhere near being a mouse and keyboard, because my fingers can't find the exact placements to use at a moment's notice ... no physical keyboard after all, have to look periodically to make sure your thumb is centered ...
As to accelerometers, they're not perfect. I prefer buttons for steering ... mostly because of the lack of auto-centering like on a joystick or with buttons. That is to say, if I hold the tablet perfectly level, its not perfectly level, its off by a bit and the car slowly bends left or right.
In the very long run, the Steam on-sale games are cheaper, and have lower hardware requirements than current games too (saving a bit of money). Last time I did the math on it though, I bought a PS3 instead of a video card of the same price.
And now that my PS3 is getting a bit long in the tooth, I could upgrade my PC to handle 1920x1080x60fps + 5.1 audio gaming on my TV ... but not for $250. So technically my PS3 is still doing better.
And for the inevitable critics, yes I play several *Actual* AAA titles at 1080p. I never got into console cross-platform titles because they're rendered way below HD and upscaled on all the consoles. Very annoyingly blurry.
I thought it was more ironic that Google has just introduced Drive this year, their own Dropbox replacement.
Wait, you think testing C and C++ against possible exploits is easier than using an interpreted language like Python or Perl? I wouldn't go back to writing my CGI with C unless there was a no-lawsuits clause.
I still use Zope when I want to write Python for the web.
Its not perfect, but its one of the best options. Write your own module using the interfaces given and voila.