OMG! Like there aren't already thousands of gmail invites floating around these days.
You do understand how exponential growth works, and how it applies to a finite population, right?
Anyway, personally I'd like to see some form of RSS crawling which compares the texts of various feeds with the texts in the browser history (probably using a Bayesian method), and uses that to recommend other articles the user might like.
That's the TV series which I referred to. Oh, and earlier I forgot to mention that it's also been an off-broadway rock opera musical, but IIRC, audiences "didn't get it" so it was cancelled after a fairly short run. ("Don't Panic," a biography of Douglas Adams, has more information about that. I had rented it at a library many years ago and have been unable to find a copy of my own since, though, so I'm probably remembering incorrectly.)
Yes, I'm sure. This is standard box-model stuff. Again, try this example, more explicitly spelled out this time: (and edited to try to get past the lameness filter... argh)
<div style="float:right;width;15em;">blahblah dabba blahblah dabba quuz quuz quux qiix blah blah boosh foop</div> <div style="background:red;">Contrary to popular belief, Lorem Ipsum is not simply random text. It has roots in a piece of classical Latin literature from 45 BC, making it over 2000 years old. Richard McClintock, a Latin professor at Hampden-Sydney College in Virginia, looked up one of the more obscure Latin words, consectetur, from a Lorem Ipsum passage, and going through the cites of the word in classical literature, discovered the undoubtable source. Lorem Ipsum comes from sections 1.10.32 and 1.10.33 of "de Finibus Bonorum et Malorum" (The Extremes of Good and Evil) by Cicero, written in 45 BC. This book is a treatise on the theory of ethics, very popular during the Renaissance. The first line of Lorem Ipsum, "Lorem ipsum dolor sit amet..", comes from a line in section 1.10.32.
The standard chunk of Lorem Ipsum used since the 1500s is reproduced below for those interested. Sections 1.10.32 and 1.10.33 from "de Finibus Bonorum et Malorum" by Cicero are also reproduced in their exact original form, accompanied by English versions from the 1914 translation by H. Rackham.</div>
In the standard CSS box model, the meta-lorem-ipsum rom the second div will wrap around the garbage from the first div, but the red background from the second div will go behind the first div.
However, in current versions of Mozilla, if you add an image background with background-attach:fixed to the second div, the meta-lorem-ipsum will still continue to wrap around where the first div's content should be, but the second div's background will paint over the "blah"s. This is obviously a Mozilla bug.
No, that's not what's supposed to happen. They're not using absolute positioning.
In Mozilla, the content of the second div still wraps around the first div's box correctly, but the background paints over the first div. This also only happens if the background-attach is set to fixed.
<div style="float:right">(lots of content here)</div> <div style="background-attach:fixed">(lots of content here)</div>
In that case, the floated div is not a child of the background-attach:fixed div, but their boxes overlap. In Mozilla, the background of the second one appears in front of the floated one.
I disagree. Safari's CSS support is not second to Mozilla's; Safari implements quite a few things which Mozilla doesn't (for example, text-shadow), while I don't know of anything which Mozilla implements which Safari doesn't. Plus, as I posted elsewhere in this thread, Mozilla has a few bugs with background-attach:fixed (though at least it supports it, unlike IE which only supports it on BODY).
I've found a few interesting bugs with Mozilla's CSS as well. For example, if you have a floated div overlapping a nonfloated div with background-attach:fixed, then the floated div will go underneath the nonfloated one's background (though the contents of the nonfloated div will still wrap around the floated div).
The workaround is to put a z-index:100 or whatever on the floated div, which is also technically a CSS spec violation (z-index only applies to absolutely-positioned elements), but at least that doesn't affect sane browsers (like Safari).
It was Hitchhiker's Guide to the Galaxy, which was a radio show, a book, and a TV series, but not a movie.
Also, one hash maps to infinitely many unique items. Read up on the pigeonhole principle. The short form is that there are only 2^128 md5 hashes, so if there are more than 2^128 things which can be hashed (and there are) then more than one of those will map onto the same md5 hash. Granted, at least one of the passwords will have to be longer than 16 bytes and it'll be likely to have non-printable or high-ASCII/UTF-8/whatever garbage in it, but it's still possible.
(And, the converse is that no matter how long your password is, there'll always be a 16-character string which is equivalent to it.)
That doesn't affect the menu bar, and it doesn't change other UI elements' sizes like scrollbars/etc. You can use TinkerTool to change the menu bar font but that still won't change the menu bar size.
Most of the Apple UI elements are fixed-size pixel images. They're very pretty pixel images, but they're actually less flexible than the UI elements in Win2K and earlier (which were drawn using GDI calls IIRC, and certainly weren't pre-rolled bitmaps).
I know that's pretty easy with MacOS X since icons and so on are designed to size proportionately.
Unfortunately, that's a myth. OSX does not use vector graphics for the UI itself, and the various UI elements are definitely pixel-based, even icons they're provided in a number of resolutions all the way up to 128x128, giving them the illusion of being scalable, which can be used for some cute tricks like having an icon which actually changes to different images based on how large it is. But icons are basically just MIPmapped polygons, and that's as close as anything in the OSX UI gets to DPI-independence.
Also, there's no built-in way to change the system font sizes, and using things like TinkerTool to do it can mess things up (since pretty much all of the UI elements are fixed pixel-size still).
To make matters worse, for the few things which are DPI-aware (such as viewing PDFs in Preview.app, and for display-oriented font sizing and so on), there's no way to actually specify your display's DPI OSX insists that all monitors are 72dpi (the old Mac standard) even though pretty much every Apple display sold today is around 100dpi (the only exception being the 14" iBook which is still around 72dpi), so when it tries to display things at "actual size" they're actually shrunk down quite a bit.
With the way that Cocoa works, they could conceivably make the UI truly DPI-independent in the future, but AFAICT Carbon is a lost cause.
I dunno, I've had several jobs where I had to keep a high-demand site running on the processor equivalent of a 486/66 or thereabouts. (Legacy systems at a university which had icky, proprietary nonportable binary formats, for example.)
No matter how clean its generated code is, it still doesn't help when most of its users have no idea what semantic markup is or how to make flexible page sizes. It might make it easier to do do CSS and HTML editing, but it still gives web designers plenty of rope to hang the users with (and makes it even easier in some ways, like with using absolute positioning and pixel-based sizing and so on).
1. My complaint was that the programmer reimplemented the grep tool in the other languages the long way around, while in sh he simply called 'grep' externally; for the purposes of using a scripting environment, calling grep externally is perfectly fine, it's just that he could have done that for the other languages as well (since he wasn't actually doing anything with grep's output aside from shunting it to stdout)
2. I realize that bash has been PORTED to basically everything, but that still doesn't help when you have to run an existing bash script on a system where you don't have root access or otherwise are not able to cleanly install bash for the purpose of running said script; for example, I seem to always end up doing work where I have to do some quick-and-dirty maintenance job on an old legacy system where there's no compiler and just the bare minimum vendor-supplied tools, and that's why I try to refrain from using bashisms in my own scripts
I overlooked that bit. But I didn't notice any bashisms in their code, and it's rather surprising how many bashless systems I've had to deploy existing scripts on (requiring some porting in many cases).
My point was that he allowed for external tool execution in sh but not in the other languages, and tclsh supports the grep commandline tool just as directly as sh does. So, the tester either should have allowed external process execution in all languages, or in no languages.
Really, "implementing grep" is such a useless test of a scripting language. Using the results of the grep is what's important.
On the subject of syntactic indentation, there is one very specific place where Python's syntactic indentation can easily burn you, and that place is Slashdot. Or any web-based forum which makes formatting a simple chunk of text difficult, for that matter.
One time a few years ago on some webboard I was debating with someone about the merits about syntactic formatting and so on, and he whipped out the usual strawman about "well, which is more understandable, this or this?" and of course, the (whatever the other language was) version would still run just fine (and the formatting could be easily recovered by anyone who cared to), while the Python version was totally worthless specifically because even a human couldn't recover the control structures without the formatting!
Decent code editors like Emacs and XCode and so on make the indentation easy to maintain, and easy to recover on most languages. But there is no way in hell that you can automatically recover the formatting on a language where the formatting itself is *part* of the language.
Anyway, yeah, 'use strict' (or its equivalent) is a must. Tcl enforces that by default (is it obvious that I have a thing for Tcl yet?), and it's easy enough to do in PHP as well (with ErrorReporting(E_ALL) or whatever). I have no idea why any programmer in their right mind would deploy a web application which makes assumptions about the default values of variables; many times I've been working on other peoples' PHP scripts which played fast and loose with global variables and automatic registration and so on and they were so full of security holes and REALLY difficult to debug. Like, it's happened way too often that I've been unable to figure out why a variable wasn't getting set only to discover that it was misspelled in its assignment or something.
Slashdot Mirror
You do understand how exponential growth works, and how it applies to a finite population, right?
Anyway, personally I'd like to see some form of RSS crawling which compares the texts of various feeds with the texts in the browser history (probably using a Bayesian method), and uses that to recommend other articles the user might like.
However, in current versions of Mozilla, if you add an image background with background-attach:fixed to the second div, the meta-lorem-ipsum will still continue to wrap around where the first div's content should be, but the second div's background will paint over the "blah"s. This is obviously a Mozilla bug.
If that's the case, then md5 is a really bad hashing algorithm.
Remember when they released Solaris 2.7 as Solaris 7 instead? Nothing new here.
In Mozilla, the content of the second div still wraps around the first div's box correctly, but the background paints over the first div. This also only happens if the background-attach is set to fixed.
Safari does border collapsing too.
No, but some less-than-16-character passwords will fill in those gaps. :)
Well, yeah, but the original poster was saying that he'd seen it in a movie, thus demolishing what little geek cred he may or may not have had. :)
Because that's not using text-shadow, it's using positioning hacks. text-shadow is way more capable and flexible than that.
I disagree. Safari's CSS support is not second to Mozilla's; Safari implements quite a few things which Mozilla doesn't (for example, text-shadow), while I don't know of anything which Mozilla implements which Safari doesn't. Plus, as I posted elsewhere in this thread, Mozilla has a few bugs with background-attach:fixed (though at least it supports it, unlike IE which only supports it on BODY).
The workaround is to put a z-index:100 or whatever on the floated div, which is also technically a CSS spec violation (z-index only applies to absolutely-positioned elements), but at least that doesn't affect sane browsers (like Safari).
Also, one hash maps to infinitely many unique items. Read up on the pigeonhole principle. The short form is that there are only 2^128 md5 hashes, so if there are more than 2^128 things which can be hashed (and there are) then more than one of those will map onto the same md5 hash. Granted, at least one of the passwords will have to be longer than 16 bytes and it'll be likely to have non-printable or high-ASCII/UTF-8/whatever garbage in it, but it's still possible.
(And, the converse is that no matter how long your password is, there'll always be a 16-character string which is equivalent to it.)
In any case, Win2k and earlier used GDI calls for most things, aside from the window decorations which were stored in a truetype font anyway. :)
Most of the Apple UI elements are fixed-size pixel images. They're very pretty pixel images, but they're actually less flexible than the UI elements in Win2K and earlier (which were drawn using GDI calls IIRC, and certainly weren't pre-rolled bitmaps).
Also, there's no built-in way to change the system font sizes, and using things like TinkerTool to do it can mess things up (since pretty much all of the UI elements are fixed pixel-size still).
To make matters worse, for the few things which are DPI-aware (such as viewing PDFs in Preview.app, and for display-oriented font sizing and so on), there's no way to actually specify your display's DPI OSX insists that all monitors are 72dpi (the old Mac standard) even though pretty much every Apple display sold today is around 100dpi (the only exception being the 14" iBook which is still around 72dpi), so when it tries to display things at "actual size" they're actually shrunk down quite a bit.
With the way that Cocoa works, they could conceivably make the UI truly DPI-independent in the future, but AFAICT Carbon is a lost cause.
I dunno, I've had several jobs where I had to keep a high-demand site running on the processor equivalent of a 486/66 or thereabouts. (Legacy systems at a university which had icky, proprietary nonportable binary formats, for example.)
No matter how clean its generated code is, it still doesn't help when most of its users have no idea what semantic markup is or how to make flexible page sizes. It might make it easier to do do CSS and HTML editing, but it still gives web designers plenty of rope to hang the users with (and makes it even easier in some ways, like with using absolute positioning and pixel-based sizing and so on).
1. My complaint was that the programmer reimplemented the grep tool in the other languages the long way around, while in sh he simply called 'grep' externally; for the purposes of using a scripting environment, calling grep externally is perfectly fine, it's just that he could have done that for the other languages as well (since he wasn't actually doing anything with grep's output aside from shunting it to stdout)
2. I realize that bash has been PORTED to basically everything, but that still doesn't help when you have to run an existing bash script on a system where you don't have root access or otherwise are not able to cleanly install bash for the purpose of running said script; for example, I seem to always end up doing work where I have to do some quick-and-dirty maintenance job on an old legacy system where there's no compiler and just the bare minimum vendor-supplied tools, and that's why I try to refrain from using bashisms in my own scripts
I overlooked that bit. But I didn't notice any bashisms in their code, and it's rather surprising how many bashless systems I've had to deploy existing scripts on (requiring some porting in many cases).
Really, "implementing grep" is such a useless test of a scripting language. Using the results of the grep is what's important.
That's bash code, not sh.
One time a few years ago on some webboard I was debating with someone about the merits about syntactic formatting and so on, and he whipped out the usual strawman about "well, which is more understandable, this or this?" and of course, the (whatever the other language was) version would still run just fine (and the formatting could be easily recovered by anyone who cared to), while the Python version was totally worthless specifically because even a human couldn't recover the control structures without the formatting!
Decent code editors like Emacs and XCode and so on make the indentation easy to maintain, and easy to recover on most languages. But there is no way in hell that you can automatically recover the formatting on a language where the formatting itself is *part* of the language.
Anyway, yeah, 'use strict' (or its equivalent) is a must. Tcl enforces that by default (is it obvious that I have a thing for Tcl yet?), and it's easy enough to do in PHP as well (with ErrorReporting(E_ALL) or whatever). I have no idea why any programmer in their right mind would deploy a web application which makes assumptions about the default values of variables; many times I've been working on other peoples' PHP scripts which played fast and loose with global variables and automatic registration and so on and they were so full of security holes and REALLY difficult to debug. Like, it's happened way too often that I've been unable to figure out why a variable wasn't getting set only to discover that it was misspelled in its assignment or something.
Isn't the rate graph normalized to the peak value?