after almost 1.5 years since the last release (MOE 1.4.4) we are reviving the Multi-OS Engine project. We started working on MOE in 2013 (back then it was called Migeran for iOS), and it will always have a special place in my professional life. Therefore it is my great personal sorrow, that we have left the project without maintenance for so long. I don’t want to delve into the past why and how this could happen. Instead let’s look into the future, and see how we can make sure that this does not happen again.
That’s some great news! Now it’s first on you to keep your promise but I’ll trust you
Will the repository also undergo some changes, like taking all the tiny repositories which currently have only one file in it and combining them into one big? (Except the website repository of course)
Happy coding!
Can’t wait to read further news and probably start contributing on the community repository!
Yes, we are planning direct Swift support with Nat/J v3. I will write more on this in the next update, but just to manage your expectations, I think it will be ready only end of Q2 2020. It requires a complete overhaul of how Nat/J works, and how the different languages are plugged into it. We plan to do the development in the open, so contributions will be very welcome.
@kisg are you planning to improve on the source code mapping back to exception stack traces?
I have several kinds of mysterious crashes in MOE internals that only happen at the user’s devices, so I only have crash reports pushed to Fabric and they aren’t that helpful.
Yes, it would be nice. Of course it is also a lot of work, so contributions will be very welcome.
The VM landscape has also changed a lot with the arrival of SubstrateVM from the Graal project.
One of the strengths of MOE is its modularity. When we started its development, it was an important design decision, that the VM can be replaced if something better than Dalvik (at the time) comes along. So we switched to ART when it became open source almost right away.
I am interested in taking MOE into a direction, where multiple Java runtimes are supported (ART, MobiVM, SubstrateVM, … etc.) and the developer can choose the best fit for her project.
I will write more on this in an upcoming MOE Update post. I am also very interested in your take on this, so I hope that there will be a lively discussion in the comments.
Not sure if anything had changed since then and in any case, I’d be interested to learn how to interpret the current stack traces down to the root cause of issue. Some crashes may seem as issues in the generated code or some MOE runtime, but I can’t say for sure.
Just one quick update: we received the official consent (and CLA) from @Noisyfox to integrate his changes into the official release of MOE. I also invited him to become a committer in the MOE project.
Thank you @Noisyfox for all your work on MOE so far, and we are looking forward to many more from you in the future.
