Notices by mcc (mcc@mastodon.social)

Thinking about how a completely plausible thing that could happen at this moment in history is that the Boring Company and the Boeing Company could merge to form the Boering Company, which would immediately move its headquarters to South Africa

@nixCraft SPIT stands for Secure, Private Information Technology and it is what we need to move toward. The entire industry should be built on SPIT

@computerspielemuseum @foone Oh, now that looks potentially viable… maybe a bit above my skill level but :O

Hello EU people:

There is an EU citizen petition to ban the use of "conversion therapy" on LGBTQ+ folks. If that's interesting to you, you can sign it here:

https://eci.ec.europa.eu/043/public/#/screen/home

Please especially take note if you are a national of Spain, Slovenia, Belgium, or the Netherlands; the petition needs about 5x as many votes as it has now, but it also needs to hit a threshold in three additional countries, and those are the four closest.

Here is a post about the petition:

https://mstdn.social/@alchemistsstudio/113946253033171377

I am getting a weird floaty feeling from FORTRAN. I do not at any point really understand what I'm doing, but I am having little to no problems having any one particular thing. I keep doing google searches and getting which I do not understand the syntax of ( `write(error_unit, *) "String to write"`— wait, what? but which work. I do not know if I'd be able to get anywhere with this language if I didn't have either a more experienced programmer or Google+Stack Overfow.

…hm. I am concerned.

According to the FORTRAN working group

https://wg5-fortran.org/N2201-N2250/N2212.pdf

As of the 2023 standard, an un-allocated deferred-length variable may have its length set by calling intrinsic procedures; they give GET_COMMAND as an example specifically, and StackOverflow users assert GET_COMMAND_ARGUMENT is also included.

I don't get this behavior. My argument is being input as ''.

Do you think this means my code (linked above) is wrong, or that gfortran -std=f2023 is nonconformant?

Here's my serious FORTRAN problem (code link in previous post):

The recommended GET_COMMAND_ARGUMENT function seems to assume you know the length of the argument ahead of time. Obviously, I don't.

https://gcc.gnu.org/onlinedocs/gfortran/GET_005fCOMMAND_005fARGUMENT.html

It allows me to pass in an `allocatable` string, but I believe it is leaving that string of length 0 if I do not ALLOCATE() it, and the fetched string is ''. Is there a way to get the length of a command-line argument before GET-ing it?

I see GET_COMMAND, but that's… awkward

Here is my current program. At the moment, all it does is take a command line argument (a path) and attempt to open the specified file. I build it with `gfortran src/puzzle.f90 -std=f2023 -o program`

https://github.com/mcclure/aoc2024/blob/822e460f81b944c21ca675303b868c45b22a4c2b/04-01-wordsearch/src/puzzle.f90

I'm having two problems, one serious, one unserious.

The unserious problem: I want to abort if the # of arguments is bad. If I do "error stop", it prints a backtrace, which I didn't ask for. If I do "call abort", gfortran fails to link ("undefined reference to 'abort_').

Now that I have successfully figured out how to read an argument from the command line without knowing its length ahead of time, I am stuck on figuring out how to read a line of text from a file without knowing its length ahead of time. Apparently not an expected FORTRAN use case. I think the trick I was using before will not work, or at least, I *think*

read(10,"(a)",size=line_length,advance='NO') line_in

should read a line without advancing the filehandle and save the size. But it saves 0.

Oh my hell lol, I sincerely believe I have found a bug (standard nonconformance) in GNU FORTRAN 14.2.0 and I have a repro case

https://github.com/mcclure/aoc2024/blob/b31be91adb5a0721f97e2ba8f145da4f36129753/04-01-wordsearch/src/puzzle.f90

Am I going to have to figure out how to report a bug on GNU. Geez. Is this going to be like the bureaucracy planet scene in Jupiter Rising

Incidentally, I am very comfortable usually with reading language specifications, but I got hold of a copy of the FORTRAN 2008 spec and… this is one of the least friendly language specifications I've ever seen, when reading it to try to determine how a program should be written.

(Trivia: When the image on the right says something like "the value must be YES or NO" what they mean is "the value must be 'YES' or 'NO'.)

This is the second time in the longform challenge I have found myself having to implement fprintf() [the other time was Forth]. Both languages do predate C, but I was hoping both would have, at some point in the last 55 years, realized "oh… people want to be able to input line-delimited text files" and added such a feature.

Like okay I understand what you are trying to do here is not commit to a particular byte length because you want to support 7-bit bytes, 8-bit bytes, and possibly UTF-16 characters or something, but YOU COULD HAVE *SAID SO* INSTEAD OF MAKING A LOOP OF 3 DEFINITIONS LINKING TO EACH OTHER

FORTRAN 2008 spec 9.1:
"A file is composed of either a sequence of file storage units (9.3.5) or a sequence of records… A file composed of file storage
13 units is called a stream file."

The definition of "file storage units" (9.3.5):
"A file storage unit is the basic unit of storage in a stream file or an unformatted record file."

The linked definition of "Stream file" (1.3.139)
A file composed of a sequence of le storage units (9.1)

YOU ASSHOLES, THIS DEFINITION IS CIRCULAR!

Since automatic deferred length initialization is not working as the spec seems to require, I decided to just read the file in line by line.

This was much harder than I expected! The GNU docs do not well describe READ/WRITE, but do well describe the standard library functions. So I wrote around FGETC(), but then it turned out this is a GNU extension (or possibly was in FORTRAN 77 but not future FORTRANS?) so I had to rewrite to use normal READ in "Stream mode"… not in the GNU docs * _ *

(1/2)

git discovery: you cannot check a file you do not have permissions to into a repository.

problem: my repo contains a directory of test files. this directory contains a second directory of "invalid" tests, i.e., tests that the program is *expected* to fail on (and if it doesn't fail cleanly that's an error). one of the "invalid" tests is a file the program doesn't have read permissions to.

I cannot check my "file with no read permissions" test case into the repository :(

By the way, check out this vaguely hilarious section from the FORTRAN 2008 spec, where they state in the *most noncommital terms possible* that a byte is *probably* 8 bits (they don't say "byte"; they don't like the word "byte"; the word "byte" appears exactly twice in the 621-page spec, both times in the C interoperability section) then have this long additional note falling all over themselves to apologize for the hubris of suggesting that a byte is probably 8 bits.

I wound up slowly picking my way through the 2008 language spec, as previously mentioned not super readable. But I got it to work:

https://github.com/mcclure/aoc2024/blob/a8835dcd8ad0162268ef16708f9a7cd8b6d45958/04-01-wordsearch/src/puzzle.f90

Annoyed I had to spend all this time just doing file management, I decided to do the file management REALLY WELL. It's got unique error messages for different types of file handling errors and everything!

Now if only I could make gfortran suppress that darn `error stop` backtrace..

(2/2)

@foone pretty sure no

I assume that the "y'all" keyword would be a standin for every variable in scope. So you say

y'all += 4

and it adds 4 to all variables.

It might be possible to implement this in userspace in Python.

#BabelOfCode 2024
Week 4
Language: FORTRAN

Confidence level: High

PREV WEEK: https://mastodon.social/@mcc/113867584791780280
RULES: https://mastodon.social/@mcc/113676228091546556

I was very excited about doing TCL this week, but I told myself the first time I get a two-dimensional array problem I'd go FORTRAN, so I guess this week is FORTRAN.

A friend of mine who did AOC2024 in December noted the early challenges this year were *very* easy. Today's definitely is. I wonder if part 2 will have any depth.