Re: [racket-dev] What is the policy on what is included in the core libraries?

2015-02-17 Thread Vincent St-Amour
I don't think we should add functions to TR that are not in Racket and
that are not clearly type-related (e.g., `cast`).

I also like Jens's solution better. Education vs crutches.

Vincent



At Tue, 17 Feb 2015 10:39:16 -0500,
Matthias Felleisen wrote:
 
 
 I'd add them to Typed Racket. That's what Haskellians are most likely to 
 explore and when they find them, it's a good thing (tm). -- Matthias
 
 
 
 
 On Feb 17, 2015, at 2:18 AM, Alexis King lexi.lam...@gmail.com wrote:
 
  I was just thinking today that I would, for example, find it useful to have 
  a (zip ...) function in racket/list that would be equivalent to (map list 
  ...). Users coming from a Haskell background might even find it useful to 
  have a zip-with function that is simply an alias for map. Admittedly, these 
  are rather trivial, but (especially in the first case) I think they’d still 
  be useful.
  
  I am all for avoiding feature creep and code bloat, but Racket’s “batteries 
  included” approach seems to make functions like these prime candidates for 
  libraries like racket/list. As long as they’re not in racket/base, they 
  seem fairly harmless, especially considering they would only be needed at 
  compile-time.
  
  Should I even consider adding things like this, or is the consensus that 
  the libraries are mostly sufficient as-is?
  
  -- 
  You received this message because you are subscribed to the Google Groups 
  Racket Developers group.
  To unsubscribe from this group and stop receiving emails from it, send an 
  email to racket-dev+unsubscr...@googlegroups.com.
  To post to this group, send email to racket-...@googlegroups.com.
  To view this discussion on the web visit 
  https://groups.google.com/d/msgid/racket-dev/5D941DB1-8A55-4A41-98A2-A3BE1BFE6D40%40gmail.com.
  For more options, visit https://groups.google.com/d/optout.
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Racket Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to racket-dev+unsubscr...@googlegroups.com.
 To post to this group, send email to racket-...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/racket-dev/EAAD5B93-DB78-419B-A662-131AD1D3E303%40ccs.neu.edu.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Racket Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-dev+unsubscr...@googlegroups.com.
To post to this group, send email to racket-...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-dev/87d258qxg8.wl%25stamourv%40ccs.neu.edu.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-dev] Github repo is two commits behind

2015-02-02 Thread Vincent St-Amour
FWIW, pulling from git.racket-lang.org has been slow (i.e. ~30mins) for
some of us in the last couple of days. Something in the mirroring may be
timing out for similar reasons.

Vincent



At Mon, 2 Feb 2015 18:41:56 -0300,
Gustavo Massaccesi wrote:
 
 * openssl: recognize version 1.0.1j #8265c9 (3 days ago) -- latest
 commit in git.racket-lang
 
 * pretty-print: fix for a current inspector that sees through
 internals #8d49a9 (3 days ago)
 
 * fix reified-syntax-class-curry (missing role argument) #302986 (3
 days ago) -- Latest commit in github
 
 Gustavo
 _
   Racket Developers list:
   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Github repo is two commits behind

2015-02-02 Thread Vincent St-Amour
I just pushed something, and now the Github mirror is up to date. The
push must have kicked the mirroring mechanism.

Vincent


At Mon, 02 Feb 2015 16:54:10 -0500,
Vincent St-Amour wrote:
 
 FWIW, pulling from git.racket-lang.org has been slow (i.e. ~30mins) for
 some of us in the last couple of days. Something in the mirroring may be
 timing out for similar reasons.
 
 Vincent
 
 
 
 At Mon, 2 Feb 2015 18:41:56 -0300,
 Gustavo Massaccesi wrote:
  
  * openssl: recognize version 1.0.1j #8265c9 (3 days ago) -- latest
  commit in git.racket-lang
  
  * pretty-print: fix for a current inspector that sees through
  internals #8d49a9 (3 days ago)
  
  * fix reified-syntax-class-curry (missing role argument) #302986 (3
  days ago) -- Latest commit in github
  
  Gustavo
  _
Racket Developers list:
http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Switching to Google Groups

2015-01-28 Thread Vincent St-Amour
In case anyone would like to use a non-gmail address for sign up, you
can sign up from this URL:
https://groups.google.com/forum/#!forum/racket-dev/join

The regular sign up button wouldn't let me.

Vincent


At Wed, 28 Jan 2015 16:47:58 -0800,
John Clements wrote:
 
 
 Dear developers,
 
 PLT would like to get out of the mailing-list administration game.
 
 Accordingly, we’re planning to switch to Google Groups. Rather than
 starting with our largest list, the Racket Users list, we’ve chosen to
 begin with the dev list, because … well, you’re probably more tolerant,
 if^H^H when something goes wrong.
 
 We would like the transition to be as smooth as possible, and we can use
 your help with this. Specifically, Google has a daily cap on the number
 of e-mail addresses that can be bulk-added to a mailing list. For this
 reason, it would speed the transition greatly if you could take a moment
 to sign up for the new group yourself, using this URL:
 
 https://groups.google.com/forum/#!forum/racket-dev
 
 We plan to disable signup for the old group now, and to halt delivery of
 mail to the existing group address tomorrow. You can post to the new
 group (after signing up) by sending mail to
 
 racket-...@googlegroups.com
 
 We plan to manually add or invite the members who do not add themselves,
 but the daily cap will mean that these users are likely to miss one or
 more days of postings to this list. Naturally, those posts will be
 archived, as part of the group.
 
 The archive of the existing list will continue to exist, though new
 messages will not be added to it.
 
 Let us know if you run into problems!
 
 Many thanks,
 
 John Clements  PLT
 _
   Racket Developers list:
   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Release process for split repos

2015-01-27 Thread Vincent St-Amour
That sounds good to me.

One concern, though: it looks like recreating old releases requires that
all the participating repos (1) still exist, (2) have the same
name/location, and (3) still have the release tags. I'm not too worried
about (1) and (3), but I could see (2) happening if, e.g., a package
changes maintainer (and therefore location), or if we have to move away
from github at some point.

IIUC, archiving snapshots of the participating repos when the release is
finalized may solve that problem. Does that sound reasonable?

Vincent



At Fri, 23 Jan 2015 15:31:21 -0500,
Ryan Culpepper wrote:
 
 I’ve added a draft of a new release process that takes the repository split 
 into account. The main difference is that there is no longer a single release 
 branch under central management; instead, there is a release branch for each 
 repository, and management responsibilities for package release branches is 
 distributed.
 
 The wiki page is here:
 
   https://github.com/plt/racket/wiki/Release-process
 
 Please review, ask questions, and point out ambiguities and potential 
 problems.
 
 Ryan
 
 
 _
   Racket Developers list:
   http://lists.racket-lang.org/dev

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


Re: [racket-dev] Release Announcement for v6.1.1

2014-10-27 Thread Vincent St-Amour
For TR:

* Exception handling changed to be safe. This may break existing
  programs that rely on unsafe behavior.

* Exports from the GUI and framework libraries have types, and can be
  used transparently from typed programs.

* Casts and predicates are supported in typed regions.


Vincent



At Mon, 27 Oct 2014 12:25:22 -0400,
Ryan Culpepper wrote:
 
 The release announcement sketch that I have so far is below.  Please
 mail me new items and/or edits.
 --
 
 mflatt:
  - optimizations (most from Gustavo Massaccesi) (82ffd405, 25c05d66,
a7a912ee, 1f2f7a1d, d14b4a80, 769c5b6e, 35eb6562, 15423988)
  - add replace-evt (as suggested by Jan Dvořák) (bc69a9b0)
  - performance tuning (c570a862, 1809df45)
  - windows: use native api for dates (135ccf09)
  - allow mixing exceptions with ffi/unsafe/alloc (from Jan Dvořák)
   (8bd5aa38)
  - fixing letrec updates? (eg 926e64f5?)
  - senora gc (2916fc34, a312f499, 881990ed)
  - raco pkg add '--binary-lib' (05523a0b, b2b00010)
  - Mac OS X Yosemite Pango repair (76f1ebde)
  - throw out latex back-end for picts ? (77ddf71b)
  - chaperones w/o redirections (1f1a10db, a8d0534e)
  - DPI-aware racket/gui on Windows (a64a1cb1)
  - Windows: fix handling of junctions as links (cf7c0134)
  - behavior of numpad Enter (7d388a07, a41cc0c3)
  - UDP improvements (2a387ace)
  - natipkg (40f5ec07)
 
 robby:
  - add #:post condition to meta functions (e991dd46)
  - improve the random checking for -i (72c83a32)
  - add contract-correct caveat to error messages (1dda800c)
  - add #:pre to define-judgment-form (54a6d317)
  - contract-stronger (eaf48bbb, 05185dcd, f669c47c, ...)
 
 matthias:
  - check-satisfied (ecfafe63,  and following)
 
 neil:
  - remove dependence on libgtkgl (c601b82f)
 
 ryanc:
  - add pattern expanders to syntax/parse (from Alex Knauth) (81cc6bf4)
  - openssl server-side SNI (from Jay Kominek) (320079ee, 2d2f5dc3)
 
 --
 
 _
  Racket Developers list:
  http://lists.racket-lang.org/dev

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


Re: [racket-dev] [plt] Push #29396: master branch updated

2014-10-20 Thread Vincent St-Amour
Yes, if convenient.

I already emailed Ryan privately about it.

Vincent



At Mon, 20 Oct 2014 17:54:59 -0400,
Matthias Felleisen wrote:
 
 
 DOn't we want to merge this into 6.1.1? 
 
 
 On Oct 20, 2014, at 3:44 PM, stamo...@racket-lang.org wrote:
 
  stamourv has updated `master' from 538bb75d64 to 9030680e31.
   http://git.racket-lang.org/plt/538bb75d64..9030680e31
  
  =[ One Commit ]=
  Directory summary:
   16.9% pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/base-env/
   83.0% 
  pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/unit-tests/
  
  ~~
  
  9030680 Vincent St-Amour stamo...@racket-lang.org 2014-10-20 11:34
  :
  | Fix types for foldl and foldr with 3 lists.
  |
  | Thanks to Jack Firth for the report.
  :
   M .../tests/typed-racket/unit-tests/typecheck-tests.rkt| 13 
  +
   M .../typed-racket-lib/typed-racket/base-env/base-env.rkt  |  4 ++--
  
  =[ Overall Diff ]===
  
  pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/base-env/base-env.rkt
  ~~
  --- 
  OLD/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/base-env/base-env.rkt
  +++ 
  NEW/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/base-env/base-env.rkt
  @@ -657,11 +657,11 @@
   (-poly (a b c d)
  (cl- [((a b . - . b) b (-lst a)) b]
[((a b c . - . c) c (-lst a) (-lst b)) c]
  -  [((a b c d . - . d) d (-lst a) (-lst b) (-lst d)) d]))]
  +  [((a b c d . - . d) d (-lst a) (-lst b) (-lst c)) d]))]
  [foldr  (-poly (a b c d)
 (cl- [((a b . - . b) b (-lst a)) b]
   [((a b c . - . c) c (-lst a) (-lst b)) c]
  - [((a b c d . - . d) d (-lst a) (-lst b) (-lst d)) 
  d]))]
  + [((a b c d . - . d) d (-lst a) (-lst b) (-lst c)) 
  d]))]
  [filter (-poly (a b) (cl-*
((asym-pred a Univ (-FS (-filter b 0) -top))
 (-lst a)
  
  pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/unit-tests/typecheck-tests.rkt
  ~~
  --- 
  OLD/pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/unit-tests/typecheck-tests.rkt
  +++ 
  NEW/pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/unit-tests/typecheck-tests.rkt
  @@ -1155,6 +1155,19 @@
  (-polydots (a) ((list) (a a) . -... . -Integer))]
  |#
  
  +[tc-e (foldl (lambda: ([x : Integer] [acc : String]) acc)  '(1 2 
  3))
  +  -String]
  +[tc-e (foldl (lambda: ([x : Integer] [y : Float] [acc : String]) 
  acc)  '(1 2 3) '(1.2 3.4 5.6))
  +  -String]
  +[tc-e (foldl (lambda: ([x : Integer] [y : Float] [z : Symbol ] 
  [acc : String]) acc)  '(1 2 3) '(1.2 3.4 5.6) '(a b c))
  +  -String]
  +[tc-e (foldr (lambda: ([x : Integer] [acc : String]) acc)  '(1 2 
  3))
  +  -String]
  +[tc-e (foldr (lambda: ([x : Integer] [y : Float] [acc : String]) 
  acc)  '(1 2 3) '(1.2 3.4 5.6))
  +  -String]
  +[tc-e (foldr (lambda: ([x : Integer] [y : Float] [z : Symbol ] 
  [acc : String]) acc)  '(1 2 3) '(1.2 3.4 5.6) '(a b c))
  +  -String]
  +
  ;; First is same as second, but with map explicitly instantiated.
  [tc-e/t (plambda: (a ...) [ys : (a ... a - Number) *]
  (lambda: [zs : a ... a]
 
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Pre-Release Checklist for v6.1.1

2014-10-16 Thread Vincent St-Amour
At Thu, 16 Oct 2014 09:13:54 -0400,
Ryan Culpepper wrote:
 * Sam Tobin-Hochstadt sa...@ccs.neu.edu,
Vincent St-Amour stamo...@ccs.neu.edu
   - Match Tests
   - Typed Racket Tests

Done.

   - Typed Racket Updates: update HISTORY
   (updates should show v6.1.1 as the most current version; email me
   to pick the changes when they're done, or tell me if there are no such
   changes.)

In process.

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


Re: [racket-dev] Pre-Release Checklist for v6.1.1

2014-10-16 Thread Vincent St-Amour
At Thu, 16 Oct 2014 11:22:04 -0400,
Vincent St-Amour wrote:
- Typed Racket Updates: update HISTORY
(updates should show v6.1.1 as the most current version; email me
to pick the changes when they're done, or tell me if there are no such
changes.)
 
 In process.

Pushed as commit 66e5a246c42dd585be9e42b280c0338de1e30892

Vincent

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


Re: [racket-dev] Intermittent Segfault on DrDr

2014-10-03 Thread Vincent St-Amour
Great! That's good news.

It's odd that the bug only started manifesting itself (at least on this
file) recently.

Thanks!

Vincent



At Thu, 2 Oct 2014 13:48:28 -0600,
Matthew Flatt wrote:
 
 I think that commit b946d4639e fixes this crash.
 
 It's nice of you to ask the day after the repair. :) I had spent a lot
 of time trying to replicate that crash, with no success, but yesterday
 was my lucky day. Claire ran a pessimization experiment on the bytecode
 compiler that made image.scrbl crash reliably. I can't say for
 certain that the bug that I fixed caused this crash, but the details
 are a close match for the test content and crash reports.
 
 The bug was introduced in 2009 (commit bc47db42e4).
 
 At Thu, 02 Oct 2014 15:00:25 -0400, Vincent St-Amour wrote:
  The file listed below has been segfaulting intermittently for about a
  month, but I can't reproduce the crash on any of my machines (Linux or
  Mac OS, both 64 bits).
  
  Walking backwards through the commit log from the first occurrence of
  the crash on DrDr, the first commit that looks like it may be related to
  segfaults is this one:
  
  https://github.com/plt/racket/commit/15423988220ce1fa5dea60917c5c7e83dde941de
  
  Any ideas?
  
  Can anyone reproduce this crash?
  
  Vincent
  
  
  At Wed,  1 Oct 2014 15:56:01 -0400 (EDT),
  d...@racket-lang.org wrote:
   
   DrDr has finished building push #29301 after 3.32h.
   
   http://drdr.racket-lang.org/29301/
   
   A file you are responsible for has a condition that may need inspecting.
 unclean:
   
  http://drdr.racket-lang.org/29301/pkgs/typed-racket-pkgs/typed-racket-test/tests
  /typed-racket/succeed/mandelbrot.rkt
   
 stderr:
   
  http://drdr.racket-lang.org/29301/pkgs/typed-racket-pkgs/typed-racket-test/tests
  /typed-racket/succeed/mandelbrot.rkt
   
   
  _
Racket Developers list:
http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] Intermittent Segfault on DrDr

2014-10-02 Thread Vincent St-Amour
The file listed below has been segfaulting intermittently for about a
month, but I can't reproduce the crash on any of my machines (Linux or
Mac OS, both 64 bits).

Walking backwards through the commit log from the first occurrence of
the crash on DrDr, the first commit that looks like it may be related to
segfaults is this one:

https://github.com/plt/racket/commit/15423988220ce1fa5dea60917c5c7e83dde941de

Any ideas?

Can anyone reproduce this crash?

Vincent


At Wed,  1 Oct 2014 15:56:01 -0400 (EDT),
d...@racket-lang.org wrote:
 
 DrDr has finished building push #29301 after 3.32h.
 
 http://drdr.racket-lang.org/29301/
 
 A file you are responsible for has a condition that may need inspecting.
   unclean:
 
 http://drdr.racket-lang.org/29301/pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/succeed/mandelbrot.rkt
 
   stderr:
 
 http://drdr.racket-lang.org/29301/pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/succeed/mandelbrot.rkt
 
 
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] [racket] Performance. Higher-order function

2014-08-28 Thread Vincent St-Amour
At Thu, 28 Aug 2014 08:55:59 -0600,
Matthew Flatt wrote:
 
 I didn't change the main-distribution package. I changed the Utah
 snapshot's configuration to make the Racket distribution have
 main-distribution plus optimization-coach.

Ah, I see. Got it.

 Changing main-distribution would interfere with a top-level `make`
 and other things that are still built around the current transitional
 model (i.e., still having a main Racket repository for the content of
 the main distribution).
 
 To really get optimization-coach into the main distribution, I think
 we have two options:
 
  * Split the main repo and shift everything into that mode.
 
  * Move optimization-coach into the main repo, for now, even though
we expect to split the main repo in the near future.

Do we have a time frame for the former? IMO, that's the way to go, but
do we think this can happen for the next release?

I don't like the latter. Merging it in and then back out again would be
pointless work, IMO, and would lead to confusion as to what the official
version is.

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


Re: [racket-dev] [racket] Performance. Higher-order function

2014-08-27 Thread Vincent St-Amour
Great, thanks!

I didn't see changes to the main repo to reflect that addition. Are the
contents of the main distribution not part of the repo anymore?

Vincent



At Wed, 27 Aug 2014 08:46:02 -0600,
Matthew Flatt wrote:
 
 The Racket snapshots at
 
  http://www.cs.utah.edu/plt/snapshots/
 
 now include the Optimization Coach package.
 
 At Tue, 12 Aug 2014 18:32:05 +0100, Matthew Flatt wrote:
  Our build system can create a distribution from any set of packages,
  and so we can easily switch over one of the snapshots to use that mode
  and include the OC. The Utah snapshot machine fell off the network
  (that's why we have more than snapshot site...), but I can try adding
  OC when I can reset it next week.
 
 _
   Racket Developers list:
   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] [racket] Performance. Higher-order function

2014-08-12 Thread Vincent St-Amour
Ok, let's try to do that. Is there currently a way to include packages
from 3rd party repos to the main distribution?

Vincent


At Tue, 12 Aug 2014 00:03:04 -0400,
Greg Hendershott wrote:
 
  Being in the main repo is different from being in the distribution (and 
  thus automatically installed). I think that OC should be there when you 
  download the full bundle.
 
 Definitely.
 
 1. It's very useful.
 2. Its existence says, Racket optimization is a thing.
 3. It's used with one of Racket's most appealing and unique facets, DrRacket.
 c
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Pre-Release Checklist for v6.1

2014-07-21 Thread Vincent St-Amour
At Thu, 17 Jul 2014 20:03:12 -0400,
Ryan Culpepper wrote:
 * Sam Tobin-Hochstadt sa...@ccs.neu.edu,
Vincent St-Amour stamo...@ccs.neu.edu
   - Match Tests
   - Typed Racket Tests

Done.

   - Typed Racket Updates: update HISTORY
   (updates should show v6.1 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, Asumu, Eric: what's new for this release?

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


Re: [racket-dev] Pre-Release Checklist for v6.1

2014-07-21 Thread Vincent St-Amour
At Mon, 21 Jul 2014 16:24:24 -0400,
Asumu Takikawa wrote:
 
 On 2014-07-21 16:14:27 -0400, Vincent St-Amour wrote:
  Sam, Asumu, Eric: what's new for this release?
 
 This came up on IRC the other day. I think Eric was saying the main
 changes were inference speedups, support for contracted functions, and
 better keyword support.

Pushed as commit 5a12f8e77.

Thanks!

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


Re: [racket-dev] Release Announcement for v6.0.1

2014-05-01 Thread Vincent St-Amour
At Thu, 01 May 2014 13:49:55 -0400,
Ryan Culpepper wrote:
 vincent:
 - contract profiler (cc0e6763, 7495243d, etc)

Nothing significant for this release.

 - make f[lx]vectors sequences (8e32e6e4)

Not sure that's worth putting in the release notes, but if we decide it
is, here's a bullet:

- flvectors and fxvectors are sequences, and can be iterated over with
  the `for' family of forms.


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


Re: [racket-dev] make-empty-namespace vs make-base-empty-namespace; ie attaching racket/base does other stuff

2014-04-28 Thread Vincent St-Amour
Extra bit of information, this works too:

#lang racket
(define ns (make-empty-namespace))
(namespace-attach-module (current-namespace) ''#%builtin ns)
(parameterize ([current-namespace ns])
  (namespace-require m.rkt))

But replacing ''#%builtin with ''#%kernel or ''#%boot doesn't. Replacing
it with 'racket/base (to end up with the equivalent of
`make-base-empty-namespace') does work.

Vincent



At Mon, 28 Apr 2014 16:38:24 -0400,
Stephen Chang wrote:
 
 Motivated by some recent email threads, I decided to better understand
 how Racket namespaces work by re-reading some docs but I got confused.
 
 Paraphrasing the examples from this part of the guide:
 http://docs.racket-lang.org/guide/mk-namespace.html
 
 the following example fails because the module registry in the
 namespace is empty:
 
 (parameterize ([current-namespace (make-empty-namespace)])
   (namespace-require m.rkt)) ; error
 
 But the example works if make-base-empty-namespace is used instead:
 
 (parameterize ([current-namespace (make-base-empty-namespace)])
   (namespace-require m.rkt)) ; works
 
 (Assume the contents of m.rkt is #lang racket/base with nothing else.)
 
 According to the docs, make-base-empty-namespace attaches
 racket/base but why does this make m.rkt suddenly available? There
 seems to be an unexplained gap between to the two examples. (Adding to
 my confusion is that (module-declared? m.rkt) evaluates to false,
 even in the 2nd case.)
 
 With help from Vincent, we investigated and speculate that perhaps
 attaching racket/base also runs boot from '#%boot, which populates
 current-module-name-resolver, but could not conclude anything
 definitively. Can someone explain what's happening?
 _
   Racket Developers list:
   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] [plt] Push #28619: master branch updated

2014-04-25 Thread Vincent St-Amour
It shouldn't. I used `list', not `cons'.

Vincent


At Fri, 25 Apr 2014 10:47:23 -0700,
Eric Dobson wrote:
 
 Doesn't this make the dead clauses return void the function instead of
 void the value? Not that they ever should run.
 
 On Fri, Apr 25, 2014 at 10:45 AM,  stamo...@racket-lang.org wrote:
  stamourv has updated `master' from b40619ffd5 to ce3033a0c7.
http://git.racket-lang.org/plt/b40619ffd5..ce3033a0c7
 
  =[ One Commit ]=
  Directory summary:
52.9% pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/optimizer/
47.0% 
  pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/optimizer/tests/
 
  ~~
 
  ce3033a Vincent St-Amour stamo...@racket-lang.org 2014-04-25 13:40
  :
  | Keep dead case-lambda clauses around to avoid changing arity.
  |
  | Closes PR14468.
  :
A 
  pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/optimizer/tests/dead-case-lambda.rkt
M .../tests/typed-racket/optimizer/tests/unboxed-for.rkt  |  2 +-
M .../typed-racket-lib/typed-racket/optimizer/dead-code.rkt   | 10 
  +++---
 
  =[ Overall Diff ]===
 
  pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/optimizer/dead-code.rkt
  
  --- 
  OLD/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/optimizer/dead-code.rkt
  +++ 
  NEW/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/optimizer/dead-code.rkt
  @@ -49,9 +49,13 @@
   (begin0
 (case-lambda
   #,@(for/list ((formals (in-syntax #'(formals ...)))
  -  (bodies  (in-syntax #'(bodies ...)))
  -  #:unless (dead-lambda-branch? formals))
  -  (cons formals (stx-map (optimize) bodies
  +  (bodies  (in-syntax #'(bodies ...
  + (if (dead-lambda-branch? formals)
  + ;; keep the clause (to have a case-lambda with the 
  right arity)
  + ;; but not the body (to make the function smaller for 
  inlining)
  + ;; TODO could do better, and keep a single clause per 
  arity
  + (list formals #'(void)) ; return type doesn't matter, 
  should never run
  + (cons formals (stx-map (optimize) bodies)
 ;; We need to keep the syntax objects around in the generated 
  code with the correct bindings
 ;; so that CheckSyntax displays the arrows correctly
 #,@(for/list ((formals (in-syntax #'(formals ...)))
 
  pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/optimizer/tests/dead-case-lambda.rkt
  
  --- /dev/null
  +++ 
  NEW/pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/optimizer/tests/dead-case-lambda.rkt
  @@ -0,0 +1,19 @@
  +#;#;
  +#END
  +TR opt: dead-case-lambda.rkt 4:10 () -- dead case-lambda branch
  +TR opt: dead-case-lambda.rkt 6:10 (d . rst) -- dead case-lambda branch
  +END
  +#END
  +(arity-at-least 0)
  +
  +END
  +
  +#lang typed/racket
  +#reader tests/typed-racket/optimizer/reset-port
  +
  +(procedure-arity
  +  (ann (case-lambda
  + [() (void)]
  + [(d) (void)]
  + [(d . rst) (void)])
  +  (Any - Any)))
 
  pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/optimizer/tests/unboxed-for.rkt
  ~~~
  --- 
  OLD/pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/optimizer/tests/unboxed-for.rkt
  +++ 
  NEW/pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/optimizer/tests/unboxed-for.rkt
  @@ -2,7 +2,6 @@
   #END
   TR opt: unboxed-for.rkt 2:0 (for/fold: : Float-Complex ((sum : 
  Float-Complex 0.0+0.0i)) ((i : Float-Complex (quote (1.0+2.0i 2.0+4.0i 
  (+ i sum)) -- call to fun with unboxed args
   TR opt: unboxed-for.rkt 2:0 (for/fold: : Float-Complex ((sum : 
  Float-Complex 0.0+0.0i)) ((i : Float-Complex (quote (1.0+2.0i 2.0+4.0i 
  (+ i sum)) -- fun - unboxed fun
  -TR opt: unboxed-for.rkt 2:0 (for/fold: : Float-Complex ((sum : 
  Float-Complex 0.0+0.0i)) ((i : Float-Complex (quote (1.0+2.0i 2.0+4.0i 
  (+ i sum)) -- unbox float-complex
   TR opt: unboxed-for.rkt 2:0 (for/fold: : Float-Complex ((sum : 
  Float-Complex 0.0+0.0i)) ((i : Float-Complex (quote (1.0+2.0i 2.0+4.0i 
  (+ i sum)) -- unboxed call site
   TR opt: unboxed-for.rkt 2:0 (for/fold: : Float-Complex ((sum : 
  Float-Complex 0.0+0.0i)) ((i : Float-Complex (quote (1.0+2.0i 2.0+4.0i 
  (+ i sum)) -- unboxed call site
   TR opt: unboxed-for.rkt 2:0 (for/fold: : Float-Complex ((sum : 
  Float-Complex 0.0+0.0i)) ((i : Float-Complex (quote (1.0+2.0i 2.0+4.0i 
  (+ i sum)) -- unboxed let bindings
  @@ -17,6 +16,7

Re: [racket-dev] [plt] Push #28576: master branch updated

2014-04-21 Thread Vincent St-Amour
At Sat, 19 Apr 2014 19:41:49 -0600,
Matthew Flatt wrote:
 
 At Sat, 19 Apr 2014 17:36:40 -0400, Vincent St-Amour wrote:
  At Sat, 19 Apr 2014 13:19:25 -0400,
  mfl...@racket-lang.org wrote:
   a01b12e Matthew Flatt mfl...@racket-lang.org 2014-04-19 10:11
   :
   | optimizer: don't move expressions into a `with-continuation-mark`
   |
   | ... unless the optimizer can prove that the expression doesn't
   | inspect continuation marks.
   :
 M pkgs/racket-pkgs/racket-test/tests/racket/optimize.rktl | 12 
   +++-
 M racket/src/racket/src/optimize.c|  5 +
  
  This optimization can be observed from another thread, like a profiler's
  sampling thread, even if the relevant code doesn't observe continuation
  marks itself.
 
 Right: If there's some synchronization point within the expression so
 that you could reliably observe the thread at that point, then the
 expression doesn't get moved relative to marks.

Ok, no problem then. Sorry for the noise.

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


Re: [racket-dev] [plt] Push #28576: master branch updated

2014-04-19 Thread Vincent St-Amour
At Sat, 19 Apr 2014 13:19:25 -0400,
mfl...@racket-lang.org wrote:
 a01b12e Matthew Flatt mfl...@racket-lang.org 2014-04-19 10:11
 :
 | optimizer: don't move expressions into a `with-continuation-mark`
 |
 | ... unless the optimizer can prove that the expression doesn't
 | inspect continuation marks.
 :
   M pkgs/racket-pkgs/racket-test/tests/racket/optimize.rktl | 12 +++-
   M racket/src/racket/src/optimize.c|  5 +

This optimization can be observed from another thread, like a profiler's
sampling thread, even if the relevant code doesn't observe continuation
marks itself.

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


Re: [racket-dev] [racket-bug] all/14404: profile would be more useful if it returned the result(s) of evaluating its body

2014-03-27 Thread Vincent St-Amour
I looked through the package descriptions, and it doesn't look like any
of them would use the profiler.

I'll do the change.

Vincent



At Thu, 27 Mar 2014 15:33:48 -0400,
Vincent St-Amour wrote:
 
 Will do.
 
 Is there a convenient way to grep through packages without installing them?
 
 Vincent
 
 
 At Thu, 27 Mar 2014 14:20:01 -0500,
 Robby Findler wrote:
  
  [1  text/plain; UTF-8 (7bit)]
  It seems unlikely that anyone does, but could you look at the code on the
  pkg server to check?
  
  Robby
  
  
  On Thu, Mar 27, 2014 at 1:42 PM, Vincent St-Amour 
  stamo...@ccs.neu.eduwrote:
  
   [ccing dev]
  
   I agree. That would also make adding profiling less intrusive than it is
   now. Consistency with `time' would also be nice. FWIW, `contract-profile'
   behaves like `time'.
  
   Currently `profile' and `profile-thunk' return whatever the profile
   renderer returns. Most renderers print their report and return void.
   But, as the documentation mentions, `values' can be used as a renderer
   in which case `profile' returns the pre-rendering analyzed profile
   data. Returning the result of the profiled expression would break that
   behavior.
  
   On the other hand, it's already possible to get the analyzed data by
   invoking the sampler and the analyzer directly. Changing the behavior of
   `profile' wouldn't remove that functionality, just make it less
   convenient.
  
   Does anyone rely on that behavior from `profile' and `profile-thunk'?
   If not, I think we should change it.
  
   Vincent
  
  
  
   At Sat, 15 Mar 2014 23:12:11 -0400,
   eric.hanch...@gmail.com wrote:
   
A new problem report is waiting at
  http://bugs.racket-lang.org/query/?cmd=viewpr=14404
   
Reported by Eric Hanchrow for release: 6.0.0.1--2013-12-13(1f1550a/a)
   
*** Description:
I recently tried to use profile, and didn't closely read its
   documentation.  I naively assumed that it would work similarly to time 
   --
   namely that I could simply wrap (profile ...) around my code, and my code
   would continue to run, but would also emit profiling information.  But of
   course profile returns void, so I had to tediously capture my thunk's 
   value
   myself, and then arrange to have that value passed outside of the 
   profile
   call.  Anyway ... I'd like the below snippet to print 9 not just once 
   (from
   the call to time), but twice.
   
*** How to repeat:
#lang racket
   
(require profile)
   
(displayln (profile (+ 2 3 4)))
(displayln (time (+ 2 3 4)))
   
*** Environment:
macosx Darwin Eric-Hanchrows-MacBook-Pro.local 13.1.0 Darwin Kernel
   Version 13.1.0: Thu Jan 16 19:40:37 PST 2014;
   root:xnu-2422.90.20~2/RELEASE_X86_64 x86_64 (x86_64-macosx/3m)
   (get-display-depth) = 32
Human Language: english
(current-memory-use) 287758760
Links: (links) = (); (links #:user? #f) = (contract-profile syntax
   mysterx sgl datalog shell-completion algol60 icons ds-store
   slatex realm games make trace plai eopl lazy 
   preprocessor
   profile racklog mzcom schemeunit unstable frtime mrlib
   swindle); (links #:root? #t) =
   (#path:/Users/erichanchrow/Library/Racket/snapshot/pkgs/throw
   #path:/Users/erichanchrow/Library/Racket/snapshot/pkgs/zeromq
   #path:/Users/erichanchrow/Library/Racket/snapshot/pkgs/zmq); (links
   #:user? #f #:root? #t) = (#path:/Applications/Racket
   v6.0.0.1/share/pkgs/racket-lib #path:/Applications/Racket
   v6.0.0.1/share/pkgs/main-distribution #path:/Applications/Racket
   v6.0.0.1/share/pkgs/at-exp-lib #path:/Applications/Racket
   v6.0.0.1/share/pkgs/compatibility #path:/Applications/Racket
   v6.0.0.1/share/pkgs/compiler #path:/Applications/Racket
   v6.0.0.1/share/pkgs/data #path:/Applications/Racket
   v6.0.0.1/share/pkgs/db #path:/Applications/Racket
 !
 v6.0.0.1/share/pkgs/deinprogramm #path:/Applications/Racket
   v6.0.0.1/share/pkgs/draw #path:/Applications/Racket
   v6.0.0.1/share/pkgs/draw-doc #path:/Applications/Racket
   v6.0.0.1/share/pkgs/draw-lib #path:/Applications/Racket
   v6.0.0.1/share/pkgs/drracket #path:/Applications/Racket
   v6.0.0.1/share/pkgs/errortrace #path:/Applications/Racket
   v6.0.0.1/share/pkgs/future-visualizer #path:/Applications/Racket
   v6.0.0.1/share/pkgs/future-visualizer-typed #path:/Applications/Racket
   v6.0.0.1/share/pkgs/gui #path:/Applications/Racket
   v6.0.0.1/share/pkgs/htdp #path:/Applications/Racket
   v6.0.0.1/share/pkgs/html #path:/Applications/Racket
   v6.0.0.1/share/pkgs/images #path:/Applications/Racket
   v6.0.0.1/share/pkgs/macro-debugger #path:/Applications/Racket
   v6.0.0.1/share/pkgs/macro-debugger-text-lib #path:/Applications/Racket
   v6.0.0.1/share/pkgs/math #path:/Applications/Racket
   v6.0.0.1/share/pkgs/mzscheme #path:/Applications/Racket
   v6.0.0.1/share/pkgs/net #path
:!
 /Applications/Racket v6.0.0.1/share/pkgs/parser-tools #path:!
 /Applications/Racket v6.0.0.1/share/pkgs/pconvert-lib
   #path:/Applications/Racket

Re: [racket-dev] [DrDr] R28413 (timeout 4) (unclean 16) (stderr 35) (changes 22)

2014-03-26 Thread Vincent St-Amour
Right. I'll fix the TR random tester.

Vincent


At Wed, 26 Mar 2014 13:25:42 -0400,
Sam Tobin-Hochstadt wrote:
 
 On Wed, Mar 26, 2014 at 1:10 PM, Robby Findler
 ro...@eecs.northwestern.edu wrote:
  Just to confirm: Redex isn't doing anything wrong, right?
 
 Correct -- I think `real` was always allowed to generate such numbers,
 but it didn't before.
 
 Sam
 
 
  Redex is now using the in-order enumeration generation in a default
  configuration (for a little while before adding some of the old-style random
  generated terms).
 
  So if you want to see what kinds of things it generates, you can use
  generate-term with the #:i-th argument.
 
  Robby
 
 
 
  On Wed, Mar 26, 2014 at 12:03 PM, Eric Dobson eric.n.dob...@gmail.com
  wrote:
 
  Looks like what is actually happening is that redex is actually
  generating reals for this program now.
 
  #lang racket
 
  (require redex/reduction-semantics)
  (define-language tr-arith
[n real])
 
  (redex-check tr-arith n #t
 #:prepare (lambda (x) (displayln x) x))
 
  Before we were only getting small integers.
 
  On Wed, Mar 26, 2014 at 9:46 AM, Eric Dobson eric.n.dob...@gmail.com
  wrote:
   This push has started breaking the random TR tests. I think the issue
   is that TR assumed that redex wouldn't generate so large numbers that
   it exceeded the flonum range. Could that have changed in this commit?
   Or changed so that were generated earlier in random testing? If so the
   issue is definitely on the TR side, but just want to confirm that the
   theory is likely.
  
   On Wed, Mar 26, 2014 at 4:58 AM,  d...@racket-lang.org wrote:
   DrDr has finished building push #28413 after 1.20h.
  
   http://drdr.racket-lang.org/28413/
  
   A file you are responsible for has a condition that may need
   inspecting.
 stderr:
  
   http://drdr.racket-lang.org/28413/pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/tr-random-testing.rkt
  
 unclean:
  
   http://drdr.racket-lang.org/28413/pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/tr-random-testing.rkt
  
  
 
 
 
  _
Racket Developers list:
http://lists.racket-lang.org/dev
 
 _
   Racket Developers list:
   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] [plt] Push #28062: master branch updated

2014-01-15 Thread Vincent St-Amour
At Wed, 15 Jan 2014 12:31:29 -0500,
mfl...@racket-lang.org wrote:
 +@history[#:added 6.0.0.1]

IIUC, x.y.z.w versions are not usually user-visible (at least, they
don't correspond to any released version). Do we want to expose them in
the docs?

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


Re: [racket-dev] release notes draft

2014-01-13 Thread Vincent St-Amour
These release notes look good to me, but maybe a bit short.

Since this is our first release with new features since 5.3.4 last May,
I would have expected a longer list. For example, during the previous
release notes discussion, Jay and Neil had some bullets that I don't see
on this list. There also were a lot more things in Robby's original
email.

If we want to keep the announcement itself short, should we point to the
various HISTORY.txt files where users can get more details?

Vincent



At Sat, 11 Jan 2014 20:27:21 -0600,
Robby Findler wrote:
 
 [1  multipart/alternative (7bit)]
 [1.1  text/plain; UTF-8 (7bit)]
 Below is the latest release notes draft. Comments?
 
 Robby
 
 
 
 Racket has a new package system, including a catalog of already available
 packages. Please visit
 
  http://pkgs.racket-lang.org/
 
 for an overview.
 
 Recent releases included the beta versions of the package system.
 Racket version 6.0 incorporates many improvements suggested by these
 preliminary experiences:
 
  * A package is treated as a single collection by default, so it is even
easier to use a Github repository as a package. Get started quickly:
  http://docs.racket-lang.org/pkg/getting-started.html
 
  * DrRacket includes a new package manager GUI, which is also available
as a stand-alone program via the gui-pkg-manager package.
 
  * The main Racket distribution has been broken into about 200 packages. An
installation starts with Minimal Racket and then adds these bundled
 packages.
 
Alternatively, you may now install a Minimal Racket distribution ---
which is about 1/10 the size of the main distribution --- and add only
those packages that you need.
 
  * Package installation supports pre-built packages that include
compiled byte code and rendered documentation, meaning packages can be
installed quickly when built versions are a available. All packages in
the main distribution are available in pre-built form.
 
 Further improvements are in the works, including package documentation on
 the package-catalog web site.
 
 COMPATIBILITY NOTE: PLaneT will remain in place for the foreseeable future,
 but we expect all package work to shift to the new system.
 
 Beyond the package system, this release brings a number of other changes:
 
  * Racket's HTML documentation has a new and improved look, thanks to
Matthew Butterick.
 
  * Racket's JIT compiler supports the ARM architecture.
 
  * Racket supports the Mac's Retina display mode.
 
  * The profiler provides a new mode that uses the errortrace library to
produce fine-grained profiles.
 
  * A new contract profiler reports how much time programs spend checking
contracts, and which contracts are most expensive.
 
  * The math/flonum library exports fast 105-bit precision operations.
 
  * Check Syntax handles generated identifiers, especially those
introduced by struct (e.g. field selectors) and Redex (e.g., e_1, e_2)
 
  * 2htdp/batch-io includes functions for dealing with html/xml in files and
web sites as X-expressions plus conveniences for web-based graph
 traversals.
 [1.2  text/html; UTF-8 (quoted-printable)]
 
 [2  text/plain; us-ascii (7bit)]
 _
   Racket Developers list:
   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] release notes draft

2014-01-13 Thread Vincent St-Amour
At Mon, 13 Jan 2014 12:25:06 -0600,
Robby Findler wrote:
 
 [1  text/plain; UTF-8 (7bit)]
 On Mon, Jan 13, 2014 at 11:05 AM, Vincent St-Amour 
 stamo...@ccs.neu.eduwrote:
 
  These release notes look good to me, but maybe a bit short.
 
  Since this is our first release with new features since 5.3.4 last May,
  I would have expected a longer list. For example, during the previous
  release notes discussion, Jay and Neil had some bullets that I don't see
  on this list. There also were a lot more things in Robby's original
  email.
 
 
 I spoke with Neil privately about the changes and got some agreement and my
 list was not intended as a list of things that were all to be included.
 
 I probably just made a mistake: would you mind helping me fix it? A
 candidate bullet would be great!

A few from your original list, in no particular order:

* The `gen:set' generic interface extends set operations to work on
  user-defined types that implement set methods, as well as on other
  set-like built-in types, such as lists.

* Picts can now be converted to the svg format.

* Racket now provides desktop entries (.desktop files) for its graphical
  executables.

* The documentation now includes a style guide: How to Program Racket.

* DrRacket now provides support for color schemes.

  If we want to keep the announcement itself short, should we point to the
  various HISTORY.txt files where users can get more details?
 
 
 I'm happy to do this too, but less excited about it, especially since we've
 now got a much better mechanism that we can use in the next release and
 we've not done this past releases.

No problem. With the bullets above, I think we have enough.

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


Re: [racket-dev] Pre-Release Checklist for v6.0, corrected url

2013-12-16 Thread Vincent St-Amour
At Mon, 16 Dec 2013 11:38:32 -0500,
Ryan Culpepper wrote:
 * Sam Tobin-Hochstadt sa...@ccs.neu.edu,
Vincent St-Amour stamo...@ccs.neu.edu
   - Match Tests
   - Typed Racket Tests

Done.

   - Typed Racket Updates: update HISTORY
   (updates should show v6.0 as the most current version; email me
   to pick the changes when they're done, or tell me if there are no such
   changes.)

Coming soon.

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


Re: [racket-dev] Pre-Release Checklist for v6.0, corrected url

2013-12-16 Thread Vincent St-Amour
At Mon, 16 Dec 2013 16:29:25 -0500,
Vincent St-Amour wrote:
- Typed Racket Updates: update HISTORY
(updates should show v6.0 as the most current version; email me
to pick the changes when they're done, or tell me if there are no such
changes.)
 
 Coming soon.

Pushed. It's commit ac480e753557 .

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


Re: [racket-dev] [plt] Push #27767: master branch updated

2013-11-15 Thread Vincent St-Amour
At Thu, 14 Nov 2013 20:37:28 -0500,
Neil Toronto wrote:
 For the following program, on my computer, the new random - 
 unsafe-flrandom optimization slows down the first loop and speeds up
 the second:
 
 #lang typed/racket
 
 (require math/flonum
  racket/unsafe/ops)
 
 (define g (current-pseudo-random-generator))
 (define bx (make-flvector 1))
 
 (for: ([_  (in-range 5)])
   (time (for: ([_  (in-range 500)])
   (unsafe-flvector-set! bx 0 (random)
 (newline)
 
 (for: ([_  (in-range 5)])
   (time (for: ([_  (in-range 500)])
   (unsafe-flvector-set! bx 0 (random g)

On my machine, both are faster with the new optimization (first one is
~756ms before and ~675 after, second is ~361 before and ~223 after).
How big is the slowdown you're seeing on the first one?

Unless you're seeing a huge slowdown, I'm not too worried. This new
optimization moves work from the runtime to Racket code, so as the JIT
gets better, the new version will get better (which is what happened
with, e.g., vector bounds checking elimination).

 (I'm going to speed up the math library's samplers by caching the
 parameter value and using the new `flrandom', but of course that's a
 separate issue.)

The latest version of Optimization Coach can help you with that. It now
reports implicit dereferences of `current-pseudo-random-generator'.

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


[racket-dev] `collection-path' Considered Brittle

2013-11-04 Thread Vincent St-Amour

While looking at Asumu's `raco-find-collection' package, Asumu and I
noticed something about the `collection-path' function that made us
uncomfortable.

`collection-path' returns *a* path where the given collection is
located. With the package system, there can now be *multiple* such
paths. `collection-path' returns the first one (in alphabetical order of
package name, at first glance).

This means that installing a package that extends collection `foo' can
break code that uses `(collection-path foo)'.

For an example that's currently broken, what used to be an arrow in the
macro stepper window is now a box with an X in it. The macro stepper
looks for that arrow in the `icons' collection, which is now split
between two packages. `collection-path' returns the path from the
package that doesn't contain that arrow.


A solution would be to provide a `collection-paths' function, that
returns *all* the relevant paths, and add a big warning to the
documentation of `collection-path'. A `collection-paths' function
already exists in
`pkgs/compiler-pkgs/compiler-lib/compiler/commands/test.rkt'.


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


Re: [racket-dev] `collection-path' Considered Brittle

2013-11-04 Thread Vincent St-Amour
At Mon, 4 Nov 2013 11:49:44 -0600,
Robby Findler wrote:
 collection-path is legacy and should generally be removed when you find it
 (I think I fixed two uses of it Saturday in fact).

The documentation does mention that `collection-file-path' is usually
preferred, but it doesn't make it clear that `collection-path' is
legacy. I'll think of a stronger wording.

 But hopefully you could use collection-file-path in most cases instead of a
 collections-path function.

I pushed a fix for the macro stepper, using `collections-file-path'.

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


Re: [racket-dev] [plt] Push #27395: master branch updated

2013-08-30 Thread Vincent St-Amour
I was thinking of the `Set' type constructor as meaning generic set,
which is why I gave that type to `generic-set?'. This interpretation is
a problem because TR treats sets as covariant.

If we make sets invariant, could TR support generic sets? [1] Or are
there other issues I'm missing?

Vincent


[1] Better support would also include subtyping between lists and sets.


At Fri, 30 Aug 2013 16:38:11 -0700,
Eric Dobson wrote:
 
 Isn't the assymetric check the wrong way? If it returns true, we know
 nothing because it might not be a hash-set, but if it returns false
 then we know that it is not a hash set?
 
 On Fri, Aug 30, 2013 at 3:30 PM, Asumu Takikawa as...@ccs.neu.edu wrote:
  On 2013-08-30 16:15:23 -0400, Sam Tobin-Hochstadt wrote:
  I worry about mutable sets here, but I can't think of any bugs it can
  cause ATM.
 
  I don't have any segfault-causing bugs, but here's a violation of the blame
  theorem:
 
#lang racket
 
(module a0 racket
  (define s (mutable-set 1 2 3))
  (provide s))
 
(module a typed/racket
  (require/typed (submod .. a0) [s Any])
  (: x (Setof Any))
  (define x (assert s generic-set?))
  (provide x))
 
(require 'a)
x
 
  Cheers,
  Asumu
  _
Racket Developers list:
http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] [plt] Push #27395: master branch updated

2013-08-30 Thread Vincent St-Amour
I'll fix `generic-set?''s type to work with `Set's as hash sets.

Vincent


At Fri, 30 Aug 2013 17:40:18 -0700,
Eric Dobson wrote:
 
 As it stands the Set type constructor is for hash sets. Changing that
 would break backwards compatibility and pr13989 is for the issue of
 changing the meaning/any change.
 
 I think there is a bunch of existing code that assumes that Set is
 exactly hashsets, or at least covariant.
 
 On Fri, Aug 30, 2013 at 5:37 PM, Vincent St-Amour stamo...@ccs.neu.edu 
 wrote:
  I was thinking of the `Set' type constructor as meaning generic set,
  which is why I gave that type to `generic-set?'. This interpretation is
  a problem because TR treats sets as covariant.
 
  If we make sets invariant, could TR support generic sets? [1] Or are
  there other issues I'm missing?
 
  Vincent
 
 
  [1] Better support would also include subtyping between lists and sets.
 
 
  At Fri, 30 Aug 2013 16:38:11 -0700,
  Eric Dobson wrote:
 
  Isn't the assymetric check the wrong way? If it returns true, we know
  nothing because it might not be a hash-set, but if it returns false
  then we know that it is not a hash set?
 
  On Fri, Aug 30, 2013 at 3:30 PM, Asumu Takikawa as...@ccs.neu.edu wrote:
   On 2013-08-30 16:15:23 -0400, Sam Tobin-Hochstadt wrote:
   I worry about mutable sets here, but I can't think of any bugs it can
   cause ATM.
  
   I don't have any segfault-causing bugs, but here's a violation of the 
   blame
   theorem:
  
 #lang racket
  
 (module a0 racket
   (define s (mutable-set 1 2 3))
   (provide s))
  
 (module a typed/racket
   (require/typed (submod .. a0) [s Any])
   (: x (Setof Any))
   (define x (assert s generic-set?))
   (provide x))
  
 (require 'a)
 x
  
   Cheers,
   Asumu
   _
 Racket Developers list:
 http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Manual inlining destroys performance for this program

2013-08-27 Thread Vincent St-Amour
It looks like you may want `define-inline' from `racket/performance-hint'.

Vincent



At Thu, 22 Aug 2013 11:11:51 -0400,
Sam Tobin-Hochstadt wrote:
 
 Ah, indeed.  I'm calling `random` in the closure now.  Fixing that
 removes the anomaly.
 
 Sam
 
 On Thu, Aug 22, 2013 at 11:05 AM, Matthew Flatt mfl...@cs.utah.edu wrote:
  At Thu, 22 Aug 2013 10:59:35 -0400, Sam Tobin-Hochstadt wrote:
  This short program generates a lot of closures, and thus doesn't run very 
  fast.
 
  #lang racket/base
 
  (require racket/flonum)
 
  (define (Point x0 x1 y0 y1)
(list (λ () (let ([x (- x1 x0)] [y (- y1 y0)])
  (flsqrt (+ (* x x) (* y y)))
 
  (define iter 1e4)
  (for ([i (in-range iter)])
(define p (Point (random) (random) (random) (random)))
(define f (car p))
(for ([i (in-range 1e3)])
  (f)))
 
  I tried manually inlining `Point` by replacing `define` with
  `define-syntax-rule`, and the program gets about 8x *slower*.  I don't
  have any idea why this is happening, especially since `Point` is
  actually inlined by the optimizer in the `define` case.
 
  Any idea why this might be?
 
  Using `define-syntax-rule' changes the program from
 
   (let ([x (random)])
 (call-a-lot (lambda () x)))
 
  to
 
   (call-a-lot (lambda () (random)))
 
 
  Did you mean to try
 
   (define (Point x0 x1 y0 y1)
 (let ([x (- x1 x0)] [y (- y1 y0)])
   (let ([v (flsqrt (+ (* x x) (* y y)))])
 (list (λ () v)
 
  ?
 
 
 _
   Racket Developers list:
   http://lists.racket-lang.org/dev

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


Re: [racket-dev] continuation-mark-set-context : Empty Stack Traces?

2013-08-13 Thread Vincent St-Amour
Thanks!

At this point, that same benchmark has about 1 empty stack trace per 300
samples, which should be good enough.

Vincent


At Mon, 12 Aug 2013 17:25:38 -0600,
Matthew Flatt wrote:
 
 I've pushed a repair for the main problem on x86_64 Linux (and other
 platforms that use DWARF-based stack unwind).
 
 A related symptom I had noticed was that building without gcc
 optimization used disabled stack traces; that's now fixed.
 
 There are still ways to end up with an empty stack trace, but it should
 happen much less often.
 
 At Wed, 07 Aug 2013 17:49:57 -0400, Vincent St-Amour wrote:
  
  I'm profiling one of the contract benchmarks[1], and I noticed that
  sometimes (about 10 out of 300 samples), `continuation-mark-set-context'
  would return an empty stack trace. This number is cut down by about half
  if I disable the JIT. These samples seem to be spread out throughout
  execution (i.e. not all at the beginning or at the end).
  
  I think this may be a regression. At least I've never observed that
  before (and since this causes the contract profiler to error (a bug
  which I'll fix), I probably would have noticed).
  
  This may be a problem because it would reduce the precision of the
  profiler by undercounting what actually was on the stack while these
  empty samples are taken.
  
  
  To observe this, clone the contract benchmarks repository[1], then run
  the attached version of render-guide.rkt inside that directory. To count
  the number of empty stack traces, apply the attached patch to the
  profiler.
  
  
  Vincent
  
  
  [1] https://github.com/stamourv/contract-benchmarks
  
  
  
  --
  [application/octet-stream render-guide.rkt] [~/Desktop  open] [~/Temp  
  open]
  
  --
  [application/octet-stream 
  0001-Have-profiler-print-number-of-empty-stack-traces.patch] [~/Desktop  
  open] [~/Temp  open]
  _
Racket Developers list:
http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] Package Update Fails?

2013-08-13 Thread Vincent St-Amour
I had installed Stephen's `graph' package. Then, he pushed a new
version, and I tried updating my install. Here's the error I got:


stamourv@ahuntsic:plt$ raco pkg update graph
Inferred package scope: /home/stamourv/src/plt/racket/share/pkgs
Resolving graph via https://pkg.racket-lang.org
Updating:
  graph
Resolving graph via https://pkg.racket-lang.org
Downloading 
https://github.com/stchang/graph/tarball/5c769639e02fac538b1034a311ea787627b8a7f6
The following uninstalled packages are listed as dependencies of graph:
   base
   data-lib
   rackunit-lib
   racket-doc
   scribble-lib
Would you like to install these dependencies? [Y/n/a/?] y
Resolving base via https://pkg.racket-lang.org
Resolving base via https://planet-compat.racket-lang.org
raco pkg update: cannot find package on catalogs
  package: base


At that point, I tried removing it and reinstalling it. I got this
error:


stamourv@ahuntsic:plt$ raco pkg remove graph
Inferred package scope: /home/stamourv/src/plt/racket/share/pkgs
Removing graph
raco setup: directory: 
#path:/home/stamourv/src/plt/racket/share/pkgs/graph does not exist for 
collection: graph
  context...:
   /home/stamourv/src/plt/racket/collects/setup/setup-unit.rkt:271:2: 
core154
   /home/stamourv/src/plt/racket/collects/setup/setup-unit.rkt:386:4: 
for-loop
   /home/stamourv/src/plt/racket/collects/pkg/main.rkt: [running body]
   /home/stamourv/src/plt/racket/collects/pkg/raco.rkt: [traversing imports]
   /home/stamourv/src/plt/racket/collects/raco/raco.rkt: [running body]
   /home/stamourv/src/plt/racket/collects/raco/main.rkt: [running body]


That directory did exist, though. At that point, the package was not
listed as installed anymore, but I couldn't install it either:


stamourv@ahuntsic:plt$ raco pkg install graph
Resolving graph via https://pkg.racket-lang.org
Downloading 
https://github.com/stchang/graph/tarball/5c769639e02fac538b1034a311ea787627b8a7f6
raco setup: given collection path: graph refers to the same directory as 
another given collection path, graph/graph
  context...:
   /home/stamourv/src/plt/racket/collects/setup/setup-unit.rkt:539:2: 
check-against-all
   /home/stamourv/src/plt/racket/collects/pkg/main.rkt: [running body]
   /home/stamourv/src/plt/racket/collects/pkg/raco.rkt: [traversing imports]
   /home/stamourv/src/plt/racket/collects/raco/raco.rkt: [running body]
   /home/stamourv/src/plt/racket/collects/raco/main.rkt: [running body]


Despite that error, the package was listed as being installed, but it
wouldn't work.

I ended up removing the package directory and removing the link (using
raco link). After that, I was finally able to reinstall the package, and
now everything works.

The old version did not have an `info.rkt' file, but the new one does. I
don't know if that makes any difference.

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


Re: [racket-dev] Package Update Fails?

2013-08-13 Thread Vincent St-Amour
At Tue, 13 Aug 2013 15:59:57 -0600,
Matthew Flatt wrote:
 
 At Tue, 13 Aug 2013 17:23:33 -0400, Vincent St-Amour wrote:
  I had installed Stephen's `graph' package. Then, he pushed a new
  version, and I tried updating my install. Here's the error I got:
  
  
  stamourv@ahuntsic:plt$ raco pkg update graph
  Inferred package scope: /home/stamourv/src/plt/racket/share/pkgs
 
 I think something had gone wrong at this point, because that path looks
 like it should have been found as installation scope.

Right, that's where the package was installed. I had a look at the
source at the time, and that's where I found it.

 If you run `raco pkg show' now, what scope does it show for graph?

I get this now, but that's after all the steps from my previous email,
which involved manually unlining and reinstalling the package:


Installation-wide:
 Package   ChecksumSource
 graph 5c769639e02fac538b1034a311ea787627b8a7f6(catalog 
graph)



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


Re: [racket-dev] Package Update Fails?

2013-08-13 Thread Vincent St-Amour
At Tue, 13 Aug 2013 16:19:28 -0600,
Matthew Flatt wrote:
 
 At Tue, 13 Aug 2013 18:12:12 -0400, Vincent St-Amour wrote:
  At Tue, 13 Aug 2013 15:59:57 -0600,
  Matthew Flatt wrote:
   
   At Tue, 13 Aug 2013 17:23:33 -0400, Vincent St-Amour wrote:
I had installed Stephen's `graph' package. Then, he pushed a new
version, and I tried updating my install. Here's the error I got:


stamourv@ahuntsic:plt$ raco pkg update graph
Inferred package scope: /home/stamourv/src/plt/racket/share/pkgs
   
   I think something had gone wrong at this point, because that path looks
   like it should have been found as installation scope.
  
  Right, that's where the package was installed. I had a look at the
  source at the time, and that's where I found it.
  
   If you run `raco pkg show' now, what scope does it show for graph?
  
  I get this now, but that's after all the steps from my previous email,
  which involved manually unlining and reinstalling the package:
  
  
  Installation-wide:
   Package   Checksum
  Source
   graph 5c769639e02fac538b1034a311ea787627b8a7f6
  (catalog 
  graph)
 
 At this point, does `raco pkg update graph' still show a path for the
 inferred scope?

Yes:

stamourv@ahuntsic:plt$ raco pkg update graph
Inferred package scope: /home/stamourv/src/plt/racket/share/pkgs
Resolving graph via https://pkg.racket-lang.org
No updates available


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


[racket-dev] continuation-mark-set-context : Empty Stack Traces?

2013-08-07 Thread Vincent St-Amour

I'm profiling one of the contract benchmarks[1], and I noticed that
sometimes (about 10 out of 300 samples), `continuation-mark-set-context'
would return an empty stack trace. This number is cut down by about half
if I disable the JIT. These samples seem to be spread out throughout
execution (i.e. not all at the beginning or at the end).

I think this may be a regression. At least I've never observed that
before (and since this causes the contract profiler to error (a bug
which I'll fix), I probably would have noticed).

This may be a problem because it would reduce the precision of the
profiler by undercounting what actually was on the stack while these
empty samples are taken.


To observe this, clone the contract benchmarks repository[1], then run
the attached version of render-guide.rkt inside that directory. To count
the number of empty stack traces, apply the attached patch to the
profiler.


Vincent


[1] https://github.com/stamourv/contract-benchmarks




render-guide.rkt
Description: Binary data


0001-Have-profiler-print-number-of-empty-stack-traces.patch
Description: Binary data
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Generics updates

2013-08-03 Thread Vincent St-Amour
At Fri, 2 Aug 2013 15:33:02 -0400,
Carl Eastlund wrote:
 
 [1  text/plain; UTF-8 (7bit)]
 On Fri, Aug 2, 2013 at 1:47 PM, Stephen Chang stch...@ccs.neu.edu wrote:
 
   With that in mind, I think it would make sense to move `set-first' and
   `set-empty?' to the primitive set (making it clear that they are
   optional, and can be derived from `set-stream' if need be). With those
   two in the primitive set, anything that implements all the primitives
   should get all the derived for free, right?
 
  Oh yeah, I like that better than moving set-stream to primitives
  since they are more standard set operations.
 
 
 So the proposal for primitive methods is to pick one canonical set of
 methods from which all the others can be derived?  I'm fairly sure there's
 more than one such set, and I'm not sure there's one choice that's clearly
 better than the others.

 I can understand the benefits of documenting a
 suggested set, but given that it is an arbitrary and pragmatic
 distinction, I'm not sure I'd want to set them off in a section any more.
 I'd just make a list in the gen:set description or something.

Sounds good to me. As long as there's a clear easy starting point for
someone implementing a new set type, I think we're good.

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


Re: [racket-dev] Generics updates

2013-08-02 Thread Vincent St-Amour
At Thu, 1 Aug 2013 18:56:08 -0400,
Carl Eastlund wrote:
 Ah, yes, set-stream isn't primitive because it can be derived if you have
 set-first and either set-rest or set-remove.  And I know there are
 dependency cycles, this is intentional so that you can implement any one of
 several related things, but most of them were supposed to go all the way
 down to primitive methods (in some sense) if all else failed.
 
 Would it be better to just remove the primitve / derived distinction,
 since it's somewhat artificial, and leave it up to the individual method
 descriptions?  Is there some better way I should be describing things?

I like the primitive / derived distinction, but I don't think that the
distinction should be done based on the presence of fallback
implementations. IMO, it makes more sense to interpret it like Stephen
did: what do I need to write to get a minimum viable set type and get
the rest for free. Presence or absence of fallbacks is just an
implementation detail. If we take that view, then basic (or something)
may make more sense than primitive, though.

With that in mind, I think it would make sense to move `set-first' and
`set-empty?' to the primitive set (making it clear that they are
optional, and can be derived from `set-stream' if need be). With those
two in the primitive set, anything that implements all the primitives
should get all the derived for free, right?

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


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

2013-07-24 Thread Vincent St-Amour
The problems I've observed were only with the tests.

The first problem I reported was caused by a bug/limitation in places,
which was fixed by 733907474190da499a1782b230086170c5b87643. It was
preventing the TR test suite from running properly.

The others were bugs in the TR tests, not in TR itself.

TR itself should be fine for the release.

Vincent



At Wed, 24 Jul 2013 15:03:08 -0500,
Robby Findler wrote:
 
 [1  text/plain; UTF-8 (7bit)]
 Vincent: can you clarify what the status of TR  the release is, please?
 Are there problems only with tests, or were there problems elsewhere too?
 
 Thanks,
 Robby
 
 
 On Tue, Jul 23, 2013 at 9:11 AM, Vincent St-Amour stamo...@ccs.neu.eduwrote:
 
  The TR tests still fail when using a single place.
 
  The following commits should be included in the release:
  069ff59a4bd6a988a5670c7e4dd38c1dbbe12ec0
  0e7940ab4943600e6f5c8f13ce7ee13e8af9a8f5
  ab5075bc762356f86bb7dfd34dac8d24ada1a140
 
  Vincent
 
 
 
  At Mon, 22 Jul 2013 17:49:20 -0400,
  Vincent St-Amour wrote:
  
   At Mon, 22 Jul 2013 15:13:28 -0400,
   Ryan Culpepper wrote:
   
Checklist items for the v5.3.6 release
   (using the v5.3.5.900 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
  
   The Linux/i386/Ubuntu Precise installer is 64 bits, which is wrong.
  
* 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.6 as the most current version; email me
   to pick the changes when they're done, or tell me if there are no
  such
   changes.)
  
   I get the following error when runing the TR tests:
  
   place-channel-put: value not allowed in a message
 value: '#:methods
 ...
  
   Is 733907474190da499a1782b230086170c5b87643 missing from the release?
  
   Now running the tests without places.
  
   Vincent
  _
Racket Developers list:
http://lists.racket-lang.org/dev
 
 [2  text/html; UTF-8 (quoted-printable)]
 
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


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

2013-07-23 Thread Vincent St-Amour
The TR tests still fail when using a single place.

The following commits should be included in the release:
069ff59a4bd6a988a5670c7e4dd38c1dbbe12ec0
0e7940ab4943600e6f5c8f13ce7ee13e8af9a8f5
ab5075bc762356f86bb7dfd34dac8d24ada1a140

Vincent



At Mon, 22 Jul 2013 17:49:20 -0400,
Vincent St-Amour wrote:
 
 At Mon, 22 Jul 2013 15:13:28 -0400,
 Ryan Culpepper wrote:
  
  Checklist items for the v5.3.6 release
 (using the v5.3.5.900 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
 
 The Linux/i386/Ubuntu Precise installer is 64 bits, which is wrong.
 
  * 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.6 as the most current version; email me
 to pick the changes when they're done, or tell me if there are no such
 changes.)
 
 I get the following error when runing the TR tests:
 
 place-channel-put: value not allowed in a message
   value: '#:methods
   ...
 
 Is 733907474190da499a1782b230086170c5b87643 missing from the release?
 
 Now running the tests without places.
 
 Vincent
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] continuation-mark-set-context Regression on 64 bit Linux

2013-07-23 Thread Vincent St-Amour

On 64 bit Linux, `continuation-mark-set-context' doesn't provide any
stack trace anymore, instead always returning the empty list. It was
working at least up to 5.3.4.

When the JIT is disabled, I get the expected stack traces.

This regression breaks the profiler, the contract profiler, and the profiling
features of the Optimization Coach.

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


Re: [racket-dev] continuation-mark-set-context Regression on 64 bit Linux

2013-07-23 Thread Vincent St-Amour
At Tue, 23 Jul 2013 19:29:27 -0500,
Robby Findler wrote:
 Is this in 5.3.6 or in the git head version?

5.3.6 is fine. That was on git HEAD. Matthew's last commit fixed it.

 Is this related to the test failures you reported earlier?

No.

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


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

2013-07-22 Thread Vincent St-Amour
At Mon, 22 Jul 2013 15:13:28 -0400,
Ryan Culpepper wrote:
 
 Checklist items for the v5.3.6 release
(using the v5.3.5.900 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

The Linux/i386/Ubuntu Precise installer is 64 bits, which is wrong.

 * 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.6 as the most current version; email me
to pick the changes when they're done, or tell me if there are no such
changes.)

I get the following error when runing the TR tests:

place-channel-put: value not allowed in a message
  value: '#:methods
  ...

Is 733907474190da499a1782b230086170c5b87643 missing from the release?

Now running the tests without places.

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


[racket-dev] Bash Completion Broken?

2013-07-09 Thread Vincent St-Amour
Bash completion for raco setup (in
pkgs/plt-services/meta/contrib/completion/racket-completion.bash)
is currently broken. It only completes collects that are in the core.
I haven't tried it, but I suspect that zsh completion is similarly
broken.

To find collects to complete, the script looks for subdirectories of the
directories listed in `current-library-collection-paths'. On my current
install, these directories are:

/home/stamourv/src/plt/add-on/5.3.900.5/collects
/home/stamourv/src/plt/racket/lib/collects

which doesn't include package-installed collects. The first directory
also doesn't exist.

Is this a bug in `current-library-collection-paths', or should the
completion script use something else now?


As a side-note, I think that plt-services/meta/contrib should be it's
own package, or maybe even three separate ones (completion, honu.vim and
rubber). If nobody objects, I'll do that.

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


Re: [racket-dev] Bash Completion Broken?

2013-07-09 Thread Vincent St-Amour
At Tue, 9 Jul 2013 10:52:18 -0600,
Matthew Flatt wrote:
 
 At Tue, 09 Jul 2013 12:23:56 -0400, Vincent St-Amour wrote:
  Bash completion for raco setup (in
  pkgs/plt-services/meta/contrib/completion/racket-completion.bash)
  is currently broken. It only completes collects that are in the core.
  I haven't tried it, but I suspect that zsh completion is similarly
  broken.
  
  To find collects to complete, the script looks for subdirectories of the
  directories listed in `current-library-collection-paths'. On my current
  install, these directories are:
  
  /home/stamourv/src/plt/add-on/5.3.900.5/collects
  /home/stamourv/src/plt/racket/lib/collects
  
  which doesn't include package-installed collects. The first directory
  also doesn't exist.
  
  Is this a bug in `current-library-collection-paths', or should the
  completion script use something else now?
 
 The completion script will need to check links, too. (That was
 technically true before, but you didn't have enough links for it to
 matter.)
 
 The example below shows how to get all top-level collection names, but
 I'm not sure that's what you want. 

The completion is used for, e.g., raco setup, so top-level collections
are probably the right thing.

I'll give that a try.

Thanks!

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


Re: [racket-dev] [plt] Push #26936: master branch updated

2013-06-06 Thread Vincent St-Amour
At Thu, 6 Jun 2013 18:39:57 -0400,
Carl Eastlund wrote:
 Also if you're going to memoize things, why are you using assoc rather than
 a hash table?  Or if at all possible, a weak hash table?

I'm using `procedure-closure-contents-eq?' as the equality predicate.
AFAIK, there's no hash table for that.

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


Re: [racket-dev] [plt] Push #26936: master branch updated

2013-06-06 Thread Vincent St-Amour
Maybe. I'll see if I can think of a better solution.

Vincent


At Thu, 6 Jun 2013 17:35:50 -0500,
Robby Findler wrote:
 
 Can't we do better than a memo table?
 
 On Thursday, June 6, 2013, wrote:
 
  stamourv has updated `master' from 5ea3a1ce6d to 6e8c9ed15a.
http://git.racket-lang.org/plt/5ea3a1ce6d..6e8c9ed15a
 
  =[ 2 Commits ]==
  Directory summary:
82.9% collects/racket/contract/private/
17.0% collects/scribblings/reference/
 
  ~~
 
  d1df869 Vincent St-Amour stamo...@racket-lang.org javascript:;
  2013-06-06 18:02
  :
  | Document procedure-closure-contents-eq?.
  :
M collects/scribblings/reference/procedures.scrbl | 5 +
 
  ~~
 
  6e8c9ed Vincent St-Amour stamo...@racket-lang.org javascript:;
  2013-06-06 18:31
  :
  | Memoize wrapped case- range contracts.
  |
  | Fixes failing contract tests.
  :
M collects/racket/contract/private/arrow.rkt | 21 +++--
 
  =[ Overall Diff ]===
 
  collects/racket/contract/private/arrow.rkt
  ~~
  --- OLD/collects/racket/contract/private/arrow.rkt
  +++ NEW/collects/racket/contract/private/arrow.rkt
  @@ -1712,12 +1712,21 @@ v4 todo:
 the domain of
 #:swap? #t)))
dom-ctcs+case-nums)
  -(map (λ (f)
  -   (define p (f rng-blame))
  -   (lambda args
  - (with-continuation-mark
  -  contract-continuation-mark-key blame
  -  (apply p args
  +(map (let ([memo '()])
  +   ;; to preserve
  procedure-closure-contents-eq?ness of the
  +   ;; wrapped procedures, memoize with f
  as the key.
  +   (λ (f)
  + (define target
  +   (assoc f memo
  procedure-closure-contents-eq?))
  + (if target
  + (cdr target)
  + (let* ([p   (f rng-blame)]
  +[new (lambda args
  +
  (with-continuation-mark
  +
   contract-continuation-mark-key blame
  +(apply p args)))])
  +   (set! memo (cons (cons f new)
  memo))
  +   new
rng-ctcs)))
 (define (chk val mtd?)
   (cond
 
  collects/scribblings/reference/procedures.scrbl
  ~~~
  --- OLD/collects/scribblings/reference/procedures.scrbl
  +++ NEW/collects/scribblings/reference/procedures.scrbl
  @@ -88,6 +88,11 @@ to the wrong number of arguments, the resulting error
  hides the first
   argument as if the procedure had been compiled with the
   @indexed-racket['method-arity-error] syntax property.}
 
  +@defproc[(procedure-closure-contents-eq? [proc1 procedure?]
  + [proc2 procedure?]) boolean?]{
  +Compares the contents of the closures of @racket[proc1] and @racket[proc2]
  +for equality by comparing closure elements pointwise using @racket[eq?]}
  +
   @; 
   @section{Keywords and Arity}
 
 

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


Re: [racket-dev] TR tests sometimes fail with a promise error

2013-05-03 Thread Vincent St-Amour
Sam, Asumu and I found and fixed the bug. Here's the problem in a
nutshell.

This is the implementation of `delay/thread' from racket/promise.

(define (delay/thread thunk)
  (let ()
(define (run)
  (call-with-exception-handler
   (lambda (e) (pset! p (make-reraise e)) (kill-thread 
(current-thread)))
   (lambda () (pset! p (call-with-values thunk list)
(define p
  (make-promise/thread
   (make-running-thread
(object-name thunk)
(thread run
p))

`run' depends on `p', and vice versa. The `run' thread may start
executing *before* `p' is actually defined. This causes `pset!' (which
is just promise mutation) to mutate `#undefined', which raises an
exception[1]. The exception handler then calls `pset!' again, which
raises an exception, and kills the thread without setting the promise's
value.

Our solution is to have `run' block on a channel until `p' is fully
initialized. I'll push the fix.

Vincent


[1] Actually, since `pset!' uses `unsafe-struct-set!', there is no
actual exception. The thread gets killed some other way.


At Thu, 2 May 2013 22:27:14 -0400,
Asumu Takikawa wrote:
 
 On 2013-05-02 22:14:44 -0400, Asumu Takikawa wrote:
  This produces a promise error on every third or fifth run or so for me.
  Commenting out the #:when line makes it work, very oddly.
 
 Tried it on another machine, the #:when line didn't matter there. Also,
 I can reproduce this more reliably on a machine with fewer cores.
 
 Cheers,
 Asumu
 _
   Racket Developers list:
   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] TR tests sometimes fail with a promise error

2013-05-03 Thread Vincent St-Amour
At Fri, 3 May 2013 11:56:02 -0400,
Eli Barzilay wrote:
 
 A few minutes ago, Vincent St-Amour wrote:
  Sam, Asumu and I found and fixed the bug. Here's the problem in a
  nutshell.
  
  This is the implementation of `delay/thread' from racket/promise.
  
  (define (delay/thread thunk)
(let ()
  (define (run)
(call-with-exception-handler
 (lambda (e) (pset! p (make-reraise e)) (kill-thread 
  (current-thread)))
 (lambda () (pset! p (call-with-values thunk list)
  (define p
(make-promise/thread
 (make-running-thread
  (object-name thunk)
  (thread run
  p))
  [...]
  Our solution is to have `run' block on a channel until `p' is fully
  initialized. I'll push the fix.
 
 I haven't looked at the code recently, but I think that something
 along these lines can work instead of some explicit syncing:
 
 (define (delay/thread thunk)
   (let ()
 (define p (make-promise/thread #f))
 (pset! p (make-running-thread (thread (λ() ...same...
 p))

I think that introduces another race condition.

If the thread is forced before the `pset!', then `force' would return #f
(line 107 of racket/promise.rkt), since the value inside the `promise/thread'
is not a thread.

Vincent

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


Re: [racket-dev] TR tests sometimes fail with a promise error

2013-05-03 Thread Vincent St-Amour
Sounds good, I'll use a semaphore.

Vincent


At Fri, 3 May 2013 09:58:25 -0600,
Matthew Flatt wrote:
 
 Thanks for tracking this down!
 
 In case you mean a channel in the sense of `make-channel', I recommend
 a semaphore, instead, since a semaphore is the lightest-weight
 synchronization construct.
 
 At Fri, 03 May 2013 11:45:38 -0400, Vincent St-Amour wrote:
  Sam, Asumu and I found and fixed the bug. Here's the problem in a
  nutshell.
  
  This is the implementation of `delay/thread' from racket/promise.
  
  (define (delay/thread thunk)
(let ()
  (define (run)
(call-with-exception-handler
 (lambda (e) (pset! p (make-reraise e)) (kill-thread 
  (current-thread)))
 (lambda () (pset! p (call-with-values thunk list)
  (define p
(make-promise/thread
 (make-running-thread
  (object-name thunk)
  (thread run
  p))
  
  `run' depends on `p', and vice versa. The `run' thread may start
  executing *before* `p' is actually defined. This causes `pset!' (which
  is just promise mutation) to mutate `#undefined', which raises an
  exception[1]. The exception handler then calls `pset!' again, which
  raises an exception, and kills the thread without setting the promise's
  value.
  
  Our solution is to have `run' block on a channel until `p' is fully
  initialized. I'll push the fix.
  
  Vincent
  
  
  [1] Actually, since `pset!' uses `unsafe-struct-set!', there is no
  actual exception. The thread gets killed some other way.
  
  
  At Thu, 2 May 2013 22:27:14 -0400,
  Asumu Takikawa wrote:
   
   On 2013-05-02 22:14:44 -0400, Asumu Takikawa wrote:
This produces a promise error on every third or fifth run or so for me.
Commenting out the #:when line makes it work, very oddly.
   
   Tried it on another machine, the #:when line didn't matter there. Also,
   I can reproduce this more reliably on a machine with fewer cores.
   
   Cheers,
   Asumu
   _
 Racket Developers list:
 http://lists.racket-lang.org/dev
  _
Racket Developers list:
http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] TR tests sometimes fail with a promise error

2013-05-03 Thread Vincent St-Amour
At Fri, 3 May 2013 12:17:46 -0400,
Eli Barzilay wrote:
 
 A few minutes ago, Vincent St-Amour wrote:
  At Fri, 3 May 2013 11:56:02 -0400, Eli Barzilay wrote:
   (define (delay/thread thunk)
 (let ()
   (define p (make-promise/thread #f))
   (pset! p (make-running-thread (thread (λ() ...same...
   p))
  
  I think that introduces another race condition.
  
  If the thread is forced before the `pset!', then `force' would
  return #f (line 107 of racket/promise.rkt), since the value inside
  the `promise/thread' is not a thread.
 
 But this can't happen because `delay/thread' won't return with the
 broken promise until after the `pset!' fixed it.
 
 (Even code in the input thunk will not be able to try to force itself
 without having itself accessible as a value.)

Makes sense. I'll give it a try.

Vincent

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


Re: [racket-dev] TR tests sometimes fail with a promise error

2013-05-03 Thread Vincent St-Amour
I tried your suggestion, and it doesn't fix the original bug.

I'll stick with the semaphores solution.

Vincent



At Fri, 03 May 2013 13:13:45 -0400,
Vincent St-Amour wrote:
 
 At Fri, 3 May 2013 12:17:46 -0400,
 Eli Barzilay wrote:
  
  A few minutes ago, Vincent St-Amour wrote:
   At Fri, 3 May 2013 11:56:02 -0400, Eli Barzilay wrote:
(define (delay/thread thunk)
  (let ()
(define p (make-promise/thread #f))
(pset! p (make-running-thread (thread (λ() ...same...
p))
   
   I think that introduces another race condition.
   
   If the thread is forced before the `pset!', then `force' would
   return #f (line 107 of racket/promise.rkt), since the value inside
   the `promise/thread' is not a thread.
  
  But this can't happen because `delay/thread' won't return with the
  broken promise until after the `pset!' fixed it.
  
  (Even code in the input thunk will not be able to try to force itself
  without having itself accessible as a value.)
 
 Makes sense. I'll give it a try.
 
 Vincent

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


Re: [racket-dev] Release Announcement for v5.3.4, Final Draft

2013-05-01 Thread Vincent St-Amour
At Wed, 1 May 2013 17:35:44 -0400,
Eli Barzilay wrote:
  * The Optimization Coach DrRacket plugin has been moved from the
 Racket distribution to the Racket package repository.
 
 It might be good to include some very quick instructions on how to
 install it.

* The Optimization Coach DrRacket plugin has been moved from the
   Racket distribution to the Racket package repository.
   Install it with: raco pkg install optimization-coach


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


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

2013-04-18 Thread Vincent St-Amour
At Wed, 17 Apr 2013 22:36:52 -0400,
Ryan Culpepper wrote:
 * Sam Tobin-Hochstadt sa...@ccs.neu.edu,
 Vincent St-Amour stamo...@ccs.neu.edu
- Match Tests
- Typed Racket Tests

Everything passes.

- Typed Racket Updates: update HISTORY
(updates should show v5.3.4 as the most current version; email me
to pick the changes when they're done, or tell me if there are no such
changes.)

That's in commit 85eab56 .

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


[racket-dev] Potential Constant Propagation Bug

2013-03-29 Thread Vincent St-Amour

I have found what I think may be a bug in Racket's constant propagation:

   (unsafe-fx* 0 (error 'foo))

does not throw and error and evaluates to 0. If 0 is replaced with
another value, or if it's `read' in, the error is thrown.
`unsafe-fxquotient' has the same issue.

On the one hand, this is an unsafe operation, so maybe I shouldn't
expect the error to be thrown. On the other hand, I would expect
effectful arguments to functions to be evaluated no matter what.

Is this a bug, or is this the desired behavior for unsafe operations?

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


Re: [racket-dev] [plt] Push #26372: master branch updated

2013-02-26 Thread Vincent St-Amour
At Tue, 26 Feb 2013 16:59:01 -0500,
mfl...@racket-lang.org wrote:
 899a327 Matthew Flatt mfl...@racket-lang.org 2013-02-26 14:14
 :
 | add experimental support for phaseless modules
 |

After reading the docs, I find the name phaseless confusing. IIUC,
these modules are not special because they have no phase, but rather
because they're the same at all phases.

Would pan-phase, omni-phase or cross-phase be an accurate
description?

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


Re: [racket-dev] [plt] Push #26224: master branch updated

2013-02-07 Thread Vincent St-Amour
At Wed, 06 Feb 2013 16:16:16 -0700,
Neil Toronto wrote:
 
 On 02/06/2013 03:28 PM, stamo...@racket-lang.org wrote:
  stamourv has updated `master' from bb216d142c to 117c81e2a6.
 http://git.racket-lang.org/plt/bb216d142c..117c81e2a6
 
  =[ One Commit ]=
  Directory summary:
100.0% collects/meta/
 
  ~~
 
  117c81e Vincent St-Amour stamo...@racket-lang.org 2013-02-06 17:22
  :
  | Increase timeout for TR random testing.
  :
 M collects/meta/props | 1 +
 
 Have you been getting timeout messages from DrDr too?

I have.

 I've been getting them for matrix-tests.rkt for the last few days, and 
 just got one for array-tests.rkt. Both are TR programs. From the 
 graph, for the latter, it looks like it's been slowing down over the 
 last week or so with a steep ramp in the last few days that just got 
 over 90 seconds.
 
http://drdr.racket-lang.org/26222/collects/math/tests/array-tests.rkt
 
 I haven't changed `math/array' or `math/matrix' or their tests in the 
 last 16 days. Were there any changes to TR that could have slowed down 
 expansion?

The union for `Number' has recently gotten bigger with the inclusion of
types for imaginaries, which can slow things down. Typechecking of calls
to `=' has also gotten slower, now that its type is used in cases where
a special typing rule (faster, but much less precise) was used. Both
changes were bug fixes.

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


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

2013-01-18 Thread Vincent St-Amour
At Thu, 17 Jan 2013 13:46:37 -0500,
Ryan Culpepper wrote:
 * Sam Tobin-Hochstadt sa...@ccs.neu.edu,
 Vincent St-Amour stamo...@ccs.neu.edu
- Match Tests
- Typed Racket Tests

Both done.

- Typed Racket Updates: update HISTORY

Pushed. Commit e763d1e1ae7cfe04d0fff173292340b6fd6c4ae6 .

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


Re: [racket-dev] Release Announcement for v5.3.2

2013-01-18 Thread Vincent St-Amour
At Thu, 17 Jan 2013 13:57:51 -0500,
Ryan Culpepper wrote:
   - define-inline (b715a6fe)

* Added `define-inline' which defines functions that are guaranteed to
  be inlined.

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


Re: [racket-dev] Five feature/limitation interactions conspire to drive mad

2013-01-03 Thread Vincent St-Amour
At Wed, 02 Jan 2013 16:57:39 -0700,
Neil Toronto wrote:
 
 On 01/02/2013 02:51 PM, Vincent St-Amour wrote:
  In your experience, have these types caused you trouble other than when
  you went looking for them specifically?
 
 Not that I recall. If I stick to union types like Integer, 
 Exact-Rational, Flonum, Real, and Number, they don't often show up. I 
 expect generalization and covariance have a lot to do with it.

Great!

 Of course, these types caused me trouble immediately because I went 
 looking for them immediately, to get optimizations. It's a happy 
 accident that always using Index for bounds and bounds-checked values 
 works out so well. (Unless you planned it?)

That's the reason I added `Index'. Without it, fixnum optimizations
would have been pretty much impossible.

  This brings me to what I think is the major issue for us n00bs: the
  types force you to understand the numeric tower really well if you want
  to use types more precise than `Number'. Before you reach that level of
  understanding, though, and Typed Racket spits errors at you, it's hard
  to tell whether it has a legitimate complaint - especially when you
  don't know whether you should expect, say, (i . fx . 0) to prove i :
  Positive-Index.
 
  Were there specific corners of the tower that you found frustrating
  (other than fixnum types)?
 
 Mostly `sqrt' and `log', when it's hard to prove their arguments are 
 nonnegative. I've gotten around it using `flsqrt' and `fllog'. I was 
 usually working with flonums anyway.

Yep, that's a good workaround (which OC recommends). It would be nice to
also have specialized versions of `sqrt', `log' and co that accept
reals, but raise exceptions instead of returning complex results.

They would still have to internally check for sign before calling `sqrt'
(or `real?' after, if we optimistically call `sqrt'), so they may not be
any faster than doing it inline in user code, but they may still be
convenient.

Would it make sense to provide something like that as part of the math
library?

 One that has bugged me recently is that TR can't prove (* x (conjugate 
 x)) : Nonnegative-Real. I have no idea how you'd do it without turning 
 Number into a product type, though.

With richer types for complexes, this could be expressible. But it would
require duplicating the numeric tower for each component, which would
get very complicated (and slow down typechecking) very fast. We thought
about doing it, but quickly decided against it. The costs clearly
outweight the benefits.

 I almost forgot this one:
 
 (/ (ann 5 Nonnegative-Real) (ann 3 Nonnegative-Real))
- : Real
1 2/3

That one is by design.

- (/ (ann +inf.0 Nonnegative-Real) (ann -0.0 Nonnegative-Real))
- : Real
-inf.0

Considering all the floating-point zeroes to be non-negative (and
non-positive) helps with closure properties, but does cause some
unexpected corner cases. We've thought about that one for a while, and I
think it's the right compromise.

 If you want more, you can grep for `assert' in the math library.

I will, thanks!

  But it's often really hard to prove that something is nonnegative
  without an explicit cast, assertion, or test, and thus stay within the
  reals in expressions with roots.
 
  I actually see that as a positive: if a property is too hard to prove
  using the type system alone, you have the option to use casts,
  assertions, or tests to help TR prove what you want [1]. Casts,
  assertions and tests give you extra power to prove things that you
  couldn't prove otherwise, or to make proofs easier.
 
 We should differentiate between what *I* can prove and what *Typed 
 Racket* can prove. I can usually prove more.

Right. Replace prove with make TR prove in what I said.

Thanks again for the feedback!

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


Re: [racket-dev] Five feature/limitation interactions conspire to drive mad

2013-01-02 Thread Vincent St-Amour
At Wed, 02 Jan 2013 12:39:21 -0700,
Neil Toronto wrote:
  Interesting. My extremely limited experience -- and Shriram's --
  suggests an eternal struggle with the numerical tower for 'beginners'
  like myself.
 
 This is my experience as well.
 
 One place this bit me pretty early was getting TR to optimize loops over 
 indexes *without using casts or assertions*.

Right, fixnum types are tricky. They don't have many closure properties,
so it's hard to stay within these types.

Because of this, we try to avoid exposing these types to beginners as
much as possible (by, e.g., not having functions in the standard library
require them as arguments). The hope is that only experts that are
trying to either (1) get every bit of performance our of their programs
or (2) enforce strict range properties in their programs actually need
to use these types. For the first use case, OC provides some help (and
better support is on the way).

In your experience, have these types caused you trouble other than when
you went looking for them specifically?

 Unfortunately, (i . fx . 0) doesn't prove i : Positive-Index, even 
 though it could.

That's a bug.

 This brings me to what I think is the major issue for us n00bs: the 
 types force you to understand the numeric tower really well if you want 
 to use types more precise than `Number'. Before you reach that level of 
 understanding, though, and Typed Racket spits errors at you, it's hard 
 to tell whether it has a legitimate complaint - especially when you 
 don't know whether you should expect, say, (i . fx . 0) to prove i : 
 Positive-Index.

Were there specific corners of the tower that you found frustrating
(other than fixnum types)?

 It would be really handy if TR could give counterexamples in these 
 cases. This is how you can end up with an exact zero by multiplying an 
 exact rational and a flonum: (* 0 1.0).

Since most TR optimization failures can be traced back to a failure to
typecheck at an optimizable type, Optimization Coach should be able to
help you here. It doesn't currently provide counter-examples, but I'll
look into it.

However, OC requires a program that typechecks, so it doesn't always
apply. Perhaps applying optimization coaching techniques (especially
proximity) to type error messages would work. Worth a try.

 After you do understand the numeric tower well, you start looking for 
 ways to prove to TR that your code won't explode at runtime. It's not 
 always possible - again because, sometimes, the types aren't as precise 
 as they could be. But sometimes because it's just hard.
 
 One fine example is `sqrt'. Its types are sensible:
 
 (sqrt (ann 5 Real))
- : Number
2.23606797749979
 
 (sqrt (ann 5 Nonnegative-Real))
- : Real [generalized from Nonnegative-Real]
2.23606797749979
 
 But it's often really hard to prove that something is nonnegative 
 without an explicit cast, assertion, or test, and thus stay within the 
 reals in expressions with roots.

I actually see that as a positive: if a property is too hard to prove
using the type system alone, you have the option to use casts,
assertions, or tests to help TR prove what you want [1]. Casts,
assertions and tests give you extra power to prove things that you
couldn't prove otherwise, or to make proofs easier.

As for the difficulty of proving properties, specific types could
probably be improved, but I don't have a general solution. Racket's
numeric tower is complicated, and TR needs to be compatible with it.

Thanks for the feedback!

Vincent


[1] Assertions and tests are usually cheap, but casts are surprisingly
expensive since they involve contracts. There's probably room for
improvement there. In the meantime, I'll extend OC to warn you when
you use casts in hot code.
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] TR: Five feature/limitation interactions conspire to drive mad

2012-12-31 Thread Vincent St-Amour
At Mon, 31 Dec 2012 13:27:50 -0700,
Neil Toronto wrote:
   1. Allow submodules to extend the reader.

Would using `#lang typed/racket/no-check' instead of `#lang racket' for
the top-level module work? It extends the reader and provides TR's
annotated forms, but otherwise counts as an untyped language.

That's not a general solution, but it may solve your problem.

   2. Don't generalize argument types in let loops.
 
 This is a bad idea. Often, inferring the types of loops only works 
 because of type generalization.

Agreed. Since this one is only a problem because of the other
limitations you list, ideally we should fix the others and leave this
one alone. Do you agree?

   3. Allow let: loops to have unannotated arguments and return values.
 
 This would totally work. I could use [i : Nonnegative-Fixnum 0] instead 
 of [#{i : Nonnegative-Fixnum} 0], and still not have to annotate `acc' 
 or the loop's return value.

Trying this one right now.

 I think all of TR's annotating forms should allow any annotation to be 
 left out.

I'll look into that next.

   4. Extend the set of types TR can produce contracts for.
 
 This probably only works for first-order function types. It would be 
 helpful, but may not even work for functions with `Array' or `Matrix' 
 arguments (they're higher-order).

I can look into making contract generation smarter. Could you send me
a list of types that caused you issues with contract generation?

 There are two more general solutions to the first problem, that 
 single-arity `case-' types sometimes make annotating impossible:
 
   5. Find some way to name the polymorphic arguments in `case-' types.
 
 Yes. This. At least 25% of my time refactoring `math/matrix' has gone to 
 writing twisty, annotation-free function bodies.

I agree that this would be useful. Sam, do you think this is doable?

In general, we need a better story for scaling up programming with
intersection types.

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


Re: [racket-dev] Contract barrier inefficiencies

2012-12-28 Thread Vincent St-Amour
At Thu, 27 Dec 2012 19:21:53 -0600,
Robby Findler wrote:
 OC could suggest moving heavily called functions across boundaries, that'd
 be cool.

That sounds interesting, and would be a good use of profiling
information. Added to my to-do list.

Thanks for the suggestion!

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


Re: [racket-dev] [plt] Push #25911: master branch updated

2012-12-17 Thread Vincent St-Amour
At Mon, 17 Dec 2012 15:00:04 -0500,
stamo...@racket-lang.org wrote:
 b715a6f Vincent St-Amour stamo...@racket-lang.org 2012-12-14 11:39
 :
 | Add define-inline.
 |
 | Drop-in replacement for define that guarantees inlining.
 :
   M collects/meta/props  | 2 ++
   A collects/unstable/inline.rkt
   A collects/unstable/scribblings/inline.scrbl
   M collects/unstable/scribblings/unstable.scrbl | 1 +

I'm not sure where this should go, so I put it in `unstable' for now.

It's related to `begin-encourage-inline' from `racket/performance-hint'
but since `define-inline' depends on `syntax/parse', I'm hesitant to put
it there.

The new Optimization Coach will recommend using it instead of `define'
in some cases, so maybe it should be provided by OC? It's useful beyond
OC, though, so that doesn't feel like the right place.

Suggestions?

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


[racket-dev] first and rest in racket/base

2012-12-13 Thread Vincent St-Amour
I just got tripped up, again, trying to traverse a list with `first' and
`rest' in a `racket/base' file. `first' and `rest' are only available in
`racket' and `racket/list', but not in `racket/base'.

If we want to encourage use of `first' and `rest' over `car' and `cdr'
and of `racket/base' when possible (which, e.g., the style guide does),
I think it makes sense to provide `first' and `rest' in `racket/base'.

The attached patch implements that change.

Does this sound reasonable?

Vincent




0001-Move-first-and-rest-to-racket-base.patch
Description: Binary data
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] first and rest in racket/base

2012-12-13 Thread Vincent St-Amour
At Thu, 13 Dec 2012 14:51:42 -0500,
Eli Barzilay wrote:
 A few minutes ago, Jay McCarthy wrote:
  I agree with Eli. first is not car and shouldn't be treated as it.
  
  car : (Cons a b) - a
  first : (List a) - a
 
 Right -- it's a different type, and the `list?' check adds a cost.
 
 I don't have too much problem with how they are now -- it's just that
 moving them to the base language makes it easier to think that they're
 the same thing, even more in the presence of the CL thing (where they
 are the same).

`racket/base' already has both `pair?' and `list?', and I don't think
anyone is getting confused. `#lang racket' has all of them, and that
does not seem to cause any issues either.

I could amend my patch to move the documentation of `first' and `rest'
with the other list operations in `racket/base' (`length', `list-ref',
etc.) instead of with `car' and `cdr'. Do you think that would help?

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


Re: [racket-dev] [plt] Push #25861: master branch updated

2012-12-06 Thread Vincent St-Amour
At Thu, 06 Dec 2012 16:27:20 -0700,
Neil Toronto wrote:
 
 On 12/06/2012 04:12 PM, stamo...@racket-lang.org wrote:
  cc8bd4f Vincent St-Amour stamo...@racket-lang.org 2012-12-06 11:59
  :
  | Make srclocs serializable.
  :
 M collects/racket/private/serialize.rkt  | 10 --
 M collects/scribblings/reference/serialization.scrbl | 10 +-
 M collects/tests/racket/serialize.rktl   |  3 +++
 
 Very interesting. What's it for?

A new version of Optimization Coach that integrates with the profiler.
Should be out soon.

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


Re: [racket-dev] [plt] Push #25720: master branch updated

2012-11-20 Thread Vincent St-Amour
Would it make sense to make this available in the `data' collection?

I'm sure it could be useful beyond syntax coloring.

Vincent


At Mon, 19 Nov 2012 23:07:35 -0500,
d...@racket-lang.org wrote:
 
 dyoo has updated `master' from 06db2f9a74 to 3f54afb9fd.
   http://git.racket-lang.org/plt/06db2f9a74..3f54afb9fd
 
 =[ One Commit ]=
 Directory summary:
  100.0% collects/syntax-color/private/
 
 ~~
 
 3f54afb Danny Yoo d...@racket-lang.org 2012-11-19 21:06
 :
 | Add rb-tree implementation in preparation for improving token-tree 
 performance.
 :
   A collects/syntax-color/private/red-black.rkt
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] [PATCH] Add a `zip' procedure to lists

2012-11-09 Thread Vincent St-Amour
Providing `zip' is still useful IMO, both for people who don't know /
remember that trick and as a shorthand.

Vincent



At Fri, 9 Nov 2012 07:34:35 -0500 (EST),
J. Ian Johnson wrote:
 
 [forgot reply all]
 zip is unnecessary because of n-ary map.
 (zip l0 l1) = (map list l0 l1)
 -Ian
 - Original Message -
 From: Diogo F. S. Ramos diogo...@gmail.com
 To: dev@racket-lang.org
 Sent: Thursday, November 8, 2012 11:46:15 PM GMT -05:00 US/Canada Eastern
 Subject: [racket-dev] [PATCH] Add a `zip' procedure to lists
 
 `zip' gathers together each element of each list, in order, returning
 a list of those elements.
 
 For example: (zip (list 4 2) (list 3 5)) = '((4 3) (2 5))
 
 Every list has to have the same length.
 ---
 There was talk in the IRC about implementing a `zip' procedure. Here
 is my try.
 
 Unfortunately I still don't know what is the preferred way to check
 for the validity of the parameters. I tried to copy the style of the
 rest of the file.
 
  collects/racket/list.rkt |9 -
  1 file changed, 8 insertions(+), 1 deletion(-)
 
 diff --git a/collects/racket/list.rkt b/collects/racket/list.rkt
 index fe32f68..18055e5 100644
 --- a/collects/racket/list.rkt
 +++ b/collects/racket/list.rkt
 @@ -32,7 +32,8 @@
   append-map
   filter-not
   shuffle
 - range)
 + range
 + zip)
  
  (define (first x)
(if (and (pair? x) (list? x))
 @@ -407,3 +408,9 @@
  [(end)(for/list ([i (in-range end)])i)]
  [(start end)  (for/list ([i (in-range start end)])  i)]
  [(start end step) (for/list ([i (in-range start end step)]) i)]))
 +
 +(define (zip list1 list2 . lists)
 +  (for ((l (list* list1 list2 lists)))
 +(unless (list? l)
 +  (raise-argument-error 'zip list? l)))
 +  (apply map list (list* list1 list2 lists)))
 -- 
 1.7.9.5
 
 _
   Racket Developers list:
   http://lists.racket-lang.org/dev
 _
   Racket Developers list:
   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Release Announcement for v5.3.1

2012-10-28 Thread Vincent St-Amour
At Wed, 24 Oct 2012 20:29:43 -0400,
Ryan Culpepper wrote:
 stamourv:
   - scheme language deprecation notice (68260a6c86)
   - compat: packages, mutable lists (800a328fe6)
   - NaN included in all float types (a6d5a98b61)

* The `#lang scheme' language is deprecated. `#lang racket' should be
  used instead.

* The `compatibility' collection provides features from Racket relatives,
  such as `defmacro' and mutable lists. These features are provided to
  ease porting code to Racket. We do not recommend using them in modern
  Racket code.

* NaN is included in all of Typed Racket's floating-point types, which
  makes precise floating-point types easier to use.

* Typed Racket provides the `:query-type/args' and `:query-type/result'
  utilities to explore types at the REPL.

* Screenshots of the widgets provided by the Racket GUI library are
  included in the documentation. (Thanks to Diogo F. S. Ramos.)

   - optimization coach changes?

Nothing major.


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


Re: [racket-dev] Release Announcement for v5.3.1

2012-10-28 Thread Vincent St-Amour
For the first one, the new part is the deprecation notice in the
docs. Probably not worth including.

The others items are not major changes. I don't mind if they're not
included.

Vincent


At Sun, 28 Oct 2012 15:38:44 -0500,
Robby Findler wrote:
 
 Is the first one is something new? Otherwise, I'm not sure that any of
 these should be in the release announcement, unless maybe there's something
 I'm missing about the changes?
 
 Robby
 
 On Sunday, October 28, 2012, Vincent St-Amour wrote:
 
  At Wed, 24 Oct 2012 20:29:43 -0400,
  Ryan Culpepper wrote:
   stamourv:
 - scheme language deprecation notice (68260a6c86)
 - compat: packages, mutable lists (800a328fe6)
 - NaN included in all float types (a6d5a98b61)
 
  * The `#lang scheme' language is deprecated. `#lang racket' should be
used instead.
 
  * The `compatibility' collection provides features from Racket relatives,
such as `defmacro' and mutable lists. These features are provided to
ease porting code to Racket. We do not recommend using them in modern
Racket code.
 
  * NaN is included in all of Typed Racket's floating-point types, which
makes precise floating-point types easier to use.
 
  * Typed Racket provides the `:query-type/args' and `:query-type/result'
utilities to explore types at the REPL.
 
  * Screenshots of the widgets provided by the Racket GUI library are
included in the documentation. (Thanks to Diogo F. S. Ramos.)
 
 - optimization coach changes?
 
  Nothing major.
 
 
  Vincent
  _
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.1, Second Call

2012-10-24 Thread Vincent St-Amour
At Mon, 22 Oct 2012 18:11:22 -0400,
Ryan Culpepper wrote:
 * Sam Tobin-Hochstadt sa...@ccs.neu.edu,
 Vincent St-Amour stamo...@ccs.neu.edu
- Match Tests
- Typed Racket Tests

All passed.

Insert large letters is currently broken, though. Sam's on it.

- Typed Racket Updates: update HISTORY
(updates should show v5.3.1 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's on it.

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


Re: [racket-dev] Disjoint unions (from PR 13131)

2012-09-22 Thread Vincent St-Amour
At Sat, 22 Sep 2012 10:52:49 -0400,
Eli Barzilay wrote:
 
 A few minutes ago, Matthias Felleisen wrote:
  
  I consider this problem distinct from Vincent's. 
 
 Yes, the problem is separate (hence moving the discussion) -- it's the
 feature that he mentioned (being able to hide types) that I was
 referring to.
 
 
  I'd argue that the separate this/that constructors exist in your
  mind only.
 
 I'm not following that...  If you're saying that the two constructors
 are not separate, then I'm more than agreeing -- I'm saying that this
 is the main feature of the whole thing: the fact that you cannot treat
 them as separate constructors as far as the type system goes.  Using
 plain structs so there's a separate `This' and `That' types is exactly
 the thing that I want to remove from these type definitions.  To make
 this even more concrete, if the types are hidden, then I cannot write
 this (I'm overloading `This' as both the constructor name and the type
 name):
 
   (: foo : Integer - This)
   (define (foo x) (This x))
 
 The nice feature that Vincent
 describes (and that I didn't know about) is how TR will not show
 hidden types without the explicit introspection tool, so even if I
 leave things for TR's inference, I would see this on the REPL:
 
(This 1)
   - : SOMETHING --- the type is not `This'
   (This 1)

This is not what I'm describing.

If `(This 1)' is used as type `SOMETHING', the TR printer will print the
type as `SOMETHING', and not `(U This That)'. This is what I mean when I
say that the TR printer is smart about named unions.

The introspection tool allows you to look inside `SOMETHING'

 (:type SOMETHING)
(U This That)

In your example, `(This 1)' is not used as type `SOMETHING'. It's just a
`This', so its type gets printed as `This'. If you want all `This's to
always be considered as `SOMETHING's, you can use a wrapper around the
constructor:

(define (This-wrapper x) (Ann (This x) SOMETHING))

What I'm suggesting is that some unions (e.g. `Natural') be opaque even
to the introspection tool. Since there's no way to get something to
typecheck as `Positive-Integer-Not-Fixnum' (the typechecker will never
give that type to anything, it's just a trick to get more precise
intersections) showing it in `:type''s output is confusing.

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


Re: [racket-dev] What are single flonums good for?

2012-09-17 Thread Vincent St-Amour
At Sun, 16 Sep 2012 17:10:01 -0500,
Matthias Felleisen wrote:
 Suppose we had started Racket long ago and maintained it until
 now. Then we'd be looking at 8bit, 16, 32, and 64 precision. In some N
 years from now, we may need 128. (Actually there were machines in the
 past that did, but never mind.)
 
 Could we separate precision and type into separate dimensions so that
 we could state types like this:
 
   ∀ p : precision. FP[p] - FP[p] 
 
 where we see FP as a type constructor that consumes a precision value
 to generate the right kind of type. This might be a dependent type but
 it could be a useful one. Of course, it isn't really a parametric form
 of polymorphism as Neil's functions show (and better still Vincent's
 rewrites).

I think row types can give us that, and clean up other parts of the
numeric tower, too. That's something we've been thinking about for some
time.

Vincent

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


Re: [racket-dev] What are single flonums good for?

2012-09-15 Thread Vincent St-Amour
At Fri, 14 Sep 2012 23:45:43 -0500,
Robby Findler wrote:
 The original message in this thread suggests that there is a type
 Single-Flonum and that it is making Neil wrangle his code to be
 careful about it.

Right, TR supports `Single-Flonum's, but not `f32vector's.

Part of the complexity in Neil's code is due to types, part of it is not.

Assuming he wrote the math library in untyped Racket:

(define (foo x)
   (cond [(double-flonum? x)  (flfoo x)]
 [(single-flonum? x)  (real-single-flonum
   (flfoo (real-double-flonum x)))]
 [else  (flfoo (real-double-flonum x))]))

The code is exactly the same as before. The complexity comes from the
fact that this function, when given single-precision inputs, wants to
produce single-precision outputs, hence the special case.

If Neil wants `foo' to be as flexible as Racket's built-in operations
(which, when given single-precision inputs, produce single-precision
outputs), he needs that special case, types or not.

If he gives up on that flexibility, things become a lot simpler:

(define (foo x)
   (flfoo (real-double-flonum x)))

This version still accepts single-precision inputs, but always produces
doubles.

The types simply mirror that distinction:

(: foo (case- (Single-Flonum - Single-Flonum)
(Flonum - Flonum)
(Real - Real)))

vs

(: foo (Real - Flonum))

This kind of complexity gets worse for functions with multiple arguments,
and types make it worse. When expressing coercion rules, the
implementation can take shortcuts that the type system cannot currently
express, leading to unwieldy types.

These issues only come up when writing libraries that aim to propagate
Racket's numeric flexibility, such as the math library or TR's base
environment. Clients of either don't need to worry about any of that.

Single-precision floats are not the source of this problem (you would
run into the same issues, in both the untyped and typed worlds, with a
function that takes ints to ints and floats to floats), but they do add
one more type to worry about.

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


Re: [racket-dev] What are single flonums good for?

2012-09-12 Thread Vincent St-Amour
Single-precision float support used to be enabled via a configure
option, which meant that some Racket installations would support them,
and some would not.

Since zo files are meant to be portable, they could not contain
single-precision floats. So, compilation would promote single literals
to doubles.

This meant that compilation could change the behavior of a program.
Here's an example:

stamourv@ahuntsic:small-float-test$ cat test2.rkt
#lang racket
(define (f x) (displayln (flonum? x)))
(f (if (with-input-from-string #t read) 1.0f0 2.0f0))
stamourv@ahuntsic:small-float-test$ racket test2.rkt
#f
stamourv@ahuntsic:small-float-test$ raco make test2.rkt
stamourv@ahuntsic:small-float-test$ racket test2.rkt
#t
stamourv@ahuntsic:small-float-test$

This example has to be a bit convoluted to defeat constant folding,
which makes the problem disappear:

stamourv@ahuntsic:small-float-test$ cat test.rkt
#lang racket
(flonum? 1.0f0)
stamourv@ahuntsic:small-float-test$ racket test.rkt
#f
stamourv@ahuntsic:small-float-test$ raco make test.rkt
stamourv@ahuntsic:small-float-test$ racket test.rkt
#f
stamourv@ahuntsic:small-float-test$ raco decompile test.rkt
(begin
  (module test 
(#%apply-values |_print-values@(lib racket/private/modbeg.rkt)| '#f)))
stamourv@ahuntsic:small-float-test$

This can make for pretty elusive bugs. This gets especially problematic
when you add unsafe float operations to the mix, which can turn these
issues into segfaults.

The solution we picked was to support single-precision floats by default
and to allow them in zos, which makes these discrepancies go away.

I agree that having to handle single floats when reasoning about numbers
complicates things, and it annoys me too. But I still think it's less
problematic than what I describe above.


At Wed, 12 Sep 2012 08:31:29 -0600,
Neil Toronto wrote:
 
 I ask because I'm tired of worrying about them. More precisely, I'm 
 tired of Typed Racket (rightly) making me worry about them.
 
 I'm also a little bit tired of this:
 
 (: foo (case- (Single-Flonum - Single-Flonum)
 (Flonum - Flonum)
 (Real - Real)))
 (define (foo x)
(cond [(double-flonum? x)  (flfoo x)]
  [(single-flonum? x)  (real-single-flonum
(flfoo (real-double-flonum x)))]
  [else  (flfoo (real-double-flonum x))]))

This function already converts rationals to doubles, and it seems
`flfoo' produces doubles too. You could drop the second clause, always
produce doubles, change the type to `(Real - Flonum)' and leave the
conversion to single to the client. Since the math library always
operates on doubles internally anyway, this would also eliminate
unnecessary conversions to singles between stages of a pipeline.

 They make it easy to write wrong code, because it's easy to use 
 `exact-inexact' when you really should use `real-double-flonum'. Plot, 
 for example, fails to render functions that return single flonums. I'm 
 surprised it doesn't segfault.

Good point, that's a problem.

 I'm sure plot isn't the only one. Every use of `exact-inexact' in the 
 standard library is suspect. If followed by applying an unsafe op, it's 
 wrong.
 
 Why do we have these things?

I don't know why they were added originally (as an option). In my limited
experience, I don't think I've seen non-test code that uses them.

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


Re: [racket-dev] TR's optimizer eventually going to unbox structs?

2012-08-27 Thread Vincent St-Amour
I don't think it would be necessary.

For the optimization to trigger, the only thing a step in the chain can
do with its argument is use its components. Anything else (e.g. checking
whether it's a substruct) would require the argument to be boxed, and
would prevent the optimization from happening.

Each step of the chain is very limited in what it can do to its
argument, which works fine for complex numbers (most operations on them
only use the components), but I'm not sure it would work well for
structs.

Vincent


At Mon, 27 Aug 2012 10:15:04 -0500,
Robby Findler wrote:
 
 Would you need a and is not a substruct? predicate to make such things work?
 
 Robby
 
 On Mon, Aug 27, 2012 at 10:11 AM, Vincent St-Amour stamo...@ccs.neu.edu 
 wrote:
  TR's complex number optimizations eliminate repeated boxing and unboxing
  in chains of operations that each consume and produce complex numbers.
 
  Similar optimizations for structs would eliminate structs for
  intermediate results in chains of operations that each consume and
  produce that same (single) kind of struct.
 
  If your code has such chains of operations, then these optimizations
  could apply.
 
  Do you have code that you think would benefit that I could look at?
 
  Vincent
 
 
  At Sat, 18 Aug 2012 12:40:21 -0600,
  Neil Toronto wrote:
 
  Is TR's optimizer eventually going to unbox structs in the same way it
  unboxes rectangular flonums?
 
  I have a design choice right now: how to represent probabilities. Floats
  are good because of their speed, but because of floating-point
  limitations, *four different representations* are typically used. (For
  the curious: p, 1-p, log(p), and log(1-p).) I'd like to make functions
  that accept any one of these representations, denoted by this type:
 
 (define-type Probability
   (U probability 1-probability log-probability log-1-probability))
 
  The types are simply struct types that tag Float.
 
  Of course, manually boxing flonums ruins any chance of the compiler
  emitting code that keeps the flonums unboxed. If TR's optimizer unboxed
  structs, though, everything could be speedy.
 
  FWIW, by eventually, I mean within the next n years, where n is a
  smallish number.
 
  Neil ⊥
  _
Racket Developers list:
http://lists.racket-lang.org/dev
 
  _
Racket Developers list:
http://lists.racket-lang.org/dev

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


Re: [racket-dev] Release Announcement for v5.3, third draft

2012-08-02 Thread Vincent St-Amour
At Thu, 02 Aug 2012 11:28:56 -0400,
Ryan Culpepper wrote:
 
 On 08/02/2012 11:16 AM, Ryan Culpepper wrote:
 [...]
 
  * There is now a very complete completion code for zsh.  It is not
 included in the distribution though, get it at: http://goo.gl/DU8JK
 (This script and the bash completions will be included in the
 standard installers in future versions.)
 
 Should we leave this item out and include it in the future, once the 
 scripts are actually included in the distribution?

I'd leave it out. This is unrelated to the release.

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


Re: [racket-dev] `compatibility' (was: [plt] Push #25038: master branch updated)

2012-07-31 Thread Vincent St-Amour
At Tue, 31 Jul 2012 09:26:56 -0700,
Sam Tobin-Hochstadt wrote:
 
 On Tue, Jul 31, 2012 at 6:42 AM, Matthew Flatt mfl...@cs.utah.edu wrote:
 
  To start afresh, here are two suggestions, which are mutually
  exclusive. The first is my preference:
 
   1. Revert the addition of `compatibility/package' and
  `compatibility/mpair', including the documentation changes (but
  maybe add back some text to discourage misuse of these libraries).
 
 I definitely think we should keep `mpair` as a more-than-compatibility
 library.  It's useful in real data structures, and it's nice not to
 have to roll your own mutable linked list when it's the right choice.

Mutable pair functions are in `racket/base', I didn't touch these and am
not planning to. Mutable list functions, though, I moved. The name is
misleading.

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


Re: [racket-dev] A Const type constructor

2012-07-31 Thread Vincent St-Amour
At Tue, 31 Jul 2012 14:36:06 -0400,
Matthias Felleisen wrote:
 
 On Jul 31, 2012, at 1:31 PM, Neil Toronto wrote:
 
  To reiterate after my absence: I won't write a typed math/vector
  until using its exports in Typed Racket wouldn't be a huge friggin'
  PITA.
 
 Let me rephrase this ever so gently. Typed Racket has failed at least
 one real test for now, namely, writing a highly usable math library.

Agreed. The invariance of vectors is a pretty big usability problem here.

 I think this is a fair judgment, and you are posing the obvious, not so
 implied problem to the TR maintainers to fix this problem. They should
 thank you on their knees, especially Vincent.

Yes, Sam and I should fix this.

Neil: I'll study your proposal in detail, and see how we could add it
(or something similar) to TR. Thanks for taking the time to write it out.

I'll have a look at what Scala does, too. AFAIK, they also have
invariant vectors and more than one numeric type, so they probably have
similar problems.

  To offer a carrot instead of a stick: There could be a short paper
  in this, titled The Case for a Clean, Correct, Covariant Const.
 
 That is what I was thinking as I was reading your message. I have not
 encountered such a proposal/language before, and I think it could be a
 really neat extension of Vincent's PADL work.

Agreed. 

 Perhaps the two of you
 should work out the details together and submit follow-up to PADL
 n+1. Oh never mind, D stands for declarative. So ship it to ICFP next
 year, functional languages do include mutation.

Sounds good to me.

Neil: let's continue this discussion off-list.

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


Re: [racket-dev] `compatibility' (was: [plt] Push #25038: master branch updated)

2012-07-31 Thread Vincent St-Amour
At Tue, 31 Jul 2012 13:04:40 -0600,
Matthew Flatt wrote:
 
 At Tue, 31 Jul 2012 14:08:16 -0400, Vincent St-Amour wrote:
  Mutable pair functions are in `racket/base', I didn't touch these and am
  not planning to. Mutable list functions, though, I moved. The name is
  misleading.
 
 Should `compatibility/mpair' be `compatibility/mlist' (while
 `racket/mpair' keeps the misleading name)?

Good idea. I'll do that.

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


Re: [racket-dev] `compatibility' (was: [plt] Push #25038: master branch updated)

2012-07-30 Thread Vincent St-Amour
At Mon, 30 Jul 2012 13:10:28 -0600,
Matthew Flatt wrote:
 
 At Fri, 20 Jul 2012 16:33:54 -0400, Vincent St-Amour wrote:
  How about having a `compatibility' collect, which would include this and
  things like `racket/package' (compatibility with Chez) and `racket/mpair'
  (compatibility with Scheme)? It would be harder to confuse these things
  with blessed Racket features.
 
 Sorry that I'm so late to this thread.
 
 I think a compatibility collection is a good idea, and it's a fine
 place for `defmacro'. I don't think `racket/...' libraries should move
 there, though.
 
 When the next big language shift comes, we should leave out some
 libraries that are now in racket, and then it may make sense to add
 some left-out ones to compatibility. As long as they stick around in
 racket though (for compatibility!), I think there's little advantage
 in adding them to compatibility. 

The main advantage (IMO) of having, say, mutable lists in
`compatibility' is that searching the docs points there instead of to
`racket'. This makes it clear that they are not a blessed Racket
feature. This is (IMO) the main point of the `compatibility' collect.

 FWIW, the `package' form wasn't even intended for compatibility. It was
 intended to support namespace management --- possibly as an expansion
 target for macros --- and to work in contexts other than module top
 levels. It hasn't turned out to be useful, though.

Now that we have submodules, are packages still useful? If not, we
should encourage the use of submodules over packages, and putting
packages in `compatibility' makes it clear that they are not the
preferred option.

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


Re: [racket-dev] `compatibility' (was: [plt] Push #25038: master branch updated)

2012-07-30 Thread Vincent St-Amour
At Mon, 30 Jul 2012 16:00:12 -0400,
Matthias Felleisen wrote:
 Having said that, I would like to propose that we COPY
 files/subcollections from racket/ to compatibility/ (and keep them in
 sync) if we wish to indicate that they are not really rackety.

Assuming you mean keeping the same interface re-providing bindings from
one to the other, as opposed to duplicating the implementation, then
that's what I did.

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


Re: [racket-dev] `compatibility' (was: [plt] Push #25038: master branch updated)

2012-07-30 Thread Vincent St-Amour
At Mon, 30 Jul 2012 14:52:06 -0600,
Matthew Flatt wrote:
 At Mon, 30 Jul 2012 16:00:12 -0400, Matthias Felleisen wrote:
  I fully and enthusiastically agree with this perspective but I don't think 
  this 
  is high on our list of things to do. 
  
  When we consider such moves, we should always consider the opportunity 
  cost. 
  What could I accomplish instead? 
  
  Having said that, I would like to propose that we COPY files/subcollections 
  from racket/ to compatibility/ (and keep them in sync) if we wish to 
  indicate 
  that they are not really rackety. 
 
 That's committed already, so I'm suggesting that we do more work to
 un-commit the change. It's the spirit of avoiding more of the
 kind of work that you suggest we avoid, though.
 
 If we really want to have two names for these things --- the
 compatibility name and the compatibility name --- then I think we
 should at least consolidate to a single compatibility manual by moving
 the documentation for `racket/mpair' and `racket/package' to the
 compatibility manual.

To make sure I understand correctly, you're suggesting that:

- We keep the `compatibility' collect.
- We keep `compatibility/defmacro'.
- We remove `compatibility/mpair' and `compatibility/package', and move
  them back to `racket/mpair' and `racket/package', respectively.
- We leave the reference and the compatibility manual as is, with docs
  for `racket/mpair' and `racket/package' in the compatibility manual.

If that's what you're suggesting, I'll implement it.

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


Re: [racket-dev] [plt] Push #25105: master branch updated

2012-07-29 Thread Vincent St-Amour
At Sun, 29 Jul 2012 10:15:17 -0400,
Matthias Felleisen wrote:
 With all due respect. Was there a reason why parametric imports don't
 work? They do change behavior in a way that doesn't jive with the TR
 port-to-typed-without-change-in-semantics philosophy.

Parametric imports were already in `typed/racket', but were not in
`typed/racket/base'.

This commit fixes `typed/racket/base' to be consistent with
`typed/racket'. It doesn't change the semantics of parametric imports.

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


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

2012-07-26 Thread Vincent St-Amour
At Wed, 25 Jul 2012 13:26:53 -0400,
Ryan Culpepper wrote:
 stamourv:
   - enable performance report for typed/racket/base (b73421f8)

- Optimization Coach (formerly Performance Report) now reports
  information about Racket's inlining optimizations. Optimization Coach
  can be launched in any language through the View menu.

 samth:
- keyword functions in TR (865a2cdc)
- TR load time optimizations (794bfa50, 6bf14151)

- Typed Racket now supports definition of functions with keyword
  arguments.
- Startup time of Typed Racket programs has been reduced.

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


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

2012-07-24 Thread Vincent St-Amour
At Tue, 24 Jul 2012 11:03:16 -0400,
Ryan Culpepper wrote:
 * Sam Tobin-Hochstadt sa...@ccs.neu.edu,
 Vincent St-Amour stamo...@ccs.neu.edu
- Match Tests
- Typed Racket Tests

Both done.

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

Pushed as c5b4906.

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


Re: [racket-dev] [plt] Push #25038: master branch updated

2012-07-20 Thread Vincent St-Amour
At Fri, 20 Jul 2012 16:17:22 -0400,
as...@racket-lang.org wrote:
 3582b57 Asumu Takikawa as...@racket-lang.org 2012-07-20 15:10
 :
 | Move mzlib/defmacro = racket/defmacro

I'm not sure this belongs in `racket'. This is not a Racket feature.
It's closer to a CL compatibility library.

How about having a `compatibility' collect, which would include this and
things like `racket/package' (compatibility with Chez) and `racket/mpair'
(compatibility with Scheme)? It would be harder to confuse these things
with blessed Racket features.

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


Re: [racket-dev] [plt] Push #24958: master branch updated

2012-07-11 Thread Vincent St-Amour
At Wed, 11 Jul 2012 01:33:02 -0400,
Eli Barzilay wrote:
 Or maybe add a new tools collection for other similar things?

I'm about to push the new version of Optimization Coach (formerly
Performance Report). Since it now works with any language (not just TR),
it would make sense to move it outside of the `typed-racket' collect.
It would be a good candidate for the `tools' collection.

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


Re: [racket-dev] [plt] Push #24958: master branch updated

2012-07-11 Thread Vincent St-Amour
(Performance) tuning?

Vincent


At Wed, 11 Jul 2012 10:04:46 -0500,
Robby Findler wrote:
 
 tools seems like too generic of a word. Is there something like
 performance-debugging that isn't so long?
 
 Robby
 
 On Wed, Jul 11, 2012 at 9:58 AM, Vincent St-Amour stamo...@ccs.neu.edu 
 wrote:
  At Wed, 11 Jul 2012 01:33:02 -0400,
  Eli Barzilay wrote:
  Or maybe add a new tools collection for other similar things?
 
  I'm about to push the new version of Optimization Coach (formerly
  Performance Report). Since it now works with any language (not just TR),
  it would make sense to move it outside of the `typed-racket' collect.
  It would be a good candidate for the `tools' collection.
 
  Vincent
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Proposal for a no-argument

2012-07-11 Thread Vincent St-Amour
At Sun, 8 Jul 2012 08:40:41 -0400,
Eli Barzilay wrote:
 Quick summary: I'll remove the #:before-first and #:after-last
 feature.  If anyone wants them, please tell me -- maybe it can be left
 for the spliced case, or maybe they could always be spliced.

+2 to always splicing.

This gives us the additional features without needing the `#:nothing'
argument.

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


Re: [racket-dev] [plt] Push #24958: master branch updated

2012-07-11 Thread Vincent St-Amour
I would prefer the full word, performance.

But with a name like that, I would expect things from
`racket/unsafe/ops' and `racket/performance-hint' to be there. Tuning
doesn't carry the same expectation (to me, at least).

Vincent



At Wed, 11 Jul 2012 10:39:53 -0500,
Robby Findler wrote:
 
 Better than tools, IMO. How about perf? Ie, perf/future-visualizer
 and perf/optimization-coach/ ?
 
 Robby
 
 On Wed, Jul 11, 2012 at 10:10 AM, Vincent St-Amour stamo...@ccs.neu.edu 
 wrote:
  (Performance) tuning?
 
  Vincent
 
 
  At Wed, 11 Jul 2012 10:04:46 -0500,
  Robby Findler wrote:
 
  tools seems like too generic of a word. Is there something like
  performance-debugging that isn't so long?
 
  Robby
 
  On Wed, Jul 11, 2012 at 9:58 AM, Vincent St-Amour stamo...@ccs.neu.edu 
  wrote:
   At Wed, 11 Jul 2012 01:33:02 -0400,
   Eli Barzilay wrote:
   Or maybe add a new tools collection for other similar things?
  
   I'm about to push the new version of Optimization Coach (formerly
   Performance Report). Since it now works with any language (not just TR),
   it would make sense to move it outside of the `typed-racket' collect.
   It would be a good candidate for the `tools' collection.
  
   Vincent
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] [plt] Push #24974: master branch updated

2012-07-11 Thread Vincent St-Amour
At Wed, 11 Jul 2012 09:37:19 -0700,
Neil Toronto wrote:
 On 07/11/2012 09:25 AM, stamo...@racket-lang.org wrote:
  84feb38 Vincent St-Amour stamo...@racket-lang.org 2011-10-11 14:26
  :
  | Enable performance report no matter the language.
  :
 M collects/typed-racket/optimizer/tool/tool.rkt | 21 
  +++--
 
 I can't tell from the overall diff. Does that also include student 
 languages?

Oops, good point. It does.

I'll see how the Macro Stepper avoids that problem, and do the same.

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


Re: [racket-dev] [plt] Push #24958: master branch updated

2012-07-11 Thread Vincent St-Amour
+1

Vincent


At Wed, 11 Jul 2012 12:04:11 -0500,
Robby Findler wrote:
 
 What about naming the collection tuning?
 
 Robby
 
 On Wed, Jul 11, 2012 at 11:34 AM, Vincent St-Amour stamo...@ccs.neu.edu 
 wrote:
  I would prefer the full word, performance.
 
  But with a name like that, I would expect things from
  `racket/unsafe/ops' and `racket/performance-hint' to be there. Tuning
  doesn't carry the same expectation (to me, at least).
 
  Vincent
 
 
 
  At Wed, 11 Jul 2012 10:39:53 -0500,
  Robby Findler wrote:
 
  Better than tools, IMO. How about perf? Ie, perf/future-visualizer
  and perf/optimization-coach/ ?
 
  Robby
 
  On Wed, Jul 11, 2012 at 10:10 AM, Vincent St-Amour stamo...@ccs.neu.edu 
  wrote:
   (Performance) tuning?
  
   Vincent
  
  
   At Wed, 11 Jul 2012 10:04:46 -0500,
   Robby Findler wrote:
  
   tools seems like too generic of a word. Is there something like
   performance-debugging that isn't so long?
  
   Robby
  
   On Wed, Jul 11, 2012 at 9:58 AM, Vincent St-Amour 
   stamo...@ccs.neu.edu wrote:
At Wed, 11 Jul 2012 01:33:02 -0400,
Eli Barzilay wrote:
Or maybe add a new tools collection for other similar things?
   
I'm about to push the new version of Optimization Coach (formerly
Performance Report). Since it now works with any language (not just 
TR),
it would make sense to move it outside of the `typed-racket' collect.
It would be a good candidate for the `tools' collection.
   
Vincent
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] [plt] Push #24958: master branch updated

2012-07-11 Thread Vincent St-Amour
Some tools have components that are required programmatically. E.g., the
macro-debugger's useless requires detector or the graphical debugger
API (which doesn't seem to be documented). Moving them may break code.

But I do agree that a top-level `tool' collect would make sense.

Vincent


At Wed, 11 Jul 2012 21:25:04 -0400,
Matthias Felleisen wrote:
 
 
 Is 'tool' plus flat subcollections really out? 
 
 I am not really keen on 'tuning', plus I see a chance to thin out the 
 collection top-level tree here. 
 
 
 On Jul 11, 2012, at 8:26 PM, Robby Findler wrote:
 
  I like coaching for the (formerly known as) performance report tool. A lot!
  
  I was suggesting tuning for the collection that would house the
  future visualizer and the performance coach and hopefully eventually a
  memory profiler. (And maybe Eli's profiler could move in there someday
  too.)
  
  Robby
  
  On Wed, Jul 11, 2012 at 7:12 PM, Matthias Felleisen
  matth...@ccs.neu.edu wrote:
  
  On Jul 11, 2012, at 7:18 PM, Robby Findler wrote:
  
  Would tuning work?
  
  They were correct, and you conjectured correctly. We conflated 
  'optimization' with 'performance gains.' As everyone knows who has been 
  around real compilers and their writers, some 'optimizations' are 
  'pessimizations' as Keith used to call them. And of course even when 
  'optimizations' reduce the running time and/or the space consumption, they 
  aren't _optimizations_ as John Dennis used to remind us. There is a 
  similar conflation that additional related work pointed out. People tend 
  to confuse 'analysis results' with 'can do optimization'. This is 
  certainly not true for in-lining in Racket and if you know of more those 
  optimizations, I'd love to hear about them.
  
  'Tuning' would work but we decided that 'coaching' was a good term for 
  what was going on from the programmer's perspective. And the word isn't 
  used anywhere else in CS as far as I know, while other terms (including 
  'tuning') are used and may have a different connotation.
  
 
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] [plt] Push #24974: master branch updated

2012-07-11 Thread Vincent St-Amour
At Wed, 11 Jul 2012 18:00:26 -0500,
Robby Findler wrote:
 
 On Wed, Jul 11, 2012 at 1:06 PM, Neil Toronto neil.toro...@gmail.com wrote:
  How about a tools drop-down?
 
  Or Online Optimization Coach (You can do
  it, Vincent!)
 
 I had that same thought, actually: online check syntax is actually
 factored into two parts. DrRacket provides an online expansion service
 and plugins you can register two handlers, one to run in the place
 where the expansion happened that is expected to produce a value to
 send back to the main place where the other handler gets it and can
 update the GUI.
 
 Probably Vincent has fairly little work to break that up; I'd guess
 the more substantial question will be how to reflect the information
 into the GUI in a way that doesn't fight with the check syntax
 information.

Making the two tools combine nicely would take some thought.

Currently, Optimization Coach is probably too slow to be used online,
but I'm planning to work on that. Probably not before the release,
though.

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


Re: [racket-dev] [racket] Insert Pict Box menu item not found in DrRacket

2012-07-10 Thread Vincent St-Amour
At Tue, 10 Jul 2012 09:13:24 -0500,
Robby Findler wrote:
 
 Version 1.2 of cdrswift.plt seems to use the slideshow-insert-pict-box
 string constant, but it is up to version 1.5 now.
 
   http://planet.racket-lang.org/display.ss?package=cdrswift.pltowner=dignatof
 
 Probably best to just leave them in for now.

Should we deprecate it and put it on a 1 year counter? (like
`mzlib/class100')

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


  1   2   >