Re: [racket-dev] make --clone installed pkgs

2015-02-18 Thread Sam Tobin-Hochstadt
That seems like a fair summary and since my preference is clearly the
minority one, I'm happy to stick with 'make as-is'. The new mode for
pulling updates will help, as well.

Sam

On Wed, Feb 18, 2015, 7:52 AM Matthew Flatt mfl...@cs.utah.edu wrote:

 At Tue, 17 Feb 2015 19:59:38 -0500, Sam Tobin-Hochstadt wrote:
  On Tue, Feb 17, 2015 at 6:41 PM, Matthew Flatt mfl...@cs.utah.edu
 wrote:
   At Tue, 17 Feb 2015 14:12:54 -0500, Sam Tobin-Hochstadt wrote:
   Does another system have a Racket-like in-place option (that works
   better)?
 
  I haven't used it, but GHC has an in-place build option where you can
  install packages; see [1].

 I don't have a lot of experience with GHC, but I have talked to some
 GHC and Cabal developers about how they work with the package system.
 Those discussions did not lead me to believe that they have an
 especially smooth system for working with packages and updates in-place
 --- and, in particular, that it's not the way they normally work. I'd
 be happy to hear more from someone who routinely works that way with
 GHC, though.

  I think the closer analogy is to what other software does when you run
  both `make` and `make install` analagous to Racket's unix-style
  installation, since that's the recommended way of building (eg
  Python), just as in-place is the recommended way of building Racket
  from source. I don't think any of those systems update packages when
  running `make install`.

 I'm not sure what you're getting at here. We seem to agree that the
 usual `make` plus `make install` is like Racket's `make unix-style`,
 neither of which updates packages (other than the ones the makefile
 knows about).


   At Tue, 17 Feb 2015 17:40:36 -0500, Matthias Felleisen wrote:
   Speaking as the user I am, I really like it that make updates
   my extra-pkgs.
  
   Package scope provides one a way to get these different behaviors. The
   current `make` updates only packages that are in installation scope,
   and it also sets installation scope to be the default, so that's why
   `make` tends to update everything that is installed. Maybe Sam should
   install additional packages in user scope, and then `make` won't try to
   update them.
 
  I expect that the packages that update for Matthias on `make` are
  packages in main-distribution

 Ah, no. I've helped Matthias when problems break his installation, I've
 noticed that he installs packages not in main-distribution (e.g.,
 marketplace), and I believe he really does want those updated.

 I had that context in mind but didn't think to spell it out as I should
 have.


  As an aside, the reason I don't install in user scope is that I switch
  between Racket implementations regularly, which would lead to
  out-of-date zo errors for all my user packages (instead, I get
  multiple copies of the packages).

 You can give each installation a different name (using `raco pkg config
 --set name ...`) to avoid the collision. That would be an extra step in
 setting up each new installation, though.


 I don't have a strong opinion on whether `make` should update packages
 outside of main-distribution, but the feedback I'm getting is

  * Sam doesn't think they should be updated --- but he also doesn't
want packages in main-distribution updated, so he's going to use
`make as-is`.

  * Everyone else who has spoken up seems to prefer an updating `make`,
so far.



-- 
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/CAK%3DHD%2BbRiPnX%3DuWH2x6UjQTzkEZn5nR-UNb-9Bka8wvZHBx-GA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-dev] make --clone installed pkgs

2015-02-17 Thread Sam Tobin-Hochstadt
On Tue, Feb 17, 2015 at 8:49 PM, Matthias Felleisen
matth...@ccs.neu.edu wrote:

 On Feb 17, 2015, at 7:59 PM, Sam Tobin-Hochstadt wrote:

 I expect that the packages that update for Matthias on `make` are
 packages in main-distribution,


 Personally, I have used the 'same' one-line command
 going back to csv through svn and now git (_update).

 When I write Speaking as the user I am .. I am
 thinking of people like me. Then again, you're
 probably saying that I am the bottom element of
 the lattice of make/update knowledge, so never mind
 what I write.

No, what I mean is that many (all?) of the packages you're thinking of
are ones, like 2htdp, that are part of main-distribution, and thus
you're in a different position than someone who develops packages that
are not part of the distribution.

I certainly don't think you're the bottom element in that lattice --
after all, you've written a shell script to automate your work.

Sam

-- 
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/CAK%3DHD%2BYwVcHtYc%2BKCOMU4bCsLCyzaFwyB-9E8uPzBV8%2BsJvqdg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


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

2015-02-17 Thread Sam Tobin-Hochstadt
On Tue, Feb 17, 2015 at 11:31 AM, Jens Axel Søgaard
jensa...@soegaard.net wrote:
 2015-02-17 14:26 GMT+01:00 Robby Findler ro...@eecs.northwestern.edu:
 I don't think the libraries are sufficient as is, but I would resist
 adding aliases.

 A alternative: Added the word  zip  to the documentation index,
 link it to map and have an example where in (map list ...) is used.

Since `zip` isn't an alias for anything, I think we should add it.

Sam

-- 
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/CAK%3DHD%2BYOu17C96DO0q7HRw5yAQEK0aXurewX%3DeDYEMmHpAz%2BBg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-dev] make --clone installed pkgs

2015-02-17 Thread Sam Tobin-Hochstadt
I think there are two seperable issues here:

1. Can we make `raco pkg update -a` better/more robust in this case?

2. Should `make` run `raco pkg update -a`?

In reverse order:

- I think `make`, by default, shouldn't update anything, and that we
should have a different Makefile target which updates things when
people want that explicitly. The current behavior is especially
problematic because it updates things that aren't in
main-distribution, meaning that it's making potentially arbitrary
breaking changes to software on your computer (not just to core
Racket).

This could be more inconvenient for someone working widely on core
packages, but if they wanted the current behavior it would be just
`make update` (or some other name) instead of `make`. As someone who
does work on a lot of core packages, I'd prefer greater explicitness.

- I think `raco pkg update p` where `p` is a cloned package should
only do anything if (a) the currently-checked-out branch is the one in
the pkg source and (b) the `git merge --ff-only` command would
succeed. Otherwise, I think it should just print a message and leave
the repository as it is. I think that's what I wanted all the times
that this operation has failed in my experience.

Sam

On Tue, Feb 17, 2015 at 9:54 AM, Robby Findler
ro...@eecs.northwestern.edu wrote:
 Sam and I have run into a situation where `make` fails because we've
 set up clone pkgs and made local modifications in a way that makes the
 git commands fail [*].

 My guess is that the right thing to do is for me to know about these
 pkgs and do something special when running make. I'm thinking that I
 could let make finish the initial steps until it gets to the step
 where it updates the pkgs and then do the update step myself and then
 run `make as-is`. But the problem with this is that I don't see what
 command I can run that will update all of the pkgs except the
 problematic ones. Like I could imagine a `raco pkg update
 --all-except-clones` or something, but that feels a bit strange as
 there could be other development modes that would also run into
 similar problems. Maybe `raco pkg update
 --all-things-from-this-catalog
 the-catalog-I-currently-get-main-distribution-from` or something
 along those lines is the way to go? In general, it seems right for me
 to run some commands whose complications are roughly proportional to
 the number of pkgs that I have installed as clones (and where I'm
 actively developing them) but not to run some commands that require me
 to do something special for each pkg that is installed.

 Any ideas? Or am I just missing the right command?

 Thanks,
 Robby

 [*] In my case, in case this suggests a better/different approach to a
 resolution: the `raco pkg update` step eventually gets to this git
 command:

   git merge --ff-only sha1

 where the sha1 is the checksum from the pkg server, I believe. In my
 case, this is a different branch than is currently checked in my
 clone'd pkg and so the git merge command fails (and that command
 failing seems like the right behavior for the setup I'd like to be
 able to use).

 --
 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/CAL3TdONOjL3_y8U_A1ZUoz_1Z%3DE3HjVV8by9e%2B2dS-W2mc51pg%40mail.gmail.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/CAK%3DHD%2BbYrWHAxWssmvXFA%2BA0tco2RDAXwORQj_iwOq%3DpYXzZOA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-dev] In Typed Racket, struct declarations do not work in an internal definition context

2015-01-24 Thread Sam Tobin-Hochstadt
On Thu, Jan 22, 2015 at 3:57 PM, Alexis King lexi.lam...@gmail.com wrote:

 I can work around this in a variety of ways—I can extract this into an
 untyped module and use require/typed, I can use vectors to “fake” structs
 and provide an appropriate interface, etc. Still, I wonder if there are any
 plans to resolve this type of problem? Since it seems to be an issue with
 how TR handles types at its core, I’m not even sure how feasible it would
 be.


I don't currently have plans to work on this problem. The big issue is
that Racket structs are what's called generative, meaning that each
time you execute a struct declaration, you get a different struct
type. Thus it's not at all clear what the right type should be for
your `make-me-a-struct` function, and type systems that do allow this
sort of thing (such as ML) would reject this particular use.

Can you say more about the specific issue you're having? There might
be a different way around it.

Sam

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


Re: [racket-dev] Implementing contracts for async channels

2015-01-15 Thread Sam Tobin-Hochstadt
On Thu, Jan 15, 2015 at 4:33 PM, Alexis King lexi.lam...@gmail.com wrote:
 As an update, I’ve made a bit more progress on this. I’ve implemented an
 impersonate-async-channel function, and I’ve actually included this in the
 exports from racket/contract. I also realized the blame information is
 correct, it works fine. Most of the other issues remain, as well as a few
 new questions:

 There is no impersonate-evt function, so I’m not sure that my implementation
 will work. What should I do about this?
 I’d assume this needs to be documented/tested as well. Where should those
 things be located?

Documentation for contracts is here:
https://github.com/plt/racket/blob/master/pkgs/racket-doc/scribblings/reference/contracts.scrbl
and in the dependent files.

Tests for contracts are here:
https://github.com/plt/racket/tree/master/pkgs/racket-test/tests/racket/contract

Sam



 On Jan 14, 2015, at 23:44, Alexis King lexi.lam...@gmail.com wrote:

 Currently, async channels do not have contracts to check their contents.
 This is a problem for Typed Racket, and it prevents typed code from
 interacting with code that produces async channels.

 I started looking into how to add contracts to the language, and it seems to
 use the chaperones/impersonator system, as I suspected. However, async
 channels obviously cannot be impersonated, so I needed to implement that as
 well.

 I modified the async-channel struct to use generics to allow it to be
 impersonated or chaperoned, which I have exposed by implementing
 chaperone-async-channel. I then tried implementing async-channel/c. The
 internals of the contract system are a little beyond me, but I got a working
 solution by following the example of the box contracts.

 My work thus far can be found here:
 https://github.com/lexi-lambda/racket/commit/84b9f3604891f3f2061fb28ed4800af8afa4751b

 First of all, is this a correct approach? Have I done anything wrong, or
 should I have done anything differently? I didn’t find much documentation on
 the internals of either of these systems, so I mostly went about things as I
 found them.

 Second, obviously, not everything is implemented here. Among the additional
 necessary changes are:

 I need to implement support for impersonators and impersonator contracts
 (right now I’ve only bothered to do chaperones).
 I need to implement async-channel/c-first-order and
 async-channel/c-stronger. I can probably figure out the latter, but I’m not
 even sure what the former is supposed to do.
 I need to implement a wrap-async-channel/c macro for the export. I’m not
 sure how this works, either. From looking at wrap-box/c, it seems to add
 some syntax properties, but I’m not sure what they do or how they work.
 Somehow, the blame information has to be correct. Is that what the wrap
 function does? Or do the async-channel functions need to be updated to
 assign blame?


 I’d really like to get this working, and I think I’m close, but I’m a little
 inexperienced. I’d appreciate any help, even if it’s just pointing me in the
 right direction.

 Thanks!



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


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


Re: [racket-dev] [racket/web-server] 1c6411: Removing out-dated WebSocket implementation

2015-01-14 Thread Sam Tobin-Hochstadt
How does this fit with backward compatibility?

Sam

On Wed, Jan 14, 2015 at 2:26 PM, Jay McCarthy jay.mccar...@gmail.com wrote:
   Branch: refs/heads/master
   Home:   https://github.com/racket/web-server
   Commit: 1c6411c670c1aa86df507a99c64dfc2701d36c0f
   
 https://github.com/racket/web-server/commit/1c6411c670c1aa86df507a99c64dfc2701d36c0f
   Author: Jay McCarthy jay.mccar...@gmail.com
   Date:   2015-01-14 (Wed, 14 Jan 2015)

   Changed paths:
 R web-server-lib/net/websocket.rkt
 R web-server-lib/net/websocket/client.rkt
 R web-server-lib/net/websocket/server.rkt

   Log Message:
   ---
   Removing out-dated WebSocket implementation


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


[racket-dev] Continuous integration for Racket on Windows

2014-12-15 Thread Sam Tobin-Hochstadt
Over the last couple days, I've set up a continuous integration system
for Racket that runs on Windows, using the service provided by
AppVeyor. You can see the current state here:

https://ci.appveyor.com/project/plt/racket

It's configured by the `appveyor.yml` file in the root of the
`plt/racket` repository. It builds Racket on every push.

Currently, it only runs the tests for the core, and unfortunately it
times out before finishing those, so all the builds are failures.
Hopefully we'll be able to reduce the time needed for this so that it
can complete -- I have some ideas.

Right now, it only sends notifications to me on failed builds, but if
you break the build or tests on Windows I'll probably send you an
email.

Happy hacking,
Sam
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] collects search order

2014-12-12 Thread Sam Tobin-Hochstadt
On Fri, Dec 12, 2014 at 8:46 AM, Matthew Flatt mfl...@cs.utah.edu wrote:
 At Thu, 11 Dec 2014 17:00:14 -0800, Dan Liebgold wrote:
 If I use the -X and -S command line parameters to Racket to make my local
 collects dir the first one searched, it makes it so I can't do (require
 srfi/1).

 Yes, this is subtle and confusing.

 Is there something special about the srfi package? (it's layout seems
 different)

 The `srfi/1` library is installed as a package, so it's not in the main
 collects tree. Package paths are registered in etc/config.rktd.
 When that file isn't present or doesn't explicitly list the location of
 packages, then the default location is within the share directory.
 The default location of the share directory, in turn, is ../share.

 (I'm using paths for an in-place installation; the details vary for a
 Unix-style installation, or I may have a detail slightly wrong, but
 it's about the same.)

 The ../share path is relative... to what? It turns out that it's
 relative to the main collects directory. So, when you provide `-X`,
 you're also changing the location of package installations.

 It may seem odd that the default location of packages (and even the
 configuration file) is derived from the main collects path, but it's
 part of a delicate balance of configuration options that keeps many old
 things working, enables `make` in the top-level of the Racket
 repository, and so on. The default paths are convenient for some
 purposes and inconvenient for others.


 To take control of the various paths, create a configuration file as
 config.rktd, and then point Racket at that file's directory using
 `-G`. For example, if I copy the collects directory of my
 installation to /tmp/collects, then

   racket -X /tmp/collects -l srfi/1

 fails, as you say. But if I create /tmp/etc/config.rktd with the
 content

  #hash((share-dir . /original/path/to/racket/share))

I have a couple follow-ups to this answer (which was very helpful for
things I want to do).

If I use a special config.rktd file, perhaps like:

#hash((pkgs-search-dirs . (/tmp/pkgs #f)))

so that I can install some packages without affecting the main Racket
installation, what will be different when running `racket -G /tmp/etc`
versus running plain `racket`? In particular, will there be packages,
links, or collections that I can `require` with plain `racket` that I
won't find with `-G /tmp/etc`? I see that the installation-name is
different, and the default pkg scope is different, and the result of
`(pkg-config-catalogs)` is now missing
file:///home/samth/sw/plt/racket/share/pkgs-catalog. Is there
anything else I'll lose? Is the best way to keep this information to
read the original config.rktd, turn paths into absolute paths, and
then add that contents to the new config.rktd that I create?

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


Re: [racket-dev] The repository is now split

2014-12-05 Thread Sam Tobin-Hochstadt
The rate limit only applies to API calls, not to downloads, so I don't
think that could be it.

Sam

On Fri, Dec 5, 2014 at 1:07 PM, Stephen Chang stch...@ccs.neu.edu wrote:
 Typed make and it timed out again.

 Could it be a github rate limit?
 https://developer.github.com/v3/rate_limit/
 https://developer.github.com/v3/#rate-limiting


 Downloading 
 https://github.com/racket/distributed-places/tarball/917d33e217b3b4897fd86a5a8116087b0714b279
 Downloading 
 https://github.com/racket/racklog/tarball/71bc8cb3dff36f343d6cdaa05e257e34def8d757
 Downloading 
 https://github.com/racket/rackunit/tarball/7300f625d56940667657dc3170acf728bf171992
 Downloading 
 https://github.com/racket/readline/tarball/a6298fd5370f9647f815c813cb5ad3032a2c0487
 tcp-connect: connection failed
   address: github.com
   port number: 443
   step: 6
   system error: Connection timed out; errno=110
   context...:


 On Fri, Dec 5, 2014 at 1:00 PM, Stephen Chang stch...@ccs.neu.edu wrote:
 Did a fresh clone and then make (Debian 7.4) and got the error below,
 even though git is not down. Do we need to increase the timeout?

 Downloading 
 https://github.com/racket/icons/tarball/d6ec572b628874361c104858dad2a574119872fb
 Downloading 
 https://github.com/racket/images/tarball/3458568c6ba363ae9510adf4ec5001aef582f651
 Downloading 
 https://github.com/racket/lazy/tarball/fca189e90c6ab9bb5101d99b67d57c9ba010b83c
 tcp-connect: connection failed
   address: codeload.github.com
   port number: 443
   step: 6
   system error: Connection timed out; errno=110
   context...:

 On Thu, Dec 4, 2014 at 2:58 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
 In cooperation with Sam, I've pushed a change to the way that `make`
 links the content of pkgs. If you run `make` again, it should tell
 you to delete your old

   racket/etc/config.rktd


 Also, the native-pkgs submodule is gone. The problem that John saw
 with libintl.8.dylib has been fixed by updating the native-library
 packages on pkgs.racket-lang.org. You'll need to use `raco pkg
 update` to get those updates!

 For now, use `git pull` to update core Racket and the handful of
 packages in pkgs. Use `raco pkg update` to update anything else. We
 expect to make `raco pkg update` apply to everything (i.e., to imply a
 `git pull` in the main repository's directory), but we're not there,
 yet.

 _
   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] The repository is now split

2014-12-05 Thread Sam Tobin-Hochstadt
The bug in frtime has been fixed now.

Sam

On Fri, Dec 5, 2014 at 3:06 PM, Stephen Chang stch...@ccs.neu.edu wrote:
 One more error, with frtime:

 raco setup: 3 making: pkgs/frtime
 raco setup: 3 making: pkgs/frtime/pkgs
 raco setup: 3 making: pkgs/frtime/pkgs/frtime (FrTime)
 racket/share/pkgs/frtime/pkgs/frtime/animation.rkt:1:18: cannot open module 
 file
   module path: frtime
   path: /home/stchang/plt-split/racket/share/pkgs/frtime/main.rkt
   system error: No such file or directory; errno=2
   context...:
standard-module-name-resolver
/home/stchang/plt-split/racket/collects/compiler/cm.rkt:315:0: compile-zo*
/home/stchang/plt-split/racket/collects/compiler/cm.rkt:519:26
/home/stchang/plt-split/racket/collects/compiler/cm.rkt:511:42
/home/stchang/plt-split/racket/collects/compiler/cm.rkt:476:0:
 maybe-compile-zo
/home/stchang/plt-split/racket/collects/compiler/cm.rkt:591:2: do-check
/home/stchang/plt-split/racket/collects/compiler/cm.rkt:673:4
/home/stchang/plt-split/racket/collects/setup/parallel-do.rkt:431:20: loop

 On Fri, Dec 5, 2014 at 1:07 PM, Stephen Chang stch...@ccs.neu.edu wrote:
 Typed make and it timed out again.

 Could it be a github rate limit?
 https://developer.github.com/v3/rate_limit/
 https://developer.github.com/v3/#rate-limiting


 Downloading 
 https://github.com/racket/distributed-places/tarball/917d33e217b3b4897fd86a5a8116087b0714b279
 Downloading 
 https://github.com/racket/racklog/tarball/71bc8cb3dff36f343d6cdaa05e257e34def8d757
 Downloading 
 https://github.com/racket/rackunit/tarball/7300f625d56940667657dc3170acf728bf171992
 Downloading 
 https://github.com/racket/readline/tarball/a6298fd5370f9647f815c813cb5ad3032a2c0487
 tcp-connect: connection failed
   address: github.com
   port number: 443
   step: 6
   system error: Connection timed out; errno=110
   context...:


 On Fri, Dec 5, 2014 at 1:00 PM, Stephen Chang stch...@ccs.neu.edu wrote:
 Did a fresh clone and then make (Debian 7.4) and got the error below,
 even though git is not down. Do we need to increase the timeout?

 Downloading 
 https://github.com/racket/icons/tarball/d6ec572b628874361c104858dad2a574119872fb
 Downloading 
 https://github.com/racket/images/tarball/3458568c6ba363ae9510adf4ec5001aef582f651
 Downloading 
 https://github.com/racket/lazy/tarball/fca189e90c6ab9bb5101d99b67d57c9ba010b83c
 tcp-connect: connection failed
   address: codeload.github.com
   port number: 443
   step: 6
   system error: Connection timed out; errno=110
   context...:

 On Thu, Dec 4, 2014 at 2:58 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
 In cooperation with Sam, I've pushed a change to the way that `make`
 links the content of pkgs. If you run `make` again, it should tell
 you to delete your old

   racket/etc/config.rktd


 Also, the native-pkgs submodule is gone. The problem that John saw
 with libintl.8.dylib has been fixed by updating the native-library
 packages on pkgs.racket-lang.org. You'll need to use `raco pkg
 update` to get those updates!

 For now, use `git pull` to update core Racket and the handful of
 packages in pkgs. Use `raco pkg update` to update anything else. We
 expect to make `raco pkg update` apply to everything (i.e., to imply a
 `git pull` in the main repository's directory), but we're not there,
 yet.

 _
   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


[racket-dev] The repository is now split

2014-12-04 Thread Sam Tobin-Hochstadt
I've just push a change to the plt repository that removes almost all
the packages.

The split repositories are all in the `racket` organization on GitHub.
You can see them here: https://github.com/racket/

I *highly* recommend creating a new clone of the repository, and
re-running `make`. This will install all of the packages in
main-distribution and main-distribution-test from the package
catalog.

There are a number of problems with the current Makefile setup, which
we're working on fixing, but which you'll need to know about for a
little while (hopefully not more than today).

* If you specify an explicit set of PKGS on the `make` command line,
that will NOT work.
* If you have user-installed Planet packages, there may be errors.

If you encounter other errors, please let me know, either by replying
or by finding me on IRC.

If you run `make` and then you want to edit and commit to a package
such as rackunit, run the following commands inside your git
checkout:

  $ mkdir extra-pkgs
  $ cd extra-pkgs
  $ raco pkg update --clone rackunit

That will create a git checkout in the extra-pkgs/rackunit directory.
The `extra-pkgs` directory is set up to be ignored by the top-level
git checkout, so it's a good place to put package checkouts.

This will almost certainly break our continuous integration systems
for a little while, but I'm working to get that fixed.

Everyone should feel free to commit to the split repositories or to
the main repository at this point -- we do not plan any git surgery
that would be harmed by that.

I'd especially like to thank Jay and Matthew for working hard to help
with this, including fixing things I've broken. :)

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


Re: [racket-dev] The repository is now split

2014-12-04 Thread Sam Tobin-Hochstadt
On Thu Dec 04 2014 at 11:27:45 AM Matthias Felleisen matth...@ccs.neu.edu
wrote:


 For those of you who have my level of experience with such things,
 here is what Sam's phrase I *highly* recommend creating a new clone
 of the repository, and re-running `make`. means, for your value of
 the name 'plt2':

 $ git clone git:plt plt2
 $ cd plt2/
 $ git submodule init
 $ git submodule update
 $ make


Exactly.

Note that the `git:plt` repository that Matthias uses here is an alias for
`git.racket-lang.org:plt`. If you're not a committer, you'll want to use
`git://git.racket-lang.org/plt.git`.

Also, the submodule steps are needed on Windows and OS X, but not on Linux
(which is why I forgot to mention them).

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


Re: [racket-dev] The repository is now split

2014-12-04 Thread Sam Tobin-Hochstadt
On Thu, Dec 4, 2014 at 12:50 PM, John Clements johnbcleme...@gmail.com wrote:
 Okay, some teething problems.

 First time around, it finished way too fast.  The problem seemed to be that
 it had an error in compiling a planet package... ah, I see, there was no
 'at-exp-lib' installed? Presumably this is because planet packages don't
 declare pkg dependencies? Anyhow, this aborted the whole compilation.

 I went back to my main installation, removed all planet packages, and
 re-ran.

 It was running great, and about 30% done, when I decided that hyperthreading
 was not getting me anything, and that I wanted to run with 4 cpus rather
 than 8. So I hit Ctrl-C, and re-ran 'make'.

 er... big mistake.

 The next time through, hundreds of packages failed to compile.  In general,
 the most popular error was one about not having the at-exp collection:

Ok, that's good to know. I'll look into what's happening there.

 standard-module-name-resolver: collection not found
   for module path: (submod at-exp reader)
   collection: at-exp
   in collection directories:
/Users/clements/Library/Racket/development/collects
/Users/clements/plt2/racket/collects
... [177 additional linked and package directories]
   context...:
show-collection-err
standard-module-name-resolver
/Users/clements/plt2/racket/collects/compiler/cm.rkt:353:23
/Users/clements/plt2/racket/collects/syntax/modcode.rkt:62:2: reader
/Users/clements/plt2/racket/collects/syntax/modcode.rkt:264:5:
 compile-one
/Users/clements/plt2/racket/collects/compiler/cm.rkt:315:0: compile-zo*
/Users/clements/plt2/racket/collects/compiler/cm.rkt:519:26
/Users/clements/plt2/racket/collects/compiler/cm.rkt:511:42
/Users/clements/plt2/racket/collects/compiler/cm.rkt:476:0:
 maybe-compile-zo
/Users/clements/plt2/racket/collects/compiler/cm.rkt:591:2: do-check
/Users/clements/plt2/racket/collects/compiler/cm.rkt:706:4:
 compilation-manager-load-handler
standard-module-name-resolver
/Users/clements/plt2/racket/collects/compiler/cm.rkt:315:0: compile-zo*
/Users/clements/plt2/racket/collects/compiler/cm.rkt:519:26
/Users/clements/plt2/racket/collects/compiler/cm.rkt:511:42
/Users/clements/plt2/racket/collects/compiler/cm.rkt:476:0:
 maybe-compile-zo...

 ... but there were some other problems, too. Like this one:

 raco setup: 3 making: pkgs/plot-gui-lib/plot/typed/private
 ffi-lib: couldn't open libintl.8.dylib (dlopen(libintl.8.dylib, 6): image
 not found)
   context...:

 /Users/clements/plt2/racket/share/pkgs/draw-lib/racket/draw/unsafe/glib.rkt:
 [running body]

 /Users/clements/plt2/racket/share/pkgs/draw-lib/racket/draw/unsafe/pango.rkt:
 [traversing imports]

 /Users/clements/plt2/racket/share/pkgs/draw-lib/racket/draw/private/font.rkt:
 [traversing imports]

 /Users/clements/plt2/racket/share/pkgs/draw-lib/racket/draw/private/contract.rkt:
 [traversing imports]
/Users/clements/plt2/racket/share/pkgs/draw-lib/racket/draw.rkt:
 [traversing imports]

 /Users/clements/plt2/racket/share/pkgs/plot-lib/plot/private/common/contract.rkt:
 [traversing imports]

 /Users/clements/plt2/racket/share/pkgs/typed-racket-lib/typed-racket/tc-setup.rkt:39:0:
 tc-setup

 /Users/clements/plt2/racket/share/pkgs/typed-racket-lib/typed-racket/typed-racket.rkt:18:4
/Users/clements/plt2/racket/collects/compiler/cm.rkt:315:0: compile-zo*
/Users/clements/plt2/racket/collects/compiler/cm.rkt:519:26
/Users/clements/plt2/racket/collects/compiler/cm.rkt:511:42
/Users/clements/plt2/racket/collects/compiler/cm.rkt:476:0:
 maybe-compile-zo
/Users/clements/plt2/racket/collects/compiler/cm.rkt:591:2: do-check
/Users/clements/plt2/racket/collects/compiler/cm.rkt:706:4:
 compilation-manager-load-handler
standard-module-name-resolver
/Users/clements/plt2/racket/collects/racket/require-transform.rkt:266:2:
 expand-import...

 I think I may just try a fresh checkout, sigh.

 All of this is probably JFYI ... I know, you shouldn't abort a make. In the
 past, though, we've been pretty robust in this department.

I think robustness in this area is important, and we'll be back there
soon, hopefully. You shouldn't have to worry about aborting make.

Sam


 John


 On Thu, Dec 4, 2014 at 8:32 AM, Sam Tobin-Hochstadt sa...@cs.indiana.edu
 wrote:



 On Thu Dec 04 2014 at 11:27:45 AM Matthias Felleisen
 matth...@ccs.neu.edu wrote:


 For those of you who have my level of experience with such things,
 here is what Sam's phrase I *highly* recommend creating a new clone
 of the repository, and re-running `make`. means, for your value of
 the name 'plt2':

 $ git clone git:plt plt2
 $ cd plt2/
 $ git submodule init
 $ git submodule update
 $ make


 Exactly.

 Note that the `git:plt` repository that Matthias uses here is an alias for
 `git.racket-lang.org:plt`. If you're not a committer, you'll want to use
 `git://git.racket-lang.org/plt.git`.

 Also, the submodule steps are needed on Windows and OS X

Re: [racket-dev] Line editing in the default REPL

2014-12-03 Thread Sam Tobin-Hochstadt
On Wed, Dec 3, 2014 at 6:10 PM, Eli Barzilay e...@barzilay.org wrote:

 If you're talking about implementing line editing yourself, then my
 personal reaction to that would be wonderful, but doing it properly
 is something that is difficult and easy to underestimate

 I've already done this (admittedly it only works on OS X, but most
 Linux terminals work exactly the same with a few different
 constants). You can see what I have so far here:
 https://github.com/LeifAndersen/racket-line-editor/blob/master/main.rkt

 If this works, I'd be thoroughly impressed -- so I tried it.  I ran
 through a bunch of configurations that I use:

None of which was OS X, which was what Leif's email explicitly said it
_only works on_.

I think we should wait till he has a version which he says works
before telling people to avoid making contributions.

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


Re: [racket-dev] new package system collections and conflicts

2014-11-30 Thread Sam Tobin-Hochstadt
On Sun, Nov 30, 2014 at 10:44 AM, Matthew Flatt mfl...@cs.utah.edu wrote:

 There are plenty of real examples where it's sensible for different
 packages to introduce modules in overlapping collections, though.
 Sometimes, it's because different packages implement different facets
 of a conceptual whole, such as math-lib, math-doc, and math-test
 all extending the math collection.

Another example where this happens (and in a way that couldn't be
fixed by combining packages) is with typed versions of libraries. If I
release a package with the collection `foo`, and then someone else
produces a typed version of it, that will probably be named either
`foo/typed` (and thus be in the `foo` namespace) or `typed/foo` (and
thus be in the `typed` namespace).

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


Re: [racket-dev] Splitting the Racket repository

2014-11-30 Thread Sam Tobin-Hochstadt
On Sat, Nov 29, 2014 at 8:16 PM, Eli Barzilay e...@barzilay.org wrote:
 On Sat, Nov 29, 2014 at 7:14 PM, Sam Tobin-Hochstadt
 sa...@cs.indiana.edu wrote:

 All the history for the code has been preserved, and for code that
 dates back before 2005, the history is extended back to the original
 CVS repository. See https://github.com/racket/games/ for an example of
 this.

 There's a failure in the import -- if you look at the commits of this
 repo (https://github.com/racket/games/commits/master), then starting
 from Robby's commit from Jul 17 (add a contract to make-card...) and
 going back, the original commit references are all bogus.

I've now fixed this (with an assist from Matthew). If you look at that
commit again, it should reference an original commit that you can
find in `plt/racket`.

Furthermore, I've renamed the repository with the history. It's now here:
  github.com/samth/plt-history

It has the original commit for everything that ends up in a split. It
also has some instructions on how to see the history including all the
original commits.

Thanks for noticing the error.

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


Re: [racket-dev] new package system collections and conflicts

2014-11-30 Thread Sam Tobin-Hochstadt
On Sun, Nov 30, 2014 at 12:23 PM, Neil Van Dyke n...@neilvandyke.org wrote:


 Packages may find it convenient to build and provide reusable
 functionality with many organizational names. This is particularly true of
 data, as many packages may have useful data structures.

 Of course, as such support code becomes very useful and developed, it
 makes sense to sprin it off into its own package.

 Are you saying that `data` is some kind of classification of what this
 module is about, and in this case specifically, this module, which is part
 of some more specific package, happens to be regarding general-purpose data
 structures, so we're putting it over here in the `data` area of a shared
 namespace hierarchy?

Yes, the idea is that it makes sense for `data/hamt` to come from the
hamt package, and for `data/fector` to come from the fector
package (this is currently the case on pkgs.racket-lang.org).

  If so, I don't understand why that would be
 considered a good idea.

Because the client of these modules shouldn't have to think about
which package they belong in to use them. This gives the package
developer freedom to combine or split packages without requiring code
changes from clients. In general, one of the assumptions of the new
package system is that metadata changes, such as dependencies, are
easier to manage than code changes. This assumption is fairly
pervasive in successful package systems, including extra-linguistic
ones such as dpkg as well as in-language ones such as Cabal and npm.

The particular mode of use, where module names splice, has been
successful in a number of other communities, such as Haskell, where
they have just such a Data hierarchy, and where, like in Racket,
package names and module names aren't connected. This is also the case
in Java packages, although the naming scheme is somewhat different.

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


Re: [racket-dev] Splitting the Racket repository

2014-11-30 Thread Sam Tobin-Hochstadt
On Sat, Nov 29, 2014 at 7:14 PM, Sam Tobin-Hochstadt
sa...@cs.indiana.edu wrote:

 # Changes for git users

 If you build Racket from source from Git, that build now contains
 fewer packages. There is not yet an single-step way to get all of the
 split pkgs as git repositories; we plan to write a script for this
 soon.

I've now written a first draft of this script. You can get it at
https://github.com/samth/clone-all

If you run:
$ racket clone-all.rkt dir

it will create clones of all the packages split out of the repository in dir.

We'll integrate this into the main repository soon.

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


[racket-dev] Splitting the Racket repository

2014-11-29 Thread Sam Tobin-Hochstadt
As Matthias mentioned in his email a few days ago, we're in the
process of splitting the repository so that it doesn't bundle together
so many packages. I've started this process already, and a number of
packages have already been split out. For most people, this won't have
a big impact, but I'll outline changes for different sorts of people
below, and mention a few open questions.

All the history for the code has been preserved, and for code that
dates back before 2005, the history is extended back to the original
CVS repository. See https://github.com/racket/games/ for an example of
this.

# Changes for other users

If you use Racket by downloading a release or a snapshot, nothing will
change for you.

# Changes for git users

If you build Racket from source from Git, that build now contains
fewer packages. There is not yet an single-step way to get all of the
split pkgs as git repositories; we plan to write a script for this
soon.

To clone individual repositories, use the new `--clone` option for
`raco pkg`, such as:

raco pkg install --clone pkg-build git://github.com/racket/pkg-build

or for packages that are grouped together in a single repository

raco pkg install --clone remote-shell
git://github.com/racket/remote-shell?path=remote-shell-lib
git://github.com/racket/remote-shell?path=remote-shell
git://github.com/racket/remote-shell?path=remote-shell-doc

Note that the clones created by `raco pkg install` cannot be pushed to
with the default origin remote.

# Changes for committers

If you have commit access to the main Racket repository, you'll be
added to the `racket` organization on GitHub, which will give you
access to commit to the repositories there, which is where all of the
new packages are.

# Open issues

## DrDr

Currently, DrDr builds all the split packages as well as the current
repository. But it doesn't yet notice when changes are pushed to the
split packages. Also, it doesn't yet know who is responsible for code
in split packages, so if some of your code in such as package breaks,
you won't get an email. We plan to fix both of these issues soon.

Also, DrDr now builds several packages that it didn't before: the
s3-sync, sha, http, and aws packages. Currently, these packages have
some test failures, but we hope to fix that soon.

## Determining the content of the distribution

Previously, the content of the distribution was the dependencies of
the main-distribution package. Since that's in the repository, it
can't depend on the split packages. Thus, we need a new canonical home
for this information.

## Release process

This will also require changes to the release process, which I'll
leave to the release managers to describe.
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Splitting the Racket repository

2014-11-29 Thread Sam Tobin-Hochstadt
On Sat, Nov 29, 2014 at 8:16 PM, Eli Barzilay e...@barzilay.org wrote:
 On Sat, Nov 29, 2014 at 7:14 PM, Sam Tobin-Hochstadt
 sa...@cs.indiana.edu wrote:

 All the history for the code has been preserved, and for code that
 dates back before 2005, the history is extended back to the original
 CVS repository. See https://github.com/racket/games/ for an example of
 this.

 There's a failure in the import -- if you look at the commits of this
 repo (https://github.com/racket/games/commits/master), then starting
 from Robby's commit from Jul 17 (add a contract to make-card...) and
 going back, the original commit references are all bogus.

For packages with old history, the shas are in reference to
https://github.com/samth/old-plt-new/ (which should maybe have a
better name).

 If you build Racket from source from Git, that build now contains
 fewer packages. There is not yet an single-step way to get all of the
 split pkgs as git repositories; we plan to write a script for this
 soon.

 Any reason they are not git modules?  (They've improved a lot, and
 they're even supported in github as links as long as they point to other
 GH repos.  See for example: https://github.com/elibarzilay/test)

The goal is to have packages that are in the main distribution not
have a particular special status, beyond being in the list of things
that gets put in the distribution.

Also, a situation where you have to update two things when you do a
commit is not ideal.

 To clone individual repositories, use the new `--clone` option for
 `raco pkg`, such as:

 raco pkg install --clone pkg-build git://github.com/racket/pkg-build

 or for packages that are grouped together in a single repository

 raco pkg install --clone remote-shell
 git://github.com/racket/remote-shell?path=remote-shell-lib
 git://github.com/racket/remote-shell?path=remote-shell
 git://github.com/racket/remote-shell?path=remote-shell-doc

 Note that the clones created by `raco pkg install` cannot be pushed to
 with the default origin remote.

 This is very obscure.  Is there a compact description of what to do when
 you want to make a change in a file that is not on the main repo?

You just need to edit and change the relevant repository -- nothing
else is required. You don't have to use --clone or any other
mechanism.

Note that the command line above can be shortened to:

raco pkg install --clone remote-shell remote-shell-lib
remote-shell-doc remote-shell

(that `remote-shell` appears twice there is intentional).

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


Re: [racket-dev] Line editing in the default REPL

2014-11-25 Thread Sam Tobin-Hochstadt
On Tue, Nov 25, 2014 at 11:00 AM, Matthew Flatt mfl...@cs.utah.edu wrote:
 Do you have in mind making xrepl intended to be part of Minimal
 Racket? If not, what's the mechanism for `racket` using xrepl when
 it's available?

I can think of a few ways of doing this.

 1 Just make xrepl part of minimal Racket (probably removing the
mandatory dependency on scribble/text/wrap)
 2 Have `racket/init` dynamically test of the presence of
xrepl/main.rkt as a collection-file-path, and load it if available.
 3 Have `racket/init` (or the `racket` binary) test for something like
`racket/init/extended` which would be part of xrepl and part of
other extended repls.
 4 Like 3, but have an additional package which depends on xrepl and
just contains `racket/init/extended`

I prefer 2, 3, or 4 of these options -- it seems fine for Minimal
Racket to not have line editing, but I'd be interested to hear what
others expect.

 A similar question applies to libeditline. Currently, for Linux and
 other Unix platforms (not counting natipkg variants), our convention
 is that native libraries are either part of the `[g]racket` executable
 or they are installed separately by users through the OS's package
 manager. We can't link to libreadline by default in a Racket
 distribution, and since libeditline isn't typically included with
 Linux distributions (as far as I can tell), it seems like we haven't
 solved any problem unless we provide libeditline. Should
 libeditline become not only part of the Minimal Racket distribution,
 but even part of the Racket executable? Or should our convention and/or
 distribution infrastructure change?

I was thinking that the readline-core package would dynamically test
of libeditline, and if it's not there fall back to libreadline. My
opinion, as someone who isn't a lawyer but has read a lot about this,
is that this would not cause Racket to be a derived work of readline.

If we don't want to do that, I see a few possibilities:

 1. We ship xrepl in whichever way we decide, and change the message
it prints when it can't find libeditline to suggest changing things
or adding (require xrepl/readline) to .racketrc.
 2. We ship a copy of libeditlinewith xrepl as a built binary, even on linux.
 3. We statically link libeditline to Racket in the standard distribution.

I think 1 sounds most appealing if we're not ok with dynamically
falling back to libreadline.

Sam


 At Mon, 24 Nov 2014 18:02:45 -0500, Sam Tobin-Hochstadt wrote:
 My understanding of the licensing issues is that if the code works with
 both libeditline and libreadline then it isn't a derived work of
 readline, and therefore could be licensed under the LGPL, like the rest of
 Racket. Furthermore, turning use of libeditline on by default wouldn't be
 linking to any GPL code, meaning that we could do that by default.

 I think we should split up the `readline` collection into `readline` and
 `readline/base` which would be what's compatible with editline, and have
 xrepl in a `readline/base` mode on by default.

 Sam

 On Mon, Nov 24, 2014 at 5:57 PM, Leif Andersen l...@leifandersen.net
 wrote:

  Hello,
 
  When a user first starts the racket repl, it doesn't do line editing due
  to licensing issues. For example, it would be nice if the default editor
  would give the previous line if you hit up arrow, rather than writing
  ^[[A.
 
  I have now pointed out xrepl to several users, and every time they always
  ask me why it's not the default repl. Apparently the problem is that xrepl
  uses GNU Readline, which is GPL. However, Asumu found that if we replace
  requiring readline with BSD's libedit (not libeditline), everything works
  fine due to libedit's readline compatibility. It doesn't have all of the
  features of readline, but it does have some of the biggest ones (such as
  being able to use arrow keys)
 
  What do you all think of having `(require editline)` that works for the
  default repl, so that it gets line editing features. This would allow us to
  also keep `(require readline)` as before, maintaining backwards
  compatibility.
 
  If we do do this, this leads to the question of distribution. Would we
  want to include libedit inside Racket distributions, or should we just link
  to whatever the user has on their system?
 
  ~Leif Andersen
 
  _
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] Line editing in the default REPL

2014-11-24 Thread Sam Tobin-Hochstadt
My understanding of the licensing issues is that if the code works with
both libeditline and libreadline then it isn't a derived work of
readline, and therefore could be licensed under the LGPL, like the rest of
Racket. Furthermore, turning use of libeditline on by default wouldn't be
linking to any GPL code, meaning that we could do that by default.

I think we should split up the `readline` collection into `readline` and
`readline/base` which would be what's compatible with editline, and have
xrepl in a `readline/base` mode on by default.

Sam

On Mon, Nov 24, 2014 at 5:57 PM, Leif Andersen l...@leifandersen.net
wrote:

 Hello,

 When a user first starts the racket repl, it doesn't do line editing due
 to licensing issues. For example, it would be nice if the default editor
 would give the previous line if you hit up arrow, rather than writing
 ^[[A.

 I have now pointed out xrepl to several users, and every time they always
 ask me why it's not the default repl. Apparently the problem is that xrepl
 uses GNU Readline, which is GPL. However, Asumu found that if we replace
 requiring readline with BSD's libedit (not libeditline), everything works
 fine due to libedit's readline compatibility. It doesn't have all of the
 features of readline, but it does have some of the biggest ones (such as
 being able to use arrow keys)

 What do you all think of having `(require editline)` that works for the
 default repl, so that it gets line editing features. This would allow us to
 also keep `(require readline)` as before, maintaining backwards
 compatibility.

 If we do do this, this leads to the question of distribution. Would we
 want to include libedit inside Racket distributions, or should we just link
 to whatever the user has on their system?

 ~Leif Andersen

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


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


Re: [racket-dev] DrRacket PF1 Search Bug?

2014-11-21 Thread Sam Tobin-Hochstadt
On Fri, Nov 21, 2014 at 9:29 AM, Eli Barzilay e...@barzilay.org wrote:
 On Fri, Nov 21, 2014 at 8:46 AM, Robby Findler
 ro...@eecs.northwestern.edu wrote:
 On Fri, Nov 21, 2014 at 12:34 AM, Eli Barzilay e...@barzilay.org wrote:
 Not that it matters, but did you try to see if it's the file
 permissions?

 Oh, they are!

 [...]

 And that was it!!

 If I run:

   $ xattr -d com.apple.quarantine /Applications/r/doc/search/index.html

 then osascript works again!
 [...]

 ... I don't know the ramifications of just calling xattr from inside
 DrRacket to fix things up. It may be better to just create the file in
 the user's directory instead.

 That (the first thing) sounds like a very bad idea, and one that will
 most likely fail in a case of a non-private machine.  The second is also
 pretty bad since you'd be exluding a central setup in such a situation.
 (Not that I see any reason to have a lab of Macs...)

We have labs of macs here at IU.

 And this is why I said that it's not really relevant -- AFAICT, the fact
 that things are setup in a way that prevents passing queries and
 fragments means that you just have to deal with it rather than try to
 play games with the filesystem.

Could we just write a file with the query embedded in it, and open that?

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


Re: [racket-dev] parse errors in types, poly-dots cause me headaches

2014-11-18 Thread Sam Tobin-Hochstadt
On Tue, Nov 18, 2014 at 10:45 AM, Matthias Felleisen
matth...@ccs.neu.edu wrote:

 It's quite possible that this is Eli's bug again, but boy this causes 
 headaches:

 Type Checker: parse error in type;
  type variable must be used with ...
   variable: Y in: Y

 And it points precisely to where Y is followed by ...

The problem here is that you're using -* without using the syntax of
-*.  Fortunately, this program doesn't need -* at all.

Unfortunately, I don't know how to make this function type check yet,
but I'll keep playing with it.

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


Re: [racket-dev] parse errors in types, poly-dots cause me headaches

2014-11-18 Thread Sam Tobin-Hochstadt
No, I ran it, it barfed, and then I figured out what went wrong. Then
I sent you an email with a fix. Unfortunately, that fix isn't enough
to make the program type check. Partly, there's an internal error, but
that's a missing case that will take work to support properly.

We can do better with the error message as well, by special casing ...
in -*, I think.

I don't, however, get the unbound identifier error that is in your
screenshot. I just got the error message from your original post. Can
you send the exact program that produced the error in the screenshot?

Sam

On Tue, Nov 18, 2014 at 11:54 AM, Matthias Felleisen
matth...@ccs.neu.edu wrote:

 On Nov 18, 2014, at 11:34 AM, Sam Tobin-Hochstadt sa...@cs.indiana.edu 
 wrote:

 On Tue, Nov 18, 2014 at 10:45 AM, Matthias Felleisen
 matth...@ccs.neu.edu wrote:

 It's quite possible that this is Eli's bug again, but boy this causes 
 headaches:

 Type Checker: parse error in type;
 type variable must be used with ...
  variable: Y in: Y

 And it points precisely to where Y is followed by ...

 The problem here is that you're using -* without using the syntax of
 -*.  Fortunately, this program doesn't need -* at all.

 Unfortunately, I don't know how to make this function type check yet,
 but I'll keep playing with it.


 Are you blaming the victim here? Please run what I send out and experience 
 how the type checker barfs on you. This is a bug report.
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] parse errors in types, poly-dots cause me headaches

2014-11-18 Thread Sam Tobin-Hochstadt
With that program, I get this error message:

unsaved editor:7:48: Type Checker: parse error in type; type
variable must be used with ... variable: Y in: Y

Which you also got. What changed it from the parse error to the
unbound identifier error?

Sam

On Tue, Nov 18, 2014 at 12:05 PM, Matthias Felleisen
matth...@ccs.neu.edu wrote:

 What I sent is the exact program that produced the attached error in today's 
 drracket [updated around 10am].




 On Nov 18, 2014, at 11:58 AM, Sam Tobin-Hochstadt sa...@cs.indiana.edu 
 wrote:

 No, I ran it, it barfed, and then I figured out what went wrong. Then
 I sent you an email with a fix. Unfortunately, that fix isn't enough
 to make the program type check. Partly, there's an internal error, but
 that's a missing case that will take work to support properly.

 We can do better with the error message as well, by special casing ...
 in -*, I think.

 I don't, however, get the unbound identifier error that is in your
 screenshot. I just got the error message from your original post. Can
 you send the exact program that produced the error in the screenshot?

 Sam

 On Tue, Nov 18, 2014 at 11:54 AM, Matthias Felleisen
 matth...@ccs.neu.edu wrote:

 On Nov 18, 2014, at 11:34 AM, Sam Tobin-Hochstadt sa...@cs.indiana.edu 
 wrote:

 On Tue, Nov 18, 2014 at 10:45 AM, Matthias Felleisen
 matth...@ccs.neu.edu wrote:

 It's quite possible that this is Eli's bug again, but boy this causes 
 headaches:

 Type Checker: parse error in type;
 type variable must be used with ...
 variable: Y in: Y

 And it points precisely to where Y is followed by ...

 The problem here is that you're using -* without using the syntax of
 -*.  Fortunately, this program doesn't need -* at all.

 Unfortunately, I don't know how to make this function type check yet,
 but I'll keep playing with it.


 Are you blaming the victim here? Please run what I send out and experience 
 how the type checker barfs on you. This is a bug report.

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


Re: [racket-dev] parse errors in types, poly-dots cause me headaches

2014-11-18 Thread Sam Tobin-Hochstadt
Yes, fix (for the internal error) coming soon.

Sam

On Tue, Nov 18, 2014 at 5:24 PM, Alexander D. Knauth
alexan...@knauth.org wrote:
 In terms of bugs, it’s probably related to this problem with call-with-values 
 and poly-dots:
 #lang typed/racket
 (: f : (All (a ...) [(- (values Any ... a)) - Void]))
 (define (f g)
   (call-with-values g void))
 ;=
 . . ../../Applications/Racket 
 v6.1.1/share/pkgs/typed-racket-lib/typed-racket/typecheck/tc-app/tc-app-values.rkt:22:4:
  match: no matching clause for (tc-results '() (cons Any 'a))

 On Nov 18, 2014, at 11:54 AM, Matthias Felleisen matth...@ccs.neu.edu wrote:


 On Nov 18, 2014, at 11:34 AM, Sam Tobin-Hochstadt sa...@cs.indiana.edu 
 wrote:

 On Tue, Nov 18, 2014 at 10:45 AM, Matthias Felleisen
 matth...@ccs.neu.edu wrote:

 It's quite possible that this is Eli's bug again, but boy this causes 
 headaches:

 Type Checker: parse error in type;
 type variable must be used with ...
 variable: Y in: Y

 And it points precisely to where Y is followed by ...

 The problem here is that you're using -* without using the syntax of
 -*.  Fortunately, this program doesn't need -* at all.

 Unfortunately, I don't know how to make this function type check yet,
 but I'll keep playing with it.


 Are you blaming the victim here? Please run what I send out and experience 
 how the type checker barfs on you. This is a bug report.
 _
  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, Second Draft

2014-10-30 Thread Sam Tobin-Hochstadt
On Wed, Oct 29, 2014 at 9:46 PM, Robby Findler
ro...@eecs.northwestern.edu wrote:
 I don't think that it's true of every type system everywhere is a
 good rationale for not owning backwards-incompatible changes (even
 when they are good backwards incompatible changes, as this one
 certainly is). I do agree with you, however, that what is especially
 bad is requiring changes to working code bases (for whatever
 definition of that word you wish to take (that is most friendly to
 people that use Racket)).

I don't think I was not owning the existence of a
backwards-incompatible change. I just don't think that the distinction
about whether it rejects programs that run correctly is meaningful --
the other change to exception handling only affects programs that were
wrong, but has been a bigger issue in practice.

 How about this one? (Starting from Matthias's offering and editing the
 apology from Sam's a bit.)

 Typed Racket closes a safety hole in the typing for the
   exception system. The revised type system restricts raise so
   that only instances of the exn structure type and flat data
   are communicated to handlers. As a side-effect, previously
   well-typed programs may fail to typecheck.

How about:

 Typed Racket now checks uses of the exception system more strictly,
eliminating safety bugs. The revised type system restricts raise so
  that only instances of the exn structure type and flat data
  are communicated to handlers, and enforces that exception handlers
deal with all possible arguments. As a side-effect, previously
  well-typed programs may fail to typecheck.

Sam


 Robby

 On Wed, Oct 29, 2014 at 5:12 PM, Sam Tobin-Hochstadt
 sa...@cs.indiana.edu wrote:
 The reason I don't like the second sentence you wrote is that it's
 true of every type system everywhere. And also, the more significant
 change for users will almost certainly be the first one (it's required
 changes to several packages already) -- almost no one raises anything
 that isn't an exn, and so I haven't seen any code actually affected by
 the second change.
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


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

2014-10-29 Thread Sam Tobin-Hochstadt
On Wed, Oct 29, 2014 at 3:30 PM, Ryan Culpepper ry...@ccs.neu.edu wrote:

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

 * Casts and predicates are supported in typed regions.

I think these two bullets (esp the first one) need to make clear that
they're about Typed Racket.

How about:

* Typed Racket's rules for exception handlers are now more
restrictive, as required for safety. This may cause type errors for
existing programs that rely on unsafe behavior.
* Typed Racket now supports casts and predicates in typed regions.

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


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

2014-10-29 Thread Sam Tobin-Hochstadt
There were two holes.

1. We allowed exception handlers to assume that they received values
of type `exn`, even when that wasn't right.
2. We allowed typed programs to throw arbitrary values, which means
that you could throw a typed function to an untyped handler, which
could then misuse it.

Both of these changes could lead to type errors in programs that won't
fail at runtime, but that's true of just about everything in Typed
Racket, so I don't really understand what you're asking. Here are
examples of programs that will now type-error for each change.

1. (with-handlers ([void exn-message]) #f)
2. (raise (lambda ([x : Integer]) x))

I think the second problem is more what you mean, in that the first
program is wrong in some sense, even though it doesn't go wrong, but
the second example is a perfectly fine Racket program (if perhaps poor
style), but not one that can be allowed in the presence of untyped
code.

Does that help explain things?
Sam

On Wed, Oct 29, 2014 at 5:17 PM, Robby Findler
ro...@eecs.northwestern.edu wrote:
 Sam: can you elaborate on precisely what the hole was? In particular,
 if there are any safe programs that the type system now rejects, I'd
 be in favor of a slightly different wording.

 Robby

 On Wed, Oct 29, 2014 at 2:35 PM, Sam Tobin-Hochstadt
 sa...@cs.indiana.edu wrote:
 On Wed, Oct 29, 2014 at 3:30 PM, Ryan Culpepper ry...@ccs.neu.edu wrote:

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

 * Casts and predicates are supported in typed regions.

 I think these two bullets (esp the first one) need to make clear that
 they're about Typed Racket.

 How about:

 * Typed Racket's rules for exception handlers are now more
 restrictive, as required for safety. This may cause type errors for
 existing programs that rely on unsafe behavior.
 * Typed Racket now supports casts and predicates in typed regions.

 Sam
 _
   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, Second Draft

2014-10-29 Thread Sam Tobin-Hochstadt
On Wed, Oct 29, 2014 at 5:47 PM, Robby Findler
ro...@eecs.northwestern.edu wrote:
 Yes, that's what I mean. I don't think that the sentence This may
 break existing programs that rely on unsafe behavior. is accurate.
 How about This may break existing programs. or Closing this hole
 requires us to disallow some programs that do not signal runtime
 errors. or something like that?

How about This may result in type errors in existing programs that
rely on the original behavior; specifically, programs that `raise`
higher-order values.

Sam


 Robby

 On Wed, Oct 29, 2014 at 4:35 PM, Sam Tobin-Hochstadt
 sa...@cs.indiana.edu wrote:
 There were two holes.

 1. We allowed exception handlers to assume that they received values
 of type `exn`, even when that wasn't right.
 2. We allowed typed programs to throw arbitrary values, which means
 that you could throw a typed function to an untyped handler, which
 could then misuse it.

 Both of these changes could lead to type errors in programs that won't
 fail at runtime, but that's true of just about everything in Typed
 Racket, so I don't really understand what you're asking. Here are
 examples of programs that will now type-error for each change.

 1. (with-handlers ([void exn-message]) #f)
 2. (raise (lambda ([x : Integer]) x))

 I think the second problem is more what you mean, in that the first
 program is wrong in some sense, even though it doesn't go wrong, but
 the second example is a perfectly fine Racket program (if perhaps poor
 style), but not one that can be allowed in the presence of untyped
 code.

 Does that help explain things?
 Sam

 On Wed, Oct 29, 2014 at 5:17 PM, Robby Findler
 ro...@eecs.northwestern.edu wrote:
 Sam: can you elaborate on precisely what the hole was? In particular,
 if there are any safe programs that the type system now rejects, I'd
 be in favor of a slightly different wording.

 Robby

 On Wed, Oct 29, 2014 at 2:35 PM, Sam Tobin-Hochstadt
 sa...@cs.indiana.edu wrote:
 On Wed, Oct 29, 2014 at 3:30 PM, Ryan Culpepper ry...@ccs.neu.edu wrote:

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

 * Casts and predicates are supported in typed regions.

 I think these two bullets (esp the first one) need to make clear that
 they're about Typed Racket.

 How about:

 * Typed Racket's rules for exception handlers are now more
 restrictive, as required for safety. This may cause type errors for
 existing programs that rely on unsafe behavior.
 * Typed Racket now supports casts and predicates in typed regions.

 Sam
 _
   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, Second Draft

2014-10-29 Thread Sam Tobin-Hochstadt
The reason I don't like the second sentence you wrote is that it's
true of every type system everywhere. And also, the more significant
change for users will almost certainly be the first one (it's required
changes to several packages already) -- almost no one raises anything
that isn't an exn, and so I haven't seen any code actually affected by
the second change.

Sam

On Wed, Oct 29, 2014 at 6:00 PM, Robby Findler
ro...@eecs.northwestern.edu wrote:
 I prefer the second sentence I sent to either of those. Fundamentally
 I think it is reasonable for the sentence to be slightly apologetic.
 There was a problem, we fixed it, but the fix may require some pain of
 our users. There's nothing wrong with that; it's just a fact of life.
 No shame in hiding it.

 Robby

 On Wed, Oct 29, 2014 at 4:55 PM, Sam Tobin-Hochstadt
 sa...@cs.indiana.edu wrote:
 On Wed, Oct 29, 2014 at 5:47 PM, Robby Findler
 ro...@eecs.northwestern.edu wrote:
 Yes, that's what I mean. I don't think that the sentence This may
 break existing programs that rely on unsafe behavior. is accurate.
 How about This may break existing programs. or Closing this hole
 requires us to disallow some programs that do not signal runtime
 errors. or something like that?

 How about This may result in type errors in existing programs that
 rely on the original behavior; specifically, programs that `raise`
 higher-order values.

 Sam


 Robby

 On Wed, Oct 29, 2014 at 4:35 PM, Sam Tobin-Hochstadt
 sa...@cs.indiana.edu wrote:
 There were two holes.

 1. We allowed exception handlers to assume that they received values
 of type `exn`, even when that wasn't right.
 2. We allowed typed programs to throw arbitrary values, which means
 that you could throw a typed function to an untyped handler, which
 could then misuse it.

 Both of these changes could lead to type errors in programs that won't
 fail at runtime, but that's true of just about everything in Typed
 Racket, so I don't really understand what you're asking. Here are
 examples of programs that will now type-error for each change.

 1. (with-handlers ([void exn-message]) #f)
 2. (raise (lambda ([x : Integer]) x))

 I think the second problem is more what you mean, in that the first
 program is wrong in some sense, even though it doesn't go wrong, but
 the second example is a perfectly fine Racket program (if perhaps poor
 style), but not one that can be allowed in the presence of untyped
 code.

 Does that help explain things?
 Sam

 On Wed, Oct 29, 2014 at 5:17 PM, Robby Findler
 ro...@eecs.northwestern.edu wrote:
 Sam: can you elaborate on precisely what the hole was? In particular,
 if there are any safe programs that the type system now rejects, I'd
 be in favor of a slightly different wording.

 Robby

 On Wed, Oct 29, 2014 at 2:35 PM, Sam Tobin-Hochstadt
 sa...@cs.indiana.edu wrote:
 On Wed, Oct 29, 2014 at 3:30 PM, Ryan Culpepper ry...@ccs.neu.edu 
 wrote:

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

 * Casts and predicates are supported in typed regions.

 I think these two bullets (esp the first one) need to make clear that
 they're about Typed Racket.

 How about:

 * Typed Racket's rules for exception handlers are now more
 restrictive, as required for safety. This may cause type errors for
 existing programs that rely on unsafe behavior.
 * Typed Racket now supports casts and predicates in typed regions.

 Sam
 _
   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, Second Draft

2014-10-29 Thread Sam Tobin-Hochstadt
Here's another idea:

* To ensure safety, Typed Racket now prohibits raising any values
other than exns and simple flat data. Some existing programs may now
have type errors because of this.

Sam

On Wed, Oct 29, 2014 at 6:12 PM, Sam Tobin-Hochstadt
sa...@cs.indiana.edu wrote:
 The reason I don't like the second sentence you wrote is that it's
 true of every type system everywhere. And also, the more significant
 change for users will almost certainly be the first one (it's required
 changes to several packages already) -- almost no one raises anything
 that isn't an exn, and so I haven't seen any code actually affected by
 the second change.

 Sam

 On Wed, Oct 29, 2014 at 6:00 PM, Robby Findler
 ro...@eecs.northwestern.edu wrote:
 I prefer the second sentence I sent to either of those. Fundamentally
 I think it is reasonable for the sentence to be slightly apologetic.
 There was a problem, we fixed it, but the fix may require some pain of
 our users. There's nothing wrong with that; it's just a fact of life.
 No shame in hiding it.

 Robby

 On Wed, Oct 29, 2014 at 4:55 PM, Sam Tobin-Hochstadt
 sa...@cs.indiana.edu wrote:
 On Wed, Oct 29, 2014 at 5:47 PM, Robby Findler
 ro...@eecs.northwestern.edu wrote:
 Yes, that's what I mean. I don't think that the sentence This may
 break existing programs that rely on unsafe behavior. is accurate.
 How about This may break existing programs. or Closing this hole
 requires us to disallow some programs that do not signal runtime
 errors. or something like that?

 How about This may result in type errors in existing programs that
 rely on the original behavior; specifically, programs that `raise`
 higher-order values.

 Sam


 Robby

 On Wed, Oct 29, 2014 at 4:35 PM, Sam Tobin-Hochstadt
 sa...@cs.indiana.edu wrote:
 There were two holes.

 1. We allowed exception handlers to assume that they received values
 of type `exn`, even when that wasn't right.
 2. We allowed typed programs to throw arbitrary values, which means
 that you could throw a typed function to an untyped handler, which
 could then misuse it.

 Both of these changes could lead to type errors in programs that won't
 fail at runtime, but that's true of just about everything in Typed
 Racket, so I don't really understand what you're asking. Here are
 examples of programs that will now type-error for each change.

 1. (with-handlers ([void exn-message]) #f)
 2. (raise (lambda ([x : Integer]) x))

 I think the second problem is more what you mean, in that the first
 program is wrong in some sense, even though it doesn't go wrong, but
 the second example is a perfectly fine Racket program (if perhaps poor
 style), but not one that can be allowed in the presence of untyped
 code.

 Does that help explain things?
 Sam

 On Wed, Oct 29, 2014 at 5:17 PM, Robby Findler
 ro...@eecs.northwestern.edu wrote:
 Sam: can you elaborate on precisely what the hole was? In particular,
 if there are any safe programs that the type system now rejects, I'd
 be in favor of a slightly different wording.

 Robby

 On Wed, Oct 29, 2014 at 2:35 PM, Sam Tobin-Hochstadt
 sa...@cs.indiana.edu wrote:
 On Wed, Oct 29, 2014 at 3:30 PM, Ryan Culpepper ry...@ccs.neu.edu 
 wrote:

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

 * Casts and predicates are supported in typed regions.

 I think these two bullets (esp the first one) need to make clear that
 they're about Typed Racket.

 How about:

 * Typed Racket's rules for exception handlers are now more
 restrictive, as required for safety. This may cause type errors for
 existing programs that rely on unsafe behavior.
 * Typed Racket now supports casts and predicates in typed regions.

 Sam
 _
   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, Second Draft

2014-10-29 Thread Sam Tobin-Hochstadt
On Wed, Oct 29, 2014 at 6:42 PM, Matthias Felleisen
matth...@ccs.neu.edu wrote:

 1. Can we please, pretty please, drop these nows from every single sentence?

 2. I think this is close to what we may wish to say. Here is a small edit:

 * Typed Racket closes a safety hole due to the types for the
   exception system. The revised type system restricts raise so
   that only instances of the exn structure type and flat data
   are communicated to handlers.

I like this, but we need to at least mention the other change. So how about:

* Typed Racket closes two safety holes in the types for the
  exception system. The revised type system restricts raise so
  that only instances of the exn structure type and flat data
  are communicated to handlers, and checks exception handlers properly.

Sam


 3. I think it is perfectly acceptable to imply that a
 restriction of an existing type system breaks existing
 programs. If you don't, I'd say

  Existing programs may suffer from new type errors
  due to this restriction.







 On Oct 29, 2014, at 6:32 PM, Sam Tobin-Hochstadt sa...@cs.indiana.edu wrote:

 Here's another idea:

 * To ensure safety, Typed Racket now prohibits raising any values
 other than exns and simple flat data. Some existing programs may now
 have type errors because of this.

 Sam

 On Wed, Oct 29, 2014 at 6:12 PM, Sam Tobin-Hochstadt
 sa...@cs.indiana.edu wrote:
 The reason I don't like the second sentence you wrote is that it's
 true of every type system everywhere. And also, the more significant
 change for users will almost certainly be the first one (it's required
 changes to several packages already) -- almost no one raises anything
 that isn't an exn, and so I haven't seen any code actually affected by
 the second change.

 Sam

 On Wed, Oct 29, 2014 at 6:00 PM, Robby Findler
 ro...@eecs.northwestern.edu wrote:
 I prefer the second sentence I sent to either of those. Fundamentally
 I think it is reasonable for the sentence to be slightly apologetic.
 There was a problem, we fixed it, but the fix may require some pain of
 our users. There's nothing wrong with that; it's just a fact of life.
 No shame in hiding it.

 Robby

 On Wed, Oct 29, 2014 at 4:55 PM, Sam Tobin-Hochstadt
 sa...@cs.indiana.edu wrote:
 On Wed, Oct 29, 2014 at 5:47 PM, Robby Findler
 ro...@eecs.northwestern.edu wrote:
 Yes, that's what I mean. I don't think that the sentence This may
 break existing programs that rely on unsafe behavior. is accurate.
 How about This may break existing programs. or Closing this hole
 requires us to disallow some programs that do not signal runtime
 errors. or something like that?

 How about This may result in type errors in existing programs that
 rely on the original behavior; specifically, programs that `raise`
 higher-order values.

 Sam


 Robby

 On Wed, Oct 29, 2014 at 4:35 PM, Sam Tobin-Hochstadt
 sa...@cs.indiana.edu wrote:
 There were two holes.

 1. We allowed exception handlers to assume that they received values
 of type `exn`, even when that wasn't right.
 2. We allowed typed programs to throw arbitrary values, which means
 that you could throw a typed function to an untyped handler, which
 could then misuse it.

 Both of these changes could lead to type errors in programs that won't
 fail at runtime, but that's true of just about everything in Typed
 Racket, so I don't really understand what you're asking. Here are
 examples of programs that will now type-error for each change.

 1. (with-handlers ([void exn-message]) #f)
 2. (raise (lambda ([x : Integer]) x))

 I think the second problem is more what you mean, in that the first
 program is wrong in some sense, even though it doesn't go wrong, but
 the second example is a perfectly fine Racket program (if perhaps poor
 style), but not one that can be allowed in the presence of untyped
 code.

 Does that help explain things?
 Sam

 On Wed, Oct 29, 2014 at 5:17 PM, Robby Findler
 ro...@eecs.northwestern.edu wrote:
 Sam: can you elaborate on precisely what the hole was? In particular,
 if there are any safe programs that the type system now rejects, I'd
 be in favor of a slightly different wording.

 Robby

 On Wed, Oct 29, 2014 at 2:35 PM, Sam Tobin-Hochstadt
 sa...@cs.indiana.edu wrote:
 On Wed, Oct 29, 2014 at 3:30 PM, Ryan Culpepper ry...@ccs.neu.edu 
 wrote:

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

 * Casts and predicates are supported in typed regions.

 I think these two bullets (esp the first one) need to make clear that
 they're about Typed Racket.

 How about:

 * Typed Racket's rules for exception handlers are now more
 restrictive, as required for safety. This may cause type errors for
 existing programs that rely on unsafe behavior.
 * Typed Racket now supports casts and predicates in typed regions.

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

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

2014-10-29 Thread Sam Tobin-Hochstadt
On Wed, Oct 29, 2014 at 6:57 PM, Matthias Felleisen
matth...@ccs.neu.edu wrote:

 properly - corresponding fashion?

No, it's a different change (the one I numbered 1. in my first message).

Sam


 Otherwise fine


 On Oct 29, 2014, at 6:54 PM, Sam Tobin-Hochstadt sa...@cs.indiana.edu wrote:

 On Wed, Oct 29, 2014 at 6:42 PM, Matthias Felleisen
 matth...@ccs.neu.edu wrote:

 1. Can we please, pretty please, drop these nows from every single 
 sentence?

 2. I think this is close to what we may wish to say. Here is a small edit:

 * Typed Racket closes a safety hole due to the types for the
  exception system. The revised type system restricts raise so
  that only instances of the exn structure type and flat data
  are communicated to handlers.

 I like this, but we need to at least mention the other change. So how about:

 * Typed Racket closes two safety holes in the types for the
  exception system. The revised type system restricts raise so
  that only instances of the exn structure type and flat data
  are communicated to handlers, and checks exception handlers properly.

 Sam


 3. I think it is perfectly acceptable to imply that a
 restriction of an existing type system breaks existing
 programs. If you don't, I'd say

 Existing programs may suffer from new type errors
 due to this restriction.







 On Oct 29, 2014, at 6:32 PM, Sam Tobin-Hochstadt sa...@cs.indiana.edu 
 wrote:

 Here's another idea:

 * To ensure safety, Typed Racket now prohibits raising any values
 other than exns and simple flat data. Some existing programs may now
 have type errors because of this.

 Sam

 On Wed, Oct 29, 2014 at 6:12 PM, Sam Tobin-Hochstadt
 sa...@cs.indiana.edu wrote:
 The reason I don't like the second sentence you wrote is that it's
 true of every type system everywhere. And also, the more significant
 change for users will almost certainly be the first one (it's required
 changes to several packages already) -- almost no one raises anything
 that isn't an exn, and so I haven't seen any code actually affected by
 the second change.

 Sam

 On Wed, Oct 29, 2014 at 6:00 PM, Robby Findler
 ro...@eecs.northwestern.edu wrote:
 I prefer the second sentence I sent to either of those. Fundamentally
 I think it is reasonable for the sentence to be slightly apologetic.
 There was a problem, we fixed it, but the fix may require some pain of
 our users. There's nothing wrong with that; it's just a fact of life.
 No shame in hiding it.

 Robby

 On Wed, Oct 29, 2014 at 4:55 PM, Sam Tobin-Hochstadt
 sa...@cs.indiana.edu wrote:
 On Wed, Oct 29, 2014 at 5:47 PM, Robby Findler
 ro...@eecs.northwestern.edu wrote:
 Yes, that's what I mean. I don't think that the sentence This may
 break existing programs that rely on unsafe behavior. is accurate.
 How about This may break existing programs. or Closing this hole
 requires us to disallow some programs that do not signal runtime
 errors. or something like that?

 How about This may result in type errors in existing programs that
 rely on the original behavior; specifically, programs that `raise`
 higher-order values.

 Sam


 Robby

 On Wed, Oct 29, 2014 at 4:35 PM, Sam Tobin-Hochstadt
 sa...@cs.indiana.edu wrote:
 There were two holes.

 1. We allowed exception handlers to assume that they received values
 of type `exn`, even when that wasn't right.
 2. We allowed typed programs to throw arbitrary values, which means
 that you could throw a typed function to an untyped handler, which
 could then misuse it.

 Both of these changes could lead to type errors in programs that won't
 fail at runtime, but that's true of just about everything in Typed
 Racket, so I don't really understand what you're asking. Here are
 examples of programs that will now type-error for each change.

 1. (with-handlers ([void exn-message]) #f)
 2. (raise (lambda ([x : Integer]) x))

 I think the second problem is more what you mean, in that the first
 program is wrong in some sense, even though it doesn't go wrong, but
 the second example is a perfectly fine Racket program (if perhaps poor
 style), but not one that can be allowed in the presence of untyped
 code.

 Does that help explain things?
 Sam

 On Wed, Oct 29, 2014 at 5:17 PM, Robby Findler
 ro...@eecs.northwestern.edu wrote:
 Sam: can you elaborate on precisely what the hole was? In particular,
 if there are any safe programs that the type system now rejects, I'd
 be in favor of a slightly different wording.

 Robby

 On Wed, Oct 29, 2014 at 2:35 PM, Sam Tobin-Hochstadt
 sa...@cs.indiana.edu wrote:
 On Wed, Oct 29, 2014 at 3:30 PM, Ryan Culpepper ry...@ccs.neu.edu 
 wrote:

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

 * Casts and predicates are supported in typed regions.

 I think these two bullets (esp the first one) need to make clear 
 that
 they're about Typed Racket.

 How about:

 * Typed Racket's rules for exception handlers are now more
 restrictive, as required for safety

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

2014-10-28 Thread Sam Tobin-Hochstadt
On Tue, Oct 28, 2014 at 12:26 PM, Asumu Takikawa as...@ccs.neu.edu wrote:
 On 2014-10-28 12:05:12 -0400, sa...@racket-lang.org wrote:
 | Avoid requires of contracts when they're not used.
 |
 | This changes when various libraries that provide contract
 | support to possible contracted bindings to declare when
 | those bindings are needed.

 Is there some unit test we can write that will check to make sure these
 requires are not included when they're not used?

 (I ask because there are some refactorings of contract generation I'd
  like to merge eventually and I don't want to break the improvement
  you've made here)

I think we could add a test that the empty `#lang typed/racket/base`
file doesn't depend on, for example, `typed-racket/utils/any-wrap`
using `raco show-dependencies`

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


Re: [racket-dev] Strange issue with identifier-binding being wrong for lexical variables

2014-10-22 Thread Sam Tobin-Hochstadt
On Wed, Oct 22, 2014 at 10:20 AM, Matthew Flatt mfl...@cs.utah.edu wrote:
 I agree that this is broken, but I'd like to put it on hold, because
 its another basic problem with the way the current macro expander
 represents lexical context.

 Adjusting the context of the expressions changes the result, because
 its the macro-introduced nature of the `main` definition that triggers
 the bad result from `identifier-binding`.

 Expansions that produce this bad `identifier-binding` result probably
 happen up all the time. They don't bother the bytecode compiler,
 because the compiler uses `free-identifier=?` to compare bindings in
 expanded code, keeping track of all of the bindings that are in the
 environment of a given expression. Depending on your use case, that
 might be the way to go for now.

If I understand correctly, I should maintain an environment of
lexically-bound identifiers at every point, and if a given identifier
is in that environment, it should be treated as lexical, even if
`identifier-binding` says that it's a module-bound variable. Only if
an identifier isn't currently bound should I treat it as a
module-bound variable.

Does that sound right? This would be easy enough for me to do.

Sam


 At Tue, 21 Oct 2014 22:26:26 -0400, Sam Tobin-Hochstadt wrote:
 I've found what I think is a bug in the expander where lexical
 references can get an `identifier-binding` result that suggests that
 they're module-bound.

 In particular, you need these three files:

 bugtest.rkt:

 (module bugtest wraptest.rkt)

 bugtest.scm:

 (define (gcbench)
   (define main #f)
   main)

 (define main #f)

 wraptest.rkt:

 #lang racket/base
 (provide (rename-out (module-begin #%module-begin)))

 (require racket/include
  (for-syntax racket/base))

 (define-syntax (module-begin stx)
   (define name (syntax-property stx 'enclosing-module-name))
   #`(#%module-begin
  (include #,(format ~a.scm name

 Then run the macro stepper with macro hiding off on bugtest.rkt.
 Click on the reference to `main` inside `gcbench`. You'll see that it
 says that it's a module-bound variable named `main.2` which is defined
 in this module.

 Then try changing the name of the top-level definition in bugtest.scm
 to `main2`. Re-run the macro stepper, and you'll see that the
 identifier-binding is now lexical.

 I tried a few things to get this to go away (such as using
 `#%plain-module-begin`) which didn't work. Reducing it to two files,
 ie doing the include directly in bugtest.rkt, made the problem
 disappear.

 Changing the body of the `module-begin` macro to:

 (define-syntax (module-begin stx)
   (define name (syntax-property stx 'enclosing-module-name))
   #`(#%module-begin
  #,(datum-syntax stx `(include ,(format ~a.scm name)))
  #,(datum-syntax stx '(main

 and then providing a bunch of extra stuff made the issue go away.
 Because there's the workaround, the issue isn't urgent.

 Sam (and Tobias, who found this bug)

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


[racket-dev] Strange issue with identifier-binding being wrong for lexical variables

2014-10-21 Thread Sam Tobin-Hochstadt
I've found what I think is a bug in the expander where lexical
references can get an `identifier-binding` result that suggests that
they're module-bound.

In particular, you need these three files:

bugtest.rkt:

(module bugtest wraptest.rkt)

bugtest.scm:

(define (gcbench)
  (define main #f)
  main)

(define main #f)

wraptest.rkt:

#lang racket/base
(provide (rename-out (module-begin #%module-begin)))

(require racket/include
 (for-syntax racket/base))

(define-syntax (module-begin stx)
  (define name (syntax-property stx 'enclosing-module-name))
  #`(#%module-begin
 (include #,(format ~a.scm name

Then run the macro stepper with macro hiding off on bugtest.rkt.
Click on the reference to `main` inside `gcbench`. You'll see that it
says that it's a module-bound variable named `main.2` which is defined
in this module.

Then try changing the name of the top-level definition in bugtest.scm
to `main2`. Re-run the macro stepper, and you'll see that the
identifier-binding is now lexical.

I tried a few things to get this to go away (such as using
`#%plain-module-begin`) which didn't work. Reducing it to two files,
ie doing the include directly in bugtest.rkt, made the problem
disappear.

Changing the body of the `module-begin` macro to:

(define-syntax (module-begin stx)
  (define name (syntax-property stx 'enclosing-module-name))
  #`(#%module-begin
 #,(datum-syntax stx `(include ,(format ~a.scm name)))
 #,(datum-syntax stx '(main

and then providing a bunch of extra stuff made the issue go away.
Because there's the workaround, the issue isn't urgent.

Sam (and Tobias, who found this bug)
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Working Cairo-bindings for Racket?

2014-09-27 Thread Sam Tobin-Hochstadt
No, I'm suggesting that while I think a real binding to cairo would be a
good idea, it should be based on the code already in racket/draw and that
the code in my library is probably useless. Feel free to use any of it that
you find useful, though.

Sam
On Sep 27, 2014 5:08 AM, Antti Karttunen antti.karttu...@gmail.com
wrote:



 On Fri, Sep 26, 2014 at 4:05 PM, Sam Tobin-Hochstadt sa...@cs.indiana.edu
  wrote:

 Instead of changing my Planet package, it would be better to provide
 an FFI to cairo based on the existing one that's in the library you
 mention. I don't think any of my package would be useful for that,
 though.



 Did I understand right that your cairo.ss is intended to work with some
 substantially earlier version of Cairo-library, and you want to keep it
 that way?

 In any case, at least I realized that
 (require racket/draw/unsafe/cairo-lib)
 followed by  (define libcairo cairo-lib)

 is (just ?) a more portable way of saying:

 (define libcairo (ffi-lib libcairo))
 [Or in Windows: (define libcairo (ffi-lib libcairo-2)) because it is
 called libcairo-2.dll]

 Like this:
 #lang racket
 (require racket/draw/unsafe/cairo-lib)
 (require ffi/unsafe)

 cairo-lib
 #ffi-lib
  (define libcairo (ffi-lib libcairo))
 . . ffi-lib: couldn't open libcairo.dll (The specified module could not
 be found.; errno=126)
  (define libcairo (ffi-lib libcairo-2))
  libcairo
 #ffi-lib
  (eq? cairo-lib libcairo)
 #t
 

 


 So I guess making my own set of bindings shouldn't be too much of
 racket-science...


 Best,

 Antti


 Sam

 On Fri, Sep 26, 2014 at 8:44 AM, Antti Karttunen
 antti.karttu...@gmail.com wrote:
 
  Another question:
 
  Would it be a big job to edit the bindings in
 
 http://planet.racket-lang.org/package-source/samth/cairo.plt/1/0/cairo.ss
  so that it worked with the current
 
  (require racket/draw/unsafe/cairo-lib)
 
  cairo-lib
  #ffi-lib
 
  ?
 
  I guess it's not just question of deprecated names for Cairo
 functions as
  mentioned in the ticket:
  http://planet.racket-lang.org/trac/ticket/357
 
  but also code like: (define libcairo (ffi-lib libcairo))
 
  right in the beginning of .../samth/cairo.plt/1/0/cairo.ss
  ?
 
 
  Yours,
 
  Antti Karttunen
 
 
  _
Racket Developers list:
http://lists.racket-lang.org/dev
 



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


Re: [racket-dev] Working Cairo-bindings for Racket?

2014-09-26 Thread Sam Tobin-Hochstadt
Instead of changing my Planet package, it would be better to provide
an FFI to cairo based on the existing one that's in the library you
mention. I don't think any of my package would be useful for that,
though.

Sam

On Fri, Sep 26, 2014 at 8:44 AM, Antti Karttunen
antti.karttu...@gmail.com wrote:

 Another question:

 Would it be a big job to edit the bindings in
 http://planet.racket-lang.org/package-source/samth/cairo.plt/1/0/cairo.ss
 so that it worked with the current

 (require racket/draw/unsafe/cairo-lib)

 cairo-lib
 #ffi-lib

 ?

 I guess it's not just question of deprecated names for Cairo functions as
 mentioned in the ticket:
 http://planet.racket-lang.org/trac/ticket/357

 but also code like: (define libcairo (ffi-lib libcairo))

 right in the beginning of .../samth/cairo.plt/1/0/cairo.ss
 ?


 Yours,

 Antti Karttunen


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

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


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

2014-09-03 Thread Sam Tobin-Hochstadt
On Wed, Sep 3, 2014 at 10:53 AM, Jay McCarthy j...@racket-lang.org wrote:
 I need to revert this because it horribly breaks the bootstrapping
 phase. It may be possible to make the core have a package in the
 future, but it's not an easy change.

Is this because code expects #f instead of base? Or for some other reason?

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


Re: [racket-dev] current packages' docs, errors, and conflicts

2014-08-18 Thread Sam Tobin-Hochstadt
On Tue, Jul 8, 2014 at 8:14 AM, Matthew Flatt mfl...@cs.utah.edu wrote:
 At Tue, 08 Jul 2014 14:08:27 +0200, Jan Dvořák wrote:

 Can you provide some guidelines on docs naming?
 I am responsible for half of the conflicts. :-)

 A package X that provides a collection X of the same name should
 probably also call its documentation X.

What should we suggest when two packages both have collections named
X? This is the case for the c and c-utils packages, which both
provide the c collection.

Sam

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


Re: [racket-dev] Should `register-finalizer` unwrap impersonators?

2014-08-17 Thread Sam Tobin-Hochstadt
How would that change things here? The issue is about
finalizer-for-what, and that chaperones/impersonators affect object
identity.

Sam

On Sun, Aug 17, 2014 at 3:37 PM, Matthias Felleisen
matth...@ccs.neu.edu wrote:

 Could we benefit from an abstract/opaque Finalizer type here? I know we don't 
 have those yet but it may address the general problem. -- Matthias




 On Aug 16, 2014, at 8:55 AM, Neil Toronto wrote:

 Short version: the contract system doesn't allow `register-finalizer` to be 
 used in Typed Racket.

 Long version: consider the following Typed Racket program, in which 
 instances of `os-resource-wrapper` represent an operating system resource 
 `os-resource`, which itself is just a counter. It attempts to register a 
 finalizer for allocated wrappers, which decrements the counter.


 #lang typed/racket

 (require/typed
 ffi/unsafe
 [register-finalizer  (All (A) (- A (- A Any) Void))])

 (: os-resource Integer)
 (define os-resource 0)

 (struct os-resource-wrapper ())

 (: alloc-os-resource (- os-resource-wrapper))
 (define (alloc-os-resource)
  (set! os-resource (add1 os-resource))
  (define w (os-resource-wrapper))
  (register-finalizer w (λ (w) (set! os-resource (sub1 os-resource
  w)

 (define w (alloc-os-resource))
 (printf os-resource = ~v~n os-resource)
 (collect-garbage)
 (sleep 1)  ; give finalizers a chance to run
 (printf os-resource = ~v~n os-resource)


 I get this output:

  os-resource = 1
  os-resource = 0

 The finalizer is being run while the program still has a pointer to the 
 wrapper object. I think it's because the wrapper object is being 
 impersonated when it's sent across the contract barrier, and the 
 *impersonator* is getting the finalizer. (Or it's a chaperone, or an 
 impostor, or a charlatan, or whatever. Let's go with impersonator.)

 In my specific case, the OS resources are OpenGL objects; e.g. vertex object 
 arrays. The call to `register-finalizer` *must* be in Typed Racket code 
 because the wrapper contains an (Instance GL-Context%), which can't have a 
 contract put on it, so it can't pass from untyped to typed code.

 Is there any reason for `register-finalizer` to behave this way? Does it 
 ever make sense to register a finalizer on an impersonator?

 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] Should `register-finalizer` unwrap impersonators?

2014-08-17 Thread Sam Tobin-Hochstadt
Can you say more about what the API for what you're imagining is?

Sam

On Sun, Aug 17, 2014 at 3:41 PM, Matthias Felleisen
matth...@ccs.neu.edu wrote:

 I am imagining that the type compilation of type Finalizer and such things 
 would be parameterized over programmer code which would yield a 'trusted' 
 'thing' in this case except that this would open the door for other such 
 things.




 On Aug 17, 2014, at 3:39 PM, Sam Tobin-Hochstadt wrote:

 How would that change things here? The issue is about
 finalizer-for-what, and that chaperones/impersonators affect object
 identity.

 Sam

 On Sun, Aug 17, 2014 at 3:37 PM, Matthias Felleisen
 matth...@ccs.neu.edu wrote:

 Could we benefit from an abstract/opaque Finalizer type here? I know we 
 don't have those yet but it may address the general problem. -- Matthias




 On Aug 16, 2014, at 8:55 AM, Neil Toronto wrote:

 Short version: the contract system doesn't allow `register-finalizer` to 
 be used in Typed Racket.

 Long version: consider the following Typed Racket program, in which 
 instances of `os-resource-wrapper` represent an operating system resource 
 `os-resource`, which itself is just a counter. It attempts to register a 
 finalizer for allocated wrappers, which decrements the counter.


 #lang typed/racket

 (require/typed
 ffi/unsafe
 [register-finalizer  (All (A) (- A (- A Any) Void))])

 (: os-resource Integer)
 (define os-resource 0)

 (struct os-resource-wrapper ())

 (: alloc-os-resource (- os-resource-wrapper))
 (define (alloc-os-resource)
 (set! os-resource (add1 os-resource))
 (define w (os-resource-wrapper))
 (register-finalizer w (λ (w) (set! os-resource (sub1 os-resource
 w)

 (define w (alloc-os-resource))
 (printf os-resource = ~v~n os-resource)
 (collect-garbage)
 (sleep 1)  ; give finalizers a chance to run
 (printf os-resource = ~v~n os-resource)


 I get this output:

 os-resource = 1
 os-resource = 0

 The finalizer is being run while the program still has a pointer to the 
 wrapper object. I think it's because the wrapper object is being 
 impersonated when it's sent across the contract barrier, and the 
 *impersonator* is getting the finalizer. (Or it's a chaperone, or an 
 impostor, or a charlatan, or whatever. Let's go with impersonator.)

 In my specific case, the OS resources are OpenGL objects; e.g. vertex 
 object arrays. The call to `register-finalizer` *must* be in Typed Racket 
 code because the wrapper contains an (Instance GL-Context%), which can't 
 have a contract put on it, so it can't pass from untyped to typed code.

 Is there any reason for `register-finalizer` to behave this way? Does it 
 ever make sense to register a finalizer on an impersonator?

 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] Should `register-finalizer` unwrap impersonators?

2014-08-16 Thread Sam Tobin-Hochstadt
That's clearly the right solution for this particular bug, but it does
seem like there's a more general problem here.

Sam

On Sat, Aug 16, 2014 at 10:40 AM, Robby Findler
ro...@eecs.northwestern.edu wrote:
 Seems simplest to be to have typed racket know to trust register finalizer
 and thus avoid wrapping it with a contract.

 Robby


 On Saturday, August 16, 2014, Neil Toronto neil.toro...@gmail.com wrote:

 Short version: the contract system doesn't allow `register-finalizer` to
 be used in Typed Racket.

 Long version: consider the following Typed Racket program, in which
 instances of `os-resource-wrapper` represent an operating system resource
 `os-resource`, which itself is just a counter. It attempts to register a
 finalizer for allocated wrappers, which decrements the counter.


 #lang typed/racket

 (require/typed
  ffi/unsafe
  [register-finalizer  (All (A) (- A (- A Any) Void))])

 (: os-resource Integer)
 (define os-resource 0)

 (struct os-resource-wrapper ())

 (: alloc-os-resource (- os-resource-wrapper))
 (define (alloc-os-resource)
   (set! os-resource (add1 os-resource))
   (define w (os-resource-wrapper))
   (register-finalizer w (λ (w) (set! os-resource (sub1 os-resource
   w)

 (define w (alloc-os-resource))
 (printf os-resource = ~v~n os-resource)
 (collect-garbage)
 (sleep 1)  ; give finalizers a chance to run
 (printf os-resource = ~v~n os-resource)


 I get this output:

   os-resource = 1
   os-resource = 0

 The finalizer is being run while the program still has a pointer to the
 wrapper object. I think it's because the wrapper object is being
 impersonated when it's sent across the contract barrier, and the
 *impersonator* is getting the finalizer. (Or it's a chaperone, or an
 impostor, or a charlatan, or whatever. Let's go with impersonator.)

 In my specific case, the OS resources are OpenGL objects; e.g. vertex
 object arrays. The call to `register-finalizer` *must* be in Typed Racket
 code because the wrapper contains an (Instance GL-Context%), which can't
 have a contract put on it, so it can't pass from untyped to typed code.

 Is there any reason for `register-finalizer` to behave this way? Does it
 ever make sense to register a finalizer on an impersonator?

 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] SGC as default

2014-08-12 Thread Sam Tobin-Hochstadt
How difficult would it be to allow the bootstrap process to use a
preexisting Racket installation? This would alleviate some of the
performance loss, for example in rebuilds by developers or in continuous
integration.

Sam
On Aug 11, 2014 11:16 PM, Matthew Flatt mfl...@cs.utah.edu wrote:

 I've changed the Racket CGC implementation --- which is mostly used
 only to build the normal Racket variant --- to use SGC by default,
 instead of the Boehm GC. The intent of the switch is to make the more
 portable GC the default.

 If you have an existing build in a repo checkout, then `make` is likely
 to fail, because the makefile dependencies are not precise enough to
 deal with the switch. You can discard your old build directory, or it
 might work to simply delete

   builddir/racket/libmzgc.a

 If you're using CGC and want to continue using the Boehm GC, then
 provide `--disable-sgc` to `configure`. I've tuned SGC to bring its
 performance closer to the Boehm GC, but it's still slower.

 _
   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

2014-07-29 Thread Sam Tobin-Hochstadt
Plumbers look like a fundamental new runtime system concept, and so I think
we should mention them, even though most people won't use them.

Sam
On Jul 29, 2014 4:02 AM, Matthew Flatt mfl...@cs.utah.edu wrote:

 At Mon, 28 Jul 2014 14:33:07 -0400, Ryan Culpepper wrote:
  mflatt:
  - ARM JIT: fix software floating-point (ffb0dd52)
  - add plumbers (d5b42f8c)
  - raco make: improve parallelism (9e3b9844)
  - deprecate 3-arg module name resolver calls (8aaa3fc5)
  - win32: support symbolic links (3e3cb716, 9fed5b58)
  - drawing, bounding boxes, picts, scribble
 (970b040d, 37af1c8e, c4a58dc4, 05760a12, dac8ba28)

 These seem too minor to mention in a release announcement. (FWIW, I
 think the first one was included in 6.0.1.)

 Possibly, it's worth noting the upgraded native libraries on Windows
 and Mac OS X:

  * Upgraded and normalized versions of graphics libraries and
dependencies (Pango, Cairo, GLib, etc.) that are bundled with Racket
on Windows and Mac OS X. For example, FreeType support is
consistently enabled.

 Like Robby's bullets, though, feel free to leave that one out.

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

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


Re: [racket-dev] Surprising behavior of for/fold. Bug?

2014-07-29 Thread Sam Tobin-Hochstadt
`#:when` and `#:unless` introduce nesting, a la `for/fold*`. So yes,
you should expect this.

Sam

On Tue, Jul 29, 2014 at 1:23 PM, J. Ian Johnson i...@ccs.neu.edu wrote:
 This will eat all your memory,

 (for/list ([x '(0 1 2 3 4 5 6)]
#:unless (= x 4)
[i (in-naturals)])
   x)

 and this won't.

 (for/list ([x '(0 1 2 3 4 5 6)]
[i (in-naturals)]
#:unless (= x 4))
   x)

 Should we expect this behavior? I was really surprised by this.
 -Ian
 _
   Racket Developers list:
   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Unable to expand cross-phase persistent module

2014-07-29 Thread Sam Tobin-Hochstadt
Here's a simpler version of this problem:

#lang racket
(parameterize ([current-namespace (make-base-namespace)])
  (expand (datum-syntax
   #f
   '(module m '#%kernel
  (#%declare #:cross-phase-persistent)

Sam

On Wed, Jul 16, 2014 at 12:59 PM, Sam Tobin-Hochstadt
sa...@cs.indiana.edu wrote:
 Running `expand` on the module defined in `racket/tcp` errors.

 In transcript form:

 - (define p (open-input-file
 /home/samth/sw/plt/racket/collects/racket/tcp.rkt))
 - (define mod (read-syntax (object-name p) p))
 - (parameterize ([current-namespace (make-base-namespace)])
  (expand (namespace-syntax-introduce mod)))
 ; /home/samth/sw/plt/racket/collects/racket/tcp.rkt::2: module: cannot be
 ;   cross-phase persistent due to required modules
 ;   in: (#%module-begin (#%require (all-except (quote #%network) 
 tcp-addresses)
 ; (rename (quote #%network) c:tcp-addresses tcp-addresses)) (#%provide
 ; tcp-connect tcp-connect/enable-break tcp-listen tcp-close
 ; tcp-accept-ready? tcp-accept tcp-accept-evt tcp-accept...
 ; [,bt for context]

 I don't know why it would do this. The same thing happens with the
 minimal module that's declared cross-phase persistent.

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


Re: [racket-dev] A tricky chaperone puzzle

2014-07-25 Thread Sam Tobin-Hochstadt
I only thought of it because the first thing I tried was to break the
chaperone invariant, thinking that 2 might already have been the behavior.
I only came up with the access control variant when that didn't work.

Sam
On Jul 25, 2014 6:04 AM, Matthew Flatt mfl...@cs.utah.edu wrote:

 Unless I still have it wrong, the implementation of 2 was
 straightforward.

 I would have overlooked the need to restrict `chaperone-struct` to
 chaperones of accessors and mutators if you hadn't mentioned it.

 At Thu, 24 Jul 2014 15:45:18 -0400, Sam Tobin-Hochstadt wrote:
  Consider the following module:
 
  (module m racket
(struct x [a])
(define v1 (x 'secret))
(define v2 (x 'public))
(provide v1 v2)
(provide/contract [x-a (- x? (not/c 'secret))]))
 
  It appears that this ensures that you can't get 'secret. But, it turns
  out that I can write a function outside of `m` that behaves like `x-a`
  without the contract:
 
  (require (prefix-in m: 'm))
 
  (define (x-a v)
(define out #f)
(with-handlers ([void void])
  (m:x-a (chaperone-struct v m:x-a (λ (s v) (set! out v) v
out)
 
  Now this works:
 
  (displayln (x-a m:v1)) ;; = 'secret
 
  The problem is that `m:x-a` is treated as a
  `struct-accessor-procedure?`, which is a capability for accessing the
  a field, even though it's a significantly restricted capability.
 
  There are a couple possible solutions I've thought of:
 
  1. Require a non-chaperoned/impersonated accessor.
  2. Actually use the chaperoned/impersonatored accessor to get the
  value out instead of the underlying accessor.
 
  1 is a little less expressive. But note that 2 means that you have to
  only allow chaperoned procedures with `chaperone-struct`, and imposes
  significant complication on the runtime.
 
  I favor 1.
 
  Sam
 
  _
Racket Developers list:
http://lists.racket-lang.org/dev

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


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

2014-07-25 Thread Sam Tobin-Hochstadt
On Fri, Jul 25, 2014 at 10:39 AM,  mfl...@racket-lang.org wrote:

 | As far as I can tell, we have to compute ourselves whether a
 | date is in daylight-saving time based on specifications of
 | when daylight and standard times start. That part seems tricky
 | and could use extra review.

From a quick search of the repository, it looks like
`scheme_get_seconds` and `seconds_to_date` aren't used anywhere else
in the C code, and thus could be rewritten in Racket using the FFI,
which might make the extra review easier. :)

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


[racket-dev] A tricky chaperone puzzle

2014-07-24 Thread Sam Tobin-Hochstadt
Consider the following module:

(module m racket
  (struct x [a])
  (define v1 (x 'secret))
  (define v2 (x 'public))
  (provide v1 v2)
  (provide/contract [x-a (- x? (not/c 'secret))]))

It appears that this ensures that you can't get 'secret. But, it turns
out that I can write a function outside of `m` that behaves like `x-a`
without the contract:

(require (prefix-in m: 'm))

(define (x-a v)
  (define out #f)
  (with-handlers ([void void])
(m:x-a (chaperone-struct v m:x-a (λ (s v) (set! out v) v
  out)

Now this works:

(displayln (x-a m:v1)) ;; = 'secret

The problem is that `m:x-a` is treated as a
`struct-accessor-procedure?`, which is a capability for accessing the
a field, even though it's a significantly restricted capability.

There are a couple possible solutions I've thought of:

1. Require a non-chaperoned/impersonated accessor.
2. Actually use the chaperoned/impersonatored accessor to get the
value out instead of the underlying accessor.

1 is a little less expressive. But note that 2 means that you have to
only allow chaperoned procedures with `chaperone-struct`, and imposes
significant complication on the runtime.

I favor 1.

Sam

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


[racket-dev] strange top-level binding for module-defined identifiers

2014-07-24 Thread Sam Tobin-Hochstadt
If you take this program (which is a lot like the implementation of
`racket/fixnum`):

#lang racket/base

(require '#%flfxnum
 racket/private/vector-wraps
 racket/unsafe/ops
 (for-syntax racket/base))

(define-vector-wraps fxvector
  fixnum? fixnum?
  fxvector? fxvector-length fxvector-ref fxvector-set! make-fxvector
  unsafe-fxvector-ref unsafe-fxvector-set! unsafe-fxvector-length
  in-fxvector*
  in-fxvector
  for/fxvector
  for*/fxvector
  fxvector-copy
  0)

And run it in the macro stepper with macro hiding off, at the end you
get a fully-expanded module where the first definition is
`:fXvector-gen`. However, if you click on this identifier, either in
the definition or in a subsequent use, it says Apparent identifier
binding: none (which means that `identifier-binding` returns #f,
which can be confirmed on the expanded syntax).

How can this happen? Is it a bug in something, or a special case that
I didn't expect?

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


Re: [racket-dev] strange top-level binding for module-defined identifiers

2014-07-24 Thread Sam Tobin-Hochstadt
Ok, here's a much simpler example:

#lang racket

(module foo racket
  (provide def-wrap)
  (define-syntax-rule (def-wrap)
(begin  (define y 1) y)))

(module bar racket
  (require (submod .. foo))
  (def-wrap))

In the fully-expanded syntax, the macro stepper suggests that `y` has
no apparent binding.

At this point it seems unlikely that it's a bug, since it happens all
the time, but I still don't understand.

Sam

On Thu, Jul 24, 2014 at 4:08 PM, Sam Tobin-Hochstadt
sa...@cs.indiana.edu wrote:
 If you take this program (which is a lot like the implementation of
 `racket/fixnum`):

 #lang racket/base

 (require '#%flfxnum
  racket/private/vector-wraps
  racket/unsafe/ops
  (for-syntax racket/base))

 (define-vector-wraps fxvector
   fixnum? fixnum?
   fxvector? fxvector-length fxvector-ref fxvector-set! make-fxvector
   unsafe-fxvector-ref unsafe-fxvector-set! unsafe-fxvector-length
   in-fxvector*
   in-fxvector
   for/fxvector
   for*/fxvector
   fxvector-copy
   0)

 And run it in the macro stepper with macro hiding off, at the end you
 get a fully-expanded module where the first definition is
 `:fXvector-gen`. However, if you click on this identifier, either in
 the definition or in a subsequent use, it says Apparent identifier
 binding: none (which means that `identifier-binding` returns #f,
 which can be confirmed on the expanded syntax).

 How can this happen? Is it a bug in something, or a special case that
 I didn't expect?

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


Re: [racket-dev] A tricky chaperone puzzle

2014-07-24 Thread Sam Tobin-Hochstadt
Thinking about it more, I think it has to be #2, since otherwise:

(module m1 racket
  (struct x (a))
  (provide (contract-out (struct x ([a integer?]

(module m2 racket
  (require 'm1)
  (provide (contract-out (struct x ([a even?]

won't work, which seems like something that should be supported.

Sam

On Thu, Jul 24, 2014 at 4:25 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
 Nice example. Offhand, I think that #2 is right, but I'll have to look
 at it more to be sure.

 At Thu, 24 Jul 2014 15:45:18 -0400, Sam Tobin-Hochstadt wrote:
 Consider the following module:

 (module m racket
   (struct x [a])
   (define v1 (x 'secret))
   (define v2 (x 'public))
   (provide v1 v2)
   (provide/contract [x-a (- x? (not/c 'secret))]))

 It appears that this ensures that you can't get 'secret. But, it turns
 out that I can write a function outside of `m` that behaves like `x-a`
 without the contract:

 (require (prefix-in m: 'm))

 (define (x-a v)
   (define out #f)
   (with-handlers ([void void])
 (m:x-a (chaperone-struct v m:x-a (λ (s v) (set! out v) v
   out)

 Now this works:

 (displayln (x-a m:v1)) ;; = 'secret

 The problem is that `m:x-a` is treated as a
 `struct-accessor-procedure?`, which is a capability for accessing the
 a field, even though it's a significantly restricted capability.

 There are a couple possible solutions I've thought of:

 1. Require a non-chaperoned/impersonated accessor.
 2. Actually use the chaperoned/impersonatored accessor to get the
 value out instead of the underlying accessor.

 1 is a little less expressive. But note that 2 means that you have to
 only allow chaperoned procedures with `chaperone-struct`, and imposes
 significant complication on the runtime.

 I favor 1.

 Sam

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

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


Re: [racket-dev] A tricky chaperone puzzle

2014-07-24 Thread Sam Tobin-Hochstadt
Struct chaperones are the important part, I think.

But the theorem would be false under option 1, I think. Adding contracts
can add non-contract errors -- the error you get when a you supply the
wrong accessor for struct-chaperone.

Sam
On Jul 24, 2014 7:54 PM, Robby Findler ro...@eecs.northwestern.edu
wrote:

 Ah, nope. That model doesn't include function chaperones!

 Robby

 On Thu, Jul 24, 2014 at 6:14 PM, Robby Findler
 ro...@eecs.northwestern.edu wrote:
  I also lean towards #2. What does the redex model say? Most of those
  pieces are in it, I think.
 
  Robby
 
  On Thu, Jul 24, 2014 at 3:25 PM, Matthew Flatt mfl...@cs.utah.edu
 wrote:
  Nice example. Offhand, I think that #2 is right, but I'll have to look
  at it more to be sure.
 
  At Thu, 24 Jul 2014 15:45:18 -0400, Sam Tobin-Hochstadt wrote:
  Consider the following module:
 
  (module m racket
(struct x [a])
(define v1 (x 'secret))
(define v2 (x 'public))
(provide v1 v2)
(provide/contract [x-a (- x? (not/c 'secret))]))
 
  It appears that this ensures that you can't get 'secret. But, it turns
  out that I can write a function outside of `m` that behaves like `x-a`
  without the contract:
 
  (require (prefix-in m: 'm))
 
  (define (x-a v)
(define out #f)
(with-handlers ([void void])
  (m:x-a (chaperone-struct v m:x-a (λ (s v) (set! out v) v
out)
 
  Now this works:
 
  (displayln (x-a m:v1)) ;; = 'secret
 
  The problem is that `m:x-a` is treated as a
  `struct-accessor-procedure?`, which is a capability for accessing the
  a field, even though it's a significantly restricted capability.
 
  There are a couple possible solutions I've thought of:
 
  1. Require a non-chaperoned/impersonated accessor.
  2. Actually use the chaperoned/impersonatored accessor to get the
  value out instead of the underlying accessor.
 
  1 is a little less expressive. But note that 2 means that you have to
  only allow chaperoned procedures with `chaperone-struct`, and imposes
  significant complication on the runtime.
 
  I favor 1.
 
  Sam
 
  _
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] Pre-Release Checklist for v6.1

2014-07-23 Thread Sam Tobin-Hochstadt
The margin-notes appear to work correctly on Chrome but wrong on
Firefox on my Linux system.

Sam

On Wed, Jul 23, 2014 at 8:13 AM, Robby Findler
ro...@eecs.northwestern.edu wrote:
 Believe it or not I actually tried that. Screenshot:
 http://www.eecs.northwestern.edu/~robby/tmp/x.png (that's Chome and
 Safari).

 Robby

 On Wed, Jul 23, 2014 at 7:02 AM, Neil Toronto neil.toro...@gmail.com wrote:
 They only do it on my system if the browser window is too narrow. And
 overlap is the wrong word: the margin notes are completely inside the blue
 boxes.

 BTW, #2 is fixed now. I added an #:unscaled? #t somewhere; Matthew did the
 actual work. :D

 Neil


 On 07/22/2014 07:20 PM, Robby Findler wrote:

 FWIW, I don't see the overlap in Chrome (on a mac) or in Safari.

 Robby

 On Tue, Jul 22, 2014 at 2:01 PM, Neil Toronto neil.toro...@gmail.com
 wrote:

 On 07/17/2014 08:03 PM, Ryan Culpepper wrote:


 * Neil Toronto neil.toro...@gmail.com
 - Plot Tests
 - Images Tests
 - Inspect icons
 - Math tests



 All tests pass, but two things need fixing: some margin notes in the math
 documentation, and `compiled-bitmap` and `compiled-bitmap-list` when they
 embed compressed bitmaps.

 1. There's an issue with margin notes overlapping blue boxes in some of
 the
 math documentation. I haven't looked into it deeply yet, so I'm not sure
 what causes it or what should be done to fix it. You can see it in the
 pre-release docs here:

  http://pre-release.racket-lang.org/doc/math/matrix_basic.html

 2. The `compiled-bitmap` and `compiled-bitmap-list` macros yield bitmaps
 that are the right size but with a half-size image tucked into the
 upper-left corner, when the bitmaps are stored in the module as JPEGs.
 (This
 doesn't affect DrRacket's icons because they're all stored as PNGs.) I
 suspect there's a missing #:unscaled? #t or two.

 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] src-id in identifier-binding for same-module definitions

2014-07-17 Thread Sam Tobin-Hochstadt
Ah, now I know what I was doing wrong. I was using identifier-binding for
references, but not for definitions. Now that I'm using it in both places,
things seem to work.

Thanks!
Sam
On Jul 17, 2014 3:08 AM, Matthew Flatt mfl...@cs.utah.edu wrote:

 Does `identifier-binding` not give you the symbol that you need?

 At Wed, 16 Jul 2014 23:32:46 -0400, Sam Tobin-Hochstadt wrote:
  Ok, I thought I had figured this out, but I was wrong.
 
  Here's what I want to be able to do:
 
   - take an identifier in a fully-expanded source file
   - translate that identifier to some symbol in a predictable way
   - so that other references to that same (free-identifier=?)
  identifier get translated to the same symbol
 
  It's pretty easy to do this in a single module -- just keep a
  free-id-table of all the identifiers mapping to gensyms. But I want to
  be able to do this across modules, and across invocations of this
  program. IOW, when I run my program on one source file, I'd like to
  get a symbol for a provided definition that's the same symbol I get
  when I run my program on a different source file containing a
  reference to that definition.
 
  Clearly this is possible, since Racket manages, but is there a way
  that I can do it?
 
  Sam
 
  On Wed, Jul 16, 2014 at 7:55 AM, Matthew Flatt mfl...@cs.utah.edu
 wrote:
   Yes, it can be .2, etc. The numbers are generated as needed to create
   distinct names --- deterministically for a given module compilation,
   assuming that all macros used by expansion are deterministic.
  
   At Wed, 16 Jul 2014 07:36:50 -0400, Sam Tobin-Hochstadt wrote:
   Does that mean that I can/should just drop the .1 to get the defined
 name?
   Can it also be .2 etc?
  
   Sam
   On Jul 16, 2014 4:34 AM, Matthew Flatt mfl...@cs.utah.edu wrote:
  
That `posn1.1` is a unreadable symbol that stands for the symbol
`posn1` plus some marks that distinguish it.
   
In other words, `posn1.1` bridges (in an ugly way) the symbol-based
world of module environments and the identifier-based world of
 syntax.
In the future, I hope to shift module environments to be
identifier-based to avoid these unreadable symbols.
   
At Tue, 15 Jul 2014 09:10:26 -0400, Sam Tobin-Hochstadt wrote:
 If you take this program and fully-expand it in the macro stepper:

 #lang racket
 (struct posn (x y))
 (define p1 (posn 1 2))

 You see that the residual program has an application of the
 `posn1`
 function, which is the hidden constructor. And indeed, the
 fully-expanded program has a definition of `posn1`. However, if
 you
 click on the use of `posn1`, the macro stepper will tell you that
 it's
 defined in this module as `posn1.1`, and provided as `posn1.1` as
 well. If you write program to grovel through the fully-expanded
 syntax, you get these same results as the `src-id` and
 `nominal-src-id` from `identifier-binding`.

 Why is this? And is there a way to get from `posn1.1` to `posn1`
reliably?

 Sam
   

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


[racket-dev] Unable to expand cross-phase persistent module

2014-07-16 Thread Sam Tobin-Hochstadt
Running `expand` on the module defined in `racket/tcp` errors.

In transcript form:

- (define p (open-input-file
/home/samth/sw/plt/racket/collects/racket/tcp.rkt))
- (define mod (read-syntax (object-name p) p))
- (parameterize ([current-namespace (make-base-namespace)])
 (expand (namespace-syntax-introduce mod)))
; /home/samth/sw/plt/racket/collects/racket/tcp.rkt::2: module: cannot be
;   cross-phase persistent due to required modules
;   in: (#%module-begin (#%require (all-except (quote #%network) tcp-addresses)
; (rename (quote #%network) c:tcp-addresses tcp-addresses)) (#%provide
; tcp-connect tcp-connect/enable-break tcp-listen tcp-close
; tcp-accept-ready? tcp-accept tcp-accept-evt tcp-accept...
; [,bt for context]

I don't know why it would do this. The same thing happens with the
minimal module that's declared cross-phase persistent.

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


Re: [racket-dev] src-id in identifier-binding for same-module definitions

2014-07-16 Thread Sam Tobin-Hochstadt
Ok, I thought I had figured this out, but I was wrong.

Here's what I want to be able to do:

 - take an identifier in a fully-expanded source file
 - translate that identifier to some symbol in a predictable way
 - so that other references to that same (free-identifier=?)
identifier get translated to the same symbol

It's pretty easy to do this in a single module -- just keep a
free-id-table of all the identifiers mapping to gensyms. But I want to
be able to do this across modules, and across invocations of this
program. IOW, when I run my program on one source file, I'd like to
get a symbol for a provided definition that's the same symbol I get
when I run my program on a different source file containing a
reference to that definition.

Clearly this is possible, since Racket manages, but is there a way
that I can do it?

Sam

On Wed, Jul 16, 2014 at 7:55 AM, Matthew Flatt mfl...@cs.utah.edu wrote:
 Yes, it can be .2, etc. The numbers are generated as needed to create
 distinct names --- deterministically for a given module compilation,
 assuming that all macros used by expansion are deterministic.

 At Wed, 16 Jul 2014 07:36:50 -0400, Sam Tobin-Hochstadt wrote:
 Does that mean that I can/should just drop the .1 to get the defined name?
 Can it also be .2 etc?

 Sam
 On Jul 16, 2014 4:34 AM, Matthew Flatt mfl...@cs.utah.edu wrote:

  That `posn1.1` is a unreadable symbol that stands for the symbol
  `posn1` plus some marks that distinguish it.
 
  In other words, `posn1.1` bridges (in an ugly way) the symbol-based
  world of module environments and the identifier-based world of syntax.
  In the future, I hope to shift module environments to be
  identifier-based to avoid these unreadable symbols.
 
  At Tue, 15 Jul 2014 09:10:26 -0400, Sam Tobin-Hochstadt wrote:
   If you take this program and fully-expand it in the macro stepper:
  
   #lang racket
   (struct posn (x y))
   (define p1 (posn 1 2))
  
   You see that the residual program has an application of the `posn1`
   function, which is the hidden constructor. And indeed, the
   fully-expanded program has a definition of `posn1`. However, if you
   click on the use of `posn1`, the macro stepper will tell you that it's
   defined in this module as `posn1.1`, and provided as `posn1.1` as
   well. If you write program to grovel through the fully-expanded
   syntax, you get these same results as the `src-id` and
   `nominal-src-id` from `identifier-binding`.
  
   Why is this? And is there a way to get from `posn1.1` to `posn1`
  reliably?
  
   Sam
 
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] src-id in identifier-binding for same-module definitions

2014-07-15 Thread Sam Tobin-Hochstadt
If you take this program and fully-expand it in the macro stepper:

#lang racket
(struct posn (x y))
(define p1 (posn 1 2))

You see that the residual program has an application of the `posn1`
function, which is the hidden constructor. And indeed, the
fully-expanded program has a definition of `posn1`. However, if you
click on the use of `posn1`, the macro stepper will tell you that it's
defined in this module as `posn1.1`, and provided as `posn1.1` as
well. If you write program to grovel through the fully-expanded
syntax, you get these same results as the `src-id` and
`nominal-src-id` from `identifier-binding`.

Why is this? And is there a way to get from `posn1.1` to `posn1` reliably?

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


Re: [racket-dev] Semantics of struct-out with except-out

2014-07-15 Thread Sam Tobin-Hochstadt
On Tue, Jul 15, 2014 at 9:23 AM, J. Ian Johnson i...@ccs.neu.edu wrote:
 I'm working on enhancing struct-info to carry field names as symbols to do 
 nice hygienic things:

 http://lists.racket-lang.org/users/archive/2014-July/063271.html

 I now see that struct-out always provides all field accessors in the static 
 struct-info associated with the struct identifier.
 This means the following produces (list 0 1) instead of an error saying that 
 Foo-x is undefined, or something along those lines:

 #lang racket/load
 (module A racket
   (struct Foo (x y))
   (provide (except-out (struct-out Foo)
Foo-x)))
 (module B racket
   (require 'A)
   (match (Foo 0 1)
 [(Foo x y) (list x y)]))
 (require 'B)

 To make struct-out not so greedy about what it provides would require a 
 backwards-incompatible change. The problem then is, should we (I) do it?

No, the current behavior is reasonable -- static struct info provides
access to the accessors.

 Part of me says yes for intuitive semantics and part of me says no because 
 the implications are that struct-info values will have to be meticulously 
 checked and rebound to mangled identifiers with new information when passing 
 through provide-specs that can affect struct identifiers.
 Should that burden be pushed to future provide-spec implementors? Should it 
 already have been?
 The alternative is to provide special syntax in struct-out to do all the 
 common provide-spec stuff and still not play nice with other provide-specs.
 The upside to this is no name mangling, but the downside is yet more special 
 syntax for what provide-specs should already do, IMHO.

 I'm planning to extend struct-out to allow renaming the fields associated 
 with a struct so the following (contrived example) is possible:

I think this should be delayed to a separate change. Are there cases
in the code base currently where this would be used?

Sam

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


Re: [racket-dev] Semantics of struct-out with except-out

2014-07-15 Thread Sam Tobin-Hochstadt
On Tue, Jul 15, 2014 at 10:12 AM, J. Ian Johnson i...@ccs.neu.edu wrote:
 Code will break if it uses struct to produce structs, provides a renamed an 
 accessor function, and uses an unhygienic feature to name the field.
 The features I know of are struct-copy, struct* match patterns, and 
 contract-out's struct form.

The backwards compatibility is a concern, but even more so, I don't
think it makes sense for hiding a particular identifier from provide,
or renaming it, to change the _contents_ of the static struct info. If
there was an explicit option in `struct-out` to do that, it would make
more sense, but `except-out` should not affect anything but the
identifiers named.

 No one but me probably did this, and that's what led to my discovery of the 
 unhygienic state of struct-copy and my previous regex-based PR to fix it.
 I don't /need/ to rename fields, since in the case that a field accessor is 
 renamed to something entirely different (e.g., Foo-x = Qux), a renamed field 
 doesn't quite benefit readability of a struct-copy that uses field x. If 
 renaming Foo-x to Foo-y, then a x - y rename is helpful. I have not yet come 
 across a need for this however.
 I can wait on this feature of struct-out (and probably contract-out's struct 
 form as well).

If we don't actually have a need for this, then let's wait, since it
seems like it adds a bunch of complexity.

Sam


 Thanks,
 -Ian
 - Original Message -
 From: Sam Tobin-Hochstadt sa...@cs.indiana.edu
 To: J. Ian Johnson i...@ccs.neu.edu
 Cc: dev dev@racket-lang.org
 Sent: Tuesday, July 15, 2014 9:35:01 AM GMT -05:00 US/Canada Eastern
 Subject: Re: [racket-dev] Semantics of struct-out with except-out

 On Tue, Jul 15, 2014 at 9:23 AM, J. Ian Johnson i...@ccs.neu.edu wrote:
 I'm working on enhancing struct-info to carry field names as symbols to do 
 nice hygienic things:

 http://lists.racket-lang.org/users/archive/2014-July/063271.html

 I now see that struct-out always provides all field accessors in the static 
 struct-info associated with the struct identifier.
 This means the following produces (list 0 1) instead of an error saying that 
 Foo-x is undefined, or something along those lines:

 #lang racket/load
 (module A racket
   (struct Foo (x y))
   (provide (except-out (struct-out Foo)
Foo-x)))
 (module B racket
   (require 'A)
   (match (Foo 0 1)
 [(Foo x y) (list x y)]))
 (require 'B)

 To make struct-out not so greedy about what it provides would require a 
 backwards-incompatible change. The problem then is, should we (I) do it?

 No, the current behavior is reasonable -- static struct info provides
 access to the accessors.

 Part of me says yes for intuitive semantics and part of me says no because 
 the implications are that struct-info values will have to be meticulously 
 checked and rebound to mangled identifiers with new information when passing 
 through provide-specs that can affect struct identifiers.
 Should that burden be pushed to future provide-spec implementors? Should it 
 already have been?
 The alternative is to provide special syntax in struct-out to do all the 
 common provide-spec stuff and still not play nice with other provide-specs.
 The upside to this is no name mangling, but the downside is yet more special 
 syntax for what provide-specs should already do, IMHO.

 I'm planning to extend struct-out to allow renaming the fields associated 
 with a struct so the following (contrived example) is possible:

 I think this should be delayed to a separate change. Are there cases
 in the code base currently where this would be used?

 Sam

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


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

2014-07-14 Thread Sam Tobin-Hochstadt
This seems like a situation where the new error message is potentially
more confusing, even though it's technically more correct. There are
lots of other caveats we could add (assuming there isn't a compiler
bug, etc) but I think adding them would make Racket harder to use.

Sam

On Mon, Jul 14, 2014 at 9:11 AM,  ro...@racket-lang.org wrote:
 robby has updated `master' from 737330deb6 to 1dda800ca2.
   http://git.racket-lang.org/plt/737330deb6..1dda800ca2

 =[ One Commit ]=
 Directory summary:
  100.0% racket/collects/racket/contract/private/

 ~~

 1dda800 Robby Findler ro...@racket-lang.org 2014-07-14 08:09
 :
 | add contract-correct caveat to contract violation error messages
 :
   M racket/collects/racket/contract/private/blame.rkt | 1 +

 =[ Overall Diff ]===

 racket/collects/racket/contract/private/blame.rkt
 ~
 --- OLD/racket/collects/racket/contract/private/blame.rkt
 +++ NEW/racket/collects/racket/contract/private/blame.rkt
 @@ -320,6 +320,7 @@
 from-line
 on-line
 blaming-line
 +  (assuming the contract is correct)
 at-line))

  ;; combine-lines : (-* #:rest (listof (or/c string? #f))) string?)
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


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

2014-07-14 Thread Sam Tobin-Hochstadt
I think the vast majority of contract errors that Racket programmers
see will be from contracts that the particular programmer didn't
write. For example: standard library contracts, or contracts from
packages they install, or contracts generated by Typed Racket, or
other such.

For example, here's a simple contract error:

- (require scribble/core)
- (part-parts 7)
; part-parts: contract violation
;   expected: part?
;   given: 7
;   in: the 1st argument of
;   (- part? (listof part?))
;   contract from:
;   pkgs/scribble-lib/scribble/core.rkt
;   blaming: top-level
;(assuming the contract is correct)
;   at: pkgs/scribble-lib/scribble/core.rkt:164.2

What does the assuming the contract is correct mean to the
programmer here? They can't change the contract, and it's not obvious
in what sense the contract being incorrect would change anything.

In general, I think that your new message makes a lot of sense if
programmers mostly experience contracts as strong invariants
protecting complex components specified publicly -- the sort of thing
you've talked about as a marketplace of components. But I don't
think that's how Racket programmers typically experience contracts --
instead, they're more like the example above: simple specifications
protecting small functions implemented privately and used as
error-checking.

Sam

On Mon, Jul 14, 2014 at 9:30 AM, Robby Findler
ro...@eecs.northwestern.edu wrote:
 I do not buy this argument: the user didn't write the compiler but they
 wrote the contract.

 Robby


 On Monday, July 14, 2014, Sam Tobin-Hochstadt sa...@cs.indiana.edu wrote:

 This seems like a situation where the new error message is potentially
 more confusing, even though it's technically more correct. There are
 lots of other caveats we could add (assuming there isn't a compiler
 bug, etc) but I think adding them would make Racket harder to use.

 Sam

 On Mon, Jul 14, 2014 at 9:11 AM,  ro...@racket-lang.org wrote:
  robby has updated `master' from 737330deb6 to 1dda800ca2.
http://git.racket-lang.org/plt/737330deb6..1dda800ca2
 
  =[ One Commit ]=
  Directory summary:
   100.0% racket/collects/racket/contract/private/
 
  ~~
 
  1dda800 Robby Findler ro...@racket-lang.org 2014-07-14 08:09
  :
  | add contract-correct caveat to contract violation error messages
  :
M racket/collects/racket/contract/private/blame.rkt | 1 +
 
  =[ Overall Diff ]===
 
  racket/collects/racket/contract/private/blame.rkt
  ~
  --- OLD/racket/collects/racket/contract/private/blame.rkt
  +++ NEW/racket/collects/racket/contract/private/blame.rkt
  @@ -320,6 +320,7 @@
  from-line
  on-line
  blaming-line
  +  (assuming the contract is correct)
  at-line))
 
   ;; combine-lines : (-* #:rest (listof (or/c string? #f))) string?)
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


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

2014-07-14 Thread Sam Tobin-Hochstadt
On Mon, Jul 14, 2014 at 10:57 AM, Matthias Felleisen
matth...@ccs.neu.edu wrote:

 Unfortunately, it is impossible to distinguish the two kinds of
 contracts. Even if we introduced two different linguistic mechanisms,
 we would simply confuse programmers more.

I certainly agree with that.

I just don't think the additional line in that error message is very
helpful, and it's already a long and scary error message.

Sam

 Let's try this experiment for a while and see what happens.




 On Jul 14, 2014, at 9:46 AM, Sam Tobin-Hochstadt sa...@cs.indiana.edu wrote:

 I think the vast majority of contract errors that Racket programmers
 see will be from contracts that the particular programmer didn't
 write. For example: standard library contracts, or contracts from
 packages they install, or contracts generated by Typed Racket, or
 other such.

 For example, here's a simple contract error:

 - (require scribble/core)
 - (part-parts 7)
 ; part-parts: contract violation
 ;   expected: part?
 ;   given: 7
 ;   in: the 1st argument of
 ;   (- part? (listof part?))
 ;   contract from:
 ;   pkgs/scribble-lib/scribble/core.rkt
 ;   blaming: top-level
 ;(assuming the contract is correct)
 ;   at: pkgs/scribble-lib/scribble/core.rkt:164.2

 What does the assuming the contract is correct mean to the
 programmer here? They can't change the contract, and it's not obvious
 in what sense the contract being incorrect would change anything.

 In general, I think that your new message makes a lot of sense if
 programmers mostly experience contracts as strong invariants
 protecting complex components specified publicly -- the sort of thing
 you've talked about as a marketplace of components. But I don't
 think that's how Racket programmers typically experience contracts --
 instead, they're more like the example above: simple specifications
 protecting small functions implemented privately and used as
 error-checking.

 Sam

 On Mon, Jul 14, 2014 at 9:30 AM, Robby Findler
 ro...@eecs.northwestern.edu wrote:
 I do not buy this argument: the user didn't write the compiler but they
 wrote the contract.

 Robby


 On Monday, July 14, 2014, Sam Tobin-Hochstadt sa...@cs.indiana.edu wrote:

 This seems like a situation where the new error message is potentially
 more confusing, even though it's technically more correct. There are
 lots of other caveats we could add (assuming there isn't a compiler
 bug, etc) but I think adding them would make Racket harder to use.

 Sam

 On Mon, Jul 14, 2014 at 9:11 AM,  ro...@racket-lang.org wrote:
 robby has updated `master' from 737330deb6 to 1dda800ca2.
  http://git.racket-lang.org/plt/737330deb6..1dda800ca2

 =[ One Commit ]=
 Directory summary:
 100.0% racket/collects/racket/contract/private/

 ~~

 1dda800 Robby Findler ro...@racket-lang.org 2014-07-14 08:09
 :
 | add contract-correct caveat to contract violation error messages
 :
  M racket/collects/racket/contract/private/blame.rkt | 1 +

 =[ Overall Diff ]===

 racket/collects/racket/contract/private/blame.rkt
 ~
 --- OLD/racket/collects/racket/contract/private/blame.rkt
 +++ NEW/racket/collects/racket/contract/private/blame.rkt
 @@ -320,6 +320,7 @@
from-line
on-line
blaming-line
 +  (assuming the contract is correct)
at-line))

 ;; combine-lines : (-* #:rest (listof (or/c string? #f))) string?)
 _
  Racket Developers list:
  http://lists.racket-lang.org/dev

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


Re: [racket-dev] racket/fasl allows sandbox escape

2014-07-10 Thread Sam Tobin-Hochstadt
Credit for this discovery goes to Jens -- I just wrote the email.

Sam
On Jul 10, 2014 2:36 AM, Matthew Flatt mfl...@cs.utah.edu wrote:

 I've pushed a repair. To double-check it, change 1140 to something like
 1340, since the table of primitives changed as part of the repair.

 Thanks for the report!

 At Wed, 9 Jul 2014 09:39:50 -0400, Sam Tobin-Hochstadt wrote:
  The following exchange with rudybot, which is running the programs in
  a sandbox, demonstrates the issue:
 
  09:35 samth rudybot: eval (let () (local-require compiler/zo-marshal
  compiler/zo-structs racket/fasl) (fasl-s-exp (zo-marshal
  (compilation-top 3 (prefix 0 '() '()) (let-void 1 #t (install-value 1
  0 #t (primval 1140) (localref #t 0 #f #f #f )))
  09:35 rudybot samth: ; Value: #procedure:unsafe-fx+
  09:36 samth rudybot: eval ((let () (local-require
  compiler/zo-marshal compiler/zo-structs racket/fasl) (fasl-s-exp
  (zo-marshal (compilation-top 3 (prefix 0 '() '()) (let-void 1 #t
  (install-value 1 0 #t (primval 1140) (localref #t 0 #f #f #f )))
  vector-ref vector-ref)
  09:36 rudybot samth: ; Value: 32681168
 
  The relevant program is:
 
  (let ()
(local-require compiler/zo-marshal compiler/zo-structs racket/fasl)
(fasl-s-exp (zo-marshal
(compilation-top 3
   (prefix 0 '() '())
   (let-void 1 #t (install-value 1 0 #t (primval
  1140) (localref #t 0 #f #f #f )))
 
  Sam
  _
Racket Developers list:
http://lists.racket-lang.org/dev

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


[racket-dev] racket/fasl allows sandbox escape

2014-07-09 Thread Sam Tobin-Hochstadt
The following exchange with rudybot, which is running the programs in
a sandbox, demonstrates the issue:

09:35 samth rudybot: eval (let () (local-require compiler/zo-marshal
compiler/zo-structs racket/fasl) (fasl-s-exp (zo-marshal
(compilation-top 3 (prefix 0 '() '()) (let-void 1 #t (install-value 1
0 #t (primval 1140) (localref #t 0 #f #f #f )))
09:35 rudybot samth: ; Value: #procedure:unsafe-fx+
09:36 samth rudybot: eval ((let () (local-require
compiler/zo-marshal compiler/zo-structs racket/fasl) (fasl-s-exp
(zo-marshal (compilation-top 3 (prefix 0 '() '()) (let-void 1 #t
(install-value 1 0 #t (primval 1140) (localref #t 0 #f #f #f )))
vector-ref vector-ref)
09:36 rudybot samth: ; Value: 32681168

The relevant program is:

(let ()
  (local-require compiler/zo-marshal compiler/zo-structs racket/fasl)
  (fasl-s-exp (zo-marshal
  (compilation-top 3
 (prefix 0 '() '())
 (let-void 1 #t (install-value 1 0 #t (primval
1140) (localref #t 0 #f #f #f )))

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


Re: [racket-dev] current packages' docs, errors, and conflicts

2014-07-08 Thread Sam Tobin-Hochstadt
On Tue, Jul 8, 2014 at 8:14 AM, Matthew Flatt mfl...@cs.utah.edu wrote:
 At Tue, 08 Jul 2014 14:08:27 +0200, Jan Dvořák wrote:
 On Tue, 2014-07-08 at 12:46 +0100, Matthew Flatt wrote:
  The rightmost column of the table may need some explanation. The column
  highlights conflicts among names of package-installed executables,
  foreign libraries, and documents. Currently, all the conflicts are
  document names, because several packages have a documents named simply
  manual or main.

 Can you provide some guidelines on docs naming?
 I am responsible for half of the conflicts. :-)

 A package X that provides a collection X of the same name should
 probably also call its documentation X.

 If the package provides both guide and reference documentation,
 then X-guide and X-reference are good choices.


 Thanks for looking into this! I've recently updated the Racket
 documentation, but I expect that more is needed. As far as I can tell,
 nothing in our documentation previously suggested that documentation
 names needs to be distinct.

Is there a reason we can't just make this work with duplicate names
instead? Perhaps disambiguiating by collection name?

I think this would change all the current URLs on
docs.racket-lang.org, so we'd have to fix that, but it seems better to
make us do a fixed amount of work rather than push this coordination
problem onto everyone who writes packages in the future.

Sam

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


Re: [racket-dev] current packages' docs, errors, and conflicts

2014-07-08 Thread Sam Tobin-Hochstadt
On Tue, Jul 8, 2014 at 11:35 AM, Matthew Flatt mfl...@cs.utah.edu wrote:
 At Tue, 8 Jul 2014 10:15:10 -0400, Sam Tobin-Hochstadt wrote:
  - I wonder if using Docker instead of VirtualBox could make
 incrementality easier, since that's one of things that they focus on.

 I don't think it would be easier, but it might be more efficient and
 even easier to set up, so it seems worth trying.

 If you're interested in trying that, the information below should help
 you get oriented.

I'll look into this.

  - I wanted to be able to see which of my packages had problems, so I
 wrote this PR: https://github.com/plt/racket/pull/721 but I'm not sure
 how to test it.

 I've merged and tweaked that change, but maybe you want to make more
 changes... I don't have a good way to try it other than to run a full
 build.

Great, that's what I figured.

  - I think we need to support planet packages -- there are some people
 still releasing new ones, and there are old ones would take
 non-trivial work to port.

 Supporting Planet packages is a lot of work. Overcoming constrained
 network access in the sandbox is the most obvious problem and probably
 easy to solve. A more subtle and important piece of the puzzle is the
 notion of built packages, which can be quickly installed for
 dependent packages or for assembling documentation at the end. Planet
 packages don't have a built concept, and a package that depends on a
 Planet package won't have the right built properties: it will
 install, but not quickly.

 I think we're much better off moving Planet packages to supported
 packages in the new package system --- at least, for use by packages in
 the new package system.

i was mostly thinking of handling packages from
planet-compat.racket-lang.org, which would avoid (some of) the network
access issues and perhaps also the built package issues.

But maybe the problem then just reappears for the regular Planet
packages that the planet-compat packages depend on?

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


Re: [racket-dev] for loops with interleaved escape continuations

2014-07-01 Thread Sam Tobin-Hochstadt
I think this is a good idea, and something that I've wanted for a long
time. But there are ways to make it much better, and generalize to all
loops.

First, recognize that a `for/...` loop is really a recursive function,
which is passing along a bunch of arguments. In this setting,
`continue` means to make a new recursive call with the same arguments
as last time, and `break` means to exit the loop with the current
values of the arguments.

One solution, therefore, is to just bind `break` and `continue`
identifiers as specified to functions that just make these calls. This
works perfectly if you call break/continue in tail position with
respect to the loop body, but does weird things otherwise.

Another solution is to bind break and continue to function which use
let/ec to jump out of whatever context they're in inside the loop
body, and then make the appropriate transition to the next
iteration/the end of the loop.

A third solution is to have explicit keywords that can appear in the
loop body, such as #:break and #:continue, and which are transformed
to make the appropriate recursive call. This avoids both the
continuation capture and the potential strange behavior when called in
non-tail position.

A fourth solution, not currently implementable, would be to take
solution 1, plus a way of statically erroring when certain expressions
didn't appear in tail position wrt another expression.

I think 4 would be my preference, but of the other three I'm unsure.

Sam

On Fri, Jun 27, 2014 at 11:15 PM, Jay Kominek komi...@gmail.com wrote:
 I've been converting a bunch of Python to Racket lately, and I have a
 lot of loops that use break and continue. I end up turning them into:

 (let/ec break
   (for (...)
 (let/ec continue
   ; do some work
   (when this-iteration-isn't-what-i-want
 (continue))
   ; do more expensive work
   (when found-what-i-want
 (break what-i-want)

 I thought it would be nice if the let/ec's could be integrated with
 for, so that you could instead write:

 (for (#:ec break
...
#:ec continue)
   ; ...same as above...

 In an attempt to help convey the behavior I want, I threw this patch together:

 https://github.com/jkominek/racket/commit/b291a0b994c679445b3210bd3efba8c6cea867e4

 I feel it behaves reasonably when using for and for/fold, but for/list
 doesn't behave in any way I'd hope for.

 Ideally somebody who understands for's implementation will agree that
 this is a great idea, and go make it all work nicely. :) Failing that
 I'm open to suggestions for how to make it behave better, in a fashion
 which would make it appropriate for inclusion.

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


Re: [racket-dev] for loops with interleaved escape continuations

2014-07-01 Thread Sam Tobin-Hochstadt
I disagree strongly that this is un-rackety. Consider the following loop:

(define v )
(let loop ([i 100])
 (define e (vector-ref v i))
 (cond [(zero? i) null]
   [(= 999 e) null]
   [(even? e) (loop (add1 i))]
   [else (cons e (loop add1 i))]))

I don't think that's un-Rackety.

Here's that loop with break/continue:

(for/list ([i (in-range 100 0 -1)])
  (define e (vector-ref v i))
  (cond [(= 999 e) (break)]
   [(even? e) (continue)]
   [else e]))

I don't think that's un-Rackety either.

Sam

On Tue, Jul 1, 2014 at 10:59 PM, Neil Van Dyke n...@neilvandyke.org wrote:
 If adding breakcontinue features to your fancy iteration syntax, I propose
 that any uses of these features in source code be somehow very prominent.

 For example, perhaps there is a keyword that must be at the top of the fancy
 iteration form, something like
 #:enable-continue-here-because-programmer-cannot-be-bothered-to-write-this-in-idiomatic-racket.

 This prominence warns readers of the code to be on the lookout for surprise
 control flow (like they would on the rare occasion that they saw a call/ec
 around a loop).  It also hints to newbie programmers that they are
 discouraged from simply transliterating syntax from other languages (rather
 than learning better control flow and structuring techniques).

 Neil V.


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

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


Re: [racket-dev] for loops with interleaved escape continuations

2014-07-01 Thread Sam Tobin-Hochstadt
On Wed, Jul 2, 2014 at 12:52 AM, John Clements
cleme...@brinckerhoff.org wrote:

 On Jul 1, 2014, at 3:46 PM, Sam Tobin-Hochstadt sa...@cs.indiana.edu wrote:

 I disagree strongly that this is un-rackety. Consider the following loop:

 (define v )
 (let loop ([i 100])
 (define e (vector-ref v i))
 (cond [(zero? i) null]
   [(= 999 e) null]
   [(even? e) (loop (add1 i))]
   [else (cons e (loop add1 i))]))

 I don't think that's un-Rackety.

 Here's that loop with break/continue:

 (for/list ([i (in-range 100 0 -1)])
  (define e (vector-ref v i))
  (cond [(= 999 e) (break)]
   [(even? e) (continue)]
   [else e]))

 You don’t like the non-capturing alternative

 (for/list ([i (in-range 100 0 -1)]
#:continue continue
#:break break)
  (define e (vector-ref v i))
  (cond [(= 999 e) (break)]
   [(even? e) (continue)]
   [else e]))

 ?

Sorry, I meant to write the hygenic version that you provide.

Sam


 Sorry, I’m working on implementing hygiene for Rust right now, and I’m kind 
 of knee-jerk in favor of non-capturing….

 John


 I don't think that's un-Rackety either.

 Sam

 On Tue, Jul 1, 2014 at 10:59 PM, Neil Van Dyke n...@neilvandyke.org wrote:
 If adding breakcontinue features to your fancy iteration syntax, I propose
 that any uses of these features in source code be somehow very prominent.

 For example, perhaps there is a keyword that must be at the top of the fancy
 iteration form, something like
 #:enable-continue-here-because-programmer-cannot-be-bothered-to-write-this-in-idiomatic-racket.

 This prominence warns readers of the code to be on the lookout for surprise
 control flow (like they would on the rare occasion that they saw a call/ec
 around a loop).  It also hints to newbie programmers that they are
 discouraged from simply transliterating syntax from other languages (rather
 than learning better control flow and structuring techniques).

 Neil V.


 _
  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 #28945: master branch updated

2014-06-30 Thread Sam Tobin-Hochstadt
On Jun 30, 2014 3:34 PM, Robby Findler ro...@eecs.northwestern.edu
wrote:

 Thanks. When I look at the dvipdf-produced pdf in my pdf viewer, it
 looks good, but the other one does not.

 I see no difference in these screenshots or the pdf.js ones you sent,
 tho. And when I view the pdfs in pdf.js via their demo features, I see
 no difference.

 What latex distribution are you using?

This is TeX Live, I think 2013 with some modifications that Debian/Ubuntu
makes.

Sam

 Robby


 On Mon, Jun 30, 2014 at 6:50 AM, Sam Tobin-Hochstadt
 sa...@cs.indiana.edu wrote:
  Attached are the two pdfs (x1 is --pdf, x is --dvipdf) and the two
  screenshots in Evince, my usual PDF viewer.
 
  Sam
 
  On Sat, Jun 28, 2014 at 9:03 PM, Robby Findler
  ro...@eecs.northwestern.edu wrote:
  I'd like to see screenshots of the pdfs in whatever viewer you usually
  use, if you don't mind. Also: what latex distribution are you using?
 
  Robby
 
  On Sat, Jun 28, 2014 at 12:16 PM, Sam Tobin-Hochstadt
  sa...@cs.indiana.edu wrote:
  Attached is a screenshot from the diffpdf tool. You can see that the
  font rendering is different in a few places.
 
  You can also see that --dvipdf loses the rest of the document after
  the Redex pict -- I don't know what could cause that.
 
  Basically the same things happen on my other linux machine.
 
  Sam
 
  On Fri, Jun 27, 2014 at 9:18 PM, Robby Findler
  ro...@eecs.northwestern.edu wrote:
  PS: Sam, were you able to produce two pdfs (via scribble --dvipdf and
  --pdf) and compare their output on your machine? Do you have
  screenshots to share?
 
  Robby
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] help wanted: watch out for missing `@history[...]`

2014-06-30 Thread Sam Tobin-Hochstadt
On Mon, Jun 30, 2014 at 5:25 AM, Matthew Flatt mfl...@cs.utah.edu wrote:
 Similarly, I don't know how much it makes sense to document refinements
 to types in `typed/...` libraries (and I'll leave that question to the
 TR implementers).


I think we make a design choice to make a type stricter/less strict,
it's worth recording, but just changing to follow Racket changes or
where it didn't fit Racket shouldn't get history entries.

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


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

2014-06-27 Thread Sam Tobin-Hochstadt
On Fri, Jun 27, 2014 at 4:30 AM,  ro...@racket-lang.org wrote:


 5280395 Robby Findler ro...@racket-lang.org 2014-06-27 03:25
 :
 | add the --dvipdf flag to scribble
 |
 | This adds a new back-end pipeline for generating pdf to
 | scribble, with the hope that included picts (e.g., those
 | generated by Redex) will look better when viewed with
 | on-screen pdf viewers

Can you explain more about why this would work better? In particular,
there are lots of things that work better/only with pdflatex (fonts,
unicode, hyperlinks, etc) so I hope that there isn't some permanent
barrier to getting both nice-looking Redex picts and fancy latex
features.

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


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

2014-06-27 Thread Sam Tobin-Hochstadt
Is the program in the commit message what I should try to see the difference?

Sam

On Fri, Jun 27, 2014 at 8:57 AM, Robby Findler
ro...@eecs.northwestern.edu wrote:
 I can't explain, no. The pdfs don't actually seem to _be_ worse when
 printing, so this pathway just seems to encourage viewers somehow.

 But apparently if you have a retina mac, this flag isn't necessary.

 Robby

 On Fri, Jun 27, 2014 at 7:22 AM, Sam Tobin-Hochstadt
 sa...@cs.indiana.edu wrote:
 On Fri, Jun 27, 2014 at 4:30 AM,  ro...@racket-lang.org wrote:


 5280395 Robby Findler ro...@racket-lang.org 2014-06-27 03:25
 :
 | add the --dvipdf flag to scribble
 |
 | This adds a new back-end pipeline for generating pdf to
 | scribble, with the hope that included picts (e.g., those
 | generated by Redex) will look better when viewed with
 | on-screen pdf viewers

 Can you explain more about why this would work better? In particular,
 there are lots of things that work better/only with pdflatex (fonts,
 unicode, hyperlinks, etc) so I hope that there isn't some permanent
 barrier to getting both nice-looking Redex picts and fancy latex
 features.

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


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

2014-06-27 Thread Sam Tobin-Hochstadt
And the one with the second x in the bottom line lower down is the one
that's from --pdf and is not intended? Are there other differences
between the pictures?

Sam

On Fri, Jun 27, 2014 at 9:02 AM, Robby Findler
ro...@eecs.northwestern.edu wrote:
 On Fri, Jun 27, 2014 at 7:59 AM, Sam Tobin-Hochstadt
 sa...@cs.indiana.edu wrote:
 Is the program in the commit message what I should try to see the difference?

 It looks different for me, yes. I'm attaching two screenshots for the
 difference I see between --pdf and --dvipdf.

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


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

2014-06-27 Thread Sam Tobin-Hochstadt
I'm trying to determine how different they look on my machine, but
unfortunately the two processes put the lines at different places on
the page. Do you have an easy way to control that?

Sam

On Fri, Jun 27, 2014 at 10:47 AM, Robby Findler
ro...@eecs.northwestern.edu wrote:
 No, the lower-down aspect is actually something else. The x and the
 y in the sans serif font on that line and the big f on the line
 above are from picts. The other characters on those lines are directly
 written in the latex code. The grammar is also a pict. The picts look
 worse in one screen shot than the other (the one whose name has
 8.01.25 is the uglier one). This effect is, I believe, one of the
 main things people mean when they say that Redex's typesetting is ugly
 (and it is indeed ugly in larger quantities).

 Robby

 On Fri, Jun 27, 2014 at 9:23 AM, Sam Tobin-Hochstadt
 sa...@cs.indiana.edu wrote:
 And the one with the second x in the bottom line lower down is the one
 that's from --pdf and is not intended? Are there other differences
 between the pictures?

 Sam

 On Fri, Jun 27, 2014 at 9:02 AM, Robby Findler
 ro...@eecs.northwestern.edu wrote:
 On Fri, Jun 27, 2014 at 7:59 AM, Sam Tobin-Hochstadt
 sa...@cs.indiana.edu wrote:
 Is the program in the commit message what I should try to see the 
 difference?

 It looks different for me, yes. I'm attaching two screenshots for the
 difference I see between --pdf and --dvipdf.

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


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

2014-06-27 Thread Sam Tobin-Hochstadt
On Fri, Jun 27, 2014 at 11:45 AM, Matthew Flatt mfl...@cs.utah.edu wrote:
 I will push a repair for that soon.

 Just to clarify a little, `--pdf` files generated on Robby's machine
 look fine in Preview on my machine, and `--pdf` files generated on my
 machine look bad in Preview on Robby's machine. The machine dependence
 is in how the output is viewed, and not what is generated.

Is this to say that `--pdf` files always look bad on Robby's machine,
but ok on yours?

 For some reason, the way that PDF fragments are pulled in by `pdflatex`
 makes the fragments look worse in some PDF viewers/machines than the
 way that PS fragments are pulled in by `latex` plus `dvips`. I think it
 has to do with heuristics in PDF viewers, and I think there's no
 difference when going to a printer.

My impression was that PDF was supposed to be a pixel-accurate format,
at least when self-contained and not using system fonts, and thus
there wouldn't be any such heuristics. Is that not true?

Sam

 At Fri, 27 Jun 2014 11:30:06 -0400, Sam Tobin-Hochstadt wrote:
 I'm trying to determine how different they look on my machine, but
 unfortunately the two processes put the lines at different places on
 the page. Do you have an easy way to control that?

 Sam

 On Fri, Jun 27, 2014 at 10:47 AM, Robby Findler
 ro...@eecs.northwestern.edu wrote:
  No, the lower-down aspect is actually something else. The x and the
  y in the sans serif font on that line and the big f on the line
  above are from picts. The other characters on those lines are directly
  written in the latex code. The grammar is also a pict. The picts look
  worse in one screen shot than the other (the one whose name has
  8.01.25 is the uglier one). This effect is, I believe, one of the
  main things people mean when they say that Redex's typesetting is ugly
  (and it is indeed ugly in larger quantities).
 
  Robby
 
  On Fri, Jun 27, 2014 at 9:23 AM, Sam Tobin-Hochstadt
  sa...@cs.indiana.edu wrote:
  And the one with the second x in the bottom line lower down is the one
  that's from --pdf and is not intended? Are there other differences
  between the pictures?
 
  Sam
 
  On Fri, Jun 27, 2014 at 9:02 AM, Robby Findler
  ro...@eecs.northwestern.edu wrote:
  On Fri, Jun 27, 2014 at 7:59 AM, Sam Tobin-Hochstadt
  sa...@cs.indiana.edu wrote:
  Is the program in the commit message what I should try to see the
 difference?
 
  It looks different for me, yes. I'm attaching two screenshots for the
  difference I see between --pdf and --dvipdf.
 
  Robby
 _
   Racket Developers list:
   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


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

2014-06-27 Thread Sam Tobin-Hochstadt
On Fri, Jun 27, 2014 at 12:30 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
 At Fri, 27 Jun 2014 11:56:39 -0400, Sam Tobin-Hochstadt wrote:
 On Fri, Jun 27, 2014 at 11:45 AM, Matthew Flatt mfl...@cs.utah.edu wrote:
  For some reason, the way that PDF fragments are pulled in by `pdflatex`
  makes the fragments look worse in some PDF viewers/machines than the
  way that PS fragments are pulled in by `latex` plus `dvips`. I think it
  has to do with heuristics in PDF viewers, and I think there's no
  difference when going to a printer.

 My impression was that PDF was supposed to be a pixel-accurate format,
 at least when self-contained and not using system fonts, and thus
 there wouldn't be any such heuristics. Is that not true?

 PDF is a vector-graphics format, not a raster-graphics format (so it
 doesn't really say anything about pixels).

Right -- what I meant was that at a given size, rendering should be
pixel-accurate, so that you shouldn't see differences between
different viewers (unlike, say, HTML, which doesn't prescribe layout
nearly as precisely).

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


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

2014-06-27 Thread Sam Tobin-Hochstadt
On Fri, Jun 27, 2014 at 2:23 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
 At Fri, 27 Jun 2014 13:43:46 -0400, Sam Tobin-Hochstadt wrote:
 On Fri, Jun 27, 2014 at 12:30 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
  At Fri, 27 Jun 2014 11:56:39 -0400, Sam Tobin-Hochstadt wrote:
  On Fri, Jun 27, 2014 at 11:45 AM, Matthew Flatt mfl...@cs.utah.edu 
  wrote:
   For some reason, the way that PDF fragments are pulled in by `pdflatex`
   makes the fragments look worse in some PDF viewers/machines than the
   way that PS fragments are pulled in by `latex` plus `dvips`. I think it
   has to do with heuristics in PDF viewers, and I think there's no
   difference when going to a printer.
 
  My impression was that PDF was supposed to be a pixel-accurate format,
  at least when self-contained and not using system fonts, and thus
  there wouldn't be any such heuristics. Is that not true?
 
  PDF is a vector-graphics format, not a raster-graphics format (so it
  doesn't really say anything about pixels).

 Right -- what I meant was that at a given size, rendering should be
 pixel-accurate, so that you shouldn't see differences between
 different viewers (unlike, say, HTML, which doesn't prescribe layout
 nearly as precisely).

 Maybe the alignment problem (now fixed) in Robby's example obscured the
 issue. It's just about the smoothness of the rendering.

 That is, PDF specifies exactly where things should be on a cartesian
 plane, but renderers draw the same image with different pixels
 depending on the display resolution, how much time the renderer spends
 on anti-aliasing, and so on. The look worse part above was meant only
 about the appearance of shape edges, and not about shapes being in the
 wrong location.

In the particular `e ::= ...` example, this is an issue of font
rendering, right? IOW, the shapes being drawn differently between
dvipdf and pdflatex are fonts placed in particular spots on the page.

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


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

2014-06-26 Thread Sam Tobin-Hochstadt
Can we make this error message a little more informative? People find this
confusing.

Sam
On Jun 26, 2014 2:22 AM, as...@racket-lang.org wrote:

 asumu has updated `master' from 5339cbaac9 to 9a14c9c420.
   http://git.racket-lang.org/plt/5339cbaac9..9a14c9c420

 =[ One Commit ]=
 Directory summary:
   44.4% pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/typecheck/
   55.5%
 pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/unit-tests/

 ~~

 9a14c9c Asumu Takikawa as...@racket-lang.org 2014-06-26 01:35
 :
 | Fix error for application Procedure type values
 |
 | Removal of top-arr in the internal representation changed
 | the error message and we didn't have a test for it.
 |
 | Closes PR 14601
 :
   M .../tests/typed-racket/unit-tests/typecheck-tests.rkt| 7
 +++
   M .../typed-racket/typecheck/tc-app-helper.rkt | 3 ++-

 =[ Overall Diff ]===


 pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/typecheck/tc-app-helper.rkt

 
 ---
 OLD/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/typecheck/tc-app-helper.rkt
 +++
 NEW/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/typecheck/tc-app-helper.rkt
 @@ -105,7 +105,8 @@
(if tail-bound (cons tail-ty tail-bound) #f)))
(cond
  [(null? doms)
 - (int-err How could doms be null: ~a ty)]
 + (tc-error/expr cannot apply function of type Procedure
 +#:return return)]
  [(and (= 1 (length doms)) (not (car rests)) (not (car drests)) (not
 tail-ty) (not tail-bound))
   (tc-error/expr
#:return return


 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
 @@ -3106,6 +3106,13 @@
   ((if (even? 4) add1 (inst values Integer)) 4)
   -Int]

 +   ;; PR 14601
 +   [tc-err
 +(let ()
 +  (: f Procedure)
 +  (define f (lambda () 'hi))
 +  (f))
 +#:msg cannot apply function of type Procedure]
  )

(test-suite

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


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

2014-06-26 Thread Sam Tobin-Hochstadt
Yeah, that looks nicer.

On Thu, Jun 26, 2014 at 9:47 AM, Asumu Takikawa as...@ccs.neu.edu wrote:
 On 2014-06-26 07:30:40 -0400, Sam Tobin-Hochstadt wrote:
Can we make this error message a little more informative? People find this
confusing.

 Sure, did you have something in mind?

 Something like this?

   Type Checker: cannot apply a function with no known arities;
 Function `f` had type Procedure which cannot be applied

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


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

2014-06-23 Thread Sam Tobin-Hochstadt
On Mon, Jun 23, 2014 at 8:29 AM,  mfl...@racket-lang.org wrote:

 6a5a303 Matthew Flatt mfl...@racket-lang.org 2014-06-23 13:23:47 +0100
 :
 | avoid getting stuck on non-UTF-8 symbol encodings in bytecode
 |


Does this fix apply to keywords as well?

I assume that strings are handled differently.

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


Re: [racket-dev] Broken build?

2014-06-20 Thread Sam Tobin-Hochstadt
The current Travis build succeed https://travis-ci.org/plt/racket so I
think you probably have some stale compiled files somewhere.

Sam

On Fri, Jun 20, 2014 at 10:03 AM, J. Ian Johnson i...@ccs.neu.edu wrote:
 I just pulled and make gives me this

 libracket.a(optimize.o): In function `expr_implies_predicate':
 /home/ianj/racket/racket/src/build/racket/src/../../../racket/src/optimize.c:2353:
  undefined reference to `scheme_syntax_p_proc'
 libracket.a(optimize.o): In function `relevant_predicate':
 /home/ianj/racket/racket/src/build/racket/src/../../../racket/src/optimize.c:3539:
  undefined reference to `scheme_syntax_p_proc'
 libracket.a(validate.o): In function `is_functional_rator':
 /home/ianj/racket/racket/src/build/racket/src/../../../racket/src/validate.c:1235:
  undefined reference to `scheme_is_functional_primitive'
 collect2: error: ld returned 1 exit status

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


Re: [racket-dev] Machinery for eliding contracts

2014-06-13 Thread Sam Tobin-Hochstadt
Yes, I think this would allow all the optimizations that Eric talked about.

Sam
On Jun 13, 2014 4:26 AM, Robby Findler ro...@eecs.northwestern.edu
wrote:

 Would it be useful to get blame information back from a value, just
 like you can currently get the contract back?

 Robby

 On Tue, Jun 10, 2014 at 11:53 AM, Matthias Felleisen
 matth...@ccs.neu.edu wrote:
 
  I was thinking of associating the contract with the type from which it
 comes and no that's not hash-consing. And if it's slower, too bad. --
 Matthias
 
 
 
 
 
  On Jun 10, 2014, at 12:47 PM, Eric Dobson eric.n.dob...@gmail.com
 wrote:
 
  On Tue, Jun 10, 2014 at 6:15 AM, Matthias Felleisen
  matth...@ccs.neu.edu wrote:
 
  On Jun 9, 2014, at 6:02 PM, Eric Dobson eric.n.dob...@gmail.com
 wrote:
 
 
  Eric, are you talking about changing the proxy values that wrap
 HO/mutable
  contracted values?
  Yes. I want the proxy values to include information about who agreed
  to the contract in addition to the contract agreed to.
 
  I actually realize that I might need more than just the contract
  agreed to because of how TR changes the generated contract to remove
  checks for what it guarantees, so that info is not in the contract.
  But I believe that can be added back as a structure property on the
  contract.
 
 
  Would some form of hash-consing contracts work here? -- Matthias
 
 
  I don't think so. But not sure exactly what you are proposing.
 
  The issue is that there are 4 contracts here and 2 of them currently
  do not exist at runtime. The 4 are TRs checks/promises on an
  export/import. (Using import for a value flowing into an exported
  function). The promise contracts do not currently exist as removing
  them was my previous optimization (They never fail). What I want to do
  is change the check on import from (array/c symbol?) to (if/c
  (protected? (array/c symbol?)) any/c (array/c symbol?)). Where
  (protected? x/c) checks if TR already promised something stronger
  than x/c.
 
  I believe that you are proposing that we can use the identity of the
  contract returned by value-contract to determine what the promised
  contract would have been. This does not work as (Array Symbol) and
  (Array Float) both get translated to (array/c any/c) for export, and
  we would want to lookup different promised contracts for them. We
  could use weak hash map as an extra field but that seems like it would
  be slow.
 
 
  _
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] Machinery for eliding contracts

2014-06-09 Thread Sam Tobin-Hochstadt
On Mon, Jun 9, 2014 at 5:48 AM, Robby Findler
ro...@eecs.northwestern.edu wrote:
 Am I right that the contract on 'f' is actually (- symbol? any)? And
 if so, where is the information coming from that lets you elide the
 check?

No, the `(boxof symbol?)` contract has to be kept around because of mutability.

 One idea for this particular case: make 'g' be a macro that inspects
 its argument and if it see obvious things like this, then it can
 expand into a call to an unprotected use of 'g' instead of the
 protected one. I'm not sure how general this would be, tho, but it has
 two advantages: a) it can be done at compile time and b) it doesn't
 need to deal with arbitrary contracts, only the ones generated by
 types. Does that approach seem to have enough merit?

I don't understand how this is supposed to work. If `g` was a macro,
how would it know that `f` was something it could specialize on? Would
every TR export also have some static information about its contract
so that macros like `g` could recognize them?

Sam


 Robby

 On Mon, Jun 9, 2014 at 2:19 AM, Eric Dobson eric.n.dob...@gmail.com wrote:
 One of the slowest parts when using TR is the contract boundary
 between untyped and typed code. Even with recent changes it still
 causes a large overhead.

 Example:
 #lang racket/load

 (module lib typed/racket
   (provide f g)
   (: f (Symbol - (Boxof Symbol)))
   (define (f x) (box x))
   (: g ((Boxof Symbol) - Symbol))
   (define (g x) (unbox x)))

 (module user-1 racket
   (provide go1)
   (require 'lib)
   (define (go1)
 (for ((i (in-range 20)))
   (g (f 'x)

 (module user-2 typed/racket
   (provide go2)
   (require 'lib)
   (define (go2)
 (for ((i (in-range 1)))
   (g (f 'x)

 (require 'user-1 'user-2)

 (for ((j 5))
   (time (go1))
   (time (go2)))


 It would be nice if the contract on the input to g could be elided. It
 seems like this could be done by using something like prop:contracted
 but that allowed accessing the parties that agreed to the contract.

 I'm imagining something like
 (lambda (v) (and (has-contract? v) (contracted-value-providing-side=?
 v 'the-typed-world) (contract-stronger? (value-contract v)
 new-contract)))

 One issue I see is that we need an unforgeable property that the value
 actually came from the typed world so we know that eliding the new
 contract is safe.

 Does this seem like a reasonable thing to support/do people see issues with 
 it?

 Other related ideas I had were:

 A similar thing could be done if the same contract were being applied
 multiple times with the same blame parties. In that case the later
 contracts could be elided because they would error out in exactly the
 same cases with exactly the same messages.

 That in addition to not applying the new contract if it is weaker than
 the old contract, we remove the old contract (and access the
 unprotected value) if the new contract is stronger. In the case that
 they were the same contract this would mean that there would be no
 higher order contract checks while the typed code was executing.
 _
   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] Machinery for eliding contracts

2014-06-09 Thread Sam Tobin-Hochstadt
On Mon, Jun 9, 2014 at 3:19 AM, Eric Dobson eric.n.dob...@gmail.com wrote:

 It would be nice if the contract on the input to g could be elided. It
 seems like this could be done by using something like prop:contracted
 but that allowed accessing the parties that agreed to the contract.

 I'm imagining something like
 (lambda (v) (and (has-contract? v) (contracted-value-providing-side=?
 v 'the-typed-world) (contract-stronger? (value-contract v)
 new-contract)))

 One issue I see is that we need an unforgeable property that the value
 actually came from the typed world so we know that eliding the new
 contract is safe.

 Does this seem like a reasonable thing to support/do people see issues with 
 it?

It seems like this could be simplified a little just by allowing
contract parties to be compared.  IOW, at the point where you're
writing that function, we have two contracts, and we need to know if
the negative party of one is the positive party of the other.  Then
you don't need to worry about unforgeability, I think.

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


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

2014-05-28 Thread Sam Tobin-Hochstadt
On Thu, May 29, 2014 at 4:26 AM,  mfl...@racket-lang.org wrote:

 | optimizer: ad hoc optimization of predicates applied to constructions
 |
 | This is probably more of a job for Typed Racket, but maybe it's
 | useful to detect some obviously unnecessary allocations of lists, etc.

I think this is a useful discussion to have. I think there are two
questions to answer:

1. Do we want people to need to use a particular language for greater
optimization, whether that's Typed Racket or some other optimizer?

2. How should we optimize the code that Typed Racket depends on?
Since this is a finite amount, we could manually do this, but we might
not want to.

Of course, in the absence of other constraints, it would be great to
have infinite optimizations at every level. But in our actual setting,
I don't know what I think the answer to either of these questions is.

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


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

2014-05-26 Thread Sam Tobin-Hochstadt
On Sat, May 24, 2014 at 8:02 AM, Jay McCarthy jay.mccar...@gmail.com wrote:

 On May 23, 2014, at 3:59 PM, Greg Hendershott greghendersh...@gmail.com 
 wrote:

 Feedback from a relatively naive Racket user:

 1.

 +External effects are exemplified by input/output (or I/O). I/O is the
 +action of a function such as @racket[tcp-connect], which communicates
 +with the operating system to send network packets outside of the
 +machine running Racket via the electromagnetic spectrum.

 It might be OK to omit via the electromagnetic spectrum. Yes I'm
 aware of RFC 1149. But still.  :)


 Yes, maybe it's too cute. I really wanted to emphasize its irreversibility.

I think emphasizing the irreversibility is a good idea, but the
document should just say that directly, instead of being cute like
this.

 2.

 +In particular, if module A is shared by the phase 1 portion of modules
 +X and Y, then any internal effects while X is compiled are not visible
 +during the compilation of Y, regardless of whether X and Y are
 +compiled during the same Racket runtime system.

 Was system supposed to be session?


 No. Each time you start Racket you get a NEW rts.

I think this terminology is going to confuse people. What about
during the same execution of Racket's runtime system?

 3. The practical example goes some way toward explaining why this
 matters. But only part way (for me). Probably some real-life situation
 motivated this. Knowing that backstory might help. (If you think that
 tale doesn't fit and/or belong in the reference docs, maybe it would
 make a great blog post?)

 Yes. One of Matthew's papers has some good examples.

In particular, Composable and Compilable Macros, ICFP 2002, and
Advanced Macrology and the implementation of Typed Scheme, Scheme
Workshop 2007.

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


Re: [racket-dev] Easy disassembly of JIT-compiled procedures

2014-05-25 Thread Sam Tobin-Hochstadt
On Sat, May 24, 2014 at 5:53 AM, Greg Hendershott
greghendersh...@gmail.com wrote:
 Testing of the new code (which is on by default) on platforms other
 than x86-64 Linux would be greatly appreciated.

 I tried and it works great on OS X, for untyped Racket.


 As for Typed Racket, I tried:

[something totally reasonable]

Unfortunately, I think that making disassembly for contracted
functions work would be both tricky, and not as helpful as you'd want,
since showing the behavior of the contract at the JIT level is not
trivial.  So for the moment, I think this is just not going to work.

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


Re: [racket-dev] Easy disassembly of JIT-compiled procedures

2014-05-23 Thread Sam Tobin-Hochstadt
Yes, as it says in the README, it requires a very recent version of
Racket. I should add that version requirement to the info file, but I
had forgotten the syntax when I was editing the file.

Sam

On Fri, May 23, 2014 at 2:02 PM, Roman Klochkov kalimeh...@mail.ru wrote:
 And now it is broken in 6.0.1

 (require disassemble)
 . . ..\..\..\..\Program Files\Racket\collects\ffi\unsafe.rkt:198:2: ffi-obj:
 couldn't get scheme_jit_find_code_end from #f

 I installed it from pkgs.racket-lang.org
 Maybe should be something like #ifdef or depend on another version of Racket
 (now it depends upon Racket6.0.0.4)

 Wed, 21 May 2014 19:50:05 -0400 от Sam Tobin-Hochstadt
 sa...@cs.indiana.edu:

 On Wed, May 21, 2014 at 6:12 PM, Neil Toronto neil.toro...@gmail.com
 wrote:
 On 05/21/2014 02:09 PM, Sam Tobin-Hochstadt wrote:

 Racketeers,

 Thanks to some improvements from Matthew, my `disassemble` package is
 now much easier to use.

 [samth@punge:~/sw/disassemble (master) plt] racket
 Welcome to Racket v6.0.1.10.

 (require disassemble)
 (define (const x) 1)
 (disassemble const)

  8943FC mov [ebx-0x4],eax
 0003 83C3FC add ebx,byte -0x4
 0006 B80300 mov eax,0x3
 000B 83C41C add esp,byte +0x1c
 000E 5F pop edi
 000F 5E pop esi
 0010 5B pop ebx
 0011 5D pop ebp
 0012 C3 ret



 That's crazy awesome. What were the improvements?

 First, Racket now tells you the end of the machine code for a jitted
 procedure with `scheme_jit_find_code_end` (so messing about with
 guessing the size is no longer needed) and it also can JIT on-demand
 (so you don't have to call a function before disassembling it) with
 `scheme_jit_now`.

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



 --
 Roman Klochkov

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


Re: [racket-dev] Easy disassembly of JIT-compiled procedures

2014-05-22 Thread Sam Tobin-Hochstadt
On Wed, May 21, 2014 at 4:09 PM, Sam Tobin-Hochstadt
sa...@cs.indiana.edu wrote:
 Racketeers,

 Thanks to some improvements from Matthew, my `disassemble` package is
 now much easier to use.

I've just pushed a new version of this, which uses an in-Racket
disassembler based on Göran Weinholt's Industria library [1].

This means (a) you don't need NASM installed and (b) it will work
properly on 64-bit OS X, despite the problems with NASM on that
platform.

Testing of the new code (which is on by default) on platforms other
than x86-64 Linux would be greatly appreciated.

Here's a sample of the revised output:

 (disassemble f)
   0: 488943f8   (mov (mem64+ rbx #x-8) rax)
   4: 4883c3f8   (add rbx #xfff8)
   8: b80300 (mov eax #x3)
   d: 4c8b75c8   (mov r14 (mem64+ rbp #x-38))
  11: 4883c428   (add rsp #x28)
  15: 415d   (pop r13)
  17: 415c   (pop r12)
  19: 5b (pop rbx)
  1a: 5d (pop rbp)
  1b: c3 (ret)

Sam

[1] https://github.com/weinholt/industria

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


[racket-dev] Easy disassembly of JIT-compiled procedures

2014-05-21 Thread Sam Tobin-Hochstadt
Racketeers,

Thanks to some improvements from Matthew, my `disassemble` package is
now much easier to use.

[samth@punge:~/sw/disassemble (master) plt] racket
Welcome to Racket v6.0.1.10.
 (require disassemble)
 (define (const x) 1)
 (disassemble const)
  8943FCmov [ebx-0x4],eax
0003  83C3FCadd ebx,byte -0x4
0006  B80300mov eax,0x3
000B  83C41Cadd esp,byte +0x1c
000E  5Fpop edi
000F  5Epop esi
0010  5Bpop ebx
0011  5Dpop ebp
0012  C3ret


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


Re: [racket-dev] Easy disassembly of JIT-compiled procedures

2014-05-21 Thread Sam Tobin-Hochstadt
On Wed, May 21, 2014 at 6:12 PM, Neil Toronto neil.toro...@gmail.com wrote:
 On 05/21/2014 02:09 PM, Sam Tobin-Hochstadt wrote:

 Racketeers,

 Thanks to some improvements from Matthew, my `disassemble` package is
 now much easier to use.

 [samth@punge:~/sw/disassemble (master) plt] racket
 Welcome to Racket v6.0.1.10.

 (require disassemble)
 (define (const x) 1)
 (disassemble const)

   8943FCmov [ebx-0x4],eax
 0003  83C3FCadd ebx,byte -0x4
 0006  B80300mov eax,0x3
 000B  83C41Cadd esp,byte +0x1c
 000E  5Fpop edi
 000F  5Epop esi
 0010  5Bpop ebx
 0011  5Dpop ebp
 0012  C3ret



 That's crazy awesome. What were the improvements?

First, Racket now tells you the end of the machine code for a jitted
procedure with `scheme_jit_find_code_end` (so messing about with
guessing the size is no longer needed) and it also can JIT on-demand
(so you don't have to call a function before disassembling it) with
`scheme_jit_now`.

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


[racket-dev] Determining if a resolved module path is a real module name

2014-05-16 Thread Sam Tobin-Hochstadt
Sometimes, `resolved-module-path-name` produces the symbol '|expanded
module|. Is this the only symbol that's produced that _isn't_ the
actual name of a module?

Also, given that I'm calling `expand` on a module form, is it possible
to do something so that I _don't_ end up with '|expanded module| as
the name?

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


Re: [racket-dev] Determining if a resolved module path is a real module name

2014-05-16 Thread Sam Tobin-Hochstadt
On Fri, May 16, 2014 at 10:23 AM, Matthew Flatt mfl...@cs.utah.edu wrote:
 The result of `expand` does not keep track of it source. You may want
 to use `resolve-module-path-index` from `syntax/modresolve`, providing
 the original module path as the second argument. The
 `resolve-module-path-index` function detects the self module path
 index (which is giving you '|expanded module|) and uses the second
 argument in its place.

Ok, thanks.

I'd actually prefer to know that a particular identifier is a
reference to the current module, so if '|expanded module| is only
(and always) produced for this case, that's plenty for me.

Sam


 At Fri, 16 May 2014 09:58:12 -0400, Sam Tobin-Hochstadt wrote:
 Sometimes, `resolved-module-path-name` produces the symbol '|expanded
 module|. Is this the only symbol that's produced that _isn't_ the
 actual name of a module?

 Also, given that I'm calling `expand` on a module form, is it possible
 to do something so that I _don't_ end up with '|expanded module| as
 the name?

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


[racket-dev] Travis now providing CI testing for Racket on Mac OS X

2014-05-14 Thread Sam Tobin-Hochstadt
Travis, the free CI system that we're using in addition to DrDr, is
now available on Macs, and I've turned that on for Racket.  You can
see the first results (sadly featuring a transient error) here:
https://travis-ci.org/plt/racket/builds/25168300

This now happens on every push, so we should be able to catch more
cross-platform issues quickly.

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


  1   2   3   4   5   6   7   8   >