Will the development continue?

[liquidscorpio]

The last commit reported is from April 2013 and there have been no interactions in issues either. Is there something (other than low-level programming) that can be done to revive it.

I really want MT3 to see the day light. :sun_with_face:

[irrenhaus3]

I've cloned this repo a while ago and I can kind of see why development died down on MT3 - the code is a giant bowl of spaghetti with very little documentation, there are function macros all over the place and there are a lot of custom implementations of sort algorithms, MD5 and so on. It's really more oldschool C than C++. Over all, not very pretty to maintain and refactor.
I'm currently going through every file, documenting each and every function and class, just to understand what's happening. Maybe I can contribute something worthwile once I understand this baby a little bit better.

[flibitijibibo]

It's really more oldschool C than C++.

Bingo.

MT3, from what I understand, is basically MT2 moved over to C++. This is basically why the code is incredibly difficult to read and still has things like asm routines... any sort of design that might have existed basically got thrown out by the move to C++, since it's essentially shoving one design into a largely incompatible language (as far as design goes).

This is probably why MT3 doesn't even really exist, because the move to C++ either didn't work at all or it didn't perform as well as the original, so we've got this different model of code development that also didn't work very well (it's hard to port something that never worked in the first place... I'm in the middle of doing something similar right now).

[liquidscorpio]

So how to breathe life into this project? I have tried a few FOSS alternatives, but the experience is not the same as MT2. In as much as, I would like to build an alternative, I have near zero understanding of inner workings of a tracker.

If this is not the code base that appeals to reason, then let us try to work a reasonable, even if, feature limited alternative.

I do not know if this would be a sane thing to do, given that there already is a (somewhat?) working code base. But then again, I do not really know how much this code will allow to be build upon nor do I know where to start if I want to start a fresh.

[AmEv7Fam]

I might be able to bring some life back into this project.

I've been gone for 2 years (I'll leave that to your imagination as to why), but I've learned a good chunk of Python in the meantime. I know, it's not a boatload similar to C(++), but I feel it should be able to help...

Now, I don't know how much time I'm going to be able to spend on this, especially with other responsibilities, but I'll see what I can do...

[AmEv7Fam]

Ouch. Forgot how bayad this code was in some places.

I do remember poking it at it a while ago, but ended up being royally confused as to what everything does.

I do remember we were in the process of removing duplicate code, but I can't remember how far Flibit and I got.

I'm wondering if the old SVN repo has some info we can splice out of it?

In the meantime, what I can do is get Travis, etc. set up, so that I don't have to fiddle with my buildbox, since I kinda messed it up 2 years ago, and family used the box for gaming (not that I'm complaining, of course, but constant random prodding by a brother who thinks similarly to you doesn't exactly help clean things up).

(Lesson learned: there is clearly a "wrong way" to "upgrade" WinXP to Win7/10 x64...)

[irrenhaus3]

I gotta say, going through this code and trying to understand it is akin to exploring the cursed tomb of an ancient egyptian ruler. It's nasty, full of booby traps and horrible things, but you really learn a thing or two about the thought process of the architect and how the entire thing even holds together. I'm having one epiphany after the other and I'm starting to get the first ideas of how to tackle the big refactor - at least for some of the more general features that could easily be abstracted by the platform-independant features of C++11 and things like boost::filesystem. I'll report status updates whenever I feel they're worthwhile.

[AmEv7Fam]

OK, Travis is up and running. For the most part, at least.

I'm going to poke at the SVN repo to see how the program evolved. I may not be able to fully write functioning C(++) yet, but if I can scrape Yannick's head from 15 years ago, that might be able to help us out.

[AmEv7Fam]

This still continues to be my biggest complaint: the MTfooNUMBER file system.

Problem is, we can't just merge the files, as that really wouldn't fix the problem.

@irrenhaus3, think you could get some commenting done as to what you find, and how things work?

[AmEv7Fam]

Poking at it again.

Ugh, the 2nd biggest issue is the obscure naming. I think what would help a lot is if we can figure out what the names are supposed to be/do, that would help a lot.

[AmEv7Fam]

Yet again.

Travis is up and running, and compiling for us now.

It looks like some of the functions that are being done are built into modern versions of the C(++) compilers.

Lemme find the link for the Windows-compiled MT3. I know I've got it somewhere, but it does show the code compiled at some point...

[AmEv7Fam]

OK, I've opened the Wiki up, so that we can contribute our notes as to what does what.

[irrenhaus3]

I mean, compiling this monster isn't really too bad, my GCC reliably builds it. It's the immediate segfaults that kinda get to me :D. My MO right now is to occasionally sit down and go through some parts of the code, committing my changes to a private repo so I don't meddle too much. I'm not only commenting, but making first small changes like replacing MTColor with a more sane version or commenting out completely unused functions. And I think there was an operator= overload somewhere that did nothing different from the default operator= except that it returned bool. Things like that. If that sounds like something I should push to a branch of this repo, let me know.

[AmEv7Fam]

Let's do a separate branch for now...

[AmEv7Fam]

OK, I've created the breaktofix branch for now, so we can mess around with the code without overly polluting the main branch.

[irrenhaus3]

That's pretty sweet. Can you give me write access to that branch?

[AmEv7Fam]

Done.

Prodding at GDB, this is what I get:

(gdb) run
Starting program: /home/ammon/NetBeansProjects/madtracker3/src/madtracker3 

Program received signal SIGSEGV, Segmentation fault.
0xf7d0cfab in readdir () from /lib/i386-linux-gnu/libc.so.6

[AmEv7Fam]

I think I figured out what's happening with that segfault...

Those who have used MT2 possibly know about the .mtx files. I talked with Yannick a while back, and he confirmed that they are just renamed .dll files. (Perhaps it would be best to re-write it to use standard .dll and .so?

What I think is happening with the segfaulting is Yannick's homebrew file management shenanigans aren't working, specifically, the *nix variant (can't say about the Win32 code, haven't been able to get it to compile to run).

[irrenhaus3]

I think I recognize that segfault too. I traced it a bit through the program and I believe it happens because the program attempts to read from a directory called "Extensions" that's supposed to be under the working directory. However, it neither creates the directory before trying to read it, nor does it search for it in any sensible way - it depends on a call to getenv("_") which will ALWAYS fail in a detached shell (e.g. your IDE). It then uses the result of this call without any error checking and segfaults immediately. I "fixed" the first segfault to occur because of this, but it only propagated up to a higher function which also did no error checking. This is definitely a part of the code that desperately needs our attention. :P

EDIT: As to why getenv("_") is unreliable, see https://gist.github.com/irrenhaus3/10d8c8ddc6c6135065d68c185370cf05

EDIT: You sure I have write access? My push just got rejected. ^^

[irrenhaus3]

I just got it to work. http://i.imgur.com/bO7Kydj.png So at least we have a MTConsole now.

EDIT: So what I think about the setup is, "Extensions" is where all the other MT3 modules go as soon as they're compiled into shared objects - MTSystem, MTAudio and all those. That's why mt3 itself doesn't create the directory, it's supposed to already exist at the start of the program. mt3 then attempts to initialize them at runtime and then makes use of their functions, if that succeeded - without any segfaults if it doesn't. Seems these are finally parts of the code that are sort of robust.

[AmEv7Fam]

Heh.

I guess I knew the line of code that it choked on, but I didn't go far enough the stack to find the offending code. Guess the code is somewhat solid, just it's obscure...

Edit: This is going to be interesting for packagers. It sounds fine to have the extensions in the ./Extensions/ directory for "portable" versions, but for installs, it could be problematic...

I think I remember a ~/.madtracker/ directory being created somehow. Perhaps the packagers could have it installed to ~/.madtracker/Extensions/, and code is updated to suit?

Nonetheless, I do agree that the segfault shouldn't be obscure like that...

Edit2: Whoops, forgot the 3 at the end of your username....

[irrenhaus3]

So I just pushed the first results of "work a bit every once in a while, commit after loooong time periods" to breaktofix. It's basically just a whole bunch of comments in lots of places, some small improvements and so on. I also modified CMakeLists.txt to compile with -std=c++11, -fpermissive, -Wall, -Wextra and -pedantic. -fpermissive NEEDS to be enabled with GCC, otherwise compilation fails because of pointer-to-int casts.

[AmEv7Fam]

Looking through your comments now.

Yes, each module was originally its own project, and each submodule is a library.

Fun fact: in MT2, MT2installdir\Extensions\foo.mtx is actually a .dll renamed to .mtx. Don't know why, but...

[irrenhaus3]

Yeah, that's probably another possibility for a refactor. I can't really imagine someone wanting to compile mt3 without the audio functionality, or the gui. ;)

[AmEv7Fam]

Yeah, the GUI folder is Win32 code. Not very portable as far as I can tell...

It almost looks like Yannick almost built... some sort of engine from scratch.

Still, I wonder if it's better to keep this "engine", or to refactor or port to another engine?

[AmEv7Fam]

Let's poke around MTSystem for a bit. It seems that, somehow, it's the module that manages the other modules. Kinda like the main module is the bootloader, and MTSystem is the OS kernel, I guess??

I don't know how Delphi is laid out, but I suppose that's where most of the layout of the program came from...

[AmEv7Fam]

The more I look at the code, the more I wonder how much of this could be condensed.

[irrenhaus3]

A lot, probably. At the very least we can get rid of

• The custom implementations of data structures like MTArray, some linked list stuff etc.
• The custom threading library, replacable by c++11 std::thread stuff
• The custom file utilities, replacable by boost.filesystem or, starting next year, c++17's std::filesystem
• Implementations of sort algorithms - std::sort over a range should be enough in almost all cases
• Win32-specific GUI and audio code which can be tackled via wxwidgets/qt/etc. and OpenAL
• Lots and lots of global data by proper encapsulation/interfacing (needs some TLC or else it'll get messy)
• A ton of macros that are just less type-safe versions of function templates

Quite a tall order, eh? I'm not too sure what's a good starting point, but since we already have a branch called break-to-fix, I guess it doesn't matter too much. ^^

[AmEv7Fam]

Heh. Finding that 200ish-line array was interesting. It was like, wat is dis.

Still, I'm going to port what I can of the GUI tomorrow into a temporary folder.

[AmEv7Fam]

I got some of the static interface ported into QT Designer. Have absolutely no idea (yet) on how to handle the dynamic interface, such as the tracking pages.

[irrenhaus3]

You just posted that comment 10 times, lol

[AmEv7Fam]

*facepalm*

Fixed it.

When i was trying to post it, I had no indication whether it was posting it or not. Now I know...