From anton at mips.complang.tuwien.ac.at Mon Nov 2 15:50:51 2009 From: anton at mips.complang.tuwien.ac.at (Anton Ertl) Date: Mon Nov 2 16:29:43 2009 Subject: [plt-dev] Build problems Message-ID: I plan to work on adding more ports to stuff like GNU Lightning using a semi-automatic techniques, and MzScheme looks like a good testbed for that (is it?). The benefit for MzScheme would be that it would get additional JIT ports. So I first tried to build mz-4.2.2 (and then 4.2.2.4, but no change) on an bunch of machines. It worked nicely on a IA32 Debian Sarge system (gcc-3.3.5), but I had trouble on the other systems. I will investigate these problems myself, but if this rings a bell for you, I would be glad for a hint. Thanks in advance, - anton On a PowerPC (shown here) and AMD64 system running Debian Lenny (gcc-4.3.2) I see: make[7]: Entering directory `/localtmp/mz-4.2.2.4/src/build/foreign' gcc -g -O2 -Wall -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I./../mzscheme -I../../foreign/../mzscheme/include -I../../foreign/../mzscheme/src -Igcc/libffi/include -c ../../foreign/foreign.c -o foreign.o In file included from ../../foreign/../mzscheme/include/scheme.h:127, from ../../foreign/../mzscheme/src/schpriv.h:21, from ../../foreign/foreign.c:9: /usr/include/stdio.h:34:21: error: stddef.h: No such file or directory In file included from /usr/include/stdio.h:75, from ../../foreign/../mzscheme/include/scheme.h:127, from ../../foreign/../mzscheme/src/schpriv.h:21, from ../../foreign/foreign.c:9: /usr/include/libio.h:53:21: error: stdarg.h: No such file or directory [and lots more, probably followup errors] Looks like the include path is broken. On an Alpha running Debian Etch (gcc-4.1.2) I eventually see: cd ..; gcc -o mzscheme3m gc2/main.o libmzscheme3m.a -ldl -lm -ldl -lm -rdynamic libmzscheme3m.a(gmp.o): In function `scheme_gmpn_mod_1': ../../../mzscheme/src/gmp/gmp.c:4444: undefined reference to `scheme_gmpn_count_leading_zeros' ../../../mzscheme/src/gmp/gmp.c:4444: undefined reference to `scheme_gmpn_count_leading_zeros' ../../../mzscheme/src/gmp/gmp.c:4469: undefined reference to `scheme_gmpn_invert_limb' ../../../mzscheme/src/gmp/gmp.c:4469: undefined reference to `scheme_gmpn_invert_limb' ../../../mzscheme/src/gmp/gmp.c:4411: undefined reference to `scheme_gmpn_invert_limb' ../../../mzscheme/src/gmp/gmp.c:4411: undefined reference to `scheme_gmpn_invert_limb' libmzscheme3m.a(gmp.o): In function `scheme_gmpn_gcd_1': ../../../mzscheme/src/gmp/gmp.c:4507: undefined reference to `scheme_gmpn_count_leading_zeros' ../../../mzscheme/src/gmp/gmp.c:4507: undefined reference to `scheme_gmpn_count_leading_zeros' ../../../mzscheme/src/gmp/gmp.c:4528: undefined reference to `scheme_gmpn_count_leading_zeros' ../../../mzscheme/src/gmp/gmp.c:4528: undefined reference to `scheme_gmpn_count_leading_zeros' ../../../mzscheme/src/gmp/gmp.c:4516: undefined reference to `scheme_gmpn_count_leading_zeros' libmzscheme3m.a(gmp.o):../../../mzscheme/src/gmp/gmp.c:4516: more undefined references to `scheme_gmpn_count_leading_zeros' follow libmzscheme3m.a(gmp.o): In function `scheme_gmpn_divrem_2': ../../../mzscheme/src/gmp/gmp.c:3710: undefined reference to `scheme_gmpn_invert_limb' ../../../mzscheme/src/gmp/gmp.c:3710: undefined reference to `scheme_gmpn_invert_limb' ../../../mzscheme/src/gmp/gmp.c:3674: undefined reference to `scheme_gmpn_invert_limb' ../../../mzscheme/src/gmp/gmp.c:3674: undefined reference to `scheme_gmpn_invert_limb' libmzscheme3m.a(gmp.o): In function `__gmpn_divmod_1_internal': ../../../mzscheme/src/gmp/gmp.c:3512: undefined reference to `scheme_gmpn_count_leading_zeros' ../../../mzscheme/src/gmp/gmp.c:3512: undefined reference to `scheme_gmpn_count_leading_zeros' ../../../mzscheme/src/gmp/gmp.c:3529: undefined reference to `scheme_gmpn_invert_limb' ../../../mzscheme/src/gmp/gmp.c:3529: undefined reference to `scheme_gmpn_invert_limb' ../../../mzscheme/src/gmp/gmp.c:3535: undefined reference to `scheme_gmpn_invert_limb' ../../../mzscheme/src/gmp/gmp.c:3535: undefined reference to `scheme_gmpn_invert_limb' libmzscheme3m.a(gmp.o): In function `scheme_gmpn_divrem_1': ../../../mzscheme/src/gmp/gmp.c:3593: undefined reference to `scheme_gmpn_count_leading_zeros' ../../../mzscheme/src/gmp/gmp.c:3593: undefined reference to `scheme_gmpn_count_leading_zeros' ../../../mzscheme/src/gmp/gmp.c:3600: undefined reference to `scheme_gmpn_invert_limb' ../../../mzscheme/src/gmp/gmp.c:3600: undefined reference to `scheme_gmpn_invert_limb' ../../../mzscheme/src/gmp/gmp.c:3610: undefined reference to `scheme_gmpn_invert_limb' ../../../mzscheme/src/gmp/gmp.c:3610: undefined reference to `scheme_gmpn_invert_limb' libmzscheme3m.a(gmp.o): In function `__gmpn_divmod_1_internal': ../../../mzscheme/src/gmp/gmp.c:3449: undefined reference to `scheme_gmpn_count_leading_zeros' ../../../mzscheme/src/gmp/gmp.c:3449: undefined reference to `scheme_gmpn_count_leading_zeros' ../../../mzscheme/src/gmp/gmp.c:3558: undefined reference to `scheme_gmpn_invert_limb' ../../../mzscheme/src/gmp/gmp.c:3558: undefined reference to `scheme_gmpn_invert_limb' ../../../mzscheme/src/gmp/gmp.c:3484: undefined reference to `scheme_gmpn_invert_limb' ../../../mzscheme/src/gmp/gmp.c:3484: undefined reference to `scheme_gmpn_invert_limb' ../../../mzscheme/src/gmp/gmp.c:3455: undefined reference to `scheme_gmpn_invert_limb' libmzscheme3m.a(gmp.o):../../../mzscheme/src/gmp/gmp.c:3455: more undefined references to `scheme_gmpn_invert_limb' follow libmzscheme3m.a(gmp.o): In function `mpn_sb_get_str': ../../../mzscheme/src/gmp/gmp.c:1905: undefined reference to `scheme_gmpn_count_leading_zeros' ../../../mzscheme/src/gmp/gmp.c:1905: undefined reference to `scheme_gmpn_count_leading_zeros' libmzscheme3m.a(gmp.o): In function `scheme_gmpn_sb_divrem_mn': ../../../mzscheme/src/gmp/gmp.c:3337: undefined reference to `scheme_gmpn_invert_limb' ../../../mzscheme/src/gmp/gmp.c:3337: undefined reference to `scheme_gmpn_invert_limb' ../../../mzscheme/src/gmp/gmp.c:3286: undefined reference to `scheme_gmpn_invert_limb' ../../../mzscheme/src/gmp/gmp.c:3286: undefined reference to `scheme_gmpn_invert_limb' libmzscheme3m.a(gmp.o): In function `scheme_gmpn_gcd': ../../../mzscheme/src/gmp/gmp.c:4913: undefined reference to `scheme_gmpn_count_leading_zeros' ../../../mzscheme/src/gmp/gmp.c:4913: undefined reference to `scheme_gmpn_count_leading_zeros' ../../../mzscheme/src/gmp/gmp.c:4916: undefined reference to `scheme_gmpn_count_leading_zeros' ../../../mzscheme/src/gmp/gmp.c:4916: undefined reference to `scheme_gmpn_count_leading_zeros' ../../../mzscheme/src/gmp/gmp.c:4939: undefined reference to `scheme_gmpn_count_leading_zeros' libmzscheme3m.a(gmp.o):../../../mzscheme/src/gmp/gmp.c:4939: more undefined references to `scheme_gmpn_count_leading_zeros' follow libmzscheme3m.a(gmp.o): In function `scheme_gmpn_tdiv_qr': ../../../mzscheme/src/gmp/gmp.c:2757: undefined reference to `scheme_gmpn_invert_limb' ../../../mzscheme/src/gmp/gmp.c:2757: undefined reference to `scheme_gmpn_invert_limb' libmzscheme3m.a(gmp.o): In function `scheme_gmpn_sqrtrem': ../../../mzscheme/src/gmp/gmp.c:3064: undefined reference to `scheme_gmpn_count_leading_zeros' ../../../mzscheme/src/gmp/gmp.c:3064: undefined reference to `scheme_gmpn_count_leading_zeros' libmzscheme3m.a(gmp.o): In function `scheme_gmpn_get_str': ../../../mzscheme/src/gmp/gmp.c:2040: undefined reference to `scheme_gmpn_count_leading_zeros' ../../../mzscheme/src/gmp/gmp.c:2040: undefined reference to `scheme_gmpn_count_leading_zeros' collect2: ld returned 1 exit status From robby at eecs.northwestern.edu Tue Nov 3 12:37:03 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Tue Nov 3 12:37:21 2009 Subject: [plt-dev] Fwd: [plt-scheme] Download links in PLaneT In-Reply-To: <779bf2730910281318j12a53bc5qd2967d3947104e95@mail.gmail.com> References: <595b9ab20910090612q98420e4g8c05fef3acaf67da@mail.gmail.com> <990e0c030910130909y7738efb8l16989c2a5fe6f85a@mail.gmail.com> <990e0c030910130915o1fa12466vb2d1a6a96981ce67@mail.gmail.com> <779bf2730910131314j17749365g4fb5cc699ee297de@mail.gmail.com> <779bf2730910281140u1180b614uf0c541832fa853e@mail.gmail.com> <932b2f1f0910281233m57fa76a9l49fa10d14e8a644e@mail.gmail.com> <779bf2730910281249p5b82acf9p2ae78188750a6a43@mail.gmail.com> <932b2f1f0910281258r39c95093l66f50c0005d1e31@mail.gmail.com> <779bf2730910281318j12a53bc5qd2967d3947104e95@mail.gmail.com> Message-ID: <932b2f1f0911030937s18f9bc6do859c9b27826ea2ef@mail.gmail.com> Well, after some more thought, I've decided I was being stupid. I've checked (essentially) your patch (revision 16521 in SVN). If I sort out some other superduperfancydancy thing in the future, I'll be sure to let you know. Sorry for the wait and I hope you've not lost steam. Robby On Wed, Oct 28, 2009 at 2:18 PM, YC wrote: > > On Wed, Oct 28, 2009 at 12:58 PM, Robby Findler > wrote: >> >> No, I'm not seeing what I recalled, either. Sorry. > > No worries. > >> >> As far as your patch goes, I'm not sure that's the best long term >> solution and I'm not sure I want to support that going forward. Given >> how easy it is to apply that patch to your own system, perhaps that's >> the best thing to do for now? > > My plan was to release a mirror tool as a planet package so others can setup > their own mirrors as well.? I agree that this might not be the long term > solution, but without having something in place such package does not make > sense for others, so I guess that would have to be delayed unless you want > to accept the patch interim or until we found a solution you can accept. > >> >> I do plan to give some thought to adding redundancy to the planet >> server to avoid outages but I've just not had a chance to really spend >> quality time on it. If you are willing to spend sometime sorting out >> the server side issues and put something together that's a bit more >> comprehensive, I'd be willing to help with it, as I have time (and to >> put it into planet itself, of course). > > I am happy to help out here.? If you can let me know what sort of server > side issues that you are thinking about (I more or less got the mirror & > proxy figured out - just need to implement it) then we can collaborate. > > Thanks, > yc > > From yinso.chen at gmail.com Tue Nov 3 13:23:54 2009 From: yinso.chen at gmail.com (YC) Date: Tue Nov 3 13:24:13 2009 Subject: [plt-dev] Fwd: [plt-scheme] Download links in PLaneT In-Reply-To: <932b2f1f0911030937s18f9bc6do859c9b27826ea2ef@mail.gmail.com> References: <595b9ab20910090612q98420e4g8c05fef3acaf67da@mail.gmail.com> <990e0c030910130915o1fa12466vb2d1a6a96981ce67@mail.gmail.com> <779bf2730910131314j17749365g4fb5cc699ee297de@mail.gmail.com> <779bf2730910281140u1180b614uf0c541832fa853e@mail.gmail.com> <932b2f1f0910281233m57fa76a9l49fa10d14e8a644e@mail.gmail.com> <779bf2730910281249p5b82acf9p2ae78188750a6a43@mail.gmail.com> <932b2f1f0910281258r39c95093l66f50c0005d1e31@mail.gmail.com> <779bf2730910281318j12a53bc5qd2967d3947104e95@mail.gmail.com> <932b2f1f0911030937s18f9bc6do859c9b27826ea2ef@mail.gmail.com> Message-ID: <779bf2730911031023ye28c2f4m8cb2e5461ea17b65@mail.gmail.com> No problem Robby - I was just about to ask how things are doing. Thanks for applying the patch. yc On Tue, Nov 3, 2009 at 10:37 AM, Robby Findler wrote: > Well, after some more thought, I've decided I was being stupid. I've > checked (essentially) your patch (revision 16521 in SVN). If I sort > out some other superduperfancydancy thing in the future, I'll be sure > to let you know. > > Sorry for the wait and I hope you've not lost steam. > > Robby > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://list.cs.brown.edu/pipermail/plt-dev/attachments/20091103/67e8cd97/attachment.htm From jos.koot at telefonica.net Wed Nov 4 13:06:04 2009 From: jos.koot at telefonica.net (Jos Koot) Date: Wed Nov 4 13:12:02 2009 Subject: [plt-dev] promises and srfi 41 Message-ID: <89EAC617A2034EE69B42FEB0C618F90C@uw2b2dff239c4d> Hi, It has been some time ago (may be a year) that I adapted Phil Bewig's srfi 41 for PLT. You did not like me duplicating the code for promises. I don't like it either. However, in order to discriminate streams from other promises without duplication of promises.ss, I need a means to make a subtype of promises. The only thing I need for that is that the promise struct descriptor is exported from promise.ss and dependent modules (e.g. scheme scheme/base). Without the ability to make a subtype of promises it is not possible to implement function =stream?=. Without this function many argument checks become faulty. Would you be inclined to export the promise struct descriptor (or any other means for the definition of subtypes of promises) in mzscheme, scheme and scheme/base? As far as I can see, wrapping stream promises in another struct type poses problems to memory bound execution of examples that should be memory bound. I am not sure, but I assume that using a subtype does not imply an extra layer of dereference. This is crucial, of course. With the aforementioned tool, I can simplify PLT's implementation of srfi 41 considerably. I also intend to expose stream-lazy to the user (which is much simpler than providing additional binding constructs (stream-lamdba, stream-let, etc) The binding constructs required by srfi 41 will be maintained, of course. Hoping all is well with you and your family, Jos. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://list.cs.brown.edu/pipermail/plt-dev/attachments/20091104/215d1248/attachment.htm From cce at ccs.neu.edu Wed Nov 4 16:44:06 2009 From: cce at ccs.neu.edu (Carl Eastlund) Date: Wed Nov 4 16:44:45 2009 Subject: [plt-dev] Generated files and co-existing copies of DrScheme Message-ID: <990e0c030911041344tfa68c40gf2b9e32c098f6c8c@mail.gmail.com> Currently there are a few headaches when one tries to keep concurrent copies of DrScheme on one machine, and I'd like to eliminate some of them. Essentially, problems of one sort or another arise when two different copies of DrScheme both try to "own" the same set of generated files. The end result is that one copy of DrScheme ends up reading files generated by the other, and the results become inconsistent (usually a compilation error or inconsistent documentation). Currently, I know of four categories of files generated by DrScheme: the user preferences file, the planet cache, user-specific Scribble documentation, and ZOs for user programs (including, and especially, planet development links). The user preferences file is fine -- I really only want one copy of that. The planet cache can be dealt with: the PLTPLANETDIR environment variable overrides its default location. This is the kind of configuration I am looking for in general. Currently, generated Scribble documentation files go in a default (platform-specific) place, and cannot be overridden. As a result, if I have two copies of 4.2.1.5, but with different planet packages installed, my documentation will reflect only one or the other; Help Desk in one of them will be wrong. I'd like control over Scribble index placement similar to the PLTPLANETDIR environment variable. Generated files (e.g. compiled/ and doc/ subdirectories) for user code go in whatever directory the user code lives in. Again, as a result, if I have code for a planet package, I can try it out in one copy of DrScheme, but the minute I load another, it tries to read the .zo files generated by the other and runs into problems (a compilation error if different version numbers, goodness knows what behavior if the same). If there were an option to store these files in a user-specific location (e.g. store all .zos in ~/.plt-scheme/compiled, or at least store development link generated files in ~/.plt-scheme/planet/devel), development code could be reusable across different copies of DrScheme. It seems to me that resolving the issue for Scribble files, at least, should be straightforward. We could institute either a PLTSCRIBBLEDIR variable for placement of the Scribble index, or PLTUSERDIR that overrides the common parent directory of Scribble and Planet installation. I prefer the latter, since it would generalize to include any other kind of generated file we come up with in the future (or any current ones I've forgotten about). I would also like to pick a conventional place in the PLT tree to store this PLTUSERDIR at (similar to /src/build for the results of 'make') and set up a 'svn:ignore' property for it. That way, just as removing an old PLT trunk checkout cleans up its build/ tree, it would also clean up planet/ and doc/ trees that are no longer needed. The development link issue is trickier -- it's not a matter of just setting up one environment variable to replace one (or maybe two, or some small fixed N) hard-coded strings, but rather changing a compilation policy for a subset of code. I don't have a concrete proposal here, but it's been brought up before and is a headache so I wanted to bring up the issue for discussion. Does anyone have a good idea how to handle this one? That's a bunch of issues, and three proposals: (1) set up PLTUSERDIR to control placement of Planet and Scribble generated files, (2) pick a conventional place in the PLT tree for users to store it who can and wish to do so, and (3) longer term, think about a way to fit development link code into this story. So -- what do the rest of you developer folks think? Carl Eastlund From ryanc at ccs.neu.edu Fri Nov 6 18:46:51 2009 From: ryanc at ccs.neu.edu (Ryan Culpepper) Date: Fri Nov 6 18:47:15 2009 Subject: [plt-dev] a common collection for utility modules Message-ID: I propose to add a new collection called "unstable" to serve as a place to put small libraries that might be of general use but either don't fit or aren't ready for any of the existing locations. For example, a graph traversal algorithm using an idiosyncratic list-based graph representation doesn't fit in scheme/list, and it isn't significant or general enough to justify creating scheme/graph. But it might be useful to more than the one module that currently uses it. There are 62 files in the collection tree ending in either "util.ss" or "utils.ss". At least some of that code must be useful to more than one client. The name "unstable" is intended as a warning that the *interfaces* in particular are unstable. Developers of planet packages and external projects should avoid using modules in the unstable collection. Contracts may change, names may change or disappear, even entire modules may move or disappear without warning to the outside world. Of course, people who make changes to modules in unstable must fix up any uses within the collections tree. I hope the unstable collection will lead to more code sharing. I also hope that it will be a place to hash out interfaces and get implementations Just Right before promoting code to the major leagues^W collections. Not for all code, just for code that doesn't immediately fit in anywhere else. Ryan From carl.eastlund at gmail.com Fri Nov 6 18:51:28 2009 From: carl.eastlund at gmail.com (Carl Eastlund) Date: Fri Nov 6 18:52:07 2009 Subject: [plt-dev] a common collection for utility modules In-Reply-To: References: Message-ID: <990e0c030911061551v2035e90ak530d4cd02b620792@mail.gmail.com> On Fri, Nov 6, 2009 at 6:46 PM, Ryan Culpepper wrote: > I propose to add a new collection called "unstable" to serve as a place to > put small libraries that might be of general use but either don't fit or > aren't ready for any of the existing locations. For example, a graph > traversal algorithm using an idiosyncratic list-based graph representation > doesn't fit in scheme/list, and it isn't significant or general enough to > justify creating scheme/graph. But it might be useful to more than the one > module that currently uses it. > > There are 62 files in the collection tree ending in either "util.ss" or > "utils.ss". At least some of that code must be useful to more than one > client. > > The name "unstable" is intended as a warning that the *interfaces* in > particular are unstable. Developers of planet packages and external projects > should avoid using modules in the unstable collection. Contracts may change, > names may change or disappear, even entire modules may move or disappear > without warning to the outside world. Of course, people who make changes to > modules in unstable must fix up any uses within the collections tree. > > I hope the unstable collection will lead to more code sharing. I also hope > that it will be a place to hash out interfaces and get implementations Just > Right before promoting code to the major leagues^W collections. Not for all > code, just for code that doesn't immediately fit in anywhere else. > > Ryan +1 --Carl From jay.mccarthy at gmail.com Fri Nov 6 21:26:47 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Fri Nov 6 21:27:08 2009 Subject: [plt-dev] a common collection for utility modules In-Reply-To: <990e0c030911061551v2035e90ak530d4cd02b620792@mail.gmail.com> References: <990e0c030911061551v2035e90ak530d4cd02b620792@mail.gmail.com> Message-ID: +1 On Sat, Nov 7, 2009 at 12:51 AM, Carl Eastlund wrote: > On Fri, Nov 6, 2009 at 6:46 PM, Ryan Culpepper wrote: >> I propose to add a new collection called "unstable" to serve as a place to >> put small libraries that might be of general use but either don't fit or >> aren't ready for any of the existing locations. For example, a graph >> traversal algorithm using an idiosyncratic list-based graph representation >> doesn't fit in scheme/list, and it isn't significant or general enough to >> justify creating scheme/graph. But it might be useful to more than the one >> module that currently uses it. >> >> There are 62 files in the collection tree ending in either "util.ss" or >> "utils.ss". At least some of that code must be useful to more than one >> client. >> >> The name "unstable" is intended as a warning that the *interfaces* in >> particular are unstable. Developers of planet packages and external projects >> should avoid using modules in the unstable collection. Contracts may change, >> names may change or disappear, even entire modules may move or disappear >> without warning to the outside world. Of course, people who make changes to >> modules in unstable must fix up any uses within the collections tree. >> >> I hope the unstable collection will lead to more code sharing. I also hope >> that it will be a place to hash out interfaces and get implementations Just >> Right before promoting code to the major leagues^W collections. Not for all >> code, just for code that doesn't immediately fit in anywhere else. >> >> Ryan > > +1 > > --Carl > _________________________________________________ > ?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 Fri Nov 6 21:53:05 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri Nov 6 21:53:26 2009 Subject: [plt-dev] a common collection for utility modules In-Reply-To: References: Message-ID: <19188.57617.399463.888129@winooski.ccs.neu.edu> -1, overall. Random points: * There was/is already mzlib/etc which wasn't successful. * I can't avoid thinking about (require unstable/foo) being similar to `from __future__ import foo'. (But you can also claim that this is a good point, being something that was already used.) * IIUC, you're talking about a relatively cheap way to having new library functions -- cheap in the sense that they won't be documented or tested, or at least not done so thoroughly. * Also, all of these libraries should come with a big warning of "can change at any time" -- but what happens when more code relies on them, and what if the person in charge of such code is not willing to put work in revising that code due to such change? * As a potential user of this, I like this part of your proposal: Of course, people who make changes to modules in unstable must fix up any uses within the collections tree. But as a potential contributor, this makes it more painful than adding a proper library. * IIUC, you want this to be able to use random pieces of code in the PLT tree, otherwise there's planet. * This means that there's an issue of distribution. For example, these libraries should not rely on mred/drscheme, or if there are parts that do rely on them, they should be easily identifiable. (This is a problem with distribution rules which is directly related to the future plan to split the distribution into a core an a bunch of additional libraries.) * Many of what could be there (eg, things that I would put in such a place) seems to me like it will end up staying there for years, because turning the code into a general library is non-trivial effort. This means a big pile of unrelated and unorganized code fragments that, which is taking the mzlib/etc thing to a higher level of being a PITA. * I was curious about having that many "util" files, so I went over them. It looks to me like only a small number of them could have generalizable parts. (List below, with `-' `+' and `?', and `?m' for a possible mred utils thing.) + games/cards/utils.ss + games/doors/private/utils.ss ? honu/private/util.ss ? mysterx/private/util.ss ? net/mime-util.ss ? schemeunit/text-ui-util.ss ? setup/private/path-utils.ss ? srfi/32/vector-util.scm ? web-server/lang/util.ss ?m framework/gui-utils.ss ?m framework/private/path-utils.ss ?m guibuilder/utils.ss - drscheme/private/embedded-snip-utils.ss - eopl/private/utils.ss - frtime/lang-utils.ss - games/doors/utils.ss - games/loa/utils.ss - games/pousse/utils.ss - handin-server/utils.ss - help/help-utils.ss - mzlib/private/sigutil.ss - mzlib/private/unit-utils.ss - parser-tools/private-lex/util.ss - planet/util.ss - preprocessor/pp-utils.ss - profile/utils.ss - redex/private/bitmap-test-util.ss - redex/private/lw-test-util.ss - redex/private/test-util.ss - schemeunit/text-ui-util-test.ss - schemeunit/util-test.ss - schemeunit/util.ss - scribble/private/manual-utils.ss - scribble/private/render-utils.ss - scribble/text/syntax-utils.ss - scribblings/foreign/utils.ss - scribblings/guide/contracts-utils.ss - scribblings/guide/guide-utils.ss - scribblings/inside/utils.ss - scribblings/main/private/utils.ss - scribblings/scribble/utils.ss - sirmail/utilr.ss - slideshow/private/utils.ss - srfi/1/util.ss - syntax/private/util.ss - texpict/utils.ss - typed-scheme/rep/rep-utils.ss - typed-scheme/types/utils.ss - typed-scheme/utils/... - typed/private/utils.ss - version/utils.ss - web-server/private/util.ss - web-server/scribblings/tutorial/tutorial-util.ss -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From carl.eastlund at gmail.com Fri Nov 6 22:11:17 2009 From: carl.eastlund at gmail.com (Carl Eastlund) Date: Fri Nov 6 22:11:55 2009 Subject: [plt-dev] a common collection for utility modules In-Reply-To: <19188.57617.399463.888129@winooski.ccs.neu.edu> References: <19188.57617.399463.888129@winooski.ccs.neu.edu> Message-ID: <990e0c030911061911h2860175cpa3fd57d3cdb243dc@mail.gmail.com> On Fri, Nov 6, 2009 at 9:53 PM, Eli Barzilay wrote: > -1, overall. > > Random points: > > * There was/is already mzlib/etc which wasn't successful. This is not quite the same as mzlib/etc, which was not so much an intentional development ground as a place for developed, published, ready-for-prime-time stuff that nevertheless had no "home". > * I can't avoid thinking about (require unstable/foo) being similar to > ?`from __future__ import foo'. ?(But you can also claim that this is > ?a good point, being something that was already used.) > > * IIUC, you're talking about a relatively cheap way to having new > ?library functions -- cheap in the sense that they won't be > ?documented or tested, or at least not done so thoroughly. I think stuff in unstable should be as documented and tested as anything else... well, at least as our somewhat new stuff. It need not have 100% polish but this isn't a place to just dash off a line of code and leave it sitting around. I see this as a place for stuff that is well developed, and used productively in at least one place, and that may be useful elsewhere, but which does has no consensus for an end-user interface (what library it goes in, what keyword arguments it uses, etc.) > * Also, all of these libraries should come with a big warning of "can > ?change at any time" -- but what happens when more code relies on > ?them, and what if the person in charge of such code is not willing > ?to put work in revising that code due to such change? Per Ryan's proposal, as you state below, someone who wants to make a change must be willing to do the propagation. If they're not, they have to leave the code as it is. So nothing should break. > * As a potential user of this, I like this part of your proposal: > > ? ?Of course, people who make changes to modules in unstable must fix > ? ?up any uses within the collections tree. > > ?But as a potential contributor, this makes it more painful than > ?adding a proper library. If you are committed to maintaining it, but want to make it other people's job to keep up, promote to a real library. If you are not committed, leave it in unstable. You are obligated to propagate fixes for any changes you make, but there is no prohibition against washing your hands of it and walking away *without* changing it. And once something is in unstable, anyone can pick it up and take charge if you walk away. > * IIUC, you want this to be able to use random pieces of code in the > ?PLT tree, otherwise there's planet. > > * This means that there's an issue of distribution. ?For example, > ?these libraries should not rely on mred/drscheme, or if there are > ?parts that do rely on them, they should be easily identifiable. > ?(This is a problem with distribution rules which is directly related > ?to the future plan to split the distribution into a core an a bunch > ?of additional libraries.) > > * Many of what could be there (eg, things that I would put in such a > ?place) seems to me like it will end up staying there for years, > ?because turning the code into a general library is non-trivial > ?effort. ?This means a big pile of unrelated and unorganized code > ?fragments that, which is taking the mzlib/etc thing to a higher > ?level of being a PITA. We already have a bunch of piles of unorganized code. At least this way there's some room for sharing, seeing each other's stuff, figuring out who wants what as a library, etc. And with multiple people picking over it, there's more chances for people to organize things, weed out dead code, etc. > * I was curious about having that many "util" files, so I went over > ?them. ?It looks to me like only a small number of them could have > ?generalizable parts. ?(List below, with `-' `+' and `?', and `?m' > ?for a possible mred utils thing.) I'm not sure "generalizable" is the (only) goal here. Some of these things are not exposed or documented, but may be useful to users (internal or external) as-is. > + games/cards/utils.ss > + games/doors/private/utils.ss > ? honu/private/util.ss > ? mysterx/private/util.ss > ? net/mime-util.ss > ? schemeunit/text-ui-util.ss > ? setup/private/path-utils.ss > ? srfi/32/vector-util.scm > ? web-server/lang/util.ss > ?m framework/gui-utils.ss > ?m framework/private/path-utils.ss > ?m guibuilder/utils.ss > - drscheme/private/embedded-snip-utils.ss > - eopl/private/utils.ss > - frtime/lang-utils.ss > - games/doors/utils.ss > - games/loa/utils.ss > - games/pousse/utils.ss > - handin-server/utils.ss > - help/help-utils.ss > - mzlib/private/sigutil.ss > - mzlib/private/unit-utils.ss > - parser-tools/private-lex/util.ss > - planet/util.ss > - preprocessor/pp-utils.ss > - profile/utils.ss > - redex/private/bitmap-test-util.ss > - redex/private/lw-test-util.ss > - redex/private/test-util.ss > - schemeunit/text-ui-util-test.ss > - schemeunit/util-test.ss > - schemeunit/util.ss > - scribble/private/manual-utils.ss > - scribble/private/render-utils.ss > - scribble/text/syntax-utils.ss > - scribblings/foreign/utils.ss > - scribblings/guide/contracts-utils.ss > - scribblings/guide/guide-utils.ss > - scribblings/inside/utils.ss > - scribblings/main/private/utils.ss > - scribblings/scribble/utils.ss > - sirmail/utilr.ss > - slideshow/private/utils.ss > - srfi/1/util.ss > - syntax/private/util.ss > - texpict/utils.ss > - typed-scheme/rep/rep-utils.ss > - typed-scheme/types/utils.ss > - typed-scheme/utils/... > - typed/private/utils.ss > - version/utils.ss > - web-server/private/util.ss > - web-server/scribblings/tutorial/tutorial-util.ss From eli at barzilay.org Fri Nov 6 22:26:52 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri Nov 6 22:27:13 2009 Subject: [plt-dev] a common collection for utility modules In-Reply-To: <990e0c030911061911h2860175cpa3fd57d3cdb243dc@mail.gmail.com> References: <19188.57617.399463.888129@winooski.ccs.neu.edu> <990e0c030911061911h2860175cpa3fd57d3cdb243dc@mail.gmail.com> Message-ID: <19188.59644.370809.571041@winooski.ccs.neu.edu> On Nov 6, Carl Eastlund wrote: > On Fri, Nov 6, 2009 at 9:53 PM, Eli Barzilay wrote: > > * As a potential user of this, I like this part of your proposal: > > > > ? ?Of course, people who make changes to modules in unstable must > > ? ?fix up any uses within the collections tree. > > > > ?But as a potential contributor, this makes it more painful than > > ?adding a proper library. > > If you are committed to maintaining it, but want to make it other > people's job to keep up, promote to a real library. If you are not > committed, leave it in unstable. This should *NOT* be an option. In fact, I considered adding an item that this whole thing sounds better if when an unstable library is not touched in a year, then it must move out (either back where it came from, or made into a library). Without this, it is pretty much guaranteed to be a dumping ground for random bits of code. > You are obligated to propagate fixes for any changes you make, but > there is no prohibition against washing your hands of it and walking > away *without* changing it. And once something is in unstable, > anyone can pick it up and take charge if you walk away. How likely is that to happen? There are tons of old code that needs cleaning and updating... > We already have a bunch of piles of unorganized code. ...why not start with that? Maybe there are useful bits that you can turn into more proper library code, even. > At least this way there's some room for sharing, seeing each other's > stuff, figuring out who wants what as a library, etc. And with > multiple people picking over it, there's more chances for people to > organize things, weed out dead code, etc. This is, in general, a very good idea. I try to at least skim over code that gets committed, and comment if there's anything that could be done better, faster, or wheteverer. A better way to promote this is to actually read code in random places, and read commit diffs. (There are certainly few enough of them that it's not too difficult.) > > * I was curious about having that many "util" files, so I went > > ? over them. ?It looks to me like only a small number of them > > ? could have generalizable parts. ?(List below, with `-' `+' and > > ? `?', and `?m' for a possible mred utils thing.) > > I'm not sure "generalizable" is the (only) goal here. Some of these > things are not exposed or documented, but may be useful to users > (internal or external) as-is. I meant that in the sense of "worth turning into a general library", where in this sentence "geenral" doesn't change anything since library already has that meaning. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From ryanc at ccs.neu.edu Fri Nov 6 22:33:39 2009 From: ryanc at ccs.neu.edu (Ryan Culpepper) Date: Fri Nov 6 22:34:13 2009 Subject: [plt-dev] a common collection for utility modules In-Reply-To: <19188.57617.399463.888129@winooski.ccs.neu.edu> References: <19188.57617.399463.888129@winooski.ccs.neu.edu> Message-ID: <4AF4EA93.7010508@ccs.neu.edu> Eli Barzilay wrote: > -1, overall. > > Random points: > > * There was/is already mzlib/etc which wasn't successful. If you're talking about the module formerly known as (lib "etc.ss"), that's irrelevant for a number of reasons. First, I never saw a welcome sign hanging on etc.ss saying "feel free to put anything you think might be useful here". Second, trying to cram everything into one module is unworkable; even if not for the phase restrictions that drive auxiliaries into separate modules, one module would become a huge unmanageable hodgepodge. Finally, mzlib as a collection was the main high-profile collection, where backwards-incompatible changes should be avoided. > * I can't avoid thinking about (require unstable/foo) being similar to > `from __future__ import foo'. (But you can also claim that this is > a good point, being something that was already used.) > > * IIUC, you're talking about a relatively cheap way to having new > library functions -- cheap in the sense that they won't be > documented or tested, or at least not done so thoroughly. Cheap as in "low barrier to entry" is good. And I'm certainly more likely to write documentation and tests for code that I've put in this shared collection than I am for code buried in, say, a macro-debugger subcollection. I might even be moved to document/test other people's shared code, if I find it useful. > * Also, all of these libraries should come with a big warning of "can > change at any time" -- but what happens when more code relies on > them, and what if the person in charge of such code is not willing > to put work in revising that code due to such change? I think we can work it out. Suppose I make a change to a library and you depend on it. I could just update your code, if it's simple to do so. I could notify you so you can figure out how to update your code. If your use is incompatible with the changes I want to make and we can't come to an agreement, we can fork the library, or part of it. > * As a potential user of this, I like this part of your proposal: > > Of course, people who make changes to modules in unstable must fix > up any uses within the collections tree. > > But as a potential contributor, this makes it more painful than > adding a proper library. > > * IIUC, you want this to be able to use random pieces of code in the > PLT tree, otherwise there's planet. Yes, exactly. In fact, there are many things on planet, such as parts of Carl's scheme package, that should probably be available here. Some of them should be migrating into the scheme collection sooner or later. > * This means that there's an issue of distribution. For example, > these libraries should not rely on mred/drscheme, or if there are > parts that do rely on them, they should be easily identifiable. > (This is a problem with distribution rules which is directly related > to the future plan to split the distribution into a core an a bunch > of additional libraries.) We should definitely allow GUI libraries in. If they have to be fenced off in a subcollection (unstable/gui), that's somewhat unpleasant but bearable. > * Many of what could be there (eg, things that I would put in such a > place) seems to me like it will end up staying there for years, > because turning the code into a general library is non-trivial > effort. This means a big pile of unrelated and unorganized code > fragments that, which is taking the mzlib/etc thing to a higher > level of being a PITA. Maybe. Do you see any reason why we can't wait and see if becomes a problem and then make efforts to tidy it up if it is? > * I was curious about having that many "util" files, so I went over > them. It looks to me like only a small number of them could have > generalizable parts. (List below, with `-' `+' and `?', and `?m' > for a possible mred utils thing.) I counted "util(s?).ss" files because it was easy. I suspect everyone has code they'd donate to the unstable collection that is mixed in with other modules or simply not named "util". I also suspect that your estimate is overly conservative. For just one example, you dismiss syntax/private/util.ss, but both Sam and Robby already depend on it (from when it used to be stxclass/util.ss and advertised). Ryan > + games/cards/utils.ss > + games/doors/private/utils.ss > ? honu/private/util.ss > ? mysterx/private/util.ss > ? net/mime-util.ss > ? schemeunit/text-ui-util.ss > ? setup/private/path-utils.ss > ? srfi/32/vector-util.scm > ? web-server/lang/util.ss > ?m framework/gui-utils.ss > ?m framework/private/path-utils.ss > ?m guibuilder/utils.ss > - drscheme/private/embedded-snip-utils.ss > - eopl/private/utils.ss > - frtime/lang-utils.ss > - games/doors/utils.ss > - games/loa/utils.ss > - games/pousse/utils.ss > - handin-server/utils.ss > - help/help-utils.ss > - mzlib/private/sigutil.ss > - mzlib/private/unit-utils.ss > - parser-tools/private-lex/util.ss > - planet/util.ss > - preprocessor/pp-utils.ss > - profile/utils.ss > - redex/private/bitmap-test-util.ss > - redex/private/lw-test-util.ss > - redex/private/test-util.ss > - schemeunit/text-ui-util-test.ss > - schemeunit/util-test.ss > - schemeunit/util.ss > - scribble/private/manual-utils.ss > - scribble/private/render-utils.ss > - scribble/text/syntax-utils.ss > - scribblings/foreign/utils.ss > - scribblings/guide/contracts-utils.ss > - scribblings/guide/guide-utils.ss > - scribblings/inside/utils.ss > - scribblings/main/private/utils.ss > - scribblings/scribble/utils.ss > - sirmail/utilr.ss > - slideshow/private/utils.ss > - srfi/1/util.ss > - syntax/private/util.ss > - texpict/utils.ss > - typed-scheme/rep/rep-utils.ss > - typed-scheme/types/utils.ss > - typed-scheme/utils/... > - typed/private/utils.ss > - version/utils.ss > - web-server/private/util.ss > - web-server/scribblings/tutorial/tutorial-util.ss From samth at ccs.neu.edu Fri Nov 6 22:41:19 2009 From: samth at ccs.neu.edu (Sam TH) Date: Fri Nov 6 22:41:56 2009 Subject: [plt-dev] a common collection for utility modules In-Reply-To: <19188.57617.399463.888129@winooski.ccs.neu.edu> References: <19188.57617.399463.888129@winooski.ccs.neu.edu> Message-ID: <63bb19ae0911061941lfb2a1a2jce7674b83d609e78@mail.gmail.com> On Fri, Nov 6, 2009 at 9:53 PM, Eli Barzilay wrote: > - typed-scheme/utils/... There are 8 files in this directory. I think 4 of them have things that are useful outside of Typed Scheme, including typed-scheme/utils/utils which has at least 21 binding of general interest. So, +1 from me too. Also, Ryan, JFDI. -- sam th samth@ccs.neu.edu From eli at barzilay.org Fri Nov 6 22:50:44 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri Nov 6 22:51:05 2009 Subject: [plt-dev] a common collection for utility modules In-Reply-To: <4AF4EA93.7010508@ccs.neu.edu> References: <19188.57617.399463.888129@winooski.ccs.neu.edu> <4AF4EA93.7010508@ccs.neu.edu> Message-ID: <19188.61076.218295.761791@winooski.ccs.neu.edu> On Nov 6, Ryan Culpepper wrote: > Eli Barzilay wrote: > > -1, overall. > > > > Random points: > > > > * There was/is already mzlib/etc which wasn't successful. > > If you're talking about the module formerly known as (lib "etc.ss"), > that's irrelevant for a number of reasons. First, I never saw a > welcome sign hanging on etc.ss saying "feel free to put anything you > think might be useful here". Second, trying to cram everything into > one module is unworkable; even if not for the phase restrictions > that drive auxiliaries into separate modules, one module would > become a huge unmanageable hodgepodge. Finally, mzlib as a > collection was the main high-profile collection, where > backwards-incompatible changes should be avoided. (I was talking about the idea behind having it, and the "etc" name is used exactly like "utils" or "misc" or "helper".) > > * Also, all of these libraries should come with a big warning of > > "can change at any time" -- but what happens when more code > > relies on them, and what if the person in charge of such code is > > not willing to put work in revising that code due to such > > change? > > I think we can work it out. Suppose I make a change to a library and > you depend on it. I could just update your code, if it's simple to > do so. I could notify you so you can figure out how to update your > code. If your use is incompatible with the changes I want to make > and we can't come to an agreement, we can fork the library, or part > of it. (Leaving beind an unstable library that I'm using, and nobody owns. A major point that I failed to make initially is that such code should never, IMO, become permanent.) > > * This means that there's an issue of distribution. For example, > > these libraries should not rely on mred/drscheme, or if there > > are parts that do rely on them, they should be easily > > identifiable. (This is a problem with distribution rules which > > is directly related to the future plan to split the distribution > > into a core an a bunch of additional libraries.) > > We should definitely allow GUI libraries in. If they have to be > fenced off in a subcollection (unstable/gui), that's somewhat > unpleasant but bearable. This would be necessary. (It could be avoided if someone was maintaining the distribution specs, but in this case you're talking about an ownerless library, so nobody will.) > > * Many of what could be there (eg, things that I would put in such > > a place) seems to me like it will end up staying there for > > years, because turning the code into a general library is > > non-trivial effort. This means a big pile of unrelated and > > unorganized code fragments that, which is taking the mzlib/etc > > thing to a higher level of being a PITA. > > Maybe. Do you see any reason why we can't wait and see if becomes a > problem and then make efforts to tidy it up if it is? Because it will. This is a fact. I'm surprised at so much enthusiasm towards adding more stuff but none towards cleaning up old stuff that needs cleening. > > * I was curious about having that many "util" files, so I went > > over them. It looks to me like only a small number of them > > could have generalizable parts. (List below, with `-' `+' and > > `?', and `?m' for a possible mred utils thing.) > > I counted "util(s?).ss" files because it was easy. I suspect > everyone has code they'd donate to the unstable collection that is > mixed in with other modules or simply not named "util". I also > suspect that your estimate is overly conservative. For just one > example, you dismiss syntax/private/util.ss, [...] I dismissed some files on different reasons -- in this case, some `syntax/utils' or splitting into libraries within the syntax collection seems fine. (IOW, these utilities are already in the right place -- and might need more internal organization and/or documentation.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From carl.eastlund at gmail.com Fri Nov 6 23:16:09 2009 From: carl.eastlund at gmail.com (Carl Eastlund) Date: Fri Nov 6 23:16:47 2009 Subject: [plt-dev] a common collection for utility modules In-Reply-To: <19188.61076.218295.761791@winooski.ccs.neu.edu> References: <19188.57617.399463.888129@winooski.ccs.neu.edu> <4AF4EA93.7010508@ccs.neu.edu> <19188.61076.218295.761791@winooski.ccs.neu.edu> Message-ID: <990e0c030911062016p2fa2d821t38d8bc465f4cc129@mail.gmail.com> On Fri, Nov 6, 2009 at 10:50 PM, Eli Barzilay wrote: >> > * Many of what could be there (eg, things that I would put in such >> > ? a place) seems to me like it will end up staying there for >> > ? years, because turning the code into a general library is >> > ? non-trivial effort. ?This means a big pile of unrelated and >> > ? unorganized code fragments that, which is taking the mzlib/etc >> > ? thing to a higher level of being a PITA. >> >> Maybe. Do you see any reason why we can't wait and see if becomes a >> problem and then make efforts to tidy it up if it is? > > Because it will. ?This is a fact. ?I'm surprised at so much enthusiasm > towards adding more stuff but none towards cleaning up old stuff that > needs cleening. First, it's not necessarily about adding more stuff. It's about taking the stuff we already have, and already write, and putting it somewhere we can share it. Second, I'm all for cleaning up stuff. But I have no idea what stuff needs to be cleaned up, or which things, when cleaned up, might have something in them I could use. This 'unstable' collection is a list of things we could all use. That's why I'm enthusiastic: I get access to more useful code. I don't see that unstable/{foo,bar,baz,bag} requires any more tidying up than if it were {foo,bar,baz,bag}/private/util. I see, mostly, the reduction in stuff that needs to be tidied up and removed, because there are more eyes on this code, more people picking it up and using it, more people who might keep it in good shape. Any that stays in bad shape, well, would have anyway. The fact of the matter is, we each currently treat our internal code as our personal code. And this is not realistic. There are all kinds of things that us behind-the-scenes implementers, not to mention some of the more advanced end users (by which I mean anyone without commit permissions to the trunk), could use. And we don't put it anywhere people can get at it. Ryan's suggestion seems a movement in the right direction. --Carl From ryanc at ccs.neu.edu Fri Nov 6 23:23:21 2009 From: ryanc at ccs.neu.edu (Ryan Culpepper) Date: Fri Nov 6 23:23:47 2009 Subject: [plt-dev] a common collection for utility modules In-Reply-To: <19188.61076.218295.761791@winooski.ccs.neu.edu> References: <19188.57617.399463.888129@winooski.ccs.neu.edu> <4AF4EA93.7010508@ccs.neu.edu> <19188.61076.218295.761791@winooski.ccs.neu.edu> Message-ID: <4AF4F639.8020209@ccs.neu.edu> Eli Barzilay wrote: > On Nov 6, Ryan Culpepper wrote: >> Eli Barzilay wrote: >>> -1, overall. >>> >>> Random points: >>> >>> * There was/is already mzlib/etc which wasn't successful. >> If you're talking about the module formerly known as (lib "etc.ss"), >> that's irrelevant for a number of reasons. First, I never saw a >> welcome sign hanging on etc.ss saying "feel free to put anything you >> think might be useful here". Second, trying to cram everything into >> one module is unworkable; even if not for the phase restrictions >> that drive auxiliaries into separate modules, one module would >> become a huge unmanageable hodgepodge. Finally, mzlib as a >> collection was the main high-profile collection, where >> backwards-incompatible changes should be avoided. > > (I was talking about the idea behind having it, and the "etc" name is > used exactly like "utils" or "misc" or "helper".) If mzlib/etc was ever the Wild West, it has since grown up into a gated community full of dependable, respectable members, veritable pillars of society. We need a new Wild West. >>> * Also, all of these libraries should come with a big warning of >>> "can change at any time" -- but what happens when more code >>> relies on them, and what if the person in charge of such code is >>> not willing to put work in revising that code due to such >>> change? >> I think we can work it out. Suppose I make a change to a library and >> you depend on it. I could just update your code, if it's simple to >> do so. I could notify you so you can figure out how to update your >> code. If your use is incompatible with the changes I want to make >> and we can't come to an agreement, we can fork the library, or part >> of it. > > (Leaving beind an unstable library that I'm using, and nobody owns. A > major point that I failed to make initially is that such code should > never, IMO, become permanent.) If you're using an unstable library and nobody owns it... you own it. Unless you can foist it off on someone else. If no one else owns it you can, of course, start assimilating the parts you want and junking the rest. If no one depends on it and no one owns it or wants to, it can be junked immediately. And yes, we should periodically review the unstable collection and eliminate dead libraries. We should probably do the same for all collections, but there's a higher risk of breaking code in planet or in some other project when we do that. >>> * This means that there's an issue of distribution. For example, >>> these libraries should not rely on mred/drscheme, or if there >>> are parts that do rely on them, they should be easily >>> identifiable. (This is a problem with distribution rules which >>> is directly related to the future plan to split the distribution >>> into a core an a bunch of additional libraries.) >> We should definitely allow GUI libraries in. If they have to be >> fenced off in a subcollection (unstable/gui), that's somewhat >> unpleasant but bearable. > > This would be necessary. (It could be avoided if someone was > maintaining the distribution specs, but in this case you're talking > about an ownerless library, so nobody will.) > > >>> * Many of what could be there (eg, things that I would put in such >>> a place) seems to me like it will end up staying there for >>> years, because turning the code into a general library is >>> non-trivial effort. This means a big pile of unrelated and >>> unorganized code fragments that, which is taking the mzlib/etc >>> thing to a higher level of being a PITA. >> Maybe. Do you see any reason why we can't wait and see if becomes a >> problem and then make efforts to tidy it up if it is? > > Because it will. This is a fact. I'm surprised at so much enthusiasm > towards adding more stuff but none towards cleaning up old stuff that > needs cleening. I see Carl has just answered this point. What he said. Ryan > > >>> * I was curious about having that many "util" files, so I went >>> over them. It looks to me like only a small number of them >>> could have generalizable parts. (List below, with `-' `+' and >>> `?', and `?m' for a possible mred utils thing.) >> I counted "util(s?).ss" files because it was easy. I suspect >> everyone has code they'd donate to the unstable collection that is >> mixed in with other modules or simply not named "util". I also >> suspect that your estimate is overly conservative. For just one >> example, you dismiss syntax/private/util.ss, [...] > > I dismissed some files on different reasons -- in this case, some > `syntax/utils' or splitting into libraries within the syntax > collection seems fine. (IOW, these utilities are already in the right > place -- and might need more internal organization and/or > documentation.) > From eli at barzilay.org Fri Nov 6 23:37:50 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri Nov 6 23:38:11 2009 Subject: [plt-dev] a common collection for utility modules In-Reply-To: <990e0c030911062016p2fa2d821t38d8bc465f4cc129@mail.gmail.com>, <4AF4F639.8020209@ccs.neu.edu> References: <19188.57617.399463.888129@winooski.ccs.neu.edu> <4AF4EA93.7010508@ccs.neu.edu> <19188.61076.218295.761791@winooski.ccs.neu.edu> <4AF4F639.8020209@ccs.neu.edu> <990e0c030911062016p2fa2d821t38d8bc465f4cc129@mail.gmail.com> Message-ID: <19188.63902.178422.208029@winooski.ccs.neu.edu> On Nov 6, Carl Eastlund wrote: > > Second, I'm all for cleaning up stuff. But I have no idea what > stuff needs to be cleaned up, Start with grepping `module.*mzscheme' -- this should give you a few hundred files to work on. > or which things, when cleaned up, might have something in them I > could use. Right -- this gives a payoff after you've done some work cleaning up stuff. > I don't see that unstable/{foo,bar,baz,bag} requires any more > tidying up than if it were {foo,bar,baz,bag}/private/util. When `foo' becomes too old and gets rewritten or replaced, everything goes with it. `unstable' will just guarantee that rotting bits will stay there. (That's exactly why I said that it seems better to accompany this proposal with a time limit for all libraries.) > I see, mostly, the reduction in stuff that needs to be tidied up and > removed, because there are more eyes on this code, more people > picking it up and using it, more people who might keep it in good > shape. Any that stays in bad shape, well, would have anyway. Why does it have to be this way? This is like claiming that most of the tree is closed source. What's preventing you from going over other people's code and fixing things? Or pointing out things that should be shared? Or telling them that something is so useful that if they just generalize that one bit and put it in a more general library, you'll volunteer to document, write tests, and maintain it? This lack of shared workload is something that exist now, and `unstable' is just putting a new label on it. > The fact of the matter is, we each currently treat our internal code > as our personal code. And this is not realistic. Yes -- fix that! And it can be fixed regardless of a new toplevel label and a new kind of a "not really organized collection of code" tool. On Nov 6, Ryan Culpepper wrote: > Eli Barzilay wrote: > > > > (Leaving beind an unstable library that I'm using, and nobody > > owns. A major point that I failed to make initially is that such > > code should never, IMO, become permanent.) > > If you're using an unstable library and nobody owns it... you own > it. Unless you can foist it off on someone else. If no one else > owns it you can, of course, start assimilating the parts you want > and junking the rest. See above. What needs fixing is for people to start looking beyond their collections -- regardless of a new collection. (And you can summarize my above concern as: if this is not fixed, then we haven't done anything besides shuffle some code around -- so now people still don't care, and the code is messier.) > If no one depends on it and no one owns it or wants to, it can be > junked immediately. And yes, we should periodically review the > unstable collection and eliminate dead libraries. We should probably > do the same for all collections, but there's a higher risk of > breaking code in planet or in some other project when we do that. So why not do that?? Everyone's jumping up and down about adding new stuff, but when it comes to improving existing code then we get these "should probably"s. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From grettke at acm.org Sat Nov 7 00:21:10 2009 From: grettke at acm.org (Grant Rettke) Date: Sat Nov 7 00:21:33 2009 Subject: [plt-dev] a common collection for utility modules In-Reply-To: References: Message-ID: <756daca50911062121t56e2d6f5i50bfd166698ba44f@mail.gmail.com> On Fri, Nov 6, 2009 at 5:46 PM, Ryan Culpepper wrote: > I hope the unstable collection will lead to more code sharing. I also hope > that it will be a place to hash out interfaces and get implementations Just > Right before promoting code to the major leagues^W collections. Not for all > code, just for code that doesn't immediately fit in anywhere else. How about allowing different types of packages: "experiment" and "production". It would make clear the intended level of quality and you wouldn't have to worry about a one-size-fits-all package. From ryanc at ccs.neu.edu Sat Nov 7 00:34:06 2009 From: ryanc at ccs.neu.edu (Ryan Culpepper) Date: Sat Nov 7 00:34:32 2009 Subject: [plt-dev] a common collection for utility modules In-Reply-To: <19188.63902.178422.208029@winooski.ccs.neu.edu> References: <19188.57617.399463.888129@winooski.ccs.neu.edu> <4AF4EA93.7010508@ccs.neu.edu> <19188.61076.218295.761791@winooski.ccs.neu.edu> <4AF4F639.8020209@ccs.neu.edu> <990e0c030911062016p2fa2d821t38d8bc465f4cc129@mail.gmail.com> <19188.63902.178422.208029@winooski.ccs.neu.edu> Message-ID: <4AF506CE.10907@ccs.neu.edu> Eli Barzilay wrote: > On Nov 6, Carl Eastlund wrote: > [...] >> I see, mostly, the reduction in stuff that needs to be tidied up and >> removed, because there are more eyes on this code, more people >> picking it up and using it, more people who might keep it in good >> shape. Any that stays in bad shape, well, would have anyway. > > Why does it have to be this way? This is like claiming that most of > the tree is closed source. What's preventing you from going over > other people's code and fixing things? Or pointing out things that > should be shared? Or telling them that something is so useful that if > they just generalize that one bit and put it in a more general > library, you'll volunteer to document, write tests, and maintain it? > This lack of shared workload is something that exist now, and > `unstable' is just putting a new label on it. > > >> The fact of the matter is, we each currently treat our internal code >> as our personal code. And this is not realistic. > > Yes -- fix that! And it can be fixed regardless of a new toplevel > label and a new kind of a "not really organized collection of code" > tool. The fact is, we tend not to interfere in other people's collections much. I've been talking about this phenomenon with various people around the Northeastern lab for years. After many discussions, I still don't have a good idea of how to fix it. So I'm attacking a related problem with a different approach. Rather than encouraging developers to wander around in other people's territory, I'm encouraging them to put more of their work into a common space. Why should you go hunting through my code for useful bits when I have a much better idea of what is generally useful and what is specific to my particular needs? And a collection is a very useful label to hang on the common space, one that interacts well with other needs such as documentation. (Infamous Ryan-Analogy: There are two ways to increase social interaction. Encourage people to barge into others' personal spaces, or encourage everyone to spend more time in public spaces. I'm going for the latter.) If you want to fix the other problem, go for it. But shouting "Be it so!" doesn't seem to work. > On Nov 6, Ryan Culpepper wrote: >> Eli Barzilay wrote: >>> (Leaving beind an unstable library that I'm using, and nobody >>> owns. A major point that I failed to make initially is that such >>> code should never, IMO, become permanent.) >> If you're using an unstable library and nobody owns it... you own >> it. Unless you can foist it off on someone else. If no one else >> owns it you can, of course, start assimilating the parts you want >> and junking the rest. > > See above. What needs fixing is for people to start looking beyond > their collections -- regardless of a new collection. (And you can > summarize my above concern as: if this is not fixed, then we haven't > done anything besides shuffle some code around -- so now people still > don't care, and the code is messier.) Shuffling code around, when done carefully, is called *organizing*. I think people are more likely to care once the code becomes better organized. I'll volunteer to watch over the unstable collection to make sure it doesn't degenerate into long-term chaos. (I make no promises about short-term chaos.) >> If no one depends on it and no one owns it or wants to, it can be >> junked immediately. And yes, we should periodically review the >> unstable collection and eliminate dead libraries. We should probably >> do the same for all collections, but there's a higher risk of >> breaking code in planet or in some other project when we do that. > > So why not do that?? Everyone's jumping up and down about adding new > stuff, but when it comes to improving existing code then we get these > "should probably"s. Just because there's work to be done in maintaining existing collections doesn't mean that it isn't worth adding another one. The movement of code might even indirectly help the existing collections. Ryan From ryanc at ccs.neu.edu Sat Nov 7 00:43:11 2009 From: ryanc at ccs.neu.edu (Ryan Culpepper) Date: Sat Nov 7 00:43:32 2009 Subject: [plt-dev] a common collection for utility modules In-Reply-To: <756daca50911062121t56e2d6f5i50bfd166698ba44f@mail.gmail.com> References: <756daca50911062121t56e2d6f5i50bfd166698ba44f@mail.gmail.com> Message-ID: <4AF508EF.4030501@ccs.neu.edu> Grant Rettke wrote: > On Fri, Nov 6, 2009 at 5:46 PM, Ryan Culpepper wrote: >> I hope the unstable collection will lead to more code sharing. I also hope >> that it will be a place to hash out interfaces and get implementations Just >> Right before promoting code to the major leagues^W collections. Not for all >> code, just for code that doesn't immediately fit in anywhere else. > > How about allowing different types of packages: "experiment" and > "production". It would make clear the intended level of quality and > you wouldn't have to worry about a one-size-fits-all package. Just to be clear, we aren't talking about packages in the PLaneT sense at all. Rather, modules and subcollections within the "unstable" collection. I think this can be done at the documentation level. Possibly we'll evolve some standard labels and encourage their use. BTW, I'm envisioning all documentation for "unstable" libraries to be within a single "Unstable" manual; that should help make it clear. Ryan From eli at barzilay.org Sat Nov 7 01:39:53 2009 From: eli at barzilay.org (Eli Barzilay) Date: Sat Nov 7 01:40:14 2009 Subject: [plt-dev] a common collection for utility modules In-Reply-To: <4AF506CE.10907@ccs.neu.edu> References: <19188.57617.399463.888129@winooski.ccs.neu.edu> <4AF4EA93.7010508@ccs.neu.edu> <19188.61076.218295.761791@winooski.ccs.neu.edu> <4AF4F639.8020209@ccs.neu.edu> <990e0c030911062016p2fa2d821t38d8bc465f4cc129@mail.gmail.com> <19188.63902.178422.208029@winooski.ccs.neu.edu> <4AF506CE.10907@ccs.neu.edu> Message-ID: <19189.5689.303260.539871@winooski.ccs.neu.edu> On Nov 7, Ryan Culpepper wrote: > > (Infamous Ryan-Analogy: There are two ways to increase social > interaction. Encourage people to barge into others' personal spaces, > or encourage everyone to spend more time in public spaces. I'm going > for the latter.) The mistake here is "collection" = "personal space", an equation that fails in a spectacular way when a collection's owner dumps it and some victim becomes its new owner. > > See above. What needs fixing is for people to start looking > > beyond their collections -- regardless of a new collection. (And > > you can summarize my above concern as: if this is not fixed, then > > we haven't done anything besides shuffle some code around -- so > > now people still don't care, and the code is messier.) > > Shuffling code around, when done carefully, is called *organizing*. The shuffling in this case (at least IIUC) involves taking out random bits of "looks like it's useful" code and moving it into a big (parent-less) collection named "unorganized stuff". [A better attempt at this kind of promotion path would to extend the chain of `scheme/foo' -> `scheme/private/foo' for some `foo's: add new list functions into `scheme/list-extra', and have all the extras documented in an "Unstable Extras" manual. This way, the unstable stuff is still organized according to functionality, and since the code is in `foo-extra', then it's hint for `foo's owner that some stuff might be good to add -- and if this comes with proper documentation and tests then it's even easier to add.] -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From yinso.chen at gmail.com Sat Nov 7 01:42:52 2009 From: yinso.chen at gmail.com (YC) Date: Sat Nov 7 01:43:16 2009 Subject: [plt-dev] a common collection for utility modules In-Reply-To: <4AF506CE.10907@ccs.neu.edu> References: <19188.57617.399463.888129@winooski.ccs.neu.edu> <4AF4EA93.7010508@ccs.neu.edu> <19188.61076.218295.761791@winooski.ccs.neu.edu> <4AF4F639.8020209@ccs.neu.edu> <990e0c030911062016p2fa2d821t38d8bc465f4cc129@mail.gmail.com> <19188.63902.178422.208029@winooski.ccs.neu.edu> <4AF506CE.10907@ccs.neu.edu> Message-ID: <779bf2730911062242p2837cef7v9e9f1a4b01a2e67a@mail.gmail.com> IMHO this is a good idea that can encourage code refactoring and reuse, but it should be done with the understanding that the experimental code will still be supported and will "eventually" become production code, otherwise it might not achieve the desired effect. Cheers, yc On Fri, Nov 6, 2009 at 9:34 PM, Ryan Culpepper wrote: > Eli Barzilay wrote: > >> On Nov 6, Carl Eastlund wrote: >> [...] >> >> I see, mostly, the reduction in stuff that needs to be tidied up and >>> removed, because there are more eyes on this code, more people >>> picking it up and using it, more people who might keep it in good >>> shape. Any that stays in bad shape, well, would have anyway. >>> >> >> Why does it have to be this way? This is like claiming that most of >> the tree is closed source. What's preventing you from going over >> other people's code and fixing things? Or pointing out things that >> should be shared? Or telling them that something is so useful that if >> they just generalize that one bit and put it in a more general >> library, you'll volunteer to document, write tests, and maintain it? >> This lack of shared workload is something that exist now, and >> `unstable' is just putting a new label on it. >> >> >> The fact of the matter is, we each currently treat our internal code >>> as our personal code. And this is not realistic. >>> >> >> Yes -- fix that! And it can be fixed regardless of a new toplevel >> label and a new kind of a "not really organized collection of code" >> tool. >> > > The fact is, we tend not to interfere in other people's collections much. > I've been talking about this phenomenon with various people around the > Northeastern lab for years. After many discussions, I still don't have a > good idea of how to fix it. So I'm attacking a related problem with a > different approach. > > Rather than encouraging developers to wander around in other people's > territory, I'm encouraging them to put more of their work into a common > space. Why should you go hunting through my code for useful bits when I have > a much better idea of what is generally useful and what is specific to my > particular needs? And a collection is a very useful label to hang on the > common space, one that interacts well with other needs such as > documentation. > > (Infamous Ryan-Analogy: There are two ways to increase social interaction. > Encourage people to barge into others' personal spaces, or encourage > everyone to spend more time in public spaces. I'm going for the latter.) > > If you want to fix the other problem, go for it. But shouting "Be it so!" > doesn't seem to work. > > > > On Nov 6, Ryan Culpepper wrote: >> >>> Eli Barzilay wrote: >>> >>>> (Leaving beind an unstable library that I'm using, and nobody >>>> owns. A major point that I failed to make initially is that such >>>> code should never, IMO, become permanent.) >>>> >>> If you're using an unstable library and nobody owns it... you own >>> it. Unless you can foist it off on someone else. If no one else >>> owns it you can, of course, start assimilating the parts you want >>> and junking the rest. >>> >> >> See above. What needs fixing is for people to start looking beyond >> their collections -- regardless of a new collection. (And you can >> summarize my above concern as: if this is not fixed, then we haven't >> done anything besides shuffle some code around -- so now people still >> don't care, and the code is messier.) >> > > Shuffling code around, when done carefully, is called *organizing*. I think > people are more likely to care once the code becomes better organized. > > I'll volunteer to watch over the unstable collection to make sure it > doesn't degenerate into long-term chaos. (I make no promises about > short-term chaos.) > > > > If no one depends on it and no one owns it or wants to, it can be >>> junked immediately. And yes, we should periodically review the >>> unstable collection and eliminate dead libraries. We should probably >>> do the same for all collections, but there's a higher risk of >>> breaking code in planet or in some other project when we do that. >>> >> >> So why not do that?? Everyone's jumping up and down about adding new >> stuff, but when it comes to improving existing code then we get these >> "should probably"s. >> > > Just because there's work to be done in maintaining existing collections > doesn't mean that it isn't worth adding another one. The movement of code > might even indirectly help the existing collections. > > Ryan > > > _________________________________________________ > 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/20091106/7874833b/attachment.htm From neil at neilvandyke.org Sat Nov 7 05:08:22 2009 From: neil at neilvandyke.org (Neil Van Dyke) Date: Sat Nov 7 05:08:43 2009 Subject: [plt-dev] a common collection for utility modules In-Reply-To: <779bf2730911062242p2837cef7v9e9f1a4b01a2e67a@mail.gmail.com> References: <19188.57617.399463.888129@winooski.ccs.neu.edu> <4AF4EA93.7010508@ccs.neu.edu> <19188.61076.218295.761791@winooski.ccs.neu.edu> <4AF4F639.8020209@ccs.neu.edu> <990e0c030911062016p2fa2d821t38d8bc465f4cc129@mail.gmail.com> <19188.63902.178422.208029@winooski.ccs.neu.edu> <4AF506CE.10907@ccs.neu.edu> <779bf2730911062242p2837cef7v9e9f1a4b01a2e67a@mail.gmail.com> Message-ID: <4AF54716.4070604@neilvandyke.org> I could only skim today's big discussion thread, so please ignore this devil's advocate playing if it's unhelpful... What about doing eating one's own dogfood, and doing experimental new libraries in PLaneT instead? If, on the other hand, it's for code-sharing of internal-use-only code within PLT Scheme, why not just put it wherever other internal-use-only code goes? If it's for internal code-sharing *plus* external use with the warning that it's unstable, why not keep it internal-use-only until it's ready, rather than dilute the PLT Scheme brand? -- http://www.neilvandyke.org/ From mflatt at cs.utah.edu Sat Nov 7 08:33:43 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Sat Nov 7 08:34:03 2009 Subject: [plt-dev] a common collection for utility modules In-Reply-To: <19189.5689.303260.539871@winooski.ccs.neu.edu> References: <19188.57617.399463.888129@winooski.ccs.neu.edu> <4AF4EA93.7010508@ccs.neu.edu> <19188.61076.218295.761791@winooski.ccs.neu.edu> <4AF4F639.8020209@ccs.neu.edu> <990e0c030911062016p2fa2d821t38d8bc465f4cc129@mail.gmail.com> <19188.63902.178422.208029@winooski.ccs.neu.edu> <4AF506CE.10907@ccs.neu.edu> <19189.5689.303260.539871@winooski.ccs.neu.edu> Message-ID: <20091107133344.591286500B7@mail-svr1.cs.utah.edu> At Fri, 6 Nov 2009 18:46:51 -0500, Ryan Culpepper wrote: > I propose to add a new collection called "unstable" to serve as a > place to put small libraries that might be of general use but either > don't fit or aren't ready for any of the existing locations. I like this idea. Eli and and Neil have some good points against, but it looks to me like "unstable" will solve more problems than it creates. Let's try it. From jay.mccarthy at gmail.com Sat Nov 7 09:40:47 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Sat Nov 7 09:41:07 2009 Subject: [plt-dev] a common collection for utility modules In-Reply-To: <20091107133344.591286500B7@mail-svr1.cs.utah.edu> References: <19188.57617.399463.888129@winooski.ccs.neu.edu> <4AF4EA93.7010508@ccs.neu.edu> <19188.61076.218295.761791@winooski.ccs.neu.edu> <4AF4F639.8020209@ccs.neu.edu> <990e0c030911062016p2fa2d821t38d8bc465f4cc129@mail.gmail.com> <19188.63902.178422.208029@winooski.ccs.neu.edu> <4AF506CE.10907@ccs.neu.edu> <19189.5689.303260.539871@winooski.ccs.neu.edu> <20091107133344.591286500B7@mail-svr1.cs.utah.edu> Message-ID: I've added a initial version of unstable with libraries from the web-server. Jay On Sat, Nov 7, 2009 at 2:33 PM, Matthew Flatt wrote: > At Fri, 6 Nov 2009 18:46:51 -0500, Ryan Culpepper wrote: >> I propose to add a new collection called "unstable" to serve as a >> place to put small libraries that might be of general use but either >> don't fit or aren't ready for any of the existing locations. > > I like this idea. Eli and and Neil have some good points against, but > it looks to me like "unstable" will solve more problems than it > creates. Let's try it. > > _________________________________________________ > ?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 samth at ccs.neu.edu Sat Nov 7 10:08:21 2009 From: samth at ccs.neu.edu (Sam TH) Date: Sat Nov 7 10:08:58 2009 Subject: [plt-dev] a common collection for utility modules In-Reply-To: <4AF54716.4070604@neilvandyke.org> References: <19188.57617.399463.888129@winooski.ccs.neu.edu> <4AF4EA93.7010508@ccs.neu.edu> <19188.61076.218295.761791@winooski.ccs.neu.edu> <4AF4F639.8020209@ccs.neu.edu> <990e0c030911062016p2fa2d821t38d8bc465f4cc129@mail.gmail.com> <19188.63902.178422.208029@winooski.ccs.neu.edu> <4AF506CE.10907@ccs.neu.edu> <779bf2730911062242p2837cef7v9e9f1a4b01a2e67a@mail.gmail.com> <4AF54716.4070604@neilvandyke.org> Message-ID: <63bb19ae0911070708n53a2abe4vddeed4e35f6fc282@mail.gmail.com> On Sat, Nov 7, 2009 at 5:08 AM, Neil Van Dyke wrote: > If, on the other hand, it's for code-sharing of internal-use-only code > within PLT Scheme, why not just put it wherever other internal-use-only code > goes? The answer here is that we are creating precisely the place where internal-use-only code goes, since it doesn't currently exist. -- sam th samth@ccs.neu.edu From matthias at ccs.neu.edu Sat Nov 7 12:12:11 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Sat Nov 7 12:12:35 2009 Subject: [plt-dev] a common collection for utility modules In-Reply-To: References: <19188.57617.399463.888129@winooski.ccs.neu.edu> <4AF4EA93.7010508@ccs.neu.edu> <19188.61076.218295.761791@winooski.ccs.neu.edu> <4AF4F639.8020209@ccs.neu.edu> <990e0c030911062016p2fa2d821t38d8bc465f4cc129@mail.gmail.com> <19188.63902.178422.208029@winooski.ccs.neu.edu> <4AF506CE.10907@ccs.neu.edu> <19189.5689.303260.539871@winooski.ccs.neu.edu> <20091107133344.591286500B7@mail-svr1.cs.utah.edu> Message-ID: Ryan and Jay, could you please write a 'manifesto' for the new collection? I am thinking of a 5-10 line text file with basic commandments for things in this collection. Here are five lines I can extract from the discussion: " * You are welcome to add any module here, as long as you claim responsibility for it. (How?) * If you change the API and/or its meaning, you must track down others uses in the plt tree and inform clients. * Use contracts to specify the API. " I suspect you will find a few more if you scan Eli's emails carefully. -- Matthias From robby at eecs.northwestern.edu Sat Nov 7 12:28:55 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Sat Nov 7 12:29:15 2009 Subject: [plt-dev] a common collection for utility modules In-Reply-To: References: <19188.61076.218295.761791@winooski.ccs.neu.edu> <4AF4F639.8020209@ccs.neu.edu> <990e0c030911062016p2fa2d821t38d8bc465f4cc129@mail.gmail.com> <19188.63902.178422.208029@winooski.ccs.neu.edu> <4AF506CE.10907@ccs.neu.edu> <19189.5689.303260.539871@winooski.ccs.neu.edu> <20091107133344.591286500B7@mail-svr1.cs.utah.edu> Message-ID: <932b2f1f0911070928k6088dc4eoad39a6abfebe031a@mail.gmail.com> For the "how?" question, you can define a scribble macro like defmodule that accepts someone's name and sticks it right at the top there with the module definition. Robby On Sat, Nov 7, 2009 at 11:12 AM, Matthias Felleisen wrote: > > Ryan and Jay, > > could you please write a 'manifesto' for the new collection? > I am thinking of a 5-10 line text file with basic commandments > for things in this collection. Here are five lines I can extract > from the discussion: > > " > * You are welcome to add any module here, > ?as long as you claim responsibility for it. (How?) > > * If you change the API and/or its meaning, > ?you must track down others uses in the plt tree and inform clients. > > * Use contracts to specify the API. > " > > I suspect you will find a few more if you scan Eli's emails > carefully. > > -- Matthias > > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > From ryanc at ccs.neu.edu Sun Nov 8 05:56:38 2009 From: ryanc at ccs.neu.edu (Ryan Culpepper) Date: Sun Nov 8 05:56:59 2009 Subject: [plt-dev] a common collection for utility modules In-Reply-To: References: <19188.57617.399463.888129@winooski.ccs.neu.edu> <4AF4EA93.7010508@ccs.neu.edu> <19188.61076.218295.761791@winooski.ccs.neu.edu> <4AF4F639.8020209@ccs.neu.edu> <990e0c030911062016p2fa2d821t38d8bc465f4cc129@mail.gmail.com> <19188.63902.178422.208029@winooski.ccs.neu.edu> <4AF506CE.10907@ccs.neu.edu> <19189.5689.303260.539871@winooski.ccs.neu.edu> <20091107133344.591286500B7@mail-svr1.cs.utah.edu> Message-ID: <4AF6A3E6.7030304@ccs.neu.edu> I've added a draft Guidelines section to the Unstable manual. Ryan Matthias Felleisen wrote: > > Ryan and Jay, > > could you please write a 'manifesto' for the new collection? > I am thinking of a 5-10 line text file with basic commandments > for things in this collection. Here are five lines I can extract > from the discussion: > > " > * You are welcome to add any module here, > as long as you claim responsibility for it. (How?) > > * If you change the API and/or its meaning, > you must track down others uses in the plt tree and inform clients. > > * Use contracts to specify the API. > " > > I suspect you will find a few more if you scan Eli's emails > carefully. > > -- Matthias > From samth at ccs.neu.edu Mon Nov 9 14:20:27 2009 From: samth at ccs.neu.edu (Sam TH) Date: Mon Nov 9 14:21:08 2009 Subject: [plt-dev] Scribble: @author+email obfuscation In-Reply-To: <990e0c030909141816h7e86952gc39f47e8145aca8d@mail.gmail.com> References: <990e0c030909121037r27615ed7p7e2274e42f5109c1@mail.gmail.com> <20090913011302.921266500A8@mail-svr1.cs.utah.edu> <990e0c030909141816h7e86952gc39f47e8145aca8d@mail.gmail.com> Message-ID: <63bb19ae0911091120o65214a1fkf1da53d8cd5e45f6@mail.gmail.com> On Mon, Sep 14, 2009 at 8:16 PM, Carl Eastlund wrote: > Thanks as always for the quick fix. ?Any chance of adding an email: > link to the address so readers can just click to reply? The address is now hyperlinked when 'obfuscate?' is #f. > On Sat, Sep 12, 2009 at 9:12 PM, Matthew Flatt wrote: >> E-mail address obfuscation is now optional (as determined by new >> keyword argument) and is disabled by default. >> >> At Sat, 12 Sep 2009 12:05:54 -0600, Jay McCarthy wrote: >>> I like the idea. I have no problem with my email being public. Google >>> is just too good at catching spam to worry for me. >>> >>> Jay >>> >>> On Sat, Sep 12, 2009 at 11:37 AM, Carl Eastlund wrote: >>> > The @author+email["My Name" "my@name.com"] form produces output like this: >>> > >>> > My Name >>> > >>> > Which is nice for avoiding spam, but annoying for the reader who wants >>> > to click a link or copy/paste. ?What do Scribble users / developers >>> > think of making author+email just embed a straightforward email link, >>> > and add author+email-no-spam for people worried about spambots? ?I'd >>> > rather have both options available. >>> > >>> > Carl Eastlund > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > -- sam th samth@ccs.neu.edu From anton at mips.complang.tuwien.ac.at Mon Nov 9 15:33:52 2009 From: anton at mips.complang.tuwien.ac.at (Anton Ertl) Date: Mon Nov 9 15:34:13 2009 Subject: [plt-dev] Re: Build problems In-Reply-To: Message-ID: Anton Ertl wrote: > So I first tried to build mz-4.2.2 (and then 4.2.2.4, but no change) > on an bunch of machines. It worked nicely on a IA32 Debian Sarge > system (gcc-3.3.5), but I had trouble on the other systems. I will > investigate these problems myself, but if this rings a bell for you, I > would be glad for a hint. Thanks in advance, > > - anton > > On a PowerPC (shown here) and AMD64 system running Debian Lenny > (gcc-4.3.2) I see: > make[7]: Entering directory `/localtmp/mz-4.2.2.4/src/build/foreign' > gcc -g -O2 -Wall -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I./../mzscheme -I../../foreign/../mzscheme/include -I../../foreign/../mzscheme/src -Igcc/libffi/include -c ../../foreign/foreign.c -o foreign.o > In file included from ../../foreign/../mzscheme/include/scheme.h:127, > from ../../foreign/../mzscheme/src/schpriv.h:21, > from ../../foreign/foreign.c:9: > /usr/include/stdio.h:34:21: error: stddef.h: No such file or directory > In file included from /usr/include/stdio.h:75, > from ../../foreign/../mzscheme/include/scheme.h:127, > from ../../foreign/../mzscheme/src/schpriv.h:21, > from ../../foreign/foreign.c:9: > /usr/include/libio.h:53:21: error: stdarg.h: No such file or directory I found a workaround for this: After configuring with ../configure CC=gcc-4.3 this compiles fine on both of these machines. Only when invoking the compiler with "gcc" do I get this error message; and that's despite that fact that gcc is just a symbolic link to gcc-4.3. Apparently the name of the command I used is used in the path lookup. Strange. I cannot currently test on the Alpha box. - anton From eli at barzilay.org Mon Nov 9 17:08:57 2009 From: eli at barzilay.org (Eli Barzilay) Date: Mon Nov 9 17:09:20 2009 Subject: [plt-dev] Re: Speed up check-syntax In-Reply-To: <932b2f1f0911091055s435613c6oa3668c80afbcf509@mail.gmail.com> References: <595b9ab20911090556u5115e7dfpfdd863588ea3fb34@mail.gmail.com> <932b2f1f0911090757i1a4fe4e9rdf5b9e4fb6efd84b@mail.gmail.com> <932b2f1f0911090828p72588563o9f83f758af475041@mail.gmail.com> <932b2f1f0911091009jec184kbe02b576da713d42@mail.gmail.com> <932b2f1f0911091022y3344aa69qc928e555ad5c7e15@mail.gmail.com> <932b2f1f0911091055s435613c6oa3668c80afbcf509@mail.gmail.com> Message-ID: <19192.37625.138009.868012@winooski.ccs.neu.edu> [Moving to plt-dev.] On Nov 9, Robby Findler wrote: > > I find such behavior annoying in my OS and expect it would be the > same in DrScheme. Things will be sluggish while it is loading. > > Nevertheless, I will try this if the parallelism stuff doesn't pan > out. 1. I find the delay-on-first-syncheck especially annoying in class. I always start a new drscheme at the beginning of the class, which means that I'm guaranteed to get the annoying delay. (And it's a classic case of unjustified delay, since drscheme will sit there for many minutes doing nothing before I get to use it.) It's at a level where I hesitate to use it -- and on some occasions I pre-arrange myself so that I click it while I speak to mask out the delay. (Being able to do such things is something that I had to learn as a stutterer...) 2. BTW, the status-line message is not showing at all on linux. I never knew that there was supposed to be such a message. (I almost never run it on my laptop.) 3. IMO, the issue will not be completely resolved with multiple cores. What if my other core is busy doing something else? What about school machines that can be very outdated? What about IO delays, since this does involve mostly IO? 4. The usual way to do these things is to have it loaded when it is idle (exactly what Stephen said) -- but then don't just start to load it so everything becomes slow, just do that in little execution chunks which are done only if the system is still otherwise idle. I think that MzScheme could use some more functionality in this area -- a nice feature to have would be a way for a thread to change its priority where this can also be a "run me only when otherwise idle" (it would be especially nice to have a hierarchy of these: "run me when otherwise idle including 1st-level idle-priority threads, and give me only 20% running time"). 5. Fantasies aside, I think that it is possible to do a reasonable job for this given the current tools. The code below looks to me like it should work fine. It runs a given thunk in the background while drscheme is idle, and using little cpu time so there's no alarming cpu load. The returned result is a thunk that returns the computed value -- waiting for it (while giving it 100% cpu) if it isn't ready yet. 6. To try it, I basically changed "syncheck.ss" with this definition: (define get-xref (run-lazily (lambda () (with-handlers ([exn? (lambda (_) #f)]) (load-collections-xref))))) I've tried it in DrScheme (on my Windows laptop, so the delay is more noticeable), and it looks like it works fine. No need for multicore support... 7. Maybe this would be a good addition to `scheme/promise'. ;; Run `thunk' when idle, slicing the time to `slice'-second frames, ;; using only `use' seconds from each frame. Return a thunk that ;; returns the result of the computation, giving it full cpu if it's not ;; ready yet. (define (run-lazily thunk #:slice [slice 0.3] #:use [use 0.05]) (define idle-evt (system-idle-evt)) (define force-sema (make-semaphore 0)) (define results #f) (define (work) (with-handlers ([void (lambda (e) (set! results (cons raise e)))]) (set! results (cons values (call-with-values thunk list))))) (define (start) (sync idle-evt) (let ([worker (parameterize ([current-thread-group (make-thread-group)]) (thread work))]) (thread-suspend worker) (let loop () ;; rest, then wait for idle time, then resume working (if (eq? (begin0 (or (sync/timeout (- slice use) force-sema) (sync idle-evt force-sema)) (thread-resume worker)) force-sema) ;; forced during one of these => let it run to completion (thread-wait worker) ;; not forced (unless (sync/timeout use worker) (thread-suspend worker) (loop)))))) (define main-thread (parameterize ([current-thread-group (make-thread-group)]) (thread start))) (lambda () (unless (thread-dead? main-thread) (semaphore-post force-sema) (thread-wait main-thread)) (apply (car results) (cdr results)))) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From robby at eecs.northwestern.edu Mon Nov 9 17:13:34 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Mon Nov 9 17:13:55 2009 Subject: [plt-dev] Re: Speed up check-syntax In-Reply-To: <19192.37625.138009.868012@winooski.ccs.neu.edu> References: <595b9ab20911090556u5115e7dfpfdd863588ea3fb34@mail.gmail.com> <932b2f1f0911090828p72588563o9f83f758af475041@mail.gmail.com> <932b2f1f0911091009jec184kbe02b576da713d42@mail.gmail.com> <932b2f1f0911091022y3344aa69qc928e555ad5c7e15@mail.gmail.com> <932b2f1f0911091055s435613c6oa3668c80afbcf509@mail.gmail.com> <19192.37625.138009.868012@winooski.ccs.neu.edu> Message-ID: <932b2f1f0911091413q248c6675y6aeea8c260b2cdd5@mail.gmail.com> Thanks, Eli. That looks nice. Matthew suggested something similar, but using mzlib/couroutine, where I use a low-priority gui callback to give the thread the next quantum. Robby On Mon, Nov 9, 2009 at 4:08 PM, Eli Barzilay wrote: > [Moving to plt-dev.] > > On Nov ?9, Robby Findler wrote: >> >> I find such behavior annoying in my OS and expect it would be the >> same in DrScheme. Things will be sluggish while it is loading. >> >> Nevertheless, I will try this if the parallelism stuff doesn't pan >> out. > > 1. I find the delay-on-first-syncheck especially annoying in class. ?I > ? always start a new drscheme at the beginning of the class, which > ? means that I'm guaranteed to get the annoying delay. ?(And it's a > ? classic case of unjustified delay, since drscheme will sit there > ? for many minutes doing nothing before I get to use it.) ?It's at a > ? level where I hesitate to use it -- and on some occasions I > ? pre-arrange myself so that I click it while I speak to mask out the > ? delay. ?(Being able to do such things is something that I had to > ? learn as a stutterer...) > > 2. BTW, the status-line message is not showing at all on linux. ?I > ? never knew that there was supposed to be such a message. ?(I almost > ? never run it on my laptop.) > > 3. IMO, the issue will not be completely resolved with multiple > ? cores. ?What if my other core is busy doing something else? ?What > ? about school machines that can be very outdated? ?What about IO > ? delays, since this does involve mostly IO? > > 4. The usual way to do these things is to have it loaded when it is > ? idle (exactly what Stephen said) -- but then don't just start to > ? load it so everything becomes slow, just do that in little > ? execution chunks which are done only if the system is still > ? otherwise idle. ?I think that MzScheme could use some more > ? functionality in this area -- a nice feature to have would be a way > ? for a thread to change its priority where this can also be a "run > ? me only when otherwise idle" (it would be especially nice to have a > ? hierarchy of these: "run me when otherwise idle including 1st-level > ? idle-priority threads, and give me only 20% running time"). > > 5. Fantasies aside, I think that it is possible to do a reasonable job > ? for this given the current tools. ?The code below looks to me like > ? it should work fine. ?It runs a given thunk in the background while > ? drscheme is idle, and using little cpu time so there's no alarming > ? cpu load. ?The returned result is a thunk that returns the computed > ? value -- waiting for it (while giving it 100% cpu) if it isn't > ? ready yet. > > 6. To try it, I basically changed "syncheck.ss" with this definition: > > ? ? (define get-xref > ? ? ? (run-lazily (lambda () > ? ? ? ? ? ? ? ? ? ? (with-handlers ([exn? (lambda (_) #f)]) > ? ? ? ? ? ? ? ? ? ? ? (load-collections-xref))))) > > ? I've tried it in DrScheme (on my Windows laptop, so the delay is > ? more noticeable), and it looks like it works fine. ?No need for > ? multicore support... > > 7. Maybe this would be a good addition to `scheme/promise'. > > > > ;; Run `thunk' when idle, slicing the time to `slice'-second frames, > ;; using only `use' seconds from each frame. ?Return a thunk that > ;; returns the result of the computation, giving it full cpu if it's not > ;; ready yet. > (define (run-lazily thunk #:slice [slice 0.3] #:use [use 0.05]) > ?(define idle-evt (system-idle-evt)) > ?(define force-sema (make-semaphore 0)) > ?(define results #f) > ?(define (work) > ? ?(with-handlers ([void (lambda (e) (set! results (cons raise e)))]) > ? ? ?(set! results (cons values (call-with-values thunk list))))) > ?(define (start) > ? ?(sync idle-evt) > ? ?(let ([worker (parameterize ([current-thread-group (make-thread-group)]) > ? ? ? ? ? ? ? ? ? ?(thread work))]) > ? ? ?(thread-suspend worker) > ? ? ?(let loop () > ? ? ? ?;; rest, then wait for idle time, then resume working > ? ? ? ?(if (eq? (begin0 (or (sync/timeout (- slice use) force-sema) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? (sync idle-evt force-sema)) > ? ? ? ? ? ? ? ? ? (thread-resume worker)) > ? ? ? ? ? ? ? ? force-sema) > ? ? ? ? ?;; forced during one of these => let it run to completion > ? ? ? ? ?(thread-wait worker) > ? ? ? ? ?;; not forced > ? ? ? ? ?(unless (sync/timeout use worker) (thread-suspend worker) (loop)))))) > ?(define main-thread > ? ?(parameterize ([current-thread-group (make-thread-group)]) > ? ? ?(thread start))) > ?(lambda () > ? ?(unless (thread-dead? main-thread) > ? ? ?(semaphore-post force-sema) > ? ? ?(thread-wait main-thread)) > ? ?(apply (car results) (cdr results)))) > > -- > ? ? ? ? ?((lambda (x) (x x)) (lambda (x) (x x))) ? ? ? ? ?Eli Barzilay: > ? ? ? ? ? ? ? ? ? ?http://barzilay.org/ ? ? ? ? ? ? ? ? ? Maze is Life! > From robby at eecs.northwestern.edu Mon Nov 9 17:15:07 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Mon Nov 9 17:15:28 2009 Subject: [plt-dev] Re: Speed up check-syntax In-Reply-To: <932b2f1f0911091413q248c6675y6aeea8c260b2cdd5@mail.gmail.com> References: <595b9ab20911090556u5115e7dfpfdd863588ea3fb34@mail.gmail.com> <932b2f1f0911090828p72588563o9f83f758af475041@mail.gmail.com> <932b2f1f0911091009jec184kbe02b576da713d42@mail.gmail.com> <932b2f1f0911091022y3344aa69qc928e555ad5c7e15@mail.gmail.com> <932b2f1f0911091055s435613c6oa3668c80afbcf509@mail.gmail.com> <19192.37625.138009.868012@winooski.ccs.neu.edu> <932b2f1f0911091413q248c6675y6aeea8c260b2cdd5@mail.gmail.com> Message-ID: <932b2f1f0911091415g335bd603w2e113fc6aad276c4@mail.gmail.com> PS: feel free to check this in, but it probably belongs in scribble/xref or setup/xref, not in the syntax checker. Robby On Mon, Nov 9, 2009 at 4:13 PM, Robby Findler wrote: > Thanks, Eli. That looks nice. > > Matthew suggested something similar, but using mzlib/couroutine, where > I use a low-priority gui callback to give the thread the next quantum. > > Robby > > On Mon, Nov 9, 2009 at 4:08 PM, Eli Barzilay wrote: >> [Moving to plt-dev.] >> >> On Nov ?9, Robby Findler wrote: >>> >>> I find such behavior annoying in my OS and expect it would be the >>> same in DrScheme. Things will be sluggish while it is loading. >>> >>> Nevertheless, I will try this if the parallelism stuff doesn't pan >>> out. >> >> 1. I find the delay-on-first-syncheck especially annoying in class. ?I >> ? always start a new drscheme at the beginning of the class, which >> ? means that I'm guaranteed to get the annoying delay. ?(And it's a >> ? classic case of unjustified delay, since drscheme will sit there >> ? for many minutes doing nothing before I get to use it.) ?It's at a >> ? level where I hesitate to use it -- and on some occasions I >> ? pre-arrange myself so that I click it while I speak to mask out the >> ? delay. ?(Being able to do such things is something that I had to >> ? learn as a stutterer...) >> >> 2. BTW, the status-line message is not showing at all on linux. ?I >> ? never knew that there was supposed to be such a message. ?(I almost >> ? never run it on my laptop.) >> >> 3. IMO, the issue will not be completely resolved with multiple >> ? cores. ?What if my other core is busy doing something else? ?What >> ? about school machines that can be very outdated? ?What about IO >> ? delays, since this does involve mostly IO? >> >> 4. The usual way to do these things is to have it loaded when it is >> ? idle (exactly what Stephen said) -- but then don't just start to >> ? load it so everything becomes slow, just do that in little >> ? execution chunks which are done only if the system is still >> ? otherwise idle. ?I think that MzScheme could use some more >> ? functionality in this area -- a nice feature to have would be a way >> ? for a thread to change its priority where this can also be a "run >> ? me only when otherwise idle" (it would be especially nice to have a >> ? hierarchy of these: "run me when otherwise idle including 1st-level >> ? idle-priority threads, and give me only 20% running time"). >> >> 5. Fantasies aside, I think that it is possible to do a reasonable job >> ? for this given the current tools. ?The code below looks to me like >> ? it should work fine. ?It runs a given thunk in the background while >> ? drscheme is idle, and using little cpu time so there's no alarming >> ? cpu load. ?The returned result is a thunk that returns the computed >> ? value -- waiting for it (while giving it 100% cpu) if it isn't >> ? ready yet. >> >> 6. To try it, I basically changed "syncheck.ss" with this definition: >> >> ? ? (define get-xref >> ? ? ? (run-lazily (lambda () >> ? ? ? ? ? ? ? ? ? ? (with-handlers ([exn? (lambda (_) #f)]) >> ? ? ? ? ? ? ? ? ? ? ? (load-collections-xref))))) >> >> ? I've tried it in DrScheme (on my Windows laptop, so the delay is >> ? more noticeable), and it looks like it works fine. ?No need for >> ? multicore support... >> >> 7. Maybe this would be a good addition to `scheme/promise'. >> >> >> >> ;; Run `thunk' when idle, slicing the time to `slice'-second frames, >> ;; using only `use' seconds from each frame. ?Return a thunk that >> ;; returns the result of the computation, giving it full cpu if it's not >> ;; ready yet. >> (define (run-lazily thunk #:slice [slice 0.3] #:use [use 0.05]) >> ?(define idle-evt (system-idle-evt)) >> ?(define force-sema (make-semaphore 0)) >> ?(define results #f) >> ?(define (work) >> ? ?(with-handlers ([void (lambda (e) (set! results (cons raise e)))]) >> ? ? ?(set! results (cons values (call-with-values thunk list))))) >> ?(define (start) >> ? ?(sync idle-evt) >> ? ?(let ([worker (parameterize ([current-thread-group (make-thread-group)]) >> ? ? ? ? ? ? ? ? ? ?(thread work))]) >> ? ? ?(thread-suspend worker) >> ? ? ?(let loop () >> ? ? ? ?;; rest, then wait for idle time, then resume working >> ? ? ? ?(if (eq? (begin0 (or (sync/timeout (- slice use) force-sema) >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? (sync idle-evt force-sema)) >> ? ? ? ? ? ? ? ? ? (thread-resume worker)) >> ? ? ? ? ? ? ? ? force-sema) >> ? ? ? ? ?;; forced during one of these => let it run to completion >> ? ? ? ? ?(thread-wait worker) >> ? ? ? ? ?;; not forced >> ? ? ? ? ?(unless (sync/timeout use worker) (thread-suspend worker) (loop)))))) >> ?(define main-thread >> ? ?(parameterize ([current-thread-group (make-thread-group)]) >> ? ? ?(thread start))) >> ?(lambda () >> ? ?(unless (thread-dead? main-thread) >> ? ? ?(semaphore-post force-sema) >> ? ? ?(thread-wait main-thread)) >> ? ?(apply (car results) (cdr results)))) >> >> -- >> ? ? ? ? ?((lambda (x) (x x)) (lambda (x) (x x))) ? ? ? ? ?Eli Barzilay: >> ? ? ? ? ? ? ? ? ? ?http://barzilay.org/ ? ? ? ? ? ? ? ? ? Maze is Life! >> > From eli at barzilay.org Mon Nov 9 17:26:17 2009 From: eli at barzilay.org (Eli Barzilay) Date: Mon Nov 9 17:26:37 2009 Subject: [plt-dev] Re: Speed up check-syntax In-Reply-To: <932b2f1f0911091413q248c6675y6aeea8c260b2cdd5@mail.gmail.com>, <932b2f1f0911091415g335bd603w2e113fc6aad276c4@mail.gmail.com> References: <595b9ab20911090556u5115e7dfpfdd863588ea3fb34@mail.gmail.com> <932b2f1f0911090828p72588563o9f83f758af475041@mail.gmail.com> <932b2f1f0911091009jec184kbe02b576da713d42@mail.gmail.com> <932b2f1f0911091022y3344aa69qc928e555ad5c7e15@mail.gmail.com> <932b2f1f0911091055s435613c6oa3668c80afbcf509@mail.gmail.com> <19192.37625.138009.868012@winooski.ccs.neu.edu> <932b2f1f0911091413q248c6675y6aeea8c260b2cdd5@mail.gmail.com> <932b2f1f0911091415g335bd603w2e113fc6aad276c4@mail.gmail.com> Message-ID: <19192.38665.305259.237558@winooski.ccs.neu.edu> On Nov 9, Robby Findler wrote: > Thanks, Eli. That looks nice. > > Matthew suggested something similar, but using mzlib/couroutine, > where I use a low-priority gui callback to give the thread the next > quantum. Is there any advantage for that? On Nov 9, Robby Findler wrote: > PS: feel free to check this in, but it probably belongs in > scribble/xref or setup/xref, not in the syntax checker. I'll probably put it in `scheme/promise' as some `delay/idle', so it works with `force' as usual. (There is some concern if there are several of these things active -- if both use the same delay values, then one can starve the other. But I don't think that this is a problem since it's used only for idle computations.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From samth at ccs.neu.edu Mon Nov 9 18:26:33 2009 From: samth at ccs.neu.edu (Sam TH) Date: Mon Nov 9 18:27:11 2009 Subject: [plt-dev] slideshow, X Windows, and multiple monitors Message-ID: <63bb19ae0911091526r4d8406c6r13ffd198bd025ada@mail.gmail.com> I recently acquired a second monitor, and now Slideshow attempts to display everything centered between the two monitors, which isn't really what I want. DrScheme itself is able to maximize properly on only one monitor, although it displays the splash screen pretty close to the center. This is on Ubuntu 9.10. Unfortunately, this makes it pretty hard to develop my talks at the moment. -- sam th samth@ccs.neu.edu From samth at ccs.neu.edu Mon Nov 9 19:10:35 2009 From: samth at ccs.neu.edu (Sam TH) Date: Mon Nov 9 20:45:51 2009 Subject: [plt-dev] bug with `scale' in slideshow Message-ID: <63bb19ae0911091610q4541ef65h8ba8423ff950460f@mail.gmail.com> Right now, the `scale' function in slideshow is very broken. Here's a screenshot. It appears to be scaling the bounding box, but not drawing the image any differently, so it just crops the image. This appears not to happen on OSX; I haven't tried Windows. -- sam th samth@ccs.neu.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: scale.png Type: image/png Size: 167715 bytes Desc: not available Url : http://list.cs.brown.edu/pipermail/plt-dev/attachments/20091109/1f3c9beb/scale-0001.png From robby at eecs.northwestern.edu Mon Nov 9 20:48:16 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Mon Nov 9 20:48:37 2009 Subject: [plt-dev] Re: [plt-scheme] Speed up check-syntax In-Reply-To: <19192.38665.305259.237558@winooski.ccs.neu.edu> References: <595b9ab20911090556u5115e7dfpfdd863588ea3fb34@mail.gmail.com> <932b2f1f0911091022y3344aa69qc928e555ad5c7e15@mail.gmail.com> <932b2f1f0911091055s435613c6oa3668c80afbcf509@mail.gmail.com> <19192.37625.138009.868012@winooski.ccs.neu.edu> <932b2f1f0911091413q248c6675y6aeea8c260b2cdd5@mail.gmail.com> <932b2f1f0911091415g335bd603w2e113fc6aad276c4@mail.gmail.com> <19192.38665.305259.237558@winooski.ccs.neu.edu> Message-ID: <932b2f1f0911091748j2b00abe9maafcef28cd328a6b@mail.gmail.com> I would guess it would be a better fit for GUI interactivity. Use a low priority callback to trigger each quantum of work. Robby On Monday, November 9, 2009, Eli Barzilay wrote: > On Nov ?9, Robby Findler wrote: >> Thanks, Eli. That looks nice. >> >> Matthew suggested something similar, but using mzlib/couroutine, >> where I use a low-priority gui callback to give the thread the next >> quantum. > > Is there any advantage for that? > > > On Nov ?9, Robby Findler wrote: >> PS: feel free to check this in, but it probably belongs in >> scribble/xref or setup/xref, not in the syntax checker. > > I'll probably put it in `scheme/promise' as some `delay/idle', so it > works with `force' as usual. > > (There is some concern if there are several of these things active -- > if both use the same delay values, then one can starve the other. ?But > I don't think that this is a problem since it's used only for idle > computations.) > > -- > ? ? ? ? ?((lambda (x) (x x)) (lambda (x) (x x))) ? ? ? ? ?Eli Barzilay: > ? ? ? ? ? ? ? ? ? ?http://barzilay.org/ ? ? ? ? ? ? ? ? ? Maze is Life! > From eli at barzilay.org Mon Nov 9 20:51:10 2009 From: eli at barzilay.org (Eli Barzilay) Date: Mon Nov 9 20:51:30 2009 Subject: [plt-dev] Re: [plt-scheme] Speed up check-syntax In-Reply-To: <932b2f1f0911091748j2b00abe9maafcef28cd328a6b@mail.gmail.com> References: <595b9ab20911090556u5115e7dfpfdd863588ea3fb34@mail.gmail.com> <932b2f1f0911091022y3344aa69qc928e555ad5c7e15@mail.gmail.com> <932b2f1f0911091055s435613c6oa3668c80afbcf509@mail.gmail.com> <19192.37625.138009.868012@winooski.ccs.neu.edu> <932b2f1f0911091413q248c6675y6aeea8c260b2cdd5@mail.gmail.com> <932b2f1f0911091415g335bd603w2e113fc6aad276c4@mail.gmail.com> <19192.38665.305259.237558@winooski.ccs.neu.edu> <932b2f1f0911091748j2b00abe9maafcef28cd328a6b@mail.gmail.com> Message-ID: <19192.50958.514385.949549@winooski.ccs.neu.edu> On Nov 9, Robby Findler wrote: > I would guess it would be a better fit for GUI interactivity. Use a > low priority callback to trigger each quantum of work. I think that in general the idle timer is even better than a low priority callback -- I was concerned that there's some constant gui activity that will make the idle timer solution starve, but it doesn't look like that's a problem. (Maybe it will be when more stuff is done in Scheme?) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From mflatt at cs.utah.edu Mon Nov 9 21:03:22 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Mon Nov 9 21:03:46 2009 Subject: [plt-dev] Re: [plt-scheme] Speed up check-syntax In-Reply-To: <932b2f1f0911091748j2b00abe9maafcef28cd328a6b@mail.gmail.com> References: <595b9ab20911090556u5115e7dfpfdd863588ea3fb34@mail.gmail.com> <932b2f1f0911091022y3344aa69qc928e555ad5c7e15@mail.gmail.com> <932b2f1f0911091055s435613c6oa3668c80afbcf509@mail.gmail.com> <19192.37625.138009.868012@winooski.ccs.neu.edu> <932b2f1f0911091413q248c6675y6aeea8c260b2cdd5@mail.gmail.com> <932b2f1f0911091415g335bd603w2e113fc6aad276c4@mail.gmail.com> <19192.38665.305259.237558@winooski.ccs.neu.edu> <932b2f1f0911091748j2b00abe9maafcef28cd328a6b@mail.gmail.com> Message-ID: <20091110020324.623976500C7@mail-svr1.cs.utah.edu> Although I previously suggested a low-priority event callback, `system-idle-evt' seems even better. The `system-idle-evt' function didn't exist when we implemented syntax coloring as a background task. Using `system-idle-event' stays out of the way of other GUI events in the same way as a low-priority callback, and since `system-idle-evt' is fair (or is supposed to be), multiple background tasks should work fine, allowing each a turn when no other work is available. Low-priority callbacks, meanwhile, effectively have a higher priority than threads blocked on `system-idle-evt'. So, maybe it's good that syntax coloring uses callbacks, since that will give it a higher priority than loading cross-reference information. At Mon, 9 Nov 2009 19:48:16 -0600, Robby Findler wrote: > I would guess it would be a better fit for GUI interactivity. Use a > low priority callback to trigger each quantum of work. > > Robby > > On Monday, November 9, 2009, Eli Barzilay wrote: > > On Nov ?9, Robby Findler wrote: > >> Thanks, Eli. That looks nice. > >> > >> Matthew suggested something similar, but using mzlib/couroutine, > >> where I use a low-priority gui callback to give the thread the next > >> quantum. > > > > Is there any advantage for that? > > > > > > On Nov ?9, Robby Findler wrote: > >> PS: feel free to check this in, but it probably belongs in > >> scribble/xref or setup/xref, not in the syntax checker. > > > > I'll probably put it in `scheme/promise' as some `delay/idle', so it > > works with `force' as usual. > > > > (There is some concern if there are several of these things active -- > > if both use the same delay values, then one can starve the other. ?But > > I don't think that this is a problem since it's used only for idle > > computations.) > > > > -- > > ? ? ? ? ?((lambda (x) (x x)) (lambda (x) (x x))) ? ? ? ? ?Eli Barzilay: > > ? ? ? ? ? ? ? ? ? ?http://barzilay.org/ ? ? ? ? ? ? ? ? ? Maze is Life! > > > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From mflatt at cs.utah.edu Mon Nov 9 21:04:35 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Mon Nov 9 21:04:56 2009 Subject: [plt-dev] Re: [plt-scheme] Speed up check-syntax In-Reply-To: <19192.50958.514385.949549@winooski.ccs.neu.edu> References: <595b9ab20911090556u5115e7dfpfdd863588ea3fb34@mail.gmail.com> <932b2f1f0911091022y3344aa69qc928e555ad5c7e15@mail.gmail.com> <932b2f1f0911091055s435613c6oa3668c80afbcf509@mail.gmail.com> <19192.37625.138009.868012@winooski.ccs.neu.edu> <932b2f1f0911091413q248c6675y6aeea8c260b2cdd5@mail.gmail.com> <932b2f1f0911091415g335bd603w2e113fc6aad276c4@mail.gmail.com> <19192.38665.305259.237558@winooski.ccs.neu.edu> <932b2f1f0911091748j2b00abe9maafcef28cd328a6b@mail.gmail.com> <19192.50958.514385.949549@winooski.ccs.neu.edu> Message-ID: <20091110020437.4C8466500BE@mail-svr1.cs.utah.edu> At Mon, 9 Nov 2009 20:51:10 -0500, Eli Barzilay wrote: > I was concerned that there's some constant gui > activity that will make the idle timer solution starve, but it doesn't > look like that's a problem. (Maybe it will be when more stuff is done > in Scheme?) No, there should never be a task that's always running. From eli at barzilay.org Mon Nov 9 21:16:53 2009 From: eli at barzilay.org (Eli Barzilay) Date: Mon Nov 9 21:17:15 2009 Subject: [plt-dev] Re: [plt-scheme] Speed up check-syntax In-Reply-To: <20091110020324.623976500C7@mail-svr1.cs.utah.edu> References: <595b9ab20911090556u5115e7dfpfdd863588ea3fb34@mail.gmail.com> <932b2f1f0911091022y3344aa69qc928e555ad5c7e15@mail.gmail.com> <932b2f1f0911091055s435613c6oa3668c80afbcf509@mail.gmail.com> <19192.37625.138009.868012@winooski.ccs.neu.edu> <932b2f1f0911091413q248c6675y6aeea8c260b2cdd5@mail.gmail.com> <932b2f1f0911091415g335bd603w2e113fc6aad276c4@mail.gmail.com> <19192.38665.305259.237558@winooski.ccs.neu.edu> <932b2f1f0911091748j2b00abe9maafcef28cd328a6b@mail.gmail.com> <20091110020324.623976500C7@mail-svr1.cs.utah.edu> Message-ID: <19192.52501.888921.267454@winooski.ccs.neu.edu> On Nov 9, Matthew Flatt wrote: > > Low-priority callbacks, meanwhile, effectively have a higher > priority than threads blocked on `system-idle-evt'. So, maybe it's > good that syntax coloring uses callbacks, since that will give it a > higher priority than loading cross-reference information. That's what I was fantasizing on previously -- in terms of that message, low priority callbacks and idle events make two levels. (And yes, the idle event as an "I really don't care when it runs, just move it out of the way" is something that fits the xref loading well, but not the colorer.) BTW, one thing that I don't like about my code is that it first sleeps, then waits for an idle event. My first thought was that it should wait for the system to be idle for some time before it kicks in. It's not possible to do this now, right? (Modulo some ridiculous busy-wait loop that keeps polling the event.) Is it possible to add something that will make it possible? (In theory there's not much point in doing this if the time slices that I'm using are smaller than what matters for human interaction, but when resources like IO are involved, it might make things feel a little less responsive.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From rafkind at cs.utah.edu Mon Nov 9 21:19:40 2009 From: rafkind at cs.utah.edu (Jon Rafkind) Date: Mon Nov 9 21:22:50 2009 Subject: [plt-dev] Re: [plt-scheme] Speed up check-syntax In-Reply-To: <19192.52501.888921.267454@winooski.ccs.neu.edu> References: <595b9ab20911090556u5115e7dfpfdd863588ea3fb34@mail.gmail.com> <932b2f1f0911091022y3344aa69qc928e555ad5c7e15@mail.gmail.com> <932b2f1f0911091055s435613c6oa3668c80afbcf509@mail.gmail.com> <19192.37625.138009.868012@winooski.ccs.neu.edu> <932b2f1f0911091413q248c6675y6aeea8c260b2cdd5@mail.gmail.com> <932b2f1f0911091415g335bd603w2e113fc6aad276c4@mail.gmail.com> <19192.38665.305259.237558@winooski.ccs.neu.edu> <932b2f1f0911091748j2b00abe9maafcef28cd328a6b@mail.gmail.com> <20091110020324.623976500C7@mail-svr1.cs.utah.edu> <19192.52501.888921.267454@winooski.ccs.neu.edu> Message-ID: <4AF8CDBC.60300@cs.utah.edu> Eli Barzilay wrote: > On Nov 9, Matthew Flatt wrote: > >> Low-priority callbacks, meanwhile, effectively have a higher >> priority than threads blocked on `system-idle-evt'. So, maybe it's >> good that syntax coloring uses callbacks, since that will give it a >> higher priority than loading cross-reference information. >> > > That's what I was fantasizing on previously -- in terms of that > message, low priority callbacks and idle events make two levels. (And > yes, the idle event as an "I really don't care when it runs, just move > it out of the way" is something that fits the xref loading well, but > not the colorer.) > > BTW, one thing that I don't like about my code is that it first > sleeps, then waits for an idle event. My first thought was that it > should wait for the system to be idle for some time before it kicks > in. It's not possible to do this now, right? (Modulo some ridiculous > busy-wait loop that keeps polling the event.) Is it possible to add > something that will make it possible? > > I noticed there was some new `futures' code in src/mzscheme/future.c. Aren't futures exactly whats required here? > (In theory there's not much point in doing this if the time slices > that I'm using are smaller than what matters for human interaction, > but when resources like IO are involved, it might make things feel a > little less responsive.) > > From robby at eecs.northwestern.edu Mon Nov 9 21:25:08 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Mon Nov 9 21:25:30 2009 Subject: [plt-dev] Re: [plt-scheme] Speed up check-syntax In-Reply-To: <4AF8CDBC.60300@cs.utah.edu> References: <595b9ab20911090556u5115e7dfpfdd863588ea3fb34@mail.gmail.com> <19192.37625.138009.868012@winooski.ccs.neu.edu> <932b2f1f0911091413q248c6675y6aeea8c260b2cdd5@mail.gmail.com> <932b2f1f0911091415g335bd603w2e113fc6aad276c4@mail.gmail.com> <19192.38665.305259.237558@winooski.ccs.neu.edu> <932b2f1f0911091748j2b00abe9maafcef28cd328a6b@mail.gmail.com> <20091110020324.623976500C7@mail-svr1.cs.utah.edu> <19192.52501.888921.267454@winooski.ccs.neu.edu> <4AF8CDBC.60300@cs.utah.edu> Message-ID: <932b2f1f0911091825p2540ca75j861a9494ddc1568@mail.gmail.com> Futures are the parallel construct that James Swaine is working on. Likely it won't be a good fit for this, but James is going to run some tests to be sure. Robby On Mon, Nov 9, 2009 at 8:19 PM, Jon Rafkind wrote: > Eli Barzilay wrote: >> >> On Nov ?9, Matthew Flatt wrote: >> >>> >>> Low-priority callbacks, meanwhile, effectively have a higher >>> priority than threads blocked on `system-idle-evt'. So, maybe it's >>> good that syntax coloring uses callbacks, since that will give it a >>> higher priority than loading cross-reference information. >>> >> >> That's what I was fantasizing on previously -- in terms of that >> message, low priority callbacks and idle events make two levels. ?(And >> yes, the idle event as an "I really don't care when it runs, just move >> it out of the way" is something that fits the xref loading well, but >> not the colorer.) >> >> BTW, one thing that I don't like about my code is that it first >> sleeps, then waits for an idle event. ?My first thought was that it >> should wait for the system to be idle for some time before it kicks >> in. ?It's not possible to do this now, right? ?(Modulo some ridiculous >> busy-wait loop that keeps polling the event.) ?Is it possible to add >> something that will make it possible? >> >> > > I noticed there was some new `futures' code in src/mzscheme/future.c. Aren't > futures exactly whats required here? >> >> (In theory there's not much point in doing this if the time slices >> that I'm using are smaller than what matters for human interaction, >> but when resources like IO are involved, it might make things feel a >> little less responsive.) >> >> > > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > From mflatt at cs.utah.edu Mon Nov 9 22:28:05 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Mon Nov 9 22:28:25 2009 Subject: [plt-dev] Release for v4.2.3 is about to begin Message-ID: <20091110032807.948C16500CF@mail-svr1.cs.utah.edu> The release process for v4.2.3 will begin in about one week (on the 15th). This means that the trunk is going to be copied into a branch -- please make sure that code that you're responsible for is as stable as possible, and let Eli know if there is any new work that should not be included in this release. >> NOW IS THE TIME TO FIX BUGS THAT YOU KNOW ABOUT <<< The time between the branch and the actual release is for fixing new errors that prevent a proper functioning of major components and that show up during the preparation for a release. From matthias at ccs.neu.edu Tue Nov 10 12:20:14 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Tue Nov 10 12:20:39 2009 Subject: [plt-dev] component delivery, a social experiment Message-ID: <352C77E5-AE2A-4BE7-A486-C4BCA8977056@ccs.neu.edu> Ladies and gentlemen, Eli spent my first hour++ in my office this morning pointing our serious flaws in our world. Here are two important points, and I am putting them up for discussion here with a request for sensible comments: 1. In some way we have been conducting a social experiment for the past 10 days or so. As you all know, Eli spent a considerable time creating the nightly build framework when he first arrived here. From the nightly build, Eli's software also creates a nightly set of deliveries and puts them up on the web somewhere. What you ma not realize is that the nightly builds have been broken for some 10 days due to the check-in of a module that breaks the component delivery mechanism. Nobody complained, so our conclusion was that nobody noticed. Our second corollary was that perhaps we only have a camel-back distribution of users: those who use svn and build from svn and those that use only the releases. (As Eli walked out of my office, I switched to my email and the first message contained a complaint about the missing nightly deliveries. This means we know of one user of the deliveries.) 2. Which brings me to the topic of "delivery by component." Apparently few, if anyone here, is aware of Eli's carefully arrange delivery layers: -- smallest: plain mzscheme, no mred, no docs -- mid size: mred, drscheme, no docs -- largest: everything Eli tells me that there are numerous people who use 'smallest'; I don't know about mid. He (and I and I know Robby) have for a long time envisioned a delivery system that starts with a core package and then asks (possibly via some gui) what other packages should be installed, e.g., the 'mred' layer or the server. The three-tier delivery system is a first step toward this component-oriented delivery. Eli has carefully maintained a dependency graph and list (that takes some 11megs) among the various files (8 platforms, 3 tiers, everything spelled out). Since people aren't really aware of this system, they easily and apparently relatively often break the non-cyclic dependencies. (I am guilty of doing this myself when I wrote the first docs that depended on slideshow.) In my opinion, we have two options: -- drop the dependency system and just deliver one large package -- enforce the dependencies. If you break them, you get a message. If you don't clean them up in N hours, the file is removed. ;; --- As I said, sensible comments welcome. -- Matthias From robby at eecs.northwestern.edu Tue Nov 10 12:50:45 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Tue Nov 10 12:51:07 2009 Subject: [plt-dev] component delivery, a social experiment In-Reply-To: <352C77E5-AE2A-4BE7-A486-C4BCA8977056@ccs.neu.edu> References: <352C77E5-AE2A-4BE7-A486-C4BCA8977056@ccs.neu.edu> Message-ID: <932b2f1f0911100950y782adaf9j57aa8d9c6bef620a@mail.gmail.com> I, for one, am quite happy that we have a nightly build and hope that we continue to have it. I suspect that anyone that uses Windows and wants to keep up from SVN also benefits, since building under Windows is not an easy thing to do (unlike the other platforms we support). I don't think the option two below you mention is feasible, simply because removing the file is likely to break the build in some other way. But perhaps we can have some other Bad Thing that happens (public blame anyone?) when someone breaks the build that would help get us back in shape quickly. Robby PS: for the record, I complained twice to Eli about the currently broken build, once when I noticed it because I wanted to point someone to recent docs and then later when someone else contacted me about it. So "no one noticed" is just plain wrong. On Tue, Nov 10, 2009 at 11:20 AM, Matthias Felleisen wrote: > > Ladies and gentlemen, > > Eli spent my first hour++ in my office this morning pointing our serious > flaws in our world. Here are two important points, and I am putting them up > for discussion here with a request for sensible comments: > > 1. In some way we have been conducting a social experiment for the past 10 > days or so. As you all know, Eli spent a considerable time creating the > nightly build framework when he first arrived here. From the nightly build, > Eli's software also creates a nightly set of deliveries and puts them up on > the web somewhere. What you ma not realize is that the nightly builds have > been broken for some 10 days due to the check-in of a module that breaks the > component delivery mechanism. > > Nobody complained, so our conclusion was that nobody noticed. Our second > corollary was that perhaps we only have a camel-back distribution of users: > those who use svn and build from svn and those that use only the releases. > (As Eli walked out of my office, I switched to my email and the first > message contained a complaint about the missing nightly deliveries. This > means we know of one user of the deliveries.) > > 2. Which brings me to the topic of "delivery by component." Apparently few, > if anyone here, is aware of Eli's carefully arrange delivery layers: > > ?-- smallest: plain mzscheme, no mred, no docs > ?-- mid size: mred, drscheme, no docs > ?-- largest: ?everything > > Eli tells me that there are numerous people who use 'smallest'; I don't know > about mid. > > He (and I and I know Robby) have for a long time envisioned a delivery > system that starts with a core package and then asks (possibly via some gui) > what other packages should be installed, e.g., the 'mred' layer or the > server. The three-tier delivery system is a first step toward this > component-oriented delivery. > > Eli has carefully maintained a dependency graph and list (that takes some > 11megs) among the various files (8 platforms, 3 tiers, everything spelled > out). Since people aren't really aware of this system, they easily and > apparently relatively often break the non-cyclic dependencies. (I am guilty > of doing this myself when I wrote the first docs that depended on > slideshow.) > > In my opinion, we have two options: > > ?-- drop the dependency system and just deliver one large package > ?-- enforce the dependencies. If you break them, you get a message. > ? ?If you don't clean them up in N hours, the file is removed. > > ;; --- > > As I said, sensible comments welcome. -- Matthias > > > > > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > From ryanc at ccs.neu.edu Tue Nov 10 13:15:19 2009 From: ryanc at ccs.neu.edu (Ryan Culpepper) Date: Tue Nov 10 13:15:42 2009 Subject: [plt-dev] component delivery, a social experiment In-Reply-To: <352C77E5-AE2A-4BE7-A486-C4BCA8977056@ccs.neu.edu> References: <352C77E5-AE2A-4BE7-A486-C4BCA8977056@ccs.neu.edu> Message-ID: On Nov 10, 2009, at 12:20 PM, Matthias Felleisen wrote: > [...] > > 2. Which brings me to the topic of "delivery by component." > Apparently few, if anyone here, is aware of Eli's carefully arrange > delivery layers: > > -- smallest: plain mzscheme, no mred, no docs > -- mid size: mred, drscheme, no docs > -- largest: everything > > Eli tells me that there are numerous people who use 'smallest'; I > don't know about mid. > > He (and I and I know Robby) have for a long time envisioned a > delivery system that starts with a core package and then asks > (possibly via some gui) what other packages should be installed, > e.g., the 'mred' layer or the server. The three-tier delivery system > is a first step toward this component-oriented delivery. > > Eli has carefully maintained a dependency graph and list (that takes > some 11megs) among the various files (8 platforms, 3 tiers, > everything spelled out). Since people aren't really aware of this > system, they easily and apparently relatively often break the non- > cyclic dependencies. (I am guilty of doing this myself when I wrote > the first docs that depended on slideshow.) Are these three tiers documented anywhere? It's difficult to follow rules you don't know. It's also difficult to make suggestions about an opaque system. 11MB sounds huge. I have no idea what to make of that number. Is there a reason why we can't shrink the specification of the tiers to something more manageable? Best of all would be if we could, at least for the collections, embed the tier separation rules within the code itself (eg, info.ss files or similar). Then we could make the standard module name resolver enforce the rules automatically, giving developers immediate notice of breakage. > In my opinion, we have two options: > > -- drop the dependency system and just deliver one large package > -- enforce the dependencies. If you break them, you get a message. > If you don't clean them up in N hours, the file is removed. How about having an email automatically go out to plt-dev if the nightly build fails? Perhaps with a record of the svn commits that might have triggered the failure, if that's feasible. Ryan From samth at ccs.neu.edu Tue Nov 10 13:58:05 2009 From: samth at ccs.neu.edu (Sam TH) Date: Tue Nov 10 13:58:42 2009 Subject: [plt-dev] component delivery, a social experiment In-Reply-To: <932b2f1f0911100950y782adaf9j57aa8d9c6bef620a@mail.gmail.com> References: <352C77E5-AE2A-4BE7-A486-C4BCA8977056@ccs.neu.edu> <932b2f1f0911100950y782adaf9j57aa8d9c6bef620a@mail.gmail.com> Message-ID: <63bb19ae0911101058t16018a2an3e2f00d370e75b87@mail.gmail.com> On Tue, Nov 10, 2009 at 12:50 PM, Robby Findler wrote: > I, for one, am quite happy that we have a nightly build and hope that > we continue to have it. I suspect that anyone that uses Windows and > wants to keep up from SVN also benefits, since building under Windows > is not an easy thing to do (unlike the other platforms we support). I know other people who use the nightly build regularly on Windows. And the nightly build docs are quite valuable. I've also benefited from the nightly build catching bugs that I've introduced. > I don't think the option two below you mention is feasible, simply > because removing the file is likely to break the build in some other > way. But perhaps we can have some other Bad Thing that happens (public > blame anyone?) when someone breaks the build that would help get us > back in shape quickly. It would be nice if DrDr could check this information, especially once DrDr is down to zero errors normally. > PS: for the record, I complained twice to Eli about the currently > broken build, once when I noticed it because I wanted to point someone > to recent docs and then later when someone else contacted me about it. > So "no one noticed" is just plain wrong. I also noticed, because I wanted to point to the recent docs, and mentioned this to Eli. -- sam th samth@ccs.neu.edu From robby at eecs.northwestern.edu Tue Nov 10 13:58:48 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Tue Nov 10 13:59:05 2009 Subject: [plt-dev] component delivery, a social experiment In-Reply-To: References: <352C77E5-AE2A-4BE7-A486-C4BCA8977056@ccs.neu.edu> Message-ID: <932b2f1f0911101058n2092cfdav59fa4f11cfe48aeb@mail.gmail.com> On Tue, Nov 10, 2009 at 12:15 PM, Ryan Culpepper wrote: > How about having an email automatically go out to plt-dev if the nightly > build fails? Perhaps with a record of the svn commits that might have > triggered the failure, if that's feasible. I believe DrDr will fill this role eventually. Robby From matthias at ccs.neu.edu Tue Nov 10 14:00:19 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Tue Nov 10 14:00:46 2009 Subject: [plt-dev] component delivery, a social experiment In-Reply-To: <63bb19ae0911101058t16018a2an3e2f00d370e75b87@mail.gmail.com> References: <352C77E5-AE2A-4BE7-A486-C4BCA8977056@ccs.neu.edu> <932b2f1f0911100950y782adaf9j57aa8d9c6bef620a@mail.gmail.com> <63bb19ae0911101058t16018a2an3e2f00d370e75b87@mail.gmail.com> Message-ID: Small note: do not confuse the nightly build with the delivery of its results. From jay.mccarthy at gmail.com Tue Nov 10 14:02:51 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Tue Nov 10 14:03:29 2009 Subject: [plt-dev] component delivery, a social experiment In-Reply-To: <932b2f1f0911101058n2092cfdav59fa4f11cfe48aeb@mail.gmail.com> References: <352C77E5-AE2A-4BE7-A486-C4BCA8977056@ccs.neu.edu> <932b2f1f0911101058n2092cfdav59fa4f11cfe48aeb@mail.gmail.com> Message-ID: Yes, once we get rid of the false errors, I will flip the switch to turn on nagging from DrDr. Jay On Tue, Nov 10, 2009 at 11:58 AM, Robby Findler wrote: > On Tue, Nov 10, 2009 at 12:15 PM, Ryan Culpepper wrote: >> How about having an email automatically go out to plt-dev if the nightly >> build fails? Perhaps with a record of the svn commits that might have >> triggered the failure, if that's feasible. > > I believe DrDr will fill this role eventually. > > Robby > _________________________________________________ > ?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 jay.mccarthy at gmail.com Tue Nov 10 14:03:27 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Tue Nov 10 14:03:54 2009 Subject: [plt-dev] component delivery, a social experiment In-Reply-To: <63bb19ae0911101058t16018a2an3e2f00d370e75b87@mail.gmail.com> References: <352C77E5-AE2A-4BE7-A486-C4BCA8977056@ccs.neu.edu> <932b2f1f0911100950y782adaf9j57aa8d9c6bef620a@mail.gmail.com> <63bb19ae0911101058t16018a2an3e2f00d370e75b87@mail.gmail.com> Message-ID: On Tue, Nov 10, 2009 at 11:58 AM, Sam TH wrote: > On Tue, Nov 10, 2009 at 12:50 PM, Robby Findler > wrote: >> I, for one, am quite happy that we have a nightly build and hope that >> we continue to have it. I suspect that anyone that uses Windows and >> wants to keep up from SVN also benefits, since building under Windows >> is not an easy thing to do (unlike the other platforms we support). > > I know other people who use the nightly build regularly on Windows. > And the nightly build docs are quite valuable. ?I've also benefited > from the nightly build catching bugs that I've introduced. > >> I don't think the option two below you mention is feasible, simply >> because removing the file is likely to break the build in some other >> way. But perhaps we can have some other Bad Thing that happens (public >> blame anyone?) when someone breaks the build that would help get us >> back in shape quickly. > > It would be nice if DrDr could check this information, especially once > DrDr is down to zero errors normally. If we can encode the conditions as a test in the tree, it will just start checking it. Jay > >> PS: for the record, I complained twice to Eli about the currently >> broken build, once when I noticed it because I wanted to point someone >> to recent docs and then later when someone else contacted me about it. >> So "no one noticed" is just plain wrong. > > I also noticed, because I wanted to point to the recent docs, and > mentioned this to Eli. > -- > sam th > samth@ccs.neu.edu > _________________________________________________ > ?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 dherman at ccs.neu.edu Tue Nov 10 14:14:15 2009 From: dherman at ccs.neu.edu (Dave Herman) Date: Tue Nov 10 14:14:50 2009 Subject: [plt-dev] component delivery, a social experiment In-Reply-To: <63bb19ae0911101058t16018a2an3e2f00d370e75b87@mail.gmail.com> References: <352C77E5-AE2A-4BE7-A486-C4BCA8977056@ccs.neu.edu> <932b2f1f0911100950y782adaf9j57aa8d9c6bef620a@mail.gmail.com> <63bb19ae0911101058t16018a2an3e2f00d370e75b87@mail.gmail.com> Message-ID: <4AF9BB87.4000906@ccs.neu.edu> >> I, for one, am quite happy that we have a nightly build and hope that >> we continue to have it. I suspect that anyone that uses Windows and >> wants to keep up from SVN also benefits, since building under Windows >> is not an easy thing to do (unlike the other platforms we support). > > I know other people who use the nightly build regularly on Windows. > And the nightly build docs are quite valuable. I've also benefited > from the nightly build catching bugs that I've introduced. FWIW: I always use the nightly builds, both in Windows and MacOS. (I coroutine between theorems and programs for my research, and I've been in theorem-proving mode, so I haven't updated DrScheme in a couple months-- which is why I didn't notice this time when it went down.) Dave From jos.koot at telefonica.net Tue Nov 10 18:26:11 2009 From: jos.koot at telefonica.net (Jos Koot) Date: Tue Nov 10 18:26:36 2009 Subject: [plt-dev] component delivery, a social experiment References: <352C77E5-AE2A-4BE7-A486-C4BCA8977056@ccs.neu.edu> Message-ID: <63CDA3711ACB4898A2C82D4A9545DD97@uw2b2dff239c4d> I frequently check for new prereleased PLT Scheme Full and allways download the most recent version (in windows xp) Two weeks without a newer release is longer than normal, but in the past it frequently occurred that the most recent release was a week old or so I was not worried. I hope downloading prerelease PLT Scheme Full will remain as easy as it is now. Jos ----- Original Message ----- From: "Matthias Felleisen" To: "PLT Developers" Sent: Tuesday, November 10, 2009 6:20 PM Subject: [plt-dev] component delivery, a social experiment > > Ladies and gentlemen, > > Eli spent my first hour++ in my office this morning pointing our serious flaws in our world. Here are two important points, and I > am putting them up for discussion here with a request for sensible comments: > > 1. In some way we have been conducting a social experiment for the past 10 days or so. As you all know, Eli spent a considerable > time creating the nightly build framework when he first arrived here. From the nightly build, Eli's software also creates a > nightly set of deliveries and puts them up on the web somewhere. What you ma not realize is that the nightly builds have been > broken for some 10 days due to the check-in of a module that breaks the component delivery mechanism. > > Nobody complained, so our conclusion was that nobody noticed. Our second corollary was that perhaps we only have a camel-back > distribution of users: those who use svn and build from svn and those that use only the releases. (As Eli walked out of my > office, I switched to my email and the first message contained a complaint about the missing nightly deliveries. This means we > know of one user of the deliveries.) > > 2. Which brings me to the topic of "delivery by component." Apparently few, if anyone here, is aware of Eli's carefully arrange > delivery layers: > > -- smallest: plain mzscheme, no mred, no docs > -- mid size: mred, drscheme, no docs > -- largest: everything > > Eli tells me that there are numerous people who use 'smallest'; I don't know about mid. > > He (and I and I know Robby) have for a long time envisioned a delivery system that starts with a core package and then asks > (possibly via some gui) what other packages should be installed, e.g., the 'mred' layer or the server. The three-tier delivery > system is a first step toward this component-oriented delivery. > > Eli has carefully maintained a dependency graph and list (that takes some 11megs) among the various files (8 platforms, 3 tiers, > everything spelled out). Since people aren't really aware of this system, they easily and apparently relatively often break the > non-cyclic dependencies. (I am guilty of doing this myself when I wrote the first docs that depended on slideshow.) > > In my opinion, we have two options: > > -- drop the dependency system and just deliver one large package > -- enforce the dependencies. If you break them, you get a message. > If you don't clean them up in N hours, the file is removed. > > ;; --- > > As I said, sensible comments welcome. -- Matthias > > > > > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev > From robby at eecs.northwestern.edu Wed Nov 11 08:15:26 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Wed Nov 11 08:15:47 2009 Subject: [plt-dev] slideshow, X Windows, and multiple monitors In-Reply-To: <63bb19ae0911091526r4d8406c6r13ffd198bd025ada@mail.gmail.com> References: <63bb19ae0911091526r4d8406c6r13ffd198bd025ada@mail.gmail.com> Message-ID: <932b2f1f0911110515q6a7a6a51m69e87e677bdb76c8@mail.gmail.com> Sam and I discussed this on IRC a while back and it seems that the difference between mac os x and x is that get-display-size returns the size of the main monitor under mac os x and the size of a bounding box surrounding all of the monitors under unix. Robby On Monday, November 9, 2009, Sam TH wrote: > I recently acquired a second monitor, and now Slideshow attempts to > display everything centered between the two monitors, which isn't > really what I want. ?DrScheme itself is able to maximize properly on > only one monitor, although it displays the splash screen pretty close > to the center. This is on Ubuntu 9.10. > > Unfortunately, this makes it pretty hard to develop my talks at the moment. > -- > sam th > samth@ccs.neu.edu > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > From matthias at ccs.neu.edu Wed Nov 11 10:25:20 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Wed Nov 11 10:25:45 2009 Subject: [plt-dev] component delivery, a social experiment In-Reply-To: <352C77E5-AE2A-4BE7-A486-C4BCA8977056@ccs.neu.edu> References: <352C77E5-AE2A-4BE7-A486-C4BCA8977056@ccs.neu.edu> Message-ID: Thanks for the responses. The responses propose three natural things: 1. We need the nightly builds. 2. Eli's component rules must be turned into something that people can read up on. 3. The email about rule violations should not go to Eli but to plt- dev. (It's all implemented, no need to shift it anywhere.) ;; --- There were no comments on component-oriented distribution. -- Matthias On Nov 10, 2009, at 12:20 PM, Matthias Felleisen wrote: > > Ladies and gentlemen, > > Eli spent my first hour++ in my office this morning pointing our > serious flaws in our world. Here are two important points, and I am > putting them up for discussion here with a request for sensible > comments: > > 1. In some way we have been conducting a social experiment for the > past 10 days or so. As you all know, Eli spent a considerable time > creating the nightly build framework when he first arrived here. > From the nightly build, Eli's software also creates a nightly set of > deliveries and puts them up on the web somewhere. What you ma not > realize is that the nightly builds have been broken for some 10 days > due to the check-in of a module that breaks the component delivery > mechanism. > > Nobody complained, so our conclusion was that nobody noticed. Our > second corollary was that perhaps we only have a camel-back > distribution of users: those who use svn and build from svn and > those that use only the releases. (As Eli walked out of my office, I > switched to my email and the first message contained a complaint > about the missing nightly deliveries. This means we know of one user > of the deliveries.) > > 2. Which brings me to the topic of "delivery by component." > Apparently few, if anyone here, is aware of Eli's carefully arrange > delivery layers: > > -- smallest: plain mzscheme, no mred, no docs > -- mid size: mred, drscheme, no docs > -- largest: everything > > Eli tells me that there are numerous people who use 'smallest'; I > don't know about mid. > > He (and I and I know Robby) have for a long time envisioned a > delivery system that starts with a core package and then asks > (possibly via some gui) what other packages should be installed, > e.g., the 'mred' layer or the server. The three-tier delivery system > is a first step toward this component-oriented delivery. > > Eli has carefully maintained a dependency graph and list (that takes > some 11megs) among the various files (8 platforms, 3 tiers, > everything spelled out). Since people aren't really aware of this > system, they easily and apparently relatively often break the non- > cyclic dependencies. (I am guilty of doing this myself when I wrote > the first docs that depended on slideshow.) > > In my opinion, we have two options: > > -- drop the dependency system and just deliver one large package > -- enforce the dependencies. If you break them, you get a message. > If you don't clean them up in N hours, the file is removed. > > ;; --- > > As I said, sensible comments welcome. -- Matthias > > > > > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From matthias at ccs.neu.edu Wed Nov 11 11:01:14 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Wed Nov 11 13:29:22 2009 Subject: [plt-dev] anyone know Chronium? Message-ID: It's basically a version of Jay's drdr system: http://dev.chromium.org/developers/testing/chromium-build-infrastructure/tour-of-the-chromium-buildbot "Chromium uses an open-source system called Buildbot to run continuous builds and tests." Anyone know about it? Any advantages over Jay's? -- Matthias From jay.mccarthy at gmail.com Wed Nov 11 11:57:20 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Wed Nov 11 13:33:30 2009 Subject: [plt-dev] component delivery, a social experiment In-Reply-To: References: <352C77E5-AE2A-4BE7-A486-C4BCA8977056@ccs.neu.edu> Message-ID: I personally don't see any value in leaving out the docs or DrScheme. Everything is so small anyways and hard drive space is cheap... I don't get the use case. Jay On Wed, Nov 11, 2009 at 8:25 AM, Matthias Felleisen wrote: > > Thanks for the responses. The responses propose three natural things: > > 1. We need the nightly builds. > > 2. Eli's component rules must be turned into something that people can read > up on. > > 3. The email about rule violations should not go to Eli but to plt-dev. > (It's all implemented, no need to shift it anywhere.) > > ;; --- > > There were no comments on component-oriented distribution. > > -- Matthias > > > > > > > > On Nov 10, 2009, at 12:20 PM, Matthias Felleisen wrote: > >> >> Ladies and gentlemen, >> >> Eli spent my first hour++ in my office this morning pointing our serious >> flaws in our world. Here are two important points, and I am putting them up >> for discussion here with a request for sensible comments: >> >> 1. In some way we have been conducting a social experiment for the past 10 >> days or so. As you all know, Eli spent a considerable time creating the >> nightly build framework when he first arrived here. From the nightly build, >> Eli's software also creates a nightly set of deliveries and puts them up on >> the web somewhere. What you ma not realize is that the nightly builds have >> been broken for some 10 days due to the check-in of a module that breaks the >> component delivery mechanism. >> >> Nobody complained, so our conclusion was that nobody noticed. Our second >> corollary was that perhaps we only have a camel-back distribution of users: >> those who use svn and build from svn and those that use only the releases. >> (As Eli walked out of my office, I switched to my email and the first >> message contained a complaint about the missing nightly deliveries. This >> means we know of one user of the deliveries.) >> >> 2. Which brings me to the topic of "delivery by component." Apparently >> few, if anyone here, is aware of Eli's carefully arrange delivery layers: >> >> -- smallest: plain mzscheme, no mred, no docs >> -- mid size: mred, drscheme, no docs >> -- largest: ?everything >> >> Eli tells me that there are numerous people who use 'smallest'; I don't >> know about mid. >> >> He (and I and I know Robby) have for a long time envisioned a delivery >> system that starts with a core package and then asks (possibly via some gui) >> what other packages should be installed, e.g., the 'mred' layer or the >> server. The three-tier delivery system is a first step toward this >> component-oriented delivery. >> >> Eli has carefully maintained a dependency graph and list (that takes some >> 11megs) among the various files (8 platforms, 3 tiers, everything spelled >> out). Since people aren't really aware of this system, they easily and >> apparently relatively often break the non-cyclic dependencies. (I am guilty >> of doing this myself when I wrote the first docs that depended on >> slideshow.) >> >> In my opinion, we have two options: >> >> -- drop the dependency system and just deliver one large package >> -- enforce the dependencies. If you break them, you get a message. >> ? If you don't clean them up in N hours, the file is removed. >> >> ;; --- >> >> As I said, sensible comments welcome. -- 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 dherman at ccs.neu.edu Wed Nov 11 13:37:13 2009 From: dherman at ccs.neu.edu (Dave Herman) Date: Wed Nov 11 13:37:55 2009 Subject: [plt-dev] anyone know Chronium? In-Reply-To: References: Message-ID: <4AFB0459.3010503@ccs.neu.edu> > It's basically a version of Jay's drdr system: No, Chromium is a web browser. They *use* buildbot, which is a continuous build system: http://buildbot.net/trac Dave From matthias at ccs.neu.edu Wed Nov 11 13:41:48 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Wed Nov 11 13:42:16 2009 Subject: [plt-dev] anyone know Chronium? In-Reply-To: <4AFB0459.3010503@ccs.neu.edu> References: <4AFB0459.3010503@ccs.neu.edu> Message-ID: Sorry for the misleading subject line. I of course meant buildbot as the message should have made abundantly clear. On Nov 11, 2009, at 1:37 PM, Dave Herman wrote: >> It's basically a version of Jay's drdr system: > > No, Chromium is a web browser. They *use* buildbot, which is a > continuous build system: > > http://buildbot.net/trac > > Dave > From samth at ccs.neu.edu Wed Nov 11 13:46:58 2009 From: samth at ccs.neu.edu (Sam TH) Date: Wed Nov 11 13:47:39 2009 Subject: [plt-dev] component delivery, a social experiment In-Reply-To: References: <352C77E5-AE2A-4BE7-A486-C4BCA8977056@ccs.neu.edu> Message-ID: <63bb19ae0911111046m6138d77fq7054fe4e36959318@mail.gmail.com> On Wed, Nov 11, 2009 at 11:57 AM, Jay McCarthy wrote: > I personally don't see any value in leaving out the docs or DrScheme. > Everything is so small anyways and hard drive space is cheap... I > don't get the use case. I believe that there are people who want to install the text interface on systems where GUI libraries are not available. But beyond that, I don't see a point. However, before we make this hard, we might want to talk to the people who package PLT for Fedora/Debian/etc. sam th > > Jay > > On Wed, Nov 11, 2009 at 8:25 AM, Matthias Felleisen > wrote: >> >> Thanks for the responses. The responses propose three natural things: >> >> 1. We need the nightly builds. >> >> 2. Eli's component rules must be turned into something that people can read >> up on. >> >> 3. The email about rule violations should not go to Eli but to plt-dev. >> (It's all implemented, no need to shift it anywhere.) >> >> ;; --- >> >> There were no comments on component-oriented distribution. >> >> -- Matthias >> >> >> >> >> >> >> >> On Nov 10, 2009, at 12:20 PM, Matthias Felleisen wrote: >> >>> >>> Ladies and gentlemen, >>> >>> Eli spent my first hour++ in my office this morning pointing our serious >>> flaws in our world. Here are two important points, and I am putting them up >>> for discussion here with a request for sensible comments: >>> >>> 1. In some way we have been conducting a social experiment for the past 10 >>> days or so. As you all know, Eli spent a considerable time creating the >>> nightly build framework when he first arrived here. From the nightly build, >>> Eli's software also creates a nightly set of deliveries and puts them up on >>> the web somewhere. What you ma not realize is that the nightly builds have >>> been broken for some 10 days due to the check-in of a module that breaks the >>> component delivery mechanism. >>> >>> Nobody complained, so our conclusion was that nobody noticed. Our second >>> corollary was that perhaps we only have a camel-back distribution of users: >>> those who use svn and build from svn and those that use only the releases. >>> (As Eli walked out of my office, I switched to my email and the first >>> message contained a complaint about the missing nightly deliveries. This >>> means we know of one user of the deliveries.) >>> >>> 2. Which brings me to the topic of "delivery by component." Apparently >>> few, if anyone here, is aware of Eli's carefully arrange delivery layers: >>> >>> -- smallest: plain mzscheme, no mred, no docs >>> -- mid size: mred, drscheme, no docs >>> -- largest: ?everything >>> >>> Eli tells me that there are numerous people who use 'smallest'; I don't >>> know about mid. >>> >>> He (and I and I know Robby) have for a long time envisioned a delivery >>> system that starts with a core package and then asks (possibly via some gui) >>> what other packages should be installed, e.g., the 'mred' layer or the >>> server. The three-tier delivery system is a first step toward this >>> component-oriented delivery. >>> >>> Eli has carefully maintained a dependency graph and list (that takes some >>> 11megs) among the various files (8 platforms, 3 tiers, everything spelled >>> out). Since people aren't really aware of this system, they easily and >>> apparently relatively often break the non-cyclic dependencies. (I am guilty >>> of doing this myself when I wrote the first docs that depended on >>> slideshow.) >>> >>> In my opinion, we have two options: >>> >>> -- drop the dependency system and just deliver one large package >>> -- enforce the dependencies. If you break them, you get a message. >>> ? If you don't clean them up in N hours, the file is removed. >>> >>> ;; --- >>> >>> As I said, sensible comments welcome. -- 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 > -- sam th samth@ccs.neu.edu From grettke at acm.org Wed Nov 11 13:49:05 2009 From: grettke at acm.org (Grant Rettke) Date: Wed Nov 11 13:49:24 2009 Subject: [plt-dev] component delivery, a social experiment In-Reply-To: <63bb19ae0911111046m6138d77fq7054fe4e36959318@mail.gmail.com> References: <352C77E5-AE2A-4BE7-A486-C4BCA8977056@ccs.neu.edu> <63bb19ae0911111046m6138d77fq7054fe4e36959318@mail.gmail.com> Message-ID: <756daca50911111049l22480e27sa1d503f8c3fb226b@mail.gmail.com> On Wed, Nov 11, 2009 at 12:46 PM, Sam TH wrote: > On Wed, Nov 11, 2009 at 11:57 AM, Jay McCarthy wrote: >> I personally don't see any value in leaving out the docs or DrScheme. >> Everything is so small anyways and hard drive space is cheap... I >> don't get the use case. > > I believe that there are people who want to install the text interface > on systems where GUI libraries are not available. ?But beyond that, I > don't see a point. ?However, before we make this hard, we might want > to talk to the people who package PLT for Fedora/Debian/etc. Some people don't use PLT because it is perceived as "bloated". They would like a download that has only mzscheme and no documentation or IDE. From yinso.chen at gmail.com Wed Nov 11 13:55:30 2009 From: yinso.chen at gmail.com (YC) Date: Wed Nov 11 13:55:53 2009 Subject: [plt-dev] component delivery, a social experiment In-Reply-To: References: <352C77E5-AE2A-4BE7-A486-C4BCA8977056@ccs.neu.edu> Message-ID: <779bf2730911111055t302b2732i97ca1291ddba068c@mail.gmail.com> I like the availability of a mzscheme-only package - it allows you to deploy a minimal system in a production environment. Thanks, yc On Wed, Nov 11, 2009 at 8:57 AM, Jay McCarthy wrote: > I personally don't see any value in leaving out the docs or DrScheme. > Everything is so small anyways and hard drive space is cheap... I > don't get the use case. > > Jay > > On Wed, Nov 11, 2009 at 8:25 AM, Matthias Felleisen > wrote: > > > > Thanks for the responses. The responses propose three natural things: > > > > 1. We need the nightly builds. > > > > 2. Eli's component rules must be turned into something that people can > read > > up on. > > > > 3. The email about rule violations should not go to Eli but to plt-dev. > > (It's all implemented, no need to shift it anywhere.) > > > > ;; --- > > > > There were no comments on component-oriented distribution. > > > > -- Matthias > > > > > > > > > > > > > > > > On Nov 10, 2009, at 12:20 PM, Matthias Felleisen wrote: > > > >> > >> Ladies and gentlemen, > >> > >> Eli spent my first hour++ in my office this morning pointing our serious > >> flaws in our world. Here are two important points, and I am putting them > up > >> for discussion here with a request for sensible comments: > >> > >> 1. In some way we have been conducting a social experiment for the past > 10 > >> days or so. As you all know, Eli spent a considerable time creating the > >> nightly build framework when he first arrived here. From the nightly > build, > >> Eli's software also creates a nightly set of deliveries and puts them up > on > >> the web somewhere. What you ma not realize is that the nightly builds > have > >> been broken for some 10 days due to the check-in of a module that breaks > the > >> component delivery mechanism. > >> > >> Nobody complained, so our conclusion was that nobody noticed. Our second > >> corollary was that perhaps we only have a camel-back distribution of > users: > >> those who use svn and build from svn and those that use only the > releases. > >> (As Eli walked out of my office, I switched to my email and the first > >> message contained a complaint about the missing nightly deliveries. This > >> means we know of one user of the deliveries.) > >> > >> 2. Which brings me to the topic of "delivery by component." Apparently > >> few, if anyone here, is aware of Eli's carefully arrange delivery > layers: > >> > >> -- smallest: plain mzscheme, no mred, no docs > >> -- mid size: mred, drscheme, no docs > >> -- largest: everything > >> > >> Eli tells me that there are numerous people who use 'smallest'; I don't > >> know about mid. > >> > >> He (and I and I know Robby) have for a long time envisioned a delivery > >> system that starts with a core package and then asks (possibly via some > gui) > >> what other packages should be installed, e.g., the 'mred' layer or the > >> server. The three-tier delivery system is a first step toward this > >> component-oriented delivery. > >> > >> Eli has carefully maintained a dependency graph and list (that takes > some > >> 11megs) among the various files (8 platforms, 3 tiers, everything > spelled > >> out). Since people aren't really aware of this system, they easily and > >> apparently relatively often break the non-cyclic dependencies. (I am > guilty > >> of doing this myself when I wrote the first docs that depended on > >> slideshow.) > >> > >> In my opinion, we have two options: > >> > >> -- drop the dependency system and just deliver one large package > >> -- enforce the dependencies. If you break them, you get a message. > >> If you don't clean them up in N hours, the file is removed. > >> > >> ;; --- > >> > >> As I said, sensible comments welcome. -- 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://list.cs.brown.edu/pipermail/plt-dev/attachments/20091111/271e0d78/attachment-0001.html From jay.mccarthy at gmail.com Wed Nov 11 14:12:16 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Wed Nov 11 14:12:38 2009 Subject: [plt-dev] anyone know Chronium? In-Reply-To: References: Message-ID: They have many machines coordinating different builds and tests. Their tests were written to cooperate with this, while DrDr takes things mostly as is. They provide more information as they run, whereas I show nothing until it is over. I looked at some of these systems before writing DrDr and found it hard to adapt them to our environment. I am willing to switch my machine to something else if people want it (and will set it up.) Pride also suggests that using Python is lame. :P Jay On Wed, Nov 11, 2009 at 9:01 AM, Matthias Felleisen wrote: > > It's basically a version of Jay's drdr system: > > ?http://dev.chromium.org/developers/testing/chromium-build-infrastructure/tour-of-the-chromium-buildbot > ?"Chromium uses an open-source system called Buildbot to run continuous > builds and tests." > > Anyone know about it? Any advantages over Jay's? -- Matthias > > _________________________________________________ > ?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 neil at neilvandyke.org Wed Nov 11 14:21:07 2009 From: neil at neilvandyke.org (Neil Van Dyke) Date: Wed Nov 11 14:21:27 2009 Subject: [plt-dev] component delivery, a social experiment In-Reply-To: <779bf2730911111055t302b2732i97ca1291ddba068c@mail.gmail.com> References: <352C77E5-AE2A-4BE7-A486-C4BCA8977056@ccs.neu.edu> <779bf2730911111055t302b2732i97ca1291ddba068c@mail.gmail.com> Message-ID: <4AFB0EA3.2040107@neilvandyke.org> YC wrote at 11/11/2009 01:55 PM: > I like the availability of a mzscheme-only package - it allows you to > deploy a minimal system in a production environment. > This could be the more important use case for providing a stripped-down packaging of PLT: people who want to run the PLT Web server for real server deployments. Size matters, especially if you're paying for disk space to a managed-server hoster or cloud hoster. But even if you're hosting your own servers with big disks, having to install all the GUI and docs on each server reduces credibility (unless PLT makes a case somewhere for having a "full development environment" on every deployed server). -- http://www.neilvandyke.org/ From grettke at acm.org Wed Nov 11 15:46:07 2009 From: grettke at acm.org (Grant Rettke) Date: Wed Nov 11 15:46:26 2009 Subject: [plt-dev] anyone know Chronium? In-Reply-To: References: Message-ID: <756daca50911111246q37e97b48g361242c1bdfa3616@mail.gmail.com> On Wed, Nov 11, 2009 at 1:12 PM, Jay McCarthy wrote: > Their tests were written to cooperate with this, while DrDr takes > things mostly as is. How much of DrDr is a generic continuous integration tool and how much of it is about tailoring the build and testing to accommodate for the current testing approaches for the PLT system? From jay.mccarthy at gmail.com Wed Nov 11 15:51:33 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Wed Nov 11 15:51:53 2009 Subject: [plt-dev] anyone know Chronium? In-Reply-To: <756daca50911111246q37e97b48g361242c1bdfa3616@mail.gmail.com> References: <756daca50911111246q37e97b48g361242c1bdfa3616@mail.gmail.com> Message-ID: It is very generic but does a few things that only make sense for PLT and it makes your "configuration file" a program that uses the library. It is also a very small amount of code: about 2k lines. Jay On Wed, Nov 11, 2009 at 1:46 PM, Grant Rettke wrote: > On Wed, Nov 11, 2009 at 1:12 PM, Jay McCarthy wrote: >> Their tests were written to cooperate with this, while DrDr takes >> things mostly as is. > > How much of DrDr is a generic continuous integration tool and how much > of it is about tailoring the build and testing to accommodate for the > current testing approaches for the PLT system? > -- 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 Thu Nov 12 13:46:29 2009 From: clements at brinckerhoff.org (John Clements) Date: Thu Nov 12 13:46:53 2009 Subject: [plt-dev] define-match-expander <-> unlib.plt doesn't compile Message-ID: Unlib.plt doesn't compile, as you (Sam) reported several weeks ago. I tried to fix the problem, and started wondering whether the underlying problem was whether 'define-match-expander' was working incorrectly. For instance, what should this program produce? foo.ss: #lang scheme (define-match-expander my-cons (error 'dontcare "aagh!") cons) (provide (rename-out [my-cons cons])) bar.ss: #lang scheme (require "foo.ss") (cons 3 4) Reading the docs, it looks like it should produce the pair containing 3 and 4, but it actually signals the error. It appears to me that the untyped folks are (mis?)reading the docs in the same way I am. Am I wrong, or is define-match-expander broken, or is something else going on? Thanks, 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/20091112/c90d70b9/smime.bin From carl.eastlund at gmail.com Thu Nov 12 13:59:18 2009 From: carl.eastlund at gmail.com (Carl Eastlund) Date: Thu Nov 12 13:59:55 2009 Subject: [plt-dev] define-match-expander <-> unlib.plt doesn't compile In-Reply-To: References: Message-ID: <990e0c030911121059q15d16ea3j18d7beb37d1a6feb@mail.gmail.com> On Thu, Nov 12, 2009 at 1:46 PM, John Clements wrote: > Unlib.plt doesn't compile, as you (Sam) reported several weeks ago. I tried > to fix the problem, and started wondering whether the underlying problem was > whether 'define-match-expander' was working incorrectly. ?For instance, what > should this program produce? > > foo.ss: > > #lang scheme > > (define-match-expander my-cons > ?(error 'dontcare "aagh!") > ?cons) > > (provide (rename-out [my-cons cons])) > > bar.ss: > > #lang scheme > > (require "foo.ss") > > (cons 3 4) > > Reading the docs, it looks like it should produce the pair containing 3 and > 4, but it actually signals the error. It appears to me that the untyped > folks are (mis?)reading the docs in the same way I am. > > Am I wrong, or is define-match-expander broken, or is something else going > on? > > Thanks, > > John John, Looks right to me. The define-match-expander form takes two expressions, both of which are evaluated immediately at phase 1 (compile-time) to produce transformers. It's basically define-syntax for a different kind of binding. You are writing as if it were define-syntax-rule, where you just fill in a pattern. Replace your use of it with: (define-match-expander my-cons (lambda (stx) (error 'dontcare "aagh!")) (syntax-rules () [(_ a b) (cons a b)])) Then you'll probably get the behavior you expected. --Carl From d.j.gurnell at gmail.com Thu Nov 12 14:08:26 2009 From: d.j.gurnell at gmail.com (Dave Gurnell) Date: Thu Nov 12 14:08:47 2009 Subject: [plt-dev] define-match-expander <-> unlib.plt doesn't compile In-Reply-To: <990e0c030911121059q15d16ea3j18d7beb37d1a6feb@mail.gmail.com> References: <990e0c030911121059q15d16ea3j18d7beb37d1a6feb@mail.gmail.com> Message-ID: <9A2585B0-E022-4FA8-81CF-BD090D26407B@gmail.com> Carl Eastlund wrote: > John, > > Looks right to me. The define-match-expander form takes two > expressions, both of which are evaluated immediately at phase 1 > (compile-time) to produce transformers. It's basically define-syntax > for a different kind of binding. You are writing as if it were > define-syntax-rule, where you just fill in a pattern. Replace your > use of it with: > > (define-match-expander my-cons > (lambda (stx) (error 'dontcare "aagh!")) > (syntax-rules () [(_ a b) (cons a b)])) > > Then you'll probably get the behavior you expected. > > --Carl Gah! Apologies again for moving so slowly on this. I'll try to fix it now. Two things: 1. If I uninstall Unlib and try: planet install untyped unlib.plt 3 18 I get a heck of a lot of Scribble errors, but I don't get any failure to compile. I'm using an older PLT... $ mzscheme -v Welcome to MzScheme v4.2.1.5 [3m], Copyright (c) 2004-2009 PLT Scheme Inc. 2. If John's looking at define-match-expander, the culprit must be this bit in match.ss in Unlib: ; (_ expr pattern ...) (define-match-expander match:eq? (syntax-rules () [(_ expr pattern ...) (? (cut eq? <> expr) pattern ...)]) eq?) ; (_ expr pattern ...) (define-match-expander match:equal? (syntax-rules () [(_ expr pattern ...) (? (cut equal? <> expr) pattern ...)]) equal?) I guess the second argument should be a syntax transformer procedure. The documentation seems to be ambiguous on this, although it's a pretty dumb misunderstanding on my part. -- Dave From d.j.gurnell at gmail.com Thu Nov 12 14:16:44 2009 From: d.j.gurnell at gmail.com (Dave Gurnell) Date: Thu Nov 12 14:17:03 2009 Subject: [plt-dev] define-match-expander <-> unlib.plt doesn't compile In-Reply-To: <990e0c030911121059q15d16ea3j18d7beb37d1a6feb@mail.gmail.com> References: <990e0c030911121059q15d16ea3j18d7beb37d1a6feb@mail.gmail.com> Message-ID: <69C84EEF-52AC-429E-964F-AA1EE10E16BF@gmail.com> I've uploaded Unlib 3.19 containing a fix for the match problem. -- Dave From clements at brinckerhoff.org Thu Nov 12 15:10:46 2009 From: clements at brinckerhoff.org (John Clements) Date: Thu Nov 12 15:11:20 2009 Subject: [plt-dev] define-match-expander <-> unlib.plt doesn't compile In-Reply-To: <69C84EEF-52AC-429E-964F-AA1EE10E16BF@gmail.com> References: <990e0c030911121059q15d16ea3j18d7beb37d1a6feb@mail.gmail.com> <69C84EEF-52AC-429E-964F-AA1EE10E16BF@gmail.com> Message-ID: On Nov 12, 2009, at 11:16 AM, Dave Gurnell wrote: > I've uploaded Unlib 3.19 containing a fix for the match problem. Awesome fixed now thanks all. 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/20091112/de236e70/smime.bin From clements at brinckerhoff.org Thu Nov 12 18:02:37 2009 From: clements at brinckerhoff.org (John Clements) Date: Thu Nov 12 18:03:00 2009 Subject: [plt-dev] Scrolling of files with large snips Message-ID: <4AEE6300-4038-4697-9451-6A2252342ECA@brinckerhoff.org> It looks like DrScheme buffers manage scroll positions using the line- at-the-top-of-the-screen. This means that for large snips--those taller than the window--there's no way to see the bottom half of the snip, because there's no intermediate scroll position between line- with-the-big-snip and (+ 1 line-with-the-big-snip). E.G.: Evaluate this program: (require 2htdp/image) (circle 500 "solid" "yellow") On the Mac, for screens less than 1000 pixels tall, there appears to be no way to inspect the bottom part of the circle. IIUC, this is not a bug but a change request. I guess the best question might be this: is this the kind of thing that might be fixed by the re-implementation of wx in scheme, or not? 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/20091112/7d7d3fb7/smime.bin From robby at eecs.northwestern.edu Thu Nov 12 18:07:51 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Thu Nov 12 18:08:11 2009 Subject: [plt-dev] Scrolling of files with large snips In-Reply-To: <4AEE6300-4038-4697-9451-6A2252342ECA@brinckerhoff.org> References: <4AEE6300-4038-4697-9451-6A2252342ECA@brinckerhoff.org> Message-ID: <932b2f1f0911121507k33bba6acgb17aa439d120e83f@mail.gmail.com> This is fixable with the current tools. It is, I believe, easy to say make scroll positions every 15 pixels (or some other fixed number). Less easy to make them at the height of the font generally in the buffer, tho. (Matthew: any hints?) Robby On Thu, Nov 12, 2009 at 5:02 PM, John Clements wrote: > It looks like DrScheme buffers manage scroll positions using the > line-at-the-top-of-the-screen. ?This means that for large snips--those > taller than the window--there's no way to see the bottom half of the snip, > because there's no intermediate scroll position between > line-with-the-big-snip and (+ 1 line-with-the-big-snip). > > E.G.: ?Evaluate this program: > > (require 2htdp/image) > > (circle 500 "solid" "yellow") > > On the Mac, for screens less than 1000 pixels tall, there appears to be no > way to inspect the bottom part of the circle. > > IIUC, this is not a bug but a change request. > > I guess the best question might be this: ?is this the kind of thing that > might be fixed by the re-implementation of wx in scheme, or not? > > John > > > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > > From robby at eecs.northwestern.edu Thu Nov 12 18:08:19 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Thu Nov 12 18:08:38 2009 Subject: [plt-dev] Scrolling of files with large snips In-Reply-To: <932b2f1f0911121507k33bba6acgb17aa439d120e83f@mail.gmail.com> References: <4AEE6300-4038-4697-9451-6A2252342ECA@brinckerhoff.org> <932b2f1f0911121507k33bba6acgb17aa439d120e83f@mail.gmail.com> Message-ID: <932b2f1f0911121508m68c1cecub77b55b8078c6c2e@mail.gmail.com> Oh, I know how to do it. Nevermind. (get the style list's standard style and get its font's height) Robby On Thu, Nov 12, 2009 at 5:07 PM, Robby Findler wrote: > This is fixable with the current tools. It is, I believe, easy to say > make scroll positions every 15 pixels (or some other fixed number). > Less easy to make them at the height of the font generally in the > buffer, tho. (Matthew: any hints?) > > Robby > > On Thu, Nov 12, 2009 at 5:02 PM, John Clements > wrote: >> It looks like DrScheme buffers manage scroll positions using the >> line-at-the-top-of-the-screen. ?This means that for large snips--those >> taller than the window--there's no way to see the bottom half of the snip, >> because there's no intermediate scroll position between >> line-with-the-big-snip and (+ 1 line-with-the-big-snip). >> >> E.G.: ?Evaluate this program: >> >> (require 2htdp/image) >> >> (circle 500 "solid" "yellow") >> >> On the Mac, for screens less than 1000 pixels tall, there appears to be no >> way to inspect the bottom part of the circle. >> >> IIUC, this is not a bug but a change request. >> >> I guess the best question might be this: ?is this the kind of thing that >> might be fixed by the re-implementation of wx in scheme, or not? >> >> John >> >> >> _________________________________________________ >> ?For list-related administrative tasks: >> ?http://list.cs.brown.edu/mailman/listinfo/plt-dev >> >> > From robby at eecs.northwestern.edu Thu Nov 12 21:00:16 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Thu Nov 12 21:00:37 2009 Subject: [plt-dev] Scrolling of files with large snips In-Reply-To: <4AEE6300-4038-4697-9451-6A2252342ECA@brinckerhoff.org> References: <4AEE6300-4038-4697-9451-6A2252342ECA@brinckerhoff.org> Message-ID: <932b2f1f0911121800x7b8f6deaoef4dff4ae064c42d@mail.gmail.com> This is fixed now. Thanks, Robby On Thu, Nov 12, 2009 at 5:02 PM, John Clements wrote: > It looks like DrScheme buffers manage scroll positions using the > line-at-the-top-of-the-screen. ?This means that for large snips--those > taller than the window--there's no way to see the bottom half of the snip, > because there's no intermediate scroll position between > line-with-the-big-snip and (+ 1 line-with-the-big-snip). > > E.G.: ?Evaluate this program: > > (require 2htdp/image) > > (circle 500 "solid" "yellow") > > On the Mac, for screens less than 1000 pixels tall, there appears to be no > way to inspect the bottom part of the circle. > > IIUC, this is not a bug but a change request. > > I guess the best question might be this: ?is this the kind of thing that > might be fixed by the re-implementation of wx in scheme, or not? > > John > > > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > > From clements at brinckerhoff.org Thu Nov 12 23:23:25 2009 From: clements at brinckerhoff.org (John Clements) Date: Thu Nov 12 23:23:54 2009 Subject: [plt-dev] Scrolling of files with large snips In-Reply-To: <932b2f1f0911121800x7b8f6deaoef4dff4ae064c42d@mail.gmail.com> References: <4AEE6300-4038-4697-9451-6A2252342ECA@brinckerhoff.org> <932b2f1f0911121800x7b8f6deaoef4dff4ae064c42d@mail.gmail.com> Message-ID: On Nov 12, 2009, at 6:00 PM, Robby Findler wrote: > This is fixed now. Wow! Thanks. 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/20091112/940c75aa/smime-0001.bin From d.j.gurnell at gmail.com Fri Nov 13 04:19:51 2009 From: d.j.gurnell at gmail.com (Dave Gurnell) Date: Fri Nov 13 04:20:10 2009 Subject: [plt-dev] define-match-expander <-> unlib.plt doesn't compile In-Reply-To: References: <990e0c030911121059q15d16ea3j18d7beb37d1a6feb@mail.gmail.com> <69C84EEF-52AC-429E-964F-AA1EE10E16BF@gmail.com> Message-ID: <4A5DED88-C0AF-4709-B016-60A0E8B6A748@gmail.com> John Clements wrote: > Dave Gurnell wrote: >> I've uploaded Unlib 3.19 containing a fix for the match problem. > Awesome fixed now thanks all. Hi all, I haven't managed to fix this in its entirety and I'm not sure how to go about it correctly. The eq? match expander now looks like this: ; (_ expr pattern ...) (define-match-expander match:eq? (lambda (stx) (syntax-case stx () [(_ expr pattern ...) #'(? (cut eq? <> expr) pattern ...)])) (lambda (stx) (syntax-case stx () [_ #'eq?]))) However, the second transformer procedure only works if eq? is in application position. Looking at the docs, I assume I want to use make- rename-transformer in some way but I can't work out how in this context. Can anyone offer any pointers? Many thanks, -- Dave From samth at ccs.neu.edu Fri Nov 13 08:57:48 2009 From: samth at ccs.neu.edu (Sam TH) Date: Fri Nov 13 08:58:26 2009 Subject: [plt-dev] define-match-expander <-> unlib.plt doesn't compile In-Reply-To: <4A5DED88-C0AF-4709-B016-60A0E8B6A748@gmail.com> References: <990e0c030911121059q15d16ea3j18d7beb37d1a6feb@mail.gmail.com> <69C84EEF-52AC-429E-964F-AA1EE10E16BF@gmail.com> <4A5DED88-C0AF-4709-B016-60A0E8B6A748@gmail.com> Message-ID: <63bb19ae0911130557w33c6dadbk928c41f25b7135d9@mail.gmail.com> On Fri, Nov 13, 2009 at 4:19 AM, Dave Gurnell wrote: > John Clements wrote: >> >> Dave Gurnell wrote: >>> >>> I've uploaded Unlib 3.19 containing a fix for the match problem. >> >> Awesome fixed now thanks all. > > Hi all, > > I haven't managed to fix this in its entirety and I'm not sure how to go > about it correctly. > > The eq? match expander now looks like this: > > ; (_ expr pattern ...) > (define-match-expander match:eq? > ?(lambda (stx) > ? ?(syntax-case stx () > ? ? ?[(_ expr pattern ...) > ? ? ? #'(? (cut eq? <> expr) pattern ...)])) > ?(lambda (stx) > ? ?(syntax-case stx () > ? ? ?[_ #'eq?]))) > > However, the second transformer procedure only works if eq? is in > application position. Looking at the docs, I assume I want to use > make-rename-transformer in some way but I can't work out how in this > context. Unfortunately, the result of `make-rename-transformer' isn't a procedure (Matthew, could this be changed?), so you can't use it here. This is probably the next best thing: ; (_ expr pattern ...) (define-match-expander match:eq? (lambda (stx) #f) (lambda (stx) (syntax-case stx (set!) [(nm . args) #'(eq? . args)] [nm (identifier? #'nm) #'eq?] [(set! . _) (raise-syntax-error #f "match expander cannot be target of a set!" stx)]))) (match:eq? 1 1) -- sam th samth@ccs.neu.edu From robby at eecs.northwestern.edu Fri Nov 13 09:29:36 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Fri Nov 13 09:29:57 2009 Subject: [plt-dev] latest docs Message-ID: <932b2f1f0911130629u5fafcf32r8b697b26489f3e61@mail.gmail.com> I wanted to share a recent version of the docs with someone who isn't building from source, and thought that maybe others might wish there were a recent docs build online somewhere, so here's the link: http://www.eecs.northwestern.edu/~robby/tmp/doc/doc/ Robby From carl.eastlund at gmail.com Fri Nov 13 11:26:15 2009 From: carl.eastlund at gmail.com (Carl Eastlund) Date: Fri Nov 13 11:27:14 2009 Subject: [plt-dev] define-match-expander <-> unlib.plt doesn't compile In-Reply-To: <63bb19ae0911130557w33c6dadbk928c41f25b7135d9@mail.gmail.com> References: <990e0c030911121059q15d16ea3j18d7beb37d1a6feb@mail.gmail.com> <69C84EEF-52AC-429E-964F-AA1EE10E16BF@gmail.com> <4A5DED88-C0AF-4709-B016-60A0E8B6A748@gmail.com> <63bb19ae0911130557w33c6dadbk928c41f25b7135d9@mail.gmail.com> Message-ID: <990e0c030911130826s5eba84efla36ec2afcd8d1cf1@mail.gmail.com> On Fri, Nov 13, 2009 at 8:57 AM, Sam TH wrote: > On Fri, Nov 13, 2009 at 4:19 AM, Dave Gurnell wrote: >> >> Hi all, >> >> I haven't managed to fix this in its entirety and I'm not sure how to go >> about it correctly. >> >> The eq? match expander now looks like this: >> >> ; (_ expr pattern ...) >> (define-match-expander match:eq? >> ?(lambda (stx) >> ? ?(syntax-case stx () >> ? ? ?[(_ expr pattern ...) >> ? ? ? #'(? (cut eq? <> expr) pattern ...)])) >> ?(lambda (stx) >> ? ?(syntax-case stx () >> ? ? ?[_ #'eq?]))) >> >> However, the second transformer procedure only works if eq? is in >> application position. Looking at the docs, I assume I want to use >> make-rename-transformer in some way but I can't work out how in this >> context. > > Unfortunately, the result of `make-rename-transformer' isn't a > procedure (Matthew, could this be changed?), so you can't use it here. The (planet cce/scheme) package includes `redirect-transformer' for this purpose. Just use (redirect-transformer #'eq?) and it will produce a transformer procedure that does the right work. --Carl From d.j.gurnell at gmail.com Fri Nov 13 12:37:07 2009 From: d.j.gurnell at gmail.com (Dave Gurnell) Date: Fri Nov 13 12:37:27 2009 Subject: [plt-dev] define-match-expander <-> unlib.plt doesn't compile In-Reply-To: <990e0c030911130826s5eba84efla36ec2afcd8d1cf1@mail.gmail.com> References: <990e0c030911121059q15d16ea3j18d7beb37d1a6feb@mail.gmail.com> <69C84EEF-52AC-429E-964F-AA1EE10E16BF@gmail.com> <4A5DED88-C0AF-4709-B016-60A0E8B6A748@gmail.com> <63bb19ae0911130557w33c6dadbk928c41f25b7135d9@mail.gmail.com> <990e0c030911130826s5eba84efla36ec2afcd8d1cf1@mail.gmail.com> Message-ID: <39941BD2-8282-4989-8A83-2AECC27D5574@gmail.com> On 13 Nov 2009, at 16:26, Carl Eastlund wrote: > On Fri, Nov 13, 2009 at 8:57 AM, Sam TH wrote: >> On Fri, Nov 13, 2009 at 4:19 AM, Dave Gurnell >> wrote: >>> [...] the second transformer procedure only works if eq? is in >>> application position. Looking at the docs, I assume I want to use >>> make-rename-transformer in some way but I can't work out how in this >>> context. >> >> Unfortunately, the result of `make-rename-transformer' isn't a >> procedure (Matthew, could this be changed?), so you can't use it >> here. > > The (planet cce/scheme) package includes `redirect-transformer' for > this purpose. Just use (redirect-transformer #'eq?) and it will > produce a transformer procedure that does the right work. Thanks, Sam and Carl! I've rewritten the forms using redirect-transformer and released the fixed code as Unlib 3.20. Cheers, -- Dave From stephen.degabrielle at acm.org Fri Nov 13 16:21:51 2009 From: stephen.degabrielle at acm.org (Stephen De Gabrielle) Date: Fri Nov 13 16:22:12 2009 Subject: [plt-dev] latest docs In-Reply-To: <932b2f1f0911130629u5fafcf32r8b697b26489f3e61@mail.gmail.com> References: <932b2f1f0911130629u5fafcf32r8b697b26489f3e61@mail.gmail.com> Message-ID: <595b9ab20911131321i5d0ab3b2l724e836f9c2593d0@mail.gmail.com> Very nice. Thank you. S. On Friday, November 13, 2009, Robby Findler wrote: > I wanted to share a recent version of the docs with someone who isn't > building from source, and thought that maybe others might wish there > were a recent docs build online somewhere, so here's the link: > > ?http://www.eecs.northwestern.edu/~robby/tmp/doc/doc/ > > Robby > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > -- -- Stephen De Gabrielle stephen.degabrielle@acm.org Telephone +44 (0)20 85670911 Mobile +44 (0)79 85189045 http://www.degabrielle.name/stephen From clements at brinckerhoff.org Sat Nov 14 01:18:45 2009 From: clements at brinckerhoff.org (John Clements) Date: Sat Nov 14 01:19:11 2009 Subject: [plt-dev] Re: [plt-scheme] scaling and rotating images using image.ss In-Reply-To: <62B2E812-4580-43C3-8DB6-665046A5916C@ccs.neu.edu> References: <891bd3390909260617t65d4cfa2he61c7bfa69c2050b@mail.gmail.com> <62B2E812-4580-43C3-8DB6-665046A5916C@ccs.neu.edu> Message-ID: <425F2102-90F5-49C9-A574-B4073539CB8C@brinckerhoff.org> On Sep 26, 2009, at 6:29 AM, Matthias Felleisen wrote: > > > 1. htdp/world is deprecated, use 2htdp/universe instead. > > 2. we consider the pinhole approach to our image library as a > mistake. To solve the problem Robby is working on 2htdp/image, a > replacement for the image library. When it comes out (end of > semester probably) it will support rotate and other such operations, > plus comparisons will be much faster. I'm surprised to say it, but right now I'm *really missing the pinhole*. I'm trying to write a function in 2htdp/image that draws, say, 36 copies of a shape arranged in a big "circle" around a center. With pinholes, this was easy. Move the pinhole way off to the left, then rotate the thing around the pinhole by 10 degrees, 20 degrees, etc. Overlay them all, and you're done. [*] With the new approach, I'm finding this nearly impossible. The natural approach involves, for instance, putting the thing "beside" a long horizontal space, and then rotating it. The problem is that it doesn't rotate about a fixed point. To see the problem, consider this program: (require 2htdp/image) (define a (beside (rectangle 150 2 "solid" "black") (ellipse 10 50 "solid" "purple"))) (overlay/places "middle" "middle" (rotate 0 a) (rotate 20 a) (rotate 40 a) (rotate 60 a)) The problem is that mapping a point in the pre-rotation shape to a point in the post-rotation shape is hard. ... After wrestling with this for quite a while, I have a solution of sorts; you have to overlay the shape you want to rotate on a large outline circle in such a way that the shape is entirely inside the circle. Rotating this shape does not change the bounding box at all, meaning that you can overlay them correctly. Needless to say, computing the size of the circle required is a big pain. E.G.: (define b (overlay/xy (circle 200 "outline" "blue") 200 200 a)) (overlay (rotate 0 b) (rotate 20 b) (rotate 40 b) (rotate 60 b)) Am I missing something obvious? John [*] with the obvious caveat that the old version didn't rotate shapes at all. -------------- 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/20091113/43b6e36f/smime-0001.bin From robby at eecs.northwestern.edu Sat Nov 14 08:25:52 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Sat Nov 14 08:26:10 2009 Subject: [plt-dev] Re: [plt-scheme] scaling and rotating images using image.ss In-Reply-To: <425F2102-90F5-49C9-A574-B4073539CB8C@brinckerhoff.org> References: <891bd3390909260617t65d4cfa2he61c7bfa69c2050b@mail.gmail.com> <62B2E812-4580-43C3-8DB6-665046A5916C@ccs.neu.edu> <425F2102-90F5-49C9-A574-B4073539CB8C@brinckerhoff.org> Message-ID: <932b2f1f0911140525wc7ba2b6sa64b693fca476fad@mail.gmail.com> I think what you did at the end is the way that I'd do it. This suggests that the library needs to support invisible ellipses (equality is going to be a pain with those in there, tho, but I guess it is nothing new when you consider that there are already zero-width and zero-height rectangles). Robby On Sat, Nov 14, 2009 at 12:18 AM, John Clements wrote: > > On Sep 26, 2009, at 6:29 AM, Matthias Felleisen wrote: > >> >> >> 1. htdp/world is deprecated, use 2htdp/universe instead. >> >> 2. we consider the pinhole approach to our image library as a mistake. To >> solve the problem Robby is working on 2htdp/image, a replacement for the >> image library. When it comes out (end of semester probably) it will support >> rotate and other such operations, plus comparisons will be much faster. > > I'm surprised to say it, but right now I'm *really missing the pinhole*. > > I'm trying to write a function in 2htdp/image that draws, say, 36 copies of > a shape arranged in a big "circle" around a center. ?With pinholes, this was > easy. ?Move the pinhole way off to the left, then rotate the thing around > the pinhole by 10 degrees, 20 degrees, etc. Overlay them all, and you're > done. [*] > > With the new approach, I'm finding this nearly impossible. ?The natural > approach involves, for instance, putting the thing "beside" a long > horizontal space, and then rotating it. ?The problem is that it doesn't > rotate about a fixed point. ?To see the problem, consider this program: > > (require 2htdp/image) > > (define a (beside (rectangle 150 2 "solid" "black") (ellipse 10 50 "solid" > "purple"))) > > (overlay/places "middle" "middle" > ? ? ? ? ? ? ? ?(rotate ?0 a) > ? ? ? ? ? ? ? ?(rotate 20 a) > ? ? ? ? ? ? ? ?(rotate 40 a) > ? ? ? ? ? ? ? ?(rotate 60 a)) > > The problem is that mapping a point in the pre-rotation shape to a point in > the post-rotation shape is hard. > > ... > > After wrestling with this for quite a while, I have a solution of sorts; you > have to overlay the shape you want to rotate on a large outline circle in > such a way that the shape is entirely inside the circle. Rotating this shape > does not change the bounding box at all, meaning that you can overlay them > correctly. Needless to say, computing the size of the circle required is a > big pain. > > E.G.: > > (define b (overlay/xy (circle 200 "outline" "blue") 200 200 a)) > > (overlay > ?(rotate ?0 b) > ?(rotate 20 b) > ?(rotate 40 b) > ?(rotate 60 b)) > > Am I missing something obvious? > > John > > [*] with the obvious caveat that the old version didn't rotate shapes at > all. > > > From matthias at ccs.neu.edu Sat Nov 14 11:42:05 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Sat Nov 14 11:42:41 2009 Subject: [plt-dev] Re: [plt-scheme] scaling and rotating images using image.ss In-Reply-To: <425F2102-90F5-49C9-A574-B4073539CB8C@brinckerhoff.org> References: <891bd3390909260617t65d4cfa2he61c7bfa69c2050b@mail.gmail.com> <62B2E812-4580-43C3-8DB6-665046A5916C@ccs.neu.edu> <425F2102-90F5-49C9-A574-B4073539CB8C@brinckerhoff.org> Message-ID: This should be (overlay/places "center" "middle" (rotate 0 a) (rotate 20 a) (rotate 40 a) (rotate 60 a)) not .. "middle" "middle" ... correct? On Nov 14, 2009, at 1:18 AM, John Clements wrote: > > On Sep 26, 2009, at 6:29 AM, Matthias Felleisen wrote: > >> >> >> 1. htdp/world is deprecated, use 2htdp/universe instead. >> >> 2. we consider the pinhole approach to our image library as a mistake. To solve the problem Robby is working on 2htdp/image, a replacement for the image library. When it comes out (end of semester probably) it will support rotate and other such operations, plus comparisons will be much faster. > > I'm surprised to say it, but right now I'm *really missing the pinhole*. > > I'm trying to write a function in 2htdp/image that draws, say, 36 copies of a shape arranged in a big "circle" around a center. With pinholes, this was easy. Move the pinhole way off to the left, then rotate the thing around the pinhole by 10 degrees, 20 degrees, etc. Overlay them all, and you're done. [*] > > With the new approach, I'm finding this nearly impossible. The natural approach involves, for instance, putting the thing "beside" a long horizontal space, and then rotating it. The problem is that it doesn't rotate about a fixed point. To see the problem, consider this program: > > (require 2htdp/image) > > (define a (beside (rectangle 150 2 "solid" "black") (ellipse 10 50 "solid" "purple"))) > > (overlay/places "middle" "middle" > (rotate 0 a) > (rotate 20 a) > (rotate 40 a) > (rotate 60 a)) > > The problem is that mapping a point in the pre-rotation shape to a point in the post-rotation shape is hard. > > ... > > After wrestling with this for quite a while, I have a solution of sorts; you have to overlay the shape you want to rotate on a large outline circle in such a way that the shape is entirely inside the circle. Rotating this shape does not change the bounding box at all, meaning that you can overlay them correctly. Needless to say, computing the size of the circle required is a big pain. > > E.G.: > > (define b (overlay/xy (circle 200 "outline" "blue") 200 200 a)) > > (overlay > (rotate 0 b) > (rotate 20 b) > (rotate 40 b) > (rotate 60 b)) > > Am I missing something obvious? > > John > > [*] with the obvious caveat that the old version didn't rotate shapes at all. > > > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From robby at eecs.northwestern.edu Sat Nov 14 11:46:25 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Sat Nov 14 11:46:46 2009 Subject: [plt-dev] Re: [plt-scheme] scaling and rotating images using image.ss In-Reply-To: References: <891bd3390909260617t65d4cfa2he61c7bfa69c2050b@mail.gmail.com> <62B2E812-4580-43C3-8DB6-665046A5916C@ccs.neu.edu> <425F2102-90F5-49C9-A574-B4073539CB8C@brinckerhoff.org> Message-ID: <932b2f1f0911140846ha472ff1r50c7a8ad513d47b7@mail.gmail.com> middle and center are synonymous (and can be used in both horizontal and vertical directions). Robby On Sat, Nov 14, 2009 at 10:42 AM, Matthias Felleisen wrote: > > This should be > > (overlay/places "center" "middle" > ? ? ? ? ? ? ? ?(rotate ?0 a) > ? ? ? ? ? ? ? ?(rotate 20 a) > ? ? ? ? ? ? ? ?(rotate 40 a) > ? ? ? ? ? ? ? ?(rotate 60 a)) > > not > > ?.. "middle" "middle" ... > > correct? > > > On Nov 14, 2009, at 1:18 AM, John Clements wrote: > >> >> On Sep 26, 2009, at 6:29 AM, Matthias Felleisen wrote: >> >>> >>> >>> 1. htdp/world is deprecated, use 2htdp/universe instead. >>> >>> 2. we consider the pinhole approach to our image library as a mistake. To solve the problem Robby is working on 2htdp/image, a replacement for the image library. When it comes out (end of semester probably) it will support rotate and other such operations, plus comparisons will be much faster. >> >> I'm surprised to say it, but right now I'm *really missing the pinhole*. >> >> I'm trying to write a function in 2htdp/image that draws, say, 36 copies of a shape arranged in a big "circle" around a center. ?With pinholes, this was easy. ?Move the pinhole way off to the left, then rotate the thing around the pinhole by 10 degrees, 20 degrees, etc. Overlay them all, and you're done. [*] >> >> With the new approach, I'm finding this nearly impossible. ?The natural approach involves, for instance, putting the thing "beside" a long horizontal space, and then rotating it. ?The problem is that it doesn't rotate about a fixed point. ?To see the problem, consider this program: >> >> (require 2htdp/image) >> >> (define a (beside (rectangle 150 2 "solid" "black") (ellipse 10 50 "solid" "purple"))) >> >> (overlay/places "middle" "middle" >> ? ? ? ? ? ? ? ?(rotate ?0 a) >> ? ? ? ? ? ? ? ?(rotate 20 a) >> ? ? ? ? ? ? ? ?(rotate 40 a) >> ? ? ? ? ? ? ? ?(rotate 60 a)) >> >> The problem is that mapping a point in the pre-rotation shape to a point in the post-rotation shape is hard. >> >> ... >> >> After wrestling with this for quite a while, I have a solution of sorts; you have to overlay the shape you want to rotate on a large outline circle in such a way that the shape is entirely inside the circle. Rotating this shape does not change the bounding box at all, meaning that you can overlay them correctly. Needless to say, computing the size of the circle required is a big pain. >> >> E.G.: >> >> (define b (overlay/xy (circle 200 "outline" "blue") 200 200 a)) >> >> (overlay >> (rotate ?0 b) >> (rotate 20 b) >> (rotate 40 b) >> (rotate 60 b)) >> >> Am I missing something obvious? >> >> John >> >> [*] with the obvious caveat that the old version didn't rotate shapes at all. >> >> >> _________________________________________________ >> ?For list-related administrative tasks: >> ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > > From matthias at ccs.neu.edu Sat Nov 14 11:49:47 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Sat Nov 14 11:50:15 2009 Subject: [plt-dev] Re: [plt-scheme] scaling and rotating images using image.ss In-Reply-To: <932b2f1f0911140846ha472ff1r50c7a8ad513d47b7@mail.gmail.com> References: <891bd3390909260617t65d4cfa2he61c7bfa69c2050b@mail.gmail.com> <62B2E812-4580-43C3-8DB6-665046A5916C@ccs.neu.edu> <425F2102-90F5-49C9-A574-B4073539CB8C@brinckerhoff.org> <932b2f1f0911140846ha472ff1r50c7a8ad513d47b7@mail.gmail.com> Message-ID: <8A227ACA-8DD2-43ED-A96A-F3BE0853551D@ccs.neu.edu> On Nov 14, 2009, at 11:46 AM, Robby Findler wrote: > middle and center are synonymous (and can be used in both horizontal > and vertical directions). Then consider this a bug report/feature request. Like in HTML, I suggest that middle and center work for vertical and horizontal alignment, respectively. -- Matthias > > Robby > > On Sat, Nov 14, 2009 at 10:42 AM, Matthias Felleisen > wrote: >> >> This should be >> >> (overlay/places "center" "middle" >> (rotate 0 a) >> (rotate 20 a) >> (rotate 40 a) >> (rotate 60 a)) >> >> not >> >> .. "middle" "middle" ... >> >> correct? >> >> >> On Nov 14, 2009, at 1:18 AM, John Clements wrote: >> >>> >>> On Sep 26, 2009, at 6:29 AM, Matthias Felleisen wrote: >>> >>>> >>>> >>>> 1. htdp/world is deprecated, use 2htdp/universe instead. >>>> >>>> 2. we consider the pinhole approach to our image library as a mistake. To solve the problem Robby is working on 2htdp/image, a replacement for the image library. When it comes out (end of semester probably) it will support rotate and other such operations, plus comparisons will be much faster. >>> >>> I'm surprised to say it, but right now I'm *really missing the pinhole*. >>> >>> I'm trying to write a function in 2htdp/image that draws, say, 36 copies of a shape arranged in a big "circle" around a center. With pinholes, this was easy. Move the pinhole way off to the left, then rotate the thing around the pinhole by 10 degrees, 20 degrees, etc. Overlay them all, and you're done. [*] >>> >>> With the new approach, I'm finding this nearly impossible. The natural approach involves, for instance, putting the thing "beside" a long horizontal space, and then rotating it. The problem is that it doesn't rotate about a fixed point. To see the problem, consider this program: >>> >>> (require 2htdp/image) >>> >>> (define a (beside (rectangle 150 2 "solid" "black") (ellipse 10 50 "solid" "purple"))) >>> >>> (overlay/places "middle" "middle" >>> (rotate 0 a) >>> (rotate 20 a) >>> (rotate 40 a) >>> (rotate 60 a)) >>> >>> The problem is that mapping a point in the pre-rotation shape to a point in the post-rotation shape is hard. >>> >>> ... >>> >>> After wrestling with this for quite a while, I have a solution of sorts; you have to overlay the shape you want to rotate on a large outline circle in such a way that the shape is entirely inside the circle. Rotating this shape does not change the bounding box at all, meaning that you can overlay them correctly. Needless to say, computing the size of the circle required is a big pain. >>> >>> E.G.: >>> >>> (define b (overlay/xy (circle 200 "outline" "blue") 200 200 a)) >>> >>> (overlay >>> (rotate 0 b) >>> (rotate 20 b) >>> (rotate 40 b) >>> (rotate 60 b)) >>> >>> Am I missing something obvious? >>> >>> John >>> >>> [*] with the obvious caveat that the old version didn't rotate shapes at all. >>> >>> >>> _________________________________________________ >>> For list-related administrative tasks: >>> http://list.cs.brown.edu/mailman/listinfo/plt-dev >> >> From carl.eastlund at gmail.com Sat Nov 14 11:53:25 2009 From: carl.eastlund at gmail.com (Carl Eastlund) Date: Sat Nov 14 11:54:03 2009 Subject: [plt-dev] Re: [plt-scheme] scaling and rotating images using image.ss In-Reply-To: <8A227ACA-8DD2-43ED-A96A-F3BE0853551D@ccs.neu.edu> References: <891bd3390909260617t65d4cfa2he61c7bfa69c2050b@mail.gmail.com> <62B2E812-4580-43C3-8DB6-665046A5916C@ccs.neu.edu> <425F2102-90F5-49C9-A574-B4073539CB8C@brinckerhoff.org> <932b2f1f0911140846ha472ff1r50c7a8ad513d47b7@mail.gmail.com> <8A227ACA-8DD2-43ED-A96A-F3BE0853551D@ccs.neu.edu> Message-ID: <990e0c030911140853m3701d474pcc06ac7d8c41b9ce@mail.gmail.com> On Sat, Nov 14, 2009 at 11:49 AM, Matthias Felleisen wrote: > > On Nov 14, 2009, at 11:46 AM, Robby Findler wrote: > >> middle and center are synonymous (and can be used in both horizontal >> and vertical directions). > > > Then consider this a bug report/feature request. Like in HTML, I suggest that middle and center work for vertical and horizontal alignment, respectively. -- Matthias UGH! I vote for the "synonymous" version. Why should users -- especially students -- have to remember which is which? Especially when the words mean the same thing. --Carl From robby at eecs.northwestern.edu Sat Nov 14 11:55:15 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Sat Nov 14 11:55:33 2009 Subject: [plt-dev] Re: [plt-scheme] scaling and rotating images using image.ss In-Reply-To: <8A227ACA-8DD2-43ED-A96A-F3BE0853551D@ccs.neu.edu> References: <891bd3390909260617t65d4cfa2he61c7bfa69c2050b@mail.gmail.com> <62B2E812-4580-43C3-8DB6-665046A5916C@ccs.neu.edu> <425F2102-90F5-49C9-A574-B4073539CB8C@brinckerhoff.org> <932b2f1f0911140846ha472ff1r50c7a8ad513d47b7@mail.gmail.com> <8A227ACA-8DD2-43ED-A96A-F3BE0853551D@ccs.neu.edu> Message-ID: <932b2f1f0911140855x35711273w9e8cbd2b1c70eaba@mail.gmail.com> On Sat, Nov 14, 2009 at 10:49 AM, Matthias Felleisen wrote: > > On Nov 14, 2009, at 11:46 AM, Robby Findler wrote: > >> middle and center are synonymous (and can be used in both horizontal >> and vertical directions). > > > Then consider this a bug report/feature request. Like in HTML, I suggest that middle and center work for vertical and horizontal alignment, respectively. -- Matthias > They do work for vertical and horizontal alignment. You want errors? Robby From matthias at ccs.neu.edu Sat Nov 14 11:56:09 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Sat Nov 14 11:56:36 2009 Subject: [plt-dev] Re: [plt-scheme] scaling and rotating images using image.ss In-Reply-To: <932b2f1f0911140855x35711273w9e8cbd2b1c70eaba@mail.gmail.com> References: <891bd3390909260617t65d4cfa2he61c7bfa69c2050b@mail.gmail.com> <62B2E812-4580-43C3-8DB6-665046A5916C@ccs.neu.edu> <425F2102-90F5-49C9-A574-B4073539CB8C@brinckerhoff.org> <932b2f1f0911140846ha472ff1r50c7a8ad513d47b7@mail.gmail.com> <8A227ACA-8DD2-43ED-A96A-F3BE0853551D@ccs.neu.edu> <932b2f1f0911140855x35711273w9e8cbd2b1c70eaba@mail.gmail.com> Message-ID: On Nov 14, 2009, at 11:55 AM, Robby Findler wrote: > On Sat, Nov 14, 2009 at 10:49 AM, Matthias Felleisen > wrote: >> >> On Nov 14, 2009, at 11:46 AM, Robby Findler wrote: >> >>> middle and center are synonymous (and can be used in both horizontal >>> and vertical directions). >> >> >> Then consider this a bug report/feature request. Like in HTML, I suggest that middle and center work for vertical and horizontal alignment, respectively. -- Matthias >> > > They do work for vertical and horizontal alignment. You want errors? Yes I thought we wanted errors but Carl's probably right. Why should we care about HTML and the people who teach HTML. From rafkind at cs.utah.edu Sat Nov 14 14:13:26 2009 From: rafkind at cs.utah.edu (Jon Rafkind) Date: Sat Nov 14 14:16:36 2009 Subject: [plt-dev] fixing mzscheme/examples Message-ID: <4AFF0156.7090004@cs.utah.edu> I tried to fixup the examples in collects/mzscheme/examples but ran into some issues. If I compile catch.c into catch.so and run it with this code x.ss: (load-extension "catch.so") (printf "~a\n" (eval-string/catch-error "(+ 1 'a)")) $ mzscheme -f x.ss Then I get: #f::0: compile: unbound identifier (and no #%app syntax transformer is bound) at: lambda in: (lambda (thunk) (with-handlers ((void (lambda (exn) (cons #f exn)))) (cons #t (thunk)))) Which usually means scheme/base hasn't been require'd. Putting (require scheme/base) into x.ss doesn't help so I tried modifying the C code. Probably the environment in `init_exn_catching_apply' has to be modified but the only way I can see to modify namespaces is with scheme_namespace_require. So I put `env' into the current MZCONFIG_ENV param and called scheme_namespace_require(scheme_intern_symbol("scheme/base")) but when I load the resulting .so I get an infinite loop. Is `scheme_make_namespace' the wrong function to call to get a new namespace? Also, not a big deal, but this command mzc --3m --cc catch.3m.c produces catch_3m.c instead of catch.c. The docs say it would produce catch.c. From cce at ccs.neu.edu Mon Nov 16 19:57:24 2009 From: cce at ccs.neu.edu (Carl Eastlund) Date: Mon Nov 16 19:58:02 2009 Subject: [plt-dev] Error message from test-engine Message-ID: <990e0c030911161657n55312125k7ad0a1eb7deea5c7@mail.gmail.com> I got the following error while trying to modify the way Dracula uses check-expect tests: force: reentrant promise gc-on-bitmap === context === /Users/cce/plt/2009-11-16/collects/scheme/promise.ss:94:10 /Users/cce/plt/2009-11-16/collects/scheme/private/more-scheme.ss:274:2: call-with-exception-handler /Users/cce/plt/2009-11-16/collects/scheme/promise.ss:86:0: force/generic /Users/cce/plt/2009-11-16/collects/framework/private/frame.ss:650:4: register-gc-blit method in ...ork/private/frame.ss:493:2 /Users/cce/plt/2009-11-16/collects/framework/private/frame.ss:493:2 /Users/cce/plt/2009-11-16/collects/scheme/private/class-internal.ss:2699:0: continue-make-object /Users/cce/plt/2009-11-16/collects/framework/private/frame.ss:749:2 /Users/cce/plt/2009-11-16/collects/scheme/private/class-internal.ss:2699:0: continue-make-object /Users/cce/plt/2009-11-16/collects/scheme/private/class-internal.ss:2699:0: continue-make-object /Users/cce/plt/2009-11-16/collects/framework/private/standard-menus.ss:179:2 /Users/cce/plt/2009-11-16/collects/scheme/private/class-internal.ss:2699:0: continue-make-object /Users/cce/plt/2009-11-16/collects/test-engine/test-display.scm:335:2 /Users/cce/plt/2009-11-16/collects/scheme/private/class-internal.ss:2699:0: continue-make-object /Users/cce/plt/2009-11-16/collects/scheme/private/class-internal.ss:2621:2: make-object /Users/cce/plt/2009-11-16/collects/test-engine/test-display.scm:70:4: display-results method in test-display% I don't think anything I did should cause this, but I'm not sure quite what happened so I can't say for sure. I do know my program had two check-expect tests, and when this error showed up the check-expect output displayed three results (my first test once and my second test twice). Does anyone know what might be causing this? Carl Eastlund From robby at eecs.northwestern.edu Mon Nov 16 20:02:07 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Mon Nov 16 20:02:28 2009 Subject: [plt-dev] Error message from test-engine In-Reply-To: <990e0c030911161657n55312125k7ad0a1eb7deea5c7@mail.gmail.com> References: <990e0c030911161657n55312125k7ad0a1eb7deea5c7@mail.gmail.com> Message-ID: <932b2f1f0911161702h77b86e00o8a632f88a78844ce@mail.gmail.com> I think Eli recently changed the way force & delay work. Perhaps that has something to do with this? Robby On Mon, Nov 16, 2009 at 6:57 PM, Carl Eastlund wrote: > I got the following error while trying to modify the way Dracula uses > check-expect tests: > > force: reentrant promise gc-on-bitmap > > ?=== context === > /Users/cce/plt/2009-11-16/collects/scheme/promise.ss:94:10 > /Users/cce/plt/2009-11-16/collects/scheme/private/more-scheme.ss:274:2: > call-with-exception-handler > /Users/cce/plt/2009-11-16/collects/scheme/promise.ss:86:0: force/generic > /Users/cce/plt/2009-11-16/collects/framework/private/frame.ss:650:4: > register-gc-blit method in ...ork/private/frame.ss:493:2 > /Users/cce/plt/2009-11-16/collects/framework/private/frame.ss:493:2 > /Users/cce/plt/2009-11-16/collects/scheme/private/class-internal.ss:2699:0: > continue-make-object > /Users/cce/plt/2009-11-16/collects/framework/private/frame.ss:749:2 > /Users/cce/plt/2009-11-16/collects/scheme/private/class-internal.ss:2699:0: > continue-make-object > /Users/cce/plt/2009-11-16/collects/scheme/private/class-internal.ss:2699:0: > continue-make-object > /Users/cce/plt/2009-11-16/collects/framework/private/standard-menus.ss:179:2 > /Users/cce/plt/2009-11-16/collects/scheme/private/class-internal.ss:2699:0: > continue-make-object > /Users/cce/plt/2009-11-16/collects/test-engine/test-display.scm:335:2 > /Users/cce/plt/2009-11-16/collects/scheme/private/class-internal.ss:2699:0: > continue-make-object > /Users/cce/plt/2009-11-16/collects/scheme/private/class-internal.ss:2621:2: > make-object > /Users/cce/plt/2009-11-16/collects/test-engine/test-display.scm:70:4: > display-results method in test-display% > > I don't think anything I did should cause this, but I'm not sure quite > what happened so I can't say for sure. ?I do know my program had two > check-expect tests, and when this error showed up the check-expect > output displayed three results (my first test once and my second test > twice). > > Does anyone know what might be causing this? > > Carl Eastlund > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > From eli at barzilay.org Mon Nov 16 20:36:41 2009 From: eli at barzilay.org (Eli Barzilay) Date: Mon Nov 16 20:37:00 2009 Subject: [plt-dev] Error message from test-engine In-Reply-To: <990e0c030911161657n55312125k7ad0a1eb7deea5c7@mail.gmail.com> References: <990e0c030911161657n55312125k7ad0a1eb7deea5c7@mail.gmail.com> Message-ID: <19201.65065.76671.767180@winooski.ccs.neu.edu> On Nov 16, Carl Eastlund wrote: > I got the following error while trying to modify the way Dracula uses > check-expect tests: > > force: reentrant promise gc-on-bitmap > [...] > > I don't think anything I did should cause this, but I'm not sure > quite what happened so I can't say for sure. I do know my program > had two check-expect tests, and when this error showed up the > check-expect output displayed three results (my first test once and > my second test twice). > > Does anyone know what might be causing this? This error happens when a promise is forced while it is forced. For example: -> (define p (delay (force p))) -> (force p) force: reentrant promise p This is especially tricky when multiple threads are involved: -> (define p (delay (sleep 5))) -> (thread (lambda () (force p))) # -> (force p) force: reentrant promise p which could be a problem since threads are involved. As for what Robby said -- I comitted some major extension to `scheme/promise', but the plain `delay'/`force'/`lazy' should be doing exactly the same thing they did before, so no *new* problems should be introduced. So, what I think you should do now is: 1. Try to undo my changes to `scheme/promise' and see if you get the same error. You can just use the contents of the file from 4.2.2 for this. If it doesn't fail, then there might be a bug in the extension, and I'll need some minimal-ish code that reproduces it. 2. But I think that it's likely it will fail too. In that case, you're probably running against the thread problem that I've demonstrated above. (If you look at your stack trace, you'll see that there is one `force/generic', which is what you'd get from my thread example, but the first one will have two.) The good news is that one of the new extensions that I added is `delay/sync' -- this is a kind of a promise that can be forced from multiple threads, the first one will compute it and the rest will block until it's ready. So, if it does fail, you should look around for code that uses `delay'/`force', and see if you can fix it by using `delay/sync'. BTW, this restriction that makes plain promises less useful with multiple threads is relatively new (since v4). The older version wouldn't throw that error -- but it would have the obvious race conditions, which means that the promise will be forced multiple time, and one will get to stay. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From robby at eecs.northwestern.edu Mon Nov 16 21:06:25 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Mon Nov 16 21:06:44 2009 Subject: [plt-dev] Error message from test-engine In-Reply-To: <19201.65065.76671.767180@winooski.ccs.neu.edu> References: <990e0c030911161657n55312125k7ad0a1eb7deea5c7@mail.gmail.com> <19201.65065.76671.767180@winooski.ccs.neu.edu> Message-ID: <932b2f1f0911161806he97777fg65728124a5a689c9@mail.gmail.com> The promise in question has been there for a very long time (10+ years, I'd guess), but there definitely could be treading problems. Perhaps just changing (in framework/private/icon.ss) to use the new thread safe stuff is the right thing. Robby On Mon, Nov 16, 2009 at 7:36 PM, Eli Barzilay wrote: > On Nov 16, Carl Eastlund wrote: >> I got the following error while trying to modify the way Dracula uses >> check-expect tests: >> >> force: reentrant promise gc-on-bitmap >> [...] >> >> I don't think anything I did should cause this, but I'm not sure >> quite what happened so I can't say for sure. ?I do know my program >> had two check-expect tests, and when this error showed up the >> check-expect output displayed three results (my first test once and >> my second test twice). >> >> Does anyone know what might be causing this? > > This error happens when a promise is forced while it is forced. ?For > example: > > ?-> (define p (delay (force p))) > ?-> (force p) > ?force: reentrant promise p > > This is especially tricky when multiple threads are involved: > > ?-> (define p (delay (sleep 5))) > ?-> (thread (lambda () (force p))) > ?# > ?-> (force p) > ?force: reentrant promise p > > which could be a problem since threads are involved. > > As for what Robby said -- I comitted some major extension to > `scheme/promise', but the plain `delay'/`force'/`lazy' should be doing > exactly the same thing they did before, so no *new* problems should be > introduced. > > So, what I think you should do now is: > > 1. Try to undo my changes to `scheme/promise' and see if you get the > ? same error. ?You can just use the contents of the file from 4.2.2 > ? for this. ?If it doesn't fail, then there might be a bug in the > ? extension, and I'll need some minimal-ish code that reproduces it. > > 2. But I think that it's likely it will fail too. ?In that case, > ? you're probably running against the thread problem that I've > ? demonstrated above. ?(If you look at your stack trace, you'll see > ? that there is one `force/generic', which is what you'd get from my > ? thread example, but the first one will have two.) > > ? The good news is that one of the new extensions that I added is > ? `delay/sync' -- this is a kind of a promise that can be forced from > ? multiple threads, the first one will compute it and the rest will > ? block until it's ready. ?So, if it does fail, you should look > ? around for code that uses `delay'/`force', and see if you can fix > ? it by using `delay/sync'. > > BTW, this restriction that makes plain promises less useful with > multiple threads is relatively new (since v4). ?The older version > wouldn't throw that error -- but it would have the obvious race > conditions, which means that the promise will be forced multiple time, > and one will get to stay. > > -- > ? ? ? ? ?((lambda (x) (x x)) (lambda (x) (x x))) ? ? ? ? ?Eli Barzilay: > ? ? ? ? ? ? ? ? ? ?http://barzilay.org/ ? ? ? ? ? ? ? ? ? Maze is Life! > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > From eli at barzilay.org Mon Nov 16 21:13:34 2009 From: eli at barzilay.org (Eli Barzilay) Date: Mon Nov 16 21:13:55 2009 Subject: [plt-dev] Error message from test-engine In-Reply-To: <932b2f1f0911161806he97777fg65728124a5a689c9@mail.gmail.com> References: <990e0c030911161657n55312125k7ad0a1eb7deea5c7@mail.gmail.com> <19201.65065.76671.767180@winooski.ccs.neu.edu> <932b2f1f0911161806he97777fg65728124a5a689c9@mail.gmail.com> Message-ID: <19202.1742.760014.852853@winooski.ccs.neu.edu> On Nov 16, Robby Findler wrote: > The promise in question has been there for a very long time (10+ > years, I'd guess), but there definitely could be treading problems. > Perhaps just changing (in framework/private/icon.ss) to use the new > thread safe stuff is the right thing. Yes, I've looked at them -- and they seem to be promises of the kind that would just lead (in pre-v4 days) to more work. But perhaps there was no problem until Carl somehow arranged things in a certain way. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From cce at ccs.neu.edu Mon Nov 16 22:43:33 2009 From: cce at ccs.neu.edu (Carl Eastlund) Date: Mon Nov 16 22:44:10 2009 Subject: [plt-dev] Error message from test-engine In-Reply-To: <19202.1742.760014.852853@winooski.ccs.neu.edu> References: <990e0c030911161657n55312125k7ad0a1eb7deea5c7@mail.gmail.com> <19201.65065.76671.767180@winooski.ccs.neu.edu> <932b2f1f0911161806he97777fg65728124a5a689c9@mail.gmail.com> <19202.1742.760014.852853@winooski.ccs.neu.edu> Message-ID: <990e0c030911161943o206ff78dvf55dee2fb5ce67e2@mail.gmail.com> On Mon, Nov 16, 2009 at 9:13 PM, Eli Barzilay wrote: > On Nov 16, Robby Findler wrote: >> The promise in question has been there for a very long time (10+ >> years, I'd guess), but there definitely could be treading problems. >> Perhaps just changing (in framework/private/icon.ss) to use the new >> thread safe stuff is the right thing. > > Yes, I've looked at them -- and they seem to be promises of the kind > that would just lead (in pre-v4 days) to more work. ?But perhaps there > was no problem until Carl somehow arranged things in a certain way. Using delay/sync for the framework icons seemed to alleviate the bug. I have committed this change. --Carl From robby at eecs.northwestern.edu Mon Nov 16 23:46:14 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Mon Nov 16 23:46:31 2009 Subject: [plt-dev] Error message from test-engine In-Reply-To: <990e0c030911161943o206ff78dvf55dee2fb5ce67e2@mail.gmail.com> References: <990e0c030911161657n55312125k7ad0a1eb7deea5c7@mail.gmail.com> <19201.65065.76671.767180@winooski.ccs.neu.edu> <932b2f1f0911161806he97777fg65728124a5a689c9@mail.gmail.com> <19202.1742.760014.852853@winooski.ccs.neu.edu> <990e0c030911161943o206ff78dvf55dee2fb5ce67e2@mail.gmail.com> Message-ID: <932b2f1f0911162046q588859f2mb878ef01ebfa7d86@mail.gmail.com> Thanks. Robby On Mon, Nov 16, 2009 at 9:43 PM, Carl Eastlund wrote: > On Mon, Nov 16, 2009 at 9:13 PM, Eli Barzilay wrote: >> On Nov 16, Robby Findler wrote: >>> The promise in question has been there for a very long time (10+ >>> years, I'd guess), but there definitely could be treading problems. >>> Perhaps just changing (in framework/private/icon.ss) to use the new >>> thread safe stuff is the right thing. >> >> Yes, I've looked at them -- and they seem to be promises of the kind >> that would just lead (in pre-v4 days) to more work. ?But perhaps there >> was no problem until Carl somehow arranged things in a certain way. > > Using delay/sync for the framework icons seemed to alleviate the bug. > I have committed this change. > > --Carl > From eli at barzilay.org Tue Nov 17 03:13:14 2009 From: eli at barzilay.org (Eli Barzilay) Date: Tue Nov 17 03:13:34 2009 Subject: [plt-dev] Release for v4.2.3 has begun Message-ID: The release process for v4.2.3 has begun: the trunk was copied to a branch for any work that is left and is now bumped to v4.2.2.900. You can go on using the trunk as usual, it is now bumped to v4.2.3.1 (to avoid having two different trees with the same version). 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.3.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://barzilay.org/ Maze is Life! From eli at barzilay.org Tue Nov 17 03:36:37 2009 From: eli at barzilay.org (Eli Barzilay) Date: Tue Nov 17 03:36:57 2009 Subject: [plt-dev] Re: [plt-scheme] Speed up check-syntax In-Reply-To: <20091110020324.623976500C7@mail-svr1.cs.utah.edu> References: <595b9ab20911090556u5115e7dfpfdd863588ea3fb34@mail.gmail.com> <932b2f1f0911091022y3344aa69qc928e555ad5c7e15@mail.gmail.com> <932b2f1f0911091055s435613c6oa3668c80afbcf509@mail.gmail.com> <19192.37625.138009.868012@winooski.ccs.neu.edu> <932b2f1f0911091413q248c6675y6aeea8c260b2cdd5@mail.gmail.com> <932b2f1f0911091415g335bd603w2e113fc6aad276c4@mail.gmail.com> <19192.38665.305259.237558@winooski.ccs.neu.edu> <932b2f1f0911091748j2b00abe9maafcef28cd328a6b@mail.gmail.com> <20091110020324.623976500C7@mail-svr1.cs.utah.edu> Message-ID: <19202.24725.519656.776568@winooski.ccs.neu.edu> I committed a change to "syncheck.ss" using the new `delay/idle'. (The `status-loading-docs-index' is now redundant, should IU remove it?) Note that on winooski (which is very fast in general), loading the docs takes some noticeable time, around 10-15 seconds IIRC. This means that an average machine can take up to twice that -- so don't try to run drscheme and click check syntax after a few seconds to see how it works. If you use it too early, then the idle promise gets forced, which uses the cpu time as usual to get it done -- and that will look as it always did. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From clements at brinckerhoff.org Tue Nov 17 14:05:15 2009 From: clements at brinckerhoff.org (John Clements) Date: Tue Nov 17 14:05:41 2009 Subject: [plt-dev] may I add example of expand? (was: Re: [plt-scheme] documentation feature requests) In-Reply-To: <932b2f1f0911151540g6f2fb5a8n1fb07dfbcb1df76a@mail.gmail.com> References: <756daca50911151354h11fa43b6qc1fba9fcaa76d9ef@mail.gmail.com> <83E2AAC8-1D90-44E0-8E4F-AF5E86D11CDB@hampshire.edu> <4B008782.9080506@neilvandyke.org> <99217E0C-9D28-4467-A94E-DF22BC6A5B10@hampshire.edu> <932b2f1f0911151540g6f2fb5a8n1fb07dfbcb1df76a@mail.gmail.com> Message-ID: On Nov 15, 2009, at 3:40 PM, Robby Findler wrote: > I've seen that Jon Rafkind has been adding such things to lots of > places in the docs and I've put them in the new image documentation > library (http://pre.plt-scheme.org/docs/html/teachpack/2htdpimage.html), > so I think it is safe to say we recognize the need and are working on > it. Every time I want to use 'expand' I have to spend 10 minutes trying to remember all of the pieces. This appears to me to be about the shortest way to use 'expand' correctly: (parameterize ([current-namespace (make-base-namespace)]) (expand (datum->syntax #f '(module foo scheme (define a 3) (+ a 4))))) Would it be appropriate to add this (or a simpler form, if it exists) to the 'expand' documentation? It would certainly have helped me. 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/20091117/fe967563/smime.bin From robby at eecs.northwestern.edu Tue Nov 17 15:07:35 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Tue Nov 17 15:07:54 2009 Subject: [plt-dev] may I add example of expand? (was: Re: [plt-scheme] documentation feature requests) In-Reply-To: References: <756daca50911151354h11fa43b6qc1fba9fcaa76d9ef@mail.gmail.com> <83E2AAC8-1D90-44E0-8E4F-AF5E86D11CDB@hampshire.edu> <4B008782.9080506@neilvandyke.org> <99217E0C-9D28-4467-A94E-DF22BC6A5B10@hampshire.edu> <932b2f1f0911151540g6f2fb5a8n1fb07dfbcb1df76a@mail.gmail.com> Message-ID: <932b2f1f0911171207v1514791cv46a9530d902fad89@mail.gmail.com> I think you probably also want an example with a namespace anchor and without a module: #lang scheme (define-namespace-anchor anchor) (parameterize ([current-namespace (namespace-anchor->namespace anchor)]) (expand (datum->syntax #f '(delay (+ 1 2))))) On Tue, Nov 17, 2009 at 1:05 PM, John Clements wrote: > > On Nov 15, 2009, at 3:40 PM, Robby Findler wrote: > >> I've seen that Jon Rafkind has been adding such things to lots of >> places in the docs and I've put them in the new image documentation >> library (http://pre.plt-scheme.org/docs/html/teachpack/2htdpimage.html), >> so I think it is safe to say we recognize the need and are working on >> it. > > Every time I want to use 'expand' I have to spend 10 minutes trying to remember all of the pieces. ?This appears to me to be about the shortest way to use 'expand' correctly: > > (parameterize ([current-namespace (make-base-namespace)]) > ?(expand > ? (datum->syntax > ? ?#f > ? ?'(module foo scheme > ? ? ? (define a 3) > ? ? ? (+ a 4))))) > > > Would it be appropriate to add this (or a simpler form, if it exists) to the 'expand' documentation? It would certainly have helped me. > > John > > > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > > From clements at brinckerhoff.org Tue Nov 17 15:30:25 2009 From: clements at brinckerhoff.org (John Clements) Date: Tue Nov 17 15:30:50 2009 Subject: [plt-dev] may I add example of expand? (was: Re: [plt-scheme] documentation feature requests) In-Reply-To: <932b2f1f0911171207v1514791cv46a9530d902fad89@mail.gmail.com> References: <756daca50911151354h11fa43b6qc1fba9fcaa76d9ef@mail.gmail.com> <83E2AAC8-1D90-44E0-8E4F-AF5E86D11CDB@hampshire.edu> <4B008782.9080506@neilvandyke.org> <99217E0C-9D28-4467-A94E-DF22BC6A5B10@hampshire.edu> <932b2f1f0911151540g6f2fb5a8n1fb07dfbcb1df76a@mail.gmail.com> <932b2f1f0911171207v1514791cv46a9530d902fad89@mail.gmail.com> Message-ID: <4048732F-FA74-4B82-87CA-FAE9695C27B2@brinckerhoff.org> On Nov 17, 2009, at 12:07 PM, Robby Findler wrote: > I think you probably also want an example with a namespace anchor and > without a module: ... I added both of these to the documentation. If this isn't an improvement, I'm happy to roll back the change. 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/20091117/ce2829f1/smime-0001.bin From robby at eecs.northwestern.edu Tue Nov 17 15:35:03 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Tue Nov 17 15:35:21 2009 Subject: [plt-dev] may I add example of expand? (was: Re: [plt-scheme] documentation feature requests) In-Reply-To: <4048732F-FA74-4B82-87CA-FAE9695C27B2@brinckerhoff.org> References: <756daca50911151354h11fa43b6qc1fba9fcaa76d9ef@mail.gmail.com> <83E2AAC8-1D90-44E0-8E4F-AF5E86D11CDB@hampshire.edu> <4B008782.9080506@neilvandyke.org> <99217E0C-9D28-4467-A94E-DF22BC6A5B10@hampshire.edu> <932b2f1f0911151540g6f2fb5a8n1fb07dfbcb1df76a@mail.gmail.com> <932b2f1f0911171207v1514791cv46a9530d902fad89@mail.gmail.com> <4048732F-FA74-4B82-87CA-FAE9695C27B2@brinckerhoff.org> Message-ID: <932b2f1f0911171235m7f563946w1ef8b25f38f7ef1e@mail.gmail.com> Sounds great to me. On Tue, Nov 17, 2009 at 2:30 PM, John Clements wrote: > > On Nov 17, 2009, at 12:07 PM, Robby Findler wrote: > >> I think you probably also want an example with a namespace anchor and >> without a module: > > ... > > I added both of these to the documentation. ?If this isn't an improvement, I'm happy to roll back the change. > > John > > From eli at barzilay.org Tue Nov 17 15:52:29 2009 From: eli at barzilay.org (Eli Barzilay) Date: Tue Nov 17 15:52:50 2009 Subject: [plt-dev] may I add example of expand? (was: Re: [plt-scheme] documentation feature requests) In-Reply-To: <4048732F-FA74-4B82-87CA-FAE9695C27B2@brinckerhoff.org> References: <756daca50911151354h11fa43b6qc1fba9fcaa76d9ef@mail.gmail.com> <83E2AAC8-1D90-44E0-8E4F-AF5E86D11CDB@hampshire.edu> <4B008782.9080506@neilvandyke.org> <99217E0C-9D28-4467-A94E-DF22BC6A5B10@hampshire.edu> <932b2f1f0911151540g6f2fb5a8n1fb07dfbcb1df76a@mail.gmail.com> <932b2f1f0911171207v1514791cv46a9530d902fad89@mail.gmail.com> <4048732F-FA74-4B82-87CA-FAE9695C27B2@brinckerhoff.org> Message-ID: <19203.3341.344849.92511@winooski.ccs.neu.edu> On Nov 17, John Clements wrote: > On Nov 17, 2009, at 12:07 PM, Robby Findler wrote: > > > I think you probably also want an example with a namespace anchor and > > without a module: > > ... > > I added both of these to the documentation. If this isn't an > improvement, I'm happy to roll back the change. Is it worth including in 4.2.3? -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From cce at ccs.neu.edu Tue Nov 17 16:55:30 2009 From: cce at ccs.neu.edu (Carl Eastlund) Date: Tue Nov 17 16:56:12 2009 Subject: [plt-dev] Re: Generated files and co-existing copies of DrScheme In-Reply-To: <990e0c030911041344tfa68c40gf2b9e32c098f6c8c@mail.gmail.com> References: <990e0c030911041344tfa68c40gf2b9e32c098f6c8c@mail.gmail.com> Message-ID: <990e0c030911171355g301a6543la9d7c16927ea32a3@mail.gmail.com> On Wed, Nov 4, 2009 at 4:44 PM, Carl Eastlund wrote: > That's a bunch of issues, and three proposals: (1) set up PLTUSERDIR > to control placement of Planet and Scribble generated files, (2) pick > a conventional place in the PLT tree for users to store it who can and > wish to do so, and (3) longer term, think about a way to fit > development link code into this story. ?So -- what do the rest of you > developer folks think? I did #1 and #2 on a branch (http://svn.plt-scheme.org/plt/branches/cce/plt+addon-dir). I updated the C implementation of (find-system-path 'addon-dir) to first check the PLTADDONDIR environment variable; Planet and Scribble both use the addon-dir, so it seems to be the right point of control. I also updated the Scribble documentation for find-system-path, and added an svn:ignore property for $PLTHOME/add-on as a canonical place for in-tree add-on directories. I have built the PLT tree with PLTADDONDIR set (which put scribble files in the custom add-on directory), run `planet show' (which constructed and queried a planet cache in the custom add-on directory), and run $PLTHOME/collects/tests/run-automated-tests.ss (which succeeded). All of this was on Mac OS X. Does anyone object if I move this to the trunk? Is there anything I need to do first (e.g. testing on other platforms)? I have attached the relevant patch for the trunk if anyone wants to try this change without grabbing the whole branch. --Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: plt+addon-dir.diff Type: application/octet-stream Size: 2405 bytes Desc: not available Url : http://list.cs.brown.edu/pipermail/plt-dev/attachments/20091117/f740cbb8/pltaddon-dir.obj From clements at brinckerhoff.org Tue Nov 17 17:09:26 2009 From: clements at brinckerhoff.org (John Clements) Date: Wed Nov 18 10:28:01 2009 Subject: [plt-dev] may I add example of expand? (was: Re: [plt-scheme] documentation feature requests) In-Reply-To: <19203.3341.344849.92511@winooski.ccs.neu.edu> References: <756daca50911151354h11fa43b6qc1fba9fcaa76d9ef@mail.gmail.com> <83E2AAC8-1D90-44E0-8E4F-AF5E86D11CDB@hampshire.edu> <4B008782.9080506@neilvandyke.org> <99217E0C-9D28-4467-A94E-DF22BC6A5B10@hampshire.edu> <932b2f1f0911151540g6f2fb5a8n1fb07dfbcb1df76a@mail.gmail.com> <932b2f1f0911171207v1514791cv46a9530d902fad89@mail.gmail.com> <4048732F-FA74-4B82-87CA-FAE9695C27B2@brinckerhoff.org> <19203.3341.344849.92511@winooski.ccs.neu.edu> Message-ID: <24982B41-58FF-43A1-9F17-524C68B57630@brinckerhoff.org> On Nov 17, 2009, at 12:52 PM, Eli Barzilay wrote: > On Nov 17, John Clements wrote: >> On Nov 17, 2009, at 12:07 PM, Robby Findler wrote: >> >>> I think you probably also want an example with a namespace anchor and >>> without a module: >> >> ... >> >> I added both of these to the documentation. If this isn't an >> improvement, I'm happy to roll back the change. > > Is it worth including in 4.2.3? No, I don't think I'd bother. 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/20091117/d2fde8b9/smime.bin From cce at ccs.neu.edu Wed Nov 18 13:54:57 2009 From: cce at ccs.neu.edu (Carl Eastlund) Date: Wed Nov 18 13:55:34 2009 Subject: [plt-dev] Build error in r16874 Message-ID: <990e0c030911181054h5fdaa86fr33b62d43d14d06f5@mail.gmail.com> I get the following build error from a clean build on Mac OS X / PPC: env XFORM_USE_PRECOMP=xsrc/precomp.h ../mzschemecgc -cqu ../../../mzscheme/gc2/xform.ss --setup . --cpp "gcc -E -I./.. -I../../../mzscheme/gc2/../include -DOS_X -D_DARWIN_UNLIMITED_SELECT -fno-common -DNEWGC_BTC_ACCOUNT " --keep-lines -o xsrc/jit.c ../../../mzscheme/gc2/../src/jit.c gcc -I./.. -I../../../mzscheme/gc2/../include -g -O2 -DOS_X -D_DARWIN_UNLIMITED_SELECT -fno-common -DNEWGC_BTC_ACCOUNT -Wall -c xsrc/jit.c -o jit.o xsrc/jit.c:3: warning: ignoring #pragma GCC diagnostic xsrc/jit.c:6: warning: ignoring #pragma GCC diagnostic ../../../mzscheme/gc2/../src/jit.c: In function 'generate_arith': ../../../mzscheme/gc2/../src/jit.c:4482: warning: value computed is not used ../../../mzscheme/gc2/../src/jit.c: In function 'do_generate_common': ../../../mzscheme/gc2/../src/jit.c:8302: warning: value computed is not used ../../../mzscheme/gc2/../src/jit.c: In function 'generate_alloc_retry': ../../../mzscheme/gc2/../src/jit.c:9103: error: 'ts_prepare_retry_alloc' undeclared (first use in this function) ../../../mzscheme/gc2/../src/jit.c:9103: error: (Each undeclared identifier is reported only once ../../../mzscheme/gc2/../src/jit.c:9103: error: for each function it appears in.) ../../../mzscheme/gc2/../src/jit.c:9103: warning: left-hand operand of comma expression has no effect ../../../mzscheme/gc2/../src/jit.c:9103: warning: left-hand operand of comma expression has no effect Carl Eastlund From cce at ccs.neu.edu Wed Nov 18 13:57:59 2009 From: cce at ccs.neu.edu (Carl Eastlund) Date: Wed Nov 18 13:58:36 2009 Subject: [plt-dev] DrDr slowdown @ r16860 Message-ID: <990e0c030911181057j6c4b0bcbp3c978d329c6a4b12@mail.gmail.com> In case this has not been noticed yet, something in revision 16860 caused DrDr to start taking 3 times as long for each revision (~90 minutes instead of ~30). It is currently about 10 revisions behind. Carl Eastlund From samth at ccs.neu.edu Wed Nov 18 14:11:20 2009 From: samth at ccs.neu.edu (Sam TH) Date: Wed Nov 18 14:11:59 2009 Subject: [plt-dev] Build error in r16874 In-Reply-To: <990e0c030911181054h5fdaa86fr33b62d43d14d06f5@mail.gmail.com> References: <990e0c030911181054h5fdaa86fr33b62d43d14d06f5@mail.gmail.com> Message-ID: <63bb19ae0911181111h150ae810tef956cea98bdefa@mail.gmail.com> On Wed, Nov 18, 2009 at 1:54 PM, Carl Eastlund wrote: > I get the following build error from a clean build on Mac OS X / PPC: Since I expect this is from all the commits that Matthew and James are doing at the moment, this seems like a good time to mention that this is what branches are for. At this point, we may just want to muddle through, but next time it would probably be better to have the work done on a branch. -- sam th samth@ccs.neu.edu From jay.mccarthy at gmail.com Wed Nov 18 14:31:19 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Wed Nov 18 14:31:42 2009 Subject: [plt-dev] DrDr slowdown @ r16860 In-Reply-To: <990e0c030911181057j6c4b0bcbp3c978d329c6a4b12@mail.gmail.com> References: <990e0c030911181057j6c4b0bcbp3c978d329c6a4b12@mail.gmail.com> Message-ID: There are also many timeouts and unclean exits. On Wed, Nov 18, 2009 at 11:57 AM, Carl Eastlund wrote: > In case this has not been noticed yet, something in revision 16860 > caused DrDr to start taking 3 times as long for each revision (~90 > minutes instead of ~30). ?It is currently about 10 revisions behind. > > Carl Eastlund > _________________________________________________ > ?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 Wed Nov 18 15:26:41 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Wed Nov 18 15:26:58 2009 Subject: [plt-dev] DrDr slowdown @ r16860 In-Reply-To: References: <990e0c030911181057j6c4b0bcbp3c978d329c6a4b12@mail.gmail.com> Message-ID: <20091118202642.15B3C6500EE@mail-svr1.cs.utah.edu> Sorry for all the bad commits. A group of us are working on MzScheme internals for a few days. To keep things simple, we've been collaborating via the trunk --- but we know that isn't working well for everyone else. We'll use a branch next time. At Wed, 18 Nov 2009 12:31:19 -0700, Jay McCarthy wrote: > There are also many timeouts and unclean exits. > > On Wed, Nov 18, 2009 at 11:57 AM, Carl Eastlund wrote: > > In case this has not been noticed yet, something in revision 16860 > > caused DrDr to start taking 3 times as long for each revision (~90 > > minutes instead of ~30). ?It is currently about 10 revisions behind. From eli at barzilay.org Fri Nov 20 02:36:50 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri Nov 20 02:37:10 2009 Subject: [plt-dev] Re: Generated files and co-existing copies of DrScheme In-Reply-To: <990e0c030911171355g301a6543la9d7c16927ea32a3@mail.gmail.com> References: <990e0c030911041344tfa68c40gf2b9e32c098f6c8c@mail.gmail.com> <990e0c030911171355g301a6543la9d7c16927ea32a3@mail.gmail.com> Message-ID: <19206.18194.888779.705087@winooski.ccs.neu.edu> On Nov 17, Carl Eastlund wrote: > On Wed, Nov 4, 2009 at 4:44 PM, Carl Eastlund wrote: > > That's a bunch of issues, and three proposals: (1) set up PLTUSERDIR > > to control placement of Planet and Scribble generated files, (2) pick > > a conventional place in the PLT tree for users to store it who can and > > wish to do so, and (3) longer term, think about a way to fit > > development link code into this story. ?So -- what do the rest of you > > developer folks think? > > I did #1 and #2 on a branch > (http://svn.plt-scheme.org/plt/branches/cce/plt+addon-dir). I > updated the C implementation of (find-system-path 'addon-dir) to > first check the PLTADDONDIR environment variable; Planet and > Scribble both use the addon-dir, so it seems to be the right point > of control. I also updated the Scribble documentation for > find-system-path, and added an svn:ignore property for > $PLTHOME/add-on as a canonical place for in-tree add-on directories. I see several issues with this: 1. As much as I personally like environment variables, it seems that they're generally confusing. Doing this change as another variable means that now the exact collection search is determined by: - $PLTCOLLECTS - Uses of `-S', `-X', and `-U' - $PLTADDONDIR - Any dynamic changes to the search path The first is a good source of complaints and confusion, and adding another environment variable seems like it will make things worse. (It doesn't help that Windows and even OSX users find it difficult to control them.) So, I think that a command-line argument would be better. It might even make sense to use `+U'. 2. There is a potential problem with code that uses `find-system-path' with 'addon-dir where 'pref-dir should have been used. But at least on my system I don't see anything that would break. 3. IIUC, the only problem that this solves is using several different installations with the same version number, is this true? Is that problem *so* common? If so, then maybe have instead a way to use your own additional suffix to the version part that gets used in ~/.plt-scheme// and ~/.plt-scheme/planet/300// ? Or maybe go the other way -- make the default addon-dir include the version (so on linux it becomes ~/.plt-scheme/), and have no version directory for the local collects (so they end up in exactly the same place), planet can drop the version directory too (and the redundantly outdated "300" part). Then it makes more sense to have a command line flag or environment variable move everything, without getting a second level of version-dependant directories. (The only problem that I see here is that the planet "cache" is less of a cache than it is now.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From robby at eecs.northwestern.edu Fri Nov 20 07:02:43 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Fri Nov 20 07:03:05 2009 Subject: [plt-dev] Re: Generated files and co-existing copies of DrScheme In-Reply-To: <19206.18194.888779.705087@winooski.ccs.neu.edu> References: <990e0c030911041344tfa68c40gf2b9e32c098f6c8c@mail.gmail.com> <990e0c030911171355g301a6543la9d7c16927ea32a3@mail.gmail.com> <19206.18194.888779.705087@winooski.ccs.neu.edu> Message-ID: <932b2f1f0911200402g1ce3fc77uceb91db9335b261e@mail.gmail.com> The "300" in the planet cache path contains stuff that is common to all 3xx and 4.x versions (cached copies of the uninstalled .plt files... maybe that's all?). Robby On Fri, Nov 20, 2009 at 1:36 AM, Eli Barzilay wrote: > On Nov 17, Carl Eastlund wrote: >> On Wed, Nov 4, 2009 at 4:44 PM, Carl Eastlund wrote: >> > That's a bunch of issues, and three proposals: (1) set up PLTUSERDIR >> > to control placement of Planet and Scribble generated files, (2) pick >> > a conventional place in the PLT tree for users to store it who can and >> > wish to do so, and (3) longer term, think about a way to fit >> > development link code into this story. ?So -- what do the rest of you >> > developer folks think? >> >> I did #1 and #2 on a branch >> (http://svn.plt-scheme.org/plt/branches/cce/plt+addon-dir). ?I >> updated the C implementation of (find-system-path 'addon-dir) to >> first check the PLTADDONDIR environment variable; Planet and >> Scribble both use the addon-dir, so it seems to be the right point >> of control. ?I also updated the Scribble documentation for >> find-system-path, and added an svn:ignore property for >> $PLTHOME/add-on as a canonical place for in-tree add-on directories. > > I see several issues with this: > > 1. As much as I personally like environment variables, it seems that > ? they're generally confusing. ?Doing this change as another variable > ? means that now the exact collection search is determined by: > ? - $PLTCOLLECTS > ? - Uses of `-S', `-X', and `-U' > ? - $PLTADDONDIR > ? - Any dynamic changes to the search path > ? The first is a good source of complaints and confusion, and adding > ? another environment variable seems like it will make things worse. > ? (It doesn't help that Windows and even OSX users find it difficult > ? to control them.) > > ? So, I think that a command-line argument would be better. ?It might > ? even make sense to use `+U'. > > 2. There is a potential problem with code that uses `find-system-path' > ? with 'addon-dir where 'pref-dir should have been used. ?But at > ? least on my system I don't see anything that would break. > > 3. IIUC, the only problem that this solves is using several different > ? installations with the same version number, is this true? ?Is that > ? problem *so* common? ?If so, then maybe have instead a way to use > ? your own additional suffix to the version part that gets used in > ? ~/.plt-scheme// and ~/.plt-scheme/planet/300// ? > > ? Or maybe go the other way -- make the default addon-dir include the > ? version (so on linux it becomes ~/.plt-scheme/), and have > ? no version directory for the local collects (so they end up in > ? exactly the same place), planet can drop the version directory too > ? (and the redundantly outdated "300" part). ?Then it makes more > ? sense to have a command line flag or environment variable move > ? everything, without getting a second level of version-dependant > ? directories. ?(The only problem that I see here is that the planet > ? "cache" is less of a cache than it is now.) > > -- > ? ? ? ? ?((lambda (x) (x x)) (lambda (x) (x x))) ? ? ? ? ?Eli Barzilay: > ? ? ? ? ? ? ? ? ? ?http://barzilay.org/ ? ? ? ? ? ? ? ? ? Maze is Life! > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > From cce at ccs.neu.edu Fri Nov 20 08:35:55 2009 From: cce at ccs.neu.edu (Carl Eastlund) Date: Fri Nov 20 08:36:35 2009 Subject: [plt-dev] Re: Generated files and co-existing copies of DrScheme In-Reply-To: <19206.18194.888779.705087@winooski.ccs.neu.edu> References: <990e0c030911041344tfa68c40gf2b9e32c098f6c8c@mail.gmail.com> <990e0c030911171355g301a6543la9d7c16927ea32a3@mail.gmail.com> <19206.18194.888779.705087@winooski.ccs.neu.edu> Message-ID: <990e0c030911200535m6d320cadj246fd0f372b36046@mail.gmail.com> On Fri, Nov 20, 2009 at 2:36 AM, Eli Barzilay wrote: > On Nov 17, Carl Eastlund wrote: >> On Wed, Nov 4, 2009 at 4:44 PM, Carl Eastlund wrote: >> > That's a bunch of issues, and three proposals: (1) set up PLTUSERDIR >> > to control placement of Planet and Scribble generated files, (2) pick >> > a conventional place in the PLT tree for users to store it who can and >> > wish to do so, and (3) longer term, think about a way to fit >> > development link code into this story. ?So -- what do the rest of you >> > developer folks think? >> >> I did #1 and #2 on a branch >> (http://svn.plt-scheme.org/plt/branches/cce/plt+addon-dir). ?I >> updated the C implementation of (find-system-path 'addon-dir) to >> first check the PLTADDONDIR environment variable; Planet and >> Scribble both use the addon-dir, so it seems to be the right point >> of control. ?I also updated the Scribble documentation for >> find-system-path, and added an svn:ignore property for >> $PLTHOME/add-on as a canonical place for in-tree add-on directories. > > I see several issues with this: > > 1. As much as I personally like environment variables, it seems that > ? they're generally confusing. ?Doing this change as another variable > ? means that now the exact collection search is determined by: > ? - $PLTCOLLECTS > ? - Uses of `-S', `-X', and `-U' > ? - $PLTADDONDIR > ? - Any dynamic changes to the search path > ? The first is a good source of complaints and confusion, and adding > ? another environment variable seems like it will make things worse. > ? (It doesn't help that Windows and even OSX users find it difficult > ? to control them.) You forgot $PLTPLANETDIR. I would be happy to try to simplify this to a single environment variable, but I think that means adding PLTADDONDIR and letting it replace PLTCOLLECTS and PLTPLANETDIR (not to mention the purely hypothetical PLTSCRIBBLEDIR). I'm not sure whether breaking compatibility for anyone who uses PLTCOLLECTS or PLTPLANETDIR is worth it for the amount of simplification. > ? So, I think that a command-line argument would be better. ?It might > ? even make sense to use `+U'. Then I have to type it every time I run the command, though. I want something I can, for the most part, set and forget. And I need the command that runs 'mzscheme' to be 'mzscheme', for instance (not 'mzscheme-4.2.2') so that scripts that call 'mzscheme' always get the one that I have chosen as recently built and fully functional. > 2. There is a potential problem with code that uses `find-system-path' > ? with 'addon-dir where 'pref-dir should have been used. ?But at > ? least on my system I don't see anything that would break. That sounds like a complaint about find-system-path, regardless of this environment variable. > 3. IIUC, the only problem that this solves is using several different > ? installations with the same version number, is this true? ?Is that > ? problem *so* common? ?If so, then maybe have instead a way to use > ? your own additional suffix to the version part that gets used in > ? ~/.plt-scheme// and ~/.plt-scheme/planet/300// ? I run into this problem every single day when I update my PLT trunk checkout. I either have to spend the duration of a complete build (including all documentation, installed planet packages, and recovery from any build errors) unable to run any PLT Scheme code of any variety -- essentially unable to work -- or I need some way to have two PLT Scheme installations of the same version that don't "share" compiled planet code. > ? Or maybe go the other way -- make the default addon-dir include the > ? version (so on linux it becomes ~/.plt-scheme/), and have > ? no version directory for the local collects (so they end up in > ? exactly the same place), planet can drop the version directory too > ? (and the redundantly outdated "300" part). ?Then it makes more > ? sense to have a command line flag or environment variable move > ? everything, without getting a second level of version-dependant > ? directories. ?(The only problem that I see here is that the planet > ? "cache" is less of a cache than it is now.) Maybe we need two settings -- PLTADDONIR and PLTVERSION. The PLTADDONDIR would then be static (I'd have no need to set it more than once -- and if I don't mind the default, not at all), and have a subdirectory for each version, plus one for a shared planet cache. Then I could set PLTVERSION for separate installations, which would override the version string *only* for the purposes of choosing a subdirectory of PLTADDONDIR. The directory tree would look like this: $PLTADDONDIR/ planet-cache/ 4.2.2/ collects/ planet/ scribblings/ 4.2.2.1/ collects/ planet/ scribblings/ ...and so forth... This would be a significant change to the way things are layed out, though. My current patch doesn't break any existing setup or change any existing directory structure. Furthermore it is already written. --Carl From cce at ccs.neu.edu Fri Nov 20 08:50:46 2009 From: cce at ccs.neu.edu (Carl Eastlund) Date: Fri Nov 20 08:51:23 2009 Subject: [plt-dev] Re: Generated files and co-existing copies of DrScheme In-Reply-To: <990e0c030911200535m6d320cadj246fd0f372b36046@mail.gmail.com> References: <990e0c030911041344tfa68c40gf2b9e32c098f6c8c@mail.gmail.com> <990e0c030911171355g301a6543la9d7c16927ea32a3@mail.gmail.com> <19206.18194.888779.705087@winooski.ccs.neu.edu> <990e0c030911200535m6d320cadj246fd0f372b36046@mail.gmail.com> Message-ID: <990e0c030911200550o78020f64lb065f1f5746bb6b7@mail.gmail.com> Pardon my pre-morning-coffee thinking. There were a few mistakes here: On Fri, Nov 20, 2009 at 8:35 AM, Carl Eastlund wrote: >> 3. IIUC, the only problem that this solves is using several different >> ? installations with the same version number, is this true? ?Is that >> ? problem *so* common? ?If so, then maybe have instead a way to use >> ? your own additional suffix to the version part that gets used in >> ? ~/.plt-scheme// and ~/.plt-scheme/planet/300// ? > > I run into this problem every single day when I update my PLT trunk > checkout. ?I either have to spend the duration of a complete build > (including all documentation, installed planet packages, and recovery > from any build errors) unable to run any PLT Scheme code of any > variety -- essentially unable to work -- or I need some way to have > two PLT Scheme installations of the same version that don't "share" > compiled planet code. The above describes the problem I run into in general, much of which is alleviated by PLTPLANETDIR. I still have the problem of clashing docs, so I can't run Help Desk in the interim and I'm stuck with the newest version afterword. However I am able to run mzscheme, drscheme, planet, setup-plt, etc. >> ? Or maybe go the other way -- make the default addon-dir include the >> ? version (so on linux it becomes ~/.plt-scheme/), and have >> ? no version directory for the local collects (so they end up in >> ? exactly the same place), planet can drop the version directory too >> ? (and the redundantly outdated "300" part). ?Then it makes more >> ? sense to have a command line flag or environment variable move >> ? everything, without getting a second level of version-dependant >> ? directories. ?(The only problem that I see here is that the planet >> ? "cache" is less of a cache than it is now.) > > Maybe we need two settings -- PLTADDONIR and PLTVERSION. ?The > PLTADDONDIR would then be static (I'd have no need to set it more than > once -- and if I don't mind the default, not at all), and have a > subdirectory for each version, plus one for a shared planet cache. > Then I could set PLTVERSION for separate installations, which would > override the version string *only* for the purposes of choosing a > subdirectory of PLTADDONDIR. ?The directory tree would look like this: > > $PLTADDONDIR/ > ?planet-cache/ > ?4.2.2/ > ? ?collects/ > ? ?planet/ > ? ?scribblings/ > ?4.2.2.1/ > ? ?collects/ > ? ?planet/ > ? ?scribblings/ > ?...and so forth... Moving PLTCOLLECTS here is odd because that's usually a user directory, much like planet development links. So I'm not sure if the collects/ subdirectory should be there. And perhaps the preferences file should be there (at the same level as planet-cache). Since this part is all hypothetical, the structure is up for debate anyway. --Carl From robby at eecs.northwestern.edu Fri Nov 20 09:05:41 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Fri Nov 20 09:05:58 2009 Subject: [plt-dev] Re: Generated files and co-existing copies of DrScheme In-Reply-To: <990e0c030911200550o78020f64lb065f1f5746bb6b7@mail.gmail.com> References: <990e0c030911041344tfa68c40gf2b9e32c098f6c8c@mail.gmail.com> <990e0c030911171355g301a6543la9d7c16927ea32a3@mail.gmail.com> <19206.18194.888779.705087@winooski.ccs.neu.edu> <990e0c030911200535m6d320cadj246fd0f372b36046@mail.gmail.com> <990e0c030911200550o78020f64lb065f1f5746bb6b7@mail.gmail.com> Message-ID: <932b2f1f0911200605u775f06aue1f77de5743d4fd0@mail.gmail.com> On Fri, Nov 20, 2009 at 7:50 AM, Carl Eastlund wrote: > Pardon my pre-morning-coffee thinking. ?There were a few mistakes here: > > On Fri, Nov 20, 2009 at 8:35 AM, Carl Eastlund wrote: >>> 3. IIUC, the only problem that this solves is using several different >>> ? installations with the same version number, is this true? ?Is that >>> ? problem *so* common? ?If so, then maybe have instead a way to use >>> ? your own additional suffix to the version part that gets used in >>> ? ~/.plt-scheme// and ~/.plt-scheme/planet/300// ? >> >> I run into this problem every single day when I update my PLT trunk >> checkout. ?I either have to spend the duration of a complete build >> (including all documentation, installed planet packages, and recovery >> from any build errors) unable to run any PLT Scheme code of any >> variety -- essentially unable to work -- or I need some way to have >> two PLT Scheme installations of the same version that don't "share" >> compiled planet code. > > The above describes the problem I run into in general, much of which > is alleviated by PLTPLANETDIR. ?I still have the problem of clashing > docs, so I can't run Help Desk in the interim and I'm stuck with the > newest version afterword. ?However I am able to run mzscheme, > drscheme, planet, setup-plt, etc. Not to be contrarian, but pre-relase docs are probably close enough usually, right? Robby From cce at ccs.neu.edu Fri Nov 20 09:14:59 2009 From: cce at ccs.neu.edu (Carl Eastlund) Date: Fri Nov 20 09:15:36 2009 Subject: [plt-dev] Re: Generated files and co-existing copies of DrScheme In-Reply-To: <932b2f1f0911200605u775f06aue1f77de5743d4fd0@mail.gmail.com> References: <990e0c030911041344tfa68c40gf2b9e32c098f6c8c@mail.gmail.com> <990e0c030911171355g301a6543la9d7c16927ea32a3@mail.gmail.com> <19206.18194.888779.705087@winooski.ccs.neu.edu> <990e0c030911200535m6d320cadj246fd0f372b36046@mail.gmail.com> <990e0c030911200550o78020f64lb065f1f5746bb6b7@mail.gmail.com> <932b2f1f0911200605u775f06aue1f77de5743d4fd0@mail.gmail.com> Message-ID: <990e0c030911200614v2b157000ga9d2bc11f10df10c@mail.gmail.com> On Fri, Nov 20, 2009 at 9:05 AM, Robby Findler wrote: > On Fri, Nov 20, 2009 at 7:50 AM, Carl Eastlund wrote: >> Pardon my pre-morning-coffee thinking. ?There were a few mistakes here: >> >> On Fri, Nov 20, 2009 at 8:35 AM, Carl Eastlund wrote: >>>> 3. IIUC, the only problem that this solves is using several different >>>> ? installations with the same version number, is this true? ?Is that >>>> ? problem *so* common? ?If so, then maybe have instead a way to use >>>> ? your own additional suffix to the version part that gets used in >>>> ? ~/.plt-scheme// and ~/.plt-scheme/planet/300// ? >>> >>> I run into this problem every single day when I update my PLT trunk >>> checkout. ?I either have to spend the duration of a complete build >>> (including all documentation, installed planet packages, and recovery >>> from any build errors) unable to run any PLT Scheme code of any >>> variety -- essentially unable to work -- or I need some way to have >>> two PLT Scheme installations of the same version that don't "share" >>> compiled planet code. >> >> The above describes the problem I run into in general, much of which >> is alleviated by PLTPLANETDIR. ?I still have the problem of clashing >> docs, so I can't run Help Desk in the interim and I'm stuck with the >> newest version afterword. ?However I am able to run mzscheme, >> drscheme, planet, setup-plt, etc. > > Not to be contrarian, but pre-relase docs are probably close enough > usually, right? Unfortunately, the new docs invariably lack planet packages (both downloaded and development linked). I spend a lot of time programming with planet code, and looking up documentation for it, and without up-to-date local documentation I wind up having to go to planet.plt-scheme.org and lookup documentation by browsing specific versions of each package, without the benefit of Help Desk's search page. --Carl From sstrickl at ccs.neu.edu Fri Nov 20 14:37:17 2009 From: sstrickl at ccs.neu.edu (Stevie Strickland) Date: Fri Nov 20 14:37:41 2009 Subject: [plt-dev] Objections to removing class100? Message-ID: <26D22E06-7B53-4A6F-B001-51FF924DC296@ccs.neu.edu> We're interested in finally removing class100 from PLT Scheme. Are there any objections? Stevie From clements at brinckerhoff.org Fri Nov 20 14:53:39 2009 From: clements at brinckerhoff.org (John Clements) Date: Fri Nov 20 14:53:58 2009 Subject: [plt-dev] Objections to removing class100? In-Reply-To: <26D22E06-7B53-4A6F-B001-51FF924DC296@ccs.neu.edu> References: <26D22E06-7B53-4A6F-B001-51FF924DC296@ccs.neu.edu> Message-ID: On Nov 20, 2009, at 11:37 AM, Stevie Strickland wrote: > We're interested in finally removing class100 from PLT Scheme. Are there any objections? Are you planning on asking plt-edu, as well? I'm guessing that's where you'll find the holdouts. 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/20091120/0e76d3e0/smime.bin From sstrickl at ccs.neu.edu Fri Nov 20 15:01:07 2009 From: sstrickl at ccs.neu.edu (Stevie Strickland) Date: Fri Nov 20 15:01:31 2009 Subject: [plt-dev] Objections to removing class100? In-Reply-To: References: <26D22E06-7B53-4A6F-B001-51FF924DC296@ccs.neu.edu> Message-ID: <94EC714F-F1EF-41DC-9089-8FA0F1B75759@ccs.neu.edu> On Nov 20, 2009, at 2:53 PM, John Clements wrote: > On Nov 20, 2009, at 11:37 AM, Stevie Strickland wrote: > >> We're interested in finally removing class100 from PLT Scheme. Are there any objections? > > Are you planning on asking plt-edu, as well? I'm guessing that's where you'll find the holdouts. A good point. I'm not on plt-edu, though. Matthias? Stevie From eli at barzilay.org Fri Nov 20 15:51:19 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri Nov 20 15:51:42 2009 Subject: [plt-dev] Re: Generated files and co-existing copies of DrScheme In-Reply-To: <990e0c030911200535m6d320cadj246fd0f372b36046@mail.gmail.com>, <990e0c030911200550o78020f64lb065f1f5746bb6b7@mail.gmail.com>, <990e0c030911200614v2b157000ga9d2bc11f10df10c@mail.gmail.com> References: <990e0c030911041344tfa68c40gf2b9e32c098f6c8c@mail.gmail.com> <990e0c030911171355g301a6543la9d7c16927ea32a3@mail.gmail.com> <19206.18194.888779.705087@winooski.ccs.neu.edu> <990e0c030911200535m6d320cadj246fd0f372b36046@mail.gmail.com> <990e0c030911200550o78020f64lb065f1f5746bb6b7@mail.gmail.com> <932b2f1f0911200605u775f06aue1f77de5743d4fd0@mail.gmail.com> <990e0c030911200614v2b157000ga9d2bc11f10df10c@mail.gmail.com> Message-ID: <19207.327.88666.63513@winooski.ccs.neu.edu> On Nov 20, Carl Eastlund wrote: > > I would be happy to try to simplify this to a single environment > variable, but I think that means adding PLTADDONDIR and letting it > replace PLTCOLLECTS and PLTPLANETDIR (not to mention the purely > hypothetical PLTSCRIBBLEDIR). I'm not sure whether breaking > compatibility for anyone who uses PLTCOLLECTS or PLTPLANETDIR is > worth it for the amount of simplification. I don't think that it's possible to make a single variable as powerful as all three. In any case, and as is usually the case with environment variables, changing things is very painful, since these things are stuck in all kinds of places. > > ? So, I think that a command-line argument would be better. ?It > > ? might even make sense to use `+U'. > > Then I have to type it every time I run the command, though. Why? If you know how to use them, then you should be able to use a script. > I want something I can, for the most part, set and forget. And I > need the command that runs 'mzscheme' to be 'mzscheme', for instance > (not 'mzscheme-4.2.2') so that scripts that call 'mzscheme' always > get the one that I have chosen as recently built and fully > functional. I don't get this. Translating an environment variable into a command-line argument is trivial. In this case, if there is a `+U' and no environment variable, I can still get it with: #!/bin/sh if [ "x$PLTADDONDIR" = "" ]; then exec /path/to/plt/bin/mzscheme "$@" else exec /path/to/plt/bin/mzscheme +S "$PLTADDONDIR" "$@" fi Or, since you want the addons to be in the PLT tree, then here's a version that uses a PLTHOME variable: #!/bin/sh exec "$PLTHOME/plt/bin/mzscheme" +S "$PLTHOME/addons" "$@" Now you just need to set PLTHOME and get everything -- and you don't even need to specify the path to the right mzscheme to run. You can even call it `mz', making it even easier to start. [FWIW, this is exactly how I run mzscheme -- I have a script that chooses a binary based on PLTHOME, and I have a convenient shell alias to toggle between the released version and the nightly build, and in the case of the released version in my home directory I have this script choose the right binary because I'm using a single directory with binaries for all platforms.] Look, the story with environment variables vs command-line flags is esentially the same one as with keyword arguments vs parameters. Parameters are more convenient in ways that make them lead to potentially more mess, like forgetting that the code goes through some dynamic context that changes it. In your patch for example, you fetch the environment variable dynamically, which means that things can get interesting with code that uses `putenv'. Fixing that wouldn't be hard, and it would get a bit closer to just a command-line flag. Another problem with environment variables is that they get passed on in strange ways. I've seen people hopelessly confused on Windows, since changing the environment is done in an awkward way. I've also seen cases where people had scripts that would set the variable somewhere on the way, in a place that they didn't see, leading to very confusing bugs where things are just not right no matter what you do. It's like the usual problem with parameters being dynamic, with the added fun bit of doing so cross-language (from shells to the process), and/or weird places where you get to set your environment variables. This is why I'm saying that personally I like them -- I work in a way that makes them very obvious (a traditional shell, basically). But that's not true for probably somewhere around 95% of the users. (You can see that in one of the many emails about PLTCOLLECTS -- it uses the colon convention which just makes a lot of sense, and is used in several places -- so I thought it would be much more known than it turns out to be (=> roughly zero people knew about it).) > I run into this problem every single day when I update my PLT trunk > checkout. I either have to spend the duration of a complete build > (including all documentation, installed planet packages, and recovery > from any build errors) That goes back to the nightly build -- why not use it? It *is* happenning every day, and the results are packaged in about 200 different ways. (Yes, you still need planet, in case the version or some interface changed, but most of the work is done if you use the nightly build.) > unable to run any PLT Scheme code of any variety -- essentially > unable to work -- [...] Or the least you can do if you really don't want to use the nightly build is run it during the night in a cron job. On Nov 20, Carl Eastlund wrote: > On Fri, Nov 20, 2009 at 9:05 AM, Robby Findler > wrote: > > > > Not to be contrarian, but pre-relase docs are probably close enough > > usually, right? > > Unfortunately, the new docs invariably lack planet packages (both > downloaded and development linked). I spend a lot of time > programming with planet code, and looking up documentation for it, > and without up-to-date local documentation I wind up having to go to > planet.plt-scheme.org and lookup documentation by browsing specific > versions of each package, without the benefit of Help Desk's search > page. But that should be a much faster process to compile just these if you use the nightly build. Or in almost all cases you should be fine with the same build when the PLT version didn't change. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From cce at ccs.neu.edu Fri Nov 20 16:20:50 2009 From: cce at ccs.neu.edu (Carl Eastlund) Date: Fri Nov 20 16:21:27 2009 Subject: [plt-dev] Re: Generated files and co-existing copies of DrScheme In-Reply-To: <19207.327.88666.63513@winooski.ccs.neu.edu> References: <990e0c030911041344tfa68c40gf2b9e32c098f6c8c@mail.gmail.com> <990e0c030911171355g301a6543la9d7c16927ea32a3@mail.gmail.com> <19206.18194.888779.705087@winooski.ccs.neu.edu> <932b2f1f0911200605u775f06aue1f77de5743d4fd0@mail.gmail.com> <990e0c030911200535m6d320cadj246fd0f372b36046@mail.gmail.com> <990e0c030911200550o78020f64lb065f1f5746bb6b7@mail.gmail.com> <990e0c030911200614v2b157000ga9d2bc11f10df10c@mail.gmail.com> <19207.327.88666.63513@winooski.ccs.neu.edu> Message-ID: <990e0c030911201320q2dff6537t7330d0032792ec90@mail.gmail.com> On Fri, Nov 20, 2009 at 3:51 PM, Eli Barzilay wrote: > On Nov 20, Carl Eastlund wrote: >> >> I would be happy to try to simplify this to a single environment >> variable, but I think that means adding PLTADDONDIR and letting it >> replace PLTCOLLECTS and PLTPLANETDIR (not to mention the purely >> hypothetical PLTSCRIBBLEDIR). ?I'm not sure whether breaking >> compatibility for anyone who uses PLTCOLLECTS or PLTPLANETDIR is >> worth it for the amount of simplification. > > I don't think that it's possible to make a single variable as powerful > as all three. ?In any case, and as is usually the case with > environment variables, changing things is very painful, since these > things are stuck in all kinds of places. > > >> > ? So, I think that a command-line argument would be better. ?It >> > ? might even make sense to use `+U'. >> >> Then I have to type it every time I run the command, though. > > Why? ?If you know how to use them, then you should be able to use a > script. > > >> I want something I can, for the most part, set and forget. ?And I >> need the command that runs 'mzscheme' to be 'mzscheme', for instance >> (not 'mzscheme-4.2.2') so that scripts that call 'mzscheme' always >> get the one that I have chosen as recently built and fully >> functional. > > I don't get this. ?Translating an environment variable into a > command-line argument is trivial. ?In this case, if there is a `+U' > and no environment variable, I can still get it with: > > ?#!/bin/sh > ?if [ "x$PLTADDONDIR" = "" ]; then exec /path/to/plt/bin/mzscheme "$@" > ?else exec /path/to/plt/bin/mzscheme +S "$PLTADDONDIR" "$@" > ?fi > > Or, since you want the addons to be in the PLT tree, then here's a > version that uses a PLTHOME variable: > > ?#!/bin/sh > ?exec "$PLTHOME/plt/bin/mzscheme" +S "$PLTHOME/addons" "$@" > > Now you just need to set PLTHOME and get everything -- and you don't > even need to specify the path to the right mzscheme to run. ?You can > even call it `mz', making it even easier to start. > > [FWIW, this is exactly how I run mzscheme -- I have a script that > chooses a binary based on PLTHOME, and I have a convenient shell alias > to toggle between the released version and the nightly build, and in > the case of the released version in my home directory I have this > script choose the right binary because I'm using a single directory > with binaries for all platforms.] > > Look, the story with environment variables vs command-line flags is > esentially the same one as with keyword arguments vs parameters. > Parameters are more convenient in ways that make them lead to > potentially more mess, like forgetting that the code goes through some > dynamic context that changes it. ?In your patch for example, you fetch > the environment variable dynamically, which means that things can get > interesting with code that uses `putenv'. ?Fixing that wouldn't be > hard, and it would get a bit closer to just a command-line flag. > > Another problem with environment variables is that they get passed on > in strange ways. ?I've seen people hopelessly confused on Windows, > since changing the environment is done in an awkward way. ?I've also > seen cases where people had scripts that would set the variable > somewhere on the way, in a place that they didn't see, leading to very > confusing bugs where things are just not right no matter what you do. > It's like the usual problem with parameters being dynamic, with the > added fun bit of doing so cross-language (from shells to the process), > and/or weird places where you get to set your environment variables. > > This is why I'm saying that personally I like them -- I work in a way > that makes them very obvious (a traditional shell, basically). ?But > that's not true for probably somewhere around 95% of the users. ?(You > can see that in one of the many emails about PLTCOLLECTS -- it uses > the colon convention which just makes a lot of sense, and is used in > several places -- so I thought it would be much more known than it > turns out to be (=> roughly zero people knew about it).) > > >> I run into this problem every single day when I update my PLT trunk >> checkout. ?I either have to spend the duration of a complete build >> (including all documentation, installed planet packages, and recovery >> from any build errors) > > That goes back to the nightly build -- why not use it? ?It *is* > happenning every day, and the results are packaged in about 200 > different ways. ?(Yes, you still need planet, in case the version or > some interface changed, but most of the work is done if you use the > nightly build.) > >> unable to run any PLT Scheme code of any variety -- essentially >> unable to work -- [...] > > Or the least you can do if you really don't want to use the nightly > build is run it during the night in a cron job. > > > On Nov 20, Carl Eastlund wrote: >> On Fri, Nov 20, 2009 at 9:05 AM, Robby Findler >> wrote: >> > >> > Not to be contrarian, but pre-relase docs are probably close enough >> > usually, right? >> >> Unfortunately, the new docs invariably lack planet packages (both >> downloaded and development linked). ?I spend a lot of time >> programming with planet code, and looking up documentation for it, >> and without up-to-date local documentation I wind up having to go to >> planet.plt-scheme.org and lookup documentation by browsing specific >> versions of each package, without the benefit of Help Desk's search >> page. > > But that should be a much faster process to compile just these if you > use the nightly build. ?Or in almost all cases you should be fine with > the same build when the PLT version didn't change. Re: making a single variable as powerful as all three: the PLTADDONDIR I have already implemented already covers scribble and planet. You're probably right that it won't cover collects, but those aren't "add-ons" in the sense of files PLT Scheme installs automatically. It could probably cover the preferences file, but I'm not 100% sure that's either possible or desirable. Re: command line argument vs environment variable: You are right, it works either way. Since we already have environment variables to control this kind of thing, I went with another environment variable. I don't think having two things controlled via enviroment and one via command line is going to be somehow less confusing than having three environment variables. If, some day, we overhaul this configuration system, I have no problem with going to all command line arguments (or just one switch, as a command line argument). I agree that proliferating the number of controls (collects, planet, add-ons, scribble, partridges in pear trees) is not something we want to do ad nauseum. I also agree that environment variables are not always the best way to control things. I see two separate issues here. First, do we want to redesign our local configuration system, addressing issues of how directory trees are laid out, what options users have, and how users express choices. This will take careful design, time to implement, and a decision of how to deal with the fact that it will almost certainly break existing configurations. Second, since such a redesign will not happen soon and may not happen ever, what do we do for now? I am not proposing that PLTADDONDIR is anything other than a workaround patch. I think it is, however, a good workaround patch. It is already implemented, it does not break existing configurations, and as far as I can think of, no one should have to use both PLTADDONDIR and PLTPLANETDIR. Re: nightly build: This doesn't solve my problem, because nightly builds do not include planet packages, and a new nightly build will still clobber the local planet and scribble files of an older one with the same version. Furthermore, as a PLT developer, I want to have svn access to the trunk -- I do occasionally update or commit a checked out tree, rather than merely checkout / build / delete. --Carl From eli at barzilay.org Fri Nov 20 16:32:23 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri Nov 20 16:32:42 2009 Subject: [plt-dev] Re: Generated files and co-existing copies of DrScheme In-Reply-To: <990e0c030911201320q2dff6537t7330d0032792ec90@mail.gmail.com> References: <990e0c030911041344tfa68c40gf2b9e32c098f6c8c@mail.gmail.com> <990e0c030911171355g301a6543la9d7c16927ea32a3@mail.gmail.com> <19206.18194.888779.705087@winooski.ccs.neu.edu> <932b2f1f0911200605u775f06aue1f77de5743d4fd0@mail.gmail.com> <990e0c030911200535m6d320cadj246fd0f372b36046@mail.gmail.com> <990e0c030911200550o78020f64lb065f1f5746bb6b7@mail.gmail.com> <990e0c030911200614v2b157000ga9d2bc11f10df10c@mail.gmail.com> <19207.327.88666.63513@winooski.ccs.neu.edu> <990e0c030911201320q2dff6537t7330d0032792ec90@mail.gmail.com> Message-ID: <19207.2791.562323.268535@winooski.ccs.neu.edu> On Nov 20, Carl Eastlund wrote: > > Re: command line argument vs environment variable: > > You are right, it works either way. Since we already have > environment variables to control this kind of thing, I went with > another environment variable. I don't think having two things > controlled via enviroment and one via command line is going to be > somehow less confusing than having three environment variables. If, > some day, we overhaul this configuration system, I have no problem > with going to all command line arguments (or just one switch, as a > command line argument). The general good direction, IMO, is to avoid environment variables as much as possible. So if you want to add a new knob, doing that with a command line argument has better chances of being useful and of staying around. Do you have any *concrete* point for preferring an environment variable over a command-line argument? > First, do we want to redesign our local configuration system, > addressing issues of how directory trees are laid out, what options > users have, and how users express choices. This will take careful > design, time to implement, and a decision of how to deal with the > fact that it will almost certainly break existing configurations. This was mostly done, with the new command line arguments and with changes that happened in the past. PLTCOLLECTS might be more difficult to pull out, but I won't cry when this is done. > Re: nightly build: > > This doesn't solve my problem, because nightly builds do not include > planet packages, Of course, but I talked about building the PLT tree itself, which is a conserable chunk of work that you don't need to do. > and a new nightly build will still clobber the local planet and > scribble files of an older one with the same version. How? -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From cce at ccs.neu.edu Fri Nov 20 16:42:28 2009 From: cce at ccs.neu.edu (Carl Eastlund) Date: Fri Nov 20 16:43:05 2009 Subject: [plt-dev] Re: Generated files and co-existing copies of DrScheme In-Reply-To: <19207.2791.562323.268535@winooski.ccs.neu.edu> References: <990e0c030911041344tfa68c40gf2b9e32c098f6c8c@mail.gmail.com> <990e0c030911171355g301a6543la9d7c16927ea32a3@mail.gmail.com> <19206.18194.888779.705087@winooski.ccs.neu.edu> <932b2f1f0911200605u775f06aue1f77de5743d4fd0@mail.gmail.com> <990e0c030911200535m6d320cadj246fd0f372b36046@mail.gmail.com> <990e0c030911200550o78020f64lb065f1f5746bb6b7@mail.gmail.com> <990e0c030911200614v2b157000ga9d2bc11f10df10c@mail.gmail.com> <19207.327.88666.63513@winooski.ccs.neu.edu> <990e0c030911201320q2dff6537t7330d0032792ec90@mail.gmail.com> <19207.2791.562323.268535@winooski.ccs.neu.edu> Message-ID: <990e0c030911201342j4eb99ad9k7ebee747df92bfbb@mail.gmail.com> On Fri, Nov 20, 2009 at 4:32 PM, Eli Barzilay wrote: > On Nov 20, Carl Eastlund wrote: >> >> Re: command line argument vs environment variable: >> >> You are right, it works either way. ?Since we already have >> environment variables to control this kind of thing, I went with >> another environment variable. ?I don't think having two things >> controlled via enviroment and one via command line is going to be >> somehow less confusing than having three environment variables. ?If, >> some day, we overhaul this configuration system, I have no problem >> with going to all command line arguments (or just one switch, as a >> command line argument). > > The general good direction, IMO, is to avoid environment variables as > much as possible. ?So if you want to add a new knob, doing that with a > command line argument has better chances of being useful and of > staying around. ?Do you have any *concrete* point for preferring an > environment variable over a command-line argument? I am preferring consistency over inconsistency. Betamax was better than VHS, but once 90% of the world was VHS there was no sense in making Betamax any more. People are using our VHS options already, so why not give them more VHS, even if Betamax is better? That *was* my argument. I think my point that "users only have to use the old way or the new way, not both" undermines it. If users use *either* the PLTPLANETDIR environment variable *or* a command line option for add-on directories, it becomes easier to justify the inconsistency. However, since I am using the same kind of script as you for calling PLT executables -- the command line approach is only easy to use if we make sure every PLT executable can accept the same argument. Do we have a single point of control for that? Or will we have to edit several programs to make sure they accept this new option? >> First, do we want to redesign our local configuration system, >> addressing issues of how directory trees are laid out, what options >> users have, and how users express choices. ?This will take careful >> design, time to implement, and a decision of how to deal with the >> fact that it will almost certainly break existing configurations. > > This was mostly done, with the new command line arguments and with > changes that happened in the past. ?PLTCOLLECTS might be more > difficult to pull out, but I won't cry when this is done. What new command line arguments do we have for this? The only ones I see are for collections; I don't see any for planet, scribble, or preferences -- any of the Mz/DrScheme generated files. >> Re: nightly build: >> >> This doesn't solve my problem, because nightly builds do not include >> planet packages, > > Of course, but I talked about building the PLT tree itself, which is a > conserable chunk of work that you don't need to do. But that's the part that also doesn't clobber anything, and thus isn't a problem for me. >> and a new nightly build will still clobber the local planet and >> scribble files of an older one with the same version. > > How? How else would it work? Where will it put these things, other than right where the previous build did? --Carl From eli at barzilay.org Fri Nov 20 16:55:40 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri Nov 20 16:56:02 2009 Subject: [plt-dev] Re: Generated files and co-existing copies of DrScheme In-Reply-To: <990e0c030911201342j4eb99ad9k7ebee747df92bfbb@mail.gmail.com> References: <990e0c030911041344tfa68c40gf2b9e32c098f6c8c@mail.gmail.com> <990e0c030911171355g301a6543la9d7c16927ea32a3@mail.gmail.com> <19206.18194.888779.705087@winooski.ccs.neu.edu> <932b2f1f0911200605u775f06aue1f77de5743d4fd0@mail.gmail.com> <990e0c030911200535m6d320cadj246fd0f372b36046@mail.gmail.com> <990e0c030911200550o78020f64lb065f1f5746bb6b7@mail.gmail.com> <990e0c030911200614v2b157000ga9d2bc11f10df10c@mail.gmail.com> <19207.327.88666.63513@winooski.ccs.neu.edu> <990e0c030911201320q2dff6537t7330d0032792ec90@mail.gmail.com> <19207.2791.562323.268535@winooski.ccs.neu.edu> <990e0c030911201342j4eb99ad9k7ebee747df92bfbb@mail.gmail.com> Message-ID: <19207.4188.748990.912951@winooski.ccs.neu.edu> On Nov 20, Carl Eastlund wrote: > On Fri, Nov 20, 2009 at 4:32 PM, Eli Barzilay wrote: > > > > The general good direction, IMO, is to avoid environment variables > > as much as possible. ?So if you want to add a new knob, doing that > > with a command line argument has better chances of being useful > > and of staying around. ?Do you have any *concrete* point for > > preferring an environment variable over a command-line argument? > > I am preferring consistency over inconsistency. Right, and my point is that moving *consistently* to command-line flags is good. Otherwise, why would -X and -S get added in v4? > However, since I am using the same kind of script as you for calling > PLT executables -- the command line approach is only easy to use if > we make sure every PLT executable can accept the same argument. Do > we have a single point of control for that? If I had a use for such a flag, then I'd add it in my scripts. > > This was mostly done, with the new command line arguments and with > > changes that happened in the past. ?PLTCOLLECTS might be more > > difficult to pull out, but I won't cry when this is done. > > What new command line arguments do we have for this? `-S' and `-X'. And `-U', which is going to interact in a funny way with a PLTADDON option. > The only ones I see are for collections; I don't see any for planet, > scribble, or preferences -- any of the Mz/DrScheme generated files. I'm talking about adding these through a command line argument instead of an environment variable. If we had arguments for these, then there wouldn't be an issue to talk about? > >> and a new nightly build will still clobber the local planet and > >> scribble files of an older one with the same version. > > > > How? > > How else would it work? Where will it put these things, other than > right where the previous build did? It has only things from the PLT tree, it cannot clobber anything in your local directories. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From cce at ccs.neu.edu Fri Nov 20 17:08:29 2009 From: cce at ccs.neu.edu (Carl Eastlund) Date: Fri Nov 20 17:09:15 2009 Subject: [plt-dev] Re: Generated files and co-existing copies of DrScheme In-Reply-To: <19207.4188.748990.912951@winooski.ccs.neu.edu> References: <990e0c030911041344tfa68c40gf2b9e32c098f6c8c@mail.gmail.com> <932b2f1f0911200605u775f06aue1f77de5743d4fd0@mail.gmail.com> <990e0c030911200535m6d320cadj246fd0f372b36046@mail.gmail.com> <990e0c030911200550o78020f64lb065f1f5746bb6b7@mail.gmail.com> <990e0c030911200614v2b157000ga9d2bc11f10df10c@mail.gmail.com> <19207.327.88666.63513@winooski.ccs.neu.edu> <990e0c030911201320q2dff6537t7330d0032792ec90@mail.gmail.com> <19207.2791.562323.268535@winooski.ccs.neu.edu> <990e0c030911201342j4eb99ad9k7ebee747df92bfbb@mail.gmail.com> <19207.4188.748990.912951@winooski.ccs.neu.edu> Message-ID: <990e0c030911201408p39f6faa5u52c9eb02f977ec6c@mail.gmail.com> On Fri, Nov 20, 2009 at 4:55 PM, Eli Barzilay wrote: > > Right, and my point is that moving *consistently* to command-line > flags is good. ?Otherwise, why would -X and -S get added in v4? Sorry, I gotcha now. Yes, if PLTCOLLECTS has been supplanted by command line arguments, then PLTPLANETDIR and PLTADDONDIR should be too. >> >> and a new nightly build will still clobber the local planet and >> >> scribble files of an older one with the same version. >> > >> > How? >> >> How else would it work? ?Where will it put these things, other than >> right where the previous build did? > > It has only things from the PLT tree, it cannot clobber anything in > your local directories. The act of unpacking the nightly build will not do so, but the inevitable subsequent act of installing planet packages will. Thus I'm not sure what the nightly build will save me, in terms of allowing separate copies of PLT Scheme to coexist. --Carl From eli at barzilay.org Fri Nov 20 17:14:41 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri Nov 20 17:15:00 2009 Subject: [plt-dev] Re: Generated files and co-existing copies of DrScheme In-Reply-To: <990e0c030911201408p39f6faa5u52c9eb02f977ec6c@mail.gmail.com> References: <990e0c030911041344tfa68c40gf2b9e32c098f6c8c@mail.gmail.com> <932b2f1f0911200605u775f06aue1f77de5743d4fd0@mail.gmail.com> <990e0c030911200535m6d320cadj246fd0f372b36046@mail.gmail.com> <990e0c030911200550o78020f64lb065f1f5746bb6b7@mail.gmail.com> <990e0c030911200614v2b157000ga9d2bc11f10df10c@mail.gmail.com> <19207.327.88666.63513@winooski.ccs.neu.edu> <990e0c030911201320q2dff6537t7330d0032792ec90@mail.gmail.com> <19207.2791.562323.268535@winooski.ccs.neu.edu> <990e0c030911201342j4eb99ad9k7ebee747df92bfbb@mail.gmail.com> <19207.4188.748990.912951@winooski.ccs.neu.edu> <990e0c030911201408p39f6faa5u52c9eb02f977ec6c@mail.gmail.com> Message-ID: <19207.5329.559747.290194@winooski.ccs.neu.edu> On Nov 20, Carl Eastlund wrote: > >> >> and a new nightly build will still clobber the local planet and > >> >> scribble files of an older one with the same version. > >> > > >> > How? > >> > >> How else would it work? ?Where will it put these things, other > >> than right where the previous build did? > > > > It has only things from the PLT tree, it cannot clobber anything > > in your local directories. > > The act of unpacking the nightly build will not do so, but the > inevitable subsequent act of installing planet packages will. Thus > I'm not sure what the nightly build will save me, in terms of > allowing separate copies of PLT Scheme to coexist. Yes, you have to do the planet part yourself either way. (But I don't see how controlling the addons directory will help there.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From cce at ccs.neu.edu Fri Nov 20 17:30:29 2009 From: cce at ccs.neu.edu (Carl Eastlund) Date: Fri Nov 20 17:38:54 2009 Subject: [plt-dev] Re: Generated files and co-existing copies of DrScheme In-Reply-To: <19207.5329.559747.290194@winooski.ccs.neu.edu> References: <990e0c030911041344tfa68c40gf2b9e32c098f6c8c@mail.gmail.com> <990e0c030911200550o78020f64lb065f1f5746bb6b7@mail.gmail.com> <990e0c030911200614v2b157000ga9d2bc11f10df10c@mail.gmail.com> <19207.327.88666.63513@winooski.ccs.neu.edu> <990e0c030911201320q2dff6537t7330d0032792ec90@mail.gmail.com> <19207.2791.562323.268535@winooski.ccs.neu.edu> <990e0c030911201342j4eb99ad9k7ebee747df92bfbb@mail.gmail.com> <19207.4188.748990.912951@winooski.ccs.neu.edu> <990e0c030911201408p39f6faa5u52c9eb02f977ec6c@mail.gmail.com> <19207.5329.559747.290194@winooski.ccs.neu.edu> Message-ID: <990e0c030911201430w55fcb629oda579711dc087c2c@mail.gmail.com> On Fri, Nov 20, 2009 at 5:14 PM, Eli Barzilay wrote: >> >> The act of unpacking the nightly build will not do so, but the >> inevitable subsequent act of installing planet packages will. ?Thus >> I'm not sure what the nightly build will save me, in terms of >> allowing separate copies of PLT Scheme to coexist. > > Yes, you have to do the planet part yourself either way. ?(But I don't > see how controlling the addons directory will help there.) The same way it will help anywhere else. By directing one nightly build to install stuff in a different place than the other. Am I missing something obvious here about your point? Because you seem to be contradicting my original premise, without coming out and saying so. Re: command line versus environment, a quick test showed me that, for instance, mzscheme accepts -X but plt-help does not. So a "run PLT executables via script based on $PLTHOME" solution suddenly has to special case different options for each command. The nice thing about environment variables is that the same set works for every command; extra ones are ignored. --Carl From eli at barzilay.org Fri Nov 20 18:42:00 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri Nov 20 18:42:20 2009 Subject: [plt-dev] Re: Generated files and co-existing copies of DrScheme In-Reply-To: <990e0c030911201430w55fcb629oda579711dc087c2c@mail.gmail.com> References: <990e0c030911041344tfa68c40gf2b9e32c098f6c8c@mail.gmail.com> <990e0c030911200550o78020f64lb065f1f5746bb6b7@mail.gmail.com> <990e0c030911200614v2b157000ga9d2bc11f10df10c@mail.gmail.com> <19207.327.88666.63513@winooski.ccs.neu.edu> <990e0c030911201320q2dff6537t7330d0032792ec90@mail.gmail.com> <19207.2791.562323.268535@winooski.ccs.neu.edu> <990e0c030911201342j4eb99ad9k7ebee747df92bfbb@mail.gmail.com> <19207.4188.748990.912951@winooski.ccs.neu.edu> <990e0c030911201408p39f6faa5u52c9eb02f977ec6c@mail.gmail.com> <19207.5329.559747.290194@winooski.ccs.neu.edu> <990e0c030911201430w55fcb629oda579711dc087c2c@mail.gmail.com> Message-ID: <19207.10568.664002.585160@winooski.ccs.neu.edu> On Nov 20, Carl Eastlund wrote: > On Fri, Nov 20, 2009 at 5:14 PM, Eli Barzilay wrote: > >> > >> The act of unpacking the nightly build will not do so, but the > >> inevitable subsequent act of installing planet packages > >> will. ?Thus I'm not sure what the nightly build will save me, in > >> terms of allowing separate copies of PLT Scheme to coexist. > > > > Yes, you have to do the planet part yourself either way. ?(But I > > don't see how controlling the addons directory will help there.) > > The same way it will help anywhere else. My question is how -- what's this "same way"? > By directing one nightly build to install stuff in a different place > than the other. Am I missing something obvious here about your > point? Because you seem to be contradicting my original premise, > without coming out and saying so. I'm not making any point -- I might be missing something about either the problem or the suggested solution, and I just didn't ask about it so far. If you're still planning to run a build every day, then what is exactly the problem? My best guess is that you're trying to avoid the wait while a build is happening -- it's only a guess, but if this is the case then how about using the ultimate parameter: mkdir ~/plt-build HOME=~/plt-build ...build everything... move directories from ~/plt-build to where they usually live > Re: command line versus environment, a quick test showed me that, > for instance, mzscheme accepts -X but plt-help does not. So a "run > PLT executables via script based on $PLTHOME" solution suddenly has > to special case different options for each command. The nice thing > about environment variables is that the same set works for every > command; extra ones are ignored. You're right, that's a general problem that already exists with `-X' and the rest. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From mflatt at cs.utah.edu Sat Nov 21 12:04:13 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Sat Nov 21 12:04:34 2009 Subject: [plt-dev] Re: Generated files and co-existing copies of DrScheme In-Reply-To: <19207.327.88666.63513@winooski.ccs.neu.edu> References: <990e0c030911041344tfa68c40gf2b9e32c098f6c8c@mail.gmail.com> <990e0c030911171355g301a6543la9d7c16927ea32a3@mail.gmail.com> <19206.18194.888779.705087@winooski.ccs.neu.edu> <990e0c030911200535m6d320cadj246fd0f372b36046@mail.gmail.com> <990e0c030911200550o78020f64lb065f1f5746bb6b7@mail.gmail.com> <932b2f1f0911200605u775f06aue1f77de5743d4fd0@mail.gmail.com> <990e0c030911200614v2b157000ga9d2bc11f10df10c@mail.gmail.com> <19207.327.88666.63513@winooski.ccs.neu.edu> Message-ID: <20091121170415.4A48B6500C9@mail-svr1.cs.utah.edu> At Fri, 20 Nov 2009 15:51:19 -0500, Eli Barzilay wrote: > Look, the story with environment variables vs command-line flags is > esentially the same one as with keyword arguments vs parameters. I completely agree. But how does this lead you to the conclusion that environment variables are bad? At the Scheme level, we always prefer to use function arguments instead of parameters. But threading some configuration information everywhere (such as the current output port) is a huge pain. So we have parameters, and various functions accept an optional argument whose default value is drawn from a parameter. Similarly, the -X and -S arguments were not added to `mzscheme' because environment variables are an inherently bad idea. They were added because it's better to supply those configurations directly when practical. But the environment variables stayed, because it's not always practical to thread a command-line argument through a chain of scripts. > Another problem with environment variables is that they get passed on > in strange ways. I've seen people hopelessly confused on Windows, > since changing the environment is done in an awkward way. The same with parameters, but we'd have a hard time getting by without them. It looks to me like a PLTADDONDIR environment variable is appropriate, and `mzscheme' should also accept a command-line flag to override it. From eli at barzilay.org Sat Nov 21 14:05:59 2009 From: eli at barzilay.org (Eli Barzilay) Date: Sat Nov 21 14:06:21 2009 Subject: [plt-dev] Re: Generated files and co-existing copies of DrScheme In-Reply-To: <20091121170415.4A48B6500C9@mail-svr1.cs.utah.edu> References: <990e0c030911041344tfa68c40gf2b9e32c098f6c8c@mail.gmail.com> <990e0c030911171355g301a6543la9d7c16927ea32a3@mail.gmail.com> <19206.18194.888779.705087@winooski.ccs.neu.edu> <990e0c030911200535m6d320cadj246fd0f372b36046@mail.gmail.com> <990e0c030911200550o78020f64lb065f1f5746bb6b7@mail.gmail.com> <932b2f1f0911200605u775f06aue1f77de5743d4fd0@mail.gmail.com> <990e0c030911200614v2b157000ga9d2bc11f10df10c@mail.gmail.com> <19207.327.88666.63513@winooski.ccs.neu.edu> <20091121170415.4A48B6500C9@mail-svr1.cs.utah.edu> Message-ID: <19208.14871.570811.620135@winooski.ccs.neu.edu> On Nov 21, Matthew Flatt wrote: > At Fri, 20 Nov 2009 15:51:19 -0500, Eli Barzilay wrote: > > Look, the story with environment variables vs command-line flags > > is esentially the same one as with keyword arguments vs > > parameters. > > I completely agree. But how does this lead you to the conclusion > that environment variables are bad? There's no conclusion that they're automatically bad -- just that they should be avoided if possible. The problem with `plt-help' is an indication that an environment variable would be more convenient than to find a way to thread command-line flags through applications. Given this, having both a command-line flag and an environment variable is a good solution, and the fact that if both are specified then the flag should override the variable is a good indication that the variable lookup should happen once on startup rather than every time. BTW, the problem that I said already exists is not with `-X' and `-S', it's `-U' which is a problem in that plt-help doesn't accept it. But there's another potential problem: the addon-dir is used for code, which means that the two settings are dependent, so it would have been nice if there was a way to do them both in PLTCOLLECTS. Also, speaking about using environment variables -- how about another for the preference, and respecting HOME when set on Windows possible with some `expand-user-path*' that will work on Windows too? The latter two are especially annoying for writing cross-platform scripts, where I often need to edit code to use (getenv "HOME") for it to work on my (windows) laptop. > > Another problem with environment variables is that they get passed > > on in strange ways. I've seen people hopelessly confused on > > Windows, since changing the environment is done in an awkward way. > > The same with parameters, but we'd have a hard time getting by > without them. They're not the same -- parameters are in the scheme world, so they're uniform like all other code. But environment variables are set in very different ways and in different places. For example, at some point the debian distribution arranged for PLTCOLLECTS to be set in the default user environment (at least IIRC), on windows you have several ways to change them, and finally trying to control environment variables in deployed applications is very easy on unix/osx, and very difficult on Windows (which is what lead to the need for `path-up'). -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From eli at barzilay.org Sat Nov 21 21:29:01 2009 From: eli at barzilay.org (Eli Barzilay) Date: Sat Nov 21 21:29:22 2009 Subject: [plt-dev] Pre-Release Checklist for v4.2.3 Message-ID: Checklist items for the v4.2.3 release (using the v4.2.2.900 release candidate 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.3.1 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 ---------------------------------------------------------------------- * 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.3 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.3 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.3 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.3 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 - 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.2.2.900 build, you will need to edit your .../collects/framework/private/version.ss file and change `(version)' to `"4.2.3"'.] -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From eli at barzilay.org Sat Nov 21 23:16:34 2009 From: eli at barzilay.org (Eli Barzilay) Date: Sat Nov 21 23:16:54 2009 Subject: [plt-dev] Release Announcement for v4.2.3 Message-ID: Candidate release announcement items below. ---------------------------------------------------------------------- * added support for changing toolbar buttons based on the #lang line, use that for #lang scribble/base * 2htdp/universe stuff * Several new kinds of promises * added `path-up' to scheme/require * syntax/parse extensions (~var, ~literal, ~and, ~not, etc) * Adding check-member-of and check-range * change _pointer to mean a reference to non-GCed memory; add _gcpointer * New `scheme/vector' library. * scheme/unsafe/ops? (wasn't mentioned last time) * Add `in-port', `port->list', `file->list'. * upgrade Boehm GC to v7.1 ---------------------------------------------------------------------- -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From sperber at deinprogramm.de Sun Nov 22 04:56:54 2009 From: sperber at deinprogramm.de (Michael Sperber) Date: Sun Nov 22 04:57:13 2009 Subject: [plt-dev] Objections to removing class100? In-Reply-To: <26D22E06-7B53-4A6F-B001-51FF924DC296@ccs.neu.edu> (Stevie Strickland's message of "Fri, 20 Nov 2009 14:37:17 -0500") References: <26D22E06-7B53-4A6F-B001-51FF924DC296@ccs.neu.edu> Message-ID: Stevie Strickland writes: > We're interested in finally removing class100 from PLT Scheme. Are > there any objections? I'm a user, but not a heavy one. Is it significant work to keep it in? -- Cheers =8-} Mike Friede, V?lkerverst?ndigung und ?berhaupt blabla From robby at eecs.northwestern.edu Sun Nov 22 09:09:14 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Sun Nov 22 09:09:33 2009 Subject: [plt-dev] Release Announcement for v4.2.3 In-Reply-To: References: Message-ID: <932b2f1f0911220609n496e0112w21ad7cc701aa37a8@mail.gmail.com> On Sat, Nov 21, 2009 at 10:16 PM, Eli Barzilay wrote: > Candidate release announcement items below. > ---------------------------------------------------------------------- > * added support for changing toolbar buttons based on the #lang line, > ?use that for #lang scribble/base Maybe as the last bullet item. > * 2htdp/universe stuff Do you mean 2htdp/image? > * New `scheme/vector' library. Speaking of this, the commit I made recently to that file and the test suite are candidates for inclusion on the release branch (if Sam thinks it is okay). Robby From mflatt at cs.utah.edu Sun Nov 22 15:31:17 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Sun Nov 22 15:31:36 2009 Subject: [plt-dev] Pre-Release Checklist for v4.2.3 In-Reply-To: References: Message-ID: <20091122203119.3F780650119@mail-svr1.cs.utah.edu> At Sat, 21 Nov 2009 21:29:01 -0500, Eli Barzilay wrote: > * Matthew Flatt > - MzScheme Tests > - Languages Tests > - mzc Tests > - .plt-packing Tests > - Unit Tests > - Syntax Color Tests > - R6RS Tests Done. > - MrEd Tests (Also check that `mred -z' and `mred-text' still works > in Windows and Mac OS X) > - mzc --exe tests Failed. Need to re-run in next build. > - Games Tests There was a drawing problem with the Jewel game on Snow Leopard. This turns out to be an old problem (it effects older PLT versions), so my guess is that the symptom is specific to Snow Leopard. It may even be a Snow Leopard bug. I found and committed a workaround, in any case. > Updates: > - MzScheme Updates: update HISTORY > - MrEd Updates: update README, HISTORY > - Update man pages in plt/man/man1: mred.1, mzscheme.1 Done. From matthias at ccs.neu.edu Sun Nov 22 18:34:28 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Sun Nov 22 18:34:54 2009 Subject: [plt-dev] Objections to removing class100? In-Reply-To: References: <26D22E06-7B53-4A6F-B001-51FF924DC296@ccs.neu.edu> Message-ID: On Nov 22, 2009, at 4:56 AM, Michael Sperber wrote: > > Stevie Strickland writes: > >> We're interested in finally removing class100 from PLT Scheme. Are >> there any objections? > > I'm a user, but not a heavy one. Is it significant work to keep it in? We are in the process of introducing class contracts. These should include contracts for inits and init-fields. Our regular class system has a **strange** init behavior, which is only used in class100 to its full extent. Specifically, you can do things like (if (tuesday?) (super-new [x 10]) (super-new [y 'a])) and you can hide this expression in 'strange' places so that it is impossible to attach contracts -- Matthias From matthias at ccs.neu.edu Sun Nov 22 19:26:07 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Sun Nov 22 19:26:30 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.2.3 In-Reply-To: References: Message-ID: <95D33260-BA99-4879-BED2-92FF47774790@ccs.neu.edu> On Nov 21, 2009, at 9:29 PM, Eli Barzilay wrote: > * Matthias Felleisen Done. From ghcooper at gmail.com Sun Nov 22 21:12:17 2009 From: ghcooper at gmail.com (Gregory Cooper) Date: Sun Nov 22 21:12:36 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.2.3 In-Reply-To: References: Message-ID: <65e1d50c0911221812v7ce7bb3el6e66d437b5692208@mail.gmail.com> > > * Greg Cooper > - FrTime Tests > Done. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://list.cs.brown.edu/pipermail/plt-dev/attachments/20091122/1b774489/attachment.htm From sperber at deinprogramm.de Mon Nov 23 02:09:00 2009 From: sperber at deinprogramm.de (Michael Sperber) Date: Mon Nov 23 02:09:24 2009 Subject: [plt-dev] Objections to removing class100? In-Reply-To: (Matthias Felleisen's message of "Sun, 22 Nov 2009 18:34:28 -0500") References: <26D22E06-7B53-4A6F-B001-51FF924DC296@ccs.neu.edu> Message-ID: Matthias Felleisen writes: > On Nov 22, 2009, at 4:56 AM, Michael Sperber wrote: > >> >> Stevie Strickland writes: >> >>> We're interested in finally removing class100 from PLT Scheme. Are >>> there any objections? >> >> I'm a user, but not a heavy one. Is it significant work to keep it in? > > We are in the process of introducing class contracts. These > should include contracts for inits and init-fields. Our regular > class system has a **strange** init behavior, which is only used > in class100 to its full extent. Specifically, you can do things > like > > (if (tuesday?) (super-new [x 10]) (super-new [y 'a])) > > and you can hide this expression in 'strange' places so that > it is impossible to attach contracts You're saying that leaving class100 as-is (i.e. without contracts) is harder than zapping it, right? (I'm totally not interested in contracts for class100.) -- Cheers =8-} Mike Friede, V?lkerverst?ndigung und ?berhaupt blabla From sstrickl at ccs.neu.edu Mon Nov 23 02:31:39 2009 From: sstrickl at ccs.neu.edu (Stevie Strickland) Date: Mon Nov 23 02:32:44 2009 Subject: [plt-dev] Objections to removing class100? In-Reply-To: References: <26D22E06-7B53-4A6F-B001-51FF924DC296@ccs.neu.edu> Message-ID: <74A5B0F1-DA7B-42AC-A61F-FDC0DA2CEB91@ccs.neu.edu> On Nov 23, 2009, at 2:09 AM, Michael Sperber wrote: > You're saying that leaving class100 as-is (i.e. without contracts) is > harder than zapping it, right? (I'm totally not interested in > contracts > for class100.) Right. The class100 forms rewrites into uses of class* from scheme/ class, and some of the changes needed would also require extending the class100 forms, which means they'd no longer be strictly the same interface as the old PLT class system. Thus, this seemed like an ideal time to just remove the deprecated interface, since there is no reason of which I'm aware that classes written using mzlib/class100 cannot be straightforwardly ported to scheme/class. If this does happen, it won't be until either late December or after the new year. Also, I'd be more than happy to write up my experiences in porting uses of class100 and friends in the PLT Scheme code base to scheme/class as a porting guide if that would make the removal more acceptable. Stevie