The playground does not work

[certik]

First it took about 30s to show the result, then I clicked on Run again and got:

This is not a good first look of Fortran newcomers who just want to test Fortran out.

Instead, why don't we use and invest in https://dev.lfortran.org/ ? It's been working non-stop for almost a year, it is very fast (immediate) and it is getting better with every LFortran change. We can have a version being hosted under fortran-lang if there is interest.

[Shaikh-Ubaid]

First it took about 30s to show the result, then I clicked on Run again and got:

Yes, I also faced similar issues. It significantly affects the user experience.

[milancurcic]

See #47. In short, creative users can run programs that eat CPU for fun. The backend is running on a free VM that gives us a fraction of a CPU to work with, so it spends a lot of time throttled. That's why you get very slow responses or even a bad response from the server. Until it's properly secured, the backend relies on users playing nice. I agree it's not a good first experience.

Yes, https://dev.lfortran.org is great. What exactly do you mean by invest in it? Of course, it doesn't need to be instead. I welcome and encourage people to contribute to both projects.

Regarding the playground that play.fortran-lang.org points to, I think that's a good idea. The best playground should be pointed to from the website, and it's obvious to me that right now that's the LFortran playground. Why don't you open an issue in the webpage repo and gain support there, and we'll easily switch over?

[certik]

@milancurcic what is the path forward with this playground to make it fast and responsive and robust against errors such as the above?

For example, the only roadblock against dev.lfortran.org is the maturity of LFortran. You can follow our progress at https://github.com/lfortran/lfortran/issues/1251, and it seems convincing that this roadmap will lead us to the finish line of delivering a playground that is fast, robust and feature complete. And so it makes sense to do this work.

The roadblock for this playground is not the maturity of GFortran, but rather how to run it. So if you could formulate a similar roadmap that will lead to success, then it makes sense to follow it. For example https://godbolt.org/ works great, so it is possible. I am guessing there is some upfront work, and then some maintenance work.

[milancurcic]

Tackling #34, #43, #47, #48, #54 would get it far. There's not much ongoing maintenance needed. VMs are quite stable and robust nowadays. I have a production server that's had no downtime in almost 5 years now.

[arteevraina]

Tackling #34, #43, #47, #48, #54 would get it far. There's not much ongoing maintenance needed. VMs are quite stable and robust nowadays. I have a production server that's had no downtime in almost 5 years now.

Hi @milancurcic , @certik Are there any plans to have this project in the upcoming GSoC again ? Basically, to allow the potential contributors to tackle the above issues & any features/fixes we can plan for.

[milancurcic]

I had thought about it but didn't end up including it, for the simple reason that it may be difficult to define the project with clear goals and deliverables. The current playground is more at the state of needing tidying and fixing-up kind of work across the board--backend, frontend, and content (tutorials, alternative compilers, and similar). So I don't necessarily want to push it as a dedicated project idea, but if there comes up an applicant with interest in it, we can consider it. It would probably not be a priority over some new projects.

I may just take one quiet weekend to dive in and take care of most of the current performance issues. It's not a lot of work needed, just needs some careful thinking through and planning.

[certik]

We should join efforts on the two projects (playground + dev.lfortran.org), if at all possible.

[milancurcic]

Here are a few ways that I see integration as possible:

1. The key reason to have a backend is to allow running compilers that can't run in the browser (all of them except LFortran). The playground currently runs only GFortran, but it's a relatively straightforward to provide options to run other free compilers like ifort, ifx, flang, and lfortran. It's not a research problem but a matter of putting existing and well known pieces together. In case of LFortran, the playground could simply load it (as it's done on dev.lfortran.org) and run it in the browser instead of making HTTP requests to the backend. This could be a good advertisement for LFortran because all other compilers in the selection would take a significant fraction of a second (or even a few seconds) to upload the program, compile it, run it, and return the response, whereas LFortran would compile and run it instantly (assuming a sufficiently simple program).
2. Share the frontend and integrate complementary features. For example, dev.lfortran.org's examples gallery is very nice to use. The playground on the other hand has a tutorial capability. An integrated frontend would have both features, and of course, it would be one frontend codebase to maintain.
3. Share the examples and tutorial content--this is naturally part of the frontend, but could be set up as a static database of content (say, as a JSON and Fortran source files) that can be accessed from any frontend, even some new experimental frontend that somebody might be developing.

[henilp105]

@milancurcic it seems that the playground is not working. can you please reboot it ?

[milancurcic]

Thanks @henilp105, I just did and it runs again.

If you or anybody else would like admin access to our AWS account, let me know by email and I can add you.

I tend to notice all emails from GitHub, but I get many every day and can miss some (this one I noticed later). The best way to reach me quickly is a DM or a chat message on Fortran Discourse, for things that aren't actual code issues of course.