Girder 5 Bug Thread

[quixote]

Thanks.
Both the Lua and Core Thread subsystems are causing 8 infractions when set to 3000ms.

[Rob H]

It definitely sounds to me as though you have a Lua script that is either taking a very long time to execute or is getting stuck in an infinite loop.

The hard part is going to be tracking it down. I would suggest using the Lua debugger for this. To enable the debugger go into File|Settings, find the Lua debugger tab and check the enable debugger checkbox then reset Girder.

I would also disable the watchdog since it will attempt to restart Girder if you sit on a breakpoint for more than the Lua timeslot.

Start the debugger and connect to the local Girder instance. When Girder becomes unresponsive press the Pause button in the debugger and take a look at the threads that are running.

[quixote]

I'll try that and see what I come up with. Thanks for the advice.

[quixote]

I took a look at the Debugger, and the problem I've found is that the unresponsive state that I am talking about occurs at Girder startup. I don't have time to connect before my startup macro is executed.
The only real issue I'm having for the moment is that I cannot reliably load my persistent variables table. Sometimes it's loaded, other times I think that it cannot aquire the mutex.
These variables are very important and store information such as the number of occupants that are in the dwelling so that the system can arm the alarm if that number drops to 0, and other less important variable such as the state of the TV, doors, etc.
How would you get around this? I guess I could create a thread with a loop that looks to see if the table is nil and if so, attempt to load it again.
What's your opinion?


Thanks

[Rob H]

Can you reset the Lua scripting when it's in this state or is it completely dead?

It sounds like there may be too much going on in the main thread when you start Girder. It may be worth using threads for any Lua scripts that are run at startup.

How are you loading the persistent variables?

[quixote]

It's pretty much completely dead. The cursor changes to an hourglass while over the application window and it sometimes says "(not responding)" on the window titlebar.

I am creating a table and filling it using gir.ReadConfigTable. I've tried delaying loading the the plugins at start and it doesn't help much. It slows down the loading process to a standstill, though it does load my table eventually (after what seems like 2 minutes).

Can you please show me the exact sytax that I could use to load my persistent variables in a thread at the start? I may be able to put a few other actions in threads as well.

Thanks.

[Rob H]

So it does resume execution?

In that case you can connect to Girder after it has started working again, then reset it. The debugger should remain connected and you should be able to pause Lua execution while it's being unresponsive.

Using a thread is pretty straightforward if you already have a parameterless function that loads the config table - I'll assume I have one called LoadPersistentVariables - to run it on a thread just use

thread.newthread(LoadPersistentVariables, {})

If you need to pass in some parameters you put them in the second parameter in a table.

[jaakkoijas]

X10-CM1X plugin does not support comport number over COM 10.

[jwilson56]

This has been fixed and the files were uploaded

http://www.promixis.com/forums/showthread.php?t=19156


Ron

the in the OneWireDM.lua file change

        local deviceproperties = {
        
            ID = odevice.Number,
            Location = odevice.Location,
            Name = odevice.Name,
            Description = '' -- does it have a description??
            Provider = self,
            
        }

to

        local deviceproperties = {
        
            ID = odevice.Number,
            Location = odevice.Location,
            Name = odevice.Name,
            Description = "",
            Provider = self,
            
        }

So both bugs are fixed?

Well somewhere after 537 the One Wire DM handle has been broken. As I didn't add anymore sensors I had not noticed that the DM setup screens were not working. I am at the lastest G5. Could someone look at it and see if we can get this working again?

With the changes to the OneWireDM.lua I still get this error:

TreeScript (RunScript,B): ...Girder5\luascript\DeviceManager/Providers/Simple.lua:47: Must provide a function "GetPlugin"
stack traceback:
[C]: in function `assert'
...Girder5\luascript\DeviceManager/Providers/Simple.lua:47: in function `MustProvide'
...r5\luascript\DeviceManager/Providers/PluginBased.lua:20: in function `Initialize'
...der5\luascript\DeviceManager/Providers/OneWireDM.lua:54: in function `Initialize'
...\Girder5\luascript\DeviceManager/Providers/Basic.lua:34: in function <...\Girder5\luascript\DeviceManager/Providers/Basic.lua:23>
(tail call): ?
...s\Promixis\Girder5\/plugins/treescript/OneWireUI.lua:37: in function <...s\Promixis\Girder5\/plugins/treescript/OneWireUI.lua:31>
...s\Promixis\Girder5\/plugins/treescript/OneWireUI.lua:106: in function `Initialize'
...s\Promixis\Girder5\/plugins/treescript/OneWireUI.lua:613: in main chunk

[Rob H]

This thread is getting way too big to keep track of - could you post this as a separate message? Thanks.