From mflatt at cs.utah.edu Fri May 1 12:59:17 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Fri May 1 12:59:36 2009 Subject: [plt-dev] latest version under Windows Message-ID: <20090501165917.E74C16500B2@mail-svr1.cs.utah.edu> If you use Windows, then after upgrading to the latest in svn (or the next nightly build), please pay extra attention to whether DrScheme or other MrEd-based programs consume too much CPU. We've seen some problems with DrScheme maxing out a CPU when it should be idle. The problems happened especially with blocking reads on network sockets, but similar problems could happen with any GUI application. The latest changes fix the problem on my machine, but this fact of the system is difficult to test. Thanks, Matthew From carl.eastlund at gmail.com Fri May 1 17:17:22 2009 From: carl.eastlund at gmail.com (Carl Eastlund) Date: Fri May 1 17:17:43 2009 Subject: [plt-dev] in-place build directory (was re: build error with svn 14677) Message-ID: <990e0c030905011417h6b9f44c6odb431b68e2eea5c@mail.gmail.com> Can we please add this advice to the src/README file? There are so many esoteric options explained in there, but the one thing that doesn't show up is our convention of creating the src/build/ directory for in-place builds. New developers shouldn't have to learn this practice by word-of-mouth. This is important enough -- and the README file detailed enough -- that we may even want a step between the current 0 (remove old PLT installation) and 1 (run configure) for creating/choosing a build directory, including a default suggestion of src/build/ and followed up by some of the discussion currently under configure. Otherwise users trying for a "quick-start in-place build" may miss the discussion currently buried at the end of the "configure" section. --Carl ---------- Forwarded message ---------- From: Eli Barzilay Date: Fri, May 1, 2009 at 5:07 PM Subject: Re: [plt-scheme] build error with svn 14677 To: Robby Findler Cc: Doug Orleans , plt-scheme@list.cs.brown.edu On May ?1, Robby Findler wrote: > The svn tree is the latest, but the Makefiles are not guaranteed to > always get the right dependencies. They usually work, but if you see > problems, best thing is to just blow away the build directory and > try again. (And if you see a configure script change or a > Makefile.in changes, then probably best to not even try.) Right. ?To make it *much* better, you should never build the source tree in place -- that is, don't do this: ?cd .../plt/src ?./configure ?make ?make install Do this instead: ?cd .../plt/src ?mkdir build ?cd build ?../configure ?make ?make install This point is not specific to PLT -- it's generally healthier to do this for any autoconf-based build. -- ? ? ? ? ?((lambda (x) (x x)) (lambda (x) (x x))) ? ? ? ? ?Eli Barzilay: ? ? ? ? ? ? ? ? ?http://www.barzilay.org/ ? ? ? ? ? ? ? ? Maze is Life! From jay.mccarthy at gmail.com Fri May 1 17:26:35 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Fri May 1 17:26:59 2009 Subject: [plt-dev] in-place build directory (was re: build error with svn 14677) In-Reply-To: <990e0c030905011417h6b9f44c6odb431b68e2eea5c@mail.gmail.com> References: <990e0c030905011417h6b9f44c6odb431b68e2eea5c@mail.gmail.com> Message-ID: It's already there: The `configure' script generates the makefiles for building MzScheme and/or MrEd. The current directory at the time `configure' is run will be used as working space for building the executables (independent of --prefix). This build directory does not have to be in the source tree, even for an "in-place" build. It's ok to run `configure' from its own directory (as in the example above), but it's often better to pick a separate build directory that is otherwise empty. Jay On Fri, May 1, 2009 at 3:17 PM, Carl Eastlund wrote: > Can we please add this advice to the src/README file? ?There are so > many esoteric options explained in there, but the one thing that > doesn't show up is our convention of creating the src/build/ directory > for in-place builds. ?New developers shouldn't have to learn this > practice by word-of-mouth. > > This is important enough -- and the README file detailed enough -- > that we may even want a step between the current 0 (remove old PLT > installation) and 1 (run configure) for creating/choosing a build > directory, including a default suggestion of src/build/ and followed > up by some of the discussion currently under configure. ?Otherwise > users trying for a "quick-start in-place build" may miss the > discussion currently buried at the end of the "configure" section. > > --Carl > > ---------- Forwarded message ---------- > From: Eli Barzilay > Date: Fri, May 1, 2009 at 5:07 PM > Subject: Re: [plt-scheme] build error with svn 14677 > To: Robby Findler > Cc: Doug Orleans , plt-scheme@list.cs.brown.edu > > > On May ?1, Robby Findler wrote: >> The svn tree is the latest, but the Makefiles are not guaranteed to >> always get the right dependencies. They usually work, but if you see >> problems, best thing is to just blow away the build directory and >> try again. (And if you see a configure script change or a >> Makefile.in changes, then probably best to not even try.) > > Right. ?To make it *much* better, you should never build the source > tree in place -- that is, don't do this: > > ?cd .../plt/src > ?./configure > ?make > ?make install > > Do this instead: > > ?cd .../plt/src > ?mkdir build > ?cd build > ?../configure > ?make > ?make install > > This point is not specific to PLT -- it's generally healthier to do > this for any autoconf-based build. > > -- > ? ? ? ? ?((lambda (x) (x x)) (lambda (x) (x x))) ? ? ? ? ?Eli Barzilay: > ? ? ? ? ? ? ? ? ?http://www.barzilay.org/ ? ? ? ? ? ? ? ? Maze is Life! > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From carl.eastlund at gmail.com Fri May 1 17:34:30 2009 From: carl.eastlund at gmail.com (Carl Eastlund) Date: Fri May 1 17:35:04 2009 Subject: [plt-dev] in-place build directory (was re: build error with svn 14677) In-Reply-To: References: <990e0c030905011417h6b9f44c6odb431b68e2eea5c@mail.gmail.com> Message-ID: <990e0c030905011434n4c339d8ew90943ed9b9985ede@mail.gmail.com> That doesn't suggest creating a directory called "build" directly under the "src" directory, nor is that explanation in a prominent place. The specific choice of "src/build" is supported by the svn:ignore property in src/, for instance -- not all choices of build directory are equal. And this explanation comes after the initial description of the "configure" command, despite the need for "mkdir build" to come before it. So I think it's somewhat out of order. For most purposes, someone making a default, in-place build can just read the first paragraph of each step, maybe skim the rest for platform-specific "gotchas", and move on. I know it's important to read the whole thing, but that doesn't mean everybody will. I think those first-paragraphs should spell out a common path to an in-place build, and currently the "mkdir build ; cd build" step is missing. --Carl On Fri, May 1, 2009 at 5:26 PM, Jay McCarthy wrote: > It's already there: > > ?The `configure' script generates the makefiles for building > ? ?MzScheme and/or MrEd. The current directory at the time > ? ?`configure' is run will be used as working space for building the > ? ?executables (independent of --prefix). This build directory does > ? ?not have to be in the source tree, even for an "in-place" > ? ?build. It's ok to run `configure' from its own directory (as in > ? ?the example above), but it's often better to pick a separate build > ? ?directory that is otherwise empty. > > Jay > > On Fri, May 1, 2009 at 3:17 PM, Carl Eastlund wrote: >> Can we please add this advice to the src/README file? ?There are so >> many esoteric options explained in there, but the one thing that >> doesn't show up is our convention of creating the src/build/ directory >> for in-place builds. ?New developers shouldn't have to learn this >> practice by word-of-mouth. >> >> This is important enough -- and the README file detailed enough -- >> that we may even want a step between the current 0 (remove old PLT >> installation) and 1 (run configure) for creating/choosing a build >> directory, including a default suggestion of src/build/ and followed >> up by some of the discussion currently under configure. ?Otherwise >> users trying for a "quick-start in-place build" may miss the >> discussion currently buried at the end of the "configure" section. >> >> --Carl >> >> ---------- Forwarded message ---------- >> From: Eli Barzilay >> Date: Fri, May 1, 2009 at 5:07 PM >> Subject: Re: [plt-scheme] build error with svn 14677 >> To: Robby Findler >> Cc: Doug Orleans , plt-scheme@list.cs.brown.edu >> >> >> On May ?1, Robby Findler wrote: >>> The svn tree is the latest, but the Makefiles are not guaranteed to >>> always get the right dependencies. They usually work, but if you see >>> problems, best thing is to just blow away the build directory and >>> try again. (And if you see a configure script change or a >>> Makefile.in changes, then probably best to not even try.) >> >> Right. ?To make it *much* better, you should never build the source >> tree in place -- that is, don't do this: >> >> ?cd .../plt/src >> ?./configure >> ?make >> ?make install >> >> Do this instead: >> >> ?cd .../plt/src >> ?mkdir build >> ?cd build >> ?../configure >> ?make >> ?make install >> >> This point is not specific to PLT -- it's generally healthier to do >> this for any autoconf-based build. >> >> -- >> ? ? ? ? ?((lambda (x) (x x)) (lambda (x) (x x))) ? ? ? ? ?Eli Barzilay: >> ? ? ? ? ? ? ? ? ?http://www.barzilay.org/ ? ? ? ? ? ? ? ? Maze is Life! >> _________________________________________________ >> ?For list-related administrative tasks: >> ?http://list.cs.brown.edu/mailman/listinfo/plt-dev >> > > > > -- > Jay McCarthy > Assistant Professor / Brigham Young University > http://teammccarthy.org/jay > > "The glory of God is Intelligence" - D&C 93 From clements at brinckerhoff.org Fri May 1 18:47:59 2009 From: clements at brinckerhoff.org (John Clements) Date: Fri May 1 18:48:24 2009 Subject: [plt-dev] in-place build directory (was re: build error with svn 14677) In-Reply-To: <990e0c030905011434n4c339d8ew90943ed9b9985ede@mail.gmail.com> References: <990e0c030905011417h6b9f44c6odb431b68e2eea5c@mail.gmail.com> <990e0c030905011434n4c339d8ew90943ed9b9985ede@mail.gmail.com> Message-ID: On May 1, 2009, at 2:34 PM, Carl Eastlund wrote: > That doesn't suggest creating a directory called "build" directly > under the "src" directory, nor is that explanation in a prominent > place. The specific choice of "src/build" is supported by the > svn:ignore property in src/, for instance -- not all choices of build > directory are equal. And this explanation comes after the initial > description of the "configure" command, despite the need for "mkdir > build" to come before it. So I think it's somewhat out of order. > > For most purposes, someone making a default, in-place build can just > read the first paragraph of each step, maybe skim the rest for > platform-specific "gotchas", and move on. I know it's important to > read the whole thing, but that doesn't mean everybody will. I think > those first-paragraphs should spell out a common path to an in-place > build, and currently the "mkdir build ; cd build" step is missing. Hmm... sounds like you're volunteering, to me! :) John > --Carl > > On Fri, May 1, 2009 at 5:26 PM, Jay McCarthy > wrote: >> It's already there: >> >> The `configure' script generates the makefiles for building >> MzScheme and/or MrEd. The current directory at the time >> `configure' is run will be used as working space for building the >> executables (independent of --prefix). This build directory does >> not have to be in the source tree, even for an "in-place" >> build. It's ok to run `configure' from its own directory (as in >> the example above), but it's often better to pick a separate build >> directory that is otherwise empty. >> >> Jay >> >> On Fri, May 1, 2009 at 3:17 PM, Carl Eastlund > > wrote: >>> Can we please add this advice to the src/README file? There are so >>> many esoteric options explained in there, but the one thing that >>> doesn't show up is our convention of creating the src/build/ >>> directory >>> for in-place builds. New developers shouldn't have to learn this >>> practice by word-of-mouth. >>> >>> This is important enough -- and the README file detailed enough -- >>> that we may even want a step between the current 0 (remove old PLT >>> installation) and 1 (run configure) for creating/choosing a build >>> directory, including a default suggestion of src/build/ and followed >>> up by some of the discussion currently under configure. Otherwise >>> users trying for a "quick-start in-place build" may miss the >>> discussion currently buried at the end of the "configure" section. >>> >>> --Carl >>> >>> ---------- Forwarded message ---------- >>> From: Eli Barzilay >>> Date: Fri, May 1, 2009 at 5:07 PM >>> Subject: Re: [plt-scheme] build error with svn 14677 >>> To: Robby Findler >>> Cc: Doug Orleans , plt-scheme@list.cs.brown.edu >>> >>> >>> On May 1, Robby Findler wrote: >>>> The svn tree is the latest, but the Makefiles are not guaranteed to >>>> always get the right dependencies. They usually work, but if you >>>> see >>>> problems, best thing is to just blow away the build directory and >>>> try again. (And if you see a configure script change or a >>>> Makefile.in changes, then probably best to not even try.) >>> >>> Right. To make it *much* better, you should never build the source >>> tree in place -- that is, don't do this: >>> >>> cd .../plt/src >>> ./configure >>> make >>> make install >>> >>> Do this instead: >>> >>> cd .../plt/src >>> mkdir build >>> cd build >>> ../configure >>> make >>> make install >>> >>> This point is not specific to PLT -- it's generally healthier to do >>> this for any autoconf-based build. >>> >>> -- >>> ((lambda (x) (x x)) (lambda (x) (x x))) Eli >>> Barzilay: >>> http://www.barzilay.org/ Maze is >>> Life! >>> _________________________________________________ >>> For list-related administrative tasks: >>> http://list.cs.brown.edu/mailman/listinfo/plt-dev >>> >> >> >> >> -- >> Jay McCarthy >> Assistant Professor / Brigham Young University >> http://teammccarthy.org/jay >> >> "The glory of God is Intelligence" - D&C 93 > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2484 bytes Desc: not available Url : http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090501/676da0b9/smime-0001.bin From eli at barzilay.org Fri May 1 19:06:06 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri May 1 19:06:27 2009 Subject: [plt-dev] in-place build directory (was re: build error with svn 14677) In-Reply-To: <990e0c030905011434n4c339d8ew90943ed9b9985ede@mail.gmail.com> References: <990e0c030905011417h6b9f44c6odb431b68e2eea5c@mail.gmail.com> <990e0c030905011434n4c339d8ew90943ed9b9985ede@mail.gmail.com> Message-ID: <18939.32862.224200.550799@winooski.ccs.neu.edu> On May 1, Carl Eastlund wrote: > That doesn't suggest creating a directory called "build" directly > under the "src" directory, IMO, the only reason to suggest a "build" subdirectory -- the `svn:ignore' property -- is well below the threshold of what should be described in the src/README file. > nor is that explanation in a prominent place. And this explanation > comes after the initial description of the "configure" command, > despite the need for "mkdir build" to come before it. So I think > it's somewhat out of order. I've added more text describing this, and I've added a second example with a "build" subdirectory. However, the "The `configure' script generates ..." paragraphe is a little off now, since the subject was previously mentioned. I tried to fix it, but it's still not great. It would be nice if you (or anyone) can go over the new text and improve it. Another thing that would be very nice to add in there is a set of packages that should be installed to build everything on various Linux distros; the list of packages for Ubuntu and Fedora should cover most cases. But I don't know the exact list -- I'm not using Ubuntu regularly, and my Fedora installations usualy contain enough stuff that it's not an issue. If anyone has such lists I'll add them too. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From carl.eastlund at gmail.com Fri May 1 19:38:15 2009 From: carl.eastlund at gmail.com (Carl Eastlund) Date: Fri May 1 19:38:37 2009 Subject: [plt-dev] in-place build directory (was re: build error with svn 14677) In-Reply-To: <18939.32862.224200.550799@winooski.ccs.neu.edu> References: <990e0c030905011417h6b9f44c6odb431b68e2eea5c@mail.gmail.com> <990e0c030905011434n4c339d8ew90943ed9b9985ede@mail.gmail.com> <18939.32862.224200.550799@winooski.ccs.neu.edu> Message-ID: <990e0c030905011638g21c7d5c6u314d7df70f83e1c9@mail.gmail.com> On Fri, May 1, 2009 at 7:06 PM, Eli Barzilay wrote: > On May ?1, Carl Eastlund wrote: >> That doesn't suggest creating a directory called "build" directly >> under the "src" directory, > > IMO, the only reason to suggest a "build" subdirectory -- the > `svn:ignore' property -- is well below the threshold of what should be > described in the src/README file. Sure, if you want to suggest making some other directory, or leave the choice of name up to the user, that's fine. But it would still make a big difference to have "step 0.5: mkdir foo" preceding "step 1: run configure", rather than some paragraph following step 1 that describes the pros and cons of various choices of directories. The "svn:ignore" property is merely a good argument in favor of suggesting build/ over foo/ in step 0.5. When I introduce new people to building PLT from source, as I've done several times, I have to say "go follow the instructions... oh and before you do that, create the trunk/src/build directory, and build from there, so you'll have to prefix configure with ../ as well." I'd rather be able to just say "go follow the instructions". I've made a set of possible changes. Here is the text of the 'mkdir' and 'configure' steps (up to the example commands); I've attached a full README file as well as a diff that makes these changes and updates later references to step numbers. -------------------- 1. Select (or create) a build directory. It is better to run the build in a different directory rather than use this directory. A common choice for in-place builds is to create the [here]/build subdirectory (where "[here]" is the directory path containing the `configure' script). This is especially convenient if you plan to update your source tree from the plt repository. Such updates might involve changes in the structure, which will leave your source tree in an inconsistent state (eg, old Makefiles referring to nonexistent files). In such cases it is convenient to just remove the "build" directory, then re-create it and start a fresh build. 2. Run the script `configure' (which is in the same directory as this README) from your build directory, possibly with a --prefix=TARGETDIR command-line argument and optionally with --enable-shared. For example, if you want to install into /usr/local/plt using dynamic libraries, then run [here]configure --prefix=/usr/local/plt --enable-shared Again, "[here]" is the directory path containing the `configure' script (possibly unnecessary, or possibly just "./", depending on your shell and PATH setting). To use a different directory for the build, such as the [here]/build suggestion from above: cd [here] mkdir build cd build ../configure --prefix=/usr/local/plt --enable-shared -------------------- -- Carl Eastlund -------------- next part -------------- A non-text attachment was scrubbed... Name: README Type: application/octet-stream Size: 17811 bytes Desc: not available Url : http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090501/9947849b/README-0002.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: README.diff Type: application/octet-stream Size: 4050 bytes Desc: not available Url : http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090501/9947849b/README-0003.obj From eli at barzilay.org Fri May 1 20:01:42 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri May 1 20:02:11 2009 Subject: [plt-dev] in-place build directory (was re: build error with svn 14677) In-Reply-To: <990e0c030905011638g21c7d5c6u314d7df70f83e1c9@mail.gmail.com> References: <990e0c030905011417h6b9f44c6odb431b68e2eea5c@mail.gmail.com> <990e0c030905011434n4c339d8ew90943ed9b9985ede@mail.gmail.com> <18939.32862.224200.550799@winooski.ccs.neu.edu> <990e0c030905011638g21c7d5c6u314d7df70f83e1c9@mail.gmail.com> Message-ID: <18939.36198.292304.565294@winooski.ccs.neu.edu> On May 1, Carl Eastlund wrote: > > I've made a set of possible changes. Here is the text of the > 'mkdir' and 'configure' steps (up to the example commands); I've > attached a full README file as well as a diff that makes these > changes and updates later references to step numbers. The problem with this, so that it's now turned around: 1. Select (or create) a build directory. It is better to run the build in a different directory rather than use this directory. This reads like a specific instruction to create a build directory. It's an option that is very useful for people who will hold the directory for a long time, but these people are still a minority. Most people will compile from source once, or will compile from source once after every release. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From dvanhorn at ccs.neu.edu Fri May 1 20:12:36 2009 From: dvanhorn at ccs.neu.edu (David Van Horn) Date: Fri May 1 20:13:15 2009 Subject: [plt-dev] Garden fence benchmark Message-ID: <49FB8FF4.6050406@ccs.neu.edu> There have been recent discussions on plt-dev and plt-scheme about "garden fence" encryption (links below). I've collected the solutions and benchmarked them. The benchmark is included in my random access list library, which out performs the other functional solutions. Results are below. You can run this and other benchmarks (including the recently discussed "frequency counting" benchmark) by doing: mzscheme -p dvanhorn/ralist:1:12/run-benchmarks For more info on the package, and source code for the benchmark see: http://planet.plt-scheme.org/display.ss?package=ralist.plt&owner=dvanhorn David Garden fence encryption benchmark ================================= http://list.cs.brown.edu/pipermail/plt-scheme/2009-March/031310.html Key: ve = imperative vector http://list.cs.brown.edu/pipermail/plt-scheme/2009-March/031313.html ra = random access list (translation of above) dr = Felleisen output data driven design recipe http://list.cs.brown.edu/pipermail/plt-scheme/2009-March/031344.html (Omitted from 1,000,000 chars case since it takes too long) co = Felleisen combinator http://list.cs.brown.edu/pipermail/plt-dev/2009-April/000532.html cy = Tobin-Hochstadt in-cycle http://list.cs.brown.edu/pipermail/plt-dev/2009-April/000533.html (define str (build-string 10000 (lambda (i) #\x))) (encrypt str 20) ve: cpu time: 8 real time: 8 gc time: 0 ra: cpu time: 18 real time: 18 gc time: 0 dr: cpu time: 14 real time: 14 gc time: 0 co: cpu time: 28 real time: 28 gc time: 0 cy: cpu time: 32 real time: 32 gc time: 0 (decrypt str 20) ve: cpu time: 7 real time: 7 gc time: 0 ra: cpu time: 18 real time: 18 gc time: 0 dr: cpu time: 35 real time: 35 gc time: 0 co: cpu time: 50 real time: 50 gc time: 0 cy: cpu time: 42 real time: 42 gc time: 0 (define str (build-string 100000 (lambda (i) #\x))) (encrypt str 20) ve: cpu time: 92 real time: 93 gc time: 20 ra: cpu time: 228 real time: 228 gc time: 49 dr: cpu time: 1199 real time: 1198 gc time: 30 co: cpu time: 456 real time: 456 gc time: 123 cy: cpu time: 378 real time: 378 gc time: 49 (decrypt str 20) ve: cpu time: 92 real time: 91 gc time: 19 ra: cpu time: 220 real time: 219 gc time: 42 dr: cpu time: 1386 real time: 1385 gc time: 122 co: cpu time: 767 real time: 769 gc time: 122 cy: cpu time: 585 real time: 592 gc time: 113 (define str (build-string 1000000 (lambda (i) #\x))) (encrypt str 20) ve: cpu time: 1580 real time: 1605 gc time: 746 ra: cpu time: 2724 real time: 2740 gc time: 890 co: cpu time: 6658 real time: 6689 gc time: 1874 cy: cpu time: 5904 real time: 5987 gc time: 1585 (decrypt str 20) ve: cpu time: 1543 real time: 1556 gc time: 712 ra: cpu time: 2700 real time: 2751 gc time: 863 co: cpu time: 11991 real time: 12183 gc time: 3877 cy: cpu time: 9145 real time: 9187 gc time: 3136 From clements at brinckerhoff.org Fri May 1 20:15:56 2009 From: clements at brinckerhoff.org (John Clements) Date: Fri May 1 20:16:22 2009 Subject: [plt-dev] in-place build directory (was re: build error with svn 14677) In-Reply-To: <18939.36198.292304.565294@winooski.ccs.neu.edu> References: <990e0c030905011417h6b9f44c6odb431b68e2eea5c@mail.gmail.com> <990e0c030905011434n4c339d8ew90943ed9b9985ede@mail.gmail.com> <18939.32862.224200.550799@winooski.ccs.neu.edu> <990e0c030905011638g21c7d5c6u314d7df70f83e1c9@mail.gmail.com> <18939.36198.292304.565294@winooski.ccs.neu.edu> Message-ID: <2A8447F7-D69E-4D3E-94DC-C9E487F8B6E4@brinckerhoff.org> On May 1, 2009, at 5:01 PM, Eli Barzilay wrote: > On May 1, Carl Eastlund wrote: >> >> I've made a set of possible changes. Here is the text of the >> 'mkdir' and 'configure' steps (up to the example commands); I've >> attached a full README file as well as a diff that makes these >> changes and updates later references to step numbers. > > The problem with this, so that it's now turned around: > > 1. Select (or create) a build directory. It is better to run the > build in a different directory rather than use this directory. > > This reads like a specific instruction to create a build directory. > It's an option that is very useful for people who will hold the > directory for a long time, but these people are still a minority. > Most people will compile from source once, or will compile from source > once after every release. So what? Does it matter if everyone creates a build directory? John -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2484 bytes Desc: not available Url : http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090501/0470020c/smime.bin From eli at barzilay.org Fri May 1 20:20:00 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri May 1 20:20:24 2009 Subject: [plt-dev] in-place build directory (was re: build error with svn 14677) In-Reply-To: <2A8447F7-D69E-4D3E-94DC-C9E487F8B6E4@brinckerhoff.org> References: <990e0c030905011417h6b9f44c6odb431b68e2eea5c@mail.gmail.com> <990e0c030905011434n4c339d8ew90943ed9b9985ede@mail.gmail.com> <18939.32862.224200.550799@winooski.ccs.neu.edu> <990e0c030905011638g21c7d5c6u314d7df70f83e1c9@mail.gmail.com> <18939.36198.292304.565294@winooski.ccs.neu.edu> <2A8447F7-D69E-4D3E-94DC-C9E487F8B6E4@brinckerhoff.org> Message-ID: <18939.37296.812932.367171@winooski.ccs.neu.edu> On May 1, John Clements wrote: > > On May 1, 2009, at 5:01 PM, Eli Barzilay wrote: > > > The problem with this, so that it's now turned around: > > > > 1. Select (or create) a build directory. It is better to run the > > build in a different directory rather than use this directory. > > > > This reads like a specific instruction to create a build > > directory. It's an option that is very useful for people who will > > hold the directory for a long time, but these people are still a > > minority. Most people will compile from source once, or will > > compile from source once after every release. > > So what? Does it matter if everyone creates a build directory? It only matters in being more complicated than it could be. You only need a brief look at Matthew's version of the file to know that ./configure; make; make install should work as expected, and I think that it is desirable to keep this property. (But just to clarify, the README file is something that Matthew writes and maintains, so I don't want to commit a change that I'm not willing to defend personally.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From carl.eastlund at gmail.com Fri May 1 20:29:24 2009 From: carl.eastlund at gmail.com (Carl Eastlund) Date: Fri May 1 20:29:41 2009 Subject: [plt-dev] in-place build directory (was re: build error with svn 14677) In-Reply-To: <18939.37296.812932.367171@winooski.ccs.neu.edu> References: <990e0c030905011417h6b9f44c6odb431b68e2eea5c@mail.gmail.com> <990e0c030905011434n4c339d8ew90943ed9b9985ede@mail.gmail.com> <18939.32862.224200.550799@winooski.ccs.neu.edu> <990e0c030905011638g21c7d5c6u314d7df70f83e1c9@mail.gmail.com> <18939.36198.292304.565294@winooski.ccs.neu.edu> <2A8447F7-D69E-4D3E-94DC-C9E487F8B6E4@brinckerhoff.org> <18939.37296.812932.367171@winooski.ccs.neu.edu> Message-ID: <990e0c030905011729u63f1bd64p4d7db9b63dfac59b@mail.gmail.com> On Fri, May 1, 2009 at 8:20 PM, Eli Barzilay wrote: > On May ?1, John Clements wrote: >> >> On May 1, 2009, at 5:01 PM, Eli Barzilay wrote: >> >> > The problem with this, so that it's now turned around: >> > >> > 1. Select (or create) a build directory. ?It is better to run the >> > ? ?build in a different directory rather than use this directory. >> > >> > This reads like a specific instruction to create a build >> > directory. ?It's an option that is very useful for people who will >> > hold the directory for a long time, but these people are still a >> > minority. ?Most people will compile from source once, or will >> > compile from source once after every release. >> >> So what? Does it matter if everyone creates a build directory? > > It only matters in being more complicated than it could be. ?You only > need a brief look at Matthew's version of the file to know that > > ?./configure; make; make install > > should work as expected, and I think that it is desirable to keep this > property. ?(But just to clarify, the README file is something that > Matthew writes and maintains, so I don't want to commit a change that > I'm not willing to defend personally.) I agree that it's nice to have the normal Unix-style build strategy of "./configure && make && make install" as a default, but in our system it's not a very good default. We should present a default that is robust in the face of updating the source and rebuilding. Now, if we want to change our configure/make scripts to make this possible, that would be nice. In the meantime, I prefer "mkdir build && cd build && ../configure && make && make install" to the more familiar but less practical version. In fact, I should really write a "quick-start" introduction with that line -- there's no particular reason people just "trying out" the build should have to scroll through several pages to figure out five default commands. -- Carl Eastlund From eli at barzilay.org Fri May 1 20:36:00 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri May 1 20:36:43 2009 Subject: [plt-dev] in-place build directory (was re: build error with svn 14677) In-Reply-To: <990e0c030905011729u63f1bd64p4d7db9b63dfac59b@mail.gmail.com> References: <990e0c030905011417h6b9f44c6odb431b68e2eea5c@mail.gmail.com> <990e0c030905011434n4c339d8ew90943ed9b9985ede@mail.gmail.com> <18939.32862.224200.550799@winooski.ccs.neu.edu> <990e0c030905011638g21c7d5c6u314d7df70f83e1c9@mail.gmail.com> <18939.36198.292304.565294@winooski.ccs.neu.edu> <2A8447F7-D69E-4D3E-94DC-C9E487F8B6E4@brinckerhoff.org> <18939.37296.812932.367171@winooski.ccs.neu.edu> <990e0c030905011729u63f1bd64p4d7db9b63dfac59b@mail.gmail.com> Message-ID: <18939.38256.869999.472250@winooski.ccs.neu.edu> On May 1, Carl Eastlund wrote: > > I agree that it's nice to have the normal Unix-style build strategy > of "./configure && make && make install" as a default, but in our > system it's not a very good default. The problems come from autoconf and from svn updating a source tree -- so "our system" is wrong here... > We should present a default that is robust in the face of updating > the source and rebuilding. Now, if we want to change our > configure/make scripts to make this possible, that would be nice. How would you do that? The only possiblity is to have `svn update' remove files, and that's not a plt problem. Another solution is to have a `make clean' target that removes all non-svn files, but that's impractical given that the target would be in a makefile that should itself be removed. > In fact, I should really write a "quick-start" introduction with > that line -- there's no particular reason people just "trying out" > the build should have to scroll through several pages to figure out > five default commands. That was my initial thought. Something that would first introduce a build then talk about the details. But I couldn't come to a conclusion of how to actually write this in a short time. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From dvanhorn at ccs.neu.edu Fri May 1 23:17:17 2009 From: dvanhorn at ccs.neu.edu (David Van Horn) Date: Fri May 1 23:17:50 2009 Subject: [plt-dev] Indexing #:keywords Message-ID: <49FBBB3D.602@ccs.neu.edu> I have searched help desk several times for particular keywords but almost nothing is indexed. Should I submit patches as I come across things that should be indexed, or will there be some more systematic way of indexing keywords (eg. all keywords in def*-forms are indexed)? David From geoff at knauth.org Sat May 2 05:30:11 2009 From: geoff at knauth.org (Geoffrey S. Knauth) Date: Sat May 2 05:30:30 2009 Subject: [plt-dev] latest version under Windows In-Reply-To: <20090501165917.E74C16500B2@mail-svr1.cs.utah.edu> References: <20090501165917.E74C16500B2@mail-svr1.cs.utah.edu> Message-ID: On May 1, 2009, at 12:59, Matthew Flatt wrote: > If you use Windows, then after upgrading to the latest in svn (or the > next nightly build), please pay extra attention to whether DrScheme or > other MrEd-based programs consume too much CPU. > > We've seen some problems with DrScheme maxing out a CPU when it should > be idle. The problems happened especially with blocking reads on > network sockets, but similar problems could happen with any GUI > application. The latest changes fix the problem on my machine, but > this > fact of the system is difficult to test. DrScheme did this once on my Mac about a week ago. At the time, I was busy, I wasn't actually using DrScheme, so I shut it down. I'll be more alert and report it next time. I'm currently running revision 14683 (may1). If I recall, the only thing I had done with DrScheme that session was to start it, press F1, look up something in the documentation on Safari, and then move on. Also once in a while Safari (v4 beta 5528.16) starts eating up resources and I shut it down, but that happens when I'm not running DrScheme. From dvanhorn at ccs.neu.edu Sat May 2 15:35:57 2009 From: dvanhorn at ccs.neu.edu (David Van Horn) Date: Sat May 2 15:36:29 2009 Subject: scheme/list requests [was: Re: [plt-dev] Re: more requests for typed-scheme] In-Reply-To: References: <63bb19ae0903162059w7ffb67fbxa46c3f6cf10cafb6@mail.gmail.com> <63bb19ae0903170550g64018bb8v278005f2a91c7c02@mail.gmail.com> Message-ID: <49FCA09D.3000307@ccs.neu.edu> Matthias Felleisen wrote: > Everyone, please find things you find useful in srfi/1 :-) I'd like to see SRFI 1's make-list in scheme/list: (make-list n [fill]) -> list? I vote for it. Sam votes for everything. Matthias sent me code that uses it, so he probably votes for it. Is 2.5 votes enough? David From matthias at ccs.neu.edu Sat May 2 15:50:07 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Sat May 2 15:50:41 2009 Subject: scheme/list requests [was: Re: [plt-dev] Re: more requests for typed-scheme] In-Reply-To: <49FCA09D.3000307@ccs.neu.edu> References: <63bb19ae0903162059w7ffb67fbxa46c3f6cf10cafb6@mail.gmail.com> <63bb19ae0903170550g64018bb8v278005f2a91c7c02@mail.gmail.com> <49FCA09D.3000307@ccs.neu.edu> Message-ID: More than plenty. On May 2, 2009, at 3:35 PM, David Van Horn wrote: > Matthias Felleisen wrote: >> Everyone, please find things you find useful in srfi/1 :-) > > I'd like to see SRFI 1's make-list in scheme/list: > > (make-list n [fill]) -> list? > > I vote for it. Sam votes for everything. Matthias sent me code > that uses it, so he probably votes for it. Is 2.5 votes enough? > > David From jensaxel at soegaard.net Sat May 2 15:45:01 2009 From: jensaxel at soegaard.net (Jens Axel Soegaard) Date: Sat May 2 16:18:41 2009 Subject: scheme/list requests [was: Re: [plt-dev] Re: more requests for typed-scheme] In-Reply-To: <49FCA09D.3000307@ccs.neu.edu> References: <63bb19ae0903162059w7ffb67fbxa46c3f6cf10cafb6@mail.gmail.com> <63bb19ae0903170550g64018bb8v278005f2a91c7c02@mail.gmail.com> <49FCA09D.3000307@ccs.neu.edu> Message-ID: <49FCA2BD.80502@soegaard.net> > Matthias Felleisen wrote: >> Everyone, please find things you find useful in srfi/1 :-) I used span the other day. I know some find the name unfortunate, but I wouldn't mind to write, say, list-span instead of span. -- Jens Axel S?gaard From dvanhorn at ccs.neu.edu Sat May 2 17:22:04 2009 From: dvanhorn at ccs.neu.edu (David Van Horn) Date: Sat May 2 17:22:36 2009 Subject: [plt-dev] range mini benchmark Message-ID: <49FCB97C.7050702@ccs.neu.edu> Here is a benchmark for a few implementations of `range': Nat Nat -> [Listof Nat] (range 0 5) => (list 0 1 2 3 4 5) (range 5 0) => (list 5 4 3 2 1 0) One uses build-list, another uses sequences. I threw in an implementation using an iterative build-list as well. I was surprised the build-list version beat out sequences -- thoroughly, with the iterative build-list being an improvement over the built in recursive one. David $ mzc range-bench.scm $ mzscheme range-bench.scm (for ((j (in-range 5))) (range 0 1000000)) range-rbl: cpu time: 862 real time: 865 gc time: 387 range-ibl: cpu time: 905 real time: 905 gc time: 642 range-seq: cpu time: 2283 real time: 2289 gc time: 1138 (for ((j (in-range 50))) (range 0 100000)) range-rbl: cpu time: 518 real time: 519 gc time: 95 range-ibl: cpu time: 365 real time: 366 gc time: 116 range-seq: cpu time: 1560 real time: 1560 gc time: 443 (for ((j (in-range 500))) (range 0 10000)) range-rbl: cpu time: 357 real time: 358 gc time: 26 range-ibl: cpu time: 267 real time: 281 gc time: 18 range-seq: cpu time: 1153 real time: 1155 gc time: 54 (for ((j (in-range 5000))) (range 0 1000)) range-rbl: cpu time: 339 real time: 339 gc time: 12 range-ibl: cpu time: 258 real time: 258 gc time: 11 range-seq: cpu time: 1126 real time: 1156 gc time: 27 (for ((j (in-range 50000))) (range 0 100)) range-rbl: cpu time: 342 real time: 343 gc time: 9 range-ibl: cpu time: 264 real time: 265 gc time: 11 range-seq: cpu time: 1151 real time: 1151 gc time: 18 -------------- next part -------------- #lang scheme ;; Mini-benchmark for range Nat Nat -> [Listof Nat] ;; (range 0 5) => (list 0 1 2 3 4 5) ;; (range 5 0) => (list 5 4 3 2 1 0) (define (it:build-list i f) (let loop ([i (sub1 i)] [a empty]) (cond [(< i 0) a] [else (loop (sub1 i) (cons (f i) a))]))) ;; using build-list (define (range-rbl lo hi) (if (>= hi lo) (build-list (+ (- hi lo) 1) (lambda (i) (+ lo i))) (build-list (+ (- lo hi) 1) (lambda (i) (- lo i))))) ;; same as above, but with iterative build-list (define (range-ibl lo hi) (if (>= hi lo) (it:build-list (+ (- hi lo) 1) (lambda (i) (+ lo i))) (it:build-list (+ (- lo hi) 1) (lambda (i) (- lo i))))) ;; using sequences (define (range-seq L H) (for/list ((i (if (>= H L) (in-range L (+ H 1)) (in-range L (- H 1) -1)))) i)) (define ranges (list range-rbl range-ibl range-seq)) (define (run j i) (printf "~a~n" `(for ((j (in-range ,j))) (range 0 ,i))) (for-each (lambda (r) (printf "~a: " (object-name r)) (collect-garbage) (time (void (for ((_ (in-range j))) (r 0 i))))) ranges) (newline)) #| (run 5 1000000) (run 50 100000) ... (run 50000 100) |# (for ((i (in-range 5))) (run (* 5 (expt 10 i)) (expt 10 (- 6 i)))) From eli at barzilay.org Sat May 2 18:17:47 2009 From: eli at barzilay.org (Eli Barzilay) Date: Sat May 2 18:18:08 2009 Subject: [plt-dev] range mini benchmark In-Reply-To: <49FCB97C.7050702@ccs.neu.edu> References: <49FCB97C.7050702@ccs.neu.edu> Message-ID: <18940.50827.659405.504355@winooski.ccs.neu.edu> On May 2, David Van Horn wrote: > Here is a benchmark for a few implementations of `range': > > Nat Nat -> [Listof Nat] > (range 0 5) => (list 0 1 2 3 4 5) > (range 5 0) => (list 5 4 3 2 1 0) > > One uses build-list, another uses sequences. I threw in an > implementation using an iterative build-list as well. > > I was surprised the build-list version beat out sequences -- thoroughly, > with the iterative build-list being an improvement over the built in > recursive one. This: (define (range-seq L H) (for/list ((i (if (>= H L) (in-range L (+ H 1)) (in-range L (- H 1) -1)))) i)) forces creating a sequence value, and this: (define (range-seq L H) (for/list ((i (in-range L (+ H 1)))) i)) doesn't, so it is much faster. Also, this kind of test is tricky to measure -- the number that you'd want is the runtime minus the GC time -- but only the GC for the resulting list. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From eli at barzilay.org Sat May 2 18:33:30 2009 From: eli at barzilay.org (Eli Barzilay) Date: Sat May 2 18:34:01 2009 Subject: scheme/list requests [was: Re: [plt-dev] Re: more requests for typed-scheme] In-Reply-To: <49FCA09D.3000307@ccs.neu.edu> References: <63bb19ae0903162059w7ffb67fbxa46c3f6cf10cafb6@mail.gmail.com> <63bb19ae0903170550g64018bb8v278005f2a91c7c02@mail.gmail.com> <49FCA09D.3000307@ccs.neu.edu> <49FCA2BD.80502@soegaard.net> Message-ID: <18940.51770.570928.343918@winooski.ccs.neu.edu> On May 2, David Van Horn wrote: > Matthias Felleisen wrote: > > Everyone, please find things you find useful in srfi/1 :-) > > I'd like to see SRFI 1's make-list in scheme/list: > > (make-list n [fill]) -> list? > > I vote for it. Sam votes for everything. Matthias sent me code > that uses it, so he probably votes for it. Is 2.5 votes enough? I'm voting against it: unlike `make-vector' and `make-string', a `make-list' would return an immutable value, so what would you use it for? (My (unconfirmed) guess is that it wasn't included in r5rs for this reason: mutation is allowed, so adding it would encourage encourage bad code that uses that mutation where a vector is more fitting.) On May 2, Jens Axel Soegaard wrote: > > Matthias Felleisen wrote: > >> Everyone, please find things you find useful in srfi/1 :-) > > I used span the other day. I know some find the name unfortunate, > but I wouldn't mind to write, say, list-span instead of span. Last time I polled for this, I had zero replies. Here it is again: I added `count', and made the `srfi/1' version reprovide it. [...] It'll also be easy to add `take-while' and `drop-while' -- but the others are more problematic, at least IMO: * list-index: does it *have* to have this name? Perhaps we can use a better name? (This already happened -- we have `append*' which Ryan suggested, which is the same as `concatenate' in srfi/1 -- and I think that `append*' makes much more sense). * span, break: these are even worse -- not only are the names vague enough to not tell me what they do, they're names that are very popular in other contexts. It's even two very different contexts, so the potential damage is doubled. (The damage being unexpected names propagating through to packages that already have those names.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From namekuseijin at gmail.com Sat May 2 18:37:20 2009 From: namekuseijin at gmail.com (namekuseijin) Date: Sat May 2 18:38:02 2009 Subject: [plt-dev] range mini benchmark In-Reply-To: <49FCB97C.7050702@ccs.neu.edu> References: <49FCB97C.7050702@ccs.neu.edu> Message-ID: <67d0527e0905021537n46cbdc55na40700bc9ee602ba@mail.gmail.com> Seems to me you're measuring consing. I'm not really a fan of creating intermediary lists, I enjoy iterators more. I have my own version of range, here simplified: ; returns an iterator for given range ; given an initial result and a reducer function, will apply it each iteration (define (range from to) (let ((> (if (> from to) < >)) (+ (if (> from to) - +))) (lambda (res reducer) (let loop ((i from) (r res)) (if (> i to) r (loop (+ i 1) (reducer i r))))))) So, I can: ((range 10 1) '() cons) to create a list from 1 to 10 (cons builds a reverse list) or simply ((range 1 10) 0 +) to sum it up, without creating intermediary lists. or even ((range 1 10) 0 (lambda (i o) (if (odd? i) (+ i o) o))) to sum only the odds. Of course, I have a version of filter to work with iterators. :) I added it to the benchmark by adding a little twist: it now builds a list by consing too. (define (range-nmk from to) (let ((> (if (> from to) < >)) (+ (if (> from to) - +))) ((lambda (res reducer) (let loop ((i from) (r res)) (if (> i to) r (loop (+ i 1) (reducer i r))))) '() cons))) (define ranges (list range-rbl range-ibl range-seq range-nmk)) on DrScheme: (for ((j (in-range 5))) (range 0 1000000)) range-rbl: cpu time: 852 real time: 851 gc time: 332 range-ibl: cpu time: 1332 real time: 1334 gc time: 88 range-seq: cpu time: 1052 real time: 1055 gc time: 212 range-nmk: cpu time: 704 real time: 706 gc time: 80 (for ((j (in-range 50))) (range 0 100000)) range-rbl: cpu time: 588 real time: 585 gc time: 68 range-ibl: cpu time: 1300 real time: 1301 gc time: 20 range-seq: cpu time: 908 real time: 908 gc time: 72 range-nmk: cpu time: 652 real time: 653 gc time: 20 (for ((j (in-range 500))) (range 0 10000)) range-rbl: cpu time: 544 real time: 544 gc time: 28 range-ibl: cpu time: 1300 real time: 1297 gc time: 12 range-seq: cpu time: 864 real time: 863 gc time: 24 range-nmk: cpu time: 644 real time: 644 gc time: 12 (for ((j (in-range 5000))) (range 0 1000)) range-rbl: cpu time: 544 real time: 543 gc time: 20 range-ibl: cpu time: 1300 real time: 1300 gc time: 8 range-seq: cpu time: 864 real time: 864 gc time: 20 range-nmk: cpu time: 648 real time: 645 gc time: 8 (for ((j (in-range 50000))) (range 0 100)) range-rbl: cpu time: 568 real time: 565 gc time: 20 range-ibl: cpu time: 1328 real time: 1328 gc time: 12 range-seq: cpu time: 900 real time: 902 gc time: 20 range-nmk: cpu time: 664 real time: 664 gc time: 12 The pure recursive way beats it, except for a fairly high range. I wonder why... From dvanhorn at ccs.neu.edu Sat May 2 19:15:45 2009 From: dvanhorn at ccs.neu.edu (David Van Horn) Date: Sat May 2 19:16:23 2009 Subject: scheme/list requests [was: Re: [plt-dev] Re: more requests for typed-scheme] In-Reply-To: <18940.51770.570928.343918@winooski.ccs.neu.edu> References: <63bb19ae0903162059w7ffb67fbxa46c3f6cf10cafb6@mail.gmail.com> <63bb19ae0903170550g64018bb8v278005f2a91c7c02@mail.gmail.com> <49FCA09D.3000307@ccs.neu.edu> <49FCA2BD.80502@soegaard.net> <18940.51770.570928.343918@winooski.ccs.neu.edu> Message-ID: <49FCD421.5070003@ccs.neu.edu> Eli Barzilay wrote: > On May 2, David Van Horn wrote: >> Matthias Felleisen wrote: >>> Everyone, please find things you find useful in srfi/1 :-) >> I'd like to see SRFI 1's make-list in scheme/list: >> >> (make-list n [fill]) -> list? >> >> I vote for it. Sam votes for everything. Matthias sent me code >> that uses it, so he probably votes for it. Is 2.5 votes enough? > > I'm voting against it: unlike `make-vector' and `make-string', a > `make-list' would return an immutable value, so what would you use it > for? http://list.cs.brown.edu/pipermail/plt-scheme/2009-March/031342.html http://svn.plt-scheme.org/plt/trunk/collects/redex/private/rg.ss http://svn.plt-scheme.org/plt/trunk/collects/swindle/extra.ss http://svn.plt-scheme.org/plt/trunk/collects/typed-scheme/utils/utils.ss http://svn.plt-scheme.org/plt/trunk/collects/profjWizard/draw-txt0.ss http://svn.plt-scheme.org/plt/trunk/collects/plot/demos/fit-demo-1.ss http://svn.plt-scheme.org/plt/trunk/collects/planet/util.ss http://svn.plt-scheme.org/plt/trunk/collects/htdp/hangman-world.ss http://svn.plt-scheme.org/plt/trunk/collects/games/paint-by-numbers/solve.ss http://svn.plt-scheme.org/plt/trunk/collects/frtime/mzscheme-core.ss http://svn.plt-scheme.org/plt/trunk/collects/frtime/demos/tetris.ss David From eli at barzilay.org Sat May 2 19:20:43 2009 From: eli at barzilay.org (Eli Barzilay) Date: Sat May 2 19:21:20 2009 Subject: scheme/list requests [was: Re: [plt-dev] Re: more requests for typed-scheme] In-Reply-To: <49FCD421.5070003@ccs.neu.edu> References: <63bb19ae0903162059w7ffb67fbxa46c3f6cf10cafb6@mail.gmail.com> <63bb19ae0903170550g64018bb8v278005f2a91c7c02@mail.gmail.com> <49FCA09D.3000307@ccs.neu.edu> <49FCA2BD.80502@soegaard.net> <18940.51770.570928.343918@winooski.ccs.neu.edu> <49FCD421.5070003@ccs.neu.edu> Message-ID: <18940.54603.153899.142777@winooski.ccs.neu.edu> On May 2, David Van Horn wrote: > Eli Barzilay wrote: > > On May 2, David Van Horn wrote: > >> Matthias Felleisen wrote: > >>> Everyone, please find things you find useful in srfi/1 :-) > >> I'd like to see SRFI 1's make-list in scheme/list: > >> > >> (make-list n [fill]) -> list? > >> > >> I vote for it. Sam votes for everything. Matthias sent me code > >> that uses it, so he probably votes for it. Is 2.5 votes enough? > > > > I'm voting against it: unlike `make-vector' and `make-string', a > > `make-list' would return an immutable value, so what would you use it > > for? Can we please use text for answers? I can grep just fine. I don't see any `make-list' on these pages. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From dvanhorn at ccs.neu.edu Sat May 2 19:25:03 2009 From: dvanhorn at ccs.neu.edu (David Van Horn) Date: Sat May 2 19:25:36 2009 Subject: scheme/list requests [was: Re: [plt-dev] Re: more requests for typed-scheme] In-Reply-To: <18940.54603.153899.142777@winooski.ccs.neu.edu> References: <63bb19ae0903162059w7ffb67fbxa46c3f6cf10cafb6@mail.gmail.com> <63bb19ae0903170550g64018bb8v278005f2a91c7c02@mail.gmail.com> <49FCA09D.3000307@ccs.neu.edu> <49FCA2BD.80502@soegaard.net> <18940.51770.570928.343918@winooski.ccs.neu.edu> <49FCD421.5070003@ccs.neu.edu> <18940.54603.153899.142777@winooski.ccs.neu.edu> Message-ID: <49FCD64F.8000606@ccs.neu.edu> Eli Barzilay wrote: > On May 2, David Van Horn wrote: >> Eli Barzilay wrote: >>> On May 2, David Van Horn wrote: >>>> Matthias Felleisen wrote: >>>>> Everyone, please find things you find useful in srfi/1 :-) >>>> I'd like to see SRFI 1's make-list in scheme/list: >>>> >>>> (make-list n [fill]) -> list? >>>> >>>> I vote for it. Sam votes for everything. Matthias sent me code >>>> that uses it, so he probably votes for it. Is 2.5 votes enough? >>> I'm voting against it: unlike `make-vector' and `make-string', a >>> `make-list' would return an immutable value, so what would you use it >>> for? > > Can we please use text for answers? I can grep just fine. Sorry. > I don't see any `make-list' on these pages. No, but that's because there is no make-list, so it is written: (let ((v e)) (build-list n (lambda (i) v))) David From eli at barzilay.org Sat May 2 19:26:49 2009 From: eli at barzilay.org (Eli Barzilay) Date: Sat May 2 19:27:11 2009 Subject: scheme/list requests [was: Re: [plt-dev] Re: more requests for typed-scheme] In-Reply-To: <49FCD64F.8000606@ccs.neu.edu> References: <63bb19ae0903162059w7ffb67fbxa46c3f6cf10cafb6@mail.gmail.com> <63bb19ae0903170550g64018bb8v278005f2a91c7c02@mail.gmail.com> <49FCA09D.3000307@ccs.neu.edu> <49FCA2BD.80502@soegaard.net> <18940.51770.570928.343918@winooski.ccs.neu.edu> <49FCD421.5070003@ccs.neu.edu> <18940.54603.153899.142777@winooski.ccs.neu.edu> <49FCD64F.8000606@ccs.neu.edu> Message-ID: <18940.54969.730749.404107@winooski.ccs.neu.edu> On May 2, David Van Horn wrote: > Eli Barzilay wrote: > > I don't see any `make-list' on these pages. > > No, but that's because there is no make-list, so it is written: > > (let ((v e)) > (build-list n (lambda (i) v))) Yes, I know. Yet these are still a minority where `build-list' does fine -- specifically (a) none of these pieces of code had a separate abstraction for `make-list' (b) the confusion re its utility and immutability of lists is still there. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From matthias at ccs.neu.edu Sat May 2 19:41:57 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Sat May 2 19:42:30 2009 Subject: scheme/list requests [was: Re: [plt-dev] Re: more requests for typed-scheme] In-Reply-To: <18940.54969.730749.404107@winooski.ccs.neu.edu> References: <63bb19ae0903162059w7ffb67fbxa46c3f6cf10cafb6@mail.gmail.com> <63bb19ae0903170550g64018bb8v278005f2a91c7c02@mail.gmail.com> <49FCA09D.3000307@ccs.neu.edu> <49FCA2BD.80502@soegaard.net> <18940.51770.570928.343918@winooski.ccs.neu.edu> <49FCD421.5070003@ccs.neu.edu> <18940.54603.153899.142777@winooski.ccs.neu.edu> <49FCD64F.8000606@ccs.neu.edu> <18940.54969.730749.404107@winooski.ccs.neu.edu> Message-ID: <9433C91B-9962-46F5-AC3D-693F18917420@ccs.neu.edu> I have used make-list on occasion, e.g., (make-list 10 #\space) while I am manipulating strings as lists of chars. I think it's worth including in typed scheme. From eli at barzilay.org Sat May 2 19:43:31 2009 From: eli at barzilay.org (Eli Barzilay) Date: Sat May 2 19:43:57 2009 Subject: scheme/list requests [was: Re: [plt-dev] Re: more requests for typed-scheme] In-Reply-To: <9433C91B-9962-46F5-AC3D-693F18917420@ccs.neu.edu> References: <63bb19ae0903162059w7ffb67fbxa46c3f6cf10cafb6@mail.gmail.com> <63bb19ae0903170550g64018bb8v278005f2a91c7c02@mail.gmail.com> <49FCA09D.3000307@ccs.neu.edu> <49FCA2BD.80502@soegaard.net> <18940.51770.570928.343918@winooski.ccs.neu.edu> <49FCD421.5070003@ccs.neu.edu> <18940.54603.153899.142777@winooski.ccs.neu.edu> <49FCD64F.8000606@ccs.neu.edu> <18940.54969.730749.404107@winooski.ccs.neu.edu> <9433C91B-9962-46F5-AC3D-693F18917420@ccs.neu.edu> Message-ID: <18940.55971.576768.812068@winooski.ccs.neu.edu> On May 2, Matthias Felleisen wrote: > > I have used make-list on occasion, e.g., > > (make-list 10 #\space) > > while I am manipulating strings as lists of chars. And that would be just like (string->list (make-string 10 #\space)). -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From eli at barzilay.org Sat May 2 19:47:42 2009 From: eli at barzilay.org (Eli Barzilay) Date: Sat May 2 19:48:03 2009 Subject: scheme/list requests [was: Re: [plt-dev] Re: more requests for typed-scheme] In-Reply-To: <18940.55971.576768.812068@winooski.ccs.neu.edu> References: <63bb19ae0903162059w7ffb67fbxa46c3f6cf10cafb6@mail.gmail.com> <63bb19ae0903170550g64018bb8v278005f2a91c7c02@mail.gmail.com> <49FCA09D.3000307@ccs.neu.edu> <49FCA2BD.80502@soegaard.net> <18940.51770.570928.343918@winooski.ccs.neu.edu> <49FCD421.5070003@ccs.neu.edu> <18940.54603.153899.142777@winooski.ccs.neu.edu> <49FCD64F.8000606@ccs.neu.edu> <18940.54969.730749.404107@winooski.ccs.neu.edu> <9433C91B-9962-46F5-AC3D-693F18917420@ccs.neu.edu> <18940.55971.576768.812068@winooski.ccs.neu.edu> Message-ID: <18940.56222.153845.630435@winooski.ccs.neu.edu> This is from the rrrs-authors list (from Will): Non-controversial #1: I object to make-list, list-fill!, list-set!, and list-copy on the grounds that they are useful only for side-effect-full programming on lists, which I claim is an unusual style that the standard should not encourage. The corresponding procedures for strings and vectors are less objectionable because side-effect-full programming on strings and vectors is normal in Scheme. [...] -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From namekuseijin at gmail.com Sat May 2 19:47:49 2009 From: namekuseijin at gmail.com (namekuseijin) Date: Sat May 2 19:48:39 2009 Subject: [plt-dev] range mini benchmark In-Reply-To: <67d0527e0905021537n46cbdc55na40700bc9ee602ba@mail.gmail.com> References: <49FCB97C.7050702@ccs.neu.edu> <67d0527e0905021537n46cbdc55na40700bc9ee602ba@mail.gmail.com> Message-ID: <67d0527e0905021647x7266783bk5c6d034dcd7ca55@mail.gmail.com> On Sat, May 2, 2009 at 7:37 PM, namekuseijin wrote: > Seems to me you're measuring consing. ?I'm not really a fan of > creating intermediary lists, I enjoy iterators more. ?I have my own > version of range, here simplified: > > ; returns an iterator for given range > ; ?given an initial result and a reducer function, will apply it each iteration > (define (range from to) > ?(let ((> (if (> from to) < >)) > ? ? ? ?(+ (if (> from to) - +))) > ? ?(lambda (res reducer) > ? ? ?(let loop ((i from) (r res)) > ? ? ? ?(if (> i to) r > ? ? ? ? ? ?(loop (+ i 1) (reducer i r))))))) > > So, I can: > ((range 10 1) '() cons) > to create a list from 1 to 10 (cons builds a reverse list) > > or simply > ((range 1 10) 0 +) > to sum it up, without creating intermediary lists. > > or even > ((range 1 10) 0 (lambda (i o) (if (odd? i) (+ i o) o))) > to sum only the odds. ?Of course, I have a version of filter to work > with iterators. :) > > I added it to the benchmark by adding a little twist: ?it now builds a > list by consing too. > > (define (range-nmk from to) > ?(let ((> (if (> from to) < >)) > ? ? ? ?(+ (if (> from to) - +))) > ? ?((lambda (res reducer) > ? ? ?(let loop ((i from) (r res)) > ? ? ? ?(if (> i to) r > ? ? ? ? ? ?(loop (+ i 1) (reducer i r))))) '() cons))) > > > (define ranges (list range-rbl range-ibl range-seq range-nmk)) > > on DrScheme: > (for ((j (in-range 5))) (range 0 1000000)) > range-rbl: cpu time: 852 real time: 851 gc time: 332 > range-ibl: cpu time: 1332 real time: 1334 gc time: 88 > range-seq: cpu time: 1052 real time: 1055 gc time: 212 > range-nmk: cpu time: 704 real time: 706 gc time: 80 > > (for ((j (in-range 50))) (range 0 100000)) > range-rbl: cpu time: 588 real time: 585 gc time: 68 > range-ibl: cpu time: 1300 real time: 1301 gc time: 20 > range-seq: cpu time: 908 real time: 908 gc time: 72 > range-nmk: cpu time: 652 real time: 653 gc time: 20 > > (for ((j (in-range 500))) (range 0 10000)) > range-rbl: cpu time: 544 real time: 544 gc time: 28 > range-ibl: cpu time: 1300 real time: 1297 gc time: 12 > range-seq: cpu time: 864 real time: 863 gc time: 24 > range-nmk: cpu time: 644 real time: 644 gc time: 12 > > (for ((j (in-range 5000))) (range 0 1000)) > range-rbl: cpu time: 544 real time: 543 gc time: 20 > range-ibl: cpu time: 1300 real time: 1300 gc time: 8 > range-seq: cpu time: 864 real time: 864 gc time: 20 > range-nmk: cpu time: 648 real time: 645 gc time: 8 > > (for ((j (in-range 50000))) (range 0 100)) > range-rbl: cpu time: 568 real time: 565 gc time: 20 > range-ibl: cpu time: 1328 real time: 1328 gc time: 12 > range-seq: cpu time: 900 real time: 902 gc time: 20 > range-nmk: cpu time: 664 real time: 664 gc time: 12 > > The pure recursive way beats it, except for a fairly high range. ?I > wonder why... > heh, should not have benchmarked it while on DrScheme environment: namekuseijin@nameku:~/dev/scheme$ mzc range-bench.scm namekuseijin@nameku:~/dev/scheme$ mzscheme range-bench.scm (for ((j (in-range 5))) (range 0 1000000)) range-rbl: cpu time: 728 real time: 732 gc time: 452 range-ibl: cpu time: 416 real time: 424 gc time: 236 range-seq: cpu time: 1224 real time: 1285 gc time: 440 range-nmk: cpu time: 488 real time: 503 gc time: 236 (for ((j (in-range 50))) (range 0 100000)) range-rbl: cpu time: 456 real time: 458 gc time: 196 range-ibl: cpu time: 204 real time: 207 gc time: 40 range-seq: cpu time: 952 real time: 1016 gc time: 180 range-nmk: cpu time: 292 real time: 303 gc time: 36 (for ((j (in-range 500))) (range 0 10000)) range-rbl: cpu time: 284 real time: 285 gc time: 32 range-ibl: cpu time: 180 real time: 181 gc time: 8 range-seq: cpu time: 804 real time: 851 gc time: 28 range-nmk: cpu time: 260 real time: 271 gc time: 12 (for ((j (in-range 5000))) (range 0 1000)) range-rbl: cpu time: 268 real time: 269 gc time: 12 range-ibl: cpu time: 176 real time: 176 gc time: 8 range-seq: cpu time: 836 real time: 836 gc time: 8 range-nmk: cpu time: 268 real time: 265 gc time: 4 (for ((j (in-range 50000))) (range 0 100)) range-rbl: cpu time: 276 real time: 274 gc time: 8 range-ibl: cpu time: 180 real time: 181 gc time: 4 range-seq: cpu time: 856 real time: 858 gc time: 20 range-nmk: cpu time: 272 real time: 271 gc time: 8 What's the cause of so much difference? Going through mzscheme, the manually named-let-written build-list really beats the socks of builtin build-list! From matthias at ccs.neu.edu Sat May 2 19:48:22 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Sat May 2 19:49:03 2009 Subject: scheme/list requests [was: Re: [plt-dev] Re: more requests for typed-scheme] In-Reply-To: <18940.55971.576768.812068@winooski.ccs.neu.edu> References: <63bb19ae0903162059w7ffb67fbxa46c3f6cf10cafb6@mail.gmail.com> <63bb19ae0903170550g64018bb8v278005f2a91c7c02@mail.gmail.com> <49FCA09D.3000307@ccs.neu.edu> <49FCA2BD.80502@soegaard.net> <18940.51770.570928.343918@winooski.ccs.neu.edu> <49FCD421.5070003@ccs.neu.edu> <18940.54603.153899.142777@winooski.ccs.neu.edu> <49FCD64F.8000606@ccs.neu.edu> <18940.54969.730749.404107@winooski.ccs.neu.edu> <9433C91B-9962-46F5-AC3D-693F18917420@ccs.neu.edu> <18940.55971.576768.812068@winooski.ccs.neu.edu> Message-ID: Very unhelpful On May 2, 2009, at 7:43 PM, Eli Barzilay wrote: > On May 2, Matthias Felleisen wrote: >> >> I have used make-list on occasion, e.g., >> >> (make-list 10 #\space) >> >> while I am manipulating strings as lists of chars. > > And that would be just like (string->list (make-string 10 #\space)). > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli > Barzilay: > http://www.barzilay.org/ Maze is > Life! From samth at ccs.neu.edu Sat May 2 19:55:49 2009 From: samth at ccs.neu.edu (Sam TH) Date: Sat May 2 19:56:08 2009 Subject: scheme/list requests [was: Re: [plt-dev] Re: more requests for typed-scheme] In-Reply-To: <18940.54969.730749.404107@winooski.ccs.neu.edu> References: <63bb19ae0903170550g64018bb8v278005f2a91c7c02@mail.gmail.com> <49FCA09D.3000307@ccs.neu.edu> <49FCA2BD.80502@soegaard.net> <18940.51770.570928.343918@winooski.ccs.neu.edu> <49FCD421.5070003@ccs.neu.edu> <18940.54603.153899.142777@winooski.ccs.neu.edu> <49FCD64F.8000606@ccs.neu.edu> <18940.54969.730749.404107@winooski.ccs.neu.edu> Message-ID: <63bb19ae0905021655s3b36fe8bxa398c9d363b9b5ac@mail.gmail.com> On Sat, May 2, 2009 at 7:26 PM, Eli Barzilay wrote: > On May ?2, David Van Horn wrote: >> Eli Barzilay wrote: >> > I don't see any `make-list' on these pages. >> >> No, but that's because there is no make-list, so it is written: >> >> (let ((v e)) >> ? ?(build-list n (lambda (i) v))) > > Yes, I know. ?Yet these are still a minority where `build-list' does > fine -- specifically (a) none of these pieces of code had a separate > abstraction for `make-list' (b) the confusion re its utility and > immutability of lists is still there. As to (a), that doesn't tell us anything about whether it would be useful. No one had written `for/list' before Matthew did, but it's very useful. As to (b), I don't think anyone will be confused about whether the resulting list is mutable, since lists are all immutable. When we have a function that we can easily add to a library, and that would simplify multiple pieces of code we write, we should add it. I don't see why there's a debate about this. -- sam th samth@ccs.neu.edu From eli at barzilay.org Sat May 2 20:16:00 2009 From: eli at barzilay.org (Eli Barzilay) Date: Sat May 2 20:16:20 2009 Subject: scheme/list requests [was: Re: [plt-dev] Re: more requests for typed-scheme] In-Reply-To: <63bb19ae0905021655s3b36fe8bxa398c9d363b9b5ac@mail.gmail.com> References: <63bb19ae0903170550g64018bb8v278005f2a91c7c02@mail.gmail.com> <49FCA09D.3000307@ccs.neu.edu> <49FCA2BD.80502@soegaard.net> <18940.51770.570928.343918@winooski.ccs.neu.edu> <49FCD421.5070003@ccs.neu.edu> <18940.54603.153899.142777@winooski.ccs.neu.edu> <49FCD64F.8000606@ccs.neu.edu> <18940.54969.730749.404107@winooski.ccs.neu.edu> <63bb19ae0905021655s3b36fe8bxa398c9d363b9b5ac@mail.gmail.com> Message-ID: <18940.57920.125005.572556@winooski.ccs.neu.edu> On May 2, Sam TH wrote: > On Sat, May 2, 2009 at 7:26 PM, Eli Barzilay wrote: > > > > Yes, I know. ?Yet these are still a minority where `build-list' > > does fine -- specifically (a) none of these pieces of code had a > > separate abstraction for `make-list' (b) the confusion re its > > utility and immutability of lists is still there. > > As to (a), that doesn't tell us anything about whether it would be > useful. No one had written `for/list' before Matthew did, but it's > very useful. Of course people wrote that -- many times, to varying degrees of completeness. > When we have a function that we can easily add to a library, and > that would simplify multiple pieces of code we write, we should add > it. I don't see why there's a debate about this. There are orders of magnitude more functions that fall in this category and are not added to the libraries, so there is obviously a debate. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From jsw at wilsonjc.us Sat May 2 21:31:54 2009 From: jsw at wilsonjc.us (Jon Wilson) Date: Sat May 2 21:35:38 2009 Subject: [plt-dev] graphics/turtles minor patch -- second try Message-ID: <49FCF40A.20205@wilsonjc.us> The patch adds a function (home) which takes us back to only one turtle, and puts that turtle back at the starting position. Just like clear, but does not clear the screen. Attached. This (third) patch is correct, I think. Sorry eli for the triple post. Regards, Jon Wilson -------------- next part -------------- --- /usr/lib/plt/collects/graphics/turtle-unit.ss 2008-11-16 14:34:52.000000000 -0500 +++ turtle-unit.ss 2009-05-02 11:04:58.000000000 -0400 @@ -227,6 +227,13 @@ (set! lines-in-drawing null) (clear-window))) +(define home + (lambda () + (flip-icons) + (set! turtles-cache empty-cache) + (set! turtles-state (list clear-turtle)) + (flip-icons))) + ;; cache elements: (define-struct c-forward (distance)) (define-struct c-turn (angle)) --- /usr/lib/plt/collects/graphics/turtle-sig.ss 2008-11-16 14:34:52.000000000 -0500 +++ turtle-sig.ss 2009-05-02 10:52:23.000000000 -0400 @@ -1,7 +1,7 @@ #lang scheme/signature turtles -clear +clear home turn turn/radians move move-offset draw draw-offset From jos.koot at telefonica.net Sun May 3 08:24:30 2009 From: jos.koot at telefonica.net (Jos Koot) Date: Sun May 3 08:24:45 2009 Subject: [plt-dev] compose Message-ID: <76DDE6F14AB8481498F0F2BAC4D52400@uw2b2dff239c4d> (compose) --> error, procedure compose: no clause matching 0 arguments Why not (compose) --> # ? The docs of DrScheme, version 4.1.5.5-svn2may2009 [3m] say: (compose proc ...) ? procedure? proc : procedure? This suggests that compose can be applied without actual arguments. The docs do not specify what happens in this case. I propose: 1: adding one more case-lambda clause to the definition of compose: (() values) 2: adding "(compose) --> procedure values" in the docs. Jos -------------- next part -------------- An HTML attachment was scrubbed... URL: http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090503/e0488781/attachment.htm From mflatt at cs.utah.edu Sun May 3 10:54:59 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Sun May 3 10:55:32 2009 Subject: scheme/list requests [was: Re: [plt-dev] Re: more requests for typed-scheme] In-Reply-To: <18940.57920.125005.572556@winooski.ccs.neu.edu> References: <63bb19ae0903170550g64018bb8v278005f2a91c7c02@mail.gmail.com> <49FCA09D.3000307@ccs.neu.edu> <49FCA2BD.80502@soegaard.net> <18940.51770.570928.343918@winooski.ccs.neu.edu> <49FCD421.5070003@ccs.neu.edu> <18940.54603.153899.142777@winooski.ccs.neu.edu> <49FCD64F.8000606@ccs.neu.edu> <18940.54969.730749.404107@winooski.ccs.neu.edu> <63bb19ae0905021655s3b36fe8bxa398c9d363b9b5ac@mail.gmail.com> <18940.57920.125005.572556@winooski.ccs.neu.edu> Message-ID: <20090503145501.43F406500D4@mail-svr1.cs.utah.edu> At Sat, 2 May 2009 19:47:42 -0400, Eli Barzilay wrote: > This is from the rrrs-authors list (from Will): > > Non-controversial #1: > I object to make-list, list-fill!, list-set!, and list-copy on the > grounds that they are useful only for side-effect-full programming on > lists, which I claim is an unusual style that the standard should not > encourage. The corresponding procedures for strings and vectors are > less objectionable because side-effect-full programming on strings > and vectors is normal in Scheme. [...] It turns out that Will was wrong with respect to `make-list', since David found lots of good functional uses of `make-list'. At Sat, 2 May 2009 20:16:00 -0400, Eli Barzilay wrote: > > When we have a function that we can easily add to a library, and > > that would simplify multiple pieces of code we write, we should add > > it. I don't see why there's a debate about this. > > There are orders of magnitude more functions that fall in this > category and are not added to the libraries, so there is obviously a > debate. Yes, there should be a debate, since the cost of each function is more code, more tests, and more documentation. I lean on the side of inclusion. It's used more in our own sources than I would have guessed, and adding it would be more consistent with the other `make-' functions. From eli at barzilay.org Sun May 3 12:22:22 2009 From: eli at barzilay.org (Eli Barzilay) Date: Sun May 3 12:22:58 2009 Subject: scheme/list requests [was: Re: [plt-dev] Re: more requests for typed-scheme] In-Reply-To: <20090503145501.43F406500D4@mail-svr1.cs.utah.edu> References: <63bb19ae0903170550g64018bb8v278005f2a91c7c02@mail.gmail.com> <49FCA09D.3000307@ccs.neu.edu> <49FCA2BD.80502@soegaard.net> <18940.51770.570928.343918@winooski.ccs.neu.edu> <49FCD421.5070003@ccs.neu.edu> <18940.54603.153899.142777@winooski.ccs.neu.edu> <49FCD64F.8000606@ccs.neu.edu> <18940.54969.730749.404107@winooski.ccs.neu.edu> <63bb19ae0905021655s3b36fe8bxa398c9d363b9b5ac@mail.gmail.com> <18940.57920.125005.572556@winooski.ccs.neu.edu> <20090503145501.43F406500D4@mail-svr1.cs.utah.edu> Message-ID: <18941.50366.284173.432163@winooski.ccs.neu.edu> On May 3, Matthew Flatt wrote: > > I lean on the side of inclusion. It's used more in our own sources > than I would have guessed, and adding it would be more consistent > with the other `make-' functions. OK, I give up. I committed `make-list', and added `const' too (to scheme/function). -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From eli at barzilay.org Sun May 3 16:42:13 2009 From: eli at barzilay.org (Eli Barzilay) Date: Sun May 3 16:42:37 2009 Subject: [plt-dev] compose In-Reply-To: <76DDE6F14AB8481498F0F2BAC4D52400@uw2b2dff239c4d> References: <76DDE6F14AB8481498F0F2BAC4D52400@uw2b2dff239c4d> Message-ID: <18942.421.857111.274997@winooski.ccs.neu.edu> On May 3, Jos Koot wrote: > (compose) --> error, procedure compose: no clause matching 0 arguments > Why not (compose) --> # ? > > The docs of DrScheme, version 4.1.5.5-svn2may2009 [3m] say: > > (compose proc ...) ? procedure? > proc : procedure? > > This suggests that compose can be applied without actual arguments. > The docs do not specify what happens in this case. I committed that in svn. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From eli at barzilay.org Sun May 3 16:46:02 2009 From: eli at barzilay.org (Eli Barzilay) Date: Sun May 3 16:46:22 2009 Subject: [plt-dev] graphics/turtles minor patch -- second try In-Reply-To: <49FCF40A.20205@wilsonjc.us> References: <49FCF40A.20205@wilsonjc.us> Message-ID: <18942.650.326234.805104@winooski.ccs.neu.edu> On May 2, Jon Wilson wrote: > The patch adds a function (home) which takes us back to only one turtle, > and puts that turtle back at the starting position. Just like clear, > but does not clear the screen. Committed in svn. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From carl.eastlund at gmail.com Sun May 3 18:07:20 2009 From: carl.eastlund at gmail.com (Carl Eastlund) Date: Sun May 3 18:07:37 2009 Subject: scheme/list requests [was: Re: [plt-dev] Re: more requests for typed-scheme] In-Reply-To: <18941.50366.284173.432163@winooski.ccs.neu.edu> References: <18940.51770.570928.343918@winooski.ccs.neu.edu> <49FCD421.5070003@ccs.neu.edu> <18940.54603.153899.142777@winooski.ccs.neu.edu> <49FCD64F.8000606@ccs.neu.edu> <18940.54969.730749.404107@winooski.ccs.neu.edu> <63bb19ae0905021655s3b36fe8bxa398c9d363b9b5ac@mail.gmail.com> <18940.57920.125005.572556@winooski.ccs.neu.edu> <20090503145501.43F406500D4@mail-svr1.cs.utah.edu> <18941.50366.284173.432163@winooski.ccs.neu.edu> Message-ID: <990e0c030905031507vb610c38k9f60bcf4bed67eea@mail.gmail.com> On Sun, May 3, 2009 at 12:22 PM, Eli Barzilay wrote: > On May ?3, Matthew Flatt wrote: >> >> I lean on the side of inclusion. It's used more in our own sources >> than I would have guessed, and adding it would be more consistent >> with the other `make-' functions. > > OK, I give up. ?I committed `make-list', and added `const' too (to > scheme/function). Eli, any objection to this diff, making const's result into a keyword-accepting (and ignoring) function? Index: function.ss =================================================================== --- function.ss (revision 14699) +++ function.ss (working copy) @@ -4,7 +4,7 @@ (define (const c) (define (const . _) c) - const) + (make-keyword-procedure const const)) (define (negate f) (unless (procedure? f) (raise-type-error 'negate "procedure" f)) From eli at barzilay.org Sun May 3 18:09:52 2009 From: eli at barzilay.org (Eli Barzilay) Date: Sun May 3 18:10:18 2009 Subject: scheme/list requests [was: Re: [plt-dev] Re: more requests for typed-scheme] In-Reply-To: <990e0c030905031507vb610c38k9f60bcf4bed67eea@mail.gmail.com> References: <18940.51770.570928.343918@winooski.ccs.neu.edu> <49FCD421.5070003@ccs.neu.edu> <18940.54603.153899.142777@winooski.ccs.neu.edu> <49FCD64F.8000606@ccs.neu.edu> <18940.54969.730749.404107@winooski.ccs.neu.edu> <63bb19ae0905021655s3b36fe8bxa398c9d363b9b5ac@mail.gmail.com> <18940.57920.125005.572556@winooski.ccs.neu.edu> <20090503145501.43F406500D4@mail-svr1.cs.utah.edu> <18941.50366.284173.432163@winooski.ccs.neu.edu> <990e0c030905031507vb610c38k9f60bcf4bed67eea@mail.gmail.com> Message-ID: <18942.5680.269711.900095@winooski.ccs.neu.edu> On May 3, Carl Eastlund wrote: > > Eli, any objection to this diff, making const's result into a > keyword-accepting (and ignoring) function? Of course not... I planned on doing that, but with the testing and the doc-ing I forgot. Committed now. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From jos.koot at telefonica.net Mon May 4 02:32:19 2009 From: jos.koot at telefonica.net (Jos Koot) Date: Mon May 4 02:32:42 2009 Subject: [plt-dev] compose References: <76DDE6F14AB8481498F0F2BAC4D52400@uw2b2dff239c4d> <18942.421.857111.274997@winooski.ccs.neu.edu> Message-ID: <161DE4A282664DDF82C33496BA2D5E2E@uw2b2dff239c4d> Thanks very much, Jos ----- Original Message ----- From: "Eli Barzilay" To: "Jos Koot" Cc: Sent: Sunday, May 03, 2009 10:42 PM Subject: Re: [plt-dev] compose > On May 3, Jos Koot wrote: >> (compose) --> error, procedure compose: no clause matching 0 arguments >> Why not (compose) --> # ? >> >> The docs of DrScheme, version 4.1.5.5-svn2may2009 [3m] say: >> >> (compose proc ...) ? procedure? >> proc : procedure? >> >> This suggests that compose can be applied without actual arguments. >> The docs do not specify what happens in this case. > > I committed that in svn. > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > http://www.barzilay.org/ Maze is Life! > From neil at neilvandyke.org Tue May 5 05:43:57 2009 From: neil at neilvandyke.org (Neil Van Dyke) Date: Tue May 5 05:44:18 2009 Subject: [plt-dev] SICP and HtDP Message-ID: <4A000A5D.9000202@neilvandyke.org> If anyone has any comments on the way the Introduction of the below document refers to PLT, HtDP, or SICP, please let me know. http://www.neilvandyke.org/sicp-plt/ I'm especially wondering where people using DrScheme for SICP should be directed for support questions. I think that, by default, some people will end up emailing their questions to the "plt-scheme" list or to me, unless the documentation strongly directs those people elsewhere. I will also bounce the text off SICP people, once the software has been tested and is ready for them to look at. Thanks, Neil -- http://www.neilvandyke.org/ From carl.eastlund at gmail.com Tue May 5 09:20:23 2009 From: carl.eastlund at gmail.com (Carl Eastlund) Date: Tue May 5 09:20:42 2009 Subject: [plt-dev] in-place build directory (was re: build error with svn 14677) In-Reply-To: <18939.38256.869999.472250@winooski.ccs.neu.edu> References: <990e0c030905011417h6b9f44c6odb431b68e2eea5c@mail.gmail.com> <990e0c030905011434n4c339d8ew90943ed9b9985ede@mail.gmail.com> <18939.32862.224200.550799@winooski.ccs.neu.edu> <990e0c030905011638g21c7d5c6u314d7df70f83e1c9@mail.gmail.com> <18939.36198.292304.565294@winooski.ccs.neu.edu> <2A8447F7-D69E-4D3E-94DC-C9E487F8B6E4@brinckerhoff.org> <18939.37296.812932.367171@winooski.ccs.neu.edu> <990e0c030905011729u63f1bd64p4d7db9b63dfac59b@mail.gmail.com> <18939.38256.869999.472250@winooski.ccs.neu.edu> Message-ID: <990e0c030905050620i4fabc145y2d4c9b31b6b2a17b@mail.gmail.com> On Fri, May 1, 2009 at 8:36 PM, Eli Barzilay wrote: >> In fact, I should really write a "quick-start" introduction with >> that line -- there's no particular reason people just "trying out" >> the build should have to scroll through several pages to figure out >> five default commands. > > That was my initial thought. ?Something that would first introduce a > build then talk about the details. ?But I couldn't come to a > conclusion of how to actually write this in a short time. I have checked in a revision to the README file (actually 3, but the first 2 are just fixes to pre-existing typos). I have updated your Quick Instructions to describe the "build" directory convention and what the result of the "quick install" is. I have added a step 1 for choosing a build directory, adapting the discussion from the old step 1, and changed the old steps 1,2,3 to 2,3,4. Here are the changed portions of the text (the quick instructions, the new step 1, and the beginning of step 2 [old step 1]): -------------------- Quick instructions: From this directory (where the `README' and `configure' files are), run the following commands: mkdir build cd build ../configure make make install This will create an in-place installation of PLT Scheme and store the results of C/C++ compilation in a separate `build' subdirectory, which is useful if you need to update your sources, delete the build, and start from scratch. You can also run the typical `./configure && make && make install' if you don't anticipate updating/rebuilding, but it will be harder to restart from scratch should you need to. -------------------- 1. Select (or create) a build directory. It's better to run the build in a directory other than the one containing `configure', especially if you're getting sources via Subversion. A common way to start a Subversion-based build is: cd [here] mkdir build cd build where "[here]" is the directory containing this `README' file and the `configure' script. The Subversion repository is configured to support this convention by ignoring `build' in this directory. A separate build directory is better in case the Makefile organization changes, or in case the Makefiles lack some dependencies. In those cases, when using a "build" subdirectory, you can just delete and re-create "build" without mangling your source tree. 2. From your build directory, run the script `configure' (which is in the same directory as this README), with optional command-line arguments --prefix=TARGETDIR or --enable-shared (or both). For example, if you want to install into /usr/local/plt using dynamic libraries, then run: [here]configure --prefix=/usr/local/plt --enable-shared Again, "[here]" is the directory path containing the `configure' script. If you follow the convention of running from a "build" subdirectory, "[here]" is just "../". If you build from the current directory, "[here]" is possibly unnecessary, or possibly just "./", depending on your shell and PATH setting. -------------------- After that it resumes with discussion of the --prefix flag, and continues as before except for step re-numbering. -- Carl Eastlund From eli at barzilay.org Tue May 5 10:03:38 2009 From: eli at barzilay.org (Eli Barzilay) Date: Tue May 5 10:04:07 2009 Subject: [plt-dev] in-place build directory (was re: build error with svn 14677) In-Reply-To: <990e0c030905050620i4fabc145y2d4c9b31b6b2a17b@mail.gmail.com> References: <990e0c030905011417h6b9f44c6odb431b68e2eea5c@mail.gmail.com> <990e0c030905011434n4c339d8ew90943ed9b9985ede@mail.gmail.com> <18939.32862.224200.550799@winooski.ccs.neu.edu> <990e0c030905011638g21c7d5c6u314d7df70f83e1c9@mail.gmail.com> <18939.36198.292304.565294@winooski.ccs.neu.edu> <2A8447F7-D69E-4D3E-94DC-C9E487F8B6E4@brinckerhoff.org> <18939.37296.812932.367171@winooski.ccs.neu.edu> <990e0c030905011729u63f1bd64p4d7db9b63dfac59b@mail.gmail.com> <18939.38256.869999.472250@winooski.ccs.neu.edu> <990e0c030905050620i4fabc145y2d4c9b31b6b2a17b@mail.gmail.com> Message-ID: <18944.18234.69107.135590@winooski.ccs.neu.edu> On May 5, Carl Eastlund wrote: > On Fri, May 1, 2009 at 8:36 PM, Eli Barzilay wrote: > > > > That was my initial thought. ?Something that would first introduce > > a build then talk about the details. ?But I couldn't come to a > > conclusion of how to actually write this in a short time. > > I have checked in a revision to the README file (actually 3, but the > first 2 are just fixes to pre-existing typos). I have updated your > Quick Instructions to describe the "build" directory convention and > what the result of the "quick install" is. [...] FWIW, this was Matthew's recent edit of the file (following this discussion I assume). I liked the way it was layed out such that a quick glimpse through the readme file makes the usual sequence obvious. People who update from svn should read just a little more, and the build instructions were very close after that part. (In any case, I'll leave it to Matthew to see if he wants any more editing...) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From matthias at ccs.neu.edu Tue May 5 10:03:17 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Tue May 5 10:07:51 2009 Subject: [plt-dev] SICP and HtDP In-Reply-To: <4A000A5D.9000202@neilvandyke.org> References: <4A000A5D.9000202@neilvandyke.org> Message-ID: <68F12E3C-1DDB-4882-9B0E-E98655EA4CDD@ccs.neu.edu> On May 5, 2009, at 5:43 AM, Neil Van Dyke wrote: > If anyone has any comments on the way the Introduction of the below > document refers to PLT, HtDP, or SICP, please let me know. > > http://www.neilvandyke.org/sicp-plt/ Perfect. > I'm especially wondering where people using DrScheme for SICP > should be directed for support questions. I think that, by > default, some people will end up emailing their questions to the > "plt-scheme" list or to me, unless the documentation strongly > directs those people elsewhere. I think we should direct people to plt-scheme for general Scheme questions and questions concerning the package (and its faithfulness to SICP). That way you don't have to answer everything. For SICP content question, they should, well, I don't know. MIT has killed SICP and Scheme (kill-scheme-kill). > I will also bounce the text off SICP people, once the software has > been tested and is ready for them to look at. They may wish to say whether they have a take on HtDP vs SICP. Of course they may not care anymore; Hal's all Python now. And they may never have read HtDP and/or the article. -- Matthias From matthias at ccs.neu.edu Tue May 5 10:20:14 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Tue May 5 10:24:42 2009 Subject: [plt-dev] in-place build directory (was re: build error with svn 14677) In-Reply-To: <990e0c030905050620i4fabc145y2d4c9b31b6b2a17b@mail.gmail.com> References: <990e0c030905011417h6b9f44c6odb431b68e2eea5c@mail.gmail.com> <990e0c030905011434n4c339d8ew90943ed9b9985ede@mail.gmail.com> <18939.32862.224200.550799@winooski.ccs.neu.edu> <990e0c030905011638g21c7d5c6u314d7df70f83e1c9@mail.gmail.com> <18939.36198.292304.565294@winooski.ccs.neu.edu> <2A8447F7-D69E-4D3E-94DC-C9E487F8B6E4@brinckerhoff.org> <18939.37296.812932.367171@winooski.ccs.neu.edu> <990e0c030905011729u63f1bd64p4d7db9b63dfac59b@mail.gmail.com> <18939.38256.869999.472250@winooski.ccs.neu.edu> <990e0c030905050620i4fabc145y2d4c9b31b6b2a17b@mail.gmail.com> Message-ID: <28DF6638-CD09-4141-B269-DCB4EE985E54@ccs.neu.edu> On May 5, 2009, at 9:20 AM, Carl Eastlund wrote: > Quick instructions: > > From this directory (where the `README' and `configure' files are), > run the following commands: > > mkdir build When you automate this (as I have done in some script), you may wish to do something like this: TARGET="build:`date | sed -e"s/ /_/g"`" ... mkdir "$TARGET" or whatever trick you know to make a unique directory. -- Matthias > cd build > ../configure > make > make install > > This will create an in-place installation of PLT Scheme and store the > results of C/C++ compilation in a separate `build' subdirectory, > which is useful if you need to update your sources, delete the build, > and start from scratch. > > You can also run the typical `./configure && make && make install' if > you don't anticipate updating/rebuilding, but it will be harder to > restart from scratch should you need to. > > -------------------- > > 1. Select (or create) a build directory. > > It's better to run the build in a directory other than the one > containing `configure', especially if you're getting sources via > Subversion. A common way to start a Subversion-based build is: > > cd [here] > mkdir build > cd build > > where "[here]" is the directory containing this `README' file and > the `configure' script. The Subversion repository is configured > to support this convention by ignoring `build' in this directory. > > A separate build directory is better in case the Makefile > organization changes, or in case the Makefiles lack some > dependencies. In those cases, when using a "build" subdirectory, > you can just delete and re-create "build" without mangling your > source tree. > > 2. From your build directory, run the script `configure' (which is in > the same directory as this README), with optional command-line > arguments --prefix=TARGETDIR or --enable-shared (or both). > > For example, if you want to install into /usr/local/plt using > dynamic libraries, then run: > > [here]configure --prefix=/usr/local/plt --enable-shared > > Again, "[here]" is the directory path containing the `configure' > script. If you follow the convention of running from a "build" > subdirectory, "[here]" is just "../". If you build from the > current directory, "[here]" is possibly unnecessary, or possibly > just "./", depending on your shell and PATH setting. > > -------------------- > > After that it resumes with discussion of the --prefix flag, and > continues as before except for step re-numbering. > > -- > Carl Eastlund > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From carl.eastlund at gmail.com Tue May 5 10:29:15 2009 From: carl.eastlund at gmail.com (Carl Eastlund) Date: Tue May 5 10:29:33 2009 Subject: [plt-dev] in-place build directory (was re: build error with svn 14677) In-Reply-To: <28DF6638-CD09-4141-B269-DCB4EE985E54@ccs.neu.edu> References: <990e0c030905011417h6b9f44c6odb431b68e2eea5c@mail.gmail.com> <18939.32862.224200.550799@winooski.ccs.neu.edu> <990e0c030905011638g21c7d5c6u314d7df70f83e1c9@mail.gmail.com> <18939.36198.292304.565294@winooski.ccs.neu.edu> <2A8447F7-D69E-4D3E-94DC-C9E487F8B6E4@brinckerhoff.org> <18939.37296.812932.367171@winooski.ccs.neu.edu> <990e0c030905011729u63f1bd64p4d7db9b63dfac59b@mail.gmail.com> <18939.38256.869999.472250@winooski.ccs.neu.edu> <990e0c030905050620i4fabc145y2d4c9b31b6b2a17b@mail.gmail.com> <28DF6638-CD09-4141-B269-DCB4EE985E54@ccs.neu.edu> Message-ID: <990e0c030905050729p2d86c1e5s3bccd3ba81377f03@mail.gmail.com> On Tue, May 5, 2009 at 10:20 AM, Matthias Felleisen wrote: > > > On May 5, 2009, at 9:20 AM, Carl Eastlund wrote: > >> Quick instructions: >> >> ?From this directory (where the `README' and `configure' files are), >> ?run the following commands: >> >> ? mkdir build > > When you automate this (as I have done in some script), you may wish to do > something like this: > > TARGET="build:`date | sed -e"s/ /_/g"`" > ... > mkdir "$TARGET" > > or whatever trick you know to make a unique directory. Why? If you want a fresh build, why leave the old "build:yesterday" around? If you don't, why not reuse your build directory? This seem like it just creates more clutter (that svn is not even set to ignore, currently). -- Carl Eastlund From robby at eecs.northwestern.edu Tue May 5 12:53:26 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Tue May 5 12:53:45 2009 Subject: [plt-dev] rnrs collection runs out of memory when compiling Message-ID: <932b2f1f0905050953t1480ed1bt3b3c3a9aa4c62e19@mail.gmail.com> I'm getting this behavior pretty consistently: setup-plt: making: rnrs setup-plt: in rnrs PLT Scheme virtual machine has run out of memory; aborting Abort Exit 134 From geoff at knauth.org Tue May 5 13:10:11 2009 From: geoff at knauth.org (Geoffrey S. Knauth) Date: Tue May 5 13:11:00 2009 Subject: [plt-dev] SICP and HtDP In-Reply-To: <68F12E3C-1DDB-4882-9B0E-E98655EA4CDD@ccs.neu.edu> References: <4A000A5D.9000202@neilvandyke.org> <68F12E3C-1DDB-4882-9B0E-E98655EA4CDD@ccs.neu.edu> Message-ID: On May 5, 2009, at 10:03, Matthias Felleisen wrote: > MIT has killed SICP and Scheme (kill-scheme-kill). Aw. Gerry and Hal are still there. And upper level people at MIT continue to do more amazing things with Scheme. It reminds of what a friend told me 30 years ago. "If you love someone, let them go." See if they fly back [from Python]. Who still uses CLU? But look at Barbara Liskov now. All will be well. From robby at eecs.northwestern.edu Tue May 5 15:48:03 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Tue May 5 15:48:22 2009 Subject: [plt-dev] ubuntu help? Message-ID: <932b2f1f0905051248x5c8824a3h43ad1007eb3887d4@mail.gmail.com> Is there a shell command I can run in ubuntu that will tell drscheme to open a file? On the mac, I can do "open rep.ss" and that file will open in drscheme. There is a similar command under windows. I see that "gnome-open" does something like this, but it opens .ss files in its own editor, not in drscheme. Anyone do this? Robby From rafkind at cs.utah.edu Tue May 5 15:52:55 2009 From: rafkind at cs.utah.edu (Jon Rafkind) Date: Tue May 5 15:53:18 2009 Subject: [plt-dev] ubuntu help? In-Reply-To: <932b2f1f0905051248x5c8824a3h43ad1007eb3887d4@mail.gmail.com> References: <932b2f1f0905051248x5c8824a3h43ad1007eb3887d4@mail.gmail.com> Message-ID: <4A009917.7060307@cs.utah.edu> Robby Findler wrote: > Is there a shell command I can run in ubuntu that will tell drscheme > to open a file? On the mac, I can do "open rep.ss" and that file will > open in drscheme. There is a similar command under windows. I see that > "gnome-open" does something like this, but it opens .ss files in its > own editor, not in drscheme. Anyone do this? > > Robby > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev > maybe you can try these not-so-easy steps to make gnome-open associate .ss with drscheme? http://ubuntuforums.org/archive/index.php/t-51012.html From pocmatos at gmail.com Tue May 5 15:55:40 2009 From: pocmatos at gmail.com (Paulo J. Matos) Date: Tue May 5 15:56:17 2009 Subject: [plt-dev] ubuntu help? In-Reply-To: <932b2f1f0905051248x5c8824a3h43ad1007eb3887d4@mail.gmail.com> References: <932b2f1f0905051248x5c8824a3h43ad1007eb3887d4@mail.gmail.com> Message-ID: <11b141710905051255g34ad454age8e0960a4fe9a974@mail.gmail.com> On Tue, May 5, 2009 at 8:48 PM, Robby Findler wrote: > Is there a shell command I can run in ubuntu that will tell drscheme > to open a file? On the mac, I can do "open rep.ss" and that file will > open in drscheme. There is a similar command under windows. I see that > "gnome-open" does something like this, but it opens .ss files in its > own editor, not in drscheme. ?Anyone do this? > > Robby > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > Specific to gnome and not to ubuntu: You can simply locate the file in nautilus and select open with... Choose the DrScheme binary and then go to the file properties -> open with (drscheme should already show up) and select it as default. Now gnome-open should open ss from drscheme... repeat for scm if you wish. Cheers, -- Paulo Jorge Matos - pocmatos at gmail.com Webpage: http://www.personal.soton.ac.uk/pocm From eli at barzilay.org Tue May 5 16:10:48 2009 From: eli at barzilay.org (Eli Barzilay) Date: Tue May 5 16:11:11 2009 Subject: [plt-dev] ubuntu help? In-Reply-To: <932b2f1f0905051248x5c8824a3h43ad1007eb3887d4@mail.gmail.com> References: <932b2f1f0905051248x5c8824a3h43ad1007eb3887d4@mail.gmail.com> Message-ID: <18944.40264.966424.962898@winooski.ccs.neu.edu> On May 5, Robby Findler wrote: > Is there a shell command I can run in ubuntu that will tell drscheme > to open a file? You need to use `drscheme -singleInstance', so when you run it again it will popup the file in an existing one instead of running a new line. > On the mac, I can do "open rep.ss" and that file will open in > drscheme. There is a similar command under windows. I see that > "gnome-open" does something like this, but it opens .ss files in its > own editor, not in drscheme. Anyone do this? (And it sounds like that command should be used in whatever gnome-open is doing...) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From robby at eecs.northwestern.edu Tue May 5 16:16:59 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Tue May 5 16:17:17 2009 Subject: [plt-dev] ubuntu help? In-Reply-To: <18944.40264.966424.962898@winooski.ccs.neu.edu> References: <932b2f1f0905051248x5c8824a3h43ad1007eb3887d4@mail.gmail.com> <18944.40264.966424.962898@winooski.ccs.neu.edu> Message-ID: <932b2f1f0905051316r6191efbau2b28f4977fd64abd@mail.gmail.com> Thanks, all! Robby From czhu at cs.utah.edu Tue May 5 16:31:34 2009 From: czhu at cs.utah.edu (Chongkai Zhu) Date: Tue May 5 16:32:05 2009 Subject: [plt-dev] why "next" on the left of "prev" Message-ID: <4A00A226.4040804@cs.utah.edu> As titled, in the search bar of DrScheme, the "next" bottom is on the left of "prev" bottom. That's unintuitive. Should they exchange place? Chongkai From pltscheme at pnkfx.org Tue May 5 16:48:12 2009 From: pltscheme at pnkfx.org (Felix Klock's PLT scheme proxy) Date: Tue May 5 16:48:34 2009 Subject: [plt-dev] why "next" on the left of "prev" In-Reply-To: <4A00A226.4040804@cs.utah.edu> References: <4A00A226.4040804@cs.utah.edu> Message-ID: <3EDD8774-0D8C-4291-ADE0-4D5C836E3676@pnkfx.org> On May 5, 2009, at 4:31 PM, Chongkai Zhu wrote: > As titled, in the search bar of DrScheme, the "next" bottom is on > the left of "prev" bottom. That's unintuitive. Should they exchange > place? I would not want to have to move my mouse over the "prev" button to get to the "next" button. I agree that the order may be unintuitive; Safari handles this problem by laying out the "prev"/"next" buttons to the *left* of the search term. Just something to consider. -Felix From jay.mccarthy at gmail.com Tue May 5 17:19:33 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Tue May 5 17:19:54 2009 Subject: [plt-dev] What is send/suspend? Message-ID: I thought some of you may be intrigued by this. [From http://jay-mccarthy.blogspot.com/2009/05/what-is-sendsuspend.html ] I often ponder what send/suspend really is. It is a lot like call/cc, but has the curious property that the continuation escapes in a single way and is only called in a particular context. I often wonder if there is something weaker than call/cc that implements send/suspend. Today I wrote a little dispatcher that uses threads to implement send/suspend. In this implementation, sending truly suspends the computation. Here's the code: http://www.copypastecode.com/codes/view/5003 The trick is to have channels for communicating responses and requests. When you run this example, you should be able to add two numbers. But, in contrast to the normal send/suspend, all the URLs are one-shots, because once the computation is resumed, it moves forward... it is never saved. This implementation technique also precludes clever implementations of send/suspend/dispatch, like: (define (send/suspend/dispatch mk-page) (let/cc k0 (send/back (mk-page (lambda (handler) (let/ec k1 (k0 (handler (send/suspend k1))))))))) Jay -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From sk at cs.brown.edu Tue May 5 17:51:03 2009 From: sk at cs.brown.edu (Shriram Krishnamurthi) Date: Tue May 5 17:51:42 2009 Subject: [plt-dev] What is send/suspend? In-Reply-To: References: Message-ID: For what it's worth, Matthias and I made this observation back at PLI 2002 in Pittsburgh (and I think you and I have talked about this). However, we never found anything we could *do* with this observation. Perhaps we should have spent more time trying different implementations and benchmarking them. [Btw, you might consider cross-posting on the PLT blog, too...] From hkBst at gentoo.org Thu May 7 16:33:06 2009 From: hkBst at gentoo.org (Marijn Schouten (hkBst)) Date: Thu May 7 16:40:40 2009 Subject: [plt-dev] syntax-case behaving differently Message-ID: <4A034582.1040800@gentoo.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I found a difference in running a file with "mzscheme -f " and with "plt-r6rs " involving syntax-case. For the first you should comment the import. Then the first will error: cdr: expects argument of type ; given # and the second will produce the expected output: (a b (+ c -1) d e) The code is: (import (rnrs)) ;comment this line for mzscheme (define make-next-coords (lambda (x) (with-syntax (((name ... pos inc) x)) (let ((pos (syntax->datum #'pos))) (let f ((names #'(name ...))(pos pos)) (with-syntax (((name rest ...) names)) (if (zero? pos) #'((+ name inc) rest ...) #`(name #,@(f (cdr names)(- pos 1)))))))))) (write (syntax->datum (make-next-coords #'(a b c d e 2 -1)))) Is this a bug or is there another explanation? Thanks, Marijn - -- If you cannot read my mind, then listen to what I say. Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML , #gentoo-{lisp,ml} on FreeNode -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoDRYIACgkQp/VmCx0OL2xuQQCfSYTIkOObHh/G73SoGnk5L3Sc nhIAniHjKUmg4XUv+lNys55srC55oAQR =zKrz -----END PGP SIGNATURE----- From mflatt at cs.utah.edu Thu May 7 17:09:24 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Thu May 7 17:09:47 2009 Subject: [plt-dev] syntax-case behaving differently In-Reply-To: <4A034582.1040800@gentoo.org> References: <4A034582.1040800@gentoo.org> Message-ID: <20090507210928.0F73765009E@mail-svr1.cs.utah.edu> At Thu, 07 May 2009 22:33:06 +0200, "Marijn Schouten (hkBst)" wrote: > I found a difference in running a file with "mzscheme -f " and with > "plt-r6rs " involving syntax-case. For the first you should comment the > import. Then the first will error: > > cdr: expects argument of type ; given # > > and the second will produce the expected output: > > (a b (+ c -1) d e) > > The code is: > > > (import (rnrs)) ;comment this line for mzscheme > > (define make-next-coords > (lambda (x) > (with-syntax (((name ... pos inc) x)) > (let ((pos (syntax->datum #'pos))) > (let f ((names #'(name ...))(pos pos)) > (with-syntax (((name rest ...) names)) > (if (zero? pos) > #'((+ name inc) rest ...) > #`(name #,@(f (cdr names)(- pos 1)))))))))) > > (write (syntax->datum (make-next-coords #'(a b c d e 2 -1)))) > > > Is this a bug or is there another explanation? R6RS and PLT Scheme have different rules about syntax-object wrapping. Specifically, #'(name ...) generates a list in R6RS, but it's a wrapped[*] syntax object in PLT Scheme. In the latter case, `syntax->list' is the simplest way to convert the syntax object to a list. One reason for this difference is that the implicit procedure-application form is lexically scoped in PLT Scheme (and you can redefine it by binding `#%app'), which means that a lexical context must be attached to parentheses (roughly speaking). [*] "Wrapped syntax object" is R6RS terminology. In PLT Scheme terminology, all "syntax object" always implies a wrapper. From dherman at ccs.neu.edu Fri May 8 12:08:57 2009 From: dherman at ccs.neu.edu (Dave Herman) Date: Fri May 8 12:09:40 2009 Subject: [plt-dev] latest version under Windows In-Reply-To: <20090501165917.E74C16500B2@mail-svr1.cs.utah.edu> References: <20090501165917.E74C16500B2@mail-svr1.cs.utah.edu> Message-ID: <4A045919.7010600@ccs.neu.edu> I've been noticing occasional hiccups where either GC pauses seem surprisingly large or -- what happened to me just now -- DrScheme just becomes unresponsive and I have to kill it. Sorry I forgot to check if the CPU usage was pegged before I killed it. I will try to pay more attention next time. Anything more specific I should be looking for? Dave Matthew Flatt wrote: > If you use Windows, then after upgrading to the latest in svn (or the > next nightly build), please pay extra attention to whether DrScheme or > other MrEd-based programs consume too much CPU. > > We've seen some problems with DrScheme maxing out a CPU when it should > be idle. The problems happened especially with blocking reads on > network sockets, but similar problems could happen with any GUI > application. The latest changes fix the problem on my machine, but this > fact of the system is difficult to test. > > > Thanks, > Matthew > > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From dorai at ccs.neu.edu Fri May 8 20:35:46 2009 From: dorai at ccs.neu.edu (Dorai Sitaram) Date: Fri May 8 20:36:07 2009 Subject: [plt-dev] PLT regexp guide typo In-Reply-To: <4A00A226.4040804@cs.utah.edu> from "Chongkai Zhu" at May 05, 2009 02:31:34 PM Message-ID: In http://docs.plt-scheme.org/guide/Backtracking.html (sec. 9.8), the wording "Overall failure is conceded..." has been changed to "Overall, failure is conceded..." The comma is misleading: I really meant "Overall" as an adjective qualifying "failure". regards, --d From eli at barzilay.org Fri May 8 21:02:02 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri May 8 21:02:24 2009 Subject: [plt-dev] PLT regexp guide typo In-Reply-To: References: <4A00A226.4040804@cs.utah.edu> Message-ID: <18948.54794.435536.180509@winooski.ccs.neu.edu> On May 8, Dorai Sitaram wrote: > In http://docs.plt-scheme.org/guide/Backtracking.html (sec. 9.8), the > wording "Overall failure is conceded..." has been changed to "Overall, > failure is conceded..." The comma is misleading: I really meant > "Overall" as an adjective qualifying "failure". Thanks -- comitted. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From eli at barzilay.org Sat May 9 11:18:59 2009 From: eli at barzilay.org (Eli Barzilay) Date: Sat May 9 11:19:26 2009 Subject: [plt-dev] v4.2 Message-ID: <18949.40675.838030.769017@winooski.ccs.neu.edu> Reminder: in about a week we begin the next release, which will be v4.2. Since this is a major change, please be alert for possible bugs. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From eli at barzilay.org Mon May 11 06:21:27 2009 From: eli at barzilay.org (Eli Barzilay) Date: Mon May 11 06:21:47 2009 Subject: [plt-dev] Test server & client Message-ID: <18951.64551.36216.786634@winooski.ccs.neu.edu> I've hacked together a test server and client, which should work very nicely for running a test in a lab. I have used a preliminary version of it in my final exam, and despite the problems[*] it went fine and everything related to the exam was much easier to deal with (no papers, easier grading, etc). I've put the sources at http://misc.barzilay.org/tester/ -- and there's a verbose README that serves as the current documentation. Aside from the intended use, the application itself is basically a specialized client where you edit files that are getting continuously synchronized to the server, so it can serve as a basis for a collaborative editing kind of application. It uses the framework library, so the editor itself is very close to DrScheme. [*] I had only a rough sketch of the server and the client, with important parts missing -- so I was hacking missing parts of the system (both client and server) while students were already using it. I anticipated this, so I set things up to make it robust -- but this was an extreme example of "live coding", much more stressful than what's usually associated with that term... -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From robby at eecs.northwestern.edu Mon May 11 07:14:14 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Mon May 11 07:14:35 2009 Subject: [plt-dev] Re: [plt-bug] all/10233: error on RUN in BSL, apparently related to test engine In-Reply-To: <4AB9CD53-9137-49F1-AC36-5B84D96C04BC@ccs.neu.edu> References: <200905091528.n49FS1E3032735@champlain.ccs.neu.edu> <932b2f1f0905101455g6b33a30bl95d5b3e23ea319ba@mail.gmail.com> <4AB9CD53-9137-49F1-AC36-5B84D96C04BC@ccs.neu.edu> Message-ID: <932b2f1f0905110414j79aa67a5g68f0bb3c78507786@mail.gmail.com> I didn't fix anything, so I'm cc'ing plt-dev in case the person who did is there. Robby On Sunday, May 10, 2009, Matthias Felleisen wrote: > > Correct. It went away with an update. (I had thursday's drscheme running.) > > BUT, now I am getting this > > > [:~/svn/2HtDP/SampleCode] matthias% (display-reason # #t #f) > (display-reason # #t #f) > (display-reason # #t #f) > (display-reason # #t #f) > (display-reason # #t #f) > (display-reason # #t #f) > (display-reason # #t #f) > (display-reason # #t #f) > (display-reason # #t #f) > (display-reason # #t #f) > (display-reason # #t #f) > (display-reason # #t #f) > (display-reason # #t #f) > > > in the console from where I launched drscheme. > > AND, I am getting the names of the functions colored as if they hadn't been run, even though my test cases provide complete coverage. > > > > On May 10, 2009, at 5:55 PM, Robby Findler wrote: > > > I just tried to look into this, but the program you sent (when running > in BSL + universe.ss with a build from a few hours ago) does not > trigger the bug for me. > > Robby > > > From matthias at ccs.neu.edu Mon May 11 07:33:02 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Mon May 11 07:33:46 2009 Subject: [plt-dev] Re: [plt-bug] all/10233: error on RUN in BSL, apparently related to test engine In-Reply-To: <932b2f1f0905110414j79aa67a5g68f0bb3c78507786@mail.gmail.com> References: <200905091528.n49FS1E3032735@champlain.ccs.neu.edu> <932b2f1f0905101455g6b33a30bl95d5b3e23ea319ba@mail.gmail.com> <4AB9CD53-9137-49F1-AC36-5B84D96C04BC@ccs.neu.edu> <932b2f1f0905110414j79aa67a5g68f0bb3c78507786@mail.gmail.com> Message-ID: <59AD21DC-FB99-4989-96AF-BA54E6108C77@ccs.neu.edu> How about the coverage bug (point 2, below)? On May 11, 2009, at 7:14 AM, Robby Findler wrote: > I didn't fix anything, so I'm cc'ing plt-dev in case the person who > did is there. > > Robby > > On Sunday, May 10, 2009, Matthias Felleisen > wrote: >> >> Correct. It went away with an update. (I had thursday's drscheme >> running.) >> >> BUT, now I am getting this >> >> >> [:~/svn/2HtDP/SampleCode] matthias% (display-reason # #t #f) >> (display-reason # #t #f) >> (display-reason # #t #f) >> (display-reason # #t #f) >> (display-reason # #t #f) >> (display-reason # #t #f) >> (display-reason # #t #f) >> (display-reason # #t #f) >> (display-reason # #t #f) >> (display-reason # #t #f) >> (display-reason # #t #f) >> (display-reason # #t #f) >> (display-reason # #t #f) >> >> >> in the console from where I launched drscheme. >> >> AND, I am getting the names of the functions colored as if they >> hadn't been run, even though my test cases provide complete coverage. >> >> >> >> On May 10, 2009, at 5:55 PM, Robby Findler wrote: >> >> >> I just tried to look into this, but the program you sent (when >> running >> in BSL + universe.ss with a build from a few hours ago) does not >> trigger the bug for me. >> >> Robby >> >> >> From robby at eecs.northwestern.edu Mon May 11 07:36:54 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Mon May 11 07:37:12 2009 Subject: [plt-dev] Re: [plt-bug] all/10233: error on RUN in BSL, apparently related to test engine In-Reply-To: <59AD21DC-FB99-4989-96AF-BA54E6108C77@ccs.neu.edu> References: <200905091528.n49FS1E3032735@champlain.ccs.neu.edu> <932b2f1f0905101455g6b33a30bl95d5b3e23ea319ba@mail.gmail.com> <4AB9CD53-9137-49F1-AC36-5B84D96C04BC@ccs.neu.edu> <932b2f1f0905110414j79aa67a5g68f0bb3c78507786@mail.gmail.com> <59AD21DC-FB99-4989-96AF-BA54E6108C77@ccs.neu.edu> Message-ID: <932b2f1f0905110436u439a82dcr4f6fd21ce52061f5@mail.gmail.com> test coverage works correctly for these three programs: (define (f x) x) --- (define (f x) x) (f 1) --- (define (f x) x) (check-expect (f 1) 1) On Mon, May 11, 2009 at 6:33 AM, Matthias Felleisen wrote: > > How about the coverage bug (point 2, below)? > > On May 11, 2009, at 7:14 AM, Robby Findler wrote: > >> I didn't fix anything, so I'm cc'ing plt-dev in case the person who >> did is there. >> >> Robby >> >> On Sunday, May 10, 2009, Matthias Felleisen wrote: >>> >>> Correct. It went away with an update. (I had thursday's drscheme >>> running.) >>> >>> BUT, now I am getting this >>> >>> >>> [:~/svn/2HtDP/SampleCode] matthias% (display-reason # #t #f) >>> (display-reason # #t #f) >>> (display-reason # #t #f) >>> (display-reason # #t #f) >>> (display-reason # #t #f) >>> (display-reason # #t #f) >>> (display-reason # #t #f) >>> (display-reason # #t #f) >>> (display-reason # #t #f) >>> (display-reason # #t #f) >>> (display-reason # #t #f) >>> (display-reason # #t #f) >>> (display-reason # #t #f) >>> >>> >>> in the console from where I launched drscheme. >>> >>> AND, I am getting the names of the functions colored as if they hadn't >>> been run, even though my test cases provide complete coverage. >>> >>> >>> >>> On May 10, 2009, at 5:55 PM, Robby Findler wrote: >>> >>> >>> I just tried to look into this, but the program you sent (when running >>> in BSL + universe.ss with a build from a few hours ago) does not >>> trigger the bug for me. >>> >>> Robby >>> >>> >>> > > From matthias at ccs.neu.edu Mon May 11 08:24:30 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Mon May 11 08:25:24 2009 Subject: [plt-dev] Re: [plt-bug] all/10233: error on RUN in BSL, apparently related to test engine In-Reply-To: <932b2f1f0905110436u439a82dcr4f6fd21ce52061f5@mail.gmail.com> References: <200905091528.n49FS1E3032735@champlain.ccs.neu.edu> <932b2f1f0905101455g6b33a30bl95d5b3e23ea319ba@mail.gmail.com> <4AB9CD53-9137-49F1-AC36-5B84D96C04BC@ccs.neu.edu> <932b2f1f0905110414j79aa67a5g68f0bb3c78507786@mail.gmail.com> <59AD21DC-FB99-4989-96AF-BA54E6108C77@ccs.neu.edu> <932b2f1f0905110436u439a82dcr4f6fd21ce52061f5@mail.gmail.com> Message-ID: Here is the smallest program for which I can get it to highlight the wrong function name: ;; BSL: (require 2htdp/universe) (define mt (empty-scene 100 100)) (check-expect (clack mt 3 2 "leave") (place-image (circle 3 "solid" "red") 3 2 mt)) (define (clack ws x y action) (cond [(mouse=? "leave" action) (place-image (circle 3 "solid" "red") x y ws)])) ;; run program run (define (main s) (big-bang s (on-mouse clack))) On May 11, 2009, at 7:36 AM, Robby Findler wrote: > test coverage works correctly for these three programs: > > (define (f x) x) > > --- > > (define (f x) x) > (f 1) > > --- > > (define (f x) x) > (check-expect (f 1) 1) > > On Mon, May 11, 2009 at 6:33 AM, Matthias Felleisen > wrote: >> >> How about the coverage bug (point 2, below)? >> >> On May 11, 2009, at 7:14 AM, Robby Findler wrote: >> >>> I didn't fix anything, so I'm cc'ing plt-dev in case the person who >>> did is there. >>> >>> Robby >>> >>> On Sunday, May 10, 2009, Matthias Felleisen >>> wrote: >>>> >>>> Correct. It went away with an update. (I had thursday's drscheme >>>> running.) >>>> >>>> BUT, now I am getting this >>>> >>>> >>>> [:~/svn/2HtDP/SampleCode] matthias% (display-reason # >>>> #t #f) >>>> (display-reason # #t #f) >>>> (display-reason # #t #f) >>>> (display-reason # #t #f) >>>> (display-reason # #t #f) >>>> (display-reason # #t #f) >>>> (display-reason # #t #f) >>>> (display-reason # #t #f) >>>> (display-reason # #t #f) >>>> (display-reason # #t #f) >>>> (display-reason # #t #f) >>>> (display-reason # #t #f) >>>> (display-reason # #t #f) >>>> >>>> >>>> in the console from where I launched drscheme. >>>> >>>> AND, I am getting the names of the functions colored as if they >>>> hadn't >>>> been run, even though my test cases provide complete coverage. >>>> >>>> >>>> >>>> On May 10, 2009, at 5:55 PM, Robby Findler wrote: >>>> >>>> >>>> I just tried to look into this, but the program you sent (when >>>> running >>>> in BSL + universe.ss with a build from a few hours ago) does not >>>> trigger the bug for me. >>>> >>>> Robby >>>> >>>> >>>> >> >> From matthias at ccs.neu.edu Mon May 11 09:48:22 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Mon May 11 09:53:01 2009 Subject: [plt-dev] Test server & client In-Reply-To: <18951.64551.36216.786634@winooski.ccs.neu.edu> References: <18951.64551.36216.786634@winooski.ccs.neu.edu> Message-ID: On May 11, 2009, at 6:21 AM, Eli Barzilay wrote: > but this was an extreme example of "live coding", much more > stressful than > what's usually associated with that term... To wit, it was so live that Eli was still writing the test while the students were taking it :-] From robby at eecs.northwestern.edu Mon May 11 10:45:23 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Mon May 11 10:45:41 2009 Subject: [plt-dev] Re: [plt-bug] all/10233: error on RUN in BSL, apparently related to test engine In-Reply-To: References: <200905091528.n49FS1E3032735@champlain.ccs.neu.edu> <932b2f1f0905101455g6b33a30bl95d5b3e23ea319ba@mail.gmail.com> <4AB9CD53-9137-49F1-AC36-5B84D96C04BC@ccs.neu.edu> <932b2f1f0905110414j79aa67a5g68f0bb3c78507786@mail.gmail.com> <59AD21DC-FB99-4989-96AF-BA54E6108C77@ccs.neu.edu> <932b2f1f0905110436u439a82dcr4f6fd21ce52061f5@mail.gmail.com> Message-ID: <932b2f1f0905110745y5dcd674fq12d350e08008d71f@mail.gmail.com> I dropped bugs since this is not the same bug as the original PR. The problem appears to be a combination of the way big-bang expands and the way test coverage works. Here's a shorter program that I think illustrates this a little bit better: ;; BSL: (require 2htdp/universe) (define (clack ws x y action) 1) (define (main s) (big-bang s (on-mouse clack))) (clack 5 3 2 "leave") In this program, you see the identifier 'clack' in the definition of clack highlighted, as well as the 's' in the body of main. This is almost right -- the correct thing would have been to highlight the 'clack' in the argument to on-mouse instead of the other clack. Is it possible that the big-bang macro is doing somethign clever with source locations that confuses the test coverage? FWIW, the test coverage is simply updating some state somewhere with source location ranges in the editor and then coloring things based on what was executed in the fully expanded program. Perhaps it is worth looking at 'big-bang' and thinking about how source locations of syntax objects flow thru that expansion in those terms? Robby From dherman at ccs.neu.edu Mon May 11 11:29:34 2009 From: dherman at ccs.neu.edu (Dave Herman) Date: Mon May 11 11:30:22 2009 Subject: [plt-dev] another freeze in WinXP Message-ID: <4A08445E.3000104@ccs.neu.edu> FWIW, just now got another freeze in Windows: I had Thunderbird active with DrScheme in the background and now can't switch back to DrScheme. CPU usage is very low (just a couple percent), so it's not pegging the processor. I've only had DrScheme running for about an hour, and have not run any significant programs, and memory usage is at about 120M. (I think I have DrScheme's memory limit set at 256M.) I'm running the nightly binary from May 6th in WinXP. Dave From matthias at ccs.neu.edu Mon May 11 11:45:03 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Mon May 11 11:45:51 2009 Subject: [plt-dev] Re: [plt-bug] all/10233: error on RUN in BSL, apparently related to test engine In-Reply-To: <932b2f1f0905110745y5dcd674fq12d350e08008d71f@mail.gmail.com> References: <200905091528.n49FS1E3032735@champlain.ccs.neu.edu> <932b2f1f0905101455g6b33a30bl95d5b3e23ea319ba@mail.gmail.com> <4AB9CD53-9137-49F1-AC36-5B84D96C04BC@ccs.neu.edu> <932b2f1f0905110414j79aa67a5g68f0bb3c78507786@mail.gmail.com> <59AD21DC-FB99-4989-96AF-BA54E6108C77@ccs.neu.edu> <932b2f1f0905110436u439a82dcr4f6fd21ce52061f5@mail.gmail.com> <932b2f1f0905110745y5dcd674fq12d350e08008d71f@mail.gmail.com> Message-ID: (Do you want me to file another bug report?) I don't know what "clever manipulation of source location" could mean, so I am posting the essence of the big-bang macro right here. As you can see I am doing _nothing_ with locations. Is it possible that I should use *syntax*/loc? (This may help with another bug I have re check-syntax and the new big-bang.) -- Matthias (define-syntax (big-bang stx) (syntax-case stx () [(big-bang) (raise-syntax-error #f "bad world description" stx)] [(big-bang w s ...) (let* ([Spec (append AllSpec WldSpec)] [kwds (map (lambda (x) (datum->syntax #'here x)) (map car Spec))] [rec? #'#f] [spec (map (lambda (stx) (syntax-case stx () [(kw . E) (and (identifier? #'kw) (for/or ([n kwds]) (free- identifier=? #'kw n))) (begin (when (free-identifier=? #'kw #'record?) (syntax-case #'E () [(V) (set! rec? #'V)] [_ (err 'record? stx)])) (cons #'kw #;(syntax-e #'kw) (syntax E)))] [_ (raise-syntax-error 'big-bang "not a legal big-bang clause" stx)])) (syntax->list (syntax (s ...))))] ;; assert: all bind = (kw . E) and kw is constrained via Bind [args (map (lambda (x) (define kw (car x)) (define co ;; patch from Jay to allow rename on import (findf (lambda (n) (free-identifier=? kw (car n))) (map (lambda (k s) (cons k (cdr s))) kwds Spec))) (list (syntax-e (car co)) ((cadr co) (cdr x)))) spec)]) #`(send (new (if #,rec? aworld% world%) [world0 w] #,@args) last))])) On May 11, 2009, at 10:45 AM, Robby Findler wrote: > I dropped bugs since this is not the same bug as the original PR. > > The problem appears to be a combination of the way big-bang expands > and the way test coverage works. Here's a shorter program that I think > illustrates this a little bit better: > > ;; BSL: > (require 2htdp/universe) > (define (clack ws x y action) 1) > (define (main s) (big-bang s (on-mouse clack))) > (clack 5 3 2 "leave") > > In this program, you see the identifier 'clack' in the definition of > clack highlighted, as well as the 's' in the body of main. > > This is almost right -- the correct thing would have been to highlight > the 'clack' in the argument to on-mouse instead of the other clack. > > Is it possible that the big-bang macro is doing somethign clever with > source locations that confuses the test coverage? > > FWIW, the test coverage is simply updating some state somewhere with > source location ranges in the editor and then coloring things based on > what was executed in the fully expanded program. Perhaps it is worth > looking at 'big-bang' and thinking about how source locations of > syntax objects flow thru that expansion in those terms? > > Robby From grettke at acm.org Mon May 11 11:53:27 2009 From: grettke at acm.org (Grant Rettke) Date: Mon May 11 11:53:45 2009 Subject: [plt-dev] Test server & client In-Reply-To: <18951.64551.36216.786634@winooski.ccs.neu.edu> References: <18951.64551.36216.786634@winooski.ccs.neu.edu> Message-ID: <756daca50905110853h52dd5ffbmd37ec82c37514806@mail.gmail.com> On Mon, May 11, 2009 at 5:21 AM, Eli Barzilay wrote: > I've hacked together a test server and client, which should work very > nicely for running a test in a lab. What kind of resources do you publish to the client besides Scheme? Do you have a sample test? I didn't see one in the archive; is there one? From eli at barzilay.org Mon May 11 22:29:56 2009 From: eli at barzilay.org (Eli Barzilay) Date: Mon May 11 22:30:18 2009 Subject: [plt-dev] Test server & client In-Reply-To: References: <18951.64551.36216.786634@winooski.ccs.neu.edu> Message-ID: <18952.57124.222990.167365@winooski.ccs.neu.edu> On May 11, Matthias Felleisen wrote: > > On May 11, 2009, at 6:21 AM, Eli Barzilay wrote: > > > but this was an extreme example of "live coding", much more > > stressful than what's usually associated with that term... > > To wit, it was so live that Eli was still writing the test while the > students were taking it :-] I forgot to include the important bits of the README file, see below. One of the advantages I listed for doing this is that you can come to the exam with only a sketch for some question, and write them fully as the exam goes... In my case, I was busy hacking on the server and client for the first ~1-2 hours, and then I wrote two question. It was fun. ---------------------------------------------------------------------- This is a server and a client to run a paperless test. The clients will run in "kiosk mode" -- locking out all other applications, which is intended to prevent students from chatting, looking up stuff on the web etc. This is currently working only on Windows. The server can run in any platform, but it is slightly more convenient if it is unix-like (linux or osx), preferably inside Emacs. Why? ---- Running a paperless exam has some major advantages: * When you get back from your exam you don't need to schlep a pile of papers. You don't need to count them every five seconds to make sure that they're all there. And you also don't need to worry about leaving the pile of graded exams on the roof of your car and realize later that you forgot them there, then spend three hours scanning the roads and sidewalks. * You don't need to deal with student handwriting (sometime even intentionally obscured -- I've seen cases where students who didn't know the answer wrote text that could barely be read). * You can provide the students with additional materials, so they don't need to kill half of a tree because your exam is open materials. (However, this is limited to text files.) * You can update files during the test: clarify questions, add hints etc. You can even have a rough sketch of some questions and write them up as the test goes on... * You can provide "template files" for the students to modify. For example, you can give them some function and ask to fix a bug. * Grading is often a repetitive job, and I found myself starting with writing detailed comments, and later on (when the 10th exam has the same mistake) settle on an explanation-less cross and other obscure markings. When you edit files, it is easy to copy+paste the same comment. * Grading can be more consistent if you're doing such copy+paste that includes the grading. In addition, it is easy to grep for a particular error that you've seen to make sure that the grading is consistent. * Obviously, you can easily come up with a textual markup system so that you compute the exam grades automatically from the graded files. I'm using a system like that for homework submission and grading, and having exams in electronic formats fits nicely into this system. * The same holds for distributing the works. You can keep the original pristine files in case students want to complain -- no need to worry about pencil-written exam being modified post-grading, and you can have the graded files available through your usual channels (eg, through the PLT handin-server). Features -------- The server and the client were designed to be *very* robust and secure, while being convenient to use. * Server-client communication is done through an encrypted connection. The server can be setup to accept connections only from some known IP addresses (and will report attempted connections from other IPs). * Clients do not have a "save" or a "submit" button -- the text is continuously sent back to the server for storage. This frees students from dealing with such details while they're stressed for time. * Clients do *not* have a Scheme REPL. This wouldn't be too hard to add, but I think that this would be bad for several reasons: students can easily get dragged to a long debugging session instead of focusing on the test; you can get dragged to asking tougher questions since the students can now actually try things out; and you can get dragged to harsher grading ("if it doesn't work, you don't get the points", versus "you got the rough idea right, so you get the points" which is common with written exams and make them less stressful). * The server backs up the directories of all clients periodically, to make things safer, and to avoid "I accidentally hit delete in the last minute" excuses. * Clients use a number of tricks to make the application run in "kiosk mode": making it nearly impossible to switch to another application or kill the client. There are cases when some of these may fail (for example, at the NEU lab ctrl+alt+delete cannot be disabled) -- the client has a safety mechanism against this: if you hit ctrl+alt+delete it will notice that it's not the focused window, and then it will (a) alert the server, and (b) set itself back into focus. * You can set up a master password that can unlock a client. (Hit ctrl+shift+P, then the password, then enter.) This is another safety feature in case of some server catastrophe: in this case you can manually unlock a station and copy the written solution out to a different application. * The server keeps a live connection with all clients and polls them frequently. This is done for two reasons: - if the client dies (either due to a bug, or to a break attempt), the server will detect and report it, - on each poll the client reports sends the server the updated contents of editable buffers to save. * The client can withstand being disconnected from the server (eg, if the server is restarted for some reason) -- it will alert the student, but will continue to operate as usual. (Specifically, the student can continue reading files and writing answers during such downtimes.) Changes are not lost -- so when a connection is re-established, synchronization continues as usual. * You can update client-visible files on the server -- the changes will be sent to all clients, and the clients will visually indicate modified files so students can easily see that they need to read something. * The server can require users to login to be able to edit files. In this case, the files that the student writes will be saved in a directory with the username. It can also work in a login-less mode, so each client corresponds to a single student working; in this case, you will need to make students write their names in their answer file(s). (This sounds insecure, but works perfectly fine in practice: as long as a responsible person is present in the room, making sure that people do not switch stations.) You can also require logins without having a password file: and login students on the machine using the master password which will work with any username, and you can even do so remotely from the server prompt. (This is also useful if some students forgot their password.) * If the server is set up to require logins, the client is still functional before such login is successful -- but it will not show editable files. This is useful, for example, if you have twice the number of machines than the number of students: each student can then use one machine to write their answers, and another machine to read the exam material. * Clients are identified with a unique client id (which you setup when the clients are started, or leave the default as the IP number), and after logging in, they are identified by usernames. These must be unique, so no user can login on two clients at the same time (but if a machine crashes, it is possible to have the student move to a different machine). In our lab, I set each client id to correspond to the physical location of the machine, so it is later possible to know if two students were sitting next to each other. (When there's suspected copying, for example.) * If a client is disconnected, and later reconnected, it will show the same content, including files that were modified by the logged-in username (if logins are required) or files that were modified on the client with the same client id -- so no edits (beyond the few seconds of poll frequency) are lost on a client crash. * The server controller can send messages to all clients. The message will flash at the bottom of each client to avoid a student missing it. The message is also logged in a "messages" buffer, so students can read these messages later again. The controller can also send a message to a single client. * Clients can send a message to the server, which is done with a chat-like interface. Together with the above, it is possible for students to ask you questions privately, and for you to announce a message back for the whole class. (For example, a student asks a question, you realize that further clarification is important so you edit a file or add a new one, and tell everyone about it.) It is also possible to disable this feature in the configuration file. * The server controller has extensive control over the clients through several commands (more below). It is possible to freeze all clients (in case you want to make sure that students listen to what you're saying) or a specific one; force all clients (or a specific one) to switch to the messages window (in case you want to make sure they're reading some messages that you're sending); unlock a client (or all) remotely (similar use case as the master password); restart a client (or all) (eg, to recycle the machine for someone else); or kill a client (or all) (which is useful at the end of the test). * The clients can show the time -- which you can configure to be a normal clock, or a countdown to a specific time. You can also change this time at the server prompt, including to any random (short) text (for example "1min!"). In all cases, the displayed time is controlled by the server, so a station with a bad internal clock will not cause problems. * Many more aspects of both the server and the clients are customizable. All the way down to indicator colors. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From eli at barzilay.org Mon May 11 22:33:17 2009 From: eli at barzilay.org (Eli Barzilay) Date: Mon May 11 22:33:38 2009 Subject: [plt-dev] Test server & client In-Reply-To: <756daca50905110853h52dd5ffbmd37ec82c37514806@mail.gmail.com> References: <18951.64551.36216.786634@winooski.ccs.neu.edu> <756daca50905110853h52dd5ffbmd37ec82c37514806@mail.gmail.com> Message-ID: <18952.57325.886624.620314@winooski.ccs.neu.edu> On May 11, Grant Rettke wrote: > On Mon, May 11, 2009 at 5:21 AM, Eli Barzilay wrote: > > I've hacked together a test server and client, which should work > > very nicely for running a test in a lab. > > What kind of resources do you publish to the client besides Scheme? In my case, it was the complete lecture notes (my notes are now at about 200 pages if printed, and many students would print most of them), code for various interpreters, and homework solutions. But any text can be added (dynamically too). > Do you have a sample test? I didn't see one in the archive; is there > one? There's not much to put for a test -- it's basically just a directory with any files you want to put in, and an empty file (or files) that the students will edit as their answer. The "Running the Server and the Clients" sections describes what to put in it. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From robby at eecs.northwestern.edu Tue May 12 16:56:34 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Tue May 12 16:56:52 2009 Subject: [plt-dev] where clauses in reduction relations & metafunctions Message-ID: <932b2f1f0905121356y2acec538y1ac9d6e2e9ae60de@mail.gmail.com> If you have any redex models lying around, can you look and see if you use 'where' clauses? If so, can you look to see if the variable bound in the where clause has an appropriate name for what it is bound to? That is, if it is bound to a number, the variable must be named number_x (for some 'x')? Thanks, Robby From matthias at ccs.neu.edu Wed May 13 13:24:33 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Wed May 13 13:25:25 2009 Subject: [plt-dev] strange error message Message-ID: <3AD903B1-C04B-4843-B4E7-974410F5BF22@ccs.neu.edu> What does this mean: define-compound-unit/infer: untagged initialization dependent signature mred^ is supplied from a later unit with link temp4 From clements at brinckerhoff.org Wed May 13 14:56:59 2009 From: clements at brinckerhoff.org (John Clements) Date: Wed May 13 14:57:24 2009 Subject: [plt-dev] FYI: OS X DrS going to 100% CPU in background Message-ID: <30DC4CA4-8CB7-46AB-8EE2-60471684A17A@brinckerhoff.org> I'm not seeing a pattern yet, but three times today I've seen DrScheme go to 100% CPU while in the background, and drop back down to <1% when brought back to the foreground. Welcome to DrScheme, version 4.1.5.5-svn4may2009 [3m]. I'm going to update DrS to the SVN head; maybe this problem will go away. John -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2484 bytes Desc: not available Url : http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090513/632bb25f/smime-0001.bin From chrdimo at ccs.neu.edu Thu May 14 12:03:45 2009 From: chrdimo at ccs.neu.edu (Christos Dimoulas) Date: Thu May 14 12:03:51 2009 Subject: [plt-dev] Multi-color calculi in Redex Message-ID: <4A0C40E1.5080109@ccs.neu.edu> I would like to define the following grammar in Redex: e := .... | let x = e in e | {e}_i E_0 := [] | let x=E_0 in e E_i := let x = E_i in e | {E_0}_i | {E_i}_j where i,j in N^*. Do you have any ideas how I could code that in Redex? Thank you. .Christos From robby at eecs.northwestern.edu Thu May 14 12:06:42 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Thu May 14 12:07:12 2009 Subject: [plt-dev] Multi-color calculi in Redex In-Reply-To: <4A0C40E1.5080109@ccs.neu.edu> References: <4A0C40E1.5080109@ccs.neu.edu> Message-ID: <932b2f1f0905140906o2375a926ke847210c6362e3be@mail.gmail.com> Am I right that you want to define a parameterize grammar (where you are counting the let nesting depth)? You can't do that like that; instead just define E that has all lets in it, and when you wanted E_i for some i, write a metafunction that counts the depth of the E and use a side-condition to ensure that the size is i. hth, Robby On Thu, May 14, 2009 at 11:03 AM, Christos Dimoulas wrote: > I would like to define the following grammar in Redex: > > e := .... | let x = e in e | {e}_i > E_0 := [] | let x=E_0 in e > > E_i := let x = E_i in e | {E_0}_i | {E_i}_j > > where i,j in N^*. > > Do you have any ideas how I could code that in Redex? > > Thank you. > > .Christos > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > From chrdimo at ccs.neu.edu Thu May 14 12:14:31 2009 From: chrdimo at ccs.neu.edu (Christos Dimoulas) Date: Thu May 14 12:15:15 2009 Subject: [plt-dev] Multi-color calculi in Redex In-Reply-To: <932b2f1f0905140906o2375a926ke847210c6362e3be@mail.gmail.com> References: <4A0C40E1.5080109@ccs.neu.edu> <932b2f1f0905140906o2375a926ke847210c6362e3be@mail.gmail.com> Message-ID: <4A0C4367.1070205@ccs.neu.edu> Robby Findler wrote: > Am I right that you want to define a parameterize grammar (where you > are counting the let nesting depth)? > Not exactly, I am trying to paint the evaluation context with the color i of the deepest colored frame {E_0}_i > You can't do that like that; instead just define E that has all lets > in it, and when you wanted E_i for some i, write a metafunction that > counts the depth of the E and use a side-condition to ensure that the > size is i. > Your suggestion may work in this case too. I will try to right a metafunction that returns the color of the evaluation context instead of having the grammar keep track of it. Thanks. .Christos > hth, > Robby > > On Thu, May 14, 2009 at 11:03 AM, Christos Dimoulas wrote: > >> I would like to define the following grammar in Redex: >> >> e := .... | let x = e in e | {e}_i >> E_0 := [] | let x=E_0 in e >> >> E_i := let x = E_i in e | {E_0}_i | {E_i}_j >> >> where i,j in N^*. >> >> Do you have any ideas how I could code that in Redex? >> >> Thank you. >> >> .Christos >> _________________________________________________ >> For list-related administrative tasks: >> http://list.cs.brown.edu/mailman/listinfo/plt-dev >> >> From matthias at ccs.neu.edu Thu May 14 13:27:28 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Thu May 14 13:27:59 2009 Subject: [plt-dev] Multi-color calculi in Redex In-Reply-To: <4A0C4367.1070205@ccs.neu.edu> References: <4A0C40E1.5080109@ccs.neu.edu> <932b2f1f0905140906o2375a926ke847210c6362e3be@mail.gmail.com> <4A0C4367.1070205@ccs.neu.edu> Message-ID: <1B6132DE-BAA2-49B5-8FA5-061D7E15FD1B@ccs.neu.edu> On May 14, 2009, at 12:14 PM, Christos Dimoulas wrote: > Robby Findler wrote: >> Am I right that you want to define a parameterize grammar (where you >> are counting the let nesting depth)? >> > Not exactly, I am trying to paint the evaluation context with the > color i of the deepest colored frame {E_0}_i > >> You can't do that like that; instead just define E that has all lets >> in it, and when you wanted E_i for some i, write a metafunction that >> counts the depth of the E and use a side-condition to ensure that the >> size is i. >> > Your suggestion may work in this case too. I will try to right a > metafunction that returns the color of the evaluation context > instead of having the grammar keep track of it. But you're not looking at size of E with i. You're looking at color. How can the shape ([] \x.x) tell you whether the context is green or red? -- Matthias > Thanks. > .Christos > >> hth, >> Robby >> >> On Thu, May 14, 2009 at 11:03 AM, Christos Dimoulas >> wrote: >> >>> I would like to define the following grammar in Redex: >>> >>> e := .... | let x = e in e | {e}_i >>> E_0 := [] | let x=E_0 in e >>> >>> E_i := let x = E_i in e | {E_0}_i | {E_i}_j >>> >>> where i,j in N^*. >>> >>> Do you have any ideas how I could code that in Redex? >>> >>> Thank you. >>> >>> .Christos >>> _________________________________________________ >>> For list-related administrative tasks: >>> http://list.cs.brown.edu/mailman/listinfo/plt-dev >>> >>> > > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From dvanhorn at ccs.neu.edu Thu May 14 13:34:34 2009 From: dvanhorn at ccs.neu.edu (David Van Horn) Date: Thu May 14 13:35:15 2009 Subject: [plt-dev] Programmatic running of student programs Message-ID: <4A0C562A.4040209@ccs.neu.edu> Is there an existing tool for running student (BSL, ISL, ...) programs in a sand-boxed environment? I would like to compute the results, the test report, and whether an error was raised, preferably without interacting or even using mred. David From dvanhorn at ccs.neu.edu Thu May 14 13:41:00 2009 From: dvanhorn at ccs.neu.edu (David Van Horn) Date: Thu May 14 13:41:47 2009 Subject: [plt-dev] Programmatic running of student programs In-Reply-To: References: <4A0C562A.4040209@ccs.neu.edu> Message-ID: <4A0C57AC.6000101@ccs.neu.edu> Shriram Krishnamurthi wrote: > I don't know how much of sand-boxing there is, but TestFest has a lot > of infrastructure for grading... Arjun? The sand-box needs are minimal; just syntactically disallowing `require' would work for my purposes, and that's easy enough for me to do. David > On Thu, May 14, 2009 at 1:34 PM, David Van Horn wrote: >> Is there an existing tool for running student (BSL, ISL, ...) programs in a >> sand-boxed environment? I would like to compute the results, the test >> report, and whether an error was raised, preferably without interacting or >> even using mred. >> >> David >> >> _________________________________________________ >> For list-related administrative tasks: >> http://list.cs.brown.edu/mailman/listinfo/plt-dev >> From sk at cs.brown.edu Thu May 14 13:36:55 2009 From: sk at cs.brown.edu (Shriram Krishnamurthi) Date: Thu May 14 13:43:04 2009 Subject: [plt-dev] Programmatic running of student programs In-Reply-To: <4A0C562A.4040209@ccs.neu.edu> References: <4A0C562A.4040209@ccs.neu.edu> Message-ID: I don't know how much of sand-boxing there is, but TestFest has a lot of infrastructure for grading... Arjun? On Thu, May 14, 2009 at 1:34 PM, David Van Horn wrote: > Is there an existing tool for running student (BSL, ISL, ...) programs in a > sand-boxed environment? ?I would like to compute the results, the test > report, and whether an error was raised, preferably without interacting or > even using mred. > > David > > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > From robby at eecs.northwestern.edu Thu May 14 14:42:28 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Thu May 14 14:42:50 2009 Subject: [plt-dev] Programmatic running of student programs In-Reply-To: <4A0C57AC.6000101@ccs.neu.edu> References: <4A0C562A.4040209@ccs.neu.edu> <4A0C57AC.6000101@ccs.neu.edu> Message-ID: <932b2f1f0905141142p657acf79v387e1a3a37351bdc@mail.gmail.com> I believe you want to look at the handin server. It has lots of support and is easy to set up and use. Robby On Thu, May 14, 2009 at 12:41 PM, David Van Horn wrote: > Shriram Krishnamurthi wrote: >> >> I don't know how much of sand-boxing there is, but TestFest has a lot >> of infrastructure for grading... ?Arjun? > > The sand-box needs are minimal; just syntactically disallowing `require' > would work for my purposes, and that's easy enough for me to do. > > David > >> On Thu, May 14, 2009 at 1:34 PM, David Van Horn >> wrote: >>> >>> Is there an existing tool for running student (BSL, ISL, ...) programs in >>> a >>> sand-boxed environment? ?I would like to compute the results, the test >>> report, and whether an error was raised, preferably without interacting >>> or >>> even using mred. >>> >>> David >>> >>> _________________________________________________ >>> ?For list-related administrative tasks: >>> ?http://list.cs.brown.edu/mailman/listinfo/plt-dev >>> > > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > From nadeem at acm.org Thu May 14 16:29:52 2009 From: nadeem at acm.org (Nadeem Abdul Hamid) Date: Thu May 14 16:30:22 2009 Subject: [plt-dev] Programmatic running of student programs In-Reply-To: <932b2f1f0905141142p657acf79v387e1a3a37351bdc@mail.gmail.com> References: <4A0C562A.4040209@ccs.neu.edu> <4A0C57AC.6000101@ccs.neu.edu> <932b2f1f0905141142p657acf79v387e1a3a37351bdc@mail.gmail.com> Message-ID: <3D325505-BF1E-4D25-8339-5528305CA3E7@acm.org> Where is information about the handin server? I can't find it... Thanks, --- nadeem On May 14, 2009, at 2:42 PM, Robby Findler wrote: > I believe you want to look at the handin server. It has lots of > support and is easy to set up and use. > > Robby > > On Thu, May 14, 2009 at 12:41 PM, David Van Horn > wrote: >> Shriram Krishnamurthi wrote: >>> >>> I don't know how much of sand-boxing there is, but TestFest has a >>> lot >>> of infrastructure for grading... Arjun? >> >> The sand-box needs are minimal; just syntactically disallowing >> `require' >> would work for my purposes, and that's easy enough for me to do. >> >> David >> >>> On Thu, May 14, 2009 at 1:34 PM, David Van Horn >> > >>> wrote: >>>> >>>> Is there an existing tool for running student (BSL, ISL, ...) >>>> programs in >>>> a >>>> sand-boxed environment? I would like to compute the results, the >>>> test >>>> report, and whether an error was raised, preferably without >>>> interacting >>>> or >>>> even using mred. >>>> >>>> David >>>> >>>> _________________________________________________ >>>> For list-related administrative tasks: >>>> http://list.cs.brown.edu/mailman/listinfo/plt-dev >>>> >> >> _________________________________________________ >> For list-related administrative tasks: >> http://list.cs.brown.edu/mailman/listinfo/plt-dev >> > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From jay.mccarthy at gmail.com Thu May 14 16:35:34 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Thu May 14 16:35:55 2009 Subject: [plt-dev] Programmatic running of student programs In-Reply-To: <3D325505-BF1E-4D25-8339-5528305CA3E7@acm.org> References: <4A0C562A.4040209@ccs.neu.edu> <4A0C57AC.6000101@ccs.neu.edu> <932b2f1f0905141142p657acf79v387e1a3a37351bdc@mail.gmail.com> <3D325505-BF1E-4D25-8339-5528305CA3E7@acm.org> Message-ID: Hmm, for some reason the Scribble doc isn't built, but if you can read Scribble it is at: http://svn.plt-scheme.org/plt/trunk/collects/handin-server/scribblings/ starting with: http://svn.plt-scheme.org/plt/trunk/collects/handin-server/scribblings/handin-server.scrbl On Thu, May 14, 2009 at 2:29 PM, Nadeem Abdul Hamid wrote: > Where is information about the handin server? I can't find it... > Thanks, > --- nadeem > > On May 14, 2009, at 2:42 PM, Robby Findler wrote: > >> I believe you want to look at the handin server. It has lots of >> support and is easy to set up and use. >> >> Robby >> >> On Thu, May 14, 2009 at 12:41 PM, David Van Horn >> wrote: >>> >>> Shriram Krishnamurthi wrote: >>>> >>>> I don't know how much of sand-boxing there is, but TestFest has a lot >>>> of infrastructure for grading... ?Arjun? >>> >>> The sand-box needs are minimal; just syntactically disallowing `require' >>> would work for my purposes, and that's easy enough for me to do. >>> >>> David >>> >>>> On Thu, May 14, 2009 at 1:34 PM, David Van Horn >>>> wrote: >>>>> >>>>> Is there an existing tool for running student (BSL, ISL, ...) programs >>>>> in >>>>> a >>>>> sand-boxed environment? ?I would like to compute the results, the test >>>>> report, and whether an error was raised, preferably without interacting >>>>> or >>>>> even using mred. >>>>> >>>>> David >>>>> >>>>> _________________________________________________ >>>>> ?For list-related administrative tasks: >>>>> ?http://list.cs.brown.edu/mailman/listinfo/plt-dev >>>>> >>> >>> _________________________________________________ >>> ?For list-related administrative tasks: >>> ?http://list.cs.brown.edu/mailman/listinfo/plt-dev >>> >> _________________________________________________ >> ?For list-related administrative tasks: >> ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From eli at barzilay.org Thu May 14 16:42:32 2009 From: eli at barzilay.org (Eli Barzilay) Date: Thu May 14 16:42:54 2009 Subject: [plt-dev] Programmatic running of student programs In-Reply-To: References: <4A0C562A.4040209@ccs.neu.edu> <4A0C57AC.6000101@ccs.neu.edu> <932b2f1f0905141142p657acf79v387e1a3a37351bdc@mail.gmail.com> <3D325505-BF1E-4D25-8339-5528305CA3E7@acm.org> Message-ID: <18956.33336.165452.485755@winooski.ccs.neu.edu> On May 14, Jay McCarthy wrote: > Hmm, for some reason the Scribble doc isn't built, but if you can read > Scribble it is at: [...] The handin server docs are put in the user directory, so they're not included in the on-line version. But the real answer to this thread is the sandbox library. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From dvanhorn at ccs.neu.edu Thu May 14 17:04:51 2009 From: dvanhorn at ccs.neu.edu (David Van Horn) Date: Thu May 14 17:05:44 2009 Subject: [plt-dev] Programmatic running of student programs In-Reply-To: <18956.33336.165452.485755@winooski.ccs.neu.edu> References: <4A0C562A.4040209@ccs.neu.edu> <4A0C57AC.6000101@ccs.neu.edu> <932b2f1f0905141142p657acf79v387e1a3a37351bdc@mail.gmail.com> <3D325505-BF1E-4D25-8339-5528305CA3E7@acm.org> <18956.33336.165452.485755@winooski.ccs.neu.edu> Message-ID: <4A0C8773.4070902@ccs.neu.edu> Eli Barzilay wrote: > ... the real answer to this thread is the sandbox library. So I can write this: (require scheme/sandbox) (define ev (call-with-input-file "some-isl-prog.scm" (lambda (p) (make-module-evaluator p #:language '(lib "htdp-intermediate.ss" "lang") #:allow-read empty)))) But how do I get the test results, values produced, etc? David From clements at brinckerhoff.org Thu May 14 19:14:00 2009 From: clements at brinckerhoff.org (John Clements) Date: Thu May 14 19:14:25 2009 Subject: [plt-dev] Programmatic running of student programs In-Reply-To: <4A0C562A.4040209@ccs.neu.edu> References: <4A0C562A.4040209@ccs.neu.edu> Message-ID: <88154935-1845-49CA-96D5-D182C413C018@brinckerhoff.org> On May 14, 2009, at 10:34 AM, David Van Horn wrote: > Is there an existing tool for running student (BSL, ISL, ...) > programs in a sand-boxed environment? I would like to compute the > results, the test report, and whether an error was raised, > preferably without interacting or even using mred. You don't say here whether you want the results of your tests or of the student tests. I suspect that you want the results of your tests, and I furthermore suspect that the easiest way to get this running is to use the handin server; you can run it locally, to hide it from the students, and I'd be happy to supply example files though of course Eli would be far more qualified. John -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2484 bytes Desc: not available Url : http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090514/90f99674/smime.bin From dvanhorn at ccs.neu.edu Thu May 14 19:29:51 2009 From: dvanhorn at ccs.neu.edu (David Van Horn) Date: Thu May 14 19:30:31 2009 Subject: [plt-dev] Programmatic running of student programs In-Reply-To: <88154935-1845-49CA-96D5-D182C413C018@brinckerhoff.org> References: <4A0C562A.4040209@ccs.neu.edu> <88154935-1845-49CA-96D5-D182C413C018@brinckerhoff.org> Message-ID: <4A0CA96F.8060004@ccs.neu.edu> John Clements wrote: > > On May 14, 2009, at 10:34 AM, David Van Horn wrote: > >> Is there an existing tool for running student (BSL, ISL, ...) programs >> in a sand-boxed environment? I would like to compute the results, the >> test report, and whether an error was raised, preferably without >> interacting or even using mred. > > You don't say here whether you want the results of your tests or of the > student tests. > > I suspect that you want the results of your tests, and I furthermore > suspect that the easiest way to get this running is to use the handin > server; you can run it locally, to hide it from the students, and I'd be > happy to supply example files though of course Eli would be far more > qualified. No, I just want the results of running the program. I don't need to interact with it, feed it tests, check for bindings, or anything else. I'd like to be able to provide a file name and get back a list of values, and either an exception value or a test report value. David From jay.mccarthy at gmail.com Thu May 14 20:07:54 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Thu May 14 20:08:25 2009 Subject: [plt-dev] Programmatic running of student programs In-Reply-To: <4A0CA96F.8060004@ccs.neu.edu> References: <4A0C562A.4040209@ccs.neu.edu> <88154935-1845-49CA-96D5-D182C413C018@brinckerhoff.org> <4A0CA96F.8060004@ccs.neu.edu> Message-ID: I did something similar with plai. I hacked the test engine to print the results in a format I parsed for my grading purposes. Sent from my iPhone On May 14, 2009, at 5:29 PM, David Van Horn wrote: > John Clements wrote: >> On May 14, 2009, at 10:34 AM, David Van Horn wrote: >>> Is there an existing tool for running student (BSL, ISL, ...) >>> programs in a sand-boxed environment? I would like to compute the >>> results, the test report, and whether an error was raised, >>> preferably without interacting or even using mred. >> You don't say here whether you want the results of your tests or of >> the student tests. >> I suspect that you want the results of your tests, and I >> furthermore suspect that the easiest way to get this running is to >> use the handin server; you can run it locally, to hide it from the >> students, and I'd be happy to supply example files though of course >> Eli would be far more qualified. > > No, I just want the results of running the program. I don't need to > interact with it, feed it tests, check for bindings, or anything > else. I'd like to be able to provide a file name and get back a list > of values, and either an exception value or a test report value. > > David > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From eli at barzilay.org Fri May 15 10:03:38 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri May 15 10:03:59 2009 Subject: [plt-dev] Programmatic running of student programs In-Reply-To: <4A0C8773.4070902@ccs.neu.edu> References: <4A0C562A.4040209@ccs.neu.edu> <4A0C57AC.6000101@ccs.neu.edu> <932b2f1f0905141142p657acf79v387e1a3a37351bdc@mail.gmail.com> <3D325505-BF1E-4D25-8339-5528305CA3E7@acm.org> <18956.33336.165452.485755@winooski.ccs.neu.edu> <4A0C8773.4070902@ccs.neu.edu> Message-ID: <18957.30266.372150.167184@winooski.ccs.neu.edu> On May 14, David Van Horn wrote: > Eli Barzilay wrote: > > ... the real answer to this thread is the sandbox library. > > So I can write this: > > (require scheme/sandbox) > (define ev > (call-with-input-file "some-isl-prog.scm" > (lambda (p) > (make-module-evaluator p > #:language > '(lib "htdp-intermediate.ss" "lang") > #:allow-read empty)))) You'll want to use '(special intermediate) for the language. > But how do I get the test results, values produced, etc? To get values you use run stuff through the resulting evaluator. Getting test results is not possible as far as I know. There might be some way to get the printout, but I don't remember how to do that too. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From rafkind at cs.utah.edu Fri May 15 23:56:18 2009 From: rafkind at cs.utah.edu (Jon Rafkind) Date: Fri May 15 23:56:39 2009 Subject: [plt-dev] embedded gui inside hierlist Message-ID: <4A0E3962.5010108@cs.utah.edu> Embedded editor-snip's act strangely when put inside the text part of a hierarchical-list-item%. The editor-snip% doesn't get aligned properly so all its internal snips are bunched up in the left hand corner. The issue seems to be whether or not the content-snip of hierarchical-list-snip% is visible or not when the list is created. That is, I added the content-snip to the main buffer in the constructor of the hierarchical-list-snip% to fix the layout problems. (sequence ... (send main-buffer insert content-snip 4) ....) I'm not sure what the difference is between adding the content-snip to the main-buffer immediately and when doing it in the handle-open call, but hopefully someone else has a better idea. What I'm trying to do is something like this: (let ([item (send list new-list)] [my-editor (new pasteboard%)] (send (send item get-editor) insert (new editor-snip% [editor my-editor])) (send my-editor insert ...stuff...)) From matthias at ccs.neu.edu Sat May 16 13:10:03 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Sat May 16 13:10:37 2009 Subject: [plt-dev] debug output Message-ID: <17C9223C-262E-4B53-90D1-04AF4205E741@ccs.neu.edu> The svn head is displaying debug output like this: (display-reason # #t #f) (display-reason # #t #f) Anyone? From eli at barzilay.org Sat May 16 14:48:24 2009 From: eli at barzilay.org (Eli Barzilay) Date: Sat May 16 14:48:44 2009 Subject: [plt-dev] debug output In-Reply-To: <17C9223C-262E-4B53-90D1-04AF4205E741@ccs.neu.edu> References: <17C9223C-262E-4B53-90D1-04AF4205E741@ccs.neu.edu> Message-ID: <18959.2680.828290.105470@winooski.ccs.neu.edu> On May 16, Matthias Felleisen wrote: > > The svn head is displaying debug output like this: > > (display-reason # #t #f) > (display-reason # #t #f) Looks like this is coming from the test-engine collection. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From eli at barzilay.org Sat May 16 21:47:22 2009 From: eli at barzilay.org (Eli Barzilay) Date: Sat May 16 21:47:51 2009 Subject: [plt-dev] Release for v4.2 has begun Message-ID: The release process for v4.2 has begun: the trunk was copied to a branch for any work that is left and is now bumped to v4.1.900. You can go on using the trunk as usual, it is now bumped to v4.2.0.1 (to avoid having two different trees with the same version). Note: Please pay attention to mred bugs! If you have any bug-fixes and changes that need to go in the release then make sure you specify that in the commit message or mail me the revision numbers. Do not try to commit anything on the pre-release branch (the server will forbid it). Note that nightly builds will go on as usual (as v4.2.0.1), and pre-release builds will be available at http://pre.plt-scheme.org/release/ Please tell me if you think that this should be announced on the plt-scheme list for wider testing. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From mflatt at cs.utah.edu Sun May 17 08:33:28 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Sun May 17 08:33:49 2009 Subject: [plt-dev] identifier-prune-lexical-context Message-ID: <20090517123330.B7AD2650131@mail-svr1.cs.utah.edu> [File under "obscure macrology" and "macro-expansion performance".] The `identifier-prune-lexical-context' function added in 4.2.0.2 strips lexical information from an identifier if the information doesn't affect the identifier's binding (or, more generally, the binding of identifiers derived from a given list of symbols). There's also a derived `quote-syntax/prune' form, which is like `quote-syntax' on an identifier, but that prunes the lexical information from the identifier. Note that `(quote-syntax/prune id)' is different from `(identifier-prune-lexical-context (quote-syntax id))'; the later would wait until the expression is evaluated to prune lexical information, while the former prunes it as the expression is expanded (so that the lexical information isn't kept in bytecode, etc.). You might wonder why irrelevant lexical information would be preserved in the first place. The reason is `datum->syntax': The macro system doesn't know whether lexical information will be transferred to some other datum, where that extra information could become relevant. Probably `datum->syntax' is too powerful an operation, but I don't know how to get rid of it. So, we've fought the excessive-information problem with a lot of encoding, caching, and lazy-initialization tricks. These tricks, however, fail for nested internal-definition contexts created by `package', especially when `define*'s are used within a package to create layers of bindings. I couldn't find new tricks that work well enough without a pruning hint from the programmer. Use `quote-syntax/prune' or `identifier-prune-lexical-context' to potentially reduce bytecode size when an identifier's context won't be transferred to other syntax objects --- or perhaps only to '#%top, which `quote-syntax/prune' excludes from pruning in addition to the identifier's symbol. Pruning probably is not worthwhile on a macro template, but it can be useful in the expansion of forms like `define-struct' and `package' that keep lists of identifiers. From robby at eecs.northwestern.edu Sun May 17 08:58:50 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Sun May 17 08:59:11 2009 Subject: [plt-dev] identifier-prune-lexical-context In-Reply-To: <20090517123330.B7AD2650131@mail-svr1.cs.utah.edu> References: <20090517123330.B7AD2650131@mail-svr1.cs.utah.edu> Message-ID: <932b2f1f0905170558o34f1c3c2p76cd470bfae32df1@mail.gmail.com> Could this be useful for contracts? It expands into a macro definition and there are generally lots of irrelevant identifiers kept, I think. You know -- this also makes me wonder if there could be a performance debugging tool in there. Perhaps something that takes a syntax object or a .zo file and inspects the information there much like the macro stepper does, but counts the number of bindings at each subexpression somehow. Robby On Sun, May 17, 2009 at 7:33 AM, Matthew Flatt wrote: > [File under "obscure macrology" and "macro-expansion performance".] > > The `identifier-prune-lexical-context' function added in 4.2.0.2 strips > lexical information from an identifier if the information doesn't > affect the identifier's binding (or, more generally, the binding of > identifiers derived from a given list of symbols). > > There's also a derived `quote-syntax/prune' form, which is like > `quote-syntax' on an identifier, but that prunes the lexical > information from the identifier. Note that `(quote-syntax/prune id)' is > different from `(identifier-prune-lexical-context (quote-syntax id))'; > the later would wait until the expression is evaluated to prune lexical > information, while the former prunes it as the expression is expanded > (so that the lexical information isn't kept in bytecode, etc.). > > > You might wonder why irrelevant lexical information would be preserved > in the first place. The reason is `datum->syntax': The macro system > doesn't know whether lexical information will be transferred to some > other datum, where that extra information could become relevant. > > Probably `datum->syntax' is too powerful an operation, but I don't know > how to get rid of it. So, we've fought the excessive-information > problem with a lot of encoding, caching, and lazy-initialization > tricks. These tricks, however, fail for nested internal-definition > contexts created by `package', especially when `define*'s are used > within a package to create layers of bindings. I couldn't find new > tricks that work well enough without a pruning hint from the > programmer. > > > Use `quote-syntax/prune' or `identifier-prune-lexical-context' to > potentially reduce bytecode size when an identifier's context won't be > transferred to other syntax objects --- or perhaps only to '#%top, > which `quote-syntax/prune' excludes from pruning in addition to the > identifier's symbol. Pruning probably is not worthwhile on a macro > template, but it can be useful in the expansion of forms like > `define-struct' and `package' that keep lists of identifiers. > > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > From eli at barzilay.org Sun May 17 09:28:42 2009 From: eli at barzilay.org (Eli Barzilay) Date: Sun May 17 09:29:03 2009 Subject: [plt-dev] identifier-prune-lexical-context In-Reply-To: <20090517123330.B7AD2650131@mail-svr1.cs.utah.edu> References: <20090517123330.B7AD2650131@mail-svr1.cs.utah.edu> Message-ID: <18960.4362.837879.885106@winooski.ccs.neu.edu> On May 17, Matthew Flatt wrote: > > Use `quote-syntax/prune' or `identifier-prune-lexical-context' to > potentially reduce bytecode size when an identifier's context won't > be transferred to other syntax objects --- or perhaps only to > '#%top, which `quote-syntax/prune' excludes from pruning in addition > to the identifier's symbol. Pruning probably is not worthwhile on a > macro template, but it can be useful in the expansion of forms like > `define-struct' and `package' that keep lists of identifiers. Is there some example to demonstrate such a use? -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From mflatt at cs.utah.edu Sun May 17 11:33:25 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Sun May 17 11:33:47 2009 Subject: [plt-dev] identifier-prune-lexical-context In-Reply-To: <18960.4362.837879.885106@winooski.ccs.neu.edu> References: <20090517123330.B7AD2650131@mail-svr1.cs.utah.edu> <18960.4362.837879.885106@winooski.ccs.neu.edu> Message-ID: <20090517153327.003F3650146@mail-svr1.cs.utah.edu> At Sun, 17 May 2009 09:28:42 -0400, Eli Barzilay wrote: > On May 17, Matthew Flatt wrote: > > > > Use `quote-syntax/prune' or `identifier-prune-lexical-context' to > > potentially reduce bytecode size when an identifier's context won't > > be transferred to other syntax objects --- or perhaps only to > > '#%top, which `quote-syntax/prune' excludes from pruning in addition > > to the identifier's symbol. Pruning probably is not worthwhile on a > > macro template, but it can be useful in the expansion of forms like > > `define-struct' and `package' that keep lists of identifiers. > > Is there some example to demonstrate such a use? Only `package' ("scheme/package.ss") and `define-struct' ("scheme/private/define-struct.ss"), so far. From matthias at ccs.neu.edu Mon May 18 11:46:25 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Mon May 18 11:47:01 2009 Subject: [plt-dev] Re: [plt-scheme] End-user instructions for upgrading single PLaneT package In-Reply-To: <932b2f1f0905180824n4d8db46bq1cf2c6b624cac3b6@mail.gmail.com> References: <4A0F5658.1050305@neilvandyke.org> <932b2f1f0905170453k4c1d2c9et861d962a3ae26ca0@mail.gmail.com> <935AF697-9B32-4434-8354-72AB44A6EBB1@adelphi.edu> <932b2f1f0905180630ob2ff698ldfb1b272391814ae@mail.gmail.com> <4A1167C7.9070409@neilvandyke.org> <932b2f1f0905180704r6af21751k68f67634077234c5@mail.gmail.com> <4A116EE0.4010208@neilvandyke.org> <932b2f1f0905180752n1f6aff2g90a8a29bbe8d7d48@mail.gmail.com> <4A117B9E.5010107@neilvandyke.org> <932b2f1f0905180824n4d8db46bq1cf2c6b624cac3b6@mail.gmail.com> Message-ID: <97F6AA09-EF6D-4558-A64E-003AFA234AEF@ccs.neu.edu> On May 18, 2009, at 11:24 AM, Robby Findler wrote: > Just to be clear, I essentially agree with everything you've written. > We do need something better and tool support for it. A GUI that helps > the user's control the upgrades would be a great idea. (IF you were to > write one I'd be happy to take it!) I am still wondering whether drscheme could support a GUI that shows what's available at Planet and even compares the versions there and in your cache. Then a simple 'click' could warn you of potential problems before you install the latest version. -- Matthias From rafkind at cs.utah.edu Mon May 18 13:41:25 2009 From: rafkind at cs.utah.edu (Jon Rafkind) Date: Mon May 18 13:41:50 2009 Subject: [plt-dev] Re: [plt-scheme] End-user instructions for upgrading single PLaneT package In-Reply-To: <97F6AA09-EF6D-4558-A64E-003AFA234AEF@ccs.neu.edu> References: <4A0F5658.1050305@neilvandyke.org> <932b2f1f0905170453k4c1d2c9et861d962a3ae26ca0@mail.gmail.com> <935AF697-9B32-4434-8354-72AB44A6EBB1@adelphi.edu> <932b2f1f0905180630ob2ff698ldfb1b272391814ae@mail.gmail.com> <4A1167C7.9070409@neilvandyke.org> <932b2f1f0905180704r6af21751k68f67634077234c5@mail.gmail.com> <4A116EE0.4010208@neilvandyke.org> <932b2f1f0905180752n1f6aff2g90a8a29bbe8d7d48@mail.gmail.com> <4A117B9E.5010107@neilvandyke.org> <932b2f1f0905180824n4d8db46bq1cf2c6b624cac3b6@mail.gmail.com> <97F6AA09-EF6D-4558-A64E-003AFA234AEF@ccs.neu.edu> Message-ID: <4A119DC5.3080602@cs.utah.edu> Matthias Felleisen wrote: > > On May 18, 2009, at 11:24 AM, Robby Findler wrote: > >> Just to be clear, I essentially agree with everything you've written. >> We do need something better and tool support for it. A GUI that helps >> the user's control the upgrades would be a great idea. (IF you were to >> write one I'd be happy to take it!) > > > I am still wondering whether drscheme could support a GUI that > shows what's available at Planet and even compares the versions > there and in your cache. Then a simple 'click' could warn you > of potential problems before you install the latest version. > I started a little gui for this last week. Here is a functional demo: http://planet.plt-scheme.org/display.ss?package=planet-manager.plt&owner=kazzmir Obviously needs a lot of work. One major problem is the planet database is not query-able. Right now I'm doing html screenscraping by reading http://planet.plt-scheme.org. From robby at eecs.northwestern.edu Mon May 18 13:43:00 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Mon May 18 13:43:21 2009 Subject: [plt-dev] Re: [plt-scheme] End-user instructions for upgrading single PLaneT package In-Reply-To: <4A119DC5.3080602@cs.utah.edu> References: <4A0F5658.1050305@neilvandyke.org> <932b2f1f0905180630ob2ff698ldfb1b272391814ae@mail.gmail.com> <4A1167C7.9070409@neilvandyke.org> <932b2f1f0905180704r6af21751k68f67634077234c5@mail.gmail.com> <4A116EE0.4010208@neilvandyke.org> <932b2f1f0905180752n1f6aff2g90a8a29bbe8d7d48@mail.gmail.com> <4A117B9E.5010107@neilvandyke.org> <932b2f1f0905180824n4d8db46bq1cf2c6b624cac3b6@mail.gmail.com> <97F6AA09-EF6D-4558-A64E-003AFA234AEF@ccs.neu.edu> <4A119DC5.3080602@cs.utah.edu> Message-ID: <932b2f1f0905181043m43741ad1pbd00f8d6cd732302@mail.gmail.com> All of the database functionality in the server is separated out, so it shoudl not be too hard to add a web-based interface to it (see db.ss in iplt/planet/). Robby On Mon, May 18, 2009 at 12:41 PM, Jon Rafkind wrote: > Matthias Felleisen wrote: >> >> On May 18, 2009, at 11:24 AM, Robby Findler wrote: >> >>> Just to be clear, I essentially agree with everything you've written. >>> We do need something better and tool support for it. A GUI that helps >>> the user's control the upgrades would be a great idea. (IF you were to >>> write one I'd be happy to take it!) >> >> >> I am still wondering whether drscheme could support a GUI that >> shows what's available at Planet and even compares the versions >> there and in your cache. Then a simple 'click' could warn you >> of potential problems before you install the latest version. >> > I started a little gui for this last week. Here is a functional demo: > http://planet.plt-scheme.org/display.ss?package=planet-manager.plt&owner=kazzmir > > Obviously needs a lot of work. One major problem is the planet database is > not query-able. Right now I'm doing html screenscraping by reading > http://planet.plt-scheme.org. > From rafkind at cs.utah.edu Mon May 18 14:02:36 2009 From: rafkind at cs.utah.edu (Jon Rafkind) Date: Mon May 18 14:03:00 2009 Subject: [plt-dev] Re: [plt-scheme] End-user instructions for upgrading single PLaneT package In-Reply-To: <932b2f1f0905181043m43741ad1pbd00f8d6cd732302@mail.gmail.com> References: <4A0F5658.1050305@neilvandyke.org> <932b2f1f0905180630ob2ff698ldfb1b272391814ae@mail.gmail.com> <4A1167C7.9070409@neilvandyke.org> <932b2f1f0905180704r6af21751k68f67634077234c5@mail.gmail.com> <4A116EE0.4010208@neilvandyke.org> <932b2f1f0905180752n1f6aff2g90a8a29bbe8d7d48@mail.gmail.com> <4A117B9E.5010107@neilvandyke.org> <932b2f1f0905180824n4d8db46bq1cf2c6b624cac3b6@mail.gmail.com> <97F6AA09-EF6D-4558-A64E-003AFA234AEF@ccs.neu.edu> <4A119DC5.3080602@cs.utah.edu> <932b2f1f0905181043m43741ad1pbd00f8d6cd732302@mail.gmail.com> Message-ID: <4A11A2BC.1070302@cs.utah.edu> Robby Findler wrote: > All of the database functionality in the server is separated out, so > it shoudl not be too hard to add a web-based interface to it (see > db.ss in iplt/planet/). > > That looks like a database for a local cache of planet, but I was talking about getting a list of all planet packages from the PLT planet server. > Robby > > On Mon, May 18, 2009 at 12:41 PM, Jon Rafkind wrote: > >> Matthias Felleisen wrote: >> >>> On May 18, 2009, at 11:24 AM, Robby Findler wrote: >>> >>> >>>> Just to be clear, I essentially agree with everything you've written. >>>> We do need something better and tool support for it. A GUI that helps >>>> the user's control the upgrades would be a great idea. (IF you were to >>>> write one I'd be happy to take it!) >>>> >>> I am still wondering whether drscheme could support a GUI that >>> shows what's available at Planet and even compares the versions >>> there and in your cache. Then a simple 'click' could warn you >>> of potential problems before you install the latest version. >>> >>> >> I started a little gui for this last week. Here is a functional demo: >> http://planet.plt-scheme.org/display.ss?package=planet-manager.plt&owner=kazzmir >> >> Obviously needs a lot of work. One major problem is the planet database is >> not query-able. Right now I'm doing html screenscraping by reading >> http://planet.plt-scheme.org. >> >> From robby at eecs.northwestern.edu Mon May 18 14:16:14 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Mon May 18 14:16:33 2009 Subject: [plt-dev] Re: [plt-scheme] End-user instructions for upgrading single PLaneT package In-Reply-To: <4A11A2BC.1070302@cs.utah.edu> References: <4A0F5658.1050305@neilvandyke.org> <932b2f1f0905180704r6af21751k68f67634077234c5@mail.gmail.com> <4A116EE0.4010208@neilvandyke.org> <932b2f1f0905180752n1f6aff2g90a8a29bbe8d7d48@mail.gmail.com> <4A117B9E.5010107@neilvandyke.org> <932b2f1f0905180824n4d8db46bq1cf2c6b624cac3b6@mail.gmail.com> <97F6AA09-EF6D-4558-A64E-003AFA234AEF@ccs.neu.edu> <4A119DC5.3080602@cs.utah.edu> <932b2f1f0905181043m43741ad1pbd00f8d6cd732302@mail.gmail.com> <4A11A2BC.1070302@cs.utah.edu> Message-ID: <932b2f1f0905181116m4b348974vd9efc740d23c7eb0@mail.gmail.com> On Mon, May 18, 2009 at 1:02 PM, Jon Rafkind wrote: > Robby Findler wrote: >> >> All of the database functionality in the server is separated out, so >> it shoudl not be too hard to add a web-based interface to it (see >> db.ss in iplt/planet/). >> >> > > That looks like a database for a local cache of planet, but I was talking > about getting a list of all planet packages from the PLT planet server. That is the code the server runs. the client does not use a database (well, it has data, but not sql). Robby From dherman at ccs.neu.edu Mon May 18 14:17:12 2009 From: dherman at ccs.neu.edu (Dave Herman) Date: Mon May 18 14:17:49 2009 Subject: [plt-dev] all versions >= 4.1.5.x *very* broken in Windows Message-ID: <4A11A628.2030901@ccs.neu.edu> This is pretty critical: on Windows, recent versions of DrScheme are repeatedly freezing. I've sent a couple emails about this, but I'm seeing it more and more since then. I updated to 4.2.0.2 today and it's just as bad or worse. It seems to be when DrScheme loses focus-- esp., I think, when part or all of the window needs to be repainted-- and I try to refocus on DrScheme and it won't come back. I would recommend tracking this one down before releasing. It's happening frequently enough that I suspect it's not a fluke. I'm happy to provide any additional info; just let me know what to look for. Dave From matthias at ccs.neu.edu Mon May 18 15:12:50 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Mon May 18 15:13:18 2009 Subject: [plt-dev] Re: [plt-scheme] End-user instructions for upgrading single PLaneT package In-Reply-To: <932b2f1f0905181116m4b348974vd9efc740d23c7eb0@mail.gmail.com> References: <4A0F5658.1050305@neilvandyke.org> <932b2f1f0905180704r6af21751k68f67634077234c5@mail.gmail.com> <4A116EE0.4010208@neilvandyke.org> <932b2f1f0905180752n1f6aff2g90a8a29bbe8d7d48@mail.gmail.com> <4A117B9E.5010107@neilvandyke.org> <932b2f1f0905180824n4d8db46bq1cf2c6b624cac3b6@mail.gmail.com> <97F6AA09-EF6D-4558-A64E-003AFA234AEF@ccs.neu.edu> <4A119DC5.3080602@cs.utah.edu> <932b2f1f0905181043m43741ad1pbd00f8d6cd732302@mail.gmail.com> <4A11A2BC.1070302@cs.utah.edu> <932b2f1f0905181116m4b348974vd9efc740d23c7eb0@mail.gmail.com> Message-ID: <6F706E8D-B1F7-46FC-8FA0-BDA71B4015FF@ccs.neu.edu> Hah, at least the right people are talking to each other. Jon, before you ever scrape HTML from one of our sites again, holler! We'll figure out how to make this work properly. -- Matthias From jay.mccarthy at gmail.com Mon May 18 16:47:15 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Mon May 18 16:47:37 2009 Subject: [plt-dev] The Two State Solution: Native and Serializable Continuations in the PLT Web Server Message-ID: From: http://jay-mccarthy.blogspot.com/2009/05/two-state-solution-native-and.html One of the annoyance of the stateless Web application language [1] that comes with the PLT Web Server is that you can't call third-party higher-order library procedures with arguments that try to capture serializable continuations. (I know, you try to do that all the time.) For example: (build-list 3 (lambda (i) (call-with-serializable-current-continuation (lambda (k) (serialize k))))) The problem is that the stateless language performs a transformation on your program to extract the continuations into a serializable representation. If you really need to do this, we've developed a compromise called "The Two State Solution": one state on the client and the other on the server. Only the third-party parts of the continuation (in this case, the code inside build-list) are stored on the server; everything else is shipped to the client. You just need to annotate your code slightly to indicate where the transition is: (serial->native (build-list 3 (lambda (i) (native->serial (call-with-serializable-current-continuation (lambda (k) (serialize k))))))) serial->native signals the transition to the third-party and native->serial signals the transition back. It is still a little annoying to find when you've called these third-party higher-order library procedures with arguments that try to capture serializable continuations, so there's a simple macro that provides a transitioning wrapper for you: (define-native (build-list/native _ ho) build-list) expands to: (define (build-list/native fst snd) (serial->native (build-list fst (lambda args (native->serial (apply snd args)))))) This new feature is documented in the online manual [2], of course. 1. http://docs.plt-scheme.org/web-server/stateless.html 2. http://faculty.cs.byu.edu/~jay/plt-doc/web-server/stateless.html#(part._.Serializable_.Continuations) -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From geoff at knauth.org Mon May 18 17:32:24 2009 From: geoff at knauth.org (Geoffrey S. Knauth) Date: Mon May 18 17:32:46 2009 Subject: [plt-dev] Re: [plt-scheme] End-user instructions for upgrading single PLaneT package In-Reply-To: <4A119DC5.3080602@cs.utah.edu> References: <4A0F5658.1050305@neilvandyke.org> <932b2f1f0905170453k4c1d2c9et861d962a3ae26ca0@mail.gmail.com> <935AF697-9B32-4434-8354-72AB44A6EBB1@adelphi.edu> <932b2f1f0905180630ob2ff698ldfb1b272391814ae@mail.gmail.com> <4A1167C7.9070409@neilvandyke.org> <932b2f1f0905180704r6af21751k68f67634077234c5@mail.gmail.com> <4A116EE0.4010208@neilvandyke.org> <932b2f1f0905180752n1f6aff2g90a8a29bbe8d7d48@mail.gmail.com> <4A117B9E.5010107@neilvandyke.org> <932b2f1f0905180824n4d8db46bq1cf2c6b624cac3b6@mail.gmail.com> <97F6AA09-EF6D-4558-A64E-003AFA234AEF@ccs.neu.edu> <4A119DC5.3080602@cs.utah.edu> Message-ID: <77D46946-B439-4CE1-ADE3-E12E208F6F05@knauth.org> On May 18, 2009, at 13:41, Jon Rafkind wrote: > I started a little gui for this last week. Here is a functional demo: > http://planet.plt-scheme.org/display.ss?package=planet-manager.plt&owner=kazzmir I like the prototype. After you figure out the "What versions are available on PLaneT?" DB question, here are some ideas for the GUI: Per package: - available versions on PLaneT (show options, select zero or more) - version(s) installed on local machine (select zero or more if uninstalling) - Install / Uninstall buttons, as you have - a button going to a doc page on the web in case package xyz is unfamiliar to the user - (maybe) an idea how often a package is used by all PLaneTeers Fancy/dancy: - a progress bar - something that tells the user how often he/she has actually used a package From meunier at ccs.neu.edu Tue May 19 04:08:04 2009 From: meunier at ccs.neu.edu (Philippe Meunier) Date: Tue May 19 04:32:46 2009 Subject: [plt-dev] compound units and contracted signatures Message-ID: <20090519080804.GA12298@denali.ccs.neu.edu> Hello, I've started using contracted signature for units, and I have a couple of comments. Here's a simple unit (in t-unit.ss): #lang scheme/unit (require "t-sig.ss") (import) (export (rename t^ (new-make-t make-t))) (define-struct t ()) (define (new-make-t s) (if (eq? s 'yes) (make-t) 33)) and the corresponding contracted signature in t-sig.ss: #lang scheme (provide t^) (define-signature t^ ((contracted (t? (any/c . -> . boolean?)) (make-t (symbol? . -> . t?))))) and it works great: > (define-values/invoke-unit t@ (import) (export t^)) > (make-t 'yes) # > (make-t 'no) (unit t@) broke the contract (-> symbol? t?) on make-t; expected , given: 33 I like the fact that the contracted t? can be used in another contract, that's great. Now I'd like to have another unit in s-unit.ss that imports t^: #lang scheme/unit (require "s-sig.ss" "t-sig.ss") (import t^) (export s^) (define (wrap-make-t x) (make-t x)) with the corresponding contracted signature in s-sig.ss: #lang scheme (provide s^) (define-signature s^ (t? ; already contracted in t-sig.ss (contracted (wrap-make-t (symbol? . -> . t?))))) and then create a compound unit: #lang scheme (require "t-unit.ss" "t-sig.ss" "s-unit.ss" "s-sig.ss") (define c@ (compound-unit (import) (export S) (link [((T : t^)) t@] [((S : s^)) s@ T]))) Unfortunately that doesn't work: define-unit: import t? is exported in: (define-unit s@ (import t^) (export s^) (define (wrap-make-t x) (make-t x))) So I have to do some extra gymnastic in s-unit.ss: #lang scheme/unit (require "s-sig.ss" "t-sig.ss") (import t^) (export (rename s^ (same-t? t?))) (define same-t? t?) (define (wrap-make-t x) (make-t x)) and the compound unit now works. So here are my comments: - I think it would be nice to get rid of the "imports cannot be exported" restriction. It looks to me like it only forces one to do extra gymnastic with things like same-t? and I'm not sure what the benefit of the restriction is. And if I have several imports that I want to re-export to use in the contracted signature s^ then using something like (define same-t? t?) multiple times becomes rapidly ugly. - It's a bit annoying that I have to have t? listed in both t^ and s^: (define-signature t^ ((contracted (t? (any/c . -> . boolean?)) (make-t (symbol? . -> . t?))))) (define-signature s^ (t? ; already contracted in t-sig.ss (contracted (wrap-make-t (symbol? . -> . t?))))) and that I have to remember that the t? in s^ should not be contracted a second time. It would be nicer to be able to simply define s^ as: (define-signature s^ ((contracted (wrap-make-t (symbol? . -> . t?))))) and then have a compound-unit-with-contracted-signatures form that would automatically bind the t? used in s^ with the t? contracted in t^ when the different pieces of the compound unit are put together. Any chance of having something like this in the future? :-) Philippe From mflatt at cs.utah.edu Tue May 19 11:41:00 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Tue May 19 11:41:19 2009 Subject: [plt-dev] all versions >= 4.1.5.x *very* broken in Windows In-Reply-To: <4A11A628.2030901@ccs.neu.edu> References: <4A11A628.2030901@ccs.neu.edu> Message-ID: <20090519154100.8EBCC6500C7@mail-svr1.cs.utah.edu> At Mon, 18 May 2009 14:17:12 -0400, Dave Herman wrote: > This is pretty critical: on Windows, recent versions of DrScheme are > repeatedly freezing. I've sent a couple emails about this, but I'm > seeing it more and more since then. I updated to 4.2.0.2 today and it's > just as bad or worse. > > It seems to be when DrScheme loses focus-- esp., I think, when part or > all of the window needs to be repainted-- and I try to refocus on > DrScheme and it won't come back. I have not been able to recreate the behavior, but I have a guess at the problem. Can you try the latest pre-release build (as of Tuesday, May 19 2009, 09:10 EDT)? From dherman at ccs.neu.edu Tue May 19 12:45:52 2009 From: dherman at ccs.neu.edu (Dave Herman) Date: Tue May 19 12:46:32 2009 Subject: [plt-dev] all versions >= 4.1.5.x *very* broken in Windows In-Reply-To: <20090519154100.8EBCC6500C7@mail-svr1.cs.utah.edu> References: <4A11A628.2030901@ccs.neu.edu> <20090519154100.8EBCC6500C7@mail-svr1.cs.utah.edu> Message-ID: <4A12E240.1020206@ccs.neu.edu> > I have not been able to recreate the behavior, but I have a guess at > the problem. Can you try the latest pre-release build (as of Tuesday, > May 19 2009, 09:10 EDT)? Downloading now. I should be spending a few hours coding today so I'll let you know if I can reproduce it. Dave From carl.eastlund at gmail.com Tue May 19 13:30:51 2009 From: carl.eastlund at gmail.com (Carl Eastlund) Date: Tue May 19 13:31:12 2009 Subject: [plt-dev] compound units and contracted signatures In-Reply-To: <20090519080804.GA12298@denali.ccs.neu.edu> References: <20090519080804.GA12298@denali.ccs.neu.edu> Message-ID: <990e0c030905191030j4bd06fc7hf938b57c7f391ca4@mail.gmail.com> Philippe, > - I think it would be nice to get rid of the "imports cannot be > ?exported" restriction. ?It looks to me like it only forces one to do > ?extra gymnastic with things like same-t? and I'm not sure what the > ?benefit of the restriction is. ?And if I have several imports that I > ?want to re-export to use in the contracted signature s^ then using > ?something like (define same-t? t?) multiple times becomes rapidly > ?ugly. The reason you can't export your imports is to prevent direct cycles in definitions. Consider U@ that imports x and exports it as y, and V@ that imports y and exports it as x. Linking U@ and V@ to form W@ results in a unit that exports x and y, neither of which has a definition at all. > - It's a bit annoying that I have to have t? listed in both t^ and s^: > > ?(define-signature t^ > ? ?((contracted (t? (any/c . -> . boolean?)) > ? ? ? ? ? ? ? ? (make-t (symbol? . -> . t?))))) > > ?(define-signature s^ > ? ?(t? ; already contracted in t-sig.ss > ? ? (contracted (wrap-make-t (symbol? . -> . t?))))) > > ?and that I have to remember that the t? in s^ should not be > ?contracted a second time. ?It would be nicer to be able to simply > ?define s^ as: > > ?(define-signature s^ > ? ?((contracted (wrap-make-t (symbol? . -> . t?))))) > > ?and then have a compound-unit-with-contracted-signatures form that > ?would automatically bind the t? used in s^ with the t? contracted in > ?t^ when the different pieces of the compound unit are put together. > ?Any chance of having something like this in the future? :-) I don't think either of your formulations -- importing t? from t^ and directly re-exporting it via s^, or simply leaving t? "free" in s^ -- express quite what I read from your code. It looks like you explicitly want wrap-make-t to share the same contract as make-t: they both map symbols to Ts, for the same notion of T. In the first case (t? in both s^ and t^), it would be trivial to write an implementation of s@ that exported an entirely different t? in s^ than it imported from t^. Thus make-t and wrap-make-t would actually have completely different output types, and their results would not be usable in the same context. You need a sharing constraint as in ML modules: the specification of make-t and wrap-make-t need the same T. In the second case (t? free in s^), you get "the same" t? as anything else you link to, but there's no guarantee in the signature that what you link to is t^. A client unit may import t^ and s^ and try to use make-t along with wrap-make-t... only to find that the imported s^ was actually constructed by linking with u^, which has a t? used for an entirely different purpose. Here, t? is shared, but with the wrong other thing. Stevie tells me there is currently no analogous feature to "sharing constraints" in unit contracts, but that he and Matthias are aware of the issue and considering several options for resolving it. For now you're probably stuck with the encoding you chose, but they're working on improving it. -- Carl Eastlund From dherman at ccs.neu.edu Tue May 19 16:50:32 2009 From: dherman at ccs.neu.edu (Dave Herman) Date: Tue May 19 16:51:16 2009 Subject: [plt-dev] all versions >= 4.1.5.x *very* broken in Windows In-Reply-To: <4A12E240.1020206@ccs.neu.edu> References: <4A11A628.2030901@ccs.neu.edu> <20090519154100.8EBCC6500C7@mail-svr1.cs.utah.edu> <4A12E240.1020206@ccs.neu.edu> Message-ID: <4A131B98.9040902@ccs.neu.edu> I'm afraid it just happened again. I've had DrScheme open for probably 5 or 6 hours, with two windows, several tabs each. I was switching from one window to the other, and it needed to completely repaint-- it's just a gray background-- but it froze. Processor idle, no disk thrashing. Windows reports the DrScheme image is taking about 180M (I've got the DrScheme memory limit set at 256M). Dave Dave Herman wrote: >> I have not been able to recreate the behavior, but I have a guess at >> the problem. Can you try the latest pre-release build (as of Tuesday, >> May 19 2009, 09:10 EDT)? > > Downloading now. I should be spending a few hours coding today so I'll > let you know if I can reproduce it. > > Dave > > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From dherman at ccs.neu.edu Tue May 19 17:00:02 2009 From: dherman at ccs.neu.edu (Dave Herman) Date: Tue May 19 17:00:46 2009 Subject: [plt-dev] all versions >= 4.1.5.x *very* broken in Windows In-Reply-To: <4A131B98.9040902@ccs.neu.edu> References: <4A11A628.2030901@ccs.neu.edu> <20090519154100.8EBCC6500C7@mail-svr1.cs.utah.edu> <4A12E240.1020206@ccs.neu.edu> <4A131B98.9040902@ccs.neu.edu> Message-ID: <4A131DD2.1040707@ccs.neu.edu> Ooh, and it just happened again-- I wonder if I'm getting closer to a method for reproducing. Stay tuned... Dave Dave Herman wrote: > I'm afraid it just happened again. I've had DrScheme open for probably 5 > or 6 hours, with two windows, several tabs each. I was switching from > one window to the other, and it needed to completely repaint-- it's just > a gray background-- but it froze. Processor idle, no disk thrashing. > Windows reports the DrScheme image is taking about 180M (I've got the > DrScheme memory limit set at 256M). > > Dave > > Dave Herman wrote: >>> I have not been able to recreate the behavior, but I have a guess at >>> the problem. Can you try the latest pre-release build (as of Tuesday, >>> May 19 2009, 09:10 EDT)? >> >> Downloading now. I should be spending a few hours coding today so I'll >> let you know if I can reproduce it. >> >> Dave >> >> _________________________________________________ >> For list-related administrative tasks: >> http://list.cs.brown.edu/mailman/listinfo/plt-dev > > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From dherman at ccs.neu.edu Tue May 19 17:08:24 2009 From: dherman at ccs.neu.edu (Dave Herman) Date: Tue May 19 17:09:05 2009 Subject: [plt-dev] all versions >= 4.1.5.x *very* broken in Windows In-Reply-To: <4A131DD2.1040707@ccs.neu.edu> References: <4A11A628.2030901@ccs.neu.edu> <20090519154100.8EBCC6500C7@mail-svr1.cs.utah.edu> <4A12E240.1020206@ccs.neu.edu> <4A131B98.9040902@ccs.neu.edu> <4A131DD2.1040707@ccs.neu.edu> Message-ID: <4A131FC8.7080105@ccs.neu.edu> Okay, I got it. Here's how I can reproduce it quickly and reliably: Open collects/mzlib/thread.ss in a new window. Scroll down so the lambda expression on line 63 is towards the top of the window, and position the keyboard cursor at 63:8, i.e. the outside of the lambda expression, so that a very large portion of the window is highlighted gray. Maximize the window. Now open a new window. Open collects/mzlib/private/structure-helper.ss. Leave the keyboard cursor at the initial position, so the whole definitions window is selected and highlighted gray. Maximize the window. Now alt-tab back and forth quickly between the two windows. After four or five switches, DrScheme reliably freezes. Dave Dave Herman wrote: > Ooh, and it just happened again-- I wonder if I'm getting closer to a > method for reproducing. Stay tuned... > > Dave > > Dave Herman wrote: >> I'm afraid it just happened again. I've had DrScheme open for probably >> 5 or 6 hours, with two windows, several tabs each. I was switching >> from one window to the other, and it needed to completely repaint-- >> it's just a gray background-- but it froze. Processor idle, no disk >> thrashing. Windows reports the DrScheme image is taking about 180M >> (I've got the DrScheme memory limit set at 256M). >> >> Dave >> >> Dave Herman wrote: >>>> I have not been able to recreate the behavior, but I have a guess at >>>> the problem. Can you try the latest pre-release build (as of Tuesday, >>>> May 19 2009, 09:10 EDT)? >>> >>> Downloading now. I should be spending a few hours coding today so >>> I'll let you know if I can reproduce it. >>> >>> Dave >>> >>> _________________________________________________ >>> For list-related administrative tasks: >>> http://list.cs.brown.edu/mailman/listinfo/plt-dev >> >> _________________________________________________ >> For list-related administrative tasks: >> http://list.cs.brown.edu/mailman/listinfo/plt-dev > > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From mflatt at cs.utah.edu Tue May 19 18:06:40 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Tue May 19 18:07:03 2009 Subject: [plt-dev] all versions >= 4.1.5.x *very* broken in Windows In-Reply-To: <4A131FC8.7080105@ccs.neu.edu> References: <4A11A628.2030901@ccs.neu.edu> <20090519154100.8EBCC6500C7@mail-svr1.cs.utah.edu> <4A12E240.1020206@ccs.neu.edu> <4A131B98.9040902@ccs.neu.edu> <4A131DD2.1040707@ccs.neu.edu> <4A131FC8.7080105@ccs.neu.edu> Message-ID: <20090519220640.747E16500BA@mail-svr1.cs.utah.edu> Thanks! I have not been able to fix it, yet, but I can easily reproduce the problem using these directions. At Tue, 19 May 2009 17:08:24 -0400, Dave Herman wrote: > Okay, I got it. Here's how I can reproduce it quickly and reliably: > > Open collects/mzlib/thread.ss in a new window. Scroll down so the lambda > expression on line 63 is towards the top of the window, and position the > keyboard cursor at 63:8, i.e. the outside of the lambda expression, so > that a very large portion of the window is highlighted gray. Maximize > the window. > > Now open a new window. Open collects/mzlib/private/structure-helper.ss. > Leave the keyboard cursor at the initial position, so the whole > definitions window is selected and highlighted gray. Maximize the window. > > Now alt-tab back and forth quickly between the two windows. After four > or five switches, DrScheme reliably freezes. > > Dave > > Dave Herman wrote: > > Ooh, and it just happened again-- I wonder if I'm getting closer to a > > method for reproducing. Stay tuned... > > > > Dave > > > > Dave Herman wrote: > >> I'm afraid it just happened again. I've had DrScheme open for probably > >> 5 or 6 hours, with two windows, several tabs each. I was switching > >> from one window to the other, and it needed to completely repaint-- > >> it's just a gray background-- but it froze. Processor idle, no disk > >> thrashing. Windows reports the DrScheme image is taking about 180M > >> (I've got the DrScheme memory limit set at 256M). > >> > >> Dave > >> > >> Dave Herman wrote: > >>>> I have not been able to recreate the behavior, but I have a guess at > >>>> the problem. Can you try the latest pre-release build (as of Tuesday, > >>>> May 19 2009, 09:10 EDT)? > >>> > >>> Downloading now. I should be spending a few hours coding today so > >>> I'll let you know if I can reproduce it. > >>> > >>> Dave > >>> > >>> _________________________________________________ > >>> For list-related administrative tasks: > >>> http://list.cs.brown.edu/mailman/listinfo/plt-dev > >> > >> _________________________________________________ > >> For list-related administrative tasks: > >> http://list.cs.brown.edu/mailman/listinfo/plt-dev > > > > _________________________________________________ > > For list-related administrative tasks: > > http://list.cs.brown.edu/mailman/listinfo/plt-dev From mflatt at cs.utah.edu Tue May 19 19:59:31 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Tue May 19 20:00:01 2009 Subject: [plt-dev] all versions >= 4.1.5.x *very* broken in Windows In-Reply-To: <20090519220640.747E16500BA@mail-svr1.cs.utah.edu> References: <4A11A628.2030901@ccs.neu.edu> <20090519154100.8EBCC6500C7@mail-svr1.cs.utah.edu> <4A12E240.1020206@ccs.neu.edu> <4A131B98.9040902@ccs.neu.edu> <4A131DD2.1040707@ccs.neu.edu> <4A131FC8.7080105@ccs.neu.edu> <20090519220640.747E16500BA@mail-svr1.cs.utah.edu> Message-ID: <20090519235932.83E56650091@mail-svr1.cs.utah.edu> This should be fixed, now. At Tue, 19 May 2009 16:06:40 -0600, Matthew Flatt wrote: > Thanks! I have not been able to fix it, yet, but I can easily reproduce > the problem using these directions. > > At Tue, 19 May 2009 17:08:24 -0400, Dave Herman wrote: > > Okay, I got it. Here's how I can reproduce it quickly and reliably: > > > > Open collects/mzlib/thread.ss in a new window. Scroll down so the lambda > > expression on line 63 is towards the top of the window, and position the > > keyboard cursor at 63:8, i.e. the outside of the lambda expression, so > > that a very large portion of the window is highlighted gray. Maximize > > the window. > > > > Now open a new window. Open collects/mzlib/private/structure-helper.ss. > > Leave the keyboard cursor at the initial position, so the whole > > definitions window is selected and highlighted gray. Maximize the window. > > > > Now alt-tab back and forth quickly between the two windows. After four > > or five switches, DrScheme reliably freezes. > > > > Dave > > > > Dave Herman wrote: > > > Ooh, and it just happened again-- I wonder if I'm getting closer to a > > > method for reproducing. Stay tuned... > > > > > > Dave > > > > > > Dave Herman wrote: > > >> I'm afraid it just happened again. I've had DrScheme open for probably > > >> 5 or 6 hours, with two windows, several tabs each. I was switching > > >> from one window to the other, and it needed to completely repaint-- > > >> it's just a gray background-- but it froze. Processor idle, no disk > > >> thrashing. Windows reports the DrScheme image is taking about 180M > > >> (I've got the DrScheme memory limit set at 256M). > > >> > > >> Dave > > >> > > >> Dave Herman wrote: > > >>>> I have not been able to recreate the behavior, but I have a guess at > > >>>> the problem. Can you try the latest pre-release build (as of Tuesday, > > >>>> May 19 2009, 09:10 EDT)? > > >>> > > >>> Downloading now. I should be spending a few hours coding today so > > >>> I'll let you know if I can reproduce it. > > >>> > > >>> Dave > > >>> > > >>> _________________________________________________ > > >>> For list-related administrative tasks: > > >>> http://list.cs.brown.edu/mailman/listinfo/plt-dev > > >> > > >> _________________________________________________ > > >> For list-related administrative tasks: > > >> http://list.cs.brown.edu/mailman/listinfo/plt-dev > > > > > > _________________________________________________ > > > For list-related administrative tasks: > > > http://list.cs.brown.edu/mailman/listinfo/plt-dev > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From meunier at ccs.neu.edu Tue May 19 22:33:52 2009 From: meunier at ccs.neu.edu (Philippe Meunier) Date: Tue May 19 22:34:11 2009 Subject: [plt-dev] compound units and contracted signatures In-Reply-To: <990e0c030905191030j4bd06fc7hf938b57c7f391ca4@mail.gmail.com> References: <20090519080804.GA12298@denali.ccs.neu.edu> <990e0c030905191030j4bd06fc7hf938b57c7f391ca4@mail.gmail.com> Message-ID: <20090520023352.GA4788@denali.ccs.neu.edu> Carl Eastlund wrote: >The reason you can't export your imports is to prevent direct cycles >in definitions. Okay, but IMHO the cure might be worse than the disease. I have a program with seven units, and three of them have to re-export some imports (two out of these three cases are because of contracted signatures) and all the (define same-t? t?) followed by renames of same-t? into t? in unit exports are a bit of a pain. Just saying :-) >It looks like you >explicitly want wrap-make-t to share the same contract as make-t: they >both map symbols to Ts, for the same notion of T. Yes. >In the first case (t? in both s^ and t^), it would be trivial to write >an implementation of s@ that exported an entirely different t? in s^ >than it imported from t^. Thus make-t and wrap-make-t would actually >have completely different output types, and their results would not be >usable in the same context. Yes, but see below. >You need a sharing constraint as in ML >modules: the specification of make-t and wrap-make-t need the same T. Yes. That's why I'm suggesting something like compound-unit-with-contracted-signatures where the sharing constraint would be implicitely specified based only on the names used in the signatures. I believe that in the vast majority of cases this would just be the right thing to do, since in practice people do not tend to to use the same names for different data structures. If, as in your example above, two units exported incompatible t? predicates, then either compound-unit-with-contracted-signatures would fail at expansion-time with a message like "two units export t? so I don't know which one you want me to use in the signature contract (symbol? . -> . t?)", or, less nicely, the user would just get a runtime contract failure saying "expected , given: #" (which is the kind of error message you already get today when two modules provide data structures with the same name and you mix them up). In such a case the programmer would just have to rename one of the data structure, or use some kind of prefix system. >In the second case (t? free in s^), you get "the same" t? as anything >else you link to, but there's no guarantee in the signature that what >you link to is t^. A client unit may import t^ and s^ and try to use >make-t along with wrap-make-t... only to find that the imported s^ was >actually constructed by linking with u^, which has a t? used for an >entirely different purpose. Here, t? is shared, but with the wrong >other thing. Then when you link your units together using compound-unit-with-contracted-signatures you'd get an error message saying "t@ and u@ both export t? so I don't know which one to use in the contract of s^". >Stevie tells me there is currently no analogous feature to "sharing >constraints" in unit contracts, but that he and Matthias are aware of >the issue and considering several options for resolving it. Great. Thanks, Philippe From carl.eastlund at gmail.com Tue May 19 23:06:58 2009 From: carl.eastlund at gmail.com (Carl Eastlund) Date: Tue May 19 23:07:17 2009 Subject: [plt-dev] compound units and contracted signatures In-Reply-To: <20090520023352.GA4788@denali.ccs.neu.edu> References: <20090519080804.GA12298@denali.ccs.neu.edu> <990e0c030905191030j4bd06fc7hf938b57c7f391ca4@mail.gmail.com> <20090520023352.GA4788@denali.ccs.neu.edu> Message-ID: <990e0c030905192006g62f73b02je013a81e1a705904@mail.gmail.com> On Tue, May 19, 2009 at 10:33 PM, Philippe Meunier wrote: > Carl Eastlund wrote: >>The reason you can't export your imports is to prevent direct cycles >>in definitions. > > Okay, but IMHO the cure might be worse than the disease. ?I have a > program with seven units, and three of them have to re-export some > imports (two out of these three cases are because of contracted > signatures) and all the (define same-t? t?) followed by renames of > same-t? into t? in unit exports are a bit of a pain. ?Just saying :-) The cure predates the disease, in this case. >>It looks like you >>explicitly want wrap-make-t to share the same contract as make-t: they >>both map symbols to Ts, for the same notion of T. > > Yes. > >>In the first case (t? in both s^ and t^), it would be trivial to write >>an implementation of s@ that exported an entirely different t? in s^ >>than it imported from t^. ?Thus make-t and wrap-make-t would actually >>have completely different output types, and their results would not be >>usable in the same context. > > Yes, but see below. > >>You need a sharing constraint as in ML >>modules: the specification of make-t and wrap-make-t need the same T. > > Yes. ?That's why I'm suggesting something like > compound-unit-with-contracted-signatures where the sharing constraint > would be implicitely specified based only on the names used in the > signatures. ?I believe that in the vast majority of cases this would > just be the right thing to do, since in practice people do not tend to > to use the same names for different data structures. > > If, as in your example above, two units exported incompatible t? > predicates, then either compound-unit-with-contracted-signatures would > fail at expansion-time with a message like "two units export t? so I > don't know which one you want me to use in the signature contract > (symbol? . -> . t?)", or, less nicely, the user would just get a > runtime contract failure saying "expected , given: #" (which is > the kind of error message you already get today when two modules > provide data structures with the same name and you mix them up). ?In > such a case the programmer would just have to rename one of the data > structure, or use some kind of prefix system. All of this assumes inferred linking, and that compound units export all signatures. For explicit linking that may hide some exports, your reasoning does not apply. You can have many different t?'s, and a later linking won't see earlier ones. And for uses of units that instantiate some generic library for particular dependencies -- say, a set unit based on an ordered type, instantiated on different types -- (a) there may be many Ts, and (b) it is important to contract based on the right Ts. While we don't use units for these things a lot in Scheme, it's a use case that gets more and more realistic with things like (a) inferred linking, making units syntactically lighter weight, and (b) Typed Scheme, typed idioms necessitating this kind of instantiation more often. >>In the second case (t? free in s^), you get "the same" t? as anything >>else you link to, but there's no guarantee in the signature that what >>you link to is t^. ?A client unit may import t^ and s^ and try to use >>make-t along with wrap-make-t... only to find that the imported s^ was >>actually constructed by linking with u^, which has a t? used for an >>entirely different purpose. ?Here, t? is shared, but with the wrong >>other thing. > > Then when you link your units together using > compound-unit-with-contracted-signatures you'd get an error message > saying "t@ and u@ both export t? so I don't know which one to use in > the contract of s^". > >>Stevie tells me there is currently no analogous feature to "sharing >>constraints" in unit contracts, but that he and Matthias are aware of >>the issue and considering several options for resolving it. > > Great. > > Thanks, > > Philippe From jay.mccarthy at gmail.com Tue May 19 23:09:36 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Tue May 19 23:09:59 2009 Subject: [plt-dev] compound units and contracted signatures In-Reply-To: <990e0c030905192006g62f73b02je013a81e1a705904@mail.gmail.com> References: <20090519080804.GA12298@denali.ccs.neu.edu> <990e0c030905191030j4bd06fc7hf938b57c7f391ca4@mail.gmail.com> <20090520023352.GA4788@denali.ccs.neu.edu> <990e0c030905192006g62f73b02je013a81e1a705904@mail.gmail.com> Message-ID: On Tue, May 19, 2009 at 9:06 PM, Carl Eastlund wrote: > While we don't use units for these things a lot in Scheme, it's a use > case that gets more and more realistic with things like (a) inferred > linking, making units syntactically lighter weight, and (b) Typed > Scheme, typed idioms necessitating this kind of instantiation more > often. Annoyances like those Philippe is mentioning are exactly why I don't use units more often. My 2 cents, Jay -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From carl.eastlund at gmail.com Tue May 19 23:12:44 2009 From: carl.eastlund at gmail.com (Carl Eastlund) Date: Tue May 19 23:13:03 2009 Subject: [plt-dev] compound units and contracted signatures In-Reply-To: References: <20090519080804.GA12298@denali.ccs.neu.edu> <990e0c030905191030j4bd06fc7hf938b57c7f391ca4@mail.gmail.com> <20090520023352.GA4788@denali.ccs.neu.edu> <990e0c030905192006g62f73b02je013a81e1a705904@mail.gmail.com> Message-ID: <990e0c030905192012x57259f2ay42fa662350cac8b8@mail.gmail.com> On Tue, May 19, 2009 at 11:09 PM, Jay McCarthy wrote: > On Tue, May 19, 2009 at 9:06 PM, Carl Eastlund wrote: >> While we don't use units for these things a lot in Scheme, it's a use >> case that gets more and more realistic with things like (a) inferred >> linking, making units syntactically lighter weight, and (b) Typed >> Scheme, typed idioms necessitating this kind of instantiation more >> often. > > Annoyances like those Philippe is mentioning are exactly why I don't > use units more often. > > My 2 cents, > > Jay Philippe is only describing problems of units with contracts, which are very, very new. None of this applies to units without contracts. Have I missed something? -- Carl Eastlund From jay.mccarthy at gmail.com Tue May 19 23:15:26 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Tue May 19 23:15:48 2009 Subject: [plt-dev] compound units and contracted signatures In-Reply-To: <990e0c030905192012x57259f2ay42fa662350cac8b8@mail.gmail.com> References: <20090519080804.GA12298@denali.ccs.neu.edu> <990e0c030905191030j4bd06fc7hf938b57c7f391ca4@mail.gmail.com> <20090520023352.GA4788@denali.ccs.neu.edu> <990e0c030905192006g62f73b02je013a81e1a705904@mail.gmail.com> <990e0c030905192012x57259f2ay42fa662350cac8b8@mail.gmail.com> Message-ID: On Tue, May 19, 2009 at 9:12 PM, Carl Eastlund wrote: > Philippe is only describing problems of units with contracts, which > are very, very new. ?None of this applies to units without contracts. > Have I missed something? The exporting importing problem is about non-contracted units. But, not having contracts in units was always a detriment to use them for me, now that we have those, I'm observing all sorts of other annoyances when I tried to use them in ways like Philippe mentions. Nevertheless, what everyone who's been involved with units has done---Matthew, Scott, Stevie---is amazing and very cool. But we're not /there/ yet. Jay -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From carl.eastlund at gmail.com Tue May 19 23:16:30 2009 From: carl.eastlund at gmail.com (Carl Eastlund) Date: Tue May 19 23:16:50 2009 Subject: [plt-dev] compound units and contracted signatures In-Reply-To: References: <20090519080804.GA12298@denali.ccs.neu.edu> <990e0c030905191030j4bd06fc7hf938b57c7f391ca4@mail.gmail.com> <20090520023352.GA4788@denali.ccs.neu.edu> <990e0c030905192006g62f73b02je013a81e1a705904@mail.gmail.com> <990e0c030905192012x57259f2ay42fa662350cac8b8@mail.gmail.com> Message-ID: <990e0c030905192016v4ad5b91bv2cd2bd6a56590fc7@mail.gmail.com> On Tue, May 19, 2009 at 11:15 PM, Jay McCarthy wrote: > On Tue, May 19, 2009 at 9:12 PM, Carl Eastlund wrote: >> Philippe is only describing problems of units with contracts, which >> are very, very new. ?None of this applies to units without contracts. >> Have I missed something? > > The exporting importing problem is about non-contracted units. True, but Philippe's need for it was. > But, not having contracts in units was always a detriment to use them > for me, now that we have those, I'm observing all sorts of other > annoyances when I tried to use them in ways like Philippe mentions. > > Nevertheless, what everyone who's been involved with units has > done---Matthew, Scott, Stevie---is amazing and very cool. But we're > not /there/ yet. That, I agree with. Always good to come closer. -- Carl Eastlund From meunier at ccs.neu.edu Wed May 20 01:12:29 2009 From: meunier at ccs.neu.edu (Philippe Meunier) Date: Wed May 20 01:12:49 2009 Subject: [plt-dev] compound units and contracted signatures In-Reply-To: <990e0c030905192006g62f73b02je013a81e1a705904@mail.gmail.com> References: <990e0c030905192012x57259f2ay42fa662350cac8b8@mail.gmail.com> <20090519080804.GA12298@denali.ccs.neu.edu> <990e0c030905191030j4bd06fc7hf938b57c7f391ca4@mail.gmail.com> <20090520023352.GA4788@denali.ccs.neu.edu> <990e0c030905192006g62f73b02je013a81e1a705904@mail.gmail.com> <20090519080804.GA12298@denali.ccs.neu.edu> <990e0c030905191030j4bd06fc7hf938b57c7f391ca4@mail.gmail.com> <20090520023352.GA4788@denali.ccs.neu.edu> <990e0c030905192006g62f73b02je013a81e1a705904@mail.gmail.com> Message-ID: <20090520051229.GA10561@denali.ccs.neu.edu> Carl Eastlund wrote: >Philippe wrote: >> Carl Eastlund wrote: >All of this assumes inferred linking, and that compound units export >all signatures. It wouldn't have to explicitly export all signatures, each compound unit could just have some special attribute somewhere to keep track of which linking assumptions have been made so far. Implementation details :-) >For explicit linking that may hide some exports, your >reasoning does not apply. You can have many different t?'s, and a >later linking won't see earlier ones. I'm not saying it's perfect, I'm just saying that in the most common linking case it's quite obvious where the t? predicate should come from, and that it would be nice to have a form like compound-unit-with-contracted-signatures to handle that common case more smoothly, that's all. Carl Eastlund wrote: >Jay McCarthy wrote: >> Carl Eastlund wrote: >>> Philippe is only describing problems of units with contracts, which >>> are very, very new. None of this applies to units without contracts. >>> Have I missed something? >> >> The exporting importing problem is about non-contracted units. > >True, but Philippe's need for it was. Actually, I said that, out of my three units that have to re-export imports, two do it because of contracted signatures. The third one is different: I'm implementing the equivalent of the adapter pattern using units. Something like this: u1 --b,c--> u0 --a,c--> drscheme where u0 acts as an adapter between u1 and drscheme that transforms functions like b into functions like a. The problem is that some functions like c that are exported by u1 don't really need to be adapted in u0, they could just be directly re-exported, but that's not possible. So I have either to do the re-define/rename dance inside u0 to go around the restriction on re-exporting the import c, or I have to split the signature of u1 into two parts, one that's imported by u0 to be adapted, and one that bypasses u0 entirely: u1 --b--> u0 --a--> drscheme | ^ | | +---------c----------+ This works too, but it means I have to tell the person implementing u1 to deal with two separate signatures instead of just one, for no obvious reason (from their point of view). So I just do the re-define/rename thing instead, since then I'm the one dealing with the small extra complexity, not the other person. For this problem too I think that the nicest solution would be to remove the not-re-exporting-imports restriction, but that's just me :-) All in all, there are fairly simple ways to go around all the various little problems with units, it's just that none of them are really nice. >> But, not having contracts in units was always a detriment to use them >> for me, now that we have those, I'm observing all sorts of other >> annoyances when I tried to use them in ways like Philippe mentions. Yes, my experience so far is that contracted signatures do exacerbate the not-re-exporting-imports problem. That being said, contracted signatures are great, and the unit system is definitely getting better (scheme/unit makes life quite a bit easier, for example). Philippe From eli at barzilay.org Wed May 20 06:05:08 2009 From: eli at barzilay.org (Eli Barzilay) Date: Wed May 20 06:05:38 2009 Subject: [plt-dev] Pre-Release Checklist for v4.2 Message-ID: Checklist items for the v4.2 release (using the v4.1.900 alpha build) Search for your name to find relevant items, reply when you finish an item (please indicate which item is done). Also, if you have any commits that should have been merged, make sure that they're in. Important: new builds are created without announcement, usually whenever I see significant commits. If you need to commit changes, please make sure you tell me to merge it to the release branch. --> Release candidates are at --> http://pre.plt-scheme.org/release/installers Please use these installers (or source bundles) -- don't test from your own svn chekout (don't test v4.2.0.2 by mistake!). To get the tests directory in the normal release, you can do this: cd .../collects svn export http://svn.plt-scheme.org/plt/release/collects/tests ---------------------------------------------------------------------- *** Testing: * Matthew Flatt - MzScheme Tests - Languages Tests - MrEd Tests (Also check that `mred -z' and `mred-text' still works in Windows and Mac OS X) - mzc Tests - mzc --exe tests - .plt-packing Tests - Games Tests - Unit Tests - Syntax Color Tests - R6RS Tests Updates: - MzScheme Updates: update HISTORY - MrEd Updates: update README, HISTORY (updates should show v4.2 as the most current version) - Update man pages in plt/man/man1: mred.1, mzscheme.1 Email me to merge the changes from the trunk when they're done, or tell me if there are no such changes. * Robby Findler - DrScheme Tests - Framework Tests - Contracts Tests - Games Tests - Teachpacks Tests: image tests - PLaneT Tests Updates: - DrScheme Updates: update HISTORY - Redex Updates: update HISTORY (updates should show v4.2 as the most current version) - Ensure that previous version of DrScheme's preference files still starts up with new DrScheme - Update man pages in plt/man/man1: drscheme.1 Email me to merge the changes from the trunk 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 v4.2 as the most current version) Email me to merge the changes from the trunk 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 Updates: - Teachpack Updates: update HISTORY (updates should show v4.2 as the most current version; email me to merge the changes from the trunk when they're done, or tell me if there are no such changes.) * Ryan Culpepper - Macro Debugger Tests - Syntax Classifier Tests * Jay McCarthy - Web server Tests - XML Tests - HTML Tests * Paul Steckler - MysterX Tests - MzCOM Tests * Kathy Gray - ProfJ Tests - Test Engine Tests * Noel Welsh , Chongkai Zhu - SRFI Tests - Ensure that all claimed srfi's are in the bundle and they all load into mzscheme or drscheme (as appropriate) * Sam Tobin-Hochstadt - Match Tests - Typed Scheme Tests * Stevie Strickland - Unit Contract Tests - Contract Region Tests * Eli Barzilay - Swindle Tests - Plot Tests - PLT Tree: compare new distribution trees to previous ones Version Updates: if a major change has happened, update the version number in: - plt/collects/mzscheme/info.ss - plt/collects/mred/info.ss * Doug Williams - Plot Tests * Greg Cooper - FrTime Tests * Carl Eastlund - Dracula Tests (confirm that Dracula runs from PLaneT) * Shriram Krishnamurthi Tour: check the tour and generate a new one if needed. [Note: Since this is a v4.1.900 build, you will need to edit your .../collects/framework/private/version.ss file and change `(version)' to `"4.2"'.] -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From jay at cs.brown.edu Wed May 20 10:47:44 2009 From: jay at cs.brown.edu (Jay McCarthy) Date: Wed May 20 10:48:04 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.2 In-Reply-To: References: Message-ID: On Wed, May 20, 2009 at 4:05 AM, Eli Barzilay wrote: > * Jay McCarthy > ?- Web server Tests > ?- XML Tests > ?- HTML Tests Done -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From pocmatos at gmail.com Wed May 20 10:49:46 2009 From: pocmatos at gmail.com (Paulo J. Matos) Date: Wed May 20 10:50:28 2009 Subject: [plt-dev] Debugging generates internal error Message-ID: <11b141710905200749s30550484mde785779d3758748@mail.gmail.com> Using version 4.2.0.2-svn17may2009 [3m] under linux generated an error I cannot reproduce now: sequence-contract-violation: negative: method set-max-width cannot be called, except in states (unlocked write-lock), args 689 === context === /home/pmatos/Applications/plt/plt-r14851/lib/plt/collects/scheme/private/more-scheme.ss:155:2: call-with-break-parameterization /home/pmatos/Applications/plt/plt-r14851/lib/plt/collects/scheme/private/more-scheme.ss:271:2: call-with-exception-handler /home/pmatos/Applications/plt/plt-r14851/lib/plt/collects/scheme/private/more-scheme.ss:155:2: call-with-break-parameterization /home/pmatos/Applications/plt/plt-r14851/lib/plt/collects/scheme/private/more-scheme.ss:271:2: call-with-exception-handler /home/pmatos/Applications/plt/plt-r14851/lib/plt/collects/drscheme/private/unit.ss:2826:8: restore-visible-tab-regions method in ...heme/private/unit.ss:1382:6 /home/pmatos/Applications/plt/plt-r14851/lib/plt/collects/drscheme/private/unit.ss:2713:8: change-to-tab method in ...heme/private/unit.ss:1382:6 /home/pmatos/Applications/plt/plt-r14851/lib/plt/collects/framework/private/handler.ss:94:5 /home/pmatos/Applications/plt/plt-r14851/lib/plt/collects/scheme/private/contract-arrow.ss:1364:3 If I am able to reproduce it further, I will let you know. Cheers, -- Paulo Jorge Matos - pocmatos at gmail.com Webpage: http://www.personal.soton.ac.uk/pocm From matthias at ccs.neu.edu Wed May 20 11:41:16 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Wed May 20 11:42:00 2009 Subject: [plt-dev] compound units and contracted signatures In-Reply-To: <20090520051229.GA10561@denali.ccs.neu.edu> References: <990e0c030905192012x57259f2ay42fa662350cac8b8@mail.gmail.com> <20090519080804.GA12298@denali.ccs.neu.edu> <990e0c030905191030j4bd06fc7hf938b57c7f391ca4@mail.gmail.com> <20090520023352.GA4788@denali.ccs.neu.edu> <990e0c030905192006g62f73b02je013a81e1a705904@mail.gmail.com> <20090519080804.GA12298@denali.ccs.neu.edu> <990e0c030905191030j4bd06fc7hf938b57c7f391ca4@mail.gmail.com> <20090520023352.GA4788@denali.ccs.neu.edu> <990e0c030905192006g62f73b02je013a81e1a705904@mail.gmail.com> <20090520051229.GA10561@denali.ccs.neu.edu> Message-ID: (We do want to promote units but to be honest, I considered contracted units a 'warm up' exercise for Stevie :-) Philippe, do you realize that F/F units used structural sig matching (they are Matthew's response to my finding faults with struct/functors) O/F units use nomimal sig matching? While I was surprised at first, it started to make sense as Stevie and I worked through the exercise of adding contracts. Matthew and I lived in a "free" world where sigs just mentioned names and there was no meaning attached to them at all. I never figured out whether our type system was pragmatic. In this day and age, I'd say my grandmother could have designed it (if she were alive). The very moment you introduce some amount of meaning (even an epsilon such as a type) or a lot (such as a contract) -- you seem to get some of the ML-style problems. BUT nominal matching ensures that you can say "the same t as over there" with importing appropriately. The name of the sig determines sameness, no sharing constraints needed. Yet. The problem with cyclic export/import comes out most when you think about cyclic datatypes. ML style type systems can't allow that. Neither can we. So we will have to think hard about this one. For now I recommend using macros to overcome the problem. -- Matthias From matthias at ccs.neu.edu Wed May 20 12:41:46 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Wed May 20 12:42:29 2009 Subject: [plt-dev] range Message-ID: <23E43BFB-0006-4D8D-A7C9-8CE5D1FE2DC5@ccs.neu.edu> Is there a function that computes such lists: > ;; Nat Nat -> [Listof Nat] > (define (range lo hi) > (if (>= hi lo) > (build-list (+ (- hi lo) 1) (lambda (i) (+ lo i))) > (build-list (+ (- lo hi) 1) (lambda (i) (- lo i))))) From eli at barzilay.org Wed May 20 13:35:31 2009 From: eli at barzilay.org (Eli Barzilay) Date: Wed May 20 13:35:53 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.2 In-Reply-To: References: Message-ID: <18964.16227.558746.395835@winooski.ccs.neu.edu> On May 20, Eli Barzilay wrote: > > --> Release candidates are at > --> http://pre.plt-scheme.org/release/installers The URL wasn't working -- fixed now. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From dherman at ccs.neu.edu Wed May 20 15:35:10 2009 From: dherman at ccs.neu.edu (Dave Herman) Date: Wed May 20 15:35:35 2009 Subject: [plt-dev] strange printing problems in Windows Message-ID: <4A145B6E.5020907@ccs.neu.edu> When I try to print from Windows, it seems to truncate portions of the document. I tried printing the definitions window earlier today and it only printed the first 6 pages of maybe a 7 or 8 page file. When I print the interactions window, it only prints a few pages at a time. I had about 16 pages of REPL interaction I wanted to print, and I had to print it in 6 chunks: 1. pp. 1 - 5 2. pp. 6 - 9 3. pp. 10 - 11 4. pp. 12 - 13 5. p. 14 6. p. 15 The bottom of the p. 15 cuts off partway through, and it won't print anything after that. When I have a shorter REPL interaction, it prints it all in one chunk, but it still just cuts off at some point. Dave From carl.eastlund at gmail.com Wed May 20 16:14:45 2009 From: carl.eastlund at gmail.com (Carl Eastlund) Date: Wed May 20 16:15:04 2009 Subject: [plt-dev] Pre-Release Checklist for v4.2 In-Reply-To: References: Message-ID: <990e0c030905201314h720d5d42lb6bd076a56563b31@mail.gmail.com> On Wed, May 20, 2009 at 6:05 AM, Eli Barzilay wrote: > > * Carl Eastlund > ?- Dracula Tests (confirm that Dracula runs from PLaneT) Done. -- Carl Eastlund From mflatt at cs.utah.edu Wed May 20 17:25:38 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Wed May 20 17:26:02 2009 Subject: [plt-dev] strange printing problems in Windows In-Reply-To: <4A145B6E.5020907@ccs.neu.edu> References: <4A145B6E.5020907@ccs.neu.edu> Message-ID: <20090520212539.3DC57650091@mail-svr1.cs.utah.edu> I've fixed a bug where printing sessions in an editor were closed incorrectly, and I expect that will fix the problem. Thanks for the report! At Wed, 20 May 2009 15:35:10 -0400, Dave Herman wrote: > When I try to print from Windows, it seems to truncate portions of the > document. I tried printing the definitions window earlier today and it > only printed the first 6 pages of maybe a 7 or 8 page file. When I print > the interactions window, it only prints a few pages at a time. I had > about 16 pages of REPL interaction I wanted to print, and I had to print > it in 6 chunks: > > 1. pp. 1 - 5 > 2. pp. 6 - 9 > 3. pp. 10 - 11 > 4. pp. 12 - 13 > 5. p. 14 > 6. p. 15 > > The bottom of the p. 15 cuts off partway through, and it won't print > anything after that. > > When I have a shorter REPL interaction, it prints it all in one chunk, > but it still just cuts off at some point. > > Dave > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From clements at brinckerhoff.org Wed May 20 17:45:34 2009 From: clements at brinckerhoff.org (John Clements) Date: Wed May 20 17:49:03 2009 Subject: [plt-dev] Q. about contract of drscheme:eval:expand-program Message-ID: The contract for drscheme:eval:expand-program specifies that it accepts an 'iter' argument fulfilling this contract: (-> (or/c eof-object? syntax? (cons/c string? any/c)) (-> any) any) I'm wondering why the (cons/c string? any/c) is in there. The documentation states: The first argument to iter is the expanded program (represented as syntax) or eof. The iter argument is called for each expression in the expanded program and once more with eof, unless an error is raised during expansion. It is called from the user?s thread. If an exception is raised during expansion of the user?s program, iter is not called. Consider setting the exception-handler during init to handle this situation. ... so, under what circumstances does expand-program call iter with (cons/c string? any/c) ? John -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2484 bytes Desc: not available Url : http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090520/2fad1bdd/smime.bin From robby at eecs.northwestern.edu Wed May 20 17:57:36 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Wed May 20 17:57:57 2009 Subject: [plt-dev] Q. about contract of drscheme:eval:expand-program In-Reply-To: References: Message-ID: <932b2f1f0905201457v4646c200j9d9b39056d01b10f@mail.gmail.com> Oh yes, you're right. That is old. Robby On Wed, May 20, 2009 at 4:45 PM, John Clements wrote: > The contract for drscheme:eval:expand-program specifies that it accepts an > 'iter' argument fulfilling this contract: > > (-> (or/c eof-object? syntax? (cons/c string? any/c)) > ? ?(-> any) > ? ?any) > > I'm wondering why the (cons/c string? any/c) is in there. ?The documentation > states: > > The first argument to iter is the expanded program (represented as syntax) > or eof. The iter argument is called for each expression in the expanded > program and once more with eof, unless an error is raised during expansion. > It is called from the user?s thread. If an exception is raised during > expansion of the user?s program, iter is not called. Consider setting the > exception-handler during init to handle this situation. > > ... so, under what circumstances does expand-program call iter with (cons/c > string? any/c) ? > > > John > > > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > > From dherman at ccs.neu.edu Wed May 20 18:13:27 2009 From: dherman at ccs.neu.edu (Dave Herman) Date: Wed May 20 18:13:57 2009 Subject: [plt-dev] strange printing problems in Windows In-Reply-To: <20090520212539.3DC57650091@mail-svr1.cs.utah.edu> References: <4A145B6E.5020907@ccs.neu.edu> <20090520212539.3DC57650091@mail-svr1.cs.utah.edu> Message-ID: <4A148087.4040405@ccs.neu.edu> Excellent, thank you! I will try it out tomorrow with the nightly build. And (belated) thanks for yesterday's fix, too. Dave Matthew Flatt wrote: > I've fixed a bug where printing sessions in an editor were closed > incorrectly, and I expect that will fix the problem. > > Thanks for the report! > > At Wed, 20 May 2009 15:35:10 -0400, Dave Herman wrote: >> When I try to print from Windows, it seems to truncate portions of the >> document. I tried printing the definitions window earlier today and it >> only printed the first 6 pages of maybe a 7 or 8 page file. When I print >> the interactions window, it only prints a few pages at a time. I had >> about 16 pages of REPL interaction I wanted to print, and I had to print >> it in 6 chunks: >> >> 1. pp. 1 - 5 >> 2. pp. 6 - 9 >> 3. pp. 10 - 11 >> 4. pp. 12 - 13 >> 5. p. 14 >> 6. p. 15 >> >> The bottom of the p. 15 cuts off partway through, and it won't print >> anything after that. >> >> When I have a shorter REPL interaction, it prints it all in one chunk, >> but it still just cuts off at some point. >> >> Dave >> _________________________________________________ >> For list-related administrative tasks: >> http://list.cs.brown.edu/mailman/listinfo/plt-dev From m.douglas.williams at gmail.com Wed May 20 19:09:22 2009 From: m.douglas.williams at gmail.com (Doug Williams) Date: Wed May 20 19:09:46 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.2 In-Reply-To: References: Message-ID: Done. The plot routines in the demos and the extensions in the science collection work as expected on my Windows box. I'll try on my other platforms later this evening. On Wed, May 20, 2009 at 4:05 AM, Eli Barzilay wrote: > Checklist items for the v4.2 release > (using the v4.1.900 alpha build) > > Search for your name to find relevant items, reply when you finish > an item (please indicate which item is done). Also, if you have > any commits that should have been merged, make sure that they're > in. > > Important: new builds are created without announcement, usually > whenever I see significant commits. If you need to commit changes, > please make sure you tell me to merge it to the release branch. > > --> Release candidates are at > --> http://pre.plt-scheme.org/release/installers > > Please use these installers (or source bundles) -- don't test from > your own svn chekout (don't test v4.2.0.2 by mistake!). To get > the tests directory in the normal release, you can do this: > cd .../collects > svn export http://svn.plt-scheme.org/plt/release/collects/tests > > ---------------------------------------------------------------------- > > *** Testing: > > * Matthew Flatt > - MzScheme Tests > - Languages Tests > - MrEd Tests (Also check that `mred -z' and `mred-text' still works > in Windows and Mac OS X) > - mzc Tests > - mzc --exe tests > - .plt-packing Tests > - Games Tests > - Unit Tests > - Syntax Color Tests > - R6RS Tests > Updates: > - MzScheme Updates: update HISTORY > - MrEd Updates: update README, HISTORY > (updates should show v4.2 as the most current version) > - Update man pages in plt/man/man1: mred.1, mzscheme.1 > Email me to merge the changes from the trunk when they're done, > or tell me if there are no such changes. > > * Robby Findler > - DrScheme Tests > - Framework Tests > - Contracts Tests > - Games Tests > - Teachpacks Tests: image tests > - PLaneT Tests > Updates: > - DrScheme Updates: update HISTORY > - Redex Updates: update HISTORY > (updates should show v4.2 as the most current version) > - Ensure that previous version of DrScheme's preference files still > starts up with new DrScheme > - Update man pages in plt/man/man1: drscheme.1 > Email me to merge the changes from the trunk 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 v4.2 as the most current version) > Email me to merge the changes from the trunk 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 > Updates: > - Teachpack Updates: update HISTORY > (updates should show v4.2 as the most current version; email me > to merge the changes from the trunk when they're done, or tell me if > there are no such changes.) > > * Ryan Culpepper > - Macro Debugger Tests > - Syntax Classifier Tests > > * Jay McCarthy > - Web server Tests > - XML Tests > - HTML Tests > > * Paul Steckler > - MysterX Tests > - MzCOM Tests > > * Kathy Gray > - ProfJ Tests > - Test Engine Tests > > * Noel Welsh , Chongkai Zhu > - SRFI Tests > - Ensure that all claimed srfi's are in the bundle and they all load > into mzscheme or drscheme (as appropriate) > > * Sam Tobin-Hochstadt > - Match Tests > - Typed Scheme Tests > > * Stevie Strickland > - Unit Contract Tests > - Contract Region Tests > > * Eli Barzilay > - Swindle Tests > - Plot Tests > - PLT Tree: compare new distribution trees to previous ones > Version Updates: if a major change has happened, update the version > number in: > - plt/collects/mzscheme/info.ss > - plt/collects/mred/info.ss > > * Doug Williams > - Plot Tests > > * Greg Cooper > - FrTime Tests > > * Carl Eastlund > - Dracula Tests (confirm that Dracula runs from PLaneT) > > * Shriram Krishnamurthi > Tour: check the tour and generate a new one if needed. > [Note: Since this is a v4.1.900 build, you will need to edit your > .../collects/framework/private/version.ss > file and change `(version)' to `"4.2"'.] > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > http://www.barzilay.org/ Maze is Life! > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090520/c87416ac/attachment.htm From clements at brinckerhoff.org Thu May 21 02:02:48 2009 From: clements at brinckerhoff.org (John Clements) Date: Thu May 21 02:03:24 2009 Subject: [plt-dev] proposed: folding in minor changes to stepper for 4.2 release Message-ID: <4B1D593A-B36F-4DA3-81B1-BD95E030B30E@brinckerhoff.org> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2484 bytes Desc: not available Url : http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090520/8f882964/smime-0001.bin From matthias at ccs.neu.edu Thu May 21 08:53:55 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Thu May 21 08:54:31 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.2 In-Reply-To: References: Message-ID: <67AA90C5-4F78-46D1-B390-CBF5556CD983@ccs.neu.edu> On May 20, 2009, at 6:05 AM, Eli Barzilay wrote: > * Matthias Felleisen > - Teachpacks Tests: check that new teachpacks are addable > - Teachpack Docs: check teachpack docs in the bundles > Updates: > - Teachpack Updates: update HISTORY > (updates should show v4.2 as the most current version; email me > to merge the changes from the trunk when they're done, or tell me if > there are no such changes.) Done. (I discovered the re-introduction of a minor bug into the line- drawing routines, but I will wait with fixing this until Robby has re- done the image.ss teachpack.) From m.douglas.williams at gmail.com Thu May 21 10:43:56 2009 From: m.douglas.williams at gmail.com (Doug Williams) Date: Thu May 21 10:50:19 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.2 In-Reply-To: References: Message-ID: Eli, With the v4.1.900 alpha build downloaded yesterday (using Windows XP), the "Print Definitions..." functionality doesn't seem to work. Basically, the print dialog comes up, then when the Print button is pressed, the "Please wait, printing..." message pops up, but nothing happens. I can print from others apps, so it isn't the printer. [I tried "Print Interactions..." and it doesn't work either. I also tried other printers, etc.] Doug On Wed, May 20, 2009 at 4:05 AM, Eli Barzilay wrote: > Checklist items for the v4.2 release > (using the v4.1.900 alpha build) > > Search for your name to find relevant items, reply when you finish > an item (please indicate which item is done). Also, if you have > any commits that should have been merged, make sure that they're > in. > > Important: new builds are created without announcement, usually > whenever I see significant commits. If you need to commit changes, > please make sure you tell me to merge it to the release branch. > > --> Release candidates are at > --> http://pre.plt-scheme.org/release/installers > > Please use these installers (or source bundles) -- don't test from > your own svn chekout (don't test v4.2.0.2 by mistake!). To get > the tests directory in the normal release, you can do this: > cd .../collects > svn export http://svn.plt-scheme.org/plt/release/collects/tests > > ---------------------------------------------------------------------- > > *** Testing: > > * Matthew Flatt > - MzScheme Tests > - Languages Tests > - MrEd Tests (Also check that `mred -z' and `mred-text' still works > in Windows and Mac OS X) > - mzc Tests > - mzc --exe tests > - .plt-packing Tests > - Games Tests > - Unit Tests > - Syntax Color Tests > - R6RS Tests > Updates: > - MzScheme Updates: update HISTORY > - MrEd Updates: update README, HISTORY > (updates should show v4.2 as the most current version) > - Update man pages in plt/man/man1: mred.1, mzscheme.1 > Email me to merge the changes from the trunk when they're done, > or tell me if there are no such changes. > > * Robby Findler > - DrScheme Tests > - Framework Tests > - Contracts Tests > - Games Tests > - Teachpacks Tests: image tests > - PLaneT Tests > Updates: > - DrScheme Updates: update HISTORY > - Redex Updates: update HISTORY > (updates should show v4.2 as the most current version) > - Ensure that previous version of DrScheme's preference files still > starts up with new DrScheme > - Update man pages in plt/man/man1: drscheme.1 > Email me to merge the changes from the trunk 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 v4.2 as the most current version) > Email me to merge the changes from the trunk 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 > Updates: > - Teachpack Updates: update HISTORY > (updates should show v4.2 as the most current version; email me > to merge the changes from the trunk when they're done, or tell me if > there are no such changes.) > > * Ryan Culpepper > - Macro Debugger Tests > - Syntax Classifier Tests > > * Jay McCarthy > - Web server Tests > - XML Tests > - HTML Tests > > * Paul Steckler > - MysterX Tests > - MzCOM Tests > > * Kathy Gray > - ProfJ Tests > - Test Engine Tests > > * Noel Welsh , Chongkai Zhu > - SRFI Tests > - Ensure that all claimed srfi's are in the bundle and they all load > into mzscheme or drscheme (as appropriate) > > * Sam Tobin-Hochstadt > - Match Tests > - Typed Scheme Tests > > * Stevie Strickland > - Unit Contract Tests > - Contract Region Tests > > * Eli Barzilay > - Swindle Tests > - Plot Tests > - PLT Tree: compare new distribution trees to previous ones > Version Updates: if a major change has happened, update the version > number in: > - plt/collects/mzscheme/info.ss > - plt/collects/mred/info.ss > > * Doug Williams > - Plot Tests > > * Greg Cooper > - FrTime Tests > > * Carl Eastlund > - Dracula Tests (confirm that Dracula runs from PLaneT) > > * Shriram Krishnamurthi > Tour: check the tour and generate a new one if needed. > [Note: Since this is a v4.1.900 build, you will need to edit your > .../collects/framework/private/version.ss > file and change `(version)' to `"4.2"'.] > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > http://www.barzilay.org/ Maze is Life! > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090521/4d3e455f/attachment.html From mflatt at cs.utah.edu Thu May 21 11:00:51 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Thu May 21 11:01:17 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.2 In-Reply-To: References: Message-ID: <20090521150054.2B1106500A3@mail-svr1.cs.utah.edu> I think this is fixed in SVN (as of yesterday afternoon), but I don't know whether the fix in the latest build. Thanks, Matthew At Thu, 21 May 2009 08:43:56 -0600, Doug Williams wrote: > Eli, > > With the v4.1.900 alpha build downloaded yesterday (using Windows XP), the > "Print Definitions..." functionality doesn't seem to work. Basically, the > print dialog comes up, then when the Print button is pressed, the "Please > wait, printing..." message pops up, but nothing happens. I can print from > others apps, so it isn't the printer. [I tried "Print Interactions..." and > it doesn't work either. I also tried other printers, etc.] > > Doug > > On Wed, May 20, 2009 at 4:05 AM, Eli Barzilay wrote: > > > Checklist items for the v4.2 release > > (using the v4.1.900 alpha build) > > > > Search for your name to find relevant items, reply when you finish > > an item (please indicate which item is done). Also, if you have > > any commits that should have been merged, make sure that they're > > in. > > > > Important: new builds are created without announcement, usually > > whenever I see significant commits. If you need to commit changes, > > please make sure you tell me to merge it to the release branch. > > > > --> Release candidates are at > > --> http://pre.plt-scheme.org/release/installers > > > > Please use these installers (or source bundles) -- don't test from > > your own svn chekout (don't test v4.2.0.2 by mistake!). To get > > the tests directory in the normal release, you can do this: > > cd .../collects > > svn export http://svn.plt-scheme.org/plt/release/collects/tests > > > > ---------------------------------------------------------------------- > > > > *** Testing: > > > > * Matthew Flatt > > - MzScheme Tests > > - Languages Tests > > - MrEd Tests (Also check that `mred -z' and `mred-text' still works > > in Windows and Mac OS X) > > - mzc Tests > > - mzc --exe tests > > - .plt-packing Tests > > - Games Tests > > - Unit Tests > > - Syntax Color Tests > > - R6RS Tests > > Updates: > > - MzScheme Updates: update HISTORY > > - MrEd Updates: update README, HISTORY > > (updates should show v4.2 as the most current version) > > - Update man pages in plt/man/man1: mred.1, mzscheme.1 > > Email me to merge the changes from the trunk when they're done, > > or tell me if there are no such changes. > > > > * Robby Findler > > - DrScheme Tests > > - Framework Tests > > - Contracts Tests > > - Games Tests > > - Teachpacks Tests: image tests > > - PLaneT Tests > > Updates: > > - DrScheme Updates: update HISTORY > > - Redex Updates: update HISTORY > > (updates should show v4.2 as the most current version) > > - Ensure that previous version of DrScheme's preference files still > > starts up with new DrScheme > > - Update man pages in plt/man/man1: drscheme.1 > > Email me to merge the changes from the trunk 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 v4.2 as the most current version) > > Email me to merge the changes from the trunk 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 > > Updates: > > - Teachpack Updates: update HISTORY > > (updates should show v4.2 as the most current version; email me > > to merge the changes from the trunk when they're done, or tell me if > > there are no such changes.) > > > > * Ryan Culpepper > > - Macro Debugger Tests > > - Syntax Classifier Tests > > > > * Jay McCarthy > > - Web server Tests > > - XML Tests > > - HTML Tests > > > > * Paul Steckler > > - MysterX Tests > > - MzCOM Tests > > > > * Kathy Gray > > - ProfJ Tests > > - Test Engine Tests > > > > * Noel Welsh , Chongkai Zhu > > - SRFI Tests > > - Ensure that all claimed srfi's are in the bundle and they all load > > into mzscheme or drscheme (as appropriate) > > > > * Sam Tobin-Hochstadt > > - Match Tests > > - Typed Scheme Tests > > > > * Stevie Strickland > > - Unit Contract Tests > > - Contract Region Tests > > > > * Eli Barzilay > > - Swindle Tests > > - Plot Tests > > - PLT Tree: compare new distribution trees to previous ones > > Version Updates: if a major change has happened, update the version > > number in: > > - plt/collects/mzscheme/info.ss > > - plt/collects/mred/info.ss > > > > * Doug Williams > > - Plot Tests > > > > * Greg Cooper > > - FrTime Tests > > > > * Carl Eastlund > > - Dracula Tests (confirm that Dracula runs from PLaneT) > > > > * Shriram Krishnamurthi > > Tour: check the tour and generate a new one if needed. > > [Note: Since this is a v4.1.900 build, you will need to edit your > > .../collects/framework/private/version.ss > > file and change `(version)' to `"4.2"'.] > > > > -- > > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > > http://www.barzilay.org/ Maze is Life! > > > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From eli at barzilay.org Thu May 21 11:01:46 2009 From: eli at barzilay.org (Eli Barzilay) Date: Thu May 21 11:02:07 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.2 In-Reply-To: References: Message-ID: <18965.27866.898732.233957@winooski.ccs.neu.edu> On May 21, Doug Williams wrote: > Eli, > > With the v4.1.900 alpha build downloaded yesterday (using Windows > XP), the "Print Definitions..." functionality doesn't seem to > work. Basically, the print dialog comes up, then when the Print > button is pressed, the "Please wait, printing..." message pops up, > but nothing happens. I can print from others apps, so it isn't the > printer. [I tried "Print Interactions..." and it doesn't work > either. I also tried other printers, etc.] There was a bug that Matthew fixed last evening, and a new build made it through sometime during the night -- so the current build (in the same place) should work fine with printing. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From dherman at ccs.neu.edu Thu May 21 11:06:36 2009 From: dherman at ccs.neu.edu (Dave Herman) Date: Thu May 21 11:07:05 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.2 In-Reply-To: <18965.27866.898732.233957@winooski.ccs.neu.edu> References: <18965.27866.898732.233957@winooski.ccs.neu.edu> Message-ID: <4A156DFC.7040305@ccs.neu.edu> > There was a bug that Matthew fixed last evening, and a new build made > it through sometime during the night -- so the current build (in the > same place) should work fine with printing. The installers page says the latest build is from two nights ago...? Dave From eli at barzilay.org Thu May 21 11:09:02 2009 From: eli at barzilay.org (Eli Barzilay) Date: Thu May 21 11:09:23 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.2 In-Reply-To: <4A156DFC.7040305@ccs.neu.edu> References: <18965.27866.898732.233957@winooski.ccs.neu.edu> <4A156DFC.7040305@ccs.neu.edu> Message-ID: <18965.28302.706506.820058@winooski.ccs.neu.edu> On May 21, Dave Herman wrote: > > There was a bug that Matthew fixed last evening, and a new build > > made it through sometime during the night -- so the current build > > (in the same place) should work fine with printing. > > The installers page says the latest build is from two nights ago...? Sorry -- I was talking about the release candidate build: http://pre.plt-scheme.org/release/ -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From robby at eecs.northwestern.edu Thu May 21 11:16:43 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Thu May 21 11:17:05 2009 Subject: [plt-dev] svn help? Message-ID: <932b2f1f0905210816v11777d95w4980e1d340245d1a@mail.gmail.com> I'm getting the following: [robby-laptop2] ~/svn> svn checkout http://svn.plt-scheme.org/usr/mflatt/text/scribble usr/mflatt/text/scribble svn: REPORT of '/usr/!svn/vcc/default': Could not read response body: Connection reset by peer (http://svn.plt-scheme.org) Exit 1 I have version 1.5.1. Anyone know what that means? (Note that the error apepars afters getting most, but not all of the files. The Makefile, in particular, didn't show up. THese did: collatz.png htdp-circle.ss scribble.scrbl style.tex conclusion.scrbl info.ss srcdoc.scrbl defproc.scrbl intro.scrbl struct-hierarchy.png eval.scrbl junk.txt struct.scrbl Robby From m.douglas.williams at gmail.com Thu May 21 11:24:54 2009 From: m.douglas.williams at gmail.com (Doug Williams) Date: Thu May 21 11:31:02 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.2 In-Reply-To: <18965.27866.898732.233957@winooski.ccs.neu.edu> References: <18965.27866.898732.233957@winooski.ccs.neu.edu> Message-ID: It works fine in the build from last night. Thanks. On Thu, May 21, 2009 at 9:01 AM, Eli Barzilay wrote: > On May 21, Doug Williams wrote: > > Eli, > > > > With the v4.1.900 alpha build downloaded yesterday (using Windows > > XP), the "Print Definitions..." functionality doesn't seem to > > work. Basically, the print dialog comes up, then when the Print > > button is pressed, the "Please wait, printing..." message pops up, > > but nothing happens. I can print from others apps, so it isn't the > > printer. [I tried "Print Interactions..." and it doesn't work > > either. I also tried other printers, etc.] > > There was a bug that Matthew fixed last evening, and a new build made > it through sometime during the night -- so the current build (in the > same place) should work fine with printing. > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > http://www.barzilay.org/ Maze is Life! > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090521/ef0ffb01/attachment.htm From robby at eecs.northwestern.edu Thu May 21 11:58:03 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Thu May 21 11:58:21 2009 Subject: [plt-dev] hangman teachpack broken Message-ID: <932b2f1f0905210858k4fecf55bweb7f09ef856ddf91@mail.gmail.com> With an empty definitions window: Welcome to DrScheme, version 4.1.900-svn20may2009 [3m]. Language: Advanced Student custom; memory limit: 256 megabytes. Teachpack: hangman.ss. 1 This program should be tested. define-compound-unit/infer: untagged initialization dependent signature mred^ is supplied from a later unit with link temp4 > From matthias at ccs.neu.edu Thu May 21 12:05:25 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Thu May 21 12:06:06 2009 Subject: [plt-dev] hangman teachpack broken In-Reply-To: <932b2f1f0905210858k4fecf55bweb7f09ef856ddf91@mail.gmail.com> References: <932b2f1f0905210858k4fecf55bweb7f09ef856ddf91@mail.gmail.com> Message-ID: <4C1BF19C-D8A0-48C2-B291-417129777264@ccs.neu.edu> Yes, I asked a while ago on this mailing list what this error message means. On May 21, 2009, at 11:58 AM, Robby Findler wrote: > With an empty definitions window: > > Welcome to DrScheme, version 4.1.900-svn20may2009 [3m]. > Language: Advanced Student custom; memory limit: 256 megabytes. > Teachpack: hangman.ss. > 1 > This program should be tested. > define-compound-unit/infer: untagged initialization dependent > signature mred^ is supplied from a later unit with link temp4 >> > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From robby at eecs.northwestern.edu Thu May 21 12:07:28 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Thu May 21 12:07:50 2009 Subject: [plt-dev] hangman teachpack broken In-Reply-To: <4C1BF19C-D8A0-48C2-B291-417129777264@ccs.neu.edu> References: <932b2f1f0905210858k4fecf55bweb7f09ef856ddf91@mail.gmail.com> <4C1BF19C-D8A0-48C2-B291-417129777264@ccs.neu.edu> Message-ID: <932b2f1f0905210907w1e3201e9x3fe743f791af9dc5@mail.gmail.com> I don't know what it means, but it happens in #lang scheme, too: #lang scheme (require htdp/hangman) Robby On Thu, May 21, 2009 at 11:05 AM, Matthias Felleisen wrote: > > Yes, I asked a while ago on this mailing list what this error message means. > > > On May 21, 2009, at 11:58 AM, Robby Findler wrote: > >> With an empty definitions window: >> >> Welcome to DrScheme, version 4.1.900-svn20may2009 [3m]. >> Language: Advanced Student custom; memory limit: 256 megabytes. >> Teachpack: hangman.ss. >> 1 >> This program should be tested. >> define-compound-unit/infer: untagged initialization dependent >> signature mred^ is supplied from a later unit with link temp4 >>> >> _________________________________________________ >> ?For list-related administrative tasks: >> ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > > From matthias at ccs.neu.edu Thu May 21 12:10:19 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Thu May 21 12:10:58 2009 Subject: [plt-dev] hangman teachpack broken In-Reply-To: <932b2f1f0905210907w1e3201e9x3fe743f791af9dc5@mail.gmail.com> References: <932b2f1f0905210858k4fecf55bweb7f09ef856ddf91@mail.gmail.com> <4C1BF19C-D8A0-48C2-B291-417129777264@ccs.neu.edu> <932b2f1f0905210907w1e3201e9x3fe743f791af9dc5@mail.gmail.com> Message-ID: When someone can tell me what the error message means, I'll start looking into it. (I am wondering whether it's related to the backdoor into drscheme that hangman opens up.) On May 21, 2009, at 12:07 PM, Robby Findler wrote: > I don't know what it means, but it happens in #lang scheme, too: > > #lang scheme > (require htdp/hangman) > > Robby > > On Thu, May 21, 2009 at 11:05 AM, Matthias Felleisen > wrote: >> >> Yes, I asked a while ago on this mailing list what this error >> message means. >> >> >> On May 21, 2009, at 11:58 AM, Robby Findler wrote: >> >>> With an empty definitions window: >>> >>> Welcome to DrScheme, version 4.1.900-svn20may2009 [3m]. >>> Language: Advanced Student custom; memory limit: 256 megabytes. >>> Teachpack: hangman.ss. >>> 1 >>> This program should be tested. >>> define-compound-unit/infer: untagged initialization dependent >>> signature mred^ is supplied from a later unit with link temp4 >>>> >>> _________________________________________________ >>> For list-related administrative tasks: >>> http://list.cs.brown.edu/mailman/listinfo/plt-dev >> >> From robby at eecs.northwestern.edu Thu May 21 12:11:59 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Thu May 21 12:12:22 2009 Subject: [plt-dev] hangman teachpack broken In-Reply-To: References: <932b2f1f0905210858k4fecf55bweb7f09ef856ddf91@mail.gmail.com> <4C1BF19C-D8A0-48C2-B291-417129777264@ccs.neu.edu> <932b2f1f0905210907w1e3201e9x3fe743f791af9dc5@mail.gmail.com> Message-ID: <932b2f1f0905210911r2d4f52ean3f2c7e241911d2c6@mail.gmail.com> It is easy to see that it isn't related. Besides the fact that the module level doesn't have the backdoor, there is this simple test: % cat > ~/tmp.ss #lang scheme (require htdp/hangman) % mred ~/tmp.ss define-compound-unit/infer: untagged initialization dependent signature mred^ is supplied from a later unit with link temp4 === context === /Users/robby/svn/exp/plt/collects/mzlib/private/unit-runtime.ss:109:5 /Users/robby/svn/exp/plt/collects/scheme/private/map.ss:44:11: for-each Exit 1 On Thu, May 21, 2009 at 11:10 AM, Matthias Felleisen wrote: > > When someone can tell me what the error message means, I'll start looking > into it. (I am wondering whether it's related to the backdoor into drscheme > that hangman opens up.) > > > > > On May 21, 2009, at 12:07 PM, Robby Findler wrote: > >> I don't know what it means, but it happens in #lang scheme, too: >> >> #lang scheme >> (require htdp/hangman) >> >> Robby >> >> On Thu, May 21, 2009 at 11:05 AM, Matthias Felleisen >> wrote: >>> >>> Yes, I asked a while ago on this mailing list what this error message >>> means. >>> >>> >>> On May 21, 2009, at 11:58 AM, Robby Findler wrote: >>> >>>> With an empty definitions window: >>>> >>>> Welcome to DrScheme, version 4.1.900-svn20may2009 [3m]. >>>> Language: Advanced Student custom; memory limit: 256 megabytes. >>>> Teachpack: hangman.ss. >>>> 1 >>>> This program should be tested. >>>> define-compound-unit/infer: untagged initialization dependent >>>> signature mred^ is supplied from a later unit with link temp4 >>>>> >>>> _________________________________________________ >>>> ?For list-related administrative tasks: >>>> ?http://list.cs.brown.edu/mailman/listinfo/plt-dev >>> >>> > > From matthias at ccs.neu.edu Thu May 21 12:21:35 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Thu May 21 12:22:14 2009 Subject: [plt-dev] hangman teachpack broken In-Reply-To: <932b2f1f0905210911r2d4f52ean3f2c7e241911d2c6@mail.gmail.com> References: <932b2f1f0905210858k4fecf55bweb7f09ef856ddf91@mail.gmail.com> <4C1BF19C-D8A0-48C2-B291-417129777264@ccs.neu.edu> <932b2f1f0905210907w1e3201e9x3fe743f791af9dc5@mail.gmail.com> <932b2f1f0905210911r2d4f52ean3f2c7e241911d2c6@mail.gmail.com> Message-ID: When I open hangman.ss in drscheme and click RUN, I get > Welcome to DrScheme, version 4.2.0.2-svn19may2009 [3m]. > Language: Module; memory limit: 256 megabytes. > define-compound-unit/infer: untagged initialization dependent > signature mred^ is supplied from a later unit with link temp4 > > I get no highlighting. I get no stack trace. Is this a DRSCHEME ERROR and do you want a report? On May 21, 2009, at 12:11 PM, Robby Findler wrote: > It is easy to see that it isn't related. Besides the fact that the > module level doesn't have the backdoor, there is this simple test: > > % cat > ~/tmp.ss > #lang scheme > (require htdp/hangman) > > % mred ~/tmp.ss > define-compound-unit/infer: untagged initialization dependent > signature mred^ is supplied from a later unit with link temp4 > > === context === > /Users/robby/svn/exp/plt/collects/mzlib/private/unit-runtime.ss:109:5 > /Users/robby/svn/exp/plt/collects/scheme/private/map.ss:44:11: for- > each > > Exit 1 > > > On Thu, May 21, 2009 at 11:10 AM, Matthias Felleisen > wrote: >> >> When someone can tell me what the error message means, I'll start >> looking >> into it. (I am wondering whether it's related to the backdoor into >> drscheme >> that hangman opens up.) >> >> >> >> >> On May 21, 2009, at 12:07 PM, Robby Findler wrote: >> >>> I don't know what it means, but it happens in #lang scheme, too: >>> >>> #lang scheme >>> (require htdp/hangman) >>> >>> Robby >>> >>> On Thu, May 21, 2009 at 11:05 AM, Matthias Felleisen >>> wrote: >>>> >>>> Yes, I asked a while ago on this mailing list what this error >>>> message >>>> means. >>>> >>>> >>>> On May 21, 2009, at 11:58 AM, Robby Findler wrote: >>>> >>>>> With an empty definitions window: >>>>> >>>>> Welcome to DrScheme, version 4.1.900-svn20may2009 [3m]. >>>>> Language: Advanced Student custom; memory limit: 256 megabytes. >>>>> Teachpack: hangman.ss. >>>>> 1 >>>>> This program should be tested. >>>>> define-compound-unit/infer: untagged initialization dependent >>>>> signature mred^ is supplied from a later unit with link temp4 >>>>>> >>>>> _________________________________________________ >>>>> For list-related administrative tasks: >>>>> http://list.cs.brown.edu/mailman/listinfo/plt-dev >>>> >>>> >> >> From matthias at ccs.neu.edu Thu May 21 12:23:44 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Thu May 21 12:24:16 2009 Subject: [plt-dev] hangman teachpack broken In-Reply-To: References: <932b2f1f0905210858k4fecf55bweb7f09ef856ddf91@mail.gmail.com> <4C1BF19C-D8A0-48C2-B291-417129777264@ccs.neu.edu> <932b2f1f0905210907w1e3201e9x3fe743f791af9dc5@mail.gmail.com> Message-ID: Running this program also triggers the error: #lang mzscheme (require "draw-sig.ss" "big-draw.ss" mzlib/unit) (provide-signature-elements draw^) From robby at eecs.northwestern.edu Thu May 21 12:29:20 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Thu May 21 12:29:42 2009 Subject: [plt-dev] hangman teachpack broken In-Reply-To: References: <932b2f1f0905210858k4fecf55bweb7f09ef856ddf91@mail.gmail.com> <4C1BF19C-D8A0-48C2-B291-417129777264@ccs.neu.edu> <932b2f1f0905210907w1e3201e9x3fe743f791af9dc5@mail.gmail.com> <932b2f1f0905210911r2d4f52ean3f2c7e241911d2c6@mail.gmail.com> Message-ID: <932b2f1f0905210929m184ad361i5d3265757da9e717@mail.gmail.com> I don't think that that's a drscheme error. At least, if it is, I'd need some help to see why (ie, a program that involves things like a few simple macro definitions and calls to raise-syntax-error). On the face of it, that looks like a bug in the macro (either that the error message just shouldn't happen, or that the macro isn't including source information). Robby On Thu, May 21, 2009 at 11:21 AM, Matthias Felleisen wrote: > > When I open hangman.ss in drscheme and click RUN, I get > >> Welcome to DrScheme, version 4.2.0.2-svn19may2009 [3m]. >> Language: Module; memory limit: 256 megabytes. >> define-compound-unit/infer: untagged initialization dependent signature >> mred^ is supplied from a later unit with link temp4 >> > > > I get no highlighting. I get no stack trace. > > Is this a DRSCHEME ERROR and do you want a report? > > > > > On May 21, 2009, at 12:11 PM, Robby Findler wrote: > >> It is easy to see that it isn't related. Besides the fact that the >> module level doesn't have the backdoor, there is this simple test: >> >> % cat > ~/tmp.ss >> #lang scheme >> (require htdp/hangman) >> >> % mred ~/tmp.ss >> define-compound-unit/infer: untagged initialization dependent >> signature mred^ is supplied from a later unit with link temp4 >> >> ?=== context === >> /Users/robby/svn/exp/plt/collects/mzlib/private/unit-runtime.ss:109:5 >> /Users/robby/svn/exp/plt/collects/scheme/private/map.ss:44:11: for-each >> >> Exit 1 >> >> >> On Thu, May 21, 2009 at 11:10 AM, Matthias Felleisen >> wrote: >>> >>> When someone can tell me what the error message means, I'll start looking >>> into it. (I am wondering whether it's related to the backdoor into >>> drscheme >>> that hangman opens up.) >>> >>> >>> >>> >>> On May 21, 2009, at 12:07 PM, Robby Findler wrote: >>> >>>> I don't know what it means, but it happens in #lang scheme, too: >>>> >>>> #lang scheme >>>> (require htdp/hangman) >>>> >>>> Robby >>>> >>>> On Thu, May 21, 2009 at 11:05 AM, Matthias Felleisen >>>> wrote: >>>>> >>>>> Yes, I asked a while ago on this mailing list what this error message >>>>> means. >>>>> >>>>> >>>>> On May 21, 2009, at 11:58 AM, Robby Findler wrote: >>>>> >>>>>> With an empty definitions window: >>>>>> >>>>>> Welcome to DrScheme, version 4.1.900-svn20may2009 [3m]. >>>>>> Language: Advanced Student custom; memory limit: 256 megabytes. >>>>>> Teachpack: hangman.ss. >>>>>> 1 >>>>>> This program should be tested. >>>>>> define-compound-unit/infer: untagged initialization dependent >>>>>> signature mred^ is supplied from a later unit with link temp4 >>>>>>> >>>>>> _________________________________________________ >>>>>> ?For list-related administrative tasks: >>>>>> ?http://list.cs.brown.edu/mailman/listinfo/plt-dev >>>>> >>>>> >>> >>> > > From mflatt at cs.utah.edu Thu May 21 12:32:50 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Thu May 21 12:33:12 2009 Subject: [plt-dev] hangman teachpack broken In-Reply-To: References: <932b2f1f0905210858k4fecf55bweb7f09ef856ddf91@mail.gmail.com> <4C1BF19C-D8A0-48C2-B291-417129777264@ccs.neu.edu> <932b2f1f0905210907w1e3201e9x3fe743f791af9dc5@mail.gmail.com> Message-ID: <20090521163250.6D85965008D@mail-svr1.cs.utah.edu> When `graphics-posn-less@' imports `mred^', it declares that the corresponding unit must be executed before `graphics-posn-less@' itself. The solution is to reverse the order of units in the `link' clause on line 17 of "big-draw.ss". At Thu, 21 May 2009 12:10:19 -0400, Matthias Felleisen wrote: > > When someone can tell me what the error message means, I'll start > looking into it. (I am wondering whether it's related to the backdoor > into drscheme that hangman opens up.) > > > > > On May 21, 2009, at 12:07 PM, Robby Findler wrote: > > > I don't know what it means, but it happens in #lang scheme, too: > > > > #lang scheme > > (require htdp/hangman) > > > > Robby > > > > On Thu, May 21, 2009 at 11:05 AM, Matthias Felleisen > > wrote: > >> > >> Yes, I asked a while ago on this mailing list what this error > >> message means. > >> > >> > >> On May 21, 2009, at 11:58 AM, Robby Findler wrote: > >> > >>> With an empty definitions window: > >>> > >>> Welcome to DrScheme, version 4.1.900-svn20may2009 [3m]. > >>> Language: Advanced Student custom; memory limit: 256 megabytes. > >>> Teachpack: hangman.ss. > >>> 1 > >>> This program should be tested. > >>> define-compound-unit/infer: untagged initialization dependent > >>> signature mred^ is supplied from a later unit with link temp4 > >>>> > >>> _________________________________________________ > >>> For list-related administrative tasks: > >>> http://list.cs.brown.edu/mailman/listinfo/plt-dev > >> > >> > > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From matthias at ccs.neu.edu Thu May 21 12:35:02 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Thu May 21 12:35:37 2009 Subject: [plt-dev] hangman teachpack broken In-Reply-To: <932b2f1f0905210929m184ad361i5d3265757da9e717@mail.gmail.com> References: <932b2f1f0905210858k4fecf55bweb7f09ef856ddf91@mail.gmail.com> <4C1BF19C-D8A0-48C2-B291-417129777264@ccs.neu.edu> <932b2f1f0905210907w1e3201e9x3fe743f791af9dc5@mail.gmail.com> <932b2f1f0905210911r2d4f52ean3f2c7e241911d2c6@mail.gmail.com> <932b2f1f0905210929m184ad361i5d3265757da9e717@mail.gmail.com> Message-ID: <0CBCB4EF-1BF2-44A5-8A51-AFF3236AE836@ccs.neu.edu> The following program triggers the error. #lang scheme/load (module draw-sig.ss scheme (provide draw^) (define-signature draw^())) (module big-draw.ss scheme (require lang/posn mzlib/unit mred mred/mred-unit graphics/graphics-sig graphics/graphics-posn-less-unit) (define-values/invoke-unit/infer (export graphics^) (link graphics-posn-less@ standard-mred@)) (provide-signature-elements graphics^) ) (module a scheme (require 'draw-sig.ss 'big-draw.ss mzlib/unit) (provide-signature-elements draw^)) (require 'a) From robby at eecs.northwestern.edu Thu May 21 12:36:29 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Thu May 21 12:36:47 2009 Subject: [plt-dev] hangman teachpack broken In-Reply-To: <0CBCB4EF-1BF2-44A5-8A51-AFF3236AE836@ccs.neu.edu> References: <932b2f1f0905210858k4fecf55bweb7f09ef856ddf91@mail.gmail.com> <4C1BF19C-D8A0-48C2-B291-417129777264@ccs.neu.edu> <932b2f1f0905210907w1e3201e9x3fe743f791af9dc5@mail.gmail.com> <932b2f1f0905210911r2d4f52ean3f2c7e241911d2c6@mail.gmail.com> <932b2f1f0905210929m184ad361i5d3265757da9e717@mail.gmail.com> <0CBCB4EF-1BF2-44A5-8A51-AFF3236AE836@ccs.neu.edu> Message-ID: <932b2f1f0905210936o481745e3qc95bbed1700a8a2e@mail.gmail.com> I was doing similar things when Matthew sent his message. Guess it pays to have written the error messages, eh? :) Thanks, Matthew. Robby On Thu, May 21, 2009 at 11:35 AM, Matthias Felleisen wrote: > > The following program triggers the error. > > #lang scheme/load > > (module draw-sig.ss scheme > ?(provide draw^) > ?(define-signature draw^())) > > > (module big-draw.ss scheme > > ?(require lang/posn > ? ? ? ? ? mzlib/unit > ? ? ? ? ? mred > ? ? ? ? ? mred/mred-unit > ? ? ? ? ? graphics/graphics-sig > ? ? ? ? ? graphics/graphics-posn-less-unit) > > ?(define-values/invoke-unit/infer > ? ?(export graphics^) > ? ?(link graphics-posn-less@ standard-mred@)) > > ?(provide-signature-elements graphics^) > ?) > > (module a scheme > ?(require 'draw-sig.ss 'big-draw.ss mzlib/unit) > ?(provide-signature-elements draw^)) > > (require 'a) > > From matthias at ccs.neu.edu Thu May 21 12:38:07 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Thu May 21 12:38:47 2009 Subject: [plt-dev] hangman teachpack broken In-Reply-To: <20090521163250.6D85965008D@mail-svr1.cs.utah.edu> References: <932b2f1f0905210858k4fecf55bweb7f09ef856ddf91@mail.gmail.com> <4C1BF19C-D8A0-48C2-B291-417129777264@ccs.neu.edu> <932b2f1f0905210907w1e3201e9x3fe743f791af9dc5@mail.gmail.com> <20090521163250.6D85965008D@mail-svr1.cs.utah.edu> Message-ID: Thanks, I discovered all this through a divide-and-conquer search and committed the fix ~1 minute ago. -- Matthias On May 21, 2009, at 12:32 PM, Matthew Flatt wrote: > When `graphics-posn-less@' imports `mred^', it declares that the > corresponding unit must be executed before `graphics-posn-less@' > itself. > > The solution is to reverse the order of units in the `link' clause on > line 17 of "big-draw.ss". > > At Thu, 21 May 2009 12:10:19 -0400, Matthias Felleisen wrote: >> >> When someone can tell me what the error message means, I'll start >> looking into it. (I am wondering whether it's related to the backdoor >> into drscheme that hangman opens up.) >> >> >> >> >> On May 21, 2009, at 12:07 PM, Robby Findler wrote: >> >>> I don't know what it means, but it happens in #lang scheme, too: >>> >>> #lang scheme >>> (require htdp/hangman) >>> >>> Robby >>> >>> On Thu, May 21, 2009 at 11:05 AM, Matthias Felleisen >>> wrote: >>>> >>>> Yes, I asked a while ago on this mailing list what this error >>>> message means. >>>> >>>> >>>> On May 21, 2009, at 11:58 AM, Robby Findler wrote: >>>> >>>>> With an empty definitions window: >>>>> >>>>> Welcome to DrScheme, version 4.1.900-svn20may2009 [3m]. >>>>> Language: Advanced Student custom; memory limit: 256 megabytes. >>>>> Teachpack: hangman.ss. >>>>> 1 >>>>> This program should be tested. >>>>> define-compound-unit/infer: untagged initialization dependent >>>>> signature mred^ is supplied from a later unit with link temp4 >>>>>> >>>>> _________________________________________________ >>>>> For list-related administrative tasks: >>>>> http://list.cs.brown.edu/mailman/listinfo/plt-dev >>>> >>>> >> >> _________________________________________________ >> For list-related administrative tasks: >> http://list.cs.brown.edu/mailman/listinfo/plt-dev From matthias at ccs.neu.edu Thu May 21 12:38:35 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Thu May 21 12:39:22 2009 Subject: [plt-dev] hangman teachpack broken In-Reply-To: <932b2f1f0905210936o481745e3qc95bbed1700a8a2e@mail.gmail.com> References: <932b2f1f0905210858k4fecf55bweb7f09ef856ddf91@mail.gmail.com> <4C1BF19C-D8A0-48C2-B291-417129777264@ccs.neu.edu> <932b2f1f0905210907w1e3201e9x3fe743f791af9dc5@mail.gmail.com> <932b2f1f0905210911r2d4f52ean3f2c7e241911d2c6@mail.gmail.com> <932b2f1f0905210929m184ad361i5d3265757da9e717@mail.gmail.com> <0CBCB4EF-1BF2-44A5-8A51-AFF3236AE836@ccs.neu.edu> <932b2f1f0905210936o481745e3qc95bbed1700a8a2e@mail.gmail.com> Message-ID: <8BAC5952-FDB4-41B5-8DC4-FE3660BF1F70@ccs.neu.edu> Meaning? I sent this message weeks ago. On May 21, 2009, at 12:36 PM, Robby Findler wrote: > I was doing similar things when Matthew sent his message. Guess it > pays to have written the error messages, eh? :) > > Thanks, Matthew. > > Robby > > On Thu, May 21, 2009 at 11:35 AM, Matthias Felleisen > wrote: >> >> The following program triggers the error. >> >> #lang scheme/load >> >> (module draw-sig.ss scheme >> (provide draw^) >> (define-signature draw^())) >> >> >> (module big-draw.ss scheme >> >> (require lang/posn >> mzlib/unit >> mred >> mred/mred-unit >> graphics/graphics-sig >> graphics/graphics-posn-less-unit) >> >> (define-values/invoke-unit/infer >> (export graphics^) >> (link graphics-posn-less@ standard-mred@)) >> >> (provide-signature-elements graphics^) >> ) >> >> (module a scheme >> (require 'draw-sig.ss 'big-draw.ss mzlib/unit) >> (provide-signature-elements draw^)) >> >> (require 'a) >> >> From ghcooper at gmail.com Thu May 21 12:54:39 2009 From: ghcooper at gmail.com (Gregory Cooper) Date: Thu May 21 12:54:57 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.2 In-Reply-To: References: Message-ID: <65e1d50c0905210954k5d8cd738sa6652d7ad269e9a9@mail.gmail.com> > * Greg Cooper > ?- FrTime Tests Done. From matthias at ccs.neu.edu Thu May 21 13:43:57 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Thu May 21 13:44:30 2009 Subject: [plt-dev] lessons learned Message-ID: Today's chase for the source of define-compound-unit/infer: untagged initialization dependent signature mred^ is supplied from a later unit with link temp4 cost me an hour of my time when a few seconds of common sense would have sufficed. I don't have such hours to waste. ;; --- LESSON 1: When I gave the POPL keynote a few years ago about our project, every single part of the talk had a single lesson: ************************** * ERROR MESSAGES MATTER. * ************************** I just can't see how the above error message would point anyone to this specification > (define-values/invoke-unit/infer > (export graphics^) > (link standard-mred@ graphics-posn-less@)) on line 15 of big-draw.ss. The name of the construct is different from that in the error message. And the message itself is gobbldedygook. ;; --- LESSON 2: People recently (27 Mar 2009) changed (see svn log, svn blame) these lines, and didn't even both to run the file as they did. ********************************* * WHEN YOU EDIT A FILE, RUN IT. * ********************************* It takes a cmd-t or a click-run and it evaluates in 3 seconds. Doing so would have revealed the bug. 3 SECONDS, 1 HOUR. ;; --- LESSON 3: When you do synthesize such language constructs, put the effort in to get them right. A simple topological sort would probably avoid all this nonsense. ;; --- Guys, this shop is not the federal government. We can't afford this sloppiness -- Matthias From thomas at deniau.org Thu May 21 15:42:51 2009 From: thomas at deniau.org (Thomas Deniau) Date: Thu May 21 16:10:08 2009 Subject: [plt-dev] Installation directories on Mac OS X Message-ID: Hi ! I'm trying to update the MacPorts port of mzscheme to version 4.1.5 (the current port is at v. 372). The way mzscheme is installed by the previous Portfile is quite strange : for example, scheme.h is installed directly into $(prefix)/ include/ instead of $(prefix)/include/plt. The problem lies in the following lines of mzscheme/configure.ac : enable_quartz=no if test "${enable_xonx}" = "yes" ; then enable_quartz=no else if test "$OS" = "Darwin" ; then enable_quartz=yes enable_origtree=yes fi fi in the ./configure help, enable_xonx is documented as concerning MrEd only. I agree that problems may occur of unixstyle is enabled and MrEd is built (frameworks, ...), but why should unixstyle be disabled if MrEd isn't being built ? I did some quick tests with enable_origtree=no in the "Darwin" clause, and everything still seems to work (and the install locations are cleaner, with everything in the right subdirectories). Are there deeper reasons that would force origtree to yes on OS X even without MrEd ? Thanks, [ I just had to add support for the Mach-O executable format in unixstyle-install.ss -- a one-line change to add the Mach-O magic number -- and to use install_name_tool to tweak a framework path] -- Thomas Deniau -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2417 bytes Desc: not available Url : http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090521/48816d9b/smime.bin From ryanc at ccs.neu.edu Thu May 21 20:29:59 2009 From: ryanc at ccs.neu.edu (Ryan Culpepper) Date: Thu May 21 20:30:34 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.2 In-Reply-To: References: Message-ID: <4A15F207.7050708@ccs.neu.edu> Eli Barzilay wrote: > > * Ryan Culpepper > - Macro Debugger Tests > - Syntax Classifier Tests Done. From czhu at cs.utah.edu Fri May 22 04:04:45 2009 From: czhu at cs.utah.edu (Chongkai Zhu) Date: Fri May 22 04:05:10 2009 Subject: [plt-dev] Pre-Release Checklist for v4.2 In-Reply-To: References: Message-ID: <4A165C9D.9010207@cs.utah.edu> Eli Barzilay wrote: > * Noel Welsh , Chongkai Zhu > - SRFI Tests > - Ensure that all claimed srfi's are in the bundle and they all load > into mzscheme or drscheme (as appropriate) > > Find an error: (require srfi/1/cons) (make-list 0) procedure make-list: expects 2 arguments, given 1: 0 The 2nd argument of SRFI 1 version of mak-list is optional. Caused by SVN revision 14693 by eli. Chongkai From eli at barzilay.org Fri May 22 04:14:59 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri May 22 04:16:05 2009 Subject: [plt-dev] Pre-Release Checklist for v4.2 In-Reply-To: <4A165C9D.9010207@cs.utah.edu> References: <4A165C9D.9010207@cs.utah.edu> Message-ID: <18966.24323.528862.177055@winooski.ccs.neu.edu> On May 22, Chongkai Zhu wrote: > > procedure make-list: expects 2 arguments, given 1: 0 OK, quick poll time: 1. What should the default value be (#f as it was, # because it makes more sense, or 0 because that's what `make-vector' uses)? 2. Which one should be fixed -- only the srfi/1 version, or the scheme/list version (implying srfi/1 too)? -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From matthias at ccs.neu.edu Fri May 22 08:25:19 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Fri May 22 08:26:06 2009 Subject: [plt-dev] Pre-Release Checklist for v4.2 In-Reply-To: <18966.24323.528862.177055@winooski.ccs.neu.edu> References: <4A165C9D.9010207@cs.utah.edu> <18966.24323.528862.177055@winooski.ccs.neu.edu> Message-ID: <1601792B-91E7-440A-A941-38A30EE7E795@ccs.neu.edu> make-list always takes two arguments. There is no natural fill value. On May 22, 2009, at 4:14 AM, Eli Barzilay wrote: > On May 22, Chongkai Zhu wrote: >> >> procedure make-list: expects 2 arguments, given 1: 0 > > OK, quick poll time: > > 1. What should the default value be (#f as it was, # because it > makes more sense, or 0 because that's what `make-vector' uses)? > > 2. Which one should be fixed -- only the srfi/1 version, or the > scheme/list version (implying srfi/1 too)? > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli > Barzilay: > http://www.barzilay.org/ Maze is > Life! > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From m.douglas.williams at gmail.com Fri May 22 08:59:27 2009 From: m.douglas.williams at gmail.com (Doug Williams) Date: Fri May 22 09:00:04 2009 Subject: [plt-dev] Pre-Release Checklist for v4.2 In-Reply-To: <1601792B-91E7-440A-A941-38A30EE7E795@ccs.neu.edu> References: <4A165C9D.9010207@cs.utah.edu> <18966.24323.528862.177055@winooski.ccs.neu.edu> <1601792B-91E7-440A-A941-38A30EE7E795@ccs.neu.edu> Message-ID: I would agree with Matthias - there is no natural fill value. A vector is often used as a sequence of numbers - at least that is where I use them the most. And, zero is a good default. A list is not usually a sequence of numbers - it's typically a sequence of whatever. And, there is no value that would be useful 'most of the time'. That being said, if you wanted them to be consistent, I would vote for #f. But, that is because I'm a long-time Lisper and it looks like nil to me. And, I'm not a 'voting' member of the list anyway. :) I would like to know why # isn't utilized more - or, alternatively, why it exists in the first place. Is there a real difference between no value (my mental model for #) and an undefined/uninitialized value (my mental model for #)? In the case of lists or vectors returned by make-list or make-vector (with no second argument), I think of those elements as being undefined or uninitialized and would like an error raised if I reference them before I store something in them. Since make-list returns an immutable list, it's hard to think of its elements as being undefined - I can't mutate them anyway. The above argument would make more sense for a make-mlist, which I don't think is there at the moment. Doug On Fri, May 22, 2009 at 6:25 AM, Matthias Felleisen wrote: > > make-list always takes two arguments. There is no natural fill value. > > > > > On May 22, 2009, at 4:14 AM, Eli Barzilay wrote: > > On May 22, Chongkai Zhu wrote: >> >>> >>> procedure make-list: expects 2 arguments, given 1: 0 >>> >> >> OK, quick poll time: >> >> 1. What should the default value be (#f as it was, # because it >> makes more sense, or 0 because that's what `make-vector' uses)? >> >> 2. Which one should be fixed -- only the srfi/1 version, or the >> scheme/list version (implying srfi/1 too)? >> >> -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: >> http://www.barzilay.org/ Maze is Life! >> _________________________________________________ >> For list-related administrative tasks: >> http://list.cs.brown.edu/mailman/listinfo/plt-dev >> > > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090522/51296043/attachment.html From matthias at ccs.neu.edu Fri May 22 10:03:18 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Fri May 22 10:03:53 2009 Subject: [plt-dev] display on console Message-ID: <8929CD4E-DD2B-4433-BDC7-04ECF14DA024@ccs.neu.edu> When I run the test engine (scheme), I am getting these outputs on the console: > (display-reason # #t #f) > (display-reason # #t #f) > (display-reason # #t #f) > (display-reason # #t #f) > (display-reason # #t #f) Is this going to be fixed for the release? From dherman at ccs.neu.edu Fri May 22 12:22:24 2009 From: dherman at ccs.neu.edu (Dave Herman) Date: Fri May 22 12:22:54 2009 Subject: [plt-dev] Pre-Release Checklist for v4.2 In-Reply-To: References: <4A165C9D.9010207@cs.utah.edu> <18966.24323.528862.177055@winooski.ccs.neu.edu> <1601792B-91E7-440A-A941-38A30EE7E795@ccs.neu.edu> Message-ID: <4A16D140.50901@ccs.neu.edu> > I would like to know why # isn't utilized more - or, > alternatively, why it exists in the first place. Is there a real > difference between no value (my mental model for #) and an > undefined/uninitialized value (my mental model for #)? I think your mental model is pretty accurate: # is primarily used for mutable entities that are only very briefly uninitialized. It's supposed to be extremely rare, especially because mutation is used much more sparingly in Scheme than other languages. By contrast, # is used for side effects that don't need to provide any useful result. That's not at all rare. By and large, my experience has been that if # shows up somewhere in a program, there's probably a bug, whereas # has lots of useful places to show up. Dave From matthias at ccs.neu.edu Fri May 22 12:32:31 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Fri May 22 12:33:12 2009 Subject: [plt-dev] lessons learned In-Reply-To: <46b603df0905220922o188c86a6w3294733306aa4f3@mail.gmail.com> References: <46b603df0905220922o188c86a6w3294733306aa4f3@mail.gmail.com> Message-ID: <2C59DF07-6DB5-4C8E-9E80-CCEC3183A62F@ccs.neu.edu> Sad fact: I agree with you and have brought up the idea in our world even before you moved to Google. Sadder fact is that this bug would have been caught with an evaluation. With a require in a mred repl. Done. No tests required. NONE. (When I modify someone else's code, I make sure to at least evaluate the definition. Usually I also ask where the test suite is.) Saddest fact is that I was stupid enough to think that our nightly tests actually executed each piece of code once. That would have revealed the code. I am just totally stupid and naive here. On May 22, 2009, at 12:22 PM, Jacob Matthews wrote: > I've said it before and I'll say it again: Set up a continuous > integration engine. Run the PLT Scheme test suites _all the time_ > (every checkin if possible --- this lets you isolate bugs to > individual svn submits or small ranges of them). Automatically measure > code coverage when the tests run. > > Your tests can catch problems like the one you discovered when they're > submitted rather than months later, but only if (1) you have tests, > (2) they actually exercise your code, and (3) you run them often. In > practice if you've got #3 you can measure #2, and measurement of #2 > drives you to do a better job of #1. > > You might want to look at tools like Hudson and CruiseControl for > ideas, though honestly it's probably easier to write your own --- > other tools would require you to write plugins in order to support PLT > Scheme anyway, and the core functionality is dead simple: it's just a > checkout-build-test loop. > > -jacob > > > On Thu, May 21, 2009 at 10:43 AM, Matthias Felleisen > wrote: >> >> Today's chase for the source of >> >> define-compound-unit/infer: untagged initialization dependent >> signature mred^ is supplied from a later unit with link temp4 >> >> cost me an hour of my time when a few seconds of common sense >> would have >> sufficed. I don't have such hours to waste. >> >> ;; --- >> >> LESSON 1: When I gave the POPL keynote a few years ago about our >> project, >> every single part of the talk had a single lesson: >> >> ************************** >> * ERROR MESSAGES MATTER. * >> ************************** >> >> I just can't see how the above error message would point anyone to >> this >> specification >> >>> (define-values/invoke-unit/infer >>> (export graphics^) >>> (link standard-mred@ graphics-posn-less@)) >> >> on line 15 of big-draw.ss. The name of the construct is different >> from that >> in the error message. And the message itself is gobbldedygook. >> >> ;; --- >> >> LESSON 2: People recently (27 Mar 2009) changed (see svn log, svn >> blame) >> these lines, and didn't even both to run the file as they did. >> >> ********************************* >> * WHEN YOU EDIT A FILE, RUN IT. * >> ********************************* >> >> It takes a cmd-t or a click-run and it evaluates in 3 seconds. >> Doing so >> would have revealed the bug. 3 SECONDS, 1 HOUR. >> >> ;; --- >> >> LESSON 3: When you do synthesize such language constructs, put the >> effort in >> to get them right. A simple topological sort would probably avoid >> all this >> nonsense. >> >> ;; --- >> >> Guys, this shop is not the federal government. We can't afford this >> sloppiness -- Matthias >> >> >> >> >> >> _________________________________________________ >> For list-related administrative tasks: >> http://list.cs.brown.edu/mailman/listinfo/plt-dev >> >> From clements at brinckerhoff.org Fri May 22 12:43:04 2009 From: clements at brinckerhoff.org (John Clements) Date: Fri May 22 12:43:26 2009 Subject: [plt-dev] Installation directories on Mac OS X In-Reply-To: References: Message-ID: <1BBCCDEF-18C5-4498-8808-46FED867F705@brinckerhoff.org> On May 21, 2009, at 12:42 PM, Thomas Deniau wrote: > Hi ! > > I'm trying to update the MacPorts port of mzscheme to version 4.1.5 > (the current port is at v. 372). I'm not going to help you with your problem, but I would like to *thank* you for tackling this. Thanks! John Clements -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2484 bytes Desc: not available Url : http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090522/f8970bea/smime.bin From jay.mccarthy at gmail.com Fri May 22 12:47:59 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Fri May 22 12:48:20 2009 Subject: [plt-dev] lessons learned In-Reply-To: <2C59DF07-6DB5-4C8E-9E80-CCEC3183A62F@ccs.neu.edu> References: <46b603df0905220922o188c86a6w3294733306aa4f3@mail.gmail.com> <2C59DF07-6DB5-4C8E-9E80-CCEC3183A62F@ccs.neu.edu> Message-ID: I will take charge of doing this if no-one else is dying to do it. I'll plan on running all the code and the test cases. If there are failures I'll send mail to the committer and the person listed on plt:resposibile. I'll figure out some way for you to put in properties or info files what shouldn't be run or what is a test cases, etc. If you have any ideas / comments, let me know. Jay On Fri, May 22, 2009 at 12:32 PM, Matthias Felleisen wrote: > > Sad fact: I agree with you and have brought up the idea in our world even > before you moved to Google. > > Sadder fact is that this bug would have been caught with an evaluation. With > a require in a mred repl. Done. No tests required. NONE. (When I modify > someone else's code, I make sure to at least evaluate the definition. > Usually I also ask where the test suite is.) > > Saddest fact is that I was stupid enough to think that our nightly tests > actually executed each piece of code once. That would have revealed the > code. I am just totally stupid and naive here. > > > On May 22, 2009, at 12:22 PM, Jacob Matthews wrote: > >> I've said it before and I'll say it again: Set up a continuous >> integration engine. Run the PLT Scheme test suites _all the time_ >> (every checkin if possible --- this lets you isolate bugs to >> individual svn submits or small ranges of them). Automatically measure >> code coverage when the tests run. >> >> Your tests can catch problems like the one you discovered when they're >> submitted rather than months later, but only if (1) you have tests, >> (2) they actually exercise your code, and (3) you run them often. In >> practice if you've got #3 you can measure #2, and measurement of #2 >> drives you to do a better job of #1. >> >> You might want to look at tools like Hudson and CruiseControl for >> ideas, though honestly it's probably easier to write your own --- >> other tools would require you to write plugins in order to support PLT >> Scheme anyway, and the core functionality is dead simple: it's just a >> checkout-build-test loop. >> >> -jacob >> >> >> On Thu, May 21, 2009 at 10:43 AM, Matthias Felleisen >> wrote: >>> >>> Today's chase for the source of >>> >>> ?define-compound-unit/infer: untagged initialization dependent >>> ?signature mred^ is supplied from a later unit with link temp4 >>> >>> cost me an hour of my time when a few seconds of common sense would have >>> sufficed. I don't have such hours to waste. >>> >>> ;; --- >>> >>> LESSON 1: When I gave the POPL keynote a few years ago about our project, >>> every single part of the talk had a single lesson: >>> >>> ? ? ************************** >>> ? ? * ERROR MESSAGES MATTER. * >>> ? ? ************************** >>> >>> I just can't see how the above error message would point anyone to this >>> specification >>> >>>> (define-values/invoke-unit/infer >>>> ?(export graphics^) >>>> ?(link standard-mred@ graphics-posn-less@)) >>> >>> on line 15 of big-draw.ss. The name of the construct is different from >>> that >>> in the error message. And the message itself is gobbldedygook. >>> >>> ;; --- >>> >>> LESSON 2: People recently (27 Mar 2009) changed (see svn log, svn blame) >>> these lines, and didn't even both to run the file as they did. >>> >>> ? ? ********************************* >>> ? ? * WHEN YOU EDIT A FILE, RUN IT. * >>> ? ? ********************************* >>> >>> It takes a cmd-t or a click-run and it evaluates in 3 seconds. Doing so >>> would have revealed the bug. 3 SECONDS, 1 HOUR. >>> >>> ;; --- >>> >>> LESSON 3: When you do synthesize such language constructs, put the effort >>> in >>> to get them right. A simple topological sort would probably avoid all >>> this >>> nonsense. >>> >>> ;; --- >>> >>> Guys, this shop is not the federal government. We can't afford this >>> sloppiness -- Matthias >>> >>> >>> >>> >>> >>> _________________________________________________ >>> ?For list-related administrative tasks: >>> ?http://list.cs.brown.edu/mailman/listinfo/plt-dev >>> >>> > > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From robby at eecs.northwestern.edu Fri May 22 12:53:51 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Fri May 22 12:54:18 2009 Subject: [plt-dev] lessons learned In-Reply-To: References: <46b603df0905220922o188c86a6w3294733306aa4f3@mail.gmail.com> <2C59DF07-6DB5-4C8E-9E80-CCEC3183A62F@ccs.neu.edu> Message-ID: <932b2f1f0905220953j504097f8h8c0b8bcff6dfa874@mail.gmail.com> I thought Eli was doing this on a nightly basis. So the problem here is, as Jacob surmised, missing (1)/(2), not (3). No? Robby On Fri, May 22, 2009 at 11:47 AM, Jay McCarthy wrote: > I will take charge of doing this if no-one else is dying to do it. > > I'll plan on running all the code and the test cases. If there are > failures I'll send mail to the committer and the person listed on > plt:resposibile. I'll figure out some way for you to put in properties > or info files what shouldn't be run or what is a test cases, etc. > > If you have any ideas / comments, let me know. > > Jay > > On Fri, May 22, 2009 at 12:32 PM, Matthias Felleisen > wrote: >> >> Sad fact: I agree with you and have brought up the idea in our world even >> before you moved to Google. >> >> Sadder fact is that this bug would have been caught with an evaluation. With >> a require in a mred repl. Done. No tests required. NONE. (When I modify >> someone else's code, I make sure to at least evaluate the definition. >> Usually I also ask where the test suite is.) >> >> Saddest fact is that I was stupid enough to think that our nightly tests >> actually executed each piece of code once. That would have revealed the >> code. I am just totally stupid and naive here. >> >> >> On May 22, 2009, at 12:22 PM, Jacob Matthews wrote: >> >>> I've said it before and I'll say it again: Set up a continuous >>> integration engine. Run the PLT Scheme test suites _all the time_ >>> (every checkin if possible --- this lets you isolate bugs to >>> individual svn submits or small ranges of them). Automatically measure >>> code coverage when the tests run. >>> >>> Your tests can catch problems like the one you discovered when they're >>> submitted rather than months later, but only if (1) you have tests, >>> (2) they actually exercise your code, and (3) you run them often. In >>> practice if you've got #3 you can measure #2, and measurement of #2 >>> drives you to do a better job of #1. >>> >>> You might want to look at tools like Hudson and CruiseControl for >>> ideas, though honestly it's probably easier to write your own --- >>> other tools would require you to write plugins in order to support PLT >>> Scheme anyway, and the core functionality is dead simple: it's just a >>> checkout-build-test loop. >>> >>> -jacob >>> >>> >>> On Thu, May 21, 2009 at 10:43 AM, Matthias Felleisen >>> wrote: >>>> >>>> Today's chase for the source of >>>> >>>> ?define-compound-unit/infer: untagged initialization dependent >>>> ?signature mred^ is supplied from a later unit with link temp4 >>>> >>>> cost me an hour of my time when a few seconds of common sense would have >>>> sufficed. I don't have such hours to waste. >>>> >>>> ;; --- >>>> >>>> LESSON 1: When I gave the POPL keynote a few years ago about our project, >>>> every single part of the talk had a single lesson: >>>> >>>> ? ? ************************** >>>> ? ? * ERROR MESSAGES MATTER. * >>>> ? ? ************************** >>>> >>>> I just can't see how the above error message would point anyone to this >>>> specification >>>> >>>>> (define-values/invoke-unit/infer >>>>> ?(export graphics^) >>>>> ?(link standard-mred@ graphics-posn-less@)) >>>> >>>> on line 15 of big-draw.ss. The name of the construct is different from >>>> that >>>> in the error message. And the message itself is gobbldedygook. >>>> >>>> ;; --- >>>> >>>> LESSON 2: People recently (27 Mar 2009) changed (see svn log, svn blame) >>>> these lines, and didn't even both to run the file as they did. >>>> >>>> ? ? ********************************* >>>> ? ? * WHEN YOU EDIT A FILE, RUN IT. * >>>> ? ? ********************************* >>>> >>>> It takes a cmd-t or a click-run and it evaluates in 3 seconds. Doing so >>>> would have revealed the bug. 3 SECONDS, 1 HOUR. >>>> >>>> ;; --- >>>> >>>> LESSON 3: When you do synthesize such language constructs, put the effort >>>> in >>>> to get them right. A simple topological sort would probably avoid all >>>> this >>>> nonsense. >>>> >>>> ;; --- >>>> >>>> Guys, this shop is not the federal government. We can't afford this >>>> sloppiness -- Matthias >>>> >>>> >>>> >>>> >>>> >>>> _________________________________________________ >>>> ?For list-related administrative tasks: >>>> ?http://list.cs.brown.edu/mailman/listinfo/plt-dev >>>> >>>> >> >> _________________________________________________ >> ?For list-related administrative tasks: >> ?http://list.cs.brown.edu/mailman/listinfo/plt-dev >> > > > > -- > Jay McCarthy > Assistant Professor / Brigham Young University > http://teammccarthy.org/jay > > "The glory of God is Intelligence" - D&C 93 > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > From jacobm at cs.uchicago.edu Fri May 22 12:22:20 2009 From: jacobm at cs.uchicago.edu (Jacob Matthews) Date: Fri May 22 12:54:56 2009 Subject: [plt-dev] lessons learned In-Reply-To: References: Message-ID: <46b603df0905220922o188c86a6w3294733306aa4f3@mail.gmail.com> I've said it before and I'll say it again: Set up a continuous integration engine. Run the PLT Scheme test suites _all the time_ (every checkin if possible --- this lets you isolate bugs to individual svn submits or small ranges of them). Automatically measure code coverage when the tests run. Your tests can catch problems like the one you discovered when they're submitted rather than months later, but only if (1) you have tests, (2) they actually exercise your code, and (3) you run them often. In practice if you've got #3 you can measure #2, and measurement of #2 drives you to do a better job of #1. You might want to look at tools like Hudson and CruiseControl for ideas, though honestly it's probably easier to write your own --- other tools would require you to write plugins in order to support PLT Scheme anyway, and the core functionality is dead simple: it's just a checkout-build-test loop. -jacob On Thu, May 21, 2009 at 10:43 AM, Matthias Felleisen wrote: > > Today's chase for the source of > > ? define-compound-unit/infer: untagged initialization dependent > ? signature mred^ is supplied from a later unit with link temp4 > > cost me an hour of my time when a few seconds of common sense would have > sufficed. I don't have such hours to waste. > > ;; --- > > LESSON 1: When I gave the POPL keynote a few years ago about our project, > every single part of the talk had a single lesson: > > ? ? ?************************** > ? ? ?* ERROR MESSAGES MATTER. * > ? ? ?************************** > > I just can't see how the above error message would point anyone to this > specification > >> (define-values/invoke-unit/infer >> ?(export graphics^) >> ?(link standard-mred@ graphics-posn-less@)) > > on line 15 of big-draw.ss. The name of the construct is different from that > in the error message. And the message itself is gobbldedygook. > > ;; --- > > LESSON 2: People recently (27 Mar 2009) changed (see svn log, svn blame) > these lines, and didn't even both to run the file as they did. > > ? ? ?********************************* > ? ? ?* WHEN YOU EDIT A FILE, RUN IT. * > ? ? ?********************************* > > It takes a cmd-t or a click-run and it evaluates in 3 seconds. Doing so > would have revealed the bug. 3 SECONDS, 1 HOUR. > > ;; --- > > LESSON 3: When you do synthesize such language constructs, put the effort in > to get them right. A simple topological sort would probably avoid all this > nonsense. > > ;; --- > > Guys, this shop is not the federal government. We can't afford this > sloppiness -- Matthias > > > > > > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > > From clements at brinckerhoff.org Fri May 22 12:58:28 2009 From: clements at brinckerhoff.org (John Clements) Date: Fri May 22 12:58:52 2009 Subject: [plt-dev] lessons learned In-Reply-To: References: <46b603df0905220922o188c86a6w3294733306aa4f3@mail.gmail.com> <2C59DF07-6DB5-4C8E-9E80-CCEC3183A62F@ccs.neu.edu> Message-ID: <60C72A01-5436-4C32-89B4-F46479D73B0E@brinckerhoff.org> On May 22, 2009, at 9:47 AM, Jay McCarthy wrote: > I will take charge of doing this if no-one else is dying to do it. > > I'll plan on running all the code and the test cases. If there are > failures I'll send mail to the committer and the person listed on > plt:resposibile. I'll figure out some way for you to put in properties > or info files what shouldn't be run or what is a test cases, etc. > > If you have any ideas / comments, let me know. Well, if you're volunteering, what I'd really like is a way to do coverage testing across multiple files; the current green/red mechanism doesn't scale well. Even within a single file, I often find myself slowly scrolling through the file looking for that tiny blip of red. John -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2484 bytes Desc: not available Url : http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090522/138fc413/smime.bin From eli at barzilay.org Fri May 22 13:00:49 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri May 22 13:01:11 2009 Subject: [plt-dev] lessons learned In-Reply-To: <60C72A01-5436-4C32-89B4-F46479D73B0E@brinckerhoff.org> References: <46b603df0905220922o188c86a6w3294733306aa4f3@mail.gmail.com> <2C59DF07-6DB5-4C8E-9E80-CCEC3183A62F@ccs.neu.edu> <60C72A01-5436-4C32-89B4-F46479D73B0E@brinckerhoff.org> Message-ID: <18966.55873.885474.894204@winooski.ccs.neu.edu> On May 22, John Clements wrote: > > Well, if you're volunteering, what I'd really like is a way to do > coverage testing across multiple files; the current green/red > mechanism doesn't scale well. In any case, measuring coverage for the tests is not practical ATM. > Even within a single file, I often find myself slowly scrolling > through the file looking for that tiny blip of red. +1 (but unrelated) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From jacobm at cs.uchicago.edu Fri May 22 13:03:32 2009 From: jacobm at cs.uchicago.edu (Jacob Matthews) Date: Fri May 22 13:03:53 2009 Subject: [plt-dev] lessons learned In-Reply-To: <18966.55873.885474.894204@winooski.ccs.neu.edu> References: <46b603df0905220922o188c86a6w3294733306aa4f3@mail.gmail.com> <2C59DF07-6DB5-4C8E-9E80-CCEC3183A62F@ccs.neu.edu> <60C72A01-5436-4C32-89B4-F46479D73B0E@brinckerhoff.org> <18966.55873.885474.894204@winooski.ccs.neu.edu> Message-ID: <46b603df0905221003gc88f2d5t50eca5a39c2f4769@mail.gmail.com> On Fri, May 22, 2009 at 10:00 AM, Eli Barzilay wrote: > On May 22, John Clements wrote: >> >> Well, if you're volunteering, what I'd really like is a way to do >> coverage testing across multiple files; the current green/red >> mechanism doesn't scale well. > > In any case, measuring coverage for the tests is not practical ATM. Out of curiosity: Why not? > > >> Even within a single file, I often find myself slowly scrolling >> through the file looking for that tiny blip of red. > > +1 (but unrelated) > > -- > ? ? ? ? ?((lambda (x) (x x)) (lambda (x) (x x))) ? ? ? ? ?Eli Barzilay: > ? ? ? ? ? ? ? ? ?http://www.barzilay.org/ ? ? ? ? ? ? ? ? Maze is Life! > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > > From eli at barzilay.org Fri May 22 13:04:41 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri May 22 13:05:04 2009 Subject: [plt-dev] lessons learned In-Reply-To: <932b2f1f0905220953j504097f8h8c0b8bcff6dfa874@mail.gmail.com> References: <46b603df0905220922o188c86a6w3294733306aa4f3@mail.gmail.com> <2C59DF07-6DB5-4C8E-9E80-CCEC3183A62F@ccs.neu.edu> <932b2f1f0905220953j504097f8h8c0b8bcff6dfa874@mail.gmail.com> Message-ID: <18966.56105.943672.913802@winooski.ccs.neu.edu> Yes, the build is running nightly, and sometimes there are additional builds, and it includes running everything hooked onto collects/tests/run-automated-tests.ss and there's a human reading (=suffering) the results in case of test problems and emailing people when necessary. The only addition that I thought might be cute is to do the per-commit build but only locally, avoiding much of the work, but the gain is neglegible. Ideally, all automated testing should be done through that file. (2) is impractical. On May 22, Robby Findler wrote: > I thought Eli was doing this on a nightly basis. So the problem here > is, as Jacob surmised, missing (1)/(2), not (3). > > No? > > Robby > > On Fri, May 22, 2009 at 11:47 AM, Jay McCarthy wrote: > > I will take charge of doing this if no-one else is dying to do it. > > > > I'll plan on running all the code and the test cases. If there are > > failures I'll send mail to the committer and the person listed on > > plt:resposibile. I'll figure out some way for you to put in properties > > or info files what shouldn't be run or what is a test cases, etc. > > > > If you have any ideas / comments, let me know. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From eli at barzilay.org Fri May 22 13:08:14 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri May 22 13:08:35 2009 Subject: [plt-dev] lessons learned In-Reply-To: <46b603df0905221003gc88f2d5t50eca5a39c2f4769@mail.gmail.com> References: <46b603df0905220922o188c86a6w3294733306aa4f3@mail.gmail.com> <2C59DF07-6DB5-4C8E-9E80-CCEC3183A62F@ccs.neu.edu> <60C72A01-5436-4C32-89B4-F46479D73B0E@brinckerhoff.org> <18966.55873.885474.894204@winooski.ccs.neu.edu> <46b603df0905221003gc88f2d5t50eca5a39c2f4769@mail.gmail.com> Message-ID: <18966.56318.62898.672069@winooski.ccs.neu.edu> On May 22, Jacob Matthews wrote: > On Fri, May 22, 2009 at 10:00 AM, Eli Barzilay wrote: > > On May 22, John Clements wrote: > >> > >> Well, if you're volunteering, what I'd really like is a way to do > >> coverage testing across multiple files; the current green/red > >> mechanism doesn't scale well. > > > > In any case, measuring coverage for the tests is not practical ATM. > > Out of curiosity: Why not? (a) errortrace is adding a good runtime factor -- and the tests take a considerable time (compiling in errortrace mode can work too, but even that is horribly expensive) (b) There's a *lot* of code, so keeping track of all expressions will be a problem (c) code is executed one test suite at a time, so it will require running it, collecting the results, etc, then combining them all. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From eli at barzilay.org Fri May 22 13:11:07 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri May 22 13:11:29 2009 Subject: [plt-dev] lessons learned In-Reply-To: <2C59DF07-6DB5-4C8E-9E80-CCEC3183A62F@ccs.neu.edu> References: <46b603df0905220922o188c86a6w3294733306aa4f3@mail.gmail.com> <2C59DF07-6DB5-4C8E-9E80-CCEC3183A62F@ccs.neu.edu> Message-ID: <18966.56491.884742.376673@winooski.ccs.neu.edu> On May 22, Matthias Felleisen wrote: > > Saddest fact is that I was stupid enough to think that our nightly > tests actually executed each piece of code once. That would have > revealed the code. I am just totally stupid and naive here. The only thing that gets executed are the tests (in tests/run-automated-tests.ss). To touch more code, the build also starts drscheme and checks to see that it actually was started. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From jensaxel at soegaard.net Fri May 22 13:14:06 2009 From: jensaxel at soegaard.net (Jens Axel Soegaard) Date: Fri May 22 13:14:28 2009 Subject: [plt-dev] lessons learned In-Reply-To: <2C59DF07-6DB5-4C8E-9E80-CCEC3183A62F@ccs.neu.edu> References: <46b603df0905220922o188c86a6w3294733306aa4f3@mail.gmail.com> <2C59DF07-6DB5-4C8E-9E80-CCEC3183A62F@ccs.neu.edu> Message-ID: <4A16DD5E.2@soegaard.net> Matthias Felleisen wrote: > Saddest fact is that I was stupid enough to think that our nightly tests > actually executed each piece of code once. That would have revealed the > code. I am just totally stupid and naive here. This (writing tests for modules without test suites) would be a perfect thing to put on the elusive list of projects that PLT would like people to contribute to. -- Jens Axel S?gaard From eli at barzilay.org Fri May 22 13:28:45 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri May 22 13:29:22 2009 Subject: [plt-dev] Pre-Release Checklist for v4.2 In-Reply-To: <1601792B-91E7-440A-A941-38A30EE7E795@ccs.neu.edu> References: <4A165C9D.9010207@cs.utah.edu> <18966.24323.528862.177055@winooski.ccs.neu.edu> <1601792B-91E7-440A-A941-38A30EE7E795@ccs.neu.edu> Message-ID: <18966.57549.784132.161225@winooski.ccs.neu.edu> The problem is that this leaves us with an incompatible srfi/1 (which is why I wrote the second option). (BTW, I wouldn't mind such incompatibility, but I don't care about `make-list' anyway.) On May 22, Matthias Felleisen wrote: > > make-list always takes two arguments. There is no natural fill value. > > > > On May 22, 2009, at 4:14 AM, Eli Barzilay wrote: > > > On May 22, Chongkai Zhu wrote: > >> > >> procedure make-list: expects 2 arguments, given 1: 0 > > > > OK, quick poll time: > > > > 1. What should the default value be (#f as it was, # because it > > makes more sense, or 0 because that's what `make-vector' uses)? > > > > 2. Which one should be fixed -- only the srfi/1 version, or the > > scheme/list version (implying srfi/1 too)? -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From eli at barzilay.org Fri May 22 13:30:07 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri May 22 13:30:30 2009 Subject: [plt-dev] Pre-Release Checklist for v4.2 In-Reply-To: <1601792B-91E7-440A-A941-38A30EE7E795@ccs.neu.edu> References: <4A165C9D.9010207@cs.utah.edu> <18966.24323.528862.177055@winooski.ccs.neu.edu> <1601792B-91E7-440A-A941-38A30EE7E795@ccs.neu.edu> Message-ID: <18966.57631.734263.184874@winooski.ccs.neu.edu> And BTW, these are two votes -- I expected many more people to say something given how many people wanted to see this thing in. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From jacobm at cs.uchicago.edu Fri May 22 13:39:10 2009 From: jacobm at cs.uchicago.edu (Jacob Matthews) Date: Fri May 22 13:39:33 2009 Subject: [plt-dev] lessons learned In-Reply-To: <18966.56318.62898.672069@winooski.ccs.neu.edu> References: <46b603df0905220922o188c86a6w3294733306aa4f3@mail.gmail.com> <2C59DF07-6DB5-4C8E-9E80-CCEC3183A62F@ccs.neu.edu> <60C72A01-5436-4C32-89B4-F46479D73B0E@brinckerhoff.org> <18966.55873.885474.894204@winooski.ccs.neu.edu> <46b603df0905221003gc88f2d5t50eca5a39c2f4769@mail.gmail.com> <18966.56318.62898.672069@winooski.ccs.neu.edu> Message-ID: <46b603df0905221039i4ff422edvc53348d98231bb83@mail.gmail.com> I don't mean to argue with you about this, but I don't really find these points convincing. After all, we manage to make it work even though I'm pretty sure we've got way more code than PLT Scheme. (To quote Kevin Bourrillion, Google's Java library curator: "If code were ice cream, we would have ... a whole lot of ice cream.") I think what you're really saying is that it's impractical to test all of PLT Scheme with one central testing service that tries to do the whole thing at once. I can definitely believe that. I think the key might be in making the process more modular --- a continuous build with "all of PLT Scheme" as its target is orders of magnitude too big to be very useful IMO. One way to chop things up would be to have separate builds for different components: a mzscheme build, a mred build, a drscheme build (or maybe further break down DrS into smaller pieces and potentially several other components for different collects. Each sub-build runs the test suites appropriate to it, and just measures code coverage in the files it cares about. (In practice, even though a test suite written to cover, say, a mred component might incidentally cover some mzlib stuff, that coverage isn't very high-quality and probably shouldn't count as mzlib tests anyway.) Sub-builds can run independently on different machines, set up by individual groups. When I was working on planet, for instance, I could've set up my own sub-project just for it, and had the system run on my local machine. (I do effectively the same thing on my current project.) One way to think about it is: suppose you're monitoring the the output of tests, and you get a message saying some tests have failed. Do you care? If you don't, you need to think about making better targets, and only monitoring the targets for which you can unhesitatingly say yes. This will incidentally make it a lot easier for smaller projects to get up and running. Coverage is actually a really important metric for test suites; without it, you get the warm fuzzies of seeing that all tests passed, but you don't get any sense whatsoever about how much assurance you can derive from them. It is worth investing effort into measuring it. -jacob (Part of my current job is to advocate good testing practices and help other teams set up good testing infrastructure for their projects, so if I come off like an evangelist, that's why. :) ) On Fri, May 22, 2009 at 10:08 AM, Eli Barzilay wrote: > On May 22, Jacob Matthews wrote: >> On Fri, May 22, 2009 at 10:00 AM, Eli Barzilay wrote: >> > On May 22, John Clements wrote: >> >> >> >> Well, if you're volunteering, what I'd really like is a way to do >> >> coverage testing across multiple files; the current green/red >> >> mechanism doesn't scale well. >> > >> > In any case, measuring coverage for the tests is not practical ATM. >> >> Out of curiosity: Why not? > > (a) errortrace is adding a good runtime factor -- and the tests take a > ? ?considerable time (compiling in errortrace mode can work too, but > ? ?even that is horribly expensive) > > (b) There's a *lot* of code, so keeping track of all expressions will > ? ?be a problem > > (c) code is executed one test suite at a time, so it will require > ? ?running it, collecting the results, etc, then combining them all. > > -- > ? ? ? ? ?((lambda (x) (x x)) (lambda (x) (x x))) ? ? ? ? ?Eli Barzilay: > ? ? ? ? ? ? ? ? ?http://www.barzilay.org/ ? ? ? ? ? ? ? ? Maze is Life! > > From eli at barzilay.org Fri May 22 13:54:40 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri May 22 13:55:01 2009 Subject: [plt-dev] lessons learned In-Reply-To: <46b603df0905221039i4ff422edvc53348d98231bb83@mail.gmail.com> References: <46b603df0905220922o188c86a6w3294733306aa4f3@mail.gmail.com> <2C59DF07-6DB5-4C8E-9E80-CCEC3183A62F@ccs.neu.edu> <60C72A01-5436-4C32-89B4-F46479D73B0E@brinckerhoff.org> <18966.55873.885474.894204@winooski.ccs.neu.edu> <46b603df0905221003gc88f2d5t50eca5a39c2f4769@mail.gmail.com> <18966.56318.62898.672069@winooski.ccs.neu.edu> <46b603df0905221039i4ff422edvc53348d98231bb83@mail.gmail.com> Message-ID: <18966.59104.905295.355372@winooski.ccs.neu.edu> On May 22, Jacob Matthews wrote: > I don't mean to argue with you about this, but I don't really find > these points convincing. After all, we manage to make it work even > though I'm pretty sure we've got way more code than PLT Scheme. (To > quote Kevin Bourrillion, Google's Java library curator: "If code > were ice cream, we would have ... a whole lot of ice cream.") re (a) I'm sure that you also are running things a little faster, and utilizing a few more cpus on the way. Last time (only time) I tried to compile all of plt in errortrace mode, it took around 2 hours; extrapolating from the current build times, this means that the solaris run will take more than 8 hours not counting running the code. re (b) -- yes, you have much more code, probably enough that keeping it all in memory is impractical anyway. This is another possible improvement to errortrace: keep the coverage points on disk. It won't help with the current system though, and in any case we don't have a server farm. Not even a server garden. More like a window box in my office and sneaking into other people's parties at night. This is also related to my (c) point. > I think what you're really saying is that it's impractical to test > all of PLT Scheme with one central testing service that tries to do > the whole thing at once. I can definitely believe that. I think the > key might be in making the process more modular --- a continuous > build with "all of PLT Scheme" as its target is orders of magnitude > too big to be very useful IMO. One way to chop things up would be to > have separate builds for different components: a mzscheme build, a > mred build, a drscheme build (or maybe further break down DrS into > smaller pieces and potentially several other components for > different collects. Each sub-build runs the test suites appropriate > to it, and just measures code coverage in the files it cares about. > (In practice, even though a test suite written to cover, say, a mred > component might incidentally cover some mzlib stuff, that coverage > isn't very high-quality and probably shouldn't count as mzlib tests > anyway.) Sub-builds can run independently on different machines, > set up by individual groups. When I was working on planet, for > instance, I could've set up my own sub-project just for it, and had > the system run on my local machine. (I do effectively the same thing > on my current project.) Yes, all of that makes sense. Care to donate a small farm? IOW, it will require work to make this possible -- not much work, but currently there is no visible gains from it. > One way to think about it is: suppose you're monitoring the the > output of tests, and you get a message saying some tests have > failed. Do you care? If you don't, you need to think about making > better targets, and only monitoring the targets for which you can > unhesitatingly say yes. This will incidentally make it a lot easier > for smaller projects to get up and running. That's a good point too. Had there been more tests, I'd arrange for failure alerts to be sent to the responsible parties. Currently, I get an email when tests fail, and I nag the responsible party. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From matthias at ccs.neu.edu Fri May 22 14:02:47 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Fri May 22 14:03:29 2009 Subject: [plt-dev] lessons learned In-Reply-To: References: <46b603df0905220922o188c86a6w3294733306aa4f3@mail.gmail.com> <2C59DF07-6DB5-4C8E-9E80-CCEC3183A62F@ccs.neu.edu> Message-ID: Jay, thanks for volunteering to do something. That was truly positive, and it made my day. The one thing I'd like to add to Eli's nightly build is some way of just evaluating each file once. Period. If it doesn't load, send a message and nag. Just like for the test cases. (I do have a separate test suite for /htdp and /2htdp, but they aren't automated.) Over the upcoming decades, I wouldn't mind seeing some way of testing more, running it continuously, etc. If someone really wants to do this, I will get a farm or two or three of machines. -- Matthias On May 22, 2009, at 12:47 PM, Jay McCarthy wrote: > I will take charge of doing this if no-one else is dying to do it. > > I'll plan on running all the code and the test cases. If there are > failures I'll send mail to the committer and the person listed on > plt:resposibile. I'll figure out some way for you to put in properties > or info files what shouldn't be run or what is a test cases, etc. > > If you have any ideas / comments, let me know. > > Jay > > On Fri, May 22, 2009 at 12:32 PM, Matthias Felleisen > wrote: >> >> Sad fact: I agree with you and have brought up the idea in our >> world even >> before you moved to Google. >> >> Sadder fact is that this bug would have been caught with an >> evaluation. With >> a require in a mred repl. Done. No tests required. NONE. (When I >> modify >> someone else's code, I make sure to at least evaluate the definition. >> Usually I also ask where the test suite is.) >> >> Saddest fact is that I was stupid enough to think that our nightly >> tests >> actually executed each piece of code once. That would have >> revealed the >> code. I am just totally stupid and naive here. >> >> >> On May 22, 2009, at 12:22 PM, Jacob Matthews wrote: >> >>> I've said it before and I'll say it again: Set up a continuous >>> integration engine. Run the PLT Scheme test suites _all the time_ >>> (every checkin if possible --- this lets you isolate bugs to >>> individual svn submits or small ranges of them). Automatically >>> measure >>> code coverage when the tests run. >>> >>> Your tests can catch problems like the one you discovered when >>> they're >>> submitted rather than months later, but only if (1) you have tests, >>> (2) they actually exercise your code, and (3) you run them often. In >>> practice if you've got #3 you can measure #2, and measurement of #2 >>> drives you to do a better job of #1. >>> >>> You might want to look at tools like Hudson and CruiseControl for >>> ideas, though honestly it's probably easier to write your own --- >>> other tools would require you to write plugins in order to >>> support PLT >>> Scheme anyway, and the core functionality is dead simple: it's >>> just a >>> checkout-build-test loop. >>> >>> -jacob >>> >>> >>> On Thu, May 21, 2009 at 10:43 AM, Matthias Felleisen >>> wrote: >>>> >>>> Today's chase for the source of >>>> >>>> define-compound-unit/infer: untagged initialization dependent >>>> signature mred^ is supplied from a later unit with link temp4 >>>> >>>> cost me an hour of my time when a few seconds of common sense >>>> would have >>>> sufficed. I don't have such hours to waste. >>>> >>>> ;; --- >>>> >>>> LESSON 1: When I gave the POPL keynote a few years ago about our >>>> project, >>>> every single part of the talk had a single lesson: >>>> >>>> ************************** >>>> * ERROR MESSAGES MATTER. * >>>> ************************** >>>> >>>> I just can't see how the above error message would point anyone >>>> to this >>>> specification >>>> >>>>> (define-values/invoke-unit/infer >>>>> (export graphics^) >>>>> (link standard-mred@ graphics-posn-less@)) >>>> >>>> on line 15 of big-draw.ss. The name of the construct is >>>> different from >>>> that >>>> in the error message. And the message itself is gobbldedygook. >>>> >>>> ;; --- >>>> >>>> LESSON 2: People recently (27 Mar 2009) changed (see svn log, >>>> svn blame) >>>> these lines, and didn't even both to run the file as they did. >>>> >>>> ********************************* >>>> * WHEN YOU EDIT A FILE, RUN IT. * >>>> ********************************* >>>> >>>> It takes a cmd-t or a click-run and it evaluates in 3 seconds. >>>> Doing so >>>> would have revealed the bug. 3 SECONDS, 1 HOUR. >>>> >>>> ;; --- >>>> >>>> LESSON 3: When you do synthesize such language constructs, put >>>> the effort >>>> in >>>> to get them right. A simple topological sort would probably >>>> avoid all >>>> this >>>> nonsense. >>>> >>>> ;; --- >>>> >>>> Guys, this shop is not the federal government. We can't afford this >>>> sloppiness -- Matthias >>>> >>>> >>>> >>>> >>>> >>>> _________________________________________________ >>>> For list-related administrative tasks: >>>> http://list.cs.brown.edu/mailman/listinfo/plt-dev >>>> >>>> >> >> _________________________________________________ >> For list-related administrative tasks: >> http://list.cs.brown.edu/mailman/listinfo/plt-dev >> > > > > -- > Jay McCarthy > Assistant Professor / Brigham Young University > http://teammccarthy.org/jay > > "The glory of God is Intelligence" - D&C 93 From mflatt at cs.utah.edu Fri May 22 14:43:51 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Fri May 22 14:44:17 2009 Subject: [plt-dev] Pre-Release Checklist for v4.2 In-Reply-To: <18966.57549.784132.161225@winooski.ccs.neu.edu> References: <4A165C9D.9010207@cs.utah.edu> <18966.24323.528862.177055@winooski.ccs.neu.edu> <1601792B-91E7-440A-A941-38A30EE7E795@ccs.neu.edu> <18966.57549.784132.161225@winooski.ccs.neu.edu> Message-ID: <20090522184353.0423965008D@mail-svr1.cs.utah.edu> I think just the `srfi/1' implementation should change, and #f seems like a fine default --- useless, but compatible. At Fri, 22 May 2009 13:28:45 -0400, Eli Barzilay wrote: > The problem is that this leaves us with an incompatible srfi/1 (which > is why I wrote the second option). (BTW, I wouldn't mind such > incompatibility, but I don't care about `make-list' anyway.) > > > On May 22, Matthias Felleisen wrote: > > > > make-list always takes two arguments. There is no natural fill value. > > > > > > > > On May 22, 2009, at 4:14 AM, Eli Barzilay wrote: > > > > > On May 22, Chongkai Zhu wrote: > > >> > > >> procedure make-list: expects 2 arguments, given 1: 0 > > > > > > OK, quick poll time: > > > > > > 1. What should the default value be (#f as it was, # because it > > > makes more sense, or 0 because that's what `make-vector' uses)? > > > > > > 2. Which one should be fixed -- only the srfi/1 version, or the > > > scheme/list version (implying srfi/1 too)? > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > http://www.barzilay.org/ Maze is Life! From robby at eecs.northwestern.edu Fri May 22 14:45:35 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Fri May 22 14:45:53 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.2 In-Reply-To: References: Message-ID: <932b2f1f0905221145x6ecdc9f9g81656458e0dbc1fc@mail.gmail.com> On Wed, May 20, 2009 at 5:05 AM, Eli Barzilay wrote: > * Robby Findler > ?- DrScheme Tests > ?- Teachpacks Tests: image tests > - Framework Tests > - Contracts Tests > - Games Tests > ?- PLaneT Tests > ?Updates: > ?- DrScheme Updates: update HISTORY > ?- Redex Updates: update HISTORY > ?(updates should show v4.2 as the most current version) > ?- Ensure that previous version of DrScheme's preference files still > ? ?starts up with new DrScheme > ?- Update man pages in plt/man/man1: drscheme.1 > ?Email me to merge the changes from the trunk when they're done, > ?or tell me if there are no such changes. done. Robby From dherman at ccs.neu.edu Fri May 22 14:48:25 2009 From: dherman at ccs.neu.edu (Dave Herman) Date: Fri May 22 14:48:54 2009 Subject: [plt-dev] slightly misleading error Message-ID: <4A16F379.2020906@ccs.neu.edu> This code: (define (foo) (values 'a 'b)) (let ([x (foo)]) x) highlights the expression (values 'a 'b) and produces the error message: context expected 1 value, received 2 values: a b The highlighted expression was the producer, but the message was about the context. This confused me when it happened to me, because I assumed the highlighted expression /was/ the context, and set about hopelessly trying to figure out what *inside* that expression had produced the wrong number of values. This is one of those "two parties disagree but there's no expressed contract" kinds of errors, so highlighting either party is reasonable, but the error message should probably be consistent with what's highlighted in order to avoid this confusion. Thanks, Dave From clements at brinckerhoff.org Fri May 22 14:52:32 2009 From: clements at brinckerhoff.org (John Clements) Date: Fri May 22 14:52:52 2009 Subject: [plt-dev] slightly misleading error In-Reply-To: <4A16F379.2020906@ccs.neu.edu> References: <4A16F379.2020906@ccs.neu.edu> Message-ID: On May 22, 2009, at 11:48 AM, Dave Herman wrote: > This code: > > (define (foo) (values 'a 'b)) > (let ([x (foo)]) x) > > highlights the expression (values 'a 'b) and produces the error > message: > > context expected 1 value, received 2 values: a b > > The highlighted expression was the producer, but the message was > about the context. This confused me when it happened to me, because > I assumed the highlighted expression /was/ the context, and set > about hopelessly trying to figure out what *inside* that expression > had produced the wrong number of values. > > This is one of those "two parties disagree but there's no expressed > contract" kinds of errors, so highlighting either party is > reasonable, but the error message should probably be consistent with > what's highlighted in order to avoid this confusion. Could you fix this by just changing the error message to "context of this expression expected 1 value, received 2 values: a b" ? John -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2484 bytes Desc: not available Url : http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090522/7cab6230/smime.bin From dherman at ccs.neu.edu Fri May 22 14:58:53 2009 From: dherman at ccs.neu.edu (Dave Herman) Date: Fri May 22 14:59:23 2009 Subject: [plt-dev] slightly misleading error In-Reply-To: References: <4A16F379.2020906@ccs.neu.edu> Message-ID: <4A16F5ED.9030708@ccs.neu.edu> > Could you fix this by just changing the error message to > > "context of this expression expected 1 value, received 2 values: a b" That still seems a little confusing to me, especially the fact that "received" is not so obviously tied to "context of [i.e., which is not the same as] this expression." Dave From clements at brinckerhoff.org Fri May 22 14:59:34 2009 From: clements at brinckerhoff.org (John Clements) Date: Fri May 22 14:59:58 2009 Subject: [plt-dev] 4.2 release should go to plt-scheme for testing first? In-Reply-To: <932b2f1f0905221145x6ecdc9f9g81656458e0dbc1fc@mail.gmail.com> References: <932b2f1f0905221145x6ecdc9f9g81656458e0dbc1fc@mail.gmail.com> Message-ID: <24833B92-84E2-4F99-8C2E-49CE0C1A2359@brinckerhoff.org> On May 22, 2009, at 11:45 AM, Robby Findler wrote: > On Wed, May 20, 2009 at 5:05 AM, Eli Barzilay > wrote: >> * Robby Findler >> - DrScheme Tests >> - Teachpacks Tests: image tests >> - Framework Tests >> - Contracts Tests >> - Games Tests >> - PLaneT Tests >> Updates: >> - DrScheme Updates: update HISTORY >> - Redex Updates: update HISTORY >> (updates should show v4.2 as the most current version) >> - Ensure that previous version of DrScheme's preference files still >> starts up with new DrScheme >> - Update man pages in plt/man/man1: drscheme.1 >> Email me to merge the changes from the trunk when they're done, >> or tell me if there are no such changes. > > done. I'm concerned that this release might not be ready for a large audience, particularly as a major version bump. Should we consider taking Eli's suggestion and asking for pre-release testing from plt- scheme? John -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2484 bytes Desc: not available Url : http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090522/e515f0c8/smime.bin From robby at eecs.northwestern.edu Fri May 22 15:04:24 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Fri May 22 15:04:46 2009 Subject: [plt-dev] 4.2 release should go to plt-scheme for testing first? In-Reply-To: <24833B92-84E2-4F99-8C2E-49CE0C1A2359@brinckerhoff.org> References: <932b2f1f0905221145x6ecdc9f9g81656458e0dbc1fc@mail.gmail.com> <24833B92-84E2-4F99-8C2E-49CE0C1A2359@brinckerhoff.org> Message-ID: <932b2f1f0905221204w340de0cdt794e0e8f1c3c0646@mail.gmail.com> Are you quoting my message specifically for a reason? And major version bumps are when things are least stable, not most stable! Robby On Fri, May 22, 2009 at 1:59 PM, John Clements wrote: > > On May 22, 2009, at 11:45 AM, Robby Findler wrote: > >> On Wed, May 20, 2009 at 5:05 AM, Eli Barzilay wrote: >>> >>> * Robby Findler >>> ?- DrScheme Tests >>> ?- Teachpacks Tests: image tests >>> - Framework Tests >>> - Contracts Tests >>> - Games Tests >>> ?- PLaneT Tests >>> ?Updates: >>> ?- DrScheme Updates: update HISTORY >>> ?- Redex Updates: update HISTORY >>> ?(updates should show v4.2 as the most current version) >>> ?- Ensure that previous version of DrScheme's preference files still >>> ? starts up with new DrScheme >>> ?- Update man pages in plt/man/man1: drscheme.1 >>> ?Email me to merge the changes from the trunk when they're done, >>> ?or tell me if there are no such changes. >> >> done. > > I'm concerned that this release might not be ready for a large audience, > particularly as a major version bump. ?Should we consider taking Eli's > suggestion and asking for pre-release testing from plt-scheme? > > John > > > > > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > > From carl.eastlund at gmail.com Fri May 22 15:05:35 2009 From: carl.eastlund at gmail.com (Carl Eastlund) Date: Fri May 22 15:05:56 2009 Subject: [plt-dev] slightly misleading error In-Reply-To: <4A16F5ED.9030708@ccs.neu.edu> References: <4A16F379.2020906@ccs.neu.edu> <4A16F5ED.9030708@ccs.neu.edu> Message-ID: <990e0c030905221205u721260cev714079cc37b66549@mail.gmail.com> On Fri, May 22, 2009 at 2:58 PM, Dave Herman wrote: >> Could you fix this by just changing the error message to >> >> "context of this expression expected 1 value, received 2 values: a b" > > That still seems a little confusing to me, especially the fact that > "received" is not so obviously tied to "context of [i.e., which is not the > same as] this expression." How about: "the dynamic context of this expression expected 1 value, but this expression produced 2 values instead: a b" -- Carl Eastlund From dherman at ccs.neu.edu Fri May 22 15:09:25 2009 From: dherman at ccs.neu.edu (Dave Herman) Date: Fri May 22 15:10:14 2009 Subject: [plt-dev] slightly misleading error In-Reply-To: <990e0c030905221205u721260cev714079cc37b66549@mail.gmail.com> References: <4A16F379.2020906@ccs.neu.edu> <4A16F5ED.9030708@ccs.neu.edu> <990e0c030905221205u721260cev714079cc37b66549@mail.gmail.com> Message-ID: <4A16F865.2090903@ccs.neu.edu> > How about: > > "the dynamic context of this expression expected 1 value, but this > expression produced 2 values instead: a b" Fine with me, but one question: are there situations where this same message will be produced but the producer expression *won't* be the one highlighted? For example, if the producer expression is bytecode-compiled? If so, there should either be two different error messages for the different situations, or the English has to be very carefully chosen to make sense in both cases. Dave From jay.mccarthy at gmail.com Fri May 22 15:09:41 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Fri May 22 15:10:18 2009 Subject: [plt-dev] lessons learned In-Reply-To: References: <46b603df0905220922o188c86a6w3294733306aa4f3@mail.gmail.com> <2C59DF07-6DB5-4C8E-9E80-CCEC3183A62F@ccs.neu.edu> Message-ID: On Fri, May 22, 2009 at 2:02 PM, Matthias Felleisen wrote: > The one thing I'd like to add to Eli's nightly build is some way of just > evaluating each file once. Period. If it doesn't load, send a message and > nag. Just like for the test cases. (I do have a separate test suite for > /htdp and /2htdp, but they aren't automated.) It seems like Eli's build is doing two things: producing the binaries for download and doing the automated tests linked in tests/. It makes sense to the first only nightly, but the second every commit. I can buy a machine and have it do the testing part basically 24/7 at BYU. I'll have it re-compile mzscheme only when the C code changes and the byte-code always. Then I'll load each file (which will include the tests, of course) and send blame to the most recent committer and the owner (via plt:responsible) of the file. I'll have a web page that shows the success of each file's loading and any messages spit out when it runs. At the beginning I can be testing library agnostic if I can assume any output to stderr is an error. I think that will be a lot better than what we have now and then we can experiment with better ways of communicating errors and coverage to my setup. For example, Eli is referring to errortrace as if it is the only option. I reckon if we just want to know whether some line of a file has been run we could get by with less information than is provided by errortrace. Anyways... that's my plan. Before I turn it live and you start getting obnoxious emails, I'll get more permission. Jay -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From clements at brinckerhoff.org Fri May 22 15:14:06 2009 From: clements at brinckerhoff.org (John Clements) Date: Fri May 22 15:14:30 2009 Subject: [plt-dev] 4.2 release should go to plt-scheme for testing first? In-Reply-To: <932b2f1f0905221204w340de0cdt794e0e8f1c3c0646@mail.gmail.com> References: <932b2f1f0905221145x6ecdc9f9g81656458e0dbc1fc@mail.gmail.com> <24833B92-84E2-4F99-8C2E-49CE0C1A2359@brinckerhoff.org> <932b2f1f0905221204w340de0cdt794e0e8f1c3c0646@mail.gmail.com> Message-ID: <9FCD949D-CC17-4145-98BA-987555396DA6@brinckerhoff.org> On May 22, 2009, at 12:04 PM, Robby Findler wrote: > Are you quoting my message specifically for a reason? Honestly, the reason that your message prompted my response was that I just fixed a bug in the stepper that I asked Eli to add to the release, and this code clearly wasn't in the code that you tested. That makes me nervous. > And major version bumps are when things are least stable, not most > stable! Yes, but I suspect that major version bumps are those that elicit the "ooh, maybe I should try upgrading this thing!" response from casual users. John -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2484 bytes Desc: not available Url : http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090522/9510bc40/smime.bin From acowley at seas.upenn.edu Fri May 22 15:23:18 2009 From: acowley at seas.upenn.edu (Anthony Cowley) Date: Fri May 22 15:23:40 2009 Subject: [plt-dev] slightly misleading error In-Reply-To: <4A16F865.2090903@ccs.neu.edu> References: <4A16F379.2020906@ccs.neu.edu> <4A16F5ED.9030708@ccs.neu.edu> <990e0c030905221205u721260cev714079cc37b66549@mail.gmail.com> <4A16F865.2090903@ccs.neu.edu> Message-ID: <81addec70905221223i36d3916eoacc5bc996808dd17@mail.gmail.com> On Fri, May 22, 2009 at 3:09 PM, Dave Herman wrote: >> How about: >> >> "the dynamic context of this expression expected 1 value, but this >> expression produced 2 values instead: a b" How about, "Expression produced 2 values, but the context exected 1." Anthony From matthias at ccs.neu.edu Fri May 22 15:26:55 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Fri May 22 15:27:51 2009 Subject: [plt-dev] lessons learned In-Reply-To: References: <46b603df0905220922o188c86a6w3294733306aa4f3@mail.gmail.com> <2C59DF07-6DB5-4C8E-9E80-CCEC3183A62F@ccs.neu.edu> Message-ID: I like your idea a lot. (I am sure you realize that some files need to be loaded in mred.) Keep us posted about the progress -- Matthias On May 22, 2009, at 3:09 PM, Jay McCarthy wrote: > On Fri, May 22, 2009 at 2:02 PM, Matthias Felleisen > wrote: >> The one thing I'd like to add to Eli's nightly build is some way >> of just >> evaluating each file once. Period. If it doesn't load, send a >> message and >> nag. Just like for the test cases. (I do have a separate test >> suite for >> /htdp and /2htdp, but they aren't automated.) > > It seems like Eli's build is doing two things: producing the binaries > for download and doing the automated tests linked in tests/. It makes > sense to the first only nightly, but the second every commit. > > I can buy a machine and have it do the testing part basically 24/7 at > BYU. I'll have it re-compile mzscheme only when the C code changes and > the byte-code always. Then I'll load each file (which will include the > tests, of course) and send blame to the most recent committer and the > owner (via plt:responsible) of the file. > > I'll have a web page that shows the success of each file's loading and > any messages spit out when it runs. At the beginning I can be testing > library agnostic if I can assume any output to stderr is an error. > > I think that will be a lot better than what we have now and then we > can experiment with better ways of communicating errors and coverage > to my setup. For example, Eli is referring to errortrace as if it is > the only option. I reckon if we just want to know whether some line of > a file has been run we could get by with less information than is > provided by errortrace. > > Anyways... that's my plan. Before I turn it live and you start getting > obnoxious emails, I'll get more permission. > > Jay > > -- > Jay McCarthy > Assistant Professor / Brigham Young University > http://teammccarthy.org/jay > > "The glory of God is Intelligence" - D&C 93 From robby at eecs.northwestern.edu Fri May 22 15:27:20 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Fri May 22 15:27:56 2009 Subject: [plt-dev] 4.2 release should go to plt-scheme for testing first? In-Reply-To: <9FCD949D-CC17-4145-98BA-987555396DA6@brinckerhoff.org> References: <932b2f1f0905221145x6ecdc9f9g81656458e0dbc1fc@mail.gmail.com> <24833B92-84E2-4F99-8C2E-49CE0C1A2359@brinckerhoff.org> <932b2f1f0905221204w340de0cdt794e0e8f1c3c0646@mail.gmail.com> <9FCD949D-CC17-4145-98BA-987555396DA6@brinckerhoff.org> Message-ID: <932b2f1f0905221227r167b12eaha3c4ebfc9a99e2f1@mail.gmail.com> On Fri, May 22, 2009 at 2:14 PM, John Clements wrote: > > On May 22, 2009, at 12:04 PM, Robby Findler wrote: > >> Are you quoting my message specifically for a reason? > > Honestly, the reason that your message prompted my response was that I just > fixed a bug in the stepper that I asked Eli to add to the release, and this > code clearly wasn't in the code that you tested. That makes me nervous. But I don't test the stepper...? >> And major version bumps are when things are least stable, not most stable! > > Yes, but I suspect that major version bumps are those that elicit the "ooh, > maybe I should try upgrading this thing!" response from casual users. Perhaps I'm just old now, but I usually refuse to upgrade until the small number is at least 2. :) Robby From carl.eastlund at gmail.com Fri May 22 15:28:14 2009 From: carl.eastlund at gmail.com (Carl Eastlund) Date: Fri May 22 15:28:32 2009 Subject: [plt-dev] slightly misleading error In-Reply-To: <81addec70905221223i36d3916eoacc5bc996808dd17@mail.gmail.com> References: <4A16F379.2020906@ccs.neu.edu> <4A16F5ED.9030708@ccs.neu.edu> <990e0c030905221205u721260cev714079cc37b66549@mail.gmail.com> <4A16F865.2090903@ccs.neu.edu> <81addec70905221223i36d3916eoacc5bc996808dd17@mail.gmail.com> Message-ID: <990e0c030905221228v58ac8e03jc5cfde67039ca5a8@mail.gmail.com> On Fri, May 22, 2009 at 3:23 PM, Anthony Cowley wrote: > On Fri, May 22, 2009 at 3:09 PM, Dave Herman wrote: >>> How about: >>> >>> "the dynamic context of this expression expected 1 value, but this >>> expression produced 2 values instead: a b" > > How about, "Expression produced 2 values, but the context exected 1." That doesn't include a printout of the 2 values in question, nor a particularly natural place to include them -- at the end of the sentence would be misleading (they're not the 1 value the context expected), and in the middle would break up the explanation if the values took multiple lines to print. -- Carl Eastlund From dvanhorn at ccs.neu.edu Fri May 22 15:30:14 2009 From: dvanhorn at ccs.neu.edu (David Van Horn) Date: Fri May 22 15:30:43 2009 Subject: [plt-dev] Pre-Release Checklist for v4.2 In-Reply-To: <18966.57631.734263.184874@winooski.ccs.neu.edu> References: <4A165C9D.9010207@cs.utah.edu> <18966.24323.528862.177055@winooski.ccs.neu.edu> <1601792B-91E7-440A-A941-38A30EE7E795@ccs.neu.edu> <18966.57631.734263.184874@winooski.ccs.neu.edu> Message-ID: <4A16FD46.2050004@ccs.neu.edu> Eli Barzilay wrote: > And BTW, these are two votes -- I expected many more people to say > something given how many people wanted to see this thing in. I think the srfi/1 module should be compatible with SRFI 1. The scheme/list version should do whatever the PLT consensus is. I like mandatory 2 arguments. David From carl.eastlund at gmail.com Fri May 22 15:34:26 2009 From: carl.eastlund at gmail.com (Carl Eastlund) Date: Fri May 22 15:34:48 2009 Subject: [plt-dev] Pre-Release Checklist for v4.2 In-Reply-To: <4A16FD46.2050004@ccs.neu.edu> References: <4A165C9D.9010207@cs.utah.edu> <18966.24323.528862.177055@winooski.ccs.neu.edu> <1601792B-91E7-440A-A941-38A30EE7E795@ccs.neu.edu> <18966.57631.734263.184874@winooski.ccs.neu.edu> <4A16FD46.2050004@ccs.neu.edu> Message-ID: <990e0c030905221234w4faeb410wba84cfd2afbf386@mail.gmail.com> On Fri, May 22, 2009 at 3:30 PM, David Van Horn wrote: > Eli Barzilay wrote: >> >> And BTW, these are two votes -- I expected many more people to say >> something given how many people wanted to see this thing in. > > I think the srfi/1 module should be compatible with SRFI 1. ?The scheme/list > version should do whatever the PLT consensus is. ?I like mandatory 2 > arguments. I agree -- srfi/1 should be compatible with SRFI 1, and I prefer a mandatory 2-argument make-list. If we only want to maintain one version of the function, I wouldn't object to re-exporting the srfi/1 version from scheme/list. I don't think we should make up a new version with a different default value, however. Having one that defaults to #f and another that defaults to 0, #, #, #, NIL, or anything else of the sort, would just be confusing. -- Carl Eastlund From acowley at seas.upenn.edu Fri May 22 15:35:14 2009 From: acowley at seas.upenn.edu (Anthony Cowley) Date: Fri May 22 15:35:40 2009 Subject: [plt-dev] slightly misleading error In-Reply-To: <990e0c030905221228v58ac8e03jc5cfde67039ca5a8@mail.gmail.com> References: <4A16F379.2020906@ccs.neu.edu> <4A16F5ED.9030708@ccs.neu.edu> <990e0c030905221205u721260cev714079cc37b66549@mail.gmail.com> <4A16F865.2090903@ccs.neu.edu> <81addec70905221223i36d3916eoacc5bc996808dd17@mail.gmail.com> <990e0c030905221228v58ac8e03jc5cfde67039ca5a8@mail.gmail.com> Message-ID: <81addec70905221235k3773189m667be4047363996a@mail.gmail.com> >> How about, "Expression produced 2 values, but the context exected 1." > > That doesn't include a printout of the 2 values in question, nor a > particularly natural place to include them -- at the end of the > sentence would be misleading (they're not the 1 value the context > expected), and in the middle would break up the explanation if the > values took multiple lines to print. Right, I left that out for the case when the expression source isn't available. If it is available, then it can be something like, "Expression (values 'a 'b) produced 2 values, but the context expected 1" But since the original complaint was the apparent disagreement between a visible highlighted expression and the apparent subject of the error sentence, I'm not even sure that printing the expression is so critical. If this were a command line compilation, then I expect an error message would be along the lines of, "Line 8, Column 7: Expression produced 2 values, but the context expected 1." Or, if the expression, when printed, is reasonably short, "Line 8, (values 'a 'b): Expression produced 2 values, but the context expected 1." Anthony From robby at eecs.northwestern.edu Fri May 22 15:31:13 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Fri May 22 15:36:38 2009 Subject: [plt-dev] lessons learned In-Reply-To: References: <46b603df0905220922o188c86a6w3294733306aa4f3@mail.gmail.com> <2C59DF07-6DB5-4C8E-9E80-CCEC3183A62F@ccs.neu.edu> Message-ID: <932b2f1f0905221231u51ff19a4i8244c057c5558c07@mail.gmail.com> That sounds great! You will find that nearly all test suites print something, tho. I'm sure it won't be hard to change them to be mroe kind to a simple predicate like that, tho. I like the idea of loading each file to see if it just runs without input (esp. now that we have a real bug that it would have caught). Are we worried about external effects here, tho? Also, I recently sped up test-coverage in the teaching languages by a large factor -- this speedup assumes that the code is only run in a single thread, which seems like a fine approximation for this job; perhaps something to think about eventually including? Robby On Fri, May 22, 2009 at 2:26 PM, Matthias Felleisen wrote: > > I like your idea a lot. (I am sure you realize that some files need to be > loaded in mred.) Keep us posted about the progress -- Matthias > > > > > On May 22, 2009, at 3:09 PM, Jay McCarthy wrote: > >> On Fri, May 22, 2009 at 2:02 PM, Matthias Felleisen >> wrote: >>> >>> The one thing I'd like to add to Eli's nightly build is some way of just >>> evaluating each file once. Period. If it doesn't load, send a message and >>> nag. Just like for the test cases. (I do have a separate test suite for >>> /htdp and /2htdp, but they aren't automated.) >> >> It seems like Eli's build is doing two things: producing the binaries >> for download and doing the automated tests linked in tests/. It makes >> sense to the first only nightly, but the second every commit. >> >> I can buy a machine and have it do the testing part basically 24/7 at >> BYU. I'll have it re-compile mzscheme only when the C code changes and >> the byte-code always. Then I'll load each file (which will include the >> tests, of course) and send blame to the most recent committer and the >> owner (via plt:responsible) of the file. >> >> I'll have a web page that shows the success of each file's loading and >> any messages spit out when it runs. At the beginning I can be testing >> library agnostic if I can assume any output to stderr is an error. >> >> I think that will be a lot better than what we have now and then we >> can experiment with better ways of communicating errors and coverage >> to my setup. For example, Eli is referring to errortrace as if it is >> the only option. I reckon if we just want to know whether some line of >> a file has been run we could get by with less information than is >> provided by errortrace. >> >> Anyways... that's my plan. Before I turn it live and you start getting >> obnoxious emails, I'll get more permission. >> >> Jay >> >> -- >> Jay McCarthy >> Assistant Professor / Brigham Young University >> http://teammccarthy.org/jay >> >> "The glory of God is Intelligence" - D&C 93 > > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > From carl.eastlund at gmail.com Fri May 22 15:38:29 2009 From: carl.eastlund at gmail.com (Carl Eastlund) Date: Fri May 22 15:45:23 2009 Subject: [plt-dev] slightly misleading error In-Reply-To: <81addec70905221235k3773189m667be4047363996a@mail.gmail.com> References: <4A16F379.2020906@ccs.neu.edu> <4A16F5ED.9030708@ccs.neu.edu> <990e0c030905221205u721260cev714079cc37b66549@mail.gmail.com> <4A16F865.2090903@ccs.neu.edu> <81addec70905221223i36d3916eoacc5bc996808dd17@mail.gmail.com> <990e0c030905221228v58ac8e03jc5cfde67039ca5a8@mail.gmail.com> <81addec70905221235k3773189m667be4047363996a@mail.gmail.com> Message-ID: <990e0c030905221238p49070ab2jbfb0233775289f39@mail.gmail.com> On Fri, May 22, 2009 at 3:35 PM, Anthony Cowley wrote: >>> How about, "Expression produced 2 values, but the context exected 1." >> >> That doesn't include a printout of the 2 values in question, nor a >> particularly natural place to include them -- at the end of the >> sentence would be misleading (they're not the 1 value the context >> expected), and in the middle would break up the explanation if the >> values took multiple lines to print. > > Right, I left that out for the case when the expression source isn't > available. If it is available, then it can be something like, > > "Expression (values 'a 'b) produced 2 values, but the context expected 1" > > But since the original complaint was the apparent disagreement between > a visible highlighted expression and the apparent subject of the error > sentence, I'm not even sure that printing the expression is so > critical. If this were a command line compilation, then I expect an > error message would be along the lines of, > > "Line 8, Column 7: Expression produced 2 values, but the context expected 1." > > Or, if the expression, when printed, is reasonably short, > > "Line 8, (values 'a 'b): Expression produced 2 values, but the context > expected 1." > > Anthony Error messages do not usually print out code; they print out dynamic values. The values don't change based on source locations, code expansion, compilation, or anything like that. -- Carl Eastlund From grettke at acm.org Fri May 22 15:47:43 2009 From: grettke at acm.org (Grant Rettke) Date: Fri May 22 15:48:01 2009 Subject: [plt-dev] lessons learned In-Reply-To: <46b603df0905221039i4ff422edvc53348d98231bb83@mail.gmail.com> References: <46b603df0905220922o188c86a6w3294733306aa4f3@mail.gmail.com> <2C59DF07-6DB5-4C8E-9E80-CCEC3183A62F@ccs.neu.edu> <60C72A01-5436-4C32-89B4-F46479D73B0E@brinckerhoff.org> <18966.55873.885474.894204@winooski.ccs.neu.edu> <46b603df0905221003gc88f2d5t50eca5a39c2f4769@mail.gmail.com> <18966.56318.62898.672069@winooski.ccs.neu.edu> <46b603df0905221039i4ff422edvc53348d98231bb83@mail.gmail.com> Message-ID: <756daca50905221247j42372c4ch5563f813f194f76a@mail.gmail.com> On Fri, May 22, 2009 at 12:39 PM, Jacob Matthews wrote: > (Part of my current job is to advocate good testing practices and help > other teams set up good testing infrastructure for their projects, so > if I come off like an evangelist, that's why. :) ) What is your job? From grettke at acm.org Fri May 22 15:52:33 2009 From: grettke at acm.org (Grant Rettke) Date: Fri May 22 15:52:54 2009 Subject: [plt-dev] lessons learned In-Reply-To: References: <46b603df0905220922o188c86a6w3294733306aa4f3@mail.gmail.com> <2C59DF07-6DB5-4C8E-9E80-CCEC3183A62F@ccs.neu.edu> Message-ID: <756daca50905221252m1943e8b7v9316a91504231ecd@mail.gmail.com> On Fri, May 22, 2009 at 2:09 PM, Jay McCarthy wrote: > On Fri, May 22, 2009 at 2:02 PM, Matthias Felleisen > It seems like Eli's build is doing two things: producing the binaries > for download and doing the automated tests linked in tests/. It makes > sense to the first only nightly, but the second every commit. However your testing pans out, it might be interesting if it were reusable, perhaps with something like Sake: http://planet.plt-scheme.org/package-source/schematics/sake.plt/1/0/planet-docs/sake/Introduction.html From dvanhorn at ccs.neu.edu Fri May 22 15:54:16 2009 From: dvanhorn at ccs.neu.edu (David Van Horn) Date: Fri May 22 15:54:59 2009 Subject: [plt-dev] Pre-Release Checklist for v4.2 In-Reply-To: <4A16FD46.2050004@ccs.neu.edu> References: <4A165C9D.9010207@cs.utah.edu> <18966.24323.528862.177055@winooski.ccs.neu.edu> <1601792B-91E7-440A-A941-38A30EE7E795@ccs.neu.edu> <18966.57631.734263.184874@winooski.ccs.neu.edu> <4A16FD46.2050004@ccs.neu.edu> Message-ID: <4A1702E8.9090705@ccs.neu.edu> By the way, I just downloaded and installed 4.1.900-svn21may2009. When I look at the docs for make-list, I see: Examples: > (make-list 7 'foo) reference to undefined identifier: make-list David From clements at brinckerhoff.org Fri May 22 15:54:23 2009 From: clements at brinckerhoff.org (John Clements) Date: Fri May 22 15:55:08 2009 Subject: [plt-dev] 4.2 release should go to plt-scheme for testing first? In-Reply-To: <932b2f1f0905221227r167b12eaha3c4ebfc9a99e2f1@mail.gmail.com> References: <932b2f1f0905221145x6ecdc9f9g81656458e0dbc1fc@mail.gmail.com> <24833B92-84E2-4F99-8C2E-49CE0C1A2359@brinckerhoff.org> <932b2f1f0905221204w340de0cdt794e0e8f1c3c0646@mail.gmail.com> <9FCD949D-CC17-4145-98BA-987555396DA6@brinckerhoff.org> <932b2f1f0905221227r167b12eaha3c4ebfc9a99e2f1@mail.gmail.com> Message-ID: <5116FD70-1534-4797-9510-0F5D5A3A8954@brinckerhoff.org> On May 22, 2009, at 12:27 PM, Robby Findler wrote: > On Fri, May 22, 2009 at 2:14 PM, John Clements > wrote: >> >> On May 22, 2009, at 12:04 PM, Robby Findler wrote: >> >>> Are you quoting my message specifically for a reason? >> >> Honestly, the reason that your message prompted my response was >> that I just >> fixed a bug in the stepper that I asked Eli to add to the release, >> and this >> code clearly wasn't in the code that you tested. That makes me >> nervous. > > But I don't test the stepper...? True. >>> And major version bumps are when things are least stable, not most >>> stable! >> >> Yes, but I suspect that major version bumps are those that elicit >> the "ooh, >> maybe I should try upgrading this thing!" response from casual users. > > Perhaps I'm just old now, but I usually refuse to upgrade until the > small number is at least 2. :) Yep. If no one else is concerned, I don't have a problem. John -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2484 bytes Desc: not available Url : http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090522/034352d2/smime.bin From dherman at ccs.neu.edu Fri May 22 16:03:28 2009 From: dherman at ccs.neu.edu (Dave Herman) Date: Fri May 22 16:04:00 2009 Subject: [plt-dev] lessons learned In-Reply-To: <756daca50905221247j42372c4ch5563f813f194f76a@mail.gmail.com> References: <46b603df0905220922o188c86a6w3294733306aa4f3@mail.gmail.com> <2C59DF07-6DB5-4C8E-9E80-CCEC3183A62F@ccs.neu.edu> <60C72A01-5436-4C32-89B4-F46479D73B0E@brinckerhoff.org> <18966.55873.885474.894204@winooski.ccs.neu.edu> <46b603df0905221003gc88f2d5t50eca5a39c2f4769@mail.gmail.com> <18966.56318.62898.672069@winooski.ccs.neu.edu> <46b603df0905221039i4ff422edvc53348d98231bb83@mail.gmail.com> <756daca50905221247j42372c4ch5563f813f194f76a@mail.gmail.com> Message-ID: <4A170510.9000209@ccs.neu.edu> > What is your job? This is off-topic. Please keep the conversation private. Dave From grettke at acm.org Fri May 22 16:05:17 2009 From: grettke at acm.org (Grant Rettke) Date: Fri May 22 16:05:45 2009 Subject: [plt-dev] lessons learned In-Reply-To: <4A170510.9000209@ccs.neu.edu> References: <2C59DF07-6DB5-4C8E-9E80-CCEC3183A62F@ccs.neu.edu> <60C72A01-5436-4C32-89B4-F46479D73B0E@brinckerhoff.org> <18966.55873.885474.894204@winooski.ccs.neu.edu> <46b603df0905221003gc88f2d5t50eca5a39c2f4769@mail.gmail.com> <18966.56318.62898.672069@winooski.ccs.neu.edu> <46b603df0905221039i4ff422edvc53348d98231bb83@mail.gmail.com> <756daca50905221247j42372c4ch5563f813f194f76a@mail.gmail.com> <4A170510.9000209@ccs.neu.edu> Message-ID: <756daca50905221305w3a828ad6k861f1a26ac5a9cbe@mail.gmail.com> On Fri, May 22, 2009 at 3:03 PM, Dave Herman wrote: >> What is your job? > > This is off-topic. Please keep the conversation private. Sorry about that I hit reply-all and regretted it. From acowley at seas.upenn.edu Fri May 22 16:06:02 2009 From: acowley at seas.upenn.edu (Anthony Cowley) Date: Fri May 22 16:06:22 2009 Subject: [plt-dev] slightly misleading error In-Reply-To: <990e0c030905221238p49070ab2jbfb0233775289f39@mail.gmail.com> References: <4A16F379.2020906@ccs.neu.edu> <4A16F5ED.9030708@ccs.neu.edu> <990e0c030905221205u721260cev714079cc37b66549@mail.gmail.com> <4A16F865.2090903@ccs.neu.edu> <81addec70905221223i36d3916eoacc5bc996808dd17@mail.gmail.com> <990e0c030905221228v58ac8e03jc5cfde67039ca5a8@mail.gmail.com> <81addec70905221235k3773189m667be4047363996a@mail.gmail.com> <990e0c030905221238p49070ab2jbfb0233775289f39@mail.gmail.com> Message-ID: <81addec70905221306u1e7d2dcfqf84382e417a4b9ca@mail.gmail.com> >> "Line 8, Column 7: Expression produced 2 values, but the context expected 1." >> >> Or, if the expression, when printed, is reasonably short, >> >> "Line 8, (values 'a 'b): Expression produced 2 values, but the context >> expected 1." >> >> Anthony > > Error messages do not usually print out code; they print out dynamic > values. ?The values don't change based on source locations, code > expansion, compilation, or anything like that. Fair enough, I guess I'm used to that from GHC, or the backtrace from a Lisp, or GCC telling one the line number and target of a bad arity function call rather than just showing the given arguments. But even if PLT error messages only show dynamic values, the dynamic values don't seem as important as the expression that generated them so I don't think it's worth having a confusing error message to highlight them if it's at all possible to obtain some information about the expression that generated them. If it's not, then, as you suggested, the current message that shows the given values probably is the best. Anthony From robby at eecs.northwestern.edu Fri May 22 16:07:07 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Fri May 22 16:07:27 2009 Subject: [plt-dev] 4.2 release should go to plt-scheme for testing first? In-Reply-To: <5116FD70-1534-4797-9510-0F5D5A3A8954@brinckerhoff.org> References: <932b2f1f0905221145x6ecdc9f9g81656458e0dbc1fc@mail.gmail.com> <24833B92-84E2-4F99-8C2E-49CE0C1A2359@brinckerhoff.org> <932b2f1f0905221204w340de0cdt794e0e8f1c3c0646@mail.gmail.com> <9FCD949D-CC17-4145-98BA-987555396DA6@brinckerhoff.org> <932b2f1f0905221227r167b12eaha3c4ebfc9a99e2f1@mail.gmail.com> <5116FD70-1534-4797-9510-0F5D5A3A8954@brinckerhoff.org> Message-ID: <932b2f1f0905221307j26f4a86ey7bc1144e8b759e92@mail.gmail.com> FWIW, I don't think we should delay the release, but instead just release with a note that there were major low-level changes, so users should expect more bugs than usual. Robby On Fri, May 22, 2009 at 2:54 PM, John Clements wrote: > > On May 22, 2009, at 12:27 PM, Robby Findler wrote: > >> On Fri, May 22, 2009 at 2:14 PM, John Clements >> wrote: >>> >>> On May 22, 2009, at 12:04 PM, Robby Findler wrote: >>> >>>> Are you quoting my message specifically for a reason? >>> >>> Honestly, the reason that your message prompted my response was that I >>> just >>> fixed a bug in the stepper that I asked Eli to add to the release, and >>> this >>> code clearly wasn't in the code that you tested. That makes me nervous. >> >> But I don't test the stepper...? > > True. > >>>> And major version bumps are when things are least stable, not most >>>> stable! >>> >>> Yes, but I suspect that major version bumps are those that elicit the >>> "ooh, >>> maybe I should try upgrading this thing!" response from casual users. >> >> Perhaps I'm just old now, but I usually refuse to upgrade until the >> small number is at least 2. :) > > Yep. > > If no one else is concerned, I don't have a problem. > > John > > From dvanhorn at ccs.neu.edu Fri May 22 16:23:44 2009 From: dvanhorn at ccs.neu.edu (David Van Horn) Date: Fri May 22 16:24:14 2009 Subject: [plt-dev] DrScheme definitions crash in pre-release Message-ID: <4A1709D0.90600@ccs.neu.edu> I can consistently put DrScheme in a bad state by the following: 1) Open a fairly large file (so syntax checking takes time) 2) Make a change 3) click Check Syntax 4) click Save -- before checking is complete. It seems as soon as syntax checking completes, an internal error is signalled. The error varies, but it always occurs. Here are a couple: 1) sequence-contract-violation: negative: method delete cannot be called, except in states (unlocked), args 0 360 === context === /Applications/PLT Scheme Full v4.1.900/collects/drscheme/private/unit.ss:529:10: after-save-file method in ...heme/private/unit.ss:454:8 /Applications/PLT Scheme Full v4.1.900/collects/drscheme/private/unit.ss:3884:29 /Applications/PLT Scheme Full v4.1.900/collects/scheme/private/more-scheme.ss:155:2: call-with-break-parameterization /Applications/PLT Scheme Full v4.1.900/collects/scheme/private/more-scheme.ss:271:2: call-with-exception-handler 2) hash-ref: expects type as 1st argument, given: #f; other arguments were: #(struct:object:...engine/test-tool.scm:30:6 ...) # === context === /Applications/PLT Scheme Full v4.1.900/collects/drscheme/syncheck.ss:414:12: syncheck:add-menu method in ...drscheme/syncheck.ss:221:10 /Applications/PLT Scheme Full v4.1.900/collects/scheme/private/map.ss:44:11: for-each /Applications/PLT Scheme Full v4.1.900/collects/drscheme/syncheck.ss:1671:22: at-phase /Applications/PLT Scheme Full v4.1.900/collects/scheme/private/map.ss:44:11: for-each /Applications/PLT Scheme Full v4.1.900/collects/scheme/private/map.ss:44:11: for-each /Applications/PLT Scheme Full v4.1.900/collects/drscheme/syncheck.ss:1489:4: annotate-basic /Applications/PLT Scheme Full v4.1.900/collects/drscheme/syncheck.ss:1413:14: expanded-expression /Applications/PLT Scheme Full v4.1.900/collects/drscheme/syncheck.ss:1247:38 /Applications/PLT Scheme Full v4.1.900/collects/drscheme/syncheck.ss:1244:35 After this, the definitions window is broken. I cannot reposition the cursor, type text, etc. I can click Save but it doesn't go away. Run and the interactions window work fine. This is on 4.1.900-svn21may2009 [3m], Mac OSX, ISL/lambda. Should I be submitting bug reports, or emailing this list since this concerns the release candidate? David From eli at barzilay.org Fri May 22 18:22:06 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri May 22 18:22:28 2009 Subject: [plt-dev] lessons learned In-Reply-To: References: <46b603df0905220922o188c86a6w3294733306aa4f3@mail.gmail.com> <2C59DF07-6DB5-4C8E-9E80-CCEC3183A62F@ccs.neu.edu> Message-ID: <18967.9614.600560.265244@winooski.ccs.neu.edu> Some items to consider (in mostly random order): * [Disclaimer: there are many items here -- that is not an indication that I'm objecting to this, but the exact opposite. I'm not trying to pile up difficulties, instead, I'm trying to list things that you need to be aware of -- and maybe it'll make it more practical to make this happen.] * As a general warning, you should plan on spending a significant amount of time on maintaining this thing -- by its nature it's close to things like the build script or the release procedure -- and I find that these things are very unstable in the sense that I'm often updating things. (Not unstable because the code is bad, but because the project moves.) For example, the big commit when Matthew pushed the 4.0 world in left a lot of files in bad state and it took a while for things to settle -- you'll need to be prepared to tweak things at such times. * While nagging the responsible parties is good in general, you need to avoid overdoing it -- for example, if that 4.0 jump leaves a large number of files in a bad state which will take you a while to fix, you'll eventually start ignoring the incoming nag messages. * Getting plt:responsible to actually work will be nice, but probably will be inconvenient enough that it will still be undermaintained. Perhaps it's best to have some heuristic assign ownership to existing files, and make the ownership go to whoever adds new files. By "existing files" I mean stuff that existed when the svn was made. (It will need to ignore the first ~5 revisions, where I set the repository up.) * Also, be prepared for disappointments -- like investing time in getting those per-file pages up with all the relevant info but having noone ever use them. (That's also very much like the build stuff...) * Some meta-data should be helpful -- since some files are not meant to run, and there are several reasons that can lead to this. I'm not sure what's the best way to put this data but svn properties might not be best because they're lost when it goes out of svn. * Assumptions like "any output to stderr is an error" are very bad, even an assumption like "an exception is a testing error" is not always true. It'll be challenging to figure it out -- meta data can help, but you don't want to overdo it by making it verbose enough that nobody will actually do so. (This is almost a guaranteed way of finding yourself doing it for everyone...) * You will need to sandbox it somehow. It's probably most convenient to make it run from a dedicated username -- and obviously having a dedicated machine covers that. But you'll need to take care of some OS restrictions so that the machine doesn't crash when running out of memory, while still keeping a hard memory limit (since running inside a scheme sandbox is not always practical.) * The platform should probably be linux, to be able to run mred remotely. Again, if it's a dedicated box it can be Windows or OSX with some screen controlling utility, but linux is still more flexible, I think. * That said, there are differences between the different platforms -- especially in mred, but also in other files, so ideally the setup would run on three machines running the three platforms. It might be possible to get this with VM or something, but it can be difficult to set it up. * Some files can have side-effects that conflict other files. The brute force solution is to run each file in a new process -- and that might be feasible if the machine is doing just this, all the time. OTOH, some files might require loading other files, so solving this will be difficult. * This also goes for running stuff in mred or mzscheme. The simple solution is to run everything in mred, but that's also more expensive (especially with one process per file). You might be able to use the dependencies to know when a file requires mred. * It's a good idea to combine loading the files and running the tests in this process. * It will be nice to have a big queue of files to try, so whenever a file is modified (or a new one is made) it is moved up to the beginning. When the queue is done, reinitizlize from all. You can trigger a modification "event" by the notification emails, or I can set up something in the commit hook. * Assigning blame using plt:responsible might be tricky -- what if A's test file fails because it depends on B's files, which depends on C's file which D changed? The ideal of having everything go smoothely so there's always a known blame (the recent comitter) is never going to happen -- some files will have had failures from before, and some blame is actually reversed. For example, D's change might be fully justified because it's a fix to an unrelated problem, but that exposed a problem in B's code. Another example is the a major version switch -- where lots of code breaks "by design". * Running setup-plt after every commit is usually fine, but in some cases it might be an issue. As an approximation, running `make' on the existing build directory is good when any C file changes, and running setup-plt when other files change -- but in addition, you'll want to clear things up when the version changes. Also, it will be good to periodically (daily or weekly, maybe?) remove everything and start from a fresh checkout. * I wasn't referring to errortrace's capability of tracking the stack, but the coverage collection tool which is included in it. I don't think that there are much cheaper alternatives to annotating code, so if you do want to test coverage, you'll need a high cpu price either way you go. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From clements at brinckerhoff.org Fri May 22 18:33:30 2009 From: clements at brinckerhoff.org (John Clements) Date: Fri May 22 18:33:57 2009 Subject: [plt-dev] Fix for a test-engine bug Message-ID: <03D0332C-3756-4DA8-885E-3354D45B73C3@brinckerhoff.org> In the release candidate, this program: #lang scheme (require test-engine/scheme-tests) (test) ... causes this error: send: no such method: display-untested-summary for class: test-display- textual% In fact, it turns out that test-display-textual% does have these methods, it's just that they're not public. Revision 14946 fixes this. Here's the diff: pcp063219pcs:~/plt/collects/test-engine clements$ svn diff -r 14945:14946 test-engine.scm Index: test-engine.scm =================================================================== --- test-engine.scm (revision 14945) +++ test-engine.scm (revision 14946) @@ -87,11 +87,11 @@ [else (format "All ~a" count)]) (if (= count 1) "" "s")))) - (define (display-untested-summary port) + (define/public (display-untested-summary port) (unless (test-silence) (fprintf port "This program should be tested.~n"))) - (define (display-disabled-summary port) + (define/public (display-disabled-summary port) (fprintf port "Tests disabled.\n")) (define/public (next-line) (printf "~a" "\n\t")) pcp063219pcs:~/plt/collects/test-engine clements$ I think this should go in the release. John -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2484 bytes Desc: not available Url : http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090522/a8fde7cf/smime.bin From carl.eastlund at gmail.com Fri May 22 18:38:58 2009 From: carl.eastlund at gmail.com (Carl Eastlund) Date: Fri May 22 18:39:16 2009 Subject: [plt-dev] lessons learned In-Reply-To: <18967.9614.600560.265244@winooski.ccs.neu.edu> References: <46b603df0905220922o188c86a6w3294733306aa4f3@mail.gmail.com> <2C59DF07-6DB5-4C8E-9E80-CCEC3183A62F@ccs.neu.edu> <18967.9614.600560.265244@winooski.ccs.neu.edu> Message-ID: <990e0c030905221538rb835856of99ec10ce5acb0fc@mail.gmail.com> On Fri, May 22, 2009 at 6:22 PM, Eli Barzilay wrote: > * Running setup-plt after every commit is usually fine, but in some > ?cases it might be an issue. ?As an approximation, running `make' on > ?the existing build directory is good when any C file changes, and > ?running setup-plt when other files change -- but in addition, you'll > ?want to clear things up when the version changes. ?Also, it will be > ?good to periodically (daily or weekly, maybe?) remove everything and > ?start from a fresh checkout. This is a good point, though I suggest going even farther. Unless it is completely infeasible, if we want to be able to trust that reported errors arise from the associated revision number, each build should be a fresh checkout, and all cached planet / scribble build information (the stuff that lives in ~/Library/PLT Scheme/ on Macs, elsewhere on other platforms) should be removed. Of course, that "completely infeasible" might shoot this suggestion down. -- Carl Eastlund From eli at barzilay.org Fri May 22 18:39:54 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri May 22 18:40:21 2009 Subject: [plt-dev] Fix for a test-engine bug In-Reply-To: <03D0332C-3756-4DA8-885E-3354D45B73C3@brinckerhoff.org> References: <03D0332C-3756-4DA8-885E-3354D45B73C3@brinckerhoff.org> Message-ID: <18967.10682.794274.145347@winooski.ccs.neu.edu> I've ran into the same problem trying to make it run in the sandbox, and I think that I tried a very similar solution. My conclusion was that it's best left for Kathy to fix... On May 22, John Clements wrote: > In the release candidate, this program: > > #lang scheme > > (require test-engine/scheme-tests) > > (test) > > > ... causes this error: > > send: no such method: display-untested-summary for class: test-display- > textual% > > In fact, it turns out that test-display-textual% does have these > methods, it's just that they're not public. > > Revision 14946 fixes this. Here's the diff: > > pcp063219pcs:~/plt/collects/test-engine clements$ svn diff -r > 14945:14946 test-engine.scm > Index: test-engine.scm > =================================================================== > --- test-engine.scm (revision 14945) > +++ test-engine.scm (revision 14946) > @@ -87,11 +87,11 @@ > [else (format "All ~a" count)]) > (if (= count 1) "" "s")))) > > - (define (display-untested-summary port) > + (define/public (display-untested-summary port) > (unless (test-silence) > (fprintf port "This program should be tested.~n"))) > > - (define (display-disabled-summary port) > + (define/public (display-disabled-summary port) > (fprintf port "Tests disabled.\n")) > > (define/public (next-line) (printf "~a" "\n\t")) > pcp063219pcs:~/plt/collects/test-engine clements$ > > > I think this should go in the release. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From eli at barzilay.org Fri May 22 18:48:18 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri May 22 18:48:38 2009 Subject: [plt-dev] lessons learned In-Reply-To: <990e0c030905221538rb835856of99ec10ce5acb0fc@mail.gmail.com> References: <46b603df0905220922o188c86a6w3294733306aa4f3@mail.gmail.com> <2C59DF07-6DB5-4C8E-9E80-CCEC3183A62F@ccs.neu.edu> <18967.9614.600560.265244@winooski.ccs.neu.edu> <990e0c030905221538rb835856of99ec10ce5acb0fc@mail.gmail.com> Message-ID: <18967.11186.192083.888361@winooski.ccs.neu.edu> On May 22, Carl Eastlund wrote: > On Fri, May 22, 2009 at 6:22 PM, Eli Barzilay wrote: > > * Running setup-plt after every commit is usually fine, but in some > > ?cases it might be an issue. ?As an approximation, running `make' > > ?on the existing build directory is good when any C file changes, > > ?and running setup-plt when other files change -- but in addition, > > ?you'll want to clear things up when the version changes. ?Also, > > ?it will be good to periodically (daily or weekly, maybe?) remove > > ?everything and start from a fresh checkout. > > This is a good point, though I suggest going even farther. Unless > it is completely infeasible, if we want to be able to trust that > reported errors arise from the associated revision number, each > build should be a fresh checkout, and all cached planet / scribble > build information (the stuff that lives in ~/Library/PLT Scheme/ on > Macs, elsewhere on other platforms) should be removed. > > Of course, that "completely infeasible" might shoot this suggestion > down. It's not *completely* infeasible... Currently, a full from-scratch build on winooski takes about 20 minutes. But if you want *each* revision checked, then you'll want to start a build for every revision N that arrived during the build, which means that it's easy to build up a significant backlog. That's still fine (since the beginning of svn we have about 8 commits per day) -- but that doesn't include testing -- and if testing means loading all files in the repository, then that can become infeasible. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From eli at barzilay.org Sat May 23 03:36:08 2009 From: eli at barzilay.org (Eli Barzilay) Date: Sat May 23 03:36:32 2009 Subject: [plt-dev] Pre-Release Checklist for v4.2 In-Reply-To: <4A1702E8.9090705@ccs.neu.edu> References: <4A165C9D.9010207@cs.utah.edu> <18966.24323.528862.177055@winooski.ccs.neu.edu> <1601792B-91E7-440A-A941-38A30EE7E795@ccs.neu.edu> <18966.57631.734263.184874@winooski.ccs.neu.edu> <4A16FD46.2050004@ccs.neu.edu> <4A1702E8.9090705@ccs.neu.edu> Message-ID: <18967.42856.685456.499261@winooski.ccs.neu.edu> On May 22, David Van Horn wrote: > By the way, I just downloaded and installed 4.1.900-svn21may2009. When > I look at the docs for make-list, I see: > > Examples: > > (make-list 7 'foo) > reference to undefined identifier: make-list Thanks -- this should be fixed now. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From eli at barzilay.org Sat May 23 04:07:18 2009 From: eli at barzilay.org (Eli Barzilay) Date: Sat May 23 04:07:55 2009 Subject: [plt-dev] Pre-Release Checklist for v4.2 In-Reply-To: <20090522184353.0423965008D@mail-svr1.cs.utah.edu> References: <4A165C9D.9010207@cs.utah.edu> <18966.24323.528862.177055@winooski.ccs.neu.edu> <1601792B-91E7-440A-A941-38A30EE7E795@ccs.neu.edu> <18966.57549.784132.161225@winooski.ccs.neu.edu> <20090522184353.0423965008D@mail-svr1.cs.utah.edu> Message-ID: <18967.44726.198339.928297@winooski.ccs.neu.edu> OK, I committed this change, and will merge to 4.2. One (smaller) problem stays: since scheme/list and srfi/1 are incompatible, requiring both needs some manual filtering because of this change. (But it required thse anyway because of other impossible to unify bindings like `map' and `for-each'.) On May 22, Matthew Flatt wrote: > I think just the `srfi/1' implementation should change, and #f seems > like a fine default --- useless, but compatible. > > At Fri, 22 May 2009 13:28:45 -0400, Eli Barzilay wrote: > > The problem is that this leaves us with an incompatible srfi/1 (which > > is why I wrote the second option). (BTW, I wouldn't mind such > > incompatibility, but I don't care about `make-list' anyway.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From thomas at deniau.org Sat May 23 05:13:12 2009 From: thomas at deniau.org (Thomas Deniau) Date: Sat May 23 05:13:36 2009 Subject: [plt-dev] Installation directories on Mac OS X In-Reply-To: References: Message-ID: On 21 mai 09, at 21:42, Thomas Deniau wrote: > in the ./configure help, enable_xonx is documented as concerning > MrEd only. I agree that problems may occur of unixstyle is enabled > and MrEd is built (frameworks, ...), but why should unixstyle be > disabled if MrEd isn't being built ? > > I did some quick tests with enable_origtree=no in the "Darwin" > clause, and everything still seems to work (and the install > locations are cleaner, with everything in the right subdirectories). Since I didn't get any answer from the list, I assume it is OK to submit the new port to MacPorts with unixstyle=yes (and origtree=no) on OS X (without MrEd) ? Thanks -- Thomas Deniau -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2417 bytes Desc: not available Url : http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090523/f5bb2039/smime.bin From matthias at ccs.neu.edu Sat May 23 08:51:56 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Sat May 23 08:59:47 2009 Subject: [plt-dev] Installation directories on Mac OS X In-Reply-To: References: Message-ID: <143A246B-E9A1-4700-BD63-4C1BDB1B65EF@ccs.neu.edu> On May 23, 2009, at 5:13 AM, Thomas Deniau wrote: > On 21 mai 09, at 21:42, Thomas Deniau wrote: > >> in the ./configure help, enable_xonx is documented as concerning >> MrEd only. I agree that problems may occur of unixstyle is enabled >> and MrEd is built (frameworks, ...), but why should unixstyle be >> disabled if MrEd isn't being built ? >> >> I did some quick tests with enable_origtree=no in the "Darwin" >> clause, and everything still seems to work (and the install >> locations are cleaner, with everything in the right subdirectories). > > Since I didn't get any answer from the list, I assume it is OK to > submit the new port to MacPorts with unixstyle=yes (and > origtree=no) on OS X (without MrEd) ? Go for it. -- Matthias From thomas at deniau.org Sat May 23 09:26:19 2009 From: thomas at deniau.org (Thomas Deniau) Date: Sat May 23 09:26:43 2009 Subject: [plt-dev] Installation directories on Mac OS X In-Reply-To: <143A246B-E9A1-4700-BD63-4C1BDB1B65EF@ccs.neu.edu> References: <143A246B-E9A1-4700-BD63-4C1BDB1B65EF@ccs.neu.edu> Message-ID: <53AA5419-F010-4CE1-9DF0-D4992546F6FE@deniau.org> On 23 mai 09, at 14:51, Matthias Felleisen wrote: > Go for it. -- Matthias Done ( http://trac.macports.org/attachment/ticket/19738/mzscheme.diff ). You might be interested in including this patch to unixstyle.ss upstream : --- ../collects/setup/unixstyle-install.ss.orig 2009-05-21 20:37:16.000000000 +0200 +++ ../collects/setup/unixstyle-install.ss 2009-05-21 20:36:39.000000000 +0200 @@ -179,7 +179,7 @@ (regexp-replace* #rx"[\"`'$\\]" (dir: 'bin) "\\\ \&")) (write-bytes buf (current-output-port) (cdadr m)))))) (let ([magic (with-input-from-file file (lambda () (read-bytes 10)))]) - (cond [(regexp-match #rx#"^\177ELF" magic) + (cond [(or (regexp-match #rx#"^\177ELF" magic) (regexp-match #rx#"^\316\372\355\376" magic)) (let ([temp (format "~a-temp-for-install" (regexp-replace* #rx"/" file "_"))]) (with-handlers ([exn? (lambda (e) (delete-file temp) (raise e))]) it adds detection of the Mach-O magic number to the fix-binary code and is needed when you enable unixstyle on Mac OS. Additionally, I changed some -I into -iquote's in the Makefile.in's : since the previous version of the port installed its headers files directly into include/ instead of include/plt/, the installed headers conflicted with the ones in the source distribution. This shouldn't do any harm unless you're not compiling with GCC. -- Thomas Deniau -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2417 bytes Desc: not available Url : http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090523/51c6e7e0/smime.bin From mflatt at cs.utah.edu Sat May 23 10:01:52 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Sat May 23 10:02:13 2009 Subject: [plt-dev] Installation directories on Mac OS X In-Reply-To: <53AA5419-F010-4CE1-9DF0-D4992546F6FE@deniau.org> References: <143A246B-E9A1-4700-BD63-4C1BDB1B65EF@ccs.neu.edu> <53AA5419-F010-4CE1-9DF0-D4992546F6FE@deniau.org> Message-ID: <20090523140153.D6DF36500A2@mail-svr1.cs.utah.edu> At Sat, 23 May 2009 15:26:19 +0200, Thomas Deniau wrote: > You might be interested in including this patch to unixstyle.ss > upstream : Thanks! I somehow missed your original message. (Maybe I accidentally deleted it before reading), but I see in the archives: Are there deeper reasons that would force origtree to yes on OS X even without MrEd ? We don't want the default MzScheme build to be different from the default Mred build, since the former is supposed to be a subset of the latter. Longer term, we should look at making MrEd work within a Unix-style installation. With your patch, maybe it's just a matter of putting ".app"s in an appropriate place. > Additionally, I changed some -I into -iquote's in the Makefile.in's : > since the previous version of the port installed its headers files > directly into include/ instead of include/plt/, the installed headers > conflicted with the ones in the source distribution. This shouldn't do > any harm unless you're not compiling with GCC. We've addressed this problem in the latest build by putting the local `-I's first, so they'll take precedence. From robby at eecs.northwestern.edu Sat May 23 11:57:35 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Sat May 23 11:57:58 2009 Subject: [plt-dev] DrScheme definitions crash in pre-release In-Reply-To: <4A1709D0.90600@ccs.neu.edu> References: <4A1709D0.90600@ccs.neu.edu> Message-ID: <932b2f1f0905230857j3cbc8934vce02ce54e25b59c4@mail.gmail.com> I tried to follow the steps with collects/drscheme/private/rep.ss and couldn't make it fail. Specifically, I hit return on the second line (making the buffer modified) and then check syntax; I waited until it was in "coloring" mode (according to the status line) and then hit cmd-s (for save) and nothing bad happened. I only tried it about 4 times, tho, so maybe I just didn't try enough? Or possibly because I'm using a mac there is something about the way event handling works on the mac that makes me miss the bug (because the save button does not go away until check syntax completes). Robby On Fri, May 22, 2009 at 3:23 PM, David Van Horn wrote: > I can consistently put DrScheme in a bad state by the following: > > 1) Open a fairly large file (so syntax checking takes time) > 2) Make a change > 3) click Check Syntax > 4) click Save -- before checking is complete. > > It seems as soon as syntax checking completes, an internal error is > signalled. ?The error varies, but it always occurs. ?Here are a couple: > > 1) > > sequence-contract-violation: negative: method delete cannot be called, > except in states (unlocked), args 0 360 > > ?=== context === > /Applications/PLT Scheme Full > v4.1.900/collects/drscheme/private/unit.ss:529:10: after-save-file method in > ...heme/private/unit.ss:454:8 > /Applications/PLT Scheme Full > v4.1.900/collects/drscheme/private/unit.ss:3884:29 > /Applications/PLT Scheme Full > v4.1.900/collects/scheme/private/more-scheme.ss:155:2: > call-with-break-parameterization > /Applications/PLT Scheme Full > v4.1.900/collects/scheme/private/more-scheme.ss:271:2: > call-with-exception-handler > > 2) > > hash-ref: expects type as 1st argument, given: #f; other arguments > were: #(struct:object:...engine/test-tool.scm:30:6 ...) > # > > ?=== context === > /Applications/PLT Scheme Full v4.1.900/collects/drscheme/syncheck.ss:414:12: > syncheck:add-menu method in ...drscheme/syncheck.ss:221:10 > /Applications/PLT Scheme Full v4.1.900/collects/scheme/private/map.ss:44:11: > for-each > /Applications/PLT Scheme Full > v4.1.900/collects/drscheme/syncheck.ss:1671:22: at-phase > /Applications/PLT Scheme Full v4.1.900/collects/scheme/private/map.ss:44:11: > for-each > /Applications/PLT Scheme Full v4.1.900/collects/scheme/private/map.ss:44:11: > for-each > /Applications/PLT Scheme Full v4.1.900/collects/drscheme/syncheck.ss:1489:4: > annotate-basic > /Applications/PLT Scheme Full > v4.1.900/collects/drscheme/syncheck.ss:1413:14: expanded-expression > /Applications/PLT Scheme Full v4.1.900/collects/drscheme/syncheck.ss:1247:38 > /Applications/PLT Scheme Full v4.1.900/collects/drscheme/syncheck.ss:1244:35 > > After this, the definitions window is broken. ?I cannot reposition the > cursor, type text, etc. ?I can click Save but it doesn't go away. ?Run and > the interactions window work fine. > > This is on 4.1.900-svn21may2009 [3m], Mac OSX, ISL/lambda. > > Should I be submitting bug reports, or emailing this list since this > concerns the release candidate? > > David > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > From robby at eecs.northwestern.edu Sat May 23 12:08:12 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Sat May 23 12:08:34 2009 Subject: [plt-dev] DrScheme definitions crash in pre-release In-Reply-To: <932b2f1f0905230857j3cbc8934vce02ce54e25b59c4@mail.gmail.com> References: <4A1709D0.90600@ccs.neu.edu> <932b2f1f0905230857j3cbc8934vce02ce54e25b59c4@mail.gmail.com> Message-ID: <932b2f1f0905230908m526d23e5i4722fb66e753fbc7@mail.gmail.com> Looking at the code, I think this could happen if the buffer were modified (triggering a callback that sets arrow-vectors to #f) while check syntax were still coloring the buffer. Check syntax does do things like lock the editor in order to ensure that those callbacks don't happen. So I guess the thing to do would be to figure out how it is getting set, probably by inspecting the stack at the point where (set! arrow-vectors #f) happens (line 404). If you dont' mind, could you add this between lines 403 and 404 and send the output? (printf "~s\n" (continuation-mark-set->context (current-continuation-marks))) ... are you in a teaching language? That would actually make more sense to me (but I'm still not getting the error to happen there either). Robby On Sat, May 23, 2009 at 10:57 AM, Robby Findler wrote: > I tried to follow the steps with collects/drscheme/private/rep.ss and > couldn't make it fail. Specifically, I hit return on the second line > (making the buffer modified) and then check syntax; I waited until it > was in "coloring" mode (according to the status line) and then hit > cmd-s (for save) and nothing bad happened. I only tried it about 4 > times, tho, so maybe I just didn't try enough? > > Or possibly because I'm using a mac there is something about the way > event handling works on the mac that makes me miss the bug (because > the save button does not go away until check syntax completes). > > Robby > > On Fri, May 22, 2009 at 3:23 PM, David Van Horn wrote: >> I can consistently put DrScheme in a bad state by the following: >> >> 1) Open a fairly large file (so syntax checking takes time) >> 2) Make a change >> 3) click Check Syntax >> 4) click Save -- before checking is complete. >> >> It seems as soon as syntax checking completes, an internal error is >> signalled. ?The error varies, but it always occurs. ?Here are a couple: >> >> 1) >> >> sequence-contract-violation: negative: method delete cannot be called, >> except in states (unlocked), args 0 360 >> >> ?=== context === >> /Applications/PLT Scheme Full >> v4.1.900/collects/drscheme/private/unit.ss:529:10: after-save-file method in >> ...heme/private/unit.ss:454:8 >> /Applications/PLT Scheme Full >> v4.1.900/collects/drscheme/private/unit.ss:3884:29 >> /Applications/PLT Scheme Full >> v4.1.900/collects/scheme/private/more-scheme.ss:155:2: >> call-with-break-parameterization >> /Applications/PLT Scheme Full >> v4.1.900/collects/scheme/private/more-scheme.ss:271:2: >> call-with-exception-handler >> >> 2) >> >> hash-ref: expects type as 1st argument, given: #f; other arguments >> were: #(struct:object:...engine/test-tool.scm:30:6 ...) >> # >> >> ?=== context === >> /Applications/PLT Scheme Full v4.1.900/collects/drscheme/syncheck.ss:414:12: >> syncheck:add-menu method in ...drscheme/syncheck.ss:221:10 >> /Applications/PLT Scheme Full v4.1.900/collects/scheme/private/map.ss:44:11: >> for-each >> /Applications/PLT Scheme Full >> v4.1.900/collects/drscheme/syncheck.ss:1671:22: at-phase >> /Applications/PLT Scheme Full v4.1.900/collects/scheme/private/map.ss:44:11: >> for-each >> /Applications/PLT Scheme Full v4.1.900/collects/scheme/private/map.ss:44:11: >> for-each >> /Applications/PLT Scheme Full v4.1.900/collects/drscheme/syncheck.ss:1489:4: >> annotate-basic >> /Applications/PLT Scheme Full >> v4.1.900/collects/drscheme/syncheck.ss:1413:14: expanded-expression >> /Applications/PLT Scheme Full v4.1.900/collects/drscheme/syncheck.ss:1247:38 >> /Applications/PLT Scheme Full v4.1.900/collects/drscheme/syncheck.ss:1244:35 >> >> After this, the definitions window is broken. ?I cannot reposition the >> cursor, type text, etc. ?I can click Save but it doesn't go away. ?Run and >> the interactions window work fine. >> >> This is on 4.1.900-svn21may2009 [3m], Mac OSX, ISL/lambda. >> >> Should I be submitting bug reports, or emailing this list since this >> concerns the release candidate? >> >> David >> _________________________________________________ >> ?For list-related administrative tasks: >> ?http://list.cs.brown.edu/mailman/listinfo/plt-dev >> > From dvanhorn at ccs.neu.edu Sat May 23 14:54:23 2009 From: dvanhorn at ccs.neu.edu (David Van Horn) Date: Sat May 23 14:54:51 2009 Subject: [plt-dev] DrScheme definitions crash in pre-release In-Reply-To: <932b2f1f0905230908m526d23e5i4722fb66e753fbc7@mail.gmail.com> References: <4A1709D0.90600@ccs.neu.edu> <932b2f1f0905230857j3cbc8934vce02ce54e25b59c4@mail.gmail.com> <932b2f1f0905230908m526d23e5i4722fb66e753fbc7@mail.gmail.com> Message-ID: <4A18465F.2060006@ccs.neu.edu> Robby Findler wrote: > I tried to follow the steps with collects/drscheme/private/rep.ss and > couldn't make it fail. Specifically, I hit return on the second line > (making the buffer modified) and then check syntax; I waited until it > was in "coloring" mode (according to the status line) and then hit > cmd-s (for save) and nothing bad happened. I only tried it about 4 > times, tho, so maybe I just didn't try enough? The problem occurs for me even if I click Save just once, although there is a time delay between clicking and the error. > Or possibly because I'm using a mac there is something about the way > event handling works on the mac that makes me miss the bug (because > the save button does not go away until check syntax completes). I'm on a mac too. > Looking at the code, I think this could happen if the buffer were > modified (triggering a callback that sets arrow-vectors to #f) while > check syntax were still coloring the buffer. Check syntax does do > things like lock the editor in order to ensure that those callbacks > don't happen. > > So I guess the thing to do would be to figure out how it is getting > set, probably by inspecting the stack at the point where (set! > arrow-vectors #f) happens (line 404). If you dont' mind, could you add > this between lines 403 and 404 and send the output? > > (printf "~s\n" (continuation-mark-set->context > (current-continuation-marks))) I don't mind. I made this edit, but where does this output go? I tried opening DrScheme from the terminal, but I don't see any output there and so far as I can tell, there is no output in DrScheme. > ... are you in a teaching language? That would actually make more > sense to me (but I'm still not getting the error to happen there > either). Yes, I am using ISL/lambda (this was in the original msg). I just confirmed -- the bug only occurs when I am in a student language. David From dvanhorn at ccs.neu.edu Sat May 23 15:02:56 2009 From: dvanhorn at ccs.neu.edu (David Van Horn) Date: Sat May 23 15:03:26 2009 Subject: [plt-dev] DrScheme definitions crash in pre-release In-Reply-To: <4A18465F.2060006@ccs.neu.edu> References: <4A1709D0.90600@ccs.neu.edu> <932b2f1f0905230857j3cbc8934vce02ce54e25b59c4@mail.gmail.com> <932b2f1f0905230908m526d23e5i4722fb66e753fbc7@mail.gmail.com> <4A18465F.2060006@ccs.neu.edu> Message-ID: <4A184860.7040709@ccs.neu.edu> David Van Horn wrote: > Robby Findler wrote: >> I tried to follow the steps with collects/drscheme/private/rep.ss and >> couldn't make it fail. Specifically, I hit return on the second line >> (making the buffer modified) and then check syntax; I waited until it >> was in "coloring" mode (according to the status line) and then hit >> cmd-s (for save) and nothing bad happened. I only tried it about 4 >> times, tho, so maybe I just didn't try enough? > > The problem occurs for me even if I click Save just once, although there > is a time delay between clicking and the error. Here is a small program that I can use to consistently reproduce the problem. Save both files into the same directory. Open wait-student.ss in DrScheme. Insert a space (modifying the file). Now press Check Syntax and quickly press Save (once will do). This program uses wait.ss to cause an expansion time delay, giving you a chance to save while check syntax is running. David -------------- next part -------------- #lang scheme (define-syntax (wait stx) (sleep 3) #''done) (wait) -------------- next part -------------- ;; The first three lines of this file were inserted by DrScheme. They record metadata ;; about the language level of this file in a form that our tools can easily process. #reader(lib "htdp-intermediate-reader.ss" "lang")((modname wait-student) (read-case-sensitive #t) (teachpacks ()) (htdp-settings #(#t constructor repeating-decimal #f #t none #f ()))) (require "wait.ss") From robby at eecs.northwestern.edu Sat May 23 15:48:10 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Sat May 23 15:48:29 2009 Subject: [plt-dev] DrScheme definitions crash in pre-release In-Reply-To: <4A184860.7040709@ccs.neu.edu> References: <4A1709D0.90600@ccs.neu.edu> <932b2f1f0905230857j3cbc8934vce02ce54e25b59c4@mail.gmail.com> <932b2f1f0905230908m526d23e5i4722fb66e753fbc7@mail.gmail.com> <4A18465F.2060006@ccs.neu.edu> <4A184860.7040709@ccs.neu.edu> Message-ID: <932b2f1f0905231248o2de3b2f1j78941a15a3ea94b2@mail.gmail.com> Thanks. I think I've fixed this now. The problem was that Check Syntax was not coping well with modifications to the editor while it was also updating the editor (and saving modifies the definitions window in the teaching languages). I've now made it cope with them a bit better, but I am not confident that my changes haven't introduced some more subtle problem, so I prefer to leave this alone for the release (since the bug has been there for years two more months won't matter). Robby From clements at brinckerhoff.org Sat May 23 16:39:43 2009 From: clements at brinckerhoff.org (John Clements) Date: Sat May 23 16:40:16 2009 Subject: [plt-dev] Installation directories on Mac OS X In-Reply-To: <20090523140153.D6DF36500A2@mail-svr1.cs.utah.edu> References: <143A246B-E9A1-4700-BD63-4C1BDB1B65EF@ccs.neu.edu> <53AA5419-F010-4CE1-9DF0-D4992546F6FE@deniau.org> <20090523140153.D6DF36500A2@mail-svr1.cs.utah.edu> Message-ID: On May 23, 2009, at 7:01 AM, Matthew Flatt wrote: > At Sat, 23 May 2009 15:26:19 +0200, Thomas Deniau wrote: >> You might be interested in including this patch to unixstyle.ss >> upstream : > > Thanks! > > > I somehow missed your original message. (Maybe I accidentally deleted > it before reading), but I see in the archives: > > Are there deeper reasons that would force origtree to yes on OS X even > without MrEd ? > > We don't want the default MzScheme build to be different from the > default Mred build, since the former is supposed to be a subset of the > latter. > > Longer term, we should look at making MrEd work within a Unix-style > installation. With your patch, maybe it's just a matter of putting > ".app"s in an appropriate place. FWIW: unlike fink's anti-app stance, MacPorts does include mac- style .apps; it generally puts them in /Applications/MacPorts, presumably to avoid conflicts with other existing applications. John -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2484 bytes Desc: not available Url : http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090523/19ee728b/smime.bin From matthias at ccs.neu.edu Sat May 23 21:16:40 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Sat May 23 21:17:07 2009 Subject: [plt-dev] make-list Message-ID: Yet another use: #lang scheme ;; Nat -> Pict ;; create a numberline with n dashes (define (numberline n) (define h1 20) (define w1 20) (define (one i) (cc-superimpose (blank w1 h1) (text (number- >string i)))) (define mmm (apply hc-append (make-list n (vline w1 h1)))) (define kkk (apply hc-append (build-list n one))) (define lnn (hline (* w1 n) h1)) (define img (vc-append (cc-superimpose mmm lnn) kkk)) (pin-arrow-line 3.0 img lnn lc-find lnn rc-find)) (numberline 21) From mflatt at cs.utah.edu Sun May 24 10:46:22 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Sun May 24 10:46:43 2009 Subject: [plt-dev] Pre-Release Checklist for v4.2 In-Reply-To: References: Message-ID: <20090524144623.DE0346500AF@mail-svr1.cs.utah.edu> At Wed, 20 May 2009 06:05:08 -0400, Eli Barzilay wrote: > * Matthew Flatt > - MzScheme Tests > - Languages Tests > - MrEd Tests (Also check that `mred -z' and `mred-text' still works > in Windows and Mac OS X) > - mzc Tests > - mzc --exe tests > - .plt-packing Tests > - Games Tests > - Unit Tests > - Syntax Color Tests > - R6RS Tests > Updates: > - MzScheme Updates: update HISTORY > - MrEd Updates: update README, HISTORY > (updates should show v4.2 as the most current version) > - Update man pages in plt/man/man1: mred.1, mzscheme.1 Done. From clements at brinckerhoff.org Sun May 24 14:20:16 2009 From: clements at brinckerhoff.org (John Clements) Date: Sun May 24 14:26:17 2009 Subject: [plt-dev] Pre-Release Checklist for v4.2 In-Reply-To: References: Message-ID: <363686C9-F82F-4421-9189-0A5854ECA09C@brinckerhoff.org> On May 20, 2009, at 3:05 AM, Eli Barzilay wrote: > > * John Clements > - Stepper Tests > Updates: > - Stepper Updates: update HISTORY > (updates should show v4.2 as the most current version) > Email me to merge the changes from the trunk when they're done, > or tell me if there are no such changes. done, HISTORY changes ready to merge. John -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2484 bytes Desc: not available Url : http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090524/e3b704d2/smime.bin From thomas at deniau.org Mon May 25 08:54:49 2009 From: thomas at deniau.org (Thomas Deniau) Date: Mon May 25 08:55:12 2009 Subject: [plt-dev] Installation directories on Mac OS X In-Reply-To: <53AA5419-F010-4CE1-9DF0-D4992546F6FE@deniau.org> References: <143A246B-E9A1-4700-BD63-4C1BDB1B65EF@ccs.neu.edu> <53AA5419-F010-4CE1-9DF0-D4992546F6FE@deniau.org> Message-ID: On 23 mai 09, at 15:26, Thomas Deniau wrote: > Done > ( http://trac.macports.org/attachment/ticket/19738/mzscheme.diff ). > > You might be interested in including this patch to unixstyle.ss > upstream : There are also some $(DESTDIR) lacking in mzscheme/Makefile.in : http://trac.macports.org/browser/trunk/dports/lang/mzscheme/files/patch-mzscheme-Makefile.in.diff?rev=51451 -- Thomas Deniau -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2417 bytes Desc: not available Url : http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090525/fe6d980b/smime.bin From eli at barzilay.org Mon May 25 22:42:43 2009 From: eli at barzilay.org (Eli Barzilay) Date: Mon May 25 22:43:12 2009 Subject: [plt-dev] Pre-Release Checklist for v4.2, second call Message-ID: [Note: this came in later than usual because of the extensive changes, next time will be back to the usual schedule.] Checklist items for the v4.2 release (using the v4.1.900 alpha build) Search for your name to find relevant items, reply when you finish an item (please indicate which item is done). Also, if you have any commits that should have been merged, make sure that they're in. Important: new builds are created without announcement, usually whenever I see significant commits. If you need to commit changes, please make sure you tell me to merge it to the release branch. --> Release candidates are at --> http://pre.plt-scheme.org/release/installers Please use these installers (or source bundles) -- don't test from your own svn chekout (don't test v4.2.0.2 by mistake!). To get the tests directory in the normal release, you can do this: cd .../collects svn export http://svn.plt-scheme.org/plt/release/collects/tests ---------------------------------------------------------------------- * Stevie Strickland - Unit Contract Tests - Contract Region Tests * Kathy Gray - ProfJ Tests * Noel Welsh , Chongkai Zhu - SRFI Tests - Ensure that all claimed srfi's are in the bundle and they all load into mzscheme or drscheme (as appropriate) * Eli Barzilay Version Updates: if a major change has happened, update the version number in: - plt/collects/mzscheme/info.ss - plt/collects/mred/info.ss -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From eli at barzilay.org Mon May 25 22:51:28 2009 From: eli at barzilay.org (Eli Barzilay) Date: Mon May 25 22:51:49 2009 Subject: [plt-dev] Release Announcement for v4.2 Message-ID: The release announcement sketch that I have so far is below. Please mail me new items and/or edits. ---------------------------------------------------------------------- PLT Scheme version 4.2 is now available from http://plt-scheme.org/ * New in `scheme/base': `hash-has-key?', `hash-ref!', `in-sequences', `in-cycle' and in `scheme': `count', `make-list' (from `scheme/list') `const' (from `scheme/function') * New statistical profiler, core and text interface for now * Scheme-implemented editor classes * on-demand instantiation of module phases * web-server: Native continuations in serial language, soft state, and typos. I'm not sure that these should have an item: * make-rename-transformer => free-identifier=? (v5.1.5.2) * free-id=? propagation through module exports; add 'not-free-identifier=? syntax property to disable free-id=? propagation; add prop:rename-transformer and prop:set-transformer; fix scheme/local so that local syntax bindings are visible to later definitions (v4.1.5.3) * per-thread cpu timing [Note that mirror sites can take a while to catch up with the new downloads.] Feedback Welcome, ---------------------------------------------------------------------- -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From robby at eecs.northwestern.edu Mon May 25 23:01:27 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Mon May 25 23:01:54 2009 Subject: [plt-dev] Release Announcement for v4.2 In-Reply-To: References: Message-ID: <932b2f1f0905252001q516b0a9fqfcbed9f318d00fa5@mail.gmail.com> I think we need a warning message with this release. Robby On Mon, May 25, 2009 at 9:51 PM, Eli Barzilay wrote: > The release announcement sketch that I have so far is below. ?Please > mail me new items and/or edits. > ---------------------------------------------------------------------- > PLT Scheme version 4.2 is now available from > > ?http://plt-scheme.org/ > > * New in `scheme/base': `hash-has-key?', `hash-ref!', > ? ? ? ? ? ? ? ? ? ? ? ?`in-sequences', `in-cycle' > ?and in `scheme': `count', `make-list' (from `scheme/list') > ? ? ? ? ? ? ? ? ? `const' (from `scheme/function') > > * New statistical profiler, core and text interface for now > > * Scheme-implemented editor classes > > * on-demand instantiation of module phases > > * web-server: Native continuations in serial language, soft > ?state, and typos. > > I'm not sure that these should have an item: > > * make-rename-transformer => free-identifier=? (v5.1.5.2) > > * free-id=? propagation through module exports; add > ?'not-free-identifier=? syntax property to disable free-id=? > ?propagation; add prop:rename-transformer and > ?prop:set-transformer; fix scheme/local so that local syntax > ?bindings are visible to later definitions (v4.1.5.3) > > * per-thread cpu timing > > [Note that mirror sites can take a while to catch up with the new > downloads.] > > Feedback Welcome, > ---------------------------------------------------------------------- > -- > ? ? ? ? ?((lambda (x) (x x)) (lambda (x) (x x))) ? ? ? ? ?Eli Barzilay: > ? ? ? ? ? ? ? ? ?http://www.barzilay.org/ ? ? ? ? ? ? ? ? Maze is Life! > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > From clements at brinckerhoff.org Mon May 25 23:41:45 2009 From: clements at brinckerhoff.org (John Clements) Date: Mon May 25 23:42:14 2009 Subject: [plt-dev] Release Announcement for v4.2 In-Reply-To: References: Message-ID: <8BE45D7C-5361-438C-B6FD-7ED8D9DCA45E@brinckerhoff.org> On May 25, 2009, at 7:51 PM, Eli Barzilay wrote: > The release announcement sketch that I have so far is below. Please > mail me new items and/or edits * The stepper can now jump to a selected program expression. John -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2484 bytes Desc: not available Url : http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090525/975b2a68/smime-0001.bin From czhu at cs.utah.edu Tue May 26 00:36:51 2009 From: czhu at cs.utah.edu (Chongkai Zhu) Date: Tue May 26 00:37:20 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.2, second call In-Reply-To: References: Message-ID: <4A1B71E3.4040300@cs.utah.edu> Eli Barzilay wrote: > * Noel Welsh , Chongkai Zhu > - SRFI Tests > - Ensure that all claimed srfi's are in the bundle and they all load > into mzscheme or drscheme (as appropriate) > > Done. Chongkai From matthias at ccs.neu.edu Tue May 26 08:37:44 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Tue May 26 08:38:17 2009 Subject: [plt-dev] Release Announcement for v4.2 In-Reply-To: References: Message-ID: <411AD2F8-EB71-4D63-8D24-1F14502ABBBF@ccs.neu.edu> world.ss is now deprecated; its replacement (universe.ss) has a new interface, using strings instead of symbols and chars. On May 25, 2009, at 10:51 PM, Eli Barzilay wrote: > The release announcement sketch that I have so far is below. Please > mail me new items and/or edits. > ---------------------------------------------------------------------- > PLT Scheme version 4.2 is now available from > > http://plt-scheme.org/ > > * New in `scheme/base': `hash-has-key?', `hash-ref!', > `in-sequences', `in-cycle' > and in `scheme': `count', `make-list' (from `scheme/list') > `const' (from `scheme/function') > > * New statistical profiler, core and text interface for now > > * Scheme-implemented editor classes > > * on-demand instantiation of module phases > > * web-server: Native continuations in serial language, soft > state, and typos. > > I'm not sure that these should have an item: > > * make-rename-transformer => free-identifier=? (v5.1.5.2) > > * free-id=? propagation through module exports; add > 'not-free-identifier=? syntax property to disable free-id=? > propagation; add prop:rename-transformer and > prop:set-transformer; fix scheme/local so that local syntax > bindings are visible to later definitions (v4.1.5.3) > > * per-thread cpu timing > > [Note that mirror sites can take a while to catch up with the new > downloads.] > > Feedback Welcome, > ---------------------------------------------------------------------- > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli > Barzilay: > http://www.barzilay.org/ Maze is > Life! > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From eli at barzilay.org Wed May 27 03:16:17 2009 From: eli at barzilay.org (Eli Barzilay) Date: Wed May 27 03:16:39 2009 Subject: [plt-dev] Release Announcement for v4.2, second call Message-ID: The release announcement sketch that I have so far is below, it's closer to proper text, but more input is needed. Note also the items that I don't know if it's worth mentioning or not. Please mail me new items and/or edits. ---------------------------------------------------------------------- PLT Scheme version 4.2 is now available from http://plt-scheme.org/ * A substantial part of MrEd (the editor classes) is now implemented in Scheme. [Need to say something about thousands of lines that were migrated etc.] * On-demand instantiation of module phases. [I don't know how to summarize that effectively.] * A new statistical profiler is now available, currently it supports only a textual output, and a GUI interface will be added and integrated into DrScheme. (See the "profiler" manual for more information.) * The `world' teachpack is now deprecated; its replacement (`universe') has a new interface, using strings instead of symbols and chars. * Web-server: Native continuations in serial language, soft state, and typos. * The stepper can now jump to a selected program expression. * New in `scheme/base': `hash-has-key?', `hash-ref!', `in-sequences', `in-cycle'; and new in `scheme': `count', `make-list' (from `scheme/list'), `const' (from `scheme/function') I'm not sure that these should have an item: * make-rename-transformer => free-identifier=? (v5.1.5.2) * free-id=? propagation through module exports; add 'not-free-identifier=? syntax property to disable free-id=? propagation; add prop:rename-transformer and prop:set-transformer; fix scheme/local so that local syntax bindings are visible to later definitions (v4.1.5.3) * per-thread cpu timing ---------------------------------------------------------------------- -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From sk at cs.brown.edu Wed May 27 06:42:14 2009 From: sk at cs.brown.edu (Shriram Krishnamurthi) Date: Wed May 27 06:42:53 2009 Subject: [plt-dev] Release Announcement for v4.2, second call In-Reply-To: References: Message-ID: > * Web-server: Native continuations in serial language, soft > ?state, and typos. It's fine to advertise that one has introduced native continuations and soft state, but it is rather more unusual to advertise that one has made new typos. (It's possible, though, that Jay meant to say "typo fixes"?) Shriram From eli at barzilay.org Wed May 27 06:44:27 2009 From: eli at barzilay.org (Eli Barzilay) Date: Wed May 27 06:44:47 2009 Subject: [plt-dev] Release Announcement for v4.2, second call In-Reply-To: References: Message-ID: <18973.6539.154735.223370@winooski.ccs.neu.edu> On May 27, Shriram Krishnamurthi wrote: > > * Web-server: Native continuations in serial language, soft state, > > and typos. > > It's fine to advertise that one has introduced native continuations > and soft state, but it is rather more unusual to advertise that one > has made new typos. (It's possible, though, that Jay meant to say > "typo fixes"?) These texts were just what I found in the commit messages. Jay already sent me a proper entry. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From dtnoizerz58 at yandex.ru Wed May 27 10:25:09 2009 From: dtnoizerz58 at yandex.ru (DTNOIZR) Date: Wed May 27 10:34:54 2009 Subject: [plt-dev] how to break and resume sandboxed evaluation multiple times? Message-ID: <17201243434309@webmail86.yandex.ru> 1) sorry for my bad english 2) I developing "collective programming environment" with multiple sandboxes 3) I need something that cannot work inside of current sandbox. I need to jump out from sandbox, do something and come back to sandbox with some result value. How to do it? I try exception handling but dont understand how to break and return multiple times ... 4)I asked this in plt-scheme@list.cs.brown.edu, but there was now answer From eli at barzilay.org Wed May 27 10:37:49 2009 From: eli at barzilay.org (Eli Barzilay) Date: Wed May 27 10:38:11 2009 Subject: [plt-dev] how to break and resume sandboxed evaluation multiple times? In-Reply-To: <17201243434309@webmail86.yandex.ru> References: <17201243434309@webmail86.yandex.ru> Message-ID: <18973.20541.720415.662752@winooski.ccs.neu.edu> On May 27, DTNOIZR wrote: > 1) sorry for my bad english > > 2) I developing "collective programming environment" with multiple > sandboxes > > 3) I need something that cannot work inside of current sandbox. I > need to jump out from sandbox, do something and come back to > sandbox with some result value. How to do it? I try exception > handling but dont understand how to break and return multiple > times ... > > 4) I asked this in plt-scheme@list.cs.brown.edu, but there was now > answer Sandboxes are *designed* to make this kind of interaction hard. For example, the sandboxed code is running in a separate thread. You will need to find some other way to have different sandboxes communicate. (The easiest choice is probably channels.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From dtnoizerz58 at yandex.ru Wed May 27 10:42:19 2009 From: dtnoizerz58 at yandex.ru (DTNOIZR) Date: Wed May 27 10:48:01 2009 Subject: [plt-dev] how to break and resume sandboxed evaluation multiple times? In-Reply-To: <18973.20541.720415.662752@winooski.ccs.neu.edu> References: <17201243434309@webmail86.yandex.ru> <18973.20541.720415.662752@winooski.ccs.neu.edu> Message-ID: <17961243435339@webmail88.yandex.ru> thanks will try channels 27.05.09, 18:37, "Eli Barzilay" : > On May 27, DTNOIZR wrote: > > 1) sorry for my bad english > > > > 2) I developing "collective programming environment" with multiple > > sandboxes > > > > 3) I need something that cannot work inside of current sandbox. I > > need to jump out from sandbox, do something and come back to > > sandbox with some result value. How to do it? I try exception > > handling but dont understand how to break and return multiple > > times ... > > > > 4) I asked this in plt-scheme@list.cs.brown.edu, but there was now > > answer > Sandboxes are *designed* to make this kind of interaction hard. > For example, the sandboxed code is running in a separate thread. You > will need to find some other way to have different sandboxes > communicate. (The easiest choice is probably channels.) > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > http://www.barzilay.org/ Maze is Life! From dtnoizerz58 at yandex.ru Wed May 27 10:40:34 2009 From: dtnoizerz58 at yandex.ru (DTNOIZR) Date: Wed May 27 10:51:43 2009 Subject: [plt-dev] how to break and resume sandboxed evaluation multiple times? In-Reply-To: <18973.20541.720415.662752@winooski.ccs.neu.edu> References: <17201243434309@webmail86.yandex.ru> <18973.20541.720415.662752@winooski.ccs.neu.edu> Message-ID: <141491243435234@webmail85.yandex.ru> From dyoo at cs.wpi.edu Wed May 27 14:50:54 2009 From: dyoo at cs.wpi.edu (Danny Yoo) Date: Wed May 27 14:51:16 2009 Subject: [plt-dev] Re: [plt-scheme] PLT Scheme v4.1.900 is available for testing In-Reply-To: References: Message-ID: On Wed, May 27, 2009 at 3:19 AM, Eli Barzilay wrote: > Version 4.1.900 is now available for testing from > > ?http://pre.plt-scheme.org/release/installers/ Ok, something broke. Here's the code: http://github.com/dyoo/moby-scheme/blob/devel/src/image-lift.ss lift-images! is meant to lift out image snips in a text%. In 4.1, this runs smoothly; under 4.1.900, I'm hitting what looks like an infinite loop. From jay.mccarthy at gmail.com Wed May 27 19:03:35 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Wed May 27 19:03:57 2009 Subject: [plt-dev] Continuous Integration Server Message-ID: I'd like to get some comments on what I have so far and stuff I plan on doing. --- What I Have --- If you go to http://faculty.cs.byu.edu/~jay/tmp/14986/ You'll see the interface for a sample run of my tester on revision 14986. [No particular reason Robby] The essential details about the revision are listed at the top (notice the links to inside the testing logs) followed by a table summarizing the run. This table always shows when there is a directory. Each entry on the table depends on if the path is a file or a directory. If it is a file, then you have (1) how long it took to "mred-text -t " the path; (2) whether the execution timed out (current timeout for everything is 10 minutes); (3) whether mred-text exited cleanly (meaning with status code 0); (4) whether there was output to STDERR. If it is a directory, you see the same information, except it is a sum of the contents of the directory. At the bottom is the entry for the entire directory. The path name on the left is a link to a page for that directory or file. As you browse, the breadcrumbs at the top of the page accumulate. Each sub-path is a link to the corresponding page, as you'd expect. If you go to the page for a file http://faculty.cs.byu.edu/~jay/tmp/14986/src/build/make.html or http://faculty.cs.byu.edu/~jay/tmp/14986/collects/frtime/gui/mod-mrpanel_ss.html are decent choices for this demo You'll have more information about the run, including the log. The stdout output is black; the stderr output is red. --- What I'd Like From You --- 1) Comments on the interface and information you would want to be displayed 2) A suggestion for a name [I'm thinking pis: the PLT Integration Server =P] 3) Comments on the ideas below --- What I Plan On Doing --- Here are some things I know I am planning on doing: * Determining if a file tests differently than the previous revision. Combining this with the saving of terminal output is, IMHO, a fairly robust way to locate errors and be testing suite agnostic. Basically, there will be another column that says "Changed?" and whether the output has changed. This is will be the basis of the "nag" emails with some heuristics to avoid unnecessary naggery. For example, if the file you just edited in the commit displays something different, it won't consider it any error if it always displayed something in that way. For example, if X.ss never printed anything on stderr than it will nag if it starts to even though you just edited it. However, if X.ss always printed on stderr, it won't nag if it prints something different. Obviously these heuristics will be very fluid. * Using Subversion properties to set the timeout on a per-file basis This will help the build not wait for ever for DrScheme, as it won't complete. By including it in Subversion, it will be versioned with the file, so the metadata is not in a magical place on the server. * Using Subversion properties to set the command-line options and execution program Most of the files can be run in mzscheme, but about 1000 need to be run in mred. Also, many files (particular in collects/tests/mzscheme/benchmarks) need command-line arguments to run properly. This will include an option to ignore files. The default will be that if a file ends in .ss, .scm, or .scrbl then mzscheme -t will do it. Again, if these are in Subversion, then it is more transparent and trackable what the test server should be doing. [I will set the initial version of these properties; no need to worry about it] * Jump to output changes on first page * Emitting the status of a build on twitter * Nag emails to committer and plt:responsible * Client-side sorting of directory listings * Eventually I'd like to do two different kinds of builds: A "fast" build that uses the previous slow build, but updates to the next version and perhaps does some sort of dependency heuristic to not run everything. A "clean" build corresponding to this. The goal would be that the fast build would be done within 30 minutes, but the clean would be available in a few hours. --- Some Data --- It took 7.34 hours to do the build on my Macbook in power save mode. At the average of 8 commits per day, this is too slow to keep up with the edge, but perhaps a better machine will do better. I currently don't even run test two files at once. (I could because I have dual CPUs on the laptop.) Plus with better timeouts I could shave off almost 5 hours. It took 500MBs of space for the source & compiled source. It took 18MBs for the output logs. The UI takes 20MBs. There were 20 files that were created in `pwd`. (Most of them with bizarre names.) There were 20 PLaneT packages installed. -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From clements at brinckerhoff.org Wed May 27 19:24:24 2009 From: clements at brinckerhoff.org (John Clements) Date: Wed May 27 19:24:51 2009 Subject: [plt-dev] Continuous Integration Server In-Reply-To: References: Message-ID: On May 27, 2009, at 4:03 PM, Jay McCarthy wrote: > I'd like to get some comments on what I have so far and stuff I plan > on doing. > > --- What I Have --- > If you go to > > http://faculty.cs.byu.edu/~jay/tmp/14986/ > > You'll see the interface for a sample run of my tester on revision > 14986. [No particular reason Robby] Nifty! I removed several dead files as a result of the information in this report. > --- What I'd Like From You --- > > 1) Comments on the interface and information you would want to be > displayed It might extraordinarily useful to record the first tested version that signalled an error. It didn't appear to me that that was contained in your proposed items below, though it might be considered a fairly natural extension. John -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2484 bytes Desc: not available Url : http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090527/29322827/smime.bin From eli at barzilay.org Wed May 27 23:27:24 2009 From: eli at barzilay.org (Eli Barzilay) Date: Wed May 27 23:27:45 2009 Subject: [plt-dev] Continuous Integration Server In-Reply-To: References: Message-ID: <18974.1180.607343.379667@winooski.ccs.neu.edu> On May 27, Jay McCarthy wrote: > I'd like to get some comments on what I have so far and stuff I plan > on doing. In complete as-I-see-it random order: * Nice interface, but the links are kind of easy to miss (since some are the usual blue, and some are black). * I like the "alert only on change" policy -- that solves a bunch of issues. But it might be problematic if there are files that produce random output -- so plan on having the meta-data should hold information like directions to ignore the file, the output, stderr output, exit code, etc. * If you're already computing the durations, then this would be another good point: if the time is very different than the previous measurement, then it's worth an alert. Also, it might be good to keep some historical data (perhaps on some selected files) to see how mzscheme is doing in general. (The plan is that I'll eventually add that to the nightly build too.) * Also, allowing to sort the result list on the time could be a useful indicator that something is wrong. * You can probably tackle timeouts in a similar way. Another thing to do with things like drscheme and plt-games is have the meta-data specify that a new window is expected to pop up with some specific title, and just declare success when you see it (see "iplt/build/test-drscheme.ss" -- it does that for drscheme). * It might be better to read a file and run it only if it's a module by the expected name, to avoid running bogus files. (Looks like this is the bulk of the loading errors.) Since this depends only on the contents of the file, you could just cache it. (Perhaps by just catching the right load error and ignoring it.) * Links from a file's page to the svn location would be nice. Maybe even dump the file's contents on the same page. (Makes it much easier to see that some problem is expected.) * The font used for the file rows is different from the Total row. (Makes it weird when there are two 1s that look different...) * Also, the meta-data should contain instructions that apply to a whole collection -- this will be usful in the case of tests/mzscheme, where it doesn't make sense to load each file, since there's a central file that loads them all anyway. (So it should probably look like some inclusion exclusion thing, where I can say "run only all.ss like that, and ignore all other files".) * If you're running a separate process for each file, you can just as well clean the directory and avoid those problems. * I'll repeat a point I made earlier -- putting the meta data on svn properties means that some people will never use that. I'd prefer some file (maybe in iplt/build, maybe even using the same language that is used for the specs). > Combining this with the saving of terminal output is, IMHO, a fairly > robust way to locate errors and be testing suite agnostic. Basically, > there will be another column that says "Changed?" and whether the > output has changed. This is will be the basis of the "nag" emails with > some heuristics to avoid unnecessary naggery. But when would "change" go away? My best guess for this involves people logging in and clicking somewhere to acknowledge that a change is expected. > For example, if the file you just edited in the commit displays > something different, it won't consider it any error if it always > displayed something in that way. For example, if X.ss never printed > anything on stderr than it will nag if it starts to even though you > just edited it. However, if X.ss always printed on stderr, it won't > nag if it prints something different. Obviously these heuristics will > be very fluid. I think that nagging also on a different output would be good, with a meta-data way to avoid it. > * Using Subversion properties to set the timeout on a per-file basis > > This will help the build not wait for ever for DrScheme, as it won't > complete. By including it in Subversion, it will be versioned with > the file, so the metadata is not in a magical place on the server. The expected window title works better for this, IMO. Adds a test instead of a fragile timeout. (And BTW, timeouts can be very fragile, since the OS might do something like a backup which will throw everything off.) > * Emitting the status of a build on twitter (Is that *really* necessary...?) > * Eventually I'd like to do two different kinds of builds: A "fast" > build that uses the previous slow build, but updates to the next > version and perhaps does some sort of dependency heuristic to not > run everything. A "clean" build corresponding to this. The goal > would be that the fast build would be done within 30 minutes, but > the clean would be available in a few hours. The time to run each of the files is probably far more dominating than the time to do a full build. > It took 7.34 hours to do the build on my Macbook in power save mode. > At the average of 8 commits per day, this is too slow to keep up > with the edge, but perhaps a better machine will do better. I > currently don't even run test two files at once. (I could because I > have dual CPUs on the laptop.) Plus with better timeouts I could > shave off almost 5 hours. IME, getting a linux installation on a good recent machine will be much faster. > It took 500MBs of space for the source & compiled source. Actually I have that at 600MB now. (Which can lead to some issues when dealing with the nightly builds -- since that's multiplied by the number of builds, then there are several packages for each OS...) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From eli at barzilay.org Wed May 27 23:29:15 2009 From: eli at barzilay.org (Eli Barzilay) Date: Wed May 27 23:29:36 2009 Subject: [plt-dev] Specs language In-Reply-To: <18974.1180.607343.379667@winooski.ccs.neu.edu> References: <18974.1180.607343.379667@winooski.ccs.neu.edu> Message-ID: <18974.1291.722627.598167@winooski.ccs.neu.edu> On May 27, Eli Barzilay wrote: > > * I'll repeat a point I made earlier -- putting the meta data on svn > properties means that some people will never use that. I'd prefer > some file (maybe in iplt/build, maybe even using the same language > that is used for the specs). On a different topic, your datalog language might be a good replacement for the distribution specs "language". -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From eli at barzilay.org Wed May 27 23:32:02 2009 From: eli at barzilay.org (Eli Barzilay) Date: Wed May 27 23:32:22 2009 Subject: [plt-dev] Continuous Integration Server In-Reply-To: <18974.1180.607343.379667@winooski.ccs.neu.edu> References: <18974.1180.607343.379667@winooski.ccs.neu.edu> Message-ID: <18974.1458.564423.83693@winooski.ccs.neu.edu> Oh, and one more: once the plt:responsible property is actually in a more complete state, then an obvious feature request would be filtering the results by that. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From jay.mccarthy at gmail.com Thu May 28 06:21:12 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Thu May 28 06:21:36 2009 Subject: [plt-dev] Re: Specs language In-Reply-To: <18974.1291.722627.598167@winooski.ccs.neu.edu> References: <18974.1180.607343.379667@winooski.ccs.neu.edu> <18974.1291.722627.598167@winooski.ccs.neu.edu> Message-ID: Cool. It might be easy to add foreign functions to my Datalog if you need interesting computations. Let me know if you have problems encoding it. Now that you have my mind running, maybe I could use it for my metadata. Jay On Wed, May 27, 2009 at 11:29 PM, Eli Barzilay wrote: > On May 27, Eli Barzilay wrote: >> >> * I'll repeat a point I made earlier -- putting the meta data on svn >> ? properties means that some people will never use that. ?I'd prefer >> ? some file (maybe in iplt/build, maybe even using the same language >> ? that is used for the specs). > > On a different topic, your datalog language might be a good > replacement for the distribution specs "language". > > -- > ? ? ? ? ?((lambda (x) (x x)) (lambda (x) (x x))) ? ? ? ? ?Eli Barzilay: > ? ? ? ? ? ? ? ? ?http://www.barzilay.org/ ? ? ? ? ? ? ? ? Maze is Life! > -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From eli at barzilay.org Thu May 28 06:35:33 2009 From: eli at barzilay.org (Eli Barzilay) Date: Thu May 28 06:35:54 2009 Subject: [plt-dev] Re: Specs language In-Reply-To: References: <18974.1180.607343.379667@winooski.ccs.neu.edu> <18974.1291.722627.598167@winooski.ccs.neu.edu> Message-ID: <18974.26869.906889.763920@winooski.ccs.neu.edu> On May 28, Jay McCarthy wrote: > Cool. It might be easy to add foreign functions to my Datalog if you > need interesting computations. Let me know if you have problems > encoding it. Now that you have my mind running, maybe I could use it > for my metadata. Well, that's a kind of a hack in the current spec language: it requires being able to hook a scheme function either to compute something (eg, path functions), or to do some side effect (like creating a distribution). It might also be possible to use the same thing for the dependencies (which is pretty heavy). -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From jay.mccarthy at gmail.com Thu May 28 06:46:27 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Thu May 28 06:46:49 2009 Subject: [plt-dev] Continuous Integration Server In-Reply-To: <18974.1180.607343.379667@winooski.ccs.neu.edu> References: <18974.1180.607343.379667@winooski.ccs.neu.edu> Message-ID: Thanks for the comments, Eli. I will act on most of them, I have a few questions below though. On Wed, May 27, 2009 at 11:27 PM, Eli Barzilay wrote: > On May 27, Jay McCarthy wrote: >> I'd like to get some comments on what I have so far and stuff I plan >> on doing. > > In complete as-I-see-it random order: > > * Nice interface, but the links are kind of easy to miss (since some > ?are the usual blue, and some are black). > > * I like the "alert only on change" policy -- that solves a bunch of > ?issues. ?But it might be problematic if there are files that produce > ?random output -- so plan on having the meta-data should hold > ?information like directions to ignore the file, the output, stderr > ?output, exit code, etc. > > * If you're already computing the durations, then this would be > ?another good point: if the time is very different than the previous > ?measurement, then it's worth an alert. ?Also, it might be good to > ?keep some historical data (perhaps on some selected files) to see > ?how mzscheme is doing in general. ?(The plan is that I'll eventually > ?add that to the nightly build too.) > > * Also, allowing to sort the result list on the time could be a useful > ?indicator that something is wrong. > > * You can probably tackle timeouts in a similar way. ?Another thing to > ?do with things like drscheme and plt-games is have the meta-data > ?specify that a new window is expected to pop up with some specific > ?title, and just declare success when you see it (see > ?"iplt/build/test-drscheme.ss" -- it does that for drscheme). > > * It might be better to read a file and run it only if it's a module > ?by the expected name, to avoid running bogus files. ?(Looks like > ?this is the bulk of the loading errors.) ?Since this depends only on > ?the contents of the file, you could just cache it. ?(Perhaps by just > ?catching the right load error and ignoring it.) > > * Links from a file's page to the svn location would be nice. ?Maybe > ?even dump the file's contents on the same page. ?(Makes it much > ?easier to see that some problem is expected.) > > * The font used for the file rows is different from the Total row. > ?(Makes it weird when there are two 1s that look different...) > > * Also, the meta-data should contain instructions that apply to a > ?whole collection -- this will be usful in the case of > ?tests/mzscheme, where it doesn't make sense to load each file, since > ?there's a central file that loads them all anyway. ?(So it should > ?probably look like some inclusion exclusion thing, where I can say > ?"run only all.ss like that, and ignore all other files".) > > * If you're running a separate process for each file, you can just as > ?well clean the directory and avoid those problems. Which directory do you mean here? > * I'll repeat a point I made earlier -- putting the meta data on svn > ?properties means that some people will never use that. ?I'd prefer > ?some file (maybe in iplt/build, maybe even using the same language > ?that is used for the specs). I don't understand this point. If it is some file in iplt then there's an even bigger disincentive for people to update it themselves. If it is a property it is not terribly hard to do a: svn pset plt:tester:command-line "mzscheme -qu ~a" the-file.ss or svn pset plt:tester:timeout "60" the-file.ss Maybe you are saying that in your experience people won't ever do anything, so I might as well make it easier for me. > >> Combining this with the saving of terminal output is, IMHO, a fairly >> robust way to locate errors and be testing suite agnostic. Basically, >> there will be another column that says "Changed?" and whether the >> output has changed. This is will be the basis of the "nag" emails with >> some heuristics to avoid unnecessary naggery. > > But when would "change" go away? ?My best guess for this involves > people logging in and clicking somewhere to acknowledge that a change > is expected. These changes would be computed on a per-revision basis. The only data is whether it is changed relative to the last revision. Therefore, there's no reason to acknowledge anything on the part of users. Am I misunderstanding your question? > >> For example, if the file you just edited in the commit displays >> something different, it won't consider it any error if it always >> displayed something in that way. For example, if X.ss never printed >> anything on stderr than it will nag if it starts to even though you >> just edited it. However, if X.ss always printed on stderr, it won't >> nag if it prints something different. Obviously these heuristics will >> be very fluid. > > I think that nagging also on a different output would be good, with a > meta-data way to avoid it. > >> * Using Subversion properties to set the timeout on a per-file basis >> >> This will help the build not wait for ever for DrScheme, as it won't >> complete. By including it in Subversion, it will be versioned with >> the file, so the metadata is not in a magical place on the server. > > The expected window title works better for this, IMO. ?Adds a test > instead of a fragile timeout. ?(And BTW, timeouts can be very fragile, > since the OS might do something like a backup which will throw > everything off.) This machine will do nothing else (including backups, because I could just rerun the software... everything it does is soft state.) > >> * Emitting the status of a build on twitter > > (Is that *really* necessary...?) Well, I use twitter, so it would be nice for me to know what the server is doing without getting lots of emails or having to check a site. (My main point in including the bullet is that you won't shouldn't expect informative emails unless something bad happened.) > >> * Eventually I'd like to do two different kinds of builds: A "fast" >> build that uses the previous slow build, but updates to the next >> version and perhaps does some sort of dependency heuristic to not >> run everything. A "clean" build corresponding to this. The goal >> would be that the fast build would be done within 30 minutes, but >> the clean would be available in a few hours. > > The time to run each of the files is probably far more dominating than > the time to do a full build. We're using the word "build" differently. I mean: everything my software does, i.e., running all the files. My "fast" version would not run _everything_ but would have some heuristic about what files should be run given commits. (Such as, everything in the same collection.) > >> It took 7.34 hours to do the build on my Macbook in power save mode. >> At the average of 8 commits per day, this is too slow to keep up >> with the edge, but perhaps a better machine will do better. I >> currently don't even run test two files at once. (I could because I >> have dual CPUs on the laptop.) Plus with better timeouts I could >> shave off almost 5 hours. > > IME, getting a linux installation on a good recent machine will be > much faster. > >> It took 500MBs of space for the source & compiled source. > > Actually I have that at 600MB now. ?(Which can lead to some issues > when dealing with the nightly builds -- since that's multiplied by the > number of builds, then there are several packages for each OS...) > > -- > ? ? ? ? ?((lambda (x) (x x)) (lambda (x) (x x))) ? ? ? ? ?Eli Barzilay: > ? ? ? ? ? ? ? ? ?http://www.barzilay.org/ ? ? ? ? ? ? ? ? Maze is Life! > -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From noelwelsh at gmail.com Thu May 28 07:10:27 2009 From: noelwelsh at gmail.com (Noel Welsh) Date: Thu May 28 07:10:47 2009 Subject: [plt-dev] Continuous Integration Server In-Reply-To: References: Message-ID: This is good. Some suggestions: On Thu, May 28, 2009 at 12:03 AM, Jay McCarthy wrote: > * Jump to output changes on first page If this means I could click on, say, the STDERR output column and see all files that emitted output, that would be good. Looking at STDERR etc. is kinda hokey (I know it's all there is a for a lot of things). Some code has decent test suites. Being able to specify where and how to run those suites would be good. (This was the motivation for Sake -- I wanted a CI server, but first needed to specify how to build a project.) A quick status overview would be good. Say, change the entire background to RED when something has broken. A lot of places have the policy that no dev. can proceed while the build is broken. I suspect PLT is too loosely coupled for that to work. Subversion properties are a bit invisible to the average programmer, but I guess they are as reasonable as any other method. With a bit of abstraction it shouldn't matter. N. From eli at barzilay.org Thu May 28 07:24:03 2009 From: eli at barzilay.org (Eli Barzilay) Date: Thu May 28 07:24:24 2009 Subject: [plt-dev] Continuous Integration Server In-Reply-To: References: <18974.1180.607343.379667@winooski.ccs.neu.edu> Message-ID: <18974.29779.396396.200291@winooski.ccs.neu.edu> On May 28, Jay McCarthy wrote: > > On Wed, May 27, 2009 at 11:27 PM, Eli Barzilay wrote: > > > > * If you're running a separate process for each file, you can just > > as well clean the directory and avoid those problems. > > Which directory do you mean here? I was referring to the problem of having file leftovers -- so between running processes you can just remove any leftover contents in the directory you're running it from (which can be any random directory). > > * I'll repeat a point I made earlier -- putting the meta data on > > svn properties means that some people will never use that. ?I'd > > prefer some file (maybe in iplt/build, maybe even using the same > > language that is used for the specs). > > I don't understand this point. If it is some file in iplt then > there's an even bigger disincentive for people to update it > themselves. If it is a property it is not terribly hard to do a: > > svn pset plt:tester:command-line "mzscheme -qu ~a" the-file.ss > > or > > svn pset plt:tester:timeout "60" the-file.ss > > Maybe you are saying that in your experience people won't ever do > anything, so I might as well make it easier for me. Yes, that's a better way of putting it... I think that it's largely because people don't usually need it (setting properties), so it's usually just beyond the short-term memory that is required to use it. Keeping it in one file will be easier for you, since crawling over the svn tree and making batch changes can be less convenient. > >> Combining this with the saving of terminal output is, IMHO, a > >> fairly robust way to locate errors and be testing suite > >> agnostic. Basically, there will be another column that says > >> "Changed?" and whether the output has changed. This is will be > >> the basis of the "nag" emails with some heuristics to avoid > >> unnecessary naggery. > > > > But when would "change" go away? ?My best guess for this involves > > people logging in and clicking somewhere to acknowledge that a > > change is expected. > > These changes would be computed on a per-revision basis. The only > data is whether it is changed relative to the last revision. > Therefore, there's no reason to acknowledge anything on the part of > users. Am I misunderstanding your question? Possibly. I think that a very common situation is that you're changing something, and you get back an alert -- the alert means that there's something that needs fixing, but since you don't have time right now you decide to deal with it later. So ideally, it would be nice to have a page of changes that happened in files that are my responsibility (and/or files that are someone else's but that I changed or broke), and I can visit that page at any time and mark off things that are fine, or that I have dealt with somehow (even just confirmed that the output is expected). > >> For example, if the file you just edited in the commit displays > >> something different, it won't consider it any error if it always > >> displayed something in that way. For example, if X.ss never printed > >> anything on stderr than it will nag if it starts to even though you > >> just edited it. However, if X.ss always printed on stderr, it won't > >> nag if it prints something different. Obviously these heuristics will > >> be very fluid. > > > > I think that nagging also on a different output would be good, with a > > meta-data way to avoid it. > > > >> * Using Subversion properties to set the timeout on a per-file basis > >> > >> This will help the build not wait for ever for DrScheme, as it won't > >> complete. By including it in Subversion, it will be versioned with > >> the file, so the metadata is not in a magical place on the server. > > > > The expected window title works better for this, IMO. ?Adds a test > > instead of a fragile timeout. ?(And BTW, timeouts can be very > > fragile, since the OS might do something like a backup which will > > throw everything off.) > > This machine will do nothing else (including backups, because I > could just rerun the software... everything it does is soft state.) The OS will still do other things. For example, you might run two tests, the first uses a lot of memory, which makes the next one load very slowly because the FS cache is all gone. Which also reminds me: when you scan the directory for files to run, sort them. Without that there might be such differences due to the particular order the files are in -- it's obviously best to not have such things, but even worse to run into a situation that is unreproducible because of it. (At some point there was a problem like that with setup-plt, and after a long chase session I made it compile files and directories alphabetically.) > >> * Emitting the status of a build on twitter > > > > (Is that *really* necessary...?) > > Well, I use twitter, so it would be nice for me to know what the > server is doing without getting lots of emails or having to check a > site. (My main point in including the bullet is that you won't > shouldn't expect informative emails unless something bad happened.) (Yeah, well, I *prefer* getting everything through emails... Much easier when there's a single entry point. I had a similar discussion with Jon Rafkind who wanted to do some subversion thing that sends commit messages on an IRC channel.) > >> * Eventually I'd like to do two different kinds of builds: A "fast" > >> build that uses the previous slow build, but updates to the next > >> version and perhaps does some sort of dependency heuristic to not > >> run everything. A "clean" build corresponding to this. The goal > >> would be that the fast build would be done within 30 minutes, but > >> the clean would be available in a few hours. > > > > The time to run each of the files is probably far more dominating > > than the time to do a full build. > > We're using the word "build" differently. I mean: everything my > software does, i.e., running all the files. My "fast" version would > not run _everything_ but would have some heuristic about what files > should be run given commits. (Such as, everything in the same > collection.) OK. This is probably not too difficult using the dependency files. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From noelwelsh at gmail.com Thu May 28 07:44:20 2009 From: noelwelsh at gmail.com (Noel Welsh) Date: Thu May 28 07:44:39 2009 Subject: [plt-dev] Continuous Integration Server In-Reply-To: References: Message-ID: On Thu, May 28, 2009 at 12:03 AM, Jay McCarthy wrote: > 2) A suggestion for a name [I'm thinking pis: the PLT Integration Server =P] Unfortunate acronym. DrDr? (As in, the thing that checks DrScheme is healthy) Doodlebug? (It runs around a lot, not really getting anywhere. [Also, unfortunate connotations in line .ss -- gives the IRC trolls something to talk about]) Astrolabe? (PLT Scheme is the sun around which PLaneT orbits. The astrolabe predicts the orbits.) N. From mflatt at cs.utah.edu Thu May 28 08:29:18 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Thu May 28 08:29:44 2009 Subject: [plt-dev] Re: [plt-scheme] PLT Scheme v4.1.900 is available for testing In-Reply-To: References: Message-ID: <20090528122919.E4A3D6500BF@mail-svr1.cs.utah.edu> Thanks! This is now fixed in SVN. At Wed, 27 May 2009 14:50:54 -0400, Danny Yoo wrote: > On Wed, May 27, 2009 at 3:19 AM, Eli Barzilay wrote: > > Version 4.1.900 is now available for testing from > > > > ?http://pre.plt-scheme.org/release/installers/ > > > Ok, something broke. Here's the code: > > http://github.com/dyoo/moby-scheme/blob/devel/src/image-lift.ss > > lift-images! is meant to lift out image snips in a text%. In 4.1, > this runs smoothly; under 4.1.900, I'm hitting what looks like an > infinite loop. > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From matthias at ccs.neu.edu Thu May 28 11:23:32 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Thu May 28 11:24:14 2009 Subject: [plt-dev] Continuous Integration Server In-Reply-To: References: Message-ID: <7C658DDA-FCD5-466C-BFDD-E706328935B7@ccs.neu.edu> doctordoctor is the right name :-) On May 28, 2009, at 7:44 AM, Noel Welsh wrote: > On Thu, May 28, 2009 at 12:03 AM, Jay McCarthy > wrote: >> 2) A suggestion for a name [I'm thinking pis: the PLT Integration >> Server =P] > > Unfortunate acronym. > > DrDr? (As in, the thing that checks DrScheme is healthy) > Doodlebug? (It runs around a lot, not really getting anywhere. [Also, > unfortunate connotations in line .ss -- gives the IRC trolls something > to talk about]) > Astrolabe? (PLT Scheme is the sun around which PLaneT orbits. The > astrolabe predicts the orbits.) > > N. > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From jay.mccarthy at gmail.com Thu May 28 11:28:07 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Thu May 28 11:28:29 2009 Subject: [plt-dev] Continuous Integration Server In-Reply-To: <7C658DDA-FCD5-466C-BFDD-E706328935B7@ccs.neu.edu> References: <7C658DDA-FCD5-466C-BFDD-E706328935B7@ccs.neu.edu> Message-ID: Alright, DrDr it is. Jay On Thu, May 28, 2009 at 11:23 AM, Matthias Felleisen wrote: > > doctordoctor is the right name :-) > > > On May 28, 2009, at 7:44 AM, Noel Welsh wrote: > >> On Thu, May 28, 2009 at 12:03 AM, Jay McCarthy >> wrote: >>> >>> 2) A suggestion for a name [I'm thinking pis: the PLT Integration Server >>> =P] >> >> Unfortunate acronym. >> >> DrDr? ?(As in, the thing that checks DrScheme is healthy) >> Doodlebug? (It runs around a lot, not really getting anywhere. [Also, >> unfortunate connotations in line .ss -- gives the IRC trolls something >> to talk about]) >> Astrolabe? (PLT Scheme is the sun around which PLaneT orbits. The >> astrolabe predicts the orbits.) >> >> N. >> _________________________________________________ >> ?For list-related administrative tasks: >> ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > > -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From robby at eecs.northwestern.edu Thu May 28 11:28:38 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Thu May 28 11:28:59 2009 Subject: [plt-dev] Continuous Integration Server In-Reply-To: <7C658DDA-FCD5-466C-BFDD-E706328935B7@ccs.neu.edu> References: <7C658DDA-FCD5-466C-BFDD-E706328935B7@ccs.neu.edu> Message-ID: <932b2f1f0905280828y27f81e35re42e251e2cbbe21b@mail.gmail.com> http://www.youtube.com/watch?v=LjSjmw_7uIE On Thu, May 28, 2009 at 10:23 AM, Matthias Felleisen wrote: > > doctordoctor is the right name :-) > > > On May 28, 2009, at 7:44 AM, Noel Welsh wrote: > >> On Thu, May 28, 2009 at 12:03 AM, Jay McCarthy >> wrote: >>> >>> 2) A suggestion for a name [I'm thinking pis: the PLT Integration Server >>> =P] >> >> Unfortunate acronym. >> >> DrDr? ?(As in, the thing that checks DrScheme is healthy) >> Doodlebug? (It runs around a lot, not really getting anywhere. [Also, >> unfortunate connotations in line .ss -- gives the IRC trolls something >> to talk about]) >> Astrolabe? (PLT Scheme is the sun around which PLaneT orbits. The >> astrolabe predicts the orbits.) >> >> N. >> _________________________________________________ >> ?For list-related administrative tasks: >> ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > From grettke at acm.org Thu May 28 13:48:12 2009 From: grettke at acm.org (Grant Rettke) Date: Thu May 28 13:48:35 2009 Subject: [plt-dev] Continuous Integration Server In-Reply-To: <932b2f1f0905280828y27f81e35re42e251e2cbbe21b@mail.gmail.com> References: <7C658DDA-FCD5-466C-BFDD-E706328935B7@ccs.neu.edu> <932b2f1f0905280828y27f81e35re42e251e2cbbe21b@mail.gmail.com> Message-ID: <756daca50905281048o421bb07eie4ee0dc0d260476e@mail.gmail.com> http://www.youtube.com/watch?v=nW5kIhcByac On Thu, May 28, 2009 at 10:28 AM, Robby Findler wrote: > http://www.youtube.com/watch?v=LjSjmw_7uIE > > On Thu, May 28, 2009 at 10:23 AM, Matthias Felleisen > wrote: >> >> doctordoctor is the right name :-) >> >> >> On May 28, 2009, at 7:44 AM, Noel Welsh wrote: >> >>> On Thu, May 28, 2009 at 12:03 AM, Jay McCarthy >>> wrote: >>>> >>>> 2) A suggestion for a name [I'm thinking pis: the PLT Integration Server >>>> =P] >>> >>> Unfortunate acronym. >>> >>> DrDr? ?(As in, the thing that checks DrScheme is healthy) >>> Doodlebug? (It runs around a lot, not really getting anywhere. [Also, >>> unfortunate connotations in line .ss -- gives the IRC trolls something >>> to talk about]) >>> Astrolabe? (PLT Scheme is the sun around which PLaneT orbits. The >>> astrolabe predicts the orbits.) >>> >>> N. >>> _________________________________________________ >>> ?For list-related administrative tasks: >>> ?http://list.cs.brown.edu/mailman/listinfo/plt-dev >> >> _________________________________________________ >> ?For list-related administrative tasks: >> ?http://list.cs.brown.edu/mailman/listinfo/plt-dev >> > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > -- http://www.wisdomandwonder.com/ From clements at brinckerhoff.org Thu May 28 20:54:43 2009 From: clements at brinckerhoff.org (John Clements) Date: Thu May 28 20:55:07 2009 Subject: [plt-dev] Continuous Integration Server In-Reply-To: <756daca50905281048o421bb07eie4ee0dc0d260476e@mail.gmail.com> References: <7C658DDA-FCD5-466C-BFDD-E706328935B7@ccs.neu.edu> <932b2f1f0905280828y27f81e35re42e251e2cbbe21b@mail.gmail.com> <756daca50905281048o421bb07eie4ee0dc0d260476e@mail.gmail.com> Message-ID: <084874B7-F490-4408-89F0-4016002E1D37@brinckerhoff.org> Interesting; my first thought was of Richard Scarry's Mr. Doctor Doctor and Mrs. Doctor Doctor. John On May 28, 2009, at 10:48 AM, Grant Rettke wrote: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2484 bytes Desc: not available Url : http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090528/0aeb8f2c/smime.bin From matthias at ccs.neu.edu Thu May 28 17:05:50 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Thu May 28 22:16:00 2009 Subject: [plt-dev] Continuous Integration Server In-Reply-To: References: Message-ID: Jay, thanks again for taking on this task. I really appreciate it, and so will NSF :-) I promised something like this in our CRI grant, but Eli's too busy for this. A couple of comments: 1. Consider some feed-back mechanism (via a web servlet perhaps) for people to accept and reject some of your software's choices. In short, consider building in some 'learning mechanism'. (I have nothing sophisticated in mind just web links that you register somehow. Then again over time you may learn to predict things from user choices and feedback.) 2. Your emails could include svn pset commands for setting/changing properties that you think may be appropriate to improve your software's behavior. (For example, if some file times out, your nagger could include a command to set the time out property low because I know that it's useless to wait or something like that.) 3. I definitely prefer svn props to a file -- especially if you can implement 2. 4. I agree with Eli on Twitter etc. I prefer email as my one point of communication. 5. Consider a monthly summary statement. 6. If you have trouble finding buying machines, holler. I am sure we can find some hardware money somewhere that buys a decent box. -- Matthias On May 27, 2009, at 7:03 PM, Jay McCarthy wrote: > I'd like to get some comments on what I have so far and stuff I > plan on doing. > > --- What I Have --- > If you go to > > http://faculty.cs.byu.edu/~jay/tmp/14986/ > > You'll see the interface for a sample run of my tester on revision > 14986. [No particular reason Robby] > > The essential details about the revision are listed at the top (notice > the links to inside the testing logs) followed by a table summarizing > the run. This table always shows when there is a directory. > > Each entry on the table depends on if the path is a file or a > directory. > > If it is a file, then you have (1) how long it took to "mred-text -t > " the path; (2) whether the execution timed out (current timeout > for everything is 10 minutes); (3) whether mred-text exited cleanly > (meaning with status code 0); (4) whether there was output to STDERR. > > If it is a directory, you see the same information, except it is a sum > of the contents of the directory. > > At the bottom is the entry for the entire directory. > > The path name on the left is a link to a page for that directory or > file. As you browse, the breadcrumbs at the top of the page > accumulate. Each sub-path is a link to the corresponding page, as > you'd expect. > > If you go to the page for a file > > http://faculty.cs.byu.edu/~jay/tmp/14986/src/build/make.html > > or http://faculty.cs.byu.edu/~jay/tmp/14986/collects/frtime/gui/mod- > mrpanel_ss.html > > are decent choices for this demo > > You'll have more information about the run, including the log. The > stdout output is black; the stderr output is red. > > --- What I'd Like From You --- > > 1) Comments on the interface and information you would want to be > displayed > > 2) A suggestion for a name [I'm thinking pis: the PLT Integration > Server =P] > > 3) Comments on the ideas below > > --- What I Plan On Doing --- > > Here are some things I know I am planning on doing: > > * Determining if a file tests differently than the previous revision. > > Combining this with the saving of terminal output is, IMHO, a fairly > robust way to locate errors and be testing suite agnostic. Basically, > there will be another column that says "Changed?" and whether the > output has changed. This is will be the basis of the "nag" emails with > some heuristics to avoid unnecessary naggery. > > For example, if the file you just edited in the commit displays > something different, it won't consider it any error if it always > displayed something in that way. For example, if X.ss never printed > anything on stderr than it will nag if it starts to even though you > just edited it. However, if X.ss always printed on stderr, it won't > nag if it prints something different. Obviously these heuristics will > be very fluid. > > * Using Subversion properties to set the timeout on a per-file basis > > This will help the build not wait for ever for DrScheme, as it won't > complete. By including it in Subversion, it will be versioned with the > file, so the metadata is not in a magical place on the server. > > * Using Subversion properties to set the command-line options and > execution program > > Most of the files can be run in mzscheme, but about 1000 need to be > run in mred. Also, many files (particular in > collects/tests/mzscheme/benchmarks) need command-line arguments to run > properly. This will include an option to ignore files. The default > will be that if a file ends in .ss, .scm, or .scrbl then mzscheme -t > will do it. Again, if these are in Subversion, then it is more > transparent and trackable what the test server should be doing. > > [I will set the initial version of these properties; no need to > worry about it] > > * Jump to output changes on first page > > * Emitting the status of a build on twitter > > * Nag emails to committer and plt:responsible > > * Client-side sorting of directory listings > > * Eventually I'd like to do two different kinds of builds: A "fast" > build that uses the previous slow build, but updates to the next > version and perhaps does some sort of dependency heuristic to not run > everything. A "clean" build corresponding to this. The goal would be > that the fast build would be done within 30 minutes, but the clean > would be available in a few hours. > > --- Some Data --- > > It took 7.34 hours to do the build on my Macbook in power save mode. > At the average of 8 commits per day, this is too slow to keep up with > the edge, but perhaps a better machine will do better. I currently > don't even run test two files at once. (I could because I have dual > CPUs on the laptop.) Plus with better timeouts I could shave off > almost 5 hours. > > It took 500MBs of space for the source & compiled source. > > It took 18MBs for the output logs. > > The UI takes 20MBs. > > There were 20 files that were created in `pwd`. (Most of them with > bizarre names.) > > There were 20 PLaneT packages installed. > > -- > Jay McCarthy > Assistant Professor / Brigham Young University > http://teammccarthy.org/jay > > "The glory of God is Intelligence" - D&C 93 > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From eli at barzilay.org Fri May 29 10:23:59 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri May 29 10:24:22 2009 Subject: [plt-dev] Continuous Integration Server In-Reply-To: References: Message-ID: <18975.61439.690648.440880@winooski.ccs.neu.edu> On May 28, Matthias Felleisen wrote: > > 2. Your emails could include svn pset commands for setting/changing > properties that you think may be appropriate to improve your > software's behavior. (For example, if some file times out, your > nagger could include a command to set the time out property low > because I know that it's useless to wait or something like that.) Actually that's a good idea for all breakages: once something breaks, you can make it continue sending the alerts -- and the way to get rid of them is to either fix it, or if it's expected, then record it on an svn property. And for even greater convenience (both for committers and for you as the one who will need to fix things up) -- don't tell people what to set, but make the web interface do that instead. This approach does make the properties strategy work out nicely. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From neil at neilvandyke.org Fri May 29 21:44:10 2009 From: neil at neilvandyke.org (Neil Van Dyke) Date: Fri May 29 21:44:36 2009 Subject: [plt-dev] documentation slowing down installs and builds dramatically Message-ID: <4A208F6A.1000405@neilvandyke.org> Subjectively, it seems like the 4.x documentation has made builds and PLaneT installs many times slower than with 3xx. For me, optimizing these documentation updates is the improvement I'd most like to see in PLT Scheme next. Thanks, Neil -- http://www.neilvandyke.org/ From eric.hanchrow at gmail.com Fri May 29 21:47:03 2009 From: eric.hanchrow at gmail.com (Eric Hanchrow) Date: Fri May 29 21:47:21 2009 Subject: [plt-dev] documentation slowing down installs and builds dramatically In-Reply-To: <4A208F6A.1000405@neilvandyke.org> References: <4A208F6A.1000405@neilvandyke.org> Message-ID: <36366a980905291847j60b7334ch20a8cf291fba14b3@mail.gmail.com> On Fri, May 29, 2009 at 6:44 PM, Neil Van Dyke wrote: > For me, optimizing these documentation updates is the improvement I'd most > like to see in PLT Scheme next. Hear, hear. From jay.mccarthy at gmail.com Sat May 30 00:15:12 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Sat May 30 00:15:36 2009 Subject: [plt-dev] Continuous Integration Server In-Reply-To: <18975.61439.690648.440880@winooski.ccs.neu.edu> References: <18975.61439.690648.440880@winooski.ccs.neu.edu> Message-ID: Good ideas. I'll definitely do this, starting with the pset lines in the email. Also, for the meta-data I think I will go with a single file for all old revisions, but I will inspect svn properties for overrides on that going forward. That will make the history useful and have a lot of good defaults without having a ton of property edits right now. Jay On Fri, May 29, 2009 at 8:23 AM, Eli Barzilay wrote: > On May 28, Matthias Felleisen wrote: >> >> 2. Your emails could include svn pset commands for setting/changing >> properties that you think may be appropriate to improve your >> software's behavior. (For example, if some file times out, your >> nagger could include a command to set the time out property low >> because I know that it's useless to wait or something like that.) > > Actually that's a good idea for all breakages: once something breaks, > you can make it continue sending the alerts -- and the way to get rid > of them is to either fix it, or if it's expected, then record it on an > svn property. ?And for even greater convenience (both for committers > and for you as the one who will need to fix things up) -- don't tell > people what to set, but make the web interface do that instead. ?This > approach does make the properties strategy work out nicely. > > -- > ? ? ? ? ?((lambda (x) (x x)) (lambda (x) (x x))) ? ? ? ? ?Eli Barzilay: > ? ? ? ? ? ? ? ? ?http://www.barzilay.org/ ? ? ? ? ? ? ? ? Maze is Life! > -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From eli at barzilay.org Sat May 30 00:25:41 2009 From: eli at barzilay.org (Eli Barzilay) Date: Sat May 30 00:26:02 2009 Subject: [plt-dev] Continuous Integration Server In-Reply-To: References: <18975.61439.690648.440880@winooski.ccs.neu.edu> Message-ID: <18976.46405.919580.767645@winooski.ccs.neu.edu> On May 29, Jay McCarthy wrote: > Good ideas. I'll definitely do this, starting with the pset lines in > the email. > > Also, for the meta-data I think I will go with a single file for all > old revisions, but I will inspect svn properties for overrides on > that going forward. That will make the history useful and have a lot > of good defaults without having a ton of property edits right now. FWIW, I think that doing both can be more difficult, unless you're careful to make the single file version have a direct way to correspond to properties. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From matthias at ccs.neu.edu Sat May 30 14:17:25 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Sat May 30 14:18:24 2009 Subject: [plt-dev] weird error; contracts for xml error Message-ID: <3143D966-520E-40E4-8B66-4F7538D5FD40@ccs.neu.edu> 1. what does this really mean: > Making Web pages in /Users/matthias/0Unison/0Web/ > link: module mismatch, probably from old bytecode whose > dependencies have changed: variable not provided (directly or > indirectly and at the expected position) from module: "/Users/ > matthias/plt/collects/xml/private/reader.ss" accessed from module: > "/Users/matthias/plt/collects/wxme/xml.ss" at source phase level: 0 > in: provide/contract-contract-id-read-xml.2 This happened right after I ran setup-plt -l xml. 2. here is a contract error, which I believes illustrates the "pressure of contracts" conjecture: > Making Web pages in /Users/matthias/0Unison/0Web/107-f08/ > (file "/Users/matthias/plt/collects/xml/private/reader.ss") broke > the contract > (-> > (or/c location? symbol? #f) > (or/c location? symbol? #f) > symbol? > (or/c permissive/c string?) > attribute?) > on make-attribute; not in permissive mode So this seems to mean a (permissive? #t) is missing from reader.ss. I added it and 'it works now' but I don't think that's the proper way to go about it. From robby at eecs.northwestern.edu Sat May 30 14:51:56 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Sat May 30 14:52:15 2009 Subject: [plt-dev] weird error; contracts for xml error In-Reply-To: <3143D966-520E-40E4-8B66-4F7538D5FD40@ccs.neu.edu> References: <3143D966-520E-40E4-8B66-4F7538D5FD40@ccs.neu.edu> Message-ID: <932b2f1f0905301151m6a74818aj5711fb5c1fd2edcc@mail.gmail.com> On Sat, May 30, 2009 at 1:17 PM, Matthias Felleisen wrote: > > 1. what does this really mean: > >> Making Web pages in /Users/matthias/0Unison/0Web/ >> link: module mismatch, probably from old bytecode whose dependencies have >> changed: variable not provided (directly or indirectly and at the expected >> position) from module: "/Users/matthias/plt/collects/xml/private/reader.ss" >> accessed from module: "/Users/matthias/plt/collects/wxme/xml.ss" at source >> phase level: 0 in: provide/contract-contract-id-read-xml.2 > > This happened right after I ran setup-plt -l xml. Probably you rebuilt the xml collection fine, but something that depended on it didn't get rebuilt. Robby From matthias at ccs.neu.edu Sat May 30 14:53:46 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Sat May 30 14:54:45 2009 Subject: [plt-dev] weird error; contracts for xml error In-Reply-To: <932b2f1f0905301151m6a74818aj5711fb5c1fd2edcc@mail.gmail.com> References: <3143D966-520E-40E4-8B66-4F7538D5FD40@ccs.neu.edu> <932b2f1f0905301151m6a74818aj5711fb5c1fd2edcc@mail.gmail.com> Message-ID: <1B65CE74-F41C-4582-96E5-59B60264EB6F@ccs.neu.edu> Yes, I discovered this right after sending the email. Specifically the wxme collection depends on the xml collection and blew up. Sorry for including spam in the report. On May 30, 2009, at 2:51 PM, Robby Findler wrote: > On Sat, May 30, 2009 at 1:17 PM, Matthias Felleisen > wrote: >> >> 1. what does this really mean: >> >>> Making Web pages in /Users/matthias/0Unison/0Web/ >>> link: module mismatch, probably from old bytecode whose >>> dependencies have >>> changed: variable not provided (directly or indirectly and at the >>> expected >>> position) from module: "/Users/matthias/plt/collects/xml/private/ >>> reader.ss" >>> accessed from module: "/Users/matthias/plt/collects/wxme/xml.ss" >>> at source >>> phase level: 0 in: provide/contract-contract-id-read-xml.2 >> >> This happened right after I ran setup-plt -l xml. > > Probably you rebuilt the xml collection fine, but something that > depended on it didn't get rebuilt. > > Robby From jay.mccarthy at gmail.com Sat May 30 15:46:41 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Sat May 30 15:47:03 2009 Subject: [plt-dev] weird error; contracts for xml error In-Reply-To: <3143D966-520E-40E4-8B66-4F7538D5FD40@ccs.neu.edu> References: <3143D966-520E-40E4-8B66-4F7538D5FD40@ccs.neu.edu> Message-ID: On Sat, May 30, 2009 at 12:17 PM, Matthias Felleisen wrote: > > 1. what does this really mean: > >> Making Web pages in /Users/matthias/0Unison/0Web/ >> link: module mismatch, probably from old bytecode whose dependencies have >> changed: variable not provided (directly or indirectly and at the expected >> position) from module: "/Users/matthias/plt/collects/xml/private/reader.ss" >> accessed from module: "/Users/matthias/plt/collects/wxme/xml.ss" at source >> phase level: 0 in: provide/contract-contract-id-read-xml.2 > > This happened right after I ran setup-plt -l xml. > > 2. here is a contract error, which I believes illustrates the "pressure of > contracts" conjecture: > >> Making Web pages in /Users/matthias/0Unison/0Web/107-f08/ >> (file "/Users/matthias/plt/collects/xml/private/reader.ss") broke the >> contract >> ?(-> >> ? (or/c location? symbol? #f) >> ? (or/c location? symbol? #f) >> ? symbol? >> ? (or/c permissive/c string?) >> ? attribute?) >> ?on make-attribute; not in permissive mode > > So this seems to mean a (permissive? #t) is missing from reader.ss. I added > it and 'it works now' but I don't think that's the proper way to go about > it. I don't know what the pressure of contracts is, but the XML parameter permissive? is basically only used by the XML tool in DrScheme to put the special Scheme boxes inside of the XML behind the XML box. You should put it in _your_ code, not the XML collection if you need it to be in permissive mode. Jay -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From robby at eecs.northwestern.edu Sat May 30 15:59:23 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Sat May 30 15:59:44 2009 Subject: [plt-dev] weird error; contracts for xml error In-Reply-To: References: <3143D966-520E-40E4-8B66-4F7538D5FD40@ccs.neu.edu> Message-ID: <932b2f1f0905301259i672f7ebfgf0823ea58fe9a221@mail.gmail.com> On Sat, May 30, 2009 at 2:46 PM, Jay McCarthy wrote: > On Sat, May 30, 2009 at 12:17 PM, Matthias Felleisen > wrote: >> >> 1. what does this really mean: >> >>> Making Web pages in /Users/matthias/0Unison/0Web/ >>> link: module mismatch, probably from old bytecode whose dependencies have >>> changed: variable not provided (directly or indirectly and at the expected >>> position) from module: "/Users/matthias/plt/collects/xml/private/reader.ss" >>> accessed from module: "/Users/matthias/plt/collects/wxme/xml.ss" at source >>> phase level: 0 in: provide/contract-contract-id-read-xml.2 >> >> This happened right after I ran setup-plt -l xml. >> >> 2. here is a contract error, which I believes illustrates the "pressure of >> contracts" conjecture: >> >>> Making Web pages in /Users/matthias/0Unison/0Web/107-f08/ >>> (file "/Users/matthias/plt/collects/xml/private/reader.ss") broke the >>> contract >>> ?(-> >>> ? (or/c location? symbol? #f) >>> ? (or/c location? symbol? #f) >>> ? symbol? >>> ? (or/c permissive/c string?) >>> ? attribute?) >>> ?on make-attribute; not in permissive mode >> >> So this seems to mean a (permissive? #t) is missing from reader.ss. I added >> it and 'it works now' but I don't think that's the proper way to go about >> it. > > I don't know what the pressure of contracts is, It is when adding one contract to (say) my module forces you to a contract your module in order to shift the blame on to the next guy. It is a way in which contracts infect a codebase. Robby > but the XML parameter > permissive? is basically only used by the XML tool in DrScheme to put > the special Scheme boxes inside of the XML behind the XML box. You > should put it in _your_ code, not the XML collection if you need it to > be in permissive mode. > > Jay > > -- > Jay McCarthy > Assistant Professor / Brigham Young University > http://teammccarthy.org/jay > > "The glory of God is Intelligence" - D&C 93 > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > From matthias at ccs.neu.edu Sat May 30 17:38:27 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Sat May 30 17:39:10 2009 Subject: [plt-dev] weird error; contracts for xml error In-Reply-To: References: <3143D966-520E-40E4-8B66-4F7538D5FD40@ccs.neu.edu> Message-ID: <5EC5B046-2ED9-4489-BC8F-1140AC223A08@ccs.neu.edu> On May 30, 2009, at 3:46 PM, Jay McCarthy wrote: >> here is a contract error, which I believes illustrates the >> "pressure of >> contracts" conjecture: >> >>> Making Web pages in /Users/matthias/0Unison/0Web/107-f08/ >>> (file "/Users/matthias/plt/collects/xml/private/reader.ss") broke >>> the >>> contract >>> (-> >>> (or/c location? symbol? #f) >>> (or/c location? symbol? #f) >>> symbol? >>> (or/c permissive/c string?) >>> attribute?) >>> on make-attribute; not in permissive mode >> >> So this seems to mean a (permissive? #t) is missing from >> reader.ss. I added >> it and 'it works now' but I don't think that's the proper way to >> go about >> it. > > I don't know what the pressure of contracts is, but the XML parameter > permissive? is basically only used by the XML tool in DrScheme to put > the special Scheme boxes inside of the XML behind the XML box. You > should put it in _your_ code, not the XML collection if you need it to > be in permissive mode --> Robby explained the principle, so let me apply it to this situation: I wrote a script that traverses a large directory tree and dynamically requires an index.ss files in each directory if it finds one. I am guessing this means two or three dozen files of between 100 and 500 lines of code. One of those invocations raised an error and blamed your module. My conjecture was what you responded with. Somehow I should set the permissive flag when the xml library is required. BUT nevertheless the way you wrote the contract, you got blamed, meaning you should protect your library better with an "entry" contract so that your "exit" contract doesn't trigger the exception. --> I naturally first looked up permissive (and was surprised to find something). Then I ran (permissive? #t) in the module that requires yours --- but the contract failure didn't go away. So I moved that expression to your module and voila things went thru. I do not know what went wrong with setting the permissive parameter in my module. And I don't have time to find out. --> One minor thing: I suggest not using a "?" at the end of the name for a parameter. ? suggests a predicate and it's difficult to get used to the idea that it isn't. -- Matthias From neil at neilvandyke.org Sun May 31 00:14:59 2009 From: neil at neilvandyke.org (Neil Van Dyke) Date: Sun May 31 00:15:31 2009 Subject: [plt-dev] documentation slowing down installs and builds dramatically In-Reply-To: <36366a980905291847j60b7334ch20a8cf291fba14b3@mail.gmail.com> References: <4A208F6A.1000405@neilvandyke.org> <36366a980905291847j60b7334ch20a8cf291fba14b3@mail.gmail.com> Message-ID: <4A220443.9050107@neilvandyke.org> I have a fresh anecdote of practical impact of the slow documentation crunching. The first bit of code I try to run from the Snooze tutorial takes over 9 minutes on a fast computer, before it attempts to connect to the database. It installs a lot of small PLaneT packages in these 9+ minutes, and seems to spend most of that time crunching documentation. (That's with reasonably fast Internet, PLTCOLLECTS unset, DrScheme memory limit off, lots of RAM, and no swap space in use, otherwise idle 2GHz dual-core, on Linux.) -- http://www.neilvandyke.org/ From jos.koot at telefonica.net Sun May 31 05:00:04 2009 From: jos.koot at telefonica.net (Jos Koot) Date: Sun May 31 05:00:27 2009 Subject: [plt-dev] full-4.2.0.2 May 27 problem Message-ID: When starting DrScheme version full-4.2.0.2 May 27, I get: default-load-handler: cannot open input file: "C:\var\tmp\plt\collects\typed-scheme\utils\tc-utils.ss" File cannot be found, errno 3 Jos -------------- next part -------------- An HTML attachment was scrubbed... URL: http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090531/dc2be98d/attachment.htm From czhu at cs.utah.edu Sun May 31 05:47:24 2009 From: czhu at cs.utah.edu (Chongkai Zhu) Date: Sun May 31 05:47:54 2009 Subject: [plt-dev] full-4.2.0.2 May 27 problem In-Reply-To: References: Message-ID: <4A22522C.5040707@cs.utah.edu> I got the same problem for plt-4.2.0.2-bin-i386-win32, and solve it by copy the whole plt directory into "C:\var\tmp\plt\" Chongkai Jos Koot wrote: > When starting DrScheme version full-4.2.0.2 May 27, I get: > default-load-handler: > cannot open input file: > "C:\var\tmp\plt\collects\typed-scheme\utils\tc-utils.ss" > File cannot be found, errno 3 > > Jos > ------------------------------------------------------------------------ > > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev > From jos.koot at telefonica.net Sun May 31 05:58:14 2009 From: jos.koot at telefonica.net (Jos Koot) Date: Sun May 31 05:59:12 2009 Subject: [plt-dev] full-4.2.0.2 May 27 problem References: <4A22522C.5040707@cs.utah.edu> Message-ID: Thanks, that will do for a while. Jos ----- Original Message ----- From: "Chongkai Zhu" To: "Jos Koot" Cc: Sent: Sunday, May 31, 2009 11:47 AM Subject: Re: [plt-dev] full-4.2.0.2 May 27 problem >I got the same problem for plt-4.2.0.2-bin-i386-win32, and solve it by > copy the whole plt directory into "C:\var\tmp\plt\" > > Chongkai > > Jos Koot wrote: >> When starting DrScheme version full-4.2.0.2 May 27, I get: >> default-load-handler: >> cannot open input file: >> "C:\var\tmp\plt\collects\typed-scheme\utils\tc-utils.ss" >> File cannot be found, errno 3 >> >> Jos >> ------------------------------------------------------------------------ >> >> _________________________________________________ >> For list-related administrative tasks: >> http://list.cs.brown.edu/mailman/listinfo/plt-dev >> > >