Re: [racket-dev] Release for v5.0.2 has begun
Here is one example. (make-discrete-histogram (case- (-r ((n1 integer?) (n2 (and/c integer? (=/c n1))) (dynamic? boolean?)) discrete-histogram?) (-r ((n1 integer?) (n2 (and/c integer? (=/c n1 discrete-histogram?) (- discrete-histogram?))) This code predates optional and keyword parameters. In cases like this, I can rewrite them using optional parameters. But, in the random distribution functions it is the first argument that is optional and that won't work. So, for example the flat (i.e., uniform) distribution includes a contract: (case- (-r ((r random-source?) (a real?) (b (/c a))) real?) (-r ((a real?) (b (/c a))) real?))) I'm not sure that one can be easily rewritten in the current contract system. [I think I would have to move the b a constraint into the code itself in the current contract system. Or, change the argument order and break backward compatibility.] Doug On Sun, Oct 24, 2010 at 6:23 PM, Robby Findler ro...@eecs.northwestern.eduwrote: The new case- only supports simple contracts, that's right. If you have more complex ones that it would be helpful to support (and can share them), that would help us guide our efforts. Thanks, Robby On Sun, Oct 24, 2010 at 7:04 PM, Doug Williams m.douglas.willi...@gmail.com wrote: The main problem I'm having is that the code has been around awhile and hasn't been fully converted to Racket - in particular it uses the scheme language (instead of the racket language) and uses (require (lib contract)). All of that seems to mean that I can't just add #:flat? #t - I get a message that vector-of doesn't accept keyword arguments. And, the case- contracts use -r, which apparently isn't supported anymore. All that means that I can't just switch to the racket language and new contracts. So, I have some conversion work to do. On the case- problem, it seems it no longer supports anything but -. Is there something I am missing there? Doug On Sun, Oct 24, 2010 at 8:53 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Fri, 22 Oct 2010 21:31:43 -0600, Doug Williams wrote: Matthew, would it make more sense to have unsafe-vector-ref (and related functions) be the more general function and unsafe-vector*-ref be the one that doesn't work on chaperoned vectors? That is just swap the definitions. That way user code that is already using unsafe-vector-ref (etc) will continue to work. As it stands, existing code that has unsafe-vector-ref (etc) will often still work (in the sense of not getting any error or crashing), but just gives the wrong results. For example, if you run science-test.ss from the examples directory in the science collection, there are no errors. But, some of the answers are wrong - for example the very first one, the gamma function. [In other cases, like the FFT routines, there are either run-time errors or crashes.] Anyway, if it isn't too late, I think swapping the definitions would make more sense and be safer. I've gone back and forth. I agree that it would be safer, but `vector-ref' is safer still, and I think of the job of `unsafe-X' as providing the lowest possible overhead over `X'. It seems nicer to me to have `*' mean somewhere in between rather than even faster. Then again, it seems bad that `vector?' (plus index bounds) isn't enough to guard `unsafe-vector-ref'. Overall, at this point in the release cycle, I'm inclined to leave things where they are (i.e., it may be too late). But let's hear more opinions from those who use `unsafe-vector-ref' and unsafe-vector*-ref'. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release for v5.0.2 has begun
On Mon, Oct 25, 2010 at 10:06 AM, Doug Williams m.douglas.willi...@gmail.com wrote: (case- (-r ((r random-source?) (a real?) (b (/c a))) real?) (-r ((a real?) (b (/c a))) real?))) I'm not sure that one can be easily rewritten in the current contract system. [I think I would have to move the b a constraint into the code itself in the current contract system. Or, change the argument order and break backward compatibility.] This can be written as a dependent contract, but with worse error messages. (-i ([r/a (or/c random-source? real?)] [a/b real?]) ([b/opt (r/a a/b) (if (random-source? r/a) (/c a/b) none/c)]) [result real?]) -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release for v5.0.2 has begun
Thanks, that's a great example. The idea (at least from the contract's point of view) is that there are two different functions with one name that have two different arities, I think. So maybe the right way to bring back case- is that contracts that match functions should come with some way to find out what arities they can match (this is kind of there implicitly now, but probably needs to be explicit) and then say that either there is no overlap or there is an ordering so that, given a function with some specific arity (arities) it gets slotted into particular parts of the contracts inside the case-. (thinking a little bit, I guess that we'd have to say that there should not be any overlap or else we'd have to kind of mix and match parts of contracts to parts of functions that seems pretty complex (if that's too opaque I can give an example to explain what I meant)) Robby On Mon, Oct 25, 2010 at 9:06 AM, Doug Williams m.douglas.willi...@gmail.com wrote: Here is one example. (make-discrete-histogram (case- (-r ((n1 integer?) (n2 (and/c integer? (=/c n1))) (dynamic? boolean?)) discrete-histogram?) (-r ((n1 integer?) (n2 (and/c integer? (=/c n1 discrete-histogram?) (- discrete-histogram?))) This code predates optional and keyword parameters. In cases like this, I can rewrite them using optional parameters. But, in the random distribution functions it is the first argument that is optional and that won't work. So, for example the flat (i.e., uniform) distribution includes a contract: (case- (-r ((r random-source?) (a real?) (b (/c a))) real?) (-r ((a real?) (b (/c a))) real?))) I'm not sure that one can be easily rewritten in the current contract system. [I think I would have to move the b a constraint into the code itself in the current contract system. Or, change the argument order and break backward compatibility.] Doug On Sun, Oct 24, 2010 at 6:23 PM, Robby Findler ro...@eecs.northwestern.edu wrote: The new case- only supports simple contracts, that's right. If you have more complex ones that it would be helpful to support (and can share them), that would help us guide our efforts. Thanks, Robby On Sun, Oct 24, 2010 at 7:04 PM, Doug Williams m.douglas.willi...@gmail.com wrote: The main problem I'm having is that the code has been around awhile and hasn't been fully converted to Racket - in particular it uses the scheme language (instead of the racket language) and uses (require (lib contract)). All of that seems to mean that I can't just add #:flat? #t - I get a message that vector-of doesn't accept keyword arguments. And, the case- contracts use -r, which apparently isn't supported anymore. All that means that I can't just switch to the racket language and new contracts. So, I have some conversion work to do. On the case- problem, it seems it no longer supports anything but -. Is there something I am missing there? Doug On Sun, Oct 24, 2010 at 8:53 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Fri, 22 Oct 2010 21:31:43 -0600, Doug Williams wrote: Matthew, would it make more sense to have unsafe-vector-ref (and related functions) be the more general function and unsafe-vector*-ref be the one that doesn't work on chaperoned vectors? That is just swap the definitions. That way user code that is already using unsafe-vector-ref (etc) will continue to work. As it stands, existing code that has unsafe-vector-ref (etc) will often still work (in the sense of not getting any error or crashing), but just gives the wrong results. For example, if you run science-test.ss from the examples directory in the science collection, there are no errors. But, some of the answers are wrong - for example the very first one, the gamma function. [In other cases, like the FFT routines, there are either run-time errors or crashes.] Anyway, if it isn't too late, I think swapping the definitions would make more sense and be safer. I've gone back and forth. I agree that it would be safer, but `vector-ref' is safer still, and I think of the job of `unsafe-X' as providing the lowest possible overhead over `X'. It seems nicer to me to have `*' mean somewhere in between rather than even faster. Then again, it seems bad that `vector?' (plus index bounds) isn't enough to guard `unsafe-vector-ref'. Overall, at this point in the release cycle, I'm inclined to leave things where they are (i.e., it may be too late). But let's hear more opinions from those who use `unsafe-vector-ref' and unsafe-vector*-ref'. _ For list-related administrative
Re: [racket-dev] Release for v5.0.2 has begun
At Fri, 22 Oct 2010 21:31:43 -0600, Doug Williams wrote: Matthew, would it make more sense to have unsafe-vector-ref (and related functions) be the more general function and unsafe-vector*-ref be the one that doesn't work on chaperoned vectors? That is just swap the definitions. That way user code that is already using unsafe-vector-ref (etc) will continue to work. Ok, let's swap them --- even for 5.0.2. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release for v5.0.2 has begun
On Mon, Oct 25, 2010 at 11:28 AM, Doug Williams m.douglas.willi...@gmail.com wrote: I had always assumed that case-lambda just checked alternatives in order until one matched - like a cond. But, that was just an assumption on my part and subject to being absolutely wrong. [But, if it is correct I would expect case- to allow overlapping contracts.] That is correct. Unfortunately, it gets more complex with contracts, since each contract matches a set of arities, not just a single arity (in the function call case, you always have a specific number of arguments at the call site). So you'd have to either postpone the decision about how to compose the contracts until the callsite comes or figure out how to kind of pull the contracts apart and put them back together in sometimes a complex way. For example, say you have these contracts put together: (case- (- integer? any) (- integer? integer? integer? any) (-* () #:rest (listof boolean?) any)) then zero, two, and four-or-more all go to the last case, but figuring out that you could have written this: (case- (- any) (- integer? any) (- boolean? boolean? any) (- integer? integer? integer? any) (-* (boolean? boolean? boolean? boolean?) #:rest (listof boolean?) any)) is not so easy for us (especially since the #:rest argument is kind of hidden). Another thing I just noticed is that the documentation says that case-lambda is provided by scheme/base and scheme - and doesn't mention racket/base or racket. To me that implies that isn't available in the racket language, but I'm sure it is. Is that a documentation error? But lambda says the same thing, so I guess it is a misinterpretation on my part of what scheme versus racket means in the docs. I'm seeing racket/base and racket, not scheme/base and scheme. Either way, that seems problematic. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release for v5.0.2 has begun
At Fri, 22 Oct 2010 21:31:43 -0600, Doug Williams wrote: Matthew, would it make more sense to have unsafe-vector-ref (and related functions) be the more general function and unsafe-vector*-ref be the one that doesn't work on chaperoned vectors? That is just swap the definitions. That way user code that is already using unsafe-vector-ref (etc) will continue to work. As it stands, existing code that has unsafe-vector-ref (etc) will often still work (in the sense of not getting any error or crashing), but just gives the wrong results. For example, if you run science-test.ss from the examples directory in the science collection, there are no errors. But, some of the answers are wrong - for example the very first one, the gamma function. [In other cases, like the FFT routines, there are either run-time errors or crashes.] Anyway, if it isn't too late, I think swapping the definitions would make more sense and be safer. I've gone back and forth. I agree that it would be safer, but `vector-ref' is safer still, and I think of the job of `unsafe-X' as providing the lowest possible overhead over `X'. It seems nicer to me to have `*' mean somewhere in between rather than even faster. Then again, it seems bad that `vector?' (plus index bounds) isn't enough to guard `unsafe-vector-ref'. Overall, at this point in the release cycle, I'm inclined to leave things where they are (i.e., it may be too late). But let's hear more opinions from those who use `unsafe-vector-ref' and unsafe-vector*-ref'. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release for v5.0.2 has begun
The new case- only supports simple contracts, that's right. If you have more complex ones that it would be helpful to support (and can share them), that would help us guide our efforts. Thanks, Robby On Sun, Oct 24, 2010 at 7:04 PM, Doug Williams m.douglas.willi...@gmail.com wrote: The main problem I'm having is that the code has been around awhile and hasn't been fully converted to Racket - in particular it uses the scheme language (instead of the racket language) and uses (require (lib contract)). All of that seems to mean that I can't just add #:flat? #t - I get a message that vector-of doesn't accept keyword arguments. And, the case- contracts use -r, which apparently isn't supported anymore. All that means that I can't just switch to the racket language and new contracts. So, I have some conversion work to do. On the case- problem, it seems it no longer supports anything but -. Is there something I am missing there? Doug On Sun, Oct 24, 2010 at 8:53 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Fri, 22 Oct 2010 21:31:43 -0600, Doug Williams wrote: Matthew, would it make more sense to have unsafe-vector-ref (and related functions) be the more general function and unsafe-vector*-ref be the one that doesn't work on chaperoned vectors? That is just swap the definitions. That way user code that is already using unsafe-vector-ref (etc) will continue to work. As it stands, existing code that has unsafe-vector-ref (etc) will often still work (in the sense of not getting any error or crashing), but just gives the wrong results. For example, if you run science-test.ss from the examples directory in the science collection, there are no errors. But, some of the answers are wrong - for example the very first one, the gamma function. [In other cases, like the FFT routines, there are either run-time errors or crashes.] Anyway, if it isn't too late, I think swapping the definitions would make more sense and be safer. I've gone back and forth. I agree that it would be safer, but `vector-ref' is safer still, and I think of the job of `unsafe-X' as providing the lowest possible overhead over `X'. It seems nicer to me to have `*' mean somewhere in between rather than even faster. Then again, it seems bad that `vector?' (plus index bounds) isn't enough to guard `unsafe-vector-ref'. Overall, at this point in the release cycle, I'm inclined to leave things where they are (i.e., it may be too late). But let's hear more opinions from those who use `unsafe-vector-ref' and unsafe-vector*-ref'. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release for v5.0.2 has begun
On Oct 24, 2010, at 8:04 PM, Doug Williams wrote: On the case- problem, it seems it no longer supports anything but -. Is there something I am missing there? This is a current limitation for case- as provided by racket/contract. When I tackle the conversion of case- to proxies/chaperones, I plan on also removing this limitation if possible. If it works out, case- should work with contract values given for the clauses (and also any type of arrow contract value) instead of being limited to direct uses of the simple - combinator. Stevie _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release for v5.0.2 has begun
On Sun, Oct 24, 2010 at 7:42 PM, Stevie Strickland sstri...@ccs.neu.edu wrote: On Oct 24, 2010, at 8:04 PM, Doug Williams wrote: On the case- problem, it seems it no longer supports anything but -. Is there something I am missing there? This is a current limitation for case- as provided by racket/contract. When I tackle the conversion of case- to proxies/chaperones, I plan on also removing this limitation if possible. If it works out, case- should work with contract values given for the clauses (and also any type of arrow contract value) instead of being limited to direct uses of the simple - combinator. What would happen if I had a contract like this: (case- (- integer? integer?) (- boolean? boolean?)) Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release for v5.0.2 has begun
On Thu, Oct 21, 2010 at 1:44 PM, Doug Williams m.douglas.willi...@gmail.com wrote: Noel and Neil, were the unsafe-flround and unsafe-fllog problems you saw just with the newer nightly builds or with the released version of Racket? [I haven't had any problems with the released versions.] Nightly builds. It was flround, not unsafe-flround, that caused crashes for me. N. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release for v5.0.2 has begun
I downloaded the pre-release version this morning - 10/20 (I believe it was a build from 10/16). The plot package and plot extensions in the science collection all work as expected. But, I am getting different numeric answers for some of my science collection routines (for example, the gamma function) and some of my newer code (for example, FFT) either fails with an error message or DrRacket just dies. All of this code uses unsafe operations and the problem may lie there somewhere. I'll try digging more deeply this evening. Doug On Sat, Oct 16, 2010 at 6:53 PM, Ryan Culpepper ry...@ccs.neu.edu wrote: The release process for v5.0.2 has begun: the `release' branch was created for any work that is left and is now bumped to v5.0.1.900. You can go on using the `master' branch as usual, it is now bumped to v5.0.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 to specify that in the commit message or mail me the commit SHA1s. You can `git checkout release' to try it out directly if needed -- but do not try to push commits on it (the server will forbid it). Note that nightly builds will go on as usual (as v5.0.2.1), and pre-release builds will be available shortly at http://pre.racket-lang.org/release/ Please tell me if you think that this should be announced on the users list for wider testing. -- Ryan Culpepper _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release for v5.0.2 has begun
Are they typed? On Oct 20, 2010, at 10:39 AM, Doug Williams wrote: I downloaded the pre-release version this morning - 10/20 (I believe it was a build from 10/16). The plot package and plot extensions in the science collection all work as expected. But, I am getting different numeric answers for some of my science collection routines (for example, the gamma function) and some of my newer code (for example, FFT) either fails with an error message or DrRacket just dies. All of this code uses unsafe operations and the problem may lie there somewhere. I'll try digging more deeply this evening. Doug On Sat, Oct 16, 2010 at 6:53 PM, Ryan Culpepper ry...@ccs.neu.edu wrote: The release process for v5.0.2 has begun: the `release' branch was created for any work that is left and is now bumped to v5.0.1.900. You can go on using the `master' branch as usual, it is now bumped to v5.0.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 to specify that in the commit message or mail me the commit SHA1s. You can `git checkout release' to try it out directly if needed -- but do not try to push commits on it (the server will forbid it). Note that nightly builds will go on as usual (as v5.0.2.1), and pre-release builds will be available shortly at http://pre.racket-lang.org/release/ Please tell me if you think that this should be announced on the users list for wider testing. -- Ryan Culpepper _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release for v5.0.2 has begun
On Oct 20, 2010, at 7:39 AM, Doug Williams wrote: I downloaded the pre-release version this morning - 10/20 (I believe it was a build from 10/16). The plot package and plot extensions in the science collection all work as expected. But, I am getting different numeric answers for some of my science collection routines (for example, the gamma function) and some of my newer code (for example, FFT) either fails with an error message or DrRacket just dies. All of this code uses unsafe operations and the problem may lie there somewhere. I'll try digging more deeply this evening. Focus first on uses of unsafe-vector-ref and unsafe-vector-set!. (Not the fx and fl variants, just the plain ones). I wound up removing these from the FFT code in order to get it to work. Check out bug PR 11264. Also, very late flash of insight: my response (getting rid of unsafe-vector-ref and unsafe-vector-set!) might explain my performance issues with the FFT library. John Doug On Sat, Oct 16, 2010 at 6:53 PM, Ryan Culpepper ry...@ccs.neu.edu wrote: The release process for v5.0.2 has begun: the `release' branch was created for any work that is left and is now bumped to v5.0.1.900. You can go on using the `master' branch as usual, it is now bumped to v5.0.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 to specify that in the commit message or mail me the commit SHA1s. You can `git checkout release' to try it out directly if needed -- but do not try to push commits on it (the server will forbid it). Note that nightly builds will go on as usual (as v5.0.2.1), and pre-release builds will be available shortly at http://pre.racket-lang.org/release/ Please tell me if you think that this should be announced on the users list for wider testing. -- Ryan Culpepper _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Release for v5.0.2 has begun
The release process for v5.0.2 has begun: the `release' branch was created for any work that is left and is now bumped to v5.0.1.900. You can go on using the `master' branch as usual, it is now bumped to v5.0.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 to specify that in the commit message or mail me the commit SHA1s. You can `git checkout release' to try it out directly if needed -- but do not try to push commits on it (the server will forbid it). Note that nightly builds will go on as usual (as v5.0.2.1), and pre-release builds will be available shortly at http://pre.racket-lang.org/release/ Please tell me if you think that this should be announced on the users list for wider testing. -- Ryan Culpepper _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
