> >5. Unix tools. I can't say how many times I've seen patches posted
>
> PERL is always a good solution, as it is available on all platforms, and
> scripts are (mostly) write-once run-anywhere. Besides, there aren't too
> many UNIX tools needed.
Perl is a fantastic tool. It is a superset of the functionality of
sed and awk; however, its flexibility comes at a price. A one-line
sed command can take multiple perl lines (unless you with to
obfuscate, in which case it can be smaller). Perl, though, would be
an excellent support language for Circle.
> >everyone reading this should go download Emacs. It's hard to learn in
>
> If you have a MacOS, Win95, or WinNT station, I recommend CodeWarrior.
> It is far superior to any development environment you will find, and
> costs only $400 ($100 for students). I'm sure anyone here who has used
> CodeWarrior will agree. Plus, coding locally in a full GUI, with
> multiple windows, searches, and more, is much more efficient than coding
> remotely via telnet and vi/emacs/joe/cat/grep/whatever.
I was being somewhat facetious in my post; I did not literally mean
everyone should run over to www.gnu.org and get Emacs (though you can
of course... *nudge nudge*). I do, however, feel that Emacs is the
best development environment available for Unix or Windows (no Mac
version I don't believe).
I've heard good things about Code Warrior, but I've never used it.
However, I think your comment about it being far superior to other
coding environments is somewhat hasty. Emacs + gcc + GNU make is IMO
the best, though not perhaps for visual development. They are much
older products, have fantastic support, complete expandability, and
are used around the world -- and have been for over a decade. The
Free Software Foundation has done a fantastic job providing the world
with open sourced development tools that are second to none.
Moreover, Circle is inherently a Unix program.
Code Warrior is, I have no doubt, a nice development environment. But
I firmly believe there is better out there :) We can continue this
discussion in email if you would like; I'm certain the others here
aren't interested in this tangential discussion.
> >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
>
> What would you replace these with? The only real solution is to replace
> them with the full syntax, which will increase filesize and decrease
> readability.
Full syntax is exactly what I suggest. Increasing file size is a moot
point. It maybe adds 60 bytes per function. A hundred functions and
that's 6k. That's a non-issue. Moreover, it doesn't decrease
readability. The ACMD is nice in that it helps specify a command;
however, it hides the actual declaration, as well as hiding the
variable names that are passed to the function. There is absolutely
no need to hide declarations. Shorthand notation like this is
somewhat convenient; however, it is not what the preprocessor was
intended for. The preprocessor extends a language, not redefines it :)
> >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
>
> I have yet to see a symbolic debugger or profiler (of two drastically
> different kinds of each that I have used) that has had a problem with
> ACMD/ASPELL.
I don't recall what program I used that had issues with it. I think
it was a cross refrencing program, but I could be mistaken. Most
programs can handle it correctly. However, it is an ugly hack of the
C language, and unnecessary. Surely we are capable of writing the
full declarations for functions?
> >mistake or some other issue ;) Also, it would be nice if all the code
> >conformed to one style. I have an indent script I use for my own
>
> Almsot everyone has their own personal style, and no script can produce
> perfect indentation - there are always exceptions.
The indent program is quite good. It breaks the source file down
using the C language's grammar. It doesn't make mistakes, generally
(at least not in my experience). I'm not saying any indentation style
is best; however, consistancy would be nice.
> >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,
>
> Where is GTK available from? I assumed it was a GNU package (given the
> undescriptive name, and the g- prefix), but it is not listed on the GNU
> ftp site.
GTK is a windowing toolkit. The Gimp uses it, as well as the Gnome
project, and a growing number of other programs.
>
> >though glib itself is cross-platform I believe, gtk probably doesn't
> >port to Win32 yet.
>
> If I can find it, I'll see if I can port it to MacOS.
I don't think ports have been worked on. However, the glib subset is
quite portable I believe -- it doesn't use any graphics. It is simply
a library for use in C programs.
--
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