I've put a new version of GP with the minor changes discussed here at http://gnu-pascal.de/contrib/frank/misc/gp-0.55.tar.gz.
Frank
Frank Heckenbach writes:
I've put a new version of GP with the minor changes discussed here at http://gnu-pascal.de/contrib/frank/misc/gp-0.55.tar.gz.
looking at
http://packages.debian.org/cgi-bin/search_contents.pl?word=%2Fgp&searchm...
I find another gp program. Renaming it to gpm is worse, pmake is the NetBSD make, what about gpmake?
On Sat, May 22, 2004 at 07:18:13AM +0200, Matthias Klose wrote:
Frank Heckenbach writes:
I've put a new version of GP with the minor changes discussed here at http://gnu-pascal.de/contrib/frank/misc/gp-0.55.tar.gz.
looking at
http://packages.debian.org/cgi-bin/search_contents.pl?word=%2Fgp&searchm...
I find another gp program. Renaming it to gpm is worse, pmake is the NetBSD make, what about gpmake?
Is this a problem? Short abbreviations tend to duplicate. Even the name GPC is used in other projects:
Guile Python Compiler (http://savannah.gnu.org/projects/gpc/)
General Polygon Clipper library (http://www.cs.man.ac.uk/aig/staff/alan/software/)
General Purpose Converter (http://freshmeat.net/projects/kgpc/)
GNOME Photo Collector (http://gpc.sourceforge.net/)
Emil
On Sat, May 22, 2004 at 07:18:13AM +0200, Matthias Klose wrote:
Frank Heckenbach writes:
I've put a new version of GP with the minor changes discussed here at http://gnu-pascal.de/contrib/frank/misc/gp-0.55.tar.gz.
looking at
http://packages.debian.org/cgi-bin/search_contents.pl?word=%2Fgp&searchm...
I find another gp program. Renaming it to gpm is worse, pmake is the NetBSD make, what about gpmake?
Is this a problem? Short abbreviations tend to duplicate. Even the name GPC is used in other projects:
Guile Python Compiler (http://savannah.gnu.org/projects/gpc/)
General Polygon Clipper library (http://www.cs.man.ac.uk/aig/staff/alan/software/)
General Purpose Converter (http://freshmeat.net/projects/kgpc/)
GNOME Photo Collector (http://gpc.sourceforge.net/)
There is a problem if two packages try to install a file with the same name. Concerning GPC: it is mostly problem for projects you mention since Gnu Pascal is already there (note that GNOME Photo Collector according to web site changed name for installed files to `gphotocoll').
With gp situation is different: I was using gp/pari from time to time in last 8 years (rarely enough that I did not remember about name conflict) and the project is probably older.
By the way, short names looks like a suicide in Google times (try to find out what 'V' or 'M' is :).
Matthias Klose wrote:
looking at
http://packages.debian.org/cgi-bin/search_contents.pl?word=%2Fgp&searchm...
I find another gp program. Renaming it to gpm is worse, pmake is the NetBSD make, what about gpmake?
Too long IMHO. Also "make" is rather a term from the "C world". A normal Pascal programmer (especially one who hasn't used GPC before) isn't expected to know about making etc. Rather, a Pascal compiler ("processor" in ISO terms) is expected to deal with modules ("programÂcomponent") just as any other parts of a Pascal program.
Waldek Hebisch wrote:
There is a problem if two packages try to install a file with the same name. Concerning GPC: it is mostly problem for projects you mention since Gnu Pascal is already there (note that GNOME Photo Collector according to web site changed name for installed files to `gphotocoll').
With gp situation is different: I was using gp/pari from time to time in last 8 years (rarely enough that I did not remember about name conflict) and the project is probably older.
By the way, short names looks like a suicide in Google times (try to find out what 'V' or 'M' is :).
Google might be too broad, since it doesn't find only program names. We could look for other suitable names that don't occur in the Debian file list, e.g.
If we don't find anything suitable (say, <= 3 letters and making sense), I suggest to rename the gpc executable to something longer and call gp gpc. This will, of course, require some incompatible changes, but I'd rather have the future recommended way of using GPC to have the more "comfortable" and easy to use name while the "old style" and C compatible plain interface (which will probably mostly occur in legacy Makefiles then) can have a longer name (probably starting with `gpc').
Frank
Frank Heckenbach wrote:
... snip ...
Too long IMHO. Also "make" is rather a term from the "C world". A normal Pascal programmer (especially one who hasn't used GPC before) isn't expected to know about making etc. Rather, a Pascal compiler ("processor" in ISO terms) is expected to deal with modules ("programÂcomponent") just as any other parts of a Pascal program.
I disagree here. make is a highly generic tool, which happens to be especially suited to the success/failure return status on Unices. In its simplest terms it requires nothing more than the ability to check file dates, launch programs, and test their return values.
CBFalconer wrote:
Frank Heckenbach wrote:
... snip ...
Too long IMHO. Also "make" is rather a term from the "C world". A normal Pascal programmer (especially one who hasn't used GPC before) isn't expected to know about making etc. Rather, a Pascal compiler ("processor" in ISO terms) is expected to deal with modules ("programÂcomponent") just as any other parts of a Pascal program.
I disagree here. make is a highly generic tool, which happens to be especially suited to the success/failure return status on Unices. In its simplest terms it requires nothing more than the ability to check file dates, launch programs, and test their return values.
In how far do you disagree? Yes, make is very generic, while our utility is rather specialized for the needs of compiling Pascal programs. So "make" isn't a suitable description for it, which is what I was saying.
OK, make is not only useful for compiling C code, if you mean this. But AFAIK that's where it originated, and where it's rather necessary.
Frank
Dixitur illum ih8mj@fjf.gnu.de scribere...
Too long IMHO. Also "make" is rather a term from the "C world". A normal Pascal programmer (especially one who hasn't used GPC before)
What about gpl? Resembles tpl, and l=linker might fit as well.
//Thorsten
Thorsten Glaser wrote:
Dixitur illum ih8mj@fjf.gnu.de scribere...
Too long IMHO. Also "make" is rather a term from the "C world". A normal Pascal programmer (especially one who hasn't used GPC before)
What about gpl? Resembles tpl, and l=linker might fit as well.
Hmm, isn't there something called GPL already? (-: Not an executable perhaps, though ...)
Frank
On 26 May 2004 at 1:18, Frank Heckenbach wrote:
[...]
If we don't find anything suitable (say, <= 3 letters and making sense), I suggest to rename the gpc executable to something longer and call gp gpc. This will, of course, require some incompatible changes, but I'd rather have the future recommended way of using GPC to have the more "comfortable" and easy to use name while the "old style" and C compatible plain interface (which will probably mostly occur in legacy Makefiles then) can have a longer name (probably starting with `gpc').
How about "gpm" or "gpi" or "gpd" or "cgp"?
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku (The African Chief) wrote:
On 26 May 2004 at 1:18, Frank Heckenbach wrote:
[...]
If we don't find anything suitable (say, <= 3 letters and making sense), I suggest to rename the gpc executable to something longer and call gp gpc. This will, of course, require some incompatible changes, but I'd rather have the future recommended way of using GPC to have the more "comfortable" and easy to use name while the "old style" and C compatible plain interface (which will probably mostly occur in legacy Makefiles then) can have a longer name (probably starting with `gpc').
How about "gpm"
That's the name of a well-known program (console mouse driver).
or "gpi" or "gpd"
These are the file name suffixes used by GPC and GP. If the name was different, we could use that name as the suffix for configuration files. (I don't like `.cfg' as you suggested. First, it's very generic; second, using program specific config files, if `foo.pas' is a program, then `foo.cfg' might be used by the programmer for a program config file, so we shouldn't use that name as the program build config file. I.e., if the tool is called GP, I'd have used `foo.gp' as the config file name. But `foo.gpi' and `foo.gpd' are already used. Of course, we could think about renaming one of them as well -- preferably gpd because it isn't so widespread yet.)
or "cgp"?
Hmm, doesn't seem to be taken, at least in Debian ...
Frank
On 27 May 2004 at 1:33, Frank Heckenbach wrote:
[...]
or "gpi" or "gpd"
These are the file name suffixes used by GPC and GP. If the name was different, we could use that name as the suffix for configuration files. (I don't like `.cfg' as you suggested. First, it's very generic; second, using program specific config files, if `foo.pas' is a program, then `foo.cfg' might be used by the programmer for a program config file, so we shouldn't use that name as the program build config file. I.e., if the tool is called GP, I'd have used `foo.gp' as the config file name. But `foo.gpi' and `foo.gpd' are already used. Of course, we could think about renaming one of them as well -- preferably gpd because it isn't so widespread yet.)
Well, Borland has .tpu and .dcu for Turbo and Delphi units respectively. Perhaps we could use .gpu for GPC units.
I have no particular preference of extension for program build configuration files.
or "cgp"?
Hmm, doesn't seem to be taken, at least in Debian ...
Perhaps we could use this then?
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku (The African Chief) wrote:
or "cgp"?
Hmm, doesn't seem to be taken, at least in Debian ...
Perhaps we could use this then?
Objections, anyone?
Matthias, would it be ok for Debian?
Frank
Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
or "cgp"?
Hmm, doesn't seem to be taken, at least in Debian ...
Perhaps we could use this then?
Objections, anyone?
Matthias, would it be ok for Debian?
I do not understand why you press for very short name. Such name is typically meanigless (for me "cgp" is meanigless), and as I wrote hard to search for. I would say that a person who do not want to type three additional characters in program name is likely to drop Pascal for a language where `begin' is repleced by a single character.
For me `gpmake' sounds almost perfect. I have a checked various languages and most do not try to use very short names. In fact I have a bunch of `xmake' programs which either generate makefiles or work as make replacement for a given language. `gpbuild' probably sound a bit better for new users, but `gpmake' is more accurate. AFAIKS the concept of "making" is widely known -- even if plain `make' is not useful for given language.
Waldek Hebisch wrote:
Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
or "cgp"?
Hmm, doesn't seem to be taken, at least in Debian ...
Perhaps we could use this then?
Objections, anyone?
Matthias, would it be ok for Debian?
I do not understand why you press for very short name. Such name is typically meanigless (for me "cgp" is meanigless),
Compile (with) GNU Pascal.
and as I wrote hard to search for. I would say that a person who do not want to type three additional characters in program name is likely to drop Pascal for a language where `begin' is repleced by a single character.
After many "complaints" I've seen so far over the years, I think it's *very* important for new potential users that the first steps are as easy as possible. Even a longer name might be deterring. (Maybe sad, but true.)
For me `gpmake' sounds almost perfect. I have a checked various languages and most do not try to use very short names. In fact I have a bunch of `xmake' programs which either generate makefiles or work as make replacement for a given language.
As I said, I don't think "make" is a good thing to think of for a *normal* Pascal programmer. We're, of course, deep in the internals, but a normal programm doesn't want to (and shouldn't have to) think about when a compiler recreates which files. It should just produce a correct executable.
Frank
On 29 May 2004 at 17:25, Frank Heckenbach wrote:
Waldek Hebisch wrote:
[...]
I do not understand why you press for very short name. Such name is typically meanigless (for me "cgp" is meanigless),
Compile (with) GNU Pascal.
Or, Compiler for GNU Pascal.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku (The African Chief) a écrit:
On 29 May 2004 at 17:25, Frank Heckenbach wrote:
Waldek Hebisch wrote:
[...]
I do not understand why you press for very short name. Such name is typically meanigless (for me "cgp" is meanigless),
Compile (with) GNU Pascal.
Or, Compiler for GNU Pascal.
I had understood that the problem to solve with gp is that the automake feature is now included as a large bunch at the end of the compiler driver gpc.exe, and that this causes large maintenance problems for every change of gcc major release. This forbids to merge pascal into the gcc main line, and to use gcc.exe as the compiler driver like for other gcc languages, after a minor arrangement with gcc maintainers to add pascal as a recogized language. gp was created to separate the automake problem from the remaining tasks of the compiler. So what about a two step process: - use gp until the compiler driver can be merged in gcc (soon ?) - rename gp to gpc afterwards. This will be somewhat incompatible with some makefiles, but the final result is logical, simple, and natural for everybody. The incompatible changes to makefiles will be minor: gpc -- automake --> gpc any beginner will prefer that, this is what all do ! gpc -c --> gcc -c like for any other gcc language choice of proper compiler is with extension
Am I overlooking something ? This is the same as the relationship between gpp (g++) and gcc (but where the difference is only in the linking stage) ?
Maurice
Frank Heckenbach wrote:
Waldek Hebisch wrote:
Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
or "cgp"?
Hmm, doesn't seem to be taken, at least in Debian ...
Perhaps we could use this then?
Objections, anyone?
Matthias, would it be ok for Debian?
I do not understand why you press for very short name. Such name is typically meanigless (for me "cgp" is meanigless),
Compile (with) GNU Pascal.
You can "rationalize" anything (for example AMA -> Another Meanigless Acronym). However, regular naming for Gnu programs puts `g' at the begining. But we do not want `gcp' (= Gnu `cp'). The point is that we loose much of psychological proxymity to gpc (in alphabetical listings `cgp' and `gpc' will show separate). Of course it is better then: aap - Absolutely Automatic Pascal apa - Awesome Pascal Automaker bpb - Beautiful Pascal Builder
but IMHO not much.
and as I wrote hard to search for. I would say that a person who do not want to type three additional characters in program name is likely to drop Pascal for a language where `begin' is repleced by a single character.
After many "complaints" I've seen so far over the years, I think it's *very* important for new potential users that the first steps are as easy as possible. Even a longer name might be deterring. (Maybe sad, but true.)
I think that shorthening name is misguided. Such users will complain about command line anyway. Give them IDE -- that will make a difference (note that IDE hides compiler/make name).
For me `gpmake' sounds almost perfect. I have a checked various languages and most do not try to use very short names. In fact I have a bunch of `xmake' programs which either generate makefiles or work as make replacement for a given language.
As I said, I don't think "make" is a good thing to think of for a *normal* Pascal programmer. We're, of course, deep in the internals, but a normal programm doesn't want to (and shouldn't have to) think about when a compiler recreates which files. It should just produce a correct executable.
I claim that `make' has quite good "name recognition". Even if they do not know what `make' is actually doing, they do know it a way to compile programs. IIRC BP IDE had `Make' and `Build' position in the menu, so the name should be known for a lot of folks.
At 5:25 PM +0200 29/5/04, Frank Heckenbach wrote:
Compile (with) GNU Pascal.
and as I wrote hard to search for. I would say that a person who do not want to type three additional characters in program name is likely to drop Pascal for a language where `begin' is repleced by a single character.
:-)
For me `gpmake' sounds almost perfect. I have a checked various languages and most do not try to use very short names. In fact I have a bunch of `xmake' programs which either generate makefiles or work as make replacement for a given language.
This is little too close to gmake for my comfort - in fact I actually read it as gmake at first and had to go back and read it again. Possibly too easy to mistype too?
As I said, I don't think "make" is a good thing to think of for a *normal* Pascal programmer. We're, of course, deep in the internals, but a normal programm doesn't want to (and shouldn't have to) think about when a compiler recreates which files. It should just produce a correct executable.
You could try keep it all within gpc as so not to generate another name that could conflict. Make gpc itself a small program that manages whatever programs do the actual work. Have users pass options to this to invoke the appropriate action either as a '-' option, e.g.
gpc -make <file(s)>
or take it a bit further in the spirit of make install, make clean:
gpc compile <options> gpc link <options> gpc make <options> gpc clean <options> gpc <options>
etc. (with a default of compile to make it compatible with previous use, as in the last example)
Pesonally I like the latter. No new name to remember, no new name to conflict with existing one, its obvious its part of gpc and you've got a wrapper you can plant anything in the future under.
If people are worried about typing, provide short-hand alternatives:
gpc c <options> gpc l <options> gpc cl <options> gpc m <options>
If you must make it separate, I'd personally refer gpc-make or gpcmake to associate it with gpc and make it more distinct from gmake.
As for cgp. Ugh. Sorry ;-)
(btw, the -noprebind does the trick Adrian, thanks.)
Cheers,
Grant
Grant Jacobs wrote:
As I said, I don't think "make" is a good thing to think of for a *normal* Pascal programmer. We're, of course, deep in the internals, but a normal programm doesn't want to (and shouldn't have to) think about when a compiler recreates which files. It should just produce a correct executable.
You could try keep it all within gpc as so not to generate another name that could conflict. Make gpc itself a small program that manages whatever programs do the actual work.
That's what the program in question ("GP") actually is. (So, as I suggested, we could rename the existing gpc executable and call this one gpc. But I'm not sure yet, because it is an incompatible change ...)
Have users pass options to this to invoke the appropriate action either as a '-' option, e.g.
gpc -make <file(s)>
gp file
or take it a bit further in the spirit of make install, make clean:
gpc compile <options>
gp -c file
gpc link <options>
gp file
gpc clean <options>
gp --clean file
It's all there.
Of course, if one wants to build external stuff (manuals etc.), this is not covered (and shouldn't be IMHO). One should use a real make then (which can invoke "gp" in turn).
Frank
Frank Heckenbach wrote:
Grant Jacobs wrote:
As I said, I don't think "make" is a good thing to think of for a *normal* Pascal programmer. We're, of course, deep in the internals, but a normal programm doesn't want to (and shouldn't have to) think about when a compiler recreates which files. It should just produce a correct executable.
You could try keep it all within gpc as so not to generate another name that could conflict. Make gpc itself a small program that manages whatever programs do the actual work.
That's what the program in question ("GP") actually is. (So, as I suggested, we could rename the existing gpc executable and call this one gpc. But I'm not sure yet, because it is an incompatible change ...)
But that is what gcc is doing already, except it is orchestrating between various languages to arrive at a common executable format. Meanwhile it is involving such diverse programs as 'as', 'ld', etc.
IMO the thing that is missing in GPC is clear instructions as to how to run individual compiles etc. for systems that include units and/or modules and/or libraries. Saying "use -automake" does not cut it. Of course, that seems to be exactly the problem you are trying to solve, but hiding the machiniations behind yet another supervisory program does not fill the bill to my mind. Therefore I propose the name YASP. :-)
I would rather see a program that scans the various sources, starting from the named one, and creates a make file for use by gnu make. This is more a Unix philosophy than a C one. After that a simple script or bat file should be able to replace YASP. Pascal is a simple language, using it should also be simple.
CBFalconer wrote:
Frank Heckenbach wrote:
Grant Jacobs wrote:
As I said, I don't think "make" is a good thing to think of for a *normal* Pascal programmer. We're, of course, deep in the internals, but a normal programm doesn't want to (and shouldn't have to) think about when a compiler recreates which files. It should just produce a correct executable.
You could try keep it all within gpc as so not to generate another name that could conflict. Make gpc itself a small program that manages whatever programs do the actual work.
That's what the program in question ("GP") actually is. (So, as I suggested, we could rename the existing gpc executable and call this one gpc. But I'm not sure yet, because it is an incompatible change ...)
But that is what gcc is doing already, except it is orchestrating between various languages to arrive at a common executable format. Meanwhile it is involving such diverse programs as 'as', 'ld', etc.
But in a "C-ish" way: compile a single file, don't care about dependencies etc.
Keep in mind that automake is a kludged-on extension that never worked correctly (and probably never could). It's served its time more or less well, but it isn't a workable solution for the future.
IMO the thing that is missing in GPC is clear instructions as to how to run individual compiles etc. for systems that include units and/or modules and/or libraries. Saying "use -automake" does not cut it. Of course, that seems to be exactly the problem you are trying to solve, but hiding the machiniations behind yet another supervisory program does not fill the bill to my mind.
Why not, if I may ask?
I would rather see a program that scans the various sources, starting from the named one, and creates a make file for use by gnu make. This is more a Unix philosophy than a C one.
I had thought about it before starting work on "GP", but came to the conclusion that it didn't really work out. As Waldek explained recently, the creation of both .gpi and .o files doesn't really fit with the make idea (single destination), and any possible work-arounds would at best be kludges.
Besides, not using make, we could be a bit more clever, e.g. not recompile a module [interface], if the module [interface] text is unchanged, even if the file was updated. make can't do this without big kludges (more external programs, timestamps and what not).
(Another thing is that we save one step by doing "GP -> gpc" rather than "GP -> make -> gpc", but that's a minor point.)
After that a simple script or bat file should be able to replace YASP.
I (had?) hoped that we could do without that, especially since "GP" is meant to add some config file and options translation mechanism, so that indeed a user could, after initially setting things up to this taste, just do `gp myprog' in almost all cases. That's also why I'd like to have a short name (not least because that's what I intend to use myself. Currently I do use scripts/aliases around `gpc', but I hoped to get rid of that with "GP" in place).
Pascal is a simple language, using it should also be simple.
While there may be debates on the first part (the module concept and other EP features really have some nontrivial aspects ;-), I agree on the second part, see the previous paragraph. (And the plain gcc/gpc interface, especially when automake is removed, certainly doesn't do that.)
BTW, I wonder if we need the (current) gpc executable at all then. I'd have to check exactly, but maybe it wouldn't basically do more than the equivalent of `gcc -lm -lgpc' (and give some different help output etc.). If we teach "GP" to pass `-lm -lgpc', we could get rid of the separate gpc executable and call "GP" gpc. But I'm not sure if everybody would be comfortable with such a change ...
Frank
On 15:34 30/05/04, Frank Heckenbach wrote:
output etc.). If we teach "GP" to pass `-lm -lgpc', we could get rid of the separate gpc executable and call "GP" gpc. But I'm not sure if everybody would be comfortable with such a change ...
Here's my take on this issue:
When GPC is merged into GCC--where `soon' is barely soon enough (and I think I speak for the majority)--and when, as you have already speculated in your previous post, the gpc executable becomes unnecessary, then people will have to deal with it, whether they'd like to or not.
Soo... I guess what I'm trying to say here is, when the Merge happens, renaming GP's executable into `gpc' won't be a problem.
Dixitur illum ih8mj@fjf.gnu.de scribere...
gnu make. This is more a Unix philosophy than a C one.
^^^ Note that this produced a hiccup on part of some readers. Please don't assume the world consists only of ILP32, ELF, #include <linux.h> and stuff like that.
output etc.). If we teach "GP" to pass `-lm -lgpc', we could get rid of the separate gpc executable and call "GP" gpc. But I'm not sure if everybody would be comfortable with such a change ...
Actually, that idea crossed my mind earlier, and it sounds more natural. I was always wondering why you didn't just use the gcc driver, except for maybe some more esoteric features (which can be done by the now-gp thing then).
Bye, //Thorsten
Thorsten Glaser wrote:
Dixitur illum ih8mj@fjf.gnu.de scribere...
gnu make. This is more a Unix philosophy than a C one.
^^^ Note that this produced a hiccup on part of some readers. Please don't assume the world consists only of ILP32, ELF, #include <linux.h> and stuff like that.
If you point out such things, it may be useful to set attributions correctly. I didn't write the above.
FWIW, as I wrote, I won't do as Chuck suggested here for other reasons, so this issue is actually irrelevant now.
output etc.). If we teach "GP" to pass `-lm -lgpc', we could get rid of the separate gpc executable and call "GP" gpc. But I'm not sure if everybody would be comfortable with such a change ...
Actually, that idea crossed my mind earlier, and it sounds more natural. I was always wondering why you didn't just use the gcc driver, except for maybe some more esoteric features (which can be done by the now-gp thing then).
Basically because "everybody" does it, i.e. each frontent has its own such driver AFAIK. But that's not a coercing point, of course. And, as I said, we could still offer the (current) gpc driver (without automake) under another (and even longer, AFAIC ;-) name.
Frank
Frank Heckenbach wrote:
Basically because "everybody" does it, i.e. each frontent has its own such driver AFAIK. But that's not a coercing point, of course. And, as I said, we could still offer the (current) gpc driver (without automake) under another (and even longer, AFAIC ;-) name.
You many times mentioned removing automake. I think you are too fast here. As I understand main problems with automake are: 1) bugs 2) maintenance
IMHO the main remaining bug is that gpc writes to GPI files after compiling interface. That bug affects `gp' too. Both automake and `gp' try to workaround that, but the real fix is to write implementation info in another place (for example a new GPI file).
Concerning maintenance I do not think the cost is so big, and one part (updating `gpc' driver) ATM is "paid" for next few months.
I am somwhat affraid of effort to maintain `gp'. I gave only short look over the sources and I did not give it real trial. However, from your comments I understand that ATM `gp' misses some automake features. Also, I am somewhat concerned by the `gp' parser (you use flex to implement it, but conceptually it is a parser). In fact, it is not clear that in GNU Pascal one can find names of imported interfaces/units without looking at all of imported interfaces. The problem is that parsing requires to know what a keyword is and many keywords are "weak" -- they may be redefined (also in imported interfaces!). Frank, you probably analysed that, but assumptions needed for `gp' to work should be written up. And some time is needed to asess if changes to GNU Pascal language will not invalidate those assumptions.
So IMHO we need few months (or a year) for `gp' to stablise _before_ we can depreciate automake. And I think that we should have a year of depreciation before removal.
Waldek Hebisch wrote:
Frank Heckenbach wrote:
Basically because "everybody" does it, i.e. each frontent has its own such driver AFAIK. But that's not a coercing point, of course. And, as I said, we could still offer the (current) gpc driver (without automake) under another (and even longer, AFAIC ;-) name.
You many times mentioned removing automake. I think you are too fast here.
Sorry, but this has been discussed (and decided) for years. It can't really be called too fast.
As I understand main problems with automake are:
- bugs
- maintenance
IMHO the main remaining bug is that gpc writes to GPI files after compiling interface. That bug affects `gp' too. Both automake and `gp' try to workaround that, but the real fix is to write implementation info in another place (for example a new GPI file).
Why do you think this is a bug, and where do you think gp tries to work around it? (In fact, gp doesn't even look at the contents of GPI files. It looks at the timestamps, but that's more like an additional paranoia check.)
Concerning maintenance I do not think the cost is so big, and one part (updating `gpc' driver) ATM is "paid" for next few months.
IIRC, about half of your recent patch is for the driver (the other half are qualified identifiers and other substantial features), and that's only for gcc-3.3.x->3.4.0. If that's not a big cost, I don't know.
And there are additional kludges in module.c (and smaller parts in other source files). You might not have had to work on this code yet, but I had to, many times, and the code is very fragile.
And that's where the real automake bugs are AFAIK. Currently I made it recompile too much rather than too little (which is bad for efficiency, and we don't even talk about checking file contents (MD5 sums as GP does) instead of just timestamps), and still it might miss some recompilations (didn't check exactly, and such situations are very tricky to debug and unnerving -- I had to do this a number of times). The core problem is that is has only local information (about the current module and its dependencies).
Besides, calling the gpc driver (recursively) from the compiler proper (gpc1) is not really in the intention of this design. So far it's seemed to work (or more precisely, we've just copied the necessary parts, pexecute etc., from gpc to gpc1), but I don't know if it won't break with some GCC version. Also, recursion is more memory hungry than iteration (as done by "GP", or make FTM).
I am somwhat affraid of effort to maintain `gp'. I gave only short look over the sources and I did not give it real trial. However, from your comments I understand that ATM `gp' misses some automake features.
Which ones?
BTW, since GP is written mostly in Pascal, it should be easier for many people to maintain it when necessary. (At least from the negative comments I've often seen about GPC being written in C.)
Also, I am somewhat concerned by the `gp' parser (you use flex to implement it, but conceptually it is a parser).
Yes.
In fact, it is not clear that in GNU Pascal one can find names of imported interfaces/units without looking at all of imported interfaces.
I'm not sure exactly what you mean. If a program says `uses foo;' or `import foo;', the name of the imported unit/interface is `foo'. Do you mean the file name (it's `foo.{pas,p,...}' unless `in '...'' is given etc., that's the same for automake)? Or do you mean names of indirectly imported interfaces (they're stored in gpd files etc.)?
And, of course, GP does look at all of the imported units/modules (either their .gpd files if existing and up to date, or their source code). It just does it in a cleaner (IMHO) way, file by file, rather than recursively intermixed (and often duplicated) as automake.
The problem is that parsing requires to know what a keyword is and many keywords are "weak" -- they may be redefined (also in imported interfaces!). Frank, you probably analysed that, but assumptions needed for `gp' to work should be written up.
Yes. In fact it may fail in some very strange cases (very crude mixtures of dialects, I doubt whether they'd ever occur in practice).
But this parser is only a small part of gp and easy to fix/rewrite. In fact, I'm thinking about using the real GPC parser -- either as a special mode to GPC itself (comparable to `-E' for the preprocessor which lists dependencies only), but it might be too much effort to "do nothing" in many places; or just taking the bison parser and removing everything unrelated (which will be a lot, including most semantic actions, so a rather simple parser remains). I think that's not a big deal, but before I do anything about it, first I want to integrate the GPC preprocessor because this may influence things.
And some time is needed to asess if changes to GNU Pascal language will not invalidate those assumptions.
Sure, changes that affect the import and export syntax could, but again, that's not a big deal. Adding a few rules to the parser (whether flex based as now, or bison based) is a matter of minutes (maybe less than it takes me to write this mail) and I expect it to happen very rarely.
So IMHO we need few months (or a year) for `gp' to stablise _before_ we can depreciate automake. And I think that we should have a year of depreciation before removal.
We can discuss time scales. I'd like to have automake deprecated in gpc-2.2, but I don't know when gpc-2.2 will be released (maybe next year).
For now, I'd like people (who used automake) to try GP in order to see if there are fundamental problems with it in practical use. This will take some months at least, of course, until we can be sure, and during this time, GP should also stabilize (as the few bugfixes in the last two weeks have already shown) ...
Frank
Frank Heckenbach wrote:
Waldek Hebisch wrote:
As I understand main problems with automake are:
- bugs
- maintenance
IMHO the main remaining bug is that gpc writes to GPI files after compiling interface. That bug affects `gp' too. Both automake and `gp' try to workaround that, but the real fix is to write implementation info in another place (for example a new GPI file).
Why do you think this is a bug, and where do you think gp tries to work around it? (In fact, gp doesn't even look at the contents of GPI files. It looks at the timestamps, but that's more like an additional paranoia check.)
"Language independent" way to decide if file is up to date is to look at its timestamp. Writing to GPI files after compiling interface means that timestamp may change and that breaks dependency analysis -- for example it is impossible to put dependencies in the makefile. In case of gpc itself we have this ugly `stamp-error-gpi' (which already caused multiple build failures) where we should dependencies on `.gpi' files.
As I wrote in another message I implementd `--disable-gpi-extension' option. With that option I can do:
gpc --automake --interface-only *.pas gpc --disable-gpi-extension --implementation-only *.pas gpc *.o
and that works even if there are cyclic imports (and implementations can be anywhere). Without `--disable-gpi-extension' the second line fails. I treat looking at the content of GPI as workaround. More precisely, I treat avoiding recompilation using extra info as a valuable optimisation, but the build should work correctly using only timestamps on files -- otherwise integration into makefiles gets very fragile.
Concerning maintenance I do not think the cost is so big, and one part (updating `gpc' driver) ATM is "paid" for next few months.
IIRC, about half of your recent patch is for the driver (the other half are qualified identifiers and other substantial features), and that's only for gcc-3.3.x->3.4.0. If that's not a big cost, I don't know.
The diff is huge -- probably 70-80% of the patch. But there are almost no really new code here. The main effort was to add back code removed from gcc-3.4.0 (+ conditioning on version). That was not trivial, as there were a few nasty incompatibilities between old and new driver. Nevertheless, it took less then 20% of effort (probably below 10%).
Two additional points: 1) time saved by gcc folks when they introduced incompatibility is probably much smaller then what I spent to correct the problem. Similarly I belive that my time spent on keeping things compatible will save other folks my more than I lost. 2) gcc-3.3.x->3.4.0 changes were large. Part was (better) multilibing support. They also changed directory structure. I hope that changes in the near future will be smaller
And there are additional kludges in module.c (and smaller parts in other source files). You might not have had to work on this code yet, but I had to, many times, and the code is very fragile.
OK, you know that better.
And that's where the real automake bugs are AFAIK. Currently I made it recompile too much rather than too little (which is bad for efficiency, and we don't even talk about checking file contents (MD5 sums as GP does) instead of just timestamps), and still it might miss some recompilations (didn't check exactly, and such situations are very tricky to debug and unnerving -- I had to do this a number of times). The core problem is that is has only local information (about the current module and its dependencies).
I do not see why using only local information is wrong -- of course assuming that all local information is consistent. I wonder if it really is not the same bug -- I say that local info is getting inconsistent and we should correct that. You say that we should not relay on local info. I am affraid that we are repeating what we wrote earlier. But all problems with automake I saw are solved by keeping correct timestamps.
I am somwhat affraid of effort to maintain `gp'. I gave only short look over the sources and I did not give it real trial. However, from your comments I understand that ATM `gp' misses some automake features.
Which ones?
Quick test (I still have to read the info file so mybe there is easy way to do that):
../../tst25/gp-0.54/gp PC='/pom/kompi/gcc/tst26/gpc7-3.4/gcc/xgpc' -B/pom/kompi/gcc/tst26/gpc7-3.4/gcc/ --no-default-paths -c *.pas gp: only one file name allowed on the command line
Intent: compile everything without linking
Also: ../../tst25/gp-0.54/gp PC='/pom/kompi/gcc/tst26/gpc7-3.4/gcc/xgpc' -B/pom/kompi/gcc/tst26/gpc7-3.4/gcc/ --no-default-paths --interface-only -c *.pas gp: `--interface-only' is meant to be used with GPC/GCC directly, not with GP
Intent: compile all interfaces
Actually, things like '*.pas' seem a good way to tell GP: "Scan the sources to find interfaces and implementations, then compile and link what is needed"
In all GP works quie well (as you see I have some nasty wishes).
BTW, since GP is written mostly in Pascal, it should be easier for many people to maintain it when necessary. (At least from the negative comments I've often seen about GPC being written in C.)
I think that GPC being in C is a big plus. Namely, we reuse _a lot_ of work that C folks did. And we can easily find C compiler to bootstrap. I often hear comments "that code is too complicated, I prefer to write from scratch then reuse it". And GCC code is considerd "hard" compared to other codes. I affraid that many fols that say "I can not help -- it is in C" would say "I can not help -- it is too complicated".
GP code should be simpler than typical compiler code, that is a plus. But in some parts C and Pascal have to be in sync. Without automatic checks that may be a problem.
Also, I am somewhat concerned by the `gp' parser (you use flex to implement it, but conceptually it is a parser).
Yes.
In fact, it is not clear that in GNU Pascal one can find names of imported interfaces/units without looking at all of imported interfaces.
I'm not sure exactly what you mean. If a program says `uses foo;' or `import foo;', the name of the imported unit/interface is `foo'. Do you mean the file name (it's `foo.{pas,p,...}' unless `in '...'' is given etc., that's the same for automake)? Or do you mean names of indirectly imported interfaces (they're stored in gpd files etc.)?
Well: program foo; type bar = (a); operator uses(x, y : bar) z : bar; begin z := x end; var import, v : bar; begin import := v uses v; end .
as you see 'uses v;' is not `uses' at all. Probably it is enough to check if there is a semicolon before -- what I am asking is if you have checked all productions of the bison grammar to verify that we will not get something more nasty.
And, of course, GP does look at all of the imported units/modules (either their .gpd files if existing and up to date, or their source code). It just does it in a cleaner (IMHO) way, file by file, rather than recursively intermixed (and often duplicated) as automake.
The problem is that parsing requires to know what a keyword is and many keywords are "weak" -- they may be redefined (also in imported interfaces!). Frank, you probably analysed that, but assumptions needed for `gp' to work should be written up.
Yes. In fact it may fail in some very strange cases (very crude mixtures of dialects, I doubt whether they'd ever occur in practice).
I am affraid that "I doubt whether they'd ever occur in practice" was used when automake was designed. Robust tool should accept _everything_ that `gpc' accepts (it may be slightly more tolerant on malformed inputs, but to limit confusion not too much). Note, that automake by it very nature uses the same parser, so it is immune to such problems.
But this parser is only a small part of gp and easy to fix/rewrite. In fact, I'm thinking about using the real GPC parser -- either as a special mode to GPC itself (comparable to `-E' for the preprocessor which lists dependencies only), but it might be too much effort to "do nothing" in many places; or just taking the bison parser and removing everything unrelated (which will be a lot, including most semantic actions, so a rather simple parser remains). I think that's not a big deal, but before I do anything about it, first I want to integrate the GPC preprocessor because this may influence things.
I wonder at what stage is the preprocessor. Actually, I was going to do the opposite -- integrate enough of the backend into `gpcpp' to get predefines working with 3.3.x and 3.4. I am slightly concerned as you engage in large rewrites, that take time. Maybe it is better to go on with old preprocessor -- IIRC the only problem I saw was ppc backend, but that is solved by the patch I posted.
And some time is needed to asess if changes to GNU Pascal language will not invalidate those assumptions.
Sure, changes that affect the import and export syntax could, but again, that's not a big deal. Adding a few rules to the parser (whether flex based as now, or bison based) is a matter of minutes (maybe less than it takes me to write this mail) and I expect it to happen very rarely.
I am somewhat concerned that we have only tests to verify that parsing works correctly. With old (non-glr) bison parser in GPC we had warranty of uniqueness (+ 1 symbol lookahead) which greatly reduced possiblity for surprising parses. Now we less predictable bison parser and we want to keep it in sync with the parser in GP. It would be nice to have automatic verifcation that both parsers give equivalent result. (One of my pet project is a tool to check uniqueness of the parse for "arbitrary" grammar -- of course unsolvable, but a bunch of tricks may go far enough.)
So IMHO we need few months (or a year) for `gp' to stablise _before_ we can depreciate automake. And I think that we should have a year of depreciation before removal.
We can discuss time scales. I'd like to have automake deprecated in gpc-2.2, but I don't know when gpc-2.2 will be released (maybe next year).
Realistically, our timeframes look similar.
Waldek Hebisch wrote:
Frank Heckenbach wrote:
Basically because "everybody" does it, i.e. each frontent has its own such driver AFAIK. But that's not a coercing point, of course. And, as I said, we could still offer the (current) gpc driver (without automake) under another (and even longer, AFAIC ;-) name.
So IMHO we need few months (or a year) for `gp' to stablise _before_ we can depreciate automake. And I think that we should have a year of depreciation before removal.
Wait a minute -- are we really talking about removing the "automake" option from the GPC command line?
Up to now, I'm heavily using it in the "autoconfed" and "automade" Makefiles for my GPC projects. :-} I wouldn't exactly be glad if it was gone.
Yours,
Markus
Markus Gerwinski wrote:
Waldek Hebisch wrote:
Frank Heckenbach wrote:
Basically because "everybody" does it, i.e. each frontent has its own such driver AFAIK. But that's not a coercing point, of course. And, as I said, we could still offer the (current) gpc driver (without automake) under another (and even longer, AFAIC ;-) name.
So IMHO we need few months (or a year) for `gp' to stablise _before_ we can depreciate automake. And I think that we should have a year of depreciation before removal.
Wait a minute -- are we really talking about removing the "automake" option from the GPC command line?
Yes -- for years.
Up to now, I'm heavily using it in the "autoconfed" and "automade" Makefiles for my GPC projects. :-} I wouldn't exactly be glad if it was gone.
Use GP (or whatever it will finally be called) then.
Frank
Markus Gerwinski wrote:
Waldek Hebisch wrote:
Frank Heckenbach wrote:
Basically because "everybody" does it, i.e. each frontent has its own such driver AFAIK. But that's not a coercing point, of course. And, as I said, we could still offer the (current) gpc driver (without automake) under another (and even longer, AFAIC ;-) name.
So IMHO we need few months (or a year) for `gp' to stablise _before_ we can depreciate automake. And I think that we should have a year of depreciation before removal.
Wait a minute -- are we really talking about removing the "automake" option from the GPC command line?
Yes.
Up to now, I'm heavily using it in the "autoconfed" and "automade" Makefiles for my GPC projects. :-} I wouldn't exactly be glad if it was gone.
The `gp' program is supposed to be a better replacement. As you see I argue that we need enough time for smooth transition.
Waldek Hebisch wrote:
Up to now, I'm heavily using it in the "autoconfed" and "automade" Makefiles for my GPC projects. :-} I wouldn't exactly be glad if it was gone.
The `gp' program is supposed to be a better replacement. As you see I argue that we need enough time for smooth transition.
I fully agree here. In fact, that's why I released it now, even though it doesn't yet have some features I'd like to implement, e.g. config files (automake doesn't have them as well, so they're irrelevant for the transition).
As I said, I plan to keep automake until the next non-alpha/beta release (gpc-2.2, or perhaps gpc-3.0, given the new features, and to converge towards the gcc version).
Afterwards I think it's a good time for several big cleanups (automake, gcc-2.x support, `asmname' and other deprecated features).
Frank
Markus Gerwinski wrote:
Wait a minute -- are we really talking about removing the "automake" option from the GPC command line?
Up to now, I'm heavily using it in the "autoconfed" and "automade" Makefiles for my GPC projects. :-} I wouldn't exactly be glad if it was gone.
I suggest to add --automake as an option to gp, equivalent to its current option --no-autobuild (default). This eases the transformation to gp (especially if at some point in the future gp will be called gpc).
Regards,
Adriaan van Os
Adriaan van Os wrote:
Markus Gerwinski wrote:
Wait a minute -- are we really talking about removing the "automake" option from the GPC command line?
Up to now, I'm heavily using it in the "autoconfed" and "automade" Makefiles for my GPC projects. :-} I wouldn't exactly be glad if it was gone.
I suggest to add --automake as an option to gp, equivalent to its current option --no-autobuild (default). This eases the transformation to gp (especially if at some point in the future gp will be called gpc).
Yes, could be useful. Also `--executable-file-name' without argument (does nothing then), probably.
Frank
On 17:25 29/05/04, Frank Heckenbach wrote:
As I said, I don't think "make" is a good thing to think of for a *normal* Pascal programmer. We're, of course, deep in the internals, but a normal programm doesn't want to (and shouldn't have to) think about when a compiler recreates which files. It should just produce a correct executable.
Sorry for the late reply.
First, something about me: Until a few days ago, I've never developed anything non-trivial on a UNIX platform. Until a few days ago, I've never even used a compiler on a UNIX, aside for installing other people's applications. At least, AFAICR.
My first programming language (ignoring BASIC, of course) is Pascal. For several years, I've only used Borland's Pascal environments (TP, BP, TPW, Delphi).
So, anyway, believe you me that a Pascal programmer (providing she hasn't been under a rock for the past, oh... decade or so?) will have, at some point in their programming experience come across the term `make' in the context of this discussion. Not only that, but that same programmer will at least have a vague (but usable) idea of what `make' in this context means.
This might seem like something against the arguments I have for renaming GP's executable into `gpc' after the Merge (see another message of mine in this thread), but that is not my intention.
Just my two cents. And sorry for the long reply; it's been a long day, and it's hard for me to think cohesively.
Neil Santos wrote:
On 17:25 29/05/04, Frank Heckenbach wrote:
As I said, I don't think "make" is a good thing to think of for a *normal* Pascal programmer. We're, of course, deep in the internals, but a normal programm doesn't want to (and shouldn't have to) think about when a compiler recreates which files. It should just produce a correct executable.
Sorry for the late reply.
First, something about me: Until a few days ago, I've never developed anything non-trivial on a UNIX platform. Until a few days ago, I've never even used a compiler on a UNIX, aside for installing other people's applications. At least, AFAICR.
My first programming language (ignoring BASIC, of course) is Pascal. For several years, I've only used Borland's Pascal environments (TP, BP, TPW, Delphi).
So, anyway, believe you me that a Pascal programmer (providing she hasn't been under a rock for the past, oh... decade or so?) will have, at some point in their programming experience come across the term `make' in the context of this discussion. Not only that, but that same programmer will at least have a vague (but usable) idea of what `make' in this context means.
This might seem like something against the arguments I have for renaming GP's executable into `gpc' after the Merge (see another message of mine in this thread), but that is not my intention.
Just my two cents. And sorry for the long reply; it's been a long day, and it's hard for me to think cohesively.
Make is not the same thing as a Pascal build. The simple proof is that make and a Pascal builder can both be used, perhaps in tandem. Make is like an assembly language of builds, Pascal builders are the high level language of builds.
Just because people knew what assemblers were, that didn't make it a good idea to name high level languages "assemblers".
Or, to express it in reverse, every one knows what make does. A Pascal builder does not do that.
Finally, I occasionally use a Pascal automatic builder, a make file, and even a shell script file to build Pascal programs, different solutions for different reasons. So I would not want "make" to do anything I don't expect make to do.
On 14:42 30/05/04, Scott Moore wrote:
[everything else snipped]
So, anyway, believe you me that a Pascal programmer (providing she hasn't been under a rock for the past, oh... decade or so?) will have, at some point in their programming experience come across the term `make' in the context of this discussion. Not only that, but that same programmer will at least have a vague (but usable) idea of what `make' in this context means.
[same here]
Finally, I occasionally use a Pascal automatic builder, a make file, and even a shell script file to build Pascal programs, different solutions for different reasons.
Okay, I know my last message wasn't exactly cohesive, but I honestly cannot figure out out how your reply is related to my message at all.
I wasn't talking about the `Build' menu item in Borland's Pascal IDEs; I didn't even mention it. I know that building things in the Pascal sense isn't the same to what make does, but I don't recall saying that I did or didn't.
In short, I don't ever recall mentioning anything about Pascal-build. What I wanted to say was that `make' is a familiar term even to your normal, everyday Pascal programmer, with `highlights' of my programming `career' thrown in for a background.
I think I can even remember a `Make' menu item in a Pascal IDE, although I can't clearly remember which, since it has been a while since I've used a Pascal IDE. It's probably Virtual Pascal's, though...
So I would not want "make" to do anything I don't expect make to do.
Same here; probably because what the things I don't expect make to do are things make doesn't do.
Neil Santos wrote:
I think I can even remember a `Make' menu item in a Pascal IDE, although I can't clearly remember which, since it has been a while since I've used a Pascal IDE. It's probably Virtual Pascal's, though...
TP's IDE has `Compile', `Make', `Build' and `Run'. (Where most people probably use only `Run' and let the IDE deal with making/building/compiling. ;-)
So I would not want "make" to do anything I don't expect make to do.
Same here; probably because what the things I don't expect make to do are things make doesn't do.
There are many things make does that "GP" doesn't do and some things "GP" does that make doesn't do.
Frank
Hi folks
Not to be boring and stop the fun about "make", "cgp", etc., but I would like to go back to the functionality of gp (or whatever it is eventually called). Once or twice I have come across an error message saying something like "foo.gpi must be recompiled". Nothing but [a] deleting foo.gpi, and [b] compiling the program again, will cure this when it happens. It has happened randomly (it has only happened twice) and so I can't figure out what specifically triggers it.
I have searched in the gp sources for "recompiled" and "recompile", and I can't see any message similar to what I have got. Is this message embedded somewhere in the compiler sources? And, why doesn't gp just recompile automatically in these cases?
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku (The African Chief) wrote:
Not to be boring and stop the fun about "make", "cgp", etc., but I would like to go back to the functionality of gp (or whatever it is eventually called). Once or twice I have come across an error message saying something like "foo.gpi must be recompiled". Nothing but [a] deleting foo.gpi, and [b] compiling the program again, will cure this when it happens. It has happened randomly (it has only happened twice) and so I can't figure out what specifically triggers it.
I have searched in the gp sources for "recompiled" and "recompile", and I can't see any message similar to what I have got. Is this message embedded somewhere in the compiler sources? And, why doesn't gp just recompile automatically in these cases?
It's a GPC message and probably means that GP didn't recompile something before. According to the subject, I assume you have upgraded to 0.55 already?
As usual, I could probably better fix it if you can reproduce it somehow. If that's not possible, try sending me the `-v' output that files, the contents of all .gpd files involved and time stamps of all source, gpi, object and .gpd files.
Frank
Frank Heckenbach wrote:
As usual, I could probably better fix it if you can reproduce it somehow. If that's not possible, try sending me the `-v' output that files,
fails
(getting tired)
Frank
Waldek Hebisch wrote:
I do not understand why you press for very short name. Such name is typically meanigless (for me "cgp" is meanigless), and as I wrote hard to search for. I would say that a person who do not want to type three additional characters in program name is likely to drop Pascal for a language where `begin' is repleced by a single character.
I agree with Waldek and thoroughly dislike "cgp". It's ugly. Brrr. What about gpca or gpa (the a stands for automake) ? Also, gp is fine for me.
Regards,
Adriaan van Os
Adriaan van Os wrote:
Waldek Hebisch wrote:
I do not understand why you press for very short name. Such name is typically meanigless (for me "cgp" is meanigless), and as I wrote hard to search for. I would say that a person who do not want to type three additional characters in program name is likely to drop Pascal for a language where `begin' is repleced by a single character.
I agree with Waldek and thoroughly dislike "cgp". It's ugly. Brrr. What about gpca or gpa (the a stands for automake) ? Also, gp is fine for me.
If anything is ugly, it's automake. SCNR. ;-)
Besides, gpc is the GNU Privacy Assistant (GnuPG). Probably TLAs starting with g are even harder to find ...
Frank
Frank Heckenbach wrote:
Adriaan van Os wrote:
I agree with Waldek and thoroughly dislike "cgp". It's ugly. Brrr. What about gpca or gpa (the a stands for automake) ? Also, gp is fine for me.
If anything is ugly, it's automake. SCNR. ;-)
Besides, gpc is the GNU Privacy Assistant (GnuPG).
gpa, of course.
Frank
Hi
This discussion is getting really bizarre. I am not sure what ugly or pretty has to do with anything. All we are looking for is a short name for a program. I am sure that everyone can produce 10 names that they would rather find more beautiful (BTW, I think that Esmeralda is a wonderful name :-)). The point is that something needs to be chosen so that Frank can get on with it. Any name is perfectly fine. If we can't agree on one (and, from the discussions so far, I don't think that we will agree on one), then let's just stick with whatever Frank finds most beautiful (perhaps even just plain "gp").
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
On 07:36 30/05/04, Prof A Olowofoyeku (The African Chief) wrote:
BTW, I think that Esmeralda is a wonderful name :-).
Personally, I think Helena is the most beautiful name in the world; but I guess you can say I'm biased, since that's my wife's name. :D
Okay... Terribly off-topic post. Let's move on, people; nothing more to see in this post. :P
-
Adriaan van Os -
CBFalconer -
Emil Jerabek -
Frank Heckenbach -
Grant Jacobs -
Markus Gerwinski -
Matthias Klose -
Maurice Lombardi -
Neil Santos -
Prof A Olowofoyeku (The African Chief) -
Scott Moore -
Thorsten Glaser -
Waldek Hebisch