@robby drracket changes the error-display-handler to displaying a message-box. Is there a way to retrieve the original display handler that outputs text on the error-port?
drracket:init I believe
Hm
They don’t seem to be documented.
errortrace-error-display-handler seems to do the job
This is my compilation procedure now: (define err-str-port (open-output-string))
(define cmc (make-caching-managed-compile-zo))
(parameterize ([current-error-port err-str-port]
[current-namespace (make-base-empty-namespace)])
(for ([f (in-list files)])
(with-handlers* ([exn? (λ (e) (errortrace-error-display-handler (exn-message e) e))])
(time-info (format "Compiling ~a" (path->string f))
(cmc f))))) However it still doesn’t recompile scripts which zos have the wrong racket version number
I suspect some interaction with DrRacket that can’t be seen from just the code above
This isn’t relevant to the problem you’re having, but using exn? is wrong; you want exn:fail? to avoid catching break exceptions
errotrace-display-handler is intended for use when you’re using errotrace
(which you aren’t)
I’m not sure what will go wrong exactly, however.
doesn’t with-handers* do that already?
No….
that’s not what the docs mean.
Seems to be working well afaict. It outputs an error message like scripts/unbound-id-not-skipped.rkt:12:4: some-unbound-id: unbound identifier
in: some-unbound-id
errortrace...:
context...:
/usr/share/racket-7.9.0.3/collects/compiler/private/cm-minimal.rkt:608:0: compile-zo*
/usr/share/racket-7.9.0.3/collects/compiler/private/cm-minimal.rkt:407:15
/usr/share/racket-7.9.0.3/collects/compiler/private/cm-minimal.rkt:396:12: build
/usr/share/racket-7.9.0.3/collects/compiler/private/cm-minimal.rkt:372:0: maybe-compile-zo
/usr/share/racket-7.9.0.3/collects/compiler/private/cm-minimal.rkt:206:0: compile-root
/usr/share/racket-7.9.0.3/collects/compiler/private/cm-minimal.rkt:102:4
/home/laurent/Prog/Racket/quickscript/base.rkt:199:6
/home/laurent/Prog/Racket/quickscript/base.rkt:181:0: compile-user-scripts
/home/laurent/Prog/Racket/quickscript/tool.rkt:59:2
body of "/home/laurent/Prog/Racket/quickscript/tool.rkt"
/usr/share/racket-7.9.0.3/pkgs/drracket/drracket/private/tools.rkt:294:2
/usr/share/racket-7.9.0.3/pkgs/drracket/drracket/private/tools.rkt:72:0: load/invoke-all-tools
.../racket/unit.rkt:996:20
body of "/usr/share/racket-7.9.0.3/pkgs/drracket/drracket/tool-lib.rkt"
body of "/usr/share/racket-7.9.0.3/pkgs/drracket/drracket/private/drracket-normal.rkt"
body of "/usr/share/racket-7.9.0.3/pkgs/drracket/drracket/drracket.rkt"
what do they mean then?
but okay to avoid catching exn:break? in any case
It isn’t okay to catch exn:break.
Replaced with (λ (e) (and (exn? e) (not (exn:break? e))))
I think you want exn:fail?
alright, I can change to that.
I don’t see what’s wrong with the code you wrote for compiling zos. I’ll try to look more deeply into it later on.
Thanks!
Another possibility is that it actually works well, but something else makes it appear to me as if it doesn’t. I’ll continue looking into it
I confirm that compilation does not happen for the faulty zos
quickscript: Begin: Compiling /home/laurent/Prog/Racket/quickscript-test/scripts/test-compile-cs.rkt...
quickscript: compiled-for-current-version? #f
[compiling...]
quickscript: compiled-for-current-version? #f
one fix is still to use this detection and delete the faulty zos files before compiling, but it’s probably best to know where the problem comes from anyhow
My feeling is that many changes can cause a zo file to be problematic so we probably don’t want to use a version number test (outside of CM that is).
I agree. Still a last resort though, in case we really can’t figure out what’s wrong
(in particular since this is a rather common case)
If you’re out of ideas, I’ll try to build a MWE. I’m pretty sure that’s not going to be straightforward though :smile: