Hi Frank,

On Tue, 2010-07-27 at 00:16 +0200, Frank Heckenbach wrote:

Hi everybody,

since GPC development has mostly stalled, I've thought about if and how its development could be continued. Here are my current thoughts about it. Since the text is quite long, I put it on the web: http://fjf.gnu.de/gpc-future.html

[...]

I'm one of those who uses GPC for legacy code. Important legacy code, since it's the major code we use in our modelling and data analysis, which I started back in the 80s as a postdoc.

So I am eternally grateful that GPC saved me the trouble of rewriting the code when our main platforms became Linux, after using CDC, Prime, AIX, Sun and DEC machines (and perhaps some others that I've forgotten...)

My code is mostly generic Pascal, but I do interface with the Lapack libraries and some of the C file-handling functions. In fact, I mostly use an ancient Linux version of the compiler, since I have no need for developments of the language itself.

The translation idea sounds like a robust way of maintaining the Pascal capability and it offers the interesting possibility of running code on systems that only have C++ compilers installed by shipping the translated code rather than trying to install a Pascal compiler. If one wants to run on a supercomputer, for example, one may have limited compiler options. Even for generic Intel machines, one might want to recompile code optimised for the particular platform.

Mike

This email may be confidential and subject to legal privilege, it may not reflect the views of the University of Canterbury, and it is not guaranteed to be virus free. If you are not an intended recipient, please notify the sender immediately and erase all copies of the message and any attachments.

Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more information.

Hi, (eek, this got longer than I wanted)

On 7/30/10, Frank Heckenbach ih8mj@fjf.gnu.de wrote:

Rugxulo wrote:

...

relying on semi-outdated GCC versions (so?),

... so much effort is required which there's noone there to do. :-(

In other words, bugs that you yourself can't fix? I don't have any huge complaints with GCC 3.4.4, that's why I'm wondering why it deathly matters to have latest and greatest GCC support (besides the obligatory "it would be nice", e.g. Atom support or plugins in 4.5.0).

...

big runtimes and thus big .EXEs (so?),

Not a problem for most cases, sometimes a problem for embedded systems etc. and for people with a 1980s mindset ("oh shock, a few megabytes executable"). ;-)

It's more of when you write a very simple tool that takes 300 KiB. It just feels wrong, esp. from an "assembly" mindset or if you're spoiled by smartlinkers in other Pascal compilers. I'll admit, Frank, to be frank, ;-) in real life it doesn't matter in 99% of cases, but I do think libgpc.a could be modularized a bit better. (No, I haven't looked closely yet, my bad! And BTW, I strongly suspect GNU ld's --gc-sections doesn't work with COFF, blech.) I mean, no offense, but when a combined DOS 8086 (TP55) + Win32 .EXE (VP21) takes 24 KiB uncompressed .... ;-)

I don't want to get too philosophical, but I think a reason for its decline was that in several ways it just was too strict. E.g., while I dislike "goto" as much as Dijkstra did, I'm not so much opposed to "Exit" (which some dismiss as a disguised goto, and ISO Pascal doesn't have).

"Exit" as in "break" out of loop? I don't even think TP had it until v6 or (more likely) v7. Also note that some languages (Oberon, Java) don't support goto at all !! And FPC only handles local gotos.

(In fact, it might have been better to leave I/O completely out of the language, like C did, and let library authors develop it

Didn't Modula-2 do that, much to many people's chagrin??

Same with the lack of an official, and therefore standardized way, to interface with foreign-language libraries, a common necessity in real-world programs. (Sure, you can reinvent every wheel, i.e. reimplement every library in Pascal, but that's not productive.)

Ada has Interface (or whatever it's called). Doesn't matter anyways as there are so many competing formats (ELF, COFF, Mach-o) and linkers that work in varying degrees and different ABIs. (Agner's ObjConv potentially helps here, but I've never heavily used it.)

So that's perhaps why BP was popular under Dos, because it was one fixed dialect (so diverging extensions, though massively present, and their long-time consequences, were not known to the majority of programmers),

Except it also extended itself several times! So code that works for TP55 (objects, units) won't work in TP3, nor code in TP6 (inline asm). Plus bugs and heavy 16-bitisms. Doesn't mean lots of good stuff wasn't written in TP/BP (e.g. Chasm: The Rift), but most of that old code is pretty unmaintainable without the exact same compiler version (ahem, TPU incompatibilities).

I/O was extended to be at least suitable for Dos (though it maps less well to other systems which were ignored by most Dos programmers)

Since TP didn't run on anything else (CP/M dropped after v3 and only two TPW releases), that's no surprise, esp. since they never fully supported ISO 7185 or 10206. It's hard to be portable when you ignore standards. And yet most compilers nowadays (even on "modern" OSes, heh) try to emulate BP-style, oddly enough.

and supported modules (units) which allowed some other needed facilities (such as CRT) to be supplied. But all of this was too short-sighted:

Everything in computers is short-sighted. We're constantly being bit by it.

We now have a mess of dialects;

No worse than all those silly Romance languages. ;-)

Dos-style I/O is too limited on modern systems; even CRT (one of the least bad designed BP units IMHO) wasn't as lasting as its C roughly-counterpart curses).

C didn't have curses built-in anyways. In fact, it left a lot out, hence POSIX (which I guess has its own dialects, e.g. 2008). Nobody bothers with pure ANSI C anymore (sadly), which is more painful when using non-GCC compilers (like OpenWatcom).

So it's no surprise that BP's popularity sharply declines with Dos's.

Don't forget that they "dropped" DOS support! BP7 was the last one (1992?). That's the whole (initial) reason for FPC's existence! Even Delphi 1 (Win3x, 1995) was the only 16-bit Windows version. I don't know if their latest (14?) is 64-bit capable yet.

And under Windows, I'm not an expert, but ISTM that Delphi's decline is largely due to MS's pushing their own languages -- which is, of course, always a natural risk for anyone targeting Windows exclusively).

Borland spun off Code Gear a few years ago, and that was later bought by (current owner) Embarcadero (who, uncoincidentally, killed the "free" Turbo Explorer 2006 line, which C++ version never installed correctly for me under Vista anyways [.NET? *spit*], MarcoV says Turbo Delphi worked though).

Targeting Windows exclusively? Ick, yeah, people do that. Not that huge a deal (big install base) but kinda a hassle (too many .NET frameworks, 64-bit borg assimilation looming, lots of bugs). People love their C#, though.

I agree that Windows isn't the best platform to target. Heck, I know I'm on unsympathetic ears here, but I often think even Linux is too much of a moving target sometimes. (Don't get me started on Mac OS X, they deprecate everything too fast. *shudder*)

the current GPC users seem to be rather diverse (WRT dialects, platforms and features used etc.), which also doesn't bode well for a new project.

Like I said, your favorite dialect seems to be ISO 10206. (I saw you praising it in some old mail in list archive.) So you should probably just use that as a testbed for your C++ idea. It seems to have a fair bit in common with a few TP extensions, even, and (I think) it's a strict superset of ISO 7185 anyways. So everybody should be happy (famous last words)! ;-)

Don't get me wrong: I don't regret the time I spent with GPC, even if it was to die now.

Even DOS (FreeDOS), BeOS (Haiku), and OS/2 (eCS) aren't dead yet! Keep hope alive! ;-)

It was an interesting experience, learning a lot not only about the various Pascal dialects, but also about compiler construction in general (which has benefitted me in other projects since then), and since I did professional work with it, it was even paid. :-) And while it was at it, it was only natural to write my hobby projects in it as well. But as with many things, their time comes and it goes, and it may be its time has gone now and maintaining a compiler only for my hobby projects is just not efficient.

Yeah, computers can suck a lot of time out of you. Oddly enough, we spend so much time just to save more time later. But yeah, it's fun, so we (or at least I) don't mind much. ;-)

Rugxulo wrote:

Long story short, there's already a BP-ish Pascal to C++ (but also some C sometimes) converter! :-)

http://www.garret.ru/pascal.html

Tried it recently. Broken.

Scott Moore

Thanks for your replies so far. Here are some comments as a summary reply to several of your mails, in no particular order.

Kevan Hashemi wrote:

But if the compiler is written in Pascal, and compiles itself, I will be very happy to start trying to host the development of GPC myself, using some sort of version control code like GIT.

plus I have static IP addresses for hosting the code. At the very least, I could maintain the existing versions.

Thanks for the offer, but unfortunately that's not my main concern. Our server (where the web site is currently hosted) has static IP addresses and more than enough free bandwidth, and we could probably set up git easily (or even go to Sourceforge etc. if this was advantageous), but I'm afraid infrastructure will not write a program. (I'm a burned child here -- with several previous initiatives, including documentation, translation, libraries, and setting up a CVS, there was always much interest in creating the infrastructure (or at least in discussing the infrastructure), but once this was done (or not done), not much actual work happened.)

I usually work on MacOS, so I could cover the interface with the MacOS operating system. We would need other people to work on the interface with the other operating systems.

Also I'm afraid to say that this isn't one of my main concerns. We have runtime libraries, and as I listed under "Reusable parts", they could probably more or less be kept. The actual problem is really the compiler proper.

When it comes to debugging, I am always able to get by with writeln statements and looking at the console on Linux or MacOS. On Windows GPC has no particular place to write to, so I have more trouble there. But I place the debugger as a low-priority item.

Of course, I've also done much writeln-debugging with GPC (for lack of alternatives) and sometimes recently also in C++ (out of habit ;-), but honestly, having a real debugger (gdb with C++) available is quite helpful sometimes, especially to find more complex bugs. For me, it's at least medium priority.

Thus, I see no need for Pascal to provide more than its existing rudimentary interface with the local operating system (although the Windows version should be brought up to the level of the others).

I also have the need for an extended OS interface (though obviously not Windows, but Unix), but again, that's not my main concern. If that was all, I'd probably write it within a few days and be done.

If the GPC compiler were written in GPC, I could work on fixing bugs. I would be happy to write or maintain the code that implements the mathematical run-time library (sin, cos, etc.). I understand that the self-compiling compiler requires a complete re-write.

Actually, GPC's runtime library is already written in Pascal for the most part (i.e., except for the direct libc interface), so that's just the area that would require the least amount of work.

Felipe Monteiro de Carvalho wrote:

One suggestion: Why not implement a syntax mode in Free Pascal which is compatible with the current GPC syntax?

That would merge both projects and avoid such trouble.

If there is no volunteer to do this work, but someone interrested in it's conclusion has some money (at least 200 eur for the doing the gross initial work, more later for the fine tuning), I could try to find an implementor for it in the context of the Lazarus Season of Code: http://wiki.freepascal.org/Lazarus_Season_of_Code

I'm skeptical given what I heard from FPC advocates WRT standard Pascal etc. before. Not wanting to rehash old and less than pleasant discussions, all I'll say WRT my participation in any project with FPC is: Not interested.

Of course, if you'd like to do this, go ahead -- and good luck!

John L. Ries wrote:

I find it interesting that when I was a young CS major back in the 1980s, I somewhat resented Pascal's status as the "official religion" in my university's CS department, but as a professional programmer, my appreciation for the way it encourages good programming practices has increased by leaps and bounds. At the same time, my attitude toward C has gone from infatuation to active dislike.

Again, I'd prefer to leave out C (which I'd suggest to noone as an alternative for Pascal), and talk about C++ instead which is indeed quite a bit more high-level (though it carries all the ballast from C, but unfortunately so does GPC, often disguised as BP extensions).

Of course, I have gathered most of my programming experience in Pascal and applied it in C++ later, and I don't know how my habits would have developed if I had started in C++.

That said, I agree in principle with the proposal to rewrite GPC in Pascal, though if it can be made easy to keep the existing GPC in sync with the GCC back end, it would free up time for the core developers to work on the rewrite.

Unfortunately, that's just the main problem here. As I wrote, I figure it would take several weeks just to "fix" gpc with gcc-4.1, after Waldek spent months porting it to gcc-4 in the first place. Then additional effort is required to port it to the current gcc, test and fix it, and by then probably new gcc versions will have appeared, possibly with major changes.

And I'm talking about full-time development here. I may have a few weeks available now, but then I'll have to concentrate more on other projects again and only have occasional time for Pascal. The same goes for Waldek. And for new developers, even if there were some, it would take some time to get used to the backend to become able to do any productive work.

So, sorry, I just don't see a way to get, let alone keep, GPC in sync with the backend. I had hoped so when I started, but since then the distance has probably even increased, despite the extensive efforts of Peter, Waldek and me.

I'm not sure how much language extension is required,

"Required" is, of course, subjective here. I tried to explain why something like templates are important to me (and adding templates in the langauge is very much non-trivial), or in other words a way to write a structure (such as a list, hash table or tree) that can be applied to *any* type.

but Pascal greatly suffers from a lack of bindings to widely used libraries, including and especially GUI toolkits. I know there is a tool to facilitate creation of Pascal bindings to C/C++ libraries, but it's not (as far as I can see) distributed with GPC, or mentioned on the GPC website. I don't really understand why the existing GPC couldn't be used to boostrap a new compiler written entirely in Pascal, but perhaps Frank could elaborate on why his suggested C++ converter is preferable as an interim step.

Perhaps I was unclear, but I didn't mean it as an interim step, but as the actual target for the alternative development (i.e., getting away from the backend). An advantage WRT your point would be that the generated C++ code could include the C/C++ headers directly, so interfacing would become easier (though not completely trivial, as I explained in my article).

Scott Moore wrote:

Although a rewrite of GPC in Pascal is interesting, I don't think it would help. It is a huge undertaking, and it still would not result in an all-Pascal project, since it must integrate with the GCC backend.

See my previous paragraph. My point of the rewrite would be that it would *not* integrate with the gcc backend, but output C++ code (which would then probably be compiled with g++ using the gcc backend, but we're not involved with that then).

Prof Abimbola Olowofoyeku (The African Chief) wrote:

My one concern would be about producing yet another Pascal object model that is not compatible with any of the existing ones. But I guess that, if the old BP model is still supported so that existing code would compile, that would be fine.

That's kind of what I half expected and half feared. If I'm the only one to want a new (or at least extended) object model (in particular WRT enforced constructors and automatic destructors) or other features (such as templates), there's no point implementing them.

Adriaan van Os wrote:

The devil is in the details. For me, a compiler is a professional tool and the quality of the tool is more important than new features. A handful of weak points may become serious deployment obstacles.

Current GPC problems:

1. wrong line numbers in debug code
2. wrong and/or incomplete debug-symbol info, notably for 64-bit code
3. order-2 performance of unit symbol loading
4. order-2 performance of operator overloading symbols

http://www2.gnu-pascal.de/crystal/gpc/en/mail12897.html 5. stalled GCC back-end development/integration (a show stopper when the target OS requires a recent GCC)

I am not complaining or opposing new features. I am saying that a future path for GPC must tackle these and similar problems. Questions must be answered. Does (5) imply moving away from the low-level GCC back-end ? What are the alternatives ?

As I wrote, the only way I could see WRT (5) as far as I'm concerned would be moving away from the backend, and my alternative would be to output C++. This could also help solving (1) (when being careful about emitting line breaks and/or inserting "#line" directives), and partly (2) (the debug info should at least be useable, but as I noted, in particular types would, at least initially, be in C++ notation).

For (3) and (4) it wouldn't help, but if the new compiler was written in a high-level language (i.e., C++ or its own new Pascal dialect) using high-level data structures (e.g., template based), it would make it easier to tackle those problems.

1. producing C/C++/Objective-C. What about the debugging experience ? What about GDB maintenance ?

Debugging plain C++ works well with gdb, even multi-threaded programs. I think at least for the mainstream languages (C and C++) gdb is currently well maintained.

Debugging Pascal translated to C++ would, of course, be inferior, see above, but still it would be a huge step forward from the current state of affairs.

2. producing LLVM assembly http://llvm.org/docs/LangRef.html

That might be an option. However, the problems I see are (a) I'm not familiar with LLVM assembly (in contrast to C++), and I'm not sure anyone else here is, so it would take additional learning before one could get productive, and (b) it's, of course, low-level, so we'd have to reimplement things like the object-model, templates, exceptions etc., that C++ already has.

3. LLVM integration http://llvm.org/docs/tutorial/ (also a moving target with a moving C++ API)

As you can imagine, I've become skeptical of moving targets.

Frank

Kevan Hashemi wrote:

In order to create a GPC that compiles itself, we need run-time libraries that provide OS routines. I assume that every OS provides such libraries independent of GCC's existence or version in the system.

Again, we have the libraries (i.e., the basic runtime library, not including stuff like graphics, see my mail about GRX, but file handling etc., including everything that a compiler needs -- which is actually not much, as far as the envinronment in concerned). On every platform where GPC runs, almost by definition, its runtime library runs.

Given that GPC's Pascal is, in your own words, Turing Complete, I assume it is possible to write in the current version of GPC the code to implement any future version of GPC, regardless of the new features.

Yes, it's possible, but it's IMHO not conformtable. I know I'm repeating myself, but I'm really fed up with having to "reimplement the list", as I wrote. It's also a psychological thing IMHO -- if advanced data structures (objects, trees, hash tables) are readily available (as in C++), you tend you use them when useful; if they're not (as in Pascal, except for objects), you're much more likely to do quick ad-hoc work-arounds, which affect the efficiency, but also the design of your program, especially in the long run. GCC's TREE_NODEs are a particularly bad example of this, spreading all over the code, but also in my Pascal programs, I often find a lot of ad-hoc list (or other structures) handling code that obscures the actual purpose of my code and thus make it harder to understand later.

Thus, re-writing GPC in Pascal seems to me to be a Pascal programming job. If there are enough development hours available, it is an elegant and long-lasting solution to GPC's problems.

Unfortunately I think that's a big "if". Your offer is appreciated, but AFAICS, even in the optimistic case (no distractions will reduce the available time in the foreseeable future), we're still way short of the necessary "manpower" to create a new compiler.

I can program in Pascal. I could write a lexer, a parser, or any other part of the program.

One note: For any project that I'd be involved in, I'd insist that the parser is created by a tool, not hand-made. It doesn't necessarily have to be Bison, but it seems a good choice since we already have the GPC language grammar in Bison form -- as I wrote, the actions would have to be rewritten, but that's the easy stuff; the hard part, the grammar, could be kept essentially unchanged, including, e.g., the handling of near-ambiguities that arose from the combination of several dialects (or sometimes from single-dialects alone -- Borland, I'm looking in your direction) and other issues.

Why do I think so? Mainly because I'm convinced that designing languages (and a new GPC would add new features, including new syntax) using hand-made parsers usually leads to bad syntax, i.e., ambiguous, nearly ambiguous or otherwise problematic.

A typical example for me is BP (or then, TP) that was written, for all we know, with a parser hand-written in assembler. They designed some problematic syntax, worst of all "^C" style character constants. A parser generator would have told them right away that they cause serious problems (and thus were a bad idea). Writing a parser by hand doesn't tell you so, so they happily added them, probably not even noting that their own new feature didn't work in many cases because they had not thought of them.

Certainly, this was an easy case, and an experienced language designer might have seen it coming without any tools, but in a language as complex as GPC (again, mainly due to the combination of dialects), conflicts are often surprising and in unexpected places, yet a parser generator like Bison detects them.

The lexer (generated by Flex) is a smaller issue, but I see no reason to switch from it either.

I will be happy to help out. If I'm starting with C code that needs to be translated into Pascal, then I will probably be able to get translations done with the minimum of help from you.

It would be more rewriting than translating, i.e. understand what the C code does (with the backend), and implement the same in Pascal (with a, say, C++ output). The big difficulty is to match the behaviour exactly (so the new GPC would be compatible with the exiting one), yet with a completely different target, with largely different internal structures (i.e., high-level structures instead of TREE_NODEs), and in a different language. That (combined with the size of the compiler) is not an easy task by any measure, obviously.

Frank

On Fri, 30 Jul 2010 05:48:29 pm Frank Heckenbach wrote:

A typical example for me is BP (or then, TP) that was written, for all we know, with a parser hand-written in assembler. They designed some problematic syntax, worst of all "^C" style character constants. A parser generator would have told them right away that they cause serious problems (and thus were a bad idea). Writing a parser by hand doesn't tell you so, so they happily added them, probably not even noting that their own new feature didn't work in many cases because they had not thought of them.

I'm sorry, I don't understand what you mean by "^C" style constants, or why they are a bad idea. Can you explain please?

On Wed, 2010-07-28 at 22:52 +0200, Frank Heckenbach wrote: [...]

...

My one concern would be about producing yet another Pascal object model that is not compatible with any of the existing ones. But I guess that, if the old BP model is still supported so that existing code would compile, that would be fine.

That's kind of what I half expected and half feared. If I'm the only one to want a new (or at least extended) object model (in particular WRT enforced constructors and automatic destructors) or other features (such as templates), there's no point implementing them.

An extended object model is fine, and Templates sound like a very good idea. My main concern was about existing code. If existing code would still compile, then that concern goes away. Enforced constructors are not a problem (that is already required in the Delphi Class model - your program will crash if you don't call a constructor to instantiate your object). I don't know how automatic destructors work, but I don't have a problem with the idea (in Delphi you would have to call object.free - a method, that calls the appropriate destructor). IMHO, any thing that makes the programmer's work less error-prone is good. But it makes sense (if at all possible without a disproportionate amount of effort) to develop/extend the object model in a way that is compatible (as far as possible) with an existing model (perhaps as a superset of one or more).

I don't know what you have in mind WRT the object model, and I don't know whether "automatic" con-/destructors refers to implicit or explicit con-/destructors. And, would there be a common ancestor (type or template) for all objects? And what would be the difference with the BP model?

Example: { BP model } type foo = object end; {foo has no con-/destructor, which are totally unnecessary; and it has no inherent behaviour or attribute }

{ extended model } type foo = extended_object end; {does foo have any con-/destructor, and/or any inherent behaviours or attitudes? what if I want to add my own con-/destructors?}

This is just a matter of curiosity for me, and the actual answer is neither here nor there. I think many programmers tend to look at new compiler features with great interest (as long as they don't break existing code) and I am sure that this will happen with a revamped GPC. It may even be that other Pascal compilers would copy the new features (e.g., Templates).

The bottom line: although a self-compiling GPC would be wonderful if possible without undue effort, it doesn't really matter what language the revamped GPC is written in (although I personally could only hope to contribute Pascal code). C++ is as good as any other language, and I see no philosophical reason against it.

I know very little about C++ standards, so what follows may simply be the result of my ignorance. The question is - how confident are you that the compiler's translation from Pascal to C++ would always compile? What C++ standard would it generate code for? Is there a lowest common denominator "standard" that would compile on any C++ compiler? How would GPC verify that there is a compliant C++ compiler? Would the GPC compiler itself compile with every standards-compliant C++ compiler? (for example, would I be able to build it on Windows with MSVC, and g++, and Borland/Turbo C++? - which would be wonderful).

Conclusion: for my part, as long as one can still run: "gpc foo.pas [blah blah]" and end up with a compiled program "foo[.exe]", then all is well.

If you can provide a list (and specifications) of Pascal tasks that need doing (and required coding principles and conventions) to get the revamped compiler going, then I am sure that there will be many volunteers (present company included).

This discussion is in danger of drifting off topic (the future of GPC development) to religious wars (OSes). So can we please bring it back to the topic?

The most crucial point for me is portability and cross-platform development. Right now, I can write a program, and compile it for Windows, Linux, and my embedded system (accessed via smbfs). If I need to, I can compile the same program for Solaris Sparc and Dos as well (and have done so in the past). This is the reason for my earlier question about which C++ standard the code generated by the renewed GPC would target. It is also the reason why I am in full support of Frank's suggestion of C++, as in preference to any other language as far as the generated code is concerned. I know that almost every decent OS under the planet has a decent C++ compiler (probably g++), and I don't believe that this is likely to change anytime soon. So that seals it for me.

Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

On Fri, 30 Jul 2010, Kevan Hashemi wrote:

Deasr Chief,

...

So that seals it for me.

I agree that a Pascal to C++ translater would be just fine. But on the other hand, that means that we need people who enjoy programming in both Pascal and C++ to support the project. Anyone who fits that description is not going to have much use for the product, because they might as well program in C++ in the first place.

The people who are dedicated to GPC are people who greatly prefer to program in Pascal. Most such people dislike programming in C++. So who is going to write this translator? Not me. Is Frank going to write it on his own?

It may be ten times as much work to re-write the compiler in Pascal, but we may find that we have a hundred times as much developer time available.

One way to proceed is for Frank to estimate how many developer hours are required for a Pascal compiler in Pascal, and for a Pascal to C++ translator, then we poll the list to see how many hours people are prepared to dedicate to each project. If only one of them gets enough hours, then we have only one practical solution.

The more I think about it, the clearer it is to me that the Pascal to C++ translator is the option discussed that I like the least. I actually would prefer a Pascal to Ada translator more than Pascal to C++, because if I had to abandon Pascal, I think I'd be much more comfortable programming in Ada than in C/C++ (I don't know enough about D to have an opinion). All things being equal (which they never are), a rewrite of GPC in Pascal is the option I like the best, followed by an effort to add full Extended Pascal/GPC language support to FPC (which has the advantage of already being written in Pascal).

Since I don't have any experience in compiler development, I don't know how useful I could be (except for maybe as a tester), but I think I could devote a couple of hours per Saturday to assist in a rewrite of GPC in Pascal, or on an FPC merger.

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

On 29 Jul 2010, at 09:47, Adriaan van Os wrote:

If each unit compiles into a separate C++ header file, C++ compilation times will suffer, even if the headers are precompiled. One way I can think of to get around that is a whole-program Pascal compilation mode that translates into one whole-program C++ file that copies only those unit-declarations that are actually used in the program.

Note that this generally causes even larger compilation times compared to separate files (unless you enable the compiler's whole program optimization infrastructure, in which case using separate files will be a bit slower), because all "regular" optimizations (-Ox) are limited to the current compilation unit.

If you put everything in a single compilation unit, then the compiler can optimize more, but if the goal is speeding up compilation then it will probably be counterproductive (possibly unless you only care about compilation speed for -O0 and not at all when using -O1 or higher).

Jonas

On 29 Jul 2010, at 11:05, Adriaan van Os wrote:

Jonas Maebe wrote:

...

If you put everything in a single compilation unit, then the compiler can optimize more, but if the goal is speeding up compilation then it will probably be counterproductive (possibly unless you only care about compilation speed for -O0 and not at all when using -O1 or higher).

It depends where the compiler is spending its time, generating code or processing declarations, reading unit symbols, etcetera. For GPC on Mac OS X, the bottleneck is absolutely the latter.

I don't think the current GPC unit loading architecture is comparable to how a C++ backend would work. And as I said, it is very much depends on the size of the compilation unit: larger compilation units generally take more or less linearly more time to parse, but the optimization time generally rises much more steeply (especially with newer compilers that perform more inter-procedural analyses).

At least that's my experience with compiling Apple's ld64, whose code is virtually all contained in large .hpp files that in turn are included in the main .cpp file. It's only about 680KB of code (mild usage of templates, but no complex template programming), but it takes a disproportionately long time to compile.

Jonas

Jonas Maebe wrote:

On 29 Jul 2010, at 11:05, Adriaan van Os wrote:

...

Jonas Maebe wrote:

...

If you put everything in a single compilation unit, then the compiler can optimize more, but if the goal is speeding up compilation then it will probably be counterproductive (possibly unless you only care about compilation speed for -O0 and not at all when using -O1 or higher).

It depends where the compiler is spending its time, generating code or processing declarations, reading unit symbols, etcetera. For GPC on Mac OS X, the bottleneck is absolutely the latter.

I don't think the current GPC unit loading architecture is comparable to how a C++ backend would work. And as I said, it is very much depends on the size of the compilation unit: larger compilation units generally take more or less linearly more time to parse, but the optimization time generally rises much more steeply (especially with newer compilers that perform more inter-procedural analyses).

I think so. Also, putting everything in one source file means that everything has to be recompiled with every change anywhere.

What's taking so long currently, Adriaan, is probably the GPI imports. That's independent of the target, i.e. a Pascal to C++ converter would have to do it just the same, so its complexity is independent of how the output is structured. As I said, this is a separate issue which would be easier to tackle if the compiler was written in a high-level language (such as C++ or Pascal with templates). It's easier to find and experiment with efficient data structures (e.g., hash tables, trees) when they're readily available than when you have to manually implement them each and every time like in C (for the current GPC) and also in Pascal so far.

BTW, is it the actual Mac OS X interfaces that are so huge, or your wrappers? I remember you had a long list of string functions for string types of various kinds and lengths. Using templates, they'd shrink drastically.

Frank

Adriaan van Os wrote:

Frank Heckenbach wrote:

...

Jonas Maebe wrote:

...

What's taking so long currently, Adriaan, is probably the GPI imports. That's independent of the target, i.e. a Pascal to C++ converter would have to do it just the same, so its complexity is independent of how the output is structured. As I said, this is a separate issue which would be easier to tackle if the compiler was written in a high-level language (such as C++ or Pascal with templates). It's easier to find and experiment with efficient data structures (e.g., hash tables, trees) when they're readily available than when you have to manually implement them each and every time like in C (for the current GPC) and also in Pascal so far.

I agree that it is a separate issue and that it is easier to tackle in a future compiler. So, I am moving this to a new thread. We need not discuss it any further now, but I am still following up to answer your questions.

The problem is not so much the speed of GPI loading as such, but the fact that unit-recompilation is of order-2 (in GPC) instead of order-1 (as in FPC).

Imagine a program P that uses unit1 .. unitN, where each unit K uses unit1..unitK-1. Currently, a compile of program P with GPC

• triggers a compilation of unit1 and writes a unit1.gpi
• triggers a compilation of unit2, which uses unit1, so loads unit1.gpi and writes unit2.gpi
• triggers a compilation of unit3, which uses unit1 and unit2, so loads unit1.gpi and unit2.gpi and

writes unit3.gpi

• etcetera
• triggers a compilation of unitK, which uses unit1..unitK-1, so loads unit1.gpi..unitK-1.gpi and

writes unitK.gpi

• etcetera

So, unit1 is written once and loaded N-1 times, unit2 is written once and loaded N-2 times, etcetera, unitK is written once and loaded N-K times, etcetare. Therefore, N .gpi files are written and (N-1) + (N-2) + ... (N-N) = N * (N-1)/2 .gpi file are loaded.

Ah, I see. I thought the issue was that a unit import/export with N declarations took O(N^2) time. I think we fixed that (or at least in some cases).

In other words, compilation times increase quadratic with the number of used units. Improving .gpi load times doesn't help much (only by the square root of the load-time improvement) and the process will still be slow when N is large. The only real solution is to make compilation a linear process, where already-loaded .gpi files are not loaded again. My understanding is that this is difficult to accomplish with the current GPC back-end.

It's not about the backend, but the driver/compiler structure (gp (or "gpc --automake") calls gpc, and gpc calls gpc1), and it's not difficult, but impossible in the current structure, because each unit is compiled by a separate process which has to load all used interfaces.

The same problem exists with C/C++ header files and the common solution there is to use include guards http://en.wikipedia.org/wiki/Include_guard.

No, that's not the same problem. The problem there is that the compilation of a single source file would be O(N^2) if it includes N headers, and each header in turn includes the previous ones. (And it would lead to duplicate declarations.)

This problem would *also* occur in Pascal (so the whole compilation would be O(N^3)), if GPC (like probably all other Pascal compilers) didn't prevent it by keeping a list of imported interfaces and avoid duplicate imports.

...

BTW, is it the actual Mac OS X interfaces that are so huge, or your

It is the actual Mac OS X interfaces that are so huge,

So if I understand you correctly now, the OS interfaces span so many units. Now I understand why you suggested to output them all to a single C++ file (since they probably change rarely, only with upgrades, and then all at once).

Can't you just put them all in a single unit, or would it become so large that you couldn't compile it (for memory reasons or so)?

Another idea (which, if possible, works now, and might also be necessary for a future GPC, if any), is to reduce the number of dependencies (maybe requiring some restructuring). I find it hard to believe that really every unit requires all previous ones. Can't they be grouped in "topics" that are mostly independent of each other (so the "uses" graph would look more like a tree than a linear chain; e.g. a roughly binary tree would be O(N log N) which should be acceptable).

Frank

Hi,

On 7/29/10, Adriaan van Os gpc@microbizz.nl wrote:

It depends where the compiler is spending its time, generating code or processing declarations, reading unit symbols, etcetera. For GPC on Mac OS X, the bottleneck is absolutely the latter.

(Caveat: limited testing) For DJGPP + GPC, the linker seems to be the weakest link. I've heard similar horror stories from Marcov from FPC, and I know they're glad to have their own (Win32-only, for now). Of course, that could just be the COFF backend, ELF may fare better (presumably since all devs use Linux these days). GNU BinUtil's "new and improved" Gold linker (from Ian Lance Taylor from Google) is, last I checked, still only for Linux/ELF/x86 (but written in C++, go figure).

Adriaan van Os wrote:

Frank Heckenbach wrote:

...

...

2. producing LLVM assembly http://llvm.org/docs/LangRef.html

That might be an option. However, the problems I see are (a) I'm not familiar with LLVM assembly (in contrast to C++), and I'm not sure anyone else here is, so it would take additional learning before one could get productive, and (b) it's, of course, low-level, so we'd have to reimplement things like the object-model, templates, exceptions etc., that C++ already has.

LLVM assembly is easy to learn (easier than C++). With regard to implementing object models, GPC has several object-modes and most of them are, as far I know, not compatible with C++. We don't want to implement for example the TP object model with C++ objects, do we ?

I would want to (if we go the converter to C++ route). GPC objects are not (and have never been) binary compatible with BP, and feature-wise, AFAICS, the C++ model is a strict superset of the BP model (and all other relevant models), with the probably necessary mapping of BP con-/destructors to plain methods, as I wrote.

I find LLVM assembly quite attractive, generic and well designed, distant from a moving API. I see a great future for LLVM. GCC looks more like an unstructured pile of macros. If a software project has a large bug database and successive releases only fix "serious regressions for primary targets", then something with that software project is fundamentally wrong (especially if the developers are hostile and aggressive on the subject on their mailing list).

I won't defend the GCC development model (I've been annoyed myself often enough), but I have to say that GCC is quite more than a pile of macros. The interface could be described as such (to a large extent), but internally there's quite a bit more going on, e.g. the various optimizers.

Frank

I have to agree with this. At our research institute all three OSes (Mac, Linux, Windows) are represented with Mac laptops scoring the highest among students. Because of the mix, platform independence is important to us and when "in house" programs are written we strictly separate "do things" from "present things on screen". So, free multiplatform languages like GPC, FPC and of course GNU C(++) and Fortran are way more in use than for instance Delphi, which is tied to Windows.

Cheers, Gorazd

Cheers, Gorazd

----- Original Message ----

From: Kevan Hashemi hashemi@brandeis.edu To: Prof. Harley Flanders harley@umich.edu Cc: Frank Heckenbach ih8mj@fjf.gnu.de; gpc@gnu.de Sent: Fri, July 30, 2010 1:19:33 PM Subject: Re: Quo vadis, GPC?

Dear Harley,

...

The Windows family counts for almost 90%:

Not in academia, it doesn't. Here at Brandeis University, there are more students with Apple lap-tops than Windows lap-tops. There are more and more students using Linux in preference to Windows. Yesterday I wiped another Windows drive and my student installed Ubunto. We're sick of Windows.

Only when you get into the vast realm of coporate America do you come across 90% Windows, and those people don't use the kind of software we're writing. They are still using XP because they are stuck with it from all their custom-made software packages from ten years ago.

I suspect that your 90% statistic does not apply to the GPC programmer's customers. In the long run, it could be that Windows, being a costly operating sytem, is going to die. Indeed, it is my belief that it will. Everywhere in the Physics community, Linux and MacOS are taking over.

Yours, Kevan

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

On Fri, 30 Jul 2010, Hodges, Robert CTR USAF AFMC 520 SMXS/MXDEC wrote:

...

...

The Windows family counts for almost 90%:

...

Not in academia, it doesn't.

Right - that's the missing 10%, mostly made up of acedamia and the entertainment industry.

Walk outside into the real world (which you eventually will, like it or not), however, and UNIX/MacOS/Linux systems virtually disappear.

40 years of UNIX, 20 years of Linux, and 10 years of MacOSX have failed to produce a combined market share greater than 9%, which has been flatlined for over a decade.

Only 1 out of 10 people want/need to use it.

But that doesn't mean that those 9% of computer users shouldn't be accomodated, particularly by their fellows. I would also argue that deliberately reinforcing that 90% market share (used to be higher) is not in the interest of anybody but Microsoft and its "partners". I have no interest in turning this discussion into an debate over MS, but the computer industry suffers not from too much competition, but too little.

Understand that while the vast majority of computer users use Windows, many others prefer other systems and are willing to sacrifice a considerable amount of convenience to do so. This is a feature, not a bug.

--------------------------| 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 Kevan Hashemi Sent: Friday, July 30, 2010 11:20 AM To: Prof. Harley Flanders Cc: Frank Heckenbach; gpc@gnu.de Subject: Re: Quo vadis, GPC?

Dear Harley,

...

The Windows family counts for almost 90%:

Not in academia, it doesn't. Here at Brandeis University, there are more

students with Apple lap-tops than Windows lap-tops. There are more and more students using Linux in preference to Windows. Yesterday I wiped another Windows drive and my student installed Ubunto. We're sick of Windows.

Only when you get into the vast realm of coporate America do you come across 90% Windows, and those people don't use the kind of software we're writing. They are still using XP because they are stuck with it from all their custom-made software packages from ten years ago.

I suspect that your 90% statistic does not apply to the GPC programmer's

customers. In the long run, it could be that Windows, being a costly operating sytem, is going to die. Indeed, it is my belief that it will. Everywhere in the Physics community, Linux and MacOS are taking over.

Yours, Kevan

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

Well spoken.

-----Original Message----- From: gpc-owner@gnu.de [mailto:gpc-owner@gnu.de] On Behalf Of John L. Ries Sent: Friday, July 30, 2010 11:34 AM To: gpc@gnu.de Subject: Re: Quo vadis, GPC?

On Fri, 30 Jul 2010, Prof. Harley Flanders wrote:

OS PLATFORM STATISTICS

Windows XP is the most popular operating system. The Windows family counts for almost 90%:

You would think from the amount of ink flowing here about Linux that it must be 10 times as popular as it actually is.  Note that Windows consistently scores about 88-89%.

That would be the nature of this list. GNU Pascal is part of the GNU project, which has always been UNIX oriented. One would also expect to find in any GNU related project a large number of people who are philosophically committed to free software, which will tend to bias people in favor of Linux, which is the single most important free (FSF definition) operating system. Also, the GNU project has done a very good job, over the years, of writing highly portable software, which is of benefit to all computer users, regardless of the platform (architecture+OS) on which they work (even, IMHO, Windows). GPC has done a very good job of maintaining platform independence, which is a very good thing that I hope will continue. I particularly appreciate this aspect, of GPC, as I routinely develop for multiple platforms and have for nearly all of my professional career.

I should note that while I don't agree with RMS and his followers that free software is a moral imperative, I greatly respect those who believe that strongly enough to act on it by developing high quality software available to anyone who wants to use it, even though they know they'll never get rich doing it. At the very least, they should be thanked for opening up a software market that had become largely noncompetitive.

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

Prof. Harley Flanders wrote:

As to O/S, the following statistics should interest everyone:

OS Platform Statistics

Windows XP is the most popular operating system. The Windows family counts for almost 90%:

2010 Win7 Vista Win2003 WinXP W2000 Linux Mac June 19.8% 11.7% 1.3% 54.6% 0.4% 4.8% 6.8% May 18.9% 12.4% 1.3% 55.3% 0.4% 4.5% 6.7% April 16.7% 13.2% 1.3% 56.1% 0.5% 4.5% 7.1% March 14.7% 13.7% 1.4% 57.8% 0.5% 4.5% 6.9% February 13.0% 14.4% 1.4% 58.4% 0.6% 4.6% 7.1% January 11.3% 15.4% 1.4% 59.4% 0.6% 4.6% 6.8%

Source: http://www.w3schools.com/browsers/browsers_os.asp

Except that browsers are not exactly the same thing as programming languages.

You would think from the amount of ink flowing here about Linux that it must be 10 times as popular as it actually is. Note that Windows consistently scores about 88-89%.

I hope you don't mean this as a complaint. If there are so many Windows programmers lurking, they're certainly allowed to speak up.

For what I know, of the 5 main developers GPC has had, the percentage of Windows users (as their main OS) is exactly 0%. So if your statistic was relevant, there should be dozens of Windows programmers just waiting to take over as main developers and GPC's future was secured for decades. Or maybe a lot of those 90% are just computer "consumers" who wouldn't notice if the OS, hardware and applications on their computer were exchanged completely, as long as their icons look the same -- and you wonder why they're not here to discuss the future of a Pascal compiler?

John L. Ries wrote:

Also, the GNU project has done a very good job, over the years, of writing highly portable software, which is of benefit to all computer users, regardless of the platform (architecture+OS) on which they work (even, IMHO, Windows). GPC has done a very good job of maintaining platform independence, which is a very good thing that I hope will continue. I particularly appreciate this aspect, of GPC, as I routinely develop for multiple platforms and have for nearly all of my professional career.

I'd add that it's not only (or even mainly) the GNU project, but standards such as POSIX that foster portability. Linux supports POSIX (plus extensions), Windows also (grudgingly) supports POSIX (minus some flaws), so a port from Linux to Windows is not always trivial, but possible with some effort.

OTOH, native Windows programs use a completely different API, and a port from Windows to Linux is a much larger task, basically rewriting anything related to the OS (not only GUIs, also file I/O uses a completely different API). Most Windows programmers don't care about this, or at best only as an afterthought.

Prof. Harley Flanders wrote:

Delphi however does support Linux.

Does it? AFAIK, there was a short-lived attempt named Kylix which has long been abandoned.

Like it or not, Delphi is the best Pascal system going out there, pricey indeed; well worth it in my opinion.

Fortunately, opinions can differ. In my opinion, software that is non-free and non-portable is never "the best".

It's IDE is remarkably good, its compiler is blindingly fast. Do you know that Delphi is checking your source code as fast as you write it, and instantly flags syntax errors?

If you like Delphi, good for you, then you should have no problems switching if GPC dies.

Side note: On-the-fly syntax checking and similar features are things that I do consider useful and would like to implement in my IDE (PENG). Of course, I need time to do it, time which I've so far spent more on GPC ...

Delphi [...] has expanded the Exit command from function bodies to have a parameter: the function result.

BTW, GPC supports that as "return".

For the sake of clarity in this discussion, could someone please make a glossary of the many acronyms therein. I do not recognize half of them.

http://lmgtfy.com

Otherwise, it might help if you told us which acronyms in particular you'd like expanded.

Hodges, Robert CTR USAF AFMC 520 SMXS/MXDEC wrote:

...

...

The Windows family counts for almost 90%:

...

Not in academia, it doesn't.

Right - that's the missing 10%, mostly made up of acedamia and the entertainment industry.

Walk outside into the real world (which you eventually will, like it or not), however, and UNIX/MacOS/Linux systems virtually disappear.

Strange, since I'm neither in academia or the entertainment industry, along with Peter and other people I work with, we must be virtually nonexistent. I wonder who supported and extended GPC between 1996 (Jukka, Jan-Jaap) and 2002 (Waldek).

Only 1 out of 10 people want/need to use it.

Or market lock-in is at work ...

John L. Ries wrote:

Understand that while the vast majority of computer users use Windows, many others prefer other systems and are willing to sacrifice a considerable amount of convenience to do so. This is a feature, not a bug.

*Sacrifice* convenience? The times I've had to sacrifice convenience were when I was "forced" to use a Windows system (fortunately not often). Even genuine GUI features like copy & paste (which are supposedly Windows' strength, I don't even have to talk about traditional Unix strengths such as file systems and networks) work so much better/easier in Linux GUIs like KDE than under Windows. I'm sure many of those "90%" would agree if they ever made an unbiased comparison (but of course, MS tries to make sure this never happens).

Prof A Olowofoyeku (The African Chief) wrote:

This discussion is in danger of drifting off topic (the future of GPC development) to religious wars (OSes). So can we please bring it back to the topic?

Probably not, but I changed the subject line. ;-)

The most crucial point for me is portability and cross-platform development. Right now, I can write a program, and compile it for Windows, Linux, and my embedded system (accessed via smbfs). If I need to, I can compile the same program for Solaris Sparc and Dos as well (and have done so in the past).

I did the same with Linux, Solaris, Dos and occasionally Windows.

This is the reason for my earlier question about which C++ standard the code generated by the renewed GPC would target.

In this case, the question is not so pressing, since g++ is at least as portable as gpc (using the same backend and better supported), and any C++ converter output should, of course, at least be compilable with g++.

John L. Ries wrote:

I should note that while I don't agree with RMS and his followers that free software is a moral imperative, I greatly respect those who believe that strongly enough to act on it by developing high quality software available to anyone who wants to use it, even though they know they'll never get rich doing it. At the very least, they should be thanked for opening up a software market that had become largely noncompetitive.

This statement was explictly acked by two other persons (it almost seems it's the only thing at all in this thread that more than two people have agreed on so far). If the general opinion here is that the project is a take-away or free software is some kind of charity, it also doesn't bode well for future projects.

This applies especially to Windows users. So far, the only major GPC contributor who is a Windows user has been The Chief who builds Windows binaries and, together with me, implemented special Windows support in some runtime units and the RTS. That's right -- I actually helped him support Windows-only features. On the opposite, I've yet to see a Windows user (who is not also a Linux user) supporting Linux-only features. And then I have to read (see above) how Windows is underrepresented and not talked about enough.

So for those who think free software means they just get it without paying (free beer, not free speech) and yet get to tell us what we should do and complain when we do what we consider important, not what they consider important (instead of doing it themselves), that won't work. Sure, one of the points of free software is that anyone can use it for any purpose, but there's also a rule: Those who code make the decisions. And by this measure, if I look through the mailing list archives, Dos and Windows have actually been vastly overrepresented.

One reason why successful free software projects thrive is contributions by users. This is true for big projects such as GNU and Linux (of the current source code in the GNU project and in Linux, RMS and Linus, respectively, have written only a small part) or TeX (though TeX itself is mostly Knuth's original code, what made it most useful was LaTeX and many 3rd party packages), but also for smaller projects, in particular also FPC.

With GPC this hasn't happened much. Even if working on the GPC compiler itself was difficult due to its backend dependency, this was no reason to prevent contributions to Pascal units, both the units that come with GPC, including most of its runtime system, and 3rd party units or applications (e.g. IDEs). But this happened only to a small degree. I can only speculate on why, whether it's mentality (as expressed in statements such as the above), or that everyone is just too busy working on their in-house applications, or even the large array of dialects that GPC supports (which are normally thought of as an asset, but may have become a problem in that they stifle cooperation between users if everybody uses their own set of features).

Frank

On Sat, 31 Jul 2010 06:22:00 pm Florian Klämpfl wrote:

I think you miss one important point here: to contribute to an OSS project one must be rather idealistic or even religious about it (yes, this includes me ;)).

"Must"?

That's probably why Microsoft agreed to match Jeff Atwood's donation of $5000 to support OSS Dot-Net development. Microsoft is famous for being idealistic and religious about open source.

http://www.codinghorror.com/blog/2007/06/supporting-open-source-projects-in-...

Not to mention idealistic and religious companies like Fujitsu, HP, Skype, to mention just a few...

http://www.postgresql.org/about/sponsors

On Sun, 1 Aug 2010 03:33:15 am Florian Klämpfl wrote:

Am 31.07.2010 19:16, schrieb Steven D'Aprano:

...

On Sat, 31 Jul 2010 06:22:00 pm Florian Klämpfl wrote:

...

I think you miss one important point here: to contribute to an OSS project one must be rather idealistic or even religious about it (yes, this includes me ;)).

"Must"?

"One" in the sense of person obviously and contribute in the sense of coding or why should one code for free?

Who says "one" is coding for free?

Companies like Google, Apple, Red Hat and many others, pay programmers to work on OSS, not because of a sense of idealism but because it suits their business model.

...

That's probably why Microsoft agreed to match Jeff Atwood's donation of $5000 to support OSS Dot-Net development. Microsoft is famous for being idealistic and religious about open source.

And? $10000 is nothing. This approximately is what a senior software developer/architect with PhD./Master/Dipl.-Inf./Dpl.-Ing. costs a company per month.

Yes, and? The point which seems to have escaped you is that *Microsoft*, a company that a few years ago described Linux and OSS as "cancer", has now realised the business worth of it to *themselves*. It might only be a tiny contribution so far, but Microsoft aren't doing it for idealistic or religious reasons. They didn't become the worlds biggest IT company by writing out $10,000 cheques for nothing.

And I noticed that you just skipped over the companies funding Postgresql development:

...

Not to mention idealistic and religious companies like Fujitsu, HP, Skype, to mention just a few...

http://www.postgresql.org/about/sponsors

So please, stop making out that OSS is solely some sort of idealistic crusade. People contribute to OSS for all sorts of reasons, including business sense, legal requirements, and others.

On 02 Aug 2010, at 09:01, Florian Klaempfl wrote:

I develop OSS longer than the term OSS exists (acutally since 1993) and 99% of all developement is done for idealistic reasons according to my experiences and I met lot of people from a lot of different projects. Even if people earn money with it, a idealistic component is required due to poor payment.

Or because it's a hobby (like writing, painting, sports, theatre, playing computer games, ...)

Jonas

Steven D'Aprano wrote:

...

...

That's probably why Microsoft agreed to match Jeff Atwood's donation of $5000 to support OSS Dot-Net development. Microsoft is famous for being idealistic and religious about open source.

And? $10000 is nothing. This approximately is what a senior software developer/architect with PhD./Master/Dipl.-Inf./Dpl.-Ing. costs a company per month.

Yes, and? The point which seems to have escaped you is that *Microsoft*, a company that a few years ago described Linux and OSS as "cancer", has now realised the business worth of it to *themselves*.

Hold on! *Dot-Net* development isn't exactly supporting Linux! In fact one might suspect that the purpose of the support might be to lure some free software supporters away from free OSs (or stop them from switching to them).

While I agree with your general point, this seems to be a bad example.

Frank

On 03 Aug 2010, at 02:30, Steven D'Aprano wrote:

I didn't mean to imply that Microsoft was all lovey-dovey with Linux now (although they've been forced by customer demand to be slightly less hostile to it). All I meant was that Microsoft sees value in the OSS model as it applies to .Net. If that's because they think it will lure people away from Linux to Windows, or stop them switching away from Windows, that just goes to support our point that there are lots of reasons for supporting OSS other than idealism.

It's not really supporting in this case. Microsoft is of the opinion that a lot of open source software infringes on their software patents (which is definitely true, just like it is the case for a lot of closed source software and for every other big company's patent portfolio). They believe that they should be compensated for this. With the .NET platform, they managed to get Novell to pay for a patent license for including Mono (an OSS implementation of the .NET platform) in their Linux distribution (SUSE), thereby validating Microsoft's claim that companies who distributes that software should pay them, and in general creating a precedent for paying patent license fees in return for the privilege of developing/distributing open source software.

So Microsoft is not really contributing to open source, but rather trying to get everyone who works on open source to pay them for infringing on their patents. It's a bit like saying that BP contributes to protecting the environment because they pay lobbyists for talking to politicians who work on environmental laws. Sure, they'll support some token "good points", but there's a significant difference between that and actually supporting the overall goal.

There are of course better examples, such as IBM, Google and even Apple. In those cases, it's more that the companies consider it to be more cost-effective to collaborate on basic infrastructure-level software rather than all privately developing basically the same stuff, rather than that they want everyone in the world to pay them for the privilege of writing and distributing free software.

As Florian mentioned however, the developers paid that way make up only a small fraction of the total open source development (many of them are even regular employees of those companies that used to work in similar, in house versions of such software) and unless your project and skills happen to be crucial to a particular company's business model, there is very little chance of ever making a living out of it.

Jonas

On 03 Aug 2010, at 17:18, Steven D'Aprano wrote:

On Tue, 3 Aug 2010 07:07:10 pm Jonas Maebe wrote:

...

It's not really supporting in this case. Microsoft is of the opinion that a lot of open source software infringes on their software patents (which is definitely true

[...]

Unless you can point out the infringing software, and demonstrate what patents it infringes, that's just an supposition. It is not "definitely true" except by doing violence to the idea of "definitely".

(to view the patents, enter the patent numbers at http://patft.uspto.gov/netahtml/PTO/srchnum.htm and click on "Search"; to see the most basic stuff covered by a patent, read claims that do not refer to other claims)

* Microsoft's patent on page up/page down (including a formula on how to calculate how much you have to scroll a text document to show the next page): 7,415,666 * Microsoft sues TomTom over (V)FAT patents infringed by the Linux kernel: http://laforge.gnumonks.org/weblog/2009/02/27/ * Microsoft reaches patent deal with HTC over patents infringed by Android: http://www.pcmag.com/article2/0,2817,2363175,00.asp * SUSE disables sub-pixel anti-aliasing because it infringes on Microsoft patents: http://techrights.org/2007/04/08/patent-font/

In what way does Microsoft writing out a cheque for thousands of dollars to give to developers who develop open sourced .Net software "trying to get everyone who works on open source to pay them for infringing on their patents"?

As I explained in the part you cut away: they are trying to get the open source version of .NET (Mono) gain wide acceptance. And they also reached a patent license deal with Novell that covered Mono (and OpenOffice): see the last FAQ at http://www.novell.com/linux/microsoft/faq.html, implying that everyone who wants to distribute/use those products should also get a patent license from Microsoft (otherwise, why would Novell need one?)

I mean, yes, I think Microsoft is devious too, but thinking that them funding developers to write OSS is a ploy to force them to pay patent fees is pure tinfoil helmet territory.

Tinfoil hats need not apply. Steve Balmer publicly announced that sooner or later someone will have to pay for the Microsoft patents that FOSS projects infringe. See http://www.linux-watch.com/news/NS6670466370.html about the Linux kernel in particular, and http://www.linux-watch.com/news/NS3513440381.html about the Novell deal and veiled threats to users of Red Hat Linux.

Yes, they're threatening to wield the patent sword (and yet they haven't done so ...

They have done plenty of times, see above. And those are only a number of published cases (there are more, involving at least Amazon, Samsung and IO Data). As you may or may not know, most patent cases however never reach the daylight and are settled behind the scenes (it's generally not good business to publish that you are being accused of patent infringement, and patent court cases cost insane amounts of money -- in fact, if the license fee is less than $1 million, in the US the costs of the court case itself will always outweigh the license fee; see slide 9 of http://people.ffii.org/~jmaebe/conf0411/tue/Brian%20Kahin.pdf ).

you have to wonder if their patents were so sound, why they haven't sued Red Hat out of existence yet?).

* Red Hat doesn't have that much money. It's more profitable to sue Linux users (Amazon, Samsung, TomTom, ...) * It could attract unwanted attention from anti-trust authorities (again)

They can do both at the same time. MS is a huge company, with many different departments with their own budgets to spend and their own managers making their own decisions.

Sure, see for example http://news.cnet.com/8301-13505_3-10290686-16.html

.NET is however not a good example.

Jonas

Steven D'Aprano wrote:

He can say whatever he likes, but until infringement is either proven in court or admitted

I'm with you on that count.

When I considered patenting my own ideas, I discovered that you could patent just about anything that had not been patented before. It's only when it comes to enforcing the patent in court that you run up against several other restrictions.

One such restriction is that your patent can't just be some reservation of use of existing technology for some purpose that you thought up, like "I patent the idea of selling software over the internet" (US Patent 4,528,643, issued July 9, 1985, for Freeny, bought by E-Data Corp, who tried to make money out of it, I don't know what happened to that in the end, but I seem to remember it going nowhere). Your patent must specify some process or technology that clearly took some effort to figure out. You can't simply jump to be the first person to patent something obvious. Furthermore, if it turns out that somebody else was already doing what you suggested, then your patent is invalid.

For sure: the rules are vague, and come down to a judgment call in court.

Yours, Kevan

On Thu, 5 Aug 2010 12:55:20 am Jonas Maebe wrote:

Therefore I stand by my original points that a) Microsoft paying a Mono developer $5,000 in no way demonstrates their alleged acceptance of open source or free software. That action fits perfectly into their patent FUD game (open source software whose usage you can license from Microsoft is good, and they'll even support its development)

There's a slight contradiction there. First you say it doesn't demonstrate their acceptance of FOSS, then you say it demonstrates their promotion of FOSS. In the second case, *Microsoft* FOSS, but still FOSS.

I think we're in violent agreement about this. In the context where this discussion started, namely motivations for contributing to FOSS software, it was claimed that idealism and religious fervour are the only reasons. I pointed out that many non-idealist and non-religious companies contribute to FOSS software. You've pointed out that Microsoft's support of FOSS is *extremely* nuanced and, dare I say it, Machiavellian:

"Microsoft FOSS Good, our competitors' FOSS Bad"

one might almost say. That's hardly support for FOSS on idealistic grounds, but a hard-nosed business tactic to defend their revenue stream from a threat. It displays an attitude that FOSS is not "a cancer" that need be destroyed, or a fringe movement from some hairy unwashed ex-UNIX dinosaurs and idealists that can be ignored, but something that will be around in the long term, and a real competitor to Microsoft that needs to be managed.

*That* was my point all along. I never suggested that Microsoft was a willing contributor to, say, the Linux kernel.

Oh wait...

http://www.microsoft.com/presspass/features/2009/jul09/07-20linuxqa.mspx http://www.linux-mag.com/id/7439

As I said, there are all sorts of reasons people contribute to FOSS projects, starting with "I have an itch that needs scratching", to "it will help prevent paying customers from dropping Windows Hyper-V virtualisation servers in favour of something else".

b) most software probably infringes on at least a couple of software patents out there (ones that will be held valid by at least one judge/ jury somewhere if they would be tried; besides, as long as a regular patent is not explicitly invalidated, it is assumed to be valid by virtue of having passed the examination process)

The second thing any competent patent defence would do (after trying to prove that your device is nothing like the patented device) is to try to invalidate the patent. Demonstrating that your device is based on prior art is not just a defence of the infringement claim, but could very well demonstrate that the patent isn't even valid because it does nothing new or different from the prior art.

As for the examination process... even the United States Patent Office is aware that the process isn't working and they grant patents too readily. They recently ran a trial "Peer-to-Patent" process, which invited people to research prior art for them. According to them, the average time each examiner has to research a patent is 18-20 hours:

http://www.peertopatent.org/getting_started

I suspect that's a self-serving over-estimate from the patent office. I remember reading that the more accurate figure is 5-6 hours per patent application, but I can't find the reference to it now so you'll just have to take that with a rather large grain of salt.

Florian Klaempfl wrote:

I wrote:

...

I think you miss one important point here: to contribute to an OSS project one must be rather idealistic or even religious about it (yes, this includes me ;))

I didn't say "only" but pointed out that it's a major motiviation for individuell persons ("one") and this is what I experienced in >15 years of free software and OSS development.

Since I'm currently in a parsing mindset, I have to point out that "must" in English implies a necessary condition, even without adding "only" (actually, "one must only ..." would mean something quite different).

Furthermore, "one" *can* be understood to refer to any person or group, not only individual persons (like in German: "man"), and I also understood it this way.

Frank

Am 06.08.2010 02:59, schrieb Steven D'Aprano:

You didn't say "major", you said "must". Not "usually are", or "can be", or "often are", or "sometimes are", or any other nuanced qualification. You made a sweeping generalisation that doesn't stand up to scrutiny.

I don't know if you are a native English speaker,

No.

...

("one") and this is what I experienced in >15 years of free software and OSS development. It explains also perfectly why FPC is a living project (yes, we also look always for contributors but which OSS projects doesn't do so?) while GPC is currently in some zombie state.

How does that explain this? Both GPC and FPC are FOSS software, aren't they? People who are idealistic about Pascal can be equally idealistic when using GPC as when using FPC, can they not?

The whole thread is about contributors and not users. FPC is self hosting so one being idealistic about pascal can also work in the compiler (and yes, several people working on FPC can maybe read C but coded seriously in C not even to talk about C++).

Anyways, the thread gets off topic.

John L. Ries wrote:

I think there are a variety of reasons why people contribute to free software, including the failure of the market to provide software that people want at prices they are willing to pay.

... or which works the way they want. That's a main reason for me. Whenever I use some proprietary software, including embedded software on "consumer electronics" devices, I notice various minor issues where I think: a 5-line (or less) change in the source code and this or that would work so much better or less annoying. But without source available, the simple change becomes impossible.

With free software, I just make the change and usually submit it back, if only so I don't have to make it again in the next version if it's accepted, so actually for quite egoistic reasons. (Though, incidentally or not, I find such kinds of problems more rarely in free software -- probably because someone else found and fixed them before me; while with non-free software, thousands or millions can find the same problem and whine on the internet about them, but they can't fix them, even if they'd like to take a little time to do it.)

(Of course, this doesn't mean there aren't also bigger issues in both free and non-free software -- in particular my involvement with GPC was caused by the rather major issue of BP's 16 bit and Dos limitations. But getting rid of thousands of minor nuisances is very helpful.)

Frank

Dear Chief,

I generally try to make available to others units (with sources) that I have benefited from

Well, I'm glad to do that, but I have not written to the list advertizing my libraries because I figure that would be close to bragging about my code.

So, all are welcome to my utility library, which provides matrix inversion using GPC's dynamic schema types, simplex fitting, and a bunch of other stuff.

http://alignment.hep.brandeis.edu/Software/Sources/utils.pas

The only documentation is in the comments, so there's another problem: when I tell people they can use my code, I have to tell them how to use it also, or else my offer is rather empty.

Yours, Kevan

Hi,

On 7/31/10, Frank Heckenbach ih8mj@fjf.gnu.de wrote:

For what I know, of the 5 main developers GPC has had, the percentage of Windows users (as their main OS) is exactly 0%. So if your statistic was relevant, there should be dozens of Windows programmers just waiting to take over as main developers and GPC's future was secured for decades. Or maybe a lot of those 90% are just computer "consumers" who wouldn't notice if the OS, hardware and applications on their computer were exchanged completely, as long as their icons look the same -- and you wonder why they're not here to discuss the future of a Pascal compiler?

That's correct, they are just consumers. And anyways 90% of all statistics are made up! ;-) My brother's new laptop is Win64. No problem at all for him (migrating from 32-bit Vista) because his favorite stuff still works: mIRC, iTunes, etc. For me (who shuns all that stuff), it'd be more painful (although admittedly mostly due to bugs and no NTVDM, *sniff*).

I'd add that it's not only (or even mainly) the GNU project, but standards such as POSIX that foster portability. Linux supports POSIX (plus extensions), Windows also (grudgingly) supports POSIX (minus some flaws), so a port from Linux to Windows is not always trivial, but possible with some effort.

Windows doesn't support POSIX at all unless you meant Cygwin. They've long ago dropped the (wimpy) POSIX subsystem. The only reason (AFAICT) to use MinGW is if you don't need POSIX and just want "fast and simple" binaries or if you dislike the Cygwin .DLL license issue. Obviously it's very hard to port anything from Linux to Windows, so there are many projects that have either none or alpha / very incomplete Windows support (e.g. Bash, Go, Git, TCC, QEMU). Targeting POSIX too heavily can indeed hurt on the Windows side. (And I'm not saying Windows is better, it's worse!)

OTOH, native Windows programs use a completely different API, and a port from Windows to Linux is a much larger task, basically rewriting anything related to the OS (not only GUIs, also file I/O uses a completely different API). Most Windows programmers don't care about this, or at best only as an afterthought.

True, sadly. It's something you have to think about ahead of time (or else really know what you're doing, have lots of experience porting, etc).

...

Like it or not, Delphi is the best Pascal system going out there, pricey indeed; well worth it in my opinion.

Fortunately, opinions can differ. In my opinion, software that is non-free and non-portable is never "the best".

Best Pascal? GPC! :-) Best Win32 (and now or soon Win64?) heavily-tweaked, Pascal-ish GUI-based? Maybe Delphi.

...

For the sake of clarity in this discussion, could someone please make a glossary of the many acronyms therein. I do not recognize half of them.

http://www.acronymfinder.com

I've yet to see a Windows user (who is not also a Linux user) supporting Linux-only features. And then I have to read (see above) how Windows is underrepresented and not talked about enough.

Well, if you're not also a Linux user, how could you even know how to support Linux?? Windows is definitely not completely underrepresented, but GNU does indeed target POSIX (or Linux) almost exclusively, and some GNU projects do indeed reject patches that don't fit that "ideal". So, it's true that Windows is supported, but they are not top tier (except maybe as a fluke sometimes by popularity).

So for those who think free software means they just get it without paying (free beer, not free speech) and yet get to tell us what we should do and complain when we do what we consider important, not what they consider important (instead of doing it themselves), that won't work.

Feedback is important. But sure, the one who codes decides. And programming isn't that easy.

Sure, one of the points of free software is that anyone can use it for any purpose, but there's also a rule: Those who code make the decisions.

:-))

And by this measure, if I look through the mailing list archives, Dos and Windows have actually been vastly overrepresented.

DOS overrepresented??? Nooooooo! Trust me, DOS is heavily shunned. It's not popular at all. I get a lot of flack for my support of it. And that's even with a GPL kernel + "BASE" (FreeDOS) + DJGPP w/ modern GCC. In some ways I consider it more portable (across OSes) and easy to use / install DOS software than Win32 or Linux. Or even easier to build / modify stuff. And yes, I know it's a losing battle ....

Win32 bores me with all its GUI and stupid technology (DirectX, .NET) although I am admittedly mostly a Windows "user". Only very very barely into Linux, but I don't think I'll ever be 100% "pro POSIX, GNU" etc. as long as their build processes and tools are so arcane and complex. In other words, I might use Linux more and more, but "in spirit" I will always be on the lookout to NOT be too *nix-oriented. It's not that I love Windows so much, just that *nix can be ugly at times. Besides, you can indeed ignore Windows (non-POSIX) if you want, but why would you want to?

I don't know, it's a mess. Even if everybody gets along (rare), everything's so complex or nobody has time. Portability is hard.

Hi,

On 7/31/10, Andreas K. Foerster list@akfoerster.de wrote:

On Sat, Jul 31, 2010 at 05:37:59AM -0500, Rugxulo wrote:

...

The only reason (AFAICT) to use MinGW is if you don't need POSIX and just want "fast and simple" binaries or if you dislike the Cygwin .DLL license issue.

No, I use MinGW because it is AFAICT the only compiler to build Windows executables for which you don't have to have a Windows system. ;-)

I meant vs. Cygwin. In other words, I see a lot of MinGW projects. Since both use GCC, you should "in theory" be able to cross compile from any valid host (even DJGPP). In practice, that doesn't always work (or is hard to do, at least for me).

OpenWatcom comes with libs and bins for (almost) any host or target, so the DOS-hosted version can by default target Win32, OS/2, Linux, etc. (Linux support is still considered experimental, but it seems to work okay, just no shared libs and no 64-bit.) Unlike TCC/Win32 or MinGW, it doesn't need MSVCRT (which I dislike, but anyways...).

...

Well, if you're not also a Linux user, how could you even know how to support Linux??

There is so much information on the Internet...

I mean how would somebody who doesn't "use" Linux a lot even have the imagination to write Linux-only features?? And a lot of the Internet is inaccurate, outdated, or disappears (bad links), argh!

...

but GNU does indeed target POSIX (or Linux) almost exclusively, and some GNU projects do indeed reject patches that don't fit that "ideal".

I don't see this. It's quite the opposite. Almost all GNU programs are also available for Windows. So I surely doubt that they reject code that makes their software run under Windows.

Not sure, I don't have a list offhand. I know a lot of Windows ports are unfinished or buggy. Sure, a lot of it works too. But I think GNU intentionally doesn't focus as much on Win32 because it's proprietary. (And yes, a few silly projects do reject patches out of spite.) It depends on the maintainers.

Of course they reject code that does not run on a GNU system or gives the (wrong) impression that their system is inferior. But what are you expecting? Would Microsoft support software that doesn't run on their system? That would really be a surprise! In contrast to the GNU project they don't even try to make most of their software run on other systems. And if than almost always for "bait and switch" stunts, ie. get others on the hook and when they byte and depend on it, then drop the support. That was also the only reason for them to implement POSIX support - to switch some POSIX people over to Windows.

MS is a 90,000+ employee company! Yes, they do a lot of dumb things, don't ask me why. I definitely don't agree with them much. They have so many bugs, dumb decisions, insane ads, high prices, but whatever, it's beyond me. I'm no huge Windows fan, and I don't want to really waste much time focusing on their dumb APIs.

Call me lazy or dumb myself, but I'm somewhat behind in Linux, so it's all fairly Greek to me. Even a lot of their stuff is too complex or I dislike. But hey, whatever, can't please everyone. There is no perfect OS.

(I'm on Linux now because XP hosed itself on this P4 oldie a few months ago. I've tried various distros off and on for three years. Always some few peculiar bugs and a few questionable decisions but otherwise okay. I'm no hardcore "user", though, don't need dual monitors or iTunes or Blu-Ray or AutoCad or PhotoShop or ....)

...

barely into Linux, but I don't think I'll ever be 100% "pro POSIX, GNU" etc. as long as their build processes and tools are so arcane and complex.

Have you tried KDevelop or Anjuta?

No, and sorry, that's not what I meant. ;-) I meant that some things are impossible to build or have horrible dependencies. In other words, I wonder what they were thinking! (This applies to any OS, lots of hard-to-reproduce builds from source code.)

P.S. I don't know, how do you decide what to support and what not to support without pissing someone off? I say the more the merrier, but I know it's hard to do.

On Sun, 1 Aug 2010, Andreas K. Foerster wrote:

On Sat, Jul 31, 2010 at 06:07:41PM -0500, Rugxulo wrote:

...

...

...

The only reason (AFAICT) to use MinGW is if you don't need POSIX and just want "fast and simple" binaries or if you dislike the Cygwin .DLL license issue.

No, I use MinGW because it is AFAICT the only compiler to build Windows executables for which you don't have to have a Windows system. ;-)

I meant vs. Cygwin. In other words, I see a lot of MinGW projects.

I also meant versus Cygwin. I am not aware that Cygwin could be used as a cross compiler. I know no distribution that has a Cygwin cross compiler, but many have a MinGW cross compiler.

Cygwin actually comes with an optional set of MinGW libraries. I normally use Cygwin GCC and friends to create MinGW execs since I have a hard time working on Windows without Cygwin anymore (the X server is addictive) and I don't really want to have to maintain a separate MinGW/MSYS installation on my Windows box.

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

On Sun, Aug 01, 2010 at 11:07:26PM +0200, Frank Heckenbach wrote:

...

Looks very useful, thanks. My suggestion is (at some point in time) to develop a repository of GPC units. BP used to have the SWAG archives, and there are all sorts of Delphi code repositories.

A good idea. However, someone has to do it. We tried it half-heartedly some years ago, but (see above) the time we spent as webmasters was time we couldn't spend on compiler development. So if there are so many who'd like to contribute but are daunted by the compiler internals as we always hear, why don't they do something like this? (Even it probably would have been more effective 10 years ago than now ...)

Why not simply use a wikipage that anyone can edit? I have made a start in the (German) Linux-Wiki: http://linuxwiki.org/GnuPascal/Software

Hi,

On Sat, Jul 31, 2010 at 06:07:41PM -0500, Rugxulo wrote:

But I think GNU intentionally doesn't focus as much on Win32 because it's proprietary.

There seems to be some misconception here on what "GNU" is - there is no "GNU overlord" that tells software developers what to do and what not to do.

Open Source developers do what they need to get their work done, what they find interesting to do, sometimes what they think need to be done, and possibly because they are paid to do some stuff they are not otherwise interested in.

So unless someone waves with a heap of money, most Open Source programmers prefer to work on environments that they are familiar with and that are easy to program for - and that's (most of the time) not windows.

gert

On 02/08/2010, Andreas K. Foerster list@akfoerster.de wrote:

On Sun, Aug 01, 2010 at 12:55:02PM +0200, Gert Doering wrote:

...

On Sat, Jul 31, 2010 at 06:07:41PM -0500, Rugxulo wrote:

...

But I think GNU intentionally doesn't focus as much on Win32 because it's proprietary.

There seems to be some misconception here on what "GNU" is - there is no "GNU overlord" that tells software developers what to do and what not to do.

Of course there is a GNU overlord: his name is Richard M. Stallman. He is the only one who can decide whether something is GNU software, or not. And he does tell developers what to do and what not, that's for sure!

[...]

...

Open Source developers do what they need to get their work done,

Who talked about "Open Source" here? And what does it have to do with GNU software?

Seems to me that there is some confusion underlying here: the GNU Project aims to produce an Open Source (more precisely, a "Free" as in speech) operating system and set of applications, and it has an overlord, namely: Richard Stallman. On the other hand, the GNU Project designed the GNU GPL (General Public License) to release the software, to ensure that the OS and friends remain forever "free" (as in speech). Now, a lot of OSS is release under GPL, to ensure "openness", but doesn't belong to the GNU project; the released software has then no overlord, save for the individual developer(s). They are not synonymous, since there are other licenses useful to release OSS.

Now, as far as GPC is concerned, I'm not positive about its status: has it been acknowledged as part of the GNU project, or is it only released as OSS, with GCC as its backend compiler?

Cheers,

On Sat, Jul 31, 2010 at 09:12:14AM +0200, Frank Heckenbach wrote:

With GPC this hasn't happened much. Even if working on the GPC compiler itself was difficult due to its backend dependency, this was no reason to prevent contributions to Pascal units, both the units that come with GPC, including most of its runtime system, and 3rd party units or applications (e.g. IDEs). But this happened only to a small degree. I can only speculate on why, whether it's mentality (as expressed in statements such as the above), or that everyone is just too busy working on their in-house applications, or even the large array of dialects that GPC supports (which are normally thought of as an asset, but may have become a problem in that they stifle cooperation between users if everybody uses their own set of features).

Or those units are just not well known. ;-)

So may I take the chance to remind you, that I still offer GPC and FPC bindings for my project AKFAvatar.

http://AKFAvatar.nongnu.org/

AKFAvatar is a graphical frontend for programs. An avatar appears on the screen and tells things written in a balloon. Writing programs for AKFAvatar is as easy as writing for the command line, but it looks much better.

I have written AKFAvatar mainly, because I myself do not like GUIs very much. But many people hate command line tools (they still identify the command line with an ancient operating system that was very limited in its capabillities... you know what I mean.) So I have written AKFAvatar as a compromise between both worlds...

P.S.: I have chosen the name "AKFAvatar" long before I ever heard of the film "Avatar". So it has absolutely nothing to do with that.

P.P.S.: I switched to other programming languages and don't do much with Pascal anymore. Pascal also has the problem that many still identify it with a long outdated implementation, and because of that they think that Pascal is lame. I think Pascal is much better than C, but I wouldn't dare anymore to say that in front of people who don't know Pascal well enough.

On Sat, Jul 31, 2010 at 09:54:49PM +0100, Prof Abimbola Olowofoyeku (The African Chief) wrote:

...

So may I take the chance to remind you, that I still offer GPC and FPC bindings for my project AKFAvatar.

http://AKFAvatar.nongnu.org/

AKFAvatar is a graphical frontend for programs. An avatar appears on the screen and tells things written in a balloon. Writing programs for AKFAvatar is as easy as writing for the command line, but it looks much better.

Looks like it could be useful. Any screen shots to see what it actually looks like in real usage?

Only the one on the homepage... (click to enlarge)

Okay, I just said that it looks much better than a text-console, I did not say that it looks great. I know that I'm not a good graphic designer.

There are some other Avatar-images in the package and you can use your own one...

There are also many features, that you could not see in a screenshot anyway. For example you can activate a slowprint mode, in which the text is displayed letter by letter. The Avatar can move in or out. You can show images or play sounds. You can make menus or ask yes/no questions (both usable with the mouse). There is a pager, with which you can scroll through long texts, like "less", but you can also use the mouse-wheel...

Gee, I even implemented a full blown terminal emulation, in which you can simply run existing programs; and not only line-oriented ones but also ncurses based programs.... But that is only available for POSIX systems. (Tested on GNU/Linux and FreeBSD.)

Frank Heckenbach wrote:

Even if working on the GPC compiler itself was difficult due to its backend dependency, this was no reason to prevent contributions to Pascal units

I would have offered to contribute, but I assumed that there were so many experts working on it that I would be told No Thank You. But I'm saying now: I'm in. I will look at the GPC internals page and try to see what's entailed in maintaining the inerface with GCC, because one way to proceed is simply to find enough people to bring the GCC interface up to date.

Yours, Kevan