Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.

SRP Precompiler Error Using /**/ Multiline Comments with "Service" Keyword

With the #pragma precomp SRP_PreCompiler directive near the start of my
program, if I follow with a multiline comment as used in C (and B before
that, and apparently PL/I before that), the "Service" keyword inside the
comment fails compilation. As an example, the following program gives
three errors :

function Test_Services(@Service, @Params) #pragma precomp SRP_PreCompiler /* ... Parameters: Service [in] -- Name of the service being requested Params ... */ GoToService else * error-handling code here end Return Response OR '' service TestService() * service code here end service

Removing the rest of the line ("[in] -- Name of the service being requested")
after the "Service" keyword removes the errors. One can retain the rest of
the line by adding a visible character (such as "@) before the keyword.
Or if "Service" is alone on a line, or surrounded only by whitespace, the
code also compiles.

The bug is linked to the GoToService statement, because removing that
statement also removes the errors. And placing the directive after any
offending multiline comments also allows the program to compile.

But is there any chance of improving the parser, which ought to ignore
everything inside a comment?


Comments

  • @vince - What version of the SRP Editor are you using? I think this might have been fixed in later releases of the SRP Editor. I couldn't find anything in the Version History about this (unless I'm being a bit blind), but I do recall this being a problem in the past. I copied your code verbatim into my system and it compiled without any errors.
  • @DonBakke - I should have posted this in the first place.

    SRP Editor version: 3.3.8.2
    Build: 2/17/22 11:13AM
  • @vince - What is the version of SRPEditor.ocx?
  • @DonBakke
    SRPEditor.ocx: 3.3.8.2
  • @vince - I've tried the version prior to, the same version, and the version after (which isn't publicly available yet) and I still cannot duplicate your issue. I think the only way for me to investigate further is to get a copy of your system.
  • @DonBakke - I wonder if someone here changed the Frameworks code (if that is relevant). I went back to the "Master" copy from which I installed on my computer and got the same three errors. But we also have a "Pristine" version which has not yet been merged with the master. And on that version the test code compiles. The editor on "Pristine" is 3.3.7.0 (and 3.3.8.2 .ocx), but I'm doubtful that the editor is the problem now.

    If you still think it worthwhile to look closer, Opto is over 300 MB compressed. Is there a way to upload it?
  • @vince - Let's check something else out first. I forgot that sometimes we find versions of $SRP_PRECOMPILER in local applications and these are older than the ones which ship with current versions of the SRP Editor or SRP Utilities. Use the Open Record dialog and look for $SRP_PRECOMPILER* in SYSOBJ. If you find it, delete it and restart OI and let me know if you still have compiler problems.

    If you don't find a local application version, open $SRP_PRECOMPILER, go to the bottom of the record, highlight the internal datetime stamp, and right click to show the Oconv DateTime. Mine looks like this:


    Let me know what datetime yours is.
  • @DonBakke - You hit the nail on the head. In addition to $SRP_PRECOMPILER which has the same date.time (19769.5519791667) shown in your screenshot, I also had $SRP_PRECOMPILER*FRAMEWORKS:


    Removing this version eliminated the errors. Now I know somewhere else to look before posting an outdated bug report to the forum.

    Thank you! I would not have solved this one in a month of Sundays.
  • @DonBakke - I have a follow-up question: How would a local version of $SRP_PRECOMPILER creep into my application?
  • Given that this was local to FRAMEWORKS, I'm wondering if we happen to have this in one of our RDKs. I'll have to look and see. If so, this was probably done for troubleshooting purposes or it was done when I was tasked with updating it to support API routines.
  • @Vince, I might have an answer...

    @DonBakke, You and I diagnosed an issue back in mid-2020 (archived-version-srputilities-1-6-1#latest) where it became clear that we had SRP debug code throughout the system once upon a time. It stands to reason that, for whatever purpose that was, we didnt give our system as full cleanout as we should have. Maybe it had creeped in there and never left?
  • @Opto_Will, sounds plausible to me. :) We double checked all of our development systems and RDKs and there is no entity for this, so I think this is more than plausible and veers toward probable.
Sign In or Register to comment.