Re: [racket-dev] ready for the package switch?
Yesterday, Matthew Flatt wrote: > > I don't think that will work right in the long run. There's > currently no easy query to get all of the subcollections of a given > collection. > > Instead of looking for subcollections of "games", I think > `games/main' should find all "info.rkt"s that have a `game' > definition (via `find-relevant-directories'). +8 for this, and also I think that it applies for other path-based conventions like tests and scribblings. (And that leads me back to the specification of these things in info files, of course.) -- ((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] ready for the package switch?
Yesterday, Carl Eastlund wrote: > On Tue, Jun 18, 2013 at 2:02 PM, Eli Barzilay wrote: > > 20 minutes ago, Carl Eastlund wrote: > > [...] > > > > git rebase -s recursive -X rename-threshold=50% mflatt/pkg2 > > From a brief reading, I think that you're much better off with > "-X subtree=/some/path". There's also a subtree strategy, which > you'd get with "-s subtree", but it is guessing how to do the > path shifting. > > I thought that too, but it didn't work when I tried it. Some of my > files need to go in racket/lib, some in pkgs/racket-tests, and I > think there might have been a third place. So unless everything is > uniformly going to the same place, the subtree options don't help. In that case, I think that you should rebase each commit based on where it should go, and possibly split commits that touch different paths. At a higher level, things like this point to possible mistakes in package splitting which should be fixed. In some cases they might mean that a different split should happen, but in the case of the racket tests I think that it's far too broad and should be taken as a temporary package until all tests move out into their proper places. Maybe Matthew decided to make it a separate package because of 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
Re: [racket-dev] ready for the package switch?
On 06/18/13 19:36, Carl Eastlund wrote: I don't understand why version control systems don't take directories and renames more seriously, because this stuff is part of the development cycle and should be recorded like any other change. Mercurial tracks renames. Look "hg help mv" :) _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] ready for the package switch?
At Tue, 18 Jun 2013 15:40:27 -0400, Ryan Culpepper wrote: > I tried it. It works, but DrRacket doesn't find the macro stepper tool. > The racket/lib/info-cache.rktd has an entry for the right location, but > it also has another (lib "macro-debugger") entry. Is this caused by > having multiple modules "named" macro-debugger/info? Yes, but that's supposed to be ok. I've pushed a repair. > BTW, something is still populating > racket/lib/collects/info-domain/compiled/cache.rktd (rather than > racket/lib/info-cache.rktd). I thought the info-domain collection would > have disappeared. (And I thought it would be in racket/etc, but that > seems not to be the case.) The "cache.rktd" file is more like a bytecode file than a configuration --- it's a kind of compilation merging multiple "info.rkt" files, as opposed to a configuration that can change independently. So, that's why it's not in "etc". But why one in "lib/collects/..." and one immediately in "lib", instead of a single file in one of those places? The one in "lib/collects/..." has everything about "lib/collects/..." and only things about "lib/collects/...", which is important for the process of creating installers. The one in "lib" stores information on package and linked collections (in installation scope). > Is there a reason for the pkgs/*-pkgs groupings? I think I'd prefer pkgs > to contain just packages, but maybe I'm overlooking a benefit. The grouping is about packages versus repositories. See the "Current Proposed Repository Organization" section of http://lists.racket-lang.org/dev/archive/2013-June/012530.html _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] ready for the package switch?
At Tue, 18 Jun 2013 17:23:56 -0500, Robby Findler wrote: > On Tue, Jun 18, 2013 at 3:14 PM, Asumu Takikawa wrote: > > > On 2013-06-18 10:47:01 -0600, Matthew Flatt wrote: > > > Because this change will break all sorts of things in the short run, > > > I'd like to feel more confident that enough of us are ready before > > > merging it to the main Racket repository. > > > > The pkg2 branch builds for me fine (modulo `plot`) and I can run > > DrRacket. The `plt-games` executable does not work, however, and just > > produces a blank window for me. > > > > > This is because this expression: > > (define gamedirs > (filter directory-exists? > (map (λ (x) (build-path x "games")) >(current-library-collection-paths > > in games/main.rkt returns the empty list. Probably some different strategy > should be used for finding games. Maybe in the pkg world just doing this: > > (define gamedirs > (list (collection-path "games"))) > > is the right thing? I don't think that will work right in the long run. There's currently no easy query to get all of the subcollections of a given collection. Instead of looking for subcollections of "games", I think `games/main' should find all "info.rkt"s that have a `game' definition (via `find-relevant-directories'). _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] ready for the package switch?
At Tue, 18 Jun 2013 13:56:14 -0400, Asumu Takikawa wrote: > On 2013-06-18 10:47:01 -0600, Matthew Flatt wrote: > > Because this change will break all sorts of things in the short run, > > I'd like to feel more confident that enough of us are ready before > > merging it to the main Racket repository. > > Just FYI, the build will probably complain when compiling `plot`, but > that's my fault and not the new package migration's fault. (and I'm > working on fixing it) I've force-pushed a new "pkg2" that is rebased onto Asumu's repairs. (Apologies for any hassle that the forced push creates.) _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] ready for the package switch?
On Tue, Jun 18, 2013 at 3:14 PM, Asumu Takikawa wrote: > On 2013-06-18 10:47:01 -0600, Matthew Flatt wrote: > > Because this change will break all sorts of things in the short run, > > I'd like to feel more confident that enough of us are ready before > > merging it to the main Racket repository. > > The pkg2 branch builds for me fine (modulo `plot`) and I can run > DrRacket. The `plt-games` executable does not work, however, and just > produces a blank window for me. > > This is because this expression: (define gamedirs (filter directory-exists? (map (λ (x) (build-path x "games")) (current-library-collection-paths in games/main.rkt returns the empty list. Probably some different strategy should be used for finding games. Maybe in the pkg world just doing this: (define gamedirs (list (collection-path "games"))) is the right thing? Works great for me too, btw. Robby _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] ready for the package switch?
At Tue, 18 Jun 2013 14:16:09 -0600, Matthew Flatt wrote: > At Tue, 18 Jun 2013 16:13:09 -0400, Carl Eastlund wrote: > > I ran 'make', after rebasing, and eventually got this error: > > > > pkg: missing dependencies > > for package: pkgs/gui-pkgs/gui-lib > > missing packages: > >gui-x86_64-macosx > > > > Anyone know what might have gone wrong? > > It's a problem with the makefile. I'll push a fix (to "pkg2") soon. Pushed. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] ready for the package switch?
At Tue, 18 Jun 2013 16:13:09 -0400, Carl Eastlund wrote: > I ran 'make', after rebasing, and eventually got this error: > > pkg: missing dependencies > for package: pkgs/gui-pkgs/gui-lib > missing packages: >gui-x86_64-macosx > > Anyone know what might have gone wrong? It's a problem with the makefile. I'll push a fix (to "pkg2") soon. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] ready for the package switch?
On 2013-06-18 10:47:01 -0600, Matthew Flatt wrote: > Because this change will break all sorts of things in the short run, > I'd like to feel more confident that enough of us are ready before > merging it to the main Racket repository. The pkg2 branch builds for me fine (modulo `plot`) and I can run DrRacket. The `plt-games` executable does not work, however, and just produces a blank window for me. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] ready for the package switch?
I ran 'make', after rebasing, and eventually got this error: pkg: missing dependencies for package: pkgs/gui-pkgs/gui-lib missing packages: gui-x86_64-macosx Anyone know what might have gone wrong? --Carl _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] ready for the package switch?
On Tue, Jun 18, 2013 at 3:40 PM, Ryan Culpepper wrote: > I tried it. It works, but DrRacket doesn't find the macro stepper tool. The > racket/lib/info-cache.rktd has an entry for the right location, but it also > has another (lib "macro-debugger") entry. Is this caused by having multiple > modules "named" macro-debugger/info? I tried it, and it works, modulo the errors with Plot that Asumu and David both mentioned. Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] ready for the package switch?
I tried it. It works, but DrRacket doesn't find the macro stepper tool. The racket/lib/info-cache.rktd has an entry for the right location, but it also has another (lib "macro-debugger") entry. Is this caused by having multiple modules "named" macro-debugger/info? BTW, something is still populating racket/lib/collects/info-domain/compiled/cache.rktd (rather than racket/lib/info-cache.rktd). I thought the info-domain collection would have disappeared. (And I thought it would be in racket/etc, but that seems not to be the case.) I tried rebasing one of my branches to the 'pkg' branch yesterday, and that seems to have worked. With Carl's advice, the next time might go even easier. Is there a reason for the pkgs/*-pkgs groupings? I think I'd prefer pkgs to contain just packages, but maybe I'm overlooking a benefit. Ryan On 06/18/2013 12:47 PM, Matthew Flatt wrote: Here's the latest (in a "pkg2" branch): https://github.com/mflatt/racket/tree/pkg2 Because this change will break all sorts of things in the short run, I'd like to feel more confident that enough of us are ready before merging it to the main Racket repository. So, vote in favor of the reorganization like this: 1. Try the branch: git clone https://github.com/mflatt/racket.git cd racket git checkout pkg2 make racket/bin/drracket 2. Reply to the list to say that it works and we should merge it. 3. If you have code in "pkgs", be ready to help get that code into the right shape/packages after the merge. Thanks! (We haven't yet changed anything about single-collection versus multi-collection packages. That's currently planned for right after the merge.) _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] ready for the package switch?
On Tue, Jun 18, 2013 at 2:02 PM, Eli Barzilay wrote: > 20 minutes ago, Carl Eastlund wrote: > > [...] > > > > git rebase -s recursive -X rename-threshold=50% mflatt/pkg2 > > From a brief reading, I think that you're much better off with > "-X subtree=/some/path". There's also a subtree strategy, which you'd > get with "-s subtree", but it is guessing how to do the path shifting. > I thought that too, but it didn't work when I tried it. Some of my files need to go in racket/lib, some in pkgs/racket-tests, and I think there might have been a third place. So unless everything is uniformly going to the same place, the subtree options don't help. --Carl _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] ready for the package switch?
On 06/18/2013 12:47 PM, Matthew Flatt wrote: 2. Reply to the list to say that it works and we should merge it. I got the below 4 similar errors. DrRacket works. Linux Mint 14 (Linux funland 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux). Let me know if I can help. raco setup: error: during making for /plot/ raco setup: pkgs/plot/typed/contracted/parameters.rkt:64:23: Type Checker: Type (Parameterof Plot-Pen-Styles) could not be converted to a contract. raco setup: in: (Parameterof Plot-Pen-Styles) raco setup: context...: raco setup: f372 raco setup: f111 raco setup: /home/dvanderson/apps/racket/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/private/type-contract.rkt:49:0: generate-contract-def raco setup: /home/dvanderson/apps/racket/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/private/type-contract.rkt:80:2: for-loop raco setup: /home/dvanderson/apps/racket/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/private/type-contract.rkt:79:0: change-contract-fixups raco setup: success raco setup: /home/dvanderson/apps/racket/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/typed-racket.rkt:53:4 raco setup: /home/dvanderson/apps/racket/racket/lib/collects/compiler/cm.rkt:372:0: compile-zo* raco setup: /home/dvanderson/apps/racket/racket/lib/collects/compiler/cm.rkt:579:26 raco setup: /home/dvanderson/apps/racket/racket/lib/collects/compiler/cm.rkt:572:42 raco setup: /home/dvanderson/apps/racket/racket/lib/collects/compiler/cm.rkt:537:0: maybe-compile-zo raco setup: /home/dvanderson/apps/racket/racket/lib/collects/compiler/cm.rkt:649:2: do-check raco setup: /home/dvanderson/apps/racket/racket/lib/collects/compiler/cm.rkt:759:4: compilation-manager-load-handler raco setup: #f::6094: standard-module-name-resolver raco setup: success raco setup: /home/dvanderson/apps/racket/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/typed-racket.rkt:53:4... raco setup: raco setup: raco setup: error: during making for /plot/typed raco setup: pkgs/plot/typed/contracted/parameters.rkt:64:23: Type Checker: Type (Parameterof Plot-Pen-Styles) could not be converted to a contract. raco setup: in: (Parameterof Plot-Pen-Styles) raco setup: context...: raco setup: f372 raco setup: f111 raco setup: /home/dvanderson/apps/racket/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/private/type-contract.rkt:49:0: generate-contract-def raco setup: /home/dvanderson/apps/racket/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/private/type-contract.rkt:80:2: for-loop raco setup: /home/dvanderson/apps/racket/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/private/type-contract.rkt:79:0: change-contract-fixups raco setup: success raco setup: /home/dvanderson/apps/racket/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/typed-racket.rkt:53:4 raco setup: /home/dvanderson/apps/racket/racket/lib/collects/compiler/cm.rkt:372:0: compile-zo* raco setup: /home/dvanderson/apps/racket/racket/lib/collects/compiler/cm.rkt:579:26 raco setup: /home/dvanderson/apps/racket/racket/lib/collects/compiler/cm.rkt:572:42 raco setup: /home/dvanderson/apps/racket/racket/lib/collects/compiler/cm.rkt:537:0: maybe-compile-zo raco setup: /home/dvanderson/apps/racket/racket/lib/collects/compiler/cm.rkt:649:2: do-check raco setup: /home/dvanderson/apps/racket/racket/lib/collects/compiler/cm.rkt:759:4: compilation-manager-load-handler raco setup: #f::6094: standard-module-name-resolver raco setup: success raco setup: /home/dvanderson/apps/racket/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/typed-racket.rkt:53:4... raco setup: raco setup: raco setup: error: during making for /plot/typed raco setup: pkgs/plot/typed/contracted/parameters.rkt:64:23: Type Checker: Type (Parameterof Plot-Pen-Styles) could not be converted to a contract. raco setup: in: (Parameterof Plot-Pen-Styles) raco setup: context...: raco setup: f372 raco setup: f111 raco setup: /home/dvanderson/apps/racket/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/private/type-contract.rkt:49:0: generate-contract-def raco setup: /home/dvanderson/apps/racket/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/private/type-contract.rkt:80:2: for-loop raco setup: /home/dvanderson/apps/racket/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/private/type-contract.rkt:79:0: change-contract-fixups raco setup: success raco setup: /home/dvanderson/apps/racket/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/typed-racket.rkt:53:4 raco setup: /home/dvanderson/apps/racket/racket/lib/collects/compiler/cm.rkt:372:0: compile-zo* raco setup: /home/dvanderson/apps/racket/racket/lib/collects/compiler/cm.rkt:579:26 raco setup: /home/dvanderson/apps/racket/racket/lib/collects/compiler/cm.rkt:572:42 raco setup: /home/dvanderson/apps/racket/racket/lib/collects/compiler/cm.
Re: [racket-dev] ready for the package switch?
Carl Eastlund wrote at 06/18/2013 01:36 PM: I don't understand why version control systems don't take directories and renames more seriously, because this stuff is part of the development cycle and should be recorded like any other change. This doesn't help, but... I think the reason is that it's hard to do, so most SCM systems haven't even tried. It's very common for a rename to be a delete-plus-add in the model. Or, in an RCS/SCCS/etc.-backed system like CVS, for someone to simply rename the files in the repository server's filesystem and break any branches that did not want those files renamed. Perhaps the most sophisticated SCM I've used, Atria ClearCase (a descendant of Apollo DSEE) in the early-mid 1990s, had a much more sophisticated model than the others, and, IIRC, even did fancy things like monitoring filesystem operations(?), but it cost a lot of money and required a lot of sys-admin. Git's free-ness and popularity makes it the obvious choice to use nowadays, but in my limited experience with it, Git seems to have a lot of evolution of "let's add on yet another somewhat different concept to our numerous existing concepts that originally built upon some scripts that Linus found useful for managing kernel patches", rather than nailing a clean and sufficient model from the start. This is a source of frustration to those of us who have used a dozen other SCM systems and recall basic things being easier to do in the past. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] ready for the package switch?
20 minutes ago, Carl Eastlund wrote: > [...] > > git rebase -s recursive -X rename-threshold=50% mflatt/pkg2 From a brief reading, I think that you're much better off with "-X subtree=/some/path". There's also a subtree strategy, which you'd get with "-s subtree", but it is guessing how to do the path shifting. > I don't understand why version control systems don't take > directories and renames more seriously, because this stuff is part > of the development cycle and should be recorded like any other > change. Meta: JFYI, not only does git not track renames, it doesn't do that *intentionally*. The exact arguments for/against are irrelevant, but the main point is that the decision was made very deliberately, and therefore you can't really accuse them of not taking it seriously enough even if you disagree with the decision. Concrete: I said this many times, and it's important to remind people of this especially now -- because git relies on detecting renames, it is *MUCH* better to commit just renames, without changes to file contents. Yes -- even if that means that there's a commit with an uncompilable tree, the potential minor hassle to future bisecters is smaller than the potential to bad rename detection damages. -- ((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] ready for the package switch?
On 2013-06-18 10:47:01 -0600, Matthew Flatt wrote: > Because this change will break all sorts of things in the short run, > I'd like to feel more confident that enough of us are ready before > merging it to the main Racket repository. Just FYI, the build will probably complain when compiling `plot`, but that's my fault and not the new package migration's fault. (and I'm working on fixing it) Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] ready for the package switch?
I'm rebasing my generic-sets branch onto the pkg2 branch to make sure that rebasing works well. Just using the default rebase options hasn't worked, it doesn't figure out to follow the renames. The following command seems to be working, however; it may work for other people as well: git rebase -s recursive -X rename-threshold=50% mflatt/pkg2 This tells git that any files that are at least 50% similar (I guess by line count?) are considered renamed versions of each other, and I guess gives it permission to do the necessary, somewhat expensive search to figure out which files to change in the rebased version instead of the ones you actually changed in the original. I also had to run the following command first: git config merge.renameLimit 10 Otherwise git won't use the rename-threshold, because there are too many files to consider in our repository and it doesn't believe you really want it to do _that much_ work. You can revert this afterward with: git config --unset merge.renameLimit I don't understand why version control systems don't take directories and renames more seriously, because this stuff is part of the development cycle and should be recorded like any other change. Anyway, if any of you out there are having trouble rebasing onto Matthew's packages branch, try the commands above. Carl Eastlund On Tue, Jun 18, 2013 at 12:47 PM, Matthew Flatt wrote: > Here's the latest (in a "pkg2" branch): > > https://github.com/mflatt/racket/tree/pkg2 > > Because this change will break all sorts of things in the short run, > I'd like to feel more confident that enough of us are ready before > merging it to the main Racket repository. > > So, vote in favor of the reorganization like this: > > 1. Try the branch: > > git clone https://github.com/mflatt/racket.git > cd racket > git checkout pkg2 > make > racket/bin/drracket > > 2. Reply to the list to say that it works and we should merge it. > > 3. If you have code in "pkgs", be ready to help get that code into the > right shape/packages after the merge. > > Thanks! > > > (We haven't yet changed anything about single-collection versus > multi-collection packages. That's currently planned for right after the > merge.) > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] ready for the package switch?
On Tue, Jun 18, 2013 at 12:54 PM, Matthew Flatt wrote: > At Tue, 18 Jun 2013 10:47:01 -0600, Matthew Flatt wrote: >> 1. Try the branch: >> >> git clone https://github.com/mflatt/racket.git > > Sorry --- that should be > > git clone git://github.com/mflatt/racket.git Either of these URLs will work, I believe. Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] ready for the package switch?
At Tue, 18 Jun 2013 10:47:01 -0600, Matthew Flatt wrote: > 1. Try the branch: > > git clone https://github.com/mflatt/racket.git Sorry --- that should be git clone git://github.com/mflatt/racket.git _ Racket Developers list: http://lists.racket-lang.org/dev
