Looks like you need to clean up your computer and online browsing settings! (Unless you meant to post that link following your comment)
That was probably one of the manual-labor spam factories that seem to be sprouting like weeds recently -- they pay people to register on a forum, read the forum, and post comments (with spam links, of course) that make just enough sense to attract real readers' attention.
On the one hand, I guess it means that spam-detecting tech has advanced far enough that it's no longer very profitable to send out machine-generated spam. On the other hand, this makes it harder for us humans to tell the difference. (But then again, xkcd has a point too.)
As long as we're talking test runs, the Chuo Shinkansen hit 581km/h in 2003.
Re:Cross-platform, but not cross-compiling
on
Autotools
·
· Score: 1
Interesting you should mention this; I've had the same problems you describe trying to get CMake to cross-compile, but with autotools, "--target=other-cpu" has generally worked fine in my experience (making it just about the only redeeming feature in that spaghetti mess of shell and m4 code). Admittedly I haven't tried building an entire Linux distribution, so maybe I just happened to choose packages that don't rely on running test programs, but IIRC autotools will explicitly disable the standard runtime tests when cross-compiling.
is that it's got ugly syntax, effectively no cross-compiling support, and less-than-helpful documentation. And its generated Makefiles sometimes miss changes in header files, forcing you to "make clean".
But yeah, it's still a good alternative to autotools.
That's 62 miles, or 100km. I can't recall hearing about a 100km jam in the 11 years I've been here, though I'll grant you a few 50-60km jams pop up on the news most holiday seasons.
We note without surprise, therefore, that the Legislature
of California, in making it unlawful for anyone but a law
enforcement agency to "use an electronic tracking device to
determine the location or movement of a person," specifically
declared "electronic tracking of a person's location without
that person's knowledge violates that person's reasonable
expectation of privacy," and implicitly but necessarily thereby
required a warrant for police use of a GPS, California Penal
Code section 637.7, Stats. 1998 c. 449 (S.B. 1667) 2.
Several other states have enacted legislation imposing civil
and criminal penalties for the use of electronic tracking
devices and expressly requiring exclusion of evidence
produced by such a device unless obtained by the police
acting pursuant to a warrant. See, e.g., Utah Code Ann.
77-23a-4, 77-23a-7, 77-23a-15.5; Minn Stat 626A.37,
626A.35; Fla Stat 934.06, 934.42; S.C. Code Ann 17-30-
140; Okla. Stat, tit 13, 176.6, 177.6; Haw. Rev. Stat
803-42, 803-44.7; 18 Pa. Cons. Stat 5761.
So if you're in one of those states, it looks like the answer is yes, it's illegal to plant a GPS tracker if you're not law enforcement (and sometimes even if you are law enforcement).
(And why does Slashdot still not support Unicode?)
I wouldn't call it a generation "clash" so much as a "progression" from one generation to the next. As one who's been programming for a fair number of years, I certainly advocate knowing the details of what's going on at the lowest levels; if you're not familiar with how caches work, for example, you might have trouble figuring out why a loop over a 2-D array is running so slowly (answer: you have the loops inverted, so every array access is missing the cache). For those who have learned programming in more modern environments, I hope my column has been informative. But at the same time, if your target environment has the capability to take care of all the details for you, I see nothing wrong with taking advantage of that. If your PC can generate new kittens faster than STL kills them off, then by all means, blast those felines to bits. (: After all, that's the whole point of progression in computer technology -- to let the programmer focus more on the high-level problem and less on the low-level nuts and bolts.
Also, just in case it wasn't clear from the column, it was not at all my intent to criticize the original software. There are certainly things that I would have done differently, but in my own playthrough, the game ran nearly flawlessly in its target environment. Creating a complex piece of software like this is no small effort, and I have nothing but respect for Alec (Holowka, the developer) for completing his work to such a high caliber.
From the game's website, screenshots, and hardware requirements it seems possible that this game could be ported to the Wii. The simplistic control scheme (mouse only, keyboard can just be used for starting/exiting game) could easily have it work on pretty much any gamepad for any system. The technical hurdles the dev went through just to get it to the PSP (a platform of much less popularity than several others) suggests he possesses the resolution to get Aquaria on other systems.
Just for the record, this PSP port is totally unofficial -- I did it mainly for the challenge of porting (and because I enjoyed the heck out of the game). That said, judging from the Wii's specs, I don't think a Wii port would be too difficult as long as you don't have to copy textures into GPU RAM for drawing. The Linux port uses SDL and OpenGL, so if there's a functional SDL/GL port for the Wii, that could save a lot of time.
I wasn't the one who posted the story, but I added a Coral Cache redirect for Slashdot referrers after the Wolfire column went live (just in case -- even though we all know Slashdotters never RTFA). People who actually want to clone the repository will presumably know not to use the Coral Cache URL, people who are just browsing shouldn't notice a difference, and hopefully my server will survive the onslaught. (:
Of course things are going to go wrong. They in fact succeeded at their primary objective, which was to run the ion engines for 1,000 hours; everything beyond that is a bonus. If anything, the engineers involved ought to be praised for being able to work around all those problems and get the thing back to Earth.
I understand your point completely, but how about giving the benefit of the doubt for once?
We tried that when they released the slim PS3 without Other OS support ("don't worry, they won't take it away from current PS3s"). Look how that turned out.
Seriously, that may be the best solution. It's what I ended up doing in a similar situation recently, because everything I could find was either 1: too expensive, 2: not cross-environment compatible (Sharepoint), 3: not stable/secure/reliable (many open source projects), and/or 4: difficult to use (just about everything -- in fact, they had used Sharepoint for a while and were desperate for anything else).
People like to talk about the virtues of software reuse, but they rarely mention the downside of accumulating complexity as a single program tries to do more and more -- or of attempting to force users into a single mold in order to limit complexity. Particularly when it comes to content management (and the intricacies of traditional version control systems versus the desire of non-technical users to just Get Things Done), if you consider the running cost of user support, it can sometimes be more efficient to build custom software that does exactly what you need, the way you need it to.
On the flip side, learning from experience (if done properly) provides one with insights as to why a particular method doesn't work, and those insights are often useful in far broader contexts than the particular cases in which they were learned. It's like understanding the concepts of arithmetic as opposed to memorizing multiplication tables: knowing the tables by heart will speed up those specific tasks significantly, but won't handle anything that falls outside their domain. And of course, if you take the learn-from-others method to extremes, you end up with people writing code like:
counter++;// increment counter
because "I was told code should be commented".
(It's also a sad truth that too many of the elderly generation fail to continue learning themselves, and insist that data should be global, identifiers should be inscrutable abbreviations, or whatnot because "that's the way I did it, goshdarnit, so that's the way you'll do it! And get off my lawn!" Which of course leads the younger programmers to not use global data or short identifiers even when they would be useful, because they wouldn't be caught dead coding like an old fart.)
I suppose that's another option, but to my eye it makes the wrong line stand out. It also only works if there's an old line to be commented out in the first place, as opposed to just a new line being added, e.g.:
____//... int a=time(NULL); ____sort(array[i]); printf("%d\n",time(NULL)-a); ____//...
Interesting; I hadn't considered the possibility of allowing one's source code editor to enforce indentation. (Not necessarily disparaging that idea, but I keep it optional, because I've found from lengthy experience that there's never One Way that works for every possible case.) I wonder if that sort of editor was one of the factors in developing Python's syntax? Certainly, if your editor enforces certain indentation rules, then there's not much harm in making use of the information encoded by that indentation.
Hm? Oh, never mind, just mumbling to myself. You're absolutely right, and I don't see how I could have possibly thought otherwise. Please, feel free to go on about your business. (:
That's it? You are that inflexible that you balk at eating cowpies?
Sorry, couldn't resist. (: But you might try studying a bit of history to see how well that "style doesn't matter, so use mine" argument works. (Hint: Style comes from taste, and people's tastes differ.)
It enforces a certain style on everyone who uses it, which decades of style wars (centuries, if you look at human languages) say is a Bad Idea.
Just one example: When I want to try something out in a routine -- perhaps for debugging, perhaps to experiment with an alternate algorithm or what have you -- I frequently outdent the code so that its temporary nature is obvious: (pretend the underscores are spaces, because Slashcode seems to eat leading whitespace)
I realize I'm coming in way late to this party, but why is everyone up in arms about this particular change? (Aside from the obvious "I'm stuck in my ways, get off my lawn" reason.) Outside of special cases like file-backed memory mappings, when is it actually useful to know the number of binary kilobytes/megabytes/gigabytes used by a file, as opposed to decimal units? I'll agree those binary units were useful back when the ratio of filesystem size to block size was small, say 10^3:1 (I remember carefully watching free cluster counts on my DOS floppies, and being grateful when 1.2MB floppies offered 1-sector instead of 2-sector clusters). But on modern systems, that ratio is more like 10^7 or 10^8:1, and unless you have OCD and absolutely have to know how every single filesystem block is being used, there's really no benefit to counting in blocks over any other unit. So why not let old hacks pass into history and start counting the way every other field does?
I haven't heard of that particular problem, but I should point out that nVidia does in fact accept bug reports (on Linux, just run nvidia-bug-report.sh and it'll tell you where to mail your report), and I have actual experience with reporting a bug (nvidia_drv crashed X when switching to another virtual console while an OpenGL window was minimized) and having it fixed.
Slashdot Mirror
Change != bad
I absolutely agree. It's just that this change == bad.
(Will that <i></i> show up in the final comment? It doesn't in preview...)
Barbie dress up games
Looks like you need to clean up your computer and online browsing settings! (Unless you meant to post that link following your comment)
That was probably one of the manual-labor spam factories that seem to be sprouting like weeds recently -- they pay people to register on a forum, read the forum, and post comments (with spam links, of course) that make just enough sense to attract real readers' attention.
On the one hand, I guess it means that spam-detecting tech has advanced far enough that it's no longer very profitable to send out machine-generated spam. On the other hand, this makes it harder for us humans to tell the difference. (But then again, xkcd has a point too.)
Just for starters:
http://hg.icculus.org/icculus/aquaria (official repository, with post-Humble Bundle patches from several people)
http://bitbucket.org/_Agent/aquaria
http://achurch.org/cgi-bin/hg/aquaria
(Not to say the others aren't undergoing development as well; Aquaria is just the only one of those four that really captured my interest.)
Append "&nfpr=1" to the search URL. If you use keyworded bookmarks in Mozilla: http://www.google.com/search?q=%s&nfpr=1
As long as we're talking test runs, the Chuo Shinkansen hit 581km/h in 2003.
Interesting you should mention this; I've had the same problems you describe trying to get CMake to cross-compile, but with autotools, "--target=other-cpu" has generally worked fine in my experience (making it just about the only redeeming feature in that spaghetti mess of shell and m4 code). Admittedly I haven't tried building an entire Linux distribution, so maybe I just happened to choose packages that don't rely on running test programs, but IIRC autotools will explicitly disable the standard runtime tests when cross-compiling.
is that it's got ugly syntax, effectively no cross-compiling support, and less-than-helpful documentation. And its generated Makefiles sometimes miss changes in header files, forcing you to "make clean".
But yeah, it's still a good alternative to autotools.
That's 62 miles, or 100km. I can't recall hearing about a 100km jam in the 11 years I've been here, though I'll grant you a few 50-60km jams pop up on the news most holiday seasons.
From TFOpinion (page 33):
We note without surprise, therefore, that the Legislature of California, in making it unlawful for anyone but a law enforcement agency to "use an electronic tracking device to determine the location or movement of a person," specifically declared "electronic tracking of a person's location without that person's knowledge violates that person's reasonable expectation of privacy," and implicitly but necessarily thereby required a warrant for police use of a GPS, California Penal Code section 637.7, Stats. 1998 c. 449 (S.B. 1667) 2. Several other states have enacted legislation imposing civil and criminal penalties for the use of electronic tracking devices and expressly requiring exclusion of evidence produced by such a device unless obtained by the police acting pursuant to a warrant. See, e.g., Utah Code Ann. 77-23a-4, 77-23a-7, 77-23a-15.5; Minn Stat 626A.37, 626A.35; Fla Stat 934.06, 934.42; S.C. Code Ann 17-30- 140; Okla. Stat, tit 13, 176.6, 177.6; Haw. Rev. Stat 803-42, 803-44.7; 18 Pa. Cons. Stat 5761.
So if you're in one of those states, it looks like the answer is yes, it's illegal to plant a GPS tracker if you're not law enforcement (and sometimes even if you are law enforcement).
(And why does Slashdot still not support Unicode?)
It's the beer glasses set on top of it that make the ring.
I wouldn't call it a generation "clash" so much as a "progression" from one generation to the next. As one who's been programming for a fair number of years, I certainly advocate knowing the details of what's going on at the lowest levels; if you're not familiar with how caches work, for example, you might have trouble figuring out why a loop over a 2-D array is running so slowly (answer: you have the loops inverted, so every array access is missing the cache). For those who have learned programming in more modern environments, I hope my column has been informative. But at the same time, if your target environment has the capability to take care of all the details for you, I see nothing wrong with taking advantage of that. If your PC can generate new kittens faster than STL kills them off, then by all means, blast those felines to bits. (: After all, that's the whole point of progression in computer technology -- to let the programmer focus more on the high-level problem and less on the low-level nuts and bolts.
Also, just in case it wasn't clear from the column, it was not at all my intent to criticize the original software. There are certainly things that I would have done differently, but in my own playthrough, the game ran nearly flawlessly in its target environment. Creating a complex piece of software like this is no small effort, and I have nothing but respect for Alec (Holowka, the developer) for completing his work to such a high caliber.
From the game's website, screenshots, and hardware requirements it seems possible that this game could be ported to the Wii. The simplistic control scheme (mouse only, keyboard can just be used for starting/exiting game) could easily have it work on pretty much any gamepad for any system. The technical hurdles the dev went through just to get it to the PSP (a platform of much less popularity than several others) suggests he possesses the resolution to get Aquaria on other systems.
Just for the record, this PSP port is totally unofficial -- I did it mainly for the challenge of porting (and because I enjoyed the heck out of the game). That said, judging from the Wii's specs, I don't think a Wii port would be too difficult as long as you don't have to copy textures into GPU RAM for drawing. The Linux port uses SDL and OpenGL, so if there's a functional SDL/GL port for the Wii, that could save a lot of time.
I wasn't the one who posted the story, but I added a Coral Cache redirect for Slashdot referrers after the Wolfire column went live (just in case -- even though we all know Slashdotters never RTFA). People who actually want to clone the repository will presumably know not to use the Coral Cache URL, people who are just browsing shouldn't notice a difference, and hopefully my server will survive the onslaught. (:
Of course things are going to go wrong. They in fact succeeded at their primary objective, which was to run the ion engines for 1,000 hours; everything beyond that is a bonus. If anything, the engineers involved ought to be praised for being able to work around all those problems and get the thing back to Earth.
I understand your point completely, but how about giving the benefit of the doubt for once?
We tried that when they released the slim PS3 without Other OS support ("don't worry, they won't take it away from current PS3s"). Look how that turned out.
Seriously, that may be the best solution. It's what I ended up doing in a similar situation recently, because everything I could find was either 1: too expensive, 2: not cross-environment compatible (Sharepoint), 3: not stable/secure/reliable (many open source projects), and/or 4: difficult to use (just about everything -- in fact, they had used Sharepoint for a while and were desperate for anything else).
People like to talk about the virtues of software reuse, but they rarely mention the downside of accumulating complexity as a single program tries to do more and more -- or of attempting to force users into a single mold in order to limit complexity. Particularly when it comes to content management (and the intricacies of traditional version control systems versus the desire of non-technical users to just Get Things Done), if you consider the running cost of user support, it can sometimes be more efficient to build custom software that does exactly what you need, the way you need it to.
Bleah. That was embarrassing. (Though maybe it indicates why I'm good at programming -- I tend to read things literally...)
On the flip side, learning from experience (if done properly) provides one with insights as to why a particular method doesn't work, and those insights are often useful in far broader contexts than the particular cases in which they were learned. It's like understanding the concepts of arithmetic as opposed to memorizing multiplication tables: knowing the tables by heart will speed up those specific tasks significantly, but won't handle anything that falls outside their domain. And of course, if you take the learn-from-others method to extremes, you end up with people writing code like:
because "I was told code should be commented".
(It's also a sad truth that too many of the elderly generation fail to continue learning themselves, and insist that data should be global, identifiers should be inscrutable abbreviations, or whatnot because "that's the way I did it, goshdarnit, so that's the way you'll do it! And get off my lawn!" Which of course leads the younger programmers to not use global data or short identifiers even when they would be useful, because they wouldn't be caught dead coding like an old fart.)
I suppose that's another option, but to my eye it makes the wrong line stand out. It also only works if there's an old line to be commented out in the first place, as opposed to just a new line being added, e.g.:
Thanks for the suggestion, though.
Interesting; I hadn't considered the possibility of allowing one's source code editor to enforce indentation. (Not necessarily disparaging that idea, but I keep it optional, because I've found from lengthy experience that there's never One Way that works for every possible case.) I wonder if that sort of editor was one of the factors in developing Python's syntax? Certainly, if your editor enforces certain indentation rules, then there's not much harm in making use of the information encoded by that indentation.
Ah, the classic case of the brainwashed devotee.
Hm? Oh, never mind, just mumbling to myself. You're absolutely right, and I don't see how I could have possibly thought otherwise. Please, feel free to go on about your business. (:
That's it? You are that inflexible that you balk at eating cowpies?
Sorry, couldn't resist. (: But you might try studying a bit of history to see how well that "style doesn't matter, so use mine" argument works. (Hint: Style comes from taste, and people's tastes differ.)
So why is it a moronic idea?
It enforces a certain style on everyone who uses it, which decades of style wars (centuries, if you look at human languages) say is a Bad Idea.
Just one example: When I want to try something out in a routine -- perhaps for debugging, perhaps to experiment with an alternate algorithm or what have you -- I frequently outdent the code so that its temporary nature is obvious: (pretend the underscores are spaces, because Slashcode seems to eat leading whitespace)
Python won't let me do that, which I find to be a significant source of frustration.
I realize I'm coming in way late to this party, but why is everyone up in arms about this particular change? (Aside from the obvious "I'm stuck in my ways, get off my lawn" reason.) Outside of special cases like file-backed memory mappings, when is it actually useful to know the number of binary kilobytes/megabytes/gigabytes used by a file, as opposed to decimal units? I'll agree those binary units were useful back when the ratio of filesystem size to block size was small, say 10^3:1 (I remember carefully watching free cluster counts on my DOS floppies, and being grateful when 1.2MB floppies offered 1-sector instead of 2-sector clusters). But on modern systems, that ratio is more like 10^7 or 10^8:1, and unless you have OCD and absolutely have to know how every single filesystem block is being used, there's really no benefit to counting in blocks over any other unit. So why not let old hacks pass into history and start counting the way every other field does?
I haven't heard of that particular problem, but I should point out that nVidia does in fact accept bug reports (on Linux, just run nvidia-bug-report.sh and it'll tell you where to mail your report), and I have actual experience with reporting a bug (nvidia_drv crashed X when switching to another virtual console while an OpenGL window was minimized) and having it fixed.