Help With Lua scripts.

[Gimbal]

Please can you provide some light on to the following.

1) I cannot call the TIME_sleep function for a LUA script.
2) LUA strfind does not seem to be recognised in the LUA script with Girder.
3) If I have a repeat until LUA script I can read upto the very last line of text written to a log file. The log file being open in read append mode by the main application and the LUA script opening it in read mode only. However, if I have a multigroup and replace the repeat until with three commands I cannot seem to read the new data written to the file. The first command reads a line and prints it, the second command is a window wait command of 250ms and, the third is a goto the first command. However Girder just sits there.
4) Does Girder finish processing a multigroup before processing another separate command in a different group. The reason I ask is the main multigroup has a goto command at the end.


Thanks again,

Robert

Any help will be greatful recieved.

[Mark F]

1) What error are you getting when calling the TIME_Sleep() function? Do you have the S capitalized? I only ask since your post doesn't.
2) Using Girder 3.2.6 pre6 from the download page, strfind("hello", "ell") returns 2, 4. Something else must be going on.

4) Girder processes all commands in a mutigroup in order. The GoTo command is treated as a subroutine or function call.

[Gimbal]

Sorry Guys, as I except you are fed up with my posts. But I am still having several problems with trying to get Girder to do what I require. So this post recaps what I am trying to achieve, what I have done, what problems I have currently, questions about resolving them, and what would be nice to make this type of project easier to do with Girder.
It might even be that what I am trying to do is just not possible to do solely with Girder at present, and only possible with the use of an external program.
Again I like to thank everyone who as posted and helped out. Especially Mark and Ron.


Again, some of this may already be supported but due to my ignorance of Girder and LUA I have not yet found out how to do it. Or due to sleep deprivation last nigth I was hallucinating.

Objective.
To create a Girder project that will process a text log file. The log file at time of execution of the Girder project may not exist, may exist but be closed, may exist and being written to by another application.
The project would read the all the lines of text in the log file until the end of the file and then wait for a new line text to be written to the file. Once a new line of text as been written the project would read this text line and then trigger a command depending upon the text before going back and waiting for a new line of text to be written. Either a command trigger would disable the project based on text read from the file or on disabling the project.

Method 1 – Attempt 1
I created a command that was triggered upon enabling Girder. The command was a LUA script that executed until Girder was disabled or upon the correct exit text being read from the file.

Issues
1) LUA seemed to hang Girder. As from the previous posts here http://www.girder.nl/phpBB2/viewtopic.php?t=2897, it was down to the fact that LUA was run on the same thread as Girder. Meaning it was not passing control back to Girder to process any other commands. Trying to unload Girder or disable led to critical errors being reported, failed to unload plugins. Probably down to the LUA script still being executed.
Solution: new approach to implement objective as current method not possible with Girder.

2) Could not read new lines of text from the log file, although they were seen when the log file was open using Notepad.
Solution: Add the flush command to LUA script just before read of new line from log file. However, this seemed to be a ugly solution.


Method 2 – Attempt 2
I use the timed server but abandoned after several attempts to implement.

Issues
1) The time server plugin could only be set to trigger down to 1s which would mean a back log of text lines in the log file would build up. Could not get the repeatedly function to work correctly.
Solution: Set the trigger time for 0s. Which gave triggered an event approximately every 0.5s. This was just about acceptable.
2) Could not disable of enable timeserver event to stop processing using the disable command or stop the group of executing.
Solution: None found. Probably down to ignorance on my behalf.


Method 3 – Attempt 3
I went back to solution 1 and broke down into several commands (multigroups) executing smaller parts segments of the original LUA script. I managed to open the log file and read to the last line of text and then became stuck.

Issues
1) Learning the lessons from attempt I and did not want to hang Girder again by using repeat loops in LUA script that wasted a lot of time waiting for the text to be written to file. Thus not hanging Girder. So I created a multigroup that with the first command reading a line of text from the log file. If a text line was read from the log file the LUA script would then trigger the appropriate command using the TriggerEvent function of LUA. If no new text had read, result of readfile was nil, then LUA script exited. The two commands that followed were a windows wait command for 250ms and then a goto command to the read line command. Unfortunately no new lines of text was read from the log file. Although they could be seen when the log file was opened in Notepad once more.
Solution attempt 1: Add the flush command before the read line of text. This seems to have no effect. Gut feeling is that the wait command is causing the variables define in previous LUA scripts to be cleared. Need to investigate.
Solution attempt 2: Remove the wait command and replace with repeat loop and Mark F’s function “TIME_Sleep” function. The script would compile but upon running would report “TIME_Sleep” being called with a nil value. I had included Mark’s plugin and called the function by “TIME_Sleep (50)” and “TIME_Sleep (delay)” where delay was set to 50 in a previous LUA script. Could not resolve the issue so tested solution 3, which is not intend as a solution but more as test to check that it was to do with the LUA script. Again, being late a night I need to check that I typed the function call in correctly - with a capital S ops:
Solution attempt 3: Resorting to the repeat loop with the flush command before the readfile call in LUA. This allowed me to read new lines of text from the log file but not to process trigger event as I was hanging Girder in the script. Hoping to solve this issue by either solution 1 or 2 or my reopening the file every time and reading the last line and comparing to the previous last line read. Not an ideal solution.
2) With reference to issue 1 the “strfind” function in LUA did not work correctly as if the definition was missing.
Intended solution: None are present.
3) Girder command “if file exists”. It seems that if the file exists and is already opened to be appended the command returns file does not exist.
Intended solution: Incorporate this into LUA script.

Questions
1) Is it possible for Girder to learn an I/O function trigger event such as an application writing to a log file?
2) In a multigroup command sequence that contains an LUA script within which trigger events are initiated via the TriggerEvent function, when is the command associated to the triggers event executed. When I finish the current command of when I finish all the commands within that multigroup?
3) How do I pass variables from the LUA script into Girder variables. From previous posts I can use pld1 to pldx variables but I cannot guarantee that these will not be corrupted. Are there any ways of creating Girder variables that I can us to store critical LUA variables and store them just before the LUA script ends and restore then as required in other LUA scripts?


Wish List
1) The ability to run a background LUA script that could TriggerEvents and then call a new function to get Girder to process the events. Once the events have been processed Girder would return to the LUA script. If this option was to be implement then a control flag could be used to disable LUA scripts in Girder commands, one or the other option.
2) A Girder function called added to LUA which when called would allow Girder to all other trigger events. The command trigger could not contain LUA scripts.
3) A solution to implement Question 1 if Girder doesn’t already support.

Thanks Guys, I know its long but I really do appreciate your feedback, help and comments.

Robert

[Mark F]

So many questions, so little time. I'm not trying to be rude or anything, I'm trying to identify the cause of the problems you are reporting.

Method 1

Girder is an event processor. It is not a LUA application environment. If your event processing doesn't end (uses an infinite loop), Girder will fail.

Method 2

Press F9 to disable all plugins (including the time server). I don't understand why polling once a second is not acceptable but this isn't my problem to solve.

If you have a buildup of lines, service all of them before exiting the LUA script on each time (polling) event.

Method 3

You basically did the same thing as method 1 and it failed the same way. The LUA triggerevent() function places an event in the event queue. The goto executes the target command immediately. The wait freezes Girder. You produced an infinite loop (that had a wait in the middle) which added events to a queue which will not be serviced.

Wish list

Ron will need to address these since I'm just another user; but, here are MY thoughts.

Girder is an event processor. It is not a LUA application environment. The LUA implementation in Girder does exactly what Girder needs for it to do. The implementation appears to be single threaded and I doubt changing it to be multi-threaded would be easy. I have no doubt that the current implementation can be made to work in your environment without changing the LUA implementation in a drastic way.


The problems you are having boil down to trying to use Girder in a way that Girder wasn't really designed for.

In an attempt to get past these problems, I have attached a .zip file to this post which contains a group of commands (and comments for each command) and events to make them fit together. I *think* this breaks the problem into the correct set of commands and events so Girder can be used for this task. The .gml also demonstrates the use of a global variable (vContinue) to stop the processing of this solution.

The .gml file requires the UserEvent and Keyboard plugins be installed and enabled. The keyboard plugin is only used to stop the processing and you can learn a remote control button instead if that makes it easier to use in your environment.

I hope this helps.

[Gimbal]

Mark,

Thanks alot now I see how you have approached the problem the water finally clears on how to try and set Girder up.

As I said in a previous post I was probably trying to get Girder to do something it wasn't intend to do. But hey I never I have a screwdriver thats great as a hammer. :-?

All I got to do now is try and work out how the plugins work. :wink:

Thanks again and hopefully I will be quiet for sometime.

Rob

[Mark F]

... hopefully I will be quiet for sometime.

I hope not.

Pushing things to do the unintended is the best way, in my opinion, to inspire innovation and new ways of thinking.

Good luck.

[Ron]

About making Girder put a Lua script in the background. There are some nasty problems in there.

• How to make the thread end nicely when Girder closes ?
• How to create different threads in Lua 4 ?
• Is Lua 4 threadsafe within one Lua_State ?

Lua 5 solves some issues with threading but that isn't due to be released until at least feb i think, and if it is released can Girder be upgraded or is Lua 5 radically different ? Cause I'm not going to break the scripting again... I promise. :-)

[Gimbal]

Thanks. Like I said it was a wish list and as every knows some wishes don't come true. :wink:

However, I have, I know you are thinking here it comes again, some more questions. :P

1) Can I use more that one user event in any one Girder project? Basically I have to User Events, one is used when I try and open the file and is set up for a 2 second delay. The other is to read a line from the file, has shown by Mark, and this is set up for a 1 second delay. However I am having problems getting any of these user events to trigger.

2) What is the different learning ALL, Girder and User?

3) If I have a a User Event and a Girder Event both triggering one command do I need two triggers. One learned for Girder Event and the other learned for User Event. If I have to learn several events then its probably the reason I having trouble with question 1.

Thanks Guys.

[Gimbal]

Just for information.

I got the User Events to work by changing them round in a IF ELSE statement. Don't know why this is the case. The funny thing is though when I changed them back to the how they were original they still worked.
Thinking this was too good to be true (not Girder - myself actual getting something to work) I exited Girder and restarted and they still worked!

I know it wasn't a typo as I use the cut and past facility in the editor.

Any one else saw this?

Robert

Extra info

The LUA script was something like this orginally when it would work:

If (loghandle==nil) then
print " Retrying to open log file!"
TriggerEvent ("RetryOpenLogFileEvent", 18)
else
print "Log file opened"
TriggerEvent ("ReadLineEvent", 18)
end

and changing to this made it work:

If (loghandle~=nil) then
print "Log file opened"
TriggerEvent ("ReadLineEvent", 18)
else
print " Retrying to open log file!"
TriggerEvent ("RetryOpenLogFileEvent", 18)
end

and when changed back to how it was originally it still work.

The RetryOpenLogFile was the first User Event in the command directory and ReadLine was the second.