MSR UI on a mobile browser

[toggledbits]

@librasun said in Expressions and LuaXP Functions:

you must first pre-populate the test1 variable with an empty array

You don't actually. This is just a bug in lexpjs. I've fixed it in my local copy, will be in the next build. It's just this simple:

[LibraSun]

@toggledbits Do you want to include conditional key references like this in lexpjs?
obj={'122':['a',5, true]}
obj?['123'][0] // null or throws error
obj?['122'][0] // (string) "a"

By this I mean do you want to have square bracketed key references treated the way potentially non-existent dot references are handled using question marks.

[toggledbits]

Confused. Are you asking for this to be added?

[LibraSun]

I think so, if it's possible. Just wanted to (a) make sure that ?[ doesn't exist yet (my testing seems inconclusive), and (b) you consider it necessary. I've already bumped into a potential use case.

So, I suppose "Yes, add it" at least for consistency with existing ?. usage.

[toggledbits]

@librasun OK... so I think I'm seeing through the confusion now...

The ?[ and ?. operators already exist; they were added together with ?? a long time ago. They are left-associative, so they refer to the operand on the left. In your examples, they will not work as you are trying to get them to because obj is non-null in every case (it's the first thing defined in the example). I think what you mean to say is:

obj={'122':['a',5, true]}
obj['123']?[0] // which will return null and not throw an error
obj['122']?[0] // which will return (string) "a"

[LibraSun]

Agree with everything you just wrote. I was mis-applying the question marks, as far as placement in my expression (treating it as a prepend instead of append). Thanks for straightening me out yet again.

I had mistakenly thought this construct only worked on objects.?with.?arbitrary.?keys and arrays[with_arbitary_indexes]? and not object keys (with non-standard names) referred to via brackets. My bad.

[LibraSun]

CODE SAMPLE: Creating an Array of N Whole Numbers [0, 1, ... , N]

Sometimes you need an array of Counting Numbers from zero to some arbitrary integer N. But it's hard to write this as an Expression in MSR, because you don't know in advance how long to make the array, and the value of N may change later.

This somewhat byzantine construct fills the bill, and works for N=0 up to N=56:

arrCount := N=56,each s in keys(substr((s='s'+1/9)+s+s,0,N+1)): int(s)

This example evaluates to the array:

arrCount == [0,1,2, … ,55,56]

Just change the number after N= (it could also be another variable name, of course!) to suit your needs.

BONUS: Need more numbers? Just add another +s in the middle for an additional 19 integers (giving max. N=75). Repeat indefinitely!

P.S. @toggledbits I may need to enter this in the Obfuscated Lexpjs Code contest!

[toggledbits]

I think it's a grand prize winner for the "Solutions for Problems Nobody Has Ever Had Using Reactor" contest, for sure, but I'll admit it's not a straightforward problem to solve without a counting loop structure, so the question is, what's the best approach:

1. Implement a counting loop statement (for in many languages);
2. Take the Python-ish approach and have either a range() function or a start..end range operator, which you could use as the operand in each;
3. Other?

Choice 2 is better suited to an expression environment, but we already ride the fine edge with each, first and do statements in the current language. But in keeping with the flavor, each of these statements still produces an expression result, so still arguably as much operator as statement; it's less clear what a sensible return result from "for" might be. On the other hand, #2 requires an array be built in memory over which to iterate, and an error could easily build a large array that consumes dangerously large amounts of (or all) available memory and have a negative impact on stability (so perhaps more safeguards in order, but how big is too big?).

EDIT: I just prototyped the two options given above:

# Example for to build array of values 1-25
arr=[]; for i =1,25: push(arr, i)
# That's unnecessarily clunky and could be streamlined by making "for" return an array
# of result values like "each":
arr=for i=1,25: i
# But then... that means "for" is about the same as "each", just different operands.
# In my mind, that kind of argues for option 2:
arr=each i in range(1,25): i
# or
arr=each i in 1..25: i
# and even that's unnecessary, because you could just do
arr=range(1,25)
arr=1..25
# because both of those naturally return an array.
# Another example, to sum all the values from 1 to 25 it would be:
sum=0; for i in 1,25: sum=sum+i
sum=0; each i in range(1,25): sum=sum+i
sum=0; each i in 1..25: sum=sum+i

I think the range operator .. is the cleanest all around, and relieves the ambiguity of having both for and each so similar. I'm not sure .. is any easier or harder to learn/remember than having a function range(start,end). So I'm leaning toward option 2 with range operator ...

[LibraSun]

100% agree that sum=0; each i in 1..25: sum=sum+i makes the most sense in terms of conciseness without introducing another function name. I don't foresee any usability issues with an m..n operator generally.

I'd expect .. to accept any integer, – or +, for its arguments m and n, regardless if m>n or n>m. Use cases include step functions or monotonic sequences for things like dimming levels over time.

Sure looks better than what I came up with, eh?

Glad I brought it up, because I had recently been hand-coding my own arrays for use with each.

[LibraSun]

@toggledbits For today's checkup on how Expressions handle assigning values by reference, I constructed:

a=b=c=[1,2,3], pop(a), shift(b), [a==b,b==c,a==c,c]

// result is [true,true,true,[2]]

A. Pls confirm this is as expected. (I'm guessing 'Yes')
B. Does result comport with typical user's expectations? (I'm guessing 50/50)
C. I know you don't want me mashing that "Try" ► button (in lieu of actual, useful, runtime evals).

Just something that's been on my mind, wondering if it belongs in your Test Suite.

[toggledbits]

You can't compare arrays (or objects) with ==. What it's telling you when you write a==b is that neither a nor b are null, 0, or false, and they are identical references. So yes, this is all expected.

As for it comporting with user expectations, if the user is a programmer, I think this will be no surprise. Non-programmers have the learning curve. Again, another reason I really don't like guiding users to expressions. New users, IMO, should be blissfully unaware of their existence.

[LibraSun]

Wise words!

[toggledbits]

By the way, I forgot to mention, as is often necessary in many languages because of the reference issue, there is a clone() function that makes a new copy of an existing array or object. So a=[1,2,3],b=clone(a),push(b,99) will result in a having [1,2,3] and b having [1,2,3,99].

[LibraSun]

It's as if you read my mind. I suppose my numerous "cloning arrays" examples gave it away.

Without clone(), I was never (easily) able to manipulate a copied array without affecting the original, and that was driving me bonkers.

Thanks!

[LibraSun]

@toggledbits , am digging how the new a..b operator behaves predictably, fixing the decimal of a and spitting out integer steps up to ≤b when both a,b > 0 and a < b. For example:

a = 1 .. 3.3
// result (array) [1,2,3]
a = 1.1 .. 2.3
// result (array) (array) [1.1,2.1]

But sometimes it tries too hard, particularly in this case where a < 0:

a = -2.3 .. 1.1
// result (array) [-2.3,-1.2999999999999998,-0.2999999999999998,0.7000000000000002]

or here, where a > b:

a = 2.3 .. 1.1
// result (array) [2.3,1.2999999999999998]

All testing thus far using only INTEGERS has avoided any rounding issues, so that will likely become my mantra on usage.
rev. 21123

[LibraSun]

KEEP TURNING OFF LIGHTS!

I thought it might be fun to have a Rule that periodically watches for lights (any device, really) left on, but I wanted the entire "action" part of the Rule to live inside a single expression. Here's what I came up with:

devs = each dev in getEntity( "vera>controller_all" ).members:
  match( dev , ".*device_\\d+" ),
devices = each dev in devs: 
  indexOf( getEntity( dev ).actions, "dimming.set" ) > -1 ? dev : null,
performAction( f = first dev in devices with getEntity( dev ).attributes.power_switch.state, "power_switch.off", { } ), 
getEntity( f ).name + " turned off."

This example only checks dimmable lights paired with Vera, but could easily be modified to include other classes of device connected to other controllers, etc.
The way it works is it (Line 1) pulls all of the member devices associated with Vera; (Line 2) filters the list to disregard devices not of the form device_NNN; (Lines 3-4) checks to see whether each device handles dimming; and, (Line 5) passes along only those for performAction() to turn off individually (one "On" device per cycle); finally, (Line 6) the name of the most recently turned-off device is logged.

I concocted this behemoth because my Vera routinely chokes on my "Lights Out" rule, which attempts to switch 20 devices OFF all at once. I felt it might be more prudent to handle the switching at a slower pace, with the added benefit that if anyone turns ON one of the listed devices during "Lights Out" time, this rule would spot it and turn it back off automatically.

Comments?

• Libra

[toggledbits]

I suggest adding both comments (# to end of line is a comment in lexpjs) and indent spaces for clarity (e.g. the match clause on the second line is part of the each on the first line, so IMO an indent would make this much more clear).

That search on the first two lines suggests that MSR may need a deterministic way to differentiate an entity that represents a device from entities that represent other system data. I'll think about that, because it has come up before.

Another way to write the test on line 4 is 'dimming' in getEntity( dev ).capabilities. The capabilities property is an object, so the in operator works by directly testing on that object, and will be much faster than using indexof() on the actions array. Given, this operation probably would not run frequently, so that kind of optimization may be overkill, but I assert that this alternative to the array search is actually easier to interpret as well, and where performance is not the leading goal, clarity is a good next candidate.

The inline assignment to a temporary variable on 5 and used in line 6 is clever and makes me cackle with glee.

[LibraSun]

@toggledbits and other puzzle lovers... I challenge you to paste in this Expression definition and run it with the 'try' button, to solve this heavily obfuscated conundrum:

solve="<creator_mystery>";
s1="(.)";s2="(..)";s3="(...)";s4=s1+s1;s5=s2+s2;s6=s3+s3;who=getEntity(replace(solve,s4+s6+s4+s4+s5+s1,"\$3\$2\$4\$5\$8\$7\$8\$9\$6\$11\$8\$7\$8\$9\$6"));
you=who[keys(who)[0x07]];are=you[keys(you)[0b01]];upper(substr(are[keys(are)[0o10]],0,0o13))

|-Answer: _____________°fa-info°(S┴IqpƎ˥פפO┴)-|

[LibraSun]

@toggledbits , how does MSR "know" that an expression like:

each dev in devs: getEntity(dev).attributes.power_switch.state ? dev : null

contains dependencies on the status of (potentially) many devices?

It's neat that MSR almost immediately detects when a light gets turned on, for instance, and the resulting array grows by one within less than a second. But what is cuing MSR to re-evaluate the above expression so quickly behind the scenes?

[toggledbits]

If devs is a constant list, the iteration visits each dev through getEntity(), and that function subscribes to any device it is asked to resolve. So the first time the expression is evaluated, it has subscribed to every device in devs.