State of Magic Lantern development

[apalazzi]

Hi,

I've started using ML to do some astrophotography and I'd like to use the astro module https://www.magiclantern.fm/forum/index.php?topic=18515.0 ; so I'm trying to compile ML for my camera (EOS 500D) however the official "unified" branch has not been updated in years (and it doesn't compile) and it's not clear which branch is best to use - maybe lua_fix ?

So, is ML still in development? Are the original developers still around?
And which branch should I use to start developing myself?

Thanks
Andrea

[kitor]

Main repository is pretty much abandoned, yes. There are many custom builds for different models - each maintained as a fork of main repo, but not for 500D as it is a pretty old model.

There's also our repository, where we try to bring up support for Digic 6 and newer models: https://github.com/reticulatedpines/magiclantern_simplified/
But it is probably not what you want as we just try not to break older models when possible, but have no way to really test that.

Your best bet is probably lua_fix or crop_rec_4k branch from the main repo.

[names_are_hard]

Hi, I maintain the reticulatepines repo, we do have a few contributors - so that's probably the most active repo.  As kitor says, it's not designed for older / well supported cams, *but*, some testing has been done and no problems have been reported so far.

That repo is a combination of multiple branches: lua_fix, unified, qemu (no longer relevant), digic6-dumper, and maybe some more I forget.  It doesn't have crop_rec_4k.  I've made several bug fixes that should improve older cams.  If you want to contribute code and you're not afraid of doing some testing, *and* you don't need crop_rec, I think it's a good repo to work on. 

It's the easiest repo to build, because I updated it for more modern systems.  I also understand the build system enough that I can help people get it working, and, I want to keep it working.  I can walk you through getting it building.

If you just want ML with some changes to one module, then yes, I'd recommend lua_fix branch from heptapod.  It will build - but it won't be easy to build.  You will want to use an older linux distro to build it, something that ships with gcc 8 would be around the right age.

[JOELwindows7]

Hey, also if you'd like to try that reticulatedpines repo above, I have prepared this Virtual Machine for you in case you need it

https://www.magiclantern.fm/forum/index.php?topic=26791.0

Basically, it works (I've tested, and figured days before) on this exactly Debian version Bullseye. And this VM already had all the relevant source codes cloned for you.

Oh yeah, if you have Windows at least 10, you should try Debian WSL instead! Also works. You just, clone it up, install some dev packages, cd to the repo, and then platform folder, which model you had, pick one that matches, make zip & that's it!

And if you got something to edit, feel free to fork that, make your edit, pull request back to that.

[names_are_hard]

I made that repo

I strongly recommend *not* making a VM that has the source code already included.  This guarantees that people are using an old version.  I will be updating from Bullseye in the near future, so this may also break a specific VM.

What would be better is determining why some configurations don't work well, and improving detection / configuration at build time.  We want to support building on multiple platforms.

[petabyte]

Agreed. A configure script would be very useful. I had made a half-finished PR to do that a while ago: https://github.com/reticulatedpines/magiclantern_simplified/pull/75

[names_are_hard]

Yup, it's a good idea but it's quite a lot of work, especially when you consider Win / Mac / Linux.  I think the current situation is actually okay, the problems you encounter are standard C developer things and pretty easy to work through.  It could be improved but it's not a barrier to entry to people that are already good devs.  It does make things harder for inexperienced devs, so it's worth improving.

[apalazzi]

Hi, I maintain the reticulatepines repo, we do have a few contributors - so that's probably the most active repo.  As kitor says, it's not designed for older / well supported cams, *but*, some testing has been done and no problems have been reported so far.

That repo is a combination of multiple branches: lua_fix, unified, qemu (no longer relevant), digic6-dumper, and maybe some more I forget.  It doesn't have crop_rec_4k.  I've made several bug fixes that should improve older cams.  If you want to contribute code and you're not afraid of doing some testing, *and* you don't need crop_rec, I think it's a good repo to work on. 

It's the easiest repo to build, because I updated it for more modern systems.  I also understand the build system enough that I can help people get it working, and, I want to keep it working.  I can walk you through getting it building.

If you just want ML with some changes to one module, then yes, I'd recommend lua_fix branch from heptapod.  It will build - but it won't be easy to build.  You will want to use an older linux distro to build it, something that ships with gcc 8 would be around the right age.

Hi,

In the meantime I've managed to build the "unified" branch included with the astro module, tanks also to various posts on the forum.

The next step would be to test your git repo and see where it stands in terms of compilation errors etc... Do you think there's a concrete risk of bricking my camera or it should be reasonably safe to load the firmware on my 500D?

How do I run the test suite? Do I need to setup a QEMU VM ?

Bye
Andrea

[names_are_hard]

The next step would be to test your git repo and see where it stands in terms of compilation errors etc... Do you think there's a concrete risk of bricking my camera or it should be reasonably safe to load the firmware on my 500D?

How do I run the test suite? Do I need to setup a QEMU VM ?

A risk?  Sure.  That's true of any ML repo.  I don't think mine will be significantly higher risk than other well tested ones, we haven't changed much for older cams.

Run what test suite?

[apalazzi]

A risk?  Sure.  That's true of any ML repo.  I don't think mine will be significantly higher risk than other well tested ones, we haven't changed much for older cams.

Sure, there's always a degree of risk with any ML repo, that's why I used the words "concrete risk" and "reasonably safe". Based on your answer, I take it that it should be "reasonably safe" to use your repo.

Run what test suite?

I remember that something about a test suite is on the ML site pages... am I wrong?

Bye
Andrea

[names_are_hard]

Okay, it's hard to quantify the risk, since it hasn't been tested on your cam.  Hard for me to know if my "reasonably" is the same as yours

There was a test suite that runs in Qemu against various cam roms.  E.g., here: https://builds.magiclantern.fm/jenkins/view/QEMU/job/QEMU-nightly-tests/

I don't have access to that server.  You can attempt to run those tests locally, but they won't pass.  Your rom will be in a different saved state to the rom on that server, so you'll fail many tests.  I'm writing a new test system that will be more resilient, fix some bugs, and most importantly: describe what the tests do so it's possible to add new roms.

There's also the selftest module, that's more useful for testing a single cam and I'd be interested in a comparison of that for heptapod vs my repo.