From: Florian J. <flo...@we...> - 2011-09-07 17:06:59
|
Am 07.09.2011 00:55, schrieb Tim E. Real: > On September 6, 2011 12:51:57 pm Florian Jung wrote: > >> Hi >> >> i think, muse's code is really, really quirky on many locations. >> how about cleaning all this up after releasing a working version? >> >> tim, sorry, but i think you're a bit of a messy ;) you never delete stuff >> ;) >> > Yeah I warned you, and apologized in advance. All that p4.0.22 stuff. I do go > back and clean up after a while. if you do this, that's okay ;) > It's not that I'm messy. The reason I do > that is so when I'm browsing a bit later I can see what the old code was and > whether the changes still make sense. > hrm. actually SVN is made for this. but YMMV, and it probably does in this case. > When you see code like that it means there was a lot of trepidation and > uncertainty so I keep the commented code, and for others to see as well. > Especially during the whirlwind switch to Qt4 when so much was being done > so quickly. i think, these QT3 -> 4 changes can be removed soon. at least in the often-used parts of muse. i mean, it didn't break till now, it won't break later, will it? > If it makes sense I clean up later. > "later" meaning what? it's not that i want to clean that up NOW, but i think in four or eight weeks this should be cleaned. can you agree with that? > Otherwise when I'm writing code and I'm really confident, I normally do not > leave things messy like that. Really! I don't, normally it's very clean :) > ok, cool =) > Two good examples are the Audio::process and Audio::processMidi. > That right there is the whole heart of the audio/midi engines, so I have to > be very careful what I do. > So it's real messy right now due to changes over the years, right up to very > recently. This is where I'm at now, so I'll clean up if things go well. > > >> there are old files, there are bunches of commented out code, and there >> are dirty workarounds >> > Who me? Well, maybe just a few. But I usually try to nail a tough dog down > instead of dirty workarounds. > i dunno who did them. some of them are from me, but significantly more are... there. and they break on greater changes. my opinion towards workarounds and hacks: they really rock, as long: * you document them. at places everyone must read (i.e., directly at that code positions) who changes stuff which might break your hack * they're self-contained. don't involve other stuff, or make assumptions which could become false if someone else changes something. my "active window" hack is _REALLY_ hackish, with RTTI and all. but it will be very hard to change some code and break that hack. because it doesn't rely on much. * there's no better solution which can be done in a reasonable amount of time: (my operations group hack for example: there IS a better solution: turn everytjing into mutex-locks or make changes to the messaging system. but this takes really, really long) > >> (and my operation groups are included there; >> that's my fault ;) ) which should be fixed... >> >> >> what do you all think about that? >> > Yes, certainly needs cleaning. But there are some of my px.xx.xx > markers I'd like to keep. One specifically is p3.3.25, which is the > massive external midi sync changes. > I'm still not certain about all that stuff I did, so to help me, I simply > look up p3.3.25 to find all the places changed, to remind me > to keep an eye on it. > > Tim. > > orcan: i'd recommend you to work in trunk, and commit as often as possible without breaking muse. especially namespace changes don't have any effect on the program's behaviour. so, whenever you've completed a part of work, and muse still compiles, commit it! greetings flo >> of course, it'll be plenty of work. but it will greatly simplify stuff >> later >> >> >> greetings >> flo >> >> > > ------------------------------------------------------------------------------ > Malware Security Report: Protecting Your Business, Customers, and the > Bottom Line. Protect your business and customers by understanding the > threat from malware and how it can impact your online business. > http://www.accelacomm.com/jaw/sfnl/114/51427462/ > _______________________________________________ > Lmuse-developer mailing list > Lmu...@li... > https://lists.sourceforge.net/lists/listinfo/lmuse-developer > > |