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@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire