Page 12 of 14
Posted: Sat Apr 30, 2022 5:04 am
by mathdon
Are you planning a new release of IrpTransmogrifier in the near future? I hope shortly to make a new official release of RMIR and will wait for a new IrpTransmogrifier if it too will be ready shortly, otherwise I will stick to v1.2.10.
Posted: Sun May 01, 2022 12:17 pm
by Barf
I plan to release version 1.2.11 as a stable version within the next few weeks. There will also be a corresponding Girr release (2.2.11).
There will not be any dramatic changes since 1.2.10, mainly small bug fixes and extensions. The current snapshot is quite close to the final version; so feel free to try the current snapshot.
More substantial changes in the sense of
#111 will not be included in this release.
Posted: Mon May 02, 2022 5:16 am
by mathdon
What has happened to NamedProtocol.getAbsoluteTolerance and NamedProtocol.getRelativeTolerance? I use them in RMIR but there no longer seems to be a way of getting those values.
Posted: Mon May 02, 2022 6:27 am
by Barf
Ooops.
They were inadvertently removed in d142de52de850fe1b7c60079a87a521f1ac7b34. Using too strong detergent when cleaning up...
A fixed version has been checked in.
Posted: Mon May 02, 2022 8:29 am
by mathdon
Thanks for the speedy fix. RMIR now compiles and runs with the latest snapshots of both IrpTransmogrifier (c5840d8) and Girr (d0af52c). No time for proper testing yet, but I will report if I find any problems.
Posted: Tue May 03, 2022 4:29 am
by mathdon
I have just spotted a typo in rmProtocols.xml that has got propagated into your merged IrpProtocols.xml. In version c5840d8 it is at line 1288. The line ends in two > signs but there should only be one. The erroneous line is
Code: Select all
<rm:translator target="power1">power1|Off|On</rm:translator>>
I think it gets ignored in processing, or I would have found it before, but it would be better if it were corrected.
Posted: Tue May 03, 2022 11:18 am
by mathdon
In IrpProtocols.xml, in fixing the IRP repeat in NEC1-Yamaha, you have inadvertently also added in a spurious extra documentation entry. Here is an extract of what is currently there:
Code: Select all
<irp:protocol name="NEC1-Yamaha">
<irp:irp>
<![CDATA[{38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,E0:1,~F:6:1,E7:1,1,^108m,(16,-4,1,^108m)*) {E0=(~Y:1:1)^(F:1),E7=(~Y:1)^(F:1:7)}[D:0..255,S:0..255=255-D,F:0..255,Y:1..3]]]>
</irp:irp>
<irp:documentation xml:space="preserve">Variant of the <a href="#NEC1">NEC1</a> protocol with the checksum in byte 4 different
(complement all of F except the MSB).
</irp:documentation>
<irp:documentation xml:space="preserve">A variant of the <a href="#NEC1">NEC1</a> protocol which differs in the relationship between bytes 3 and 4.
Instead of byte 4 being the complement of byte 3, the relationship is determined by the value of the Y parameter, as follows:
<ul>
<li>Y=1: Only bits 0-6 are complemented.</li>
<li>Y=2: Only bits 1-7 are complemented.</li>
<li>Y=3: Only bits 1-6 are complemented.</li>
</ul>
</irp:documentation>
The second entry, with the different Y values documented, is the correct one.
Posted: Wed May 04, 2022 7:03 am
by mathdon
Thanks for making the fixes to IrpProtocols.xml. If you are interested, I have now uploaded RMIR v2.14.13 to the SVN which incorporates your latest snapshots, d5e8d1c for IrpTransmogrifier, d0af52c for Girr. Remember, if you try to run this build, that you need to do mvn validate first, to install the snapshots from the libs subfolder. I do not intend to issue this as a development build unless something occurs that necessitates a new build before you are ready with your new release versions.
Posted: Wed May 04, 2022 1:32 pm
by Barf
The "typos" in IrpProtocols.xml has been checked in (thank you!), but you seem to have noticed that already.
I got your new SVN version, and, without making extensive tests, did not find any peculiarities.
However, one thing disturbed my consciousness: The new getRelativeTolerance (and the three other get-ters) return null if the variable is not assigned in the current protocol, the old one returned the default value (IrCoreUtils.DEFAULT_RELATIVE_TOLERANCE). I have added functions getRelativeToreranceWithDefault that returns the default, if not assigned. (Correspondingly, the get*() return Double, the get*WithDefault return double.) Use any you want.
Checked in as 5d7fc3b19ec2c5e7ff2ac015a80939eb465e119f.
Posted: Thu May 05, 2022 4:38 am
by mathdon
Thanks for pointing out this change. I have looked into my code and I use the returned values only once, in a call to the constructor Analyzer( irSignal, absTol, relTol ) where absTol and relTol are the returned Double values. On looking into your code, if I read it correctly then in due course these Double values are converted to double values by calls to IrCoreUtils.getDoubleWithSubstitute(Double userValue, double fallback), which converts nulls to the appropriate default value. If I am right then this means that all is well and that I do not need to change anything. Can you confirm that this is correct, that I haven't missed some other use in the constructor where nulls are not converted to default values?
Posted: Thu May 05, 2022 12:53 pm
by Barf
First, I think it would be more logical to use get*WithDefault() for the parameters of a protocol, since you want the actual, current parameter value, and do not care (here) if it is a special value, or happens to be the default value.
mathdon wrote:if I read it correctly then in due course these Double values are converted to double values by calls to IrCoreUtils.getDoubleWithSubstitute(Double userValue, double fallback), which converts nulls to the appropriate default value. If I am right then this means that all is well and that I do not need to change anything.
Well, yes,
while the current defaults in the protocols are the same as the defaults in the Analyzer, but this is not a guaranteed and documented property, and may not be true in the future.
You pick the parameters of the first decoded protocol, and feed it to an Analyzer constructor. I do not consider this a good idea. The analyzer should do its job independent of the decoder. The tolerances of the Analyzer are used to determine how the measured durations are grouped, which is pretty different from the usage in the decoder. Suggestion: just use the Analyzer(IrSignal) constructor. Then you do not need NamedProtocol.get*Tolerance() either
Posted: Fri May 06, 2022 8:00 am
by mathdon
Barf wrote:The analyzer should do its job independent of the decoder.
In an ideal world the analyzer should just take an IrSignal and find the best analysis without further help, but the world is not ideal so it takes tolerances as parameters to provide context. The analysis display in RMIR does not pretend to be ignorant of the decode. Its aim is to present the signal data in an IRP form that can be compared with one derived from the IRP used by the decoder, which is also displayed. There are two possible choices of tolerance values for the analyzer, the default values and those used by the decoder, if different. For this use it seems to me that the best choice is those used by the decoder. Of course, if there is no decode then only the analysis is displayed and that will have used the defaults.
Barf wrote:I think it would be more logical to use get*WithDefault() for the parameters of a protocol ... while the current defaults in the protocols are the same as the defaults in the Analyzer, ... this is not a guaranteed and documented property, and may not be true in the future.
I have done as you suggest, now in the SVN, though any change you make in the future can be addressed at that time. I'm not a fan of future-proofing, as very often the future you proof against isn't actually what happens.
Posted: Thu May 12, 2022 2:16 pm
by Barf
Release candidate 1 of IrpTransmogrifier 1.2.11 and Girr 2.2.11 are available in the usual locations. Only main difference from recent version is that protocol F12 has prefer-over F12x. (Otherwise all F12 decodes also decode as F12x).
Please let know if there are any issues within, say, a week.
Release notes
Posted: Tue May 24, 2022 5:13 am
by mathdon
Barf wrote:Please let know if there are any issues within, say, a week.
In case you missed my PM, I have found no issues with your RC1 in my testing, so as far as I am concerned it is ready for issue as final.
Posted: Tue May 24, 2022 3:32 pm
by Barf
IrpTransmogrifier 1.2.11 and Girr 2.2.11 have been released.
Release notes: (The notation #n refers to issues number n at
https://github.com/bengtmartensson/IrpT ... ier/issues .)
Code: Select all
This version consists mainly of a few extensions, bugfixes and cleanups.
* If DecoderParameters.allDecodes is true, indicate which decode is preferred with new API call.
* Bugfix/cleanup on decoder parameter and --override handling. #214.
* Some cleanup of XML code generation.
* Decoded protocol parameters (in toString()) now ordered as in the IRP ParameterSpecs. #207.
* Analyze now optionally generates ParameterSpecs in the IRP. Resolves #202.
* New protocols: Eufy, F12x, Keeprite. ((From RMIR).
* Bugfix in IrpDatabase.toElement(Document ...). #219.
* Add intro, repeat, ending to --classify output. #218.
* Remove cName (@c-name in XML) completely. #217.
* Rename min-leadout to minimum-leading (pull request #212 from seanyoung).
* Bugfix for IrCoreUtils.parseLong(String, boolean, int). #211.
* New function IrpDatabase.setDocumentation.
Graham, sorry for not answering faster. I got and read your PM.