Re: [racket-users] Stack trace

2019-05-03 Thread Mark Engelberg
> Krishnamurthi et al. have been working on[*] for Pyret, which shows the > evaluation of a term as a single large tree, allowing you to inspect each > call and the arguments that were passed to each call. > > John > > [*] I thought of it independently, but they thought of

[racket-users] Stack trace

2019-05-02 Thread Mark Engelberg
Working with a student in DrRacket for the first time in a while. I notice that in BSL, an error in a function does not tell you what input to the function caused the error, nor does it show the stack trace by drawing arrows in the definitions window the way I remember. When did this behavior

Re: [racket-users] IO in racket is painful

2016-03-22 Thread Mark Engelberg
On Tue, Mar 22, 2016 at 9:20 PM, Stephen Chang wrote: > :) I had started writing up a parsack example, and I was all set to > admonish the OP for not creating a parser when you want a parser but > then I saw it was for a programming contest where I guess this sort of >

Re: [racket-users] IO in racket is painful

2016-03-22 Thread Mark Engelberg
Hi, I have coached several teams on using Racket in programming contests. In our local contests, the most common input format is to have one line per dataset, and each dataset is typically several pieces of data separated by spaces. For this common input format, the 2htdp/batch-io teachpack is