BSL error stepping big-bang

[maueroats]

I know this occurred running the stepper on a big-bang, which should not be done.

Error message

This occurs in the stepper.

skip-step?: expects (or/c (listof procedure?) #false) or false, given (list function "supposed to be skipped" function)
  in: the 2nd argument of
      (->
       (or/c
        'normal-break
        'normal-break/values
        'result-exp-break
        'result-value-break
        'double-break
        'late-let-break
        'expr-finished-break
        'define-struct-break)
       (or/c (listof procedure?) #false)
       render-settings?
       boolean?)
  contract from: 
      <pkgs>/htdp-lib/stepper/private/reconstruct.rkt
  blaming: <pkgs>/htdp-lib/stepper/private/model.rkt
   (assuming the contract is correct)
  at: <pkgs>/htdp-lib/stepper/private/reconstruct.rkt:48:2

Source code

The complaint appears to be originating from this line. The complaint looks like an error that the string "supposed to be skipped" does not satisfy procedure?.

This might arise from more careful enforcement of a contract than in the past?

Would replacing the string with (lambda () "supposed to be skipped") cause problems?

Reproduce

(require 2htdp/image)
(require 2htdp/universe)

(define nothingness (square 0 "solid" "transparent"))

(define (2draw3 img)
  (overlay img (empty-scene 400 100)))

(big-bang nothingness
  (to-draw 2draw3))

[shhyou]

It looks like d53a197 changed run-it to send which could be the cause.

[rfindler]

I wonder if using quasisyntax/loc would work but on the call to run-it (perhaps putting it into a non-tail position too?)

[shhyou]

Well, just using the previous version of run-it is not sufficient, but it has to be the commented out run-it function in 36fc539.

@mfelleisen in 36fc539, why was the old run-it replaced by only the send part? I can use raco exe to create executables with the commented out run-it, so is it okay to uncomment run-it?

  ;; (-> Object) -> Any
+ (define (run-it o)
+   (send (o) last))
+ 
+ #;
  (define (run-it o)
    (define esp (make-eventspace))
    (define thd (eventspace-handler-thread esp))
    (with-handlers ((exn:break? (lambda (x) (break-thread thd))))
      ...

[rfindler]

I think the highlighting (the reason behind d53a197) is affected by things like tail position (which the run it that was replaced in 36fc539 would have had differently) and the stepper can be affected by syntax properties or annotations that say things like "please ignore functions named run-it".

The function that creates a new eventspace and disables breaks, etc, seems like a concern unrelated to the stepper and also unrelated to highlighting.

[shhyou]

I think the highlighting (the reason behind d53a197) is affected by things like tail position (which the run it that was replaced in 36fc539 would have had differently) and the stepper can be affected by syntax properties or annotations that say things like "please ignore functions named run-it".

Yes, I see the point behind d53a197 that fixes the source location for highlighting, but it turns out that only reverting the inlining of run-it and using run-it per the (define (run-it o) (send (o) last)) code does not solve the problem. But it turns out that using the commented-out run-it function from 36fc539 does solve the bug, so something else must be going on.

The function that creates a new eventspace and disables breaks, etc, seems like a concern unrelated to the stepper and also unrelated to highlighting.

The weird thing is using the run-it that creates an eventspace does make a difference and the stepper doesn't break anymore. It also runs the object creation ((o)) in a different thread, so some of these must be affecting the continuation marks.

[mfelleisen]

This arrangement was carefully "negotiated" between John and myself -- but of course, the rationale is in two heads and not written down. @shhyou is correct in that the thread arranges continuation marks differently and that's the key to the stepper marking up the stack.