Updated: New version (this one runs :) - even for Mac Parallels folks). Sorry about that - improper manifest file with VC Express 2005 (or something); I'll have to look at exactly what the issue was later. The links in the post have also been corrected.
I was visting a friend last week, to see some of the VERY interesting new work he's doing, but, as an aside (nothing to do with any real project), he had just been playing around with OpenGL on his manly MacTel box. He wrote this fun little particle system thing that treated every pixel in an image as a particle... it was very fun, but only ran on the Mac.
So (being me) I did a version for Windows - no OpenGL, DirectX, or other (though those would help), of course, just code. Its not very optimal (its only 9kb compressed) - but kinda fun to play with. You can download it here. Click and drag in the image to see it work; press the 'o' key to load a new image.
Remember, its just a little app I compiled on my computer: there's been no QA, and it probably has a bug or two - other than that, its harmless :)
Finally uploaded all the family pictures of our Disney Trip. A few little sneaks and peeks... :)Its really a bit more of a pain than it should be - its easy to publish galleries; tougher to make sites for this type of thing. Somebody should do something (or recommend something) on that...
I finally decided to install .NET 3.0 so I could play around with some XBAP demos. They're interesting (for example, from the New York Times). It still seems like the primary value of "RIA" applications is (a) ease of deployment, and (b) state transitions, i.e. animations (note: WPF required link).
Whether its Flash, AJAX, WPF, OS X, etc. - haven't really seen any new interaction paradigms (that aren't fun, but useless) - it just looks prettier; you could have presented the same utility with the original Mac OS user interface, more or less. That's not the case with the transition from DOS/command line apps to GUIs.
Heck look at the Firefox 2.0 UI...
That's not a bad thing or anything, but a little surprising I guess - its been more than 20 years (at least 15, if you want to give it a few years). Evolution, not revolution...
Updated: Reminder - some "older tech" examples of richness (in Flash, DHTML, Java); some adding value - some not so much :) ... And speaking of useless but fun - here's a image/photo "sand" simulation in plain old C code :)
The Conference that is... Looks like Will did well (no surprise :)). As discussed...
I didn't see this at the time article was published (10/11) - but my timing was good (10/3) :)
So I was playing around with some of the new features in JavaScript 1.7 - not a lot of discussion about them in the Firefox 2.0/IE 7 release brouhaha, but definitely really useful improvements there for developers.
In particular, co-routines (in the form of the "yield" operator) are the key big improvement (IMHO). The rest is mostly syntactic sugar - and in fact, most of those are indeed enabled by co-routines (which they label as "Generators").
I have to admit, though, to being a little disappointed with trying to use them in practice, for "programming in the large" with JS type things. As always, I might be missing something - but what I'm finding is that most of the time I don't want to necessarily yield to just the calling function; I want to yield waaaay up the stack. I think what I'm really looking for is a "resumable" exception of sorts- where I can yield all the way up somewhere, take some action, and then continue execution back to the yield - ALMOST there with JS 1.7 generators - but the implementation seems to be more about keeping up with Python superficially... ah, well.
Still - it does simplify A LOT of real world design patterns, so I can't complain. No denying that co-routines are a powerful programming paradigm, which I first saw in Ruby, then Python, and now JavaScript. There are even a few attempts to bring them to C - but I guess the interesting question will be how much browser adoption (in a fragmented market) of these features affects their real world utility and use.
Adobe has much less of that particular adoption problem - being a single vendor monopoly for core technology has its advantages.
Probably more than a few folk at Microsoft (among other places :P) were laughing their @$$es off last week. If you haven't heard about the debate - it basically boils down to this: Although Firefox is "free" (distribution and source code use/re-use), the name and artwork are trademarks of the Mozilla Foundation.
So they (the Foundation) have made a few pointed requests to Linux distros like Debian, with regard to how they may distribute work product from the Mozilla Foundation, particularly with regards to their key successful product, Firefox.
The problems are basically this, as (I interpret) the Mozilla Foundation sees it: (1) All distributions using their name must include exactly their artwork and logos and (2) they wish to review and approve "substantive" patches for distributions using their trademarked names. The rationale is pretty straight-forward: consumers have come to know and recognize the Firefox brand, and the Mozilla Foundation has invested in building that brand - and they don't want to see its value eroded by confusing imagery or shoddy product.
Straight from the horse's mouth, I'd have to agree these are fine and reasonable things when you're running a business. And now that Firefox is generating real revenue and market share, apparently many in the open source movement seem to be unhappy their new web browser overlords.
They should remember though, money's important - and it may not flow if its too far from "core" Firefox.
So the counter plan is to branch Firefox and ship "IceWeasel" (fire=ice, fox=weasel) - of which there are two variants already: Debian and GNU. The whole point, they argue, of "free software" is to enable EXACTLY the type of customization of products the Mozilla Foundation is arguing to prevent under the Firefox brand. So they're going to fragment in response...
Much better.
Really.
What's funny is both sides aren't wrong - and a good example of where being right (on either side) is to the detriment of both. Maybe they should try a brand family strategy to compromise - something like "Firefox Prime" (but, uh, better... :P) for the "official" Mozilla distributions, and "Firefox Debian" for branches/changes... ah, whatever.
Let's hear one for those young whipper snappers "stickin' it to the man!"... oh wait... who was who again?
Coming soon. Robust IM, no "software" required.
Speaking of content runtimes and Rich Internet Applications - the Boxely Community Technology Preview is available for download. Its used by a bevy of AOL applications and will be more broadly available for use by third party developers, for plug-ins to AOL applications, as well as "other" things.
Well, I'm back, and had a great time with the family. We stayed on the Disney World premises - which harkens to how Casinos have no windows or clocks - a completely immersive experience. Those Disney theme park guys really know how to make you happy about spending, and they manage every detail - about my largest complaint is that the 1/32nd scale 3D princess crown chocolate replica at our Cinderella dinner was made of dark chocolate.
I prefer milk chocolate.
In other news, Mark Cuban did a funny bit why GooTube is going be a legal nightmare - but I still think its possible that DRM, at least as currently envisioned, is NOT the "end state" solution for content creators.
And, this is also a bit old, but J2ME's evolution is interesting to watch in the distributed application runtime game. They've had some success on devices, tons and tons for server development and none to really speak of on the desktop (yet). Nevertheless, they continue to flog the "write once/run anywhere" banner with this news with Lazlo Systems about "Orbit" and application portability. Like Microsoft, Sun is attacking this market from a developer perspective - and as application execution context boundaries blur, that may become more effective in the marketplace. I still think they're a dark horse vs. the "top 3" in this space, but it is still an emergent technology space, so who knows.
We're off to Disney World! We'll be gone for a week or so, so... see you then :)
The kids have been packed for a week and had their suitcases by the door - just in case we have a vacation emergency.
Soooooo fun!
WWWWoooooowwww.
I guess they can afford it, and its nice to extend the brand (if you're hunting for some rationalization - which we all are :)), but still - it's a bit nutsy (and they're potentially risking more than the invested cash).
Well, no matter how you slice it , its a bold move in the citizen video space - and it should be interesting to see what Google make of it, if nothing else. In particular, if they can stick to their new mantra ("features, not products") seriously with this acquisition - well, could be very interesting. All in all, I'd say: crazy deal, but probably not a bad idea for the involved parties.
Let the good times roll - :) remember this? Dot-com-2.0 craz-azee-zaniness (and some background).
Yesterday, Google publicly released their source code search tool - which is pretty nice. I'd not like to be koders or krugle just now (hey, this is just like when Microsoft used to release products, back in the day!)
When people wonder what possible chink there could be in Google's armor: this is it. Specialization of presentation - of interface - tends to win over time. This is at once less of a chink and more of chink than I think people generally think (I think :)).
That is, although I do believe in the power of specialization over consolidation, from a UI perspective, that doesn't necessarily speak to economies of scale, from an execution perspective - it only addresses user fickleness and opportunities for behaviour disruptions.
On a minor note, I'd wish they'd be a *tiny* bit more consistent with the root URLs for their products - as a user, its annoying. For example, their code search product is at http://www.google.com/codesearch, while you reach their blog search at http://blogsearch.google.com or http://www.google.com/blogsearch. For a company that pays attention to the little details of experience, you'd have hoped they'd have codified that at least. Updated: I take it back (I did say that Google cares about details :)) - http://codesearch.google.com works now; it didn't until well after my post.
You should check out Light AIM (*ahem* LAIM) and AOL OpenRide.
Very different product, uh, vectors, for lack of a better term, but both are interesting because they're DIFFERENT (yay!). Good to see some products that are not just cloning the marketplace from AOL... whether they're great or just flops I guess the market will tell us, but certainly they're not attempts to produce "good enough".
Updated: Some nice profile results on GCC from Eric O'Laughlen. Full optimizations on I think is the important case.Continued from Part 2. Inspired by this post from Google.
I think I'll do a full article on this shortly - covering the full range of mathematical operations, because this is fairly simple but important (for example). Oddly, most of the default answers seem to be 64-bit math (Microsoft and Linus/Linux) or assembly (everybody else). I'm not sure why - perhaps I'm missing something? But first, some performance results:
--------- Testing Addition
--------- Math requiring no overflow detection, but still testing for it
-------------------- This is for speed (overhead)
Test Simple........... total: 100000001 Time = 651.314 ms (1)
Test ASM Safe......... total: 100000001 Time = 1799.14 ms (2)
Test MS Safe.......... total: 100000001 Time = 1205.74 ms (3)
Test ASM SETTO Safe... total: 100000001 Time = 706.609 ms (4)
Test Sree C Safe...... total: 100000001 Time = 694.44 ms (5)
Key:
(1) is a+b, just for a baseline
(2) is the common Assembly solution I've seen a few places on the web
(3) is the Microsoft SafeInt class
(4) is the assembly recommended by Eric, following Mike
(5) is my C version (below)
The basic idea is really simple, and pretty obvious for the unsigned integer case, as everyone points out. If you add two positive numbers, and the result is smaller than either number, your addition overflowed.
It gets a little more complicated for the signed case, but not really THAT much more complicated. Basically, if you want to test if the result of an addition is supposed to be greater or less than a specific number, you only have to look at the sign of the OTHER number. That is, if you're testing if "a+b" overflowed, the unsigned test is "a is greater than c" and the signed test is "(a greater than c)!=(b less than zero)" (we can optimize that "b is less than zero" test, such that this becomes two compares and one jump).
So the code for my fast C version - you can plug it into the benchmark source I posted yourself:
__forceinline long __sreeSafeadd(long a, long b)
{
long c = a + b;
if ((a<=c)==(unsigned long(b)>>31))
SafeIntOnOverflow();
return c;
}
Its not what I might call "maximally" portable, in that it presumes two's-complement and basic processor oveflow arithmetic, but its basically as good as it gets (IMHO). It also uses one of my favored "mini-patterns" - using comparison as a computation value, as opposed to just as just a branch variable. This pattern extends fairly well to all the common overflow arithmetic math operations, amongst other things, though being a graphics guy, I really just want the stuff to clamp - I'm not sure that people are prepared to deal with integer overflow exceptions. I only used that in these examples because that's how the MS stuff worked that I started with as a benchmark for performance - I think exceptions are generally bad for most programmers and should not be used.
But what suprised me about all this, was (a) lack of "first order" information online, with real benchmarks, and, relatedly, (b) the assumptions folks tended to make about performance (particularly the "its Assembly so its faster"). This is a pretty basic simple (but important) thing, but the error propagation of information on the web was quite high - seems like people have just pushed around the same code and ideas from site to site, as opposed to actually investigating from first principles.
This assumption driven "error propagation" seems like a common problem that I'd hope at least technologists would be more immune from - not so much. I wish I saw more stuff like this for developers.
Heh. Veeeerrry funny, over generalizations, blah blah blah, etc. - but consistent with my experiences with tech culture delusions of grandeur - read this if you're a geek with start-up dreams (and you're vaguely serious about it).
Funniest (to me) were #6 and #7 (Hah! Lisp sux because it is SO productive it makes you anti-social - brilliant!).
Courtesy of Slashdot, naturally (news for nerds).
Somebody should produce the counter - top ten business-guy business myths; any doofus who starts quoting "Good to Great" should Google "logical fallacy" and "appeal to authority"... :) (you know who you are... :P)
