Re: Online Help in eLua?

Posted by Dado Sutter on
URL: http://elua-development.15.s1.nabble.com/Online-Help-in-eLua-tp2456949p2457076.html

Hello,
   I had thought about a "help module" once. It would not depend on modules's metatables (to be implemented by each new module) but would be a separate module and have something like your help() function.
   The problem is that, with our current main target boards, we just can't affoard so much ram and even flash. (Remember, some crazy guys are talking seriously about eLua on 8 bits :)
   If architectured as an optional module, it could be interesting to have in the next generation of chips/boards, that promisse to come with plenty of space to play with. (they are actually out there already ! :)
   We also want to concentrate the doc in a single place and the move we've made (comming on v0.6) to webbook proves that. But not all the project's "doc" is related to the modules, their functions or even the code implementation. This would be more of a "Reference Manual", which is one of the sections of the new "site/doc".
   I'm not sure if Bogdan will care too much about documenting the core code, other than keeping it clear and "self-documented". But it will be nice to hear some more opinions on this too.
   Thanks for the thread Snyder.

Best
Dado

On Tue, Mar 10, 2009 at 15:17, James Snyder <[hidden email]> wrote:

I'm not suggesting this for the current release, but I was playing around with enumerating the tables for our hardware modules and it gave me a thought.

Is there a plan or interest in using metatables to provide simple help information for module methods?  I know something like this could always quickly grow into something that consumes many kilobytes of space, but what about just optional really short descriptions, like the following:

> help(adc.setclock)
setclock( id, clock, [timer_id] ) -- set clock and timer_id for channel id

or even just the parameter list:
> help(adc.setclock)
setclock( id, clock, [timer_id] )

Doing some sort of programmatic generation of the list, I think, would be key to make it maintainable.

Maybe this could even be extended so that the documentation could be kept inline in the module source and have a script that will take take these elements and populate the webbook docs.

Just a thought :-)   I like the idea of only having to update documentation in one place and have it be usable in multiple contexts.  I'm not thinking it should be too rigid or have a million fields that need to be populated, more something that is as simple as possible.

--
James Snyder
Biomedical Engineering
Northwestern University
[hidden email]
http://fanplastic.org/key.txt

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev