From mflatt at cs.utah.edu Mon Jun 1 09:05:05 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Mon Jun 1 09:05:30 2009 Subject: [plt-dev] Release Announcement for v4.2, second call In-Reply-To: <18973.6539.154735.223370@winooski.ccs.neu.edu> References: <18973.6539.154735.223370@winooski.ccs.neu.edu> Message-ID: <20090601130507.4AFED6500D7@mail-svr1.cs.utah.edu> I left the web-server bullet alone, since you have new text from Jay, but here's a suggestion for the rest. ---------------------------------------- PLT Scheme version 4.2 is now available from http://plt-scheme.org/ Internally, this version includes a conversion from C++ to Scheme for part of the GUI toolbox --- specifically, 25k lines of code that implement the general text and pasteboard editor. This conversion is a start on a larger reimplementation of the GUI toolbox. Although we believe that this change will help make PLT Scheme better in the long run, we must expect bugs in the short term due to porting errors. Users should therefore be aware of the change, even though the new implementation is meant to behave the same as previous versions. * A new statistical profiler is now available; see the "profiler" manual for more information. Currently, the profiler supports only textual output, but future plans include a GUI interface and DrScheme integration. * The `world' teachpack is now deprecated. Its replacement `universe' has a new interface that uses strings instead of symbols and characters. * Web-server: Native continuations in serial language, soft state, and typos. * DrScheme's Stepper can now jump to a selected program expression. * New in `scheme/base': `hash-has-key?', `hash-ref!', `in-sequences', `in-cycle'. New in `scheme': `count', `make-list' (from `scheme/list'), `const' (from `scheme/function'). * Some performance improvements, including faster start-up for small programs. The latter is a result of delaying module invocations at higher phases (compile time, meta-compile time, etc.) until compilation is demanded at the next lower phase; this on-demand instantiation is per-phase, as opposed to per-module within a phase. From mflatt at cs.utah.edu Mon Jun 1 09:50:06 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Mon Jun 1 09:50:40 2009 Subject: [plt-dev] documentation slowing down installs and builds dramatically In-Reply-To: <4A220443.9050107@neilvandyke.org> References: <4A208F6A.1000405@neilvandyke.org> <36366a980905291847j60b7334ch20a8cf291fba14b3@mail.gmail.com> <4A220443.9050107@neilvandyke.org> Message-ID: <20090601135008.896786500CF@mail-svr1.cs.utah.edu> I haven't investigated, but I have a guess. When a planet package A depends on another planet package B, then trying to compile A triggers an install of B. As the docs for B build, the search and master index are re-built, and that's where the time goes. Then the build of A continues, and again the search and master index are rebuilt. If you end up installing N packages, then the search and master index are built N times, which would take a while if N is big enough. Maybe someone who knows planet better can say that it doesn't work that way? Or maybe someone has observed enough about the build to say that the time isn't spent just in re-building the index and search? At Sun, 31 May 2009 00:14:59 -0400, Neil Van Dyke wrote: > I have a fresh anecdote of practical impact of the slow documentation > crunching. > > The first bit of code I try to run from the Snooze tutorial takes over 9 > minutes on a fast computer, before it attempts to connect to the database. > > It installs a lot of small PLaneT packages in these 9+ minutes, and > seems to spend most of that time crunching documentation. > > (That's with reasonably fast Internet, PLTCOLLECTS unset, DrScheme > memory limit off, lots of RAM, and no swap space in use, otherwise idle > 2GHz dual-core, on Linux.) > > -- > http://www.neilvandyke.org/ > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From robby at eecs.northwestern.edu Mon Jun 1 09:58:46 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Mon Jun 1 09:59:08 2009 Subject: [plt-dev] documentation slowing down installs and builds dramatically In-Reply-To: <20090601135008.896786500CF@mail-svr1.cs.utah.edu> References: <4A208F6A.1000405@neilvandyke.org> <36366a980905291847j60b7334ch20a8cf291fba14b3@mail.gmail.com> <4A220443.9050107@neilvandyke.org> <20090601135008.896786500CF@mail-svr1.cs.utah.edu> Message-ID: <932b2f1f0906010658t77653a0fw5f94bf8ee722d6cf@mail.gmail.com> I think PLaneT does indeed work that way. Even worse, there is a bug somewhere that causes CM to not compile package B (or C or D ...) making things even worse. I got as far as figuring out that it was a parameter that changed (I think it was the namespace?) that somehow causes CM to disable itself, but I could not figure out what the right fix was. I believe the right fix is to be using a new instantiation of CM and the code seems to be doing that, but apparently it isn't. (I should probably go try again to fix that. I got lost somewhere inside setup-plt last time I tried.) Robby On Mon, Jun 1, 2009 at 8:50 AM, Matthew Flatt wrote: > I haven't investigated, but I have a guess. When a planet package A > depends on another planet package B, then trying to compile A triggers > an install of B. As the docs for B build, the search and master index > are re-built, and that's where the time goes. Then the build of A > continues, and again the search and master index are rebuilt. If you > end up installing N packages, then the search and master index are > built N times, which would take a while if N is big enough. > > Maybe someone who knows planet better can say that it doesn't work that > way? Or maybe someone has observed enough about the build to say that > the time isn't spent just in re-building the index and search? > > At Sun, 31 May 2009 00:14:59 -0400, Neil Van Dyke wrote: >> I have a fresh anecdote of practical impact of the slow documentation >> crunching. >> >> The first bit of code I try to run from the Snooze tutorial takes over 9 >> minutes on a fast computer, before it attempts to connect to the database. >> >> It installs a lot of small PLaneT packages in these 9+ minutes, and >> seems to spend most of that time crunching documentation. >> >> (That's with reasonably fast Internet, PLTCOLLECTS unset, DrScheme >> memory limit off, lots of RAM, and no swap space in use, otherwise idle >> 2GHz dual-core, on Linux.) >> >> -- >> http://www.neilvandyke.org/ >> _________________________________________________ >> ? For list-related administrative tasks: >> ? http://list.cs.brown.edu/mailman/listinfo/plt-dev > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > From eli at barzilay.org Mon Jun 1 10:07:05 2009 From: eli at barzilay.org (Eli Barzilay) Date: Mon Jun 1 10:07:26 2009 Subject: [plt-dev] Release Announcement for v4.2 -- final version, hopefully Message-ID: The final announcement that I have now is below. ---------------------------------------------------------------------- PLT Scheme version 4.2 is now available from http://plt-scheme.org/ Internally, this version includes a conversion from C++ to Scheme for part of the GUI toolbox --- specifically, 25k lines of code that implement the general text and pasteboard editor. This conversion is a start on a larger reimplementation of the GUI toolbox. Although we believe that this change will help make PLT Scheme better in the long run, we must expect bugs in the short term due to porting errors. Users should therefore be aware of the change, even though the new implementation is meant to behave the same as previous versions. * A new statistical profiler is now available; see the "profiler" manual for more information. Currently, the profiler supports only textual output, but future plans include a GUI interface and DrScheme integration. * The `world' teachpack is now deprecated. Its replacement `universe' has a new interface that uses strings instead of symbols and characters. * Web-server: Native continuations in the stateless servlet language support capturing continuations from untransformed contexts; soft state library for stateless servlets. * DrScheme's Stepper can now jump to a selected program expression. * New in `scheme/base': `hash-has-key?', `hash-ref!', `in-sequences', `in-cycle'. New in `scheme': `count', `make-list' (from `scheme/list'), `const' (from `scheme/function'). * Some performance improvements, including faster start-up for small programs. The latter is a result of delaying module invocations at higher phases (compile time, meta-compile time, etc.) until compilation is demanded at the next lower phase; this on-demand instantiation is per-phase, as opposed to per-module within a phase. [Note that mirror sites can take a while to catch up with the new downloads.] Feedback Welcome, ---------------------------------------------------------------------- -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From noelwelsh at gmail.com Mon Jun 1 10:16:31 2009 From: noelwelsh at gmail.com (Noel Welsh) Date: Mon Jun 1 10:17:11 2009 Subject: [plt-dev] Accessing other's usr repository; SQLite package broken Message-ID: Hi all, In 4.2 the sqlite.plt package is broken: > (require (planet untyped/snooze:2:6)) sqlite.ss:12:3: compile: unbound identifier in module in: ptr-ref It looks like something has changed in the FFI to make ptr-ref an unsafe function (which indeed it should be). The fix is trivial. I notice I have permission to access Jay's repo where sqlite is stored, but when I try to check it out I get: > svn co http://svn.plt-scheme.org/usr/jay/sqlite sqlite svn: Server sent unexpected return value (403 Forbidden) in response to PROPFIND request for '/usr/jay' How does one go about this? Thanks, N. From eli at barzilay.org Mon Jun 1 10:22:50 2009 From: eli at barzilay.org (Eli Barzilay) Date: Mon Jun 1 10:23:11 2009 Subject: [plt-dev] Accessing other's usr repository; SQLite package broken In-Reply-To: References: Message-ID: <18979.58426.341107.385207@winooski.ccs.neu.edu> On Jun 1, Noel Welsh wrote: > > I notice I have permission to access Jay's repo where sqlite is > stored, but when I try to check it out I get: > > > svn co http://svn.plt-scheme.org/usr/jay/sqlite sqlite > svn: Server sent unexpected return value (403 Forbidden) in response > to PROPFIND request for '/usr/jay' > > How does one go about this? This might be related to the subversion bug that has been there for a while now, and has finally received some attention recently. Or it might work right if jay adds read access for you to his root. (But I'm not sure why your client would need to read `/usr/jay', so it might still be that bug.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From jay.mccarthy at gmail.com Mon Jun 1 11:24:16 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Mon Jun 1 11:31:57 2009 Subject: [plt-dev] Accessing other's usr repository; SQLite package broken In-Reply-To: <18979.58426.341107.385207@winooski.ccs.neu.edu> References: <18979.58426.341107.385207@winooski.ccs.neu.edu> Message-ID: I actually moved the sqlite repository to a different place with all my other planet packages. That probably explains the SVN error. As far as the error in the package... if you update to the latest version I don't even use ptr-ref any more, so that error doesn't show up and my test suite passes from SVN. Jay On Mon, Jun 1, 2009 at 8:22 AM, Eli Barzilay wrote: > On Jun ?1, Noel Welsh wrote: >> >> I notice I have permission to access Jay's repo where sqlite is >> stored, but when I try to check it out I get: >> >> > svn co http://svn.plt-scheme.org/usr/jay/sqlite sqlite >> svn: Server sent unexpected return value (403 Forbidden) in response >> to PROPFIND request for '/usr/jay' >> >> How does one go about this? > > This might be related to the subversion bug that has been there for a > while now, and has finally received some attention recently. > > Or it might work right if jay adds read access for you to his root. > (But I'm not sure why your client would need to read `/usr/jay', so it > might still be that bug.) > > -- > ? ? ? ? ?((lambda (x) (x x)) (lambda (x) (x x))) ? ? ? ? ?Eli Barzilay: > ? ? ? ? ? ? ? ? ?http://www.barzilay.org/ ? ? ? ? ? ? ? ? Maze is Life! > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From cobbe at ccs.neu.edu Tue Jun 2 08:41:48 2009 From: cobbe at ccs.neu.edu (Richard Cobbe) Date: Tue Jun 2 08:42:07 2009 Subject: [plt-dev] What happened to configure --prefix on MacOS? Message-ID: <20090602124148.GB615@perdita.local> Forgive me if this has been discussed elsewhere, but I've been extremely busy of late and haven't really been reading the PLT lists. I just did an "svn up" followed by "mkdir build; cd build; ../src/configure --prefix=$HOME/Applications/plt", only to learn that configure no longer supports --prefix on OS X. What's going on here? How do I do a non-in-place build? (I see no reason to keep the .o files and other artifacts of compilation around between builds, especially since I 'svn up' so infrequently that I always get changes to the .c files, which according to Matthew requires creating a new build directory.) Richard From mflatt at cs.utah.edu Tue Jun 2 08:46:09 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Tue Jun 2 08:46:30 2009 Subject: [plt-dev] What happened to configure --prefix on MacOS? In-Reply-To: <20090602124148.GB615@perdita.local> References: <20090602124148.GB615@perdita.local> Message-ID: <20090602124611.0C4DE65010D@mail-svr1.cs.utah.edu> At Tue, 2 Jun 2009 08:41:48 -0400, Richard Cobbe wrote: > Forgive me if this has been discussed elsewhere, but I've been extremely > busy of late and haven't really been reading the PLT lists. > > I just did an "svn up" followed by "mkdir build; cd build; ../src/configure > --prefix=$HOME/Applications/plt", only to learn that configure no longer > supports --prefix on OS X. > > What's going on here? How do I do a non-in-place build? You should have received the following error message: ERROR: --prefix not allowed for a Mac OS X build, unless either --enable-xonx is supplied (to create a Unix-style build), or --enable-macprefix is supplied (to allow a Mac-style installation, even though --prefix is normally used for Unix-style installations) So, you want `--enable-macprefix'. We disabled `--prefix' by default on Mac OS X, because it doesn't quite produce the layout that a Unix user would expect. The `--enable-macprefix' flag lets you use `--prefix' anyway. From cobbe at ccs.neu.edu Tue Jun 2 09:21:09 2009 From: cobbe at ccs.neu.edu (Richard Cobbe) Date: Tue Jun 2 09:21:31 2009 Subject: [plt-dev] What happened to configure --prefix on MacOS? In-Reply-To: <20090602124611.0C4DE65010D@mail-svr1.cs.utah.edu> References: <20090602124148.GB615@perdita.local> <20090602124611.0C4DE65010D@mail-svr1.cs.utah.edu> Message-ID: <20090602132109.GA5725@perdita.local> On Tue, Jun 02, 2009 at 06:46:09AM -0600, Matthew Flatt wrote: > At Tue, 2 Jun 2009 08:41:48 -0400, Richard Cobbe wrote: > > Forgive me if this has been discussed elsewhere, but I've been extremely > > busy of late and haven't really been reading the PLT lists. > > > > I just did an "svn up" followed by "mkdir build; cd build; ../src/configure > > --prefix=$HOME/Applications/plt", only to learn that configure no longer > > supports --prefix on OS X. > > > > What's going on here? How do I do a non-in-place build? > > You should have received the following error message: > > ERROR: --prefix not allowed for a Mac OS X build, unless either > --enable-xonx is supplied (to create a Unix-style > build), or > --enable-macprefix is supplied (to allow a Mac-style > installation, even though --prefix is normally used > for Unix-style installations) > > So, you want `--enable-macprefix'. > > We disabled `--prefix' by default on Mac OS X, because it doesn't quite > produce the layout that a Unix user would expect. The `--enable-macprefix' > flag lets you use `--prefix' anyway. Ah, I see. I did indeed get that error message, but I didn't realize that --enable-macprefix would get me what I wanted -- partly because I read the error message too quickly, and partly because I was (and am) not entirely clear on what "Mac-style installation" means. I'll give that a shot. Thanks! Richard From eli at barzilay.org Tue Jun 2 09:25:13 2009 From: eli at barzilay.org (Eli Barzilay) Date: Tue Jun 2 09:25:34 2009 Subject: [plt-dev] What happened to configure --prefix on MacOS? In-Reply-To: <20090602132109.GA5725@perdita.local> References: <20090602124148.GB615@perdita.local> <20090602124611.0C4DE65010D@mail-svr1.cs.utah.edu> <20090602132109.GA5725@perdita.local> Message-ID: <18981.10297.715862.507376@winooski.ccs.neu.edu> On Jun 2, Richard Cobbe wrote: > > Ah, I see. I did indeed get that error message, but I didn't > realize that --enable-macprefix would get me what I wanted -- partly > because I read the error message too quickly, and partly because I > was (and am) not entirely clear on what "Mac-style installation" > means. The thing that triggered this (very recent), was doing ./configure --prefix=/usr which does something very different -- and very broken on OSX (and IIRC, the mac ports thing had this problem for a long time, without anyone noticing). -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From eli at barzilay.org Tue Jun 2 14:52:00 2009 From: eli at barzilay.org (Eli Barzilay) Date: Tue Jun 2 14:52:21 2009 Subject: [plt-dev] Module browser change Message-ID: <18981.29904.4219.707719@winooski.ccs.neu.edu> I have committed a change to the module browser: requires for a file that is local to the same "library" are always shown, even if the require is using a symbolic name or (planet ...). This means that if you're working on a plt collection and open the module browser, you'll see your library's files even if you choose to hide lib requires, and the same for planet. (For now, the concept of what directory is considered a library is currently hard-wired as a subdirectory of one of the collection roots, or four levels down from the planet cache.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From eli at barzilay.org Tue Jun 2 15:30:49 2009 From: eli at barzilay.org (Eli Barzilay) Date: Tue Jun 2 15:31:10 2009 Subject: [plt-dev] full-4.2.0.2 May 27 problem In-Reply-To: <4A22522C.5040707@cs.utah.edu> References: <4A22522C.5040707@cs.utah.edu> Message-ID: <18981.32233.84236.395703@winooski.ccs.neu.edu> On May 31, Chongkai Zhu wrote: > I got the same problem for plt-4.2.0.2-bin-i386-win32, and solve it > by copy the whole plt directory into "C:\var\tmp\plt\" This is fixed in today's build. (Just in case anyone did such a hack to avoid the problem.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From jay.mccarthy at gmail.com Tue Jun 2 22:49:20 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Tue Jun 2 22:49:40 2009 Subject: [plt-dev] struct match-expander a la struct-copy Message-ID: The structure patterns in scheme/match have always bugged me that they didn't let you put the fields in any order and you had to put in _ for the fields you didn't care about. I've remedied this with a new match expander, struct*. I'd like to put in the tree. Do people agree? -- Use cases -- (define-struct super-tree (left right extra)) (define example1 (make-super-tree 1 2 "And a pony!")) (match example1 [(struct* super-tree ([left (? number? l)] [right (? number? r)])) (printf "All numbers! ~a ~a~n" l r)]) (match example1 [(struct* super-tree ([right (? number? r)] [left (? number? l)])) (printf "Look ma, any order! ~a ~a~n" l r)]) (define-struct (even-better-tree super-tree) (more-extra-good)) (define example2 (make-even-better-tree 1 2 "And a pony!" "And a giraffe!")) (match example2 [(struct* super-tree ([left (? number? l)] [right (? number? r)])) (printf "All numbers! ~a ~a~n" l r)]) (match example2 [(struct* even-better-tree ([more-extra-good (? string? m)])) (printf "~a~n" m)]) -- Code & Test Cases -- #lang scheme (require (for-syntax scheme/struct-info syntax/boundmap scheme/list)) (define-match-expander struct* (lambda (stx) (syntax-case stx () [(_ struct-name (field+pat ...)) (let* ([fail (lambda () (raise-syntax-error 'struct* "not a structure definition" stx #'struct-name))] [v (syntax-local-value #'struct-name fail)] [field-acc->pattern (make-free-identifier-mapping)]) (unless (struct-info? v) (fail)) ; Check each pattern and capture the field-accessor name (for-each (lambda (an) (syntax-case an () [(field pat) (unless (identifier? #'field) (raise-syntax-error 'struct* "not an identifier for field name" stx #'field)) (let ([field-acc (datum->syntax #'field (string->symbol (format "~a-~a" (syntax-e #'struct-name) (syntax-e #'field))) #'field)]) (when (free-identifier-mapping-get field-acc->pattern field-acc (lambda () #f)) (raise-syntax-error 'struct* "Field name appears twice" stx #'field)) (free-identifier-mapping-put! field-acc->pattern field-acc #'pat))] [_ (raise-syntax-error 'struct* "expected a field pattern of the form ( )" stx an)])) (syntax->list #'(field+pat ...))) (let* (; Get the structure info [acc (fourth (extract-struct-info v))] ;; the accessors come in reverse order [acc (reverse acc)] ;; remove the first element, if it's #f [acc (cond [(empty? acc) acc] [(not (first acc)) (rest acc)] [else acc])] ; Order the patterns in the order of the accessors [pats-in-order (for/list ([field-acc (in-list acc)]) (begin0 (free-identifier-mapping-get field-acc->pattern field-acc (lambda () (syntax/loc stx _))) ; Use up pattern (free-identifier-mapping-put! field-acc->pattern field-acc #f)))]) ; Check that all patterns were used (free-identifier-mapping-for-each field-acc->pattern (lambda (field-acc pat) (when pat (raise-syntax-error 'struct* "field name not associated with given structure type" stx field-acc)))) (quasisyntax/loc stx (struct struct-name #,pats-in-order))))]))) ; Comment out to test syntax errors ; Bad struct info id #;(match example1 [(struct* some-tree ([left (? number? l)] [right (? number? r)])) (printf "Just the facts: ~a ~a~n" l r)]) ; Bad struct info (define-for-syntax uncool-tree #f) #;(match example1 [(struct* uncool-tree ([left (? number? l)] [right (? number? r)])) (printf "Just the facts: ~a ~a~n" l r)]) ; Bad syntax form #;(match example1 [(struct* super-tree ([foo] [right (? number? r)])) (printf "Just the facts: ~a ~a~n" l r)]) ; Not an id for field #;(match example1 [(struct* super-tree ([(+ 1 1) (? number? l)] [right (? number? r)])) (printf "Just the facts: ~a ~a~n" l r)]) ; Field appears twice #;(match example1 [(struct* super-tree ([right _] [right (? number? r)])) (printf "Just the facts: ~a~n" r)]) ; Not a field id #;(match example1 [(struct* super-tree ([feet (? number?)] [right (? number? r)])) (printf "Just the facts: ~a~n" r)]) ; Super structs don't work #;(match example2 [(struct* even-better-tree ([left (? number? l)] [right (? number? r)] [more-extra-good (? string? s)])) (printf "All numbers (+ 1 string)! ~a ~a ~a~n" l r s)]) ; Super structs don't work #;(match example2 [(struct* even-better-tree ([left (? number? l)] [extra (? string? e)] [right (? number? r)] [more-extra-good (? string? m)])) (printf "All numbers (+ 2 strings)! ~a ~a ~a ~a~n" l e r m)]) -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From jos.koot at telefonica.net Wed Jun 3 04:11:30 2009 From: jos.koot at telefonica.net (Jos Koot) Date: Wed Jun 3 04:12:35 2009 Subject: [plt-dev] full-4.2.0.2 May 27 problem References: <4A22522C.5040707@cs.utah.edu> <18981.32233.84236.395703@winooski.ccs.neu.edu> Message-ID: <77C27FCEC3D94674AD93A26D0C8898BE@uw2b2dff239c4d> Thanks, Jos ----- Original Message ----- From: "Eli Barzilay" To: "Chongkai Zhu" Cc: "Jos Koot" ; Sent: Tuesday, June 02, 2009 9:30 PM Subject: Re: [plt-dev] full-4.2.0.2 May 27 problem > On May 31, Chongkai Zhu wrote: >> I got the same problem for plt-4.2.0.2-bin-i386-win32, and solve it >> by copy the whole plt directory into "C:\var\tmp\plt\" > > This is fixed in today's build. (Just in case anyone did such a hack > to avoid the problem.) > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > http://www.barzilay.org/ Maze is Life! > From cobbe at ccs.neu.edu Wed Jun 3 06:28:30 2009 From: cobbe at ccs.neu.edu (Richard Cobbe) Date: Wed Jun 3 06:28:52 2009 Subject: [plt-dev] struct match-expander a la struct-copy In-Reply-To: References: Message-ID: <20090603102829.GA615@perdita.local> On Tue, Jun 02, 2009 at 08:49:20PM -0600, Jay McCarthy wrote: > The structure patterns in scheme/match have always bugged me that they > didn't let you put the fields in any order and you had to put in _ for > the fields you didn't care about. > > I've remedied this with a new match expander, struct*. I'd like to put > in the tree. Do people agree? Looks great to me; the problems with the built-in struct patterns have long annoyed me. My views.plt package on Planet addresses some of the same problems that you've identified, but the overlap isn't complete. Views also handle abstract data types, and they're by-position instead of by-name. Indeed, when I get a chance, it would be interesting to add the by-name matching to views along side the existing by-position system. Richard From noelwelsh at gmail.com Wed Jun 3 06:32:19 2009 From: noelwelsh at gmail.com (Noel Welsh) Date: Wed Jun 3 06:32:39 2009 Subject: [plt-dev] struct match-expander a la struct-copy In-Reply-To: References: Message-ID: On Wed, Jun 3, 2009 at 3:49 AM, Jay McCarthy wrote: > The structure patterns in scheme/match have always bugged me that they > didn't let you put the fields in any order and you had to put in _ for > the fields you didn't care about. It would be nice to be able to use the field name as a pattern, which I don't think your system does. So I could write: (define-struct foo (left right)) (match (make-foo 'a 'b) [(struct* foo (right left)) (cons right left)]) N. From eli at barzilay.org Wed Jun 3 06:58:01 2009 From: eli at barzilay.org (Eli Barzilay) Date: Wed Jun 3 06:58:21 2009 Subject: [plt-dev] struct match-expander a la struct-copy In-Reply-To: References: Message-ID: <18982.22329.172409.834089@winooski.ccs.neu.edu> On Jun 2, Jay McCarthy wrote: > The structure patterns in scheme/match have always bugged me that > they didn't let you put the fields in any order and you had to put > in _ for the fields you didn't care about. > > I've remedied this with a new match expander, struct*. I'd like to > put in the tree. Do people agree? But the problem with that is that it's even farther away from the syntax to create an instance. Ideally, I'd like to see options to `define-struct' that can get you a keyword-based constructor instead or in addition to the positional one. ("In addition too" is a better option, re the thread on renaming a constructor -- since you'll be able to specify the name of each constructor.) Then define whatever constructor was made as a match pattern too. Something like: (define-struct foo (x y) #:positional-constructor make-foo1 #:keyworded-cosntrutor make-foo2) (match ... [(make-foo1 x y) ...] ;; or [(make-foo2 #:x x #:y y) ...]) (But I'm not sure about the syntax to define this constructor, it might be better to follow the syntax for functions: (define-struct foo (#:x x #:y y)) perhaps even use that to specify defaults. But there are cases where you want both the positional and the keyworded versions...) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From d.j.gurnell at gmail.com Wed Jun 3 10:05:51 2009 From: d.j.gurnell at gmail.com (Dave Gurnell) Date: Wed Jun 3 10:06:30 2009 Subject: [plt-dev] struct match-expander a la struct-copy In-Reply-To: <18982.22329.172409.834089@winooski.ccs.neu.edu> References: <18982.22329.172409.834089@winooski.ccs.neu.edu> Message-ID: > (define-struct foo (x y) > #:positional-constructor make-foo1 > #:keyworded-cosntrutor make-foo2) +1 The #:positional-constructor option would be really useful for another purpose: I sometimes find myself creating custom constructors for structs and providing them under contracts. I currently have to do it in two modules to get the right names: foo-internal.ss #lang scheme (define-struct foo (...)) (define (create-foo ...) ...) (provide/contract [struct foo ...] [create-foo ...])) foo.ss #lang scheme (require "foo-internal.ss") (provide (except-out (struct-out foo) make-foo) (rename-out [create-foo make-foo])) This addition would allow me to define a struct with "make-foo/ internal" (or something) as its uncontracted constructor name and define make-foo directly without the renaming shenanigans. -- Dave From pocmatos at gmail.com Wed Jun 3 11:12:04 2009 From: pocmatos at gmail.com (Paulo J. Matos) Date: Wed Jun 3 11:12:45 2009 Subject: [plt-dev] struct match-expander a la struct-copy In-Reply-To: References: Message-ID: <11b141710906030812l2b38f0ecjbab6dc6c58fe1cce@mail.gmail.com> On Wed, Jun 3, 2009 at 3:49 AM, Jay McCarthy wrote: > The structure patterns in scheme/match have always bugged me that they > didn't let you put the fields in any order and you had to put in _ for > the fields you didn't care about. > > I've remedied this with a new match expander, struct*. I'd like to put > in the tree. Do people agree? > I could definitely use something like this. It would definitely be extremely useful. +1 vote for it! -- Paulo Jorge Matos - pocmatos at gmail.com http://www.pmatos.net From grettke at acm.org Wed Jun 3 12:34:48 2009 From: grettke at acm.org (Grant Rettke) Date: Wed Jun 3 12:41:37 2009 Subject: [plt-dev] struct match-expander a la struct-copy In-Reply-To: References: Message-ID: <756daca50906030934x6e3fea53jadc2ce50d4b867f5@mail.gmail.com> On Tue, Jun 2, 2009 at 9:49 PM, Jay McCarthy wrote: > I've remedied this with a new match expander, struct*. I'd like to put > in the tree. Do people agree? That looks good! From clements at brinckerhoff.org Wed Jun 3 12:55:40 2009 From: clements at brinckerhoff.org (John Clements) Date: Wed Jun 3 12:56:04 2009 Subject: [plt-dev] struct match-expander a la struct-copy In-Reply-To: <11b141710906030812l2b38f0ecjbab6dc6c58fe1cce@mail.gmail.com> References: <11b141710906030812l2b38f0ecjbab6dc6c58fe1cce@mail.gmail.com> Message-ID: On Jun 3, 2009, at 8:12 AM, Paulo J. Matos wrote: > On Wed, Jun 3, 2009 at 3:49 AM, Jay McCarthy > wrote: >> The structure patterns in scheme/match have always bugged me that >> they >> didn't let you put the fields in any order and you had to put in _ >> for >> the fields you didn't care about. IIUC, the proposal would allow you to leave out fields without a warning. This strikes me as potentially dangerous, especially if this stuff is used in the teaching languages. I actually recall some discussion of this on the OCaml list (OCaml behaves in this way, IIUC), and some were suggesting that a slightly different form be required for an incomplete match. 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/20090603/7c09ae1b/smime.bin From jay.mccarthy at gmail.com Wed Jun 3 12:58:57 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Wed Jun 3 12:59:19 2009 Subject: [plt-dev] struct match-expander a la struct-copy In-Reply-To: References: <11b141710906030812l2b38f0ecjbab6dc6c58fe1cce@mail.gmail.com> Message-ID: Just to clarify, I don't think this should replace the existing struct form, but I think it is useful and wanted enough to warrant being included in scheme/match Jay On Wed, Jun 3, 2009 at 10:55 AM, John Clements wrote: > > On Jun 3, 2009, at 8:12 AM, Paulo J. Matos wrote: > >> On Wed, Jun 3, 2009 at 3:49 AM, Jay McCarthy >> wrote: >>> >>> The structure patterns in scheme/match have always bugged me that they >>> didn't let you put the fields in any order and you had to put in _ for >>> the fields you didn't care about. > > IIUC, the proposal would allow you to leave out fields without a warning. > ?This strikes me as potentially dangerous, especially if this stuff is used > in the teaching languages. ?I actually recall some discussion of this on the > OCaml list (OCaml behaves in this way, IIUC), and some were suggesting that > a slightly different form be required for an incomplete match. > > John > > -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From d.j.gurnell at gmail.com Thu Jun 4 05:39:40 2009 From: d.j.gurnell at gmail.com (Dave Gurnell) Date: Thu Jun 4 05:40:13 2009 Subject: [plt-dev] struct match-expander a la struct-copy In-Reply-To: <756daca50906030934x6e3fea53jadc2ce50d4b867f5@mail.gmail.com> References: <756daca50906030934x6e3fea53jadc2ce50d4b867f5@mail.gmail.com> Message-ID: <8CD60001-EAA6-4D3A-B61C-868315AD2E14@gmail.com> > I've remedied this with a new match expander, struct*. I'd like to put > in the tree. Do people agree? This looks super-useful! From jay.mccarthy at gmail.com Thu Jun 4 13:03:28 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Thu Jun 4 13:03:50 2009 Subject: [plt-dev] syntax-local-lift-expressions Message-ID: I'm trying to use syntax-local-lift to lift the definition of a structure to the top level. syntax-local-lift-module-end-declaration doesn't work because it is not guaranteed to be in an expression context, so I can't have a define. syntax-local-lift-expression doesn't work because it only works for establishing a single binding, whereas a structure definition requires 3+2n bindings. I thought that I might be able to simulate this: #lang scheme (require (for-syntax scheme/list)) (define-for-syntax (syntax-local-lift-expression/values how-many stx) (define the-values-id (syntax-local-lift-expression (quasisyntax/loc stx (call-with-values #,stx (lambda the-values the-values))))) (build-list how-many (lambda (which-value) (syntax-local-lift-expression (quasisyntax/loc stx (list-ref #,the-values-id #,which-value)))))) (define-syntax (testit stx) (syntax-case stx () [(_) (let ([the-values (syntax-local-lift-expression/values 3 (syntax/loc stx (values 1 2 3)))]) (syntax-local-lift-module-end-declaration (quasisyntax/loc stx (begin #,@(map (lambda (value-id) (quasisyntax/loc stx (printf "~S~n" #,value-id))) the-values))))) (syntax/loc stx (printf "Lifted~n"))])) (testit) But I cannot, because syntax-local-lift-expression puts things in the reverse order of the calls. This is expanded in the macro stepper to: (define-values (lifted.6:84) (#%app:85 list-ref:86 lifted.0:87 '2)) (define-values (lifted.4:88) (#%app:89 list-ref:86 lifted.0:87 '1)) (define-values (lifted.2:90) (#%app:91 list-ref:86 lifted.0:87 '0)) (define-values (lifted.0:87) (#%app:92 call-with-values:86 (#%app:93 values:86 (quote 1) (quote 2) (quote 3)) (lambda:94 the-values:86 the-values:86))) (#%app:96 call-with-values:96 (lambda:96 () (#%app:95 printf:86 (quote "Lifted~n"))) print-values:96) (#%app:97 printf:86 (quote "~S~n") lifted.2:90) (#%app:98 printf:86 (quote "~S~n") lifted.4:88) (#%app:99 printf:86 (quote "~S~n") lifted.6:84) So... can we get either of these changed? Either a native syntax-local-lift-expressions or put the syntax-local-lift-expression calls in the order they are given, rather than the reverse? Jay -- 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 Thu Jun 4 14:03:32 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Thu Jun 4 14:03:52 2009 Subject: [plt-dev] syntax-local-lift-expressions In-Reply-To: References: Message-ID: <20090604180333.2B719650137@mail-svr1.cs.utah.edu> At Thu, 4 Jun 2009 11:03:28 -0600, Jay McCarthy wrote: > can we get [...] a native > syntax-local-lift-expressions Yes, I can add that. From robby at eecs.northwestern.edu Fri Jun 5 10:57:54 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Fri Jun 5 10:58:17 2009 Subject: [plt-dev] help with svn? Message-ID: <932b2f1f0906050757u49de73a1s42929d28de0539a9@mail.gmail.com> I was svn v1.5.4 to check out usr/robby and getting this error: svn: REPORT of '/usr/!svn/vcc/default': Could not read response body: Connection reset by peer (http://svn.plt-scheme.org) Exit 1 so I upgraded to 1.6.2 and now I get this: svn checkout http://svn.plt-scheme.org/usr/robby robby svn: Unrecognized URL scheme for 'http://svn.plt-scheme.org/usr/robby' Any ideas? Thanks, Robby From pocmatos at gmail.com Fri Jun 5 11:50:49 2009 From: pocmatos at gmail.com (Paulo J. Matos) Date: Fri Jun 5 11:51:41 2009 Subject: [plt-dev] help with svn? In-Reply-To: <932b2f1f0906050757u49de73a1s42929d28de0539a9@mail.gmail.com> References: <932b2f1f0906050757u49de73a1s42929d28de0539a9@mail.gmail.com> Message-ID: <11b141710906050850o1caa7a32q2a1736dfcdc99efc@mail.gmail.com> On Fri, Jun 5, 2009 at 3:57 PM, Robby Findler wrote: > I was svn v1.5.4 to check out usr/robby and getting this error: > > > svn: REPORT of '/usr/!svn/vcc/default': Could not read response body: > Connection reset by peer (http://svn.plt-scheme.org) > Exit 1 > > > so I upgraded to 1.6.2 and now I get this: > > svn checkout http://svn.plt-scheme.org/usr/robby robby > svn: Unrecognized URL scheme for 'http://svn.plt-scheme.org/usr/robby' > Which OS? I saw something like this recently when upgrading to 1.6.2 due to a bug in neon. In gentoo this was the bug report: http://bugs.gentoo.org/show_bug.cgi?id=264101 Solved by downgrading neon. Cheers, Paulo Matos > Any ideas? > > Thanks, > Robby > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > -- Paulo Jorge Matos - pocmatos at gmail.com http://www.pmatos.net From robby at eecs.northwestern.edu Fri Jun 5 12:33:01 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Fri Jun 5 12:33:22 2009 Subject: [plt-dev] help with svn? In-Reply-To: <11b141710906050850o1caa7a32q2a1736dfcdc99efc@mail.gmail.com> References: <932b2f1f0906050757u49de73a1s42929d28de0539a9@mail.gmail.com> <11b141710906050850o1caa7a32q2a1736dfcdc99efc@mail.gmail.com> Message-ID: <932b2f1f0906050933k4cd975c5o3cc035f46351d7ab@mail.gmail.com> Turns out I didn't include http support when I built 1.6.2. After doing that, I was able to check everything out fine. Robby On Fri, Jun 5, 2009 at 10:50 AM, Paulo J. Matos wrote: > On Fri, Jun 5, 2009 at 3:57 PM, Robby > Findler wrote: >> I was svn v1.5.4 to check out usr/robby and getting this error: >> >> >> svn: REPORT of '/usr/!svn/vcc/default': Could not read response body: >> Connection reset by peer (http://svn.plt-scheme.org) >> Exit 1 >> >> >> so I upgraded to 1.6.2 and now I get this: >> >> svn checkout http://svn.plt-scheme.org/usr/robby robby >> svn: Unrecognized URL scheme for 'http://svn.plt-scheme.org/usr/robby' >> > > Which OS? > I saw something like this recently when upgrading to 1.6.2 due to a > bug in neon. > In gentoo this was the bug report: > http://bugs.gentoo.org/show_bug.cgi?id=264101 > > Solved by downgrading neon. > > Cheers, > > Paulo Matos > >> Any ideas? >> >> Thanks, >> Robby >> _________________________________________________ >> ?For list-related administrative tasks: >> ?http://list.cs.brown.edu/mailman/listinfo/plt-dev >> > > > > -- > Paulo Jorge Matos - pocmatos at gmail.com > http://www.pmatos.net > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > From mflatt at cs.utah.edu Sat Jun 6 11:14:37 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Sat Jun 6 11:14:59 2009 Subject: [plt-dev] syntax-local-lift-expressions In-Reply-To: References: Message-ID: <20090606151439.4B5826500C8@mail-svr1.cs.utah.edu> At Thu, 4 Jun 2009 11:03:28 -0600, Jay McCarthy wrote: > I'm trying to use syntax-local-lift to lift the definition of a > structure to the top level. Now in SVN, v4.2.0.3 provides `syntax-local-lift-values-expression'. From robby at eecs.northwestern.edu Sat Jun 6 20:42:40 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Sat Jun 6 20:42:58 2009 Subject: [plt-dev] foreign fails to configure Message-ID: <932b2f1f0906061742q55d64c1lface1474966fe511@mail.gmail.com> I'm starting from a clean build directory and get the error: configure: error: source directory already configured; run "make distclean" there first configure: error: ../../../../foreign/gcc/libffi/configure failed for foreign/gcc/libffi Full transcript below. Robby [chienshi] ~/svn/exp/plt/src% mkdir build [chienshi] ~/svn/exp/plt/src% cd build [chienshi] exp/plt/src/build% ../configure checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking how to run the C preprocessor... gcc -E checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for ranlib... ranlib checking for cos in -lm... yes checking for dlopen in -ldl... yes checking for inline keyword... yes checking for noinline attribute... yes checking for GNU preprocessor... yes checking for nl_langinfo (CODESET)... yes checking for getaddrinfo... no checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... rm: conftest.dSYM: is a directory rm: conftest.dSYM: is a directory yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking iconv.h usability... yes checking iconv.h presence... yes checking for iconv.h... yes checking iconv is usable... yes -liconv checking for mbsrtowcs... yes checking for char... yes checking size of char... 1 checking for short... yes checking size of short... 2 checking for int... yes checking size of int... 4 checking for long... yes checking size of long... 4 checking for long long... yes checking size of long long... 8 checking for stack direction... down checking whether byte ordering is bigendian... no checking whether C++ compiler works... yes checking whether new and new[] are different... yes checking png.h usability... no checking png.h presence... no checking for png.h... no no libpng headers installed; building from PLT copy checking jpeglib.h usability... no checking jpeglib.h presence... no checking for jpeglib.h... no no libjpeg headers installed; building from PLT copy configure: creating ./config.status config.status: creating Makefile config.status: creating mzscheme/Makefile config.status: creating mzscheme/src/Makefile config.status: creating mzscheme/dynsrc/Makefile config.status: creating mzscheme/gc/Makefile config.status: creating mzscheme/sgc/Makefile config.status: creating mzscheme/gc2/Makefile config.status: creating foreign/Makefile config.status: creating mred/Makefile config.status: creating mred/wxs/Makefile config.status: creating mred/gc2/Makefile config.status: creating wxcommon/libpng/Makefile config.status: creating wxcommon/zlib/Makefile config.status: creating wxmac/src/Makefile config.status: creating mzscheme/mzconfig.h === configuring in foreign/gcc/libffi (/Users/robby/svn/exp/plt/src/build/foreign/gcc/libffi) configure: running /bin/sh ../../../../foreign/gcc/libffi/configure '--prefix=/Users/robby/svn/exp/plt' '--disable-multilib' --cache-file=/dev/null --srcdir=../../../../foreign/gcc/libffi checking build system type... i386-apple-darwin9.6.0 checking host system type... i386-apple-darwin9.6.0 checking target system type... i386-apple-darwin9.6.0 checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking whether make sets $(MAKE)... yes configure: error: source directory already configured; run "make distclean" there first configure: error: ../../../../foreign/gcc/libffi/configure failed for foreign/gcc/libffi Exit 1 [chienshi] exp/plt/src/build% From robby at eecs.northwestern.edu Sat Jun 6 20:45:45 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Sat Jun 6 20:52:32 2009 Subject: [plt-dev] Re: foreign fails to configure In-Reply-To: <932b2f1f0906061742q55d64c1lface1474966fe511@mail.gmail.com> References: <932b2f1f0906061742q55d64c1lface1474966fe511@mail.gmail.com> Message-ID: <932b2f1f0906061745g351fd85ahbc5bf324e748fe90@mail.gmail.com> Deleting all of the src tree and re-downloading it worked. I don't think that I'd run configure outside of that build directory, but it is possible, I suppose. Robby On Sat, Jun 6, 2009 at 7:42 PM, Robby Findler wrote: > I'm starting from a clean build directory and get the error: > > configure: error: source directory already configured; run "make > distclean" there first > configure: error: ../../../../foreign/gcc/libffi/configure failed for > foreign/gcc/libffi > > Full transcript below. > > Robby > > [chienshi] ~/svn/exp/plt/src% mkdir build > [chienshi] ~/svn/exp/plt/src% cd build > [chienshi] exp/plt/src/build% ../configure > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ISO C89... none needed > checking how to run the C preprocessor... gcc -E > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking how to run the C++ preprocessor... g++ -E > checking for ranlib... ranlib > checking for cos in -lm... yes > checking for dlopen in -ldl... yes > checking for inline keyword... yes > checking for noinline attribute... yes > checking for GNU preprocessor... yes > checking for nl_langinfo (CODESET)... yes > checking for getaddrinfo... no > checking for grep that handles long lines and -e... /usr/bin/grep > checking for egrep... /usr/bin/grep -E > checking for ANSI C header files... rm: conftest.dSYM: is a directory > rm: conftest.dSYM: is a directory > yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking iconv.h usability... yes > checking iconv.h presence... yes > checking for iconv.h... yes > checking iconv is usable... yes -liconv > checking for mbsrtowcs... yes > checking for char... yes > checking size of char... 1 > checking for short... yes > checking size of short... 2 > checking for int... yes > checking size of int... 4 > checking for long... yes > checking size of long... 4 > checking for long long... yes > checking size of long long... 8 > checking for stack direction... down > checking whether byte ordering is bigendian... no > checking whether C++ compiler works... yes > checking whether new and new[] are different... yes > checking png.h usability... no > checking png.h presence... no > checking for png.h... no > no libpng headers installed; building from PLT copy > checking jpeglib.h usability... no > checking jpeglib.h presence... no > checking for jpeglib.h... no > no libjpeg headers installed; building from PLT copy > configure: creating ./config.status > config.status: creating Makefile > config.status: creating mzscheme/Makefile > config.status: creating mzscheme/src/Makefile > config.status: creating mzscheme/dynsrc/Makefile > config.status: creating mzscheme/gc/Makefile > config.status: creating mzscheme/sgc/Makefile > config.status: creating mzscheme/gc2/Makefile > config.status: creating foreign/Makefile > config.status: creating mred/Makefile > config.status: creating mred/wxs/Makefile > config.status: creating mred/gc2/Makefile > config.status: creating wxcommon/libpng/Makefile > config.status: creating wxcommon/zlib/Makefile > config.status: creating wxmac/src/Makefile > config.status: creating mzscheme/mzconfig.h > === configuring in foreign/gcc/libffi > (/Users/robby/svn/exp/plt/src/build/foreign/gcc/libffi) > configure: running /bin/sh ../../../../foreign/gcc/libffi/configure > '--prefix=/Users/robby/svn/exp/plt' ?'--disable-multilib' > --cache-file=/dev/null --srcdir=../../../../foreign/gcc/libffi > checking build system type... i386-apple-darwin9.6.0 > checking host system type... i386-apple-darwin9.6.0 > checking target system type... i386-apple-darwin9.6.0 > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... no > checking for mawk... no > checking for nawk... no > checking for awk... awk > checking whether make sets $(MAKE)... yes > configure: error: source directory already configured; run "make > distclean" there first > configure: error: ../../../../foreign/gcc/libffi/configure failed for > foreign/gcc/libffi > Exit 1 > [chienshi] exp/plt/src/build% > From robby at eecs.northwestern.edu Sun Jun 7 08:39:01 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Sun Jun 7 08:39:25 2009 Subject: [plt-dev] Re: [plt-scheme] SchemeUnit confusion In-Reply-To: References: <904774730906061815k1b921710h2385077107b26ba9@mail.gmail.com> Message-ID: <932b2f1f0906070539pc996511qa8c7d62e848de2c2@mail.gmail.com> Why recommend the planet version over the core version? Robby On Sun, Jun 7, 2009 at 3:48 AM, Noel Welsh wrote: > On Sun, Jun 7, 2009 at 2:15 AM, Todd O'Bryan wrote: >> In the latest SVN, I have the following program in the Definitions window. >> >> #lang scheme/base >> (require (planet schematics/schemeunit:3) >> ? ? ? ? schemeunit/text-ui) >> > > Here you mix the Planet version of SchemeUnit with the version bundled > with PLT. Due to generative structures they don't interact well. I > recommend using just the Planet version: > > (require (planet schematics/schemeunit:3) > ? ? ? ? ? ? (planet schematics/schemeunit:3/text-ui)) > > N. > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-scheme > From eli at barzilay.org Sun Jun 7 13:07:45 2009 From: eli at barzilay.org (Eli Barzilay) Date: Sun Jun 7 13:08:06 2009 Subject: [plt-dev] Re: doc searches In-Reply-To: References: <4A2AE422.40700@neilvandyke.org> <18987.41614.846385.281248@winooski.ccs.neu.edu> <4A2BB30B.9050702@neilvandyke.org> <18987.46409.175262.68355@winooski.ccs.neu.edu> <18987.61070.354579.936597@winooski.ccs.neu.edu> Message-ID: <18987.62433.382001.239872@winooski.ccs.neu.edu> [Note: moved to plt-dev, since this is off-topic for the general list.] On Jun 7, Henk Boom wrote: > 2009/6/7 Eli Barzilay : > > On Jun ?7, Henk Boom wrote: > >> > >> Why not keep only the identifier and module names in the main index, > >> then when the user clicks on the link get the html information from > >> a .js file based on a hash of the name? Just from looking at the > >> index file it seems that this would shrink it quite a bit. > > > > * Note that as soon as you stop typing, it starts a search, and to > > ?display the results it will need the rest of the information. ?(You > > ?could argue for changing that interface though, and make it require > > ?clicking some search button or hitting enter -- but see below.) > > > > * If the hashes are good, it means that results will be distributed > > ?nicely over all sub-files, which means that an average batch of > > ?results will hit all of them, so you'll end up loading all data > > ?anyway, and possibly slower, since it'll neead to read a file, and > > ?merge the data into the main index vector, with all the accounting > > ?that it implies. > > > > * Another problem is what I mentioned earlier -- it requires runtime > > ?loading of files, which can be a pain when used with local pages. > > > > * In addition, there are additional bits of information that are > > ?needed: > > ?- What's the type of the entry (eg, you can use `M:' to search only > > ? ?for bindings)? > > ?- Which module is it coming from (the full version of that operator > > ? ?is `M:' to restrict searches only for bindings in matching > > ? ?modules)? > > ?- Which manual is it coming from (the `T:' operator makes the search > > ? ?specific to a manual)? > > Ah, I see it's more complicated than I thought. I can reply to some > of the points you bring up, but not all: Well, I'm not trying to get into some flamewar over the details -- I'm just listing the problems that I can expect or went through. So yes, some of these can be addressed, in some way that is bad to some degree, but that doesn't help with actually getting a solution. > Why does it need the rest of the information to display the results? > If you only fetch the URL when the user clicks the link it seems > that only the name and the module are needed for display. This means > that typically you would need only to load a single one of the hash > .js files. Loading on a click is worse that what I thought you suggested. It means that the link cannot point to the right manual which means that you can't see in your browser's status line where it will take you (that's something that I consider pretty rude...). But ignoring that, it means that at the moment when the link is clicked, the code should retrieve the file to know where to jump to -- which will delay the action, and in some cases it will just appear that the page is not working at all. In addition to that you run into a bunch of problems at the low-level that the browser should really take care of. For example, you can just make the browser jump to a page -- you need to check the ctrl and shift status to know if the user wanted a new window or tab, taking into consideration the different interfaces in different browsers, and ignoring browsers that might be user-customized (which will just have to face the fact that the plt pages behave like we want them to, ignoring what you like), and assuming that there *is* a way to open a new tab or a new window reliable (probably not, since it's rare to see a browser without some popup blocker these days). You also need to deal gracefully with failures -- a second click before the index is retrieved should be ignored *unless* enough time has passed which means that we should give up on getting it. (And this is much more of a problem than it seems -- the first thing anyone will do when a link doesn't respond is to immediately click it repeatedly a few times.) > If you include the module name and the manual name (perhaps by index) > in the main .js file then M: and T: should work fine as far as I can > tell. That's already most of the data. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From henk at henk.ca Sun Jun 7 13:29:16 2009 From: henk at henk.ca (Henk Boom) Date: Sun Jun 7 13:29:35 2009 Subject: [plt-dev] Re: doc searches In-Reply-To: <18987.62433.382001.239872@winooski.ccs.neu.edu> References: <4A2AE422.40700@neilvandyke.org> <18987.41614.846385.281248@winooski.ccs.neu.edu> <4A2BB30B.9050702@neilvandyke.org> <18987.46409.175262.68355@winooski.ccs.neu.edu> <18987.61070.354579.936597@winooski.ccs.neu.edu> <18987.62433.382001.239872@winooski.ccs.neu.edu> Message-ID: (Sorry Eli, I forgot to reply to list) 2009/6/7 Eli Barzilay : > Loading on a click is worse that what I thought you suggested. =C2=A0It > means that the link cannot point to the right manual which means that > you can't see in your browser's status line where it will take you > (that's something that I consider pretty rude...). =C2=A0But ignoring tha= t, > it means that at the moment when the link is clicked, the code should > retrieve the file to know where to jump to -- which will delay the > action, and in some cases it will just appear that the page is not > working at all. > > In addition to that you run into a bunch of problems at the low-level > that the browser should really take care of. =C2=A0For example, you can > just make the browser jump to a page -- you need to check the ctrl and > shift status to know if the user wanted a new window or tab, taking > into consideration the different interfaces in different browsers, and > ignoring browsers that might be user-customized (which will just have > to face the fact that the plt pages behave like we want them to, > ignoring what you like), and assuming that there *is* a way to open a > new tab or a new window reliable (probably not, since it's rare to see > a browser without some popup blocker these days). > > You also need to deal gracefully with failures -- a second click > before the index is retrieved should be ignored *unless* enough time > has passed which means that we should give up on getting it. =C2=A0(And > this is much more of a problem than it seems -- the first thing anyone > will do when a link doesn't respond is to immediately click it > repeatedly a few times.) > > >> If you include the module name and the manual name (perhaps by index) >> in the main .js file then M: and T: should work fine as far as I can >> tell. I can see now that this probably isn't going to work as a solution. Just FYI though, there's a common trick for handling this kind of on-click event which is to have the url point to #goto-car or something similar and handle it as a response to that instead, this way it "just works" when the user opens the link in a new window/tab. AFAIK Facebook/twitter/Google Reader do something like this, though they use it for triggering ajax page reloads rather than for redirects. Henk From eli at barzilay.org Sun Jun 7 14:25:52 2009 From: eli at barzilay.org (Eli Barzilay) Date: Sun Jun 7 14:26:13 2009 Subject: [plt-dev] Re: doc searches In-Reply-To: References: <4A2AE422.40700@neilvandyke.org> <18987.41614.846385.281248@winooski.ccs.neu.edu> <4A2BB30B.9050702@neilvandyke.org> <18987.46409.175262.68355@winooski.ccs.neu.edu> <18987.61070.354579.936597@winooski.ccs.neu.edu> <18987.62433.382001.239872@winooski.ccs.neu.edu> Message-ID: <18988.1584.539393.767375@winooski.ccs.neu.edu> On Jun 7, Henk Boom wrote: > > I can see now that this probably isn't going to work as a solution. > > Just FYI though, there's a common trick for handling this kind of > on-click event which is to have the url point to #goto-car or > something similar and handle it as a response to that instead, this > way it "just works" when the user opens the link in a new > window/tab. AFAIK Facebook/twitter/Google Reader do something like > this, though they use it for triggering ajax page reloads rather > than for redirects. What ajax pages do (AFAICT), is basically push "somepage#some-data" down your history, which makes it possible to use the back button to do things like jump back from a mail search view back to the default mailbox view. It also makes it possible to save a url that will make it go to a specific email or search etc. (For example, with FF's feature of saving the state when you exit, it means that next time you start it you will get to the same state you were at.) I've looked at doing it for the searches, but there are some hairy issues (as usual with browser compatibility) to solve -- so it's either deal with these issues, or drag in another javascript library into plt just to do that. Now, even if that's done, there is still a problem with loading the index file: if I middle-click a link to get it in a new tab, most browsers will reload the JS index in that tab and then proceed to load the hash chunk with the rest of the data. This means that the time from clicking a link to getting the page becomes extremely slow. (BTW, last time I looked, only IE was caching the index vector so openning the search page in a second tab did not have a delay. But to compensate for that, it took longer than other browsers to load the index...) BTW, I should have mentioned trampoline pages -- those are similar in nature, and suffer from similar issues (maybe more severe). -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From robby at eecs.northwestern.edu Mon Jun 8 14:00:09 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Mon Jun 8 14:22:51 2009 Subject: [plt-dev] more svn troubles Message-ID: <932b2f1f0906081100h1237ef7ax78c97d5a9dcdb957@mail.gmail.com> Now that I'm using svn v1.6.2, I can't seem to login to get /usr/matthias/Papers/Universe. This might be because of a new way of interpreting permissions (as I can still get the files via the web browser). Anyone know? (Eli, could you just give me more permissions, if that seems like it would work?) Thanks, Robby From noelwelsh at gmail.com Mon Jun 8 16:03:25 2009 From: noelwelsh at gmail.com (Noel Welsh) Date: Mon Jun 8 16:03:54 2009 Subject: [plt-dev] Re: [plt-scheme] SchemeUnit confusion In-Reply-To: <932b2f1f0906070539pc996511qa8c7d62e848de2c2@mail.gmail.com> References: <904774730906061815k1b921710h2385077107b26ba9@mail.gmail.com> <932b2f1f0906070539pc996511qa8c7d62e848de2c2@mail.gmail.com> Message-ID: Dependency management. We've been bitten by changes in the web server stopping us upgrading PLT to get bug fixes in other areas. Now SchemeUnit isn't as likely to change as the web server, but why make the dependency if you can avoid it? (This only applies if you aren't developing core code. If you are, use the core version.) N. On Sun, Jun 7, 2009 at 1:39 PM, Robby Findler wrote: > Why recommend the planet version over the core version? > > Robby From matthias at ccs.neu.edu Mon Jun 8 17:59:58 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Mon Jun 8 18:00:44 2009 Subject: [plt-dev] Re: [plt-scheme] SchemeUnit confusion In-Reply-To: References: <904774730906061815k1b921710h2385077107b26ba9@mail.gmail.com> <932b2f1f0906070539pc996511qa8c7d62e848de2c2@mail.gmail.com> Message-ID: <12ADC240-877C-429C-BC41-DB137488015F@ccs.neu.edu> Noel, I don't understand this response at all. Could you elaborate? In the past we have deprecated planet package when we moved code into the core. -- Matthias On Jun 8, 2009, at 4:03 PM, Noel Welsh wrote: > Dependency management. We've been bitten by changes in the web server > stopping us upgrading PLT to get bug fixes in other areas. Now > SchemeUnit isn't as likely to change as the web server, but why make > the dependency if you can avoid it? (This only applies if you aren't > developing core code. If you are, use the core version.) > > N. > > On Sun, Jun 7, 2009 at 1:39 PM, Robby > Findler wrote: >> Why recommend the planet version over the core version? >> >> Robby > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From d.j.gurnell at gmail.com Tue Jun 9 05:10:58 2009 From: d.j.gurnell at gmail.com (Dave Gurnell) Date: Tue Jun 9 05:11:30 2009 Subject: [plt-dev] Re: [plt-scheme] SchemeUnit confusion In-Reply-To: <12ADC240-877C-429C-BC41-DB137488015F@ccs.neu.edu> References: <904774730906061815k1b921710h2385077107b26ba9@mail.gmail.com> <932b2f1f0906070539pc996511qa8c7d62e848de2c2@mail.gmail.com> <12ADC240-877C-429C-BC41-DB137488015F@ccs.neu.edu> Message-ID: <6E44B2CE-1501-4197-8189-4577B8ED5422@gmail.com> From an app developer's point of view, I think Noel's reasoning is this: All of PLT is bundled together under one big version number. If you upgrade the core, you upgrade all the satellite libraries as well. This has three drawbacks: - if you want to upgrade to a newer version of PLT for an improvement in one library, you may have to deal with potential backwards-incompatible changes in other libraries at the same time; - compiling all of PLT can be slow; - other software you have developed may still use older versions of PLT. PLaneT offers a little more flexibility: to a certain degree you can choose to upgrade one dependency independently of the rest. In other words, if Noel makes a change to Schemeunit, and a developer is requiring it from the core, he/she will have to update all of PLT at the same time, which might take a while and make upgrading difficult. If, however, the developer is requiring Schemeunit from PLaneT, they should hopefully be able to just upgrade that one library and leave everything else as-is. Cheers, -- Dave > Noel, I don't understand this response at all. Could you elaborate? > In the past we have deprecated planet package when we moved code > into the core. -- Matthias > >> Dependency management. We've been bitten by changes in the web server >> stopping us upgrading PLT to get bug fixes in other areas. Now >> SchemeUnit isn't as likely to change as the web server, but why make >> the dependency if you can avoid it? (This only applies if you aren't >> developing core code. If you are, use the core version.) >> >> N. >> >>> Why recommend the planet version over the core version? >>> >>> Robby > From matthias at ccs.neu.edu Tue Jun 9 09:21:22 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Tue Jun 9 09:22:08 2009 Subject: [plt-dev] Re: [plt-scheme] SchemeUnit confusion In-Reply-To: <6E44B2CE-1501-4197-8189-4577B8ED5422@gmail.com> References: <904774730906061815k1b921710h2385077107b26ba9@mail.gmail.com> <932b2f1f0906070539pc996511qa8c7d62e848de2c2@mail.gmail.com> <12ADC240-877C-429C-BC41-DB137488015F@ccs.neu.edu> <6E44B2CE-1501-4197-8189-4577B8ED5422@gmail.com> Message-ID: <988E91FE-BDAC-41B2-8CA1-6F2CDC8EA816@ccs.neu.edu> We routinely update collections in the core code base and most of the time, it suffices to run setup on the new collection or a few others. (Personally I often update my code base from scratch once a day.) I think it would be great if we got into this mode for SU, too. -- Matthias On Jun 9, 2009, at 5:10 AM, Dave Gurnell wrote: > From an app developer's point of view, I think Noel's reasoning is > this: > > All of PLT is bundled together under one big version number. If you > upgrade the core, you upgrade all the satellite libraries as well. > This has three drawbacks: > > - if you want to upgrade to a newer version of PLT for an > improvement in one library, you may have to deal with potential > backwards-incompatible changes in other libraries at the same time; > > - compiling all of PLT can be slow; > > - other software you have developed may still use older versions > of PLT. > > PLaneT offers a little more flexibility: to a certain degree you > can choose to upgrade one dependency independently of the rest. > > In other words, if Noel makes a change to Schemeunit, and a > developer is requiring it from the core, he/she will have to update > all of PLT at the same time, which might take a while and make > upgrading difficult. If, however, the developer is requiring > Schemeunit from PLaneT, they should hopefully be able to just > upgrade that one library and leave everything else as-is. > > Cheers, > > -- Dave > >> Noel, I don't understand this response at all. Could you >> elaborate? In the past we have deprecated planet package when we >> moved code into the core. -- Matthias >> >>> Dependency management. We've been bitten by changes in the web >>> server >>> stopping us upgrading PLT to get bug fixes in other areas. Now >>> SchemeUnit isn't as likely to change as the web server, but why make >>> the dependency if you can avoid it? (This only applies if you aren't >>> developing core code. If you are, use the core version.) >>> >>> N. >>> >>>> Why recommend the planet version over the core version? >>>> >>>> Robby >> > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From matthias at ccs.neu.edu Tue Jun 9 09:33:50 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Tue Jun 9 09:34:34 2009 Subject: [plt-dev] Re: [plt-scheme] SchemeUnit confusion In-Reply-To: <932b2f1f0906090631g322ff53m43c8dc2f9adc1e7b@mail.gmail.com> References: <904774730906061815k1b921710h2385077107b26ba9@mail.gmail.com> <932b2f1f0906070539pc996511qa8c7d62e848de2c2@mail.gmail.com> <12ADC240-877C-429C-BC41-DB137488015F@ccs.neu.edu> <6E44B2CE-1501-4197-8189-4577B8ED5422@gmail.com> <988E91FE-BDAC-41B2-8CA1-6F2CDC8EA816@ccs.neu.edu> <932b2f1f0906090631g322ff53m43c8dc2f9adc1e7b@mail.gmail.com> Message-ID: Then I don't understand the exchange either. People who use an actual release (as opposed to the svn head) have a stable release of SU. When the next release comes out, they get a pre-compiled bundle, ready to install. Sorry for being dense -- Matthias On Jun 9, 2009, at 9:31 AM, Robby Findler wrote: > I think the concern is for code that is being written by people who > aren't working in our SVN repository. > > Robby > > On Tue, Jun 9, 2009 at 8:21 AM, Matthias > Felleisen wrote: >> >> We routinely update collections in the core code base and most of >> the time, >> it suffices to run setup on the new collection or a few others. >> (Personally >> I often update my code base from scratch once a day.) >> >> I think it would be great if we got into this mode for SU, too. -- >> Matthias >> >> >> >> >> >> On Jun 9, 2009, at 5:10 AM, Dave Gurnell wrote: >> >>> From an app developer's point of view, I think Noel's reasoning >>> is this: >>> >>> All of PLT is bundled together under one big version number. If you >>> upgrade the core, you upgrade all the satellite libraries as >>> well. This has >>> three drawbacks: >>> >>> - if you want to upgrade to a newer version of PLT for an >>> improvement in >>> one library, you may have to deal with potential backwards- >>> incompatible >>> changes in other libraries at the same time; >>> >>> - compiling all of PLT can be slow; >>> >>> - other software you have developed may still use older versions >>> of PLT. >>> >>> PLaneT offers a little more flexibility: to a certain degree you can >>> choose to upgrade one dependency independently of the rest. >>> >>> In other words, if Noel makes a change to Schemeunit, and a >>> developer is >>> requiring it from the core, he/she will have to update all of PLT >>> at the >>> same time, which might take a while and make upgrading difficult. >>> If, >>> however, the developer is requiring Schemeunit from PLaneT, they >>> should >>> hopefully be able to just upgrade that one library and leave >>> everything else >>> as-is. >>> >>> Cheers, >>> >>> -- Dave >>> >>>> Noel, I don't understand this response at all. Could you >>>> elaborate? In >>>> the past we have deprecated planet package when we moved code >>>> into the core. >>>> -- Matthias >>>> >>>>> Dependency management. We've been bitten by changes in the web >>>>> server >>>>> stopping us upgrading PLT to get bug fixes in other areas. Now >>>>> SchemeUnit isn't as likely to change as the web server, but why >>>>> make >>>>> the dependency if you can avoid it? (This only applies if you >>>>> aren't >>>>> developing core code. If you are, use the core version.) >>>>> >>>>> N. >>>>> >>>>>> Why recommend the planet version over the core version? >>>>>> >>>>>> Robby >>>> >>> _________________________________________________ >>> For list-related administrative tasks: >>> http://list.cs.brown.edu/mailman/listinfo/plt-dev >> >> _________________________________________________ >> For list-related administrative tasks: >> http://list.cs.brown.edu/mailman/listinfo/plt-dev >> From robby at eecs.northwestern.edu Tue Jun 9 09:31:24 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Tue Jun 9 09:36:49 2009 Subject: [plt-dev] Re: [plt-scheme] SchemeUnit confusion In-Reply-To: <988E91FE-BDAC-41B2-8CA1-6F2CDC8EA816@ccs.neu.edu> References: <904774730906061815k1b921710h2385077107b26ba9@mail.gmail.com> <932b2f1f0906070539pc996511qa8c7d62e848de2c2@mail.gmail.com> <12ADC240-877C-429C-BC41-DB137488015F@ccs.neu.edu> <6E44B2CE-1501-4197-8189-4577B8ED5422@gmail.com> <988E91FE-BDAC-41B2-8CA1-6F2CDC8EA816@ccs.neu.edu> Message-ID: <932b2f1f0906090631g322ff53m43c8dc2f9adc1e7b@mail.gmail.com> I think the concern is for code that is being written by people who aren't working in our SVN repository. Robby On Tue, Jun 9, 2009 at 8:21 AM, Matthias Felleisen wrote: > > We routinely update collections in the core code base and most of the time, > it suffices to run setup on the new collection or a few others. (Personally > I often update my code base from scratch once a day.) > > I think it would be great if we got into this mode for SU, too. -- Matthias > > > > > > On Jun 9, 2009, at 5:10 AM, Dave Gurnell wrote: > >> From an app developer's point of view, I think Noel's reasoning is this: >> >> All of PLT is bundled together under one big version number. If you >> upgrade the core, you upgrade all the satellite libraries as well. This has >> three drawbacks: >> >> ?- if you want to upgrade to a newer version of PLT for an improvement in >> one library, you may have to deal with potential backwards-incompatible >> changes in other libraries at the same time; >> >> ?- compiling all of PLT can be slow; >> >> ?- other software you have developed may still use older versions of PLT. >> >> PLaneT offers a little more flexibility: to a certain degree you can >> choose to upgrade one dependency independently of the rest. >> >> In other words, if Noel makes a change to Schemeunit, and a developer is >> requiring it from the core, he/she will have to update all of PLT at the >> same time, which might take a while and make upgrading difficult. If, >> however, the developer is requiring Schemeunit from PLaneT, they should >> hopefully be able to just upgrade that one library and leave everything else >> as-is. >> >> Cheers, >> >> -- Dave >> >>> Noel, I don't understand this response at all. Could you elaborate? In >>> the past we have deprecated planet package when we moved code into the core. >>> -- Matthias >>> >>>> Dependency management. We've been bitten by changes in the web server >>>> stopping us upgrading PLT to get bug fixes in other areas. Now >>>> SchemeUnit isn't as likely to change as the web server, but why make >>>> the dependency if you can avoid it? (This only applies if you aren't >>>> developing core code. If you are, use the core version.) >>>> >>>> N. >>>> >>>>> Why recommend the planet version over the core version? >>>>> >>>>> Robby >>> >> _________________________________________________ >> ?For list-related administrative tasks: >> ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > From matthias at ccs.neu.edu Tue Jun 9 09:39:44 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Tue Jun 9 09:40:29 2009 Subject: [plt-dev] Re: [plt-scheme] SchemeUnit confusion In-Reply-To: <932b2f1f0906090636j10cf542cs6491bc7e1c3581c1@mail.gmail.com> References: <904774730906061815k1b921710h2385077107b26ba9@mail.gmail.com> <932b2f1f0906070539pc996511qa8c7d62e848de2c2@mail.gmail.com> <12ADC240-877C-429C-BC41-DB137488015F@ccs.neu.edu> <6E44B2CE-1501-4197-8189-4577B8ED5422@gmail.com> <988E91FE-BDAC-41B2-8CA1-6F2CDC8EA816@ccs.neu.edu> <932b2f1f0906090631g322ff53m43c8dc2f9adc1e7b@mail.gmail.com> <932b2f1f0906090636j10cf542cs6491bc7e1c3581c1@mail.gmail.com> Message-ID: Thanks. I understand that but I find the probability of such scenarios low. Perhaps it's a lack of experience with planet libraries. Eli just told me that SU isn't a part of the release yet, so my assumptions were wrong, too. I think it should be a part of the release and I have told Eli so. On Jun 9, 2009, at 9:36 AM, Robby Findler wrote: > I think the worry goes something like this: > > a) I use the plt web server and scheme unit (to pick two arbitrary > parts of the distribution, really this could be X and Y iiuc). > b) a new release comes out that has a bugfix in the web server that > I need > c) the new release also comes with backwards incompatibilities to > schemeunit that break my code that I don't have time at the moment to > fix. > > What to do? Well, if I had used schemeunit from planet, I could > (probably) upgrade the webserver only, without upgrading schemeunit. > > Robby > > On Tue, Jun 9, 2009 at 8:33 AM, Matthias > Felleisen wrote: >> >> Then I don't understand the exchange either. People who use an actual >> release (as opposed to the svn head) have a stable release of SU. >> When >> the next release comes out, they get a pre-compiled bundle, ready to >> install. >> >> Sorry for being dense -- Matthias >> >> >> >> >> >> >> On Jun 9, 2009, at 9:31 AM, Robby Findler wrote: >> >>> I think the concern is for code that is being written by people who >>> aren't working in our SVN repository. >>> >>> Robby >>> >>> On Tue, Jun 9, 2009 at 8:21 AM, Matthias >>> Felleisen >>> wrote: >>>> >>>> We routinely update collections in the core code base and most >>>> of the >>>> time, >>>> it suffices to run setup on the new collection or a few others. >>>> (Personally >>>> I often update my code base from scratch once a day.) >>>> >>>> I think it would be great if we got into this mode for SU, too. -- >>>> Matthias >>>> >>>> >>>> >>>> >>>> >>>> On Jun 9, 2009, at 5:10 AM, Dave Gurnell wrote: >>>> >>>>> From an app developer's point of view, I think Noel's reasoning >>>>> is this: >>>>> >>>>> All of PLT is bundled together under one big version number. If >>>>> you >>>>> upgrade the core, you upgrade all the satellite libraries as >>>>> well. This >>>>> has >>>>> three drawbacks: >>>>> >>>>> - if you want to upgrade to a newer version of PLT for an >>>>> improvement >>>>> in >>>>> one library, you may have to deal with potential backwards- >>>>> incompatible >>>>> changes in other libraries at the same time; >>>>> >>>>> - compiling all of PLT can be slow; >>>>> >>>>> - other software you have developed may still use older >>>>> versions of >>>>> PLT. >>>>> >>>>> PLaneT offers a little more flexibility: to a certain degree >>>>> you can >>>>> choose to upgrade one dependency independently of the rest. >>>>> >>>>> In other words, if Noel makes a change to Schemeunit, and a >>>>> developer is >>>>> requiring it from the core, he/she will have to update all of >>>>> PLT at the >>>>> same time, which might take a while and make upgrading >>>>> difficult. If, >>>>> however, the developer is requiring Schemeunit from PLaneT, >>>>> they should >>>>> hopefully be able to just upgrade that one library and leave >>>>> everything >>>>> else >>>>> as-is. >>>>> >>>>> Cheers, >>>>> >>>>> -- Dave >>>>> >>>>>> Noel, I don't understand this response at all. Could you >>>>>> elaborate? In >>>>>> the past we have deprecated planet package when we moved code >>>>>> into the >>>>>> core. >>>>>> -- Matthias >>>>>> >>>>>>> Dependency management. We've been bitten by changes in the >>>>>>> web server >>>>>>> stopping us upgrading PLT to get bug fixes in other areas. Now >>>>>>> SchemeUnit isn't as likely to change as the web server, but >>>>>>> why make >>>>>>> the dependency if you can avoid it? (This only applies if you >>>>>>> aren't >>>>>>> developing core code. If you are, use the core version.) >>>>>>> >>>>>>> N. >>>>>>> >>>>>>>> Why recommend the planet version over the core version? >>>>>>>> >>>>>>>> Robby >>>>>> >>>>> _________________________________________________ >>>>> For list-related administrative tasks: >>>>> http://list.cs.brown.edu/mailman/listinfo/plt-dev >>>> >>>> _________________________________________________ >>>> For list-related administrative tasks: >>>> http://list.cs.brown.edu/mailman/listinfo/plt-dev >>>> >> >> From robby at eecs.northwestern.edu Tue Jun 9 09:43:18 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Tue Jun 9 09:43:43 2009 Subject: [plt-dev] Re: [plt-scheme] SchemeUnit confusion In-Reply-To: References: <904774730906061815k1b921710h2385077107b26ba9@mail.gmail.com> <932b2f1f0906070539pc996511qa8c7d62e848de2c2@mail.gmail.com> <12ADC240-877C-429C-BC41-DB137488015F@ccs.neu.edu> <6E44B2CE-1501-4197-8189-4577B8ED5422@gmail.com> <988E91FE-BDAC-41B2-8CA1-6F2CDC8EA816@ccs.neu.edu> <932b2f1f0906090631g322ff53m43c8dc2f9adc1e7b@mail.gmail.com> <932b2f1f0906090636j10cf542cs6491bc7e1c3581c1@mail.gmail.com> Message-ID: <932b2f1f0906090643o1d5bab42sb9915ec301e0ddb1@mail.gmail.com> Well, if you look at the larger picture of a community-wide synchronized release of everything that is currently in planet, that is clearly untenable. So there is some value in letting things move independently. Another thing to compare to is OS releases. Perhaps we should be spending more manpower on planet and everything outside of mzscheme and a few core libraries should move there. Then, a major release corresponds to picking a set of version numbers from planet and packaging them into a single distributable. Robby On Tue, Jun 9, 2009 at 8:39 AM, Matthias Felleisen wrote: > > Thanks. I understand that but I find the probability of such > scenarios low. Perhaps it's a lack of experience with planet > libraries. > > Eli just told me that SU isn't a part of the release yet, so my > assumptions were wrong, too. > > I think it should be a part of the release and I have told Eli so. > > > > > > On Jun 9, 2009, at 9:36 AM, Robby Findler wrote: > >> I think the worry goes something like this: >> >> a) I use the plt web server and scheme unit (to pick two arbitrary >> parts of the distribution, really this could be X and Y iiuc). >> b) a new release comes out that has a bugfix in the web server that I need >> c) the new release also comes with backwards incompatibilities to >> schemeunit that break my code that I don't have time at the moment to >> fix. >> >> What to do? Well, if I had used schemeunit from planet, I could >> (probably) upgrade the webserver only, without upgrading schemeunit. >> >> Robby >> >> On Tue, Jun 9, 2009 at 8:33 AM, Matthias Felleisen >> wrote: >>> >>> Then I don't understand the exchange either. People who use an actual >>> release (as opposed to the svn head) have a stable release of SU. When >>> the next release comes out, they get a pre-compiled bundle, ready to >>> install. >>> >>> Sorry for being dense -- Matthias >>> >>> >>> >>> >>> >>> >>> On Jun 9, 2009, at 9:31 AM, Robby Findler wrote: >>> >>>> I think the concern is for code that is being written by people who >>>> aren't working in our SVN repository. >>>> >>>> Robby >>>> >>>> On Tue, Jun 9, 2009 at 8:21 AM, Matthias Felleisen >>>> wrote: >>>>> >>>>> We routinely update collections in the core code base and most of the >>>>> time, >>>>> it suffices to run setup on the new collection or a few others. >>>>> (Personally >>>>> I often update my code base from scratch once a day.) >>>>> >>>>> I think it would be great if we got into this mode for SU, too. -- >>>>> Matthias >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Jun 9, 2009, at 5:10 AM, Dave Gurnell wrote: >>>>> >>>>>> From an app developer's point of view, I think Noel's reasoning is >>>>>> this: >>>>>> >>>>>> All of PLT is bundled together under one big version number. If you >>>>>> upgrade the core, you upgrade all the satellite libraries as well. >>>>>> This >>>>>> has >>>>>> three drawbacks: >>>>>> >>>>>> ?- if you want to upgrade to a newer version of PLT for an improvement >>>>>> in >>>>>> one library, you may have to deal with potential >>>>>> backwards-incompatible >>>>>> changes in other libraries at the same time; >>>>>> >>>>>> ?- compiling all of PLT can be slow; >>>>>> >>>>>> ?- other software you have developed may still use older versions of >>>>>> PLT. >>>>>> >>>>>> PLaneT offers a little more flexibility: to a certain degree you can >>>>>> choose to upgrade one dependency independently of the rest. >>>>>> >>>>>> In other words, if Noel makes a change to Schemeunit, and a developer >>>>>> is >>>>>> requiring it from the core, he/she will have to update all of PLT at >>>>>> the >>>>>> same time, which might take a while and make upgrading difficult. If, >>>>>> however, the developer is requiring Schemeunit from PLaneT, they >>>>>> should >>>>>> hopefully be able to just upgrade that one library and leave >>>>>> everything >>>>>> else >>>>>> as-is. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> -- Dave >>>>>> >>>>>>> Noel, I don't understand this response at all. Could you elaborate? >>>>>>> In >>>>>>> the past we have deprecated planet package when we moved code into >>>>>>> the >>>>>>> core. >>>>>>> -- Matthias >>>>>>> >>>>>>>> Dependency management. We've been bitten by changes in the web >>>>>>>> server >>>>>>>> stopping us upgrading PLT to get bug fixes in other areas. Now >>>>>>>> SchemeUnit isn't as likely to change as the web server, but why make >>>>>>>> the dependency if you can avoid it? (This only applies if you aren't >>>>>>>> developing core code. If you are, use the core version.) >>>>>>>> >>>>>>>> N. >>>>>>>> >>>>>>>>> Why recommend the planet version over the core version? >>>>>>>>> >>>>>>>>> Robby >>>>>>> >>>>>> _________________________________________________ >>>>>> ?For list-related administrative tasks: >>>>>> ?http://list.cs.brown.edu/mailman/listinfo/plt-dev >>>>> >>>>> _________________________________________________ >>>>> ?For list-related administrative tasks: >>>>> ?http://list.cs.brown.edu/mailman/listinfo/plt-dev >>>>> >>> >>> > > From noelwelsh at gmail.com Tue Jun 9 09:52:42 2009 From: noelwelsh at gmail.com (Noel Welsh) Date: Tue Jun 9 09:53:00 2009 Subject: [plt-dev] Re: [plt-scheme] SchemeUnit confusion In-Reply-To: <932b2f1f0906090643o1d5bab42sb9915ec301e0ddb1@mail.gmail.com> References: <904774730906061815k1b921710h2385077107b26ba9@mail.gmail.com> <12ADC240-877C-429C-BC41-DB137488015F@ccs.neu.edu> <6E44B2CE-1501-4197-8189-4577B8ED5422@gmail.com> <988E91FE-BDAC-41B2-8CA1-6F2CDC8EA816@ccs.neu.edu> <932b2f1f0906090631g322ff53m43c8dc2f9adc1e7b@mail.gmail.com> <932b2f1f0906090636j10cf542cs6491bc7e1c3581c1@mail.gmail.com> <932b2f1f0906090643o1d5bab42sb9915ec301e0ddb1@mail.gmail.com> Message-ID: At Untyped we normally develop on something close to the trunk (necessary for bug fixes and so on) and fairly regularly get wedged by incompatible changes. On Tue, Jun 9, 2009 at 2:43 PM, Robby Findler wrote: > ... Perhaps we > should be spending more manpower on planet and everything outside of > mzscheme and a few core libraries should move there. Then, a major > release corresponds to picking a set of version numbers from planet > and packaging them into a single distributable. This would be ideal, IMO N. From matthias at ccs.neu.edu Tue Jun 9 09:55:35 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Tue Jun 9 09:56:20 2009 Subject: [plt-dev] Re: [plt-scheme] SchemeUnit confusion In-Reply-To: <932b2f1f0906090643o1d5bab42sb9915ec301e0ddb1@mail.gmail.com> References: <904774730906061815k1b921710h2385077107b26ba9@mail.gmail.com> <932b2f1f0906070539pc996511qa8c7d62e848de2c2@mail.gmail.com> <12ADC240-877C-429C-BC41-DB137488015F@ccs.neu.edu> <6E44B2CE-1501-4197-8189-4577B8ED5422@gmail.com> <988E91FE-BDAC-41B2-8CA1-6F2CDC8EA816@ccs.neu.edu> <932b2f1f0906090631g322ff53m43c8dc2f9adc1e7b@mail.gmail.com> <932b2f1f0906090636j10cf542cs6491bc7e1c3581c1@mail.gmail.com> <932b2f1f0906090643o1d5bab42sb9915ec301e0ddb1@mail.gmail.com> Message-ID: Sorry, I understand that part. And I do want to turn DrScheme into an OS and Planet into a regular "software update" process so you can get the latest pieces when they are released. I just didnt understand the scenario that was dealt with. On Jun 9, 2009, at 9:43 AM, Robby Findler wrote: > Well, if you look at the larger picture of a community-wide > synchronized release of everything that is currently in planet, that > is clearly untenable. So there is some value in letting things move > independently. Another thing to compare to is OS releases. Perhaps we > should be spending more manpower on planet and everything outside of > mzscheme and a few core libraries should move there. Then, a major > release corresponds to picking a set of version numbers from planet > and packaging them into a single distributable. > > Robby > > On Tue, Jun 9, 2009 at 8:39 AM, Matthias > Felleisen wrote: >> >> Thanks. I understand that but I find the probability of such >> scenarios low. Perhaps it's a lack of experience with planet >> libraries. >> >> Eli just told me that SU isn't a part of the release yet, so my >> assumptions were wrong, too. >> >> I think it should be a part of the release and I have told Eli so. >> >> >> >> >> >> On Jun 9, 2009, at 9:36 AM, Robby Findler wrote: >> >>> I think the worry goes something like this: >>> >>> a) I use the plt web server and scheme unit (to pick two arbitrary >>> parts of the distribution, really this could be X and Y iiuc). >>> b) a new release comes out that has a bugfix in the web server >>> that I need >>> c) the new release also comes with backwards incompatibilities to >>> schemeunit that break my code that I don't have time at the >>> moment to >>> fix. >>> >>> What to do? Well, if I had used schemeunit from planet, I could >>> (probably) upgrade the webserver only, without upgrading schemeunit. >>> >>> Robby >>> >>> On Tue, Jun 9, 2009 at 8:33 AM, Matthias >>> Felleisen >>> wrote: >>>> >>>> Then I don't understand the exchange either. People who use an >>>> actual >>>> release (as opposed to the svn head) have a stable release of >>>> SU. When >>>> the next release comes out, they get a pre-compiled bundle, >>>> ready to >>>> install. >>>> >>>> Sorry for being dense -- Matthias >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Jun 9, 2009, at 9:31 AM, Robby Findler wrote: >>>> >>>>> I think the concern is for code that is being written by people >>>>> who >>>>> aren't working in our SVN repository. >>>>> >>>>> Robby >>>>> >>>>> On Tue, Jun 9, 2009 at 8:21 AM, Matthias >>>>> Felleisen >>>>> wrote: >>>>>> >>>>>> We routinely update collections in the core code base and most >>>>>> of the >>>>>> time, >>>>>> it suffices to run setup on the new collection or a few others. >>>>>> (Personally >>>>>> I often update my code base from scratch once a day.) >>>>>> >>>>>> I think it would be great if we got into this mode for SU, >>>>>> too. -- >>>>>> Matthias >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Jun 9, 2009, at 5:10 AM, Dave Gurnell wrote: >>>>>> >>>>>>> From an app developer's point of view, I think Noel's >>>>>>> reasoning is >>>>>>> this: >>>>>>> >>>>>>> All of PLT is bundled together under one big version number. >>>>>>> If you >>>>>>> upgrade the core, you upgrade all the satellite libraries as >>>>>>> well. >>>>>>> This >>>>>>> has >>>>>>> three drawbacks: >>>>>>> >>>>>>> - if you want to upgrade to a newer version of PLT for an >>>>>>> improvement >>>>>>> in >>>>>>> one library, you may have to deal with potential >>>>>>> backwards-incompatible >>>>>>> changes in other libraries at the same time; >>>>>>> >>>>>>> - compiling all of PLT can be slow; >>>>>>> >>>>>>> - other software you have developed may still use older >>>>>>> versions of >>>>>>> PLT. >>>>>>> >>>>>>> PLaneT offers a little more flexibility: to a certain degree >>>>>>> you can >>>>>>> choose to upgrade one dependency independently of the rest. >>>>>>> >>>>>>> In other words, if Noel makes a change to Schemeunit, and a >>>>>>> developer >>>>>>> is >>>>>>> requiring it from the core, he/she will have to update all of >>>>>>> PLT at >>>>>>> the >>>>>>> same time, which might take a while and make upgrading >>>>>>> difficult. If, >>>>>>> however, the developer is requiring Schemeunit from PLaneT, they >>>>>>> should >>>>>>> hopefully be able to just upgrade that one library and leave >>>>>>> everything >>>>>>> else >>>>>>> as-is. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> -- Dave >>>>>>> >>>>>>>> Noel, I don't understand this response at all. Could you >>>>>>>> elaborate? >>>>>>>> In >>>>>>>> the past we have deprecated planet package when we moved >>>>>>>> code into >>>>>>>> the >>>>>>>> core. >>>>>>>> -- Matthias >>>>>>>> >>>>>>>>> Dependency management. We've been bitten by changes in the web >>>>>>>>> server >>>>>>>>> stopping us upgrading PLT to get bug fixes in other areas. Now >>>>>>>>> SchemeUnit isn't as likely to change as the web server, but >>>>>>>>> why make >>>>>>>>> the dependency if you can avoid it? (This only applies if >>>>>>>>> you aren't >>>>>>>>> developing core code. If you are, use the core version.) >>>>>>>>> >>>>>>>>> N. >>>>>>>>> >>>>>>>>>> Why recommend the planet version over the core version? >>>>>>>>>> >>>>>>>>>> Robby >>>>>>>> >>>>>>> _________________________________________________ >>>>>>> For list-related administrative tasks: >>>>>>> http://list.cs.brown.edu/mailman/listinfo/plt-dev >>>>>> >>>>>> _________________________________________________ >>>>>> For list-related administrative tasks: >>>>>> http://list.cs.brown.edu/mailman/listinfo/plt-dev >>>>>> >>>> >>>> >> >> From d.j.gurnell at gmail.com Tue Jun 9 10:01:37 2009 From: d.j.gurnell at gmail.com (Dave Gurnell) Date: Tue Jun 9 10:02:14 2009 Subject: [plt-dev] Re: [plt-scheme] SchemeUnit confusion Message-ID: <5050B589-8A84-4F16-9B5E-0D912260918A@gmail.com> Noel beat me to it but... This is a fairly big problem for Untyped. We've spent a lot of time porting code to new versions of various libraries (the web server is the key one, although that's understandable given we're writing web apps), to get bug fixes in the core of mzscheme (continuations, threads, custodians etc). Forced upgrades have a nasty habit of coming just before deadlines, when we stress test software and find it crashes for one reason or another. There's also the knock-on effect that we end up running different versions of PLT for different applications for different customers. We've partially dealt with this by writing a bunch of shell scripts that let us switch back and forth between PLT versions on our dev boxes. FWIW, in the past we've always tried to stick fairly close to the head of PLT svn, which was not the best policy. We're now easing back from that, only upgrading when we have to, instead of when we simply like the look of a new feature. -- Dave > Thanks. I understand that but I find the probability of such > scenarios low. Perhaps it's a lack of experience with planet > libraries. > > Eli just told me that SU isn't a part of the release yet, so my > assumptions were wrong, too. > > I think it should be a part of the release and I have told Eli so. From robby at eecs.northwestern.edu Tue Jun 9 09:36:10 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Tue Jun 9 10:09:06 2009 Subject: [plt-dev] Re: [plt-scheme] SchemeUnit confusion In-Reply-To: References: <904774730906061815k1b921710h2385077107b26ba9@mail.gmail.com> <932b2f1f0906070539pc996511qa8c7d62e848de2c2@mail.gmail.com> <12ADC240-877C-429C-BC41-DB137488015F@ccs.neu.edu> <6E44B2CE-1501-4197-8189-4577B8ED5422@gmail.com> <988E91FE-BDAC-41B2-8CA1-6F2CDC8EA816@ccs.neu.edu> <932b2f1f0906090631g322ff53m43c8dc2f9adc1e7b@mail.gmail.com> Message-ID: <932b2f1f0906090636j10cf542cs6491bc7e1c3581c1@mail.gmail.com> I think the worry goes something like this: a) I use the plt web server and scheme unit (to pick two arbitrary parts of the distribution, really this could be X and Y iiuc). b) a new release comes out that has a bugfix in the web server that I need c) the new release also comes with backwards incompatibilities to schemeunit that break my code that I don't have time at the moment to fix. What to do? Well, if I had used schemeunit from planet, I could (probably) upgrade the webserver only, without upgrading schemeunit. Robby On Tue, Jun 9, 2009 at 8:33 AM, Matthias Felleisen wrote: > > Then I don't understand the exchange either. People who use an actual > release (as opposed to the svn head) have a stable release of SU. When > the next release comes out, they get a pre-compiled bundle, ready to > install. > > Sorry for being dense -- Matthias > > > > > > > On Jun 9, 2009, at 9:31 AM, Robby Findler wrote: > >> I think the concern is for code that is being written by people who >> aren't working in our SVN repository. >> >> Robby >> >> On Tue, Jun 9, 2009 at 8:21 AM, Matthias Felleisen >> wrote: >>> >>> We routinely update collections in the core code base and most of the >>> time, >>> it suffices to run setup on the new collection or a few others. >>> (Personally >>> I often update my code base from scratch once a day.) >>> >>> I think it would be great if we got into this mode for SU, too. -- >>> Matthias >>> >>> >>> >>> >>> >>> On Jun 9, 2009, at 5:10 AM, Dave Gurnell wrote: >>> >>>> From an app developer's point of view, I think Noel's reasoning is this: >>>> >>>> All of PLT is bundled together under one big version number. If you >>>> upgrade the core, you upgrade all the satellite libraries as well. This >>>> has >>>> three drawbacks: >>>> >>>> ?- if you want to upgrade to a newer version of PLT for an improvement >>>> in >>>> one library, you may have to deal with potential backwards-incompatible >>>> changes in other libraries at the same time; >>>> >>>> ?- compiling all of PLT can be slow; >>>> >>>> ?- other software you have developed may still use older versions of >>>> PLT. >>>> >>>> PLaneT offers a little more flexibility: to a certain degree you can >>>> choose to upgrade one dependency independently of the rest. >>>> >>>> In other words, if Noel makes a change to Schemeunit, and a developer is >>>> requiring it from the core, he/she will have to update all of PLT at the >>>> same time, which might take a while and make upgrading difficult. If, >>>> however, the developer is requiring Schemeunit from PLaneT, they should >>>> hopefully be able to just upgrade that one library and leave everything >>>> else >>>> as-is. >>>> >>>> Cheers, >>>> >>>> -- Dave >>>> >>>>> Noel, I don't understand this response at all. Could you elaborate? In >>>>> the past we have deprecated planet package when we moved code into the >>>>> core. >>>>> -- Matthias >>>>> >>>>>> Dependency management. We've been bitten by changes in the web server >>>>>> stopping us upgrading PLT to get bug fixes in other areas. Now >>>>>> SchemeUnit isn't as likely to change as the web server, but why make >>>>>> the dependency if you can avoid it? (This only applies if you aren't >>>>>> developing core code. If you are, use the core version.) >>>>>> >>>>>> N. >>>>>> >>>>>>> Why recommend the planet version over the core version? >>>>>>> >>>>>>> Robby >>>>> >>>> _________________________________________________ >>>> ?For list-related administrative tasks: >>>> ?http://list.cs.brown.edu/mailman/listinfo/plt-dev >>> >>> _________________________________________________ >>> ?For list-related administrative tasks: >>> ?http://list.cs.brown.edu/mailman/listinfo/plt-dev >>> > > From d.j.gurnell at gmail.com Tue Jun 9 10:08:59 2009 From: d.j.gurnell at gmail.com (Dave Gurnell) Date: Tue Jun 9 10:09:42 2009 Subject: [plt-dev] Re: [plt-scheme] SchemeUnit confusion In-Reply-To: References: <904774730906061815k1b921710h2385077107b26ba9@mail.gmail.com> <932b2f1f0906070539pc996511qa8c7d62e848de2c2@mail.gmail.com> <12ADC240-877C-429C-BC41-DB137488015F@ccs.neu.edu> <6E44B2CE-1501-4197-8189-4577B8ED5422@gmail.com> <988E91FE-BDAC-41B2-8CA1-6F2CDC8EA816@ccs.neu.edu> <932b2f1f0906090631g322ff53m43c8dc2f9adc1e7b@mail.gmail.com> <932b2f1f0906090636j10cf542cs6491bc7e1c3581c1@mail.gmail.com> <932b2f1f0906090643o1d5bab42sb9915ec301e0ddb1@mail.gmail.com> Message-ID: <8FABB046-4349-4215-91D3-FFDC4F15932A@gmail.com> Absolutely. So you could have something like: - libraries are all distributed as versioned packages; - a PLT distribution is a PLT core, plus a bunch of bundled core packages; - require statements pull packages from the default distribution by default, or from PLaneT if they're not present; - adding version numbers to require statements can pull newer versions of packages straight from PLaneT. Something like that anyway. I don't know if this is a correct or feasible approach. -- Dave > Sorry, I understand that part. And I do want to turn DrScheme > into an OS and Planet into a regular "software update" process > so you can get the latest pieces when they are released. > > I just didnt understand the scenario that was dealt with. > >> Well, if you look at the larger picture of a community-wide >> synchronized release of everything that is currently in planet, that >> is clearly untenable. So there is some value in letting things move >> independently. Another thing to compare to is OS releases. Perhaps we >> should be spending more manpower on planet and everything outside of >> mzscheme and a few core libraries should move there. Then, a major >> release corresponds to picking a set of version numbers from planet >> and packaging them into a single distributable. From d.j.gurnell at gmail.com Tue Jun 9 10:08:59 2009 From: d.j.gurnell at gmail.com (Dave Gurnell) Date: Tue Jun 9 10:13:08 2009 Subject: [plt-dev] Re: [plt-scheme] SchemeUnit confusion In-Reply-To: References: <904774730906061815k1b921710h2385077107b26ba9@mail.gmail.com> <932b2f1f0906070539pc996511qa8c7d62e848de2c2@mail.gmail.com> <12ADC240-877C-429C-BC41-DB137488015F@ccs.neu.edu> <6E44B2CE-1501-4197-8189-4577B8ED5422@gmail.com> <988E91FE-BDAC-41B2-8CA1-6F2CDC8EA816@ccs.neu.edu> <932b2f1f0906090631g322ff53m43c8dc2f9adc1e7b@mail.gmail.com> <932b2f1f0906090636j10cf542cs6491bc7e1c3581c1@mail.gmail.com> <932b2f1f0906090643o1d5bab42sb9915ec301e0ddb1@mail.gmail.com> Message-ID: <8FABB046-4349-4215-91D3-FFDC4F15932A@gmail.com> Absolutely. So you could have something like: - libraries are all distributed as versioned packages; - a PLT distribution is a PLT core, plus a bunch of bundled core packages; - require statements pull packages from the default distribution by default, or from PLaneT if they're not present; - adding version numbers to require statements can pull newer versions of packages straight from PLaneT. Something like that anyway. I don't know if this is a correct or feasible approach. -- Dave > Sorry, I understand that part. And I do want to turn DrScheme > into an OS and Planet into a regular "software update" process > so you can get the latest pieces when they are released. > > I just didnt understand the scenario that was dealt with. > >> Well, if you look at the larger picture of a community-wide >> synchronized release of everything that is currently in planet, that >> is clearly untenable. So there is some value in letting things move >> independently. Another thing to compare to is OS releases. Perhaps we >> should be spending more manpower on planet and everything outside of >> mzscheme and a few core libraries should move there. Then, a major >> release corresponds to picking a set of version numbers from planet >> and packaging them into a single distributable. From neil at neilvandyke.org Tue Jun 9 14:14:00 2009 From: neil at neilvandyke.org (Neil Van Dyke) Date: Tue Jun 9 14:14:34 2009 Subject: [plt-dev] Re: [plt-scheme] SchemeUnit confusion In-Reply-To: <5050B589-8A84-4F16-9B5E-0D912260918A@gmail.com> References: <5050B589-8A84-4F16-9B5E-0D912260918A@gmail.com> Message-ID: <4A2EA668.9090708@neilvandyke.org> Dave Gurnell wrote at 06/09/2009 10:01 AM: > We've partially dealt with this by writing a bunch of shell scripts > that let us switch back and forth between PLT versions on our dev boxes. Similar thing here. Though the makefiles for development and production all specify absolute paths to the appropriate "/usr/local/plt-" directory. > We're now easing back from that, only upgrading when we have to, > instead of when we simply like the look of a new feature. Similar thing here. I just advised a client that they could keep production systems at an earlier 4.x version for now, and just edit the makefile temporarily if they want to use 4.2 for the profiler or other improved development tools. -- http://www.neilvandyke.org/ From clements at brinckerhoff.org Wed Jun 10 13:51:20 2009 From: clements at brinckerhoff.org (John Clements) Date: Wed Jun 10 13:51:52 2009 Subject: [plt-dev] Possible addition to Guide? Message-ID: <30766A57-5B1F-418A-87A5-9F4BABB11AAA@brinckerhoff.org> I spent half an hour yesterday trying to read code from a file and expand it. I finally figured it out, but getting all my ducks in a row was more painful than expected. Perhaps we could add something like this to the Guide somewhere? Expanding the code in a file: #lang scheme (define (expand-from-file dir name) (parameterize ([current-load-relative-directory dir] ;; make sure the relative requires work [current-namespace (make-base-empty-namespace)] ;; a fresh namespace for expansion [read-accept-reader #t]) ;; to allow a #lang specification (namespace-require 'scheme) ;; get 'module' into the current namespace (call-with-input-file (build-path dir name) (lambda (port) (let ([raw-stx (read-syntax name port)]) ;; the raw syntax (expand raw-stx)))))) ;; pick some random file to expand: (expand-from-file "/Users/clements/plt/collects/stepper/" "stepper- tool.ss") 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/20090610/54f6ec3a/smime.bin From matthias at ccs.neu.edu Fri Jun 12 11:44:50 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Fri Jun 12 11:45:26 2009 Subject: [plt-dev] drscheme issues error messages Message-ID: <0784A67A-A450-47ED-8010-C389680AA252@ccs.neu.edu> I don't know yet where this is coming from (I am experimenting with error in BSL). procedure application: expected procedure, given: # (struct:exn:fail:contract:arity "procedure error: expects 2 arguments, given 1: \"traffic light expected, given: some other value \"" #) (no arguments) === context === /Users/matthias/plt/collects/mred/private/wxme/text.ss:482:2: on- default-event method in text% /Users/matthias/plt/collects/mred/private/wxme/editor-canvas.ss: 376:2: on-event method in editor-canvas% /Users/matthias/plt/collects/scheme/private/more-scheme.ss:155:2: call-with-break-parameterization /Users/matthias/plt/collects/scheme/private/more-scheme.ss:271:2: call-with-exception-handler From neil at neilvandyke.org Sat Jun 13 12:39:33 2009 From: neil at neilvandyke.org (Neil Van Dyke) Date: Sat Jun 13 12:40:10 2009 Subject: [plt-dev] reading symbols beginning with colon as keywords? Message-ID: <4A33D645.5030902@neilvandyke.org> How about symbols beginning with ":" be read as keywords, as if they began with "#:"? I want to use keyword arguments in my libraries, but "#:" is big and scary-looking, and a pain to type. I think this change would break very little old code, and any such old code could be updated pretty easily. -- http://www.neilvandyke.org/ From czhu at cs.utah.edu Sat Jun 13 19:55:00 2009 From: czhu at cs.utah.edu (Chongkai Zhu) Date: Sat Jun 13 19:55:30 2009 Subject: [plt-dev] reading symbols beginning with colon as keywords? In-Reply-To: <4A33D645.5030902@neilvandyke.org> References: <4A33D645.5030902@neilvandyke.org> Message-ID: <4A343C54.5040908@cs.utah.edu> You can do this on your own code with readtables: http://docs.plt-scheme.org/reference/readtables.html Chongkai Neil Van Dyke wrote: > How about symbols beginning with ":" be read as keywords, as if they > began with "#:"? > > I want to use keyword arguments in my libraries, but "#:" is big and > scary-looking, and a pain to type. > > I think this change would break very little old code, and any such old > code could be updated pretty easily. > From neil at neilvandyke.org Sat Jun 13 20:26:06 2009 From: neil at neilvandyke.org (Neil Van Dyke) Date: Sat Jun 13 20:33:41 2009 Subject: [plt-dev] reading symbols beginning with colon as keywords? In-Reply-To: <4A343C54.5040908@cs.utah.edu> References: <4A33D645.5030902@neilvandyke.org> <4A343C54.5040908@cs.utah.edu> Message-ID: <4A34439E.10602@neilvandyke.org> Thanks. The two limitations to this solution I see are: 1. My code would diverge further from "scheme/base", when I'm trying to stay close to it. 2. Other people would still have to either use "#:" or go through the same contortions themselves to diverge. Chongkai Zhu wrote at 06/13/2009 07:55 PM: > You can do this on your own code with readtables: > > http://docs.plt-scheme.org/reference/readtables.html > > Chongkai > > Neil Van Dyke wrote: >> How about symbols beginning with ":" be read as keywords, as if they >> began with "#:"? >> >> I want to use keyword arguments in my libraries, but "#:" is big and >> scary-looking, and a pain to type. >> >> I think this change would break very little old code, and any such >> old code could be updated pretty easily. >> > > From grettke at acm.org Sat Jun 13 22:26:32 2009 From: grettke at acm.org (Grant Rettke) Date: Sat Jun 13 22:26:50 2009 Subject: [plt-dev] reading symbols beginning with colon as keywords? In-Reply-To: <4A343C54.5040908@cs.utah.edu> References: <4A33D645.5030902@neilvandyke.org> <4A343C54.5040908@cs.utah.edu> Message-ID: <756daca50906131926x12852629g6d5e9b77acb9eeb0@mail.gmail.com> On Sat, Jun 13, 2009 at 6:55 PM, Chongkai Zhu wrote: > You can do this on your own code with readtables: If you put it in base you would lure Ruby programmers to PLT. From sperber at deinprogramm.de Sun Jun 14 09:17:21 2009 From: sperber at deinprogramm.de (Michael Sperber) Date: Sun Jun 14 09:27:31 2009 Subject: [plt-dev] reading symbols beginning with colon as keywords? In-Reply-To: <756daca50906131926x12852629g6d5e9b77acb9eeb0@mail.gmail.com> (Grant Rettke's message of "Sat, 13 Jun 2009 21:26:32 -0500") References: <4A33D645.5030902@neilvandyke.org> <4A343C54.5040908@cs.utah.edu> <756daca50906131926x12852629g6d5e9b77acb9eeb0@mail.gmail.com> Message-ID: Grant Rettke writes: > On Sat, Jun 13, 2009 at 6:55 PM, Chongkai Zhu wrote: >> You can do this on your own code with readtables: > > If you put it in base you would lure Ruby programmers to PLT. ... and lure some Scheme programmers away who use identifiers starting with a colon for other purposes. -- Cheers =8-} Mike Friede, V?lkerverst?ndigung und ?berhaupt blabla From mflatt at cs.utah.edu Sun Jun 14 09:34:24 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Sun Jun 14 09:34:47 2009 Subject: [plt-dev] reading symbols beginning with colon as keywords? In-Reply-To: <4A33D645.5030902@neilvandyke.org> References: <4A33D645.5030902@neilvandyke.org> Message-ID: <20090614133428.15FFC6500EE@mail-svr1.cs.utah.edu> At Sat, 13 Jun 2009 12:39:33 -0400, Neil Van Dyke wrote: > How about symbols beginning with ":" be read as keywords, as if they > began with "#:"? > > I want to use keyword arguments in my libraries, but "#:" is big and > scary-looking, and a pain to type. I don't think that "#:" is scary or a pain to type, and I like the way that it stands out a bit. But I respect your opinion, and I know that many others prefix a ":" prefix. Of course, there are also people who feel that a ":" suffix is the only sensible choice. (I don't know how big the various camps are. Just to satisfy my curiosity, I'll take a poll on the plt-scheme list.) I see no substantial technical advantage for any of the choices of syntax, but there's a significant advantage in picking just one. All else being equal, a single syntax makes the language easier to learn, documentation easier to read, parsers easier to implement and extend, etc. So, while I'm unsure that "#:" should be the syntax of keywords forever, I'm sure that I don't want to support an additional ":" prefix right now. From neil at neilvandyke.org Sun Jun 14 09:55:44 2009 From: neil at neilvandyke.org (Neil Van Dyke) Date: Sun Jun 14 09:56:25 2009 Subject: [plt-dev] reading symbols beginning with colon as keywords? In-Reply-To: <20090614133428.15FFC6500EE@mail-svr1.cs.utah.edu> References: <4A33D645.5030902@neilvandyke.org> <20090614133428.15FFC6500EE@mail-svr1.cs.utah.edu> Message-ID: <4A350160.4090501@neilvandyke.org> Matthew Flatt wrote at 06/14/2009 09:34 AM: > I see no substantial technical advantage for any of the choices of > syntax, but there's a significant advantage in picking just one. All > else being equal, a single syntax makes the language easier to learn, > documentation easier to read, parsers easier to implement and extend, > etc. So, while I'm unsure that "#:" should be the syntax of keywords > forever, I'm sure that I don't want to support an additional ":" prefix > right now. > While I think ":" is superior to "#:", I would not advocate switching to ":" if doing so meant breaking code that used "#:". Except perhaps in a major new PLT release (e.g., 5.0). -- http://www.neilvandyke.org/ From d.j.gurnell at gmail.com Mon Jun 15 04:50:03 2009 From: d.j.gurnell at gmail.com (Dave Gurnell) Date: Mon Jun 15 04:50:45 2009 Subject: [plt-dev] reading symbols beginning with colon as keywords? In-Reply-To: <4A350160.4090501@neilvandyke.org> References: <4A33D645.5030902@neilvandyke.org> <20090614133428.15FFC6500EE@mail-svr1.cs.utah.edu> <4A350160.4090501@neilvandyke.org> Message-ID: <662D3C4C-A2AA-41C3-8401-7A633A23796D@gmail.com> On 14 Jun 2009, at 14:55, Neil Van Dyke wrote: > Matthew Flatt wrote at 06/14/2009 09:34 AM: >> I see no substantial technical advantage for any of the choices of >> syntax, but there's a significant advantage in picking just one. All >> else being equal, a single syntax makes the language easier to learn, >> documentation easier to read, parsers easier to implement and extend, >> etc. So, while I'm unsure that "#:" should be the syntax of keywords >> forever, I'm sure that I don't want to support an additional ":" >> prefix >> right now. >> > > While I think ":" is superior to "#:", I would not advocate > switching to ":" if doing so meant breaking code that used "#:". > Except perhaps in a major new PLT release (e.g., 5.0). +1 to this. I wasn't a massive fan of '#:' initially, but it makes some kind of aesthetic sense along side other reader syntax like #t, #px, #s and so on. Changing things now (or in the future) for the sake of a single character would be lots of work for very little gain. From neil at neilvandyke.org Mon Jun 15 05:22:37 2009 From: neil at neilvandyke.org (Neil Van Dyke) Date: Mon Jun 15 05:23:16 2009 Subject: [plt-dev] reading symbols beginning with colon as keywords? In-Reply-To: <662D3C4C-A2AA-41C3-8401-7A633A23796D@gmail.com> References: <4A33D645.5030902@neilvandyke.org> <20090614133428.15FFC6500EE@mail-svr1.cs.utah.edu> <4A350160.4090501@neilvandyke.org> <662D3C4C-A2AA-41C3-8401-7A633A23796D@gmail.com> Message-ID: <4A3612DD.9040305@neilvandyke.org> Dave Gurnell wrote at 06/15/2009 04:50 AM: > Changing things now (or in the future) for the sake of a single > character would be lots of work for very little gain. My followup message was worded poorly. I'm not advocating *switching*. I would very much like ":" to be *added* a shorthand or alternative for "#:", while continuing to support "#:". (I appreciate the concern that the language not be bloated with two ways to do it, however, and I'm not sure how to resolve that.) Describing why I think "#:" is so bad is difficult when there's a wide range of inclinations towards the *visual* (as opposed to, say, the *verbal*). One tack that might work: should argument names visually dominate operation names? If someone has use of a facility with gaze-tracking, I think you can get at least a CS MS thesis out of this question, and then do your doctoral work on visual/perceptual and cognition aspects of programming language syntax. -- http://www.neilvandyke.org/ From hkBst at gentoo.org Mon Jun 15 08:36:03 2009 From: hkBst at gentoo.org (Marijn Schouten (hkBst)) Date: Mon Jun 15 08:52:03 2009 Subject: [plt-dev] drscheme executable linked to old libs Message-ID: <4A364033.6030307@gentoo.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm using plt-scheme-4.2. When starting drscheme, I get: $ drscheme /usr/bin/mred: error while loading shared libraries: libmzscheme3m-4.1.5.so: cannot open shared object file: No such file or directory 4.1.5 is the version I had installed while upgrading to 4.2. I had the same problem when upgrading to 4.1.5 from 4.1.4. The workaround is to install the upgrade twice. I don't run drscheme very often, so I don't know how far back the issue goes. I thought this was the same issue as the path issue reported wrt mac builds, but it remains unfixed on linux. Marijn - -- If you cannot read my mind, then listen to what I say. Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML , #gentoo-{lisp,ml} on FreeNode -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAko2QDMACgkQp/VmCx0OL2zNGwCeKhseTWMDl7rJl3DLS/lmxpe/ s3UAoMQctGetiDThXoNh2Eh8f/guJAIK =oFuz -----END PGP SIGNATURE----- From eli at barzilay.org Mon Jun 15 18:13:01 2009 From: eli at barzilay.org (Eli Barzilay) Date: Mon Jun 15 18:13:21 2009 Subject: [plt-dev] drscheme executable linked to old libs In-Reply-To: <4A364033.6030307@gentoo.org> References: <4A364033.6030307@gentoo.org> Message-ID: <18998.51053.85365.281070@winooski.ccs.neu.edu> On Jun 15, Marijn Schouten (hkBst) wrote: > I'm using plt-scheme-4.2. > When starting drscheme, I get: > > $ drscheme > /usr/bin/mred: error while loading shared libraries: libmzscheme3m-4.1.5.so: > cannot open shared object file: No such file or directory > > 4.1.5 is the version I had installed while upgrading to 4.2. I had the same > problem when upgrading to 4.1.5 from 4.1.4. The workaround is to > install the upgrade twice. I don't run drscheme very often, so I > don't know how far back the issue goes. > > I thought this was the same issue as the path issue reported wrt mac > builds, but it remains unfixed on linux. If this is due to that problem (using the mac ports thing), then it is likely to continue being a problem in this way because you have some stuff at /usr that should really be inside the PLT tree. In addition, I don't know if they fixed their build routine, or how. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From hkBst at gentoo.org Tue Jun 16 16:51:12 2009 From: hkBst at gentoo.org (Marijn Schouten (hkBst)) Date: Tue Jun 16 16:58:17 2009 Subject: [plt-dev] drscheme executable linked to old libs In-Reply-To: <18998.51053.85365.281070@winooski.ccs.neu.edu> References: <4A364033.6030307@gentoo.org> <18998.51053.85365.281070@winooski.ccs.neu.edu> Message-ID: <4A3805C0.2020603@gentoo.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eli Barzilay wrote: > On Jun 15, Marijn Schouten (hkBst) wrote: >> I'm using plt-scheme-4.2. >> When starting drscheme, I get: >> >> $ drscheme >> /usr/bin/mred: error while loading shared libraries: libmzscheme3m-4.1.5.so: >> cannot open shared object file: No such file or directory >> >> 4.1.5 is the version I had installed while upgrading to 4.2. I had the same >> problem when upgrading to 4.1.5 from 4.1.4. The workaround is to >> install the upgrade twice. I don't run drscheme very often, so I >> don't know how far back the issue goes. >> >> I thought this was the same issue as the path issue reported wrt mac >> builds, but it remains unfixed on linux. > > If this is due to that problem (using the mac ports thing), then it is > likely to continue being a problem in this way because you have some > stuff at /usr that should really be inside the PLT tree. In addition, > I don't know if they fixed their build routine, or how. > Well, the old installed version is at prefix /usr. The new version is compiled in a staging area (DESTDIR). The compilation process should use its own libraries instead of using the old installed ones. Marijn - -- If you cannot read my mind, then listen to what I say. Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML , #gentoo-{lisp,ml} on FreeNode -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAko4BcAACgkQp/VmCx0OL2yoRwCfVwKTsTGYE6+/JhGjllzXG+ub w+0AnjjyANWjsUKSeIRRZ4szWIgfMTsm =axBX -----END PGP SIGNATURE----- From eli at barzilay.org Tue Jun 16 17:08:06 2009 From: eli at barzilay.org (Eli Barzilay) Date: Tue Jun 16 17:08:27 2009 Subject: [plt-dev] drscheme executable linked to old libs In-Reply-To: <4A3805C0.2020603@gentoo.org> References: <4A364033.6030307@gentoo.org> <18998.51053.85365.281070@winooski.ccs.neu.edu> <4A3805C0.2020603@gentoo.org> Message-ID: <19000.2486.712322.630138@winooski.ccs.neu.edu> On Jun 16, Marijn Schouten (hkBst) wrote: > > Eli Barzilay wrote: > > On Jun 15, Marijn Schouten (hkBst) wrote: > >> I'm using plt-scheme-4.2. > >> When starting drscheme, I get: > >> > >> $ drscheme > >> /usr/bin/mred: error while loading shared libraries: > >> libmzscheme3m-4.1.5.so: cannot open shared object file: No such > >> file or directory > >> > >> 4.1.5 is the version I had installed while upgrading to 4.2. I > >> had the same problem when upgrading to 4.1.5 from 4.1.4. The > >> workaround is to install the upgrade twice. I don't run drscheme > >> very often, so I don't know how far back the issue goes. > >> > >> I thought this was the same issue as the path issue reported wrt > >> mac builds, but it remains unfixed on linux. > > > > If this is due to that problem (using the mac ports thing), then > > it is likely to continue being a problem in this way because you > > have some stuff at /usr that should really be inside the PLT tree. > > In addition, I don't know if they fixed their build routine, or > > how. > > Well, the old installed version is at prefix /usr. The new version > is compiled in a staging area (DESTDIR). The compilation process > should use its own libraries instead of using the old installed > ones. It should, but there are some issues with things in /usr that have precedence over things in the local build directory -- so AFAICT (from second-hand experience), the best way to deal with this is to manually remove all the bogus files in /usr. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From mflatt at cs.utah.edu Wed Jun 17 02:01:44 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Wed Jun 17 02:02:09 2009 Subject: [plt-dev] documentation slowing down installs and builds dramatically In-Reply-To: <932b2f1f0906010658t77653a0fw5f94bf8ee722d6cf@mail.gmail.com> References: <4A208F6A.1000405@neilvandyke.org> <36366a980905291847j60b7334ch20a8cf291fba14b3@mail.gmail.com> <4A220443.9050107@neilvandyke.org> <20090601135008.896786500CF@mail-svr1.cs.utah.edu> <932b2f1f0906010658t77653a0fw5f94bf8ee722d6cf@mail.gmail.com> Message-ID: <20090617060148.645936500A8@mail-svr1.cs.utah.edu> At Mon, 1 Jun 2009 08:58:46 -0500, Robby Findler wrote: > I think PLaneT does indeed work that way. Even worse, there is a bug > somewhere that causes CM to not compile package B (or C or D ...) > making things even worse. I got as far as figuring out that it was a > parameter that changed (I think it was the namespace?) that somehow > causes CM to disable itself, but I could not figure out what the right > fix was. I believe the right fix is to be using a new instantiation of > CM and the code seems to be doing that, but apparently it isn't. That doesn't seem to be a problem, actually. When A requires B, the "skipping" messages for B come from the outer CM for A, while an inner instance of CM is correctly compiling B. I changed `compiler/compiler-unit' slightly so that it "binds" the CM trace handler that it installs to a particular port, and that avoids the confusing printout. From robby at eecs.northwestern.edu Wed Jun 17 07:25:41 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Wed Jun 17 07:32:19 2009 Subject: [plt-dev] documentation slowing down installs and builds dramatically In-Reply-To: <20090617060148.645936500A8@mail-svr1.cs.utah.edu> References: <4A208F6A.1000405@neilvandyke.org> <36366a980905291847j60b7334ch20a8cf291fba14b3@mail.gmail.com> <4A220443.9050107@neilvandyke.org> <20090601135008.896786500CF@mail-svr1.cs.utah.edu> <932b2f1f0906010658t77653a0fw5f94bf8ee722d6cf@mail.gmail.com> <20090617060148.645936500A8@mail-svr1.cs.utah.edu> Message-ID: <932b2f1f0906170425v3fb2b5d0i2cf84f23488af559@mail.gmail.com> Oh! Thanks. Talk about a wild goose chase. So .. should planet be invoking setup-plt with flags that control the documentation generation more carefully in order to speed up things? Robby On Wed, Jun 17, 2009 at 1:01 AM, Matthew Flatt wrote: > At Mon, 1 Jun 2009 08:58:46 -0500, Robby Findler wrote: >> I think PLaneT does indeed work that way. Even worse, there is a bug >> somewhere that causes CM to not compile package B (or C or D ...) >> making things even worse. I got as far as figuring out that it was a >> parameter that changed (I think it was the namespace?) that somehow >> causes CM to disable itself, but I could not figure out what the right >> fix was. I believe the right fix is to be using a new instantiation of >> CM and the code seems to be doing that, but apparently it isn't. > > That doesn't seem to be a problem, actually. When A requires B, the > "skipping" messages for B come from the outer CM for A, while an inner > instance of CM is correctly compiling B. > > I changed `compiler/compiler-unit' slightly so that it "binds" the CM > trace handler that it installs to a particular port, and that avoids > the confusing printout. > > From cce at ccs.neu.edu Wed Jun 17 20:28:10 2009 From: cce at ccs.neu.edu (Carl Eastlund) Date: Wed Jun 17 20:28:50 2009 Subject: [plt-dev] symbol->string and mutability Message-ID: <990e0c030906171728x7413182eub1881d414a334de8@mail.gmail.com> Why do symbol->string and keyword->string produce mutable strings? In so doing, they have to allocate a new string every time. Is there any way to get at an immutable string that is not allocated more than once? I would prefer that this be the default behavior; R6RS already specifies that symbol->string produces an immutable string, for instance. --Carl From mflatt at cs.utah.edu Thu Jun 18 03:35:08 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Thu Jun 18 03:35:32 2009 Subject: [plt-dev] symbol->string and mutability In-Reply-To: <990e0c030906171728x7413182eub1881d414a334de8@mail.gmail.com> References: <990e0c030906171728x7413182eub1881d414a334de8@mail.gmail.com> Message-ID: <20090618073511.C372965012D@mail-svr1.cs.utah.edu> At Wed, 17 Jun 2009 20:28:10 -0400, Carl Eastlund wrote: > Why do symbol->string and keyword->string produce mutable strings? In > so doing, they have to allocate a new string every time. Is there any > way to get at an immutable string that is not allocated more than > once? I would prefer that this be the default behavior; R6RS already > specifies that symbol->string produces an immutable string, for > instance. Symbols and keywords are represented internally in UTF-8, while strings are represented internally as UTF-32. So, there's not an obvious way to have `symbol->string' avoid allocation, except by either caching a string reference in the symbol (probably not worth the extra space, since most symbols are never converted) or keeping a symbol-to-string mapping in a hash table (which any programmer can do externally). I think it would be a good idea to switch to an immutable-string result, but considering potential incompatibility, it has never seemed worthwhile in the short run. From robby at eecs.northwestern.edu Thu Jun 18 07:50:23 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Thu Jun 18 07:50:44 2009 Subject: [plt-dev] symbol->string and mutability In-Reply-To: <20090618073511.C372965012D@mail-svr1.cs.utah.edu> References: <990e0c030906171728x7413182eub1881d414a334de8@mail.gmail.com> <20090618073511.C372965012D@mail-svr1.cs.utah.edu> Message-ID: <932b2f1f0906180450k35211c7fk978c1d14b902c33d@mail.gmail.com> Just curious, but why the different representations? Is it because you don't need to be able to index into a symbol and thus utf-8's (usually) more compact representation is a win but for strings, where you do need to index into it, a simple computation (and avoiding searching?) makes UTF-32 the right choice? Robby On Thu, Jun 18, 2009 at 2:35 AM, Matthew Flatt wrote: > At Wed, 17 Jun 2009 20:28:10 -0400, Carl Eastlund wrote: >> Why do symbol->string and keyword->string produce mutable strings? ?In >> so doing, they have to allocate a new string every time. ?Is there any >> way to get at an immutable string that is not allocated more than >> once? ?I would prefer that this be the default behavior; R6RS already >> specifies that symbol->string produces an immutable string, for >> instance. > > Symbols and keywords are represented internally in UTF-8, while strings > are represented internally as UTF-32. So, there's not an obvious way to > have `symbol->string' avoid allocation, except by either caching a > string reference in the symbol (probably not worth the extra space, > since most symbols are never converted) or keeping a symbol-to-string > mapping in a hash table (which any programmer can do externally). > > I think it would be a good idea to switch to an immutable-string > result, but considering potential incompatibility, it has never seemed > worthwhile in the short run. > > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > From mflatt at cs.utah.edu Thu Jun 18 08:30:47 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Thu Jun 18 08:31:18 2009 Subject: [plt-dev] symbol->string and mutability In-Reply-To: <932b2f1f0906180450k35211c7fk978c1d14b902c33d@mail.gmail.com> References: <990e0c030906171728x7413182eub1881d414a334de8@mail.gmail.com> <20090618073511.C372965012D@mail-svr1.cs.utah.edu> <932b2f1f0906180450k35211c7fk978c1d14b902c33d@mail.gmail.com> Message-ID: <20090618123049.E01B6650131@mail-svr1.cs.utah.edu> Yes, exactly. At Thu, 18 Jun 2009 06:50:23 -0500, Robby Findler wrote: > Just curious, but why the different representations? Is it because you > don't need to be able to index into a symbol and thus utf-8's > (usually) more compact representation is a win but for strings, where > you do need to index into it, a simple computation (and avoiding > searching?) makes UTF-32 the right choice? > > Robby > > On Thu, Jun 18, 2009 at 2:35 AM, Matthew Flatt wrote: > > At Wed, 17 Jun 2009 20:28:10 -0400, Carl Eastlund wrote: > >> Why do symbol->string and keyword->string produce mutable strings? ?In > >> so doing, they have to allocate a new string every time. ?Is there any > >> way to get at an immutable string that is not allocated more than > >> once? ?I would prefer that this be the default behavior; R6RS already > >> specifies that symbol->string produces an immutable string, for > >> instance. > > > > Symbols and keywords are represented internally in UTF-8, while strings > > are represented internally as UTF-32. So, there's not an obvious way to > > have `symbol->string' avoid allocation, except by either caching a > > string reference in the symbol (probably not worth the extra space, > > since most symbols are never converted) or keeping a symbol-to-string > > mapping in a hash table (which any programmer can do externally). > > > > I think it would be a good idea to switch to an immutable-string > > result, but considering potential incompatibility, it has never seemed > > worthwhile in the short run. > > > > _________________________________________________ > > ?For list-related administrative tasks: > > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > > From cce at ccs.neu.edu Thu Jun 18 11:30:53 2009 From: cce at ccs.neu.edu (Carl Eastlund) Date: Thu Jun 18 11:31:32 2009 Subject: [plt-dev] symbol->string and mutability In-Reply-To: <20090618073511.C372965012D@mail-svr1.cs.utah.edu> References: <990e0c030906171728x7413182eub1881d414a334de8@mail.gmail.com> <20090618073511.C372965012D@mail-svr1.cs.utah.edu> Message-ID: <990e0c030906180830h5cd6bcaendf464800cabf9abe@mail.gmail.com> On Thu, Jun 18, 2009 at 3:35 AM, Matthew Flatt wrote: > At Wed, 17 Jun 2009 20:28:10 -0400, Carl Eastlund wrote: >> Why do symbol->string and keyword->string produce mutable strings? ?In >> so doing, they have to allocate a new string every time. ?Is there any >> way to get at an immutable string that is not allocated more than >> once? ?I would prefer that this be the default behavior; R6RS already >> specifies that symbol->string produces an immutable string, for >> instance. > > Symbols and keywords are represented internally in UTF-8, while strings > are represented internally as UTF-32. So, there's not an obvious way to > have `symbol->string' avoid allocation, except by either caching a > string reference in the symbol (probably not worth the extra space, > since most symbols are never converted) or keeping a symbol-to-string > mapping in a hash table (which any programmer can do externally). > > I think it would be a good idea to switch to an immutable-string > result, but considering potential incompatibility, it has never seemed > worthwhile in the short run. I see. I have contracts set up to accept only symbols and keywords whose names are ASCII strings; I was planning to use a weak, eq?-based hash of their names to shortcut the test. Apparently, though, I cannot get eq?-unique names for symbols and strings. If I hash the symbols and keywords themselves, I believe the weak table can never reclaim the space (since interned symbols and keywords are forgeable); if I use an equal? hash, it defeats the purpose. In the end, this is probably premature optimization; symbol and keyword names are usually short, so I can just use an unhashed check. However, while I'm musing out loud... would it be possible to have symbol->bytes and keyword->bytes that produce the UTF-8 representation (presumably with guarantees of uniqueness, immutability, and proper UTF-8 encoding)? --Carl From mflatt at cs.utah.edu Thu Jun 18 16:03:56 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Thu Jun 18 16:04:18 2009 Subject: [plt-dev] symbol->string and mutability In-Reply-To: <990e0c030906180830h5cd6bcaendf464800cabf9abe@mail.gmail.com> References: <990e0c030906171728x7413182eub1881d414a334de8@mail.gmail.com> <20090618073511.C372965012D@mail-svr1.cs.utah.edu> <990e0c030906180830h5cd6bcaendf464800cabf9abe@mail.gmail.com> Message-ID: <20090618200358.B43A565012B@mail-svr1.cs.utah.edu> At Thu, 18 Jun 2009 11:30:53 -0400, Carl Eastlund wrote: > On Thu, Jun 18, 2009 at 3:35 AM, Matthew Flatt wrote: > > At Wed, 17 Jun 2009 20:28:10 -0400, Carl Eastlund wrote: > >> Why do symbol->string and keyword->string produce mutable strings? ?In > >> so doing, they have to allocate a new string every time. ?Is there any > >> way to get at an immutable string that is not allocated more than > >> once? ?I would prefer that this be the default behavior; R6RS already > >> specifies that symbol->string produces an immutable string, for > >> instance. > > > > Symbols and keywords are represented internally in UTF-8, while strings > > are represented internally as UTF-32. So, there's not an obvious way to > > have `symbol->string' avoid allocation, except by either caching a > > string reference in the symbol (probably not worth the extra space, > > since most symbols are never converted) or keeping a symbol-to-string > > mapping in a hash table (which any programmer can do externally). > > > > I think it would be a good idea to switch to an immutable-string > > result, but considering potential incompatibility, it has never seemed > > worthwhile in the short run. > > I see. I have contracts set up to accept only symbols and keywords > whose names are ASCII strings; I was planning to use a weak, eq?-based > hash of their names to shortcut the test. Apparently, though, I > cannot get eq?-unique names for symbols and strings. If I hash the > symbols and keywords themselves, I believe the weak table can never > reclaim the space (since interned symbols and keywords are forgeable); No --- symbols and keywords are GCed, so a weak hash table would work. (And weakness in hash tables isn't about whether you could synthesize the key. We have `equal?'-based hash tables with weak keys, after all.) > However, while I'm musing out loud... would it be possible to have > symbol->bytes and keyword->bytes that produce the UTF-8 representation > (presumably with guarantees of uniqueness, immutability, and proper > UTF-8 encoding)? Do you mean that `symbol->bytes' would avoid allocation, which is possible because the symbol is UTF-8 encoded? If so, there's another part of the representation story that I left out last time. A symbol's content is "inlined" into the allocated symbol record, while a string or a byte string is a record containing a pointer to the string's characters. This difference has to do with C interoperability and a GC-based prohibition on pointers into the interior of an allocated object. So, there are many ways in which the current representations don't yield a cheap `symbol->bytes' operation. From cce at ccs.neu.edu Thu Jun 18 16:27:02 2009 From: cce at ccs.neu.edu (Carl Eastlund) Date: Thu Jun 18 16:29:08 2009 Subject: [plt-dev] symbol->string and mutability In-Reply-To: <20090618200358.B43A565012B@mail-svr1.cs.utah.edu> References: <990e0c030906171728x7413182eub1881d414a334de8@mail.gmail.com> <20090618073511.C372965012D@mail-svr1.cs.utah.edu> <990e0c030906180830h5cd6bcaendf464800cabf9abe@mail.gmail.com> <20090618200358.B43A565012B@mail-svr1.cs.utah.edu> Message-ID: <990e0c030906181327q1cbb87ccq7f75eb7de7b5f415@mail.gmail.com> On Thu, Jun 18, 2009 at 4:03 PM, Matthew Flatt wrote: >> >> I see. ?I have contracts set up to accept only symbols and keywords >> whose names are ASCII strings; I was planning to use a weak, eq?-based >> hash of their names to shortcut the test. ?Apparently, though, I >> cannot get eq?-unique names for symbols and strings. ?If I hash the >> symbols and keywords themselves, I believe the weak table can never >> reclaim the space (since interned symbols and keywords are forgeable); > > No --- symbols and keywords are GCed, so a weak hash table would work. > > (And weakness in hash tables isn't about whether you could synthesize > the key. We have `equal?'-based hash tables with weak keys, after all.) I see. I tried to demonstrate this one way or another to myself with a weak box containing a symbol and a call to collect-garbage, and the box never "emptied". Perhaps that experiment was not conclusive; maybe collect-garbage doesn't guarantee emptying of all weak boxes, or I had a reference to the symbol lying around somewhere I didn't know about. >> However, while I'm musing out loud... would it be possible to have >> symbol->bytes and keyword->bytes that produce the UTF-8 representation >> (presumably with guarantees of uniqueness, immutability, and proper >> UTF-8 encoding)? > > Do you mean that `symbol->bytes' would avoid allocation, which is > possible because the symbol is UTF-8 encoded? > > If so, there's another part of the representation story that I left out > last time. A symbol's content is "inlined" into the allocated symbol > record, while a string or a byte string is a record containing a > pointer to the string's characters. This difference has to do with C > interoperability and a GC-based prohibition on pointers into the > interior of an allocated object. So, there are many ways in which the > current representations don't yield a cheap `symbol->bytes' operation. I figured there might be something like that going on. Not a major issue, I will get along without this. --Carl From mflatt at cs.utah.edu Thu Jun 18 16:34:18 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Thu Jun 18 16:34:40 2009 Subject: [plt-dev] symbol->string and mutability In-Reply-To: <990e0c030906181327q1cbb87ccq7f75eb7de7b5f415@mail.gmail.com> References: <990e0c030906171728x7413182eub1881d414a334de8@mail.gmail.com> <20090618073511.C372965012D@mail-svr1.cs.utah.edu> <990e0c030906180830h5cd6bcaendf464800cabf9abe@mail.gmail.com> <20090618200358.B43A565012B@mail-svr1.cs.utah.edu> <990e0c030906181327q1cbb87ccq7f75eb7de7b5f415@mail.gmail.com> Message-ID: <20090618203420.973FA650148@mail-svr1.cs.utah.edu> At Thu, 18 Jun 2009 16:27:02 -0400, Carl Eastlund wrote: > On Thu, Jun 18, 2009 at 4:03 PM, Matthew Flatt wrote: > >> > >> I see. ?I have contracts set up to accept only symbols and keywords > >> whose names are ASCII strings; I was planning to use a weak, eq?-based > >> hash of their names to shortcut the test. ?Apparently, though, I > >> cannot get eq?-unique names for symbols and strings. ?If I hash the > >> symbols and keywords themselves, I believe the weak table can never > >> reclaim the space (since interned symbols and keywords are forgeable); > > > > No --- symbols and keywords are GCed, so a weak hash table would work. > > > > (And weakness in hash tables isn't about whether you could synthesize > > the key. We have `equal?'-based hash tables with weak keys, after all.) > > I see. I tried to demonstrate this one way or another to myself with > a weak box containing a symbol and a call to collect-garbage, and the > box never "emptied". Perhaps that experiment was not conclusive; > maybe collect-garbage doesn't guarantee emptying of all weak boxes, or > I had a reference to the symbol lying around somewhere I didn't know > about. I tried this in the MzScheme and DrScheme (module language) REPLs: > (define b (make-weak-box 'not-used-elsewhere)) > (weak-box-value b) not-used-elsewhere > (collect-garbage) > (weak-box-value b) #f Did you try the same thing? From cce at ccs.neu.edu Thu Jun 18 16:38:56 2009 From: cce at ccs.neu.edu (Carl Eastlund) Date: Thu Jun 18 16:39:34 2009 Subject: [plt-dev] symbol->string and mutability In-Reply-To: <20090618203420.973FA650148@mail-svr1.cs.utah.edu> References: <990e0c030906171728x7413182eub1881d414a334de8@mail.gmail.com> <20090618073511.C372965012D@mail-svr1.cs.utah.edu> <990e0c030906180830h5cd6bcaendf464800cabf9abe@mail.gmail.com> <20090618200358.B43A565012B@mail-svr1.cs.utah.edu> <990e0c030906181327q1cbb87ccq7f75eb7de7b5f415@mail.gmail.com> <20090618203420.973FA650148@mail-svr1.cs.utah.edu> Message-ID: <990e0c030906181338s6112a524i471ee284676e60ba@mail.gmail.com> On Thu, Jun 18, 2009 at 4:34 PM, Matthew Flatt wrote: >> > >> > No --- symbols and keywords are GCed, so a weak hash table would work. >> > >> > (And weakness in hash tables isn't about whether you could synthesize >> > the key. We have `equal?'-based hash tables with weak keys, after all.) >> >> I see. ?I tried to demonstrate this one way or another to myself with >> a weak box containing a symbol and a call to collect-garbage, and the >> box never "emptied". ?Perhaps that experiment was not conclusive; >> maybe collect-garbage doesn't guarantee emptying of all weak boxes, or >> I had a reference to the symbol lying around somewhere I didn't know >> about. > > I tried this in the MzScheme and DrScheme (module language) REPLs: > > ?> (define b (make-weak-box 'not-used-elsewhere)) > ?> (weak-box-value b) > ?not-used-elsewhere > ?> (collect-garbage) > ?> (weak-box-value b) > ?#f > > Did you try the same thing? Nope. I put the first line in the definitions window, which of course put the symbol in the compiled version of the module, thus preventing it from being GC'd. Oops. --Carl From czhu at cs.utah.edu Thu Jun 18 23:23:37 2009 From: czhu at cs.utah.edu (Chongkai Zhu) Date: Thu Jun 18 23:24:02 2009 Subject: [plt-dev] scribble with gui Message-ID: <4A3B04B9.1080209@cs.utah.edu> Hi all, I am writing a scribble document and part of the source code is: @(define my-eval (call-with-trusted-sandbox-configuration (lambda () (parameterize ((sandbox-output 'string) (sandbox-error-output 'string)) (make-evaluator 'scheme/base #:requires (list (if gui? 'scheme/gui/base 'scheme/base))))))) @examples[#:eval my-eval #|code that relies on scheme/gui/base|#] @(kill-evaluator my-eval) I put the scrbl file into a .plt file, and then install it inside DrScheme (which I assume will make gui available). But the generated doc suggests otherwise: The "@(define" part leaves nothing in the html file, which is right. The "@examples" part generates, after the input: reference to an identifier before its definition: image in module: 'program in red, which I assume is caused because 'scheme/gui/base is not required. Is this a bug, or did I do something wrong? More weirdly, after that the html file contains a line: # It seems to be the result of "@(kill-evaluator", but shouldn't that not be printed? Thanks, Chongkai From czhu at cs.utah.edu Fri Jun 19 02:09:16 2009 From: czhu at cs.utah.edu (Chongkai Zhu) Date: Fri Jun 19 02:09:42 2009 Subject: [plt-dev] another scribble question In-Reply-To: <4A3B04B9.1080209@cs.utah.edu> References: <4A3B04B9.1080209@cs.utah.edu> Message-ID: <4A3B2B8C.1040109@cs.utah.edu> Another question, in the info.ss file I specified a category for the `scribblings' field. The document is build, and can be searched. The index pape says "This is an installation- and user-specific listing, including documentation for installed PLaneT packages.", but still doesn't list my document under the category I specify. Seems to be a bug for me. Chongkai Chongkai Zhu wrote: > Hi all, > > I am writing a scribble document ... From robby at eecs.northwestern.edu Fri Jun 19 11:33:16 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Fri Jun 19 11:33:38 2009 Subject: [plt-dev] svn, more confusion Message-ID: <932b2f1f0906190833h5722cf5br7a1d20a09b64f84c@mail.gmail.com> I'd like to create a branch from a specific revision. I tried this: svn copy http://svn.plt-scheme.org/plt/trunk/collects/redex@14919 http://svn.plt-scheme.org/plt/branches/robby/redex-pat but got the usual "please give me your password" message which I now interpret as "something is broken". Does anyone know what I'm doing wrong? Thanks, Robby From ryanc at ccs.neu.edu Fri Jun 19 11:51:03 2009 From: ryanc at ccs.neu.edu (Ryan Culpepper) Date: Fri Jun 19 11:51:29 2009 Subject: [plt-dev] svn, more confusion In-Reply-To: <932b2f1f0906190833h5722cf5br7a1d20a09b64f84c@mail.gmail.com> References: <932b2f1f0906190833h5722cf5br7a1d20a09b64f84c@mail.gmail.com> Message-ID: <4A3BB3E7.9090708@ccs.neu.edu> Robby Findler wrote: > I'd like to create a branch from a specific revision. I tried this: > > svn copy http://svn.plt-scheme.org/plt/trunk/collects/redex@14919 > http://svn.plt-scheme.org/plt/branches/robby/redex-pat > > but got the usual "please give me your password" message which I now > interpret as "something is broken". > > Does anyone know what I'm doing wrong? I belive this is subversion horribly dropping the ball. There's a bug in clients 1.5 and later. I think this is the relevant bug report (although the symptoms they list are slightly different): http://subversion.tigris.org/issues/show_bug.cgi?id=3242 You should be able to do the URL to URL copy if you have an old version (1.4 and earlier) of svn around. Alternatively, you could update your WC to that revision and to a WC to URL copy; I think that should work. Eli: could this issue be added to the plt svn HOWTO page? Ryan From robby at eecs.northwestern.edu Fri Jun 19 12:44:03 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Fri Jun 19 12:44:25 2009 Subject: [plt-dev] svn, more confusion In-Reply-To: <0F01B363-0D11-466E-A6DA-3AE5CD659520@gmail.com> References: <932b2f1f0906190833h5722cf5br7a1d20a09b64f84c@mail.gmail.com> <0F01B363-0D11-466E-A6DA-3AE5CD659520@gmail.com> Message-ID: <932b2f1f0906190944p30ae58f6t521bb9ed36c542ae@mail.gmail.com> Just in case anyone else wants to do this, Dave helpfully supplied a workaround. (Note that I'm using svn v1.6.2, so this isn't fixed there yet.) Robby On Fri, Jun 19, 2009 at 10:40 AM, Dave Gurnell wrote: > > On 19 Jun 2009, at 16:33, Robby Findler wrote: > >> I'd like to create a branch from a specific revision. I tried this: >> >> svn copy http://svn.plt-scheme.org/plt/trunk/collects/redex@14919 >> http://svn.plt-scheme.org/plt/branches/robby/redex-pat >> >> but got the usual "please give me your password" message which I now >> interpret as "something is broken". >> >> Does anyone know what I'm doing wrong? > > I don't really understand the SVN command line so I tend to stick to what I > know. FWIW I'm fairly sure the following commands would work on the Untyped > SVN: > > cd /plt/branches/robby > svn copy -r14919 http://svn.plt-scheme.org/plt/trunk/collects/redex > redex-pat > svn commit redex-pat > > Cheers, > > -- Dave > > From pocmatos at gmail.com Fri Jun 19 14:20:22 2009 From: pocmatos at gmail.com (Paulo J. Matos) Date: Fri Jun 19 14:21:04 2009 Subject: [plt-dev] DrScheme in big screen is cut after col 285 Message-ID: <11b141710906191120k6e8a2dcew85dbd880cd171640@mail.gmail.com> Hi, It seems DrScheme 4.2 stops rendering after column 285. Is there a reason for this? [screenshot http://users.ecs.soton.ac.uk/pocm06r/screenshot.png] Cheers, -- Paulo Jorge Matos - pocmatos at gmail.com http://www.pmatos.net From eli at barzilay.org Mon Jun 22 03:46:13 2009 From: eli at barzilay.org (Eli Barzilay) Date: Mon Jun 22 03:46:35 2009 Subject: [plt-dev] in-place build directory (was re: build error with svn 14677) In-Reply-To: <20090622074403.GA59805@duncan.reilly.home> References: <990e0c030905011417h6b9f44c6odb431b68e2eea5c@mail.gmail.com> <990e0c030905011434n4c339d8ew90943ed9b9985ede@mail.gmail.com> <18939.32862.224200.550799@winooski.ccs.neu.edu> <990e0c030905011638g21c7d5c6u314d7df70f83e1c9@mail.gmail.com> <18939.36198.292304.565294@winooski.ccs.neu.edu> <2A8447F7-D69E-4D3E-94DC-C9E487F8B6E4@brinckerhoff.org> <18939.37296.812932.367171@winooski.ccs.neu.edu> <20090622074403.GA59805@duncan.reilly.home> Message-ID: <19007.14021.208291.429514@winooski.ccs.neu.edu> On Jun 22, Andrew Reilly wrote: > > If ./configure works now, that's really great, and I'll be happy to > simplify the port accordingly... [I'm two releases behind, now. > Sorry about that. Will try to find time to catch up.] Even if it does, it's better to build from a different directory. (And, IIUC, this applies to all autoconf-based applications.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From andrew-scheme at areilly.bpc-users.org Mon Jun 22 03:44:03 2009 From: andrew-scheme at areilly.bpc-users.org (Andrew Reilly) Date: Mon Jun 22 05:02:13 2009 Subject: [plt-dev] in-place build directory (was re: build error with svn 14677) In-Reply-To: <18939.37296.812932.367171@winooski.ccs.neu.edu> References: <990e0c030905011417h6b9f44c6odb431b68e2eea5c@mail.gmail.com> <990e0c030905011434n4c339d8ew90943ed9b9985ede@mail.gmail.com> <18939.32862.224200.550799@winooski.ccs.neu.edu> <990e0c030905011638g21c7d5c6u314d7df70f83e1c9@mail.gmail.com> <18939.36198.292304.565294@winooski.ccs.neu.edu> <2A8447F7-D69E-4D3E-94DC-C9E487F8B6E4@brinckerhoff.org> <18939.37296.812932.367171@winooski.ccs.neu.edu> Message-ID: <20090622074403.GA59805@duncan.reilly.home> Sorry for dredging up an old thread, but I'm just back from holidays and catching up on the list... On Fri, May 01, 2009 at 08:20:00PM -0400, Eli Barzilay wrote: > On May 1, John Clements wrote: > > So what? Does it matter if everyone creates a build directory? > > It only matters in being more complicated than it could be. You only > need a brief look at Matthew's version of the file to know that > > ./configure; make; make install > > should work as expected, and I think that it is desirable to keep this > property. (But just to clarify, the README file is something that > Matthew writes and maintains, so I don't want to commit a change that > I'm not willing to defend personally.) The FreeBSD port of plt-scheme goes to the additional effort of doing the mkdir src/build; cd build; ../configure; ... steps because back when I was creating it, build-in-place did *not* work. Something to do with tree-spanning paths in the xform step that I never did get to the bottom of: making ports use a separate build directory was much simpler. If ./configure works now, that's really great, and I'll be happy to simplify the port accordingly... [I'm two releases behind, now. Sorry about that. Will try to find time to catch up.] Cheers, -- Andrew From mflatt at cs.utah.edu Mon Jun 22 08:56:33 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Mon Jun 22 08:57:14 2009 Subject: [plt-dev] scribble with gui In-Reply-To: <4A3B04B9.1080209@cs.utah.edu> References: <4A3B04B9.1080209@cs.utah.edu> Message-ID: <20090622125635.6EA8A650108@mail-svr1.cs.utah.edu> At Fri, 19 Jun 2009 11:23:37 +0800, Chongkai Zhu wrote: > I am writing a scribble document and part of the source code is: > > @(define my-eval > (call-with-trusted-sandbox-configuration > (lambda () > (parameterize ((sandbox-output 'string) > (sandbox-error-output 'string)) > (make-evaluator 'scheme/base #:requires > (list (if gui? > 'scheme/gui/base > 'scheme/base))))))) > > @examples[#:eval my-eval > #|code that relies on scheme/gui/base|#] > > @(kill-evaluator my-eval) > > I put the scrbl file into a .plt file, and then install it inside > DrScheme (which I assume will make gui available). > But the generated doc suggests otherwise: > > The "@(define" part leaves nothing in the html file, which is right. > > The "@examples" part generates, after the input: > > reference to an identifier before its definition: > > image in module: 'program > > > in red, which I assume is caused because 'scheme/gui/base is not > required. Is this a bug, or did I do something wrong? `scheme/gui/base' is not available when setup-plt runs. The "Quick" document works around that by having two modes controlled through an environment variable: one where images are rendered to PNGs (to be run when scheme/gui' is available), and another that just uses the PNGs (to be used by setup-plt). > More weirdly, after that the html file contains a line: > > # > > It seems to be the result of "@(kill-evaluator", but shouldn't that not > be printed? The `scribble/doc' and `scribble/manual' languages do not currently ignore void results. Probably they should. Meanwhile, the `define' form didn't generate output because `defines' are specially lifted out of a document (i.e., it's not because `define' produces void). From mflatt at cs.utah.edu Mon Jun 22 08:56:40 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Mon Jun 22 08:57:18 2009 Subject: [plt-dev] another scribble question In-Reply-To: <4A3B2B8C.1040109@cs.utah.edu> References: <4A3B04B9.1080209@cs.utah.edu> <4A3B2B8C.1040109@cs.utah.edu> Message-ID: <20090622125642.2AEA065011B@mail-svr1.cs.utah.edu> It's difficult to guess what could be wrong. Can you supply an example? At Fri, 19 Jun 2009 14:09:16 +0800, Chongkai Zhu wrote: > Another question, in the info.ss file I specified a category for the > `scribblings' field. The document is build, and can be searched. The > index pape says "This is an installation- and user-specific listing, > including documentation for installed PLaneT packages.", but still > doesn't list my document under the category I specify. Seems to be a bug > for me. > > Chongkai > > Chongkai Zhu wrote: > > Hi all, > > > > I am writing a scribble document ... > > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From czhu at cs.utah.edu Mon Jun 22 21:48:46 2009 From: czhu at cs.utah.edu (Chongkai Zhu) Date: Mon Jun 22 21:49:18 2009 Subject: [plt-dev] scribble with gui In-Reply-To: <20090622125635.6EA8A650108@mail-svr1.cs.utah.edu> References: <4A3B04B9.1080209@cs.utah.edu> <20090622125635.6EA8A650108@mail-svr1.cs.utah.edu> Message-ID: <4A40347E.8000000@cs.utah.edu> Matthew Flatt wrote: > `scheme/gui/base' is not available when setup-plt runs. The "Quick" > document works around that by having two modes controlled through an > environment variable: one where images are rendered to PNGs (to be run > when scheme/gui' is available), and another that just uses the PNGs (to > be used by setup-plt). > Thanks. I found the doc here http://docs.plt-scheme.org/scriblib/gui-eval.html Chongkai From czhu at cs.utah.edu Tue Jun 23 00:05:26 2009 From: czhu at cs.utah.edu (Chongkai Zhu) Date: Tue Jun 23 00:07:09 2009 Subject: [plt-dev] another scribble question In-Reply-To: <20090622125642.2AEA065011B@mail-svr1.cs.utah.edu> References: <4A3B04B9.1080209@cs.utah.edu> <4A3B2B8C.1040109@cs.utah.edu> <20090622125642.2AEA065011B@mail-svr1.cs.utah.edu> Message-ID: <4A405486.6030104@cs.utah.edu> Attached is the example. Problems I see: 1. After just installing the .plt file, the document is build but not listed under "Interoperability" of the main-index. Install another .plt file (which also has a scribble doc) will list the document of the first .plt file, but not it's own document. 2. By installing the .plt file, the html file is correctly rendered. I also want to generate a local html file that links to http://doc.plt-scheme.org/. So I execute C:\Program Files\PLT-4.2.0.2>scribble.exe --html --redirect-main http://doc.plt-scheme.org/index.html docu.scrbl I get an docu.html file (also attached), but obviously the links are not correct. I also tried "scribble.exe --html docu.scrbl" and got the same result. What did I do wrong here? I'm using DrScheme, version 4.2.0.2-svn2jun2009 on Windows. Thanks, Chongkai Matthew Flatt wrote: > It's difficult to guess what could be wrong. Can you supply an example? > > At Fri, 19 Jun 2009 14:09:16 +0800, Chongkai Zhu wrote: > >> Another question, in the info.ss file I specified a category for the >> `scribblings' field. The document is build, and can be searched. The >> index pape says "This is an installation- and user-specific listing, >> including documentation for installed PLaneT packages.", but still >> doesn't list my document under the category I specify. Seems to be a bug >> for me. >> >> Chongkai >> >> Chongkai Zhu wrote: >> >>> Hi all, >>> >>> I am writing a scribble document ... >>> >> _________________________________________________ >> For list-related administrative tasks: >> http://list.cs.brown.edu/mailman/listinfo/plt-dev >> -------------- next part -------------- H4sIAAAAAAAAA4VSvW7bMBDeCegdDvIQuqgkt02WLs0DdCiQbEEGijpZRChSIY9xkaJ99h4l y7GHtAQECN/P/f/4fi+kVWPbKZABnxNGgl4ZmwJuQWoVEVZYSqdGRsuoQ2uBGCtZI5OblH7C wP/PyRPC+Br1gCzNbHabgPHESinLVZH917vdNj8mtHe9NZrOxUu2asm2yCZLVUCryLzgty1s aAUHP+IF02cmW6tMdybEI4iWG5Nro/wEt2G4RzNOPhCMyrhKe2uRq6kmFdDNfu4tOVK5V/yZ lfxzhODFm+4fhQu2C1muQUu4EIjeWHyXhrLzOtUzwtrP1zvxYWOV2wNDpm0tNiwoxO067jd8 VC4pWwg4Pdn7UFnVooV1T4VgLxmy+OvuaIR7Tvx7JjwNGKol0MOVtKadi8sy4/ax2SeTv7W8 RzARHGKHXZ39d7wVGlgJqvWJ4HbJ+nCqdfNRLtDou3xix7LmuC1f4Hb7yIH+MyDjel/HyNP5 dPPlNB2kNDWZItUWQnbYG4cwJ7k44zcu39Ck9swPRNPXpjkcDrWOdSI11Nil5o9+HVJzbjmb BVzx4s92BZIvwjjC4Kd8BIX4C1eLJJhyAwAA -------------- next part -------------- An HTML attachment was scrubbed... URL: http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090623/65deb2c1/docu.html From mflatt at cs.utah.edu Tue Jun 23 08:29:54 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Tue Jun 23 08:30:24 2009 Subject: [plt-dev] another scribble question In-Reply-To: <4A405486.6030104@cs.utah.edu> References: <4A3B04B9.1080209@cs.utah.edu> <4A3B2B8C.1040109@cs.utah.edu> <20090622125642.2AEA065011B@mail-svr1.cs.utah.edu> <4A405486.6030104@cs.utah.edu> Message-ID: <20090623122956.0D724650125@mail-svr1.cs.utah.edu> At Tue, 23 Jun 2009 12:05:26 +0800, Chongkai Zhu wrote: > 1. After just installing the .plt file, the document is build but not > listed under "Interoperability" of the main-index. For me, it's listed immediately after I install either through `setup-plt' or DrScheme. Can you send the install log, which may provide more hints? Also, are you working with a fresh user directory, so that opening documentation initially takes you to the installation-specific (but not user specific) help page, while opening documentation afterward takes you to the user-specific page? Or do you start out with at least a user-specific page, which is supposed to get updated? > 2. By installing the .plt file, the html file is correctly rendered. I > also want to generate a local html file that links to > http://doc.plt-scheme.org/. So I execute > > C:\Program Files\PLT-4.2.0.2>scribble.exe --html --redirect-main > http://doc.plt-scheme.org/index.html docu.scrbl > > I get an docu.html file (also attached), but obviously the links are not > correct. I also tried "scribble.exe --html docu.scrbl" and got the same > result. What did I do wrong here? Add ++xref-in setup/xref load-collections-xref to the `scribble' command line, so that it loads in the cross references that will be redirected. From czhu at cs.utah.edu Tue Jun 23 09:08:30 2009 From: czhu at cs.utah.edu (Chongkai Zhu) Date: Tue Jun 23 09:09:03 2009 Subject: [plt-dev] another scribble question In-Reply-To: <20090623122956.0D724650125@mail-svr1.cs.utah.edu> References: <4A3B04B9.1080209@cs.utah.edu> <4A3B2B8C.1040109@cs.utah.edu> <20090622125642.2AEA065011B@mail-svr1.cs.utah.edu> <4A405486.6030104@cs.utah.edu> <20090623122956.0D724650125@mail-svr1.cs.utah.edu> Message-ID: <4A40D3CE.5050107@cs.utah.edu> Matthew Flatt wrote: > At Tue, 23 Jun 2009 12:05:26 +0800, Chongkai Zhu wrote: > >> 1. After just installing the .plt file, the document is build but not >> listed under "Interoperability" of the main-index. >> > > For me, it's listed immediately after I install either through > `setup-plt' or DrScheme. Can you send the install log, which may > provide more hints? > > Attached. > Also, are you working with a fresh user directory, so that opening > documentation initially takes you to the installation-specific (but not > user specific) help page, while opening documentation afterward takes > you to the user-specific page? Or do you start out with at least a > user-specific page, which is supposed to get updated? > > I always mean "file:///C:/Documents%20and%20Settings/Chongkai%20Zhu/Application%20Data/PLT%20Scheme/4.2.0.2/doc/index.html". I never use "file:///C:/Program%20Files/PLT-4.2.0.2/doc/index.html". Maybe I should update to latest SVN? >> 2. By installing the .plt file, the html file is correctly rendered. I >> also want to generate a local html file that links to >> http://doc.plt-scheme.org/. So I execute >> >> C:\Program Files\PLT-4.2.0.2>scribble.exe --html --redirect-main >> http://doc.plt-scheme.org/index.html docu.scrbl >> >> I get an docu.html file (also attached), but obviously the links are not >> correct. I also tried "scribble.exe --html docu.scrbl" and got the same >> result. What did I do wrong here? >> > > Add > > ++xref-in setup/xref load-collections-xref > > to the `scribble' command line, so that it loads in the cross > references that will be redirected. > > Thanks. - Chongkai -------------- next part -------------- setup-plt: version: 4.2.0.2 [3m] setup-plt: variants: 3m setup-plt: main collects: C:\Program Files\PLT-4.2.0.2\collects setup-plt: collects paths: setup-plt: C:\Documents and Settings\Chongkai Zhu\Application Data\PLT Scheme\4.2.0.2\collects setup-plt: C:\Program Files\PLT-4.2.0.2\collects setup-plt: Unpacking scrbl test from C:\Program Files\PLT-4.2.0.2\scrbl-test.plt setup-plt: making directory scrbl-test in C:\Documents and Settings\Chongkai Zhu\Application Data\PLT Scheme\4.2.0.2\collects\ setup-plt: unpacking docu.scrbl in C:\Documents and Settings\Chongkai Zhu\Application Data\PLT Scheme\4.2.0.2\collects\scrbl-test\ setup-plt: unpacking info.ss in C:\Documents and Settings\Chongkai Zhu\Application Data\PLT Scheme\4.2.0.2\collects\scrbl-test\ setup-plt: --- pre-installing collections --- setup-plt: --- compiling collections --- setup-plt: making: /scrbl-test (scrbl test) setup-plt: in /scrbl-test setup-plt: --- updating info-domain tables --- setup-plt: updating: /info-domain/compiled/cache.ss setup-plt: --- building documentation --- setup-plt: using: /chongkai/sml.plt/1/2/ml.scrbl setup-plt: using: algol60/algol60.scrbl setup-plt: using: browser/browser.scrbl setup-plt: using: games/cards/cards.scrbl setup-plt: using: compiler/cffi.scrbl setup-plt: using: config/config.scrbl setup-plt: using: scribblings/drscheme/drscheme.scrbl setup-plt: using: dynext/dynext.scrbl setup-plt: using: embedded-gui/scribblings/embedded-gui.scrbl setup-plt: using: eopl/eopl.scrbl setup-plt: using: ffi/objc.scrbl setup-plt: using: scribblings/foreign/foreign.scrbl setup-plt: using: scribblings/framework/framework.scrbl setup-plt: using: frtime/frtime.scrbl setup-plt: using: games/scribblings/games.scrbl setup-plt: using: games/gl-board-game/gl-board-game.scrbl setup-plt: using: scribblings/gui/gui.scrbl setup-plt: using: scribblings/guide/guide.scrbl setup-plt: using: scribblings/honu/honu.scrbl setup-plt: using: scribblings/htdp-langs/htdp-langs.scrbl setup-plt: using: html/html.scrbl setup-plt: using: scribblings/inside/inside.scrbl setup-plt: using: lang/htdp-lib.scrbl setup-plt: using: lazy/lazy.scrbl setup-plt: using: macro-debugger/macro-debugger.scrbl setup-plt: using: scribblings/main/start.scrbl setup-plt: using: scribblings/main/user/start.scrbl setup-plt: using: scribblings/main/search.scrbl setup-plt: using: scribblings/main/master-index.scrbl setup-plt: using: scribblings/main/user/search.scrbl setup-plt: using: scribblings/main/user/master-index.scrbl setup-plt: using: scribblings/main/getting-started.scrbl setup-plt: using: scribblings/main/license.scrbl setup-plt: using: scribblings/main/acks.scrbl setup-plt: using: scribblings/main/release.scrbl setup-plt: using: make/make.scrbl setup-plt: using: scribblings/more/more.scrbl setup-plt: using: /mrmathematica/mrmma.scrbl setup-plt: using: mysterx/scribblings/mysterx.scrbl setup-plt: using: scribblings/mzc/mzc.scrbl setup-plt: using: mzcom/mzcom.scrbl setup-plt: using: mzscheme/mzscheme.scrbl setup-plt: using: openssl/openssl.scrbl setup-plt: using: parser-tools/parser-tools.scrbl setup-plt: using: planet/planet.scrbl setup-plt: using: plot/plot.scrbl setup-plt: using: preprocessor/scribblings/preprocessor.scrbl setup-plt: using: profj/scribblings/htdc.scrbl setup-plt: using: scribblings/quick/quick.scrbl setup-plt: using: r5rs/r5rs.scrbl setup-plt: using: r6rs/scribblings/r6rs.scrbl setup-plt: using: readline/readline.scrbl setup-plt: using: redex/redex.scrbl setup-plt: using: scribblings/reference/reference.scrbl setup-plt: running: /scrbl-test/docu.scrbl setup-plt: using: scribblings/scribble/scribble.scrbl setup-plt: using: scriblib/scribblings/scriblib.scrbl setup-plt: using: deinprogramm/scribblings/deinprogramm.scrbl setup-plt: using: profile/scribblings/profile.scrbl setup-plt: using: mrlib/scribblings/mrlib.scrbl setup-plt: using: net/scribblings/net.scrbl setup-plt: using: errortrace/scribblings/errortrace.scrbl setup-plt: using: mzlib/scribblings/mzlib.scrbl setup-plt: using: trace/scribblings/trace.scrbl setup-plt: using: graphics/scribblings/graphics.scrbl setup-plt: using: graphics/scribblings/turtles.scrbl setup-plt: using: file/scribblings/file.scrbl setup-plt: using: scribblings/setup-plt/setup-plt.scrbl setup-plt: using: sgl/scribblings/sgl.scrbl setup-plt: using: slatex/slatex-wrap.scrbl setup-plt: using: scribblings/slideshow/slideshow.scrbl setup-plt: using: srfi/srfi.scrbl setup-plt: using: string-constants/string-constants.scrbl setup-plt: using: stxclass/scribblings/stxclass.scrbl setup-plt: using: swindle/swindle.scrbl setup-plt: using: syntax/scribblings/syntax.scrbl setup-plt: using: syntax-color/syntax-color.scrbl setup-plt: using: teachpack/teachpack.scrbl setup-plt: using: test-box-recovery/test-box-recovery.scrbl setup-plt: using: test-engine/test-engine.scrbl setup-plt: using: scribblings/tools/tools.scrbl setup-plt: using: typed-scheme/ts-reference.scrbl setup-plt: using: typed-scheme/ts-guide.scrbl setup-plt: using: version/version.scrbl setup-plt: using: web-server/scribblings/web-server.scrbl setup-plt: using: web-server/scribblings/web-server-internal.scrbl setup-plt: using: web-server/scribblings/tutorial/continue.scrbl setup-plt: using: xml/xml.scrbl setup-plt: rendering: scribblings/main/user/start.scrbl setup-plt: rendering: scribblings/main/user/search.scrbl setup-plt: rendering: scribblings/main/user/master-index.scrbl setup-plt: rendering: /scrbl-test/docu.scrbl setup-plt: re-rendering: scribblings/main/user/master-index.scrbl setup-plt: --- creating launchers --- setup-plt: --- installing collections --- setup-plt: --- post-installing collections --- setup-plt: done From jay.mccarthy at gmail.com Wed Jun 24 14:35:46 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Wed Jun 24 14:36:07 2009 Subject: [plt-dev] struct match-expander a la struct-copy In-Reply-To: <18982.22329.172409.834089@winooski.ccs.neu.edu> References: <18982.22329.172409.834089@winooski.ccs.neu.edu> Message-ID: I experimented with this a little bit and didn't like it too much, because to do it right you get into strangeness with super structures. Can you think of some way around it? Here's an example: (define-struct crazy (car) #:transparent) (define-struct (kons crazy) (car cdr) #:transparent) (define make-kons/key (struct-keyword-constructor kons)) (make-kons/key #:crazy-car 0 #:kons-car 1 #:kons-cdr 2) Here's the code for struct-keyword-constructor: (require (for-syntax scheme/match scheme/list scheme/struct-info)) (define-for-syntax (fix-first l) (if (first l) l (rest l))) (define-syntax (struct-keyword-constructor stx) (syntax-case stx () [(_ struct-id) (unless (identifier? #'struct-id) (raise-syntax-error 'struct-keyword-constructor "Not an identifier" #'struct-id)) (match (syntax-local-value #'struct-id (lambda () (raise-syntax-error 'struct-keyword-constructor "Not bound syntax identifier" #'struct-id))) [(and (? struct-info?) (app extract-struct-info (list descriptor constructor predicate (list accessors-reversed ...) mutators super-type-info))) (define accessors (fix-first (reverse accessors-reversed))) (with-syntax ([formals (for/fold ([l empty]) ([a (in-list accessors-reversed)]) (if a (list* (string->keyword (symbol->string (syntax-e a))) a l) l))] [(field ...) accessors]) (quasisyntax/loc stx (lambda formals (#,constructor field ...))))] [else (raise-syntax-error 'struct-keyword-constructor "Not bound to structure info" #'struct-id)])])) Jay On Wed, Jun 3, 2009 at 4:58 AM, Eli Barzilay wrote: > On Jun ?2, Jay McCarthy wrote: >> The structure patterns in scheme/match have always bugged me that >> they didn't let you put the fields in any order and you had to put >> in _ for the fields you didn't care about. >> >> I've remedied this with a new match expander, struct*. I'd like to >> put in the tree. Do people agree? > > But the problem with that is that it's even farther away from the > syntax to create an instance. ?Ideally, I'd like to see options to > `define-struct' that can get you a keyword-based constructor instead > or in addition to the positional one. ?("In addition too" is a better > option, re the thread on renaming a constructor -- since you'll be > able to specify the name of each constructor.) ?Then define whatever > constructor was made as a match pattern too. ?Something like: > > ?(define-struct foo (x y) > ? ?#:positional-constructor make-foo1 > ? ?#:keyworded-cosntrutor make-foo2) > > ?(match ... > ? ?[(make-foo1 x y) ...] > ? ?;; or > ? ?[(make-foo2 #:x x #:y y) ...]) > > (But I'm not sure about the syntax to define this constructor, it > might be better to follow the syntax for functions: > > ?(define-struct foo (#:x x #:y y)) > > perhaps even use that to specify defaults. ?But there are cases where > you want both the positional and the keyworded versions...) > > -- > ? ? ? ? ?((lambda (x) (x x)) (lambda (x) (x x))) ? ? ? ? ?Eli Barzilay: > ? ? ? ? ? ? ? ? ?http://www.barzilay.org/ ? ? ? ? ? ? ? ? Maze is Life! > -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From jay.mccarthy at gmail.com Wed Jun 24 15:36:48 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Wed Jun 24 15:43:52 2009 Subject: [plt-dev] Re: struct match-expander a la struct-copy In-Reply-To: References: Message-ID: This is now in SVN available in scheme/match with tests and documentation. Jay On Tue, Jun 2, 2009 at 8:49 PM, Jay McCarthy wrote: > The structure patterns in scheme/match have always bugged me that they > didn't let you put the fields in any order and you had to put in _ for > the fields you didn't care about. > > I've remedied this with a new match expander, struct*. I'd like to put > in the tree. Do people agree? > > -- Use cases -- > > (define-struct super-tree (left right extra)) > > (define example1 > ?(make-super-tree 1 2 "And a pony!")) > > (match example1 > ?[(struct* super-tree > ? ? ? ? ? ?([left (? number? l)] > ? ? ? ? ? ? [right (? number? r)])) > ? (printf "All numbers! ~a ~a~n" l r)]) > > (match example1 > ?[(struct* super-tree > ? ? ? ? ? ?([right (? number? r)] > ? ? ? ? ? ? [left (? number? l)])) > ? (printf "Look ma, any order! ~a ~a~n" l r)]) > > (define-struct (even-better-tree super-tree) (more-extra-good)) > > (define example2 > ?(make-even-better-tree 1 2 "And a pony!" "And a giraffe!")) > > (match example2 > ?[(struct* super-tree > ? ? ? ? ? ?([left (? number? l)] > ? ? ? ? ? ? [right (? number? r)])) > ? (printf "All numbers! ~a ~a~n" l r)]) > > (match example2 > ?[(struct* even-better-tree > ? ? ? ? ? ?([more-extra-good (? string? m)])) > ? (printf "~a~n" m)]) > > -- Code & Test Cases -- > > #lang scheme > (require (for-syntax scheme/struct-info > ? ? ? ? ? ? ? ? ? ? syntax/boundmap > ? ? ? ? ? ? ? ? ? ? scheme/list)) > > (define-match-expander > ?struct* > ?(lambda (stx) > ? ?(syntax-case stx () > ? ? ?[(_ struct-name (field+pat ...)) > ? ? ? (let* ([fail (lambda () > ? ? ? ? ? ? ? ? ? ? ?(raise-syntax-error > ? ? ? ? ? ? ? ? ? ? ? 'struct* "not a structure definition" > ? ? ? ? ? ? ? ? ? ? ? stx #'struct-name))] > ? ? ? ? ? ? ?[v (syntax-local-value #'struct-name fail)] > ? ? ? ? ? ? ?[field-acc->pattern (make-free-identifier-mapping)]) > ? ? ? ? (unless (struct-info? v) (fail)) > ? ? ? ? ; Check each pattern and capture the field-accessor name > ? ? ? ? (for-each (lambda (an) > ? ? ? ? ? ? ? ? ? ? (syntax-case an () > ? ? ? ? ? ? ? ? ? ? ? [(field pat) > ? ? ? ? ? ? ? ? ? ? ? ?(unless (identifier? #'field) > ? ? ? ? ? ? ? ? ? ? ? ? ?(raise-syntax-error > ? ? ? ? ? ? ? ? ? ? ? ? ? 'struct* "not an identifier for field name" > ? ? ? ? ? ? ? ? ? ? ? ? ? stx #'field)) > ? ? ? ? ? ? ? ? ? ? ? ?(let ([field-acc > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (datum->syntax #'field > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(string->symbol > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (format "~a-~a" > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (syntax-e #'struct-name) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (syntax-e #'field))) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?#'field)]) > ? ? ? ? ? ? ? ? ? ? ? ? ?(when (free-identifier-mapping-get > field-acc->pattern field-acc (lambda () #f)) > ? ? ? ? ? ? ? ? ? ? ? ? ? ?(raise-syntax-error 'struct* "Field name > appears twice" stx #'field)) > ? ? ? ? ? ? ? ? ? ? ? ? ?(free-identifier-mapping-put! > field-acc->pattern field-acc #'pat))] > ? ? ? ? ? ? ? ? ? ? ? [_ > ? ? ? ? ? ? ? ? ? ? ? ?(raise-syntax-error > ? ? ? ? ? ? ? ? ? ? ? ? 'struct* "expected a field pattern of the > form ( )" > ? ? ? ? ? ? ? ? ? ? ? ? stx an)])) > ? ? ? ? ? ? ? ? ? (syntax->list #'(field+pat ...))) > ? ? ? ? (let* (; Get the structure info > ? ? ? ? ? ? ? ?[acc (fourth (extract-struct-info v))] > ? ? ? ? ? ? ? ?;; the accessors come in reverse order > ? ? ? ? ? ? ? ?[acc (reverse acc)] > ? ? ? ? ? ? ? ?;; remove the first element, if it's #f > ? ? ? ? ? ? ? ?[acc (cond [(empty? acc) acc] > ? ? ? ? ? ? ? ? ? ? ? ? ? [(not (first acc)) (rest acc)] > ? ? ? ? ? ? ? ? ? ? ? ? ? [else acc])] > ? ? ? ? ? ? ? ?; Order the patterns in the order of the accessors > ? ? ? ? ? ? ? ?[pats-in-order > ? ? ? ? ? ? ? ? (for/list ([field-acc (in-list acc)]) > ? ? ? ? ? ? ? ? ? (begin0 > ? ? ? ? ? ? ? ? ? ? (free-identifier-mapping-get > ? ? ? ? ? ? ? ? ? ? ?field-acc->pattern field-acc > ? ? ? ? ? ? ? ? ? ? ?(lambda () (syntax/loc stx _))) > ? ? ? ? ? ? ? ? ? ? ; Use up pattern > ? ? ? ? ? ? ? ? ? ? (free-identifier-mapping-put! > ? ? ? ? ? ? ? ? ? ? ?field-acc->pattern field-acc #f)))]) > ? ? ? ? ? ; Check that all patterns were used > ? ? ? ? ? (free-identifier-mapping-for-each > ? ? ? ? ? ?field-acc->pattern > ? ? ? ? ? ?(lambda (field-acc pat) > ? ? ? ? ? ? ?(when pat > ? ? ? ? ? ? ? ?(raise-syntax-error 'struct* "field name not > associated with given structure type" > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?stx field-acc)))) > ? ? ? ? ? (quasisyntax/loc stx > ? ? ? ? ? ? (struct struct-name #,pats-in-order))))]))) > > ; Comment out to test syntax errors > > ; Bad struct info id > #;(match example1 > ? ?[(struct* some-tree > ? ? ? ? ? ? ?([left (? number? l)] > ? ? ? ? ? ? ? [right (? number? r)])) > ? ? (printf "Just the facts: ~a ~a~n" > ? ? ? ? ? ? l r)]) > > ; Bad struct info > (define-for-syntax uncool-tree #f) > #;(match example1 > ? ?[(struct* uncool-tree > ? ? ? ? ? ? ?([left (? number? l)] > ? ? ? ? ? ? ? [right (? number? r)])) > ? ? (printf "Just the facts: ~a ~a~n" > ? ? ? ? ? ? l r)]) > > ; Bad syntax form > #;(match example1 > ? ?[(struct* super-tree > ? ? ? ? ? ? ?([foo] > ? ? ? ? ? ? ? [right (? number? r)])) > ? ? (printf "Just the facts: ~a ~a~n" > ? ? ? ? ? ? l r)]) > > ; Not an id for field > #;(match example1 > ? ?[(struct* super-tree > ? ? ? ? ? ? ?([(+ 1 1) (? number? l)] > ? ? ? ? ? ? ? [right (? number? r)])) > ? ? (printf "Just the facts: ~a ~a~n" > ? ? ? ? ? ? l r)]) > > ; Field appears twice > #;(match example1 > ? ?[(struct* super-tree > ? ? ? ? ? ? ?([right _] > ? ? ? ? ? ? ? [right (? number? r)])) > ? ? (printf "Just the facts: ~a~n" > ? ? ? ? ? ? r)]) > > ; Not a field id > #;(match example1 > ?[(struct* super-tree > ? ? ? ? ? ?([feet (? number?)] > ? ? ? ? ? ? [right (? number? r)])) > ? (printf "Just the facts: ~a~n" > ? ? ? ? ? r)]) > > ; Super structs don't work > #;(match example2 > ?[(struct* even-better-tree > ? ? ? ? ? ?([left (? number? l)] > ? ? ? ? ? ? [right (? number? r)] > ? ? ? ? ? ? [more-extra-good (? string? s)])) > ? (printf "All numbers (+ 1 string)! ~a ~a ~a~n" l r s)]) > > ; Super structs don't work > #;(match example2 > ?[(struct* even-better-tree > ? ? ? ? ? ?([left (? number? l)] > ? ? ? ? ? ? [extra (? string? e)] > ? ? ? ? ? ? [right (? number? r)] > ? ? ? ? ? ? [more-extra-good (? string? m)])) > ? (printf "All numbers (+ 2 strings)! ~a ~a ~a ~a~n" l e r m)]) > > -- > Jay McCarthy > Assistant Professor / Brigham Young University > http://teammccarthy.org/jay > > "The glory of God is Intelligence" - D&C 93 > -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From eli at barzilay.org Thu Jun 25 16:37:24 2009 From: eli at barzilay.org (Eli Barzilay) Date: Thu Jun 25 16:37:46 2009 Subject: [plt-dev] struct match-expander a la struct-copy In-Reply-To: References: <18982.22329.172409.834089@winooski.ccs.neu.edu> Message-ID: <19011.57348.57251.920660@winooski.ccs.neu.edu> On Jun 24, Jay McCarthy wrote: > I experimented with this a little bit and didn't like it too much, > because to do it right you get into strangeness with super > structures. Can you think of some way around it? Using (make-foo #:foo-x 1 #:foo-x 2) is of course bad. To make it analogous to function arguments you'd need to have user-supplied keywords, and the only tricky bit is that you also need to collect the keywords from a parent struct and throw an error if there are conflicts. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From robby at eecs.northwestern.edu Thu Jun 25 21:35:06 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Thu Jun 25 21:40:44 2009 Subject: [plt-dev] recent Redex developments Message-ID: <932b2f1f0906251835qcf6670ek17fa9e81309fcf5f@mail.gmail.com> New recently in Redex: - Redex's where patterns now accept the full pattern language of Redex (this is another source of ambiguity, of course, so it may also give rise to multiple ways that a rule may fire). - Added define-relation. This represents a relation as a function to booleans. define-relation definitions looks a lot like define-metafunction definitions, but it relaxes the constraint that there is only one case that applies and instead if any case produces #t, the relation is considered to hold. Also, there can be multiple expressions in the body of a single case; those must all hold for the case to hold. The intention is that this matches a little bit better relations that are written down in sequent style. (But do keep in mind that there are no fundamental changes here -- Redex cannot do any prolog-like search or anything like that). - The restriction that a metafunction definition has a single way for a pattern to match has been slightly relaxed; specifically if all of the ways that a pattern can decompose produce the same results, then no error is signalled. For example, that allows this definition of set minus: (define-language empty-language) (define-metafunction empty-language [(minus (any_1 ... any_2 any_3 ...) (any_2 any_4 ...)) (minus (any_1 ... any_3 ...) (any_2 any_4 ...))] [(minus (any_1 ...) (any_2 any_3 ...)) (minus (any_1 ...) (any_3 ...))] [(minus (any_1 ...) ()) (any_1 ...)]) whereas in the previous versions, this call: (term (minus (1 1 1) (1))) would have signalled an error. Robby From robby at eecs.northwestern.edu Thu Jun 25 22:28:23 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Thu Jun 25 22:28:44 2009 Subject: [plt-dev] Re: recent Redex developments In-Reply-To: <932b2f1f0906251835qcf6670ek17fa9e81309fcf5f@mail.gmail.com> References: <932b2f1f0906251835qcf6670ek17fa9e81309fcf5f@mail.gmail.com> Message-ID: <932b2f1f0906251928m503aa8gb4cb2d8df07eed77@mail.gmail.com> Oh -- and I should have pointed out that the where change is a backwards incompatible change. Specifically, if you used a variable in a where clause before that wasn't a non-terminal, Redex now treats that like a literal (just like in other patterns). I hope this won't cause too much confusion. Robby On Thu, Jun 25, 2009 at 8:35 PM, Robby Findler wrote: > New recently in Redex: > > - Redex's where patterns now accept the full pattern language of Redex > (this is another source of ambiguity, of course, so it may also give > rise to multiple ways that a rule may fire). > > - Added define-relation. This represents a relation as a function to > booleans. define-relation definitions looks a lot like > define-metafunction definitions, but it relaxes the constraint that > there is only one case that applies and instead if any case produces > #t, the relation is considered to hold. Also, there can be multiple > expressions in the body of a single case; those must all hold for the > case to hold. The intention is that this matches a little bit better > relations that are written down in sequent style. (But do keep in mind > that there are no fundamental changes here -- Redex cannot do any > prolog-like search or anything like that). > > - The restriction that a metafunction definition has a single way for > a pattern to match has been slightly relaxed; specifically if all of > the ways that a pattern can decompose produce the same results, then > no error is signalled. For example, that allows this definition of set > minus: > > (define-language empty-language) > (define-metafunction empty-language > ?[(minus (any_1 ... any_2 any_3 ...) (any_2 any_4 ...)) > ? (minus (any_1 ... any_3 ...) (any_2 any_4 ...))] > ?[(minus (any_1 ...) (any_2 any_3 ...)) > ? (minus (any_1 ...) (any_3 ...))] > ?[(minus (any_1 ...) ()) > ? (any_1 ...)]) > > whereas in the previous versions, this call: (term (minus (1 1 1) > (1))) would have signalled an error. > > Robby > From czhu at cs.utah.edu Fri Jun 26 07:14:18 2009 From: czhu at cs.utah.edu (Chongkai Zhu) Date: Fri Jun 26 07:14:41 2009 Subject: [plt-dev] defmodulelang and planet Message-ID: <4A44AD8A.6060804@cs.utah.edu> How do I defmodulelang a planet language? I tried @defmodulelang[(planet id)] but the result was #lang (planet id) which has an extra pair of parenthesis. Also, will @schememod[planet id] link "id" to the "defmodulelang" part? Thanks, Chongkai