08 Mar, 2009, boblinski wrote in the 1st comment:
Votes: 0
I was just wondering what the different compilers I can use for ROM2.4 if I'm on a Windows XP operating system.

I'm currently using Cygwin but I don't find it very informative when it comes to Bugs and Mud-crashes..

Any advice?
08 Mar, 2009, Tyche wrote in the 2nd comment:
Votes: 0
There's quite a few free compilers and tools. I've linked to some on my site.
Note that compiling under Windows with a native compiler entails some changes to the code.
However, you will find just about any C compiler to be as "informative" as Cygwin's GNU gcc/gdb.
That is error messages, stack dumps, debugging are difficult when you don't understand the language or the system.
08 Mar, 2009, quixadhal wrote in the 3rd comment:
Votes: 0
There is also the option of running linux in a virtual machine. If you don't have VMWare, I've heard good things about Sun's free VirtualBox. Of course, if you don't want to do the OS install yourself, you can always download an already-installed VM, and use VMPlayer (free) to run it.

I've seen quite a few threads devoted to people struggling to get things working under cygwin, and I certainly understand not having a spare machine to run linux on, or wanted to deal with the hassle of installing or learning it. However, the amount of energy being spent to learn cygwin, and how to work around the places it doesn't cover, far exceeds the amount you'd spend running a VM, IMHO anyways.

Personally, I have a VM of Debian 5, installed as a server (no X windows GUI). It's setup to use 256M of RAM and have a 2G hard drive, of which about 1.5G is in use with several MUD codebases sitting there under development. When I feel like working on something, it takes about 20 seconds to start the VM, and then I ssh into it like any other unix box, and when I'm done it takes another 20 seconds to do a proper shutdown. I can then pack up the whole thing using WinRar and it fits on a CD (just over 500M) for backups. I can even punch holes through my firewall and let people play the game on the VM (using bridged networking).

I have a real file server which I used to use for most of my development, but it's an older 900MHz P3, and running a VM lets me using my (also older) 3GHz P4 to compile things repeatedly, meaning I have less time to go get more coffee. :)

If you're genuinely happy working in the Windows environment, and using the cygwin emulation library to pretend you're on a unix system, more power to you! I just think that since most MUD's were written to run in a unix environment, VM's are a reasonable solution to not having (or wanting) spare hardware, and a better fit than an imperfect emulation library. Cygwin fans, get those flamethorwers warmed up I guess.
08 Mar, 2009, David Haley wrote in the 4th comment:
Votes: 0
There's been an alternative to Cygwin that's been discussed a fair bit called AndLinux. It's apparently quite popular with people who use it, although I haven't used it myself (as Linux is my primary desktop). Just ask The_Fury, I'm sure he'll tell you all about it. :smile:
09 Mar, 2009, Tyche wrote in the 5th comment:
Votes: 0
The issue is the poster didn't know what structs or boolean operators were two weeks ago.
The damn operating system or compiler doesn't change that.
Learning C takes time.
09 Mar, 2009, David Haley wrote in the 6th comment:
Votes: 0
Ah, I hadn't noticed that the idea was to get a more informative compiler/OS. In that case, indeed, the choice of OS and compiler is basically absolutely irrelevant.
09 Mar, 2009, The_Fury wrote in the 7th comment:
Votes: 0
David Haley said:
Just ask The_Fury, I'm sure he'll tell you all about it. :smile:


Yeah im like the high guru of Andlinux.
09 Mar, 2009, Dean wrote in the 8th comment:
Votes: 0
Tyche said:
The issue is the poster didn't know what structs or boolean operators were two weeks ago.
The damn operating system or compiler doesn't change that.
Learning C takes time.


I'll second Tyche here, that OS or compiler isn't going to make much of a difference. Take your time with it, it'll come eventually.
09 Mar, 2009, boblinski wrote in the 9th comment:
Votes: 0
The thing that annoys me is errors/bugs like this:

Quote
Mon Mar 9 20:52:21 2009 :: Loaded 1 mobprogs.
Mon Mar 9 20:52:21 2009 :: Loaded 1 mobprogs.
Mon Mar 9 20:52:21 2009 :: [*****] BUG: Equip_char: already equipped (3).
Mon Mar 9 20:52:21 2009 :: ROM is ready to rock on port 9999 (0.0.0.0).


How am I to know what file this is, let alone where in the file…
09 Mar, 2009, Tyche wrote in the 10th comment:
Votes: 0
Those messages are produced by the mud and they aren't all that enlightening.
I would guess they come from a function named equip_char.

There's a utility called grep, which you can search for things in files

For example from the shell command line…
$ grep -n equip_char *.c

This searches for the occurance of equip_char in all the files ending in .c in the current directory. The -n option tells it to display line numbers.

The output might look like this..
act_obj.c:1362: unequip_char( ch, obj );
act_obj.c:1395: equip_char( ch, obj, WEAR_LIGHT );
act_obj.c:1411: equip_char( ch, obj, WEAR_FINGER_L );
act_obj.c:1419: equip_char( ch, obj, WEAR_FINGER_R );
act_obj.c:1440: equip_char( ch, obj, WEAR_NECK_1 );
act_obj.c:1448: equip_char( ch, obj, WEAR_NECK_2 );
act_obj.c:1463: equip_char( ch, obj, WEAR_BODY );
act_obj.c:1473: equip_char( ch, obj, WEAR_HEAD );
act_obj.c:1483: equip_char( ch, obj, WEAR_LEGS );
act_obj.c:1493: equip_char( ch, obj, WEAR_FEET );
act_obj.c:1503: equip_char( ch, obj, WEAR_HANDS );
act_obj.c:1513: equip_char( ch, obj, WEAR_ARMS );
act_obj.c:1523: equip_char( ch, obj, WEAR_ABOUT );
act_obj.c:1533: equip_char( ch, obj, WEAR_WAIST );
act_obj.c:1551: equip_char( ch, obj, WEAR_WRIST_L );
act_obj.c:1561: equip_char( ch, obj, WEAR_WRIST_R );
act_obj.c:1587: equip_char( ch, obj, WEAR_SHIELD );
act_obj.c:1616: equip_char( ch, obj, WEAR_WIELD );
act_obj.c:1650: equip_char( ch, obj, WEAR_HOLD );
act_obj.c:1660: equip_char(ch,obj,WEAR_FLOAT);
act_wiz.c:248: equip_char( ch, obj, WEAR_LIGHT );
act_wiz.c:256: equip_char( ch, obj, WEAR_BODY );
act_wiz.c:277: equip_char(ch,obj,WEAR_WIELD);
act_wiz.c:287: equip_char( ch, obj, WEAR_SHIELD );
db.c:1450: equip_char( mob, obj, pReset->arg3 );
handler.c:1488: unequip_char( ch, obj );
handler.c:1575:void equip_char( CHAR_DATA *ch, OBJ_DATA *obj, int iWear )
handler.c:1627:void unequip_char( CHAR_DATA *ch, OBJ_DATA *obj )
handler.c:1636: bug( "Unequip_char: already unequipped.", 0 );

Note the line I bolded is different from most of the rest. It's a function definition as opposed to a call of the function.

So in my case the function equip_char() starts at line 1575 in handler.c

If you have an editor like nano you can start it from the command shell passing the line number and file.
For example…

$ nano +1575 handler.c

I see…
/*
* Equip a char with an obj.
*/
void equip_char( CHAR_DATA *ch, OBJ_DATA *obj, int iWear )
{
AFFECT_DATA *paf;
int i;

if ( get_eq_char( ch, iWear ) != NULL )
{
bug( "Equip_char: already equipped (%d).", iWear );
return;
}

It looks like a character, probably in this case a mobile is being equipped twice to the same wear location.
It's a reset in one of the areas perhaps.

Resets in the area files look like these from midgaard.are.
M 0 3069 4 3138 4 * the cityguard
E 1 3365 -1 0 * a war banner
E 1 3364 -1 1 * a city guard signet ring
E 1 3350 -1 16 * a standard issue sword

One of the E resets is loading to the same wear location as a previous one. Not these above.. it's just an example.

Which area file and which mob is unknown, because the error message doesn't say.
A better error message would show the name and line of the area file, and the object and mobile vnums.
The only thing I see you have to go on is the wear location is number 3.
It appears this BUG/error isn't fatal. That is the object just isn't loaded to the mob and things continue.
09 Mar, 2009, boblinski wrote in the 11th comment:
Votes: 0
Okay, cool thanks for the explanation!
09 Mar, 2009, Tyche wrote in the 12th comment:
Votes: 0
Here's something a little more advanced.

$ egrep -n '^E +[0-9]+ +[0-9]+ +[-0-9]+ +3' *.are

That command will find all the equipment resets to wear location 3 in all your area files.

The search text, '^E +[0-9]+ +[0-9]+ +[-0-9]+ +3', is called a regular expression the pieces of which mean…

'^E' - line starts with E
' +' - one or more spaces
'[0-9]+' - one or more digits
'[-0-9]+' - one or more digits may be signed
'3' - the digit 3

Find me a line starting with E followed by one or more spaces followed by one or more digits followed by one or more spaces followed by one or more digits followed by one or more spaces followed by one or more digits which may be signed followed by one or more spaces followed by a 3.
12 Mar, 2009, elanthis wrote in the 13th comment:
Votes: 0
David Haley said:
Ah, I hadn't noticed that the idea was to get a more informative compiler/OS. In that case, indeed, the choice of OS and compiler is basically absolutely irrelevant.


Actually there has been a lot of work lately into more informative compiler error messages, which is one reason I'm looking forward to Clang (http://clang.llvm.org) hitting production quality level. Some GCC errors for example make almost no sense even to me (although I can look at the line of code it complains about and figure it out no problem), and often times compilers through away semantic information that the compiler itself doesn't need, leading to poor error messages. For example, they usually display errors involving code using a typedef that references the original type and not the typedef name, which can make the error far more obscure sounding. Macros also can cause a huge number of errors that make no sense when looking directly at the code. Clang retains more information about the actual source code in its AST and its semantic analyzer uses that information to produce far more user friendly error messages than GCC, Visual C++, or other common compilers ever have. It's especially useful for C++ (which Clang still has very incomplete support for), where error messages often spit out fully-expanded template parameters even though the source code only ever references simple-looking types like std::vector<int> or std::string.

http://clang.llvm.org/features.html#expr...

None of that is going to matter in the least if the OP is having problems with the uninformative error messages produced by the MUD itself, of course. :)
12 Mar, 2009, David Haley wrote in the 14th comment:
Votes: 0
One of the things I like about Sun's C++ compiler is that template parameters are given explicitly once in messages, and then referenced as Type0, Type1, etc. So instead of:

std::map<int, std::string>::pair<int, std::string>

you'd get something like:

std::map<int, std::string>::pair<Type0, Type1>

a trivial example, but it's awfully useful when your template parameters are complex types, or even more templates. (Think map of string to map of string to vector of string..)
13 Mar, 2009, Igabod wrote in the 15th comment:
Votes: 0
man I wish I knew about the -n option for grep, that would have made things a LOT easier on me. Thanks for the info Tyche.

Just as an aside for boblinsky, the -i option makes it so that your search is case insensitive. meaning you can type grep -i blahblah *.* and it'll return instances of blahblah BLAHblah and other variations on that within the code. Just using grep without the -i means you have to capitalize things correctly.
13 Mar, 2009, Noplex wrote in the 16th comment:
Votes: 0
David Haley said:
One of the things I like about Sun's C++ compiler is that template parameters are given explicitly once in messages, and then referenced as Type0, Type1, etc. So instead of:

std::map<int, std::string>::pair<int, std::string>

you'd get something like:

std::map<int, std::string>::pair<Type0, Type1>

a trivial example, but it's awfully useful when your template parameters are complex types, or even more templates. (Think map of string to map of string to vector of string..)

That's pretty nice, but couldn't you just use the standard contract of std::map and refer to std::map<int,std::string>::key_type and std::map<int,std::string>::data_type? If you're going to hide the types anyway why not use what the standard exposes? But I see where it may be useful just not in the example you provided.
13 Mar, 2009, elanthis wrote in the 17th comment:
Votes: 0
Noplex said:
That's pretty nice, but couldn't you just use the standard contract of std::map and refer to std::map<int,std::string>::key_type and std::map<int,std::string>::data_type? If you're going to hide the types anyway why not use what the standard exposes? But I see where it may be useful just not in the example you provided.


Because the compiler doesn't know about those. The types aren't built-in to the compiler, they're just part of a standard library. Should the compiler see the template types and then search all the typedefs inside the type to see if any match the template type arguments? It might even pick the wrong one in some cases, e.g., if you have a std::map<int, int>, it might either just use key_type for both ints, or the compiler would have to be even smarter and figure out which typedefs map to which template typenames. It would not be a bad thing to do at all: it's just really hard, and there's some corner cases that may not work correctly.

Usually the biggest offender with templates in C++ is the fact that most templates you use are already specialized (sometimes partially). Especially when C++0x is out and allows partial template typedefs. The issue is that developer often uses std::string::iterator and then the compiler starts spitting out errors referencing something like base_iterator<char, std::allocator<char>, std::basic_string<char, std::allocator<char> > >::iterator.

What Clang does (and what I guess maybe Sun's compiler might do?) is that it remembers that you defined the variable in question as a std::string (which is just a typedef) and uses that in the error messages, while most compilers throw away the typedef information during parsing of the AST and so are forced to show the fully expanded type in errors.

Clang does a lot more, too. It's error messages are usually just a lot clearer. Where GCC might say "invalid operand type" Clang might say "cannot use + operator on types (int, struct foo)" and then also shows the line of code with nifty highlighting:

int a = (5 * num) + data;
~~~~~~~~~ ^ ~~~~
13 Mar, 2009, David Haley wrote in the 18th comment:
Votes: 0
Also, I picked that example just because I couldn't think of another example of the types repeating off the top of my head. :redface:

And hey, this Clang compiler sounds utterly awesome…

elanthis said:
The issue is that developer often uses std::string::iterator and then the compiler starts spitting out errors referencing something like base_iterator<char, std::allocator<char>, std::basic_string<char, std::allocator<char> > >::iterator.

Meh, I've always hated that. :mad:

I find that with template-related compiler errors, it's usually easier to get the line number from the error output (if you can find it) and then eyeball it myself, stepping through instantiation in my head if necessary.
(Hey, that would be a cool tool: something that lets you interactively expand a template to see what happens…)
13 Mar, 2009, Noplex wrote in the 19th comment:
Votes: 0
Interesting. I'm going to have to take a look later. Anything that I should be worrying about (e.g. major differences between GCC4)?
0.0/19