I agree with most of this, though there are a few things I'd like to comment
on. I too have been mostly just listening, gathering what info I can from
the list, posting something when I think I can help. Before you read the
rest of this though, PLEASE don't start another of those Win VS Unix
arguments because of this. I can tell by reading the original that the
author likes Unix, well I am a Windows person, and I think that CircleMUD
should be developed for both.
>1. The biggest issue in my opinion is the use of macros. Macros
>definitely have their place, but computer speed has increased so much
>since the first circlemud that they become less and less of a speed
>issue.
I definatly agree here. Sometimes I really like macros (like the MIN / MAX
ones), but in a lot of places (eg. REMOVE_FROM_LIST) they can be a pain.
>(Additionally, for speed issues, gcc allows for the inlining of
>functions, even in C code. Perhaps VC++ provides a similar facility,
>but with the progression of Cygnus' gnuwin32 [which I am assuming
>supports inlining like this], I see less and less need to explicitly
>support such an alien compiler).
Though you may think of it as alien, I think it is a great compiler, and I
see no reason to stop supporting it now, after a lot of work was probably
put into getting support in the first place. I am planning on making a
patch/port that will compile cleanly under the Borland compiler as well. I
know that VC++ does support inlining.
>3. Layout. The code in circlemud is, to be honest, poorly laid out.
>The file divisions are usually fairly accurate, though there are many
>contradictions and oddities in the code that make it hard to
>understand what functions belong in which files. I personally use
>Emacs and etags, so this is much less of an issue, but it is still a
>design issue that needs addressing. Also, we need a single .h file;
>having several is a real problem.
Here I agree with one of the other comments I read on this message. Having
multiple .H files is a good thing. It may make editing a bit harder, but
the amount of time it saves when recompiling makes it worth it.
>Another layout issue are player directories. I personally like having
>a binary database (which allows for easy statistics gathering at the
>expense of offline maintenance, more on this later) and separate
>pfiles for info which grows (aliases, eq files). However, the
>structure makes it hard to administer. I've changed the layout on my
>mud to store pfiles in directories like this:
I too like the binary database, and have separate files for growing files.
>5. Unix tools. I can't say how many times I've seen patches posted
>for things that would be pretty simple to with a few lines in a bash
>script. Again, Cygnus saves us here, providing a large number of very
>useful ports of GNU tools (sed in particular comes to mind, though I
>assume there are other ports available). There are a LOT of useful,
>powerful tools out there... we need to take advantage of that! Also,
>everyone reading this should go download Emacs. It's hard to learn in
>that it is very different than anything else out there, but once you
>do, you'll be twice as productive, or more.
Here I have to complain a bit. I have a Linux machine here too, and I like
a lot of the tools, but making Unix tools a requirement for CircleMUD I see
as a bad thing. As I said before, a lot of work has probably been put into
CircleMUD to make it run under Windows, and I don't think we should start
going Unix-only now. Some of the Cygnus tools are great too, but I've
managed to get by without them too (I have been running a CircleMUD under
Win95 for about 1 year.) I also think everyone should choose their own
editor. In Win95 I like the editor in Developer Studio. When I use Linux,
I use VIM (I also have Vim for Win32) Each editor has it's own strengths
and weaknesses, go with what you know.
>6. Code appearance. Circle is in most cases readable; however, there
>are times it isn't. In particular, the use of typedefs can simplify
>things. Also, we need to get rid of ACMD and ASPELL (something I did
>straight off). They are a convenience in the initial writing of a
>command or spell, but they are an abuse of notation, so to speak, and
>can cause problems with symbolic debuggers as well as cross
>referencing programs. Generally, for every time you're lazy when you
>code something, you'll spend three hours later fixing a shortsighted
>mistake or some other issue ;)
I very much like ACMD and ASPELL. I haven't had any problems with them
debugging or anything, and the VC++ browse tools (like the tags things in
unix) work fine with them too. I think not having them would cause even
more problems as people tried to create commands with different paramater
lists, and then the Master Command List wouldn't work anymore.
>Also, it would be nice if all the code
>conformed to one style. I have an indent script I use for my own
>(though I don't need it often since I let emacs do my formatting for
>me) which reformats all the code to a specific style. It's quite
>useful.
VC++ 5 has a built-in indent function. Besides just indenting while you
type, it can also re-indent files, which is great because all of the stock
code uses 2 spaces, while the default setup in VC++ uses tabs that are 4
spaces long.
>7. Linked lists. The current linked list support is, well, somewhat
>dirty. Imbedding next elements into all the structures then using the
>REMOVE_FROM_LIST macro is extremely ugly. We need to get a simple
>linked list library written (a fairly simple task), or use one out
>there. I personally use the singly linked list class from glib (a
>subcomponent of gtk, which provides a large amount of common C
>algorithms and structures, including hashes, lists, and I believe
>trees), which is exactly what we need. The only downside is that,
>though glib itself is cross-platform I believe, gtk probably doesn't
>port to Win32 yet.
There is an STL that comes with VC++ that is portable to Unix. (It comes
with VC++, but it is not produced by Microsoft) I'm not sure if it meets
all of CircleMUD's needs, but if anyone wants to look at it, e-mail me and
I'll send you a copy.
>Okay, that's it for now. I hope no one construes this as any kind of
>flame -- I am a big circlemud supporter (I wouldn't be coding one if I
>weren't). But we need to think about the future.
I hope you take my comments the same way. I really hate it when the large
flame wars get on here every once in a while. If you have nothing nice to
say, don't say anything at all.
>PS: Has anyone done any work on an X based pfile database editor?
>I've been toying with gtk lately and am considering writing one.
>Would this be useful to anyone? I'd like to keep it flexible enough
>to handle changes to the char_data structure without much rewriting.
>Is there much demand for this? I personally don't like ascii pfiles
>since it fragments what I consider data that belongs in a central
>location... however, ascii files definitely are much easier to work
>with.
I was thinking of writing a Win32 one, but I decided not too. If there is a
large demand I still might though, e-mail me about it (not the list.)
------------------------------------------------------------
G: "If we do happen to step on a mine, Sir, what do we do?"
EB: "Normal procedure, Lieutenant, is to jump 200 feet in
the air and scatter oneself over a wide area."
-- Somewhere in No Man's Land, BA4
------------------------------------------------------------
Rob Baumstark: shirak@connect.ab.ca
cst0656@nait.ab.ca
------------------------------------------------------------
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/15/00 PST