> > Perl is a nice, stable language. Even the versions for windows
> >rarely tend to fail. All the same, it's a full featured language, and it
> >doesn't have things like the ability to restrict memory usage, detect
> >infinite loops, or deny a user the ability to read/write arbitrary files
> >owned by the mud process owner.
>
> 1) Run in separate process; use rlimit.
> 2) In a separate process, it's killable if it stops responding. (Could use
> rlimit CPU usage but it's going to be CPU-bound usually anyway so it'd
> end up dying prematurely.)
> 3) $cpt = new Safe; $cpt->deny(qw(sysopen open))
>
> > Aside from that, writing languages is fun. Weren't you the one
> >who got the lexxer out just a while ago?
>
> That's a trivial language. I meant writing something on the scale of C or
> Perl because once a language is started everyone's going to want their own
> pet operators and functions thrown in until it grows just as big. Then you
> have to document it all and keep interfaces relatively stable.
Actually, most languages don't end up being that difficult to
write a parser-interpreter for. The hard part is optimization. Now, we
don't need something that's as flexible as perl, and frankly, the syntax
for C is relatively small and straightforward.
Unfortunately, we'd just need a large subset of commands.
>
> > Also, the mechanism for insuring that we don't have name-space
> >conflicts while at the same time allowing for persistent memory objects,
> >all in embedded code is difficult.
> > I'm sure you wouldn't want a seperate persistent process for each
> >unique script..
>
> 'use Safe' stuffs all variables into a separate namespace too. Have a
> separate namespace for each player and the system itself.
I reread the info for this, it does indeed have seperate
namespaces, so long as you keep track of the individual 'safe' objects you
instantiate. There are still many, many problems with this; you'd still
have/want to fork the processes off since there's no way to insure that
any given process wouldn't take an undue amount of time. That is, the
only type of time sharing perl is capable of is via process control
(alarm/suspending/etc - and some of these are not reentrant. I see
difficulties in restoring state and the location of the execution pointer.
(Perl still doesn't ~really~ work with threads incredibly well,
but it can be used in most cases anyway, except for on windows systems.)
For example, you wouldn't want a fight procedure waiting on an
introduction procedure that spits out some fact every 5 seconds for 60
seconds.
Of course, this becomes even more complex on systems like windows
which barely support the idea of (non-proprietary) signal handling.
I still think the flexibility of perl will make it far too
difficult to account for even a reasonable number of the points of
failure. Upping the complexity of the system by using thread/process
controls which are OS-dependant or using additional external
programs/shells like rlimit makes it even worse.
I am curious though, what you have envisioned... before I get too
dragged down in the details, what do you envision a perl script actually
looking like/doing? I tend to avoid embedding other languages in my code,
and when I do, they usually don't have to end up passing more than
individual pieces of information back and forth...
Would there be a general set of structures generated and passed
into the perl function to descibe the players, rooms, mobs, objs and their
important relationships, or would this be accessable directly from the
embedded perl via some... uh.. magic?
Also, a sidenote; using the perl that comes with cygwin for
windows ends up being (depending on what you're doing) around 8-80x slower
than a compiled from source version on a linux machine. Use activestate
if you have to use windows. It's still slower than the linux, but there's
not such a wide descrepancy when you perform network operations.
PjD
--
+---------------------------------------------------------------+
| FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
| Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
| Newbie List: http://groups.yahoo.com/group/circle-newbies/ |
+---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 06/25/03 PDT