> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
> Of Kevin Lawton
> Sent: Wednesday, August 02, 2000 9:43 AM
> To: [EMAIL PROTECTED]
> Subject: Re: plex86.conf script file ideas
>
>
> There are many reasons to have an alreaady
> implemented scripting language rather than roll our own.
>
> It helps to look at the script language via an
> interactive command prompt rather than a *.rc file.
> For driving debugging, testing, and other uses we
> need to be able to arbitrarily load/unload user modules,
> call routines in those modules, tweak settings
> in the VM, change registers in the VM CPU, request
> info from the VM, etc.
>
> Once you look at it this way, it eliminates using
> a simple script language and pre-processor.
>
> If all we ever want to do involves limited changes,
> then a simple script will do. But if we want real
> power from plex86, then we need more.
>
> You might have a complex debug script function, which
> loads some modules, sets up the CPU and some memory,
> and takes a few parameters. With a script language,
> we could call this at any arbitrary time and because
> of parameters not have to rewrite it 20 ways.
Sorry to tell you Kev, but you seem to have forgotten that we will have to
write it 20 different ways--script or no script. For example, what is
handled by insmod in LINUX is done by a kernel32 library call in Win32, and
so on, and so forth. Many of the things that you have mentioned seem to me
as if they would be better handled by system() calls anyway. Since we will
have to write up different sections for different OS's in any case, why not
put those sections to some use here.
>
> We also need variables. Need to be able to set a
> variable, such that the behaviour of downstream script
> code changes. With an increasing number of script
> file options, it gets rediculous commenting/uncommenting
> to get this functionality.
>
> We will certainly need to be able to recursively read
> other script files. I we are to be able to run script
> code arbitrarily from a prompt, call functions etc,
> then we really need a script language to take care of
> all this; caching script code for later execution etc.
>
> A powerful script language is an excellent way to create
> various kinds of tests, like validation tests, for plex86.
> It's also an excellent way for developers to pass test code
> to each other.
>
> I'm looking for a script language that will not only deal
> with *.rc files, but take care of all these needs.
>
> It would be ideal if the script language came as a library
> rather than having to "embed" it in the code.
>
> -Kevin
>
This may sound really dumb to those of you from the C/C++ crowd, but why
don't you just use something very dumb & designed for this job--with a
combination C/C++ block structure & a more BASIC/FORTH type syntax? As
Ramon said, all we are doing here is writing a glorified parser, right? Why
not use that functionality to handle the config files as mostly simple
"variable = value" pairs, delimited with semicolons--and then take the
parser functionality of the main project itself and use that to handle
"burn-in test" scripts as well as any other strange or non-standard things
that you may want to do "on-the-fly" like test plug&play preparedness by
alternately showing and hiding a network adapter or a printer. I think that
it should be kept in mind, while we are on the subject, that any of this
type of test "scripting" we may want to do should really be handled from a
built-in debugging "prompt" or "console," and not by the host OS, like would
be done with some sort of standard scripting language. This is because of
the sundry types of operating systems and environments that we will end up
dealing with--and what I mentioned the system() call idea for.
Also, if you plan on having the program (Plex86) manipulate the config
files or even the debug & test scripts via the built-in GUI, you are better
off keeping all of the config & and script stuff internal so that it may
handle all of the editing in a way more constructive than some of the config
tools out there for various UNIX services (SWAT comes to mind.....).
Anyway, if it isn't already clear, I side with Ramon. Make whatever we end
up using simple, clear, braindead, and local (built-in). I hope that
somebody takes this and does something more constructive with it than the
squabbling that has thus far defined this thread.
Drew Northup, N1XIM
