openLuup: Suggestion
-
As @akbooer said in another thread...
I suppose I should also be setting out a roadmap. At the risk of it becoming a commitment, let's just say that, for the moment, it's just a list of incremental development ideas and some blue sky thinking:
ZWay plugin integrated in openLuup distribution (as are AltAppStore and VeraBridge)* native scene triggers – not the same as Vera, not the same as AltUI variable watches, but definable in the openLuup console.
utilities for managing Data Historian archives
better task & job messagesand then...
fully asynchronous I/O
enhanced HTTP server with data compression (perhaps using third-party web server?)
Ajax calls for asynchronous updates of some console pages (Devices, Scenes, ...)
...Ideas always welcomed!
-
I had been thinking of apache, but it looked cumbersome. Lighttpd, of course, was another Vera-inspired option (openWRT.). I must look up more about nginx.
How easy is this to install on any system? Does it support WSAPI CGIs?
—————————
Edit: after a little homework, I think that the answer is yes, for WSAPI. Not that I know how I’ll use it, just that some of openLuup is implemented like that.
-
Yup, I at one point at one such proxy running to force going through login before being able to openLuup by blocking the port 3480 to any access except for nginx from my firewall. This has always been an odd thing missing from the vera which deems blocking the local access and forcing going through their server being their secure mode. Nginx reverse proxy could then act as the local authentication server.
-
An idea: (prompted by @CatmanV2 ’s mammoth code development in Lua Test windows) ...
...there could be a version of the require() statement which includes code from one of the other openLuup Lua Test windows (currently a total of three, but could be more) to aid in modularity when testing.
-
An idea: (prompted by @CatmanV2 ’s mammoth code development in Lua Test windows) ...
...there could be a version of the require() statement which includes code from one of the other openLuup Lua Test windows (currently a total of three, but could be more) to aid in modularity when testing.
@akbooer said in openLuup: Suggestion:
An idea: (prompted by @CatmanV2 ’s mammoth code development in Lua Test windows) ...
Well, it turns out that this is already easy to do!
If the Lua Test Code window #3 contains, for example:
local function foo () return "this function is in Lua Test Code #3" end return {foo = foo}
(in other words, a standard module declaration) and then in another test window you write:
local T3 = loadstring (luup.attr_get "LuaTestCode3") () print (T3.foo())
then you will get the expected result:
––– 1 line ––– 0.5 ms –––
this function is in Lua Test Code #3
Job done!!
-
Not sure if this is the "Official" openLuup suggestion thread but: in the Lua test code windows in the console. It would be good if they were cleared when you hit the code Submit button. That way you see all your old print statement outputs disappear and affirms you have actually clicked the button.
-
Not sure if this is the "Official" openLuup suggestion thread but: in the Lua test code windows in the console. It would be good if they were cleared when you hit the code Submit button. That way you see all your old print statement outputs disappear and affirms you have actually clicked the button.
@a-lurker said in openLuup: Suggestion:
Not sure if this is the "Official" openLuup suggestion thread
Yes, it is.
@a-lurker said in openLuup: Suggestion:
It would be good if they were cleared when you hit the code Submit button.
Not sure I’m understanding this. You press the button, the code is run, the results are in the output window. It usually happens quite quickly... I did think of adding a time stamp to the header to show when it was run.
-
I was recently playing around with some AES ECB encoding/decoding and I'm looking at changes amongst a myriad of same other info that's coming in over a link over a period of time. On thinking about this further: I don't see anything printed at all, until the program is finished (that's the actual problem). Whereas the log can spit out debug info as the code proceeds. If the code takes time to run (lots of seconds) decoding incoming data; then I'm unsure if it is executing till it finishes or has indeed crashed.
Doesn't need a time stamp. Just a blank output screen when the Submit button is operated; ready for new the output to be shown immediately the program finishes..
-
An idea: (prompted by @CatmanV2 ’s mammoth code development in Lua Test windows) ...
...there could be a version of the require() statement which includes code from one of the other openLuup Lua Test windows (currently a total of three, but could be more) to aid in modularity when testing.
-
I was recently playing around with some AES ECB encoding/decoding and I'm looking at changes amongst a myriad of same other info that's coming in over a link over a period of time. On thinking about this further: I don't see anything printed at all, until the program is finished (that's the actual problem). Whereas the log can spit out debug info as the code proceeds. If the code takes time to run (lots of seconds) decoding incoming data; then I'm unsure if it is executing till it finishes or has indeed crashed.
Doesn't need a time stamp. Just a blank output screen when the Submit button is operated; ready for new the output to be shown immediately the program finishes..
@a-lurker said in openLuup: Suggestion:
I don't see anything printed at all, until the program is finished
Slippery slope, this. Next you’d be wanting to interact with a running program...
Ajax requests are the answer to this – and for real time updates of the devices page – so it’s on the list (actually I must write the list down, sometime) and the basic infrastructure is there.
I’ll see what can be done sooner re. clearing the output window.
-
I had a quick go at this... and failed.
My motto (for openLuup engine and console) is "no JavaScript". Actually, there is a teeny tiny bit, in order to be able to hook into the indispensible Ace editor.
I was willing to break the rule if it solved a problem, but the obvious bit of JS to clear the output window before submit does not work since it is, in fact, an iframe, not a div. I'm no expert in this, and don't really want to be one, believing that server-side pages are inifinitely preferable. (the speed of the openLuup console, cf., say, AltUI, or, God forbid, UI7, is testament to this mantra.)
It will be solved in due course, but the quick fix approach will not do it. I am a bit busy with a different, exciting, project (that, one day, may surface as an openLuup plugin as one of its guises.)
Sorry. Tried. Failed.
AK
-
AK - thanks for your efforts. I think I will survive without it. What with three test windows and UI output with pretty() versus watching the log file go past: I think I'm doing pretty well (pun intended).
Here is another possible suggestion/query. As you may have noted I've been disappearing down and reappearing up at various rabbit holes re: luup.call_delay(). I fully appreciate that the openLuup code is busy doing stuff and a requested delay may blossom into something longer than requested. You mentioned AltUI may hit the system a bit hard but I didn't note any difference with it running or not - that's one rabbit hole of many. So is it possible to somehow profile openLuup to see what is really holding it up. It could possibly be the Vera connection; another rabbit hole or indeed all my own plugins. I'm unsure how this would be done. May be an auxiliary test program that could be run for ten minutes or so? Lua has some debug library built in that may be useful. Anyway may be in the too hard basket as profiling can be a can of worms.
Another query - the openLuup console has System-->All_Gobals, which is great for finding vars that should have been declared as local. So question - is there some code that you can write that you execute with your other test code in the Lua test window, that will list globals in the code running in the Lua test window, so errant vars can be found and made local, as needed? Could also apply to functions.
-
AK - thanks for your efforts. I think I will survive without it. What with three test windows and UI output with pretty() versus watching the log file go past: I think I'm doing pretty well (pun intended).
Here is another possible suggestion/query. As you may have noted I've been disappearing down and reappearing up at various rabbit holes re: luup.call_delay(). I fully appreciate that the openLuup code is busy doing stuff and a requested delay may blossom into something longer than requested. You mentioned AltUI may hit the system a bit hard but I didn't note any difference with it running or not - that's one rabbit hole of many. So is it possible to somehow profile openLuup to see what is really holding it up. It could possibly be the Vera connection; another rabbit hole or indeed all my own plugins. I'm unsure how this would be done. May be an auxiliary test program that could be run for ten minutes or so? Lua has some debug library built in that may be useful. Anyway may be in the too hard basket as profiling can be a can of worms.
Another query - the openLuup console has System-->All_Gobals, which is great for finding vars that should have been declared as local. So question - is there some code that you can write that you execute with your other test code in the Lua test window, that will list globals in the code running in the Lua test window, so errant vars can be found and made local, as needed? Could also apply to functions.
@a-lurker said in openLuup: Suggestion:
So is it possible to somehow profile openLuup to see what is really holding it up.
How strange... for the other project I am currently working on, I’ve started using the Lua debug library to profile the code. As warned in the docs, the library can be slow, so timing is not really possible at the Lua level. Counting procedure calls, however, is faster, but I’m not sure it will give you what you need. On the plus side, it’s trivial to add the profiler to any running code with no changes required. I’ve not tried this on openLuup, yet...
@a-lurker said in openLuup: Suggestion:
is there some code that you can write that you execute with your other test code in the Lua test window, that will list globals in the code running in the Lua test window
Well, yes, of course! Ah, you want to know what that is... I just need to try this on my development system, and not an iPad. Perhaps after breakfast...
-
@a-lurker said in openLuup: Suggestion:
is there some code [...] that will list globals in the code running in the Lua test window
So here's a little function that shows you all the globals in the Lua Test Code area (shared with scenes / Startup Lua / Shutdown Lua.)
local function globals () local G = {} local name_type = "([^/]+)/(.+)" local gnames = "%-20s %s" for g, x in pairs (_G) do G[#G+1] = g .. '/' .. type(x) end table.sort (G) for _, g in ipairs(G) do print (gnames: format (g: match (name_type))) end end globals()
Running that in one of my test windows shows:
––– 58 lines ––– 0.2 ms ––– ALTUI table ALTUI_LuaRunHandler function LuaTestCode3 function _G table _KEY function _NAME string _VERSION string assert function bit table collectgarbage function coroutine table debug table dofile function error function gcinfo function getfenv function getmetatable function io table ipairs function jit table json table lfs table load function loadfile function loadstring function luup table math table module function newproxy function next function os table package table pairs function pcall function pretty function pretty_old function print function rawequal function rawget function rawlen function rawset function require function scene_1 function scene_10001 function scene_10002 function scene_2 function scene_3 function scene_4 function select function setfenv function setmetatable function string table table table tonumber function tostring function type function unpack function xpcall function
Notice that, unlike the openLuup console's
System > All Globals
menu, this simple code does not winnow out the standard Lua globals. -
@a-lurker said in openLuup: Suggestion:
So is it possible to somehow profile openLuup to see what is really holding it up.
How strange... for the other project I am currently working on, I’ve started using the Lua debug library to profile the code. As warned in the docs, the library can be slow, so timing is not really possible at the Lua level. Counting procedure calls, however, is faster, but I’m not sure it will give you what you need. On the plus side, it’s trivial to add the profiler to any running code with no changes required. I’ve not tried this on openLuup, yet...
@a-lurker said in openLuup: Suggestion:
is there some code that you can write that you execute with your other test code in the Lua test window, that will list globals in the code running in the Lua test window
Well, yes, of course! Ah, you want to know what that is... I just need to try this on my development system, and not an iPad. Perhaps after breakfast...
@akbooer said in openLuup: Suggestion:
Perhaps after breakfast...
What's for breakfast - bangers & mash?
That's helpful. Quickly identified four vars that were global, when they shouldn't have been, in the test code. It's amazing how they can slip through a manual visual check of the code.
-
Glad that did the trick...
...I’ve just thought of an easier way – I could just add the Lua Test Code environment to the
System > All Globals
page!(Breakfast was, in fact, crumpets and maple syrup.)
-
@akbooer said in openLuup: Suggestion:
just add the Lua Test Code environment
If possible that would be good.