Displaying precompiler output in SRP EDITOR.EDT STATUS

davidgoddard

Our precompiler outputs to the SRP_EDITOR.EDT_STATUS control ok, but gets overwritten by "compilation successful" message. Is there another way to send the info to the editor so that the output is displayed correctly at the completion of a compilation?

DonBakke

David,

I am confused by the statement "so that the output is displayed correctly". What is incorrect about the output?

As a side question, would sending output to the Viewer (Shift+F7) help?

davidgoddard

From a pre-compiler, what is the suggested way to return text, like the vnav checker does, so that the output is displayed in the EDT_STATUS control.

KevinFournier

I see, you want a way to generate your own warnings or errors. I presume your pre-compiler is accomplished through a Repository COMPILE hack? That is, the SRP Editor just runs Repository COMPILE and you're version of Repository runs a pre-compiler? If that's the case, you would need to emulate the way Repository COMPILE returns errors.

davidgoddard

The precompiler is implemented using the #PRAGMA PRECOMP notation in the source code.

It appears that the compiler uses set_status and get_status to pass errors around. I don't know how the VNAV checker returns it's output. In srp-editor v2.6.1 I've found that the VNAV checker is a little hit and miss. Some times it returns results and some times it does not.

If the precompiler returns output via set_status then the compile process terminates before compiling and VNAV checking. The precompiler works more like the VNAV checker and returns warnings, which should not stop the compilation process.

Maybe one solution is that the editor clears the EDT_STATUS control when a compile is triggered, then appends output to the control, rather than replacing the contents, when the compilation process completes.

KevinFournier

Ah, yes, the #PRAGMA PRECOMP. I forgot all about that. I'll have to play with this to see the best way to poll errors from PRECOMP routines. All VNAV stuff, by the way, is done using Revelation's BLINT routine, although the SRP Editor does try to clean up the results of BLINT to remove false positives.

MattCrozier

On a side note, is there a way to temporarily turn UTF8 mode off during a compile? I'd love that - it would speed up the compiler quite a bit.

Cheers, M@

MattCrozier

Yeap, at least on OI 8.0.8. I've just tried compiling a 3300 line program - in UTF8 mode this takes 64 seconds, but with UTF8 off - 4 seconds!

davidgoddard

what, UTF8 mode slows down compiling?

KevinFournier

Turning UTF-8 before compiling could break programs that use Unicode characters within their strings. It is better that someone that doesn't need UTF-8 just turn it off at their own discretion.

Besides, I'm pretty sure OI 10 will improve compiling performance since it will all be UTF-16.

MattCrozier

Turning UTF-8 before compiling could break programs that use Unicode characters within their strings. It is better that someone that doesn't need UTF-8 just turn it off at their own discretion.

True! I'd be aware of those cases as it's pretty rare. I presume a precompiler could do a
len( allSourceCode) != getByteSize( allSourceCode) test to check if there are any unicode characters in the precompiled source code (including Inserts).

Besides, I'm pretty sure OI 10 will improve compiling performance since it will all be UTF-16.

Hmm, how will that work? Won't it still have to parse UTF multi-btye characters, at least in existing source code??

KevinFournier

In UTF-16, every character is a word (two bytes), which covers all the known Unicode characters. Technically, UTF-16 allows for multi-word characters, but it currently doesn't need them. So, for now, OI will be able to assume a fixed width for all characters, thus granting it the same speeds as ASCII.

I suppose we could do length check, and perhaps that's something I'll play around with. Good idea.

MattCrozier

In UTF-16, every character is a word (two bytes), which covers all the known Unicode characters.

What does that mean for existing data (including source code presumably), most of which will be stored as single byte UTF-8? Will the OI 10 upgrade have to go through a character conversion process?

I just tried an experiment! It seems that the compiler doesn't care about unicode characters, even in variable names. I compiled this simple unicode program in ANSI mode,
Subroutine Test_Unicode( void) Üñìçðďë = "Here is some Üñìçðďë" Call Msg( @window, Üñìçðďë) Returnand it displays properly when run in UTF-8 mode.

KevinFournier

Data can be stored in any encoding be it ASCII or UTF-8, it will simply be re-encoded into UTF-16 when it is stored into memory. This is a one time operation that is not very expensive. In fact, it's already happening a lot in OI. Have you ever used a WinAPI call? Well, some of them have two versions: e.g. GetWindowTextA and GetWindowTextW. Most of OI's predefined WinAPI calls use the 'A' version: ASCII. However, all the 'A' version does is convert the incoming text from UTF-8 to UTF-16 then call the 'W' version.

Regarding the compilation, I suppose it makes sense that UTF-8 is preserved during compilation because strings don't have to be processed character-by-character. The compiler merely accepts all bytes between the quotes. Still, I can't help but think that there's an element of luck at play here. If a character is three bytes, for instance, and one of those bytes has the same code as the equal sign, I wonder if that would mess things up. Better yet, what if the last byte of the last character is a pipe. Would that fool the compiler into thinking it's a line continuation?

MattCrozier

Data can be stored in any encoding be it ASCII or UTF-8, it will simply be re-encoded into UTF-16 when it is stored into memory. This is a one time operation that is not very expensive. In fact, it's already happening a lot in OI. Have you ever used a WinAPI call? Well, some of them have two versions: e.g. GetWindowTextA and GetWindowTextW. Most of OI's predefined WinAPI calls use the 'A' version: ASCII. However, all the 'A' version does is convert the incoming text from UTF-8 to UTF-16 then call the 'W' version.

Ahh, I see! Thanks

Regarding the compilation, I suppose it makes sense that UTF-8 is preserved during compilation because strings don't have to be processed character-by-character. The compiler merely accepts all bytes between the quotes. Still, I can't help but think that there's an element of luck at play here. If a character is three bytes, for instance, and one of those bytes has the same code as the equal sign, I wonder if that would mess things up. Better yet, what if the last byte of the last character is a pipe. Would that fool the compiler into thinking it's a line continuation?

But we know that won't happen, right?, because of OI's implementation of UTF-8 which states (in the online help) that all multi-bytes are high-order (> 0x80) and such ANSI characters are not used in Basic+ itself. (And also < 0xF0, so system delimiters are preserved).