Currently working with DrRacket 7.2 on Mac OS X. What bugs me is that everything becomes unresponsive while executing heavy stuff or code that does not terminate. The stop/kill button usually does nothing and force-quitting the app is the only option. I tried the latest Racket-on-Chez build which seems much better in this regard, but is over-all rather sluggish. Hope this will improve.
I test drove Racket-on-Chez the other day by attempting to use the pict3d module (since 3d is an application that needs speed). My experience was as follows:
1) Install pict3d through DrRacket's built-in package manager - sudden, silent crash. Luckily I ran it from a terminal, which indicates an out of memory error.
2) Raise DrRacket's memory limit to "unlimited" and retry. Same result.
3) Google how to install packages from the command line. Wait for package to build. Build hangs during documentation. Eventually give up and ctrl-c. Hopefully it still works without docs? Racket packages aren't transactional, so every failed build leaves Racket thinking a package is installed, but it's actually broken.
4) Run DrRacket. Load pict3d and type oneliner. Incautiously press an F-key I assume will run the program. DrRacket crashes.
5) Run DrRacket. Load pict3d and type oneliner. Carefully run the program. Scene is incredibly slow but works! Then DrRacket hard crashes and locks my entire desktop so I have to go to a TTY to recover. My graphics are corrupted in a minor way. I haven't rebooted since then, and they're still corrupted.
I really, really like the look of Racket and want to use it in anger for a project, and I have a specific one in mind that would benefit from 3D, but this user experience is singularly bad. It's probably pict3d's fault, but there's no indication of this module being of "pre-alpha" stability. Or maybe it's an interaction with Racket-on-chez and C library interfacing. Let's hope it gets better.
> It's probably pict3d's fault, but there's no indication of this module being of "pre-alpha" stability. Or maybe it's an interaction with Racket-on-chez and C library interfacing.
Racket-on-Chez is what's pre-alpha. I don't think there's been requests for anyone to test it unless they were going to dig into the guts and try to fix things.
> since 3d is an application that needs speed
if the slowest part of your 3D is how quickly you can make calls into OpenGL, you're in a pretty good place.
Out of curiosity, is there a particular reason you were trying to use Racket CS for this?
AFAIU typed Racket currently adversely affects performance on Racket CS (in certain cases) and pict3d looks like it's a non-base package written in typed Racket so it's likely not the best candidate for running on Racket CS right now.
