openLuup email server

[rafale77]

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.

[akbooer]

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]

@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!!

[a-lurker]

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.

[akbooer]

@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.

[a-lurker]

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..

[CatmanV2]

@akbooer said in openLuup: Suggestion:

An idea: (prompted by @CatmanV2 ’s mammoth code development in Lua Test windows) ...

That seems somehow unlikely!

C

[akbooer]

@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.

[akbooer]

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

[a-lurker]

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.

[akbooer]

@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]

@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]

@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.

[akbooer]

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.)

[a-lurker]

@akbooer said in openLuup: Suggestion:

just add the Lua Test Code environment

If possible that would be good.

[akbooer]

@a-lurker said in openLuup: Suggestion:

If possible that would be good.

Done!