It has been 7 versions since a FULL source has been released, or so the forums state, but 4.19 has the entire source, you just have to go to the http://www.gammon.com.au/files/mushclient/src/
to get it.
I use MS Visual Studio 6, which is MSVC++ 6, which I believe is what you yourself used Nick, but haven't the foggiest idea how to use the "diffs" from version to version to amend source code.
Perhaps you could release the code every 2 updates, or 5 updates as a rule of thumb, cause I know that doing it every update would be taxing, unless you wrote a batch file in whatever language to do the task of zipping the source folders up and what-not, which might be the BEST thing for all that wish to jump on board, but are not totally familiar with the tasks required for compiling the program.
And again thank you for making Mushclient, it is a WONDERFUL program, and has given me MANY hours of entertainment on MANY muds.
That means, in the original file doc_construct.cpp, consider lines 49 - 54, and add (hence the +) the lines marked with a + sign (of course, excluding column 1, with the + in it).
Now those lines become 49 - 61 as shown above.
The other lines shown (the unmarked ones) are to put the diff "in context". It is known as a "context diff". The reason for the context is that if you had added some lines of your own further up, the patch program can still synchronize the correct place, because it does not totally rely on the line numbers shown. They are effectively a hint, about where to look for the correct context.
The other symbols you might see are ! which means replace.
Here is an example of a replacement:
*** localize.lua 12 Jun 2007 04:01:56 -0000 1.2
--- localize.lua 10 Jan 2008 01:24:53 -0000 1.3
***************
*** 19,25 ****
fo = assert (io.open ("Localize_template.lua", "w"))
fo:write ("-- MUSHclient localization file\n\n")
! fo:write (os.date ("-- Written: %A, %m %B %Y at %H:%M:%S\n\n"))
-- try to work out number of arguments (see sprintf format)
-- eg. %+06.4f
--- 19,25 ----
fo = assert (io.open ("Localize_template.lua", "w"))
fo:write ("-- MUSHclient localization file\n\n")
! fo:write (os.date ("-- Written: %A, %d %B %Y at %H:%M:%S\n\n"))
-- try to work out number of arguments (see sprintf format)
-- eg. %+06.4f
Here the incorrect os.date line was replaced with a different one.
Finally, if a line is removed it would have a "-" at the start of it.
As stated it was released for 4.19, BUT it is not advertised, that is the reason it is 7 versions since it was advertised in the Announcement posting for the new version.
Nick, you, yourself used the C++ 6 compiler from MS, so perhaps you could explain where in that is the patch feature.
I know that it comes standard with the GCC compilers, but this is MS we are talking about, and nothing is really standard with them.
Well, on the announcement post for version 4.21 it mentions where the diffs are. I was basically saving lots of new posts in that section for something that only a handful of people would use. However I see your point.
It is true that the patch program isn't part of the MS Visual package.
I see where you are coming from, a few years ago I used Visual C++ and had no idea what "patch" or "diff" was.
I use a hybrid set of tools these days. The whole idea of distributing a "diff" file is that it seems crazy for everyone to have to download 1 Mb of data to obtain what is probably 1K of differences from one version to the next.
It might be an option to make a VCS repository available. I'd be willing to maintain such a thing, but it's pretty easy to do. The hard part IMO is deciding which system to use. :-)
I would be much obliged if you would upload the diff tool you are using, or email it to my email address you have on file for me on the forums, as I would like to delve into altering Mushclient to allow full COM calls.
It is going to be a pain in the ass to do, because you have it implemented where the main application itself has no COM objects, it is the "Documents" it handles that have all the interfaces.
I have been looking at several tlb's and trying to see how things are done in the "global section" of the "Object Browser" of VB, and it is a separate interface named whatever, with a coclass named Global, referring to that separate interface. This CAN be done to allow you to query the list of open worlds with a few rewrites, and allow access to them via the named version. Although the GetWorld function will need another version created that DOES not do its queries from within a "Mushclient Document Class"
I would be much obliged if you would upload the diff tool you are using ...
I don't know if it will work without the Cygwin environment, but that is publicly and freely available. I suggest you get a Cygwin install going, making sure that the patch utility is part of the selected options.
It might take a while the first time, but you get gcc and heaps of other interesting stuff.
well being on dialup means that I will be downloading things for over 24 hours, I know, I've done it before.
I do however think I found a suitable substitute, i google'd for windows patch, and 6th down the page was "Patch for Windows" - http://gnuwin32.sourceforge.net/packages/patch.htm
Hopefully that will get the job done, if not I have several linux distros that are on CD's and can probably use vmware to load those and use it to patch things, but I would rather not use those to do the task.
-Onoitsu2
[Edit:] c:\Program Files\GnuWin32\bin\patch.exe: **** malformed patch at line 561: =========================
==========================================
Using version_4.21_diffs.txt from the location you have it uploaded.
That particular line seems to be changes to the help file contents: mushclient.cnt
It looks like the linefeeds are somehow missing from that particular bit. Since you probably aren't too interested in the help file (which you have anyway), I would delete that part of the patch file (edit it and you will see what I mean - delete the faulty bit between the ====== symbols).
http://www.cs.purdue.edu/homes/trinkle/RCS/ has Windows binaries (no Cygwin required) of GNU RCS, which encludes both diff and merge, but I am not sure how you would go about patching source that isn't under version control.
VCS would be my preference, although the problem is agreeing on which VCS to use; I'd prefer bzr myself. :-) (but could live with git too) As I said, I would be willing to host and maintain the repository based on Nick's source releases.
Given the choice of VCS and SVN, I would choose SVN, for although it is evil, there is git-svn. I do not know if there is a git-vcs. Besides, git was written by Linus, and who can argue with that? *dives under desk awaiting flames*
Just whatever is decided, do not use CVS... I still have nightmares about that one from college. This is not exaggeration, it really is the cause of some bad dreams for me.
VCS is just a generic term for version control system, so I'm pretty sure there is no git-vcs. :-)
(What I meant when I said that VCS would be my preference was that I would like to have a VCS repository around instead of diff files. That way you solve all of these problems with one stone.)
I'd rather use git over svn myself. I'd rather use bzr over all others. ;) But git is certainly much better than svn IMO due to being distributed (the reason why I like bzr). bzr also has export capabilities to svn and cvs (evil though it may be).
And hey, if git is supported by Linus, what about bzr being the VCS behind all of Canonical's development? *ducks and covers* :-P
I don't want to personally set up a git / svn / whatever server, however I have absolutely no objection if someone like David wants to set one up that is publicly accessible. He could keep the "official" source up to date by simply applying the diffs as I release them.
Some of the version control systems also allow you to view the pretty-printed (or at least, syntax-coloured) source directly on the web, which would be nice too.
I should point out that if anyone is having problems processing the diff files, because they don't have Linux or Cygwin, or for whatever reason, they may also have problems with git / svn / cvs. For example, they may not be supported under Windows, or may be confusing to use. I certainly found setting up a repository confusing.
David: Bah, must learn to not read and talk while typing. Replace everything in my last post about "VCS" with "bzr". Also, it is hard to argue with a company that backs Ubuntu, but still... Linus' Resume: Linux! Also, Linus is no longer in charge of git. It is just something he made because he was bored for a week or so, then decided to go back to kernel development. I honestly do not have a problem with bzr, I just really like git.
Nick: Both git and bzr have windows binaries that run just fine. No need to worry about cross-platform capability. I like the idea of bzr, but never used it, git is simple, and would not require much more than how you are hosting the source currently. SVN is evil, but it works well, and I can just use git-svn and ignore the fact that I am really using SVN.
So has the debate been settled on the method of source release?
-Onoitsu2
[Edit: I found out why things would not patch, cause I was attempting to patch from version 4.19 up to 4.21, and it was looking for 4.20 in several locations, as well as in the mushclient.cnt there are a few alterations since 4.19 and 4.20 that I don't understand in the diff formatting.
Perhaps you could upload the 4.21 source, and every version you could do a diff of it, instead of posting the change, like the XML one in 4.20 has, as there must have been a few other things since then that changed, in things like the mushclient.cnt for instance.
[Edit#2: The patch tool I downloaded from http://gnuwin32.sourceforge.net/packages/patch.htm works WONDERFULLY, you just have to go to a cmdline to use it, it is so simply done, CD to the dir the files are located in (c:\programming\altered\mushclient), I typed in from there "c:\Program Files\GnuWin32\bin\patch.exe" (used tab completion :-D) SPACE < diffs.txt (I renamed the version_4.21_diffs.txt for ease of typing)
Entire line inclufing prompt:
C:\Programming\altered\MUSHCLIENT>"c:\Program Files\GnuWin32\bin\patch.exe" < diffs.txt
I can patch using the standard tools without trouble.
As for the debate on releasing source, I'm just waiting for people to say they'd actually like to see a repository before I set it up. Since you asked for the change in the first place I guess that means I'm looking at you Onoitsu2. :-)
I'm probably going to settle on git because more people use it than bzr, although that means I'll have to learn how to set it up. If it's anything like bzr, though, that will be a very easy process...
I found out why things would not patch, cause I was attempting to patch from version 4.19 up to 4.21, and it was looking for 4.20 in several locations, as well as in the mushclient.cnt there are a few alterations since 4.19 and 4.20 that I don't understand in the diff formatting.
Yes there would be a couple of spots where the version would be different, I didn't really count that as a change. My intent was, that armed with the diff file, you could create version 4.21 easily enough.
Technically a change to the help file isn't a change to the source of MUSHclient.
You could make out a fairly strong case that the diffs are actually preferable than a full release of the source, and here is why:
If you merely want to recreate the exact source I have, why not just download the executable, and not care about the source? Or, if you want to see the general way things work, a version or two back is fine.
However if you start making your own changes (like adding some new feature) then the diffs are easier to work with. Being context diffs they will add my changes/fixes and leave yours in place too.
If you get the full source each time (and not diffs) then any changes you made are lost of you switch to the new version.
Nick I do realize this, I just would like to be on an even level with what has been released thus far, so that I can start from there, as you just added several commands to Mushclient recently, between v4.20 and 4.21, if something like a minor tweak to a single function, like that that was done for version 4.20 and the XML Save Double function. But when you add multiple commands and other things, then it kind of complicates things.
A version control repository, especially a modern distributed one like git or bzr, makes it even easier than using patches and diffs to maintain branches of a given code base. Let's assume Onoitsu2 wants to have a derivative of the core MUSHclient code. He branches the main repository, and then starts work on it. When a new version is released, and the repository is updated, all he has to do is merge with it to receive all changes that were made -- and maintain his own changes.
I agree that a full source release is not the best option. But a VCS really has the best of both worlds. It lets you have the full source now if you want it, in addition to getting an arbitrary version of the source, or getting diffs, or branching and following development, or . . . ... basically it lets you have the fullest control that can be reasonably expected over your code vs. the central code.
I had the same problem with the patch file mentioned above, it didn't work with either the Windows or Linux versions of patch (which handle line endings differently). Maybe it's the VCS spitting out invalid patches.
FWIW, Bazaar also gets my vote as a version control system. Unlike CVS and the like you don't need to read a whole book to understand how it works, and there's no need for a centrally hosted repositry. The setup would consist of Nick typing "bzr init" in the mushclient directory.
Yes I could type that easily enough, the problems are:
That particular PC (which I use for MUSHclient source) is not turned on all the time - which is the case for all my PCs.
I have a firewall and would need to open up an incoming port to allow people to access the source
I am not sure I want to make publicly available my "home" IP address
I am not sure if the gammon.com.au web server allows source repositories to run on it - it is a web host after all.
I like the idea in principle, but need a host for the source, other than my own private PCs. Perhaps SourceForge would do it, although I have never used that before to host stuff.
I'm no expert but I know you can use Bazaar without really publishing the repository at all. You can make a .zip file of the source with "bzr export" and upload it for others to download and work on, and they can use "bzr send" to make a merge directive, which is a zip file containing a patch with some extra metadata, and email it to you for integration. Of course as the person who has to do the merging you're in the best position to know whether that would be worth the extra hassle.
Also, Bazaar will work read-only over ordinary http, so if you wanted you could do source releases by uploading the source tree to a directory on a web server, and people could "pull" from it directly.
Well, doing a "cvs export", zipping it up, and uploading that file to my web site is pretty-much what I currently do, so I don't see I have got much further down the track.
Again, I would be happy to host a repository, whatever flavor ends up being chosen. Nick, I believe that you already have access to a the-haleys.com account anyhow. :)
As for what is gained by having the repository available online: it lets people see the history, not just the current state. Indeed having the current state is what already exists; having history is what is missing.
You probably also need to change the version number in doc.h and readme.txt.
Then you could apply the patches for 4.21.
However if you made a checkpoint or whatever bzr calls it we would have at least 3 versions of history. From then on I could supply you with the patch file (or do it myself) to keep it up-to-date.
If you wanted to start with an earlier version (eg. 4.01) then I could apply (or send) the subsequent patches so you can get it up-to-date.
Yay, a repository! Now if only Micro$oft would drop the price of MFC. And as for what version to start with... 0.63 :) Really, anywhere from when MUSHclient became open source to now would be fine as a starting point.
I quite like the idea of a web-based access method for nice pretty-printed source. At least I can point to various places and say "this is how I did it", and maybe someone can say "but here is a neater way".
Great! I will take care of this right after my exam in an hour. :-)
And Nick, I can create the patches fairly easily myself by just extracting source files on top of each other and let bzr figure it out. Then, I can just grab the source archives you already have online rather than bother you for patches. :)
And yes, I also know of a way to get nice pretty-printed source code diffs, which I will set up as well. If you'd like to get a feel for what it looks like, see:
http://www.binarygoblins.com:8088/
I haven't kept those up to date; it was mostly an experiment to see if it worked. (The "last changed" dates are a little weird, though...)
I have started to build the repository history from version 4.01. It's taking a little longer than expected because I cannot apply the diffs as-is; the line ending formats are messing things up and AFAICT I can't tell patch to leave the CRs in the diff file -- it insists on removing them. (--binary doesn't seem to do anything -- and it says it does nothing on POSIX systems.)
And yeah, I didn't realize you meant coloring of the code, and not just the diffs... oops. :-)
There are a few unix2dos and dos2unix utilities around that will fix up line endings. There is one version in the Downloads area here.
And for fun, I wrote one in Lua, which you can run from the MUSHclient immediate window. This one gets rid of \r from the file, you could modify it slightly to add them back.
-- get file name
local filename = utils.filepicker ("Choose file to convert")
if not filename then
return
end -- no file
-- read original file
local f = io.open (filename, "rb") -- binary mode
local s = f:read ("*a") -- read entire file
f:close ()
local count
-- convert file
s, count = string.gsub (s, "\r", "")
-- write converted file
f = io.open (filename, "wb")
f:write (s) -- write entire file
f:close ()
-- show summary
print ("File " .. filename .. " written, "
.. count .. " carriage-returns removed, "
.. " new file size is " .. #s .. " bytes.")
(EDIT: note that a few of the lines also need spaces at the end... kind of annoying to show here, and probably doesn't really matter... and using the --ignore-whitespace option makes patch ignore the problem.)
Yes, well I am not certain what happened there, except that perhaps the "enormous mutant star goat" (to quote from The Restaurant At The End Of The Universe) got to it.
Strictly speaking, the help "contents" file is not really part of the source, so I wouldn't be too concerned about it.
One last problem; it appears that there is no diff or source archive for v4.20, but the diff for v4.21 seems to assume that it's patching 4.20. Could you send me a diff from 4.19 to 4.20? Once I get that I'll have every version since 4.01 in bzr version control. :-)
OK, all done, just need to go about making it publicly viewable in some sane manner. The repos are accessible but not in a nice graphical way at the moment:
Make a directory "zlib" at the same level as the MUSHclient source directory (in my case mushclient-4.21), and unzip the files into that zlib directory. This will be a once-off operation, as zlib won't change from version to version.
Don't make the directory inside the MUSHclient directory, make it adjacent to it (so mushclient-4.21 and zlib directories are at the same level).
Missing file forcelib.h.
Because of some obscure problem, I had to add the include below into the zlib source (that is, the files downloaded in the previous step).
However the include refers to a parent "mushclient" directory, not "mushclient-4.21" and thus the compile fails.
To fix this, copy the file forcelib.h from the MUSHclient source directory into the zlib directory.
Then for each file that gives the error change:
#include "..\mushclient\forcelib.h" // see ID: Q148652
to:
#include "forcelib.h" // see ID: Q148652
(That is around 15 .c files).
That should compile cleanly then (the zlib steps are a once-off because that directory will not change after this).
However to run without errors you need a couple of DLLs - Lua and the DLL with the English resources in it.
Use a current MUSHclient distribution and copy these files into the WinRel directory (the one where it put MUSHclient.exe into):
lua5.1.dll
The entire "locale" directory (that is copy "locale" so it is a subdirectory of WinRel").
I think the problems you had with mushclient.cnt file is because it was marked as binary in my cvs repository. I have changed it back to text, I think.
Quote: I think the problems you had with mushclient.cnt file is because it was marked as binary in my cvs repository.
Oh, that might do it. I did notice, by the way, that some entries in the patch file were of the form: "binary files X and Y differ" -- but with no indication of how. So those binary files didn't get patched.
Quote: The directories shown there seem empty, David.
Indeed, that's normal actually. It's just a directory that holds the .bzr directory that tells bzr clients how to get the source. See:
http://www.binarygoblins.com/~david/bzr/mushclient/mushclient-4.21/.bzr/
It's the URL that you give to bzr, not a URL that humans are supposed to be able to read. The actual files are stored elsewhere, in a "shared repository":
http://www.binarygoblins.com/~david/bzr/mushclient/.bzr/
From there you can explore the 'repository' directory, although frankly I can't really make much sense of it directly. :-)
What's nice about the shared repository method is that the whole repository (all 17 versions) takes up only 9mb. The bzr branches are rather "light" in that sense; they don't require duplication of data, yet they all maintain they own state. (This isn't a feature unique to bzr, but I think that e.g. cvs doesn't do this.)
Anyhow, I'll apply those patches you posted and then go about putting up the pretty interface I showed for the FUSS project stuff.
I've added version 4.22. I also removed doc.ico from previous versions. Finally, I created a new directory for the zlib library with the forcelib change applied.
Now to finish making the repositories nicely visible...
As a note, when I'm done with this, I'll make a friendlier URL than the existing one. Something like www.binarygoblins.com/mushclient/bzr, perhaps.
OK, I have at least a first version done... Please see:
http://www.binarygoblins.com/mushclient/bzr/
That lets you browse the repositories.
You can "check out" a repository by using:
bzr branch [repository url]
where the URL is obtained from the "[Repository]" link.
To view the history of a repository, click on "[Log]". (Note that a given version will include the history of all previous versions, too.) You may browse a repository's contents by clicking on "[Inventory]".
I set up a simple page for the repositories so that if you click on "Repository" it'll give you an indication of what's going on instead of just giving a blank directory list.
At one point I'll try to figure out how to customize that page to make it more MUSHclient specific; in particular I would like to change the page title, have a link back to this site, maybe have brief compilation instructions (or a link to one of Nick's posts), etc.
Nick, if you could update the 4.22 announcement to use the new repository URL that would be nice. (I'm going to delete the old URLs soon to clear up clutter.)
Yes that looks very nice David. I have amended the link on the client release announcement page.
If anyone wants to see exactly what is in the new version click on "Mark for diff" for an earlier version (eg. the one just before the current one), and then when the page refreshes, click on the "Diff" button for the current version. This shows all the source changes.
The source looks nice too, some of the spacing is a bit out, that is probably my fault in a way. I usually have tab stops set to 2 apart, and if the occasional tab crept into the source (rather than 2 spaces) they are being displayed on the web page with more than 2 spaces.
If there is some way of making the style sheet or whatever it is, that displays the source, default to tabs 2 apart that would make the display slightly better.
How odd... I'll have to look into that. The web interface is relatively new, I believe, so it could be a bug of theirs. I'll take a look at their code and see what they're up to. It could be a pretty quick fix: you'd assume that not being able to see subdirectories would be an easy bug to spot!
I disabled the .targz zip to not put too much load on my server -- it would have to generate a .targz every time somebody clicked that list. The better way to get the source is to install bzr and use it to download the source:
The file bzr-setup-1.2.0.exe is a 5.65 Mb download, so there is a bit of an overhead the first time. It should theoretically only download changes once you have the full version downloaded, although when I tried recently with the link David gave above, it seems to be downloading the whole thing again. Maybe it didn't realize it was a version of the earlier download.
Quote: it seems to be downloading the whole thing again. Maybe it didn't realize it was a version of the earlier download.
Once you have downloaded it with a "bzr branch" command, you update it by going into the branch you created and doing "bzr pull". If you do that, it only downloads what is necessary.
Quote: It doesn't cache it? [the downloaded archive]
I don't think so; it's a fairly simplistic web interface. I'll check, though.
Quote: Anyway, I'd have to install a program to DL the source?
Well, we're talking about the version control here, not just the source. What you're getting is the entire history of all MUSHclient versions.
I agree that it would be nice to have an archive of the most up-to-date version without having to install a VCS to get it. I'll look into that caching business.
I think this is the right thread to continue,
What happened to the BZR server? It continues to be announced in the release announcements, but seems to be down every time I try to access it.
I apologize for the server downtime. I packed my apartment up into boxes almost a month ago, and have just barely finished the initial unpacking. I'll be getting the server up in a few days, at which point the bzr repository will be available again. I'll make an announcement when that happens. Again, sorry for the downtime.
The server is back up, although my internet connection has been having some issues since yesterday 6pm. I will be catching up to the versions I missed while the server was down shortly.
Everything is normally accessible again, except that because my "friendly" ISP blocks port 80, you need to use port 8080 instead. So, you need to go to: http://www.binarygoblins.com:8080/mushclient/bzr
Again, I will be catching up on the versions ASAP.
From now on that should be updated immediately when new versions are released, or indeed before the release, so you can see the work in progress before a release.
