I've now pushed what should be a fix for the bug. It is a fix for this
small example, and so hopefully a fix for your later model too.
#lang racket
(require redex/reduction-semantics)
(define-language L
(cap-x (side-condition
variable_1
(regexp-match #rx"^[A-Z]" (symbol->string (term variable_1))))))
(redex-check
L
cap-x
#t
#:attempts 10)
On Wed, Mar 26, 2014 at 11:29 PM, Stephen Chang <stch...@ccs.neu.edu> wrote:
> Sorry, just to clarify, the use of the #:ad-hoc keyword is a
> workaround and is not intended to break backwards incompatibility,
> right?
>
> On Wed, Mar 26, 2014 at 7:55 PM, Robby Findler
> <ro...@eecs.northwestern.edu> wrote:
> > That is a bug in redex-check. You can work around it by passing #:ad-hoc
> to
> > redex-check (this goes back to the old behavior).
> >
> > Robby
> >
> >
> > On Wed, Mar 26, 2014 at 6:33 PM, Stephen Chang <stch...@ccs.neu.edu>
> wrote:
> >>
> >> Not sure if this is related, but if I have a call to redex-check that
> >> is suddenly producing the error:
> >>
> >> generate-term: #:i-th does not support "side-condition" patterns
> >>
> >> What are some possible causes? (still trying to distill to a small
> >> example).
> >>
> >> On Wed, Mar 26, 2014 at 1:10 PM, Robby Findler
> >> <ro...@eecs.northwestern.edu> wrote:
> >> > Just to confirm: Redex isn't doing anything wrong, right?
> >> >
> >> > Redex is now using the in-order enumeration generation in a default
> >> > configuration (for a little while before adding some of the old-style
> >> > random
> >> > generated terms).
> >> >
> >> > So if you want to see what kinds of things it generates, you can use
> >> > generate-term with the #:i-th argument.
> >> >
> >> > Robby
> >> >
> >> >
> >> >
> >> > On Wed, Mar 26, 2014 at 12:03 PM, Eric Dobson <
> eric.n.dob...@gmail.com>
> >> > wrote:
> >> >>
> >> >> Looks like what is actually happening is that redex is actually
> >> >> generating reals for this program now.
> >> >>
> >> >> #lang racket
> >> >>
> >> >> (require redex/reduction-semantics)
> >> >> (define-language tr-arith
> >> >> [n real])
> >> >>
> >> >> (redex-check tr-arith n #t
> >> >> #:prepare (lambda (x) (displayln x) x))
> >> >>
> >> >> Before we were only getting small integers.
> >> >>
> >> >> On Wed, Mar 26, 2014 at 9:46 AM, Eric Dobson <
> eric.n.dob...@gmail.com>
> >> >> wrote:
> >> >> > This push has started breaking the random TR tests. I think the
> issue
> >> >> > is that TR assumed that redex wouldn't generate so large numbers
> that
> >> >> > it exceeded the flonum range. Could that have changed in this
> commit?
> >> >> > Or changed so that were generated earlier in random testing? If so
> >> >> > the
> >> >> > issue is definitely on the TR side, but just want to confirm that
> the
> >> >> > theory is likely.
> >> >> >
> >> >> > On Wed, Mar 26, 2014 at 4:58 AM, <d...@racket-lang.org> wrote:
> >> >> >> DrDr has finished building push #28413 after 1.20h.
> >> >> >>
> >> >> >> http://drdr.racket-lang.org/28413/
> >> >> >>
> >> >> >> A file you are responsible for has a condition that may need
> >> >> >> inspecting.
> >> >> >> stderr:
> >> >> >>
> >> >> >>
> >> >> >>
> http://drdr.racket-lang.org/28413/pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/tr-random-testing.rkt
> >> >> >>
> >> >> >> unclean:
> >> >> >>
> >> >> >>
> >> >> >>
> http://drdr.racket-lang.org/28413/pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/tr-random-testing.rkt
> >> >> >>
> >> >> >>
> >> >
> >> >
> >> >
> >> > _________________________
> >> > Racket Developers list:
> >> > http://lists.racket-lang.org/dev
> >> >
> >
> >
>
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
