Yes that fixed it. Thanks!
On Thu, Mar 27, 2014 at 12:54 AM, Robby Findler
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
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->str
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
wrote:
> That is a bug in redex-check. You can work around it by passing #:ad-hoc to
> redex-check (this goes back
> 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).
Thanks! That saved me some debugging.
>
> Robby
>
>
> On Wed, Mar 26, 2014 at 6:33 PM, Stephen Chang wrote:
>>
>> Not sure if this is related, but if I have a call t
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 wrote:
> Not sure if this is related, but if I have a call to redex-check that
> is suddenly producing the error:
>
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
Right. I'll fix the TR random tester.
Vincent
At Wed, 26 Mar 2014 13:25:42 -0400,
Sam Tobin-Hochstadt wrote:
>
> On Wed, Mar 26, 2014 at 1:10 PM, Robby Findler
> wrote:
> > Just to confirm: Redex isn't doing anything wrong, right?
>
> Correct -- I think `real` was always allowed to generate s
On Wed, Mar 26, 2014 at 1:10 PM, Robby Findler
wrote:
> Just to confirm: Redex isn't doing anything wrong, right?
Correct -- I think `real` was always allowed to generate such numbers,
but it didn't before.
Sam
>
> Redex is now using the in-order enumeration generation in a default
> configurat
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
generat
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 i
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 definitel
11 matches
Mail list logo
