Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow resetting to previous error stacks; Fixes to toplevel variable evaluation #362

Closed
wants to merge 2 commits into from

Conversation

Affonso-Gui
Copy link
Member

The function reset takes an optional argument to select which level it should reset (throw). However, in current implementation the stack always wind back to level 0, independently of the argument given.

Example below.

1.eus$ (let ((a 1)) (error "1st error"))
Call Stack (max depth: 20):
  0: at (error "1st error")
  1: at (let ((a 1)) (error "1st error"))
  2: at #<compiled-code #X66045f8>
eus 0 error:  1st error in (error "1st error")
2.E1-eus$ (let ((b 2)) (error "2nd error"))
Call Stack (max depth: 20):
  0: at (error "2nd error")
  1: at (let ((b 2)) (error "2nd error"))
  2: at euserror
  3: at euserror
  4: at (error "1st error")
  5: at (let ((a 1)) (error "1st error"))
  6: at #<compiled-code #X66045f8>
eus 0 error:  2nd error in (error "2nd error")
3.E2-eus$ (eval-dynamic 'a)
1
4.E2-eus$ (eval-dynamic 'b)
2
5.E2-eus$ (reset 2)
6.eus$ (eval-dynamic 'a)
*unbound*
7.eus$ (eval-dynamic 'b)
*unbound*

With this fixes, (reset 2) throws 2 and goes back to level 1:

1.eus$ (let ((a 1)) (error "1st error"))
Call Stack (max depth: 20):
  0: at (error "1st error")
  1: at (let ((a 1)) (error "1st error"))
  2: at #<compiled-code #X64dfdc0>
eus 0 error:  1st error in (error "1st error")
2.E1-eus$ (let ((b 2)) (error "2nd error"))
Call Stack (max depth: 20):
  0: at (error "2nd error")
  1: at (let ((b 2)) (error "2nd error"))
  2: at euserror
  3: at euserror
  4: at (error "1st error")
  5: at (let ((a 1)) (error "1st error"))
  6: at #<compiled-code #X64dfdc0>
eus 0 error:  2nd error in (error "2nd error")
3.E2-eus$ (eval-dynamic 'a)
1
4.E2-eus$ (eval-dynamic 'b)
2
5.E2-eus$ (reset 2)
6.E1-eus$ (eval-dynamic 'a)
1
7.E1-eus$ (eval-dynamic 'b)
*unbound*

@inabajsk

@Affonso-Gui
Copy link
Member Author

@k-okada Please review

@Affonso-Gui
Copy link
Member Author

Added commit to solve the following problems in toplevel variable evaluation:

  • Cannot evaluate a symbol that is also fbound
  • Evaluation of unbound symbols leads to unclear response: 32512

With this changes:

1.eus$ 10
10
2.eus$ *
10
3.eus$ * 2 2
4
4.eus$ ls
c               Makefile.Cygwin    Makefile.IRIX5      Makefile.LinuxSH4.2    Makefile.SunOS5.X11R6.1
comp            Makefile.Cygwin32  Makefile.IRIX6      Makefile.Linux.thread  opengl
geo             Makefile.Cygwin64  Makefile.Linux      Makefile.rgc           README
image           Makefile.Darwin    Makefile.Linux64    Makefile.SunOS4        README.rgc
l               Makefile.generic1  Makefile.LinuxARM   Makefile.SunOS4.sub    tool
Makefile        Makefile.generic2  Makefile.Linux.ppc  Makefile.SunOS5        xwindow
Makefile.Alpha  Makefile.IRIX      Makefile.LinuxSH4   Makefile.SunOS5.i386
0
5.eus$ guiga
sh: 1: guiga: not found
Call Stack (max depth: 20):
  0: at #<compiled-code #X52d7e80>
eus 0 error: unbound variable guiga in #<compiled-code #X52d7e80>
6.E1-eus$ 

Note that

  1. * is symbol-evaluated when there are no trailing arguments and function-evaluated otherwise
  2. unbound variable errors are appropriately raised on evaluation of unbound symbols
  3. unix evaluation remains the same for valid commands

@Affonso-Gui Affonso-Gui changed the title Allow resetting to previous error stacks Allow resetting to previous error stacks; Fixes to toplevel variable evaluation Feb 27, 2019
@Affonso-Gui
Copy link
Member Author

@k-okada @furushchev @mmurooka Accepting comments.

@Affonso-Gui Affonso-Gui changed the base branch from master to cl-compatible March 6, 2019 08:21
@Affonso-Gui
Copy link
Member Author

Changed base to cl-compatible for testing features

@Affonso-Gui
Copy link
Member Author

Closing in favor of #366 and #367

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant