Rob Baumstark <shirak@CONNECT.AB.CA> writes:
> 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.
I agree completely; this definitely isn't the place (if there even is
one) for an advocacy debate. However, there _are_ tools that
originated in the Unix world that have been ported that we can take
advantage of.
> >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.
I agree completely :) We should use small functions to access the
data (somewhat akin to C++ methods, except we have explicit function calls).
> >(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.
I'm not meaning to say that VC++ is a bad compiler. By alien I meant
it wasn't taken into account during the original coding. A Unix
compiler and a Windows/Mac compiler are two fundamentally different
beasts. But with Cygnus' Gnu-win32, we don't really need to support
VC++ as much as we do -- circle will compile and un unmodified under
this compiler (I believe, please correct me if I'm wrong; I know
though that it is very little work).
> >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.
It also makes dependancy checking harder (though that is handlable by
gcc -MM). It doesn't save nearly as much time as people believe, though.
> >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.
I don't think they should be a pre-requisite. Nor do I think we
should all use the same development environment. But we could take
great advantage of what is available with minimal effort. I've seen
50, 60, 70k patches that do the work of a 5 line sed script, yet won't
work on modified codebases; the sed script would. (I can provide a
definite example I refer to in my response to George -- the conversion
of the full "struct char_data" to CHAR_DATA throughout the code, as
well as the other structures).
> >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.
People shouldn't use different parameters. But there's no need for me
to repeat myself, see my comments in my response to George :)
> >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.
The indent program (that George pointed out is already used) allows
for uniform code indentation. Picking a style is hard, but we should
try to be consistant. Remember, making diff's can be a mess if the
indentation is different (though I hope everyone makes diffs straight
from stock).
> >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.
Hewlett-Packard wrote it, I believe. See my comments in another post;
C++ isn't the direction circle should head IMO.
> >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.
I agree completely. This thread touches on a lot of topics near and
dear to many (OSs, compilers, development environments). We
definitely don't need flamewars here :)
> >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.)
This brings up an interesting point. Has anyone done any kind of
survey to see what different platforms are being used? How many
Windows people, or Mac people?
--
James Turner turnerjh@xtn.net
http://www.vuse.vanderbilt.edu/~turnerj1/
+------------------------------------------------------------+
| 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