Page 1 of 5 123 ... LastLast
Results 1 to 10 of 49

Thread: Could Plugins be written in LUA?

  1. #1
    Join Date
    Jun 2002
    Location
    Tokyo
    Posts
    391

    Default Could Plugins be written in LUA?

    Hi,

    I have a standard library of functions written in LUA for the NetRemote project. I load the library by using the OnLoad, OnPluginEnable and OnScriptReset events. However this does confuse users a lot (e.g. when they first add my GML to their GML the code is not executed). It also means that my functions must be loaded at the top of the GML.

    My thought was whether it would be possible to have Girder Plugins written in LUA?

    My idea goes something like this:

    On startup Girder looks for *.lua in the plugins directory and loads each file.

    If more control is needed, each file could implement two functions FILENAME_Enable() and FILENAME_Disable() to allow the plugin menu to configure them. I assume we would need to use FILENAME to avoid namespace clashes.

    Any thoughts? I know this is not as manly as writing propper C++ plugins, but sadly I don't have the development environment available to me.

    Gavin

  2. #2
    Join Date
    Feb 2001
    Location
    Plano, TX, USA
    Posts
    3,055

    Default

    To get this type of support directly in Girder requires changes by Ron so I can't comment on whether that is possible.

    However, a plugin could be written to support what you are asking for. Parsing a text file for the routines "FILENAME_Enable()" and "FILENAME_Disable()" would be a pain. What if the *.LUA files were each executed by the plugin once for the enable, reset and disable events and a variable (GIRDERSTATE?) would contain the reason why the script is running? Would that be sufficient?

    I'm not clear on what, exactly, you expect to get out of this. Do you expect an ordering of the LUA files? (this one executes before that one) Or is this simply a way to make sure the scripts are executed without an ordering requirement?

    What I've outlined above (without an ordering requirement) is probably not very hard. If this is what you want, I could work on it in the next few days.
    Mark F

  3. #3
    Join Date
    Jun 2002
    Location
    Tokyo
    Posts
    391

    Default

    Mark,

    That non-ordered solution would be great. My only aim is to provide users access to an API of LUA calls without the workings of the API getting in their way. I was just trying to think of generic LUA solutions.

    One more thought. Would it be possible to also parse the plugin (script) when an event occurs? I guess this depends on how fast the LUA code is. Is it interpreted, or is their a bytecode compiled? If it's compiled once, and then able to be executed many times, that would speed things up?

    Cheers,

    Gavin

  4. #4
    Join Date
    Feb 2001
    Location
    Plano, TX, USA
    Posts
    3,055

    Default

    LUA code is interpreted. Girder provides facilities for plugins to pre-compile this into bytecode to allow faster execution for repeated use routines.

    The serial plugin supports LUA event handlers (scripts that are executed when a serial event occurs). These handlers are pre-compiled into bytecode and held in memory.

    Doing this for a generic case is possible.

    This is my current thinking:

    The plugin will execute all files matching "./lua/*.lua" when it receives a GirderEnable event.

    The plugin will export two routines - AddEventHandler() and RemoveEventHandler()

    AddEventHandler() - Adds a LUA event handler for a specified event. The handler will be read from a file, pre-compiled and saved in memory. It will return an indicator for failures. It will take 3 parameters:
    DeviceID - device ID to match (-1 = ALL)
    EventString - event string to match ("" = ALL)
    FileName - filename of LUA event handler

    RemoveEventHandler() - Removes a previously added LUA event handler. It will return an indicator for failures. It will take 3 parameters which must match the AddEventHandler() call exactly:
    DeviceID - device ID to match
    EventString - event string to match
    FileName - filename of LUA event handler

    Multiple calls to the AddEventHandler() routine with identical parameters causes a re-compile of the event handler code from the file.

    All data is dynamic (nothing saved in the registry).

    When an event handler gets control, the LUA environment will be the same as if it were called during a Girder Variable Manipulation Script command. (EventString, EventDeviceID, pldX will be valid)

    How does this sound?
    Mark F

  5. #5
    Join Date
    Jun 2002
    Location
    Tokyo
    Posts
    391

    Default

    Mark

    This is sounding great!! I think it can open the way to a lot of light-weight plugin solutions.

    One thing about the Add/RemoveEventHandler() - You suggest that it takes a file name as the third arguement. This could run into trouble if the filename is *.lua. I also think it would be more elegant if this was a function name (or a sting representing a function name) - this gives the developper the choice of having all his functions and events in one file, or many.

    I guess the issue is, can Girder call named LUA functions on events. This sound like what the serial plugin is doing.

    Cheers,

    Gavin

  6. #6
    Join Date
    Feb 2001
    Location
    Plano, TX, USA
    Posts
    3,055

    Default

    The serial plugin has a single LUA script for each event. It doesn't call a specific LUA routine name.

    The plugin will provide three interfaces - AddEventHandlerName(), AddEventHandlerFile() and RemoveEventHandler().

    AddEventHandlerFile() and RemoveEventHandler() work as in the previous post with the exception that the third parameter to RemoveEventHandler() is a handler name (file or routine). I don't plan on supporting wildcards (ie. *.lua) for the filenames.

    AddEventHandlerName() - Adds a named LUA function as the event handler for a specified event. It will return an indicator for failures. It will take 3 parameters:
    DeviceID - device ID to match (-1 = ALL)
    EventString - event string to match ("" = ALL)
    FunctionName - LUA function name of the event handler

    The named function must be added to the global function pool by some other means.

    RemoveEventHandler() can remove either type of event handlers.
    Mark F

  7. #7
    Join Date
    Jun 2002
    Location
    Tokyo
    Posts
    391

    Default

    Mark,

    Thanks!! This sounds perfect to me.

    My one emphasis on the use of function name (a string) rather than function (a LUA pointer to some code) is that since we can't predict the order of plugin loading, we can't guarantee that the function pointer will be defined. The name acts as a "soft reference" (sorry Perl speak!) in case a user wants to call a function in another plugin which hasn't been loaded yet. .... but then you probably knew this anyway.

    So in use it would look like

    AddEventHandlerName(-1,"some_event","some_event_handler")

    Cheers, Gavin

  8. #8
    Join Date
    Feb 2001
    Location
    Plano, TX, USA
    Posts
    3,055

    Default

    Okey-Dokey! I'll let you know when I have something to test.
    Mark F

  9. #9
    Join Date
    Feb 2001
    Location
    Plano, TX, USA
    Posts
    3,055

    Default

    I have completed the first beta of the plugin that does this stuff.

    Please download, test and comment.

    The .zip file includes a readme but no examples.
    Mark F

  10. #10
    Join Date
    Jun 2002
    Location
    Tokyo
    Posts
    391

    Default

    Mark,

    That was fast!!

    I gave it a try and the plugin loaded fine (Win2k, Girder 3.2.7b FYI). It also appears to be executing any code in the *.lua fine. Both on load and after reset.

    However I'm having a bad time with the AddEventHandlerName() call. I have the following:

    Code:
    function ExampleEvent() 
         print("Hello World")
         return 1
    end
    
    AddEventHandlerName(-1, "", "ExampleEvent")
    return 1
    In a file. On reset I get:

    error: attempt to call a nil value
    Any ideas? Am I doing something stupid?

    Thanks again for all your help.

    Gavin

Page 1 of 5 123 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •