That's lspiderl if I'm not mistaken. Igabod's spelling is generally fine, he just uses neither punctuation nor paragraph structure. :smile:

David, not sure if you've used recent versions of git. It's just as easy to use as bzr or Subversion these days. I think so, anyways, and I have to use all of them on a near daily basis. (Ah, the joys of independent contracting, and having to work in a number of different clients' setups. Including the ones with no source control system at all… which always seem to be the clients with the most money and the biggest software budgets, oddly enough. :/ )

There are three reasons I discourage the use of Subversion. The first is perhaps a small thing to most people: it requires one to setup a master repository. It doesn't have to be a full server setup, but it's still an extra step and just one more thing to deal with that neither Git, Darcs, Mercurial, Bzr, or Monotone require. This in turn can be a maintenance burden when it comes to making real backups or moving hosts, as it's more crap to be remembered and moved. The second reason – and this is the big one – is that branch support is Subversion is practically right out of the stone age, due to the way Subversion stores commits and the lack of full merge tracking support. Subversion is flat out unusable for some development environments because of that. The third reason is that Subversion is just damn slow. I've seen svn updates on small projects take as long as a full hg pull on Firefox.

Your correct, |spider| was indeed the one whom mentioned having Dyslexia!

I last used git in ~March 2008, so it's quite possible its usage got friendlier since then. I should probably look into it again soonish: although I love bzr, it is a little slow for huge projects. And by 'huge', I mean far huger than any MUD: I'm talking millions and millions of lines of code with many revisions (for kicks, I tried adding some of our work repositories to bzr to see what would happen). Its speed compared to git is quite tolerable for MUD-sized projects.

btw, I feel like mentioning that it actually might be worth learning how to do things "the right way" even if it's just a personal project. If you plan on getting into professional software development then these kinds of little personal projects are really the best way to learn proper practice.

for the most part it's laziness. A small factor of it is also because i'm at work and have to break away every now and then to answer the phone or something and just don't feel like proof reading a post in a forum. I do not care anything about being "1337" and i'm not trying to be annoying. I simply am being me. I assume nobody else has enough of a problem with the way i type to say anything, and i'm sure if they did they would've said something already. I'm not writing a term paper or anything so i could care less about paragraph structure. My spelling is impeccable most of the time which is what most people pick on here so i'm sure thats why nobody picks on my punctuation and capitalization errors. Now that i've addressed your concerns, lets address some of mine. What seems to be your problem with me in particular? I've still shown you no disrespect and you feel the need to come out and attack me for voicing my opinion on the rudeness of your previous post. I'm an adult trying to resolve a conflict with another adult in the manner which adults are supposed to do things, yet i'm being met with the kind of talk one would expect in an online spat between two highschoolers. I just want to have a civil relationship with the people that frequent this forum, not constant dispute. I believe i am owed at least a LITTLE respect here because of the way i behave. You don't have to call me "sir" or anything, i just expect to have grown-up conversations on a site that is frequented by mostly grown-ups. And to The_Furey, you are mistaken as DH already mentioned, just thought i'd confirm that for you. Now, back on topic, what is so special about git that i can't do myself with tar -cvf whatever.tar whatever? other than making it easier to compare files, from what has been said it does nothing i would need. I already put the date on the name of my backups. I am the only coder on this project so i don't need to worry about somebody else screwing the code up, just me, so the merging feature isn't needed. I'm not trying to put down git or the other ones, i'm just trying to find out what it does that i cannot already do but need to do. Educate me please.

[edit because i skipped a word somewhere]

i don't have urge to do professional programming work anymore, i used to want to open my own software company but i've grown out of that desire, mostly cause my programming skill isn't advancing quite as fast as it should, also because i get bored with a given project rather quickly and like to move on before i've finished with said project frequently. i've got 3 different muds that i'm actively making changes on right now but next week one of those will be replaced with a different one. eventually i'll probably settle down on one project and see it through to the end, at which point i'll put into practice everything i've learned about how to do it right. Until that time however, i'm just having fun and isn't that the important thing? To me, coding is very much like dating women. When you just wanna have fun you tend to not follow the rules of having a successful serious relationship (code) and just go for the cheap thrills. All the while picking up more information on how to have a successful relationship (mud) in the future. Only difference is if i screw up with a chick i can't just go back and undo what i did by untaring the backup file.

I addressed your "rudeness" post directly. If there are any other issues you have with the post, then you need to be more explicit. I'm not a mind reader.

i'm just gonna squash any likely arguments arising from this thread by ending my part in the conversation regarding tyche's way of communicating with me. However now i have a problem that has arisen from my tinkering with the makefile that i would like some assistance with. now, whenever i try to copyover in the game it crashes but then comes back up immediately. the log files show do_copyover: execl: No such file or directory that particular line in the code is as follows:

execl (EXE_FILE, "../src/merc.exe", buf, "copyover", buf2, (char *) NULL);

i changed it from just merc to merc.exe due to what tyche informed me of previously. of course changing it back to merc doesn't fix anything, i'm just wondering if i should have left it as just merc in the makefile or if there is a different problem here.

Check to make sure EXE_FILE is the right path/filename. That is the argument that is the target
file to execute. The 2nd argument is really what will be argv[0] and is just normally passed as the
filename to the program (but is NOT used by execl() for the target).

thats definately the right path, in my src directory when i type dir i can see merc.exe

act_comm.c  bounty.c     dragon.h      kingdom.c   monk3.c    startup
act_info.c  clan.c       drow.c        leader.c    monk.c     string.c
act_move.c  clan_list.c  fight.c       low_act.c   monk.h     update.c
act_obj.c   clans.h      garou.c       low_misc.c  ninja.c    vamp.c
act_wiz.c   comm.c       garou.h       low_wiz.c   obj        warlock.c
arena.c     config.c     handler.c     mage.c      olc.c      warlock.h
arena.h     config.sys   highlander.c  magic.c     old.h      wizutil.c
backup      const.c      interp.c      Makefile    player.h
bit.c       db.c         kav_fight.c   merc.exe    rot_wiz.c
board.c     demon.c      kav_info.c    merc.h      save.c
board.h     dempowers.c  kav_wiz.c     monk2.c     special.c

But, is EXE_FILE defined as the right path (probably in merc.h)? Again, the first argument to execl(),
the one that is EXE_FILE is the path/filename used by execl(). All the rest of the arguments are just
passed to the spawned program and are not used by execl(). In other words, the "../src/merc.exe"
you have as the 2nd argument has nothing to do with the path/file execl() will use to find the program.

haha i didn't even remember that one, thanks for pointing out my stupidity sharmair.

Since you mentioned paragraph structure etc. and asked if people cared… :smile: I actually do care, quite a bit, but perhaps not enough to voice it as Tyche did. Proper use of punctuation and paragraphs makes it much easier to read and understand posts, especially as they get longer than a few lines in length. For example, I almost missed your question about VCS vs. tar because it was buried in a much larger paragraph about you talking to Tyche.

Finally, it is a matter of respect, really, to some extent: if somebody expects others to take the time to write well thought-out answers to sometimes complex or time-consuming questions, I think that the least that somebody could do would be to take the time on their end to write properly. Somebody who writes properly tends to be taken much more seriously than somebody who can barely string together a few sentences, and is forgiven things more readily. Somebody who gives the impression that they didn't spend any time on their post will not make people want to spend time replying to it. That is why people make comments about posts that have mistakes every other word.

Now to the topics at hand:


Archiving the code manually is of course far, far better than doing nothing at all. Using version control means it becomes an almost thoughtless process. For starters, you don't have to know what you changed (but see remark below). You don't use disk space unless you actually change things. Backing up your code – in case of a hard drive crash for example – becomes as simple as backing up the repository, giving you a backup of not only your current code, but the entire history of your code. You can track things like file renames with version control, which is something "dumb archiving" does not do. If you ever do decide to have other people on the project, all of the infrastructure is set up already.

Now, if you actually take the time to commit things with care, you can associate messages with your commits which serve as an indication of what you thought you were doing with the changes. Then, if you find a bug later on, you can look at your commit logs to figure out what the heck you were thinking a few days/weeks/months ago. It also makes it very easy to figure out which date you need to roll back to in case you know which change broke things way-back-when: just look for the right commit message, and roll back to right before that. If you use archiving for everything, you have to open up every single archive and manually inspect them to figure out which one is the right one.

In some cases, with version control, if you're a little clever with it, you can even selectively remove revisions and keep the changes after them. So you could go back, skip the revision that caused problems, and still keep the revisions afterward that fixed bugs.


Sure, maybe. Or, you just pick up bad habits without realizing it, and waste lots of time by taking shortcuts where doing it right in the first place would have taken only a little bit longer. Trust me, been there and done that. :smile:

If only, huh? ;)

You mean like what we all have to do when using g++ on gcc4.2+ with the const correctness of strings? :P

That's not a bad example, yes! :lol: Had people used constness correctly, and had people respected types correctly (e.g. don't treat a size_t as an int), the code would have been squeaky clean with the newer compilers.

A couple of points…
There are likely going to be follow-ups on why during the build process rm -f merc.exe or gcc -o merc.exe are failing because of access errors. Assuming at some point the OP actually sees the failure messages, whether they be suppressed or in the wrong color. Factoring in the use of Erwin's copyover code and Cygwin compounds the already lame practice of making the live executable the target or removing it prior to the build process. Now the general reason why removal of the target is bad is that the mud might crash and restart, be manually rebooted, or "copyovered/hotbooted" anytime prior to creating a working target executable. It's a problem independent of operating system and with players waiting for the game to return the situation is less than ideal. On windows, and this includes cygwin (as cygwin processes are windows processes), executables and dlls are treated as memory mapped files and are locked while the process is alive. There's a trick to get around access issues by installing a new executable by renaming the running one, before copying a new one and hotbooting the mud.

I'm going to assume that the live executable (the one the startup script and the hardcoded copyover point to) reside in the area directory, and that the build target executable resides in the src directory. They could reside elsewhere, but the point of the exercise is the build process doesn't target the live executable.

Again going back to the original Makefile..



Obviously if header dependencies are implemented through the earlier given information and links or the mechanism Elanthis suggested then 'make clean' is rarely used. And the path of implementing changes is…

make

Once a clean build is attained then…

make install

Followed by copyover (or restarting the mud)

Even for Cygwin? Windows is particularly anal when it comes to messing with files that are in use.

edit: rename actually works on in-use binaries, nice suggestion.

Yeah, to illustrate the issue…

$ cat getchar.c 
  #include <stdio.h>
  main() {getchar();}
  
  $ gcc getchar.c ; ./a &
  [1] 3560
  
  $ ps
        PID    PPID    PGID     WINPID  TTY  UID    STIME COMMAND
       5588       1    5588       5588  con 1000 02:21:09 /usr/bin/rxvt
       4508    5588    4508       6120    0 1000 02:21:09 /usr/bin/bash
  S    3560    4508    3560       5960    0 1000 15:27:37 /home/jlambert/a
       5320    4508    5320       5952    0 1000 15:27:43 /usr/bin/ps
  
  $ rm -f a.exe
  rm: cannot remove `a.exe': Permission denied

  $ gcc getchar.c        
  /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot open output file a.exe: Device or resource busy
  collect2: ld returned 1 exit status
  
  $ mv a.exe old_a.exe
  
  $ rm -f a.exe

  $ gcc getchar.c        

  $ ps
        PID    PPID    PGID     WINPID  TTY  UID    STIME COMMAND
       5588       1    5588       5588  con 1000 02:21:09 /usr/bin/rxvt
       4508    5588    4508       6120    0 1000 02:21:09 /usr/bin/bash
  S    3560    4508    3560       5960    0 1000 15:27:37 /home/jlambert/a
       5320    4508    5320       5952    0 1000 15:27:43 /usr/bin/ps

  $ rm old_a.exe 
  rm: cannot remove `old_a.exe': Permission denied