Re: [racket-dev] Release for v5.0.2 has begun
On Mon, Oct 25, 2010 at 11:28 AM, Doug Williams 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. 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
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.] 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. Doug On Mon, Oct 25, 2010 at 8:46 AM, Robby Findler wrote: > 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 > 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 > >> 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 > >> > 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
Re: [racket-dev] Release for v5.0.2 has begun
But that does hide the intent of the case-lambda usage, which is captured in the original. On Mon, Oct 25, 2010 at 8:21 AM, Sam Tobin-Hochstadt wrote: > On Mon, Oct 25, 2010 at 10:06 AM, Doug Williams > 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
On Oct 24, 2010, at 10:10 PM, Robby Findler wrote: > What would happen if I had a contract like this: > > (case-> (-> integer? integer?) (-> boolean? boolean?)) One of two things: a) You'd get an error for having overlapping arities in your contracts. This is the most likely to be implemented, at least at first, since I believe that's what current case-> does, right? I'd do a quick spot check, but I'm rebuilding Racket at the moment. b) You'd filter the contracts by arity, and then at the overlaps, you'd have to resort to first-order checks on the arguments to decide which argument/result contracts to apply. With the above contract, that would disambiguate, but obviously there could be overlaps even after first-order checks (structs with prop:procedure, for example). Stevie _ 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 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 > 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 >> 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 >> > 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 ar
Re: [racket-dev] Release for v5.0.2 has begun
On Mon, Oct 25, 2010 at 10:06 AM, Doug Williams 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
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 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 > 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 > 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 Sun, Oct 24, 2010 at 7:42 PM, Stevie Strickland 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 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
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 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 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
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 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
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
With the #:flat? keyword on the contracts and unsafe-vector-ref, etc, I get the following run times: cpu time: 94 real time: 94 gc time: 0 cpu time: 63 real time: 63 gc time: 0 #t This is essentially the same run times as the 5.0.1 values. Doug On Sat, Oct 23, 2010 at 4:26 PM, Doug Williams wrote: > John, > > In the FFT with unsafe-vector*-ref, etc substituted for unsafe-vector-ref, > etc, the run times are up to 100% greater. There may be places I can revert > to the unsafe-vector-ref, etc versions, but it would require an analysis of > the code that I don't have the time to do at the moment. I guess another > alternative is to keep the old behavior using the #:flat keyword on the > contracts. Using your test, I had the following on my laptop on 5.0.1 > > > cpu time: 94 real time: 94 gc time: 0 > > cpu time: 79 real time: 78 gc time: 0 > > #t > > On 5.0.1.900 I get the following run times: > > cpu time: 203 real time: 203 gc time: 0 > cpu time: 94 real time: 94 gc time: 0 > #t > > I see similar results on my other tests > > I'll see what I get with the #:flat keyword next. > > Doug > > > On Fri, Oct 22, 2010 at 9:31 PM, Doug Williams < > m.douglas.willi...@gmail.com> 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. >> >> Doug >> >> On Wed, Oct 20, 2010 at 8:56 AM, Matthew Flatt wrote: >> >>> At Wed, 20 Oct 2010 07:48:20 -0700, John Clements wrote: >>> > >>> > 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. >>> >>> Overall, keep in mind that changes to vector contracts mean that >>> vectors can be wrapped with chaperones. That's why `unsafe-vector-ref' >>> may need to change to `unsafe-vector*-ref', and it may explain >>> performance differences in general. >>> >>> >> > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release for v5.0.2 has begun
John, In the FFT with unsafe-vector*-ref, etc substituted for unsafe-vector-ref, etc, the run times are up to 100% greater. There may be places I can revert to the unsafe-vector-ref, etc versions, but it would require an analysis of the code that I don't have the time to do at the moment. I guess another alternative is to keep the old behavior using the #:flat keyword on the contracts. Using your test, I had the following on my laptop on 5.0.1 > cpu time: 94 real time: 94 gc time: 0 > cpu time: 79 real time: 78 gc time: 0 > #t On 5.0.1.900 I get the following run times: cpu time: 203 real time: 203 gc time: 0 cpu time: 94 real time: 94 gc time: 0 #t I see similar results on my other tests I'll see what I get with the #:flat keyword next. Doug On Fri, Oct 22, 2010 at 9:31 PM, 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. > > Doug > > On Wed, Oct 20, 2010 at 8:56 AM, Matthew Flatt wrote: > >> At Wed, 20 Oct 2010 07:48:20 -0700, John Clements wrote: >> > >> > 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. >> >> Overall, keep in mind that changes to vector contracts mean that >> vectors can be wrapped with chaperones. That's why `unsafe-vector-ref' >> may need to change to `unsafe-vector*-ref', and it may explain >> performance differences in general. >> >> > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release for v5.0.2 has begun
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. Doug On Wed, Oct 20, 2010 at 8:56 AM, Matthew Flatt wrote: > At Wed, 20 Oct 2010 07:48:20 -0700, John Clements wrote: > > > > 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. > > Overall, keep in mind that changes to vector contracts mean that > vectors can be wrapped with chaperones. That's why `unsafe-vector-ref' > may need to change to `unsafe-vector*-ref', and it may explain > performance differences in general. > > _ 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 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 am definitely using unsafe-vector-ref (and -set!) - a lot - with contracted vectors. So, that is at least part of my problem. And, the newer code uses many of the newer unsafe operations (like unsafe-fllog). This weekend I will change all of the vector references and see how everything runs with the pre-release version 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.] Doug On Wed, Oct 20, 2010 at 5:55 PM, Neil Toronto wrote: > Noel Welsh wrote: > >> On Wed, Oct 20, 2010 at 3:39 PM, 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. >>> >> >> There is a crash inducing bug in some uses of flround (at least, last >> time I tried it). I haven't previously reported it as I haven't had >> the time to narrow down the situation that causes it. My DCT package >> on Github triggers it. >> > > I've had unsafe-fllog crash DrRacket a few times. The symptoms are always > consistent for me, but the bug fixers (Vincent and Matthew in this case) > haven't been able to duplicate them. It's very context-sensitive (e.g. it > depends whether printf and/or parameters are used nearby, and whether the > unsafe-fllog comes from TR's optimizer), so it was very hard to narrow down > in the first place. > > I'm thinking this is all the same thing, and JIT-related. (Except maybe > Doug's is caused by chaperones.) > > Neil T > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release for v5.0.2 has begun
Noel Welsh wrote: On Wed, Oct 20, 2010 at 3:39 PM, 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. There is a crash inducing bug in some uses of flround (at least, last time I tried it). I haven't previously reported it as I haven't had the time to narrow down the situation that causes it. My DCT package on Github triggers it. I've had unsafe-fllog crash DrRacket a few times. The symptoms are always consistent for me, but the bug fixers (Vincent and Matthew in this case) haven't been able to duplicate them. It's very context-sensitive (e.g. it depends whether printf and/or parameters are used nearby, and whether the unsafe-fllog comes from TR's optimizer), so it was very hard to narrow down in the first place. I'm thinking this is all the same thing, and JIT-related. (Except maybe Doug's is caused by chaperones.) Neil T _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release for v5.0.2 has begun
At Wed, 20 Oct 2010 11:36:58 -0600, Doug Williams wrote: > I'm not sure I understand what you're saying Matthew. > > On Wed, Oct 20, 2010 at 8:56 AM, Matthew Flatt wrote: > > Overall, keep in mind that changes to vector contracts mean that > > vectors can be wrapped with chaperones. That's why `unsafe-vector-ref' > > may need to change to `unsafe-vector*-ref', and it may explain > > performance differences in general. Contracted vectors are now wrapped in chaperones. unsafe-vector-ref works only on raw vectors, not on chaperoned vectors. Therefore, if you use unsafe-vector-ref on a contracted vector, bad things happen. unsafe-vector*-ref and other procedures have been introduced to work on both plain vectors and chaperoned vectors. Since they have to check for chaperones, they're a bit slower than unsafe-vector-ref, but they're still faster than plain vector-ref. Vincent _ 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 10:31 AM, Doug Williams wrote: > John, was that to get them to work with a nightly (or pre-release) build or > with the released version of Racket? I've not had any problems running them > on the released version. But, I haven't exercised them to the extent that you > have. Pre-release. John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release for v5.0.2 has begun
On Wed, Oct 20, 2010 at 3:39 PM, 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. There is a crash inducing bug in some uses of flround (at least, last time I tried it). I haven't previously reported it as I haven't had the time to narrow down the situation that causes it. My DCT package on Github triggers it. HTH, N. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release for v5.0.2 has begun
I'm not sure I understand what you're saying Matthew. On Wed, Oct 20, 2010 at 8:56 AM, Matthew Flatt wrote: > At Wed, 20 Oct 2010 07:48:20 -0700, John Clements wrote: > > > > 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. > > Overall, keep in mind that changes to vector contracts mean that > vectors can be wrapped with chaperones. That's why `unsafe-vector-ref' > may need to change to `unsafe-vector*-ref', and it may explain > performance differences in general. > > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release for v5.0.2 has begun
John, was that to get them to work with a nightly (or pre-release) build or with the released version of Racket? I've not had any problems running them on the released version. But, I haven't exercised them to the extent that you have. On Wed, Oct 20, 2010 at 8:48 AM, John Clements wrote: > > 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 > 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
None of these are typed. On Wed, Oct 20, 2010 at 8:43 AM, Matthias Felleisen wrote: > > 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 > 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
I'll see if I can reproduce the problem with the typed version. At Wed, 20 Oct 2010 07:48:20 -0700, John Clements wrote: > 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. I doubt so. While porting this code to Typed Racket, I measured the effect of the different classes of unsafe operations on it, and unsafe vector operations had no noticeable effect. Vincent _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release for v5.0.2 has begun
At Wed, 20 Oct 2010 07:48:20 -0700, John Clements wrote: > > 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. Overall, keep in mind that changes to vector contracts mean that vectors can be wrapped with chaperones. That's why `unsafe-vector-ref' may need to change to `unsafe-vector*-ref', and it may explain performance differences in general. _ 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 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
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 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
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 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
[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
