[racket-dev] Release for v5.3 is about to begin

2012-04-02 Thread Ryan Culpepper
The release process for v5.3 will begin in about a week.  If
you have any new features that you want in and are relatively close
to being done, now is a good time to do that.
-- 
Ryan Culpepper
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Release for v5.3 is about to begin

2012-04-02 Thread Danny Yoo
On Monday, April 2, 2012, Ryan Culpepper wrote:

 The release process for v5.3 will begin in about a week.  If
 you have any new features that you want in and are relatively close
 to being done, now is a good time to do that.



Is submodule support going to be a part of 5.3?
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] confusing doc for in-directory

2012-04-02 Thread Matthew Flatt
I pushed a doc update, but forgot to reply. The documentation now
clarifies that `in-directory' recursively traverses subdirectories, and
it suggests `directory-list' for just the immediate content of a
directory.

At Wed, 28 Mar 2012 17:21:57 -0700, Eric Hanchrow wrote:
 http://docs.racket-lang.org/reference/sequences.html?q=read-directory#(def._((li
 b._racket/private/base..rkt)._in-directory))
  says that the form will ``Return a sequence that produces all of the
 paths for files, directories, and links with dir. ''  That's
 ungrammatical, but worse, it gave me no clue that it will return all
 files _at any depth_, similar to the Unix comand find dir.  I'd
 expected it to return only immediate children of dir, similarly to
 find dir -mindepth 1 -maxdepth 1; I was surprised when (in-directory
 /tmp) complained about not being able to open
 /tmp/some-subdirectory/ due to permissions problems.
 _
   Racket Developers list:
   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] provide specs in eopl in repository use (all-defined-out) instead of (all-defined)

2012-04-02 Thread Nadeem Abdul Hamid
How come when building Racket from the latest source of the repository
(at least as of 3 days ago), #lang eopl doesn't recognize
(all-defined) as a valid provide spec and wants (all-defined-out)
instead?
--- nadeem
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] provide specs in eopl in repository use (all-defined-out) instead of (all-defined)

2012-04-02 Thread Robby Findler
Because it was changed to be based on #lang racket instead of the
(old) #lang mzscheme not too long ago. I think there was a post here
(or on the users's list) about this, but I'm not sure that this
particular point was mentioned there, so I can see how you'd be
surprised.

Is this causing you trouble with classes or similar? Would a #lang
eopl/mzscheme or something like that be useful for backwards
compatibility? (You'd still need to use that #lang line, tho, since
the regular eopl language is now changed for good.)

Robby

On Mon, Apr 2, 2012 at 7:09 PM, Nadeem Abdul Hamid nad...@acm.org wrote:
 How come when building Racket from the latest source of the repository
 (at least as of 3 days ago), #lang eopl doesn't recognize
 (all-defined) as a valid provide spec and wants (all-defined-out)
 instead?
 --- nadeem
 _
  Racket Developers list:
  http://lists.racket-lang.org/dev

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


Re: [racket-dev] provide specs in eopl in repository use (all-defined-out) instead of (all-defined)

2012-04-02 Thread Nadeem Abdul Hamid
OK, thanks. Just wanted to make sure something wasn't broken. It's
only a minor inconvenience - my students are using the version from
the download page, while I usually use one built from source, but I've
just been using the regular 5.2.1 version to run their programs. In
any event, perhaps the documentation needs to be updated: the entry:
  
http://pre.racket-lang.org/docs/html/eopl/index.html#(form._((lib._eopl/eopl..rkt)._provide))
points to the mzscheme version of provide.

--- nadeem

On Mon, Apr 2, 2012 at 8:22 PM, Robby Findler
ro...@eecs.northwestern.edu wrote:
 Because it was changed to be based on #lang racket instead of the
 (old) #lang mzscheme not too long ago. I think there was a post here
 (or on the users's list) about this, but I'm not sure that this
 particular point was mentioned there, so I can see how you'd be
 surprised.

 Is this causing you trouble with classes or similar? Would a #lang
 eopl/mzscheme or something like that be useful for backwards
 compatibility? (You'd still need to use that #lang line, tho, since
 the regular eopl language is now changed for good.)

 Robby

 On Mon, Apr 2, 2012 at 7:09 PM, Nadeem Abdul Hamid nad...@acm.org wrote:
 How come when building Racket from the latest source of the repository
 (at least as of 3 days ago), #lang eopl doesn't recognize
 (all-defined) as a valid provide spec and wants (all-defined-out)
 instead?
 --- nadeem
 _
  Racket Developers list:
  http://lists.racket-lang.org/dev

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