#fortran 77

[multidimensionalsock]

Fun fact:

Older versions of FORTRAN (notably, it was introduced in FORTRAN 77) allow you to use IMPLICIT to define what variables what type should be used for variables where no specific type had been defined, based on the first letter of the variable name.

FORTRAN is strongly typed, when you make a variable you state it's type at the start.

E.g. This creates and then steps the value of an integer called J.

INTEGER :: IntExample

IntExample = 4

However with the use of IMPLICIT, we can do the following.

IMPLICIT INTEGER(I)

IntExample = 4

Fortran knows that IntExample is an int, because we have told it that any variable which starts with I, should be assumed to be an integer, unless stated otherwise.

Implicit can also be used for ranges of characters, and multiple characters

IMPLICIT REAL(X-Z) - would define any variable whose first character is between X and Z on the alphabet as a floating point (real) number.

IMPLICIT COMPLEX(U,V,W), CHARACTER*4 (C,S) - means that any variable that starts with U, V or W will be a COMPLEX type, and any variable starting with C or S will be a CHARACTER (used for strings and char types)

The benefits of this can't be seen as much today, but Fortran is known as the oldest computer programming language on earth, at the time when Fortran applications were being developed, space saved to store the program from not having to define every variables type explicitly could make quite a difference.

It also aligns with Hungarian notation, where you add a letter to the start of each variable type to denote what it is. E.g. bGrounded, would be a boolean, sMessage, would be a string. Though as far as I can tell, Hungarian notation is not common with Fortran users.

[sukimas]

when i have a job and more free time i'm going to create a game maker program that's written in fortran 77. you guys figure it out.

[afactaday]

#aFactADay2023

#1048: when arrays of inferred length were being added to FORTRAN 77 (back when you had to write it in all caps), there was a big argument over what to separate the upper and lower bounds with. two of the best proposals were an asterisk and a colon, so Walt Brainerd wrote an article called "Astronomy vs Gastroenterology". i promise, this is the peak of computer science humour, funnier than half a byte being a nibble.

another FORTRAN joke is that "In FORTRAN, GOD is REAL (unless declared INTEGER)", which references the fact that variables have default data types based on their first letter (A-H are real (decimal numbers)).

[brianmcnett-blog]

This 47-year-old computer is, if memory serves me, actually THREE computer systems, two of which are TTL and the third which is CMOS. The two TTL systems are basically identical, although they perform different functions. These machines are direct copies of the Viking Orbiter Computer Command System. They are each dual-redundant, having two of every circuit: power supplies, processors, buffers, inputs, and outputs. One of these serves as the CCS for Voyager, the other is somewhat modified over the original Viking Orbiter unit and serves as the Attitude and Articulation Control System.

The third is the Flight Data Subsystem, a a 128 register, nibble-serial CPU and 8096 words of 16-bit RAM. This FDS is the portion with the bad memory. It's a known issue with CMOS that its failure rate IS higher than TTL, but 47 years is a good long life, and this was the first time NASA had used CMOS on a probe. However, also as I understand this, NASA hasn't fully fixed the problem. They're not receiving good science data yet. What they've done is sufficiently resolved the communications issue for Voyager 1 to send useful ENGINEERING data. Now with that out of the way they can resolve the rest of the problem. Here's a top-down photo of the FDS, courtesy NASA.

Data storage on Voyager 1 is magnetic tape, which has been used over and over across its 47-year life, but only in situations where high data transmission rates can't be achieved. The FDS is directly connected to the RTG power source, as if the CMOS chips lose power, all data is lost, but as a loss of power for Voyager 1 implies far deeper issues, it's unlikely they'd need an FDS at that point. The original code for Voyager 1 was written using a combination of Fortran and Fortran 77, but over the years, updates to the code have been written in C. One of the features of the Voyager probes is that they can be programmed remotely on the fly. So... Anyway, a computer, built over 50 years ago, from early, discrete, CMOS logic, now nearly a full light-day away from Earth, developed a fault in a memory circuit, and engineers on Earth were able to diagnose the fault, and fix it through clever programming in a language, C, which wasn't broadly available until AFTER the Voyager probes had launched (I'm dating this from K&R C, not the early "research" releases. We could argue endlessly about when C was created). At any rate, JPL was using Fortran in 1977, not C. Today they use C, and somehow this still works seamlessly. Folks, this is a nearly 50-year-old system doing its level best, still returning useful data, long after it's official mission ended. We got our money's work on Voyager, don't ever doubt it. And kudos the the brilliant people keeping her going.

Y'all, the world is sleeping on what NASA just pulled off with Voyager 1

The probe has been sending gibberish science data back to Earth, and scientists feared it was just the probe finally dying. You know, after working for 50 GODDAMN YEARS and LEAVING THE GODDAMN SOLAR SYSTEM and STILL CHURNING OUT GODDAMN DATA.

So they analyzed the gibberish and realized that in it was a total readout of EVERYTHING ON THE PROBE. Data, the programming, hardware specs and status, everything. They realized that one of the chips was malfunctioning.

So what do you do when your probe is 22 Billion km away and needs a fix? Why, you just REPROGRAM THAT ENTIRE GODDAMN THING. Told it to avoid the bad chip, store the data elsewhere.

Sent the new code on April 18th. Got a response on April 20th - yeah, it's so far away that it took that long just to transmit.

And the probe is working again.

From a programmer's perspective, that may be the most fucking impressive thing I have ever heard.

[codingprolab]

CECS 342 Assignment 5 - Ancient Languages with Fortran 77

The purpose of this assignment is to give you some experience programming with older programming languages. You will be using Fortran 77 for this assignment (and not a newer version of Fortran!). Write a program in Fortran 77 to sort an array of numbers entered from the keyboard and then using binary search, search for a number in the array. If the number is not found then it should ask for…

[a078740849aposts]

ISBN: 978-960-645-666-4 Συγγραφέας: Αλέξανδρος Σ. Καράκος Εκδότης: Κλειδάριθμος Σελίδες: 486 Ημερομηνία Έκδοσης: 2024-12-01 Διαστάσεις: 24 x 17 Εξώφυλλο: Χαρτόδετο

[naming-is-my-greatest-weakness]

Whitespace-Insensitive

This is a fun one, but its going to need a little bit of background first.

Aside 1: Word Demarcation

Using spaces to demarcate words is a surprisingly recent innovation. Written Classical Latin and Greek both employed a form called scripto continua, in which words run one in to one another. This would look something like

Thiswouldlooksomethinglike

Occasionally, an interpunct (·) would be used to separate words, particularly on monuments and inscriptions, but it was not an obligatory part of the orthography. Separating words with spaces appeared in the seventh and eights centuries, and spread over the next few hundred years.

(All [0])

Aside 2: FORTRAN Whitespace Handling

Not only is FORTRAN whitespace-insensitive in the modern sense of collapsing all whitespace into a single character, whitespace was completely ignored, even within a keyword or variable name.

For example, GO TO and GOTO are completely equivalent, and would presumably be tokenized the same.

(All [1])

Finally

These facts led one FORTRAN manual to quip

Consistently separating words by spaces became a general custom about the tenth century A.D., and lasted until about 1957, when FORTRAN 77 abandoned the practice. [1]

[0] Wiki will do here

[1] SunSoft FORTRAN77 4.0 User's Guide, 1995.

[mafaweb]

WATFIV ve WATFOR nedir?WATFIV ve WATFOR, IBM tarafından geliştirilen ve FORTRAN dilinde yazılmış iki farklı bilgisayar programlama dili derleyicisidir. WATFOR, Fortran IV dilinin derleyicisidir ve FORTRAN IV dilinin yapılandırılmasına uygundur. WATFIV ise FORTRAN 66 dilinin derleyicisidir ve FORTRAN 66 dilinin yapılandırılmasına uygundur.İlk olarak 1966 yılında çıkan WATFIV, daha sonrasında FORTRAN 77 standardının piyasaya sürülmesiyle yerini WATFOR'a bırakmıştır. Yani WATFIV ve WATFOR, FORTRAN dilinin farklı versiyonlarına uyumlu şekilde çalışan derleyicilerdir.FORTRAN dilinin gelişmesiyle birlikte WATFIV ve WATFOR'un kullanımı da yaygınlaşmış ve bilgisayar programcıları tarafından sıklıkla tercih edilen derleyiciler haline gelmiştir. Hala birçok bilgi işlem uygulamasında kullanılmakta olan WATFIV ve WATFOR, bilgisayar programlamada önemli bir yere sahiptir.Bu derleyiciler, bilgisayar programcılarına FORTRAN diliyle program yazma ve derleme imkanı sunar. Bu sayede bilgisayar programlamacıları, verimli ve hızlı bir şekilde program geliştirebilir ve uygulama oluşturabilirler.WATFIV ve WATFOR'un gelişimi WATFIV ve WATFOR, Fortran dili için iki farklı derleyici programıdır. WATFIV, Waterloo Üniversitesi'nde geliştirilmiş, öğrencilerin ve akademisyenlerin kullanımı için tasarlanmış bir derleyici programıdır. Diğer yandan WATFOR, bu programın daha gelişmiş bir versiyonudur ve endüstriyel kullanım için uygun hale getirilmiştir. WATFIV ve WATFOR'un gelişimi sürecinde, başlangıçta sadece akademik amaçlarla kullanılan WATFIV, endüstriyel taleplerin artmasıyla beraber WATFOR'a evrilmiştir. Waterloo Üniversitesi, öğrencilerin endüstriyel dünyaya daha iyi hazırlanmaları amacıyla WATFOR'u geliştirmiştir. WATFIV ve WATFOR'un gelişimi sürecinde, özellikle bilgisayar teknolojisinin gelişmesiyle beraber, programlama dillerinde de sürekli yenilikler yapılması kaçınılmaz olmuştur. Bu yenilikler sayesinde, her iki derleyici programı da sürekli olarak güncellenmiş ve geliştirilmiştir. Sonuç olarak, WATFIV ve WATFOR'un gelişimi süreci, hem akademik hem de endüstriyel dünyadaki taleplere cevap verebilmek amacıyla sürekli olarak devam etmektedir. Günümüzde de sürekli olarak geliştirilen bu derleyici programları, programlama dünyasında önemli bir yere sahiptir. WATFIV ve WATFOR'un kullanım alanları WATFIV ve WATFOR, bilgisayar bilimlerinde kullanılan iki farklı programlama dilidir. Bu diller, genellikle sayısal analiz ve bilimsel hesaplama gibi alanlarda kullanılır. Özellikle mühendislik, matematik, fizik ve benzeri disiplinlerde yaygın olarak tercih edilir. WATFIV ve WATFOR programlama dilleri, büyük verilerin analizi, karmaşık matematiksel problemlerin çözümü ve bilimsel araştırmalar gibi yoğun hesaplama gerektiren alanlarda kullanıcılarına büyük avantajlar sağlar. Özellikle karmaşık matematiksel modellerin oluşturulması ve çözümü konusunda oldukça etkilidir. Genellikle üniversitelerin mühendislik ve fen fakültelerinde, araştırma laboratuvarlarında ve endüstriyel matematik uygulamalarında WATFIV ve WATFOR programlama dillerine sıkça başvurulur. Bu dillerin sağladığı güçlü hesaplama imkanları sayesinde, kritik öneme sahip problemlerin çözümü hızlı ve etkili bir şekilde gerçekleştirilebilir. WATFIV ve WATFOR programlama dilleri, karmaşık matematiksel problemlerin yanı sıra veri analizi, modelleme, simülasyon ve optimizasyon gibi geniş bir yelpazede kullanıcılarına kolaylık sağlar. Bu yönüyle, bilimsel araştırmalardan endüstriyel uygulamalara kadar çok çeşitli alanlarda etkin bir şekilde kullanılabilir. WATFIV ve WATFOR arasındaki fark WATFIV ve WATFOR arasındaki en temel fark, WATFIV'in FORTRAN IV dilini, WATFOR'un ise FORTRAN 66 dilini kullanan derleyiciler olmalarıdır. FORTRAN IV, daha eski bir dilken, FORTRAN 66 ise bu dilin güncellenmiş bir versiyonudur. Diğer bir fark, WATFIV'in sadece tek geçişli bir derleyici olmasıdır. Yani, program bir defa çalıştırılır ve tüm hatalar aynı zamanda bulunur. WATFOR ise çok geçişli bir derleyici olup, programın hatalarını bulmak için birkaç kere çalıştırılabilir.

Ayrıca, WATFIV'in sadece bir alt küme tabanlı bir dil olması ve tip dönüşümlerinin otomatik olarak gerçekleşmemesi de diğer bir fark olarak karşımıza çıkar. WATFOR ise daha kapsamlı bir dildir ve tip dönüşümleri otomatik olarak gerçekleşir. Son olarak, WATFIV ve WATFOR'un performans açısından da farklılık gösterdiğini belirtmek gerekir. WATFOR, FORTRAN 66 derleyicisini kullandığı için daha verimli kodlar üretebilir. WATFIV ve WATFOR'un avantajlarıWATFIV ve WATFOR programlama dilleri, bilgisayar bilimleri alanında kullanılan ve birçok avantaja sahip olan dillerdir. Bu dillerin kullanımı, program geliştirme sürecinde bir dizi kolaylık sağlar. Bu avantajlardan ilki, WATFIV ve WATFOR'un öğrenilmesinin diğer dillere göre daha kolay olmasıdır. Bu dillerin syntax'ı oldukça basittir ve anlaşılması kolaydır. Böylece, programcılar kısa sürede bu dilleri öğrenerek kullanmaya başlayabilirler.Bir diğer avantajı ise, WATFIV ve WATFOR'un hızlı çalışmasıdır. Bu diller, derlendikten sonra oldukça hızlı bir şekilde çalışır ve yüksek performans gösterirler. Bu da programların hızlı bir şekilde çalıştırılmasını ve verimli bir şekilde sonuç alınmasını sağlar.Bunun yanı sıra, WATFIV ve WATFOR dilleri, geniş bir kütüphane ve modüller setine sahiptir. Bu durum, programcıların ihtiyaç duydukları çeşitli fonksiyonları kolayca kullanabilmelerini sağlar. Bu sayede, programlama süreci daha hızlı ve verimli bir şekilde gerçekleştirilebilir.Son olarak, WATFIV ve WATFOR dilleri, esneklikleri sayesinde farklı platformlarda kullanılabilirler. Bu da programcılara çoklu platform desteği sunar ve projelerini farklı platformlarda rahatlıkla uygulayabilmelerine olanak tanır. Tüm bu avantajlar, WATFIV ve WATFOR'un tercih edilen programlama dilleri olmasını sağlar.WATFIV ve WATFOR'un örnek kullanımıWATFIV ve WATFOR, başlangıçta Fortran programlama dilleri için yazılmış bir derleyici programıdır. WATFIV, Waterloo Üniversitesi tarafından 1966 yılında geliştirilmiş ve daha sonra WATFOR'a evrilmiştir. Her iki program da, özellikle de akademik ve bilimsel alanlarda yaygın olarak kullanılmıştır.WATFIV'un örnek kullanımı açısından, genellikle karmaşık matematiksel problemleri çözmek için kullanılmıştır. Örneğin, diferansiyel denklemler veya lineer cebir problemleri gibi konularda araştırmacılar ve öğrenciler tarafından tercih edilmiştir. Ayrıca, mühendislik ve fizik gibi alanlarda da yoğun bir şekilde kullanılmıştır.WATFOR ise, WATFIV'in geliştirilmiş bir versiyonudur ve özellikle derleyici hatalarını daha etkili bir şekilde ayıklama imkanı sunar. Bu nedenle, büyük ölçekli projelerde tercih edilmektedir. Özellikle, endüstriyel ekiplerin karmaşık yazılım projelerinde WATFOR'u tercih ettiğini görmekteyiz.Sonuç olarak, WATFIV ve WATFOR'un örnek kullanımı açısından, bu programların matematiksel problemlerin çözümü ve büyük projelerde kod geliştirme gibi çeşitli alanlarda etkili bir şekilde kullanıldığını görmekteyiz.

[frentmeister]

Wie man Sicherheitstests für AngularJS mit Hilfe von OWASP ZAP durchführt

Schon 2018 hatte ich mich sehr umfassend mit dem Thema Voyager 1 und Voyager 2 beschäftigt. Dabei ging es um eine „fixe“ Idee, dass man das Board System welches Fortran beruht auf Python umswitcht. Ich habe in diesem Beitrag von 2018 dargelegt, wie die einzelnen Komponenten aufgebaut sind, wie man eventuell hier Python zum Einsatz bringen könnte. Aber nachhaltig auch festgestellt, dass ein Umstieg auf Python eventuell sogar schädlicher wäre.   https://www.dev-crowd.com/2018/12/22/retro-engineering-am-beispiel-voyager-1-und-voyager-2-mission/   Betrachtet man die Meldung bezüglich des „falschen Befehls“ der an Voyager 2 versendet wurde, so hätte man das in einer entsprechenden Emulation eigentlich feststellen müssen, dass eben dieser Befehl klar falsch ist. Bisher bin ich immer davon ausgegangen, dass so etwas in einer Emulation auf einem Environment stattfindet. Denn wie bei allen uns bekannten Sprachen, die man entsprechend einsetzt, gibt es entsprechende Testframeworks, die entsprechende Emulationen ausführen. Die Antenne von »Voyager 2« zeigt nicht mehr exakt zur Erde, der Kontakt ist dadurch unterbrochen. Der Grund: ein falscher Befehl. Doch im Oktober könnte die Kommunikation wieder aufgenommen werden. Quelle: https://www.spiegel.de/wissenschaft/nasa-verliert-kontakt-zu-sonde-voyager-2-wegen-eines-falschen-befehls-a-2c41883b-2e28-4413-a40b-075c59c10ce1 Hier eine weitere Meldung: Der Kontakt zu der Sonde war am 21. Juli 2023 abgebrochen, nachdem "eine Serie geplanter Befehle" an sie gesendet worden war. Die hatten dazu geführt, dass sich die Antenne um 2 Grad von der Erde wegdrehte, weshalb kein Kontakt mehr möglich war. Quelle: https://www.golem.de/news/raumfahrt-nasa-empfaengt-signal-von-voyager-2-2308-176370.html     Fortran spielte in den frühen Jahren der Raumfahrt und insbesondere bei der Entwicklung von Raumsonden eine wichtige Rolle. Das Voyager-Programm wurde in den 1970er Jahren gestartet, als Fortran immer noch eine der vorherrschenden Programmiersprachen für wissenschaftliche und technische Anwendungen war. Und Fortan wird bis heute gerade auch im wissenschaftlichen Umfeld immer noch genutzt! Welche Fortran Versionen gibt es? - Fortran I (1957): Die erste Version von Fortran wurde 1957 von IBM entwickelt. Sie wurde für den IBM 704 Computer entwickelt und war die erste höhere Programmiersprache überhaupt. Fortran I unterstützte die grundlegenden Konzepte der Programmierung, aber es gab noch keine Unterprogramme (keine Unterstützung für Unterprogramme wie Funktionen oder Subroutinen). - Fortran II (1958): Fortran II wurde 1958 veröffentlicht und fügte einige neue Funktionen hinzu, darunter Unterprogramme und die Möglichkeit, Unterprogramme in anderen Unterprogrammen aufzurufen. Es war eine verbesserte Version von Fortran I. - Fortran IV (1962): Fortran IV war eine weiter verbesserte Version von Fortran und wurde 1962 veröffentlicht. Es führte neue Funktionen wie logische Variablen, DO-Schleifen und FORMAT-Anweisungen ein, um die Ausgabe zu formatieren. - Fortran 66: Fortran 66, auch bekannt als Fortran IV oder Fortran 66 Standard, wurde 1966 eingeführt. Es war die erste offizielle Version der Sprache mit einem standardisierten Sprachumfang. Fortran 66 führte neue Funktionen wie das IF-THEN-ELSE-Konstrukt ein und standardisierte einige vorhandene Sprachkonstrukte. - Fortran 77: Fortran 77, auch bekannt als Fortran 1977 Standard, wurde 1977 veröffentlicht. Es war eine bedeutende Aktualisierung und erweiterte den Funktionsumfang von Fortran erheblich. Fortran 77 führte Zeichenkettenverarbeitung, dynamische Speicherzuweisung (mit der ALLOCATE-Anweisung) und verbesserte Array-Funktionen ein. - Fortran 90: Fortran 90 wurde 1991 veröffentlicht und brachte wichtige Erweiterungen in die Sprache. Es führte den freien Formatierungsstil ein, verbesserte die Array-Unterstützung (einschließlich dynamischer Arrays und Array-Schnittoperationen), fügte neue Sprachkonstrukte wie MODULES, POINTERs und DO WHILE-Schleifen hinzu und ermöglichte rekursive Unterprogramme. - Fortran 95: Fortran 95 wurde 1997 als geringfügige Aktualisierung von Fortran 90 veröffentlicht. Es behebt einige Unklarheiten und Fehler in Fortran 90 und fügt einige neue Funktionen hinzu, wie beispielsweise Verbesserungen bei der ALLOCATE-Anweisung und Unterstützung für den CHARACTER-Datentyp mit variabler Länge. - Fortran 2003, Fortran 2008, Fortran 2018: Diese Versionen sind weitere Erweiterungen von Fortran, die neue Funktionen und Verbesserungen in die Sprache einbringen, wie z. B. Verbesserungen bei der Behandlung von Zeichenketten, Verbesserungen bei der parallelen Programmierung (Fortran 2008) und viele andere Funktionen.  

Testframeworks für Fortran

In der Welt von Fortran gibt es mehrere Testframeworks, die verwendet werden können, um Unit-Tests für Fortran-Code durchzuführen. Wobei man sagen muss das Voyger 2 in Teilen noch auf Fortran 77 beruht aber auch Fortran 90.   Hier sind einige beliebte Testframeworks, es gibt aber weitaus mehr unter anderem entwickelt durch NASA Mitarbeiter: Testframework Details Weiterführende Informationen Alternative FRUIT (Fortran Unit Tester): FRUIT ist eines der ältesten Testframeworks für Fortran und wird häufig verwendet, um Unit-Tests für Fortran-77-Code zu schreiben. Es unterstützt die Erstellung von Testsuiten und Assertions, um die Funktionalität von Fortran-Routinen zu überprüfen. https://github.com/mortele/FRUIT FUnit FUnit ist ein moderneres Testframework für Fortran, das speziell für die Erstellung von Unit-Tests in Fortran entwickelt wurde. Es unterstützt Fortran 90 und höher und bietet eine Vielzahl von Testfunktionen und Assertions. https://fortranwiki.org/fortran/show/FUnit    Fortran Unit Test (FUT): FUT ist ein weiteres Testframework für Fortran, das es ermöglicht, Unit-Tests für Fortran-Code zu schreiben. Es bietet Funktionen wie Assertions und die Möglichkeit, Testergebnisse zu protokollieren. https://github.com/dongli/fortran-unit-test   PFUnit (Parallel Fortran Unit Test): PFUnit ist ein Testframework, das speziell für den Test paralleler Fortran-Code entwickelt wurde. Es ermöglicht die Durchführung von Tests für parallele Funktionen und Routinen. https://github.com/Goddard-Fortran-Ecosystem/pFUnit Fortran Test Framework (FTF): Das Fortran Test Framework ist ein einfaches und leichtgewichtiges Testframework für Fortran. Es unterstützt die Erstellung von Unit-Tests und Assertions.   https://github.com/agforero/FTFramework Ein Flussdiagramm zur Beschreibung der Laufzeit:

    ForFUnit: ForFUnit ist ein weiteres Testframework für Fortran, das es ermöglicht, Unit-Tests für Fortran-Code zu schreiben. Es bietet Funktionen wie Assertions und die Möglichkeit, Testergebnisse zu protokollieren.       Fortuno Benutzerfreundliches, flexibles und erweiterbares objektorientiertes Fortran-Unit-Testing-Framework zum Testen von seriellen, MPI-parallelisierten und Coarray-parallelisierten Anwendungen. https://github.com/aradi/fortuno      

Aufbau von Testszenarien in Fortran

In Fortran gibt es keine eingebauten Testframeworks oder Assertions wie in einigen modernen Programmiersprachen. Daher müssen Entwickler Testroutinen und Assertions oft manuell implementieren. Hier ist ein einfaches Beispiel, wie ihr eine Testroutine mit Assertions in Fortran erstellen könnt: PROGRAM TestExample IMPLICIT NONE ! Function to be tested REAL FUNCTION Square(x) REAL, INTENT(IN) :: x Square = x * x END FUNCTION Square ! Test routine SUBROUTINE RunTests INTEGER :: numTests, i REAL :: input, result, expected ! Array of test cases: (input, expected result) REAL, DIMENSION(3, 2) :: testCases testCases = RESHAPE(, ) numTests = SIZE(testCases, 1) DO i = 1, numTests input = testCases(i, 1) expected = testCases(i, 2) result = Square(input) ! Assertion IF (result == expected) THEN WRITE(*, '(A, F6.2, A, F6.2)') 'Test ', input, ': Passed. Result = ', result ELSE WRITE(*, '(A, F6.2, A, F6.2, A, F6.2)') 'Test ', input, ': Failed. Expected = ', expected, ', Got = ', result END IF END DO END SUBROUTINE RunTests ! Run the tests CALL RunTests() END PROGRAM TestExample

Aufbau einer Testsuite in Fortran

In Fortran gibt es keine eingebaute Testsuit-Struktur wie in einigen modernen Programmiersprachen. Daher müssen Entwickler Testsuiten manuell implementieren. Eine Testsuite in Fortran ist eine Sammlung von mehreren Testroutinen, die verschiedene Funktionen oder Teile des Fortran-Codes testen. Hier ist ein einfaches Beispiel, wie Sie eine Testsuite in Fortran erstellen können: Angenommen, ihr habt eine Fortran-Datei my_functions.f90, die einige Funktionen enthält, die ihr testen möchtet. Ihr könnt eine separate Testdatei test_my_functions.f90 erstellen, die eure Testsuite enthält. ! Datei: my_functions.f90 MODULE MyFunctions IMPLICIT NONE CONTAINS ! Funktion 1: Berechne das Quadrat einer Zahl REAL FUNCTION Square(x) REAL, INTENT(IN) :: x Square = x * x END FUNCTION Square ! Funktion 2: Berechne die Fakultät einer ganzen Zahl INTEGER FUNCTION Factorial(n) INTEGER, INTENT(IN) :: n INTEGER :: i, result result = 1 DO i = 1, n result = result * i END DO Factorial = result END FUNCTION Factorial END MODULE MyFunctions   ! Datei: test_my_functions.f90 PROGRAM TestSuite USE MyFunctions IMPLICIT NONE ! Testroutine für Square SUBROUTINE TestSquare REAL :: input, result, expected ! Testfälle: (input, erwartetes Ergebnis) REAL, DIMENSION(3, 2) :: testCases testCases = RESHAPE(, ) WRITE(*, '(A)') 'Testing Square' DO i = 1, SIZE(testCases, 1) input = testCases(i, 1) expected = testCases(i, 2) result = Square(input) ! Assertion IF (result == expected) THEN WRITE(*, '(A, F6.2, A, F6.2)') 'Test ', input, ': Passed. Result = ', result ELSE WRITE(*, '(A, F6.2, A, F6.2, A, F6.2)') 'Test ', input, ': Failed. Expected = ', expected, ', Got = ', result END IF END DO END SUBROUTINE TestSquare ! Testroutine für Factorial SUBROUTINE TestFactorial INTEGER :: input, result, expected ! Testfälle: (input, erwartetes Ergebnis) INTEGER, DIMENSION(3, 2) :: testCases testCases = RESHAPE(, ) WRITE(*, '(A)') 'Testing Factorial' DO i = 1, SIZE(testCases, 1) input = testCases(i, 1) expected = testCases(i, 2) result = Factorial(input) ! Assertion IF (result == expected) THEN WRITE(*, '(A, I3, A, I6)') 'Test ', input, ': Passed. Result = ', result ELSE WRITE(*, '(A, I3, A, I6, A, I6)') 'Test ', input, ': Failed. Expected = ', expected, ', Got = ', result END IF END DO END SUBROUTINE TestFactorial ! Hauptprogramm der Testsuite CALL TestSquare() CALL TestFactorial() END PROGRAM TestSuite  

Wie man den Fehler hätte verhindern können?

Grundsätzlich gehe ich davom aus das die NASA solche Testmethoden einsetzt und auch entsprechende Emulationen laufen hat? Trotzdem wundert es das man hier eben doch falsche Befehle versendet hat. Entweder ist es menschliches Versagen, oder die Befehle wurden nicht ausreichend geprüft? Das Testen von falschen oder fehlerhaften Befehlen in Fortran kann schwierig sein, da der Fortran-Compiler normalerweise während der Kompilierung Fehler in ungültigen Befehlen erkennt und den Kompilationsprozess beendet. Dennoch könnt ihr in einigen Fällen Testfälle erstellen, um zu überprüfen, wie Ihr Code mit fehlerhaften Befehlen umgeht. Hier sind einige Möglichkeiten, wie ihr falsche Befehle in Fortran testen könntet: - Ungültige Variablennamen: Erstellt Testfälle mit ungültigen oder nicht deklarierten Variablennamen, um zu überprüfen, wie euer Code auf solche Fehler reagiert. - Syntaxfehler: Erstellt Testfälle mit fehlerhaften Syntaxkonstruktionen, wie beispielsweise fehlenden Klammern, falschen Zeichenketten oder fehlenden Semikolons. - Falsche Datentypen: Überprüft, wie euer Code auf ungültige Datentypen reagiert, z. B. wenn ihr versucht, eine Zeichenkette in eine ganze Zahl umzuwandeln oder umgekehrt. - Ungültige Compilerdirektiven: Testet, wie euer Code auf ungültige oder nicht unterstützte Compilerdirektiven reagiert. - Fehlerhafte Ein-/Ausgabeoperationen: Testet, wie euer Code auf fehlerhafte Ein-/Ausgabeoperationen reagiert, z. B. wenn ihr versucht, in eine geschlossene Datei zu schreiben oder von einer nicht vorhandenen Datei zu lesen. Die folgenden Beispiele zeigen, wie einige der oben genannten Szenarien in einer Testumgebung aussehen könnten: FUNCTION Divide(a, b) REAL, INTENT(IN) :: a, b REAL :: Divide IF (b == 0.0) THEN WRITE(*, '(A)') 'Error: Division by zero.' STOP END IF Divide = a / b END FUNCTION Divide SUBROUTINE TestNegativeDivision REAL :: result ! Negative Test: Division durch Null result = Divide(5.0, 0.0) ! Erwartung: Fehlermeldung "Error: Division by zero." END SUBROUTINE TestNegativeDivision FUNCTION GetStringLength(str) CHARACTER(*), INTENT(IN) :: str INTEGER :: GetStringLength GetStringLength = LEN_TRIM(str) END FUNCTION GetStringLength SUBROUTINE TestInvalidStringLength INTEGER :: length CHARACTER(5) :: myString = "Hello" ! Negative Test: Zuweisen eines zu langen Strings zu einer begrenzten Zeichenkette length = GetStringLength(myString) ! Erwartung: Compilerfehler oder Laufzeitfehler END SUBROUTINE TestInvalidStringLength Diese Beispiele zeigen, wie ihr Testfälle erstellen könnt, die fehlerhafte Befehle in eurem Fortran-Code auslösen, um sicherzustellen, dass euer Code angemessen auf solche Fehler reagiert. Wie in jeder anderen Sprache sollte man auch die entsprecchenden Workflows einhalten. Es geht immer um den Test von Schwachstellen, daher ergeben sich auch immer die gleichen Szenarieren im Test. Statische Code-Analyse: Statische Code-Analysetools durchsuchen euren Quellcode, um mögliche Schwachstellen und Fehler zu erkennen, ohne den Code tatsächlich auszuführen. Diese Tools können beispielsweise potenzielle Speicherzugriffsfehler, uninitialisierte Variablen oder unsichere Aufrufe von Funktionen erkennen. Einige gängige statische Analysetools für Fortran sind: - Frama-C: Ein Framework für die statische Analyse von C- und Fortran-Code. - FortranLint: Ein kommerzielles statisches Analysetool für Fortran. Dynamische Code-Analyse: Dynamische Code-Analysetools führen Ihren Code aus und überwachen sein Verhalten zur Laufzeit. Diese Tools können Laufzeitfehler, Speicherlecks und andere potenzielle Probleme erkennen. Beim Testen von Fortran ist es wichtig, Ihre Tests mit verschiedenen Eingabewerten und Grenzfallbedingungen durchzuführen. Mit selbst ist nur ein Tool bekannt welches Entsprechend ab Fortran 77 eingesetzt werden kann: Code-Reviews: Peer-Reviews und Sicherheitsüberprüfungen sind ebenfalls wichtige Schritte, um potenzielle Schwachstellen im Code zu entdecken. Lassen Sie andere Entwickler Ihren Code überprüfen und Feedback geben, um mögliche Sicherheitslücken zu identifizieren.

Kann man diesen Testcode automatisieren?

Ja, ihr könnt den Testcode in Jenkins oder GitHub in einer Pipeline automatisieren, um eine kontinuierliche Integration und automatisierte Testabläufe zu ermöglichen. Beide Plattformen bieten Möglichkeiten, Skripte und Tests in einer Pipeline zu definieren und auszuführen, um sicherzustellen, dass euer Code kontinuierlich getestet wird. Es wundert mich das dieser fehler gerade der NASA passiert ist, denn einige der oben genannten Testframeworks sind eigene Entwicklungen von NASA Mitarbeitern. Beispiel Jenkins: In Jenkins könnt ihr eine Pipeline erstellen, um eure Fortran-Tests zu automatisieren. Ein einfacher Jenkins-Pipeline-Code könnte wie folgt aussehen: pipeline { agent any stages { stage('Build') { steps { // Hier den Code aus dem Repository klonen und den Fortran-Compiler ausführen, um den Code zu kompilieren } } stage('Test') { steps { sh 'gfortran -o test_my_functions test_my_functions.f90 my_functions.f90' // Kompilieren des Testcodes sh './test_my_functions' // Ausführen der Testsuite } } } } Beispiel Github Actions; In GitHub können Sie eine ähnliche Pipeline in Form von GitHub Actions erstellen. GitHub Actions ermöglicht es Ihnen, den Testcode in einer YAML-Datei zu definieren, die im Repository gespeichert wird. Read the full article

[pillmillipedes]

Wanna add a couple more

Assembly, 77 years

Fortran, 67 years

APL, 58 years (older than ASCII)

Smalltalk, 52 years (general public release came later)

MATLAB, 45 years

Erlang, 38 years

Lua, 31 years

Ruby, 29 years

C is 45 years old and ML is 44 years old, can you imagine.

[afactaday]

#aFactADay2023

#1049: in a FORTRAN 77 meeting in November 1976, a proposal was made, titled "Letter O Considered Harmful". it proposed removing the letter O entirely. this would solve both the problem of confusing it with the digit 0, and people over-using GO TO statements. that might have of course broken some old code, but that was dismissed because it would be "probably non-conforming, anyway".

[mayertis-not-a-user]

Lol, I was studying Fortran 77 in my university. It was crazy - it's syntax seemed for me to be similar to Pascal, so it was confusing me all the time 😂

What if we did portmanteau ship-names for the computer side of the Encom polycule

(F)lynn

Y(OR)I

(TR)on

R(AM)

Fortram

.

.

[a078740849aposts]

ISBN: 978-960-645-666-4 Συγγραφέας: Αλέξανδρος Σ. Καράκος Εκδότης: Κλειδάριθμος Σελίδες: 486 Ημερομηνία Έκδοσης: 2024-12-01 Διαστάσεις: 24 x 17 Εξώφυλλο: Χαρτόδετο

[metastablephysicist]

what's the opposite of a hateblog? loveblog? this is now a fortran 77 loveblog

[1e-9des]

sometimes I still can't believe that my daily grind involves working with fortran code.

[aharonov-bohm-affect]

Depending on the version of Fortran, you may have made the right decision.