Quoting Tom Schneider schneidt@mail.nih.gov:

Thanks for redirecting the conversation to the important issues at hand.

GPC is quite important for many molecular biologists because the sequence logo method, which is now widely used in molecular biology, is written in Pascal.

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

GPC potentially provides a long term solution only if standard Pascal can be compiled on it.

I firmly agree. 10206 is compatible with 7185. The default should be adherence to one of those, preferably 7185. With any luck this should lead to universal usage of the standards.

Dear Peter,

Martin Liddle wrote:

...

In message 20100815132901.GB12590@mail.g-n-u.de, Peter Gerwinski peter@gerwinski.de writes

...

If GNU Pascal is important for you, please consider to invest into its future by funding our work on GPC.

Can you give some estimate of the costs involved?

As I wrote, we are speaking of several months of full-time work on GPC by an experienced programmer.

Our normal rates for high-level programming are between 100 and 120 EUR/h plus value-added tax. In this special case I offer to code for 40 EUR/h.

So the estimate is "several 10000 EUR".

That's a lot of money for a single person or company. For instance, Waldek, Frank or myself cannot simply afford it by working for free on GPC instead of doing our paid work. But if everyone who values GPC contributes, it becomes affordable.

This particular project is about rewriting the compiler in Pascal, thus removing the last obstacle which prevents you from programming it by yourself. So what you get for your money is much more than just a compiler.

willett wrote:

...

if I need or want to develop substantial code, I would use Extended Pascal, and I would want it to run on multiple platforms. Thus the project you describe would have value to me in that it would keep my existing code viable and would keep my options open.

Yes, that's our intention.

...

On the above basis, I would be willing to contribute $500 to the project you describe in 2. I would be willing to pay in advance, given sufficient contributions from myself and others to complete the project, and given your assurance of a good faith effort to carry it to completion.

That's very fair.

...

I would also hope that there is some plan for 1. prior to embarking on 2., even if it is a separate effort.

The plan for step 2 depends on who joins the GPC development team during step 1. If it is up to Frank and myself to decide, the new backend will be C++. But until then, the GPC frontend will have been rewritten in Pascal, and a new team might be ready to take over GPC development and make a different offer.

...

I would encourage others on this list to answer Peter's question, which requires a specific commitment if this (substantial) project is to go forward. Note that it is not unusual to pay $1000 for a high-quality unix compiler, with subsequent upgrade fees. I'm replying on the public list rather than privately to Peter, since I did not see any others yet answering his question.

Thanks. If enough people join, this will enable us to consolidate the future of GPC.

Hiltibidal, Rob wrote:

...

Unfortunately you touch upon a subject dear to business. That is support.

That's not unfortunate at all.

With proprietary software like, e.g., Borland Delphi, you pay for permission to use the compiler and get some limited support for free. With free software like GNU Pascal, you get that permission for free and pay for actual work: support, customization, or whatever.

...

Are you, Peter, willing to make DB2, Oracle, MySQL and Postgres support as easy as jdbc is?

Sure, if someone pays for it. That's how free software business works.

If, for instance, ten companies need a universal database interface for GPC similar to JDBC, and each of them invests EUR 1000, we can work on it with a budget of EUR 10000. Sounds feasible.

This was just an example. If you need an actual offer, we can negotiate about that. A "JDBC" library might be easier to write with the new GPC we are offering to create, but of course we can write one for the existing GPC - in such a way that it will remain usable with the new one.

Peter

Dear Peter,

(Aplogies for bad send of partial mail earlier.)

I'd like to be certain I know what's on offer here before I think about dipping into my grant to pay for development. My choice is to move to FPC or to help develop GPC. My understanding of the GPC development is as follows. Please correct me.

The GPC development you propose is to re-write the GPC compiler in Pascal. The result will be a compiler that other Pascal programmers, like me, can fix and extend.

The compiler will produce some kind of intermediate representation of the Pascal program. The existing IR is GCC's. Keeping up with changes in the GCC IR definition is time-consuming. You and Frank prefer C++ as the IR. Other options are the LLVM IR.

Advantage of C++ is availability on all platforms, and you and Frank are familiar with C++.

Disadvantage of C++ is compiling C++ IR will can generate its own errors, which will be mysterious to the Pascal user. The debugger will operate upon the code as if it were a C++ source, which will mangle some names and types. In order to work on the compiler, we will have to learn C++.

Yours, Kevan

Hello,

Kevan Hashemi wrote:

[...] My understanding of the GPC development is as follows. Please correct me.

The GPC development you propose is to re-write the GPC compiler in Pascal. The result will be a compiler that other Pascal programmers, like me, can fix and extend.

Correct.

The compiler will produce some kind of intermediate representation of the Pascal program. The existing IR is GCC's. Keeping up with changes in the GCC IR definition is time-consuming. You and Frank prefer C++ as the IR. Other options are the LLVM IR.

Almost correct. In the first step, the IR will be just a Pascal data structure in memory. In the second step, this will be output as C++ code (or LLVM, or whatever).

Already after the first step the compiler will be written in Pascal, so Pascal programmers, like you, can contribute to the second step.

The offer, so far, is about the first step.

Advantage of C++ is availability on all platforms, and you and Frank are familiar with C++.

Correct.

Disadvantage of C++ is compiling C++ IR will can generate its own errors, which will be mysterious to the Pascal user.

Not really. If the frontend works correctly it will catch all errors before outputting any C++ code (or LLVM, or whatever).

The debugger will operate upon the code as if it were a C++ source, which will mangle some names and types.

Yes, but this can be corrected afterwards in a later step.

In order to work on the compiler, we will have to learn C++.

No. That's exactly the purpose of step 1: enable Pascal programmers to work on the compiler.

If you want to work on the backend you need of course some knowledge about the IR, which can be C++, or LLVM, or whatever. But in any case it will be much more readable for Pascal programmers than the current GCC backend (C with hand-made "objects") or an optimizing machine-specific assembler backend.

Peter

Hiltibidal, Rob wrote:

You get a place to store your repository: subversion, cvs no matter, maybe sourceforge? or off the apache.org site?

Until recently, we provided CVS access to GPC. Virtually noone ever used it, so we abandoned it with the last system upgrade.

Developers like myself contribute code Everyone learns and grows

Be welcome. The code is there.

If the fact that GPC is written in C prevents you from contributing to it, that's exactly the problem we offer to solve.

There is nothing which prevents you from contributing libraries (XML, access to various DBs, etc.) to GPC. If you want to write such a thing, just do it.

Peter

Kevan Hashemi wrote:

Given a binary version of the compiler, we apply this binary to a new version of the Pascal GPC source code, which produces a new C++ program representing the compiler, which we compile again with GCC, to produce a new compiler binary. Is that how it would work?

Yes, but all this will be happening automatically behind the stage. The command line to compile a GPC program will remain as simple as "gpc hello.pas -o hello".

And I assume the advantage of C++ as the output is that you could, in theory, use any C++ compiler to get the binary.

That's one potential advantage of C++. For a detailed discussion, see Frank's page http://fjf.gnu.de/gpc-future.html, section "GPC as a C++ Converter".

To what extent will you use C++ features particular to GCC?

IMHO it is best to adhere to ISO standard C++. But anyway, the backend is step 2.

Peter

Dear Kevan,

you wrote:

You propose a GPC "frontend" written in Pascal. Given a Pascal program as input, this frontend will produce a "Pascal data structure in memory" (I'm quoting you there, but I'm pretty sure I know what you mean).

Correct so far.

The existing GPC frontend is written in C. Given a Pascal program as input, this existing frontend produces... what?

A C data structure in memory, the so-called TREE_NODEs. Some C structs (records in Pascal) containing pointers to other structs, and so on.

I thought it was GCC IR code.

Yes. GCC IR code (in memory) are the TREE_NODEs.

I'm assuming that Step 1 produces something that works before we complete Step 2,

Well, it works, but it does not produce code.

Step 1 is not a compiler, but just one half of it, the frontend.

We can do a lot of things with the frontend alone. In particular we can check for many sorts of errors, so we know that the Pascal program we want to compile is valid.

To really compile a program, we need the other half of the compiler, the backend. In the current GPC, we hand over the TREE_NODEs to some C functions which optimize them and produce assembler code, which is then processed further to get an executable.

With the proposed new GPC, we must write some Pascal code which hands over the "Pascal data structure in memory" to something which can produce an executable. IMHO the most promising way to do that is to output C++ code and then call g++ to produce an executable. (See Frank's page http://fjf.gnu.de/gpc-future.html for a detailed discussion.) Others on this list seem to prefer LLVM, Ada, Modula2, or whatever.

Rewriting the frontend means to read complicated C code, which is much more difficult than to write it. Realistically this can only be done by the "old guys" - Waldek, Frank, and/or myself. On the other hand, creating the backend means to write a new Pascal program, so everyone on this list can, in principle, do that. This is the reason why I separate both steps.

Peter

Dear Kevan,

you wrote:

Thank you for your explanation, which I enjoyed very much.

You are welcome. :-)

My guess is that this data structure is an abstract syntax tree.

Correct.

If so, will you provide documentation on the AST format as part of Step 1, or will the Pascal code itself provide the documentation,

The latter. For example, the representation of an array type in memory might look as follows.

Type PArrayType = ^TArrayType; TArrayType = object (TComposedType) IndexType, ElementType: PType; LowerIndex, UpperIndex: POrdinalValue end;

or will you use some standard format? Is the existing TREENODE output in GCC's AST format?

The AST is not written to disk, but handed over from the frontend to the backend, which then produces assembler output (in the GCC case).

Until we have a back-end, I suppose the front-end must be compiled with the existing GPC binary. Is that right? But the back-end could also be written in Pascal and compiled the same way.

Correct.

To be precise, the frontend and the backend are not two programs, but two parts of the same program.

When you get the chance, please be more specific about your cost estimate for the front-end in Pascal. If it's $20k, we need forty people donating $500 or ten people donating $2k.

As I wrote today at 15:24:47, the estimate is "several 10000 EUR".

I'm looking at roughly 40 hours to re-write my code for FPC. So a donation of $500 to your cause would be money well spent. A donation of $2000 I would have to think about more carefully.

I understand.

What about the back end? Please estimate how long it would take you to make a C++ back end. I could write a back-end for LLVM IR, I suppose, but I'm not in a position to estimate how many hours it will take me.

Indeed, such numbers are hard to estimate.

Right now, I am looking for sponsors, on this list and elsewhere. If it turns out that "several 10000 EUR" is out of range anyway, then the project is dead. In that case, we are all better off to save our time and money for porting our code to another compiler before the GCC 3.x backend dies, taking the existing GPC with it.

OTOH if enough individuals are willing to invest $500 (Thanks again for your offer!) and enough companies are willing to invest larger amounts, it makes sense to work out more concrete numbers which tell us how far we can get.

Peter

Hiltibidal, Rob wrote:

Personally I prefer dealing with a native pascal compiler

FPC compiles or used to compile to assembler for some things,... very fast.

Seems to me the "pggy back" method for using C as the base compiler will add delayus and debug symbol issues.

Might be a better idea to simply go the byte code route.

That's what an LLVM assembly http://llvm.org/docs/LangRef.html writer could do (and yes, an LLVM back-end is under consideration for FPC also).

Regards,

Adriaan van Os

On Tue, 17 Aug 2010, Hiltibidal, Rob wrote:

Personally I prefer dealing with a native pascal compiler

FPC compiles or used to compile to assembler for some things,... very fast.

Seems to me the "pggy back" method for using C as the base compiler will add delayus and debug symbol issues.

Might be a better idea to simply go the byte code route.

I'd rather skip the intermediate language translator step completely and go straight to a rewrite of the compiler in Pascal, but I don't see that happening, unless one of us relieves Frank of the burden of maintaining the interface to the GCC back end (I don't think I have time to learn the interface at this point either, sorry to say). Given that the translator step appears to be the way we're going in the short term, bytecode might be an acceptable intermediary if it is is promptly converted to native binary (the bytecode compiler would effectively replace the GCC back end), rather than requiring execs to include an onboard p-code interpreter, as I have to think that the latter would slow execs down dramatically, and it would make cross-language development much more difficult.

I'm not terribly happy about using C++ as the intermediate language, but it does have the virtue of being readily available on just about every computing platform in common use. A Wirthian language like Ada would probably work better as an interediate language, but then the developers would have to distribute compiler binaries for whatever computing platforms people are likely to use (or make cross-compilation insanely easy), and someone would have to test frequently to make sure the interface still works. The same thing would have to be done with a bootstrapped Pascal compiler, but that would be under the control of this set of developers, rather than a different set that has little or no reason to care about Pascal.

Thought that just occurred to me:

Given the similarities between Pascal and Ada, how feasible would it be to adapt the existing GNAT codebase to compile Pascal, instead of Ada?

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

-----Original Message----- From: gpc-owner@gnu.de [mailto:gpc-owner@gnu.de] On Behalf Of Peter Gerwinski Sent: Tuesday, August 17, 2010 12:52 PM To: GNU Pascal mailing list Subject: Re: How important is GPC for you?

Kevan Hashemi wrote:

...

Given a binary version of the compiler, we apply this binary to a new

...

version of the Pascal GPC source code, which produces a new C++

program

...

representing the compiler, which we compile again with GCC, to produce

a

...

new compiler binary. Is that how it would work?

Yes, but all this will be happening automatically behind the stage. The command line to compile a GPC program will remain as simple as "gpc hello.pas -o hello".

...

And I assume the advantage of C++ as the output is that you could, in

...

theory, use any C++ compiler to get the binary.

That's one potential advantage of C++. For a detailed discussion, see Frank's page http://fjf.gnu.de/gpc-future.html, section "GPC as a C++ Converter".

...

To what extent will you use C++ features particular to GCC?

IMHO it is best to adhere to ISO standard C++. But anyway, the backend is step 2.

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

PRIVILEGED AND CONFIDENTIAL This email transmission contains privileged and confidential information intended only for the use of the individual or entity named above. If the reader of the email is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any use, dissemination or copying of this email transmission is strictly prohibited by the sender. If you have received this transmission in error, please delete the email and immediately notify the sender via the email return address or mailto:postmaster@argushealth.com. Thank you.

On Tue, 17 Aug 2010, Peter Gerwinski wrote:

John L. Ries wrote:

...

A Wirthian language like Ada would probably work better as an interediate language, [...]

The difference between Wirthian languages and C-like languages is, AFAICT, error-checking. In our case, error-checking is done in the frontend, so we don't win anything here.

My thought was that Pascal would likely be easier to translate into Ada than into C++, but if such is not the case, then never mind.

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

On 17 Aug 2010, at 17:13, Hiltibidal, Rob wrote:

Does anyone actually pay for perl?

http://www.perlfoundation.org/sponsors

For Java?

Previously Sun, now Oracle.

For python?

http://www.python.org/psf/

For groovy?

http://groovy.codehaus.org/ says it's "Sustained & led by SpringSource"

For jython?

It's also supported by the Python Foundation.

Company's pay and pay well for products made in those languages and support for products in those languages.

And for the development of those languages and their compilers as well.

Guess what I am saying since other languages already have the functionality built into them for company's to be competitive why would a company pay to reinvent the wheel?

First of all, it's not reinventing the wheel since an ISO Standard/Extended Pascal compiler is not the same as a Perl/Java/Python/... compiler. In fact, the proposed project is exactly to only develop the Pascal frontend and to reuse what can be reused from other projects (the code generation part).

Secondly, the investment in the development of such a compiler may be offset by the combined savings in a) having to rewrite all your existing code b) retraining yourself and others in becoming proficient in another language + framework (it can take quite a while until you reach the same level of productivity in the other development environment)

On the other hand a few people with a love of a language pulling together to build and play catch up to make a language robust and mature...

I've not seen anyone here talking about changing the language. They want to use the existing language with a modern compiler.

Jonas

On Tue, 17 Aug 2010, Jonas Maebe wrote:

On 17 Aug 2010, at 18:32, Jonas Maebe wrote:

...

I've not seen anyone here talking about changing the language.

Oops, for a moment I forgot all the talk about generics etc. Anyway, one does not exclude the other (to the contrary, in fact).

Jonas

I do seem to recall Frank asking for wishlist items (so I, among others, provided), but I think most of us are happy with the language as it is. It's less a matter of changing the language, than extending it in useful ways.

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

Unfortunately you touch upon a subject dear to business.

That is support.

Yes IBM receives a lot of money from companies like mine for its C compiler and AIX software. Fortunately Java is not near the fees.. yet.

But when it comes to a "five 9's SLA and performance guarantees" with sub second response time there has to be minimal room for error.

This in part requires effort on the coder to use proper error checking and handling. For the language the tools must exist to properly debug and support the effort aswell as provide for error and exception handling.

Then there is platform support. Just fyi the GNU C compiler for version 3.x does not work or work well in AIX 6. Something's broke for us when we upgraded to AIX 6.

Without delving into OS wars for a language to be successful as either a primary language for application or a support language supporting the backend processes I would think you'd want GPC to successfully compile in the primary business os's... zOS, AIX, Solaris with possibly cygwin under windows. pdksh is widely popular when having to delve into scripting on the windows platform.

So perhaps the bigger question is not how important is gpc for us but what have you set your sights on and what are you willing to do maintain a significant presence?

Personally I love pascal. I prefer it over java. Yet I have to connect to major databases usually with jdbc. DB2, Oracle, MySQL, and Postgres are what most people in my area have to deal with for RDBM support. Are you, Peter, willing to make DB2, Oracle, MySQL and Postgres support as easy as jdbc is? Without database support the language is not really useful to most businesses.

FPC Pascal relies on ODBC drivers. With JDBC gaining such popularity I do not know how successful Unix odbc drivers are or will be. I haven't had to work with Unix ODBC for more than 10 years now. I am not sure merimar(merimac sp?) is even available any more.

So bottom line to be fully successful you need cross platform capability for 32 and 64 bit os's, native rdbm support with fully capable error handling/error checking support.

-----Original Message----- From: gpc-owner@gnu.de [mailto:gpc-owner@gnu.de] On Behalf Of willett Sent: Sunday, August 15, 2010 5:02 PM To: GNU Pascal mailing list Cc: Peter Gerwinski Subject: Re: How important is GPC for you?

Peter (and Frank and Waldek),

I have tens of thousands of lines of code that complies in GPC. Equally or more important, I code most fluidly in Classic Standard Pascal (7185) and Extended Pascal. I find Extended Pascal to be a very powerful and general-purpose language.

if I need or want to develop substantial code, I would use Extended Pascal, and I would want it to run on multiple platforms. Thus the project you describe would have value to me in that it would keep my existing code viable and would keep my options open.

On the above basis, I would be willing to contribute $500 to the project you describe in 2. I would be willing to pay in advance, given sufficient contributions from myself and others to complete the project, and given your assurance of a good faith effort to carry it to completion. I would also hope that there is some plan for 1. prior to embarking on 2., even if it is a separate effort.

I would encourage others on this list to answer Peter's question, which requires a specific commitment if this (substantial) project is to go forward. Note that it is not unusual to pay $1000 for a high-quality unix compiler, with subsequent upgrade fees. I'm replying on the public list rather than privately to Peter, since I did not see any others yet answering his question.

Willett Kempton Visible Software

On 15 Aug 2010, at 09:29, Peter Gerwinski wrote:

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 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

PRIVILEGED AND CONFIDENTIAL This email transmission contains privileged and confidential information intended only for the use of the individual or entity named above. If the reader of the email is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any use, dissemination or copying of this email transmission is strictly prohibited by the sender. If you have received this transmission in error, please delete the email and immediately notify the sender via the email return address or mailto:postmaster@argushealth.com. Thank you.