[DGD] Hope someone can help

[mtaylor]

Thank you Zell :) 

I think I managed to grasp most of what you are saying. It was really
helpful to have someone just run through things with me. Like I said I'm not
a born coder ;) 

Anyway I wonder if I can be cheeky enough to take advantage of your
knowledge a little more. I wasn't sure about a couple of things...

I wrote:
>> Same sort of thing with r-limits ... Don't know what they are and how to use
>> them and couldn¹t find anything simple enough for my mind ;)

You replied:
> They're used when you want to be able to trust some code less than
> other code. The most hard-core layers of your library will probably
> run without using rlimits, which means they never run out of ticks
> or stack. This means that a badly written loop can permently freeze
> your process, and a bad recursion can crash it.
> 
> If you want to be able to relax a bit when you write less hardcore
> systems, like pretty much all your actual game code, you make sure
> all such code executes with reduced tick/stack quota.
> 
> If you have an LPMud style setup where you invent people to come
> and code on your Mud, you -definitely- want to make sure they do
> not accidentally (or maliciously) crash your game with their code.
> 
> To make sure all mudlib code runs with reduced tick/stack quotas,
> you have to implement callout gateways in an auto object, as well
> as take full control over user objects created by incoming telnet
> connections etc etc. This is one of the services that the kernel
> library supplies, and which you will spend an inordinate amount of
> time trying to reimplement. :-)
> 
> To be honest, since you have full control of all the code, you can
> probably just stick a bunch of rlimits in the right places and do
> something about callouts.

The thing is ... I don't know what ticks and stacks are. I know that
probably makes me seem like a four year old running for president ;)
We are not going to run the standard code/builders thing. We want to have a
test mud where we can fully test new code as it comes along. Code will be
submitted by other coders and not written from within the mud.

To be honest with you ... I didn't understand any of the bit about Callout
Gateways and the like ... Sorry Par :(

I also wondered what you mean by putting a bunch of r-limits in the 'right
places' ... Um ... Where would the right places be? Any advice on where to
put r-limits. And how do I do that?
Also what is it I need to do about call-outs? Is it preventing call-out's
being made when their aren't enough stack/tick thingies which I suppose
would be bad for the mud running?

Last question on that ... Does it matter if we didn't include r-limits any
where? Is it something that will prevent our mud from working?


>> We're also wondering how to 'save' our mud so that if a crash occurs we
>> don't lose too much time. Any help on that?
> 
> That's persistence. Call dump_state() regularly.

Okay cool! Got that :) *feels proud*
 
>> In fact if someone were to take a look at our code, maybe they could advise
>> us on improvements or whether it just won't work.
> 
> I suggest the only way you can make a large persistent fantasy
> Mud is to hook up with a developer who is willing to really dig
> into these complex issues -- especially if you're not doing it
> with the kernel library.
> 
> Zell

That sounds ominous :( Do you really think that we can't / shouldn't go
further without another developer helping out with these things. Our code
and ideas are great ... Haven't seen lots of them in any other muds about.
I've introduced ideas from the rl rpg system me and friends have developed
over 6 - 7 years. And I'm proud at least that we have got this far ;)


I'm not doing to badly for an Ecologist who just does this for fun ;)



Once again Par thank you so much for taking the time to reply. Really
appreciated :)


Matt






_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd