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

[James]

On Apr 28, 2017, at 5:03 PM, Tony Garnock-Jones wrote:

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

Thanks that's really helpful.  I had heard that libsodium was the way to go but 
I'm just now reading about the details.

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

I think we want standard TLS.  I know enough about cryptography to know that I 
really don't want to roll my own.  So I guess OpenSSL is what we'll use but 
then, maybe, something else for local file cryptography and signing.  We might 
even use OpenPGP as a helper application.


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.

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

[James]

Thanks Neil.  I'm aware of the problem of implementation issues, in general, 
but I am new to Racket.  So, if I understand correctly, this would argue for 
using the OpenSSL Racket module for TLS.  I think that's the most sensitive 
part, in terms of C/C++ bugs and failures, since it's network facing.  

James

On Apr 28, 2017, at 1:37 PM, Neil Van Dyke wrote:

> I always look at tonyg's work first.
> 
> Aside: I try to keep uses of third-party crypto code as simple and minimal as 
> possible.  We know crypto implementations are complex, and defect-prone.  And 
> any party in the chain of the software architecture or provenance can 
> introduce a vulnerability (e.g., Debian breaking SSL when they were only 
> supposed to be compiling and packaging upstream code).  One thing I've done 
> in the past, when appropriate, is to isolate crypto libraries to separate 
> processes, and use variations on Racket `system` to call them.  This at least 
> keeps C/C++ bugs from being able to exploit or corrupt anything in the Racket 
> process, and also usually makes any failures in the running C/C++ code 
> short-lived
> 
> 
> James wrote on 04/28/2017 01:13 PM:
>> 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] #lang languages and cyclic dependencies

[Philip McGrath]

I'm working on a #lang for configuration files for a larger project I'm
working on, and I'm trying to find a setup that meets my (largely cosmetic)
goals without producing a "standard-module-name-resolver: cycle in loading"
error.

Given the following directory structure:

   - my-project/
  - config.rkt
  - config/
 - local.rkt
 - production.rkt

I would like both to write "local.rkt" and "production.rkt" in "#lang
my-project/config" and to have "(require my-project/config)" provide
bindings re-exported from "local.rkt" and "production.rkt" and some extra
bindings for working with those values.

This seems like it should be doable, because there aren't any logical
cyclic dependencies, but I haven't found a way to convince Racket of that.

I initially tried making a "my-project/config/lang/" directory with a
"module-lang.rkt" and a "reader.rkt" consisting of "(module reader
syntax/module-reader my-project/config/lang/module-language)", then having
"config.rkt" require and re-export "local.rkt", "production.rkt", and the
appropriate exports of "module-lang.rkt", but this gave me a "cycle in
loading" error.

My first guess was that the problem might be that Racket was looking for a
reader submodule of "config.rkt", so I re-wrote "module-lang.rkt" and
"reader.rkt" as submodules of "config.rkt" (with "module", not "module*" or
"module+"), but this didn't solve the problem.

Is there a way to do what I want?

-Philip

-- 
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] DR + light syntax layer + quickcheck

['John Clements' via Racket Users]

If someone hasn’t already done this, I’ve got a few CS Ed papers for sure….

I’m looking at Python now, but this should be much easier in Racket: I’d like 
to put together a simple syntax for unenforced data definitions and signatures, 
then use instructor help to map these to course-specific quickcheck modules, 
allowing students to easily find input values on which their functions produce 
the wrong (i.e., not matching signature) kinds of values, even for functions 
that aren’t specifically described by instructors.

Has someone done it already? I found “Hypothesis” for Python, which looks 
quickcheck-like but doesn’t use PEP 484. I don’t know of anything like this in 
the Racket world, where it should literally be the work of a weekend. I see how 
it could be seen to undercut test case generation, except that (by generating 
only inputs) it could also *simplify* the task of specifying test cases.

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.

Re: [racket-users] DrRacket preferences error

[Robby Findler]

I've thought about this a little bit and I don't think that a simple
fix is forthcoming, so I've disabled the offending code for now and
hope to return to this another time.

The preferences dialog should now work for git-based builds (and
assuming all goes well with the snapshots tonight, the snapshot builds
tomorro).

Robby


On Sat, Apr 29, 2017 at 6:40 PM, Robby Findler
 wrote:
> This bug was introduced in 6.9 (but it was in git since a little before
> 6.8). I learned about it today, sadly.
>
> Robby
>
> On Sat, Apr 29, 2017 at 6:30 PM 'John Clements' via Racket Users
>  wrote:
>>
>>
>> > On Apr 29, 2017, at 11:36, Philip McGrath 
>> > wrote:
>> >
>> > After upgrading to 6.9, I'm getting the following "DrRacket Internal
>> > Error" when I try to open the preferences menu on MacOS:
>> >
>> > preferences:get: tried to get a preference but no default set for
>> > 'scribble-reindent-paragraph-width
>> >   context...:
>> >/Applications/Racket
>> > v6.9/share/pkgs/gui-lib/framework/preferences.rkt:93:0: preferences:get
>> >/Applications/Racket
>> > v6.9/collects/racket/contract/private/arrow-val-first.rkt:357:18
>> >/Applications/Racket
>> > v6.9/share/pkgs/gui-lib/scribble/private/indentation.rkt:15:1
>> >/Applications/Racket
>> > v6.9/collects/racket/contract/private/arrow-higher-order.rkt:342:33
>> >/Applications/Racket
>> > v6.9/share/pkgs/gui-lib/framework/private/preferences.rkt:390:5
>> >/Applications/Racket
>> > v6.9/share/pkgs/gui-lib/framework/private/preferences.rkt:289:14:
>> > build-ppanel-tree
>> >/Applications/Racket
>> > v6.9/share/pkgs/gui-lib/framework/private/preferences.rkt:261:2:
>> > make-preferences-dialog
>> >/Applications/Racket
>> > v6.9/share/pkgs/gui-lib/framework/private/preferences.rkt:243:2: 
>> > show-dialog
>> >/Applications/Racket
>> > v6.9/share/pkgs/gui-lib/mred/private/app.rkt:67:21
>> >/Applications/Racket
>> > v6.9/share/pkgs/gui-lib/mred/private/wx/common/queue.rkt:454:6
>> >/Applications/Racket
>> > v6.9/share/pkgs/gui-lib/mred/private/wx/common/queue.rkt:505:32
>> >/Applications/Racket
>> > v6.9/share/pkgs/gui-lib/mred/private/wx/common/queue.rkt:653:3
>> >
>> > Is this a problem with my setup, or with DrRacket?
>>
>> Actually, I’ve been seeing this for quite some time; since well before 6.8
>> came out.
>>
>> It’s a bit squirrely, though; moving the prefs file out of the way solves
>> the problem, and then moving it back again seems not to bring the problem
>> back. I think this stymied me in trying to formulate a bug report.
>>
>> But: yes, I’ve seen this a lot.
>>
>> 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.

Re: [racket-users] Racket v6.9

[Vincent St-Amour]

Hi Meino,

Glad to hear everything is working now!

Thanks for reporting this usability issue in the installer. I'll look
into it.

Vincent



On Fri, 28 Apr 2017 19:42:24 -0500,
tu...@posteo.de wrote:
> 
> 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.
> > > 

Re: [racket-users] Increasing speed of a simulation

[Matthias Felleisen]

> On Apr 30, 2017, at 1:30 PM, Vityou  wrote:
> 
> I am working on an ant colony simulation/game/thing.  Right now I'm using 
> 2htdp/universe and 2htdp/image and the racket language.  To represent an ant, 
> I made a struct with a position, angle, and carrying-food?.  To test the 
> speed of the simulation I made a new ant with a random angle on every clock 
> tick of big bang (my world state is a structure that holds a list of ants and 
> various other things like pheromones, food, etc.).  However, when there were 
> about 250 ants on the screen, it started to slow down a lot.  Not rendering 
> sped it up somewhat but not by much.  I was confused by this because in 
> python I had made a similar simulation with 5000 objects and it didn't seem 
> so slow down very much.  Is there anyway to make it faster?  Thanks for any 
> help.


You should probably replace 2htdp/universe and /image with racket/draw and 
racket/gui. And I should probably write a chapter on how to do so 
systematically. 

[[ These teaching libraries are written in a purely functional style and with 
tons of checks so that if something goes wrong, which always does for 
beginners, the error messages are good. The price you pay in performance is a 
large factor. ]] 

-- 
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] Increasing speed of a simulation

[Vityou]

I am working on an ant colony simulation/game/thing.  Right now I'm using 
2htdp/universe and 2htdp/image and the racket language.  To represent an ant, I 
made a struct with a position, angle, and carrying-food?.  To test the speed of 
the simulation I made a new ant with a random angle on every clock tick of big 
bang (my world state is a structure that holds a list of ants and various other 
things like pheromones, food, etc.).  However, when there were about 250 ants 
on the screen, it started to slow down a lot.  Not rendering sped it up 
somewhat but not by much.  I was confused by this because in python I had made 
a similar simulation with 5000 objects and it didn't seem so slow down very 
much.  Is there anyway to make it faster?  Thanks for any help.

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

[Rebelsky, Samuel]

The Bootstrap project has been hard at work to make WeScheme accessible, 
including some sensible expand/collapse options for viewing code and options.  
See the post at

http://www.bootstrapworld.org/blog/accessibility/User-Interface-REPL.shtml

for some basic information.  There are at least two other posts in the 'blog 
about accessibility in WeScheme.

-- SamR

> On Apr 28, 2017, at 12: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.

Re: [racket-users] student project idea: semi-WYSIWYG Scribble editor (Was: Racket 6.9)

[Matthew Butterick]

> On Apr 29, 2017, at 2:24 PM, Neil Van Dyke  wrote:
> 
> Alternatively, and simpler: you might have two window panes, one in which the 
> user writes Scribble source, and another that gives an almost-live 
> semi-WYSIWYG view of how the source would render.


FWIW, Pollen includes dynamic previewing of Scribble files (where the 
"almost-live semi-WYSIWYG view" is a browser window). This is how I work on all 
my Scribble sources.

-- 
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] student project idea: semi-WYSIWYG Scribble editor (Was: Racket 6.9)

[Neil Van Dyke]

Hendrik Boom wrote on 04/30/2017 08:25 AM:

On Sat, Apr 29, 2017 at 05:24:39PM -0400, Neil Van Dyke wrote:


Alternatively, and simpler: you might have two window panes, one in which
the user writes Scribble source, and another that gives an almost-live
semi-WYSIWYG view of how the source would render. Ideally have the
semi-WYSIWYG one approximate UI cues like text cursor point and selection
highlighting in the semi-WYSIWG view.

This is the approach that makes sense to me.  But pointing and
selecting in the semi-WYSIWYG window would probaby require deep
involvement in scribble's own code.


Doing it perfectly would.  I'm proposing this as an exercise in clever 
hacking for a student, not routine engineering.


For one approach, a semi-WYSIWYG program could "experiment" with the 
renderer, to see what the output is for a given input construct, and see 
whether it can trace the input text through, and what happens to it.  If 
it can't see where the text went, then maybe that text just appears 
non-WYSIWYG with an box around it, and you can still represent points 
and selections.   But if the program can find the input text in the 
output, then the program can look for attributes of the rendering in 
which it is interested (mainly typeface/size/color changes), and 
selectively apply those to its semi-WYSIWYG view.


Constructs that require more complex structure, like itemized lists, are 
a harder problem, but not intractable, if you don't need to be perfect.  
These are easier if you're wiling to send real valid documents through a 
renderer, and remember things you've learned.


There are also some UI design decisions to make about how semi-WYSIWYG 
handles output it can't figure out.  Consider a user-defined procedure 
`plural`, which, for example, takes the input "try" and ultimately 
renders as "tries".  You can't trace that text through (unless you want 
to throw linguistics at this particular contrived example, which I 
suspect would be irrelevant overkill for real world situations).  You 
might decide that such things are rendered semi-WYSIWYG as a two-part 
input-output box, or you might just show the input in a box, or (if you 
don't need to be editable) show only an approximation of the output, or 
show only the output approximation except when the cursor/pointer is in 
it or adjacent.


--
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] RE: student project idea: semi-WYSIWYG Scribble editor (Was: Racket 6.9)

[Hendrik Boom]

On Sun, Apr 30, 2017 at 01:24:23AM +0200, Jos Koot wrote:
> Hi Matthias,
> Put it your way it seems managable for a simple user like me.
> I don't immediately see how to follow all details of your advice,
> but I'll look into it in due time. I'll need time for that
> and probably from time to time some more advice.
> For instance, I would like to avoid repeated execution of interactions
> that are not mutated, for they may slow down.
> The rendering of a scribble can easily take 10 or more seconds.

That's the main reason I'm not using Scribble.  I'm writing a novel, 
and rendering it in scribble takes enough time to set up a coffee 
maker, not just to pour out a cup in the next room.

But I like Scribble enough to have written a C++ implementation of the 
very few Scribble primitives I actually use frequently.  That renders 
the entire novel faster than I can blink.  It takes longer for my 
browser to read the generated HTML than it takes to produce it.

Of course my code doesnt allow the writer to code new features in 
Scribble.  That's a serious loss.

I was using the version of Scribble that's packaged with Debian/Devuan 
Jessie.  Are there known serious performance issues with that, such as 
not running actual machine code?

-- hendrik

> A memoizing interaction (and companions) seems possible, though.
> May be much more memoizing is possible for speed up.

If Scribble is has to be as slow as I found it to be, it's necessary.  

I'm not sure if Scribble is well-suited to memozation.  THings like 
index entries and page numbers seem prety well to require global 
reprocessing.

--  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] student project idea: semi-WYSIWYG Scribble editor (Was: Racket 6.9)

[Hendrik Boom]

On Sat, Apr 29, 2017 at 05:24:39PM -0400, Neil Van Dyke wrote:

> 
> Alternatively, and simpler: you might have two window panes, one in which
> the user writes Scribble source, and another that gives an almost-live
> semi-WYSIWYG view of how the source would render. Ideally have the
> semi-WYSIWYG one approximate UI cues like text cursor point and selection
> highlighting in the semi-WYSIWG view.

This is the approach that makes sense to me.  But pointing and 
selecting in the semi-WYSIWYG window would probaby require deep 
involvement in scribble's own code.

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