From: amylaar@opal.cs.tu-berlin.de (J"orn Rennecke)
Subject: Re: Darker Realms - The Mudlib
Organization: Techn. University of Berlin, Germany
Date: Sun, 16 Aug 1992 16:47:31 GMT

jacob@fy.chalmers.se (Jacob Hallen) writes:

>In article <1992Aug13.023104.24530@cs.tu-berlin.de> amylaar@opal.cs.tu-berlin.de (J"orn Rennecke) writes:
>>The game should only reboot when the driver is changed. And then, you can't
>>use old binaries anyway...
>
>Machine crashes, service, level 1 backups, extensive mods in the

Machine crashes, service, level 1 backups: that's a reason, but do you have
this often?

>mudlib, unwanted creations by wizards, lack of memory, memory

Lack of memory: test the following:
a) you have a memory leak in the driver
b) your machine could need some cheap simms
c) you should thing about exploiting the clean_up feature more

Extenive madlib changes can be done on-the-fly. But testing them first on a
testmud might be a good idea.

>fragmentation, machine owner wants to run his daily FEM job, mud is

Memory fragmentation: that's no problem, smalloc.c can handle this nicely.
Only thing you have to do is to use an appropriate FIT_STYLE.

>closed during office hours. Just to mention a few reasons for
>rebooting.
>
>>If it weren't for this flashy hard disk light, ' wouldn't even notice this
>>'compilation horizon' on my home machine. Compilation of the rooms and screen
>>ouput have about the same speed.
>
>Perhaps you should take all parameters into account. The relation
>between disk speed and CPU speed would for instance affect your
>mileage. 
>
>>Hmm, the algorithm is often indicated by the function/variable names
>
>This is not true of the parts of your code that I have examined closely. 
>...

Hmm, how do you call heapsort :-)

>Programming is just as much about producing readable code as it is
>about producing efficient programs to run. Maybe even more about
>making readable code, since we have compilers that take care of quite
>a bit of the efficiency problem. Maybe you have heard about the
>software crisis, this is really what the crisis is all about.

The software crisis were not that much a problem if computers could take more
care of themselves. Lpmuds tend to have less computing power, but more
interdisciplinary work and enthusiasm than common AI projects.

>>If i had a simplistic style to express algorithms in code, it wouldn't be
>>as fast as it is when it is written with the entire gamedriver in mind.
>
>I beg to differ. I have seen an enormous amount of student code, and
>invariably the shortest and clearest is also the fastest.

I know there is a way to obfuscate simple things & make them slower. Student
code often deals with less complex problems. But hve you seen something of the
compelexity of a stable gamedriver that's written in a clear & eficient style?
If so, let's share :-)

>gamedriver. However, code that is hard to read will not bring us
>closer to that goal, and as the gamedriver evolves in the future it
>will take us even further from the goal.

Some ways how lvalues crash the game are not easy to understand, because the
triggering LPC code isn't either... and you can't understand the assignment
order and special precautions unless you understood the lvalue problem in all
its fascets.

	amylaar