Yes that fixed it. Thanks!
On Thu, Mar 27, 2014 at 12:54 AM, Robby Findler <ro...@eecs.northwestern.edu> wrote: > 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
