>>
APLDN Home

>>
Events

>>
Trainings

>>
APL Books

>>
APLDN Links

>>
Discussion Groups

>>
Downloads

>>
Articles

>>
Library

>>
Learning Tools

>>
APLDN User IO

>>
APL2000.com




Bug Reports

Author Thread: Bug in Code Walker?
Paul.Ravitz
Bug in Code Walker?
Posted: Tuesday, July 25, 2006 12:36 PM (EST)

Consider these two functions:

 

    foo1
[1]   0 0½0
[2]   3+4
   

 

    foo2
[1]   0 0½0
[2]   3+
   

Put a stop on line [1] of both functions.

 

Run foo1.  It stops on [1].  Press F10.  It runs line [1] and then stops on [2] (as it should).

 

Run foo2.  It stops on [1].  Press F10.  It runs line [1] but it does NOT stop on [2], but immediately signals SYNTAX ERROR on [2].  I don't think this is correct -- it should have stopped before trying to execute line [2].

 

Interestingly, if you ALSO put a stop on line [2], foo2 DOES stop before executing line [2] when you single-step with F10.  But it shouldn't matter whether you have a stop or not on line [2]; F10 should single-step and stop BEFORE a line is executed.


Comments:

Author Thread:
Patrick.Parks
Bug in Code Walker?
Posted: Tuesday, July 25, 2006 2:25 PM (EST)
Hi Paul, I agree with your assessment. F10 should stop on line [2] in both cases WITHOUT signalling the SYNTAX ERROR. This is a bug. However, I do NOT think this is happening because we are trying to EXECUTE line [2] without stopping after F10. It is probably happening beause we are COMPILING line [2] proactively and discovering the SYNTAX ERROR. Pat

     

Mark.Osborne
Bug in Code Walker?
Posted: Tuesday, July 25, 2006 3:50 PM (EST)

Paul,

 

I think Pat's assessment is on the mark.  Furthemore, F10 requests a step to line [2].  The interpreter needs to hang it's hat somewhere on the beginning of the line[2] codestring, but there isn't one yet, so there is no place for the token pointer to point to when stopping at the beginning of line[2].  Before we can stop there, we need to create the codestring by parsing the line.  That's when we get the syntax error.  Given the syntax error, there is no way to build a correct codestring to stop on.  So we have no alternative but to signal the error and suspend.

 

I don't think there is much else we can do here in any trivial way.

 

Am I missing something here and this is somehow more important to you than it appears to me?

 

/Mark

     

Paul.Ravitz
Bug in Code Walker?
Posted: Tuesday, July 25, 2006 4:03 PM (EST)
It's not terribly important. The example I gave was a simplification of an actual occurrence that happened to me today, to make it easier for others to duplicate it. It surprised me (that it appeared to execute), so I thought it was worth reporting. But since it's not actually executing but is only in an analysis stage, no harm is being done, so I don't think it should be high on anyones list. However, can you explain why it IS able to stop (apparently before creating the codestring) with F10 when there's a STOP on the line? Is it that the stop gives it a place "to hang it's hat"? Thanks. p

     

Mark.Osborne
Bug in Code Walker?
Posted: Tuesday, July 25, 2006 4:21 PM (EST)

Paul,

 

The STOP bit is stored in a byte in a codestring.  So setting a STOP on a line that does not yet have a codestring causes a dummy codestring to be materialized for that line.  It doesn't do syntax analysis, just drops a canonical dummy codestring in as a storage point for the stop bit.  So you don't get the syntax error then until you try to step past the dummy codestring and cause the line to be parsed.

 

/Mark

     



APL2000 Official Web Site

Make others happy and joyful. Your happiness will multiply a thousand fold.
--- Swami Sivananda

APLDN Home   |    |  Events   |  Trainings   |  APL Books   |  APLDN Links   |    |  Discussion Groups   |    |  Downloads   |  Articles   |  Library   |  Learning Tools   |  APLDN User IO   |  APL2000.com   |