Re: [racket-dev] help with our mac os x installer?
Yesterday, Robby Findler wrote: > Does anyone have expertise or interest to help us figure out how to do a > better job with the mac os x packaging for Racket? > > It sure would be great if we had an alias to /Applications and a nice "drag > this there" image on the background of the .dmg like all the other mac > installers do > > The one constraint: the result has to be scriptable. That is, we > should be able to take some build and run some script to get a .dmg > with the nice setup. (Currently we have a script that makes a .dmg, > but with the ugly setup, as I'm sure you've all seen.) To clearify, the current script is a bash thing that simply constructs the directory and packages it up as a DMG. The new script (using osascript, IIRC) would run between the two steps, and will arrange for the mac metadata to have the desired layout. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package install mode
Yesterday, Ray Racine wrote: > I repent. While a reversible (install/uninstall) system-wide build > / install from source has some value in cases, I now doubt there is > adequate ROEMOF, return on effort and maintenance of feature. This was actually a side comment related to the fact that I have frequently posted messages about getting bad dependencies in the core. They will make it very hard to get to a nice small core. > Overall, for me, a trimmer "core" Racket installation is for more > valuable. I think that this is universally valuable. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #26024: master branch updated
I like the idea of the match patterns... but I'm worried about the details. The names are very common: get, post, head, etc. And I think exporting them as http-method-get or GET, etc would be hideous. Also, there is no exhaustive list of valid HTTP methods... anything can be used. And even the lisf of commonly used ones is long: http://annevankesteren.nl/2007/10/http-methods (as of 2007) Do you have any ideas for a solution to this? Jay On Fri, Jan 4, 2013 at 9:27 AM, Sam Tobin-Hochstadt wrote: > Ah, that makes sense. You could think about providing match patterns > for each of the HTTP methods, in that case -- people might be less > confused by that than strings. > > On Fri, Jan 4, 2013 at 10:30 AM, Jay McCarthy wrote: >> The programmer's input is not a string. It is a match pattern, so you can >> use 'or', '_', etc. >> >> >> On Fri, Jan 4, 2013 at 6:30 AM, Sam Tobin-Hochstadt >> wrote: >>> >>> Why not normalize this at the other end (ie, normalize the provided >>> string as well as the actual method) so that "GET" as well as "get" >>> will work? >>> >>> Sam >>> >>> On Fri, Jan 4, 2013 at 7:45 AM, wrote: >>> > jay has updated `master' from aa5f2e7875 to c07ff948ee. >>> > http://git.racket-lang.org/plt/aa5f2e7875..c07ff948ee >>> > >>> > =[ One Commit ]= >>> > Directory summary: >>> > 100.0% collects/web-server/scribblings/ >>> > >>> > ~~ >>> > >>> > c07ff94 Jay McCarthy 2013-01-04 05:44 >>> > : >>> > | Fixes PR13406 >>> > : >>> > M collects/web-server/scribblings/dispatch.scrbl | 11 +-- >>> > >>> > =[ Overall Diff ]=== >>> > >>> > collects/web-server/scribblings/dispatch.scrbl >>> > ~~ >>> > --- OLD/collects/web-server/scribblings/dispatch.scrbl >>> > +++ NEW/collects/web-server/scribblings/dispatch.scrbl >>> > @@ -118,6 +118,7 @@ or else the filesystem server will never see the >>> > requests. >>> > [maybe-method >>> >code:blank >>> >(code:line #:method method)] >>> > + [method pat] >>> > [maybe-else-clause >>> >code:blank >>> >[else else-fun]]) >>> > @@ -137,9 +138,15 @@ the @racket[dispatch-fun] given as its first >>> > argument. >>> > @racket[(next-dispatcher)] to signal to the Web Server that this >>> > dispatcher does not apply. >>> > >>> > - If any @racket[_method] is left out, it assumed to apply to requests >>> > -without methods and GET methods. >>> > + The @racket[_method] syntax is used in a @racket[match] expression to >>> > +match the @racket[request-method] part of the incoming request >>> > +object. However, since HTTP allows methods to use any case, the byte >>> > +string from @racket[request-method] is normalized to a lower-case >>> > +string. Thus, valid patterns are things like: @racket["get"], >>> > +@racket["post"], @racket["head"], @racket[(or "get" "post")], etc. >>> > >>> > + If @racket[_method] is left out, it assumed to apply to requests >>> > +without methods and GET methods. >>> > } >>> > >>> > @defform[ >> >> _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #26024: master branch updated
On Mon, Jan 7, 2013 at 10:24 AM, Jay McCarthy wrote: > I like the idea of the match patterns... but I'm worried about the details. > > The names are very common: get, post, head, etc. And I think exporting > them as http-method-get or GET, etc would be hideous. > > Also, there is no exhaustive list of valid HTTP methods... anything > can be used. And even the lisf of commonly used ones is long: > > http://annevankesteren.nl/2007/10/http-methods (as of 2007) > > Do you have any ideas for a solution to this? I like `GET`, `POST`, etc -- they're often spelled all-uppercase in documentation etc (as in Anne's list). Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #26024: master branch updated
Maybe a matcher like (http-method foo) that expands to (regexp #px"^(?i:foo)$") ? 10 minutes ago, Jay McCarthy wrote: > I like the idea of the match patterns... but I'm worried about the details. > > The names are very common: get, post, head, etc. And I think exporting > them as http-method-get or GET, etc would be hideous. > > Also, there is no exhaustive list of valid HTTP methods... anything > can be used. And even the lisf of commonly used ones is long: > > http://annevankesteren.nl/2007/10/http-methods (as of 2007) > > Do you have any ideas for a solution to this? -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #26024: master branch updated
How about just saying that the input is either the string "get" "put" "post" or a match pattern and if it is one of the former, then do case-folding before checking? Robby On Mon, Jan 7, 2013 at 9:24 AM, Jay McCarthy wrote: > I like the idea of the match patterns... but I'm worried about the details. > > The names are very common: get, post, head, etc. And I think exporting > them as http-method-get or GET, etc would be hideous. > > Also, there is no exhaustive list of valid HTTP methods... anything > can be used. And even the lisf of commonly used ones is long: > > http://annevankesteren.nl/2007/10/http-methods (as of 2007) > > Do you have any ideas for a solution to this? > > Jay > > > On Fri, Jan 4, 2013 at 9:27 AM, Sam Tobin-Hochstadt > wrote: > > Ah, that makes sense. You could think about providing match patterns > > for each of the HTTP methods, in that case -- people might be less > > confused by that than strings. > > > > On Fri, Jan 4, 2013 at 10:30 AM, Jay McCarthy > wrote: > >> The programmer's input is not a string. It is a match pattern, so you > can > >> use 'or', '_', etc. > >> > >> > >> On Fri, Jan 4, 2013 at 6:30 AM, Sam Tobin-Hochstadt > >> wrote: > >>> > >>> Why not normalize this at the other end (ie, normalize the provided > >>> string as well as the actual method) so that "GET" as well as "get" > >>> will work? > >>> > >>> Sam > >>> > >>> On Fri, Jan 4, 2013 at 7:45 AM, wrote: > >>> > jay has updated `master' from aa5f2e7875 to c07ff948ee. > >>> > http://git.racket-lang.org/plt/aa5f2e7875..c07ff948ee > >>> > > >>> > =[ One Commit > ]= > >>> > Directory summary: > >>> > 100.0% collects/web-server/scribblings/ > >>> > > >>> > ~~ > >>> > > >>> > c07ff94 Jay McCarthy 2013-01-04 05:44 > >>> > : > >>> > | Fixes PR13406 > >>> > : > >>> > M collects/web-server/scribblings/dispatch.scrbl | 11 +-- > >>> > > >>> > =[ Overall Diff > ]=== > >>> > > >>> > collects/web-server/scribblings/dispatch.scrbl > >>> > ~~ > >>> > --- OLD/collects/web-server/scribblings/dispatch.scrbl > >>> > +++ NEW/collects/web-server/scribblings/dispatch.scrbl > >>> > @@ -118,6 +118,7 @@ or else the filesystem server will never see the > >>> > requests. > >>> > [maybe-method > >>> >code:blank > >>> >(code:line #:method method)] > >>> > + [method pat] > >>> > [maybe-else-clause > >>> >code:blank > >>> >[else else-fun]]) > >>> > @@ -137,9 +138,15 @@ the @racket[dispatch-fun] given as its first > >>> > argument. > >>> > @racket[(next-dispatcher)] to signal to the Web Server that this > >>> > dispatcher does not apply. > >>> > > >>> > - If any @racket[_method] is left out, it assumed to apply to > requests > >>> > -without methods and GET methods. > >>> > + The @racket[_method] syntax is used in a @racket[match] expression > to > >>> > +match the @racket[request-method] part of the incoming request > >>> > +object. However, since HTTP allows methods to use any case, the byte > >>> > +string from @racket[request-method] is normalized to a lower-case > >>> > +string. Thus, valid patterns are things like: @racket["get"], > >>> > +@racket["post"], @racket["head"], @racket[(or "get" "post")], etc. > >>> > > >>> > + If @racket[_method] is left out, it assumed to apply to requests > >>> > +without methods and GET methods. > >>> > } > >>> > > >>> > @defform[ > >> > >> > _ > Racket Developers list: > http://lists.racket-lang.org/dev > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Motivation for polymorphic opaque types
I think this "specific case" covers pretty much every abstract data type written in Typed Racket, including all those exported by PFDS and math/array. (Well, the RAList type in PFDS would have to wrap its lists of roots in a struct to get great performance in untyped Racket instead of just good performance.) In math/array, in particular, there are only a few instances in which the typed code instantiates the Array type, all having to do with conversions to and from FlArray and FCArray. Yes, this would make me very happy. :) Neil ⊥ On 01/06/2013 03:36 PM, Sam Tobin-Hochstadt wrote: Right -- if we (the typed code) are picking the instantiation, then we have to check structurally, to make sure that it's really got integers everywhere. But if it's a plain type parameter, then the untyped side gets to pick it, and WLOG they could pick `Any`, meaning that there's no wrong values they could supply. That means that as long as they supply a `kons`, it must meet the contract of `(Kons A)`. So I think the contract can be much cheaper in this one specific case, which fortunately is the case that Neil cares about, I think. Sam On Sun, Jan 6, 2013 at 5:28 PM, Robby Findler wrote: Oh-- I think you're right that the type parameter can matter (it could go over to R as an Integer list and come back as a Boolean list or something). Robby On Sun, Jan 6, 2013 at 4:08 PM, Sam Tobin-Hochstadt wrote: Sorry, that was very silly of me. That isn't what's happening at all, because type soundness means we don't need to enforce the parametricity at all. The actual relevant program is: (module m racket (struct kons (a d)) (struct mt ()) (define MT (mt)) (define (FST v) (when (eq? MT v) (error 'empty)) (kons-a v)) (define (RST v) (when (eq? MT v) (error 'empty)) (kons-d v)) (define (LST . x) (if (empty? x) MT (kons (first x) (apply LST (rest x) (define (LST/C elem/c) (define C (recursive-contract (or/c (λ (v) (eq? v MT)) (struct/dc kons [a elem/c] [d C] C) (provide/contract [LST (->* () #:rest any/c (LST/C any/c))] [FST (-> (LST/C any/c) any/c)] [RST (-> (LST/C any/c) (LST/C any/c))]) ) However, thinking about this more, it's an invariant that `kons` structures are always correctly constructed, and we can rely on them to have *some* instantiation that typechecks -- that's why the `any/c` is ok. That suggests to me that contract generation for a struct type applied to simple type variables can always be just the predicate for that type, which would make Neil very happy. I want to think about this more before I'm sure, though. Thanks for being patient while I get this wrong in various ways ... Sam On Sun, Jan 6, 2013 at 4:13 PM, Robby Findler wrote: This has a non-chaperone contract being used in a struct/c, I think? (FST (LST 1 2 3)) => struct/dc: expected chaperone contracts, but field a has # Robby On Sun, Jan 6, 2013 at 2:40 PM, Sam Tobin-Hochstadt wrote: On Sun, Jan 6, 2013 at 3:23 PM, Robby Findler wrote: On Sun, Jan 6, 2013 at 2:18 PM, Sam Tobin-Hochstadt wrote: The boundaries have the information; that's how the contracts got inserted in the first place. No, the contracts are parametric contracts using `parametric->/c`, and thus don't have any information about the types used at all. I don't see why you can't tag them when something at a boundary and then check that something at another boundary instead of doing some deep check. The problem is that I don't know what to tag them *with*. Consider the following program: #lang racket (struct kons (a d)) (struct mt ()) (define MT (mt)) (define (FST v) (when (eq? MT v) (error 'empty)) (kons-a v)) (define (RST v) (when (eq? MT v) (error 'empty)) (kons-d v)) (define (LST . x) (if (empty? x) MT (kons (first x) (apply LST (rest x) (define (LST/C elem/c) (define C (recursive-contract (or/c (λ (v) (eq? v MT)) (struct/c kons elem/c C C) (provide/contract [LST (parametric->/c (A) (->* () #:rest A (LST/C A)))] [FST (parametric->/c (A) (-> (LST/C A) A))] [RST (parametric->/c (A) (-> (LST/C A) (LST/C A)))]) This is the essence of Neil's polymorphic list program, as implemented by Typed Racket. I don't know how to change those contracts to not be really expensive, because I can't pick the instantiation of A at runtime to tag the structure instances with. Sam _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Release for v5.3.2 has begun
The release process for v5.3.2 has begun: the `release' branch was created for any work that is left and is now bumped to v5.3.1.900. You can go on using the `master' branch as usual, it is now bumped to v5.3.2.1 (to avoid having two different trees with the same version). If you have any bug-fixes and changes that need to go in the release then make sure to specify that in the commit message or mail me the commit SHA1s. You can `git checkout release' to try it out directly if needed -- but do not try to push commits on it (the server will forbid it). Please make sure that code that you're responsible for is as stable as possible, and let me know if there is any new work that should not be included in this release. >> NOW IS THE TIME TO FIX BUGS THAT YOU KNOW ABOUT <<< The time between the `release' branch creation and the actual release is for fixing new errors that prevent proper functioning of major components and that show up during the preparation for a release. You can also finalize piece of work that is not yet complete, but please avoid merging new features. Note that nightly builds will go on as usual (starting from v5.3.2.1 and going up as usual), and pre-release builds will be available shortly at http://pre.racket-lang.org/release/ Please tell me if you think that this release is significant enough that it should be announced on the users list for wider testing. _ Racket Developers list: http://lists.racket-lang.org/dev
