Re: [racket-dev] Planet 2 Beta Release
On Sat, Dec 1, 2012 at 10:56 AM, Jay McCarthy jay.mccar...@gmail.com wrote: On Fri, Nov 30, 2012 at 7:09 PM, Matthew Flatt mfl...@cs.utah.edu wrote: Version-specific installation - Not to speak too much on Jay's behalf, but I think he isn't convinced that the new default is right. If `--shared' is the default, then a `raco pkg update' could be enough to get all your installed packages working with a new version. If installation is instead version-specific, then you have to reinstall every package that you use whenever you upgrade. I think that if installation is all-version by default, then users who are going to end up with bad configurations that they have trouble repairing. A better way to deal with upgrades would be something like `raco pkg migrate'. If we decide that version-specific is the right default to keep, and if some would still like a more convenient way to manage all-version packages, we could add an environment variable that makes `--shared' the default. Something that bothers me a lot of P1 is that when I install an upgrade, I lose all my packages. This means that the documentation search suddenly starts returning different things, so I forget about which packages I had installed at all. I only discover this when I go to write something and have a long install and download process. Or, when I run a script I wrote a long time ago and it doesn't return instantly, but spawns an install. I'm much less worried about Racket versions breaking installed packages than Matthew. I don't think it is that common for core changes to break things and when it does happen, P2 is designed to easily allow you to upgrade all your packages to the latest versions, something that was very inconvenient with P1. I.e. you can do raco pkg update --all, which isn't possible with P1. I strongly agree with Jay here. A few additional reasons, besides what he explained: - The explanation that package doesn't work with the latest Racket, you need to update it is easier for people to understand than you don't have that package installed, unless you do in which case you should migrate it to your current version. This is helped by the fact that most other languages that I know of have all-version installation. - Developer convenience is important, and most of us use git HEAD, whose versions change quite rapidly. Now following the version number is very important, otherwise all your software will break. - Once many of the current collects move to packages, there will be many fewer opportunities to break the behavior of the core, so the problems Matthew worries about will be less severe, and the problems Jay and I worry about may be more severe. - Version-specific installation does not work well with package-specific installation, which is something I hope we can add as an option in the future. - One drawback of version-specific installation in Planet1 that I experienced was that fixing an installed Planet package by editing the source broke entirely when switching to a new version. Relatedly, version-specific install almost requires putting the installations in an out-of-the-way directory, making finding and editing source more difficult. -- sam th sa...@ccs.neu.edu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
At Sun, 2 Dec 2012 10:15:56 -0500, Sam Tobin-Hochstadt wrote: - Developer convenience is important, and most of us use git HEAD, whose versions change quite rapidly. Consider installing packages to work with your git HEAD checkout as installation-specific packages. That way, there's no version issue --- and when you want to check Racket's behavior in the current release, your git HEAD build doesn't interfere with the release. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
Who here has tried using `raco link' for development? The default mode is user-specific but not version-specific, and I've found that default to be inconvenient. Usually, it turns out, I want an installation-specific link, because I want it linked only for my development version of Racket. When I get to the point that I do want to use a different Racket version, it's a pain to juggle the links or make a copy for different version. I look forward to using packages, installation-specific links, and version-specific installs that are taken as snapshots of the git repo. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
On Sun, Dec 2, 2012 at 10:38 AM, Matthew Flatt mfl...@cs.utah.edu wrote: Who here has tried using `raco link' for development? I use `raco link` for all of my development -- once `raco link` was released, I basically gave up on Planet1 and used `raco link` for everything. The default mode is user-specific but not version-specific, and I've found that default to be inconvenient. Usually, it turns out, I want an installation-specific link, because I want it linked only for my development version of Racket. When I get to the point that I do want to use a different Racket version, it's a pain to juggle the links or make a copy for different version. I look forward to using packages, installation-specific links, and version-specific installs that are taken as snapshots of the git repo. I have mostly the opposite impression of `raco link`. I like the default behavior, but that may be a result of my use of a set of scripts [1] for managing Racket installations that makes basically everything into installation-specific packages. One additional issue with version-specific installs that I just thought of -- imagine a student installing a course package on a lab computer, and then Racket being upgraded during the semester. [1] https://github.com/takikawa/racket-dev-goodies -- sam th sa...@ccs.neu.edu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
At Sun, 2 Dec 2012 10:55:01 -0500, Sam Tobin-Hochstadt wrote: I have mostly the opposite impression of `raco link`. I like the default behavior, but that may be a result of my use of a set of scripts [1] for managing Racket installations that makes basically everything into installation-specific packages. It sounds like you're advocating something that you haven't tried, and you wanted installation-specific links, anyway. If there's still some reason that environment-variable scripts are the way to go as far as packages are concerned, then let's add an environment variable that changes the default for package installation and affects only people who know how to deal with it. One additional issue with version-specific installs that I just thought of -- imagine a student installing a course package on a lab computer, and then Racket being upgraded during the semester. Exactly. That student is going to get an error message when DrRacket starts up saying that the handin tool is broken. They complain to someone, and so on. It would be much better for the handin tool (for the class they aren't taking anymore) to just be gone until they specifically ask for it back through a migration tool. Or they just shrug and re-install, but that's more obvious and doesn't involve bugging a teacher or admin. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Testing whether a procedure gets collected
On Dec 1, 2012, at 9:23 PM, Robby Findler wrote: I think the high-level answer is that you have to understand something about details that aren't currently specified but nevertheless are how things currently work and then make a test that will work when you make those additional assumptions (and then keep it running in drdr so you can tell when the assumptions get broken). Doesn't this suggest deep down that Neil is trying to 'beat' Racket and its implementation with his program? I think the entire discussion (I didn't follow every detail) points to something lacking about the language. -- Matthias _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Testing whether a procedure gets collected
On Sun, Dec 2, 2012 at 11:43 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: On Dec 1, 2012, at 9:23 PM, Robby Findler wrote: I think the high-level answer is that you have to understand something about details that aren't currently specified but nevertheless are how things currently work and then make a test that will work when you make those additional assumptions (and then keep it running in drdr so you can tell when the assumptions get broken). Doesn't this suggest deep down that Neil is trying to 'beat' Racket and its implementation with his program? I think the entire discussion (I didn't follow every detail) points to something lacking about the language. -- Matthias I think that Neil wants to formulate a test case that checks that his datastructure doesn't leak and is complaining about the lack of specification for what If the garbage collector has proven (quote from the docs) means. My experience with similar testing is that the level of specification is actually okay. I can't speak for finalizers (they are more complex) but weak boxes seem fine. Robby _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
Exactly. That student is going to get an error message when DrRacket starts up saying that the handin tool is broken. They complain to someone, and so on. Or, even worse, the student can get the error message at Check Syntax time, after which because it's an internal error, DrRacket goes unresponsive and the user can't even save their program anymore. (I've had this happen a few times, and it's one of the worse case scenarios I've run into.) _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Testing whether a procedure gets collected
On 12/02/2012 12:10 PM, Robby Findler wrote: On Sun, Dec 2, 2012 at 11:43 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: On Dec 1, 2012, at 9:23 PM, Robby Findler wrote: I think the high-level answer is that you have to understand something about details that aren't currently specified but nevertheless are how things currently work and then make a test that will work when you make those additional assumptions (and then keep it running in drdr so you can tell when the assumptions get broken). Doesn't this suggest deep down that Neil is trying to 'beat' Racket and its implementation with his program? I think the entire discussion (I didn't follow every detail) points to something lacking about the language. -- Matthias I think that Neil wants to formulate a test case that checks that his datastructure doesn't leak and is complaining about the lack of specification for what If the garbage collector has proven (quote from the docs) means. I didn't mean to sound complain-y... :p My experience with similar testing is that the level of specification is actually okay. I can't speak for finalizers (they are more complex) but weak boxes seem fine. And that helps a lot, so thanks! You're both right, of course. I'm essentially trying to test something that is unobservable. The fact that I can observe it is an implementation accident. The specific accident, that a weak box is cleared as soon as possible, happens to be common and generally expected. I don't know whether it's worth it in this case to tighten the specification. I don't want anyone to spend time on it unless it's actually worth researching. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
