Hello, everyone!
Some of you might still remember me. From about 1995 to 2001 I was
the main GPC developer who implemented BP-style units, objects, and
other things. I am still hosting the GPC web pages, this mailing
list, etc.
In 1998 I started my own company (G-N-U GmbH, http://www.g-n-u.de)
doing business on free software. Our product range includes
professional service for GNU Pascal, developing and customizing
free software, and other services.
For a while, GNU Pascal was a very …
[View More]important tool for my company,
which justified that I invested a lot of time and money into it.
However, over the years more and more customers addressed me with
other needs.
Meanwhile, GNU Pascal has reached a point where it needs full-time
attention by an experienced GPC developer for several months.
1. The GCC backend is drifting away. Even if we just want to keep
the existing language alive, without aiming at extensions, we
need to transplant it onto a new, long-time stable backend.
2. It is very difficult for GPC enthusiasts to join the development
team, since GPC is written in C rather than Pascal.
Realistically, only Waldek, Frank, and/or myself can replace the
GPC backend or rewrite the GPC frontend in Pascal without breaking
the compiler. However all three of us face the necessity to make a
living and thus cannot afford to do that large amount of work just
for fun. It needs to be funded.
I suggest to concentrate our forces on problem 2 and to rewrite the
GPC frontend in Pascal without any backend. This gives you, Pascal
programmers using GPC, the opportunity to watch the emerging new
compiler and to become a GPC developer. Once this step is completed
and the new compiler can represent a Pascal program in memory, the
(hopefully enlarged) GPC development team has a free choice which
backend(s?) to implement.
If GNU Pascal is important for you, please consider to invest into
its future by funding our work on GPC.
You can contact me either on this list or in private email.
Encrypted mail is welcome. Please find my public key at:
http://www.peter.gerwinski.de/peter-gerwinski.public-key.asc
Greetings,
Peter
--
Dr. rer. nat. Peter Gerwinski - http://www.peter.gerwinski.de
G-N-U GmbH - First Class IT Services - http://www.g-n-u.de
German pages for GNU & free software - http://www.gnu.de
GNU Pascal - http://www.gnu-pascal.de
[View Less]
On Sat, 14 Aug 2010 04:17:58 pm Rugxulo wrote:
> Hi,
>
> On 8/13/10, Steven D'Aprano <steve(a)pearwood.info> wrote:
> > But we're not discussing what "should be", but what *is*,
>
> Even if we cared enough to find out (and apparently none of us do, or
> don't know who to ask), the way it *is* could change yet again by the
> time we finish GPC 2015.
Yes. So what? You have to consider the laws as they are *now*, not how
they might be some time in the indefinite …
[View More]future.
> Besides, like I said, what if your country
> doesn't approve of such laws?
Then you won't be infringing your own country's laws, and you have
nothing to worry about so long as you don't distribute the software in
countries where it is infringing.
[...]
> > and the legal
> > reality is that works like P5, even without a copyright notice,
> > *are* copyrighted and will remain so for the foreseeable future.
>
> P5 is Scott's (heavy) modification. I don't know if it's enough to
> constitute a whole "new" work or just another derivative.
It's a derivative.
> He says his work is PD.
If he is infringing the P4 copyright, he doesn't have the right to write
P5 in the first place, let alone to put it into the public domain.
I don't equate copyright infringement with theft, but the analogy
sometimes is useful. If you steal a diamond, and put it into a ring,
and then give that ring away, the recipient is still receiving stolen
goods. The excuse "But Scott said I could have it" is worthless. (The
excuse "but I didn't know it was stolen" *might* help, but that's not
always a given, and regardless, you don't get to keep the ring.)
> And
> Pemberton publishes his book online for free now (though he didn't
> write P4 himself, right??). That should tell you something, even if
> it's not legally airtight.
No, it doesn't tell you anything. "You can download this book for free"
is not the same as "You can write derivative works from this" or "you
can re-distribute it". These are separate rights.
> (Scott says several commercial compilers
> used P4 as a basis. So apparently they didn't mind!!)
Scott has no credibility in my mind. The legal theories he has been
promoting in this thread are beyond ridiculous, e.g. the theory that
works enter the public domain if you *know about* (not even approve of,
or give permission to, but merely *know*) somebody -- anybody -- giving
away copies for free.
> > That means
> > that using such a work puts you in legal jeopardy unless you get an
> > explicit licence to use it.
>
> Right, but who to ask? I assume Pemberton, he should know better than
> any of us. But if even he didn't write it, how can we be sure who
> did?
Ask the author if he is the copyright holder, and if so, what rights is
he willing to give.
--
Steven D'Aprano
[View Less]
Argh, did it again, sent to wrong address.
---------- Forwarded message ----------
Hi,
On 8/13/10, Steven D'Aprano <steve_AT_pearwood_DOT_info> wrote:
>
> But we're not discussing what "should be", but what *is*,
Even if we cared enough to find out (and apparently none of us do, or
don't know who to ask), the way it *is* could change yet again by the
time we finish GPC 2015. Besides, like I said, what if your country
doesn't approve of such laws? It really pains me to hear that …
[View More]such and
such is illegal (only) now or such and such a country doesn't follow
this or that the U.S. is more strict, etc. Sure, if you think "all the
world's U.S./Europe", it simplifies things, but it doesn't truly solve
it.
> and the legal
> reality is that works like P5, even without a copyright notice, *are*
> copyrighted and will remain so for the foreseeable future.
P5 is Scott's (heavy) modification. I don't know if it's enough to
constitute a whole "new" work or just another derivative. He says his
work is PD. So we'd only have to worry about the "old" P4 bits. And
Pemberton publishes his book online for free now (though he didn't
write P4 himself, right??). That should tell you something, even if
it's not legally airtight. (Scott says several commercial compilers
used P4 as a basis. So apparently they didn't mind!!)
> That means
> that using such a work puts you in legal jeopardy unless you get an
> explicit licence to use it.
Right, but who to ask? I assume Pemberton, he should know better than
any of us. But if even he didn't write it, how can we be sure who did?
> If you, or somebody else, chooses to take that risk, then by all means
> do so. Just do so with full understanding that you *are* infringing
> copyright, and even if the author is happy to turn a blind eye, the
> copyright holder might not be.
I have no intention of screwing over anybody. But we're talking about
something very small and old. Doesn't mean legal wars haven't been
waged on similarly old or small stuff, but still ... it doesn't seem
like it's THAT big a deal!
> As for the rest of the debate... well, it's too long, too rambling, the
> analogies you make are strange, and none of it really matters.
Okay, so I ramble, and my analogies suck. Sue me. (Oh wait, that's not
illegal.) ;-)
> We're
> not designing our perfect copyright law, nor are we documenting all the
> crazy things people do. We're trying to help Frank decide what the
> future of gpc should be.
Clearly Scott (who is clearly intelligent) thinks P5 is worthwhile.
Frank (also intelligent) would prefer to go another direction. That's
his right. The point is that if we want a (classic / standard) Pascal
written in Pascal, P5 would probably be a good starting point.
Otherwise it might be better just to modify FPC to add an ISO 10206
mode.
[View Less]
Bah, silly reply sent only via private mail (Gmail's fault). I'm not
egotistical to expect this post to be worth anything, but here ya go
anyways ....
---------- Forwarded message ----------
From: Rugxulo <rugxulo(a)gmail.com>
Date: Thu, 12 Aug 2010 23:55:07 -0500
Subject: Re: Quo vadis, GPC?
To: Steven D'Aprano <steve(a)pearwood.info>
Hi,
On 8/12/10, Steven D'Aprano <steve(a)pearwood.info> wrote:
> On Fri, 13 Aug 2010 02:26:41 am Rugxulo wrote:
>
>> It may be …
[View More]true that now all work is by default copyrighted. I'm not
>> even sure you can PD software in some countries (ugh). But most
>> important is the original author(s)' intent.
>
> That is possibly the LEAST important factor. What the original author
> wants doesn't matter. What matters is what the current copyright holder
> thinks, and what the law says.
You're right, good point, BUT copyright was never meant to be extended
indefinitely. And there are a lot of crazy laws. You can't please
everybody, even if you try. It's a minefield. I'm not saying you
shouldn't try, but pretending that a law (standard) matters over what
most people think (Borland) is naive at best. Some people support the
law just because it's the law. Others follow what's good and decent.
(Yes, I have an unrelated grudge, heh, stupid law changed much to my
disadvantage in an extremely arbitrary way.)
For example, I personally disagree that anybody but Terry Welch
should've ever had the LZW patent, esp. since it was milked for twenty
years AFTER he died!! Somebody please tell me how that's fair. (BTW, I
hate software patents, just giving a lame example. If it doesn't help
the guy who invented it, what good is it?)
>> If they don't care,
>> nobody else will. It's not worth arguing over their "rights" when
>> they don't care anymore (or never did).
>
> That's simply not true. What happens when the author dies, and his heirs
> inherit ownership of the copyrighted work?
What happens when the compiler for the copyrighted work is no longer
available? What happens when the OS it ran on is no longer available?
What happens when it's no longer available for sale? What happens when
the cpu it runs on is no longer mass produced? (See, I can worry too!)
What happens if nobody remembers how to use it? What happens if
everybody is too busy arguing legalities to appreciate the gift horse
(and his mouth or whatever)?
> What guarantee do you have
> that they will be as easy-going with regard to copyright as the
> original owner? Without a licence from the original author, this
> becomes a clear and obvious case of infringement.
I agree that a clear statement would be best. But if you can't get
one, don't worry! No reason to assume the worst if you make a best
effort to find out.
BTW, many people have rescinded licenses for various things without
any good reason. And they scream and yell how they are allowed to push
people around. It's disgusting. "Oops, sorry, end users, we don't care
about you." Big surprise. It's not the first time nor the last.
> What happens if the work was written under the auspices of a university,
> which in 1972 was quite happy to let the author publish without a
> copyright notice, but in 2010 discover that under the terms of their
> employment contract at the time, they actually own the copyright, not
> the author?
Gross incompetence at best, flagrant misuse of copyright at worst.
Lucky for them it wasn't written in some extinct language! (How many
existing, popular Pascal compilers can build P4 out-of-the-box? If
it's only GPC, then I would find that highly ironic.)
> Or what happens if responsibility for enforcing copyright is separate
> from the creative act? You can have a situation where the left hand is
> explicitly encouraging people to use copyrighted material, while the
> right hand is threatening those same people for infringement.
Probably a good reason that companies shouldn't get exclusive rights
to all their workers' efforts. (How that's even legal is beyond me.
What they do in their free time should never be owned by anyone else.)
> A recent
> case, where the Discovery Channel's marketing department provided
> promotional material to a fan website, and the legal department then
> threatened them with a lawsuit and forced the owner to hand over
> ownership of the domain:
Trust me, I know of plenty of similarly crazy cases. I try not to
infuriate myself with too much of that. People are crazy and will do
crazy things whether it makes sense or not, legal or illegal, etc. The
world is broken.
> Don't imagine for one second that this is unique. I've even seen cases
> where the marketing department of a record label uploaded videos to
> YouTube, and the legal department then made DMCA claims and had their
> own videos removed. (I can't find the link right now, sorry.)
I've seen lots of crazy things too. Yes, big companies are crazy, and
the crazy laws that cater to them are just as bad.
> I note that you made a quip:
>
> You know what they say about "assume".
>
> and then immediately go on to advise us to assume that the absence of an
> explicit prohibition against copying a work is the same as permission
> to copy. That's terribly irresponsible. Under copyright law, it works
> the other way: in the absence of explicit permission, you are legally
> required to assume the prohibition stands.
Like I said, it's moot here since nobody here (except Scott) is using
P4 or P5 for a compiler. BUT, if we were, I would definitely ask Steve
P. (and whoever else) for some kind of reassurance. If that failed to
get any response, I would not worry and proceed as normal.
It's kinda funny that this comes up today. I've had a certain book in
my possession for months now because the person I returned it to (so
they could return it to their mother, who loaned it to me)
accidentally returned it back to me (!) and yet refused to retrieve
it! Am I legally bound to return what I already returned, even at my
own inconvenience? If so, how fast should I send it? I already told
them twice about it, and they gave me the runaround. I finally just
said, "Forget it, I'll mail it directly." Had to do it myself, they
weren't responsible enough to do it! (Note that this book was only $15
new, which is very small claims at best. How much is a compiler [or
more specifically, P4] worth to you??)
I also had some really old baseball cards I assumed for YEARS belonged
to a distant family member, but that person never stayed in contact
with me. (I am much younger.) I never could even confirm whose they
were, much less what to do with them. I finally shipped them off to
the "nearest" other relative I could find. Legally, I have no idea
what I would be required to do, but I did my best to be fair (even if
it took like twenty years, and note that I'm only 31, heh).
So yes, I do indeed care, but often times it's worrying over nothing.
If nobody complains about something you ALREADY have in your
possession, why would they complain once you do something with it?
(Did Pemberton's publisher care to get the original authors' explicit
permission? If they didn't care, why should we? For laughs???)
[View Less]
Frank Heckenbach wrote:
> since GPC development has mostly stalled, I've thought about if and
> how its development could be continued. Here are my current thoughts
> about it. Since the text is quite long, I put it on the web:
> http://fjf.gnu.de/gpc-future.html
Although I no longer use Pascal, I would like to make a plea for GNU
Pascal to be sustained.
Generating C (or even C++) as an alternative target is certainly a
useful feature for any compiler to have but if GPC was to …
[View More]lose its
interface to the GCC back-end, I wonder if it would still be GNU
Pascal. I believe most people associate GCC back-end support with any
compiler that carries the GNU moniker.
Don't get me wrong, I am not a GNU fanboy nor a GCC zealot. I know
that developing for the GCC back-end can be painful. Nevertheless, I
believe it would be a loss for the Algol/Pascal family of languages
and their users to see Pascal disappear from the list of supported
languages in the GCC toolbox.
It is correct that the existing code will remain available but without
maintenance, GNU Pascal would eventually cease to work with the latest
GCC distribution.
GNU Modula-2 is now very close to its 1.0 release at which point it is
expected to become part of the main GCC distribution. It would be sad
to see Pascal leave the GCC party just as Modula-2 joins.
It is not uncommon that a project maintainer burns out after a decade.
Nobody can blame you for that. Perhaps somebody else can be found to
take over the project and continue it.
As for retargeting GNU Pascal, I personally would consider that a new
project. How much sense it would make to reuse the GNU Pascal front
end for a new compiler project to target a different back-end I am
unable to say. However, I can comment on targeting the LLVM compiler
infrastructure.
First, some clarification. Some posters appear to be confused about
what LLVM is. For example, I saw one commenter writing "I am not
interested in programming in ... LLVM". The LLVM compiler
infrastructure is not a programming language you would write programs
in. Instead, it is a compiler-back end library that compiler
developers can use to plug their compilers into thereby saving
themselves the effort to write their own target specific back-ends and
optimisers.
Compared to using the GCC back-end, LLVM is far more straightforward.
There are two ways to interface to it. You can either use the C or C++
bindings and generate your LLVM AST directly from within your own
parser, or you could write a back-end for LLVM pseudo-assembly code
which is actually far cleaner than C or C++. It is a typed virtual
assembly language that has atomic intrinsics and trampolines and a lot
of other useful things.
I am currently involved in a Modula-2 compiler project that targets C
and LLVM (via the LLVM pseudo-assembly language). We are using a
template approach for code generation and for each AST node a
corresponding C or LLVM template is populated with the details from
the AST node. So far code generation has only been in an experimental
stage but I can already tell you from this experimental experience
that targeting LLVM is certainly far more straight forward than
targeting the GCC back-end.
It would certainly be nice to see a Pascal compiler targeting LLVM but
as I said, this should probably be considered a new project and no
longer GNU Pascal. Even with an LLVM Pascal compiler available, I
still believe it would be beneficial to sustain GNU Pascal (as a
Pascal compiler targeting the GCC back-end).
Anyway, good luck to you and the GNU Pascal community
--
Projects mentioned in this post:
GNU Modula-2 (http://www.nongnu.org/gm2)
LLVM Compiler Infrastructure (http://llvm.org)
Objective Modula-2 (http://objective.modula2.net)
Modula-2 R10 (http://www.ohloh.net/p/m2r10)
[View Less]
Bastiaan Veelo wrote:
> We have an extensive code base of Extended Pascal that is in active use
> commercially, and we will continue development in many years to come. We
> are using the Prospero compiler, which is still serving our needs. But,
> as Prospero is Windows-only, gpc has always appeared as the most
> promising escape route to portability, should we need it. Therefore I am
> hoping that gpc will find its way into the future.
>
> I have a small …
[View More]contribution to the discussion. Regarding the suggestion
> of turning gpc into a translator to some other language, I would suggest
> considering the D programming language as the target language, instead
> of C++. I have been following the development of D for many years, and
> have always seen similarities between Extended Pascal and D. Off the top
> of my head there are nested functions, modules, function argument
> storage classes, better type safety than C++, dynamic arrays with size
> information, and fast compilation (especially compared to C++). There
> may be more similarities. D's template design is also much better than
> C++'s, as is its approach to const-correctness and its alternative to
> multiple-inheritance. D is designed to be a better language than C++,
> and I think it is. I think that of modern languages D is most compatible
> to the way Pascal programmers like to think (pardon the generalization)
> and although its syntax is C++-inspired, D might be a good candidate to
> "take over" from Pascal. If gpc would do a good job at generating
> readable D code, Pascal programmers could choose to continue writing
> Pascal or make the switch to D completely and be happy with it.
>
> Some pointers:
> http://en.wikipedia.org/wiki/D_%28programming_language%29
> http://www.digitalmars.com/d/
As for the main features as listed in the Wikipedia article:
- some are mainly library issues or can be addressed as such,
including associative and dynamic arrays (e.g. map and vector in
STL) or array slicing (not sure if STL currently provides this,
but it could),
- some of the mentioned improvements actually exist in C++ such as
inner classes and the previously mentioned STL types,
- some things will be addressed in the planned C++0x standard
(http://en.wikipedia.org/wiki/C%2B%2B0x), e.g. foreach-like loops,
better metaprogamming including compile-time function execution,
and anonymous functions, including nested ones and closures,
- some things I don't necessarily see as advantages for our
purposes, e.g. automatic gargabe collection (on a (Pascal)
language level, I think we should leave the choice to the user),
or limited multiple inheritance (though I hardly need the full
version myself, but if we choose to implement just the limited
form, we can do it equally well in C++ and D, since it's a strict
subset of the full version; but if we, now or later, decide we
want the full form in some object model, C++ has it),
- for some things the description there is too vague, e.g.
"reengineered template syntax" (the example doesn't tell me much
-- however, if it's only about syntax, it doesn't matter much for
a target language anyway) or the inline assembler (g++ has one, I
have no idea if D's is better or worse -- mostly likely it won't
be (CPU-)portable (quite hard for assembler code ;-), and apart
from that, I see no major drawbacks in the g++ inline assembler
(same as that in gcc and gpc), except maybe from syntax
(irrelevant, see above); in particular it cooperates well with the
optimizer which is not true of many other inline assemblers I've
seen, in particular BP's, even for that tiny bit of optimization
that BP has),
- so only a few things are left that are clearly advantages in my
view, e.g. true modules and first class arrays. (Though modules
are not such a big issue for a compiler-converter either;
converting to C++ style "compilation units" and headers is not
much more difficult, and the more tricky part -- processing
modules in the correct order WRT dependencies -- has to be done in
the frontend anyway; this is what "gp" currently does which could
partly be reused as well.)
But most importantly of all (IMHO), D doesn't seem very widespread.
Maybe this will change. However, since one root of our problems is
really that Pascal isn't so widespread (anymore), I'm reluctant to
base its renewal on another language whose long-time future is also
in doubt AFAICS. Honestly, if I had to bet on the futue of D vs.
C++0x, I'd take the latter, even if it's still in the
standardization process, just because of the mass of existing C++
code and compilers. (And even if C++0x fails, the fallback to the
existing C++ standard is soft, whereas a failure of D a few years
from now when we have based our new compiler on it would be fatal.)
Of course, for manually (or semi-automatically) converting your
Pascal programs to another language if GPC has no future, D might be
a good choice.
Frank
--
Frank Heckenbach, f.heckenbach(a)fh-soft.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: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8
[View Less]
Here's a puzzle in the from of a program.
Regards to all!
Tom
program inout (input,output);
(* version = 1.01 of inout.p 2010 Aug 12
2010 Aug 12, 1.01: testing on Sun
2010 Aug 12, 1.00: origin on mac
Thomas D. Schneider, Ph.D.
National Institutes of Health
Gene Regulation and Chromosome Biology Laboratory
schneidt(a)mail.nih.gov
http://alum.mit.edu/www/toms (permanent)
Test input string in GPC.
The program reads one character from the user at a time. If the user
types the wrong …
[View More]character and wishes to correct it, then they should
be able to type control-H (^H) or delete and correct the input. This
works with GPC on a Sun computer, but on a Mac OSX (10.6.2) one
instead sees '^H' and no backspace occurs.
What can be done at compile time to make backspace work on the Mac?
********************************************************************************
On a Sun computer:
% inout
h
the character was h
u
the character was u
b
the character was b
z
the character was z
a
the character was a
b
the character was b
q
the character was q
Backspace (control-H) and delete work as expected.
On a Mac:
% inout
a
the character was a
abcd
the character was a
abcd^H^H^H^H^H^H^H^H control H or delete gives same^H^H^H
the character was a
q
the character was q
Backspace (control-H) and delete do not work.
*)
var
n: char; (* a character from the user *)
begin
n := ' ';
while (n <> 'q') do begin
readln(input, n);
writeln(output, 'the character was ',n);
end;
end.
[View Less]
I've been following the debate with some interest - although I'm no
expert on compilers.
My work involves a lot of data processing, for which I use Python
scripts from which I can call functions coded in Pascal (and other
languages).
The interfacing works as follows: Pascal modules are linked statically
to some C interface code (which converts Python objects to/ from C
types). The C interface code is compiled to Python compatible DLLs,
which can be imported directly into Python. I'm sure …
[View More]there are other
ways to achieve the same end (and it would be nicer to be able to do the
conversion to/from Python objects in Pascal) - but it works. I use the
MinGW compiler to compile my code. The extensions work with the standard
(MSVC) Python distribution.
As long as there is a straightforward means of creating Python binary
extensions from Pascal source code I'll be happy - but since Python is
written in C the C++ solution sounds more promising, so I will vote for
that.
Andrew.
http://www.npl.co.uk/materials/http://www.npl.co.uk/electromagnetic/
-------------------------------------------------------------------
This e-mail and any attachments may contain confidential and/or
privileged material; it is for the intended addressee(s) only.
If you are not a named addressee, you must not use, retain or
disclose such information.
NPL Management Ltd cannot guarantee that the e-mail or any
attachments are free from viruses.
NPL Management Ltd. Registered in England and Wales. No: 2937881
Registered Office: Serco House, 16 Bartley Wood Business Park,
Hook, Hampshire, United Kingdom RG27 9UY
-------------------------------------------------------------------
[View Less]
First, everything in this message occurred while logged in as "root".
I think I've installed the compiler properly but the assembler always reports errors for "push" and "pop". Sample messages and the results when compiling with the -v option can be found below.
The platform is a HP xw8200 (Xeon) machine running 64 bit Red Hat Enterprise Linux Desktop, probably release 5.2. On this system "uname -a" produces:
Linux lxstn08 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:48 EDT 2009 x86_64 …
[View More]x86_64 x86_64 GNU/Linux
gcc was not installed on this system when gpc was loaded. Using the web page instructions for binaries at http://www.gnu-pascal.de/binary/ I installed the "gpc-2.1-with-gcc.i686-pc-linux-gnu.tar.gz" file into the standard location. After gpc was installed "man gpc" worked and "gpc -v" says:
gpc version 2.1 (20020510), based on 2.95.2 19991024 (release).
So far so good. Now the problem:
Compiling the absolute minimum version of "hello.pas" (1 writeln statement) produced ~15 assember error messages, a mixture of:
Error: suffix or operands invalid for "push" (and/or)
Error: suffix or operands invalid for "pop"
messages with about 4 times more "push" than "pop" messages.
Any ideas about how to fix this problem?
BTW, Although a 64 bit executable would be much preferred a 32 bit target that can run under 64 bit RHEL would also work for us.
----- BACKGROUND INFO
For safety, security, and configuration control reasons changing the RHEL components is not allowed. But installing applications (e.g. gpc, vnc, Open Office) that do not affect the O/S is OK.
"man as" says that binutils contains the portable Gnu assember.
My first thought was a 64/32 bit word length mismatch in a library, the compiler or the assembler. The "yum" results are at the end of this message.
Using the "-v" option produces (with <CR>s inserted for clarity):
# gpc -v hello.pas
Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs
gpc version 2.1 (20020510), based on 2.95.2 19991024 (release)
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/gpcpp -lang-pascal -v
-famtmpfile=/tmp/ccL8ikKt -fdelphi-comments
-D__GNU_PASCAL__ -undef -D__GNUC__=2
-D__GNUC_MINOR__=95 -D__GPC__=2 -D__GPC_MINOR__=1 -D__GPC_VERSION__=2.1
-D__GPC_RELEASE__=20020510 -D__BITS_LITTLE_ENDIAN__=1
-D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1
-D__NEED_NO_ALIGNMENT__=1 -D__ELF__ -Dunix -D__i386__
-Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__linux__ -D__unix
-D__linux -Asystem(posix) -Acpu(i386) -Amachine(i386) -Di386 -D__i386
-D__i386__ -Di686 -Dpentiumpro -D__i686 -D__i686__ -D__pentiumpro
-D__pentiumpro__ hello.p /tmp/cc3waT7h.i
GNU Pascal Compiler PreProcessor version 2.1 (20020510), based on gcc-2.95.2 19991024 (release) (i386 Linux/ELF)
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/local/i686-pc-linux-gnu/include
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/include
/usr/include
End of search list.
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/gpc1 /tmp/cc3waT7h.i -quiet -dumpbase hello.pas -version -famtmpfile=/tmp/ccL8ikKt -o /tmp/cc3waT7h.s
GNU Pascal version 2.95.2 19991024 (release) (i686-pc-linux-gnu) compiled by GNU C version 3.3.3.
GNU Pascal version is actually 2.1 (20020510), based on gcc-2.95.2 19991024 (release)
as -V -Qy -o /tmp/cc3waT7h1.o /tmp/cc3waT7h.s
GNU assembler version 2.17.50.0.6-12.el5 (x86_64-redhat-linux) using BFD version 2.17.50.0.6-12.el5 20061020
/tmp/cc3waT7h.s: Assembler messages:
/tmp/cc3waT7h.s:14: Error: suffix or operands invalid for `push'
/tmp/cc3waT7h.s:18: Error: suffix or operands invalid for `push'
... (about ~14 more "pop" and "push" error messages)
---
The man page for "as(1)" does not list the options -V or -Qy (used above). Also odd is that the "/usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2" folder contains "collect2" instead of "collect" - and that the file "/lib/crt[01n].o" does not exist on this system (or is the "gpc" man page out of date?).
I have downloaded but not installed the "gcc-core-2.95.2.tar.gz" compiler (from http://www.gnu-pascal.de/stable/). As suggested by the mailing list archives I have also downloaded a newer version of gpc and gcc from http://alignment.hep.brandeis.edu/Software/Pascal/Index.html (by using the "Linux binary", "GCC 3.4.6" and "GPC 20070904" links on that page). I then untarred gcc 3.4.6 into it's normal location (but "man gcc" and "gcc" still do not work). I have not yet tried installing the newer version of gpc.
yum reports the following packages as installed:
binutils.x86_64 2.17.50.0.06-12.el5 (missing i386 version?)
glibc.i686 2.5-42 (instead of i386 version?)
glibc.x86_64 2.5-42
glibc-common.x86_64 2.5-42
libgcc.i386 4.1.2-46.el5 (i686 version needed?)
libgcc.x86_64 4.1.2-46.el5
<EOM>
[View Less]
When I first started using FPC, I went through the manuals looking for
useful features. I came across both open arrays and dynamic arrays, and
thought that they might be valuable. But nowhere could I find any notation for
the second, third ... dimension of the array. Without that, open and
dynamic arrays were little more than curiosities, possibly useful for
1-dimensional array, but not beyond.
Now I see from your email that the notation for the second dimension of an
array is …
[View More]Length(xarray[i]) where i is any valid index value (and hence can
always be 0). By extension, the third dimension presumably would be
Length(xarray[0,0]), and so forth.
Never, ever, would I have guessed that would work. It makes sense
mathematically, but notationally I would have expected something like
Length(xarray,2) for the second dimension. If I had thought of Length(xarray[0]), I
would have deemed it so implausible that I never would have tried it.
But simply because this is feasible does not mean that one should use it.
For one thing, I would like the compiler to generate warning messages if I
try to add two matrices of incompatible sizes. I don't want to discover
this hours into a computation. That type of checking is one of the main
virtues of Pascal.
For another, it requires that I code a SetLength statement for every
array. That means the array information becomes decentralized. I can't just
read down the VAR section of my procedure and learn what I need about the
variables, I must consult two sections.
Of course I wouldn't have to make every array open, but then I would have a
mixture of two kinds of array declarations. This creates an extra
maintenance task, making some arrays open, when needed, and restoring them to
fixed size when they no longer need to be open. The problem could become
fierce when the same declarations are shared by several different procedures.
Which one should set the length? How can I be sure the length is set
before I reach MyProc?
So, once again, I throw my support towards adding vector operations to the
compiler.
Frank Rubin
In a message dated 8/6/2010 12:23:25 P.M. Eastern Daylight Time,
harley(a)umich.edu writes:
Dear Frank Rubin,
"Except that you have to code every single case separately, 2x6, 3x10,
4x4x4, etc. You need to write a separate routine for every shape of array
you
want to use."
Not so:
Use open arrays (always 0-based):
type Matrix = array of array of TRing;
Youu can write code, roughly:
operator * (const A, B: Matrix): Matrix;
var RowA, ColA, RowB, ColB,
I, J, K: Integer;
T: TRing;
begin
RowA := Length(A); ... ColB := Length(B[0]);
if ColA <> RowB then ...
SetLength(Result, RowA);
for J := 0 to RowA - 1 do SetLength(Result[J], ColB);
for I := 0 to RowA - 1 do
for K := 0 to ColB - 1 do
begin
T := Zero; // prefer just 0
for J := 0 to ColA - 1 do
T := T + A[I, J]*B[J, K];
Result[I, K] := T;
end;
end;
once and for all, covering all sizes of matrices.
The problem I do not yet know how to solve:
to do it for all TRing.
So I need a type TRing that can include any structure
that has + and * operators, and a 0 element:
Integers, Floats, Rationals, Gaussian Integers,
Polynomials with xxx coefficients,... any possible
data type I can define with overloaded +, *, etc.
Note that 0 is a problem in itself -- one really needs
to overload it too!
Frank Heckenbach's first reply to me may contain the answer.
I haven't completely digested it yet.
Cheers,
Harley
[View Less]