I have been wondering the same thing.

------------ KC7RAD -Ken Linder

On Tue, Dec 27, 2016 at 7:35 PM, Schneider schneidt@mail.nih.gov wrote:

Has GPC been abandoned?

https://en.wikipedia.org/wiki/GNU_Pascal

"as of July 2016 no further releases or announcements had been made."

Tom

Thomas D. Schneider, Ph.D. Senior Investigator National Institutes of Health National Cancer Institute Center for Cancer Research RNA Biology Laboratory Molecular Information Theory Group Frederick, Maryland 21702-1201 schneidt@mail.nih.gov https://schneider.ncifcrf.gov (current link) https://alum.mit.edu/www/toms (permanent link)

---

Gpc mailing list Gpc@gnu.de https://www.g-n-u.de/mailman/listinfo/gpc

Have you tried contacting Peter, "The African Chief" or any of the other people that worked on the compiler?

If no one is responding, perhaps I should get a snapshot of all the files on www.gnu-pascal.de . Wouldn't want the entire thing lost.

-Ken

On Tue, Dec 27, 2016 at 9:39 PM, Schneider schneidt@mail.nih.gov wrote:

Ken:

...

I have been wondering the same thing.

It's not functional on Mac OS X for more than a year and the guy responsible for it doesn't respond.

Tom

Thomas D. Schneider, Ph.D. Senior Investigator National Institutes of Health National Cancer Institute Center for Cancer Research RNA Biology Laboratory Molecular Information Theory Group Frederick, Maryland 21702-1201 schneidt@mail.nih.gov https://schneider.ncifcrf.gov (current link) https://alum.mit.edu/www/toms (permanent link)

It would be nice if we could find something on the website more recent than 2005 (perhaps a changelog and links to the current codebase); maybe some instructions on how to get GPC to compile with GCC 5 and 6, or at least a sense of how one would go about creating the necessary patches to the latter.

Personally, I would be overjoyed if I had some time to contribute to GPC development, but I work too many hours at my regular job to consider it at the present time; but perhaps there are some small things that some of us could do to move things along at the rate of an hour or two a week per person.

--------------------------| John L. Ries | Salford Systems | Phone: (619)543-8880 x107 | or (435)867-8885 | --------------------------|

On Wed, 28 Dec 2016, Prof Abimbola Olowofoyeku wrote:

What (apart from that which is already well documented about the current state of the development efforts) would you like to ask us?

Regards The chief On 29 Dec 2016, at 03:43, Ken Linder kc7rad@gmail.com wrote: Have you tried contacting Peter, "The African Chief" or any of the other people that worked on the compiler? If no one is responding, perhaps I should get a snapshot of all the files on www.gnu-pascal.de .  Wouldn't want the entire thing lost.

-Ken

On Tue, Dec 27, 2016 at 9:39 PM, Schneider schneidt@mail.nih.gov wrote: Ken:

  > I have been wondering the same thing.

  It's not functional on Mac OS X for more than a year and
  the guy
  responsible for it doesn't respond.

  Tom

    Thomas D. Schneider, Ph.D.
    Senior Investigator
    National Institutes of Health
    National Cancer Institute
    Center for Cancer Research
    RNA Biology Laboratory
    Molecular Information Theory Group
    Frederick, Maryland  21702-1201
    schneidt@mail.nih.gov
    https://schneider.ncifcrf.gov (current link)
    https://alum.mit.edu/www/toms (permanent link)

---

Gpc mailing list Gpc@gnu.de https://www.g-n-u.de/mailman/listinfo/gpc

That's pretty much what I was looking for on the subject of "how to get GPC to compile with a given version of GCC". Thanks.

--------------------------| John L. Ries | Salford Systems | Phone: (619)543-8880 x107 | or (435)867-8885 | --------------------------|

On Thu, 29 Dec 2016, Waldek Hebisch wrote:

John L. Ries wrote:

...

It would be nice if we could find something on the website more recent than 2005 (perhaps a changelog and links to the current codebase); maybe some instructions on how to get GPC to compile with GCC 5 and 6, or at least a sense of how one would go about creating the necessary patches to the latter.

I a sense porting process is simple (or you may call it primitive): first put gpc files into gcc tree and try to apply as much of patches to older gcc as applies. Then try to compile, this will produce tons of errors. Form the errors see what changed in gcc and adapt gpc to the change. In current gpc source there are a conditionals which choose version of gpc code apropriate for given gcc version, but during porting one can work with single version and add conditionals later. After sevaral iterations one should obtain compilable version. Then run testsuite and fix regressions.

Finding out what exactly needs to be changed is important part of the work. For example when some gcc function used by gpc is missing one needs to find out how to handle this. Sometimes function is no longer needed and one may simply delete the call. Sometimes there is a rename and one has to use new name. Sometimes there is a deeper change. To know what to do it is helpful to look at gcc change logs and at parts of C compiler parallel to Pascal compiler.

...

Personally, I would be overjoyed if I had some time to contribute to GPC development, but I work too many hours at my regular job to consider it at the present time; but perhaps there are some small things that some of us could do to move things along at the rate of an hour or two a week per person.

Concerning adapting to newer gcc: this is probably about one man-month per gcc version. It is poorly decomposable problem: there are interactions with earlier step and it is important to use facts established in earlier steps in subsequent steps. If you make long break you are likely to forget things and re-do discovery work. Actually, discovery work for single problem is likely to take more than two hours, so if you literally mean two hours per week (as opposed to say a weeked per quater) than you will have trouble making any progress. Also given that new versions appear yearly at slow speed you will end up with port to newer, but still obsolete gcc version.

-- Waldek Hebisch

---

Gpc mailing list Gpc@gnu.de https://www.g-n-u.de/mailman/listinfo/gpc

I take your point that things could be more clearly spelt out on the GPC web site about the current state of play. But we did discuss this matter at length in 2010 - see

http://www.g-n-u.de/pipermail/gpc/2010-July/thread.html

Best regards,

The Chief

On 29.12.2016 18:03, Ken Linder wrote:

With

all due respect to Prof. Olowofoyeku, I do not personally find anything well documented about the current state of GPC development on the GPC homepage. The wikipedia page does have some helpful information regarding its current state; however, information on a Wikipedia page is not always accurate and may even be misleading.

As John wrote, the

most recent files on the website are quite old. There is no explanation to the general person interested in GPC who visits the site, why there is nothing newer. Nothing in the FAQ or documentation. Perhaps searching the e-mail archives might yield something, but in my experience, people with only cursory interest, will not dig deep for the answers. A topic as serious as the current development state, especially for a project like GPC that appears to have been abandoned, should be plainly state somewhere on the project website.

PLEASE Please understand I am not

complaining. I am simply giving my opinion and offering my help. Pascal was one of my first languages and I honestly would not enjoy seeing GPC completely wither away and disappear. That said, I am NOT a compiler or OS developer. I did briefly experiment with GPC code in the early 2000's, but have very little experience with C in general. That doesn't mean I can't learn it; my learning curve would just be rather steep.

It is my firm opinion we should chat about what can be done with GPC. Should it be rewritten in C++? Should it be patched and cleaned up to work with the newest GCC toolchains? Should GPC become a translator, accepting pascal code and emitting C++?

Thoughts??? -Ken

The conversation with Frank Heckenbach was pretty much the last that was heard on this list on the status and direction of GPC. It would have been good if there had been some follow-up conversations (I thought the exercise was enormously helpful, even though I disagreed with Frank's proposal), but instead, there was nothing.

I'm going to see if it is even possible to compile and run GPC 2.1 on my OpenSUSE box and then see where to go from there (I'll probably follow up with Waldek Hebisch's latest-and-greatest from 2007, followed by whatever is currently in the Git repository he pointed us to). I don't use Pascal professionally, but I do use it for personal projects (I greatly prefer it to C/C++) so I'll do what little I can to push things along.

--------------------------| John L. Ries | Salford Systems | Phone: (619)543-8880 x107 | or (435)867-8885 | --------------------------|

On Monday 2017-01-02 10:53, Treutwein Bernhard wrote:

Date: Mon, 2 Jan 2017 10:53:18 From: Treutwein Bernhard Bernhard.Treutwein@Verwaltung.Uni-Muenchen.DE To: "'gpc@gnu.de'" gpc@gnu.de Subject: RE: Is GPC dead?

...

I take your point that things could be more clearly spelt out on the GPC web site about the current state of play.

Absolutely.

...

But we did discuss this matter at length in 2010 - see http://www.g-n-u.de/pipermail/gpc/2010-July/thread.html

When I started trying to use GPC in March, 2016 the whole GPC website was defunc, but I was able to dig out the contact person (Peter Gerwisnki) and he resurrected the pages. I also had a short PM exchange with him about the slow death of GPC, and he pointed me to the 2010 thread and specially Frank Heckenbach's summary, which I successfully found at archive.org: http://web.archive.org/web/20140714170318/http://fjf.gnu.de/gpc-future.html

I do not know, if more groups have problems with keeping their projects up with gcc development, but I know that GNU Modula-2 has similar problems.

With some work, I was able to build a working GPC on TinyCore Linux, but apparently I've lost my notes how I did it. I remember that I had to combine several patches & tips from the mailing list, but I had success.

I agree with Ken that it is not no straightforward way to get a running gpc on a standard Linux. TinyCore is quite special in having very few tools only in the default setup and you generally can use older packages without big problems, but the more mainline distributions have interdependencies, which make it quite difficult to downgrade to older versions.

-- Bernhard _______________________________________________ Gpc mailing list Gpc@gnu.de https://www.g-n-u.de/mailman/listinfo/gpc

Leo:

https://sourceforge.net/p/p2ada/code/HEAD/tree/ http://p2ada.sourceforge.net/pascada.htm

I looked into this last July. I got the converter going and I got the compiler running. My final note:

2016 Jul 18

Currently hung because ada cannot handle files other than input and output. That is, it crashes if one tries to writeln(afile, 'something');

Example:

program shell(afile, output); var afile: text; begin rewrite(afile); writeln(afile, 'shell output'); end.

This produces a file called 'afile' with contents 'shell output'. It compiles with FPC and translates to c and compiles with p2c. Ada can't handle it. I suspect there is a way to do it but could not find the documentation.

Tom

Thomas D. Schneider, Ph.D. Senior Investigator National Institutes of Health National Cancer Institute Center for Cancer Research RNA Biology Laboratory Molecular Information Theory Group Frederick, Maryland 21702-1201 schneidt@mail.nih.gov https://schneider.ncifcrf.gov (current link) https://alum.mit.edu/www/toms (permanent link)

The problem is not with Ada (or Ada.Command_Line) but rather that p2ada doesn't understand reset or rewrite (!). But it does understand Open and Create (and Append for cases where the file already exists). P2ada is not prefect and it does require manual intervention though it will do a reasonable job most times. Don't be discouraged by this less than ideal translation for your short program (I agree it doesn't look like a promising start). Here is a short variation on the original program that will be correctly translated to Ada by p2ada,

program shell; var afile: text; begin Create(afile,"foo.txt"); writeln(afile, 'shell output'); end.

Two points to note 1) don't include *any* file variables in the Program name, 2) you must provide a file name for each call Open/Create/Append.

If you do decide to continue exploring p2ada I can give you some hints on other quirks in the p2ada process.

Cheers, Leo

On 4 January 2017 at 19:22, Gale Paeper gpaeper@empirenet.com wrote:

...

On Jan 3, 2017, at 10:08 PM, Schneider schneidt@mail.nih.gov wrote:

Leo:

...

https://sourceforge.net/p/p2ada/code/HEAD/tree/ http://p2ada.sourceforge.net/pascada.htm

I looked into this last July. I got the converter going and I got the compiler running. My final note:

...

2016 Jul 18

Currently hung because ada cannot handle files other than input and

output.

...

...

That is, it crashes if one tries to writeln(afile, 'something');

Example:

program shell(afile, output); var afile: text; begin rewrite(afile); writeln(afile, 'shell output'); end.

This produces a file called 'afile' with contents 'shell output'. It compiles with FPC and translates to c and compiles with p2c. Ada can't handle it. I suspect there is a way to do it but could not find the documentation.

Hmm... While I don't know Ada well enough to be even considered dangerous, I think the solution you're looking for lies in Ada'a Ada.Command_Line package which has the procedures that provide for reading the command line parameter text file name that Pascal's runtime system automatically associates to the "afile" file variable. Once you have the name then you use Ada.Text_IO package's procedures to create the file and output to it.

Ada'a mechanism for connecting to external command line parameters has more of a C argv argc style of parameter associating mechanism than Pascal's program parameter list of file variable names where the runtime system automatically associates the external command line parameter with the program's internal fileparameter.

I'm not sure how Ada's file handling procedures deal with the legal usage possibilities of Pascal's rewrite procedure. Rewrite does the "Right thing" regardless whether the file already exits or not. I don't know if both cases are automatically handled by Ada's runtime system in a similar Pascal runtime system manner or if you have to check which case you have and then have code to deal separately with each case.

Gale Paeper gpaeper@empirenet.com

---

Gpc mailing list Gpc@gnu.de https://www.g-n-u.de/mailman/listinfo/gpc

Leo:

1. don't include *any* file variables in the Program name,

Whoops, a minor typo, that short pascal file should have been program shell; var afile: text; begin Create(afile,out_file,"foo.txt"); writeln(afile, 'shell output'); end. Notice the second argument to Create: out_file. Ada is very picky, you have to tell it that you want to write to the file "foo.txt". If you want to read from a file use Open (afile,in_file,"bah.txt"); rather than reset(afile,"bah.txt")

Got it.

That was enough for me to build a horribly slow preprocessor that fixes the code before translation.

Seems to me that should be part of p2ada.

I see the next major problem is 'anonymous arrays not allowed as components' but a little googling showed how to fix that.

Seems like the road to convert to ada is open but with so many programs it is likely a big job.

Tom

Thomas D. Schneider, Ph.D. Senior Investigator National Institutes of Health National Cancer Institute Center for Cancer Research RNA Biology Laboratory Molecular Information Theory Group Frederick, Maryland 21702-1201 schneidt@mail.nih.gov https://schneider.ncifcrf.gov (current link) https://alum.mit.edu/www/toms (permanent link)

Hi Kevan,

Yes, your "type Data ..." is the way to go. You can later declare arrays of type QData using

foo : Qdata (1..37); bah : Qdata (6..100);

You can do simple loops like

for i in foo'first .. fool'last loop foo (i) := i; end loop;

or even

for i in bah'range loop bah (i) := i*i; end loop;

You can also use this method to handle GPC's conformant arrays formal parameters. So the Pascal code

procedure mary (var abc : Array[a..b] of Integer); ... mary (foo); mary (bah);

would become

procedure mary (abc : in out Qdata) is ... mary (foo); mary (bah);

The attributes 'first, 'last and 'range are Ada's way of giving you access to the properties (well attributes) of your arrays.

If you're using gnat you'll also find that it comes with a pretty printer. It only works on correct Ada code so it's usually the lats thing I do after a conversion using pa2ada. Try

gnatpp fred.adb

(see gnatpp --help for a list of options)

Cheers, Leo

ps. The correct usage is Ada not ADA (the folks on comp.lang.ada will have a pink fit if you use ADA, they'll point out that it could be the Australian Dental Association). Ada is a name not an acronym.

On 5 January 2017 at 07:15, Kevan Hashemi hashemi@brandeis.edu wrote:

Dear Leo

I'm not sure how committed people on this list are to staying with Pascal

...

but if you are prepared to jump ship to Ada then I can tell you from my own experience it is well worth the effort.

This is an interesting proposal.

I just installed GCC 4.7.0 with ADA included on my MacOS 10.7 laptop (still with 10.7 so I can use existing GPC binaries). The ADA compiler works right away, which is awesome.

I downloaded p2ada binaries and translate the following program:

program p; begin writeln('hello world from Pascal.'); end.

The ADA output compiles immeditaely in the ADA compiler, and runs correctly. I note that the ADA code contains 38 lines, but I'm guessing that much of the extra occurs only once per translation. I now try to translate the following program:

program p;

type graph_type(num_points:integer)=array [0..num_points-1] of real; graph_ptr=^graph_type;

var xg:graph_ptr; i:integer;

begin new(xg,100); for i:=0 to 99 do xg^[i]:=i; end.

In p2ada I get: "Syntax Error at line 4"

It looks like p2ada does not translate dynamic schema types. I would have to convert them all manualy. But does ADA itself support dynamic schema types? It supports a format like this:

type QData is array(Positive range <>) of Quarndex;

I guess that's an array of any integer size. If anyone can confirm that it's possible to translate dynamic schema types into ADA, then this translation looks like a good long-term solution.

Yours, Kevan

-- Kevan Hashemi, Electrical Engineer Physics Department, Brandeis University http://alignment.hep.brandeis.edu/

On 4 Jan 2017, at 23:26, Kevan Hashemi hashemi@brandeis.edu wrote:

My main concern is whether I can implement the following dynamic allocation of memory space for graphs, images, and matrices.

type graph_type(num_points:integer)=array [0..num_points-1] of real; graph_ptr=^graph_type; var xg:graph_ptr; i:integer; begin for i:=100 to 200 do begin new(xg,i); dispose(xg,i); end;

I just came across an Ada example that may help you: https://en.wikibooks.org/wiki/Ada_Programming/Types/access#Deleting_objects_...

I am pleased to see this discussion, because at my work we are somewhat in the same boat. We use the Prospero compiler, which finally appears to have vanished from the Internet. We have previously considered gpc, but its limited support for Extended Pascal has stopped us. We will have a serious look at Ada.

Bastiaan.

On 5 Jan 2017, at 00:32, Leo Brewin leo.brewin@monash.edu wrote:

Hi Kevan & Bastiaan,

Here is a short example showing two methods for dynamic allocation.

Thank you.

Bastiaan.

Hi Kevan,

 huge : Integer := 128_000_000;

Here the size of the array is predefined with a constant "huge".

No. "huge" is a variable that is initialised to 128,000,000. The memory is allocated dynamicly and it is allocated from the heap (the main memory pool).

Perhaps this is a better example for what you want

with Ada.Text_IO; use Ada.Text_IO; with Ada.Unchecked_Deallocation;

procedure Foo is

package Integer_IO is new Ada.Text_IO.Integer_IO (Integer); use Integer_IO;

type vector is array (Integer range <>) of Float; type vector_ptr is access vector; procedure Free_Vector is new Ada.Unchecked_Deallocation (vector, vector_ptr);

num : Integer;

begin

get (num); -- read the size of the array from standard input

declare

xg_ptr : vector_ptr := new vector (0..num); xg : vector renames xg_ptr.all;

begin Put (xg'last); New_line; Free_Vector (xg_ptr); -- essential to avoid memory leaks end;

end Foo;

And another example,

with Ada.Text_IO; use Ada.Text_IO; with Ada.Unchecked_Deallocation;

procedure Foo is

package Integer_IO is new Ada.Text_IO.Integer_IO (Integer); use Integer_IO;

type vector is array (Integer range <>) of Float; type vector_ptr is access vector; procedure Free_Vector is new Ada.Unchecked_Deallocation (vector, vector_ptr);

min, max : Integer;

procedure bahbah (min,max : Integer) is xg_ptr : vector_ptr := new vector (min..max); -- min, max unknown at compile time xg : vector renames xg_ptr.all; begin

Put (xg'last); New_line; Free_Vector (xg_ptr); -- essential to avoid memory leaks

end bahbah;

begin

get (min); get (max);

bahbah (min,max);

end Foo;

Cheers, Leo

On 6 January 2017 at 04:39, Kevan Hashemi hashemi@brandeis.edu wrote:

Leo: Thank you for your code example.

for i in 10 .. 20 loop

...

  -- create xg on the stack (okay but stack size is limited)
  -- xg exists only within this declare block
  declare
     xg : Array (0..i-1) of Float;
  begin
     Put (xg'last);
     New_line;
  end;

end loop;

That's the dynamic allocation I'm looking for, except it's on the stack. I need to use the main memory for dynamic allocation.

  huge : Integer := 128_000_000;

...

  xg_ptr : vector_ptr := new vector (0..huge);
  xg     : vector renames xg_ptr.all;

begin Put (xg'last); New_line; Free_Vector (xg_ptr); -- essential to avoid memory leaks end;

Here the size of the array is predefined with a constant "huge".

Bastiaan: Thanks for the link. In the linked code we have:

...

VA := new Vector (1 .. 10); VB := VA; -- points to the same location as VA

Here, the vector size is predefined with the constants 1 and 10.

Peter: Thank you for your FPC example, which does exactly what I need.

...

program A; type graph_type = array of real; var xg:graph_type; i:integer; begin for i:=100 to 200 do begin setlength(xg,i); xg := nil; end; end.

Somehow, I missed setlength when I looked into FPC, and when I asked the FPC group about dynamic arrays, they must have interpreted my question as "does FPC support exactly the same syntax as GPC". So it looks like I could switch to FPC with minimal work.

Yours, Kevan

-- Kevan Hashemi, Electrical Engineer Physics Department, Brandeis University http://alignment.hep.brandeis.edu/

Bastiaan Veelo wrote:

have vanished from the Internet. We have previously considered gpc, but = its limited support for Extended Pascal has stopped us.

Out of curiosity: what was the deal breaking feature?

Bastiaan Veelo wrote:

...

On 5 Jan 2017, at 02:21, Waldek Hebisch hebisch@math.uni.wroc.pl =

wrote:

...

=20 Bastiaan Veelo wrote:

...

=20 have vanished from the Internet. We have previously considered gpc, =

but =3D

...

...

its limited support for Extended Pascal has stopped us.

=20 Out of curiosity: what was the deal breaking feature?

Hi Waldek,

It was about a decade ago, and I don=E2=80=99t remember the details of = the problems. If I look at the missing bits now: "The Extended Pascal = features still missing from GPC are qualified module import, protected = module export variables, set types with variable bounds, structured = value initializers and expressions as subrange lower bounds=E2=80=9D = [1], I don=E2=80=99t see any deficiencies that couldn=E2=80=99t be = worked around.

Actually, this list is out of date. Starting from gpc-20051104 qualified module import and structured value initializers are supported. Few other were supported earlier. Current statement (which AFAICS corresponds to gpc-20051104) is:

: The Extended Pascal features still missing from GPC : are set types with variable bounds and discriminated ordinal schema as : schema discriminants.

According to my own notes [2] it may have been this, but = also the use of some non-standard Prospero extensions or API (OO? Memory = mapped files? w32 GUI support? Serial bus? Printing? Plotting?). Back = then the objective was not to replace Prospero but to find a way to mix = languages, and gpc+gcc made it possible to link object files into the = same executable. Before trying to make our massive code base compatible = with gpc, I looked for a different way to do that. When I found one that = allowed us to continue to use Prospero, which had served us well over = many years, I stopped using gpc.

Best regards, Bastiaan.

[1] http://www.gnu-pascal.de/gpc/Welcome.html#Welcome = http://www.gnu-pascal.de/gpc/Welcome.html#Welcome [2] http://data.hiper-conf.info/compit2011_berlin.pdf = http://data.hiper-conf.info/compit2011_berlin.pdf page 361

I understand decision to not use gpc. Simply in the past I looked at list of features of Prospero Pascal and there were missing Extended Pascal features. So I was curious which feature decided that gpc support was "limited" and Prospero presumably "not limited".

On 04/01/17 22:26, Kevan Hashemi wrote:

My main concern is whether I can implement the following dynamic allocation of memory space for graphs, images, and matrices.

type graph_type(num_points:integer)=array [0..num_points-1] of real; graph_ptr=^graph_type; var xg:graph_ptr; i:integer; begin for i:=100 to 200 do begin new(xg,i); dispose(xg,i); end;

Here we are creating arrays of integers of increasing size and disposing of them. I started moving to FPC a few years back, only to find that this dynamic functionality is not available.

Hi Kevan,

Dynamic arrays are available in FPC. http://wiki.freepascal.org/Dynamic_array

I would have thought that your program stub above could be written for FPC something like;-

program A;

type graph_type = array of real;

var xg:graph_type; i:integer;

begin for i:=100 to 200 do begin setlength(xg,i); xg := nil; end; end.

Regards, Peter

I think when I have time, I will do something similar to John; build GPC on my Debian box.

I am NOT a C or C++ programmer so will rely heavily on notes from this thread, especially those from Waldeck :-) Honestly, I haven't built GPC since about 2002 or so and he last time I used GPC was about 2005.

I'm a telcom/database programmer, mostly using C#, SQL, HTML, XML and a host of industry specific tools. The only raw C experience I have is working on the GPC compiler. My learning curve is going to be extremely steep. I don't work on compilers or OSs or anything very low level. That said, with a little time, I can navigate C code.

I thoroughly understand understand Waldeck wrote...

I do not think rewrite is a good idea. In many cases code is messy for a reason: the task it has to do is messy. When planning rewrite one looks at big picture and gets impression that things can be organized neatly. But messines comes from little details which are not visible in big picture. Rather, the correct approach is constant restructuiring.

If we are to revive GPC, or minimally try to make it work, I think we should update the website to indicate this. Maybe there are folks out there who might want to help if they see GPC is not dead or abandoned. Does Peter have control over the website?

-Ken

On Tue, Jan 3, 2017 at 7:35 PM, John L. Ries jries@salford-systems.com wrote:

I'm going to see if it is even possible to compile and run GPC 2.1 on my OpenSUSE box and then see where to go from there (I'll probably follow up with Waldek Hebisch's latest-and-greatest from 2007, followed by whatever is currently in the Git repository he pointed us to). I don't use Pascal professionally, but I do use it for personal projects (I greatly prefer it to C/C++) so I'll do what little I can to push things along.

Excellent. I'll give the OpenSUSE RPM a shot when I get to my office. The SRPM will be most helpful going forward.

--------------------------| John L. Ries | Salford Systems | Phone: (619)543-8880 x107 | or (435)867-8885 | --------------------------|

On Wed, 4 Jan 2017, Peter wrote:

On 02/01/17 17:53, Treutwein Bernhard wrote:

...

I agree with Ken that it is not no straightforward way to get a running gpc on a standard Linux.

Hi Bernhard,

Packages for rpm systems are available here. https://software.opensuse.org/package/gpc

For Ubuntu, Debian, Mint etc packages can be downloaded from my ppa https://launchpad.net/~ueter/+archive/ubuntu/gpc-3.4

Both sites include source if you want to build your own. Worked for me in 2014/2015 using gcc 4.8 on Debian Stretch.

Also, some useful building tips here http://alignment.hep.brandeis.edu/Software/Pascal/Pascal.html (which is what I used to get started on my ppa packages)

Regards, Peter B

---

Gpc mailing list Gpc@gnu.de https://www.g-n-u.de/mailman/listinfo/gpc

On 04/01/17 19:15, John L. Ries wrote:

Is there a reason why the Texinfo doc is not included in the OpenSUSE/Tumbleweed package?

My guess would be that OpenSUSE uses texinfo > 4 whereas gpc needs texinfo <= 4

Note, if you are just after the info file, its in the upstream source tarball.

http://alignment.hep.brandeis.edu/Software/Pascal/ gpc-20070904-build.tar.gz

or https://github.com/hebisch/gpc/archive/master.zip

In my humble opinion, GPC should continue to be a native Pascal compiler, not a translator. It should be updated to use the current GCC back ends (Waldek has done some of this in the past and I accept his characterization of the process; but I think it's necessary if GPC is to continue to be viable); and the goal should still be to get that aspect of the code completely up to date so that GPC can be added to GCC. And I think it highly important that it be made easy to create binary packages (I can probably devote some time to this, starting with a SlackBuild script, but it will go quicker if more than one person is doing it, especially since for me it would be a learning experience) and do whatever else can be reasonably done to get GPC into people's hands (to including making Linux, Windows, and OSX builds available for download from the website), remembering that it appears to have completely disappeared from Linux distros, and extant collections of UNIX toys.

I assume that the codebase is maintained in some sort of revision control system, such as Git. If it isn't, then it should be.

I'll also accept Frank Heckenbach's characterization of the state of the codebase (a mess), as I doubt things have improved since he last posted on the subject. A rewrite is probably in order, but that is best determined by those who have some familiarity with said codebase. Frank suggested that GPC translate to C behind the scenes, but I fail to see what that would buy us, except the elimination of the need to interface directly with the GCC back end, which is apparently a pain (but perhaps that is a good enough reason by itself). In any case, a rewrite would of necessity be a long term task and should probably be done gradually.

I've never written a compiler (though I have worked on interpreters from time to time starting in college), but if I were to write a Pascal front end to GCC from scratch, my plan (until I knew better) would probably be to use bison and flex to specify as much of the syntax (and meaning thereof) as possible, adding such C (or C++) code as is necessary to communicate with the back end and the user. It would be more elegant to write it in Pascal (as GNAT is written in Ada), but it would require a Pascal compiler to compile it and there aren't many of those in common use anymore (Free Pascal being the most visible one of late). The runtime library, however, would be written completely in Pascal and compiled with GPC, though it would probably call standard C functions to handle low level I/O and memory management (at least); such would be facilitated by a utility to translate C header files into Borland-style Pascal units (or Extended Pascal modules). Since this would be a front-end to GCC, it would have to interface at least indirectly with the C runtime anyway. I'm *guessing* that most of the compiler maintenance would involce updates to the GCC interface and bug fixes; and that most real development would be on the runtime (which would be written in Pascal), but again, chances are excellent that I have no idea what I'm talking about.

That said, let's hear what the developers have to say on the subject.

--------------------------| John L. Ries | Salford Systems | Phone: (619)543-8880 x107 | or (435)867-8885 | --------------------------|

On Thu, 29 Dec 2016, Ken Linder wrote:

With all due respect to Prof. Olowofoyeku, I do not personally find anything well documented about the current state of GPC development on the GPC homepage.  The wikipedia page does have some helpful information regarding its current state; however, information on a Wikipedia page is not always accurate and may even be misleading. As John wrote, the most recent files on the website are quite old.  There is no explanation to the general person interested in GPC who visits the site, why there is nothing newer.  Nothing in the FAQ or documentation.  Perhaps searching the e-mail archives might yield something, but in my experience, people with only cursory interest, will not dig deep for the answers.  A topic as serious as the current development state, especially for a project like GPC that appears to have been abandoned, should be plainly state somewhere on the project website.

PLEASE Please understand I am not complaining.  I am simply giving my opinion and offering my help.  Pascal was one of my first languages and I honestly would not enjoy seeing GPC completely wither away and disappear. That said, I am NOT a compiler or OS developer.  I did briefly experiment with GPC code in the early 2000's, but have very little experience with C in general.  That doesn't mean I can't learn it; my learning curve would just be rather steep.

It is my firm opinion we should chat about what can be done with GPC. Should it be rewritten in C++?  Should it be patched and cleaned up to work with the newest GCC toolchains?  Should GPC become a translator, accepting pascal code and emitting C++?

Thoughts??? -Ken

On Wed, Dec 28, 2016 at 12:59 PM, John L. Ries jries@salford-systems.com wrote: It would be nice if we could find something on the website more recent than 2005 (perhaps a changelog and links to the current codebase); maybe some instructions on how to get GPC to compile with GCC 5 and 6, or at least a sense of how one would go about creating the necessary patches to the latter.

  Personally, I would be overjoyed if I had some time to
  contribute to GPC
  development, but I work too many hours at my regular job to
  consider it at
  the present time; but perhaps there are some small things that
  some of us
  could do to move things along at the rate of an hour or two a
  week per
  person.

  --------------------------|
  John L. Ries              |
  Salford Systems           |
  Phone: (619)543-8880 x107 |
  or     (435)867-8885      |
  --------------------------|


  On Wed, 28 Dec 2016, Prof Abimbola Olowofoyeku wrote:

  > What (apart from that which is already well documented about
  the current
  > state of the development efforts) would you like to ask us?
  >
  > Regards
  > The chief
  > On 29 Dec 2016, at 03:43, Ken Linder <kc7rad@gmail.com> wrote:
  >       Have you tried contacting Peter, "The African Chief" or
  any of
  >       the other people that worked on the compiler?
  > If no one is responding, perhaps I should get a snapshot of
  all the
  > files on www.gnu-pascal.de .  Wouldn't want the entire thing
  lost.
  >
  > -Ken
  >
  > On Tue, Dec 27, 2016 at 9:39 PM, Schneider
  <schneidt@mail.nih.gov>
  > wrote:
  >       Ken:
  >
  >       > I have been wondering the same thing.
  >
  >       It's not functional on Mac OS X for more than a year and
  >       the guy
  >       responsible for it doesn't respond.
  >
  >       Tom
  >
  >         Thomas D. Schneider, Ph.D.
  >         Senior Investigator
  >         National Institutes of Health
  >         National Cancer Institute
  >         Center for Cancer Research
  >         RNA Biology Laboratory
  >         Molecular Information Theory Group
  >         Frederick, Maryland  21702-1201
  >         schneidt@mail.nih.gov
  >         https://schneider.ncifcrf.gov (current link)
  >         https://alum.mit.edu/www/toms (permanent link)
  >
  >

...

---

_

...

Gpc mailing list Gpc@gnu.de https://www.g-n-u.de/mailman/listinfo/gpc

Thanks again. That clarifies things a lot.

--------------------------| John L. Ries | Salford Systems | Phone: (619)543-8880 x107 | or (435)867-8885 | --------------------------|

On Thu, 29 Dec 2016, Waldek Hebisch wrote:

John L. Ries wrote:

...

In my humble opinion, GPC should continue to be a native Pascal compiler, not a translator. It should be updated to use the current GCC back ends (Waldek has done some of this in the past and I accept his characterization of the process; but I think it's necessary if GPC is to continue to be viable); and the goal should still be to get that aspect of the code completely up to date so that GPC can be added to GCC. And I think it highly important that it be made easy to create binary packages (I can probably devote some time to this, starting with a SlackBuild script, but it will go quicker if more than one person is doing it, especially since for me it would be a learning experience) and do whatever else can be reasonably done to get GPC into people's hands (to including making Linux, Windows, and OSX builds available for download from the website), remembering that it appears to have completely disappeared from Linux distros, and extant collections of UNIX toys.

I assume that the codebase is maintained in some sort of revision control system, such as Git. If it isn't, then it should be.

Current version is at:

https://github.com/hebisch/gpc

...

I'll also accept Frank Heckenbach's characterization of the state of the codebase (a mess), as I doubt things have improved since he last posted on the subject. A rewrite is probably in order, but that is best determined by those who have some familiarity with said codebase. Frank suggested that GPC translate to C behind the scenes, but I fail to see what that would buy us, except the elimination of the need to interface directly with the GCC back end, which is apparently a pain (but perhaps that is a good enough reason by itself). In any case, a rewrite would of necessity be a long term task and should probably be done gradually.

I do not think rewrite is a good idea. In many cases code is messy for a reason: the task it has to do is messy. When planning rewrite one looks at big picture and gets impression that things can be organized neatly. But messines comes from little details which are not visible in big picture. Rather, the correct approach is constant restructuiring.

One problem is that GCC backend puts considerable constraints on the frontend. So loose coupling between frontend and the backend could bring better structure. But then we have to reimplement several parts that we currently take from backend. For example backend constant folder is several thousneds of lines -- using our data structures we would have to duplicate it.

...

I've never written a compiler (though I have worked on interpreters from time to time starting in college), but if I were to write a Pascal front end to GCC from scratch, my plan (until I knew better) would probably be to use bison and flex to specify as much of the syntax (and meaning thereof) as possible, adding such C (or C++) code as is necessary to communicate with the back end and the user.

Yes, syntax is mostly handled by flex and bison: corresponding source files makes about 7% of frontend sources.

...

It would be more elegant to write it in Pascal (as GNAT is written in Ada), but it would require a Pascal compiler to compile it and there aren't many of those in common use anymore (Free Pascal being the most visible one of late). The runtime library, however, would be written completely in Pascal and compiled with GPC, though it would probably call standard C functions to handle low level I/O and memory management (at least);

Runtime is mostly in Pascal, but part of OS interface is in C.

...

such would be facilitated by a utility to translate C header files into Borland-style Pascal units (or Extended Pascal modules). Since this would be a front-end to GCC, it would have to interface at least indirectly with the C runtime anyway. I'm *guessing* that most of the compiler maintenance would involce updates to the GCC interface and bug fixes; and that most real development would be on the runtime (which would be written in Pascal), but again, chances are excellent that I have no idea what I'm talking about.

Actually, large parts of real developement were on compiler proper. One thing is to implement desirable language extensions. First, there are still unimplemented corners of Extended Pascal (mainly set schemas). Much of Object Pascal is done, but there are nice features (views) missing. ATM there is no exception support (I have non-working code -- it handles syntax, but couses miscompilation in several cases). It is not clear if overloading is desirable -- ATM it is available for operators, but not for functions and procedures.

Another thing is error checking. First, to catch errors requires nontrivial effort. Second, even more effort goes into generation of sensible error messages.

-- Waldek Hebisch

---

Gpc mailing list Gpc@gnu.de https://www.g-n-u.de/mailman/listinfo/gpc

On Dec 27, 2016, at 7:39 PM, Schneider schneidt@mail.nih.gov wrote:

Ken:

...

I have been wondering the same thing.

It's not functional on Mac OS X for more than a year and the guy responsible for it doesn't respond.

The last time I could put a lot of time into trying to get GPC building for Mac OS X versions 10.8 or later, there were two big items (so far) that needed to be fixed to get past stage 1 building GPC with any of the GPC supported base gcc versions.

1. Starting with Mac OS X 10.6 (and a later than GPC gcc supported version) Apple started using system version dependent compile time version determined linker and library specs for the build driver. The solution I believe is to back port from a later version of gcc containing Apple's system versioning mechanics code so the older GPC/gcc combinations work in the same system version specific manner with the necessary/correct linker and library specs.

2. The older GPC/gcc supported versions' autoconfig config files have assumptions built into them that does not hold correct in a post Mac OS X 10,6/10,7 compilation setting.. Of particular note, config items (e.g., compiler and linker macros and directives) critical to successful stage 1 bootstrapping doesn't get feed on to later bootstrapping stages in a manner to get anything built. (Part of the problem here is that Apple reorganized some of the system header file locations starting with Mac OS X 10.8 so quite a few of the autoconfig test programs fail unless you can get them to use an older version of the system headers and linker libraries.)

The older GPC/gcc supported versions have issues with Apple's now stock llvm based tool chain. For compiling code issues with Apple's stock clang C compiler, the solution the old versions GPC/gcc code bases is to use one the current version GNU gcc Mac OS X ports to do the compiling. For assembler related issues, the solution is to build and configure to use GNU's as assembler and for that to work you have to be specific to invoke a GNU gcc instead of getting hijacked by XCode's aliasing of gcc/cc to the llvm based integrated clang compiler/assembler. There are also linker issues; however, unfortunately, for Mac OS X 10.11 and later there is no alternative linker solution other than Apple's llvm based integrated linker.

Using a Mac OS X built current gcc version for compiling, I was able to get through stage 1 GPC/gcc config, compile and GPC RTS build after trail and error messaging of config parameters and compiler building flags. (Until item 1 above is fixed, the GPC RTS build system requires some hand tweaking for a linking issue to get the RTS built in stage 1.)

As far as the work involved goes, item 1 above looks to be the easiest and a fairly straight forward back port from a newer version of gcc to one or more of the supported GPC/gcc version. I think accomplishing the item 1 fixes will be a necessary and good start in fixing item 2 problems since that should fix autoconfig going off the rails into bogus cross compiling land due to linker issues.

Overall, it would be a lot simpler if GPC was updated to use a closer to current gcc version since all the multitude of changes due to Apple's change over to a llvm based tool change stock base and reorganization of system hearer and library files have already been "solved" by the mainline gcc maintainers. However, as Waldek alludes to in a later e-mail, the updating is a pretty big task iitself.

Gale Paeper gpaeper@empirenet.com

Adriaan:

I still want to make a release for recent versions of Mac OS X, but simply can't find the time ....

Fabulous!!!

Tom

Thomas D. Schneider, Ph.D. Senior Investigator National Institutes of Health National Cancer Institute Center for Cancer Research RNA Biology Laboratory Molecular Information Theory Group Frederick, Maryland 21702-1201 schneidt@mail.nih.gov https://schneider.ncifcrf.gov (current link) https://alum.mit.edu/www/toms (permanent link)

John:

So we have yet to find anyone who is currently working on GPC, which brings the original question back to the foreground. Is GPC dead? If so, shall we revive it or would it be better to implement Extended Pascal in Free Pascal? If it is ongoing or deemed to be worth reviving, what can we non-developers do to help (leaving open the possibility that some of us may need to become developers)?

I'm strongly in favor of reviving it. Having several compilers allows one to bypass problems with one of them and to find bugs. I have a set of Pascal programs for DNA sequence analysis and soon I'm going to release previously patent-protected code. This code will be useful to many molecular biologists around the world. They already use sequence logos:

https://alum.mit.edu/www/toms/glossary.html#sequence_logo

Those show average patterns in DNA (by stacks of letters). The method is used all around the world now.

The soon to be released code is for sequence walkers:

https://alum.mit.edu/www/toms/glossary.html#sequence_walker

Here's a pretty picture of what they can do to show patterns in DNA:

https://schneider.ncifcrf.gov/ftp/fispromoterArt.jpg

So if people are to take advantage of these tools, having several healthy Pascal compilers is important.

Tom

Thomas D. Schneider, Ph.D. Senior Investigator National Institutes of Health National Cancer Institute Center for Cancer Research RNA Biology Laboratory Molecular Information Theory Group Frederick, Maryland 21702-1201 schneidt@mail.nih.gov https://schneider.ncifcrf.gov (current link) https://alum.mit.edu/www/toms (permanent link)

I'm wondering if we could get some help from the GCC developer folks. Just a thought. More tomorrow when I have a clear head. I'm fighting a horrible cold.

-Ken

On Sat, Dec 31, 2016 at 11:10 PM, Waldek Hebisch hebisch@math.uni.wroc.pl wrote:

John L. Ries wrote:

...

If it is ongoing or deemed to be worth reviving, what can we non-de= velopers do to help (leaving open the possibility that some of us may

need =

...

to become developers)?

Using old versions of gcc is probably as close as one can get to minimize ongoing work. But of course there are problems due to changing environment. And there is need to fix bugs. Now, in this area first step is to realize that there is a problem. So when gpc does not build or you see a bug report it. See for example

www.chiark.greenend.org.uk/~sgtatham/bugs.html

on how to do this. If problems with building gpc are due to changes in operating system you can report problems to developers of said systems -- while it is unlikely that they withdraw breaking changes they may offer some workarounds.

Freqently, fixes can be found on the net. For example, as I wrote in another message older gcc-s does not build on current Debian stable. But in Debian repository there is package for gcc-3.3 and it contains 'multiarch-include.dpatch' which solves main problem. This patch does not apply to gcc-3.4.6, but can be easily adapted -- one just have to notice that part of patched code moved from one file to another (both files are appear in the patch). There is another problem, but in this case Gogle gives workaround: set LIBRARY_PATH enviroment varibale to /usr/lib/x86_64-linux-gnu (with x86_64-linux-gnu replaced by appropriate architecture).

Fixes like this take time, but do not require deep familarity with gpc. In fact, the main thing was that I knew that almost all "gpc" build problems are in fact gcc build problems so I looked for workarouds for gcc.

-- Waldek Hebisch

---

Gpc mailing list Gpc@gnu.de https://www.g-n-u.de/mailman/listinfo/gpc