Re: [racket-users] Racketeers and slide-show presentations

On 16/09/2017 16:47, Daniel Brunner wrote: I switched to slideshow/pict recently but it takes a lot of time for me to prepare the presentation due to my missing skills in using pict. That's also the major stumbling block for me. Whenever I have to prepare a presentation, it's just not the

[racket-users] Re: Racketeers and slide-show presentations

On Sat, 16 Sep 2017 10:08:56 -0400 Matthias Felleisen wrote: > When you watch the presentations of people who present with > latex/beamer, you notice that most just excerpt the paper. This > reduces the amount of time needed to prepare the presentation and the > quality of

[racket-users] Re: Racketeers and slide-show presentations

On Sat, 16 Sep 2017 16:47:41 +0200 Daniel Brunner wrote: > Hello, > I switched to slideshow/pict recently but it takes a lot of time for > me to prepare the presentation due to my missing skills in using pict. Are you happy with it? You're right - I can also feel that for

[racket-users] Re: Racketeers and slide-show presentations

On Sat, 16 Sep 2017 12:48:24 -0700 Andrew Gwozdziewycz wrote: > I've been hacking on a way to make *simpler* slideshow presentations, > which I'll actually present briefly at Racketcon next month. The idea > is to take something plaintext and turn it into slides, so you don't >

Re: [racket-users] Racketeers and slide-show presentations

On 16/09/2017 21:48, Andrew Gwozdziewycz wrote: I've been hacking on a way to make *simpler* slideshow presentations, which I'll actually present briefly at Racketcon next month. The idea is to take something plaintext and turn it into slides, so you don't have to be a pict master. I am

Re: [racket-users] Racketeers and slide-show presentations

> On Sep 17, 2017, at 5:34 AM, Konrad Hinsen wrote: > > Did anyone consider to implement something like sketch-n-sketch for Racket > picts? > > https://ravichugh.github.io/sketch-n-sketch/ > > The idea is to combine interactive manipulation and programmatic

Re: [racket-users] TR for fast manipulation of C data

Thanks to all of you; with casts changed to asserts, the use of unsafe-vector primitives, and changing the language to /no-check (which, if I’m understanding correctly, will disable contract checking as Robby suggests), resampling 15 seconds of audio goes from 1.2 seconds at the command line to

Re: [racket-users] TR for fast manipulation of C data

Each call in the program shrinked from ~20s to ~0.4s on my computer if I replaced all the casts with asserts. Given there's a correspondence between the two for base types, I wonder if existing gradually typed programs would benefit just from a more optimized expansion of `cast`. On Sun, Sep 17,

[racket-users] TR for fast manipulation of C data

I’m currently unhappy with the speed of rsound’s resampling. This is a pretty straightforward interpolation operation; if you’re not already familiar, imagine mapping an old vector ‘o' of size M onto a new vector ’n’ of size N where each point ‘i’ in the new vector is obtained by linearly

Re: [racket-users] TR for fast manipulation of C data

Simply changing all the casts (cast _ Natural) into (assert _ exact-nonnegative-integer?), and (cast _ Positive-Flonum) into (assert (assert _ flonum?) positive?) speeds up significantly for me. On Sun, Sep 17, 2017 at 9:11 PM, Robby Findler wrote: > Maybe a first

Re: [racket-users] TR for fast manipulation of C data

(and (cast _ Positive-Fixnum) into (assert (assert _ fIxnum?) positive?)). Somehow these make a huge difference.) On Sun, Sep 17, 2017 at 9:19 PM, Phil Nguyen wrote: > Simply changing all the casts (cast _ Natural) into (assert _ > exact-nonnegative-integer?), and

Re: [racket-users] TR for fast manipulation of C data

`cast` uses the contract system, which is harder for the compiler to optimize than `assert` which is just an if. At least that's my initial impression. Sam On Sep 17, 2017 9:27 PM, "Phil Nguyen" wrote: > (and (cast _ Positive-Fixnum) into (assert (assert _ fIxnum?)