Re: [racket-users] How to improve compile times?

[Alex Harsanyi]

On Friday, April 28, 2017 at 10:04:52 PM UTC+8, Matthew Flatt wrote:
> I notice that your code calls `running-stickman-icon` on startup, which
> takes about 2 seconds on my machine.

Well, this is embarrassing for me.  I remember adding that code in and having 
to decide on whether to wait 2 seconds for the "About" dialog to be ready or to 
compute the value at start up, delaying startup time.  I made a mental note to 
create a PNG image and loading that, but forgot about doing it.   Thanks for 
pointing it out.

Alex.

-- 
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] Speeding up graphics / moving away from 2htdp/image

[WarGrey Gyoudmon Ju]

On Sat, Apr 29, 2017 at 5:21 AM, Daniel Prager 
wrote:

> On Sat, Apr 29, 2017 at 2:10 AM, WarGrey Gyoudmon Ju <
> juzhenli...@gmail.com> wrote:
>
>> Hello, I think the main reason that pict is faster than 2htdp/image is,
>> the pict is implemented with struct while the 2htdp/image is implemented
>> with class, the speed of rendering is just as fast/slow as each other, but
>> manipulation on class is much heavier than on struct when combining large
>> numbers of shapes. Maybe you want to check the code of `table` in pict-lib,
>> it is a good example to place shapes into grids in a functional way.
>>
>
> Interesting. I'd also note that unlike pict 2htdp/image doesn't provide a
> way to draw direct to dc, necessitating going via bitmaps when using it in
> conjunction with racket/gui.
>

Actually, this is not the case, every 2htdp/image shape is a subclass of
snip%(see the `draw` method of snip%), though you have to compute another 9
arguments...

I remembered some points that old conversations had suggested:
1. 2htdp/image is not efficient enough for building real world gui
application, racket/draw should be used instead.
2. When drawing large amount of shapes, the cost of getting into and out
the drawing context is critical.
3. typed racket is helpful even for real time rendering, say, perlin noise,
almost as fast as java, (but I did not see the direct link between your
work and real time rendering.)

Good luck 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] Racket v6.9

[tuxic]

Hi Vincent,

It was a layer eight error...(mine).

It seems that answering "Yes" to ""/usr/local/racket" exists, delete?"
means "No" and a simple "y" removes the old installation (guessed).
The old installation was still in place.

I fied that and now the brand new racket is the brand new racket.

:)

Sorry for the wrong red alert...

Cheers
Meino



On 04/28 02:59, Vincent St-Amour wrote:
> Hi Meino,
> 
> I can't reproduce this on either Mac OS or Linux.
> 
> Are you sure you have the right Racket in your path?
> 
> Vincent
> 
> 
> 
> On Thu, 27 Apr 2017 22:14:44 -0500,
> tu...@posteo.de wrote:
> > 
> > Hi,
> > 
> > ...it looks like, that the REPL still states to be
> > verion 6.8 of racket ?
> > (x86_84/Linux)
> > 
> > Cheers
> > Meino
> > 
> > 
> > On 04/27 03:47, Vincent St-Amour wrote:
> > > Racket version 6.9 is now available from
> > > 
> > > http://racket-lang.org/
> > > 
> > > ---
> > > 
> > > Security Announcement:
> > > 
> > > A security vulnerability in the `racket/sandbox` library and Typed
> > > Racket allowed malicious Typed Racket code to escape the sandbox.
> > > This vulnerability has been fixed in Racket version 6.9. Anyone using
> > > `racket/sandbox` to execute untrustworthy code with access to Typed
> > > Racket should upgrade to version 6.9 immediately.
> > > 
> > > While this known vulnerability has been eliminated, it is possible that
> > > similar errors in other installed collections could also be exploited,
> > > although we are not currently aware of any existing vulnerabilities. We
> > > recommend that if you use the Racket sandbox to execute untrustworthy
> > > Racket code, you should also employ additional operating system or
> > > virtual machine level protections. The documentation for `racket/sandbox`
> > > has been updated to list recommended security practices for using the
> > > library.
> > > 
> > > Thanks to Scott Moore for identifying this vulnerability.
> > > 
> > > ---
> > > 
> > > - The official package catalog Web site is revised to have a new user
> > >   experience.
> > > 
> > > - The Northwestern snapshot site keeps weekly snapshots going up to 12
> > >   weeks into the past. Those provide a middle ground for users who want
> > >   access to new features earlier than stable releases, but want less
> > >   churn than nightly builds.
> > > 
> > > - DrRacket provides a refactoring tool to remove unused requires in
> > >   modules.
> > > 
> > > - DrRacket's #lang-line customization support works better with buggy
> > >   (i.e., in development) languages.
> > > 
> > > - The web server's cookie libraries, including "id cookie" authentication,
> > >   support RFC 6265.
> > > 
> > > - The `db` library supports PostgreSQL's UUID type.
> > > 
> > > - The `raco` command lists matching commands when passed an ambiguous
> > >   command prefix.
> > > 
> > > - The bytecode compiler detects more optimization opportunities for
> > >   structure operations.
> > > 
> > > - Scribble can produce output via XeLaTeX as an alternative to LaTeX.
> > > 
> > > - Scribble supports the `acmart` LaTeX style, for use with ACM
> > >   publications.
> > > 
> > > - Scribble supports the use of CJK characters in tags.
> > > 
> > > ---
> > > 
> > > The following people contributed to this release:
> > > Alex Knauth, Alexander Shopov, Alexis King, Andrew Kent, Asumu Takikawa,
> > > Ben Greenman, Daniel Feltey, David Van Horn, Georges Dupéron, Greg
> > > Hendershott, Gustavo Massaccesi, Ingo Blechschmidt, James Bornholt,
> > > James Whang, Jay McCarthy, Jeff Shelley, John Clements, Jordan Johnson,
> > > Leandro Facchinetti, Leif Andersen, Marc Burns, Matthew Butterick,
> > > Matthew Eric Bassett, Matthew Flatt, Matthias Felleisen, Michael Myers,
> > > Mike Sperber, Philip McGrath, Philippe Meunier, Robby Findler, Royall
> > > Spence, Ryan Culpepper, Sam Caldwell, Sam Tobin-Hochstadt, Shu-Hung You,
> > > Spencer Florence, Stephen Chang, Tony Garnock-Jones, Vincent St-Amour,
> > > WarGrey Gyoudmon Ju, Wei Tang, and William G Hatch.
> > > 
> > > Feedback Welcome
> > > 
> > > -- 
> > > 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] Speeding up graphics / moving away from 2htdp/image

[Daniel Prager]

On Sat, Apr 29, 2017 at 2:10 AM, WarGrey Gyoudmon Ju 
wrote:

> Hello, I think the main reason that pict is faster than 2htdp/image is,
> the pict is implemented with struct while the 2htdp/image is implemented
> with class, the speed of rendering is just as fast/slow as each other, but
> manipulation on class is much heavier than on struct when combining large
> numbers of shapes. Maybe you want to check the code of `table` in pict-lib,
> it is a good example to place shapes into grids in a functional way.
>

Interesting. I'd also note that unlike pict 2htdp/image doesn't provide a
way to draw direct to dc, necessitating going via bitmaps when using it in
conjunction with racket/gui.


> I tested your example with my functional bitmap APIs (with arguments
> memorized, and it only creates one bitmap% when combining a list of
> shapes), as expected it is too slow(<3s, without memorizing it's <6s) to
> stand with, but it also indicates that half or less time used is not
> creating or drawing single primitive shapes, but every primitive shape is
> rendered duplicately whenever its combining shape is rendering. So the
> issue is, to find a strategy to call `freeze` at a reasonable level of
> combined shapes.
>

My thinking has been to strip back to simpler strategies initially to see
how much speed is possible, then apply freezing and caching strategies
later, if applicable. (Something, something "premature optimization ...
evil" ;-)


>
> One reason that you may have to write your own combiner(here the term
> should be "layout") is, `freeze` can make a big shape, but it cannot avoid
> the duplicate rendering since it actually do the drawing. So your combiner
> would focus on providing the position and size information for dc to `draw`
> or `copy` and/or `rotate/flip`. Sounds hard to do it with fewer bugs.
>

Before resorting to writing my own combiner / layout I think I'll see what
performance I can get from a custom "block" pict. From the pict library's
POV this would reduce the number of picts in my examples from 1000s to 1.

Thanks

Dan

-- 
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] OpenSSL vs. NaCl/libsodium

[Tony Garnock-Jones]

Hi James,

On 4/28/17 1:13 PM, James wrote:
> https://github.com/mgorlick/CRESTaceans/tree/master/bindings/libsodium
> https://github.com/tonyg/racl/tree/master

I'm the author of racl. I've not used mgorlick's code, but one thing to
bear in mind is that it uses libsodium, where racl uses plain NaCl.
Libsodium is definitely the way to go - plain NaCl is largely vestigial
at this point.

If I were to use racl in production, I would change the implementation
of racl to use libsodium instead of NaCl.

Racl includes a few useful utilities (like SPKI SEXP I/O and some hacky
sketches of encrypted TCP ports based on NaCl primitives), where
mgorlick's code looks to be just the NaCl primitives.

mgorlick's code has contracts; mine does not, which is a shame. I should
add some.

Finally, neither NaCl nor libsodium nor racl provides anything TLS-like.
If you wanted some kind of streaming network code on top of NaCl, you're
firmly in "roll-your-own crypto" territory.

Cheers,
  Tony

-- 
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] Racket v6.9

[Vincent St-Amour]

Hi Meino,

I can't reproduce this on either Mac OS or Linux.

Are you sure you have the right Racket in your path?

Vincent



On Thu, 27 Apr 2017 22:14:44 -0500,
tu...@posteo.de wrote:
> 
> Hi,
> 
> ...it looks like, that the REPL still states to be
> verion 6.8 of racket ?
> (x86_84/Linux)
> 
> Cheers
> Meino
> 
> 
> On 04/27 03:47, Vincent St-Amour wrote:
> > Racket version 6.9 is now available from
> > 
> > http://racket-lang.org/
> > 
> > ---
> > 
> > Security Announcement:
> > 
> > A security vulnerability in the `racket/sandbox` library and Typed
> > Racket allowed malicious Typed Racket code to escape the sandbox.
> > This vulnerability has been fixed in Racket version 6.9. Anyone using
> > `racket/sandbox` to execute untrustworthy code with access to Typed
> > Racket should upgrade to version 6.9 immediately.
> > 
> > While this known vulnerability has been eliminated, it is possible that
> > similar errors in other installed collections could also be exploited,
> > although we are not currently aware of any existing vulnerabilities. We
> > recommend that if you use the Racket sandbox to execute untrustworthy
> > Racket code, you should also employ additional operating system or
> > virtual machine level protections. The documentation for `racket/sandbox`
> > has been updated to list recommended security practices for using the
> > library.
> > 
> > Thanks to Scott Moore for identifying this vulnerability.
> > 
> > ---
> > 
> > - The official package catalog Web site is revised to have a new user
> >   experience.
> > 
> > - The Northwestern snapshot site keeps weekly snapshots going up to 12
> >   weeks into the past. Those provide a middle ground for users who want
> >   access to new features earlier than stable releases, but want less
> >   churn than nightly builds.
> > 
> > - DrRacket provides a refactoring tool to remove unused requires in
> >   modules.
> > 
> > - DrRacket's #lang-line customization support works better with buggy
> >   (i.e., in development) languages.
> > 
> > - The web server's cookie libraries, including "id cookie" authentication,
> >   support RFC 6265.
> > 
> > - The `db` library supports PostgreSQL's UUID type.
> > 
> > - The `raco` command lists matching commands when passed an ambiguous
> >   command prefix.
> > 
> > - The bytecode compiler detects more optimization opportunities for
> >   structure operations.
> > 
> > - Scribble can produce output via XeLaTeX as an alternative to LaTeX.
> > 
> > - Scribble supports the `acmart` LaTeX style, for use with ACM
> >   publications.
> > 
> > - Scribble supports the use of CJK characters in tags.
> > 
> > ---
> > 
> > The following people contributed to this release:
> > Alex Knauth, Alexander Shopov, Alexis King, Andrew Kent, Asumu Takikawa,
> > Ben Greenman, Daniel Feltey, David Van Horn, Georges Dupéron, Greg
> > Hendershott, Gustavo Massaccesi, Ingo Blechschmidt, James Bornholt,
> > James Whang, Jay McCarthy, Jeff Shelley, John Clements, Jordan Johnson,
> > Leandro Facchinetti, Leif Andersen, Marc Burns, Matthew Butterick,
> > Matthew Eric Bassett, Matthew Flatt, Matthias Felleisen, Michael Myers,
> > Mike Sperber, Philip McGrath, Philippe Meunier, Robby Findler, Royall
> > Spence, Ryan Culpepper, Sam Caldwell, Sam Tobin-Hochstadt, Shu-Hung You,
> > Spencer Florence, Stephen Chang, Tony Garnock-Jones, Vincent St-Amour,
> > WarGrey Gyoudmon Ju, Wei Tang, and William G Hatch.
> > 
> > Feedback Welcome
> > 
> > -- 
> > 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] DrRacket Accessibility with Screen readers

[Leif Andersen]

Hello Erika.

I have low vision and have had better luck using screen magnifiers
with DrRacket than screen readers. With that being said, I honestly
don't have much experience with JAWS. Although I take it that means
you do want to use Windows screen readers with DrRacket, is this
correct?

~Leif Andersen


On Fri, Apr 28, 2017 at 1:07 PM, Erika Thompson
 wrote:
> We're using DrRacket in an online course on edX, How to Code. We've had a 
> student enquire about using a screen reader with DrRacket. Does anyone know 
> anything about DrRacket's compatibility with screen readers, such as Jaws. 
> Thanks so much
>
> --
> 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] Re: How to improve compile times?

[Dan Liebgold]

Is all your code (and the racket distro) on a local SSD? We've found that 
file/network IO during startup and require can certainly impact performance.

-- 
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] OpenSSL vs. NaCl/libsodium

[James]

I am researching options for a major project which needs various cryptography 
functions.  We want to implement TLS with ourselves as the only certificate 
authority, establish a web of trust, and also encrypt and sign individual 
files.  I see that there is an OpenSSL module in Racket so that's an option.  I 
thought I saw an NaCl module a while back but now I can't find it. Maybe I'm 
mistaken.  What I did find was two different projects on Github which provide 
language bindings for Racket to libsodium.  Neither have much documentation so 
I am wondering if they are ready for a major project and if so, which one 
should I use?

They are:
https://github.com/mgorlick/CRESTaceans/tree/master/bindings/libsodium
https://github.com/tonyg/racl/tree/master

I also see references to another one called natrium but there are only broken 
links.  

James

-- 
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] DrRacket Accessibility with Screen readers

[Erika Thompson]

We're using DrRacket in an online course on edX, How to Code. We've had a 
student enquire about using a screen reader with DrRacket. Does anyone know 
anything about DrRacket's compatibility with screen readers, such as Jaws. 
Thanks so much 

-- 
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] Proper non-tail recursion?

[Daniel Bastos]

On Fri, Apr 28, 2017 at 12:29 PM, Matthias Felleisen
 wrote:
>> On Apr 28, 2017, at 11:12 AM, Ben Greenman  
>> wrote:
>>
>> On Fri, Apr 28, 2017 at 11:08 AM, Daniel Bastos  wrote:
>> interview done with Guido van Rossum
>>
>> http://neopythonic.blogspot.com/2009/04/tail-recursion-elimination.html
>
> Guys, this conversation is really not about PITCH per se.

Thanks for pointing that out.  I failed to recognize the subject was
beyond my knowledge, so I totally misunderstood everything.  Thank
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] Speeding up graphics / moving away from 2htdp/image

[WarGrey Gyoudmon Ju]

Hello, I think the main reason that pict is faster than 2htdp/image is, the
pict is implemented with struct while the 2htdp/image is implemented with
class, the speed of rendering is just as fast/slow as each other, but
manipulation on class is much heavier than on struct when combining large
numbers of shapes. Maybe you want to check the code of `table` in pict-lib,
it is a good example to place shapes into grids in a functional way.

I tested your example with my functional bitmap APIs (with arguments
memorized, and it only creates one bitmap% when combining a list of
shapes), as expected it is too slow(<3s, without memorizing it's <6s) to
stand with, but it also indicates that half or less time used is not
creating or drawing single primitive shapes, but every primitive shape is
rendered duplicately whenever its combining shape is rendering. So the
issue is, to find a strategy to call `freeze` at a reasonable level of
combined shapes.

One reason that you may have to write your own combiner(here the term
should be "layout") is, `freeze` can make a big shape, but it cannot avoid
the duplicate rendering since it actually do the drawing. So your combiner
would focus on providing the position and size information for dc to `draw`
or `copy` and/or `rotate/flip`. Sounds hard to do it with fewer bugs.

On Fri, Apr 28, 2017 at 9:32 PM, Daniel Prager 
wrote:

> Thanks Hendrik & Alex
>
> Hendrik:
>
> What you're suggesting sounds to me a lot like what the pict library
> already does. Switching to pict would seem to give a good speed-up, but
> perhaps it's possible to do better. Hence the benchmarking exercise.
>
> Perhaps make a closure that, when called, does the rendering to dc,
>> and treat the closure as a representation for the image?  Then let the
>> image and pict combiners operate on the closures to produce more
>> closures?
>
>
>
> Alex:
>
> I'm using rendering to a bitmap% in the case of the pict library as a
> proxy for direct rendering to a dc. I would certainly  render directly if I
> were to switch to pict.
>
> Timings vary on the actual layout in Quilt Explorer, depending on block
> complexity. The 18 blocks at the bottom of the page are choices in block
> layout / shading or color that the user can click on — that's the
> "exploring" part.
>
> A "next level" improvement might be something similar to the "virtual dom"
> pioneered (or at least popularised) by the react-js folk, to simplify and
> reduce the cost of re-rendering.
>
> Dan
>
>
>
>
> On Fri, Apr 28, 2017 at 11:05 PM, Alex Harsanyi 
> wrote:
>
>> On Friday, April 28, 2017 at 6:40:06 PM UTC+8, Daniel Prager wrote:
>>
>> > The reason is that what I really want to do is more complex layouts,
>> for which 2htdp/image or pict combiners make life a lot easier.
>>
>> The code to convert to bitmap allocates the bitmap and draws to the
>> bitmap.  In the actual application you can draw directly to the canvas DC
>> in the on-paint method, which would save a bitmap allocation and an
>> intermediate draw step.
>>
>> >
>> > Some work-in-progress ...
>> >
>> > The idea of Quilt Explorer is to use symmetry and randomness, combined
>> with some user selection to create original quilt designs.
>>
>> looking at these designs, I think by the time you're done writing code
>> that draws directly to a dc, the code will be just as slow as the pict
>> code, and probably with more bugs.
>>
>> Also, it seems you are rendering about 20 designs on the page.
>>
>> How long does it take to render an actual quilt design?
>>
>> Best Regards,
>> Alex.
>
> --
> 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] Proper non-tail recursion?

[Ben Greenman]

Right ... it's about "growable stack languages" or "infinite stack
languages" or "heapful languages" or something like that.

On Fri, Apr 28, 2017 at 11:29 AM, Matthias Felleisen 
wrote:

>
> > On Apr 28, 2017, at 11:12 AM, Ben Greenman 
> wrote:
> >
> >
> > On Fri, Apr 28, 2017 at 11:08 AM, Daniel Bastos 
> wrote:
> > interview done with Guido van Rossum
> >
> > http://neopythonic.blogspot.com/2009/04/tail-recursion-elimination.html
>
>
> Guys, this conversation is really not about PITCH per se.

-- 
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] Proper non-tail recursion?

[Matthias Felleisen]

> On Apr 28, 2017, at 11:12 AM, Ben Greenman  
> wrote:
> 
> 
> On Fri, Apr 28, 2017 at 11:08 AM, Daniel Bastos  wrote:
> interview done with Guido van Rossum
> 
> http://neopythonic.blogspot.com/2009/04/tail-recursion-elimination.html


Guys, this conversation is really not about PITCH per se. 

-- 
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] Proper non-tail recursion?

[Ben Greenman]

On Fri, Apr 28, 2017 at 11:08 AM, Daniel Bastos  wrote:

> interview done with Guido van Rossum


http://neopythonic.blogspot.com/2009/04/tail-recursion-elimination.html


Related:

lexical scope is interesting *theoretically*, but its inefficient to
> implement; dynamic scope is the fast choice


 http://www.paulgraham.com/thist.html

-- 
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] Proper non-tail recursion?

[Daniel Bastos]

On Fri, Apr 28, 2017 at 11:19 AM, Matthias Felleisen
 wrote:
> [...] Their implementors will argue that deep recursions don’t exist or 
> shouldn’t be supported. [...]

Python's argument for not supporting tail-call optimization (if I
should call it that way after this thread) is that it makes it fail to
produce an informative ``Traceback''.   That's what I remember from an
interview done with Guido van Rossum.  (I don't recall any other
reasons.)

-- 
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] Proper non-tail recursion?

[Matthias Felleisen]

As some have pointed out downstream from here, SML is definitely a language 
that does it (but see Appel’s articles on why stacks are superfluous from years 
ago and weep). 

I suspect that all faithful Scheme implementations get close or satisfy this 
property. 

But as others have mentioned, many languages fail this property. Their 
implementors will argue that deep recursions don’t exist or shouldn’t be 
supported. Sadly, this is even true for languages that support call/cc or 
similar control operators, with which you could easily achieve this (through 
internal uses). And when I read their arguments, I recall the tales of my first 
programming course which told us of IBM’s objections to Algol because it 
dynamically allocated memory (on the stack) and how inefficient this would be, 
and that Algol 60 had to be stopped etc. It reminds me of C++’s limits on 
template expansions. It was 7 or 8, it might be 20 now. It reminds me of 
Scala’s prelude which defines the function class for up to 5, 8, 22 arguments. 

When will we learn and implement the elegant solution so that we can strive for 
good performance for it? 





> On Apr 27, 2017, at 7:01 PM, brendan  wrote:
> 
> Dr. Felleisen,
> 
> Thanks for the informative response. Is Racket the only language with 
> unbounded recursion depth as far as you know? And with respect to 
> implementation, can you explain the role of the one extra bit that you 
> mention?
> 
> A number of functional languages targeting platforms like the JVM and 
> browsers are compromised by the lack of proper tail calls. I often wonder how 
> much of a performance penalty you would have to pay if those languages were 
> implemented by CPS-transforming the whole program and running on a 
> trampoline, except where the compiler could prove constant-bounded call depth.
> 
> On Tuesday, April 25, 2017 at 9:09:10 PM UTC-4, Matthias Felleisen wrote:
>> Brendan, 
>> 
>> you’re correct in attributing the idea that the proper implementation of 
>> tail calls is far less important to the Scheme and Racket community. Dybvig 
>> expressed this idea first in a talk titled a Bag of Hacks in the early 90s. 
>> Matthew then at some point said that the true goal is to never run out of 
>> stack space (other than run out of memory period); once we have that proper 
>> tail-call implementation might just be of secondary value. 
>> 
>> As for terminology, I think I would say that a language ought to support 
>> ‘unbounded recursion depth’. Unwieldy name. 
>> 
>> How is it implemented? When a call is about to exhaust the available stack 
>> space, grab the stack, move it into the heap, start a new one with a frame 
>> that links to the moved stack. If you now also want to implement 
>> continuation-grabing control operators (call/cc, C, F, prompt, etc) you can 
>> do so with one extra bit per stack frame and lazy copying of heap-moved 
>> stacks to the stack proper. 
>> 
>> While I am at it, let me advocate PITCH as the slogan for Proper 
>> Implementation of Tail Calls. (Where does the H come from? I added it to 
>> make a complete word.) What many people fail to see is that every language 
>> with function calls has tail positions. The syntax may obscure those with 
>> various superfluous keywords but that does not invalidate the idea. A 
>> tail-call position is a ‘return’ place in a function body. Period. So when 
>> people say “we implement tail calls”, it’s basically nonsense because every 
>> language with function calls must implement tail calls. The question is 
>> whether the evaluation of arguments or the evaluation of function calls 
>> consumes space. And if you love OO design patterns — which is where Scheme 
>> comes from — you must opt into the former not the latter, which means you 
>> must implement tail calls properly. 
>> 
>> — Matthias
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> On Apr 25, 2017, at 7:32 PM, brendan  wrote:
>>> 
>>> Good points: It wasn't strictly true to say that you can make non-tail 
>>> calls "without fear." Rather, your memory for continuation frames is shared 
>>> with, and just as large as, any other kind of data.
>>> 
>>> -- 
>>> 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] How to improve compile times?

[Matthew Flatt]

At Thu, 27 Apr 2017 23:07:01 -0700 (PDT), Alex Harsanyi wrote:
> > * The size of the bytecode does matter (and switching to Chez scheme's 
> run-time could hopefully improve that)
> 
> All the .zo files put together are about 4Mb.  I'm not sure if this is big or 
> not?

4MB is not big. But your program pulls in `framework`, `plot`, and
`math` (which is used by `plot`, anyway), which all have to be loaded
and involve lots of bytecode.

> What I'm wondering is if class definition actually runs some code when a 
> module is required, like the code below:
> 
> (define my-class% 
>(class object% (init) (super-new)
>   (define/public (say-hello) (printf "hello~%"

Yes, constructing the class does take some work, but it's unlikely to
be a noticeable amount of work.

I notice that your code calls `running-stickman-icon` on startup, which
takes about 2 seconds on my machine. Meanwhile, just loading
`plot`+`math`+`framework` takes about 2.5 seconds. Maybe there are some
other slow-to-load libraries, and then maybe improving code-loading
times in Racket will help for your application.

-- 
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] How to improve compile times?

[Matthew Flatt]

At Thu, 27 Apr 2017 11:47:41 -0700 (PDT), Dupéron Georges wrote:
> If I understand correctly, [...]

Yes, that all looks right.

> It would be nice to find a way to detect what code gets executed when
> a module is required, at the various meta-levels. Maybe running raco
> cover on an empty file containing only (require some-module) could
> help?

Yes, that sounds helpful. The module loader should log events about
module loading an instantiation at various phases, and then a tool
could put that information in a readable format. I'll add that to my
"to do" list for the new expander.

> I'm not sure how submodules fit in this picture (the main concerns being the 
> test submodule, and the doc submodule for literate programs).

Submodules differ from top-level modules only in that compiling a
module from source implies compiling its submodules, even if you do not
run the submodules. In compiled form, however, submodule bytecode is
loaded or not independent of other modules, so the existence of a
`test` or `doc` submodule does not affect the time required to load the
enclosing module by itself.

-- 
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] Speeding up graphics / moving away from 2htdp/image

[Daniel Prager]

Thanks Hendrik & Alex

Hendrik:

What you're suggesting sounds to me a lot like what the pict library
already does. Switching to pict would seem to give a good speed-up, but
perhaps it's possible to do better. Hence the benchmarking exercise.

Perhaps make a closure that, when called, does the rendering to dc,
> and treat the closure as a representation for the image?  Then let the
> image and pict combiners operate on the closures to produce more
> closures?



Alex:

I'm using rendering to a bitmap% in the case of the pict library as a proxy
for direct rendering to a dc. I would certainly  render directly if I were
to switch to pict.

Timings vary on the actual layout in Quilt Explorer, depending on block
complexity. The 18 blocks at the bottom of the page are choices in block
layout / shading or color that the user can click on — that's the
"exploring" part.

A "next level" improvement might be something similar to the "virtual dom"
pioneered (or at least popularised) by the react-js folk, to simplify and
reduce the cost of re-rendering.

Dan



On Fri, Apr 28, 2017 at 11:05 PM, Alex Harsanyi 
wrote:

> On Friday, April 28, 2017 at 6:40:06 PM UTC+8, Daniel Prager wrote:
>
> > The reason is that what I really want to do is more complex layouts, for
> which 2htdp/image or pict combiners make life a lot easier.
>
> The code to convert to bitmap allocates the bitmap and draws to the
> bitmap.  In the actual application you can draw directly to the canvas DC
> in the on-paint method, which would save a bitmap allocation and an
> intermediate draw step.
>
> >
> > Some work-in-progress ...
> >
> > The idea of Quilt Explorer is to use symmetry and randomness, combined
> with some user selection to create original quilt designs.
>
> looking at these designs, I think by the time you're done writing code
> that draws directly to a dc, the code will be just as slow as the pict
> code, and probably with more bugs.
>
> Also, it seems you are rendering about 20 designs on the page.
>
> How long does it take to render an actual quilt design?
>
> Best Regards,
> Alex.

-- 
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] Speeding up graphics / moving away from 2htdp/image

[Alex Harsanyi]

On Friday, April 28, 2017 at 6:40:06 PM UTC+8, Daniel Prager wrote:

> The reason is that what I really want to do is more complex layouts, for 
> which 2htdp/image or pict combiners make life a lot easier.

The code to convert to bitmap allocates the bitmap and draws to the bitmap.  In 
the actual application you can draw directly to the canvas DC in the on-paint 
method, which would save a bitmap allocation and an intermediate draw step.

> 
> Some work-in-progress ...
> 
> The idea of Quilt Explorer is to use symmetry and randomness, combined with 
> some user selection to create original quilt designs.

looking at these designs, I think by the time you're done writing code that 
draws directly to a dc, the code will be just as slow as the pict code, and 
probably with more bugs.

Also, it seems you are rendering about 20 designs on the page.

How long does it take to render an actual quilt design?

Best Regards,
Alex.

-- 
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] Speeding up graphics / moving away from 2htdp/image

[Hendrik Boom]

On Fri, Apr 28, 2017 at 08:39:33PM +1000, Daniel Prager wrote:
> 
> Now, you may be wondering why I want to keep using 2htdp/image if I already
> have code to directly draw to dc
> 
> The reason is that what I really want to do is more complex layouts, for
> which 2htdp/image or pict combiners make life a lot easier.

Perhaps make a closure that, when called, does the rendering to dc, 
and treat the closure as a representation for the image?  Then let the 
image and pict combiners operate on the closures to produce more 
closures?

You do have a functional language to work with.  You can use it as 
such.

-- hendrik

-- 
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] How to improve compile times?

[Dupéron Georges]

> > * Alex Harsanyi's start-up time is due to run-time (phase 0) initialisation 
> > code in the required libraries, including things like (define v 
> > costly-expression), which look like they could be saved as constants, but 
> > actually involve running the expression.
> 
> I actively try to avoid this case and I believe the program has little or no 
> such code anymore.  However, even when I removed such cases, it did not seem 
> to make much difference.  Racket code actually runs fast.

Just a quick clarification: I meant that such initialisation code may be 
present in the libraries that you require, not in your own code (and so you do 
not have much control over this, unless you start modifying the libraries).

> > * If Alex Harsanyi's code uses dynamic-require or eval, the phase 1 
> > initialisation code of the required libraries is executed when eval or 
> > dynamic-require are first invoked.
> 
> The code does not use any of those things.  Also, apart from 3 macros dealing 
> with baking in some API KEYS at compile time, there are no uses of 
> `define-syntax` and friends.

Again, there could be some use of eval within library code, or in code 
generated by library macros, even if there is no direct use of eval in your 
code.

Nice application, by the way :)

-- 
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] How to improve compile times?

[Alex Harsanyi]

On Friday, April 28, 2017 at 2:47:41 AM UTC+8, Dupéron Georges wrote:
> Thank you Matthew for the explanation.
> 
> If I understand correctly,
> 
> * Alex Harsanyi's start-up time is due to run-time (phase 0) initialisation 
> code in the required libraries, including things like (define v 
> costly-expression), which look like they could be saved as constants, but 
> actually involve running the expression.
> 

I actively try to avoid this case and I believe the program has little or no 
such code anymore.  However, even when I removed such cases, it did not seem to 
make much difference.  Racket code actually runs fast.

> * If Alex Harsanyi's code uses dynamic-require or eval, the phase 1 
> initialisation code of the required libraries is executed when eval or 
> dynamic-require are first invoked.

The code does not use any of those things.  Also, apart from 3 macros dealing 
with baking in some API KEYS at compile time, there are no uses of 
`define-syntax` and friends.

> * The size of the bytecode does matter (and switching to Chez scheme's 
> run-time could hopefully improve that)

All the .zo files put together are about 4Mb.  I'm not sure if this is big or 
not?

What I'm wondering is if class definition actually runs some code when a module 
is required, like the code below:

(define my-class% 
   (class object% (init) (super-new)
  (define/public (say-hello) (printf "hello~%"


In the end, the start up time does not bother me too much, as it is a GUI 
application and I spend a lot of time using it after starting it up, so the 7 
second wait is acceptable. I have other, more interesting, application features 
to work on anyway :-)

If anyone wants to look at the startup time, or help out with any other 
development, here is the application:

https://github.com/alex-hhh/ActivityLog2

Best Regards,
Alex.

-- 
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.