Lily development is split between people who work on the server-side, and people who work on various clients for connecting to lily.
To be a server developer, you generally work on the lambdaMOO code (ie, verbs and properties) which implements the 'lilyCore'. Occasionally there is some work on the moo program itself (which is written in C), but that is pretty rare. Changes in lambdaMOO code can be installed on-the-fly (assuming you are careful), while changes to the moo program require shutting down the server and restarting it.
-- GaranceDrosehn - 19 Dec 2003
As a note about being careful... For example, when trying something at RPI one day, I did this or something very much like it...
foreach d in ($discs)
count = 0;
if (d.private = 0)
count = count + 1;
endif
endfor
A very common programming error, but running this snippet of code on a live core has nigh-disastrous effects. =-)
This is one of the reasons I am a big proponent of "dev work on your own core", "test on the backup of a live server", and treat the live server as production.
That said, no one else that puts live code on RPI seems to do as much damage as me. =-)
--
CoKe - 24 Dec 2003
We should probably add another section on good programming practices, but I definitely agree that it is important to test changes on some other server-image first, before installing on the live RPI server. While I have had good luck with my changes, it's because I have the luxury of full access to the production core, which makes it easy to build a good testing strategy.
I copy a checkpoint of the RPI production core to a test copy, start that up, and (usually) purge all the /review buffers (mainly to make it smaller). I checkpoint that test database, and use my splitcore.rb script to break out all the verbs and their properties into separate files. I then make my changes to various verbs and properties, keeping a list of what I'm changing, and in what order I have to change them to be safe. Once I've tested everything, I go back and replace the test-core with a clean copy of the production core, and copy-and-paste the commands that I expect will install the changes. I test again. If that worked, then I can copy-and-paste the same set of commands to the production core. This strategy won't catch all the mistakes I might make, but it eliminates a large number of them, particularly the most disastrous ones like a simple typo in a critical verb.
Another reason I do things this way is to try and figure out how LilyInCvs would have to work to be reliable. That is a very challenging goal, at least to be able to do it as live updates!
-- GaranceDrosehn - 24 Dec 2003
to top