I have ported Dali Clock to the Palm Pre.
Truly, this program will last forever. If I have anything to say about it.
It's a little slow. It is, in fact, a bit slower than the PalmOS "Classic" port. And, for that matter, the original Xerox Alto version. Why, you may ask?
Because this port is written entirely in Javascript.
frsrs.
Let's take a moment to ponder this version and the Alto version, and just how many wasted instructions, layers of abstraction, frameworks, toolkits and outright cruft have gotten between the algorithm and the frame buffer in the intervening twenty-seven years. This program makes my phone hot. Hot, I tell you.
Oh. The huge manatee.
Welcome to the future! The web is the next desktop lol.
Is it too late to go back in time and kneecap whichever smartarses thought that making a hypertext viewer have Turing-complete scripting ability was a good idea?
Skynet is calling and the call is coming from inside your pocket! [blood-curdling shriek - plus those violin noises]
BTW, Google has just announced native code support for Android, so maybe
peercompetitive pressure...Some WebOS apps must be written natively. I very much doubt the Classic PalmOS emulator is in JavaScript. Whether Palm release the SDK required to write native apps is another matter, though I imagine that if they don't, someone will reverse engineer it pretty quickly.
"Some WebOS apps must be written natively."
You can't fool me! It's JavaScript, all the way down!
They'll eventually have the hardware understand javascript. ;-)
They said the same thing about Java...10 years ago.
There is hardware that understands Java :(
I believe the emulator is implemented as a npapi plugin that runs in the browser...
THE CALL IS COMING FROM INSIDE YOUR PANTS
If you're going to complain about how stupid it is that browsers use javascript (horrors!), you really ought to do it on usenet, not livejournal. Just sayin'...
I'm afraid that your snark is rather derailed by the fact that LiveJournal is one of the few sites that still work with JavaScript disabled. ;)
(Also, if I didn't use things I didn't approve of, the only person I'd be communicating with would be Stallman, assuming that GnuSense even has a news client. That would not be a good prize.)
Yeah, and everybody disables javascript before visiting livejournal because it's so much better that way.
Every successful abstraction, starting with (or possibly before) the compiler, attracts the ire of cranky old-guard types who complain about how inefficient it is and how it dilutes the purity of computing. And then everybody else goes ahead and uses it anyway because it lets them do things they couldn't do before.
I'm not berating scripting languages: I'm berating their use in browsers over a decade ago and what this lead to. But I'll shut up now. (And there was much rejoycing.)
Which leads us back to the DaliClock which someone was well able to do before JavaScript was around. ;-)
You mean other than xslt?
http://www.unidex.com/turing/utm.htm
What I boggle at is that C++ template instantiation is turing complete _at_compile_time_:
http://ubiety.uwaterloo.ca/~tveldhui/papers/2003/turing.pdf
Unless I'm very much mistaken, XSLT, and in fact all the bastard X-children of SGML (1998; '96 if you want to go back to a draft), postdate JavaScript (1995). So, no, I do not mean that.
(I'm sure someone could cite a prior-to-Web hypertext system with Turing-complete documents, but the closest that comes to mind is Trellis, where links formed a Petri net.)
In things-that-remind-me-of-Dali-Clock news, and are also implemented in Javascript, Scroll Clock
Aren't there any hardware/software designers left that want to build devices that run efficiently?
I thought we'd all decided scripting languages were slow and not worth using for serious computational stuff?
Oh yeah... I forgot, our computers got fast enough that we could pull this mad stunt off.
Think of all those wasted CPU cycles the next time you watch your phone redraw its tiny screen. It's wrong when 10 year old 8bit computers are more responsive than current generation machines.
I gather from this that the Palm Pre is a departure from Palm's traditional championing of lightweight, efficient platforms?
How disappointing.
The clue is in the name "WebOS".
The Web is a crap hypertext system, an even worse thin-client system, and quite possibly the worst concievable graphical application platform. At least use of it on full-size computers has the excuse that it's vaguely zero-install, cross-platform, and loads from a remote server, so the publisher can enforce obsolescence. For a locally-installed, device-specific (which it will be, if it's to make use of native human interaction capabilities like tilting, touchscreens, or trackballs) program, IT ARE MAKE NO SENSE.
But, hey, it's like totally 2.0, man!
Lame, looks like the iPhone still remains the "Platform which most closely resembles how I think computing should be".
This makes me sad.
As somebody who works at a company developing apps for all the major platforms including iPhone, Blackberry, Android and Windows Mobile, WebOS has the distinct advantage of being the easiest to develop for out of all of them (at least for our goals). In the long run I think that means that the Pre will end up with more apps than any other platform, which will be Very Good for Palm.
> Aren't there any hardware/software designers left that want to
> build devices that run efficiently?
Yes, we're called "embedded developers", we do things like BusyBox, and as far as I can tell we're all slowly migrating to the iPhone.
> Think of all those wasted CPU cycles the next time you watch your
> phone redraw its tiny screen. It's wrong when 10 year old 8bit
> computers are more responsive than current generation machines.
Except that CPU cycles use power which eats battery life, which is a big deal in the embedded world.
By the way, if you think Moore's Law will give every device so much memory and CPU you won't have to care, you haven't heard of "disposable computing", where Moore's Law someday makes a small but usable amount of computer power so cheap you can manufacture millions of them to be _thrown_away_.
Imagine the day when electronic paper's patents expire and you walk down a cereal aisle full of boxes of captain crunch that change what's displayed on the front of the box every 30 seconds. If a usable computer can cost less than the "free toy inside" and run for months off of a blinky-LED style watch battery, or perhaps they'll eventually get this stuff work:
http://www.post-gazette.com/healthscience/20000904harvest1.asp
http://www.cellular-news.com/story/22920.php
http://www.guardian.co.uk/environment/2009/jun/10/nokia-mobile-phone
Yes, they'll have to work out the environmental kinks of throwing them away, but regulation will take a while to catch up, and if you make 'em really really small the materials used in them become rounding errors for the rest of the packaging...
Huh? Busybox isn't what I'd use as an example of something good, I'm not sure what you're getting at with the remark about CPU cycles because the entire point is that they're being squandered nowadays on largely pointless abstraction, and oh boy--I sure can't wait for the era of such waste and societal decadence that Cap'n Crunch boxes are animated. Maybe when I look down while I'm taking a dump in my own home there can be some sort of advertisement in there too.
I thought xdaliclock was the coolest thing to ever hit a computer screen when I was 18 years old (well, that, and a few other things). It was like Whoa The Numbers Are Melting How Cool Is This?
I'm nearly twice that age now and it's still pretty Whoa.
Since it's JavaScript, do you have a version that we can view here in the comfort of our Firefox, Chrome or Safari?
Using anigifs instead of canvas might up your framerate. But I guess that's not the point of dali clock.
Sadly, it has to do transitions between arbitrary numbers (when switching out of date-mode, or when machine load causes it to have to skip a second or two to keep up.) I addressed this in the X11 version, when in 1991 I was trying to make the animation run sufficiently fast when doing uncompressed X protocol to a remote NCD X terminal running over a 14.4kbps modem connection (which is what I had at home), and the number of cached intermediate frames was vast. I cached [1-9]→0, [1-8]→[2-9], [1-7]→[3-9] and 9→1.
Also, that's cheating.
You only need 100 images, right? Also, thanks for making it run fast on NCD X terminals; that's what I first saw it on (in 1993). And it was the coolest thing.
121 transitions. Times the frame rate.
Also, cheating.
What's the 11th character? I meant you'd need 100 transition animations. Yes, it's cheating.
They transition to/from blank as well. But actually you can omit the null transition so really it's only 110 transitions.
Of course, now you have a version that runs on iPhone and Android too, and any platform that has a modernish browser. We've finally got a universal application platform. It's just a pity that it kind of sucks.
I got about halfway through a "real" iPhone port of Dali Clock (porting the Cocoa version) and gave up because it was just too much of a pain in the ass. See, iPhone doesn't run Cocoa, it runs something a lot like Cocoa, in that it's a GUI written in Objective C, but the libraries are completely different in arbitrary ways. I mean, you wouldn't want color allocation to have the same API on both a Mac and an iPhone, right? That would be crazy talk.
It's in the source bundle if anyone wants to finish it.
Of course, it will most likely be rejected, with no reason given, by some low-level app store flunky.
Since everyone else is too busy feeling superior, I'll throw in that I'd be curious to see a profile of what makes it slow. The pre uses v8 so the JS is JITting to native ARM code. The rendering is WebKit which is fast and light for what it does. Just guessing, but it could be JS→canvas overhead or it could be drawing overhead. Depends on how you're implementing the morphs -- if it's as a pixel buffer, then yeah, pretty slow.
I support the above request for a web version. I've got a friend who works on this sort of stuff for Chrome who would probably poke at it a bit.
http://statictype.org/jsdaliclock.zip
Just modified enough to make it run.
Works on Firefox and Chrome.
Haven't tested anywhere else.
oh, and live version here:
http://statictype.org/jsdaliclock/clock-scene.html
This makes my dual-core laptop speed up its fan. Fuck JavaScript. :|
This makes my desktop use... 2% CPU?
Your laptop sucks.
Never denied that.
For whatever it's worth this runs on a 1st Gen iPod Touch with v3 OS' Safari.
Thank you, sir.
Runs at a decent clip in a firefox 3.5 nightly, but we have a JIT now too. I'll throw this into the performance suite we're fleshing out in the next few months, along with the various emulators, raytracers and other gewgaws.
Always good to keep the needs of real eyecandy in mind when tuning.
It seems to run moderately well on Firefox 3 as well.
On the other hand this little thing I slapped together:
http://statictype.org/chainreaction/
has a noticeable speed difference between Chrome and Firefox3. Although it's possible that I'm doing something wrong somewhere.
Turning off firebug and running in safe-mode didn't make it any faster.
I haven't tried it on Firefox 3.5 with their new JS engine though.
Could make a difference. I just tried and it seems a bit faster with the JIT enabled, but you don't have a framerate count or anything, so it's hard to tell. I'm not surprised if chrome (or safari) still beats us on a given page. They've been doing excellent work too. Yay performance competition! Everyone wins.
The engine in 3.5 is very ... difficult to make predictions about the performance of, at this point. When it guesses right and hits peak speeds, it can beat v8 and sfx. It has a more aggressive type-specialization and inlining system. When it guesses wrong, it has more work to undo and subsequently gets hurt worse. V8 and sfx tend to sit at a more steady state, benchmark-to-benchmark; amusingly sfx is usually on top, and it isn't even a JIT, just a context-threaded interpreter with a lot of smart design choices.
But there are a number of knobs to turn (and auto-knob-turning algorithms to stabilize). We think we have a lot of room for performance improvement. This release was more about getting it working.
Thanks for that.
I thought about trying to abstract it out so that the clock code was just a subroutine of the WebOS code, but it seemed like kind of a rathole...
Works in Opera 9 too, so looks like you've got it right. (Doesn't in MSIE 7, but does that even support canvas malarky?)
no version of IE supports canvas directly, but there is the ExplorerCanvas project:
http://excanvas.sourceforge.net/
It's fine for what it is, but it'd be much nicer if MS would stop bucking the rest of the world. I also suspect excanvas is too slow for Dali Clock.
Anyone with Windows at their disposal want to try this?
...
Anyone?
I tried doing the one-line change to add excanvas.
Internet Explorer gave me a random javascript error.
I couldn't be bothered to follow it further.
Already mentioned cluecc but I did get off on a tangent and managed to track down some results for it with v8 here.
Chances are the clue output is not really 'optimal' vs. hand-targeting js, but the 10%-of-native result is an interesting... "win-to-fail ratio."
It's hard to find Whetstone results for the CPU in the Pre, but if the results table here has anything to do with anything (see also some phone review sites publishing Dhry and Whet figures for smartphones), current-era smartphones are performing somewhere between a 386 and Pentium 133 [although this is with the phone OS running]. So 10% of that doesn't leave much... maybe only somewhere between a MicroVAX and a Cray 1. [Yes, Whetstone is completely the wrong benchmark to use, but it's all I have the native-vs.v8-js results available for.]
The point, if there is one to this post, would seem to be that there's room for improvement and/or that js maybe isn't the best 'universal VM' for applications like this (vs. something like llvm, the forgotten Tao products behind the Amiga Inc. pipe-dream, or a rare instance of Java working properly). But one would think that, in theory, native js should be able to come up a little higher than the 10% penalty, so the other problem is the lack of a fast path (or optimization therefor) to get graphics onto the screen.
What's horribly wrong is not so much having abstraction, it's that the modern attempts at abstraction are benchmarking far worse than LISP. (So did LISP get something right, or is it just that it takes 20+ years to properly optimize that level of abstraction?)
You forget that due to relativistic social and economic forces at work in the expansion of computing, the state of the art in deployed computer science is actually traveling backwards in time. It takes enormous effort just to slow the reversal down.
If you want a technical perspective: the nature of JS (mostly all the loose binding) makes JITs for it extremely speculative; they have to do a lot of guesswork. When your guesses turn out right, you can drive the speed up pretty high. When they turn out wrong, you have to throw out guesses and adapt very fast (or at least try to limit the damage).
Also -- quite independent of the language -- the layers of software between the JS engine and the framebuffer are substantial these days. Takes a lot of carving to get a fast path all the way down.
There remains quite a bit of room for improvement in the JS engine arena though. There's active competition now, at long last. The next few years will see a lot of field-tuning and benchmark-wars in this area.
Awesome. I believe this makes you the largest WebOS develop in existence.
I've been using xdaliclock for almost fifteen years now, and I find this both awesome and hilarious.
Here, I've written the DaliClock family a bastard cousin who is never invited to reunions, an S60 3rd edition port.
(Also, obligatory video is here, it's a bit loud because the phone speaker was a bit too close to the camera mic. might want to turn the volume down a bit before playing.)There's still a couple of problems to sort out, it doesn't sync too well with clock time at the moment, skipping about one second in 15. Plus there's a noticeable redraw at the end of each cycle when it refreshes the screen. But still, not too bad for a couple of hours work.I'll probably sort those things out tomorrow and put some source and binaries up.
Ha, I was thinking of doing an S60 port.
Can you release the source?
I'd be interested in seeing how it works..
"Truly, this program will last forever. If I have anything to say about it."
All hail the Dali Clock. Never shall it cease to morph. Never!
When I have to reinstall Debian because I've managed to break it by trying out stupid things (again), "aptitude install xdaliclock" is right after getting X up and running (yet again...). Thank you again, JWZ.