I'm just a layman, but from what I gather the extra dimensions are supposed to be circular rather than "linear", like the ones we commonly use. The circumference of these circles is very small (Planck length).
The most impressive eye-tracking device I've ever seen is Tobii. It's based on infrared sensors which detect the movement of your eyes. I was pretty much amazed with the accuracy of the device, much better than I thought it would be.
Re:Nope, it's the putative new users problem
on
Linux Needs Critics
·
· Score: 1
Please stop. This sort of prejudice has been following OSS developers since forever, but is nothing more than a load of crap. I'm going to say it one more time: we DON'T use emacs, we use vim!
Just got back from CeBIT, tried out an eye tracking device made by Tobii. I guess the technology has been around for a while now (the girl at the stand said they've been in business since 2003 I think) but I've never had a chance to try it out myself. Very, very impressive.
Basically you control the mouse pointer with just your eyes. The calibration is dead simple, you just need to look at two corners of your screen and that's it. The accuracy of the device amazed me completely. The sentiment is perhaps best conveyed by my a comment made by a colleague of mine after trying out the device: "dude, let's go to a strip bar. We've just seen a computer you can control with your eyes. What else could impress us... but tits?"
Their main use cases so far are disabled persons, but it's also used by e.g. marketing people to check which parts of the add your eyes focus on mostly etc.
Have the EU set up a software repository. Force MS to modify Windows copies sold in the EU so that they connect to this repository the first time the user clicks the "Internet" icon.
And c'mon, realistically, how difficult it is to choose the browsers? Firefox, Safari, Opera, Chrome. You don't need an exact mathematical formula to figure it out, just use common sense
EU could also use the same mechanism to offer other kinds of software for Windows.
The site will be almost entirely content. It will need to be updated by non-technical staff, specifically uploading PDFs, creating new pages, and applying tags from a set taxonomy. It will need to handle user accounts and control access permissions down to the page level. This doesn't seem to call for much more than a standard CMS.
We do not want to spend a lot of money on a license. We want a system that we can host and for which we can easily outsource work (no vendor lock-in).
So far so good. Joomla might fit the bill (the permissions bit might be problematic depending on your exact needs).
We want a system that we can customize pretty easily; bonus if there is a large community creating extensions.
That's where it starts to get interesting. Customizing Joomla is a pain. The "core" is not designed in a very modular/extensible way, and the quality of the code itself is generally low. Joomla provides nothing which would resemble a framework (think Cake, Symphony, etc) making you re-invent the wheel for every component (or create a framework of your own).
The quality of third-party extensions (or "components" in the parlance) ranges, with some exceptions, from bad to dowright attrocious. To be fair most of them do their job, but customizing them? Forget it. Security-wise, you're lucky if they escape their SQL, forget about XSS or heaven forbid CSRF prevention. Not to mention that they tend to follow the time-honored PHP tradition of "notices are OK".
Also, because of the lack of extensibility in Joomla, components often include so-called "core hacks", which comprise of replacing the original Joomla files with their own version. You can imagine that because of this some components don't play very well with each other, and don't play well with Joomla upgrades at all
Search-engine friendly links are also a problem. Joomla comes with a SEF URL rewriter, but often that doesn't cover all the needs. So you need to install yet another component (openSEF or 404sef), which also tends to step on toes of some other things.
The low cost IMHO is a red herring. I used to do contract work for a small company specialized in customizing Joomla for clients. The process would generally go like this:
The client wants to install Joomla - hey it's free, and has all these great features out of the box. He needs the template and some extra functionality, for which we can find 3rd party components.
The designers create the template.
We install the components and customize their appearance to match the site
With very simple sites, this is where it would end. More often than not, the process continues
The customer decides that he needs some more functionality. Install more components
Somewhere along the line, interoperability issues start to pop up, work on fixing those. Also, upon detailed inspection, it turns out that functionality of the Joomla core/components is missing/inadequate, so the programmers (i.e. me) start looking for ways to customize them and/or write new code. Without a proper Web framework (and the popular PHP frameworks tend not to work inside Joomla) this takes much more time than with one.
By the time the process is finished, the original project has stretched from weeks to months, and the price has gone up from $1-2k to $10k+
The funny thing is, if we developed the CMS from scratch using a proper framework (or better, started by customizing a CMS that utilizes one):
Duplicating the functionality of Joomla/needed components would most likely take a week or two - realistically, 95% of it little more than a thin interface layer over the database. Developement of new functionality would be orders of magnituted faster.
Customizing the appearance would take about the same time as with Joomla
So please, do yourself a favor. Find a decent Web development company that works using a decent framework. I'm a Python fanboy so I'd su
Yet meatspin and goatse links still work. I do not know what the proper and official BSD logo is, but knowing that Slashdot censors it makes me shudder in horror.
As someone wrote above, there's a very elegant solution: use a repository, just like Linux distros do. Categorize the apps, and provide a short description along with each one.
Of course, a slight problem is that it's never going to happen.
That's OK, but that's not what I was asking. If the Universe is inherently "holographic" and the uncertainty at the Planck scale - 10^(-34)m in the "real" Universe translates to uncertainty on the scale of 10^(-16)m in "our" world, how would it be possible to perform measurements on the scale of 10^(-21)m in our world, no matter which method you use?
It might be that my memory is failing me and that the actual number is different, but I do remember that we were all amazed that the number was orders of magnitude smaller than the (classical) radius of an electron, which is about 10^(-15)m
I agree that static typing is somewhat more self-documenting, but not keeping your documentation up to date is yet another way to assure a maintainance hell, regardless of your choice of language.
And of course I'm not arguing that you can't have a good test suite with a statically typed language. I'm arguing that following best practices such as writing tests and documenting things renders the ostensible advantages of static type checking redundant. On the other hand, not following best practices also renders these advantages pretty much useless.
Just having your program successfully pass checks for static typing (i.e. that it compiles) provides no hints whether your program actually works. Having a good test suite, on the other hand, goes a long way - especially for projects which you expect to have to maintain.
A positive side-effect of having a good test suite is that it provides type checks as well
Somebody dubbed their financial management and planning software "Hyperion"? Are they aware that Hyperion is the sole satellite in the Solar system with a completely chaoitic orbit?
The article states that the uncertaintly at the Planck scale at the (hypothetical) border could translate to something like 10^(-16)m scale in "our world"? But some 10 years ago when I was at some research facility near Padua, they had a gravitational wave detector which they claimed could detect movement on the scale of 10^(-21)m so that would suggest we can already make much more precise measurements. How would that be possible?
(Disclaimer if I'm missing something obvious: I'm not a physicist)
Well you almost always use iterators in Python anyway, so yes the str class could do UTF-8 internally and implement an "intelligent" iterator. Slicing would require a bit more work, and generally the whole thing would be somewhat slower but who cares, Python isn't exactly the pinnacle of speed anyways. It's just a matter of priorities I guess.
But why the heck would you want to create constant strings containing UTF-8 errors? The only need I see for creating purposely errorenous UTF-8 is for round tripping existing malformed identifiers (such as filenames), not to introduce new ones! And also, how would you treat \u escapes in byte strings? Always as UTF-8? According to the encoding of the file? Explicit is better than implicit...
I disagree about UTF-8. My native tongue and both of its scripts (Latin and Cyrillyc) use non-ASCII characters, and iteration and slicing pop up fairly often - much more often than invalid UTF-8. I'd really hate it to have to think about code point boundaries while working on them, UCS-2/UTF-32 are much nicer in that regard.
Again, I'm not saying that the issue of handling invalid UTF-8 is not important. It is of course completely trivial to handle invalid UTF-8 in Python - it's just not trivial to round trip it. Still, if Python provides bytes interface for the lowest level APIs I don't see a huge problem there - even though a standard library solution would be very nice.
And I certainly don't see a big problem with string literals, just add.encode()?
I have to apologize to you. I was under the wrong impression that UCS-2 uses the entire word range, but it doesn't, the surrogate range is not used making it upwards-compatible with UTF-16. And since v2.2, Python can deal with surrogate pairs in \U escapes and some other places. While you get valid UTF-16 the support is half-baked. E.g. the G clef example is not recognized as a single character by unicode.name on my Windows build, rather as two (invalid) UCS-2 characters. My Linux build works nicely, suggesting it was built with UCS-4 support.
Maybe I'm an idiot, but I'm not so hot for code units. The behavior of len() itself is not that important, but I don't want to think about cutting off code points in the middle while iterating and slicing, it's a much bigger concern to me than round-tripping invalid.
I still don't understand the crux of your argument, really. Are you suggesting that UTF-8 should be used for internal representation? Now that I think about it, the fact that Microsoft chose another route suddenly makes it seem like it might be the cleverer choice;) Still, Java, C# and Qt (the other languages/library I've used when dealing with Unicode) all use UCS-2/UTF-16, so the criticism could well-apply there as well. If Python 3 provides bytes versions of low-level interfaces I don't see what the fuss is about. People who write broken software in Python 3 would still do it in Python 2.
I find it very hard to believe that Python turned U+1D11E into a two-word string when it "does not do UTF-16". No plausable bug in UCS-2 converting would do that, it would either produce an error or a 1-word string.
You should think a bit harder. U+1D11E is more than 2 bytes can encode. I'm not an expert on Python internals but you don't need to be one to make an educated guess how that gets encoded into 4 bytes (two UCS-2 characters). If Python did use UTF-16, it would not have trouble representing the character and it would report the length to be 1, not 2, but it does not do so because UTF-16 is variable-length and hence computationally much more expensive. For that very reason there's no language that I know of that does use UTF-16 to represent Unicode.
Yes you would like to think that. However that is NOT what programmers do, and you are living in fantasy land if you think they will. Just yesterday...
I'm not living in a fantasy land, you're just working with uneducated programmers. Encodings are not rocket science. And you and your programmers will likely have to learn to work with them if you're going to survive in any kind of non-English environment. Do you think Microsoft added wide byte support because they were kind?
Also an anonymous poster points out the Python3.0 forces the argv command line arguments through the default conversion and there is NOTHING the Python program can do about this. This is absolutely one of the worst possible decisions possible! You basically are unable to put an invalid encoding on the command line, and if there is no way to force UTF-8 before this happens, you cannot put anything other that ISO-8859-1 on the command line! So much for being able to make a Python program that can delete or rename a file with invalid UTF-8 in it's name.
ISO-8859-1? I don't think that word means what you think it means. I think the word you're looking for is "ASCII". There are Latin-1 byte sequences that are not valid UTF-8 sequences, so using Latin-1 on the command line does not make you safe in any way.
As I already said, I otherwise concur that the string-only argv is a blunder and that a bytes version should be provided for the all the lowest level APIs.
As I understand a lot of work has been done to provide both string and bytes version for the various filesystem/IO APIs, so I wouldn't say that the Python devs intend to cause "grief for anything that doesn't fit the unicode world-view".
But if there's no way to get a bytes version of argv then yes I'd say it's a genuine problem, especially on POSIX systems.
Again, no. G clef is code point 0x1D11E, outside of BMP (higher than 0xFFFF), which UCS-2 (unlike UTF-16) can't represent. As a result, you get nonsense when you try to use that code point in Python. Which is what I said in my previous post.
How do you handle incorrect UTF-8? You report the error, use 'some other error handling scheme instead of 'strict' for decoding, or write a decoder of your own.
I've read your previous posts. You weren't making any sense back then, and you aren't making any now either. However, for some reason your trolling seems to go well with the mods every time.
It's a fact that the Unicode support in Python is not perfect (see e.g. this post). However, every and any issue you might have with Python 3 internal representation of Unicode strings, you are bound to have with Python 2 as well. The only thing that has changed is that the unicode and str types got replaced with str and bytes types respectively, and that you can't mix the two anymore without explicitely encoding/decoding them. And both of these are good things (TM).
Also, for someone who has supposedly spent so much time investigating Python Unicode support to great depths, it's rather funny that you don't know that Python does not use UTF-16 for internal representation of Unicode strings. It uses either UCS-2 (the default) or UCS-4, which are both fixed-length encodings. Unfortunately, the default one cannot represent characters outside the Basic Multilingual Plane, but hey - neither can say Java.
And finally, your argument that "real Python programs need to handle arbitrary data that is *PROBABLY* UTF-8." is utter rubbish. If you need to handle non-ASCII textual data you either:
need to know the encoding of the data explicitely (say an HTTP header, or just a general convention) OR
need to perform heuristics on the data and try to guess the encoding 0 and then hope for the best
Slashdot Mirror
I'm just a layman, but from what I gather the extra dimensions are supposed to be circular rather than "linear", like the ones we commonly use. The circumference of these circles is very small (Planck length).
The most impressive eye-tracking device I've ever seen is Tobii. It's based on infrared sensors which detect the movement of your eyes. I was pretty much amazed with the accuracy of the device, much better than I thought it would be.
No Rico, not yet.
Please stop. This sort of prejudice has been following OSS developers since forever, but is nothing more than a load of crap. I'm going to say it one more time: we DON'T use emacs, we use vim!
Depends who you call. I hear that Joe the Plumber has some really good rates.
No, they're replacing the obsolete 1980s technology (shuttles) with modern, 1960s technology. It's progress.
Just got back from CeBIT, tried out an eye tracking device made by Tobii. I guess the technology has been around for a while now (the girl at the stand said they've been in business since 2003 I think) but I've never had a chance to try it out myself. Very, very impressive.
Basically you control the mouse pointer with just your eyes. The calibration is dead simple, you just need to look at two corners of your screen and that's it. The accuracy of the device amazed me completely. The sentiment is perhaps best conveyed by my a comment made by a colleague of mine after trying out the device: "dude, let's go to a strip bar. We've just seen a computer you can control with your eyes. What else could impress us... but tits?"
Their main use cases so far are disabled persons, but it's also used by e.g. marketing people to check which parts of the add your eyes focus on mostly etc.
Which browsers make the cut and which don't??
Have the EU set up a software repository. Force MS to modify Windows copies sold in the EU so that they connect to this repository the first time the user clicks the "Internet" icon.
And c'mon, realistically, how difficult it is to choose the browsers? Firefox, Safari, Opera, Chrome. You don't need an exact mathematical formula to figure it out, just use common sense
EU could also use the same mechanism to offer other kinds of software for Windows.
The site will be almost entirely content. It will need to be updated by non-technical staff, specifically uploading PDFs, creating new pages, and applying tags from a set taxonomy. It will need to handle user accounts and control access permissions down to the page level. This doesn't seem to call for much more than a standard CMS.
We do not want to spend a lot of money on a license. We want a system that we can host and for which we can easily outsource work (no vendor lock-in).
So far so good. Joomla might fit the bill (the permissions bit might be problematic depending on your exact needs).
We want a system that we can customize pretty easily; bonus if there is a large community creating extensions.
That's where it starts to get interesting. Customizing Joomla is a pain. The "core" is not designed in a very modular/extensible way, and the quality of the code itself is generally low. Joomla provides nothing which would resemble a framework (think Cake, Symphony, etc) making you re-invent the wheel for every component (or create a framework of your own).
The quality of third-party extensions (or "components" in the parlance) ranges, with some exceptions, from bad to dowright attrocious. To be fair most of them do their job, but customizing them? Forget it. Security-wise, you're lucky if they escape their SQL, forget about XSS or heaven forbid CSRF prevention. Not to mention that they tend to follow the time-honored PHP tradition of "notices are OK".
Also, because of the lack of extensibility in Joomla, components often include so-called "core hacks", which comprise of replacing the original Joomla files with their own version. You can imagine that because of this some components don't play very well with each other, and don't play well with Joomla upgrades at all
Search-engine friendly links are also a problem. Joomla comes with a SEF URL rewriter, but often that doesn't cover all the needs. So you need to install yet another component (openSEF or 404sef), which also tends to step on toes of some other things.
The low cost IMHO is a red herring. I used to do contract work for a small company specialized in customizing Joomla for clients. The process would generally go like this:
By the time the process is finished, the original project has stretched from weeks to months, and the price has gone up from $1-2k to $10k+
The funny thing is, if we developed the CMS from scratch using a proper framework (or better, started by customizing a CMS that utilizes one):
So please, do yourself a favor. Find a decent Web development company that works using a decent framework. I'm a Python fanboy so I'd su
Yet meatspin and goatse links still work. I do not know what the proper and official BSD logo is, but knowing that Slashdot censors it makes me shudder in horror.
Slashdot mods don't get Monty Python references? Dang it, the times they are a-changin...
As someone wrote above, there's a very elegant solution: use a repository, just like Linux distros do. Categorize the apps, and provide a short description along with each one.
Of course, a slight problem is that it's never going to happen.
That's OK, but that's not what I was asking. If the Universe is inherently "holographic" and the uncertainty at the Planck scale - 10^(-34)m in the "real" Universe translates to uncertainty on the scale of 10^(-16)m in "our" world, how would it be possible to perform measurements on the scale of 10^(-21)m in our world, no matter which method you use?
It might be that my memory is failing me and that the actual number is different, but I do remember that we were all amazed that the number was orders of magnitude smaller than the (classical) radius of an electron, which is about 10^(-15)m
I agree that static typing is somewhat more self-documenting, but not keeping your documentation up to date is yet another way to assure a maintainance hell, regardless of your choice of language.
And of course I'm not arguing that you can't have a good test suite with a statically typed language. I'm arguing that following best practices such as writing tests and documenting things renders the ostensible advantages of static type checking redundant. On the other hand, not following best practices also renders these advantages pretty much useless.
Just having your program successfully pass checks for static typing (i.e. that it compiles) provides no hints whether your program actually works. Having a good test suite, on the other hand, goes a long way - especially for projects which you expect to have to maintain.
A positive side-effect of having a good test suite is that it provides type checks as well
Somebody dubbed their financial management and planning software "Hyperion"? Are they aware that Hyperion is the sole satellite in the Solar system with a completely chaoitic orbit?
but the question is moot as you may be pretty close to dead by then...and your kids...
I don't see how his personal relationship with his kids influences this thread, but I still find it commendable if he is close to them.
On the other hand, I find his "talking to the dead" crap rather appaling
(I see that mods got points to burn, so I figured: what the heck?)
The article states that the uncertaintly at the Planck scale at the (hypothetical) border could translate to something like 10^(-16)m scale in "our world"? But some 10 years ago when I was at some research facility near Padua, they had a gravitational wave detector which they claimed could detect movement on the scale of 10^(-21)m so that would suggest we can already make much more precise measurements. How would that be possible?
(Disclaimer if I'm missing something obvious: I'm not a physicist)
Well you almost always use iterators in Python anyway, so yes the str class could do UTF-8 internally and implement an "intelligent" iterator. Slicing would require a bit more work, and generally the whole thing would be somewhat slower but who cares, Python isn't exactly the pinnacle of speed anyways. It's just a matter of priorities I guess.
But why the heck would you want to create constant strings containing UTF-8 errors? The only need I see for creating purposely errorenous UTF-8 is for round tripping existing malformed identifiers (such as filenames), not to introduce new ones! And also, how would you treat \u escapes in byte strings? Always as UTF-8? According to the encoding of the file? Explicit is better than implicit...
I disagree about UTF-8. My native tongue and both of its scripts (Latin and Cyrillyc) use non-ASCII characters, and iteration and slicing pop up fairly often - much more often than invalid UTF-8. I'd really hate it to have to think about code point boundaries while working on them, UCS-2/UTF-32 are much nicer in that regard.
Again, I'm not saying that the issue of handling invalid UTF-8 is not important. It is of course completely trivial to handle invalid UTF-8 in Python - it's just not trivial to round trip it. Still, if Python provides bytes interface for the lowest level APIs I don't see a huge problem there - even though a standard library solution would be very nice.
And I certainly don't see a big problem with string literals, just add .encode()?
I have to apologize to you. I was under the wrong impression that UCS-2 uses the entire word range, but it doesn't, the surrogate range is not used making it upwards-compatible with UTF-16. And since v2.2, Python can deal with surrogate pairs in \U escapes and some other places. While you get valid UTF-16 the support is half-baked. E.g. the G clef example is not recognized as a single character by unicode.name on my Windows build, rather as two (invalid) UCS-2 characters. My Linux build works nicely, suggesting it was built with UCS-4 support.
Maybe I'm an idiot, but I'm not so hot for code units. The behavior of len() itself is not that important, but I don't want to think about cutting off code points in the middle while iterating and slicing, it's a much bigger concern to me than round-tripping invalid .
I still don't understand the crux of your argument, really. Are you suggesting that UTF-8 should be used for internal representation? Now that I think about it, the fact that Microsoft chose another route suddenly makes it seem like it might be the cleverer choice ;) Still, Java, C# and Qt (the other languages/library I've used when dealing with Unicode) all use UCS-2/UTF-16, so the criticism could well-apply there as well. If Python 3 provides bytes versions of low-level interfaces I don't see what the fuss is about. People who write broken software in Python 3 would still do it in Python 2.
I find it very hard to believe that Python turned U+1D11E into a two-word string when it "does not do UTF-16". No plausable bug in UCS-2 converting would do that, it would either produce an error or a 1-word string.
You should think a bit harder. U+1D11E is more than 2 bytes can encode. I'm not an expert on Python internals but you don't need to be one to make an educated guess how that gets encoded into 4 bytes (two UCS-2 characters). If Python did use UTF-16, it would not have trouble representing the character and it would report the length to be 1, not 2, but it does not do so because UTF-16 is variable-length and hence computationally much more expensive. For that very reason there's no language that I know of that does use UTF-16 to represent Unicode.
Yes you would like to think that. However that is NOT what programmers do, and you are living in fantasy land if you think they will. Just yesterday...
I'm not living in a fantasy land, you're just working with uneducated programmers. Encodings are not rocket science. And you and your programmers will likely have to learn to work with them if you're going to survive in any kind of non-English environment. Do you think Microsoft added wide byte support because they were kind?
Also an anonymous poster points out the Python3.0 forces the argv command line arguments through the default conversion and there is NOTHING the Python program can do about this. This is absolutely one of the worst possible decisions possible! You basically are unable to put an invalid encoding on the command line, and if there is no way to force UTF-8 before this happens, you cannot put anything other that ISO-8859-1 on the command line! So much for being able to make a Python program that can delete or rename a file with invalid UTF-8 in it's name.
ISO-8859-1? I don't think that word means what you think it means. I think the word you're looking for is "ASCII". There are Latin-1 byte sequences that are not valid UTF-8 sequences, so using Latin-1 on the command line does not make you safe in any way.
As I already said, I otherwise concur that the string-only argv is a blunder and that a bytes version should be provided for the all the lowest level APIs.
As I understand a lot of work has been done to provide both string and bytes version for the various filesystem/IO APIs, so I wouldn't say that the Python devs intend to cause "grief for anything that doesn't fit the unicode world-view". But if there's no way to get a bytes version of argv then yes I'd say it's a genuine problem, especially on POSIX systems.
Again, no. G clef is code point 0x1D11E, outside of BMP (higher than 0xFFFF), which UCS-2 (unlike UTF-16) can't represent. As a result, you get nonsense when you try to use that code point in Python. Which is what I said in my previous post.
How do you handle incorrect UTF-8? You report the error, use 'some other error handling scheme instead of 'strict' for decoding, or write a decoder of your own.
I've read your previous posts. You weren't making any sense back then, and you aren't making any now either. However, for some reason your trolling seems to go well with the mods every time.
It's a fact that the Unicode support in Python is not perfect (see e.g. this post). However, every and any issue you might have with Python 3 internal representation of Unicode strings, you are bound to have with Python 2 as well. The only thing that has changed is that the unicode and str types got replaced with str and bytes types respectively, and that you can't mix the two anymore without explicitely encoding/decoding them. And both of these are good things (TM).
Also, for someone who has supposedly spent so much time investigating Python Unicode support to great depths, it's rather funny that you don't know that Python does not use UTF-16 for internal representation of Unicode strings. It uses either UCS-2 (the default) or UCS-4, which are both fixed-length encodings. Unfortunately, the default one cannot represent characters outside the Basic Multilingual Plane, but hey - neither can say Java.
And finally, your argument that "real Python programs need to handle arbitrary data that is *PROBABLY* UTF-8." is utter rubbish. If you need to handle non-ASCII textual data you either: