Hmm, I don't think the greedy approach will work.
The first line of the second thread, (set! a (list c)), will execute
without error immediately, but it really needs to happen between the
evaluation of a and (first a) in the first line of the first thread.
Probably needs to be done by hand.
_
It looks like the puzzle is to find an interleaving of execution that
makes sense.
Other than solving it by hand, one idea I have is to wrap around each
line of code some sort of error handler that keeps trying that line
until it succeeds. This should work if the puzzle has been designed
so that
On Wed, Jan 19, 2011 at 02:43:40PM -0500, Doug Orleans wrote:
> The following program was a puzzle in the 2011 MIT Mystery Hunt held last
> weekend. (I'm not linking directly to the site because they posted a
> solution and I don't want you to be tempted to look at the answer
> prematurely...) I
The following program was a puzzle in the 2011 MIT Mystery Hunt held last
weekend. (I'm not linking directly to the site because they posted a
solution and I don't want you to be tempted to look at the answer
prematurely...) I was disappointed that Dr Racket doesn't seem to have a
multi-threaded
Since Hacker News is probably the busiest site running on PLT Scheme,
the following might be interesting to those interested on how MzScheme
handles load:
http://ycombinator.com/newsnews.html#19jan
Note that this applies to MzScheme, and not necessarily Racket. Arc
(which runs HN) runs on the o
I guess I'm the closest we have to a MysterX maintainer. Unfortunately,
my answer for question 1 is "I don't know". For the other two, I can
only say "that sounds like a bug".
MysterX was created prior to the current FFI, and re-implementing it is
probably a good idea --- if we can find a voluntee
6 matches
Mail list logo
