05 Mar, 2013, Odoth wrote in the 1st comment:
Votes: 0
I have been mud coding on and off for a few years. One thing that I have always wondered about is what tools others use for mud development…mostly because I'm curious what kind of stuff I might be missing out on. :lol:

I code for a Rom based mud so everything's in C. I use vim with ctags most of the time but use notepad++ with FTP plugin occasionally as well. GDB for debug when necessary. Our team also began using a bug tracker (MantisBT) which seems pretty convenient as well.

What tools do you use that make your life a lot easier? Any suggestions for us poor fools stuck writing in C? :biggrin:
06 Mar, 2013, Lyanic wrote in the 2nd comment:
Votes: 0
git, Trac, Valgrind, gprof, ant, deheader, WinSCP

There'd be a lot more if I weren't limiting this to the C language and stuff external to the binary.
06 Mar, 2013, Tyche wrote in the 3rd comment:
Votes: 0
I often use a number of C libraries, like:
zlib, pcre, tokyo_cabinet, gc, sqlite3, decnumber.
06 Mar, 2013, Rarva.Riendf wrote in the 4th comment:
Votes: 0
I use Eclispe as an editor, and Clang (thx to Vigud) in addition to GCC for more errors catching. (and Valgrind and Gprof as well)
06 Mar, 2013, quixadhal wrote in the 5th comment:
Votes: 0
vim for code and data, graph paper for design.
06 Mar, 2013, Davenge wrote in the 6th comment:
Votes: 0
I personally keep things pretty simple, nano git and gdb for debugging. Haven't found any concrete way to get ctags on Nano and I so love those keybindings that I don't feel like upgrading to vim or emacs. Something more mainstream with Ctags. I'm just a KISS kind of guy, which can really be a curse sometimes…
06 Mar, 2013, Kline wrote in the 7th comment:
Votes: 0
Nano, valgrind, git, GDB, cppcheck, ccache … List goes on. Lately I've been forcing myself to learn Netbeans more. It's the only IDE I've found with reliable remote-GDB support and built-in SSH, SFTP, network shares, etc…Very flexible. I'm growing fond of all the features an actual IDE can provide me over nano :)
07 Mar, 2013, salindor wrote in the 8th comment:
Votes: 0
I upgraded my mud to work on windows so I could develop in visual studio 2010.

I used to use notepad and vim and college… I can't go back (ok ok I can go back, but I don't wanna). Being able to hover over any variable and see its contents… I mean you just can't beat that.

Salindor
07 Mar, 2013, Odoth wrote in the 9th comment:
Votes: 0
Tyche said:
I often use a number of C libraries, like:
zlib, pcre, tokyo_cabinet, gc, sqlite3, decnumber.


I assume you mean you use these for mud development? May I ask what sorts of things you use pcre for?
07 Mar, 2013, Lyanic wrote in the 10th comment:
Votes: 0
Kline said:
Nano, valgrind, git, GDB, cppcheck, ccache …

How did I never know about cppcheck before? It's nifty. I ran it on my code and it found a couple minor issues. It's not a huge gain, but it was so easy to use and only took 5 minutes or so. Thanks for the recommendation.
07 Mar, 2013, Rarva.Riendf wrote in the 11th comment:
Votes: 0
Lyanic said:
Kline said:
Nano, valgrind, git, GDB, cppcheck, ccache …

How did I never know about cppcheck before? It's nifty. I ran it on my code and it found a couple minor issues. It's not a huge gain, but it was so easy to use and only took 5 minutes or so. Thanks for the recommendation.


Does it report more/different warning than clang –analyze on your code?

ps: ran it on mine, seems like you cannot rely only or one or the other sigh, new warnings to look into…
07 Mar, 2013, Vigud wrote in the 12th comment:
Votes: 0
Yeah, I recently learned about cppcheck and it's good. I knew about clang-analyzer before, and another thing on the horizon is clang -fsanitize: http://clang.llvm.org/docs/UsersManual.h...
07 Mar, 2013, Tyche wrote in the 13th comment:
Votes: 0
Odoth said:
I assume you mean you use these for mud development? May I ask what sorts of things you use pcre for?

Regular expression libraries are very useful. I use pcre to mark up text in descriptions, match objects and
verbs in the environment, search for objects in the mud, and simple things like line conversions.
21 Mar, 2013, Nathan wrote in the 14th comment:
Votes: 0
Eclipse is great, I use it for Java of course. Being able to do some kinds of code refactoring more or less automatically is very handy. It's especially true for renaming stuff, moving files around, changing method signatures, and more on the fly. I've been using git for some code ever since I put my code on github (duh, right?). If I used the built in debugger I'd be better off, but I tend to just use a function wrapped around System.out.println for debug. Notepad++ is awesome, but I really like code completion which it doesn't have :( and that's not including the all-important ability to just click to execute the program/code.
21 Mar, 2013, Rarva.Riendf wrote in the 15th comment:
Votes: 0
Nathan said:
Eclipse is great, I use it for Java of course

Heh I use it for C as well, even if not the best tool for it at least I dont have to learn another one.
In java, you would be better off using the debugger, hell you can modify code AND values on the fly even go back at the beginning of the function and test the modification without ever relaunching! Use it, and never look back.
28 Mar, 2013, Rarva.Riendf wrote in the 16th comment:
Votes: 0
Oh since I have just seen it, new version of GCC is out with a new compil option

http://gcc.gnu.org/gcc-4.8/changes.html

AddressSanitizer , a fast memory error detector, has been added and can be enabled via -fsanitize=address. Memory access instructions will be instrumented to detect heap-, stack-, and global-buffer overflow as well as use-after-free bugs. To get nicer stacktraces, use -fno-omit-frame-pointer. The AddressSanitizer is available on IA-32/x86-64/x32/PowerPC/PowerPC64 GNU/Linux and on x86-64 Darwin.
28 Mar, 2013, Kline wrote in the 17th comment:
Votes: 0
Rarva.Riendf said:
Oh since I have just seen it, new version of GCC is out with a new compil option

http://gcc.gnu.org/gcc-4.8/changes.html

AddressSanitizer , a fast memory error detector, has been added and can be enabled via -fsanitize=address. Memory access instructions will be instrumented to detect heap-, stack-, and global-buffer overflow as well as use-after-free bugs. To get nicer stacktraces, use -fno-omit-frame-pointer. The AddressSanitizer is available on IA-32/x86-64/x32/PowerPC/PowerPC64 GNU/Linux and on x86-64 Darwin.


Thanks; guess I'll get to try it without having to build it myself in about two years when Debian catches up.
28 Mar, 2013, Nathan wrote in the 18th comment:
Votes: 0
Kline said:
Rarva.Riendf said:
Oh since I have just seen it, new version of GCC is out with a new compil option

http://gcc.gnu.org/gcc-4.8/changes.html

AddressSanitizer , a fast memory error detector, has been added and can be enabled via -fsanitize=address. Memory access instructions will be instrumented to detect heap-, stack-, and global-buffer overflow as well as use-after-free bugs. To get nicer stacktraces, use -fno-omit-frame-pointer. The AddressSanitizer is available on IA-32/x86-64/x32/PowerPC/PowerPC64 GNU/Linux and on x86-64 Darwin.


Thanks; guess I'll get to try it without having to build it myself in about two years when Debian catches up.


Do you have an especial problem with compiling it yourself? Is gcc difficult to build yourself or something?
28 Mar, 2013, Idealiad wrote in the 19th comment:
Votes: 0
Sometimes building it yourself brings in dependencies you don't want on your system? Just guessing.
28 Mar, 2013, quixadhal wrote in the 20th comment:
Votes: 0
As someone who's done this in the early 1990's, before Linux… compiling a compiler is a 3 step process.

First, you download the new compiler source and compile it with your existing compiler (full debug, no optimizations).
Then you set that compiler aside and unpack a fresh copy. You set your environmental variables/path/etc so it uses your newly compiled compiler and compile it again (full debug, no optimizations).
THEN you do the same thing again, using copy #2 to compile copy #3. If those two copies are identical (diff –binary), you have a working compiler that you can safely install in your system.

Optinally, you can then use that third copy to recompile it with optimizations,if you trust such things. :)

The reason for this… you need to verify that it can compile itself properly, and you can't do that with the native compiler because it WILL produce different code.

Sound like a pain in the arse? Welcome to normal sysadmin activity before things got so warm and cushy. ;)
0.0/29