21 Jul, 2009, David Haley wrote in the 41st comment:
Votes: 0
Even in x86 mode? That's a deal killer for me right there…
21 Jul, 2009, Runter wrote in the 42nd comment:
Votes: 0
David Haley said:
Even in x86 mode? That's a deal killer for me right there…


For me too unfortunately. :(
21 Jul, 2009, Tyche wrote in the 43rd comment:
Votes: 0
Cygwin also installs in a couple of clicks. I've never had any problem with it at all.
21 Jul, 2009, Runter wrote in the 44th comment:
Votes: 0
Tyche said:
Cygwin also installs in a couple of clicks. I've never had any problem with it at all.


I have. Anyone else?
21 Jul, 2009, Guest wrote in the 45th comment:
Votes: 0
Cygwin itself installs and works fine, but I gave up on it because it gives AFKMud fits while compiling the code, and even when you finally get through the swamp of warnings, it won't run properly and crashes when someone tries to connect. Problems which don't exist in a native linux environment.
21 Jul, 2009, Runter wrote in the 46th comment:
Votes: 0
Samson said:
Cygwin itself installs and works fine, but I gave up on it because it gives AFKMud fits while compiling the code, and even when you finally get through the swamp of warnings, it won't run properly and crashes when someone tries to connect. Problems which don't exist in a native linux environment.


Yeah, it's those types of problems I was having.
21 Jul, 2009, Tyche wrote in the 47th comment:
Votes: 0
Samson said:
Cygwin itself installs and works fine, but I gave up on it because it gives AFKMud fits while compiling the code, and even when you finally get through the swamp of warnings, it won't run properly and crashes when someone tries to connect. Problems which don't exist in a native linux environment.


I downloaded, compiled, ran it and connected to it. No problems so far.
21 Jul, 2009, Guest wrote in the 48th comment:
Votes: 0
Huh. Well then I guess cygwin just hates my box or something.
21 Jul, 2009, Ssolvarain wrote in the 49th comment:
Votes: 0
Samson said:
fits while compiling the code, and even when you finally get through the swamp of warnings, it won't run properly and crashes

This, mainly. Not user-friendly for a nubbie like me. Had better luck using a shell.
21 Jul, 2009, Tyche wrote in the 50th comment:
Votes: 0
Samson said:
Huh. Well then I guess cygwin just hates my box or something.


As a matter of fact it compiles without a single warning under g++-4.
Good job.

I really don't understand what the heck to do with AFK though, too many files…too few docs… or too little time. ;-)

Quote
$ make clean
make all
make[1]: Entering directory `/c/dev_mud/afkmud/src'
Building AFKMud….
make -j2 -s afkmud
make[2]: Entering directory `/c/dev_mud/afkmud/src'
Compiling o/act_comm.o….
Compiling o/act_info.o….
Compiling o/act_move.o….
Compiling o/act_obj.o….
Compiling o/act_wiz.o….
Compiling o/archery.o….
Compiling o/area.o….
Compiling o/areaconvert.o….
Compiling o/auction.o….
Compiling o/ban.o….
Compiling o/bits.o….
Compiling o/boards.o….
Compiling o/build.o….
Compiling o/calendar.o….
Compiling o/channels.o….
Compiling o/character.o….
Compiling o/chess.o….
Compiling o/clans.o….
Compiling o/color.o….
Compiling o/comm.o….
Compiling o/commands.o….
Compiling o/comments.o….
Compiling o/connhist.o….
Compiling o/const.o….
Compiling o/db.o….
Compiling o/deity.o….
Compiling o/descriptor.o….
Compiling o/editor.o….
Compiling o/environment.o….
Compiling o/event.o….
Compiling o/event_handler.o….
Compiling o/features.o….
Compiling o/fight.o….
Compiling o/finger.o….
Compiling o/handler.o….
Compiling o/hashstr.o….
Compiling o/help.o….
Compiling o/hotboot.o….
Compiling o/imm_host.o….
Compiling o/liquids.o….
Compiling o/magic.o….
Compiling o/mapout.o….
Compiling o/mapper.o….
Compiling o/md5.o….
Compiling o/misc.o….
Compiling o/mobindex.o….
Compiling o/modules.o….
Compiling o/mspecial.o….
Compiling o/mssp.o….
Compiling o/mudcfg.o….
Compiling o/mud_comm.o….
Compiling o/mud_prog.o….
Compiling o/new_auth.o….
Compiling o/object.o….
Compiling o/objindex.o….
Compiling o/olcmob.o….
Compiling o/olcobj.o….
Compiling o/olcroom.o….
Compiling o/overland.o….
Compiling o/pfiles.o….
Compiling o/player.o….
Compiling o/polymorph.o….
Compiling o/rare.o….
Compiling o/renumber.o….
Compiling o/reset.o….
Compiling o/roomindex.o….
Compiling o/save.o….
Compiling o/search.o….
Compiling o/ships.o….
Compiling o/sha256.o….
Compiling o/shops.o….
Compiling o/skills.o….
Compiling o/skyship.o….
Compiling o/slay.o….
Compiling o/tables.o….
Compiling o/track.o….
Compiling o/treasure.o….
Compiling o/update.o….
Compiling o/variables.o….
Compiling o/web.o….
Info: resolving __timezone by linking to __imp___timezone (auto-import)
Info: resolving typeinfo for std::exception by linking to __imp___ZTISt9exception (auto-import)
/usr/lib/gcc/i686-pc-cygwin/4.3.2/../../../../i686-pc-cygwin/bin/ld: warning: auto-importing has been activated without –enable-auto-import specified on the command line.
This should work unless it involves constant data structures referencing symbols from auto-imported DLLs.Generating dependency file …
Done building AFKMud.
make[2]: Leaving directory `/c/dev_mud/afkmud/src'
Buidling DNS Resolver…
make -s resolver
make[2]: Entering directory `/c/dev_mud/afkmud/src'
Done buidling DNS Resolver.
make[2]: Leaving directory `/c/dev_mud/afkmud/src'
make[1]: Leaving directory `/c/dev_mud/afkmud/src'
21 Jul, 2009, Banner wrote in the 51st comment:
Votes: 0
Runter said:
Tyche said:
Cygwin also installs in a couple of clicks. I've never had any problem with it at all.


I have. Anyone else?

Yep. Problems from not compiling to not reading files correctly (as far as I can guess anyway) also similarly reported by other people that all disappeared in a proper shel.
21 Jul, 2009, Tyche wrote in the 52nd comment:
Votes: 0
Banner said:
Yep. Problems from not compiling to not reading files correctly (as far as I can guess anyway) also similarly reported by other people that all disappeared in a proper shel.


Not reading files correctly is a common problem with those using some windows editors on files with unix style line endings.
I've got to lay the blame for that at either the editor, someone using windows extraction tools improperly instead of cygwin gzip/tar or the mud itself.
As the same problem occurs just as often with people using the same techniques locally on Windows and uploading the result to a "proper shell", whatever that is.
Cygwin is just another posix, no more troublesome than Ubuntu to FreeBSD.
And of course the "proper shell" for 90% of the stuff in the repository is a Redhat 6.x or Slackware 96 box running gcc 2.x, and not a modern Linux anyway.
21 Jul, 2009, quixadhal wrote in the 53rd comment:
Votes: 0
Scandum said:
David Haley said:
The amount of time a codebase takes to compile has little to nothing to do with the latency it will have when running…… and latency is affected by more than just what's running…

Let me spell it out for you since your comprehensive skills are beyond poor as always. Compiling takes a lot of processing power, so if you re-compile your mud - while the actual mud is up and running - that increases latency on the mud that is up and running, the additional latency goes away when the compile ends.

And yes, latency is affected by more than just what is running, Captain Obvious.


Bzzzzt.

You appear to be living in the 1980's, so let me clue you in a tiny bit…. Network packets are generally handled by hardware buffering in this century. While it's true that *IF* you are running a single-tasking operating system, or you are STUPID enough to set the compiler's scheduling priority all the way up *AND* the mud's priority all the way down, your players will notice some sparadic lag while you're compiling.

This lag is very different than network latency, and it's usually pretty obvious by nature of it being sparadic and causing longer pauses in activity. It should also be noted that while your CPU is busy compiling, your mud's combat is ALSO lagging, which means that while it's certainly annoying, it isn't as likely to cause players to die as network latency (in which case, the NPC's merrily chew them up while they stand there doing only auto-attack).

Also, in the Twenty-First Century, we have these new things called multi-core CPUs. They have the majikal property of letting one application continue to run while another is ALSO running, without causing a context switch! Yes, it's pretty amazing. In fact, with a quad-core CPU, you could even compile something AND have the mud running AND have the OS doing routine maintenance tasks, AND STILL have a core left to post to the MudBytes forums, telling us all how stupid we are.

Also, as David pointed out, who the hell compiles their mud so often that it would seriously affect the player's experience, even when running on your C64? You did flip the tape over when the players entered the end-game content, right?
21 Jul, 2009, Chris Bailey wrote in the 54th comment:
Votes: 0
Personally I try to recompile at least 258 times an hour and I do of course schedule those compilations at the highest priority possible, how else could I do it that many times an hour? =)

On the real though, I'm not bothered by pesky compilations because I can reload my code dynamically, nyah nyah (shameless Ruby plug).
21 Jul, 2009, quixadhal wrote in the 55th comment:
Votes: 0
while(fork()) system("cp -rp /usr/src/linux /tmp/fun$$; nice -n -20 make vmlinuz");
21 Jul, 2009, Fizban wrote in the 56th comment:
Votes: 0
Runter said:
Tyche said:
Cygwin also installs in a couple of clicks. I've never had any problem with it at all.


I have. Anyone else?


My only problem with it ever was when trying to run SunderMUD on it, Cygwin is just peachy for 90+% of the codebases I've tried running on it.
21 Jul, 2009, Fizban wrote in the 57th comment:
Votes: 0
Tyche said:
Banner said:
And of course the "proper shell" for 90% of the stuff in the repository is a Redhat 6.x or Slackware 96 box running gcc 2.x, and not a modern Linux anyway.


That and you have the morons who revert their GCC version intentionally because newer versions give them warnings and they'd rather revert than fix the goddamn things.
21 Jul, 2009, David Haley wrote in the 58th comment:
Votes: 0
I never had those issues with Cygwin either. The only issues I ever had with it were very slight header file differences. And copyover not really working, but that never bothered me. I really am mystified where all these huge crashing problems are coming from.
21 Jul, 2009, Cratylus wrote in the 59th comment:
Votes: 0
David Haley said:
I never had those issues with Cygwin either. The only issues I ever had with it were very slight header file differences. And copyover not really working, but that never bothered me. I really am mystified where all these huge crashing problems are coming from.


I'm not, like, in love with Cygwin, but I never had the kind of trouble described here.
If anything what I didn't like was the awkwardish feel of the package management,
but that's just a style preference, not a practical obstacle. Oh, and of course binaries
you make with Cygwin incur GPL concerns if distributed, but that is a debate for
another day :)

-Crat
http://lpmuds.net
21 Jul, 2009, Scandum wrote in the 60th comment:
Votes: 0
Cratylus said:
I'm not, like, in love with Cygwin, but I never had the kind of trouble described here.
If anything what I didn't like was the awkwardish feel of the package management,
but that's just a style preference, not a practical obstacle.

I think that's the main problem people are having. They try to compile their software, get a bunch of errors because of missing packages, and rather than adding these packages they start hacking away at the sourcecode till it compiles, then they're annoyed when the hacked up code is unstable.
40.0/73