certik

Please go ahead, that would be great. The output of this script: https://github.com/certik/slabikar-otf/blob/dce9fc9e575f7d6e... creates a single line SVG. The other scripts then feed it to Inkscape and read it back as outline, so you would skip this step. You can then use this script: https://github.com/certik/slabikar-otf/blob/dce9fc9e575f7d6e... to convert to glif and the rest of the pipeline to build the font. I think I implemented single line fonts in glif.py, but if not, it shouldn't be hard to implement. If you are interested in collaborating on this, please let me know, we can add it as another job at the CI to test this mode.

Do you have a plotter? Send some videos and photos once you get it working!

Yes, we can! Can you please submit a pull request here: https://github.com/certik/slabikar-otf, just add the new character definitions here: https://github.com/certik/slabikar-otf/blob/dce9fc9e575f7d6e..., here is an example how uring (ů) is done: https://github.com/certik/slabikar-otf/blob/dce9fc9e575f7d6e....

Indeed! The above cursive is a Czechoslovakian style from 1990s (I think it hasn't changed much since then), and most European countries have quite similar cursive. In the United States the cursive is actually similar also, but a few letters are different, notably: z, r, t and most uppercase letters. My kids learn it at public schools here in the U.S., but it is secondary after print style and assignments are not accepted in cursive... (I am sure it varies from school to school though.)

I created this cursive handwriting OTF font that you can test in a browser (or any other program):

https://certik.github.io/slabikar-otf/

It correctly connects letters and it can do Czech and Slovak accents. It is based on a Metafont source (to be used in TeX) from Petr Olšák, I wrote Python code that reproduces Metafont's Bezier curves algorithm, generates curves as SVG, then calls Inkscape to convert the curve to its boundary, imports back into Python from SVG and then it generates OTF curves and the final font.

Dear Vivek, thank you for the note. I am the original author of SymPy. Most people who work on SymPy myself included do it in our free time. So far this has cost many hours of my and many other people's free time to try to figure out what is going on and to get this resolved. I also personally reject your allegations against us.

I thought about this situation and how your company could make this right. If you would be willing to help improve the SymPy project, I think it would be very well received. If you are interested, please let us know! See Travis Oliphant's reply, you could for example donate some money to NumFOCUS. We are very good with using money that people or companies donate to fund development and we can really boost SymPy forward big time with a generous donation.

Co-author here. If you have any feedback on our work or any questions, please let us know. I'll be happy to answer.

I am a Fortran advocate, but I don't complain that people use C++ or Python. I use C++ and Python myself, both are great languages. I agree Fortran is missing the library ecosystem, and that is why we started fpm. It takes years to fix this problem.

Also with LFortran (https://lfortran.org) being interactive like Julia, our hope is that it will allow to prototype directly in Fortran.

(I am the original author of LFortran.)

Indeed, I expect it will be newcomers to Fortran from languages like Python, Julia or Matlab who will really like LFortran once it matures. We are working very hard on it and are close to compiling real world projects, you can follow our progress on MVP here:

https://gitlab.com/lfortran/lfortran/-/issues/313

Current Fortran programmers might not always appreciate the interactive part, but I think they will also like LFortran as another independent compiler and for some of its features once it matures (such as C++ translation, fast compilation, good warnings, automatic wrappers to/from Python, etc.).

Thank you. I agree with all of this, and that is precisely the reason why I decided to get involved to make things better. To fix all of the above I believe we need:

* Much better tooling and more organized community, thus we started https://fortran-lang.org/ and the associated projects (fpm, stdlib, ...) and discussion board (Discourse)

* Better compiler that has good support for all Fortran features, and can help with linking and using C++ and Python libraries (automatic wrappers both ways), better optional warnings (to prevent old style code), good support for GPUs, etc. Also interactive like Python or Julia. I started LFortran (https://lfortran.org) to fix that.

* Perhaps some improvements to the language (I joined the Standards Committee and I encourage people to join). We have a subgroup for generics (templates). The hash maps should probably go to stdlib first, later we can think about putting them into the language itself.

This issue of separating a build system and a package manager vs lumping it together is a key design decision. We chose to follow Rust's Cargo, which lumps it together. It seems like a wrong decision at first (for the reason you stated), but we feel it is actually the right decision: from the user experience it feels much more natural and robust. I was not sure at first, but after playing with Cargo and Rust, you realize that this is the way to go.

I don't know what exactly is going on, but last time I looked into it, it seemed the main difference between the codes was how quickly you can do 1/sqrt(x). Ultimately, I would like to see more numerical benchmarks and also compare more versions in a given language.

We started a repository for it:

https://github.com/fortran-lang/benchmarks/

But didn't have time to work on it yet. See the issues, e.g., at:

https://github.com/fortran-lang/benchmarks/issues/2

For some discussion how to best do that.

The first version was actually in Rust, then Haskell and finally in Fortran.

It sounded like a crazy idea at first, but then we discussed it and realized this is exactly what we should do. It makes perfect sense.

There is also LFortran, an interactive Fortran compiler:

https://lfortran.org/

Which has multiple backends, besides the default LLVM one, it also has a C++ backend (to translate Fortran projects to a readable C++), and once MLIR matures, we'll add an MLIR backend also.

(I am the original author.)

Good catch! Thank you:

https://github.com/fortran-lang/fortran-lang.org/pull/230

I've seen a similar change in recent years. 10 years ago Intel Fortran was usually faster, at least 20%. Good 20%. GFortran seems to have caught up a lot.

Author of the blog post here. There are two Flang compilers:

https://fortran-lang.org/compilers/

The legacy Flang and a new Flang. I don't know exactly the plans for the legacy Flang, but I assume the idea is to eventually use new Flang. The new Flang and LFortran where started at about the same time, they have a little bit different design. Both written in C++. LFortran has from the ground up written to be interactive (like Julia or Python), in addition to regular compilation to binaries. Some of the other goals of Flang and LFortran overlap.

I think it's good for Fortran to have at least two actively developed open source compilers.

There is speed of compilation (I did some very preliminary benchmarks and I think it will be very good) and there is speed of the generated code, there currently we just use stock LLVM. But down the road we will have special optimizations on top, just like Intel Fortran is doing. Some of the things I personally would like to have a close look on is array operations, where I've heard from many users that they are slower than explicit loops. And function inlining and other such operations.

We want to have a dedicated repository for benchmarking compilers:

https://github.com/fortran-lang/benchmarks/issues/2

Next time. ;)

Indeed. Intel Fortran is generally considered one of the best. It was not cheap, but it is now available for free. In general I think there is a huge opportunity for new compilers, and I have started one such effort myself: https://lfortran.org.

LFortran is not ready yet for production usage, but I've been developing it on M1 Macs, everything works (both compiling of LFortran itself, as well as LFortran compiling other codes and interactive usage in Jupyter). It compiles really fast and I really enjoy the experience of M1.

Author here. Yes, some people did not like the title, I didn't realize that it necessary means Fortran was dead. I meant it in the way of "rejuvenate". Fortran was not dead.

Great question. Here are some candidates:

* https://github.com/rswier/c4

* https://github.com/Fedjmike/mini-c

* https://github.com/rui314/8cc

* https://github.com/rui314/chibicc

* https://github.com/aligrudi/neatcc

Some of them are actually interpreters, and I personally would be interested in actual compilers that generate machine code.

Yes, once MLIR is more mature, we plan to have a backend for LFortran to also use MLIR.

Thanks for the benchmarks. Do you see some intrinsic reason why a Fortran compiler couldn't do these optimizations? I would think it would know all the information so it would be the ideal place to optimize it.

LFortran author here. We will get there. I spent a lot of time in the last year bootstrapping our efforts around https://fortran-lang.org/, which was very successful. I have shifted my focus on LFortran again now.

That has been requested quite often: https://gitlab.com/lfortran/lfortran/-/issues/97

LFortran author here. I missed one of these discussions.

LFortran author here. There is a Python prototype version that you can see in the notebook and it has very limited support for arrays. I stopped spending more time on it once I got further enough to validate that the idea works. And I am now spending all my time on the production LFortran implementation in C++. I am very close to make it usable for some very simple things, and then we'll go from there.