Why one cannot recommend the freerunner as a daily phone (was Re: Is a FreeRunner sufficient for me?)

Laura Vance vancel at thespazcat.com
Thu Jun 25 01:32:42 CEST 2009


It's not about the programmer managing memory, the C++ compiler produces 
a MUCH larger memory footprint.

I like C++ programming, and I used C for years before that.  My first 
exposure to C++ was when I simply compiled one of my C programs with the 
C++ switch.  An executable file that was about 2k compiled as C became 
about 140k compiled as C++ ... I didn't modify the code at all.

The thing that I think is a complete absurdity is the fact that so much 
of the software for the FR is written in an interpreted language 
(Python).  This alone contributes to the slowness of the device.  Heck, 
the frameworkd is a python program. (top shows "python 
/usr/bin/frameworkd").  The core systems need to be compiled.  With a 
past employer, I did most of my development in perl, and I ran into a 
bottleneck in the interpreter for startup time.  I copied the program in 
C++ and did a load comparison of the two.  It was easy to bring the 
system to its knees with the interpreted language, but I couldn't even 
get the cpu load to bump more than a tiny bit using the compiled C++.  
(I write perl using the same structure as my C++, so it's very easy for 
me to port between the two)

This is nothing against python in general, I don't think any interpreted 
language belongs in a phone except provide the interpreter for the 
individual owner to write their own code... but interpreted code should 
not make up the core of the system.  Interpreted languages are excellent 
for rapid prototyping and initial development, but once it's ready for 
any type of release, it should be ported to C (in this case) or C++.

I do use my Freerunner (rev6 that nobody has told me about a buzz... and 
I've asked them) on a daily basis.  I choose not to let my phone go on 
standby, because I had heard about some of the problems with my current 
release, but I'm willing to charge it frequently since I am choosing to 
not let it standby.

At some point, I'd like to get into the SMS code and make it do a few 
things:
- Show the contact rather than the phone number
- Show the actual time the message was received. (currently all messages 
are 1-1-1970)
- Link the SMS message to a "voicemail" icon (my provider sends a 
message from -@ when I have voicemail and <ascii triangle>@ when all 
voicemail has been heard).

But that's when I have the time. :)

-Laura


mobi phil wrote:

> memory?... this remembers me about women... you can give the same 
> amount of money to a blond, black, brunette, blue eyes etc. women... 
> all of them they will spend it the same nanosecond...
> give the same money to a good businessman.... He will use it carefully...
>
> the programming language does not make too much difference neither. 
> Give the same memory to an unconscious programmer he will waste it the 
> same, just in few lines of code whatever C or C++ or C-- his is 
> programming. Only issue could be memory fragmentation, that with a 
> little care could be avoided in C++ as well. Average C++ programmers 
> have no idea how to save memory. But C++ at least helps you a bit more 
> to think in patterns, to keep much more order with less effort.
>
> I think if one keeps for the backend all the legacy (not pejorative ) 
> C code, but coding against a simple widgetset for the GUI in C++ is 
> not a bad idea. Creating a C wrapper, was not really a joke, for only 
> C programmers...
>
> I am not saying that C++ is better for the embedded devices, far from 
> that. Just that Qt has a much better abstraction than other toolkits, 
> and is easier to use than few other toolkits. And besides that 
> produces much better user experience. And it is portable. Encourage 
> programmers to create GUI with QT, in few days there will be somebody 
> who will port that to windows CE as there is QT toolkit for CE as 
> well. Then maybe wince programmers would also think about programming 
> against some more generic toolkit etc.
>
> By the way... did anybody "reverse engineer' a bit the iphone ?or 
> Android?(not necessarily only the code, but gui patterns I think 
> paying a little attention to their way of doing things maybe will 
> inspire a bit.
>
> would not like to offend... just some random ideas...
>
> mobiphil at mobiphil.com <mailto:mobiphil at mobiphil.com>
>
>
> On Wed, Jun 24, 2009 at 8:08 PM, David Ford <david at blue-labs.org 
> <mailto:david at blue-labs.org>> wrote:
>
>     do you understand the weight involved with using c++?  without
>     very very
>     careful management, c++ is rather hefty for embedded devices.
>      granted,
>     having 128M to work in is indeed far more tenable than smaller devices
>     but it's still onerous.
>
>     C is much more lightweight and very functional.  any benefits of c++
>     usually don't overcome the drawbacks for embedded devices.
>
>     -d
>
>     On 06/24/09 07:09, mobi phil wrote:
>     > Hey!! Is this kind of phrase "i am not interested in c++. " driving
>     > the linux phone development? I can never understand how is it
>     possible
>     > to have such a huge gap on the scale between C programmers and C++
>     > programmers? Why are C++ programmers dying out? Is it because some C
>     > programmers never managed to get the point with C++ and those
>     who did,
>     > switched automatically to Java? I propose a C wrapper arround
>     Qt, for
>     > the C programmers, and everybody will still benefit, beleive me.
>     QT is
>     > a treasure, is a nice clean code! And it is fast!
>
>     _______________________________________________
>     Openmoko community mailing list
>     community at lists.openmoko.org <mailto:community at lists.openmoko.org>
>     http://lists.openmoko.org/mailman/listinfo/community
>
>
>
>
> -- 
> being mobile, but including technology
> http://mobiphil.com
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Openmoko community mailing list
>community at lists.openmoko.org
>http://lists.openmoko.org/mailman/listinfo/community
>  
>



More information about the community mailing list