Re: Problems with installing GPC under Red

Tomasz Kowaltowski wrote:

> I installed  gpc-2.1-with-gcc.i686-pc-linux-gnu.tar.gz under my previous 
> Linux (Red Hat 8.) and it worked without any problems.
> 
> I did the same under Red Hat 9. When I tried to compile a program 'gpc' 
> complained:
> 
> gpc: installation problem, cannot exec `gpcpp': No such file or directory
> 
> I put then in /usr/local/bin a symbolic link:

I think this binary was broken. I've uplaoded a new one. Sorry for
the inconvenience.

Frank

--

-- 
Frank Heckenbach, frank <at> g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: 51FF C1F0 1A77 C6C2 4482  4DDC 117A 9773 7F88 1707

Re: function arcsin

Le Jeudi 29 Mai 2003 00:29, Frank Heckenbach a écrit :
> Boris Herman wrote:
> > >> If there's interest, I could add ArcSin and ArcCos to the runtime
> > >> library.
> > >
> > > This would be great!
> >
> > I've found out that I get more precision by using this self-written
> > function:
> >
> > function ArcSin(x:double):double;
> > const c1=1e-6;
> > begin
> >   if abs(x-1)<c1 then
> >    ArcSin:=pi/2
> >   else
> >    if abs(1+x)<c1 then
> >     ArcSin:=-pi/2
> >    else
> >     ArcSin:=ArcTan(x/sqrt(1-sqr(x)));
> > end;
>
> I hope Emil will comment on the numeric stability of this function
> etc. I'm a bit worried about the c1 definition. It might be suitable
> for the Double type on your platform, but I think a general function
> should try to work with MinReal, EpsReal etc.

This code gives only something like simple precision on my machine (AMD 
athlon, that is IEEE floating point arithmetic)

Re: Problems with installing GPC under Red Hat 9

Frank Heckenbach wrote:
 >
 > Tomasz Kowaltowski wrote:
 >
 > > I installed  gpc-2.1-with-gcc.i686-pc-linux-gnu.tar.gz under my 
previous
 > > Linux (Red Hat 8.) and it worked without any problems.
 > >
 > > I did the same under Red Hat 9. When I tried to compile a program 
'gpc'
 > > complained:
 > >
 > > gpc: installation problem, cannot exec `gpcpp': No such file or 
directory
 > >
 > > I put then in /usr/local/bin a symbolic link:
 >
 > I think this binary was broken. I've uplaoded a new one. Sorry for
 > the inconvenience.
 >
 > Frank

I tried again with:

gpc-20030507-with-gcc.i686-pc-linux-gnu.tar.gz

and

gpc-2.1-with-gcc.i686-pc-linux-gnu.tar.gz

Re: Problems with installing GPC under Red

Tomasz Kowaltowski wrote:

> I tried again with:
> 
> gpc-20030507-with-gcc.i686-pc-linux-gnu.tar.gz
> 
> and
> 
> gpc-2.1-with-gcc.i686-pc-linux-gnu.tar.gz
> 
> With both I get output like:
> 
> /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/libgpc.a(rts.o)(.text+0x465): 
> In function `_p_UpCase':
> /home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:871: undefined reference to 
> `__ctype_toupper'
> /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/libgpc.a(rts.o)(.text+0x485): 
> In function `_p_LoCase':

Looks like a glibc version conflict (I thought these days were over)
...

Unless someone has an idea how to build a binary as independent of
glibc versions as possible, I guess you might have to compile GPC
yourself (which is usually not difficult under Linux).

Frank

--

-- 
Frank Heckenbach, frank <at> g-n-u.de, http://fjf.gnu.de/, 7977168E

Re: 64 bit code generation

On Sat, 31 May 2003, Frank Heckenbach wrote:

> /var/tmp//ccrvtgAm.s: Assembler messages:
> /var/tmp//ccrvtgAm.s:7: Error: .COMMon length (-1894967300.) <0! Ignored.
>
> line 7:	.common	N,1999999996,4
>
> This size is correct, so I suppose the problem is with the
> assembler. You might need to get a 64 bit one (if it's a Solaris
> assembler), or try to compile binutils for 64 bit target (if it's
> using the GNU assembler).

Sorry, did not understand you last time. The source and assembler I have
sent is the version that compiles. Here goes the version that fails. The
only difference is the size of the vector. The assembler is the "GNU as"
and it is 64-capable. Other tools have been successfully compiled with it
on the system.

miklos

program prime;

const
 max=600000000;

var
 i,j:integer;
 n:array[2..max] of integer;

ArcSin, ArcCos

For now I'm using the libm routines, since I'm not convinced that
the alternatives are really better. For complex numbers, I'm adding
the following, rather simple, routines. If Emil (or someone else)
wants to provide more optimized/numerically stable versions, let me
know.

function Complex_ArcSin (z: Complex): Complex;
var t: Complex;
begin
  t := Ln (Cmplx (-Im (z), Re (z)) + SqRt (1 - Sqr (z)));
  Complex_ArcSin := Cmplx (Im (t), -Re (t))
end;

function Complex_ArcCos (z: Complex): Complex;
var t: Complex;
begin
  t := Ln (z + SqRt (Sqr (z) - 1));
  Complex_ArcCos := Cmplx (Im (t), -Re (t))
end;

Frank

--

-- 
Frank Heckenbach, frank <at> g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: 51FF C1F0 1A77 C6C2 4482  4DDC 117A 9773 7F88 1707

Overriding non-virtual methods by virtual ones

I recently came about the issue of overriding non-virtual methods by
virtual ones. GPC currently allows this, but it may be slightly
confusing. BP allows it as well, so we shouldn't forbid it. But
should we warn? (Always or unless `--borland-pascal' was given?)

type
  a = object
    procedure p;
  end;

  b = object (a)
    procedure p; virtual;
  end;

Frank

--

-- 
Frank Heckenbach, frank <at> g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: 51FF C1F0 1A77 C6C2 4482  4DDC 117A 9773 7F88 1707

Re: Overriding non-virtual methods by virtual ones

On 2 Jun 2003 at 21:34, Frank Heckenbach wrote:

> I recently came about the issue of overriding non-virtual methods by
> virtual ones. GPC currently allows this, but it may be slightly
> confusing. BP allows it as well, so we shouldn't forbid it. But should
> we warn? (Always or unless `--borland-pascal' was given?)

A warning except under '--borland-pascal' is fine. Another thing - an 
object with virtual methods but no constructor causes confusion under 
BP - e.g.,

type
  a = object
    procedure p;
  end;

  b = object (a)
    procedure p; virtual;
  end;

procedure a.p;
begin
  writeln ('a');
end;

procedure b.p;
begin
  writeln ('b');
end;

Re: Implicit length/upperbound declarations

CBFalconer wrote:

> Why not start the thinking from what is as compatible as possible
> with standard Pascal techniques.

Since you bring up the issue of ISO 7185 ("classic" Pascal) vs.
10206 (Extended Pascal) again, would you like to address the
following limitations of classic Pascal? (Excuse me if I sound a
little like Brian Kernighan, but I think these points are valid
criticisms of classic Pascal. Most of them have been addressed in
Extended Pascal -- and, I have to admit, most of them also in BP,
though often differently.)

- No variables of dynamic size. You can't, e.g., get a number of
  elements at runtime and do something with them.(*) Without using
  standard compliance level 1 (conformant array parameters), you
  can't even have routines that work on arrays of different size, so
  common routines have to be copied for each possible size.

  (*) The usually suggested work-arounds include:

  - Set a maximum size at runtime. This is suitable for demo and
    learning programs, not for the real world (unless perhaps the
    size is made unreasonably large, but this will waste too much
    memory).

  - Use linked lists. This works in some cases, but often it adds an
    O(n) factor to the complexity and is therefore inacceptable.

  - Use more complicated structures such as balanced trees. This

Re: 64 bit code generation

On Sat, 31 May 2003, Frank Heckenbach wrote:

Frank,

> line 7:	.common	N,1999999996,4

am I right to think that the elements of N are stored on 4 bytes according
to this notation? That would explain the size I can see on the "top" as
the memory allocation. On the other hand it is a bad news. N supposed to
be an integer, i.e. 2 bytes. The compiler allocates twice of the necessary
size for the array. It is not a problem for "normal" size arrays but it
could be a big problem for larger ones.

Cheers,

miklos