OK I'm stumped on this one. This used to work, except for the occasional report of text views crashing under Wine.
Now, under a debug build, if I load a file in the internal notepad, I get this:
However in the release build it looks OK. Worstje put this comment into the source:
* Originally there is an '#IFDEF _UNICODE' statement around these pragmas, but we don't compile as _UNICODE.
* Research shows this #IFDEF seems to exist by default due to a bug in CEditView in MBCS mode, but I do not
* believe this bug can affect us at present as it involves 'loading from files'. Testing thus far seems to
* confirm there is no different behaviour in/around the command window with this enabled. -JW
This seems to be pretty close to the problem area - a bug in CEditView, and possibly involving MBCS mode. Do you have any more details or suggestions?
I tried to work around it by reading directly into the edit control (which worked) and then saving from the edit control, which also worked. But doing it that way the Find dialog fails to find anything. I believe it is using a shadow buffer (for unknown reasons) and the find is searching the shadow buffer, not the edit control.
I'm not particularly happy with some builds randomly working - it suggests it is good luck rather than good management. For example, a bit of memory that happens to be zero this time.
And I should add that when reading the file with the debugger, the data is actually correct when read in. However setting the handle in the shadow buffer seems to somehow fail. Perhaps it thinks it is Unicode. I don't know for sure.
That's odd. Building from your branch under Debug mode and opening my script file in the internal notepad shows nothing strange. Maybe it has to do with the theming that Worstje enabled? Our development environments are obviously pretty different, and I know there are some things Worstje did to keep VC6 viable with the changes.
Try using `git bisect` to determine which precise commit did it?
It happened before the theming stuff, and in any case that doesn't affect the text windows.
I tried reverting back to the previous version and then bisecting my way back to the current one, and it all worked. After all it works now in the release build.
I tried deleting all the temporary VS files and rebuilding and that seemed to work for a while.
I think there is something more subtle going on.
I'm interested to know more about "a bug in CEditView". CTextView, which exhibits the behaviour, is derived from CEditView.
I had failed to catch that CTextView is derived of CEditView, even though I tried loading addxml.lua just now - no glitches or bugs that I can see. Regarding the bugs, I couldn't find any good sources on the issue when I was searching, hence my vague comment - although I am really glad Twisol found a more indepth explanation of the issue.
It is just a guess, but I think if you (conditionally for MSVC++6) redefine the appropriate methods in CTextView, it should be possible to work around the issue. That'd make the fix somewhat similar to the KB issues suggested fix earlier in this topic over a year ago for the glitches with world tabs displayed.
Something else to look at: http://groups.google.co.uk/group/microsoft.public.dotnet.languages.vc/browse_thread/thread/f6fc1b21d8d6338c/cc4e5227ddd1f7a9?lnk=st&q=ceditview+manifest+partch&rnum=4&hl=en#cc4e5227ddd1f7a9
The reason the release build has this fixed is because you are dynamically linking against the MFC libraries (or so I deduce). Those likely have had this particular bug fixed. The MFC debug libraries however seem not to have had it fixed. If you check the version numbers of the relevant DLLs, I bet you can find out a thing or two to confirm this theory.
And I found yet something else... I figure http://www.codeproject.com/KB/files/textfiledocument.aspx might be a replacement for CTextView if this problem is unsolvable?
Btw, Nick, if you could upload some builds showing the behaviour you describe (a debug that garbles text, a release that works fine), I can check it here to see if it isn't per chance some weird stuff going on on your PC.
Well I almost bit the bullet and downloaded VS2010 but when I saw the price:
Visual Studio 2010 Professional
Developer tool
Buy Download
AU$1,387.00
I can't quite make my fingers enter my credit card details for $1387 for a compiler, when g++ (arguably better) is free, and it is to support a program that I am giving away.
So I better try to solve the problem another way.
BTW if this was g++ (which you get free downloads for) then I agree it would be crazy to be using a 10-year old compiler.
Even Apple, you know, give away their development environment (which includes g++) but also has a very snazzy graphical IDE.
I just can't quite stop resenting the fact that Microsoft is trying to make money - a lot of it - from the people who will develop software to help sell their operating system.
It says it was fixed in MFC 7; VS2005 has MFC 8, and VS2010 has MFC 10. I don't know what's up with the Release build working, though.
I spotted that page, thanks.
Let me show what they are talking about:
void CEditView::ReadFromArchive(CArchive& ar, UINT nLen)
// Read certain amount of text from the file, assume at least nLen
// characters (not bytes) are in the file.
{
ASSERT_VALID(this);
LPVOID hText = LocalAlloc(LMEM_MOVEABLE, (nLen+1)*sizeof(TCHAR));
if (hText == NULL)
AfxThrowMemoryException();
LPTSTR lpszText = (LPTSTR)LocalLock(hText);
ASSERT(lpszText != NULL);
if (ar.Read(lpszText, nLen*sizeof(TCHAR)) != nLen*sizeof(TCHAR))
{
LocalUnlock(hText);
LocalFree(hText);
AfxThrowArchiveException(CArchiveException::endOfFile);
}
// Replace the editing edit buffer with the newly loaded data
lpszText[nLen] = '\0';
#ifndef _UNICODE
if (afxData.bWin95)
{
// set the text with SetWindowText, then free
BOOL bResult = ::SetWindowText(m_hWnd, lpszText);
LocalUnlock(hText);
LocalFree(hText);
// make sure that SetWindowText was successful
if (!bResult || ::GetWindowTextLength(m_hWnd) < (int)nLen)
AfxThrowMemoryException();
// remove old shadow buffer
delete[] m_pShadowBuffer;
m_pShadowBuffer = NULL;
m_nShadowSize = 0;
ASSERT_VALID(this);
return;
}
#endif
LocalUnlock(hText);
HLOCAL hOldText = GetEditCtrl().GetHandle();
ASSERT(hOldText != NULL);
LocalFree(hOldText);
GetEditCtrl().SetHandle((HLOCAL)(UINT)(DWORD)hText);
Invalidate();
ASSERT_VALID(this);
}
The #ifndef _UNICODE only affects code that applies if you are Windows 95, right? Which I'm not, I am testing on XP.
However hoping that was the issue I had in fact forced it to think it *was* Windows 95, see here:
So far so good. But then I found that the searches found nothing because it was *searching* the shadow buffer. So I thought "this is crazy" and it worked before anyway.
The reason the release build has this fixed is because you are dynamically linking against the MFC libraries (or so I deduce). Those likely have had this particular bug fixed.
No, I'm not. Good suggestion. But I in fact statically link against both to get consistent behaviour.
In any case, why would the library be fixed? I haven't downloaded fixes. That is, not recently. I got the latest Visual Studio 6 service pack a while back, but as you can understand, they don't update that every week.
Edit: Seems I got ninja'd a couple of times while writing this. Will post in a bit on the stuff I missed. :)
I fully understand your reluctance to buy a newer version, and I am even tempted to agree with it.
But a part of me also feels like one needs to be realistic. You bought VC++6 like... 10+ years ago. That's a huge amount of time that has gone by. It is a professional tool meant to help you make money. While I don't know how much you have made using MUSHclient, nor what you do currently, I bet VC++ has been among the backbone of your work as a software developer.
Whatever work you have done during those 10 years, part of it should have been a fiscal write-off for your investment into the tools, and to allow you to buy new tools as your time/field requires it.
Now I don't say 'buy VS2010 for MUSHclient'. That would be stupid. Stick to VC6++ for that if it is the extent of your activities. But I am saying that if you are still a professional (fulltime) software developer, switching to a modern tool is completely expected. VC6++ is not supported anymore, so delivering work for a modern OS would be unprofessional.
Nick Gammon said: Well I almost bit the bullet and downloaded VS2010 but when I saw the price:
Visual Studio 2010 Professional
Developer tool
Buy Download
AU$1,387.00
...Ouch. There's a $549 package (US$) with the MSDN Essentials subscription instead, but it's unclear whether it's just the MSDN subscription that expires, or whether you have to renew the whole darn IDE.
Nick Gammon said: I can't quite make my fingers enter my credit card details for $1387 for a compiler, when g++ (arguably better) is free, and it is to support a program that I am giving away.
I'm not advocating Microsoft here, but MSVC is a lot more than just a compiler. (Ugh, but I'm still trying to find a version with no MSDN subscription...)
Nick Gammon said: I just can't quite stop resenting the fact that Microsoft is trying to make money - a lot of it - from the people who will develop software to help sell their operating system.
If you join a local community college for a semester, maybe you can get in on Microsoft's DreamSpark program. XD
I assume it's pricier than the one-year subscription product because they don't have their hook in you.
(I'm not trying to get you to buy it, I'm just pointing out better deals than what you posted. Of course, if you did get it, then I could get the $200 upgrade and we'd all be on even ground, which would be astonishing. :O)
Nick, I dug into the sourcecode for the CEditView as VS2010s MFC has it, and I've put the parts I thought relevant up on Pastebin so you can try to figure out how to do a good fix.
I'd do more but I'm totally unsure on how to properly fix it without having the version of the framework that has the booboo in the first place.
What the hey? Why does VS2010 Professional with MSDN cost $1000 in the US but $2000 in Australia? And why can I get a version without any MSDN stuff for $700?
Nick Gammon said: And as for why? Well, we have long had the feeling of being ripped off for software over here.
Shipping charges, eh? Those software boxes are really heavy, it takes a lot of work to import them.
I'm afraid that experience is universal. There's nothing fun about being able to guess a price in EUROs just by seeing the price in US DOLLARs simply by switching out the monetary sign.
Over here, they do not even (reasonably) have the 'shipping charges' excuse. :(
Nick, I dug into the sourcecode for the CEditView as VS2010s MFC has it, and I've put the parts I thought relevant up on Pastebin so you can try to figure out how to do a good fix.
What you have there is a variation on what I had (except for the test for the control version instead of the operating system version). If it passes the test, it would be behaviour B I had (where the find doesn't work) and if it fails the test I would get behaviour A (garbage).
But it shouldn't take heaps of code to fix - this only just started happening.
I posted tons of links earlier in this thread, and I think one of them also explains why it is happening. In case I forgot the link with that information, I can explain the reason for as far I recall it.
For theming support, we need Common Controls v6. Common Controls v6 work, under the hood, as full unicode controls where the old ones do not. Which is why MSVC2010 does the check for the common controls version, as that one returns wchars. Otherwise, you get ordinary chars back, which very likely was the old codepath that has zero issues.
Problem is that your version has wchars casted as chars, meaning they kinda look like chinese characters were you to use the right font.
So from what I saw from your commit, you totally cut out the non-unicode (v5) bits. You need to keep both in there I am pretty sure. It's just the bwin95 check that is bonkers for as far I can tell without any upclose experience with it.
I posted tons of links earlier in this thread, and I think one of them also explains why it is happening. In case I forgot the link with that information, I can explain the reason for as far I recall it.
For theming support, we need Common Controls v6. Common Controls v6 work, under the hood, as full unicode controls where the old ones do not. Which is why MSVC2010 does the check for the common controls version, as that one returns wchars.
... could lose the relative paths? It just broke my build as I obviously do not have the file there. Then again... I am not sure how to proper reference that file. Gonna figure that out a bit later, but for now at least I posted here.
Found it. The following makes it work for me.
#include <../src/mfc/afximpl.h>
I am not sure about 2005 and such, but can you add an #if for later compiler versions (or maybe later a _MFC_VER would be more appropriate) so that the file is included from the proper place depending on what MFC version we're using?
Edit (yet another one):
Talking with Twisol on AIM, and I realized it might be better not to fix the include to be right, but rather to make sure your fixes for the blocks only affect the VC++6 and its MFC version. After all, our versions have the bug fixed, so your fixing MFC6 might actually break stuff for us because we are messing around with the internals.
Worstje said: Talking with Twisol on AIM, and I realized it might be better not to fix the include to be right, but rather to make sure your fixes for the blocks only affect the VC++6 and its MFC version. After all, our versions have the bug fixed, so your fixing MFC6 might actually break stuff for us because we are messing around with the internals.
That sounds like a much better plan in my opinion. Only fix what's broken, right?
Do you want to #define all that extra stuff away for you, is that what you are saying? Maybe test first and see.
That's why I was suggesting you add:
#if _MSC_VER >= 1400 // doesn't work with Visual Studio 6
#include <../src/mfc/afximpl.h>
#else
#include <../src/afximpl.h>
#end
That way the include is correct for us. Although avoiding including it for non-VC++6, and #if'ing your fixes for the bug for your VC++6 version in specific seems like an even better (cleaner?) idea having thought about it in more detail.
That sounds like a much better plan in my opinion. Only fix what's broken, right?
This is what I hate about all this adapting to different things (the themes are another case in point). The whole thing is turning into a delicate flower, where there are tests for exact versions of libraries, exact versions of the compiler, conditionally including stuff here but not there, and so on.
I don't want to conditionally include source, more than absolutely necessary, depending on the compiler version. Testing a runtime library, well if it has to be done, it has to be done.
Well, I am sorry to inform you, but requirements change over the years. I can't help the fact Windows gets new features, and people like to see those features used while at the very same time, you insist on keeping compatibility with Windows 95 and the likes.
I don't like the fact that, to fix a bug affecting YOUR version of MFC only, ALL versions of MFC get a fix applied that might well conflict with their inner workings which are NOT garantueed to be compatible with OLDER versions - only the interfaces are garantueed to be compatible. If your fix ends up requiring a header that is considered 'innards', don't make us require it either - this situation shows it is obviously not garantueed to exist for us in the same location.
If this post comes over as a bit hostile, I apologize. I know the MUSHclient source code ain't the most beautiful thing ever, and I avoid bringing that and the word 'refactor' up. I accept that I'll work with what we have. However, I do refuse to accept that because it is already a relative mess that we do not have to think about the best approaches to a situation such as this one.
There is no way to avoid conditionally including header files. If you want to minimize that, it is best to refactor the fixes to only affect your compiler version.
Right. Finally I have worked out what has been happening over the last couple of days. Fully two days, I would way, working out why, suddenly, with no code changes I could account for to cause it, the notepad window suddenly showed garbage.
Just to recap:
The notepad window has worked fine for years.
I recently made various changes to other parts of the code - some of which were just moving code around into different files.
Some improvements were also made, but basically the CTextView was not touched at all.
Suddenly, the notepad just showed garbage.
Reverting back to previous commits didn't fix the problem.
It seemed to be just something in version 4.62, but no code change seemed to be possibly responsible.
With the assistance of Worstje, and adding a substantial amount of extra code the problem went away.
There were then complaints that this should be conditionally added because recent compilers "weren't broken" like mine was.
There have been hints that perhaps I should spend $1000+ to get a "better" compiler.
But none of this explains why. Why did it suddenly start happening? I deleted all temporary files, did a rebuild all, everything I could think of. Then there was a small clue, doing a debug start up:
Loaded 'C:\WINDOWS\system32\user32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\version.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\winmm.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\shlwapi.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\comdlg32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.5512_x-ww_35d4ce83\comctl32.dll',
no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\shell32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\winspool.drv', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\oledlg.dll', no matching symbolic information found.
What the heck is C:\WINDOWS\WinSxS? A quick Google reveals it is part of Microsoft's "compatibility" system. But I didn't remember seeing that before.
Aha! There was one change recently - but not to the source, which is why reverting the source didn't affect anything. Here it is ...
Worstje said:
I created a theming branch on github, and have already fixed the bug regarding the notorious "tip of the day" dialog.
...
May I request testing and, assuming there are no issues, to have support for visual styles turned on by default?
The problem is caused by having the file MUSHclient.exe.manifest in the MUSHclient directory. No wonder reverting the source didn't fix it, because that file wasn't reverted (ie. deleted).
To be fair to Worstje he didn't expect this to happen. Neither did I. And had the problem surfaced the moment after putting the manifest file there I would have twigged. But it was like hours later, or the next day, after even more source changes, that I thought to open the internal notepad. One of the reasons for that is, that I use Crimson Editor most of the time, and when I hit "edit" to edit a plugin, it just goes to Crimson Editor.
What the new themes did is bring in a new comctl32.dll which handled the edit controls differently. Pretty subtle huh? Pretty annoying too.
It's annoying because, whilst I sympathize with the idea of a more modern look and feel, making a change that basically just gave you rounded buttons and a few shadows here and there, has wasted two days of my time.
And then the solution (the interim solution we had) isn't something I feel totally comfortable with. What if, for example, thousands of existing users who don't happen to have that control now have the client fail? What if some people don't have UxTheme.dll?
You have already complained here that you don't want to make changes "to fix a bug affecting YOUR version of MFC only". Well, how can you say with confidence that it will work whatever we do?
Certainly no-one predicated that adding in the manifest file would cause corruption in the notepad window. So I wonder what else unexpected will happen?
If Microsoft supported their developers (like Apple do, and Linux) by giving away the development tools, then I could accept that I should have the most modern tools. But when it is a thousand dollars every three or four years (after all, there is VS2005, VS2008, VS2010, then I feel like I am just giving them money for basically bug fixes. Big money. Especially when I get practically no income from MUSHclient.
Now that I know what to look for doing a Google for "ceditview manifest" reveals quite a few hits. A bit of griping too, because this is obviously not a new problem.
Nick Gammon said: *There were then complaints that this should be conditionally added because recent compilers "weren't broken" like mine was.
Suggestions. Also this has nothing to do with the compiler, we've shown that it's actually MFC 6 - a library that's bundled with the VC6 IDE - that has the issue.
Nick Gammon said: *There have been hints that perhaps I should spend $1000+ to get a "better" compiler.
Suggestions. I'm not about to get into the business of forcing people to spend money they don't want to spend. What I was doing is trying to determine why it costs so much, and whether there was a better deal. Also, note that it's only $200 to upgrade from VS2005/2008 to VS2010. VC6, on the other hand, is officially unsupported.
Visual Studio is not just the compiler, but also the visual environment, included libraries (MFC being the obvious one), assorted utilities (the resource editor comes to mind), and an (unwanted) MSDN subscription. If it were just a compiler I think we'd have far fewer issues... C++ doesn't change that quickly, as shown by how successful we've been in working on the same code in both VC6 and VS2010. Besides, the Express editions come with the same compiler. What are they missing? Other bundles, like MFC.
Sorry, Nick, it's just been getting on my nerves that you refer to Visual Studio as a "compiler" and compare it to g++.
Nick Gammon said: What the new themes did is bring in a new comctl32.dll which handled the edit controls differently. Pretty subtle huh? Pretty annoying too.
I toyed with the manifest before any of this came to light, and right inside the file it shows a dependency. It's not very subtle unless you forget it's there (which I agree can be a problem).
Nick Gammon said: What if some people don't have UxTheme.dll?
Worstje and I talked about this, and if you look at his code, I believe it will fail gracefully. That's why it doesn't add the uxtheme library as a hard dependency.
Nick, there is a lot of stuff in your last post, and a lot of (pent up) frustration as well. Also, I need to point out... the entire 'why' you wrote down just now is something I already explained once around four hours ago. Not in as much detail as you have, I admit, but if you spent the last four hours figuring out that I think it is sad my posts ended up lost in the discussion concerning the monetary cost of a VS2010 purchase.
The moment I made the change I made an explicit comment in the source regarding a CEditview bug of which I then did not find the details. I checked all source code and only found a few references, since the rest was in a derived class (CTextView), so I wrote down that I thought it not to be an issue at present. Never the less, I made sure to document it.
Quote: You have already complained here that you don't want to make changes "to fix a bug affecting YOUR version of MFC only". Well, how can you say with confidence that it will work whatever we do?
Certainly no-one predicated that adding in the manifest file would cause corruption in the notepad window. So I wonder what else unexpected will happen?
I will answer your two questions in reversed order. I am going to be ruthless, and say I did predict it. I will quote the comment I mentioned above:
/* Manifest instructions for the linker.
* Originally there is an '#IFDEF _UNICODE' statement around these pragmas, but we don't compile as _UNICODE.
* Research shows this #IFDEF seems to exist by default due to a bug in CEditView in MBCS mode, but I do not
* believe this bug can affect us at present as it involves 'loading from files'. Testing thus far seems to
* confirm there is no different behaviour in/around the command window with this enabled. -JW
*/
In the beginning of this thread, you noticed the problem with the garbled notepad window. You even found that comment. If I were to look back on the appropriate forum topic, I am pretty sure I would also find a request of myself asking you and Twisol to test it to see if it didn't cause trouble. My MFC version does not have this bug, and I could never have caught it myself.
Second (first?) question. Can I be confident that it will work no matter what we do? Hell no. We are developing for a modern-day environment using a 10-year old compiler as our primary code-cruncher, around 10-year old bugs with no support from Microsoft. But _within_ those requirements, I am damn confident. Why?
1. One of the articles linked elsewhere in this thread shows three different bugs in the MFC Visual C++ 6 uses (called 'bugged MFC' from now on). One of them describes this particular bug in enough detail to understand the issue.
2. Using the latter and some digging into VS2010 source files, we managed to engineer a fix that stops the bugged MFC from messing up the output window.
3. I made sure to make all calls to uxtheme.dll dynamic calls, so they do not affect backward compatibility. This took considerable effort which I commented extensively - which your post just now betrays not even skimming over.
The only confidence I do _not_ have is that it will keep working on newer compilers, since we are working around a bug for the bugged MFC on all MFCs, even those with the bug fixed. At some point, if not properly specialized to focus on the bugged MFC only, it will cause hard to track bugs for people compiling MUSHclient under that environment.
This post is a bit late since I took my time writing it, but the implications inbetween the lines are really starting to annoy me. I did expect a lot of this, be it in less detail, and I feel as if I am being blamed for checking in changes without testing. I made every single effort I could, adding comments, asking for code reviews, posting posts on the forum, and still it ends up as 'I wasted 2 days tracing a mystery bug'.
Nick, I love you to death, but you confuse me like no other at the same time. You want to know what things do before checking them in, yet all my comments in the source and on the forums here seem to fall upon deaf ears. I do not have you on AIM, so the slow/indirect communication is likely a big part of our communication troubles, but this is not conducive for anyone: you get frustrated with us, and we get frustrated with you. Old compilers, new compilers, in the end they are a detail that becomes a focus due to communication failing us.
Well to give you credit - and I suppose I overlooked this a bit - your comments about the CEditView were indeed adjacent to the stuff about the manifest.
I suppose I just didn't twig that the mere inclusion of the manifest file - and not changes to the source per se - caused my problems.
And to be fair to Twisol:
Twisol said:
That's odd. ... Maybe it has to do with the theming that Worstje enabled? ...
Try using `git bisect` to determine which precise commit did it?
I focused more on the "precise commit" issue rather than the "theming that Worstje enabled". With the benefit of hindsight, I followed the wrong path.
Oh well, when we have all calmed down a bit (particularly me, eh?) we will have a better end result. :)
Nick, do you have AIM or some other instant messenger? I think in the future we might be able to save ourselves a lot of time with a bit directer line of communication.
(I have no intention of taking discussions away from here - merely to improve communications when forum posts are a bit too clumsy for communication.)
... yet all my comments in the source and on the forums here seem to fall upon deaf ears....
Well not totally, and we got a result, working together.
You are probably familiar with the concept of "what I heard is not what you said". Sometimes we hear what we expect to hear, and see what we expect to see.
On a more humorous note, check out this:
http://www.youtube.com/watch?v=vBPG_OBgTWg
In this video the fellow experiments by swapping people in mid-conversation and seeing if the subject notices. This has been done a few times, and in most cases they don't. They already have made up their minds about what they are seeing and even blatant evidence to the contrary doesn't appear to shift them.
In this video the fellow experiments by swapping people in mid-conversation and seeing if the subject notices. This has been done a few times, and in most cases they don't. They already have made up their minds about what they are seeing and even blatant evidence to the contrary doesn't appear to shift them.
That's some pretty awesome stuff. Now I am tempted to pull some practical jokes like this coming april. xD
(Any chance you can answer my question in my previous post? I think you missed it.)
There's IRC. I've always got mIRC running in the background. I can join #mushclient-dev in a snap. Just like that; I'm there now if anyone wants to come by, and I can leave it on my auto-join list.
[EDIT]: I agree with everything Worstje said below, which is why I jumped straight to IRC. Sorry for not being clear. :D
[EDIT] 2: Freenode network, I can't believe I forgot to say that...
I suppose, although messengers tend to be a bit more userfriendly. No need to actually play the game. I've got everything from AIM to Yahoo to MSN to ICQ even.
Likewise, in my experience, people spend less time logged on onto a mud than they do on a messenger, meaning it is trickier to get a hold of someone or to leave them a quick message.
Putting aside a nice chat for a minute, I feel as if I have been through the mill with this version, what with the major changes, some subtle issues with the timestamps (solved in the end by changing the opacity of text drawing) and then the corrupted window issue.
Are there any major reasons we can't get this out as a version for people to test? Then we can start from scratch with a new version.
BTW here is another video about noticing things:
http://www.youtube.com/watch?v=mAnKvo-fPs0
In this case the subject fills in a form, and then the guy behind the desk ducks down, and another one stands up in his place, and 75% of people don't notice the change.
Oh, I feel this version has had all the changes it needs. (Minus that bugfix that isn't specific enough, but that's been brought up to death by now, so I'll save that for a future version. xD)
I'll check that video out tomorrow - got some stuff to finish and tomorrow it'll be a nice way to start the day. :)
For your viewing 'pleasure', I have put all VS2010 CEditView code regarding find and replace on pastebin. I'd go through the details and such myself, but I haven't got a clue where it goes wrong for you, and I'd have a hard time debugging an issue I don't have as well. Copy/paste as you see fit, or if you spot a more surgical solution to your problems, do that.
http://pastebin.com/s0k6HfcD
Well I just don't think it's worth it. I see what is happening a bit more clearly. The new controls assume the text is Unicode (obviously the old ones didn't because without changes anywhere else they work).
Now I initially tried changing the ReadFromArchive to convert the text to Unicode (assuming it was UTF-8 - can we assume that? and if not, what do we assume?).
So instead of setting the shadow buffer to nothing, I put the Unicode text in the shadow buffer - in other words like this:
So far so good - the text appears OK, and it writes out OK, as the writing part seemed to be assuming Unicode (why?).
But the finding doesn't work. Setting some breakpoints found that the MFC I have assumes we have straight text and not Unicode. But this is reasonable - it *is not* a Unicode app. Now I can start replacing all the finding stuff to do a Unicode find, but why not rewrite the whole app to be Unicode while I'm at it?
Next thing I'll find is that copying and pasting won't work right because one is Unicode and one isn't,
The thing is, Worstje, you are trying to put old wine into new bottles. It doesn't work. And the fact that the new common controls "just assume" you have Unicode in the edit window, when the old ones don't make any such assumption, doesn't help one bit.
I think the whole thing will have to be reverted, sorry. If you want to start again and write a Unicode client, be my guest. But this merging in of (dare I say it) buggy common controls with an old app isn't working.
I can't say much other than that I am disappointed.
It is not the common controls that are buggy, it is _your_ specific MFC version. There are ZERO issues on my VS2010 build, and I am pretty sure Twisol has the same experience on his VS2005 build. It is a bugfix to your framework (Twisol would hit me if I said compiler again), and the only way to fix that bug in your framework is to tackle your framework. Newer versions of the framework are the perfect example that MFC is not per definition flawed, and thus there is no 'old genie new bottle' thing going on - it is a plain old bug. Nothing more, nothing less.
Do I get that it isn't fun to work around bugs and all that? Totally. But now you also know how we feel trying to make every single change we make compatible back to W95, VC++6 and whatever else.
Last of all, there is one more thing I'd like to voice.
Back when you made the source available, you have made complaints more than once that it was for naught, saying things like (no exact quote - I am too lazy to look it up) 'only a handful of people has downloaded the source', and more things along the lines of people being unable to help out with patches and the likes.
I have been putting a lot of work into the theming, because I would like to see it implemented. I have not asked you to point out X or Y as I was trying to figure things out, but merely offered patches and welcomed all criticism and issues that popped up as a result of them (which I do thank you for).
In the end, I have gone out of my way to try and keep patches as compatible as humanly possible given the 'demands' placed on me. Is it too much asked that, given the work that has been put in, we do not sling the 'old genie, new bottle' argument while we know very well that the entire compiler has had its end-of-life date placed around 10 years ago now?
By the same argument, we might all just as well stop developing MUSHclient, since this is like putting an ancient bottle in a fancy new winerack, followed by putting a new wine in the bottle from time to time. You either accept time moves on, requirements and tastes differ and evolve, or you put it aside in the antiquated section. Switching sides along with what seems best given the situation
This post is totally all over the place arguments-wise, and I suck at the imagery comparisons as well, and I apologize for all that.
TL;DR: I care about MUSHclient, I'll go along with a lot of decisions despite not agreeing with the reasons, but there's limits to everything. We have a possible fix for your specific framework, and you rather drop a 'feature' than use it. That's how I see it. When it is proven the Find function cannot be patched to make to work again, I'll gladly surrender the argument, but right now, it is total utter poppycock.
There are ZERO issues on my VS2010 build, and I am pretty sure Twisol has the same experience on his VS2005 build.
My major point here is that you two have got it to work using custom builds and using modern versions of Windows. Fine. But I have about 4,000 downloads a month. I get quite a feel that a lot of people are using Ubuntu. Certainly they won't all have the latest Windows controls.
It isn't enough that two people can get it to work. I need it to work reliably for the 4000 * 12 per year that are downloading it.
There are a lot of hurdles to overcome in making MUSHclient look like a modern Vista / Windows 7 app, and adding a file into a directory and tweaking a couple of settings is not it.
Worstje said:
It is not the common controls that are buggy, it is _your_ specific MFC version.
My version of MFC has served me well over the last 15 years. It is the attempt to shoe-horn modern controls into an old framework that is the problem.
Worstje said:
I have gone out of my way to try and keep patches as compatible as humanly possible given the 'demands' placed on me.
I sympathise, honestly. I have suggested in the past that the client could be rewritten. The Mudlet guys have done just that, in that they did their own open-source, cross-platform client.
I appreciate all the suggestions, and realize that they were intended to improve things. I also realize you can't test if your changes will work with my old compiler sophisticated Integrated Development Environment.
There is nothing stopping you or Twisol releasing a "new improved" MUSHclient, designed to work on XP or Vista upwards. It could have reworked GUI interfaces (ie. configuration screens). It could have better theming. It could be refactored <grin>.
I just don't like the idea - and I may well be wrong - of tweaking away, rewriting stuff like the CTextView to incorporate the new controls, and basically adding cosmetic stuff, for no real purpose, apart from looks.
Something like the timestamps, that was a nice idea. I can actually see how that might be used when playing a MUD - to see how quickly hits arrive in combat. But rounded buttons on a dialog box? Which you rarely have up? I think that is just over-egging the pudding.
Nick Gammon said: There is nothing stopping you or Twisol releasing a "new improved" MUSHclient, designed to work on XP or Vista upwards. It could have reworked GUI interfaces (ie. configuration screens). It could have better theming. It could be refactored <grin>.
The topic of forking came up in passing between us, but only to say that we both detest the idea of forking MUSHclient, not least because of all the hard work you personally put into it. A MUSHclient without Nick Gammon sounds like a very strange proposition. I personally would rather create something entirely new.
Nick Gammon said: But rounded buttons on a dialog box? Which you rarely have up? I think that is just over-egging the pudding.
One of the things Worstje mentioned to me is how he's met so many people who reportedly looked at MUSHclient and didn't think it was even still maintained. MUSHclient looks and feels dated, regardless of whether it's actually true or not. This may not be a major point, but I do think it's a valid one.
[EDIT]: I understand you're probably not actively marketing MUSHclient, and that's a perfectly valid viewpoint too. After all, if you're not trying to put a product out there, there's not as much pressure to make these changes. I would suppose that's why Zugg killed zMud and made CMUD - after all, he makes money from his clients - but of course I know very little about Zugg's stuff.
You are aware the _only_ thing you had to do to get MUSHclient to revert to its 'classic' look was remove the .manifest? The manifest is what causes the v6 controls to be loaded. No manifest, no v6, no unicode, no problem.
Removing all the other improvements only hurts people who wish to build with > VC6++ versions. The THEME_GLUE things did not do anything without the proper controls loaded, for example.
The reason I do not fork MUSHclient is three-fold. First of all, out of respect to the man who created it and maintained it for over 15 years. Second is because it would confuse users. And third is because I don't like to do the entire regular development thing for myself - I rather contribute to something that lasts.
Quote: My version of MFC has served me well over the last 15 years. It is the attempt to shoe-horn modern controls into an old framework that is the problem.
An attempt that would very likely have been succesful had you not chosen to revert the entire thing. Which is not to say I see that as the problem - I see the fact you insist on sticking to a 'MFC version that has served you well for 15 years' as the problem, while it is obvious it has had its shortcomings for 8 of those years.
Otherwise, you would have enabled support for themed controls 8 years ago. Essentially, you wish to develop using an outdated IDE that has not truly sufficed for the last eight years because you consider all of its shortcomings as bridges you'd rather not cross.
But rounded buttons on a dialog box? Which you rarely have up? I think that is just over-egging the pudding.
If that is your view, I can see why you are opposed. It is far more than that though. It is about consistency. MUSHclient stands out as a sore thumb just like those very recent Office versions stand out in their own way, and it is a gap that only grows. For a window that takes up 1/3rd of my screen on a near permanent basis, I do like to have the things that can be pretty, be pretty. Additionally, I hear when talking to people that they feel MUSHclient is not worth checking out because it looks outdated and unmaintained.
Personally, the biggest gain throughout this effort for me was to learn some of the code intricacies, and to help move some things along to the next generation. The unicode issues were an unexpected but nice side effect - if you can convert small things on a case-by-case basis, a full conversion becomes a reality at some point.
Theming.
Fixing the weird screen-greedy infobar of doom.
Command line window with red-wavey-underline spellcheck built in.
Redoing world properties.
Cleaning up global prefs.
Those were the things I was working towards, working on, or making plans for. But if something as simple as this already causes major strife, I do not believe I can ever do those other things. The infobar of doom might need a bugfix approach like the unicode issue of today did. The command line window may not be that compatible with older versions of windows. World properties are doing fine as they are, so why change them?
It will always be an uphill battle with you, Nick. And for someone like me who only wants to code so people will have a use for the things being coded, the maintenance / regular releases aspect is not interesting. But the constant battle is equally frustrating - I bet that we could have fixed your bug in the time it took us to discuss this issue, revert those commits, and whatever else you did.
I still love you, but the frustration is not worth it. I doubt I will do much more than fix the occasional bug from now on forth.
Even having only read the last page of posts, this discussion seems to have taken an interesting turn. You all have very valid points, and you're all very good coders, so I hope we can all get along here. :)
Now, I just want to say that I have looked through the MUSHclient source quite a lot, and I learned a good many things from it. I made pretty good progress on my own client before I got distracted with other projects, but I do hope to get back to it and make it something that at least I can use myself to play my MUD.
A modern interface can really go a long way towards better usability and increased functionality. There have been many advances in controls available through the libraries now, and I'm pretty excited about the potential of several of them in my own applications. If only I didn't always get stuck on silly things like art for toolbar icons...
Even having only read the last page of posts, this discussion seems to have taken an interesting turn. You all have very valid points, and you're all very good coders, so I hope we can all get along here. :)
I'm getting along just fine. It is the working along that is giving me trouble. :)
Quote: Now, I just want to say that I have looked through the MUSHclient source quite a lot, and I learned a good many things from it. I made pretty good progress on my own client before I got distracted with other projects, but I do hope to get back to it and make it something that at least I can use myself to play my MUD.
I feel the same, there is a fair number of interesting things in the source. If it isn't the good decisions and code, it is the fact the code shows its age with rings like a tree would. It shows me what to pay attention to, and where I can improve.
Quote: A modern interface can really go a long way towards better usability and increased functionality. There have been many advances in controls available through the libraries now, and I'm pretty excited about the potential of several of them in my own applications. If only I didn't always get stuck on silly things like art for toolbar icons...
I feel the same way, and tend to get stuck at the same spot with art and such. Is there any chance your client is opensource? I'd love to go through it, and if I gathered correctly from other posts you actually borrowed a lot of MUSHclient source code, or forked or whatever - meaning I might be interested in contributing if that is anywhere up your alley.
One of the things Worstje mentioned to me is how he's met so many people who reportedly looked at MUSHclient and didn't think it was even still maintained. MUSHclient looks and feels dated, regardless of whether it's actually true or not.
I just don't understand this bit. Let's say on a MUD someone recommends MUSHclient - in that case they can say "don't worry if it looks a bit old, it works really well".
But if it isn't recommended, you are saying someone downloads it, installs it, fires it up, looks at the user interface and then deletes it? That's a strange workflow, isn't it?
But if they refuse to download and install it, because it looks dated, how do they know it looks dated? If you can explain this "race condition" to me, I'll be interested to hear.
Or are you saying that someone has heard the client is good, but once installed they glance at the configuration dialogs and say "oh blast! square buttons! it's rounded buttons with shadows for me or nothing!". Delete!
I don't mind helping other open-source guys. Here is another client that might be more suited to your tastes if you want a free, cross-platform, and more modern-looking client:
Mudlet has the same problem. They say they're "Open Source like Lua", but according to the Lua FAQ; Lua isn't Open Source. Mudlet is not a collaborative project. It's one guy, Heiko, in control and he's much worse than you about keeping Git repositories updated. There's no point trying to offer patches or aide to the project because any source you can get is ancient.
Plus, Mudlet has some majorly shortcomings functionally... Every other mud client in the world has a trigger for if a line starts with an ansi code (Like MC ONLY tests the first char) Mudlet checks the whole line for the ansi code, with no way to anchor it... argh.
... he's much worse than you about keeping Git repositories updated.
Bearing in mind that implies I am bad, and he is worse. When I make a change these days, I test it, and as soon as it looks reasonable, I do "git commit" and "git push". Certainly for each release of the executable, I also make sure that the corresponding source is fully committed at the same time.
Willfa said:
... according to the Lua FAQ; Lua isn't Open Source.
I am on Nick's side on this one - for the most part anyway. He is nothing other than excellent in keeping git repositories updated, even though he has a habit of skipping commits to merge, or manually merging and forgetting a thing or two. But the intention is very much there - once he is able, he commits changes.
Regarding open source Lua stuff... I think WillFa refers to the fact that Lua development is done behind closed doors, with periodical patches being released as well as work versions (beta) of new versions. It's quite like Nick solely releasing the source at one-version intervals like he did upto version 4.45. It was only then that he began to incorporate github into his routine.
There's a difference between open source and day-to-day open development.
My code is open source, hosted on Assembla. I have a few screenshots of some places where I improved the user interface. My code is far from complete, but I'm pleased with how far it got.
http://www.assembla.com/spaces/mudder
(I know this isn't really the place for this, so I apologize for the little derail.)
... he's much worse than you about keeping Git repositories updated.
Bearing in mind that implies I am bad, and he is worse. When I make a change these days, I test it, and as soon as it looks reasonable, I do "git commit" and "git push". Certainly for each release of the executable, I also make sure that the corresponding source is fully committed at the same time.
Or an ambiguous way to say you're awesome and he sucks... As you pointed out, you're very dutiful and commendable about it, so I'll attribute your inference of "you're bad" because you may have felt ganged up on, or something. Wasn't my intention. (I wonder if that's a colloquial difference. "Taco Bell is much worse than lobster, and McDonald's is even worse than that." Around here, 'even worse' would carry your inference. 'much worse' is just a relative statement with no subjective starting point. Yaaaa, I'm involved in ANOTHER pedantic, semantic argument on here!)
Nick said:
Willfa said:
... according to the Lua FAQ; Lua isn't Open Source.
See this page on the Lua site:
http://www.lua.org/license.html
First paragraph (in part):
Lua License said:
Lua is certified Open Source software.
From http://www.lua.org/faq.html
1.9 Do you accept patches?
We encourage discussions based on tested code solutions for problems and enhancements, but we never incorporate third-party code verbatim. We always try to understand the issue and the proposed solution and then, if we choose to address the issue, we provide our own code. Lua is not an open-source project, with code contributed by several people. All code is written by us. See also the previous question.
Ok, I shouldn't have capitalized it.
Nick GammonAustraliaForum Administrator#62
WillFa said:
Lua FAQ said:
Lua is not an open-source project, with code contributed by several people. All code is written by us. See also the previous question.
With my psychic powers I knew you would raise that, because otherwise why would you have made that claim?
However I pre-empted you by posting to the Lua mailing list, pointing out that the two statements contradicted each other. The response was:
Luiz Henrique de Figueiredo said:
> http://www.lua.org/about.html
>
> "Lua is not an open-source project, with code contributed by several people: all code is written by us.".
This is indeed misleading and will be removed by tomorrow.
Yaaaa, I'm involved in ANOTHER pedantic, semantic argument on here!
That's nothing to what I started on the Lua mailing list. They are down to arguing about a comma (actually, *the* comma) in the "open source" statement.
Worse effectively means "more bad" - so to be worse, you start off with badness.
You don't say for example, "Film A was really good, but Film B was worse". It would be more like "Film A was really good, but Film B was less good" (not more bad).
Worse effectively means "more bad" - so to be worse, you start off with badness.
You don't say for example, "Film A was really good, but Film B was worse". It would be more like "Film A was really good, but Film B was less good" (not more bad).
But perhaps we are getting carried away here. :-)
Disregarding our frequent praise, sycophancy, and asskissing, you admit you're not perfect - so there is some degree of 'bad' in you. It may not (certainly not in my estimation) be one of your predominate traits, but there is in fact some 'bad' that enables the relative comparison...
(We're not carried away until until you make a WoW character named LessBadThanPerfect)
;)
Speaking of arguments about commas... I read this the other day and it made me laugh:
From http://www.guardian.co.uk/styleguide/o
Quote:
Oxford comma
a comma before the final "and" in lists: straightforward ones (he ate ham, eggs and chips) do not need one, but sometimes it can help the reader (he ate cereal, kippers, bacon, eggs, toast and marmalade, and tea), and sometimes it is essential:
compare
I dedicate this book to my parents, Martin Amis, and JK Rowling
with
I dedicate this book to my parents, Martin Amis and JK Rowling
Further to my comments about not wanting to spend $1000+ on upgrading Visual Studio, there was an interesting opinion on the Lua mailing list:
Lua mailing list said:
Microsoft doesn't really want independant software developers (they only hurt their business), they want to sell a product: Visual Studio. And the crt is the doc-format of the compiler: every release a new version so that when one developer updates all other have to update, too.
This is the impression I get. I have already spent many thousands of dollars on Microsoft products over the years, including MSDN. However that doesn't seem to count for much. Granted that software I paid around $500 to $1000 for has some bugs, I would expect those to be fixed as part of the rather substantial cost of the software. Not to have to pay $1000 again for another version in 2005, and then another version in 2010. And remember the saying "Upgrade your software - exchange your old bugs for new ones".
And the other part of the opinion I quoted was the relentless pressure - now that Twisol and Worstje have chosen to get a newer version (perhaps for them their first version), there is the pressure on me to upgrade "to keep up". This is the: "when one developer updates all other have to update, too".
Nick Gammon said: Not to have to pay $1000 again for another version in 2005, and then another version in 2010. And remember the saying "Upgrade your software - exchange your old bugs for new ones".
It's a $300 (edit: USD) upgrade from 2005 to 2010. I'm pretty sure I mentioned that.
Nick Gammon said: [...] now that Twisol and Worstje have chosen to get a newer version (perhaps for them their first version) [...]
It is my first version, yeah. Though, as I intend for programming to be my career, I am definitely considering getting the upgrade.
Nick Gammon said: Worse effectively means "more bad" - so to be worse, you start off with badness.
I like "I could care less" a lot. I could care 100% and still care less. :)
Further to my comments about not wanting to spend $1000+ on upgrading Visual Studio, there was an interesting opinion on the Lua mailing list:
Lua mailing list said:
Microsoft doesn't really want independant software developers (they only hurt their business), they want to sell a product: Visual Studio. And the crt is the doc-format of the compiler: every release a new version so that when one developer updates all other have to update, too.
This is the impression I get. I have already spent many thousands of dollars on Microsoft products over the years, including MSDN. However that doesn't seem to count for much. Granted that software I paid around $500 to $1000 for has some bugs, I would expect those to be fixed as part of the rather substantial cost of the software. Not to have to pay $1000 again for another version in 2005, and then another version in 2010. And remember the saying "Upgrade your software - exchange your old bugs for new ones".
And the other part of the opinion I quoted was the relentless pressure - now that Twisol and Worstje have chosen to get a newer version (perhaps for them their first version), there is the pressure on me to upgrade "to keep up". This is the: "when one developer updates all other have to update, too".
Of course, Microsoft won't mind that will they?
So, ummm... Isn't this the big argument for ditching MFC for STL and getting away from VS all together?
I like "I could care less" a lot. I could care 100% and still care less. :)
Right. Which is why originally, and by people's tone of voice what they mean to say is, "I couldn't care less."
0% caring.
Not at all.
Zilch.
Even expending the effort to hand over a rat's patootie is more than I care to spare.
Nada.
None.
My buddy asked me if I understood the difference between ignorance and apathy. I replied "I don't know and I don't care."
WillFa said: So, ummm... Isn't this the big argument for ditching MFC for STL and getting away from VS all together?
MFC != STL. We'd have to move to a totally new GUI framework, such as wxWidgets. Nick's said several times that it would probably be better just to start from scratch, and I agree.
WillFa said: My buddy asked me if I understood the difference between ignorance and apathy. I replied "I don't know and I don't care."
Correct. As I see it MFC provides a number of features to developers:
Helper routines (eg. lists, string classes). These could be readily converted to STL because that provides similar things.
Helpful GUI management of dialogs. This was very helpful when I didn't know that much about instantiating dialogs, and exchanging data to/from the C++ structures into the dialog box, and back again.
There is low-level stuff like checking numeric fields are numbers, etc.
Management of Windows structures and messages (for example, making frame windows, child windows, splitter windows).
Encapsulation of stuff like device contexts, effectively hiding some of the low-level housekeeping from you.
Management of things like menus, dimming menu items that are not in context right now and so on.
A nice GUI interface (probably much nicer than the one I have) which simplifies a lot of the coding effort.
STL doesn't address any but the first, because it isn't a Windows-based (or indeed a GUI-based) thing.
So as Twisol said, you would probably need to move to wxWindows (or just do it all "by hand").
That would be such a huge change you may as well just start again. And when you started again you would seriously consider making it a Unicode app (thus eliminating these problems with text views), seriously revisit the scripting (like Twisol wanted to do), rework the GUI interface, and redesign a whole heap of stuff with the benefit of hindsight.
You are aware the _only_ thing you had to do to get MUSHclient to revert to its 'classic' look was remove the .manifest? The manifest is what causes the v6 controls to be loaded. No manifest, no v6, no unicode, no problem.
If I understand correctly, you don't need it all reverted. The only thing that went wrong (the edit control) was for me, not you, right? So the changes to the way the edit control was loaded doesn't need to be done?
So can you be more explicit about what changes you really need? You kept saying it was my version of MFC that is broken.
If I revert the changes I am not sure whether that will then break the behaviour for other people.
Let me put it another way - what is to stop you just grabbing the source and whipping out a custom build? Just merge your theming changes in with my latest source - which I always release.
None of the changes to the code that I made will break your build as long as there is no .manifest in your directory that specifies the usage of the common controls v6.
The THEME_GLUE fixes a graphical glitch that is visible only for themed users, and that will have zero effect on users that are not seeing a themed environment in the first place. The uxtheme.dll dependancy is (as the code explains) a fully dynamic one, meaning it fails completely silently if not available, and the nature of the uxtheme.dll is to provide visual gimmicks when appropriate. If the environment is not right (user doesn't have it enabled, common controls not loaded, etc) they resolve to NOOPs. (And if you wish / don't trust that, you could even wrap the themeglue.h file into a conditional for excluding your version, although I see no reason for that.)
I agree I would not need your VC6++ bugfixes reverted. Sorry for the unclarity on that subject (although I believe they do no harm when common controls aren't loaded).
So the only thing that I would like to see reverted are the themeglue changes as well as the #pragma's involving the linker. (When I originally saw your commit, I admit I didn't dive too deeply into it - I thought you had reverted all my theme-related commits like the tipdlg, world prefs and global prefs.)
Quote: Let me put it another way - what is to stop you just grabbing the source and whipping out a custom build? Just merge your theming changes in with my latest source - which I always release.
The last few times I attempted to merge my theming changes with your master I kept getting merge conflicts for every single time I tried to 'sync' up with your branch. I probably did something wrong to make the auto-merging fail on the same files every time I merged after you brought out commits. In the end, it just seems easier and more sensible to keep the changes in the primary MUSHclient repository since they aren't affecting your build anyway if you keep the manifest excluded from the installation. And if you were to put the manifest for versions that pre-date any of my theming-related commits, you'd have the bugs with CEditview as well.
Is there a reason you insist on reimplementing / seperating fixes rather than merging them with the full support of the git toolkit?
And in response to my recent suggestion:
Nick Gammon said:
Just merge your theming changes in with my latest source - which I always release.
You reply:
Worstje said:
The last few times I attempted to merge my theming changes with your master I kept getting merge conflicts for every single time I tried to 'sync' up with your branch.
So without wanting to sound too snaky, you ask why I don't just do things the "Git way" but admit that you yourself have problems doing just that.
So please bear with me when I seem to cut and paste for no apparent reason, rather than just re-applying your commits.
I see no inconsistency with Worstje's remarks. He's arguing against dividing changes. You tend re-implement changes instead of consolidating them, and Worstje is saying he'd prefer to consolidate his theming changes in the official repository. When it's not consolidated, and the split-off features have to be merged with every future change, it creates a lot of managerial overhead. But if everyone's on the same page, there's just the one-time cost of consolidating the changes.
All I am saying is that I can't always get Git to work in the way I expect - same as him.
So rather than doing nothing, or spending hours working out why, and possibly corrupting my copy, I look at the changes and see a handful of lines that need to be copied and pasted, and do that.
Not to imply anything, but there are tons of open-source projects that don't seem to have that problem. And not to put words in his mouth, but I think the problem is dealing with the conflicts, not forcing Git to do what you want.
If there's any specific issue you have with Git, I'm more than happy to (try to) help... :)
[EDIT]: As for corrupting your copy... I mentioned in my original t_regexp pull request that you can just create a new git branch and pull the changes into it, to give them a test drive separately from your master branch.
So without wanting to sound too snaky, you ask why I don't just do things the "Git way" but admit that you yourself have problems doing just that.
So please bear with me when I seem to cut and paste for no apparent reason, rather than just re-applying your commits.
Exactly, I have problems. I am human, and fully blame myself for being imperfect. Now, let's offset things a little...
I downloaded git for the first time on September 15, which is also the day I got my first taste of it. That's basically a good two weeks, three if you want to round upwards. During that time, I made my first steps into the MUSHclient source, wrote my first patches and did the research and debugging I needed to get done.
Git was written for busy busy projects with tons of merges, reverses, branching and so forth - the Linux kernel being the need of its creation. Thus, I assume git has good merging facilities, together with everything else one might expect, and so far it has not let me down. My own knowledge has been my limiting factor thus far, and I will work on improving that as I get more experience with the tool.
Do I expect you to be a git wizard? No. But as a project 'leader', do I expect you to go out of your way to do things manually that it can do for you with a bit of research, skipping the many errorprone actions that might result? I have only argued for the removal of human error, and the constant PMs/posts/notifications to you that you might have done something wrong. I know I'd hate it if people pointed out my mistakes every commit or two, so instead I try to offer a way in which you spend less time correcting, and as a result, spend less time getting annoyed with me as being the dude that always points out your mistakes.
Now, at this time my ability to merge this stuff from your branch with my theming each time manually causes me to have to re-merge on every subsequent pull. Yeah, I am horrible for not having figured all the details out yet, but it isn't as if there isn't a better alternative: leaving the code in as it was since it is not going to break anything, and to boot, anyone else who wants to build with a modern environment can have the added functionality.
And everything Twisol says is what I also feel - he just writes a bit more concise and less defensively than I do. :)
If there's any specific issue you have with Git, I'm more than happy to (try to) help... :)
Worstje said:
The last few times I attempted to merge my theming changes with your master I kept getting merge conflicts for every single time I tried to 'sync' up with your branch.
Twisol - how about helping Worste to do his merge?
I know. But if there are conflicts, Git must be unable to merge the changes without breaking something. It's not a matter of figuring out how to make Git do something, it's a matter of Git telling us it can't do something automatically. :|
We've talked briefly, but semi-speculating. He told me that the conflicts can be resolved, which makes sense (of course). The problem is that he had to re-fix the same conflicts after he pulled in the next set of changes from you. This would happen if you touched the same conflicting code again, but I don't see anything particularly odd in his network graph. I think it might have been around the time when you pulled in Worstje's theming changes, then reverted the majority of them, but I can't really say for sure.
