Re: [racket-dev] [plt] Push #28213: master branch updated
On 2014-02-20 21:25:59 -0700, Neil Toronto wrote: > You mean something like this would work? > > (define-type (Leaf1 X) (Pair (Leaf2 X) (Leaf2 X))) > (define-type (Leaf2 X) (U X (Pair (Leaf1 X) (Leaf1 X Yes, that should work. Here's an example interaction from my development branch: Welcome to Racket v5.90.0.10. -> (let () (define-type (Leaf1 X) (Pair (Leaf2 X) (Leaf2 X))) (define-type (Leaf2 X) (U X (Pair (Leaf1 X) (Leaf1 X (define: x : (Leaf1 Integer) (cons 3 (cons (cons 5 5) (cons 6 5 x) - : (Leaf1 Integer) '(3 (5 . 5) 6 . 5) Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28213: master branch updated
On 02/20/2014 09:03 PM, Asumu Takikawa wrote: On 2014-02-20 20:31:56 -0700, Neil Toronto wrote: How close is this to being able to support, say, the plot library converted to TR? The OO stuff in it is a few custom classes without anything complicated, a couple of snip% descendants, and drawing onto device contexts. Should be very close. Not quite there currently because there are two more chunks that I've written and haven't pushed yet: * Implicit (mutual) recursive type aliases, so that a `define-type` can define mutually recursive type alises like the types for `bitmap%` and `bitmap-dc%`. You mean something like this would work? (define-type (Leaf1 X) (Pair (Leaf2 X) (Leaf2 X))) (define-type (Leaf2 X) (U X (Pair (Leaf1 X) (Leaf1 X * Types for everything in racket/gui and a few other libraries. Types for the framework are still work-in-progress. * Full contract support. I'm with Robby. This sounds awesome. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28213: master branch updated
This looks fantastic! Robby On Thu, Feb 20, 2014 at 10:06 PM, Asumu Takikawa wrote: > On 2014-02-20 23:03:22 -0500, Asumu Takikawa wrote: > > Should be very close. Not quite there currently because there are two > > more chunks that I've written and haven't pushed yet: > > > > * Implicit (mutual) recursive type aliases, so that a `define-type` > > can define mutually recursive type alises like the types for > > `bitmap%` and `bitmap-dc%`. > > > > * Types for everything in racket/gui and a few other libraries. > > Types for the framework are still work-in-progress. > > > > * Full contract support. > > Apparently I should learn how to count though. :p > > Cheers, > Asumu > _ > Racket Developers list: > http://lists.racket-lang.org/dev > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28213: master branch updated
On 2014-02-20 23:03:22 -0500, Asumu Takikawa wrote: > Should be very close. Not quite there currently because there are two > more chunks that I've written and haven't pushed yet: > > * Implicit (mutual) recursive type aliases, so that a `define-type` > can define mutually recursive type alises like the types for > `bitmap%` and `bitmap-dc%`. > > * Types for everything in racket/gui and a few other libraries. > Types for the framework are still work-in-progress. > > * Full contract support. Apparently I should learn how to count though. :p Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28213: master branch updated
On 2014-02-20 20:31:56 -0700, Neil Toronto wrote: > How close is this to being able to support, say, the plot library > converted to TR? The OO stuff in it is a few custom classes without > anything complicated, a couple of snip% descendants, and drawing > onto device contexts. Should be very close. Not quite there currently because there are two more chunks that I've written and haven't pushed yet: * Implicit (mutual) recursive type aliases, so that a `define-type` can define mutually recursive type alises like the types for `bitmap%` and `bitmap-dc%`. * Types for everything in racket/gui and a few other libraries. Types for the framework are still work-in-progress. * Full contract support. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28213: master branch updated
On 02/20/2014 02:52 PM, as...@racket-lang.org wrote: asumu has updated `master' from 1f27fb7848 to 1c6c0855f7. http://git.racket-lang.org/plt/1f27fb7848..1c6c0855f7 =[ 103 Commits ] Directory summary: 3.8% pkgs/typed-racket-pkgs/typed-racket-doc/typed-racket/scribblings/reference/ 10.7% pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/base-env/ 6.1% pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/private/ 4.0% pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/rep/ 34.5% pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/typecheck/ 9.6% pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/types/ 4.0% pkgs/typed-racket-pkgs/typed-racket-more/typed/mred/ 23.6% pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/unit-tests/ 3.4% pkgs/ ~~ [... HOLY COW ...] How close is this to being able to support, say, the plot library converted to TR? The OO stuff in it is a few custom classes without anything complicated, a couple of snip% descendants, and drawing onto device contexts. Also, is there a paper floating around somewhere that details the interesting problems that have been solved to make this work? Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket head fails to compile
At Sun, 09 Feb 2014 08:35:03 +, "Paulo J. Matos" wrote: > On 09/02/14 00:03, Matthew Flatt wrote: > > There should be many more flags passed to `gcc`, including some -I > > flags and some -D flags. > > > > Is something in your environment overriding the CFLAGS definition in > > the makefile? Normally, a definition in the makefile would take > > precedence over an environment variable, but maybe something else is > > taking precedence over the definition? > > > > > Doh, right. I assumed for no good reason racket would behave the same > way my usual project does and use env CFLAGS as the optimization flags > used for compilation. Any other env variable the racket build system > uses for me to add additional compilation flags? (for example to build > with `-O2 -ftree-vectorize` or `-O0 -g3`) > > After some thought shouldn't -D... and -I... flags be controlled by > CPPFLAGS and not CFLAGS such that overriding CFLAGS would still leave > CPPFLAGS intact? I've changed the makefiles so that setting CFLAGS (or CPPFLAGS) will hopefully work the way you expect. _ Racket Developers list: http://lists.racket-lang.org/dev
