From grettke at acm.org Sun Mar 1 11:45:18 2009 From: grettke at acm.org (Grant Rettke) Date: Sun Mar 1 11:45:37 2009 Subject: [plt-dev] Errors with SRFI-1 in R6RS mode that are not in #scheme mode in PLT 4.1.4.3-svn13feb2009 Message-ID: <756daca50903010845n3d7cdc82sa54fd4494795a5a3@mail.gmail.com> I am getting errors with SRFI-1 in R6RS mode that are not in #scheme mode in: Welcome to DrScheme, version 4.1.4.3-svn13feb2009 [3m]. #lang scheme (require (only-in srfi/1 split-at take drop)) (take '(a b c d e) 2) ; => (a b) (drop '(a b c d e) 2) ; => (c d e) (split-at '(a b c d e) 2) ; => expecting ;(values (take '(a b c d e) 2) (drop '(a b c d e) 2) >(a b) >(c d e) >(a b) >(c d e) This does not: #!r6rs (import (rnrs base) (only (srfi :1) split-at take drop)) (take '(a b c d e) 2) ; => (a b) (drop '(a b c d e) 2) ; => (c d e) (split-at '(a b c d e) 2) ; => expecting ;(values (take '(a b c d e) 2) (drop '(a b c d e) 2) >take: index 2 too large for list (not a proper list): {a b c d e}2 >drop: index 2 too large for list (not a proper list): {a b c d e}2 >take: index 2 too large for list (not a proper list): {a b c d e}2 What am I doing wrong? From eli at barzilay.org Sun Mar 1 11:53:49 2009 From: eli at barzilay.org (Eli Barzilay) Date: Sun Mar 1 11:54:09 2009 Subject: [plt-dev] Errors with SRFI-1 in R6RS mode that are not in #scheme mode in PLT 4.1.4.3-svn13feb2009 In-Reply-To: <756daca50903010845n3d7cdc82sa54fd4494795a5a3@mail.gmail.com> References: <756daca50903010845n3d7cdc82sa54fd4494795a5a3@mail.gmail.com> Message-ID: <18858.48541.172955.800723@winooski.ccs.neu.edu> On Mar 1, Grant Rettke wrote: > > This does not: > > #!r6rs > > (import (rnrs base) > (only (srfi :1) split-at take drop)) > > (take '(a b c d e) 2) ; => (a b) > (drop '(a b c d e) 2) ; => (c d e) > (split-at '(a b c d e) 2) ; => expecting > ;(values (take '(a b c d e) 2) (drop '(a b > c d e) 2) > > >take: index 2 too large for list (not a proper list): {a b c d e}2 > >drop: index 2 too large for list (not a proper list): {a b c d e}2 > >take: index 2 too large for list (not a proper list): {a b c d e}2 > > What am I doing wrong? Mutable lists are not `list?', so you get the same error as if you did (take "blah" 2). (BTW, such messages like this are more fitting to the main list.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From vyzo at media.mit.edu Sun Mar 1 12:45:31 2009 From: vyzo at media.mit.edu (Dimitris Vyzovitis) Date: Sun Mar 1 12:45:54 2009 Subject: [plt-dev] Hunting down an elusive certification bug In-Reply-To: <20090228223945.C698E6500A8@mail-svr1.cs.utah.edu> References: <887D54C9-70A3-45C7-B120-A33842BD0EE2@cs.utah.edu> <20090228223945.C698E6500A8@mail-svr1.cs.utah.edu> Message-ID: On Sat, 28 Feb 2009, Matthew Flatt wrote: > At Sat, 28 Feb 2009 15:45:11 -0500 (EST), Dimitris Vyzovitis wrote: >> Where foo is syntax-local-value looked up as a macro, and then called >> on the syntax (directly, as a function without local expand). >> The result is deconstructed as #'(pat ...) > > That sounds like the problem. When you call a transformer directly, > then you're taking on the role of the macro expander, and you're > obligated to do all the same sort of things that the expander does. > > If `local-expand' applies, but if you need to pull a syntax-object > vector apart, then my guess is that the deconstruction is still going > to cause certificate problems. You might be able to avoid the > certificate problem by expecting a `begin' form back instead of a > vector --- just because `local-expand' by default pushes certificates > down one level when it see a `begin' form. > > The more general solution is to do what the macro expander does, which > is to record a certifier along with the transformer and use it on the > result, possibly use `syntax-recertify' on pieces that you pull apart, > and so on. You can see examples of this in `match' (look for > `match-expander-transform' in the implementation) and `for'. > Unfortunately, this is all a bit complex, but that's the trade-off in > implementing your own sub-expander. This seems to work with minimum pain: Expansion for splice with: ... (let ((intro (make-syntax-introducer))) (syntax-local-introduce (intro (macro (intro (syntax-local-introduce stx)))))) Where the splicing macro is defined capturing the certifier: ... (let (cert (syntax-local-certifier)) (lambda (x) (syntax-case x () ((_ arg ...) (with-syntax (((body (... ...)) (list (cert (syntax rule)) ...))) (syntax/loc x (body (... ...)))))))))) -- vyzo From dherman at ccs.neu.edu Sun Mar 1 13:08:49 2009 From: dherman at ccs.neu.edu (Dave Herman) Date: Sun Mar 1 13:09:27 2009 Subject: [plt-dev] Should Check Syntax work on R6RS library files? In-Reply-To: <756daca50902281555y1d307380k89edd9d6bcfc9c91@mail.gmail.com> References: <756daca50902280513h26efc24cjd12b69b79b950f52@mail.gmail.com> <0075BBC8D2D943A9B15FA3907F134C6A@uw2b2dff239c4d> <756daca50902280707h1a3a6f30r4e30f8c371d88095@mail.gmail.com> <3D9872BF2E574C1A9F9DF8CAB778215B@uw2b2dff239c4d> <756daca50902281246t6bebf6a1l5b1d9724de054190@mail.gmail.com> <756daca50902281555y1d307380k89edd9d6bcfc9c91@mail.gmail.com> Message-ID: <49AACF31.5050104@ccs.neu.edu> You know about `struct-out' as well, right? http://docs.plt-scheme.org/reference/require.html#(form._((lib._scheme/base..ss)._struct-out)) Dave Grant Rettke wrote: >> How does that help you with the renaming with a syntax? >> You confuse me. > > In R6RS constructor and getter/setter methods are generated for you by > define-record-type; but you have to manually enter all of them for > exports. When you rename the records, then, you have to search-replace > to correct all of your exports. > > In #lang scheme you can use the export spec (all-defined-out) so you > don't have to worry about manually entering all of those exports. > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From grettke at acm.org Sun Mar 1 13:15:04 2009 From: grettke at acm.org (Grant Rettke) Date: Sun Mar 1 13:15:26 2009 Subject: [plt-dev] Should Check Syntax work on R6RS library files? In-Reply-To: <49AACF31.5050104@ccs.neu.edu> References: <756daca50902280513h26efc24cjd12b69b79b950f52@mail.gmail.com> <0075BBC8D2D943A9B15FA3907F134C6A@uw2b2dff239c4d> <756daca50902280707h1a3a6f30r4e30f8c371d88095@mail.gmail.com> <3D9872BF2E574C1A9F9DF8CAB778215B@uw2b2dff239c4d> <756daca50902281246t6bebf6a1l5b1d9724de054190@mail.gmail.com> <756daca50902281555y1d307380k89edd9d6bcfc9c91@mail.gmail.com> <49AACF31.5050104@ccs.neu.edu> Message-ID: <756daca50903011015t2c4edb37m53fb5555faa818c8@mail.gmail.com> > You know about `struct-out' as well, right? > > http://docs.plt-scheme.org/reference/require.html#(form._((lib._scheme/base..ss)._struct-out)) Thank you Dave. From vyzo at media.mit.edu Tue Mar 3 14:31:33 2009 From: vyzo at media.mit.edu (Dimitris Vyzovitis) Date: Tue Mar 3 14:31:54 2009 Subject: [plt-dev] thread-specifics [PATCH] Message-ID: The attached patch adds two new atomic primitives implementing thread-specifics: (thread-get-specific thread? (undefined (lambda () #f)) -> any? Retrieve the specific value from a thread. The optional undefined thunk is used to provide a value when the specific has not been set by the target thread. (thread-set-specific! any?) -> void Set the specific value for the current thread. These primitives are useful for communicating publicly visible information and simplify common synchronization patterns. Some simple examples in the test module [thread-specific.ss]: async: an asynchronous computation wrapper around threads. tagged: a state machine that tags its current state. my-thread: a synchronous thread spawner that places an ownership mark. test run: > (require "test-threadsp.ss") > (run-tests) (sync (async a1)) => 1 ; correct (exn? v2) => #t ; correct (thread-get-specific tag) => b1 ; correct (thread-get-specific tag) => b2 ; correct (thread-get-specific tag) => b3 ; correct (my-thread? (thread void) mark) => #f ; correct (my-thread? (my-thread void mark) mark) => #t ; correct -- vyzo -------------- next part -------------- Index: mzscheme/include/scheme.h =================================================================== --- mzscheme/include/scheme.h (revision 13918) +++ mzscheme/include/scheme.h (working copy) @@ -1090,6 +1090,8 @@ Scheme_Object *mbox_last; Scheme_Object *mbox_sema; + Scheme_Object *specific; + #ifdef MZ_PRECISE_GC struct GC_Thread_Info *gc_info; /* managed by the GC */ #endif Index: mzscheme/src/mzmark.c =================================================================== --- mzscheme/src/mzmark.c (revision 13918) +++ mzscheme/src/mzmark.c (working copy) @@ -1693,6 +1693,8 @@ gcMARK(pr->mbox_first); gcMARK(pr->mbox_last); gcMARK(pr->mbox_sema); + + gcMARK(pr->specific); return gcBYTES_TO_WORDS(sizeof(Scheme_Thread)); } @@ -1803,6 +1805,8 @@ gcFIXUP(pr->mbox_first); gcFIXUP(pr->mbox_last); gcFIXUP(pr->mbox_sema); + + gcFIXUP(pr->specific); return gcBYTES_TO_WORDS(sizeof(Scheme_Thread)); } Index: mzscheme/src/thread.c =================================================================== --- mzscheme/src/thread.c (revision 13918) +++ mzscheme/src/thread.c (working copy) @@ -2325,6 +2325,8 @@ process->mbox_last = NULL; process->mbox_sema = NULL; + process->specific = NULL; + process->mref = NULL; process->extra_mrefs = NULL; Index: mzscheme/src/mzmarksrc.c =================================================================== --- mzscheme/src/mzmarksrc.c (revision 13918) +++ mzscheme/src/mzmarksrc.c (working copy) @@ -706,6 +706,8 @@ gcMARK(pr->mbox_first); gcMARK(pr->mbox_last); gcMARK(pr->mbox_sema); + + gcMARK(pr->specific); size: gcBYTES_TO_WORDS(sizeof(Scheme_Thread)); } Index: mzscheme/src/sema.c =================================================================== --- mzscheme/src/sema.c (revision 13918) +++ mzscheme/src/sema.c (working copy) @@ -44,6 +44,9 @@ static Scheme_Object *thread_receive_evt(int n, Scheme_Object **p); static Scheme_Object *thread_rewind_receive(int n, Scheme_Object **p); +static Scheme_Object *thread_get_specific(int n, Scheme_Object **p); +static Scheme_Object *thread_set_specific(int n, Scheme_Object **p); + static Scheme_Object *make_alarm(int n, Scheme_Object **p); static Scheme_Object *make_sys_idle(int n, Scheme_Object **p); @@ -170,6 +173,17 @@ 1, 1), env); + scheme_add_global_constant("thread-get-specific", + scheme_make_prim_w_arity(thread_get_specific, + "thread-get-specific", + 1, 2), + env); + scheme_add_global_constant("thread-set-specific!", + scheme_make_prim_w_arity(thread_set_specific, + "thread-set-specific!", + 1, 1), + env); + scheme_add_global_constant("alarm-evt", scheme_make_prim_w_arity(make_alarm, "alarm-evt", @@ -1207,6 +1221,33 @@ } /**********************************************************************/ +/* Thread specifics */ +/**********************************************************************/ +static Scheme_Object *thread_get_specific(int argc, Scheme_Object **argv) +{ + if (SCHEME_THREADP(argv[0])) { + Scheme_Thread *p = (Scheme_Thread*)argv[0]; + if (argc > 1) + scheme_check_proc_arity2("thread-get-specific", 0, 1, argc, argv, 1); + + if (p->specific) + return p->specific; + else if (argc > 1) + return _scheme_tail_apply(argv[1], 0, NULL); + else return scheme_false; + } else + scheme_wrong_type("thread-get-specific", "thread", 0, argc, argv); + + return NULL; +} + +static Scheme_Object *thread_set_specific(int argc, Scheme_Object **argv) +{ + scheme_current_thread->specific = argv[0]; + return scheme_void; +} + +/**********************************************************************/ /* alarms */ /**********************************************************************/ Index: mzscheme/src/schminc.h =================================================================== --- mzscheme/src/schminc.h (revision 13918) +++ mzscheme/src/schminc.h (working copy) @@ -11,9 +11,9 @@ EXPECTED_PRIM_COUNT to the new value, and then USE_COMPILED_STARTUP can be set to 1 again. */ -#define USE_COMPILED_STARTUP 1 +#define USE_COMPILED_STARTUP 0 -#define EXPECTED_PRIM_COUNT 947 +#define EXPECTED_PRIM_COUNT 949 #ifdef MZSCHEME_SOMETHING_OMITTED # undef USE_COMPILED_STARTUP Index: mzscheme/src/cstartup.inc =================================================================== --- mzscheme/src/cstartup.inc (revision 13918) +++ mzscheme/src/cstartup.inc (working copy) @@ -1,560 +0,0 @@ - { - static MZCOMPILED_STRING_FAR unsigned char expr[] = {35,126,7,52,46,49,46,52,46,50,50,0,0,0,1,0,0,3,0,12,0, -17,0,20,0,27,0,40,0,47,0,51,0,58,0,63,0,68,0,72,0,78, -0,92,0,106,0,109,0,115,0,119,0,121,0,132,0,134,0,148,0,155,0, -177,0,179,0,193,0,253,0,23,1,32,1,41,1,51,1,87,1,126,1,165, -1,234,1,42,2,130,2,194,2,199,2,219,2,110,3,130,3,181,3,247,3, -132,4,34,5,84,5,107,5,186,5,0,0,132,7,0,0,29,11,11,68,104, -101,114,101,45,115,116,120,64,99,111,110,100,62,111,114,66,108,101,116,114,101, -99,72,112,97,114,97,109,101,116,101,114,105,122,101,66,117,110,108,101,115,115, -63,108,101,116,66,100,101,102,105,110,101,64,119,104,101,110,64,108,101,116,42, -63,97,110,100,65,113,117,111,116,101,29,94,2,13,68,35,37,107,101,114,110, -101,108,11,29,94,2,13,68,35,37,112,97,114,97,109,122,11,62,105,102,65, -98,101,103,105,110,63,115,116,120,61,115,70,108,101,116,45,118,97,108,117,101, -115,61,120,73,108,101,116,114,101,99,45,118,97,108,117,101,115,66,108,97,109, -98,100,97,1,20,112,97,114,97,109,101,116,101,114,105,122,97,116,105,111,110, -45,107,101,121,61,118,73,100,101,102,105,110,101,45,118,97,108,117,101,115,98, -10,35,11,8,134,228,94,159,2,15,35,35,159,2,14,35,35,16,20,2,3, -2,1,2,5,2,1,2,6,2,1,2,7,2,1,2,8,2,1,2,9,2, -1,2,10,2,1,2,4,2,1,2,11,2,1,2,12,2,1,97,36,11,8, -134,228,93,159,2,14,35,36,16,2,2,2,161,2,1,36,2,2,2,1,2, -2,97,10,11,11,8,134,228,16,0,97,10,37,11,8,134,228,16,0,13,16, -4,35,29,11,11,2,1,11,18,16,2,99,64,104,101,114,101,8,31,8,30, -8,29,8,28,8,27,93,8,224,13,57,0,0,95,9,8,224,13,57,0,0, -2,1,27,248,22,135,4,23,196,1,249,22,128,4,80,158,38,35,251,22,75, -2,16,248,22,90,23,200,2,12,249,22,65,2,17,248,22,92,23,202,1,27, -248,22,135,4,23,196,1,249,22,128,4,80,158,38,35,251,22,75,2,16,248, -22,90,23,200,2,249,22,65,2,17,248,22,92,23,202,1,12,27,248,22,67, -248,22,135,4,23,197,1,28,248,22,73,23,194,2,20,15,159,36,35,36,28, -248,22,73,248,22,67,23,195,2,248,22,66,193,249,22,128,4,80,158,38,35, -251,22,75,2,16,248,22,66,23,200,2,249,22,65,2,12,248,22,67,23,202, -1,11,18,16,2,101,10,8,31,8,30,8,29,8,28,8,27,16,4,11,11, -2,18,3,1,7,101,110,118,57,55,57,53,16,4,11,11,2,19,3,1,7, -101,110,118,57,55,57,54,93,8,224,14,57,0,0,95,9,8,224,14,57,0, -0,2,1,27,248,22,67,248,22,135,4,23,197,1,28,248,22,73,23,194,2, -20,15,159,36,35,36,28,248,22,73,248,22,67,23,195,2,248,22,66,193,249, -22,128,4,80,158,38,35,250,22,75,2,20,248,22,75,249,22,75,248,22,75, -2,21,248,22,66,23,202,2,251,22,75,2,16,2,21,2,21,249,22,65,2, -4,248,22,67,23,205,1,18,16,2,101,11,8,31,8,30,8,29,8,28,8, -27,16,4,11,11,2,18,3,1,7,101,110,118,57,55,57,56,16,4,11,11, -2,19,3,1,7,101,110,118,57,55,57,57,93,8,224,15,57,0,0,95,9, -8,224,15,57,0,0,2,1,248,22,135,4,193,27,248,22,135,4,194,249,22, -65,248,22,75,248,22,66,196,248,22,67,195,27,248,22,67,248,22,135,4,23, -197,1,249,22,128,4,80,158,38,35,28,248,22,53,248,22,129,4,248,22,66, -23,198,2,27,249,22,2,32,0,89,162,8,44,36,42,9,222,33,39,248,22, -135,4,248,22,90,23,200,2,250,22,75,2,22,248,22,75,249,22,75,248,22, -75,248,22,66,23,204,2,250,22,76,2,23,249,22,2,22,66,23,204,2,248, -22,92,23,206,2,249,22,65,248,22,66,23,202,1,249,22,2,22,90,23,200, -1,250,22,76,2,20,249,22,2,32,0,89,162,8,44,36,46,9,222,33,40, -248,22,135,4,248,22,66,201,248,22,67,198,27,248,22,135,4,194,249,22,65, -248,22,75,248,22,66,196,248,22,67,195,27,248,22,67,248,22,135,4,23,197, -1,249,22,128,4,80,158,38,35,250,22,76,2,22,249,22,2,32,0,89,162, -8,44,36,46,9,222,33,42,248,22,135,4,248,22,66,201,248,22,67,198,27, -248,22,67,248,22,135,4,196,27,248,22,135,4,248,22,66,195,249,22,128,4, -80,158,39,35,28,248,22,73,195,250,22,76,2,20,9,248,22,67,199,250,22, -75,2,8,248,22,75,248,22,66,199,250,22,76,2,11,248,22,67,201,248,22, -67,202,27,248,22,67,248,22,135,4,23,197,1,27,249,22,1,22,79,249,22, -2,22,135,4,248,22,135,4,248,22,66,199,249,22,128,4,80,158,39,35,251, -22,75,1,22,119,105,116,104,45,99,111,110,116,105,110,117,97,116,105,111,110, -45,109,97,114,107,2,24,250,22,76,1,23,101,120,116,101,110,100,45,112,97, -114,97,109,101,116,101,114,105,122,97,116,105,111,110,21,95,1,27,99,111,110, -116,105,110,117,97,116,105,111,110,45,109,97,114,107,45,115,101,116,45,102,105, -114,115,116,11,2,24,201,250,22,76,2,20,9,248,22,67,203,27,248,22,67, -248,22,135,4,23,197,1,28,248,22,73,23,194,2,20,15,159,36,35,36,249, -22,128,4,80,158,38,35,27,248,22,135,4,248,22,66,23,198,2,28,249,22, -164,8,62,61,62,248,22,129,4,248,22,90,23,197,2,250,22,75,2,20,248, -22,75,249,22,75,21,93,2,25,248,22,66,199,250,22,76,2,3,249,22,75, -2,25,249,22,75,248,22,99,203,2,25,248,22,67,202,251,22,75,2,16,28, -249,22,164,8,248,22,129,4,248,22,66,23,201,2,64,101,108,115,101,10,248, -22,66,23,198,2,250,22,76,2,20,9,248,22,67,23,201,1,249,22,65,2, -3,248,22,67,23,203,1,100,8,31,8,30,8,29,8,28,8,27,16,4,11, -11,2,18,3,1,7,101,110,118,57,56,50,49,16,4,11,11,2,19,3,1, -7,101,110,118,57,56,50,50,93,8,224,16,57,0,0,18,16,2,158,94,10, -64,118,111,105,100,8,47,95,9,8,224,16,57,0,0,2,1,27,248,22,67, -248,22,135,4,196,249,22,128,4,80,158,38,35,28,248,22,53,248,22,129,4, -248,22,66,197,250,22,75,2,26,248,22,75,248,22,66,199,248,22,90,198,27, -248,22,129,4,248,22,66,197,250,22,75,2,26,248,22,75,248,22,66,197,250, -22,76,2,23,248,22,67,199,248,22,67,202,159,35,20,103,159,35,16,1,11, -16,0,83,158,41,20,100,143,69,35,37,109,105,110,45,115,116,120,2,1,11, -10,11,10,35,80,158,35,35,20,103,159,35,16,0,16,0,11,11,16,1,2, -2,36,16,0,35,16,0,35,11,11,38,35,11,11,16,10,2,3,2,4,2, -5,2,6,2,7,2,8,2,9,2,10,2,11,2,12,16,10,11,11,11,11, -11,11,11,11,11,11,16,10,2,3,2,4,2,5,2,6,2,7,2,8,2, -9,2,10,2,11,2,12,35,45,36,11,11,16,0,16,0,16,0,35,35,11, -11,11,16,0,16,0,16,0,35,35,16,11,16,5,2,2,20,15,159,35,35, -35,35,20,103,159,35,16,0,16,1,33,32,10,16,5,2,7,89,162,8,44, -36,52,9,223,0,33,33,35,20,103,159,35,16,1,2,2,16,0,11,16,5, -2,10,89,162,8,44,36,52,9,223,0,33,34,35,20,103,159,35,16,1,2, -2,16,0,11,16,5,2,12,89,162,8,44,36,52,9,223,0,33,35,35,20, -103,159,35,16,1,2,2,16,1,33,36,11,16,5,2,4,89,162,8,44,36, -55,9,223,0,33,37,35,20,103,159,35,16,1,2,2,16,1,33,38,11,16, -5,2,8,89,162,8,44,36,57,9,223,0,33,41,35,20,103,159,35,16,1, -2,2,16,0,11,16,5,2,5,89,162,8,44,36,52,9,223,0,33,43,35, -20,103,159,35,16,1,2,2,16,0,11,16,5,2,11,89,162,8,44,36,53, -9,223,0,33,44,35,20,103,159,35,16,1,2,2,16,0,11,16,5,2,6, -89,162,8,44,36,54,9,223,0,33,45,35,20,103,159,35,16,1,2,2,16, -0,11,16,5,2,3,89,162,8,44,36,57,9,223,0,33,46,35,20,103,159, -35,16,1,2,2,16,1,33,48,11,16,5,2,9,89,162,8,44,36,53,9, -223,0,33,49,35,20,103,159,35,16,1,2,2,16,0,11,16,0,94,2,14, -2,15,93,2,14,9,9,35,0}; - EVAL_ONE_SIZED_STR((char *)expr, 2045); - } - { - static MZCOMPILED_STRING_FAR unsigned char expr[] = {35,126,7,52,46,49,46,52,46,50,59,0,0,0,1,0,0,13,0,18,0, -35,0,50,0,68,0,84,0,94,0,112,0,132,0,148,0,166,0,197,0,226, -0,248,0,6,1,12,1,26,1,31,1,41,1,49,1,77,1,109,1,154,1, -199,1,223,1,6,2,8,2,65,2,155,3,196,3,31,5,135,5,239,5,100, -6,114,6,148,6,164,6,14,8,28,8,191,8,192,9,192,10,199,10,206,10, -213,10,88,11,101,11,56,12,158,12,171,12,193,12,145,13,49,14,121,15,129, -15,137,15,163,15,18,16,0,0,6,19,0,0,72,112,97,116,104,45,115,116, -114,105,110,103,63,64,98,115,98,115,76,110,111,114,109,97,108,45,99,97,115, -101,45,112,97,116,104,74,45,99,104,101,99,107,45,114,101,108,112,97,116,104, -77,45,99,104,101,99,107,45,99,111,108,108,101,99,116,105,111,110,75,99,111, -108,108,101,99,116,105,111,110,45,112,97,116,104,69,45,102,105,110,100,45,99, -111,108,77,99,104,101,99,107,45,115,117,102,102,105,120,45,99,97,108,108,79, -112,97,116,104,45,114,101,112,108,97,99,101,45,115,117,102,102,105,120,75,112, -97,116,104,45,97,100,100,45,115,117,102,102,105,120,77,108,111,97,100,47,117, -115,101,45,99,111,109,112,105,108,101,100,1,29,102,105,110,100,45,108,105,98, -114,97,114,121,45,99,111,108,108,101,99,116,105,111,110,45,112,97,116,104,115, -1,27,112,97,116,104,45,108,105,115,116,45,115,116,114,105,110,103,45,62,112, -97,116,104,45,108,105,115,116,1,20,102,105,110,100,45,101,120,101,99,117,116, -97,98,108,101,45,112,97,116,104,73,101,109,98,101,100,100,101,100,45,108,111, -97,100,65,113,117,111,116,101,29,94,2,16,68,35,37,112,97,114,97,109,122, -11,64,108,111,111,112,69,101,120,101,99,45,102,105,108,101,67,119,105,110,100, -111,119,115,6,25,25,112,97,116,104,32,111,114,32,118,97,108,105,100,45,112, -97,116,104,32,115,116,114,105,110,103,6,29,29,126,97,58,32,105,110,118,97, -108,105,100,32,114,101,108,97,116,105,118,101,32,112,97,116,104,58,32,126,115, -6,42,42,126,97,58,32,99,111,108,108,101,99,116,105,111,110,32,110,111,116, -32,102,111,117,110,100,58,32,126,115,32,105,110,32,97,110,121,32,111,102,58, -32,126,115,6,42,42,112,97,116,104,32,40,102,111,114,32,97,110,121,32,115, -121,115,116,101,109,41,32,111,114,32,118,97,108,105,100,45,112,97,116,104,32, -115,116,114,105,110,103,6,21,21,115,116,114,105,110,103,32,111,114,32,98,121, -116,101,32,115,116,114,105,110,103,6,36,36,99,97,110,110,111,116,32,97,100, -100,32,97,32,115,117,102,102,105,120,32,116,111,32,97,32,114,111,111,116,32, -112,97,116,104,58,32,5,0,27,20,14,159,80,158,36,50,250,80,158,39,51, -249,22,27,11,80,158,41,50,22,182,12,10,248,22,157,5,23,196,2,28,248, -22,154,6,23,194,2,12,87,94,248,22,168,8,23,194,1,248,80,159,37,53, -36,195,28,248,22,73,23,195,2,9,27,248,22,66,23,196,2,27,28,248,22, -163,13,23,195,2,23,194,1,28,248,22,162,13,23,195,2,249,22,164,13,23, -196,1,250,80,158,42,48,248,22,178,13,2,19,11,10,250,80,158,40,48,248, -22,178,13,2,19,23,197,1,10,28,23,193,2,249,22,65,248,22,166,13,249, -22,164,13,23,198,1,247,22,179,13,27,248,22,67,23,200,1,28,248,22,73, -23,194,2,9,27,248,22,66,23,195,2,27,28,248,22,163,13,23,195,2,23, -194,1,28,248,22,162,13,23,195,2,249,22,164,13,23,196,1,250,80,158,47, -48,248,22,178,13,2,19,11,10,250,80,158,45,48,248,22,178,13,2,19,23, -197,1,10,28,23,193,2,249,22,65,248,22,166,13,249,22,164,13,23,198,1, -247,22,179,13,248,80,159,45,52,36,248,22,67,23,199,1,87,94,23,193,1, -248,80,159,43,52,36,248,22,67,23,197,1,87,94,23,193,1,27,248,22,67, -23,198,1,28,248,22,73,23,194,2,9,27,248,22,66,23,195,2,27,28,248, -22,163,13,23,195,2,23,194,1,28,248,22,162,13,23,195,2,249,22,164,13, -23,196,1,250,80,158,45,48,248,22,178,13,2,19,11,10,250,80,158,43,48, -248,22,178,13,2,19,23,197,1,10,28,23,193,2,249,22,65,248,22,166,13, -249,22,164,13,23,198,1,247,22,179,13,248,80,159,43,52,36,248,22,67,23, -199,1,248,80,159,41,52,36,248,22,67,196,27,248,22,139,13,23,195,2,28, -23,193,2,192,87,94,23,193,1,28,248,22,159,6,23,195,2,27,248,22,161, -13,195,28,192,192,248,22,162,13,195,11,87,94,28,28,248,22,140,13,23,195, -2,10,27,248,22,139,13,23,196,2,28,23,193,2,192,87,94,23,193,1,28, -248,22,159,6,23,196,2,27,248,22,161,13,23,197,2,28,23,193,2,192,87, -94,23,193,1,248,22,162,13,23,197,2,11,12,250,22,132,9,76,110,111,114, -109,97,108,45,112,97,116,104,45,99,97,115,101,6,42,42,112,97,116,104,32, -40,102,111,114,32,97,110,121,32,115,121,115,116,101,109,41,32,111,114,32,118, -97,108,105,100,45,112,97,116,104,32,115,116,114,105,110,103,23,197,2,28,28, -248,22,140,13,23,195,2,249,22,164,8,248,22,141,13,23,197,2,2,20,249, -22,164,8,247,22,178,7,2,20,27,28,248,22,159,6,23,196,2,23,195,2, -248,22,168,7,248,22,144,13,23,197,2,28,249,22,191,13,0,21,35,114,120, -34,94,91,92,92,93,91,92,92,93,91,63,93,91,92,92,93,34,23,195,2, -28,248,22,159,6,195,248,22,147,13,195,194,27,248,22,134,7,23,195,1,249, -22,148,13,248,22,171,7,250,22,133,14,0,6,35,114,120,34,47,34,28,249, -22,191,13,0,22,35,114,120,34,91,47,92,92,93,91,46,32,93,43,91,47, -92,92,93,42,36,34,23,201,2,23,199,1,250,22,133,14,0,19,35,114,120, -34,91,32,46,93,43,40,91,47,92,92,93,42,41,36,34,23,202,1,6,2, -2,92,49,80,159,43,36,37,2,20,28,248,22,159,6,194,248,22,147,13,194, -193,87,94,28,27,248,22,139,13,23,196,2,28,23,193,2,192,87,94,23,193, -1,28,248,22,159,6,23,196,2,27,248,22,161,13,23,197,2,28,23,193,2, -192,87,94,23,193,1,248,22,162,13,23,197,2,11,12,250,22,132,9,23,196, -2,2,21,23,197,2,28,248,22,161,13,23,195,2,12,248,22,158,11,249,22, -167,10,248,22,188,6,250,22,143,7,2,22,23,200,1,23,201,1,247,22,23, -87,94,28,27,248,22,139,13,23,196,2,28,23,193,2,192,87,94,23,193,1, -28,248,22,159,6,23,196,2,27,248,22,161,13,23,197,2,28,23,193,2,192, -87,94,23,193,1,248,22,162,13,23,197,2,11,12,250,22,132,9,23,196,2, -2,21,23,197,2,28,248,22,161,13,23,195,2,12,248,22,158,11,249,22,167, -10,248,22,188,6,250,22,143,7,2,22,23,200,1,23,201,1,247,22,23,87, -94,87,94,28,27,248,22,139,13,23,196,2,28,23,193,2,192,87,94,23,193, -1,28,248,22,159,6,23,196,2,27,248,22,161,13,23,197,2,28,23,193,2, -192,87,94,23,193,1,248,22,162,13,23,197,2,11,12,250,22,132,9,195,2, -21,23,197,2,28,248,22,161,13,23,195,2,12,248,22,158,11,249,22,167,10, -248,22,188,6,250,22,143,7,2,22,199,23,201,1,247,22,23,249,22,3,89, -162,8,44,36,49,9,223,2,33,33,196,248,22,158,11,249,22,133,11,23,196, -1,247,22,23,87,94,250,80,159,38,39,36,2,6,196,197,251,80,159,39,41, -36,2,6,32,0,89,162,8,44,36,44,9,222,33,35,197,198,32,37,89,162, -43,41,58,65,99,108,111,111,112,222,33,38,28,248,22,73,23,199,2,87,94, -23,198,1,248,23,196,1,251,22,143,7,2,23,23,199,1,28,248,22,73,23, -203,2,87,94,23,202,1,23,201,1,250,22,1,22,157,13,23,204,1,23,205, -1,23,198,1,27,249,22,157,13,248,22,66,23,202,2,23,199,2,28,248,22, -152,13,23,194,2,27,250,22,1,22,157,13,23,197,1,23,202,2,28,248,22, -152,13,23,194,2,192,87,94,23,193,1,27,248,22,67,23,202,1,28,248,22, -73,23,194,2,87,94,23,193,1,248,23,199,1,251,22,143,7,2,23,23,202, -1,28,248,22,73,23,206,2,87,94,23,205,1,23,204,1,250,22,1,22,157, -13,23,207,1,23,208,1,23,201,1,27,249,22,157,13,248,22,66,23,197,2, -23,202,2,28,248,22,152,13,23,194,2,27,250,22,1,22,157,13,23,197,1, -204,28,248,22,152,13,193,192,253,2,37,203,204,205,206,23,15,248,22,67,201, -253,2,37,202,203,204,205,206,248,22,67,200,87,94,23,193,1,27,248,22,67, -23,201,1,28,248,22,73,23,194,2,87,94,23,193,1,248,23,198,1,251,22, -143,7,2,23,23,201,1,28,248,22,73,23,205,2,87,94,23,204,1,23,203, -1,250,22,1,22,157,13,23,206,1,23,207,1,23,200,1,27,249,22,157,13, -248,22,66,23,197,2,23,201,2,28,248,22,152,13,23,194,2,27,250,22,1, -22,157,13,23,197,1,203,28,248,22,152,13,193,192,253,2,37,202,203,204,205, -206,248,22,67,201,253,2,37,201,202,203,204,205,248,22,67,200,27,247,22,180, -13,253,2,37,198,199,200,201,202,198,87,95,28,28,248,22,140,13,23,194,2, -10,27,248,22,139,13,23,195,2,28,23,193,2,192,87,94,23,193,1,28,248, -22,159,6,23,195,2,27,248,22,161,13,23,196,2,28,23,193,2,192,87,94, -23,193,1,248,22,162,13,23,196,2,11,12,252,22,132,9,23,200,2,2,24, -35,23,198,2,23,199,2,28,28,248,22,159,6,23,195,2,10,248,22,147,7, -23,195,2,87,94,23,194,1,12,252,22,132,9,23,200,2,2,25,36,23,198, -2,23,199,1,91,159,38,11,90,161,38,35,11,248,22,160,13,23,197,2,87, -94,23,195,1,87,94,28,192,12,250,22,133,9,23,201,1,2,26,23,199,1, -249,22,7,194,195,91,159,37,11,90,161,37,35,11,87,95,28,28,248,22,140, -13,23,196,2,10,27,248,22,139,13,23,197,2,28,23,193,2,192,87,94,23, -193,1,28,248,22,159,6,23,197,2,27,248,22,161,13,23,198,2,28,23,193, -2,192,87,94,23,193,1,248,22,162,13,23,198,2,11,12,252,22,132,9,2, -9,2,24,35,23,200,2,23,201,2,28,28,248,22,159,6,23,197,2,10,248, -22,147,7,23,197,2,12,252,22,132,9,2,9,2,25,36,23,200,2,23,201, -2,91,159,38,11,90,161,38,35,11,248,22,160,13,23,199,2,87,94,23,195, -1,87,94,28,192,12,250,22,133,9,2,9,2,26,23,201,2,249,22,7,194, -195,27,249,22,149,13,250,22,132,14,0,18,35,114,120,35,34,40,91,46,93, -91,94,46,93,42,124,41,36,34,248,22,145,13,23,201,1,28,248,22,159,6, -23,203,2,249,22,171,7,23,204,1,8,63,23,202,1,28,248,22,140,13,23, -199,2,248,22,141,13,23,199,1,87,94,23,198,1,247,22,142,13,28,248,22, -139,13,194,249,22,157,13,195,194,192,91,159,37,11,90,161,37,35,11,87,95, -28,28,248,22,140,13,23,196,2,10,27,248,22,139,13,23,197,2,28,23,193, -2,192,87,94,23,193,1,28,248,22,159,6,23,197,2,27,248,22,161,13,23, -198,2,28,23,193,2,192,87,94,23,193,1,248,22,162,13,23,198,2,11,12, -252,22,132,9,2,10,2,24,35,23,200,2,23,201,2,28,28,248,22,159,6, -23,197,2,10,248,22,147,7,23,197,2,12,252,22,132,9,2,10,2,25,36, -23,200,2,23,201,2,91,159,38,11,90,161,38,35,11,248,22,160,13,23,199, -2,87,94,23,195,1,87,94,28,192,12,250,22,133,9,2,10,2,26,23,201, -2,249,22,7,194,195,27,249,22,149,13,249,22,157,7,250,22,133,14,0,9, -35,114,120,35,34,91,46,93,34,248,22,145,13,23,203,1,6,1,1,95,28, -248,22,159,6,23,202,2,249,22,171,7,23,203,1,8,63,23,201,1,28,248, -22,140,13,23,199,2,248,22,141,13,23,199,1,87,94,23,198,1,247,22,142, -13,28,248,22,139,13,194,249,22,157,13,195,194,192,249,247,22,190,4,194,11, -249,80,158,37,46,9,9,249,80,158,37,46,195,9,27,247,22,182,13,249,80, -158,38,47,28,23,195,2,27,248,22,176,7,6,11,11,80,76,84,67,79,76, -76,69,67,84,83,28,192,192,6,0,0,6,0,0,27,28,23,196,1,250,22, -157,13,248,22,178,13,69,97,100,100,111,110,45,100,105,114,247,22,174,7,6, -8,8,99,111,108,108,101,99,116,115,11,27,248,80,159,41,52,36,250,22,79, -23,203,1,248,22,75,248,22,178,13,72,99,111,108,108,101,99,116,115,45,100, -105,114,23,204,1,28,23,194,2,249,22,65,23,196,1,23,195,1,192,32,47, -89,162,8,44,38,54,2,18,222,33,48,27,249,22,189,13,23,197,2,23,198, -2,28,23,193,2,87,94,23,196,1,27,248,22,90,23,195,2,27,27,248,22, -99,23,197,1,27,249,22,189,13,23,201,2,23,196,2,28,23,193,2,87,94, -23,194,1,27,248,22,90,23,195,2,27,250,2,47,23,203,2,23,204,1,248, -22,99,23,199,1,28,249,22,153,7,23,196,2,2,27,249,22,79,23,202,2, -194,249,22,65,248,22,148,13,23,197,1,23,195,1,87,95,23,199,1,23,193, -1,28,249,22,153,7,23,196,2,2,27,249,22,79,23,200,2,9,249,22,65, -248,22,148,13,23,197,1,9,28,249,22,153,7,23,196,2,2,27,249,22,79, -197,194,87,94,23,196,1,249,22,65,248,22,148,13,23,197,1,194,87,94,23, -193,1,28,249,22,153,7,23,198,2,2,27,249,22,79,195,9,87,94,23,194, -1,249,22,65,248,22,148,13,23,199,1,9,87,95,28,28,248,22,147,7,194, -10,248,22,159,6,194,12,250,22,132,9,2,13,6,21,21,98,121,116,101,32, -115,116,114,105,110,103,32,111,114,32,115,116,114,105,110,103,196,28,28,248,22, -74,195,249,22,4,22,139,13,196,11,12,250,22,132,9,2,13,6,13,13,108, -105,115,116,32,111,102,32,112,97,116,104,115,197,250,2,47,197,195,28,248,22, -159,6,197,248,22,170,7,197,196,32,50,89,162,8,44,39,57,2,18,222,33, -53,32,51,89,162,8,44,38,54,70,102,111,117,110,100,45,101,120,101,99,222, -33,52,28,23,193,2,91,159,38,11,90,161,38,35,11,248,22,160,13,23,199, -2,87,95,23,195,1,23,194,1,27,28,23,198,2,27,248,22,165,13,23,201, -2,28,249,22,166,8,23,195,2,23,202,2,11,28,248,22,161,13,23,194,2, -250,2,51,23,201,2,23,202,2,249,22,157,13,23,200,2,23,198,1,250,2, -51,23,201,2,23,202,2,23,196,1,11,28,23,193,2,192,87,94,23,193,1, -27,28,248,22,139,13,23,196,2,27,249,22,157,13,23,198,2,23,201,2,28, -28,248,22,152,13,193,10,248,22,151,13,193,192,11,11,28,23,193,2,192,87, -94,23,193,1,28,23,199,2,11,27,248,22,165,13,23,202,2,28,249,22,166, -8,23,195,2,23,203,1,11,28,248,22,161,13,23,194,2,250,2,51,23,202, -1,23,203,1,249,22,157,13,23,201,1,23,198,1,250,2,51,201,202,195,194, -28,248,22,73,23,197,2,11,27,248,22,164,13,248,22,66,23,199,2,27,249, -22,157,13,23,196,1,23,197,2,28,248,22,151,13,23,194,2,250,2,51,198, -199,195,87,94,23,193,1,27,248,22,67,23,200,1,28,248,22,73,23,194,2, -11,27,248,22,164,13,248,22,66,23,196,2,27,249,22,157,13,23,196,1,23, -200,2,28,248,22,151,13,23,194,2,250,2,51,201,202,195,87,94,23,193,1, -27,248,22,67,23,197,1,28,248,22,73,23,194,2,11,27,248,22,164,13,248, -22,66,195,27,249,22,157,13,23,196,1,202,28,248,22,151,13,193,250,2,51, -204,205,195,251,2,50,204,205,206,248,22,67,199,87,95,28,27,248,22,139,13, -23,196,2,28,23,193,2,192,87,94,23,193,1,28,248,22,159,6,23,196,2, -27,248,22,161,13,23,197,2,28,23,193,2,192,87,94,23,193,1,248,22,162, -13,23,197,2,11,12,250,22,132,9,2,14,6,25,25,112,97,116,104,32,111, -114,32,115,116,114,105,110,103,32,40,115,97,110,115,32,110,117,108,41,23,197, -2,28,28,23,195,2,28,27,248,22,139,13,23,197,2,28,23,193,2,192,87, -94,23,193,1,28,248,22,159,6,23,197,2,27,248,22,161,13,23,198,2,28, -23,193,2,192,87,94,23,193,1,248,22,162,13,23,198,2,11,248,22,161,13, -23,196,2,11,10,12,250,22,132,9,2,14,6,29,29,35,102,32,111,114,32, -114,101,108,97,116,105,118,101,32,112,97,116,104,32,111,114,32,115,116,114,105, -110,103,23,198,2,28,28,248,22,161,13,23,195,2,91,159,38,11,90,161,38, -35,11,248,22,160,13,23,198,2,249,22,164,8,194,68,114,101,108,97,116,105, -118,101,11,27,248,22,176,7,6,4,4,80,65,84,72,251,2,50,23,199,1, -23,200,1,23,201,1,28,23,197,2,27,249,80,159,43,47,37,23,200,1,9, -28,249,22,164,8,247,22,178,7,2,20,249,22,65,248,22,148,13,5,1,46, -23,195,1,192,9,27,248,22,164,13,23,196,1,28,248,22,151,13,193,250,2, -51,198,199,195,11,250,80,158,38,48,196,197,11,250,80,158,38,48,196,11,11, -87,94,249,22,150,6,247,22,186,4,195,248,22,176,5,249,22,172,3,35,249, -22,156,3,197,198,27,28,23,197,2,87,95,23,196,1,23,195,1,23,197,1, -87,94,23,197,1,27,248,22,178,13,2,19,27,249,80,159,40,48,37,23,196, -1,11,27,27,248,22,175,3,23,200,1,28,192,192,35,27,27,248,22,175,3, -23,202,1,28,192,192,35,249,22,153,5,23,197,1,83,158,39,20,97,95,89, -162,8,44,35,47,9,224,3,2,33,57,23,195,1,23,196,1,27,248,22,138, -5,23,195,1,248,80,159,38,53,36,193,159,35,20,103,159,35,16,1,11,16, -0,83,158,41,20,100,143,67,35,37,117,116,105,108,115,29,11,11,11,11,10, -10,42,80,158,35,35,20,103,159,37,16,17,2,1,2,2,2,3,2,4,2, -5,2,6,2,7,2,8,2,9,2,10,2,11,2,12,2,13,2,14,2,15, -30,2,17,1,20,112,97,114,97,109,101,116,101,114,105,122,97,116,105,111,110, -45,107,101,121,4,30,2,17,1,23,101,120,116,101,110,100,45,112,97,114,97, -109,101,116,101,114,105,122,97,116,105,111,110,3,16,0,11,11,16,0,35,16, -0,35,16,4,2,5,2,4,2,2,2,8,39,11,11,38,35,11,11,16,11, -2,7,2,6,2,15,2,14,2,12,2,11,2,3,2,10,2,13,2,9,2, -1,16,11,11,11,11,11,11,11,11,11,11,11,11,16,11,2,7,2,6,2, -15,2,14,2,12,2,11,2,3,2,10,2,13,2,9,2,1,46,46,36,11, -11,16,0,16,0,16,0,35,35,11,11,11,16,0,16,0,16,0,35,35,16, -0,16,17,83,158,35,16,2,89,162,43,36,48,2,18,223,0,33,28,80,159, -35,53,36,83,158,35,16,2,89,162,8,44,36,55,2,18,223,0,33,29,80, -159,35,52,36,83,158,35,16,2,32,0,89,162,43,36,44,2,1,222,33,30, -80,159,35,35,36,83,158,35,16,2,249,22,161,6,7,92,7,92,80,159,35, -36,36,83,158,35,16,2,89,162,43,36,53,2,3,223,0,33,31,80,159,35, -37,36,83,158,35,16,2,32,0,89,162,8,44,37,49,2,4,222,33,32,80, -159,35,38,36,83,158,35,16,2,32,0,89,162,8,44,38,50,2,5,222,33, -34,80,159,35,39,36,83,158,35,16,2,89,162,8,45,37,47,2,6,223,0, -33,36,80,159,35,40,36,83,158,35,16,2,32,0,89,162,43,39,51,2,7, -222,33,39,80,159,35,41,36,83,158,35,16,2,32,0,89,162,43,38,49,2, -8,222,33,40,80,159,35,42,36,83,158,35,16,2,32,0,89,162,43,37,52, -2,9,222,33,41,80,159,35,43,36,83,158,35,16,2,32,0,89,162,43,37, -53,2,10,222,33,42,80,159,35,44,36,83,158,35,16,2,32,0,89,162,43, -36,43,2,11,222,33,43,80,159,35,45,36,83,158,35,16,2,83,158,38,20, -96,96,2,12,89,162,43,35,43,9,223,0,33,44,89,162,43,36,44,9,223, -0,33,45,89,162,43,37,54,9,223,0,33,46,80,159,35,46,36,83,158,35, -16,2,27,248,22,185,13,248,22,170,7,27,28,249,22,164,8,247,22,178,7, -2,20,6,1,1,59,6,1,1,58,250,22,143,7,6,14,14,40,91,94,126, -97,93,42,41,126,97,40,46,42,41,23,196,2,23,196,1,89,162,8,44,37, -47,2,13,223,0,33,49,80,159,35,47,36,83,158,35,16,2,83,158,38,20, -96,96,2,14,89,162,8,44,38,53,9,223,0,33,54,89,162,43,37,46,9, -223,0,33,55,89,162,43,36,45,9,223,0,33,56,80,159,35,48,36,83,158, -35,16,2,89,162,43,38,51,2,15,223,0,33,58,80,159,35,49,36,94,29, -94,2,16,68,35,37,107,101,114,110,101,108,11,29,94,2,16,69,35,37,109, -105,110,45,115,116,120,11,9,9,9,35,0}; - EVAL_ONE_SIZED_STR((char *)expr, 5009); - } - { - static MZCOMPILED_STRING_FAR unsigned char expr[] = {35,126,7,52,46,49,46,52,46,50,8,0,0,0,1,0,0,6,0,19,0, -34,0,48,0,62,0,76,0,111,0,0,0,1,1,0,0,65,113,117,111,116, -101,29,94,2,1,67,35,37,117,116,105,108,115,11,29,94,2,1,69,35,37, -110,101,116,119,111,114,107,11,29,94,2,1,68,35,37,112,97,114,97,109,122, -11,29,94,2,1,68,35,37,101,120,112,111,98,115,11,29,94,2,1,68,35, -37,107,101,114,110,101,108,11,98,10,35,11,8,140,230,97,159,2,2,35,35, -159,2,3,35,35,159,2,4,35,35,159,2,5,35,35,159,2,6,35,35,16, -0,159,35,20,103,159,35,16,1,11,16,0,83,158,41,20,100,143,69,35,37, -98,117,105,108,116,105,110,29,11,11,11,10,10,18,96,11,42,42,42,35,80, -158,35,35,20,103,159,35,16,0,16,0,11,11,16,0,35,16,0,35,16,0, -35,11,11,38,35,11,11,16,0,16,0,16,0,35,35,36,11,11,16,0,16, -0,16,0,35,35,11,11,11,16,0,16,0,16,0,35,35,16,0,16,0,99, -2,6,2,5,29,94,2,1,69,35,37,102,111,114,101,105,103,110,11,2,4, -2,3,2,2,29,94,2,1,67,35,37,112,108,97,99,101,11,9,9,9,35, -0}; - EVAL_ONE_SIZED_STR((char *)expr, 294); - } - { - static MZCOMPILED_STRING_FAR unsigned char expr[] = {35,126,7,52,46,49,46,52,46,50,52,0,0,0,1,0,0,11,0,38,0, -44,0,57,0,71,0,93,0,119,0,131,0,149,0,169,0,181,0,197,0,220, -0,0,1,5,1,10,1,15,1,24,1,29,1,60,1,64,1,72,1,81,1, -89,1,196,1,241,1,5,2,34,2,65,2,121,2,131,2,178,2,188,2,195, -2,82,4,95,4,114,4,233,4,245,4,141,5,155,5,21,6,27,6,41,6, -68,6,153,6,155,6,221,6,166,12,225,12,3,13,0,0,138,15,0,0,70, -100,108,108,45,115,117,102,102,105,120,1,25,100,101,102,97,117,108,116,45,108, -111,97,100,47,117,115,101,45,99,111,109,112,105,108,101,100,65,113,117,111,116, -101,29,94,2,3,67,35,37,117,116,105,108,115,11,29,94,2,3,68,35,37, -112,97,114,97,109,122,11,1,20,100,101,102,97,117,108,116,45,114,101,97,100, -101,114,45,103,117,97,114,100,1,24,45,109,111,100,117,108,101,45,104,97,115, -104,45,116,97,98,108,101,45,116,97,98,108,101,71,45,112,97,116,104,45,99, -97,99,104,101,77,45,108,111,97,100,105,110,103,45,102,105,108,101,110,97,109, -101,79,45,108,111,97,100,105,110,103,45,112,114,111,109,112,116,45,116,97,103, -71,45,112,114,101,118,45,114,101,108,116,111,75,45,112,114,101,118,45,114,101, -108,116,111,45,100,105,114,1,21,115,112,108,105,116,45,114,101,108,97,116,105, -118,101,45,115,116,114,105,110,103,1,34,109,97,107,101,45,115,116,97,110,100, -97,114,100,45,109,111,100,117,108,101,45,110,97,109,101,45,114,101,115,111,108, -118,101,114,64,98,111,111,116,64,115,97,109,101,5,3,46,122,111,6,6,6, -110,97,116,105,118,101,64,108,111,111,112,1,29,115,116,97,110,100,97,114,100, -45,109,111,100,117,108,101,45,110,97,109,101,45,114,101,115,111,108,118,101,114, -63,108,105,98,67,105,103,110,111,114,101,100,249,22,14,195,80,159,37,45,37, -249,80,159,37,48,36,195,10,27,28,23,195,2,28,249,22,164,8,23,197,2, -80,159,38,46,37,87,94,23,195,1,80,159,36,47,37,27,248,22,173,4,23, -197,2,28,248,22,139,13,23,194,2,91,159,38,11,90,161,38,35,11,248,22, -160,13,23,197,1,87,95,83,160,37,11,80,159,40,46,37,198,83,160,37,11, -80,159,40,47,37,192,192,11,11,28,23,193,2,192,87,94,23,193,1,27,247, -22,191,4,28,192,192,247,22,179,13,20,14,159,80,158,35,39,250,80,158,38, -40,249,22,27,11,80,158,40,39,22,191,4,28,248,22,139,13,23,198,2,23, -197,1,87,94,23,197,1,247,22,179,13,247,194,250,22,157,13,23,197,1,23, -199,1,249,80,158,42,38,23,198,1,2,17,252,22,157,13,23,199,1,23,201, -1,2,18,247,22,179,7,249,80,158,44,38,23,200,1,80,159,44,35,37,87, -94,23,194,1,27,250,22,174,13,196,11,32,0,89,162,8,44,35,40,9,222, -11,28,192,249,22,65,195,194,11,27,252,22,157,13,23,200,1,23,202,1,2, -18,247,22,179,7,249,80,158,45,38,23,201,1,80,159,45,35,37,27,250,22, -174,13,196,11,32,0,89,162,8,44,35,40,9,222,11,28,192,249,22,65,195, -194,11,249,247,22,184,13,248,22,66,195,195,27,250,22,157,13,23,198,1,23, -200,1,249,80,158,43,38,23,199,1,2,17,27,250,22,174,13,196,11,32,0, -89,162,8,44,35,40,9,222,11,28,192,249,22,65,195,194,11,249,247,22,189, -4,248,22,66,195,195,249,247,22,189,4,194,195,87,94,28,248,80,158,36,37, -23,195,2,12,250,22,132,9,77,108,111,97,100,47,117,115,101,45,99,111,109, -112,105,108,101,100,6,25,25,112,97,116,104,32,111,114,32,118,97,108,105,100, -45,112,97,116,104,32,115,116,114,105,110,103,23,197,2,91,159,41,11,90,161, -36,35,11,28,248,22,163,13,23,201,2,23,200,1,27,247,22,191,4,28,23, -193,2,249,22,164,13,23,203,1,23,195,1,200,90,161,38,36,11,248,22,160, -13,23,194,2,87,94,23,196,1,90,161,36,39,11,28,249,22,164,8,23,196, -2,68,114,101,108,97,116,105,118,101,87,94,23,194,1,2,16,23,194,1,90, -161,36,40,11,247,22,181,13,27,89,162,43,36,49,62,122,111,225,7,5,3, -33,27,27,89,162,43,36,51,9,225,8,6,4,33,28,27,249,22,5,89,162, -8,44,36,46,9,223,5,33,29,23,203,2,27,28,23,195,1,27,249,22,5, -89,162,8,44,36,52,9,225,13,11,9,33,30,23,205,2,27,28,23,196,2, -11,193,28,192,192,28,193,28,23,196,2,28,249,22,168,3,248,22,67,196,248, -22,67,23,199,2,193,11,11,11,11,28,23,193,2,249,80,159,47,54,36,202, -89,162,43,35,45,9,224,14,2,33,31,87,94,23,193,1,27,28,23,197,1, -27,249,22,5,83,158,39,20,97,94,89,162,8,44,36,50,9,225,14,12,10, -33,32,23,203,1,23,206,1,27,28,196,11,193,28,192,192,28,193,28,196,28, -249,22,168,3,248,22,67,196,248,22,67,199,193,11,11,11,11,28,192,249,80, -159,48,54,36,203,89,162,43,35,45,9,224,15,2,33,33,249,80,159,48,54, -36,203,89,162,43,35,44,9,224,15,7,33,34,32,36,89,162,8,44,36,54, -2,19,222,33,38,0,17,35,114,120,34,94,40,46,42,63,41,47,40,46,42, -41,36,34,27,249,22,189,13,2,37,23,196,2,28,23,193,2,87,94,23,194, -1,249,22,65,248,22,90,23,196,2,27,248,22,99,23,197,1,27,249,22,189, -13,2,37,23,196,2,28,23,193,2,87,94,23,194,1,249,22,65,248,22,90, -23,196,2,27,248,22,99,23,197,1,27,249,22,189,13,2,37,23,196,2,28, -23,193,2,87,94,23,194,1,249,22,65,248,22,90,23,196,2,248,2,36,248, -22,99,23,197,1,248,22,75,194,248,22,75,194,248,22,75,194,32,39,89,162, -43,36,54,2,19,222,33,40,28,248,22,73,248,22,67,23,195,2,249,22,7, -9,248,22,66,195,91,159,37,11,90,161,37,35,11,27,248,22,67,23,197,2, -28,248,22,73,248,22,67,23,195,2,249,22,7,9,248,22,66,195,91,159,37, -11,90,161,37,35,11,27,248,22,67,23,197,2,28,248,22,73,248,22,67,23, -195,2,249,22,7,9,248,22,66,195,91,159,37,11,90,161,37,35,11,248,2, -39,248,22,67,23,197,2,249,22,7,249,22,65,248,22,66,23,200,1,23,197, -1,195,249,22,7,249,22,65,248,22,66,23,200,1,23,197,1,195,249,22,7, -249,22,65,248,22,66,23,200,1,23,197,1,195,27,248,2,36,23,195,1,28, -194,192,248,2,39,193,87,95,28,248,22,171,4,195,12,250,22,132,9,2,20, -6,20,20,114,101,115,111,108,118,101,100,45,109,111,100,117,108,101,45,112,97, -116,104,197,28,24,193,2,248,24,194,1,195,87,94,23,193,1,12,27,27,250, -22,139,2,80,159,41,42,37,248,22,145,14,247,22,186,11,11,28,23,193,2, -192,87,94,23,193,1,27,247,22,123,87,94,250,22,137,2,80,159,42,42,37, -248,22,145,14,247,22,186,11,195,192,250,22,137,2,195,198,66,97,116,116,97, -99,104,251,211,197,198,199,10,28,192,250,22,131,9,11,196,195,248,22,129,9, -194,28,249,22,165,6,194,6,1,1,46,2,16,28,249,22,165,6,194,6,2, -2,46,46,62,117,112,192,28,249,22,166,8,248,22,67,23,200,2,23,197,1, -28,249,22,164,8,248,22,66,23,200,2,23,196,1,251,22,129,9,2,20,6, -26,26,99,121,99,108,101,32,105,110,32,108,111,97,100,105,110,103,32,97,116, -32,126,101,58,32,126,101,23,200,1,249,22,2,22,67,248,22,80,249,22,65, -23,206,1,23,202,1,12,12,247,192,20,14,159,80,159,39,44,37,249,22,65, -248,22,145,14,247,22,186,11,23,197,1,20,14,159,80,158,39,39,250,80,158, -42,40,249,22,27,11,80,158,44,39,22,153,4,23,196,1,249,247,22,190,4, -23,198,1,248,22,54,248,22,143,13,23,198,1,87,94,28,28,248,22,139,13, -23,197,2,10,248,22,177,4,23,197,2,12,28,23,198,2,250,22,131,9,11, -6,15,15,98,97,100,32,109,111,100,117,108,101,32,112,97,116,104,23,201,2, -250,22,132,9,2,20,6,19,19,109,111,100,117,108,101,45,112,97,116,104,32, -111,114,32,112,97,116,104,23,199,2,28,28,248,22,63,23,197,2,249,22,164, -8,248,22,66,23,199,2,2,3,11,248,22,172,4,248,22,90,197,28,28,248, -22,63,23,197,2,249,22,164,8,248,22,66,23,199,2,66,112,108,97,110,101, -116,11,87,94,28,207,12,20,14,159,80,158,37,39,250,80,158,40,40,249,22, -27,11,80,158,42,39,22,186,11,23,197,1,90,161,36,35,10,249,22,154,4, -21,94,2,21,6,18,18,112,108,97,110,101,116,47,114,101,115,111,108,118,101, -114,46,115,115,1,27,112,108,97,110,101,116,45,109,111,100,117,108,101,45,110, -97,109,101,45,114,101,115,111,108,118,101,114,12,251,211,199,200,201,202,87,94, -23,193,1,27,89,162,8,44,36,45,79,115,104,111,119,45,99,111,108,108,101, -99,116,105,111,110,45,101,114,114,223,6,33,44,27,28,248,22,53,23,199,2, -27,250,22,139,2,80,159,43,43,37,249,22,65,23,204,2,247,22,180,13,11, -28,23,193,2,192,87,94,23,193,1,91,159,37,11,90,161,37,35,11,249,80, -159,44,48,36,248,22,56,23,204,2,11,27,251,80,158,47,50,2,20,23,202, -1,28,248,22,73,23,199,2,23,199,2,248,22,66,23,199,2,28,248,22,73, -23,199,2,9,248,22,67,23,199,2,249,22,157,13,23,195,1,28,248,22,73, -23,197,1,87,94,23,197,1,6,7,7,109,97,105,110,46,115,115,249,22,182, -6,23,199,1,6,3,3,46,115,115,28,248,22,159,6,23,199,2,87,94,23, -194,1,27,248,80,159,41,55,36,23,201,2,27,250,22,139,2,80,159,44,43, -37,249,22,65,23,205,2,23,199,2,11,28,23,193,2,192,87,94,23,193,1, -91,159,37,11,90,161,37,35,11,249,80,159,45,48,36,23,204,2,11,250,22, -1,22,157,13,23,199,1,249,22,79,249,22,2,32,0,89,162,8,44,36,43, -9,222,33,45,23,200,1,248,22,75,23,200,1,28,248,22,139,13,23,199,2, -87,94,23,194,1,28,248,22,162,13,23,199,2,23,198,2,248,22,75,6,26, -26,32,40,97,32,112,97,116,104,32,109,117,115,116,32,98,101,32,97,98,115, -111,108,117,116,101,41,28,249,22,164,8,248,22,66,23,201,2,2,21,27,250, -22,139,2,80,159,43,43,37,249,22,65,23,204,2,247,22,180,13,11,28,23, -193,2,192,87,94,23,193,1,91,159,38,11,90,161,37,35,11,249,80,159,45, -48,36,248,22,90,23,205,2,11,90,161,36,37,11,28,248,22,73,248,22,92, -23,204,2,28,248,22,73,23,194,2,249,22,191,13,0,8,35,114,120,34,91, -46,93,34,23,196,2,11,10,27,27,28,23,197,2,249,22,79,28,248,22,73, -248,22,92,23,208,2,21,93,6,5,5,109,122,108,105,98,249,22,1,22,79, -249,22,2,80,159,51,56,36,248,22,92,23,211,2,23,197,2,28,248,22,73, -23,196,2,248,22,75,23,197,2,23,195,2,251,80,158,49,50,2,20,23,204, -1,248,22,66,23,198,2,248,22,67,23,198,1,249,22,157,13,23,195,1,28, -23,198,1,87,94,23,196,1,23,197,1,28,248,22,73,23,197,1,87,94,23, -197,1,6,7,7,109,97,105,110,46,115,115,28,249,22,191,13,0,8,35,114, -120,34,91,46,93,34,23,199,2,23,197,1,249,22,182,6,23,199,1,6,3, -3,46,115,115,28,249,22,164,8,248,22,66,23,201,2,64,102,105,108,101,249, -22,164,13,248,22,168,13,248,22,90,23,202,2,248,80,159,42,55,36,23,202, -2,12,87,94,28,28,248,22,139,13,23,194,2,10,248,22,181,7,23,194,2, -87,94,23,200,1,12,28,23,200,2,250,22,131,9,67,114,101,113,117,105,114, -101,249,22,143,7,6,17,17,98,97,100,32,109,111,100,117,108,101,32,112,97, -116,104,126,97,28,23,198,2,248,22,66,23,199,2,6,0,0,23,203,1,87, -94,23,200,1,250,22,132,9,2,20,249,22,143,7,6,13,13,109,111,100,117, -108,101,32,112,97,116,104,126,97,28,23,198,2,248,22,66,23,199,2,6,0, -0,23,201,2,27,28,248,22,181,7,23,195,2,249,22,186,7,23,196,2,35, -249,22,166,13,248,22,167,13,23,197,2,11,27,28,248,22,181,7,23,196,2, -249,22,186,7,23,197,2,36,248,80,158,42,51,23,195,2,91,159,38,11,90, -161,38,35,11,28,248,22,181,7,23,199,2,250,22,7,2,22,249,22,186,7, -23,203,2,37,2,22,248,22,160,13,23,198,2,87,95,23,195,1,23,193,1, -27,28,248,22,181,7,23,200,2,249,22,186,7,23,201,2,38,249,80,158,47, -52,23,197,2,5,0,27,28,248,22,181,7,23,201,2,249,22,186,7,23,202, -2,39,248,22,172,4,23,200,2,27,27,250,22,139,2,80,159,51,42,37,248, -22,145,14,247,22,186,11,11,28,23,193,2,192,87,94,23,193,1,27,247,22, -123,87,94,250,22,137,2,80,159,52,42,37,248,22,145,14,247,22,186,11,195, -192,87,95,28,23,209,1,27,250,22,139,2,23,197,2,197,11,28,23,193,1, -12,87,95,27,27,28,248,22,17,80,159,51,45,37,80,159,50,45,37,247,22, -19,250,22,25,248,22,23,23,197,2,80,159,53,44,37,23,196,1,27,248,22, -145,14,247,22,186,11,249,22,3,83,158,39,20,97,94,89,162,8,44,36,54, -9,226,12,11,2,3,33,46,23,195,1,23,196,1,248,28,248,22,17,80,159, -50,45,37,32,0,89,162,43,36,41,9,222,33,47,80,159,49,57,36,89,162, -43,35,50,9,227,14,9,8,4,3,33,48,250,22,137,2,23,197,1,197,10, -12,28,28,248,22,181,7,23,202,1,11,27,248,22,159,6,23,208,2,28,192, -192,28,248,22,63,23,208,2,249,22,164,8,248,22,66,23,210,2,2,21,11, -250,22,137,2,80,159,50,43,37,28,248,22,159,6,23,210,2,249,22,65,23, -211,1,248,80,159,53,55,36,23,213,1,87,94,23,210,1,249,22,65,23,211, -1,247,22,180,13,252,22,183,7,23,208,1,23,207,1,23,205,1,23,203,1, -201,12,193,91,159,37,10,90,161,36,35,10,11,90,161,36,36,10,83,158,38, -20,96,96,2,20,89,162,8,44,36,50,9,224,2,0,33,42,89,162,43,38, -48,9,223,1,33,43,89,162,43,39,8,30,9,225,2,3,0,33,49,208,87, -95,248,22,152,4,248,80,159,37,49,37,247,22,186,11,248,22,190,4,80,159, -36,36,37,248,22,177,12,80,159,36,41,36,159,35,20,103,159,35,16,1,11, -16,0,83,158,41,20,100,143,66,35,37,98,111,111,116,29,11,11,11,11,10, -10,36,80,158,35,35,20,103,159,39,16,19,2,1,2,2,30,2,4,72,112, -97,116,104,45,115,116,114,105,110,103,63,10,30,2,4,75,112,97,116,104,45, -97,100,100,45,115,117,102,102,105,120,7,30,2,5,1,20,112,97,114,97,109, -101,116,101,114,105,122,97,116,105,111,110,45,107,101,121,4,30,2,5,1,23, -101,120,116,101,110,100,45,112,97,114,97,109,101,116,101,114,105,122,97,116,105, -111,110,3,2,6,2,7,2,8,2,9,2,10,2,11,2,12,2,13,2,14, -30,2,4,69,45,102,105,110,100,45,99,111,108,0,30,2,4,76,110,111,114, -109,97,108,45,99,97,115,101,45,112,97,116,104,6,30,2,4,79,112,97,116, -104,45,114,101,112,108,97,99,101,45,115,117,102,102,105,120,9,2,15,16,0, -11,11,16,0,35,16,0,35,16,11,2,9,2,10,2,7,2,8,2,11,2, -12,2,2,2,6,2,1,2,14,2,13,46,11,11,38,35,11,11,16,1,2, -15,16,1,11,16,1,2,15,36,36,36,11,11,16,0,16,0,16,0,35,35, -11,11,11,16,0,16,0,16,0,35,35,16,0,16,16,83,158,35,16,2,89, -162,43,36,44,9,223,0,33,23,80,159,35,57,36,83,158,35,16,2,89,162, -43,36,44,9,223,0,33,24,80,159,35,56,36,83,158,35,16,2,89,162,43, -36,48,67,103,101,116,45,100,105,114,223,0,33,25,80,159,35,55,36,83,158, -35,16,2,89,162,43,37,48,68,119,105,116,104,45,100,105,114,223,0,33,26, -80,159,35,54,36,83,158,35,16,2,248,22,178,7,69,115,111,45,115,117,102, -102,105,120,80,159,35,35,36,83,158,35,16,2,89,162,43,37,59,2,2,223, -0,33,35,80,159,35,36,36,83,158,35,16,2,32,0,89,162,8,44,36,41, -2,6,222,192,80,159,35,41,36,83,158,35,16,2,247,22,126,80,159,35,42, -36,83,158,35,16,2,247,22,125,80,159,35,43,36,83,158,35,16,2,247,22, -61,80,159,35,44,36,83,158,35,16,2,248,22,18,74,109,111,100,117,108,101, -45,108,111,97,100,105,110,103,80,159,35,45,36,83,158,35,16,2,11,80,158, -35,46,83,158,35,16,2,11,80,158,35,47,83,158,35,16,2,32,0,89,162, -43,37,44,2,13,222,33,41,80,159,35,48,36,83,158,35,16,2,89,162,8, -44,36,44,2,14,223,0,33,50,80,159,35,49,36,83,158,35,16,2,89,162, -43,35,43,2,15,223,0,33,51,80,159,35,53,36,95,29,94,2,3,68,35, -37,107,101,114,110,101,108,11,29,94,2,3,69,35,37,109,105,110,45,115,116, -120,11,2,4,9,9,9,35,0}; - EVAL_ONE_SIZED_STR((char *)expr, 4103); - } -------------- next part -------------- #lang scheme (require srfi/78) (provide async test-async tagged test-tags my-thread my-thread? test-my-thread run-tests) (define (async thunk) (let ((thr (thread (lambda () (with-handlers ((void (lambda (e) (thread-set-specific! e)))) (thread-set-specific! (thunk))))))) (handle-evt thr (lambda (thr) (thread-get-specific thr))))) (define (a1) 1) (define (a2) (error 'a2)) (define (test-async) (check (sync (async a1)) => 1) (let ((v2 (sync (async a2)))) (check (exn? v2) => #t))) (define (tagged . fs) (thread (lambda () (for ((f fs)) (thread-set-specific! (object-name (car f))) (apply (car f) (cdr f)))))) (define (b1 sema) (semaphore-wait sema)) (define (b2 sema) (semaphore-wait sema)) (define (b3 sema) (semaphore-wait sema)) (define (test-tags) (let* ((semas (build-list 3 (lambda (i) (make-semaphore)))) (acts (for/list ((f (list b1 b2 b3)) (s semas)) (list f s))) (tag (apply tagged acts))) (for ((state acts)) (sync (system-idle-evt)) (check (thread-get-specific tag) => (object-name (car state))) (semaphore-post (cadr state))) (thread-wait tag))) (define (my-thread thunk mark) (let* ((sema (make-semaphore)) (thr (thread (lambda () (thread-set-specific! mark) (semaphore-post sema) (thunk))))) (semaphore-wait sema) thr)) (define (my-thread? thr mark) (eq? (thread-get-specific thr) mark)) (define (test-my-thread) (let ((mark #&me)) (check (my-thread? (thread void) mark) => #f) (check (my-thread? (my-thread void mark) mark) => #t))) (define (run-tests) (test-async) (test-tags) (test-my-thread)) From mflatt at cs.utah.edu Tue Mar 3 14:35:04 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Tue Mar 3 14:35:37 2009 Subject: [plt-dev] thread-specifics [PATCH] In-Reply-To: References: Message-ID: <20090303193504.953D56500C6@mail-svr1.cs.utah.edu> Is there a reason this needs to be built in, instead of implemented as a weak hash table? At Tue, 3 Mar 2009 14:31:33 -0500 (EST), Dimitris Vyzovitis wrote: > The attached patch adds two new atomic primitives implementing > thread-specifics: > (thread-get-specific thread? (undefined (lambda () #f)) -> any? > Retrieve the specific value from a thread. > The optional undefined thunk is used to provide a value when the > specific has not been set by the target thread. > (thread-set-specific! any?) -> void > Set the specific value for the current thread. > > These primitives are useful for communicating publicly visible information > and simplify common synchronization patterns. > > Some simple examples in the test module [thread-specific.ss]: > async: an asynchronous computation wrapper around threads. > tagged: a state machine that tags its current state. > my-thread: a synchronous thread spawner that places an ownership mark. > > test run: > > (require "test-threadsp.ss") > > (run-tests) > > (sync (async a1)) > => 1 > ; correct > > (exn? v2) > => #t > ; correct > > (thread-get-specific tag) > => b1 > ; correct > > (thread-get-specific tag) > => b2 > ; correct > > (thread-get-specific tag) > => b3 > ; correct > > (my-thread? (thread void) mark) > => #f > ; correct > > (my-thread? (my-thread void mark) mark) > => #t > ; correct > > -- vyzo From vyzo at media.mit.edu Tue Mar 3 14:39:39 2009 From: vyzo at media.mit.edu (Dimitris Vyzovitis) Date: Tue Mar 3 14:40:07 2009 Subject: [plt-dev] thread-specifics [PATCH] In-Reply-To: <20090303193504.953D56500C6@mail-svr1.cs.utah.edu> References: <20090303193504.953D56500C6@mail-svr1.cs.utah.edu> Message-ID: On Tue, 3 Mar 2009, Matthew Flatt wrote: > Is there a reason this needs to be built in, instead of implemented as > a weak hash table? There is no rendezvous needed to access the specific, because it is attached to the thread (a public readonly cell), simplifying things with barriers, tagging, etc. The thread can set a weak table in its specific if for key/value access. -- vyzo From vyzo at media.mit.edu Tue Mar 3 14:41:15 2009 From: vyzo at media.mit.edu (Dimitris Vyzovitis) Date: Tue Mar 3 14:41:35 2009 Subject: [plt-dev] thread-specifics [PATCH] In-Reply-To: <20090303193504.953D56500C6@mail-svr1.cs.utah.edu> References: <20090303193504.953D56500C6@mail-svr1.cs.utah.edu> Message-ID: On Tue, 3 Mar 2009, Matthew Flatt wrote: > Is there a reason this needs to be built in, instead of implemented as > a weak hash table? A secondary effect: The specific becomes a 'class' for the thread [which is an actor as an instance of an active object] -- vyzo From mflatt at cs.utah.edu Tue Mar 3 14:51:01 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Tue Mar 3 14:51:25 2009 Subject: [plt-dev] thread-specifics [PATCH] In-Reply-To: References: <20090303193504.953D56500C6@mail-svr1.cs.utah.edu> Message-ID: <20090303195101.AF8926500FA@mail-svr1.cs.utah.edu> At Tue, 3 Mar 2009 14:39:39 -0500 (EST), Dimitris Vyzovitis wrote: > On Tue, 3 Mar 2009, Matthew Flatt wrote: > > > Is there a reason this needs to be built in, instead of implemented as > > a weak hash table? > > There is no rendezvous needed to access the specific, because it is > attached to the thread (a public readonly cell), simplifying things with > barriers, tagging, etc. There's also no rendezvous for an `eq?'-based weak hash table (which is the variant suitable for mapping threads to values). More precisely, the rendezvous is implemented in each case by atomicity of the core. > The thread can set a weak table in its specific if for key/value access. But it's only composable to the degree that everyone who can seet a thread uses the weak hash table... From jay.mccarthy at gmail.com Tue Mar 3 15:03:18 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Tue Mar 3 15:03:41 2009 Subject: [plt-dev] PLT Web Server: Stateless & Traditional Compatibility Message-ID: The stateless and traditional Web server APIs are now more compatible. The stateless offers versions of send/suspend etc that don't use URL structs. The traditional offers versions that do. Jay -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From vyzo at media.mit.edu Tue Mar 3 15:05:04 2009 From: vyzo at media.mit.edu (Dimitris Vyzovitis) Date: Tue Mar 3 15:05:25 2009 Subject: [plt-dev] thread-specifics [PATCH] In-Reply-To: <20090303195101.AF8926500FA@mail-svr1.cs.utah.edu> References: <20090303193504.953D56500C6@mail-svr1.cs.utah.edu> <20090303195101.AF8926500FA@mail-svr1.cs.utah.edu> Message-ID: On Tue, 3 Mar 2009, Matthew Flatt wrote: > At Tue, 3 Mar 2009 14:39:39 -0500 (EST), Dimitris Vyzovitis wrote: >> On Tue, 3 Mar 2009, Matthew Flatt wrote: >> >>> Is there a reason this needs to be built in, instead of implemented as >>> a weak hash table? >> >> There is no rendezvous needed to access the specific, because it is >> attached to the thread (a public readonly cell), simplifying things with >> barriers, tagging, etc. > > There's also no rendezvous for an `eq?'-based weak hash table (which is > the variant suitable for mapping threads to values). > > More precisely, the rendezvous is implemented in each case by atomicity > of the core. Well, I take it you mean having a global weak-hash table here? That is rendezvous in itself, because it has to be accessed and implement a synchronization protocol to it. The specific is not weak - it is a thread-attached property that can be written only by the thread itself (thus communicating internal state information) and read by every other thread that has a reference to it. As a primitive, the specific is a low level synchronization primitive, with the function of volatile synchronous broadcasts [and it has associated event semantics by being attached to a thread]. >> The thread can set a weak table in its specific if for key/value access. > > But it's only composable to the degree that everyone who can seet a > thread uses the weak hash table... Well, the specific a hash-table by default; But I don't think that weakness of keys should be enforced at such low level, and in general I prefer to keep most general nature of the primitive. -- vyzo From mflatt at cs.utah.edu Tue Mar 3 15:17:26 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Tue Mar 3 15:17:48 2009 Subject: [plt-dev] thread-specifics [PATCH] In-Reply-To: References: <20090303193504.953D56500C6@mail-svr1.cs.utah.edu> <20090303195101.AF8926500FA@mail-svr1.cs.utah.edu> Message-ID: <20090303201726.517396500A8@mail-svr1.cs.utah.edu> At Tue, 3 Mar 2009 15:05:04 -0500 (EST), Dimitris Vyzovitis wrote: > On Tue, 3 Mar 2009, Matthew Flatt wrote: > > > At Tue, 3 Mar 2009 14:39:39 -0500 (EST), Dimitris Vyzovitis wrote: > >> On Tue, 3 Mar 2009, Matthew Flatt wrote: > >> > >>> Is there a reason this needs to be built in, instead of implemented as > >>> a weak hash table? > >> > >> There is no rendezvous needed to access the specific, because it is > >> attached to the thread (a public readonly cell), simplifying things with > >> barriers, tagging, etc. > > > > There's also no rendezvous for an `eq?'-based weak hash table (which is > > the variant suitable for mapping threads to values). > > > > More precisely, the rendezvous is implemented in each case by atomicity > > of the core. > > Well, I take it you mean having a global weak-hash table here? Yes. > That is > rendezvous in itself, because it has to be accessed and implement a > synchronization protocol to it. I concede that when you share anything, whether a hash table or a thread references, that there is some sort of rendezvous. But I don't see why it's more of a problem with a hash table. > The specific is not weak - it is a thread-attached property that can > be written only by the thread itself (thus communicating internal state > information) and read by every other thread that has a reference to it. I mean that the table weakly holds thread references as keys, which is the usual trick for adding a "field" to an object without changing the object representation. The specific value should be strongly held, I imagine. > As a primitive, the specific is a low level synchronization primitive, > with the function of volatile synchronous broadcasts [and it has > associated event semantics by being attached to a thread]. I still believe that this is equally true of `hash-set!' and `hash-ref'. > >> The thread can set a weak table in its specific if for key/value access. > > > > But it's only composable to the degree that everyone who can seet a > > thread uses the weak hash table... > > Well, the specific a hash-table by default; But I don't think that > weakness of keys should be enforced at such low level, and in general > I prefer to keep most general nature of the primitive. I think we must be talking past each other. To me, it seems like we already have a suitable general mechanism for extending objects externally, which is an `eq?'-based hash table with weakly held keys. From vyzo at media.mit.edu Tue Mar 3 15:29:44 2009 From: vyzo at media.mit.edu (Dimitris Vyzovitis) Date: Tue Mar 3 15:30:06 2009 Subject: [plt-dev] thread-specifics [PATCH] In-Reply-To: <20090303201726.517396500A8@mail-svr1.cs.utah.edu> References: <20090303193504.953D56500C6@mail-svr1.cs.utah.edu> <20090303195101.AF8926500FA@mail-svr1.cs.utah.edu> <20090303201726.517396500A8@mail-svr1.cs.utah.edu> Message-ID: On Tue, 3 Mar 2009, Matthew Flatt wrote: >> Well, I take it you mean having a global weak-hash table here? > > Yes. > >> That is >> rendezvous in itself, because it has to be accessed and implement a >> synchronization protocol to it. > > I concede that when you share anything, whether a hash table or a > thread references, that there is some sort of rendezvous. But I don't > see why it's more of a problem with a hash table. I can see a few problems here: 1) The key in the value problem - the threads may well refer to themselves this complicates the access patterns in the hashtable 2) Access permissions There is concurrency involved in the updates. The specific access protocol provides memory consistent: The owner thread can write atomically Everybody can read atomically and always sees the last value placed by the owner in trace causality sense. The specific is asynchronous and very very cheap. In addition, the fact that specific is a slot that makes a lightweight tool (without having to go to all this) for easily implementing common synchronization patterns: barriers, async completion tokens, thread tags, etc >> Well, the specific a hash-table by default; But I don't think that >> weakness of keys should be enforced at such low level, and in general >> I prefer to keep most general nature of the primitive. > > I think we must be talking past each other. To me, it seems like we > already have a suitable general mechanism for extending objects > externally, which is an `eq?'-based hash table with weakly held keys. I am arguing that the extant solution (the weak hash) does not provide the functionality specifics provide without significant implementation complexities. Also, with regards to composition: by limiting the specific to a single cell, the compositional properties can be managed at the language level (scheme/base) where you are not limited by what you can reasonably do in the core. -- vyzo From eli at barzilay.org Tue Mar 3 15:35:36 2009 From: eli at barzilay.org (Eli Barzilay) Date: Tue Mar 3 15:35:57 2009 Subject: [plt-dev] Re: [Issue 3242] svn 1.5 want access to root with no reason. In-Reply-To: <20090303191505.7AA0C7B04E9@sc157-tigr.sjc.collab.net> References: <20090303191505.7AA0C7B04E9@sc157-tigr.sjc.collab.net> Message-ID: <18861.38040.70858.348632@winooski.ccs.neu.edu> This is a bit from the discussion about the svn bug, which might be a useful tip for times when you run into the svn bug: On Mar 3, kan@tigris.org wrote: > As I noticed, "svn up" may give the problem if some new files were > added in repo. And it's interesting, if "svn up" doesn't work, you > can make "svn switch" to the same url, it will update all with no > problems. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From pltscheme at pnkfx.org Tue Mar 3 15:39:54 2009 From: pltscheme at pnkfx.org (Felix Klock's PLT scheme proxy) Date: Tue Mar 3 15:40:14 2009 Subject: [plt-dev] overriding constructor style printing Message-ID: PLT developers- If I am developing a teachpack that is intended for use with the Student languages (Beginning Student et al), how do I override how structures I define are printed? Searching the documentation for "constructor style printing" sent me to the mzlib/pconvert library, and I figured out how to achieve this when one is using the install-converting-printer procedure to turn on constructor style printing. But then when I tried to require my module as a teachpack into Student code, it continued to print using the internal structure constructor name. ---- By the way, its really hard to understand the current mzlib/pconvert documentation. But my current hypothesis is that I was wrong to try to adapt that library for this goal anyway; it seems like it is totally orthogonal to how the Student languages accomplish constructor style printing. So perhaps the mzlib/pconvert library is deprecated and the state of its documentation is irrelevant. ---- Example Code to illustrate what I am talking about: ;;; FILE: bug.ss #lang scheme (provide external) (require mzlib/pconvert) ; (install-converting-printer) (define-struct internal (value) #:transparent) (define (external v) (make-internal v)) (current-print-convert-hook (let ((old-hook (current-print-convert-hook))) (lambda (v basic-convert sub-convert) (if (internal? v) `(external ,(sub-convert (internal-value v))) (old-hook v basic-convert sub-convert))))) ;;; END OF FILE bug.ss ;;; FILE: bug2.ss (require "bug.ss") ;; EXPRESSION DESIRED-OUTPUT ACTUAL-OUTPUT (external 3) ; (external 3) (make-internal 3) ;;; END OF FILE bug2.ss -Felix From grettke at acm.org Tue Mar 3 15:51:58 2009 From: grettke at acm.org (Grant Rettke) Date: Tue Mar 3 15:52:16 2009 Subject: [plt-dev] Re: [Issue 3242] svn 1.5 want access to root with no reason. In-Reply-To: <18861.38040.70858.348632@winooski.ccs.neu.edu> References: <20090303191505.7AA0C7B04E9@sc157-tigr.sjc.collab.net> <18861.38040.70858.348632@winooski.ccs.neu.edu> Message-ID: <756daca50903031251w53ec80f7i2353aa63a51ee2c3@mail.gmail.com> On Tue, Mar 3, 2009 at 2:35 PM, Eli Barzilay wrote: > This is a bit from the discussion about the svn bug, which might be a > useful tip for times when you run into the svn bug: > > On Mar ?3, kan@tigris.org wrote: >> As I noticed, "svn up" may give the problem if some new files were >> added in repo. ?And it's interesting, if "svn up" doesn't work, you >> can make "svn switch" to the same url, it will update all with no >> problems. Is this SVN issue number 3242? We experienced the same thing at work after this thread began. Based on what they said in the comments; the client code ignores the security model on some operations but not others. From mflatt at cs.utah.edu Tue Mar 3 15:52:08 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Tue Mar 3 15:52:53 2009 Subject: [plt-dev] thread-specifics [PATCH] In-Reply-To: References: <20090303193504.953D56500C6@mail-svr1.cs.utah.edu> <20090303195101.AF8926500FA@mail-svr1.cs.utah.edu> <20090303201726.517396500A8@mail-svr1.cs.utah.edu> Message-ID: <20090303205209.3CC7A6500A2@mail-svr1.cs.utah.edu> At Tue, 3 Mar 2009 15:29:44 -0500 (EST), Dimitris Vyzovitis wrote: > On Tue, 3 Mar 2009, Matthew Flatt wrote: > > >> Well, I take it you mean having a global weak-hash table here? > > > > Yes. > > > >> That is > >> rendezvous in itself, because it has to be accessed and implement a > >> synchronization protocol to it. > > > > I concede that when you share anything, whether a hash table or a > > thread references, that there is some sort of rendezvous. But I don't > > see why it's more of a problem with a hash table. > > I can see a few problems here: > 1) The key in the value problem - the threads may well refer to themselves > this complicates the access patterns in the hashtable Ephemerons solve this easily. > 2) Access permissions > There is concurrency involved in the updates. > The specific access protocol provides memory consistent: > The owner thread can write atomically > Everybody can read atomically and always sees the last value placed > by the owner in trace causality sense. > The specific is asynchronous and very very cheap. But `hash-ref' and `hash-set!' handle concurrency. > In addition, the fact that specific is a slot that makes a lightweight > tool (without having to go to all this) for easily implementing common > synchronization patterns: barriers, async completion tokens, thread tags, > etc Here's an implementation: #lang scheme/base (provide specific-ref specific-set!) (define specifics (make-weak-hasheq)) (define (specific-ref th [fail (lambda () #f)]) (let ([c (hash-ref specifics th #f)]) (if c (ephemeron-value c) (fail)))) (define (specific-set! th v) (hash-set! specifics th (make-ephemeron th v))) This doesn't seem complex to me. It will be a bit slower than your patch. Still, on my machine, 1M iterations has set and ref takes 0.33 seconds. If I replace the implementation above with the minimal (define v #f) (define (specific-ref th [fail (lambda () #f)]) v) (define (specific-set! th v2) (set! v2 v)) then 1M iterations takes 0.14 seconds. So the implementation seems unlikely to be a performance bottleneck. > Also, with regards to composition: by limiting the specific to a single > cell, the compositional properties can be managed at the language level > (scheme/base) where you are not limited by what you can reasonably do in > the core. This is probably a genuine disagreement. I believe that `scheme/base' is obliged to provide composable abstractions, and not just hooks into the implementation. From eli at barzilay.org Tue Mar 3 15:53:32 2009 From: eli at barzilay.org (Eli Barzilay) Date: Tue Mar 3 15:53:53 2009 Subject: [plt-dev] Re: [Issue 3242] svn 1.5 want access to root with no reason. In-Reply-To: <756daca50903031251w53ec80f7i2353aa63a51ee2c3@mail.gmail.com> References: <20090303191505.7AA0C7B04E9@sc157-tigr.sjc.collab.net> <18861.38040.70858.348632@winooski.ccs.neu.edu> <756daca50903031251w53ec80f7i2353aa63a51ee2c3@mail.gmail.com> Message-ID: <18861.39116.900418.986588@winooski.ccs.neu.edu> On Mar 3, Grant Rettke wrote: > On Tue, Mar 3, 2009 at 2:35 PM, Eli Barzilay wrote: > > This is a bit from the discussion about the svn bug, which might be a > > useful tip for times when you run into the svn bug: > > > > On Mar ?3, kan@tigris.org wrote: > >> As I noticed, "svn up" may give the problem if some new files were > >> added in repo. ?And it's interesting, if "svn up" doesn't work, you > >> can make "svn switch" to the same url, it will update all with no > >> problems. > > Is this SVN issue number 3242? Yes. There are some related issues (see the full page for ones that are marked as duplicates.) > We experienced the same thing at work after this thread began. > > Based on what they said in the comments; the client code ignores the > security model on some operations but not others. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From mflatt at cs.utah.edu Tue Mar 3 16:00:49 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Tue Mar 3 16:01:17 2009 Subject: [plt-dev] overriding constructor style printing In-Reply-To: References: Message-ID: <20090303210049.DC1816500BA@mail-svr1.cs.utah.edu> At Tue, 3 Mar 2009 15:39:54 -0500, Felix Klock's PLT scheme proxy wrote: > Example Code to illustrate what I am talking about: > > ;;; FILE: bug.ss > #lang scheme > (provide external) > (require mzlib/pconvert) > ; (install-converting-printer) > (define-struct internal (value) #:transparent) > (define (external v) (make-internal v)) > (current-print-convert-hook > (let ((old-hook (current-print-convert-hook))) > (lambda (v basic-convert sub-convert) > (if (internal? v) > `(external ,(sub-convert (internal-value v))) > (old-hook v basic-convert sub-convert))))) > ;;; END OF FILE bug.ss > > ;;; FILE: bug2.ss > (require "bug.ss") > > ;; EXPRESSION DESIRED-OUTPUT ACTUAL-OUTPUT > (external 3) ; (external 3) (make-internal 3) > > ;;; END OF FILE bug2.ss I think you want to implement the `prop:print-convert-constructor-name' property: #lang scheme (provide external) (require mzlib/pconvert-prop) (define-struct internal (value) #:transparent #:property prop:print-convert-constructor-name 'external) (define (external v) (make-internal v)) From vyzo at media.mit.edu Tue Mar 3 16:07:08 2009 From: vyzo at media.mit.edu (Dimitris Vyzovitis) Date: Tue Mar 3 16:07:28 2009 Subject: [plt-dev] thread-specifics [PATCH] In-Reply-To: <20090303205209.3CC7A6500A2@mail-svr1.cs.utah.edu> References: <20090303193504.953D56500C6@mail-svr1.cs.utah.edu> <20090303195101.AF8926500FA@mail-svr1.cs.utah.edu> <20090303201726.517396500A8@mail-svr1.cs.utah.edu> <20090303205209.3CC7A6500A2@mail-svr1.cs.utah.edu> Message-ID: On Tue, 3 Mar 2009, Matthew Flatt wrote: >> Also, with regards to composition: by limiting the specific to a single >> cell, the compositional properties can be managed at the language level >> (scheme/base) where you are not limited by what you can reasonably do in >> the core. > > This is probably a genuine disagreement. I believe that `scheme/base' > is obliged to provide composable abstractions, and not just hooks into > the implementation. I think that's what I was saying: scheme/base can provide what is the best abstraction through the kernel hook; you are more limited when implemented in kernel. -- vyzo From robby at eecs.northwestern.edu Tue Mar 3 16:20:42 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Tue Mar 3 16:21:03 2009 Subject: [plt-dev] thread-specifics [PATCH] In-Reply-To: References: <20090303193504.953D56500C6@mail-svr1.cs.utah.edu> <20090303195101.AF8926500FA@mail-svr1.cs.utah.edu> <20090303201726.517396500A8@mail-svr1.cs.utah.edu> <20090303205209.3CC7A6500A2@mail-svr1.cs.utah.edu> Message-ID: <932b2f1f0903031320v46562dc5h1e2b00efcf5bf722@mail.gmail.com> On Tue, Mar 3, 2009 at 3:07 PM, Dimitris Vyzovitis wrote: > On Tue, 3 Mar 2009, Matthew Flatt wrote: > >>> Also, with regards to composition: by limiting the specific to a single >>> cell, the compositional properties can be managed at the language level >>> (scheme/base) where you are not limited by what you can reasonably do in >>> the core. >> >> This is probably a genuine disagreement. I believe that `scheme/base' >> is obliged to provide composable abstractions, and not just hooks into >> the implementation. > > I think that's what I was saying: scheme/base can provide what is the best > abstraction through the kernel hook; you are more limited when implemented > in kernel. This conversation is confusing, but I think Matthew is saying that mzscheme's kernel is already providing a sufficient set of abstractions. No need for more. Robby From vyzo at media.mit.edu Tue Mar 3 16:22:00 2009 From: vyzo at media.mit.edu (Dimitris Vyzovitis) Date: Tue Mar 3 16:22:28 2009 Subject: [plt-dev] thread-specifics [PATCH] In-Reply-To: <932b2f1f0903031320v46562dc5h1e2b00efcf5bf722@mail.gmail.com> References: <20090303193504.953D56500C6@mail-svr1.cs.utah.edu> <20090303195101.AF8926500FA@mail-svr1.cs.utah.edu> <20090303201726.517396500A8@mail-svr1.cs.utah.edu> <20090303205209.3CC7A6500A2@mail-svr1.cs.utah.edu> <932b2f1f0903031320v46562dc5h1e2b00efcf5bf722@mail.gmail.com> Message-ID: On Tue, 3 Mar 2009, Robby Findler wrote: > This conversation is confusing, but I think Matthew is saying that > mzscheme's kernel is already providing a sufficient set of > abstractions. No need for more. I conceded this by not arguing further :p -- vyzo From robby at eecs.northwestern.edu Tue Mar 3 16:24:04 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Tue Mar 3 16:24:22 2009 Subject: [plt-dev] thread-specifics [PATCH] In-Reply-To: References: <20090303195101.AF8926500FA@mail-svr1.cs.utah.edu> <20090303201726.517396500A8@mail-svr1.cs.utah.edu> <20090303205209.3CC7A6500A2@mail-svr1.cs.utah.edu> <932b2f1f0903031320v46562dc5h1e2b00efcf5bf722@mail.gmail.com> Message-ID: <932b2f1f0903031324j5a1dca50rb0de03e445bd5ac8@mail.gmail.com> On Tue, Mar 3, 2009 at 3:22 PM, Dimitris Vyzovitis wrote: > On Tue, 3 Mar 2009, Robby Findler wrote: > >> This conversation is confusing, but I think Matthew is saying that >> mzscheme's kernel is already providing a sufficient set of >> abstractions. No need for more. > > I conceded this by not arguing further :p Is that the contrapositive of proof by authority? ;) Robby From pltscheme at pnkfx.org Tue Mar 3 17:17:16 2009 From: pltscheme at pnkfx.org (Felix Klock's PLT scheme proxy) Date: Tue Mar 3 17:17:38 2009 Subject: [plt-dev] overriding constructor style printing In-Reply-To: <20090303210049.DC1816500BA@mail-svr1.cs.utah.edu> References: <20090303210049.DC1816500BA@mail-svr1.cs.utah.edu> Message-ID: <7B0F5A51-CF38-4473-8F72-65FB276137EB@pnkfx.org> Matthew (cc'ing plt-dev)- On Mar 3, 2009, at 4:00 PM, Matthew Flatt wrote: > I think you want to implement the `prop:print-convert-constructor- > name' > property: > > #lang scheme > (provide external) > (require mzlib/pconvert-prop) > (define-struct internal (value) #:transparent > #:property prop:print-convert-constructor-name 'external) > (define (external v) (make-internal v)) I looked into that option, but it is not sufficiently general for my goal. I think reducing my issue down to a simpler test case for presentation to the list was a mistake; I've corrected that mistake at the end of this email. ---- I do not want to expose the internal structure at all; I want an abstract view of the fields it contains. In general, the designer of an abstract data type wants to only provide an abstract view of that type. Sometimes that goal conflicts with constructor-style printing, but not always. In my particular case, I am trying to develop a multiset abstraction, ``bag''. The primary constructor for bag (or ``pseudo-constructor'' if you prefer) is a *procedure* and not one of the constructors resulting from a define-struct special form. The pseudo-constructor for bag has an interface analogous to that of the list procedure. Internally a bag is represented by a structure, unordered, with one field (which itself holds a list). But I do not want my external student clients to see that view; I want them only to see an expression involving the bag pseudo-constructor, and the exported operations on the bag abstraction. ---- So, back to my question: "if I am developing a teachpack that is intended for use with the Student languages (Beginning Student et al), how do I override how structures I define are printed?" I have attached the code I have below so you can see concretely what I am talking about. The end goal here is that I want the following to work as follows at the Interactions Window: > (bag 1 2) (bag 1 2) but I cannot figure out how to get that effect in the Student languages. (I *can* get it via the mzlib/pconvert library alone.) At this point I have employed the prop:print-convert-constructor-name property to implement the following approximation: > (bag 1 2) (make-bag (list 1 2)) but this does not satisfy me. -Felix Here is the relevant code: ;;; FILE: bag.ss #lang scheme (provide bag bag? bag-contains? bag-choose bag-choose-first bag-choose-rest bag-length bag-union bag-map bag-fold subbag?) (require mzlib/pconvert) (require mzlib/pconvert-prop) #| (install-converting-printer) |# ;; A [Bagof X] is a (make-unordered [Listof X]) ;; interpretation: ;; a (make-unordered (list x1 x2 .. xN) is a multiset containing N elements (define-struct unordered (elems) #:property prop:equal+hash (let ((hasher (lambda (b hash) (foldr (lambda (x n) (bitwise-ior (hash x) n)) 0)))) (list (lambda (b1 b2 equal?) (and (= (bag-length b1) (bag-length b2)) (subbag? b1 b2) (subbag? b2 b1))) hasher hasher)) #:property prop:custom-write (lambda (b p write-mode) (let ((p* (open-output-string))) (if write-mode (write (unordered-elems b) p*) (display (unordered-elems b) p*)) (write-string "#" p))) #:property prop:print-convert-constructor-name 'make-bag #:transparent ) (current-print-convert-hook (let ((old-hook (current-print-convert-hook))) (lambda (v basic-convert sub-convert) (if (bag? v) `(bag ,@(map sub-convert (unordered-elems v))) (old-hook v basic-convert sub-convert))))) (define (bag? x) (unordered? x)) ;; subbag? : [Bagof X] [Bagof X] -> Boolean (define (subbag? b1 b2) (andmap (lambda (x) (bag-contains? b2 x)) (unordered-elems b1))) ;; bag-contains? : [Bagof X] X -> Boolean (define (bag-contains? b x) (not (not (member x (unordered-elems b))))) ;; bag : X ... -> [Bagof X] (define (bag . l) (make-unordered l)) ;; bag-choose : [Bagof X] -> (values X [Bagof X]) (define (bag-choose b) (values (car (unordered-elems b)) (make-unordered (cdr (unordered-elems b))))) ;; bag-choose-first : [Bagof X] -> X (define (bag-choose-first b) (call-with-values (lambda () (bag-choose b)) (lambda (x b*) x))) ;; bag-choose-rest : [Bagof X] -> [Bagof X] (define (bag-choose-rest b) (call-with-values (lambda () (bag-choose b)) (lambda (x b*) b*))) ;; bag-length : [Bagof X] -> Nat (define (bag-length b) (length (unordered-elems b))) ;; bag-union : [Bagof X] ... -> [Bagof X] (define (bag-union . l) (make-unordered (append-map unordered-elems l))) ;; bag-map : (X -> Y) [Bagof X] -> [Bagof Y] (define (bag-map f b) (make-unordered (map f (unordered-elems b)))) ;; bag-append-map : (X -> [Bagof Y]) [Bagof X] -> [Bagof Y] (define (bag-append-map f b) (foldr bag-union (bag) (map f (unordered-elems b)))) ;; bag-fold : (X Y -> Y) Y [Bagof X] -> Y (define (bag-fold f z b) (foldr f z (unordered-elems b))) ;; build-bag : Nat (Nat -> X) -> [Bagof X] (define (build-bag n f) (make-unordered (build-list n f))) ;;; END OF FILE bag.ss ;; The first three lines of this file were inserted by DrScheme. They record metadata ;; about the language level of this file in a form that our tools can easily process. #reader(lib "htdp-intermediate-lambda-reader.ss" "lang")((modname arrangements) (read-case-sensitive #t) (teachpacks ((lib "world.ss" "teachpack" "htdp"))) (htdp-settings #(#t constructor repeating- decimal #f #t none #f ((lib "world.ss" "teachpack" "htdp"))))) ;;; FILE: arrangements.ss (require "bag.ss") ;; A Word is a [Listof Symbol] ;; all-placements : Symbol Word -> [Bagof Word] (check-expect (all-placements 's '()) (bag '(s))) (check-expect (all-placements 's '(a)) (bag '(s a) '(a s))) (check-expect (all-placements 's '(a b)) (bag '(s a b) '(a s b) '(a b s))) (define (all-placements s w) (cond ((empty? w) (bag (list s))) (else (bag-union (bag (cons s w)) (bag-map (lambda (w*) (cons (first w) w*)) (all-placements s (rest w))))))) ;; arrangements : Word -> [Bagof Word] ;; produces all permutations of a-word (check-expect (arrangements empty) (bag empty)) (check-expect (arrangements (list 'd)) (bag (list 'd))) (check-expect (arrangements (list 'c 'd)) (bag (list 'c 'd) (list 'd 'c))) (check-expect (arrangements (list 'c 'd)) (bag (list 'd 'c) (list 'c 'd))) (define (arrangements x) (cond ((empty? x) (bag empty)) (else (bag-fold (lambda (w* b) (bag-union (all-placements (first x) w*) b)) (bag) (arrangements (rest x)))))) ;;; END OF FILE arrangements.ss From mflatt at cs.utah.edu Tue Mar 3 17:38:57 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Tue Mar 3 17:39:15 2009 Subject: [plt-dev] overriding constructor style printing In-Reply-To: <7B0F5A51-CF38-4473-8F72-65FB276137EB@pnkfx.org> References: <20090303210049.DC1816500BA@mail-svr1.cs.utah.edu> <7B0F5A51-CF38-4473-8F72-65FB276137EB@pnkfx.org> Message-ID: <20090303223857.529066500AF@mail-svr1.cs.utah.edu> At Tue, 3 Mar 2009 17:17:16 -0500, Felix Klock's PLT scheme proxy wrote: > I do not want to expose the internal structure at all; I want an > abstract view of the fields it contains. In general, the designer of > an abstract data type wants to only provide an abstract view of that > type. Sometimes that goal conflicts with constructor-style printing, > but not always. My initial response to your earlier message was: Probably print-convert needs to recognize a property that gives you more control over the conversion, much like `prop:custom-write' gives you control over `write' and `display' output. So, that was probably the right answer after all, since the limited property that's already available doesn't work well enough. I can add that property. Meanwhile, I don't have an answer that works with the current version. From mflatt at cs.utah.edu Tue Mar 3 21:55:39 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Tue Mar 3 21:56:00 2009 Subject: [plt-dev] overriding constructor style printing In-Reply-To: <7B0F5A51-CF38-4473-8F72-65FB276137EB@pnkfx.org> References: <20090303210049.DC1816500BA@mail-svr1.cs.utah.edu> <7B0F5A51-CF38-4473-8F72-65FB276137EB@pnkfx.org> Message-ID: <20090304025540.B45316500BA@mail-svr1.cs.utah.edu> I've added `prop:print-converter' to `mzlib/pconvert-prop' in SVN. You can use it like this: (define-struct unordered (elems) .... #:property prop:print-converter (lambda (v recur) `(bag ,@(map recur (unordered-elems v)))) ....) From yinso.chen at gmail.com Wed Mar 4 02:05:10 2009 From: yinso.chen at gmail.com (YC) Date: Wed Mar 4 02:05:31 2009 Subject: [plt-dev] web-server redirect behavior and possible patch Message-ID: <779bf2730903032305m57f14d9dkecc4a7c9755f2413@mail.gmail.com> I just noticed that if empty string "" is passed into `(redirect-to)`, the response will not include a Location header (even though the header object exists in the response object generated by `(redirect-to)`. While passing in empty string is a client bug, perhaps it's better to simply stop the input in the first place? If so - below is a plausible patch for web-server/http/redirect.ss Thanks, yc --- /usr/local/plt/lib/plt/collects/web-server/http/redirect.ss 2008-11-16 11:34:46.000000000 -0800 +++ plt-scheme/web-server/http/redirect.ss 2009-03-03 23:00:10.000000000 -0800 @@ -24,7 +24,8 @@ (provide/contract [redirect-to - (->* (string?) (redirection-status? #:headers (listof header?)) + (->* ((and/c string? (lambda (s) (> (string-length s) 0)))) + (redirection-status? #:headers (listof header?)) response/full?)] [redirection-status? (any/c . -> . boolean?)] [permanently redirection-status?] -------------- next part -------------- An HTML attachment was scrubbed... URL: http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090303/0fcd0f32/attachment.html From rafkind at cs.utah.edu Thu Mar 5 00:13:46 2009 From: rafkind at cs.utah.edu (Jon Rafkind) Date: Thu Mar 5 00:14:24 2009 Subject: [plt-dev] redex words flipped Message-ID: <49AF5F8A.4010203@cs.utah.edu> In redex, when A reduces to B such that an arrow points to B from A and A is in quadrants 1 or 4 relative to B, the text is flipped. Here is a screenshot http://www.cs.utah.edu/~rafkind/tmp/redex.png From d.j.gurnell at gmail.com Thu Mar 5 14:22:41 2009 From: d.j.gurnell at gmail.com (Dave Gurnell) Date: Thu Mar 5 14:30:28 2009 Subject: [plt-dev] file/zip file sizes Message-ID: <18AEA650-9A4C-449C-BA3A-C8F45AE06B4D@gmail.com> Hi all, I remember someone mentioning the size of ZIP files created with file/ zip a while back. I can't remember the context, though, and I can't find the post in my archives. Anyway, I just created a lot of ZIP files with file/zip, and unzipping and rezipping them on the command line saved a lot of space. Does anyone remember the resolution of the original ZIP-related post? Cheers, -- Dave From eli at barzilay.org Thu Mar 5 17:42:56 2009 From: eli at barzilay.org (Eli Barzilay) Date: Thu Mar 5 17:43:17 2009 Subject: [plt-dev] file/zip file sizes In-Reply-To: <18AEA650-9A4C-449C-BA3A-C8F45AE06B4D@gmail.com> References: <18AEA650-9A4C-449C-BA3A-C8F45AE06B4D@gmail.com> Message-ID: <18864.21872.720350.804634@winooski.ccs.neu.edu> On Mar 5, Dave Gurnell wrote: > Hi all, > > I remember someone mentioning the size of ZIP files created with > file/ zip a while back. I can't remember the context, though, and I > can't find the post in my archives. > > Anyway, I just created a lot of ZIP files with file/zip, and > unzipping and rezipping them on the command line saved a lot of > space. > > Does anyone remember the resolution of the original ZIP-related > post? There was none. The zip functionality is implementd in collects/mzlib/zip.ss, which uses collects/mzlib/deflate.ss to do the compression work. That last module is a direct translation of the gzip code (and as a result, it's not as fast as you could get with more idiomatic Scheme code). It does have a LEVEL definition which corresponds to the compression level argument for gzip, and I tried to tweak that to see what happens. To my surprise, I discovered a bug that I introduced a long time ago -- which made it do almost no compression (or maybe none at all). But the result still had valid format so it wasn't discovered. I fixed that, and made some other minor improvements (mainly changed more vectors to byte string -- the code is old enough that it precedes byte strings). A quick summary of gzipping a large (10M) text file on my machine: Before the bug fix: cpu time: 3879; size: 4938648 = 49.4% After fixing it: cpu time: 4497; size: 2226952 = 22.2% After switching to use more byte strings: cpu time: 4373 And when tweaking the LEVEL I get: level = 1 -- cpu time: 3153; size: 2545842 = 25.5% level = 9 -- cpu time: 9844; size: 2195097 = 22.0% So it looks like there is no point in changing the level. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From d.j.gurnell at gmail.com Fri Mar 6 03:58:58 2009 From: d.j.gurnell at gmail.com (Dave Gurnell) Date: Fri Mar 6 04:00:07 2009 Subject: [plt-dev] file/zip file sizes In-Reply-To: <18864.21872.720350.804634@winooski.ccs.neu.edu> References: <18AEA650-9A4C-449C-BA3A-C8F45AE06B4D@gmail.com> <18864.21872.720350.804634@winooski.ccs.neu.edu> Message-ID: >> It does have a LEVEL definition which corresponds to the compression > level argument for gzip, and I tried to tweak that to see what > happens. To my surprise, I discovered a bug that I introduced a long > time ago -- which made it do almost no compression (or maybe none at > all). But the result still had valid format so it wasn't discovered. > > I fixed that, and made some other minor improvements [...] That's great news! I'll grab the code and check it out. Many thanks, -- Dave From jay.mccarthy at gmail.com Fri Mar 6 11:41:51 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Fri Mar 6 11:42:26 2009 Subject: [plt-dev] Scribble "problem" Message-ID: In the HTML renderer, the 'toc style isn't observed if 'multi-page (or --htmls) isn't also on, but if either of those is used, there is no way to keep top-level sections on one page. I'm rewriting my course site in Scribble. I'd like to have the top-level sections be on one page, but I want all the assignment sub-sections on separate pages. So, I put 'toc in the style of assignment section and leave the top-level without it. Neither --html or --htmls gets it right. I'm willing to patch it, but it is hard to follow how the multi-page render in scribble/html-render does its thing. 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 Fri Mar 6 12:35:32 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Fri Mar 6 12:35:51 2009 Subject: [plt-dev] Scribble "problem" In-Reply-To: References: Message-ID: <20090306173532.68F056500AE@mail-svr1.cs.utah.edu> At Fri, 6 Mar 2009 09:41:51 -0700, Jay McCarthy wrote: > In the HTML renderer, the 'toc style isn't observed if 'multi-page (or > --htmls) isn't also on, but if either of those is used, there is no > way to keep top-level sections on one page. I've added support for a 'non-toc style that applies just to the top page for --htmls rendering. From jay.mccarthy at gmail.com Fri Mar 6 13:09:42 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Fri Mar 6 13:10:11 2009 Subject: [plt-dev] Scribble "problem" In-Reply-To: <20090306173532.68F056500AE@mail-svr1.cs.utah.edu> References: <20090306173532.68F056500AE@mail-svr1.cs.utah.edu> Message-ID: Thanks! It works well. Two things I noticed though. The toc on the upper-left is by default collapsed. I can't see in the docs where to control that. The other thing is in the one section where I have 'toc, the first sub-section's prev link tries to go to the now non-existent page. Ditto with the last next link. Jay On Fri, Mar 6, 2009 at 10:35 AM, Matthew Flatt wrote: > At Fri, 6 Mar 2009 09:41:51 -0700, Jay McCarthy wrote: >> In the HTML renderer, the 'toc style isn't observed if 'multi-page (or >> --htmls) isn't also on, but if either of those is used, there is no >> way to keep top-level sections on one page. > > I've added support for a 'non-toc style that applies just to the top > page for --htmls rendering. > > -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From mflatt at cs.utah.edu Fri Mar 6 13:43:16 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Fri Mar 6 13:43:38 2009 Subject: [plt-dev] Scribble "problem" In-Reply-To: References: <20090306173532.68F056500AE@mail-svr1.cs.utah.edu> Message-ID: <20090306184316.4944865008D@mail-svr1.cs.utah.edu> These should be fixed, now. At least, I think they behave sensibly. Instead of making the ToC uncollapsed, the sections show up in the "on this page" ToC. The redundancy there was always bothered me a little, but it's at least consistent redundancy for now. At Fri, 6 Mar 2009 11:09:42 -0700, Jay McCarthy wrote: > Thanks! It works well. > > Two things I noticed though. The toc on the upper-left is by default > collapsed. I can't see in the docs where to control that. The other > thing is in the one section where I have 'toc, the first sub-section's > prev link tries to go to the now non-existent page. Ditto with the > last next link. > > Jay > > On Fri, Mar 6, 2009 at 10:35 AM, Matthew Flatt wrote: > > At Fri, 6 Mar 2009 09:41:51 -0700, Jay McCarthy wrote: > >> In the HTML renderer, the 'toc style isn't observed if 'multi-page (or > >> --htmls) isn't also on, but if either of those is used, there is no > >> way to keep top-level sections on one page. > > > > I've added support for a 'non-toc style that applies just to the top > > page for --htmls rendering. > > > > > > > > -- > 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 Fri Mar 6 13:52:37 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Fri Mar 6 13:53:16 2009 Subject: [plt-dev] Scribble "problem" In-Reply-To: <20090306184316.4944865008D@mail-svr1.cs.utah.edu> References: <20090306173532.68F056500AE@mail-svr1.cs.utah.edu> <20090306184316.4944865008D@mail-svr1.cs.utah.edu> Message-ID: Nice! Looks great! On Fri, Mar 6, 2009 at 11:43 AM, Matthew Flatt wrote: > These should be fixed, now. At least, I think they behave sensibly. > > Instead of making the ToC uncollapsed, the sections show up in the "on > this page" ToC. The redundancy there was always bothered me a little, > but it's at least consistent redundancy for now. > > At Fri, 6 Mar 2009 11:09:42 -0700, Jay McCarthy wrote: >> Thanks! It works well. >> >> Two things I noticed though. The toc on the upper-left is by default >> collapsed. I can't see in the docs where to control that. The other >> thing is in the one section where I have 'toc, the first sub-section's >> prev link tries to go to the now non-existent page. Ditto with the >> last next link. >> >> Jay >> >> On Fri, Mar 6, 2009 at 10:35 AM, Matthew Flatt wrote: >> > At Fri, 6 Mar 2009 09:41:51 -0700, Jay McCarthy wrote: >> >> In the HTML renderer, the 'toc style isn't observed if 'multi-page (or >> >> --htmls) isn't also on, but if either of those is used, there is no >> >> way to keep top-level sections on one page. >> > >> > I've added support for a 'non-toc style that applies just to the top >> > page for --htmls rendering. >> > >> > >> >> >> >> -- >> 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 Fri Mar 6 14:36:08 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri Mar 6 14:36:29 2009 Subject: [plt-dev] "poll": scribble syntax & indentation Message-ID: <18865.31528.532054.708649@winooski.ccs.neu.edu> This is not really a poll, but rather a long winded attempt to see if anyone has any good ideas for a solution. (Or me thinking out loud.) I've been staring at this problem for a while now, and I'm slowly converging on a solution that is not as good as I'd hope. The problem is that trying to use the scribble syntax for cases where indentation matters is difficult right now. This is most obvious if you try to do use the scribble/text preprocessor language to generate code. [It doesn't come up with the usual documentation languages, because they're mostly insensitive for indentation -- but it might be an issue in the future there too, if there is some @scheme{...} macro that operates on the raw text (like drscheme) rather than the current @scheme[...] which uses syntax source information (like slideshow).] For example, this: #lang scribble/text function foo() { @list{if (1 < 2) something1 else something2 fi } return } will not come out right. What's missing is some function to use instead of `list' which will somehow grab its initial output column and use it for all nested newlines. The scribble reader does put syntax properties on what it reads which makes it seem like there is some solution that involves a macro which will use that information, but that won't work in general because the *source* of the misindented text can come from a different part of the code -- one that is at an arbitrarily different position. An example of this (the @@if{text1}{text2}{text3} uses a curried `if' binding, each block of text happens at a different curried level) is: #!/bin/env mzscheme #lang scribble/text @(define (((if . c) . t) . e) @list{ if (@c) @t else @e}) function foo() { @list{if (1 < 2) something1 else @@@if{2<3}{something2}{something3} repeat 3 { @@@if{2<3}{something2}{something3} } fi } return } In this example the `if' function is used in two different places, each with a different indentation -- and the definition obviously has a fixed indentation. This makes me think that as much as I'd wish this to be done at syntax time through a macro, I'd have to do something dynamic -- some `with-indentation' function which knows where in the output stream it should be printed, and adds this to newlines in its body. Even worse, it will need to divert its body to a temporary buffer, then convert the newlines there because you could just as well produce newlines in Scheme expressions instead of being part of the input -- for example, if this was used above: @@@if{2<3}{@"something2.1\nsomething2.2"}{something3} then you'd probably want that newline to get the right indentation injected too. The first reason that I don't like this soution is that it will be specific to the preprocessor output functionality, which will need to turn on location tracking and make the location available for that `with-indentation' function. But it gets even more complicated. Consider this example: #lang scribble/text function foo() { var lst = [@list{item1, item2}] // @list{comment1 comment2} return } Ideally, this should output: function foo() { var lst = [item1, item2] // comment1 // comment2 return } which means that there should be two functions: the first `list' should use `with-indentation' so the items get indented properly, and the second should use some other `with-prefix' function which uses the prefix preceding it instead of just the indentation. This makes me think of an even worse solution -- instead of just turning on location tracking, the scribble/text output should use a custom port that keeps track of the contents of the current line before the current output location. This is bad because 1. It makes it an even more scribble/text-specific solution 2. It'll make it slow an complex 3. And most importantly, the beauty of the scribble syntax was in getting away from this kind of low-level hacking, and I'd really prefer some solution that doesn't mix the output port details with the code in this way. I'd appreciate any comments and ideas anyone might have. (BTW, yes, I looked at what the Cheetah framework does; it's a horrible hack, much worse than the above. See http://www.cheetahtemplate.org/docs/TODO for details.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From robby at eecs.northwestern.edu Fri Mar 6 14:52:39 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Fri Mar 6 14:53:32 2009 Subject: [plt-dev] "poll": scribble syntax & indentation In-Reply-To: <18865.31528.532054.708649@winooski.ccs.neu.edu> References: <18865.31528.532054.708649@winooski.ccs.neu.edu> Message-ID: <932b2f1f0903061152p1bb11d1fp8563b57ca30b271e@mail.gmail.com> Did you consider having the scribble reader be more sophisticated with the strings it generates? That is, if a string comes from {} in Scribble (as opposed to "something" in a s-expression position -- those don't get this special treatment), then it only puts enough spaces in to go from the { to the rest of the lines? (Well, probably it would have to start at the leftmost position in the {}, but let me illustrate). Eg: @f{a b c} would be (f "a\nb\nc") instead of (f "a\n b\n c"). Then, if the { is alone on the first line, you'd use the left-most column that appears inside the {}s, eg: @f{ a b c } would be (f "a\nb\nc") not (f " a\n b\n c\n") Robby On Fri, Mar 6, 2009 at 2:36 PM, Eli Barzilay wrote: > This is not really a poll, but rather a long winded attempt to see if > anyone has any good ideas for a solution. ?(Or me thinking out loud.) > I've been staring at this problem for a while now, and I'm slowly > converging on a solution that is not as good as I'd hope. > > The problem is that trying to use the scribble syntax for cases where > indentation matters is difficult right now. ?This is most obvious if > you try to do use the scribble/text preprocessor language to generate > code. ?[It doesn't come up with the usual documentation languages, > because they're mostly insensitive for indentation -- but it might be > an issue in the future there too, if there is some @scheme{...} macro > that operates on the raw text (like drscheme) rather than the current > @scheme[...] which uses syntax source information (like slideshow).] > > For example, this: > > ?#lang scribble/text > ?function foo() { > ? ?@list{if (1 < 2) > ? ? ? ? ? ?something1 > ? ? ? ? ?else > ? ? ? ? ? ?something2 > ? ? ? ? ?fi > ? ? ? ? ?} > ? ?return > ?} > > will not come out right. ?What's missing is some function to use > instead of `list' which will somehow grab its initial output column > and use it for all nested newlines. ?The scribble reader does put > syntax properties on what it reads which makes it seem like there is > some solution that involves a macro which will use that information, > but that won't work in general because the *source* of the misindented > text can come from a different part of the code -- one that is at an > arbitrarily different position. ?An example of this (the > @@if{text1}{text2}{text3} uses a curried `if' binding, each block of > text happens at a different curried level) is: > > ?#!/bin/env mzscheme > ?#lang scribble/text > > ?@(define (((if . c) . t) . e) > ? ? @list{ > ? ? ? if (@c) > ? ? ? ? @t > ? ? ? else > ? ? ? ? @e}) > > ?function foo() { > ? ?@list{if (1 < 2) > ? ? ? ? ? ?something1 > ? ? ? ? ?else > ? ? ? ? ? ?@@@if{2<3}{something2}{something3} > ? ? ? ? ? ?repeat 3 { > ? ? ? ? ? ? ?@@@if{2<3}{something2}{something3} > ? ? ? ? ? ?} > ? ? ? ? ?fi > ? ? ? ? ?} > ? ?return > ?} > > In this example the `if' function is used in two different places, > each with a different indentation -- and the definition obviously has > a fixed indentation. > > This makes me think that as much as I'd wish this to be done at syntax > time through a macro, I'd have to do something dynamic -- some > `with-indentation' function which knows where in the output stream it > should be printed, and adds this to newlines in its body. ?Even worse, > it will need to divert its body to a temporary buffer, then convert > the newlines there because you could just as well produce newlines in > Scheme expressions instead of being part of the input -- for example, > if this was used above: > > ? ? ? ? ? ?@@@if{2<3}{@"something2.1\nsomething2.2"}{something3} > > then you'd probably want that newline to get the right indentation > injected too. ?The first reason that I don't like this soution is that > it will be specific to the preprocessor output functionality, which > will need to turn on location tracking and make the location available > for that `with-indentation' function. > > But it gets even more complicated. ?Consider this example: > > ?#lang scribble/text > ?function foo() { > ? ?var lst = [@list{item1, > ? ? ? ? ? ? ? ? ? ? item2}] > ? ?// @list{comment1 > ? ? ? ? ? ? comment2} > ? ?return > ?} > > Ideally, this should output: > > ?function foo() { > ? ?var lst = [item1, > ? ? ? ? ? ? ? item2] > ? ?// comment1 > ? ?// comment2 > ? ?return > ?} > > which means that there should be two functions: the first `list' > should use `with-indentation' so the items get indented properly, and > the second should use some other `with-prefix' function which uses the > prefix preceding it instead of just the indentation. > > This makes me think of an even worse solution -- instead of just > turning on location tracking, the scribble/text output should use a > custom port that keeps track of the contents of the current line > before the current output location. ?This is bad because > > 1. It makes it an even more scribble/text-specific solution > > 2. It'll make it slow an complex > > 3. And most importantly, the beauty of the scribble syntax was in > ? getting away from this kind of low-level hacking, and I'd really > ? prefer some solution that doesn't mix the output port details with > ? the code in this way. > > I'd appreciate any comments and ideas anyone might have. > > > (BTW, yes, I looked at what the Cheetah framework does; it's a > horrible hack, much worse than the above. ?See > http://www.cheetahtemplate.org/docs/TODO for details.) > > -- > ? ? ? ? ?((lambda (x) (x x)) (lambda (x) (x x))) ? ? ? ? ?Eli Barzilay: > ? ? ? ? ? ? ? ? ?http://www.barzilay.org/ ? ? ? ? ? ? ? ? Maze is Life! > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > From robby at eecs.northwestern.edu Fri Mar 6 14:53:57 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Fri Mar 6 14:54:21 2009 Subject: [plt-dev] "poll": scribble syntax & indentation In-Reply-To: <932b2f1f0903061152p1bb11d1fp8563b57ca30b271e@mail.gmail.com> References: <18865.31528.532054.708649@winooski.ccs.neu.edu> <932b2f1f0903061152p1bb11d1fp8563b57ca30b271e@mail.gmail.com> Message-ID: <932b2f1f0903061153s8aee3d9u75ed9d009f88d5da@mail.gmail.com> Hm. I don't know who messed up the indentation below, but the first example should look like the output of this expression: (display "@f{a\n b\n c}") Robby On Fri, Mar 6, 2009 at 2:52 PM, Robby Findler wrote: > Did you consider having the scribble reader be more sophisticated with > the strings it generates? That is, if a string comes from {} in > Scribble (as opposed to "something" in a s-expression position -- > those don't get this special treatment), then it only puts enough > spaces in to go from the { to the rest of the lines? (Well, probably > it would have to start at the leftmost position in the {}, but let me > illustrate). > > Eg: > > @f{a > ? b > ? c} > > would be (f "a\nb\nc") instead of (f "a\n ? b\n ? c"). > > Then, if the { is alone on the first line, you'd use the left-most > column that appears inside the {}s, eg: > > @f{ > ?a > ?b > ?c > } > > would be > > (f "a\nb\nc") not (f " a\n b\n c\n") > > Robby > > On Fri, Mar 6, 2009 at 2:36 PM, Eli Barzilay wrote: >> This is not really a poll, but rather a long winded attempt to see if >> anyone has any good ideas for a solution. ?(Or me thinking out loud.) >> I've been staring at this problem for a while now, and I'm slowly >> converging on a solution that is not as good as I'd hope. >> >> The problem is that trying to use the scribble syntax for cases where >> indentation matters is difficult right now. ?This is most obvious if >> you try to do use the scribble/text preprocessor language to generate >> code. ?[It doesn't come up with the usual documentation languages, >> because they're mostly insensitive for indentation -- but it might be >> an issue in the future there too, if there is some @scheme{...} macro >> that operates on the raw text (like drscheme) rather than the current >> @scheme[...] which uses syntax source information (like slideshow).] >> >> For example, this: >> >> ?#lang scribble/text >> ?function foo() { >> ? ?@list{if (1 < 2) >> ? ? ? ? ? ?something1 >> ? ? ? ? ?else >> ? ? ? ? ? ?something2 >> ? ? ? ? ?fi >> ? ? ? ? ?} >> ? ?return >> ?} >> >> will not come out right. ?What's missing is some function to use >> instead of `list' which will somehow grab its initial output column >> and use it for all nested newlines. ?The scribble reader does put >> syntax properties on what it reads which makes it seem like there is >> some solution that involves a macro which will use that information, >> but that won't work in general because the *source* of the misindented >> text can come from a different part of the code -- one that is at an >> arbitrarily different position. ?An example of this (the >> @@if{text1}{text2}{text3} uses a curried `if' binding, each block of >> text happens at a different curried level) is: >> >> ?#!/bin/env mzscheme >> ?#lang scribble/text >> >> ?@(define (((if . c) . t) . e) >> ? ? @list{ >> ? ? ? if (@c) >> ? ? ? ? @t >> ? ? ? else >> ? ? ? ? @e}) >> >> ?function foo() { >> ? ?@list{if (1 < 2) >> ? ? ? ? ? ?something1 >> ? ? ? ? ?else >> ? ? ? ? ? ?@@@if{2<3}{something2}{something3} >> ? ? ? ? ? ?repeat 3 { >> ? ? ? ? ? ? ?@@@if{2<3}{something2}{something3} >> ? ? ? ? ? ?} >> ? ? ? ? ?fi >> ? ? ? ? ?} >> ? ?return >> ?} >> >> In this example the `if' function is used in two different places, >> each with a different indentation -- and the definition obviously has >> a fixed indentation. >> >> This makes me think that as much as I'd wish this to be done at syntax >> time through a macro, I'd have to do something dynamic -- some >> `with-indentation' function which knows where in the output stream it >> should be printed, and adds this to newlines in its body. ?Even worse, >> it will need to divert its body to a temporary buffer, then convert >> the newlines there because you could just as well produce newlines in >> Scheme expressions instead of being part of the input -- for example, >> if this was used above: >> >> ? ? ? ? ? ?@@@if{2<3}{@"something2.1\nsomething2.2"}{something3} >> >> then you'd probably want that newline to get the right indentation >> injected too. ?The first reason that I don't like this soution is that >> it will be specific to the preprocessor output functionality, which >> will need to turn on location tracking and make the location available >> for that `with-indentation' function. >> >> But it gets even more complicated. ?Consider this example: >> >> ?#lang scribble/text >> ?function foo() { >> ? ?var lst = [@list{item1, >> ? ? ? ? ? ? ? ? ? ? item2}] >> ? ?// @list{comment1 >> ? ? ? ? ? ? comment2} >> ? ?return >> ?} >> >> Ideally, this should output: >> >> ?function foo() { >> ? ?var lst = [item1, >> ? ? ? ? ? ? ? item2] >> ? ?// comment1 >> ? ?// comment2 >> ? ?return >> ?} >> >> which means that there should be two functions: the first `list' >> should use `with-indentation' so the items get indented properly, and >> the second should use some other `with-prefix' function which uses the >> prefix preceding it instead of just the indentation. >> >> This makes me think of an even worse solution -- instead of just >> turning on location tracking, the scribble/text output should use a >> custom port that keeps track of the contents of the current line >> before the current output location. ?This is bad because >> >> 1. It makes it an even more scribble/text-specific solution >> >> 2. It'll make it slow an complex >> >> 3. And most importantly, the beauty of the scribble syntax was in >> ? getting away from this kind of low-level hacking, and I'd really >> ? prefer some solution that doesn't mix the output port details with >> ? the code in this way. >> >> I'd appreciate any comments and ideas anyone might have. >> >> >> (BTW, yes, I looked at what the Cheetah framework does; it's a >> horrible hack, much worse than the above. ?See >> http://www.cheetahtemplate.org/docs/TODO for details.) >> >> -- >> ? ? ? ? ?((lambda (x) (x x)) (lambda (x) (x x))) ? ? ? ? ?Eli Barzilay: >> ? ? ? ? ? ? ? ? ?http://www.barzilay.org/ ? ? ? ? ? ? ? ? Maze is Life! >> _________________________________________________ >> ?For list-related administrative tasks: >> ?http://list.cs.brown.edu/mailman/listinfo/plt-dev >> > From eli at barzilay.org Fri Mar 6 15:02:07 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri Mar 6 15:02:27 2009 Subject: [plt-dev] "poll": scribble syntax & indentation In-Reply-To: <932b2f1f0903061152p1bb11d1fp8563b57ca30b271e@mail.gmail.com> References: <18865.31528.532054.708649@winooski.ccs.neu.edu> <932b2f1f0903061152p1bb11d1fp8563b57ca30b271e@mail.gmail.com> <932b2f1f0903061153s8aee3d9u75ed9d009f88d5da@mail.gmail.com> Message-ID: <18865.33087.22766.963862@winooski.ccs.neu.edu> On Mar 6, Robby Findler wrote: > Did you consider having the scribble reader be more sophisticated > with the strings it generates? That is, if a string comes from {} in > Scribble (as opposed to "something" in a s-expression position -- > those don't get this special treatment), then it only puts enough > spaces in to go from the { to the rest of the lines? (Well, probably > it would have to start at the leftmost position in the {}, but let > me illustrate). > > Eg: > > @f{a > b > c} > > would be (f "a\nb\nc") instead of (f "a\n b\n c"). > [...] It already does that, for example, try these two: #lang at-exp scheme/base '@f{a b c} '@f{a b c} '@f{ a b c} It's slightly different than what you suggest in that it keeps separate "\n" strings so it's easy for functions that want to do some line-based processing. (And these "\n" are parsed as string syntax objects with a property that contains the original string exactly, so you can still get a "real verbatim" effect.) I'm happy to have made it this way, because including the text with the spaces would make things impossible to use sanely. (Same reason as above: the indentation would come from the place where a function happens to be defined, so spaces would be pretty much random.) On Mar 6, Robby Findler wrote: > Hm. I don't know who messed up the indentation below, but the first > example should look like the output of this expression: > > (display "@f{a\n b\n c}") (Looks like your mail client messed up showing it to you, it was perfectly fine in the email you sent...) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From eli at barzilay.org Fri Mar 6 17:11:45 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri Mar 6 17:12:06 2009 Subject: [plt-dev] scribble html formatting Message-ID: <18865.40865.987591.243299@winooski.ccs.neu.edu> Speaking about html formatting -- it looks to me like the reason to bottom-align all boxes is that it fits well with formatting pieces of text, where some of the pieces can be "taller". But this doesn't work well in tables where the taller element is itself some text with newlines -- that's very noticeable in the hard to read defproc output, which looks like: foo: some contract this text is the contract bar: for bar, not for foo baz: some other contract It would be nice to have this render as: foo: some contract bar: this text is the contract for bar, not for foo baz: some other contract instead. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From mflatt at cs.utah.edu Fri Mar 6 17:17:40 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Fri Mar 6 17:18:18 2009 Subject: [plt-dev] scribble html formatting In-Reply-To: <18865.40865.987591.243299@winooski.ccs.neu.edu> References: <18865.40865.987591.243299@winooski.ccs.neu.edu> Message-ID: <20090306221740.BBD4F6500AC@mail-svr1.cs.utah.edu> At Fri, 6 Mar 2009 17:11:45 -0500, Eli Barzilay wrote: > Speaking about html formatting -- it looks to me like the reason to > bottom-align all boxes is that it fits well with formatting pieces of > text, where some of the pieces can be "taller". But this doesn't work > well in tables where the taller element is itself some text with > newlines -- that's very noticeable in the hard to read defproc output, > which looks like: > > foo: some contract > this text is the contract > bar: for bar, not for foo > baz: some other contract > > It would be nice to have this render as: > > foo: some contract > bar: this text is the contract > for bar, not for foo > baz: some other contract > > instead. `defproc' does render the latter way, because it uses a CSS class to turn on top alignment (".argcontract td" in "scribble.css"), right? From eli at barzilay.org Fri Mar 6 17:17:44 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri Mar 6 17:18:21 2009 Subject: [plt-dev] scribble html formatting In-Reply-To: <18865.40865.987591.243299@winooski.ccs.neu.edu> References: <18865.40865.987591.243299@winooski.ccs.neu.edu> Message-ID: <18865.41224.815256.244412@winooski.ccs.neu.edu> On Mar 6, Eli Barzilay wrote: > [...] BTW, I wrote that when trying to decipher the description of `make-output-port' -- and one weird problem there is that the `buffer-mode' appears as if it as no defeault value but it's still at the end. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From rafkind at cs.utah.edu Fri Mar 6 17:20:16 2009 From: rafkind at cs.utah.edu (Jon Rafkind) Date: Fri Mar 6 17:20:42 2009 Subject: [plt-dev] [Fwd: [plt-scheme] How should PLTCOLLECTS work?] Message-ID: <49B1A1A0.2030506@cs.utah.edu> This problem as struck me in the past. What do other think of drscheme printing a warning if it can't find its own libraries at startup time? I think this can be done in the shell/batch script. If it can't find drscheme/drscheme.ss then it could issue a warning that potentially PLTCOLLECTS is incorrect. It would be nice to do this for mzscheme as well but I don't know of a clean way to do it. -------------- next part -------------- An embedded message was scrubbed... From: Grant Rettke Subject: [plt-scheme] How should PLTCOLLECTS work? Date: Thu, 5 Mar 2009 20:30:37 -0600 Size: 4884 Url: http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090306/9ee1cc10/plt-schemeHowshouldPLTCOLLECTSwork-0001.eml From grettke at acm.org Fri Mar 6 17:22:17 2009 From: grettke at acm.org (Grant Rettke) Date: Fri Mar 6 17:22:39 2009 Subject: [plt-dev] [Fwd: [plt-scheme] How should PLTCOLLECTS work?] In-Reply-To: <49B1A1A0.2030506@cs.utah.edu> References: <49B1A1A0.2030506@cs.utah.edu> Message-ID: <756daca50903061422w5b2f8e03xd5ca0061ea582482@mail.gmail.com> Eli's explanation should get pasted into the docs. Reading the docs didn't communicate to me what he did. On Fri, Mar 6, 2009 at 4:20 PM, Jon Rafkind wrote: > This problem as struck me in the past. What do other think of drscheme > printing a warning if it can't find its own libraries at startup time? I > think this can be done in the shell/batch script. If it can't find > drscheme/drscheme.ss then it could issue a warning that potentially > PLTCOLLECTS is incorrect. > > It would be nice to do this for mzscheme as well but I don't know of a clean > way to do it. > > The doc says that: > > "If the PLTCOLLECTS environment variable is defined, it is combined > with the default list using path-list-string->path-list." > > Setting it to "C:\collects" on Windows XP with PLt 4.1.4 results in > this message when DrScheme is started: > > lib: standard-module-name-resolver: collection not found: "drscheme" > in any of: (#) in: (lib "drscheme/drscheme.ss") > > [Exited] > > DrScheme does not start. > > What did I do wrong? > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-scheme > > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > > -- http://www.wisdomandwonder.com/ From eli at barzilay.org Fri Mar 6 17:23:06 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri Mar 6 17:23:29 2009 Subject: [plt-dev] scribble html formatting In-Reply-To: <20090306221740.BBD4F6500AC@mail-svr1.cs.utah.edu> References: <18865.40865.987591.243299@winooski.ccs.neu.edu> <18865.41224.815256.244412@winooski.ccs.neu.edu> <20090306221740.BBD4F6500AC@mail-svr1.cs.utah.edu> Message-ID: <18865.41546.69305.992683@winooski.ccs.neu.edu> On Mar 6, Matthew Flatt wrote: > At Fri, 6 Mar 2009 17:11:45 -0500, Eli Barzilay wrote: > > It would be nice to have this render as: > > > > foo: some contract > > bar: this text is the contract > > for bar, not for foo > > baz: some other contract > > > > instead. > > `defproc' does render the latter way, because it uses a CSS class to > turn on top alignment (".argcontract td" in "scribble.css"), right? Ugh, you're right -- seems that this is somehow rendered wrong on my browser on winooski (which has an "old" fedora distribution), but not on my laptop (windows, with FF and IE). On Mar 6, Eli Barzilay wrote: > On Mar 6, Eli Barzilay wrote: > > [...] > > BTW, I wrote that when trying to decipher the description of > `make-output-port' -- and one weird problem there is that the > `buffer-mode' appears as if it as no defeault value but it's still > at the end. (This problem is still there though.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From mflatt at cs.utah.edu Fri Mar 6 17:24:09 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Fri Mar 6 17:24:27 2009 Subject: [plt-dev] scribble html formatting In-Reply-To: <18865.41546.69305.992683@winooski.ccs.neu.edu> References: <18865.40865.987591.243299@winooski.ccs.neu.edu> <18865.41224.815256.244412@winooski.ccs.neu.edu> <20090306221740.BBD4F6500AC@mail-svr1.cs.utah.edu> <18865.41546.69305.992683@winooski.ccs.neu.edu> Message-ID: <20090306222409.4D8D36500AC@mail-svr1.cs.utah.edu> At Fri, 6 Mar 2009 17:23:06 -0500, Eli Barzilay wrote: > On Mar 6, Eli Barzilay wrote: > > On Mar 6, Eli Barzilay wrote: > > > [...] > > > > BTW, I wrote that when trying to decipher the description of > > `make-output-port' -- and one weird problem there is that the > > `buffer-mode' appears as if it as no defeault value but it's still > > at the end. > > (This problem is still there though.) Fixed in SVN. From rafkind at cs.utah.edu Fri Mar 6 17:25:17 2009 From: rafkind at cs.utah.edu (Jon Rafkind) Date: Fri Mar 6 17:25:35 2009 Subject: [plt-dev] [Fwd: [plt-scheme] How should PLTCOLLECTS work?] In-Reply-To: <756daca50903061422w5b2f8e03xd5ca0061ea582482@mail.gmail.com> References: <49B1A1A0.2030506@cs.utah.edu> <756daca50903061422w5b2f8e03xd5ca0061ea582482@mail.gmail.com> Message-ID: <49B1A2CD.8060102@cs.utah.edu> Grant Rettke wrote: > Eli's explanation should get pasted into the docs. Reading the docs > didn't communicate to me what he did. > > Ok, if its useful to you then I agree it should be added. In the general case I think the computer shouldn't just say "error" but rather offer possibilities to fix the error. I'm sure this is a case where people have lots of opinions but I don't want to start a war. From eli at barzilay.org Fri Mar 6 17:28:45 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri Mar 6 17:29:05 2009 Subject: [plt-dev] [Fwd: [plt-scheme] How should PLTCOLLECTS work?] In-Reply-To: <49B1A1A0.2030506@cs.utah.edu> References: <49B1A1A0.2030506@cs.utah.edu> Message-ID: <18865.41885.309263.633687@winooski.ccs.neu.edu> On Mar 6, Jon Rafkind wrote: > This problem as struck me in the past. What do other think of > drscheme printing a warning if it can't find its own libraries at > startup time? I think this can be done in the shell/batch script. If > it can't find drscheme/drscheme.ss then it could issue a warning > that potentially PLTCOLLECTS is incorrect. Doing that in the shell will be a nightmare. Actually, the best way I can think of "doing it in the shell" is by capturing stderr output and changing the error if it looks like the usual complaint. (And this is a bad idea.) A slightly better (but still pretty bad, IMO) solution is to add a mzscheme flag that says something like "load srscheme/drscheme.ss, and if you can't find it, then say something about PLTCOLLECTS". This is bad IMO for the reason we talked about yesterday: such a flag is roughly telling mzscheme to read your mind and guess what caused the error. > It would be nice to do this for mzscheme as well but I don't know of a > clean way to do it. Why not take my explanation and add it in the docs? If it appears in the same place that PLTCOLLECTS is mentioned, then there shouldn't be any problem since people will see it. (Perhaps in a new page, which will be linked from the PLTCOLLECTS entry, describing the different uses it can have, and warning about the potential mess you can get yourself into.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From matthias at ccs.neu.edu Fri Mar 6 03:24:29 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Fri Mar 6 20:48:44 2009 Subject: [plt-dev] overriding constructor style printing In-Reply-To: <7B0F5A51-CF38-4473-8F72-65FB276137EB@pnkfx.org> References: <20090303210049.DC1816500BA@mail-svr1.cs.utah.edu> <7B0F5A51-CF38-4473-8F72-65FB276137EB@pnkfx.org> Message-ID: On Mar 3, 2009, at 5:17 PM, Felix Klock's PLT scheme proxy wrote: > In general, the designer of an abstract data type wants to only > provide an abstract view of that type. Late to the game and it's a philosophical answer, too. Over years of Scheme programming I came to the conclusion that this desire is ideologically misguided for a language without types. Types -- in Reynolds's words -- are enforcing syntactic barriers of abstraction. In a world of types, it is therefore natural to wish to present an _abstract type_ as something the client side cannot see. (How about the server side, btw?) Because the barrier is only syntactic, a concrete view of the elements of an abstract type would actually allow us to fake them at run-time. (Example: abstype t = ... : if I print these things concretely as 1 2 3 I can use a 1 or a 2 as t and float it from a (badly typed part of the system) into the abstype region and possibly destroy invariants.) Untyped languages don't support abstract types. They support dynamic protection of invariants (see Robby and Wadler's and Jacob's paper). So it's perfectly okay to show clients how a bag is represented: as (make-bag (list (list 'a 2) (list 'b 1))) or (make-bag (list 'a 'a 'b)). They can't fake it because bag is generative. In short you have fallen prey to the ideological preaching of Typed people. Of course, I realize that you wish to make a point to your students so I also understand why having an appropriate print style around is useful. You are turning the "TeachScheme" language into something students might encounter once they move into types. -- Matthias From matthias at ccs.neu.edu Fri Mar 6 03:52:59 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Fri Mar 6 20:49:14 2009 Subject: [plt-dev] file/zip file sizes In-Reply-To: <18864.21872.720350.804634@winooski.ccs.neu.edu> References: <18AEA650-9A4C-449C-BA3A-C8F45AE06B4D@gmail.com> <18864.21872.720350.804634@winooski.ccs.neu.edu> Message-ID: <46513C76-CC33-442F-AFC8-9DBBE783631E@ccs.neu.edu> On Mar 5, 2009, at 5:42 PM, Eli Barzilay wrote: > It does have a LEVEL definition which corresponds to the compression > level argument for gzip, and I tried to tweak that to see what > happens. To my surprise, I discovered a bug that I introduced a long > time ago -- which made it do almost no compression (or maybe none at > all). But the result still had valid format so it wasn't discovered. It sounds to me like one could formulate a test suite for this program: -- create correct format -- compress some file by a well-known factor. Did you add this to the test suite? -- Matthias From robby at eecs.northwestern.edu Fri Mar 6 21:21:39 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Fri Mar 6 21:22:01 2009 Subject: [plt-dev] file/zip file sizes In-Reply-To: <46513C76-CC33-442F-AFC8-9DBBE783631E@ccs.neu.edu> References: <18AEA650-9A4C-449C-BA3A-C8F45AE06B4D@gmail.com> <18864.21872.720350.804634@winooski.ccs.neu.edu> <46513C76-CC33-442F-AFC8-9DBBE783631E@ccs.neu.edu> Message-ID: <932b2f1f0903061821l7eb33d58p2824c9e051145db@mail.gmail.com> If you fix the input, you shoul dbe able to predict the compression precisely, right? It is deterministic! And likely there is some simple unit test for the actual bug that Eli found. On Fri, Mar 6, 2009 at 2:52 AM, Matthias Felleisen wrote: > > On Mar 5, 2009, at 5:42 PM, Eli Barzilay wrote: > >> It does have a LEVEL definition which corresponds to the compression >> level argument for gzip, and I tried to tweak that to see what >> happens. ?To my surprise, I discovered a bug that I introduced a long >> time ago -- which made it do almost no compression (or maybe none at >> all). ?But the result still had valid format so it wasn't discovered. > > > It sounds to me like one could formulate a test suite for this > program: > > ?-- create correct format > ?-- compress some file by a well-known factor. > > Did you add this to the test suite? -- Matthias > > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > From robby at eecs.northwestern.edu Fri Mar 6 21:31:53 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Fri Mar 6 21:32:16 2009 Subject: [plt-dev] overriding constructor style printing In-Reply-To: References: <20090303210049.DC1816500BA@mail-svr1.cs.utah.edu> <7B0F5A51-CF38-4473-8F72-65FB276137EB@pnkfx.org> Message-ID: <932b2f1f0903061831r3283b1e0l4ff62f0b8ac26061@mail.gmail.com> On Fri, Mar 6, 2009 at 2:24 AM, Matthias Felleisen wrote: > On Mar 3, 2009, at 5:17 PM, Felix Klock's PLT scheme proxy wrote: > >> ?In general, the designer of an abstract data type wants to only provide >> an abstract view of that type. > > > Late to the game and it's a philosophical answer, too. > > Over years of Scheme programming I came to the conclusion that this desire > is ideologically misguided for a language without types. > > Types -- in Reynolds's words -- are enforcing syntactic barriers of > abstraction. In a world of types, it is therefore natural to wish to present > an _abstract type_ as something the client side cannot see. (How about the > server side, btw?) Because the barrier is only syntactic, a concrete view of > the elements of an abstract type would actually allow us to fake them at > run-time. (Example: abstype t = ... : if I print these things concretely as > 1 2 3 I can use a 1 or a 2 as t and float it from a (badly typed part of the > system) into the abstype region and possibly destroy invariants.) > > Untyped languages don't support abstract types. They support dynamic > protection of invariants (see Robby and Wadler's and Jacob's paper). I think Matthias means Jacob & Amal's paper (altho we are continuing to work on this area): http://ttic.uchicago.edu/~amal/papers/parpolyseal.pdf Even if you're not interested in the technical details, the intro is worth a read. Robby From eli at barzilay.org Fri Mar 6 21:34:59 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri Mar 6 21:35:22 2009 Subject: [plt-dev] file/zip file sizes In-Reply-To: <932b2f1f0903061821l7eb33d58p2824c9e051145db@mail.gmail.com> References: <18AEA650-9A4C-449C-BA3A-C8F45AE06B4D@gmail.com> <18864.21872.720350.804634@winooski.ccs.neu.edu> <46513C76-CC33-442F-AFC8-9DBBE783631E@ccs.neu.edu> <932b2f1f0903061821l7eb33d58p2824c9e051145db@mail.gmail.com> Message-ID: <18865.56659.192156.197060@winooski.ccs.neu.edu> On Fri, Mar 6, 2009 at 2:52 AM, Matthias Felleisen wrote: > > It sounds to me like one could formulate a test suite for this > program: > > ?-- create correct format > ?-- compress some file by a well-known factor. > > Did you add this to the test suite? -- Matthias No, I still have it on my todo list. There is a file in tests/mzcheme/gzip.ss which is not used, which uses gzip+gunzip to check that data is the same, and some commented code seems like it's comparing it to the unix gzip. I'm not sure that comparing it to gzip is a good idea, since it's likely that it will change in small ways -- which is why I thought that I should try it first and find if there is some way to make it work sensibly. But I think that comparing just the size would work much better, so there's no need for gzip headache for the tests. (BTW, I'll also make a new test collection and remove the above file from the mzscheme pile.) On Mar 6, Robby Findler wrote: > If you fix the input, you shoul dbe able to predict the compression > precisely, right? It is deterministic! I don't think that it's a good idea for roughly the same reason as above; but also because this would be a classic example of a copy-paste test. (IOW, how do you know that this deterministic output is the correct one?) > And likely there is some simple unit test for the actual bug that > Eli found. No -- in fact the unused gzip+gunzip test wouldn't discover it, for the same reason that the code actually worked. The bug was roughly this: (define-syntax foo (syntax-rules () [(foo x y z) #'(some output with x y and z)])) Here's a tricky exercise: try to guess what the bug is... Anyway, since the code is extremely imperative, the usual result would be some kind of failure -- but this happened to be a macro that didn't do any real damage if its body is not executed -- it just didn't do the compression (or maybe didn't compress as well as it should have). The bottom line is that the output was still valid, and gunzip would get you back the proper result. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From pnkfelix at ccs.neu.edu Fri Mar 6 21:57:00 2009 From: pnkfelix at ccs.neu.edu (Felix S Klock II) Date: Fri Mar 6 22:04:35 2009 Subject: [plt-dev] overriding constructor style printing In-Reply-To: References: <20090303210049.DC1816500BA@mail-svr1.cs.utah.edu> <7B0F5A51-CF38-4473-8F72-65FB276137EB@pnkfx.org> Message-ID: Matthias- On Mar 6, 2009, at 3:24 AM, Matthias Felleisen wrote: > On Mar 3, 2009, at 5:17 PM, Felix Klock's PLT scheme proxy wrote: > >> In general, the designer of an abstract data type wants to only >> provide an abstract view of that type. > > > Late to the game and it's a philosophical answer, too. > > Over years of Scheme programming I came to the conclusion that this > desire is ideologically misguided for a language without types. > > Types -- in Reynolds's words -- are enforcing syntactic barriers of > abstraction. In a world of types, it is therefore natural to wish to > present an _abstract type_ as something the client side cannot see. > (How about the server side, btw?) On this "server side" point, CLU had explicit operations to convert a concrete representation into the sealed abstraction that a "cluster" (module) would export to the outside world. I'm not sure if that's the sort of thing you're thinking of in your musing above though. > Because the barrier is only syntactic, a concrete view of the > elements of an abstract type would actually allow us to fake them at > run-time. (Example: abstype t = ... : if I print these things > concretely as 1 2 3 I can use a 1 or a 2 as t and float it from a > (badly typed part of the system) into the abstype region and > possibly destroy invariants.) > > Untyped languages don't support abstract types. They support dynamic > protection of invariants (see Robby and Wadler's and Jacob's paper). > So it's perfectly okay to show clients how a bag is represented: as > (make-bag (list (list 'a 2) (list 'b 1))) or (make-bag (list 'a 'a > 'b)). They can't fake it because bag is generative. > > In short you have fallen prey to the ideological preaching of Typed > people. Hmm. I do not really agree that I've fallen prey to the ideological preaching of that community. (I will admit that long ago I fell prey to the ideological preaching of Liskov and Guttag, and you might consider them part of the "Typed" clan; so maybe I am wrong to disagree with your claim about to whom I have fallen prey.) This is not about preventing rep exposure to enforce the invariants of my module (a standard topic in discussions of abstract types). My goal (while implementing the constructor style printing aspect of this library) is to help my audience *see* and manipulate the abstraction being represented, rather than spitting out the underlying representation and forcing them to apply an appropriate abstraction function ("interpretation") in their heads. Overriding the constructor-style printing here is about increasing the usability of these abstract bags, because it: 1. Provides an immediate hint towards a "constructor" (or pseudo- constructor); in this case, the function most relevant for constructing such objects, and 2. Hides the irrelevant details of the representation that could confuse a student who is not familiar with how to map concrete data to abstract information. (If you show them the underlying lists of the representation, it distracts from the essential point that element order does not matter for these objects, which makes them special and very different from what they've seen before. Worse, it may lead them to think that in lists as well the order does not matter, and their heads explode.) ---- Perhaps my choice of terminology was poor (even though I consider it standard, even in the dynamic language community). How about: "In general, the designer of an abstract class of data wants to only provide an abstract view of that class." Do you object to that statement as well? What is wrong with desiring to hide internal details of my library? ---- > Of course, I realize that you wish to make a point to your students > so I also understand why having an appropriate print style around is > useful. You are turning the "TeachScheme" language into something > students might encounter once they move into types. I cannot tell if this paragraph is your way of predicting my response above and warding it off ahead of time; so I am including the response nonetheless. :) I also cannot tell which particular "something" that the students might encounter you are referring to above. (Multisets? Abstract data types? Information with more than one possible representation?) -Felix From robby at eecs.northwestern.edu Fri Mar 6 23:29:19 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Fri Mar 6 23:29:41 2009 Subject: [plt-dev] file/zip file sizes In-Reply-To: <18865.56659.192156.197060@winooski.ccs.neu.edu> References: <18AEA650-9A4C-449C-BA3A-C8F45AE06B4D@gmail.com> <18864.21872.720350.804634@winooski.ccs.neu.edu> <46513C76-CC33-442F-AFC8-9DBBE783631E@ccs.neu.edu> <932b2f1f0903061821l7eb33d58p2824c9e051145db@mail.gmail.com> <18865.56659.192156.197060@winooski.ccs.neu.edu> Message-ID: <932b2f1f0903062029l1c33389dib90ae506d0ae50ea@mail.gmail.com> Can you please point me to the code and explain the fix? Thank you. Robby On 3/6/09, Eli Barzilay wrote: > On Fri, Mar 6, 2009 at 2:52 AM, Matthias Felleisen > wrote: >> >> It sounds to me like one could formulate a test suite for this >> program: >> >> -- create correct format >> -- compress some file by a well-known factor. >> >> Did you add this to the test suite? -- Matthias > > No, I still have it on my todo list. There is a file in > tests/mzcheme/gzip.ss which is not used, which uses gzip+gunzip to > check that data is the same, and some commented code seems like it's > comparing it to the unix gzip. I'm not sure that comparing it to gzip > is a good idea, since it's likely that it will change in small ways -- > which is why I thought that I should try it first and find if there is > some way to make it work sensibly. > > But I think that comparing just the size would work much better, so > there's no need for gzip headache for the tests. > > (BTW, I'll also make a new test collection and remove the above file > from the mzscheme pile.) > > > On Mar 6, Robby Findler wrote: >> If you fix the input, you shoul dbe able to predict the compression >> precisely, right? It is deterministic! > > I don't think that it's a good idea for roughly the same reason as > above; but also because this would be a classic example of a > copy-paste test. (IOW, how do you know that this deterministic output > is the correct one?) > > >> And likely there is some simple unit test for the actual bug that >> Eli found. > > No -- in fact the unused gzip+gunzip test wouldn't discover it, for > the same reason that the code actually worked. The bug was roughly > this: > > (define-syntax foo > (syntax-rules () > [(foo x y z) > #'(some output with x y and z)])) > > Here's a tricky exercise: try to guess what the bug is... > > Anyway, since the code is extremely imperative, the usual result would > be some kind of failure -- but this happened to be a macro that didn't > do any real damage if its body is not executed -- it just didn't do > the compression (or maybe didn't compress as well as it should have). > The bottom line is that the output was still valid, and gunzip would > get you back the proper result. > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > http://www.barzilay.org/ Maze is Life! > From eli at barzilay.org Fri Mar 6 23:40:44 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri Mar 6 23:41:05 2009 Subject: [plt-dev] file/zip file sizes In-Reply-To: <932b2f1f0903062029l1c33389dib90ae506d0ae50ea@mail.gmail.com> References: <18AEA650-9A4C-449C-BA3A-C8F45AE06B4D@gmail.com> <18864.21872.720350.804634@winooski.ccs.neu.edu> <46513C76-CC33-442F-AFC8-9DBBE783631E@ccs.neu.edu> <932b2f1f0903061821l7eb33d58p2824c9e051145db@mail.gmail.com> <18865.56659.192156.197060@winooski.ccs.neu.edu> <932b2f1f0903062029l1c33389dib90ae506d0ae50ea@mail.gmail.com> Message-ID: <18865.64204.130141.864496@winooski.ccs.neu.edu> On Mar 6, Robby Findler wrote: > Can you please point me to the code and explain the fix? It's just the bug that I described below. Revision 13971. > On 3/6/09, Eli Barzilay wrote: > > On Fri, Mar 6, 2009 at 2:52 AM, Matthias Felleisen > > wrote: > >> > >> It sounds to me like one could formulate a test suite for this > >> program: > >> > >> -- create correct format > >> -- compress some file by a well-known factor. > >> > >> Did you add this to the test suite? -- Matthias > > > > No, I still have it on my todo list. There is a file in > > tests/mzcheme/gzip.ss which is not used, which uses gzip+gunzip to > > check that data is the same, and some commented code seems like it's > > comparing it to the unix gzip. I'm not sure that comparing it to gzip > > is a good idea, since it's likely that it will change in small ways -- > > which is why I thought that I should try it first and find if there is > > some way to make it work sensibly. > > > > But I think that comparing just the size would work much better, so > > there's no need for gzip headache for the tests. > > > > (BTW, I'll also make a new test collection and remove the above file > > from the mzscheme pile.) > > > > > > On Mar 6, Robby Findler wrote: > >> If you fix the input, you shoul dbe able to predict the compression > >> precisely, right? It is deterministic! > > > > I don't think that it's a good idea for roughly the same reason as > > above; but also because this would be a classic example of a > > copy-paste test. (IOW, how do you know that this deterministic output > > is the correct one?) > > > > > >> And likely there is some simple unit test for the actual bug that > >> Eli found. > > > > No -- in fact the unused gzip+gunzip test wouldn't discover it, for > > the same reason that the code actually worked. The bug was roughly > > this: > > > > (define-syntax foo > > (syntax-rules () > > [(foo x y z) > > #'(some output with x y and z)])) > > > > Here's a tricky exercise: try to guess what the bug is... > > > > Anyway, since the code is extremely imperative, the usual result would > > be some kind of failure -- but this happened to be a macro that didn't > > do any real damage if its body is not executed -- it just didn't do > > the compression (or maybe didn't compress as well as it should have). > > The bottom line is that the output was still valid, and gunzip would > > get you back the proper result. > > > > -- > > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > > http://www.barzilay.org/ Maze is Life! > > -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From robby at eecs.northwestern.edu Sat Mar 7 06:38:24 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Sat Mar 7 06:38:44 2009 Subject: [plt-dev] "poll": scribble syntax & indentation In-Reply-To: <18865.31528.532054.708649@winooski.ccs.neu.edu> References: <18865.31528.532054.708649@winooski.ccs.neu.edu> Message-ID: <932b2f1f0903070338m20a27420yd3c787ab32fab7b3@mail.gmail.com> On Fri, Mar 6, 2009 at 1:36 PM, Eli Barzilay wrote: > For example, this: > > ?#lang scribble/text > ?function foo() { > ? ?@list{if (1 < 2) > ? ? ? ? ? ?something1 > ? ? ? ? ?else > ? ? ? ? ? ?something2 > ? ? ? ? ?fi > ? ? ? ? ?} > ? ?return > ?} > > will not come out right. I think I don't get what coming out right would be here. It looks right to me! Robby From dorai at ccs.neu.edu Sat Mar 7 11:07:31 2009 From: dorai at ccs.neu.edu (Dorai Sitaram) Date: Sat Mar 7 11:07:53 2009 Subject: [plt-dev] immutable-pair question In-Reply-To: <932b2f1f0903062029l1c33389dib90ae506d0ae50ea@mail.gmail.com> from "Robby Findler" at Mar 06, 2009 10:29:19 PM Message-ID: Shouldn't (eqv? (list 1 2) (list 1 2)) be returning #t nowadays? --d From eli at barzilay.org Sat Mar 7 14:08:55 2009 From: eli at barzilay.org (Eli Barzilay) Date: Sat Mar 7 14:09:16 2009 Subject: [plt-dev] "poll": scribble syntax & indentation In-Reply-To: <932b2f1f0903070338m20a27420yd3c787ab32fab7b3@mail.gmail.com> References: <18865.31528.532054.708649@winooski.ccs.neu.edu> <932b2f1f0903070338m20a27420yd3c787ab32fab7b3@mail.gmail.com> Message-ID: <18866.50759.91704.438735@winooski.ccs.neu.edu> On Mar 7, Robby Findler wrote: > On Fri, Mar 6, 2009 at 1:36 PM, Eli Barzilay wrote: > > For example, this: > > > > ?#lang scribble/text > > ?function foo() { > > ? ?@list{if (1 < 2) > > ? ? ? ? ? ?something1 > > ? ? ? ? ?else > > ? ? ? ? ? ?something2 > > ? ? ? ? ?fi > > ? ? ? ? ?} > > ? ?return > > ?} > > > > will not come out right. > > I think I don't get what coming out right would be here. It looks right to me! The current output of this is: function foo() { if (1 < 2) something1 else something2 fi return } instead of function foo() { if (1 < 2) something1 else something2 fi return } This is because the list has this contents: "if (1 < 2)" "\n" " something1" "\n" "else" "\n" " something2" "\n" "fi" So the indentation that you see inside the resulting "if" block is the indentation that is internal to the `list' expression, ignoring the context. Here's a more exaggerated example: #lang scribble/text function foo() { newline @list{if (1 < 2) something1 else something2 fi } return } prints: function foo() { newline if (1 < 2) something1 else something2 fi return } -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From robby at eecs.northwestern.edu Sat Mar 7 14:56:55 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Sat Mar 7 14:57:13 2009 Subject: [plt-dev] "poll": scribble syntax & indentation In-Reply-To: <18866.50759.91704.438735@winooski.ccs.neu.edu> References: <18865.31528.532054.708649@winooski.ccs.neu.edu> <932b2f1f0903070338m20a27420yd3c787ab32fab7b3@mail.gmail.com> <18866.50759.91704.438735@winooski.ccs.neu.edu> Message-ID: <932b2f1f0903071156k54501b10j7fb6bab85b465dca@mail.gmail.com> Oh, I see. Perhaps the right thing is to treat nested list structure as starting a new indentation block, so that the "something1" is indented relative to the beginning of the list that it is in, resulting in this output: function foo() { if (1 < 2) something1 else something2 fi return } In other words, you'd have a 'flatten' function that would be called (in this case) by (something like) the scribble/text module-begin that instead of being just 'apply string-append' it would also prefix each element of a sublist by an indentation amount. You'd provide this function for uses in other contexts (like in an at-exp language) and people would just have to call it there, instead of having it work automatically. This would generalize to 'with prefix' if you wanted to, but I think this example from your original message: function foo() { var lst = [@list{item1, item2}] // @list{comment1 comment2} return } would turn into this: function foo() { var lst = item1, var lst = item2 // comment1 // comment2 return } (ie, it would have an extra 'var lst =' for the first list). Robby From matthias at ccs.neu.edu Sat Mar 7 15:06:53 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Sat Mar 7 15:07:32 2009 Subject: [plt-dev] overriding constructor style printing In-Reply-To: References: <20090303210049.DC1816500BA@mail-svr1.cs.utah.edu> <7B0F5A51-CF38-4473-8F72-65FB276137EB@pnkfx.org> Message-ID: <78BA87E6-CB8F-4A7D-B07F-E8F03E495632@ccs.neu.edu> On Mar 6, 2009, at 9:57 PM, Felix S Klock II wrote: > Perhaps my choice of terminology was poor (even though I consider > it standard, even in the dynamic language community). How about: > "In general, the designer of an abstract class of data wants to > only provide an abstract view of that class." No, this use of constructor-style printing is good for students and good in general. Showing students an 'abstract' view in a Scheme class is also fine. I just haven't thought thru the implications for design. ;; --- Clu is typed and Liskov/Guttag are "type guys" (though I doubt they understood the connection between types and proofs and soundness). -- Matthias From robby at eecs.northwestern.edu Sat Mar 7 15:24:30 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Sat Mar 7 15:24:51 2009 Subject: [plt-dev] file/zip file sizes In-Reply-To: <18865.64204.130141.864496@winooski.ccs.neu.edu> References: <18AEA650-9A4C-449C-BA3A-C8F45AE06B4D@gmail.com> <18864.21872.720350.804634@winooski.ccs.neu.edu> <46513C76-CC33-442F-AFC8-9DBBE783631E@ccs.neu.edu> <932b2f1f0903061821l7eb33d58p2824c9e051145db@mail.gmail.com> <18865.56659.192156.197060@winooski.ccs.neu.edu> <932b2f1f0903062029l1c33389dib90ae506d0ae50ea@mail.gmail.com> <18865.64204.130141.864496@winooski.ccs.neu.edu> Message-ID: <932b2f1f0903071224y5e37a8a6pd8fc98c08a598877@mail.gmail.com> If I understand this properly, your fix changes INSERT_STRING from doing nothing to doing something. And INSERT_STRING is a macro, but one that behaves like a function of its arguments. In other words, the most trivial unit test of INSERT_STRING would have caught this bug. (Did you maybe not understand what I meant by 'unit test'?) Here's a test case. This should produce 'vec-entry. It produced 'dummy before the bug fix. (let ([x 'dummy]) (INSERT_STRING 0 x void #"abc" (build-vector 32769 (? (i) 'vec-entry)) (build-vector 32769 (? (i) 'vec-entry2)) 0) x) Robby On Fri, Mar 6, 2009 at 10:40 PM, Eli Barzilay wrote: > On Mar ?6, Robby Findler wrote: >> Can you please point me to the code and explain the fix? > > It's just the bug that I described below. ?Revision 13971. > > >> On 3/6/09, Eli Barzilay wrote: >> > On Fri, Mar 6, 2009 at 2:52 AM, Matthias Felleisen >> > wrote: >> >> >> >> It sounds to me like one could formulate a test suite for this >> >> program: >> >> >> >> ?-- create correct format >> >> ?-- compress some file by a well-known factor. >> >> >> >> Did you add this to the test suite? -- Matthias >> > >> > No, I still have it on my todo list. ?There is a file in >> > tests/mzcheme/gzip.ss which is not used, which uses gzip+gunzip to >> > check that data is the same, and some commented code seems like it's >> > comparing it to the unix gzip. ?I'm not sure that comparing it to gzip >> > is a good idea, since it's likely that it will change in small ways -- >> > which is why I thought that I should try it first and find if there is >> > some way to make it work sensibly. >> > >> > But I think that comparing just the size would work much better, so >> > there's no need for gzip headache for the tests. >> > >> > (BTW, I'll also make a new test collection and remove the above file >> > from the mzscheme pile.) >> > >> > >> > On Mar ?6, Robby Findler wrote: >> >> If you fix the input, you shoul dbe able to predict the compression >> >> precisely, right? It is deterministic! >> > >> > I don't think that it's a good idea for roughly the same reason as >> > above; but also because this would be a classic example of a >> > copy-paste test. ?(IOW, how do you know that this deterministic output >> > is the correct one?) >> > >> > >> >> And likely there is some simple unit test for the actual bug that >> >> Eli found. >> > >> > No -- in fact the unused gzip+gunzip test wouldn't discover it, for >> > the same reason that the code actually worked. ?The bug was roughly >> > this: >> > >> > ? (define-syntax foo >> > ? ? (syntax-rules () >> > ? ? ? [(foo x y z) >> > ? ? ? ?#'(some output with x y and z)])) >> > >> > Here's a tricky exercise: try to guess what the bug is... >> > >> > Anyway, since the code is extremely imperative, the usual result would >> > be some kind of failure -- but this happened to be a macro that didn't >> > do any real damage if its body is not executed -- it just didn't do >> > the compression (or maybe didn't compress as well as it should have). >> > The bottom line is that the output was still valid, and gunzip would >> > get you back the proper result. >> > >> > -- >> > ? ? ? ? ? ((lambda (x) (x x)) (lambda (x) (x x))) ? ? ? ? ?Eli Barzilay: >> > ? ? ? ? ? ? ? ? ? http://www.barzilay.org/ ? ? ? ? ? ? ? ? Maze is Life! >> > > > -- > ? ? ? ? ?((lambda (x) (x x)) (lambda (x) (x x))) ? ? ? ? ?Eli Barzilay: > ? ? ? ? ? ? ? ? ?http://www.barzilay.org/ ? ? ? ? ? ? ? ? Maze is Life! > From eli at barzilay.org Sun Mar 8 10:32:35 2009 From: eli at barzilay.org (Eli Barzilay) Date: Sun Mar 8 10:32:56 2009 Subject: [plt-dev] Reminder: release in a week Message-ID: <18867.55043.558261.43487@winooski.ccs.neu.edu> This is a reminder that the next release is going to start with the brandh in one week, getting things in order is a good idea. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From eli at barzilay.org Sun Mar 8 10:37:01 2009 From: eli at barzilay.org (Eli Barzilay) Date: Sun Mar 8 10:37:22 2009 Subject: [plt-dev] Reminder: release in a week In-Reply-To: <18867.55043.558261.43487@winooski.ccs.neu.edu> References: <18867.55043.558261.43487@winooski.ccs.neu.edu> Message-ID: <18867.55309.352583.938234@winooski.ccs.neu.edu> On Mar 8, Eli Barzilay wrote: > This is a reminder that the next release is going to start with the > brandh in one week, getting things in order is a good idea. ^^^^^^ branch -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From mflatt at cs.utah.edu Mon Mar 9 07:13:15 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Mon Mar 9 07:13:36 2009 Subject: [plt-dev] new collection: deinprogramm Message-ID: <20090309111317.A9CBD6500A9@mail-svr1.cs.utah.edu> FYI: There's now a "deinprogramm" collection in SVN that provides support for the German-language textbook _Die Macht der Abstraktion_. It's also included in the main distribution. Matthew From pocmatos at gmail.com Mon Mar 9 07:18:30 2009 From: pocmatos at gmail.com (Paulo J. Matos) Date: Mon Mar 9 07:18:58 2009 Subject: [plt-dev] new collection: deinprogramm In-Reply-To: <20090309111317.A9CBD6500A9@mail-svr1.cs.utah.edu> References: <20090309111317.A9CBD6500A9@mail-svr1.cs.utah.edu> Message-ID: <11b141710903090418r25900921sdd146751ded6eb6c@mail.gmail.com> On Mon, Mar 9, 2009 at 11:13 AM, Matthew Flatt wrote: > FYI: There's now a "deinprogramm" collection in SVN that provides > support for the German-language textbook _Die Macht der Abstraktion_. > It's also included in the main distribution. > I am currently learning German, so since I am still not really fluent, I guess I might give it a try in a couple of months. Doesn't it bring anything new for PLAI / EOPL / HTDP / SICP readers? > > Matthew > > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > -- Paulo Jorge Matos - pocmatos at gmail.com Webpage: http://www.personal.soton.ac.uk/pocm From mflatt at cs.utah.edu Mon Mar 9 08:30:33 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Mon Mar 9 08:30:58 2009 Subject: [plt-dev] Scribble errors in Dracula distribution In-Reply-To: <990e0c030902131028l8026edep2be73b92c586fcb5@mail.gmail.com> References: <990e0c030902131028l8026edep2be73b92c586fcb5@mail.gmail.com> Message-ID: <20090309123035.91B426500AF@mail-svr1.cs.utah.edu> At Fri, 13 Feb 2009 13:28:18 -0500, Carl Eastlund wrote: > The pre-built documentation I uploaded with Dracula 8.1 has some > broken internal links. You can see an example in the first paragraph > at: > > http://planet.plt-scheme.org/package-source/cce/dracula.plt/8/1/planet- > docs/reference/index.html > > These links work fine in the Dracula package itself. Does anyone know > why they wouldn't work in the version created for the .plt file? I > didn't see any errors reported when I built the package, or I would > have copied them and reported this problem then. > > Have any other planet package maintainers seen problems like this? I've finally looked into this. A file like "expressions.scrbl" in the Dracula document source has a `for-label' import of "../../lang/dracula.ss" instead of `(planet cce/dracula:8:1/lang/dracula))'. The relative path overlaps with the Planet package after its installed, so that's why the installed docs work. While building for the ".plt" file, though, Scribble doesn't know that "../../lang/dracula.ss" in the source directory for the new package corresponds to a Planet package. One solution is to use (require (for-label (planet cce/dracula:8:1/lang/dracula))) instead of relative-path `for-label' requires in the doc sources. Or maybe add something like to `require-this-package-for-label' to the set of documentation macros currently provided by `(planet cce/scheme:3:0)'. But this highlights the fact that building the docs for a new Planet package requires that the package is installed at build time. Otherwise, the `planet create' command seems to be set up to avoid that requirement. Maybe `planet create' should set up a temporary development link while building a package? Or should `planet create' work in terms of an installed package instead of a given source directory (in which case the docs could be built by running out of the installation, which solves the relative-path problem)? From robby at eecs.northwestern.edu Mon Mar 9 08:57:08 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Mon Mar 9 08:57:31 2009 Subject: [plt-dev] Scribble errors in Dracula distribution In-Reply-To: <20090309123035.91B426500AF@mail-svr1.cs.utah.edu> References: <990e0c030902131028l8026edep2be73b92c586fcb5@mail.gmail.com> <20090309123035.91B426500AF@mail-svr1.cs.utah.edu> Message-ID: <932b2f1f0903090557o5cb8baaex4f24969b5d957306@mail.gmail.com> It makes sense to me that planet create should be working from a development link, not a directory. Robby On Mon, Mar 9, 2009 at 7:30 AM, Matthew Flatt wrote: > At Fri, 13 Feb 2009 13:28:18 -0500, Carl Eastlund wrote: >> The pre-built documentation I uploaded with Dracula 8.1 has some >> broken internal links. ?You can see an example in the first paragraph >> at: >> >> http://planet.plt-scheme.org/package-source/cce/dracula.plt/8/1/planet- >> docs/reference/index.html >> >> These links work fine in the Dracula package itself. ?Does anyone know >> why they wouldn't work in the version created for the .plt file? ?I >> didn't see any errors reported when I built the package, or I would >> have copied them and reported this problem then. >> >> Have any other planet package maintainers seen problems like this? > > I've finally looked into this. > > A file like "expressions.scrbl" in the Dracula document source has a > `for-label' import of "../../lang/dracula.ss" instead of `(planet > cce/dracula:8:1/lang/dracula))'. The relative path overlaps with the > Planet package after its installed, so that's why the installed docs > work. While building for the ".plt" file, though, Scribble doesn't know > that "../../lang/dracula.ss" in the source directory for the new > package corresponds to a Planet package. > > One solution is to use > > ?(require (for-label (planet cce/dracula:8:1/lang/dracula))) > > instead of relative-path `for-label' requires in the doc sources. Or > maybe add something like to `require-this-package-for-label' to the set > of documentation macros currently provided by `(planet > cce/scheme:3:0)'. > > > But this highlights the fact that building the docs for a new Planet > package requires that the package is installed at build time. > Otherwise, the `planet create' command seems to be set up to avoid that > requirement. Maybe `planet create' should set up a temporary > development link while building a package? Or should `planet create' > work in terms of an installed package instead of a given source > directory (in which case the docs could be built by running out of the > installation, which solves the relative-path problem)? > > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > From dherman at ccs.neu.edu Mon Mar 9 10:42:22 2009 From: dherman at ccs.neu.edu (Dave Herman) Date: Mon Mar 9 10:42:42 2009 Subject: [plt-dev] Scribble errors in Dracula distribution In-Reply-To: <20090309123035.91B426500AF@mail-svr1.cs.utah.edu> References: <990e0c030902131028l8026edep2be73b92c586fcb5@mail.gmail.com> <20090309123035.91B426500AF@mail-svr1.cs.utah.edu> Message-ID: <49B52ACE.2050201@ccs.neu.edu> > But this highlights the fact that building the docs for a new Planet > package requires that the package is installed at build time. > Otherwise, the `planet create' command seems to be set up to avoid that > requirement. Maybe `planet create' should set up a temporary > development link while building a package? I think this would solve a number of problems. For one, there's great potential for inconsistency between building the docs on the developer's machine, the PLaneT server (for generating the public docs), or the user's machine. Dave From noelwelsh at gmail.com Mon Mar 9 10:46:15 2009 From: noelwelsh at gmail.com (Noel Welsh) Date: Mon Mar 9 10:46:34 2009 Subject: [plt-dev] Scribble errors in Dracula distribution In-Reply-To: <932b2f1f0903090557o5cb8baaex4f24969b5d957306@mail.gmail.com> References: <990e0c030902131028l8026edep2be73b92c586fcb5@mail.gmail.com> <20090309123035.91B426500AF@mail-svr1.cs.utah.edu> <932b2f1f0903090557o5cb8baaex4f24969b5d957306@mail.gmail.com> Message-ID: On Mon, Mar 9, 2009 at 12:57 PM, Robby Findler wrote: > It makes sense to me that planet create should be working from a > development link, not a directory. +1 N. From chust at web.de Mon Mar 9 11:24:41 2009 From: chust at web.de (Thomas Chust) Date: Mon Mar 9 11:25:01 2009 Subject: [plt-dev] Scribble errors in Dracula distribution In-Reply-To: <932b2f1f0903090557o5cb8baaex4f24969b5d957306@mail.gmail.com> References: <990e0c030902131028l8026edep2be73b92c586fcb5@mail.gmail.com> <20090309123035.91B426500AF@mail-svr1.cs.utah.edu> <932b2f1f0903090557o5cb8baaex4f24969b5d957306@mail.gmail.com> Message-ID: <1c1a33bc0903090824o48c054b2x1d6d057c96ecbc25@mail.gmail.com> 2009-03-09 Robby Findler : > It makes sense to me that planet create should be working from a > development link, not a directory. > [...] Hello, this sounds like a good idea, but in practice I have always used planet create on a cleanly setup directory and not the development link I used, simply to prevent it from including all sorts of stuff that doesn't belong in the package like editor backups and version control system support files. Maybe planet create should look at some sort of manifest file to determine what actually should go into the package? I think that would be useful. cu, Thomas -- When C++ is your hammer, every problem looks like your thumb. From cce at ccs.neu.edu Mon Mar 9 11:30:58 2009 From: cce at ccs.neu.edu (Carl Eastlund) Date: Mon Mar 9 11:31:24 2009 Subject: [plt-dev] Scribble errors in Dracula distribution In-Reply-To: <20090309123035.91B426500AF@mail-svr1.cs.utah.edu> References: <990e0c030902131028l8026edep2be73b92c586fcb5@mail.gmail.com> <20090309123035.91B426500AF@mail-svr1.cs.utah.edu> Message-ID: <990e0c030903090830x6b210f1bn55e6d9ca92bfea97@mail.gmail.com> On Mon, Mar 9, 2009 at 8:30 AM, Matthew Flatt wrote: > At Fri, 13 Feb 2009 13:28:18 -0500, Carl Eastlund wrote: >> The pre-built documentation I uploaded with Dracula 8.1 has some >> broken internal links. ?You can see an example in the first paragraph >> at: >> >> http://planet.plt-scheme.org/package-source/cce/dracula.plt/8/1/planet- >> docs/reference/index.html >> >> These links work fine in the Dracula package itself. ?Does anyone know >> why they wouldn't work in the version created for the .plt file? ?I >> didn't see any errors reported when I built the package, or I would >> have copied them and reported this problem then. >> >> Have any other planet package maintainers seen problems like this? > > I've finally looked into this. > > A file like "expressions.scrbl" in the Dracula document source has a > `for-label' import of "../../lang/dracula.ss" instead of `(planet > cce/dracula:8:1/lang/dracula))'. The relative path overlaps with the > Planet package after its installed, so that's why the installed docs > work. While building for the ".plt" file, though, Scribble doesn't know > that "../../lang/dracula.ss" in the source directory for the new > package corresponds to a Planet package. > > One solution is to use > > ?(require (for-label (planet cce/dracula:8:1/lang/dracula))) > > instead of relative-path `for-label' requires in the doc sources. Or > maybe add something like to `require-this-package-for-label' to the set > of documentation macros currently provided by `(planet > cce/scheme:3:0)'. If I do that, then every time I update the package, I have to search for every such occurrence and update cce/dracula:8:1/... to say cce/dracula:8:2/... or whatever. Hence the relative links that stay the same across updates. If I make a require expander that generates a (planet ...) spec with appropriate version number, will Scribble "understand" that? --Carl From neil at neilvandyke.org Mon Mar 9 11:32:49 2009 From: neil at neilvandyke.org (Neil Van Dyke) Date: Mon Mar 9 11:33:19 2009 Subject: [plt-dev] Scribble errors in Dracula distribution In-Reply-To: <1c1a33bc0903090824o48c054b2x1d6d057c96ecbc25@mail.gmail.com> References: <990e0c030902131028l8026edep2be73b92c586fcb5@mail.gmail.com> <20090309123035.91B426500AF@mail-svr1.cs.utah.edu> <932b2f1f0903090557o5cb8baaex4f24969b5d957306@mail.gmail.com> <1c1a33bc0903090824o48c054b2x1d6d057c96ecbc25@mail.gmail.com> Message-ID: <49B536A1.8050402@neilvandyke.org> Thomas Chust wrote at 03/09/2009 11:24 AM: > [...] but in practice I have always used > planet create on a cleanly setup directory and not the development > link I used, simply to prevent it from including all sorts of stuff > that doesn't belong in the package [...] Same here. My "Makefile" production is below. I always have a development link in place when building the PLaneT package, but I do wish to tightly control (in an opt-in way) what goes into the ".plt" file. $(PLANET_FILE): $(PLANET_FILES) Makefile rm -f $(PLANET_FILE) @if [ -e $(PLANET_DIR) ] ; then echo "ERROR: REMOVE $(PLANET_DIR)" ; false ; else true ; fi mkdir $(PLANET_DIR) cp $(PLANET_FILES) $(PLANET_DIR)/. $(PLANET_TOOL) create $(PLANET_DIR) rm -rf $(PLANET_DIR) From carl.eastlund at gmail.com Mon Mar 9 11:35:53 2009 From: carl.eastlund at gmail.com (Carl Eastlund) Date: Mon Mar 9 11:36:13 2009 Subject: [plt-dev] Scribble errors in Dracula distribution In-Reply-To: <1c1a33bc0903090824o48c054b2x1d6d057c96ecbc25@mail.gmail.com> References: <990e0c030902131028l8026edep2be73b92c586fcb5@mail.gmail.com> <20090309123035.91B426500AF@mail-svr1.cs.utah.edu> <932b2f1f0903090557o5cb8baaex4f24969b5d957306@mail.gmail.com> <1c1a33bc0903090824o48c054b2x1d6d057c96ecbc25@mail.gmail.com> Message-ID: <990e0c030903090835t407b132aoc3fd347fc9556ff7@mail.gmail.com> On Mon, Mar 9, 2009 at 11:24 AM, Thomas Chust wrote: > 2009-03-09 Robby Findler : >> It makes sense to me that planet create should be working from a >> development link, not a directory. >> [...] > > Hello, > > this sounds like a good idea, but in practice I have always used > planet create on a cleanly setup directory and not the development > link I used, simply to prevent it from including all sorts of stuff > that doesn't belong in the package like editor backups and version > control system support files. > > Maybe planet create should look at some sort of manifest file to > determine what actually should go into the package? I think that would > be useful. I think a clean space is a good idea, but the development link is important so Scribble can treat the files as part of the installation. It should be only a couple extra lines in a script, Makefile, whatever, to move the development link to point to the clean directory during the installation process, then move it back when you're done. --Carl From mflatt at cs.utah.edu Mon Mar 9 11:47:13 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Mon Mar 9 11:47:42 2009 Subject: [plt-dev] Scribble errors in Dracula distribution In-Reply-To: <990e0c030903090830x6b210f1bn55e6d9ca92bfea97@mail.gmail.com> References: <990e0c030902131028l8026edep2be73b92c586fcb5@mail.gmail.com> <20090309123035.91B426500AF@mail-svr1.cs.utah.edu> <990e0c030903090830x6b210f1bn55e6d9ca92bfea97@mail.gmail.com> Message-ID: <20090309154715.7C31865009C@mail-svr1.cs.utah.edu> At Mon, 9 Mar 2009 11:30:58 -0400, Carl Eastlund wrote: > If I make a require expander that generates > a (planet ...) spec with appropriate version number, will Scribble > "understand" that? Yes. Scribble just looks at `for-label' bindings, leaving it to the module+macro system to create those bindings. From cce at ccs.neu.edu Mon Mar 9 13:36:59 2009 From: cce at ccs.neu.edu (Carl Eastlund) Date: Mon Mar 9 13:37:18 2009 Subject: [plt-dev] Scribble errors in Dracula distribution In-Reply-To: <20090309154715.7C31865009C@mail-svr1.cs.utah.edu> References: <990e0c030902131028l8026edep2be73b92c586fcb5@mail.gmail.com> <20090309123035.91B426500AF@mail-svr1.cs.utah.edu> <990e0c030903090830x6b210f1bn55e6d9ca92bfea97@mail.gmail.com> <20090309154715.7C31865009C@mail-svr1.cs.utah.edu> Message-ID: <990e0c030903091036s263648edi9a1ef461e0275c61@mail.gmail.com> On Mon, Mar 9, 2009 at 11:47 AM, Matthew Flatt wrote: > At Mon, 9 Mar 2009 11:30:58 -0400, Carl Eastlund wrote: >> ?If I make a require expander that generates >> a (planet ...) spec with appropriate version number, will Scribble >> "understand" that? > > Yes. Scribble just looks at `for-label' bindings, leaving it to the > module+macro system to create those bindings. What is different about the result of (planet ...) bindings from relative bindings that gives Scribble a clue as to when to provide links, given that both should refer to the same file at the time the documentation is built? -- Carl Eastlund From jacobm at cs.uchicago.edu Mon Mar 9 13:43:16 2009 From: jacobm at cs.uchicago.edu (Jacob Matthews) Date: Mon Mar 9 13:44:02 2009 Subject: [plt-dev] Scribble errors in Dracula distribution In-Reply-To: <990e0c030903090835t407b132aoc3fd347fc9556ff7@mail.gmail.com> References: <990e0c030902131028l8026edep2be73b92c586fcb5@mail.gmail.com> <20090309123035.91B426500AF@mail-svr1.cs.utah.edu> <932b2f1f0903090557o5cb8baaex4f24969b5d957306@mail.gmail.com> <1c1a33bc0903090824o48c054b2x1d6d057c96ecbc25@mail.gmail.com> <990e0c030903090835t407b132aoc3fd347fc9556ff7@mail.gmail.com> Message-ID: <46b603df0903091043j33ad40c6gbdd9f536fbb7676e@mail.gmail.com> [-jacobm@google.com, +jacobm@gmail.com] [Moving this so it actually goes to me. jacobm@google.com is a different guy.] On Mon, Mar 9, 2009 at 8:35 AM, Carl Eastlund wrote: > On Mon, Mar 9, 2009 at 11:24 AM, Thomas Chust wrote: >> 2009-03-09 Robby Findler : >>> It makes sense to me that planet create should be working from a >>> development link, not a directory. >>> [...] >> >> Hello, >> >> this sounds like a good idea, but in practice I have always used >> planet create on a cleanly setup directory and not the development >> link I used, simply to prevent it from including all sorts of stuff >> that doesn't belong in the package like editor backups and version >> control system support files. >> >> Maybe planet create should look at some sort of manifest file to >> determine what actually should go into the package? I think that would >> be useful. > > I think a clean space is a good idea, but the development link is > important so Scribble can treat the files as part of the installation. > ?It should be only a couple extra lines in a script, Makefile, > whatever, to move the development link to point to the clean directory > during the installation process, then move it back when you're done. > > --Carl > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > > From mflatt at cs.utah.edu Mon Mar 9 13:43:36 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Mon Mar 9 13:44:07 2009 Subject: [plt-dev] Scribble errors in Dracula distribution In-Reply-To: <990e0c030903091036s263648edi9a1ef461e0275c61@mail.gmail.com> References: <990e0c030902131028l8026edep2be73b92c586fcb5@mail.gmail.com> <20090309123035.91B426500AF@mail-svr1.cs.utah.edu> <990e0c030903090830x6b210f1bn55e6d9ca92bfea97@mail.gmail.com> <20090309154715.7C31865009C@mail-svr1.cs.utah.edu> <990e0c030903091036s263648edi9a1ef461e0275c61@mail.gmail.com> Message-ID: <20090309174337.E1DCB65003B@mail-svr1.cs.utah.edu> At Mon, 9 Mar 2009 13:36:59 -0400, Carl Eastlund wrote: > On Mon, Mar 9, 2009 at 11:47 AM, Matthew Flatt wrote: > > At Mon, 9 Mar 2009 11:30:58 -0400, Carl Eastlund wrote: > >> ?If I make a require expander that generates > >> a (planet ...) spec with appropriate version number, will Scribble > >> "understand" that? > > > > Yes. Scribble just looks at `for-label' bindings, leaving it to the > > module+macro system to create those bindings. > > What is different about the result of (planet ...) bindings from > relative bindings that gives Scribble a clue as to when to provide > links, given that both should refer to the same file at the time the > documentation is built? The "given" isn't actually given. When you say planet create then even if and a package installation happen to be the same on the filesystem, `planet create' doesn't access through a `planet' path, so relative paths in are unrelated to Planet paths at the level of module paths. One current proposal is to have `planet create' build documentation out of a currently installed package, instead from an arbitrary directory. From mflatt at cs.utah.edu Mon Mar 9 13:52:49 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Mon Mar 9 13:53:10 2009 Subject: [plt-dev] Scribble errors in Dracula distribution In-Reply-To: <20090309174337.E1DCB65003B@mail-svr1.cs.utah.edu> References: <990e0c030902131028l8026edep2be73b92c586fcb5@mail.gmail.com> <20090309123035.91B426500AF@mail-svr1.cs.utah.edu> <990e0c030903090830x6b210f1bn55e6d9ca92bfea97@mail.gmail.com> <20090309154715.7C31865009C@mail-svr1.cs.utah.edu> <990e0c030903091036s263648edi9a1ef461e0275c61@mail.gmail.com> <20090309174337.E1DCB65003B@mail-svr1.cs.utah.edu> Message-ID: <20090309175251.302C565003B@mail-svr1.cs.utah.edu> At Mon, 9 Mar 2009 11:43:36 -0600, Matthew Flatt wrote: > At Mon, 9 Mar 2009 13:36:59 -0400, Carl Eastlund wrote: > > On Mon, Mar 9, 2009 at 11:47 AM, Matthew Flatt wrote: > > > At Mon, 9 Mar 2009 11:30:58 -0400, Carl Eastlund wrote: > > >> ?If I make a require expander that generates > > >> a (planet ...) spec with appropriate version number, will Scribble > > >> "understand" that? > > > > > > Yes. Scribble just looks at `for-label' bindings, leaving it to the > > > module+macro system to create those bindings. > > > > What is different about the result of (planet ...) bindings from > > relative bindings that gives Scribble a clue as to when to provide > > links, given that both should refer to the same file at the time the > > documentation is built? > > The "given" isn't actually given. > > When you say > > planet create > > then even if and a package installation happen to be the same on > the filesystem, `planet create' doesn't access through a `planet' > path, so relative paths in are unrelated to Planet paths at the > level of module paths. On further thought, it may not be because of the way that is accessed, but because `planet create' creates a directory to stage the package and then builds the docs out of that directory, instead of using the existing directory. (The coincidence of files accessed directly and through `planet' and `lib' paths is a little fragile, since there's no reliable way to normalize paths, but I think that's not the issue after all.) That is, `planet create' doesn't currently require the to be an installation, but if it does happen to be one, maybe that coincidence would be enough --- if the documentation were rendered using the existing document module, instead of a staged copy. Even so, we may not want to rely on that coincidence. From dherman at ccs.neu.edu Mon Mar 9 14:25:58 2009 From: dherman at ccs.neu.edu (Dave Herman) Date: Mon Mar 9 14:26:16 2009 Subject: [plt-dev] abstract/uncomputable contracts in Scribble Message-ID: <49B55F36.8050207@ccs.neu.edu> AFAICT there isn't a standard way to document something with a contract that doesn't actually correspond to a Scheme predicate. One place I miss this is when I want to describe a new parametric type. Another is when I reuse structs at different types. For example: 1) define some AST structs; 2) reuse those structs with #f in place of certain subterms to represent contexts. This could be represented as a parameteric type, but that's pretty heavyweight. It'd be nice to be able to say something like An /expression context/ is an expression where... and then be able to document procedures like (fill-context context expr) -> expr context : expression context expr : expression I can (and do) get lots of mileage out of `unsyntax' in Scribble, but wonder if this is worth adding a new idiom or two to Scribble. Dave From samth at ccs.neu.edu Mon Mar 9 16:15:46 2009 From: samth at ccs.neu.edu (Sam TH) Date: Mon Mar 9 16:16:07 2009 Subject: [plt-dev] syntax-local-value and identifier-mappings Message-ID: <63bb19ae0903091315jee5ad88la8c90254c9e6604b@mail.gmail.com> Typed Scheme is implemented using a free-identifier-mapping that associates type names with types. This has the nice property that it cooperates with the module system to track arbitrary requires, provides, and renamings. Unfortunately, it breaks in the presence of rename transformers. Right now, `syntax-local-value' cooperates with `make-rename-transformer' to 'do the right thing'. However, it's not possible to build any other abstractions with the same property, since you can't get out the target of a rename transformer (you can't even tell that an identifier is bound to one). It would be nice if `syntax-local-value' took an additional argument to specify that it shouldn't loop, so that other abstractions could be built that respected rename-transformers. Thanks, -- sam th samth@ccs.neu.edu From mflatt at cs.utah.edu Mon Mar 9 20:22:14 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Mon Mar 9 20:22:36 2009 Subject: [plt-dev] syntax-local-value and identifier-mappings In-Reply-To: <63bb19ae0903091315jee5ad88la8c90254c9e6604b@mail.gmail.com> References: <63bb19ae0903091315jee5ad88la8c90254c9e6604b@mail.gmail.com> Message-ID: <20090310002216.7CD5F6500A2@mail-svr1.cs.utah.edu> At Mon, 9 Mar 2009 16:15:46 -0400, Sam TH wrote: > Right now, `syntax-local-value' cooperates with > `make-rename-transformer' to 'do the right thing'. However, it's not > possible to build any other abstractions with the same property, since > you can't get out the target of a rename transformer (you can't even > tell that an identifier is bound to one). It would be nice if > `syntax-local-value' took an additional argument to specify that it > shouldn't loop, so that other abstractions could be built that > respected rename-transformers. I've tried this before, following much the same rationale. It turned out not to solve the problems that motivated it before, though, and so I removed that capability in an attempt to keep renaming more abstract. In particular, making intermediate names accessible might provide access to a scope that is otherwise unavailable (by taking a intermediate identifier's context and transferring it to a different symbol). At the same time, I agree that `make-rename-transformer' isn't right. One place this show up is in the package system, where opening a package doesn't give you the same bindings in terms of `free-identifier=?': (define-package p (x y) (define-syntax x (syntax-rules (y) [(x y) 'y] [(x z) 'other])) (define y 'placeholder)) (let () (open-package p) (x y)) ; => 'other, instead of 'y That's because `open-package' introduces new bindings to rename transformers, instead of actually splicing the bindings from the package. > Typed Scheme is implemented using a free-identifier-mapping that > associates type names with types. This has the nice property that it > cooperates with the module system to track arbitrary requires, > provides, and renamings. Unfortunately, it breaks in the presence of > rename transformers. This sounds like the same problem as for `open-package'. You don't specifically need to walk the links. You need a truer renaming --- one that works with `free-identifier=?'. Right? Ideally, the renaming should work at the level of syntax objects, where `free-identifier=?' lives, instead of at the level of transformer bindings. One possibility is a `define-renaming' form that adjusts bindings at the syntax-object level. That seems like the right thing at some level, but then we'd end up with a zoo of syntactic forms for local binding, etc. Also, it would require converting existing code. Another possibility is to have `free-identifier=?' inspect transformer bindings in the current scope, so that it would effectively walk a renaming chain in the same way as `syntax-local-value'. That would work with existing code, but move `free-identifier=?' out of the pure syntax-object level means that it wouldn't work quite always, and it might make comparisons significantly more expensive. One last possibility, which I had not really considered until now, is to have the macro expander treat a transformer binding to a renamer by applying a syntax-object renaming immediately, instead of merely installing a transformer binding. That sounds promising to me, and I could give it a try next week or so. From samth at ccs.neu.edu Mon Mar 9 20:33:17 2009 From: samth at ccs.neu.edu (Sam TH) Date: Mon Mar 9 20:33:37 2009 Subject: [plt-dev] syntax-local-value and identifier-mappings In-Reply-To: <20090310002216.7CD5F6500A2@mail-svr1.cs.utah.edu> References: <63bb19ae0903091315jee5ad88la8c90254c9e6604b@mail.gmail.com> <20090310002216.7CD5F6500A2@mail-svr1.cs.utah.edu> Message-ID: <63bb19ae0903091733l6f8797cao2b8304f6f306a321@mail.gmail.com> On Mon, Mar 9, 2009 at 8:22 PM, Matthew Flatt wrote: > At Mon, 9 Mar 2009 16:15:46 -0400, Sam TH wrote: >> Right now, `syntax-local-value' cooperates with >> `make-rename-transformer' to 'do the right thing'. ?However, it's not >> possible to build any other abstractions with the same property, since >> you can't get out the target of a rename transformer (you can't even >> tell that an identifier is bound to one). ?It would be nice if >> `syntax-local-value' took an additional argument to specify that it >> shouldn't loop, so that other abstractions could be built that >> respected rename-transformers. > > I've tried this before, following much the same rationale. It turned > out not to solve the problems that motivated it before, though, and so > I removed that capability in an attempt to keep renaming more abstract. > In particular, making intermediate names accessible might provide > access to a scope that is otherwise unavailable (by taking a > intermediate identifier's context and transferring it to a different > symbol). It seems like this sort of 'attack' is something the certificate system should be preventing. > At the same time, I agree that `make-rename-transformer' isn't right. > One place this show up is in the package system, where opening a > package doesn't give you the same bindings in terms of > `free-identifier=?': > > ?(define-package p (x y) > ? ?(define-syntax x > ? ? ?(syntax-rules (y) > ? ? ? ?[(x y) 'y] > ? ? ? ?[(x z) 'other])) > ? ?(define y 'placeholder)) > > ?(let () > ?(open-package p) > ?(x y)) ; => 'other, instead of 'y > > That's because `open-package' introduces new bindings to rename > transformers, instead of actually splicing the bindings from the > package. > >> Typed Scheme is implemented using a free-identifier-mapping that >> associates type names with types. ?This has the nice property that it >> cooperates with the module system to track arbitrary requires, >> provides, and renamings. ?Unfortunately, it breaks in the presence of >> rename transformers. > > This sounds like the same problem as for `open-package'. You don't > specifically need to walk the links. You need a truer renaming --- one > that works with `free-identifier=?'. Right? So, in one sense, if (as you suggest) `free-identifier=?' cooperated with rename transformers, then that would work. But the other constraint is that I need the binding form to operate at the expression level, since the code that uses `make-rename-transformer' looks like this: (define-syntax foo (if (typed-context?) (make-rename-transformer #'foo*) (make-rename-transformer #'other-foo))) so something like `define-renaming' wouldn't work. > Ideally, the renaming should work at the level of syntax objects, where > `free-identifier=?' lives, instead of at the level of transformer > bindings. > > One possibility is a `define-renaming' form that adjusts bindings at > the syntax-object level. That seems like the right thing at some level, > but then we'd end up with a zoo of syntactic forms for local binding, > etc. Also, it would require converting existing code. > > Another possibility is to have `free-identifier=?' inspect transformer > bindings in the current scope, so that it would effectively walk a > renaming chain in the same way as `syntax-local-value'. That would work > with existing code, but move `free-identifier=?' out of the pure > syntax-object level means that it wouldn't work quite always, and it > might make comparisons significantly more expensive. > > One last possibility, which I had not really considered until now, is > to have the macro expander treat a transformer binding to a renamer by > applying a syntax-object renaming immediately, instead of merely > installing a transformer binding. That sounds promising to me, and I > could give it a try next week or so. I'm not sure what you mean here. Would this be the expander that processes the binding, or the reference? Thanks, -- sam th samth@ccs.neu.edu From mflatt at cs.utah.edu Mon Mar 9 20:49:39 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Mon Mar 9 20:50:00 2009 Subject: [plt-dev] syntax-local-value and identifier-mappings In-Reply-To: <63bb19ae0903091733l6f8797cao2b8304f6f306a321@mail.gmail.com> References: <63bb19ae0903091315jee5ad88la8c90254c9e6604b@mail.gmail.com> <20090310002216.7CD5F6500A2@mail-svr1.cs.utah.edu> <63bb19ae0903091733l6f8797cao2b8304f6f306a321@mail.gmail.com> Message-ID: <20090310004941.8B59D6500A9@mail-svr1.cs.utah.edu> At Mon, 9 Mar 2009 20:33:17 -0400, Sam TH wrote: > On Mon, Mar 9, 2009 at 8:22 PM, Matthew Flatt wrote: > > At Mon, 9 Mar 2009 16:15:46 -0400, Sam TH wrote: > >> Right now, `syntax-local-value' cooperates with > >> `make-rename-transformer' to 'do the right thing'. ?However, it's not > >> possible to build any other abstractions with the same property, since > >> you can't get out the target of a rename transformer (you can't even > >> tell that an identifier is bound to one). ?It would be nice if > >> `syntax-local-value' took an additional argument to specify that it > >> shouldn't loop, so that other abstractions could be built that > >> respected rename-transformers. > > > > I've tried this before, following much the same rationale. It turned > > out not to solve the problems that motivated it before, though, and so > > I removed that capability in an attempt to keep renaming more abstract. > > In particular, making intermediate names accessible might provide > > access to a scope that is otherwise unavailable (by taking a > > intermediate identifier's context and transferring it to a different > > symbol). > > It seems like this sort of 'attack' is something the certificate > system should be preventing. Yes, I suppose it would. Maybe that's not a problem after all. Still, getting `free-identifier=?' to work seems like a more useful result. > But the other > constraint is that I need the binding form to operate at the > expression level, since the code that uses `make-rename-transformer' > looks like this: > > (define-syntax foo > (if (typed-context?) > (make-rename-transformer #'foo*) > (make-rename-transformer #'other-foo))) > > so something like `define-renaming' wouldn't work. It depends on what's allowed on the right-hand side of `define-renaming'. In any case, triggering `define-renaming'-like behavior through a rename-transformer result would allow the above pattern. > > One last possibility, which I had not really considered until now, is > > to have the macro expander treat a transformer binding to a renamer by > > applying a syntax-object renaming immediately, instead of merely > > installing a transformer binding. That sounds promising to me, and I > > could give it a try next week or so. > > I'm not sure what you mean here. Would this be the expander that > processes the binding, or the reference? The expander. The expander already applies one kind of syntax-object renaming for the binding introduced by `define', `define-syntax', `let-values', `letrec-syntax', etc. When it sees a rename-transformer value for a transformer binding, it would apply an additional syntax-object annotation, which `free-identifier=?' would use to connect the old and new bindings. From sperber at deinprogramm.de Tue Mar 10 03:00:11 2009 From: sperber at deinprogramm.de (Michael Sperber) Date: Tue Mar 10 03:06:39 2009 Subject: [plt-dev] new collection: deinprogramm In-Reply-To: <11b141710903090418r25900921sdd146751ded6eb6c@mail.gmail.com> (Paulo J. Matos's message of "Mon, 9 Mar 2009 11:18:30 +0000") References: <20090309111317.A9CBD6500A9@mail-svr1.cs.utah.edu> <11b141710903090418r25900921sdd146751ded6eb6c@mail.gmail.com> Message-ID: "Paulo J. Matos" writes: > I am currently learning German, so since I am still not really fluent, > I guess I might give it a try in a couple of months. Doesn't it bring > anything new for PLAI / EOPL / HTDP / SICP readers? Not substantially. It's really a German variation of HtDP. -- Cheers =8-} Mike Friede, V?lkerverst?ndigung und ?berhaupt blabla From jay.mccarthy at gmail.com Tue Mar 10 18:06:26 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Tue Mar 10 18:06:47 2009 Subject: [plt-dev] Terminal control Message-ID: Don't ask why, but I'd like to do a terminal app with PLT. But I can figure out how to capture key presses as they are done. I can type something in and press enter, but I can't capture the key right when it is pressed, do something, and NOT print it out. I assumed that read-byte would do it, but apparently not. Any suggestions? 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 Tue Mar 10 18:31:57 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Tue Mar 10 18:32:19 2009 Subject: [plt-dev] Terminal control In-Reply-To: References: Message-ID: <20090310223159.E27AA650091@mail-svr1.cs.utah.edu> At Tue, 10 Mar 2009 16:06:26 -0600, Jay McCarthy wrote: > Don't ask why, but I'd like to do a terminal app with PLT. > > But I can figure out how to capture key presses as they are done. I > can type something in and press enter, but I can't capture the key > right when it is pressed, do something, and NOT print it out. > > I assumed that read-byte would do it, but apparently not. > > Any suggestions? You probably want to use the C library's "termios" functions to control the terminal associated with stdin. Try `man cfmakeraw' for more information. You'll also need scheme_get_port_fd() to go from a Scheme port to a file descriptor. (Yep, I see the typo in the docs for that one... fixed in SVN.) From eli at barzilay.org Tue Mar 10 18:42:56 2009 From: eli at barzilay.org (Eli Barzilay) Date: Tue Mar 10 18:43:19 2009 Subject: [plt-dev] Terminal control In-Reply-To: <20090310223159.E27AA650091@mail-svr1.cs.utah.edu> References: <20090310223159.E27AA650091@mail-svr1.cs.utah.edu> Message-ID: <18870.60656.746442.656025@winooski.ccs.neu.edu> On Mar 10, Matthew Flatt wrote: > At Tue, 10 Mar 2009 16:06:26 -0600, Jay McCarthy wrote: > > Don't ask why, but I'd like to do a terminal app with PLT. > > > > But I can figure out how to capture key presses as they are > > done. I can type something in and press enter, but I can't capture > > the key right when it is pressed, do something, and NOT print it > > out. > > > > I assumed that read-byte would do it, but apparently not. > > > > Any suggestions? > > You probably want to use the C library's "termios" functions to > control the terminal associated with stdin. Try `man cfmakeraw' for > more information. > > You'll also need scheme_get_port_fd() to go from a Scheme port to a > file descriptor. (Yep, I see the typo in the docs for that > one... fixed in SVN.) It might be easier to just use stty, which can get you that kind of control. Here's some code that demonstrates how to get single characters as they come, without echoing them back. (I've been using variations of this for a long time for all kinds of convenient scripts.) #!/bin/env mzscheme #lang scheme/base (require scheme/system) (define (call-with-stty thunk) (define stty-exe (or (find-executable-path "stty") (error 'stty "could not find executable"))) (define (stty . args) (or (apply system* stty-exe args) (error 'stty "couldn't run with ~e" args))) (define (get) (let ([o (open-output-string)]) (parameterize ([current-output-port o]) (stty "-g") (regexp-replace #rx"\r?\n$" (get-output-string o) "")))) (let ([settings (get)]) (dynamic-wind (lambda () (stty "raw" "-echo" "opost")) thunk (lambda () (stty settings))))) (call-with-stty (lambda () (let loop () (printf "Hit any key, q to exit: ") (flush-output) (let ([ch (read-char)]) (printf "~s\n" ch) (unless (eq? ch #\q) (loop)))))) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From jay.mccarthy at gmail.com Tue Mar 10 18:44:29 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Tue Mar 10 18:44:51 2009 Subject: [plt-dev] Terminal control In-Reply-To: <18870.60656.746442.656025@winooski.ccs.neu.edu> References: <20090310223159.E27AA650091@mail-svr1.cs.utah.edu> <18870.60656.746442.656025@winooski.ccs.neu.edu> Message-ID: Cool. I'll try these out! Jay On Tue, Mar 10, 2009 at 4:42 PM, Eli Barzilay wrote: > On Mar 10, Matthew Flatt wrote: >> At Tue, 10 Mar 2009 16:06:26 -0600, Jay McCarthy wrote: >> > Don't ask why, but I'd like to do a terminal app with PLT. >> > >> > But I can figure out how to capture key presses as they are >> > done. I can type something in and press enter, but I can't capture >> > the key right when it is pressed, do something, and NOT print it >> > out. >> > >> > I assumed that read-byte would do it, but apparently not. >> > >> > Any suggestions? >> >> You probably want to use the C library's "termios" functions to >> control the terminal associated with stdin. Try `man cfmakeraw' for >> more information. >> >> You'll also need scheme_get_port_fd() to go from a Scheme port to a >> file descriptor. (Yep, I see the typo in the docs for that >> one... fixed in SVN.) > > It might be easier to just use stty, which can get you that kind of > control. ?Here's some code that demonstrates how to get single > characters as they come, without echoing them back. ?(I've been using > variations of this for a long time for all kinds of convenient > scripts.) > > > #!/bin/env mzscheme > > #lang scheme/base > > (require scheme/system) > > (define (call-with-stty thunk) > ?(define stty-exe > ? ?(or (find-executable-path "stty") > ? ? ? ?(error 'stty "could not find executable"))) > ?(define (stty . args) > ? ?(or (apply system* stty-exe args) > ? ? ? ?(error 'stty "couldn't run with ~e" args))) > ?(define (get) > ? ?(let ([o (open-output-string)]) > ? ? ?(parameterize ([current-output-port o]) > ? ? ? ?(stty "-g") > ? ? ? ?(regexp-replace #rx"\r?\n$" (get-output-string o) "")))) > ?(let ([settings (get)]) > ? ?(dynamic-wind (lambda () (stty "raw" "-echo" "opost")) > ? ? ? ? ? ? ? ? ?thunk > ? ? ? ? ? ? ? ? ?(lambda () (stty settings))))) > > (call-with-stty > ?(lambda () > ? ?(let loop () > ? ? ?(printf "Hit any key, q to exit: ") > ? ? ?(flush-output) > ? ? ?(let ([ch (read-char)]) > ? ? ? ?(printf "~s\n" ch) > ? ? ? ?(unless (eq? ch #\q) (loop)))))) > > > > -- > ? ? ? ? ?((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 samth at ccs.neu.edu Tue Mar 10 19:01:15 2009 From: samth at ccs.neu.edu (Sam TH) Date: Tue Mar 10 19:01:34 2009 Subject: [plt-dev] require with multiple forms Message-ID: <63bb19ae0903101601o3c42a9a1w579676ff5f75a108@mail.gmail.com> Right now, (require A B C) expands all of A, B, and C before requiring any of them. This means that if the `foo' collection provides the `foo-in' require transformer, this doesn't work: (require foo (foo-in bar)) Instead, you have to write this: (require foo) (require (foo-in bar)) The following patch changes (require A ...) to be (begin (require A) ...), so that the first example should now work, which I would find significantly more convenient. If there aren't objections, I'll write some tests and commit this. -- sam th samth@ccs.neu.edu Index: collects/scheme/private/reqprov.ss =================================================================== --- collects/scheme/private/reqprov.ss (revision 14026) +++ collects/scheme/private/reqprov.ss (working copy) @@ -317,12 +317,12 @@ (syntax->list #'(elem ...))))] [_ (transform-simple in 0 #| run phase |#)]))]) (syntax-case stx () + [(_ in) + (with-syntax ([(new-in ...) (transform-one #'in)]) + (syntax/loc stx + (#%require new-in ...)))] [(_ in ...) - (with-syntax ([(new-in ...) - (apply append - (map transform-one (syntax->list #'(in ...))))]) - (syntax/loc stx - (#%require new-in ...)))]))) + (syntax/loc stx (begin (require in) ...))]))) ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; require transformers From matthias at ccs.neu.edu Tue Mar 10 20:40:23 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Tue Mar 10 20:41:12 2009 Subject: [plt-dev] Re: [plt-bug] all/10123: spelling error in redex scribble docs In-Reply-To: <200903110020.n2B0K1bU006598@champlain.ccs.neu.edu> References: <200903110020.n2B0K1bU006598@champlain.ccs.neu.edu> Message-ID: <8EC0F967-CFFF-4C2F-8EEE-3B550CD5B97B@ccs.neu.edu> On Mar 10, 2009, at 8:20 PM, pnkfelix@ccs.neu.edu wrote: > Port Emacs' flyspell mode to DrScheme. This has been on Robby's list for a while but by golly, it's a great task for a volunteer -- Matthias From robby at eecs.northwestern.edu Tue Mar 10 21:50:05 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Tue Mar 10 21:50:26 2009 Subject: [plt-dev] Re: [plt-bug] all/10123: spelling error in redex scribble docs In-Reply-To: <8EC0F967-CFFF-4C2F-8EEE-3B550CD5B97B@ccs.neu.edu> References: <200903110020.n2B0K1bU006598@champlain.ccs.neu.edu> <8EC0F967-CFFF-4C2F-8EEE-3B550CD5B97B@ccs.neu.edu> Message-ID: <932b2f1f0903101850s43931b69g75c2f219bfdbac2e@mail.gmail.com> FWIW, I did do a spell checker for SirMail that uses the same setup as the syntax colorer, so one could turn that on for strings or for comments, I expect. Robby On Tue, Mar 10, 2009 at 7:40 PM, Matthias Felleisen wrote: > > On Mar 10, 2009, at 8:20 PM, pnkfelix@ccs.neu.edu wrote: > >> ?Port Emacs' flyspell mode to DrScheme. > > > This has been on Robby's list for a while but by golly, it's a great task > for a volunteer -- Matthias > > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > From czhu at cs.utah.edu Wed Mar 11 00:28:06 2009 From: czhu at cs.utah.edu (Chongkai Zhu) Date: Wed Mar 11 00:28:29 2009 Subject: [plt-dev] macro stepper question Message-ID: <49B73DD6.4090501@cs.utah.edu> Macro step on the following code with standard hiding (or as long as mzscheme syntax is hidden): (require scheme/package) (define-syntax-rule (d t) t) (match (d 1) (x x)) (define-package p #:all-defined (match (d 1) (x x))) The (d 1) in the top-level match expression gets expended, but the same macro in the package stay unexpanded. Is this a bug? Chongkai From rafkind at cs.utah.edu Wed Mar 11 01:57:34 2009 From: rafkind at cs.utah.edu (Jon Rafkind) Date: Wed Mar 11 01:57:54 2009 Subject: [plt-dev] setup-plt error Message-ID: <49B752CE.4000202@cs.utah.edu> I just updated svn (14049) and built from source. I saw this in setup-plt. ... setup-plt: running: web-server/scribblings/web-server.scrbl ffi-lib: couldn't open "libcrypto.so" (libcrypto.so: cannot open shared object file: No such file or directory) setup-plt: running: web-server/scribblings/tutorial/continue.scrbl setup-plt: running: xml/xml.scrbl ... I'm sure someone will know instantly what the problem is. From neil at neilvandyke.org Wed Mar 11 02:30:07 2009 From: neil at neilvandyke.org (Neil Van Dyke) Date: Wed Mar 11 02:30:29 2009 Subject: [plt-dev] setup-plt error In-Reply-To: <49B752CE.4000202@cs.utah.edu> References: <49B752CE.4000202@cs.utah.edu> Message-ID: <49B75A6F.5010107@neilvandyke.org> Jon Rafkind wrote at 03/11/2009 01:57 AM: > I just updated svn (14049) and built from source. I saw this in > setup-plt. > > ... > setup-plt: running: web-server/scribblings/web-server.scrbl > ffi-lib: couldn't open "libcrypto.so" (libcrypto.so: cannot open > shared object file: No such file or directory) [...] I suspect that's one of the OpenSSL shared libraries. Perhaps you don't have that installed? I don't know what OS distribution you have. If you were using Debian GNU/Linux "stable", you'd want to do an "apt-get install libssl0.9.8 openssl". Neil -- http://www.neilvandyke.org/ From rafkind at cs.utah.edu Wed Mar 11 11:29:04 2009 From: rafkind at cs.utah.edu (Jon Rafkind) Date: Wed Mar 11 11:29:24 2009 Subject: [plt-dev] setup-plt error In-Reply-To: <49B75A6F.5010107@neilvandyke.org> References: <49B752CE.4000202@cs.utah.edu> <49B75A6F.5010107@neilvandyke.org> Message-ID: <49B7D8C0.3040409@cs.utah.edu> Neil Van Dyke wrote: > Jon Rafkind wrote at 03/11/2009 01:57 AM: >> I just updated svn (14049) and built from source. I saw this in >> setup-plt. >> >> ... >> setup-plt: running: web-server/scribblings/web-server.scrbl >> ffi-lib: couldn't open "libcrypto.so" (libcrypto.so: cannot open >> shared object file: No such file or directory) > [...] > > I suspect that's one of the OpenSSL shared libraries. Perhaps you > don't have that installed? I checked that. /usr/lib $ ls -l libcrypt* -rw-r--r-- 1 root root 44870 2008-09-12 08:33 libcrypt.a -rw-r--r-- 1 root root 1342340 2009-01-07 11:43 libcrypto.so.0.9.8 lrwxrwxrwx 1 root root 18 2008-09-30 09:30 libcrypt.so -> /lib/libcrypt.so.1 lrwxrwxrwx 1 root root 19 2008-09-30 07:30 libcryptui.so.0 -> libcryptui.so.0.0.0 -rw-r--r-- 1 root root 56056 2008-05-27 08:45 libcryptui.so.0.0.0 Annnnd now I see the problem too. libcrypt != libcrypto I guess. Do other system symlink libcrypto.so.x.y.z to libcrypto.so? I am using ubuntu 8.04. From jay.mccarthy at gmail.com Wed Mar 11 11:34:39 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Wed Mar 11 11:35:00 2009 Subject: [plt-dev] setup-plt error In-Reply-To: <49B7D8C0.3040409@cs.utah.edu> References: <49B752CE.4000202@cs.utah.edu> <49B75A6F.5010107@neilvandyke.org> <49B7D8C0.3040409@cs.utah.edu> Message-ID: FYI, the web-server uses libcrypto to get the HMAC-SHA1 functions. It does it the same way the openssl library calls libcrypto. So whatever problem you're discovering "should" be a problem with (require openssl) also. Jay On Wed, Mar 11, 2009 at 9:29 AM, Jon Rafkind wrote: > Neil Van Dyke wrote: >> >> Jon Rafkind wrote at 03/11/2009 01:57 AM: >>> >>> I just updated svn (14049) and built from source. I saw this in >>> setup-plt. >>> >>> ... >>> setup-plt: running: web-server/scribblings/web-server.scrbl >>> ffi-lib: couldn't open "libcrypto.so" (libcrypto.so: cannot open shared >>> object file: No such file or directory) >> >> [...] >> >> I suspect ?that's one of the OpenSSL shared libraries. ?Perhaps you don't >> have that installed? > > I checked that. > /usr/lib $ ls -l libcrypt* > -rw-r--r-- 1 root root ? 44870 2008-09-12 08:33 libcrypt.a > -rw-r--r-- 1 root root 1342340 2009-01-07 11:43 libcrypto.so.0.9.8 > lrwxrwxrwx 1 root root ? ? ?18 2008-09-30 09:30 libcrypt.so -> > /lib/libcrypt.so.1 > lrwxrwxrwx 1 root root ? ? ?19 2008-09-30 07:30 libcryptui.so.0 -> > libcryptui.so.0.0.0 > -rw-r--r-- 1 root root ? 56056 2008-05-27 08:45 libcryptui.so.0.0.0 > > Annnnd now I see the problem too. libcrypt != libcrypto I guess. Do other > system symlink libcrypto.so.x.y.z to libcrypto.so? I am using ubuntu 8.04. > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From eli at barzilay.org Wed Mar 11 11:39:43 2009 From: eli at barzilay.org (Eli Barzilay) Date: Wed Mar 11 11:40:24 2009 Subject: [plt-dev] setup-plt error In-Reply-To: References: <49B752CE.4000202@cs.utah.edu> <49B75A6F.5010107@neilvandyke.org> <49B7D8C0.3040409@cs.utah.edu> Message-ID: <18871.56127.570344.718879@winooski.ccs.neu.edu> It sounds like there are examples in the documentation that use this functionality -- if this is the case then it's better to remove them so people without the library will still be able to run setup-plt without errors. On Mar 11, Jay McCarthy wrote: > FYI, the web-server uses libcrypto to get the HMAC-SHA1 > functions. It does it the same way the openssl library calls > libcrypto. So whatever problem you're discovering "should" be a > problem with > > (require openssl) > > also. > > Jay > > On Wed, Mar 11, 2009 at 9:29 AM, Jon Rafkind wrote: > > Neil Van Dyke wrote: > >> > >> Jon Rafkind wrote at 03/11/2009 01:57 AM: > >>> > >>> I just updated svn (14049) and built from source. I saw this in > >>> setup-plt. > >>> > >>> ... > >>> setup-plt: running: web-server/scribblings/web-server.scrbl > >>> ffi-lib: couldn't open "libcrypto.so" (libcrypto.so: cannot open shared > >>> object file: No such file or directory) > >> > >> [...] -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From ryanc at ccs.neu.edu Wed Mar 11 11:45:22 2009 From: ryanc at ccs.neu.edu (Ryan Culpepper) Date: Wed Mar 11 11:45:51 2009 Subject: [plt-dev] macro stepper question In-Reply-To: <49B73DD6.4090501@cs.utah.edu> References: <49B73DD6.4090501@cs.utah.edu> Message-ID: <426EB5CE-9EB8-495F-B652-FB5F512D0C58@ccs.neu.edu> On Mar 11, 2009, at 12:28 AM, Chongkai Zhu wrote: > Macro step on the following code with standard hiding (or as long as > mzscheme syntax is hidden): > > (require scheme/package) > > (define-syntax-rule (d t) > t) > > (match (d 1) > (x x)) > > (define-package p #:all-defined > (match (d 1) > (x x))) > > The (d 1) in the top-level match expression gets expended, but the > same macro in the package stay unexpanded. Is this a bug? I think 'define-package' is doing some renames in a way that escapes the macro stepper. I'll have an idea of what's happening and how I can fix it, but I haven't had time to test my hypothesis yet. Ryan > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From jay.mccarthy at gmail.com Wed Mar 11 11:46:16 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Wed Mar 11 11:46:39 2009 Subject: [plt-dev] setup-plt error In-Reply-To: <18871.56127.570344.718879@winooski.ccs.neu.edu> References: <49B752CE.4000202@cs.utah.edu> <49B75A6F.5010107@neilvandyke.org> <49B7D8C0.3040409@cs.utah.edu> <18871.56127.570344.718879@winooski.ccs.neu.edu> Message-ID: Okay, but my point is that he DOES have the library, yet can't use the openssl or this part of the web-server. So we should figure out how to fix that. Jay On Wed, Mar 11, 2009 at 9:39 AM, Eli Barzilay wrote: > It sounds like there are examples in the documentation that use this > functionality -- if this is the case then it's better to remove them > so people without the library will still be able to run setup-plt > without errors. > > > On Mar 11, Jay McCarthy wrote: >> FYI, the web-server uses libcrypto to get the HMAC-SHA1 >> functions. It does it the same way the openssl library calls >> libcrypto. So whatever problem you're discovering "should" be a >> problem with >> >> (require openssl) >> >> also. >> >> Jay >> >> On Wed, Mar 11, 2009 at 9:29 AM, Jon Rafkind wrote: >> > Neil Van Dyke wrote: >> >> >> >> Jon Rafkind wrote at 03/11/2009 01:57 AM: >> >>> >> >>> I just updated svn (14049) and built from source. I saw this in >> >>> setup-plt. >> >>> >> >>> ... >> >>> setup-plt: running: web-server/scribblings/web-server.scrbl >> >>> ffi-lib: couldn't open "libcrypto.so" (libcrypto.so: cannot open shared >> >>> object file: No such file or directory) >> >> >> >> [...] > > -- > ? ? ? ? ?((lambda (x) (x x)) (lambda (x) (x x))) ? ? ? ? ?Eli Barzilay: > ? ? ? ? ? ? ? ? ?http://www.barzilay.org/ ? ? ? ? ? ? ? ? Maze is Life! > -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From eli at barzilay.org Wed Mar 11 11:49:29 2009 From: eli at barzilay.org (Eli Barzilay) Date: Wed Mar 11 11:49:55 2009 Subject: [plt-dev] setup-plt error In-Reply-To: References: <49B752CE.4000202@cs.utah.edu> <49B75A6F.5010107@neilvandyke.org> <49B7D8C0.3040409@cs.utah.edu> <18871.56127.570344.718879@winooski.ccs.neu.edu> Message-ID: <18871.56713.744178.234457@winooski.ccs.neu.edu> On Mar 11, Jay McCarthy wrote: > Okay, but my point is that he DOES have the library, yet can't use > the openssl or this part of the web-server. So we should figure out > how to fix that. (I don't know why that happens, it should find "libcrypto.so.0.9.8".) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From czhu at cs.utah.edu Wed Mar 11 13:28:28 2009 From: czhu at cs.utah.edu (Chongkai Zhu) Date: Wed Mar 11 13:28:48 2009 Subject: [plt-dev] macro stepper question In-Reply-To: <426EB5CE-9EB8-495F-B652-FB5F512D0C58@ccs.neu.edu> References: <49B73DD6.4090501@cs.utah.edu> <426EB5CE-9EB8-495F-B652-FB5F512D0C58@ccs.neu.edu> Message-ID: <49B7F4BC.6000206@cs.utah.edu> Thanks. As I noted, not only `match' but quite some expressions (most just sit inside some of my own macro(s) that expands to `begin' don't expand inside a package. I would assume they are all caused by the same reason. Chongkai Ryan Culpepper wrote: > On Mar 11, 2009, at 12:28 AM, Chongkai Zhu wrote: > >> Macro step on the following code with standard hiding (or as long as >> mzscheme syntax is hidden): >> >> (require scheme/package) >> >> (define-syntax-rule (d t) >> t) >> >> (match (d 1) >> (x x)) >> >> (define-package p #:all-defined >> (match (d 1) >> (x x))) >> >> The (d 1) in the top-level match expression gets expended, but the >> same macro in the package stay unexpanded. Is this a bug? > > I think 'define-package' is doing some renames in a way that escapes > the macro stepper. I'll have an idea of what's happening and how I can > fix it, but I haven't had time to test my hypothesis yet. > > Ryan > >> _________________________________________________ >> For list-related administrative tasks: >> http://list.cs.brown.edu/mailman/listinfo/plt-dev From ryanc at ccs.neu.edu Thu Mar 12 14:16:06 2009 From: ryanc at ccs.neu.edu (Ryan Culpepper) Date: Thu Mar 12 14:16:38 2009 Subject: [plt-dev] module pretty printing Message-ID: <49B95166.2010508@ccs.neu.edu> Does anyone mind if I add a new rule for module pretty-printing? The current rule is "two up, rest as expr-list", which leads to things like this: (module m lang (define-syntax name ;; <-- (syntax-rules () ((_) 'ok)))) The new rule would be "two up, rest as expr": (module m lang (define-syntax mac (syntax-rules () ((_) 'blah)))) Ryan From robby at eecs.northwestern.edu Fri Mar 13 07:39:53 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Fri Mar 13 07:40:12 2009 Subject: [plt-dev] xml contract violation Message-ID: <932b2f1f0903130439y4008ed8dn1f77c453a8b4cc42@mail.gmail.com> Anyone recognize this? (file "C:\\cygwin\\home\\robby\\svn\\exp\\plt\\collects\\xml\\private\\reader.ss") broke the contract (-> (or/c location? symbol? #f) (or/c location? symbol? #f) symbol? (listof attribute?) (listof (or/c permissive/c pcdata? element? entity? comment? cdata? p-i?)) element?) on make-element; not in permissive mode === context === C:\cygwin\home\robby\svn\exp\plt\collects\scheme\private\contract-guts.ss:220:0: raise-contract-error C:\cygwin\home\robby\svn\exp\plt\collects\scheme\private\map.ss:22:17: loop C:\cygwin\home\robby\svn\exp\plt\collects\scheme\private\contract-arrow.ss:1347:3 C:\cygwin\home\robby\svn\exp\plt\collects\xml\private\reader.ss:89:4: read-content C:\cygwin\home\robby\svn\exp\plt\collects\xml\private\reader.ss:89:4: read-content C:\cygwin\home\robby\svn\exp\plt\collects\xml\private\reader.ss:24:2: read-xml C:\cygwin\home\robby\svn\exp\plt\collects\stepper\private\xml-snip-helpers.ss:52:7 C:\cygwin\home\robby\svn\exp\plt\collects\syntax\module-reader.ss:87:19: loop C:\cygwin\home\robby\svn\exp\plt\collects\syntax\module-reader.ss:78:0: wrap-internal C:\cygwin\home\robby\svn\exp\plt\collects\wxme\wxme.ss:665:2: do-read C:\cygwin\home\robby\svn\exp\plt\collects\wxme\wxme.ss:694:2: wxme-read-syntax C:\cygwin\home\robby\html\build-tree.scm:10:2: build-directory From jay.mccarthy at gmail.com Fri Mar 13 08:12:17 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Fri Mar 13 08:12:38 2009 Subject: [plt-dev] xml contract violation In-Reply-To: <932b2f1f0903130439y4008ed8dn1f77c453a8b4cc42@mail.gmail.com> References: <932b2f1f0903130439y4008ed8dn1f77c453a8b4cc42@mail.gmail.com> Message-ID: The way that the XML boxes work is to have the XML collect parse XML that contains embedded structs that aren't XML. To implement that, but provide real contracts in other places, it uses a permissive? parameter to control whether the contract is enforced. It looks like when I added the permissive? parameterizes, I may've missed one place that needed them... On line 55 of stepper/private/xml-snip-helpers, that call to read-xml should be wrapped in parameterize (like the line after it) and maybe the eliminate-whitespace one too. But I don't know how to test that unit test that code... (I just tried something and can't make it error like you have.) Jay On Fri, Mar 13, 2009 at 5:39 AM, Robby Findler wrote: > Anyone recognize this? > > (file "C:\\cygwin\\home\\robby\\svn\\exp\\plt\\collects\\xml\\private\\reader.ss") > broke the contract > ?(-> > ? (or/c location? symbol? #f) > ? (or/c location? symbol? #f) > ? symbol? > ? (listof attribute?) > ? (listof > ? ?(or/c > ? ? permissive/c > ? ? pcdata? > ? ? element? > ? ? entity? > ? ? comment? > ? ? cdata? > ? ? p-i?)) > ? element?) > ?on make-element; not in permissive mode > > ?=== context === > C:\cygwin\home\robby\svn\exp\plt\collects\scheme\private\contract-guts.ss:220:0: > raise-contract-error > C:\cygwin\home\robby\svn\exp\plt\collects\scheme\private\map.ss:22:17: loop > C:\cygwin\home\robby\svn\exp\plt\collects\scheme\private\contract-arrow.ss:1347:3 > C:\cygwin\home\robby\svn\exp\plt\collects\xml\private\reader.ss:89:4: > read-content > C:\cygwin\home\robby\svn\exp\plt\collects\xml\private\reader.ss:89:4: > read-content > C:\cygwin\home\robby\svn\exp\plt\collects\xml\private\reader.ss:24:2: read-xml > C:\cygwin\home\robby\svn\exp\plt\collects\stepper\private\xml-snip-helpers.ss:52:7 > C:\cygwin\home\robby\svn\exp\plt\collects\syntax\module-reader.ss:87:19: loop > C:\cygwin\home\robby\svn\exp\plt\collects\syntax\module-reader.ss:78:0: > wrap-internal > C:\cygwin\home\robby\svn\exp\plt\collects\wxme\wxme.ss:665:2: do-read > C:\cygwin\home\robby\svn\exp\plt\collects\wxme\wxme.ss:694:2: wxme-read-syntax > C:\cygwin\home\robby\html\build-tree.scm:10:2: build-directory > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From neil at neilvandyke.org Sat Mar 14 04:29:13 2009 From: neil at neilvandyke.org (Neil Van Dyke) Date: Sat Mar 14 04:29:34 2009 Subject: [plt-dev] trust of PLaneT packages Message-ID: <49BB6AD9.2020101@neilvandyke.org> (Emailing "plt-dev" for the smaller audience.) I think PLaneT is a big win, but I still have a little unease about security of making it so easy for untrusted parties to execute arbitrary code. Some off-the-cuff ideas: * Build degrees of code trust into the language, perhaps in parallel to PLT's contracts. So, for example, code in more-trusted module M that is influenced by code in less-trusted module L inherits the lowest trust level of all the influencing code. If there is a minimum trust level for the evaluation, no code with a lower trust level can be evaluated. Figuring out the semantics and then a usable implementation seems to me like a great research project, if it's not already been done. The semantics work might also yield new best-practices, like "don't export parameters from a module." * Sandboxes for untrusted code? * All PLaneT server traffic through SSL, using keys distributed with PLT, for discouraging a casual attackers from impersonating a PLaneT server, such as on an open WiFi AP. * Possibly require PLaneT packages to be signed, which would make it harder for an attacker to upload a new version of someone else's package. Drawback is that it's a hassle barrier to people uploading packages. * User interface whenever a new PLaneT package/version is about to be installed. It can inform what package is being installed, show whether it is by an author previously trusted by the user, show what code would be executed just by requiring it (before calling any of its definitions), give a chance to inspect all the code, show diffs since the last version, etc. * Have a means of "certifying" particular packages. So human editors could inspect new uploads of packages, inspect the code, and add their signature to the code to say that they noticed no problems. This is tricky from a liability standpoint. PLaneT users could specify that they only want to use PLaneT packages that have been certified. * A variation on "certifying" would be a mechanism for people to "flag" a particular package or version they see on PLaneT as having a security problem. That avoids a liability issue, though it only lets PLaneT users say "only use PLaneT packages that have not been flagged," rather than the more restrictive "only use PLaneT packages that have been certified." There could also be a mechanism for people to be informed when they've already installed PLaneT packages that have since been flagged. There would need to be a mechanism for removing flags, and awareness that the flag mechanism itself creates a denial-of-service vulnerability. Thanks, Neil From eli at barzilay.org Sun Mar 15 21:20:04 2009 From: eli at barzilay.org (Eli Barzilay) Date: Sun Mar 15 21:20:26 2009 Subject: [plt-dev] Release for v4.1.5 is about to begin Message-ID: The release process for v4.1.5 is about to begin. This means that the trunk is going to be copied into a branch -- please make sure that code that you're responsible for is as stable as possible, and let me know if there is any new work that should not be included in this release. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From eli at barzilay.org Sun Mar 15 21:21:31 2009 From: eli at barzilay.org (Eli Barzilay) Date: Sun Mar 15 21:21:52 2009 Subject: [plt-dev] Release for v4.1.5 is about to begin In-Reply-To: References: Message-ID: <18877.43419.235990.921716@winooski.ccs.neu.edu> On Mar 15, Eli Barzilay wrote: > The release process for v4.1.5 is about to begin. This means that > the trunk is going to be copied into a branch -- please make sure > that code that you're responsible for is as stable as possible, and > let me know if there is any new work that should not be included in > this release. Sorry -- please ignore this email, that was the reminder that I sent last week. Expect another message shortly about the release branch. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From eli at barzilay.org Sun Mar 15 21:32:06 2009 From: eli at barzilay.org (Eli Barzilay) Date: Sun Mar 15 21:32:27 2009 Subject: [plt-dev] Release for v4.1.5 has begun Message-ID: The release process for v4.1.5 has begun: the trunk was copied to a branch for any work that is left and is now bumped to v4.1.4.900. You can go on using the trunk as usual, it is now bumped to v4.1.5.1 (to avoid having two different trees with the same version). If you have any bug-fixes and changes that need to go in the release then make sure you specify that in the commit message or mail me the revision numbers. Do not try to commit anything on the pre-release branch (the server will forbid it). Note that nightly builds will go on as usual (as v4.1.5.1), and pre-release builds will be available at http://pre.plt-scheme.org/release/ -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From jay.mccarthy at gmail.com Mon Mar 16 16:17:33 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Mon Mar 16 16:17:57 2009 Subject: [plt-dev] struct-copy for objects Message-ID: Is there any way of making something like struct-copy for objects? It seems like object-info and class-info have the machinery, but I'm wondering if there's some fundamental reason it wouldn't work. I'd like to use the object system functionally without writing lots of boiler plate. Jay -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From matthias at ccs.neu.edu Mon Mar 16 16:21:19 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Mon Mar 16 16:23:23 2009 Subject: [plt-dev] struct-copy for objects In-Reply-To: References: Message-ID: <297FD4F2-0551-4A4A-B916-AFAD061612FE@ccs.neu.edu> Ah, I asked this question recently only to be reminded of my age by my grad students. How'd you copy private vars and methods? On Mar 16, 2009, at 4:17 PM, Jay McCarthy wrote: > Is there any way of making something like struct-copy for objects? > > It seems like object-info and class-info have the machinery, but I'm > wondering if there's some fundamental reason it wouldn't work. > > I'd like to use the object system functionally without writing lots of > boiler plate. > > Jay > > -- > Jay McCarthy > Assistant Professor / Brigham Young University > http://teammccarthy.org/jay > > "The glory of God is Intelligence" - D&C 93 > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From jay.mccarthy at gmail.com Mon Mar 16 16:33:13 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Mon Mar 16 16:33:36 2009 Subject: [plt-dev] struct-copy for objects In-Reply-To: <297FD4F2-0551-4A4A-B916-AFAD061612FE@ccs.neu.edu> References: <297FD4F2-0551-4A4A-B916-AFAD061612FE@ccs.neu.edu> Message-ID: Good point. I guess I'll deal for now. Two ideas: A syntax form that works with an interface (updateable<%>) that makes the class deal with this stuff. (A related note syntax transformers in the class system's interfaces might work analogous to the unit system's) A syntax form that is only legal inside the the class, so it can know what all the fields are. (Although this would probably break for a subclass's private fields.) Jay On Mon, Mar 16, 2009 at 2:21 PM, Matthias Felleisen wrote: > > Ah, I asked this question recently only to be reminded of my age by my grad > students. How'd you copy private vars and methods? > > > On Mar 16, 2009, at 4:17 PM, Jay McCarthy wrote: > >> Is there any way of making something like struct-copy for objects? >> >> It seems like object-info and class-info have the machinery, but I'm >> wondering if there's some fundamental reason it wouldn't work. >> >> I'd like to use the object system functionally without writing lots of >> boiler plate. >> >> Jay >> >> -- >> Jay McCarthy >> Assistant Professor / Brigham Young University >> http://teammccarthy.org/jay >> >> "The glory of God is Intelligence" - D&C 93 >> _________________________________________________ >> ?For list-related administrative tasks: >> ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > > -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From matthias at ccs.neu.edu Mon Mar 16 16:34:36 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Mon Mar 16 16:36:40 2009 Subject: [plt-dev] struct-copy for objects In-Reply-To: References: <297FD4F2-0551-4A4A-B916-AFAD061612FE@ccs.neu.edu> Message-ID: I tend to use something like choice 1 to approximate this thing when I need it (and I tend to need it when I push functional class-based programming during "hell" projects). -- Matthias On Mar 16, 2009, at 4:33 PM, Jay McCarthy wrote: > Good point. I guess I'll deal for now. > > Two ideas: > > A syntax form that works with an interface (updateable<%>) that makes > the class deal with this stuff. (A related note syntax transformers in > the class system's interfaces might work analogous to the unit > system's) > > A syntax form that is only legal inside the the class, so it can know > what all the fields are. (Although this would probably break for a > subclass's private fields.) > > Jay > > On Mon, Mar 16, 2009 at 2:21 PM, Matthias Felleisen > wrote: >> >> Ah, I asked this question recently only to be reminded of my age >> by my grad >> students. How'd you copy private vars and methods? >> >> >> On Mar 16, 2009, at 4:17 PM, Jay McCarthy wrote: >> >>> Is there any way of making something like struct-copy for objects? >>> >>> It seems like object-info and class-info have the machinery, but I'm >>> wondering if there's some fundamental reason it wouldn't work. >>> >>> I'd like to use the object system functionally without writing >>> lots of >>> boiler plate. >>> >>> Jay >>> >>> -- >>> Jay McCarthy >>> Assistant Professor / Brigham Young University >>> http://teammccarthy.org/jay >>> >>> "The glory of God is Intelligence" - D&C 93 >>> _________________________________________________ >>> For list-related administrative tasks: >>> http://list.cs.brown.edu/mailman/listinfo/plt-dev >> >> > > > > -- > Jay McCarthy > Assistant Professor / Brigham Young University > http://teammccarthy.org/jay > > "The glory of God is Intelligence" - D&C 93 From ryanc at ccs.neu.edu Mon Mar 16 17:08:27 2009 From: ryanc at ccs.neu.edu (Ryan Culpepper) Date: Mon Mar 16 17:08:58 2009 Subject: [plt-dev] struct-copy for objects In-Reply-To: References: <297FD4F2-0551-4A4A-B916-AFAD061612FE@ccs.neu.edu> Message-ID: Matthias and I worked on a macro solution to this problem (or something similar) a while ago. We didn't figure out The Right Way, but we might have something Good Enough for your purposes :) If you want, I can dig up and update the code and send it to you. Ryan On Mar 16, 2009, at 4:33 PM, Jay McCarthy wrote: > Good point. I guess I'll deal for now. > > Two ideas: > > A syntax form that works with an interface (updateable<%>) that makes > the class deal with this stuff. (A related note syntax transformers in > the class system's interfaces might work analogous to the unit > system's) > > A syntax form that is only legal inside the the class, so it can know > what all the fields are. (Although this would probably break for a > subclass's private fields.) > > Jay > > On Mon, Mar 16, 2009 at 2:21 PM, Matthias Felleisen > wrote: >> >> Ah, I asked this question recently only to be reminded of my age by >> my grad >> students. How'd you copy private vars and methods? >> >> >> On Mar 16, 2009, at 4:17 PM, Jay McCarthy wrote: >> >>> Is there any way of making something like struct-copy for objects? >>> >>> It seems like object-info and class-info have the machinery, but I'm >>> wondering if there's some fundamental reason it wouldn't work. >>> >>> I'd like to use the object system functionally without writing >>> lots of >>> boiler plate. >>> >>> Jay >>> >>> -- >>> Jay McCarthy >>> Assistant Professor / Brigham Young University >>> http://teammccarthy.org/jay >>> >>> "The glory of God is Intelligence" - D&C 93 >>> _________________________________________________ >>> For list-related administrative tasks: >>> http://list.cs.brown.edu/mailman/listinfo/plt-dev >> >> > > > > -- > Jay McCarthy > Assistant Professor / Brigham Young University > http://teammccarthy.org/jay > > "The glory of God is Intelligence" - D&C 93 > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From henk at henk.ca Mon Mar 16 17:29:39 2009 From: henk at henk.ca (Henk Boom) Date: Mon Mar 16 17:30:00 2009 Subject: [plt-dev] struct-copy for objects In-Reply-To: References: <297FD4F2-0551-4A4A-B916-AFAD061612FE@ccs.neu.edu> Message-ID: 2009/3/16 Jay McCarthy : > Good point. I guess I'll deal for now. > > Two ideas: > > A syntax form that works with an interface (updateable<%>) that makes > the class deal with this stuff. (A related note syntax transformers in > the class system's interfaces might work analogous to the unit > system's) > > A syntax form that is only legal inside the the class, so it can know > what all the fields are. (Although this would probably break for a > subclass's private fields.) I tried something a little over a year ago which introduced a new (data ...) form for data which should be copied from object to object. http://list.cs.brown.edu/pipermail/plt-scheme/2007-October/020851.html Henk From clements at brinckerhoff.org Mon Mar 16 17:29:50 2009 From: clements at brinckerhoff.org (John Clements) Date: Mon Mar 16 17:30:30 2009 Subject: [plt-dev] Re: [plt-bug] all/10133: set! sometimes doesn't work in interactions window In-Reply-To: <18878.49433.580717.685100@winooski.ccs.neu.edu> References: <200903162048.n2GKm19r006587@champlain.ccs.neu.edu> <18878.48541.643521.924568@winooski.ccs.neu.edu> <20090316210833.B5174650091@mail-svr1.cs.utah.edu> <18878.49433.580717.685100@winooski.ccs.neu.edu> Message-ID: <9D79799D-A5A5-4108-BE33-355D0D1B6080@brinckerhoff.org> On Mar 16, 2009, at 2:14 PM, Eli Barzilay wrote: > On Mar 16, Matthew Flatt wrote: >> See also >> >> http://docs.plt-scheme.org/guide/module-set.html >> >> We should work on getting documentation links into error messages. > > +1 What I'd really like to see is some kind of leverage using Google & web-fu. In particular, I'd like it to be possible for people to google for error messages and wind up at a page where they can contribute and read other peoples' suggested links and/or fixes. I know for a fact that my students google for error messages, and it seems like it would be possible for plt-scheme to host a web page where people could contribute helpful suggestions. Naturally, the biggest obstacle is probably keeping the spam down. Could use something like DSandler's water cooler... http://dsandler.org/wp/archives/2009/03/15/twitter-comments-results 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/20090316/967eb2bd/smime-0001.bin From eli at barzilay.org Mon Mar 16 19:34:17 2009 From: eli at barzilay.org (Eli Barzilay) Date: Mon Mar 16 19:34:38 2009 Subject: [plt-dev] Re: [plt-bug] all/10133: set! sometimes doesn't work in interactions window In-Reply-To: <9D79799D-A5A5-4108-BE33-355D0D1B6080@brinckerhoff.org> References: <200903162048.n2GKm19r006587@champlain.ccs.neu.edu> <18878.48541.643521.924568@winooski.ccs.neu.edu> <20090316210833.B5174650091@mail-svr1.cs.utah.edu> <18878.49433.580717.685100@winooski.ccs.neu.edu> <9D79799D-A5A5-4108-BE33-355D0D1B6080@brinckerhoff.org> Message-ID: <18878.57849.215374.980469@winooski.ccs.neu.edu> On Mar 16, John Clements wrote: > > On Mar 16, 2009, at 2:14 PM, Eli Barzilay wrote: > > > On Mar 16, Matthew Flatt wrote: > >> See also > >> > >> http://docs.plt-scheme.org/guide/module-set.html > >> > >> We should work on getting documentation links into error messages. > > > > +1 > > What I'd really like to see is some kind of leverage using Google & > web-fu. -2 (One for the google part, and another for my original contribution to it...) I think that relying on google for anything concrete is dangerous. It usually ends up with explaining why stuff doesn't work using some excuse of "it wasn't indexed yet", it is easy to get lost in a maze of redesigning links so that the "proper" links get more weight, etc. The danger in the first part is that by the time the content should have been indexed, enough time has passed for you to be far from the piece of documentation, which means a higher overhead to start editing it again -- and even if you do, there's a delay in getting to see the results. (IOW, the "debug-rerun" cycle has about two weeks between each step.) > In particular, I'd like it to be possible for people to google for > error messages and wind up at a page where they can contribute and > read other peoples' suggested links and/or fixes. I know for a fact > that my students google for error messages, [People will do it, and they usually know the kind of salt that needs to be applied. But to include it in DrScheme error message, for example, means that it's becoming an "official" way to know what errors mean.] > and it seems like it would be possible for plt-scheme to host a web > page where people could contribute helpful suggestions. This is (unrelated to the above) a good idea though. One of my original ideas for the documentation was to have wiki-style "edit" links which will go to a page that allows you to edit the source for that bit of documentation. Such edits can be send as patches to some place where someone can review and apply it. IIRC, there are some Gnome projects that do just this. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From matthias at ccs.neu.edu Mon Mar 16 20:30:42 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Mon Mar 16 20:31:40 2009 Subject: [plt-dev] request for typed library Message-ID: I'd like the textual part of htdp/testing to be turned into a typed library. If it is, is it checked in? -- Matthias From kathryn.gray at cl.cam.ac.uk Mon Mar 16 20:37:11 2009 From: kathryn.gray at cl.cam.ac.uk (Kathy Gray) Date: Mon Mar 16 20:53:17 2009 Subject: [plt-dev] request for typed library In-Reply-To: References: Message-ID: <1D2BDDB2-F1F7-4B47-9F3C-B98DB1471452@cl.cam.ac.uk> On 17 Mar 2009, at 12:30:42, Matthias Felleisen wrote: > > I'd like the textual part of htdp/testing to be turned into a typed > library. If it is, is it checked in? -- Matthias htdp/testing is deprecated and, as I keep saying, should disappear when there are no more requirements on it. The functions provided by htdp/testing are actually implemented by test-engine/scheme-tests.ss, which is what anyone using htdp/testing should be using now instead. I don't know if the implementation could be turned into a typed library. -Kathy From matthias at ccs.neu.edu Mon Mar 16 21:43:43 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Mon Mar 16 21:44:41 2009 Subject: [plt-dev] more requests for typed-scheme Message-ID: After a disasterous conversion attempt. We need: 1. local 2. empty?, first, second 3. make-list (srfi/1) (provide all base types for now): well, we really need a polymorphically typed srfi/1 4. list->string, string->list (base) 4. We need docs for primitives (say filter) and examples. 6. Is it really true that filters can be defined only via the (: ...) form (at the top level)? -- Matthias From jay.mccarthy at gmail.com Mon Mar 16 23:45:43 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Mon Mar 16 23:46:08 2009 Subject: [plt-dev] ParenQuest Message-ID: You might enjoy playing ParenQuest for a few moments. wget faculty.cs.byu.edu/~jay/tmp/rl.tar.gz tar xzvf rl.tar.gz mred -t rl/ui-world.ss Use the numpad or the arrow keys or VI keys to move around. Press "," to pick up a parenthesis (Make sure you don't misbalance or pick up the wrong color at the wrong time) Look for an error message on the console if you win/lose Jay -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From henk at henk.ca Mon Mar 16 23:50:57 2009 From: henk at henk.ca (Henk Boom) Date: Mon Mar 16 23:51:16 2009 Subject: [plt-dev] ParenQuest In-Reply-To: References: Message-ID: 2009/3/16 Jay McCarthy : > You might enjoy playing ParenQuest for a few moments. > > wget faculty.cs.byu.edu/~jay/tmp/rl.tar.gz > tar xzvf rl.tar.gz > mred -t rl/ui-world.ss > > Use the numpad or the arrow keys or VI keys to move around. > Press "," to pick up a parenthesis > (Make sure you don't misbalance or pick up the wrong color at the wrong time) > > Look for an error message on the console if you win/lose I got an error message instead of a game =(. What version does it run on? henk@korhal ~/tmp $ mred -t rl/ui-world.ss rl/text-world/text-world-sig.ss:10:4: define-signature: unknown signature form at: contracted in: (define-signature text-world^ ((contracted (scene? (-> any/c boolean?)) (empty-scene (-> exact-positive-integer? exact-positive-integer? scene?)) (image? (-> any/c boolean?)) (place-image (-> image? exact-nonnegative-integer? exact-nonnegative-integer? ... === context === try-next /usr/lib/plt/collects/scheme/private/modbeg.ss:44:4 Henk From rafkind at cs.utah.edu Mon Mar 16 23:57:53 2009 From: rafkind at cs.utah.edu (Jon Rafkind) Date: Mon Mar 16 23:58:19 2009 Subject: [plt-dev] ParenQuest In-Reply-To: References: Message-ID: <49BF1FC1.9000505@cs.utah.edu> Henk Boom wrote: > 2009/3/16 Jay McCarthy : > >> You might enjoy playing ParenQuest for a few moments. >> >> wget faculty.cs.byu.edu/~jay/tmp/rl.tar.gz >> tar xzvf rl.tar.gz >> mred -t rl/ui-world.ss >> >> Use the numpad or the arrow keys or VI keys to move around. >> Press "," to pick up a parenthesis >> (Make sure you don't misbalance or pick up the wrong color at the wrong time) >> >> Look for an error message on the console if you win/lose >> > > I got an error message instead of a game =(. What version does it run on? > > henk@korhal ~/tmp $ mred -t rl/ui-world.ss > rl/text-world/text-world-sig.ss:10:4: define-signature: unknown > signature form at: contracted in: (define-signature text-world^ > ((contracted (scene? (-> any/c boolean?)) (empty-scene (-> > exact-positive-integer? exact-positive-integer? scene?)) (image? (-> > any/c boolean?)) (place-image (-> image? exact-nonnegative-integer? > exact-nonnegative-integer? ... > > === context === > try-next > /usr/lib/plt/collects/scheme/private/modbeg.ss:44:4 > > I got a different error: cadr: expects argument of type ; given #f === context === /home/jon/svn/plt/collects/2htdp/universe.ss:154:23 /home/jon/svn/plt/collects/scheme/private/map.ss:22:17: loop /home/jon/svn/plt/collects/2htdp/universe.ss:132:0 $ mzscheme -v Welcome to MzScheme v4.1.4.3 [3m], Copyright (c) 2004-2009 PLT Scheme Inc. From samth at ccs.neu.edu Mon Mar 16 23:59:02 2009 From: samth at ccs.neu.edu (Sam TH) Date: Mon Mar 16 23:59:20 2009 Subject: [plt-dev] Re: more requests for typed-scheme In-Reply-To: References: Message-ID: <63bb19ae0903162059w7ffb67fbxa46c3f6cf10cafb6@mail.gmail.com> On Mon, Mar 16, 2009 at 9:43 PM, Matthias Felleisen wrote: > After a disasterous conversion attempt. > > We need: > > 1. local Available from scheme/local > 2. empty?, first, second Available from scheme/list > 3. make-list (srfi/1) (provide all base types for now): well, we really need > a polymorphically typed srfi/1 We can't do this without contracts for polymorphic functions. > 4. list->string, string->list (base) Fixed in SVN. > 4. We need docs for primitives (say filter) and examples. Is this just `filter' (which has special behavior in Typed Scheme) or all of the primitives? > 6. Is it really true that filters can be defined only via the (: ...) form > (at the top level)? I don't understand what you're asking here. The simple answer is no, this should work fine: #lang typed-scheme (let () (: f (Any -> Boolean : Number)) (define (f x) (number? x)) (f 3)) -- sam th samth@ccs.neu.edu From samth at ccs.neu.edu Tue Mar 17 00:02:00 2009 From: samth at ccs.neu.edu (Sam TH) Date: Tue Mar 17 00:05:27 2009 Subject: [plt-dev] request for typed library In-Reply-To: <1D2BDDB2-F1F7-4B47-9F3C-B98DB1471452@cl.cam.ac.uk> References: <1D2BDDB2-F1F7-4B47-9F3C-B98DB1471452@cl.cam.ac.uk> Message-ID: <63bb19ae0903162102q13a231a5gf3ecd8094c44164d@mail.gmail.com> On Mon, Mar 16, 2009 at 8:37 PM, Kathy Gray wrote: > On 17 Mar 2009, at 12:30:42, Matthias Felleisen wrote: > >> >> I'd like the textual part of htdp/testing to be turned into a typed >> library. If it is, is it checked in? -- Matthias > > htdp/testing is deprecated and, as I keep saying, should disappear when > there are no more requirements on it. > > The functions provided by htdp/testing are actually implemented by > test-engine/scheme-tests.ss, which is what anyone using htdp/testing should > be using now instead. I don't know if the implementation could be turned > into a typed library. Is there a plan for a library to be used by programs that aren't written in the teaching languages? `check-expect' is nicely lightweight, but it's hard to recommend its use when it has no non-teaching-language documentation or module. I think the last time I looked, it wouldn't be too hard to make a typed version. -- sam th samth@ccs.neu.edu From jay.mccarthy at gmail.com Tue Mar 17 00:04:17 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Tue Mar 17 00:09:26 2009 Subject: [plt-dev] ParenQuest In-Reply-To: References: Message-ID: That error is from the new contracts in the unit system. That came out in SVN about three weeks ago. You could wait until the release soon or try a nightly build... Jay On Mon, Mar 16, 2009 at 9:50 PM, Henk Boom wrote: > 2009/3/16 Jay McCarthy : >> You might enjoy playing ParenQuest for a few moments. >> >> wget faculty.cs.byu.edu/~jay/tmp/rl.tar.gz >> tar xzvf rl.tar.gz >> mred -t rl/ui-world.ss >> >> Use the numpad or the arrow keys or VI keys to move around. >> Press "," to pick up a parenthesis >> (Make sure you don't misbalance or pick up the wrong color at the wrong time) >> >> Look for an error message on the console if you win/lose > > I got an error message instead of a game =(. What version does it run on? > > henk@korhal ~/tmp $ mred -t rl/ui-world.ss > rl/text-world/text-world-sig.ss:10:4: define-signature: unknown > signature form at: contracted in: (define-signature text-world^ > ((contracted (scene? (-> any/c boolean?)) (empty-scene (-> > exact-positive-integer? exact-positive-integer? scene?)) (image? (-> > any/c boolean?)) (place-image (-> image? exact-nonnegative-integer? > exact-nonnegative-integer? ... > > ?=== context === > try-next > /usr/lib/plt/collects/scheme/private/modbeg.ss:44:4 > > ? ?Henk > -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From jay.mccarthy at gmail.com Tue Mar 17 00:05:36 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Tue Mar 17 00:10:12 2009 Subject: [plt-dev] ParenQuest In-Reply-To: <49BF1FC1.9000505@cs.utah.edu> References: <49BF1FC1.9000505@cs.utah.edu> Message-ID: That's PR 10129. Fixed in SVN as of this morning I believe. I sent it to plt-dev for a reason... people who like to bleed on the edge like me ;) Jay On Mon, Mar 16, 2009 at 9:57 PM, Jon Rafkind wrote: > Henk Boom wrote: >> >> 2009/3/16 Jay McCarthy : >> >>> >>> You might enjoy playing ParenQuest for a few moments. >>> >>> wget faculty.cs.byu.edu/~jay/tmp/rl.tar.gz >>> tar xzvf rl.tar.gz >>> mred -t rl/ui-world.ss >>> >>> Use the numpad or the arrow keys or VI keys to move around. >>> Press "," to pick up a parenthesis >>> (Make sure you don't misbalance or pick up the wrong color at the wrong >>> time) >>> >>> Look for an error message on the console if you win/lose >>> >> >> I got an error message instead of a game =(. What version does it run on? >> >> henk@korhal ~/tmp $ mred -t rl/ui-world.ss >> rl/text-world/text-world-sig.ss:10:4: define-signature: unknown >> signature form at: contracted in: (define-signature text-world^ >> ((contracted (scene? (-> any/c boolean?)) (empty-scene (-> >> exact-positive-integer? exact-positive-integer? scene?)) (image? (-> >> any/c boolean?)) (place-image (-> image? exact-nonnegative-integer? >> exact-nonnegative-integer? ... >> >> ?=== context === >> try-next >> /usr/lib/plt/collects/scheme/private/modbeg.ss:44:4 >> >> > > I got a different error: > cadr: expects argument of type ; given #f > > === context === > /home/jon/svn/plt/collects/2htdp/universe.ss:154:23 > /home/jon/svn/plt/collects/scheme/private/map.ss:22:17: loop > /home/jon/svn/plt/collects/2htdp/universe.ss:132:0 > > $ mzscheme -v > Welcome to MzScheme v4.1.4.3 [3m], Copyright (c) 2004-2009 PLT Scheme Inc. > -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From robby at eecs.northwestern.edu Tue Mar 17 07:55:40 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Tue Mar 17 07:56:02 2009 Subject: [plt-dev] ParenQuest In-Reply-To: References: <49BF1FC1.9000505@cs.utah.edu> Message-ID: <932b2f1f0903170455y575eb934h5e9947dea3eedf5b@mail.gmail.com> I bonk'd my head! But I seem to be stuck -- is it possible the maze generation doesn't actually connect everything? (I might have just not walked in the right place, possibly ...) Robby On Mon, Mar 16, 2009 at 11:05 PM, Jay McCarthy wrote: > That's PR 10129. Fixed in SVN as of this morning I believe. > > I sent it to plt-dev for a reason... people who like to bleed on the > edge like me ;) > > Jay > > On Mon, Mar 16, 2009 at 9:57 PM, Jon Rafkind wrote: >> Henk Boom wrote: >>> >>> 2009/3/16 Jay McCarthy : >>> >>>> >>>> You might enjoy playing ParenQuest for a few moments. >>>> >>>> wget faculty.cs.byu.edu/~jay/tmp/rl.tar.gz >>>> tar xzvf rl.tar.gz >>>> mred -t rl/ui-world.ss >>>> >>>> Use the numpad or the arrow keys or VI keys to move around. >>>> Press "," to pick up a parenthesis >>>> (Make sure you don't misbalance or pick up the wrong color at the wrong >>>> time) >>>> >>>> Look for an error message on the console if you win/lose >>>> >>> >>> I got an error message instead of a game =(. What version does it run on? >>> >>> henk@korhal ~/tmp $ mred -t rl/ui-world.ss >>> rl/text-world/text-world-sig.ss:10:4: define-signature: unknown >>> signature form at: contracted in: (define-signature text-world^ >>> ((contracted (scene? (-> any/c boolean?)) (empty-scene (-> >>> exact-positive-integer? exact-positive-integer? scene?)) (image? (-> >>> any/c boolean?)) (place-image (-> image? exact-nonnegative-integer? >>> exact-nonnegative-integer? ... >>> >>> ?=== context === >>> try-next >>> /usr/lib/plt/collects/scheme/private/modbeg.ss:44:4 >>> >>> >> >> I got a different error: >> cadr: expects argument of type ; given #f >> >> === context === >> /home/jon/svn/plt/collects/2htdp/universe.ss:154:23 >> /home/jon/svn/plt/collects/scheme/private/map.ss:22:17: loop >> /home/jon/svn/plt/collects/2htdp/universe.ss:132:0 >> >> $ mzscheme -v >> Welcome to MzScheme v4.1.4.3 [3m], Copyright (c) 2004-2009 PLT Scheme Inc. >> > > > > -- > Jay McCarthy > Assistant Professor / Brigham Young University > http://teammccarthy.org/jay > > "The glory of God is Intelligence" - D&C 93 > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > From jay.mccarthy at gmail.com Tue Mar 17 08:06:17 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Tue Mar 17 08:06:38 2009 Subject: [plt-dev] ParenQuest In-Reply-To: <932b2f1f0903170455y575eb934h5e9947dea3eedf5b@mail.gmail.com> References: <49BF1FC1.9000505@cs.utah.edu> <932b2f1f0903170455y575eb934h5e9947dea3eedf5b@mail.gmail.com> Message-ID: The maze algorithm always generates connected mazes. You can move diagonal with y for upper left, u for upper right, b for lower left, and n for lower right. (You can also use the appropriate keys of the number pad.) :) Jay On Tue, Mar 17, 2009 at 5:55 AM, Robby Findler wrote: > I bonk'd my head! > > But I seem to be stuck -- is it possible the maze generation doesn't > actually connect everything? (I might have just not walked in the > right place, possibly ...) > > Robby > > On Mon, Mar 16, 2009 at 11:05 PM, Jay McCarthy wrote: >> That's PR 10129. Fixed in SVN as of this morning I believe. >> >> I sent it to plt-dev for a reason... people who like to bleed on the >> edge like me ;) >> >> Jay >> >> On Mon, Mar 16, 2009 at 9:57 PM, Jon Rafkind wrote: >>> Henk Boom wrote: >>>> >>>> 2009/3/16 Jay McCarthy : >>>> >>>>> >>>>> You might enjoy playing ParenQuest for a few moments. >>>>> >>>>> wget faculty.cs.byu.edu/~jay/tmp/rl.tar.gz >>>>> tar xzvf rl.tar.gz >>>>> mred -t rl/ui-world.ss >>>>> >>>>> Use the numpad or the arrow keys or VI keys to move around. >>>>> Press "," to pick up a parenthesis >>>>> (Make sure you don't misbalance or pick up the wrong color at the wrong >>>>> time) >>>>> >>>>> Look for an error message on the console if you win/lose >>>>> >>>> >>>> I got an error message instead of a game =(. What version does it run on? >>>> >>>> henk@korhal ~/tmp $ mred -t rl/ui-world.ss >>>> rl/text-world/text-world-sig.ss:10:4: define-signature: unknown >>>> signature form at: contracted in: (define-signature text-world^ >>>> ((contracted (scene? (-> any/c boolean?)) (empty-scene (-> >>>> exact-positive-integer? exact-positive-integer? scene?)) (image? (-> >>>> any/c boolean?)) (place-image (-> image? exact-nonnegative-integer? >>>> exact-nonnegative-integer? ... >>>> >>>> ?=== context === >>>> try-next >>>> /usr/lib/plt/collects/scheme/private/modbeg.ss:44:4 >>>> >>>> >>> >>> I got a different error: >>> cadr: expects argument of type ; given #f >>> >>> === context === >>> /home/jon/svn/plt/collects/2htdp/universe.ss:154:23 >>> /home/jon/svn/plt/collects/scheme/private/map.ss:22:17: loop >>> /home/jon/svn/plt/collects/2htdp/universe.ss:132:0 >>> >>> $ mzscheme -v >>> Welcome to MzScheme v4.1.4.3 [3m], Copyright (c) 2004-2009 PLT Scheme Inc. >>> >> >> >> >> -- >> Jay McCarthy >> Assistant Professor / Brigham Young University >> http://teammccarthy.org/jay >> >> "The glory of God is Intelligence" - D&C 93 >> _________________________________________________ >> ?For list-related administrative tasks: >> ?http://list.cs.brown.edu/mailman/listinfo/plt-dev >> > -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From matthias at ccs.neu.edu Tue Mar 17 08:38:43 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Tue Mar 17 08:39:33 2009 Subject: [plt-dev] Re: more requests for typed-scheme In-Reply-To: <63bb19ae0903162059w7ffb67fbxa46c3f6cf10cafb6@mail.gmail.com> References: <63bb19ae0903162059w7ffb67fbxa46c3f6cf10cafb6@mail.gmail.com> Message-ID: On Mar 16, 2009, at 11:59 PM, Sam TH wrote: > >> 3. make-list (srfi/1) (provide all base types for now): well, we >> really need >> a polymorphically typed srfi/1 > > We can't do this without contracts for polymorphic functions. In the meantime, let's port the whole library to Typed Scheme. It's too useful not to be around. From matthias at ccs.neu.edu Tue Mar 17 08:39:51 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Tue Mar 17 08:41:19 2009 Subject: [plt-dev] request for typed library In-Reply-To: <63bb19ae0903162102q13a231a5gf3ecd8094c44164d@mail.gmail.com> References: <1D2BDDB2-F1F7-4B47-9F3C-B98DB1471452@cl.cam.ac.uk> <63bb19ae0903162102q13a231a5gf3ecd8094c44164d@mail.gmail.com> Message-ID: We need one of three things: -- Kathy's test engine -- SchemeUnit -- Eli's test-->>>>#$%^^&*& in Typed Scheme. Tests are indispensable, no matter how many types you have in a program -- Matthias On Mar 17, 2009, at 12:02 AM, Sam TH wrote: > On Mon, Mar 16, 2009 at 8:37 PM, Kathy Gray > wrote: >> On 17 Mar 2009, at 12:30:42, Matthias Felleisen wrote: >> >>> >>> I'd like the textual part of htdp/testing to be turned into a typed >>> library. If it is, is it checked in? -- Matthias >> >> htdp/testing is deprecated and, as I keep saying, should disappear >> when >> there are no more requirements on it. >> >> The functions provided by htdp/testing are actually implemented by >> test-engine/scheme-tests.ss, which is what anyone using htdp/ >> testing should >> be using now instead. I don't know if the implementation could be >> turned >> into a typed library. > > Is there a plan for a library to be used by programs that aren't > written in the teaching languages? `check-expect' is nicely > lightweight, but it's hard to recommend its use when it has no > non-teaching-language documentation or module. > > I think the last time I looked, it wouldn't be too hard to make a > typed version. > > -- > sam th > samth@ccs.neu.edu From eli at barzilay.org Tue Mar 17 08:44:02 2009 From: eli at barzilay.org (Eli Barzilay) Date: Tue Mar 17 08:44:25 2009 Subject: [plt-dev] request for typed library In-Reply-To: References: <1D2BDDB2-F1F7-4B47-9F3C-B98DB1471452@cl.cam.ac.uk> <63bb19ae0903162102q13a231a5gf3ecd8094c44164d@mail.gmail.com> Message-ID: <18879.39698.70599.43358@winooski.ccs.neu.edu> On Mar 17, Matthias Felleisen wrote: > > We need one of three things: > > -- Kathy's test engine > -- SchemeUnit > -- Eli's test-->>>>#$%^^&*& > > in Typed Scheme. Tests are indispensable, no matter how many types > you have in a program -- Matthias "My" tests (the CSU660 version) work almost trivially in TS, but that's by declaring a type for the few functions involved. It should be fine to do it "for real" though, since it only relies on functions that are being called to throw an error or not. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From samth at ccs.neu.edu Tue Mar 17 08:48:27 2009 From: samth at ccs.neu.edu (Sam TH) Date: Tue Mar 17 08:48:45 2009 Subject: [plt-dev] request for typed library In-Reply-To: References: <1D2BDDB2-F1F7-4B47-9F3C-B98DB1471452@cl.cam.ac.uk> <63bb19ae0903162102q13a231a5gf3ecd8094c44164d@mail.gmail.com> Message-ID: <63bb19ae0903170548l53aa0fabnb636869eaccb01f5@mail.gmail.com> On Tue, Mar 17, 2009 at 8:39 AM, Matthias Felleisen wrote: > > We need one of three things: > > ?-- Kathy's test engine > ?-- SchemeUnit > ?-- Eli's test-->>>>#$%^^&*& > > in Typed Scheme. Tests are indispensable, no matter how many types you have > in a program -- Matthias I agree, but since PLT doesn't seem to be able to choose what to do about testing, I haven't tried to pick. Perhaps this should be on the agenda for the next meeting. -- sam th samth@ccs.neu.edu From samth at ccs.neu.edu Tue Mar 17 08:50:01 2009 From: samth at ccs.neu.edu (Sam TH) Date: Tue Mar 17 08:50:36 2009 Subject: [plt-dev] Re: more requests for typed-scheme In-Reply-To: References: <63bb19ae0903162059w7ffb67fbxa46c3f6cf10cafb6@mail.gmail.com> Message-ID: <63bb19ae0903170550g64018bb8v278005f2a91c7c02@mail.gmail.com> On Tue, Mar 17, 2009 at 8:38 AM, Matthias Felleisen wrote: > > On Mar 16, 2009, at 11:59 PM, Sam TH wrote: > >> >>> 3. make-list (srfi/1) (provide all base types for now): well, we really >>> need >>> a polymorphically typed srfi/1 >> >> We can't do this without contracts for polymorphic functions. > > > In the meantime, let's port the whole library to Typed Scheme. It's too > useful not to be around. I thought the idea was that anything that anything from SRFI 1 that multiple people find useful should go in `scheme/list'. As I recall, I advocated for putting everything there, so anything you find useful automatically has enough votes. :) -- sam th samth@ccs.neu.edu From dvanhorn at ccs.neu.edu Tue Mar 17 08:50:10 2009 From: dvanhorn at ccs.neu.edu (David Van Horn) Date: Tue Mar 17 08:50:40 2009 Subject: [plt-dev] request for typed library In-Reply-To: References: <1D2BDDB2-F1F7-4B47-9F3C-B98DB1471452@cl.cam.ac.uk> <63bb19ae0903162102q13a231a5gf3ecd8094c44164d@mail.gmail.com> Message-ID: <49BF9C82.8050300@ccs.neu.edu> Matthias Felleisen wrote: > > We need one of three things: > > -- Kathy's test engine > -- SchemeUnit > -- Eli's test-->>>>#$%^^&*& > > in Typed Scheme. Tests are indispensable, no matter how many types you > have in a program -- Matthias check-expect ought to be low hanging fruit. I tried doing it when I was working on Typed Student, but couldn't get things working. You just want to tell TS that the check-expect form takes two subforms of type Any. Since check-expect can only appear at the top-level it's return type is not important. But since check-expect is a macro, the expanded code has to be well-typed. Maybe one implementation strategy is have a functional check expect, check-expectf, typed:check-expect expands into that and check-expectf is wrapped with the contract Any Any -> Void. This would go a long way for me. David From robby at eecs.northwestern.edu Tue Mar 17 08:51:47 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Tue Mar 17 08:52:10 2009 Subject: [plt-dev] ParenQuest In-Reply-To: References: <49BF1FC1.9000505@cs.utah.edu> <932b2f1f0903170455y575eb934h5e9947dea3eedf5b@mail.gmail.com> Message-ID: <932b2f1f0903170551x3247309ep1737190a76e02944@mail.gmail.com> Yeah I got stuck a couple of times just not exploring some corner somewhere that was the only connection out of the region I was in. Probably that happened again and I just couldn't find the corner. Robby On 3/17/09, Jay McCarthy wrote: > The maze algorithm always generates connected mazes. > > You can move diagonal with y for upper left, u for upper right, b for > lower left, and n for lower right. (You can also use the appropriate > keys of the number pad.) > > :) > > Jay > > On Tue, Mar 17, 2009 at 5:55 AM, Robby Findler > wrote: >> I bonk'd my head! >> >> But I seem to be stuck -- is it possible the maze generation doesn't >> actually connect everything? (I might have just not walked in the >> right place, possibly ...) >> >> Robby >> >> On Mon, Mar 16, 2009 at 11:05 PM, Jay McCarthy >> wrote: >>> That's PR 10129. Fixed in SVN as of this morning I believe. >>> >>> I sent it to plt-dev for a reason... people who like to bleed on the >>> edge like me ;) >>> >>> Jay >>> >>> On Mon, Mar 16, 2009 at 9:57 PM, Jon Rafkind wrote: >>>> Henk Boom wrote: >>>>> >>>>> 2009/3/16 Jay McCarthy : >>>>> >>>>>> >>>>>> You might enjoy playing ParenQuest for a few moments. >>>>>> >>>>>> wget faculty.cs.byu.edu/~jay/tmp/rl.tar.gz >>>>>> tar xzvf rl.tar.gz >>>>>> mred -t rl/ui-world.ss >>>>>> >>>>>> Use the numpad or the arrow keys or VI keys to move around. >>>>>> Press "," to pick up a parenthesis >>>>>> (Make sure you don't misbalance or pick up the wrong color at the >>>>>> wrong >>>>>> time) >>>>>> >>>>>> Look for an error message on the console if you win/lose >>>>>> >>>>> >>>>> I got an error message instead of a game =(. What version does it run >>>>> on? >>>>> >>>>> henk@korhal ~/tmp $ mred -t rl/ui-world.ss >>>>> rl/text-world/text-world-sig.ss:10:4: define-signature: unknown >>>>> signature form at: contracted in: (define-signature text-world^ >>>>> ((contracted (scene? (-> any/c boolean?)) (empty-scene (-> >>>>> exact-positive-integer? exact-positive-integer? scene?)) (image? (-> >>>>> any/c boolean?)) (place-image (-> image? exact-nonnegative-integer? >>>>> exact-nonnegative-integer? ... >>>>> >>>>> === context === >>>>> try-next >>>>> /usr/lib/plt/collects/scheme/private/modbeg.ss:44:4 >>>>> >>>>> >>>> >>>> I got a different error: >>>> cadr: expects argument of type ; given #f >>>> >>>> === context === >>>> /home/jon/svn/plt/collects/2htdp/universe.ss:154:23 >>>> /home/jon/svn/plt/collects/scheme/private/map.ss:22:17: loop >>>> /home/jon/svn/plt/collects/2htdp/universe.ss:132:0 >>>> >>>> $ mzscheme -v >>>> Welcome to MzScheme v4.1.4.3 [3m], Copyright (c) 2004-2009 PLT Scheme >>>> Inc. >>>> >>> >>> >>> >>> -- >>> Jay McCarthy >>> Assistant Professor / Brigham Young University >>> http://teammccarthy.org/jay >>> >>> "The glory of God is Intelligence" - D&C 93 >>> _________________________________________________ >>> For list-related administrative tasks: >>> http://list.cs.brown.edu/mailman/listinfo/plt-dev >>> >> > > > > -- > Jay McCarthy > Assistant Professor / Brigham Young University > http://teammccarthy.org/jay > > "The glory of God is Intelligence" - D&C 93 > From matthias at ccs.neu.edu Tue Mar 17 08:52:55 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Tue Mar 17 08:53:46 2009 Subject: [plt-dev] Re: more requests for typed-scheme In-Reply-To: <63bb19ae0903170550g64018bb8v278005f2a91c7c02@mail.gmail.com> References: <63bb19ae0903162059w7ffb67fbxa46c3f6cf10cafb6@mail.gmail.com> <63bb19ae0903170550g64018bb8v278005f2a91c7c02@mail.gmail.com> Message-ID: Everyone, please find things you find useful in srfi/1 :-) On Mar 17, 2009, at 8:50 AM, Sam TH wrote: > On Tue, Mar 17, 2009 at 8:38 AM, Matthias Felleisen > wrote: >> >> On Mar 16, 2009, at 11:59 PM, Sam TH wrote: >> >>> >>>> 3. make-list (srfi/1) (provide all base types for now): well, we >>>> really >>>> need >>>> a polymorphically typed srfi/1 >>> >>> We can't do this without contracts for polymorphic functions. >> >> >> In the meantime, let's port the whole library to Typed Scheme. >> It's too >> useful not to be around. > > I thought the idea was that anything that anything from SRFI 1 that > multiple people find useful should go in `scheme/list'. As I recall, > I advocated for putting everything there, so anything you find useful > automatically has enough votes. :) > > -- > sam th > samth@ccs.neu.edu From kathryn.gray at cl.cam.ac.uk Tue Mar 17 08:58:19 2009 From: kathryn.gray at cl.cam.ac.uk (Kathryn Gray) Date: Tue Mar 17 08:58:57 2009 Subject: [plt-dev] request for typed library In-Reply-To: <63bb19ae0903162102q13a231a5gf3ecd8094c44164d@mail.gmail.com> References: <1D2BDDB2-F1F7-4B47-9F3C-B98DB1471452@cl.cam.ac.uk> <63bb19ae0903162102q13a231a5gf3ecd8094c44164d@mail.gmail.com> Message-ID: <439BADC5-D9EF-46D3-A6D2-24DB4630D61C@cl.cam.ac.uk> On 17 Mar 2009, at 4:02:00, Sam TH wrote: > On Mon, Mar 16, 2009 at 8:37 PM, Kathy Gray > wrote: >> On 17 Mar 2009, at 12:30:42, Matthias Felleisen wrote: >> >>> >>> I'd like the textual part of htdp/testing to be turned into a typed >>> library. If it is, is it checked in? -- Matthias >> >> htdp/testing is deprecated and, as I keep saying, should disappear >> when >> there are no more requirements on it. >> >> The functions provided by htdp/testing are actually implemented by >> test-engine/scheme-tests.ss, which is what anyone using htdp/ >> testing should >> be using now instead. I don't know if the implementation could be >> turned >> into a typed library. > > Is there a plan for a library to be used by programs that aren't > written in the teaching languages? `check-expect' is nicely > lightweight, but it's hard to recommend its use when it has no > non-teaching-language documentation or module. The test-engine/scheme-tests.ss can be used as a library by programs that aren't written in the teaching language currently; the test results from this library appear in print statements instead of a window in DrScheme. Documentation is coming. -Kathy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090317/80051421/attachment-0001.html From dvanhorn at ccs.neu.edu Tue Mar 17 08:58:20 2009 From: dvanhorn at ccs.neu.edu (David Van Horn) Date: Tue Mar 17 08:59:02 2009 Subject: [plt-dev] request for typed library In-Reply-To: <1D2BDDB2-F1F7-4B47-9F3C-B98DB1471452@cl.cam.ac.uk> References: <1D2BDDB2-F1F7-4B47-9F3C-B98DB1471452@cl.cam.ac.uk> Message-ID: <49BF9E6C.8040505@ccs.neu.edu> Kathy Gray wrote: > On 17 Mar 2009, at 12:30:42, Matthias Felleisen wrote: > >> >> I'd like the textual part of htdp/testing to be turned into a typed >> library. If it is, is it checked in? -- Matthias > > htdp/testing is deprecated and, as I keep saying, should disappear when > there are no more requirements on it. I find htdp/testing quite useful for lightweight testing and simple porting of Student programs to Scheme. If it goes away, something as easy to use should replace it. Which I guess prompts the question: why have it go away at all? David From matthias at ccs.neu.edu Tue Mar 17 09:53:33 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Tue Mar 17 09:55:20 2009 Subject: [plt-dev] request for typed library In-Reply-To: <439BADC5-D9EF-46D3-A6D2-24DB4630D61C@cl.cam.ac.uk> References: <1D2BDDB2-F1F7-4B47-9F3C-B98DB1471452@cl.cam.ac.uk> <63bb19ae0903162102q13a231a5gf3ecd8094c44164d@mail.gmail.com> <439BADC5-D9EF-46D3-A6D2-24DB4630D61C@cl.cam.ac.uk> Message-ID: On Mar 17, 2009, at 8:58 AM, Kathryn Gray wrote: > The test-engine/scheme-tests.ss can be used as a library by > programs that aren't written in the teaching language currently; > the test results from this library appear in print statements > instead of a window in DrScheme. So does htdp/testing ... (test) . Why are we deprecating htdp/testing again? From kathryn.gray at cl.cam.ac.uk Tue Mar 17 10:16:27 2009 From: kathryn.gray at cl.cam.ac.uk (Kathryn Gray) Date: Tue Mar 17 10:16:31 2009 Subject: [plt-dev] request for typed library In-Reply-To: References: <1D2BDDB2-F1F7-4B47-9F3C-B98DB1471452@cl.cam.ac.uk> <63bb19ae0903162102q13a231a5gf3ecd8094c44164d@mail.gmail.com> <439BADC5-D9EF-46D3-A6D2-24DB4630D61C@cl.cam.ac.uk> Message-ID: On 17 Mar 2009, at 1:53:33, Matthias Felleisen wrote: > > On Mar 17, 2009, at 8:58 AM, Kathryn Gray wrote: > >> The test-engine/scheme-tests.ss can be used as a library by >> programs that aren't written in the teaching language currently; >> the test results from this library appear in print statements >> instead of a window in DrScheme. > > So does htdp/testing ... (test) . Why are we deprecating htdp/ > testing again? The functionality doesn't need to (and isn't) going away. All htdp/testing does is reexport items from the other library, but unlike test-engine/scheme-tests it can easily be added by students as a teach pack. If a student does this, and then calls (test) manually; all of their test results appear twice. Why is this a desirable behavior to have? Why should we be letting students add this as a teach pack? -Kathy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090317/1903ccb5/attachment.htm From carl.eastlund at gmail.com Tue Mar 17 10:14:49 2009 From: carl.eastlund at gmail.com (Carl Eastlund) Date: Tue Mar 17 10:21:52 2009 Subject: [plt-dev] request for typed library In-Reply-To: References: <1D2BDDB2-F1F7-4B47-9F3C-B98DB1471452@cl.cam.ac.uk> <63bb19ae0903162102q13a231a5gf3ecd8094c44164d@mail.gmail.com> <439BADC5-D9EF-46D3-A6D2-24DB4630D61C@cl.cam.ac.uk> Message-ID: <990e0c030903170714s7906e52bj464fdecaa1b545a4@mail.gmail.com> On Tue, Mar 17, 2009 at 9:53 AM, Matthias Felleisen wrote: > > On Mar 17, 2009, at 8:58 AM, Kathryn Gray wrote: > >> The test-engine/scheme-tests.ss can be used as a library by programs that >> aren't written in the teaching language currently; the test results from >> this library appear in print statements instead of a window in DrScheme. > > So does htdp/testing ... (test) . Why are we deprecating htdp/testing > again?_________________________________________________ If we have a new and an old implementation, why wouldn't we? Why insist on maintaining two versions of something? -- Carl Eastlund From matthias at ccs.neu.edu Tue Mar 17 10:52:49 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Tue Mar 17 10:54:35 2009 Subject: [plt-dev] request for typed library In-Reply-To: References: <1D2BDDB2-F1F7-4B47-9F3C-B98DB1471452@cl.cam.ac.uk> <63bb19ae0903162102q13a231a5gf3ecd8094c44164d@mail.gmail.com> <439BADC5-D9EF-46D3-A6D2-24DB4630D61C@cl.cam.ac.uk> Message-ID: On Mar 17, 2009, at 10:16 AM, Kathryn Gray wrote: > > On 17 Mar 2009, at 1:53:33, Matthias Felleisen wrote: > >> >> On Mar 17, 2009, at 8:58 AM, Kathryn Gray wrote: >> >>> The test-engine/scheme-tests.ss can be used as a library by >>> programs that aren't written in the teaching language currently; >>> the test results from this library appear in print statements >>> instead of a window in DrScheme. >> >> So does htdp/testing ... (test) . Why are we deprecating htdp/ >> testing again? > > > The functionality doesn't need to (and isn't) going away. > > All htdp/testing does is reexport items from the other library, but > unlike test-engine/scheme-tests it can easily be added by students > as a teach pack. > > If a student does this, and then calls (test) manually; all of > their test results appear twice. Why is this a desirable behavior > to have? Why should we be letting students add this as a teach pack? I remembered that it was a re-export of functionality. I had forgotten about the testing-twice part. Let's print "deprecated, require test-engine/scheme-tests" instead from htdp/testing. And by 5.0 we throw it out. Thanks -- Matthias From robby at eecs.northwestern.edu Tue Mar 17 11:19:14 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Tue Mar 17 11:19:17 2009 Subject: [plt-dev] request for typed library In-Reply-To: References: <1D2BDDB2-F1F7-4B47-9F3C-B98DB1471452@cl.cam.ac.uk> <63bb19ae0903162102q13a231a5gf3ecd8094c44164d@mail.gmail.com> <439BADC5-D9EF-46D3-A6D2-24DB4630D61C@cl.cam.ac.uk> Message-ID: <932b2f1f0903170819m248d59caj17035de3f1026d0e@mail.gmail.com> What would happen if we threw it out now (on the trunk, not on the release branch)? Robby On Tue, Mar 17, 2009 at 9:52 AM, Matthias Felleisen wrote: > > On Mar 17, 2009, at 10:16 AM, Kathryn Gray wrote: > >> >> On 17 Mar 2009, at 1:53:33, Matthias Felleisen wrote: >> >>> >>> On Mar 17, 2009, at 8:58 AM, Kathryn Gray wrote: >>> >>>> The test-engine/scheme-tests.ss can be used as a library by programs >>>> that aren't written in the teaching language currently; the test results >>>> from this library appear in print statements instead of a window in >>>> DrScheme. >>> >>> So does htdp/testing ... (test) . Why are we deprecating htdp/testing >>> again? >> >> >> The functionality doesn't need to (and isn't) going away. >> >> All htdp/testing does is reexport items from the other library, but unlike >> test-engine/scheme-tests it can easily be added by students as a teach pack. >> >> If a student does this, and then calls (test) manually; all of their test >> results appear twice. Why is this a desirable behavior to have? Why should >> we be letting students add this as a teach pack? > > > I remembered that it was a re-export of functionality. I had forgotten about > the testing-twice part. > > Let's print "deprecated, require test-engine/scheme-tests" instead from > htdp/testing. And by 5.0 we throw it out. > > Thanks -- Matthias > > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > From matthias at ccs.neu.edu Tue Mar 17 12:04:38 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Tue Mar 17 12:06:28 2009 Subject: [plt-dev] request for typed library In-Reply-To: <932b2f1f0903170819m248d59caj17035de3f1026d0e@mail.gmail.com> References: <1D2BDDB2-F1F7-4B47-9F3C-B98DB1471452@cl.cam.ac.uk> <63bb19ae0903162102q13a231a5gf3ecd8094c44164d@mail.gmail.com> <439BADC5-D9EF-46D3-A6D2-24DB4630D61C@cl.cam.ac.uk> <932b2f1f0903170819m248d59caj17035de3f1026d0e@mail.gmail.com> Message-ID: Let's do it. All it means is that I (and others) have to remember the longer name. On Mar 17, 2009, at 11:19 AM, Robby Findler wrote: > What would happen if we threw it out now (on the trunk, not on the > release branch)? > > Robby > > On Tue, Mar 17, 2009 at 9:52 AM, Matthias Felleisen > wrote: >> >> On Mar 17, 2009, at 10:16 AM, Kathryn Gray wrote: >> >>> >>> On 17 Mar 2009, at 1:53:33, Matthias Felleisen wrote: >>> >>>> >>>> On Mar 17, 2009, at 8:58 AM, Kathryn Gray wrote: >>>> >>>>> The test-engine/scheme-tests.ss can be used as a library by >>>>> programs >>>>> that aren't written in the teaching language currently; the >>>>> test results >>>>> from this library appear in print statements instead of a >>>>> window in >>>>> DrScheme. >>>> >>>> So does htdp/testing ... (test) . Why are we deprecating htdp/ >>>> testing >>>> again? >>> >>> >>> The functionality doesn't need to (and isn't) going away. >>> >>> All htdp/testing does is reexport items from the other library, >>> but unlike >>> test-engine/scheme-tests it can easily be added by students as a >>> teach pack. >>> >>> If a student does this, and then calls (test) manually; all of >>> their test >>> results appear twice. Why is this a desirable behavior to have? >>> Why should >>> we be letting students add this as a teach pack? >> >> >> I remembered that it was a re-export of functionality. I had >> forgotten about >> the testing-twice part. >> >> Let's print "deprecated, require test-engine/scheme-tests" instead >> from >> htdp/testing. And by 5.0 we throw it out. >> >> Thanks -- Matthias >> >> _________________________________________________ >> For list-related administrative tasks: >> http://list.cs.brown.edu/mailman/listinfo/plt-dev >> From dherman at ccs.neu.edu Tue Mar 17 12:16:42 2009 From: dherman at ccs.neu.edu (Dave Herman) Date: Tue Mar 17 12:17:06 2009 Subject: [plt-dev] Re: more requests for typed-scheme In-Reply-To: References: <63bb19ae0903162059w7ffb67fbxa46c3f6cf10cafb6@mail.gmail.com> <63bb19ae0903170550g64018bb8v278005f2a91c7c02@mail.gmail.com> Message-ID: <49BFCCEA.4050209@ccs.neu.edu> > Everyone, please find things you find useful in srfi/1 :-) FWIW, my favorites that I think are still absent from scheme/list: count, list-index, take-while, drop-while, span, break Also all the lset stuff, though that might make sense to provide as a different library. Dave From kathryn.gray at cl.cam.ac.uk Tue Mar 17 12:23:56 2009 From: kathryn.gray at cl.cam.ac.uk (Kathryn Gray) Date: Tue Mar 17 12:24:02 2009 Subject: [plt-dev] request for typed library In-Reply-To: <932b2f1f0903170819m248d59caj17035de3f1026d0e@mail.gmail.com> References: <1D2BDDB2-F1F7-4B47-9F3C-B98DB1471452@cl.cam.ac.uk> <63bb19ae0903162102q13a231a5gf3ecd8094c44164d@mail.gmail.com> <439BADC5-D9EF-46D3-A6D2-24DB4630D61C@cl.cam.ac.uk> <932b2f1f0903170819m248d59caj17035de3f1026d0e@mail.gmail.com> Message-ID: Provided we also remove teachpacks/htdp/testing, there are no errors from setup-plt; so removal seems safe to me. -Kathy On 17 Mar 2009, at 3:19:14, Robby Findler wrote: > What would happen if we threw it out now (on the trunk, not on the > release branch)? > > Robby > > On Tue, Mar 17, 2009 at 9:52 AM, Matthias Felleisen > wrote: >> >> On Mar 17, 2009, at 10:16 AM, Kathryn Gray wrote: >> >>> >>> On 17 Mar 2009, at 1:53:33, Matthias Felleisen wrote: >>> >>>> >>>> On Mar 17, 2009, at 8:58 AM, Kathryn Gray wrote: >>>> >>>>> The test-engine/scheme-tests.ss can be used as a library by >>>>> programs >>>>> that aren't written in the teaching language currently; the test >>>>> results >>>>> from this library appear in print statements instead of a window >>>>> in >>>>> DrScheme. >>>> >>>> So does htdp/testing ... (test) . Why are we deprecating htdp/ >>>> testing >>>> again? >>> >>> >>> The functionality doesn't need to (and isn't) going away. >>> >>> All htdp/testing does is reexport items from the other library, >>> but unlike >>> test-engine/scheme-tests it can easily be added by students as a >>> teach pack. >>> >>> If a student does this, and then calls (test) manually; all of >>> their test >>> results appear twice. Why is this a desirable behavior to have? >>> Why should >>> we be letting students add this as a teach pack? >> >> >> I remembered that it was a re-export of functionality. I had >> forgotten about >> the testing-twice part. >> >> Let's print "deprecated, require test-engine/scheme-tests" instead >> from >> htdp/testing. And by 5.0 we throw it out. >> >> Thanks -- Matthias >> >> _________________________________________________ >> For list-related administrative tasks: >> http://list.cs.brown.edu/mailman/listinfo/plt-dev >> -Kathy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090317/a8d7b251/attachment.htm From matthias at ccs.neu.edu Tue Mar 17 12:59:15 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Tue Mar 17 13:01:03 2009 Subject: [plt-dev] request for typed library In-Reply-To: References: <1D2BDDB2-F1F7-4B47-9F3C-B98DB1471452@cl.cam.ac.uk> <63bb19ae0903162102q13a231a5gf3ecd8094c44164d@mail.gmail.com> <439BADC5-D9EF-46D3-A6D2-24DB4630D61C@cl.cam.ac.uk> <932b2f1f0903170819m248d59caj17035de3f1026d0e@mail.gmail.com> Message-ID: Go for it. On Mar 17, 2009, at 12:23 PM, Kathryn Gray wrote: > Provided we also remove teachpacks/htdp/testing, there are no > errors from setup-plt; so removal seems safe to me. > > -Kathy > > On 17 Mar 2009, at 3:19:14, Robby Findler wrote: > >> What would happen if we threw it out now (on the trunk, not on the >> release branch)? >> >> Robby >> >> On Tue, Mar 17, 2009 at 9:52 AM, Matthias Felleisen >> wrote: >>> >>> On Mar 17, 2009, at 10:16 AM, Kathryn Gray wrote: >>> >>>> >>>> On 17 Mar 2009, at 1:53:33, Matthias Felleisen wrote: >>>> >>>>> >>>>> On Mar 17, 2009, at 8:58 AM, Kathryn Gray wrote: >>>>> >>>>>> The test-engine/scheme-tests.ss can be used as a library by >>>>>> programs >>>>>> that aren't written in the teaching language currently; the >>>>>> test results >>>>>> from this library appear in print statements instead of a >>>>>> window in >>>>>> DrScheme. >>>>> >>>>> So does htdp/testing ... (test) . Why are we deprecating htdp/ >>>>> testing >>>>> again? >>>> >>>> >>>> The functionality doesn't need to (and isn't) going away. >>>> >>>> All htdp/testing does is reexport items from the other library, >>>> but unlike >>>> test-engine/scheme-tests it can easily be added by students as a >>>> teach pack. >>>> >>>> If a student does this, and then calls (test) manually; all of >>>> their test >>>> results appear twice. Why is this a desirable behavior to have? >>>> Why should >>>> we be letting students add this as a teach pack? >>> >>> >>> I remembered that it was a re-export of functionality. I had >>> forgotten about >>> the testing-twice part. >>> >>> Let's print "deprecated, require test-engine/scheme-tests" >>> instead from >>> htdp/testing. And by 5.0 we throw it out. >>> >>> Thanks -- Matthias >>> >>> _________________________________________________ >>> For list-related administrative tasks: >>> http://list.cs.brown.edu/mailman/listinfo/plt-dev >>> > > -Kathy > From mflatt at cs.utah.edu Tue Mar 17 17:07:24 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Tue Mar 17 17:07:28 2009 Subject: [plt-dev] syntax-local-value and identifier-mappings In-Reply-To: <20090310002216.7CD5F6500A2@mail-svr1.cs.utah.edu> References: <63bb19ae0903091315jee5ad88la8c90254c9e6604b@mail.gmail.com> <20090310002216.7CD5F6500A2@mail-svr1.cs.utah.edu> Message-ID: <20090317210724.90A0565009E@mail-svr1.cs.utah.edu> At Mon, 9 Mar 2009 18:22:14 -0600, Matthew Flatt wrote: > One last possibility, which I had not really considered until now, is > to have the macro expander treat a transformer binding to a renamer by > applying a syntax-object renaming immediately, instead of merely > installing a transformer binding. That sounds promising to me, and I > could give it a try next week or so. This change is in SVN as v4.1.5.2. When you bind an identifier as syntax to a rename transformer, the parser installs a syntax-object equivalence to make the original and new identifiers `free-identifier=?': > (define x 'whatever) > (define-syntax y (make-rename-transformer #'x)) > (free-identifier=? #'x #'y) #t This change should make things work better. For example, `define-package' works more the way you'd expect with `syntax-rules' literals: (define-package p (x y) (define-syntax x (syntax-rules (y) [(x y) 'y] [(x z) 'other])) (define y 'placeholder)) (let () (open-package p) (x y)) ; => 'y, instead of 'other Similarly, Typed Scheme's use of a `free-identifier=?' table to track types should now cooperate automatically with forms like `define-package' (or the `splicing-let' form that Ryan just posted to plt-scheme). From jay.mccarthy at gmail.com Tue Mar 17 18:30:35 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Tue Mar 17 18:30:41 2009 Subject: [plt-dev] Weird bug Message-ID: I have a planet package with a file called main that exports 'error' When I try to run the following module: #lang scheme (require (planet cce/scheme:4:1/planet)) (require (for-label (only-in (this-package-in main) error))) I get the following error: module: identifier already imported from a different source in: error (rename (planet plai/plai:1:0/main) error error) (rename (planet plai/plai:1:0/main) error error) It macro expands to: (module test scheme (#%module-begin (#%require (planet cce/scheme:4:1/planet)) (#%require (just-meta 1 (for-meta #f (rename (planet plai/plai:1:0/main) error error))) (just-meta 0 (for-meta #f (rename (planet plai/plai:1:0/main) error error))) (for-meta #f (only (planet plai/plai:1:0/main)))))) I can't seem to get an error without using planet or cce's library. Any idea? Jay -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From robby at eecs.northwestern.edu Tue Mar 17 19:03:43 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Tue Mar 17 19:03:45 2009 Subject: [plt-dev] language dialog Message-ID: <932b2f1f0903171603o27130bd1of9d7aa86f9320a04@mail.gmail.com> I found some bugs in the way the language dialog is set up (these are ripples from earlier fixes to the language dialog that introduced the bug that caused the module language to forget the collection paths ...). If you have time, please do poke around in that dialog and see if you can get strange things to happen ... (I'm trying too and so far everything is okay, afaict.) Note that I just committed a fix (revision 14164). Thanks, Robby From mflatt at cs.utah.edu Tue Mar 17 20:51:43 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Tue Mar 17 20:51:49 2009 Subject: [plt-dev] Weird bug In-Reply-To: References: Message-ID: <20090318005145.C04F265009E@mail-svr1.cs.utah.edu> At Tue, 17 Mar 2009 16:30:35 -0600, Jay McCarthy wrote: > I have a planet package with a file called main that exports 'error' > > When I try to run the following module: > > #lang scheme > (require (planet cce/scheme:4:1/planet)) > (require (for-label (only-in (this-package-in main) > error))) > > I get the following error: > > module: identifier already imported from a different source in: > error > (rename (planet plai/plai:1:0/main) error error) > (rename (planet plai/plai:1:0/main) error error) I can provoke this error by creating "main.ss" as #lang scheme (require "other.ss") (define-for-syntax error 5) (provide error (for-syntax error)) where "other.ss" also exports `error' (at phase level 0). So, "main.ss" exports different `error' bindings at phase levels 0 and 1. That creates a conflict for the `for-label' import, because `for-label' collapses all phases, and thus ends up with two different `error' bindings. Is that what happens in your program? I see that defining "main.ss" as #lang scheme (define error 5) (define-for-syntax error 5) (provide error (for-syntax error)) doesn't trigger an error, but that's a bug. The `require' form is apparently checking just the id and module, which is the same, but it should also compare the source phase levels. From eli at barzilay.org Wed Mar 18 03:35:31 2009 From: eli at barzilay.org (Eli Barzilay) Date: Wed Mar 18 03:35:52 2009 Subject: [plt-dev] Pre-Release Checklist for v4.1.5 Message-ID: Checklist items for the v4.1.5 release (using the v4.1.4.900 alpha build) Search for your name to find relevant items, reply when you finish an item (please indicate which item is done). Also, if you have any commits that should have been merged, make sure that they're in. Important: new builds are created without announcement, usually whenever I see significant commits. If you need to commit changes, please make sure you tell me to merge it to the release branch. --> Release candidates are at --> http://pre.plt-scheme.org/release/installers Please use these installers (or source bundles) -- don't test from your own svn chekout (don't test v4.1.5.1 by mistake!). To get the tests directory in the normal release, you can do this: cd .../collects svn export http://svn.plt-scheme.org/plt/release/collects/tests ---------------------------------------------------------------------- *** Testing: * Matthew Flatt - MzScheme Tests - Languages Tests - MrEd Tests (Also check that `mred -z' and `mred-text' still works in Windows and Mac OS X) - mzc Tests - mzc --exe tests - .plt-packing Tests - Games Tests - Unit Tests - Syntax Color Tests - R6RS Tests Updates: - MzScheme Updates: update HISTORY - MrEd Updates: update README, HISTORY (updates should show v4.1.5 as the most current version) - Update man pages in plt/man/man1: mred.1, mzscheme.1 Email me to merge the changes from the trunk when they're done, or tell me if there are no such changes. * Robby Findler - DrScheme Tests - Framework Tests - Contracts Tests - Games Tests - Teachpacks Tests: image tests - PLaneT Tests Updates: - DrScheme Updates: update HISTORY - Redex Updates: update HISTORY (updates should show v4.1.5 as the most current version) - Ensure that previous version of DrScheme's preference files still starts up with new DrScheme - Update man pages in plt/man/man1: drscheme.1 Email me to merge the changes from the trunk when they're done, or tell me if there are no such changes. * John Clements - Stepper Tests Updates: - Stepper Updates: update HISTORY (updates should show v4.1.5 as the most current version) Email me to merge the changes from the trunk when they're done, or tell me if there are no such changes. * Matthias Felleisen - Teachpacks Tests: check that new teachpacks are addable - Teachpack Docs: check teachpack docs in the bundles Updates: - Teachpack Updates: update HISTORY (updates should show v4.1.5 as the most current version; email me to merge the changes from the trunk when they're done, or tell me if there are no such changes.) * Ryan Culpepper - Macro Debugger Tests - Syntax Classifier Tests * Jay McCarthy - Web server Tests - XML Tests - HTML Tests * Paul Steckler - MysterX Tests - MzCOM Tests * Kathy Gray - ProfJ Tests - Test Engine Tests * Noel Welsh , Chongkai Zhu - SRFI Tests - Ensure that all claimed srfi's are in the bundle and they all load into mzscheme or drscheme (as appropriate) * Sam Tobin-Hochstadt - Match Tests - Typed Scheme Tests * Stevie Strickland - Unit Contract Tests - Contract Region Tests * Eli Barzilay - Swindle Tests - Plot Tests - PLT Tree: compare new distribution trees to previous ones Version Updates: if a major change has happened, update the version number in: - plt/collects/mzscheme/info.ss - plt/collects/mred/info.ss * Doug Williams - Plot Tests * Greg Cooper - FrTime Tests * Carl Eastlund - Dracula Tests (confirm that Dracula runs from PLaneT) * Shriram Krishnamurthi Tour: check the tour and generate a new one if needed. [Note: Since this is a v4.1.4.900 build, you will need to edit your .../collects/framework/private/version.ss file and change `(version)' to `"4.1.5"'.] -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From mflatt at cs.utah.edu Wed Mar 18 09:04:34 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Wed Mar 18 09:04:41 2009 Subject: [plt-dev] Pre-Release Checklist for v4.1.5 In-Reply-To: References: Message-ID: <20090318130436.A652F6500A2@mail-svr1.cs.utah.edu> At Wed, 18 Mar 2009 03:35:31 -0400, Eli Barzilay wrote: > * Matthew Flatt > - MzScheme Tests > - Languages Tests > - MrEd Tests (Also check that `mred -z' and `mred-text' still works > in Windows and Mac OS X) > - mzc Tests > - mzc --exe tests > - .plt-packing Tests > - Games Tests > - Unit Tests > - Syntax Color Tests > - R6RS Tests > Updates: > - MzScheme Updates: update HISTORY > - MrEd Updates: update README, HISTORY > (updates should show v4.1.5 as the most current version) > - Update man pages in plt/man/man1: mred.1, mzscheme.1 > Email me to merge the changes from the trunk when they're done, > or tell me if there are no such changes. Done. From jay.mccarthy at gmail.com Wed Mar 18 11:53:46 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Wed Mar 18 11:53:49 2009 Subject: [plt-dev] Pre-Release Checklist for v4.1.5 In-Reply-To: References: Message-ID: On Wed, Mar 18, 2009 at 1:35 AM, Eli Barzilay wrote: > * Jay McCarthy > ?- Web server Tests > ?- XML Tests > ?- HTML Tests Done -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From jay.mccarthy at gmail.com Wed Mar 18 12:23:59 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Wed Mar 18 12:24:03 2009 Subject: [plt-dev] Weird bug In-Reply-To: <20090318005145.C04F265009E@mail-svr1.cs.utah.edu> References: <20090318005145.C04F265009E@mail-svr1.cs.utah.edu> Message-ID: Ya, that was the issue. I was reproviding scheme, except for "error", but scheme provides error at the syntax and expression phases, and I was only overriding the expression level. Now that I know (except-out (all-from-out scheme) error (for-syntax error)) is legal, I have to change my mental model of provides. Jay On Tue, Mar 17, 2009 at 6:51 PM, Matthew Flatt wrote: > At Tue, 17 Mar 2009 16:30:35 -0600, Jay McCarthy wrote: >> I have a planet package with a file called main that exports 'error' >> >> When I try to run the following module: >> >> #lang scheme >> (require (planet cce/scheme:4:1/planet)) >> (require (for-label (only-in (this-package-in main) >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? error))) >> >> I get the following error: >> >> module: identifier already imported from a different source in: >> ? error >> ? (rename (planet plai/plai:1:0/main) error error) >> ? (rename (planet plai/plai:1:0/main) error error) > > I can provoke this error by creating "main.ss" as > > ?#lang scheme > ?(require "other.ss") > ?(define-for-syntax error 5) > ?(provide error > ? ? ? ? ?(for-syntax error)) > > where "other.ss" also exports `error' (at phase level 0). > > So, "main.ss" exports different `error' bindings at phase levels 0 and > 1. That creates a conflict for the `for-label' import, because > `for-label' collapses all phases, and thus ends up with two different > `error' bindings. > > Is that what happens in your program? > > > I see that defining "main.ss" as > > ?#lang scheme > ?(define error 5) > ?(define-for-syntax error 5) > ?(provide error > ? ? ? ? ?(for-syntax error)) > > doesn't trigger an error, but that's a bug. The `require' form is > apparently checking just the id and module, which is the same, but it > should also compare the source phase levels. > > -- 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 Mar 18 12:43:20 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Wed Mar 18 12:43:24 2009 Subject: [plt-dev] prefix-in and schemelink don't play well in Scribble Message-ID: If I require scheme with a prefix... (require (for-label (prefix-in scheme: scheme))) and want to link to an identifier from scheme, @schemelink[scheme:error]{@schemeidfont{error}} I get the following error in the build: setup-plt: WARNING: undefined tag in ....scrbl: setup-plt: (undef "--UNDEFINED:scheme:error--") But, the link is fine in the HTML documentation. Also, I think @schemelink should have a #:underline? option so I can make this bit of documentation look like a normal variable reference. It would be simple to add to manual-scheme.ss, but I'm not familiar with the syntax keyword pattern, so I won't attempt it. Another convenience would be to be able to write something like: @scheme[#:prefix scheme: error] or @scheme[#:unprefix? #t scheme:error] for the same effect Jay -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From robby at eecs.northwestern.edu Wed Mar 18 12:51:45 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Wed Mar 18 12:51:48 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.1.5 In-Reply-To: References: Message-ID: <932b2f1f0903180951j451dd997p39037d0e5fae6980@mail.gmail.com> On Wed, Mar 18, 2009 at 2:35 AM, Eli Barzilay wrote: > * Robby Findler > ?- DrScheme Tests > - Framework Tests > ?- Contracts Tests > - Games Tests > ?- Teachpacks Tests: image tests > ?- PLaneT Tests > ?Updates: > ?- DrScheme Updates: update HISTORY > ?- Redex Updates: update HISTORY > ?(updates should show v4.1.5 as the most current version) > ?- Ensure that previous version of DrScheme's preference files still > ? ?starts up with new DrScheme > ?- Update man pages in plt/man/man1: drscheme.1 > ?Email me to merge the changes from the trunk when they're done, > ?or tell me if there are no such changes. Done. Robby From sstrickl at ccs.neu.edu Wed Mar 18 13:29:03 2009 From: sstrickl at ccs.neu.edu (Stevie Strickland) Date: Wed Mar 18 13:29:42 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.1.5 In-Reply-To: References: Message-ID: <292E9372-ECC2-4F17-9025-F8927E896646@ccs.neu.edu> On Mar 18, 2009, at 3:35 AM, Eli Barzilay wrote: > * Stevie Strickland > - Unit Contract Tests > - Contract Region Tests Done. Stevie From jay.mccarthy at gmail.com Wed Mar 18 13:30:20 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Wed Mar 18 13:30:23 2009 Subject: [plt-dev] Scribble example Message-ID: As an example of what you can do with Scribble, you might be interested in taking a look at my PL course site: http://faculty.cs.byu.edu/~jay/courses/proto/330/course/ I can send the code to anyone interested. Some things worked amazingly well: - @scheme - @secref - @examples - custom stylesheets (for my zebra stripped tables) Other things were annoying, but I got the hang of it - Building tables (I had to write a custom macro each time) - "faking" bindings for assignments with declare-exporting #:use-sources Other things were quite painful: - Referring to PLaneT packages (basically, I couldn't find a way to, because --redirect-main works great to go to doc.plt-scheme.org, but there isn't anything comparable to planet.plt-scheme.org's docs.) [Assignment 2.16 basically repeats the PLaneT docs] [I got the links to work at all by faking definitions exported by PLAI and defidentifier-ing them in the help section, so the links would bring you back to there] - Cross reference links within @schemeblock or @examples (Take a look at Section 10, it would be nice if that `define' could generate a cross reference. I could simulate it by #,(defidentifier #'convert-to-letter) but didn't want to go through that pain. - Using macros in @schemeblock (take a look at the define-type in assignment 2.18, particularly the `bif' variant.) (Note: The page refers to a PLAI planet package that isn't on the server yet. It is still being tested.) Jay -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From carl.eastlund at gmail.com Wed Mar 18 15:10:30 2009 From: carl.eastlund at gmail.com (Carl Eastlund) Date: Wed Mar 18 15:10:33 2009 Subject: [plt-dev] Pre-Release Checklist for v4.1.5 In-Reply-To: References: Message-ID: <990e0c030903181210x6315aaa4w80d721a2c0699958@mail.gmail.com> On Wed, Mar 18, 2009 at 3:35 AM, Eli Barzilay wrote: > Checklist items for the v4.1.5 release > ?(using the v4.1.4.900 alpha build) > > * Carl Eastlund > ?- Dracula Tests (confirm that Dracula runs from PLaneT) Done. -- Carl Eastlund From samth at ccs.neu.edu Wed Mar 18 15:31:23 2009 From: samth at ccs.neu.edu (Sam TH) Date: Wed Mar 18 15:31:27 2009 Subject: [plt-dev] syntax-local-value and identifier-mappings In-Reply-To: <20090317210724.90A0565009E@mail-svr1.cs.utah.edu> References: <63bb19ae0903091315jee5ad88la8c90254c9e6604b@mail.gmail.com> <20090310002216.7CD5F6500A2@mail-svr1.cs.utah.edu> <20090317210724.90A0565009E@mail-svr1.cs.utah.edu> Message-ID: <63bb19ae0903181231p38776e8by116b10a8b9381ebe@mail.gmail.com> On Tue, Mar 17, 2009 at 5:07 PM, Matthew Flatt wrote: > > This change is in SVN as v4.1.5.2. This doesn't seem to be working for me. In particular, this program (also attached) gives an error from `free-identifier-mapping-get', but I think it should succeed. #lang scheme/load (module m scheme (require (for-syntax syntax/boundmap)) (define-for-syntax table (make-free-identifier-mapping)) (define-syntax x 1) (define-syntax x* (make-rename-transformer #'x)) (begin-for-syntax (free-identifier-mapping-put! table #'x 'got-it)) (define-syntax (get stx) (syntax-case stx () [(_ i) #`(quote #,(free-identifier-mapping-get table #'i))])) (provide (rename-out [x* x]) get)) (module n scheme (require 'm) (get x)) (require 'n) Am I doing something wrong here? Thanks, -- sam th samth@ccs.neu.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: id-map-bug.ss Type: application/octet-stream Size: 511 bytes Desc: not available Url : http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090318/086e1e6a/id-map-bug.obj From mflatt at cs.utah.edu Wed Mar 18 15:41:38 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Wed Mar 18 15:41:50 2009 Subject: [plt-dev] syntax-local-value and identifier-mappings In-Reply-To: <63bb19ae0903181231p38776e8by116b10a8b9381ebe@mail.gmail.com> References: <63bb19ae0903091315jee5ad88la8c90254c9e6604b@mail.gmail.com> <20090310002216.7CD5F6500A2@mail-svr1.cs.utah.edu> <20090317210724.90A0565009E@mail-svr1.cs.utah.edu> <63bb19ae0903181231p38776e8by116b10a8b9381ebe@mail.gmail.com> Message-ID: <20090318194138.AE579650064@mail-svr1.cs.utah.edu> At Wed, 18 Mar 2009 15:31:23 -0400, Sam TH wrote: > On Tue, Mar 17, 2009 at 5:07 PM, Matthew Flatt wrote: > > > > This change is in SVN as v4.1.5.2. > > This doesn't seem to be working for me. In particular, this program > (also attached) gives an error from `free-identifier-mapping-get', but > I think it should succeed. > > [...] > > Am I doing something wrong here? No. This works when you use just one module, but not two modules, right? I need to generalize one step further with respect to `provide'... From clements at brinckerhoff.org Wed Mar 18 17:08:51 2009 From: clements at brinckerhoff.org (John Clements) Date: Wed Mar 18 17:09:07 2009 Subject: [plt-dev] Stepper tests for DeinProgramm language levels? Message-ID: As part of pre-release testing, I run the tests in plt/collects/tests/ stepper/through-tests... which don't cover any of the deinprogramm language levels. You clearly have a stake in making sure that the stepper still works for these language levels, so I'm wondering if you'd like to contribute some tests. Currently, the tests are all in one place--though that could easily change--and they're in one of two formats: my straightforward if somewhat verbose style, and Eli's compact but non-sexp-y flavor. Here are a couple of examples: ;; my verbose style (t1 let2 (test-both-ints "(let ([a (+ 4 5)] [b (+ 9 20)]) (+ a b))" `((before-after ((hilite (let ([a (+ 4 5)] [b (+ 9 20)]) (+ a b)))) ((hilite (define a_0 (+ 4 5))) (hilite (define b_0 (+ 9 20))) (hilite (+ a_0 b_0)))) (before-after ((define a_0 (hilite (+ 4 5))) (define b_0 (+ 9 20)) (+ a_0 b_0)) ((define a_0 (hilite 9)) (define b_0 (+ 9 20)) (+ a_0 b_0))) (before-after ((define a_0 9) (define b_0 (hilite (+ 9 20))) (+ a_0 b_0)) ((define a_0 9) (define b_0 (hilite 29)) (+ a_0 b_0))) (before-after ((define a_0 9) (define b_0 29) (+ (hilite a_0) b_0)) ((define a_0 9) (define b_0 29) (+ (hilite 9) b_0))) (before-after ((define a_0 9) (define b_0 29) (+ 9 (hilite b_0))) ((define a_0 9) (define b_0 29) (+ 9 (hilite 29)))) (before-after ((define a_0 9) (define b_0 29) (hilite (+ 9 29))) ((define a_0 9) (define b_0 29) (hilite 38))) (finished-stepping)))) ;; eli's compact style: (let ([def `(define a5 (lambda (a5) (+ a5 13)))]) (t lam-def test-upto-int ,def (a5 23) :: ,def {(a5 23)} -> ,def {(+ 23 13)} -> ,def {36})) Looking at this more closely, the lowest-hanging fruit here would simply be identifying existing tests where the expected result in some DeinProgramm language level is the same as the existing expected result for some test. I took a quick crack at running a beginner programm in the lowest DeinProgramm level, but the error message suggested that I couldn't define new operations in this language level, so I just gave up :). Anyhow, if you find time to do this at some point, it would probably increase the reliability of the stepper w.r.t. DeinProgramm. cc'ing plt-dev, in case anyone else has good suggestions. 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/20090318/1de004dd/smime.bin From mflatt at cs.utah.edu Wed Mar 18 17:48:15 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Wed Mar 18 17:48:21 2009 Subject: [plt-dev] syntax-local-value and identifier-mappings In-Reply-To: <63bb19ae0903091733l6f8797cao2b8304f6f306a321@mail.gmail.com> References: <63bb19ae0903091315jee5ad88la8c90254c9e6604b@mail.gmail.com> <20090310002216.7CD5F6500A2@mail-svr1.cs.utah.edu> <63bb19ae0903091733l6f8797cao2b8304f6f306a321@mail.gmail.com> Message-ID: <20090318214816.561416500AE@mail-svr1.cs.utah.edu> At Mon, 9 Mar 2009 18:22:14 -0600, Matthew Flatt wrote: > One last possibility, which I had not really considered until now, is > to have the macro expander treat a transformer binding to a renamer by > applying a syntax-object renaming immediately, instead of merely > installing a transformer binding. That sounds promising to me, and I > could give it a try next week or so. It seemed strange to me is that running a transformer expression would determine `free-identifier=?' equivalences. Of course, transformers create binding forms all the time, so I couldn't quite put my finger on why that should be a problem... At Mon, 9 Mar 2009 20:33:17 -0400, Sam TH wrote: > On Mon, Mar 9, 2009 at 8:22 PM, Matthew Flatt wrote: > So, in one sense, if (as you suggest) `free-identifier=?' cooperated > with rename transformers, then that would work. But the other > constraint is that I need the binding form to operate at the > expression level, since the code that uses `make-rename-transformer' > looks like this: > > (define-syntax foo > (if (typed-context?) > (make-rename-transformer #'foo*) > (make-rename-transformer #'other-foo))) > > so something like `define-renaming' wouldn't work. ...but this really should have made me see. The context of the `foo' definition will be parsed/expanded once and for all, which means that `free-identifier=?' equivalences in that context are fixed. But this syntax definition is evaluated many times afterward, once for each "visit" to the enclosing module. I didn't make the connection between "expression level" and "can produce different results at different times", and the latter is a feature that Typed Scheme relies on. The problem is easier to see if you think about `for-label' imports, which don't "visit" the imported module. If a module containing the above definition is imported `for-label', should `foo' be `free-label-identifier=?' to `foo*' or `other-foo'? There's no way to say, because the `if' expression isn't evaluated. Back to the drawing board. I think `define-renaming' in roughly its current form (as a pattern of a transformer binding plus `make-rename-transformer') is useful. It doesn't solve the problem in Typed Scheme, though. We could add a `syntax-local-value' that doesn't recur, but now I wonder: do bindings like `foo' really need to be created with `make-rename-transformer'? Could they instead be implemented as macro transformers that are actually procedure instances, so Typed Scheme could chain through the renaming manually? I have in mind something like this: (define-struct typed-id (orig) #:property prop:procedure (lambda (stx self) (syntax-case stx () [(id arg ...) #`(#,(typed-id-orig self) arg ...)] [id (typed-id-orig self)]))) (define-syntax foo (make-typed-id (if (typed-context?) #'foo* #'other-foo)))) From clements at brinckerhoff.org Wed Mar 18 17:51:46 2009 From: clements at brinckerhoff.org (John Clements) Date: Wed Mar 18 17:51:59 2009 Subject: [plt-dev] check-expect "dock" + stepper: minor bug, fix after release? Message-ID: Currently, clicking the "dock" button on a check-expect error window that pops up during the stepper's evaluation causes the window to disappear. I propose that the "dock" button be disabled or removed when the window pops up during stepping. 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/20090318/d1d7993a/smime.bin From clements at brinckerhoff.org Wed Mar 18 17:57:05 2009 From: clements at brinckerhoff.org (John Clements) Date: Wed Mar 18 17:57:09 2009 Subject: [plt-dev] Pre-Release Checklist for v4.1.5 In-Reply-To: References: Message-ID: <0B60D290-51E9-4C15-99EA-131A7BF32982@brinckerhoff.org> On Mar 18, 2009, at 12:35 AM, Eli Barzilay wrote: > Checklist items for the v4.1.5 release > (using the v4.1.4.900 alpha build) > > * John Clements > - Stepper Tests > Updates: > - Stepper Updates: update HISTORY > (updates should show v4.1.5 as the most current version) > Email me to merge the changes from the trunk when they're done, > or tell me if there are no such changes. Done. 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/20090318/fbd67fb4/smime.bin From samth at ccs.neu.edu Wed Mar 18 18:20:42 2009 From: samth at ccs.neu.edu (Sam TH) Date: Wed Mar 18 18:27:50 2009 Subject: [plt-dev] syntax-local-value and identifier-mappings In-Reply-To: <20090318214816.561416500AE@mail-svr1.cs.utah.edu> References: <63bb19ae0903091315jee5ad88la8c90254c9e6604b@mail.gmail.com> <20090310002216.7CD5F6500A2@mail-svr1.cs.utah.edu> <63bb19ae0903091733l6f8797cao2b8304f6f306a321@mail.gmail.com> <20090318214816.561416500AE@mail-svr1.cs.utah.edu> Message-ID: <63bb19ae0903181520s1b7f49a1t5a91c3cae218c1c9@mail.gmail.com> On Wed, Mar 18, 2009 at 5:48 PM, Matthew Flatt wrote: > At Mon, 9 Mar 2009 18:22:14 -0600, Matthew Flatt wrote: >> One last possibility, which I had not really considered until now, is >> to have the macro expander treat a transformer binding to a renamer by >> applying a syntax-object renaming immediately, instead of merely >> installing a transformer binding. That sounds promising to me, and I >> could give it a try next week or so. > > It seemed strange to me is that running a transformer expression would > determine `free-identifier=?' equivalences. Of course, transformers > create binding forms all the time, so I couldn't quite put my finger on > why that should be a problem... > > At Mon, 9 Mar 2009 20:33:17 -0400, Sam TH wrote: >> On Mon, Mar 9, 2009 at 8:22 PM, Matthew Flatt wrote: >> So, in one sense, if (as you suggest) `free-identifier=?' cooperated >> with rename transformers, then that would work. ?But the other >> constraint is that I need the binding form to operate at the >> expression level, since the code that uses `make-rename-transformer' >> looks like this: >> >> (define-syntax foo >> ? ?(if (typed-context?) >> ? ? ? ?(make-rename-transformer #'foo*) >> ? ? ? ?(make-rename-transformer #'other-foo))) >> >> so something like `define-renaming' wouldn't work. > > ...but this really should have made me see. > > The context of the `foo' definition will be parsed/expanded once and > for all, which means that `free-identifier=?' equivalences in that > context are fixed. But this syntax definition is evaluated many times > afterward, once for each "visit" to the enclosing module. I didn't make > the connection between "expression level" and "can produce different > results at different times", and the latter is a feature that Typed > Scheme relies on. > > The problem is easier to see if you think about `for-label' imports, > which don't "visit" the imported module. If a module containing the > above definition is imported `for-label', should `foo' be > `free-label-identifier=?' to `foo*' or `other-foo'? There's no way to > say, because the `if' expression isn't evaluated. That makes sense. > Back to the drawing board. > > I think `define-renaming' in roughly its current form (as a pattern of > a transformer binding plus `make-rename-transformer') is useful. It > doesn't solve the problem in Typed Scheme, though. > > We could add a `syntax-local-value' that doesn't recur, but now I > wonder: do bindings like `foo' really need to be created with > `make-rename-transformer'? Could they instead be implemented as macro > transformers that are actually procedure instances, so Typed Scheme > could chain through the renaming manually? I have in mind something > like this: > > ?(define-struct typed-id (orig) > ? ? #:property prop:procedure (lambda (stx self) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(syntax-case stx () > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [(id arg ...) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?#`(#,(typed-id-orig self) arg ...)] > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [id (typed-id-orig self)]))) > > ?(define-syntax foo > ? ?(make-typed-id > ? ? ?(if (typed-context?) > ? ? ? ? ?#'foo* > ? ? ? ? ?#'other-foo)))) No, this won't work. One problem is that these identifiers appear in contexts that are not expression positions (in particular, in types). Another problem is that the relevant identifier may be bound to something else (such as static struct information), and the only way the typechecker interferes with it is by using it as the key in a `free-identifier-mapping'. So wrapping these identifiers in something else would break in at least two ways. I vote for the non-recursive version of `syntax-local-value' It's the simpler operation, and the idea of the general form being implementable in Scheme rather than C is appealing. -- sam th samth@ccs.neu.edu From ryanc at ccs.neu.edu Wed Mar 18 18:28:57 2009 From: ryanc at ccs.neu.edu (Ryan Culpepper) Date: Wed Mar 18 18:29:08 2009 Subject: [plt-dev] Stepper tests for DeinProgramm language levels? In-Reply-To: References: Message-ID: <7E3BEBBD-7779-4B1A-B2D5-9B57D6B240D7@ccs.neu.edu> On Mar 18, 2009, at 5:08 PM, John Clements wrote: > As part of pre-release testing, I run the tests in plt/collects/ > tests/stepper/through-tests... which don't cover any of the > deinprogramm language levels. You clearly have a stake in making > sure that the stepper still works for these language levels, so I'm > wondering if you'd like to contribute some tests. Currently, the > tests are all in one place--though that could easily change--and > they're in one of two formats: my straightforward if somewhat > verbose style, and Eli's compact but non-sexp-y flavor. Here are a > couple of examples: > > ;; my verbose style > > (t1 let2 > (test-both-ints "(let ([a (+ 4 5)] [b (+ 9 20)]) (+ a b))" > `((before-after ((hilite (let ([a (+ 4 5)] [b (+ > 9 20)]) (+ a b)))) > ((hilite (define a_0 (+ 4 5))) > (hilite (define b_0 (+ 9 20))) (hilite (+ a_0 b_0)))) > (before-after ((define a_0 (hilite (+ 4 5))) > (define b_0 (+ 9 20)) (+ a_0 b_0)) > ((define a_0 (hilite 9)) (define > b_0 (+ 9 20)) (+ a_0 b_0))) > (before-after ((define a_0 9) (define b_0 > (hilite (+ 9 20))) (+ a_0 b_0)) > ((define a_0 9) (define b_0 > (hilite 29)) (+ a_0 b_0))) > (before-after ((define a_0 9) (define b_0 29) > (+ (hilite a_0) b_0)) > ((define a_0 9) (define b_0 29) > (+ (hilite 9) b_0))) > (before-after ((define a_0 9) (define b_0 29) > (+ 9 (hilite b_0))) > ((define a_0 9) (define b_0 29) > (+ 9 (hilite 29)))) > (before-after ((define a_0 9) (define b_0 29) > (hilite (+ 9 29))) > ((define a_0 9) (define b_0 29) > (hilite 38))) > (finished-stepping)))) > > > ;; eli's compact style: > > (let ([def `(define a5 (lambda (a5) (+ a5 13)))]) > (t lam-def test-upto-int > ,def (a5 23) > :: ,def {(a5 23)} > -> ,def {(+ 23 13)} > -> ,def {36})) > > > Looking at this more closely, the lowest-hanging fruit here would > simply be identifying existing tests where the expected result in > some DeinProgramm language level is the same as the existing > expected result for some test. > > I took a quick crack at running a beginner programm in the lowest > DeinProgramm level, but the error message suggested that I couldn't > define new operations in this language level, so I just gave up :). I think the DeinProgramm teaching languages just require the explicit lambda style of function definition. Ryan > Anyhow, if you find time to do this at some point, it would probably > increase the reliability of the stepper w.r.t. DeinProgramm. > > cc'ing plt-dev, in case anyone else has good suggestions. > > John > > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From eli at barzilay.org Wed Mar 18 18:31:55 2009 From: eli at barzilay.org (Eli Barzilay) Date: Wed Mar 18 18:31:59 2009 Subject: [plt-dev] Stepper tests for DeinProgramm language levels? In-Reply-To: References: Message-ID: <18881.30299.40443.682481@winooski.ccs.neu.edu> On Mar 18, John Clements wrote: > [...] > Anyhow, if you find time to do this at some point, it would probably > increase the reliability of the stepper w.r.t. DeinProgramm. It would be better to avoid the unnecessary dependency that this will introduce; the simple way to do so is for you to expose some testing facility from the stepper tests, and the deinprogramm tests can then require it. (But my impression was what Ryan said.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From ghcooper at gmail.com Wed Mar 18 18:52:54 2009 From: ghcooper at gmail.com (Gregory Cooper) Date: Wed Mar 18 18:52:56 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.1.5 In-Reply-To: References: Message-ID: <65e1d50c0903181552u5bfe94c8j9876b2c085094c8f@mail.gmail.com> > * Greg Cooper > ?- FrTime Tests Done. From eli at barzilay.org Wed Mar 18 19:09:30 2009 From: eli at barzilay.org (Eli Barzilay) Date: Wed Mar 18 19:09:38 2009 Subject: [plt-dev] Release Announcement for v4.1.5 Message-ID: These are possible release announcement items that I saw in the logs. Please mail me concrete release items. * Main additions - Ryan: stxclass - Stevie: Unit contracts, region contract, etc - Jay: web server: digest auth, stuffers - Matthias: world, universe - new at-exp "language" - Literate programming in scribble - Mike: deinprogramm - scribble/text much improved: deals with indentation * Possible items - Sam: TS news? (new wrappers, new syntax, etc) - Robby: Redex news? - Jay: XML/HTML/CGI - scribble command line can now render PDFs (via pdflatex) * Minor additions - SRFI re-exports with R6RS-friendly SRFI-97 names - add bitwise-bit-field - planet verbose? - log-viewing support in drscheme - Check Syntax: added "Tack arrows crossing selection" * Many bugfixes (notable: scheme/package, zip bugfix, drscheme language, match, windows networking, ?) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From matthias at ccs.neu.edu Wed Mar 18 19:15:33 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Wed Mar 18 19:17:17 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.1.5 In-Reply-To: References: Message-ID: <83A3AB94-0503-41E4-A6F0-6D9F6A5334B3@ccs.neu.edu> On Mar 18, 2009, at 3:35 AM, Eli Barzilay wrote: > * Matthias Felleisen > - Teachpacks Tests: check that new teachpacks are addable > - Teachpack Docs: check teachpack docs in the bundles > Updates: > - Teachpack Updates: update HISTORY > (updates should show v4.1.5 as the most current version; email me > to merge the changes from the trunk when they're done, or tell me if > there are no such changes.) Done. Matthew: I noticed that the 'event not registered' bug for QUIT is back. From ryanc at ccs.neu.edu Wed Mar 18 19:27:48 2009 From: ryanc at ccs.neu.edu (Ryan Culpepper) Date: Wed Mar 18 19:27:57 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.1.5 In-Reply-To: References: Message-ID: On Mar 18, 2009, at 3:35 AM, Eli Barzilay wrote: > * Ryan Culpepper > - Macro Debugger Tests > - Syntax Classifier Tests Done. From robby at eecs.northwestern.edu Wed Mar 18 20:53:26 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Wed Mar 18 20:53:29 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.1.5 In-Reply-To: <83A3AB94-0503-41E4-A6F0-6D9F6A5334B3@ccs.neu.edu> References: <83A3AB94-0503-41E4-A6F0-6D9F6A5334B3@ccs.neu.edu> Message-ID: <932b2f1f0903181753o1b92707j331491aef5576099@mail.gmail.com> What is the 'event not registered' bug? On Wed, Mar 18, 2009 at 6:15 PM, Matthias Felleisen wrote: > > On Mar 18, 2009, at 3:35 AM, Eli Barzilay wrote: > >> * Matthias Felleisen >> ?- Teachpacks Tests: check that new teachpacks are addable >> ?- Teachpack Docs: check teachpack docs in the bundles >> ?Updates: >> ?- Teachpack Updates: update HISTORY >> ?(updates should show v4.1.5 as the most current version; email me >> ?to merge the changes from the trunk when they're done, or tell me if >> ?there are no such changes.) > > > Done. > > Matthew: I noticed that the 'event not registered' bug for QUIT is > back._________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > From matthias at ccs.neu.edu Wed Mar 18 21:48:08 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Wed Mar 18 21:48:47 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.1.5 In-Reply-To: <932b2f1f0903181753o1b92707j331491aef5576099@mail.gmail.com> References: <83A3AB94-0503-41E4-A6F0-6D9F6A5334B3@ccs.neu.edu> <932b2f1f0903181753o1b92707j331491aef5576099@mail.gmail.com> Message-ID: <0631E79C-2887-4968-8B1D-F2E5CCF995CD@ccs.neu.edu> I hit RETURN and the QUIT-enabled button doesn't respond. On Mar 18, 2009, at 8:53 PM, Robby Findler wrote: > What is the 'event not registered' bug? > > On Wed, Mar 18, 2009 at 6:15 PM, Matthias Felleisen > wrote: >> >> On Mar 18, 2009, at 3:35 AM, Eli Barzilay wrote: >> >>> * Matthias Felleisen >>> - Teachpacks Tests: check that new teachpacks are addable >>> - Teachpack Docs: check teachpack docs in the bundles >>> Updates: >>> - Teachpack Updates: update HISTORY >>> (updates should show v4.1.5 as the most current version; email me >>> to merge the changes from the trunk when they're done, or tell >>> me if >>> there are no such changes.) >> >> >> Done. >> >> Matthew: I noticed that the 'event not registered' bug for QUIT is >> back._________________________________________________ >> For list-related administrative tasks: >> http://list.cs.brown.edu/mailman/listinfo/plt-dev >> From sperber at deinprogramm.de Thu Mar 19 03:03:29 2009 From: sperber at deinprogramm.de (Michael Sperber) Date: Thu Mar 19 03:03:36 2009 Subject: [plt-dev] Stepper tests for DeinProgramm language levels? In-Reply-To: <7E3BEBBD-7779-4B1A-B2D5-9B57D6B240D7@ccs.neu.edu> (Ryan Culpepper's message of "Wed, 18 Mar 2009 18:28:57 -0400") References: <7E3BEBBD-7779-4B1A-B2D5-9B57D6B240D7@ccs.neu.edu> Message-ID: Ryan Culpepper writes: > On Mar 18, 2009, at 5:08 PM, John Clements wrote: >> As part of pre-release testing, I run the tests in plt/collects/ >> tests/stepper/through-tests... which don't cover any of the >> deinprogramm language levels. You clearly have a stake in making >> sure that the stepper still works for these language levels, so I'm >> wondering if you'd like to contribute some tests. Currently, the >> tests are all in one place--though that could easily change--and >> they're in one of two formats: my straightforward if somewhat >> verbose style, and Eli's compact but non-sexp-y flavor. Here are a >> couple of examples: So far, I've kept the test suites for the DeinProgramm stuff separate. As to the stepper, the main problems in the past have been with rendering, and I've tested that manually. But I'll take up the suggestion and write some automated tests - thanks for explaining! But I'm still unsure whether to check out tests into SVN (most of the existing ones uses SchemeUnit). Should I? > I think the DeinProgramm teaching languages just require the explicit > lambda style of function definition. Exactly. -- Cheers =8-} Mike Friede, V?lkerverst?ndigung und ?berhaupt blabla From eli at barzilay.org Thu Mar 19 07:30:19 2009 From: eli at barzilay.org (Eli Barzilay) Date: Thu Mar 19 07:30:23 2009 Subject: [plt-dev] Pre-Release Checklist for v4.1.5, second call Message-ID: Checklist items for the v4.1.5 release (using the v4.1.4.900 alpha build) Search for your name to find relevant items, reply when you finish an item (please indicate which item is done). Also, if you have any commits that should have been merged, make sure that they're in. Important: new builds are created without announcement, usually whenever I see significant commits. If you need to commit changes, please make sure you tell me to merge it to the release branch. --> Release candidates are at --> http://pre.plt-scheme.org/release/installers Please use these installers (or source bundles) -- don't test from your own svn chekout (don't test v4.1.5.1 by mistake!). To get the tests directory in the normal release, you can do this: cd .../collects svn export http://svn.plt-scheme.org/plt/release/collects/tests ---------------------------------------------------------------------- *** Testing: * Kathy Gray - ProfJ Tests - Test Engine Tests * Noel Welsh , Chongkai Zhu - SRFI Tests - Ensure that all claimed srfi's are in the bundle and they all load into mzscheme or drscheme (as appropriate) * Sam Tobin-Hochstadt - Match Tests - Typed Scheme Tests * Doug Williams - Plot Tests -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From eli at barzilay.org Thu Mar 19 07:31:43 2009 From: eli at barzilay.org (Eli Barzilay) Date: Thu Mar 19 07:31:45 2009 Subject: [plt-dev] Release Announcement for v4.1.5 Message-ID: The release announcement sketch that I have so far is below. I just wrote something on all items that I could, but it's probably pretty bad, still. Please mail me edits. Specifically, these: * Main additions - Ryan: stxclass - Stevie: Unit contracts, region contract, etc - scribble/text much improved: deals with indentation * Possible items - Sam: TS news? (new wrappers, new syntax, etc) - Robby: Redex news? probably need a proper blurb. ---------------------------------------------------------------------- PLT Scheme version 4.1.5 is now available from http://plt-scheme.org/ * Web Server: - new URL-based dispatching library `web-server/dispatch', - customizable continuation serialization policies for the stateless web language `web-server/stuffers', - abstraction of serve/servlet to build simpler dispatchers `web-server/servlet-env', - HTTP Digest authentication support `web-server/http/digest-auth', - built-in cookie support in `web-server/http/cookie' and `web-server/http/cookie-parse', - highlighting and pretty-printing of errors in Xexpr constructions, - load control dispatcher for limit concurrent sessions `web-server/dispatchers/limit'. * Scribble: - Literate programming is now available using the new `scribble/lp' language. - A new `at-exp' language makes it convenient to use the scribble reader's @-expressions for general code. - The `scribble/text' preprocessor language has been extended to deal with indentation and other formatting issues. - The "scribble" command-line tool accepts a `--pdf' flag to render PDFs (via pdflatex). * DrScheme now provides feedback when PLaneT downloads and installs new packages. * Language levels and teachpacks from the DeinProgramm project for the German textbook "Die Macht der Abstraktion" by Herbert Klaeren and Michael Sperber have been added. * Misc: - The `xml' and `html' collections are now contracted. - Binding parsing in net/cgi now interacts with `net/uri-codec's configuration parameters. - DrScheme captures logging output. - Check syntax: it is now possible to tack arrows crossing the currently selected text. - SRFI collections are available with R6RS-frienly names as in SRFI-97. - New `bitwise-bit-field' function. * The usual pile of bugfixes. (Notable: `scheme/package' works, `deflate' compression fixed, DrScheme language dialog issue resolved, `match' fixes, Windows networking, and much more.) ---------------------------------------------------------------------- -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From eli at barzilay.org Thu Mar 19 07:36:26 2009 From: eli at barzilay.org (Eli Barzilay) Date: Thu Mar 19 07:36:30 2009 Subject: [plt-dev] Stepper tests for DeinProgramm language levels? In-Reply-To: References: <7E3BEBBD-7779-4B1A-B2D5-9B57D6B240D7@ccs.neu.edu> Message-ID: <18882.11834.217423.536195@winooski.ccs.neu.edu> On Mar 19, Michael Sperber wrote: > > So far, I've kept the test suites for the DeinProgramm stuff > separate. As to the stepper, the main problems in the past have > been with rendering, and I've tested that manually. But I'll take > up the suggestion and write some automated tests - thanks for > explaining! > > But I'm still unsure whether to check out tests into SVN (most of > the existing ones uses SchemeUnit). Should I? You can do that either in a new "tests/deinprogramm" collection, or in some "deinprogramm/whatever" subcollection. In any case, tell me about it so I know how to update the distribution specs. And keep in mind my comment too -- it's fine for your tests to rely on the stepper tests, but if it goes the otherway then the dependencies will get messed up. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From matthias at ccs.neu.edu Thu Mar 19 09:48:16 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Thu Mar 19 09:50:02 2009 Subject: [plt-dev] Stepper tests for DeinProgramm language levels? In-Reply-To: <18882.11834.217423.536195@winooski.ccs.neu.edu> References: <7E3BEBBD-7779-4B1A-B2D5-9B57D6B240D7@ccs.neu.edu> <18882.11834.217423.536195@winooski.ccs.neu.edu> Message-ID: <686F7B9F-BCFC-41DD-9F02-3D9F04166612@ccs.neu.edu> In the past we have not included collections that use SchemeUnit because it hasn't been integrated with the core yet. -- Matthias On Mar 19, 2009, at 7:36 AM, Eli Barzilay wrote: > On Mar 19, Michael Sperber wrote: >> >> So far, I've kept the test suites for the DeinProgramm stuff >> separate. As to the stepper, the main problems in the past have >> been with rendering, and I've tested that manually. But I'll take >> up the suggestion and write some automated tests - thanks for >> explaining! >> >> But I'm still unsure whether to check out tests into SVN (most of >> the existing ones uses SchemeUnit). Should I? > > You can do that either in a new "tests/deinprogramm" collection, or in > some "deinprogramm/whatever" subcollection. In any case, tell me > about it so I know how to update the distribution specs. > > And keep in mind my comment too -- it's fine for your tests to rely on > the stepper tests, but if it goes the otherway then the dependencies > will get messed up. > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli > Barzilay: > http://www.barzilay.org/ Maze is > Life! > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From eli at barzilay.org Thu Mar 19 09:56:04 2009 From: eli at barzilay.org (Eli Barzilay) Date: Thu Mar 19 09:56:07 2009 Subject: [plt-dev] Stepper tests for DeinProgramm language levels? In-Reply-To: <686F7B9F-BCFC-41DD-9F02-3D9F04166612@ccs.neu.edu> References: <7E3BEBBD-7779-4B1A-B2D5-9B57D6B240D7@ccs.neu.edu> <18882.11834.217423.536195@winooski.ccs.neu.edu> <686F7B9F-BCFC-41DD-9F02-3D9F04166612@ccs.neu.edu> Message-ID: <18882.20212.467881.663032@winooski.ccs.neu.edu> On Mar 19, Matthias Felleisen wrote: > > In the past we have not included collections that use SchemeUnit > because it hasn't been integrated with the core yet. -- Matthias They can be used in test collections, provided that the info file is set to avoid compiling them. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From mflatt at cs.utah.edu Thu Mar 19 09:56:49 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Thu Mar 19 09:56:57 2009 Subject: [plt-dev] Stepper tests for DeinProgramm language levels? In-Reply-To: <686F7B9F-BCFC-41DD-9F02-3D9F04166612@ccs.neu.edu> References: <7E3BEBBD-7779-4B1A-B2D5-9B57D6B240D7@ccs.neu.edu> <18882.11834.217423.536195@winooski.ccs.neu.edu> <686F7B9F-BCFC-41DD-9F02-3D9F04166612@ccs.neu.edu> Message-ID: <20090319135651.7EC5665008D@mail-svr1.cs.utah.edu> We do have tests in "collects/tests" that use SchemeUnit. (The test files are not compiled by setup-plt.) At Thu, 19 Mar 2009 09:48:16 -0400, Matthias Felleisen wrote: > > > In the past we have not included collections that use SchemeUnit > because it hasn't been integrated with the core yet. -- Matthias > > > > > > On Mar 19, 2009, at 7:36 AM, Eli Barzilay wrote: > > > On Mar 19, Michael Sperber wrote: > >> > >> So far, I've kept the test suites for the DeinProgramm stuff > >> separate. As to the stepper, the main problems in the past have > >> been with rendering, and I've tested that manually. But I'll take > >> up the suggestion and write some automated tests - thanks for > >> explaining! > >> > >> But I'm still unsure whether to check out tests into SVN (most of > >> the existing ones uses SchemeUnit). Should I? > > > > You can do that either in a new "tests/deinprogramm" collection, or in > > some "deinprogramm/whatever" subcollection. In any case, tell me > > about it so I know how to update the distribution specs. > > > > And keep in mind my comment too -- it's fine for your tests to rely on > > the stepper tests, but if it goes the otherway then the dependencies > > will get messed up. > > > > -- > > ((lambda (x) (x x)) (lambda (x) (x x))) Eli > > Barzilay: > > http://www.barzilay.org/ Maze is > > Life! > > _________________________________________________ > > For list-related administrative tasks: > > http://list.cs.brown.edu/mailman/listinfo/plt-dev > > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From kathryn.gray at cl.cam.ac.uk Thu Mar 19 11:38:12 2009 From: kathryn.gray at cl.cam.ac.uk (Kathryn Gray) Date: Thu Mar 19 11:38:31 2009 Subject: [plt-dev] Pre-Release Checklist for v4.1.5, second call In-Reply-To: References: Message-ID: <35E43224-748C-48F8-BA6D-CDA6412BC48B@cl.cam.ac.uk> On 19 Mar 2009, at 11:30:19, Eli Barzilay wrote: > * Kathy Gray > - ProfJ Tests > - Test Engine Tests Done. -Kathy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090319/16897282/attachment.html From clements at brinckerhoff.org Thu Mar 19 11:41:58 2009 From: clements at brinckerhoff.org (John Clements) Date: Thu Mar 19 11:42:30 2009 Subject: [plt-dev] Stepper tests for DeinProgramm language levels? In-Reply-To: <18882.20212.467881.663032@winooski.ccs.neu.edu> References: <7E3BEBBD-7779-4B1A-B2D5-9B57D6B240D7@ccs.neu.edu> <18882.11834.217423.536195@winooski.ccs.neu.edu> <686F7B9F-BCFC-41DD-9F02-3D9F04166612@ccs.neu.edu> <18882.20212.467881.663032@winooski.ccs.neu.edu> Message-ID: <209BA8BF-E89F-45EB-A057-1A3DB553C493@brinckerhoff.org> On Mar 19, 2009, at 6:56 AM, Eli Barzilay wrote: > On Mar 19, Matthias Felleisen wrote: >> >> In the past we have not included collections that use SchemeUnit >> because it hasn't been integrated with the core yet. -- Matthias > > They can be used in test collections, provided that the info file is > set to avoid compiling them. It'll mean another step in testing release bundles, though. I don't think I'm likely to make the stepper tests depend on SchemeUnit. 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/20090319/6e7c0261/smime-0001.bin From noelwelsh at gmail.com Thu Mar 19 12:03:24 2009 From: noelwelsh at gmail.com (Noel Welsh) Date: Thu Mar 19 12:03:44 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.1.5, second call In-Reply-To: References: Message-ID: On Thu, Mar 19, 2009 at 11:30 AM, Eli Barzilay wrote: > * Noel Welsh , Chongkai Zhu > ?- SRFI Tests > ?- Ensure that all claimed srfi's are in the bundle and they all load > ? ?into mzscheme or drscheme (as appropriate) DONE (though I'm not sure about the funky R6RS names, and what should be done with them.) N. From m.douglas.williams at gmail.com Thu Mar 19 12:35:05 2009 From: m.douglas.williams at gmail.com (Doug Williams) Date: Thu Mar 19 12:35:26 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.1.5, second call In-Reply-To: References: Message-ID: The plot tests and the plot extensions in the science collection all run as expected. Doug On Thu, Mar 19, 2009 at 5:30 AM, Eli Barzilay wrote: > Checklist items for the v4.1.5 release > (using the v4.1.4.900 alpha build) > > Search for your name to find relevant items, reply when you finish > an item (please indicate which item is done). Also, if you have > any commits that should have been merged, make sure that they're > in. > > Important: new builds are created without announcement, usually > whenever I see significant commits. If you need to commit changes, > please make sure you tell me to merge it to the release branch. > > --> Release candidates are at > --> http://pre.plt-scheme.org/release/installers > > Please use these installers (or source bundles) -- don't test from > your own svn chekout (don't test v4.1.5.1 by mistake!). To get > the tests directory in the normal release, you can do this: > cd .../collects > svn export http://svn.plt-scheme.org/plt/release/collects/tests > > ---------------------------------------------------------------------- > > *** Testing: > > * Kathy Gray > - ProfJ Tests > - Test Engine Tests > > * Noel Welsh , Chongkai Zhu > - SRFI Tests > - Ensure that all claimed srfi's are in the bundle and they all load > into mzscheme or drscheme (as appropriate) > > * Sam Tobin-Hochstadt > - Match Tests > - Typed Scheme Tests > > * Doug Williams > - Plot Tests > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > http://www.barzilay.org/ Maze is Life! > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090319/04d3919c/attachment.html From m.douglas.williams at gmail.com Thu Mar 19 13:04:22 2009 From: m.douglas.williams at gmail.com (Doug Williams) Date: Thu Mar 19 13:10:01 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.1.5, second call In-Reply-To: References: Message-ID: I am getting many warnings/errors from some of the PLaneT packages that I don't remember seeing in the past: compile: access from an uncertified context to unexported variable from module: "C:\Program Files\PLT\collects\scheme\private\stxloc.ss" setup-plt: error: during Building docs for C:\Documents and Settings\dwilliams\Application Data\PLT Scheme\planet\300\4.1.4.900\cache\cce\scheme.plt\1\3\manual.scrbl setup-plt: compile: access from an uncertified context to unexported variable from module: "C:\Program Files\PLT\collects\scheme\private\stxloc.ss" WARNING: collected information for key multiple times: (mod-path "(planet schematics/sake)"); values: #(# ("Build files") #t (mod-path "(planet schematics/sake)")) #(# ("The Sake API") #t (mod-path "(planet schematics/sake)")) WARNING: collected information for key multiple times: (index-entry (mod-path "(planet schematics/sake)")); values: (("(planet schematics/sake)") (#(struct:sized-element ... ...)) #) (("(planet schematics/sake)") (#(struct:sized-element ... ...)) #) WARNING: collected information for key multiple times: (mod-path "(planet schematics/sake)"); values: #(# ("Build files") #t (mod-path "(planet schematics/sake)")) #(# ("The Sake API") #t (mod-path "(planet schematics/sake)")) WARNING: collected information for key multiple times: (index-entry (mod-path "(planet schematics/sake)")); values: (("(planet schematics/sake)") (#(struct:sized-element ... ...)) #) (("(planet schematics/sake)") (#(struct:sized-element ... ...)) #) I cleared out my PLaneT cache prior to loading the new version, so some may be new versions of the packages. I'm not as concerned about the warnings as about the first ones that seem to be errors. Is this indicative of some problem? Doug On Thu, Mar 19, 2009 at 5:30 AM, Eli Barzilay wrote: > Checklist items for the v4.1.5 release > (using the v4.1.4.900 alpha build) > > Search for your name to find relevant items, reply when you finish > an item (please indicate which item is done). Also, if you have > any commits that should have been merged, make sure that they're > in. > > Important: new builds are created without announcement, usually > whenever I see significant commits. If you need to commit changes, > please make sure you tell me to merge it to the release branch. > > --> Release candidates are at > --> http://pre.plt-scheme.org/release/installers > > Please use these installers (or source bundles) -- don't test from > your own svn chekout (don't test v4.1.5.1 by mistake!). To get > the tests directory in the normal release, you can do this: > cd .../collects > svn export http://svn.plt-scheme.org/plt/release/collects/tests > > ---------------------------------------------------------------------- > > *** Testing: > > * Kathy Gray > - ProfJ Tests > - Test Engine Tests > > * Noel Welsh , Chongkai Zhu > - SRFI Tests > - Ensure that all claimed srfi's are in the bundle and they all load > into mzscheme or drscheme (as appropriate) > > * Sam Tobin-Hochstadt > - Match Tests > - Typed Scheme Tests > > * Doug Williams > - Plot Tests > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > http://www.barzilay.org/ Maze is Life! > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090319/6d49b98c/attachment.html From carl.eastlund at gmail.com Thu Mar 19 13:51:41 2009 From: carl.eastlund at gmail.com (Carl Eastlund) Date: Thu Mar 19 13:52:05 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.1.5, second call In-Reply-To: References: Message-ID: <990e0c030903191051o5fe835b6xdf7a170a78a68c38@mail.gmail.com> Hmm. I believe I started getting this kind of error after recent changes to the sandbox library, when I used sandboxes for examples in Scribble documentation. I stopped getting the error when I started using call-with-trusted-sandbox-configuration to construct the appropriate sandbox. In fact, (planet cce/scheme/sandbox) exports make-trusted-evaluator, make-trusted-module-evaluator, make-scribble-evaluator, and make-scribble-module-evaluator that are designed to work around this bug (and one other peculiarity of sandboxes for Scribble examples). Give either method of making trusted sandboxes a try, if your packages use sandboxed examples, and see if the problem goes away. --Carl On Thu, Mar 19, 2009 at 1:04 PM, Doug Williams wrote: > I am getting many warnings/errors from some of the PLaneT packages that I > don't remember seeing in the past: > > compile: access from an uncertified context to unexported variable from > module: "C:\Program Files\PLT\collects\scheme\private\stxloc.ss" > setup-plt: error: during Building docs for C:\Documents and > Settings\dwilliams\Application Data\PLT > Scheme\planet\300\4.1.4.900\cache\cce\scheme.plt\1\3\manual.scrbl > setup-plt:?? compile: access from an uncertified context to unexported > variable from module: "C:\Program > Files\PLT\collects\scheme\private\stxloc.ss" > WARNING: collected information for key multiple times: (mod-path "(planet > schematics/sake)"); values: #(# Settings\dwilliams\Application Data\PLT > Scheme\planet\300\4.1.4.900\cache\schematics\sake.plt\1\0\doc\sake\Build_files.html> > ("Build files") #t (mod-path "(planet schematics/sake)")) > #(# Scheme\planet\300\4.1.4.900\cache\schematics\sake.plt\1\0\doc\sake\The_Sake_API.html> > ("The Sake API") #t (mod-path "(planet schematics/sake)")) > WARNING: collected information for key multiple times: (index-entry > (mod-path "(planet schematics/sake)")); values: (("(planet > schematics/sake)") (#(struct:sized-element ... ...)) > #) (("(planet schematics/sake)") > (#(struct:sized-element ... ...)) #) > WARNING: collected information for key multiple times: (mod-path "(planet > schematics/sake)"); values: #(# Settings\dwilliams\Application Data\PLT > Scheme\planet\300\4.1.4.900\cache\schematics\sake.plt\1\0\doc\sake\Build_files.html> > ("Build files") #t (mod-path "(planet schematics/sake)")) > #(# Scheme\planet\300\4.1.4.900\cache\schematics\sake.plt\1\0\doc\sake\The_Sake_API.html> > ("The Sake API") #t (mod-path "(planet schematics/sake)")) > WARNING: collected information for key multiple times: (index-entry > (mod-path "(planet schematics/sake)")); values: (("(planet > schematics/sake)") (#(struct:sized-element ... ...)) > #) (("(planet schematics/sake)") > (#(struct:sized-element ... ...)) #) > > I cleared out my PLaneT cache prior to loading the new version, so some may > be new versions of the packages. I'm not as concerned about the warnings as > about the first ones that seem to be errors. > > Is this indicative of some problem? > > Doug > > > On Thu, Mar 19, 2009 at 5:30 AM, Eli Barzilay wrote: >> >> Checklist items for the v4.1.5 release >> ?(using the v4.1.4.900 alpha build) >> >> Search for your name to find relevant items, reply when you finish >> an item (please indicate which item is done). ?Also, if you have >> any commits that should have been merged, make sure that they're >> in. >> >> Important: new builds are created without announcement, usually >> whenever I see significant commits. ?If you need to commit changes, >> please make sure you tell me to merge it to the release branch. >> >> --> Release candidates are at >> --> ? http://pre.plt-scheme.org/release/installers >> >> Please use these installers (or source bundles) -- don't test from >> your own svn chekout (don't test v4.1.5.1 by mistake!). ?To get >> the tests directory in the normal release, you can do this: >> ?cd .../collects >> ?svn export http://svn.plt-scheme.org/plt/release/collects/tests >> >> ---------------------------------------------------------------------- >> >> *** Testing: >> >> * Kathy Gray >> ?- ProfJ Tests >> ?- Test Engine Tests >> >> * Noel Welsh , Chongkai Zhu >> ?- SRFI Tests >> ?- Ensure that all claimed srfi's are in the bundle and they all load >> ? ?into mzscheme or drscheme (as appropriate) >> >> * Sam Tobin-Hochstadt >> ?- Match Tests >> ?- Typed Scheme Tests >> >> * Doug Williams >> ?- Plot Tests >> >> -- >> ? ? ? ? ?((lambda (x) (x x)) (lambda (x) (x x))) ? ? ? ? ?Eli Barzilay: >> ? ? ? ? ? ? ? ? ?http://www.barzilay.org/ ? ? ? ? ? ? ? ? Maze is Life! From m.douglas.williams at gmail.com Thu Mar 19 14:07:40 2009 From: m.douglas.williams at gmail.com (Doug Williams) Date: Thu Mar 19 14:08:03 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.1.5, second call In-Reply-To: <990e0c030903191051o5fe835b6xdf7a170a78a68c38@mail.gmail.com> References: <990e0c030903191051o5fe835b6xdf7a170a78a68c38@mail.gmail.com> Message-ID: Carl, it looks like the error came from your scheme.plt package. I'm not sophisticated enough yet to need sandboxes - particularly in a scribble manual. Doug On Thu, Mar 19, 2009 at 11:51 AM, Carl Eastlund wrote: > Hmm. I believe I started getting this kind of error after recent > changes to the sandbox library, when I used sandboxes for examples in > Scribble documentation. I stopped getting the error when I started > using call-with-trusted-sandbox-configuration to construct the > appropriate sandbox. In fact, (planet cce/scheme/sandbox) exports > make-trusted-evaluator, make-trusted-module-evaluator, > make-scribble-evaluator, and make-scribble-module-evaluator that are > designed to work around this bug (and one other peculiarity of > sandboxes for Scribble examples). > > Give either method of making trusted sandboxes a try, if your packages > use sandboxed examples, and see if the problem goes away. > > --Carl > > On Thu, Mar 19, 2009 at 1:04 PM, Doug Williams > wrote: > > I am getting many warnings/errors from some of the PLaneT packages that I > > don't remember seeing in the past: > > > > compile: access from an uncertified context to unexported variable from > > module: "C:\Program Files\PLT\collects\scheme\private\stxloc.ss" > > setup-plt: error: during Building docs for C:\Documents and > > Settings\dwilliams\Application Data\PLT > > Scheme\planet\300\4.1.4.900\cache\cce\scheme.plt\1\3\manual.scrbl > > setup-plt: compile: access from an uncertified context to unexported > > variable from module: "C:\Program > > Files\PLT\collects\scheme\private\stxloc.ss" > > WARNING: collected information for key multiple times: (mod-path "(planet > > schematics/sake)"); values: #(# > Settings\dwilliams\Application Data\PLT > > > Scheme\planet\300\4.1.4.900\cache\schematics\sake.plt\1\0\doc\sake\Build_files.html> > > ("Build files") #t (mod-path "(planet schematics/sake)")) > > #(# > > Scheme\planet\300\4.1.4.900\cache\schematics\sake.plt\1\0\doc\sake\The_Sake_API.html> > > ("The Sake API") #t (mod-path "(planet schematics/sake)")) > > WARNING: collected information for key multiple times: (index-entry > > (mod-path "(planet schematics/sake)")); values: (("(planet > > schematics/sake)") (#(struct:sized-element ... ...)) > > #) (("(planet schematics/sake)") > > (#(struct:sized-element ... ...)) #) > > WARNING: collected information for key multiple times: (mod-path "(planet > > schematics/sake)"); values: #(# > Settings\dwilliams\Application Data\PLT > > > Scheme\planet\300\4.1.4.900\cache\schematics\sake.plt\1\0\doc\sake\Build_files.html> > > ("Build files") #t (mod-path "(planet schematics/sake)")) > > #(# > > Scheme\planet\300\4.1.4.900\cache\schematics\sake.plt\1\0\doc\sake\The_Sake_API.html> > > ("The Sake API") #t (mod-path "(planet schematics/sake)")) > > WARNING: collected information for key multiple times: (index-entry > > (mod-path "(planet schematics/sake)")); values: (("(planet > > schematics/sake)") (#(struct:sized-element ... ...)) > > #) (("(planet schematics/sake)") > > (#(struct:sized-element ... ...)) #) > > > > I cleared out my PLaneT cache prior to loading the new version, so some > may > > be new versions of the packages. I'm not as concerned about the warnings > as > > about the first ones that seem to be errors. > > > > Is this indicative of some problem? > > > > Doug > > > > > > On Thu, Mar 19, 2009 at 5:30 AM, Eli Barzilay wrote: > >> > >> Checklist items for the v4.1.5 release > >> (using the v4.1.4.900 alpha build) > >> > >> Search for your name to find relevant items, reply when you finish > >> an item (please indicate which item is done). Also, if you have > >> any commits that should have been merged, make sure that they're > >> in. > >> > >> Important: new builds are created without announcement, usually > >> whenever I see significant commits. If you need to commit changes, > >> please make sure you tell me to merge it to the release branch. > >> > >> --> Release candidates are at > >> --> http://pre.plt-scheme.org/release/installers > >> > >> Please use these installers (or source bundles) -- don't test from > >> your own svn chekout (don't test v4.1.5.1 by mistake!). To get > >> the tests directory in the normal release, you can do this: > >> cd .../collects > >> svn export http://svn.plt-scheme.org/plt/release/collects/tests > >> > >> ---------------------------------------------------------------------- > >> > >> *** Testing: > >> > >> * Kathy Gray > >> - ProfJ Tests > >> - Test Engine Tests > >> > >> * Noel Welsh , Chongkai Zhu > >> - SRFI Tests > >> - Ensure that all claimed srfi's are in the bundle and they all load > >> into mzscheme or drscheme (as appropriate) > >> > >> * Sam Tobin-Hochstadt > >> - Match Tests > >> - Typed Scheme Tests > >> > >> * Doug Williams > >> - Plot Tests > >> > >> -- > >> ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > >> http://www.barzilay.org/ Maze is Life! > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090319/2b88527f/attachment.html From carl.eastlund at gmail.com Thu Mar 19 14:10:44 2009 From: carl.eastlund at gmail.com (Carl Eastlund) Date: Thu Mar 19 14:11:02 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.1.5, second call In-Reply-To: References: <990e0c030903191051o5fe835b6xdf7a170a78a68c38@mail.gmail.com> Message-ID: <990e0c030903191110r364f4ac4h942d66fcfc1f189e@mail.gmail.com> Oh, hey, that is my package. Sorry, I saw "williams" in the path and leapt to a conclusion without noticing it wasn't the package owner name. I'll look into it. --Carl On Thu, Mar 19, 2009 at 2:07 PM, Doug Williams wrote: > Carl, it looks like the error came from your scheme.plt package. I'm not > sophisticated enough yet to need sandboxes - particularly in a scribble > manual. > > Doug > > On Thu, Mar 19, 2009 at 11:51 AM, Carl Eastlund > wrote: >> >> Hmm. ?I believe I started getting this kind of error after recent >> changes to the sandbox library, when I used sandboxes for examples in >> Scribble documentation. ?I stopped getting the error when I started >> using call-with-trusted-sandbox-configuration to construct the >> appropriate sandbox. ?In fact, (planet cce/scheme/sandbox) exports >> make-trusted-evaluator, make-trusted-module-evaluator, >> make-scribble-evaluator, and make-scribble-module-evaluator that are >> designed to work around this bug (and one other peculiarity of >> sandboxes for Scribble examples). >> >> Give either method of making trusted sandboxes a try, if your packages >> use sandboxed examples, and see if the problem goes away. >> >> --Carl >> >> On Thu, Mar 19, 2009 at 1:04 PM, Doug Williams >> wrote: >> > I am getting many warnings/errors from some of the PLaneT packages that >> > I >> > don't remember seeing in the past: >> > >> > compile: access from an uncertified context to unexported variable from >> > module: "C:\Program Files\PLT\collects\scheme\private\stxloc.ss" >> > setup-plt: error: during Building docs for C:\Documents and >> > Settings\dwilliams\Application Data\PLT >> > Scheme\planet\300\4.1.4.900\cache\cce\scheme.plt\1\3\manual.scrbl >> > setup-plt:?? compile: access from an uncertified context to unexported >> > variable from module: "C:\Program >> > Files\PLT\collects\scheme\private\stxloc.ss" >> > WARNING: collected information for key multiple times: (mod-path >> > "(planet >> > schematics/sake)"); values: #(#> > Settings\dwilliams\Application Data\PLT >> > >> > Scheme\planet\300\4.1.4.900\cache\schematics\sake.plt\1\0\doc\sake\Build_files.html> >> > ("Build files") #t (mod-path "(planet schematics/sake)")) >> > #(#> > >> > Scheme\planet\300\4.1.4.900\cache\schematics\sake.plt\1\0\doc\sake\The_Sake_API.html> >> > ("The Sake API") #t (mod-path "(planet schematics/sake)")) >> > WARNING: collected information for key multiple times: (index-entry >> > (mod-path "(planet schematics/sake)")); values: (("(planet >> > schematics/sake)") (#(struct:sized-element ... ...)) >> > #) (("(planet schematics/sake)") >> > (#(struct:sized-element ... ...)) #) >> > WARNING: collected information for key multiple times: (mod-path >> > "(planet >> > schematics/sake)"); values: #(#> > Settings\dwilliams\Application Data\PLT >> > >> > Scheme\planet\300\4.1.4.900\cache\schematics\sake.plt\1\0\doc\sake\Build_files.html> >> > ("Build files") #t (mod-path "(planet schematics/sake)")) >> > #(#> > >> > Scheme\planet\300\4.1.4.900\cache\schematics\sake.plt\1\0\doc\sake\The_Sake_API.html> >> > ("The Sake API") #t (mod-path "(planet schematics/sake)")) >> > WARNING: collected information for key multiple times: (index-entry >> > (mod-path "(planet schematics/sake)")); values: (("(planet >> > schematics/sake)") (#(struct:sized-element ... ...)) >> > #) (("(planet schematics/sake)") >> > (#(struct:sized-element ... ...)) #) >> > >> > I cleared out my PLaneT cache prior to loading the new version, so some >> > may >> > be new versions of the packages. I'm not as concerned about the warnings >> > as >> > about the first ones that seem to be errors. >> > >> > Is this indicative of some problem? >> > >> > Doug From carl.eastlund at gmail.com Thu Mar 19 14:14:36 2009 From: carl.eastlund at gmail.com (Carl Eastlund) Date: Thu Mar 19 14:14:54 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.1.5, second call In-Reply-To: <990e0c030903191110r364f4ac4h942d66fcfc1f189e@mail.gmail.com> References: <990e0c030903191051o5fe835b6xdf7a170a78a68c38@mail.gmail.com> <990e0c030903191110r364f4ac4h942d66fcfc1f189e@mail.gmail.com> Message-ID: <990e0c030903191114w538feaffl537644af260619da@mail.gmail.com> Oh, you're using an old version of my package. I don't know what you have that depends on cce/scheme:1:3, but please notify the appropriate author to upgrade their dependency to cce/scheme:4:1. The old version will definitely run into this bug. --Carl On Thu, Mar 19, 2009 at 2:10 PM, Carl Eastlund wrote: > Oh, hey, that is my package. ?Sorry, I saw "williams" in the path and > leapt to a conclusion without noticing it wasn't the package owner > name. ?I'll look into it. > > --Carl > > On Thu, Mar 19, 2009 at 2:07 PM, Doug Williams > wrote: >> Carl, it looks like the error came from your scheme.plt package. I'm not >> sophisticated enough yet to need sandboxes - particularly in a scribble >> manual. >> >> Doug From m.douglas.williams at gmail.com Thu Mar 19 14:19:18 2009 From: m.douglas.williams at gmail.com (Doug Williams) Date: Thu Mar 19 14:19:38 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.1.5, second call In-Reply-To: <990e0c030903191114w538feaffl537644af260619da@mail.gmail.com> References: <990e0c030903191051o5fe835b6xdf7a170a78a68c38@mail.gmail.com> <990e0c030903191110r364f4ac4h942d66fcfc1f189e@mail.gmail.com> <990e0c030903191114w538feaffl537644af260619da@mail.gmail.com> Message-ID: It seems to be one of the sxml or ssax packages that eventually leads to the error message. They lead to many packages being downloaded. On Thu, Mar 19, 2009 at 12:14 PM, Carl Eastlund wrote: > Oh, you're using an old version of my package. I don't know what you > have that depends on cce/scheme:1:3, but please notify the appropriate > author to upgrade their dependency to cce/scheme:4:1. The old version > will definitely run into this bug. > > --Carl > > On Thu, Mar 19, 2009 at 2:10 PM, Carl Eastlund > wrote: > > Oh, hey, that is my package. Sorry, I saw "williams" in the path and > > leapt to a conclusion without noticing it wasn't the package owner > > name. I'll look into it. > > > > --Carl > > > > On Thu, Mar 19, 2009 at 2:07 PM, Doug Williams > > wrote: > >> Carl, it looks like the error came from your scheme.plt package. I'm not > >> sophisticated enough yet to need sandboxes - particularly in a scribble > >> manual. > >> > >> Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090319/7df7e9dd/attachment-0001.htm From sperber at deinprogramm.de Thu Mar 19 14:21:18 2009 From: sperber at deinprogramm.de (Michael Sperber) Date: Thu Mar 19 14:21:36 2009 Subject: [plt-dev] Stepper tests for DeinProgramm language levels? In-Reply-To: <18882.20212.467881.663032@winooski.ccs.neu.edu> (Eli Barzilay's message of "Thu, 19 Mar 2009 09:56:04 -0400") References: <7E3BEBBD-7779-4B1A-B2D5-9B57D6B240D7@ccs.neu.edu> <18882.11834.217423.536195@winooski.ccs.neu.edu> <686F7B9F-BCFC-41DD-9F02-3D9F04166612@ccs.neu.edu> <18882.20212.467881.663032@winooski.ccs.neu.edu> Message-ID: It really sounds as though it would be better if I continued to maintain our tests separately. If you think otherwise, let me know. -- Cheers =8-} Mike Friede, V?lkerverst?ndigung und ?berhaupt blabla From robby at eecs.northwestern.edu Thu Mar 19 14:21:46 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Thu Mar 19 14:22:21 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.1.5, second call In-Reply-To: References: <990e0c030903191051o5fe835b6xdf7a170a78a68c38@mail.gmail.com> <990e0c030903191110r364f4ac4h942d66fcfc1f189e@mail.gmail.com> <990e0c030903191114w538feaffl537644af260619da@mail.gmail.com> Message-ID: <932b2f1f0903191121m69547686k8895db0c264e9e59@mail.gmail.com> Carl: is it possible to release 1.4 of your package that just deals with this bug? Or is there no fix to the bug that doesn't also break the interface somehow? Robby On Thu, Mar 19, 2009 at 1:19 PM, Doug Williams wrote: > It seems to be one of the sxml or ssax packages that eventually leads to the > error message.? They lead to many packages being downloaded. > > On Thu, Mar 19, 2009 at 12:14 PM, Carl Eastlund > wrote: >> >> Oh, you're using an old version of my package. ?I don't know what you >> have that depends on cce/scheme:1:3, but please notify the appropriate >> author to upgrade their dependency to cce/scheme:4:1. ?The old version >> will definitely run into this bug. >> >> --Carl >> >> On Thu, Mar 19, 2009 at 2:10 PM, Carl Eastlund >> wrote: >> > Oh, hey, that is my package. ?Sorry, I saw "williams" in the path and >> > leapt to a conclusion without noticing it wasn't the package owner >> > name. ?I'll look into it. >> > >> > --Carl >> > >> > On Thu, Mar 19, 2009 at 2:07 PM, Doug Williams >> > wrote: >> >> Carl, it looks like the error came from your scheme.plt package. I'm >> >> not >> >> sophisticated enough yet to need sandboxes - particularly in a scribble >> >> manual. >> >> >> >> Doug > > > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > > From carl.eastlund at gmail.com Thu Mar 19 14:44:28 2009 From: carl.eastlund at gmail.com (Carl Eastlund) Date: Thu Mar 19 14:52:07 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.1.5, second call In-Reply-To: <932b2f1f0903191121m69547686k8895db0c264e9e59@mail.gmail.com> References: <990e0c030903191051o5fe835b6xdf7a170a78a68c38@mail.gmail.com> <990e0c030903191110r364f4ac4h942d66fcfc1f189e@mail.gmail.com> <990e0c030903191114w538feaffl537644af260619da@mail.gmail.com> <932b2f1f0903191121m69547686k8895db0c264e9e59@mail.gmail.com> Message-ID: <990e0c030903191144s1b22a13eh44f9af4394240c3f@mail.gmail.com> I can release a 1.4, probably, though to make sure it really works means going through... let's see... probably at least a half dozen setup-plt runs including rebuild of Scribble docs and search index. (One to remove my current build of the package, one to add version 1.3 and duplicate the bug, one with the fix to make sure it works, one to remove that, one to add and test it from the built .plt package instead of the development link, one to remove that, and one to put my normal version back. That's seven.) If we run into other dependencies on old versions of my code, I may have to repeat this process for major versions 2 and 3 of cce/scheme.plt as well, plus old versions of fasttest and dracula. And while I am doing this, I can't do anything else with DrScheme because the code won't load (I need Dracula, which needs all of these packages). I can't even run a different version of DrScheme, because they all share one set of development links. I really don't want to have to maintain outdated packages this way. I would much rather deprecate old versions, and leave it up to other authors to keep their code up to date too by updating old versions as needed. This way no one would have to update more than one version of each package when things go out of date. If we have some pressing need for (planet cce/scheme:1) to work that is greater than other obsolete dependencies, I can release a fixed version 1.4, but it would just be a band-aid on the general issue of obsolete planet/PLT dependencies. If this is just one instance among many, I think it is up to the ssax/sxml author(s) to upgrade to a newer version of my package. I do wish there were a way to specify an upper limit on the version number with which a package is compatible, just like we have a lower limit. That way users would get an error message stating clearly that the cce/scheme:1:3 dependency was broken in PLT 4.1.5, instead of an error about uncertified contexts. I could remove cce/scheme:1:3 from the server (make it unavailable), but that breaks code for users still in 4.1.4 or earlier who can use it without problem. Right now all I can do is leave the current error message and explain it to users when it comes up. --Carl On Thu, Mar 19, 2009 at 2:21 PM, Robby Findler wrote: > Carl: is it possible to release 1.4 of your package that just deals > with this bug? Or is there no fix to the bug that doesn't also break > the interface somehow? > > Robby > > On Thu, Mar 19, 2009 at 1:19 PM, Doug Williams > wrote: >> It seems to be one of the sxml or ssax packages that eventually leads to the >> error message.? They lead to many packages being downloaded. >> >> On Thu, Mar 19, 2009 at 12:14 PM, Carl Eastlund >> wrote: >>> >>> Oh, you're using an old version of my package. ?I don't know what you >>> have that depends on cce/scheme:1:3, but please notify the appropriate >>> author to upgrade their dependency to cce/scheme:4:1. ?The old version >>> will definitely run into this bug. >>> >>> --Carl >>> >>> On Thu, Mar 19, 2009 at 2:10 PM, Carl Eastlund >>> wrote: >>> > Oh, hey, that is my package. ?Sorry, I saw "williams" in the path and >>> > leapt to a conclusion without noticing it wasn't the package owner >>> > name. ?I'll look into it. >>> > >>> > --Carl >>> > >>> > On Thu, Mar 19, 2009 at 2:07 PM, Doug Williams >>> > wrote: >>> >> Carl, it looks like the error came from your scheme.plt package. I'm >>> >> not >>> >> sophisticated enough yet to need sandboxes - particularly in a scribble >>> >> manual. >>> >> >>> >> Doug From robby at eecs.northwestern.edu Thu Mar 19 14:54:25 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Thu Mar 19 14:54:43 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.1.5, second call In-Reply-To: <990e0c030903191144s1b22a13eh44f9af4394240c3f@mail.gmail.com> References: <990e0c030903191051o5fe835b6xdf7a170a78a68c38@mail.gmail.com> <990e0c030903191110r364f4ac4h942d66fcfc1f189e@mail.gmail.com> <990e0c030903191114w538feaffl537644af260619da@mail.gmail.com> <932b2f1f0903191121m69547686k8895db0c264e9e59@mail.gmail.com> <990e0c030903191144s1b22a13eh44f9af4394240c3f@mail.gmail.com> Message-ID: <932b2f1f0903191154y56650d9i2cfc6996a82b5870@mail.gmail.com> On Thu, Mar 19, 2009 at 1:44 PM, Carl Eastlund wrote: > I do wish there were a way to specify an upper limit on the version > number with which a package is compatible, just like we have a lower > limit. ?That way users would get an error message stating clearly that > the cce/scheme:1:3 dependency was broken in PLT 4.1.5, instead of an > error about uncertified contexts. ?I could remove cce/scheme:1:3 from > the server (make it unavailable), but that breaks code for users still > in 4.1.4 or earlier who can use it without problem. ?Right now all I > can do is leave the current error message and explain it to users when > it comes up. Oh, if that would solve the problem, then yes, that sounds better. Robby From carl.eastlund at gmail.com Thu Mar 19 15:06:00 2009 From: carl.eastlund at gmail.com (Carl Eastlund) Date: Thu Mar 19 15:06:19 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.1.5, second call In-Reply-To: <932b2f1f0903191154y56650d9i2cfc6996a82b5870@mail.gmail.com> References: <990e0c030903191051o5fe835b6xdf7a170a78a68c38@mail.gmail.com> <990e0c030903191110r364f4ac4h942d66fcfc1f189e@mail.gmail.com> <990e0c030903191114w538feaffl537644af260619da@mail.gmail.com> <932b2f1f0903191121m69547686k8895db0c264e9e59@mail.gmail.com> <990e0c030903191144s1b22a13eh44f9af4394240c3f@mail.gmail.com> <932b2f1f0903191154y56650d9i2cfc6996a82b5870@mail.gmail.com> Message-ID: <990e0c030903191206w2aaf4f34k82f50f3fa679d780@mail.gmail.com> On Thu, Mar 19, 2009 at 2:54 PM, Robby Findler wrote: > On Thu, Mar 19, 2009 at 1:44 PM, Carl Eastlund wrote: >> I do wish there were a way to specify an upper limit on the version >> number with which a package is compatible, just like we have a lower >> limit. ?That way users would get an error message stating clearly that >> the cce/scheme:1:3 dependency was broken in PLT 4.1.5, instead of an >> error about uncertified contexts. ?I could remove cce/scheme:1:3 from >> the server (make it unavailable), but that breaks code for users still >> in 4.1.4 or earlier who can use it without problem. ?Right now all I >> can do is leave the current error message and explain it to users when >> it comes up. > > Oh, if that would solve the problem, then yes, that sounds better. Which of the three alternatives did you mean? The only one that looks like a complete solution to me (upper limits on PLT version numbers for planet packages) is currently unimplemented, and I doubt it would get into the release even if someone wrote it right now. The other two leave some subset of users unsatisfied (either without code or without a useful error message). I mean, realistically I probably have to choose the last option and just explain the error message as people run into it, but I don't feel that this truly solves the problem. -- Carl Eastlund From robby at eecs.northwestern.edu Thu Mar 19 15:13:19 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Thu Mar 19 15:13:36 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.1.5, second call In-Reply-To: <990e0c030903191206w2aaf4f34k82f50f3fa679d780@mail.gmail.com> References: <990e0c030903191051o5fe835b6xdf7a170a78a68c38@mail.gmail.com> <990e0c030903191110r364f4ac4h942d66fcfc1f189e@mail.gmail.com> <990e0c030903191114w538feaffl537644af260619da@mail.gmail.com> <932b2f1f0903191121m69547686k8895db0c264e9e59@mail.gmail.com> <990e0c030903191144s1b22a13eh44f9af4394240c3f@mail.gmail.com> <932b2f1f0903191154y56650d9i2cfc6996a82b5870@mail.gmail.com> <990e0c030903191206w2aaf4f34k82f50f3fa679d780@mail.gmail.com> Message-ID: <932b2f1f0903191213x4d702b05l9c00e10df84190f3@mail.gmail.com> On Thu, Mar 19, 2009 at 2:06 PM, Carl Eastlund wrote: > On Thu, Mar 19, 2009 at 2:54 PM, Robby Findler > wrote: >> On Thu, Mar 19, 2009 at 1:44 PM, Carl Eastlund wrote: >>> I do wish there were a way to specify an upper limit on the version >>> number with which a package is compatible, The quoted thing above would be nice to have and seems to solve the problem better. From carl.eastlund at gmail.com Thu Mar 19 15:15:26 2009 From: carl.eastlund at gmail.com (Carl Eastlund) Date: Thu Mar 19 15:15:46 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.1.5, second call In-Reply-To: <932b2f1f0903191213x4d702b05l9c00e10df84190f3@mail.gmail.com> References: <990e0c030903191110r364f4ac4h942d66fcfc1f189e@mail.gmail.com> <990e0c030903191114w538feaffl537644af260619da@mail.gmail.com> <932b2f1f0903191121m69547686k8895db0c264e9e59@mail.gmail.com> <990e0c030903191144s1b22a13eh44f9af4394240c3f@mail.gmail.com> <932b2f1f0903191154y56650d9i2cfc6996a82b5870@mail.gmail.com> <990e0c030903191206w2aaf4f34k82f50f3fa679d780@mail.gmail.com> <932b2f1f0903191213x4d702b05l9c00e10df84190f3@mail.gmail.com> Message-ID: <990e0c030903191215g121c6daao8e886b9938a925c2@mail.gmail.com> On Thu, Mar 19, 2009 at 3:13 PM, Robby Findler wrote: > On Thu, Mar 19, 2009 at 2:06 PM, Carl Eastlund wrote: >> On Thu, Mar 19, 2009 at 2:54 PM, Robby Findler >> wrote: >>> On Thu, Mar 19, 2009 at 1:44 PM, Carl Eastlund wrote: >>>> I do wish there were a way to specify an upper limit on the version >>>> number with which a package is compatible, > > The quoted thing above would be nice to have and seems to solve the > problem better. Ok. I'll file a Trac ticket for the package with the outdated dependency for now, and add appropriate version limits for my own old packages as soon as Planet supports them. -- Carl Eastlund From eli at barzilay.org Thu Mar 19 15:39:42 2009 From: eli at barzilay.org (Eli Barzilay) Date: Thu Mar 19 15:40:05 2009 Subject: [plt-dev] Stepper tests for DeinProgramm language levels? In-Reply-To: References: <7E3BEBBD-7779-4B1A-B2D5-9B57D6B240D7@ccs.neu.edu> <18882.11834.217423.536195@winooski.ccs.neu.edu> <686F7B9F-BCFC-41DD-9F02-3D9F04166612@ccs.neu.edu> <18882.20212.467881.663032@winooski.ccs.neu.edu> Message-ID: <18882.40830.828916.93296@winooski.ccs.neu.edu> On Mar 19, Michael Sperber wrote: > > It really sounds as though it would be better if I continued to > maintain our tests separately. If you think otherwise, let me know. There is no problem including them. The only thing is that I'll need to know where they are so they can be omitted from the usual (non-"full") distributions. The thing that would create a mess is if your tests were getting to be an actual part of the stepper tests: the stepper is part of the "drscheme" distribution, and your collection is part of the bigger "plt" distribution -- the first is not really made, but it's there to ensure that things don't get too tangled (by verifying that there are no dependencies from the "dr" distro outside). So if/when things move to separate packages, such dependencies mean that more code gets into the drscheme package. (The stepper collection should also be out of the "dr" bubble, but it's too tangled in.) The bottom line is that if your tests only use code that John's tests provide then there is no problem. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From mflatt at cs.utah.edu Thu Mar 19 16:31:00 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Thu Mar 19 16:31:18 2009 Subject: [plt-dev] syntax-local-value and identifier-mappings In-Reply-To: <63bb19ae0903181520s1b7f49a1t5a91c3cae218c1c9@mail.gmail.com> References: <63bb19ae0903091315jee5ad88la8c90254c9e6604b@mail.gmail.com> <20090310002216.7CD5F6500A2@mail-svr1.cs.utah.edu> <63bb19ae0903091733l6f8797cao2b8304f6f306a321@mail.gmail.com> <20090318214816.561416500AE@mail-svr1.cs.utah.edu> <63bb19ae0903181520s1b7f49a1t5a91c3cae218c1c9@mail.gmail.com> Message-ID: <20090319203100.8E9336500A8@mail-svr1.cs.utah.edu> At Wed, 18 Mar 2009 18:20:42 -0400, Sam TH wrote: > I vote for the non-recursive version of `syntax-local-value' It's `syntax-local-value/immediate' in v4.1.5.3 in SVN. A transformer binding to a rename transformer still installs `free-identifier=?' mappings, and `provide' now replaces a rename-transformer export with the target of the rename to make `free-identifier=?' work as expected across module boundaries. All of this machinery can now be disabled for a given rename transformer by attaching a 'not-free-identifier=? syntax property to the target identifier; you'll want to do that for the bindings that Typed Scheme generates, since the choice of rename target needs to be delayed. Finally, I've added `prop:rename-transformer' and `prop:set!-transformer', which make it easier to create extended rename or assignment transformers. From carl.eastlund at gmail.com Thu Mar 19 16:45:36 2009 From: carl.eastlund at gmail.com (Carl Eastlund) Date: Thu Mar 19 16:45:55 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.1.5, second call In-Reply-To: <990e0c030903191215g121c6daao8e886b9938a925c2@mail.gmail.com> References: <990e0c030903191110r364f4ac4h942d66fcfc1f189e@mail.gmail.com> <990e0c030903191114w538feaffl537644af260619da@mail.gmail.com> <932b2f1f0903191121m69547686k8895db0c264e9e59@mail.gmail.com> <990e0c030903191144s1b22a13eh44f9af4394240c3f@mail.gmail.com> <932b2f1f0903191154y56650d9i2cfc6996a82b5870@mail.gmail.com> <990e0c030903191206w2aaf4f34k82f50f3fa679d780@mail.gmail.com> <932b2f1f0903191213x4d702b05l9c00e10df84190f3@mail.gmail.com> <990e0c030903191215g121c6daao8e886b9938a925c2@mail.gmail.com> Message-ID: <990e0c030903191345j702585eu5ced04a8d40918e5@mail.gmail.com> On Thu, Mar 19, 2009 at 3:15 PM, Carl Eastlund wrote: > > Ok. ?I'll file a Trac ticket for the package with the outdated > dependency for now, and add appropriate version limits for my own old > packages as soon as Planet supports them. Even better, the dependency turned out to be in galore.plt; I have access to the source code. (I suppose this should be unsurprising; not too many other people probably write source code that depends on early versions of my package.) I have fixed the dependency and asked Jens to release a new version of the package. Once it goes out this particular bug should be fixed (at least, once you remove the old cce/scheme and soegaard/galore, run planet clearlinks, and setup-plt). -- Carl Eastlund From eli at barzilay.org Thu Mar 19 20:38:34 2009 From: eli at barzilay.org (Eli Barzilay) Date: Thu Mar 19 20:39:05 2009 Subject: [plt-dev] Release Announcement for v4.1.5, third call Message-ID: The release announcement sketch that I have so far is below. I didn't get any additional edits. Specific people: * Stevie: Unit contracts, region contract, etc -- this should definitely be blurbed * Robby: are there any Redex news? ---------------------------------------------------------------------- * Web Server: - new URL-based dispatching library `web-server/dispatch', - customizable continuation serialization policies for the stateless web language `web-server/stuffers', - abstraction of serve/servlet to build simpler dispatchers `web-server/servlet-env', - HTTP Digest authentication support `web-server/http/digest-auth', - built-in cookie support in `web-server/http/cookie' and `web-server/http/cookie-parse', - highlighting and pretty-printing of errors in Xexpr constructions, - load control dispatcher for limit concurrent sessions `web-server/dispatchers/limit'. * Scribble: - Literate programming is now available using the new `scribble/lp' language. - A new `at-exp' language makes it convenient to use the scribble reader's @-expressions for general code. - The `scribble/text' preprocessor language has been extended to deal with indentation and other formatting issues. - The "scribble" command-line tool accepts a `--pdf' flag to render PDFs (via pdflatex). * DrScheme now provides feedback when PLaneT downloads and installs new packages. * Language levels and teachpacks from the DeinProgramm project for the German textbook "Die Macht der Abstraktion" by Herbert Klaeren and Michael Sperber have been added. * Misc: - Typed Scheme now comes with several more pre-wrapped libraries, found in the `typed' collection. - The `xml' and `html' collections are now contracted. - Binding parsing in net/cgi now interacts with `net/uri-codec's configuration parameters. - DrScheme captures logging output. - Check syntax: it is now possible to tack arrows crossing the currently selected text. - SRFI collections are available with R6RS-frienly names as in SRFI-97. - New `bitwise-bit-field' function. * The usual pile of bugfixes. (Notable: `scheme/package' works, `deflate' compression fixed, DrScheme language dialog issue resolved, `match' fixes, Windows networking, and much more.) ---------------------------------------------------------------------- -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From robby at eecs.northwestern.edu Thu Mar 19 20:56:29 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Thu Mar 19 20:56:50 2009 Subject: [plt-dev] Release Announcement for v4.1.5, third call In-Reply-To: References: Message-ID: <932b2f1f0903191756o67378a99yce470c6665404d25@mail.gmail.com> There is misc stuff, but I don't see anything worth mentioning in the release particularly. Robby On Thu, Mar 19, 2009 at 7:38 PM, Eli Barzilay wrote: > The release announcement sketch that I have so far is below. ?I didn't > get any additional edits. > > Specific people: > > * Stevie: Unit contracts, region contract, etc -- this should > ?definitely be blurbed > > * Robby: are there any Redex news? > > ---------------------------------------------------------------------- > > * Web Server: > ?- new URL-based dispatching library `web-server/dispatch', > ?- customizable continuation serialization policies for the stateless > ? ?web language `web-server/stuffers', > ?- abstraction of serve/servlet to build simpler dispatchers > ? ?`web-server/servlet-env', > ?- HTTP Digest authentication support `web-server/http/digest-auth', > ?- built-in cookie support in `web-server/http/cookie' and > ? ?`web-server/http/cookie-parse', > ?- highlighting and pretty-printing of errors in Xexpr constructions, > ?- load control dispatcher for limit concurrent sessions > ? ?`web-server/dispatchers/limit'. > > * Scribble: > ?- Literate programming is now available using the new > ? ?`scribble/lp' language. > ?- A new `at-exp' language makes it convenient to use the > ? ?scribble reader's @-expressions for general code. > ?- The `scribble/text' preprocessor language has been extended to > ? ?deal with indentation and other formatting issues. > ?- The "scribble" command-line tool accepts a `--pdf' flag to > ? ?render PDFs (via pdflatex). > > * DrScheme now provides feedback when PLaneT downloads and > ?installs new packages. > > * Language levels and teachpacks from the DeinProgramm project for > ?the German textbook "Die Macht der Abstraktion" by Herbert > ?Klaeren and Michael Sperber have been added. > > * Misc: > ?- Typed Scheme now comes with several more pre-wrapped > ? ?libraries, found in the `typed' collection. > ?- The `xml' and `html' collections are now contracted. > ?- Binding parsing in net/cgi now interacts with `net/uri-codec's > ? ?configuration parameters. > ?- DrScheme captures logging output. > ?- Check syntax: it is now possible to tack arrows crossing the > ? ?currently selected text. > ?- SRFI collections are available with R6RS-frienly names as in > ? ?SRFI-97. > ?- New `bitwise-bit-field' function. > > * The usual pile of bugfixes. ?(Notable: `scheme/package' works, > ?`deflate' compression fixed, DrScheme language dialog issue > ?resolved, `match' fixes, Windows networking, and much more.) > > ---------------------------------------------------------------------- > -- > ? ? ? ? ?((lambda (x) (x x)) (lambda (x) (x x))) ? ? ? ? ?Eli Barzilay: > ? ? ? ? ? ? ? ? ?http://www.barzilay.org/ ? ? ? ? ? ? ? ? Maze is Life! > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > From czhu at cs.utah.edu Fri Mar 20 01:28:51 2009 From: czhu at cs.utah.edu (Chongkai Zhu) Date: Fri Mar 20 01:29:14 2009 Subject: [plt-dev] macro-stepper and expand help function defined with define-for-syntax Message-ID: <49C32993.9050801@cs.utah.edu> If I put my macro in a helper function with define-for-syntax, then the macro stepper will not show expansion of anything inside this macro For example, (define-for-syntax (f stx) (syntax-case stx () ((_ p ...) #'(begin p ...)))) (define-syntax my-begin f) (my-begin (my-begin 1 2)) Macro stepper with standard hiding won't show the expansion of the inside `my-begin', or anything I put there. Is this a bug? Thanks, Chongkai From ryanc at ccs.neu.edu Fri Mar 20 13:11:50 2009 From: ryanc at ccs.neu.edu (Ryan Culpepper) Date: Fri Mar 20 13:11:56 2009 Subject: [plt-dev] Re: macro-stepper and expand help function defined with define-for-syntax In-Reply-To: <49C32993.9050801@cs.utah.edu> References: <49C32993.9050801@cs.utah.edu> Message-ID: <49C3CE56.70403@ccs.neu.edu> Chongkai Zhu wrote: > If I put my macro in a helper function with define-for-syntax, then the > macro stepper will not show expansion of anything inside this macro > > For example, > > (define-for-syntax (f stx) > (syntax-case stx () > ((_ p ...) > #'(begin p ...)))) > (define-syntax my-begin f) > (my-begin (my-begin 1 2)) > > Macro stepper with standard hiding won't show the expansion of the > inside `my-begin', or anything I put there. Is this a bug? There's a bug, but it doesn't have anything to do with 'define-for-syntax'. It has to do with begin-splicing in modules. I'll look into it. Ryan From eli at barzilay.org Sat Mar 21 23:36:41 2009 From: eli at barzilay.org (Eli Barzilay) Date: Sat Mar 21 23:37:01 2009 Subject: [plt-dev] Re: more requests for typed-scheme In-Reply-To: <49BFCCEA.4050209@ccs.neu.edu> References: <63bb19ae0903162059w7ffb67fbxa46c3f6cf10cafb6@mail.gmail.com> <63bb19ae0903170550g64018bb8v278005f2a91c7c02@mail.gmail.com> <49BFCCEA.4050209@ccs.neu.edu> Message-ID: <18885.45641.33556.5631@winooski.ccs.neu.edu> On Mar 17, Dave Herman wrote: > > Everyone, please find things you find useful in srfi/1 :-) > > FWIW, my favorites that I think are still absent from scheme/list: > > count, list-index, take-while, drop-while, span, break I added `count', and made the `srfi/1' version reprovide it. (This will not e in 4.1.5, of course.) It'll also be easy to add `take-while' and `drop-while' -- but the others are more problematic, at least IMO: * list-index: does it *have* to have this name? Perhaps we can use a better name? (This already happened -- we have `append*' which Ryan suggested, which is the same as `concatenate' in srfi/1 -- and I think that `append*' makes much more sense). * span, break: these are even worse -- not only are the names vague enough to not tell me what they do, they're names that are very popular in other contexts. It's even two very different contexts, so the potential damage is doubled. (The damage being unexpected names propagating through to packages that already have those names.) > Also all the lset stuff, though that might make sense to provide as > a different library. This should definitely be a separate library, IMO. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From sperber at deinprogramm.de Sun Mar 22 10:31:49 2009 From: sperber at deinprogramm.de (Michael Sperber) Date: Sun Mar 22 10:32:09 2009 Subject: [plt-dev] Stepper tests for DeinProgramm language levels? In-Reply-To: <18882.11834.217423.536195@winooski.ccs.neu.edu> (Eli Barzilay's message of "Thu, 19 Mar 2009 07:36:26 -0400") References: <7E3BEBBD-7779-4B1A-B2D5-9B57D6B240D7@ccs.neu.edu> <18882.11834.217423.536195@winooski.ccs.neu.edu> Message-ID: Eli Barzilay writes: > You can do that either in a new "tests/deinprogramm" collection, or in > some "deinprogramm/whatever" subcollection. In any case, tell me > about it so I know how to update the distribution specs. I've checked test code into tests/deinprogramm. > And keep in mind my comment too -- it's fine for your tests to rely on > the stepper tests, but if it goes the otherway then the dependencies > will get messed up. Yes - my plan is to just run the tests myself prior to releases. -- Cheers =8-} Mike Friede, V?lkerverst?ndigung und ?berhaupt blabla From clements at brinckerhoff.org Sun Mar 22 12:41:59 2009 From: clements at brinckerhoff.org (John Clements) Date: Sun Mar 22 12:42:29 2009 Subject: [plt-dev] Stepper tests for DeinProgramm language levels? In-Reply-To: References: <7E3BEBBD-7779-4B1A-B2D5-9B57D6B240D7@ccs.neu.edu> <18882.11834.217423.536195@winooski.ccs.neu.edu> Message-ID: <0E51F340-222D-4A46-91D5-3ACDA55355DF@brinckerhoff.org> On Mar 22, 2009, at 7:31 AM, Michael Sperber wrote: > > Eli Barzilay writes: > >> You can do that either in a new "tests/deinprogramm" collection, or >> in >> some "deinprogramm/whatever" subcollection. In any case, tell me >> about it so I know how to update the distribution specs. > > I've checked test code into tests/deinprogramm. > >> And keep in mind my comment too -- it's fine for your tests to rely >> on >> the stepper tests, but if it goes the otherway then the dependencies >> will get messed up. > > Yes - my plan is to just run the tests myself prior to releases. For what it's worth, I've done a rough refactoring of the stepper's tests to make it possible to use this framework for your tests as well. Here's a simple example of a module that contains just one test. Now we can see how much work we've duplicated... John #lang scheme (require tests/stepper/test-engine tests/stepper/test-abbrev (prefix-in m: tests/stepper/language-level-model) stepper/private/model-settings) ;; I'll be honest with you: I'm mostly in the dark w.r.t why ;; this parameterization is necessary.... I'm guessing it ;; has to do with the mutation of the current namespace ;; that occurs in run-teaching-language (parameterize ([current-namespace (make-base-namespace)]) (let* ([defs1 `((define (a x) (+ x 5)) (define b a))] [defs2 (append defs1 `((define c a)))]) (apply ;; you can abstract over this application with a define-syntax run-one-test (tt 'top-ref4 ;; - the name of the test m:intermediate ;; - the language level (or levels) to run in ,@defs1 (define c b) (c 3) ;; - the expressions to test (everything up to the first ::) :: ,@defs1 (define c {b}) ;; - the steps; the '::' divides steps, repeated '->'s indicate -> ,@defs1 (define c {a}) ;; that the 'before' of the second step is the 'after' of :: ,@defs2 ({c} 3) ;; the first one. the curly braces indicate the hilighted sexp. -> ,@defs2 ({a} 3) :: ,@defs2 {(a 3)} -> ,@defs2 {(+ 3 5)} -> ,@defs2 {8})))) -------------- 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/20090322/08dbf4fb/smime.bin From samth at ccs.neu.edu Mon Mar 23 11:55:28 2009 From: samth at ccs.neu.edu (Sam TH) Date: Mon Mar 23 11:55:49 2009 Subject: [plt-dev] type-scheme wrapper for file/tar In-Reply-To: <779bf2730902251223u551dadc5t93e043d0639f1106@mail.gmail.com> References: <779bf2730902251223u551dadc5t93e043d0639f1106@mail.gmail.com> Message-ID: <63bb19ae0903230855s4c0d2fb2o94cd2f164b502427@mail.gmail.com> Thanks for the wrapper, and for the bug reports for the documentation. I've committed the wrapper, and changed the docs (including adding documentation for `tar-gzip'). sam th On Wed, Feb 25, 2009 at 8:23 PM, YC wrote: > Hi Sam, > > Below is the wrapper for file/tar.? I found a few discrepancies from the > doc: > > both tar and tar->output returns a exact-nonenegative-integer? instead of > void? (due to the last call being (write-bytes ...)), so I had them return > Integer > tar->output takes (listof path?) instead of (listof path-string?) > tar-gzip is missing from the doc but is available in mzlib/tar (from which > file/tar imports), so I export it as well, and it actually returns void? > this time > > Also I didn't find a way to write optional parameters so I used > case-lambda.? Let me know if there is another way to write it.? (What would > be the way to write keyword parameter then?) > > Thoughts? > > #lang typed-scheme > ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; > ;; tar.ss > ;; typed-scheme wrapper on file/tar > ;; yc 2009/2/25 > ;; licensed in LGPL, the same license as PLT Scheme itself. > > ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; > ;; basic type aliases. > (define-type-alias Path-String (U Path String)) > > (require/typed file/tar > ?????????????? ;; tar appears to return exact-nonenegative-integer? instead > of void? > ?????????????? (tar (Path-String Path-String * -> Integer)) > ?????????????? ;; tar->output appears to take (listof path) instead of > (listof path-string?) > ?????????????? ;; it also appears to return exact-nonenegative-integer? > ?????????????? (tar->output (case-lambda ((Listof Path) -> Integer) > ???????????????????????????????????????? ((Listof Path) Output-Port -> > Integer))) > ?????????????? ;; tar->gzip > ?????????????? ;; missing from file/tar but available in mzlib/tar > ?????????????? ;; actually returns void? > ?????????????? (tar-gzip (Path-String Path-String * -> Void)) > ?????????????? ) > > (provide tar tar->output tar-gzip) > > > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > > -- sam th samth@ccs.neu.edu From jay.mccarthy at gmail.com Mon Mar 23 15:56:31 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Mon Mar 23 15:56:51 2009 Subject: [plt-dev] Cannot redefine a constant Message-ID: If I am investigating some internal functionality, like the class system. If I try to "Check Syntax", I get the following error: define-values: cannot re-define a constant: insp This is in scheme/private/class-internal.ss Is there some mode for working on such internal things? Or can I just not use Check Syntax? Jay -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From samth at ccs.neu.edu Tue Mar 24 13:50:50 2009 From: samth at ccs.neu.edu (Sam TH) Date: Tue Mar 24 13:51:08 2009 Subject: [plt-dev] Call for Participation: Writing Typed Scheme wrapper modules In-Reply-To: <9A19D3AB8C4F4A658F96CF5611358602@uw2b2dff239c4d> References: <63bb19ae0902241305n1b79caa9tc87dea8c989ca950@mail.gmail.com> <779bf2730902241357h3c8760c9wd8b3148f17c6c367@mail.gmail.com> <63bb19ae0902241404p3a4f9afk822e1fc5bf67192d@mail.gmail.com> <779bf2730902241427x525391fasa9de111eaf0e079b@mail.gmail.com> <63bb19ae0902241520w4b259851v584489f8cfb4d50b@mail.gmail.com> <779bf2730902241532g5891dd90pf3f0d4f9295070ef@mail.gmail.com> <7AEA20C361E44F1B8F4BD079E235B22E@uw2b2dff239c4d> <63bb19ae0902250523m2fb8e65doa0e5714644dd1c90@mail.gmail.com> <9A19D3AB8C4F4A658F96CF5611358602@uw2b2dff239c4d> Message-ID: <63bb19ae0903241050n793ff9b2pbc456cbd1aaf1178@mail.gmail.com> On Wed, Feb 25, 2009 at 3:11 PM, Jos Koot wrote: > Below is my first trial of math-wrapper with some tests. Would this come > close to what you expect? Comments are appreciated. I've committed this (as part of the TS base environment), and added `tanh' to the `scheme/math' library. Thanks, and I hope you're still interested in contributing more wrappers. -- sam th samth@ccs.neu.edu From jay.mccarthy at gmail.com Wed Mar 25 12:03:12 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Wed Mar 25 12:03:34 2009 Subject: [plt-dev] scheme/foreign and unicode Message-ID: I noticed that there is no _char type that automatically calls char->integer and integer->char. Also, there doesn't appear to be a way to get individual unicode characters out to C code that expects a wchar_t or something like that. Am I missing something? Jay -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From ryanc at ccs.neu.edu Wed Mar 25 20:28:41 2009 From: ryanc at ccs.neu.edu (Ryan Culpepper) Date: Wed Mar 25 20:28:53 2009 Subject: [plt-dev] replacement for *-identifier-mapping Message-ID: <49CACC39.40307@ccs.neu.edu> I've adapted the code from syntax/boundmap to use the new v4-style names (get->ref, put!->set!, etc) and support the new dict interface (in scheme/dict), including both mutable and immutable variants. I'd like to add it as a new module in the syntax collection. I'm looking for opinions about noun phrases to replace 'identifier-mapping'. I'd prefer something shorter. The module name: syntax/ Constructors: make-bound-, make-immutable-bound-, make-free-, make-immutable-free- Lookup: bound--ref, free--ref Update: bound--set!, free--set! and so on Here are some that I've thought of: id-table id-hash Thoughts? Ryan From sstrickl at ccs.neu.edu Wed Mar 25 20:35:09 2009 From: sstrickl at ccs.neu.edu (Stevie Strickland) Date: Wed Mar 25 20:35:34 2009 Subject: [plt-dev] replacement for *-identifier-mapping In-Reply-To: <49CACC39.40307@ccs.neu.edu> References: <49CACC39.40307@ccs.neu.edu> Message-ID: On Mar 26, 2009, at 12:28 AM, Ryan Culpepper wrote: > I'm looking for opinions about noun phrases to replace 'identifier- > mapping'. I'd prefer something shorter. ... > Here are some that I've thought of: > > id-table > id-hash Any particular reason you didn't consider id-map as well? Stevie From ryanc at ccs.neu.edu Wed Mar 25 20:47:53 2009 From: ryanc at ccs.neu.edu (Ryan Culpepper) Date: Wed Mar 25 20:48:01 2009 Subject: [plt-dev] replacement for *-identifier-mapping In-Reply-To: References: <49CACC39.40307@ccs.neu.edu> Message-ID: <49CAD0B9.4020003@ccs.neu.edu> Stevie Strickland wrote: > On Mar 26, 2009, at 12:28 AM, Ryan Culpepper wrote: >> I'm looking for opinions about noun phrases to replace >> 'identifier-mapping'. I'd prefer something shorter. > ... >> Here are some that I've thought of: >> >> id-table >> id-hash > > Any particular reason you didn't consider id-map as well? Then there would be procedures '*-id-map-map'. I don't like that. I think it's a bad idea to use 'map' as a noun when it's already used pervasively as a verb. Ryan From carl.eastlund at gmail.com Wed Mar 25 20:53:59 2009 From: carl.eastlund at gmail.com (Carl Eastlund) Date: Wed Mar 25 20:54:17 2009 Subject: [plt-dev] replacement for *-identifier-mapping In-Reply-To: <49CAD0B9.4020003@ccs.neu.edu> References: <49CACC39.40307@ccs.neu.edu> <49CAD0B9.4020003@ccs.neu.edu> Message-ID: <990e0c030903251753o72e72488t4c203aebc91ace0d@mail.gmail.com> On Wed, Mar 25, 2009 at 8:47 PM, Ryan Culpepper wrote: > Stevie Strickland wrote: >> >> On Mar 26, 2009, at 12:28 AM, Ryan Culpepper wrote: >>> >>> I'm looking for opinions about noun phrases to replace >>> 'identifier-mapping'. I'd prefer something shorter. >> >> ... >>> >>> Here are some that I've thought of: >>> >>> id-table >>> id-hash >> >> Any particular reason you didn't consider id-map as well? > > Then there would be procedures '*-id-map-map'. I don't like that. I think > it's a bad idea to use 'map' as a noun when it's already used pervasively as > a verb. If you're going to nounify it, it should be mapping. But I'm a fan of id-table; it means you're not tying yourself to an implementation that uses hash functions if you ever decide to change it. -- Carl Eastlund From robby at eecs.northwestern.edu Thu Mar 26 03:27:06 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Thu Mar 26 03:29:20 2009 Subject: [plt-dev] replacement for *-identifier-mapping In-Reply-To: <990e0c030903251753o72e72488t4c203aebc91ace0d@mail.gmail.com> References: <49CACC39.40307@ccs.neu.edu> <49CAD0B9.4020003@ccs.neu.edu> <990e0c030903251753o72e72488t4c203aebc91ace0d@mail.gmail.com> Message-ID: <932b2f1f0903260027m58ed334dv1b6cfa23fa1ae357@mail.gmail.com> How about not including the "bound-" and "free-" prefixes in the lookup functions? Robby From ryanc at ccs.neu.edu Thu Mar 26 13:59:13 2009 From: ryanc at ccs.neu.edu (Ryan Culpepper) Date: Thu Mar 26 13:59:38 2009 Subject: [plt-dev] replacement for *-identifier-mapping In-Reply-To: <932b2f1f0903260027m58ed334dv1b6cfa23fa1ae357@mail.gmail.com> References: <49CACC39.40307@ccs.neu.edu> <49CAD0B9.4020003@ccs.neu.edu> <990e0c030903251753o72e72488t4c203aebc91ace0d@mail.gmail.com> <932b2f1f0903260027m58ed334dv1b6cfa23fa1ae357@mail.gmail.com> Message-ID: <917B487D-DA92-4A6E-AAB5-1BA36B3A6F12@ccs.neu.edu> On Mar 26, 2009, at 3:27 AM, Robby Findler wrote: > How about not including the "bound-" and "free-" prefixes in the > lookup functions? I can think of three main alternatives for providing access to the operations: 1. Provide specific procedures (eg, 'bound-id-table-ref') and also implement a generic interface (so 'dict-ref' also works). 2. Provide only constructors; all other operations go through the generic interface. 3. Like 1 (specific procedures) but collapse some together (eg, 'id- table-ref'). (Supporting the generic dict interface is a given.) I like option 1 best, since it serves both the people who like short generic names and those who like the explicitness (and greater speed--???) of distinct specific procedures. Ryan From jay.mccarthy at gmail.com Thu Mar 26 15:07:30 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Thu Mar 26 15:07:52 2009 Subject: [plt-dev] Re: [plt-scheme] expr-syntax-object-iterator: unknown expr: (#%variable-reference) In-Reply-To: <20090326131310.GA16949@giebrok.zwizwa.be> References: <20090326131310.GA16949@giebrok.zwizwa.be> Message-ID: This does not appear to be a bug in the html collection, so I don't know how to fix it. If it is a bug in the html collection, can the debugger debugger give me a clue? Jay On Thu, Mar 26, 2009 at 7:13 AM, Tom Schouten wrote: > Hello, > > In DrScheme, the following code produces no errors on "run": > > ?#lang scheme/base > ?(require html) > ?(read-html-as-xml (open-input-string "")) > > but it does print out an error message on "debug": > > ?Welcome to DrScheme, version 4.1.5 [3m]. > ?Language: Module; memory limit: 128 megabytes. > ?expr-syntax-object-iterator: unknown expr: (#%variable-reference) > > Cheers, > Tom > > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-scheme > -- 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 Mar 26 23:29:28 2009 From: eli at barzilay.org (Eli Barzilay) Date: Thu Mar 26 23:29:48 2009 Subject: [plt-dev] Suggestion: `with-hash' Message-ID: <18892.18456.532354.61023@winooski.ccs.neu.edu> Here's a suggestion for a small addition to `scheme/base', with the obvious meaning: (with-hash ) Lookup in and return the found value. If there is no value evaluate , store it in for the , and return it. I'm sure that many are familiar with the usual little dance routine you need to do to get this done -- it's not hard to write, but it's very annoying. Having a memoization tool helps, but there are many cases where you don't want a function, just the through-the-hash thing. And yes, you can often use a memoized function to get the above implicitly -- but what if you want your own hash table for some reason (for example, Dave's planet package has only two kinds of hashes, what if you want a weak hash?), or what if want to use the hash table later to get a list of values? Or maybe you just don't want the cost of an extra function for some reason. In contrast, the above has no overhead, is minimal enough so it's easy to remember, and convenient enough for many cases (just grepping the collection tree for "(or (hash-ref" shows that this will be useful). In addition, it's easy to define a memoized function with this, for example: (define hcons (let ([t (make-hasheq)]) (lambda (a b) (with-hash (with-hash t a (make-hasheq)) b (cons a b))))) Any objections? -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From ryanc at ccs.neu.edu Fri Mar 27 00:33:08 2009 From: ryanc at ccs.neu.edu (Ryan Culpepper) Date: Fri Mar 27 00:33:35 2009 Subject: [plt-dev] Suggestion: `with-hash' In-Reply-To: <18892.18456.532354.61023@winooski.ccs.neu.edu> References: <18892.18456.532354.61023@winooski.ccs.neu.edu> Message-ID: <49CC5704.1030208@ccs.neu.edu> Eli Barzilay wrote: > Here's a suggestion for a small addition to `scheme/base', with the > obvious meaning: > > (with-hash ) > > Lookup in and return the found value. If there is > no value evaluate , store it in for the , and > return it. > [...] > > Any objections? I don't like the name. I think you should make it a procedure (use the normal hash value/thunk convention) and name it 'hash-ref/default!' or something similarly descriptive. Also, how about making it generic instead and adding it to scheme/dict? I'd rather procedures for common usage patterns of dictionaries were put in scheme/dict than added to the base language. Ryan From eli at barzilay.org Fri Mar 27 00:43:54 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri Mar 27 00:44:16 2009 Subject: [plt-dev] Suggestion: `with-hash' In-Reply-To: <49CC5704.1030208@ccs.neu.edu> References: <18892.18456.532354.61023@winooski.ccs.neu.edu> <49CC5704.1030208@ccs.neu.edu> Message-ID: <18892.22922.630614.286919@winooski.ccs.neu.edu> On Mar 27, Ryan Culpepper wrote: > Eli Barzilay wrote: > > Here's a suggestion for a small addition to `scheme/base', with the > > obvious meaning: > > > > (with-hash ) > > > > Lookup in and return the found value. If there is > > no value evaluate , store it in for the , and > > return it. > > [...] > > > > Any objections? > > I don't like the name. That's the best I could think of -- and the good point in it is that it's a strong hint that it's a macro. > I think you should make it a procedure (use the normal hash > value/thunk convention) and name it 'hash-ref/default!' or something > similarly descriptive. That's actually a point that I forgot to mention. At some point, Matthew made `hash-ref' accept a plain value for a default rather than a thunk. The reason is that (or (hash-ref t k #f) ...stuff..) is faster than putting stuff in a thunk. This is especially important with hash tables, when you're trying to speed things up. > Also, how about making it generic instead and adding it to > scheme/dict? I'd rather procedures for common usage patterns of > dictionaries were put in scheme/dict than added to the base > language. That would of course be useful as a dict method too -- but there's no contradiction in having both. (As with other methods that correspond to specific functions -- you pay for the dispatch when you prefer a generic code.) On Mar 27, Henk Boom wrote: > > If the last argument were a thunk then it would almost make sense to > just call it 'hash-ref!'. That feels like an oxymoron though =). That *was* my first choice -- but I didn't want that name for a macro. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From henk at henk.ca Fri Mar 27 00:38:38 2009 From: henk at henk.ca (Henk Boom) Date: Fri Mar 27 01:05:19 2009 Subject: [plt-dev] Suggestion: `with-hash' In-Reply-To: <49CC5704.1030208@ccs.neu.edu> References: <18892.18456.532354.61023@winooski.ccs.neu.edu> <49CC5704.1030208@ccs.neu.edu> Message-ID: 2009/3/27 Ryan Culpepper : > Eli Barzilay wrote: >> >> Here's a suggestion for a small addition to `scheme/base', with the >> obvious meaning: >> >> ?(with-hash ) >> >> ? ?Lookup in and return the found value. ?If there is >> ? ?no value evaluate , store it in for the , and >> ? ?return it. >> ?[...] >> >> Any objections? > > I don't like the name. I think you should make it a procedure (use the > normal hash value/thunk convention) and name it 'hash-ref/default!' or > something similarly descriptive. If the last argument were a thunk then it would almost make sense to just call it 'hash-ref!'. That feels like an oxymoron though =). Henk From ryanc at ccs.neu.edu Fri Mar 27 01:30:15 2009 From: ryanc at ccs.neu.edu (Ryan Culpepper) Date: Fri Mar 27 01:30:35 2009 Subject: [plt-dev] Suggestion: `with-hash' In-Reply-To: <18892.22922.630614.286919@winooski.ccs.neu.edu> References: <18892.18456.532354.61023@winooski.ccs.neu.edu> <49CC5704.1030208@ccs.neu.edu> <18892.22922.630614.286919@winooski.ccs.neu.edu> Message-ID: <49CC6467.7020507@ccs.neu.edu> Eli Barzilay wrote: > On Mar 27, Ryan Culpepper wrote: >> Eli Barzilay wrote: >>> Here's a suggestion for a small addition to `scheme/base', with the >>> obvious meaning: >>> >>> (with-hash ) >>> >>> Lookup in and return the found value. If there is >>> no value evaluate , store it in for the , and >>> return it. >>> [...] >>> >>> Any objections? >> I don't like the name. > > That's the best I could think of -- and the good point in it is that > it's a strong hint that it's a macro. It shouldn't be a macro. A macro that is really really almost just a procedure is a dinky kind of macro. >> I think you should make it a procedure (use the normal hash >> value/thunk convention) and name it 'hash-ref/default!' or something >> similarly descriptive. > > That's actually a point that I forgot to mention. At some point, > Matthew made `hash-ref' accept a plain value for a default rather than > a thunk. The reason is that > > (or (hash-ref t k #f) ...stuff..) > > is faster than putting stuff in a thunk. This is especially important > with hash tables, when you're trying to speed things up. The docs say 'hash-ref' accepts a third value, which if a procedure is applied to get the default value and which otherwise is interpreted as the default value. That's what I meant by "the normal hash value/thunk convention". >> Also, how about making it generic instead and adding it to >> scheme/dict? I'd rather procedures for common usage patterns of >> dictionaries were put in scheme/dict than added to the base >> language. > > That would of course be useful as a dict method too -- but there's no > contradiction in having both. (As with other methods that correspond > to specific functions -- you pay for the dispatch when you prefer a > generic code.) I'm saying it sounds more like a library procedure than a base language procedure. I want 'hash-push!' and 'hash-set!/error-if-already-present' and other hash (or dict) procedures, but I don't think they belong in scheme/base. Ryan > On Mar 27, Henk Boom wrote: >> If the last argument were a thunk then it would almost make sense to >> just call it 'hash-ref!'. That feels like an oxymoron though =). > > That *was* my first choice -- but I didn't want that name for a macro. > From neil at neilvandyke.org Fri Mar 27 01:33:58 2009 From: neil at neilvandyke.org (Neil Van Dyke) Date: Fri Mar 27 01:34:24 2009 Subject: [plt-dev] changing xexpr Message-ID: <49CC6546.9080105@neilvandyke.org> Would PLT be willing to change sexprs in the near future to a new 'standard' sexp-based representation for XML? The goals are: (1) unify SXML and PLT's xexprs; (2) make a few improvements on both. The practical problem is getting this new representation adopted by PLT and others. Otherwise, I might as well stick with SXML, the current de facto standard. Regarding PLT adoption, I'm thinking that the new representation could start with xexprs, replace the non-sexp structs with sexp forms, and add a few missing things. PLT's implementation of this representation could be made backward-compatible with programs that use the old sexpr representation. I'd want to involve a PLT representative and at least Oleg or Kirill in reviewing the proposal and suggesting any changes. I suspect this should be a SRFI at some point. -- http://www.neilvandyke.org/ From eli at barzilay.org Fri Mar 27 02:32:50 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri Mar 27 02:33:14 2009 Subject: [plt-dev] Suggestion: `with-hash' In-Reply-To: <49CC6467.7020507@ccs.neu.edu> References: <18892.18456.532354.61023@winooski.ccs.neu.edu> <49CC5704.1030208@ccs.neu.edu> <18892.22922.630614.286919@winooski.ccs.neu.edu> <49CC6467.7020507@ccs.neu.edu> Message-ID: <18892.29458.940505.231273@winooski.ccs.neu.edu> On Mar 27, Ryan Culpepper wrote: > > The docs say 'hash-ref' accepts a third value, which if a procedure > is applied to get the default value and which otherwise is > interpreted as the default value. That's what I meant by "the normal > hash value/thunk convention". I know. A popular use case is allocating something to put in the table. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From jay.mccarthy at gmail.com Fri Mar 27 08:15:38 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Fri Mar 27 08:16:01 2009 Subject: [plt-dev] changing xexpr In-Reply-To: <49CC6546.9080105@neilvandyke.org> References: <49CC6546.9080105@neilvandyke.org> Message-ID: Hi Neil, As the XML and Web server maintainer, I am willing to talk about how to make the xexprs better. Even though you had the email message earlier this month, I don't understand what changes you think need to be made. Whatever changes, it is very important that everything stay compatible. Jay On Thu, Mar 26, 2009 at 11:33 PM, Neil Van Dyke wrote: > Would PLT be willing to change sexprs in the near future to a new 'standard' > sexp-based representation for XML? > > The goals are: (1) unify SXML and PLT's xexprs; (2) make a few improvements > on both. > > The practical problem is getting this new representation adopted by PLT and > others. ?Otherwise, I might as well stick with SXML, the current de facto > standard. > > Regarding PLT adoption, I'm thinking that the new representation could start > with xexprs, replace the non-sexp structs with sexp forms, and add a few > missing things. ?PLT's implementation of this representation could be made > backward-compatible with programs that use the old sexpr representation. > > I'd want to involve a PLT representative and at least Oleg or Kirill in > reviewing the proposal and suggesting any changes. ?I suspect this should be > a SRFI at some point. > > -- > http://www.neilvandyke.org/ > > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From robby at eecs.northwestern.edu Fri Mar 27 21:37:20 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Fri Mar 27 21:37:38 2009 Subject: [plt-dev] replacement for *-identifier-mapping In-Reply-To: <917B487D-DA92-4A6E-AAB5-1BA36B3A6F12@ccs.neu.edu> References: <49CACC39.40307@ccs.neu.edu> <49CAD0B9.4020003@ccs.neu.edu> <990e0c030903251753o72e72488t4c203aebc91ace0d@mail.gmail.com> <932b2f1f0903260027m58ed334dv1b6cfa23fa1ae357@mail.gmail.com> <917B487D-DA92-4A6E-AAB5-1BA36B3A6F12@ccs.neu.edu> Message-ID: <932b2f1f0903271837l795ac224ifaa0df2fe3630aa6@mail.gmail.com> Oh, yes. dict-ref is good. Robby On Thu, Mar 26, 2009 at 12:59 PM, Ryan Culpepper wrote: > On Mar 26, 2009, at 3:27 AM, Robby Findler wrote: > >> How about not including the "bound-" and "free-" prefixes in the >> lookup functions? > > > I can think of three main alternatives for providing access to the > operations: > > 1. Provide specific procedures (eg, 'bound-id-table-ref') and also implement > a generic interface (so 'dict-ref' also works). > 2. Provide only constructors; all other operations go through the generic > interface. > 3. Like 1 (specific procedures) but collapse some together (eg, > 'id-table-ref'). > > ( Supporting the generic dict interface is a given.) > > I like option 1 best, since it serves both the people who like short generic > names and those who like the explicitness (and greater speed--???) of > distinct specific procedures. > > Ryan > > From noelwelsh at gmail.com Sun Mar 29 13:41:52 2009 From: noelwelsh at gmail.com (Noel Welsh) Date: Sun Mar 29 13:49:49 2009 Subject: [plt-dev] update on experiment in re-implementing MrEd In-Reply-To: <20090206231055.BB9226500AD@mail-svr1.cs.utah.edu> References: <20090206231055.BB9226500AD@mail-svr1.cs.utah.edu> Message-ID: > One piece of the puzzle is easy to split from the rest: implementing > the `dc<%>' classes on top of Cairo. I'm not gonna volunteer to do this, as I don't think I have time to complete the job. However I couldn't stop myself fiddling around with the code, and I've gone and implemented draw-rectangle for Cocoa (code is not committed). Two points: 1. The Cairo code will be mostly generic, so I think there should be a dc base class/mixin/trait in common 2. The Cairo drawing model is quite different to the dc model. dc is immediate -- you call functions and the shapes appear immediately. The Cairo model is to specify the path completely and only then stroke and/or fill the path. Presumably this enables GPU optimisations. This naturally leads to functions like line_to etc. The Cairo model also goes beyond dc, offering alpha channel, masking, etc. No doubt you know all this. How do you envisage extending the dc to offer these features? Cheers, N. From mflatt at cs.utah.edu Sun Mar 29 14:00:42 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Sun Mar 29 14:01:04 2009 Subject: [plt-dev] update on experiment in re-implementing MrEd In-Reply-To: References: <20090206231055.BB9226500AD@mail-svr1.cs.utah.edu> Message-ID: <20090329180045.523ED6500A9@mail-svr1.cs.utah.edu> At Sun, 29 Mar 2009 18:41:52 +0100, Noel Welsh wrote: > 1. The Cairo code will be mostly generic, so I think there should be a > dc base class/mixin/trait in common Yes. > 2. The Cairo drawing model is quite different to the dc model. dc is > immediate -- you call functions and the shapes appear immediately. The > Cairo model is to specify the path completely and only then stroke > and/or fill the path. Presumably this enables GPU optimisations. This > naturally leads to functions like line_to etc. The Cairo model also > goes beyond dc, offering alpha channel, masking, etc. No doubt you > know all this. How do you envisage extending the dc to offer these > features? `dc<%>' already supports `dc-path%', which is close to the Cairo (i.e., PostScript) model. There's also already a global alpha, and we'll add more things like rotation (or, more generally, a transformation matrix). Is masking different from clipping? I guess I'll find out... BTW, I'm writing this message in a SirMail that's running on top of `editor<%>' classes that are implemented in Scheme instead of C++ (which is phase 1 of this re-implement MrEd experiment). If testing continues to go well, I may be able to merge to the trunk soon. From noelwelsh at gmail.com Mon Mar 30 05:13:11 2009 From: noelwelsh at gmail.com (Noel Welsh) Date: Mon Mar 30 05:13:30 2009 Subject: [plt-dev] update on experiment in re-implementing MrEd In-Reply-To: <20090329180045.523ED6500A9@mail-svr1.cs.utah.edu> References: <20090206231055.BB9226500AD@mail-svr1.cs.utah.edu> <20090329180045.523ED6500A9@mail-svr1.cs.utah.edu> Message-ID: On Sun, Mar 29, 2009 at 7:00 PM, Matthew Flatt wrote: > `dc<%>' already supports `dc-path%', which is close to the Cairo (i.e., > PostScript) model. There's also already a global alpha, and we'll add > more things like rotation (or, more generally, a transformation > matrix). > > Is masking different from clipping? I guess I'll find out... Heh. I didn't know about this stuff. I even went so far as to start implementing 2D vector graphics in OpenGL to replicate this functionality. > BTW, I'm writing this message in a SirMail that's running on top of > `editor<%>' classes that are implemented in Scheme instead of C++ > (which is phase 1 of this re-implement MrEd experiment). If testing > continues to go well, I may be able to merge to the trunk soon. Cool. I've implemented a bit of the dc<%> interface. Commit message reproduced below. I have an issue writing tests. It appears that I can't use Cairo/Cocoa from a MrEd application. This is understandable. There also appears to be a threading issue. Does Cocoa take over the main thread or something? cocoa.ss runs, but my almost identical dc-test.ss (replace #lang scheme/gui with #lang scheme/base, comment out MrEd code) doesn't draw anything. The only difference I can see is the thread created in cocoa, so perhaps I need to duplicate that. Commit msg: Start implementing the dc<%> interface. Currently draw-rectangle and draw-line are defined for Cocoa only. common/dc.ss: - contains a mixin that defines the common Cairo based methods - defines an interface, dc-backend<%>, that the backends must implement cocoa/dc.ss: - defines a Cocoa specific backend and a Cocoa dc implementation tests/dc-test.ss - An attempt to define a test comparing Cocoa/Cairo rendering and MrEd rendering. This just hangs -- I don't know why. Run as mred dc-test.ss {cocoa|mred} To add new dc<%> methods: - Extend cairo.ss with any new cairo functions needed - Implement methods on common/dc.ss - Add test to tests/dc-test.ss (and get dc-test.ss working if you know how!) N. From noelwelsh at gmail.com Mon Mar 30 05:41:54 2009 From: noelwelsh at gmail.com (Noel Welsh) Date: Mon Mar 30 05:42:13 2009 Subject: [plt-dev] update on experiment in re-implementing MrEd In-Reply-To: References: <20090206231055.BB9226500AD@mail-svr1.cs.utah.edu> <20090329180045.523ED6500A9@mail-svr1.cs.utah.edu> Message-ID: On Mon, Mar 30, 2009 at 10:13 AM, Noel Welsh wrote: > reproduced below. I have an issue writing tests. I've fixed this. I needed a yield (I also got rid of MrEd; not sure this was necessary). The test shows many rendering problems -- try resizing the window -- but its a start. N. From jos.koot at telefonica.net Mon Mar 30 10:21:05 2009 From: jos.koot at telefonica.net (Jos Koot) Date: Mon Mar 30 10:21:25 2009 Subject: [plt-dev] typed-scheme-wrapper for pretty Message-ID: With delay I prepared a typed-scheme wrapper for scheme/pretty. Where can I find a test suite for it. Your opinion is appreciated on the following. I kept the wrapper as simple as possible by choosing the smallest contracts that contains all possibilities (for example Integer for Exact-positive-integer and Boolean for #f) I did not include additional tests on such things as exact-positive-integers, because these tests would duplicate those of scheme/pretty. Jos -------------- next part -------------- An HTML attachment was scrubbed... URL: http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090330/12e476d5/attachment.htm From mflatt at cs.utah.edu Mon Mar 30 11:35:16 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Mon Mar 30 11:35:42 2009 Subject: [plt-dev] try out Scheme-implemented editor classes Message-ID: <20090330153518.77C206500AE@mail-svr1.cs.utah.edu> The Scheme re-implementation of the `editor<%>' classes is now essentially complete. You can try it by building and running from http://svn.plt-scheme.org/plt/branches/mflatt/wxme/ instead of the SVN trunk. You should try this if you're responsible for code that uses the classes from sections 2.5 of the `scheme/gui' reference manual. Running branch should look just like running the trunk (as of sometime last week), because this isn't the whole MrEd re-implementation. The widget and drawing classes are still as much in C++ as before. But the text editor and "pasteboard" that you use in DrScheme, Redex, card games, etc., is now implemented completely in Scheme on top of the widget and drawing libraries, instead of in C++. For a given platform, the old editor implementation was about half of the C++ in MrEd (not counting MzScheme). So, this is a big change, but it won't look like it from the outside. Ideally, you'll notice no changes at all unless you look at the source. The point of the change is that we can more easily move the lower widget and drawing layers from C++ into Scheme. If you're curious to compare the old and new code, compare http://svn.plt-scheme.org/plt/trunk/src/mred/wxme/ to http://svn.plt-scheme.org/plt/branches/mflatt/wxme/collects/mred/private/wxme/ If you run the branch, then I can pretty much guarantee that you'll find bugs. The new implementation is 17k lines of Scheme code ported from 25k lines of C++ code.[*] A new 1.3k-line test suite is much more than we had before, but it falls well short of good coverage outside core operations like inserting text or computing layout. There will still be stupid translation errors, such as an extra pair of parentheses that cause a boolean to be applied as a function or a missing default argument on a method declaration. Since the code is now in Scheme, however, you may find that it's easy to fix a bug yourself, and I welcome those repairs. Otherwise, send bug reports. Depending on whether people try the branch and what bugs they find, I may wait until next week to merge to the trunk. [*] In my experience, C/C++ programs usually get much smaller when ported to Scheme, while 17k isn't much less than 25k. But the starting point was relatively high-level C++ code, and the class and method structure is essentially intact in the port. From rafkind at cs.utah.edu Mon Mar 30 13:30:06 2009 From: rafkind at cs.utah.edu (Jon Rafkind) Date: Mon Mar 30 13:30:24 2009 Subject: [plt-dev] try out Scheme-implemented editor classes In-Reply-To: <20090330153518.77C206500AE@mail-svr1.cs.utah.edu> References: <20090330153518.77C206500AE@mail-svr1.cs.utah.edu> Message-ID: <49D1019E.80500@cs.utah.edu> Matthew Flatt wrote: > The Scheme re-implementation of the `editor<%>' classes is now > essentially complete. You can try it by building and running from > > I took it for a quick spin. I got this exception in drscheme when trying to paste some text using my vi tool. send: no such method: same-eventspace? for class: clipboard<%> === context === /home/jon/svn/mred-experiment/f/wxme/collects/scheme/private/class-internal.ss:3671:2: obj-error /home/jon/svn/mred-experiment/f/wxme/collects/mred/private/wxme/editor.ss:1040:2: do-buffer-paste method in editor% /home/jon/svn/mred-experiment/f/wxme/collects/mred/private/wxme/text.ss:2007:2: do-paste method in text% /home/jon/svn/scheme/vi/utils.ss:79:0: repeat /home/jon/svn/scheme/vi/tool.ss:678:9: do-command /home/jon/svn/scheme/vi/tool.ss:304:4: accept method in ...vn/scheme/vi/tool.ss:265:2 /home/jon/svn/mred-experiment/f/wxme/collects/mred/private/wxme/editor-canvas.ss:414:2: on-char method in editor-canvas% /home/jon/svn/mred-experiment/f/wxme/collects/scheme/private/more-scheme.ss:155:2: call-with-break-parameterization /home/jon/svn/mred-experiment/f/wxme/collects/scheme/private/more-scheme.ss:271:2: call-with-exception-handler From mflatt at cs.utah.edu Mon Mar 30 13:55:49 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Mon Mar 30 13:56:08 2009 Subject: [plt-dev] try out Scheme-implemented editor classes In-Reply-To: <49D1019E.80500@cs.utah.edu> References: <20090330153518.77C206500AE@mail-svr1.cs.utah.edu> <49D1019E.80500@cs.utah.edu> Message-ID: <20090330175550.653906500A3@mail-svr1.cs.utah.edu> At Mon, 30 Mar 2009 11:30:06 -0600, Jon Rafkind wrote: > Matthew Flatt wrote: > > The Scheme re-implementation of the `editor<%>' classes is now > > essentially complete. You can try it by building and running from > > > > > I took it for a quick spin. I got this exception in drscheme when trying > to paste some text using my vi tool. > send: no such method: same-eventspace? for class: clipboard<%> This one is fixed - thanks!