[crossfire] scripts

[Mark Wedel]

Alex Schultz wrote:

> Such  running scripts from text in memory is very possible indeed :)
> In fact, we could (and should IMHO) go one step further: Run it from the
> bytecodes in memory. The python code already has faculties for caching
> the bytecode of python scripts in memory (caches up to 16 scripts as
> bytecode in memory) and this increases speed of running the same script
> over and over VERY dramatically (code for this derived from daimonin's
> changes in the python plugin before it moved to lua). So, why store text
> in memory as such to run, when one could store the bytecode which would
> be much much faster and use less memory :)

  Right - I was thinking that it may be possible to store some machine format.

  As someone said, the one disadvantage of these collected scripts is that you 
can't change them on the fly.

  However, I'd consider that a pretty minor issue - if you're developing a 
script, you could certainly store it is a plain file so you can run it over and 
over again until it works, and then move it to the arch where it gets collected.

  As far as the idea of collect copying the scripts over to the maps script 
idea, I think this is a bad idea for many reasons:

- In a sense, it pollutes the maps directory as far as SVN goes - you now have a 
bunch of files under maps which are not part of SVN.  As things go right now, 
you can use a svn checkout for your maps area, and it will remain pure.

- The abilities/ownership of the collect process gets many.  It probably isn't 
that uncommon that one uid is used to build the source and run collect, and 
another is actually used for the make install.  In this model, the collection 
process would be unable to copy the scripts directly over into the maps area - 
instead, it would have to copy them to a temporary area, (lib/scripts/...), and 
then the install copies those over.

  But if we're going to do that, it probably makes sense to just copy those over 
into some non map area of the install directory (share/scripts/...) or something

- This may make packaging (rpms) more of a problem - this is especially true if 
a map script becomes an arch script or vice versa - now you have conflicting 
files in the RPMs.  If they are in completely separate directories, no issue.

  As far as pathnames, to me, the simplest thing is to have a basic pathname and 
there just be a search order - server looks first in maps/scripts/..., then in 
share/scripts/..., etc.  That should be very easy to do - the only issue is if 
there are two scripts of the same name.

> 
> Alex Schultz
> 
> _______________________________________________
> crossfire mailing list
> crossfire at metalforge.org
> http://mailman.metalforge.org/mailman/listinfo/crossfire