Re: [racket-users] Speeding up graphics / moving away from 2htdp/image

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

Re: [racket-users] DrRacket Accessibility with Screen readers

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

[racket-users] DrRacket Accessibility with Screen readers

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

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

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

Re: [racket-users] Proper non-tail recursion?

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

[racket-users] OpenSSL vs. NaCl/libsodium

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

Re: [racket-users] Speeding up graphics / moving away from 2htdp/image

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

Re: [racket-users] Racket v6.9

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

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

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

Re: [racket-users] OpenSSL vs. NaCl/libsodium

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

Re: [racket-users] Speeding up graphics / moving away from 2htdp/image

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

Re: [racket-users] Racket v6.9

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

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

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

Re: [racket-users] Proper non-tail recursion?

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,

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

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

Re: [racket-users] Speeding up graphics / moving away from 2htdp/image

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

Re: [racket-users] Speeding up graphics / moving away from 2htdp/image

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

Re: [racket-users] Speeding up graphics / moving away from 2htdp/image

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

Re: [racket-users] Proper non-tail recursion?

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

Re: [racket-users] Proper non-tail recursion?

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

Re: [racket-users] Proper non-tail recursion?

> 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

Re: [racket-users] Proper non-tail recursion?

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:

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

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

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

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 >