Could somebody tell me if the update will house a dual boot machine. I have avoided booting into Windows because of fear it will wipe my Linux partition or at least require fixing the boot manager. I am fine otherwise with updating to Microsoft's latest.
Modern rail lines do not have expansion gaps. The rail is continuous (made of short pieces welded together) and is under tension, so heat just makes the tension go down slightly.
Gnome 2 disabled the ability that existed in almost all earlier X11 window managers to work with overlapping windows, by forcing you to raise windows on click.
There was an option in gconf to turn off raise-on-click, but for some reason it also disabled the ability of a program to raise its *own* windows. This effectively makes the option useless. The obvious reason is because the designers did not want that, because it might confuse those poor Windows users (Windows also forces clicks to raise windows). The gconf included a long comment about how absolutely logical and necessary this was and how any program relying on the ability to *decide* whether to raise on click was "broken". Surely one of the biggest pieces of bullshit I have seen in a long time. And these people are still working on this, making it worse and worse.
The text is designed to be copied and pasted into a terminal.
Generally this is a lot easier than "find Registry Editor here on the start menu, now click here, here, here and then scroll down to find this item, now paste in this text which is just as mysterious as any Linux command".
It is true that when it does not work there is not a lot of help.
Error diffusion will help (calculate the floating point value and then store the two nearest integers with a probability based on the value) but not if the correction is extreme. Blurting the image to a floating point value will fix it but, of course, introduces blur.
Which happens to be the fifth year after the beginning of 1979 and the first five year averaging period which can use the data set I already mentioned.
He did not plot against an average of the temperature measurements, he chose a specific year.
I'd like to know what "predictions" have such wildly sqiggly graphs.
I suspect this graph is meaninless bunk unless you can come up with a really good explanation for what those "44 lines" mean. Best guess (after the "it's all made up" guess) is that somebody scribbled lines between the maximum error bars of all of them.
There has been at no time proof of deliberate deception. It is all asserted without evidence.
Holy crap are you stupid.
He chose the hottest possible year as the "baseline" to start the predictions from, so they are as high as possible, then chose a totally different "running average" which also causes that hottest year to produce a flat line (notice that his "plot" of temperatures starts flat and increases in slope, completely contrary to normal denialist claim that warming has slowed). What are the odds that out of 30 or so years to choose from, he would choose the one with the greatest height above the average linear line? The odds that this is deliberate deception are about 30:1.
The fact that you see unable to see this is just an indication that you are a close minded idiot.
I was amused when I bought a blender online. I was deluged with ads for blenders! Hint: since I now have a brand-new blender, I am actually the least-likely person to want to buy a blender!
I think I made it worse because I also searched for Blender the software.
C++98 did have the "throw" function specification, and in general it was found to be more trouble than it was worth, with the possible exception of "throw()", which should be replaced by "noexcept" in modern C++.
Apparently it was Visual C++ that made "throw()" do what "noexcept" now does: it means you can be certain that this code will not throw an exception. This caused it to be used a lot, but the actual C++ definition of what "throw()" did was not that at all and was quite useless.
"finally" does not exist in C++, fortunately, since RAII is much better. There's no reason you can't allocate on the heap and have destructors clean everything up. That's what auto_ptr was for in C++98 and what shared_ptr and unique_ptr are for in C++11. If you need to worry about what the destructors are doing and what order they're called in, you're almost always doing it wrong. (There may be applications I am currently unfamiliar with where that matters, but that would be unfortunate.) A "finally" block has low cohesion and high coupling, whereas destructors have high cohesion and low coupling.
You are correct that RAII can do everything "finally" does, but it does sometimes require the writing of very strange classes when some kind of finally statement would work better. But to actually work well the statement can't be at the end, it should be next to the definition. Something like this would work just like a local unique_ptr (not suggesting this but imagine a more one-off instance of something that needs destruction):
char* ptr = new char[BUFSIZE];
finally { delete[] ptr; }
We're still going to need two objects, one a base object and one a pointer object. If we use raw pointers, the reference count will not be incremented and decremented properly, and we need the reference count to reliably be equal to the number of pointers extant. Therefore, the pointer needs to have its own copy constructor, copy assignment operator, and destructor, which will call the appropriate increment and decrement methods (the decrement method to include the deletion as a special case). If we keep the reference count with the object instead of with the pointer, we can keep the pointer size down without indirection.
This is no more complicated than what has to be done with shared_ptr. And you are confused, you can use raw pointers all you want, as long as you know there is a shared_ptr pointing at the object. This happens in many cases.
We need to document heavily that IRefCount (or something more according to C++ naming) is to be inherited virtually, as otherwise we could have more than one reference count if we add it to multiple levels of a class hierarchy. (C++ multiple inheritance can be tricky to get right.)
So, we've got the pointer object, which will contain the pointer and have some attached functionality, and the reference count mixin. This works as long as we can easily modify the class structure, but it does require a fairly sophistication serialization/deserialization system to keep the modified and unmodified objects in sync. In addition, since it changes the memory layout of a class, it can lead to slow compiles.
It's not a "mixin". It is a base class. This avoids your supposed problems.
With this, we also don't get weak_ptr functionality. A shared_ptr object has a shared pointer count and a weak pointer count. This makes it possible, for example, to have a circular list that can be destructed: have one link be a weak_ptr and everything else a shared_ptr. The object itself is destructed when the shared pointer count goes to zero, and the shared_ptr object when both go to zero. (A weak_ptr does nothing on its own, but can be converted to a shared_ptr if the target object is still there.)
You can implement weak_ptr in EXACTLY the same way make_shared does it. The object is destroyed but the memory is not freed until the weak_ptr count goes to zero. In fact it is fairly easy to have "an object that supports weak_ptr" be a different base class than the plain refcounted object, thus you don't pay for the weak_ptr overhead on every pointer (though you can't make a weak_ptr unless the object is derived from the correct base class).
I don't see this as being easier than shared_ptr, although it is superior for some purposes.
It is enormously easier when you have to do the equivalent of make_shared_from_this (or whatever they called it), and to avoid constructor shenanigans so that the user has to call make_shared and not construct raw objects. The implementation is about the same as shared_ptr.
Boost called this an "intrusive pointer" but they did not support weak pointers. That could be done with a few extra calls. It was a bit ugly as they tried to not define the base class (instead it called functions that the class defined to inc/dec the ref count), I think insisting that everything be based on a refcounted base class would work just fine.
It is not quarting the momentum. It is increasing the mass, while keeping the momentum the same. This reduces the velocity, but (I suspect more importantly) the momentum is delivered to a larger area of the target, which is what really reduces the lethality.
Huh? Here is the 2nd paragraph of the linked site. It certainly does refute the post above. I think your reading comprehension needs some work:
"Radiocarbon analysis has dated the parchment on which the text is written to the period between AD 568 and 645 with 95.4% accuracy. The test was carried out in a laboratory at the University of Oxford. The result places the leaves close to the time of the Prophet Muhammad, who is generally thought to have lived between AD 570 and 632."
Note that "AD 568 to 645" is different than the Slashdot article lead which says "545 AD and 568".
Holy crap, stop it with your "insightful" comments that Seattle is not very Republican. The poster knows that and is just delighting in seeing you people show your idiocy by trying to "correct" him.
A nuclear accident could easily release a lot more radiation than a coal plant. You are confused by the often-quoted fact that when operating normally, a coal plant can release more radiation. An accident though means the plant is not operating normally.
This may mean that the risk from the radiation from either type of plant when operating normally is pretty low. It's fun to point out that more radiation comes from a coal plant, but I'm pretty certain the danger from breathing the other crap that comes out of the coal plant way outweighs the radiation danger.
I think he is comparing the energy in the beam to the total of all wavelengths in the sunlight, not just the microwaves. However the wording is certainly misleading and I read it the same way you did, too.
You are right, one of the features of these "Republican" posts is they often are done for regions or groups that are certainly *not* Republican. This is probably the clearest indication that these are troll posts.
I believe the "stupid Republicans" posts are a troll, possibly from somebody who is actually right-wing. They are designed to look like they are posted by as stupid a person as possible. Have seen a couple equally ludicrous ones for the opposite direction, though they tend to use "Liberals" rather than "Democrats". Sometimes they use the exact same wording as the republican attack. Not as common, however, for whatever that means.
I would agree. Anybody with a model railroad I have ever known is a married male in retirement, who had kids that have moved out of the house. So I kind of doubt any of them are virgins.
The intention is to have the database update when the close() is done, not on every write().
It is pretty obvious that the desired functionality could be done by fuse, where a get() is done on open and a put() is done on close if write was ever called.
I think the modern day applications that only write a part of a file are nearly non-existent (and in fact partial update where another program can see your unfinished writing, is usually a bug, not a feature). So there is no need for any api other than put().
There is a nice subset that only reads part of a file (and that part almost always includes the start of the file) however. So I can see this as being an argument for being able to access blocks of data from the remote.
Slashdot Mirror
Could somebody tell me if the update will house a dual boot machine. I have avoided booting into Windows because of fear it will wipe my Linux partition or at least require fixing the boot manager. I am fine otherwise with updating to Microsoft's latest.
Modern rail lines do not have expansion gaps. The rail is continuous (made of short pieces welded together) and is under tension, so heat just makes the tension go down slightly.
So what's missing from say 2.x that was in 0.x?
Ability to work on a window without raising it to the top.
Gnome 2 disabled the ability that existed in almost all earlier X11 window managers to work with overlapping windows, by forcing you to raise windows on click.
There was an option in gconf to turn off raise-on-click, but for some reason it also disabled the ability of a program to raise its *own* windows. This effectively makes the option useless. The obvious reason is because the designers did not want that, because it might confuse those poor Windows users (Windows also forces clicks to raise windows). The gconf included a long comment about how absolutely logical and necessary this was and how any program relying on the ability to *decide* whether to raise on click was "broken". Surely one of the biggest pieces of bullshit I have seen in a long time. And these people are still working on this, making it worse and worse.
The text is designed to be copied and pasted into a terminal.
Generally this is a lot easier than "find Registry Editor here on the start menu, now click here, here, here and then scroll down to find this item, now paste in this text which is just as mysterious as any Linux command".
It is true that when it does not work there is not a lot of help.
Error diffusion will help (calculate the floating point value and then store the two nearest integers with a probability based on the value) but not if the correction is extreme. Blurting the image to a floating point value will fix it but, of course, introduces blur.
Which happens to be the fifth year after the beginning of 1979 and the first five year averaging period which can use the data set I already mentioned.
He did not plot against an average of the temperature measurements, he chose a specific year.
I'd like to know what "predictions" have such wildly sqiggly graphs.
I suspect this graph is meaninless bunk unless you can come up with a really good explanation for what those "44 lines" mean. Best guess (after the "it's all made up" guess) is that somebody scribbled lines between the maximum error bars of all of them.
There has been at no time proof of deliberate deception. It is all asserted without evidence.
Holy crap are you stupid.
He chose the hottest possible year as the "baseline" to start the predictions from, so they are as high as possible, then chose a totally different "running average" which also causes that hottest year to produce a flat line (notice that his "plot" of temperatures starts flat and increases in slope, completely contrary to normal denialist claim that warming has slowed). What are the odds that out of 30 or so years to choose from, he would choose the one with the greatest height above the average linear line? The odds that this is deliberate deception are about 30:1.
The fact that you see unable to see this is just an indication that you are a close minded idiot.
Confusing weather with climate. Denier spotted!
I was amused when I bought a blender online. I was deluged with ads for blenders! Hint: since I now have a brand-new blender, I am actually the least-likely person to want to buy a blender!
I think I made it worse because I also searched for Blender the software.
C++98 did have the "throw" function specification, and in general it was found to be more trouble than it was worth, with the possible exception of "throw()", which should be replaced by "noexcept" in modern C++.
Apparently it was Visual C++ that made "throw()" do what "noexcept" now does: it means you can be certain that this code will not throw an exception. This caused it to be used a lot, but the actual C++ definition of what "throw()" did was not that at all and was quite useless.
"finally" does not exist in C++, fortunately, since RAII is much better. There's no reason you can't allocate on the heap and have destructors clean everything up. That's what auto_ptr was for in C++98 and what shared_ptr and unique_ptr are for in C++11. If you need to worry about what the destructors are doing and what order they're called in, you're almost always doing it wrong. (There may be applications I am currently unfamiliar with where that matters, but that would be unfortunate.) A "finally" block has low cohesion and high coupling, whereas destructors have high cohesion and low coupling.
You are correct that RAII can do everything "finally" does, but it does sometimes require the writing of very strange classes when some kind of finally statement would work better. But to actually work well the statement can't be at the end, it should be next to the definition. Something like this would work just like a local unique_ptr (not suggesting this but imagine a more one-off instance of something that needs destruction):
char* ptr = new char[BUFSIZE];
finally { delete[] ptr; }
We're still going to need two objects, one a base object and one a pointer object. If we use raw pointers, the reference count will not be incremented and decremented properly, and we need the reference count to reliably be equal to the number of pointers extant. Therefore, the pointer needs to have its own copy constructor, copy assignment operator, and destructor, which will call the appropriate increment and decrement methods (the decrement method to include the deletion as a special case). If we keep the reference count with the object instead of with the pointer, we can keep the pointer size down without indirection.
This is no more complicated than what has to be done with shared_ptr. And you are confused, you can use raw pointers all you want, as long as you know there is a shared_ptr pointing at the object. This happens in many cases.
We need to document heavily that IRefCount (or something more according to C++ naming) is to be inherited virtually, as otherwise we could have more than one reference count if we add it to multiple levels of a class hierarchy. (C++ multiple inheritance can be tricky to get right.)
So, we've got the pointer object, which will contain the pointer and have some attached functionality, and the reference count mixin. This works as long as we can easily modify the class structure, but it does require a fairly sophistication serialization/deserialization system to keep the modified and unmodified objects in sync. In addition, since it changes the memory layout of a class, it can lead to slow compiles.
It's not a "mixin". It is a base class. This avoids your supposed problems.
With this, we also don't get weak_ptr functionality. A shared_ptr object has a shared pointer count and a weak pointer count. This makes it possible, for example, to have a circular list that can be destructed: have one link be a weak_ptr and everything else a shared_ptr. The object itself is destructed when the shared pointer count goes to zero, and the shared_ptr object when both go to zero. (A weak_ptr does nothing on its own, but can be converted to a shared_ptr if the target object is still there.)
You can implement weak_ptr in EXACTLY the same way make_shared does it. The object is destroyed but the memory is not freed until the weak_ptr count goes to zero. In fact it is fairly easy to have "an object that supports weak_ptr" be a different base class than the plain refcounted object, thus you don't pay for the weak_ptr overhead on every pointer (though you can't make a weak_ptr unless the object is derived from the correct base class).
I don't see this as being easier than shared_ptr, although it is superior for some purposes.
It is enormously easier when you have to do the equivalent of make_shared_from_this (or whatever they called it), and to avoid constructor shenanigans so that the user has to call make_shared and not construct raw objects. The implementation is about the same as shared_ptr.
Boost called this an "intrusive pointer" but they did not support weak pointers. That could be done with a few extra calls. It was a bit ugly as they tried to not define the base class (instead it called functions that the class defined to inc/dec the ref count), I think insisting that everything be based on a refcounted base class would work just fine.
"Least hypocritical country which neither pretends that it is democratic, nor that it never spies on its own citizens"
North Korea? I think the civilians know quite well they are being spied on.
Did you flunk basic physics?
It is not quarting the momentum. It is increasing the mass, while keeping the momentum the same. This reduces the velocity, but (I suspect more importantly) the momentum is delivered to a larger area of the target, which is what really reduces the lethality.
Huh? Here is the 2nd paragraph of the linked site. It certainly does refute the post above. I think your reading comprehension needs some work:
"Radiocarbon analysis has dated the parchment on which the text is written to the period between AD 568 and 645 with 95.4% accuracy. The test was carried out in a laboratory at the University of Oxford. The result places the leaves close to the time of the Prophet Muhammad, who is generally thought to have lived between AD 570 and 632."
Note that "AD 568 to 645" is different than the Slashdot article lead which says "545 AD and 568".
The "republicans" post is a TROLL!
Holy crap, stop it with your "insightful" comments that Seattle is not very Republican. The poster knows that and is just delighting in seeing you people show your idiocy by trying to "correct" him.
A nuclear accident could easily release a lot more radiation than a coal plant. You are confused by the often-quoted fact that when operating normally, a coal plant can release more radiation. An accident though means the plant is not operating normally.
This may mean that the risk from the radiation from either type of plant when operating normally is pretty low. It's fun to point out that more radiation comes from a coal plant, but I'm pretty certain the danger from breathing the other crap that comes out of the coal plant way outweighs the radiation danger.
I think he is comparing the energy in the beam to the total of all wavelengths in the sunlight, not just the microwaves. However the wording is certainly misleading and I read it the same way you did, too.
You are right, one of the features of these "Republican" posts is they often are done for regions or groups that are certainly *not* Republican. This is probably the clearest indication that these are troll posts.
I believe the "stupid Republicans" posts are a troll, possibly from somebody who is actually right-wing. They are designed to look like they are posted by as stupid a person as possible. Have seen a couple equally ludicrous ones for the opposite direction, though they tend to use "Liberals" rather than "Democrats". Sometimes they use the exact same wording as the republican attack. Not as common, however, for whatever that means.
I would agree. Anybody with a model railroad I have ever known is a married male in retirement, who had kids that have moved out of the house. So I kind of doubt any of them are virgins.
The intention is to have the database update when the close() is done, not on every write().
It is pretty obvious that the desired functionality could be done by fuse, where a get() is done on open and a put() is done on close if write was ever called.
I think the modern day applications that only write a part of a file are nearly non-existent (and in fact partial update where another program can see your unfinished writing, is usually a bug, not a feature). So there is no need for any api other than put().
There is a nice subset that only reads part of a file (and that part almost always includes the start of the file) however. So I can see this as being an argument for being able to access blocks of data from the remote.
You are required to use a different context per-thread, so of course you got "interesting" bugs using the same context.
However even if you used different contexts there are bugs in the drivers (or hardware) so it did not work.
You will be able to request that the car stay around until you go back. It will cost you something, however.