Re: [racket-dev] Continuing to work on GitHub bug migration

2013-05-30 Thread Sam Tobin-Hochstadt
On Thu, May 30, 2013 at 5:34 PM, John Clements
 wrote:
>
> On May 30, 2013, at 1:47 PM, Sam Tobin-Hochstadt wrote:
>
>> After a long hiatus, I'm again working on migrating our bug database
>> to GitHub issues. My plan is to convert a large portion of the old
>> bugs (more than 5 years old, up to 9433) in the near future, and in
>> particular all of the bugs filed before the bug DB moved to
>> Northeastern (up to ~2100) very soon.
>>
>> To do this, I need GitHub authorization keys from people who used the
>> bug DB then, so that I can post bugs and comments as you to GitHub. To
>> provide them, please visit this page:
>> http://samth2.ccs.neu.edu:8080/github-auth/ and follow the
>> instructions.
>
> It looks like this server is not currently accepting connections on port 
> 8080….

Sorry about that, it's now fixed.

Sam

_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Continuing to work on GitHub bug migration

2013-05-30 Thread John Clements

On May 30, 2013, at 1:47 PM, Sam Tobin-Hochstadt wrote:

> After a long hiatus, I'm again working on migrating our bug database
> to GitHub issues. My plan is to convert a large portion of the old
> bugs (more than 5 years old, up to 9433) in the near future, and in
> particular all of the bugs filed before the bug DB moved to
> Northeastern (up to ~2100) very soon.
> 
> To do this, I need GitHub authorization keys from people who used the
> bug DB then, so that I can post bugs and comments as you to GitHub. To
> provide them, please visit this page:
> http://samth2.ccs.neu.edu:8080/github-auth/ and follow the
> instructions.

It looks like this server is not currently accepting connections on port 8080….

clements@li21-127:~$ curl -v http://samth2.ccs.neu.edu:8080/github-auth/
* About to connect() to samth2.ccs.neu.edu port 8080 (#0)
*   Trying 129.10.115.151... Connection refused
* couldn't connect to host
* Closing connection #0
curl: (7) couldn't connect to host
clements@li21-127:~$ 



> 
> This applies for anyone who's used the bug DB ever, although I won't
> be migrating the newer bugs immediately.
> 
> The people who are most needed for my immediate plans have been
> explicitly cc'ed on this message. If you're one of them and for
> whatever reason, you don't want to do this, please just let me know
> off-list.
> 
> Thanks!
> Sam
> _
>  Racket Developers list:
>  http://lists.racket-lang.org/dev


_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] white bar in lhs of comment box: bug or feature?

2013-05-30 Thread John Clements
In the attached screenshot (hopefully small enough to get through the size filter), I see that the background of the "comment semicolon" is rendered in white, regardless of the background color. Based on the lack of space between that bar and the enclosed text, I'm imagining this is a bug.  On the other hand, it's kind of nice to be able to see the extent of the box clearly. I'll submit a PR if this is actually a bug; it seems like it could be a one-line fix.John_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] Continuing to work on GitHub bug migration

2013-05-30 Thread Sam Tobin-Hochstadt
After a long hiatus, I'm again working on migrating our bug database
to GitHub issues. My plan is to convert a large portion of the old
bugs (more than 5 years old, up to 9433) in the near future, and in
particular all of the bugs filed before the bug DB moved to
Northeastern (up to ~2100) very soon.

To do this, I need GitHub authorization keys from people who used the
bug DB then, so that I can post bugs and comments as you to GitHub. To
provide them, please visit this page:
http://samth2.ccs.neu.edu:8080/github-auth/ and follow the
instructions.

This applies for anyone who's used the bug DB ever, although I won't
be migrating the newer bugs immediately.

The people who are most needed for my immediate plans have been
explicitly cc'ed on this message. If you're one of them and for
whatever reason, you don't want to do this, please just let me know
off-list.

Thanks!
Sam
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] PLaneT(2): Single vs multi-collection packages

2013-05-30 Thread Eli Barzilay
Yes, I really want to try and get to look into doing this.  The thing
is that multi-collection libraries are going to be a common case for
plt packages (which will get pulled out from the main repository), but
the single-collection ones are going to be the much more popular case
elsewhere.

(And I also still dream on doing some `url-in' to require a single
file, since that's also an important mode of quick sharing.  But
that's another story.)


10 minutes ago, Jay McCarthy wrote:
> The Racket package system doesn't support packages that aren't
> collection roots. Eli has said that he wants to implement such a
> feature, but it is not available today.
> 
> Jay
> 
> On Thu, May 30, 2013 at 8:29 AM, Laurent  wrote:
> > I'm willing to upgrade my packages for the new PLaneT system, but one thing
> > that pushes me back is the fact that I need to create a directory for my
> > package and a subdirectory for the collection(s).
> >
> > But most of my packages are (and will probably be) single-collection
> > packages, and it hurts my logic to have to modify my directory tree for that
> > purpose.
> >
> > I know there have been several discussions already about this, but perhaps
> > there is a simple fix:
> > Maybe there could be a `single-collection?' entry in the info.rkt file
> > which, when true, would tell `raco pkg install' to create itself a directory
> > for the package that has the same name as the collection it contains?

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] PLaneT(2): Single vs multi-collection packages

2013-05-30 Thread Jay McCarthy
The Racket package system doesn't support packages that aren't
collection roots. Eli has said that he wants to implement such a
feature, but it is not available today.

Jay

On Thu, May 30, 2013 at 8:29 AM, Laurent  wrote:
> I'm willing to upgrade my packages for the new PLaneT system, but one thing
> that pushes me back is the fact that I need to create a directory for my
> package and a subdirectory for the collection(s).
>
> But most of my packages are (and will probably be) single-collection
> packages, and it hurts my logic to have to modify my directory tree for that
> purpose.
>
> I know there have been several discussions already about this, but perhaps
> there is a simple fix:
> Maybe there could be a `single-collection?' entry in the info.rkt file
> which, when true, would tell `raco pkg install' to create itself a directory
> for the package that has the same name as the collection it contains?
>
> Laurent
>
>
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
>



-- 
Jay McCarthy 
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] raco pkg remove not removing

2013-05-30 Thread J. Ian Johnson
Quite right. You caught it. Thanks.
-Ian
- Original Message -
From: "Matthew Flatt" 
To: "J. Ian Johnson" 
Cc: "J. Ian Johnson" , "dev" 
Sent: Thursday, May 30, 2013 12:42:18 PM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] raco pkg remove not removing

Does `raco link -l' show any trace of the old package (which would
suggest that the package manager failed between the points of removing
its own registration of the package and removing the link)?

If the package install was not installation-wide, then all state should
be in your "add-on" directory as reported by `(find-system-path
'addon-dir)'. The links are in "links.rktd", and package files are in
"pkgs" or "pkgs" inside a directory whose name is a version number.

At Thu, 30 May 2013 11:38:05 -0400 (EDT), "J. Ian Johnson" wrote:
> Following Asumu's advice, I used --force. I got the same error, but then it 
> was no longer installed. I tried to install again with the fixed files. It's 
> still looking for a directory for-accumulate! There's nothing in my 
> repository 
> that references that name anymore. I'm quite confused. Are there some latent 
> files downloaded by the package manager that are being used when they 
> shouldn't? If so, that's a bug. Additionally I would want to know where they 
> are so I can delete them to work around the problem currently.
> -Ian
> - Original Message -
> From: "J. Ian Johnson" 
> To: "dev" 
> Sent: Thursday, May 30, 2013 11:31:25 AM GMT -05:00 US/Canada Eastern
> Subject: [racket-dev] raco pkg remove not removing
> 
> I tried to turn my nifty-macros repo into something that the new package 
> manager could work with. I recently changed for-accumulate.rkt to for-acc.rkt 
> but forgot to change main.rkt to require and reprovide from the new file. I 
> installed from github and it died on looking for the for-accumulate 
> directory. 
> This is weird since nothing referred to the directory - it was all the files. 
> Even so, I changed main.rkt to reflect the changes and tried to install. No 
> go, the package was already installed (albeit incorrectly). I try to remove. 
> It has the same error and fails to remove the package. I'm now stuck. How to 
> I 
> remove an incorrectly installed package?
> 
> -Ian
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] raco pkg remove not removing

2013-05-30 Thread Matthew Flatt
Does `raco link -l' show any trace of the old package (which would
suggest that the package manager failed between the points of removing
its own registration of the package and removing the link)?

If the package install was not installation-wide, then all state should
be in your "add-on" directory as reported by `(find-system-path
'addon-dir)'. The links are in "links.rktd", and package files are in
"pkgs" or "pkgs" inside a directory whose name is a version number.

At Thu, 30 May 2013 11:38:05 -0400 (EDT), "J. Ian Johnson" wrote:
> Following Asumu's advice, I used --force. I got the same error, but then it 
> was no longer installed. I tried to install again with the fixed files. It's 
> still looking for a directory for-accumulate! There's nothing in my 
> repository 
> that references that name anymore. I'm quite confused. Are there some latent 
> files downloaded by the package manager that are being used when they 
> shouldn't? If so, that's a bug. Additionally I would want to know where they 
> are so I can delete them to work around the problem currently.
> -Ian
> - Original Message -
> From: "J. Ian Johnson" 
> To: "dev" 
> Sent: Thursday, May 30, 2013 11:31:25 AM GMT -05:00 US/Canada Eastern
> Subject: [racket-dev] raco pkg remove not removing
> 
> I tried to turn my nifty-macros repo into something that the new package 
> manager could work with. I recently changed for-accumulate.rkt to for-acc.rkt 
> but forgot to change main.rkt to require and reprovide from the new file. I 
> installed from github and it died on looking for the for-accumulate 
> directory. 
> This is weird since nothing referred to the directory - it was all the files. 
> Even so, I changed main.rkt to reflect the changes and tried to install. No 
> go, the package was already installed (albeit incorrectly). I try to remove. 
> It has the same error and fails to remove the package. I'm now stuck. How to 
> I 
> remove an incorrectly installed package?
> 
> -Ian
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] raco pkg remove not removing

2013-05-30 Thread J. Ian Johnson
Following Asumu's advice, I used --force. I got the same error, but then it was 
no longer installed. I tried to install again with the fixed files. It's still 
looking for a directory for-accumulate! There's nothing in my repository that 
references that name anymore. I'm quite confused. Are there some latent files 
downloaded by the package manager that are being used when they shouldn't? If 
so, that's a bug. Additionally I would want to know where they are so I can 
delete them to work around the problem currently.
-Ian
- Original Message -
From: "J. Ian Johnson" 
To: "dev" 
Sent: Thursday, May 30, 2013 11:31:25 AM GMT -05:00 US/Canada Eastern
Subject: [racket-dev] raco pkg remove not removing

I tried to turn my nifty-macros repo into something that the new package 
manager could work with. I recently changed for-accumulate.rkt to for-acc.rkt 
but forgot to change main.rkt to require and reprovide from the new file. I 
installed from github and it died on looking for the for-accumulate directory. 
This is weird since nothing referred to the directory - it was all the files. 
Even so, I changed main.rkt to reflect the changes and tried to install. No go, 
the package was already installed (albeit incorrectly). I try to remove. It has 
the same error and fails to remove the package. I'm now stuck. How to I remove 
an incorrectly installed package?

-Ian
_
  Racket Developers list:
  http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] raco pkg remove not removing

2013-05-30 Thread J. Ian Johnson
I tried to turn my nifty-macros repo into something that the new package 
manager could work with. I recently changed for-accumulate.rkt to for-acc.rkt 
but forgot to change main.rkt to require and reprovide from the new file. I 
installed from github and it died on looking for the for-accumulate directory. 
This is weird since nothing referred to the directory - it was all the files. 
Even so, I changed main.rkt to reflect the changes and tried to install. No go, 
the package was already installed (albeit incorrectly). I try to remove. It has 
the same error and fails to remove the package. I'm now stuck. How to I remove 
an incorrectly installed package?

-Ian
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] experiment reorganizing the repo into packages

2013-05-30 Thread Matthew Flatt
As I understand things, we should certainly try to align divisions of
responsibility with divisions of code (including tests and docs) among
packages.

My initial experiment probably doesn't align them very well, and I'd
expect a better alignment to emerge from everyone's efforts to improve
some initial cut.

At Thu, 30 May 2013 11:02:16 -0400, Matthias Felleisen wrote:
> 
> Matthew, 
> 
> I have seen 'personal responsibility' mentioned only in passing. 
> 
> Does existence of package imply any personal responsibilities? 
> The current organization doesn't seem to say so. 
> 
> -- Matthias
> 
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev

_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] experiment reorganizing the repo into packages

2013-05-30 Thread Matthias Felleisen

Matthew, 

I have seen 'personal responsibility' mentioned only in passing. 

Does existence of package imply any personal responsibilities? 
The current organization doesn't seem to say so. 

-- Matthias

_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] experiment reorganizing the repo into packages

2013-05-30 Thread Matthew Flatt
At Thu, 30 May 2013 10:02:29 -0400, Sam Tobin-Hochstadt wrote:
> One question, though: how does this work with the package manager.
> Right now, only repositories can be specified as the source when
> creating a package at pkg.racket-lang.org.  There must be something
> I'm missing about how this will work.

A repository spec is

 github://github.com

where the  can be a subdirectory name.

So, if the Scribble repo is github://github.com/plt/scribble, then

 scribble-lib
   => github://github.com/plt/scribble/master/scribble-lib
 scribble-docs
   => github://github.com/plt/scribble/master/scribble-docs
 scribble
   => github://github.com/plt/scribble/master/scribble

should work.

That does add yet another directory layer if we try to make the
"scribble" repo a submodule of another repo, though.

_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] PLaneT(2): Single vs multi-collection packages

2013-05-30 Thread Laurent
I'm willing to upgrade my packages for the new PLaneT system, but one thing
that pushes me back is the fact that I need to create a directory for my
package and a subdirectory for the collection(s).

But most of my packages are (and will probably be) single-collection
packages, and it hurts my logic to have to modify my directory tree for
that purpose.

I know there have been several discussions already about this, but perhaps
there is a simple fix:
Maybe there could be a `single-collection?' entry in the info.rkt file
which, when true, would tell `raco pkg install' to create itself a
directory for the package that has the same name as the collection it
contains?

Laurent
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] experiment reorganizing the repo into packages

2013-05-30 Thread Sam Tobin-Hochstadt
On Thu, May 30, 2013 at 9:07 AM, Matthew Flatt  wrote:
> At Thu, 30 May 2013 09:01:16 -0400, Sam Tobin-Hochstadt wrote:
>> I also really don't want to have Typed Racket's documentation outside
>> of Typed Racket's code repository, and I think it would be a mistake
>> to do that for other parts of Racket.  An on-point comment on this
>> from just yesterday in a different context:
>> https://twitter.com/domenic/status/339848565838983168 and I think the
>> same reasons that's true would make splitting repositories for code
>> and documentation a big mistake.
>
> Just to make sure that everyone is on the same page: different packages
> do not imply different repositories.
>
> When packages are in a single repository, though, things work best if
> each package has its own subdirectory. I would imagine, for example,
> that "scribble-lib", "scribble-doc", and "scribble" would all be
> directories in a single repository (referenced by three packages), for
> example.
>
> It may even make sense to have certain different packages in a single
> repository whether or not we split "-lib" and "-doc" into packages.

Ok, that's reassuring.  In that case, I'm ambivalent between 2 & 3.

One question, though: how does this work with the package manager.
Right now, only repositories can be specified as the source when
creating a package at pkg.racket-lang.org.  There must be something
I'm missing about how this will work.

Sam
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] experiment reorganizing the repo into packages

2013-05-30 Thread Matthew Flatt
At Thu, 30 May 2013 09:01:16 -0400, Sam Tobin-Hochstadt wrote:
> I also really don't want to have Typed Racket's documentation outside
> of Typed Racket's code repository, and I think it would be a mistake
> to do that for other parts of Racket.  An on-point comment on this
> from just yesterday in a different context:
> https://twitter.com/domenic/status/339848565838983168 and I think the
> same reasons that's true would make splitting repositories for code
> and documentation a big mistake.

Just to make sure that everyone is on the same page: different packages
do not imply different repositories. 

When packages are in a single repository, though, things work best if
each package has its own subdirectory. I would imagine, for example,
that "scribble-lib", "scribble-doc", and "scribble" would all be
directories in a single repository (referenced by three packages), for
example.

It may even make sense to have certain different packages in a single
repository whether or not we split "-lib" and "-doc" into packages.

_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] experiment reorganizing the repo into packages

2013-05-30 Thread Sam Tobin-Hochstadt
On Thu, May 30, 2013 at 8:50 AM, Matthew Flatt  wrote:
>
> To summarize, I see our options as
>
>  1. Suspend the effort to reorganize our repository into packages and
> instead start experimenting with subpackages.
>
>  2. Use a naming convention and keep the same kind of split as in the
> experimental reorganization --- and decide on some initial
> conventions ("-lib", "-doc", "-typed", and "-exe"?).
>
>  3. Reorganize our repository into packages, but don't try to split out
> things that conceptually belong together but have different kinds
> of dependencies (such as run-time code versus documentation).
>
> My preference in order is 2, 3, 1.

I don't think we should think of 1 as an option at this point.

I also really don't want to have Typed Racket's documentation outside
of Typed Racket's code repository, and I think it would be a mistake
to do that for other parts of Racket.  An on-point comment on this
from just yesterday in a different context:
https://twitter.com/domenic/status/339848565838983168 and I think the
same reasons that's true would make splitting repositories for code
and documentation a big mistake.

That doesn't mean that "-typed" versions of some packages doesn't make
sense, though (gui-typed, for example).

I would significantly prefer the binary packages idea to splitting the
repositories.

Sam
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] experiment reorganizing the repo into packages

2013-05-30 Thread Matthew Flatt
At Wed, 29 May 2013 15:51:30 -0400, Eli Barzilay wrote:
> 20 minutes ago, Matthew Flatt wrote:
> > > [..."package distribution kinds"...]
> > 
> > Well, I agree with all these thoughts, but what's the conclusion?
> > 
> > There's no requirement that packages be in multiple repositories,
> > but different packages in a single repository currently have to be
> > different subdirectories in the repository. Do we need (or do we
> > really want) a notion of "subpackages" to support some general form
> > of splitting within a package?
> 
> I think so.

I've been trying to think through the details, and I don't see this as
the right direction for now.

You've sketched out the producer side, and I'm not sure of some about
some of those details. The consumer side seems even more complex to me.
It seems like the package system would have to keep track of which
subpackages are installed for a package, provide an interface to the
user (e.g., in the GUI) for subpackages, and be able to update a
package with new subpackages --- all while tracking dependencies at the
level of subpackages. I'm sure it can all be done, but I'm not sure how
difficult or important it will be relative to everything else that
still needs to be done, and I'm pretty sure it can't all be done right
now.

I'm inclined to think that the analogy to submodules is apt at the
level of the design process: we should try plain packages, first, and
when we understand them better try to improve with an extension to
subpackages.


Instead of trying to create subpackages, we might stick with a naming
convention. Even with a naming convention, it might make sense to
extend the package-manager GUI so that it recognizes the convention and
groups related packages together in a list view (but all the machinery
remains at the package level). Also, a package implementor is free to
develop "subpackages" along the lines you suggest, but splitting out
the subpackages into packages before handling them to a catalog.


Or, we could just not try to slice packages as finely for now, so that
the "-lib" and "-docs" packages of the experimental split are merged
together --- leaving a future split possibly to subpackages. That will
most likely result in a coarse layering that is close to "build-deps"
up to the "drracket" layer, but still provide more separation for
things that are outside the layer needed by DrRacket itself; for
example, "games", "redex", "htdp", "plai", "picturing-programs", and
"plot" can still be separate packages, I think.


To summarize, I see our options as

 1. Suspend the effort to reorganize our repository into packages and
instead start experimenting with subpackages.

 2. Use a naming convention and keep the same kind of split as in the
experimental reorganization --- and decide on some initial
conventions ("-lib", "-doc", "-typed", and "-exe"?).

 3. Reorganize our repository into packages, but don't try to split out
things that conceptually belong together but have different kinds
of dependencies (such as run-time code versus documentation).

My preference in order is 2, 3, 1.

_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] for/fold feature request

2013-05-30 Thread oev
Hi, Ian!

> The for[/*] macros are fairly low in the language tower for Racket, so
making these kinds of changes robust in the original implementation is
cumbersome and error-prone.

I supposed that adding anything as optional would not affect existing stuff.

> I've written a shim to use on top of for/fold
> and for*/fold to alleviate some pain in multiple value accumulation,
post-processing and irrelevant intermediate accumulators. It uses
syntax/parse, which is higher in the language tower. Check it out at
>
> https://github.com/ianj/nifty-macros/tree/master/for-accumulate

It's good enough to publish it as a package.

> If you find any bugs, just shoot me an email and I'll make sure to fix
the problems.
> -Ian

IMO, `for/acc' or `for/accum' is better than full name.

Thanks for answer!





> - Original Message -
> From: "oev" 
> To: dev@racket-lang.org
> Sent: Wednesday, May 29, 2013 7:30:59 AM GMT -05:00 US/Canada Eastern
Subject: [racket-dev]  for/fold feature request
>
> Hi, all!
>
> Using `for/fold' with more than one accumulator is inconvenient, when
there is a need for auxiliary operations with accumulators before
return.
>
> For example:
>
> (define (partition pred lst)
>   (define-values (a1 a2)
> (for/fold ([acc1 null]
>[acc2 null])
>   ([v (in-list lst)])
>   (if (pred v)
>   (values (cons v acc1) acc2)
>   (values acc1 (cons v acc2)
>   (values (reverse a1)
>   (reverse a2)))
>
> In example, it's impossible to reverse accumulators without using
intermediate definitions and applying `values' again.
>
> IMHO, very often in `loop with accumulator' cases, there is a final
operation with accumulator before return.
>
> Is it possible to add ability for defining such final operation as
optional or keyword argument?
>
> For example:
>
> (define (partition pred lst)
>   (for/fold ([acc1 null reverse]
>  [acc2 null reverse])
> ([v (in-list lst)])
> (if (pred v)
> (values (cons v acc1) acc2)
> (values acc1 (cons v acc2))
>
> ... or even better:
>
> (define (partition pred lst)
>   (for/fold ([acc1 null #:do-finally reverse]
>  [acc2 null #:do-finally reverse])
> ([v (in-list lst)])
> (if (pred v)
> (values (cons v acc1) acc2)
> (values acc1 (cons v acc2))
>
>
>
>
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
>




_
  Racket Developers list:
  http://lists.racket-lang.org/dev