This is possible in France due to the primary and runoff elections.
The US system with exactly one election means there are only going to be two candidates, always, no matter what. The only way your new centrist party could win is if either the Democrats or Republicans actually dropped out of the race.
Sorry. The level of intelligence on SlashDot has dropped so much that you may need to more clearly indicate that something is satire. I really thought it was a sincere statement by an idiot.
Yea, right, I'm sure a letter from the credit card companies is really believable. And even they had to insert this text before they started complaining about the evil guberment:
"The CARD Act has provided consumers with significant benefits, among them the elimination (with few exceptions) of increases on interest rates on existing balances, whether the regular purchase interest rate or an introductory or promotional rate. These restrictions help consumers avoid surprises due to increases in their interest rates. In addition, since implementation of the CARD Act, customers are paying significantly less in late payment fees and overthelimit fees. Customers also appear to be paying a higher portion of their outstanding balances, perhaps due to the minimum payment disclosure of the CARD Act, which explains how long it will take customers to repay a credit card balance if they only pay the minimum payment.
"While the CARD Act has provided clear and significant benefits to consumers, there have also been significant tradeoffs...
Sorry, no. They broke strings entirely in Python 3.0 and that is why people cannot port to them.
Here is how to do strings correctly: use UTF-8 and DO NOT BARF ON ENCODING ERRORS!
It is absolutely 100% a requirement that a program be able to read a random byte stream into a "string", then write it out again, and get the same byte stream.
In Python 2.0 this only barfed if you tried to convert that string to "Unicode" (it would have been nice if it did not barf, but at least you could store, read, and write strings).
In Python 3.0 it will BARF ON READ. This makes it impossible to write reliable software.
Yes you can use "bytes" in Python 3.0. But that really sucks if in fact you expect your bytes to be readable text, with only RARE (but not magically non-existent) errors.
Wayland does in fact have support for resolution independence. By this I mean that if a program does nothing about the resolution of the screen, Wayland assumes it is drawing for approximately 100 dpi, and scales the image by 2 if the screen is 200dpi. I think it only does integer scaling but it may be up to the compositor implementation.
If a program actually claims it's drawing for the high-resolution display, then Wayland does not scale. The problem with X (and I think with Windows) was that there was no api so a program could tell the system that it is handling the high resolution, so the compositor had to assume it was.
So some Uber rides will cost 50 cents more because the driver is doing this? I don't think so. This will come out of the drivers income. Don't be naive.
Honestly the changes in Python 3 should not be any obstacle to porting code. Most of it winds up being a find and replace. The major difference is the use of unicode, and if your package really depends heavily on strings not being unicode, you probably did it wrong. The problem is that if one package that lots of people depend on has devs that just say, "I don't wanna," everything breaks down. And more than one package has devs like that.
At this point, if the Python community could make "porting" as simple as adding a header to a.py file, there would still be people that would refuse to do it.
The problem with Python 3 "unicode" is not that text is not Unicode. The problem is that *random binary data* is not Unicode, but when you read data from an unknown source, you MUST assume it is "random binary data". Trusting it to follow some pattern is by far the stupidest thing you can do.
In Python 2 you could put random binary data into a "string" and then write it to disk without any change, and no errors would be produced. Only if you tried to *display* the string would you get an exception. In Python 3 it will immediately throw an exception, at a completely useless point in your program (ie when you are reading data in, not when you are processing it). Changing every "string" to a "bytes" will "fix" it, but then you have to change the type of every single function that is called from "string" to "bytes", and so on, eventually replacing every single "string" in your program with "bytes". And you are out of luck if one of those api's is from a library that you don't control.
Python 3 will NEVER get accepted unless you can put totally arbitrary patterns of 8-bit data into a "string" and get them back out unchanged. All exceptions must be deferred until something actually tries to split the data into Unicode code points. Even then they should be providing a more useful iterator based api that returns an object that says "the code point is this" or "there is a UTF-8 parsing error here and the first byte is this".
I don't know if you are trying to make a joke, but global warming is not going to do too much to the earthquakes. Greenland is already rising steadily due to the loss of the glaciers from the last ice age. It is really slow and will still happen for tens of thousands of years. Even if all the current ice cap disappeared tomorrow it would, at best, speed this up a tiny amount (the current ice cap is a fraction of the ice age ice cap so the amount of lost mass is only a small change). The weight of the new ice added to the ocean is insignificant (if it raised the ocean 30 feet that would still only be a tiny fraction of mass increase, think about how deep the ocean is).
That does not make sense. If the path is too long to fit in the buffer the software could not work anyway, since the text returned cannot be the correct path name. So I agree I don't see what the problem is and why this is not the default.
If nothing is holding them up (ie in free fall if they turn off their engines) then the proper bank would be at 90 degrees, not some smaller angle. Also (more importantly) the engines need to fire exactly outward from the turn (basically it will make a circle around some point the engines are pointing toward and cannot do anything else).
Best design for a ship would have the engine firing straight down when the humans are in a comfortable position. A highly maneuverable ship would fly "sideways" during maneuvers, the engine firing crosswise to maximize it's ability to change direction as it approaches an enemy. It would only fly parallel to the engine when accelerating. And it would have to spend an equal amount of time decelerating, and that is what it would likely be doing when approaching an enemy. This also points the engine at the enemy, and considering how fast the exhaust must be (seeing as these ships seem to contain very little reaction mass) that engine is much more powerful and destructive than any other weapon they have.
Ding ding ding! Somebody has actually identified the reason you cannot migrate from 2 to 3.
In 2 you can read arbitrary bytes into a string without throwing an exception. Only if you try to convert to a Unicode string would an exception be thrown, and you can do lots of stuff with strings without converting them to Unicode (such as read and write the to files and examine the bytes).
In 3 reading into a string can throw an exception if the stream of bytes has an encoding error. The "solution" is that you have to read into a bytes array. But almost certainly what you want to do with the data is pass it to another function that takes a string, and that will throw the exception (either for the wrong data type or because it tried to convert the bytes to a string). You have to rewrite every single function you will call to take a bytes array, rewriting every single thing they call, etc. This is not possible for any reasonable sized software project. It also is really annoying in that 99.99% of the time the data is a "string" in that it is valid UTF-8, and you have thrown away any easy methods of looking at them or comparing them to quoted string constants.
The "string" should have remained a byte array so it could be used for arbitrary bytes, and indexing returns the bytes. "decoding" to Unicode should have been done with iterators, which have the advantage that you can choose the iterator to handle errors in different ways, and to do Unicode normalization if wanted. The "unicode" strings (which are arrays of 16 or 32-bit items) could remain for back-compatibility but deprecated.
Something about Unicode turns otherwise intelligent people into idiot savants, where they will figure out obscenely complex "solutions" for a problem (encoding errors) that should be no more difficult than figuring out how to make your word processor not crash on misspelled words.
No fan of Trump, but he certainly is not doing "what is profitable for himself". As a business decision running for president is a really stupid idea so he is obviously not making decisions based on what makes him the most money.
He does want to feed his ego, which is going to be a lot less predictable than "what makes Trump the most money".
That seems like it would work. I think it could also make sure the text is typed on the "new" keyboard so even your proposed stupid user could not type it in.
Slashdot Mirror
This is possible in France due to the primary and runoff elections.
The US system with exactly one election means there are only going to be two candidates, always, no matter what. The only way your new centrist party could win is if either the Democrats or Republicans actually dropped out of the race.
Sorry. The level of intelligence on SlashDot has dropped so much that you may need to more clearly indicate that something is satire. I really thought it was a sincere statement by an idiot.
Because you just typed in both passwords and it remembered them?
Yea, right, I'm sure a letter from the credit card companies is really believable. And even they had to insert this text before they started complaining about the evil guberment:
"The CARD Act has provided consumers with significant benefits, among them the elimination (with
few exceptions) of increases on interest rates on existing balances, whether the regular purchase
interest rate or an introductory or promotional rate. These restrictions help consumers avoid surprises
due to increases in their interest rates. In addition, since implementation of the CARD Act, customers
are paying significantly less in late payment fees and overthelimit fees. Customers also appear to be
paying a higher portion of their outstanding balances, perhaps due to the minimum payment disclosure
of the CARD Act, which explains how long it will take customers to repay a credit card balance if they
only pay the minimum payment.
"While the CARD Act has provided clear and significant benefits to consumers, there have also been
significant tradeoffs...
I was just trying to say that if you want to run Maya you don't need Windows emulation.
You can get Maya for Linux
"Jobwashing" - Similar to "greenwashing" but updated for the present era.
Sorry, no. They broke strings entirely in Python 3.0 and that is why people cannot port to them.
Here is how to do strings correctly: use UTF-8 and DO NOT BARF ON ENCODING ERRORS!
It is absolutely 100% a requirement that a program be able to read a random byte stream into a "string", then write it out again, and get the same byte stream.
In Python 2.0 this only barfed if you tried to convert that string to "Unicode" (it would have been nice if it did not barf, but at least you could store, read, and write strings).
In Python 3.0 it will BARF ON READ. This makes it impossible to write reliable software.
Yes you can use "bytes" in Python 3.0. But that really sucks if in fact you expect your bytes to be readable text, with only RARE (but not magically non-existent) errors.
It's satire, stupid
Actually this won't fix X11 applications running on Wayland, as they are just using X11 api which lacks any "I understood the resolution" call.
Wayland does in fact have support for resolution independence. By this I mean that if a program does nothing about the resolution of the screen, Wayland assumes it is drawing for approximately 100 dpi, and scales the image by 2 if the screen is 200dpi. I think it only does integer scaling but it may be up to the compositor implementation.
If a program actually claims it's drawing for the high-resolution display, then Wayland does not scale. The problem with X (and I think with Windows) was that there was no api so a program could tell the system that it is handling the high resolution, so the compositor had to assume it was.
So some Uber rides will cost 50 cents more because the driver is doing this? I don't think so. This will come out of the drivers income. Don't be naive.
Honestly the changes in Python 3 should not be any obstacle to porting code. Most of it winds up being a find and replace. The major difference is the use of unicode, and if your package really depends heavily on strings not being unicode, you probably did it wrong. The problem is that if one package that lots of people depend on has devs that just say, "I don't wanna," everything breaks down. And more than one package has devs like that.
At this point, if the Python community could make "porting" as simple as adding a header to a .py file, there would still be people that would refuse to do it.
The problem with Python 3 "unicode" is not that text is not Unicode. The problem is that *random binary data* is not Unicode, but when you read data from an unknown source, you MUST assume it is "random binary data". Trusting it to follow some pattern is by far the stupidest thing you can do.
In Python 2 you could put random binary data into a "string" and then write it to disk without any change, and no errors would be produced. Only if you tried to *display* the string would you get an exception. In Python 3 it will immediately throw an exception, at a completely useless point in your program (ie when you are reading data in, not when you are processing it). Changing every "string" to a "bytes" will "fix" it, but then you have to change the type of every single function that is called from "string" to "bytes", and so on, eventually replacing every single "string" in your program with "bytes". And you are out of luck if one of those api's is from a library that you don't control.
Python 3 will NEVER get accepted unless you can put totally arbitrary patterns of 8-bit data into a "string" and get them back out unchanged. All exceptions must be deferred until something actually tries to split the data into Unicode code points. Even then they should be providing a more useful iterator based api that returns an object that says "the code point is this" or "there is a UTF-8 parsing error here and the first byte is this".
An annual cost of $230 is about $20/month. I am paying that for one HD DVR from Frontier. So I think this average certainly is from single boxes.
I don't know if you are trying to make a joke, but global warming is not going to do too much to the earthquakes. Greenland is already rising steadily due to the loss of the glaciers from the last ice age. It is really slow and will still happen for tens of thousands of years. Even if all the current ice cap disappeared tomorrow it would, at best, speed this up a tiny amount (the current ice cap is a fraction of the ice age ice cap so the amount of lost mass is only a small change). The weight of the new ice added to the ocean is insignificant (if it raised the ocean 30 feet that would still only be a tiny fraction of mass increase, think about how deep the ocean is).
It's "auto&&" now, but don't forget to put "std::move()" around things anyway for when this still does not do what you want.
I'm am worried they will later have to make "auto&&&" to get "what everybody really expects auto to do as C++17 still got it wrong".
Maybe they should recover it and put it in the Smithsonian.
That would be the most expensive museum relic in the history of the world however.
That does not make sense. If the path is too long to fit in the buffer the software could not work anyway, since the text returned cannot be the correct path name. So I agree I don't see what the problem is and why this is not the default.
If nothing is holding them up (ie in free fall if they turn off their engines) then the proper bank would be at 90 degrees, not some smaller angle. Also (more importantly) the engines need to fire exactly outward from the turn (basically it will make a circle around some point the engines are pointing toward and cannot do anything else).
Best design for a ship would have the engine firing straight down when the humans are in a comfortable position. A highly maneuverable ship would fly "sideways" during maneuvers, the engine firing crosswise to maximize it's ability to change direction as it approaches an enemy. It would only fly parallel to the engine when accelerating. And it would have to spend an equal amount of time decelerating, and that is what it would likely be doing when approaching an enemy. This also points the engine at the enemy, and considering how fast the exhaust must be (seeing as these ships seem to contain very little reaction mass) that engine is much more powerful and destructive than any other weapon they have.
I don't think businesses that want a locked down desktop allow people to plug in random scanners and printers
There is a space between "else" and "printf" that can't be removed.
Ding ding ding! Somebody has actually identified the reason you cannot migrate from 2 to 3.
In 2 you can read arbitrary bytes into a string without throwing an exception. Only if you try to convert to a Unicode string would an exception be thrown, and you can do lots of stuff with strings without converting them to Unicode (such as read and write the to files and examine the bytes).
In 3 reading into a string can throw an exception if the stream of bytes has an encoding error. The "solution" is that you have to read into a bytes array. But almost certainly what you want to do with the data is pass it to another function that takes a string, and that will throw the exception (either for the wrong data type or because it tried to convert the bytes to a string). You have to rewrite every single function you will call to take a bytes array, rewriting every single thing they call, etc. This is not possible for any reasonable sized software project. It also is really annoying in that 99.99% of the time the data is a "string" in that it is valid UTF-8, and you have thrown away any easy methods of looking at them or comparing them to quoted string constants.
The "string" should have remained a byte array so it could be used for arbitrary bytes, and indexing returns the bytes. "decoding" to Unicode should have been done with iterators, which have the advantage that you can choose the iterator to handle errors in different ways, and to do Unicode normalization if wanted. The "unicode" strings (which are arrays of 16 or 32-bit items) could remain for back-compatibility but deprecated.
Something about Unicode turns otherwise intelligent people into idiot savants, where they will figure out obscenely complex "solutions" for a problem (encoding errors) that should be no more difficult than figuring out how to make your word processor not crash on misspelled words.
No fan of Trump, but he certainly is not doing "what is profitable for himself". As a business decision running for president is a really stupid idea so he is obviously not making decisions based on what makes him the most money.
He does want to feed his ego, which is going to be a lot less predictable than "what makes Trump the most money".
That seems like it would work. I think it could also make sure the text is typed on the "new" keyboard so even your proposed stupid user could not type it in.
I think he is saying the car is exempted, but he is not allowed to modify it, even if his modifications would make it less polluting.