Re: [racket-dev] check-match?

[Joe Gibbs Politz]

I think I've successfully sent a thingie to you:

https://github.com/plt/racket/pull/171

Let me know if I Did It Wrong.  This is the first time I've clicked
the "Pull Request" button on Github.

On Mon, Nov 19, 2012 at 10:12 PM, Joe Gibbs Politz  wrote:
> Gotcha.  match-pred can be a separate thing.
>
> check-match can also let you use the identifiers bound in the match with an
> optional third argument, which relies on more than match-pred anyway.
> That's what I'm doing.
>
>
> On Mon, Nov 19, 2012 at 9:30 PM, Robby Findler 
> wrote:
>>
>> I think it is better to have a check-match since that way people are
>> more likely to find it.
>>
>> Robby
>>
>> On Mon, Nov 19, 2012 at 7:56 PM, Joe Gibbs Politz 
>> wrote:
>> >>  (? P) => (lambda (x) (match x [P true] [_ false]))
>> >
>> > I like this quite a bit.  It wouldn't be crazy to add it as
>> > match-pred(icate) right next to match-lambda, match-let, and friends
>> >
>> > (http://docs.racket-lang.org/reference/match.html?q=match&q=match-pred#(form._((lib._racket/match..rkt)._match-lambda))).
>> >
>> > Then, for rackunit, it's just up to how much we like writing
>> >
>> > (check-match foo P)
>> >
>> > vs.
>> >
>> > (check-pred (match-pred P) foo)
>> >
>> > Both seem handy to me.
>> >
>> > _
>> >   Racket Developers list:
>> >   http://lists.racket-lang.org/dev
>> >
>
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] check-match?

[Joe Gibbs Politz]

Gotcha.  match-pred can be a separate thing.

check-match can also let you use the identifiers bound in the match with an
optional third argument, which relies on more than match-pred anyway.
 That's what I'm doing.


On Mon, Nov 19, 2012 at 9:30 PM, Robby Findler
wrote:

> I think it is better to have a check-match since that way people are
> more likely to find it.
>
> Robby
>
> On Mon, Nov 19, 2012 at 7:56 PM, Joe Gibbs Politz 
> wrote:
> >>  (? P) => (lambda (x) (match x [P true] [_ false]))
> >
> > I like this quite a bit.  It wouldn't be crazy to add it as
> > match-pred(icate) right next to match-lambda, match-let, and friends
> > (
> http://docs.racket-lang.org/reference/match.html?q=match&q=match-pred#(form._((lib._racket/match..rkt)._match-lambda))
> ).
> >
> > Then, for rackunit, it's just up to how much we like writing
> >
> > (check-match foo P)
> >
> > vs.
> >
> > (check-pred (match-pred P) foo)
> >
> > Both seem handy to me.
> >
> > _
> >   Racket Developers list:
> >   http://lists.racket-lang.org/dev
> >
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] check-match?

[Robby Findler]

I think it is better to have a check-match since that way people are
more likely to find it.

Robby

On Mon, Nov 19, 2012 at 7:56 PM, Joe Gibbs Politz  wrote:
>>  (? P) => (lambda (x) (match x [P true] [_ false]))
>
> I like this quite a bit.  It wouldn't be crazy to add it as
> match-pred(icate) right next to match-lambda, match-let, and friends
> (http://docs.racket-lang.org/reference/match.html?q=match&q=match-pred#(form._((lib._racket/match..rkt)._match-lambda))).
>
> Then, for rackunit, it's just up to how much we like writing
>
> (check-match foo P)
>
> vs.
>
> (check-pred (match-pred P) foo)
>
> Both seem handy to me.
>
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] check-match?

[Joe Gibbs Politz]

>  (? P) => (lambda (x) (match x [P true] [_ false]))

I like this quite a bit.  It wouldn't be crazy to add it as
match-pred(icate) right next to match-lambda, match-let, and friends (
http://docs.racket-lang.org/reference/match.html?q=match&q=match-pred#(form._((lib._racket/match..rkt)._match-lambda))
).

Then, for rackunit, it's just up to how much we like writing

(check-match foo P)

vs.

(check-pred (match-pred P) foo)

Both seem handy to me.
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] check-match?

[Robby Findler]

rackunit has check-pred, of course.

Robby

On Mon, Nov 19, 2012 at 7:31 PM, Shriram Krishnamurthi  
wrote:
> Predicates in general would be really awesome.  I think the testing
> infrastructure for Sperber's book (DMDA) has something like this.
>
> Making it lightweight is what matters most, whether through a new
> match form or a more general predicate form.
>
> Shriram
>
> On Mon, Nov 19, 2012 at 8:25 PM, David Van Horn  wrote:
>> On 11/19/12 8:20 PM, Joe Gibbs Politz wrote:
>>>
>>>  > Yeah, that is very nice! (It should begin with "check" not "test"
>>> tho, right?)
>>>
>>> Indeed; Jonah was writing w.r.t plai, which uses test.  Should use
>>> check- in rackunit.
>>>
>>> I noticed that this also violates, from the rackunit docs:
>>>
>>> "Although checks are implemented as macros, which is necessary to grab
>>> source location, they are conceptually functions. This means, for
>>> instance, checks always evaluate their arguments."
>>>
>>> I suppose this should go in a separate section of "additional checks" or
>>> some such?
>>
>>
>> Maybe the right thing to do is make it lightweight to write predicates with
>> match so that you don't even need a separate testing form?
>>
>> Something like (? P) => (lambda (x) (match x [P true] [_ false]))
>>
>> David
>>
>>
>>
>> _
>>  Racket Developers list:
>>  http://lists.racket-lang.org/dev
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] check-match?

[Robby Findler]

That might be nice, but a form for including a match pattern seems
like something that would be really great to have.

Robby

On Mon, Nov 19, 2012 at 7:25 PM, David Van Horn  wrote:
> On 11/19/12 8:20 PM, Joe Gibbs Politz wrote:
>>
>>  > Yeah, that is very nice! (It should begin with "check" not "test"
>> tho, right?)
>>
>> Indeed; Jonah was writing w.r.t plai, which uses test.  Should use
>> check- in rackunit.
>>
>> I noticed that this also violates, from the rackunit docs:
>>
>> "Although checks are implemented as macros, which is necessary to grab
>> source location, they are conceptually functions. This means, for
>> instance, checks always evaluate their arguments."
>>
>> I suppose this should go in a separate section of "additional checks" or
>> some such?
>
>
> Maybe the right thing to do is make it lightweight to write predicates with
> match so that you don't even need a separate testing form?
>
> Something like (? P) => (lambda (x) (match x [P true] [_ false]))
>
> David
>
>
>
> _
>  Racket Developers list:
>  http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] check-match?

[Shriram Krishnamurthi]

Predicates in general would be really awesome.  I think the testing
infrastructure for Sperber's book (DMDA) has something like this.

Making it lightweight is what matters most, whether through a new
match form or a more general predicate form.

Shriram

On Mon, Nov 19, 2012 at 8:25 PM, David Van Horn  wrote:
> On 11/19/12 8:20 PM, Joe Gibbs Politz wrote:
>>
>>  > Yeah, that is very nice! (It should begin with "check" not "test"
>> tho, right?)
>>
>> Indeed; Jonah was writing w.r.t plai, which uses test.  Should use
>> check- in rackunit.
>>
>> I noticed that this also violates, from the rackunit docs:
>>
>> "Although checks are implemented as macros, which is necessary to grab
>> source location, they are conceptually functions. This means, for
>> instance, checks always evaluate their arguments."
>>
>> I suppose this should go in a separate section of "additional checks" or
>> some such?
>
>
> Maybe the right thing to do is make it lightweight to write predicates with
> match so that you don't even need a separate testing form?
>
> Something like (? P) => (lambda (x) (match x [P true] [_ false]))
>
> David
>
>
>
> _
>  Racket Developers list:
>  http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] check-match?

[Robby Findler]

I think you should just stick "(except @racket[check-],
since its first/second argument is a match pattern)" or something like
that into the docs in your pull request.

Also test cases: I think there is a test suite for rackunit somewhere;
let me know if you have trouble with it and I can add tests.

Robby

On Mon, Nov 19, 2012 at 7:20 PM, Joe Gibbs Politz  wrote:
>> Yeah, that is very nice! (It should begin with "check" not "test" tho,
>> right?)
>
> Indeed; Jonah was writing w.r.t plai, which uses test.  Should use check- in
> rackunit.
>
> I noticed that this also violates, from the rackunit docs:
>
> "Although checks are implemented as macros, which is necessary to grab
> source location, they are conceptually functions. This means, for instance,
> checks always evaluate their arguments."
>
> I suppose this should go in a separate section of "additional checks" or
> some such?
>
>
> On Mon, Nov 19, 2012 at 8:01 PM, Robby Findler 
> wrote:
>>
>> Yeah, that is very nice! (It should begin with "check" not "test" tho,
>> right?)
>>
>> Robby
>>
>>
>> On Monday, November 19, 2012, Matthias Felleisen wrote:
>>>
>>>
>>> That is cute. Why don't you just create a pull request and Ryan can
>>> integrate it into rackunit? -- Matthias
>>>
>>>
>>>
>>>
>>>
>>> On Nov 19, 2012, at 4:22 PM, Joe Gibbs Politz wrote:
>>>
>>> > A small suggestion:
>>> >
>>> > I used roughly this macro (credit Jonah Kagan) recently to help me
>>> > write some tests for parsing code that agnostic to which source position 
>>> > is
>>> > generated in the parse:
>>> >
>>> > (define-syntax test/match
>>> >   (syntax-rules ()
>>> > [(test/match actual expected pred)
>>> >  (let ([actual-val actual])
>>> >(with-check-info* (list (make-check-actual actual-val)
>>> >(make-check-expected 'expected))
>>> >  (thunk (check-true (match actual-val
>>> > [expected pred]
>>> > [_ false])]
>>> >
>>> > [(test/match actual expected)
>>> >  (test/match actual expected true)]))
>>> >
>>> > Shriram remarked that he was surprised some sort of check-match wasn't
>>> > in rackunit already.  Is it worth adding something like this?
>>> >
>>> > I'm doing things like:
>>> >
>>> > (test/match (parse "5 'foo'") (s-block _ (list (s-num _ 5) (s-str _
>>> > "foo"
>>> >
>>> > Where the structs s-block, s-num, and s-str all expect a srcloc as
>>> > their first argument, but I don't care about it for these tests.
>>> >
>>> > The actual use is at:
>>> >
>>> >
>>> > https://github.com/brownplt/pyret-lang/blob/master/src/tests/parse-tests.rkt#L36
>>> >
>>> > That file would be much, much uglier without this macro.
>>> >
>>> > Cheers,
>>> > Joe P.
>>> >
>>> > _
>>> >  Racket Developers list:
>>> >  http://lists.racket-lang.org/dev
>>>
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] check-match?

[David Van Horn]

On 11/19/12 8:20 PM, Joe Gibbs Politz wrote:

 > Yeah, that is very nice! (It should begin with "check" not "test"
tho, right?)

Indeed; Jonah was writing w.r.t plai, which uses test.  Should use
check- in rackunit.

I noticed that this also violates, from the rackunit docs:

"Although checks are implemented as macros, which is necessary to grab
source location, they are conceptually functions. This means, for
instance, checks always evaluate their arguments."

I suppose this should go in a separate section of "additional checks" or
some such?


Maybe the right thing to do is make it lightweight to write predicates 
with match so that you don't even need a separate testing form?


Something like (? P) => (lambda (x) (match x [P true] [_ false]))

David


_
 Racket Developers list:
 http://lists.racket-lang.org/dev

Re: [racket-dev] check-match?

[Joe Gibbs Politz]

> Yeah, that is very nice! (It should begin with "check" not "test" tho,
right?)

Indeed; Jonah was writing w.r.t plai, which uses test.  Should use check-
in rackunit.

I noticed that this also violates, from the rackunit docs:

"Although checks are implemented as macros, which is necessary to grab
source location, they are conceptually functions. This means, for instance,
checks always evaluate their arguments."

I suppose this should go in a separate section of "additional checks" or
some such?


On Mon, Nov 19, 2012 at 8:01 PM, Robby Findler
wrote:

> Yeah, that is very nice! (It should begin with "check" not "test" tho,
> right?)
>
> Robby
>
>
> On Monday, November 19, 2012, Matthias Felleisen wrote:
>
>>
>> That is cute. Why don't you just create a pull request and Ryan can
>> integrate it into rackunit? -- Matthias
>>
>>
>>
>>
>>
>> On Nov 19, 2012, at 4:22 PM, Joe Gibbs Politz wrote:
>>
>> > A small suggestion:
>> >
>> > I used roughly this macro (credit Jonah Kagan) recently to help me
>> write some tests for parsing code that agnostic to which source position is
>> generated in the parse:
>> >
>> > (define-syntax test/match
>> >   (syntax-rules ()
>> > [(test/match actual expected pred)
>> >  (let ([actual-val actual])
>> >(with-check-info* (list (make-check-actual actual-val)
>> >(make-check-expected 'expected))
>> >  (thunk (check-true (match actual-val
>> > [expected pred]
>> > [_ false])]
>> >
>> > [(test/match actual expected)
>> >  (test/match actual expected true)]))
>> >
>> > Shriram remarked that he was surprised some sort of check-match wasn't
>> in rackunit already.  Is it worth adding something like this?
>> >
>> > I'm doing things like:
>> >
>> > (test/match (parse "5 'foo'") (s-block _ (list (s-num _ 5) (s-str _
>> "foo"
>> >
>> > Where the structs s-block, s-num, and s-str all expect a srcloc as
>> their first argument, but I don't care about it for these tests.
>> >
>> > The actual use is at:
>> >
>> >
>> https://github.com/brownplt/pyret-lang/blob/master/src/tests/parse-tests.rkt#L36
>> >
>> > That file would be much, much uglier without this macro.
>> >
>> > Cheers,
>> > Joe P.
>> >
>> > _
>> >  Racket Developers list:
>> >  http://lists.racket-lang.org/dev
>>
>>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] check-match?

[Shriram Krishnamurthi]

We use test in PLAI, and I suggested it in that context (eg,
unification, where you don't care about the gensym'ed names of logic
variables), which is probably why it got called that.

On Mon, Nov 19, 2012 at 8:01 PM, Robby Findler
 wrote:
> Yeah, that is very nice! (It should begin with "check" not "test" tho,
> right?)
>
> Robby
>
>
> On Monday, November 19, 2012, Matthias Felleisen wrote:
>>
>>
>> That is cute. Why don't you just create a pull request and Ryan can
>> integrate it into rackunit? -- Matthias
>>
>>
>>
>>
>>
>> On Nov 19, 2012, at 4:22 PM, Joe Gibbs Politz wrote:
>>
>> > A small suggestion:
>> >
>> > I used roughly this macro (credit Jonah Kagan) recently to help me write
>> > some tests for parsing code that agnostic to which source position is
>> > generated in the parse:
>> >
>> > (define-syntax test/match
>> >   (syntax-rules ()
>> > [(test/match actual expected pred)
>> >  (let ([actual-val actual])
>> >(with-check-info* (list (make-check-actual actual-val)
>> >(make-check-expected 'expected))
>> >  (thunk (check-true (match actual-val
>> > [expected pred]
>> > [_ false])]
>> >
>> > [(test/match actual expected)
>> >  (test/match actual expected true)]))
>> >
>> > Shriram remarked that he was surprised some sort of check-match wasn't
>> > in rackunit already.  Is it worth adding something like this?
>> >
>> > I'm doing things like:
>> >
>> > (test/match (parse "5 'foo'") (s-block _ (list (s-num _ 5) (s-str _
>> > "foo"
>> >
>> > Where the structs s-block, s-num, and s-str all expect a srcloc as their
>> > first argument, but I don't care about it for these tests.
>> >
>> > The actual use is at:
>> >
>> >
>> > https://github.com/brownplt/pyret-lang/blob/master/src/tests/parse-tests.rkt#L36
>> >
>> > That file would be much, much uglier without this macro.
>> >
>> > Cheers,
>> > Joe P.
>> >
>> > _
>> >  Racket Developers list:
>> >  http://lists.racket-lang.org/dev
>>
>
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Racket installs more files on amd64 than on i386

[Robby Findler]

Oh, I see.

If you really need the lists of files to be the same, it is probably best
to make both versions have the files (altho don't different architectures
have different sets of files in general?).

Probably you'll be breaking the distro if you remove files.

Robby

On Monday, November 19, 2012, Juan Francisco Cantero Hurtado wrote:

> On 11/19/12 19:21, Robby Findler wrote:
>
>> I think it is probably best to have the OpenBSD port be a faithful
>> match to 5.3.1. This isn't a major bug and hopefully you'll just get
>> the fix in 5.3.2 or whatever the next version is called in 2-3 months.
>> Does that sound ok to you?
>>
>
> Temporally I'll remove the files affected from the PLIST (the list of
> files of the package), with this I can avoid the differences between archs.
> When the bug is fixed, I'll decide if the patch is too invasive or not for
> add to the port. Obviously this bug isn't a big problem for me :)
>
> OpenBSD will release the next version at May 1 and IIRC the frozen of the
> CVS will occur in February. I want do racket a official package for the
> next release, so I need fix or at least add a note about the known bugs.
>
>
>> Robby
>>
>> On Mon, Nov 19, 2012 at 12:13 PM, Juan Francisco Cantero Hurtado
>>  wrote:
>>
>>> On 11/19/12 03:40, Robby Findler wrote:
>>>

 On Sun, Nov 18, 2012 at 8:18 PM, Neil Toronto 
 wrote:

>
> It's a problem with the contract boundary. The examples work fine in
> Typed
> Racket. The problem type is this:
>
> (: flomap-transform
>  (case->
>   (flomap Flomap-Transform -> flomap)
>   (flomap Flomap-Transform Integer Integer Integer Integer
>   -> flomap)))
>
> The contract system claims that `flomap-transform' breaks its own
> contract.
> This is clearly bogus, so TR must be generating the wrong contract for
> it.
>
> Still, I should have caught this, and I apologize. I'll do penance
> by...
> writing a bug report? Probably not enough.
>


 Penance is an antiquated concept. We should do away with it. :)

 But if you feel bad enough to make a small program that demonstrates
 the problem that would be a contribution to it's solution!

>>>
>>>
>>> Thanks for to catch the bug guys!. Please send me a mail when you fix the
>>> bug and I'll add the patches to the OpenBSD port.
>>>
>>>
>
> _
>  Racket Developers list:
>  http://lists.racket-lang.org/**dev 
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] check-match?

[Robby Findler]

Yeah, that is very nice! (It should begin with "check" not "test" tho,
right?)

Robby

On Monday, November 19, 2012, Matthias Felleisen wrote:

>
> That is cute. Why don't you just create a pull request and Ryan can
> integrate it into rackunit? -- Matthias
>
>
>
>
>
> On Nov 19, 2012, at 4:22 PM, Joe Gibbs Politz wrote:
>
> > A small suggestion:
> >
> > I used roughly this macro (credit Jonah Kagan) recently to help me write
> some tests for parsing code that agnostic to which source position is
> generated in the parse:
> >
> > (define-syntax test/match
> >   (syntax-rules ()
> > [(test/match actual expected pred)
> >  (let ([actual-val actual])
> >(with-check-info* (list (make-check-actual actual-val)
> >(make-check-expected 'expected))
> >  (thunk (check-true (match actual-val
> > [expected pred]
> > [_ false])]
> >
> > [(test/match actual expected)
> >  (test/match actual expected true)]))
> >
> > Shriram remarked that he was surprised some sort of check-match wasn't
> in rackunit already.  Is it worth adding something like this?
> >
> > I'm doing things like:
> >
> > (test/match (parse "5 'foo'") (s-block _ (list (s-num _ 5) (s-str _
> "foo"
> >
> > Where the structs s-block, s-num, and s-str all expect a srcloc as their
> first argument, but I don't care about it for these tests.
> >
> > The actual use is at:
> >
> >
> https://github.com/brownplt/pyret-lang/blob/master/src/tests/parse-tests.rkt#L36
> >
> > That file would be much, much uglier without this macro.
> >
> > Cheers,
> > Joe P.
> >
> > _
> >  Racket Developers list:
> >  http://lists.racket-lang.org/dev
>
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] check-match?

[David Van Horn]

I written things like this before, so something built-in would be useful 
to me too.


David


On 11/19/12 5:01 PM, Matthias Felleisen wrote:


That is cute. Why don't you just create a pull request and Ryan can integrate 
it into rackunit? -- Matthias





On Nov 19, 2012, at 4:22 PM, Joe Gibbs Politz wrote:


A small suggestion:

I used roughly this macro (credit Jonah Kagan) recently to help me write some 
tests for parsing code that agnostic to which source position is generated in 
the parse:

(define-syntax test/match
   (syntax-rules ()
 [(test/match actual expected pred)
  (let ([actual-val actual])
(with-check-info* (list (make-check-actual actual-val)
(make-check-expected 'expected))
  (thunk (check-true (match actual-val
 [expected pred]
 [_ false])]

 [(test/match actual expected)
  (test/match actual expected true)]))

Shriram remarked that he was surprised some sort of check-match wasn't in 
rackunit already.  Is it worth adding something like this?

I'm doing things like:

(test/match (parse "5 'foo'") (s-block _ (list (s-num _ 5) (s-str _ "foo"

Where the structs s-block, s-num, and s-str all expect a srcloc as their first 
argument, but I don't care about it for these tests.

The actual use is at:

https://github.com/brownplt/pyret-lang/blob/master/src/tests/parse-tests.rkt#L36

That file would be much, much uglier without this macro.

Cheers,
Joe P.

_
  Racket Developers list:
  http://lists.racket-lang.org/dev




_
   Racket Developers list:
   http://lists.racket-lang.org/dev



_
 Racket Developers list:
 http://lists.racket-lang.org/dev

Re: [racket-dev] check-match?

[Matthias Felleisen]

That is cute. Why don't you just create a pull request and Ryan can integrate 
it into rackunit? -- Matthias





On Nov 19, 2012, at 4:22 PM, Joe Gibbs Politz wrote:

> A small suggestion:
> 
> I used roughly this macro (credit Jonah Kagan) recently to help me write some 
> tests for parsing code that agnostic to which source position is generated in 
> the parse:
> 
> (define-syntax test/match
>   (syntax-rules ()
> [(test/match actual expected pred)
>  (let ([actual-val actual])
>(with-check-info* (list (make-check-actual actual-val)
>(make-check-expected 'expected))
>  (thunk (check-true (match actual-val
> [expected pred]
> [_ false])]
> 
> [(test/match actual expected)
>  (test/match actual expected true)]))
> 
> Shriram remarked that he was surprised some sort of check-match wasn't in 
> rackunit already.  Is it worth adding something like this?
> 
> I'm doing things like:
> 
> (test/match (parse "5 'foo'") (s-block _ (list (s-num _ 5) (s-str _ "foo"
> 
> Where the structs s-block, s-num, and s-str all expect a srcloc as their 
> first argument, but I don't care about it for these tests.
> 
> The actual use is at:
> 
> https://github.com/brownplt/pyret-lang/blob/master/src/tests/parse-tests.rkt#L36
> 
> That file would be much, much uglier without this macro.
> 
> Cheers,
> Joe P.
> 
> _
>  Racket Developers list:
>  http://lists.racket-lang.org/dev



smime.p7s
Description: S/MIME cryptographic signature
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] check-match?

[Joe Gibbs Politz]

A small suggestion:

I used roughly this macro (credit Jonah Kagan) recently to help me write
some tests for parsing code that agnostic to which source position is
generated in the parse:

(define-syntax test/match
  (syntax-rules ()
[(test/match actual expected pred)
 (let ([actual-val actual])
   (with-check-info* (list (make-check-actual actual-val)
   (make-check-expected 'expected))
 (thunk (check-true (match actual-val
[expected pred]
[_ false])]

[(test/match actual expected)
 (test/match actual expected true)]))

Shriram remarked that he was surprised some sort of check-match wasn't in
rackunit already.  Is it worth adding something like this?

I'm doing things like:

(test/match (parse "5 'foo'") (s-block _ (list (s-num _ 5) (s-str _
"foo"

Where the structs s-block, s-num, and s-str all expect a srcloc as their
first argument, but I don't care about it for these tests.

The actual use is at:

https://github.com/brownplt/pyret-lang/blob/master/src/tests/parse-tests.rkt#L36

That file would be much, much uglier without this macro.

Cheers,
Joe P.
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Racket installs more files on amd64 than on i386

[Juan Francisco Cantero Hurtado]

On 11/19/12 19:21, Robby Findler wrote:

I think it is probably best to have the OpenBSD port be a faithful
match to 5.3.1. This isn't a major bug and hopefully you'll just get
the fix in 5.3.2 or whatever the next version is called in 2-3 months.
Does that sound ok to you?


Temporally I'll remove the files affected from the PLIST (the list of 
files of the package), with this I can avoid the differences between 
archs. When the bug is fixed, I'll decide if the patch is too invasive 
or not for add to the port. Obviously this bug isn't a big problem for 
me :)


OpenBSD will release the next version at May 1 and IIRC the frozen of 
the CVS will occur in February. I want do racket a official package for 
the next release, so I need fix or at least add a note about the known 
bugs.




Robby

On Mon, Nov 19, 2012 at 12:13 PM, Juan Francisco Cantero Hurtado
 wrote:

On 11/19/12 03:40, Robby Findler wrote:


On Sun, Nov 18, 2012 at 8:18 PM, Neil Toronto 
wrote:


It's a problem with the contract boundary. The examples work fine in
Typed
Racket. The problem type is this:

(: flomap-transform
 (case->
  (flomap Flomap-Transform -> flomap)
  (flomap Flomap-Transform Integer Integer Integer Integer
  -> flomap)))

The contract system claims that `flomap-transform' breaks its own
contract.
This is clearly bogus, so TR must be generating the wrong contract for
it.

Still, I should have caught this, and I apologize. I'll do penance by...
writing a bug report? Probably not enough.



Penance is an antiquated concept. We should do away with it. :)

But if you feel bad enough to make a small program that demonstrates
the problem that would be a contribution to it's solution!



Thanks for to catch the bug guys!. Please send me a mail when you fix the
bug and I'll add the patches to the OpenBSD port.




_
 Racket Developers list:
 http://lists.racket-lang.org/dev

Re: [racket-dev] Racket installs more files on amd64 than on i386

[Robby Findler]

I think it is probably best to have the OpenBSD port be a faithful
match to 5.3.1. This isn't a major bug and hopefully you'll just get
the fix in 5.3.2 or whatever the next version is called in 2-3 months.
Does that sound ok to you?

Robby

On Mon, Nov 19, 2012 at 12:13 PM, Juan Francisco Cantero Hurtado
 wrote:
> On 11/19/12 03:40, Robby Findler wrote:
>>
>> On Sun, Nov 18, 2012 at 8:18 PM, Neil Toronto 
>> wrote:
>>>
>>> It's a problem with the contract boundary. The examples work fine in
>>> Typed
>>> Racket. The problem type is this:
>>>
>>> (: flomap-transform
>>> (case->
>>>  (flomap Flomap-Transform -> flomap)
>>>  (flomap Flomap-Transform Integer Integer Integer Integer
>>>  -> flomap)))
>>>
>>> The contract system claims that `flomap-transform' breaks its own
>>> contract.
>>> This is clearly bogus, so TR must be generating the wrong contract for
>>> it.
>>>
>>> Still, I should have caught this, and I apologize. I'll do penance by...
>>> writing a bug report? Probably not enough.
>>
>>
>> Penance is an antiquated concept. We should do away with it. :)
>>
>> But if you feel bad enough to make a small program that demonstrates
>> the problem that would be a contribution to it's solution!
>
>
> Thanks for to catch the bug guys!. Please send me a mail when you fix the
> bug and I'll add the patches to the OpenBSD port.
>
>
>
> _
>  Racket Developers list:
>  http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Racket installs more files on amd64 than on i386

[Juan Francisco Cantero Hurtado]

On 11/19/12 03:40, Robby Findler wrote:

On Sun, Nov 18, 2012 at 8:18 PM, Neil Toronto  wrote:

It's a problem with the contract boundary. The examples work fine in Typed
Racket. The problem type is this:

(: flomap-transform
(case->
 (flomap Flomap-Transform -> flomap)
 (flomap Flomap-Transform Integer Integer Integer Integer
 -> flomap)))

The contract system claims that `flomap-transform' breaks its own contract.
This is clearly bogus, so TR must be generating the wrong contract for it.

Still, I should have caught this, and I apologize. I'll do penance by...
writing a bug report? Probably not enough.


Penance is an antiquated concept. We should do away with it. :)

But if you feel bad enough to make a small program that demonstrates
the problem that would be a contribution to it's solution!


Thanks for to catch the bug guys!. Please send me a mail when you fix 
the bug and I'll add the patches to the OpenBSD port.



_
 Racket Developers list:
 http://lists.racket-lang.org/dev

Re: [racket-dev] Wow; racket master at least 2x faster than 5.3.1 on my rb tree benchmark?

[Robby Findler]

Score another one for random testing! :)

On Sun, Nov 18, 2012 at 10:26 PM, Danny Yoo  wrote:
>
>
> On Sun, Nov 18, 2012 at 4:24 PM, Pierpaolo Bernardi 
> wrote:
>>
>> How does compare to builtin mutable hashes?
>
>
>
> The following code represents a rough hashtable equivalent of what my rb
> code would be enabling (quick search for word by position):
>
>
>   ;; We might be curious as to the overhead of the tree structure.
>   ;; (of course, it's worth it because we are dealing with a dynamic set
> here.)
>   ;; Still, let's compare with inserting into a native hash:
>   (printf "just for comparison: inserting in a native hash:\n")
>   (let ([ht (make-hash)])
> (time
>   (for/fold ([acc 0]) ([word (in-list (force all-words))])
> (hash-set! ht acc word)
> (+ acc (string-length word)
>
>
> It's also useful to compare this vs the existing splay tree approach in
> syntax-color/token-tree:
>
>   (printf "just for comparison: inserting in the original token
> tree:\n")
>   (let ([t (new token-tree%)])
> (time
>   (for ([word (in-list (force all-words))])
> (insert-last-spec! t (string-length word) word
>
>
> Here's the output of the insertion benchmark:
>
> ;; (from the rb-tree insertion)
> inserting 235886 words at the end...
> cpu time: 204 real time: 205 gc time: 0
>
> just for comparison: inserting in a native hash:
> cpu time: 108 real time: 107 gc time: 0
>
> just for comparison: inserting in the original token tree:
> cpu time: 51 real time: 51 gc time: 0
>
>
> So compared to the rb-tree version, insertions into the hashtable are about
> twice as fast.  And as one might expect, the splay tree bulk insertion is
> the fastest: it doesn't deal with balance at insertion time and can it delay
> that work until we start searching the structure.
>
> The rb-tree (as well as the original splay code) allows for much more
> flexible searches and dynamic updates into the sequence structure than the
> hash, so it's definitely worth the extra complexity.  My conjecture is that
> the non-allocating nature of the rb-tree, as well as its always-balanced
> structure, will be worth the cost of the extra insertion time vs splays.  I
> just hope I can show it!  :)  I'll see tomorrow when I code up a token-tree%
> implementation and start measuring times in DrRacket.
>
> I just got done with the fundamental rb-tree data structures this evening.
> Thank goodness Robby strongly recommended me to write a randomized testing
> approach.  It caught a lot of things I hadn't even considered.
>
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev