While trying to learn and exploit the unix (linux) platform, my google searches have turned up ms.net references (for example named pipes or fifos). MS is re-learning unix.
In unix, software is built as small programs (tools) and assembled via scripting languages into executables. Tool instances are managed as "processes" by the OS itself. This script level approach is similar to compiled level classes, polymorphism, encapsulation, etc, of other languages. But of course, scripts are far simpler and more flexible.
Many of these unix tools are quite old, but still useful. For example the cron program is a background job scheduler.
Where modern pascal works so well is in building new compiled unix tools. C is just not an option for most applications programmers.
So I am less concerned with "new" features than I am with stability and clarity. Both GPC and FPC are fantastic contributions to the world's technical community (on the linux platform). The learning process is very long, so stability and clarity are essential.
Hi, Rick!
I couldn't agree with you more. GPC is a great step forward in a fight for diversity, if it isn't anything else. It would be very nice to have all kernel calls available in GPC via a library, so one could also write system programs in GPC. IMHO GPC is nowadays stable enough to succeed writing system programs, and it is possible that such programs would be more reliable! (cosider only range checking vs. C's dangerous pointers that always shoot somebody in his leg).
Your thinking is enouraging me to attempt writting very system software for Linux in GPC. After all, installing GPC is now as easy as installing .deb or .rpm, isn't it?
I agree with you that stability is much more important than "new" things when writting system-level software.
Have a nice day, Mirsad
On Fri, 10 Jun 2005, Rick Engebretson wrote:
While trying to learn and exploit the unix (linux) platform, my google searches have turned up ms.net references (for example named pipes or fifos). MS is re-learning unix.
In unix, software is built as small programs (tools) and assembled via scripting languages into executables. Tool instances are managed as "processes" by the OS itself. This script level approach is similar to compiled level classes, polymorphism, encapsulation, etc, of other languages. But of course, scripts are far simpler and more flexible.
Many of these unix tools are quite old, but still useful. For example the cron program is a background job scheduler.
Where modern pascal works so well is in building new compiled unix tools. C is just not an option for most applications programmers.
So I am less concerned with "new" features than I am with stability and clarity. Both GPC and FPC are fantastic contributions to the world's technical community (on the linux platform). The learning process is very long, so stability and clarity are essential.
Mirsad Todorovac wrote:
I couldn't agree with you more. GPC is a great step forward in a fight for diversity, if it isn't anything else. It would be very nice to have all kernel calls available in GPC via a library, so one could also write system programs in GPC.
I partly agree. There are system calls for very specific purposes (say, mounting, loading modules, or even single-purpose calls such as sync() and reboot()). They are used by the corresponding utilities, and those utilities exist (though written in C), and are well tested over the years. I see no real point rewriting those utilities, just for the sake of it. If a higher level program really wants to performs those tasks (such as mounting, module loading, syncing, rebooting), which would be a rare situation anyway, I'd prefer to call the external utility actually. Basically, as Rick wrote about shell programs -- this is, of course, possible from Pascal programs as well, and it'll probably be more portable.
So, such kinds of system calls aside, there are still a number that should be made available to GPC programs IMHO. I've done some of them in the RTS, but mostly on an as-needed basis so far. I'll probably add more when I get to it and/or need it, and if you like to, you're welcome to help.
But please keep in mind portability. Unix tools, and especially GNU tools, gained popularity also because of their portability (across Unix systems, and mostly also to Dos, Windows and Mac now). Using autoconf, e.g. in the RTS, will help here quite a bit. BTW, I think in this regard, we're also in a better situation than C programmers. They have to auto-check the features in each single program (or use a portable library layers -- I've seen some attempts, but none seems to have widely spread yet). In GPC, if we do it in the RTS, it will be available for all GPC programs, without the need to find and install an external library, and tested with the installation of GPC (provided, of course, you write test programs for the new routines, which I stronly encourage).
I agree with you that stability is much more important than "new" things when writting system-level software.
I certainly don't object to the importance fo stability. Just please keep in mind that stability it still something we strive to attain in GPC in the first place, considering its history starting as a hacked C compiler frontend, and seeing that until a few years ago, compiling with optimization and/or debugging info (leave alone both), or using a number of problematic features (including schemata) was more or less suicidal. ;-) I think we've made significant progress up to now -- the number of known bugs on the to-do list and in the test/todo directory is at an all-time low now (22 programs in the latter, most of which are actually new feature requests, and of the remaining few bugs, most are rather exotic situations). There are still some problems on 64 bits targets and some less common systems, and Waldek is working to fix them. Once most of them are fixed (and no new short-term bugs are present), I think we can really call GPC a stable compiler for the first time.
From then on, of course, I'll try to preserve this level of
stability in future releases (except possibly alpha releases, as recently discussed).
Frank
Frank Heckenbach wrote:
Mirsad Todorovac wrote:
It was 1:30 in the morning here when I wrote the email. Unix has given us global communications in our generation. I've been pushing a fuel cell grid, and mentioned hybrid/electric cars. Unix-like computing underlies much of a happier, more peaceful world.
The GPC team has made great progress, as has the FPC team, offering outstanding open source Pascal to the world for FREE!!
My mail was more directed to those who have not tried Unix/Linux yet want ever more features from GPC itself.
I've been in this game a long time. I sit at a desk from Otto Schmitt's lab from the U of Minnesota. Otto was a big man, about 6 foot 2 inches and 300 pounds. One of his original Schmitt triggers weighs about 150 pounds. Electronics was a big man's game. The cooling systems of the old tube computers were walk-in coolers.
We are doing very well, and must keep a long term perspective. That was my expressed concern.
Seems there are still big fans for Pascal. So do we with our SCADA system.
However, IBM is giving up support for Pascal, which is making up a significant portion of our source codes.
Does anyone know whether there is any project in place to extend the support to AIX5.x?
If there is beta or even alpha version available, we would like to join for thorough testing & trial.
Best Regards.
Rick Engebretson wrote:
While trying to learn and exploit the unix (linux) platform, my google searches have turned up ms.net references (for example named pipes or fifos). MS is re-learning unix.
In unix, software is built as small programs (tools) and assembled via scripting languages into executables. Tool instances are managed as "processes" by the OS itself. This script level approach is similar to compiled level classes, polymorphism, encapsulation, etc, of other languages. But of course, scripts are far simpler and more flexible.
Many of these unix tools are quite old, but still useful. For example the cron program is a background job scheduler.
Where modern pascal works so well is in building new compiled unix tools. C is just not an option for most applications programmers.
So I am less concerned with "new" features than I am with stability and clarity. Both GPC and FPC are fantastic contributions to the world's technical community (on the linux platform). The learning process is very long, so stability and clarity are essential.
KM Pong wrote:
Seems there are still big fans for Pascal. So do we with our SCADA system.
However, IBM is giving up support for Pascal, which is making up a significant portion of our source codes.
Does anyone know whether there is any project in place to extend the support to AIX5.x?
If there is beta or even alpha version available, we would like to join for thorough testing & trial.
GPC should work "out of the box" on AIX5.[23]. I can not myself test GPC on AIX but on the mailing list we had success reports.
You need to build GPC form the sources (AFAIK there is no binary package available). For that you need also GCC sources (gcc-3.3.x or gcc-3.4.x). Building GCC on AIX needs some care, read GPC and GCC instalation note. If you need more info ask here.
Hi,
On Thu, Jun 23, 2005 at 12:49:16AM +0800, KM Pong wrote:
Does anyone know whether there is any project in place to extend the support to AIX5.x?
GPC works fine on AIX 5.x
There are some differences between the AIX pascal compiler (xlp) and gpc - things like structure aligmnent, if I remember correctly - but "our pascal people" tell me that this is nothing they can't handle. (I'm a C person, so I don't know the specifics - I'm just responsible for compiling GPC and installing it - and I've forgotten most of the pascal knowledge I had).
gert