FB Parsing of QB "dot" names

[mmbcastle]

Is there a compiler directive, switch, etc to have FB not treat dots as whitespace in names?

For example, I'm converting a lot of old code, and some of the function names look like...

public SUB READ.MULTIKEY(KEYFILE$,DATA.KEYS%(),mkMASK$(),TOTKEY%,NUMKEYS%) STATIC
public SUB FORMAT.SORT.KEY(NUMKEYS%,DATA.KEYS%(),mkMASK$(),BKEY%,LKEY%,DATA.TYPE%,MASK$,FMTKEY$) STATIC

When I compile these, it doesn't like the function names because it sees "MULTIKEY" and "FORMAT" as the identifiers (which clash with keywords), rather than the full names.

I'm using the #lang "fblite" directive. I don't recall what errors I ran into when I was trying to use the "qb" directive, but that solved some issues I was running into as I'm converting these old libraries.

[mmbcastle]

A mod can delete this thread if desired. However, someone else may get a benefit from seeing what I learned.

I figured out what I was seeing was actually a difference between how the old QB parser and the FB parser work.

I had routines calling helper functions that were defined lower down in the same library source file. In the old QB, this was ok. However, I know a lot of parsers work this same way and want all functions defined before they are called. That's how I knew to rearrange the source file, which fixed the issue.

If someone else is converting old QB code, it would be easy to stumble on this same error. I know I lost an hour or two trying to work out what was going on.

[MrSwiss]

Two remarks:
Why not going 'all the way' and convert to -lang "FB"?
(all current/future development is typically in the 'native' dialect only)

Easy solution for "dot" in identifiers is: replace it with underline "_".
(dots are typically used for Type.Member access ... in -lang "FB")

[mmbcastle]

Thanks for the reply.

I am converting a few hundred thousand lines of old QB code before MS finally removes 16 bit support. Right now, I'm still in the process of converting the old "core" libraries.

In this "first pass", I'm trying to develop procedures to convert the old code with as little editing as possible. Going forward, I do intend to more fully embrace FB for new development. I have used VB and other newer BASIC dialects (along with a lot of other languages, but that's another story). I do also expect to revisit a lot of these old library functions to take advantage of the more advanced FB features (like access to more memory for sort routines).

It turned out the dots weren't the issue, but I did assume I could swap them for underscores if it came to that. As you say, a fairly quick search/replace, but I'm still glad that's not a conversion step I'll have to take.

[MrSwiss]

Sorry but I don't understand that remark:

I am converting a few hundred thousand lines of old QB code before MS finally removes 16 bit support.

since, that has been removed a long time ago (>= Y2K - Win2000 - Win_NT 5.0). 32-bit or 64-bit.
Even FB-DOS is 32-bit ...

I've heard the "first pass story" too many times, to belive, that the implied "second pass" ever takes place.
(lets face it, it means more or less: double effort needed, twice: learning/doing it)
Just meant to be solid advice, the decision is yours of course.

[mmbcastle]

Sorry but I don't understand that remark:
I am converting a few hundred thousand lines of old QB code before MS finally removes 16 bit support.
since, that has been removed a long time ago (>= Y2K - Win2000 - Win_NT 5.0). 32-bit or 64-bit.
Even FB-DOS is 32-bit ...

Actually, in Windows 32 bit it's fairly easy to enable built-in 16 bit support. Text based applications still function perfectly well. The old games I wrote mostly don't work, but I can dump them in a DosBOX if I want to revisit them. Microsoft is in the process of dropping support for 32 bit Windows, which will finally end MS support of 16 bit. I have task scheduling, file conversion and direct mail presort software that is still an integral part of my business that runs 24/7. Which ironically, means I have a codebase which had it's origins in 1987 that is supporting the backend processing of websites, making PDFs, etc.

I've heard the "first pass story" too many times, to believe, that the implied "second pass" ever takes place.
(lets face it, it means more or less: double effort needed, twice: learning/doing it)
Just meant to be solid advice, the decision is yours of course.

Yes. I expect I won't revisit 95+% of the old library code after the initial conversion. That's kind of the point of a library, and especially this conversion; write it and forget it. If I can drag these old applications into the 21st century and still use them as a foundation for future work, that saves a tremendous amount of effort to port all this code. I'm already anticipating scores of hours of rework just because FB doesn't support the old QB FIELD statement. Fortunately, that's one of the things I have in my library; externally defined, data file management. I can just convert to my own tools instead of getting locked into the FB syntax.

[MrSwiss]

Just keep in mind, that -lang "fblite" and -lang "fb", do use different default "calling conventions".
(especially important in libraries, is "equal calling conventions" than "main-code")

[jj2007]

Microsoft is in the process of dropping support for 32 bit Windows, which will finally end MS support of 16 bit.

I have a 1MB source that compiles to a 480k 16-bit exe with sophisticated graphics. It won't run on 64-bit Windows, of course, but it runs fine on Oracle's VirtualBox with a 32-bit XP guest OS.

[mmbcastle]

Yeah. We have some things we run in VM's and they work ok on the "yes it runs" level (like VB 6). We've tried to do that on the main production programs too, but it didn't deliver the performance we needed. It's not too unusual for a customer to drop in 50,000 addresses that need postal presorts done and returned within 30 minutes. That doesn't sound like too big a deal, but in a VM it could take 30 minutes to sort 20,000 records, and we have to sort that file several different ways for the various final presort reports (and yes we will recode it as a database application one of these days so most of the sorting happens during the import). The job scheduler can (and often does) launch several different cmd windows for various tasks on one customer and/or multiple customer files that may be in house at one time.

In native 16 bit QB in a cmd prompt, it can sort 60,000 records in 11 seconds. I'm very interested in seeing how the FB version will perform, especially once we can access more memory. We're doing that with 32k available RAM for a string array. Depending on the key length, we read in a maximum of 4,000 records at a time into memory, then "shuffle merge" those into an index output file. From what I can tell, we should be able to access 1+MB in the RAM buffer under FB, so that will be crazy.

[jj2007]

Is there a compiler directive, switch, etc to have FB not treat dots as whitespace in names?

For example, I'm converting a lot of old code, and some of the function names look like...

public SUB READ.MULTIKEY(KEYFILE$,DATA.KEYS%(),mkMASK$(),TOTKEY%,NUMKEYS%) STATIC
public SUB FORMAT.SORT.KEY(NUMKEYS%,DATA.KEYS%(),mkMASK$(),BKEY%,LKEY%,DATA.TYPE%,MASK$,FMTKEY$) STATIC

When I compile these, it doesn't like the function names because it sees "MULTIKEY" and "FORMAT" as the identifiers (which clash with keywords), rather than the full names.

You should convert all READ.MULTIKEY etc to READ_MULTIKEY. That might take a second or so for a one MB source.

It's not too unusual for a customer to drop in 50,000 addresses that need postal presorts done and returned within 30 minutes.

Sorting a Million records of a tab-delimited file by some column (address, ...) takes typically one second. Something seems not to work as it should. Can you elaborate how your files look like, and how you proceed to sort them?