Description of problem: There seems to be an issue with processing comments, particularly of the form: CPU Requirements [7843] #BZ815500 This results in errors of the form: ERROR: Index: 45, Size: 44 ERROR: Index: 46, Size: 45 ERROR: Index: 53, Size: 52 ERROR: Index: 54, Size: 53 ERROR: Index: 55, Size: 54 ERROR: Index: 78, Size: 77 ERROR: Index: 117, Size: 116 ERROR: Index: 153, Size: 152 Moving comments to a new line makes these go away, but I was under the impression that we should be able to insert a comment at any point - with all content after the first # being treated as a comment. Version-Release number of selected component (if applicable): 0.24.7
This comment also seemed to cause the same issue: # Consider moving the task (7517) down into the actual install part, a lot of people seem to miss it.
After putting all comments on their own line, and removing the brackets from the comment mentioned in c#2, I no longer get the index errors. I now get this instead: INFO: The Content Specification is valid. ERROR: An error occurred during processing please try again. =/
Ok, error reported in c#3 appears to be because I had the tag line: [Writer=sgordon,RHEV 3.1,RHEV Installation Guide] While the original just had: [Writer=sgordon] Probably a separate bug I guess.
Yeah there was a bug with 0.24.7 in regards to the tags, this has been fixed in 0.24.8 so make sure you update. See: Bug #831905 As for the inline comments they aren't supported and are of very low priority. As for the error message I've been trying to fix that for a while but I haven't been able to recreate it using any of my VM's with different OS's and Java versions installed. I know another cause of it is if your missing a ending bracket. As for your second comment its a bit unclear whether its an inline comment or a full line comment. Full line comments should work if its the only thing on the line, if it doesn't then please let me know and I'll look into it.
Just adding I can easily replicate the index error when using comments at the end of a new line.
Fixed and I'll update with a release number when I do a build. Cause: Trying to read a new line that shouldn't have been read and an issue with the line counting when parsing. Consequence: Because the line number was actually one higher then it should of been when reading a new line that it shouldn't have been it was trying to append text to line that didn't exist, hence the ArrayOutOfBounds Exception message. Fix: Make the parser only read the new line under certain circumstances so that the line counter isn't incremented incorrectly.
(In reply to comment #5) > Yeah there was a bug with 0.24.7 in regards to the tags, this has been fixed > in 0.24.8 so make sure you update. See: Bug #831905 > > As for the inline comments they aren't supported and are of very low > priority. As for the error message I've been trying to fix that for a while > but I haven't been able to recreate it using any of my VM's with different > OS's and Java versions installed. I know another cause of it is if your > missing a ending bracket. Ok, but does the documentation mention that inline comments aren't supported? The way I read it just says that # is the comment character, which from it's behaviour in other languages would imply that everything thereafter is a comment - regardless of where it appears. > As for your second comment its a bit unclear whether its an inline comment > or a full line comment. Full line comments should work if its the only thing > on the line, if it doesn't then please let me know and I'll look into it. As per the content spec I attached that one is on its own line, removing the brackets () made it parse successfully. So I think the parser is struggling with certain special characters in the comments. That probably still needs to be looked at.
(In reply to comment #8) > (In reply to comment #5) > > Yeah there was a bug with 0.24.7 in regards to the tags, this has been fixed > > in 0.24.8 so make sure you update. See: Bug #831905 > > > > As for the inline comments they aren't supported and are of very low > > priority. As for the error message I've been trying to fix that for a while > > but I haven't been able to recreate it using any of my VM's with different > > OS's and Java versions installed. I know another cause of it is if your > > missing a ending bracket. Tbh I never read the docs in full as Josh wrote them. I'll check it over and if it's wrong I'll talk to Josh and get it fixed up. > Ok, but does the documentation mention that inline comments aren't > supported? The way I read it just says that # is the comment character, > which from it's behaviour in other languages would imply that everything > thereafter is a comment - regardless of where it appears. > > > As for your second comment its a bit unclear whether its an inline comment > > or a full line comment. Full line comments should work if its the only thing > > on the line, if it doesn't then please let me know and I'll look into it. > > As per the content spec I attached that one is on its own line, removing the > brackets () made it parse successfully. So I think the parser is struggling > with certain special characters in the comments. That probably still needs > to be looked at. Thanks, I never actually looked over the spec you emailed me, so I'll take a look and find the issue with it.
I cannot find anything that even mentions comments within content specs, in the CSP Guide at: https://engineering.redhat.com/docs/en-US/Engineering_Content_Services/1/html-single/Content_Spec_Processor_Guide/index.html#Appendix-Example_Content_Specs The only thing I was able to find was a line in the template files: "# Lines that commence with the # symbol are comments" which is fairly clear. Either way I'll talk to Josh about getting a note added into the guide.
With the single line comment, the issue is resolved using the fix from above. The reason is because of the bug from earlier it continues to parse lines until it believes to have finished a topic. Due to the inline comment a few lines above the single line comment it was trying to parse the comment as being part of that topic (ie. it assumed it was a tag-category grouping).
Released as part of 0.24.9
Closing and setting as current release as no QA was performed by the original reporter. If there is still an issue with this bug still than please re-open it.