dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Re: Rockbox scripting language (was: Cron job on Rockbox & FLAC recording)

Re: Rockbox scripting language (was: Cron job on Rockbox & FLAC recording)

From: Daniel Stenberg <>
Date: Thu, 22 Jun 2006 09:43:06 +0200 (CEST)

On Thu, 22 Jun 2006, RaeNye wrote:

> Several scriptable elements currently exist (WPS, .cfg files -- including
> themes) but a more powerful language will enable RB to do much more,
> including:

This would require some rather drastic changes.

> - scheduled tasks (much more than "sleep after 10 idle minutes")

... and it would require that we can start scripts (in the background) on a
given time.

> - configurable menus and button assignment. This needs some basic redesign,
> but once we move to generic events (i.e., MENU_BACK instead of #ifdef ....
> BUTTON_XXX) it's rather simple

... and it would require that we run scripts for each button, or at least
allow scripts to be run that way.

> - much richer WPS options (no more "you need these 7 specialized patches to
> run this WPS")

Are you suggesting the WPS screen would be drawn with the help of a scripting
language then? It would certainly make them a lot harder to make for the
average user.

Also, I would expect that to be more resource hungry both in terms of memory
and CPU (== less run-time).

> I suggest lua (, OS and free for all uses, last version: 5.02)
> which combines powerful structure (OOP, functional programming, etc.) with a
> low memory footprint (on x86: 100K/lua core, 100K/std. library - less than
> most codecs).

If we would, it could hardly run on Archos and then we need to maintain
ability to run Rockbox entirely without this scripting option.

> To compile this we mostly need some dynamic memory allocation scheme
> (realloc() -compatible)

Ugha. But sure, if this scripting idea is deemed to be a super-good idea, we
could of course provide a tiny little memory pool and malloc to be used by the
scripting language only.

> (I *will* ignore comments mentioning the feature freeze or version 3.0)

Let me put it this way instead:

By not working on fixing the actual current problems we have and instead
working on new post-3.0 features, we'll just get a longer feature freeze

  Daniel Stenberg -- --
Received on 2006-06-22

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy