From robby at eecs.northwestern.edu Tue Sep 1 01:31:48 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Tue Sep 1 01:34:22 2009 Subject: [plt-dev] search responsiveness should be better Message-ID: <932b2f1f0908312231q72b3d1dbya16e2976c9209be7@mail.gmail.com> DrScheme's interactive search should feel more responsive now. Please let me know if things still feel slow. Also, do keep (specific) complaints about where DrScheme feels slow coming. Even better if you set the PLTDRPROFILE environment variable and record some profiling information during the things that feel sluggish. Robby From eli at barzilay.org Tue Sep 1 18:05:01 2009 From: eli at barzilay.org (Eli Barzilay) Date: Tue Sep 1 18:05:24 2009 Subject: [plt-dev] Re: hosed doc search In-Reply-To: <20090901141757.F11236500A8@mail-svr1.cs.utah.edu> References: <904774730909010618t45763075we67d8e9f462e6d7b@mail.gmail.com> <20090901141757.F11236500A8@mail-svr1.cs.utah.edu> Message-ID: <19101.39565.657076.261021@winooski.ccs.neu.edu> On Sep 1, Matthew Flatt wrote: > > You might need to delete a cookie with "PLT_Root" in its name. > > I had to do that once after I installed a Planet package, opened > docs with `plt-help', and then removed the version-specific > subdirectory in my ".plt-scheme" directory. Searching got confused > because the index file had disappeared, and the "PLT_Root" cookie > points to that index file. This is not the first time this happened, and I still don't have an idea how it can be fixed. Just in case someone has a good idea. [Moved to plt-dev.] -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From eli at barzilay.org Tue Sep 1 18:06:39 2009 From: eli at barzilay.org (Eli Barzilay) Date: Tue Sep 1 18:07:00 2009 Subject: [plt-dev] Release for v4.2.2 is about to begin Message-ID: The release process for v4.2.2 will begin in about two weeks. If you have any new features that you want in and are relatively close to being done, now is a good time to do that. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From robby at eecs.northwestern.edu Tue Sep 1 18:23:17 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Tue Sep 1 18:23:43 2009 Subject: [plt-dev] Re: hosed doc search In-Reply-To: <19101.39565.657076.261021@winooski.ccs.neu.edu> References: <904774730909010618t45763075we67d8e9f462e6d7b@mail.gmail.com> <20090901141757.F11236500A8@mail-svr1.cs.utah.edu> <19101.39565.657076.261021@winooski.ccs.neu.edu> Message-ID: <932b2f1f0909011523w5857c8f6pcd172efd0f451515@mail.gmail.com> Can javascript not check to see if the file pointed at by PLT_Root exists and (if not) just pretend it isn't set? Robby On Tue, Sep 1, 2009 at 5:05 PM, Eli Barzilay wrote: > On Sep ?1, Matthew Flatt wrote: >> >> You might need to delete a cookie with "PLT_Root" in its name. >> >> I had to do that once after I installed a Planet package, opened >> docs with `plt-help', and then removed the version-specific >> subdirectory in my ".plt-scheme" directory. Searching got confused >> because the index file had disappeared, and the "PLT_Root" cookie >> points to that index file. > > This is not the first time this happened, and I still don't have an > idea how it can be fixed. ?Just in case someone has a good idea. > > [Moved to plt-dev.] > > -- > ? ? ? ? ?((lambda (x) (x x)) (lambda (x) (x x))) ? ? ? ? ?Eli Barzilay: > ? ? ? ? ? ? ? ? ? ?http://barzilay.org/ ? ? ? ? ? ? ? ? ? Maze is Life! > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > From eli at barzilay.org Tue Sep 1 18:35:14 2009 From: eli at barzilay.org (Eli Barzilay) Date: Tue Sep 1 18:35:36 2009 Subject: [plt-dev] Re: hosed doc search In-Reply-To: <932b2f1f0909011523w5857c8f6pcd172efd0f451515@mail.gmail.com> References: <904774730909010618t45763075we67d8e9f462e6d7b@mail.gmail.com> <20090901141757.F11236500A8@mail-svr1.cs.utah.edu> <19101.39565.657076.261021@winooski.ccs.neu.edu> <932b2f1f0909011523w5857c8f6pcd172efd0f451515@mail.gmail.com> Message-ID: <19101.41378.620696.982614@winooski.ccs.neu.edu> On Sep 1, Robby Findler wrote: > Can javascript not check to see if the file pointed at by PLT_Root > exists No way that I know of. (Something like that would make a bunch of things easier, but it's probably high up the list of what makes security problems.) > and (if not) just pretend it isn't set? -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From robby at eecs.northwestern.edu Wed Sep 2 00:34:11 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Wed Sep 2 00:34:29 2009 Subject: [plt-dev] Re: hosed doc search In-Reply-To: <19101.41378.620696.982614@winooski.ccs.neu.edu> References: <904774730909010618t45763075we67d8e9f462e6d7b@mail.gmail.com> <20090901141757.F11236500A8@mail-svr1.cs.utah.edu> <19101.39565.657076.261021@winooski.ccs.neu.edu> <932b2f1f0909011523w5857c8f6pcd172efd0f451515@mail.gmail.com> <19101.41378.620696.982614@winooski.ccs.neu.edu> Message-ID: <932b2f1f0909012134ld84725fmee47fde9b8111999@mail.gmail.com> 2009/9/1 Eli Barzilay : > On Sep ?1, Robby Findler wrote: >> Can javascript not check to see if the file pointed at by PLT_Root >> exists > > No way that I know of. ?(Something like that would make a bunch of > things easier, but it's probably high up the list of what makes > security problems.) Bizarro. You can send the file to the browser, but not check to see if the file exists... Robby From matthias at ccs.neu.edu Wed Sep 2 03:28:18 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Wed Sep 2 03:28:59 2009 Subject: [plt-dev] Re: hosed doc search In-Reply-To: <932b2f1f0909012134ld84725fmee47fde9b8111999@mail.gmail.com> References: <904774730909010618t45763075we67d8e9f462e6d7b@mail.gmail.com> <20090901141757.F11236500A8@mail-svr1.cs.utah.edu> <19101.39565.657076.261021@winooski.ccs.neu.edu> <932b2f1f0909011523w5857c8f6pcd172efd0f451515@mail.gmail.com> <19101.41378.620696.982614@winooski.ccs.neu.edu> <932b2f1f0909012134ld84725fmee47fde9b8111999@mail.gmail.com> Message-ID: <88A17D0A-C1B0-4B41-B8A8-A9DBDCAFC248@ccs.neu.edu> If Javascript has exceptions, you can encode this test. On Sep 2, 2009, at 12:34 AM, Robby Findler wrote: > 2009/9/1 Eli Barzilay : >> On Sep 1, Robby Findler wrote: >>> Can javascript not check to see if the file pointed at by PLT_Root >>> exists >> >> No way that I know of. (Something like that would make a bunch of >> things easier, but it's probably high up the list of what makes >> security problems.) > > Bizarro. You can send the file to the browser, but not check to see if > the file exists... > > Robby > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From robby at eecs.northwestern.edu Fri Sep 4 14:00:08 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Fri Sep 4 14:00:26 2009 Subject: [plt-dev] abstract contracts Message-ID: <932b2f1f0909041100t60fe99b9t173aa72cfd482b53@mail.gmail.com> I've added #:exists to provide/contract, as a way to hide information ala "type t" declarations on ML signatures. See the contracts section in the Guide for a worked example and a discussion of a gotcha. The short version is that you can now write things like this: (provide/contract #:exists stack [new stack] [push (-> int stack stack)] [pop (-> (and/c stack non-empty?) int)] [non-empty? (-> stack boolean?)]) and have the contract system enforce data abstraction, even if your stack operations are simply these: (define new '()) (define push cons) (define pop car) (define non-empty? pair?) That is, clients of your module will not be able to treat your stacks as if they were lists, even though they really are lists. Robby From matthias at ccs.neu.edu Sat Sep 5 11:02:12 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Sat Sep 5 11:02:45 2009 Subject: [plt-dev] abstract contracts In-Reply-To: <932b2f1f0909041100t60fe99b9t173aa72cfd482b53@mail.gmail.com> References: <932b2f1f0909041100t60fe99b9t173aa72cfd482b53@mail.gmail.com> Message-ID: <3D068A0E-AA6D-4DDC-9276-42AF987E64C4@ccs.neu.edu> Is there a stack? predicate afterwards? On Sep 4, 2009, at 2:00 PM, Robby Findler wrote: > I've added #:exists to provide/contract, as a way to hide information > ala "type t" declarations on ML signatures. > > See the contracts section in the Guide for a worked example and a > discussion of a gotcha. The short version is that you can now write > things like this: > > (provide/contract > #:exists stack > [new stack] > [push (-> int stack stack)] > [pop (-> (and/c stack non-empty?) int)] > [non-empty? (-> stack boolean?)]) > > and have the contract system enforce data abstraction, even if your > stack operations are simply these: > > (define new '()) > (define push cons) > (define pop car) > (define non-empty? pair?) > > That is, clients of your module will not be able to treat your stacks > as if they were lists, even though they really are lists. > > Robby > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From robby at eecs.northwestern.edu Sat Sep 5 18:04:49 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Sat Sep 5 18:05:10 2009 Subject: [plt-dev] abstract contracts In-Reply-To: <3D068A0E-AA6D-4DDC-9276-42AF987E64C4@ccs.neu.edu> References: <932b2f1f0909041100t60fe99b9t173aa72cfd482b53@mail.gmail.com> <3D068A0E-AA6D-4DDC-9276-42AF987E64C4@ccs.neu.edu> Message-ID: <932b2f1f0909051504m2d3e278dw5f63ea3a0ded01f3@mail.gmail.com> No. As we discussed, there can't be with this meaning of #:exists. If there were, you'd run into the same problem as with number? (for those that don't know what I'm talking about, see the new second gotcha section in the contracts documentation in the guide). But, if you want to protect yourself by shifting blame, you can still do that. You need to use the 'stack' contract in your own code to do so instead of using a predicate test. Robby On Sat, Sep 5, 2009 at 10:02 AM, Matthias Felleisen wrote: > > Is there a stack? predicate afterwards? > > On Sep 4, 2009, at 2:00 PM, Robby Findler wrote: > >> I've added #:exists to provide/contract, as a way to hide information >> ala "type t" declarations on ML signatures. >> >> See the contracts section in the Guide for a worked example and a >> discussion of a gotcha. The short version is that you can now write >> things like this: >> >> (provide/contract >> ?#:exists stack >> ?[new stack] >> ?[push (-> int stack stack)] >> ?[pop (-> (and/c stack non-empty?) int)] >> ?[non-empty? (-> stack boolean?)]) >> >> and have the contract system enforce data abstraction, even if your >> stack operations are simply these: >> >> ?(define new '()) >> ?(define push cons) >> ?(define pop car) >> ?(define non-empty? pair?) >> >> That is, clients of your module will not be able to treat your stacks >> as if they were lists, even though they really are lists. >> >> Robby >> _________________________________________________ >> ?For list-related administrative tasks: >> ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > > From matthias at ccs.neu.edu Sat Sep 5 20:58:31 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Sun Sep 6 09:55:46 2009 Subject: [plt-dev] abstract contracts In-Reply-To: <932b2f1f0909051504m2d3e278dw5f63ea3a0ded01f3@mail.gmail.com> References: <932b2f1f0909041100t60fe99b9t173aa72cfd482b53@mail.gmail.com> <3D068A0E-AA6D-4DDC-9276-42AF987E64C4@ccs.neu.edu> <932b2f1f0909051504m2d3e278dw5f63ea3a0ded01f3@mail.gmail.com> Message-ID: On Sep 5, 2009, at 6:04 PM, Robby Findler wrote: > No. As we discussed, there can't be with this meaning of #:exists. If > there were, you'd run into the same problem as with number? (for those > that don't know what I'm talking about, see the new second gotcha > section in the contracts documentation in the guide). > > But, if you want to protect yourself by shifting blame, you can still > do that. You need to use the 'stack' contract in your own code to do > so instead of using a predicate test. So the client can write additional contracts involving stacks, e.g., [stack-append (-> stack stack stack)] but it is impossible to write data definitions such as A collection is one of: -- stack -- queue and then use it because you can't distinguish a stack from a queue. (Of course, if both stacks and queues support the same operations, you can do this.) -- Matthias > Robby > > On Sat, Sep 5, 2009 at 10:02 AM, Matthias Felleisen > wrote: >> >> Is there a stack? predicate afterwards? >> >> On Sep 4, 2009, at 2:00 PM, Robby Findler wrote: >> >>> I've added #:exists to provide/contract, as a way to hide >>> information >>> ala "type t" declarations on ML signatures. >>> >>> See the contracts section in the Guide for a worked example and a >>> discussion of a gotcha. The short version is that you can now write >>> things like this: >>> >>> (provide/contract >>> #:exists stack >>> [new stack] >>> [push (-> int stack stack)] >>> [pop (-> (and/c stack non-empty?) int)] >>> [non-empty? (-> stack boolean?)]) >>> >>> and have the contract system enforce data abstraction, even if your >>> stack operations are simply these: >>> >>> (define new '()) >>> (define push cons) >>> (define pop car) >>> (define non-empty? pair?) >>> >>> That is, clients of your module will not be able to treat your >>> stacks >>> as if they were lists, even though they really are lists. >>> >>> Robby >>> _________________________________________________ >>> For list-related administrative tasks: >>> http://list.cs.brown.edu/mailman/listinfo/plt-dev >> >> From mflatt at cs.utah.edu Sun Sep 6 14:27:27 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Sun Sep 6 14:27:09 2009 Subject: [plt-dev] performance-oriented unsafe operations (v4.2.1.8) Message-ID: <20090906182649.BE90765010D@mail-svr1.cs.utah.edu> Version 4.2.1.8 (now in SVN) starts an experiment with performance-oriented unsafe operations. The new `scheme/unsafe/ops' library provides operations such as `unsafe-vector-ref' and `unsafe-fl+' (for inexact real addition) that are inlined by the JIT without contract checks. If a call violates the contract of a function from `scheme/unsafe/ops', arbitrarily bad things can happen. As long as contracts are satisfied, however, performance should be a little better than with corresponding safe operations. As part of the experiment, the expansion of `for' with `in-range' and `in-vector' now uses unsafe operations (in a safe way). For example, `in-vector' uses `unsafe-vector-ref' as well as a fixnum comparison for detecting when it has reached the end of a vector; it also uses unsafe fixnum arithmetic to increment the index as long as the step is 1 or -1 (in which case no overflow can occur during the increment). These improvements make a 10-20% difference in a tight loop over a vector. Future possible directions include making the JIT specialize combinations of inexact operations to avoid boxing intermediate results. The exports of `scheme/unsafe/ops' are protected, so that a code inspector can prevent access to unsafe operations by untrusted code. From rafkind at cs.utah.edu Sun Sep 6 15:44:52 2009 From: rafkind at cs.utah.edu (Jon Rafkind) Date: Sun Sep 6 15:46:58 2009 Subject: [plt-dev] performance-oriented unsafe operations (v4.2.1.8) In-Reply-To: <20090906182649.BE90765010D@mail-svr1.cs.utah.edu> References: <20090906182649.BE90765010D@mail-svr1.cs.utah.edu> Message-ID: <4AA41134.8000503@cs.utah.edu> Matthew Flatt wrote: > Version 4.2.1.8 (now in SVN) starts an experiment with > performance-oriented unsafe operations. > > The new `scheme/unsafe/ops' library provides operations such as > `unsafe-vector-ref' and `unsafe-fl+' (for inexact real addition) that > are inlined by the JIT without contract checks. If a call violates the > contract of a function from `scheme/unsafe/ops', arbitrarily bad > things can happen. As long as contracts are satisfied, however, > performance should be a little better than with corresponding safe > operations. > > As part of the experiment, the expansion of `for' with `in-range' and > `in-vector' now uses unsafe operations (in a safe way). For example, > `in-vector' uses `unsafe-vector-ref' as well as a fixnum comparison > for detecting when it has reached the end of a vector; it also uses > unsafe fixnum arithmetic to increment the index as long as the step is > 1 or -1 (in which case no overflow can occur during the > increment). These improvements make a 10-20% difference in a tight > loop over a vector. > > I get about a 25% speedup. dual-core amd64 running with a 32-bit ubuntu. pre-unsafe cpu time: 1040 real time: 1046 gc time: 72 cpu time: 1064 real time: 1089 gc time: 132 cpu time: 1000 real time: 1005 gc time: 8 cpu time: 940 real time: 954 gc time: 12 cpu time: 940 real time: 947 gc time: 0 unsafe: cpu time: 748 real time: 749 gc time: 20 cpu time: 732 real time: 738 gc time: 4 cpu time: 776 real time: 782 gc time: 44 cpu time: 736 real time: 749 gc time: 12 cpu time: 744 real time: 743 gc time: 8 code: (for/fold ([sum 0]) ([i (in-range 4000000)]) (+ sum i)) From m.douglas.williams at gmail.com Sun Sep 6 16:22:34 2009 From: m.douglas.williams at gmail.com (Doug Williams) Date: Sun Sep 6 16:22:57 2009 Subject: [plt-dev] performance-oriented unsafe operations (v4.2.1.8) In-Reply-To: <20090906182649.BE90765010D@mail-svr1.cs.utah.edu> References: <20090906182649.BE90765010D@mail-svr1.cs.utah.edu> Message-ID: Matthew, These look like good things for me to use for efficiency in the science collection. Will these these be in the upcoming 4.2.2 release? I assume that if I use these and introduce a dependency on 4.2.2 or later that I should also bump the version number of the science collection in PLaneT - even if the interface remains the same. Does that make sense? I guess the term 'experiment' here confuses me. Is this something that might go away again? Should I wait until everyone is comfortable with the results? Doug On Sun, Sep 6, 2009 at 12:27 PM, Matthew Flatt wrote: > Version 4.2.1.8 (now in SVN) starts an experiment with > performance-oriented unsafe operations. > > The new `scheme/unsafe/ops' library provides operations such as > `unsafe-vector-ref' and `unsafe-fl+' (for inexact real addition) that > are inlined by the JIT without contract checks. If a call violates the > contract of a function from `scheme/unsafe/ops', arbitrarily bad > things can happen. As long as contracts are satisfied, however, > performance should be a little better than with corresponding safe > operations. > > As part of the experiment, the expansion of `for' with `in-range' and > `in-vector' now uses unsafe operations (in a safe way). For example, > `in-vector' uses `unsafe-vector-ref' as well as a fixnum comparison > for detecting when it has reached the end of a vector; it also uses > unsafe fixnum arithmetic to increment the index as long as the step is > 1 or -1 (in which case no overflow can occur during the > increment). These improvements make a 10-20% difference in a tight > loop over a vector. > > Future possible directions include making the JIT specialize > combinations of inexact operations to avoid boxing intermediate > results. > > The exports of `scheme/unsafe/ops' are protected, so that a code > inspector can prevent access to unsafe operations by untrusted code. > > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090906/b5df38fe/attachment.html From robby at eecs.northwestern.edu Sun Sep 6 18:14:32 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Sun Sep 6 18:14:55 2009 Subject: [plt-dev] abstract contracts In-Reply-To: References: <932b2f1f0909041100t60fe99b9t173aa72cfd482b53@mail.gmail.com> <3D068A0E-AA6D-4DDC-9276-42AF987E64C4@ccs.neu.edu> <932b2f1f0909051504m2d3e278dw5f63ea3a0ded01f3@mail.gmail.com> Message-ID: <932b2f1f0909061514q1bb89dcenf056fe21b72d773f@mail.gmail.com> Right. That wouldn't be parametric. Robby On Sat, Sep 5, 2009 at 7:58 PM, Matthias Felleisen wrote: > > On Sep 5, 2009, at 6:04 PM, Robby Findler wrote: > >> No. As we discussed, there can't be with this meaning of #:exists. If >> there were, you'd run into the same problem as with number? (for those >> that don't know what I'm talking about, see the new second gotcha >> section in the contracts documentation in the guide). >> >> But, if you want to protect yourself by shifting blame, you can still >> do that. You need to use the 'stack' contract in your own code to do >> so instead of using a predicate test. > > So the client can write additional contracts involving stacks, e.g., > > ?[stack-append (-> stack stack stack)] > > but it is impossible to write data definitions such as > > ?A collection is one of: > ? -- stack > ? -- queue > > and then use it because you can't distinguish a stack from a queue. (Of > course, if both stacks and queues support the same operations, you can do > this.) > > -- Matthias > > > > >> Robby >> >> On Sat, Sep 5, 2009 at 10:02 AM, Matthias Felleisen >> wrote: >>> >>> Is there a stack? predicate afterwards? >>> >>> On Sep 4, 2009, at 2:00 PM, Robby Findler wrote: >>> >>>> I've added #:exists to provide/contract, as a way to hide information >>>> ala "type t" declarations on ML signatures. >>>> >>>> See the contracts section in the Guide for a worked example and a >>>> discussion of a gotcha. The short version is that you can now write >>>> things like this: >>>> >>>> (provide/contract >>>> ?#:exists stack >>>> ?[new stack] >>>> ?[push (-> int stack stack)] >>>> ?[pop (-> (and/c stack non-empty?) int)] >>>> ?[non-empty? (-> stack boolean?)]) >>>> >>>> and have the contract system enforce data abstraction, even if your >>>> stack operations are simply these: >>>> >>>> ?(define new '()) >>>> ?(define push cons) >>>> ?(define pop car) >>>> ?(define non-empty? pair?) >>>> >>>> That is, clients of your module will not be able to treat your stacks >>>> as if they were lists, even though they really are lists. >>>> >>>> Robby >>>> _________________________________________________ >>>> ?For list-related administrative tasks: >>>> ?http://list.cs.brown.edu/mailman/listinfo/plt-dev >>> >>> > > From mflatt at cs.utah.edu Sun Sep 6 19:14:46 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Sun Sep 6 19:14:26 2009 Subject: [plt-dev] performance-oriented unsafe operations (v4.2.1.8) In-Reply-To: References: <20090906182649.BE90765010D@mail-svr1.cs.utah.edu> Message-ID: <20090906231406.AD3996500EA@mail-svr1.cs.utah.edu> At Sun, 6 Sep 2009 14:22:34 -0600, Doug Williams wrote: > These look like good things for me to use for efficiency in the science > collection. Will these these be in the upcoming 4.2.2 release? Yes, that's the current plan. > I assume that if I use these and introduce a dependency on 4.2.2 or later > that I should also bump the version number of the science collection in > PLaneT - even if the interface remains the same. Does that make sense? No, I think you wouldn't change the major version, since there's no API change. > I guess the term 'experiment' here confuses me. Is this something that might > go away again? Should I wait until everyone is comfortable with the results? Well, we need your help experimenting... I think of it as an experiment in that I'm not sure that this is the right approach for better performance. But it seems worth a try, and if it works well for many purposes, then it'll stick. > On Sun, Sep 6, 2009 at 12:27 PM, Matthew Flatt wrote: > > > Version 4.2.1.8 (now in SVN) starts an experiment with > > performance-oriented unsafe operations. > > > > The new `scheme/unsafe/ops' library provides operations such as > > `unsafe-vector-ref' and `unsafe-fl+' (for inexact real addition) that > > are inlined by the JIT without contract checks. If a call violates the > > contract of a function from `scheme/unsafe/ops', arbitrarily bad > > things can happen. As long as contracts are satisfied, however, > > performance should be a little better than with corresponding safe > > operations. > > > > As part of the experiment, the expansion of `for' with `in-range' and > > `in-vector' now uses unsafe operations (in a safe way). For example, > > `in-vector' uses `unsafe-vector-ref' as well as a fixnum comparison > > for detecting when it has reached the end of a vector; it also uses > > unsafe fixnum arithmetic to increment the index as long as the step is > > 1 or -1 (in which case no overflow can occur during the > > increment). These improvements make a 10-20% difference in a tight > > loop over a vector. > > > > Future possible directions include making the JIT specialize > > combinations of inexact operations to avoid boxing intermediate > > results. > > > > The exports of `scheme/unsafe/ops' are protected, so that a code > > inspector can prevent access to unsafe operations by untrusted code. From robby at eecs.northwestern.edu Sun Sep 6 20:10:17 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Sun Sep 6 20:10:35 2009 Subject: [plt-dev] performance-oriented unsafe operations (v4.2.1.8) In-Reply-To: <20090906231406.AD3996500EA@mail-svr1.cs.utah.edu> References: <20090906182649.BE90765010D@mail-svr1.cs.utah.edu> <20090906231406.AD3996500EA@mail-svr1.cs.utah.edu> Message-ID: <932b2f1f0909061710s1c1337b1pfe2696a331f8b1ae@mail.gmail.com> On Sun, Sep 6, 2009 at 6:14 PM, Matthew Flatt wrote: > At Sun, 6 Sep 2009 14:22:34 -0600, Doug Williams wrote: >> I assume that if I use these and introduce a dependency on 4.2.2 or later >> that I should also bump the version number of the science collection in >> PLaneT - even if the interface remains the same. Does that make sense? > > No, I think you wouldn't change the major version, since there's no API > change. You would, however, add a constraint that the latest version of the science collection depends on 4.2.2 and so people using 4.2.1 (and lower) wouldn't see that new version. Robby From m.douglas.williams at gmail.com Sun Sep 6 20:59:01 2009 From: m.douglas.williams at gmail.com (Doug Williams) Date: Sun Sep 6 20:59:21 2009 Subject: [plt-dev] performance-oriented unsafe operations (v4.2.1.8) In-Reply-To: <932b2f1f0909061710s1c1337b1pfe2696a331f8b1ae@mail.gmail.com> References: <20090906182649.BE90765010D@mail-svr1.cs.utah.edu> <20090906231406.AD3996500EA@mail-svr1.cs.utah.edu> <932b2f1f0909061710s1c1337b1pfe2696a331f8b1ae@mail.gmail.com> Message-ID: I will do that. One other thing that is really just semantics. Would it be better to call the operations 'unchecked-' instead of 'unsafe-'? Generally, we are calling the function because we know it is safe to avoid some constraint check - not because it is unsafe. Just a nit. Doug On Sun, Sep 6, 2009 at 6:10 PM, Robby Findler wrote: > On Sun, Sep 6, 2009 at 6:14 PM, Matthew Flatt wrote: > > At Sun, 6 Sep 2009 14:22:34 -0600, Doug Williams wrote: > >> I assume that if I use these and introduce a dependency on 4.2.2 or > later > >> that I should also bump the version number of the science collection in > >> PLaneT - even if the interface remains the same. Does that make sense? > > > > No, I think you wouldn't change the major version, since there's no API > > change. > > You would, however, add a constraint that the latest version of the > science collection depends on 4.2.2 and so people using 4.2.1 (and > lower) wouldn't see that new version. > > Robby > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090906/9d950664/attachment-0001.htm From carl.eastlund at gmail.com Mon Sep 7 06:20:50 2009 From: carl.eastlund at gmail.com (Carl Eastlund) Date: Mon Sep 7 06:41:44 2009 Subject: [plt-dev] performance-oriented unsafe operations (v4.2.1.8) In-Reply-To: References: <20090906182649.BE90765010D@mail-svr1.cs.utah.edu> <20090906231406.AD3996500EA@mail-svr1.cs.utah.edu> <932b2f1f0909061710s1c1337b1pfe2696a331f8b1ae@mail.gmail.com> Message-ID: <990e0c030909070320k3a02d152sd1434554409c0b35@mail.gmail.com> On Mon, Sep 7, 2009 at 1:59 AM, Doug Williams wrote: > One other thing that is really just semantics. Actually, that's just syntax. ;) On this list, semantics is the important stuff. > Would it be better to call > the operations 'unchecked-' instead of 'unsafe-'? > Generally, we are calling the function because we know it is safe to avoid > some constraint check - not because it is unsafe. Just a nit. --Carl From jacobm at cs.uchicago.edu Mon Sep 7 14:01:40 2009 From: jacobm at cs.uchicago.edu (Jacob Matthews) Date: Mon Sep 7 14:07:56 2009 Subject: [plt-dev] abstract contracts In-Reply-To: <932b2f1f0909061514q1bb89dcenf056fe21b72d773f@mail.gmail.com> References: <932b2f1f0909041100t60fe99b9t173aa72cfd482b53@mail.gmail.com> <3D068A0E-AA6D-4DDC-9276-42AF987E64C4@ccs.neu.edu> <932b2f1f0909051504m2d3e278dw5f63ea3a0ded01f3@mail.gmail.com> <932b2f1f0909061514q1bb89dcenf056fe21b72d773f@mail.gmail.com> Message-ID: <46b603df0909071101h506ce7f0t65c292fea5ada838@mail.gmail.com> On Sun, Sep 6, 2009 at 3:14 PM, Robby Findler wrote: > Right. That wouldn't be parametric. I think it's the contracts-don't-change-programs condition, not the parametricity condition, that would be violated here. -jacob > > Robby > > On Sat, Sep 5, 2009 at 7:58 PM, Matthias Felleisen wrote: >> >> On Sep 5, 2009, at 6:04 PM, Robby Findler wrote: >> >>> No. As we discussed, there can't be with this meaning of #:exists. If >>> there were, you'd run into the same problem as with number? (for those >>> that don't know what I'm talking about, see the new second gotcha >>> section in the contracts documentation in the guide). >>> >>> But, if you want to protect yourself by shifting blame, you can still >>> do that. You need to use the 'stack' contract in your own code to do >>> so instead of using a predicate test. >> >> So the client can write additional contracts involving stacks, e.g., >> >> ?[stack-append (-> stack stack stack)] >> >> but it is impossible to write data definitions such as >> >> ?A collection is one of: >> ? -- stack >> ? -- queue >> >> and then use it because you can't distinguish a stack from a queue. (Of >> course, if both stacks and queues support the same operations, you can do >> this.) >> >> -- Matthias >> >> >> >> >>> Robby >>> >>> On Sat, Sep 5, 2009 at 10:02 AM, Matthias Felleisen >>> wrote: >>>> >>>> Is there a stack? predicate afterwards? >>>> >>>> On Sep 4, 2009, at 2:00 PM, Robby Findler wrote: >>>> >>>>> I've added #:exists to provide/contract, as a way to hide information >>>>> ala "type t" declarations on ML signatures. >>>>> >>>>> See the contracts section in the Guide for a worked example and a >>>>> discussion of a gotcha. The short version is that you can now write >>>>> things like this: >>>>> >>>>> (provide/contract >>>>> ?#:exists stack >>>>> ?[new stack] >>>>> ?[push (-> int stack stack)] >>>>> ?[pop (-> (and/c stack non-empty?) int)] >>>>> ?[non-empty? (-> stack boolean?)]) >>>>> >>>>> and have the contract system enforce data abstraction, even if your >>>>> stack operations are simply these: >>>>> >>>>> ?(define new '()) >>>>> ?(define push cons) >>>>> ?(define pop car) >>>>> ?(define non-empty? pair?) >>>>> >>>>> That is, clients of your module will not be able to treat your stacks >>>>> as if they were lists, even though they really are lists. >>>>> >>>>> Robby >>>>> _________________________________________________ >>>>> ?For list-related administrative tasks: >>>>> ?http://list.cs.brown.edu/mailman/listinfo/plt-dev >>>> >>>> >> >> > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > > From fahree at gmail.com Mon Sep 7 14:11:57 2009 From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=) Date: Mon Sep 7 14:12:40 2009 Subject: [plt-dev] performance-oriented unsafe operations (v4.2.1.8) In-Reply-To: <990e0c030909070320k3a02d152sd1434554409c0b35@mail.gmail.com> References: <20090906182649.BE90765010D@mail-svr1.cs.utah.edu> <20090906231406.AD3996500EA@mail-svr1.cs.utah.edu> <932b2f1f0909061710s1c1337b1pfe2696a331f8b1ae@mail.gmail.com> <990e0c030909070320k3a02d152sd1434554409c0b35@mail.gmail.com> Message-ID: <653bea160909071111w1ca0c51em59bec8564b327994@mail.gmail.com> Maybe it's better to keep the very same name as the safe operation, and let whoever imports it choose a different prefix. The immediate benefit is that switching from safe to unsafe becomes trivial, which is great for developing and testing in safe mode but delivering and running in unsafe mode. What will be interesting is to see if TypedScheme modules allow to squeeze extra performance by expanding to unsafe operations. [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] If it's not worth doing right, it's not worth doing. -- Scott McKay 2009/9/7 Carl Eastlund : > On Mon, Sep 7, 2009 at 1:59 AM, Doug > Williams wrote: >> One other thing that is really just semantics. > > Actually, that's just syntax. ?;) > > On this list, semantics is the important stuff. > >> Would it be better to call >> the operations 'unchecked-' instead of 'unsafe-'? >> Generally, we are calling the function because we know it is safe to avoid >> some constraint check - not because it is unsafe. Just a nit. > > --Carl From eli at barzilay.org Mon Sep 7 17:13:59 2009 From: eli at barzilay.org (Eli Barzilay) Date: Mon Sep 7 17:14:21 2009 Subject: [plt-dev] performance-oriented unsafe operations (v4.2.1.8) In-Reply-To: <653bea160909071111w1ca0c51em59bec8564b327994@mail.gmail.com> References: <20090906182649.BE90765010D@mail-svr1.cs.utah.edu> <20090906231406.AD3996500EA@mail-svr1.cs.utah.edu> <932b2f1f0909061710s1c1337b1pfe2696a331f8b1ae@mail.gmail.com> <990e0c030909070320k3a02d152sd1434554409c0b35@mail.gmail.com> <653bea160909071111w1ca0c51em59bec8564b327994@mail.gmail.com> Message-ID: <19109.30615.356819.900688@winooski.ccs.neu.edu> On Sep 7, Far? wrote: > Maybe it's better to keep the very same name as the safe operation, > and let whoever imports it choose a different prefix. The immediate > benefit is that switching from safe to unsafe becomes trivial, which > is great for developing and testing in safe mode but delivering and > running in unsafe mode. That was one of the options to implementing this, but I think that it is a little less convenient. There is also an issue with some of the operators that have no safe edquivalents -- for example, there is no `fl*' function. In any case, there is the `filtered-in' form for requiring modules (from the `scheme/require' module) that can be used to achieve the same effect: Welcome to MzScheme v4.2.1.8 [3m], Copyright (c) 2004-2009 PLT Scheme Inc. > (require scheme/require (filtered-in (lambda (s) (let ([m (regexp-match #rx"^unsafe-(.*)$" s)]) (and m (cadr m)))) scheme/unsafe/ops)) > (car 3) SIGSEGV fault on 0xf zsh: abort mz And, of course, going from here to defining an unsafe language like you want is easy. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From m.douglas.williams at gmail.com Mon Sep 7 19:09:05 2009 From: m.douglas.williams at gmail.com (Doug Williams) Date: Mon Sep 7 19:09:27 2009 Subject: [plt-dev] performance-oriented unsafe operations (v4.2.1.8) In-Reply-To: <653bea160909071111w1ca0c51em59bec8564b327994@mail.gmail.com> References: <20090906182649.BE90765010D@mail-svr1.cs.utah.edu> <20090906231406.AD3996500EA@mail-svr1.cs.utah.edu> <932b2f1f0909061710s1c1337b1pfe2696a331f8b1ae@mail.gmail.com> <990e0c030909070320k3a02d152sd1434554409c0b35@mail.gmail.com> <653bea160909071111w1ca0c51em59bec8564b327994@mail.gmail.com> Message-ID: In this case, I prefer having a nice, ugly name with something like unsafe or unchecked in it. And, I want it at the point the unsafe/unchecked operation is being done. For production code, it's important for whoever wants to understand (i.e., maintain) it later to know the intent and its implications. Changing between them (generally) should not be a trivial decision. Doug On Mon, Sep 7, 2009 at 12:11 PM, Far? wrote: > Maybe it's better to keep the very same name as the safe operation, > and let whoever imports it choose a different prefix. The immediate > benefit is that switching from safe to unsafe becomes trivial, which > is great for developing and testing in safe mode but delivering and > running in unsafe mode. > > What will be interesting is to see if TypedScheme modules allow to > squeeze extra performance by expanding to unsafe operations. > > [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | > http://fare.tunes.org ] > If it's not worth doing right, it's not worth doing. -- Scott McKay > > > > > 2009/9/7 Carl Eastlund : > > On Mon, Sep 7, 2009 at 1:59 AM, Doug > > Williams wrote: > >> One other thing that is really just semantics. > > > > Actually, that's just syntax. ;) > > > > On this list, semantics is the important stuff. > > > >> Would it be better to call > >> the operations 'unchecked-' instead of 'unsafe-'? > >> Generally, we are calling the function because we know it is safe to > avoid > >> some constraint check - not because it is unsafe. Just a nit. > > > > --Carl > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090907/1a9099e2/attachment.html From carl.eastlund at gmail.com Tue Sep 8 04:36:10 2009 From: carl.eastlund at gmail.com (Carl Eastlund) Date: Tue Sep 8 04:36:48 2009 Subject: [plt-dev] abstract contracts In-Reply-To: <46b603df0909071101h506ce7f0t65c292fea5ada838@mail.gmail.com> References: <932b2f1f0909041100t60fe99b9t173aa72cfd482b53@mail.gmail.com> <3D068A0E-AA6D-4DDC-9276-42AF987E64C4@ccs.neu.edu> <932b2f1f0909051504m2d3e278dw5f63ea3a0ded01f3@mail.gmail.com> <932b2f1f0909061514q1bb89dcenf056fe21b72d773f@mail.gmail.com> <46b603df0909071101h506ce7f0t65c292fea5ada838@mail.gmail.com> Message-ID: <990e0c030909080136m2d3a07a2q6ad25b1539ecf65b@mail.gmail.com> On Mon, Sep 7, 2009 at 7:01 PM, Jacob Matthews wrote: > On Sun, Sep 6, 2009 at 3:14 PM, Robby > Findler wrote: >> Right. That wouldn't be parametric. > > I think it's the contracts-don't-change-programs condition, not the > parametricity condition, that would be violated here. > > -jacob Don't these contracts already change the program? I thought, since Robby indicated that "stacks" cannot be used as lists, these contracts would be wrapping the values in opaque structs for outside observers. Adding or removing the contracts changes how a list-implemented stack responds to list?. Or have I misunderstood the behavior of #:exists contracts? --Carl From robby at eecs.northwestern.edu Tue Sep 8 08:17:15 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Tue Sep 8 08:17:36 2009 Subject: [plt-dev] abstract contracts In-Reply-To: <990e0c030909080136m2d3a07a2q6ad25b1539ecf65b@mail.gmail.com> References: <932b2f1f0909041100t60fe99b9t173aa72cfd482b53@mail.gmail.com> <3D068A0E-AA6D-4DDC-9276-42AF987E64C4@ccs.neu.edu> <932b2f1f0909051504m2d3e278dw5f63ea3a0ded01f3@mail.gmail.com> <932b2f1f0909061514q1bb89dcenf056fe21b72d773f@mail.gmail.com> <46b603df0909071101h506ce7f0t65c292fea5ada838@mail.gmail.com> <990e0c030909080136m2d3a07a2q6ad25b1539ecf65b@mail.gmail.com> Message-ID: <932b2f1f0909080517x26cabc5bp269fd87de1644d78@mail.gmail.com> On Tue, Sep 8, 2009 at 3:36 AM, Carl Eastlund wrote: > On Mon, Sep 7, 2009 at 7:01 PM, Jacob Matthews wrote: >> On Sun, Sep 6, 2009 at 3:14 PM, Robby >> Findler wrote: >>> Right. That wouldn't be parametric. >> >> I think it's the contracts-don't-change-programs condition, not the >> parametricity condition, that would be violated here. >> >> -jacob > > Don't these contracts already change the program? ?I thought, since > Robby indicated that "stacks" cannot be used as lists, these contracts > would be wrapping the values in opaque structs for outside observers. > Adding or removing the contracts changes how a list-implemented stack > responds to list?. ?Or have I misunderstood the behavior of #:exists > contracts? You have understood. list? is a problem. It should blow up on these contracts and, if you use the scheme/exists language (as mentioned in the docs I pointed to) it would blow up. Robby From matthias at ccs.neu.edu Tue Sep 8 08:18:07 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Tue Sep 8 08:18:42 2009 Subject: [plt-dev] abstract contracts In-Reply-To: <990e0c030909080136m2d3a07a2q6ad25b1539ecf65b@mail.gmail.com> References: <932b2f1f0909041100t60fe99b9t173aa72cfd482b53@mail.gmail.com> <3D068A0E-AA6D-4DDC-9276-42AF987E64C4@ccs.neu.edu> <932b2f1f0909051504m2d3e278dw5f63ea3a0ded01f3@mail.gmail.com> <932b2f1f0909061514q1bb89dcenf056fe21b72d773f@mail.gmail.com> <46b603df0909071101h506ce7f0t65c292fea5ada838@mail.gmail.com> <990e0c030909080136m2d3a07a2q6ad25b1539ecf65b@mail.gmail.com> Message-ID: <91A12ADA-257D-47A2-B172-7D752F7EBAA2@ccs.neu.edu> On Sep 8, 2009, at 4:36 AM, Carl Eastlund wrote: > On Mon, Sep 7, 2009 at 7:01 PM, Jacob > Matthews wrote: >> On Sun, Sep 6, 2009 at 3:14 PM, Robby >> Findler wrote: >>> Right. That wouldn't be parametric. >> >> I think it's the contracts-don't-change-programs condition, not the >> parametricity condition, that would be violated here. >> >> -jacob > > Don't these contracts already change the program? I thought, since > Robby indicated that "stacks" cannot be used as lists, these contracts > would be wrapping the values in opaque structs for outside observers. > Adding or removing the contracts changes how a list-implemented stack > responds to list?. Or have I misunderstood the behavior of #:exists > contracts? They do in the sense that (if (pair? stack) (launch-nuclear-missile #:target 'HydePark@Chicago) (printf "hello world")) produces two different results if you remove #:exists naively. I assume that Robby has a mechanism that says #:wrap-automatically and is the 'replacement' of contracts in plain provide in order to avoid the destruction of his neighborhood. Thanks for reminding me of this. Sam and I had an example like this that explained why we couldn't use plain polymorphic contracts to control exports from Typed Scheme. -- Matthias From robby at eecs.northwestern.edu Tue Sep 8 08:21:09 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Tue Sep 8 08:21:27 2009 Subject: [plt-dev] abstract contracts In-Reply-To: <91A12ADA-257D-47A2-B172-7D752F7EBAA2@ccs.neu.edu> References: <932b2f1f0909041100t60fe99b9t173aa72cfd482b53@mail.gmail.com> <3D068A0E-AA6D-4DDC-9276-42AF987E64C4@ccs.neu.edu> <932b2f1f0909051504m2d3e278dw5f63ea3a0ded01f3@mail.gmail.com> <932b2f1f0909061514q1bb89dcenf056fe21b72d773f@mail.gmail.com> <46b603df0909071101h506ce7f0t65c292fea5ada838@mail.gmail.com> <990e0c030909080136m2d3a07a2q6ad25b1539ecf65b@mail.gmail.com> <91A12ADA-257D-47A2-B172-7D752F7EBAA2@ccs.neu.edu> Message-ID: <932b2f1f0909080521k71e05d08g8470298c6484bdb9@mail.gmail.com> On Tue, Sep 8, 2009 at 7:18 AM, Matthias Felleisen wrote: > Thanks for reminding me of this. Sam and I had an example like this > that explained why we couldn't use plain polymorphic contracts to > control exports from Typed Scheme. I don't see how an example along these lines would make typed scheme unsound. (Such examples still behave parametrically polymorphically.) Robby From cce at ccs.neu.edu Tue Sep 8 19:01:24 2009 From: cce at ccs.neu.edu (Carl Eastlund) Date: Tue Sep 8 19:02:11 2009 Subject: [plt-dev] Mysterious "link: module mismatch" bug Message-ID: <990e0c030909081601q2edc8e02u18fab6141c334601@mail.gmail.com> Running code in DrScheme from one of my planet development links, I get this familiar error: link: module mismatch, probably from old bytecode whose dependencies have changed: variable not provided (directly or indirectly and at the expected position) from module: "/Users/cce/research/planet/scheme/syntax.ss" accessed from module: "/Users/cce/research/planet/scheme/require-provide.ss" at source phase level: 0 in: provide/contract-contract-id-make-planet-path.62 The usual process to fix this is to recompile the relevant files. I have now twice cleaned out all compiled files from my planet development links and run a full 'setup-plt' to restore them, and the message has not gone away. What could be causing this, if the .zo files are all up to date? Carl Eastlund From robby at eecs.northwestern.edu Tue Sep 8 19:21:30 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Tue Sep 8 19:21:53 2009 Subject: [plt-dev] Mysterious "link: module mismatch" bug In-Reply-To: <990e0c030909081601q2edc8e02u18fab6141c334601@mail.gmail.com> References: <990e0c030909081601q2edc8e02u18fab6141c334601@mail.gmail.com> Message-ID: <932b2f1f0909081621k246d5137qa65dc3620e96b62b@mail.gmail.com> Likely the files in compiled/drscheme/ are out of date. Why cm isn't bringing them back into sync is unclear to me, but you can at least get out of the bad loop by deleting those directories. Robby On Tue, Sep 8, 2009 at 6:01 PM, Carl Eastlund wrote: > Running code in DrScheme from one of my planet development links, I > get this familiar error: > > link: module mismatch, probably from old bytecode whose dependencies > have changed: variable not provided (directly or indirectly and at the > expected position) from module: > "/Users/cce/research/planet/scheme/syntax.ss" accessed from module: > "/Users/cce/research/planet/scheme/require-provide.ss" at source phase > level: 0 in: provide/contract-contract-id-make-planet-path.62 > > The usual process to fix this is to recompile the relevant files. ?I > have now twice cleaned out all compiled files from my planet > development links and run a full 'setup-plt' to restore them, and the > message has not gone away. ?What could be causing this, if the .zo > files are all up to date? > > Carl Eastlund > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > From cce at ccs.neu.edu Tue Sep 8 20:04:20 2009 From: cce at ccs.neu.edu (Carl Eastlund) Date: Tue Sep 8 20:04:58 2009 Subject: [plt-dev] Mysterious "link: module mismatch" bug In-Reply-To: <932b2f1f0909081621k246d5137qa65dc3620e96b62b@mail.gmail.com> References: <990e0c030909081601q2edc8e02u18fab6141c334601@mail.gmail.com> <932b2f1f0909081621k246d5137qa65dc3620e96b62b@mail.gmail.com> Message-ID: <990e0c030909081704l79122a0cu43ab792292dc746c@mail.gmail.com> The cleanup I did each time involved rm -r of the compiled/ directories, so the drscheme/ subdirectories were gone as well. --Carl On Wed, Sep 9, 2009 at 12:21 AM, Robby Findler wrote: > Likely the files in compiled/drscheme/ are out of date. Why cm isn't > bringing them back into sync is unclear to me, but you can at least > get out of the bad loop by deleting those directories. > > Robby > > On Tue, Sep 8, 2009 at 6:01 PM, Carl Eastlund wrote: >> Running code in DrScheme from one of my planet development links, I >> get this familiar error: >> >> link: module mismatch, probably from old bytecode whose dependencies >> have changed: variable not provided (directly or indirectly and at the >> expected position) from module: >> "/Users/cce/research/planet/scheme/syntax.ss" accessed from module: >> "/Users/cce/research/planet/scheme/require-provide.ss" at source phase >> level: 0 in: provide/contract-contract-id-make-planet-path.62 >> >> The usual process to fix this is to recompile the relevant files. ?I >> have now twice cleaned out all compiled files from my planet >> development links and run a full 'setup-plt' to restore them, and the >> message has not gone away. ?What could be causing this, if the .zo >> files are all up to date? >> >> Carl Eastlund From robby at eecs.northwestern.edu Tue Sep 8 20:36:08 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Tue Sep 8 20:36:26 2009 Subject: [plt-dev] Mysterious "link: module mismatch" bug In-Reply-To: <990e0c030909081704l79122a0cu43ab792292dc746c@mail.gmail.com> References: <990e0c030909081601q2edc8e02u18fab6141c334601@mail.gmail.com> <932b2f1f0909081621k246d5137qa65dc3620e96b62b@mail.gmail.com> <990e0c030909081704l79122a0cu43ab792292dc746c@mail.gmail.com> Message-ID: <932b2f1f0909081736o4ce2588avb4041997f50c76e2@mail.gmail.com> Do you get the error when you run from outside of DrScheme? Robby On Tue, Sep 8, 2009 at 7:04 PM, Carl Eastlund wrote: > The cleanup I did each time involved rm -r of the compiled/ > directories, so the drscheme/ subdirectories were gone as well. > > --Carl > > On Wed, Sep 9, 2009 at 12:21 AM, Robby > Findler wrote: >> Likely the files in compiled/drscheme/ are out of date. Why cm isn't >> bringing them back into sync is unclear to me, but you can at least >> get out of the bad loop by deleting those directories. >> >> Robby >> >> On Tue, Sep 8, 2009 at 6:01 PM, Carl Eastlund wrote: >>> Running code in DrScheme from one of my planet development links, I >>> get this familiar error: >>> >>> link: module mismatch, probably from old bytecode whose dependencies >>> have changed: variable not provided (directly or indirectly and at the >>> expected position) from module: >>> "/Users/cce/research/planet/scheme/syntax.ss" accessed from module: >>> "/Users/cce/research/planet/scheme/require-provide.ss" at source phase >>> level: 0 in: provide/contract-contract-id-make-planet-path.62 >>> >>> The usual process to fix this is to recompile the relevant files. ?I >>> have now twice cleaned out all compiled files from my planet >>> development links and run a full 'setup-plt' to restore them, and the >>> message has not gone away. ?What could be causing this, if the .zo >>> files are all up to date? >>> >>> Carl Eastlund > From m.douglas.williams at gmail.com Tue Sep 8 20:57:23 2009 From: m.douglas.williams at gmail.com (Doug Williams) Date: Tue Sep 8 20:57:47 2009 Subject: [plt-dev] Mysterious "link: module mismatch" bug In-Reply-To: <932b2f1f0909081736o4ce2588avb4041997f50c76e2@mail.gmail.com> References: <990e0c030909081601q2edc8e02u18fab6141c334601@mail.gmail.com> <932b2f1f0909081621k246d5137qa65dc3620e96b62b@mail.gmail.com> <990e0c030909081704l79122a0cu43ab792292dc746c@mail.gmail.com> <932b2f1f0909081736o4ce2588avb4041997f50c76e2@mail.gmail.com> Message-ID: I have had a similar problem that requires me to roll back to 4.1.5 for some of my code. I've tracked it down to the following code where I've using eval to build a procedure from piece parts when constructing a rule network. [They parts don't (necessarily) exist in the same syntactic construct, so I can't build them in the rule macro and have to do it when building the rule network.] It now fails (post 4.1.5) if the the rule actions contain references things to another module. (eval `(lambda ,previous-variable-list (begin ,@(rule-actions rule))) (namespace-anchor->namespace anchor))) The error given is: farmer.ss:26:11: link: module mismatch, probably from old bytecode whose dependencies have changed: variable not provided (directly or indirectly) from module: "C:\Documents and Settings\dwilliams\Application Data\PLT Scheme\planet\300\4.2.0.900\ cache\williams\science.plt\3\5\random-distributions\triangular.ss" accessed from module: "C:\Documents and Settings\dwilliams\Application Data\PLT Scheme\planet\300\4.2.0.900\cache\williams\inference.plt\2\0\private\inference-control.ss" at source phase level: 0 in: random-triangular In this case, random-triangular is defined in a required package. I suspect it is something different with namespace-anchor->namespace or something along those lines. Any ideas? Doug On Tue, Sep 8, 2009 at 6:36 PM, Robby Findler wrote: > Do you get the error when you run from outside of DrScheme? > > Robby > > On Tue, Sep 8, 2009 at 7:04 PM, Carl Eastlund wrote: > > The cleanup I did each time involved rm -r of the compiled/ > > directories, so the drscheme/ subdirectories were gone as well. > > > > --Carl > > > > On Wed, Sep 9, 2009 at 12:21 AM, Robby > > Findler wrote: > >> Likely the files in compiled/drscheme/ are out of date. Why cm isn't > >> bringing them back into sync is unclear to me, but you can at least > >> get out of the bad loop by deleting those directories. > >> > >> Robby > >> > >> On Tue, Sep 8, 2009 at 6:01 PM, Carl Eastlund wrote: > >>> Running code in DrScheme from one of my planet development links, I > >>> get this familiar error: > >>> > >>> link: module mismatch, probably from old bytecode whose dependencies > >>> have changed: variable not provided (directly or indirectly and at the > >>> expected position) from module: > >>> "/Users/cce/research/planet/scheme/syntax.ss" accessed from module: > >>> "/Users/cce/research/planet/scheme/require-provide.ss" at source phase > >>> level: 0 in: provide/contract-contract-id-make-planet-path.62 > >>> > >>> The usual process to fix this is to recompile the relevant files. I > >>> have now twice cleaned out all compiled files from my planet > >>> development links and run a full 'setup-plt' to restore them, and the > >>> message has not gone away. What could be causing this, if the .zo > >>> files are all up to date? > >>> > >>> Carl Eastlund > > > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090908/3d9cfbe7/attachment.htm From robby at eecs.northwestern.edu Tue Sep 8 22:35:16 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Tue Sep 8 22:35:35 2009 Subject: [plt-dev] another tweak to automatic compilation Message-ID: <932b2f1f0909081935w7e15e7bey78aaed63a721c23c@mail.gmail.com> The automatic compilation stuff in DrScheme now avoids installed planet files (but still compiles stuff inside planet development links). Robby From cce at ccs.neu.edu Wed Sep 9 06:04:29 2009 From: cce at ccs.neu.edu (Carl Eastlund) Date: Wed Sep 9 06:05:07 2009 Subject: [plt-dev] Mysterious "link: module mismatch" bug In-Reply-To: <932b2f1f0909081736o4ce2588avb4041997f50c76e2@mail.gmail.com> References: <990e0c030909081601q2edc8e02u18fab6141c334601@mail.gmail.com> <932b2f1f0909081621k246d5137qa65dc3620e96b62b@mail.gmail.com> <990e0c030909081704l79122a0cu43ab792292dc746c@mail.gmail.com> <932b2f1f0909081736o4ce2588avb4041997f50c76e2@mail.gmail.com> Message-ID: <990e0c030909090304s37e4aacbh364c336d3b6f0070@mail.gmail.com> No, when I disable the GUI dependencies it still gets the error in DrScheme but runs just fine in MzScheme. Carl Eastlund On Wed, Sep 9, 2009 at 1:36 AM, Robby Findler wrote: > Do you get the error when you run from outside of DrScheme? > > Robby > > On Tue, Sep 8, 2009 at 7:04 PM, Carl Eastlund wrote: >> The cleanup I did each time involved rm -r of the compiled/ >> directories, so the drscheme/ subdirectories were gone as well. >> >> --Carl >> >> On Wed, Sep 9, 2009 at 12:21 AM, Robby >> Findler wrote: >>> Likely the files in compiled/drscheme/ are out of date. Why cm isn't >>> bringing them back into sync is unclear to me, but you can at least >>> get out of the bad loop by deleting those directories. >>> >>> Robby >>> >>> On Tue, Sep 8, 2009 at 6:01 PM, Carl Eastlund wrote: >>>> Running code in DrScheme from one of my planet development links, I >>>> get this familiar error: >>>> >>>> link: module mismatch, probably from old bytecode whose dependencies >>>> have changed: variable not provided (directly or indirectly and at the >>>> expected position) from module: >>>> "/Users/cce/research/planet/scheme/syntax.ss" accessed from module: >>>> "/Users/cce/research/planet/scheme/require-provide.ss" at source phase >>>> level: 0 in: provide/contract-contract-id-make-planet-path.62 >>>> >>>> The usual process to fix this is to recompile the relevant files. ?I >>>> have now twice cleaned out all compiled files from my planet >>>> development links and run a full 'setup-plt' to restore them, and the >>>> message has not gone away. ?What could be causing this, if the .zo >>>> files are all up to date? >>>> >>>> Carl Eastlund From eli at barzilay.org Wed Sep 9 11:33:57 2009 From: eli at barzilay.org (Eli Barzilay) Date: Wed Sep 9 11:34:17 2009 Subject: [plt-dev] Release for v4.2.2 is about to begin Message-ID: The release process for v4.2.2 will begin in about one week. 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. >> NOW IS THE TIME TO FIX BUGS THAT YOU KNOW ABOUT <<< The time between the branch and the actual release is for fixing new errors that prevent a proper functioning of major components and that show up during the preparation for a release. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From eli at barzilay.org Wed Sep 9 19:16:38 2009 From: eli at barzilay.org (Eli Barzilay) Date: Wed Sep 9 19:17:02 2009 Subject: [plt-dev] Re: preliminary "Snow Leopard" report In-Reply-To: <4C6C0024-AF4F-417E-A502-5F90FB4F4D98@brinckerhoff.org> References: <8E764499-A87B-4E88-A426-E724202784C9@brinckerhoff.org> <49E6B4A7-333C-467B-9BCF-79EFC2263B40@brinckerhoff.org> <20090905115245.43F636500EA@mail-svr1.cs.utah.edu> <4B69F577-0720-4DAB-A350-118188EF1E85@brinckerhoff.org> <20090908120242.818436500FE@mail-svr1.cs.utah.edu> <20090909010816.3139B6500BA@mail-svr1.cs.utah.edu> <904774730909091513h63cdf5afg3ad5bc63986336d2@mail.gmail.com> <4C6C0024-AF4F-417E-A502-5F90FB4F4D98@brinckerhoff.org> Message-ID: <19112.14166.353142.235756@winooski.ccs.neu.edu> On Sep 9, John Clements wrote: > On Sep 9, 2009, at 3:13 PM, Todd O'Bryan wrote: > > > Any chance of getting a Snow Leopard-compatible 4.2.1 release? One > > of my students upgraded and now can't use his DrScheme. > > > > Or is there a workaround that doesn't involve installing all of > > the dev tools? > > Hmm... as I mentioned earlier, I had no problems running the > precompiled version of 4.2.1 on Snow Leopard; my only difficulty was > in compiling it from scratch. This was on an x86_64 machine, if > that matters. I didn't follow the OSX issues -- but JFYI, if there's a need for a new build (and a machine to host it) then please tell me asap. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From robby at eecs.northwestern.edu Wed Sep 9 19:32:14 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Wed Sep 9 19:32:33 2009 Subject: [plt-dev] check-expect bug Message-ID: <932b2f1f0909091632s7e70e87ay508404413f2149f5@mail.gmail.com> Is someone looking into that already? Robby From robby at eecs.northwestern.edu Wed Sep 9 22:56:21 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Wed Sep 9 22:56:39 2009 Subject: [plt-dev] an api for check syntax & module browser Message-ID: <932b2f1f0909091956r24cb76bfqb87c358a9798d913@mail.gmail.com> So, I've heard various people saying it would be nice to have a separate api for check syntax (and presumably the module browser) pulled out of DrScheme. I definitely agree with that, but I'm wondering how to prioritize it. Does anyone have some specific use in mind for the api? Thanks, Robby From jay.mccarthy at gmail.com Wed Sep 9 22:58:24 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Wed Sep 9 22:58:46 2009 Subject: [plt-dev] an api for check syntax & module browser In-Reply-To: <932b2f1f0909091956r24cb76bfqb87c358a9798d913@mail.gmail.com> References: <932b2f1f0909091956r24cb76bfqb87c358a9798d913@mail.gmail.com> Message-ID: Documentation. Scribble's main annoyance for me is that @schemeblock isn't syntax highlighted. Take for instance the example at the end of this section: http://docs.plt-scheme.org/continue/index.html#(part._.Rendering_.H.T.M.L) The module browser might be a nice advantage for rewriting developer-centric documentation. [Even though I think these are good uses, I don't think you should prioritize this.] Jay On Wed, Sep 9, 2009 at 8:56 PM, Robby Findler wrote: > So, I've heard various people saying it would be nice to have a > separate api for check syntax (and presumably the module browser) > pulled out of DrScheme. I definitely agree with that, but I'm > wondering how to prioritize it. Does anyone have some specific use in > mind for the api? > > Thanks, > Robby > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From neil at neilvandyke.org Wed Sep 9 23:05:53 2009 From: neil at neilvandyke.org (Neil Van Dyke) Date: Wed Sep 9 23:06:13 2009 Subject: [plt-dev] an api for check syntax & module browser In-Reply-To: <932b2f1f0909091956r24cb76bfqb87c358a9798d913@mail.gmail.com> References: <932b2f1f0909091956r24cb76bfqb87c358a9798d913@mail.gmail.com> Message-ID: <4AA86D11.8040503@neilvandyke.org> Robby Findler wrote at 09/09/2009 10:56 PM: > So, I've heard various people saying it would be nice to have a > separate api for check syntax (and presumably the module browser) > pulled out of DrScheme. > IMHO, a higher priority wishlist item is to make Check Syntax faster or even continuously-updated. Right now, it's more a "batch" thing, when it might be an "interactive" thing. If there's a slick API, exposing it to DrScheme add-ons makes DrScheme better and promotes adoption of DrScheme. Exposing that functionality outside DrScheme makes Emacs better. -- http://www.neilvandyke.org/ From robby at eecs.northwestern.edu Wed Sep 9 23:05:32 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Wed Sep 9 23:06:20 2009 Subject: [plt-dev] an api for check syntax & module browser In-Reply-To: References: <932b2f1f0909091956r24cb76bfqb87c358a9798d913@mail.gmail.com> Message-ID: <932b2f1f0909092005o72c25dfbnda5100a273531072@mail.gmail.com> On Wed, Sep 9, 2009 at 9:58 PM, Jay McCarthy wrote: > Documentation. > > Scribble's main annoyance for me is that @schemeblock isn't syntax > highlighted. Take for instance the example at the end of this section: > > http://docs.plt-scheme.org/continue/index.html#(part._.Rendering_.H.T.M.L) I see a lot of blue there, but I would have expected that require for-label's would color syntax black there. Check syntax could give you little more over that, I don't think. Or am I missing something? > The module browser might be a nice advantage for rewriting > developer-centric documentation. FWIW, the API I could easily provide for that one is something like a function that takes a file (with a module in it) and produces a graph, or possibly a laid-out graph. Robby From ryanc at ccs.neu.edu Thu Sep 10 00:56:10 2009 From: ryanc at ccs.neu.edu (Ryan Culpepper) Date: Thu Sep 10 00:55:24 2009 Subject: [plt-dev] an api for check syntax & module browser In-Reply-To: <932b2f1f0909091956r24cb76bfqb87c358a9798d913@mail.gmail.com> References: <932b2f1f0909091956r24cb76bfqb87c358a9798d913@mail.gmail.com> Message-ID: <4AA886EA.6020604@ccs.neu.edu> Robby Findler wrote: > So, I've heard various people saying it would be nice to have a > separate api for check syntax (and presumably the module browser) > pulled out of DrScheme. I definitely agree with that, but I'm > wondering how to prioritize it. Does anyone have some specific use in > mind for the api? (My wishlist for the next decade of Christmases follows. Feel free to focus on just the first part, since that's the part that your message actually asked about.) I envision two APIs. One handles source code analysis, possibly including expansion, builds def-use relations, etc. The other handles annotations to code in editors, allows adding mouseover callbacks to regions of code, adding right-click menu items, etc. Some client programs of the first API: - Find useless definitions: names neither referenced as a variable, referenced within a syntax template, nor provided. - Given a collection of modules, find names defined but not referenced within the collection. - Find useless 'require' forms. - Given an expression, find the locally-bound free variables (cf lambda-lifting). - Find provided names that don't have Scribble docs. - Given a module, find decompositions of the module into submodules. Some client programs of the second API: - Visualizations of the analyses above. - Typed Scheme could pop up type information in places where it is currently implicit: eg, let-bound variables, when the mouse goes over the variable name. - The parser-tools 'parser' macro could offer to show the FIRST set of a nonterminal name as a context-menu command, Spidey-like. Ideally, we might eventually develop a third API for manipulating programs in editors. Then programs in the first set of examples could be incorporated into full-fledged refactoring tools. For example, don't just compute the useless definitions, allow their interactive deletion. Ryan From robby at eecs.northwestern.edu Thu Sep 10 02:52:08 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Thu Sep 10 02:52:27 2009 Subject: [plt-dev] Re: check-expect bug In-Reply-To: <932b2f1f0909091632s7e70e87ay508404413f2149f5@mail.gmail.com> References: <932b2f1f0909091632s7e70e87ay508404413f2149f5@mail.gmail.com> Message-ID: <932b2f1f0909092352r50889b36v91540ede5945144a@mail.gmail.com> Looks like there were many hands at work in the function that is causing the trouble. Kathy, Eli, Mike, and John all worked on the function run-and-check (and now me). Some questions/comments: -- the call to exn? in that with handlers should probably be exn:fail?. The only difference here is probably that breaks will not be handled (when it is exn:fail?) which means that clicking the stop button won't make the code go into this handler, which seems like a good thing. I have committed this change. -- the "uncaught exn: #f" message seems to stem from the fact that the body of this function always calls (raise #f) when a test case fails. I have no idea why it does that, but I changed (raise exn) to (when exn (raise exn)). Someone who knows this code (if a single such a person exists) should probably check that over. This is what I did to fix PR 10438. I have also committed this change, but in a second commit. Robby On Wed, Sep 9, 2009 at 6:32 PM, Robby Findler wrote: > Is someone looking into that already? > > Robby > From robby at eecs.northwestern.edu Thu Sep 10 03:01:56 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Thu Sep 10 03:02:15 2009 Subject: [plt-dev] check-expect bug In-Reply-To: References: <932b2f1f0909091632s7e70e87ay508404413f2149f5@mail.gmail.com> Message-ID: <932b2f1f0909100001r3fddb5fds35e527851864bb49@mail.gmail.com> There were a few PRs that went by. One was that images didn't print right, but that turned out not to be reproducible (and may not have been specific to check-expect or even the teachign languages). One was the "uncaught exception #f" printout and the last was that the "trace" link in the error display window signalled an error. That's all that I'm aware of anyways. Robby On Thu, Sep 10, 2009 at 1:57 AM, Michael Sperber wrote: > > Robby Findler writes: > >> Is someone looking into that already? > > What's the bug? > > -- > Cheers =8-} Mike > Friede, V?lkerverst?ndigung und ?berhaupt blabla > From sperber at deinprogramm.de Thu Sep 10 02:57:11 2009 From: sperber at deinprogramm.de (Michael Sperber) Date: Thu Sep 10 03:02:34 2009 Subject: [plt-dev] check-expect bug In-Reply-To: <932b2f1f0909091632s7e70e87ay508404413f2149f5@mail.gmail.com> (Robby Findler's message of "Wed, 9 Sep 2009 18:32:14 -0500") References: <932b2f1f0909091632s7e70e87ay508404413f2149f5@mail.gmail.com> Message-ID: Robby Findler writes: > Is someone looking into that already? What's the bug? -- Cheers =8-} Mike Friede, V?lkerverst?ndigung und ?berhaupt blabla From robby at eecs.northwestern.edu Thu Sep 10 03:02:40 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Thu Sep 10 03:03:00 2009 Subject: [plt-dev] Re: check-expect bug In-Reply-To: References: <932b2f1f0909091632s7e70e87ay508404413f2149f5@mail.gmail.com> <932b2f1f0909092352r50889b36v91540ede5945144a@mail.gmail.com> Message-ID: <932b2f1f0909100002vd461c77y99c248129a46e61b@mail.gmail.com> Thanks, Mike. Robby On Thu, Sep 10, 2009 at 1:59 AM, Michael Sperber wrote: > > Robby Findler writes: > >> Looks like there were many hands at work in the function that is >> causing the trouble. Kathy, Eli, Mike, and John all worked on the >> function run-and-check (and now me). Some questions/comments: >> >> -- the call to exn? in that with handlers should probably be >> exn:fail?. The only difference here is probably that breaks will not >> be handled (when it is exn:fail?) which means that clicking the stop >> button won't make the code go into this handler, which seems like a >> good thing. I have committed this change. >> >> -- the "uncaught exn: #f" message seems to stem from the fact that the >> body of this function always calls (raise #f) when a test case fails. >> I have no idea why it does that, but I changed (raise exn) to (when >> exn (raise exn)). Someone who knows this code (if a single such a >> person exists) should probably check that over. This is what I did to >> fix PR 10438. I have also committed this change, but in a second >> commit. > > I'll look into the remaining issue either this afternoon (i.e. in a few > hours) or tomorrow. > > -- > Cheers =8-} Mike > Friede, V?lkerverst?ndigung und ?berhaupt blabla > From sperber at deinprogramm.de Thu Sep 10 02:59:30 2009 From: sperber at deinprogramm.de (Michael Sperber) Date: Thu Sep 10 03:07:33 2009 Subject: [plt-dev] Re: check-expect bug In-Reply-To: <932b2f1f0909092352r50889b36v91540ede5945144a@mail.gmail.com> (Robby Findler's message of "Thu, 10 Sep 2009 01:52:08 -0500") References: <932b2f1f0909091632s7e70e87ay508404413f2149f5@mail.gmail.com> <932b2f1f0909092352r50889b36v91540ede5945144a@mail.gmail.com> Message-ID: Robby Findler writes: > Looks like there were many hands at work in the function that is > causing the trouble. Kathy, Eli, Mike, and John all worked on the > function run-and-check (and now me). Some questions/comments: > > -- the call to exn? in that with handlers should probably be > exn:fail?. The only difference here is probably that breaks will not > be handled (when it is exn:fail?) which means that clicking the stop > button won't make the code go into this handler, which seems like a > good thing. I have committed this change. > > -- the "uncaught exn: #f" message seems to stem from the fact that the > body of this function always calls (raise #f) when a test case fails. > I have no idea why it does that, but I changed (raise exn) to (when > exn (raise exn)). Someone who knows this code (if a single such a > person exists) should probably check that over. This is what I did to > fix PR 10438. I have also committed this change, but in a second > commit. I'll look into the remaining issue either this afternoon (i.e. in a few hours) or tomorrow. -- Cheers =8-} Mike Friede, V?lkerverst?ndigung und ?berhaupt blabla From meunier at ccs.neu.edu Thu Sep 10 03:43:13 2009 From: meunier at ccs.neu.edu (Philippe Meunier) Date: Thu Sep 10 03:43:32 2009 Subject: [plt-dev] an api for check syntax & module browser In-Reply-To: <4AA886EA.6020604@ccs.neu.edu> References: <932b2f1f0909091956r24cb76bfqb87c358a9798d913@mail.gmail.com> <4AA886EA.6020604@ccs.neu.edu> Message-ID: <20090910074312.GA24779@denali.ccs.neu.edu> Ryan Culpepper wrote: > I envision two APIs. One handles source code analysis, possibly > including expansion, builds def-use relations, etc. The other handles > annotations to code in editors, allows adding mouseover callbacks to > regions of code, adding right-click menu items, etc. FYI, I'm working on an abstract interpretation framework for DrScheme that will eventually provide APIs for that stuff, including the GUI part (in fact the GUI part of MrFlow already had a basic version of an API that provided the mouseover callbacks (to draw flow arrows) and the right-click menu items, it's just that MrFlow was that API's only customer and that the API had only minimal documentation). Most of (all?) the "client programs" you list would then be plug-in analyses for the framework. In turn there's fairly simple DrScheme tool that takes the framework and all its analyses and plugs the whole thing into DrScheme (in theory the framework can be plugged into any program you want, but I haven't actually tried it yet). In parallel to working on the framework proper, I'm also developing two client analyses, mostly to check that I'm abstracting the framework at the right level, and, interestingly, one of them is an attempt at re-implementing Robby's syntax checker (the other client is a tracing evaluator, and there's in fact a third client I'm working on, which one day should become MrFlow 2.0, but that one is harder to develop than the other two). Don't hold your breath though, I've got about 2000 lines of code so far and I'm only just about to be able to analyze the lambda calculus, so it'll be quite a while before I have something that can more or less match Robby's tool. Progress is steady but slow, there's just a ton of infrastructure code to write (anybody wants to write a hashconsing library that can handle cyclic data structures, unions, subtyping (and least upper bounds in general), and that's reasonably efficient and GC-friendly?) Philippe From jao at gnu.org Thu Sep 10 07:01:44 2009 From: jao at gnu.org (Jose A. Ortega Ruiz) Date: Thu Sep 10 07:36:19 2009 Subject: [plt-dev] Re: an api for check syntax & module browser References: <932b2f1f0909091956r24cb76bfqb87c358a9798d913@mail.gmail.com> Message-ID: <87ws4712sn.fsf@mithrandir.homeunix.net> Robby Findler writes: > So, I've heard various people saying it would be nice to have a > separate api for check syntax (and presumably the module browser) > pulled out of DrScheme. I definitely agree with that, but I'm > wondering how to prioritize it. Does anyone have some specific use in > mind for the api? I would definitely use it in geiser, my emacs mode, to provide functionality similar to that of DrScheme's. For instance, highlighting and reporting of syntax errors. And one thing i cannot currently do (perhaps because i don't know how to do it in mzscheme) is to show callers/callees trees. Also, i currently compute an approximate list of local identifiers by parsing forms in elisp (to offer them for completion): with check-syntax i'd have a correct list of local bindings available, and could perhaps also highlight them. In summary, i'd bring DrScheme's check-syntax interface the mzscheme/emacs world. Thanks! jao From dherman at ccs.neu.edu Thu Sep 10 09:15:44 2009 From: dherman at ccs.neu.edu (Dave Herman) Date: Thu Sep 10 09:16:14 2009 Subject: [plt-dev] an api for check syntax & module browser In-Reply-To: <932b2f1f0909091956r24cb76bfqb87c358a9798d913@mail.gmail.com> References: <932b2f1f0909091956r24cb76bfqb87c358a9798d913@mail.gmail.com> Message-ID: <31530B67-2228-4C83-9A19-A4488244839D@ccs.neu.edu> At some point, I would love to create an experimental language with typed macros, where Check Syntax didn't actually need to expand the macros to get binding information because the types would provide that info. Thanks, Dave On Sep 9, 2009, at 10:56 PM, Robby Findler wrote: > So, I've heard various people saying it would be nice to have a > separate api for check syntax (and presumably the module browser) > pulled out of DrScheme. I definitely agree with that, but I'm > wondering how to prioritize it. Does anyone have some specific use in > mind for the api? > > Thanks, > Robby > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From matthias at ccs.neu.edu Thu Sep 10 09:37:59 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Thu Sep 10 09:38:29 2009 Subject: [plt-dev] an api for check syntax & module browser In-Reply-To: <932b2f1f0909091956r24cb76bfqb87c358a9798d913@mail.gmail.com> References: <932b2f1f0909091956r24cb76bfqb87c358a9798d913@mail.gmail.com> Message-ID: <78B03431-95B6-4DE7-BF05-3DE55B572901@ccs.neu.edu> Here are two plug-ins I could imagine: -- the module browser could display contracted provides and/or typed provides on mouse-over (I am not asking that you write this; an API that can enable this application without changing the module browser is what I imagine) -- check-syntax could be parameterized over the analysis it performs to enable simple refactorings (separate step) On Sep 9, 2009, at 10:56 PM, Robby Findler wrote: > So, I've heard various people saying it would be nice to have a > separate api for check syntax (and presumably the module browser) > pulled out of DrScheme. I definitely agree with that, but I'm > wondering how to prioritize it. Does anyone have some specific use in > mind for the api? > > Thanks, > Robby > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From matthias at ccs.neu.edu Thu Sep 10 09:39:28 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Thu Sep 10 09:39:53 2009 Subject: [plt-dev] an api for check syntax & module browser In-Reply-To: <20090910074312.GA24779@denali.ccs.neu.edu> References: <932b2f1f0909091956r24cb76bfqb87c358a9798d913@mail.gmail.com> <4AA886EA.6020604@ccs.neu.edu> <20090910074312.GA24779@denali.ccs.neu.edu> Message-ID: <6DBFF96A-09E6-4F07-98D3-6F226DAAACD8@ccs.neu.edu> On Sep 10, 2009, at 3:43 AM, Philippe Meunier wrote: > Progress is steady but slow, there's just a > ton of infrastructure code to write (anybody wants to write a > hashconsing library that can handle cyclic data structures, unions, > subtyping (and least upper bounds in general), and that's reasonably > efficient and GC-friendly?) Make a list of concrete specs, publish it here. See whether we can't find volunteers. From robby at eecs.northwestern.edu Thu Sep 10 09:55:33 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Thu Sep 10 09:55:54 2009 Subject: [plt-dev] an api for check syntax & module browser In-Reply-To: <20090910074312.GA24779@denali.ccs.neu.edu> References: <932b2f1f0909091956r24cb76bfqb87c358a9798d913@mail.gmail.com> <4AA886EA.6020604@ccs.neu.edu> <20090910074312.GA24779@denali.ccs.neu.edu> Message-ID: <932b2f1f0909100655v47273224nccae435b699b7545@mail.gmail.com> That sounds like a great thing (I know you've mentioned it to me privately before, but it was nice to get a little more detail now)! That also suggests an indirect use of the check syntax refactoring I had in mind, namely building a test suite that checks to see that they behave the same way. Robby On Thu, Sep 10, 2009 at 2:43 AM, Philippe Meunier wrote: > Ryan Culpepper wrote: >> I envision two APIs. One handles source code analysis, possibly >> including expansion, builds def-use relations, etc. The other handles >> annotations to code in editors, allows adding mouseover callbacks to >> regions of code, adding right-click menu items, etc. > > FYI, I'm working on an abstract interpretation framework for DrScheme > that will eventually provide APIs for that stuff, including the GUI > part (in fact the GUI part of MrFlow already had a basic version of an > API that provided the mouseover callbacks (to draw flow arrows) and > the right-click menu items, it's just that MrFlow was that API's only > customer and that the API had only minimal documentation). > > Most of (all?) the "client programs" you list would then be plug-in > analyses for the framework. ?In turn there's fairly simple DrScheme > tool that takes the framework and all its analyses and plugs the whole > thing into DrScheme (in theory the framework can be plugged into any > program you want, but I haven't actually tried it yet). ?In parallel > to working on the framework proper, I'm also developing two client > analyses, mostly to check that I'm abstracting the framework at the > right level, and, interestingly, one of them is an attempt at > re-implementing Robby's syntax checker (the other client is a tracing > evaluator, and there's in fact a third client I'm working on, which > one day should become MrFlow 2.0, but that one is harder to develop > than the other two). > > Don't hold your breath though, I've got about 2000 lines of code so > far and I'm only just about to be able to analyze the lambda calculus, > so it'll be quite a while before I have something that can more or > less match Robby's tool. ?Progress is steady but slow, there's just a > ton of infrastructure code to write (anybody wants to write a > hashconsing library that can handle cyclic data structures, unions, > subtyping (and least upper bounds in general), and that's reasonably > efficient and GC-friendly?) > > Philippe > > > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > From samth at ccs.neu.edu Thu Sep 10 12:49:10 2009 From: samth at ccs.neu.edu (Sam TH) Date: Thu Sep 10 12:55:13 2009 Subject: [plt-dev] strange behavior with printf, format, and unsyntax Message-ID: <63bb19ae0909100949n6f91fd4dpa94c04d429ef85cb@mail.gmail.com> This program: #lang scheme (display (format "~a~n" '(scheme #,3))) (format "~a~n" '(scheme #,3)) (printf "~a~n" '(scheme #,3)) Produces these results: (scheme (unsyntax 3)) "(scheme (unsyntax 3))\n" (scheme #,3) which rather surprised me. Why is `printf' behaving differently from `format'? -- sam th samth@ccs.neu.edu From rafkind at cs.utah.edu Thu Sep 10 12:59:33 2009 From: rafkind at cs.utah.edu (Jon Rafkind) Date: Thu Sep 10 13:01:39 2009 Subject: [plt-dev] strange behavior with printf, format, and unsyntax In-Reply-To: <63bb19ae0909100949n6f91fd4dpa94c04d429ef85cb@mail.gmail.com> References: <63bb19ae0909100949n6f91fd4dpa94c04d429ef85cb@mail.gmail.com> Message-ID: <4AA93075.7080201@cs.utah.edu> Sam TH wrote: > This program: > > #lang scheme > > (display (format "~a~n" '(scheme #,3))) > (format "~a~n" '(scheme #,3)) > (printf "~a~n" '(scheme #,3)) > > Produces these results: > > (scheme (unsyntax 3)) > "(scheme (unsyntax 3))\n" > (scheme #,3) > > which rather surprised me. Why is `printf' behaving differently from `format'? > It prints (unsyntax 3) for me. (scheme (unsyntax 3)) "(scheme (unsyntax 3))\n" (scheme (unsyntax 3)) $ mzscheme --version Welcome to MzScheme v4.2.1.8 [3m], Copyright (c) 2004-2009 PLT Scheme Inc. From ryanc at ccs.neu.edu Thu Sep 10 13:07:07 2009 From: ryanc at ccs.neu.edu (Ryan Culpepper) Date: Thu Sep 10 13:06:15 2009 Subject: [plt-dev] strange behavior with printf, format, and unsyntax In-Reply-To: <63bb19ae0909100949n6f91fd4dpa94c04d429ef85cb@mail.gmail.com> References: <63bb19ae0909100949n6f91fd4dpa94c04d429ef85cb@mail.gmail.com> Message-ID: <4AA9323B.20404@ccs.neu.edu> Sam TH wrote: > This program: > > #lang scheme > > (display (format "~a~n" '(scheme #,3))) > (format "~a~n" '(scheme #,3)) > (printf "~a~n" '(scheme #,3)) > > Produces these results: > > (scheme (unsyntax 3)) > "(scheme (unsyntax 3))\n" > (scheme #,3) > > which rather surprised me. Why is `printf' behaving differently from `format'? You ran this in DrScheme, right? They're the same in mzscheme. Output ports have procedures associated with them (see 'port-print-handler') to customize printing. That's how, for example, printing a syntax object can result in a snip being inserted into an editor. I guess DrScheme's output port also does reader abbreviations. This might be connected to the output style language preference. Ryan From robby at eecs.northwestern.edu Thu Sep 10 18:47:34 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Thu Sep 10 18:47:55 2009 Subject: [plt-dev] strange behavior with printf, format, and unsyntax In-Reply-To: <4AA9323B.20404@ccs.neu.edu> References: <63bb19ae0909100949n6f91fd4dpa94c04d429ef85cb@mail.gmail.com> <4AA9323B.20404@ccs.neu.edu> Message-ID: <932b2f1f0909101547m45d396f1ra242562cd2eae74d@mail.gmail.com> DrScheme's printer uses pretty-print, which does the reader shorthands. Robby On Thu, Sep 10, 2009 at 12:07 PM, Ryan Culpepper wrote: > Sam TH wrote: >> >> This program: >> >> #lang scheme >> >> (display (format "~a~n" '(scheme #,3))) >> (format "~a~n" '(scheme #,3)) >> (printf "~a~n" '(scheme #,3)) >> >> Produces these results: >> >> (scheme (unsyntax 3)) >> "(scheme (unsyntax 3))\n" >> (scheme #,3) >> >> which rather surprised me. ?Why is `printf' behaving differently from >> `format'? > > You ran this in DrScheme, right? They're the same in mzscheme. > > Output ports have procedures associated with them (see 'port-print-handler') > to customize printing. That's how, for example, printing a syntax object can > result in a snip being inserted into an editor. I guess DrScheme's output > port also does reader abbreviations. This might be connected to the output > style language preference. > > Ryan > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > From eli at barzilay.org Thu Sep 10 22:55:39 2009 From: eli at barzilay.org (Eli Barzilay) Date: Thu Sep 10 22:56:00 2009 Subject: [plt-dev] Re: loop over environment variables and delete an environment variable In-Reply-To: <3cbaf1c80909101923q3855e1f2u2afac918a23df980@mail.gmail.com> References: <3cbaf1c80909101906n63028127m11a784a6b1bcea7c@mail.gmail.com> <19113.45456.822154.916635@winooski.ccs.neu.edu> <3cbaf1c80909101923q3855e1f2u2afac918a23df980@mail.gmail.com> Message-ID: <19113.48171.202485.536597@winooski.ccs.neu.edu> [Moved to plt-dev] On Sep 10, Peter Michaux wrote: > On Thu, Sep 10, 2009 at 7:10 PM, Eli Barzilay wrote: > > On Sep 10, Peter Michaux wrote: > >> It seems that with the exception of using the FFI there currently > >> is no facility in PLT to either loop over the complete set of > >> environment variables or delete an environment variable. Is that > >> a correct conclusion? Is adding that sort of functionality in any > >> plans? > > > > Would you be willing to write the code? > > Will? Yes. Capable? I don't know. I haven't done anything inside the > MzScheme C code. The important thing is to see how to make something that runs on Windows too. But looking at the code, there is something that looks strange and might be some old leftover: it looks like if `GETENV_FUNCTION' is not defined, then there is some environment initialization from an "Environment" file (which is expected to be in the directory where the process starts?), and it looks like the code tracks `setenv' uses in the `putenv_str_table' -- but that doesn't get used unless `GETENV_FUNCTION' is not defined. Matthew -- is there a reason for that? > Would a function like (environment->alist) be the desirable way to > access the full environment? IMO it would be simpler to have a function that returns a list of environment variable names, but it's probably a good idea to look around and see what other implementations (and other languages) do. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From czhu at cs.utah.edu Fri Sep 11 00:07:38 2009 From: czhu at cs.utah.edu (Chongkai Zhu) Date: Fri Sep 11 00:08:07 2009 Subject: [plt-dev] Re: loop over environment variables and delete an environment variable In-Reply-To: <19113.48171.202485.536597@winooski.ccs.neu.edu> References: <3cbaf1c80909101906n63028127m11a784a6b1bcea7c@mail.gmail.com> <19113.45456.822154.916635@winooski.ccs.neu.edu> <3cbaf1c80909101923q3855e1f2u2afac918a23df980@mail.gmail.com> <19113.48171.202485.536597@winooski.ccs.neu.edu> Message-ID: <4AA9CD0A.1060302@cs.utah.edu> Eli Barzilay wrote: > [Moved to plt-dev] > > > IMO it would be simpler to have a function that returns a list of > environment variable names, but it's probably a good idea to look > around and see what other implementations (and other languages) do. > > http://srfi.schemers.org/srfi-98/srfi-98.html From sperber at deinprogramm.de Fri Sep 11 04:59:49 2009 From: sperber at deinprogramm.de (Michael Sperber) Date: Fri Sep 11 05:00:10 2009 Subject: [plt-dev] Re: check-expect bug In-Reply-To: <932b2f1f0909092352r50889b36v91540ede5945144a@mail.gmail.com> (Robby Findler's message of "Thu, 10 Sep 2009 01:52:08 -0500") References: <932b2f1f0909091632s7e70e87ay508404413f2149f5@mail.gmail.com> <932b2f1f0909092352r50889b36v91540ede5945144a@mail.gmail.com> Message-ID: Robby Findler writes: > -- the call to exn? in that with handlers should probably be > exn:fail?. The only difference here is probably that breaks will not > be handled (when it is exn:fail?) which means that clicking the stop > button won't make the code go into this handler, which seems like a > good thing. I have committed this change. Sure. I kind of liked the behavior with the user break, but it's not a big deal. > -- the "uncaught exn: #f" message seems to stem from the fact that the > body of this function always calls (raise #f) when a test case fails. > I have no idea why it does that, but I changed (raise exn) to (when > exn (raise exn)). Someone who knows this code (if a single such a > person exists) should probably check that over. This is what I did to > fix PR 10438. I have also committed this change, but in a second > commit. I sure am responsible for this; I don't know what got into me. Sorry. I think everything related to `check-expect' is OK now: PR10435: Pilot error; I've closed this after clarifying the documentation. PR10437: Fixed by Kathy PR10438: Robby's fix was good, I've clarified the code a wee bit. PR10440: Like everyone else, I can't reproduce. Thanks to Robby and Kathy for fixing things! Please be sure to let me know if there's anything else that needs fixing. -- Cheers =8-} Mike Friede, V?lkerverst?ndigung und ?berhaupt blabla From robby at eecs.northwestern.edu Fri Sep 11 05:26:37 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Fri Sep 11 05:26:55 2009 Subject: [plt-dev] Re: check-expect bug In-Reply-To: References: <932b2f1f0909091632s7e70e87ay508404413f2149f5@mail.gmail.com> <932b2f1f0909092352r50889b36v91540ede5945144a@mail.gmail.com> Message-ID: <932b2f1f0909110226g141dcaddt18ea2e62f21d2076@mail.gmail.com> On Fri, Sep 11, 2009 at 3:59 AM, Michael Sperber wrote: > > Robby Findler writes: > >> -- the call to exn? in that with handlers should probably be >> exn:fail?. The only difference here is probably that breaks will not >> be handled (when it is exn:fail?) which means that clicking the stop >> button won't make the code go into this handler, which seems like a >> good thing. I have committed this change. > > Sure. ?I kind of liked the behavior with the user break, but it's not a > big deal. But if I double click the break button (for example), it won't work; it will just corrupt the stack trace (not that the stack trace matters for the teaching languages of course). >> -- the "uncaught exn: #f" message seems to stem from the fact that the >> body of this function always calls (raise #f) when a test case fails. >> I have no idea why it does that, but I changed (raise exn) to (when >> exn (raise exn)). Someone who knows this code (if a single such a >> person exists) should probably check that over. This is what I did to >> fix PR 10438. I have also committed this change, but in a second >> commit. > > I sure am responsible for this; I don't know what got into me. ?Sorry. > > I think everything related to `check-expect' is OK now: > > PR10435: Pilot error; I've closed this after clarifying the documentation. > PR10437: Fixed by Kathy > PR10438: Robby's fix was good, I've clarified the code a wee bit. > PR10440: Like everyone else, I can't reproduce. > > Thanks to Robby and Kathy for fixing things! > > Please be sure to let me know if there's anything else that needs > fixing. Thanks for your help, Mike. Robby From rafkind at cs.utah.edu Fri Sep 11 13:43:03 2009 From: rafkind at cs.utah.edu (Jon Rafkind) Date: Fri Sep 11 13:45:10 2009 Subject: [plt-dev] skipping message in setup-plt Message-ID: <4AAA8C27.708@cs.utah.edu> $ setup-plt -l scribblings/reference ... setup-plt: skipping: /home/jon/svn/scheme/vi/vi.scrbl ... Could this message be changed to say why it was skipped? I think I used to get an error about the wrong version of bytecode or something. From pltscheme at pnkfx.org Fri Sep 11 16:40:04 2009 From: pltscheme at pnkfx.org (Felix Klock's PLT scheme proxy) Date: Fri Sep 11 16:40:27 2009 Subject: [plt-dev] I've confused Ryan and scared Sam. Message-ID: <33670F66-3943-4D09-8578-45321CA66EFE@pnkfx.org> PLT Folks- Definitions window: ------------------- #lang scheme (define-syntax b (syntax-rules () ((_) 'first-post!))) (define-syntax a (syntax-rules () ((_) (begin (define-syntax b (syntax-rules () ((_) 1))) (b))))) (a) Interactions window: -------------------- Welcome to DrScheme, version 4.1.5 [3m]. Language: Module custom; memory limit: 1024 megabytes. 1 > (a) first-post! > This seems wrong. -Felix From cce at ccs.neu.edu Sat Sep 12 13:37:15 2009 From: cce at ccs.neu.edu (Carl Eastlund) Date: Sat Sep 12 13:37:54 2009 Subject: [plt-dev] Scribble: @author+email obfuscation Message-ID: <990e0c030909121037r27615ed7p7e2274e42f5109c1@mail.gmail.com> The @author+email["My Name" "my@name.com"] form produces output like this: My Name Which is nice for avoiding spam, but annoying for the reader who wants to click a link or copy/paste. What do Scribble users / developers think of making author+email just embed a straightforward email link, and add author+email-no-spam for people worried about spambots? I'd rather have both options available. Carl Eastlund From jay.mccarthy at gmail.com Sat Sep 12 14:05:54 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Sat Sep 12 14:06:15 2009 Subject: [plt-dev] Scribble: @author+email obfuscation In-Reply-To: <990e0c030909121037r27615ed7p7e2274e42f5109c1@mail.gmail.com> References: <990e0c030909121037r27615ed7p7e2274e42f5109c1@mail.gmail.com> Message-ID: I like the idea. I have no problem with my email being public. Google is just too good at catching spam to worry for me. Jay On Sat, Sep 12, 2009 at 11:37 AM, Carl Eastlund wrote: > The @author+email["My Name" "my@name.com"] form produces output like this: > > My Name > > Which is nice for avoiding spam, but annoying for the reader who wants > to click a link or copy/paste. ?What do Scribble users / developers > think of making author+email just embed a straightforward email link, > and add author+email-no-spam for people worried about spambots? ?I'd > rather have both options available. > > Carl Eastlund > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From petermichaux at gmail.com Fri Sep 11 00:13:37 2009 From: petermichaux at gmail.com (Peter Michaux) Date: Sat Sep 12 17:03:56 2009 Subject: [plt-dev] Re: loop over environment variables and delete an environment variable In-Reply-To: <19113.48171.202485.536597@winooski.ccs.neu.edu> References: <3cbaf1c80909101906n63028127m11a784a6b1bcea7c@mail.gmail.com> <19113.45456.822154.916635@winooski.ccs.neu.edu> <3cbaf1c80909101923q3855e1f2u2afac918a23df980@mail.gmail.com> <19113.48171.202485.536597@winooski.ccs.neu.edu> Message-ID: <3cbaf1c80909102113i6122c687sc6746b9070cc1f3c@mail.gmail.com> On Thu, Sep 10, 2009 at 7:55 PM, Eli Barzilay wrote: >> Would a function like (environment->alist) be the desirable way to >> access the full environment? > > IMO it would be simpler to have a function that returns a list of > environment variable names, but it's probably a good idea to look > around and see what other implementations (and other languages) do. Not sure which implementations matter but... Scheme48 has (environment-alist) http://www.s48.org/0.57/manual/s48manual_68.html Gauche has (sys-environ) (sys-environ->alist) http://practical-scheme.net/gauche/man/gauche-refe_60.html#Environment-Inquiry Peter From mflatt at cs.utah.edu Sat Sep 12 21:12:58 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Sat Sep 12 21:13:28 2009 Subject: [plt-dev] Scribble: @author+email obfuscation In-Reply-To: References: <990e0c030909121037r27615ed7p7e2274e42f5109c1@mail.gmail.com> Message-ID: <20090913011302.921266500A8@mail-svr1.cs.utah.edu> E-mail address obfuscation is now optional (as determined by new keyword argument) and is disabled by default. At Sat, 12 Sep 2009 12:05:54 -0600, Jay McCarthy wrote: > I like the idea. I have no problem with my email being public. Google > is just too good at catching spam to worry for me. > > Jay > > On Sat, Sep 12, 2009 at 11:37 AM, Carl Eastlund wrote: > > The @author+email["My Name" "my@name.com"] form produces output like this: > > > > My Name > > > > Which is nice for avoiding spam, but annoying for the reader who wants > > to click a link or copy/paste. ?What do Scribble users / developers > > think of making author+email just embed a straightforward email link, > > and add author+email-no-spam for people worried about spambots? ?I'd > > rather have both options available. > > > > Carl Eastlund > > _________________________________________________ > > ?For list-related administrative tasks: > > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > > > > > > -- > 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 cce at ccs.neu.edu Mon Sep 14 21:16:09 2009 From: cce at ccs.neu.edu (Carl Eastlund) Date: Mon Sep 14 21:16:47 2009 Subject: [plt-dev] Scribble: @author+email obfuscation In-Reply-To: <20090913011302.921266500A8@mail-svr1.cs.utah.edu> References: <990e0c030909121037r27615ed7p7e2274e42f5109c1@mail.gmail.com> <20090913011302.921266500A8@mail-svr1.cs.utah.edu> Message-ID: <990e0c030909141816h7e86952gc39f47e8145aca8d@mail.gmail.com> Thanks as always for the quick fix. Any chance of adding an email: link to the address so readers can just click to reply? Carl Eastlund On Sat, Sep 12, 2009 at 9:12 PM, Matthew Flatt wrote: > E-mail address obfuscation is now optional (as determined by new > keyword argument) and is disabled by default. > > At Sat, 12 Sep 2009 12:05:54 -0600, Jay McCarthy wrote: >> I like the idea. I have no problem with my email being public. Google >> is just too good at catching spam to worry for me. >> >> Jay >> >> On Sat, Sep 12, 2009 at 11:37 AM, Carl Eastlund wrote: >> > The @author+email["My Name" "my@name.com"] form produces output like this: >> > >> > My Name >> > >> > Which is nice for avoiding spam, but annoying for the reader who wants >> > to click a link or copy/paste. ?What do Scribble users / developers >> > think of making author+email just embed a straightforward email link, >> > and add author+email-no-spam for people worried about spambots? ?I'd >> > rather have both options available. >> > >> > Carl Eastlund From cce at ccs.neu.edu Tue Sep 15 18:58:30 2009 From: cce at ccs.neu.edu (Carl Eastlund) Date: Tue Sep 15 18:59:07 2009 Subject: [plt-dev] Unicode is a pain Message-ID: <990e0c030909151558g557bda43hbd9205c10d57c5b7@mail.gmail.com> Specifically, can we please give "new-?/c" an ascii alias such as "new-existential/c"? Or if such a thing already ?, it needs to be documented. My desk is not big enough yet for a full unicode keyboard. More generally, unicode names are fine but we're not "there" yet; we should always have ascii alternatives. Thanks! Carl Eastlund From robby at eecs.northwestern.edu Tue Sep 15 19:00:49 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Tue Sep 15 19:01:11 2009 Subject: [plt-dev] Unicode is a pain In-Reply-To: <990e0c030909151558g557bda43hbd9205c10d57c5b7@mail.gmail.com> References: <990e0c030909151558g557bda43hbd9205c10d57c5b7@mail.gmail.com> Message-ID: <932b2f1f0909151600x1ef268dmfb384c154857cd90@mail.gmail.com> It has that funny name because you shouldn't have to type it much (only people writing contract systems (ie, Stevie) should need it). Plus, I think its name is wrong anyways, and will have to change, but not in a way you'd like :) Also typing "new-\exists/c" is shorter than what you propose. Robby On Tue, Sep 15, 2009 at 5:58 PM, Carl Eastlund wrote: > Specifically, can we please give "new-?/c" an ascii alias such as > "new-existential/c"? ?Or if such a thing already ?, it needs to be > documented. ?My desk is not big enough yet for a full unicode > keyboard. ?More generally, unicode names are fine but we're not > "there" yet; we should always have ascii alternatives. ?Thanks! > > Carl Eastlund > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > From cce at ccs.neu.edu Tue Sep 15 19:15:31 2009 From: cce at ccs.neu.edu (Carl Eastlund) Date: Tue Sep 15 19:16:09 2009 Subject: [plt-dev] Unicode is a pain In-Reply-To: <932b2f1f0909151600x1ef268dmfb384c154857cd90@mail.gmail.com> References: <990e0c030909151558g557bda43hbd9205c10d57c5b7@mail.gmail.com> <932b2f1f0909151600x1ef268dmfb384c154857cd90@mail.gmail.com> Message-ID: <990e0c030909151615k7e0710b9pfd155c48605abd3a@mail.gmail.com> On Tue, Sep 15, 2009 at 7:00 PM, Robby Findler wrote: > It has that funny name because you shouldn't have to type it much > (only people writing contract systems (ie, Stevie) should need it). Once something is in the documentation, that seems like an invitation to other users to use it. Just because something is used rarely or only by a few people, doesn't mean it should be inconvenient does it? > Plus, I think its name is wrong anyways, and will have to change, but > not in a way you'd like :) > > Also typing "new-\exists/c" is shorter than what you propose. Not really, if you count the time it'd take me to look up in Help Desk how to do that. I already know how to type the alphabet; I haven't memorized DrScheme's Unicode shortcuts. Nor does every programmer interested in the contract system necessarily use DrScheme as their primary editor. --Carl > On Tue, Sep 15, 2009 at 5:58 PM, Carl Eastlund wrote: >> Specifically, can we please give "new-?/c" an ascii alias such as >> "new-existential/c"? ?Or if such a thing already ?, it needs to be >> documented. ?My desk is not big enough yet for a full unicode >> keyboard. ?More generally, unicode names are fine but we're not >> "there" yet; we should always have ascii alternatives. ?Thanks! >> >> Carl Eastlund From acowley at seas.upenn.edu Tue Sep 15 19:53:39 2009 From: acowley at seas.upenn.edu (Anthony Cowley) Date: Tue Sep 15 19:53:58 2009 Subject: [plt-dev] Unicode is a pain In-Reply-To: <990e0c030909151615k7e0710b9pfd155c48605abd3a@mail.gmail.com> References: <990e0c030909151558g557bda43hbd9205c10d57c5b7@mail.gmail.com> <932b2f1f0909151600x1ef268dmfb384c154857cd90@mail.gmail.com> <990e0c030909151615k7e0710b9pfd155c48605abd3a@mail.gmail.com> Message-ID: <81addec70909151653u36f42af7v479589aa57a03f71@mail.gmail.com> On Tue, Sep 15, 2009 at 7:15 PM, Carl Eastlund wrote: > Not really, if you count the time it'd take me to look up in Help Desk > how to do that. ?I already know how to type the alphabet; I haven't > memorized DrScheme's Unicode shortcuts. ?Nor does every programmer > interested in the contract system necessarily use DrScheme as their > primary editor. These shortcuts aren't specific to DrScheme, though, and work fine in Emacs with the TeX input mode. (I'm only chiming in because I actually really appreciate that DrScheme supports the same shortcuts for unicode characters that I'm used to in Emacs.) Anthony From cobbe at ccs.neu.edu Wed Sep 16 07:03:14 2009 From: cobbe at ccs.neu.edu (Richard Cobbe) Date: Wed Sep 16 07:03:43 2009 Subject: [plt-dev] Unicode is a pain In-Reply-To: <81addec70909151653u36f42af7v479589aa57a03f71@mail.gmail.com> References: <990e0c030909151558g557bda43hbd9205c10d57c5b7@mail.gmail.com> <932b2f1f0909151600x1ef268dmfb384c154857cd90@mail.gmail.com> <990e0c030909151615k7e0710b9pfd155c48605abd3a@mail.gmail.com> <81addec70909151653u36f42af7v479589aa57a03f71@mail.gmail.com> Message-ID: <20090916110314.GA604@perdita.local> On Tue, Sep 15, 2009 at 07:53:39PM -0400, Anthony Cowley wrote: > On Tue, Sep 15, 2009 at 7:15 PM, Carl Eastlund wrote: > > Not really, if you count the time it'd take me to look up in Help Desk > > how to do that. ?I already know how to type the alphabet; I haven't > > memorized DrScheme's Unicode shortcuts. ?Nor does every programmer > > interested in the contract system necessarily use DrScheme as their > > primary editor. > > These shortcuts aren't specific to DrScheme, though, and work fine in > Emacs with the TeX input mode. Interesting. I wasn't aware of TeX input mode and googled for it, but all I got was TeX-mode (well, plus one mode for editing APL source), which can't be what you're referring to. Could you provide some pointers? Thanks, Richard From dherman at ccs.neu.edu Wed Sep 16 09:05:03 2009 From: dherman at ccs.neu.edu (Dave Herman) Date: Wed Sep 16 09:05:43 2009 Subject: [plt-dev] parser macros Message-ID: <819FF254-1AD9-48C6-AC8B-E51AE7777329@ccs.neu.edu> Floating an idea: I'd love to see an extension to the `parser' form that allows programmers to define grammar macros. Imagine if you could do something like this: (parser (start Expr) (end EOF) (tokens Tokens) (macros (define-macro (List x) [(LPAREN (ListTail x)) $2]) (define-macro (ListTail x) [(RPAREN) '()] [(x COMMA (ListTail x)) (cons $1 $3)])) (grammar (Expr [(Expr (List Expr)) (make-app-expr $1 $2)] [(LAMBDA ID (List ID)) (make-lambda-expr $2 $3)] ;; etc... ))) and imagine the macros would be expanded away as part of the expansion of the `parser' form. This would give you the ability to define abstractions in the grammar language in a manner that results in code duplication rather than sharing. Obviously, it's a bit of a blunt instrument, but in an LALR framework this kind of duplication is sometimes necessary to avoid conflicts. Perhaps better yet, it'd be cool if these macros could be defined independently, like match-expanders: (define-grammar-expander (ListTail x) [(RPAREN) '()] [(x COMMA (ListTail x)) (cons $1 $3)]) Thoughts? BTW, who maintains the parser-tools these days? Dave From jay.mccarthy at gmail.com Wed Sep 16 09:51:32 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Wed Sep 16 09:51:54 2009 Subject: [plt-dev] parser macros In-Reply-To: <819FF254-1AD9-48C6-AC8B-E51AE7777329@ccs.neu.edu> References: <819FF254-1AD9-48C6-AC8B-E51AE7777329@ccs.neu.edu> Message-ID: +1 On Wed, Sep 16, 2009 at 7:05 AM, Dave Herman wrote: > Floating an idea: > > I'd love to see an extension to the `parser' form that allows programmers to > define grammar macros. Imagine if you could do something like this: > > (parser > ?(start Expr) > ?(end EOF) > ?(tokens Tokens) > ?(macros > ? (define-macro (List x) > ? ? [(LPAREN (ListTail x)) > ? ? ?$2]) > ? (define-macro (ListTail x) > ? ? [(RPAREN) '()] > ? ? [(x COMMA (ListTail x)) > ? ? ?(cons $1 $3)])) > ?(grammar > ? (Expr > ? ? [(Expr (List Expr)) > ? ? ?(make-app-expr $1 $2)] > ? ? [(LAMBDA ID (List ID)) > ? ? ?(make-lambda-expr $2 $3)] > ? ? ;; etc... > ? ? ))) > > and imagine the macros would be expanded away as part of the expansion of > the `parser' form. This would give you the ability to define abstractions in > the grammar language in a manner that results in code duplication rather > than sharing. Obviously, it's a bit of a blunt instrument, but in an LALR > framework this kind of duplication is sometimes necessary to avoid > conflicts. > > Perhaps better yet, it'd be cool if these macros could be defined > independently, like match-expanders: > > ? ?(define-grammar-expander (ListTail x) > ? ? ?[(RPAREN) '()] > ? ? ?[(x COMMA (ListTail x)) > ? ? ? (cons $1 $3)]) > > Thoughts? > > BTW, who maintains the parser-tools these days? > > Dave > > _________________________________________________ > ?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 acowley at seas.upenn.edu Wed Sep 16 12:05:41 2009 From: acowley at seas.upenn.edu (Anthony Cowley) Date: Wed Sep 16 12:06:05 2009 Subject: [plt-dev] Unicode is a pain In-Reply-To: <20090916110314.GA604@perdita.local> References: <990e0c030909151558g557bda43hbd9205c10d57c5b7@mail.gmail.com> <932b2f1f0909151600x1ef268dmfb384c154857cd90@mail.gmail.com> <990e0c030909151615k7e0710b9pfd155c48605abd3a@mail.gmail.com> <81addec70909151653u36f42af7v479589aa57a03f71@mail.gmail.com> <20090916110314.GA604@perdita.local> Message-ID: <81addec70909160905l629cacaajdf3c73060d54889a@mail.gmail.com> On Wed, Sep 16, 2009 at 7:03 AM, Richard Cobbe wrote: > Interesting. ?I wasn't aware of TeX input mode and googled for it, but all > I got was TeX-mode (well, plus one mode for editing APL source), which > can't be what you're referring to. ?Could you provide some pointers? It's an input-method rather than a normal mode, but I hope a more expert Emacs user can chime in here as quick googling wasn't terribly productive for me either. Here's a blog post by someone who was pleased to find out about it themselves, In Aquamacs, I just hit C-\ to toggle it, and then all the usual TeX macros work, with auto-completion. Anthony From robby at eecs.northwestern.edu Wed Sep 16 14:35:48 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Wed Sep 16 14:36:13 2009 Subject: [plt-dev] Unicode is a pain In-Reply-To: <81addec70909160905l629cacaajdf3c73060d54889a@mail.gmail.com> References: <990e0c030909151558g557bda43hbd9205c10d57c5b7@mail.gmail.com> <932b2f1f0909151600x1ef268dmfb384c154857cd90@mail.gmail.com> <990e0c030909151615k7e0710b9pfd155c48605abd3a@mail.gmail.com> <81addec70909151653u36f42af7v479589aa57a03f71@mail.gmail.com> <20090916110314.GA604@perdita.local> <81addec70909160905l629cacaajdf3c73060d54889a@mail.gmail.com> Message-ID: <932b2f1f0909161135wbdde9d3w8266daf1312e4596@mail.gmail.com> 2009/9/16 Anthony Cowley : > On Wed, Sep 16, 2009 at 7:03 AM, Richard Cobbe wrote: >> Interesting. ?I wasn't aware of TeX input mode and googled for it, but all >> I got was TeX-mode (well, plus one mode for editing APL source), which >> can't be what you're referring to. ?Could you provide some pointers? > > It's an input-method rather than a normal mode, but I hope a more > expert Emacs user can chime in here as quick googling wasn't terribly > productive for me either. Here's a blog post by someone who was > pleased to find out about it themselves, > > > In Aquamacs, I just hit C-\ to toggle it, and then all the usual TeX > macros work, with auto-completion. That's a bit different than DrScheme: in DrScheme, it isn't a mode; you hit control-\ after typing a tex command. It would be good to have a way to get autocompletion there, but I'm hesitant to add yet another mode. Robby From rafkind at cs.utah.edu Wed Sep 16 14:38:07 2009 From: rafkind at cs.utah.edu (Jon Rafkind) Date: Wed Sep 16 14:40:20 2009 Subject: [plt-dev] mzlib/trace better prefixes Message-ID: <4AB1308F.6010707@cs.utah.edu> Attached is a patch that changes the prefixes that mzlib/trace prints depending on whether a function call is occuring or if a result is being returned. "<" is a function call and ">" is a return value. I find this is easier to read than the current ambiguous "|". If no one disagrees with the change in style then I will clean up the patch and commit it. <(a 0) < (b 0) < <(c 0) < < (d 0) > > 0 > >1 > 2 >3 3 vs |(a 0) | (b 0) | |(c 0) | | (d 0) | | 0 | |1 | 2 |3 3 Results become very ambiguous when the return value is a list that looks like a function call. #lang scheme (require mzlib/trace) (define (foo x) `(foo ,x)) (trace foo) (foo 2) $ mzscheme n.ss |(foo 2) |(foo 2) (foo 2) -------------- next part -------------- A non-text attachment was scrubbed... Name: trace.diff Type: text/x-patch Size: 7208 bytes Desc: not available Url : http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090916/4532b901/trace.bin From acowley at seas.upenn.edu Wed Sep 16 14:55:15 2009 From: acowley at seas.upenn.edu (Anthony Cowley) Date: Wed Sep 16 14:55:34 2009 Subject: [plt-dev] Unicode is a pain In-Reply-To: <932b2f1f0909161135wbdde9d3w8266daf1312e4596@mail.gmail.com> References: <990e0c030909151558g557bda43hbd9205c10d57c5b7@mail.gmail.com> <932b2f1f0909151600x1ef268dmfb384c154857cd90@mail.gmail.com> <990e0c030909151615k7e0710b9pfd155c48605abd3a@mail.gmail.com> <81addec70909151653u36f42af7v479589aa57a03f71@mail.gmail.com> <20090916110314.GA604@perdita.local> <81addec70909160905l629cacaajdf3c73060d54889a@mail.gmail.com> <932b2f1f0909161135wbdde9d3w8266daf1312e4596@mail.gmail.com> Message-ID: <81addec70909161155t1b8c8108w6e52d2c8a90b3bc1@mail.gmail.com> On Wed, Sep 16, 2009 at 2:35 PM, Robby Findler wrote: > That's a bit different than DrScheme: in DrScheme, it isn't a mode; > you hit control-\ after typing a tex command. It would be good to have > a way to get autocompletion there, but I'm hesitant to add yet another > mode. I'd rather have autocompletion for my variable names (cue someone telling me that this already works in DrScheme and I just don't know how to use it). The fact that the unicode commands are consistent across TeX, Emacs, and DrScheme is enough even without the autocompletion since most of the names are pretty reasonable. Anthony From jensaxel at soegaard.net Wed Sep 16 15:43:03 2009 From: jensaxel at soegaard.net (=?UTF-8?Q?Jens_Axel_S=C3=B8gaard?=) Date: Wed Sep 16 15:43:26 2009 Subject: [plt-dev] Unicode is a pain In-Reply-To: <932b2f1f0909161135wbdde9d3w8266daf1312e4596@mail.gmail.com> References: <990e0c030909151558g557bda43hbd9205c10d57c5b7@mail.gmail.com> <932b2f1f0909151600x1ef268dmfb384c154857cd90@mail.gmail.com> <990e0c030909151615k7e0710b9pfd155c48605abd3a@mail.gmail.com> <81addec70909151653u36f42af7v479589aa57a03f71@mail.gmail.com> <20090916110314.GA604@perdita.local> <81addec70909160905l629cacaajdf3c73060d54889a@mail.gmail.com> <932b2f1f0909161135wbdde9d3w8266daf1312e4596@mail.gmail.com> Message-ID: <4072c51f0909161243o2729bcd0x75406f4782823b3d@mail.gmail.com> 2009/9/16 Robby Findler : > 2009/9/16 Anthony Cowley : >> In Aquamacs, I just hit C-\ to toggle it, and then all the usual TeX >> macros work, with auto-completion. > > That's a bit different than DrScheme: in DrScheme, it isn't a mode; > you hit control-\ after typing a tex command. It would be good to have > a way to get autocompletion there, but I'm hesitant to add yet another > mode. This might be a bike shed discussion, but I much prefer the way Mathematica handles the entering of mathematical symbols to the DrScheme way. In Mathematica one must activates "symbol entering mode" before entering the character name. This is done via an easily found key stroke (as opposed to the more cumbersome C-\ BTW: On non-US keyboards \ is missing, so C-\ requires pressing three keys at the same time). Mathematica chose ESC as the key to enter char-inserting-mode. The carret changes visual appearence (to a verticl dotted line instead of a solid vertical line). Then one enters the character name, and finally one hits ESC again. It is works very nicely because ESC is easy to hit. Mathematica defines quite a few short cuts for the common characters such as ESC a ESC for alpha, ESC => ESC for Leftrigtarrow etc. http://reference.wolfram.com/mathematica/tutorial/EnteringGreekLetters.html http://reference.wolfram.com/mathematica/tutorial/OtherMathematicalNotation.html I noticed the difference between the two mind sets when I recently wrote a program containing alpha, beta and gamma. -- Jens Axel S?gaard From robby at eecs.northwestern.edu Wed Sep 16 19:51:02 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Wed Sep 16 19:51:24 2009 Subject: [plt-dev] Unicode is a pain In-Reply-To: <4072c51f0909161243o2729bcd0x75406f4782823b3d@mail.gmail.com> References: <990e0c030909151558g557bda43hbd9205c10d57c5b7@mail.gmail.com> <932b2f1f0909151600x1ef268dmfb384c154857cd90@mail.gmail.com> <990e0c030909151615k7e0710b9pfd155c48605abd3a@mail.gmail.com> <81addec70909151653u36f42af7v479589aa57a03f71@mail.gmail.com> <20090916110314.GA604@perdita.local> <81addec70909160905l629cacaajdf3c73060d54889a@mail.gmail.com> <932b2f1f0909161135wbdde9d3w8266daf1312e4596@mail.gmail.com> <4072c51f0909161243o2729bcd0x75406f4782823b3d@mail.gmail.com> Message-ID: <932b2f1f0909161651i51858f4ah4fec2cf4dcb6fb1d@mail.gmail.com> That does sound very nice. Esc is pretty heavily used in DrScheme already, due to its attempt to copy emacs keybindings and using esc as meta, but esc followed by another key might work to enter such a mode, but it would probably also be nice to have just a single keystroke to enter the mode. In any case, I'd welcome a patch -- and one can even try it out without modifying drscheme's source via the keybindings stuff. :) Robby On Wed, Sep 16, 2009 at 2:43 PM, Jens Axel S?gaard wrote: > 2009/9/16 Robby Findler : >> 2009/9/16 Anthony Cowley : > >>> In Aquamacs, I just hit C-\ to toggle it, and then all the usual TeX >>> macros work, with auto-completion. >> >> That's a bit different than DrScheme: in DrScheme, it isn't a mode; >> you hit control-\ after typing a tex command. It would be good to have >> a way to get autocompletion there, but I'm hesitant to add yet another >> mode. > > This might be a bike shed discussion, but I much prefer the way > Mathematica handles the entering of mathematical symbols to > the DrScheme way. > > In Mathematica one must activates "symbol entering mode" before > entering the character name. This is done via an easily found key stroke > (as opposed to the more cumbersome C-\ ? BTW: On non-US keyboards > \ is missing, so C-\ requires pressing three keys at the same time). > > Mathematica chose ESC as the key to enter char-inserting-mode. > The carret changes visual appearence (to a verticl dotted line instead > of a solid vertical line). Then one enters the character name, and > finally one hits ESC again. It is works very nicely because ESC is > easy to hit. > > Mathematica defines quite a few short cuts for the common characters > such as ?ESC a ESC for alpha, ESC => ESC for Leftrigtarrow etc. > > http://reference.wolfram.com/mathematica/tutorial/EnteringGreekLetters.html > http://reference.wolfram.com/mathematica/tutorial/OtherMathematicalNotation.html > > I noticed the difference between the two mind sets when I recently wrote > a program containing alpha, beta and gamma. > > -- > Jens Axel S?gaard > From meunier at ccs.neu.edu Wed Sep 16 21:43:25 2009 From: meunier at ccs.neu.edu (Philippe Meunier) Date: Wed Sep 16 21:43:44 2009 Subject: [plt-dev] mzlib/trace better prefixes In-Reply-To: <4AB1308F.6010707@cs.utah.edu> References: <4AB1308F.6010707@cs.utah.edu> Message-ID: <20090917014325.GA1424@denali.ccs.neu.edu> Jon Rafkind wrote: > Attached is a patch that changes the prefixes that mzlib/trace prints > depending on whether a function call is occuring or if a result is being > returned. "<" is a function call and ">" is a return value. That looks backward to me: the trace library represents the stack of function calls horizontally from left to right, so for a function call I would expect it to use ">" to point in the direction in which the stack grows... I don't see anything wrong with using "|" anyway (if it's used the right way, see below). > I find this is easier to read than the current ambiguous "|". I agree that the current output: |(fact 5) | (fact 4) | |(fact 3) | | (fact 2) | | |(fact 1) | | | (fact 0) | | | 1 | | |1 | | 2 | |6 | 24 |120 120 could be better. I understand why 120 appears twice but I find it a bit confusing, and I also think it would be better to use "|" to symbolize actual stack frames rather than just use it along with " " for vertical alignment purposes, even if that means using twice the amount of horizontal space to represent the stack. Something like this: (fact 5) | (fact 4) | | (fact 3) | | | (fact 2) | | | | (fact 1) | | | | | (fact 0) | | | | | 1 | | | | 1 | | | 2 | | 6 | 24 120 or like this, if you imagine that (fact 2) is somehow a tail call: (fact 5) | (fact 4) | | (fact 3) | | (fact 2) | | | (fact 1) | | | | (fact 0) | | | | 1 | | | 1 | | 6 | 24 120 Philippe From rafkind at cs.utah.edu Wed Sep 16 23:56:01 2009 From: rafkind at cs.utah.edu (Jon Rafkind) Date: Wed Sep 16 23:58:14 2009 Subject: [plt-dev] mzlib/trace better prefixes In-Reply-To: <20090917014325.GA1424@denali.ccs.neu.edu> References: <4AB1308F.6010707@cs.utah.edu> <20090917014325.GA1424@denali.ccs.neu.edu> Message-ID: <4AB1B351.5000700@cs.utah.edu> Philippe Meunier wrote: > Jon Rafkind wrote: > >> Attached is a patch that changes the prefixes that mzlib/trace prints >> depending on whether a function call is occuring or if a result is being >> returned. "<" is a function call and ">" is a return value. >> > > That looks backward to me: the trace library represents the stack of > function calls horizontally from left to right, so for a function call > I would expect it to use ">" to point in the direction in which the > stack grows... I don't see anything wrong with using "|" anyway (if > it's used the right way, see below). > > Eli pointed the same out to me so I'll change it to >. >> I find this is easier to read than the current ambiguous "|". >> > > I agree that the current output: > > |(fact 5) > | (fact 4) > | |(fact 3) > | | (fact 2) > | | |(fact 1) > | | | (fact 0) > | | | 1 > | | |1 > | | 2 > | |6 > | 24 > |120 > 120 > > could be better. I understand why 120 appears twice but I find it a > bit confusing, and I also think it would be better to use "|" to > symbolize actual stack frames rather than just use it along with " " > for vertical alignment purposes, even if that means using twice the > amount of horizontal space to represent the stack. Something like > this: > > The output already shows you the number of stack frames. The number of stack frames is basically the amount of space before the input/output. Only one | is printed for every two stack frames, I guess to make the output look nicer. > (fact 5) > | (fact 4) > | | (fact 3) > | | | (fact 2) > | | | | (fact 1) > | | | | | (fact 0) > | | | | | 1 > | | | | 1 > | | | 2 > | | 6 > | 24 > 120 > > or like this, if you imagine that (fact 2) is somehow a tail call: > > (fact 5) > | (fact 4) > | | (fact 3) > | | (fact 2) > | | | (fact 1) > | | | | (fact 0) > | | | | 1 > | | | 1 > | | 6 > | 24 > 120 > > I think you mean (fact 3) is a tail call, but yes the trace output does that too (condense tail calls so they take up the same amount of output). From eli at barzilay.org Thu Sep 17 05:35:51 2009 From: eli at barzilay.org (Eli Barzilay) Date: Thu Sep 17 05:36:11 2009 Subject: [plt-dev] Release for v4.2.2 has begun Message-ID: The release process for v4.2.2 has begun: the trunk was copied to a branch for any work that is left and is now bumped to v4.2.1.900. You can go on using the trunk as usual, it is now bumped to v4.2.2.1 (to avoid having two different trees with the same version). If you have any bug-fixes and changes that need to go in the release then make sure you specify that in the commit message or mail me the revision numbers. Do not try to commit anything on the pre-release branch (the server will forbid it). Note that nightly builds will go on as usual (as v4.2.2.1), and pre-release builds will be available at http://pre.plt-scheme.org/release/ Please tell me if you think that this should be announced on the plt-scheme list for wider testing. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From eli at barzilay.org Thu Sep 17 08:21:05 2009 From: eli at barzilay.org (Eli Barzilay) Date: Thu Sep 17 08:21:27 2009 Subject: [plt-dev] Release for v4.2.2 has begun In-Reply-To: References: Message-ID: <19122.10673.944247.709877@winooski.ccs.neu.edu> On Sep 17, Eli Barzilay wrote: > > 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. [...] Reminder: when you commit stuff, please indicate if it should be included branch -- either in the commit message or in a followup email. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From matthias at ccs.neu.edu Thu Sep 17 12:49:34 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Thu Sep 17 12:49:59 2009 Subject: [plt-dev] setup Message-ID: <70CCC8EB-FCC5-4D4E-8281-438AE85225B7@ccs.neu.edu> setup-plt has been suffering from this ugly mess for a couple of days now: > setup-plt: error: during making for htdch/Examples > setup-plt: load-handler: expected a `module' declaration for > `viera-bug' in # viera-bug.ss>, but found something else > make[1]: *** [install-3m] Error 1 > make: *** [install] Error 2 From ryanc at ccs.neu.edu Thu Sep 17 12:54:59 2009 From: ryanc at ccs.neu.edu (Ryan Culpepper) Date: Thu Sep 17 12:55:53 2009 Subject: [plt-dev] setup In-Reply-To: <70CCC8EB-FCC5-4D4E-8281-438AE85225B7@ccs.neu.edu> References: <70CCC8EB-FCC5-4D4E-8281-438AE85225B7@ccs.neu.edu> Message-ID: <4AB269E3.2030906@ccs.neu.edu> Is this an uncommitted local file of yours? The htdch collection is gone. Ryan Matthias Felleisen wrote: > > setup-plt has been suffering from this ugly mess for a couple of days now: > > >> setup-plt: error: during making for htdch/Examples >> setup-plt: load-handler: expected a `module' declaration for >> `viera-bug' in >> #, but >> found something else >> make[1]: *** [install-3m] Error 1 >> make: *** [install] Error 2 > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From mflatt at cs.utah.edu Thu Sep 17 12:55:03 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Thu Sep 17 12:55:57 2009 Subject: [plt-dev] setup In-Reply-To: <70CCC8EB-FCC5-4D4E-8281-438AE85225B7@ccs.neu.edu> References: <70CCC8EB-FCC5-4D4E-8281-438AE85225B7@ccs.neu.edu> Message-ID: <20090917165504.6A3156500C6@mail-svr1.cs.utah.edu> You need to delete your leftover "collects/htdch" directory, since it has been removed from the SVN trunk. At Thu, 17 Sep 2009 12:49:34 -0400, Matthias Felleisen wrote: > > setup-plt has been suffering from this ugly mess for a couple of days > now: > > > > setup-plt: error: during making for htdch/Examples > > setup-plt: load-handler: expected a `module' declaration for > > `viera-bug' in # > viera-bug.ss>, but found something else > > make[1]: *** [install-3m] Error 1 > > make: *** [install] Error 2 > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From matthias at ccs.neu.edu Thu Sep 17 12:55:56 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Thu Sep 17 12:56:24 2009 Subject: [plt-dev] setup In-Reply-To: <20090917165504.6A3156500C6@mail-svr1.cs.utah.edu> References: <70CCC8EB-FCC5-4D4E-8281-438AE85225B7@ccs.neu.edu> <20090917165504.6A3156500C6@mail-svr1.cs.utah.edu> Message-ID: <50965C45-76D6-4008-9AAA-4C7195BDA8B9@ccs.neu.edu> Mea culpa .. On Sep 17, 2009, at 12:55 PM, Matthew Flatt wrote: > You need to delete your leftover "collects/htdch" directory, since it > has been removed from the SVN trunk. > > At Thu, 17 Sep 2009 12:49:34 -0400, Matthias Felleisen wrote: >> >> setup-plt has been suffering from this ugly mess for a couple of days >> now: >> >> >>> setup-plt: error: during making for htdch/Examples >>> setup-plt: load-handler: expected a `module' declaration for >>> `viera-bug' in #>> viera-bug.ss>, but found something else >>> make[1]: *** [install-3m] Error 1 >>> make: *** [install] Error 2 >> _________________________________________________ >> For list-related administrative tasks: >> http://list.cs.brown.edu/mailman/listinfo/plt-dev From kathryn.gray at cl.cam.ac.uk Fri Sep 18 08:45:48 2009 From: kathryn.gray at cl.cam.ac.uk (Kathryn Gray) Date: Fri Sep 18 09:01:50 2009 Subject: [plt-dev] Expansion to check forms Message-ID: <25E84973-C419-41D1-A9C0-A81FB5F1FB26@cl.cam.ac.uk> Per some recent requests, I've added two new forms to the check-expect line (primarily for testing random functions): check-member-of check-range Documentation for these is in the HtDP docs and the test-engine docs. Heads up to John: these expand too much in the stepper. Cheers, -Kathy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090918/7d09c472/attachment-0001.html From matthias at ccs.neu.edu Fri Sep 18 09:06:56 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Fri Sep 18 09:07:24 2009 Subject: [plt-dev] Expansion to check forms In-Reply-To: <25E84973-C419-41D1-A9C0-A81FB5F1FB26@cl.cam.ac.uk> References: <25E84973-C419-41D1-A9C0-A81FB5F1FB26@cl.cam.ac.uk> Message-ID: <3050B693-E544-414D-8264-63DF4B96C482@ccs.neu.edu> Thanks for the quick service. On Sep 18, 2009, at 8:45 AM, Kathryn Gray wrote: > Per some recent requests, I've added two new forms to the check- > expect line (primarily for testing random functions): > check-member-of > check-range > > Documentation for these is in the HtDP docs and the test-engine docs. > > Heads up to John: these expand too much in the stepper. > > Cheers, > -Kathy > > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From clements at brinckerhoff.org Fri Sep 18 11:43:58 2009 From: clements at brinckerhoff.org (John Clements) Date: Fri Sep 18 11:44:20 2009 Subject: [plt-dev] Re: Expansion to check forms In-Reply-To: <25E84973-C419-41D1-A9C0-A81FB5F1FB26@cl.cam.ac.uk> References: <25E84973-C419-41D1-A9C0-A81FB5F1FB26@cl.cam.ac.uk> Message-ID: On Sep 18, 2009, at 5:45 AM, Kathryn Gray wrote: > Per some recent requests, I've added two new forms to the check- > expect line (primarily for testing random functions): > check-member-of > check-range > > Documentation for these is in the HtDP docs and the test-engine docs. > > Heads up to John: these expand too much in the stepper. Thanks. Are these going into 4.2.2? 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/20090918/139c7a59/smime.bin From matthias at ccs.neu.edu Fri Sep 18 11:58:24 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Fri Sep 18 11:58:52 2009 Subject: [plt-dev] Re: Expansion to check forms In-Reply-To: References: <25E84973-C419-41D1-A9C0-A81FB5F1FB26@cl.cam.ac.uk> Message-ID: <445E494D-F5D8-416B-8029-B0A3E4150205@ccs.neu.edu> While I am really tempted, let's follow our standard policy. No new features now. On Sep 18, 2009, at 11:43 AM, John Clements wrote: > > On Sep 18, 2009, at 5:45 AM, Kathryn Gray wrote: > >> Per some recent requests, I've added two new forms to the check- >> expect line (primarily for testing random functions): >> check-member-of >> check-range >> >> Documentation for these is in the HtDP docs and the test-engine docs. >> >> Heads up to John: these expand too much in the stepper. > > Thanks. Are these going into 4.2.2? > > John > > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From eli at barzilay.org Sun Sep 20 16:17:44 2009 From: eli at barzilay.org (Eli Barzilay) Date: Sun Sep 20 16:18:05 2009 Subject: [plt-dev] Re: Expansion to check forms In-Reply-To: <445E494D-F5D8-416B-8029-B0A3E4150205@ccs.neu.edu> References: <25E84973-C419-41D1-A9C0-A81FB5F1FB26@cl.cam.ac.uk> <445E494D-F5D8-416B-8029-B0A3E4150205@ccs.neu.edu> Message-ID: <19126.36328.658771.300444@winooski.ccs.neu.edu> Kathy -- to be safe, these are the commits that you did that do *not* go into 4.2.2: 16045, 16064, 16065. On Sep 18, Matthias Felleisen wrote: > While I am really tempted, let's follow our standard policy. No new > features now. > > > On Sep 18, 2009, at 11:43 AM, John Clements wrote: > > > > > On Sep 18, 2009, at 5:45 AM, Kathryn Gray wrote: > > > >> Per some recent requests, I've added two new forms to the check- > >> expect line (primarily for testing random functions): > >> check-member-of > >> check-range > >> > >> Documentation for these is in the HtDP docs and the test-engine docs. > >> > >> Heads up to John: these expand too much in the stepper. > > > > Thanks. Are these going into 4.2.2? -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From eli at barzilay.org Sun Sep 20 16:54:56 2009 From: eli at barzilay.org (Eli Barzilay) Date: Sun Sep 20 16:55:16 2009 Subject: [plt-dev] More profj leftovers Message-ID: <19126.38560.315096.892722@winooski.ccs.neu.edu> These are profj leftovers that need to be removed -- looks like it's only Robby and Kathy that have items here: * scribblings/drscheme/menus.scrbl Has descriptions of "Insert Java Comment Box" and "Insert Java Interactions Box" menu items. * scribblings/drscheme/languages.scrbl Has a "ProfessorJ" section. * test-engine/test-coverage.scm Has two style classes named "profj:syntax-colors:scheme:covered" and "profj:syntax-colors:scheme:uncovered". (Will it be a problem to rename these?) * string-constants These probably need to stay there to make the planet tool work. (And point at the problem with the `string-constants' collection in that it's not modular.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From robby at eecs.northwestern.edu Sun Sep 20 18:23:39 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Sun Sep 20 18:23:57 2009 Subject: [plt-dev] More profj leftovers In-Reply-To: <19126.38560.315096.892722@winooski.ccs.neu.edu> References: <19126.38560.315096.892722@winooski.ccs.neu.edu> Message-ID: <932b2f1f0909201523g22909f3bn3d99317a638dac0b@mail.gmail.com> On Sun, Sep 20, 2009 at 3:54 PM, Eli Barzilay wrote: > These are profj leftovers that need to be removed -- looks like it's > only Robby and Kathy that have items here: > > * scribblings/drscheme/menus.scrbl > ?Has descriptions of "Insert Java Comment Box" and "Insert Java > ?Interactions Box" menu items. > > * scribblings/drscheme/languages.scrbl > ?Has a "ProfessorJ" section. I've removed the two above. Robby From robby at eecs.northwestern.edu Sun Sep 20 20:13:09 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Sun Sep 20 20:13:57 2009 Subject: [plt-dev] error in teaching languages Message-ID: <932b2f1f0909201713k2339ad6aj31e2e5c639d232d@mail.gmail.com> I noticed that 'error' changed in the teaching languages. In 4.2.1, it used to take two arguments, but now it takes 1. Is that intentional? (Sorry if I missed a message somewhere about that.) Robby From matthias at ccs.neu.edu Sun Sep 20 20:17:49 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Sun Sep 20 20:18:25 2009 Subject: [plt-dev] error in teaching languages In-Reply-To: <932b2f1f0909201713k2339ad6aj31e2e5c639d232d@mail.gmail.com> References: <932b2f1f0909201713k2339ad6aj31e2e5c639d232d@mail.gmail.com> Message-ID: <2FCAB1AB-F66F-4077-838B-D9BEAD35577D@ccs.neu.edu> That's a change for HtDP/2e BUT as soon as I committed it I realized that I needed to accommodate old-style HtDP. Then the power went out :-) On Sep 20, 2009, at 8:13 PM, Robby Findler wrote: > I noticed that 'error' changed in the teaching languages. In 4.2.1, it > used to take two arguments, but now it takes 1. Is that intentional? > (Sorry if I missed a message somewhere about that.) > > Robby > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From jpc-ml at zenburn.net Sun Sep 27 10:27:30 2009 From: jpc-ml at zenburn.net (=?UTF-8?B?SmFrdWIgUGlvdHIgQ8WCYXBh?=) Date: Sun Sep 27 10:27:52 2009 Subject: [plt-dev] Profiling Message-ID: <4ABF7652.9020400@zenburn.net> I tried to profile some GUI code which uses canvas% but unfortunately I get strange results. AFAIU (most of) the time spent in the C drawing code is accounted for but distributed non-uniformly between scheme functions. My conjecture is that the profiling thread cannot run while the drawing is taking place (assuming all Scheme threads are serialized like with FFI calls) which causes non-uniform continuation mark sampling. The profiler code is correcting for this non-uniformity by adding all the time (spent in scheme and C) to the last captured sample (which is not likely to be the one that called the C code). PS. There are some difficulties with profiling in the presence of tail-calls but this can be fixed with some use of trace-begin from tail.plt. -- regards, Jakub Piotr C?apa From eli at barzilay.org Mon Sep 28 11:24:32 2009 From: eli at barzilay.org (Eli Barzilay) Date: Mon Sep 28 11:24:58 2009 Subject: [plt-dev] DNS changes Message-ID: <19136.54576.770771.124970@winooski.ccs.neu.edu> JFYI: I have changed the way DNS is done for plt-scheme.org, schemers.org, htdp.org, and nepls.org. Hopefully, there shouldn't be any visible problems, but let me know asap if you see anything fishy. Shriram & Mike: it would also be good to try out email to the domains you're dealing with -- nepls.org and schemers.org. (I've just tried emailing passwords@htdp.org and that seems to be fine.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From eli at barzilay.org Mon Sep 28 15:59:49 2009 From: eli at barzilay.org (Eli Barzilay) Date: Mon Sep 28 16:00:13 2009 Subject: [plt-dev] Pre-Release Checklist for v4.2.2 Message-ID: [Apologies for the huge delay.] Checklist items for the v4.2.2 release (using the v4.2.1.900 release candidate build) Search for your name to find relevant items, reply when you finish an item (please indicate which item is done). Also, if you have any commits that should have been merged, make sure that they're in. Important: new builds are created without announcement, usually whenever I see significant commits. If you need to commit changes, please make sure you tell me to merge it to the release branch. --> Release candidates are at --> http://pre.plt-scheme.org/release/installers Please use these installers (or source bundles) -- don't test from your own svn chekout (don't test v4.2.2.1 by mistake!). To get the tests directory in the normal release, you can do this: cd .../collects svn export http://svn.plt-scheme.org/plt/release/collects/tests ---------------------------------------------------------------------- * Matthew Flatt - MzScheme Tests - Languages Tests - MrEd Tests (Also check that `mred -z' and `mred-text' still works in Windows and Mac OS X) - mzc Tests - mzc --exe tests - .plt-packing Tests - Games Tests - Unit Tests - Syntax Color Tests - R6RS Tests Updates: - MzScheme Updates: update HISTORY - MrEd Updates: update README, HISTORY (updates should show v4.2.2 as the most current version) - Update man pages in plt/man/man1: mred.1, mzscheme.1 Email me to merge the changes from the trunk when they're done, or tell me if there are no such changes. * Robby Findler - DrScheme Tests - Framework Tests - Contracts Tests - Games Tests - Teachpacks Tests: image tests - PLaneT Tests Updates: - DrScheme Updates: update HISTORY - Redex Updates: update HISTORY (updates should show v4.2.2 as the most current version) - Ensure that previous version of DrScheme's preference files still starts up with new DrScheme - Update man pages in plt/man/man1: drscheme.1 Email me to merge the changes from the trunk when they're done, or tell me if there are no such changes. * John Clements - Stepper Tests Updates: - Stepper Updates: update HISTORY (updates should show v4.2.2 as the most current version) Email me to merge the changes from the trunk when they're done, or tell me if there are no such changes. * Matthias Felleisen - Teachpacks Tests: check that new teachpacks are addable - Teachpack Docs: check teachpack docs in the bundles Updates: - Teachpack Updates: update HISTORY (updates should show v4.2.2 as the most current version; email me to merge the changes from the trunk when they're done, or tell me if there are no such changes.) * Ryan Culpepper - Macro Debugger Tests - Syntax Classifier Tests * Jay McCarthy - Web server Tests - XML Tests - HTML Tests * Paul Steckler - MysterX Tests - MzCOM Tests * Kathy Gray - ProfJ Tests - Test Engine Tests * Noel Welsh , Chongkai Zhu - SRFI Tests - Ensure that all claimed srfi's are in the bundle and they all load into mzscheme or drscheme (as appropriate) * Sam Tobin-Hochstadt - Match Tests - Typed Scheme Tests * Stevie Strickland - Unit Contract Tests - Contract Region Tests * Eli Barzilay - Swindle Tests - Plot Tests - PLT Tree: compare new distribution trees to previous ones Version Updates: if a major change has happened, update the version number in: - plt/collects/mzscheme/info.ss - plt/collects/mred/info.ss * Doug Williams - Plot Tests * Greg Cooper - FrTime Tests * Carl Eastlund - Dracula Tests (confirm that Dracula runs from PLaneT) * Shriram Krishnamurthi Tour: check the tour and generate a new one if needed. [Note: Since this is a v4.2.1.900 build, you will need to edit your .../collects/framework/private/version.ss file and change `(version)' to `"4.2.2"'.] -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From eli at barzilay.org Mon Sep 28 16:02:27 2009 From: eli at barzilay.org (Eli Barzilay) Date: Mon Sep 28 16:02:48 2009 Subject: [plt-dev] Release Announcement for v4.2.2 Message-ID: The list of possible release announcement items that I have collected is below. Please mail me new items and/or full items, or tell me if something is irrelevant. (In any case, please indicate which part of these items it applies to.) ---------------------------------------------------------------------- * profj (and related: `profjWizard', `htdc') gone, profj will appear in planet instead * test-engine changes - Change to behavior in interactions window. Option 1 implemented. - Turning off the nag * scribble reorganization * drscheme - moved the warning into the frame (out of the interactions window) - added a close icon to the yellow warning message - syntax coloring for at-exp - automatic compilation in the module language - drscheme now saves its compiled files in its own directory - automatic compilation in drscheme now avoids the installed planet files - improved responsiveness of interactive searching - changed the default for fixing up parentheses - new coloring of set!'d variables - added phase information to the module browser * New stuff in `syntax/parse' Also `syntax/keyword'? `stxclass' collection gone * Printout of syntax objects (and `print-syntax-width') * new core function `file-or-directory-identity' * new `scheme/generator' library - make generators use a parameterized yield function * new `in-producer' iteration * New `scheme/unsafe/ops' module * htdp changes - added last-picture option to stop-when - added make-pair to beginner - added state display to world programs - re-directed image - run-simulation -> animate * `slideshow/play' * contracts: - exists contracts - added scheme/exists lang - define-struct/contract can handle sub-typing now - allow #:property keyword * DeinProgramm/DMdA - Add QuickCheck-based property testing to the DeinProgramm/DMdA languages. - contract stuff - a bunch of other things, which I assume is included in the text I have ---------------------------------------------------------------------- -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From robby at eecs.northwestern.edu Mon Sep 28 16:24:24 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Mon Sep 28 16:24:43 2009 Subject: [plt-dev] Release Announcement for v4.2.2 In-Reply-To: References: Message-ID: <932b2f1f0909281324s567d58d3ic25bafee4209884@mail.gmail.com> On Mon, Sep 28, 2009 at 3:02 PM, Eli Barzilay wrote: > The list of possible release announcement items that I have collected > is below. ?Please mail me new items and/or full items, or tell me if > something is irrelevant. ?(In any case, please indicate which part of > these items it applies to.) > > ---------------------------------------------------------------------- > * profj (and related: `profjWizard', `htdc') gone, > ?profj will appear in planet instead > > * test-engine changes > ? ?- Change to behavior in interactions window. Option 1 > ? ? ?implemented. > ? ?- Turning off the nag > > * scribble reorganization > > * drscheme > ? ?- moved the warning into the frame (out of the interactions > ? ? ?window) > ? ? ?- added a close icon to the yellow warning message > ? ?- syntax coloring for at-exp > ? ?- automatic compilation in the module language > ? ? ?- drscheme now saves its compiled files in its own directory > ? ? ?- automatic compilation in drscheme now avoids the installed > ? ? ? ?planet files > ? ?- improved responsiveness of interactive searching > ? ?- changed the default for fixing up parentheses > ? ?- new coloring of set!'d variables > ? ?- added phase information to the module browser The automatic compilation is entirely new in this release (so the second subbullet can just be part of the main thing). If someone else wants to say which of the above are worth being in the release, I'd be happy to supply the blurb. The #:exists contracts may deserve a mention. If they do, I'd say something like this: - added support for abstract contracts via the #:exists keywords. This is an experiment to add support for data hiding to the contract system. Robby From robby at eecs.northwestern.edu Mon Sep 28 17:00:58 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Mon Sep 28 17:01:16 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.2.2 In-Reply-To: References: Message-ID: <932b2f1f0909281400j2d1172dbs807b1fd7f7008233@mail.gmail.com> On Mon, Sep 28, 2009 at 2:59 PM, Eli Barzilay wrote: > * Robby Findler > ?- DrScheme Tests > ?- Framework Tests > ?- Contracts Tests > ?- Games Tests > ?- Teachpacks Tests: image tests > ?- PLaneT Tests Done. > ?Updates: > ?- DrScheme Updates: update HISTORY > ?- Redex Updates: update HISTORY > ?(updates should show v4.2.2 as the most current version) Committed, revision 16148 in svn. Please merge into the release branch. > ?- 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 Mon Sep 28 17:06:01 2009 From: sstrickl at ccs.neu.edu (Stevie Strickland) Date: Mon Sep 28 17:06:26 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.2.2 In-Reply-To: References: Message-ID: <11E4435A-C2ED-4107-B7E2-B9A6C0449EBD@ccs.neu.edu> On Sep 28, 2009, at 3:59 PM, Eli Barzilay wrote: > * Stevie Strickland > - Unit Contract Tests > - Contract Region Tests Done. Stevie From matthias at ccs.neu.edu Tue Sep 29 09:05:45 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Tue Sep 29 09:06:11 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.2.2 In-Reply-To: References: Message-ID: <64854C89-AE9A-490F-B073-48C67E726A17@ccs.neu.edu> On Sep 28, 2009, at 3:59 PM, Eli Barzilay wrote: > * Matthias Felleisen > - Teachpacks Tests: check that new teachpacks are addable > - Teachpack Docs: check teachpack docs in the bundles > Updates: > - Teachpack Updates: update HISTORY > (updates should show v4.2.2 as the most current version; email me > to merge the changes from the trunk when they're done, or tell me if > there are no such changes.) done From robby at eecs.northwestern.edu Tue Sep 29 10:24:06 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Tue Sep 29 10:24:25 2009 Subject: [plt-dev] mzlib/trace broken (and thus redex too) Message-ID: <932b2f1f0909290724x43daa6c3w77f4aa89680245fb@mail.gmail.com> >From the latest svn sources, running setup-plt: setup-plt: in mzlib /home/robby/svn/exp/plt/collects/mzlib/trace.ss:7:34: module: provided identifier not defined or imported at: trace-apply in: (#%module-begin (printing-module-begin (require scheme/pretty (for-syntax scheme/base))) (printing-module-begin (provide trace untrace current-trace-print-args trace-apply current-trace-notify current-prefix-out current-prefix-in)) (printing-module-begi... From robby at eecs.northwestern.edu Tue Sep 29 10:35:41 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Tue Sep 29 10:36:00 2009 Subject: [plt-dev] Re: mzlib/trace broken (and thus redex too) In-Reply-To: <932b2f1f0909290724x43daa6c3w77f4aa89680245fb@mail.gmail.com> References: <932b2f1f0909290724x43daa6c3w77f4aa89680245fb@mail.gmail.com> Message-ID: <932b2f1f0909290735w2af540a3i1c7209e750503ef8@mail.gmail.com> Turns out it was easy to fix, so I've committed the change (a function was renamed, but the provide wasn't changed). Robby On Tue, Sep 29, 2009 at 9:24 AM, Robby Findler wrote: > From the latest svn sources, running setup-plt: > > setup-plt: ?in mzlib > /home/robby/svn/exp/plt/collects/mzlib/trace.ss:7:34: module: provided > identifier not defined or imported at: trace-apply in: (#%module-begin > (printing-module-begin (require scheme/pretty (for-syntax > scheme/base))) (printing-module-begin (provide trace untrace > current-trace-print-args trace-apply current-trace-notify > current-prefix-out current-prefix-in)) (printing-module-begi... > From noelwelsh at gmail.com Tue Sep 29 10:36:08 2009 From: noelwelsh at gmail.com (Noel Welsh) Date: Tue Sep 29 10:36:27 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.2.2 In-Reply-To: References: Message-ID: On Mon, Sep 28, 2009 at 8:59 PM, 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 N. From m.douglas.williams at gmail.com Tue Sep 29 11:05:23 2009 From: m.douglas.williams at gmail.com (Doug Williams) Date: Tue Sep 29 11:13:05 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.2.2 In-Reply-To: References: Message-ID: * Doug Williams > - Plot Tests > > Done. All of the PLoT demos and the science collection PLoT extensions work as expected. The fix for the inference collection bug also works. I now get a couple of scribble errors in my packages that I didn't get before. I will track those down. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090929/05fc5af1/attachment.htm From mflatt at cs.utah.edu Tue Sep 29 11:39:47 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Tue Sep 29 11:40:07 2009 Subject: [plt-dev] Pre-Release Checklist for v4.2.2 In-Reply-To: References: Message-ID: <20090929153948.7694B6500BA@mail-svr1.cs.utah.edu> At Mon, 28 Sep 2009 15:59:49 -0400, Eli Barzilay wrote: > * Matthew Flatt > - MzScheme Tests > - Languages Tests > - MrEd Tests (Also check that `mred -z' and `mred-text' still works > in Windows and Mac OS X) > - mzc Tests > - mzc --exe tests > - .plt-packing Tests > - Games Tests > - Unit Tests > - Syntax Color Tests > - R6RS Tests > Updates: > - MzScheme Updates: update HISTORY > - MrEd Updates: update README, HISTORY > (updates should show v4.2.2 as the most current version) > - Update man pages in plt/man/man1: mred.1, mzscheme.1 > Email me to merge the changes from the trunk when they're done, > or tell me if there are no such changes. Done. From ghcooper at gmail.com Tue Sep 29 12:07:33 2009 From: ghcooper at gmail.com (Gregory Cooper) Date: Tue Sep 29 12:07:53 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.2.2 In-Reply-To: References: Message-ID: <65e1d50c0909290907me3b1aa8s42fa238cd029cf35@mail.gmail.com> > * Greg Cooper > ?- FrTime Tests Done. From kathryn.gray at cl.cam.ac.uk Tue Sep 29 12:09:35 2009 From: kathryn.gray at cl.cam.ac.uk (Kathryn Gray) Date: Tue Sep 29 12:09:55 2009 Subject: [plt-dev] Pre-Release Checklist for v4.2.2 In-Reply-To: References: Message-ID: On 28 Sep 2009, at 8:59:49, Eli Barzilay wrote: > > * Kathy Gray > - ProfJ Tests This nag can be removed > - Test Engine Tests Done -Kathy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090929/defb298c/attachment.htm From carl.eastlund at gmail.com Tue Sep 29 12:21:47 2009 From: carl.eastlund at gmail.com (Carl Eastlund) Date: Tue Sep 29 12:22:25 2009 Subject: [plt-dev] Pre-Release Checklist for v4.2.2 In-Reply-To: References: Message-ID: <990e0c030909290921ma37c629pa71231af33aa399f@mail.gmail.com> On Mon, Sep 28, 2009 at 3:59 PM, Eli Barzilay wrote: > * Carl Eastlund > ?- Dracula Tests (confirm that Dracula runs from PLaneT) Done. (There's a bug in one of the Dracula teachpacks I need to fix, but since it's on Planet there's no need to hold up the release. The installation works fine.) --Carl From ryanc at ccs.neu.edu Tue Sep 29 16:53:39 2009 From: ryanc at ccs.neu.edu (Ryan Culpepper) Date: Tue Sep 29 16:54:24 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.2.2 In-Reply-To: References: Message-ID: > * Ryan Culpepper > - Macro Debugger Tests > - Syntax Classifier Tests Done (committed bug fix to macro stepper, r16173) Ryan From rafkind at cs.utah.edu Tue Sep 29 16:56:59 2009 From: rafkind at cs.utah.edu (Jon Rafkind) Date: Tue Sep 29 16:59:33 2009 Subject: [plt-dev] Release Announcement for v4.2.2 In-Reply-To: References: Message-ID: <4AC2749B.9080105@cs.utah.edu> > * new `scheme/generator' library > - make generators use a parameterized yield function > > * new `in-producer' iteration > * new `scheme/generator' library allows for coroutine style iterators * new `in-producer' form that makes `scheme/generator' available inside `for' style iteration From mflatt at cs.utah.edu Tue Sep 29 17:09:31 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Tue Sep 29 17:09:51 2009 Subject: [plt-dev] Release Announcement for v4.2.2 In-Reply-To: References: Message-ID: <20090929210931.8D630650064@mail-svr1.cs.utah.edu> At Mon, 28 Sep 2009 16:02:27 -0400, Eli Barzilay wrote: > * scribble reorganization * New Scribble libraries and documentation make it easier to get started with Scribble, especially for uses other than PLT documentation. DrScheme now supports @-expression coloring and tabbing for Scribble languages and `#lang at-exp ...'. > * Printout of syntax objects (and `print-syntax-width') > * new core function `file-or-directory-identity' > * New `scheme/unsafe/ops' module > * `slideshow/play' Too minor to mention. (Support for unsafe operations might evolve into something worth mentioning, but it's not yet there.) From clements at brinckerhoff.org Tue Sep 29 18:36:31 2009 From: clements at brinckerhoff.org (John Clements) Date: Tue Sep 29 18:36:52 2009 Subject: [plt-dev] DrScheme output on stderr in OS X 10.6 Message-ID: <7BA86677-E2D5-4647-8EDC-BCEC1C777A9D@brinckerhoff.org> Due possibly to changes in the way the OS works, DrScheme is generating a fair number of messages on stderr (they also go into system.log, AFAICT). Here's the most recent pair, obtained from the release candidate 4.2.1.900: Tue Sep 29 15:28:20 pcp062723pcs.wireless.calpoly.edu DrScheme[73277] : kCGErrorIllegalArgument: CGSOrderWindowList Tue Sep 29 15:28:20 pcp062723pcs.wireless.calpoly.edu DrScheme[73277] : kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged. FWIW, "fair" number = between 0 and 10 per day. 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/20090929/f03577cf/smime.bin From clements at brinckerhoff.org Tue Sep 29 18:54:19 2009 From: clements at brinckerhoff.org (John Clements) Date: Tue Sep 29 18:54:43 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.2.2 In-Reply-To: References: Message-ID: <6D125AE7-2247-4E00-BD94-6AB85D75FD23@brinckerhoff.org> On Sep 28, 2009, at 12:59 PM, Eli Barzilay wrote: > > * John Clements > - Stepper Tests Found an important bug. Looks like an easy fix that should go in the release. I expect to have this fixed tonight. 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/20090929/2e6c8646/smime.bin From clements at brinckerhoff.org Wed Sep 30 02:06:11 2009 From: clements at brinckerhoff.org (John Clements) Date: Wed Sep 30 02:06:37 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.2.2 In-Reply-To: <6D125AE7-2247-4E00-BD94-6AB85D75FD23@brinckerhoff.org> References: <6D125AE7-2247-4E00-BD94-6AB85D75FD23@brinckerhoff.org> Message-ID: <68215305-DD9A-4373-BE03-CB61C39854CD@brinckerhoff.org> On Sep 29, 2009, at 3:54 PM, John Clements wrote: > > On Sep 28, 2009, at 12:59 PM, Eli Barzilay wrote: > >> >> * John Clements >> - Stepper Tests > > Found an important bug. Looks like an easy fix that should go in > the release. I expect to have this fixed tonight. Fixed, thanks for waiting. 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/20090929/5c312266/smime.bin From clements at brinckerhoff.org Wed Sep 30 10:55:50 2009 From: clements at brinckerhoff.org (John Clements) Date: Wed Sep 30 10:56:23 2009 Subject: [plt-dev] Re: Pre-Release Checklist for v4.2.2 In-Reply-To: References: Message-ID: On Sep 28, 2009, at 12:59 PM, Eli Barzilay wrote: > > * John Clements > - Stepper Tests done. > Updates: > - Stepper Updates: update HISTORY > (updates should show v4.2.2 as the most current version) > Email me to merge the changes from the trunk when they're done, > or tell me if there are no such changes. done. 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/20090930/e5ff0545/smime.bin