Re: [racket-dev] [plt] Push #22553: master branch updated
On Tue, Apr 26, 2011 at 12:01 PM, sstri...@racket-lang.org wrote:
sstrickl has updated `master' from d859642195 to f5de8bdabf.
http://git.racket-lang.org/plt/d859642195..f5de8bdabf
=[ 1 Commits ]==
Directory summary:
49.9% collects/slatex/private/
50.0% collects/slatex/
~~
f5de8bd Stevie Strickland sstri...@racket-lang.org 2011-04-26 12:57
:
| Move scmxlated source for slatex into private.
|
| Anyone using the sole export from slatex.rkt should really be using the
| functions provided by slatex-wrapper.rkt instead, which I imagine is why
| this has never been documented.
:
R collects/slatex/{ = private}/slatex.rkt (100%)
M collects/slatex/README | 4 ++--
M collects/slatex/slatex-wrapper.rkt | 2 +-
M collects/slatex/tests/test-docs-complete.rkt | 1 -
Any reason not to just document it instead? This code has been
unchanging forever and I don't think we want to break old scripts
whimsically.
Roby
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [plt] Push #22553: master branch updated
On Apr 26, 2011, at 1:05 PM, Robby Findler wrote:
On Tue, Apr 26, 2011 at 12:01 PM, sstri...@racket-lang.org wrote:
f5de8bd Stevie Strickland sstri...@racket-lang.org 2011-04-26 12:57
:
| Move scmxlated source for slatex into private.
|
| Anyone using the sole export from slatex.rkt should really be using the
| functions provided by slatex-wrapper.rkt instead, which I imagine is why
| this has never been documented.
:
R collects/slatex/{ = private}/slatex.rkt (100%)
M collects/slatex/README |4 ++--
M collects/slatex/slatex-wrapper.rkt |2 +-
M collects/slatex/tests/test-docs-complete.rkt |1 -
Any reason not to just document it instead? This code has been
unchanging forever and I don't think we want to break old scripts
whimsically.
I would imagine that any old scripts would be using the documented
slatex-wrapper interface, especially since there's a lot of setup work done in
that interface that would have to be duplicated otherwise. Do we have reason
to believe that people have been using the undocumented
`slatex::process-main-tex-file' function instead?
Stevie
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [plt] Push #22553: master branch updated
On Tue, Apr 26, 2011 at 12:09 PM, Stevie Strickland
sstri...@racket-lang.org wrote:
On Apr 26, 2011, at 1:05 PM, Robby Findler wrote:
On Tue, Apr 26, 2011 at 12:01 PM, sstri...@racket-lang.org wrote:
f5de8bd Stevie Strickland sstri...@racket-lang.org 2011-04-26 12:57
:
| Move scmxlated source for slatex into private.
|
| Anyone using the sole export from slatex.rkt should really be using the
| functions provided by slatex-wrapper.rkt instead, which I imagine is why
| this has never been documented.
:
R collects/slatex/{ = private}/slatex.rkt (100%)
M collects/slatex/README | 4 ++--
M collects/slatex/slatex-wrapper.rkt | 2 +-
M collects/slatex/tests/test-docs-complete.rkt | 1 -
Any reason not to just document it instead? This code has been
unchanging forever and I don't think we want to break old scripts
whimsically.
I would imagine that any old scripts would be using the documented
slatex-wrapper interface, especially since there's a lot of setup work done
in that interface that would have to be duplicated otherwise. Do we have
reason to believe that people have been using the undocumented
`slatex::process-main-tex-file' function instead?
I don't know of people who are, but I think that in situations like
these we should err on the side of not-breaking-code.
In this case, I would document this function as roughly like the
@racketmodname[slatex] library function X, provided here for backwards
compatibility. New code should use X. or similar.
Is that any more difficult than what's been done?
Robby
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] lots of new tests pushed
On 4/25/2011 7:00 PM, Robby Findler wrote: I've just looked over the results from the first complete drdr run and there were a few files that probably shouldn't have been checked, so I've pushed something that removes them. (I only made it to the 's's so I'll continue looking at the output more later.) If you want help fixing your docs, please ask. If you want to just not be bothered with this, please just tell me which collection is bothering you, and I'll remove the check. I want to just not be bothered with the SRFI docs. AFAICS, all SRFI docs are there. Chongkai Thanks, Robby On Mon, Apr 25, 2011 at 1:32 PM, Robby Findler ro...@eecs.northwestern.edu wrote: I just pushed tests for all non-racket and non-scheme collections that makes sure that all of the top-level libraries have their exports fully documented. I left out info.rkt and tried to drop obviously bad things from this list, but if you spot problems when drdr complains at you, please just go edit the file to remove libraries that shouldn't be there. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [plt] Push #22553: master branch updated
I second your judgment. I think it should be a part of the exercise to exorcise such hidden interfaces. On Apr 26, 2011, at 1:25 PM, Stevie Strickland wrote: On Apr 26, 2011, at 1:19 PM, Robby Findler wrote: I don't know of people who are, but I think that in situations like these we should err on the side of not-breaking-code. In this case, I would document this function as roughly like the @racketmodname[slatex] library function X, provided here for backwards compatibility. New code should use X. or similar. Is that any more difficult than what's been done? Yes, because it is not roughly like any of those library functions, due to all the setup that is skipped by using it directly. This function is not documented in Dorai's original documentation for slatex or in our own. Thus, anyone who has used that function was using an undocumented, unsupported interface. Part of this exercise, I assumed, was to decide which exports were important to document, and which exports have been unintentionally exported and thus should be unexported or considered `private'. This looks like a perfect example of the latter, instead of the former. I'm happy with putting it back and just removing it from the docs check instead, but I figured the move into `private' would make it more clear that this was _not_ something that should be used directly. Stevie _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Typed Racket support for Ephemerons
I have added support for ephemerons to Typed Racket, and submitted a pull request on Github (https://github.com/plt/racket/pull/5). This patch is supposed to fix PR 11633. Is there anything else I should do to get this patch integrated? -Eric _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Typed Racket support for Ephemerons
I've had a quick look at your patch, and it looks good to me. Did you make sure that all of TR's tests still pass? I'll pull that and commit it for you. Vincent At Tue, 26 Apr 2011 14:19:38 -0400, Eric Dobson wrote: I have added support for ephemerons to Typed Racket, and submitted a pull request on Github (https://github.com/plt/racket/pull/5). This patch is supposed to fix PR 11633. Is there anything else I should do to get this patch integrated? -Eric _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [plt] Push #22553: master branch updated
OK. Robby On Tue, Apr 26, 2011 at 12:48 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: I second your judgment. I think it should be a part of the exercise to exorcise such hidden interfaces. On Apr 26, 2011, at 1:25 PM, Stevie Strickland wrote: On Apr 26, 2011, at 1:19 PM, Robby Findler wrote: I don't know of people who are, but I think that in situations like these we should err on the side of not-breaking-code. In this case, I would document this function as roughly like the @racketmodname[slatex] library function X, provided here for backwards compatibility. New code should use X. or similar. Is that any more difficult than what's been done? Yes, because it is not roughly like any of those library functions, due to all the setup that is skipped by using it directly. This function is not documented in Dorai's original documentation for slatex or in our own. Thus, anyone who has used that function was using an undocumented, unsupported interface. Part of this exercise, I assumed, was to decide which exports were important to document, and which exports have been unintentionally exported and thus should be unexported or considered `private'. This looks like a perfect example of the latter, instead of the former. I'm happy with putting it back and just removing it from the docs check instead, but I figured the move into `private' would make it more clear that this was _not_ something that should be used directly. Stevie _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Typed Racket support for Ephemerons
On Tue, Apr 26, 2011 at 2:19 PM, Eric Dobson eric.n.dob...@gmail.com wrote: I have added support for ephemerons to Typed Racket, and submitted a pull request on Github (https://github.com/plt/racket/pull/5). This patch is supposed to fix PR 11633. All of this looks good, except that `EphemeronTop' is unnecessary. Since ephemerons are covariant, (Ephemeronof Any) is a supertype of (Ephemeronof T) for any type T. Vincent says that he'll change that and push the result. Thanks! -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Typed Racket support for Ephemerons
The tests all pass (for me). -Eric On Tue, Apr 26, 2011 at 2:54 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Tue, Apr 26, 2011 at 2:19 PM, Eric Dobson eric.n.dob...@gmail.com wrote: I have added support for ephemerons to Typed Racket, and submitted a pull request on Github (https://github.com/plt/racket/pull/5). This patch is supposed to fix PR 11633. All of this looks good, except that `EphemeronTop' is unnecessary. Since ephemerons are covariant, (Ephemeronof Any) is a supertype of (Ephemeronof T) for any type T. Vincent says that he'll change that and push the result. Thanks! -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] release blurb for 5.1.1
Here are some suggested items for the 5.1.1 release announcement. Please respond with any additions/deletions. The stuff in parentheses are short git sha1's. Use 'git show 12ab345' to see the commit. ryan: * new ffi/file module (..needs description..) (9bc3457bb) matthew * Removed drscheme, mred, and mred.app although mred for unix still exists (8d9e10f34e) * The installed version of libffi can be used instead of the distributed version (f3c3bb4441c) * `touch' and `future' are safe functions to execute inside futures (857003378 3bf0f800a76) * A new streams library compatible with `for' has been added to the racket collection as `racket/stream' (e652546bf52) * list-box% now supports multi-column (137d96c08917) eli * chrome is a supported browser in drracket (52ca08a8a9a) * All 3rd party copyrighted code has had their licenses clarified or changed to be compatible with the LGPL (f6f7e4eb3502 a3d00a910afb) robby * Added a widget to the status line of DrRacket that can toggle line numbers (c4e0559db4ca37) * The module browser graph is rendered much faster. (e928bd840c02) * Added `overlay/align', `underlay/align', `overlay/align/offset' and 'underlay/align/offset' (c1668d894e210) stephen * The stepper now supports lazy racket (da456f2e37e54) kathy * Addition of `define-wish' to the teaching languages and corresponding addition of support for wishes in test reports and check-expects (7758f508c56) _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] release blurb for 5.1.1
On Apr 26, 2011, at 3:46 PM, Jon Rafkind wrote: kathy * Addition of `define-wish' to the teaching languages and corresponding addition of support for wishes in test reports and check-expects (7758f508c56) This wasn't supposed to go in. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Pre-Release Checklist for v5.1.1, second call
On 04/25/2011 01:48 AM, Noel Welsh wrote: On Sun, Apr 24, 2011 at 2:04 AM, Ryan Culpepperry...@ccs.neu.edu wrote: * Noel Welshnoelwe...@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) I'm going to have difficulty doing this in a reasonable timeframe. I'm on holiday at the moment and working on a project proposal w/ May deadline in free time. Sorry. FWIW, this code doesn't change very often and is almost certainly ok. I just ran the test scripts for Rackunit and the SRFIs without problems, so I'm marking your items as done. Ryan _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] release blurb for 5.1.1
More things: Casey: - Redex version of Jay's continuation mark transformation (3250ff84) - Other redex news? Vincent: - TR's numeric tower is now built from unions of non-overlapping base types. (d4c93cc1) Vincent/Sam: other TR news? Vincent/Matthew: single precision flonums? Matthew: - `file/resource'? - Recent speed thing. Robby: - make hard links be version specific (4f165d3b)? - 2htdp/image news? - builds on osx 64 bits James/Matthew: futures news? (future semaphores, `future' in future, more ...) Generators have formals (generator formals body ...+) Ryan: `racket/syntax' etc -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] release blurb for 5.1.1
On Apr 26, 2011, at 2:33 PM, Eli Barzilay wrote: More things: Casey: - Redex version of Jay's continuation mark transformation (3250ff84) - Other redex news? Vincent: - TR's numeric tower is now built from unions of non-overlapping base types. (d4c93cc1) Vincent/Sam: other TR news? Vincent/Matthew: single precision flonums? Matthew: - `file/resource'? - Recent speed thing. Robby: - make hard links be version specific (4f165d3b)? - 2htdp/image news? - builds on osx 64 bits James/Matthew: futures news? (future semaphores, `future' in future, more ...) Generators have formals (generator formals body ...+) Ryan: `racket/syntax' etc I know that Stephen wanted something on the lazy stepper John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] better x86 performance
Here are the numbers for Racket, Typed Racket, Gambit and Larceny on 32 bits, and without Larceny on 64 bits. Overall, we're competitive, but we're losing pretty hard on deriv. Vincent fastestgambitlarcenyrackettyped-racketcpstack5715 ms1.1311.461.44dderiv6200 ms1.4811.491.51deriv3096 ms11.343.083.13div7434 ms12.161.161.11fft5903 ms12.011.491.11graphs7656 ms1.471.201.021lattice25863 ms2.0711.501.41maze27678 ms3.643.581.001mazefun11693 ms1.5211.081.06nfa6419 ms1.2611.231.03nqueens6835 ms1.0411.041.07paraffins6950 ms11.951.431.22tak7669 ms1.541.561.001takl7325 ms2.321.641.351triangle8960 ms1.001.1011.09 fastestgambitrackettyped-racketcpstack5332 ms11.501.47dderiv5981 ms11.331.30deriv3064 ms12.372.32div7014 ms11.581.56fft3830 ms11.471.16graphs6794 ms1.221.011lattice27250 ms1.311.061maze27280 ms2.461.041mazefun12295 ms1.101.091nfa6794 ms11.391.15nqueens5651 ms11.211.09paraffins8679 ms11.521.20tak7916 ms11.021.00takl8252 ms1.621.131triangle6862 ms11.211.27 At Sun, 24 Apr 2011 22:09:18 -0400, Vincent St-Amour wrote: These are impressive speedups! Given how close we were to the fastest Scheme compilers on some of these, that may be enough to give us the lead. I'll run the benchmarks on different implementations tomorrow. Vincent At Sun, 24 Apr 2011 17:11:21 -0600, Matthew Flatt wrote: The `assoc' example helped focus my attention on a long-unsolved issue with JIT-generated code, where non-tail calls from JIT-generated code to other JIT-generated code seemed more expensive than they should be. This effect showed up in `assq' and `assoc' through a high relative cost for calling `assq' or `assoc' on a short list (compared to calling the C implementation). This time, I finally saw what I've been missing: It's crucial to pair `call' and `ret' instructions on x86. That won't be news to compiler writers; it's a basic fact that I missed along the way. When the JIT generates a non-tail call from to other code that it generates, it sets up the called procedure's frame directly (because various computed values are more readily available before jumping to the called procedure). After setting up the frame --- including a return address --- the target code was reached using `jmp'. Later, the `ret' to return from the non-tail call would confuse the processor and caused stalls, because the `ret' it wasn't matched with its `call'. It's easy enough to put the return address in place using `call' when setting up a frame, which exposes the right nesting to the processor. The enclosed table shows the effect on traditional Scheme microbenchmarks. Improvements of 20% are common, and several improve by 50% or more. It's difficult to say which real code will benefit, but I think the improvement is likely to be useful. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] release blurb for 5.1.1
On 04/26/2011 03:45 PM, Robby Findler wrote: I think the only possible ones for me (where me in the first line really means Carl) that makes it into the big announcement are: - PLaneT development links are now version-specific I think this deserves a mention. What about parametric contracts? Or other contract changes? Ryan - Added `overlay/align', `underlay/align', `overlay/align/offset' and 'underlay/align/offset' to 2htdp/image but I'm fine if neither get mentioned. Robby On Tue, Apr 26, 2011 at 4:33 PM, Eli Barzilaye...@barzilay.org wrote: More things: Casey: - Redex version of Jay's continuation mark transformation (3250ff84) - Other redex news? Vincent: - TR's numeric tower is now built from unions of non-overlapping base types. (d4c93cc1) Vincent/Sam: other TR news? Vincent/Matthew: single precision flonums? Matthew: - `file/resource'? - Recent speed thing. Robby: - make hard links be version specific (4f165d3b)? - 2htdp/image news? - builds on osx 64 bits James/Matthew: futures news? (future semaphores, `future' in future, more ...) Generators have formals (generator formals body ...+) Ryan: `racket/syntax' etc -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] release blurb for 5.1.1
The new `racket/syntax' library contains facilities useful for writing macros. The `syntax/srcloc' and `syntx/location' libraries have been added for manipulating source locations. The new `ffi/file' library is useful for writing foreign library bindings that cooperate with Racket's security guard mechanism. Ryan On 04/26/2011 01:46 PM, Jon Rafkind wrote: Here are some suggested items for the 5.1.1 release announcement. Please respond with any additions/deletions. The stuff in parentheses are short git sha1's. Use 'git show 12ab345' to see the commit. ryan: * new ffi/file module (..needs description..) (9bc3457bb) matthew * Removed drscheme, mred, and mred.app although mred for unix still exists (8d9e10f34e) * The installed version of libffi can be used instead of the distributed version (f3c3bb4441c) * `touch' and `future' are safe functions to execute inside futures (857003378 3bf0f800a76) * A new streams library compatible with `for' has been added to the racket collection as `racket/stream' (e652546bf52) * list-box% now supports multi-column (137d96c08917) eli * chrome is a supported browser in drracket (52ca08a8a9a) * All 3rd party copyrighted code has had their licenses clarified or changed to be compatible with the LGPL (f6f7e4eb3502 a3d00a910afb) robby * Added a widget to the status line of DrRacket that can toggle line numbers (c4e0559db4ca37) * The module browser graph is rendered much faster. (e928bd840c02) * Added `overlay/align', `underlay/align', `overlay/align/offset' and 'underlay/align/offset' (c1668d894e210) stephen * The stepper now supports lazy racket (da456f2e37e54) kathy * Addition of `define-wish' to the teaching languages and corresponding addition of support for wishes in test reports and check-expects (7758f508c56) _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] release blurb for 5.1.1
On Tue, Apr 26, 2011 at 5:04 PM, Ryan Culpepper ry...@ccs.neu.edu wrote: On 04/26/2011 03:45 PM, Robby Findler wrote: I think the only possible ones for me (where me in the first line really means Carl) that makes it into the big announcement are: - PLaneT development links are now version-specific I think this deserves a mention. What about parametric contracts? Or other contract changes? I don't think the one new combinator we have is really going to have that big of an impact on our programmers (and partly because I think we don't really have the right answer yet for how to fit things into Racket Typed Racket properly). Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Pre-Release Checklist for v5.1.1, second call
Ok, thanks. That's 90% of the work done. N. On Tue, Apr 26, 2011 at 10:31 PM, Ryan Culpepper ry...@ccs.neu.edu wrote: I just ran the test scripts for Rackunit and the SRFIs without problems, so I'm marking your items as done. Ryan _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] narrow menus in 5.1
A user from #scheme on irc said drracket in 5.1 shows narrow menus. His system is ubuntu 10.10, the language is Portuguese. http://www.pasteall.org/pic/show.php?id=11565 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] release blurb for 5.1.1
* The Universe protocol of 5.1 and its predecessors are incompatible. (Ouch, this requires a change to the HISTORY. Will push soon.) _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] narrow menus in 5.1
This happens on my system as well, which is Ubuntu 11.04, but it didn't happen until some point after 5.1, I believe. On Tue, Apr 26, 2011 at 6:58 PM, Jon Rafkind rafk...@cs.utah.edu wrote: A user from #scheme on irc said drracket in 5.1 shows narrow menus. His system is ubuntu 10.10, the language is Portuguese. http://www.pasteall.org/pic/show.php?id=11565 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
