Re: [racket-dev] [racket] DrRacket Tools/plugins info wanted
I think it would also help if the doc pages cited by the OP were to list all tools coming with the main distribution and explain how to disable them a bit more. That's less work than coding. -- Matthias On Jul 29, 2013, at 1:01 PM, Robby Findler wrote: [moved to dev@] Would it be something to shoot for with the package-based release: only getting a minimal set of tools/plugins (like Stephen's set) when the drracket package is the only one installed (starting from a minimal racket)? Robby On Mon, Jul 29, 2013 at 8:32 AM, Stephen De Gabrielle stephen.degabrie...@acm.org wrote: Hi, I delete anything that I recognise don't use, (and leave the stuff I don't understand alone). I remove the teaching languages, slideshow, swindle, lazy. If you find racket doesn't launch you can always manually edit the preferences file. My suggested working minimum is Check Syntax Graphical Debugger Macro Stepper I like to include RackUnit HTH Stephen image.png -- Stephen De Gabrielle On Mon, Jul 29, 2013 at 8:46 AM, Jon Kleiser jon.klei...@usit.uio.no wrote: Hi, On one of my older Macs, DrRacket uses quite some time to launch, and I wondered if disabling some of the 17 Tools in the Preferences could help. Before disabling any of these, however, I'd like some info about what they really do. Looking here didn't make me any wiser: http://docs.racket-lang.org/drracket/prefs-explanation.html#%28part._.Tools%29 ... except that those tools are also called plugins. I cannot see that this page http://docs.racket-lang.org/tools/ has the info that I'm looking for either. /Jon Racket Users list: http://lists.racket-lang.org/users Racket Users list: http://lists.racket-lang.org/users Racket Users list: http://lists.racket-lang.org/users _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] git submodule for native-library packages
A report from the junior varsity squad: I just tried this on OS X and it worked AOK. FWIW I've been strictly doing `git pull --ff-only upstream master` to keep my fork's master 100% in sync with PLT's. Any experimentation or feature requests done solely on topic branches. (Like I wrote about here: http://www.greghendershott.com/2013/04/a-guide-for-infrequent-contributors-to-racket.html ) I don't yet know enough about Git submodules to understand the analog of that workflow for submodules, if any. I suspect it will be moot because I'll probably never doink around with the kind of stuff in native-pkgs. However if submodules start to get used more extensively I guess I may need to learn more about submodules. On Sat, Jul 27, 2013 at 9:10 AM, Matthew Flatt mfl...@cs.utah.edu wrote: Nothing has been split out of the current git repository, but there is now a native-pkgs git submodule for the native-library packages. If you build on Mac OS X or Windows or if you run a snapshot build, then you'll need to use git pull git submodule init git submodule update once on each repository checkout from now on, and git pull git submodule update for updates after the first checkout. If you just `git pull' without the submodule commands, then you'll have an empty native-pkgs directory. That's fine if you're building on, say, Linux. If you're on Mac OS X or Windows, then the makefile should give you a good error message and suggest using `git submodule init' and `git submodule update'. If you use `git submodule update' today and forget to use it in the future, probably things will be fine for a long time, because native-pkgs doesn't change often. If native-pkgs does change and you forget `git submodule update', then (as I understand things) `git status' will tell you that there's a mismatch. The mismatch report might take a form that's not entirely clear, but it should be enough to remind you to run `git submodule update'. I'm still unsure that submodules are going to be useful for managing a kind of main-distribution repository with references to package repositories. I'm much more confident that a submodule will work for the native-library packages in the current build structure. The native libraries are already kept in a separate repository, they change infrequently, and almost no one has to change them. Also, the native-pkgs git submodule replaces two things that I think were just bad forms of `git submodule update': * A makefile target that fires on Mac OS X and uses `git pull', which is bad if you happen to be working offline. * A note in INSTALL.txt that tells Windows users to manually clone a particular git repository. If a git submodule does not work out for native-library packages after all, then should be easy to roll back, since there was no split to rewind. Meanwhile, we get a little experience with git submodules. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] git submodule for native-library packages
On 2013-07-27 07:10:54 -0600, Matthew Flatt wrote: I'm still unsure that submodules are going to be useful for managing a kind of main-distribution repository with references to package repositories. Perhaps it would be worth considering using the git subtree feature instead of submodules for the rest of the repository (just to clarify, I'm not saying we should reconsider submodules for native-pkgs). Description here: https://github.com/apenwarr/git-subtree/blob/master/git-subtree.txt In particular, this aspect seems useful for us: you can also extract the entire history of a subdirectory from your project and make it into a standalone project From what I understand (not having used them yet), subtrees also enable end users of our main repo to just do a clone without any special consideration for the subtrees. Only package maintainers would have to occasionally update the subtrees in the main repo to pull in changes from their own package repos. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] git submodule for native-library packages
I looked into git-subtree, and as I recall it, nothing in the setup recalls what subtree is used for what. Every git-subtree command you enter has to be fully explicit, which is a big hassle. Whereas git-submodule saves its state in the repository, so it knows what it's being used for and you only need to do it once. Hopefully I misunderstood git-subtree, but if I didn't, I found its interface disappointing. Carl Eastlund On Tue, Jul 30, 2013 at 5:41 PM, Asumu Takikawa as...@ccs.neu.edu wrote: On 2013-07-27 07:10:54 -0600, Matthew Flatt wrote: I'm still unsure that submodules are going to be useful for managing a kind of main-distribution repository with references to package repositories. Perhaps it would be worth considering using the git subtree feature instead of submodules for the rest of the repository (just to clarify, I'm not saying we should reconsider submodules for native-pkgs). Description here: https://github.com/apenwarr/git-subtree/blob/master/git-subtree.txt In particular, this aspect seems useful for us: you can also extract the entire history of a subdirectory from your project and make it into a standalone project From what I understand (not having used them yet), subtrees also enable end users of our main repo to just do a clone without any special consideration for the subtrees. Only package maintainers would have to occasionally update the subtrees in the main repo to pull in changes from their own package repos. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] git submodule for native-library packages
On 2013-07-30 17:44:37 -0400, Carl Eastlund wrote: I looked into git-subtree, and as I recall it, nothing in the setup recalls what subtree is used for what. Every git-subtree command you enter has to be fully explicit, which is a big hassle. AFAIK, you are correct. OTOH, I imagine that using subtree commands is actually going to be relatively rare. Here is my reasoning: * You are a developer on a Racket main distribution package: - Most of your commits will be local to that package while you work on it. Let's assume this is in a separate repo (otherwise the subtree thing is moot) - You'll work on a working copy of that package installed instead of the core package that ships with release Racket (using `raco pkg` to set up the links) - Assuming the last two points, you are unlikely to use any subtree commands until the changes need to be merged for a release or for wider use/testing. * You are a power user of Racket: - You'll just clone the whole Racket git repo and automatically get all of the subtrees. No additional effort necessary unless you want to make changes. * You are a developer responsible for the release: - You will probably end up pulling all subtrees (which is pretty manual work) and then cherry-pick all relevant commits. In comparison, I think submodules are supposed to make it less convenient for the power user who is just cloning the repo. That said, this isn't informed by a lot of experience with either feature, so please take with a salt mine. Maybe I will try this with Typed Racket somewhere and see what happens. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] git submodule for native-library packages
On 2013-07-31 00:04:20 -0400, Asumu Takikawa wrote: Maybe I will try this with Typed Racket somewhere and see what happens. One downside I discovered immediately after trying to set this up: the subtree command is only available in git 1.7.11 and newer and it's only available if the contrib tools are packaged in your git install (it's not in Debian). I tried using the subtree command to split out the main Typed Racket package into a separate repo. The result is here: https://github.com/takikawa/typed-racket-lib One issue is that the new repo only has history going back until the package split. This makes sense, given that the old paths are nonsense in the new repo. Maybe this is ok if the main Racket repo still has the history though. Unfortunately, this experiment didn't work very well. Doing a `git subtree pull` with just one simple new commit caused a spurious merge conflict, due to the fact that the new repo's SHA1s are different. Splitting out the package will require more clever git hackery. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
