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 wrote: > How does this fit with backward compatibility? > > Sam > > On Wed, Jan 14, 2015 at 2:26 PM, Jay McCarthy > 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 > > 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." - D&C 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 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." - D&C 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 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." - D&C 64:33 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Multiple 'raco make' processes
Specifically, you can get errors like "Called export 72 and expected set->list but got list->set. Chaos!" Jay On Tue, Dec 9, 2014 at 3:09 PM, Matthew Flatt wrote: > Unfortunately, the bytecode compiler is not completely deterministic. > Generating the same ".zo" file from the same source is likely to > produce different bytes each time. The root causes are various counters > and hash orders, and I hope to fix that eventually. For now, since the > generated bytecode is different, there can be inconsistencies instead > of just duplicated work. > > At Tue, 9 Dec 2014 11:54:16 -0800, Dan Liebgold wrote: >> If the multiple 'raco make's would produce the same results, then there >> should be no inconsistency, just duplicate work, right? >> >> And my use case is a bit different... I need to spawn the multiple 'raco >> makes', rather than have raco make spawn multiple racket instances (via the >> -j flag). Although this particular setup will bear some examination. >> >> On Tue, Dec 9, 2014 at 11:47 AM, Robby Findler >> wrote: >> >> > Ah sorry: meant to add: did you try the -j flag? >> > >> > >> > On Tuesday, December 9, 2014, Robby Findler >> > wrote: >> > >> >> I think they can stomp on each other and you can get inconsistent >> >> results, theoretically. >> >> >> >> Robby >> >> >> >> On Tuesday, December 9, 2014, Dan Liebgold >> >> wrote: >> >> >> >>> If I have multiple instances of raco make running and some of the files >> >>> they are checking/rebuilding are shared across the instances... what >> >>> happens? Does raco make have lock to ensure no contention? Or does each >> >>> process potentially redo some work? >> >>> >> >>> -- >> >>> Dan Liebgold[dan.liebg...@gmail.com] >> >>> >> >> >> >> >> -- >> Dan Liebgold[dan.liebg...@gmail.com] >> _ >> 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." - D&C 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 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 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 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 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." - D&C 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 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 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." >> - D&C 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." - D&C 64:33 _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] DrDr & the split repository
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." - D&C 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 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." - D&C 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 wrote: > > Jay McCarthy wrote on 11/30/2014 12:30 PM: >> >> On Sunday, November 30, 2014, Neil Van Dyke > <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." - D&C 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 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 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." > - D&C 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." - D&C 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 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." - D&C 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 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." - D&C 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 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." - D&C 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 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." - D&C 64:33 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #29418: master branch updated
_WEAK_BOX_VAL(sub_cont->meta_continuation_src)
> + != p->meta_continuation))) {
> sub_cont = NULL;
>}
>if (sub_cont && (sub_cont->ss.cont_mark_pos == MZ_CONT_MARK_POS)) {
> @@ -5777,35 +5791,18 @@ internal_call_cc (int argc, Scheme_Object *argv[])
>/* Just use this one. */
>cont = sub_cont;
> } else {
> - /* Only continuation marks can be different. Mostly just re-use
> sub_cont. */
> - intptr_t offset;
> - Scheme_Cont_Mark *msaved;
> - Scheme_Cont_Jmp *buf_ptr;
> -
> - cont = MALLOC_ONE_TAGGED(Scheme_Cont);
> - cont->so.type = scheme_cont_type;
> -
> - buf_ptr = MALLOC_ONE_RT(Scheme_Cont_Jmp);
> - SET_REQUIRED_TAG(buf_ptr->type = scheme_rt_cont_jmp);
> - cont->buf_ptr = buf_ptr;
> -
> - cont->buf_ptr->buf.cont = sub_cont;
> - cont->escape_cont = sub_cont->escape_cont;
> -
> - sub_cont = sub_cont->buf_ptr->buf.cont;
> -
> - /* This mark stack won't be restored, but it may be
> + /* Only continuation marks can be different. Mostly just re-use
> sub_cont.
> + The mark stack won't be restored, but it may be
> used by `continuation-marks'. */
> - cont->ss.cont_mark_stack = MZ_CONT_MARK_STACK;
> - msaved = copy_out_mark_stack(p, cont->ss.cont_mark_stack, sub_cont,
> &offset, NULL, 0);
> - cont->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."
- D&C 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 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." - D&C 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 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." - D&C 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 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." - D&C 64:33 _ Racket Developers list: http://lists.racket-lang.org/dev
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 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 > 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 >> 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 >> > 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 >>
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 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 > 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
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 wrote: > If I do a (require (file )) 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." - D&C 64:33 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Pre-Release Checklist for v6.1.1
On Thu, Oct 16, 2014 at 9:13 AM, Ryan Culpepper wrote: > * Jay McCarthy > - Web Server Tests > - XML Tests > - HTML Tests > - PLAI Tests > - Racklog tests > - Datalog tests All passed -- 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." - D&C 64:33 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] pkgs.racket-lang.org
On Fri, Sep 26, 2014 at 7:26 PM, Jan Dvořák wrote: > Hi, > > about the <http://pkgs.racket-lang.org/> - the site is getting rather large. > Wouldn't server-side filtering work better than the client javascript > solution? You are finding it slow? > Plus I often have trouble submitting new packages, the form could easily be > done in the traditional way and the experience would be much better. Adding > a package would be an atomic operating, unlike the current situation where I > have to fill out some fields three times before they register correctly. What do you mean by that? You should only have to fill out a field one time correctly. If you're saying that you add one field and it doesn't work, then there's a problem. As far as making it one operation, that's something I may do shortly. Jay > [Firefox on Fedora 20, x86_64] > > Best regards, > Jan Dvorak > > > > _________ > Racket Developers list: > http://lists.racket-lang.org/dev -- Jay McCarthy http://jeapostrophe.github.io "Wherefore, be not weary in well-doing, for ye are laying the foundation of a great work. And out of small things proceedeth that which is great." - D&C 64:33 _ Racket Developers list: http://lists.racket-lang.org/dev
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 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." - D&C 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." - D&C 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=en&authuser=0&user=DFJca0EJ But it hasn't yet been integrated well enough Jay On Thu, Sep 4, 2014 at 1:44 PM, Antti Karttunen wrote: > On Thu, Sep 4, 2014 at 7:00 PM, wrote: > >> Message: 6 >> Date: Thu, 4 Sep 2014 11:35:32 -0400 >> From: Philippe Meunier >> 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." - D&C 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." - D&C 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 wrote: > On Wed, Sep 3, 2014 at 10:53 AM, Jay McCarthy 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." - D&C 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 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." - D&C 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, 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 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 "+") > - (define len (length d)) > - (define pkg-name (path-element->string (list-ref p len))) > - (if (regexp-match? #rx"pkgs[.]rktd" pkg-name) > - (values #f #f #f) ; don't count the database as a package > - (values (if (regexp-match? #rx"[+]" pkg-name) ; + 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 ,sco
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 wrote: > On Tue, Jul 8, 2014 at 8:14 AM, Matthew Flatt 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." - D&C 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 wrote: > I've tried both now. No go. > -Ian > - Original Message - > From: "Leif Andersen" > To: "J. Ian Johnson" > Cc: "dev" > 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 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." - D&C 64:33 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Pre-Release Checklist for v6.1
On Thu, Jul 17, 2014 at 8:03 PM, Ryan Culpepper wrote:
> Checklist items for the v6.1 release
> (using the v6.0.900.900 release candidate build)
>
> Search for your name to find relevant items, reply when you finish an
> item (please indicate which item/s is/are done). Also, if you have any
> commits that should have been picked, make sure that the changes are in.
>
> Important: new builds are created without announcement, usually whenever
> I pick a few commits. If you need to commit changes, please make sure
> you tell me to pick it into the release branch.
>
> --> Release candidates are at
> --> http://pre-release.racket-lang.org
>
> Please use these installers (or source bundles) -- don't test from
> your own git clone (don't test the `master' branch by mistake!). To
> get the tests, you can do this:
>
> cd ...racket-root...
> ./bin/raco pkg install -i main-distribution-test
>
> --
>
> * Matthew Flatt
> - Racket Tests
> - Languages Tests
> - GRacket Tests (Also check that `gracket -z' and `gracket-text' still
> works in Windows and Mac OS X)
> - mzc --exe tests
> - .plt-packing Tests
> - Games Tests
> - Unit Tests
> - Syntax Color Tests
> - R6RS Tests
> - JPR's test suite
> - Create an executable from a BSL program
> - Run COM tests
> - Embed-in-c test
> - Try compiling with -funsigned-char
> - Try compiling with TEST_ALTERNATE_TARGET_REGISTER
> Updates:
> - Racket Updates: update HISTORY
> (updates should show v6.1 as the most current version)
> - Update man pages in racket/man/man1: racket.1, gracket.1, raco.1
> Email me to pick the changes when they're done, or tell me if there
> are no such changes.
>
> * Robby Findler
> - DrRacket Tests
> - Framework Tests
> - Contracts Tests
> - Games Tests
> - Teachpacks Tests: image tests
> - PLaneT Tests
> - Redex Tests
> Updates:
> - DrRacket Updates: update HISTORY
> - Redex Updates: update HISTORY
> (updates should show v6.1 as the most current version)
> - Ensure that previous version of DrRacket's preference files still
> starts up with new DrRacket
> - Update man pages in racket/man/man1: drracket.1
> Email me to pick the changes when they're done, or tell me if there
> are no such changes.
>
> * John Clements
> - Stepper Tests
> Updates:
> - Stepper Updates: update HISTORY
> (updates should show v6.1 as the most current version; email me
> to pick the changes when they're done, or tell me if there are no such
> changes.)
>
> * Sam Tobin-Hochstadt ,
>Vincent St-Amour
> - Match Tests
> - Typed Racket Tests
> - Typed Racket Updates: update HISTORY
> (updates should show v6.1 as the most current version; email me
> to pick the changes when they're done, or tell me if there are no such
> changes.)
>
> * Matthias Felleisen
> - Teachpacks Tests: check that new teachpacks are addable
> - Teachpack Docs: check teachpack docs in the bundles
> - Try teaching-languages testing framework (check-expect)
> Updates:
> - Teachpack Updates: update HISTORY
> (updates should show v6.1 as the most current version; email me
> to pick the changes when they're done, or tell me if there are no such
> changes.)
>
> * Ryan Culpepper
> - Macro Debugger Tests
> - syntax-parse Tests
> - RackUnit GUI Tests
> - Data Tests
> - DB Tests
> - Rackunit Tests
> - SRFI Tests
>
> * Jay McCarthy
> - Web Server Tests
> - XML Tests
> - HTML Tests
> - PLAI Tests
> - Racklog tests
> - Datalog tests
All passed
> * Stevie Strickland
> - Unit Contract Tests
> - Contract Region Tests
> - Class Contract Tests
>
> * Stephen Chang
> - Lazy Racket Tests
> - Lazy stepper tests
>
> * Eli Barzilay
> - Swindle Tests
> - XREPL Tests
> - Verify PL language
> - Racket Tree: compare new distribution tree to previous one
> - Run the unix installer tests
> - Run zsh completions tests
> (". .../racket-completion.zsh; _racket --self-test")
>
> * Stephen Bloch
> - Picturing Programs Tests
>
> * Greg Cooper
> - FrTime Tests
>
> * Jon Rafkind
> Release tests for (one of the) linux releases:
> - Test that the `racket' and `racket-textual' source releases
> compile fine (note that they're still called `plt' and `mz' at
> this stage).
> - Test that the binary installers for both work, try each one in
> both normal and unix-st
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 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 > units&signatures (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." - D&C 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 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 > 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." > - D&C 64:33 -- Jay McCarthy 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." - D&C 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 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." - D&C 64:33 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28829: master branch updated
Ok. I thought about what kinds of things might be different in the
future with more understanding and experience using assertions...
How about this: Start an assert library with two exports,
assert/higher-order and assert. Your research suggests that contracts
are the only meaningful higher-order assertions, so this thing is
assert/higher-order and the contract DSL is the right way to specify
the condition. On the other hand, assert would be like the traditional
one that using expressions. Another name for a/ho would be
assert/contract which might be useful for using contracts for flat
values. (The name though, only communicates mechanism and not the
purpose like h-o.)
Jay
On Sun, Jun 1, 2014 at 6:14 PM, Robby Findler
wrote:
> (I must have missed that suggestion, sorry.)
>
> I don't object to the sentiment behind the name, but I feel like we
> have not figured out the best way to do assertions or invariants and
> so we should leave such a valuable name for a future
> contributor/insight and use the more "ugly" name for this one.
>
> Even if that name ends up in a different library, I wouldn't want an
> assertion/invariant library to conflict with racket/contract.
>
> Robby
>
>
> On Sun, Jun 1, 2014 at 6:57 PM, Matthias Felleisen
> wrote:
>>
>> I suggested exactly that name in a private message to Robby.
>>
>>
>>
>> On Jun 1, 2014, at 7:49 PM, Jay McCarthy wrote:
>>
>>> Based on this commit, I feel like "assert" would be a better name than
>>> "invariant-assertion". I can imagine putting these on various internal
>>> parts of a function where the self-blame would be justified. The
>>> (define id (assert ctc e)) pattern is just one common use.
>>>
>>> Jay
>>>
>>> On Sat, May 31, 2014 at 1:46 PM, wrote:
>>>> matthias has updated `master' from 9d94ef725e to 89dea63995.
>>>> http://git.racket-lang.org/plt/9d94ef725e..89dea63995
>>>>
>>>> =[ One Commit ]=
>>>> Directory summary:
>>>> 84.2% pkgs/racket-pkgs/racket-doc/scribblings/reference/
>>>> 11.0% racket/collects/racket/contract/private/
>>>> 4.6% racket/collects/racket/contract/
>>>>
>>>> ~~
>>>>
>>>> 89dea63 Matthias Felleisen 2014-05-31 15:45
>>>> :
>>>> | removed _contract_ language from _invariant-..._ as much as possible
>>>> |
>>>> | added a hint as to why the error message uses the inappropriate contract
>>>> language
>>>> :
>>>> M racket/collects/racket/contract/private/base.rkt | 4 ++--
>>>> M racket/collects/racket/contract/region.rkt| 2 +-
>>>> M .../scribblings/reference/contracts.scrbl | 22
>>>> ++--
>>>>
>>>> =[ Overall Diff ]===
>>>>
>>>> pkgs/racket-pkgs/racket-doc/scribblings/reference/contracts.scrbl
>>>> ~
>>>> --- OLD/pkgs/racket-pkgs/racket-doc/scribblings/reference/contracts.scrbl
>>>> +++ NEW/pkgs/racket-pkgs/racket-doc/scribblings/reference/contracts.scrbl
>>>> @@ -1509,24 +1509,24 @@ The @racket[define-struct/contract] form only
>>>> allows a subset of the
>>>> (make-salmon #f 'pacific)
>>>> ]}
>>>>
>>>> -@defform[(invariant-contract contract-expr expr)]{
>>>> - Establishes an invariant of @racket[expr], determined by
>>>> @racket[contract-expr].
>>>> +@defform[(invariant-assertion invariant-expr expr)]{
>>>> + Establishes an invariant of @racket[expr], determined by
>>>> @racket[invariant-expr].
>>>>
>>>> - Unlike other ways to attach contracts to values, an
>>>> - @racket[invariant-contract] does not establish a boundary
>>>> - between two parties. Instead, it simply puts the contract
>>>> - on the value, treating the module containing the
>>>> - @racket[invariant-contract] expression as the party to be blamed
>>>> - for any violations of the contract.
>>>> + Unlike the specification of a contract, an
>>>> + @racket[invariant-assertion] does not establish a boundary
>>>> + between two parties. Instead, it simply attaches a logical assertion
>>>> + to the value. Because the form uses contract machinery to check the
>>>> + assertion, the surround module is treated as t
Re: [racket-dev] [plt] Push #28829: master branch updated
Based on this commit, I feel like "assert" would be a better name than
"invariant-assertion". I can imagine putting these on various internal
parts of a function where the self-blame would be justified. The
(define id (assert ctc e)) pattern is just one common use.
Jay
On Sat, May 31, 2014 at 1:46 PM, wrote:
> matthias has updated `master' from 9d94ef725e to 89dea63995.
> http://git.racket-lang.org/plt/9d94ef725e..89dea63995
>
> =[ One Commit ]=
> Directory summary:
> 84.2% pkgs/racket-pkgs/racket-doc/scribblings/reference/
> 11.0% racket/collects/racket/contract/private/
>4.6% racket/collects/racket/contract/
>
> ~~
>
> 89dea63 Matthias Felleisen 2014-05-31 15:45
> :
> | removed _contract_ language from _invariant-..._ as much as possible
> |
> | added a hint as to why the error message uses the inappropriate contract
> language
> :
> M racket/collects/racket/contract/private/base.rkt | 4 ++--
> M racket/collects/racket/contract/region.rkt| 2 +-
> M .../scribblings/reference/contracts.scrbl | 22
> ++--
>
> =[ Overall Diff ]===
>
> pkgs/racket-pkgs/racket-doc/scribblings/reference/contracts.scrbl
> ~
> --- OLD/pkgs/racket-pkgs/racket-doc/scribblings/reference/contracts.scrbl
> +++ NEW/pkgs/racket-pkgs/racket-doc/scribblings/reference/contracts.scrbl
> @@ -1509,24 +1509,24 @@ The @racket[define-struct/contract] form only allows
> a subset of the
> (make-salmon #f 'pacific)
> ]}
>
> -@defform[(invariant-contract contract-expr expr)]{
> - Establishes an invariant of @racket[expr], determined by
> @racket[contract-expr].
> +@defform[(invariant-assertion invariant-expr expr)]{
> + Establishes an invariant of @racket[expr], determined by
> @racket[invariant-expr].
>
> - Unlike other ways to attach contracts to values, an
> - @racket[invariant-contract] does not establish a boundary
> - between two parties. Instead, it simply puts the contract
> - on the value, treating the module containing the
> - @racket[invariant-contract] expression as the party to be blamed
> - for any violations of the contract.
> + Unlike the specification of a contract, an
> + @racket[invariant-assertion] does not establish a boundary
> + between two parties. Instead, it simply attaches a logical assertion
> + to the value. Because the form uses contract machinery to check the
> + assertion, the surround module is treated as the party to be blamed
> + for any violations of the assertion.
>
> - This means, for example, that the contract is checked on
> + This means, for example, that the assertion is checked on
>recursive calls, when an invariant is used on the right-hand
> - side of a definition.
> + side of a definition:
>
>@examples[#:eval
> furlongs->feet-eval
> (define furlongss->feets
> - (invariant-contract
> + (invariant-assertion
> (-> (listof real?) (listof real?))
> (λ (l)
> (cond
>
> racket/collects/racket/contract/private/base.rkt
>
> --- OLD/racket/collects/racket/contract/private/base.rkt
> +++ NEW/racket/collects/racket/contract/private/base.rkt
> @@ -3,7 +3,7 @@
> (provide contract
> (rename-out [-recursive-contract recursive-contract])
> current-contract-region
> - invariant-contract)
> + invariant-assertion)
>
> (require (for-syntax racket/base syntax/name syntax/srcloc)
> racket/stxparam
> @@ -89,7 +89,7 @@
>(procedure-rename new-val vs-name)])]
>[else new-val])))
>
> -(define-syntax (invariant-contract stx)
> +(define-syntax (invariant-assertion stx)
>(syntax-case stx ()
> [(_ ctc e)
> (quasisyntax/loc stx
>
> racket/collects/racket/contract/region.rkt
> ~~
> --- OLD/racket/collects/racket/contract/region.rkt
> +++ NEW/racket/collects/racket/contract/region.rkt
> @@ -4,7 +4,7 @@
> define/contract
> with-contract
> current-contract-region
> - invariant-contract)
> + invariant-assertion)
>
> (require (for-syntax racket/base
> racket/struct-info
--
Jay McCarthy
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay
"The glory of God is Intelligence" - D&C 93
_
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 > 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, 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 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
> +instant
[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 Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 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 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 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" >>> To: "Matthias Felleisen" >>> Cc: "dev@racket-lang.org Dev" >>> 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 >>> 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 > Assistant Professor / Brigham Young University > http://faculty.cs.byu.edu/~jay > > "The glory of God is Intelligence" - D&C 93 -- Jay McCarthy Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 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 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" >> To: "Matthias Felleisen" >> Cc: "dev@racket-lang.org Dev" >> 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 >> 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 Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 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 wrote: > * Jay McCarthy > - Web Server Tests > - XML Tests > - HTML Tests > - PLAI Tests > - Racklog tests > - Datalog tests All passed -- Jay McCarthy Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 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 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 Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 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 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 Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Pre-Release Checklist for v6.0, Second Call
On Sun, Dec 29, 2013 at 11:57 AM, Ryan Culpepper wrote:
> Checklist items for the v6.0 release
> (using the v5.91.0.900 release candidate build)
>
> Search for your name to find relevant items, reply when you finish an
> item (please indicate which item/s is/are done). Also, if you have any
> commits that should have been picked, make sure that the changes are in.
>
> Important: new builds are created without announcement, usually whenever
> I pick a few commits. If you need to commit changes, please make sure
> you tell me to pick it into the release branch.
>
> --> Release candidates are at
> --> http://plt.eecs.northwestern.edu/release-snapshots/
>
> Note the nonstandard location!
>
> The "Racket plus Tests" builds already include the test packages. If
> you use a "Minimal Racket" build instead, install test packages
> manually using "raco pkg install".
>
> ------
>
> * Matthew Flatt
> - Run COM tests
>
> * Robby Findler
> - DrRacket Tests
>
> * Jay McCarthy
> - Web Server Tests
> - HTML Tests
All passed
> * Eli Barzilay
> - Swindle Tests
> - XREPL Tests
> - Verify PL language
> - Racket Tree: compare new distribution tree to previous one
> - Run the unix installer tests
> - Run zsh completions tests
> (". .../racket-completion.zsh; _racket --self-test")
> Version Updates: if a major change has happened, update the version
> number in:
> - racket/collects/mzscheme/info.rkt
> - racket/collects/mred/info.rkt
>
> * Carl Eastlund
> - Dracula Tests (confirm that Dracula runs from PLaneT)
>
> * David Van Horn
> - EoPL Tests
>
> * Neil Toronto
> - Plot Tests
--
Jay McCarthy
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay
"The glory of God is Intelligence" - D&C 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 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 Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 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, 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 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 2013-12-20 15:47
> :
> | Remove secret information from pkg error messages
> :
> M racket/collects/pkg/util.rkt | 4 +++-
>
> ~~
>
> 7faab4d Jay McCarthy 2013-12-20 15:53
> :
> | Fix PR14216
> :
> M racket/collects/pkg/lib.rkt | 5 +++--
>
> ~~
>
> 490e21f Jay McCarthy 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 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 @@
>
>
>
> + cellpadding="0" cellspacing="0" width="100%"> href="http://racket-lang.org/";>( style="font-size: 80px; vertical-align: middle;">( class="navtitle" style="font-size: 60px; vertical-align:
> middle;">( style="vertical-align: middle; margin: 13px 0.25em 0 0; border: 0;"> class="navtitle" style="font-size: 80px; vertical-align:
> middle;">Racket style="font-size: 60px; vertical-align: middle;">) class="navtitle" style="font-size: 80px; vertical-align:
> middle;">)) href="http://racket-lang.org/help.html";>Need
> Help? width="100%"> class="navlink"> href="http://racket-lang.org/";>About class="navlinkcell"> href="http://racket-lang.org/download/";>Download class="navlinkcell"> href="http://docs.racket-lang.org/";>Documentation class="navlinkcell"> href="/">Packages class="navitem"> href="http://racket-lang.org/community.html";>Community class="navlinkcell"> href="http://racket-lang.org/learning.html!
">!
> Learning!
>
> +
>
>Packages
>
> @@ -55,7 +57,7 @@
> Description: id="pi_description">
> Tags:
> id="pi_add_tag_text" class="text ui-widget-content ui-corner-all" /> id="pi_add_tag_button">Add Tag
> -Versions Exceptions id="pi_versions">
> +Version Exceptions id="pi_versions">
> Version:
> Source: id="pi_add_version_source_text" class="text ui-widget-content ui-corner-all"
> />Add Version Exception
> Dependencies id="pi_dependencies">
> Conflicts id="pi_conflicts">
>
> pkgs/plt-services/meta/pkg-index/official/static/style.css
> ~~
> --- OLD/pkgs/plt-services/meta/pkg-index/official/static/style.css
> +++ NEW/pkgs/plt-services/meta/pkg-index/official/static/style.css
> @@ -154,3 +154,52 @@ a.possible {
> tr#pi_delete_row td {
> text-
Re: [racket-dev] release notes
Ah. I think you should do it :) On Fri, Dec 20, 2013 at 2:36 PM, Robby Findler 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 > wrote: >> >> On Fri, Dec 20, 2013 at 2:17 PM, Robby Findler >> 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 >> > wrote: >> >> >> >> On Thu, Dec 19, 2013 at 7:41 PM, Robby Findler >> >> 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 >> >> Assistant Professor / Brigham Young University >> >> http://faculty.cs.byu.edu/~jay >> >> >> >> "The glory of God is Intelligence" - D&C 93 >> > >> > >> >> >> >> -- >> Jay McCarthy >> Assistant Professor / Brigham Young University >> http://faculty.cs.byu.edu/~jay >> >> "The glory of God is Intelligence" - D&C 93 > > -- Jay McCarthy Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 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 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 > wrote: >> >> On Thu, Dec 19, 2013 at 7:41 PM, Robby Findler >> 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 >> Assistant Professor / Brigham Young University >> http://faculty.cs.byu.edu/~jay >> >> "The glory of God is Intelligence" - D&C 93 > > -- Jay McCarthy Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 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 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 Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 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 wrote: > On Fri, Dec 20, 2013 at 8:26 AM, Matthew Flatt 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 Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 _ Racket Developers list: http://lists.racket-lang.org/dev
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 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 > wrote: >> >> On Mon, Dec 16, 2013 at 9:38 AM, Ryan Culpepper wrote: >> > * Jay McCarthy >> > - 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 >> Assistant Professor / Brigham Young University >> http://faculty.cs.byu.edu/~jay >> >> "The glory of God is Intelligence" - D&C 93 >> _ >> Racket Developers list: >> http://lists.racket-lang.org/dev > > -- Jay McCarthy Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 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 wrote: > * Jay McCarthy > - 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 Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 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 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 > 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 >> > wrote: >> >> >> >> >> >> >> >> On Wed, Nov 27, 2013 at 7:21 PM, Jay McCarthy >> >> 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 #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, 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 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 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] [plt] Push #27862: master branch updated
On Wed, Nov 27, 2013 at 6:27 PM, Robby Findler wrote: > > > > On Wed, Nov 27, 2013 at 7:21 PM, Jay McCarthy 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 #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 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 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, 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 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 2013-11-27 14:54 >> > : >> > | edit on lose focus >> > : >> > M pkgs/plt-services/meta/pkg-index/official/static/index.js | 4 +++- >> > >> > ~~ >> > >> > cf1755f Jay McCarthy 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 2013-11-27 15:30 >> > : >> > | deleting static s3 content properly >> > : >> > M pkgs/plt-services/meta/pkg-index/official/static.rkt | 11 >> > ++- >> > >> > ~~ >> > >> > 7b7a5ad Jay McCarthy 2013-11-27 15:33 >> > : >> > | increase pkg test timeout >> > : >> > M pkgs/plt-services/meta/props | 2 +- >> > >> > ~~ >> > >> > 60ae164 Jay McCarthy 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 >> > >
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, 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 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 2013-11-27 14:54 > : > | edit on lose focus > : > M pkgs/plt-services/meta/pkg-index/official/static/index.js | 4 +++- > > ~~ > > cf1755f Jay McCarthy 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 2013-11-27 15:30 > : > | deleting static s3 content properly > : > M pkgs/plt-services/meta/pkg-index/official/static.rkt | 11 ++- > > ~~ > > 7b7a5ad Jay McCarthy 2013-11-27 15:33 > : > | increase pkg test timeout > : > M pkgs/plt-services/meta/props | 2 +- > > ~~ > > 60ae164 Jay McCarthy 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 @@ > Last Edit: > Description: id="pi_description"> > Tags: > -Add > Tag > + id="pi_add_tag_text" class="text ui-widget-content ui-corner-all" /> id="pi_add_tag_button">Add Tag > Versions Exceptions id="pi_versions"> > Version: > Source: id="pi_add_version_source_text" class="text ui-widget-content ui-corner-all" > />Add Version Exception > Dependencies id="pi_dependencies"> > Conflicts id="pi_conflicts"> > Modules > + id="pi_delete_button">Delete > +Package(there is no undo!) > > >Install this package > with:raco pkg install id="pi_name_inst">or, with the 'File|Install Package...' > menu option in DrRacket. > > pkgs/plt-services/meta/pkg-index/official/static/index.js > ~ > --- OLD
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 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 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 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 >> > # >> > >> > 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 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] [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 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 > # > > 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 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] 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 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 Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 _ 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 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 Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 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 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 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 Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 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 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 Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] how to test rackunit
tion: > pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/all-rackunit-tests.rkt:49:3 > actual: "apples" > expected: "oranges" > Check failure > > > Failures > Intended to throw error > Intended to throw error > ERROR > testing: <> > context...: > > /home/dtp/src/dtp-racket/pkgs/rackunit-pkgs/rackunit-lib/rackunit/private/result.rkt:99:3 > > /home/dtp/src/dtp-racket/pkgs/rackunit-pkgs/rackunit-lib/rackunit/private/test-suite.rkt:28:2 >the-tests > > /home/dtp/src/dtp-racket/pkgs/rackunit-pkgs/rackunit-lib/rackunit/private/test-suite.rkt:60:0: > apply-test-suite > > /home/dtp/src/dtp-racket/pkgs/rackunit-pkgs/rackunit-lib/rackunit/text-ui.rkt:238:0: > run-tests14 > > /home/dtp/src/dtp-racket/pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/run-tests.rkt: > [running body] >f88 >loop >loop >loop >f88 > > /home/dtp/src/dtp-racket/pkgs/compiler-pkgs/compiler-lib/compiler/commands/test.rkt: > [running body] >/home/dtp/src/dtp-racket/racket/collects/raco/raco.rkt: [running body] >/home/dtp/src/dtp-racket/racket/collects/raco/main.rkt: [running body] > > > > Failures > Error within a check > Error within a check > ERROR > name: check > location: > pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/all-rackunit-tests.rkt:51:37 > params: # > 'foo > 'bar > error: contract violation > expected: string? > given: 'bar > argument position: 2nd > other arguments...: >'foo > context...: > > /home/dtp/src/dtp-racket/pkgs/rackunit-pkgs/rackunit-lib/rackunit/private/check.rkt:133:29 > > /home/dtp/src/dtp-racket/pkgs/rackunit-pkgs/rackunit-lib/rackunit/private/check.rkt:119:21: > check491437 > > /home/dtp/src/dtp-racket/pkgs/rackunit-pkgs/rackunit-lib/rackunit/private/result.rkt:99:3 > > /home/dtp/src/dtp-racket/pkgs/rackunit-pkgs/rackunit-lib/rackunit/private/test-suite.rkt:28:2 >the-tests > > /home/dtp/src/dtp-racket/pkgs/rackunit-pkgs/rackunit-lib/rackunit/private/test-suite.rkt:60:0: > apply-test-suite > > /home/dtp/src/dtp-racket/pkgs/rackunit-pkgs/rackunit-lib/rackunit/text-ui.rkt:238:0: > run-tests14 > > /home/dtp/src/dtp-racket/pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/run-tests.rkt: > [running body] >f88 >loop >loop >loop >f88 > > /home/dtp/src/dtp-racket/pkgs/compiler-pkgs/compiler-lib/compiler/commands/test.rkt: > [running body] >/home/dtp/src/dtp-racket/racket/collects/raco/raco.rkt: [running body] >/home/dtp/src/dtp-racket/racket/collects/raco/main.rkt: [running body] > > > 0 success(es) 3 failure(s) 2 error(s) 5 test(s) run > 5 > raco test: > "pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/standalone-check-test.rkt" > Oh HAI! > I didn't run > raco test: > "pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/standalone-test-case-test.rkt" > raco test: "pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/standalone.rkt" > raco test: > "pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/test-case-test.rkt" > raco test: > "pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/test-suite-test.rkt" > raco test: "pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/test-test.rkt" > raco test: "pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/text-ui-test.rkt" > raco test: > "pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/text-ui-util-test.rkt" > 55/340 test failures > raco test: "pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/tl.rkt" > raco test: "pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/util-test.rkt" > _ > Racket Developers list: > http://lists.racket-lang.org/dev -- Jay McCarthy Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 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 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
> /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
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay
"The glory of God is Intelligence" - D&C 93
_
Racket Developers list:
http://lists.racket-lang.org/dev
[racket-dev] PLT Package Catalog changes
I've updated the package catalog to be a JS application that is hosted on S3 with the Racket portion just handling the dynamic portion. As the DNS entries are being changed, the old server https://pkg.racket-lang.org redirects to http://pkg.racket-lang.org and will serve the static content. In the future, it will redirect to http://pkgs.racket-lang.org which is the S3 site that the documentation will start referring to. The dynamic portion will be at https://pkgd.racket-lang.org but you will never go to that site yourself. 'raco pkg' (and friends) will starting contacting "http://pkgs.racket-lang.org"; and if there are old clients out there (as there are sure to be) then "https://pkg.racket-lang.org"; will redirect appropriately. I am fairly certain that everything is in working order... I've tested it with old clients and new clients, but it's possible that there will be weirdness until the DNS entries are out there. I've tested the JS code with most major browsers on Linux and I believe I use all standard things (jquery, etc) that are cross-browser, but please inform me of any problems you find. Jay -- Jay McCarthy Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 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
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 "IIUC"s 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
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay
"The glory of God is Intelligence" - D&C 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 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 Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Generics updates
Totally agree. On Wed, Oct 2, 2013 at 2:53 PM, Sam Tobin-Hochstadt wrote: > On Wed, Oct 2, 2013 at 4:44 PM, Jay McCarthy 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 >> wrote: >>> On Wed, Oct 2, 2013 at 4:29 PM, Robby Findler >>> 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 >>>> 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 >>>>> wrote: >>>>> > If we do go this way, we should be careful about the subtyping >>>>> > relationship >>>>> > since we want a
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 wrote: > On Wed, Oct 2, 2013 at 4:29 PM, Robby Findler > 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 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 >>> 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 >>> > 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 >>> >> 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" >>> >> > To: "Carl Eastlund" >>> >> > Cc: "Racket Developers" >>> >> > Sent: Wednesday, October 2, 2013 3:23:07 PM GMT -05:00 US/Canada >>> >> > Eastern >>> >> > Subject: Re: [racket-dev] Generics upda
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 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 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 >> 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 >> > 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 >> >> 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" >> >> > To: "Carl Eastlund" >> >> > Cc: "Racket Developers" >> >> > 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 >> >> > 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. >> >> >>
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 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 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 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" >> > To: "Carl Eastlund" >> > Cc: "Racket Developers" >> > 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 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 [*] >&
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 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" > To: "Carl Eastlund" > Cc: "Racket Developers" > 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 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 > Assistant Professor / Brigham Young University > http://faculty.cs.byu.edu/~jay > > "The glory of God is Intelligence" - D&C 93 > _ > Racket Developers list: > http://lists.racket-lang.org/dev -- Jay McCarthy Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 _ Racket Developers list: http://lists.racket-lang.org/dev
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 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 Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 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 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 Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 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 Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 _ Racket Developers list: http://lists.racket-lang.org/dev
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 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 Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 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 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 Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 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 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 Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 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 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 Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 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 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 Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 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 wrote: > 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 > Assistant Professor / Brigham Young University > http://faculty.cs.byu.edu/~jay > > "The glory of God is Intelligence" - D&C 93 > > > -- Jay McCarthy Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 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 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 Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 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 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 > 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 > > Assistant Professor / Brigham Young University > > http://faculty.cs.byu.edu/~jay > > > > "The glory of God is Intelligence" - D&C 93 > > _ > > Racket Developers list: > > http://lists.racket-lang.org/dev > -- Jay McCarthy Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 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 Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket] Functional Updates for Structs
ans >> (wire source through pipe into sink) ...) >> >> The context for this is robotics programming where source and sink structs >> model input and the robot respectively. If anyone's familiar with LabView, >> it's not entirely dissimilar. >> >> I'm trying to make the DSL 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 Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 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 wrote: > > On Fri, Aug 23, 2013 at 2:48 PM, Jay McCarthy > 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 Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 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 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 Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 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 Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Lists aren't sets, but have set-like operations
h, yes. The set? predicate no longer distinguishes a representation. >> >> There are several predicates for the original set type, now called >> >> "hash >> >> sets": set-eq?, set-eqv?, set-equal?, set-mutable?, set-immtuable?, and >> >> set-weak?. I didn't add the basic "hash-set?", but perhaps I should. >> >> It's >> >> a weird name, since "hash-set" and "hash-set!" are already existing, >> >> unrelated functions. >> >> >> >> Carl Eastlund >> >> >> >> >> >> On Wed, Aug 21, 2013 at 7:08 PM, J. Ian Johnson < i...@ccs.neu.edu > >> >> wrote: >> >> >> >> > Okay, I can abide. However, that doesn't really get at my >> >> > frustration. I'm >> >> > using the set constructor, that appears to now be an >> >> > immutable-custom-set >> >> > with make-immutable-hash as its make-table. So what I'm looking for >> >> > is not >> >> > set?, but set-immutable?, as it's a distinct (family of) struct types >> >> > that >> >> > won't clash with the primitive data that I'm otherwise using. >> >> > -Ian >> >> > - Original Message - >> >> > From: "Carl Eastlund" < c...@ccs.neu.edu > >> >> > To: "J. Ian Johnson" < i...@ccs.neu.edu > >> >> > Cc: "dev" < dev@racket-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 Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 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 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 `. 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 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 Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Updating dependency packages from other sources
On Sat, Aug 17, 2013 at 6:16 AM, Matthew Flatt wrote: > At Fri, 16 Aug 2013 17:22:13 -0400, Asumu Takikawa wrote: >> > 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. >> >> Right now updates from the local filesystem (say in --copy mode) aren't >> tracked. Is the idea to change that so that `raco pkg update foo` will >> copy a new version of the package from the filesystem? > > That hasn't changed. Jay will have to comment on the rationale for not > updating packages by name from local sources. > > My guess is that local sources are not expected to stick around, and > you don't want something like `raco pkg update --all' getting confused > when half of a local directory in "/tmp" has been erased. Yes, exactly. The idea is that if a directory is expected to hang around then you --link it but if it isn't then you --copy it. I imagined that local FS would only be used for development or after some sort of external system (like ftp or scp) copied the thing to your disk. -- Jay McCarthy Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 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 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 Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 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 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 Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 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 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 Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 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 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 Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 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 > * Jay McCarthy > - Web Server Tests > - XML Tests > - HTML Tests > - PLAI Tests > - Racklog tests > - Datalog tests All done -- Jay McCarthy Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 _ Racket Developers list: http://lists.racket-lang.org/dev
