Release for v6.5 has begun
56 views
Skip to first unread message
Vincent St-Amour
Apr 7, 2016, 12:47:19 PM4/7/16
to d...@racket-lang.org
The release process for v6.5 has begun: the `release' branch was
created for any work that is left and is now bumped to v6.4.90.900. You
can go on using the `master' branch as usual, it is now bumped to
v6.5.0.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).
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 `release' branch creation and the actual
release is for fixing new errors that prevent proper functioning of
major components and that show up during the preparation for a
release. You can also finalize piece of work that is not yet
complete, but please avoid merging new features.
Note that nightly builds will go on as usual (starting from
v6.5.0.1 and going up as usual), and pre-release builds will be
available shortly at
http://pre-release.racket-lang.org/
Please tell me if you think that this release is significant enough
that it should be announced on the users list for wider testing.}}
created for any work that is left and is now bumped to v6.4.90.900. You
can go on using the `master' branch as usual, it is now bumped to
v6.5.0.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).
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 `release' branch creation and the actual
release is for fixing new errors that prevent proper functioning of
major components and that show up during the preparation for a
release. You can also finalize piece of work that is not yet
complete, but please avoid merging new features.
Note that nightly builds will go on as usual (starting from
v6.5.0.1 and going up as usual), and pre-release builds will be
available shortly at
http://pre-release.racket-lang.org/
Please tell me if you think that this release is significant enough
that it should be announced on the users list for wider testing.}}
Doug Williams
Apr 15, 2016, 10:40:25 PM4/15/16
to Vincent St-Amour, d...@racket-lang.org
I tested the plot package that I normally test and it works fine. But, I still have a problem that I first noticed in 6.4 - but may have been introduced slightly earlier. For me it manifests as a problem with the interaction between typed Racket code, bigfloat? in math/bigfloat, and some higher-order values passed as 'Any' in untyped code, mcons in racket/mpair. This is Racket bug #15274.
My describe package dispatches on the type of an argument to be described. As noted above, it include descriptions of, among many other things, bigfloats and mutable lists. But, the dispatch code fails because of the above error. The easiest fix is just to not include any typed Racket types, but that is more extreme than I would like. I could move all of the tests for types from typed Racket to the end (which may currently be just bigfloat), but types that I don't currently test for may still hit the same error.
Is there a simple fix for predicates like bigfloat? in the typed code to not use Any as a type? Or some other recommendation?
Doug
--
You received this message because you are subscribed to the Google Groups "Racket Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+...@googlegroups.com.
To post to this group, send email to racke...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/m2inzt5ptp.wl-stamourv%40eecs.northwestern.edu.
For more options, visit https://groups.google.com/d/optout.
Vincent St-Amour
Apr 18, 2016, 4:05:34 PM4/18/16
to Doug Williams, Vincent St-Amour, d...@racket-lang.org
As far as the release is concerned, I don't think there's anything we
can do about this problem at this stage. Since that regression was
already present in 6.4, I don't think it's urgent to put a fix in 6.5.
As far as workarounds to use with 6.4/6.5, maybe Sam has some ideas.
Vincent
> https://groups.google.com/d/msgid/racket-dev/CACvwowXDERG9z5AHo%3DTamZDQWVJZXt6HvJvD%3D6kAf-F3WyDZKg%40mail.gmail.com.
can do about this problem at this stage. Since that regression was
already present in 6.4, I don't think it's urgent to put a fix in 6.5.
As far as workarounds to use with 6.4/6.5, maybe Sam has some ideas.
Vincent
Sam Tobin-Hochstadt
Apr 18, 2016, 5:09:43 PM4/18/16
to Vincent St-Amour, Doug Williams, d...@racket-lang.org
Unfortunately, there's not a good workaround to suggest here.
What's happening is that `bigfloat?` is the `mpfr?` predicate defined
by `define-cstruct` in `mpfr.rkt`. This is an untyped Racket file,
which takes an arbitrary value, and is given the type `(-> Any
Boolean)` in TR by `bigfloat-mpfr.rkt` (using the `opaque`)
declaration. This means that TR doesn't have any way to know what kind
of contract to put on `bigfloat?`, so it puts on a contract that
allows any immutable value, but has to prevent any changes or reads
from mutable locations. For most mutable values, that means a
chaperone, but there are no chaperones for `mcons`. Also, for most
struct predicates such a restrictive check isn't needed, but
`define-cstruct` predicates aren't marked as being struct predicates
as those defined with `struct` are.
Long-term, we can tag cstruct predicates specially, and we can
potentially add mpair chaperones. I'm not sure how much work either of
those will require.
Sam
On Mon, Apr 18, 2016 at 4:05 PM, Vincent St-Amour
<stam...@eecs.northwestern.edu> wrote:
> As far as the release is concerned, I don't think there's anything we
> can do about this problem at this stage. Since that regression was
> already present in 6.4, I don't think it's urgent to put a fix in 6.5.
>
> As far as workarounds to use with 6.4/6.5, maybe Sam has some ideas.
>
> Vincent
>
>
>
> On Fri, 15 Apr 2016 21:40:24 -0500,
> Doug Williams wrote:
>>
>> https://groups.google.com/d/msgid/racket-dev/CACvwowXDERG9z5AHo%3DTamZDQWVJZXt6HvJvD%3D6kAf-F3WyDZKg%40mail.gmail.com.
What's happening is that `bigfloat?` is the `mpfr?` predicate defined
by `define-cstruct` in `mpfr.rkt`. This is an untyped Racket file,
which takes an arbitrary value, and is given the type `(-> Any
Boolean)` in TR by `bigfloat-mpfr.rkt` (using the `opaque`)
declaration. This means that TR doesn't have any way to know what kind
of contract to put on `bigfloat?`, so it puts on a contract that
allows any immutable value, but has to prevent any changes or reads
from mutable locations. For most mutable values, that means a
chaperone, but there are no chaperones for `mcons`. Also, for most
struct predicates such a restrictive check isn't needed, but
`define-cstruct` predicates aren't marked as being struct predicates
as those defined with `struct` are.
Long-term, we can tag cstruct predicates specially, and we can
potentially add mpair chaperones. I'm not sure how much work either of
those will require.
Sam
On Mon, Apr 18, 2016 at 4:05 PM, Vincent St-Amour
<stam...@eecs.northwestern.edu> wrote:
> As far as the release is concerned, I don't think there's anything we
> can do about this problem at this stage. Since that regression was
> already present in 6.4, I don't think it's urgent to put a fix in 6.5.
>
> As far as workarounds to use with 6.4/6.5, maybe Sam has some ideas.
>
> Vincent
>
>
>
> On Fri, 15 Apr 2016 21:40:24 -0500,
> Doug Williams wrote:
>>
> --
> You received this message because you are subscribed to the Google Groups "Racket Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+...@googlegroups.com.
> To post to this group, send email to racke...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/m2zisqznqt.wl-stamourv%40eecs.northwestern.edu.
> You received this message because you are subscribed to the Google Groups "Racket Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+...@googlegroups.com.
> To post to this group, send email to racke...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages