[racket-dev] [DrDr] R28413 (timeout 4) (unclean 16) (stderr 35) (changes 22)

From: Robby Findler (robby at eecs.northwestern.edu)
Date: Thu Mar 27 00:54:42 EDT 2014

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 <stchang at 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
> <robby at 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 <stchang at 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
> >> <robby at 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.dobson at 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.dobson at 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,  <drdr at 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
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20140326/ee5a1db6/attachment.html>

Posted on the dev mailing list.