* why ada is so unpopular ? @ 2004-01-17 11:15 Szymon Guz 2004-01-17 13:53 ` Martin Dowie ` (3 more replies) 0 siblings, 4 replies; 296+ messages in thread From: Szymon Guz @ 2004-01-17 11:15 UTC (permalink / raw) Hi, I'd like to know how ada is popular ? And i which countries. I'm asking because I live in Poland and here I couldn't find any firm that use it. szymon guz ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-17 11:15 why ada is so unpopular ? Szymon Guz @ 2004-01-17 13:53 ` Martin Dowie 2004-01-17 14:27 ` Dmytry Lavrov ` (2 subsequent siblings) 3 siblings, 0 replies; 296+ messages in thread From: Martin Dowie @ 2004-01-17 13:53 UTC (permalink / raw) "Szymon Guz" <alpha@skynetSMIECI.VONorg.NOJUSZpl> wrote in message news:bub5n8$kf5$1@atlantis.news.tpi.pl... > Hi, > I'd like to know how ada is popular ? And i which countries. I'm asking > because I live in Poland and here I couldn't find any firm that use it. Check your local military suppliers. We certainly sell Ada-based products to Poland. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-17 11:15 why ada is so unpopular ? Szymon Guz 2004-01-17 13:53 ` Martin Dowie @ 2004-01-17 14:27 ` Dmytry Lavrov 2004-01-17 21:02 ` Szymon Guz 2004-01-18 18:41 ` Jano 2004-01-21 2:01 ` Luke A. Guest 3 siblings, 1 reply; 296+ messages in thread From: Dmytry Lavrov @ 2004-01-17 14:27 UTC (permalink / raw) Military uses. It's answer to question why unpopular. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-17 14:27 ` Dmytry Lavrov @ 2004-01-17 21:02 ` Szymon Guz 2004-01-17 22:36 ` Adrian Knoth ` (2 more replies) 0 siblings, 3 replies; 296+ messages in thread From: Szymon Guz @ 2004-01-17 21:02 UTC (permalink / raw) Dmytry Lavrov wrote: > Military uses. It's answer to question why unpopular. I see. But I'd like to know if it is worth learning. I'd like to write a program and maybe in future earn on that and I still don't know what to choose ada or C++. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-17 21:02 ` Szymon Guz @ 2004-01-17 22:36 ` Adrian Knoth 2004-01-18 9:21 ` Szymon Guz 2004-01-17 23:01 ` Marin David Condic 2004-01-19 23:46 ` chris 2 siblings, 1 reply; 296+ messages in thread From: Adrian Knoth @ 2004-01-17 22:36 UTC (permalink / raw) Szymon Guz <alpha@skynetSMIECI.VONorg.NOJUSZpl> wrote: >> Military uses. It's answer to question why unpopular. > program and maybe in future earn on that and I still don't know what to > choose ada or C++. If your program solves the problem then your clients won't ask which language do you've used. If you're more common with C++, then use C++. If you need some libraries only available for C++, use C++. If you think you might get serious problems in quality when using C++, use Ada. ;) And never forget: While the Ada-guys go out for lunch the C++-devision is still using the debugger ;) [don't remember the exact quote] -- mail: adi@thur.de http://adi.thur.de PGP: v2-key via keyserver Kosmetik ist die Kunst aus der Not eine Jugend zu machen! ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-17 22:36 ` Adrian Knoth @ 2004-01-18 9:21 ` Szymon Guz 2004-01-18 12:18 ` Luke A. Guest 2004-01-18 12:59 ` Ronald Dauster 0 siblings, 2 replies; 296+ messages in thread From: Szymon Guz @ 2004-01-18 9:21 UTC (permalink / raw) Adrian Knoth wrote: > Szymon Guz <alpha@skynetSMIECI.VONorg.NOJUSZpl> wrote: > > >>>Military uses. It's answer to question why unpopular. >> >>program and maybe in future earn on that and I still don't know what to >>choose ada or C++. > > > If your program solves the problem then your clients won't ask which > language do you've used. > > If you're more common with C++, then use C++. If you need some > libraries only available for C++, use C++. If you think you might > get serious problems in quality when using C++, use Ada. ;) > > And never forget: While the Ada-guys go out for lunch the C++-devision > is still using the debugger ;) [don't remember the exact quote] > well.. I know that, but my problem is a little bit different. I don't have money for sth like Builder or Kylix or Visual but I think that my program really needs to operate on some windows. I don't want to write that using WinApi nor Gtk; First of all the Gtk/Qt licence is not good for me and WinApi is terrible. I wanted to use wxWindows. It is written in C++, that's why I still don't know what to choose. Mix wxWindows(C++) with Ada or just use C++. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-18 9:21 ` Szymon Guz @ 2004-01-18 12:18 ` Luke A. Guest 2004-01-18 13:09 ` Ronald Dauster 2004-01-18 12:59 ` Ronald Dauster 1 sibling, 1 reply; 296+ messages in thread From: Luke A. Guest @ 2004-01-18 12:18 UTC (permalink / raw) On Sun, 18 Jan 2004 10:21:16 +0100, Szymon Guz wrote: > well.. I know that, but my problem is a little bit different. I don't > have money for sth like Builder or Kylix or Visual but I think that my > program really needs to operate on some windows. I don't want to write > that using WinApi nor Gtk; First of all the Gtk/Qt licence is not good > for me and WinApi is terrible. I wanted to use wxWindows. It is written > in C++, that's why I still don't know what to choose. Mix wxWindows(C++) > with Ada or just use C++. Hmm, I asked this on the wxWindows list the other day, the reply was that the easiest way to do it would be to add an Ada backend to SWIG and use the code from wxPython. I can't be bothered as I haven't got the time. Luke. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re:was: why ada is so unpopular ? 2004-01-18 12:18 ` Luke A. Guest @ 2004-01-18 13:09 ` Ronald Dauster 0 siblings, 0 replies; 296+ messages in thread From: Ronald Dauster @ 2004-01-18 13:09 UTC (permalink / raw) Luke A. Guest wrote: > On Sun, 18 Jan 2004 10:21:16 +0100, Szymon Guz wrote: > > >>well.. I know that, but my problem is a little bit different. I don't >>have money for sth like Builder or Kylix or Visual but I think that my >>program really needs to operate on some windows. I don't want to write >>that using WinApi nor Gtk; First of all the Gtk/Qt licence is not good >>for me and WinApi is terrible. I wanted to use wxWindows. It is written >>in C++, that's why I still don't know what to choose. Mix wxWindows(C++) >>with Ada or just use C++. > > > Hmm, I asked this on the wxWindows list the other day, the reply was that > the easiest way to do it would be to add an Ada backend to SWIG and use > the code from wxPython. > Writing a language backend for SWIG is by no means trivial. In addition, the SWIG mappings for different languages have very different capabilities. That means, to get a clean Ada interface the wxPython interface will need a lot of tweaking. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-18 9:21 ` Szymon Guz 2004-01-18 12:18 ` Luke A. Guest @ 2004-01-18 12:59 ` Ronald Dauster 2004-01-18 13:25 ` Stephane Richard 2004-01-18 14:17 ` Szymon Guz 1 sibling, 2 replies; 296+ messages in thread From: Ronald Dauster @ 2004-01-18 12:59 UTC (permalink / raw) Szymon Guz wrote: > > well.. I know that, but my problem is a little bit different. I don't > have money for sth like Builder or Kylix or Visual but I think that my > program really needs to operate on some windows. I don't want to write > that using WinApi nor Gtk; First of all the Gtk/Qt licence is not good The Gtk and Qt licenses are substantially different. GTK is under LGPL and I do not see, where this creates a problem. Qt, of course, either requires your application to be licensed under GPL or you have to buy a commercial license. > for me and WinApi is terrible. I wanted to use wxWindows. It is written > in C++, that's why I still don't know what to choose. Mix wxWindows(C++) > with Ada or just use C++. As far as I know, there is no Ada binding to wxWindows and, given the size and programming style of wxWindows, it will be a _lot_ of work to create one. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-18 12:59 ` Ronald Dauster @ 2004-01-18 13:25 ` Stephane Richard 2004-01-18 14:17 ` Szymon Guz 1 sibling, 0 replies; 296+ messages in thread From: Stephane Richard @ 2004-01-18 13:25 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1259 bytes --] To what I know too, there's no Ada binding for it....and it would probably be equal or less work to port the whole library to Ada instead of attempting to bind to it. -- St�phane Richard "Ada World" Webmaster http://www.adaworld.com "Ronald Dauster" <rpd@gido.remove_this_part.de> wrote in message news:budvvf$9al$1@online.de... > Szymon Guz wrote: > > > > > well.. I know that, but my problem is a little bit different. I don't > > have money for sth like Builder or Kylix or Visual but I think that my > > program really needs to operate on some windows. I don't want to write > > that using WinApi nor Gtk; First of all the Gtk/Qt licence is not good > > The Gtk and Qt licenses are substantially different. GTK is under > LGPL and I do not see, where this creates a problem. Qt, of course, > either requires your application to be licensed under GPL or you have > to buy a commercial license. > > > for me and WinApi is terrible. I wanted to use wxWindows. It is written > > in C++, that's why I still don't know what to choose. Mix wxWindows(C++) > > with Ada or just use C++. > > As far as I know, there is no Ada binding to wxWindows and, given the > size and programming style of wxWindows, it will be a _lot_ of work to > create one. > > > ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-18 12:59 ` Ronald Dauster 2004-01-18 13:25 ` Stephane Richard @ 2004-01-18 14:17 ` Szymon Guz 2004-01-18 14:42 ` Marin David Condic 1 sibling, 1 reply; 296+ messages in thread From: Szymon Guz @ 2004-01-18 14:17 UTC (permalink / raw) Ronald Dauster wrote: > Szymon Guz wrote: > >> >> well.. I know that, but my problem is a little bit different. I don't >> have money for sth like Builder or Kylix or Visual but I think that my >> program really needs to operate on some windows. I don't want to write >> that using WinApi nor Gtk; First of all the Gtk/Qt licence is not good > > > The Gtk and Qt licenses are substantially different. GTK is under > LGPL and I do not see, where this creates a problem. Qt, of course, > either requires your application to be licensed under GPL or you have > to buy a commercial license. > well... I wrote that thinking that GTK is licenced under GPL, I'll check that because I'm not sure how it really is. The commercial licence of Qt is too expensive for me and the GPL licence means that my program have to licensed under GPL and I want to avoid that. >> for me and WinApi is terrible. I wanted to use wxWindows. It is >> written in C++, that's why I still don't know what to choose. Mix >> wxWindows(C++) with Ada or just use C++. > > > As far as I know, there is no Ada binding to wxWindows and, given the > size and programming style of wxWindows, it will be a _lot_ of work to > create one. > so does that all mean that I should use C++ for that ? ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-18 14:17 ` Szymon Guz @ 2004-01-18 14:42 ` Marin David Condic 2004-01-18 15:23 ` Szymon Guz 2004-01-18 16:34 ` Preben Randhol 0 siblings, 2 replies; 296+ messages in thread From: Marin David Condic @ 2004-01-18 14:42 UTC (permalink / raw) My understanding of Gtk - at least in its Ada incarnation GtkAda - was that it is licensed such that an application that calls it is not subject to the GPL license. Should one modify the library itself, those changes would naturally be covered by the GPL, but to simply use it as a GUI interface would not require you to put your app under the GPL. Am I wrong about this? MDC Szymon Guz wrote: > > well... > I wrote that thinking that GTK is licenced under GPL, I'll check that > because I'm not sure how it really is. > The commercial licence of Qt is too expensive for me and the GPL licence > means that my program have to licensed under GPL and I want to avoid that. > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-18 14:42 ` Marin David Condic @ 2004-01-18 15:23 ` Szymon Guz 2004-01-18 17:53 ` Jeffrey Carter 2004-01-18 16:34 ` Preben Randhol 1 sibling, 1 reply; 296+ messages in thread From: Szymon Guz @ 2004-01-18 15:23 UTC (permalink / raw) Marin David Condic wrote: > My understanding of Gtk - at least in its Ada incarnation GtkAda - was > that it is licensed such that an application that calls it is not > subject to the GPL license. Should one modify the library itself, those > changes would naturally be covered by the GPL, but to simply use it as a > GUI interface would not require you to put your app under the GPL. Am I > wrong about this? > > MDC > yea, you're right.. I've checked that and for suer it the LGPL licence: "GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties." http://gtk.org/faq/#AEN81 ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-18 15:23 ` Szymon Guz @ 2004-01-18 17:53 ` Jeffrey Carter 0 siblings, 0 replies; 296+ messages in thread From: Jeffrey Carter @ 2004-01-18 17:53 UTC (permalink / raw) Szymon Guz wrote: > yea, you're right.. I've checked that and for suer it the LGPL licence: > > "GTK+ is free software and part of the GNU Project. However, the > licensing terms for GTK+, the GNU LGPL, allow it to be used by all > developers, including those developing proprietary software, without any > license fees or royalties." > http://gtk.org/faq/#AEN81 GtkAda, the Ada binding to GTK+, is under the GNAT-Modified GPL (GMGPL), so Ada programs using GTK through GtkAda can be proprietary if the developer desires. -- Jeff Carter "Ada has made you lazy and careless. You can write programs in C that are just as safe by the simple application of super-human diligence." E. Robert Tisdale 72 ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-18 14:42 ` Marin David Condic 2004-01-18 15:23 ` Szymon Guz @ 2004-01-18 16:34 ` Preben Randhol 2004-01-19 12:59 ` Marin David Condic 1 sibling, 1 reply; 296+ messages in thread From: Preben Randhol @ 2004-01-18 16:34 UTC (permalink / raw) On 2004-01-18, Marin David Condic <nobody@noplace.com> wrote: > My understanding of Gtk - at least in its Ada incarnation GtkAda - was > that it is licensed such that an application that calls it is not > subject to the GPL license. Should one modify the library itself, those > changes would naturally be covered by the GPL, but to simply use it as a > GUI interface would not require you to put your app under the GPL. Am I > wrong about this? Nope. The GtkAda license: License This package is distributed under the GPL license, slightly modified so that you can create proprietary software with this toolkit. The license is actually the same as the GNAT library itself. You should also read the Gtk license itself if you intend to do proprietary software based on gtk and GtkAda. -- "Saving keystrokes is the job of the text editor, not the programming language." ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-18 16:34 ` Preben Randhol @ 2004-01-19 12:59 ` Marin David Condic 2004-01-19 13:06 ` Preben Randhol 2004-01-19 13:09 ` Jeff C, 0 siblings, 2 replies; 296+ messages in thread From: Marin David Condic @ 2004-01-19 12:59 UTC (permalink / raw) I don't know about the Gtk license itself or why GtkAda would have to modify it slightly to enable the writing of proprietary software. What I gathered by looking at the GtkAda license at least was that one could develop an entirely proprietary app that made the Gtk calls through the GtkAda binding. If one was doing a Gtk based interface, GtkAda seems like the only logical choice (unless one needs Gtk capabilities that aren't supported in GtkAda - a problem that all such bindings have and an argument as to why Ada ought to have its own GUI.) It seems the best choice for a semi-portable interface if that is the requirement. GPL "infection" does not seem to be an issue AFAICS. MDC Preben Randhol wrote: > > This package is distributed under the GPL license, slightly modified so > that you can create proprietary software with this toolkit. The license > is actually the same as the GNAT library itself. You should also read > the Gtk license itself if you intend to do proprietary software based on > gtk and GtkAda. > > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-19 12:59 ` Marin David Condic @ 2004-01-19 13:06 ` Preben Randhol 2004-01-19 13:28 ` Marin David Condic 2004-01-19 13:09 ` Jeff C, 1 sibling, 1 reply; 296+ messages in thread From: Preben Randhol @ 2004-01-19 13:06 UTC (permalink / raw) On 2004-01-19, Marin David Condic <nobody@noplace.com> wrote: > I don't know about the Gtk license itself or why GtkAda would have to > modify it slightly to enable the writing of proprietary software. Gtk usees LGPL GtkAda uses GMGPL as simple as that. > aren't supported in GtkAda - a problem that all such bindings have and > an argument as to why Ada ought to have its own GUI.) Well if you look at Java you see that the GUI isn't the same in all platforms and IMHO the GUI is butt-ugly. The only benifit of a special Ada GUI would be portability and not having to use C library. -- "Saving keystrokes is the job of the text editor, not the programming language." ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-19 13:06 ` Preben Randhol @ 2004-01-19 13:28 ` Marin David Condic 2004-01-19 13:37 ` Preben Randhol 0 siblings, 1 reply; 296+ messages in thread From: Marin David Condic @ 2004-01-19 13:28 UTC (permalink / raw) Preben Randhol wrote: > > Well if you look at Java you see that the GUI isn't the same in all > platforms and IMHO the GUI is butt-ugly. > Java's GUI may or may not be butt-ugly. But one thing it is: It's _Java's_ GUI and as it evolves, Java users pretty much get full access to whatever new features are added without having to wait for some binding to catch up. > The only benifit of a special Ada GUI would be portability and not > having to use C library. > Portability would be one thing, but not the only thing. "Product Distinction" would be another: An Ada GUI could go its own way and do things "The Ada Way" from the programmer's perspective and might even provide a unique "Look & Feel" to Ada apps. (People might then actually *care* that their apps were done with Ada, eh?) You'd also benefit from the fact that (as observed above for Java) it would be _Ada's_ GUI and there would be no waiting around for some binding to catch up. It goes its own direction, develops its own look-and-feel and might start developing features that user's of other languages would wish *they* had available to them. (Hint: Switch to Ada and you can have them.) I've tinkered with GtkAda and - while it is a good and useful thing - I can observe that there seem to be some features that Gtk has (under Gnome?) that are simply not available through GtkAda. One might want to use those features - but its either roll your own, wait for GtkAda to catch up or go use C/C++ like the entire rest of the world does. What do you suppose most programmers do? (Hint: Look at the relative popularity of C/C++ to that of Ada.) This is always the problem that Ada has with bindings, etc. It's playing the "Me Too!!!!" catch-up game. The best you can hope for then is to come in second-place. That's why Ada ought to be developing a library of its own to supply a GUI and the other things that seem to come along for the ride with C++ or Java. MDC -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-19 13:28 ` Marin David Condic @ 2004-01-19 13:37 ` Preben Randhol 2004-01-20 12:38 ` Marin David Condic 0 siblings, 1 reply; 296+ messages in thread From: Preben Randhol @ 2004-01-19 13:37 UTC (permalink / raw) On 2004-01-19, Marin David Condic <nobody@noplace.com> wrote: > Java's GUI may or may not be butt-ugly. But one thing it is: It's > _Java's_ GUI and as it evolves, Java users pretty much get full access > to whatever new features are added without having to wait for some > binding to catch up. Well, who would be in charge of an Ada GUI and develop it actively and not every 10-15 years ? > Portability would be one thing, but not the only thing. "Product > Distinction" would be another: An Ada GUI could go its own way and do > things "The Ada Way" from the programmer's perspective and might even > provide a unique "Look & Feel" to Ada apps. (People might then actually > *care* that their apps were done with Ada, eh?) Sure, but there are other things that the GUI to show that. My problem is that there are X GUIs and Y OSes out there already. > I've tinkered with GtkAda and - while it is a good and useful thing - > I can observe that there seem to be some features that Gtk has (under > Gnome?) that are simply not available through GtkAda. One might want > to use those features - but its either roll your own, wait for GtkAda > to catch up or go use C/C++ like the entire rest of the world does. > What do you suppose most programmers do? (Hint: Look at the relative > popularity of C/C++ to that of Ada.) Well if you look at the timespan for developing Gtk you'll see it isn't a trivial task. Making a binding is, however, much more trivial. > This is always the problem that Ada has with bindings, etc. It's > playing the "Me Too!!!!" catch-up game. The best you can hope for then > is to come in second-place. That's why Ada ought to be developing a > library of its own to supply a GUI and the other things that seem to > come along for the ride with C++ or Java. Yes I agree. But I want a container library +++ first. -- "Saving keystrokes is the job of the text editor, not the programming language." ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-19 13:37 ` Preben Randhol @ 2004-01-20 12:38 ` Marin David Condic 2004-01-20 17:31 ` Standard Ada Preprocessor (Was: why ada is so unpopular ?) Warren W. Gay VE3WWG [not found] ` <ldlq00hmnm7ofaqem3kkrt7qhf6o7kjfmj@4ax.com> 0 siblings, 2 replies; 296+ messages in thread From: Marin David Condic @ 2004-01-20 12:38 UTC (permalink / raw) Preben Randhol wrote: > > Well, who would be in charge of an Ada GUI and develop it actively and > not every 10-15 years ? > Who's in charge of Java's GUI? Do they update it only every 10 to 15 years? Why is it that Java can do it but Ada can't? (Besides lack of will.) Here's the point: Java can find a way to react quickly to a changing world and provide developers with tools to help them do their jobs with greater speed. Ada can't because of lack of will to do so. Who wins? (Hint: the answer is Java. ;-) > > Sure, but there are other things that the GUI to show that. My problem > is that there are X GUIs and Y OSes out there already. > How did Java manage to get a GUI that seems to be useful across a number of platforms? How did it succeed in something that looks so hopeless? Realistically, a GUI needs to support Windows and X-Windows (across a few different flavors of Unix) and it can cover 90% of the market. The rest? You say "Here is the GUI library in source - go make it work for yourself if you have to use something off-the-wall..." Ada has this "Portability Fetish" that often cripples it. "If we can't make a feature work on everything from a PC to a digital toaster then it can't be part of the language!" We solve that with some kind of library external to the standard that exists in source and works on some stated number of platforms and where it doesn't work - don't try to use it. The problem, of course, is to get the vendors to actually think that Ada *needs* something like this and exhibit the will & leadership to get it. > > Well if you look at the timespan for developing Gtk you'll see it isn't > a trivial task. Making a binding is, however, much more trivial. > I never said a GUI was a trivial task. What I said was that the C programmers are always going to get it *first* and its going to look the way *C programmers* want it to look. The Ada programmers will always get it later and will have to struggle with the usual C metaphors. As long as Ada depends on bindings for this sort of thing, Ada programmers are sucking hind tit. Developers ask themselves "Do I want to suck hind tit?" Generally the answer is "No!" and they go develop in C/C++ or Java. So long as Ada is in that ugly position, developers will stay away from it in droves. They'll go where they can get the most bang for the buck - and for the most part, that's not Ada. > > Yes I agree. But I want a container library +++ first. > I have absolutely no objection to a container library. However, we barely see any real will to get even *that* as a standard with the vendors lacking the leadership to get in front of the problem and say "Here's the answer that everyone should start to agree on..." I suppose if they want to lose the compiler-wars, that's up to them. Realistically, developers can look at Java and (to some extent) C++ and see that they are getting a whole lot more leverage by way of a library than they do with Ada. Your average uncommitted developer is going to see all that leverage and ask "So why is it I should go with some obscure, niche programming language that offers me less in the way of tools and I have to struggle by being incompatible with the whole rest of the universe? What do I get for this? An unquantified cost savings in maintenance ten years down the line and a few less bugs? My software doesn't live that long and I can tolerate a few bugs and what I gain in development leverage will easily outweigh the cost of fixing the bugs if I really need to." Its basically a no-brainer that is consistently demonstrated over and over again by the fact that developers are using languages other than Ada. The question is simple: "Do you want Ada to be around in ten years with a healthy, large user base?" If you'll settle for Ada being some niche language used in a few antique projects (like Jovial?) then it certainly can have that much strength. But if you want Ada to be a "Player" in the language market, then Ada had better start finding a way to offer *more* leverage to the developer than does its competitors. MDC -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-20 12:38 ` Marin David Condic @ 2004-01-20 17:31 ` Warren W. Gay VE3WWG 2004-01-20 18:50 ` Standard Ada Preprocessor Georg Bauhaus 2004-01-21 12:39 ` Standard Ada Preprocessor (Was: why ada is so unpopular ?) Marin David Condic [not found] ` <ldlq00hmnm7ofaqem3kkrt7qhf6o7kjfmj@4ax.com> 1 sibling, 2 replies; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-20 17:31 UTC (permalink / raw) Marin David Condic wrote: > Preben Randhol wrote: >> Well, who would be in charge of an Ada GUI and develop it actively and >> not every 10-15 years ? ... > Ada has this "Portability Fetish" that often cripples it. "If we can't > make a feature work on everything from a PC to a digital toaster then it > can't be part of the language!" We solve that with some kind of library > external to the standard that exists in source and works on some stated > number of platforms and where it doesn't work - don't try to use it. The > problem, of course, is to get the vendors to actually think that Ada > *needs* something like this and exhibit the will & leadership to get it. ... > MDC Portability of course is an important issue. This becomes even more important to Open Sourced projects, since they must be easy to compile and maintain for all/most flavours of UNIX, and different Windows environments (native and/or CYGWIN etc.) (I'll probably take some heat for this but..) In my opinion, the preprocessing of C code has made C the clear winner (and now C++) for portability. Examples of code that compiles and runs on the ancient Atari, BeOS, UNIX and Windows etc are not hard to find. Unless the Ada code is pretty much disconnected from the operating system, you won't find the same level of portability. Granted preprocessing results in ugly code. But it is pretty clear that developers prefer to maintain one source module, rather than trying to keep 10+ parallel modules synchronized (for each supported platform). It is certainly my preference to centralize maintenance. Any time you can centralize the control of something, maintenance becomes cleaner, and is forced to be consistent (much like database normalization). gnatprep obviously helps to address this issue for the "gnat world". But IMHO Ada could be well served if there was a standard for an Ada preprocessors. Its use of course would be optional (for the purests and those situations where it is not needed), but a standard would make Ada code more easily portable. Failing that, everyone must bake their own solution to this problem. Many maintain that by centralizing problem code into separate libraries works well enough. But this does not help in the cases where a product can be compiled with different options turned on or not (say from a Makefile). In other cases, it may mean enhancements involve maintenance of several parallel modules, instead of one centralized location. I havn't checked to see if any current discussions are taking place about the possibility of standardizing a preprocessor. But if were to guess, it has been discussed and summarily dismissed on religious grounds ;-) -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-20 17:31 ` Standard Ada Preprocessor (Was: why ada is so unpopular ?) Warren W. Gay VE3WWG @ 2004-01-20 18:50 ` Georg Bauhaus 2004-01-26 4:00 ` Peter Richtmyer 2004-02-01 15:09 ` Mark 2004-01-21 12:39 ` Standard Ada Preprocessor (Was: why ada is so unpopular ?) Marin David Condic 1 sibling, 2 replies; 296+ messages in thread From: Georg Bauhaus @ 2004-01-20 18:50 UTC (permalink / raw) Warren W. Gay VE3WWG <warren@ve3wwg.tk> wrote: : Portability of course is an important issue. This becomes even more : important to Open Sourced projects, since they must be easy to : compile and maintain for all/most flavours of UNIX, and different : Windows environments (native and/or CYGWIN etc.) "native and/or CYGWIN" is a distinction that IMO amounts to saying "not portable and/or portable", at least for your average C command line tool or X11 program. How would you compile a Unix program not using one of the Unix libraries/services provided with or for Windows? No preprocessor can help here, unless it magically provides a mapping from a cooperating sequence of API calls found in the Unix world to a cooperating sequence of APIs calls found in the Windows world. Or are you saying that Ada code shoud use #ifs all over the place, neglecting language features? IMHO, a program is portable if it uses *abstraction*, for example a good separation a la MVC. Abstraction is more easily expressed in a Ada than in CYGWIN's perceived "standard" language, I think. A program is not portable in this sense if it is a Unix command line tool and happens to run on top of a Unix layer, or if it is an X11 program and runs in the presence of an X server that has been ported to Windows. : Failing that, everyone must bake their own solution to this : problem. Many maintain that by centralizing problem code into : separate libraries works well enough. But this does not help : in the cases where a product can be compiled with different : options turned on or not (say from a Makefile). How could #ifs or text substitutions make any difference? If the maintenance has to happen in my head so to speak, that is if I have to know which #if surround what specialisation, I'd rather stay with my language and use what is provided for expressing a difference in a type's components say. Example struct _gna { int x; int y; #if defined(__S1__) int z; #else short z; #endif } *S; I don't see the advantage, even if the distinction appears "centralised" (?). : In other cases, : it may mean enhancements involve maintenance of several parallel : modules, instead of one centralized location. Why not use language means to check modules for compliance with the common requirements? "display help on topic_abc_123 in a dialogue window" could well be mapped to an abstract operation. -- Georg ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-20 18:50 ` Standard Ada Preprocessor Georg Bauhaus @ 2004-01-26 4:00 ` Peter Richtmyer 2004-01-26 5:01 ` tmoran 2004-01-26 12:01 ` Marin David Condic 2004-02-01 15:09 ` Mark 1 sibling, 2 replies; 296+ messages in thread From: Peter Richtmyer @ 2004-01-26 4:00 UTC (permalink / raw) I have not read the entire thread. Bottom lines for me: 1) too bad Ada does not have a preprocessor 2) I needed one, so I created one It has served me well for 4 years on Win2000, Solaris, HP/UX, and LynxOS. Not elegant but very useful to me, to take code home at night, develop/test on Win2000, then back to work with the same source code (preparsed) to continue to develop/test on Solaris (or other). I have included some files: PreProcess.pm -- the preprocessor PreCheck.pm -- checks for conditionals and some sample DOS batch files Use if you like, ignore otherwise :-) I hope it will help someone out there. Peter ======================== PreProcess.pm ========================== #!/usr/bin/perl -s package Devel::PreProcess; #IO: use IO::File; #use vars qw( $Conditionals $StripPreserve $StripDelete ); #use vars qw( $CMNT $CNDT $GenAda $fh $fhout $to_file $line_number ); $RETURN_CODE = 0; # code returned to system or caller # 0 - OK # -1 - Command Line option error. # -2 - Could not open the input file or none specified. # -3 - Could not open the output file or none specified. goto PAST_HELP; #### We put 'HELP' up here so you can see it easily. :-) PRINT_HELP: print <<"END_HELP"; Devel::PreProcess v 1.7 01/25/04 Generate conditional compile code for source code From a command line, sh> perl -s Devel/PreProcess.pm -Flags sourcefile > targetfile or sh> perl -s Devel/PreProcess.pm -Flags sourcefile [targetfile] Or in a Perl script, use Devel::PreProcess qw( Flags ); Devel::PreProcess::parse_file( $sourcefile [, $targetfile] ); DESCRIPTION This package processes source files and outputs a modified version according to several user-setable option flags, as detailed below. Each of the flag names listed below can be used as above, with a hyphen on the command line, or as one of the arguments in an import statement. Each of these flags are mapped to the scalar package variable of the same name. Option -Conditionals (True is the default) (Use Noconditionals to turn it off) If true, parse_file will utilize a simple conditional inclusion scheme, as follows. --#__COND__ if expr1 ... --#__COND__ elsif expr2 ... --#__COND__ else ... --#__COND__ endif The "elsif" line is optional, and there may be more than one such line. The "else" line is optional. The provided Perl expression (expr1) is evaluated, and unless it is true, everything up to the next conditional declaration is made into special comment lines ("--#"). If "false" then sucessive elsif conditionals, if preset, are evaluated as in any "if ... elsif ... else ... endif" logic. In addition, a single line may be conditional'd using the following format: --#{expr3} source code first line here; some more source code on second line; --#{expr4} When these expressions (expr3 and expr4) are evaluated, when True then the line will be output in the format of the second line above so that the Ada code is active. When an expression is False, then the output will be in the format of the second above. For example, lines below were preprocessed with "-demo" on command line: -- TESTING: this is demo line --#{$demo} --#{!$demo} -- TESTING: not a demo line WARNING: This does not work correctly in some environments unless there are spaces after the "}" and/or before the "--#" when at the end of a line. The conditional functionality can be combined with Perl's -s switch, which allows you to set flags on the command line, such as: perl -s Devel/PreProcess.pm -Switch filter.test You can use any name for your switch, and the matching scalar variable will be set true; the following code will only be used if you supply the argument as shown below. --#__COND__ if $Switch --# put_line ("you hit the switch!"); put_line ("so these two lines will be printed"); --#__COND__ endif If the Switch variable (entered on the command line as in the example above) is true then the output file will contain: --#__COND__ if $Switch put_line ("you hit the switch!"); put_line ("so these two lines will be printed"); --#__COND__ endif Thus, the two Ada lines of code will be compiled. If the Switch variable is false then the output file will contain: --#__COND__ if $Switch --# put_line ("you hit the switch!"); --# put_line ("so these two lines will be printed"); --#__COND__ endif Since the "if" and "elsif" conditions are Perl conditionals, they can be compound conditionals. Use "&&" for AND, "||" for OR, etc. And use the "!" for NOT. For example: --#__COND__ if ($green && ! ($apple || $pear)) In addition, the "if ... endif" blocks can be nested. In reality, it is legal to have white-space between the "--#" and the "__COND__" portions of a conditional statement. It should be noted that one of the strengths of this preprocessor is that the output from one "run" can be used as the input to the next run. For example, if code is being developed on two different computing environments (e.g. home and work), then the code can be generated using a "-home" switch. The code would be developed and tested some at home, with changes made. Then the code would be run through with the "-work" switch set, and development and test would continue on the same source code at work. Option -StripPreserve This option will cause all lines beginning with the Conditional Comment prefix ("--#" or its replacement using option "CMNT" described below) on the output side of the logic to be replaced with a blank line in the output stream. Option -StripDelete This option will cause all lines beginning with the Conditional Comment prefix ("--#" or its replacement) on the output side of the logic to be deleted, that is, not written to the output stream. Option -CMNT="comment-string" This option will replace the Conditional Comment string "--#" with the "comment-string" provided. Thus -CMNT="--$$$" would specify an alternative for conditional comment string for Ada, while -CMNT="#*#*" could be used to specify a conditional comment string when preparsing Perl source code. Option -CNDT="conditional-string" This option will replace the Conditional string "__COND__" with the "conditional-string" provided. This is the string that comes after the CMNT string to specify a line with "if", "elsif", "else" and "endif" statements. Option -LEFT="left-side" This option will replace the "{" as the string on the left side of a single-line conditional with "left-side" Option -RIGHT="right-side" This option will replace the "}" as the string on the right side of a single-line conditional with "right-side" So, if entered " -LEFT="{{" -RIGHT="}}" then the single-line conditionals would be similar to: --#{{expr5}} Care must be taken, certain special charaters need to be "escaped". For example, a left paren by itself will not work (you will get a program error). So: -LEFT="(" will not work, use -LEFT="\(" BUGS AND CAVEATS Option Flags -CMNT and -CNDT msy not work when calling from another Perl script. (Workaround: just make a separate copy of the pgm that has the desired defaults.) END_HELP exit ($RETURN_CODE); ################3############## Change History ################################# # ver date description # --- -------- --------------------------------------------------------------- # 1.7 01/25/04 Editorial changes only # 1.6 07/10/03 Minor pattern-matching change # 1.5 03/26/01 If the output is a directory, then use the same filename # as the input, for writing to the output directory. # 1.4b 11/07/00 Some clean-up, comments, deleted code, ... # 1.4a 9/26/00 Corrected "help" # 1.4 09/25/00 Had to make changes to work with perl5 on HP. # 1.3a 9/25/00 Documentation update only. No CODE changes. # 1.3 03/06/00 Adding the single-line conditional. --#{$test} # 1.2 02/28/00 Clean up. # # 1.1 02/27/00 Commenting out the "IO::File" logic with #IO: prefix and # replacing it with old-style I/O so I can run for now on systems # that do not have the IO package. # # 1.0 02/26/00 Original PAST_HELP: # # Change the variables below to change the "syntax" of the conditionals: # $CMNT = "--#"; $CNDT = "__COND__"; $LEFT = "{"; $RIGHT = "}"; # $Conditionals = 1; # @psuedo_INC - directories to search for modules #use vars qw( @psuedo_INC ); # really constants below - is there better way of making constants in Perl 5? #use vars qw( $EOF $ELSIF $ELSE $ENDIF ); $EOF = 1; $ELSIF = 2; $ELSE = 3; $ENDIF = 4; # %Importers - maps file inclusion keywords to their import methods #use vars qw( %Importers ); #%Importers = ( # 'require' => '', # 'use' => 'import', # 'no' => 'unimport', #); # Devel::PreProcessor->import( 'StripPreserve', 'Conditionals', ... ); sub import { my $package = shift; foreach ( @_ ) { if ( m/Conditionals/i ) { $Conditionals = 1; } elsif ( m/Noconditionals/i ) { ### PMR not tested yet $Conditionals = 0; ### PMR not tested yet } elsif ( m/h/i ) { goto PRINT_HELP; } elsif ( m/help/i ) { goto PRINT_HELP; } elsif ( m/StripPreserve/i ) { $StripPreserve = 1; } elsif ( m/StripDelete/i ) { $StripDelete = 1; } elsif ( m/LibPath:(.*)/i ) { @INC = split(/\:/, $1); } elsif ( m/CMNT=(.*)/) { ### PMR not tested yet $CMNT = $1; ### PMR not tested yet } elsif ( m/CNDT=(.*)/) { ### PMR not tested yet $CNDT = $1; ### PMR not tested yet } elsif ( m/RIGHT=(.*)/) { $RIGHT = $1; } elsif ( m/LEFT=(.*)/) { $LEFT = $1; } else { die "unkown import"; } } } # If we're being run from the command line, look for certain options # on the command line after program name. unless ( caller ) { goto PRINT_HELP if ( $main::help || $main::h ) ; goto PRINT_HELP if ( $main::Help || $main::H ) ; $Conditionals = 0 if ( $main::Noconditionals ); $Conditionals ||= $main::Conditionals; $StripPreserve ||= $main::StripPreserve; $StripDelete ||= $main::StripDelete; $CMNT = $main::CMNT if ($main::CMNT); $CNDT = $main::CNDT if ($main::CNDT); $LEFT = $main::LEFT if ($main::LEFT); $RIGHT = $main::RIGHT if ($main::RIGHT); my $in_source = shift @ARGV; # input filename my $out_source = shift @ARGV; # output filename parse_file ( $in_source, $out_source ); } # ------------------------------ parse_file ------------------------------------ # # Calling: parse_file ( $infilename [, $outfilename] ); # # This routine is called by the mainline above. But it can also be called # by an external program. # sub parse_file { # # before doing much, let's make sure that any overrides to conditional # matching variables are legal. # ## NEED to get this to work, and one for the {$test} if ( eval ("$line =~ /$CMNT\s*$CNDT/") ) { print "ERROR: You entered an illegal string for CMNT or CNDT \n"; print " CMNT='$CMNT', CNDT='$CNDT' \n"; print " Use a backslash '\\' before certain special characters. \n"; die "Try Again"; } my $infilename = shift; # the file to preparse #IO: $fh = IO::File->new($infilename); # global inputfile handle open ( INPUT, $infilename ) || die "Unable to open input file $infilename"; my $outfilename = shift; # the file to write to if ($outfilename) { # if output file specified # ----------------------------------------------------------- # if the output filename is a directory, just use it and # the input filename for the complete output name. # ----------------------------------------------------------- if (-d $outfilename) { @inparts = split(/[\\\/]/, $infilename); # split into parts separated by "\" or "/" $fname = $inparts[$#inparts]; # the last part is the input file name $outfilename .= "/$fname"; } #IO: $fhout = IO::File->new("> $outfilename"); # open output file open ( OUTPUT, "> $outfilename" ) || die "Unable to open output file $outfilename" ; $to_file = 1; # "writing to file" } else { # else $to_file = 0; # "writing to stdout" } my $top_eof = parse_block ( 1, 1 ); # parse entire file die "Program terminating before End-of-File - too many endif's ? " if ($top_eof != $EOF); } # ------------------------------ parse_block ------------------------------------- # # $rtn = parse_block ( $level, $GenAda ); # # Parses a "block" of code. If "$level" = 1, then this "block" is the entire file. # Since we always want to generate Ada for the file-level, $GenAda = 1 for level = 1. # While parsing lines in a block, if we find a "conditional if", then that is # the start of an embedded block, and this routine is called recursively to parse # that block. # # $rtn - these are the values that can be passed back from parse_block, and they # tell you why we returned from the routine. If not "EOF", then $_ has the # line of source code with the Conditional Commented statement, and it has # not been printed yet. # $EOF = 1; # $ELSIF = 2; # $ELSE = 3; # $ENDIF = 4; # sub parse_block { my $level = shift; # What level of recursion (1 = outermost) my $GenAda = shift; # Whether it is OK to generate Ada # out of cond-commented code LINE: while( 1 ) { # # Get a new line of code. If we hit eof, then return EOF. # #IO: return ($EOF) if (! defined ($_ = $fh->getline) ); return ($EOF) if (! ($_ = <INPUT>) ); $line_number ++; # # if this is a COND "endif", "elsif", or "else" then # return to previous block with the code for this line # return ($ENDIF) if ( $_ =~ /^\s*$CMNT\s*$CNDT\s*endif/i ); return ($ELSIF) if ( $_ =~ /^\s*$CMNT\s*$CNDT\s*elsif\s+/i ); return ($ELSE) if ( $_ =~ /^\s*$CMNT\s*$CNDT\s*else\s+/i ); # # If this line is a special conditional "if" # evaluate the conditional that is on the 'if' # write it if writeing cond comments # call this routine recursively with level nbr and conditional results # if ( $Conditionals && /^\s*$CMNT\s*$CNDT\s?(.*)$/i ) { my $conditional = $1; if ( $conditional =~ s/^if //i ) { write_if ("$_"); # write cond "if" line "as-is" (unless stripping) my $This_GenAda = eval "package main;\n$conditional"; my $We_Had_GenAda = 0; # # Why $We_Had_GenAda ? # If this "if block" turns out ot be a complex block such as "if-elsif-else" # Then we need to keep track of whether or not we have had one "true" # sub-block within it. After one true sub-block, all others must be false. # Once we have had that "true" sub-block, $We_Had_GenAda will = true. # SUB_BLOCK: while ( 1 ) { my $eob = parse_block ( ($level + 1), ($This_GenAda && $GenAda && (not $We_Had_GenAda )) ); $We_Had_GenAda = ($This_GenAda && $GenAda) || $We_Had_GenAda; die "End-of-File reached while in a Conditional Compile block" if ($eof); write_if ("$_"); # write line that ended block / sub-block next LINE if ($eob == $ENDIF); # done with entire block if ($eob == $ELSE) { $This_GenAda = ! $We_Had_GenAda; # set up this block GenAda #$This_GenAda = not $We_Had_GenAda; # set up this block GenAda next SUB_BLOCK; # parse the "else" subblock } die "Program error - bad EOB" if ($eob != $ELSIF); # Parse the "condition" part out of line and evaluate it true / false /^\s*$CMNT\s*$CNDT\s?elsif(.*)$/i; $conditional = "$1"; $This_GenAda = eval "package main;\n$conditional"; # will loop back to SUB_BLOCK and parse this "elsif" sub-block. } } else { print "$_"; die "conditional above is out of place"; } } # look for a single line conditional. local ($SCOND) = ""; local ($SLINE) = ""; if ( /^(\s*$CMNT\s*$LEFT.*$RIGHT)(.*)$/ ) { #print "TEMP found $1 in --#\${LEFT}xxxx\$RIGHT} line and $2 after it\n"; $SCOND = $1; $SLINE = $2; } if ( /^(.*)($CMNT\s*$LEFT.*$RIGHT\s*)$/ ) { #print "TEMP found '$1' before '$2' \n"; $SCOND = $2; chomp($SCOND); $SLINE = $1; } if ( $SCOND ) { $SCOND =~ /$CMNT\s*$LEFT(.*)$RIGHT/; if ( eval "package main;\n$1" ) { &write_if ("$SLINE $SCOND\n"); } else { &write_if ("$SCOND $SLINE\n"); } next LINE; } # # If we are in the outer level (not within a COND block), then we do not even # have to look at the line of code. Just write it (if..) # if ($level == 1) { # # We could make a check here for a "--$COMM" line. That would be a straggler, # outside of a conditional, so we could alert the officials about it. # write_if ("$_"); # local routine to write if OK to write next LINE; } # # $GenAda can only be true if we are processing conditionals and we found # a conditional that evaluated True. # ##print " \$GenAda = $GenAda \n"; if ($GenAda) { # # This line must NOT be a COND comment. If it is now, # then remove the COND part. # if ( /^\s*$CMNT(.*)$/i ) { write_if ("$1\n"); } else { write_if ("$_"); } next LINE; } # # If we are processing conditionals and this line should be commented out, # then make sure that it is a conditional comment before calling write routine. # #if ($Conditionals && not $GenAda) { if ($Conditionals && ! $GenAda) { if ( /^\s*$CMNT/ ) { write_if ("$_"); } else { write_if ("$CMNT$_"); } next LINE; } die "We found a condition that this humble programmer did not anticipate."; } # end loop } # end sub parse_block # --------------------------------------------------------------------------------------- #sub write_if ($line); # # write the line unless the "StripPreserve" or "StripDelete" flag is set # and this is a conditional comment. # sub write_if { $_ = shift; # if ( /^\s*$CMNT/ ) { # if a cond commment return if ($StripDelete); # delete the line if we are strip-deleting. if ($StripPreserve) { # if strip-replacing with blank line write_line ("\n"); # substitute a blank line return; # } # } # If this is NOT a comment, but has the "one-line" conditional at the right end # and we are stripping comments, Then we want to keep the line except for the # conditional at the right end. # if ( /^(.*) ($CMNT\s*$LEFT.*$RIGHT\s*)$/ ) { if ( $StripDelete || $StripPreserve ) { write_line ("$1\n"); return; } } write_line ("$_"); # write the line as-is } # --------------------------------------------------------------------------------------- # # Write it to stdout or the file (if specified). # sub write_line { my $line = shift; if ( $to_file ) { #IO: $fhout->print ($line); print OUTPUT "$line"; } else { print "$line"; } } #----------- 1; __END__ =head1 NAME Devel::PreProcess - Source code preprocessing. =head1 SYNOPSIS From a command line, sh> perl Devel/PreProcess.pm -Flags sourcefile > targetfile or sh> perl Devel/PreProcess.pm -Flags sourcefile [targetfile] Or in a Perl script, use Devel::PreProcess qw( Flags ); Devel::PreProcess::parse_file( $sourcefile [, $targetfile] ); =head1 DESCRIPTION This package processes source files and outputs a modified version according to several user-setable option flags, as detailed below. Each of the flag names listed below can be used as above, with a hyphen on the command line, or as one of the arguments in an import statement. Each of these flags are mapped to the scalar package variable of the same name. =over 4 =item Conditionals (True is the default) (Use Noconditionals to turn it off) If true, parse_file will utilize a simple conditional inclusion scheme, as follows. --#__COND__ if expr1 ... --#__COND__ elsif expr2 ... --#__COND__ else ... --#__COND__ endif The "elsif" line is optional, and there may be more than one such line. The "else" line is optional. The provided Perl expression (expr1) is evaluated, and unless it is true, everything up to the next conditional declaration is made into comment lines. If "false" then sucessive elsif conditionals, if preset, are evaluated as in any "if ... elsif ... else ... endif" logic. The conditional functionality can be combined with Perl's C<-s> switch, which allows you to set flags on the command line, such as: perl -s Devel/PreProcess.pm -Conditionals -Switch filter.test You can use any name for your switch, and the matching scalar variable will be set true; the following code will only be used if you supply the argument as shown below. --#__COND__ if $Switch --# put_line ("you hit the switch!"); put_line ("so these two lines will be printed"); --#__COND__ endif If the Switch variable is true then the output file will contain: --#__COND__ if $Switch put_line ("you hit the switch!"); put_line ("so these two lines will be printed"); --#__COND__ endif Thus, the two Ada lines of code will be compiled. If the Switch variable is false then the output file will contain: --#__COND__ if $Switch --# put_line ("you hit the switch!"); --# put_line ("so these two lines will be printed"); --#__COND__ endif Since the "if" and "elsif" conditions are Perl conditionals, they can be a compound conditional. Use "&&" for AND, "||" for OR, etc. For example: --#__COND__ if ($green && ($apple || $pear)) In addition, the "if ... endif" blocks can be nested. In reality, it is legal to have white-space between the "--#" and the "__COND__" portions of a conditional statement. =item StripPreserve This option will cause all lines beginning with the Conditional Comment prefix ("--#" or its replacement) on the output side of the logic to be replaced with a blank line in the output stream. =item StripDelete This option will cause all lines beginning with the Conditional Comment prefix ("--#" or its replacement) on the output side of the logic to be deleted, that is, not written to the output stream. =item CMNT="comment-string" This option will replace the Conditional Comment string "--#" with the "comment-string" provided. Thus -CMNT="--$$$" would specify an alternative for conditional comment string for Ada, while -CMNT="#*#*" could be used to specify a conditional comment string when preparsing Perl source code. =item CNDT="conditional-string" This option will replace the Conditional string "__COND__" with the "conditional-string" provided. This is the string that comes after the CMNT string to specify a line with "if", "elsif", "else" and "endif" statements. =back =head1 EXAMPLES =head1 BUGS AND CAVEATS Option Flags -CMNT and -CNDT may not work when calling from another Perl script. (Workaround: just make a separate copy of the pgm that has the desired defaults.) =head1 PREREQUISITES This package should run on standard Perl 5 installations, but may not run on earliest Perl 5 releases or incomplete installations. =head1 STATUS AND SUPPORT This release of Devel::PreProcess is intended primarily for limited private use. Not all options (especially "caller" options) have been tested. =head1 AUTHORS AND COPYRIGHT This program was adapted from a Devel::PreProcessor.pm from Evolution Online Systems, Inc. E<lt>www.evolution.comE<gt>, which had Copyright restrictions on it. It is felt that the changes to it are significant enought that the Copyright is not applicable. Nevertheless, credit is given to them for the basic program structure. Also, an email from them said it is OK to use it in this way. The modifications were made by Peter Richtmyer, RISYS, Portsmouth, RI. Others may use and modify it, just don't sell it or package it for sale. ============================= PreCheck.pm =============================== #!/usr/local/bin/perl -s package Devel::PreCheck; #IO: use IO::File; #use vars qw( $Conditionals $StripPreserve $StripDelete ); #use vars qw( $CMNT $CNDT $GenAda $fh $fhout $to_file $line_number ); $RETURN_CODE = 0; # code returned to system or caller # 0 - OK # -1 - Command Line option error. # -2 - Could not open the input file or none specified. # -3 - Could not open the output file or none specified. goto PAST_HELP; #### We put 'HELP' up here so you can see it easily. :-) PRINT_HELP: print <<"END_HELP"; Devel::PreCheck v 2.1 Check for conditional compile code in source code From a command line, sh> perl -s Devel/PreCheck.pm -Flags sourcefile Or in a Perl script, use Devel::PreProcess qw( Flags ); Devel::PreProcess::parse_file( $sourcefile ); DESCRIPTION This package processes source files and outputs a 0 - no conditional statements found 1 - found Each of the flag names listed below can be used as above, with a hyphen on the command line, or as one of the arguments in an import statement. Each of these flags are mapped to the scalar package variable of the same name. Option -Conditionals (True is the default) (Use Noconditionals to turn it off) If true, parse_file will utilize a simple conditional inclusion scheme, as follows. --#__COND__ if expr1 ... --#__COND__ elsif expr2 ... --#__COND__ else ... --#__COND__ endif The "elsif" line is optional, and there may be more than one such line. The "else" line is optional. The provided Perl expression (expr1) is evaluated, and unless it is true, everything up to the next conditional declaration is made into special comment lines ("--#"). If "false" then sucessive elsif conditionals, if preset, are evaluated as in any "if ... elsif ... else ... endif" logic. In addition, a single line may be conditional'd using the following format: --#{expr3} source code first line here; some more source code on second line; --#{expr4} When these expressions (expr3 and expr4) are evaluated, when True then the line will be output in the format of the second line above so that the Ada code is active. When an expression is False, then the output will be in the format of the second above. For example, lines below were preprocessed with "-demo" on command line: -- TESTING: this is demo line --#{$demo} --#{!$demo} -- TESTING: not a demo line WARNING: This does not work correctly in some environments unless there are spaces after the "}" and/or before the "--#" when at the end of a line. The conditional functionality can be combined with Perl's -s switch, which allows you to set flags on the command line, such as: perl -s Devel/PreProcess.pm -Switch filter.test You can use any name for your switch, and the matching scalar variable will be set true; the following code will only be used if you supply the argument as shown below. --#__COND__ if $Switch --# put_line ("you hit the switch!"); put_line ("so these two lines will be printed"); --#__COND__ endif If the Switch variable (entered on the command line as in the example above) is true then the output file will contain: --#__COND__ if $Switch put_line ("you hit the switch!"); put_line ("so these two lines will be printed"); --#__COND__ endif Thus, the two Ada lines of code will be compiled. If the Switch variable is false then the output file will contain: --#__COND__ if $Switch --# put_line ("you hit the switch!"); --# put_line ("so these two lines will be printed"); --#__COND__ endif Since the "if" and "elsif" conditions are Perl conditionals, they can be compound conditionals. Use "&&" for AND, "||" for OR, etc. And use the "!" for NOT. For example: --#__COND__ if ($green && ! ($apple || $pear)) In addition, the "if ... endif" blocks can be nested. In reality, it is legal to have white-space between the "--#" and the "__COND__" portions of a conditional statement. It should be noted that one of the strengths of this preprocessor is that the output from one "run" can be used as the input to the next run. For example, if code is being developed on two different computing environments (e.g. home and work), then the code can be generated using a "-home" switch. The code would be developed and tested some at home, with changes made. Then the code would be run through with the "-work" switch set, and development and test would continue on the same source code at work. Option -CMNT="comment-string" This option will replace the Conditional Comment string "--#" with the "comment-string" provided. Thus -CMNT="--$$$" would specify an alternative for conditional comment string for Ada, while -CMNT="#*#*" could be used to specify a conditional comment string when preparsing Perl source code. Option -CNDT="conditional-string" This option will replace the Conditional string "__COND__" with the "conditional-string" provided. This is the string that comes after the CMNT string to specify a line with "if", "elsif", "else" and "endif" statements. Option -LEFT="left-side" This option will replace the "{" as the string on the left side of a single-line conditional with "left-side" Option -RIGHT="right-side" This option will replace the "}" as the string on the right side of a single-line conditional with "right-side" So, if entered " -LEFT="{{" -RIGHT="}}" then the single-line conditionals would be similar to: --#{{expr5}} Care must be taken, certain special charaters need to be "escaped". For example, a left paren by itself will not work (you will get a program error). So: -LEFT="(" will not work, use -LEFT="\(" BUGS AND CAVEATS Option Flags -CMNT and -CNDT msy not work when calling from another Perl script. (Workaround: just make a separate copy of the pgm that has the desired defaults.) END_HELP exit ($RETURN_CODE); ################3############## Change History ################################# # ver date description # --- -------- ----------------------------------------------------------------- # 1.0 03/26/00 Original, copied from PreProcess.pm # 2.0 06/08/03 In addition to looking for a string like "--#__COND__" # at the beginning of a line, must also look for a # string like "--#{...}" at the beginning or end of a line. # 2.1 07/10/03 Minor pattern-matching change PAST_HELP: # # Change the variables below to change the "syntax" of the conditionals: # $CMNT = "--#"; $CNDT = "__COND__"; $LEFT = "{"; $RIGHT = "}"; # $Conditionals = 1; # @psuedo_INC - directories to search for modules #use vars qw( @psuedo_INC ); # %Importers - maps file inclusion keywords to their import methods #use vars qw( %Importers ); #%Importers = ( # 'require' => '', # 'use' => 'import', # 'no' => 'unimport', #); # Devel::PreProcessor->import( 'StripPreserve', 'Conditionals', ... ); sub import { my $package = shift; foreach ( @_ ) { if ( m/Conditionals/i ) { $Conditionals = 1; } elsif ( m/Noconditionals/i ) { ### PMR not tested yet $Conditionals = 0; ### PMR not tested yet } elsif ( m/h/i ) { goto PRINT_HELP; } elsif ( m/help/i ) { goto PRINT_HELP; } elsif ( m/LibPath:(.*)/i ) { @INC = split(/\:/, $1); } elsif ( m/CMNT=(.*)/) { ### PMR not tested yet $CMNT = $1; ### PMR not tested yet } elsif ( m/CNDT=(.*)/) { ### PMR not tested yet $CNDT = $1; ### PMR not tested yet } elsif ( m/RIGHT=(.*)/) { $RIGHT = $1; } elsif ( m/LEFT=(.*)/) { $LEFT = $1; } else { die "unkown import"; } } } # If we're being run from the command line, look for certain options # on the command line after program name. unless ( caller ) { goto PRINT_HELP if ( $main::help || $main::h ) ; goto PRINT_HELP if ( $main::Help || $main::H ) ; $Conditionals = 0 if ( $main::Noconditionals ); $Conditionals ||= $main::Conditionals; $CMNT = $main::CMNT if ($main::CMNT); $CNDT = $main::CNDT if ($main::CNDT); $LEFT = $main::LEFT if ($main::LEFT); $RIGHT = $main::RIGHT if ($main::RIGHT); my $in_source = shift @ARGV; # input filename parse_file ( $in_source ); } # ------------------------------ parse_file ------------------------------------ # # Calling: parse_file ( $infilename ); # # This routine is called by the mainline above. But it can also be called # by an external program. # sub parse_file { # # before doing much, let's make sure that any overrides to conditional # matching variables are legal. # ## NEED to get this to work, and one for the {$test} if ( eval ("$line =~ /$CMNT\s*$CNDT/") ) { print "ERROR: You entered an illegal string for CMNT or CNDT \n"; print " CMNT='$CMNT', CNDT='$CNDT' \n"; print " Use a backslash '\\' before certain special characters. \n"; die "Try Again"; } my $infilename = shift; # the file to preparse #IO: $fh = IO::File->new($infilename); # global inputfile handle #print ("open ( INPUT, $infilename ) \n"); open ( INPUT, $infilename ) || die "Unable to open input file $infilename"; while (<INPUT>) { # print "looking for $CMNT$CNDT in: $_\n"; if ( /^\s*$CMNT\s*$CNDT/i ) { print "Found conditional in: file $infilename \n"; close (INPUT); exit 1; # found conditional } # print "looking for $CMNT$LEFT...$RIGHT at beginning of: $_\n"; if ( /^(\s*$CMNT\s*$LEFT.*$RIGHT)(.*)$/ ) { print "Found conditional in: file $infilename \n"; close (INPUT); exit 1; # found conditional } print "looking for $CMNT$LEFT...$RIGHT at end of: $_\n"; if ( /^(.*)($CMNT\s*$LEFT.*$RIGHT\s*)$/ ) { print "Found conditional in: file $infilename \n"; close (INPUT); exit 1; # found conditional } } print "DID NOT FIND CONDITIONAL in FILE: $infilename \n"; close (INPUT); exit 0; # no conditionals found } #----------- 1; __END__ =head1 NAME Devel::PreProcess - Source code preprocessing. =head1 SYNOPSIS From a command line, sh> perl Devel/PreProcess.pm -Flags sourcefile > targetfile or sh> perl Devel/PreProcess.pm -Flags sourcefile [targetfile] Or in a Perl script, use Devel::PreProcess qw( Flags ); Devel::PreProcess::parse_file( $sourcefile [, $targetfile] ); =head1 DESCRIPTION This package processes source files and outputs a modified version according to several user-setable option flags, as detailed below. Each of the flag names listed below can be used as above, with a hyphen on the command line, or as one of the arguments in an import statement. Each of these flags are mapped to the scalar package variable of the same name. =over 4 =item Conditionals (True is the default) (Use Noconditionals to turn it off) If true, parse_file will utilize a simple conditional inclusion scheme, as follows. --#__COND__ if expr1 ... --#__COND__ elsif expr2 ... --#__COND__ else ... --#__COND__ endif The "elsif" line is optional, and there may be more than one such line. The "else" line is optional. The provided Perl expression (expr1) is evaluated, and unless it is true, everything up to the next conditional declaration is made into comment lines. If "false" then sucessive elsif conditionals, if preset, are evaluated as in any "if ... elsif ... else ... endif" logic. The conditional functionality can be combined with Perl's C<-s> switch, which allows you to set flags on the command line, such as: perl -s Devel/PreProcess.pm -Conditionals -Switch filter.test You can use any name for your switch, and the matching scalar variable will be set true; the following code will only be used if you supply the argument as shown below. --#__COND__ if $Switch --# put_line ("you hit the switch!"); put_line ("so these two lines will be printed"); --#__COND__ endif If the Switch variable is true then the output file will contain: --#__COND__ if $Switch put_line ("you hit the switch!"); put_line ("so these two lines will be printed"); --#__COND__ endif Thus, the two Ada lines of code will be compiled. If the Switch variable is false then the output file will contain: --#__COND__ if $Switch --# put_line ("you hit the switch!"); --# put_line ("so these two lines will be printed"); --#__COND__ endif Since the "if" and "elsif" conditions are Perl conditionals, they can be a compound conditional. Use "&&" for AND, "||" for OR, etc. For example: --#__COND__ if ($green && ($apple || $pear)) In addition, the "if ... endif" blocks can be nested. In reality, it is legal to have white-space between the "--#" and the "__COND__" portions of a conditional statement. =item StripPreserve This option will cause all lines beginning with the Conditional Comment prefix ("--#" or its replacement) on the output side of the logic to be replaced with a blank line in the output stream. =item StripDelete This option will cause all lines beginning with the Conditional Comment prefix ("--#" or its replacement) on the output side of the logic to be deleted, that is, not written to the output stream. =item CMNT="comment-string" This option will replace the Conditional Comment string "--#" with the "comment-string" provided. Thus -CMNT="--$$$" would specify an alternative for conditional comment string for Ada, while -CMNT="#*#*" could be used to specify a conditional comment string when preparsing Perl source code. =item CNDT="conditional-string" This option will replace the Conditional string "__COND__" with the "conditional-string" provided. This is the string that comes after the CMNT string to specify a line with "if", "elsif", "else" and "endif" statements. =back =head1 EXAMPLES =head1 BUGS AND CAVEATS Option Flags -CMNT and -CNDT msy not work when calling from another Perl script. (Workaround: just make a separate copy of the pgm that has the desired defaults.) =head1 PREREQUISITES This package should run on standard Perl 5 installations, but may not run on earliest Perl 5 releases or incomplete installations. =head1 STATUS AND SUPPORT This release of Devel::PreProcess is intended primarily for limited private use. Not all options (especially "caller" options) have been tested. =head1 AUTHORS AND COPYRIGHT This program was adapted from a Devel::PreProcessor.pm from Evolution Online Systems, Inc. E<lt>www.evolution.comE<gt>, which had Copyright restrictions on it. It is felt that the changes to it are significant enought that the Copyright is not applicable. Nevertheless, credit is given to them for the basic program structure. Also, an email from them said it is OK to use it in this way. The modifications were made by Peter Richtmyer, RISYS, Portsmouth, RI. Others may use and modify it, just don't sell it or package it for sale. ============================ BAT_PREP.BAT ================================ echo off REM BAT_PREP.BAT REM 03/26/01 REM 04/12/01 added .txt files for help template REM 11/07/01 added logic to create output dir if needed REM 06/08/03 chgd ".scr" to ".script" REM REM need to call this with at least two parameters: REM REM 1 = sending directory REM 2 = receiving directory REM 3 - 9 = (optional) the Perl variable names for preprocessing. REM REM for example: REM REM bat_prep D:\my_dir D:\my_dir2 -demo -gnat REM REM remember we do not WANT TO COPY .BAT FILES if not exist %1 echo #### ERROR in BAT_PREP.BAT, the Sending dir does not exist: %1 #### if not exist %1 pause call CREATE_DIR_IF_NEEDED %2 echo ABOUT TO COPY ALL .ada, .adb, .ads, .script, .txt gnat.* FROM %1 TO %2 CTL-C to QUIT pause rem the options like "-demo" must have a dash before them rem from %1 to %2 with booleans: %3 %4 %5 %6 %7 %8 %9 rem ARE YOU SURE? BACK UP FIRST????? rem echo about to copy all %1\*.txt to %2 rem pause copy %1\*.txt %2 rem echo about to copy all %1\*.script to %2 rem pause copy %1\*.script %2 rem echo about to copy all %1\gnat.* to %2 rem pause copy %1\gnat.* %2 PAUSE for %%f in (%1\*.ada %1\*.ads %1\*.adb) do call bat_chk_convert.bat %%f %2 %3 %4 %5 %6 %7 %8 %9 pause -- check results ========================= BAT_CHK_CONVERT.BAT ========================== echo off REM BAT_CHK_CONVERT.BAT REM 03/26/01 REM REM need to call this with at least two parameters: REM REM 1 = sending directory REM 2 = receiving directory REM 3 - 9 = (optional) the Perl variable names for preprocessing. REM REM for example: REM REM bat_chk_convert D:\my_dir D:\my_dir2 -demo -gnat REM rem the options like "-demo" must have a dash before them rem from %1 to %2 with booleans: %3 %4 %5 %6 %7 %8 %9 rem Note that we only want to preprocess if we have to. rem otherwise we use a "copy" command so the file date does not change. rem pause rem first see if there are any conditionals ("--#") in the file rem echo calling PreCheck.pm %3 %4 %5 %6 %7 %8 %9 %1 perl -s C:\perl\bin\PreCheck.pm %3 %4 %5 %6 %7 %8 %9 %1 if not errorlevel 1 goto copyfile rem echo PreProcess.pm %3 %4 %5 %6 %7 %8 %9 %1 %2 perl -s C:\perl\bin\PreProcess.pm %3 %4 %5 %6 %7 %8 %9 %1 %2 goto end :copyfile copy %1 %2 :end rem pause ======================= CREATE_DIR_IF_NEEDED.BAT ======================= echo off REM CREATE_DIR_IF_NEEDED.BAT REM REM 11/07/01 new REM REM need to call this with parameters REM REM 1 = directory to check, and add if it does not exist REM REM for example: REM REM call CREATE_DIR_IF_NEEDED D:\my_dir REM if not exist %1 echo Creating the output dir: %1 if not exist %1 mkdir %1 if not exist %1 echo #### ERROR: could not create output dir: %1 #### if not exist %1 pause ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-26 4:00 ` Peter Richtmyer @ 2004-01-26 5:01 ` tmoran 2004-01-26 12:01 ` Marin David Condic 1 sibling, 0 replies; 296+ messages in thread From: tmoran @ 2004-01-26 5:01 UTC (permalink / raw) >Lines: 1496 While appreciating the offer of the program, I really do prefer not to have exceedingly large ( > 100 line, say) newsgroup messages. Better to just post a link to a web site. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-26 4:00 ` Peter Richtmyer 2004-01-26 5:01 ` tmoran @ 2004-01-26 12:01 ` Marin David Condic 1 sibling, 0 replies; 296+ messages in thread From: Marin David Condic @ 2004-01-26 12:01 UTC (permalink / raw) Well, there you go. Ada doesn't provide a "standard" way to do it - perhaps out of some sense of technical purity. People still find it an attractive way to fix the problems they have maintaining things for two or more platforms. What do they do? They home-grow an answer that solves their problem (while not being portable) - or they go use a language that gives them what they want. MDC Peter Richtmyer wrote: > I have not read the entire thread. Bottom lines for me: > 1) too bad Ada does not have a preprocessor > 2) I needed one, so I created one > > It has served me well for 4 years on Win2000, Solaris, HP/UX, > and LynxOS. Not elegant but very useful to me, to take code > home at night, develop/test on Win2000, then back to work with the > same source code (preparsed) to continue to develop/test on Solaris > (or other). > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-20 18:50 ` Standard Ada Preprocessor Georg Bauhaus 2004-01-26 4:00 ` Peter Richtmyer @ 2004-02-01 15:09 ` Mark 2004-02-01 19:10 ` Frank J. Lhota 1 sibling, 1 reply; 296+ messages in thread From: Mark @ 2004-02-01 15:09 UTC (permalink / raw) late to the party and jumping in the middle of discussion [sorry] please see: http://www.digitalmars.com/d/index.html look for The C Preprocessor Versus D for a different approach to getting rid of the preprocessor but maintaining some of the primary usage. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-02-01 15:09 ` Mark @ 2004-02-01 19:10 ` Frank J. Lhota 2004-02-02 16:48 ` Martin Krischik 0 siblings, 1 reply; 296+ messages in thread From: Frank J. Lhota @ 2004-02-01 19:10 UTC (permalink / raw) "Mark" <prenom_nomus@yahoo.com> wrote in message news:c5b88987.0402010709.1d27a8a3@posting.google.com... > late to the party and jumping in the middle of discussion [sorry] > please see: > > http://www.digitalmars.com/d/index.html > look for The C Preprocessor Versus D > > for a different approach to getting rid of the preprocessor but > maintaining some of the primary usage. It's interesting to see the Ada concepts that have made it into D, including the use of in / out / in out parameter modes. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-02-01 19:10 ` Frank J. Lhota @ 2004-02-02 16:48 ` Martin Krischik 2004-02-02 18:22 ` Frank J. Lhota 0 siblings, 1 reply; 296+ messages in thread From: Martin Krischik @ 2004-02-02 16:48 UTC (permalink / raw) Frank J. Lhota wrote: > "Mark" <prenom_nomus@yahoo.com> wrote in message > news:c5b88987.0402010709.1d27a8a3@posting.google.com... >> late to the party and jumping in the middle of discussion [sorry] >> please see: >> >> http://www.digitalmars.com/d/index.html >> look for The C Preprocessor Versus D >> >> for a different approach to getting rid of the preprocessor but >> maintaining some of the primary usage. > > It's interesting to see the Ada concepts that have made it into D, > including the use of in / out / in out parameter modes. But the sad point is that D hasn't got ranges. With Regards Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-02-02 16:48 ` Martin Krischik @ 2004-02-02 18:22 ` Frank J. Lhota 0 siblings, 0 replies; 296+ messages in thread From: Frank J. Lhota @ 2004-02-02 18:22 UTC (permalink / raw) "Martin Krischik" <krischik@users.sourceforge.net> wrote in message news:1113821.JAX30lkfSv@linux1.krischik.com... > But the sad point is that D hasn't got ranges. ... but it does have array slices. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-20 17:31 ` Standard Ada Preprocessor (Was: why ada is so unpopular ?) Warren W. Gay VE3WWG 2004-01-20 18:50 ` Standard Ada Preprocessor Georg Bauhaus @ 2004-01-21 12:39 ` Marin David Condic 2004-01-21 13:12 ` Standard Ada Preprocessor Georg Bauhaus 2004-01-22 0:05 ` Standard Ada Preprocessor (Was: why ada is so unpopular ?) Robert I. Eachus 1 sibling, 2 replies; 296+ messages in thread From: Marin David Condic @ 2004-01-21 12:39 UTC (permalink / raw) While I find preprocessors distasteful and can see how they can become an unholy mess (look at some of that "Portable C" code to which you refer! :-) I'm afraid I'd have to agree to some extent. Ada ought to have some sort of answer for how to deal with maintaining a single body of code that has to compile for more than one environment. Even if you have the same target hardware and two different compilers (even from the same manufacturer sometimes!) you can have statements that will compile on one but not on the other. Isolation with separate bodies is sometimes difficult to do and always complicates the build process. Some form of conditional compilation would make the job easier. Naturally that has risks and can lead to all sorts of abuse. I'm not sure there is a good answer, but Ada ought to try to address it somehow. Eventually, developers need some scheme for how to deal with implementation differences and platform differences. To the extent that it can be handled via isolation in "standard" & "portable" interfaces, this is a good thing. But we've seen reluctance to do so for a variety of reasons, not the least of which is the time & expense to get those interfaces specified & implemented by the vendors. Even then, you'll have differences that can't be cleanly dealt with that still give full access to the underlying features of an OS or implementation. I'm not smart enough to figure out if there is a better answer than conditional compilation, so I'd have to agree that some sort of standard method of getting conditional compilation or preprocessing would be a good thing. MDC Warren W. Gay VE3WWG wrote: > > (I'll probably take some heat for this but..) > > In my opinion, the preprocessing of C code has made C the clear > winner (and now C++) for portability. Examples of code that > compiles and runs on the ancient Atari, BeOS, UNIX and Windows > etc are not hard to find. Unless the Ada code is pretty > much disconnected from the operating system, you won't find > the same level of portability. > > Granted preprocessing results in ugly code. But it is > pretty clear that developers prefer to maintain one > source module, rather than trying to keep 10+ parallel modules > synchronized (for each supported platform). > It is certainly my preference to centralize maintenance. > Any time you can centralize the control of something, > maintenance becomes cleaner, and is forced > to be consistent (much like database normalization). > > gnatprep obviously helps to address this issue for the "gnat > world". But IMHO Ada could be well served if there was a standard > for an Ada preprocessors. Its use of course would be optional > (for the purests and those situations where it is not needed), > but a standard would make Ada code more easily portable. > > Failing that, everyone must bake their own solution to this > problem. Many maintain that by centralizing problem code into > separate libraries works well enough. But this does not help > in the cases where a product can be compiled with different > options turned on or not (say from a Makefile). In other cases, > it may mean enhancements involve maintenance of several parallel > modules, instead of one centralized location. > > I havn't checked to see if any current discussions are > taking place about the possibility of standardizing a > preprocessor. But if were to guess, it has been discussed > and summarily dismissed on religious grounds ;-) > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-21 12:39 ` Standard Ada Preprocessor (Was: why ada is so unpopular ?) Marin David Condic @ 2004-01-21 13:12 ` Georg Bauhaus 2004-01-22 0:05 ` Standard Ada Preprocessor (Was: why ada is so unpopular ?) Robert I. Eachus 1 sibling, 0 replies; 296+ messages in thread From: Georg Bauhaus @ 2004-01-21 13:12 UTC (permalink / raw) Marin David Condic <nobody@noplace.com> wrote: : Even if you have the same target hardware and two different compilers : (even from the same manufacturer sometimes!) you can have statements : that will compile on one but not on the other. But then this is not an issue of program portability, but of compiler differences or compiler bugs. To some extent Source Code Versioning software and branches can help. : Isolation with separate : bodies is sometimes difficult to do and always complicates the build : process. Some form of conditional compilation would make the job easier. I'd prefer a conditional build process. IMHO, there should be a declarative language for build processes, integrated with one or more "source languages". ACE files (Eiffel), Project files (Ada), VCS integration/awareness etc. : Naturally that has risks and can lead to all sorts of abuse. If you keep the #ifs out of the code, and instead declare the target/compiler dependences in documents of their own right, to be processed by a configuration preprocessor, that risk isn't there, I think. -- Georg ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-21 12:39 ` Standard Ada Preprocessor (Was: why ada is so unpopular ?) Marin David Condic 2004-01-21 13:12 ` Standard Ada Preprocessor Georg Bauhaus @ 2004-01-22 0:05 ` Robert I. Eachus 2004-01-22 5:59 ` Randy Brukardt ` (2 more replies) 1 sibling, 3 replies; 296+ messages in thread From: Robert I. Eachus @ 2004-01-22 0:05 UTC (permalink / raw) Marin David Condic wrote: > Ada ought to have some sort of answer for how to deal with maintaining a > single body of code that has to compile for more than one environment. > Even if you have the same target hardware and two different compilers > (even from the same manufacturer sometimes!) you can have statements > that will compile on one but not on the other. Isolation with separate > bodies is sometimes difficult to do and always complicates the build > process. Some form of conditional compilation would make the job easier. Technically what we expected way back when was that users would write code that depended on the value of System.System_Name, which was made an Ada constant for just that reason. (Compilers could evaluate "if System.System_Name = VAX then..." at compile time to eliminate any overhead.) In practice, two things prevented that. First, vendors didn't list all supported systems in package System, usually just the one you were compiling for. But more important was that the Ada culture quickly became to avoid dependencies on System for any reason whatsoever. Now, we are where we are: ----------------------------------------------------------- with Ada.Text_IO; use Ada.Text_IO; with System; use System; procedure System_Names is package Name_IO is new Enumeration_IO(System.Name); begin Put(" The Available System Names are: "); for I in System.Name'Range loop Name_IO.Put(I); if I = System.Name'Last then Put_Line("."); else Put(", "); if Col > 60 then New_Line; end if; end if; end loop; New_Line; Put(" Current System.System_Name is: "); Name_IO.Put(System.System_Name); Put_Line("."); end System_Names; ----------------------------------------------------------- E:\Ada\Test>system_names system_names The Available System Names are: SYSTEM_NAME_GNAT. Current System.System_Name is: SYSTEM_NAME_GNAT. Is there any compiler that produces a useful output? Of course, with GNAT at least I can modify system and recompile it. But of course, the usual is to do the easier thing, and have some other system dependent package defined by the project will all the dependencies depending on that. But that forces projects to do the version control that should come from the compiler switches. (The code generator has to know enough about the target to patch up System. But for that to work the type System.Name has to contain a useful set of names.) Incidently this is the first program I have written in a while that had a bug not caught by the compiler. For some reason Are was capitalized in one of the message strings. ;-) -- Robert I. Eachus "The war on terror is a different kind of war, waged capture by capture, cell by cell, and victory by victory. Our security is assured by our perseverance and by our sure belief in the success of liberty." -- George W. Bush ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-22 0:05 ` Standard Ada Preprocessor (Was: why ada is so unpopular ?) Robert I. Eachus @ 2004-01-22 5:59 ` Randy Brukardt 2004-01-22 12:58 ` Marin David Condic 2004-01-22 14:13 ` Robert A Duff 2004-01-22 12:47 ` Marin David Condic 2004-01-22 13:19 ` Standard Ada Preprocessor Georg Bauhaus 2 siblings, 2 replies; 296+ messages in thread From: Randy Brukardt @ 2004-01-22 5:59 UTC (permalink / raw) "Robert I. Eachus" <rieachus@comcast.net> wrote in message news:LNOdncWFbKUojpLdRVn-uQ@comcast.com... > E:\Ada\Test>system_names > system_names > The Available System Names are: SYSTEM_NAME_GNAT. > > Current System.System_Name is: SYSTEM_NAME_GNAT. > > Is there any compiler that produces a useful output? Dunno. We used to have additional names in that enumeration, but I believe we removed the capability because of the ACVC. In Ada 83, you were supposed to be able to set the value of the System_Name (via a pragma, I believe) to any of the allowed choices. The best way to "avoid" that test was to have only one name in the enumeration. Then, the test couldn't do anything useful. Although that capability is long gone, I suppose implementers are sticking with the way it was back then. Besides, having all of your supported targets in the enumeration is a real maintenance headache. If you add or drop support for a target, you have to go modify System in all of the targets. Yuck. Randy. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-22 5:59 ` Randy Brukardt @ 2004-01-22 12:58 ` Marin David Condic 2004-01-22 17:25 ` Warren W. Gay VE3WWG 2004-01-23 2:47 ` Robert I. Eachus 2004-01-22 14:13 ` Robert A Duff 1 sibling, 2 replies; 296+ messages in thread From: Marin David Condic @ 2004-01-22 12:58 UTC (permalink / raw) And that only expands geometrically if you try to support enumerals for other vendor's implementations in order to be able to accept code built for their compilers. How about *adding* something to system like: System.Compiler_ID : constant String := "Something Useful Here" ; This would not break anything that was already using System_Name (although given its general uselessness, I doubt that is very much) and would provide a mechanism for identifying the compiler that is doing the job. Then statements like "if (Compiler_ID = "Something") then..." would possibly be useful. You still need some mechanism to wrap that around declarations and other stuff. Perhaps that could be solved with some flavor of a pragma that could take a case-like if statement around what you want conditionally compiled. Maybe the whole thing should be solved with a pragma since you don't want to have to first "with" System before you can start conditionally withing other packages. That also gets simpler to deal with from a language perspective since there has always been the ability to have implementation defined pragmas. MDC Randy Brukardt wrote: > > Besides, having all of your supported targets in the enumeration is a real > maintenance headache. If you add or drop support for a target, you have to > go modify System in all of the targets. Yuck. > > Randy. > > > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-22 12:58 ` Marin David Condic @ 2004-01-22 17:25 ` Warren W. Gay VE3WWG 2004-01-23 12:24 ` Marin David Condic 2004-01-23 2:47 ` Robert I. Eachus 1 sibling, 1 reply; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-22 17:25 UTC (permalink / raw) Marin David Condic wrote: > And that only expands geometrically if you try to support enumerals for > other vendor's implementations in order to be able to accept code built > for their compilers. > > How about *adding* something to system like: > > System.Compiler_ID : constant String := "Something Useful Here" ; > ... > You still need some mechanism to wrap that around declarations and other > stuff. Perhaps that could be solved with some flavor of a pragma that > could take a case-like if statement around what you want conditionally > compiled. Maybe the whole thing should be solved with a pragma since you > don't want to have to first "with" System before you can start > conditionally withing other packages. That also gets simpler to deal > with from a language perspective since there has always been the ability > to have implementation defined pragmas. > > MDC ... Not only do you have system(s) to worry about, you have version(s) of system(s), you have optionally installed component(s) and choice(s) in compiler(s) as well. If you are writing source code to accomodate these different variables, you have quite a source code issue on your hand. Here are a couple of examples: - Are you using: - GNU curses library? - the real UNIX curses library (or non BSD variant)? - are you using PDcurses library? - Does the user have (and want to use) the readline library? These are just two cases, which require you to configure your code. Blocks of code are unnecessary if no readline support exists. Whether you are using PDcurses, UNIX curses or GNU curses requires you to work around bugs and shortcomings in different ways. I havn't re-checked, but IIRC, Florist ends up generating a large portion of specs, and I suspect that bodies are probably "processed" as well. Any bindings related code, gets very quickly into the need for conditional compilation. Part of the Florist need for generated specs is due to the constants that must be ferreted out of C header files. But the other reason to #if is related to whether a particular API is even present on the platform of choice, and whether or not certain structures (records) are required. In bindings, you often run into optional structural components as well. The system call stat(2) for example uses a structure. But the members of that structure changes, depending upon the POSIX platform chosen. The only way to avoid this is to dumb it down so much that all platforms provide the same thing. But this doesn't work well with stat, because you'd have to dumb it down a lot, to achieve full portability - causing needed functionality to be lost. -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-22 17:25 ` Warren W. Gay VE3WWG @ 2004-01-23 12:24 ` Marin David Condic 2004-01-23 13:46 ` Dmitry A. Kazakov 0 siblings, 1 reply; 296+ messages in thread From: Marin David Condic @ 2004-01-23 12:24 UTC (permalink / raw) That's why much as I might find some kind of preprocessing distasteful and certainly don't want to watch it degenerate into the unholy mess that you have with C, I think we need *some* mechanism for conditional compilation. Those who argue that it should all be isolated with different package bodies have to address the fact that a) this is often difficult or impossible and b) it implies some kind of configuration management or build utilities that are totally outside the scope of the language and may not exist. I'd like to be able to hand off a collection of source code and say "This is the main program - just compile it from there on your machine..." If it involves different bodies, I've got to provide you with detailed build instructions and can't assume you've got the same tools as I do. All that gets fixed automagically if I could put some conditional compilation statements into the code that indicate which way to go based on some kind of directive to the compiler. (I don't trust something in the package System to be sufficient - that at best can only tell you about the compiler, but not necessarily about the external platform and its potential variations.) MDC Warren W. Gay VE3WWG wrote: > > Not only do you have system(s) to worry about, you have version(s) > of system(s), you have optionally installed component(s) and choice(s) > in compiler(s) as well. If you are writing source code to accomodate > these different variables, you have quite a source code issue on your > hand. Here are a couple of examples: > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-23 12:24 ` Marin David Condic @ 2004-01-23 13:46 ` Dmitry A. Kazakov 2004-01-23 17:16 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 296+ messages in thread From: Dmitry A. Kazakov @ 2004-01-23 13:46 UTC (permalink / raw) On Fri, 23 Jan 2004 12:24:31 GMT, Marin David Condic <nobody@noplace.com> wrote: >That's why much as I might find some kind of preprocessing distasteful >and certainly don't want to watch it degenerate into the unholy mess >that you have with C, I think we need *some* mechanism for conditional >compilation. > >Those who argue that it should all be isolated with different package >bodies have to address the fact that a) this is often difficult or >impossible ... different bodies which are not necessarily packages. If smaller units required there are subroutines for that. > and b) it implies some kind of configuration management or >build utilities that are totally outside the scope of the language and >may not exist. But the language defines the notion of a library. If we could extend it in a way allowing selection of a child units path during compilation, then I believe, it could be 80% of the issue. >I'd like to be able to hand off a collection of source code and say >"This is the main program - just compile it from there on your >machine..." If it involves different bodies, I've got to provide you >with detailed build instructions and can't assume you've got the same >tools as I do. All that gets fixed automagically if I could put some >conditional compilation statements into the code that indicate which way >to go based on some kind of directive to the compiler. (I don't trust >something in the package System to be sufficient - that at best can only >tell you about the compiler, but not necessarily about the external >platform and its potential variations.) If we could limit variations to compilation units, I think we could, then there might be a better way than preprocessing. We could invent some sort of abstract packages [units], providing some interface (types, values, procedures) without any implementation. So types and constants could be declared incomplete there. Then a set of normal compilation units could provide various platform/condition-specific implementations of an abstract unit. Using such an unit in "with", "use" etc should select an implementation at compile-time from the set of visible concrete units. That would be some sort of polymorphic compilation units. -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-23 13:46 ` Dmitry A. Kazakov @ 2004-01-23 17:16 ` Warren W. Gay VE3WWG 2004-01-23 17:52 ` Jeffrey Carter ` (3 more replies) 0 siblings, 4 replies; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-23 17:16 UTC (permalink / raw) Dmitry A. Kazakov wrote: > On Fri, 23 Jan 2004 12:24:31 GMT, Marin David Condic > <nobody@noplace.com> wrote: > >>That's why much as I might find some kind of preprocessing distasteful >>and certainly don't want to watch it degenerate into the unholy mess >>that you have with C, I think we need *some* mechanism for conditional >>compilation. >> >>Those who argue that it should all be isolated with different package >>bodies have to address the fact that a) this is often difficult or >>impossible ... >>and b) it implies some kind of configuration management or >>build utilities that are totally outside the scope of the language and >>may not exist. > > But the language defines the notion of a library. If we could extend > it in a way allowing selection of a child units path during > compilation, then I believe, it could be 80% of the issue. Whether the problem is 50% or 20% is not the issue. The problem is that even if I have a 2% problem, it is a _royal_pain_(TM). If you have to support different implementation defined pragmas, if you have to support optional record components (in bindings to OS services or to different C libraries like readline), then whether the problem is big or small, it is unsolved if it ain't 100% solved. >>I'd like to be able to hand off a collection of source code and say >>"This is the main program - just compile it from there on your >>machine..." If it involves different bodies, I've got to provide you >>with detailed build instructions and can't assume you've got the same >>tools as I do. All that gets fixed automagically if I could put some >>conditional compilation statements into the code that indicate which way >>to go based on some kind of directive to the compiler. (I don't trust >>something in the package System to be sufficient - that at best can only >>tell you about the compiler, but not necessarily about the external >>platform and its potential variations.) > > If we could limit variations to compilation units, I think we could, > then there might be a better way than preprocessing. As soon as you start splitting code into different parallel "files", you are denormalizing and decentralizing your code. This is maintenance hell. If you find a bug in one of these "portability" unique files, then you have to edit several files to effect the same fix. It also much more difficult to view the impact to other "platforms" for such a fix. Don't get me wrong. I support the push for a better solution, but I haven't seen any evidence of anything better than a conditional compile. Whether conditional compilation comes about by preprocessing or as part of the internal compile process, I don't care (compiler writers will care however). But I think that the lack of portability in Ada does hold it back for more general use. > We could invent some sort of abstract packages [units], providing some > interface (types, values, procedures) without any implementation. So > types and constants could be declared incomplete there. Then a set of > normal compilation units could provide various > platform/condition-specific implementations of an abstract unit. Using > such an unit in "with", "use" etc should select an implementation at > compile-time from the set of visible concrete units. That would be > some sort of polymorphic compilation units. MDC also pointed to the need sometimes to do conditional "with" in a compile. If I am using GNAT, I may need (or find it convenient) to use a GNAT.* package. If I use another Ada compiler, I may want to use some other vendor provided packages for similar functionality. Of course, depending upon what you "with", will also conditionally change what you want to compile. So in the end, there is a strong need for "conditional compiles". If we can agree on that, then let's leave preprocessing out of the discussion and focus on "conditional compilation". How that is achieved is an implementation issue. Again, perhaps conditional compilation should also be optional to placate those who will have no part in it ;-) (perhaps enabled by compile option). -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-23 17:16 ` Warren W. Gay VE3WWG @ 2004-01-23 17:52 ` Jeffrey Carter 2004-01-23 21:57 ` Warren W. Gay VE3WWG 2004-01-23 17:56 ` Larry Hazel ` (2 subsequent siblings) 3 siblings, 1 reply; 296+ messages in thread From: Jeffrey Carter @ 2004-01-23 17:52 UTC (permalink / raw) Warren W. Gay VE3WWG wrote: > > As soon as you start splitting code into different parallel "files", > you are denormalizing and decentralizing your code. This is > maintenance hell. If you find a bug in one of these "portability" > unique files, then you have to edit several files to effect the > same fix. It also much more difficult to view the impact to > other "platforms" for such a fix. C with preprocessor directives is also Maintenance Hell. I don't see that it's a better Hell. -- Jeff Carter "C++ is like jamming a helicopter inside a Miata and expecting some sort of improvement." Drew Olbrich 51 ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-23 17:52 ` Jeffrey Carter @ 2004-01-23 21:57 ` Warren W. Gay VE3WWG 2004-01-24 0:52 ` Jeffrey Carter ` (2 more replies) 0 siblings, 3 replies; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-23 21:57 UTC (permalink / raw) Jeffrey Carter wrote: > Warren W. Gay VE3WWG wrote: >> As soon as you start splitting code into different parallel "files", >> you are denormalizing and decentralizing your code. This is >> maintenance hell. If you find a bug in one of these "portability" >> unique files, then you have to edit several files to effect the >> same fix. It also much more difficult to view the impact to >> other "platforms" for such a fix. > > C with preprocessor directives is also Maintenance Hell. I don't see > that it's a better Hell. Given that it should be optional, it would not be your problem ;-) -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-23 21:57 ` Warren W. Gay VE3WWG @ 2004-01-24 0:52 ` Jeffrey Carter 2004-01-26 17:19 ` Warren W. Gay VE3WWG 2004-01-24 1:34 ` Standard Ada Preprocessor (Was: why ada is so unpopular ?) Marin David Condic 2004-01-24 8:20 ` Pascal Obry 2 siblings, 1 reply; 296+ messages in thread From: Jeffrey Carter @ 2004-01-24 0:52 UTC (permalink / raw) Warren W. Gay VE3WWG wrote: > Jeffrey Carter wrote: >> >> C with preprocessor directives is also Maintenance Hell. I don't see >> that it's a better Hell. > > Given that it should be optional, it would not be your problem ;-) So, I'll never have to look at poorly written SW again in my life? Where do I sign up? -- Jeff Carter "C++ is like giving an AK-47 to a monk, shooting him full of crack and letting him loose in a mall and expecting him to balance your checking account 'when he has the time.'" Drew Olbrich 52 ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-24 0:52 ` Jeffrey Carter @ 2004-01-26 17:19 ` Warren W. Gay VE3WWG 2004-01-27 12:24 ` Marin David Condic 0 siblings, 1 reply; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-26 17:19 UTC (permalink / raw) Jeffrey Carter wrote: > Warren W. Gay VE3WWG wrote: >> Jeffrey Carter wrote: >>> C with preprocessor directives is also Maintenance Hell. I don't see >>> that it's a better Hell. >> >> Given that it should be optional, it would not be your problem ;-) > > So, I'll never have to look at poorly written SW again in my life? Where > do I sign up? You of course, with tongue in cheek, read too much into that ;-) But this last statement of yours seems to imply: "conditionally compiled code = poorly written SW" If so, I would have to simply disagree. -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-26 17:19 ` Warren W. Gay VE3WWG @ 2004-01-27 12:24 ` Marin David Condic 2004-01-27 19:03 ` Standard Ada Preprocessor Georg Bauhaus 0 siblings, 1 reply; 296+ messages in thread From: Marin David Condic @ 2004-01-27 12:24 UTC (permalink / raw) Just about any language feature can be abused. What about Unchecked_Conversion? What about address clauses to achieve overlays? What about rep clauses in general? Any of these things (and more!) could be criticized as leading to "Bad Software Engineering" - but they serve a useful purpose and the developer is advised to use them judiciously. Anyone who spatters his code all over with conditional compilation directives isn't working to a proper design. But how would that be different than spattering the code all over with direct calls to an OS? Given that such style leads to lack of portability, should we disallow such a capability? Or perhaps we trust that the wise developer will isolate the OS dependencies down at some low level that is relatively easily replaced should the code move or OS change? Same with conditional compilation - trust that the wise developer will use it judiciously where it makes sense. MDC Warren W. Gay VE3WWG wrote: > > But this last statement of yours seems to imply: > > "conditionally compiled code = poorly written SW" > > If so, I would have to simply disagree. > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 12:24 ` Marin David Condic @ 2004-01-27 19:03 ` Georg Bauhaus 0 siblings, 0 replies; 296+ messages in thread From: Georg Bauhaus @ 2004-01-27 19:03 UTC (permalink / raw) Marin David Condic <nobody@noplace.com> wrote: : : What about address clauses to achieve overlays? : What about rep clauses in general? Any of these things (and more!) could : be criticized as leading to "Bad Software Engineering" - but they serve : a useful purpose and the developer is advised to use them judiciously. (Interestingly, Controlled types disallow overlays ;-) ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-23 21:57 ` Warren W. Gay VE3WWG 2004-01-24 0:52 ` Jeffrey Carter @ 2004-01-24 1:34 ` Marin David Condic 2004-01-26 17:27 ` Warren W. Gay VE3WWG 2004-01-24 8:20 ` Pascal Obry 2 siblings, 1 reply; 296+ messages in thread From: Marin David Condic @ 2004-01-24 1:34 UTC (permalink / raw) Having to maintain something that works on more than one environment is always some version of Hell. Given that we don't have one single computer architecture and one single OS and one single compiler, etc., there is *some* form of Hell we'll have to deal with. Conditional compilation may just be the least painful version of Hell in some circumstances. MDC Warren W. Gay VE3WWG wrote: > Jeffrey Carter wrote: >> >> C with preprocessor directives is also Maintenance Hell. I don't see >> that it's a better Hell. > > > Given that it should be optional, it would not be your problem ;-) -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-24 1:34 ` Standard Ada Preprocessor (Was: why ada is so unpopular ?) Marin David Condic @ 2004-01-26 17:27 ` Warren W. Gay VE3WWG 2004-01-27 12:30 ` Marin David Condic 0 siblings, 1 reply; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-26 17:27 UTC (permalink / raw) Marin David Condic wrote: > Having to maintain something that works on more than one environment is > always some version of Hell. Given that we don't have one single > computer architecture and one single OS and one single compiler, etc., > there is *some* form of Hell we'll have to deal with. Conditional > compilation may just be the least painful version of Hell in some > circumstances. > > MDC > > Warren W. Gay VE3WWG wrote: >> Jeffrey Carter wrote: >> >>> C with preprocessor directives is also Maintenance Hell. I don't see >>> that it's a better Hell. >> >> Given that it should be optional, it would not be your problem ;-) I would tend to agree. There is no "pure" way to make non-trivial code portable. If we go back to the "non-normalized database" metaphore, keeping separate versions of code for purity sake (to avoid conditional compilation), is like having to update a customer name in a database in 12 different tables. This potentially leads to leaving one instance of that name wrong, or left unchanged. Whereas, centralizing the affected code in one place (ugly or not), requires only one update to get it changed (like changing a name in a database in one centralized place). Again, I am not saying it has to be "preprocessing" because that is an implementation detail. I am also saying that it need not look like C's preprocessor #ifs. Choose something more elegant. -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-26 17:27 ` Warren W. Gay VE3WWG @ 2004-01-27 12:30 ` Marin David Condic 0 siblings, 0 replies; 296+ messages in thread From: Marin David Condic @ 2004-01-27 12:30 UTC (permalink / raw) Someone might come up with a tool that makes this relatively easy to manage and unlikely to get missed. I've not seen a tool that makes it totally painless or without the possibility of error. In any event, if such a tool did exist and managing separate source files was free (or really cheap) and it was damned near impossible to miss updating all the versions of the source, it would *still* not be an answer that the Ada developer could count on being in place everywhere he might send his code. In the days of "Open Source" - that ought to be a concern. MDC Warren W. Gay VE3WWG wrote: > > If we go back to the "non-normalized database" metaphore, keeping > separate versions of code for purity sake (to avoid conditional > compilation), is like having to update a customer name in a > database in 12 different tables. This potentially leads to > leaving one instance of that name wrong, or left unchanged. > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-23 21:57 ` Warren W. Gay VE3WWG 2004-01-24 0:52 ` Jeffrey Carter 2004-01-24 1:34 ` Standard Ada Preprocessor (Was: why ada is so unpopular ?) Marin David Condic @ 2004-01-24 8:20 ` Pascal Obry 2004-01-26 17:29 ` Warren W. Gay VE3WWG 2 siblings, 1 reply; 296+ messages in thread From: Pascal Obry @ 2004-01-24 8:20 UTC (permalink / raw) "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> writes: > Given that it should be optional, it would not be your problem ;-) It's also optional in C/C++ ... and AFAIK this is a problem for everybody :) Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://perso.wanadoo.fr/pascal.obry --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-24 8:20 ` Pascal Obry @ 2004-01-26 17:29 ` Warren W. Gay VE3WWG 0 siblings, 0 replies; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-26 17:29 UTC (permalink / raw) Pascal Obry wrote: > "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> writes: > >>Given that it should be optional, it would not be your problem ;-) > > It's also optional in C/C++ ... and AFAIK this is a problem for everybody :) > > Pascal. You have to go out of your way to turn it off in a C/C++ compile. In that sense, it is not optional. Another factor that gets into the way of optional use in C/C++, is the fact that the standard and system include files all *require* that preprocessing takes place. So in the normal C/C++ use, preprocessing is _not_ optional. But you knew that already ;-) -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-23 17:16 ` Warren W. Gay VE3WWG 2004-01-23 17:52 ` Jeffrey Carter @ 2004-01-23 17:56 ` Larry Hazel 2004-01-24 1:36 ` Marin David Condic 2004-01-23 22:14 ` Randy Brukardt 2004-01-26 9:34 ` Dmitry A. Kazakov 3 siblings, 1 reply; 296+ messages in thread From: Larry Hazel @ 2004-01-23 17:56 UTC (permalink / raw) Warren W. Gay VE3WWG wrote: > As soon as you start splitting code into different parallel "files", > you are denormalizing and decentralizing your code. This is > maintenance hell. If you find a bug in one of these "portability" > unique files, then you have to edit several files to effect the > same fix. It also much more difficult to view the impact to > other "platforms" for such a fix. Why is it more difficult to edit several files than several places in one file separated by some ugly conditional compilation directives. The code in the separate files would be much cleaner and easier to read. The only conditional compilation need I see is some way to select which body to use with a spec. > > Don't get me wrong. I support the push for a better solution, but > I haven't seen any evidence of anything better than a conditional > compile. Whether conditional compilation comes about by preprocessing > or as part of the internal compile process, I don't care (compiler > writers will care however). But I think that the lack of portability > in Ada does hold it back for more general use. > > MDC also pointed to the need sometimes to do conditional "with" in > a compile. If I am using GNAT, I may need (or find it convenient) > to use a GNAT.* package. If I use another Ada compiler, I may want > to use some other vendor provided packages for similar functionality. > Of course, depending upon what you "with", will also conditionally > change what you want to compile. You should "with" compiler specific units only in a body, so that shouldn't be a problem. > > So in the end, there is a strong need for "conditional compiles". > If we can agree on that, then let's leave preprocessing out of the > discussion and focus on "conditional compilation". How that is > achieved is an implementation issue. > > Again, perhaps conditional compilation should also be optional > to placate those who will have no part in it ;-) > (perhaps enabled by compile option). ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-23 17:56 ` Larry Hazel @ 2004-01-24 1:36 ` Marin David Condic 0 siblings, 0 replies; 296+ messages in thread From: Marin David Condic @ 2004-01-24 1:36 UTC (permalink / raw) It may not be the editing that is a pain but the build process that is a pain. Or at least the bigger pain. Since Ada can't promise you some kind of build process or CM environment, it can't do much to provide you with a *portable* solution to the problem. However, conditional compilation - ugly as it may be - is at least *portable*. MDC Larry Hazel wrote: > > Why is it more difficult to edit several files than several places in > one file separated by some ugly conditional compilation directives. The > code in the separate files would be much cleaner and easier to read. The > only conditional compilation need I see is some way to select which body > to use with a spec. -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-23 17:16 ` Warren W. Gay VE3WWG 2004-01-23 17:52 ` Jeffrey Carter 2004-01-23 17:56 ` Larry Hazel @ 2004-01-23 22:14 ` Randy Brukardt 2004-01-23 22:42 ` tmoran 2004-01-26 17:50 ` Warren W. Gay VE3WWG 2004-01-26 9:34 ` Dmitry A. Kazakov 3 siblings, 2 replies; 296+ messages in thread From: Randy Brukardt @ 2004-01-23 22:14 UTC (permalink / raw) "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message news:QEcQb.20015$cQ6.817492@news20.bellglobal.com... > Dmitry A. Kazakov wrote: > >>I'd like to be able to hand off a collection of source code and say > > If we could limit variations to compilation units, I think we could, > > then there might be a better way than preprocessing. > > As soon as you start splitting code into different parallel "files", > you are denormalizing and decentralizing your code. This is > maintenance hell. If you find a bug in one of these "portability" > unique files, then you have to edit several files to effect the > same fix. It also much more difficult to view the impact to > other "platforms" for such a fix. I have to agree with Dmitry. This is a configuration management problem, and an editor problem, not a language problem. There's no need to mess with the language here. We of course have this sort of problem managing the various versions of Janus/Ada. Existing version control systems didn't seem to address the problem in a useful way, in that they don't provide a way to get the most current files of a particular target, given that some files are shared, some are related, and some are unique. Tagging and branching just don't do the trick (tagging because that relates to specific versions of a file, wheras I want the most recent, and branching because it generally doesn't allow working on all of the branches at once, nor does it allow identifying which branch belongs to which app). So our solution was to build a wrapper around an existing version control system (originally was PVCS, now is CVS) to track the interelationships, allow grabbing the most recent version of everything (as well as specific tagged versions), and so on. We can get reports of related files changed in one version and not updated in another, so we can mostly avoid "the fix a bug in one version, but not in all versions" problem. But the real problem here is version control is at too large a granule. There is no reason for it to be done at the file level; it would be better to do it at the level of "pieces", where the actual file that is compiled is assembled out of pieces by the tools, and versioned separately. Then, even shared code within related files would change once, and the problems of different versions would be minimized. (If the change is in unshared code, there is no alternative to checking the other versions manually; that's true in a conditional compilation environment as well.) My conclusion is this a tools problem, not a language problem. The problem with Ada is immature programming systems, not a lack of conditional compilation. (And a lot of people who are unwilling to do better -- which of course is the same reason it is hard to get people to use Ada in the first place.) Randy Brukardt ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-23 22:14 ` Randy Brukardt @ 2004-01-23 22:42 ` tmoran 2004-01-26 17:50 ` Warren W. Gay VE3WWG 1 sibling, 0 replies; 296+ messages in thread From: tmoran @ 2004-01-23 22:42 UTC (permalink / raw) >But the real problem here is version control is at too large a granule. >There is no reason for it to be done at the file level; it would be better >to do it at the level of "pieces", where the actual file that is compiled is My impression (having never used it) was that the Rational environment offered that. If so, how did it work out? ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-23 22:14 ` Randy Brukardt 2004-01-23 22:42 ` tmoran @ 2004-01-26 17:50 ` Warren W. Gay VE3WWG 2004-01-26 18:54 ` Standard Ada Preprocessor Jeffrey Carter 2004-01-27 12:48 ` Standard Ada Preprocessor (Was: why ada is so unpopular ?) Marin David Condic 1 sibling, 2 replies; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-26 17:50 UTC (permalink / raw) Randy Brukardt wrote: > "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message > news:QEcQb.20015$cQ6.817492@news20.bellglobal.com... > >>Dmitry A. Kazakov wrote: >> >>>>I'd like to be able to hand off a collection of source code and say >>> >>>If we could limit variations to compilation units, I think we could, >>>then there might be a better way than preprocessing. >> >>As soon as you start splitting code into different parallel "files", >>you are denormalizing and decentralizing your code. This is >>maintenance hell. If you find a bug in one of these "portability" >>unique files, then you have to edit several files to effect the >>same fix. It also much more difficult to view the impact to >>other "platforms" for such a fix. > > I have to agree with Dmitry. This is a configuration management problem, and > an editor problem, not a language problem. There's no need to mess with the > language here. I would settle for a standard "precompiler tool", if one doesn't want to tinker with the language. For me, this matter is all moot anyway, because all that I am likely to use is gnatprep, lacking any other standard tool. However, having said that, there may be some advantages to integrating conditional compilation into the language. One of the problems that C/C++ has, is that you cannot do things like: #if sizeof(int) == 16 ... #else ... #endif This is just one example. Another might be to test the offset of a structure member, and add padding where necessary. The problem is that the preprocessor does not have the ability to evaluate size expressions. Ada projects may also have similar needs and more. Having a conditional compilation integrated into the language might provide some advanced portability features. Certainly integration like this would be an improvement in capability over other languages beginning with C ;-) And what I find amusing is that except for a few that appreciate this issue, we've heard of every ugly work-around possible, rather than face the issue square in the eye. This is just my opinion mind you, and perhaps small things amuse me ;-) It seems like a large number of people have this "Ada doesn't do it this way" attitude (otherwise known as "not invented here syndrome"). It kind of reminds me of the differences between Linux developers vs the *BSD ones. Both sides can learn from the other, but one side tends to look down on the other, and thus limits their thinking. (I won't say who ;-) As Ada stands now, it only serves the less portable embedded environment. If people truly do want to see wide-spread adoption of Ada, you will need to improve the portability to a level that competes well with C/C++. As for me, based upon what I have seen in this group, I'll just go on using gnatprep like I always have. The fact that ACT created this tool, and the fact that I and others use it, demonstrates a need that is not yet satisfied by the standard. -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-26 17:50 ` Warren W. Gay VE3WWG @ 2004-01-26 18:54 ` Jeffrey Carter 2004-01-26 21:53 ` Warren W. Gay VE3WWG 2004-01-27 12:48 ` Standard Ada Preprocessor (Was: why ada is so unpopular ?) Marin David Condic 1 sibling, 1 reply; 296+ messages in thread From: Jeffrey Carter @ 2004-01-26 18:54 UTC (permalink / raw) Warren W. Gay VE3WWG wrote: > #if sizeof(int) == 16 Ah, yes, 128-bit integers. Of course, this is not an issue in Ada, since we declare appropriate numeric types. > And what I find amusing is that except for a few that > appreciate this issue, we've heard of every ugly > work-around possible, rather than face the issue > square in the eye. This is just my opinion mind you, > and perhaps small things amuse me ;-) As someone who has faced the issue and never used a preprocessor, but has had to read code that does, I find a good design that hides the dependencies to be far more readable. Eachus has also faced the issue without using a preprocessor, with similar results. As the ARM says, Ada emphasizes "program readability over ease of writing". Preprocessors do the opposite. Preprocessors are a coder's solution; information hiding is a software engineer's solution. Perhaps to the question, "Do you like debugging?" which is very accurate at distinguishing coders from software engineers, we should add, "Do you like preprocessors?" -- Jeff Carter "I'm a lumberjack and I'm OK." Monty Python's Flying Circus 54 ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-26 18:54 ` Standard Ada Preprocessor Jeffrey Carter @ 2004-01-26 21:53 ` Warren W. Gay VE3WWG 2004-01-27 0:00 ` Robert I. Eachus 0 siblings, 1 reply; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-26 21:53 UTC (permalink / raw) Jeffrey Carter wrote: > Warren W. Gay VE3WWG wrote: > >> #if sizeof(int) == 16 > > Ah, yes, 128-bit integers. Of course, this is not an issue in Ada, since > we declare appropriate numeric types. Oops! Substitute 4 or 8 for 16! >> And what I find amusing is that except for a few that >> appreciate this issue, we've heard of every ugly >> work-around possible, rather than face the issue >> square in the eye. This is just my opinion mind you, >> and perhaps small things amuse me ;-) > > As someone who has faced the issue and never used a preprocessor, but > has had to read code that does, I find a good design that hides the > dependencies to be far more readable. Of course this is to be "preferred". > Eachus has also faced the issue > without using a preprocessor, with similar results. As the ARM says, Ada > emphasizes "program readability over ease of writing". Preprocessors do > the opposite. And two people's experience does not equate to "everyone's" ;-) > Preprocessors are a coder's solution; information hiding is a software > engineer's solution. Perhaps to the question, "Do you like debugging?" > which is very accurate at distinguishing coders from software engineers, > we should add, "Do you like preprocessors?" As said before, I prefer a portable platform neutral code as much as the next guy. But when you start writing bindings and such that must bind to _many_ different situations, this simply becomes impractical. -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-26 21:53 ` Warren W. Gay VE3WWG @ 2004-01-27 0:00 ` Robert I. Eachus 2004-01-27 17:30 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 296+ messages in thread From: Robert I. Eachus @ 2004-01-27 0:00 UTC (permalink / raw) Warren W. Gay VE3WWG wrote: > As said before, I prefer a portable platform neutral code > as much as the next guy. But when you start writing bindings > and such that must bind to _many_ different situations, > this simply becomes impractical. I feel here like I am being castigated for something I have never said. (No, I am not saying Warren is attacking me, just that I have the feeling that I am not getting my point across.) The problem is that there is an underlying philosophical difference, and until and unless you accept the "Ada" philosophy you will be uncomfortable programming in Ada. Once you "get it" Ada becomes as comfortable as well broken-in shoe. There are still some minor lumps and bumps--but you don't notice them. For a second assume that there are things that do require a preprocessor to do in Ada. Now look at the long debate here, from the point of view that one group uses preprocessor directives in with clauses and the public part of packages, while I argue that this is poor programming practice and that all preprocessor directives belong in unit bodies where possible, and as few such bodies as possible. And actually that IS the way I feel. With one minor exception. When you do the necessary work to collect all of the pre-processor decorated code in one spot, surprise! There isn't any left. But there is really a trick to this, and it is important to understand. In the military the problem is known as micro-management. Problems and issues should be addressed at the right level, without solutions imposed from above which may not be appropriate in a particular situation. In Ada where this often comes up is in representation clauses. You either tell the compiler to "do it right" with alignment directives, or lay things out bit-by-bit with rep clauses. If there is an implementation INdependent format you have to follow, sometimes because you are interfacing directly to some special-purpose hardware. Fine, use static layouts. But these are, by their nature not compiler dependent in any way. The hardware you interface with, or the other computer system you interface with, or whatever, specifies the layout. If some compiler can't support those rep clauses, it is not time for preprocessor directives, it is time to either fix the compiler or get a new one. The bits MUST look exactly like that, it is not an option. The second case is where you want the bits laid out a certain way for efficiency. Fine, no problem...and no rep clause required or needed. That is the compiler's job. You may use alignment clauses and specify that some components are aliased, but the compiler will take all that into account when it lays out the record. If two compilers do it differently on different hardware because, say, Integer is a different size? Not a problem. If you needed the records to be identical on different hardware, you would have specified things that way. So as far as I am concerned, the case of rep specs that compile on one compiler and not on another is almost uninteresting. If you care, it is a big problem. But it has to be fixed by fixing (or replacing) one compiler. A pre-processor CAN'T help. If you are trying to use pre-processor directives to force efficient layouts on each different platform, you are micro-managing. Let each compiler choose the layout it thinks is best. -- Robert I. Eachus "The war on terror is a different kind of war, waged capture by capture, cell by cell, and victory by victory. Our security is assured by our perseverance and by our sure belief in the success of liberty." -- George W. Bush ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 0:00 ` Robert I. Eachus @ 2004-01-27 17:30 ` Warren W. Gay VE3WWG 2004-01-27 20:55 ` Robert A Duff 2004-01-27 21:04 ` Randy Brukardt 0 siblings, 2 replies; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-27 17:30 UTC (permalink / raw) Robert I. Eachus wrote: > Warren W. Gay VE3WWG wrote: > >> As said before, I prefer a portable platform neutral code >> as much as the next guy. But when you start writing bindings >> and such that must bind to _many_ different situations, >> this simply becomes impractical. > > I feel here like I am being castigated for something I have never said. > (No, I am not saying Warren is attacking me, just that I have the > feeling that I am not getting my point across.) It could be argued that MDC, lurkers and I are not getting our point across ;-) > The problem is that there is an underlying philosophical difference, and > until and unless you accept the "Ada" philosophy you will be > uncomfortable programming in Ada. Once you "get it" Ada becomes as > comfortable as well broken-in shoe. There are still some minor lumps > and bumps--but you don't notice them. The "Ada phylosophy" works until you start interfacing to many foreign components (normally C ones) that cannot be relied upon to be the same. You cannot even rely on the same API to be available, in some cases. This is where things get real ugly. The practical side of many bindings, requires me to deal with portability issues in a "C wrapper". This may not always be entirely possible to avoid because of C macros, but I would like to put more code into Ada than into C. But I can't, because Ada cannot deal with the portability issues. That is, unless I resort to processes outside of the language (like gnatprep and code generation). I would just like people to look at some of the "practical" issues without resorting to quoting "ivory tower" notions. Again, all of this would be _optional_ anyway. The military can outlaw it for all I care, but for general purpose computing, it needs to be addressed. > For a second assume that there are things that do require a preprocessor > to do in Ada. Now look at the long debate here, from the point of view > that one group uses preprocessor directives in with clauses and the > public part of packages, while I argue that this is poor programming > practice and that all preprocessor directives belong in unit bodies > where possible, and as few such bodies as possible. I am not against any of these techniques. What I am against is the notion that "no, we don't do it that way because it might get abused". There is a need for it in the GP case, perhaps not in the military and embedded case. But if you're only going to do the later, than why add an Annex to deal with COBOL interfaces and features? > And actually that IS the way I feel. With one minor exception. When > you do the necessary work to collect all of the pre-processor decorated > code in one spot, surprise! There isn't any left. Point to some major open sourced work, where it can be compiled and installed on Win32, Linux and many flavours of *NIX, and I might believe this. Why is it that large portions of Florist is generated code? I know that C macros demand this, but what about the API issues? This says preprocessing all over it. > But there is really a trick to this, and it is important to understand. > In the military the problem is known as micro-management. Problems and > issues should be addressed at the right level, without solutions imposed > from above which may not be appropriate in a particular situation. The military can make its own rules and enforce them. But again, *sigh*, in the general purpose world, things need to be a bit more flexible. > In Ada where this often comes up is in representation clauses. You > either tell the compiler to "do it right" with alignment directives, or > lay things out bit-by-bit with rep clauses. If there is an > implementation INdependent format you have to follow, sometimes because > you are interfacing directly to some special-purpose hardware. Fine, > use static layouts. But these are, by their nature not compiler > dependent in any way. The hardware you interface with, or the other > computer system you interface with, or whatever, specifies the layout. > If some compiler can't support those rep clauses, it is not time for > preprocessor directives, it is time to either fix the compiler or get a > new one. The bits MUST look exactly like that, it is not an option. If you are binding to an API that returns a structure, and on one platform you get 3 members back, and on another you get 5, then just how is any Ada construct going to address this? What if the order of member placement is different? These are the kind of portability issues that Ada programmers must wrestle with when binding to existing code. > The second case is where you want the bits laid out a certain way for > efficiency. Fine, no problem...and no rep clause required or needed. > That is the compiler's job. You may use alignment clauses and specify > that some components are aliased, but the compiler will take all that > into account when it lays out the record. If two compilers do it > differently on different hardware because, say, Integer is a different > size? Not a problem. If you needed the records to be identical on > different hardware, you would have specified things that way. Again, you look at the simple cases where everything is the same. When dealing with portability issues, you are looking at representation issues where the interfaces are DIFFERENT. > So as far as I am concerned, the case of rep specs that compile on one > compiler and not on another is almost uninteresting. If you care, it is > a big problem. But it has to be fixed by fixing (or replacing) one > compiler. A pre-processor CAN'T help. If you are trying to use > pre-processor directives to force efficient layouts on each different > platform, you are micro-managing. Let each compiler choose the layout > it thinks is best. Your examples _are_ uninteresting. The interesting ones are the ones that differ according to platform, platform version, and the choice of library(ies) used. -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 17:30 ` Warren W. Gay VE3WWG @ 2004-01-27 20:55 ` Robert A Duff 2004-01-27 22:03 ` Robert I. Eachus 2004-01-28 12:28 ` Marin David Condic 2004-01-27 21:04 ` Randy Brukardt 1 sibling, 2 replies; 296+ messages in thread From: Robert A Duff @ 2004-01-27 20:55 UTC (permalink / raw) "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> writes: > The "Ada phylosophy" works until... I'm rather skeptical of talk about "Ada philosophy". I agree with you and MDC that the issue is a very practical one. It's all well and good to recommend encapsulating system dependencies in package bodies and so forth. But you still need some mechanism to select which body to use in each case. I don't see any advantage to using make-file hackery for that, over using #ifdef's. The fact that some C programs are ugly due to overuse of #ifdefs is not a good reason to outlaw preprocessors. First of all, scattering #ifdefs all over the place is not necessary, even in C, given a good design. Second, if Ada had a preprocessor, it wouldn't be used as in C: to define enumeration types, to write pragma-inline functions, to write generics. It would be used sparingly. > I would just like people to look at some of the "practical" > issues without resorting to quoting "ivory tower" notions. I agree. > I am not against any of these techniques. What I am against > is the notion that "no, we don't do it that way because it > might get abused". I agree. The language designer's job is to prevent mistakes, not to prevent deliberate abuse. - Bob ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 20:55 ` Robert A Duff @ 2004-01-27 22:03 ` Robert I. Eachus 2004-01-28 12:28 ` Marin David Condic 1 sibling, 0 replies; 296+ messages in thread From: Robert I. Eachus @ 2004-01-27 22:03 UTC (permalink / raw) Robert A Duff wrote: > I'm rather skeptical of talk about "Ada philosophy". I agree with you > and MDC that the issue is a very practical one. It's all well and good > to recommend encapsulating system dependencies in package bodies and so > forth. But you still need some mechanism to select which body to use in > each case. I don't see any advantage to using make-file hackery for > that, over using #ifdef's. I completely and totally agree. One of the things I love about Ada is the ability to avoid messing around with makefiles. But this again totally misses what I keep saying about Ada pre-processors. I don't avoid them intentionally. It is just that if I get to the body of one of these implementation dependent packages, I usually write it using ifs and case statements planning to convert to #ifdefs later if needed. This allows me to use one Ada compiler to (compile-time) debug the Ada code completely. But once it compiles cleanly I don't switch to pre-processor directives for the fun of it. I wait until I need it. I'm still waiting... If your experience is different, fine. But why are we arguing? I never said that Ada compilers shouldn't support pre-processors, or that they shouldn't be used. I just suggested waiting until it is needed. I'm going to get back to work on some Ada code I hope to post soon. Again, if it needs a pre-processor to make it portable, I'll use one. But I don't expect it to happen. Now if you think there should be a STANDARD Ada pre-processor, that is fine with me as well. Just don't expect the ARG to develop the standard, form a PRG or whatever instead. The ARG already has enough to do. >>I am not against any of these techniques. What I am against >>is the notion that "no, we don't do it that way because it >>might get abused". Definitely not my position. I am the typical engineer. I work very hard at being lazy. So I will use whatever tools make my life easier. In this case, my "ivory tower notion" is that if I can do it in Ada, or with a pre-processor, I'll do it in Ada, even if it takes a little more design effort up front. I know that when I am deep into schedule pressure and design changes I will thank myself. -- Robert I. Eachus "The war on terror is a different kind of war, waged capture by capture, cell by cell, and victory by victory. Our security is assured by our perseverance and by our sure belief in the success of liberty." -- George W. Bush ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 20:55 ` Robert A Duff 2004-01-27 22:03 ` Robert I. Eachus @ 2004-01-28 12:28 ` Marin David Condic 2004-01-28 20:55 ` Simon Wright 2004-01-30 16:52 ` Pascal Obry 1 sibling, 2 replies; 296+ messages in thread From: Marin David Condic @ 2004-01-28 12:28 UTC (permalink / raw) The hiding of system/target/compiler dependent stuff in a body is all well and good. (I'm not convinced that it can *always* be hidden in a body and even if it can, that's another layer of indirection that sometimes starts posing unnecessary overhead for applications that might care about that.) Sure, isolate it in a body. Write a monograph about how to hide compiler, target, OS, and other platform dependencies in a body. I'll try to follow it. Now give me a way to select *which* body I want via some standard compiler mechanism that I can count on having available. Shell scripts, makefiles or other build process mechanisms are simply pushing *that* problem off in another layer of indirection - and its a non-portable, uncertain layer at that. MDC Robert A Duff wrote: > > I'm rather skeptical of talk about "Ada philosophy". I agree with you > and MDC that the issue is a very practical one. It's all well and good > to recommend encapsulating system dependencies in package bodies and so > forth. But you still need some mechanism to select which body to use in > each case. I don't see any advantage to using make-file hackery for > that, over using #ifdef's. > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-28 12:28 ` Marin David Condic @ 2004-01-28 20:55 ` Simon Wright 2004-01-29 12:40 ` Marin David Condic 2004-01-30 16:52 ` Pascal Obry 1 sibling, 1 reply; 296+ messages in thread From: Simon Wright @ 2004-01-28 20:55 UTC (permalink / raw) Marin David Condic <nobody@noplace.com> writes: > Sure, isolate it in a body. Write a monograph about how to hide > compiler, target, OS, and other platform dependencies in a > body. I'll try to follow it. Now give me a way to select *which* > body I want via some standard compiler mechanism that I can count on > having available. Shell scripts, makefiles or other build process > mechanisms are simply pushing *that* problem off in another layer of > indirection - and its a non-portable, uncertain layer at that. I'm probably missing the point here, but as I recall the C side of things has a humungous incomprehensible heap of autoconf, m4, shell scripts, GNU make only, imake .. people are happy enough with that, where's the problem on the Ada side in selecting the right source file variant? I've just added support for arrays to my UML-to-Ada generator, under pressure. I _know_ I'm going to regret it, people are just bound to decide to (eg) implement their own associations using them rather than rely on the built-ins .. if you give people a bad feature they will use it badly. Of course the market rules here, shame really .. -- Simon Wright 100% Ada, no bugs. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-28 20:55 ` Simon Wright @ 2004-01-29 12:40 ` Marin David Condic 2004-01-29 18:08 ` Jeffrey Carter 2004-01-29 20:45 ` Simon Wright 0 siblings, 2 replies; 296+ messages in thread From: Marin David Condic @ 2004-01-29 12:40 UTC (permalink / raw) Well, let's sum it up this way: Its possible to have a given statement that works in environment A but not in B. For B you need an alternate statement. The decision has to be made at compile time because its the compiler that rejects the statement, so you can't wait until runtime and look at some configuration parameter to decide which statement to use. That leaves you with these choices: 1) Have the two alternate lines in the same file & let the compiler decide (based on some condition) which to actually read & interpret. 2) Build your own pre-processor because the compiler writers won't do the job in a standard way for you - but this is really no different than having the compiler decide. Its still indicating in the source code which line to compile. 2) Have the two alternate lines in two alternate files and let the build process decide which to actually send to the compiler. (Substitute the word "line" for "file" and you see the problem is identical - just using different mechanisms for which line to let the compiler try to interpret.) You aren't fundamentally changing the problem - just where it will be dealt with. If the argument against conditional compilation is that it will make ugly, incomprehensible code, then that same argument goes against the build process. It is, after all, some set of instructions that will be obeyed by the computer and hence a kind of programming language, so giving *it* the responsibility is just going to result in ugly, incomprehensible code at the build level. Only it won't be portable and you can't count on it being there and someone who doesn't know what's going on with the different bodies of code is likely to bugger it up. Not to mention the other related maintenance problems such as not having all the code relating to one specific conceptual function in one place - the "unnormalized database" situation described (I think) by Warren. So worrying about adding a feature that has the potential to be abused is, in my mind, a non-starter. The feature *will* be added *somewhere* so long as people have to manage code that must work in more than one environment. One camp says "Your life will be so much better if only you push that problem off to the build process level rather than the source code level." Another camp says "I've been there and done that and I think that at least some of the time, I'd rather deal with that problem at the source code level". The problem is inherently unpleasant no matter which way you go. But you *will* have to deal with it and IMHO, *sometimes* I want to deal with it at the source code level because it creates the fewest headaches for me. The fact that someone might abuse it is also a non-starter. People can abuse *anything* in a programming language. (Look at the religious wars over using something like the predefined type "Integer" - some think its handy and convenient and others think it is apostasy and should never be used at all under any circumstances. Yet its in the language and Ada programs are probably still better built on average than those in some other languages. Life goes on in an imperfect world.) MDC Simon Wright wrote: > > I'm probably missing the point here, but as I recall the C side of > things has a humungous incomprehensible heap of autoconf, m4, shell > scripts, GNU make only, imake .. people are happy enough with that, > where's the problem on the Ada side in selecting the right source file > variant? > > I've just added support for arrays to my UML-to-Ada generator, under > pressure. I _know_ I'm going to regret it, people are just bound to > decide to (eg) implement their own associations using them rather than > rely on the built-ins .. if you give people a bad feature they will > use it badly. Of course the market rules here, shame really .. > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-29 12:40 ` Marin David Condic @ 2004-01-29 18:08 ` Jeffrey Carter 2004-01-30 12:30 ` Marin David Condic 2004-01-29 20:45 ` Simon Wright 1 sibling, 1 reply; 296+ messages in thread From: Jeffrey Carter @ 2004-01-29 18:08 UTC (permalink / raw) Marin David Condic wrote: > You aren't fundamentally changing the problem - just where it will be > dealt with. If the argument against conditional compilation is that it > will make ugly, incomprehensible code, then that same argument goes > against the build process. It is, after all, some set of instructions > that will be obeyed by the computer and hence a kind of programming > language, so giving *it* the responsibility is just going to result in > ugly, incomprehensible code at the build level. There's a general SW engineering principle called localization. You don't lump your code for dealing with a 4-line LCD display in with the code for dealing with a temperature sensor just because they're both hardware. Similarly, you shouldn't want your code for doing something platform dependent on one platform lumped in with your code for another platform, nor your code for doing things lumped in with your code for deciding which code to use for this build. Separating concerns this way makes everything easier to understand. I can look at the code for dealing with a VMS file system without having to understand the code for selecting a VMS file system; I can look at the code for selecting the file system without having to look at the code for dealing with file systems. That said, it would be nice to have a standard, portable way to select different bodies for a build, but even without it, the advantages of separating these independent concerns seem clear. -- Jeff Carter "Many times we're given rhymes that are quite unsingable." Monty Python and the Holy Grail 57 ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-29 18:08 ` Jeffrey Carter @ 2004-01-30 12:30 ` Marin David Condic 0 siblings, 0 replies; 296+ messages in thread From: Marin David Condic @ 2004-01-30 12:30 UTC (permalink / raw) I don't think I've ever said that it was "bad" to localize dependencies and try to isolate this stuff. Quite the contrary. But if you could scatter system dependencies all over the code or scatter conditional compilation all over the code, why couldn't it be done all over the whole system, just at the file level? Why couldn't a project of 100 files have 50 for one system and 50 for another system and not have anything "localized" in that sense? So my contention is that it can be abused no matter where you push the problem. Often system dependencies are *not* isolated - people write code all the time that works for only one system. Good, bad or somewhere in between - its still done. Offering some kind of conditional compilation doesn't really change that much. That said, I'd be inclined to agree that perhaps the problem could be solved with some portable means of selecting different bodies for a build. Its a reasonable compromise that at least tends to encourage isolation of dependencies at some appropriate level. I don't know that it solves *every* problem, but it probably fixes enough of them that the rest wouldn't matter much. Remember that one of the big strengths of Ada is its assistance on making *portable* code by providing strong *standard* mechanisims for dealing with system dependencies. Everything from specifying numeric accuracy up through tasking is an attempt to say "If the implementation is compliant to the standard, you go compile for the platform and your code will work." Providing a mechanism for dealing with compile-time dependencies is just going down that same path a little further. MDC Jeffrey Carter wrote: > > There's a general SW engineering principle called localization. You > don't lump your code for dealing with a 4-line LCD display in with the > code for dealing with a temperature sensor just because they're both > hardware. Similarly, you shouldn't want your code for doing something > platform dependent on one platform lumped in with your code for another > platform, nor your code for doing things lumped in with your code for > deciding which code to use for this build. > > Separating concerns this way makes everything easier to understand. I > can look at the code for dealing with a VMS file system without having > to understand the code for selecting a VMS file system; I can look at > the code for selecting the file system without having to look at the > code for dealing with file systems. > > That said, it would be nice to have a standard, portable way to select > different bodies for a build, but even without it, the advantages of > separating these independent concerns seem clear. > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-29 12:40 ` Marin David Condic 2004-01-29 18:08 ` Jeffrey Carter @ 2004-01-29 20:45 ` Simon Wright 2004-01-29 23:12 ` Randy Brukardt 2004-01-30 12:36 ` Marin David Condic 1 sibling, 2 replies; 296+ messages in thread From: Simon Wright @ 2004-01-29 20:45 UTC (permalink / raw) Marin David Condic <nobody@noplace.com> writes: > 1) Have the two alternate lines in the same file & let the compiler > decide (based on some condition) which to actually read & interpret. The point I was fumbling towards is that you now have _two_ complicated things, probably: * the external autoconf or whatever setup that decides from the environment whether some feature is present and sets the result in environment variables, a config.h or a makefile; * and the source code that uses the condition. -S ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-29 20:45 ` Simon Wright @ 2004-01-29 23:12 ` Randy Brukardt 2004-01-30 13:09 ` Marin David Condic 2004-01-30 12:36 ` Marin David Condic 1 sibling, 1 reply; 296+ messages in thread From: Randy Brukardt @ 2004-01-29 23:12 UTC (permalink / raw) "Simon Wright" <simon@pushface.org> wrote in message news:x7visiufpr5.fsf@smaug.pushface.org... > Marin David Condic <nobody@noplace.com> writes: > > > 1) Have the two alternate lines in the same file & let the compiler > > decide (based on some condition) which to actually read & interpret. > > The point I was fumbling towards is that you now have _two_ > complicated things, probably: > > * the external autoconf or whatever setup that decides from the > environment whether some feature is present and sets the result in > environment variables, a config.h or a makefile; > > * and the source code that uses the condition. Right. There is no such thing as a compile-time solution that doesn't change some code or management artifact like build scripts. If you're using conditional compilation, you have to set the choice of which to use somewhere. You're going to have to manage that code or scripts with some form of configuration management per configuration. You cannot avoid this part of the problem on anything but the tiniest one-person projects (where you might actually be able to remember a bucket of special command-line switches - but as I get older, I find I can't even do that anymore...). So, given that you have a solution to the managment of separate code/build scripts, why would you not apply it to managing separate specs and bodies? And clearly, separate implementation-dependent code is always preferable (and don't forget that subunits also can be used to keep implementation-dependent stuff separate). There are cases where Ada's existing conditional compilation doesn't work (or makes the code much harder to read), but they're rare enough that going further is a very tough sell. Randy. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-29 23:12 ` Randy Brukardt @ 2004-01-30 13:09 ` Marin David Condic 2004-01-30 18:06 ` Jeffrey Carter 0 siblings, 1 reply; 296+ messages in thread From: Marin David Condic @ 2004-01-30 13:09 UTC (permalink / raw) That's a fair point. No matter what you do, you'll have to have some kind of "outside the language" mechanism for specifying which path you want to go down and that isn't under the control of the language. But do consider this: Something like "gnatmake" has pretty much eliminated for me needing to worry about build scripts in most situations. The *language* goes out and figures out what is out of date and what needs to be included in the build. So long as I can point to a single pile of files and say "there's a build in there somewhere - you go figure it out...", Ada does a marvelous job with it. Compared to C, this is a major improvement in many respects. So it might not be that much of a stretch to ask something like gnatmake to go decide which way to branch in selecting files from two or more alternate paths within that pile of files. Something as simple as saying 'gnatmake -buildstring="Go Down Path A"' might be sufficient so long as there was some way of picking up the "Path A" variants of files via some language mechanism so that I knew I could take the same pile of files and hand them off to Janus Ada or Aonix or any other compliant compiler and know that someone with little familiarity with my pile of code could use minimal instructions and direct an appropriate build for his platform. It all goes to enhancing Ada's ability to be "The Portability Language". It already does so much in that respect that I think its a shame it can't seem to find a way to get around the fact that no two compilers or environments are ever going to be identical. "Outside The Language" solutions exist - but then we're no better than C (or other languages) in that regard. In some ways worse since at least C provides a (maybe at times ugly) way of directing the compiler down alternate paths. MDC Randy Brukardt wrote: > > Right. There is no such thing as a compile-time solution that doesn't change > some code or management artifact like build scripts. If you're using > conditional compilation, you have to set the choice of which to use > somewhere. You're going to have to manage that code or scripts with some > form of configuration management per configuration. You cannot avoid this > part of the problem on anything but the tiniest one-person projects (where > you might actually be able to remember a bucket of special command-line > switches - but as I get older, I find I can't even do that anymore...). So, > given that you have a solution to the managment of separate code/build > scripts, why would you not apply it to managing separate specs and bodies? > And clearly, separate implementation-dependent code is always preferable > (and don't forget that subunits also can be used to keep > implementation-dependent stuff separate). > > There are cases where Ada's existing conditional compilation doesn't work > (or makes the code much harder to read), but they're rare enough that going > further is a very tough sell. > > Randy. > > > > > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-30 13:09 ` Marin David Condic @ 2004-01-30 18:06 ` Jeffrey Carter 2004-01-31 8:11 ` Marin David Condic 0 siblings, 1 reply; 296+ messages in thread From: Jeffrey Carter @ 2004-01-30 18:06 UTC (permalink / raw) Marin David Condic wrote: > So it might not be that much of a stretch to ask something like gnatmake > to go decide which way to branch in selecting files from two or more > alternate paths within that pile of files. Something as simple as saying > 'gnatmake -buildstring="Go Down Path A"' might be sufficient so long as > there was some way of picking up the "Path A" variants of files via some > language mechanism so that I knew I could take the same pile of files > and hand them off to Janus Ada or Aonix or any other compliant compiler > and know that someone with little familiarity with my pile of code could > use minimal instructions and direct an appropriate build for his platform. There was a posting on gnatlist today about the -X switch to GNAT and the use of project files to accomplish this. One can declare different lists of source directories, each associated with a meaningful identifier. One can then specify an identifier to -X and GNAT will use that list of source directories. This is not portable, but it may serve as a good basis for defining something that could become standard. -- Jeff Carter "Whatever it is, I'm against it." Horse Feathers 46 ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-30 18:06 ` Jeffrey Carter @ 2004-01-31 8:11 ` Marin David Condic 0 siblings, 0 replies; 296+ messages in thread From: Marin David Condic @ 2004-01-31 8:11 UTC (permalink / raw) That there is an implemented answer at least gives people something to try and then throw stones at. I kind of like the fact that Gnat seems to not be afraid to experiment with practical solutions & see how well or poorly they operate in the real world. It might even be a place to implement some kind of conditional compilation within files and test it out. :-) MDC Jeffrey Carter wrote: > > There was a posting on gnatlist today about the -X switch to GNAT and > the use of project files to accomplish this. One can declare different > lists of source directories, each associated with a meaningful > identifier. One can then specify an identifier to -X and GNAT will use > that list of source directories. > > This is not portable, but it may serve as a good basis for defining > something that could become standard. > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-29 20:45 ` Simon Wright 2004-01-29 23:12 ` Randy Brukardt @ 2004-01-30 12:36 ` Marin David Condic 1 sibling, 0 replies; 296+ messages in thread From: Marin David Condic @ 2004-01-30 12:36 UTC (permalink / raw) I never said it was pretty. :-) I just said that the problem of dealing with compiler dependencies, environment dependencies and system dependencies is real and that we don't seem to have a really good portable answer to it sometimes. I'm suggesting there might be something the language could do to make dealing with that easier - if not prettier. I'm open to suggestions. MDC Simon Wright wrote: > > The point I was fumbling towards is that you now have _two_ > complicated things, probably: > > * the external autoconf or whatever setup that decides from the > environment whether some feature is present and sets the result in > environment variables, a config.h or a makefile; > > * and the source code that uses the condition. > > -S -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-28 12:28 ` Marin David Condic 2004-01-28 20:55 ` Simon Wright @ 2004-01-30 16:52 ` Pascal Obry 2004-01-31 8:25 ` Marin David Condic 1 sibling, 1 reply; 296+ messages in thread From: Pascal Obry @ 2004-01-30 16:52 UTC (permalink / raw) Marin, > The hiding of system/target/compiler dependent stuff in a body is all well > and good. (I'm not convinced that it can *always* be hidden in a body and > even if it can, that's another layer of indirection that sometimes starts > posing unnecessary overhead for applications that might care about that.) Pragma Inline could be used to avoid that. > Sure, isolate it in a body. Write a monograph about how to hide compiler, > target, OS, and other platform dependencies in a body. I'll try to follow > it. Now give me a way to select *which* body I want via some standard > compiler mechanism that I can count on having available. :) You know that this is not portable. Ada has nothing to do with file system and configuration management. > Shell scripts, makefiles or other build process mechanisms are simply > pushing *that* problem off in another layer of indirection - and its a > non-portable, uncertain layer at that. I do this with a makefile, lot of GNU software are doing that from a configure script. Using ClearCase you can use a specific view for the target/OS/hardward whatever you want the view to me... But I repeat this is not a compiler issue but a Configuration Management one. Use the on that best fits for your project. Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://perso.wanadoo.fr/pascal.obry --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-30 16:52 ` Pascal Obry @ 2004-01-31 8:25 ` Marin David Condic 0 siblings, 0 replies; 296+ messages in thread From: Marin David Condic @ 2004-01-31 8:25 UTC (permalink / raw) You mean like when the compiler is supposed to detect that a specification is out of date and recompile whatever depends on it? :-) Let's be practical. Ada specifies things that require some kind of "Outside The Source File" action to take place. Its not technically impossible or outside the bounds of a language standard to do that. You could write a rule that said some logical name or function would exist that an implementation is required to get a string into at compile time and that the string could be used for conditional compilation via a pragma or some other mechanism. There could be ways of specifying within the language how to connect different filenames to different packages just like there's a mechanism to associate an Ada logical package name with some actual file right now. The exact details of how a user does it from the outside might not be portable - but then neither is the means of invoking the Ada compiler on some set of files right now. MDC Pascal Obry wrote: > > > :) You know that this is not portable. Ada has nothing to do with file system > and configuration management. > > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 17:30 ` Warren W. Gay VE3WWG 2004-01-27 20:55 ` Robert A Duff @ 2004-01-27 21:04 ` Randy Brukardt 2004-01-28 12:42 ` Marin David Condic 1 sibling, 1 reply; 296+ messages in thread From: Randy Brukardt @ 2004-01-27 21:04 UTC (permalink / raw) "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message news:XdxRb.49218$Kg6.359124@news20.bellglobal.com... ... > The "Ada phylosophy" works until you start interfacing to many > foreign components (normally C ones) that cannot be relied upon > to be the same. You cannot even rely on the same API to be > available, in some cases. This is where things get real ugly. > > The practical side of many bindings, requires me to deal > with portability issues in a "C wrapper". This may not always > be entirely possible to avoid because of C macros, but I > would like to put more code into Ada than into C. But I > can't, because Ada cannot deal with the portability issues. > That is, unless I resort to processes outside of the language > (like gnatprep and code generation). I've always thought that CM really needs to be applied on a per-line basis. That is, you should be able to branch individual lines of a source file. Clearly, such a system must be integrated with an editor, and should be able to cleanly handle multiple versions of a system. With such a system, you could cleanly manage any sort of differences without making the source code harder to read. It's unfortunate that such systems have never appeared in use. Randy. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 21:04 ` Randy Brukardt @ 2004-01-28 12:42 ` Marin David Condic 0 siblings, 0 replies; 296+ messages in thread From: Marin David Condic @ 2004-01-28 12:42 UTC (permalink / raw) That would be nice. It would be even nicer if it was done in some manner that one could expect to exist on at least some wide variety of platforms. The thing is that it *isn't* available at the moment - or at least not in a practical way. Some kind of conditional compilation is not difficult to implement and *could* be available in short order. (Doesn't even really need the ARG - just an agreement by most of the vendors to use some mechanism like a pragma. The hypothetical line-level CM might even work by *generating* the pragma {or whatever} around the code.) So we could A) wait around for the world to become perfect or b) do something that gets a sub-optimal answer available in a reasonable timeframe. You could guess which I'd prefer. :-) MDC Randy Brukardt wrote: > > > I've always thought that CM really needs to be applied on a per-line basis. > That is, you should be able to branch individual lines of a source file. > Clearly, such a system must be integrated with an editor, and should be able > to cleanly handle multiple versions of a system. > > With such a system, you could cleanly manage any sort of differences without > making the source code harder to read. It's unfortunate that such systems > have never appeared in use. > > Randy. > > > > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-26 17:50 ` Warren W. Gay VE3WWG 2004-01-26 18:54 ` Standard Ada Preprocessor Jeffrey Carter @ 2004-01-27 12:48 ` Marin David Condic 1 sibling, 0 replies; 296+ messages in thread From: Marin David Condic @ 2004-01-27 12:48 UTC (permalink / raw) Warren W. Gay VE3WWG wrote: > > And what I find amusing is that except for a few that > appreciate this issue, we've heard of every ugly > work-around possible, rather than face the issue > square in the eye. This is just my opinion mind you, > and perhaps small things amuse me ;-) > Perhaps it starts from noble intentions. There are certainly a large number of cases where a C programmer might dive into conditional compilation when a more "pure" approach might yield an answer that is more elegant and less subject to errors. But having decided from such examples that "Conditional Compilation = Evil" we then see increasingly complex, difficult to implement and (often) non-portable and inefficient schemes to try to work around not having it. After a while you start wondering "what was it I was trying to avoid with all these gyrations and was it really so bad???" > > As Ada stands now, it only serves the less portable > embedded environment. If people truly do want to see > wide-spread adoption of Ada, you will need to > improve the portability to a level that competes > well with C/C++. > Remember that when it comes to embedded systems, "Ada" ranks below "Other" in choice of programming language. Somehow, Ada failed to pay attention to the embedded customer and got profoundly ignored in return. So having blown that market - probably permanently - it should likely not worry so much about that market and concentrate on others. Having said that, I'd dispute that embeded computing has any less need for portability than any other area. Perhaps at times even more need for portability. You're often trying to write code that will work with off-line simulations, prototype boards, different variants of production boards, multiple versions of RTOS's, etc. Further, because these systems might hang around for many generations of hardware, they have to be adaptable to change. So yes, I get to worry a whole lot about portability of code. ;-) > As for me, based upon what I have seen in this group, > I'll just go on using gnatprep like I always have. The > fact that ACT created this tool, and the fact that I > and others use it, demonstrates a need that is not yet > satisfied by the standard. Since tools *are* invented to do this sort of thing regularly, it would be nice to have a *standard* set of tools one could count on having in place. People find a way of getting what they want. Sometimes its done by switching languages. MDC -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-23 17:16 ` Warren W. Gay VE3WWG ` (2 preceding siblings ...) 2004-01-23 22:14 ` Randy Brukardt @ 2004-01-26 9:34 ` Dmitry A. Kazakov 2004-01-26 19:23 ` Randy Brukardt 3 siblings, 1 reply; 296+ messages in thread From: Dmitry A. Kazakov @ 2004-01-26 9:34 UTC (permalink / raw) On Fri, 23 Jan 2004 12:16:20 -0500, "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote: >Dmitry A. Kazakov wrote: >> On Fri, 23 Jan 2004 12:24:31 GMT, Marin David Condic >> <nobody@noplace.com> wrote: >> >>>That's why much as I might find some kind of preprocessing distasteful >>>and certainly don't want to watch it degenerate into the unholy mess >>>that you have with C, I think we need *some* mechanism for conditional >>>compilation. >>> >>>Those who argue that it should all be isolated with different package >>>bodies have to address the fact that a) this is often difficult or >>>impossible >... >>>and b) it implies some kind of configuration management or >>>build utilities that are totally outside the scope of the language and >>>may not exist. >> >> But the language defines the notion of a library. If we could extend >> it in a way allowing selection of a child units path during >> compilation, then I believe, it could be 80% of the issue. > >Whether the problem is 50% or 20% is not the issue. The problem is >that even if I have a 2% problem, it is a _royal_pain_(TM). If you >have to support different implementation defined pragmas, if you have >to support optional record components (in bindings to OS services >or to different C libraries like readline), then whether the >problem is big or small, it is unsolved if it ain't 100% solved. Mmm, you know, we are happily working with a finite subset of rational numbers, which represent 0% of all reals. >>>I'd like to be able to hand off a collection of source code and say >>>"This is the main program - just compile it from there on your >>>machine..." If it involves different bodies, I've got to provide you >>>with detailed build instructions and can't assume you've got the same >>>tools as I do. All that gets fixed automagically if I could put some >>>conditional compilation statements into the code that indicate which way >>>to go based on some kind of directive to the compiler. (I don't trust >>>something in the package System to be sufficient - that at best can only >>>tell you about the compiler, but not necessarily about the external >>>platform and its potential variations.) >> >> If we could limit variations to compilation units, I think we could, >> then there might be a better way than preprocessing. > >As soon as you start splitting code into different parallel "files", >you are denormalizing and decentralizing your code. This is >maintenance hell. If you find a bug in one of these "portability" >unique files, then you have to edit several files to effect the >same fix. It also much more difficult to view the impact to >other "platforms" for such a fix. No, this is why instead of loose conditional withs, I would like to see abstract packages defining an interface for a path to implement. Then a portable program will be developed in terms of that abstract package interface. This would be, so to speak, a "package-wide" program. Fixing a bug there will do it for all paths. A bug fixed in a path (implementation) will by no means affect other paths. Already in Ada one could write: generic type File is limited private; with procedure Read (...) is <>; with procedure Write (...) is <>; --- package Abstract_OS_Interface is -- Nothing here end Abstract_OS_Interface; Then: with Abstract_OS_Interface; package UNIX is type File is ...; procedure Read (...); procedure Write (...); package Interface is new Abstract_OS_Interface (File); end UNIX; with Abstract_OS_Interface; package Win32 is type File is ...; procedure Read (...); procedure Write (...); package Interface is new Abstract_OS_Interface (File); end Win32; Now what I need is just to conditionally with/use *.Interface and, importantly, to have a way to ensure that nothing else from the enclosing package be visible. The technique above works fine with subroutines having defaults. But it becomes awkward with types and values. Worse is that one cannot hide implementations in private: package Win32 is type File is limited private; procedure Read (...); procedure Write (...); package Interface is new Abstract_OS_Interface (File); -- Error, a premature use of File! private type File is limited record ... -- Do want them see it end record; end Win32; -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-26 9:34 ` Dmitry A. Kazakov @ 2004-01-26 19:23 ` Randy Brukardt 0 siblings, 0 replies; 296+ messages in thread From: Randy Brukardt @ 2004-01-26 19:23 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:onk910pmf41et1uai45hc6mfqhasdkmi8c@4ax.com... ... > The technique above works fine with subroutines having defaults. But > it becomes awkward with types and values. Worse is that one cannot > hide implementations in private: > > package Win32 is > type File is limited private; > procedure Read (...); > procedure Write (...); > package Interface is new Abstract_OS_Interface (File); > -- Error, a premature use of File! > private > type File is limited record > ... -- Do want them see it > end record; > end Win32; There is an AI on this problem. Dunno if it will get solved, though - the proposed solutions have not picked up much support... Randy. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-22 12:58 ` Marin David Condic 2004-01-22 17:25 ` Warren W. Gay VE3WWG @ 2004-01-23 2:47 ` Robert I. Eachus 2004-01-23 12:38 ` Marin David Condic ` (2 more replies) 1 sibling, 3 replies; 296+ messages in thread From: Robert I. Eachus @ 2004-01-23 2:47 UTC (permalink / raw) Marin David Condic wrote: > How about *adding* something to system like: > > System.Compiler_ID : constant String := "Something Useful Here" ; > > This would not break anything that was already using System_Name > (although given its general uselessness, I doubt that is very much) and > would provide a mechanism for identifying the compiler that is doing the > job. Then statements like "if (Compiler_ID = "Something") then..." would > possibly be useful. In Ada 83 that wouldn't have worked. But I think it would be wonderful to get rid of the type Name in system and add three string constants: Operating_System: constant String := implementation_dependent; Hardware_Architecture: constant String := implementation_dependent; Compiler: constant String := implementation_dependent; Version: constant String := implementation_dependent; If I were going to write this up as an AI, I would include as "Implementation Advice" that the strings be static, that configuration pragmas be allowed to affect the values, and that the version strings for a particular compiler should sort as strings into cronological order. Oh, and redefine System_Name to return a String, but not necessarily a static String. It should give the name of the machine the program is running on. (The machine I am typing this on is Milliways.) Memory_Size should be redefined as a function that returns the system memory size, and there should be a functions Stack_Size and Heap_Size that return the actual maximum permitted Stack_Size (either for the main program or for the task where it is called), any the size of the default heap. (The more I think about it, the type they return is not a stumbling block. That should be an implementation defined integer or modular type. Any program that needs to use the type will either use numberic literals or do a type conversion.) Anyone interested enough to propose this as a (late) addition to Ada0Y? Since Jean Ichbiah interchanged Name and System_Name at the very last moment in Ada 83, there certainly is a precedent for changing System late in the game. As far as I know that was the only significant change between the printers proof and the published ANSI standard. (Page number 2-2 certainly wasn't significant. ;-) > You still need some mechanism to wrap that around declarations and other > stuff. Perhaps that could be solved with some flavor of a pragma that > could take a case-like if statement around what you want conditionally > compiled. Maybe the whole thing should be solved with a pragma since you > don't want to have to first "with" System before you can start > conditionally withing other packages. That also gets simpler to deal > with from a language perspective since there has always been the ability > to have implementation defined pragmas. My current approach to this problem is to have packages OS, and ISA. Then in whatever library I am working these do the necesssary via package renames. I've thought about using a preprocessor, but so far the renames work and look much neater, as far as the source code is concerned. What I would really, really like is for the compiler to expand those names based on compile time flags and defaults. I don't think that trick should be a language defined/required behavior, but I don't see any reason why a compiler couldn't validate even if it included such a feature. -- Robert I. Eachus "The war on terror is a different kind of war, waged capture by capture, cell by cell, and victory by victory. Our security is assured by our perseverance and by our sure belief in the success of liberty." -- George W. Bush ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-23 2:47 ` Robert I. Eachus @ 2004-01-23 12:38 ` Marin David Condic 2004-01-24 5:23 ` Robert I. Eachus 2004-01-24 8:17 ` Pascal Obry 2004-01-23 16:38 ` Alexandre E. Kopilovitch 2004-01-23 17:24 ` Warren W. Gay VE3WWG 2 siblings, 2 replies; 296+ messages in thread From: Marin David Condic @ 2004-01-23 12:38 UTC (permalink / raw) The more I think about it the more I want there to be a conditional compilation capability that would allow some unlimited set of logical names to be associated with strings at compile time. What you propose would be helpful but A) still only helps where you can put an "if" statement and is useless around declarations and b) doesn't account for all the possible variants that may impact a program at compile time or run time. "Operating_System", for example, is insufficient to tell you if you have certain libraries available to you or not. Unless you force some structure on the string that allows it to be parsed to provide more detailed information. I think we either need a single logical compile-time variable with a structured string that can be parsed (some format like "Attrribute => Value, ....") or you need an arbitrary set of compile time variables that the developer can establish and document as required settings for conditional compilation. Most of what's in System seems to be useful only at run time. By then, I could have easily solved the problem for myself by having some kind of app-defined configuration file or similar thing I read in and use to determine which calls to make. So any solution has to happen at compile time or it really doesn't do any good. MDC Robert I. Eachus wrote: > > In Ada 83 that wouldn't have worked. But I think it would be wonderful > to get rid of the type Name in system and add three string constants: > > Operating_System: constant String := implementation_dependent; > Hardware_Architecture: constant String := implementation_dependent; > Compiler: constant String := implementation_dependent; > Version: constant String := implementation_dependent; > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-23 12:38 ` Marin David Condic @ 2004-01-24 5:23 ` Robert I. Eachus 2004-01-24 12:28 ` Marin David Condic 2004-01-26 18:03 ` Warren W. Gay VE3WWG 2004-01-24 8:17 ` Pascal Obry 1 sibling, 2 replies; 296+ messages in thread From: Robert I. Eachus @ 2004-01-24 5:23 UTC (permalink / raw) Marin David Condic wrote: > Most of what's in System seems to be useful only at run time. By then, I > could have easily solved the problem for myself by having some kind of > app-defined configuration file or similar thing I read in and use to > determine which calls to make. So any solution has to happen at compile > time or it really doesn't do any good. My point was that we can fix System to some extent, since Strings can now be static. Of course there is NO universal solution because on some systems some values will be static, and on others they won't be known until run-time. But if we "fix" System so that the compiler can document such things, then users will be able to do what they can do. I certainly don't buy the "conditional compilation must happen at compile time" argument. It may be true in most embedded applications that you can statically know these things at compile time. But I also deal with creating .dlls that must match the current hardware. If that means that I have to generate self-modifying code, so be it. (In practice I build and install the correct dispatch table when initializing a .dll.) Now it would be nice if I had a compiler that could create a .dll that would use x87, 3dNow!, SSE, SSE2, or possibly now SSE3 code as appropriate. I don't. But assuming I know what I am doing creating the correct .dll is not too painful. (Low-crawling under barbed wire in the mud, rather than crawling over broken glass in freezing rain.) But every once in a while I like to dream about the facility that Ada environments were supposed to have had, where I could just say compile this code for these dozen hardware specifications, and package the result in one load module. ;-) However, back to the world as it exists. The discipline of Ada is that you should be able to push most, if not all, hardware dependencies first into package and other unit bodies, and then into variant parts and if statements. It is hard word to do that. But IMHO it is much easier to maintain than you can ever save during development by not doing the work. So I don't believe in preprocessors for Ada code. There are times that I do get frustrated at the fact that I can put case statements in type declarations and sequences of statements, but I can't wrap a single declaration in one. But usually after a short break, I come back and it wasn't necessary after all. -- Robert I. Eachus "The war on terror is a different kind of war, waged capture by capture, cell by cell, and victory by victory. Our security is assured by our perseverance and by our sure belief in the success of liberty." -- George W. Bush ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-24 5:23 ` Robert I. Eachus @ 2004-01-24 12:28 ` Marin David Condic 2004-01-24 15:32 ` Robert I. Eachus 2004-01-26 18:03 ` Warren W. Gay VE3WWG 1 sibling, 1 reply; 296+ messages in thread From: Marin David Condic @ 2004-01-24 12:28 UTC (permalink / raw) Well, there are things that happen at compile time. Perhaps in theory they don't *have* to happen at compile time - but in the world we live in and for the forseeable future, things are going to be done at compile time. Since different compilers often support (or don't support) different declarations, I'd like some way of saying "If I'm on Gnat - compile this declaration - if on Aonix, make this the declaration...". I don't know how that can happen at runtime. Likewise, when withing packages that may be compiler dependent and using statements from them, I'd like some way of doing that and I can't imagine how a procedure call of something that doesn't get withed is going to sneak past the compiler and get resolved at runtime. Like I've said elsewhere, perhaps you can handle this through various CM and build processes, but often this is harder to manage or it has pitfalls organizationally and it doesn't provide a *portable* answer that I know I can count on in some other environment. Sure, you can create yet one more layer of indirection and hide all that stuff under a "portable" interface (and you probably should, even if you had conditional compilation) but you've just pushed the problem off one level. You've got two separate bodies of code that have to be tracked and managed and maintained and you don't necessarily have the tools to do that easily, nor is it guaranteed to work if you've got to drag it to an as yet to be specified environment. Conditional compilation is not necessarily pretty, but the whole mess of trying to maintain a variety of different targets never is under the best of circumstances. Conditional compilation would at least provide a portable answer. MDC Robert I. Eachus wrote: > > I certainly don't buy the "conditional compilation must happen at > compile time" argument. It may be true in most embedded applications > that you can statically know these things at compile time. But I also > deal with creating .dlls that must match the current hardware. If that > means that I have to generate self-modifying code, so be it. (In > practice I build and install the correct dispatch table when > initializing a .dll.) -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-24 12:28 ` Marin David Condic @ 2004-01-24 15:32 ` Robert I. Eachus 2004-01-24 15:43 ` Marin David Condic 0 siblings, 1 reply; 296+ messages in thread From: Robert I. Eachus @ 2004-01-24 15:32 UTC (permalink / raw) Marin David Condic wrote: > Since different compilers often support (or don't support) different > declarations, I'd like some way of saying "If I'm on Gnat - compile this > declaration - if on Aonix, make this the declaration...". I don't know > how that can happen at runtime. Likewise, when withing packages that may > be compiler dependent and using statements from them, I'd like some way > of doing that and I can't imagine how a procedure call of something that > doesn't get withed is going to sneak past the compiler and get resolved > at runtime. Now I see why you worry about about illegal code and I don't. As far as I am concerned, ANYTHING I can do to minimize differences between versions is worth the effort. That certainly includes building wrappers. So in the Ada 83 days when different compilers had different names for the trancendental math packages, I had MY standard. (Usually kept updated based on the latest NUMWG work, but that is a detail.) Similarly, I had my package that did command line arguments, with different bodies for Alsys and Verdix, etc. So I kept a collection of 'standard' packages needed for portability. If I needed to deal with say, a bug in Solaris, I did it there. The net result was one directory of implementation dependent packages, with multiple implementations, and applications that were completely implementation independent. I kept the package specifications for the implementation dependent stuff identical, if necessary by making the bindings thicker than might otherwise be needed. The only case where I can ever remember a problem, Rational called me about one of my ADAR packages that didn't compile due to an Unchecked_Conversion. Rational didn't allow Unchecked_Conversions of access types. In addition to telling them a work around, I suggested that they treat this case as as a compiler bug. It involved an Unchecked_Conversion of an object of an access type to the same access type. (Why did I do it? It allowed me to put a with clause on a body instead of on the package specification.) -- Robert I. Eachus "The war on terror is a different kind of war, waged capture by capture, cell by cell, and victory by victory. Our security is assured by our perseverance and by our sure belief in the success of liberty." -- George W. Bush ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-24 15:32 ` Robert I. Eachus @ 2004-01-24 15:43 ` Marin David Condic 2004-01-25 4:24 ` Robert I. Eachus 2004-01-29 11:17 ` Jacob Sparre Andersen 0 siblings, 2 replies; 296+ messages in thread From: Marin David Condic @ 2004-01-24 15:43 UTC (permalink / raw) Yeah. Isolating them down at some low level is fine. But that still leaves you with the problem of "How do I code up the stuff at the low level?" You're either controlling it with some kind of build scripts & CM or you do it with something inside the language. Given that it needs to be done & I can't keep pushing it off with indirection forever, I'd like a language mechanism for doing it. Maybe conditional compilation is not the answer. But then let's come up with something else. Sooner or later, I've got to have a way of maintaining code that works in one place but not in another and relying on external mechanisms is often difficult or impossible. (Handing source code off to unknown destinations is a good example - you may not know who or what is at the other end and may not be able to trust that they have mechanisms or competence to manage multiple builds. Source code I can trust because I can verify that it works as intended. Mechanisms outside that are uncertain.) MDC Robert I. Eachus wrote: > > Now I see why you worry about about illegal code and I don't. As far as > I am concerned, ANYTHING I can do to minimize differences between > versions is worth the effort. That certainly includes building > wrappers. So in the Ada 83 days when different compilers had different > names for the trancendental math packages, I had MY standard. (Usually > kept updated based on the latest NUMWG work, but that is a detail.) > Similarly, I had my package that did command line arguments, with > different bodies for Alsys and Verdix, etc. So I kept a collection of > 'standard' packages needed for portability. If I needed to deal with > say, a bug in Solaris, I did it there. > > The net result was one directory of implementation dependent packages, > with multiple implementations, and applications that were completely > implementation independent. I kept the package specifications for the > implementation dependent stuff identical, if necessary by making the > bindings thicker than might otherwise be needed. The only case where I > can ever remember a problem, Rational called me about one of my ADAR > packages that didn't compile due to an Unchecked_Conversion. > > Rational didn't allow Unchecked_Conversions of access types. In > addition to telling them a work around, I suggested that they treat this > case as as a compiler bug. It involved an Unchecked_Conversion of an > object of an access type to the same access type. (Why did I do it? It > allowed me to put a with clause on a body instead of on the package > specification.) > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-24 15:43 ` Marin David Condic @ 2004-01-25 4:24 ` Robert I. Eachus 2004-01-25 16:24 ` Marin David Condic 2004-01-29 11:17 ` Jacob Sparre Andersen 1 sibling, 1 reply; 296+ messages in thread From: Robert I. Eachus @ 2004-01-25 4:24 UTC (permalink / raw) Marin David Condic wrote: > Maybe conditional compilation is not the answer. But then let's come up > with something else. Sooner or later, I've got to have a way of > maintaining code that works in one place but not in another and relying > on external mechanisms is often difficult or impossible. (Handing source > code off to unknown destinations is a good example - you may not know > who or what is at the other end and may not be able to trust that they > have mechanisms or competence to manage multiple builds. Source code I > can trust because I can verify that it works as intended. Mechanisms > outside that are uncertain.) Totally agree, which is why I try to do it all in Ada source, with "if SSE then..." instead of "#ifdef SSE ..." The disadvantage of this approach is that the code must compile cleanly, even if it will be statically eliminated at compile time. I just haven't found that to be a major hurdle. I can easily see that happening if you are "up against the wall" with a compiler bug. But with GNAT, I have the source, and know how to use it. ;-) -- Robert I. Eachus "The war on terror is a different kind of war, waged capture by capture, cell by cell, and victory by victory. Our security is assured by our perseverance and by our sure belief in the success of liberty." -- George W. Bush ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-25 4:24 ` Robert I. Eachus @ 2004-01-25 16:24 ` Marin David Condic 0 siblings, 0 replies; 296+ messages in thread From: Marin David Condic @ 2004-01-25 16:24 UTC (permalink / raw) Well, I suppose if I assumed Gnat as the compiler (not always possible, obviously) then I at least have this work around: Code it up in C with #ifdef's and bind to it with Ada. :-) The problem is, of course, sometimes you can't assume a C compiler is around - unless you're coding the whole thing in C and then its a non-issue. With C, you clearly can get your conditional compilation (and a bunch of things you maybe *didn't* want ;-) That is one reason why a lot of developers go with C. It does what they *want* it to do instead of having it tell them "You shouldn't *want* to do that!" I think that's one thing that makes it difficult to sell Ada sometimes. MDC Robert I. Eachus wrote: > > I just haven't found that to be a major hurdle. I can easily see that > happening if you are "up against the wall" with a compiler bug. But > with GNAT, I have the source, and know how to use it. ;-) > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-24 15:43 ` Marin David Condic 2004-01-25 4:24 ` Robert I. Eachus @ 2004-01-29 11:17 ` Jacob Sparre Andersen 2004-01-29 12:52 ` Marin David Condic 1 sibling, 1 reply; 296+ messages in thread From: Jacob Sparre Andersen @ 2004-01-29 11:17 UTC (permalink / raw) Marin David Condic wrote: > Yeah. Isolating them down at some low level is fine. But that still > leaves you with the problem of "How do I code up the stuff at the > low level?" You're either controlling it with some kind of build > scripts & CM or you do it with something inside the language. Given > that it needs to be done & I can't keep pushing it off with > indirection forever, I'd like a language mechanism for doing it. Would a pragma in the package specification declaring which file the package body should be read from depending on some compilation parameters (compiler, operating system, etc.) do the job? Something like this, where the body is grabbed from the file named by the first "Body_Source_File" pragma with a matching condition. If no "Body_Source_File" pragma has a matching condition, the compiler just uses its default routine for finding the source code for the package body. with System; with System.Compiler_Flags; package Hiding_Compiler_Specific_Details is pragma Body_Source_File (Condition => System.Compiler_Name = "GNAT", File => "GNAT/HCSD.ada_body"); pragma Body_Source_File (Condition => System.Compiler_Flags.Set ("--with-gnu-gettext"), File => "GNU-Gettext/HCSD.ada_body"); pragma Body_Source_File (Condition => True, File => "default_implementations/HCSD.ada_body"); ... end Hiding_Compiler_Specific_Details; This would limit the language handling of conditional compilation to selecting package/unit bodies, but I think it would solve most of the problems mentioned in this discussion, without risking the whole preprocessing hell seen in too many C programs. Greetings, Jacob -- �But you have to be a bit wary of a ship that collects snowflakes.� -- Diziet Sma ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-29 11:17 ` Jacob Sparre Andersen @ 2004-01-29 12:52 ` Marin David Condic 0 siblings, 0 replies; 296+ messages in thread From: Marin David Condic @ 2004-01-29 12:52 UTC (permalink / raw) That might be an answer. It at least goes a long way towards alleviating most of the problems. I'd have some concerns about mentioning actual filenames in the pragma because that can be incredibly system dependent and all you have to do is move some directory tree and the whole thing collapses. I've seen that problem show up in C and would prefer not to have it show up in any Ada code. If, OTOH, it let me use some kind of symbolic name in much the same way as I already do with a package name, then you can at least figure that each compiler or platform has some mechanism for finding a body already and now it just does so with a different name. (On Gnat, it looks for an appropriately named file. On Aonix, it looks in its compilation database for the right unit to associate. On ??? - it uses whatever means it has natively.) Maybe its something like this: with Some_Package ; if (some_condition) then for Some_Package'Body use GNAT_Some_Package ; else for Some_Package'Body use AONIX_Some_Package ; end if ; I'm not saying it would have to be this syntax or that a pragma wouldn't be better. Just saying that I want the compiler to apply its normal interpretation rules to find "GNAT_Some_Package" and pretend that its name is "Some_Package". Something like that might work. MDC Jacob Sparre Andersen wrote: > > Would a pragma in the package specification declaring which file the > package body should be read from depending on some compilation > parameters (compiler, operating system, etc.) do the job? > > Something like this, where the body is grabbed from the file named by > the first "Body_Source_File" pragma with a matching condition. If no > "Body_Source_File" pragma has a matching condition, the compiler just > uses its default routine for finding the source code for the package > body. > > with System; > with System.Compiler_Flags; > > package Hiding_Compiler_Specific_Details is > pragma Body_Source_File > (Condition => System.Compiler_Name = "GNAT", > File => "GNAT/HCSD.ada_body"); > pragma Body_Source_File > (Condition => System.Compiler_Flags.Set ("--with-gnu-gettext"), > File => "GNU-Gettext/HCSD.ada_body"); > pragma Body_Source_File > (Condition => True, > File => "default_implementations/HCSD.ada_body"); > > ... > end Hiding_Compiler_Specific_Details; > > This would limit the language handling of conditional compilation to > selecting package/unit bodies, but I think it would solve most of the > problems mentioned in this discussion, without risking the whole > preprocessing hell seen in too many C programs. > > Greetings, > > Jacob -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-24 5:23 ` Robert I. Eachus 2004-01-24 12:28 ` Marin David Condic @ 2004-01-26 18:03 ` Warren W. Gay VE3WWG 2004-01-26 19:14 ` Standard Ada Preprocessor Jeffrey Carter ` (2 more replies) 1 sibling, 3 replies; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-26 18:03 UTC (permalink / raw) Robert I. Eachus wrote: > Marin David Condic wrote: >> Most of what's in System seems to be useful only at run time. By then, >> I could have easily solved the problem for myself by having some kind >> of app-defined configuration file or similar thing I read in and use >> to determine which calls to make. So any solution has to happen at >> compile time or it really doesn't do any good. > > My point was that we can fix System to some extent, since Strings can > now be static. Of course there is NO universal solution because on some > systems some values will be static, and on others they won't be known > until run-time. But if we "fix" System so that the compiler can > document such things, then users will be able to do what they can do. I hate "no universal solution" fixes. I hate having to revist things multiple times. I hate preprocessors too, but I hate the other issues more. > I certainly don't buy the "conditional compilation must happen at > compile time" argument. It may be true in most embedded applications > that you can statically know these things at compile time. But I also > deal with creating .dlls that must match the current hardware. If that > means that I have to generate self-modifying code, so be it. (In > practice I build and install the correct dispatch table when > initializing a .dll.) DLLs only are part of _one_ vendor's solutions. Try dealing with different POSIX-like environments from _many_ vendors. The solutions get dirtier and quickly. For example, you'd pretty much have to have a different package for every POSIX-like environment, because of changes like what was included in the stat(2) structure (and others). Worse, you'd have to matrix it out to the various releases of Linux, FreeBSD, NetBSD, OpenBSD, Solaris, IRIX, HPUX etc. You cannot hope to accommodate all of these differences by package names. Throw into the mix a different set of compilers, and different versions of a readline library, and the solution is entirely doomed. > But every once in a while I like to dream about the facility that Ada > environments were supposed to have had, where I could just say compile > this code for these dozen hardware specifications, and package the > result in one load module. ;-) > > However, back to the world as it exists. The world as it is, does not need to remain entirely static ;-) > The discipline of Ada is that > you should be able to push most, if not all, hardware dependencies first > into package and other unit bodies, and then into variant parts and if > statements. Ok, so we're getting back to the argument "Ada doesn't do it this way". This works for limited embedded environments, but I think you're hearing from others, that it still does not do the job well enough in the modern Open Sourced world. If Ada sticks to this model (the "embedded only"), then it is then doomed to never achieve wider acceptance, IMO. > It is hard word to do that. But IMHO it is much easier to > maintain than you can ever save during development by not doing the work. Matrix 10 POSIX environments x 10 versions of the same, x 4 different versions of a curses library. That leaves you with 400 different custom (possibly groups of) packages to work with. Real slick indeed. :( > So I don't believe in preprocessors for Ada code. Think "conditional compilation". I see the "how" as an implementation detail, that need _not_ track the C/C++ experience. > There are times that > I do get frustrated at the fact that I can put case statements in type > declarations and sequences of statements, but I can't wrap a single > declaration in one. But usually after a short break, I come back and it > wasn't necessary after all. I get frustrated with the short sightedness of the "not invented here syndrome". But maybe, that is just me. ;-) -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-26 18:03 ` Warren W. Gay VE3WWG @ 2004-01-26 19:14 ` Jeffrey Carter 2004-01-26 22:04 ` Warren W. Gay VE3WWG ` (2 more replies) 2004-01-26 23:44 ` Georg Bauhaus 2004-01-27 0:15 ` Standard Ada Preprocessor (Was: why ada is so unpopular ?) Robert I. Eachus 2 siblings, 3 replies; 296+ messages in thread From: Jeffrey Carter @ 2004-01-26 19:14 UTC (permalink / raw) Warren W. Gay VE3WWG wrote: > Matrix 10 POSIX environments x 10 versions of the same, x 4 > different versions of a curses library. That leaves you with > 400 different custom (possibly groups of) packages to work > with. Real slick indeed. :( One standard POSIX-Ada binding and one application-specific screen control package leaves me with 4 different package bodies to deal with, each of which contains code specific to one curses library. The code for a specific curses library is in one place, so I don't have to hunt all over the code for the bits that deal with that library when I have to change something. If you want to handle those package bodies as one big file that you preprocess to get the desired version for a platform, go ahead. The payoff was in creating the application-specific package. The point should always be "what does the application require?", not "what does the platform/environment provide?" Once you've done that you can always hide the differences behind an application-specific interface. >> So I don't believe in preprocessors for Ada code. > > Think "conditional compilation". I see the "how" as an > implementation detail, that need _not_ track the C/C++ > experience. This thread is about a standard preprocessor (see the subject). But as someone who has done this kind of thing without a preprocessor and prefer the results, I'm convinced that what's needed is a portable way to tell the compiler to use the package body from the Win32 directory, or from the UNIX directory, or from the VMS directory. -- Jeff Carter "I'm a lumberjack and I'm OK." Monty Python's Flying Circus 54 ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-26 19:14 ` Standard Ada Preprocessor Jeffrey Carter @ 2004-01-26 22:04 ` Warren W. Gay VE3WWG 2004-01-27 1:00 ` Jeffrey Carter ` (3 more replies) 2004-01-27 0:06 ` Robert I. Eachus 2004-01-27 0:17 ` Standard Ada Preprocessor Alexandre E. Kopilovitch 2 siblings, 4 replies; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-26 22:04 UTC (permalink / raw) Jeffrey Carter wrote: > Warren W. Gay VE3WWG wrote: > >> Matrix 10 POSIX environments x 10 versions of the same, x 4 >> different versions of a curses library. That leaves you with >> 400 different custom (possibly groups of) packages to work >> with. Real slick indeed. :( > > One standard POSIX-Ada binding Impossible. Some UNIces provide some API structure members, while others don't, or provide something else again. Yes, you can dumb it down to a "standard" (or omit non-universal functionality), but by doing so you throw away functionality. I find that unacceptable. > and one application-specific screen > control package leaves me with 4 different package bodies to deal with, > each of which contains code specific to one curses library. Ah, but you cannot assume that the binding for PDcurses, is going to be the same for all different POSIX platforms! Going from POSIX, to X Windows, to Win32, will change the interfaces again. It is not this simple, as the level of support changes depending upon the platform, and version of the same (in some cases). Try it in an open sourced project (as I have), and you'll be a little wiser for it. > If you want to handle those package bodies as one big file that you > preprocess to get the desired version for a platform, go ahead. The > payoff was in creating the application-specific package. > > The point should always be "what does the application require?", not > "what does the platform/environment provide?" When you code "bindings" you have to consider both. Sometimes you can push the application requirments into the thick binding, developing some distance from the thin one. But at some level, you will _still_ have to look at OS and C library level "requirements". Develop some Open Sourced code in without gnatprep, and we'll see how portable it is ;-) > Once you've done that you > can always hide the differences behind an application-specific interface. There is hiding to be sure. But down at the C and OS level, things get rather ugly when trying to be "portable". The fault of this is not so much Ada, but trying to interface to a predominantly non-Ada world. >> Think "conditional compilation". I see the "how" as an >> implementation detail, that need _not_ track the C/C++ >> experience. > > This thread is about a standard preprocessor (see the subject). But as > someone who has done this kind of thing without a preprocessor and > prefer the results, I'm convinced that what's needed is a portable way > to tell the compiler to use the package body from the Win32 directory, > or from the UNIX directory, or from the VMS directory. That functionality would help. But there is still a need for more than that. -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-26 22:04 ` Warren W. Gay VE3WWG @ 2004-01-27 1:00 ` Jeffrey Carter 2004-01-27 8:35 ` Ole-Hjalmar Kristensen 2004-01-27 17:33 ` Warren W. Gay VE3WWG 2004-01-27 2:35 ` Randy Brukardt ` (2 subsequent siblings) 3 siblings, 2 replies; 296+ messages in thread From: Jeffrey Carter @ 2004-01-27 1:00 UTC (permalink / raw) Warren W. Gay VE3WWG wrote: > Jeffrey Carter wrote: > >> One standard POSIX-Ada binding > > Impossible. Some UNIces provide some API structure members, > while others don't, or provide something else again. Yes, > you can dumb it down to a "standard" (or omit non-universal > functionality), but by doing so you throw away functionality. > I find that unacceptable. There is a standard POSIX-Ada binding (Florist is an implementation of this standard) to the POSIX standard. If you want something not in this standard, obviously you're going to have to provide it yourself on some platforms. If you're on a platform that doesn't provide some of the functionality, then it's not a POSIX system. In neither case are you dealing with different versions of POSIX. -- Jeff Carter "Beyond 100,000 lines of code you should probably be coding in Ada." P. J. Plauger 26 ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 1:00 ` Jeffrey Carter @ 2004-01-27 8:35 ` Ole-Hjalmar Kristensen 2004-01-27 11:09 ` Georg Bauhaus 2004-01-27 17:50 ` Standard Ada Preprocessor Warren W. Gay VE3WWG 2004-01-27 17:33 ` Warren W. Gay VE3WWG 1 sibling, 2 replies; 296+ messages in thread From: Ole-Hjalmar Kristensen @ 2004-01-27 8:35 UTC (permalink / raw) >>>>> "JC" == Jeffrey Carter <spam@spam.com> writes: JC> Warren W. Gay VE3WWG wrote: >> Jeffrey Carter wrote: >> >>> One standard POSIX-Ada binding >> Impossible. Some UNIces provide some API structure members, >> while others don't, or provide something else again. Yes, >> you can dumb it down to a "standard" (or omit non-universal >> functionality), but by doing so you throw away functionality. >> I find that unacceptable. JC> There is a standard POSIX-Ada binding (Florist is an implementation of JC> this standard) to the POSIX standard. If you want something not in JC> this standard, obviously you're going to have to provide it yourself JC> on some platforms. If you're on a platform that doesn't provide some JC> of the functionality, then it's not a POSIX system. In neither case JC> are you dealing with different versions of POSIX. Which does not matter if what you are doing is maintaining a program which is running on multiple platforms and is compiled with multiple compilers. The program has to run even if the platform does not support a standard package like Florist. How many platforms is Florist really available on, btw.? What matters is how do I do this while keeping the code readable and maintainable. One way to combat the combinatorial explosion of platforms * compiler * library is to explicitly test for the features of the environment you really need to know, not assume something because of a particular platform/compiler. This is the approach typically used by projects using the 'configure' tool. I would really like to have some standard configuration tool which could take such parameters as input and produce a version of the system tailored to the environment in which it is to be compiled and run. In absence of this, I have to do the job manually, or use some kind of preprocessing. Btw., such a configuration tool would have to keep the exact same information internally as the condtional compilation rules handled by the preprocessor. The only difference is that with the preprocessor, the programmer can see the rules as part of the program text. JC> -- JC> Jeff Carter JC> "Beyond 100,000 lines of code you JC> should probably be coding in Ada." JC> P. J. Plauger JC> 26 -- C++: The power, elegance and simplicity of a hand grenade. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 8:35 ` Ole-Hjalmar Kristensen @ 2004-01-27 11:09 ` Georg Bauhaus 2004-01-27 15:22 ` Ole-Hjalmar Kristensen 2004-01-27 15:54 ` Robert I. Eachus 2004-01-27 17:50 ` Standard Ada Preprocessor Warren W. Gay VE3WWG 1 sibling, 2 replies; 296+ messages in thread From: Georg Bauhaus @ 2004-01-27 11:09 UTC (permalink / raw) Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com> wrote: : One way to combat the combinatorial explosion of platforms * compiler : * library is to explicitly test for the features of the environment : you really need to know, not assume something because of a particular : platform/compiler. This is the approach typically used by projects : using the 'configure' tool. Only to some extent is this test possible with this approach. Some GNU software authors must frankly tell you that unless you use a know combination of compiler (i.e. gcc ;-) and OS (i.e., Unix or Wunix), "... non-default environments can expose bugs in the system header files, crippling compilation in _very_ non-obvious ways. Because of that, we define them only on well-tested architectures where we know they will work." (from wget config-post.h "1.9+cvs-dev") And promtly como --c --strict lets me translate the source, but without --remarks, it does not tell me that usleep is not defined. So for a double argument to usleep which has been manually range checked, the conversion to long is not done... The configure approach has always been a nightmare for me the moment I had to deviate from the assumptions that the configure script is known to verify. : I would really like to have some standard configuration tool which : could take such parameters as input and produce a version of the : system tailored to the environment in which it is to be compiled and : run. Yes. But do you think it will ever be produced by programmers (who like to creatively write programs)? Collegues tell me that CM is tedious, always the same, automatic, boring, wast of time, etc. etc., they want a DWIM procedure. And when I answer that configuration management, installation procedures, installation testing routines and so one are 50% of software development, I'm on my own. So the trick will be to turn CM into a programming problem, so programmers and mathematicians will be instrested in solving it. -- Georg ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 11:09 ` Georg Bauhaus @ 2004-01-27 15:22 ` Ole-Hjalmar Kristensen 2004-01-27 15:54 ` Robert I. Eachus 1 sibling, 0 replies; 296+ messages in thread From: Ole-Hjalmar Kristensen @ 2004-01-27 15:22 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: > Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com> wrote: > : One way to combat the combinatorial explosion of platforms * compiler > : * library is to explicitly test for the features of the environment > : you really need to know, not assume something because of a particular > : platform/compiler. This is the approach typically used by projects > : using the 'configure' tool. > > Only to some extent is this test possible with this approach. > Some GNU software authors must frankly tell you that unless > you use a know combination of compiler (i.e. gcc ;-) and OS (i.e., > Unix or Wunix), > "... non-default environments can expose bugs in the system header > files, crippling compilation in _very_ non-obvious ways. Because > of that, we define them only on well-tested architectures where we > know they will work." > (from wget config-post.h "1.9+cvs-dev") Yes, you depend very much on how intelligent the configure scripts are, and you cannot count on it being automatically portable to another platform, but in my experience it is more portable and more readable then trying to cover all platform/compiler/os versions explicitly. This is from experience of developing/maintaining a > 1000 KLOC project on diverse platforms, like FreeBSD, Linux, AIX, HP-UX, Solaris, and Windows for several years. > > And promtly como --c --strict lets me translate the source, > but without --remarks, it does not tell me that usleep is not > defined. So for a double argument to usleep which has been > manually range checked, the conversion to long is not done... > > The configure approach has always been a nightmare for me the moment > I had to deviate from the assumptions that the configure script > is known to verify. > Yes, of course. As soon as you introduce new kinds of system dependencies, you have to revice the configure script. The hard part is figuring out which part of your code is really system dependent. You usually find it out by trying to port your system. Remember the saying about there is no such thing about portable software, only software which has been ported :-) > : I would really like to have some standard configuration tool which > : could take such parameters as input and produce a version of the > : system tailored to the environment in which it is to be compiled and > : run. > > Yes. But do you think it will ever be produced by programmers (who > like to creatively write programs)? > Collegues tell me that CM is tedious, always the same, automatic, > boring, wast of time, etc. etc., they want a DWIM procedure. > And when I answer that configuration > management, installation procedures, installation testing routines > and so one are 50% of software development, I'm on my own. > > So the trick will be to turn CM into a programming problem, so > programmers and mathematicians will be instrested in solving it. > > > -- Georg In addition, you need it to be available without too much effort. Isn't turning CM into a programming problem exactly what you do by using a preprocessor? -- C++: The power, elegance and simplicity of a hand grenade. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 11:09 ` Georg Bauhaus 2004-01-27 15:22 ` Ole-Hjalmar Kristensen @ 2004-01-27 15:54 ` Robert I. Eachus 2004-01-27 18:00 ` Warren W. Gay VE3WWG ` (2 more replies) 1 sibling, 3 replies; 296+ messages in thread From: Robert I. Eachus @ 2004-01-27 15:54 UTC (permalink / raw) Georg Bauhaus wrote: > So the trick will be to turn CM into a programming problem, so > programmers and mathematicians will be instrested in solving it. No, I think the right approach is to keep improving Ada for software engineers and let programmers use C++. We are doomed to live in a world where most code is poorly designed. All we can do is try to keep an island of sanity, and try to insure that Ada is used where quality is critical. (I am not saying there is no well designed C++ out there. There is, but it is the exception, not something you can expect.) -- Robert I. Eachus "The war on terror is a different kind of war, waged capture by capture, cell by cell, and victory by victory. Our security is assured by our perseverance and by our sure belief in the success of liberty." -- George W. Bush ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 15:54 ` Robert I. Eachus @ 2004-01-27 18:00 ` Warren W. Gay VE3WWG 2004-01-27 19:19 ` David Starner ` (2 more replies) 2004-01-27 19:11 ` Standard Ada Preprocessor Jeffrey Carter 2004-01-27 21:48 ` Alexandre E. Kopilovitch 2 siblings, 3 replies; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-27 18:00 UTC (permalink / raw) Robert I. Eachus wrote: > Georg Bauhaus wrote: >> So the trick will be to turn CM into a programming problem, so >> programmers and mathematicians will be instrested in solving it. > > No, I think the right approach is to keep improving Ada for software > engineers and let programmers use C++. OUCH. I can't believe you said that. Perhaps this is getting to the root of the "real" problem. ;-) Perhaps we "lowly programmers" need to ditch Ada, and reinvent our own flavour of the same. After all, only "lowly programmers" would need to worry about such dirty things as portability. -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 18:00 ` Warren W. Gay VE3WWG @ 2004-01-27 19:19 ` David Starner 2004-01-27 20:08 ` Ludovic Brenta ` (4 more replies) 2004-01-27 20:44 ` Randy Brukardt 2004-01-27 22:15 ` Alexandre E. Kopilovitch 2 siblings, 5 replies; 296+ messages in thread From: David Starner @ 2004-01-27 19:19 UTC (permalink / raw) On Tue, 27 Jan 2004 13:00:31 -0500, Warren W. Gay VE3WWG wrote: > Perhaps this is getting to the root of the "real" problem. ;-) > > Perhaps we "lowly programmers" need to ditch Ada, and reinvent > our own flavour of the same. After all, only "lowly programmers" > would need to worry about such dirty things as portability. My feelings too. 15 years ago, someone made a killing by releasing a Turbo Pascal for under a hundred bucks, and made Pascal a major language. Free software has helped drop the off-the-shelf price of a complete Un*x system with C, C++, Pascal and Lisp compilers to under a hundred bucks. But I still get quoted a price of $700 for an Ada compiler. Maybe that's fine for ye system engineers, but programmers, especially we student programmers, don't have a wealth of money to drop on compilers. Perhaps I need to find a new hammer. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 19:19 ` David Starner @ 2004-01-27 20:08 ` Ludovic Brenta 2004-01-27 20:19 ` Georg Bauhaus ` (3 subsequent siblings) 4 siblings, 0 replies; 296+ messages in thread From: Ludovic Brenta @ 2004-01-27 20:08 UTC (permalink / raw) David Starner <dvdeug@email.ro> writes: > My feelings too. 15 years ago, someone made a killing by releasing a > Turbo Pascal for under a hundred bucks, and made Pascal a major language. > Free software has helped drop the off-the-shelf price of a complete Un*x > system with C, C++, Pascal and Lisp compilers to under a hundred bucks. > But I still get quoted a price of $700 for an Ada compiler. Maybe that's > fine for ye system engineers, but programmers, especially we student > programmers, don't have a wealth of money to drop on compilers. Perhaps I > need to find a new hammer. See my post about Debian GNU/Linux :) -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 19:19 ` David Starner 2004-01-27 20:08 ` Ludovic Brenta @ 2004-01-27 20:19 ` Georg Bauhaus 2004-01-27 20:58 ` Randy Brukardt ` (2 subsequent siblings) 4 siblings, 0 replies; 296+ messages in thread From: Georg Bauhaus @ 2004-01-27 20:19 UTC (permalink / raw) David Starner <dvdeug@email.ro> wrote: : Free software has helped drop the off-the-shelf price of a complete Un*x : system with C, C++, Pascal and Lisp compilers to under a hundred bucks. : But I still get quoted a price of $700 for an Ada compiler. Hm. I see one compiler for $0, one for $195, one for EUR 8xx, and variations on the topic. With each you can get additions, like libraries for creating GUIs, etc. In all, from the little I know, these products can be called "professional versions", even without major "additions". What do you have to pay if you want the "professional versions" of Delphi, C++, Lisp? More in most cases. Marketing. -- Georg ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 19:19 ` David Starner 2004-01-27 20:08 ` Ludovic Brenta 2004-01-27 20:19 ` Georg Bauhaus @ 2004-01-27 20:58 ` Randy Brukardt 2004-01-27 22:13 ` Simon Wright 2004-01-28 12:50 ` Marin David Condic 4 siblings, 0 replies; 296+ messages in thread From: Randy Brukardt @ 2004-01-27 20:58 UTC (permalink / raw) "David Starner" <dvdeug@email.ro> wrote in message news:pan.2004.01.27.18.56.15.347278@email.ro... > On Tue, 27 Jan 2004 13:00:31 -0500, Warren W. Gay VE3WWG wrote: > ... 15 years ago, someone made a killing by releasing a > Turbo Pascal for under a hundred bucks, and made Pascal a major language. About the same time, RRS offers Janus/Ada for $99. It certainly didn't make Ada more popular... (And it should be remembered that Turbo Pascal was the third such low priced Pascal. Anybody remember the $29 JRT Pascal that preceded it? There's more to it than the price...) > Free software has helped drop the off-the-shelf price of a complete Un*x > system with C, C++, Pascal and Lisp compilers to under a hundred bucks. > But I still get quoted a price of $700 for an Ada compiler. For the record, you can buy Janus/Ada for as little as $195 (with only 90 days of support, and no GUI tools). > Maybe that's > fine for ye system engineers, but programmers, especially we student > programmers, don't have a wealth of money to drop on compilers. Perhaps I > need to find a new hammer. Ada doesn't have the sort of sugar daddies that a lot of these other languages to. So far as I know, all existing Ada compilers are produced by companies that make substantial portions of their revenue from their Ada development systems. Giving them away isn't going to improve the bottom line. For instance, here at RRS, virtually all of our revenue is from Ada development tools. If we started to give them away for free, there would be a number of effects: (1) Support costs would jump dramatically. With far more users, there would be far more questions to answer and bugs to track down. We'd have to implement a "triage" system - which is precisely what you don't like about ACT. (2) Revenue would drop to zero - we have no other products. We've never sold much support, probably because we answer questions from anyone with one of our products, supported or not. (3) Because of (1) and (2), we'd need to find another revenue source. What ever that is, it would remove most of the resources from the Ada compiler. So the net effect would be to completely stall development of the Ada compiler. That's unlikely to help you or anyone else. Your complaint really seems to boil down to not liking the policies of the maintainer of GNAT. The obvious solution in the Open Source world is to find another maintainer. All you have to do is figure how those people will be funded (or convinced to do a full-time job for free). Randy. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 19:19 ` David Starner ` (2 preceding siblings ...) 2004-01-27 20:58 ` Randy Brukardt @ 2004-01-27 22:13 ` Simon Wright 2004-01-27 23:04 ` David Starner 2004-01-28 12:50 ` Marin David Condic 4 siblings, 1 reply; 296+ messages in thread From: Simon Wright @ 2004-01-27 22:13 UTC (permalink / raw) David Starner <dvdeug@email.ro> writes: > My feelings too. 15 years ago, someone made a killing by releasing a > Turbo Pascal for under a hundred bucks, and made Pascal a major > language. Free software has helped drop the off-the-shelf price of > a complete Un*x system with C, C++, Pascal and Lisp compilers to > under a hundred bucks. But I still get quoted a price of $700 for > an Ada compiler. Maybe that's fine for ye system engineers, but > programmers, especially we student programmers, don't have a wealth > of money to drop on compilers. Perhaps I need to find a new hammer. This doesn't make sense. The latest GCC distribution comes with C, C++, Fortran, Java, Pascal, Python, Perl, and --- yes --- Ada. All at practically zero cost. If I want a supported environment for any of those I will have to pay money. For example, Dr Dobb's is advertising the Intel C++ compiler for Linux at a special discount price of $378. The Ada compiler for $700 is probably the Aonix one? They have a free download too, again not supported (though they do have a mailing list). -- Simon Wright 100% Ada, no bugs. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 22:13 ` Simon Wright @ 2004-01-27 23:04 ` David Starner 2004-01-28 1:41 ` Jeffrey Carter ` (2 more replies) 0 siblings, 3 replies; 296+ messages in thread From: David Starner @ 2004-01-27 23:04 UTC (permalink / raw) On Tue, 27 Jan 2004 22:13:36 +0000, Simon Wright wrote: > This doesn't make sense. > > The latest GCC distribution comes with C, C++, Fortran, Java, Pascal, > Python, Perl, and --- yes --- Ada. All at practically zero cost. You're a bit confused. Python and Perl don't come with GCC, and Pascal isn't a part of the standard GCC distribution. > If I want a supported environment for any of those I will have to pay > money. You see two states: the free level and the supported level. Because of how I work, I see three: the unsupported (which may cost a pretty penny, but you won't get much direct support), the professionally supported (I've at least heard of places where you pay huge bucks and get engineers at your beck and call) and something in-between that a lot of free software reaches, maybe call it the casually supported. If I submit a bug report on the C compiler in GCC, it will get examined, treated respectfully and it's not even inconceivable that a fix will get backported in the release branch, either by the GCC maintainers or by the Debian maintainers. It is high importance to all people working on most of those compilers that they continue to run in the latest released GCC and libc. I've submitted a documentation bug on GNAT that has not been dealt with. There are two GCC frontends in risk of being dropped in the GCC 3.5 release because of large structural changes; Fortran 77, which has no active maintainers, and Ada. The cumulative effect is that GNAT is effectively unsupported, where most of the other compilers (Fortran 77 excepted) are casually supported. As GNAT is the only Ada compiler that is Free software, that has a negative effect on how Ada is viewed in the world of Free software, and how a programmer who intends his programs to end up in the world of Free software should react. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 23:04 ` David Starner @ 2004-01-28 1:41 ` Jeffrey Carter 2004-01-28 2:26 ` Georg Bauhaus 2004-01-28 2:50 ` Stephen Leake 2 siblings, 0 replies; 296+ messages in thread From: Jeffrey Carter @ 2004-01-28 1:41 UTC (permalink / raw) David Starner wrote: > If I submit a bug report on the C compiler in GCC, it will get examined, > treated respectfully and it's not even inconceivable that a fix will get > backported in the release branch, either by the GCC maintainers or by the > Debian maintainers. It is high importance to all people working on most of > those compilers that they continue to run in the latest released GCC and > libc. I've submitted a documentation bug on GNAT that has not been dealt > with. There are two GCC frontends in risk of being dropped in the GCC 3.5 > release because of large structural changes; Fortran 77, which has no > active maintainers, and Ada. The cumulative effect is that GNAT is > effectively unsupported, where most of the other compilers (Fortran 77 > excepted) are casually supported. It seems from this and an earlier post that you've submitted bug reports for C that were not dealt with, and have submitted bug reports for GNAT that were not dealt with. But since you've submitted bug reports for C that were dealt with, but have yet to submit a bug report for GNAT that has been dealt with, you seem to conclude that support for C is better than support for GNAT. FWIW, I've submitted at least one bug report on a public version of GNAT that was dealt with. -- Jeff Carter "Son of a window-dresser." Monty Python & the Holy Grail 12 ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 23:04 ` David Starner 2004-01-28 1:41 ` Jeffrey Carter @ 2004-01-28 2:26 ` Georg Bauhaus 2004-01-28 2:50 ` Stephen Leake 2 siblings, 0 replies; 296+ messages in thread From: Georg Bauhaus @ 2004-01-28 2:26 UTC (permalink / raw) David Starner <dvdeug@email.ro> wrote: : : I've submitted a documentation bug on GNAT that has not been dealt : with. Where have you sent them? to report@ or to GCC's bugzilla? Many of the handful of reports I have sent to both addresses have been answered, sometimes with most helpful additional comments. (I'm not a customer. One documentation bug.) This includes reports sent only recently to GCC's Ada maintainers via Bugzilla, with answers from people with ACT and non-ACT addresses. : There are two GCC frontends in risk of being dropped in the GCC 3.5 : release because of large structural changes; Fortran 77, which has no : active maintainers, and Ada. The cumulative effect is that GNAT is : effectively unsupported, where most of the other compilers (Fortran 77 : excepted) are casually supported. I don't follow. GNAT, ifaik, is the GCC based compiler offered by ACT. GCC contains an Ada front end which appears rather tightly coupled with ACT's GNAT sources. You can check this if you look at the extensive ChangeLog in the gcc/gcc/ada directory. : As GNAT is the only Ada compiler that is Free software, that has a : negative effect on how Ada is viewed in the world of Free software, and : how a programmer who intends his programs to end up in the world of Free : software should react. I know of only 2 Free Software C compilers, and of one Free Software C++ compiler. If these numbers are correct, how should they have the opposite effect on the views of these popular languages? -- Georg ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 23:04 ` David Starner 2004-01-28 1:41 ` Jeffrey Carter 2004-01-28 2:26 ` Georg Bauhaus @ 2004-01-28 2:50 ` Stephen Leake 2004-01-28 3:21 ` Jeff C, ` (2 more replies) 2 siblings, 3 replies; 296+ messages in thread From: Stephen Leake @ 2004-01-28 2:50 UTC (permalink / raw) To: comp.lang.ada David Starner <dvdeug@email.ro> writes: > ... Because of how > I work, I see three: the unsupported (which may cost a pretty penny, but > you won't get much direct support), the professionally supported (I've at > least heard of places where you pay huge bucks and get engineers at your > beck and call) One such place is Ada Core Technologies, the maintainers of GNAT, the Free Software Gnu Ada compiler. > and something in-between that a lot of free software reaches, maybe > call it the casually supported. Like Lynx OS, VxWorks (not free software; also not very good support). > If I submit a bug report on the C compiler in GCC, it will get > examined, treated respectfully and it's not even inconceivable that > a fix will get backported in the release branch, either by the GCC > maintainers or by the Debian maintainers. It is high importance to > all people working on most of those compilers that they continue to > run in the latest released GCC and libc. I've submitted a > documentation bug on GNAT that has not been dealt with. As a paying customer, I get fast and excellent response from ACT. I have submitted many bug reports. > There are two GCC frontends in risk of being dropped in the GCC 3.5 > release because of large structural changes; Fortran 77, which has > no active maintainers, and Ada. The cumulative effect is that GNAT > is effectively unsupported, where most of the other compilers > (Fortran 77 excepted) are casually supported. I don't know where you get your information; ACT says otherwise. They are making it a high priority to keep the Ada in the gcc distribution working and up-to-date. Not as high a priority as satisfying paying customers, of course. But they see a good Free Software Ada compiler as excellent advertising for their services. In the past, they have released public versions of GNAT, usually based on slightly old versions of gcc. Now, they are trying to keep up with the current gcc versions, since they see that as even better advertising. > As GNAT is the only Ada compiler that is Free software, that has a > negative effect on how Ada is viewed in the world of Free software, > and how a programmer who intends his programs to end up in the world > of Free software should react. Getting the facts is always a good idea ... -- -- Stephe ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-28 2:50 ` Stephen Leake @ 2004-01-28 3:21 ` Jeff C, 2004-01-28 3:57 ` David Starner 2004-01-28 20:34 ` Michael Bode 2 siblings, 0 replies; 296+ messages in thread From: Jeff C, @ 2004-01-28 3:21 UTC (permalink / raw) "Stephen Leake" <stephen_leake@acm.org> wrote in message news:mailman.46.1075258237.2270.comp.lang.ada@ada-france.org... > David Starner <dvdeug@email.ro> writes: > > > > There are two GCC frontends in risk of being dropped in the GCC 3.5 > > release because of large structural changes; Fortran 77, which has > > no active maintainers, and Ada. The cumulative effect is that GNAT > > is effectively unsupported, where most of the other compilers > > (Fortran 77 excepted) are casually supported. > > I don't know where you get your information; ACT says otherwise. They > are making it a high priority to keep the Ada in the gcc distribution > working and up-to-date. Not as high a priority as satisfying paying > customers, of course. But they see a good Free Software Ada compiler > as excellent advertising for their services. In the past, they have > released public versions of GNAT, usually based on slightly old > versions of gcc. Now, they are trying to keep up with the current gcc > versions, since they see that as even better advertising. > Actually, he probably gets his information from the gcc mailing list. It is indeed true that there is a chance (probably a good chance) that there will be no Ada front end in gcc 3.5 (which may actually be gcc 4.0...but that is a different matter). That is not to say that Ada would not re-appear in 3.5.1 or 4.1. The issue is that gcc is getting ready to fold in a major infrastructure change that requires some heavy modification to the front ends. This is a major upgrade to the compiler and currently creates a compiler that runs a little slower but produces code that runs a little faster. The reason that it is still a "good thing" is that in theory it will be easier to roll in new optimizations into the compiler and actually make it much better in the future. Even the Ada maintainers on the gcc mailing list have indicated that Ada support should not be a show stopper for a 3.5 or 4.0 release. They have also indicated that they would likely roll in the needed changes at some point but that it is not a high priority. So things are not as bad as they sound but certainly not as good as they could be. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-28 2:50 ` Stephen Leake 2004-01-28 3:21 ` Jeff C, @ 2004-01-28 3:57 ` David Starner 2004-01-29 3:03 ` Stephen Leake 2004-01-28 20:34 ` Michael Bode 2 siblings, 1 reply; 296+ messages in thread From: David Starner @ 2004-01-28 3:57 UTC (permalink / raw) On Tue, 27 Jan 2004 21:50:19 -0500, Stephen Leake wrote: > As a paying customer, I get fast and excellent response from ACT. I > have submitted many bug reports. I'm not doubting that. >> There are two GCC frontends in risk of being dropped in the GCC 3.5 >> release because of large structural changes; Fortran 77, which has >> no active maintainers, and Ada. The cumulative effect is that GNAT >> is effectively unsupported, where most of the other compilers >> (Fortran 77 excepted) are casually supported. > > I don't know where you get your information; ACT says otherwise. In <http://gcc.gnu.org/ml/gcc/2004-01/msg00999.html> Richard Kenner writes: *** > As it is today, it is impossible to build an Ada compiler with the > branch. [...] At some point in the not too distant future, the Ada front end will handle function-at-a-time and then converting it to using tree-ssa might be something that the tree-ssa folks can either do or help with, but I don't see this is a major timing issue: even if we had one release of GCC (say 3.5) that didn't support Ada, it wouldn't be fatal and should not hold up tree-ssa if it were ready before the Ada conversion was done. *** It's a long thread, and Robert Dewar and Richard Kenner restate that basic point a few times. > They > are making it a high priority to keep the Ada in the gcc distribution > working and up-to-date. In <http://gcc.gnu.org/ml/gcc/2004-01/msg01970.html> Arnaud Charlet <charlet at ACT-Europe dot FR> writes *** [...] Note that GCC 3.3 contains a pretty bad Ada compiler (possibly worse than 3.2 which was not very good either), so it is not recommended to use it for anything else than bootstrapping newer versions as far as Ada is concerned. *** GCC 2.95 was the first release of GCC after the EGCS branch became mainline. There was almost four years between that release and GCC 3.3, and they have not produced a compiler that runs on the post-EGCS code that they consider good. > Getting the facts is always a good idea ... Yes, it is. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-28 3:57 ` David Starner @ 2004-01-29 3:03 ` Stephen Leake 2004-01-29 7:20 ` David Starner 2004-01-29 12:57 ` Marin David Condic 0 siblings, 2 replies; 296+ messages in thread From: Stephen Leake @ 2004-01-29 3:03 UTC (permalink / raw) To: comp.lang.ada David Starner <dvdeug@email.ro> writes: > <snip summary of gcc thread> Ok, thanks for the update. This is a typical problem with open source/bazarre development projects. If one subgroup has significantly different goals than the general group, they will get left out. ACT has much higher quality goals than the general gcc group. I prefer it that way. -- -- Stephe ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-29 3:03 ` Stephen Leake @ 2004-01-29 7:20 ` David Starner 2004-01-29 11:14 ` Georg Bauhaus 2004-01-29 12:57 ` Marin David Condic 1 sibling, 1 reply; 296+ messages in thread From: David Starner @ 2004-01-29 7:20 UTC (permalink / raw) On Wed, 28 Jan 2004 22:03:18 -0500, Stephen Leake wrote: > This is a typical problem with open source/bazarre development > projects. If one subgroup has significantly different goals than the > general group, they will get left out. I hardly see how this is a problem with open source. If Microsoft had an Ada frontend to their compiler, and was looking to replace the middle layer with a all-around superior one, do you think they'd hesitate to release a new Visual C++ because Visual Ada wasn't ported to the new middle end? > ACT has much higher quality goals than the general gcc group. Any evidence for this, or is this just jingoism? ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-29 7:20 ` David Starner @ 2004-01-29 11:14 ` Georg Bauhaus 2004-01-29 18:56 ` David Starner 0 siblings, 1 reply; 296+ messages in thread From: Georg Bauhaus @ 2004-01-29 11:14 UTC (permalink / raw) David Starner <dvdeug@email.ro> wrote: : : Any evidence for this, or is this just jingoism? Users of GNAT 3.15p have been able to work with 3.15p for quite long. The 3.4 branch (not even released yet) of GCC has an Ada front end which includes many corrections and improvements. What is wrong with working with GCC 3.4 compilers if it is better than 3.15p? Latest and greatest = highest score in version number? Versionitis. Georg ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-29 11:14 ` Georg Bauhaus @ 2004-01-29 18:56 ` David Starner 2004-01-29 19:41 ` Georg Bauhaus 0 siblings, 1 reply; 296+ messages in thread From: David Starner @ 2004-01-29 18:56 UTC (permalink / raw) On Thu, 29 Jan 2004 11:14:20 +0000, Georg Bauhaus wrote: > Latest and greatest = highest score in version number? > Versionitis. Using the version of the GNAT compiler that comes with my distribution, and hence the one that matches the latest C compiler has many advantages. If I have an obscure code generation bug on little endian MIPS or some other obscure architecture, it's probably not one that C and C++ programmers have already found and got fixed, and it may get fixed without switching major compiler versions. I'm able to compile on a larger percentage of the architectures that my C colleagues can, due to people porting GNAT on GCC-head instead of an ancient branch, and due to the number of architectures that were added to new GCC. Also, some of the Ada libraries come precompiled for the GNAT version that comes with my distribution, and the Ada compiler and debuggers and other programs are tested against that version of GCC and the distribution. Old versions of GNAT do not support the libc I'm using, for one thing. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-29 18:56 ` David Starner @ 2004-01-29 19:41 ` Georg Bauhaus 0 siblings, 0 replies; 296+ messages in thread From: Georg Bauhaus @ 2004-01-29 19:41 UTC (permalink / raw) David Starner <dvdeug@email.ro> wrote: : On Thu, 29 Jan 2004 11:14:20 +0000, Georg Bauhaus wrote: : :> Latest and greatest = highest score in version number? :> Versionitis. : : Using the version of the GNAT compiler that comes with my distribution, : and hence the one that matches the latest C compiler has many advantages. I don't understand the "hence". : I'm able to compile on a larger : percentage of the architectures the ancient obscure ones you mentioned? : that my C colleagues can, due to people : porting GNAT on GCC-head instead of an ancient branch, and due to the : number of architectures that were added to new GCC. I gather then that this is not a personal computer architecture? If not, a handheld? A cell phone? If you will be developing software for sale for one of the new million sellers, might not some support be very helpful? : Also, some of the Ada : libraries come precompiled for the GNAT version that comes with my : distribution, and the Ada compiler and debuggers and other programs are : tested against that version of GCC and the distribution. Old versions of : GNAT do not support the libc I'm using, for one thing. True. But you aren't saying that GCC 3.4 is old when it is not yet released or that it is old in a year or so? -- georg ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-29 3:03 ` Stephen Leake 2004-01-29 7:20 ` David Starner @ 2004-01-29 12:57 ` Marin David Condic 2004-01-29 13:51 ` Preben Randhol 1 sibling, 1 reply; 296+ messages in thread From: Marin David Condic @ 2004-01-29 12:57 UTC (permalink / raw) Its odd how the whole "Open Source" movement was supposed to avoid rigid heierarchies and "let a hundred flowers bloom" so to speak. Everyone would be free to do what they wanted and there would be all sorts of variations on software products and everything would be so beautiful. But once Open Source products get out there, they rather quickly have to re-invent the whole heierarchy and rigid control that quashes individual variants. Irony runs rampant! :-) MDC Stephen Leake wrote: > > This is a typical problem with open source/bazarre development > projects. If one subgroup has significantly different goals than the > general group, they will get left out. -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-29 12:57 ` Marin David Condic @ 2004-01-29 13:51 ` Preben Randhol 2004-01-30 2:46 ` Robert I. Eachus 0 siblings, 1 reply; 296+ messages in thread From: Preben Randhol @ 2004-01-29 13:51 UTC (permalink / raw) On 2004-01-29, Marin David Condic <nobody@noplace.com> wrote: > Its odd how the whole "Open Source" movement was supposed to avoid rigid > heierarchies and "let a hundred flowers bloom" so to speak. Everyone No, it wasn't. You are confusing it with the Bazaar model which is something else entirely. -- "Saving keystrokes is the job of the text editor, not the programming language." ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-29 13:51 ` Preben Randhol @ 2004-01-30 2:46 ` Robert I. Eachus 0 siblings, 0 replies; 296+ messages in thread From: Robert I. Eachus @ 2004-01-30 2:46 UTC (permalink / raw) Preben Randhol wrote: > No, it wasn't. You are confusing it with the Bazaar model which is something > else entirely. And most people who have read "The Cathedral and the Bazaar" prefer the Cathedral approach for operating systems kernels (look at Linux) and compilers (such as GCC and GNAT). One person, Linus Torvalds, approves all additions and changes to the Linux kernel. That doesn't mean that the Cathedral model is used fof the rest of Linux, in fact there are many developers and teams working on the same and different parts of Linux. But having one kernel chain, and controlled releases of new versions allows the rest of Linux to use the Bazaar model. I won't even try to describe the problems with GCC that occured recently due to a forking of the compiler development chains, but by the end of this year I hope we will all be back to a single gcc chain. -- Robert I. Eachus "The war on terror is a different kind of war, waged capture by capture, cell by cell, and victory by victory. Our security is assured by our perseverance and by our sure belief in the success of liberty." -- George W. Bush ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-28 2:50 ` Stephen Leake 2004-01-28 3:21 ` Jeff C, 2004-01-28 3:57 ` David Starner @ 2004-01-28 20:34 ` Michael Bode 2004-01-29 3:06 ` Stephen Leake 2 siblings, 1 reply; 296+ messages in thread From: Michael Bode @ 2004-01-28 20:34 UTC (permalink / raw) Stephen Leake <stephen_leake@acm.org> writes: > As a paying customer, I get fast and excellent response from ACT. I > have submitted many bug reports. Just being curious: roughly what is the price per seat for GNAT support? I don't want to ask ACT because I'm not likely to become a paying customer. -- PGP Key: http://home.t-online.de/home/michael_bode/downloads/michael_bode.key ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-28 20:34 ` Michael Bode @ 2004-01-29 3:06 ` Stephen Leake 0 siblings, 0 replies; 296+ messages in thread From: Stephen Leake @ 2004-01-29 3:06 UTC (permalink / raw) To: comp.lang.ada Michael Bode <m.g.bode@web.de> writes: > Stephen Leake <stephen_leake@acm.org> writes: > > > As a paying customer, I get fast and excellent response from ACT. I > > have submitted many bug reports. > > Just being curious: roughly what is the price per seat for GNAT > support? I'm paying $18k per year for 5 seats. But it varies (a lot) for different targets and hosts, and for different combinations of products. -- -- Stephe ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 19:19 ` David Starner ` (3 preceding siblings ...) 2004-01-27 22:13 ` Simon Wright @ 2004-01-28 12:50 ` Marin David Condic 4 siblings, 0 replies; 296+ messages in thread From: Marin David Condic @ 2004-01-28 12:50 UTC (permalink / raw) David Starner wrote: > > > My feelings too. 15 years ago, someone made a killing by releasing a > Turbo Pascal for under a hundred bucks, and made Pascal a major > language. It was probably more than 15 years ago - Early 1980's? > Free software has helped drop the off-the-shelf price of a complete > Un*x system with C, C++, Pascal and Lisp compilers to under a hundred > bucks. But I still get quoted a price of $700 for an Ada compiler. > Maybe that's fine for ye system engineers, but programmers, > especially we student programmers, don't have a wealth of money to > drop on compilers. Perhaps I need to find a new hammer. In fairness, something like Gnat has forced the cost of Ada compilers down too. Gnat is available at no cost and is of reasonable quality for most work. And there are compilers such as MSVC++ that will come in at a $700 price tag (or thereabouts - I've not priced it recently) as well. So Ada is at least in the ballpark. Where Ada may be weaker than other languages is in the area of what all surrounds the compiler itself. Things like Java present a more "Total Solution" to the potential buyer. MDC -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 18:00 ` Warren W. Gay VE3WWG 2004-01-27 19:19 ` David Starner @ 2004-01-27 20:44 ` Randy Brukardt 2004-01-27 22:15 ` Alexandre E. Kopilovitch 2 siblings, 0 replies; 296+ messages in thread From: Randy Brukardt @ 2004-01-27 20:44 UTC (permalink / raw) "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message news:fGxRb.49248$Kg6.361048@news20.bellglobal.com... ... > Perhaps we "lowly programmers" need to ditch Ada, and reinvent > our own flavour of the same. After all, only "lowly programmers" > would need to worry about such dirty things as portability. Everyone has to worry about portability. But "software engineers" use CM and design to manage the problem, rather than trying to sweep it under a rug. Conditional compilation, if present, would be used in very, very restricted circumstances. Randy. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 18:00 ` Warren W. Gay VE3WWG 2004-01-27 19:19 ` David Starner 2004-01-27 20:44 ` Randy Brukardt @ 2004-01-27 22:15 ` Alexandre E. Kopilovitch 2004-01-29 17:31 ` Standard Ada Preprocessor (conclusions) Warren W. Gay VE3WWG 2 siblings, 1 reply; 296+ messages in thread From: Alexandre E. Kopilovitch @ 2004-01-27 22:15 UTC (permalink / raw) To: comp.lang.ada Warren W. Gay wrote: > >> So the trick will be to turn CM into a programming problem, so > >> programmers and mathematicians will be instrested in solving it. > > > > No, I think the right approach is to keep improving Ada for software > > engineers and let programmers use C++. > > OUCH. I can't believe you said that. But what you expected? It is exactly you who provoked that. You was given many good explanations, but you continued to insist infinitely on your viewpoint, without taking a break for consideration of arguments of your opponent to good depth. > Perhaps this is getting to the root of the "real" problem. ;-) Certainly NO. > Perhaps we "lowly programmers" need to ditch Ada, and reinvent > our own flavour of the same. This is simply nonsense. You, and even "we" simply have no skills that are necessary for reaching anything comparable. > After all, only "lowly programmers" > would need to worry about such dirty things as portability. Oh, perhaps you really need a year of real software engineering practice. Or get a good friend of that kind. It seems that you should not rely upon your imagination in this matter. Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (conclusions) 2004-01-27 22:15 ` Alexandre E. Kopilovitch @ 2004-01-29 17:31 ` Warren W. Gay VE3WWG 2004-01-29 19:44 ` Georg Bauhaus 2004-01-30 13:25 ` Marin David Condic 0 siblings, 2 replies; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-29 17:31 UTC (permalink / raw) Alexandre E. Kopilovitch wrote: > Warren W. Gay wrote: >>>>So the trick will be to turn CM into a programming problem, so >>>>programmers and mathematicians will be instrested in solving it. >>> >>>No, I think the right approach is to keep improving Ada for software >>>engineers and let programmers use C++. >> >>OUCH. I can't believe you said that. > > But what you expected? It is exactly you who provoked that. You was given > many good explanations, but you continued to insist infinitely on your > viewpoint, without taking a break for consideration of arguments of your > opponent to good depth. It seems to me that what this all boils down to is a deeply entrenched attitude that "we don't do it 'that way', and never will". And if it is truly that way, then fine. But let's at least be honest about it. Looking at the larger question of why "Ada is Unpopular?" then, I would have to conclude from this thread (and the original) that this attitude is ONE reason that Ada has not achieved popular support. That is a shame, IMO, because there has been much effort expended into bringing software into a newer level of quality and reliability. Much could be learned from the lessons of Ada. But IMHO, there needs to be an increased look at the practical issues (I don't see += as one of them). But Ada must survive in a predominantly C/C++ world. If Ada doesn't put the engineer/programmer on a nearly equal footing with C/C++ programmers, the battle for marketshare is lost. The issues I presented, were primarily focused on bindings to this world. An area where Ada is very weak. Perhaps a secondary conclusion from this entire discussion can be that perhaps Ada is not really targeted for "General Purpose" computing after all, and never will be. Again, if that be the case, fine, but let's not try to pretend otherwise. When networks were being designed there was the holy ISO model. This was the "engineered" solution. Today however, we all use the TCP/IP model, which was designed from the ground up. Developed in part by practical experience. I think there is a lesson there, that Ada can learn from. -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (conclusions) 2004-01-29 17:31 ` Standard Ada Preprocessor (conclusions) Warren W. Gay VE3WWG @ 2004-01-29 19:44 ` Georg Bauhaus 2004-01-30 13:25 ` Marin David Condic 1 sibling, 0 replies; 296+ messages in thread From: Georg Bauhaus @ 2004-01-29 19:44 UTC (permalink / raw) Warren W. Gay VE3WWG <warren@ve3wwg.tk> wrote: : : Looking at the larger question of why "Ada is Unpopular?" : then, I would have to conclude from this thread (and the : original) that this attitude is ONE reason : that Ada has not achieved popular support. Does C# have a preprocessor? Java? -- Georg ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (conclusions) 2004-01-29 17:31 ` Standard Ada Preprocessor (conclusions) Warren W. Gay VE3WWG 2004-01-29 19:44 ` Georg Bauhaus @ 2004-01-30 13:25 ` Marin David Condic 2004-01-30 13:29 ` Lutz Donnerhacke 1 sibling, 1 reply; 296+ messages in thread From: Marin David Condic @ 2004-01-30 13:25 UTC (permalink / raw) I'm afraid I'd have to agree to some extent. Ada *must* pay attention to what real-world developers *are* doing and why they are doing it and ask "Can I be of some assistance in that area?" It *must* offer more and better to the average developer or the average developer will go somewhere else. Complex, arcane, difficult to understand techniques to get around what might be perceived as "bad" in what developers are already doing doesn't help them much. Offering them a "better" solution that is easy for them to grasp and utilize is something that helps make the sale. A good example is the whole ability of Ada to handle the "make" job right from a single command rather than having to build all sorts of complex, arcane, difficult to understand makefiles. The developer has a *better* answer with Ada than he does with C in that regard. We don't need to blindly mimmic whatever already exists - that would be the "Me Too!" answer. But if we can offer them something that does the same job in a better way - or offer them everything they've already got and *more* - then there's more incentive to use Ada. Ada should take a look at what the people who *don't* use Ada are doing and what it is they need to do their jobs better. If it really offers them more leverage and does it in simple ways that they can understand and utilize, perhaps they'll start gravitating towards the better mousetrap? MDC Warren W. Gay VE3WWG wrote: > > Looking at the larger question of why "Ada is Unpopular?" > then, I would have to conclude from this thread (and the > original) that this attitude is ONE reason > that Ada has not achieved popular support. That is a > shame, IMO, because there has been much effort > expended into bringing software into a newer level of > quality and reliability. Much could be learned from the > lessons of Ada. > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (conclusions) 2004-01-30 13:25 ` Marin David Condic @ 2004-01-30 13:29 ` Lutz Donnerhacke 2004-01-30 13:53 ` Marin David Condic 0 siblings, 1 reply; 296+ messages in thread From: Lutz Donnerhacke @ 2004-01-30 13:29 UTC (permalink / raw) * Marin David Condic wrote: > answer. But if we can offer them something that does the same job in a > better way - or offer them everything they've already got and *more* - > then there's more incentive to use Ada. My setup for plattform dependant implementations: - There is a source directory containing all portable files. - There are plattform dependant directories containing only the implementation body (usually as generic instanciation or seperate body) - Call: gnatmake -aI"platform" ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (conclusions) 2004-01-30 13:29 ` Lutz Donnerhacke @ 2004-01-30 13:53 ` Marin David Condic 2004-01-30 14:14 ` Lutz Donnerhacke 0 siblings, 1 reply; 296+ messages in thread From: Marin David Condic @ 2004-01-30 13:53 UTC (permalink / raw) I didn't say you couldn't get there. I said you couldn't get there in a way you knew was portable across all compliant Ada compilers. Dragging the pile of code over to some other system means someone has to then figure out what are all the system dependencies & deal with some alternate mechanism for selecting what files go into the build. Also, it sometimes seems like overkill to have to manage separate piles of files if the problem is rather small & self-contained. Remember that "Ada /= Gnat" and "Ada_Development_Environment /= Linux" and "Ada_Target /= x86" Sometimes there is a lot of variation in where the code has to go. MDC Lutz Donnerhacke wrote: > > My setup for plattform dependant implementations: > - There is a source directory containing all portable files. > - There are plattform dependant directories containing only the > implementation body (usually as generic instanciation or seperate body) > - Call: gnatmake -aI"platform" -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (conclusions) 2004-01-30 13:53 ` Marin David Condic @ 2004-01-30 14:14 ` Lutz Donnerhacke 0 siblings, 0 replies; 296+ messages in thread From: Lutz Donnerhacke @ 2004-01-30 14:14 UTC (permalink / raw) * Marin David Condic wrote: > Remember that "Ada /= Gnat" Of course. I'd prefer ARM compilant sources. > and "Ada_Development_Environment /= Linux" Linux, OSF/1, and NextStep. > and "Ada_Target /= x86" x86 (different families), 68k, and alpha. > Sometimes there is a lot of variation in where the code has to go. Of course. In this case simply copy the content of the platform directory into the source directory and call your prefered ada compiler. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 15:54 ` Robert I. Eachus 2004-01-27 18:00 ` Warren W. Gay VE3WWG @ 2004-01-27 19:11 ` Jeffrey Carter 2004-01-27 21:48 ` Alexandre E. Kopilovitch 2 siblings, 0 replies; 296+ messages in thread From: Jeffrey Carter @ 2004-01-27 19:11 UTC (permalink / raw) Robert I. Eachus wrote: > No, I think the right approach is to keep improving Ada for software > engineers and let programmers use C++. We are doomed to live in a world > where most code is poorly designed. All we can do is try to keep an > island of sanity, and try to insure that Ada is used where quality is > critical. (I am not saying there is no well designed C++ out there. > There is, but it is the exception, not something you can expect.) What's really needed is to only allow software engineers to choose languages and design software. Coders can only write small, well specified pieces of code for the designs developed by software engineers. The problem is distinguishing software engineers from coders and the economic pressures for poor quality software. -- Jeff Carter "Beyond 100,000 lines of code you should probably be coding in Ada." P. J. Plauger 26 ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 15:54 ` Robert I. Eachus 2004-01-27 18:00 ` Warren W. Gay VE3WWG 2004-01-27 19:11 ` Standard Ada Preprocessor Jeffrey Carter @ 2004-01-27 21:48 ` Alexandre E. Kopilovitch 2004-01-28 16:26 ` Robert I. Eachus 2 siblings, 1 reply; 296+ messages in thread From: Alexandre E. Kopilovitch @ 2004-01-27 21:48 UTC (permalink / raw) To: comp.lang.ada Robert I. Eachus wrote: > I think the right approach is to keep improving Ada for software > engineers and let programmers use C++. No, thanks. We programmers will use all the languages we see as good and possible for our current task and circumstances. Including Visual Basic, Java, Lisp, Smalltalk, assemblers etc., and including certainly Ada and C++. > We are doomed to live in a world where most code is poorly designed. Code is man-made, and man-made things of all kinds are mostly poorly designed. > All we can do is try to keep an island of sanity, Island can't be defended by itself. It was proven several times that even good air forces cannot defend their airbases by themselves, without sufficient support on the ground. Certainly you know all that very well. Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 21:48 ` Alexandre E. Kopilovitch @ 2004-01-28 16:26 ` Robert I. Eachus 2004-01-29 2:51 ` Alexandre E. Kopilovitch 0 siblings, 1 reply; 296+ messages in thread From: Robert I. Eachus @ 2004-01-28 16:26 UTC (permalink / raw) Alexandre E. Kopilovitch wrote: > Robert I. Eachus wrote: > >>I think the right approach is to keep improving Ada for software >>engineers and let programmers use C++. > > No, thanks. We programmers will use all the languages we see as good and > possible for our current task and circumstances. Including Visual Basic, Java, > Lisp, Smalltalk, assemblers etc., and including certainly Ada and C++. Agreed. I was being a little flip in the comment. My meaning was that programmers tend to ignore the software engineering issues raised by C++. I expect software engineers to continue to use whichever language is most appropriate for the purpose. I've probably now written more Ada than PL/I but it is close. (Remember I helped develop an Ada compiler that ran on Multics, and then worked on Stratus VOS for a while.) C is probably now third instead of Fortran. Since I tend to be heavily into numeric/linear algebra code, I still write Fortran from time to time--but more C than Fortran. I haven't written much Pascal in the last twenty years, but that could change. Same for BASIC, although some people do use Visual BASIC for user interfaces, that is not the type of code I usually write. (I learned C++ and did some programming in it just for the experience. In fact, I did the same thing with Prolog and a couple of other languages.) I don't know if you consider SQL, XML, and HTML as a programming languages, but recently I have written a lot of all three. And of course I have done my share of sh, csh, and Lisp programming. I even programmed some numerics code in APL... >> We are doomed to live in a world where most code is poorly designed. > > Code is man-made, and man-made things of all kinds are mostly poorly designed. That is usually referred to as Sturgeon's Law: "Sure, 90% of science fiction is crud. That's because 90% of everything is crud." ;-) >> All we can do is try to keep an island of sanity, > > Island can't be defended by itself. It was proven several times that even > good air forces cannot defend their airbases by themselves, without sufficient > support on the ground. > > Certainly you know all that very well. Of course. Again my meaning was not that we should give up entirely, but that some fights were not worth fighting over and over again. In fact, to restate my position: 1) There are good pre-processors available for Ada, for when you need to use a preprocessor with Ada. 2) There is no need for a STANDARD Ada pre-processor, because most of the need for that sort of thing in Ada is better done in Ada. I'd rather spend my efforts in the standards area on making Ada a 99% solution instead of a 90% solution. 3) I have discovered lots of "tricks" that allow you to avoid using a pre-processor with Ada. Here they are. If you like, you can use them. If you don't like, fine. 4) In particular, remembering that addresses in address clauses need not be static is a huge help. In fact, I have sometimes put declarations with address clauses in inner scopes. Then I made the addresses non-static according to Ada rules just so that the (unused) record declaration will compile with a different compiler. Also use named numbers to make "portable" representation clauses tolerable. I always put the complex expressions in one package specification and write: "for Some_Record_Type use Component_1 at Start_1 range First_Bit_1 .. Last_Bit_1; Component_2 at Start_2 range First_Bit_2 .. Last_Bit_2; Component_3 at Start_3 range First_Bit_3 .. Last_Bit_3; ..." Wherever record rep clauses are needed. Of course, Start_n, First_Bit_n, and Last_Bit_n are named numbers (usually more descriptive) from that package. That way the decision as to whether to have multiple versions of that one file, or use complicated (static) expressions to handle both little and big endian architectures can be made when I need to port the application to a new environment. Having all of the numbers used in rep specs in one place is a big help however you manage them, so I do it even if I am never planning to port the code to a new compiler or OS. -- Robert I. Eachus "The war on terror is a different kind of war, waged capture by capture, cell by cell, and victory by victory. Our security is assured by our perseverance and by our sure belief in the success of liberty." -- George W. Bush ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-28 16:26 ` Robert I. Eachus @ 2004-01-29 2:51 ` Alexandre E. Kopilovitch 2004-01-29 11:19 ` Georg Bauhaus 0 siblings, 1 reply; 296+ messages in thread From: Alexandre E. Kopilovitch @ 2004-01-29 2:51 UTC (permalink / raw) To: comp.lang.ada Robert I. Eachus wrote: > I don't know if you consider SQL, XML, and HTML as a programming > languages, Well, 3 different answers for them: 1) HTML is not a programming language, and any attempt to make it a programming language is fundamentally wrong; 2) SQL is controversial thing. Personally I don't see it as a programming language, on similar ground as for RPG. Both are too fixed on purpose (this and goal-orientation are different things). 3) about XML I'm still not sure. From its popular presentation it does not seem a programming language; but SAX somehow changes the picture. Probably the decisive feature is DTD, but it is not clear (at least for me) *what* is (or may be) programmed within a DTD, and to which limits. > 2) There is no need for a STANDARD Ada pre-processor, because most of > the need for that sort of thing in Ada is better done in Ada. I'd > rather spend my efforts in the standards area on making Ada a 99% > solution instead of a 90% solution. Ok, but there is one thing, which was mentioned by many in this thread (and perhaps by you also): the need to have multiple bodies for a package and to choose between them according to particular configuration. This need certainly does not require preprocessor, but perhaps it will be good to add some standard language construct for that - which communicates to a compiler the fact that the body of particular package must be picked from non-standard place. Nothing more than that - all other information (compiler option formats etc.) need not and cannot be standardized. Something like pragma Remote_Body; >From other side, I wonder, why - if something like this is really needed - it was not already added to existing compilers as an implementation-defined feature. Or it was? Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-29 2:51 ` Alexandre E. Kopilovitch @ 2004-01-29 11:19 ` Georg Bauhaus 2004-01-29 22:02 ` Nature of XML (was: Re: Standard Ada Preprocessor) Alexandre E. Kopilovitch 0 siblings, 1 reply; 296+ messages in thread From: Georg Bauhaus @ 2004-01-29 11:19 UTC (permalink / raw) Alexandre E. Kopilovitch <aek@vb1162.spb.edu> wrote: : : 3) about XML I'm still not sure. From its popular presentation it does not : seem a programming language; but SAX somehow changes the picture. XML is a well defined term, and the hint it has in its name is "markup language". SAX stands for Simple API for XML parsers, not a programming language. -- Georg ^ permalink raw reply [flat|nested] 296+ messages in thread
* Nature of XML (was: Re: Standard Ada Preprocessor) 2004-01-29 11:19 ` Georg Bauhaus @ 2004-01-29 22:02 ` Alexandre E. Kopilovitch 2004-01-30 8:53 ` Preben Randhol 2004-01-30 18:49 ` Nature of XML Georg Bauhaus 0 siblings, 2 replies; 296+ messages in thread From: Alexandre E. Kopilovitch @ 2004-01-29 22:02 UTC (permalink / raw) To: comp.lang.ada Georg Bauhaus wrote: > : 3) about XML I'm still not sure. From its popular presentation it does not > : seem a programming language; but SAX somehow changes the picture. > > XML is a well defined term, and the hint it has in its > name is "markup language". Yes, but you did not noticО©╫d the first letter -:) > SAX stands for Simple API for XML parsers, not a programming language. Ok, but constructing an input stream for an automaton is also programming - no less that constructing a transition matrix for it. And SAX produces exactly that - a stream of events... as far as I know. Anyway, you excluded DTDs from your consideration, and that is the most suspicious thing there. DTDs certainly can't be characterized as simply "markup". Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Nature of XML (was: Re: Standard Ada Preprocessor) 2004-01-29 22:02 ` Nature of XML (was: Re: Standard Ada Preprocessor) Alexandre E. Kopilovitch @ 2004-01-30 8:53 ` Preben Randhol 2004-01-30 17:35 ` Alexandre E. Kopilovitch 2004-01-30 18:49 ` Nature of XML Georg Bauhaus 1 sibling, 1 reply; 296+ messages in thread From: Preben Randhol @ 2004-01-30 8:53 UTC (permalink / raw) On 2004-01-29, Alexandre E. Kopilovitch <aek@VB1162.spb.edu> wrote: > Ok, but constructing an input stream for an automaton is also programming - > no less that constructing a transition matrix for it. And SAX produces exactly > that - a stream of events... as far as I know. http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?programming+language -- "Saving keystrokes is the job of the text editor, not the programming language." ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Nature of XML (was: Re: Standard Ada Preprocessor) 2004-01-30 8:53 ` Preben Randhol @ 2004-01-30 17:35 ` Alexandre E. Kopilovitch 2004-01-30 19:13 ` Preben Randhol 0 siblings, 1 reply; 296+ messages in thread From: Alexandre E. Kopilovitch @ 2004-01-30 17:35 UTC (permalink / raw) To: comp.lang.ada Preben Randhol wrote: > > constructing an input stream for an automaton is also programming - > > no less that constructing a transition matrix for it. And SAX produces exactly > > that - a stream of events... as far as I know. > > http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?programming+language => "A formal language in which computer programs are written." Well, good for you. As far as I understand from some your previous postings, your profession is chemistry, and not programming. Would you be satisfied by a definition of molecule, from which you are unable to tell reasonably, whether a crystal is simply a single huge molecule or not? Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Nature of XML (was: Re: Standard Ada Preprocessor) 2004-01-30 17:35 ` Alexandre E. Kopilovitch @ 2004-01-30 19:13 ` Preben Randhol 2004-01-31 16:04 ` Alexandre E. Kopilovitch 0 siblings, 1 reply; 296+ messages in thread From: Preben Randhol @ 2004-01-30 19:13 UTC (permalink / raw) On 2004-01-30, Alexandre E. Kopilovitch <aek@VB1162.spb.edu> wrote: >> >> http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?programming+language > >=> "A formal language in which computer programs are written." > > Well, good for you. As far as I understand from some your previous postings, > your profession is chemistry, and not programming. Would you be satisfied by > a definition of molecule, from which you are unable to tell reasonably, > whether a crystal is simply a single huge molecule or not? What on earth are you talking about? SAX is an API for XML processing. This one is event based. It is not a transformation tool per se but you can use it to generate XML -- "Saving keystrokes is the job of the text editor, not the programming language." ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Nature of XML (was: Re: Standard Ada Preprocessor) 2004-01-30 19:13 ` Preben Randhol @ 2004-01-31 16:04 ` Alexandre E. Kopilovitch 2004-01-31 16:45 ` Preben Randhol 0 siblings, 1 reply; 296+ messages in thread From: Alexandre E. Kopilovitch @ 2004-01-31 16:04 UTC (permalink / raw) To: comp.lang.ada Preben Randhol wrote: > >> http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?programming+language > > > >=> "A formal language in which computer programs are written." > > > > Well, good for you. As far as I understand from some your previous postings, > > your profession is chemistry, and not programming. Would you be satisfied by > > a definition of molecule, from which you are unable to tell reasonably, > > whether a crystal is simply a single huge molecule or not? > > What on earth are you talking about? For confusing you even more -:) , let's consider the difference between Engrus and Ruglish. With Engrus, the English language plays significant role in thinking, while with Ruglish all thinking goes with Russian only, and translation occurs immediately before coughing words out. >-- >"Saving keystrokes is the job of the text editor, not the programming > language." You may see that as irony, but the most known Ada 83 designer Jean Ichbiah turned exactly to that - the flagship product of his company aimed to saving keystrokes: http://www.textware.com . Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Nature of XML (was: Re: Standard Ada Preprocessor) 2004-01-31 16:04 ` Alexandre E. Kopilovitch @ 2004-01-31 16:45 ` Preben Randhol 0 siblings, 0 replies; 296+ messages in thread From: Preben Randhol @ 2004-01-31 16:45 UTC (permalink / raw) On 2004-01-31, Alexandre E. Kopilovitch <aek@VB1162.spb.edu> wrote: >>-- >>"Saving keystrokes is the job of the text editor, not the programming >> language." > > You may see that as irony, but the most known Ada 83 designer Jean Ichbiah > turned exactly to that - the flagship product of his company aimed to saving > keystrokes: http://www.textware.com . Yes. As I said it is the job of the text editor :-) -- "Saving keystrokes is the job of the text editor, not the programming language." ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Nature of XML 2004-01-29 22:02 ` Nature of XML (was: Re: Standard Ada Preprocessor) Alexandre E. Kopilovitch 2004-01-30 8:53 ` Preben Randhol @ 2004-01-30 18:49 ` Georg Bauhaus 2004-01-30 19:16 ` Marius Amado Alves 1 sibling, 1 reply; 296+ messages in thread From: Georg Bauhaus @ 2004-01-30 18:49 UTC (permalink / raw) Alexandre E. Kopilovitch <aek@vb1162.spb.edu> wrote: : Georg Bauhaus wrote: : :> : 3) about XML I'm still not sure. From its popular presentation it does not :> : seem a programming language; but SAX somehow changes the picture. :> :> XML is a well defined term, and the hint it has in its :> name is "markup language". : Yes, but you did not notic?d the first letter -:) Yes, but that's cheating :-) :> SAX stands for Simple API for XML parsers, not a programming language. : Ok, but constructing an input stream for an automaton is also programming - : no less that constructing a transition matrix for it. And SAX produces exactly : that - a stream of events... as far as I know. Does an API produce something? : Anyway, you excluded DTDs from your consideration, and that is the most : suspicious thing there. DTDs certainly can't be characterized as simply : "markup". "<" followed by "!" starts a declaration, a markup declaration in SGML reference syntax. <!>, a comment declaration, is the smallest comment possible in SGML. So we have comments for a start. There are DOCTYPE, ELEMENT, ENTITY, NOTATION, ATTLIST, and some more kinds of declarations, among them marked sections, which can be INCLUDED, or IGNORED, so we have conditional "compilation", and maybe forward branching? :-) Add some typing in ATTLIST and some constraints by IDREF(S). Then there is the treatment of (parameter) entity references. Does it allow computations on strings? I don't know. Here is add: * The DTD <!ENTITY x "1"> <!ENTITY y "11"> <!ELEMENT result EMPTY> <!ATTLIST result value NMTOKEN #FIXED "&x;&y;"> * the document instance <?xml version="1.0"?> <!DOCTYPE result SYSTEM "add.dtd"> <result/> * a "noncomputing" transformation that just shows the result. <transform xmlns="http://www.w3.org/1999/XSL/Transform" version="1.0"> <template match="result"> <value-of select="@value"/> </template> </transform> (This is not XML at work, but the X you mentioned, in a sense :-) -- Georg ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Nature of XML 2004-01-30 18:49 ` Nature of XML Georg Bauhaus @ 2004-01-30 19:16 ` Marius Amado Alves 2004-01-30 22:59 ` Georg Bauhaus 0 siblings, 1 reply; 296+ messages in thread From: Marius Amado Alves @ 2004-01-30 19:16 UTC (permalink / raw) To: comp.lang.ada Programming languages have semantics. XML does not. Simple, no? ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Nature of XML 2004-01-30 19:16 ` Marius Amado Alves @ 2004-01-30 22:59 ` Georg Bauhaus 2004-01-31 1:26 ` Robert I. Eachus 0 siblings, 1 reply; 296+ messages in thread From: Georg Bauhaus @ 2004-01-30 22:59 UTC (permalink / raw) Marius Amado Alves <maa@liacc.up.pt> wrote: : Programming languages have semantics. XML does not. Simple, no? If an IDREF attribute implies that an attribute value must refer to an element with the corresponding id, is that syntax? ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Nature of XML 2004-01-30 22:59 ` Georg Bauhaus @ 2004-01-31 1:26 ` Robert I. Eachus 2004-01-31 13:08 ` Nature of XML (ramblings) Marius Amado Alves 2004-02-03 1:35 ` Nature of XML Robert C. Leif 0 siblings, 2 replies; 296+ messages in thread From: Robert I. Eachus @ 2004-01-31 1:26 UTC (permalink / raw) Georg Bauhaus wrote: > Marius Amado Alves <maa@liacc.up.pt> wrote: > : Programming languages have semantics. XML does not. Simple, no? > > If an IDREF attribute implies that an attribute value must > refer to an element with the corresponding id, is that syntax? Guys, try not to get carried away! In the post that started this unending thread I said: "I don't know if you consider SQL, XML, and HTML as a programming languages, but recently I have written a lot of all three." Should I have said I don't know ... and I don't care. ;-) I consider writing SQL and HTML as part of a database interface program as programming. The fact that the SQL and HTML may be in quotes inside an Ada subprogram is not really relevant. (They count as non-comment source lines of code.) On the other hand, if I am creating a static web page in HTML I don't consider that activity to be programming. If you have a different definition you use, fine. -- Robert I. Eachus "The war on terror is a different kind of war, waged capture by capture, cell by cell, and victory by victory. Our security is assured by our perseverance and by our sure belief in the success of liberty." -- George W. Bush ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Nature of XML (ramblings) 2004-01-31 1:26 ` Robert I. Eachus @ 2004-01-31 13:08 ` Marius Amado Alves 2004-01-31 18:14 ` Georg Bauhaus 2004-02-03 1:35 ` Nature of XML Robert C. Leif 1 sibling, 1 reply; 296+ messages in thread From: Marius Amado Alves @ 2004-01-31 13:08 UTC (permalink / raw) To: comp.lang.ada Robert I. Eachus wrote: > Georg Bauhaus wrote: > >> Marius Amado Alves <maa@liacc.up.pt> wrote: >> : Programming languages have semantics. XML does not. Simple, no? >> >> If an IDREF attribute implies that an attribute value must >> refer to an element with the corresponding id, is that syntax? > Ok, I stand corrected. I should have said *operational* semantics. > Guys, try not to get carried away! In the post that started this > unending thread I said: "I don't know if you consider SQL, XML, and > HTML as a programming languages, but recently I have written a lot of > all three." > > Should I have said I don't know ... and I don't care. ;-) I consider > writing SQL and HTML as part of a database interface program as > programming. The fact that the SQL and HTML may be in quotes inside > an Ada subprogram is not really relevant. (They count as non-comment > source lines of code.) On the other hand, if I am creating a static > web page in HTML I don't consider that activity to be programming. If > you have a different definition you use, fine. > Sure. Just rambling now: it's interesting that usualy the somehow most deep, higher concepts in a domain are the least well defined: programming, programming languages. In linguistics "semantics" has been called "the science that does not exist" (Fernando Belo?). And of course some if not all linguistics semanticists agree but notice that you can still 'do' semantics even though the term is not defined. In programming we may be a bit more 'safe'. Ada, SQL, XML, HTML are all well defined. As is the notion of general purpose language. Of course Ada is such a thing whereas SQL, XML and HTML are not. SQL has Module for extending C and Ada with it self. Of course when we use SQL, etc. strings in an Ada program we're using these languages, but that does not make them programming languages. We also often use English strings in an Ada program e.g. for dialog boxes. That is a kind of multilingual programming, but I would say 'proper' multilingual programming is when you combine multiple *general purpose*, or 'operational' languages. Systems often combine Ada and C. I remember writing a system with Ada, C, Prolog, SQL, CGI (HTTP) and HTML. And of course there are the ORBs. As I said, just rambling, but sometimes I feel the need to discuss these higher concepts, to check if something has changed there with the continuing appearance of new 'technologies'. I guess no changes since last time I looked. Also, any XML appraisal touches a sensitive button in me. I used to be attracted to XML. Now I find it horrible. Just today I got this feeling independently. I was reading a PhD thesis by Parmentier, where he transforms from BibTeX format to XML for "ease of processing". He shows an entry in the the two formats side by side. The contrast in readability is stunning: BiTeX very readable, XML completely unreadable. And (La)TeX is not usually particularly readable. Also, you could see right away that an automaton for parsing the BibTeX would be much simpler to right than for the XML, and I bet more simpler to do it e.g. in Ada that to write the XSLT for the XML (and assembling and all the required tools). XML is the major hoax of two millenia. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Nature of XML (ramblings) 2004-01-31 13:08 ` Nature of XML (ramblings) Marius Amado Alves @ 2004-01-31 18:14 ` Georg Bauhaus 0 siblings, 0 replies; 296+ messages in thread From: Georg Bauhaus @ 2004-01-31 18:14 UTC (permalink / raw) Marius Amado Alves <amado.alves@netcabo.pt> wrote: : As I said, just rambling, but sometimes I feel the need to discuss these : higher concepts, to check if something has changed there with the : continuing appearance of new 'technologies'. I guess no changes since : last time I looked. Also, any XML appraisal touches a sensitive button : in me. I used to be attracted to XML. Now I find it horrible. Just today : I got this feeling independently. I was reading a PhD thesis by : Parmentier, where he transforms from BibTeX format to XML for "ease of : processing". And not ease of reading. : He shows an entry in the the two formats side by side. The : contrast in readability is stunning: BiTeX very readable, XML completely : unreadable. And (La)TeX is not usually particularly readable. Also, you : could see right away that an automaton for parsing the BibTeX would be : much simpler to right than for the XML, and I bet more simpler to do it : e.g. in Ada that to write the XSLT for the XML (and assembling and all : the required tools). XML is the major hoax of two millenia. XML is certainly a very much misunderstood language. (Is a parser for Ada easier than a parser for Oberon? Should we be writing programs in Oberon for that reason?) If you read bibliographies without the help of a computer providing a view suitable for humans, you should at least switch to SGML with SHORTTAG, and maybe OMITTAG. All this has been known when old SGML was standardised, XML is in parts a manifest of advances in editor construction -- users are supposed not to see it. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Nature of XML 2004-01-31 1:26 ` Robert I. Eachus 2004-01-31 13:08 ` Nature of XML (ramblings) Marius Amado Alves @ 2004-02-03 1:35 ` Robert C. Leif 2004-02-03 14:23 ` Georg Bauhaus 1 sibling, 1 reply; 296+ messages in thread From: Robert C. Leif @ 2004-02-03 1:35 UTC (permalink / raw) It depends on what one means as XML. XSL, XSL Fo, and XForms have methods (subprograms). Therefore, I would consider them to be rudimentary, specialized programming languages. Since they can work with schema, they effectively use the equivalent of Ada data-types. The real trick would be to augment the XML "functions" with in, in out, out attributes or elements. Bob Leif ---------------------------------------------- "Robert I. Eachus" <rieachus@comcast.net> wrote in message news:<e4ydnf8STO_5mYbdRVn-hA@comcast.com>... > Georg Bauhaus wrote: > > > Marius Amado Alves <maa@liacc.up.pt> wrote: > > : Programming languages have semantics. XML does not. Simple, no? > > > > If an IDREF attribute implies that an attribute value must > > refer to an element with the corresponding id, is that syntax? > > Guys, try not to get carried away! In the post that started this > unending thread I said: "I don't know if you consider SQL, XML, and HTML > as a programming languages, but recently I have written a lot of all three." > > Should I have said I don't know ... and I don't care. ;-) I consider > writing SQL and HTML as part of a database interface program as > programming. The fact that the SQL and HTML may be in quotes inside an > Ada subprogram is not really relevant. (They count as non-comment source > lines of code.) On the other hand, if I am creating a static web page in > HTML I don't consider that activity to be programming. If you have a > different definition you use, fine. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Nature of XML 2004-02-03 1:35 ` Nature of XML Robert C. Leif @ 2004-02-03 14:23 ` Georg Bauhaus 0 siblings, 0 replies; 296+ messages in thread From: Georg Bauhaus @ 2004-02-03 14:23 UTC (permalink / raw) Robert C. Leif <rleif@rleif.com> wrote: : It depends on what one means as XML. : XSL, o.K. : XSL Fo, Is there any kind of programming in specifying formatting objects? : and XForms o.K., mostly XPath+ predicates. : have : methods (subprograms). : Therefore, I would consider them to be : rudimentary, specialized programming languages. XSL is not exactly rudimentary I think. It is an extensible "functional" programming language, i.e. only in mode parameters (with overloading of function names, BTW). <template match="foo" > ... <template match="foo" mode="flavoured"> ... <template match="foo[@tag='T0']" > ... <template match="foo[@tag='T1']" > ... <template match="foo[@tag='T1']" mode="flavoured"> ... <template name="foo" > ... ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 8:35 ` Ole-Hjalmar Kristensen 2004-01-27 11:09 ` Georg Bauhaus @ 2004-01-27 17:50 ` Warren W. Gay VE3WWG 2004-01-27 20:42 ` Randy Brukardt 2004-01-28 12:27 ` Ole-Hjalmar Kristensen 1 sibling, 2 replies; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-27 17:50 UTC (permalink / raw) Ole-Hjalmar Kristensen wrote: >>>>>>"JC" == Jeffrey Carter <spam@spam.com> writes: > JC> Warren W. Gay VE3WWG wrote: > >> Jeffrey Carter wrote: > >>> One standard POSIX-Ada binding > >> Impossible. Some UNIces provide some API structure members, > >> while others don't, or provide something else again. Yes, > >> you can dumb it down to a "standard" (or omit non-universal > >> functionality), but by doing so you throw away functionality. > >> I find that unacceptable. > JC> There is a standard POSIX-Ada binding (Florist is an implementation of > JC> this standard) to the POSIX standard. If you want something not in > JC> this standard, obviously you're going to have to provide it yourself > JC> on some platforms. If you're on a platform that doesn't provide some > JC> of the functionality, then it's not a POSIX system. In neither case > JC> are you dealing with different versions of POSIX. > > Which does not matter if what you are doing is maintaining a program > which is running on multiple platforms and is compiled with multiple > compilers. The program has to run even if the platform does not > support a standard package like Florist. How many platforms is Florist > really available on, btw.? Listen, C programmers do this thing every day. "If some feature is available, then do it this way, else do 'it' in a more inferior way". Just because you write to "any platform", doesn't mean you have to dumb down the code for all platforms. If one O/S gives me an efficient way to do something, and I care to take advantage of this, then I can do just that with conditional compilation. By saying that an Ada program would never do that, has again condemned it to be inferior in some cases (which, IMO, is an entirely unnecessary limitation). > What matters is how do I do this while keeping the code readable and > maintainable. Of course! I could argue that conditional compilation may make it clearer where I'd run into portability problems on some platforms, because the different offending code is right in front of me (vs sitting somewhere else, unexplored). > One way to combat the combinatorial explosion of platforms * compiler > * library is to explicitly test for the features of the environment > you really need to know, not assume something because of a particular > platform/compiler. This is the approach typically used by projects > using the 'configure' tool. Yes, and that ./configure tool generates files that drive a conditional compile process. But no amount of Ada if statements can help you with conditionally with-ing certain packages, and conditional code that have to distinguish between the code that must work around differences and limitations, and deal with optional members of records etc. But this horse has been beaten to death already in this thread, and I see no reason to expand upon it again. > I would really like to have some standard configuration tool which > could take such parameters as input and produce a version of the > system tailored to the environment in which it is to be compiled and > run. This is just a high level statement of what has already been discussed. So how are you going to _implement_ this? 1. Preprocessing? 2. Conditional compilation? 3. Generate source code? The problem with #3 (which is what you seem to be suggesting) is that when there is a compile time problem, or a maintenance issue, you end up wanting to work with the generated files. BUT, you know you have to remember to work with the original INPUT files, that were used to generate it. #3 actually describes the gnatprep case, and there are options to make it easier to work this way (eg. an option that relates the line # back to the one in the original input file). But every once in a while, I end up modifying the wrong file by accident. I hate this. Conditional compilation would be a better solution for the developer because it is less error prone, and it is more natural. -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 17:50 ` Standard Ada Preprocessor Warren W. Gay VE3WWG @ 2004-01-27 20:42 ` Randy Brukardt 2004-01-27 21:41 ` Warren W. Gay VE3WWG 2004-01-28 12:27 ` Ole-Hjalmar Kristensen 1 sibling, 1 reply; 296+ messages in thread From: Randy Brukardt @ 2004-01-27 20:42 UTC (permalink / raw) "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message news:ZwxRb.49242$Kg6.360396@news20.bellglobal.com... ... > I hate this. Conditional compilation would be a better > solution for the developer because it is less error prone, > and it is more natural. I couldn't disagree. Now, try to figure out a natural way to express such conditional compilation in Ada. I can't (and I've tried to solve this problem for 20 years.) If you don't have a non-ugly way to solve the problem, the chances of anything being done about it are zero. There have been similar issues with similar resolutions in the history of Ada. For instance, you'd can't usefully redefine "*" and "/" on fixed point types in Ada 95. The problem is well known, but without a solution, it was never fixed in Ada 95. Tucker recently proposed a solution that appears to work, so we'll probably fix this in Ada 200Y. But without a workable solution, there can be no new feature. (And, because not everyone finds this necessary, the solution needs to be clean and well-integrated into the rest of the language.) Randy. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 20:42 ` Randy Brukardt @ 2004-01-27 21:41 ` Warren W. Gay VE3WWG 2004-01-28 9:10 ` Dmitry A. Kazakov 2004-01-28 23:21 ` Randy Brukardt 0 siblings, 2 replies; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-27 21:41 UTC (permalink / raw) Randy Brukardt wrote: > "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message > news:ZwxRb.49242$Kg6.360396@news20.bellglobal.com... > .... >>I hate this. Conditional compilation would be a better >>solution for the developer because it is less error prone, >>and it is more natural. > > I couldn't disagree. Now, try to figure out a natural way to express such > conditional compilation in Ada. I can't (and I've tried to solve this > problem for 20 years.) If you don't have a non-ugly way to solve the > problem, the chances of anything being done about it are zero. I agree that an elegant solution should always be sought. Especially if you are looking at the far reaching consequences of "language changes". But if this problem has existed for 20 years and no solution has come to light, then maybe it is time to consider a less elegant solution? > But without a workable solution, there can be no new feature. (And, because > not everyone finds this necessary, the solution needs to be clean and > well-integrated into the rest of the language.) > > Randy. I don't think it is a matter of "no solution exists". It is a matter of "elegancy" as you have already stated. No one here has come out and said "it won't work". There are simply biases against the approaches, which vary from "Ada doesn't do it that way" to "it's ugly". But solutions do exist. To satisfy both camps, I would make the use of such a feature something you have to enable (by compile option). Then by default, you would get what you have always had. The objection of course is that if some developers start to use it, then someday you might have to maintain code that uses it. But for shops that can mandate tools and conventions, you can mandate against its use anyway. This brings us back to a matter of preference. -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 21:41 ` Warren W. Gay VE3WWG @ 2004-01-28 9:10 ` Dmitry A. Kazakov 2004-01-29 17:39 ` Warren W. Gay VE3WWG 2004-01-28 23:21 ` Randy Brukardt 1 sibling, 1 reply; 296+ messages in thread From: Dmitry A. Kazakov @ 2004-01-28 9:10 UTC (permalink / raw) On Tue, 27 Jan 2004 16:41:50 -0500, "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote: >Randy Brukardt wrote: >> "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message >> news:ZwxRb.49242$Kg6.360396@news20.bellglobal.com... >> .... >>>I hate this. Conditional compilation would be a better >>>solution for the developer because it is less error prone, >>>and it is more natural. >> >> I couldn't disagree. Now, try to figure out a natural way to express such >> conditional compilation in Ada. I can't (and I've tried to solve this >> problem for 20 years.) If you don't have a non-ugly way to solve the >> problem, the chances of anything being done about it are zero. > >I agree that an elegant solution should always be sought. >Especially if you are looking at the far reaching consequences >of "language changes". But if this problem has existed for >20 years and no solution has come to light, then maybe it >is time to consider a less elegant solution? Conditional compilation is not less elegant it is disastrous. Ada design is based on contracts. A conditional compilation contradicts to this very principle. What kind of contract has Foo? #if ... procedure Foo (X : in out Integer); #else type Foo is record X : String; end record; #end if IMO the solution is abstract packages. -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-28 9:10 ` Dmitry A. Kazakov @ 2004-01-29 17:39 ` Warren W. Gay VE3WWG 0 siblings, 0 replies; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-29 17:39 UTC (permalink / raw) Dmitry A. Kazakov wrote: > On Tue, 27 Jan 2004 16:41:50 -0500, "Warren W. Gay VE3WWG" > <warren@ve3wwg.tk> wrote: >>Randy Brukardt wrote: >>>"Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message >>>news:ZwxRb.49242$Kg6.360396@news20.bellglobal.com... >>>.... > Conditional compilation is not less elegant it is disastrous. Ada > design is based on contracts. A conditional compilation contradicts to > this very principle. What kind of contract has Foo? > > #if ... > procedure Foo (X : in out Integer); > #else > type Foo is record > X : String; > end record; > #end if > > IMO the solution is abstract packages. I have presented the case as far as I have energy for it. The discussions here have lead me to conclude that I'll have to blaze my own trail (with help from gnatprep), as I have always had to do. I never expected much agreement on this anyway. It was however, interesting to hear that I am not the only one to share this opinion. Having said my piece on this, and I'm signing off. -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 21:41 ` Warren W. Gay VE3WWG 2004-01-28 9:10 ` Dmitry A. Kazakov @ 2004-01-28 23:21 ` Randy Brukardt 2004-01-29 17:46 ` Warren W. Gay VE3WWG 2004-01-30 3:20 ` Robert I. Eachus 1 sibling, 2 replies; 296+ messages in thread From: Randy Brukardt @ 2004-01-28 23:21 UTC (permalink / raw) "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message news:KVARb.52238$Kg6.385745@news20.bellglobal.com... > Randy Brukardt wrote: ... > > I couldn't disagree. Now, try to figure out a natural way to express such > > conditional compilation in Ada. I can't (and I've tried to solve this > > problem for 20 years.) If you don't have a non-ugly way to solve the > > problem, the chances of anything being done about it are zero. > > I agree that an elegant solution should always be sought. > Especially if you are looking at the far reaching consequences > of "language changes". But if this problem has existed for > 20 years and no solution has come to light, then maybe it > is time to consider a less elegant solution? Updating the Ada standard is as much a political process as it is a technical one. In this case, I and others tried to get a solution added to Ada 95. There was too much opposition at that time. Given that nothing has changed, I'd expect the same result if the same solutions are presented. Indeed, we have a meta-rule that we won't even waste time on issues decided during Ada 95's development unless there is significant new information. (The few that have come up, like 'in out' for functions, have ended up with precisely the same results as the last time - even with new information.) The only new information that I could think of that would help here would be an elegant solution. Certainly, the fact that the problem exists - or its scope - haven't changed a bit in the last 12 years. I'm going to spend my time on issues that have a chance to be approved (like a limited containers library), not tilting at windmills. (I've done enough of that in the last couple of years.) Otherwise, you'll get have to use a non-standard solution like Gnatprep. Randy. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-28 23:21 ` Randy Brukardt @ 2004-01-29 17:46 ` Warren W. Gay VE3WWG 2004-01-30 3:20 ` Robert I. Eachus 1 sibling, 0 replies; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-29 17:46 UTC (permalink / raw) Randy Brukardt wrote: > "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message > news:KVARb.52238$Kg6.385745@news20.bellglobal.com... >>Randy Brukardt wrote: > .... >>>I couldn't disagree. Now, try to figure out a natural way to express > such >>>conditional compilation in Ada. I can't (and I've tried to solve this >>>problem for 20 years.) If you don't have a non-ugly way to solve the >>>problem, the chances of anything being done about it are zero. >> >>I agree that an elegant solution should always be sought. >>Especially if you are looking at the far reaching consequences >>of "language changes". But if this problem has existed for >>20 years and no solution has come to light, then maybe it >>is time to consider a less elegant solution? > > Updating the Ada standard is as much a political process as it is a > technical one. In this case, I and others tried to get a solution added to > Ada 95. There was too much opposition at that time. Given that nothing has > changed, I'd expect the same result if the same solutions are presented. > Indeed, we have a meta-rule that we won't even waste time on issues decided > during Ada 95's development unless there is significant new information. > (The few that have come up, like 'in out' for functions, have ended up with > precisely the same results as the last time - even with new information.) I can only agree with this. Please understand, that this was not a discussion that "we should include X in 200Y". That is too much further down the road. The discussion stemmed from the wider context of "Why is Ada Unpopular?" I then wanted to discuss the merits of addressing conditional compilation. To say that it was ready for a proposal, would be naive ;-) But the discussion here was useful. In my mind, unless the general concensous changes, there does not seem to be an acceptable solution to the majority on this topic. But as I said in another post, it was interesting to note from others that agreed there was a need to be addressed there. > The only new information that I could think of that would help here would be > an elegant solution. Certainly, the fact that the problem exists - or its > scope - haven't changed a bit in the last 12 years. To this I was only suggesting that if an elegant solution does not emerge in 12-20 years, then perhaps there is none. And if this is the conclusion, then perhaps it is time to lower the "standard" a bit, to address practical needs. > I'm going to spend my > time on issues that have a chance to be approved (like a limited containers > library), not tilting at windmills. (I've done enough of that in the last > couple of years.) > > Otherwise, you'll get have to use a non-standard solution like Gnatprep. > > Randy. A sensible thing to do. ;-) -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-28 23:21 ` Randy Brukardt 2004-01-29 17:46 ` Warren W. Gay VE3WWG @ 2004-01-30 3:20 ` Robert I. Eachus 1 sibling, 0 replies; 296+ messages in thread From: Robert I. Eachus @ 2004-01-30 3:20 UTC (permalink / raw) Randy Brukardt wrote: > Updating the Ada standard is as much a political process as it is a > technical one. In this case, I and others tried to get a solution added to > Ada 95. There was too much opposition at that time. Given that nothing has > changed, I'd expect the same result if the same solutions are presented. > Indeed, we have a meta-rule that we won't even waste time on issues decided > during Ada 95's development unless there is significant new information. > (The few that have come up, like 'in out' for functions, have ended up with > precisely the same results as the last time - even with new information.) > > The only new information that I could think of that would help here would be > an elegant solution. Certainly, the fact that the problem exists - or its > scope - haven't changed a bit in the last 12 years. I'm going to spend my > time on issues that have a chance to be approved (like a limited containers > library), not tilting at windmills. (I've done enough of that in the last > couple of years.) > > Otherwise, you'll get have to use a non-standard solution like Gnatprep. What Randy says is 100% correct. There is a lot of work invovled in updating a language standard, and this time around there is no full-time team working on Ada 0Y, so things that didn't make the cut in Ada 9X are even less likely to get in this time. However, having said that, I will continue to work on making it easier to use Ada in place of a pre-processor language. The main requirements for that, as they have been all along, are major goals of the Ada community. As long as there is "only one Ada," and Ada compilers do static code elimination, then it is possible to use Ada if and case statements for conditional code. Yes, I know that there are some things you can't do this way. But I haven't found them to be a big deal. For example, if I have numeric code that uses 32 and 36-bit integers depending on target, I know how to define a portable integer type that doesn't require creating a 36-bit integer type on hardware that doesn't support it. Floating-point is a bit harder, but there what really changes is whether there is a type with more precision than IEEE double, and what it is called. That IS a case where I do have multiple bodies, but since the code for machines that support IEEE extended and those that don't is totally different, I don't mind mantaining separate bodies. -- Robert I. Eachus "The war on terror is a different kind of war, waged capture by capture, cell by cell, and victory by victory. Our security is assured by our perseverance and by our sure belief in the success of liberty." -- George W. Bush ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 17:50 ` Standard Ada Preprocessor Warren W. Gay VE3WWG 2004-01-27 20:42 ` Randy Brukardt @ 2004-01-28 12:27 ` Ole-Hjalmar Kristensen 2004-01-29 17:53 ` Warren W. Gay VE3WWG 1 sibling, 1 reply; 296+ messages in thread From: Ole-Hjalmar Kristensen @ 2004-01-28 12:27 UTC (permalink / raw) "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> writes: > Ole-Hjalmar Kristensen wrote: > > >>>>>>"JC" == Jeffrey Carter <spam@spam.com> writes: > > JC> Warren W. Gay VE3WWG wrote: > > >> Jeffrey Carter wrote: > > >>> One standard POSIX-Ada binding > > >> Impossible. Some UNIces provide some API structure members, > > >> while others don't, or provide something else again. Yes, > > >> you can dumb it down to a "standard" (or omit non-universal > > >> functionality), but by doing so you throw away functionality. > > >> I find that unacceptable. > > JC> There is a standard POSIX-Ada binding (Florist is an implementation of > > JC> this standard) to the POSIX standard. If you want something not in > > JC> this standard, obviously you're going to have to provide it yourself > > JC> on some platforms. If you're on a platform that doesn't provide some > > JC> of the functionality, then it's not a POSIX system. In neither case > > JC> are you dealing with different versions of POSIX. > > Which does not matter if what you are doing is maintaining a program > > which is running on multiple platforms and is compiled with multiple > > compilers. The program has to run even if the platform does not > > support a standard package like Florist. How many platforms is Florist > > really available on, btw.? > > Listen, C programmers do this thing every day. "If some feature > is available, then do it this way, else do 'it' in a more > inferior way". > For the past 20 years, I think about 90% of the code I have been writing is C or C++, so please cool down... I think you may have misread my answer. The sentence "Which does not matter if what you are doing is maintaining..." is answer to "There is a standard POSIX-Ada binding...". To re-state my position: It does not matter that there is a standard POSIX-Ada binding if I am maintaining a program on a platform where this standard POSIX binding does not exist. I still have to get my system working, somehow. The problem does not go away because of this standard binding. > Just because you write to "any platform", doesn't mean you > have to dumb down the code for all platforms. If one O/S gives > me an efficient way to do something, and I care to take > advantage of this, then I can do just that with conditional > compilation. > > By saying that an Ada program would never do that, has again > condemned it to be inferior in some cases (which, IMO, > is an entirely unnecessary limitation). > > > What matters is how do I do this while keeping the code readable and > > maintainable. > > Of course! I could argue that conditional compilation may > make it clearer where I'd run into portability problems > on some platforms, because the different offending code > is right in front of me (vs sitting somewhere else, > unexplored). > I never said conditional compilation was bad. > > One way to combat the combinatorial explosion of platforms * compiler > > * library is to explicitly test for the features of the environment > > you really need to know, not assume something because of a particular > > platform/compiler. This is the approach typically used by projects > > using the 'configure' tool. > > Yes, and that ./configure tool generates files that drive > a conditional compile process. But no amount of Ada if > statements can help you with conditionally with-ing certain > packages, and conditional code that have to distinguish > between the code that must work around differences and > limitations, and deal with optional members of records etc. > I agree. My point was simply that there is an alternative to test for compiler/platform. > But this horse has been beaten to death already in this > thread, and I see no reason to expand upon it again. > > > I would really like to have some standard configuration tool which > > could take such parameters as input and produce a version of the > > system tailored to the environment in which it is to be compiled and > > run. > > This is just a high level statement of what has already > been discussed. So how are you going to _implement_ this? > > 1. Preprocessing? > 2. Conditional compilation? > 3. Generate source code? > > The problem with #3 (which is what you seem to be suggesting) > is that when there is a compile time problem, or a maintenance > issue, you end up wanting to work with the generated files. BUT, > you know you have to remember to work with the original INPUT > files, that were used to generate it. #3 actually describes > the gnatprep case, and there are options to make it easier > to work this way (eg. an option that relates the line # > back to the one in the original input file). But every once > in a while, I end up modifying the wrong file by accident. > I hate this. Conditional compilation would be a better > solution for the developer because it is less error prone, > and it is more natural. > > -- > Warren W. Gay VE3WWG > http://ve3wwg.tk > It's been a while since I worked actively with CM systems, but basically the idea is that you select the variant you want to work on, make your changes, and then commit your changes to the system to integrate them with the other variants. Yes, you easily get into problems when wanting to work with generated files. (Unless the compiler is integrated with the CM system in such a way that the output of the compiler is related to the original file, and you do not see the intermediate file at all). What you do with a conditional compilation system is to code the exact same information as the CM system needs to keep internally into the source code. As you point out, sometimes it may not be desirable to hide this information, other times it may be for the sake of easily seeing the variant you are working on. Please observe that I am not arguing against conditional compilation. Given the state of the art, it may well be the best solution in a number of circumstances. -- C++: The power, elegance and simplicity of a hand grenade. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-28 12:27 ` Ole-Hjalmar Kristensen @ 2004-01-29 17:53 ` Warren W. Gay VE3WWG 0 siblings, 0 replies; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-29 17:53 UTC (permalink / raw) Ole-Hjalmar Kristensen wrote: > "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> writes: >>Ole-Hjalmar Kristensen wrote: >>>>>>>>"JC" == Jeffrey Carter <spam@spam.com> writes: >>> >>> JC> Warren W. Gay VE3WWG wrote: >>> >> Jeffrey Carter wrote: >>> >>> One standard POSIX-Ada binding >>> >> Impossible. Some UNIces provide some API structure members, >>> >> while others don't, or provide something else again. Yes, >>> >> you can dumb it down to a "standard" (or omit non-universal >>> >> functionality), but by doing so you throw away functionality. >>> >> I find that unacceptable. >>> JC> There is a standard POSIX-Ada binding (Florist is an implementation of >>> JC> this standard) to the POSIX standard. If you want something not in >>> JC> this standard, obviously you're going to have to provide it yourself >>> JC> on some platforms. If you're on a platform that doesn't provide some >>> JC> of the functionality, then it's not a POSIX system. In neither case >>> JC> are you dealing with different versions of POSIX. >>>Which does not matter if what you are doing is maintaining a program >>>which is running on multiple platforms and is compiled with multiple >>>compilers. The program has to run even if the platform does not >>>support a standard package like Florist. How many platforms is Florist >>>really available on, btw.? >> >>Listen, C programmers do this thing every day. "If some feature >>is available, then do it this way, else do 'it' in a more >>inferior way". > > For the past 20 years, I think about 90% of the code I have been writing > is C or C++, so please cool down... I am calmer today ;-) > I think you may have misread my answer. The sentence > "Which does not matter if what you are doing is maintaining..." is answer to > "There is a standard POSIX-Ada binding...". > > To re-state my position: It does not matter that there is a standard POSIX-Ada > binding if I am maintaining a program on a platform where this standard > POSIX binding does not exist. I still have to get my system working, somehow. > The problem does not go away because of this standard binding. Ok, yes. And my original point was that Florist does not cover all of your POSIX-like needs anyway. To get equal footing with C/C++ environments, you need Ada bindings to all of the shared libraries that GNU/Linux provides for example. As you understand, this is where things get necessarily ugly. >>>What matters is how do I do this while keeping the code readable and >>>maintainable. >> >>Of course! I could argue that conditional compilation may >>make it clearer where I'd run into portability problems >>on some platforms, because the different offending code >>is right in front of me (vs sitting somewhere else, >>unexplored). > > I never said conditional compilation was bad. I'll reiterate that readable code is first on my list also. But I would like the choice to forgo that for thin bindings. I don't there there is much justification for it outside of thin bindings. ... > Please observe that I am not arguing against conditional compilation. > Given the state of the art, it may well be the best solution in a number > of circumstances. Which was really my thrust in this thread. If an elegant solution has not emerged, then it is time to look at the "requirments" for such. One of them is suspect ;-) -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 1:00 ` Jeffrey Carter 2004-01-27 8:35 ` Ole-Hjalmar Kristensen @ 2004-01-27 17:33 ` Warren W. Gay VE3WWG 2004-01-27 19:07 ` Jeffrey Carter 1 sibling, 1 reply; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-27 17:33 UTC (permalink / raw) Jeffrey Carter wrote: > Warren W. Gay VE3WWG wrote: > >> Jeffrey Carter wrote: >>> One standard POSIX-Ada binding >> >> Impossible. Some UNIces provide some API structure members, >> while others don't, or provide something else again. Yes, >> you can dumb it down to a "standard" (or omit non-universal >> functionality), but by doing so you throw away functionality. >> I find that unacceptable. > > There is a standard POSIX-Ada binding (Florist is an implementation of > this standard) to the POSIX standard. If you want something not in this > standard, obviously you're going to have to provide it yourself on some > platforms. If you're on a platform that doesn't provide some of the > functionality, then it's not a POSIX system. In neither case are you > dealing with different versions of POSIX. So your message to the Ada world is that if Florist can't give you access to that O/S feature, then you should be using C? That's a progressive Ada answer. ;-) -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 17:33 ` Warren W. Gay VE3WWG @ 2004-01-27 19:07 ` Jeffrey Carter 2004-01-27 21:42 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 296+ messages in thread From: Jeffrey Carter @ 2004-01-27 19:07 UTC (permalink / raw) Warren W. Gay VE3WWG wrote: > So your message to the Ada world is that if Florist > can't give you access to that O/S feature, then you > should be using C? That's a progressive Ada answer. ;-) It's impossible to correct willful ignorance. You claimed you had to deal with 10 different versions of "POSIX". My answer is that there is exactly one POSIX. If you're after things not part of POSIX, that has nothing to do with POSIX. -- Jeff Carter "Beyond 100,000 lines of code you should probably be coding in Ada." P. J. Plauger 26 ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 19:07 ` Jeffrey Carter @ 2004-01-27 21:42 ` Warren W. Gay VE3WWG 0 siblings, 0 replies; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-27 21:42 UTC (permalink / raw) Jeffrey Carter wrote: > Warren W. Gay VE3WWG wrote: > >> So your message to the Ada world is that if Florist >> can't give you access to that O/S feature, then you >> should be using C? That's a progressive Ada answer. ;-) > > It's impossible to correct willful ignorance. You claimed you had to > deal with 10 different versions of "POSIX". My answer is that there is > exactly one POSIX. If you're after things not part of POSIX, that has > nothing to do with POSIX. Fine: read "POSIX-like" then. Everyone wants to be a lawyer ;-) -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-26 22:04 ` Warren W. Gay VE3WWG 2004-01-27 1:00 ` Jeffrey Carter @ 2004-01-27 2:35 ` Randy Brukardt 2004-01-27 21:47 ` Warren W. Gay VE3WWG 2004-01-27 3:54 ` Jeffrey Carter 2004-01-27 7:41 ` Standard Ada Preprocessor Pascal Obry 3 siblings, 1 reply; 296+ messages in thread From: Randy Brukardt @ 2004-01-27 2:35 UTC (permalink / raw) "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message news:e9gRb.4112$qU3.177385@news20.bellglobal.com... > Jeffrey Carter wrote: > > > Warren W. Gay VE3WWG wrote: > > > >> Matrix 10 POSIX environments x 10 versions of the same, x 4 > >> different versions of a curses library. That leaves you with > >> 400 different custom (possibly groups of) packages to work > >> with. Real slick indeed. :( > > > > One standard POSIX-Ada binding > > Impossible. Some UNIces provide some API structure members, > while others don't, or provide something else again. Yes, > you can dumb it down to a "standard" (or omit non-universal > functionality), but by doing so you throw away functionality. > I find that unacceptable. What is the point of having that functionality? Any code depending on it is by definition not portable. If you can't abstract a reasonable facimile of it, it probably isn't worth using. Otherwise, it will poison your whole application, and lock it to a few targets. What Claw does for features that aren't available on the current target is to raise Not_Supported_Error (which hopefully the caller can do something useful with, such as fall back to something that is supported). Thus, the interface is as rich as possible. That probably won't work everywhere, but if you want portability, you have to eliminate functionality that is available only a few targets. (Which is why embedded code pretty much cannot be portable by definition.) Randy. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 2:35 ` Randy Brukardt @ 2004-01-27 21:47 ` Warren W. Gay VE3WWG 2004-01-28 1:19 ` Jeffrey Carter 2004-01-28 23:35 ` Randy Brukardt 0 siblings, 2 replies; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-27 21:47 UTC (permalink / raw) Randy Brukardt wrote: > "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message > news:e9gRb.4112$qU3.177385@news20.bellglobal.com... >>Jeffrey Carter wrote: >>>Warren W. Gay VE3WWG wrote: >>>>Matrix 10 POSIX environments x 10 versions of the same, x 4 >>>>different versions of a curses library. That leaves you with >>>>400 different custom (possibly groups of) packages to work >>>>with. Real slick indeed. :( >>> >>>One standard POSIX-Ada binding >> >>Impossible. Some UNIces provide some API structure members, >>while others don't, or provide something else again. Yes, >>you can dumb it down to a "standard" (or omit non-universal >>functionality), but by doing so you throw away functionality. >>I find that unacceptable. > > What is the point of having that functionality? Any code depending on it is > by definition not portable. Performance! Some platforms for instance support asynchronous I/O. Some with bugs, others not at all. If you are writing servers, that BTW are very performance sensitive, then if you can determine that asynch I/O works properly (and well) on a given platform, then you're going to use it! Anything less is inferior. For platforms where asynch I/O is defective or just plain busted, you'll do things the plain old way you always did it (with a corresponding hit in performance). It doesn't take much imagination to see the need for this type of thing. > What Claw does for features that aren't available on the current target is > to raise Not_Supported_Error (which hopefully the caller can do something > useful with, such as fall back to something that is supported). That will really help performance. Let's add some unnecessary exceptions! -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 21:47 ` Warren W. Gay VE3WWG @ 2004-01-28 1:19 ` Jeffrey Carter 2004-01-28 12:30 ` Ole-Hjalmar Kristensen 2004-01-28 23:35 ` Randy Brukardt 1 sibling, 1 reply; 296+ messages in thread From: Jeffrey Carter @ 2004-01-28 1:19 UTC (permalink / raw) Warren W. Gay VE3WWG wrote: > Some platforms for instance support asynchronous I/O. > Some with bugs, others not at all. If you are writing > servers, that BTW are very performance sensitive, then > if you can determine that asynch I/O works properly > (and well) on a given platform, then you're going to > use it! Anything less is inferior. > > For platforms where asynch I/O is defective or just > plain busted, you'll do things the plain old way you > always did it (with a corresponding hit in performance). If the performance on these latter systems is unacceptable, then you don't have a solution for those systems. If it is acceptable, then you have no portability problem, since you can use the plain old way on all systems and achieve acceptable performance. Either way you have no problem with or without a preprocessor. -- Jeff Carter "Son of a window-dresser." Monty Python & the Holy Grail 12 ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-28 1:19 ` Jeffrey Carter @ 2004-01-28 12:30 ` Ole-Hjalmar Kristensen 0 siblings, 0 replies; 296+ messages in thread From: Ole-Hjalmar Kristensen @ 2004-01-28 12:30 UTC (permalink / raw) Jeffrey Carter <spam@spam.com> writes: > Warren W. Gay VE3WWG wrote: > > > Some platforms for instance support asynchronous I/O. > > Some with bugs, others not at all. If you are writing > > servers, that BTW are very performance sensitive, then > > if you can determine that asynch I/O works properly > > (and well) on a given platform, then you're going to > > use it! Anything less is inferior. > > For platforms where asynch I/O is defective or just > > plain busted, you'll do things the plain old way you > > always did it (with a corresponding hit in performance). > > If the performance on these latter systems is unacceptable, then you > don't have a solution for those systems. If it is acceptable, then you > have no portability problem, since you can use the plain old way on > all systems and achieve acceptable performance. Either way you have no > problem with or without a preprocessor. Ever heard about competing products? > > -- > Jeff Carter > "Son of a window-dresser." > Monty Python & the Holy Grail > 12 > -- C++: The power, elegance and simplicity of a hand grenade. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 21:47 ` Warren W. Gay VE3WWG 2004-01-28 1:19 ` Jeffrey Carter @ 2004-01-28 23:35 ` Randy Brukardt 2004-01-29 10:16 ` Ole-Hjalmar Kristensen 2004-01-29 17:58 ` Warren W. Gay VE3WWG 1 sibling, 2 replies; 296+ messages in thread From: Randy Brukardt @ 2004-01-28 23:35 UTC (permalink / raw) "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message news:a%ARb.52241$Kg6.386478@news20.bellglobal.com... > Randy Brukardt wrote: ... > > What is the point of having that functionality? Any code depending on it is > > by definition not portable. > > Performance! > > Some platforms for instance support asynchronous I/O. > Some with bugs, others not at all. If you are writing > servers, that BTW are very performance sensitive, then > if you can determine that asynch I/O works properly > (and well) on a given platform, then you're going to > use it! Anything less is inferior. Truly high-performance applications are by definition, not portable. The parts that aren't high-performance might be sharable, but again, this is a larger granularity than conditional compilation would be good for. Taking your example, you need to use tasks to make asynch. I/O work. If you don't have asynch. I/O, you probably don't want the tasks, either (because they have a substantial overhead in most cases), especially as the I/O may very well block all of the tasks. So large parts of the code will need to be different. ... > > What Claw does for features that aren't available on the current target is > > to raise Not_Supported_Error (which hopefully the caller can do something > > useful with, such as fall back to something that is supported). > > That will really help performance. Let's add some unnecessary > exceptions! Different problem. We're trying to get the code to run unmodified on as many targets as possible. Having it being self-adapting is very valuable in that aim. (Hopefully, even the binarys can run on most targets unmodified.) Randy. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-28 23:35 ` Randy Brukardt @ 2004-01-29 10:16 ` Ole-Hjalmar Kristensen 2004-01-29 17:58 ` Warren W. Gay VE3WWG 1 sibling, 0 replies; 296+ messages in thread From: Ole-Hjalmar Kristensen @ 2004-01-29 10:16 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> writes: > "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message > news:a%ARb.52241$Kg6.386478@news20.bellglobal.com... > > Randy Brukardt wrote: > ... > > > What is the point of having that functionality? Any code depending on it > is > > > by definition not portable. > > > > Performance! > > > > Some platforms for instance support asynchronous I/O. > > Some with bugs, others not at all. If you are writing > > servers, that BTW are very performance sensitive, then > > if you can determine that asynch I/O works properly > > (and well) on a given platform, then you're going to > > use it! Anything less is inferior. > > Truly high-performance applications are by definition, not portable. The > parts that aren't high-performance might be sharable, but again, this is a > larger granularity than conditional compilation would be good for. Taking > your example, you need to use tasks to make asynch. I/O work. If you don't > have asynch. I/O, you probably don't want the tasks, either (because they > have a substantial overhead in most cases), especially as the I/O may very > well block all of the tasks. So large parts of the code will need to be > different. You do not need tasks if you have asynchronous IO like the mechanisms available under POSIX, Solaris or Windows. You can use tasks with asynchronous IO of course, but you do not need them. If you do not have asynchroous IO you definitely want to use tasks, precisely because on many (most?) platforms doing IO from one task will not block other tasks. Usually you get better performance with async IO than with using tasks, because there usually will be more internal locks set in the OS, effectively stopping you from executing multiple IO operations in parallel as efficiently as with async IO. > > ... > > > What Claw does for features that aren't available on the current target > is > > > to raise Not_Supported_Error (which hopefully the caller can do > something > > > useful with, such as fall back to something that is supported). > > > > That will really help performance. Let's add some unnecessary > > exceptions! > > Different problem. We're trying to get the code to run unmodified on as many > targets as possible. Having it being self-adapting is very valuable in that > aim. (Hopefully, even the binarys can run on most targets unmodified.) > > Randy. > Yes, but he is trying to get the code to run unmodified on many platforms by making it adaptive at compile time. Same goal, different means. > > > -- C++: The power, elegance and simplicity of a hand grenade. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-28 23:35 ` Randy Brukardt 2004-01-29 10:16 ` Ole-Hjalmar Kristensen @ 2004-01-29 17:58 ` Warren W. Gay VE3WWG 2004-01-29 23:19 ` Randy Brukardt 1 sibling, 1 reply; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-29 17:58 UTC (permalink / raw) Randy Brukardt wrote: > "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message > news:a%ARb.52241$Kg6.386478@news20.bellglobal.com... >>Randy Brukardt wrote: > .... >>>What is the point of having that functionality? Any code depending on it > is >>>by definition not portable. >> >>Performance! >> >>Some platforms for instance support asynchronous I/O. >>Some with bugs, others not at all. If you are writing >>servers, that BTW are very performance sensitive, then >>if you can determine that asynch I/O works properly >>(and well) on a given platform, then you're going to >>use it! Anything less is inferior. > > Truly high-performance applications are by definition, not portable. This is a "head in the sand" argument, if I may say so. C/C++ code does this every day. To say that Ada shouldn't or needn't is statement of denial. That is my only point. >>>useful with, such as fall back to something that is supported). >> >>That will really help performance. Let's add some unnecessary >>exceptions! > > > Different problem. We're trying to get the code to run unmodified on as many > targets as possible. Having it being self-adapting is very valuable in that > aim. (Hopefully, even the binarys can run on most targets unmodified.) > > Randy. This is like probing hardware when Linux boots. Hardware is getting better, so that probes don't hang etc., but this adds time to the boot process, and for some hardware configs, is unstable and leads to hangs. Testing a version of a Linux kernel for a working asynch I/O API or not, seems much like the same thing. Its ugly, its dangerous and leads to more problems than it solves. It is much better to work all of that out at compile time, and never deal with it again. -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-29 17:58 ` Warren W. Gay VE3WWG @ 2004-01-29 23:19 ` Randy Brukardt 0 siblings, 0 replies; 296+ messages in thread From: Randy Brukardt @ 2004-01-29 23:19 UTC (permalink / raw) "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message news:qQbSb.57519$Kg6.643416@news20.bellglobal.com... > Randy Brukardt wrote: ... > > Different problem. We're trying to get the code to run unmodified on as many > > targets as possible. Having it being self-adapting is very valuable in that > > aim. (Hopefully, even the binarys can run on most targets unmodified.) > > > > This is like probing hardware when Linux boots. Hardware is > getting better, so that probes don't hang etc., but this adds > time to the boot process, and for some hardware configs, is > unstable and leads to hangs. > > Testing a version of a Linux kernel for a working asynch I/O > API or not, seems much like the same thing. Its ugly, its > dangerous and leads to more problems than it solves. It is > much better to work all of that out at compile time, and never > deal with it again. I would be likely to base the decision whether or not to use a feature (say asynch I/O) on the version information provided by the kernel. (I'm presuming that Linux isn't so primitive that it doesn't have version/distribution/supported features queries.) Plus, of course, lots of upfront testing. Thus, the same info that you're using at compile-time would be used to choose which implementation to use. I readily admit that doing this is easier on Windows, where the number of versions is somwhat bounded, and it's possible to get information (not always right, of course) in one place. (Window emulators always try to match the real thing as closely as possible, so they tend to be less incompatible than the different versions of the real thing...) Randy. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-26 22:04 ` Warren W. Gay VE3WWG 2004-01-27 1:00 ` Jeffrey Carter 2004-01-27 2:35 ` Randy Brukardt @ 2004-01-27 3:54 ` Jeffrey Carter 2004-01-27 21:53 ` Warren W. Gay VE3WWG 2004-01-27 7:41 ` Standard Ada Preprocessor Pascal Obry 3 siblings, 1 reply; 296+ messages in thread From: Jeffrey Carter @ 2004-01-27 3:54 UTC (permalink / raw) Warren W. Gay VE3WWG wrote: > Develop some Open Sourced code in > without gnatprep, and we'll see how portable it is ;-) Here's some Q&D open source, GPLed code to solve the following requirments, assuming that the proposed Ada.Directories is not available: List the names of all the files in the current directory, sorted in String order (that is, the order defined by "<" for String), one per line. Sure, this is a simple problem, but I don't have the time to work a significant problem. If you think a more complex problem should be used, provide the problem and your solution to it. All the OS and compiler dependencies are in the subunit Fill. I have provided a body for fill that works with GNAT 3.15p on any OS GNAT supports (because GNAT has already hidden the details of doing this on different OSes in GNAT.OS_Lib). Provide a different body for Fill for another compiler or OS, and explain why you need a preprocessor to do so. It's possible to push the OS and compiler dependencies down even further in this example, but I don't think it's necessary. Warning: Over 100 LOC follows. I apologize for the long posting, but am unable to respond to the challenge in a timely manner otherwise. Feel free to skip it if you like. I've used an 80-character line length, but some lines may wrap. -- File Lister: a sample open-source project without a preprocessor -- Copyright (C) 2004 by Jeffrey R. Carter -- This is free software; you can redistribute it and/or modify it under -- terms of the GNU General Public License as published by the Free Software -- Foundation; either version 2, or (at your option) any later version. -- This software is distributed in the hope that it will be useful, but WITH -- OUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY -- or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -- for more details. Free Software Foundation, 59 Temple Place - Suite -- 330, Boston, MA 02111-1307, USA. -- The root package for the File Lister software. package File_Lister is pragma Pure; end File_Lister; -- The list must be instantiated at the library level because it uses a -- controlled type. -- Print_One must be declared here so we can pass its 'access to the list's -- Iterate procedure. with Ada.Strings.Unbounded; with PragmARC.Assignment; with PragmARC.List_Unbounded; package File_Lister.Lists is procedure Assign is new PragmARC.Assignment (Element => Ada.Strings.Unbounded.Unbounded_String); package File_List is new PragmARC.List_Unbounded (Element => Ada.Strings.Unbounded.Unbounded_String); procedure Print_One (Item : in out Ada.Strings.Unbounded.Unbounded_String; Context : in out File_List.Context_Data'Class; Pos : in File_List.Position; Continue : out Boolean); -- Print Item to standard output, followed by a line terminator. end File_Lister.Lists; with Ada.Text_IO; package body File_Lister.Lists is procedure Print_One (Item : in out Ada.Strings.Unbounded.Unbounded_String; Context : in out File_List.Context_Data'Class; Pos : in File_List.Position; Continue : out Boolean) is use Ada.Strings.Unbounded; use Ada.Text_IO; begin -- Print_One Put_Line (Item => To_String (Item)); Continue := True; end Print_One; end File_Lister.Lists; -- Main procedure for File Lister with Ada.Strings.Unbounded; with File_Lister.Lists; procedure File_Lister.Program is use File_Lister.Lists; procedure Fill (List : in out File_List.Handle) is separate; -- Fill List with information about the files in the current -- directory. List : File_List.Handle; Dummy : File_List.Context_Data; begin -- File_Lister.Program Fill (List => List); List.Sort (Less_Than => Ada.Strings.Unbounded."<"'access); List.Iterate (Action => Print_One'access, Context => Dummy); end File_Lister.Program; -- File_Lister.Program.Fill: version for GNAT 3.15p on all platforms. -- Replace to accomodate other platforms or compilers. with Ada.Strings.Unbounded; with GNAT.Directory_Operations; separate (File_Lister.Program) procedure Fill (List : in out File_List.Handle) is use Ada.Strings.Unbounded; use GNAT.Directory_Operations; Dir : Dir_Type; Name : String (1 .. 1_000); Last : Natural; Info : Unbounded_String; Pos : File_List.Position; begin -- Fill Open (Dir => Dir, Dir_Name => Get_Current_Dir); Get_All : loop Read (Dir => Dir, Str => Name, Last => Last); exit Get_All when Last <= 0; Info := To_Unbounded_String (Name (Name'First .. Last) ); List.Append (Item => Info, After => List.Last, New_Pos => Pos); end loop Get_All; Close (Dir => Dir); end Fill; I've created lists of Unbounded_Strings exceeding 3,000 strings without any memory problems on a Win98 machine with 64 KB of memory, so I doubt there are many situations where this program will have memory problems. Providing error handling is left as an exercise for the reader. -- Jeff Carter "Beyond 100,000 lines of code you should probably be coding in Ada." P. J. Plauger 26 ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 3:54 ` Jeffrey Carter @ 2004-01-27 21:53 ` Warren W. Gay VE3WWG 2004-01-28 1:27 ` Jeffrey Carter ` (2 more replies) 0 siblings, 3 replies; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-27 21:53 UTC (permalink / raw) Jeffrey Carter wrote: > Warren W. Gay VE3WWG wrote: >> Develop some Open Sourced code in >> without gnatprep, and we'll see how portable it is ;-) > > Here's some Q&D open source, GPLed code to solve the following > requirments, assuming that the proposed Ada.Directories is not > available: List the names of all the files in the current directory, > sorted in String order (that is, the order defined by "<" for String), > one per line. > > Sure, this is a simple problem, but I don't have the time to work a > significant problem. If you think a more complex problem should be used, > provide the problem and your solution to it. Precisely the problem: all solutions proposed have been towards simple problems. Try writing a binding to curses, to run with: - UNIX real curses - GNU curses - PDcurses then, make it compile and work for win2k, Linux, Solaris, and HPUX. Do it without gnatprep or code generation. Yes, you can dumb this assignment down to a few curses calls and be successful at this. But try providing the full complement of functionality for each of the above curses libraries. -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 21:53 ` Warren W. Gay VE3WWG @ 2004-01-28 1:27 ` Jeffrey Carter 2004-01-29 18:02 ` Warren W. Gay VE3WWG 2004-01-28 20:35 ` Pascal Obry 2004-01-28 23:41 ` Randy Brukardt 2 siblings, 1 reply; 296+ messages in thread From: Jeffrey Carter @ 2004-01-28 1:27 UTC (permalink / raw) Warren W. Gay VE3WWG wrote: > Try writing a binding to curses, to run with: > > - UNIX real curses > - GNU curses > - PDcurses > > then, make it compile and work for win2k, Linux, Solaris, > and HPUX. Do it without gnatprep or code generation. Where's the specification for "curses" that I'm to write a binding to? Clearly it's no larger than the intersection of the 3 curses packages you named. Where's your solution, that cannot be achieved with a preprocessor? If you're asking for everything in all 3 packages, then why not say "Give me a binding to everything and make it compile and work on everything?" That's not requirements for a realistic application; they're pie-in-the-sky wishing for a DWIM system. > Yes, you can dumb this assignment down to a few curses calls > and be successful at this. But try providing the full complement > of functionality for each of the above curses libraries. This is your problem. Give me requirements for an application that needs to do X, Y, Z, and W. Show me your solution and why you think a preprocessor is necessary for it. Then I can show you how I can do it without a preprocessor. I met your challenge. It's time to put your time where your mouth is and meet mine. -- Jeff Carter "Son of a window-dresser." Monty Python & the Holy Grail 12 ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-28 1:27 ` Jeffrey Carter @ 2004-01-29 18:02 ` Warren W. Gay VE3WWG 0 siblings, 0 replies; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-29 18:02 UTC (permalink / raw) Jeffrey Carter wrote: > Warren W. Gay VE3WWG wrote: > >> Try writing a binding to curses, to run with: >> >> - UNIX real curses >> - GNU curses >> - PDcurses >> >> then, make it compile and work for win2k, Linux, Solaris, >> and HPUX. Do it without gnatprep or code generation. > > Where's the specification for "curses" that I'm to write a binding to? > Clearly it's no larger than the intersection of the 3 curses packages > you named. Where's your solution, that cannot be achieved with a > preprocessor? The idea is to put the Ada programmer on an even keel with the C/C++ programmer on the same platform. If from C you can call GNU curses API xyz (or functionality provided by xyz), they by George, it would be nice for the Ada program to take advantage of the same feature (caveat: thick bindings do not always make this comparison trivial, but think functionality). By the same token, xyz may not be available to the PDcurses programmer on some or all platforms. Win32 may be more restricted for example. -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 21:53 ` Warren W. Gay VE3WWG 2004-01-28 1:27 ` Jeffrey Carter @ 2004-01-28 20:35 ` Pascal Obry 2004-01-29 0:53 ` Jeffrey Carter 2004-01-28 23:41 ` Randy Brukardt 2 siblings, 1 reply; 296+ messages in thread From: Pascal Obry @ 2004-01-28 20:35 UTC (permalink / raw) "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> writes: > Try writing a binding to curses, to run with: > > - UNIX real curses > - GNU curses > - PDcurses > > then, make it compile and work for win2k, Linux, Solaris, > and HPUX. Do it without gnatprep or code generation. Maybe you'll call AWS a small project. It works on Windows, Linux, Solaris, MacOS-X, FreeBSD... No gnatprep. Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://perso.wanadoo.fr/pascal.obry --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-28 20:35 ` Pascal Obry @ 2004-01-29 0:53 ` Jeffrey Carter 0 siblings, 0 replies; 296+ messages in thread From: Jeffrey Carter @ 2004-01-29 0:53 UTC (permalink / raw) Pascal Obry wrote: > Maybe you'll call AWS a small project. It works on Windows, Linux, > Solaris, MacOS-X, FreeBSD... No gnatprep. I wonder if the definition of a small project is like the definition of AI. Those who say computers can't be intelligent keep raising the bar as things they said a computer couldn't do are accomplished. -- Jeff Carter "What I wouldn't give for a large sock with horse manure in it." Annie Hall 42 ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 21:53 ` Warren W. Gay VE3WWG 2004-01-28 1:27 ` Jeffrey Carter 2004-01-28 20:35 ` Pascal Obry @ 2004-01-28 23:41 ` Randy Brukardt 2004-01-29 18:04 ` Warren W. Gay VE3WWG 2004-01-30 2:33 ` Chad R. Meiners 2 siblings, 2 replies; 296+ messages in thread From: Randy Brukardt @ 2004-01-28 23:41 UTC (permalink / raw) "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message news:r4BRb.52247$Kg6.387022@news20.bellglobal.com... ... > Try writing a binding to curses, to run with: > > - UNIX real curses > - GNU curses > - PDcurses > > then, make it compile and work for win2k, Linux, Solaris, > and HPUX. Do it without gnatprep or code generation. We had this problem with our JWindows text window library. (That was a pre-cursor to Claw.) Our solution to this particular problem was to use none of the above (we didn't trust the C code much anyway, particularly on SCO.), and instead we directly intepreted the Termcap structures. That was a mess, but it worked pretty well on all of the platforms that we tried it on. (Which included Suns, Alphas, and the Unisaurs.) These days, its not clear that that would work, but so what? No one in their right mind used curses back then (late 80's) and I fail to see how that's changed now. Randy. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-28 23:41 ` Randy Brukardt @ 2004-01-29 18:04 ` Warren W. Gay VE3WWG 2004-01-30 2:33 ` Chad R. Meiners 1 sibling, 0 replies; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-29 18:04 UTC (permalink / raw) Randy Brukardt wrote: > "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message > news:r4BRb.52247$Kg6.387022@news20.bellglobal.com... > .... >>Try writing a binding to curses, to run with: >> >> - UNIX real curses >> - GNU curses >> - PDcurses >> >>then, make it compile and work for win2k, Linux, Solaris, >>and HPUX. Do it without gnatprep or code generation. > > We had this problem with our JWindows text window library. (That was a > pre-cursor to Claw.) Our solution to this particular problem was to use none > of the above (we didn't trust the C code much anyway, particularly on SCO.), > and instead we directly intepreted the Termcap structures. That was a mess, > but it worked pretty well on all of the platforms that we tried it on. > (Which included Suns, Alphas, and the Unisaurs.) Well, I would agree that the ideal solution would be to rewrite all GNU libraries in Ada. I would agree that a POSIX kernel in Ada would be nice (or AdaOS). But until that happens, I don't have the luxury of rewriting everything ;-) > These days, its not clear that that would work, but so what? No one in their > right mind used curses back then (late 80's) and I fail to see how that's > changed now. > > Randy. Curses is far from dead. There are still a large number of text mode terminals used around the globe. -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-28 23:41 ` Randy Brukardt 2004-01-29 18:04 ` Warren W. Gay VE3WWG @ 2004-01-30 2:33 ` Chad R. Meiners 2004-01-30 18:00 ` Warren W. Gay VE3WWG 1 sibling, 1 reply; 296+ messages in thread From: Chad R. Meiners @ 2004-01-30 2:33 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> wrote in message news:101gi766nkf57b6@corp.supernews.com... > These days, its not clear that that would work, but so what? No one in their > right mind used curses back then (late 80's) and I fail to see how that's > changed now. I always thought they called it curses due to the foul language I used when trying to get it to work properly ;-) Win32 console API's on the other hand are a dream compared to my experience with curses ;-) -CRM ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-30 2:33 ` Chad R. Meiners @ 2004-01-30 18:00 ` Warren W. Gay VE3WWG 2004-01-30 22:52 ` Blinking text Chad R. Meiners 0 siblings, 1 reply; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-30 18:00 UTC (permalink / raw) Chad R. Meiners wrote: > "Randy Brukardt" <randy@rrsoftware.com> wrote in message > news:101gi766nkf57b6@corp.supernews.com... > >>These days, its not clear that that would work, but so what? No one in >> their >>right mind used curses back then (late 80's) and I fail to see how that's >>changed now. > > I always thought they called it curses due to the foul language I used when > trying to get it to work properly ;-) Some serial terminals do tend to have that effect on developers and users alike ;-) > Win32 console API's on the other hand are a dream compared to my experience > with curses ;-) > > -CRM That is probably true, at least until you need the blinking attribute. The problem is sufficiently difficult that the blink attribute does not exist in PDcurses (yet), where it can be used in win32 environments. -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Blinking text 2004-01-30 18:00 ` Warren W. Gay VE3WWG @ 2004-01-30 22:52 ` Chad R. Meiners 2004-02-06 17:14 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 296+ messages in thread From: Chad R. Meiners @ 2004-01-30 22:52 UTC (permalink / raw) "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message news:FYwSb.43814$mf4.1513524@news20.bellglobal.com... > > That is probably true, at least until you need the blinking > attribute. The problem is sufficiently difficult that the > blink attribute does not exist in PDcurses (yet), where it > can be used in win32 environments. You *could* fake the blink attribute on win32 with a task that updates the screen regularly, but I don't care too much for blinking text so I never missed it. -CRM ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Blinking text 2004-01-30 22:52 ` Blinking text Chad R. Meiners @ 2004-02-06 17:14 ` Warren W. Gay VE3WWG 0 siblings, 0 replies; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-02-06 17:14 UTC (permalink / raw) Chad R. Meiners wrote: > "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message > news:FYwSb.43814$mf4.1513524@news20.bellglobal.com... > >>That is probably true, at least until you need the blinking >>attribute. The problem is sufficiently difficult that the >>blink attribute does not exist in PDcurses (yet), where it >>can be used in win32 environments. > > You *could* fake the blink attribute on win32 with a task that updates the > screen regularly, but I don't care too much for blinking text so I never > missed it. > > -CRM This is precisely what I suggested to the PDcurses maintainer some time ago. But to date this hasn't been included AFAIK, leaving me to conclude that it must be sufficiently messy that he's not been inclined to bother with it. The Blinking attribute is clearly one that should not be abused. Yet there are times when you want it, for things like "DANGER Will Robinson... do you really want to delete that file? (I would only blink the "DANGER" part, BTW). A "web parallel" to the blink attribute are those stupid animated graphics that spin and fuss around beside the news article text. It becomes hard to ignore, when the text wraps around these stupid animated images. -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-26 22:04 ` Warren W. Gay VE3WWG ` (2 preceding siblings ...) 2004-01-27 3:54 ` Jeffrey Carter @ 2004-01-27 7:41 ` Pascal Obry 2004-01-27 21:53 ` Warren W. Gay VE3WWG 3 siblings, 1 reply; 296+ messages in thread From: Pascal Obry @ 2004-01-27 7:41 UTC (permalink / raw) "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> writes: > Impossible. Some UNIces provide some API structure members, > while others don't, or provide something else again. Yes, > you can dumb it down to a "standard" (or omit non-universal > functionality), but by doing so you throw away functionality. > I find that unacceptable. Well yet if the standard offers 99% of the functionality you need it remains you to do the work for the remaining 1% ! Not that bad :) Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://perso.wanadoo.fr/pascal.obry --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 7:41 ` Standard Ada Preprocessor Pascal Obry @ 2004-01-27 21:53 ` Warren W. Gay VE3WWG 0 siblings, 0 replies; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-27 21:53 UTC (permalink / raw) Pascal Obry wrote: > "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> writes: >>Impossible. Some UNIces provide some API structure members, >>while others don't, or provide something else again. Yes, >>you can dumb it down to a "standard" (or omit non-universal >>functionality), but by doing so you throw away functionality. >>I find that unacceptable. > > Well yet if the standard offers 99% of the functionality you need it remains > you to do the work for the remaining 1% ! Not that bad :) > > Pascal. Who guarantees that it will only be 1%? ;-) -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-26 19:14 ` Standard Ada Preprocessor Jeffrey Carter 2004-01-26 22:04 ` Warren W. Gay VE3WWG @ 2004-01-27 0:06 ` Robert I. Eachus 2004-01-27 21:55 ` Warren W. Gay VE3WWG 2004-01-27 0:17 ` Standard Ada Preprocessor Alexandre E. Kopilovitch 2 siblings, 1 reply; 296+ messages in thread From: Robert I. Eachus @ 2004-01-27 0:06 UTC (permalink / raw) Jeffrey Carter wrote: > This thread is about a standard preprocessor (see the subject). But as > someone who has done this kind of thing without a preprocessor and > prefer the results, I'm convinced that what's needed is a portable way > to tell the compiler to use the package body from the Win32 directory, > or from the UNIX directory, or from the VMS directory. Amen! Incidently, I use symbolic links. It is a little more complicated that using search paths in environment variables, but I feel it gives me better control. -- Robert I. Eachus "The war on terror is a different kind of war, waged capture by capture, cell by cell, and victory by victory. Our security is assured by our perseverance and by our sure belief in the success of liberty." -- George W. Bush ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 0:06 ` Robert I. Eachus @ 2004-01-27 21:55 ` Warren W. Gay VE3WWG 2004-01-28 1:34 ` Jeffrey Carter 0 siblings, 1 reply; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-27 21:55 UTC (permalink / raw) Robert I. Eachus wrote: > Jeffrey Carter wrote: > >> This thread is about a standard preprocessor (see the subject). You're right. But if you followed the thread, we progressed from there ;-) > But as >> someone who has done this kind of thing without a preprocessor and >> prefer the results, I'm convinced that what's needed is a portable way >> to tell the compiler to use the package body from the Win32 directory, >> or from the UNIX directory, or from the VMS directory. > > Amen! Incidently, I use symbolic links. It is a little more > complicated that using search paths in environment variables, but I feel > it gives me better control. Ostriches, with head in a warm sandy place. -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 21:55 ` Warren W. Gay VE3WWG @ 2004-01-28 1:34 ` Jeffrey Carter 2004-01-30 17:19 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 296+ messages in thread From: Jeffrey Carter @ 2004-01-28 1:34 UTC (permalink / raw) Warren W. Gay VE3WWG wrote: > Ostriches, with head in a warm sandy place. An ad hominem attack! How nice! A sure sign of an indefensible position. -- Jeff Carter "Son of a window-dresser." Monty Python & the Holy Grail 12 ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-28 1:34 ` Jeffrey Carter @ 2004-01-30 17:19 ` Warren W. Gay VE3WWG 2004-01-30 19:06 ` Frank J. Lhota 0 siblings, 1 reply; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-30 17:19 UTC (permalink / raw) Jeffrey Carter wrote: > Warren W. Gay VE3WWG wrote: > >> Ostriches, with head in a warm sandy place. > > An ad hominem attack! How nice! A sure sign of an indefensible position. Fair enough. I hear that ostrich meat is tasty ;-) -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-30 17:19 ` Warren W. Gay VE3WWG @ 2004-01-30 19:06 ` Frank J. Lhota 2004-02-10 11:18 ` stephen.freeman9 0 siblings, 1 reply; 296+ messages in thread From: Frank J. Lhota @ 2004-01-30 19:06 UTC (permalink / raw) > Fair enough. I hear that ostrich meat is tasty ;-) ... and low in fat. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-30 19:06 ` Frank J. Lhota @ 2004-02-10 11:18 ` stephen.freeman9 2004-02-10 17:45 ` Language Design (was Standard Ada Preprocessor) Warren W. Gay VE3WWG 0 siblings, 1 reply; 296+ messages in thread From: stephen.freeman9 @ 2004-02-10 11:18 UTC (permalink / raw) This argument about C (and D) is very interesting - I have been working on Safety related work (Uk Defstan SIL 3/ Sil 4 software and DO178b level a) for flying aircraft. We use Ada (Spark Ada at that) to develop code. However the world in general knows C not Ada. D helps to strengthen C as does Misra (see Misra 2 for latest invocation) but as said - what is lacking is definition of ranges (and strong typing) . A possible solution I'm working on is "E" for want of a more novel name. This should look like C but ask the programmer to define typedef's for each logically different type s/he is using and as a comment specify the ranges that that is valid for. It then needs a pre-processor to parse that to check for inconsistancies. (perhaps convert it to Ada?) "Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> wrote in message news:sWxSb.74$bn1.6@nwrdny02.gnilink.net... > > Fair enough. I hear that ostrich meat is tasty ;-) > > ... and low in fat. > > ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Language Design (was Standard Ada Preprocessor) 2004-02-10 11:18 ` stephen.freeman9 @ 2004-02-10 17:45 ` Warren W. Gay VE3WWG 0 siblings, 0 replies; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-02-10 17:45 UTC (permalink / raw) stephen.freeman9 wrote: > This argument about C (and D) is very interesting - I have been working on > Safety related work (Uk Defstan SIL 3/ Sil 4 software and DO178b level a) > for flying aircraft. We use Ada (Spark Ada at that) to develop code. > However the world in general knows C not Ada. D helps to strengthen C as > does Misra (see Misra 2 for latest invocation) but as said - what is > lacking is definition of ranges (and strong typing) . A possible solution > I'm working on is "E" for want of a more novel name. This should look like > C but ask the programmer to define typedef's for each logically different > type s/he is using and as a comment specify the ranges that that is valid > for. It then needs a pre-processor to parse that to check for > inconsistancies. (perhaps convert it to Ada?) For my taste, there is too much interest in creating new languages that look like C. I am OK with borrowing successful concepts from any language (if it makes sense), but to me D is just an improved C, just like Java is a flavour of C++, and C# yet another flavour. IMO, it would be better for the designer to step back from experienace in several languages (not just the C/C++/C#/Java camp) and look at the problems that the language is designed to solve. Learn from the ancestors, but some small subset of those languages shouldn't dictate how the new one gets defined. IOW, the design effort shouldn't be stated as "a better version of C" ;-) What that kind of statement effectively says is that C is so good that we should use that as a starting point for improving that model. I would rather "they" examine the questions: what has C done well? What has PASCAL done well? What has Modula-3 done well? What has Ada done well? What has <functional languages> done well? Take away the winning concepts and use only the concepts as a basis for design. Surely the C string handling and arrays in general is flawed by the lack of range constraints. Can "they" not improve upon that? Well, no: not if their mandate is a better C. </rant> ;-) -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-26 19:14 ` Standard Ada Preprocessor Jeffrey Carter 2004-01-26 22:04 ` Warren W. Gay VE3WWG 2004-01-27 0:06 ` Robert I. Eachus @ 2004-01-27 0:17 ` Alexandre E. Kopilovitch 2 siblings, 0 replies; 296+ messages in thread From: Alexandre E. Kopilovitch @ 2004-01-27 0:17 UTC (permalink / raw) To: comp.lang.ada Jeffrey Carter wrote: > I'm convinced that what's needed is a portable way > to tell the compiler to use the package body from the Win32 directory, > or from the UNIX directory, or from the VMS directory. A pragma for use after package's specs: #pragma Remote_Body (Store_Name = "Bodies"); (relegating all other to a particular compiler and its User's Guide...) - something like this? Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-26 18:03 ` Warren W. Gay VE3WWG 2004-01-26 19:14 ` Standard Ada Preprocessor Jeffrey Carter @ 2004-01-26 23:44 ` Georg Bauhaus 2004-01-27 22:04 ` Warren W. Gay VE3WWG 2004-01-27 0:15 ` Standard Ada Preprocessor (Was: why ada is so unpopular ?) Robert I. Eachus 2 siblings, 1 reply; 296+ messages in thread From: Georg Bauhaus @ 2004-01-26 23:44 UTC (permalink / raw) Warren W. Gay VE3WWG <warren@ve3wwg.tk> wrote: : For example, you'd pretty much have to have a different package : for every POSIX-like environment, because of changes like what : was included in the stat(2) structure (and others). Worse, you'd : have to matrix it out to the various releases of Linux, FreeBSD, : NetBSD, OpenBSD, Solaris, IRIX, HPUX etc. You cannot hope to : accommodate all of these differences by package names. Not throwing in everything, (though that adds combinations no matter which method is chosen to deal with the variety), the following works for me (and also in more complex arrangements). I will have to make exactly two changes if I want to switch the OS/POSIX combination: with OS; -- see next procedure run is use OS.BSD; sample_file: constant := -321; -- just any unlikely file descriptor, don't create havoc -- We need C.int comparisons for function returns, so: use type int; begin -- bad style and all sorts of things... if C_MINUS_1 = lockf(sample_file, F_LOCK, 8192) then raise Program_Error; end if; end run; with Systems.BSD_x86; -- with other Systems as well... package OS is package BSD renames Systems.BSD_x86.FantasyBSD.Non_Standard_POSIX; -- package Linux renames ...; -- package SUNOS renames ...; -- package MacOS renames ...; end OS; package Systems is end Systems; with Interfaces.C; use Interfaces; package Systems.BSD_x86 is -- POSIX items for all flavours of BSD for x86. -- As there are allegedly both Standard POSIX items and non-standard -- ones on some (possibly older) systems, see Warren W. Gay's posting, -- there is a Non_Standard_POSIX and a Standard_POSIX package in -- each BSD variant package. -- ---------------- -- FantasyBSD -- ---------------- package FantasyBSD is package Non_Standard_POSIX is use type C.int; C_MINUS_1: constant C.int := -1; -- indicating a failing function F_LOCK: constant C.int := 3_4829; -- surprising value subtype off_t is C.long; subtype int is C.int; function lockf (file_descriptor: int; function_number: int; bytes: off_t) return int; pragma import(C, lockf); end Non_Standard_POSIX; package Standard_POSIX is -- rename needed functions from ISO Ada Bindings end Standard_POSIX; end FantasyBSD; -- ---------------- -- OpenBSD -- ---------------- package OpenBSD is end OpenBSD; -- ---------------- -- FreeBSD -- ---------------- package FreeBSD is end FreeBSD; -- ... end Systems.BSD_x86; georg@strudel:~/rsrc/Ada/wg$ gnatmake run gcc -c run.adb gcc -c os.ads gcc -c systems.ads gcc -c systems-bsd_x86.ads gnatbind -x run.ali gnatlink run.ali georg@strudel:~/rsrc/Ada/wg$ ./run raised PROGRAM_ERROR : run.adb:15 explicit raise georg@strudel:~/rsrc/Ada/wg$ Most outstanding bug: the program has been compiled on Linux strudel 2.4.18 #1 Fri May 2 17:22:29 CEST 2003 i686 unknown ;-) : I get frustrated with the short sightedness of the "not invented : here syndrome". But maybe, that is just me. ;-) Hm. Plan 9's C enviroment does well without #ifdefs, even though it has to provide this environment for different architectures. This is reported to be confusing for those who have unfortunately been told to use #if defined __THIS_HEADER__ in header files, as a replacement for a design that keeps things separate so multiple inclusion does not occur. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-26 23:44 ` Georg Bauhaus @ 2004-01-27 22:04 ` Warren W. Gay VE3WWG 2004-01-28 2:47 ` Georg Bauhaus 0 siblings, 1 reply; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-27 22:04 UTC (permalink / raw) Georg Bauhaus wrote: > Warren W. Gay VE3WWG <warren@ve3wwg.tk> wrote: > : For example, you'd pretty much have to have a different package > : for every POSIX-like environment, because of changes like what > : was included in the stat(2) structure (and others). Worse, you'd > : have to matrix it out to the various releases of Linux, FreeBSD, > : NetBSD, OpenBSD, Solaris, IRIX, HPUX etc. You cannot hope to > : accommodate all of these differences by package names. > > Not throwing in everything, (though that adds combinations no > matter which method is chosen to deal with the variety), > the following works for me (and also in more complex arrangements). > I will have to make exactly two changes if I want to switch the > OS/POSIX combination: > > with OS; -- see next > procedure run is > > use OS.BSD; ... But this gets back to maintaining many mostly parallel pieces of code. For some projects, this is very incovenient. There I said it. I wish for more convenience to deal with portability. > : I get frustrated with the short sightedness of the "not invented > : here syndrome". But maybe, that is just me. ;-) > > Hm. Plan 9's C enviroment does well without #ifdefs, even though > it has to provide this environment for different architectures. How does this help the Ada scenario? I am not saying that some situations cannot be best addressed with separately maintained packages/bodies. But it is not the best solution for some projects that are very platform sensitive (see earlier posts for why). > This is reported to be confusing for those who have unfortunately > been told to use > > #if defined __THIS_HEADER__ > > in header files, as a replacement for a design that keeps things > separate so multiple inclusion does not occur. C header files are a mess. Ada packages are soooo different from C, that we don't need to even go there. However, there is a case to conditionally with a package, just as a C program has a case for conditionally #include-ing. I can't add to the plan9 case, since I've not dug too deep into it. Unless they change their copyright restrictions, I will not make any investment of my time there. -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-27 22:04 ` Warren W. Gay VE3WWG @ 2004-01-28 2:47 ` Georg Bauhaus 2004-01-30 17:29 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 296+ messages in thread From: Georg Bauhaus @ 2004-01-28 2:47 UTC (permalink / raw) Warren W. Gay VE3WWG <warren@ve3wwg.tk> wrote: : : But this gets back to maintaining many mostly parallel : pieces of code. Well, yes. It is very centralised though. The ideal scenario for me would be a declaration (using clickable check boxes or editing text) that effectively creates a program view. This means, I specify what I want at a high level and the computer compiles this into a corresponding source text view. When I see if <this> context_clause_A fi source source if <this> variant_A else variant_B fi source source if <this> addition_A fi source this looks like assembly language to me, with all its flexibility. But why do we build higher level text structures and compilers? It is interesting that programmers and in particular those with an engineering attitude have not built machinery to solve the problem in a high level systematic manner. Why? There is an opportunity to sell something, or selling support, or starting a community effort... -- Georg ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-28 2:47 ` Georg Bauhaus @ 2004-01-30 17:29 ` Warren W. Gay VE3WWG 2004-01-30 19:06 ` Georg Bauhaus 2004-01-31 8:42 ` Marin David Condic 0 siblings, 2 replies; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-30 17:29 UTC (permalink / raw) Georg Bauhaus wrote: > Warren W. Gay VE3WWG <warren@ve3wwg.tk> wrote: > : > : But this gets back to maintaining many mostly parallel > : pieces of code. > > Well, yes. It is very centralised though. > The ideal scenario for me would be a declaration (using > clickable check boxes or editing text) that > effectively creates a program view. This means, I specify > what I want at a high level and the computer compiles this > into a corresponding source text view. True, but there are other factors to consider in development. Mind you this is a "developer convenience" issue, but once you compile and/or debug, and you realize that line 905 of xyz.adb needs to be changed, where must the real editing be done? Probably not the file that the compiler used, because it was generated by some other tool. Often what happens is the xyz.adb gets edited, and the change is lost. Tracing back to the where the change really has to go is inconvenient, if not extremely so. If you're trying to sort out a problem with open sourced project(s), then you have to sort out how the creator/maintainer set things up for you (each project will be different). Again, I find this annoying at best. > When I see > > if <this> > context_clause_A > fi > source > source > if <this> > variant_A > else > variant_B > fi > source > source > if <this> > addition_A > fi > source > > this looks like assembly language to me, with all its flexibility. Yes, this is ugly, but not always _this_ ugly. Furthermore, if this ugliness were confined only to thin bindings, I could live with that. No Ada programmer wants to see this throughout his project. > But why do we build higher level text structures and compilers? I don't understand your point here. > It is interesting that programmers and in particular those > with an engineering attitude have not built machinery to solve > the problem in a high level systematic manner. Why? > > There is an opportunity to sell something, or selling support, > or starting a community effort... > > -- Georg I think the real reason is that people are holding out for the "ivory tower" (aka "elegant") solution. There is nothing wrong with this in principle, but I think it is fair to say that after 12-20 years, if no solution has emerged, then the standard has been set too high. -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-30 17:29 ` Warren W. Gay VE3WWG @ 2004-01-30 19:06 ` Georg Bauhaus 2004-01-31 8:42 ` Marin David Condic 1 sibling, 0 replies; 296+ messages in thread From: Georg Bauhaus @ 2004-01-30 19:06 UTC (permalink / raw) Warren W. Gay VE3WWG <warren@ve3wwg.tk> wrote: : you : realize that line 905 of xyz.adb needs to be changed, : where must the real editing be done? Probably not the : file that the compiler used, because it was generated : by some other tool. Often what happens is the xyz.adb : gets edited, and the change is lost. Hm, how can that be when you have deterministic rules that will lead to one source text view given N configuration inputs? Of course programmers will have to be aware that they have to consider the configuration with care. :> this looks like assembly language to me, with all its flexibility. : : Yes, this is ugly, but not always _this_ ugly. Furthermore, : if this ugliness were confined only to thin bindings, I : could live with that. No Ada programmer wants to see this : throughout his project. : :> But why do we build higher level text structures and compilers? : : I don't understand your point here. Assembly language may be useful here and there but it seems like programming is mostly done in higher level languages. If configuration with conditionals in source files and assembly languge are considered analogous, my expectation is that it makes sense to create a higher level language for configuration. From another comment in this thread I conclude that ClearCase has something like this. -- Georg ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-30 17:29 ` Warren W. Gay VE3WWG 2004-01-30 19:06 ` Georg Bauhaus @ 2004-01-31 8:42 ` Marin David Condic 2004-02-02 17:28 ` Warren W. Gay VE3WWG 1 sibling, 1 reply; 296+ messages in thread From: Marin David Condic @ 2004-01-31 8:42 UTC (permalink / raw) If there is no elegant solution, then the alternatives are to create an inelegant one or live with the problem. Or switch to a language that has the inelegant solution. My concern is with the last alternative. People look at Ada and say "I can't make it do what I want it to do..." The Ada advocates say "Well, you can but you have to turn your head just right, stand on one leg, blink your eyes three times...." Or some version of "Go solve it with a tool outside the language...." So the developer does: He uses C++. We don't have to make Ada look like C, C++ or Java, but we ought to aim for at least providing a way of doing important things that these languages can do in some Ada-ish manner. You can't stop people from wanting things you don't like. You can refuse to sell it to them (as one should, if it is immoral), but that just sends them off to someone who *will* sell it to them. MDC Warren W. Gay VE3WWG wrote: > > I think the real reason is that people are holding out for > the "ivory tower" (aka "elegant") solution. There is nothing > wrong with this in principle, but I think it is fair to say > that after 12-20 years, if no solution has emerged, then the > standard has been set too high. > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-31 8:42 ` Marin David Condic @ 2004-02-02 17:28 ` Warren W. Gay VE3WWG 0 siblings, 0 replies; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-02-02 17:28 UTC (permalink / raw) Marin David Condic wrote: > If there is no elegant solution, then the alternatives are to create an > inelegant one or live with the problem. Or switch to a language that has > the inelegant solution. My concern is with the last alternative. People > look at Ada and say "I can't make it do what I want it to do..." The Ada > advocates say "Well, you can but you have to turn your head just right, > stand on one leg, blink your eyes three times...." This would give me trouble ;-) ... > We don't have to make Ada look like C, C++ or Java, but we ought to aim > for at least providing a way of doing important things that these > languages can do in some Ada-ish manner. Which was the point of the discussion. > > You can't stop people from wanting things you don't like. You can refuse > to sell it to them (as one should, if it is immoral), but that just > sends them off to someone who *will* sell it to them. > > MDC I was tempted to compare this with "gun control", but that might lead to another entirely OT thread ;-) -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-26 18:03 ` Warren W. Gay VE3WWG 2004-01-26 19:14 ` Standard Ada Preprocessor Jeffrey Carter 2004-01-26 23:44 ` Georg Bauhaus @ 2004-01-27 0:15 ` Robert I. Eachus 2004-01-27 22:05 ` Warren W. Gay VE3WWG 2 siblings, 1 reply; 296+ messages in thread From: Robert I. Eachus @ 2004-01-27 0:15 UTC (permalink / raw) Robert I. Eachus wrote: > My point was that we can fix System to some extent, since Strings can > now be static. Of course there is NO universal solution because on > some systems some values will be static, and on others they won't be > known until run-time. But if we "fix" System so that the compiler can > document such things, then users will be able to do what they can do. Warren W. Gay VE3WWG wrote: > I hate "no universal solution" fixes. I hate having to revist > things multiple times. I hate preprocessors too, but I hate > the other issues more. I think you misunderstood what I was saying here. On some systems memory size is static. This is common in embedded systems, the RAM may be part of the CPU chip. In that case users would want the compiler to use a static value for memory size. But on a PC, if I stick another DIMM in and reboot, I want my (previously compiled) program to see the right memory size. So a compiler targeting a PC should use a system call to get the memory size at run-time. That was what I meant by "no universal solution." We (the ARG) should give Implementation Advice about when the values in package System should be static and when they should use a system call. But the choice should be left to the implementor, because he knows the characteristics of the actual target. > >> I certainly don't buy the "conditional compilation must happen at >> compile time" argument. It may be true in most embedded applications >> that you can statically know these things at compile time. But I also >> deal with creating .dlls that must match the current hardware. If >> that means that I have to generate self-modifying code, so be it. (In >> practice I build and install the correct dispatch table when >> initializing a .dll.) > > > DLLs only are part of _one_ vendor's solutions. Try dealing with > different POSIX-like environments from _many_ vendors. The solutions > get dirtier and quickly. > > For example, you'd pretty much have to have a different package > for every POSIX-like environment, because of changes like what > was included in the stat(2) structure (and others). Worse, you'd > have to matrix it out to the various releases of Linux, FreeBSD, > NetBSD, OpenBSD, Solaris, IRIX, HPUX etc. You cannot hope to > accommodate all of these differences by package names. Throw > into the mix a different set of compilers, and different versions > of a readline library, and the solution is entirely doomed. > >> But every once in a while I like to dream about the facility that Ada >> environments were supposed to have had, where I could just say compile >> this code for these dozen hardware specifications, and package the >> result in one load module. ;-) >> >> However, back to the world as it exists. > > > The world as it is, does not need to remain entirely static ;-) > >> The discipline of Ada is that you should be able to push most, if not >> all, hardware dependencies first into package and other unit bodies, >> and then into variant parts and if statements. > > > Ok, so we're getting back to the argument "Ada doesn't do it > this way". This works for limited embedded environments, but > I think you're hearing from others, that it still does not > do the job well enough in the modern Open Sourced world. If > Ada sticks to this model (the "embedded only"), then it is > then doomed to never achieve wider acceptance, IMO. > > > It is hard word to do that. But IMHO it is much easier to > >> maintain than you can ever save during development by not doing the work. > > > Matrix 10 POSIX environments x 10 versions of the same, x 4 > different versions of a curses library. That leaves you with > 400 different custom (possibly groups of) packages to work > with. Real slick indeed. :( > >> So I don't believe in preprocessors for Ada code. > > > Think "conditional compilation". I see the "how" as an > implementation detail, that need _not_ track the C/C++ > experience. > >> There are times that I do get frustrated at the fact that I can put >> case statements in type declarations and sequences of statements, but >> I can't wrap a single declaration in one. But usually after a short >> break, I come back and it wasn't necessary after all. > > > I get frustrated with the short sightedness of the "not invented > here syndrome". But maybe, that is just me. ;-) > -- Robert I. Eachus "The war on terror is a different kind of war, waged capture by capture, cell by cell, and victory by victory. Our security is assured by our perseverance and by our sure belief in the success of liberty." -- George W. Bush ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-27 0:15 ` Standard Ada Preprocessor (Was: why ada is so unpopular ?) Robert I. Eachus @ 2004-01-27 22:05 ` Warren W. Gay VE3WWG 0 siblings, 0 replies; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-27 22:05 UTC (permalink / raw) Robert I. Eachus wrote: > Robert I. Eachus wrote: > >> My point was that we can fix System to some extent, since Strings can >> now be static. Of course there is NO universal solution because on >> some systems some values will be static, and on others they won't be >> known until run-time. But if we "fix" System so that the compiler can >> document such things, then users will be able to do what they can do. > > Warren W. Gay VE3WWG wrote: > >> I hate "no universal solution" fixes. I hate having to revist >> things multiple times. I hate preprocessors too, but I hate >> the other issues more. > > I think you misunderstood what I was saying here. On some systems > memory size is static. This is common in embedded systems, the RAM may > be part of the CPU chip. In that case users would want the compiler to > use a static value for memory size. But on a PC, if I stick another > DIMM in and reboot, I want my (previously compiled) program to see the > right memory size. So a compiler targeting a PC should use a system > call to get the memory size at run-time. That was what I meant by "no > universal solution." We (the ARG) should give Implementation Advice > about when the values in package System should be static and when they > should use a system call. But the choice should be left to the > implementor, because he knows the characteristics of the actual target. OK, understood now. -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-23 12:38 ` Marin David Condic 2004-01-24 5:23 ` Robert I. Eachus @ 2004-01-24 8:17 ` Pascal Obry 2004-01-24 12:44 ` Marin David Condic 1 sibling, 1 reply; 296+ messages in thread From: Pascal Obry @ 2004-01-24 8:17 UTC (permalink / raw) Marin David Condic <nobody@noplace.com> writes: > The more I think about it the more I want there to be a conditional > compilation capability that would allow some unlimited set of logical names I'm not sure I agree with that. Of course it will be a working solution but this is not a solution I'd like to see all over the place. Such feature will just encourage people to create messy code! I still prefer the one-spec and multiple bodies solution. At least the spec is target/hardware independent. This means that a good design needs to be done. Once this is done the selection of the right body depending on the target/hardware is a matter of configuration management. The argument saying that this solution make too much code duplication is wrong. It is perfectly possible to use child package/procedure/function for the one routine that is target/hardware dependant in whole API. Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://perso.wanadoo.fr/pascal.obry --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-24 8:17 ` Pascal Obry @ 2004-01-24 12:44 ` Marin David Condic 2004-01-24 15:39 ` Robert I. Eachus 2004-01-26 11:28 ` Ole-Hjalmar Kristensen 0 siblings, 2 replies; 296+ messages in thread From: Marin David Condic @ 2004-01-24 12:44 UTC (permalink / raw) O.K. Can you think of *some* way for the *language* to specify redirection to an alternate body? That might fix most problems - if not all. (What do I do if I want alternative declarations in a spec to account for compiler differences?) I suppose if we had some kind of "conditional with" we could construct a few more layers of indirection and provide alternate implementations that are picked up by the compiler. Some version of: with if (condition) Gnat_Solution ; with if (condition) Aonix_Solution ; and assuming that Gnat_Solution and Aonix_Solution have an identical interface (just different bodies) a similar "conditional use" in the right context would let you connect to the right thing. (They might not need identical interfaces - you might allow for differences in declarations so long as all the right identifiers were visible.) So then if you had a compiler specific package or some platform dependent thing, you'd hide it under some "skin" that provided a common interface. Withing and using the right "skin" would give you a portable way of handling the building of a system for two or more targets. (Assuming that the compiler didn't need to compile something conditionally withed just to be able to ignore the with.) MDC Pascal Obry wrote: > > I'm not sure I agree with that. Of course it will be a working solution but > this is not a solution I'd like to see all over the place. Such feature will > just encourage people to create messy code! > > I still prefer the one-spec and multiple bodies solution. At least the spec is > target/hardware independent. This means that a good design needs to be > done. Once this is done the selection of the right body depending on the > target/hardware is a matter of configuration management. > > The argument saying that this solution make too much code duplication is > wrong. It is perfectly possible to use child package/procedure/function for > the one routine that is target/hardware dependant in whole API. > > Pascal. > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-24 12:44 ` Marin David Condic @ 2004-01-24 15:39 ` Robert I. Eachus 2004-01-24 16:06 ` Marin David Condic 2004-01-26 11:28 ` Ole-Hjalmar Kristensen 1 sibling, 1 reply; 296+ messages in thread From: Robert I. Eachus @ 2004-01-24 15:39 UTC (permalink / raw) Marin David Condic wrote: > I suppose if we had some kind of "conditional with" we could construct a > few more layers of indirection and provide alternate implementations > that are picked up by the compiler. Some version of: > > with if (condition) Gnat_Solution ; > with if (condition) Aonix_Solution ; > > and assuming that Gnat_Solution and Aonix_Solution have an identical > interface (just different bodies) a similar "conditional use" in the > right context would let you connect to the right thing. But again you are trying hard to make things difficult for yourself. First, if the interface to Gnat_Solution and Aonix_Solution are identical, why do you want to make source that uses the interface compiler dependent? Both the Gnat and Aonix packages should be named Solution. ;-) Now that you have gone that far, you have banished all of the compiler dependencies to the body of Solution. Either use the tricks I described, or if the bodies are so different that it makes sense to mantain them separately, provide them as separate files, and use different makefiles for Aonix and Gnat. (Gnat likes to dictate the names of files, but it does provide facilities for overriding that.) -- Robert I. Eachus "The war on terror is a different kind of war, waged capture by capture, cell by cell, and victory by victory. Our security is assured by our perseverance and by our sure belief in the success of liberty." -- George W. Bush ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-24 15:39 ` Robert I. Eachus @ 2004-01-24 16:06 ` Marin David Condic 0 siblings, 0 replies; 296+ messages in thread From: Marin David Condic @ 2004-01-24 16:06 UTC (permalink / raw) Robert I. Eachus wrote: > > But again you are trying hard to make things difficult for yourself. > First, if the interface to Gnat_Solution and Aonix_Solution are > identical, why do you want to make source that uses the interface > compiler dependent? Both the Gnat and Aonix packages should be named > Solution. ;-) > They may not be "identical" in all respects - remember rep clauses! I can have declarations that *won't* compile on some compiler. However the type, object, subprogram, etc. *names* might be identical. And I'd like a way to make sure I never try to compile/link/run a Gnat package body with an Aonix compiler/linker. Maybe I can start with an identical spec and two different bodies (maybe!) and how is it I make sure the right body gets picked up by the right compiler? That's an environmental thing - so I have to figure that one out and come up with some scheme for handling that. (makefiles, CVS trees, whatever. It won't be portable.) All you can do is delay the problem with indirection - you can't make it go away. Sooner or later, you've got code that compiles for one environment and not for another. Now manage it. (Or maybe I could have a conditional compile preprocessor and have just *one* set of files to deal with? :-) > Now that you have gone that far, you have banished all of the compiler > dependencies to the body of Solution. Either use the tricks I > described, or if the bodies are so different that it makes sense to > mantain them separately, provide them as separate files, and use > different makefiles for Aonix and Gnat. (Gnat likes to dictate the > names of files, but it does provide facilities for overriding that.) > > Yup. I've been saying all along that I *know* I can solve the problem with some kind of build process and/or CM. Separate makefiles (if you have makefiles) or some other OS/third-party-product dependent answer is out there. We've been building different builds of the same thing for a long time now and a solution does exist. I have *never* said you couldn't find a way to do it with technology that exists today. A solution does exist. Just not a *Portable* solution and one you can count on being there all the time. And not always a *simple* solution to a sometimes *simple* problem. You're dependent on some kind of outside-the-language-can't-count-on-having-it-there patch to deal with the fact that compilers and OS's and libraries and targets and environments are *not* always identical. Also, its sometimes "Overkill" to suddenly have to buy into separate builds with separate sources and separate CM on them, etc. If you need just a small handful of things fixed at some low level, you may not want to force your project to forever be doing that extra maintenance effort and bookeeping that goes along with handling divergent copies of source code. I'm not saying I can't find a way to live without it. I'm just saying it would help simplify a lot of problems if we had something like conditional compilation or some other patch to deal with differences between environments. I'd like to have a way of *not* having divergent copies of source code - or if they must diverge, then give me a mechanism for auto-selecting them that I can count on having in any place I take the code. MDC -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-24 12:44 ` Marin David Condic 2004-01-24 15:39 ` Robert I. Eachus @ 2004-01-26 11:28 ` Ole-Hjalmar Kristensen 2004-01-26 12:07 ` Marin David Condic 1 sibling, 1 reply; 296+ messages in thread From: Ole-Hjalmar Kristensen @ 2004-01-26 11:28 UTC (permalink / raw) >>>>> "MDC" == Marin David Condic <nobody@noplace.com> writes: MDC> O.K. Can you think of *some* way for the *language* to specify MDC> redirection to an alternate body? That might fix most problems - if MDC> not all. (What do I do if I want alternative declarations in a spec to MDC> account for compiler differences?) What about allowing specialization of generic packages? Then you could have multiple bodies, the right one selected by the arguments to the generic instantiation. MDC> I suppose if we had some kind of "conditional with" we could construct MDC> a few more layers of indirection and provide alternate implementations MDC> that are picked up by the compiler. Some version of: MDC> with if (condition) Gnat_Solution ; MDC> with if (condition) Aonix_Solution ; MDC> and assuming that Gnat_Solution and Aonix_Solution have an identical MDC> interface (just different bodies) a similar "conditional use" in the MDC> right context would let you connect to the right thing. (They might MDC> not need identical interfaces - you might allow for differences in MDC> declarations so long as all the right identifiers were visible.) MDC> So then if you had a compiler specific package or some platform MDC> dependent thing, you'd hide it under some "skin" that provided a MDC> common interface. Withing and using the right "skin" would give you a MDC> portable way of handling the building of a system for two or more MDC> targets. (Assuming that the compiler didn't need to compile something MDC> conditionally withed just to be able to ignore the with.) MDC> MDC MDC> Pascal Obry wrote: >> I'm not sure I agree with that. Of course it will be a working >> solution but >> this is not a solution I'd like to see all over the place. Such feature will >> just encourage people to create messy code! >> I still prefer the one-spec and multiple bodies solution. At least >> the spec is >> target/hardware independent. This means that a good design needs to be >> done. Once this is done the selection of the right body depending on the >> target/hardware is a matter of configuration management. >> The argument saying that this solution make too much code >> duplication is >> wrong. It is perfectly possible to use child package/procedure/function for >> the one routine that is target/hardware dependant in whole API. >> Pascal. >> MDC> -- MDC> ====================================================================== MDC> Marin David Condic MDC> I work for: http://www.belcan.com/ MDC> My project is: http://www.jsf.mil/NSFrames.htm MDC> Send Replies To: m o d c @ a m o g MDC> c n i c . r MDC> "Face it ladies, its not the dress that makes you look fat. MDC> Its the FAT that makes you look fat." MDC> -- Al Bundy MDC> ====================================================================== -- C++: The power, elegance and simplicity of a hand grenade. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-26 11:28 ` Ole-Hjalmar Kristensen @ 2004-01-26 12:07 ` Marin David Condic 0 siblings, 0 replies; 296+ messages in thread From: Marin David Condic @ 2004-01-26 12:07 UTC (permalink / raw) I don't know what that would look like. Would you see it as somehow able to select a body to compile based on some kind of switch or condition settable by the compiler? It *feels* a little cumbersome, but I'd have to see an example of how it would work to say for sure. MDC Ole-Hjalmar Kristensen wrote: > > What about allowing specialization of generic packages? Then you could > have multiple bodies, the right one selected by the arguments to the > generic instantiation. > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-23 2:47 ` Robert I. Eachus 2004-01-23 12:38 ` Marin David Condic @ 2004-01-23 16:38 ` Alexandre E. Kopilovitch 2004-01-23 17:54 ` Jeffrey Carter 2004-01-23 17:24 ` Warren W. Gay VE3WWG 2 siblings, 1 reply; 296+ messages in thread From: Alexandre E. Kopilovitch @ 2004-01-23 16:38 UTC (permalink / raw) To: comp.lang.ada Robert I. Eachus wrote: > ... I think it would be wonderful > to get rid of the type Name in system and add three string constants: > > Operating_System: constant String := implementation_dependent; > Hardware_Architecture: constant String := implementation_dependent; > Compiler: constant String := implementation_dependent; > Version: constant String := implementation_dependent; I think that Compiler string constant (followed by its Version) should be placed first in this sequence to underline the understanding that it is the main key and that the meaning of all other items here (that is, Operating_System and Hardware_Architecture) is relative to the Compiler. Also, it may be useful to duplicate the pair {Operating_System, Hardware_Architecture} - to cover the case of cross-compilation, that is: Compiler: constant String := implementation_dependent; Version: constant String := implementation_dependent; Host_Operating_System: constant String := implementation_dependent; Host_Hardware_Architecture: constant String := implementation_dependent; Target_Operating_System: constant String := implementation_dependent; Target_Hardware_Architecture: constant String := implementation_dependent; Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-23 16:38 ` Alexandre E. Kopilovitch @ 2004-01-23 17:54 ` Jeffrey Carter 0 siblings, 0 replies; 296+ messages in thread From: Jeffrey Carter @ 2004-01-23 17:54 UTC (permalink / raw) Robert I. Eachus wrote: >... I think it would be wonderful >to get rid of the type Name in system and add three string constants: > >Operating_System: constant String := implementation_dependent; >Hardware_Architecture: constant String := implementation_dependent; >Compiler: constant String := implementation_dependent; >Version: constant String := implementation_dependent; FOUR string constants ... chief among our string constants ... I'll come in again. -- Jeff Carter "C++ is like jamming a helicopter inside a Miata and expecting some sort of improvement." Drew Olbrich 51 ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-23 2:47 ` Robert I. Eachus 2004-01-23 12:38 ` Marin David Condic 2004-01-23 16:38 ` Alexandre E. Kopilovitch @ 2004-01-23 17:24 ` Warren W. Gay VE3WWG 2004-01-23 22:30 ` Randy Brukardt 2 siblings, 1 reply; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-23 17:24 UTC (permalink / raw) Robert I. Eachus wrote: > Marin David Condic wrote: > >> How about *adding* something to system like: >> >> System.Compiler_ID : constant String := "Something Useful Here" ; >> >> This would not break anything that was already using System_Name >> (although given its general uselessness, I doubt that is very much) >> and would provide a mechanism for identifying the compiler that is >> doing the job. Then statements like "if (Compiler_ID = "Something") >> then..." would possibly be useful. > > In Ada 83 that wouldn't have worked. But I think it would be wonderful > to get rid of the type Name in system and add three string constants: > > Operating_System: constant String := implementation_dependent; > Hardware_Architecture: constant String := implementation_dependent; > Compiler: constant String := implementation_dependent; > Version: constant String := implementation_dependent; This is still a very limited solution to the problems where conditional compilation is needed. MDC pointed out a good example where conditional "with" is desirable (and of course this affects coresponding code). These items only deal with system and compiler level issues. How do you solve the issues involved with different curses libraries? - UNIX/*BSD curses library? - GNU/Linux curses library? - PDcurses? If you're writing a curses binding, you not only need to know which of these you're binding to, you need some serious interface changes within your Ada code to be successful (changes to API calls, conventions etc.) Some of the pragmas you will use, will also be conditional upon what platform and "library" you're interfacing with. Even where interfaces are identical, you often have to work around bugs or implementation limitations. The current "Ada compile process" does not solve this issue. So I would suggest that the lack of "conditional compilation" capability in Ada holds it back from general use. If you don't want preprocessing, then fine. Engineer a "conditional compile" capability, and leave the "how" as an implementation detail. -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-23 17:24 ` Warren W. Gay VE3WWG @ 2004-01-23 22:30 ` Randy Brukardt 2004-01-26 22:11 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 296+ messages in thread From: Randy Brukardt @ 2004-01-23 22:30 UTC (permalink / raw) "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message news:PMcQb.20017$cQ6.818801@news20.bellglobal.com... > How do you solve the issues involved with different curses > libraries? > > - UNIX/*BSD curses library? > - GNU/Linux curses library? > - PDcurses? You use a thick curses binding, of course. And if the bodies need to be different, then there are different bodies. So what? There are a number of parts of Claw that have different bodies (and in a few cases, specs of private packages) for different compilers. It would be nice if there was an automated way to keep the common parts of those in sync, but that's a tools issue, not a language issue. Similarly, the bodies for Claw-less sockets will be completely different between the Windows version and the GNAT sockets version (and I think, the Linux version, if we ever do that). (This is closer to your situation.) There isn't much point in trying to share the code; far too little can be shared. Conditional compilation only makes sense when you can share large parts of the code -- but in those cases, careful use of subunits can again put the differences all into a single body that might as well be handled separately. Randy. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-23 22:30 ` Randy Brukardt @ 2004-01-26 22:11 ` Warren W. Gay VE3WWG 2004-01-27 0:28 ` Robert I. Eachus 2004-01-27 1:02 ` Jeffrey Carter 0 siblings, 2 replies; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-26 22:11 UTC (permalink / raw) Randy Brukardt wrote: > "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message > news:PMcQb.20017$cQ6.818801@news20.bellglobal.com... > >>How do you solve the issues involved with different curses >>libraries? >> >> - UNIX/*BSD curses library? >> - GNU/Linux curses library? >> - PDcurses? > > You use a thick curses binding, of course. Of course, and just what do you think the binding has to worry about? ;-) > And if the bodies need to be > different, then there are different bodies. So what? The "so what" is that 90% of the code will be in common. So why would I duplicate 90% to manage the 10% in 3+ cases? Centralized maintenance is what I am after. As soon as you decentralize it, someone is going to forget, bungle or neglect to update the fix in one of the other n bodies. This does not a good solution make. > There are a number of parts of Claw that have different bodies (and in a few > cases, specs of private packages) for different compilers. It would be nice > if there was an automated way to keep the common parts of those in sync, but > that's a tools issue, not a language issue. That is just narrow thinking. Only you are saying it "must be tools". I am suggesting that perhaps another more natural solution is possible. > Similarly, the bodies for Claw-less sockets will be completely different > between the Windows version and the GNAT sockets version (and I think, the > Linux version, if we ever do that). (This is closer to your situation.) > There isn't much point in trying to share the code; far too little can be > shared. Conditional compilation only makes sense when you can share large > parts of the code -- but in those cases, careful use of subunits can again > put the differences all into a single body that might as well be handled > separately. > > Randy. I am not suggesting for a minute that the whole world needs to release software in the same manner. It doesn't seem to bother you to maintain multiple instances of similar code. I personally hate it and would much rather have it centralized. We can disagree on the preference. Can we agree on having a choice at least? -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-26 22:11 ` Warren W. Gay VE3WWG @ 2004-01-27 0:28 ` Robert I. Eachus 2004-01-27 22:13 ` Warren W. Gay VE3WWG 2004-01-27 1:02 ` Jeffrey Carter 1 sibling, 1 reply; 296+ messages in thread From: Robert I. Eachus @ 2004-01-27 0:28 UTC (permalink / raw) Warren W. Gay VE3WWG wrote: > I am not suggesting for a minute that the whole world needs to > release software in the same manner. It doesn't seem to bother > you to maintain multiple instances of similar code. I personally > hate it and would much rather have it centralized. We can disagree > on the preference. As long as you understand that the people arguing on both sides here actually know what they are talking about. Right now I don't do much embedded work. Randy's work with CLAW is probably among the goriest cases of a thick binding dealing with multiple environments around. > Can we agree on having a choice at least? Sure, you have that choice. There are several good pre-processors for Ada. Go, get one, use it. Pretty soon you will join Randy and I on the other side of the fence. Don't get me wrong, the GNAT pre-processor facilities are great, much better than cpp. But when you really try to use it you end up in self protection migrating as much pre-processor stuff as possible into one unit. Then once you start planning out the code you want for some change to that unit, then figuring out where to stick it in the middle of all the preprocessor directives, you will agree that multiple bodies are easier to maintain. ;-) (Incidently, there is an intermediate position you go through, and which works nicely for some units. The bodies of subprograms in the unit each turns into a case statement on the processor or compiler. But when I reach that point, I use Ada instead of the pre-processor for the case statements.) -- Robert I. Eachus "The war on terror is a different kind of war, waged capture by capture, cell by cell, and victory by victory. Our security is assured by our perseverance and by our sure belief in the success of liberty." -- George W. Bush ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-27 0:28 ` Robert I. Eachus @ 2004-01-27 22:13 ` Warren W. Gay VE3WWG 0 siblings, 0 replies; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-27 22:13 UTC (permalink / raw) Robert I. Eachus wrote: > Warren W. Gay VE3WWG wrote: ... >> Can we agree on having a choice at least? > > Sure, you have that choice. There are several good pre-processors for > Ada. Go, get one, use it. I've been using one for quite some time. But remember, the request was for a *standard* one. ;-) > Pretty soon you will join Randy and I on the > other side of the fence. Until systems start all looking the same (not likely), and userland APIs (shared libraries) all start being consistent (there will always be different versions), I'll always have to be adapting Ada code to these messy differences. Until the day comes when I don't need to write bindings to C and C++ code, I'll always be using gnatprep, as I have from the beginning. Until I get Ada bindings for all the C stuff out there, I will always be in need for "conditional compilation". Read my lips ;-) > Don't get me wrong, the GNAT pre-processor > facilities are great, much better than cpp. But when you really try to > use it you end up in self protection migrating as much pre-processor > stuff as possible into one unit. Then once you start planning out the > code you want for some change to that unit, then figuring out where to > stick it in the middle of all the preprocessor directives, you will > agree that multiple bodies are easier to maintain. ;-) > > (Incidently, there is an intermediate position you go through, and which > works nicely for some units. The bodies of subprograms in the unit > each turns into a case statement on the processor or compiler. But when > I reach that point, I use Ada instead of the pre-processor for the case > statements.) I am _not_ saying that gnatprep _is_ the solution. But some carefully designed conditional compilation needs to be considered. It should be available and optional. That is all. -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-26 22:11 ` Warren W. Gay VE3WWG 2004-01-27 0:28 ` Robert I. Eachus @ 2004-01-27 1:02 ` Jeffrey Carter 1 sibling, 0 replies; 296+ messages in thread From: Jeffrey Carter @ 2004-01-27 1:02 UTC (permalink / raw) Warren W. Gay VE3WWG wrote: >> And if the bodies need to be >> different, then there are different bodies. So what? > > The "so what" is that 90% of the code will be in common. > So why would I duplicate 90% to manage the 10% in 3+ > cases? There's no code in common if you do it right. -- Jeff Carter "Beyond 100,000 lines of code you should probably be coding in Ada." P. J. Plauger 26 ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-22 5:59 ` Randy Brukardt 2004-01-22 12:58 ` Marin David Condic @ 2004-01-22 14:13 ` Robert A Duff 2004-01-22 17:27 ` Warren W. Gay VE3WWG 2004-01-23 12:52 ` Marin David Condic 1 sibling, 2 replies; 296+ messages in thread From: Robert A Duff @ 2004-01-22 14:13 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> writes: > "Robert I. Eachus" <rieachus@comcast.net> wrote in message > news:LNOdncWFbKUojpLdRVn-uQ@comcast.com... > > E:\Ada\Test>system_names > > system_names > > The Available System Names are: SYSTEM_NAME_GNAT. > > > > Current System.System_Name is: SYSTEM_NAME_GNAT. > > > > Is there any compiler that produces a useful output? > > Dunno. We used to have additional names in that enumeration, but I believe > we removed the capability because of the ACVC. In Ada 83, you were supposed > to be able to set the value of the System_Name (via a pragma, I believe) to > any of the allowed choices. The best way to "avoid" that test was to have > only one name in the enumeration. Then, the test couldn't do anything > useful. There was also a pragma to change the size of a storage unit. Very strange. Compilers are not generally capable of redesigning the target hardware in the fly! Anyway, it seems to me that the whole idea of System.System_Name could never work, unless there were some world-wide registry of names. Much easier to let individual projects roll their own -- they know what systems they (currently) support, and they know whether they care about the target hardware, or the target OS, or the Ada compiler, or whatever. - Bob ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-22 14:13 ` Robert A Duff @ 2004-01-22 17:27 ` Warren W. Gay VE3WWG 2004-01-23 12:54 ` Marin David Condic 2004-01-23 12:52 ` Marin David Condic 1 sibling, 1 reply; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-22 17:27 UTC (permalink / raw) Robert A Duff wrote: > "Randy Brukardt" <randy@rrsoftware.com> writes: >>"Robert I. Eachus" <rieachus@comcast.net> wrote in message >>news:LNOdncWFbKUojpLdRVn-uQ@comcast.com... >> >>>E:\Ada\Test>system_names >>>system_names >>> The Available System Names are: SYSTEM_NAME_GNAT. >>> >>> Current System.System_Name is: SYSTEM_NAME_GNAT. >>> >>>Is there any compiler that produces a useful output? >> >>Dunno. We used to have additional names in that enumeration, but I believe >>we removed the capability because of the ACVC. In Ada 83, you were supposed >>to be able to set the value of the System_Name (via a pragma, I believe) to >>any of the allowed choices. The best way to "avoid" that test was to have >>only one name in the enumeration. Then, the test couldn't do anything >>useful. > > There was also a pragma to change the size of a storage unit. > Very strange. Compilers are not generally capable of redesigning > the target hardware in the fly! ... Non-standard pragmas (implementation defined) are another reason why conditional compilation (or preprocessing) is required. Sometimes it is necessary to use the non-standard pragmas, especially when doing bindings. -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-22 17:27 ` Warren W. Gay VE3WWG @ 2004-01-23 12:54 ` Marin David Condic 2004-01-23 17:26 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 296+ messages in thread From: Marin David Condic @ 2004-01-23 12:54 UTC (permalink / raw) But the language already says that if an implementation doesn't recognize a pragma, that it should be ignored. So you already have some limited conditional compilation. Its not a big stretch to imagine from there some pragma that lets you include or exclude statements depending on some compile-time condition. MDC Warren W. Gay VE3WWG wrote: > > Non-standard pragmas (implementation defined) are another reason > why conditional compilation (or preprocessing) is required. > Sometimes it is necessary to use the non-standard pragmas, > especially when doing bindings. -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-23 12:54 ` Marin David Condic @ 2004-01-23 17:26 ` Warren W. Gay VE3WWG 0 siblings, 0 replies; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-23 17:26 UTC (permalink / raw) Marin David Condic wrote: > But the language already says that if an implementation doesn't > recognize a pragma, that it should be ignored. So you already have some > limited conditional compilation. Its not a big stretch to imagine from > there some pragma that lets you include or exclude statements depending > on some compile-time condition. > > MDC > > Warren W. Gay VE3WWG wrote: > >> Non-standard pragmas (implementation defined) are another reason >> why conditional compilation (or preprocessing) is required. >> Sometimes it is necessary to use the non-standard pragmas, >> especially when doing bindings. That is fine, when the compiler doesn't recognize the pragma. But what happens if two compilers both recognize an implementation pragma, but have different requirements? Different parameters for example? Or how about different consequences? Maybe it only applies in one case, but not the other? -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-22 14:13 ` Robert A Duff 2004-01-22 17:27 ` Warren W. Gay VE3WWG @ 2004-01-23 12:52 ` Marin David Condic 2004-01-24 5:52 ` Robert I. Eachus 1 sibling, 1 reply; 296+ messages in thread From: Marin David Condic @ 2004-01-23 12:52 UTC (permalink / raw) O.K. But we always had that capability. Right now I could write a package and call it "Configuration" (or whatever) and house in it a bunch of different strings that tell me what is or is not available in a particular compiler/target/version/etc arrangement. But unless you can actually *do* something with that info, having it available is totally useless. By the time I'm running and can read it and branch around some piece of code - its too late. I need it to solve issues at compile time - where a given compiler can't even see a given statement or it will choke. Perhaps a pragma that took some constant string and compared it to a string literal and compiled the associated code only if equal would be sufficient. I could build my "package Configuration" and have something like pragma If_Equal (Configuration.OS => "TOPS 10", <some collection of Ada code - declarative or executable>) ; It would be a cheap fix that minimizes the impact to any existing packages or code and only requires compile-time interpretation of a pragma - something compilers already do. MDC Robert A Duff wrote: > > Anyway, it seems to me that the whole idea of System.System_Name could > never work, unless there were some world-wide registry of names. > Much easier to let individual projects roll their own -- they know > what systems they (currently) support, and they know whether they care > about the target hardware, or the target OS, or the Ada compiler, > or whatever. > > - Bob -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-23 12:52 ` Marin David Condic @ 2004-01-24 5:52 ` Robert I. Eachus 2004-01-24 12:56 ` Marin David Condic 0 siblings, 1 reply; 296+ messages in thread From: Robert I. Eachus @ 2004-01-24 5:52 UTC (permalink / raw) Marin David Condic wrote: > Perhaps a pragma that took some constant string and compared it to a > string literal and compiled the associated code only if equal would be > sufficient. I could build my "package Configuration" and have something > like > > pragma If_Equal (Configuration.OS => "TOPS 10", > <some collection of Ada code - declarative or executable>) ; > > It would be a cheap fix that minimizes the impact to any existing > packages or code and only requires compile-time interpretation of a > pragma - something compilers already do. Today you can write code that says: if Configuration.OS = "TOPS 10" then <some collection of executable Ada code> else <some other collection of excutable Ada code> end if; And your compiler should eliminate the code not executed if Configuration.OS is a static string constant. That is available now. What about declarations? Then you have two choices. The first is variant parts: type Foo(Choice: Boolean) is record case Choice is when True => Tops_10_Component: Float; when False => ... end case; end record; Or you can do: if Configuration.OS = "TOPS 10" then declare Tops_10_Only: Integer := ...; begin <some collection of executable Ada code> end; else declare Some_Other_Declaration: Some_Record_Type; begin <some other collection of excutable Ada code> end; end if; Also you can make a static Boolean constant: Tops_10: constant Boolean := Configuration.OS = TOPS 10"; If you want or need to, I usually do. Oh, one other neat trick. Look at Foo above. When creating all those objects of type Foo, you don't want to have to remember to specify the correct constraint. So just say: subtype Foob is Foo(Tops_10); If you forget and declare an object of type Foo, the compiler will tell you. (Unless of course you give it an initial value, but then you don't really have a bug anyway, since the value has the right discriminant.) If you are generating decent floating point code for x86 processors right now you can end up with a LARGE enumeration type and case statements. (Actually, combining the cases so the right one is available on each system is a non-trivial exercise. And once I get it working, I often leave the intended static constants as variables and set them at install-time or run-time. I need that to make testing survivable, so why not let people use it that way. ;-) So right now, these features are a usable part of the language. Not heavily used, but they can be. Which is why I think that "fixing" System and explaining why would be a big help. -- Robert I. Eachus "The war on terror is a different kind of war, waged capture by capture, cell by cell, and victory by victory. Our security is assured by our perseverance and by our sure belief in the success of liberty." -- George W. Bush ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-24 5:52 ` Robert I. Eachus @ 2004-01-24 12:56 ` Marin David Condic 2004-01-24 15:53 ` Robert I. Eachus 2004-01-30 17:34 ` Standard Ada Preprocessor (Was: why ada is so unpopular ?) Warren W. Gay VE3WWG 0 siblings, 2 replies; 296+ messages in thread From: Marin David Condic @ 2004-01-24 12:56 UTC (permalink / raw) That works for some things, but it still will barf when a statement is compileable for one target but not for another. I'm thinking of a case where (for example) you can get one size of float for one target, but for another target that size is not allowed. Hiding it in a discriminated record isn't going to help if the compiler pukes all over the alternative you're not going to use. Perhaps the compiler should be smarter - but if I keep waiting for compilers to be smarter, I won't get my job done & I'll be forced to resort to C. ;-) If you don't like the floating point example ("You ought to be using digits & attributes, you fool!" :-) then think "representation clause" and start imagining all the target/compiler variations on that. Its an interesting proposition and might provide some usefulness. Certainly there are characteristics that can be toggled at runtime and this might be of some help. (Like I said, the runtime stuff I already could have handled with my own package.) Its just that usually the point where I get hung out to dry is when I can't get something past the compiler because it is compiler-dependent or there's something platform/target dependent that makes the compiler choke. MDC Robert I. Eachus wrote: > > Today you can write code that says: > > if Configuration.OS = "TOPS 10" > then > <some collection of executable Ada code> > else > <some other collection of excutable Ada code> > end if; > > And your compiler should eliminate the code not executed if > Configuration.OS is a static string constant. That is available now. > > What about declarations? Then you have two choices. The first is > variant parts: > > type Foo(Choice: Boolean) is record > case Choice is > when True => > Tops_10_Component: Float; > when False => > ... > end case; > end record; > > Or you can do: > > if Configuration.OS = "TOPS 10" > then > declare > Tops_10_Only: Integer := ...; > begin > <some collection of executable Ada code> > end; > else > declare > Some_Other_Declaration: Some_Record_Type; > begin > <some other collection of excutable Ada code> > end; > end if; > > Also you can make a static Boolean constant: > > Tops_10: constant Boolean := Configuration.OS = TOPS 10"; > > If you want or need to, I usually do. Oh, one other neat trick. Look > at Foo above. When creating all those objects of type Foo, you don't > want to have to remember to specify the correct constraint. So just say: > > subtype Foob is Foo(Tops_10); > > If you forget and declare an object of type Foo, the compiler will tell > you. (Unless of course you give it an initial value, but then you don't > really have a bug anyway, since the value has the right discriminant.) > > If you are generating decent floating point code for x86 processors > right now you can end up with a LARGE enumeration type and case > statements. (Actually, combining the cases so the right one is available > on each system is a non-trivial exercise. And once I get it working, I > often leave the intended static constants as variables and set them at > install-time or run-time. I need that to make testing survivable, so > why not let people use it that way. ;-) > > So right now, these features are a usable part of the language. Not > heavily used, but they can be. Which is why I think that "fixing" > System and explaining why would be a big help. > > > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-24 12:56 ` Marin David Condic @ 2004-01-24 15:53 ` Robert I. Eachus 2004-01-30 17:39 ` Warren W. Gay VE3WWG 2004-01-30 17:34 ` Standard Ada Preprocessor (Was: why ada is so unpopular ?) Warren W. Gay VE3WWG 1 sibling, 1 reply; 296+ messages in thread From: Robert I. Eachus @ 2004-01-24 15:53 UTC (permalink / raw) Marin David Condic wrote: > That works for some things, but it still will barf when a statement is > compileable for one target but not for another. I'm thinking of a case > where (for example) you can get one size of float for one target, but > for another target that size is not allowed... I'm sorry, but to me this is heresy. Not that you might want to specify a value for digits, I do that all the time. But when it matters enough to specify it, it is IMPORTANT. If a particular compiler doesn't support that specification, there is no point in trying to hide the problem. The application code I wrote won't run in that environment. End of story. Well, not exactly end of story. There are cases where I write code that uses IEEE extended precision if available, and when it is not uses IEEE double with different algorithms and other methods of maintaining the required precision, such as scaled (64-bit) integers. That code is so different there is no point in trying to deal with it using ifdefs or whatever. Two different matrix library bodies for the same specification is the best I can do. -- Robert I. Eachus "The war on terror is a different kind of war, waged capture by capture, cell by cell, and victory by victory. Our security is assured by our perseverance and by our sure belief in the success of liberty." -- George W. Bush ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-24 15:53 ` Robert I. Eachus @ 2004-01-30 17:39 ` Warren W. Gay VE3WWG 2004-01-31 1:58 ` Robert I. Eachus 0 siblings, 1 reply; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-30 17:39 UTC (permalink / raw) Robert I. Eachus wrote: > Marin David Condic wrote: > >> That works for some things, but it still will barf when a statement is >> compileable for one target but not for another. I'm thinking of a case >> where (for example) you can get one size of float for one target, but >> for another target that size is not allowed... > > I'm sorry, but to me this is heresy. Not that you might want to specify > a value for digits, I do that all the time. > > But when it matters enough to specify it, it is IMPORTANT. If a > particular compiler doesn't support that specification, there is no > point in trying to hide the problem. The application code I wrote won't > run in that environment. End of story. > > Well, not exactly end of story. There are cases where I write code that > uses IEEE extended precision if available, and when it is not uses IEEE > double with different algorithms and other methods of maintaining the > required precision, such as scaled (64-bit) integers. That code is so > different there is no point in trying to deal with it using ifdefs or > whatever. Two different matrix library bodies for the same > specification is the best I can do. Ah, but when you are writing code that must interface with 3rd party software, where at one version it uses a 16-bit value, and on other versions 32-bits etc., then you must make your Ada code match _it_. You look at the world as if everything conforms to your view within Ada. I'll agree, that this is the best way to have it. But when writing code that must compile against what the user has installed, whether it be a kernel release, or a shared library or version of a DLL, you must match what _they_have_ -- not what you'd like it to be. This is one area where trouble sets in. And what is even worse, you can configure your interface with the pragma Import(), and it will compile and link successfully. However, at _run_ time, you'll get undefined behavior if things don't agree. This is the impedance mismatch that you get between Ada and C (for example), and obviously something you try to minimize. -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-30 17:39 ` Warren W. Gay VE3WWG @ 2004-01-31 1:58 ` Robert I. Eachus 2004-02-02 17:55 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 296+ messages in thread From: Robert I. Eachus @ 2004-01-31 1:58 UTC (permalink / raw) Warren W. Gay VE3WWG wrote: > Ah, but when you are writing code that must interface with > 3rd party software, where at one version it uses a 16-bit > value, and on other versions 32-bits etc., then you must > make your Ada code match _it_. Hmmm. I won't say that this is not a potentially killer problem. Just that the issue has nothing to do with configuration clauses. First let me deal with the different size issue. I have code that interfaces to the two different versions of the subprogram, and code that checks a (local static variable) defining which interface is used. My code is written with an if or case statement and multiple calls: procedure Thick_Binding (I: in out Integer) is begin if OS.Name = Solaris then declare Local: Int_16; begin Local := Int_16(I); C_Routine(Local); exception when Constraint_Error => ... end; elsif OS.Name = Windows then Different_C_Routine(I); end if; end Thick_Binding; The code is all legal Ada except that I have left out the thin C binding part) and the fact that there may be all sorts of trouble if C_Routine is called with a 16-bit value on Windows (or maybe not). As I said, the thin bindings part may compile on the "wrong" system or may not. But I deal with that problem in the thin bindings themselves. Why all the dire words up above? We used to call it "version skew." If your project depends on components and tools from more than three vendors or from the same vendor with different update schedules, you can have the problem that there may never be a consistant set of all three that works together. That is a problem outside the ability of anyone here to fix. All you can do is to choose the components that your project DEPENDs on, and keep that list small. In fact, you can partition the code into two separately compiled and mantained subsystems to mitigate the version skew effects. One thing that almost jumps out at you from this is something that is almost normal practice in the industry. If you have a system that depends on web protocols AND a database, you need to partition the two as well as you can. You may or may not have separate front ends for IE and Netscape/Mozilla, you may use ASPs or generate HTML, etc. But if you want to avoid headaches, the portion of the application that is database dependent (schemas, data integrity, etc.) is separate from the webserving front end. > And what is even worse, you can configure your interface > with the pragma Import(), and it will compile and link > successfully. However, at _run_ time, you'll get undefined > behavior if things don't agree. This is the impedance > mismatch that you get between Ada and C (for example), > and obviously something you try to minimize. Exactly, I use Ada to choose the right version of the interface for the actual system. But more important, as I said above, I try to partition the system as much as possible so that different subsystems/partitions/whatever can be updated separately, with only Ada interfaces maintained as part of the project in common. -- Robert I. Eachus "The war on terror is a different kind of war, waged capture by capture, cell by cell, and victory by victory. Our security is assured by our perseverance and by our sure belief in the success of liberty." -- George W. Bush ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-31 1:58 ` Robert I. Eachus @ 2004-02-02 17:55 ` Warren W. Gay VE3WWG 2004-02-04 18:36 ` Robert I. Eachus 0 siblings, 1 reply; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-02-02 17:55 UTC (permalink / raw) Robert I. Eachus wrote: > Warren W. Gay VE3WWG wrote: > >> Ah, but when you are writing code that must interface with >> 3rd party software, where at one version it uses a 16-bit >> value, and on other versions 32-bits etc., then you must >> make your Ada code match _it_. > > Hmmm. I won't say that this is not a potentially killer problem. Just > that the issue has nothing to do with configuration clauses. That statement is rather strong. This kind of thing is handled in the C/C++ world all the time as a configuration item. Now we could argue whether it should or not, but I don't want to beat on that dead horse here. > First let me deal with the different size issue. I have code that > interfaces to the two different versions of the subprogram, and code > that checks a (local static variable) defining which interface is used. > My code is written with an if or case statement and multiple calls: > > procedure Thick_Binding (I: in out Integer) is > begin > if OS.Name = Solaris then > declare > Local: Int_16; > begin > Local := Int_16(I); > C_Routine(Local); > exception > when Constraint_Error => ... > end; > elsif OS.Name = Windows then > Different_C_Routine(I); > end if; > end Thick_Binding; > > The code is all legal Ada except that I have left out the thin C binding > part) and the fact that there may be all sorts of trouble if C_Routine > is called with a 16-bit value on Windows (or maybe not). This does work I suppose, if you add the different pragma Imports to do the mappings between C_Routine and Different_C_Routine to the same C function xyz(). But this type of a solution can explode if the variations to the different versions of OS kernels is added. Linux for example has gone through many revisions, and so IMO, it is much simpler to define pid_t as a particular type, once and for all, once you know what it should be. If you had to code for these variances everywhere a pid_t was involved, it would be much more ugly than the conditional compiled solution. But, that is _opinion_, and I expect that we'll disagree about that. ... > Why all the dire words up above? We used to call it "version skew." If > your project depends on components and tools from more than three > vendors or from the same vendor with different update schedules, you can > have the problem that there may never be a consistant set of all three > that works together. That is a problem outside the ability of anyone > here to fix. All you can do is to choose the components that your > project DEPENDs on, and keep that list small. But this was my original point: if this is done successfully in C/C++ every day, then why can we not provide the same capability (albiet in a better way) to compete at this same level? Because of the conditional compilation bias, people want to explain away the need for it. Right now, it is _difficult_ to write Open Sourced projects that compete with C/C++ ones. You might not care about that, but it is close to my heart. So while I am running short of energy for further discussion of this apparently futile idea, it was my hope to spark some good ideas for some solution(s). > In fact, you can partition the code into two separately compiled Partitioning works good for smaller "works". Once the number of variables rise, this becomes impractical. Remember, you are trying to write something that will compile on the most "user hosted platforms" as possible. You cannot dictate the version of their kernel, the version of the other software non-Ada libraries they are using. You might dictate that your project is only supportable with certain version restrictions, but you want to reduce the number of those limitations to the minimum practicable. You will _never_ be able to compile all variations yourself either, nor will you be able to test them yourself. Some source code "alternatives" are safer in the "untested" realm. You cannot every hope to code for all of the possibilities. As ugly as it is, C/C++ has managed to deal with this problem sucessfully. And I am not suggesting for a minute that we copy their approach, but they are doing _something_ right. Anyway, I have said my piece on this subject. I have no energy to flog this dead horse even more. I already know what I have to do ;-) -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-02-02 17:55 ` Warren W. Gay VE3WWG @ 2004-02-04 18:36 ` Robert I. Eachus 2004-02-06 17:27 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 296+ messages in thread From: Robert I. Eachus @ 2004-02-04 18:36 UTC (permalink / raw) Warren W. Gay VE3WWG wrote: > Robert I. Eachus wrote: >> Hmmm. I won't say that this is not a potentially killer problem. >> Just that the issue has nothing to do with configuration clauses. > > > That statement is rather strong. This kind of thing is > handled in the C/C++ world all the time as a configuration > item. Now we could argue whether it should or not, but > I don't want to beat on that dead horse here. > >> First let me deal with the different size issue... > This does work I suppose, if you add the different pragma Imports > to do the mappings between C_Routine and Different_C_Routine to > the same C function xyz(). Yep, I left that part out as obvious. I still think we are violently agreeing. I have no objection to using a preprocessor with Ada when needed, and I expect that good compilers will provide one. > But this type of a solution can explode > if the variations to the different versions of OS kernels is > added. Linux for example has gone through many revisions, and > so IMO, it is much simpler to define pid_t as a particular type, > once and for all, once you know what it should be. If you > had to code for these variances everywhere a pid_t was > involved, it would be much more ugly than the > conditional compiled solution. > > But, that is _opinion_, and I expect that we'll disagree > about that. No, if it makes sense to export pid_t as an abstract data type, then do it, and the Linux version dependencies are all in that package. If you only use pid_t in one or two places, then that is a waste of effort. Each time we work on a project, both you and I will make hundreds of such decisions. I don't think it is right to force anyone to do something in only one "Ada approved" way. >> Why all the dire words up above? We used to call it "version skew." >> If your project depends on components and tools from more than three >> vendors or from the same vendor with different update schedules, you >> can have the problem that there may never be a consistant set of all >> three that works together. That is a problem outside the ability of >> anyone here to fix. All you can do is to choose the components that >> your project DEPENDs on, and keep that list small. > > But this was my original point: if this is done successfully in C/C++ > every day, then why can we not provide the same capability > (albiet in a better way) to compete at this same level? > Because of the conditional compilation bias, people want > to explain away the need for it. I have seen many projects killed by version skew. I could go so far as to say it is the number one killer of all projects, and all open source projects. As you depend on more external applications/systems the number of potential version skew problems goes up as N(N-1)/2. If your code only depends on say, GNAT, no version skew. (Or from another project's point of view, one opportunity for version skew, since your project may not work with all versions of GNAT. But when you have a system that depends on the OS, the compiler, a graphics package, a database, and a browser, N is five. The number of potential mismatches is 10. That can be dealt with in an embedded development project--choose a set of versions that work together and never change any of them. But for an open source project you can't do that. And that is why bringing other standards into the language and compiler is a win. Every standard that becomes explicitly part of the language or implicitly through support by most compilers means that the compiler developers deal with the version skew, and you don't have to. > Anyway, I have said my piece on this subject. I have > no energy to flog this dead horse even more. I already > know what I have to do ;-) Same here. I can't slay the version skew monster, but I can try to minimize the number of cases it comes up. Where we differ is on which is the best way to do that. I want to bring as many "standard" interfaces inside the Ada boundary as possible, you want to standardize the preprocessor. As I have said before, I have no objection to that, as long as you don't expect the ARG to do it. Expecting WG9 to do it is another issue, and I don't have a strong opinion on that, other than a PRG or whatever should be created instead of assigning the problem to the ARG. Remember that in several cases issues have been treated exactly this way, only to eventually end up in the Ada standard. For example, there was an awful lot of work done by the NUMWG and the NRG on math packages for Ada. I participated a small bit mostly as a liason with the ARG to explain why some particular proposals caused other issues in the language. Other such groups include the CRG (character sets) and the work done on information systems that eventually ended up as Annex F and decimal types. -- Robert I. Eachus "The war on terror is a different kind of war, waged capture by capture, cell by cell, and victory by victory. Our security is assured by our perseverance and by our sure belief in the success of liberty." -- George W. Bush ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-02-04 18:36 ` Robert I. Eachus @ 2004-02-06 17:27 ` Warren W. Gay VE3WWG 2004-02-07 13:18 ` Marin David Condic 2004-02-10 14:59 ` Standard Ada Preprocessor Jacob Sparre Andersen 0 siblings, 2 replies; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-02-06 17:27 UTC (permalink / raw) Robert I. Eachus wrote: > Warren W. Gay VE3WWG wrote: >> Robert I. Eachus wrote: ... > I have seen many projects killed by version skew. I could go so far as > to say it is the number one killer of all projects, and all open source > projects. As you depend on more external applications/systems the > number of potential version skew problems goes up as N(N-1)/2. If your > code only depends on say, GNAT, no version skew. (Or from another > project's point of view, one opportunity for version skew, since your > project may not work with all versions of GNAT. I won't disagree with this.. > But when you have a system that depends on the OS, the compiler, a > graphics package, a database, and a browser, N is five. The number of > potential mismatches is 10. That can be dealt with in an embedded > development project--choose a set of versions that work together and > never change any of them. But for an open source project you can't do > that. Which is precisely the challenge. If you want to write some package X (some killer app), then obviously end users will all want it to run with what they have installed. In fact, this may in part be mandated by _other_ package requirements, where version conflicts may force a choice of one. So the challenge is to use the best technology (Ada) and yet be capable of accomodating a large range of "environments". > And that is why bringing other standards into the language and compiler > is a win. Every standard that becomes explicitly part of the language > or implicitly through support by most compilers means that the compiler > developers deal with the version skew, and you don't have to. Yes: I fully support the notion of standards. They simplify life in so many ways. But if I look at all the shared libraries that are available for use under Linux, and the number of Ada "bindings", what is immediately available to me is rather restricted. If I need that functionality, the onus is now on me to solve that problem (rewrite, bind or otherwise adapt). I think because of the targeted end user, Open Sourced projects have a special "need", compared to perhaps the "typical" Ada project (whatever that is ;-) So forgive me if my needs are slanted a bit differently ;-) >> Anyway, I have said my piece on this subject. I have >> no energy to flog this dead horse even more. I already >> know what I have to do ;-) > > Same here. I can't slay the version skew monster, but I can try to > minimize the number of cases it comes up. Where we differ is on which > is the best way to do that. I want to bring as many "standard" > interfaces inside the Ada boundary as possible, you want to standardize > the preprocessor. As I have said before, I have no objection to that, > as long as you don't expect the ARG to do it. I never suggested that someone should just plop it into the ARG's lap without doing homework/whatever. All I can do is speak for myself here, and say that I just wanted to have an open discussion on the merits of some sort of conditional compilation. The result of this discussion seems to suggest that most are resisting the idea, for different reasons. So be it. Maybe with time, resistance to the idea will fade as more people try to address the practical problems that Open Sourced projects face in Ada. One can hope ;-) -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-02-06 17:27 ` Warren W. Gay VE3WWG @ 2004-02-07 13:18 ` Marin David Condic 2004-02-09 17:37 ` Warren W. Gay VE3WWG 2004-02-10 14:59 ` Standard Ada Preprocessor Jacob Sparre Andersen 1 sibling, 1 reply; 296+ messages in thread From: Marin David Condic @ 2004-02-07 13:18 UTC (permalink / raw) Unfortunately, the resistance typically "fades" in the form of "Its just too hard for me to get my job done with Ada so I'll go switch to XYZ..." I think Ada tends to suffer from the mindset of "If the world doesn't want to fit into my software development theories, then so much the worse for the world." Everyone wants to avoid making Ada a messy hodgepodge of 'features' like one finds with C, but a little more focus on practical help to the average developer out there might go a long way. MDC Warren W. Gay VE3WWG wrote: > > The result of this discussion seems to suggest that most > are resisting the idea, for different reasons. So > be it. Maybe with time, resistance to the idea will fade > as more people try to address the practical problems that > Open Sourced projects face in Ada. One can hope ;-) > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-02-07 13:18 ` Marin David Condic @ 2004-02-09 17:37 ` Warren W. Gay VE3WWG 0 siblings, 0 replies; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-02-09 17:37 UTC (permalink / raw) Marin David Condic wrote: > Unfortunately, the resistance typically "fades" in the form of "Its just > too hard for me to get my job done with Ada so I'll go switch to XYZ..." > I think Ada tends to suffer from the mindset of "If the world doesn't > want to fit into my software development theories, then so much the > worse for the world." Everyone wants to avoid making Ada a messy > hodgepodge of 'features' like one finds with C, but a little more focus > on practical help to the average developer out there might go a long way. > > MDC I couldn't agree more ;-) > Warren W. Gay VE3WWG wrote: >> The result of this discussion seems to suggest that most >> are resisting the idea, for different reasons. So >> be it. Maybe with time, resistance to the idea will fade >> as more people try to address the practical problems that >> Open Sourced projects face in Ada. One can hope ;-) -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-02-06 17:27 ` Warren W. Gay VE3WWG 2004-02-07 13:18 ` Marin David Condic @ 2004-02-10 14:59 ` Jacob Sparre Andersen 2004-02-10 17:57 ` Warren W. Gay VE3WWG 1 sibling, 1 reply; 296+ messages in thread From: Jacob Sparre Andersen @ 2004-02-10 14:59 UTC (permalink / raw) Warren W. Gay VE3WWG wrote: > So the challenge is to use the best technology (Ada) and yet be > capable of accomodating a large range of "environments". Agreed. But don't you agree that allowing a preprocessor to work on package specifications isn't exactly good Ada style. Then you can't trust the package specifications anymore. Although I prefer a simple "choose an appropriate package body" method, I can see some benefits of allowing full preprocessing of package bodies. My main problem right now is: Is it possible to specify a sensible common method for asking the compiler questions about the target environment? How? My first thought was to tell the user (of the compiler) to give the compiler some appropriate flags, indicating the information needed for selecting which package bodies to choose. But that would still leave the problem of making those configuration decisions to the user instead of automating them. Could we ask the compilers to be able to tell us if some library (a string indicating a library name) exists in a specific version (a string indicating a version)? What do compiler vendors say to that? What other kinds of compile time switches do we want to be able to make? Either based on user choice or on the configuration of the target system. > I think because of the targeted end user, Open Sourced projects have > a special "need", compared to perhaps the "typical" Ada project > (whatever that is ;-) Yes. But users of Open Source software already seem to have agreed to use Autoconf/Automake as their "standard" compile-time configuration tool. How does that work on non-Unix systems BTW? > I never suggested that someone should just plop it into the ARG's > lap without doing homework/whatever. All I can do is speak for > myself here, and say that I just wanted to have an open discussion > on the merits of some sort of conditional compilation. Good. Maybe we can actually come up with a suggestion we can sell to the ARG. > The result of this discussion seems to suggest that most are > resisting the idea, for different reasons. So be it. Maybe with > time, resistance to the idea will fade as more people try to address > the practical problems that Open Sourced projects face in Ada. One > can hope ;-) I hope we can find a solution that makes it easier for people who receive a source code package with an Ada program to just compile and run the program, _without_ letting the whole C preprocessor hell loose in Ada too. Greetings, Jacob -- "Hungh. You see! More bear. Yellow snow is always dead give-away." ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-02-10 14:59 ` Standard Ada Preprocessor Jacob Sparre Andersen @ 2004-02-10 17:57 ` Warren W. Gay VE3WWG 2004-02-10 21:49 ` Jacob Sparre Andersen 0 siblings, 1 reply; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-02-10 17:57 UTC (permalink / raw) Jacob Sparre Andersen wrote: > Warren W. Gay VE3WWG wrote: ... > But don't you agree that allowing a preprocessor to work on package > specifications isn't exactly good Ada style. No argument. But I do have a problem to solve. The problem is ugly, and the solution might be ugly too ;-) > Then you can't trust the > package specifications anymore. Although I prefer a simple "choose an > appropriate package body" method, I can see some benefits of allowing > full preprocessing of package bodies. You might be using a different meaning for "trust" than I use. As I see it, it need not be any different trust-wise than #included source code in a C program. You know in advance that certain elements will be compiled certain way in certain environments. I can trust that to be the case no matter how many times that is called upon. I can also trust that things will be compiled in the other environments that will use them. I see no real issue here. I'll agree however, that it is bad style and ugly. > My main problem right now is: Is it possible to specify a sensible > common method for asking the compiler questions about the target > environment? How? That is the problem for Ada that has remained unsolved for (IMO) too long. > My first thought was to tell the user (of the compiler) to give the > compiler some appropriate flags, indicating the information needed for > selecting which package bodies to choose. But that would still leave > the problem of making those configuration decisions to the user > instead of automating them. The problem that exists now is not generating the configuration. That can be done a multitude of ways, and is done in Open Sourced projects all over the place. The problem is taking it from configuration to source code. That is where the rubber hits the road right now. C/C++ deal with this just fine. Ada is challenged here. > Could we ask the compilers to be able to tell us if some library (a > string indicating a library name) exists in a specific version (a > string indicating a version)? What do compiler vendors say to that? > > What other kinds of compile time switches do we want to be able to > make? Either based on user choice or on the configuration of the > target system. It is not up to the compiler to know what configuration to use. But given directions about the configuration, the job is to generate a compiled version of that solution ;-) >>I think because of the targeted end user, Open Sourced projects have >>a special "need", compared to perhaps the "typical" Ada project >>(whatever that is ;-) > > Yes. But users of Open Source software already seem to have agreed to > use Autoconf/Automake as their "standard" compile-time configuration > tool. How does that work on non-Unix systems BTW? Again, Autoconf et al work fine for C/C++ systems. It requires real gyrations to use it with Ada ;-) Presumably, Autoconf could be used in a CYGWIN environment, though I have not tried it myself. Windows is in some ways much easier to config for, since there are fewer variations than exist in the *NIX/*BSD world. There are of course, still variations, and one has to be concerned about what optional components are installed etc. The general approach to Windows seems to be to provide an Intel binary (setup) to do that work. >>The result of this discussion seems to suggest that most are >>resisting the idea, for different reasons. So be it. Maybe with >>time, resistance to the idea will fade as more people try to address >>the practical problems that Open Sourced projects face in Ada. One >>can hope ;-) > > I hope we can find a solution that makes it easier for people who > receive a source code package with an Ada program to just compile and > run the program, _without_ letting the whole C preprocessor hell loose > in Ada too. > > Greetings, > > Jacob The fact that a conditional compilation feature is made available, does not require it to be used. Just by mandating that it is not done by default should help. Certainly safety critical systems where perhaps this type of thing would not be tolerated, you can mandate that it never be used. So given the above, the real resistance is boils down to the argument "I don't want to ever see it". -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-02-10 17:57 ` Warren W. Gay VE3WWG @ 2004-02-10 21:49 ` Jacob Sparre Andersen 2004-02-11 8:34 ` Dmitry A. Kazakov 2004-02-13 17:27 ` Warren W. Gay VE3WWG 0 siblings, 2 replies; 296+ messages in thread From: Jacob Sparre Andersen @ 2004-02-10 21:49 UTC (permalink / raw) Warren W. Gay VE3WWG wrote: > Jacob Sparre Andersen wrote: > > Warren W. Gay VE3WWG wrote: > > But don't you agree that allowing a preprocessor to work on > > package specifications isn't exactly good Ada style. > > No argument. But I do have a problem to solve. The problem is ugly, > and the solution might be ugly too ;-) :-( Do you have any examples, where you would have, or actually have, used a preprocessor on package specifications? (I hope I haven't missed some in the discussion) I probably make too simple systems, but I find it hard to imagine cases, where it wouldn't be more appropriate to - at least - keep the variant parts of the code away from package specifications. > > Then you can't trust the package specifications anymore. Although > > I prefer a simple "choose an appropriate package body" method, I > > can see some benefits of allowing full preprocessing of package > > bodies. > > You might be using a different meaning for "trust" than I use. As I > see it, it need not be any different trust-wise than #included > source code in a C program. You know in advance that certain > elements will be compiled certain way in certain environments. I can > trust that to be the case no matter how many times that is called > upon. My problem is that if the package specifications vary with the target environment, that means that all the code using that package also may have to vary with the target environment, and thus propagate use of conditional compilation. - I doubt that the ARG would let that into the standard. > > My main problem right now is: Is it possible to specify a sensible > > common method for asking the compiler questions about the target > > environment? How? > > That is the problem for Ada that has remained unsolved for (IMO) too > long. Haven't anybody tried to put a suggestion together? > > My first thought was to tell the user (of the compiler) to give > > the compiler some appropriate flags, indicating the information > > needed for selecting which package bodies to choose. But that > > would still leave the problem of making those configuration > > decisions to the user instead of automating them. > > The problem that exists now is not generating the configuration. I am not sure I agree. > That can be done a multitude of ways, and is done in Open Sourced > projects all over the place. Yes, but the Open Source world has a de-facto standard for doing it. We should either get those tools to support Ada as well as they support C and C++ or make an easier and safer solution for Ada. > The problem is taking it from configuration to source code. That is > where the rubber hits the road right now. C/C++ deal with this just > fine. Ada is challenged here. I would say that that part is close to trivial - if we can agree to which granularity to support. At one extreme there is the current situation with no formalised conditional compilation, somewhere in between there is letting the compiler choose appropriate package bodies given the configuration parameters, and at the other extreme we have mandating something like the C preprocessor. Personally I would like to have the solution of letting the compiler choose appropriate package bodies. But without some level of automated detection of the target environment, it wouldn't be of much use, and I could just as well handle it myself as I do today. > It is not up to the compiler to know what configuration to use. But > given directions about the configuration, the job is to generate a > compiled version of that solution ;-) I can understand your point of view, but if we really want to compete with `./configure && make && su -c make install`, we have to do better than that. If users have to find out which versions of which libraries are on their systems _and_ how to tell the compiler that information, we are already _far_ behind what I can do myself with existing tools and without much work. > Again, Autoconf et al work fine for C/C++ systems. It requires real > gyrations to use it with Ada ;-) Sure? I have never had to create an Autoconf/Automake configuration from scratch, but I find it hard to imagine that it requires excessive amounts of work to get it to do the testing needed to configure an Ada program. > The fact that a conditional compilation feature is made available, > does not require it to be used. Right. But programmers have an awful habit of using whatever tools available. > So given the above, the real resistance is boils down to the > argument "I don't want to ever see it". If you are talking about full C preprocessor style conditional compilation, you are certainly right. If we are talking about some intermediated solution, where the public part of package specifications are untouched by the conditional compilation mechanism _and_ we can include some implementation advise about the compiler guessing or asking the user the questions needed to resolve the conditional compilation, then I will most likely support it. Jacob -- "I don't want to gain immortality in my works. I want to gain it by not dying." ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-02-10 21:49 ` Jacob Sparre Andersen @ 2004-02-11 8:34 ` Dmitry A. Kazakov 2004-02-13 17:27 ` Warren W. Gay VE3WWG 1 sibling, 0 replies; 296+ messages in thread From: Dmitry A. Kazakov @ 2004-02-11 8:34 UTC (permalink / raw) On 10 Feb 2004 22:49:28 +0100, Jacob Sparre Andersen <sparre@nbi.dk> wrote: >My problem is that if the package specifications vary with the target >environment, that means that all the code using that package also may >have to vary with the target environment, and thus propagate use of >conditional compilation. - I doubt that the ARG would let that into >the standard. Sure. The solution should be based on a contract model. -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-02-10 21:49 ` Jacob Sparre Andersen 2004-02-11 8:34 ` Dmitry A. Kazakov @ 2004-02-13 17:27 ` Warren W. Gay VE3WWG 1 sibling, 0 replies; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-02-13 17:27 UTC (permalink / raw) Jacob Sparre Andersen wrote: > Warren W. Gay VE3WWG wrote: >>Jacob Sparre Andersen wrote: >>>Warren W. Gay VE3WWG wrote: >>>But don't you agree that allowing a preprocessor to work on >>>package specifications isn't exactly good Ada style. >> >>No argument. But I do have a problem to solve. The problem is ugly, >>and the solution might be ugly too ;-) > > :-( > > Do you have any examples, where you would have, or actually have, used > a preprocessor on package specifications? (I hope I haven't missed > some in the discussion) I've kind of run out of steam on this thread. I've pointed out some general examples in the earlier parts of this thread. >>So given the above, the real resistance is boils down to the >>argument "I don't want to ever see it". > > If you are talking about full C preprocessor style conditional > compilation, you are certainly right. No, actually (this has been discussed earlier in this thread). Remember that some of C/C++'s problems are related to #include which is quite different that with-ing a package. However, there are times when you want to with one package over another (for example you want to use the GNAT.* package(s) when using GNAT, and something else to replace if compiling with another compiler). This is just one example and of course you need to conditionally compile code depending upon which package(s) you have with-ed because the functionality may not be the same (certainly the hierarchical names for the package defined items are different also). -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-24 12:56 ` Marin David Condic 2004-01-24 15:53 ` Robert I. Eachus @ 2004-01-30 17:34 ` Warren W. Gay VE3WWG 1 sibling, 0 replies; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-30 17:34 UTC (permalink / raw) Marin David Condic wrote: > That works for some things, but it still will barf when a statement is > compileable for one target but not for another. I'm thinking of a case > where (for example) you can get one size of float for one target, but > for another target that size is not allowed. Hiding it in a > discriminated record isn't going to help if the compiler pukes all over > the alternative you're not going to use. Agreed. The same is true if an API function xyzzy() is only available in a Linux setting but not in an HPUX setting. If may compile, but it will never link. To work around this, you'd then have to link with a bunch of stub functions under HPUX, just to make the link phase successful. This is a very ugly solution for something that is "engineered", IMHO. It is also potentially dangerous, unless of course you pepper all of your stubs with "raise Program_Error" or some such. -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-22 0:05 ` Standard Ada Preprocessor (Was: why ada is so unpopular ?) Robert I. Eachus 2004-01-22 5:59 ` Randy Brukardt @ 2004-01-22 12:47 ` Marin David Condic 2004-01-22 13:24 ` Jean-Pierre Rosen 2004-01-22 17:29 ` Warren W. Gay VE3WWG 2004-01-22 13:19 ` Standard Ada Preprocessor Georg Bauhaus 2 siblings, 2 replies; 296+ messages in thread From: Marin David Condic @ 2004-01-22 12:47 UTC (permalink / raw) O.K., but three things. 1) With it being an enumeral, unless *ALL* implementations use the same ones, I have code that won't compile, right? Assuming Aonix doesn't have an enumeral like: SYSTEM_NAME_GNAT then I clearly can't write "if (SYSTEM_NAME_GNAT) then...". A character string would be more usable in this regard, but then you still need to have some useful set of character strings. This is probably the primary reason it isn't used - its totally useless for any sort of portability concern. The code works so long as its the Gnat compiler doing it, but it doesn't work (or even compile) for Aonix or something else, right? So I might just as well not have had the conditional statements in there in the first place because it didn't work to begin with and it didn't work just as nicely with the "if" statement wrapped around it. It would also be totally unreasonable to expect that all vendors would pick up all other vendor's enumeral sets to make sure it was portable at least at the compilation level. 2) No matter what I do, I can't use this in a *declaration*. Earlier versions of Gnat (for the PC - it wasn't supported on the Alpha and maybe not for others) would support a 96 bit float. Now that has become a 128 bit float. (My guess is that they both held an IEEE 80 bit float, but I never checked that far.) So I'd like some capability to say something like: if (System.Name = "GNAT v12.something") then type X is new Float_96 ; for X'Size use 96 ; elsif (System.Name = "GNAT v15.something") then type X is new Float_128 ; for X'Size use 128 ; end if ; This may be a trivial example that could probably be better done with something like System.Max_Digits, but that doesn't mean there are not more complicated and difficult cases that just plain can't be handled with the current setup. 3) Even in executable parts of the code, this doesn't get you around a problem where one compiler/target will support a given statement and another compiler/target will not. Suppose you had some compiler/target dependent package available to you - GNAT.Something. In a different compiler/target, you have a similar package - AONIX.SomethingElse. You'd like (at some low level of isolation) to build a skin over this by withing the appropriate package and making the appropriate call. Something like: if (System.Name = "GNAT") then with GNAT.Something ; elsif (System.Name = "AONIX") then with AONIX.SomethingElse ; end if ; package Isolation_Skin is procedure Do_The_Thing is begin if (System.Name = "GNAT") then GNAT.Something.Do_It_The_GNAT_Way ; elsif (System.Name = "AONIX") then AONIX.SomethingElse.Do_It_The_AONIX_Way ; end if ; end Do_The_Thing ; end Isolation_Skin ; Under the current system, I can't pull the "with" trick part, but the idea is that the statement: AONIX.SomethingElse.Do_It_The_AONIX_Way may not even be compilable in the Gnat environment. There are plenty of "implementation defined" or "implementation dependent" features of Ada - not to mention compiler bugs, etc., that would make sure that a given body of code might not compile for an implementation, so a simple "if" statement can't get you around it. It must be pre-processed in some manner to effectively comment out the branches that don't work. Granted, you can create two package bodies and isolate it down at that point, but then you've got to configuration manage and build with two bodies. Ada has no "Standard" configuration management or build tools built in to handle this so you get no guarantee from the language that you could provide some kind of build script or whatever to do it. (Hence why developers tend to like some kind of conditional compilation. Its the only way you can *guarantee* that you have a mechanism of getting your code to work on two different platforms.) BTW: I have no hesitation to dip into the package System when I've got to do something system dependent - referencing addresses, etc. For PC/Workstation apps, this isn't that often, but in the embedded world its absolutely critical. Naturally, you try to isolate these dependencies down at some low level so they don't intersperse all throughout the code and make porting a more difficult job, but there should be no reason to hesitate to use System when there is some system dependent feature you need. So at least in *my* individual little Ada culture, there is no phobia about it. :-) MDC Robert I. Eachus wrote: > > Technically what we expected way back when was that users would write > code that depended on the value of System.System_Name, which was made an > Ada constant for just that reason. (Compilers could evaluate "if > System.System_Name = VAX then..." at compile time to eliminate any > overhead.) > > In practice, two things prevented that. First, vendors didn't list all > supported systems in package System, usually just the one you were > compiling for. But more important was that the Ada culture quickly > became to avoid dependencies on System for any reason whatsoever. > > Now, we are where we are: > > ----------------------------------------------------------- > with Ada.Text_IO; use Ada.Text_IO; > with System; use System; > procedure System_Names is > package Name_IO is new Enumeration_IO(System.Name); > begin > Put(" The Available System Names are: "); > for I in System.Name'Range loop > Name_IO.Put(I); > if I = System.Name'Last > then > Put_Line("."); > else > Put(", "); > if Col > 60 then New_Line; end if; > end if; > end loop; > New_Line; > Put(" Current System.System_Name is: "); > Name_IO.Put(System.System_Name); > Put_Line("."); > end System_Names; > ----------------------------------------------------------- > > E:\Ada\Test>system_names > system_names > The Available System Names are: SYSTEM_NAME_GNAT. > > Current System.System_Name is: SYSTEM_NAME_GNAT. > > Is there any compiler that produces a useful output? Of course, with > GNAT at least I can modify system and recompile it. But of course, the > usual is to do the easier thing, and have some other system dependent > package defined by the project will all the dependencies depending on > that. But that forces projects to do the version control that should > come from the compiler switches. (The code generator has to know enough > about the target to patch up System. But for that to work the type > System.Name has to contain a useful set of names.) > > Incidently this is the first program I have written in a while that had > a bug not caught by the compiler. For some reason Are was capitalized > in one of the message strings. ;-) > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-22 12:47 ` Marin David Condic @ 2004-01-22 13:24 ` Jean-Pierre Rosen 2004-01-22 18:20 ` Robert A Duff 2004-01-23 12:59 ` Marin David Condic 2004-01-22 17:29 ` Warren W. Gay VE3WWG 1 sibling, 2 replies; 296+ messages in thread From: Jean-Pierre Rosen @ 2004-01-22 13:24 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 496 bytes --] "Marin David Condic" <nobody@noplace.com> a �crit dans le message de news:400FC65B.2020006@noplace.com... > 1) With it being an enumeral, unless *ALL* implementations use the same > ones, I have code that won't compile, right? Wrong. If you prefer it as string, you can always write: If Name'Image (System_Name) = "Whatever" then .... -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-22 13:24 ` Jean-Pierre Rosen @ 2004-01-22 18:20 ` Robert A Duff 2004-01-23 9:18 ` Jean-Pierre Rosen 2004-01-23 12:59 ` Marin David Condic 1 sibling, 1 reply; 296+ messages in thread From: Robert A Duff @ 2004-01-22 18:20 UTC (permalink / raw) "Jean-Pierre Rosen" <rosen@adalog.fr> writes: > "Marin David Condic" <nobody@noplace.com> a �crit dans le message de news:400FC65B.2020006@noplace.com... > > 1) With it being an enumeral, unless *ALL* implementations use the same > > ones, I have code that won't compile, right? > Wrong. If you prefer it as string, you can always write: > If Name'Image (System_Name) = "Whatever" then .... ... which is always False, even when System_Name = Whatever. ;-) - Bob ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-22 18:20 ` Robert A Duff @ 2004-01-23 9:18 ` Jean-Pierre Rosen 0 siblings, 0 replies; 296+ messages in thread From: Jean-Pierre Rosen @ 2004-01-23 9:18 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 872 bytes --] "Robert A Duff" <bobduff@shell01.TheWorld.com> a �crit dans le message de news:wccd69bx2td.fsf@shell01.TheWorld.com... > "Jean-Pierre Rosen" <rosen@adalog.fr> writes: > > > "Marin David Condic" <nobody@noplace.com> a �crit dans le message de news:400FC65B.2020006@noplace.com... > > > 1) With it being an enumeral, unless *ALL* implementations use the same > > > ones, I have code that won't compile, right? > > Wrong. If you prefer it as string, you can always write: > > If Name'Image (System_Name) = "Whatever" then .... > > ... which is always False, even when System_Name = Whatever. ;-) > Of course, should be "WHATEVER".... Sigh, even in this case, everything posted should be tried on a compiler :-) -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-22 13:24 ` Jean-Pierre Rosen 2004-01-22 18:20 ` Robert A Duff @ 2004-01-23 12:59 ` Marin David Condic 2004-01-23 14:21 ` Jean-Pierre Rosen 2004-01-24 6:02 ` Robert I. Eachus 1 sibling, 2 replies; 296+ messages in thread From: Marin David Condic @ 2004-01-23 12:59 UTC (permalink / raw) O.K. So there's a trick to get around it. (Do we call this "The Other Rosen Trick"? :-) Is Name'Image guaranteed to be in a given character case? (I've not checked that recently & must have forgot.) That may eliminate one possible problem, but it really doesn't help make this feature useful. It still only helps at run time and I could have done that with a package of my own. If it doesn't let you branch around things that won't compile for a given configuration, then it really is mostly useless. MDC Jean-Pierre Rosen wrote: > "Marin David Condic" <nobody@noplace.com> a �crit dans le message de news:400FC65B.2020006@noplace.com... > >>1) With it being an enumeral, unless *ALL* implementations use the same >>ones, I have code that won't compile, right? > > Wrong. If you prefer it as string, you can always write: > If Name'Image (System_Name) = "Whatever" then .... > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-23 12:59 ` Marin David Condic @ 2004-01-23 14:21 ` Jean-Pierre Rosen 2004-01-24 6:02 ` Robert I. Eachus 1 sibling, 0 replies; 296+ messages in thread From: Jean-Pierre Rosen @ 2004-01-23 14:21 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1036 bytes --] "Marin David Condic" <nobody@noplace.com> a �crit dans le message de news:40111AC2.7010802@noplace.com... > O.K. So there's a trick to get around it. (Do we call this "The Other > Rosen Trick"? :-) Is Name'Image guaranteed to be in a given character > case? (I've not checked that recently & must have forgot.) Yes, it is guaranteed upper case (that's why my example is actually wrong!) > That may eliminate one possible problem, but it really doesn't help make > this feature useful. It still only helps at run time and I could have > done that with a package of my own. If it doesn't let you branch around > things that won't compile for a given configuration, then it really is > mostly useless. Sure. I was only addressing your claim that it would be better to have System_Name as a string. In a sense, you already have it. The rest of the discussion is a different issue. -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-23 12:59 ` Marin David Condic 2004-01-23 14:21 ` Jean-Pierre Rosen @ 2004-01-24 6:02 ` Robert I. Eachus 2004-01-24 13:09 ` Marin David Condic 1 sibling, 1 reply; 296+ messages in thread From: Robert I. Eachus @ 2004-01-24 6:02 UTC (permalink / raw) Marin David Condic wrote: > O.K. So there's a trick to get around it. (Do we call this "The Other > Rosen Trick"? :-) Is Name'Image guaranteed to be in a given character > case? (I've not checked that recently & must have forgot.) UPPER_CASE. > That may eliminate one possible problem, but it really doesn't help make > this feature useful. It still only helps at run time and I could have > done that with a package of my own. If it doesn't let you branch around > things that won't compile for a given configuration, then it really is > mostly useless. Is it just me, or is this really an issue? Remember it IS static, which means that it does give you contitional compilation at compile time. What it doesn't give you is the ability to write code that is illegal, and compile anyway if it is not in the (static) execution path. I just never run into this situation unless there is a bug. There is one case that I am aware of where this CAN happen, supplying a value for digits in a floating point type declaration, or declaring an integer or modular type that is too large for the implementation. Of course, I use GNAT. GNAT now supports IEEE floating-point and 64-bit integer, fixed, decimal, and modular types for all versions. That is enough for me. -- Robert I. Eachus "The war on terror is a different kind of war, waged capture by capture, cell by cell, and victory by victory. Our security is assured by our perseverance and by our sure belief in the success of liberty." -- George W. Bush ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-24 6:02 ` Robert I. Eachus @ 2004-01-24 13:09 ` Marin David Condic 2004-01-24 19:32 ` tmoran 0 siblings, 1 reply; 296+ messages in thread From: Marin David Condic @ 2004-01-24 13:09 UTC (permalink / raw) Maybe its just you. :-) I don't run into it every day - its just that when you run into it, its like hitting a brick wall at 100mph. Code can be 100% totally legal and not compile. I can write you representation clauses all day long that are 100% pure Ada and will just make the compiler puke all over the place. (Or perhaps not give you what you want - which may be even worse). Compiler X may support the statement but Compiler Y may not. Worse, Compiler X for Target A may consider it legal but Compiler X for Target B does not. When you run into it, you end up pulling out your hair wishing you had some means of making the compiler ignore the version of the statement that you don't want for the particular target. Sometimes its a really, really little thing and you start considering another layer of indirection and separate build paths and the potential inefficiencies of the extra indirection (for me, that's often an issue) and you're going "Damnation! If I just had one little itsy-bitsy, insignificant, tiny conditional compilation directive here, I'd save myself the massive trouble of having to deal with two separate builds and all the headaches that go with it! Curse you, Ada Lovelace!!!" I'd rather not have that headache - and sometimes there are prohibitions or problems with multiple build paths that make it difficult or impossible. So you find some way of suffering under durress and muddling through and envying the guys who get to use C. :-) MDC Robert I. Eachus wrote: > > Is it just me, or is this really an issue? Remember it IS static, which > means that it does give you contitional compilation at compile time. > What it doesn't give you is the ability to write code that is illegal, > and compile anyway if it is not in the (static) execution path. > > I just never run into this situation unless there is a bug. There is > one case that I am aware of where this CAN happen, supplying a value for > digits in a floating point type declaration, or declaring an integer or > modular type that is too large for the implementation. > > Of course, I use GNAT. GNAT now supports IEEE floating-point and 64-bit > integer, fixed, decimal, and modular types for all versions. That is > enough for me. > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-24 13:09 ` Marin David Condic @ 2004-01-24 19:32 ` tmoran 2004-01-24 20:34 ` Marin David Condic 0 siblings, 1 reply; 296+ messages in thread From: tmoran @ 2004-01-24 19:32 UTC (permalink / raw) >and you're going "Damnation! If I just had one little itsy-bitsy, >insignificant, tiny conditional compilation directive here, I'd save If the preprocessor was limited to something like --Gnat_Win32 <<code for Gnat on Win32 target>> --ObjectAda_Linux <<code for ObjectAda, Linux target>> I would agree that's helpful. But as soon as the preprocessor gets non-trivial - nested conditionals, includes, etc - it's just begging for idiots (and even some otherwise non-idiots) to create a mess. I've seen C code from large and well known companies that is nearly impenetrable due to overuse of the preprocessor. If they had spent 1/10 the effort on good design-for-multiple-systems, it would have been maintainable, but it's much easier to add a (preprocessor) tweak here and there and let the mess grow. And the answer "good programmers will not misuse the language" doesn't fly very well in c.l.a. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-24 19:32 ` tmoran @ 2004-01-24 20:34 ` Marin David Condic 0 siblings, 0 replies; 296+ messages in thread From: Marin David Condic @ 2004-01-24 20:34 UTC (permalink / raw) Oh yes! Of course! I agree 1000%! I've *seen* and had to maintain things where the C preprocessor was abused to the point where one could spend days trying to decipher macros and all that. Let's not even start with #include chains! I absolutely don't want something that would turn into an unholy mess. I think some relatively simple directive(s) that could give you one version of something when its Compiler A and another version of something if its Compiler B (or likewise for possibly unsupported packages, or OS dependencies) that would be enough to minimize the fuss when you've got relatively small & trivial things to go fix. Of course a lot of these things have a nasty habbit of growing along the way into something way beyond the original intent. MDC tmoran@acm.org wrote: >>and you're going "Damnation! If I just had one little itsy-bitsy, >>insignificant, tiny conditional compilation directive here, I'd save > > If the preprocessor was limited to something like > --Gnat_Win32 <<code for Gnat on Win32 target>> > --ObjectAda_Linux <<code for ObjectAda, Linux target>> > I would agree that's helpful. But as soon as the preprocessor gets > non-trivial - nested conditionals, includes, etc - it's just begging for > idiots (and even some otherwise non-idiots) to create a mess. I've seen C > code from large and well known companies that is nearly impenetrable due > to overuse of the preprocessor. If they had spent 1/10 the effort on good > design-for-multiple-systems, it would have been maintainable, but it's > much easier to add a (preprocessor) tweak here and there and let the mess > grow. And the answer "good programmers will not misuse the language" > doesn't fly very well in c.l.a. -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-22 12:47 ` Marin David Condic 2004-01-22 13:24 ` Jean-Pierre Rosen @ 2004-01-22 17:29 ` Warren W. Gay VE3WWG 1 sibling, 0 replies; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-22 17:29 UTC (permalink / raw) Marin David Condic wrote: > O.K., but three things. > ... > if (System.Name = "GNAT") then > with GNAT.Something ; > elsif (System.Name = "AONIX") then > with AONIX.SomethingElse ; > end if ; > > package Isolation_Skin is > procedure Do_The_Thing is > begin > if (System.Name = "GNAT") then > GNAT.Something.Do_It_The_GNAT_Way ; > elsif (System.Name = "AONIX") then > AONIX.SomethingElse.Do_It_The_AONIX_Way ; > end if ; > end Do_The_Thing ; > end Isolation_Skin ; ... Another very good point! -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-22 0:05 ` Standard Ada Preprocessor (Was: why ada is so unpopular ?) Robert I. Eachus 2004-01-22 5:59 ` Randy Brukardt 2004-01-22 12:47 ` Marin David Condic @ 2004-01-22 13:19 ` Georg Bauhaus 2004-01-22 13:49 ` Marin David Condic 2004-01-22 14:12 ` Dmitry A. Kazakov 2 siblings, 2 replies; 296+ messages in thread From: Georg Bauhaus @ 2004-01-22 13:19 UTC (permalink / raw) Robert I. Eachus <rieachus@comcast.net> wrote: : E:\Ada\Test>system_names : system_names : The Available System Names are: SYSTEM_NAME_GNAT. : : Current System.System_Name is: SYSTEM_NAME_GNAT. : : Is there any compiler that produces a useful output? ObjectAda: The Available System Names are: S370, I80X86, I80386, MC680X0, VAX, TRANSPUTER, RS_6000, MIPS, HP9000_PA_RISC, HP9000_300, SPARC. Current System.System_Name is: I80386. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-22 13:19 ` Standard Ada Preprocessor Georg Bauhaus @ 2004-01-22 13:49 ` Marin David Condic 2004-01-22 15:03 ` Georg Bauhaus 2004-01-22 14:12 ` Dmitry A. Kazakov 1 sibling, 1 reply; 296+ messages in thread From: Marin David Condic @ 2004-01-22 13:49 UTC (permalink / raw) Better than Gnat, but still not terribly useful if you want to make code that will compile on both a Gnat and an Aonix platform. MDC Georg Bauhaus wrote: > > ObjectAda: > The Available System Names are: S370, I80X86, I80386, MC680X0, > VAX, TRANSPUTER, RS_6000, MIPS, HP9000_PA_RISC, HP9000_300, > SPARC. > > Current System.System_Name is: I80386. > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-22 13:49 ` Marin David Condic @ 2004-01-22 15:03 ` Georg Bauhaus 2004-01-22 17:33 ` Warren W. Gay VE3WWG 2004-01-23 13:11 ` Marin David Condic 0 siblings, 2 replies; 296+ messages in thread From: Georg Bauhaus @ 2004-01-22 15:03 UTC (permalink / raw) Marin David Condic <nobody@noplace.com> wrote: : Better than Gnat, but still not terribly useful if you want to make code : that will compile on both a Gnat and an Aonix platform. What kind of difficulties do you see that could be better solved by a preprocessor? (Things supported in GNAT but not ObjectAda or vice versa? Dependence on pragmata?) I have code that is compiled by OA 722, by GCC 34, but not by GNAT 3.15p. Ada source text is chopped where necessary using make. (Operating) System specific routines are are assembled into a package hierarchy (which I naively had top-level-named "System" (and that triggers a bug box in GCC 34 after looping (the maintainers say that, obviously, a library unit should not be modified...))) Then a branch renames package Systems.Windows, another renames package Systems.UNIX (or similarly). The problem that leads GNAT 3.15p to reject another unit is apparently a bug in GNAT 3.15p that has been fixed in GCC 34. I like this better than having to construct sources around a compiler bug/limitation using hopefully temporary preprocessor #ifs. -- Georg ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-22 15:03 ` Georg Bauhaus @ 2004-01-22 17:33 ` Warren W. Gay VE3WWG 2004-01-22 19:02 ` Georg Bauhaus 2004-01-23 13:11 ` Marin David Condic 1 sibling, 1 reply; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-22 17:33 UTC (permalink / raw) Georg Bauhaus wrote: > Marin David Condic <nobody@noplace.com> wrote: > : Better than Gnat, but still not terribly useful if you want to make code > : that will compile on both a Gnat and an Aonix platform. > > What kind of difficulties do you see that could be better solved > by a preprocessor? (Things supported in GNAT but not ObjectAda or vice > versa? Dependence on pragmata?) MDC pointed out that you cannot conditionally do "with" as one example. Implementation defined pragmas are another area of difficulty. Optional features are a pain to deal with since there is no way to feed values into a compile process (using make), without creating make "steps" that process the source code before hand (ie. this becomes a manual preprocessing step). -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-22 17:33 ` Warren W. Gay VE3WWG @ 2004-01-22 19:02 ` Georg Bauhaus 2004-01-23 17:35 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 296+ messages in thread From: Georg Bauhaus @ 2004-01-22 19:02 UTC (permalink / raw) Warren W. Gay VE3WWG <warren@ve3wwg.tk> wrote: : MDC pointed out that you cannot conditionally do "with" : as one example. Withing or not cannot be an option unless another possibly related conditional requires a unit or not. If there is no other conditional text, renaming an empty package will do. : Implementation defined pragmas are : another area of difficulty. Optional features are : a pain to deal with since there is no way to feed : values into a compile process (using make), : without creating make "steps" that process the : source code before hand (ie. this becomes a manual : preprocessing step). So what is the greater pain? To me, placing conditionals near the conditional sections is tempting, but usually leads to #ifs all over the place. It is like writing tasking constructs without language support, or like wrting your own dispatcher. If we had a way to declare for any of the 2**N compilations which conditions are to be met, and which parts of the program text have to be in place for one of the compilations, configuration could be done in a systematic manner, with the help of a computer program that does configuration checking, and with a readable statement (declarative in style) of the programs dependences. -- Georg ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-22 19:02 ` Georg Bauhaus @ 2004-01-23 17:35 ` Warren W. Gay VE3WWG 2004-01-24 1:50 ` Marin David Condic 2004-01-24 6:08 ` Robert I. Eachus 0 siblings, 2 replies; 296+ messages in thread From: Warren W. Gay VE3WWG @ 2004-01-23 17:35 UTC (permalink / raw) Georg Bauhaus wrote: > Warren W. Gay VE3WWG <warren@ve3wwg.tk> wrote: > : MDC pointed out that you cannot conditionally do "with" > : as one example. > > Withing or not cannot be an option unless another possibly > related conditional requires a unit or not. > If there is no other conditional text, renaming an empty > package will do. Perhaps I don't understand your point here, but if I supply a parameter on the command line to the compiler that says I am compiling with GNAT (or PDcurses or whatever), then I can at compile time choose what packages I am going to "need". I don't find any reason to see prevent a conditional compile condition here. > : Implementation defined pragmas are > : another area of difficulty. Optional features are > : a pain to deal with since there is no way to feed > : values into a compile process (using make), > : without creating make "steps" that process the > : source code before hand (ie. this becomes a manual > : preprocessing step). > > So what is the greater pain? > To me, placing conditionals near the conditional sections is > tempting, but usually leads to #ifs all over the place. If you have #ifs all over the place, it is because you need them ;-) Granted much of this abuse on the C/C++ side is related to how C/C++ works in the first place. So drawing parallels to C should be done carefully. There is still a strong need for conditional compilation. Not for embedded work, since you have very specific targets for that code. But if Ada is to support the general purpose computing environment, and to support portability, it must have better facilities for the portability issues that come up. > It is > like writing tasking constructs without language support, or > like wrting your own dispatcher. If we had a way to declare for > any of the 2**N compilations which conditions are to be met, and > which parts of the program text have to be in place for one of the > compilations, configuration could be done in a systematic manner, > with the help of a computer program that does configuration checking, > and with a readable statement (declarative in style) of the programs > dependences. Tell me, how do you solve the situation where API call to your OS requires 3 parameters on one platform, and 2 on another? No if statement can solve that for you. -- Warren W. Gay VE3WWG http://ve3wwg.tk ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-23 17:35 ` Warren W. Gay VE3WWG @ 2004-01-24 1:50 ` Marin David Condic 2004-01-24 5:33 ` Randy Brukardt 2004-01-24 6:08 ` Robert I. Eachus 1 sibling, 1 reply; 296+ messages in thread From: Marin David Condic @ 2004-01-24 1:50 UTC (permalink / raw) Even in embedded work it is sometimes important. I might have code that relates to some breadboard version of the system that dummies up some stuff that exists differently on the "real" hardware. Or I might want to make a version of some of the code that operates on a workstation by faking out hardware that exists in the real unit. Or I might have multiple turns of a hardware board that each have peculiarities that need to be coded around. Or I might have multiple versions of an RTOS with variations on system calls that change from one version to the next. I've encountered all of these in real-world situations and sometimes I might have dealt with them by having separate bodies (often really difficult to manage in practice) or I dealt with them via conditional compilation because I was using C. I just know it happens enough where conditional compilation would be a useful thing and not always a matter of abuse. If someone thinks it isn't really needed because it can be dealt with via some kind of CM or build process - I'd suggest they need to work in some of the environments I've been in where you either don't have the tools or there are all sorts of complications that make this really hard to do. Conditional compilation isn't always pretty - but then neither are rep clauses or other things that are regularly done because that's the easiest way to get the job done. MDC Warren W. Gay VE3WWG wrote: > > There is still a strong need for conditional compilation. > Not for embedded work, since you have very specific > targets for that code. But if Ada is to support the > general purpose computing environment, and to support > portability, it must have better facilities for the > portability issues that come up. > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-24 1:50 ` Marin David Condic @ 2004-01-24 5:33 ` Randy Brukardt 2004-01-24 13:28 ` Marin David Condic 0 siblings, 1 reply; 296+ messages in thread From: Randy Brukardt @ 2004-01-24 5:33 UTC (permalink / raw) "Marin David Condic" <nobody@noplace.com> wrote in message news:4011CF46.3040001@noplace.com... ... > I've encountered all of these in real-world situations and sometimes I > might have dealt with them by having separate bodies (often really > difficult to manage in practice) or I dealt with them via conditional > compilation because I was using C. I just know it happens enough where > conditional compilation would be a useful thing and not always a matter > of abuse. If someone thinks it isn't really needed because it can be > dealt with via some kind of CM or build process - I'd suggest they need > to work in some of the environments I've been in where you either don't > have the tools or there are all sorts of complications that make this > really hard to do. You want to change the language because you've had to work in poorly managed shops with insufficient tools? Sure, we all do what we have to do to get the job done, but that hardly justifies a major language change (and one where no obvious workable solution springs to mind). > Conditional compilation isn't always pretty - but then neither are rep > clauses or other things that are regularly done because that's the > easiest way to get the job done. I think you're comparing apples to oranges. Rep clauses are an elegant way of getting the job done; the only alternative is bit mask operations and those are a lot harder to understand. And they certainly aren't about just interfacing to hardware - I use them a lot to reduce storage use without making critical parts too slow. So I guess I'd say that rep. clauses ARE pretty. You'd be better off picking on Access_to_Address_Conversions or something like that -- except that no one much uses any of those packages. Perhaps because they are ugly. I'm not personally against conditional compilation, I just don't see any way to integrate a useful form of it into the language. (I don't think it is necessary in an ideal world, but the world is hardly ideal - people write gibberish in C and Java after all.) The form that Janus/Ada has (and we no longer use in new code because it isn't flexible enough) is a pure binary in-or-out scheme intended solely for marking debugging code. ('@' is either compiled as a comment "--" or as a space ' ' depending on the command line options.) Pragmas have a number of problems: they can't be used in some parts of the code (for example, formal_parts and discriminant_parts); such a pragma would violate "good taste in pragmas" as laid out in 2.8; and enough people think that they're ugly to prevent them from being used this way. (GNAT's pragma Debug was considered and discarded for this reason.) Some sort of syntax would be needed, and that seems like it would be pretty heavy. (And I have no idea what it ought to look like.) If you want to propose something, feel free, but remember that the ARG is not taking new topics anymore, so unless you can find a way to coordinate it with an existing AI, it will have to wait for Ada 1Z. Randy. All-in-all, it seems like there ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-24 5:33 ` Randy Brukardt @ 2004-01-24 13:28 ` Marin David Condic 2004-01-24 15:58 ` Robert I. Eachus ` (2 more replies) 0 siblings, 3 replies; 296+ messages in thread From: Marin David Condic @ 2004-01-24 13:28 UTC (permalink / raw) Rep clauses are ugly in the sense that "In A Perfect World" we'd want to let the compiler worry about how to represent data. Inherently, they make the code compiler and target dependent. By their very existence, you can't just hand someone some body of code and say "Trust me. It will compile & run on your machine..." Rep clauses are actually one of the better arguments for needing conditional compilation. (Target A? Use this rep! Target B? Use that one!) Oh sure. They are better than a sharp stick in the eye and if you have to control representation, they're an elegant solution. But they are still "Butt Ugly" in the sense that the instant you use one, you can't promise that the code will work *anywhere* except on the one compiler/target where you built it. As for submitting something to the ARG? I'll leave that to the language lawyers. They'll come up with far better proposals than I could ever write - so long as they think the idea might be a good one. I'm just the end-user of Ada - a customer - expressing what he thinks would make the language more usable on a day-to-day level. We're a dwindling herd, so maybe those opinions ought to get some attention by the people who make and sell Ada. Hope springs eternal! :-) MDC Randy Brukardt wrote: > > I think you're comparing apples to oranges. Rep clauses are an elegant way > of getting the job done; the only alternative is bit mask operations and > those are a lot harder to understand. And they certainly aren't about just > interfacing to hardware - I use them a lot to reduce storage use without > making critical parts too slow. So I guess I'd say that rep. clauses ARE > pretty. You'd be better off picking on Access_to_Address_Conversions or > something like that -- except that no one much uses any of those packages. > Perhaps because they are ugly. -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-24 13:28 ` Marin David Condic @ 2004-01-24 15:58 ` Robert I. Eachus 2004-01-24 16:11 ` Marin David Condic 2004-01-24 19:32 ` tmoran 2004-01-24 23:39 ` Randy Brukardt 2 siblings, 1 reply; 296+ messages in thread From: Robert I. Eachus @ 2004-01-24 15:58 UTC (permalink / raw) Marin David Condic wrote: > Rep clauses are ugly in the sense that "In A Perfect World" we'd want to > let the compiler worry about how to represent data. Inherently, they > make the code compiler and target dependent. By their very existence, > you can't just hand someone some body of code and say "Trust me. It will > compile & run on your machine..." Rep clauses are actually one of the > better arguments for needing conditional compilation. (Target A? Use > this rep! Target B? Use that one!) Somebody wrote an article (for Ada Letters I think) on how to write representation specifications that are legal (and identical!) for bigendian and little endian hardware. Anyone remember it? I tend now to target only x86 family machines, where MMX, 3dNow!, SSE, and SSE2 give me enough headaches. ;-) -- Robert I. Eachus "The war on terror is a different kind of war, waged capture by capture, cell by cell, and victory by victory. Our security is assured by our perseverance and by our sure belief in the success of liberty." -- George W. Bush ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-24 15:58 ` Robert I. Eachus @ 2004-01-24 16:11 ` Marin David Condic 0 siblings, 0 replies; 296+ messages in thread From: Marin David Condic @ 2004-01-24 16:11 UTC (permalink / raw) Possible. But endianness is *not* the only reason for the existence of rep clauses. So while you *might* write portable endianness code, you can't figure that's the answer to everything. Somewhere a rep clause is going to work for one target and you'll need a different rep clause for a different target. Until all compilers and environments are exactly alike, you'll have some kind of problem like this. MDC Robert I. Eachus wrote: > > Somebody wrote an article (for Ada Letters I think) on how to write > representation specifications that are legal (and identical!) for > bigendian and little endian hardware. Anyone remember it? I tend now > to target only x86 family machines, where MMX, 3dNow!, SSE, and SSE2 > give me enough headaches. ;-) > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-24 13:28 ` Marin David Condic 2004-01-24 15:58 ` Robert I. Eachus @ 2004-01-24 19:32 ` tmoran 2004-01-24 20:44 ` Marin David Condic 2004-01-24 23:39 ` Randy Brukardt 2 siblings, 1 reply; 296+ messages in thread From: tmoran @ 2004-01-24 19:32 UTC (permalink / raw) >Rep clauses are ugly in the sense that "In A Perfect World" we'd want to >let the compiler worry about how to represent data. Inherently, they >make the code compiler and target dependent. By their very existence, >you can't just hand someone some body of code and say "Trust me. It will I don't understand what you use rep clauses for. I normally use them when a data structure must be shared outside my program, by a hardware device, an OS call, another program, etc. For those, the rep clause does not change when you change compiler or target machine - unless your target *requires* a change because it demands a different representation. Not even a perfect compiler could do that automatically. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-24 19:32 ` tmoran @ 2004-01-24 20:44 ` Marin David Condic 2004-01-25 5:02 ` Robert I. Eachus 0 siblings, 1 reply; 296+ messages in thread From: Marin David Condic @ 2004-01-24 20:44 UTC (permalink / raw) A simple case: Suppose you are developing for an embedded box but you want to do some simple "Smoke Testing" on a PC. For the embedded box, you need a rep clause for some register. For the PC you're dummying that up with something and don't want a rep clause at all. (Or the PC compiler barfs on the rep clause that the embedded compiler accepts.) It would be nice to say "If compiling for the PC with Aonix, use this code (no rep), but if compiling for the target with the Gnat compiler, go use that code..." I've also run into situations where the hardware weenies are working as fast as we software bozos are and every few weeks, you're getting new turns of a board with different hardware in it. You still need to compile for earlier boards but now you have something different - probably with a different rep clause. I don't want to go into some complex CM and build process just for the developmental stuff - I just need a quick and dirty answer to being able to get the code to work on two (or more) boxes short-term. That's why I'm saying that conditional compilation may be ugly and intellectually unsatisfying and not "The Perfect World" but often you've got circumstances that make it the best, expedient choice for fixing a real world situation. And yes, I agree it can be abused. Maybe there is some way of making it simple enough to get a job done but not powerful enough to make an atrocity. But its been observed that there never has been a programming language in which it has been the least bit hard to write bad code. Maybe we can just accept that and live with it. MDC tmoran@acm.org wrote: > > I don't understand what you use rep clauses for. I normally use them > when a data structure must be shared outside my program, by a hardware > device, an OS call, another program, etc. For those, the rep clause does > not change when you change compiler or target machine - unless your target > *requires* a change because it demands a different representation. Not > even a perfect compiler could do that automatically. -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-24 20:44 ` Marin David Condic @ 2004-01-25 5:02 ` Robert I. Eachus 2004-01-25 16:38 ` Marin David Condic 0 siblings, 1 reply; 296+ messages in thread From: Robert I. Eachus @ 2004-01-25 5:02 UTC (permalink / raw) Marin David Condic wrote: > A simple case: Suppose you are developing for an embedded box but you > want to do some simple "Smoke Testing" on a PC. For the embedded box, > you need a rep clause for some register. For the PC you're dummying that > up with something and don't want a rep clause at all. (Or the PC > compiler barfs on the rep clause that the embedded compiler accepts.) It > would be nice to say "If compiling for the PC with Aonix, use this code > (no rep), but if compiling for the target with the Gnat compiler, go use > that code..." You are familar with RM 13.1(22) right? "An implementation need not support representation items containing nonstatic expressions, except that an implementation should support a representation item for a given entity if each nonstatic expression in the representation item is a name that statically denotes a constant declared before the entity." I know it is Implemenation Advice, but especially for Address representation specifications it is almost required of any decent compiler that they support at least this. If you don't understand how to read it look at the "Rosen trick": function Random(Gen: Generator) return Float is Local: Generator; for Local'Address use Gen'Address; begin .... end Random; The value of Gen'Address is definitely non-static. But it is easy for a compiler to "get it right" in this case because the value of Local'Address each time the declaration of Local is elaborated. What has this got to do with Marin's complaint? He thinks that invalid representation clauses must be illegal. If they are non-static they can't be illegal because the value to be set at run-time is wrong. Either the compiler will raise Program_Error at run-time or execution of the invalid representation clause will make the program erroneous. See for example RM 13.3(13): "If an Address is specified, it is the programmer's responsibility to ensure that the address is valid; otherwise, program execution is erroneous." Since the address in the representation clause need not be static, your program can set it at run-time depending on the hardware involved. You mean you have never done that? I have code with address clauses that depend on system calls made at run-time. So loosen up a little Marin, and try writing non-static representation clauses. Remember 13.1(22) that I referenced above, and that 'Size for objects (but not subtypes) must be static, RM 13.3(41). But you should be able to do a lot more with Rep clauses than you have done so far. ;-) -- Robert I. Eachus "The war on terror is a different kind of war, waged capture by capture, cell by cell, and victory by victory. Our security is assured by our perseverance and by our sure belief in the success of liberty." -- George W. Bush ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-25 5:02 ` Robert I. Eachus @ 2004-01-25 16:38 ` Marin David Condic 2004-01-26 16:03 ` Robert I. Eachus 0 siblings, 1 reply; 296+ messages in thread From: Marin David Condic @ 2004-01-25 16:38 UTC (permalink / raw) I'm not talking about addresses. Have you never seen a rep clause on a record, for example, that a given compiler will refuse to accept even if it is syntactically legal? I don't happen to have one sitting in my back pocket at the moment, but I *know* I've coded up valid rep clauses on records that compilers have spit out and refused to accept. Technically, it is legal for an implementation to refuse just about any rep clause it doesn't want to be bothered with - so perhaps you've got it coded up one way for one compiler and another way for another compiler. Perhaps there's some arcane trick that can be pulled to change rep clauses on a record on the fly, but I've not seen it (and it sure starts sounding *far* more complex than decrypting a simple conditional compilation directive - maybe this is what frustrates me about the opposition to a conditional compile: Everyone holds out some cumbersome, complex, arcane trickery that is orders of magnitude more difficult to understand and utilize properly as an answer in order to avoid something that is capable of being pretty simple & basic.). What I *have* seen is rep clauses that a compiler refuses to accept - and hence I can't even *get* to runtime because I've got compile errors. Legal or not - Moral or not - I still have to get a job done and a conditonal compilation directive of some sort would fix the problem. MDC Robert I. Eachus wrote: > > You are familar with RM 13.1(22) right? "An implementation need not > support representation items containing nonstatic expressions, except > that an implementation should support a representation item for a given > entity if each nonstatic expression in the representation item is a name > that statically denotes a constant declared before the entity." > > I know it is Implemenation Advice, but especially for Address > representation specifications it is almost required of any decent > compiler that they support at least this. If you don't understand how > to read it look at the "Rosen trick": > > function Random(Gen: Generator) return Float is > Local: Generator; > for Local'Address use Gen'Address; > begin > .... > end Random; > > The value of Gen'Address is definitely non-static. But it is easy for a > compiler to "get it right" in this case because the value of > Local'Address each time the declaration of Local is elaborated. > > What has this got to do with Marin's complaint? He thinks that invalid > representation clauses must be illegal. If they are non-static they > can't be illegal because the value to be set at run-time is wrong. > Either the compiler will raise Program_Error at run-time or execution of > the invalid representation clause will make the program erroneous. See > for example RM 13.3(13): "If an Address is specified, it is the > programmer's responsibility to ensure that the address is valid; > otherwise, program execution is erroneous." > > Since the address in the representation clause need not be static, your > program can set it at run-time depending on the hardware involved. You > mean you have never done that? I have code with address clauses that > depend on system calls made at run-time. > > So loosen up a little Marin, and try writing non-static representation > clauses. Remember 13.1(22) that I referenced above, and that 'Size for > objects (but not subtypes) must be static, RM 13.3(41). But you should > be able to do a lot more with Rep clauses than you have done so far. ;-) > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-25 16:38 ` Marin David Condic @ 2004-01-26 16:03 ` Robert I. Eachus 0 siblings, 0 replies; 296+ messages in thread From: Robert I. Eachus @ 2004-01-26 16:03 UTC (permalink / raw) Marin David Condic wrote: > I'm not talking about addresses. Have you never seen a rep clause on a > record, for example, that a given compiler will refuse to accept even if > it is syntactically legal? I don't happen to have one sitting in my back > pocket at the moment, but I *know* I've coded up valid rep clauses on > records that compilers have spit out and refused to accept. Technically, > it is legal for an implementation to refuse just about any rep clause it > doesn't want to be bothered with - so perhaps you've got it coded up one > way for one compiler and another way for another compiler. > > Perhaps there's some arcane trick that can be pulled to change rep > clauses on a record on the fly, but I've not seen it (and it sure starts > sounding *far* more complex than decrypting a simple conditional > compilation directive - maybe this is what frustrates me about the > opposition to a conditional compile: Everyone holds out some cumbersome, > complex, arcane trickery that is orders of magnitude more difficult to > understand and utilize properly as an answer in order to avoid something > that is capable of being pretty simple & basic.). What I *have* seen is > rep clauses that a compiler refuses to accept - and hence I can't even > *get* to runtime because I've got compile errors. Legal or not - Moral > or not - I still have to get a job done and a conditonal compilation > directive of some sort would fix the problem. Sigh, if you want to win the debate, fine, but I can't help you. If you want to have an easier time of it when writing implementation dependent code, pay attention. My point is not that I have a magic wand that can be waved over your program to reduce the amount of implementation code to zero. My point is that if you are willing to do things the Ada way instead of the C way, the number of system dependent files becomes very small. It would be nice if you could write your code so that all of the that code depended on System, so you didn't need to maintain multiple versions. To some extent that is a bug in the language that we discussed in this thread. (Implementations where System.Name is useless.) What I am trying to say, is use these techniques, and you will end up with one or two files that need to be changed when porting. If you want to use a preprocessor to maintain that file, fine. Many Ada compilers actually supply one, or you can use cpp. Personally my style is to provide a "generic" version and to expect those who port the code to tailor it. Optimally, that file contains only a package body, but doing that requires going to extremes you might not like. Just to give one example, You might define two interfaces for some OS calls and choose which one to use every time the interface is called. This requires that the code that calls them, and the parameters passed, are in a nested scope. This often adds extra overhead to system calls. Worth it? You choose. But putting all the system dependent cruft in one compilation unit in my experience, should be automatic. -- Robert I. Eachus "The war on terror is a different kind of war, waged capture by capture, cell by cell, and victory by victory. Our security is assured by our perseverance and by our sure belief in the success of liberty." -- George W. Bush ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-24 13:28 ` Marin David Condic 2004-01-24 15:58 ` Robert I. Eachus 2004-01-24 19:32 ` tmoran @ 2004-01-24 23:39 ` Randy Brukardt 2004-01-25 13:47 ` Stephane Richard 2 siblings, 1 reply; 296+ messages in thread From: Randy Brukardt @ 2004-01-24 23:39 UTC (permalink / raw) "Marin David Condic" <nobody@noplace.com> wrote in message news:401272E3.4040506@noplace.com... ... > Oh sure. They are better than a sharp stick in the eye and if you have > to control representation, they're an elegant solution. But they are > still "Butt Ugly" in the sense that the instant you use one, you can't > promise that the code will work *anywhere* except on the one > compiler/target where you built it. There is hardly any (useful) code that will work *anywhere*. Most existing free Ada code won't run on Janus/Ada out of the box because Integer is 16-bit -- and thus a lot of operations overflow. (Of course, there's no problem with proper type declarations, but those are rare.) And a lot of code is dependent in some way on the target - for GUI or output devices or whatever. Certainly adding a rep. clause has little effect on that. Especially if your world view pretty much starts and ends with PC hardware (as mine does practically). We build Claw from the ground up with the intent of making it portable to every Windows compiler -- yet there a quite a few differences that we have to deal with. So rep. clauses don't bother me; it is extremely rare that they would make code less portable than it already is. > As for submitting something to the ARG? I'll leave that to the language > lawyers. They'll come up with far better proposals than I could ever > write - so long as they think the idea might be a good one. The language lawyers are unlikely to even pay any attention to it unless you submit a worked out change request. We have enough such requests that we certainly aren't looking for more! I view this is list pretty much as what Robert Dewar called a "chat list" - a place where people gripe a lot, turn molehills into mountains (and vice versa), and you can't gauge much of anything by the conversations here. I read this list mainly as part of my work for one of my other hats (webmaster at adaic.org) -- I'm trolling for newsworthy items. There have been occassional ideas where I got excited enough to propose something to the ARG ("private with" is the one that comes to mind), but these days I feel swamped enough that it would have to be a stupendous idea before I'd make more work for myself. So, if you want something done, you need to take action to make a proposal on Ada-Comment. It certainly doesn't need to be perfect - and even if it is, the ARG would change it all around before standardizing it - but if no one asks, it's very unlikely that the topic would even come up. Griping here may feel good, but it has virtually no impact on the future of Ada. Randy. I'm just the > end-user of Ada - a customer - expressing what he thinks would make the > language more usable on a day-to-day level. We're a dwindling herd, so > maybe those opinions ought to get some attention by the people who make > and sell Ada. Hope springs eternal! :-) ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-24 23:39 ` Randy Brukardt @ 2004-01-25 13:47 ` Stephane Richard 2004-01-26 19:19 ` Randy Brukardt 0 siblings, 1 reply; 296+ messages in thread From: Stephane Richard @ 2004-01-25 13:47 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 3241 bytes --] What's the URL for Ada-comment? -- St�phane Richard "Ada World" Webmaster http://www.adaworld.com "Randy Brukardt" <randy@rrsoftware.com> wrote in message news:10160jcm6ma1acf@corp.supernews.com... > "Marin David Condic" <nobody@noplace.com> wrote in message > news:401272E3.4040506@noplace.com... > ... > > Oh sure. They are better than a sharp stick in the eye and if you have > > to control representation, they're an elegant solution. But they are > > still "Butt Ugly" in the sense that the instant you use one, you can't > > promise that the code will work *anywhere* except on the one > > compiler/target where you built it. > > There is hardly any (useful) code that will work *anywhere*. Most existing > free Ada code won't run on Janus/Ada out of the box because Integer is > 16-bit -- and thus a lot of operations overflow. (Of course, there's no > problem with proper type declarations, but those are rare.) And a lot of > code is dependent in some way on the target - for GUI or output devices or > whatever. Certainly adding a rep. clause has little effect on that. > Especially if your world view pretty much starts and ends with PC hardware > (as mine does practically). > > We build Claw from the ground up with the intent of making it portable to > every Windows compiler -- yet there a quite a few differences that we have > to deal with. So rep. clauses don't bother me; it is extremely rare that > they would make code less portable than it already is. > > > As for submitting something to the ARG? I'll leave that to the language > > lawyers. They'll come up with far better proposals than I could ever > > write - so long as they think the idea might be a good one. > > The language lawyers are unlikely to even pay any attention to it unless you > submit a worked out change request. We have enough such requests that we > certainly aren't looking for more! > > I view this is list pretty much as what Robert Dewar called a "chat list" - > a place where people gripe a lot, turn molehills into mountains (and vice > versa), and you can't gauge much of anything by the conversations here. I > read this list mainly as part of my work for one of my other hats (webmaster > at adaic.org) -- I'm trolling for newsworthy items. There have been > occassional ideas where I got excited enough to propose something to the ARG > ("private with" is the one that comes to mind), but these days I feel > swamped enough that it would have to be a stupendous idea before I'd make > more work for myself. > > So, if you want something done, you need to take action to make a proposal > on Ada-Comment. It certainly doesn't need to be perfect - and even if it is, > the ARG would change it all around before standardizing it - but if no one > asks, it's very unlikely that the topic would even come up. Griping here may > feel good, but it has virtually no impact on the future of Ada. > > Randy. > > > > I'm just the > > end-user of Ada - a customer - expressing what he thinks would make the > > language more usable on a day-to-day level. We're a dwindling herd, so > > maybe those opinions ought to get some attention by the people who make > > and sell Ada. Hope springs eternal! :-) > > > ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-25 13:47 ` Stephane Richard @ 2004-01-26 19:19 ` Randy Brukardt 0 siblings, 0 replies; 296+ messages in thread From: Randy Brukardt @ 2004-01-26 19:19 UTC (permalink / raw) "Stephane Richard" <stephane.richard@verizon.net> wrote in message news:XNPQb.5318$Ig2.1236@nwrdny02.gnilink.net... > What's the URL for Ada-comment? There is a page describing access to Ada-Comment at: http://www.adaic.com/standards/articles/comment.html Randy. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-23 17:35 ` Warren W. Gay VE3WWG 2004-01-24 1:50 ` Marin David Condic @ 2004-01-24 6:08 ` Robert I. Eachus 1 sibling, 0 replies; 296+ messages in thread From: Robert I. Eachus @ 2004-01-24 6:08 UTC (permalink / raw) Warren W. Gay VE3WWG wrote: > Tell me, how do you solve the situation where API call to your > OS requires 3 parameters on one platform, and 2 on another? No > if statement can solve that for you. Of course it can, see above. I sometimes feel dirty having two Ada templates bound (by the linker) to the same C function, and depending on configuration constants to insure that I make call with the correct parameters for this environment. But I do it. -- Robert I. Eachus "The war on terror is a different kind of war, waged capture by capture, cell by cell, and victory by victory. Our security is assured by our perseverance and by our sure belief in the success of liberty." -- George W. Bush ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-22 15:03 ` Georg Bauhaus 2004-01-22 17:33 ` Warren W. Gay VE3WWG @ 2004-01-23 13:11 ` Marin David Condic 1 sibling, 0 replies; 296+ messages in thread From: Marin David Condic @ 2004-01-23 13:11 UTC (permalink / raw) I agree that if you can isolate something down in a low-level "System Dependency" package and swap those out easily, that you have *an* answer to some (if not all) problems. I've done this thousands of times. I've described cases elsewhere in this thread that *must* be dealt with at compile time (either by having separate configuration dependent units and some kind of conditional build tools or by having conditional compilation.) I'll bet you've even encountered things like a given declaration that works fine on one compiler but doesn't work on another or a statement that is legal and compiles for one compiler but is illegal for another. There are all sorts of allowed compiler differences - without even bringing up the subject of trying to get around compiler bugs. So if there's issues that have to be resolved at compile time and I can't guarantee that there is some external configuration management and/or build tools available to make maintaining separate units possible (if not always desirable) then I want some kind of conditional compilation to help me maintain a single body of code that works for more than one configuration. MDC Georg Bauhaus wrote: > What kind of difficulties do you see that could be better solved > by a preprocessor? (Things supported in GNAT but not ObjectAda or vice > versa? Dependence on pragmata?) > > I have code that is compiled by OA 722, by GCC 34, but not by GNAT 3.15p. > Ada source text is chopped where necessary using make. > (Operating) System specific routines are are assembled into a > package hierarchy (which I naively had top-level-named "System" (and > that triggers a bug box in GCC 34 after looping (the maintainers > say that, obviously, a library unit should not be modified...))) > Then a branch renames package Systems.Windows, another renames > package Systems.UNIX (or similarly). > > The problem that leads GNAT 3.15p to reject another unit is > apparently a bug in GNAT 3.15p that has been fixed in GCC 34. > I like this better than having to construct sources around a > compiler bug/limitation using hopefully temporary preprocessor #ifs. > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor 2004-01-22 13:19 ` Standard Ada Preprocessor Georg Bauhaus 2004-01-22 13:49 ` Marin David Condic @ 2004-01-22 14:12 ` Dmitry A. Kazakov 1 sibling, 0 replies; 296+ messages in thread From: Dmitry A. Kazakov @ 2004-01-22 14:12 UTC (permalink / raw) On Thu, 22 Jan 2004 13:19:08 +0000 (UTC), Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote: >Robert I. Eachus <rieachus@comcast.net> wrote: > >: E:\Ada\Test>system_names >: system_names >: The Available System Names are: SYSTEM_NAME_GNAT. >: >: Current System.System_Name is: SYSTEM_NAME_GNAT. >: >: Is there any compiler that produces a useful output? > >ObjectAda: > The Available System Names are: S370, I80X86, I80386, MC680X0, >VAX, TRANSPUTER, Should that mean they have a compiler for Inmos T805? I am impressed! > RS_6000, MIPS, HP9000_PA_RISC, HP9000_300, SPARC. > > Current System.System_Name is: I80386. -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 296+ messages in thread
[parent not found: <ldlq00hmnm7ofaqem3kkrt7qhf6o7kjfmj@4ax.com>]
* Re: why ada is so unpopular ? [not found] ` <ldlq00hmnm7ofaqem3kkrt7qhf6o7kjfmj@4ax.com> @ 2004-01-21 12:20 ` Marin David Condic 0 siblings, 0 replies; 296+ messages in thread From: Marin David Condic @ 2004-01-21 12:20 UTC (permalink / raw) I'm aware of who takes care of Java's library and the differences between Java and Ada with respect to reference implementation versus standards. The point is that if Java can manage to have a library and a GUI that is at least mostly portable (via reference implementation) then why can't Ada? Its proven to be a popular route and one that can be handled well enough to keep the user community happy. It adds leverage to development and makes Java a good choice for lots of apps. Is Ada going to sit around and say "Sure it could be useful to you but I won't do it because it violates some intellectual purism I have in mind..."? That just makes language choice really simple: use Java. ;-) MDC Dennis Lee Bieber wrote: > > Most likely, SUN. Java is, essentially, owned by one company. > THEY define it, and they release the reference implementation. What Sun > releases, in effect, defines the "standard". > > Ada, OTOH, is not defined by implementations -- the converse in > fact. The formal standard document defines the language, implementations > are expected to conform to that standard. When Ada was first defined, > one of the requirements of the language was that there be no supersets > or subsets of the language. Any differences from the standard meant that > the result language could NOT be called Ada -- in those days, if anyone > could be said to own Ada, it was the US DoD <G>. > > The other item is that Java's GUI is defined at a high-level, > and relies on low-level /OS specific/ code in the JVM. There is no such > beast in Ada. Any graphical library would have to be built in versions > for each OS. > > -- > > ============================================================== < > > wlfraed@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG < > > wulfraed@dm.net | Bestiaria Support Staff < > > ============================================================== < > > Home Page: <http://www.dm.net/~wulfraed/> < > > Overflow Page: <http://wlfraed.home.netcom.com/> < -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-19 12:59 ` Marin David Condic 2004-01-19 13:06 ` Preben Randhol @ 2004-01-19 13:09 ` Jeff C, 2004-01-19 23:03 ` Robert I. Eachus 1 sibling, 1 reply; 296+ messages in thread From: Jeff C, @ 2004-01-19 13:09 UTC (permalink / raw) "Marin David Condic" <nobody@noplace.com> wrote in message news:400BD4B5.6000307@noplace.com... > I don't know about the Gtk license itself or why GtkAda would have to > modify it slightly to enable the writing of proprietary software. What I > gathered by looking at the GtkAda license at least was that one could > develop an entirely proprietary app that made the Gtk calls through the > GtkAda binding. If one was doing a Gtk based interface, GtkAda seems > like the only logical choice (unless one needs Gtk capabilities that > aren't supported in GtkAda - a problem that all such bindings have and > an argument as to why Ada ought to have its own GUI.) > > It seems the best choice for a semi-portable interface if that is the > requirement. GPL "infection" does not seem to be an issue AFAICS. > > MDC > > Preben Randhol wrote: > > > > This package is distributed under the GPL license, slightly modified so > > that you can create proprietary software with this toolkit. The license > > is actually the same as the GNAT library itself. You should also read > > the Gtk license itself if you intend to do proprietary software based on > > gtk and GtkAda. > > > > > The "read the license part" is just a warning that this software (like almost all software) is covered by A license so make sure you understand the terms before development. The reason that the GNAT libraries and GtkAda use a modified GPL instead of an LGPL is that it is difficult (if not impossible) to comply with the terms of the LGPL in Ada (and in many cases C++) with proprietary distribution. WARNING. NON LAWYER APPROXIMATION OF TRUTH TO FOLLOW The LGPL requires that you distribute source with your execuables or that you distribute your execuables in such a way that the components that are LGPL can be updated by the end users (e.g. dynamically link to the LGPL library or provide .o files for all the proprietary stuff)..This woulld in theory allow an end user to fix a bug in the LGPL component (or get a bug fix link library) and "update" the program. The problem in Ada (and actually in other languages) is that there are pieces of code that at hard to do this with. If you have and LGPL generic it is essentially impossible with GNAT to have that be an LGPL component since the generic expantion happens at compile time. Something like this is also true of C++ and to some exent C header files. So the GMGPL is actually a slightly lesser (in RMS speak) language than the LGPL (meaning that it does not require the "field upgrade" capability of the LGPL. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-19 13:09 ` Jeff C, @ 2004-01-19 23:03 ` Robert I. Eachus 2004-01-20 1:10 ` cl1 0 siblings, 1 reply; 296+ messages in thread From: Robert I. Eachus @ 2004-01-19 23:03 UTC (permalink / raw) Jeff C, wrote: > So the GMGPL is actually a slightly lesser (in RMS speak) language than the > LGPL (meaning that it does not require the "field upgrade" capability of the LGPL. I am not picking on Jeff, who does a good job of describing why GTK+ uses LGPL and GtkAda uses GMGPL. I just want to say that the consensus is that GtkAda can be used without any "Gnu contamination" of your application. You can release such a program as proprietary or if you prefer copylefted or into the public domain. All you really need to know is that the respective developers got their licensing right so that you don't need to worry. As to GtkAda, it seems to be the consensus Ada graphics library right now. It would be nice if someone would update it, but probably the best way to describe the situation is that it is much better than "good enough" so no one currently seems to feel a need to do better. -- Robert I. Eachus "The war on terror is a different kind of war, waged capture by capture, cell by cell, and victory by victory. Our security is assured by our perseverance and by our sure belief in the success of liberty." -- George W. Bush ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-19 23:03 ` Robert I. Eachus @ 2004-01-20 1:10 ` cl1 2004-01-20 5:34 ` Robert I. Eachus 0 siblings, 1 reply; 296+ messages in thread From: cl1 @ 2004-01-20 1:10 UTC (permalink / raw) "Robert I. Eachus" <rieachus@comcast.net> wrote in message news:_NedndNu6J_W_5Hd4p2dnA@comcast.com... > Jeff C, wrote: > > > So the GMGPL is actually a slightly lesser (in RMS speak) language than the > > LGPL (meaning that it does not require the "field upgrade" capability of the LGPL. > > I am not picking on Jeff, who does a good job of describing why GTK+ > uses LGPL and GtkAda uses GMGPL. I just want to say that the consensus > is that GtkAda can be used without any "Gnu contamination" of your > application. You can release such a program as proprietary or if you > prefer copylefted or into the public domain. All you really need to > know is that the respective developers got their licensing right so that > you don't need to worry. > > As to GtkAda, it seems to be the consensus Ada graphics library right > now. It would be nice if someone would update it, but probably the best > way to describe the situation is that it is much better than "good > enough" so no one currently seems to feel a need to do better. Last i checked gtkada was current with gtk+ http://libre.act-europe.fr/GtkAda/ and it also has some stuff that gtk+ doesn't have(not that i have used that stuff) > > -- > Robert I. Eachus > > "The war on terror is a different kind of war, waged capture by capture, > cell by cell, and victory by victory. Our security is assured by our > perseverance and by our sure belief in the success of liberty." -- > George W. Bush > ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-20 1:10 ` cl1 @ 2004-01-20 5:34 ` Robert I. Eachus 2004-01-20 7:37 ` Preben Randhol 0 siblings, 1 reply; 296+ messages in thread From: Robert I. Eachus @ 2004-01-20 5:34 UTC (permalink / raw) cl1 wrote: > Last i checked gtkada was current with gtk+ > http://libre.act-europe.fr/GtkAda/ > and it also has some stuff that gtk+ doesn't have(not that i have used that > stuff) Shrug. I would like it if GtkAda had a more Ada-like binding. But as I said it is more than good enough so other things are higher on my priority list. -- Robert I. Eachus "The war on terror is a different kind of war, waged capture by capture, cell by cell, and victory by victory. Our security is assured by our perseverance and by our sure belief in the success of liberty." -- George W. Bush ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-20 5:34 ` Robert I. Eachus @ 2004-01-20 7:37 ` Preben Randhol 2004-01-20 16:41 ` Robert I. Eachus 2004-01-20 23:59 ` Stephen Leake 0 siblings, 2 replies; 296+ messages in thread From: Preben Randhol @ 2004-01-20 7:37 UTC (permalink / raw) On 2004-01-20, Robert I. Eachus <rieachus@comcast.net> wrote: > > Shrug. I would like it if GtkAda had a more Ada-like binding. But as I > said it is more than good enough so other things are higher on my > priority list. Please descibe what you mean. -- "Saving keystrokes is the job of the text editor, not the programming language." ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-20 7:37 ` Preben Randhol @ 2004-01-20 16:41 ` Robert I. Eachus 2004-01-20 23:59 ` Stephen Leake 1 sibling, 0 replies; 296+ messages in thread From: Robert I. Eachus @ 2004-01-20 16:41 UTC (permalink / raw) Preben Randhol wrote: > On 2004-01-20, Robert I. Eachus <rieachus@comcast.net> wrote: > >>Shrug. I would like it if GtkAda had a more Ada-like binding. But as I >>said it is more than good enough so other things are higher on my >>priority list. > > > Please descibe what you mean. Exactly what I said. There are some areas where, when I use GtkAda, I think "It might be nice if..." Then when I think about it a bit more, I realize what a major undertaking it would take compared to the very minor benefit, and forget about it. I'd mention specific cases, but as I said, I can't even think of any that were worth remembering. ;-) Just in case anyone thinks I am 'damning with faint praise', there is a very good reason that GtkAda is currently the most used Ada graphics interface, and that is that it is by far the best. There are lots of other things where an investment of my time may make a difference, excuse me if I get back to them. Incidently when Ada0Y is finalized and compilers comform to it, I suspect that changing GtkAda to use interfaces and constructors in some areas will be well worth the effort. But that is probably a project for next year, or the year after. -- Robert I. Eachus "The war on terror is a different kind of war, waged capture by capture, cell by cell, and victory by victory. Our security is assured by our perseverance and by our sure belief in the success of liberty." -- George W. Bush ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-20 7:37 ` Preben Randhol 2004-01-20 16:41 ` Robert I. Eachus @ 2004-01-20 23:59 ` Stephen Leake 2004-01-21 10:29 ` Preben Randhol 1 sibling, 1 reply; 296+ messages in thread From: Stephen Leake @ 2004-01-20 23:59 UTC (permalink / raw) To: comp.lang.ada Preben Randhol <randhol+valid_for_reply_from_news@pvv.org> writes: > On 2004-01-20, Robert I. Eachus <rieachus@comcast.net> wrote: > > > > Shrug. I would like it if GtkAda had a more Ada-like binding. But as I > > said it is more than good enough so other things are higher on my > > priority list. > > Please descibe what you mean. I'll jump in here :) GtkAda currently follows Gtk+ in using strings to name events; the Ada way would be to use enumerals, named constants, or function names. GtkAda also allows the user to easily bind an incorrect handler to an event ("incorrect" here meaning "has the wrong parameter/result profile"). The error is reported at run-time, but the Ada way is to catch this error at compile time. In my GtkAda projects, I'm attempting to fix both issues, by providing child packages for the current GtkAda packages that present the "Ada way". If it works out, I'll propose it as a change to be incorporated (some things would benefit from being primitive operations, which must be in the same package as the type). -- -- Stephe ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-20 23:59 ` Stephen Leake @ 2004-01-21 10:29 ` Preben Randhol 0 siblings, 0 replies; 296+ messages in thread From: Preben Randhol @ 2004-01-21 10:29 UTC (permalink / raw) On 2004-01-20, Stephen Leake <Stephe.Leake@nasa.gov> wrote: > GtkAda also allows the user to easily bind an incorrect handler to an > event ("incorrect" here meaning "has the wrong parameter/result > profile"). The error is reported at run-time, but the Ada way is to > catch this error at compile time. How do you bind your handles? If I remember correctly there are two ways, the C way and the Ada way already. At least I use marshals which will make the compiler catch errors at compile time. Can you give a source example? -- "Saving keystrokes is the job of the text editor, not the programming language." ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-17 21:02 ` Szymon Guz 2004-01-17 22:36 ` Adrian Knoth @ 2004-01-17 23:01 ` Marin David Condic 2004-01-18 0:30 ` Hyman Rosen 2004-01-19 23:46 ` chris 2 siblings, 1 reply; 296+ messages in thread From: Marin David Condic @ 2004-01-17 23:01 UTC (permalink / raw) Its *always* worth learning a programming language because it can show you the strengths and weaknesses of other languages & improves your programming skills in general. Learning Ada might teach you a thing or two about what is good/bad about something like C++ - whereas ignorance of Ada and knowledge only of C++ (for example) tends to leave you blind about how things might otherwise be done. As for earning anything from the experience, you might consider this: If you decide to write a *useful* program, there are ways that the program may generate some money for you. Nobody will care much that it was written in Ada or C++ or Java. Come up with a good idea and get a baseline product built and see if you can find some users. Make money by selling upgrades or by licensing the technology or any number of other business models. As for simple employment, while a company may be looking for a dozen years of experience in Programming Language X - showing them on your resume that you know a *variety* of languages tends to indicate that you are a quick learner and adaptable as well as well educated. Any experience cannot possibly hurt you. Learning some Ada is an excellent way of discovering techniques and capabilities you aren't likely to see duplicated in other languages. Szymon Guz wrote: > > I see. But I'd like to know if it is worth learning. I'd like to write a > program and maybe in future earn on that and I still don't know what to > choose ada or C++. > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-17 23:01 ` Marin David Condic @ 2004-01-18 0:30 ` Hyman Rosen 2004-01-18 2:06 ` cl1 2004-01-18 14:34 ` Marin David Condic 0 siblings, 2 replies; 296+ messages in thread From: Hyman Rosen @ 2004-01-18 0:30 UTC (permalink / raw) Marin David Condic wrote: > showing them on your resume that you know a *variety* of languages > tends to indicate that you are a quick learner and adaptable as well > as well educated. Any experience cannot possibly hurt you. I interviewed a programming candidate for my compnay not long ago who had C++ and Ada on his resume. I was looking forward to a nice chat on comparing the two languages. Unfortunately, it turned out that the candidate knew nothing about either one. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-18 0:30 ` Hyman Rosen @ 2004-01-18 2:06 ` cl1 2004-01-18 3:12 ` Hyman Rosen 2004-01-18 14:34 ` Marin David Condic 1 sibling, 1 reply; 296+ messages in thread From: cl1 @ 2004-01-18 2:06 UTC (permalink / raw) "Hyman Rosen" <hyrosen@mail.com> wrote in message news:WskOb.68$Wm4.21@nwrdny01.gnilink.net... > Marin David Condic wrote: > > showing them on your resume that you know a *variety* of languages > > tends to indicate that you are a quick learner and adaptable as well > > as well educated. Any experience cannot possibly hurt you. > > I interviewed a programming candidate for my compnay not long ago who > had C++ and Ada on his resume. I was looking forward to a nice chat on > comparing the two languages. Unfortunately, it turned out that the > candidate knew nothing about either one. and this is why it took me almost 2 years to find a job ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-18 2:06 ` cl1 @ 2004-01-18 3:12 ` Hyman Rosen 2004-01-18 3:28 ` cl1 0 siblings, 1 reply; 296+ messages in thread From: Hyman Rosen @ 2004-01-18 3:12 UTC (permalink / raw) cl1 wrote: > and this is why it took me almost 2 years to find a job You mean that you too put things on your resume that you didn't know anything about? ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-18 3:12 ` Hyman Rosen @ 2004-01-18 3:28 ` cl1 0 siblings, 0 replies; 296+ messages in thread From: cl1 @ 2004-01-18 3:28 UTC (permalink / raw) "Hyman Rosen" <hyrosen@mail.com> wrote in message news:MQmOb.124$Wm4.66@nwrdny01.gnilink.net... > cl1 wrote: > > and this is why it took me almost 2 years to find a job > > You mean that you too put things on your resume that you > didn't know anything about? god no! but there are so many people who do it's been like playing the lottery to get my resume in front of companies to get an interview. I no longer have this problem as of last friday. (yippie) i start my new job as and ASP/VB developer on monday... ... i feel like such a whore. but at least i'm writing code :) someday i hope to write really good stuff with ada on a linux platform as soon as i can find someone to hire me. but i think it would help for me to have more than a few months of learning experiance with ada before i attempt that endevor. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-18 0:30 ` Hyman Rosen 2004-01-18 2:06 ` cl1 @ 2004-01-18 14:34 ` Marin David Condic 1 sibling, 0 replies; 296+ messages in thread From: Marin David Condic @ 2004-01-18 14:34 UTC (permalink / raw) Resumes are a little like "Marketing" (in the bad sense of the word). You often have to divide everything by 10. Perhaps this is why companies seem to be paying very little attention to them these days. I know when my boss and I are discussing personnel, his push is always to find someone that someone else in the organization can give a good recommendation for or otherwise get them vetted by a reliable source. Blind resumes may or may not tell you much about the candidate. Even if the person didn't exagerate his skills too badly, it doesn't tell you much about work habbits and interpersonal skills. I don't care how many languages a guy has or how much experience he can show if he is incapable of getting a job done on time or can't get along with his co-workers & customers. You sometimes can't tell that until its too late. ;-) MDC Hyman Rosen wrote: > I interviewed a programming candidate for my compnay not long ago who > had C++ and Ada on his resume. I was looking forward to a nice chat on > comparing the two languages. Unfortunately, it turned out that the > candidate knew nothing about either one. -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-17 21:02 ` Szymon Guz 2004-01-17 22:36 ` Adrian Knoth 2004-01-17 23:01 ` Marin David Condic @ 2004-01-19 23:46 ` chris 2 siblings, 0 replies; 296+ messages in thread From: chris @ 2004-01-19 23:46 UTC (permalink / raw) Szymon Guz wrote: > Dmytry Lavrov wrote: > >> Military uses. It's answer to question why unpopular. > > I see. But I'd like to know if it is worth learning. I'd like to write a > program and maybe in future earn on that and I still don't know what to > choose ada or C++. I've tried Gtkmm and GtkAda. Gtkmm was easier to use to begin with, but I ran into a problem with the model I was building because I didn't understand C++ too well (templates specifically). In Ada it was easier to build the model because I know the language fairly well, but the view in GtkAda was a little more difficult (or in the way... don't like generically instantiated handlers). It's a trade off. I went for Ada, but only because C++ got on my nerves and I found the Oz documentation too academic... there are enough academics messing with my brain at the minute. ;) Personally I'd try both and see what fits... no wait! I did ;) Chris ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-17 11:15 why ada is so unpopular ? Szymon Guz 2004-01-17 13:53 ` Martin Dowie 2004-01-17 14:27 ` Dmytry Lavrov @ 2004-01-18 18:41 ` Jano 2004-01-21 2:01 ` Luke A. Guest 3 siblings, 0 replies; 296+ messages in thread From: Jano @ 2004-01-18 18:41 UTC (permalink / raw) Szymon Guz dice... > Hi, > I'd like to know how ada is popular ? And i which countries. I'm asking > because I live in Poland and here I couldn't find any firm that use it. It's the language of choice to teach several subjects in Zaragoza (Spain) college, computer engineering. I couldn't say about other colleges in Spain. Introduction to programming. Data structures and algorithms. Concurrent programming. Real time programming. Embedded systems. I may be missing something. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-17 11:15 why ada is so unpopular ? Szymon Guz ` (2 preceding siblings ...) 2004-01-18 18:41 ` Jano @ 2004-01-21 2:01 ` Luke A. Guest 2004-01-21 14:23 ` Hyman Rosen ` (2 more replies) 3 siblings, 3 replies; 296+ messages in thread From: Luke A. Guest @ 2004-01-21 2:01 UTC (permalink / raw) On Sat, 17 Jan 2004 12:15:35 +0100, Szymon Guz wrote: > Hi, > I'd like to know how ada is popular ? And i which countries. I'm asking > because I live in Poland and here I couldn't find any firm that use it. Well, I wouldn't say that Ada is unpopular. There are other factors to take into consideration: 1) Management don't know about Ada. 2) Management tend to want the programmers to use languages that are the current fad, i.e. C/C++. 3) I had to learn Ada at uni and I had no idea about before then. I actually love the language, It has so many features not found anywhere else that are (IMO) necessary for development. 4) Programmers learn what is required of them. 5) The DoD (supposedly) dropped all support for Ada and this then looks (to the outsider) that the language is dead. I think that if enough programmers get to know Ada, I think that better programming standards will emerge, but it's up to those who know it and those who can tell others about it to spread the word and make sure that others start to use it. Luke. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-21 2:01 ` Luke A. Guest @ 2004-01-21 14:23 ` Hyman Rosen 2004-01-21 14:31 ` Ludovic Brenta 2004-01-21 18:31 ` chris 2 siblings, 0 replies; 296+ messages in thread From: Hyman Rosen @ 2004-01-21 14:23 UTC (permalink / raw) Luke A. Guest wrote: > 2) Management tend to want the programmers to use > languages that are the current fad, i.e. C/C++. And they all communicate in that fad language English instead of using NewSpeak. Despite the fact that in NewSpeak your sentences are clear and unambiguous, people are still required to use languages which fail to accurately deliver to the listener the intent of the speaker. Remember, "You can't put too much water into a nuclear reactor!" ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-21 2:01 ` Luke A. Guest 2004-01-21 14:23 ` Hyman Rosen @ 2004-01-21 14:31 ` Ludovic Brenta 2004-01-21 15:15 ` Hyman Rosen 2004-01-21 18:31 ` chris 2 siblings, 1 reply; 296+ messages in thread From: Ludovic Brenta @ 2004-01-21 14:31 UTC (permalink / raw) "Luke A. Guest" <laguest@n_o_p_o_r_k_a_n_d_h_a_m.abyss2.demon.co.uk> writes: > On Sat, 17 Jan 2004 12:15:35 +0100, Szymon Guz wrote: > > > Hi, > > I'd like to know how ada is popular ? And i which countries. I'm asking > > because I live in Poland and here I couldn't find any firm that use it. > > Well, I wouldn't say that Ada is unpopular. There are other factors to > take into consideration: > > 1) Management don't know about Ada. > 2) Management tend to want the programmers to use languages that are the > current fad, i.e. C/C++. In my view their attitude is more cynical than that. The reason why they want programmers to use "mainstream" languages is so they can replace programmers easily without retraining. They want programmers to be disposable and interchangeable just like a piece of commodity hardware. They don't mind that their language of choice has an adverse effect on the quality of software, because they're interested in selling bug fixes, upgrades and maintenance. They also don't mind that disposable programmers will produce disposable software. They're in fact quite happy about it. I don't like to sound so pessimistic, but I've actually gotten a manager to admit openly to all of the above. Now that was at a very large company that makes enterprise data storage products. I was not a nuclear, aerospace, or rail company. I hope there are still companies that try to produce quality software. > 3) I had to learn Ada at uni and I had no idea about before then. I > actually love the language, It has so many features not found anywhere > else that are (IMO) necessary for development. Yes. Furthermore, I have found that people who learn Ada often change their attitude regarding software development. They no longer want to develop junk, disposable software; instead they want to develop quality software that lasts. (yes, there are many people who actually like developing disposable software; those are the ones who promote and improve on scripting languages like Perl or Python to a point where they change from being prototyping languages to being implementation languages). > 4) Programmers learn what is required of them. > 5) The DoD (supposedly) dropped all support for Ada and this then looks > (to the outsider) that the language is dead. > > I think that if enough programmers get to know Ada, I think that better > programming standards will emerge, but it's up to those who know it > and those who can tell others about it to spread the word and make sure > that others start to use it. > > Luke. I would like to see more free software developed in Ada. The free software world does not try to produce disposable software, and therefore would benefit from a language that helps improve quality. Perhaps, that way, Ada will become a little bit more mainstream. -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-21 14:31 ` Ludovic Brenta @ 2004-01-21 15:15 ` Hyman Rosen 2004-01-21 18:40 ` Robert A Duff 0 siblings, 1 reply; 296+ messages in thread From: Hyman Rosen @ 2004-01-21 15:15 UTC (permalink / raw) Ludovic Brenta wrote: > I've actually gotten a manager to admit openly to all of the above. I'll bet he was just tired of your badgering him about Ada, and told you that to get you to go away and leave him alone. I do that with my three-year old sometimes too. ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-21 15:15 ` Hyman Rosen @ 2004-01-21 18:40 ` Robert A Duff 0 siblings, 0 replies; 296+ messages in thread From: Robert A Duff @ 2004-01-21 18:40 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> writes: > I'll bet he was just tired of your badgering him about Ada, > and told you that to get you to go away and leave him alone. > I do that with my three-year old sometimes too. I'm glad to know your three-year-old badgers you about Ada. ;-) Good taste. - Bob ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-21 2:01 ` Luke A. Guest 2004-01-21 14:23 ` Hyman Rosen 2004-01-21 14:31 ` Ludovic Brenta @ 2004-01-21 18:31 ` chris 2004-01-22 13:11 ` Marin David Condic 2 siblings, 1 reply; 296+ messages in thread From: chris @ 2004-01-21 18:31 UTC (permalink / raw) Luke A. Guest wrote: > > Well, I wouldn't say that Ada is unpopular. There are other factors to > take into consideration: > > 1) Management don't know about Ada. If they knew, would they care? In the desktop, I don't think so. Ludovic is right in the disposability of programmers. Especially today. Do you know how many software developers are out in just the UK there looking for jobs (like me)? Loads! The more experienced SEs might even have to take a pay drop (in terms of what they're worth) just to get a job. There is not as much money as there used to be out there and people aren't going to take risks moving over to other technologies if the technologies they have do the job and there's a steady stream of programmers conversant in those technologies available. Unis teach graduates the hot technology and the cycle repeats! > 2) Management tend to want the programmers to use languages that are the > current fad, i.e. C/C++. > 3) I had to learn Ada at uni and I had no idea about before then. I > actually love the language, It has so many features not found anywhere > else that are (IMO) necessary for development. I used to think so, but have found similar features in other languages expressed more powerfully and also with the benefit of run time portability and lots of tools targetting the desktop developer. Ocaml for instance library support on the desktop exceeds Ada's with the exception of GUI toolkits (there are only a couple of these), despite being a functionally imperative language from the research community (or maybe it doesn't, but appears so since there is a central repository full of current links & sw). I think the perception from uni is that Ada is a good language, but why spend time making data structure libraries or downloading them when C++, C#, Delphi (iirc) and Java have them out of the box. Data structures will be remedied but what about XML? It has no place in the standard but what if compilers came with an XML parser, a gui toolkit and whatever else need be. Note it doesn't take ACT (specifically) to do this. Someone could package it up for people and let them download it. Some Ada compiler companies might do this already but are they expensive? > I think that if enough programmers get to know Ada, I think that better > programming standards will emerge, but it's up to those who know it > and those who can tell others about it to spread the word and make sure > that others start to use it. It's a nice language yes, but it's one of *many* such languages. Chris ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-21 18:31 ` chris @ 2004-01-22 13:11 ` Marin David Condic 2004-01-22 23:33 ` Stephen Leake 0 siblings, 1 reply; 296+ messages in thread From: Marin David Condic @ 2004-01-22 13:11 UTC (permalink / raw) Its not a totally illigitimate concern. Programmers come and go. Its expensive and risky to use *anything* outside of the mainstream. Hardware is a good example. Would you rather support a current version of an IBM PC or an old DEC Alpha/VMS system? The old system is *really* costly to maintain because nobody is mass producing parts for it and not as many programmers know how to use it, etc. All that adds cost to a project. The technical superiority of an Alpha over a PC is irrelevant. You'd be building your system on top of an antique and the first breakdown you have is going to kill you. As for "disposable" programmers - would you be willing to sign a long-term contract promising never to leave the company you are at? Probably not. Hence a manager needs to consider the possibility that you might quit and what does he do in that case? He would have to hire and train someone else - costly and time consuming. So using a language that is widely known and platforms that are widely used, he minimizes risks and costs. That's what managers are *supposed* to do. Rather than complain about "stupid management" we ought to be helping them solve their problems. If Ada had much more capability and widespread use, then the manager has substantially less risk in going that route. Give the poor guy something he can *trust* will be around, supported, low cost and high leverage and you may discover he starts making decisions more to your liking. MDC chris wrote: > > If they knew, would they care? In the desktop, I don't think so. > Ludovic is right in the disposability of programmers. Especially today. > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-22 13:11 ` Marin David Condic @ 2004-01-22 23:33 ` Stephen Leake 2004-01-23 13:25 ` Marin David Condic 0 siblings, 1 reply; 296+ messages in thread From: Stephen Leake @ 2004-01-22 23:33 UTC (permalink / raw) To: comp.lang.ada Marin David Condic <nobody@noplace.com> writes: > Rather than complain about "stupid management" we ought to be helping > them solve their problems. If Ada had much more capability and > widespread use, then the manager has substantially less risk in going > that route. Give the poor guy something he can *trust* will be around, > supported, low cost and high leverage and you may discover he starts > making decisions more to your liking. In my field, the time it takes to learn Ada is quite small compared to the time it takes to learn how to write useful programs. The later involves data structures, real-time scheduling, the physics of actuators and sensors, and control algorithms. None of those things are "main stream" :). And yet the managers still say "we can't teach people new programming languages". -- -- Stephe ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: why ada is so unpopular ? 2004-01-22 23:33 ` Stephen Leake @ 2004-01-23 13:25 ` Marin David Condic 0 siblings, 0 replies; 296+ messages in thread From: Marin David Condic @ 2004-01-23 13:25 UTC (permalink / raw) Been there. Done that. Got the T-Shirt. You're right that in lots of domains, it takes you more time to learn the domain than to learn the language. Managers love to hire guys who already have experience in the domain for exactly that reason. But that doesn't really address the issue that a manager has when choosing a language. Training people is *part* of the cost, but by no means all of it. If you're building things using sensors and actuators and control algorithms like I am, then you're probably talking about very long-lived systems that are extremely expensive to verify. Especially in some environment like that, a manager doesn't want to be sitting on top of a dead-end language. If it becomes mostly non-existant in ten years and his control has to live for another 30 years, he is most eggregiously sexually penetrated when he has to switch to something else in mid-project. I'll reiterate: Give the poor manager something he can have some confidence in and believe it will solve his problems and maybe he'll start making the decisions you want him to make. He lives or dies by things like cost, schedule, time-to-market, risk reduction, etc. Selecting some niche language with an uncertain future, a lack of industry support, a poverty of tools/libraries (compared to other choices) and a profound disinterest on the part of most of the available programmers out there just doesn't look like a career-enhancing move. Fix that and maybe he'll show more interest in the language. MDC Stephen Leake wrote: > > In my field, the time it takes to learn Ada is quite small compared to > the time it takes to learn how to write useful programs. The later > involves data structures, real-time scheduling, the physics of > actuators and sensors, and control algorithms. None of those things > are "main stream" :). > > And yet the managers still say "we can't teach people new programming > languages". > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) @ 2004-01-23 20:03 Leon Winslow 2004-01-24 2:00 ` Marin David Condic 0 siblings, 1 reply; 296+ messages in thread From: Leon Winslow @ 2004-01-23 20:03 UTC (permalink / raw) **** Post for FREE via your newsreader at post.usenet.com **** I'm interested in knowing why no one has mentioned that 40 years ago the COBAL language included a statement to specify the machine and/or operating system for the executable code. If you wanted the program to run on a UNIX box, you essentially entered UNIX at the head of the program; if you wanted it to run on a Windows box you entered Windows. The rest of the program remained the same. (Its been a long time since I used this feature so I don't remember the exact syntax. Maybe someone else knows?) Of course, very few compilers actually implemented more than one option. If you wanted a different one, you usually needed a different compiler. The important feature however is that the rest of the program was independent of the machine that would execute the program. If COBAL could implement this 40 years ago, why can't we try something similar? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= *** Usenet.com - The #1 Usenet Newsgroup Service on The Planet! *** http://www.usenet.com Unlimited Download - 19 Seperate Servers - 90,000 groups - Uncensored -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-23 20:03 Standard Ada Preprocessor (Was: why ada is so unpopular ?) Leon Winslow @ 2004-01-24 2:00 ` Marin David Condic 0 siblings, 0 replies; 296+ messages in thread From: Marin David Condic @ 2004-01-24 2:00 UTC (permalink / raw) Probably because it was widely ignored by implementers and hence pretty close to useless. In a perfect world, all compilers would recognize platform differences and correct for them so you had 100% portable code - but this is not likely to happen while I'm above ground. Its really pretty hopeless to expect that a compiler writer can forsee *all* platform differences and deal with them via some abstraction, so you have to leave it in the hands of the developer. Somehow, the developer needs to detect and code around such platform differences. MDC Leon Winslow wrote: > **** Post for FREE via your newsreader at post.usenet.com **** > > I'm interested in knowing why no one has mentioned that 40 years ago the > COBAL language included a statement to specify the machine and/or > operating system for the executable code. If you wanted the program to > run on a UNIX box, you essentially entered UNIX at the head of the > program; if you wanted it to run on a Windows box you entered Windows. > The rest of the program remained the same. (Its been a long time since > I used this feature so I don't remember the exact syntax. Maybe someone > else knows?) > > Of course, very few compilers actually implemented more than one > option. If you wanted a different one, you usually needed a different > compiler. > > The important feature however is that the rest of the program was > independent of the machine that would execute the program. If COBAL > could implement this 40 years ago, why can't we try something similar? > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > *** Usenet.com - The #1 Usenet Newsgroup Service on The Planet! *** > http://www.usenet.com > Unlimited Download - 19 Seperate Servers - 90,000 groups - Uncensored > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 296+ messages in thread
* RE: Standard Ada Preprocessor (Was: why ada is so unpopular ?) @ 2004-01-26 20:03 Lionel.DRAGHI 2004-01-26 23:10 ` Robert A Duff 0 siblings, 1 reply; 296+ messages in thread From: Lionel.DRAGHI @ 2004-01-26 20:03 UTC (permalink / raw) To: comp.lang.ada | -----Message d'origine----- | De: Warren W. Gay VE3WWG [mailto:warren@ve3wwg.tk] ... | >> | >>> C with preprocessor directives is also Maintenance Hell. | I don't see | >>> that it's a better Hell. | >> | >> Given that it should be optional, it would not be your problem ;-) | | I would tend to agree. There is no "pure" way to make non-trivial | code portable. | | If we go back to the "non-normalized database" metaphore, keeping | separate versions of code for purity sake (to avoid conditional | compilation), is like having to update a customer name in a | database in 12 different tables. This potentially leads to | leaving one instance of that name wrong, or left unchanged. A good design allows to separate common and customized code in a pretty sharp way. There is no free lunch, and you need some more code and design. Method template and Strategy patterns are useful here. It is possible (and not so hard) to get a software with no embedded dead code, and with almost no possible source confusion, that is, with the whole configuration defined in one source. Lets consider two OS interfaces (not compiled code) : ---------------------------------------------------------- package OS_Interface is procedure Open_File (Name ... ...); ... -- etc. private type Abstract_Interface is abstract ... procedure Open_File (Abstract_Interface ... Name ... ...) is abstract; ... procedure Register_As_Concrete (Abstract_Interface'class'Access...); -- used by child interfaces to register themself end OS_Interface; ---------------------------------------------------------- package body OS_Interface is Concrete : ... -- pointer to the concrete Interface, -- set by Register_As_Concrete procedure Open_File (Name ... ...) is begin Open_File (Concrete, Name ...); -- let's dispatch to the concrete -- Interface end Open_File; ... end OS_Interface; ---------------------------------------------------------- package OS_Interface.Windows is type Windows_Interface is new Abstract_Interface ... -- define abstract operations -- redefine some of the concrete operations. ... procedure Register; -- register this one as the concrete interface -- by calling Register_As_Concrete with -- a local dummy instance of Windows_Interface end OS_Interface.Windows; For the configuration, you need some separate configuration procedure : ---------------------------------------------------------- separate (Main) procedure Configure is begin OS_Interface.Windows.Register; end Configure; But this is the only compilation unit provided in several versions, the only one that you need to manage carefully in your configuration system. As for conditional compilation systems, some external configuration is pretty unavoidable. Note also that calls to (for example) a specific Linux thin binding will be hidden into the OS_Interface.Linux package : Register is the only operation in OS_Interface child specification, so if you don't "with" it within the Configure operation, this code is not included in the executable. Another advantage is that you don't touch common code when adding or modifying some specific implementation. You don't cause useless recompilations or regression testing. For user code, the whole stuff is hidden : it just call OS_Interface.Open_File (Name, ...); as usual. One drawback of this template respect to conditional compilation is an added indirection and dispatching hidden into OS_Interface body. But if someone care of performance at this point, he is in a desperate situation. Another drawback is the difficulty to compare implementations, but it's not that useful, neither that difficult to do with your favorite environment. -- Lionel Draghi ^ permalink raw reply [flat|nested] 296+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?) 2004-01-26 20:03 Lionel.DRAGHI @ 2004-01-26 23:10 ` Robert A Duff 0 siblings, 0 replies; 296+ messages in thread From: Robert A Duff @ 2004-01-26 23:10 UTC (permalink / raw) Lionel.DRAGHI@fr.thalesgroup.com writes: The approach you outlined is a good one, in many cases, but: > One drawback of this template respect to conditional compilation is an added > indirection and dispatching hidden into OS_Interface body. > But if someone care of performance at this point, he is in a desperate > situation. I have sometimes needed static constants that depend on the configuration, either for efficiency reasons, or so I could use them in places where Ada requires static expressions. - Bob ^ permalink raw reply [flat|nested] 296+ messages in thread
end of thread, other threads:[~2004-02-13 17:27 UTC | newest] Thread overview: 296+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-01-17 11:15 why ada is so unpopular ? Szymon Guz 2004-01-17 13:53 ` Martin Dowie 2004-01-17 14:27 ` Dmytry Lavrov 2004-01-17 21:02 ` Szymon Guz 2004-01-17 22:36 ` Adrian Knoth 2004-01-18 9:21 ` Szymon Guz 2004-01-18 12:18 ` Luke A. Guest 2004-01-18 13:09 ` Ronald Dauster 2004-01-18 12:59 ` Ronald Dauster 2004-01-18 13:25 ` Stephane Richard 2004-01-18 14:17 ` Szymon Guz 2004-01-18 14:42 ` Marin David Condic 2004-01-18 15:23 ` Szymon Guz 2004-01-18 17:53 ` Jeffrey Carter 2004-01-18 16:34 ` Preben Randhol 2004-01-19 12:59 ` Marin David Condic 2004-01-19 13:06 ` Preben Randhol 2004-01-19 13:28 ` Marin David Condic 2004-01-19 13:37 ` Preben Randhol 2004-01-20 12:38 ` Marin David Condic 2004-01-20 17:31 ` Standard Ada Preprocessor (Was: why ada is so unpopular ?) Warren W. Gay VE3WWG 2004-01-20 18:50 ` Standard Ada Preprocessor Georg Bauhaus 2004-01-26 4:00 ` Peter Richtmyer 2004-01-26 5:01 ` tmoran 2004-01-26 12:01 ` Marin David Condic 2004-02-01 15:09 ` Mark 2004-02-01 19:10 ` Frank J. Lhota 2004-02-02 16:48 ` Martin Krischik 2004-02-02 18:22 ` Frank J. Lhota 2004-01-21 12:39 ` Standard Ada Preprocessor (Was: why ada is so unpopular ?) Marin David Condic 2004-01-21 13:12 ` Standard Ada Preprocessor Georg Bauhaus 2004-01-22 0:05 ` Standard Ada Preprocessor (Was: why ada is so unpopular ?) Robert I. Eachus 2004-01-22 5:59 ` Randy Brukardt 2004-01-22 12:58 ` Marin David Condic 2004-01-22 17:25 ` Warren W. Gay VE3WWG 2004-01-23 12:24 ` Marin David Condic 2004-01-23 13:46 ` Dmitry A. Kazakov 2004-01-23 17:16 ` Warren W. Gay VE3WWG 2004-01-23 17:52 ` Jeffrey Carter 2004-01-23 21:57 ` Warren W. Gay VE3WWG 2004-01-24 0:52 ` Jeffrey Carter 2004-01-26 17:19 ` Warren W. Gay VE3WWG 2004-01-27 12:24 ` Marin David Condic 2004-01-27 19:03 ` Standard Ada Preprocessor Georg Bauhaus 2004-01-24 1:34 ` Standard Ada Preprocessor (Was: why ada is so unpopular ?) Marin David Condic 2004-01-26 17:27 ` Warren W. Gay VE3WWG 2004-01-27 12:30 ` Marin David Condic 2004-01-24 8:20 ` Pascal Obry 2004-01-26 17:29 ` Warren W. Gay VE3WWG 2004-01-23 17:56 ` Larry Hazel 2004-01-24 1:36 ` Marin David Condic 2004-01-23 22:14 ` Randy Brukardt 2004-01-23 22:42 ` tmoran 2004-01-26 17:50 ` Warren W. Gay VE3WWG 2004-01-26 18:54 ` Standard Ada Preprocessor Jeffrey Carter 2004-01-26 21:53 ` Warren W. Gay VE3WWG 2004-01-27 0:00 ` Robert I. Eachus 2004-01-27 17:30 ` Warren W. Gay VE3WWG 2004-01-27 20:55 ` Robert A Duff 2004-01-27 22:03 ` Robert I. Eachus 2004-01-28 12:28 ` Marin David Condic 2004-01-28 20:55 ` Simon Wright 2004-01-29 12:40 ` Marin David Condic 2004-01-29 18:08 ` Jeffrey Carter 2004-01-30 12:30 ` Marin David Condic 2004-01-29 20:45 ` Simon Wright 2004-01-29 23:12 ` Randy Brukardt 2004-01-30 13:09 ` Marin David Condic 2004-01-30 18:06 ` Jeffrey Carter 2004-01-31 8:11 ` Marin David Condic 2004-01-30 12:36 ` Marin David Condic 2004-01-30 16:52 ` Pascal Obry 2004-01-31 8:25 ` Marin David Condic 2004-01-27 21:04 ` Randy Brukardt 2004-01-28 12:42 ` Marin David Condic 2004-01-27 12:48 ` Standard Ada Preprocessor (Was: why ada is so unpopular ?) Marin David Condic 2004-01-26 9:34 ` Dmitry A. Kazakov 2004-01-26 19:23 ` Randy Brukardt 2004-01-23 2:47 ` Robert I. Eachus 2004-01-23 12:38 ` Marin David Condic 2004-01-24 5:23 ` Robert I. Eachus 2004-01-24 12:28 ` Marin David Condic 2004-01-24 15:32 ` Robert I. Eachus 2004-01-24 15:43 ` Marin David Condic 2004-01-25 4:24 ` Robert I. Eachus 2004-01-25 16:24 ` Marin David Condic 2004-01-29 11:17 ` Jacob Sparre Andersen 2004-01-29 12:52 ` Marin David Condic 2004-01-26 18:03 ` Warren W. Gay VE3WWG 2004-01-26 19:14 ` Standard Ada Preprocessor Jeffrey Carter 2004-01-26 22:04 ` Warren W. Gay VE3WWG 2004-01-27 1:00 ` Jeffrey Carter 2004-01-27 8:35 ` Ole-Hjalmar Kristensen 2004-01-27 11:09 ` Georg Bauhaus 2004-01-27 15:22 ` Ole-Hjalmar Kristensen 2004-01-27 15:54 ` Robert I. Eachus 2004-01-27 18:00 ` Warren W. Gay VE3WWG 2004-01-27 19:19 ` David Starner 2004-01-27 20:08 ` Ludovic Brenta 2004-01-27 20:19 ` Georg Bauhaus 2004-01-27 20:58 ` Randy Brukardt 2004-01-27 22:13 ` Simon Wright 2004-01-27 23:04 ` David Starner 2004-01-28 1:41 ` Jeffrey Carter 2004-01-28 2:26 ` Georg Bauhaus 2004-01-28 2:50 ` Stephen Leake 2004-01-28 3:21 ` Jeff C, 2004-01-28 3:57 ` David Starner 2004-01-29 3:03 ` Stephen Leake 2004-01-29 7:20 ` David Starner 2004-01-29 11:14 ` Georg Bauhaus 2004-01-29 18:56 ` David Starner 2004-01-29 19:41 ` Georg Bauhaus 2004-01-29 12:57 ` Marin David Condic 2004-01-29 13:51 ` Preben Randhol 2004-01-30 2:46 ` Robert I. Eachus 2004-01-28 20:34 ` Michael Bode 2004-01-29 3:06 ` Stephen Leake 2004-01-28 12:50 ` Marin David Condic 2004-01-27 20:44 ` Randy Brukardt 2004-01-27 22:15 ` Alexandre E. Kopilovitch 2004-01-29 17:31 ` Standard Ada Preprocessor (conclusions) Warren W. Gay VE3WWG 2004-01-29 19:44 ` Georg Bauhaus 2004-01-30 13:25 ` Marin David Condic 2004-01-30 13:29 ` Lutz Donnerhacke 2004-01-30 13:53 ` Marin David Condic 2004-01-30 14:14 ` Lutz Donnerhacke 2004-01-27 19:11 ` Standard Ada Preprocessor Jeffrey Carter 2004-01-27 21:48 ` Alexandre E. Kopilovitch 2004-01-28 16:26 ` Robert I. Eachus 2004-01-29 2:51 ` Alexandre E. Kopilovitch 2004-01-29 11:19 ` Georg Bauhaus 2004-01-29 22:02 ` Nature of XML (was: Re: Standard Ada Preprocessor) Alexandre E. Kopilovitch 2004-01-30 8:53 ` Preben Randhol 2004-01-30 17:35 ` Alexandre E. Kopilovitch 2004-01-30 19:13 ` Preben Randhol 2004-01-31 16:04 ` Alexandre E. Kopilovitch 2004-01-31 16:45 ` Preben Randhol 2004-01-30 18:49 ` Nature of XML Georg Bauhaus 2004-01-30 19:16 ` Marius Amado Alves 2004-01-30 22:59 ` Georg Bauhaus 2004-01-31 1:26 ` Robert I. Eachus 2004-01-31 13:08 ` Nature of XML (ramblings) Marius Amado Alves 2004-01-31 18:14 ` Georg Bauhaus 2004-02-03 1:35 ` Nature of XML Robert C. Leif 2004-02-03 14:23 ` Georg Bauhaus 2004-01-27 17:50 ` Standard Ada Preprocessor Warren W. Gay VE3WWG 2004-01-27 20:42 ` Randy Brukardt 2004-01-27 21:41 ` Warren W. Gay VE3WWG 2004-01-28 9:10 ` Dmitry A. Kazakov 2004-01-29 17:39 ` Warren W. Gay VE3WWG 2004-01-28 23:21 ` Randy Brukardt 2004-01-29 17:46 ` Warren W. Gay VE3WWG 2004-01-30 3:20 ` Robert I. Eachus 2004-01-28 12:27 ` Ole-Hjalmar Kristensen 2004-01-29 17:53 ` Warren W. Gay VE3WWG 2004-01-27 17:33 ` Warren W. Gay VE3WWG 2004-01-27 19:07 ` Jeffrey Carter 2004-01-27 21:42 ` Warren W. Gay VE3WWG 2004-01-27 2:35 ` Randy Brukardt 2004-01-27 21:47 ` Warren W. Gay VE3WWG 2004-01-28 1:19 ` Jeffrey Carter 2004-01-28 12:30 ` Ole-Hjalmar Kristensen 2004-01-28 23:35 ` Randy Brukardt 2004-01-29 10:16 ` Ole-Hjalmar Kristensen 2004-01-29 17:58 ` Warren W. Gay VE3WWG 2004-01-29 23:19 ` Randy Brukardt 2004-01-27 3:54 ` Jeffrey Carter 2004-01-27 21:53 ` Warren W. Gay VE3WWG 2004-01-28 1:27 ` Jeffrey Carter 2004-01-29 18:02 ` Warren W. Gay VE3WWG 2004-01-28 20:35 ` Pascal Obry 2004-01-29 0:53 ` Jeffrey Carter 2004-01-28 23:41 ` Randy Brukardt 2004-01-29 18:04 ` Warren W. Gay VE3WWG 2004-01-30 2:33 ` Chad R. Meiners 2004-01-30 18:00 ` Warren W. Gay VE3WWG 2004-01-30 22:52 ` Blinking text Chad R. Meiners 2004-02-06 17:14 ` Warren W. Gay VE3WWG 2004-01-27 7:41 ` Standard Ada Preprocessor Pascal Obry 2004-01-27 21:53 ` Warren W. Gay VE3WWG 2004-01-27 0:06 ` Robert I. Eachus 2004-01-27 21:55 ` Warren W. Gay VE3WWG 2004-01-28 1:34 ` Jeffrey Carter 2004-01-30 17:19 ` Warren W. Gay VE3WWG 2004-01-30 19:06 ` Frank J. Lhota 2004-02-10 11:18 ` stephen.freeman9 2004-02-10 17:45 ` Language Design (was Standard Ada Preprocessor) Warren W. Gay VE3WWG 2004-01-27 0:17 ` Standard Ada Preprocessor Alexandre E. Kopilovitch 2004-01-26 23:44 ` Georg Bauhaus 2004-01-27 22:04 ` Warren W. Gay VE3WWG 2004-01-28 2:47 ` Georg Bauhaus 2004-01-30 17:29 ` Warren W. Gay VE3WWG 2004-01-30 19:06 ` Georg Bauhaus 2004-01-31 8:42 ` Marin David Condic 2004-02-02 17:28 ` Warren W. Gay VE3WWG 2004-01-27 0:15 ` Standard Ada Preprocessor (Was: why ada is so unpopular ?) Robert I. Eachus 2004-01-27 22:05 ` Warren W. Gay VE3WWG 2004-01-24 8:17 ` Pascal Obry 2004-01-24 12:44 ` Marin David Condic 2004-01-24 15:39 ` Robert I. Eachus 2004-01-24 16:06 ` Marin David Condic 2004-01-26 11:28 ` Ole-Hjalmar Kristensen 2004-01-26 12:07 ` Marin David Condic 2004-01-23 16:38 ` Alexandre E. Kopilovitch 2004-01-23 17:54 ` Jeffrey Carter 2004-01-23 17:24 ` Warren W. Gay VE3WWG 2004-01-23 22:30 ` Randy Brukardt 2004-01-26 22:11 ` Warren W. Gay VE3WWG 2004-01-27 0:28 ` Robert I. Eachus 2004-01-27 22:13 ` Warren W. Gay VE3WWG 2004-01-27 1:02 ` Jeffrey Carter 2004-01-22 14:13 ` Robert A Duff 2004-01-22 17:27 ` Warren W. Gay VE3WWG 2004-01-23 12:54 ` Marin David Condic 2004-01-23 17:26 ` Warren W. Gay VE3WWG 2004-01-23 12:52 ` Marin David Condic 2004-01-24 5:52 ` Robert I. Eachus 2004-01-24 12:56 ` Marin David Condic 2004-01-24 15:53 ` Robert I. Eachus 2004-01-30 17:39 ` Warren W. Gay VE3WWG 2004-01-31 1:58 ` Robert I. Eachus 2004-02-02 17:55 ` Warren W. Gay VE3WWG 2004-02-04 18:36 ` Robert I. Eachus 2004-02-06 17:27 ` Warren W. Gay VE3WWG 2004-02-07 13:18 ` Marin David Condic 2004-02-09 17:37 ` Warren W. Gay VE3WWG 2004-02-10 14:59 ` Standard Ada Preprocessor Jacob Sparre Andersen 2004-02-10 17:57 ` Warren W. Gay VE3WWG 2004-02-10 21:49 ` Jacob Sparre Andersen 2004-02-11 8:34 ` Dmitry A. Kazakov 2004-02-13 17:27 ` Warren W. Gay VE3WWG 2004-01-30 17:34 ` Standard Ada Preprocessor (Was: why ada is so unpopular ?) Warren W. Gay VE3WWG 2004-01-22 12:47 ` Marin David Condic 2004-01-22 13:24 ` Jean-Pierre Rosen 2004-01-22 18:20 ` Robert A Duff 2004-01-23 9:18 ` Jean-Pierre Rosen 2004-01-23 12:59 ` Marin David Condic 2004-01-23 14:21 ` Jean-Pierre Rosen 2004-01-24 6:02 ` Robert I. Eachus 2004-01-24 13:09 ` Marin David Condic 2004-01-24 19:32 ` tmoran 2004-01-24 20:34 ` Marin David Condic 2004-01-22 17:29 ` Warren W. Gay VE3WWG 2004-01-22 13:19 ` Standard Ada Preprocessor Georg Bauhaus 2004-01-22 13:49 ` Marin David Condic 2004-01-22 15:03 ` Georg Bauhaus 2004-01-22 17:33 ` Warren W. Gay VE3WWG 2004-01-22 19:02 ` Georg Bauhaus 2004-01-23 17:35 ` Warren W. Gay VE3WWG 2004-01-24 1:50 ` Marin David Condic 2004-01-24 5:33 ` Randy Brukardt 2004-01-24 13:28 ` Marin David Condic 2004-01-24 15:58 ` Robert I. Eachus 2004-01-24 16:11 ` Marin David Condic 2004-01-24 19:32 ` tmoran 2004-01-24 20:44 ` Marin David Condic 2004-01-25 5:02 ` Robert I. Eachus 2004-01-25 16:38 ` Marin David Condic 2004-01-26 16:03 ` Robert I. Eachus 2004-01-24 23:39 ` Randy Brukardt 2004-01-25 13:47 ` Stephane Richard 2004-01-26 19:19 ` Randy Brukardt 2004-01-24 6:08 ` Robert I. Eachus 2004-01-23 13:11 ` Marin David Condic 2004-01-22 14:12 ` Dmitry A. Kazakov [not found] ` <ldlq00hmnm7ofaqem3kkrt7qhf6o7kjfmj@4ax.com> 2004-01-21 12:20 ` why ada is so unpopular ? Marin David Condic 2004-01-19 13:09 ` Jeff C, 2004-01-19 23:03 ` Robert I. Eachus 2004-01-20 1:10 ` cl1 2004-01-20 5:34 ` Robert I. Eachus 2004-01-20 7:37 ` Preben Randhol 2004-01-20 16:41 ` Robert I. Eachus 2004-01-20 23:59 ` Stephen Leake 2004-01-21 10:29 ` Preben Randhol 2004-01-17 23:01 ` Marin David Condic 2004-01-18 0:30 ` Hyman Rosen 2004-01-18 2:06 ` cl1 2004-01-18 3:12 ` Hyman Rosen 2004-01-18 3:28 ` cl1 2004-01-18 14:34 ` Marin David Condic 2004-01-19 23:46 ` chris 2004-01-18 18:41 ` Jano 2004-01-21 2:01 ` Luke A. Guest 2004-01-21 14:23 ` Hyman Rosen 2004-01-21 14:31 ` Ludovic Brenta 2004-01-21 15:15 ` Hyman Rosen 2004-01-21 18:40 ` Robert A Duff 2004-01-21 18:31 ` chris 2004-01-22 13:11 ` Marin David Condic 2004-01-22 23:33 ` Stephen Leake 2004-01-23 13:25 ` Marin David Condic -- strict thread matches above, loose matches on Subject: below -- 2004-01-23 20:03 Standard Ada Preprocessor (Was: why ada is so unpopular ?) Leon Winslow 2004-01-24 2:00 ` Marin David Condic 2004-01-26 20:03 Lionel.DRAGHI 2004-01-26 23:10 ` Robert A Duff
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox