SRP Compiler warnings

Chris_Meyer

As per attached image I am getting many warnings in OI10.2.1 that do NOT exist in OI9.4.6

Chris_Meyer

BTW The OI10 editor does NOT display any warnings.

KevinFournier

Interesting. OI 10 and SRP Editor both supposedly use the BLINT routine to find VNAVs, so I can't explain why you are getting VNAVs for variables that don't even exist in the code. If you email me the routine and all the inserts it uses, I can see if I can replicate the issue and get to the bottom of it.

BarryStevens

I am also trying to help Chris with this, so pardon me for butting in.
Is the code you present to the compiler the actual code that we see or do you parse it to somewhere then compile it.
Where is that code stored and can we get access to it, and maybe compile that in the OIs compiler.

If I compile SRP_Set_Prop_Array there are no errors.

I am suspecting that there must be some sort of coding convention that is being used as a carry over from very early OI9 that your parser cannot handle. Because pretty much all the large code procs that Chris has done over the ages have this issue.
The variables are there , and are being initialised but also the errors are most of the time pointing to the wrong spot which made me suspect that that is not the actual code that is being compiled.

Would an appbackup work better for you maybe, then everything could be caught.

DonBakke

As Kevin mentioned, we are calling Revelation's BLINT routine as we always had. So if this is behaving differently in OI 10 versus OI 9 (i.e., same code does not product the warnings in OI 9 but you are still using the SRP Editor) or if the OI 10 editor behaves differently than the SRP Editor, then this tells us that BLINT is either 1.) not being used, or 2.) is being used differently than expected. The easiest way for us to determine this is to compile the same routine and diagnose this at a lower level.

DonBakke

Oh...as far as sending us a package, if you really think sending us an entire system is best, then we would prefer a copy of the entire OI folder, zipped up, and then uploaded to a web page that we can provide. Sending us an AppBackup will require us to prep a few things and we would rather not go through that much work just to get access to code. Alternatively, if there are just a few inserts and this one stored procedure then just email those to us as text files. Note, we don't need any other stored procedures as we are not going to run the code. We just need to see what happens when we compile the code.

BarryStevens

I will leave Chris to follow up this.

Thank you.

KevinFournier

SRP Editor 3.4.3.3 fixes this. Download the installer here.

BarryStevens

Thank you.
That works

btw: What is 'Added Hook and Unhook TCL commands'

DonBakke

It's a way to automatically implement BASIC+ hooking as described in this blog article. It is a technique we use frequently to understand how OI works, or customize the way OI behaves, so it made sense to finally create a feature in the SRP Editor to make this much easier.

Hooking was what allowed us to figure out how BLINT in OI 10 behaves differently than OI 9 and thus fix the SRP Editor for Chris' situation.

BarryStevens

Ok, found an issue.
If a function or subroutine is not declared, the error message is:


OI10 compiler gives the expected error messages

Chris_Meyer

Trying to compile an Insert and get the following message in OI9.4.6

KevinFournier

Fixed and fixed. Redownload and install. Version will be 3.4.3.4.

Opto_Will

@KevinFournier,

I seem to be getting the Runtime Error 'Variable not assigned' when F9ing on a Record in 3.4.3.4.
(F9 is my habit in the Editor to Save and Compile, even on a record where no compilation takes place).

The record Saves OK so the issue must be in the 'No Compilation' side....

Opto_Will

@KevinFournier

Did you note "F9 on a records throws an error after installing Editor 3.4.3.4" on the 'The List'?

KevinFournier

Thanks for reminding me. This one had slipped through the cracks. I fixed the issue and just officially released 3.4.4 of the SRP Editor.

Opto_Will

Thanks @KevinFournier :)