Rochus

Working for the Company?

It's outrageously expensive. And you can't just buy what you really need, just all or nothing. In many projects I only need Qt Core; for that I would have to buy a license for everything fro…

Thanks for the hint. Didn't know it. As it seems it is no longer Qt. They once started with Qt (don't know which version) but they have "completely diverged" as they say. The goal …

It's not as big as Linux, Chromium, Dart and others. All of my projects are still compatible with C++ Qt 4. I'm able to and I will maintain it as soon as someone is estabilshing a free fork;…

Yes, exactly. You have my vote and my support in case the Qt framework will be forked based on the LGPL 2 versions and continued from there independently of the Qt Company. Here some figures: Nokia bo…

It's not my site, and actually the proponents of pharo and smalltalk should have best interest that their language is optimally presented.

LGPL was decided by Nokia who bought the IP from Trolltech for ~150 Mio $ and also came up for the development costs up to Qt 5.1. Digia and The Qt Company "bought" the IP for about 5 Mio $…

Ok, I see. It's a pitty Pharo is not on the diagram.

Thank you for your detailed, interesting answer. I look forward to reading the referenced papers. At the moment I am building frontends for LuaJIT and would like to compare performance with analog imp…

In what respect is it different? What did you intend to show?

I already posted the link in my comment.

That's interesting work, thank you very much. I would be very interested in the performance gain in using the GraalVM JIT compared to the original Squeek (Cog) or e.g. VisualWorks the performance…

If you can measure you don't have to imagine.

Well, weird benchmarks are probably all those where your favorite language doesn't look good ;-)

If you need another speedup consider LuaJIT which is used at CERN for heavy number crunching and data analysis, see http://cds.cern.ch/record/2157242?ln=de . E.g. on slide 14: Lua…

No. It's not designed for that. It was designed as a minimal lanuage focussing at the bare essentials required to implement a minimal operating system with graphical user interface.

Right. The whole point of Oberon is being as simple as possible. If you need all the fancy stuff introduced with Oberon-2 or Active Oberon (which are not the same lange as the one designed by Wirth) t…

Thanks, interesting. But so far I don't see such a big advantage over LuaJIT or the Lua language that would justify creating a new, incompatible fork. It's just another variant, not necessar…

Does your fork base on LJ 2.0 or 2.1 beta?

I had also a look at RaptorJIT. But as far as I understood it only runs on x86-64, not on x86. Or do I have a misunderstanding?

I don't think this work fits your needs. Have a look at something like https://en.wikipedia.org/wiki/NodeMCU or http://www.eluaproject.net/ or https:/…

Thanks for the suggestion. I think mostly people who want to use LuaJIT as a backend for another language, not primarily Lua programmers, might be interested in my work. Here is an article describing …

Oberon is very well suited for experiments; the language is so minimal that it is quite easy to write a compiler. Here is e.g. a front end for LuaJIT: https://github.com/rochus-keller&…

Great work, many thanks to WD. As far as I see only a subset of the SystemVerilog features is used. Is there a "coding standard" somewhere available specifying this subset with a rationale? …