Re: [racket-dev] Pre-Release Checklist for v5.3

2012-04-19 Thread Kathy Gray

On 18 Apr 2012, at 16:00, Ryan Culpepper wrote:

 * Kathy Gray kathryn.g...@cl.cam.ac.uk
  - Test Engine Tests

Done

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


Re: [racket-dev] Fwd: [racket] Are There More String Functions?

2012-04-19 Thread Laurent
(sorry, I couldn't figure out how to reply properly from the list archive,
as I don't receive the dev-list emails.)

One string function that I often find useful in various scripting languages
is a `string-split' (explode in php).
It can be done with `regexp-split', but having something more along the
lines of a `string-split' should belong to a racket/string lib I think.
Plus it would be symmetric with `string-join', which already is in
racket/string (or at least a doc line pointing to regexp-split should be
added there).

Maybe also a `string-replace' could be useful, especially when one does not
want regexps and has special characters that need to be quoted.

Regexps are very powerful, but they are complicated for beginners.

Laurent



 I think `racket/string' should provide the useful string functions,
 rather than refer users to srfis. The only srfi/13 function I ever
 use is `string-trim-both' -- any objection to adding that to
 `racket/string'?
 On Tue, Apr 17, 2012 at 5:29 PM, Matthias Felleisen
 matth...@ccs.neu.edu wrote:
 
  I saw no response to this question and no commit that includes the
  cross-link. Anything?
 
 
  Begin forwarded message:
 
  From: Asumu Takikawa as...@ccs.neu.edu
  Subject: Re: [racket] Are There More String Functions?
  Date: April 12, 2012 5:47:26 PM EDT
  To: Cristian Esquivias cristian.esquiv...@gmail.com
  Cc: us...@racket-lang.org
 
  On 2012-04-12 10:43:15 -0700, Cristian Esquivias wrote:
  As a slight aside, is this module mentioned anywhere in the Racket
  Guide or Racket Reference? I tried to RTFM as much as possible but
  didn't see this module mentioned anywhere in the string pages. Should
  this module be mentioned for others like me?
 
  I think that's an interesting point and has been brought up before on
  this list: what's the official stance on SRFIs? On the documentation
  page they are near the bottom in Miscellaneous libraries.
 
  If their use is encouraged, maybe doc pages should have a pointer in the
  margin similar to how reference entries point to guide entries. For
  example, the string section in the reference could point to SRFI-13.
 
  Cheers,
  Asumu
  
   Racket Users list:
   http://lists.racket-lang.org/users
 
 
  _
   Racket Developers list:
   http://lists.racket-lang.org/dev
 --
 sam th
 sa...@ccs.neu.edu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Fwd: [racket] Are There More String Functions?

2012-04-19 Thread Matthias Felleisen

I second that. 



On Apr 19, 2012, at 5:57 AM, Laurent wrote:

 (sorry, I couldn't figure out how to reply properly from the list archive, as 
 I don't receive the dev-list emails.)
 
 One string function that I often find useful in various scripting languages 
 is a `string-split' (explode in php).
 It can be done with `regexp-split', but having something more along the lines 
 of a `string-split' should belong to a racket/string lib I think.
 Plus it would be symmetric with `string-join', which already is in 
 racket/string (or at least a doc line pointing to regexp-split should be 
 added there).
 
 Maybe also a `string-replace' could be useful, especially when one does not 
 want regexps and has special characters that need to be quoted.
 
 Regexps are very powerful, but they are complicated for beginners.
 
 Laurent
 
  
 I think `racket/string' should provide the useful string functions,
 rather than refer users to srfis. The only srfi/13 function I ever
 use is `string-trim-both' -- any objection to adding that to
 `racket/string'?
 On Tue, Apr 17, 2012 at 5:29 PM, Matthias Felleisen
 matth...@ccs.neu.edu wrote:
 
  I saw no response to this question and no commit that includes the
  cross-link. Anything?
 
 
  Begin forwarded message:
 
  From: Asumu Takikawa as...@ccs.neu.edu
  Subject: Re: [racket] Are There More String Functions?
  Date: April 12, 2012 5:47:26 PM EDT
  To: Cristian Esquivias cristian.esquiv...@gmail.com
  Cc: us...@racket-lang.org
 
  On 2012-04-12 10:43:15 -0700, Cristian Esquivias wrote:
  As a slight aside, is this module mentioned anywhere in the Racket
  Guide or Racket Reference? I tried to RTFM as much as possible but
  didn't see this module mentioned anywhere in the string pages. Should
  this module be mentioned for others like me?
 
  I think that's an interesting point and has been brought up before on
  this list: what's the official stance on SRFIs? On the documentation
  page they are near the bottom in Miscellaneous libraries.
 
  If their use is encouraged, maybe doc pages should have a pointer in the
  margin similar to how reference entries point to guide entries. For
  example, the string section in the reference could point to SRFI-13.
 
  Cheers,
  Asumu
  
   Racket Users list:
   http://lists.racket-lang.org/users
 
 
  _
   Racket Developers list:
   http://lists.racket-lang.org/dev
 --
 sam th
 sa...@ccs.neu.edu
 _
  Racket Developers list:
  http://lists.racket-lang.org/dev

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


Re: [racket-dev] `string-split'

2012-04-19 Thread Eli Barzilay
[Changed title to talk about each one separately.]

Two hours ago, Laurent wrote:
 One string function that I often find useful in various scripting
 languages is a `string-split' (explode in php).  It can be done with
 `regexp-split', but having something more along the lines of a
 `string-split' should belong to a racket/string lib I think.  Plus
 it would be symmetric with `string-join', which already is in
 racket/ string (or at least a doc line pointing to regexp-split
 should be added there).

If you mean something like this:

  (define (string-split str) (regexp-match* #px\\S+ str))

?

If so, then I see a much weaker point for it -- unlike other small
utilities, this one doesn't even compose two function calls.

The very weak point here is if you want a default argument that
specifies the gaps to split on rather than the words:

  (define (string-split str [sep #px\\s+])
(remove* '() (regexp-split sep str)))

but that *does* use regexps, so I don't see the point, still...

-- 
  ((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] `string-replace'

2012-04-19 Thread Eli Barzilay
Two hours ago, Laurent wrote:

 Maybe also a `string-replace' could be useful, especially when one
 does not want regexps and has special characters that need to be
 quoted.

Again, it's not clear how this shold look -- my guess:

  (define (string-replace from str to)
(regexp-replace* (regexp-quote from) str to))

If so, then I see a weak point for this too: on one hand it does
compose two functions, but it does nothing more than that.  Also
characters that need to be quoted seem suspicious to me -- can you
clarify?  (I see quoting next to something that is supposed to be
newbie-friendly, and my alarm goes off...)

-- 
  ((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] `string-split'

2012-04-19 Thread Sam Tobin-Hochstadt
On Thu, Apr 19, 2012 at 8:21 AM, Eli Barzilay e...@barzilay.org wrote:

 Two hours ago, Laurent wrote:
 One string function that I often find useful in various scripting
 languages is a `string-split' (explode in php).  It can be done with
 `regexp-split', but having something more along the lines of a
 `string-split' should belong to a racket/string lib I think.  Plus
 it would be symmetric with `string-join', which already is in
 racket/ string (or at least a doc line pointing to regexp-split
 should be added there).

 If you mean something like this:

  (define (string-split str) (regexp-match* #px\\S+ str))

 ?

 If so, then I see a much weaker point for it -- unlike other small
 utilities, this one doesn't even compose two function calls.

It composes one function call (with an extremely complex API) with one
domain-specific language (that lots of people don't
know/understand/use) into one extremely simple but useful function.

 The very weak point here is if you want a default argument that
 specifies the gaps to split on rather than the words:

  (define (string-split str [sep #px\\s+])
    (remove* '() (regexp-split sep str)))

 but that *does* use regexps, so I don't see the point, still...

Note that (string-split str ;) works given that implementation,
which I think makes it both easy-to-understand and useful.
-- 
sam th
sa...@ccs.neu.edu

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


Re: [racket-dev] `string-split'

2012-04-19 Thread Laurent
 (define (string-split str [sep #px\\s+])
(remove* '() (regexp-split sep str)))


Nearly, I meant something more like this:

(define (string-split str [splitter  ])
  (regexp-split (regexp-quote splitter) str))

No regexp from the user POV, and much easier to use with little knowledge.
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] `string-split'

2012-04-19 Thread Matthew Flatt
I agree with this: we should add `string-split', the one-argument case
should be as Eli wrote, and the two-argument case should be as Laurent
wrote. (Probably the optional second argument should be string-or-#f,
where #f means to use #px\\s+.)

At Thu, 19 Apr 2012 14:30:31 +0200, Laurent wrote:
  (define (string-split str [sep #px\\s+])
 (remove* '() (regexp-split sep str)))
 
 
 Nearly, I meant something more like this:
 
 (define (string-split str [splitter  ])
   (regexp-split (regexp-quote splitter) str))
 
 No regexp from the user POV, and much easier to use with little knowledge.
 _
   Racket Developers list:
   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] `string-split'

2012-04-19 Thread Matthias Felleisen

I think Laurent pointed out in his initial message that beginners may be 
intimidated by regexps. I agree. Plus someone who isn't fluent with regexp may 
be more comfortable with string-split. Last but not least, a program documents 
itself more clearly with string-split vs regexp. 



On Apr 19, 2012, at 8:21 AM, Eli Barzilay wrote:

 [Changed title to talk about each one separately.]
 
 Two hours ago, Laurent wrote:
 One string function that I often find useful in various scripting
 languages is a `string-split' (explode in php).  It can be done with
 `regexp-split', but having something more along the lines of a
 `string-split' should belong to a racket/string lib I think.  Plus
 it would be symmetric with `string-join', which already is in
 racket/ string (or at least a doc line pointing to regexp-split
 should be added there).
 
 If you mean something like this:
 
  (define (string-split str) (regexp-match* #px\\S+ str))
 
 ?
 
 If so, then I see a much weaker point for it -- unlike other small
 utilities, this one doesn't even compose two function calls.
 
 The very weak point here is if you want a default argument that
 specifies the gaps to split on rather than the words:
 
  (define (string-split str [sep #px\\s+])
(remove* '() (regexp-split sep str)))
 
 but that *does* use regexps, so I don't see the point, still...
 
 -- 
  ((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


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


Re: [racket-dev] `string-replace'

2012-04-19 Thread Matthew Flatt
At Thu, 19 Apr 2012 08:26:20 -0400, Eli Barzilay wrote:
 Two hours ago, Laurent wrote:
 
  Maybe also a `string-replace' could be useful, especially when one
  does not want regexps and has special characters that need to be
  quoted.
 
 Again, it's not clear how this shold look -- my guess:
 
   (define (string-replace from str to)
 (regexp-replace* (regexp-quote from) str to))
 
 If so, then I see a weak point for this too: on one hand it does
 compose two functions, but it does nothing more than that.  Also
 characters that need to be quoted seem suspicious to me -- can you
 clarify?  (I see quoting next to something that is supposed to be
 newbie-friendly, and my alarm goes off...)

Surely Laurent meant

   (define (string-replace str from to)
 (regexp-replace* (regexp-quote from) str (regexp-replace-quote to)))

which I think is a great addition.

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


Re: [racket-dev] `string-replace'

2012-04-19 Thread Laurent
On Thu, Apr 19, 2012 at 14:26, Eli Barzilay e...@barzilay.org wrote:

 Two hours ago, Laurent wrote:

  Maybe also a `string-replace' could be useful, especially when one
  does not want regexps and has special characters that need to be
  quoted.

 Again, it's not clear how this shold look -- my guess:

  (define (string-replace from str to)
(regexp-replace* (regexp-quote from) str to))


I meant this:

(define (string-replace from str to)
   (regexp-replace* (regexp-quote from) str (regexp-replace-quote to)))

(string-replace ( (a list) \\1)  ; - \\1a list)

Newbie-friendly (I meant regexp-quoted without the user seeing it) and easy
to use.

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


Re: [racket-dev] `string-split'

2012-04-19 Thread Laurent
On Thu, Apr 19, 2012 at 14:33, Matthew Flatt mfl...@cs.utah.edu wrote:

 I agree with this: we should add `string-split', the one-argument case
 should be as Eli wrote,


About this I'm not sure, as one cannot reproduce this behavior by providing
an argument (or it could make the difference between string-as-not-regexps
and regexps? Wouldn't this be different from other places?).
It would then appear somewhat magical. To me the   default splitter seems
more intuitive.

Laurent


 and the two-argument case should be as Laurent
 wrote. (Probably the optional second argument should be string-or-#f,
 where #f means to use #px\\s+.)

 At Thu, 19 Apr 2012 14:30:31 +0200, Laurent wrote:
   (define (string-split str [sep #px\\s+])
  (remove* '() (regexp-split sep str)))
  
 
  Nearly, I meant something more like this:
 
  (define (string-split str [splitter  ])
(regexp-split (regexp-quote splitter) str))
 
  No regexp from the user POV, and much easier to use with little
 knowledge.
  _
Racket Developers list:
http://lists.racket-lang.org/dev

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


Re: [racket-dev] `string-split'

2012-04-19 Thread Matthew Flatt
At Thu, 19 Apr 2012 14:43:44 +0200, Laurent wrote:
 On Thu, Apr 19, 2012 at 14:33, Matthew Flatt mfl...@cs.utah.edu wrote:
 
  I agree with this: we should add `string-split', the one-argument case
  should be as Eli wrote,
 
 
 About this I'm not sure, as one cannot reproduce this behavior by providing
 an argument (or it could make the difference between string-as-not-regexps
 and regexps? Wouldn't this be different from other places?).

I'm suggesting that supplying `#f' as the argument would be the same as
not supplying the argument.

It is a special case, though. I don't mind the specialness here,
because I see the job of `string-split' as making a couple of useful
special cases easy (as opposed to the generality of `regexp-split').


 It would then appear somewhat magical. To me the   default splitter seems
 more intuitive.
 
 Laurent
 
 
  and the two-argument case should be as Laurent
  wrote. (Probably the optional second argument should be string-or-#f,
  where #f means to use #px\\s+.)
 
  At Thu, 19 Apr 2012 14:30:31 +0200, Laurent wrote:
(define (string-split str [sep #px\\s+])
   (remove* '() (regexp-split sep str)))
   
  
   Nearly, I meant something more like this:
  
   (define (string-split str [splitter  ])
 (regexp-split (regexp-quote splitter) str))
  
   No regexp from the user POV, and much easier to use with little
  knowledge.
   _
 Racket Developers list:
 http://lists.racket-lang.org/dev
 
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] `string-split'

2012-04-19 Thread Laurent
On Thu, Apr 19, 2012 at 14:53, Matthew Flatt mfl...@cs.utah.edu wrote:

 At Thu, 19 Apr 2012 14:43:44 +0200, Laurent wrote:
  On Thu, Apr 19, 2012 at 14:33, Matthew Flatt mfl...@cs.utah.edu wrote:
 
   I agree with this: we should add `string-split', the one-argument case
   should be as Eli wrote,
 
 
  About this I'm not sure, as one cannot reproduce this behavior by
 providing
  an argument (or it could make the difference between
 string-as-not-regexps
  and regexps? Wouldn't this be different from other places?).

 I'm suggesting that supplying `#f' as the argument would be the same as
 not supplying the argument.

 It is a special case, though. I don't mind the specialness here,
 because I see the job of `string-split' as making a couple of useful
 special cases easy (as opposed to the generality of `regexp-split').


Then instead of #f one idea is to go one step further and consider
different useful cases based on input symbols like 'whitespaces,
'non-alpha, etc. ? Or even a list of string/symbols that can be used as a
splitter.
That would make a more powerful function for sure. (It's just that I'm
troubled by the uniqueness of this magical default argument)

Laurent





  It would then appear somewhat magical. To me the   default splitter
 seems
  more intuitive.
 
  Laurent
 
 
   and the two-argument case should be as Laurent
   wrote. (Probably the optional second argument should be string-or-#f,
   where #f means to use #px\\s+.)
  
   At Thu, 19 Apr 2012 14:30:31 +0200, Laurent wrote:
 (define (string-split str [sep #px\\s+])
(remove* '() (regexp-split sep str)))

   
Nearly, I meant something more like this:
   
(define (string-split str [splitter  ])
  (regexp-split (regexp-quote splitter) str))
   
No regexp from the user POV, and much easier to use with little
   knowledge.
_
  Racket Developers list:
  http://lists.racket-lang.org/dev
  

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


Re: [racket-dev] `string-split'

2012-04-19 Thread Eli Barzilay
A few minutes ago, Laurent wrote:
 
 Then instead of #f one idea is to go one step further and consider
 different useful cases based on input symbols like 'whitespaces,
 'non-alpha, etc. ? Or even a list of string/symbols that can be used
 as a splitter.  That would make a more powerful function for
 sure. (It's just that I'm troubled by the uniqueness of this magical
 default argument)

(This is something that I do object to...  It leads to srfi-14 which
is one overkill way for that, and we already have regexps that do
that.  So I think that simple is a major point.)

-- 
  ((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] `string-split'

2012-04-19 Thread Eli Barzilay
[Meta-note: I'm not just flatly object to these, just trying to
clarify the exact behavior and the possible effects on other
functions.]

10 minutes ago, Laurent wrote:
  
 
  (define (string-split str [sep #px\\s+])
    (remove* '() (regexp-split sep str)))
 
 Nearly, I meant something more like this:
 
 (define (string-split str [splitter  ])
   (regexp-split (regexp-quote splitter) str))
 
 No regexp from the user POV, and much easier to use with little
 knowledge.

That doesn't seem right -- with this you get

  - (string-split  st  ring)
  '( st  ring)

which is why I think that the above is a better definition in terms of
newbie-ness.


10 minutes ago, Matthew Flatt wrote:
 I agree with this: we should add `string-split', the one-argument case
 should be as Eli wrote, and the two-argument case should be as Laurent
 wrote. (Probably the optional second argument should be string-or-#f,
 where #f means to use #px\\s+.)

Continuing with this line, it seems that a better definition is as
follows:

  (define (string-split str [sep  ])
(remove* '() (regexp-split (regexp-quote (or sep  )) str)))

Except that the full definition could be a bit more efficient.

Three questions:

1. Laurent: Does this make more sense?

2. Matthew: Is there any reason to make the #f-as-default part of the
   interface?  (Even with the new reply I don't see a necessity for
   this -- if the target is newbies, then I think that keeping it as a
   string is simpler...)

3. There's also the point of how this optional argument plays with
   other functions in `racket/string'.  If it works as above, then
   `string-trim' and `string-normalize-spaces' should change
   accordingly so they take the same kind of input simplified
   regexp.

4. Related to Q3: what does xy as that argument mean exactly?
   a. #rx[xy]
   b. #rx[xy]+
   c. #rxxy
   d. #rx(?:xy)+

-- 
  ((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] `string-replace'

2012-04-19 Thread Eli Barzilay
30 minutes ago, Laurent wrote:
 
 I meant this:
 
 (define (string-replace from str to)
    (regexp-replace* (regexp-quote from) str (regexp-replace-quote to)))

30 minutes ago, Matthew Flatt wrote:
 
 Surely Laurent meant
 
(define (string-replace str from to)
  (regexp-replace* (regexp-quote from) str (regexp-replace-quote to)))

(Yes, that was a typo.)

If this is added, then that begs to also have something like[*]

  (define (string-index-of sub str [start 0] [end (string-length str)])
(define m (regexp-match-positions (regexp-quote sub) str start end))
(and m (caar m)))

?  If so, then what should it be called?



([*] untested, more typos possible.)

-- 
  ((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] `string-split'

2012-04-19 Thread Laurent
Continuing with this line, it seems that a better definition is as
 follows:

  (define (string-split str [sep  ])
(remove* '() (regexp-split (regexp-quote (or sep  )) str)))

 Except that the full definition could be a bit more efficient.

 Three questions:

 1. Laurent: Does this make more sense?


Yes, this definitely makes more sense to me.
It would then treat (string-split aXXby X) just like the   case.

Although if you want to find the columns of a latex line like x  y  z
you will have the wrong result.
Maybe use an optional argument to remove the empty strings? (not sure)


 2. Matthew: Is there any reason to make the #f-as-default part of the
   interface?  (Even with the new reply I don't see a necessity for
   this -- if the target is newbies, then I think that keeping it as a
   string is simpler...)


There is probably no need for #f with the new spec.

4. Related to Q3: what does xy as that argument mean exactly?
   a. #rx[xy]
   b. #rx[xy]+
   c. #rxxy
   d. #rx(?:xy)+


Good question. d. would be the simplest case for newbies, but b. might be
more useful.
I think several other languages avoid this issue by using only one
character as the separator.

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


[racket-dev] Argument positions of string-... like functions

2012-04-19 Thread Laurent
   (define (string-index-of sub str [start 0] [end (string-length str)])


I always need to go check the documentation for that kind of argument
position (like for (string-replace from str to) ).
To me, what makes more sense is to have the str argument on the first
position, just like for a method call with a self argument, which makes
sense for strings on functions like string-
Does it bother other people too?

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


Re: [racket-dev] Argument positions of string-... like functions

2012-04-19 Thread Eli Barzilay
A few minutes ago, Laurent wrote:
   (define (string-index-of sub str [start 0] [end (string-length str)])
 
 I always need to go check the documentation for that kind of argument position
 (like for (string-replace from str to) ).
 To me, what makes more sense is to have the str argument on the first
 position, just like for a method call with a self argument, which makes sense
 for strings on functions like string-
 Does it bother other people too?

(I was about to suggest the same thing.  The `string-replace' not
following `regexp-replace's order is the bad point here.)

-- 
  ((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] `string-split'

2012-04-19 Thread Laurent

 4. Related to Q3: what does xy as that argument mean exactly?
   a. #rx[xy]
   b. #rx[xy]+
   c. #rxxy
   d. #rx(?:xy)+


 Good question. d. would be the simplest case for newbies, but b. might be
 more useful.


It would make more sense that a string really is a string, not a set of
characters.
Without going as far as srfi-14, a set could be a list of strings or
characters, but maybe this is not needed.

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


Re: [racket-dev] `string-split'

2012-04-19 Thread Eli Barzilay
Just now, Laurent wrote:
 1. Laurent: Does this make more sense?
 
 Yes, this definitely makes more sense to me.  It would then treat
 (string-split aXXby X) just like the   case.
 
 Although if you want to find the columns of a latex line like x 
 y  z you will have the wrong result.  Maybe use an optional
 argument to remove the empty strings? (not sure)

(This complicates things...)

First, I don't think that there's a need to make it able to do stuff
like that -- either you go with regexps, or you use combinations like

  (map string-trim (string-split x  y  z ))


 4. Related to Q3: what does xy as that argument mean exactly?
   a. #rx[xy]
   b. #rx[xy]+
   c. #rxxy
   d. #rx(?:xy)+
 
 Good question. d. would be the simplest case for newbies, but
 b. might be more useful.  I think several other languages avoid this
 issue by using only one character as the separator.

The complication is that with   or  \t it seems that you'd want b,
and with  you'd want c.  (Maybe even make  equivalent to
#rx * * -- that looks like it's too much guessing.)

And you're also making a point for:

  e. Throw an error, must be a single-character string.

BTW, this question is important because it affects other functions, so
I'd like to resolve it before doing anything.

-- 
  ((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] Pre-Release Checklist for v5.3

2012-04-19 Thread Doug Williams
All of the plot routines work as expected.

Done

Doug

On Wednesday, April 18, 2012, Ryan Culpepper wrote:

 Checklist items for the v5.3 release
  (using the v5.2.901.1 release candidate build)

 Search for your name to find relevant items, reply when you finish an
 item (please indicate which item/s is/are done).  Also, if you have any
 commits that should have been picked, make sure that the changes are in.

 Important: new builds are created without announcement, usually whenever
 I pick a few commits.  If you need to commit changes, please make sure
 you tell me to pick it into the release branch.

 -- Release candidates are at
 --   
 http://pre.racket-lang.org/**release/installershttp://pre.racket-lang.org/release/installers

 Please use these installers (or source bundles) -- don't test from
 your own git clone (don't test v5.3.0.1 by mistake!).  To get
 the tests directory in such a directory, you can do this:
  cd ...racket-root...
  git archive 
 --remote=git://git.racket-**lang.org/plt.githttp://git.racket-lang.org/plt.gitrelease
  \
  -- collects/tests | tar x

 --**--**--

 * Matthew Flatt mfl...@cs.utah.edu
  - Racket Tests
  - Languages Tests
  - GRacket Tests (Also check that `gracket -z' and `gracket-text' still
works in Windows and Mac OS X)
  - mzc --exe tests
  - .plt-packing Tests
  - Games Tests
  - Unit Tests
  - Syntax Color Tests
  - R6RS Tests
  - JPR's test suite
  - Create an executable from a BSL program
  - Run COM tests
  - Try compiling with -funsigned-char
  Updates:
  - Racket Updates: update HISTORY
  (updates should show v5.3 as the most current version)
  - Update man pages in racket/man/man1: racket.1, gracket.1, raco.1
  Email me to pick the changes when they're done, or tell me if there
  are no such changes.

 * Robby Findler ro...@eecs.northwestern.edu
  - DrRacket Tests
  - Framework Tests
  - Contracts Tests
  - Games Tests
  - Teachpacks Tests: image tests
  - PLaneT Tests
  - Redex Tests
  Updates:
  - DrRacket Updates: update HISTORY
  - Redex Updates: update HISTORY
  (updates should show v5.3 as the most current version)
  - Ensure that previous version of DrRacket's preference files still
starts up with new DrRacket
  - Update man pages in racket/man/man1: drracket.1
  Email me to pick the changes when they're done, or tell me if there
  are no such changes.

 * John Clements cleme...@brinckerhoff.org
  - Stepper Tests
  Updates:
  - Stepper Updates: update HISTORY
  (updates should show v5.3 as the most current version; email me
  to pick the changes when they're done, or tell me if there are no such
  changes.)

 * Sam Tobin-Hochstadt sa...@ccs.neu.edu,
   Vincent St-Amour stamo...@ccs.neu.edu
  - Match Tests
  - Typed Racket Tests
  - Typed Racket Updates: update HISTORY
  (updates should show v5.3 as the most current version; email me
  to pick the changes when they're done, or tell me if there are no such
  changes.)

 * Matthias Felleisen matth...@ccs.neu.edu
  - Teachpacks Tests: check that new teachpacks are addable
  - Teachpack Docs: check teachpack docs in the bundles
  Updates:
  - Teachpack Updates: update HISTORY
  (updates should show v5.3 as the most current version; email me
  to pick the changes when they're done, or tell me if there are no such
  changes.)

 * Ryan Culpepper r...@cs.utah.edu
  - Macro Debugger Tests
  - Syntax Classifier Tests
  - RackUnit GUI Tests
  - Data Tests
  - DB Tests

 * Jay McCarthy jay.mccar...@gmail.com
  - Web Server Tests
  - XML Tests
  - HTML Tests
  - PLAI Tests
  - Racklog tests
  - Datalog tests

 * Kathy Gray kathryn.g...@cl.cam.ac.uk
  - Test Engine Tests

 * Noel Welsh noelwe...@gmail.com
  - Rackunit Tests
  - SRFI Tests
  - Ensure that all claimed srfi's are in the installer and they all
load into racket or drracket (as appropriate)

 * Stevie Strickland sstri...@ccs.neu.edu
  - Unit Contract Tests
  - Contract Region Tests

 * Stephen Chang stch...@ccs.neu.edu
  - Lazy Racket Tests
  - Lazy stepper tests

 * Eli Barzilay e...@barzilay.org
  - Swindle Tests
  - XREPL Tests
  - Racket Tree: compare new distribution tree to previous one
  - Run the unix installer tests
  Version Updates: if a major change has happened, update the version
  number in:
  - racket/collects/mzscheme/info.**rkt
  - racket/collects/mred/info.rkt

 * Stephen Bloch sbl...@adelphi.edu
  - Picturing Programs Tests

 * Greg Cooper g...@cs.brown.edu
  - FrTime Tests

 * Carl Eastlund c...@ccs.neu.edu
  - Dracula Tests (confirm that Dracula runs from PLaneT)

 * Jon Rafkind rafk...@cs.utah.edu
  Release tests for (one of the) linux releases:
  - Test that the `racket' and `racket-textual' source releases
compile fine (note that they're still called `plt' and `mz' at
this stage).
  - Test that the binary installers for both work, try each one in
both normal and unix-style installation modes. (just ubuntu)
  [Note: get the release 

Re: [racket-dev] `string-split'

2012-04-19 Thread Eli Barzilay
An hour and a half ago, Ryan Culpepper wrote:
 Instead of trying to design a 'string-split' that is both
 miraculously intuitive and profoundly flexible, why not design it
 like a Model-T

Invalid analogy: the issue is not flexibility, it's making something
that is simple (first) and useful (second) in most cases.


An hour and a half ago, Michael W wrote:
 (TL;DR: I'd suggest two functions: one (string-words str) function
 that does Eli's way, and one (string-split str sep) that does it
 Laurent's way).

I don't think that we argued on what it should do, rather it looks
like we're both looking for whatever option looks best...


- (string-split  st  ring)
'( st  ring)
  
  which is why I think that the above is a better definition in terms of
  newbie-ness.
 
 No, every other language I've worked with does that.
 [...]

The examples you're quoting are the equivalents of our `regexp-split',
which works in a similar way and is not going to change.  We're
talking about some watered-down version that is easier to use.


Just now, Laurent wrote:
 (TL;DR: I'd suggest two functions: one (string-words str)
 function that does Eli's way, and one (string-split str sep)
 that does it Laurent's way).
 
 That would be a good option to me, considering that my way is with
 remaining s in the output list.  The question remains if a string
 can be accepted for sep, in which case the empty string must be
 considered, as pointed out in the Lua discussion. Though a single
 char should be sufficient for nearly all simple cases.

I think that I have a good conclusion here, I'll post on a new thread.

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


[racket-dev] `racket/string' extensions

2012-04-19 Thread Eli Barzilay
Sorry for the new thread, but this is a kind of a summary on the
extensions that I think we're converging to, with a way to resolve the
exact meaning of arguments.  Please read through and reply if you see
any problems with it.  There are three specific questions, which are
marked with [*1*]...[*3b*] -- I'd appreciate suggestions for them.


Starting with the problem of the argument, I think that the best
choice is to go with plain ones -- no implicit `+', and no strings as
bags of characters.  (This is option (c) in the other thread.)

Two rationales:

  * These functions are supposed to be simple, so a simple rule like
that works nicely to that end.

  * Uses strings for what they are: an ordered sequence of characters.
Going with a bag-of-characters is really abusing the string type.
Adding an implicit `+' is complicating things since it interprets
a string as a kind of a pattern.

But to allow other uses, make these arguments a string *or* a regexp,
where a regexp is taken as-is.  This leads to another simplicity point
in this design:

  * These functions are mostly similar to the regexp ones, except that
the implicit coercion from a string to a pattern happens with
`regexp-quote' rather than with `regexp'.

It also means that when you want something that is not a plain string,
you just use a regexp.  This doesn't necessarily goes back to the full
regexp versions with the implied complexity.  A few examples:

  * The default argument for a pattern that serves as a separator (as
in `string-trim' and `string-split') is a regexp: #px\\s+.  So
newbies get to use them without learning them.

  * If there's a need for something different in the future, say one
or more spaces and tabs, then making regexps a valid input means
that we could add a binding for such regexps, so newbies can now
do something like:

  (string-split string spaces-or-tabs)

and still not worry about regexps.

  * Even if there's some obvious need for the bag-of-chars thing, it
could be added as a function:

  (string-split string (either   \t))

Note that I'm not suggesting adding these last two items -- I'm just
saying that accepting regexps means that such extensions are easier to
do in the future.


The suggested functions are (these are skeletons, they'll also have
keyword arguments for some more tweaks):

  (string-trim str [sep #px\\s+])
Removes occurrences of `sep' from the beginning and end of `str'.
(Keywords can make it do only one side.)  This is already
implemented (but not pushed).  I will need to change it though, in
subtle ways due to the new meaning of the `sep' argument.

  (string-normalize-spaces str [sep #px\\s+])
Replaces occurrences of `sep' with a space, trimming it at the
edges.  (Keywords can disable the trimming, and can make it use a
different character to substitute.)  This is also already
implemented but will need to change in subtle ways as the last
one.

  (string-split str [sep #px\\s+])
Splits `str' on occurrences of `sep'.  Unclear whether it should
do that with or without trimming, which affects keeping a
first/last empty part.  [*1*] Possible solution: make it take a
`#:trim?' keyword, in analogy to `string-normalize-spaces'.  This
would make `#t' the obvious choice for a default, which means that
  (string-split ,,foo, bar, ,) - '(foo  bar)

  (string-replace str from to [start 0] [end (string-length str)])
Simple wrapper that quotes the `from' and `to'.  Note the
different order argument which is supposed to make this be more
like common functions.  Another rationale for this difference:
these functions focus on the string, rather than on the regexp.

  (string-index str sub [start 0] [end (string-length str)])
Looks for occurrences of `sub' in `str', returns the index if
found, #f otherwise.  [*2*] I'm not sure about the name, maybe
`string-index-of' is better?

  (list-index list elt)
Looks for `elt' in `list'.  This is a possible extension for
`racket/list' that would be kind of obvious with adding the above.
[*3*] I'm not sure if it should be added, but IIRC it was
requested a few times.  If it does get added, then there's another
question for how far the analogy goes: [*3a*] Should it take a
start/end index too?  [*3b*] Should it take a list of elements and
look for a matching sublist instead (which is not a function that
is common to ask for, AFAICT)?

-- 
  ((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] `racket/string' extensions

2012-04-19 Thread Laurent
I like it a lot.

[...]

  (string-split str [sep #px\\s+])
Splits `str' on occurrences of `sep'.  Unclear whether it should
do that with or without trimming, which affects keeping a
first/last empty part.  [*1*] Possible solution: make it take a
`#:trim?' keyword, in analogy to `string-normalize-spaces'.  This
would make `#t' the obvious choice for a default, which means that
  (string-split ,,foo, bar, ,) - '(foo  bar)


A keyword might be a good idea indeed.


  (list-index list elt)
Looks for `elt' in `list'.  This is a possible extension for
`racket/list' that would be kind of obvious with adding the above.
[*3*] I'm not sure if it should be added, but IIRC it was
requested a few times.  If it does get added, then there's another
question for how far the analogy goes: [*3a*] Should it take a
start/end index too?  [*3b*] Should it take a list of elements and
look for a matching sublist instead (which is not a function that
is common to ask for, AFAICT)?


Or should it take a comparison operator (e.g., defaulting to equal?) ?
Maybe list-index could be simple (considering the list flat), and
list-index* could return a list of positions in the sublists?
E.g., (list-index* '(a (b (c d) e) f) 'c) - '(1 1 0)
(list-index* '(a (b (c d) e) f) '(c d)) - '(1 1)

Btw, from time to time I wish that `remove*' accepted a single element that
is not a list.
I find it a bit cumbersome and not good looking to wrap a single value in a
(list ...).
Since modifying remove* would probably break a few things, maybe a remove+ ?

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


Re: [racket-dev] `racket/string' extensions

2012-04-19 Thread namekuseijin
On Thu, Apr 19, 2012 at 1:28 PM, Eli Barzilay e...@barzilay.org wrote:
  (list-index list elt)
    Looks for `elt' in `list'.  This is a possible extension for
    `racket/list' that would be kind of obvious with adding the above.
    [*3*] I'm not sure if it should be added, but IIRC it was
    requested a few times.

those who requested are not aware of member.

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


Re: [racket-dev] pr 12683 and using something like text:nbsp-space?

2012-04-19 Thread Danny Yoo
On Thu, Apr 12, 2012 at 5:26 PM, Robby Findler
ro...@eecs.northwestern.edu wrote:
 Yes, normalization doesn't deal with those spaces. It does change the
 text in ways that are unfriendly and I often tell DrRacket no when
 it asks about normalization. I just wanted to put that into the mix
 for this conversation, since it is a place that has to deal with
 similar issues.


I propose a backtrack my current patch, and instead to do the following:

---

* Add a set of choices in the editor Preferences pane, with the
following options:

Treatment of Unicode zero-width characters (such as zero-width spaces):

1. Preserve them.
2. When introduced, prompt a dialog choice to delete them.
3. Automatically delete them.

with the default preference to be option 2.


* Collect the set of zero-width characters.  Zero-width spaces, of
course, but also see what other Unicode characters exhibit similar
weird behavior.


* Develop a mixin class specific to DrRacket (outside the framework)
to implement this behavior.


---

Does that sound right with everyone?
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] More low-level submodule questions, and changelog improvements?

2012-04-19 Thread Matthew Flatt
At Wed, 18 Apr 2012 14:41:46 -0400, Danny Yoo wrote:
  I'm trying to wrap my head around submodules so I can get it working
  with Whalesong
 
 
 I see that the structure of 'mod' has changed a bit to accommodate
 submodules; in particular, mod-name can now be a list of symbols vs
 just a symbol, comparing:
 
 
 http://docs.racket-lang.org/raco/decompile.html#(def._((lib._compiler/zo-structs
 ..rkt)._mod-srcname))
 
 vs:
 
 http://pre.racket-lang.org/docs/html/raco/decompile.html#(def._((lib._compiler/z
 o-structs..rkt)._mod-srcname))
 
 
 Is it guaranteed that if mod-name is a list, it's a list of at least
 two symbols?

Yes. I see that contracts promise only a non-empty list, so I'll fix
that.

 I see the mod-pre-submodules and mod-post-submodules fields in the mod
 structure.  Those are the only changes I can see from:
 
 $ git diff v5.2.1 origin/release zo-structs.rkt
 
 
 I guess the runtime things I need to be careful about now are the
 changed semantics to resolved-module-paths.  Are there other changes I
 should pay particular attention to?

If you have a module name resolver or `load/use-compiled' handler,
the protocol for those changed slightly, too.

 Aside: it's times like these where I wish there was an extensive
 Racket summary document [...]

 In contrast, the document I'd like to see should be a guide that helps
 me migrate code.  It should document changes in the runtime behavior
 of core library functions, e.g. the change in what resolved module
 paths mean is implied by submodules.
 
 I do remember that there used to be a Changelog document that
 described the changes per release, but I can't find it from the
 racket-lang.org web site.  From my memory, it didn't fulfill this
 migration role either.

The change log is

 doc/release-notes/racket/HISTORY.txt

and we try to keep it up-to-date with compatibility issues. I see that
it's missing the change to resolved module paths, though, which is a
serious omission that I'll fix.

You can get to the release notes from the documentation page by
following the Release Notes link on the left of the page, and then
the Racket core link.

The change log is not the more extensive prose description that you'd
prefer, though. At best, it's a list of alerts for updated
documentation that you should check. I would like to do better, but I
can't promise any more in the near future.

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


Re: [racket-dev] Is this legal submodule code?

2012-04-19 Thread Matthew Flatt
I've pushed a repair for this bug.

At Wed, 18 Apr 2012 13:02:05 -0400, Danny Yoo wrote:
 I'm trying to wrap my head around submodules so I can get it working
 with Whalesong, but I'm running into an issue:
 
 #lang racket
 
 (define (print-cake n)
   #;(show~an #\.)
   #;(show  .-~a-.  n #\|)
   #;(show  | ~a |  n #\space)
   (show ---~a--- n #\-))
 
 (define (show fmt n ch)
   (printf fmt (make-string n ch))
   (newline))
 
 (module* main2 #f
   (print-cake 20)
 
   (module* inner-main #f
   (print-cake 20)))
 
 
 
 I'm trying to understand what it means for the name of a module to
 be a list, and I expect the name of the inner-main module to be (cake
 main2 inner-main).  Is that right?
 
 
 But I see the following error message when trying to run this under DrRacket:
 
 
 ##
 Welcome to DrRacket, version 5.2.901.1--2012-04-18(7279b02/g) [3m].
 Language: racket.
 . . local/racket/collects/errortrace/errortrace-lib.rkt:434:2:
 standard-module-name-resolver: too many ..s in submodule path:
 (submod (quote cake) ..)
 ##
 
 
 
 I don't know enough about submodules yet to know if this is a bug or
 I'm just doing something wrong.
 _
   Racket Developers list:
   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] `racket/string' extensions

2012-04-19 Thread David Vanderson
Thank you so much for this.  This was definitely one area of difficulty 
when I started using Racket for scripting.


On 04/19/2012 09:28 AM, Eli Barzilay wrote:

But to allow other uses, make these arguments a string *or* a regexp,
where a regexp is taken as-is.  This leads to another simplicity point
in this design:


This is fantastic.

   (string-split str [sep #px\\s+])
 Splits `str' on occurrences of `sep'.  Unclear whether it should
 do that with or without trimming, which affects keeping a
 first/last empty part.  [*1*] Possible solution: make it take a
 `#:trim?' keyword, in analogy to `string-normalize-spaces'.  This
 would make `#t' the obvious choice for a default, which means that
   (string-split ,,foo, bar, ,) -  '(foo  bar)
I like the #:trim? keyword, but I would suggest defaulting to #f.  Many 
of my uses of string-split would be doing simple parsing of delimited 
input, and it seems to me that trimming by default would be non-obvious.

   (string-index str sub [start 0] [end (string-length str)])
 Looks for occurrences of `sub' in `str', returns the index if
 found, #f otherwise.  [*2*] I'm not sure about the name, maybe
 `string-index-of' is better?

Either sounds fine, so I'd go with string-index just because it's shorter.

   (list-index list elt)
 Looks for `elt' in `list'.  This is a possible extension for
 `racket/list' that would be kind of obvious with adding the above.
 [*3*] I'm not sure if it should be added, but IIRC it was
 requested a few times.  If it does get added, then there's another
 question for how far the analogy goes: [*3a*] Should it take a
 start/end index too?  [*3b*] Should it take a list of elements and
 look for a matching sublist instead (which is not a function that
 is common to ask for, AFAICT)?


How do people do this now?


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


Re: [racket-dev] Is this legal submodule code?

2012-04-19 Thread Danny Yoo
On Thu, Apr 19, 2012 at 2:45 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
 I've pushed a repair for this bug.


Ah, thank you!  I will try it out as soon as it hits the 5.3 release branch.
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] pr 12683 and using something like text:nbsp-space?

2012-04-19 Thread Eli Barzilay
An hour ago, Danny Yoo wrote:
 On Thu, Apr 12, 2012 at 5:26 PM, Robby Findler
 ro...@eecs.northwestern.edu wrote:
  Yes, normalization doesn't deal with those spaces. It does change
  the text in ways that are unfriendly and I often tell DrRacket
  no when it asks about normalization. I just wanted to put that
  into the mix for this conversation, since it is a place that has
  to deal with similar issues.
 
 I propose a backtrack my current patch, and instead to do the
 following:
 
 ---
 
 * Add a set of choices in the editor Preferences pane, with the
   following options:
 
 Treatment of Unicode zero-width characters (such as zero-width spaces):
 
 1. Preserve them.
 2. When introduced, prompt a dialog choice to delete them.
 3. Automatically delete them.
 
 with the default preference to be option 2.

I see some problems here that need to be addressed.

The first problem is the definition of zero-width characters: some
of these are not problematic -- for example, #\u05B0 is something that
gets added to a letter so it doesn't have its own width.  OTOH, there
are many other sources of confusion that are not at all related to
width, like #\u0392 which is usually even displayed using the same B
character so there's no visual difference.

The second problem is the thir option offering to just delete them.
Since I view a proper solution as something that can deal with all
of these problems, plain deletion is obviously not always the right
solution.

The third problem is something that I already mentioned: even if both
of the above points are addressed, what if I choose #3 because it
seems like an easy way to avoid such problems, and later I get bitten
when I paste some text with an intention of keeping these things in?
There's no way to avoid it by saying that it's only a few people who
would run into these things -- since these people are exactly the kind
of people who are likely to suffer these results.  (IOW, if I deal
with weird texts, I'm likely to get nagged a lot and choose #3, and
I'm also likely to want these things in strings.)

So I think that this should be revised as follows:

1. Drop the whole zero-width, and instead just use something that
   indicates potentially confusing.  (I'm surprised that this thread
   keeps focusing on just zero-width spaces.)

2. Change #2 to some form of normalization.  (That's a bad term
   since it has a specific sense, but I'm sure that there's some term
   somewhere for these kind of changes.)

3. Remove option #3.

Alternatively: add a display mode that spells out all of the fishy
characters, as done in Emacs when you open a file in literal mode.


 * Collect the set of zero-width characters.  Zero-width spaces, of
 course, but also see what other Unicode characters exhibit similar
 weird behavior.

(I completely agree with this -- the list of these things will grow;
only not restricted to zero-width-ness.)

-- 
  ((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] pr 12683 and using something like text:nbsp-space?

2012-04-19 Thread Robby Findler
I think this is the kind of mixin that belongs in the framework and, if you
don't want it, you don't mix it in.

The preferences dialog additions could be DrRacket-specific, tho.

Also, option 2 should probably have a button in the dialog that adjusts the
preference to one of the two silent modes.

Robby

On Thursday, April 19, 2012, Eli Barzilay wrote:

 An hour ago, Danny Yoo wrote:
  On Thu, Apr 12, 2012 at 5:26 PM, Robby Findler
  ro...@eecs.northwestern.edu javascript:; wrote:
   Yes, normalization doesn't deal with those spaces. It does change
   the text in ways that are unfriendly and I often tell DrRacket
   no when it asks about normalization. I just wanted to put that
   into the mix for this conversation, since it is a place that has
   to deal with similar issues.
 
  I propose a backtrack my current patch, and instead to do the
  following:
 
  ---
 
  * Add a set of choices in the editor Preferences pane, with the
following options:
 
  Treatment of Unicode zero-width characters (such as zero-width
 spaces):
 
  1. Preserve them.
  2. When introduced, prompt a dialog choice to delete them.
  3. Automatically delete them.
 
  with the default preference to be option 2.

 I see some problems here that need to be addressed.

 The first problem is the definition of zero-width characters: some
 of these are not problematic -- for example, #\u05B0 is something that
 gets added to a letter so it doesn't have its own width.  OTOH, there
 are many other sources of confusion that are not at all related to
 width, like #\u0392 which is usually even displayed using the same B
 character so there's no visual difference.

 The second problem is the thir option offering to just delete them.
 Since I view a proper solution as something that can deal with all
 of these problems, plain deletion is obviously not always the right
 solution.

 The third problem is something that I already mentioned: even if both
 of the above points are addressed, what if I choose #3 because it
 seems like an easy way to avoid such problems, and later I get bitten
 when I paste some text with an intention of keeping these things in?
 There's no way to avoid it by saying that it's only a few people who
 would run into these things -- since these people are exactly the kind
 of people who are likely to suffer these results.  (IOW, if I deal
 with weird texts, I'm likely to get nagged a lot and choose #3, and
 I'm also likely to want these things in strings.)

 So I think that this should be revised as follows:

 1. Drop the whole zero-width, and instead just use something that
   indicates potentially confusing.  (I'm surprised that this thread
   keeps focusing on just zero-width spaces.)

 2. Change #2 to some form of normalization.  (That's a bad term
   since it has a specific sense, but I'm sure that there's some term
   somewhere for these kind of changes.)

 3. Remove option #3.

 Alternatively: add a display mode that spells out all of the fishy
 characters, as done in Emacs when you open a file in literal mode.


  * Collect the set of zero-width characters.  Zero-width spaces, of
  course, but also see what other Unicode characters exhibit similar
  weird behavior.

 (I completely agree with this -- the list of these things will grow;
 only not restricted to zero-width-ness.)

 --
  ((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] Pre-Release Checklist for v5.3

2012-04-19 Thread John Clements

On Apr 18, 2012, at 8:00 AM, Ryan Culpepper wrote:

 Checklist items for the v5.3 release
  (using the v5.2.901.1 release candidate build)

I'm confused by the OS X download options on the pre-release download page 
(http://pre.racket-lang.org/release/installers/).

Specifically, one of the entries is labelled

Mac OS X (32-bit 64-bit)

I'm guessing this was supposed to be

Mac OS X (Intel 64-bit)

?

Apologies if I've missed discussion of this elsewhere.

John



smime.p7s
Description: S/MIME cryptographic signature
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] current head doesn't compile?

2012-04-19 Thread Matthew Flatt
I've pushed a fix.

At Thu, 19 Apr 2012 16:55:10 -0700, John Clements wrote:
 Apologies in advance if this is my fault; I can't see an obvious reason why 
 it 
 would be.
 
 I'm building from the head, and I rm'ed my build directory, and I get a build 
 failure that ends with:
 
 Compiling xform support...
 default-load-handler: cannot open input file: 
 /Users/clements/plt/src/build/racket/gc2/xform-collects/scheme/base.rkt (No 
 such file or directory; errno=2)
 
  === context ===
 standard-module-name-resolver
 /Users/clements/plt/src/racket/gc2/xform.rkt:95:24
 /Users/clements/plt/src/racket/gc2/xform.rkt: [running body]
 
 make[4]: *** [xsrc/precomp.h] Error 1
 make[3]: *** [all] Error 2
 make[2]: *** [3m] Error 2
 make[1]: *** [3m] Error 2
 make: *** [all] Error 2
 pcp074113pcs:~/plt/src/build clements$ 
 
 
 I checked the list of copy commands that precede this, and sure enough, 
 there's no line corresponding to a copy of collects/scheme/base.rkt. So… 
 there's a missing copy? I took a brief look at src/racket/gc2/setup.rkt, but 
 I 
 didn't see an obvious fix. :) I've attached the full text of the build.
 
 Again, apologies if this is my fault.
 
 Ooh… just looked at git log, perhaps this has something to do with 
 2b76d9e5b03ea97b8de155d2dda63e64256a3212 ?
 
 John 
 
 
 
 
 --
 [text/plain foo.txt] [~/Desktop  open] [~/Temp  open]
 
 --
 [application/pkcs7-signature smime.p7s] [~/Desktop  open] [~/Temp  open]
 _
   Racket Developers list:
   http://lists.racket-lang.org/dev

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


Re: [racket-dev] current head doesn't compile?

2012-04-19 Thread Eli Barzilay
Just now, Matthew Flatt wrote:
 I've pushed a fix.
 
 At Thu, 19 Apr 2012 16:55:10 -0700, John Clements wrote:
  Ooh… just looked at git log, perhaps this has something to do with 
  2b76d9e5b03ea97b8de155d2dda63e64256a3212 ?

Yes, it was my fault.  (I didn't try to build from scratch, so I
didn't see that problem.)

-- 
  ((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] Pre-Release Checklist for v5.3

2012-04-19 Thread Eli Barzilay
Three hours ago, John Clements wrote:
 
 Mac OS X (32-bit 64-bit)
 
 I'm guessing this was supposed to be
 
 Mac OS X (Intel 64-bit)

Yes, that was a typo.

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


[racket-dev] Seg Fault in GC with Pre-Release Racket

2012-04-19 Thread Williams, Doug
I have downloaded the latest pre-release for v5.3
(plt-5.2.901.1-bin-i386-win32.exe). All of my PLaneT collections load
and run fine. But, my large application at work fails to run - it dies
during startup with Seg Fault (internal error during gc) at 58720044
printed (twice) in a new window. It's running under Windows XP.  I've
attached a screen shot of the Visual Studio debugger error window with
slightly more information. Let me know if there is anything else I can
provide.

 

Doug

 

attachment: 4-19-2012 8-26-23 AM.png_
  Racket Developers list:
  http://lists.racket-lang.org/dev