Pop-11's compiler checks only for syntactic correctness.
Additional (semantic) checks are done at run time.
If you use the SimAgent toolkit, the parts of your program that define
rules, rulesets, rulesystems, etc. are no longer pop11, but use a syntax
defined mostly in the poprulebase library, which extends pop11.
There is some syntax checking done when rules are read in, and
there is more checking done at run time (e.g. the rule interpreter
checks for stack errors caused by running pop11 code in conditions or
actions, and if you have pop11 code in conditions or actions the
normal pop11 run-time checks will be done).
You have to read the Mishap messages *very* carefully to work out what
is going wrong.
> I have written a simulation program by sim_agent, but when I compile it ,I
> receive wonderful errors(mishap interrupted) as they have confused me.
Is this while the code is compiled, but not yet run. E.g. is it BEFORE
you invoke sim_scheduler ?
The example given at the end of your message should compile just fine if
you fix this bit
[num of protectors is ?num_p] (*************************error
line*********************)
and remove line breaks in the various 'end of line' comments (starting
';;;'). I suspect those line breaks were not in your code, only in the
email message.
If you intended the line above to include a pop11 comment it would have
to start with "/*" and end with "*/" separated from other asterisks.
E.g.
[num of protectors is ?num_p] /* *************************error
line******************** */
Otherwise there is no reason why that line should produce any kind of
error during compilation.
However if your variable ?num_p gets the value 0 then you can get an
'overflow' error (MISHAP - DIVIDING BY ZERO) when you use it in a
division expression in the action later on.
That would happen at run time not compile time.
> For
> example, sometimes, I don't change any things and compile again and receive
> mishap interrupted at another line but with the same column number (at or
> before line â??line numberâ?? column 56(this number is fixed always)).
This could happen if you are not merely compiling code, but running it,
and the command you give to run the code takes up 55 columns. E.g. the
following command always produces
;;; MISHAP interrupted
;;; (At or before line 1231 column 41)
'this is a cat' + 'this is a dog' =>
> I check
> above lines of it, each time but I have not perceive any special errors.
I suspect you have not provided enough information for a remote
diagnosis.
If you start pop11, then compile a file which has at the top:
uses newkit
then defines classes, rulesets, rulefamilies and rulesystems
but does not include any instructions to *run* the program and has no
instructions to create any instances of the classes, do you still get
the Mishap message?
If you only get the message when you run the program, that could be
caused by many things: E.g. badly defined procedures, global variables
not initialised properly, class instances with slots not initialised
properly, mistakes in conditions or actions in rules.
The description of your program at the end looks quite complicated.
Did you get a simpler version to run?
You should first make sure you can run a simple version of your program
and then gradually extend it, testing each bit as you add it.
If you write a lot of code, then try to run it tracking down errors
can be very difficult because you don't know which bits of the program
you can rely on.
> Also, FOR loop as the following form isn't run at my pop11 ! and I got
> error:
> for 1->i step i+1->i till i<k+1 do <action> endfor;
This will do nothing because if k is greater than 0, the condition
i<k+1
will be true at the beginning and so the program will stop immediately.
E.g.
vars i;
for 1 -> i step i+1 -> i till i < 5 do [hello ^i] => endfor;
prints nothing.
This version:
vars i;
for 1 -> i step i+1 -> i till i > 5 do [hello ^i] => endfor;
prints
** [hello 1]
** [hello 2]
** [hello 3]
** [hello 4]
** [hello 5]
> Then, I used " for i to k do <action> endfor;".
The 'step' .... 'till' format for 'for' loops is very general, but is
more likely to lead to mistakes than the other formats described in
HELP FOR
and
HELP FOR_FORM
Aaron
|