Skip to content

can’t debug

Forums Forums SIMPOL Programming can’t debug

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #46
    Jim Locker
    Member

    When I try to run the debugger, I am getting this message: Error: internal error in function “Error value: 60 ValBldg3: previous code: lv1._.fg.fc.curbldg =@ getrecord(lv1._.fg.sg,”building.sbm”,”BUILDING”,”BldgName”,lv7,precise=”exact”)” Error: the runtime information couldn’t be retrieved The line being referred to is this: me._.fg.fc.curbldg =@ getrecord(me._.fg.sg,”building.sbm”,”BUILDING”,”BldgName”,sName,precise=”exact”) The documentation for Error 60 says that it means “Debugger: malformed statement. – Internal” Well that doesn’t help much. Earlier, I had this error, and I discovered a variable definition statement a few lines above that ended in a comma. Fixed it, problem disappeared. This time, I don’t see such an error, AND this code was compiling and executing without issue until I added a new event handler further down in this file. I copied/pasted some code (including the indicated line) to get me started in that new event handler, but the whole thing compiles without incident. So what does this error mean and what can I do about it? I tried smprun32, but I can’t seem to get it to run from the command line. Error this and error that – I finally gave up.

    #1559
    Michael
    Keymaster

    Jim wrote:
    > When I try to run the debugger, I am getting this message:
    >
    > Error: internal error in function "Error value: 60 ValBldg3: previous
    > code: lv1._.fg.fc.curbldg =@
    > getrecord(lv1._.fg.sg,"building.sbm","BUILDING","BldgName",lv7,precise="exact")"
    > Error: the runtime information couldn't be retrieved
    >
    > The line being referred to is this:
    >
    > me._.fg.fc.curbldg =@
    > getrecord(me._.fg.sg,"building.sbm","BUILDING","BldgName",sName,precise="exact")

    No, it is actually referring to the line that follows that line. I added
    this bit of diagnostic info to try and help track these problems down.
    It can't tell you the line you are on, but it can tell you the previous
    line it processed successfully. So what does the code from the next line
    look like?

    > The documentation for Error 60 says that it means "Debugger:
    > malformed statement. – Internal"
    >
    > Well that doesn't help much.

    I appreciate that, but I have never managed to get one in the 8 years I
    have been programming in SIMPOL, so it isn't a common one by any means.

    > Earlier, I had this error, and I discovered a variable definition
    > statement a few lines above that ended in a comma. Fixed it, problem
    > disappeared.
    >
    > This time, I don't see such an error, AND this code was compiling and
    > executing without issue until I added a new event handler further
    > down in this file. I copied/pasted some code (including the
    > indicated line) to get me started in that new event handler, but the
    > whole thing compiles without incident.
    >
    > So what does this error mean and what can I do about it?
    >
    > I tried smprun32, but I can't seem to get it to run from the command
    > line. Error this and error that – I finally gave up.

    Actually, if you have installed SIMPOL, you should be able to just run
    the program with its name from the command line. For debugging, it
    becomes more messy, you need to use the full path and call smpd1_32.exe
    instead.

    Ciao, Neil

    #1826
    Jim Locker
    Member

    Neil Robinson wrote:

    > Jim wrote:
    >> When I try to run the debugger, I am getting this message:
    >>
    >> Error: internal error in function "Error value: 60 ValBldg3: previous
    >> code: lv1._.fg.fc.curbldg =@
    >>
    getrecord(lv1._.fg.sg,"building.sbm","BUILDING","BldgName",lv7,precise="exact")"
    >> Error: the runtime information couldn't be retrieved
    >>
    >> The line being referred to is this:
    >>
    >> me._.fg.fc.curbldg =@
    >>
    getrecord(me._.fg.sg,"building.sbm","BUILDING","BldgName",sName,precise="exact")

    > No, it is actually referring to the line that follows that line. I added
    > this bit of diagnostic info to try and help track these problems down.
    > It can't tell you the line you are on, but it can tell you the previous
    > line it processed successfully. So what does the code from the next line
    > look like?

    This is the next few lines:

    if me._.fg.fc.curbldg =@= .nul
    if not me._.fg.sg.fallback
    //do ppcs stuff
    end if
    else

    Note that the inner if statement is essentially stubbed out; there at
    present is no executable line inside it. I'll test to see if that is the
    problem, but at this time I have a fair number of these things – all
    associated with currently unimplemented ppcs interface stuff that I have
    not yet ported – and the debugger is not complaining about them.

    #1696
    Jim Locker
    Member

    Jim wrote:

    > This is the next few lines:

    > if me._.fg.fc.curbldg =@= .nul
    > if not me._.fg.sg.fallback
    > //do ppcs stuff
    > end if
    > else

    OK, the two lines after this segment were these:

    bGotbldg = .true
    end if

    So, I inverted the logic, and made the code look like this:

    if me._.fg.fc.curbldg !@= .nul
    bGotbldg = .true
    else
    if not me._.fg.sg.fallback
    //do ppcs stuff
    end if
    end if

    and suddenly the debugger was happy.

    Go figure.

    I do understand the situation, but if the logic was invalid I would have
    expected the compiler to choke on it.

    Apparently the debugger is happy so long as the first branch of the if has
    something in it, and will permit the else branch to be empty, but not
    vice-versa.

    #1530
    Michael
    Keymaster

    Jim wrote:
    > and suddenly the debugger was happy.
    >
    > Go figure.
    >
    > I do understand the situation, but if the logic was invalid I would
    > have expected the compiler to choke on it.
    >
    > Apparently the debugger is happy so long as the first branch of the
    > if has something in it, and will permit the else branch to be empty,
    > but not vice-versa.

    Jim,

    The problem is that in the compiled code, there is no place where the
    end if statement is located, (the code is not there in the compiled
    code, it just goes to the next logical place), so for the debugger to
    work, it has to reverse engineer the compiled code, and then try to
    associate that with the source. Most of the time it works well, but not
    always. Empty stub style ifs can really cause trouble. I sometimes just
    put something like i = 1 in them, just to make it easier.

    Ciao, Neil

Viewing 5 posts - 1 through 5 (of 5 total)
  • You must be logged in to reply to this topic.