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 <[email protected]> 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: >> >> 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 >> >> On Thu, Apr 7, 2016 at 10:46 AM, Vincent St-Amour >> <[email protected]> wrote: >> >> 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.}} >> >> -- >> 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 [email protected]. >> To post to this group, send email to [email protected]. >> 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. >> >> >> -- >> 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 [email protected]. >> To post to this group, send email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/racket-dev/CACvwowXDERG9z5AHo%3DTamZDQWVJZXt6HvJvD%3D6kAf-F3WyDZKg%40mail.gmail.com. >> For more options, visit https://groups.google.com/d/optout. > > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-dev/m2zisqznqt.wl-stamourv%40eecs.northwestern.edu. > For more options, visit https://groups.google.com/d/optout. -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/CAK%3DHD%2BZb2BJjbBHfkD_w1T60dnwwzZkd2LSw69FfnQ0k924iXg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
