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] hash->list stability?
That makes sense. 'sort' to the rescue! On Tuesday, June 18, 2013, Carl Eastlund wrote: > On Tue, Jun 18, 2013 at 3:21 PM, Dan Liebgold > > > wrote: > >> According to the docs, hash->list returns a list in an unspecified order. >> Can anyone tell me a little about how hash->list might return two >> different orders give the same hash table? Possibly across different >> invocations of Racket? >> >> Thanks, >> -- >> Dan Liebgold[dan.liebg...@gmail.com > 'dan.liebg...@gmail.com');>] >> > > Different invocations of Racket could do it; for instance, eq-hash-code > assigns hash codes sequentially to objects on demand, so if objects were > hashed in a different order nondeterministically, they would be put in a > table in a different order. Adding or removing elements via mutation might > also cause a table to be resized, and that might shuffle around the > existing/remaining elements and cause them to be in a different order. > > --Carl > -- Dan Liebgold[dan.liebg...@gmail.com] _ 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] hash->list stability?
On Tue, Jun 18, 2013 at 3:21 PM, Dan Liebgold wrote: > According to the docs, hash->list returns a list in an unspecified order. > Can anyone tell me a little about how hash->list might return two > different orders give the same hash table? Possibly across different > invocations of Racket? > > Thanks, > -- > Dan Liebgold[dan.liebg...@gmail.com] > Different invocations of Racket could do it; for instance, eq-hash-code assigns hash codes sequentially to objects on demand, so if objects were hashed in a different order nondeterministically, they would be put in a table in a different order. Adding or removing elements via mutation might also cause a table to be resized, and that might shuffle around the existing/remaining elements and cause them to be in a different order. --Carl _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] hash->list stability?
According to the docs, hash->list returns a list in an unspecified order. Can anyone tell me a little about how hash->list might return two different orders give the same hash table? Possibly across different invocations of Racket? Thanks, -- Dan Liebgold[dan.liebg...@gmail.com] _ 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
[racket-dev] ready for the package switch?
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-dev] Realm of Racket
Thanks for bearing with me with the special release. It's done! Here is the message that went to 'users' and 'edu'. Realm of Racket is finally out. For the first 72 hours, NoStarch.com offers a 40% off coupon plus a free e-book version if you buy the book from their website. Otherwise the book is distributed through O'Reilly and is available at the usual places wherever O'Reilly sells its wares. ROAR is a book designed and authored by freshmen students from Northeastern, edited by myself and David Van Horn. It is intended for novices with some basic exposure to programming, not necessarily in Racket or Lisp-related languages. Following Conrad Barski's Land of Lisp, ROAR mixes instructions on programming with the creation of interactive games;, all of it illustrated with drawings and short cartoon stories. While LOL uses text-based gaming, ROAR is based on the HtDP 2e libraries, used inside of #lang racket modules. NoStarch.com's web site includes a sample chapter, "Hungry Henry", which showcases the creation of distributed GUI games. At Northeastern, we intend to use ROAR as the recommended bridge between HtDP/2e -- which does not use Racket but teaching languages -- and real Racket programming. I will also borrow exercises from ROAR to run my freshman course on program design. Congratulations to Mimi, Spencer, Rose, Eric, Scott, Ryan, Forrest, and Nicole for sticking through a two-year production process. Enjoy -- Matthias p.s. I am told you're welcome to re-distribute the coupon message below as widely as you wish. Begin forwarded message: > From: No Starch Press > Subject: 40% Off Realm of Racket > Date: June 18, 2013 11:00:20 AM EDT > > Learn to Program, One Game at a Time! > Email look funny? > View it in your browser. > > 40% Off Realm of Racket > > For the next 72 hours, get 40% off Realm of Racket, and learn to program in > Racket, one game at a time! > > Use coupon code RACKETEERS. > > Coupon good on print or ebook purchase. Print purchase includes DRM-free > ebook (PDF, epub, and mobi). > > Follow on Twitter | Friend on Facebook | Forward to a friend > No Starch Press > 38 Ringold Street > San Francisco, CA 94103 > > Add us to your address book > > Update subscription | Unsubscribe| View in browser > > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] PLaneT(2): Single vs multi-collection packages
Matthew Flatt wrote at 06/18/2013 07:59 AM: In principle, you should add a versioned dependency on "racket" to indicate that the package does not work with version 5.3.4, and so users of v5.3.4 should get an earlier revision of the package. Just a general comment... For production use, I try not to have libraries push people to new versions of Racket without good reason. Despite my general awareness and practice, I was actually bit by this problem recently. A consulting client who used one of my open source libraries in production had a problem that I had addressed in a new version of the library. But it turned out that an interim version of the library added a dependency on some new Racket feature, and client's production setup would be disrupted if they had to move Racket versions (increases unknowns). I ended up forking my own library for the client, and merging the fix into their fork. In the more distant past, I think I've also had at least one situation in which I made a Racket (or PLT Scheme) library version use some new Racket feature, then in a subsequent version I reversed this change, so that it could work with an older Racket version. This doesn't have to be a big encumbrance -- I do adopt new Racket features when they are win (e.g., submodules, define-logger), but I try to make small efforts to avoid requiring newer Racket versions than I really need, since pushing people to new Racket versions does seem to cause problems in practice. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] PLaneT(2): Single vs multi-collection packages
At Mon, 17 Jun 2013 16:53:50 -0400, Greg Hendershott wrote: > I'm still thinking that I'll keep my existing multi-collection > packages as multi, to preserve compatibility with 5.3.4. Only because, > although my packages don't have many users, I'll err on the side of > their convenience. > > But if someone else did want to change from multi to single: > > 1. Philosophical: Wouldn't this be bad to do without renaming the > package, since the spirit of the package system versioning is, never > break backward compatibility? Or, is it acceptable, now, since this > is technically still in beta? In principle, you should add a versioned dependency on "racket" to indicate that the package does not work with version 5.3.4, and so users of v5.3.4 should get an earlier revision of the package. We have not yet set up "pkg.racket-lang.org" to pay attention to the version number that is included in a request or to let authors configure version-specific mappings for packages, though. > 2. Practical: Would `raco pkg update' handle such a multi->single > transform? Or should packagers instruct users to (a) remove and (b) > install? `raco pkg update' can handle a switch from multi-package form to single-package form or vice versa. > I'm asking in case it would help to have the answer(s) ready for doc > or FAQ purposes. > > > On Sat, Jun 15, 2013 at 11:19 AM, Matthew Flatt wrote: > > At Fri, 14 Jun 2013 21:14:58 -0400, Greg Hendershott wrote: > >> I just want to be clear what I need to do to > >> keep compatibility with 5.3.4 for existing packages. If that means > >> adding something to info.rkt to say, "yeah, I'm still multi", I may do > >> that. > > > > Yes, that's exactly what will be required for a package to work with > > both v5.3.4 and after the change: keep the package multi-collection, > > and explicitly declare it as such by adding a line to "info.rkt". > > > > For the new "info.rkt" field, should it be > > > > (define multi-collection? #t) > > > > ? > > _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Need help staging traverse-blocks to generate a document glossary
I am trying to use traverse-block to build a glossary of terms used in a document. I have a scribble function @vocab to tag items to include in the glossary. I want to display the glossary early in the document (before the terms are used). I'm having trouble delaying glossary generation until the list of terms has been populated (the list is populated if I generate the glossary at the end of the document, but the terms list is empty if I generate near the top of the document). My @vocab function uses traverse-element to build the term list: (define (vocab body) (traverse-element (lambda (get set) (set 'vocab-used (cons body (get 'vocab-used '( (elem #:style bs-vocab-style body My glossary function (in my scribble extension, not exposed to the document author) fetches and displays the terms. I call it within a larger user-exposed function that defines the document contents: (define (glossary) (traverse-block (lambda (get set) (traverse-block (lambda (get set) (define terms (get 'vocab-used '())) (para terms)) (I tried nesting the inner lambda directly in the outer one, but that yields an error from traverse-block-block that no block is computed). The user-facing scribble function that calls glossary is also wrapped in a traverse-block (for reasons unrelated to the glossary). Rough structure is as follows, where @vocab calls are in body: (define (lesson . body) (traverse-block (lambda (get set) (glossary) (para body What do I need to change to populate the glossary? thanks! Kathi _ Racket Developers list: http://lists.racket-lang.org/dev
