JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

Quirk with IRP-Variations, repeats and IrpTransmogrifier

 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Software
View previous topic :: View next topic  
Author Message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Tue Apr 20, 2021 1:40 pm    Post subject: Quirk with IRP-Variations, repeats and IrpTransmogrifier Reply with quote

Sean Young recently discovered a quirk with Variations and IrpTransmogrifier, reported here. Basically, a Variation without (infinite) repeat in the enclosing IrStream is senseless, but IrpTransmogrifier happily accepted it. Embarassed My proposed solution is to basically to prohibit it (throw Exception), and fix the involved protocol-IRPs. Details in the quoted issue.

Anyone would like to comment? (If you do not have or want a Github account, you can write here.)
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Wed Apr 21, 2021 5:48 am    Post subject: Reply with quote

@Barf

Although I wrote the IRP Specification document based on John Fine's work, I defer to you for any improvements, fixes and so on. I never expected anyone to actually implement it in the way you have and am amazed that it was actually possible to do so with only the modest additions you have made. If you, or anyone else, cares to revise the specification document to incorporate your and any other changes, I am very happy for them to do so. I can't remember if I have posted it as a .doc as well as a .pdf, but if not then I am happy to post the .doc file to make it easier to work on. As for the present issue, I have no views to contribute.
_________________
Graham
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Wed Apr 21, 2021 9:57 am    Post subject: Reply with quote

On second thoughts I do have a view. All that seems to be wrong is that IrpProtocols has one meaningless IRP, namely that for RCA(Old) since a variation without an infinite repeat, as you say, is meaningless. That IRP needs to be corrected. I don't think there is anything wrong with the IRP Spec in this regard. Also, I doubt if there are many software applications that catch every conceivable piece of meaningless input so I don't see why IrpTransmogrifier needs to be amended to catch this one.
_________________
Graham
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Thu Apr 22, 2021 4:35 am    Post subject: Reply with quote

mathdon wrote:
All that seems to be wrong is that IrpProtocols has one meaningless IRP, namely that for RCA(Old) since a variation without an infinite repeat, as you say, is meaningless. That IRP needs to be corrected.

The protocols Direct_TV_P*, OrtekMCE_relaxed, RCA-38(Old), RCA(Old), Velodyne. XMP*, Zaptor-* have been fixed in the branch.

Quote:
I don't think there is anything wrong with the IRP Spec in this regard.


Agreed; your sentence
Quote:
a variation is a permitted type of irstream item that operates in conjunction with a repeat marker for the irstream that contains it.

"prohibits" variations in repeat marker-less IrStream.

Quote:
Also, I doubt if there are many software applications that catch every conceivable piece of meaningless input so I don't see why IrpTransmogrifier needs to be amended to catch this one.

It is not about prohibiting everything that is silly, it is about having a behaviour that is logical, consistent, easy to understand and document. The behaviour demonstrated by Sean was not really acceptable. In this case, I considered it the simplest solution just to prohibit the ambigous/contradictory construct.

I am definitely against "prohibiting everything silly".
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Software All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

Powered by phpBB © 2001, 2005 phpBB Group
Top 7 Advantages of Playing Online Slots The Evolution of Remote Control