Fortran playground

The WASM backend in LFortran is less capable than the LLVM backend (which supports allocatable). Our plan is to first get the LLVM route to “beta” quality, and the WASM backend will catch up.


As your tests indicate, the sites vary widely in capabilities; but each has strengths – a particular compiler, versions, the abilitity to import and export projects, fortran prettifiers, various debug abilities. I do not think any automatically “modernize”. Some allow for more cores or larger codes than others, … I wish Discourse could be used to evolve documenation from discussion to FAQ to group wiki document, ultiimately ending up as an article on fortran-lang or the Fortran WIki; but it does not. The list would definitely benefit being turned into a table with an indication of what compiler(s) are supported. I just now experimented with making it into a numeric poll so people could rate their experience with the site, which I think would be useful. I know of no way to add a poll to the Fortran Wiki. Thanks for the review of the sites; but I agree the list of itself in not all the information needed to make efficient use of them. Browsing them does give some good ideas of what would be good to add or not add to the fortran-lang playground at a minimum.

@urbanjost go ahead and send a PR to the webpage, where we can maintain this list where to run Fortran code online.

I like to be broken record and point out ad infinitum, the Fortran playground would do well to showcase the language.

Ideally it will support everything a current language standard has to offer, its syntax and semantics.

As such, it should adapt quickly to employ whichever processor on the backend that comes closest to conforming.

1 Like

This is probably loading infinitely again. I wonder what could be causing it.

I would like to help fix it. If we get it to work, I am curious to know how many simultaneous requests/users would we be able to handle?

Thanks, Ubaid. It seems to be back up now.

The server (gunicorn) is fast and concurrent and can handle 1000s of requests. The bottleneck will be in the compiler + Fortran program workload. If we run it on one full CPU, and the user submits a program that takes 1 s to compile and run on one CPU, the server will be 100% busy for 1 second. Many other users can submit programs at the same time, and the server will field them, but separate compiler and program processes will compete for the CPU.

I think the recipe for a robust and working playground server will be a balance between sufficient CPU resources and restricting jobs to sufficiently short compile+run time, and of course forbidding spinning off OS processes from the Fortran program.

1 Like

Great, Thank you for the clarification! It is really helpful.

It seems one of the primary concerns that limit the playground to reach more people could be the availability of the compute power. Since we have 1 CPU, I guess not many people could be able to use it simultaneously. I did some exploration around the various options available to us for deployment. I found It seems to be free to use (I think unless we hit a million users a month). I find the features it offers attractive. At Pricing, they share:

If you release an app via Deta Discovery, you can already make your app massively available to people all around the planet, without having to think about infrastructure or costs.

At Terms and Conditions, they described their soft limits. They are as follows:

  • For the Free Tier (on monthly basis):
    • Deta Drive
      • 5 GB storage
      • 70,000 read requests
      • 30,000 write requests
    • Deta Base
      • 250 MB of storage
      • 70,000 read requests
      • 30,000 write requests
    • Deta Micros & Space Applications
      • 500,000 requests
      • 10,000 GB-Seconds of compute
        • A GB-Second is the amount of memory provisioned to a Deta Micro multiplied by how long it runs. E.g. a Micro that has 500 MB of memory and runs for 2 seconds consumes 1 GB-Second.

Do you think we can use this to deploy the playground?

1 Like

Probably yes, but before worrying about scaling up for many users I suggest first focusing on fixing known software issues and getting it to work robustly on a small server.