On 2/20/06, Martin Voelkle <[EMAIL PROTECTED]> wrote: > > I know this has been discussed before, again and again, but I think > > its about time we start taking it serioussly: I would like to begin > > work on embedding a scripting language in the 1.1 branch. So, lets > > stop the theorieticall stuff, most scripting languages, such as > > python, are going to be more portable than c++, and are very unlikely > > to cause determinism issues. And, if the language in question does > > cause a determinism issue, i can pick it up and change it early. > > > > I suggest we start looking at this from a dependancy standpoint. I > > would like to see python in the system, because of Boost.Python, it > > would be very easy to embedd, and the power, ease of use and > > portability of python makes it an ideal candidate. On the downside, > > python is a very large dependancy. > > > > There are certainly other languages, however. Lua is much more > > compact, but I'm much less familiar with lua. Its interface isn't bad, > > and things such as lua++ and luapp will make it easy to embedd, not as > > easy as python. > > > > I've heard you ask about the language Squirrel. I've looked into it, > > and it seems like a very nice, compact language, quite elegant by my > > standards, especially for a C-derived syntax. Then there is scheme. > > Scheme is very compact, like lua, infact its possible to import the > > entire language into our project as a single file, although we would > > be unlikely to do so. The language does have a lisp syntax, making it > > somewhat different than what we are used to. > > > > What should we pick? Don't think of it as a determistic or statespace > > problem, all the languages i've looked into can provide us with the > > assurrances we need. Think of it as a dependancy and usability review. > > We should decide now, and I can begin work soon. > > I'd be very interested if you could provide references that confirm > that these runtimes do povide us with the assurances we need. > If you embed an existing runtime, you must also be careful about > security: we don't want maps to access files or open sockets by > themselves. The security thing is an issue in many embedded languages. You can generally solve it by providing a "limited enviroment", which means no importing io modules. or such things. > > I think you are overlooking the problem. Retrofitting checkpointing > and determinism in an existing runtime is irrealistic for the python > runtime. Checkpointing in python is certainly do-able, infact i've done it before, very easily. A full vm dump is do-able within python itself, and of coarse also from pythons interface, just by looking into the "global dict", you can find everything you need to do a full vm marshal (marshaling) or serial (serialization). I have the python cookbook, and they demonstrate it fully.
As for determinism, python is *more* deterministic than C++, having no such thing as "undefined behaviour" or "implementation defined", and doesn't cause problems like C/C++ does. > > Talking about languages, I think python is a bit unintuitive for map > designers without a programming background. If you want a widely-used > and simple language, ruby fits better IMHO. JavaScript could also be > nice. I think python is very intuitive. Its also got a very easy-to-learn syntax, just look at Scons for example, who also use python, and successfully teach people with no experience in python how to create scripts, and the advantage of being a full language shows when people get more experienced. And, last note, python is used more widely than ruby. > > NCT: on thread per unit will probably never be possible for performance > reasons. > > Martin > > > _______________________________________________ > glob2-devel mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/glob2-devel > _______________________________________________ glob2-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/glob2-devel
