From: Matthew Flatt <mflatt@cs.utah.edu>
To: plt-scheme@list.cs.brown.edu
Subject: [plt-scheme] 360.2
Date: Thu, 23 Nov 2006 09:55:13 0800

MzScheme and MrEd are now version 360.2 in the SVN repository trunk.

Changes:

 * Added support for manipulating filesystem paths that work on
   other platforms. For example,

     (split-path (bytes->path #"//machine/drive" ’windows))

   produces

     (values #f
             (bytes->path #"//machine/drive" ’windows)
             #t)

   on all platforms, since "//machine/drive" according to Windows
   conventions is a UNC path (and thus a root), while

     (split-path (bytes->path #"//machine/drive" ’unix))

   produces

     (values (bytes->path #"/machine/" ’unix)
             (bytes->path #"drive" ’unix)
             #f)

   since "//machine/drive" according to Unix conventions means "drive"
   inside the directory "machine" at the filesystem root (though with
   an extra forward slash at the beginning).

   The new optional argument to `bytes->path’ can be ’unix or ’windows,
   and it defaults to the result of `(system-path-convention-type)’.
   Mac OS X uses the ’unix path convention.

   The `path?’ predicate recognizes only paths that use the current
   platform’s convention. The `path-for-some-system?’ predicate
   recognizes all paths, and `path-convention-type’ takes a path for
   some platform and returns its type.

   MzScheme procedures that manipulate a path without consulting the
   filesystem now work with a path for any platform. In the case of a
   procedure like `build-path’, the given paths must all use the same
   convention. Also, in the case of `build-path’, all the arguments
   could be ’up and ’same, in which case the type for the result is the
   current platform’s type; the procedure `build-path/convention-type’
   accepts a specific convention type. Where strings are accepted, they
   are treated as paths using the current platform’s convention.

   Unless otherwise stated, a procedure that accepts a path argument
   accepts only paths using the current platform’s convention. Since
   the `path?’ predicate recognizes only paths for the current
   platform, existing contracts using `path?’ are ok, though some
   contracts might be generalized to support paths for any platform.

   The `string->path’ procedure always creates paths for the current
   platform’s conventions; too much can go wrong if you try to covert a
   string to another platform’s conventions using the encoding for the
   current machine’s locale. In cases where you think it should work,
   anyway, use one of the `string->bytes’ procedures.

 * The `serialize’ function from `(lib "serialize.ss")’ includes the
   path’s convention when serializing a path. Data serialized with the
   old protocol effectively deserializes as before: the path is assumed
   to use the current platform’s convention.

 * Added `integer-length’. The SRFI-60 implementation now re-exports
   MzScheme’s `integer-length’ (so there are no problems with
   collisions).

 * Added an optional argument to `tcp-addresses’ to get local and
   remote port numbers, in addition to local and remote addresses.

 * Added `system-idle-evt’, which produces an event that is ready when
   --- if the event were replaced by `never-evt’ in any active
   synchronization --- no MzScheme thread would be immediately
   runnable. This event is experimental, and it may only be useful for
   testing other of MzScheme’s synchronization primitives.

Matthew