New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ola streaming client reports invalid value. #1198
Comments
Have you been able to confirm which of the two zeros in your command is causing the error? |
The "red" script will
It does "2" for both the 0 and the 1 universe, because at one point in time the physical lamp was connected to the other universe... Anyway it seems to be the universe id that is the problem. "1" for a universe id is invalid at the moment. I still don't understand what's wrong with "0". |
Can we see the script please? What version of OLA are you using? What OS etc? How did you install it? What's confusing me, is those errors must be coming from here: To reach that, the flag has to not have_arg() which obviously the universe one should have. Then it has to fail to set the value to "1", which all flag types should support. TBH this is feeling rather like a preprocessor issue with the macros to me, assuming you compiled it yourself. |
I am using OLA compiled from GIT because i'm also adding a driver for some hardware that I'm building. It seems I'm using an "own-compiled" version, because which ola_streaming_client returns /usr/local/bin.
Ok Some more experimenting:
|
Okay, so I see the default shipped version works, so let's try and narrow down why your compile is failing. Can you try the install version of you're compiled version, just to check it's not the lack of ltmain wrappers breaking it: Can you try building either from the 0.10 branch or this PR and see if they work: The PR should give us some more clues as to where and how flag parsing is failing for you. |
Can we also have all the traditional info like OS flavour/version, compiler version etc. Do any of these commands parse their args correctly? |
OS: Raspbian GNU/Linux 8 I modified common/base/Flags.cpp to: I think my modification of the code is better than yours.
|
It would be good to run one or two of the other commands just to rule out an issue with that specific utility. They vast majority of them have man pages, or you can just do ola_rdm_discover -u and ola_uni_stats (doesn't need a -u). I believe if you don't run the ltmain wrapper (./examples/ola_streaming_client) if will run the code in that program, but find any libraries centrally, which in your case could be either the previously installed local ones in /usr/local/lib or the debian packaged ones in /usr/lib, neither of which will have your change obviously. Can you just confirm that running ./examples/ola_streaming_client fixes the problem and it sends the data as expected? In which case it was probably a bug in a previous version that we've since fixed, or some quirk of not running it via the ltmain wrapper. Regarding code modifications, are you comparing your proposed patch to the existing code, or to my PR I linked to before ( https://github.com/OpenLightingProject/ola/pull/1199/files#diff-cb14df65f07890e5bf7f649d05439e5bR208 )? Mine also mentions the name of the flag, personally I'm inclined to steer away from activate and not immediately obvious what it does. It's also potentially confusing with the flag present concept we've got. Essentially a flag with no argument is a special case of a boolean flag, equivalent to saying --flag-name true, without having to write the true bit, hence I'd rather keep the error message similar to what you'd see with a bool flag requiring an argument if you used an invalid argument (e.g. tru), compared to introducing a new term like activate. TBH that particular error basically shouldn't ever happen, so I'm still rather confused how it did, you got a bool flag that didn't accept 1 as a valid value! |
Okay, I think you have a version of OLA on your machine prior to 0.9.0 which it was loading the library from, we used to only support true/false in a bool, where the flag parsing code passes in 1, t/f and 1/0 were added later here: Which I think explains it. We could in theory change the 1 the flag code passes in for a true, which would then be backwards compatible, but we've never tested or promised that you can use a newer front end with older libs (in comparison, we try to be careful that the other way round works for API usage), so who knows what else would break still. |
@rewolff have you had a chance to confirm please? |
Sorry. Have been very busy lately. No time for OLA stuff. |
Have you had any time since @rewolff ? |
When I do:
ola_streaming_client -u 0 -d 2,255,2,255,0
ola_streaming client reports:
Invalid value 0
And I must say that I disagree. zero is en entirely valid value.. The statement "invalid value 0" is simply wrong.
Now, it could quite possibly be the case that in some context the value "0" is not valid. But the error message should reflect that.
Of course it is easy for a programmer be writing the code for parsing "universe IDs", and that when the parsing fails, then to report "invalid value". But by the time the program suite is further along, such a failure comes from somewhere in the program, and as a user I'm left to guess WHY it considers "0" an invalid value.
Could it be that I wrote O instead of 0? No. Could it be that "0" is not a valid universe ID? No. (I checked the web interface, and I have universes with ID 0 and 2. Apparently I wrote the script when 0 and 1 were valid universe IDs... ).
P.S. The issue is not getting my ola_streaming_client commandline to work, but to improve the software.
The text was updated successfully, but these errors were encountered: