Re: [racket-dev] [racket/web-server] 1c6411: Removing out-dated WebSocket implementation
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
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
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
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
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
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
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
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
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
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
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
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
-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?
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
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
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
#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
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
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] Package build information
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
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?
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
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
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
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
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
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?
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
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
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
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
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
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?
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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)
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
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] accessing @deftech terms in the reference from the guide
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
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?
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
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
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
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
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
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
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.
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
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?)
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?)
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?)
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
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?
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?
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
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
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
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
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
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
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
-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
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
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
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?
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
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
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
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?
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
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
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?
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
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
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
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
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
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
Re: [racket-dev] experience using the `pkg` branch
On Fri, Jun 14, 2013 at 8:40 AM, Carl Eastlund c...@ccs.neu.edu wrote: Jay, Thanks for the detailed summary. Right now I think the biggest missing piece of information when something goes wrong is which packages were affected?. If I download package A, and it pulls in B and C, and they pull in D, E, and F, and then somewhere along the lines raco setup fails, I now have six packages installed, and no clear idea which ones are working fine and which ones need to be fixed. If raco pkg could communicate with raco setup in some way to associate files that failed with the packages they came from, it would be very useful at the end to get a report like: raco pkg successfully installed packages B, E, and F; raco setup reports errors with the installation of A, C, and D. That or a raco pkg status command to look up similar information. Otherwise the user is left to track down the dependencies responsible for errors themselves, which can very time consuming when each step of the search involves running raco setup on some new subset of packages. One of my vices is thinking of the simplest way to do something and not the best for the user. One really simple way to do this is to make it so that rather than running one 'raco setup' after a whole bunch of package activity, it does many and can say what happened after each one. This is more like Planet. I think it would be slightly slower. Another idea is to make it so that 'raco setup' can have a mode where it passes error structures back that contain the paths (so 'raco pkg' knows where they are and which package directory it was) rather than just printing error messages. I'm not sure how 'raco setup' is internally organized enough to know if that is feasible. I'm sure this extra scrutiny and criticism for the package system isn't easy, so let me take this moment to also say -- thanks so much for writing the package system! It wouldn't be worth all this nitpicking if it weren't a great system; we've come a long way from distributing source code via .plt files, to having something worth using to bundle up our core software. Carl Eastlund On Fri, Jun 14, 2013 at 10:13 AM, Jay McCarthy jay.mccar...@gmail.com wrote: I'll try to respond to these four messages at the same time... Sam said, In addition to the larger point Robby makes, this can be pretty confusing. For example, you can fail to install enough dependencies, I think. Another problem is that there's no way to know what to do to fix things. Say there's an error in `raco setup` that's transient (the machine lost power, for example). What command do I run to 'fix' the setup? I don't even know what collections were being installed. On Thu, Jun 13, 2013 at 9:27 PM, Robby Findler ro...@eecs.northwestern.edu wrote: I know it runs it. I don't know why Jay writes 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.. I can't tell if there's some technical piece I'm missing or not (on the surface, these words sound almost lazy but I *KNOW* Jay is anything but lazy!) Robby On Thu, Jun 13, 2013 at 10:21 PM, Carl Eastlund c...@ccs.neu.edu wrote: It does run 'raco setup', it just doesn't have much to do in response to a failure, at least right now. Carl Eastlund On Thu, Jun 13, 2013 at 11:14 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Also, Jay: can you explain more why 'raco setup' isn't something that we should think about as running inside the pkg manager? (I'm not saying that automatically rolling back packages is the right thing to do or anything like that, but I would like to understand the model you have better.) Short: I interpret these messages to be saying, raco pkg printed error messages and didn't say what was wrong or what I should do about it. The messages came from 'raco setup', of course, and 'raco pkg' gave no interpretation. As a simple first step, we can have 'raco pkg' observe the output of 'raco setup' (which might require changing it) and if it gives any error message of any kind, end with a message like: raco pkg detected strange output during setup. This could mean there was a problem. If you would like to undo this command, run: raco pkg remove the-package-you-installed This sounds like a simple to change to make, but there's one big problem. After 'raco pkg update' runs, the undo command is much more complicated and scary in its own way raco pkg remove --force the-package-you-updated raco pkg install the-source-for-the-package-you-updated-at-the-old-git-commit But some package sources may not be possible to get back, such as an old tar ball that you downloaded and don't have any more. When raco pkg update runs normally, it leaves the old files in place until the end and then deletes them. It could put these into some sort of 'archive' location to facilitate
Re: [racket-dev] experience using the `pkg` branch
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 -- 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
