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

[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

 

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

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

[Stephen Chang]

> * Stephen Chang 
>  - Lazy Racket Tests
>  - Lazy stepper tests

All passed.

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

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

[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

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

[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] current head doesn't compile?

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

[John Clements]

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

> * John Clements 
>  - 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.)

Done.

John



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

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

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

[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
> > > 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?

[Eli Barzilay]

An hour ago, Danny Yoo wrote:
> On Thu, Apr 12, 2012 at 5:26 PM, Robby Findler
>  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] Is this legal submodule code?

[Danny Yoo]

On Thu, Apr 19, 2012 at 2:45 PM, Matthew Flatt  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] `racket/string' extensions

[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?

[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 "   ~a   " n #\.)
>   #;(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] Pre-Release Checklist for v5.3

[Michael Sperber]

Ryan Culpepper  writes:

> * Mike Sperber 
>   - DMdA Tests
>   - Stepper Tests
>   - Signature Tests

Done.

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

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

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

[Danny Yoo]

On Thu, Apr 12, 2012 at 5:26 PM, Robby Findler
 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] `racket/string' extensions

[namekuseijin]

On Thu, Apr 19, 2012 at 1:28 PM, Eli Barzilay  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] `racket/string' extensions

[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

[racket-dev] `racket/string' extensions

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

[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

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

[Laurent]

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

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

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

[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/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.gitrelease
>  \
>  -- collects/tests | tar x
>
> --**--**--
>
> * Matthew Flatt 
>  - 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 
>  - 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 
>  - 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 ,
>   Vincent St-Amour 
>  - 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 
>  - 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 
>  - Macro Debugger Tests
>  - Syntax Classifier Tests
>  - RackUnit GUI Tests
>  - Data Tests
>  - DB Tests
>
> * Jay McCarthy 
>  - Web Server Tests
>  - XML Tests
>  - HTML Tests
>  - PLAI Tests
>  - Racklog tests
>  - Datalog tests
>
> * Kathy Gray 
>  - Test Engine Tests
>
> * Noel Welsh 
>  - 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 
>  - Unit Contract Tests
>  - Contract Region Tests
>
> * Stephen Chang 
>  - Lazy Racket Tests
>  - Lazy stepper tests
>
> * Eli Barzilay 
>  - 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 
>  - Picturing Programs Tests
>
> * Greg Cooper 
>  - FrTime Tests
>
> * Carl Eastlund 
>  - Dracula Tests (confirm that Dracula runs from PLaneT)
>
> * Jon Rafkind 
>  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 candidates from the URL in this email. Use
>   the 'static table' link to see a list of all tar files available]
>
> * Mike Sperber 
>  - DMdA Tests
>  - Stepper Tests
>  - Signature Te

Re: [racket-dev] my bf language no longer works; how to fix?

[Matthew Flatt]

At Wed, 18 Apr 2012 15:40:09 -0400, Danny Yoo wrote:
> On Wed, Apr 18, 2012 at 3:09 PM, Danny Yoo  wrote:
> > This no longer appears to work in 5.3:
> >
> >    #lang planet dyoo/bf
> >    ,[.,]
> >
> > I'm not sure how to fix this.  Help?  I see the following error message:
> 
> 
> Ok, bug traced.  It looks like module-declared? is being used like
> this in the context of parsing a program in the bf PLaneT language:
> 
> (module-declared? '(submod (planet dyoo/bf) reader) #t)
> 
> At this point, the standard module name resolver raises an error on
> behalf of the module-declared? function.

I've pushed a fix.

> From reading the documentation on module-declared?, I thought that it
> wasn't supposed to raise exceptions when given non-existant modules.
> But module-declared? raises an error when given other junk module
> names.  Is it supposed to do so? 
> For example:
> 
> 
> > (module-declared? 'blah #f)
> (module-declared? 'blah #f)
> standard-module-name-resolver: collection not found: "blah" in any of:
> (#
> #)
> 

It's only supposed to refrain from complaining for submodule paths
where the root module doesn't exist. It will still complain for bad
collection names, bad planet packages, or non-submodule paths; I'll
make a note to clarify in the docs.


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

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

[Michael W]

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

50 minutes ago, Eli Barzilay wrote:
> 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.

No, every other language I've worked with does that.

$ python
Python 3.2.2 (default, Nov 21 2011, 16:51:01) 
[GCC 4.6.2] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> " st  ring".split(" ")
['', 'st', '', 'ring']


$ node
> " st  ring".split(" ")
[ '', 'st', '', 'ring' ]


$ php -a
php > var_dump(split(" ", " str  ing"));
array(4) {
  [0]=>
  string(0) ""
  [1]=>
  string(3) "str"
  [2]=>
  string(0) ""
  [3]=>
  string(3) "ing"
}

Haskell uses two functions; one which eliminates contiguous runs
and one which doesn't (and comes from an entire external library,
sheesh! though it's easy to write your own):
$ ghci
Prelude> words " str  ing"
["str","ing"]
Prelude> Data.List.Split.splitOn " "  " str  ing"
["","str","","ing"]


Ruby has the weirdest behavior, which I consider to be a bug:

$ irb
irb(main):001:0> " st  ring".split(" ")
=> ["st", "ring"]
irb(main):002:0> " st  ring".split(/ /)
=> ["", "st", "", "ring"]

The ruby docs say:
http://www.ruby-doc.org/core-1.9.3/String.html
If pattern is a String, then its contents are used as the
delimiter when splitting str. If pattern is a single space, str
is split on whitespace, with leading whitespace and runs of
contiguous whitespace characters ignored.
If pattern is a Regexp, str is divided where the pattern matches.
Whenever the pattern matches a zero-length string, str is split
into individual characters. If pattern contains groups, the
respective matches will be returned in the array as well.

In looking for Lua (which doesn't include one, by the way), I
found http://lua-users.org/wiki/SplitJoin which has a big summary
of the issues.

-- 
For the Future!
_mike
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

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

[Ryan Culpepper]

Instead of trying to design a 'string-split' that is both miraculously 
intuitive and profoundly flexible, why not design it like a Model-T and 
then write a guide/cookbook for how to use regexps to do all of the 
common cases that the extremely limited 'string-split' doesn't handle?


I suspect that writing such a guide will expose a few cases where common 
patterns can be turned into functions (similar to 'regexp-replace-quote').


Ryan


On 04/19/2012 07:27 AM, Eli Barzilay wrote:

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. #rx"xy"
   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.



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

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

[Laurent]

> > 4. Related to Q3: what does "xy" as that argument mean exactly?
> >   a. #rx"[xy]"
> >   b. #rx"[xy]+"
> >   c. #rx"xy"
> >   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.
>

If we make things as simple-but-useful as possible, then I'd go for a
single char separator with option b/d. (I don't think there are many cases
where one would want a string as a separator?)
Personally, I don't like much when functions ask for a character because
the #\ looks ugly to me, but it still makes more sense than asking for a
string that must have a single character.

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

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

[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. #rx"xy"
>   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] `string-split'

[Laurent]

>
> 4. Related to Q3: what does "xy" as that argument mean exactly?
>>   a. #rx"[xy]"
>>   b. #rx"[xy]+"
>>   c. #rx"xy"
>>   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] Argument positions of string-... like functions

[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

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

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

[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. #rx"xy"
>   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

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

[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'

[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. #rx"xy"
   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-split'

[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'

[Laurent]

On Thu, Apr 19, 2012 at 14:53, Matthew Flatt  wrote:

> At Thu, 19 Apr 2012 14:43:44 +0200, Laurent wrote:
> > On Thu, Apr 19, 2012 at 14:33, Matthew Flatt  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'

[Matthew Flatt]

At Thu, 19 Apr 2012 14:43:44 +0200, Laurent wrote:
> On Thu, Apr 19, 2012 at 14:33, Matthew Flatt  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'

[Laurent]

On Thu, Apr 19, 2012 at 14:33, Matthew Flatt  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-replace'

[Laurent]

On Thu, Apr 19, 2012 at 14:26, 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))
>

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-replace'

[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-split'

[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-split'

[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'

[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'

[Sam Tobin-Hochstadt]

On Thu, Apr 19, 2012 at 8:21 AM, Eli Barzilay  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-replace'

[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'

[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] Fwd: [racket] Are There More String Functions?

[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
>  wrote:
> >
> > I saw no response to this question and no commit that includes the
> > cross-link. Anything?
> >
> >
> > Begin forwarded message:
> >
> >> From: Asumu Takikawa 
> >> Subject: Re: [racket] Are There More String Functions?
> >> Date: April 12, 2012 5:47:26 PM EDT
> >> To: Cristian Esquivias 
> >> 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] Fwd: [racket] Are There More String Functions?

[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
>  wrote:
> >
> > I saw no response to this question and no commit that includes the
> > cross-link. Anything?
> >
> >
> > Begin forwarded message:
> >
> >> From: Asumu Takikawa 
> >> Subject: Re: [racket] Are There More String Functions?
> >> Date: April 12, 2012 5:47:26 PM EDT
> >> To: Cristian Esquivias 
> >> 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] Pre-Release Checklist for v5.3

[Kathy Gray]

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

> * Kathy Gray 
>  - Test Engine Tests

Done

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