[racket] My PLT->Racket porting experience

At Wed, 2 Mar 2011 18:53:23 -0800, Drew Hess wrote:
> * On Mac OS X, there's a bug in play-sound: the meaning of the async
>   flag is inverted. If it's #t, the thread will pause until the sound
>   is finished playing. If it's #f, the procedure call will return
>   immediately.

I'll fix that.

> * Window management on Mac OS X is broken. Dialog boxes will sometimes
>   appear behind the main window. When this happens, it appears to the

Like others, I haven't seen that effect, but I'll try to replicate it.

The solution may be to more aggressively force certain windows to the
front within an eventspace.

> * Scrolling through a source code window in DrRacket 5.1 on Mac OS X
>   is very sluggish, quite a bit slower than it was in DrScheme
>   4.2.x.

Do you see this mainly with key combinations, by dragging the
scrollbar, or both?

> * The main difficulty I had, and how I spent most of my porting
>   and debugging time, is that paths in Racket are now relative to the
>   module in which they're used, which is different than the way
>   they're interpreted in PLT.
> 
>   I modified the Bootstrap teachpack to allow the students to override
>   the sounds that are played when various game events happen. I didn't
>   have time to do things the proper way, by making sounds a first-class
>   object in the DrScheme/DrRacket environment (which would be a great
>   enhancement, by the way), so the students have to define a couple of
>   variables whose values are strings, representing the file names of
>   the sounds they want to play. The sounds are placed in the same
>   directory as their game source code, and the variables are passed as
>   arguments to the Bootstrap teachpack's "start" procedure. The
>   Bootstrap teachpack then uses the file names as arguments to
>   play-sound.
> 
>   In PLT 4.2.x, this works great: the file names are looked up
>   relative to the directory in which the *game source code* lives, and
>   they play back as intended. In Racket 5.1 (didn't try with earlier
>   versions), the file names are looked up relative to the *teachpack's
>   directory*, and therefore aren't found.

This doesn't sound like something that we intended to change, and I'm
not clear on the setup. Can you provide a little example teachpack that
would illustrate the difference?

>   - Worst of all, on the Mac, at least, the runtime errors that are
>     raised by the teachpack when play-sound can't find the file are
>     not displayed in the Interactive window! This was the cause of
>     most of my frustration and wasted time. I had no idea why the game
>     was hanging when it was supposed to play a sound: no error
>     message, no pop-up, nothing in the log window... just a frozen
>     game window.

This is possibly related to error-printing bugs that Robby has fixed
since v5.1, although I'm not sure.