Forums › Forums › SIMPOL Programming › can’t debug
- This topic has 4 replies, 2 voices, and was last updated 14 years, 5 months ago by Jim Locker.
- AuthorPosts
- December 15, 2009 at 3:22 am #46Jim LockerMember
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.
December 15, 2009 at 9:36 am #1559MichaelKeymasterJim 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
December 15, 2009 at 5:39 pm #1826Jim LockerMemberNeil 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
elseNote 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.December 16, 2009 at 6:49 am #1696Jim LockerMemberJim wrote:
> This is the next few lines:
> if me._.fg.fc.curbldg =@= .nul
> if not me._.fg.sg.fallback
> //do ppcs stuff
> end if
> elseOK, the two lines after this segment were these:
bGotbldg = .true
end ifSo, 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 ifand 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.December 16, 2009 at 8:20 pm #1530MichaelKeymasterJim 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
- AuthorPosts
- You must be logged in to reply to this topic.