This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Schaefer Frank R wrote: > > Hello. > > I'm actually doing some work to get a scripting language to run for > FreeCiv, a GNU Clone of the strategy game civilisation. People like Guile > too much, so it's perhaps the best choice. My problem with guile: Is the scripting language intended to design new games with, or to construct new AIs, or what? > 1) How can I access the symbol table ? My idea was to provide the user > with a list of actual cities, military units or isles for example. I > think it would be the best if I write them directly into the symbol table. > Parsing strings to get them in there might be \_much_/ too slow. You can define variables from the C level. However, I do not reccomend this approach. Instead, I would reccomend defining procedures that return a list of cities, look up a city by name, etc. > I'm _not_ the guile freak, so please forgive me two stupid questions: > 2) Can I make data structures read only, so that changes can only be > made from the C-world ? > You can create your own C-implemented first-class types, called `smobs'. If you provide only read operations for them, > 3) Is there a way to prevent people from peeking and poking arround with > guile to brake into a network for ex. ? I mean can I restrict the > instruction set / the functions that guile provides ? It should not > be possible for example that hackers can use a FreeCiv connection > to get the '/etc/password' file or sniffle the tcp-network or fork > billions of mini-processes that wipe out all other processes. You mean you want people to be able to upload untrusted Guile code into the server? That's probably not a good idea just yet. However, with some of the upcoming module system changes planned, it should not be hard to create a "safe" module that provides no dangerous operations, in which uploaded code should be run. I would consider instead the approach of running the script code on the client, if that works for your purposes. - Maciej