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.
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.
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.
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.
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");
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.
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 :)
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.