[fpc-devel]BUGS!

[Michael.VanCanneyt at Wisa.be]

On Mon, 19 Nov 2001, Alan Grimes wrote:

> However I must report a few problems I have with it:
>
> 1. The source distro doesn't install on 8.3 systems. I can unpack the
> source directory manually and everything seems to be in order, but I
> don't expect that I will be able to exparament with it in its present
> form...

All files that should be compilable on DOS do have the 8.3 format; This
includes at least the RTL and compiler. try the following:
(assuming you have a unix-like find installed)

find rtl -type f | check83
find compiler -type f | check83

With check83 the following little proggy:

program check83;

uses sysutils;

Var
 S,F : String;
 P : integer;

begin
  While not eof do
    begin
    Readln(s);
    F:=ExtractFilename(S);
    P:=Pos('.',F);
    If (length(F)>12) or
       (P>9) then
      Writeln(f,' ',P);
    end;
end.

The program doesn't report any errors here, so the filenames are OK.
There are some files that are reported as errors in the FCL, but these
will not work on DOS anyhow, so...

We do try to take this into account.

>
> 2. The source directory is very difficult to navigate. It is almost as
> bad as /usr/bin under Unix. A well written "map" or "index" file should
> be added with all haste. Additionally, it appears that certain machine
> and OS specific files are held in the general directory. This only adds
> to the clutter. I suggest a structure somewhat like this:
>
> /source/compiler/
>       |-IA32
>       |  |-- DOS  (Optionally; just having OS files in their prcessor
>                   categories should be sufficient. )
>       |  |-- Linux
>       |  |-- FreeBSD
>       |  L-- That other OS from Redmond...
>       |-PPC
>       |  |- OS X

The 1.1 development branch already has a changed structure which goes in
this direction. Not quite, but mostly.

> etc....
>
> 3. Documentation (Part I): The documentation is the best I've seen in
> years but still it has a few things which could be better:

In fact, it is SO good, that a publishing company refused to publish it
since they expected not to make money on it, as it's already freely
downloadable...

:-)

>
> Section 1.3: This list is nearly identical to the handout I got in
> highschool back in '94... =P   Unfortunately, one needs to go rummaging
> through the rest of the document in order to find the discussion of
> these keywords. Saying something like:

Please indicate which manual and the title of the section.
The section numbers aren't fixed.

>
> "ASM  (Pg.40)
>  Begin (Pg.35)
>  Break (Pg. 63)"
>
> would be a great improvment.

If you are referring to the list of reserved keywords, then the page numbers
will not be added; They would confuse matters IMHO.

You can, however, look in the index for the page numbers, that is what an
index is for.

>
> 4. Documentation (part II): While your syntax diagrams are a nice
> innovation (Its the first time I have read a language text that used
> them), A thourough discussion of the *symantics* of the varrious
> language features seems to be missing. Of particular interest to me is
> what exactly "PROGRAM" means to the compiler.

That an executable module follows, of course ? I don't understand what
you mean with this. Could you give more examples ? I'll be glad to add
more explanations.

>
>
> Okay, that's enough "bugs"; My plans for the system is to fork a version
> that I will call "Spherical", Its runtime environment will be used as
> the kernel of my Sphere Operating System. The root environment will NOT
> support the "program" type, rather software written to run at system
> level must use a new "SPHERE" outline. Sphere is/will be a system
> oriented operating system.
>
>
> --
> Waiting for a typical DOS application to crash is like waiting for hell
> to freeze over.

i.e about every hour. You should read Damon Knight :) (or was it Asimov?)

Michael.