Openmoko - User contributions [en]

Talk:November 6, 2007 Community Update

2007-11-06T17:52:40Z

Placid:

How many of you must have 850 MHz support, and would be satisfied with an 850/1800/1900MHz variant, and how many of you must have full quad-band?

Note that by asking this question we do not promise to provide these options.

Please put your answers below:

'''Must have an 850/1800/1900MHz variant'''
* -- [[User:Mwester]] 06:46, 6 November 2007 (CST) - This thing is nothing but an extremely expensive PDA without 850 support. It should do what it was claimed it could do when it was sold (quad-band), but I can live with taking a real phone with me when travelling internationally.
* -- [[User:ShakataGaNai|ShakataGaNai]] 03:34, 6 November 2007 (CET)
* -- [[User:Aking|Aking]] 21:55 EST, 2007-11-05 - Live/work in an 850 only zone
* -- [[User:Matt|Mattdawg]] 19:57 MST, 6 November 2007
* -- [[User:Writchie|Wally Ritchie]] 10:02 EST, 6 November 2007 - GTA02 MUST support largest US GSM carrier.
* -- [[User:Digger|Digger]] 04:15, 6 November 2007 (CET) - But for the money would prefer quad-band
* -- [[User:Wisp|wisp]] 04:29, 6 November 2007 (CET) - But for the money would greatly prefer quad-band
* -- [[User:WJCarpenter|WJCarpenter]] 19:45, 6 November 2007 (PST)
* -- [[User:Angus|Angus]] 20:59, 5 November 2007 (MST) - Required for Rogers in Canada
* -- [[User:Montgoss|Montgoss]] 22:34 CST, 5 November 2007 - Frequently in areas that use 850 band.
* -- [[User:Xaid|Xaid]] 21:12, November 5th, 2007 (MST) - Rogers Wireless in Edmonton uses both 850/1900 bands.
* -- [[User:Mmontour|Mmontour]] 06:45, 6 November 2007 (CET) - So far I've been able to use my phone with 1900 only (Fido in Vancouver, BC) but I do sometimes travel to 850-only areas.
* -- [[User:Romulus|Romulus]] 07:31, November 6th, 2007 (PST) - I'm with Rogers and will need 850 when on the road.
* -- [[User:Mary|Mary]] 11:24, November 6th, 2007 (EST)

'''Is OK with the current 900/1800/1900MHz variant'''
* -- [[User:BlueStar88|BlueStar88]] 11:50, 6 November 2007 (CET) - 900 (D1-, D2- and O2-Network) and 1800 (E- and O2-Network) are essential in Germany
* -- (Most of Europe? From my quick bit of research, it seems 850Mhz is only needed for the US, Canada, Anguilla, Ecuador, Montserrat, Panama, St. Kitts and Nevis, Turks and Caicos Islands )
* -- [[User:C.M|C.M]] 06:44 CST, 6 November 2007 - 850 would be nice, but I don't need it.
* -- [[User:Avanc|Avanc]] 08:52 CET, 6 November 2007 - 850 would be nice, but I don't want to miss 900
* -- [[User:PT|PT]] 08:27 GMT, 6 November 2007 - 850 would be nice but the other three are more important for me
* -- [[User:s.decken|s.decken]] 10:49 GMT, 6 November 2007 - 850 would be nice but not required
* -- [[User:PiotrDuda|_alcik_]] 11:55 GMT, 6 November 2007 - I really need the 900.
* -- [[User:Mic|Mic]] 12:15 CET, 6 November 2007 - in Europe is 900 essential
* -- [[User:Mockenh|Mockenh]] 12:45 CET, 6 November 2007 - need 900 (Germany)
* -- [[User:Psmears|Psmears]] 14:55, 6 November 2007 (CET) 900/1800 covers most of the world; 1900 covers enough of USA/Canada to be useful for short trips.
* -- [[User:Placid|Placid]] 18:52, 6 November 2007 (CET) - UK, T-Mobile, OK with tri-band.
* -- [[User:Vegar|Vegar]] 16:46, 6 November 2007 (CET) - 850 would be nice, but the other three are much more important
* -- [[User:einalex|einalex]] 17:04 CET, 6 November 2007 - in Germany/Europe GSM 900 is a must-have. For me, 850 is optional.
* -- [[User:PBeck|PatrickBeck]] 17:45, 6 November 2007 (CET) I live in germany, so is 850 optional for me. But quadband would be nice.
* -- [[User:AVee]] Same as above, having a hardware/software switch for 850/900 would help as well.

'''Must have full quad-band support''' (note that this is not for GTA01 or GTA02)
* -- [[User:Elektrolott|Elektrolott]] 18:45 (PST), 2007-11-05
* -- [[User:ClashTheBunny|ClashTheBunny]] 04:03, 6 November 2007 (CET) - Right now I live on the North Shore of Boston and most places are 850
* -- [[User:Sagacis|Sagacis]] 04:16, 6 November 2007 (CET) - The phone is a brick to me without 850. International travel means I need all four bands.
* -- [[User:Davemaster|Davemaster]] 21:47, 5 November 2007 (ET) - International travelers, Me and my group (company) deals all over. We need all four bands.
*-- [[User:Rakshat|Rakshat]] 05:40, 6 November 2007 (CET) - For travel in the US, otherwise I am ok with the 900/1800/1900Mhz variant
* --[[User:NeilenMarais|NeilenMarais]] 15:37, 6 November 2007 (CET) - For travel to US also
* -- [[User:Jaebird|Jaebird]] 09:00, 6 November 2007 (CST) - The phone should be refundable to me without 850 (It was sold as a quad band phone, it is NOT). International travel means I need all four bands.

User:Placid

2007-11-06T15:23:58Z

Placid:

Website: [http://beplacid.net Placid]

Programmer from the UK

Talk:November 6, 2007 Community Update

2007-11-06T15:23:14Z

Placid:

How many of you must have 850 MHz support, and would be satisfied with an 850/1800/1900MHz variant, and how many of you must have full quad-band?

Note that by asking this question we do not promise to provide these options.

Please put your answers below:

'''Must have an 850/1800/1900MHz variant'''
* -- [[User:Mwester]] 06:46, 6 November 2007 (CST) - This thing is nothing but an extremely expensive PDA without 850 support. It should do what it was claimed it could do when it was sold (quad-band), but I can live with taking a real phone with me when travelling internationally.
* -- [[User:ShakataGaNai|ShakataGaNai]] 03:34, 6 November 2007 (CET)
* -- [[User:Aking|Aking]] 21:55 EST, 2007-11-05 - Live/work in an 850 only zone
* -- [[User:Matt|Mattdawg]] 19:57 MST, 6 November 2007
* -- [[User:Writchie|Wally Ritchie]] 10:02 EST, 6 November 2007 - GTA02 MUST support largest US GSM carrier.
* -- [[User:Digger|Digger]] 04:15, 6 November 2007 (CET) - But for the money would prefer quad-band
* -- [[User:Wisp|wisp]] 04:29, 6 November 2007 (CET) - But for the money would greatly prefer quad-band
* -- [[User:WJCarpenter|WJCarpenter]] 19:45, 6 November 2007 (PST)
* -- [[User:Angus|Angus]] 20:59, 5 November 2007 (MST) - Required for Rogers in Canada
* -- [[User:Montgoss|Montgoss]] 22:34 CST, 5 November 2007 - Frequently in areas that use 850 band.
* -- [[User:Xaid|Xaid]] 21:12, November 5th, 2007 (MST) - Rogers Wireless in Edmonton uses both 850/1900 bands.
* -- [[User:Mmontour|Mmontour]] 06:45, 6 November 2007 (CET) - So far I've been able to use my phone with 1900 only (Fido in Vancouver, BC) but I do sometimes travel to 850-only areas.
'''Is OK with the current 900/1800/1900MHz variant'''
* -- [[User:BlueStar88|BlueStar88]] 11:50, 6 November 2007 (CET) - 900 (D1-, D2- and O2-Network) and 1800 (E- and O2-Network) are essential in Germany
* -- (Most of Europe? From my quick bit of research, it seems 850Mhz is only needed for the US, Canada, Anguilla, Ecuador, Montserrat, Panama, St. Kitts and Nevis, Turks and Caicos Islands )
* -- [[User:C.M|C.M]] 06:44 CST, 6 November 2007 - 850 would be nice, but I don't need it.
* -- [[User:Avanc|Avanc]] 08:52 CET, 6 November 2007 - 850 would be nice, but I don't want to miss 900
* -- [[User:PT|PT]] 08:27 GMT, 6 November 2007 - 850 would be nice but the other three are more important for me
* -- [[User:s.decken|s.decken]] 10:49 GMT, 6 November 2007 - 850 would be nice but not required
* -- [[User:PiotrDuda|_alcik_]] 11:55 GMT, 6 November 2007 - I really need the 900.
* -- [[User:Mic|Mic]] 12:15 CET, 6 November 2007 - in Europe is 900 essential
* -- [[User:Mockenh|Mockenh]] 12:45 CET, 6 November 2007 - need 900 (Germany)
* -- [[User:Psmears|Psmears]] 14:55, 6 November 2007 (CET) 900/1800 covers most of the world; 1900 covers enough of USA/Canada to be useful for short trips.
* -- [[User:Placid|Placid]] 1515 (GMT), 6 November 2007 - UK, T-Mobile, OK with tri-band.

'''Must have full quad-band support''' (note that this is not for GTA01 or GTA02)
* -- [[User:Elektrolott|Elektrolott]] 18:45 (PST), 2007-11-05
* -- [[User:ClashTheBunny|ClashTheBunny]] 04:03, 6 November 2007 (CET) - Right now I live on the North Shore of Boston and most places are 850
* -- [[User:Sagacis|Sagacis]] 04:16, 6 November 2007 (CET) - The phone is a brick to me without 850. International travel means I need all four bands.
* -- [[User:Davemaster|Davemaster]] 21:47, 5 November 2007 (ET) - International travelers, Me and my group (company) deals all over. We need all four bands.
*-- [[User:Rakshat|Rakshat]] 05:40, 6 November 2007 (CET) - For travel in the US, otherwise I am ok with the 900/1800/1900Mhz variant
* --[[User:NeilenMarais|NeilenMarais]] 15:37, 6 November 2007 (CET) - For travel to US also
* -- [[User:Jaebird|Jaebird]] 09:00, 6 November 2007 (CST) - The phone should be refundable to me without 850 (It was sold as a quad band phone, it is NOT). International travel means I need all four bands.

Neo 1973 Battery Charging Logic

2007-08-21T08:20:38Z

Placid: /* from deep discharged battery */

The [[Neo1973 Battery]] charging logic is embedded into our [[Neo1973 GTA01 Power Management|PCF50606 Power Management]] Unit (PMU).

The PCF50606 supports a variety of [[Neo1973 Battery]] charging modes, based around the hardware limitations of USB.

Some USB hubs only provide up to 100mA per device.
If more than the available current is drawn from them, they may be reset, or power off.
This resets all devices connected to the USB bus, possibly causing data loss.
So, fast charge mode is only enabled after the Neo is told that it is safe to charge at this current.

An alternative method is used when connected to a more USB-compliant dumb charger. If the Neo measures 48 kΩ +/- 1% between usb pin 5 and ground, it will detect the dumb charger and use it for fast charging.

{{warning|While we have spent a significant amount on various safe-guards such as battery-internal overcurrent/overvoltage protection, manual twisting with low-level charger control aspects is not recommended. It might damage either the [[battery]] or charging circuit.}}

== Charging Modes ==

=== Pre Charge ===

The default mode is what the PMU calls 'Pre Charge'. In which we draw up to 100mA charging current from the USB socket. This mode is safe to use on any USB socket, since the USB specification mandates that 100mA is always available.

However, 100mA charging at a 1200mAh [[Neo1973 Battery]] means around 12hrs charging time, not very practical at all.

=== Fast Charge ===

Fast Charge is what the PMU calls the charging mode in which we draw up to 500mA charging current from the USB socket. This mode can only be used if the USB stack on the host controller has selected a '''USB Configuration''' for the Neo which allows it to draw 500mA.

By default, if you apply +5V to the USB device socket, we draw only 100mA.

==== Fast Charge (CCCV) ====

Fast charging, using first constant current, later constant voltage. This is what we use for our Li-Ion [[Neo1973 Battery]]

==== Fast Charge (CVCC) ====

[[Category:Neo1973 Hardware]]

== Neo1973 emergency charging ==

=== from deep discharged battery ===

A deep discharged battery is one where the terminal voltage is below the minimal voltage threshold. The Neo1973 (specifically: The PCF50606 PMU) will not power-on the device. ''see also [[Neo1973 GTA01 Power Management]]

If you make sure to remove the USB cable and put a deep discharged battery into the Neo1973, the battery can still be charged. All you need to do is to provide 5V to the USB socket, by either connecting the Neo1973 to some USB port or a dumb USB charger.

The battery will charge only with 100mA, and it will take a couple of hours until the battery is again charged to a level where it can power the phone.

{{note|Please do not press the power button before you have waited for something like four hours. If you do so, the phone might [partially] power up, and draw more power than the 100mA supplied by the charger/USB, and so begin discharging itself again.

If you did press the power button,
#remove the battery,
#wait a moment,
#insert the battery
#connect the charger or USB.}}

The procedure to follow is:
# '''Open Case.
# '''Remove Battery.
# '''Wait 20s.''' ''This resets the hardware, and makes sure nothing is drawing current during the next stage.
# '''Insert the Battery.'''
# '''Plug into a USB host, or USB charger.''' ''At this time, the battery will be charging at a low rate.
# '''Wait 1 hour.''' At this time, the battery will be approximately 5% charged, which should run the Neo for several minutes. ''This time needs to be resolved: it is not quite clear how long to charge a deeply discharged battery before the device is able to request a 500 mA fast charge current.
# '''If you have a USB host, plug it into a port capable of sourcing 500mA and load the appropriate drivers, so the neo can negotiate to draw 500mA.

*If you have a dumb charger, see the [[Bootloader]] page for how to add a u-boot menu entry to turn on fast-charging.

==Proposals for alternative charging schemes==

An alternate method - for example sensing if there is no USB communication from the host for 30 seconds - as may be the case with dumb 'USB chargers' - would need to be used to be compatible with the vast majority of already existing hardware.
This has a small risk of causing buses it is connected to in suspend mode, when they are not active, to crash, and is not compliant with the specification.

:The USB spec requires the host to reply in a much shorter time than 30 seconds. Waiting that long is overkill and would be very annoying if you were trying to charge with something like a [http://www.21st-century-goods.com/page/21st/PROD/AHPG crank charger].

[[Category:Neo1973 Hardware]]

Openmoko Local Groups: London

2007-07-30T11:30:26Z

Placid:

Welcome to OpenMoko London!

Beer and Neo anyone?

{|border=1
!Name
!Skills
!Interest
!Location
|-
|[[User:jptmoore|John Moore]]
|C/Scheme
|Application development
|Pinner
|-
|Alex
|Java,Perl,Python
|User & developer
|Hampshire
|}

See [[Talk:OpenMoko_Local_Groups:_London|discussion]]

[[Category:Community]]

Openmoko Local Groups: London

2007-07-30T10:51:01Z

Placid:

Welcome to OpenMoko London!

Beer and Neo anyone?

{|border=1
!Name
!Skills
!Interest
!Location
|-
|[[User:jptmoore|John Moore]]
|C/Scheme
|Application development
|Pinner
|-
|Alex
|Java,Perl,Python
|Application development
|Hampshire
|}

See [[Talk:OpenMoko_Local_Groups:_London|discussion]]

[[Category:Community]]

Openmoko Local Groups: London

2007-07-30T10:50:41Z

Placid:

Welcome to OpenMoko London!

Beer and Neo anyone?

{|border=1
!Name
!Skills
!Interest
!Location
|-
|[[User:jptmoore|John Moore]]
|C/Scheme
|Application development
|Pinner
|-
|[Alex]
|Java,Perl,Python
|Application development
|Hampshire
|}

See [[Talk:OpenMoko_Local_Groups:_London|discussion]]

[[Category:Community]]

Wishlist/BuiltInScriptingLanguage

2007-04-12T13:58:05Z

Placid: /* Perl */

{{Wishlist}}

== Discussion ==

[http://lists.openmoko.org/pipermail/community/2007-January/001909.html There was a discussion on the mailing list about choosing a built-in scripting language.]

Many different scripting languages will be optionally available in the repository. However, developers who choose one of these languages for their applications will not be able to see their applications included in the standard ROM nor available for use by those without an external microSD card.

[http://lists.openmoko.org/pipermail/community/2007-January/001945.html As expressed by Corey]:

''It's true that you have the ability to add anything to the phone.''

''There's another important consideration to remember: OpenMoko is a platform also; an inherent aspect of such a platform is that it always come shipped with X standard api's available for developers. This is why FIC had to select a group of components: gcc, glibc, xorg/kdrive, dbus and gtk, for instance.''

''They may decide that a scripting language would also be a necessary or beneficial feature to include in the base/standard platform''

...

''Choice is good.''

''And so is having a known/standard/default/static api and platform to build from; when I begin writting commercial and/or free software for the OpenMoko, I will design my software according the existing OpenMoko specs, and thereby circumvent the necessity of having to verify that my customers/end users have first installed the necessary scripting language, which would additionally circumvent the probability that your phone will end up with every scripting language known to man.''

''> So having lua on my system would be more or less pointless as I don't use it myself.''

''Less than one meg of space would be potentially wasted, true enough in your case. Know that there is probably plenty of other software on the OpenMoko platform that you, yourself, will not be using.''

''Also realize that though _you_ may not be directly using this hypothetical scripting language, it is more than likely that one or more of the standard apps that ship with the phone will be using it, and that other 3rd party software that you may or may not install may also be using it.''

[http://lists.openmoko.org/pipermail/community/2007-January/001947.html Derek Pressnall also expressed it well:]

''The reason is the same reason the device is being shipped with a given kernel (Linux), a given set of libraries (glibc, gtk), etc. So that when a developer writes an application, it will be known to be able to run on all shipped devices. So, in this light, it may be benificial to included a standard interpreted language that can be a known
target. ''

''The benefits to having an interpreter included (esp. one that has hooks into the gui and other phone functions) are that more apps will be made available -- there are more hackers that can code up quick scripts than ones that will learn & code for a specific gui accessible only from a compiled language. And, the benefit of having a particular interpreter is that when these little apps / scripts are packaged up, you don't have a dependancy nightmare (even though this can be somewhat mitigated by a good package management system, it is only as good as the backend repository, and having self-contained packages are the simplest of all). Also, by settling on a single standard, even if it is one that some developers may have to learn, it makes it more worthwhile to learn a new scripting environment that is widely deployed on your target platform. But for these same reasons, the interpreted language target will need careful consideration, lest we get stuck with something that doesn't adequetly meet most needs.''

''As a secondary issue, if the included interpreter is easily embeddable, then it would be nice to have it as the standard across all the included applets that can use it (i.e., it would be good if the email/sms client, phonebook manager, dialer, etc. were all scriptable).''

''But whatever is decided on (if a single language is picked), a function library should be developed for it that includes access to all the phone specific features (in addition to the gui hooks).''

[[http://lists.openmoko.org/pipermail/community/2007-January/001955.html and Ben Burdette:]]

''That's all well and good when everyone has SPACE for every scripting language known to man. But use 10mb here, 10mb there for scripting languages, and suddenly there's nothing left of my 64mb of flash. ''

''I'm all for allowing people to use whatever scripting language they want. But I'd like the peace of mind of knowing I can write a scripted app that will run on every OpenMoko phone out there, even if they have no memory expansion card. I don't want the situation where the poor user has to unload someone else's app and scripting environment in order to use mine, or vice versa. ''

Bryan Larsen adds:

''It'll be faster for me to develop my apps in Ruby-GTK2 and then port to C once the application stabilizes, since so much of the actual work involves playing with and discarding various ideas. Why should I have to go through the totally unnecessary step of transliterating my code into C just so it can be used by mainstream users? I don't really care if Ruby or Python or even Javascript is chosen, I just want something for rapid development that I can ship without translating!''

For all these reasons, a choice should be made, and it should be made quickly. A scripting language should be chosen and "blessed"; actual implementation on OpenMoko is a much lower priority as most people will likely be (or should be) prototyping their applications on a PC anyways.

== Factors to Consider ==

# '''How popular is it?''' The fewer people that need to learn a new language, the less whining we'll get on the list when it's chosen.
# '''How big is the run time environment?''' This is perhaps the most important question, since we are trying to fit into a very small fraction of the 64MB of space available in the OpenMoko ROM. We only need the run time environment; it is expected that developers will have a PC or microSD card to compile to the intermediate form used by the scripting language. It's also presumed that a stripped down, precompiled standard library will be included.
# '''Is it easy to learn?''' Assuming that the user has already learned some Algol influenced language, (ie pretty much every language in widespread current use except for Lisp and FORTRAN), how easy is it to learn?
# '''How advanced is it?''' We want to include a language that people will use. Specifically I'm going to look for "closures" and "meta-programming" as a measure of how "advanced" the language is. These are very arbitrary choices, but they are something I've found useful. If you have any other pet measures, let me know!
# '''Does it have bindings to GTK2, OpenMoko-libs and D-BUS?''' These three things will be required to write applications that look and feel like OpenMoko apps, as well as interact well with the built-in applications.
# '''How does it perform?''' Performance is usually not a major concern for a scripting language, but due to the limited horsepower available on phones, it is a concern.
# '''Is it embeddable?''' Traditionally in the Unix world, applications were small tools bound together by scripts and pipes. Traditionally in the Windows world, applications were huge monolothic beasts that were scriptable using a built-in scripting language such as Visual Basic for Applications. This model is also used in the Unix world, Emacs being the classic example. A hybrid model has emerged and become popular in modern Unix GUI's such as OSX, Gnome and KDE: applications expose a scripting friendly API via D-BUS, CORBA or Applescript so that external scripts can appear to act as internal scripts. If the scripting language chosen is easily embeddable, all three models become available on OpenMoko. It's expected that the third model will be the most popular, but the second model may have size/overhead advantages.
# '''What major applications of interest''' are available in the language and would be useful on OpenMoko?

== The Languages (already included) ==

=== BASH / Shell scripts ===

# already included, useful for most cases - [http://99-bottles-of-beer.net/language-bash-98.html example]
# Shell is a very popular scripting language.
# There will be a shell of some form available on OpenMoko, therefore it is "free".
# Shell is idiosyncratic, but all Unix developers know it in at least a very limited degree.
# Shell is a full language, but can hardly be compared to languages designed monolithically. :)
# D-BUS is usable from the command line. GTK2 may be used via [http://www.gtk-server.org/index.html gtk-server].

=== AWK ===

# already included, very powerful - [http://99-bottles-of-beer.net/language-awk-53.html example]

=== SED ===

# already included, useful together with bash / awk [http://99-bottles-of-beer.net/language-sed-1087.html example1],[http://www.student.northpark.edu/pemente/sed/sed1line.txt example2]

=== Javascript ===

# Javascript is a very popular scripting language because it's the defacto web user-side scripting language.
# Javascript will be available on whichever web browser is included in the project, therefore it is "free".
# Javascript has a straightforward C-style syntax. Core Javascript is actually a very nice language; it gets a bad rap because of inconsistencies in implementation and bugs in the various browsers.
# Closures are very popular in Javascript. Metaprogramming is possible; JSON is an example of a form of such.
# An incomplete set of bindings for GTK2 are [http://oss.mps.com.sg/GtkJavaScript available here.]. [http://www.gtk-server.org/index.html gtk-server] may be used instead if those bindings are insufficient.

== The Languages (not included) ==

''Warning: opinions ahead''

=== Lua ===

# Lua is a moderately popular scripting language popular in video games and in Brazil.
# It has a tiny footprint: 150K claimed, the run time environment takes up around 400K in OpenZaurus.
# Lua has a simple syntax and is easy to learn.
# It has first class closures. A fundamental building block of Lua is the ability to redefine any defined or undefined aspect of the language; this provides a basic metaprogramming ability. [[http://metalua.luaforge.net/ metalua] provides full metaprogramming, if such extremes are needed.
# Bindings are available for GTK2.
# Performance is very similar to Python or Perl
# It is very easy to embed.

=== Python ===

# Python is an extremely popular scripting language.
# By stripping down the standard libraries to the edge of usability, it can be made to fit within 1MB. (claim unverified). I suspect that 3MB is a more usable number.
# Designed as an educational language, it is easy to learn.
# It has closures, although they were a late addition to the language. Metaprogramming is very difficult.
# Bindings are available for GTK2 and D-BUS. GTK bindings are part of the Gnome project.
# Performance is good. Psyco can make it extremely good, but that is unlikely to be available to OpenMoko.
# Python can be embedded, although not trivially.
# OLPC uses Python heavily and may produce applications suitable for porting to OpenMoko

=== Ruby ===

# Ruby is a popular scripting language.
# Size is unknown, although comparable to Python, I suspect.
# Ruby is seen by many to be an excellent compromise between the terseness and power of Perl and the readability and ease of learning of Python.
# It has closures. Metaprogramming can be hairy, but Rails is an excellent example of the beautiful results it can acheive.
# Bindings are available for GTK2 and D-BUS.
# Performance is worse than Python or Perl in current versions, although the next version of Ruby is likely to be much better.

=== Perl ===

# Perl is an extremely popular scripting language.
# Sizewise, it is likely to be a little bit smaller than Python or Ruby.
# It is not generally considered an easy language to learn. This is probably mostly due to the idiosyncrasy of typical Perl programs. Perl is generally easier to write than to read or maintain, most other languages are the other way around.
# Perl has first class closures. Perl's metaprogramming abilities lie between that of Python and Ruby.
# Perl has existed for a considerable amount of time in comparison to other scripting languages, which means it is stable and boasts an extensive amount of third-party libraries/modules.
# Bindings are available to GTK2 and D-BUS. Gtk bindings are part of the GNOME project.

=== Lisp/Scheme/Guile ===

# There are a lot of Lisp variants available. It is the second oldest high-level programming language available, yet still retains moderate popularity for new projects.
# Lisp variants have been run on 16K computers. Usable variants are substantially larger, but will be significantly smaller than Python.
# Lisp syntax is very simple, and hated by many. :)
# Modern lisp variants are more "powerful" than every other language listed here.
# GTK2 and D-BUS bindings are available

=== Java ===

# Not a scripting language, but Java does offer garbage collection and a few features that make development slightly faster than C. A J2ME JVM is ubiquitous on competing cell phones so is likely to be included in OpenMoko for purely competitive reasons.
# A full J2ME implementation takes about 2 Megabytes of space. [http://developers.sun.com/techtopics/mobility/getstart/articles/survey/ (reading in between the lines here. I could be very wrong)]. However since it's likely to be included in the phone for other reasons it can be considered "free".
# Java is very C-like.
# Java is not a scripting language and doesn't support advanced scripting language features.
# libswt-gtk provides uses GTK2 to display SWT java apps, and libgtk-java provides a direct binding.

=== JRuby ===

# JRuby is a version of ruby that runs on the JVM. Jython is also available although it appears that JRuby is being more actively supported by Sun.
# If a JVM is on the phone, then JRuby is "free".
#
#
# JRuby can use the Java bindings to GTK2.

== Summary ==

If the space is available, the most popular choices will be Ruby and Python. Python is currently more popular, however Ruby is gaining ground fast. The choice between the two is political. Neither is wrong; you'll offend people making either choice. However, "both" is a very expensive option, so a choice will have to be made.

If the space is more limited, Lua and Scheme are probably the best choices. Unless your developers include a large number of grey-bearded Lisp hackers, Lua is probably the best choice. This may be unfortunate, but it is so.

If an appropriate amount of manpower is available to bring the bindings up to snuff, the "free" choice of Javascript may be the best choice of all.

JRuby is also an interesting choice. It's very likely that a J2ME JVM will be included in the standard installation for purely competitive reasons, so JRuby is very close to free with a little bit of work.

--[[User:Bryan Larsen|Bryan Larsen]] 21:44, 3 April 2007 (CEST)

[[Category:Ideas]]

Wishlist/BuiltInScriptingLanguage

2007-04-12T13:57:41Z

Placid: /* Perl */

{{Wishlist}}

== Discussion ==

[http://lists.openmoko.org/pipermail/community/2007-January/001909.html There was a discussion on the mailing list about choosing a built-in scripting language.]

Many different scripting languages will be optionally available in the repository. However, developers who choose one of these languages for their applications will not be able to see their applications included in the standard ROM nor available for use by those without an external microSD card.

[http://lists.openmoko.org/pipermail/community/2007-January/001945.html As expressed by Corey]:

''It's true that you have the ability to add anything to the phone.''

''There's another important consideration to remember: OpenMoko is a platform also; an inherent aspect of such a platform is that it always come shipped with X standard api's available for developers. This is why FIC had to select a group of components: gcc, glibc, xorg/kdrive, dbus and gtk, for instance.''

''They may decide that a scripting language would also be a necessary or beneficial feature to include in the base/standard platform''

...

''Choice is good.''

''And so is having a known/standard/default/static api and platform to build from; when I begin writting commercial and/or free software for the OpenMoko, I will design my software according the existing OpenMoko specs, and thereby circumvent the necessity of having to verify that my customers/end users have first installed the necessary scripting language, which would additionally circumvent the probability that your phone will end up with every scripting language known to man.''

''> So having lua on my system would be more or less pointless as I don't use it myself.''

''Less than one meg of space would be potentially wasted, true enough in your case. Know that there is probably plenty of other software on the OpenMoko platform that you, yourself, will not be using.''

''Also realize that though _you_ may not be directly using this hypothetical scripting language, it is more than likely that one or more of the standard apps that ship with the phone will be using it, and that other 3rd party software that you may or may not install may also be using it.''

[http://lists.openmoko.org/pipermail/community/2007-January/001947.html Derek Pressnall also expressed it well:]

''The reason is the same reason the device is being shipped with a given kernel (Linux), a given set of libraries (glibc, gtk), etc. So that when a developer writes an application, it will be known to be able to run on all shipped devices. So, in this light, it may be benificial to included a standard interpreted language that can be a known
target. ''

''The benefits to having an interpreter included (esp. one that has hooks into the gui and other phone functions) are that more apps will be made available -- there are more hackers that can code up quick scripts than ones that will learn & code for a specific gui accessible only from a compiled language. And, the benefit of having a particular interpreter is that when these little apps / scripts are packaged up, you don't have a dependancy nightmare (even though this can be somewhat mitigated by a good package management system, it is only as good as the backend repository, and having self-contained packages are the simplest of all). Also, by settling on a single standard, even if it is one that some developers may have to learn, it makes it more worthwhile to learn a new scripting environment that is widely deployed on your target platform. But for these same reasons, the interpreted language target will need careful consideration, lest we get stuck with something that doesn't adequetly meet most needs.''

''As a secondary issue, if the included interpreter is easily embeddable, then it would be nice to have it as the standard across all the included applets that can use it (i.e., it would be good if the email/sms client, phonebook manager, dialer, etc. were all scriptable).''

''But whatever is decided on (if a single language is picked), a function library should be developed for it that includes access to all the phone specific features (in addition to the gui hooks).''

[[http://lists.openmoko.org/pipermail/community/2007-January/001955.html and Ben Burdette:]]

''That's all well and good when everyone has SPACE for every scripting language known to man. But use 10mb here, 10mb there for scripting languages, and suddenly there's nothing left of my 64mb of flash. ''

''I'm all for allowing people to use whatever scripting language they want. But I'd like the peace of mind of knowing I can write a scripted app that will run on every OpenMoko phone out there, even if they have no memory expansion card. I don't want the situation where the poor user has to unload someone else's app and scripting environment in order to use mine, or vice versa. ''

Bryan Larsen adds:

''It'll be faster for me to develop my apps in Ruby-GTK2 and then port to C once the application stabilizes, since so much of the actual work involves playing with and discarding various ideas. Why should I have to go through the totally unnecessary step of transliterating my code into C just so it can be used by mainstream users? I don't really care if Ruby or Python or even Javascript is chosen, I just want something for rapid development that I can ship without translating!''

For all these reasons, a choice should be made, and it should be made quickly. A scripting language should be chosen and "blessed"; actual implementation on OpenMoko is a much lower priority as most people will likely be (or should be) prototyping their applications on a PC anyways.

== Factors to Consider ==

# '''How popular is it?''' The fewer people that need to learn a new language, the less whining we'll get on the list when it's chosen.
# '''How big is the run time environment?''' This is perhaps the most important question, since we are trying to fit into a very small fraction of the 64MB of space available in the OpenMoko ROM. We only need the run time environment; it is expected that developers will have a PC or microSD card to compile to the intermediate form used by the scripting language. It's also presumed that a stripped down, precompiled standard library will be included.
# '''Is it easy to learn?''' Assuming that the user has already learned some Algol influenced language, (ie pretty much every language in widespread current use except for Lisp and FORTRAN), how easy is it to learn?
# '''How advanced is it?''' We want to include a language that people will use. Specifically I'm going to look for "closures" and "meta-programming" as a measure of how "advanced" the language is. These are very arbitrary choices, but they are something I've found useful. If you have any other pet measures, let me know!
# '''Does it have bindings to GTK2, OpenMoko-libs and D-BUS?''' These three things will be required to write applications that look and feel like OpenMoko apps, as well as interact well with the built-in applications.
# '''How does it perform?''' Performance is usually not a major concern for a scripting language, but due to the limited horsepower available on phones, it is a concern.
# '''Is it embeddable?''' Traditionally in the Unix world, applications were small tools bound together by scripts and pipes. Traditionally in the Windows world, applications were huge monolothic beasts that were scriptable using a built-in scripting language such as Visual Basic for Applications. This model is also used in the Unix world, Emacs being the classic example. A hybrid model has emerged and become popular in modern Unix GUI's such as OSX, Gnome and KDE: applications expose a scripting friendly API via D-BUS, CORBA or Applescript so that external scripts can appear to act as internal scripts. If the scripting language chosen is easily embeddable, all three models become available on OpenMoko. It's expected that the third model will be the most popular, but the second model may have size/overhead advantages.
# '''What major applications of interest''' are available in the language and would be useful on OpenMoko?

== The Languages (already included) ==

=== BASH / Shell scripts ===

# already included, useful for most cases - [http://99-bottles-of-beer.net/language-bash-98.html example]
# Shell is a very popular scripting language.
# There will be a shell of some form available on OpenMoko, therefore it is "free".
# Shell is idiosyncratic, but all Unix developers know it in at least a very limited degree.
# Shell is a full language, but can hardly be compared to languages designed monolithically. :)
# D-BUS is usable from the command line. GTK2 may be used via [http://www.gtk-server.org/index.html gtk-server].

=== AWK ===

# already included, very powerful - [http://99-bottles-of-beer.net/language-awk-53.html example]

=== SED ===

# already included, useful together with bash / awk [http://99-bottles-of-beer.net/language-sed-1087.html example1],[http://www.student.northpark.edu/pemente/sed/sed1line.txt example2]

=== Javascript ===

# Javascript is a very popular scripting language because it's the defacto web user-side scripting language.
# Javascript will be available on whichever web browser is included in the project, therefore it is "free".
# Javascript has a straightforward C-style syntax. Core Javascript is actually a very nice language; it gets a bad rap because of inconsistencies in implementation and bugs in the various browsers.
# Closures are very popular in Javascript. Metaprogramming is possible; JSON is an example of a form of such.
# An incomplete set of bindings for GTK2 are [http://oss.mps.com.sg/GtkJavaScript available here.]. [http://www.gtk-server.org/index.html gtk-server] may be used instead if those bindings are insufficient.

== The Languages (not included) ==

''Warning: opinions ahead''

=== Lua ===

# Lua is a moderately popular scripting language popular in video games and in Brazil.
# It has a tiny footprint: 150K claimed, the run time environment takes up around 400K in OpenZaurus.
# Lua has a simple syntax and is easy to learn.
# It has first class closures. A fundamental building block of Lua is the ability to redefine any defined or undefined aspect of the language; this provides a basic metaprogramming ability. [[http://metalua.luaforge.net/ metalua] provides full metaprogramming, if such extremes are needed.
# Bindings are available for GTK2.
# Performance is very similar to Python or Perl
# It is very easy to embed.

=== Python ===

# Python is an extremely popular scripting language.
# By stripping down the standard libraries to the edge of usability, it can be made to fit within 1MB. (claim unverified). I suspect that 3MB is a more usable number.
# Designed as an educational language, it is easy to learn.
# It has closures, although they were a late addition to the language. Metaprogramming is very difficult.
# Bindings are available for GTK2 and D-BUS. GTK bindings are part of the Gnome project.
# Performance is good. Psyco can make it extremely good, but that is unlikely to be available to OpenMoko.
# Python can be embedded, although not trivially.
# OLPC uses Python heavily and may produce applications suitable for porting to OpenMoko

=== Ruby ===

# Ruby is a popular scripting language.
# Size is unknown, although comparable to Python, I suspect.
# Ruby is seen by many to be an excellent compromise between the terseness and power of Perl and the readability and ease of learning of Python.
# It has closures. Metaprogramming can be hairy, but Rails is an excellent example of the beautiful results it can acheive.
# Bindings are available for GTK2 and D-BUS.
# Performance is worse than Python or Perl in current versions, although the next version of Ruby is likely to be much better.

=== Perl ===

# Perl is a very popular scripting language.
# Sizewise, it is likely to be a little bit smaller than Python or Ruby.
# It is not generally considered an easy language to learn. This is probably mostly due to the idiosyncrasy of typical Perl programs. Perl is generally easier to write than to read or maintain, most other languages are the other way around.
# Perl has first class closures. Perl's metaprogramming abilities lie between that of Python and Ruby.
# Perl has existed for a considerable amount of time in comparison to other scripting languages, which means it is stable and boasts an extensive amount of third-party libraries/modules.
# Bindings are available to GTK2 and D-BUS. Gtk bindings are part of the GNOME project.

=== Lisp/Scheme/Guile ===

# There are a lot of Lisp variants available. It is the second oldest high-level programming language available, yet still retains moderate popularity for new projects.
# Lisp variants have been run on 16K computers. Usable variants are substantially larger, but will be significantly smaller than Python.
# Lisp syntax is very simple, and hated by many. :)
# Modern lisp variants are more "powerful" than every other language listed here.
# GTK2 and D-BUS bindings are available

=== Java ===

# Not a scripting language, but Java does offer garbage collection and a few features that make development slightly faster than C. A J2ME JVM is ubiquitous on competing cell phones so is likely to be included in OpenMoko for purely competitive reasons.
# A full J2ME implementation takes about 2 Megabytes of space. [http://developers.sun.com/techtopics/mobility/getstart/articles/survey/ (reading in between the lines here. I could be very wrong)]. However since it's likely to be included in the phone for other reasons it can be considered "free".
# Java is very C-like.
# Java is not a scripting language and doesn't support advanced scripting language features.
# libswt-gtk provides uses GTK2 to display SWT java apps, and libgtk-java provides a direct binding.

=== JRuby ===

# JRuby is a version of ruby that runs on the JVM. Jython is also available although it appears that JRuby is being more actively supported by Sun.
# If a JVM is on the phone, then JRuby is "free".
#
#
# JRuby can use the Java bindings to GTK2.

== Summary ==

If the space is available, the most popular choices will be Ruby and Python. Python is currently more popular, however Ruby is gaining ground fast. The choice between the two is political. Neither is wrong; you'll offend people making either choice. However, "both" is a very expensive option, so a choice will have to be made.

If the space is more limited, Lua and Scheme are probably the best choices. Unless your developers include a large number of grey-bearded Lisp hackers, Lua is probably the best choice. This may be unfortunate, but it is so.

If an appropriate amount of manpower is available to bring the bindings up to snuff, the "free" choice of Javascript may be the best choice of all.

JRuby is also an interesting choice. It's very likely that a J2ME JVM will be included in the standard installation for purely competitive reasons, so JRuby is very close to free with a little bit of work.

--[[User:Bryan Larsen|Bryan Larsen]] 21:44, 3 April 2007 (CEST)

[[Category:Ideas]]

Wishlist/BuiltInScriptingLanguage

2007-04-12T13:41:43Z

Placid: /* Perl */

{{Wishlist}}

== Discussion ==

[http://lists.openmoko.org/pipermail/community/2007-January/001909.html There was a discussion on the mailing list about choosing a built-in scripting language.]

Many different scripting languages will be optionally available in the repository. However, developers who choose one of these languages for their applications will not be able to see their applications included in the standard ROM nor available for use by those without an external microSD card.

[http://lists.openmoko.org/pipermail/community/2007-January/001945.html As expressed by Corey]:

''It's true that you have the ability to add anything to the phone.''

''There's another important consideration to remember: OpenMoko is a platform also; an inherent aspect of such a platform is that it always come shipped with X standard api's available for developers. This is why FIC had to select a group of components: gcc, glibc, xorg/kdrive, dbus and gtk, for instance.''

''They may decide that a scripting language would also be a necessary or beneficial feature to include in the base/standard platform''

...

''Choice is good.''

''And so is having a known/standard/default/static api and platform to build from; when I begin writting commercial and/or free software for the OpenMoko, I will design my software according the existing OpenMoko specs, and thereby circumvent the necessity of having to verify that my customers/end users have first installed the necessary scripting language, which would additionally circumvent the probability that your phone will end up with every scripting language known to man.''

''> So having lua on my system would be more or less pointless as I don't use it myself.''

''Less than one meg of space would be potentially wasted, true enough in your case. Know that there is probably plenty of other software on the OpenMoko platform that you, yourself, will not be using.''

''Also realize that though _you_ may not be directly using this hypothetical scripting language, it is more than likely that one or more of the standard apps that ship with the phone will be using it, and that other 3rd party software that you may or may not install may also be using it.''

[http://lists.openmoko.org/pipermail/community/2007-January/001947.html Derek Pressnall also expressed it well:]

''The reason is the same reason the device is being shipped with a given kernel (Linux), a given set of libraries (glibc, gtk), etc. So that when a developer writes an application, it will be known to be able to run on all shipped devices. So, in this light, it may be benificial to included a standard interpreted language that can be a known
target. ''

''The benefits to having an interpreter included (esp. one that has hooks into the gui and other phone functions) are that more apps will be made available -- there are more hackers that can code up quick scripts than ones that will learn & code for a specific gui accessible only from a compiled language. And, the benefit of having a particular interpreter is that when these little apps / scripts are packaged up, you don't have a dependancy nightmare (even though this can be somewhat mitigated by a good package management system, it is only as good as the backend repository, and having self-contained packages are the simplest of all). Also, by settling on a single standard, even if it is one that some developers may have to learn, it makes it more worthwhile to learn a new scripting environment that is widely deployed on your target platform. But for these same reasons, the interpreted language target will need careful consideration, lest we get stuck with something that doesn't adequetly meet most needs.''

''As a secondary issue, if the included interpreter is easily embeddable, then it would be nice to have it as the standard across all the included applets that can use it (i.e., it would be good if the email/sms client, phonebook manager, dialer, etc. were all scriptable).''

''But whatever is decided on (if a single language is picked), a function library should be developed for it that includes access to all the phone specific features (in addition to the gui hooks).''

[[http://lists.openmoko.org/pipermail/community/2007-January/001955.html and Ben Burdette:]]

''That's all well and good when everyone has SPACE for every scripting language known to man. But use 10mb here, 10mb there for scripting languages, and suddenly there's nothing left of my 64mb of flash. ''

''I'm all for allowing people to use whatever scripting language they want. But I'd like the peace of mind of knowing I can write a scripted app that will run on every OpenMoko phone out there, even if they have no memory expansion card. I don't want the situation where the poor user has to unload someone else's app and scripting environment in order to use mine, or vice versa. ''

Bryan Larsen adds:

''It'll be faster for me to develop my apps in Ruby-GTK2 and then port to C once the application stabilizes, since so much of the actual work involves playing with and discarding various ideas. Why should I have to go through the totally unnecessary step of transliterating my code into C just so it can be used by mainstream users? I don't really care if Ruby or Python or even Javascript is chosen, I just want something for rapid development that I can ship without translating!''

For all these reasons, a choice should be made, and it should be made quickly. A scripting language should be chosen and "blessed"; actual implementation on OpenMoko is a much lower priority as most people will likely be (or should be) prototyping their applications on a PC anyways.

== Factors to Consider ==

# '''How popular is it?''' The fewer people that need to learn a new language, the less whining we'll get on the list when it's chosen.
# '''How big is the run time environment?''' This is perhaps the most important question, since we are trying to fit into a very small fraction of the 64MB of space available in the OpenMoko ROM. We only need the run time environment; it is expected that developers will have a PC or microSD card to compile to the intermediate form used by the scripting language. It's also presumed that a stripped down, precompiled standard library will be included.
# '''Is it easy to learn?''' Assuming that the user has already learned some Algol influenced language, (ie pretty much every language in widespread current use except for Lisp and FORTRAN), how easy is it to learn?
# '''How advanced is it?''' We want to include a language that people will use. Specifically I'm going to look for "closures" and "meta-programming" as a measure of how "advanced" the language is. These are very arbitrary choices, but they are something I've found useful. If you have any other pet measures, let me know!
# '''Does it have bindings to GTK2, OpenMoko-libs and D-BUS?''' These three things will be required to write applications that look and feel like OpenMoko apps, as well as interact well with the built-in applications.
# '''How does it perform?''' Performance is usually not a major concern for a scripting language, but due to the limited horsepower available on phones, it is a concern.
# '''Is it embeddable?''' Traditionally in the Unix world, applications were small tools bound together by scripts and pipes. Traditionally in the Windows world, applications were huge monolothic beasts that were scriptable using a built-in scripting language such as Visual Basic for Applications. This model is also used in the Unix world, Emacs being the classic example. A hybrid model has emerged and become popular in modern Unix GUI's such as OSX, Gnome and KDE: applications expose a scripting friendly API via D-BUS, CORBA or Applescript so that external scripts can appear to act as internal scripts. If the scripting language chosen is easily embeddable, all three models become available on OpenMoko. It's expected that the third model will be the most popular, but the second model may have size/overhead advantages.
# '''What major applications of interest''' are available in the language and would be useful on OpenMoko?

== The Languages (already included) ==

=== BASH / Shell scripts ===

# already included, useful for most cases - [http://99-bottles-of-beer.net/language-bash-98.html example]
# Shell is a very popular scripting language.
# There will be a shell of some form available on OpenMoko, therefore it is "free".
# Shell is idiosyncratic, but all Unix developers know it in at least a very limited degree.
# Shell is a full language, but can hardly be compared to languages designed monolithically. :)
# D-BUS is usable from the command line. GTK2 may be used via [http://www.gtk-server.org/index.html gtk-server].

=== AWK ===

# already included, very powerful - [http://99-bottles-of-beer.net/language-awk-53.html example]

=== SED ===

# already included, useful together with bash / awk [http://99-bottles-of-beer.net/language-sed-1087.html example1],[http://www.student.northpark.edu/pemente/sed/sed1line.txt example2]

=== Javascript ===

# Javascript is a very popular scripting language because it's the defacto web user-side scripting language.
# Javascript will be available on whichever web browser is included in the project, therefore it is "free".
# Javascript has a straightforward C-style syntax. Core Javascript is actually a very nice language; it gets a bad rap because of inconsistencies in implementation and bugs in the various browsers.
# Closures are very popular in Javascript. Metaprogramming is possible; JSON is an example of a form of such.
# An incomplete set of bindings for GTK2 are [http://oss.mps.com.sg/GtkJavaScript available here.]. [http://www.gtk-server.org/index.html gtk-server] may be used instead if those bindings are insufficient.

== The Languages (not included) ==

''Warning: opinions ahead''

=== Lua ===

# Lua is a moderately popular scripting language popular in video games and in Brazil.
# It has a tiny footprint: 150K claimed, the run time environment takes up around 400K in OpenZaurus.
# Lua has a simple syntax and is easy to learn.
# It has first class closures. A fundamental building block of Lua is the ability to redefine any defined or undefined aspect of the language; this provides a basic metaprogramming ability. [[http://metalua.luaforge.net/ metalua] provides full metaprogramming, if such extremes are needed.
# Bindings are available for GTK2.
# Performance is very similar to Python or Perl
# It is very easy to embed.

=== Python ===

# Python is an extremely popular scripting language.
# By stripping down the standard libraries to the edge of usability, it can be made to fit within 1MB. (claim unverified). I suspect that 3MB is a more usable number.
# Designed as an educational language, it is easy to learn.
# It has closures, although they were a late addition to the language. Metaprogramming is very difficult.
# Bindings are available for GTK2 and D-BUS. GTK bindings are part of the Gnome project.
# Performance is good. Psyco can make it extremely good, but that is unlikely to be available to OpenMoko.
# Python can be embedded, although not trivially.
# OLPC uses Python heavily and may produce applications suitable for porting to OpenMoko

=== Ruby ===

# Ruby is a popular scripting language.
# Size is unknown, although comparable to Python, I suspect.
# Ruby is seen by many to be an excellent compromise between the terseness and power of Perl and the readability and ease of learning of Python.
# It has closures. Metaprogramming can be hairy, but Rails is an excellent example of the beautiful results it can acheive.
# Bindings are available for GTK2 and D-BUS.
# Performance is worse than Python or Perl in current versions, although the next version of Ruby is likely to be much better.

=== Perl ===

# Perl is a very popular scripting language, although that popularity appears to be waning.
# Sizewise, it is likely to be a little bit smaller than Python or Ruby.
# It is not generally considered an easy language to learn. This is probably mostly due to the idiosyncrasy of typical Perl programs. Perl is generally easier to write than to read or maintain, most other languages are the other way around.
# Perl has first class closures. Perl's metaprogramming abilities lie between that of Python and Ruby.
# Perl has existed for a considerable amount of time in comparison to other scripting languages, which means it is stable and boasts an extensive amount of third-party libraries/modules.
# Bindings are available to GTK2 and D-BUS. Gtk bindings are part of the GNOME project.

=== Lisp/Scheme/Guile ===

# There are a lot of Lisp variants available. It is the second oldest high-level programming language available, yet still retains moderate popularity for new projects.
# Lisp variants have been run on 16K computers. Usable variants are substantially larger, but will be significantly smaller than Python.
# Lisp syntax is very simple, and hated by many. :)
# Modern lisp variants are more "powerful" than every other language listed here.
# GTK2 and D-BUS bindings are available

=== Java ===

# Not a scripting language, but Java does offer garbage collection and a few features that make development slightly faster than C. A J2ME JVM is ubiquitous on competing cell phones so is likely to be included in OpenMoko for purely competitive reasons.
# A full J2ME implementation takes about 2 Megabytes of space. [http://developers.sun.com/techtopics/mobility/getstart/articles/survey/ (reading in between the lines here. I could be very wrong)]. However since it's likely to be included in the phone for other reasons it can be considered "free".
# Java is very C-like.
# Java is not a scripting language and doesn't support advanced scripting language features.
# libswt-gtk provides uses GTK2 to display SWT java apps, and libgtk-java provides a direct binding.

=== JRuby ===

# JRuby is a version of ruby that runs on the JVM. Jython is also available although it appears that JRuby is being more actively supported by Sun.
# If a JVM is on the phone, then JRuby is "free".
#
#
# JRuby can use the Java bindings to GTK2.

== Summary ==

If the space is available, the most popular choices will be Ruby and Python. Python is currently more popular, however Ruby is gaining ground fast. The choice between the two is political. Neither is wrong; you'll offend people making either choice. However, "both" is a very expensive option, so a choice will have to be made.

If the space is more limited, Lua and Scheme are probably the best choices. Unless your developers include a large number of grey-bearded Lisp hackers, Lua is probably the best choice. This may be unfortunate, but it is so.

If an appropriate amount of manpower is available to bring the bindings up to snuff, the "free" choice of Javascript may be the best choice of all.

JRuby is also an interesting choice. It's very likely that a J2ME JVM will be included in the standard installation for purely competitive reasons, so JRuby is very close to free with a little bit of work.

--[[User:Bryan Larsen|Bryan Larsen]] 21:44, 3 April 2007 (CEST)

[[Category:Ideas]]