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

['John Clements' via users-redirect]

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 0.24 seconds, 
about 5x faster. That means about 1 second per minute, which essentially 
changes the time from “why is my computer taking forever to load this song” 
down to “oh, that’s not as snappy as it could be,” which is a vast improvement.

Also, thinking about it harder, there’s no type in TR that corresponds to a 
signed 16-bit integer, so the type system isn’t going to have the tools to 
eliminate the range check anyhow; I have to go for the unsafe one if I want to 
avoid that check.

Finally, *many* thanks for the clarification on the difference between cast and 
assert. Like Phil, I’m surprised that the cast can’t be optimized to the assert 
in the common case of the flat types, but I’ve discovered many times with TR 
that there are corner cases that I’m not thinking of.

Best,

John Clements


> On Sep 17, 2017, at 21:16, Phil Nguyen  wrote:
> 
> 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, 2017 at 9:39 PM, Sam Tobin-Hochstadt  
> wrote:
> `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?) 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 (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 step is to just (unsafely) disable the contract checking
> in order to see what the upper-limit of the improvement is.
> 
> Robby
> 
> 
> On Sun, Sep 17, 2017 at 8:07 PM, 'John Clements' via users-redirect
>  wrote:
> > 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 
> > interpolating the two points of the old vector nearest to i*(M/N).
> >
> > Currently, it takes about 10 seconds to resample 60 seconds of audio, which 
> > I believe could be much much better. I bet that TR would help a lot here, 
> > but I’ve been poking around, and I don’t see any typed access to s16vectors 
> > or cpointers. I’m guessing that importing the ffi/unsafe functions with 
> > wrappers would be considerably slower...
> >
> > … well, I shouldn’t guess. I should try.
> >
> > AAGH! Yep, I was right. it goes 7x slower after naive conversion to TR. I 
> > could probably do better by working with the optimization coach, but I’m 
> > guessing that interposing the contract boundary on every read and write to 
> > the s16vector is a big slowdown that could easily be avoided. So: is there 
> > a good way to use TR for access to cpointers?
> >
> > I’ve attached the code in case anyone wants to see it; I don’t really care 
> > about the first call to (time …); it’s appallingly slow (20x slower in TR), 
> > but that’s not the part I’m trying to speed up. It’s the second call to 
> > (time…), around
> > the resample call.
> >
> > John
> >
> >
> >
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Racket Users" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to racket-users+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
> 
> --
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
> 



-- 
You received 

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

[Phil Nguyen]

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, 2017 at 9:39 PM, Sam Tobin-Hochstadt 
wrote:

> `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?)
>> 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 (cast _ Positive-Flonum) into (assert
>>> (assert _ flonum?) positive?) speeds up significantly for me.
>>>
>>> On Sun, Sep 17, 2017 at 9:11 PM, Robby Findler <
>>> ro...@eecs.northwestern.edu> wrote:
>>>
 Maybe a first step is to just (unsafely) disable the contract checking
 in order to see what the upper-limit of the improvement is.

 Robby


 On Sun, Sep 17, 2017 at 8:07 PM, 'John Clements' via users-redirect
  wrote:
 > 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
 interpolating the two points of the old vector nearest to i*(M/N).
 >
 > Currently, it takes about 10 seconds to resample 60 seconds of audio,
 which I believe could be much much better. I bet that TR would help a lot
 here, but I’ve been poking around, and I don’t see any typed access to
 s16vectors or cpointers. I’m guessing that importing the ffi/unsafe
 functions with wrappers would be considerably slower...
 >
 > … well, I shouldn’t guess. I should try.
 >
 > AAGH! Yep, I was right. it goes 7x slower after naive conversion to
 TR. I could probably do better by working with the optimization coach, but
 I’m guessing that interposing the contract boundary on every read and write
 to the s16vector is a big slowdown that could easily be avoided. So: is
 there a good way to use TR for access to cpointers?
 >
 > I’ve attached the code in case anyone wants to see it; I don’t really
 care about the first call to (time …); it’s appallingly slow (20x slower in
 TR), but that’s not the part I’m trying to speed up. It’s the second call
 to (time…), around
 > the resample call.
 >
 > John
 >
 >
 >
 > --
 > You received this message because you are subscribed to the Google
 Groups "Racket Users" group.
 > To unsubscribe from this group and stop receiving emails from it,
 send an email to racket-users+unsubscr...@googlegroups.com.
 > For more options, visit https://groups.google.com/d/optout.

 --
 You received this message because you are subscribed to the Google
 Groups "Racket Users" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to racket-users+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Racket Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to racket-users+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Sam Tobin-Hochstadt]

`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?) 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 (cast _ Positive-Flonum) into (assert
>> (assert _ flonum?) positive?) speeds up significantly for me.
>>
>> On Sun, Sep 17, 2017 at 9:11 PM, Robby Findler <
>> ro...@eecs.northwestern.edu> wrote:
>>
>>> Maybe a first step is to just (unsafely) disable the contract checking
>>> in order to see what the upper-limit of the improvement is.
>>>
>>> Robby
>>>
>>>
>>> On Sun, Sep 17, 2017 at 8:07 PM, 'John Clements' via users-redirect
>>>  wrote:
>>> > 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
>>> interpolating the two points of the old vector nearest to i*(M/N).
>>> >
>>> > Currently, it takes about 10 seconds to resample 60 seconds of audio,
>>> which I believe could be much much better. I bet that TR would help a lot
>>> here, but I’ve been poking around, and I don’t see any typed access to
>>> s16vectors or cpointers. I’m guessing that importing the ffi/unsafe
>>> functions with wrappers would be considerably slower...
>>> >
>>> > … well, I shouldn’t guess. I should try.
>>> >
>>> > AAGH! Yep, I was right. it goes 7x slower after naive conversion to
>>> TR. I could probably do better by working with the optimization coach, but
>>> I’m guessing that interposing the contract boundary on every read and write
>>> to the s16vector is a big slowdown that could easily be avoided. So: is
>>> there a good way to use TR for access to cpointers?
>>> >
>>> > I’ve attached the code in case anyone wants to see it; I don’t really
>>> care about the first call to (time …); it’s appallingly slow (20x slower in
>>> TR), but that’s not the part I’m trying to speed up. It’s the second call
>>> to (time…), around
>>> > the resample call.
>>> >
>>> > John
>>> >
>>> >
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google
>>> Groups "Racket Users" group.
>>> > To unsubscribe from this group and stop receiving emails from it, send
>>> an email to racket-users+unsubscr...@googlegroups.com.
>>> > For more options, visit https://groups.google.com/d/optout.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Racket Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to racket-users+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Phil Nguyen]

(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 (cast _ Positive-Flonum) into (assert
> (assert _ flonum?) positive?) speeds up significantly for me.
>
> On Sun, Sep 17, 2017 at 9:11 PM, Robby Findler <
> ro...@eecs.northwestern.edu> wrote:
>
>> Maybe a first step is to just (unsafely) disable the contract checking
>> in order to see what the upper-limit of the improvement is.
>>
>> Robby
>>
>>
>> On Sun, Sep 17, 2017 at 8:07 PM, 'John Clements' via users-redirect
>>  wrote:
>> > 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
>> interpolating the two points of the old vector nearest to i*(M/N).
>> >
>> > Currently, it takes about 10 seconds to resample 60 seconds of audio,
>> which I believe could be much much better. I bet that TR would help a lot
>> here, but I’ve been poking around, and I don’t see any typed access to
>> s16vectors or cpointers. I’m guessing that importing the ffi/unsafe
>> functions with wrappers would be considerably slower...
>> >
>> > … well, I shouldn’t guess. I should try.
>> >
>> > AAGH! Yep, I was right. it goes 7x slower after naive conversion to TR.
>> I could probably do better by working with the optimization coach, but I’m
>> guessing that interposing the contract boundary on every read and write to
>> the s16vector is a big slowdown that could easily be avoided. So: is there
>> a good way to use TR for access to cpointers?
>> >
>> > I’ve attached the code in case anyone wants to see it; I don’t really
>> care about the first call to (time …); it’s appallingly slow (20x slower in
>> TR), but that’s not the part I’m trying to speed up. It’s the second call
>> to (time…), around
>> > the resample call.
>> >
>> > John
>> >
>> >
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups "Racket Users" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an email to racket-users+unsubscr...@googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Racket Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to racket-users+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Phil Nguyen]

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 step is to just (unsafely) disable the contract checking
> in order to see what the upper-limit of the improvement is.
>
> Robby
>
>
> On Sun, Sep 17, 2017 at 8:07 PM, 'John Clements' via users-redirect
>  wrote:
> > 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
> interpolating the two points of the old vector nearest to i*(M/N).
> >
> > Currently, it takes about 10 seconds to resample 60 seconds of audio,
> which I believe could be much much better. I bet that TR would help a lot
> here, but I’ve been poking around, and I don’t see any typed access to
> s16vectors or cpointers. I’m guessing that importing the ffi/unsafe
> functions with wrappers would be considerably slower...
> >
> > … well, I shouldn’t guess. I should try.
> >
> > AAGH! Yep, I was right. it goes 7x slower after naive conversion to TR.
> I could probably do better by working with the optimization coach, but I’m
> guessing that interposing the contract boundary on every read and write to
> the s16vector is a big slowdown that could easily be avoided. So: is there
> a good way to use TR for access to cpointers?
> >
> > I’ve attached the code in case anyone wants to see it; I don’t really
> care about the first call to (time …); it’s appallingly slow (20x slower in
> TR), but that’s not the part I’m trying to speed up. It’s the second call
> to (time…), around
> > the resample call.
> >
> > John
> >
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Racket Users" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to racket-users+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

['John Clements' via users-redirect]

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 interpolating 
the two points of the old vector nearest to i*(M/N).

Currently, it takes about 10 seconds to resample 60 seconds of audio, which I 
believe could be much much better. I bet that TR would help a lot here, but 
I’ve been poking around, and I don’t see any typed access to s16vectors or 
cpointers. I’m guessing that importing the ffi/unsafe functions with wrappers 
would be considerably slower...

… well, I shouldn’t guess. I should try.

AAGH! Yep, I was right. it goes 7x slower after naive conversion to TR. I could 
probably do better by working with the optimization coach, but I’m guessing 
that interposing the contract boundary on every read and write to the s16vector 
is a big slowdown that could easily be avoided. So: is there a good way to use 
TR for access to cpointers?

I’ve attached the code in case anyone wants to see it; I don’t really care 
about the first call to (time …); it’s appallingly slow (20x slower in TR), but 
that’s not the part I’m trying to speed up. It’s the second call to (time…), 
around
the resample call.

John



-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


check-resample-speed.rkt
Description: Binary data

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

[Matthias Felleisen]

> 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 construction 
> in an intelligent way. This could help a lot for simplifying the kind of 
> picts that are difficult to do purely programmatically.


We have thought of this. We may work on it. 




> On Sep 17, 2017, at 4:58 AM, Gour  wrote:
> 
>> — my use of scribble is restricted to a few papers with PhD students 
>>  and How to Design Programs/2e. 
> 
> Have you served it well for HtDP2e?


Yes, in principle. Even though Scribble is in its infancy compared to 
LaTex/TeX, 
Scribble gets many things right as a PL that LaTeX/TeX got wrong. Plain wrong. 
(Knuth was an amateur when it came to PL.) 

Maintaining source code so that you can target both the Web and a MIT P is 
extremely difficult, however, in both systems. 

If you want to write a long-ish (es. non-technical) piece, consider Pollen. 


> Maybe I should mentioned that I do non-technical presentations…

If you need individualized but similar diagrams and slides, Pict and Slideshow 
are for you. 

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Konrad Hinsen]

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 right moment to invest time into 
learning pict.


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 
construction in an intelligent way. This could help a lot for 
simplifying the kind of picts that are difficult to do purely 
programmatically.


Konrad.

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Konrad Hinsen]

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 trying to work in how to include slides that are Picts, but it's 
still a bit early.


This looks interesting! But it also looks like you are inventing yet 
another lightweight markup language. You do mention Markdown as an 
inspiration, so why not use it fully? There's a Markdown parser ready 
for reuse:


   https://docs.racket-lang.org/markdown/

For slideshow-specific features such as speaker notes, you could copy 
other Markdown-based slideshow tools, e.g. reveal.js.


Konrad.

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Gour]

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
> have to be a pict master. I am trying to work in how to include
> slides that are Picts, but it's still a bit early.

That sound just a s the right tool!

> Naturally, the resultant slideshows are slideshow (the tool)
> compatible, and as a result, allow for speakers notes and handouts to
> be included. 

I'm glad not being the only one thinking that way. ;)

> I hope to have a lot more posted next week, but the
> start of what I'm talking about is at:
> 
> https://github.com/apg/slideshow-simple

I'll certainly take a look!

> Not sure if that meets your needs yet, but hopefully it will soon.

Thanks a lot!

-- 
Everyone is forced to act helplessly according to the qualities
he has acquired from the modes of material nature; therefore no
one can refrain from doing something, not even for a moment.


-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Gour]

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's noob it could take quite some
time to prepare presentations, but it may pay off in the long run.


Sincerely,
Gour

-- 
Not by merely abstaining from work can one achieve freedom
from reaction, nor by renunciation alone can one attain perfection.


-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Gour]

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 the presentation at the same time. 

That's true.

> A paper/handout and a presentation are two completely different ways of
> bringing across intuition and if you connect them, you miss a chance.

I must admit in for most of the presentaions I do, flip-chart is the only tool
I use since I prefer its interactivity and consider it's better for *teaching*.

> In this sense, you’re at an advantage with scribble and slideshow -)
> The bit of disconnect forces you to rethink the presentation. Pict is
> a bit of a connection between the two. 

Thank you - I confess I was not really aware of the pict's existance as
separate package.

>  — my use of scribble is restricted to a few papers with PhD students 
>   and How to Design Programs/2e. 

Have you served it well for HtDP2e?

>  — I do not use slideshow only pict. 

That's interesting, indeed.

Maybe I should mentioned that I do non-technical presentations...


Sincerely,
Gour

-- 
One who is not disturbed in mind even amidst the threefold
miseries or elated when there is happiness, and who is free
from attachment, fear and anger, is called a sage of steady mind.


-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.