Re: [racket-dev] Pre-Release Checklist for v5.3
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?
(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?
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'
[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'
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'
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'
(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'
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'
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'
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'
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'
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'
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'
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'
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'
[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'
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'
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
(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
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'
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'
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
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'
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
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
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
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?
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?
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?
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
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?
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?
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?
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
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?
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?
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
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
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
