Total rebuild of the code?

Started by Harbinger, November 15, 2008, 01:34:07

Previous topic - Next topic
Print
Go Down Pages1
User actions

Harbinger

November 15, 2008, 01:34:07
Y'know, perusing the Bugs board, i've noticed a lot of bugs that sprang up from the .52 build. I know when the dev(s) put in fixes and features, from what i understand about the "tightness" of the code is that sometimes you never know where one solution will cause problems somewhere else, hence the bugs...

So the natural question that came to my mind is, has any of our coders thought about totally recoding MPT, using its important functions to do what makes MPT great? Is the enormity of the project greater than the time that the devs have? What has been the discussion so far?

Sam_Zen

#1
November 15, 2008, 01:45:47
I think I understand your point.
One can repair some occasional problems of a system, but there comes a point where there are too many workarounds, band aids, elastics and paperclips.
So it could be more efficient to take a step back in the process, and rewrite some basics in the first place.
0.618033988

psishock

#2
November 15, 2008, 03:39:39
that's enormous work Harbinger, we get "trouble" with "minor" feature/bugfix requests, no one would dare to rewrite the code from scratch afaik. Even the source code was almost completely undocumented when it went open source, i believe it still got some unsure parts.
I'm as calm as a synth without a player.  (Sam_Zen)

LPChip

#3
November 15, 2008, 11:14:58
I have suggested to rewrite OpenMPT from scratch several years ago, and although all the devs were enthausiastic in what I was suggesting, it never got of the ground.

The motivation behind my suggestion was to get the code modular, so you can easilly work on the code and even possibly, only compile one module and distribute that as an update, rather than having to do a complete compile. That would allow better multi-threating and it could possibly get is leave the VS .net 2003 dependencies.

That would also give us the oppotunity to get a newer interface, etc... It never got of the ground because it is just soo time consuming.
"Heh, maybe I should've joined the compo only because it would've meant I wouldn't have had to worry about a damn EQ or compressor for a change. " - Atlantis
"yes.. I think in this case it was wishful thinking: MPT is makng my life hard so it must be wrong" - Rewbs

Saga Musix

#4
November 15, 2008, 11:22:26
modplug is a really big software and it's been developed for more than 10 years now. You can't just rebuild it from one day to another. not even from one year to another, i think.

Harbiger, do note that all those bugs are NOT only appearing in the .52 release, that just indicates the version the bug reporters used! Several bugs I reported (and fixed) are still from the good ol' MPT 1.16, yet i filed them under ".52" cause i use that for tracking (or rather my custom .53 build 8)).

but if you want to do so... go ahead! :nuts:
» No support, bug reports, feature requests via private messages - they will not be answered. Use the forums and the issue tracker so that everyone can benefit from your post.

älskling

#5
November 15, 2008, 12:14:32
What Jojo said. The version number doesn't necessarily mean the bug was introduced in that version, it simply means that whoever found the bug was using that particular version. The "new" bugs that are introduced with new features or fixes of old bugs are usually (if found) resolved rather quickly.

In my experience, the latest version has (with some eceptions... ;)) always been the most usable one.

Relabsoluness

#6
November 15, 2008, 20:32:45
[Note: The thread was moved to Development chatter]

Quote from: "Harbinger"So the natural question that came to my mind is, has any of our coders thought about totally recoding MPT, using its important functions to do what makes MPT great? Is the enormity of the project greater than the time that the devs have? What has been the discussion so far?
Personally I would be rather strongly against rewriting ideas without been given very good justification. A few thoughts about this:

-It would be very time consuming and would need a lot of expertise which few hobbyist developer have. And if there were competent developers at every corner, I'm sure OpenMPT would have more skilled lead dev at the moment.
-There are no one working on OpenMPT code full time; implementing such huge changes doesn't sound like a thing that many would do just for 'fun' besides day job.
-Would the rewrite project ever finish? My not very glamorous view of many open source projects is that eager people start implementing some unrealistically large plans that just fade away because they have better things to do. For example history of Psycle is rather interesting to read from this perspective.
-Uncertainty on the result. After spending a lot of time rewriting the code, what would be the result compared to that situation that the same time would have been spend on developing new features on the old code basis?

Quote from: "älskling"What Jojo said. The version number doesn't necessarily
mean the bug was introduced in that version, it simply means that whoever found the bug was using that particular version.
Indeed, I took a quick look at .52 bug reports -- none seemed to be new to .52.

Quote from: "älskling"In my experience, the latest version has (with some eceptions... ;)) always been the most usable one.
In case you remember, what would be the exceptions (besides .50)?

Harbinger

#7
November 15, 2008, 21:37:48
Constructive and wise counsel from someone who knows. Thanks Relab.
I guess it's the one huge flaw of open-sourcing -- end-users are pretty much stuck with the original app with only minor modifs made by hobbyists or people with an actual RL... :?  I've found that open-sourced programs, while allowing them a "second life", tend to stifle new apps (of the same kind) for the same platform.

Someday somehow that will change, perhaps by introducing a small profit motive....who knows.....

Saga Musix

#8
November 15, 2008, 22:09:33
Quote from: "Harbinger"I guess it's the one huge flaw of open-sourcing
Oh, so you think that it would have been better if Olivier would have let rottened the modplug sourcecode over the years? He didn't have the time to maintain this huge project anymore, so it's a very good choice that he opened it to anyone!
» No support, bug reports, feature requests via private messages - they will not be answered. Use the forums and the issue tracker so that everyone can benefit from your post.

älskling

#9
November 15, 2008, 22:23:53
Quote from: "Relabsoluness"In case you remember, what would be the exceptions (besides .50)?
I think mixmode 1.17RC1 was an exception (1.17RC2 is great), and before that there were some annoying bugs in 1.16.0215a and .20040910

Other than that, it's been a smooth ride.

Harbinger

#10
November 15, 2008, 22:37:05
Quote from: "Jojo"
Quote from: "Harbinger"I guess it's the one huge flaw of open-sourcing
Oh, so you think that it would have been better if Olivier would have let rottened the modplug sourcecode over the years? He didn't have the time to maintain this huge project anymore, so it's a very good choice that he opened it to anyone!

Seriously dude, chill. I said it was the ONE huge flaw. There is a trade-off for everything, which everyone must learn by experience. I'm glad he did leave it available, because we can't be sure anything better would have been born. I'm NOT complaining...

Relabsoluness

#11
November 16, 2008, 01:39:51
Quote from: "älskling"I think mixmode 1.17RC1 was an exception (1.17RC2 is great), and before that there were some annoying bugs in 1.16.0215a and .20040910.
Impressive memory :)

älskling

#12
November 16, 2008, 08:21:21
Quote from: "Relabsoluness"
Quote from: "älskling"I think mixmode 1.17RC1 was an exception (1.17RC2 is great), and before that there were some annoying bugs in 1.16.0215a and .20040910.
Impressive memory :)
No, impressive search for "ganja" in history.txt.
Print
Go Up Pages1
User actions