That ROCKS. Yay, I don't have to give up the illusion of control while, er, giving up the illusion of control.
This is why I use vim. Not because it's better, but because it's less likely to wake up.
Thou shalt not make a machine in the likeness of a human mind.
There are many new machines on Ix... troubling machines.. thinking machines...
Ah, if only the G1 had a Ctrl-key..
Perhaps he was able to repurpose the "Menu" or "Magnifying glass" keys?
You clearly haven't used a g1. The terminal app uses clicking the scrollwheel as control.
However, that's not even worth knowing about because Connectbot added localhost support so you can now use it as a local terminal - it still does clickwheel control; but double click esc/meta; scrolling up down left right are the appropriate arrows keys, and you can highlight and copy and paste text. Did I mention it does ssh too? Yeah, connectbot is basically the best terminal app I've used on -any- phone ever, and I've used them on WinCE/Symbian/iphone/etc
Between connectbot and the browser, I basically can do everything from my g1 that I need to do from a laptop on the road.
Wrong guess. I've had a G1 for months, and I love it.
But I've tried running emacs over ConnectBot, and I have to say, the scrollball makes a horrid control key. Keys aren't meant to roll under your thumb (thus moving the cursor) if you aren't extremely careful about pressing them.
I also have issues with the terminal emulation on ConnectBot, for what it's worth. I run mutt in color mode with my normal terminals, and ConnectBot still makes a hash of some of that.
All that said, the G1 has become my best friend, and I love it dearly.
I just wish it had another key on the keyboard that could be used for Ctrl.
Dunno, I've got no problem using mutt in color (in screen) on ConnectBot at all.
And I use vim, so the control key doesn't bug me so much. But yeah, they could have added that key.
Yes a non rolling discrete key would be an improvement; but in my experience a very minor one. My old nokia symbian phone had one (as well as an Own key). That said, putty on symbian was significantly worse in every other respect. The lead connectbot developer Kruton on #connectbot on freenode is also very responsive if you've got bug reports or suggestions for improvements. I haven't looked; but it's not inconceivable that the new IME framework might allow for key remapping (put the extra shift and alt keys to use); or you could certainly create a special OSK. But w/e I think it's great as is, especially now with localhost terminal support.
They gave me a Google Ion (Magic, myTouch, G2) Android phone at Google I/O. The price point was hard to argue with. I freaking love the thing. My poor Treo 680 feels bereft.
I don't think I'd like emacs any better on the phone than I do on a desktop.
I'm fond of having Android Scripting Framework even if I don't use it yet. Something nifty about having Python and BeanShell in your purse...
Nice... If I cared about mobile 'phones mine would be android.
"Sure, I'm alive...but why."
Zomg, phone hacks...
I haven't even gotten my Android software update yet for fear it'll fry my phone.
Yes. Alas, cupcake, for me, is still just a snack.
Not to proselytize but what? Cupcake/1.5 is mostly a bugfix release - slightly improved battery life; added some features that should've been there to begin with (OSK/IME support, Find on page in browser). Donut is where the current public repo is now, and eclair isn't far off....
Don't live in the past.
Now if only they hadn't used Java and the terrible speed penalty it incurs (at least the sidekick's proprietary jvm was speedy; but it was also developed for much slower hardware. Fast hardware makes programmers razy).
I thought they didn't use a virtual machine? I was told they did "something else" to make it run natively.
Nah, the Dalek Dalvik VM is a JVM re-engineered to be incompatible with Java byte codes and to use less memory. One of the things they did with Dalvik is to convert it from a stack oriented byte code machine to a register oriented one, for the sake of being able to have a more efficient interpreter.
Unfortunately, a more efficient interpreter is still slower than the results of a good JIT compiler.. especially since modern ARM processors have some support for directly executing Java byte code in silicon.
Hopefully they'll be adding optimizations to Dalvik to speed it up along the way.
Many of their own apps (the browser, particularly) are written in native C/C++ against their non-GPLed C library replacement.
That's what makes what Noah did such an accomplishment.. he has a developer phone, and he got GNU Emacs to compile and link against the non-standard C library. Non-rooted, non developer Android phones don't allow that kind of hanky panky.
Actually what I did was far easier--and really, better because of the other side effects: I installed debian on a partition of the sd card and chrooted into that. I ran a totally stock build of emacs.
The reason why that's better than screwing with the android native libs is that a bunch of other stuff runs in debian userland and you don't have to do any extra work for them. My next project is to set up openvpn, which only involves building the tun.ko module for my kernel because I'm using stock firmware and google thoughtlessly didn't include it. The rest already works.
Granted this is all still a lot more cumbersome to use than the dalek dalvik apps. Also granted is the fact that my time has no value.
I agree about the trackball being a lousy ctrl key. Before connectbot added local term support i was mainly using "better terminal emulator" and that has the option to let you use other keys for ctrl, including the 2nd "@" key. Maybe someone will add that to connectbot also.
Ah, ok. So you're able to run Debian apps with glibc simultaneously with the Android apps?
That's pretty damn cool.
Just to be clear, among Dalvik's several goals, none of them was to be gratuitously incompatible with historical vms, though the incompatibility was an inevitable outcome of heeding the actual goals (e.g. memory-mappable executable format, fast interpreter, etc.).
Also, the browser isn't a "native app" per se. The UI is all written in Java, and it links to WebKit for the HTML rendering. WebKit happens to be one of the bigger native libraries that you get access to, but there are others (OpenGL, ICU, OpenSSL). The browser isn't doing anything particularly proprietary.
From a couple comments up, the "terrible speed penalty" from running an interpreter is mostly a phantom -- overly glibly, on the one hand Android already includes native code for much of the heavy lifting (see above); and on the other hand a good mobile app spends most of its time waiting for user or network input, and waiting runs just as fast whether you're interpreted or executing hand-coded asm -- though there is in fact a JIT for Dalvik in the works at this point, to help out the bona fide cases. Additionally, folks are currently trying to push out a Native Development Kit (NDK), which aims to provide a long-term supportable way of including native code in apps. The JIT code hasn't hit the public repo yet, but I believe the NDK has (even though it's not yet officially released).
(Again, to artkiver) Just for the record, on a current gen mobile cpu, I am pretty sure the Dalvik interpreter would beat the hiptop's one, due to the vastly reduced number of instruction dispatches (with their inevitable pipeline bubbles). I won't opine on other parts of the system.
I guess it all depends how you benchmark. For me, if I switch between a messaging app and a contacts app on the sidekick it's pretty much instantaneous. It routinely takes 5-10 seconds to do the same thing on my g1.
There's benchmarks, and then there's actual user "waiting for device to do what I told it do" timings. In every experience I've ever had, the latter is a more important metric. The only way android is a win currently, is waiting for the device to do what I want it to is still faster than going to a laptop in most cases for getting as much functionality as I get out of the thing.
Don't even get me started on Dalvik and its incompatibilities; or how the private google repository has goodies that the rest of the world doesn't have access to currently. If java had any saving grace it was the erroneous hype of "write once run everywhere." And if adopting open sores meant "we'll release our in house stuff when we've already moved on to the next build train" then you're losing the major advantage the community in a f/oss development model really has to contribute to your cause.
Like I said elsewhere, WebOS is actually much more of a google mindset take on a phone OS than Android. I could see some crazy NaCL implementation befitting it much more cleanly. But I'm glad google is behind Android and I'm glad Android is staffed with smart ex-Danger peeps. The others who went to Apple seems like they mostly couldn't stand working there and instead went to Palm to work on the Pre. I hope Palm can weather the undertaking; or that google pilfers some of the smart ones to make improvements to Android.
I mean, please don't take this as a dig since it sounds like you've worked on it. I've got a number of other friends who are working on Android (and have worked at Danger, Be, Apple and Palm as well) Android in my experience, is the currently still the best of the worst of what's out there and I wouldn't trade it for consumer alternatives. But I really expect we could've been much further along in 2009 than we are. In many respects, you guys are ahead of the curve because your competitors crippled things -so badly-.
I mean, sure it had copy and paste, and multitasking unlike the iphone. But what about job control? GC is *great*, and I'm glad to have it, but it's solving a different problem. There are times where I've had to pop the battery out of my g1 in order to even get it to power off. And just as many times I get erroneous "Wait/force close" prompts for an application I've just launched and the GC is being too eager when reality is it takes time to load things. If you do some history reading and find that a team that worked with Feynman came up with user job control and multitasking simultaneously. You'll realize that such an omission in any OS is only getting half of the picture. There's a reason we've invented these things, please forgetting our history and thinking we've got a better solution when at best it's a complementary system; has actual real user experience losses.
But whatever, the hiptop was the amiga of smartphones. It may indeed be because the sidekick is a much simpler system than android, and if you got it bootstrapped on dalvik on comparable hardware, dalvik might actually be faster; not an exercise I can undertake without some major effort and pulling strings. Or it may be more than that; using linux as the glorified bootloader that Android does has its own penalties to come with the advantages. We'll eventually surpass what was way ahead of its time, but as in the case of the Amiga, I suspect it will take a lot longer than anyone expects.
Fast, cheap, functional, pick two is the name of the game I guess? I'd pay more to get the two F's.
>I guess it all depends how you benchmark. For>me, if I switch between a messaging app and a>contacts app on the sidekick it's pretty much>instantaneous. It routinely takes 5-10>seconds to do the same thing on my g1.
I'm not gonna deny that you've experienced longer delays in switching between apps on a G1 compared to your Sidekick. I'm just saying that that's not because of the difference in VMs.
Note: App switch pauses generally don't have anything to do with GC on the G1. Most GC pauses are under 200msec. (And yes, even that's too long.)
Also, yes, I am qualified to comment on both the Sidekick VM's internals as well as Dalvik's.
Also also, you are preaching to the choir in re: running Android as a normal open source project. It hurts every time someone makes that complaint, because so many of us on the inside are trying to push things in the right direction, and it will take a lot of time and effort to get there. You are understandably frustrated, but please realize that the people most likely to hear your rants are just as frustrated.
Well if there's anything I can do to help let me know. We may not be entirely on the same page but we both want to see improvements. I may be a critic but it's not based in animosity & hopefully the jist can be taken constructively even if I'm pointing in the wrong direction for what is being implemented in a deleterious manner.
I mean I'm replying on my g1 right now; which is something at least two smartphone platforms I've used in the past couldn't even do. :)
What you can do to help: Interact on thepublic mailing lists. Submit useful bug reports. Submit patches. Write apps and widgets. sudo make me a real Emacs app. In short, don't just stand by the sidelines kvetching. (A limited amount of kvetching is acceptable assuming you do one or more of the preceding.)
sudo make me a real Emacs app.
Just for the record, while the "most imminent" release branch is still operated on privately, the Android team has been active in accepting patches on tip-of-tree, and some patches do get cherry-picked for shorter term release. Different sub-projects have different predilections in that regard; the repo project, for example, operates entirely in the open.
What is the G1 using for its busy timeout?
Beat's me; I'm not a database guy. UTSL? Whinging to the contrary notwithstanding, what's published at source.android.com is very close to what actually shipped.
I wish I had the time, but as evidenced by the recent plummeting in my fanboy posting frequency here, I've been really busy. Plus you and I both know that sadly not all of the source is open yet.
Can I make you a deal? I promise to look through the source for it as soon as I can if you would please post a bug internally saying that some guy who claims to have done a lot of os-level sqllite clients on ARMs is saying that some of the new delays in Cupcake behave very similar to a sqllite busy timeout issue and would you please ask QA to run their perfomance tests at 5 ms, 10 ms, and 1000 ms (which was the default on all but a few builds of sqllite and I fear may have slipped back in)?
I would be happy to look through the code as a customer, but honestly I probably won't be able to for a month. It would be so cool if you would have your DB and QA folks just give it a quick look.
Filed with title: Some guy on the internet says that maybe we need to do some sqlite "busy timeout" tuning
>Plus you and I both know that sadly not all of the>source is open yet.
The code in (your) question is in fact available on the public Cupcake branch.
Here's what's not open: Proprietary drivers (owned by device manufacturers), proprietary Google apps (e.g. Gmail), embargoed new features (e.g. pre-Cupcake, the homescreen widget code), and interim bug fix churn. That last one isn't intentionally left unpublished, it's just that the internal and external repos aren't totally in synch.
The main db guy says:
Our busy timeout is set to 1s, but we pretty much neverhit that since we use a Java level exclusive lock per DB and only asingle process accessing the database to avoid, among other things,hitting the SQLite file level locking due to the nasty polling it doeswhen the lock is busy.
He left the bug open, so maybe he's doing some more investigation.
Please recommend changing it and then running the QA performance suite. It's easy to think that only one proc is accessing, when all kinds of helpful people have done things with its threads or even other procs for quick access.
Can someone explain why this is notable?
See Jamie's tags up top.
I did in fact write dialer.el (called fso.el) for the OpenMoko and used Emacs to make and receive phone calls and send and receive text messages for a few months. It worked "nicely".
Also also also, FWIW, this is totally and completely awesome (hi, Noah!), though I really want to run Emacs as a native app, and without having to include all of Debian. Technically, this should be possible to do in a supported way as soon as the NDK is out there (not that I expect anyone to actually go through that effort any time soon, myself included).
I just don't want to have to root my phone, or run a developer model (more likely to do the later), and it would be nifty if it could talk to the native api (dialer.el).
Sigh. Emacs needs to figure out how to handle html better (port to emca script and run it in a browser?).