HLA v2.0 progress report

[Randall Hyde]

Hi all,
Yesterday I "ported" the current HLA v2.0/ADK code base over to Linux. Largely, the work consisted of four things:

1. Converting a small win32-specific routine that processed memory-mapped files to use the HLA stdlib code for memory-mapped files (originally, HLA v2.0's memory mapped code was written before this functionality was added to the stdlib, which is why HLA v2.0 didn't use the stdlib code in the first place; indeed, the need for this in HLA v2.0 is why this functionality was added to the HLA standard library).

2. Commenting out the code that computes the number of lines/second compilation rates in the compiler (well, #IF'd out, when compiling under Linux). The problem here is that I've never ported the HLA stdlib timer class to Linux (which the compile rate computation uses).

3. #IF'd out a reference to stdout.handle (which is meaningful only under Win32).

4. Wrote a "getFullFilePath" function for Linux (Win32 API provides this, had to provide it myself under Linux).

After the above, the HLA v2.0 compiler compiled and ran under Linux. All in all, about 300 lines of code had to be changed, commented out, or written. Not bad for over 90,000 lines of source code :-)

At some point in the next day or so, I'll port the HLA v2.0 test suite to Linux (this should mainly consist of writing a script to convert all the Windows CRLF text files to Linux LF files) and the port to Linux will be complete.
Cheers,
Randy Hyde

[Sevag.K]

At some point in the next day or so, I'll port the HLA v2.0 test suite to Linux (this should mainly consist of writing a script to convert all the Windows CRLF text files to Linux LF files) and the port to Linux will be complete.
Cheers,
Randy Hyde

Correct me if I'm wrong, but Linux seems able to handle the Windows CRLF just fine without conversion.  The KDE editor I use loads MS-DOS text files and saves
in the same format and HLA-linux  is able to process it.  You may not need to convert the files!

[DarkWolf]

Converting the files is not a bad idea.

Not all linux users have KDE editor, what if they are GNOME users ?
Or fluxbox, blackbox, etc... ( see where I'm going with this ? ).

Not all desktops/distros may necessarily come with an editor that automagically converts MS text files.
Converting them might still be a good idea, besides if all it takes a simple script to replace the eol character why not ?

[Randall Hyde]

At some point in the next day or so, I'll port the HLA v2.0 test suite to Linux (this should mainly consist of writing a script to convert all the Windows CRLF text files to Linux LF files) and the port to Linux will be complete.
Cheers,
Randy Hyde

Correct me if I'm wrong, but Linux seems able to handle the Windows CRLF just fine without conversion.  The KDE editor I use loads MS-DOS text files and saves
in the same format and HLA-linux  is able to process it.  You may not need to convert the files!

HLA is also pretty good about handling CRs in the text file. However, not every editor out there is as forgiving as the KDE editor. Besides, Linux purists tend to get upset when they see CRs scattered through the file.

On a different note, the main thing holding up the port right now is that I've got to port the HLA stdlib fileclass to Linux (should have been done a long time ago, but I completely missed the fact that it's Windows only). I need this in order to run the HLA v2.0 test suite.
Cheers,
Randy Hyde

[Sevag.K]

I just realized a potential problem... actually it's a problem that I got and solved by fluke
without realizing what was causing it.

Until now, I assumed linux text files would always have $0A and Windows/DOS text files
$0D0A as line breaks and wrote my programs with that assumption.

Sort of like:

// skip over EOL to start of next line
#if (os.win32)
    add (2, esi);
#elseif (os.linux)
   inc (esi);
#endif

I'll have to change my strategy:  Search for $0A to find EOL, then compare
[esi-1] with $0d to determine if I'm dealilng with DOS text files then subtract
from the current char pointer to grab a substring consisting of a single line.