Lets work our way to a new stable release.

Started by Audionut, April 20, 2013, 03:32:40 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Audionut

engardeknave, while I respect that you have concern for the developers, ultimately, they are capable of deciding where they spend their development time.

I have a strong desire for keeping the development section in a manner suitable for development, and it is for this reason that I kindly suggest that members place serious thought into the manner in which they post in this thread (and other development threads) in the future.

g3gg0

about exceptions implemented using setjmp:

never ever. no setjmp/longjmp. http://www.abxsoft.com/misra/m122.html
its forbidden in serious guidelines for reason.

(although i dont really understand why we need exception handling. looks like an answer to a question that was never asked)
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

Des219

engardeknave, my whole reason for posting the suggestion was for the developers to save them time and energy in the long run.  From reading the thread and a few others about Tragic Lantern vs Magic Lantern, it looks like there is currently a challenge with new camera models, new features, and getting them all into a single release.  The typical question that is asked is when will the next stable release be available?  This is frustrating for the developers and for the users.  If it were feasible to release single features as they become stable that would be a huge benefit to the developers and the end users.  Again, the developers are doing a great job and are devoting their personal time on a free project.  I was proposing a possible solution to help for future releases.

Unfortunately I do not currently program in C or C++ so I am not comfortable altering code that I am not sure is stable for my $2000 camera.  Also, I only have one camera so I would not be a good candidate for cross model programming.  It also is very difficult for someone to jump in on the project without discussion with the main developers.  Which is why I posted here.

g3gg0, I appreciate that a developer has looked at this.  Thank you!  I see that the try/catch option with setjmp was not a good one.  This is good to know.  Since I have your attention, my original post was suggesting to have the main features in a standard class that called wrapper functions to camera specific functions.  The attempt of the try/catch would be to call functions and if they are not developed then display that this feature is not yet available.  The logic was to implement features as they become stable.  Would this be beneficial to you as a developer?  Would you also see benefits for the end users?

g3gg0

the problems we currently have, are not related to any language based solutions.
even with C# or any other high level language we would have any advantage.
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

Des219

Quote from: a1ex on April 20, 2013, 05:51:31 PM
- Backend stuff: we are pretty close to the limit of how much RAM we can use (how many things we can cram inside). Module system (under development) will improve this. This can be for 2.5 if you ask me, but g3gg0 would like it earlier.

- I'd like a boot process that supports all cameras with a single download (like the unified 2.3 zip). The current approach does not scale to the new models (it requires a huge fat binary containing the code for all cameras). I'd like a small platform-independent bootloader, the camera-specific modules (ML core), and user modules (functions that are only loaded on demand; usually platform-independent code).

My solution was inline with the above.

Quote from: g3gg0 on February 02, 2014, 11:54:19 PM
the problems we currently have, are not related to any language based solutions.
even with C# or any other high level language we would have any advantage.

Totally agree that a higher level language would not be the solution even if it were possible.

Des219

One more thing... sorry if my suggestion insulted anyone's intelligence.  I was only making a recommendation based on the perceived problems I had read.  It wasn't that I thought the development team was unaware of the possibility of wrapper functions, it was just that they were not initially used and possibly were overlooked since the project had grown so quickly and successfully from the initial implementation.  If anyone wants to discuss this with me I would be glad to assist in anyway that I can.