[DSL] Add extra commands/abilities to DSL scripts/rules#5481
Conversation
|
Also, consider the specific new commands I've implemented as more of a suggestion. This can be tweaked as desired. @rkoshak Perhaps you have something to add here? |
|
The itest fails because of some unresolved reference. I'm trying to figure it out, but if anybody has any hints of how to figure out the problem, it would be appreciated, because I frankly have no idea how to handle the bndrun resolution. |
|
I don't think the itest fails over dependencies, but that the startlevel is insufficient: If I understand it correctly, So, the question is: Is it actually a problem that |
|
I've set the startlevel in the test to 40, which is required for the script engine to start, and it seems to resolve the problem with the test. I'm still uncertain as to whether reaching startlevel 40 before the Are there scripts being executed before startlevel 40 is reached? |
|
Now there's a new test failure, not sure exactly how it is related yet: |
|
The current test failure seems to have some complicated timing reason. The following line in Resource resource = resourceSet.createResource(URI.createURI(PREFIX_TMP_MODEL + name));This results in an NPE. The question is why it returns
I'm not sure what this mythical factory is and why it suddenly can't be found, but I assume that it has something to do with |
|
I changed the strategy regarding This has resolved the test problems, but comes with the caveat that |
|
In case somebody wants to test it for themselves, this bundle should be all that's needed. |
|
@rkoshak I've added some additional methods for manipulation of metadata. Is that somewhat what you had in mind? I've also reluctantly implemented the varargs "solution" for the maps, so that it's possible to simply call e.g. Since these are just suggestions, I haven't bothered to finish the Javadocs, as I'm sure they'll change, which makes the time I spend writing the documentation a waste. |
|
@rkoshak I've added even more overloads, so not all the metadata methods accept either item name or |
|
@lolodomo There's no a lot of activity here, maybe you're interested in this? This isn't important for me in any way, but seen in light of all the other discussions about DSL versus other scripting languages and the difference in what you can do, I thought that this might be a welcome contribution to close the gap. |
|
Ï've never fully understood the "action" concept in OH. I understand that they are similar to functions/methods, but not what the significance of making things "actions" is. We have for example Why this structure? Is an |
|
I've reorganized The "full versions" are also there, so you can call |
|
This pull request has been mentioned on openHAB Community. There might be relevant details there: https://community.openhab.org/t/rules-and-rule-templates-yaml-integration/168568/222 |
|
#5484 adds Running afterwards |
Adding That said, the goal of this PR isn't to make it possible to do those things, but to make it reasonably convenient. As long as imports can be resolved, you can always use This PR has public static @Nullable <T> T getInstance(Class<T> clazz) {
Bundle bundle = FrameworkUtil.getBundle(clazz);
if (bundle != null) {
BundleContext bc = bundle.getBundleContext();
if (bc != null) {
ServiceReference<T> ref = bc.getServiceReference(clazz);
if (ref != null) {
return bc.getService(ref);
}
}
}
return null;
}So, I don't see these two as "competing" in any way. |
|
After By using the function |
Rectification: After |
|
I didn't remember that the services were reference counted, so I'll have to make some modifications to accommodate that. But, as I see it, we can't expect script authors to use try/finally to make sure to release the reference. I've looked a bit in core, and it seems like this is "mishandled" other places as well. If you look at JS Scripting, it does the exact same thing: https://openhab.github.io/openhab-js/osgi.js.html#line38 Since it's unrealistic that script authors can manage the reference counting, I think the best thing to do is to release the reference before returning it. That will work just fine as long as something else keeps a "counted reference" to the instance. In OH, this will almost always be the case, there are other components that reference "everything". As far as I understand, OSGi uses this reference counting to automatically stop services that aren't used by anything. The fact that a service is referenced doesn't prevent an explicit shutdown, so it's not like "a lock", it just prevents automatic shutdown. Since the script acquiring the reference should never have the only reference, releasing it before returning should work fine in practice. In the very unlikely scenario that this isn't the case, the script will fail when it tries to use the service if OSGi has shut it down in the meanwhile. I think that is acceptable, given that it is extremely unlikely to happen, and it should be better than to "leak references". |
lolodomo
left a comment
lolodomo
left a comment
There was a problem hiding this comment.
Very promising contribution.
Just few comments
|
@Nadahar : thank you for that contribution. Why is it still in draft mode ? Does it mean it is not yet finished ? |
Signed-off-by: Ravi Nadahar <nadahar@rediffmail.com>
Signed-off-by: Ravi Nadahar <nadahar@rediffmail.com>
Signed-off-by: Ravi Nadahar <nadahar@rediffmail.com>
…der control Signed-off-by: Ravi Nadahar <nadahar@rediffmail.com>
|
I built the full core from this PR, and then built the whole addons repo against that. There were no add-on failures locally, so I don't think the nullness annotation changes are that risky. Build result |
Signed-off-by: Ravi Nadahar <nadahar@rediffmail.com>
Signed-off-by: Ravi Nadahar <nadahar@rediffmail.com>
Signed-off-by: Ravi Nadahar <nadahar@rediffmail.com>
Signed-off-by: Ravi Nadahar <nadahar@rediffmail.com>
|
The current change adds new implicit imports in DSL Rules/Scripts/Transforms and adds new methods to ScriptServiceUtil. Both changes are independent of each other. Implicit importsThe implicit imports represent a syntaxis sugar: everything possible without the implicit imports is also possible with the implicit imports. This is how it has always worked in DSL Transformations. One argument in favour of the implicit imports is, that when converting textual DSL rules (from On the other side there is no concluding documentation including all implicit imports. This leads to allegations, that there are regressions in regards to changes of the implicit imports, but at the same time no examples are provided with these allegations, which worked with particular openHAB version in the past. In the absense of documentation of the available implicit imports, such allegations - something worked in the past, but does not work any more - will continue to emerge. The absense of documentation however also means, that implicit imports can be removed in future openHAB versions. (Because users currently feel the same, as if implicit imports were removed.) Writing DSL Scripts and Rules is currently a lof of trial and error, until it works. The “trial and error” will not change by adding more implicit imports, which are nowhere documented. I suggest first writing down in the documentation at https://www.openhab.org/docs/ which implicit imports are availabe, and then possibly adding new implicit imports. However my feeling is that by the time the changes to the documentation are approved, people who wanted to add new implicit imports, would have lost their motivation. Thus before adding new implicit imports, the process of approving proposed changes to the documentation should be streamlined. As a matter of fact I have investigated such allegations in the past, I have put time there, and the way to avoid allegations in the future, that something was implicitly imported in the past and is not anymore - is to write down what is implicitly imported. The allegations will not disappear in the future by adding more implicit imports. New methods to ScriptServiceUtilAdding new methods to ScriptServiceUtil is syntaxis sugar, allowing access to RuleManager and others. Access to OSGi services like RuleManager can be done from Groovy and from DSL Rules/Scripts/Transformation in the same way (just Groovy does not have yet Even without the current changes That said I think it only makes sense to add new methods to ScriptServiceUtil after the current functionality is written in the documentation at https://www.openhab.org/docs/. I am not willing to undermine here all the developement work done, but instead I want to emphasize that without documenting the current functionality, it makes little sense to add more undocumented functionality. |
|
I will say that in general, I absolutely agree that these things must be documented to be useful, but I started making this simply because I was told time and time that this and that couldn't be done from DSL. I looked into it and discovered that it was only true because nobody had enabled it. I know that it most of this "could" be done if you created the full "Java code" to handle all these things, but not always, because some things weren't available/visible to the scripts bundle. But, I also think it's pointless to argue that people should figure out all the details of how to do the things as if they were Java developers. I think these things are more than just syntactic sugar. They provide various things that people typically need without having to go through all the technical details. It's a bit like saying that The helper libraries basically do the same thing. You can do it all without helper libraries from JavaScript, Python and Ruby, but most people use the helper libraries. Languages that don't have helper libraries, like Groovy, has almost no users. Jython used to be quite widespread in OH from what I understand, but when the helper library was discontinued/disappeared, the language went more or less dead. It's still available, but I've yet to hear about anybody that use it in OH today. So, I think it's pretty evident that providing such easier access to common functionality is very important for most users. There are tons more that could be added here, I didn't set out to make a full helper library for DSL, I was initially trying to figure out why some things "weren't possible". So, if there is will and demand, much more could be made available like this. I don't really use that "complex" rules that I need to manipulate registries etc., so I have little idea what is and isn't "needed", which is why I stopped once I had made some of the things that seemed most "handy". When it comes to allegations about what used to work in the past, we have Git history, so we don't really need the documentation to figure out what is and isn't true. If Git history is too difficult, one can also simply run an older version and test. |
In case of using
Can you, by looking at the git history, or by running an older version, find out, if |
|
This change constists of:
As the above bullets are completely independent of each other, and all of them combined produce 3100 new lines of code, I think it would have been better, if this single PR was split into several, distinct proposals for code changes. |
It wasn't just running other rules, but accessing some of the registries. Regardless, I've already explained why I don't think it matters much if it's "possible" if you have to know and use all the OSGi stuff yourself.
Yes, according to the Git history, it was never available. That doesn't mean that we know that it didn't work, but that's a different issue entirely. If we had documentation for implicit imports, it wouldn't have been there. It would have changed nothing, it could still have worked.
I disagree. I don't make changes based on the code structure, but based on the resulting change in behavior/"features". Many of the changes would make little or no sense alone, so it would be very difficult to try to justify why things were changed. |
Signed-off-by: Ravi Nadahar <nadahar@rediffmail.com>
Just a little clarity on the history here. Before OH 3, Jython was the most used non-DSL language. However, the helper library was maintained outside of the openHAB project and the author did not want to move it under the openHAB project. At the time of OH 3's release, that developer disappeared and closed down the helper library repo. The same developer was the only one maintaining the Jython add-on. So the add-on basically became abandonded. Others forked the helper library repo and tried to keep it up but it became pretty clear that the overall situation was untenable. I personally started moving everything over the Nashorn JS without any helper library instead (and it was pretty miserable with 1/3 to 1/2 of all my code being importing OSGI crap over and over again) because it was clear that Jython wasn't going to be able to keep up in it's semi abandonded state. It was and remains really awkward to have to use Since then, GraalVM Python was added and, importantly, the main developer for that has taken on maintenance of Jython too so Jython isn't so abandonded any more. However, I don't know if the Jython helper library is being kept up to date. And Jython still only supports the 2.7 version of Python that reached end-of-life more than six years ago. And the last time I looked, there was a whole lot that the Jython Helper Library doesn't support (i.e. it's not kept up with new OH features). The drop in use of Jython has more than just the Helper Library problems working against it, but that is a significant reason not to use it. |
Thanks for filling in, I don't know the full story, but my main point was that I disagree that it's "pointless" to add "convenience functions" even though it is possible to achieve the same if you write a lot of code that deals with OSGi and whatnot. That is fundamentally what this PR provides, and it is fundamentally what the helper libraries provides. It doesn't look "pointless" to me, because people seem to much prefer it and use it much more when such "convenience functions" are available. |
We can argue for a very long time about this and I don't think it is worth trying to do all of the forensics to find the proof. I have since moved all my rules away from DSL, so anything I do is for ease of use for DSL users. And I do think there is a lot that can be made easier with DSL. The lack of ease, I would say, is a major reason people actually moved away from it. |
|
I will give it a few days before merging, but LGTM. |
Just to confirm that it works but the proper syntax is: |
Add access to various system registries, OSGi instances and the ability to run and enable/disable rules to DSL scripts.
This has been considered "impossible" to do, yet I've met no special obstacles, and it seems to work with my (limited) testing. I'm therefore skeptical that there might be something that I've missed, like additional startup issues caused by
ScriptServiceUtilreferencing additional instances, thus depending on them. But, I've observed no such problems.Additional context/information about the historical problems with this is appreciated, but as far as I can see at the moment, this works without complications.