
Is there a canonical way to do what the example for https://docs.racket-lang.org/reference/exns.html#%28def._%28%28quote._~23~25kernel%29._prop~3aexn~3asrclocs%29%29\|prop:exn:srclocs does? That is, I want to raise an exception at runtime where the error source location is that of one of the arguments of the macro

I’ve tracked down the problem to an implementation that’s both slow and atomic (can’t swap threads) for multiplying an integer by a non-integer rational on CS. Here’s a simpler example: #lang racket/base
(define start-time (current-seconds))
(define STEP (/ 5 2))
(define (draw-leaf n i)
(when (zero? (modulo i 10000))
(report i))
(begin
(* n 2) ; expensive and atomic on CS
(draw-leaf (* n STEP)
(add1 i))))
(define (report i)
(collect-garbage)
(printf "~s ~s @ ~s\n"
i
(current-memory-use)
(- (current-seconds) start-time)))
(draw-leaf 1 0)
This variant doesn’t run out of memory anytime soon, because it uses begin
. But changing that begin
to cons
will accumulate memory.
The solution is to use the same algorithm that @samth had put in place for multiplying rationals. I’ll test more and then push.
With that improvement, your original example above runs out of memory quickly, just like Racket BC (but Racket CS recovers a lot better after ending the program).
Meanwhile, I don’t have a good workaround. An extra obstacle in your example is that breaks are disabled while check-syntax
runs in *SL, which is annoying and possibly worth fixing, too. (@robby: this is why I was asking) Otherwise, you have to hit the “Stop” button twice to kill the program.

Sounds like we should change check-expect
. I’ll start an email thread with mike and matthias to see if there was a reason for the current state.

Great choice of example btw.

I would recommend one of the following: 1. Expand into a use of quote-srcloc
with the macro argument whose source location you want. 2. Or first transfer the source location to a smaller syntax object, like (datum->syntax #f 'here the-macro-arg-syntax)
and then expand into a use of quote-srcloc
with that syntax instead. (This can make the expansion easier to read, for example in the macro stepper.)

~I’m not sure I understand the question? My understanding is that all error display handlers show exn-message
, and “fancy” ones will check exn:srclocs?
and if true also display the list from exn:srclocs-accessor
.~ Ah this is about the example not multiple srclocs.

@ryanc Thanks!

Is there a simple way to provide
something from a *SL file (doesn’t matter if it’s ISL+ or ASL)?

%provide ?

"#%provide: This function is not defined"

Trikcy. Maybe write a module that exports provide
and then require that module?

Tricky even.

But that’s doesn’t qualify as “simple” though.

If I (require racket/base)
in order to get to provide
, then it also imports things that shadow *SL bindings… I think I need to do the bounce-through-another-file approach, or just give the starter code as a #lang racket
file anyway

(require (only-in racket/base provide))
?

I couldn’t make it work with quote-srcloc
(the source location wasn’t displayed in DrR, so I assume it didn’t like the format of what was given) but it works with syntax-srcloc

only-in
isn’t part of ASL :wink:

(the require syntax expects a module, string path, or a (lib …) form, but not a general require-spec)

Are you making a teachpack for *SL Languages?

Might be easier to crib from one of the existing teachpacks that import stuff without trampling the student language level.

Thanks!

And to be clear: this problem doesn’t show up in BC? (We’ve been recommending students use BC, but some students have M1s and can only use CS, which probably explains why we’re not seeing it more often)

Right, the specific problem here was CS-specific.

Okay thanks. We have a midterm on Monday, and a problem that is likely to trigger this bug. If you have ideas for mitigations or workarounds, let me know. I’m going to consider whether we should change this problem.

@67j8vwjc4oud has joined the channel

At least one student reports BC works fine under Rosetta; does anyone know of issues affecting Racket under Rosetta on Apple m1?

My understanding is that it works correctly, but it hasn’t had much testing.

It didn’t work right at first but then they fixed something in Rosetta

There is an issue with places and the GC write barrier — something about signals not being delivered in the right thread. I haven’t seen it affect DrRacket, though.

@jsulmont has joined the channel