There is no way to mark the language version, no #pragma stdc version iso99
Delphi: {$IF CompilerVersion >= 17.0} Freepascal: {$if FPC_VERSION > 2} No make files: the compiler handles that trash for you. Compatibility: Freepascal supports Delphi, Object Pascal, and has various switches for all kinds of things should you need it. Supports Windows, Linux, Mac, Android, Amiga (...seriously) and a multitude of other systems. On Wed, May 9, 2018, 6:54 AM Richard O'Keefe <rao...@gmail.com> wrote: > I have a C++ program written in the late 80s by someone > else. It used to run fine under cfront 2.0 and early g++. > Ten years after it was written it was impossible to compile. > > *Since* that there have been changes to streams and strings, > amongst other things. > > The 1989 C standard changed the semantics of mixed signed/unsigned > integer arithmetic. It also inadvertently rendered illegal a > widely used technique. It is notoriously the case these days > that compilers taking the C standards literally have "broken" > quite a lot of code that worked with less ambitious compilers. > I have been watching this phenomenon with considerable > nervousness. See for example > http://www.eng.utah.edu/~cs5785/slides-f10/Dangerous+Optimizations.pdf > > I have certainly had previously acceptable C89 code be rejected > by compilers as not being legal C11. It is true that compilers > tend to have command line/IDE switches to ask that old code be > compiled under old rules, but you cannot say that *in* the program. > There is no way to mark the language version, no > #pragma stdc version iso99 > > > > As for Java, I could rant about the floods of deprecation warnings > from old code. I shall content myself with one observation. > Read http://java-performance.info/changes-to-string-java-1-7-0_06/ > Before Java 1.7, the substring operation in Java took O(1) time > and space. From Java 1.7 on, it takes time and space linear in the > size of the result. The syntax and abstract semantics did not > change but the pragmatics did. Code that had adequate performance > could suddenly start crawling. > > Oracle do a tolerably thorough job of describing compatibility > issues between JDK releases. See for example > > http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html#A999198 > where we learned that the 'apt' tool was gone, the JDBC-ODBC bridge > was gone, 32-bit Solaris support (and yes, I was still using 32-bit > code in SPARC Solaris and Intel Solaris) was gone, and the type > inference algorithm had changed in a way that could break things. > I am still somewhat peeved about some of the rewriting I've had to > do over the last several releases. > > Then there is the simple fact that porting code from one release of > an OS to another can be a pain. Solaris 10 to OpenSolaris was easy. > OpenSolaris to Solaris 11 was not as painless. Solaris 11 to > OpenIndiana was not a happy time for me. OpenBSD changes forced > rework. I'd finally got my program to port smoothly between Solaris, > Darwin, and Linux. And then I had trouble porting to the next major > release of Linux. And with Ubuntu 17, I've got another problem I > still haven't tracked down. All of this in a C program that gets > regularly (sp)linted and checked all sorts of ways, written with > the intention of producing portable code. > > EVERYTHING BREAKS. > > > On 7 May 2018 at 22:42, Trygve Reenskaug <tryg...@ifi.uio.no> wrote: > >> Please tell me when Java, C, C++, etc programs stopped working because >> their runtime systems had changed. >> Please tell me when Java, C, C++, etc compilers stopped compiling old >> code because the languages had changed. >> >> >> On 07.05.2018 11:57, Norbert Hartl wrote: >> >> I understand what you are saying but it contains some misconceptions >> about the modern software world. >> >> „The earth is not stopping to turn just because you want to stay on the >> sunny side“ >> >> There is two funny concepts going on in the modern software industry. The >> one tells you that because you want to do a product everything else around >> you should come to a full stop so can comfortably build your software not >> disturbed by other things. The second one tells you that you _have to >> upgrade_ … there is this magical force preventing you from staying where >> you are. Both notions are funny alone but they come combined and then they >> turn out to be a non-sensical monster. >> >> Let’s take a different approach. Put in everything you say about >> software, libraries, etc the word version. So you can build upon Pharo >> version 3 your own product. You can stay at that version and it won’t >> change. If the software you sell is not 80% pharo but your own you should >> not have a problem just to stay on that version because you develop your >> own stuff. But still the world did not stop turning and there is pharo 4. >> You decide there are a few nice features but the work to adjust is too big >> to take the risk. Then there is pharo 5 and you … nahhh not this time….Then >> there is pharo6 and they not only changed the image but also the way source >> code is managed. That prevents you further from adjusting. But hey you can >> still be happy with pharo3 and it does not change. >> >> So what is the real problem? Yes, money/time is not enough. I think there >> are a lot of people risking their health to promote pharo and now we have a >> consortium that can pay engineers to do work on pharo. So let me tell you a >> future story: >> >> You see what pharo is doing and you think it is good. You can also see >> that there are too less resources to proceed in the way you need it to go. >> So you decide to show pharo to the world inspiring people with some kind of >> a vision. The result is that more people pay into the consortium and we >> hire more engineers. And then one day the consortium has enough money to >> pay engineers that can care about a LTS (long term support) version of >> pharo. So you can stay on pharo version 3 and still get those annoying bugs >> fixed. And hey this team has also enough time to provide you with tools >> that make a migration to pharo version 4 more easy and less annoying for >> you. And then you have your own product based on pharo version 4. And then >> for version 5, version 6,…. Sounds like a dream…but hey…it is indeed >> realistic. It just depends on how the people approach it >> >> How does this sound? >> >> Norbert >> >> Am 07.05.2018 um 11:31 schrieb Trygve Reenskaug <tryg...@ifi.uio.no>: >> >> Thanks for your quick answer. I have only a fleeting knowledge of Pharo >> but liked what I saw. The Squeak class library has seen organic growth >> since 1978 or earlier. Pharo gave it a thorough overhaul. At the Pharo >> kernel was a minimal image with a minimal class library. The rest of the >> functionality was partitioned into packages that could be added to the >> kernel image as required. Beautiful. But only my dream? >> >> *Matthew 7:24-27: And the rain fell, and the floods came, and the winds >> blew and beat on that house, but it did not fall, because it had been >> founded on the rock. And everyone who hears these words of mine and does >> not do them will be like a foolish man who built his house on the sand."* >> >> I am developing an IDE for non-programmers called BabyIDE, a >> non-intrusive extension of Squeak. Where the Class Browser in Squeak is >> used to work with one class at the time, the BabyIDE browser is used to >> work with structures of collaborating objects, ignoring their classes. I >> would like to develop a BabyIDE image that gets broad usage and long life. >> I'm looking for a rock to build on and hoped it could be what I thought was >> the Pharo kernel+ a few selected packages. In your answer, I read that if I >> build BabyIDE on Pharo, I will be building on sand. >> >> pharo.org writes: "*Pharo is a pure object-oriented programming >> language...*". The only language I can see is defined by the release >> image. A Pharo programmer builds application programs in this language. He >> or she can add new classes, change existing ones, subclass them, add or >> change methods, change the Smalltalk dictionary, etc. etc. An extremely >> flexible and powerful language. >> >> A tale from the future when Pharo is a mainstream language: Business >> customers benefit from end users using applications that are written by >> Pharo programmers who built on the Pharo language and environment that had >> been developed by the Pharo community. One day there is a happy >> announcement: A new version of Pharo will be launched tomorrow. It is truly >> cool and includes any number of improvements, some of them documented. And, >> by the way, applications written in the current Pharo will no longer work. >> So please inform your customers that you will not be able to serve them for >> a while. We are confident that all your application programmers will be >> happy to drop whatever they are doing in order to adapt their applications >> to the new Pharo so that you can start serving your customers again. >> >> Cheers >> --Trygve >> >> >> >> On 06.05.2018 13:00, Norbert Hartl wrote: >> >> Can you elaborate on what you consider as a kernel? There are always >> things moving in the pharo world. The last years the virtual machine got >> some iterations and it is still not fully stable. For pharo it is hard to >> have it stable because we feel the need that a lot of the existing parts >> need to be replaced to be useful in these times. Furthermore pharo is also >> prototyping platform for programming language features. All of these are >> counter-stability measures. So if you need a stable kernel from native >> ground up to UI pharo won‘t be that thing you are looking for the coming >> years (if at all). You always need to adopt to change so you need to define >> your required scope better in order to get an estimate. >> >> Norbert >> >> Am 06.05.2018 um 11:31 schrieb Trygve Reenskaug <tryg...@ifi.uio.no>: >> >> I'm working on a programing paradigm and IDE for the personal programmer >> who wants to control his or her IoT. The size of the target audience I have >> in mind is >100 million. I gave up Squeak long ago as a platform because >> they obsolete my code faster than I can write it. I have now frozen Squeak >> 3.10.2 and hope its runtime will survive until I find a better foundation. >> My hope is that Pharo has a stable kernel that I can build on. According >> to Stephan, this is not so. Is there any plan for creating a stable Pharo >> kernel that people can use for building software of lasting value for >> millions of non-expert users? >> --Thanks, Trygve >> >> On 05.05.2018 13:53, Stephan Eggermont wrote: >> >> I’ve taken a look at what would be needed to >> support magma on pharo a few years ago. Chris always told us he uses it >> professionally on squeak and *has not enough capacity to keep up with >> changes in pharo without having a customer/maintainer for it.* Twice a year >> or so someone asks about magma on pharo and takes a look. AFAIK there are >> no real obstacles to a port, but magma uses a lot of deep implementation >> specifics that will take an experienced smalltalker to deal with, and a lot >> of mailing list archeology as pharo changed a lot since magma worked on >> pharo last >> >> Stephan >> >> >> -- >> *The essence of object orientation is that >> objects collaborate to achieve a goal. * >> Trygve Reenskaug mailto: tryg...@ifi.uio.no <%20tryg...@ifi.uio.no> >> Morgedalsvn. 5A http://folk.uio.no/trygver/ >> N-0378 Oslo http://fullOO.info <http://fulloo.info/> >> Norway Tel: (+47) 22 49 57 27 >> >> >> -- >> *The essence of object orientation is that >> objects collaborate to achieve a goal. * >> Trygve Reenskaug mailto: tryg...@ifi.uio.no <%20tryg...@ifi.uio.no> >> Morgedalsvn. 5A http://folk.uio.no/trygver/ >> N-0378 Oslo http://fullOO.info <http://fulloo.info/> >> Norway Tel: (+47) 22 49 57 27 >> >> >> >> -- >> >> *The essence of object orientation is that objects collaborate to >> achieve a goal. * >> Trygve Reenskaug mailto: tryg...@ifi.uio.no <%20tryg...@ifi.uio.no> >> Morgedalsvn. 5A http://folk.uio.no/trygver/ >> N-0378 Oslo http://fullOO.info >> Norway Tel: (+47) 22 49 57 27 >> > >