iLiad ANNOUNCE: Lua5.1 package for Iliad

[ericshliao]

I have one question: why the loading time of C apps (without modifying registry.xml) much longer than Lua?

I found one weird problem. My C apps, if not integrated into registry.xml, will take much long loading time (may over one minute), and LED will keep flashing if not manually stopped. Lua script, even without modifying registry.xml, it only takes about ten seconds to load, and LED won't flash. Why the difference? Any ideas?

[hansel]

Originally Posted by ericshliao

I have one question: why the loading time of C apps (without modifying registry.xml) much longer than Lua?

Lua is not only cool, it's also fast

Seriously, it must be something in the way your app is coded. I did a small C gtk app once, it started in 7-8 seconds.

Some ideas and guesses:

• Do you use xx in both cases? xx turns the led off when started...
• If your app has items with a cursor: disable cursor blinking! With xedpmgr or xx this causes many display updates (eats a lot of cpu ( and battery)). This is handled automatically in the lgob-iliad package for GtkEntry an GtkTextview. The code is:
  
  

    // ptr is a pointer to a   GtkEntry an GtkTextview  
          GtkSettings* settings = gtk_widget_get_settings(ptr);
          g_object_set(settings, "gtk-cursor-blink", (int)FALSE, NULL);

PS: xx has an option to delay the display refreshing: when you do 'myapp | xx -p -s6 ' , the refreshings starts after 6 seconds, possibly avoiding some needless refreshes while myapp is starting...

[ericshliao]

Thanx for the detailed instructions.
1. As to the flashing LED, I can imagine that xx suppresses LED. I also remember that xepdmgr has the similiar code. Maybe my memory serves me wrong.
2. I will try to disable cursor blinking later. To make the problem more clear, I have an example. When I port FBReader to iLiad, if I modify registry.xml to integrate FBReader, FBReader can be launched in about 30 seconds. If registry.xml not modified, it takes about two minutes or longer for FBReader to launch.

[hansel]

Some (educated ) guesses... During a 'normal start', contentlister starts a shell to run a script (run.sh), which starts your app. When using the registry, contentlister does a fork(), followed by an execvp() of your application (no shell involved). With execvp() lots of process resources (such as open files) are kept open. It could be (not sure about this) that shared libraries are still attached to the process causing the new excutable to load (= dynamic linking) faster.
EDIT 18 nov: this is probably not correct?

PS: This gives me a cool idea: if I add the Lua interpreter to contentlister (I've been planning this for a long time), and 'preload' lgob (including the gtk libs, which is already available in contenlister), then it should be possible to start Lua apps and tools very quickly...

A Lua enabled contentlister would also be much easier to modify / extend...

[Iñigo]

Originally Posted by hansel

PS: This gives me a cool idea: if I add the Lua interpreter to contentlister (I've been planning this for a long time), and 'preload' lgob (including the gtk libs, which is already available in contenlister), then it should be possible to start Lua apps and tools very quickly...

A Lua enabled contentlister would also be much easier to modify / extend...

I'm designing / thinking on a new content lister from some time ago.
First I'm going to release a simple file manager (Fedora 12 has been announced today so it won't be as soon as I thought ).

I have lot of ideas but as I would use some of the features I'm testing in this file manager I prefer waiting for your comments.

Btw, a Lua question:
I have some options in the file "program.ini" (f.e. "OPTION1 = true\nOPTION2 = false ..."). Is there a simple way to read this file using "loadfile" or similar and get a table with those options without parsing the file line by line
=> opts = { OPTIONS1 = true, OPTIONS2 = false, ... }, opts been a table defined in _G from the calling code?

Iñigo

[ericshliao]

Originally Posted by Iñigo

Btw, a Lua question:
I have some options in the file "program.ini" (f.e. "OPTION1 = true\nOPTION2 = false ..."). Is there a simple way to read this file using "loadfile" or similar and get a table with those options without parsing the file line by line
=> opts = { OPTIONS1 = true, OPTIONS2 = false, ... }, opts been a table defined in _G from the calling code?

Iñigo

Glib privodes a "Key-value file parser". See here: http://library.gnome.org/devel/glib/...le-parser.html

[hansel]

Originally Posted by ericshliao

Glib privodes a "Key-value file parser". See here: http://library.gnome.org/devel/glib/...le-parser.html

Those are cool functions, but they are not in Lgob (yet)

Personally I prefer to store settings in xml file (that's what always do at work). If you choose to store values in attributs (not in tags) (like <Opts option1='true' option2='false'/>), then converting Lua (nested) hashes to and from xml is quite simple...

[Iñigo]

Excuse me for the silence, too much work these days...

Originally Posted by hansel

Those are cool functions, but they are not in Lgob (yet)

Personally I prefer to store settings in xml file (that's what always do at work). If you choose to store values in attributs (not in tags) (like <Opts option1='true' option2='false'/>), then converting Lua (nested) hashes to and from xml is quite simple...

Well, I don't like XML so much, I usually prefer simpler solutions, like =pair values or JSON.

For the record, here you have the code I'm finally using:

local buf = "OPT1 = 1,OPT2 = 2"
local txt = "{\n"
for k, v in buf:gfind("([^%s]+)%s*=%s*([^\n]+)") do txt = txt .. k .. " = " .. v .. ",\n" end
txt = txt:sub(1, -3) .. "\n}"
print(txt)
print("***************************************************************************")
r = assert(loadstring("return " .. txt))
pr(r())

A simple loadstring should also work, but I prefer this implementation in order to catch malformed configuration file.

[hansel]

Originally Posted by Iñigo

Well, I don't like XML so much, I usually prefer simpler solutions, like =pair values or JSON.

I agree that JSON is 'nicer' than XML (easier to read and edit for humans). But apart from the syntax JSON and XML are almost the same thing (for configuration purpose). Both JSON and XML are much more powerful than plain ini files because the allow you to store structured data.

There are JSON implementations for Lua, like http://json.luaforge.net/ (I did not try it)