[syslinux] Lua.c32 wiki page

[Dag Wieers]

On Tue, 10 Aug 2010, Marcel Ritter wrote:

>  Am 09.08.2010 23:37, schrieb Dag Wieers:
>>  On Mon, 9 Aug 2010, Marcel Ritter wrote:
>>
>>  The examples make it very obvious how to use lua.c32 so I hope this will
>>  creation some traction within the community.
-snip-

>>  On the other hand the usage of some of the functions and the lack of
>>  consistency of the function names, make me realize we can do a better job
>>  before people start to rely on it.
>>
>>  I would propose to:
>>
>>  - change functions that return a fixed value and do not require arguments
>>     into values (avoid the function-call)
>>       eg. syslinux.version vs syslinux.version()
>
> Ok - I'll have to look into this.
> Creating lua functions seems to be better documented than an
> simple variable assignment  :-)

Haha, as usual they skip the "easy" stuff :-)


>>   - change functions that return a table and not require arguments into
>>     real tables (avoid the extra assignment and function-call)
>>       eg. dmi.table vs dmi.gettable()
>
> One thing I don't like about this is:
> If I get it right, to assign a variable the code necessary will have
> to be executed on every start of the lua interpreter, even if the
> return value is never used. The above example is relatively
> heavy and may cause trouble on some machines.
> I think this solution is ok for simple assignments like syslinux.version,
> but we might get into trouble doing that for all kind of functions.

I agree with you, on the other hand if these were seperate packages, 
people that load the dmi package probably want the content of the table 
anyway. So maybe we should move the functionality into seperate packages 
so people can load the modules they need. And the modules provide the 
variables and functions in the most convenient format.


>>   - make functions more consistent, now some use underscores (local_boot,
>>     run_kernel, load_background) vs no underscores (loadfile, getmodes())
>
> Is there a coding style to define those things for syslinux/lua?
> I just took whatever came to my mind - feel free to change them
> to whatever you like.

I just wanted to raise the issue, from a functional point of view my 
critisism is void. I would try to stick to what is being done for lua 
internal functionality so that it feels very much integrated with the 
language. (One of the things I hate with PHP ;-))


>>   - some functionality does not seem syslinux specific (filename, filesize)
>
> If I recall correctly I needed those options because I wanted to
> use the existing com32 functions, instead of copying code to
> a second location.

Right, the functionality definitely has its place. I was just wondering 
whether the functions could live in some other module. Maybe:

 	file.filename()
 	file.filesize()
 	file.loadfile()


>>   - some functions can be merged (sleep, msleep)
>
> I didn't find the mail concerning this, but I think I did only one of them.

>From scanning the modules I noticed both are available and I just 
tested this, both also do work !


>>   - some functions have questionable (confusing?) names (boot_it,
>>     boot_linux, run_command, run_kernel_image)
>
> I know - I hat quite some trouble to get a kernel booting at all, the
> last thing I was thinking about was proper function names, sorry.

>From the usage in the documentation it is not all clear to me what each 
does.

  - boot_it()
  - boot_linux(kernel, cmdline, [mem_limit], [videomode])
  - final_cleanup()
  - local_boot()
  - run_command(cmd)
  - run_default()
  - run_kernel_image(kernel, cmdline, ipappend_flags, type)

Maybe Peter has a good naming-convention for this ?


>>  If we want to do it right, now is the time.
> 
> That's right, I guess at the moment there are only very few people
> aware of lua in syslinux, and even less are using it already.

Maybe I should not have created the wiki page, then ;-)

Although some of the c32 modules are trivially reimplemented as 
lua-scripts, and the ones that cannot are likely using some functionality 
we need to add to lua. Maintaining it as lua-scripts is likely going to 
get more people involved and improve them.


Despite all the "criticism", thanks again for your Lua contributions. The 
wealth of possibilities for mere mortals like me is scary...

-- 
--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]