Re: [racket-dev] tags on github
Two minutes ago, John Clements wrote: > > On Dec 7, 2010, at 5:52 PM, Eli Barzilay wrote: > > > 6 minutes ago, Robby Findler wrote: > >> It is a kind out of the way place but it would be a shame if > >> someone went there, esp. since the latest stuff is in the middle > >> of the list. > > > > OK, so I'll take it as a "yes" vote. Any suggestion for new > > names? One option is to go with the common misconception of > > "v372" -> "v3.72", another is a silly "v372" -> "z372". > > Wait... isn't it *reverse* order? In this case, you could name them > old-scheme-v372 (a double entendre). Or antique-v372, or whatever > you like. Right? [slaps forehead] In my defense, there was a "zzz" suggestion on #github which threw me off. I'll use "old-v372" then. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] tags on github
On Dec 7, 2010, at 5:52 PM, Eli Barzilay wrote: > 6 minutes ago, Robby Findler wrote: >> It is a kind out of the way place but it would be a shame if someone >> went there, esp. since the latest stuff is in the middle of the >> list. > > OK, so I'll take it as a "yes" vote. Any suggestion for new names? > One option is to go with the common misconception of "v372" -> > "v3.72", another is a silly "v372" -> "z372". Wait... isn't it *reverse* order? In this case, you could name them old-scheme-v372 (a double entendre). Or antique-v372, or whatever you like. Right? John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] tags on github
Four minutes ago, Robby Findler wrote: > On Tue, Dec 7, 2010 at 7:52 PM, Eli Barzilay wrote: > > 6 minutes ago, Robby Findler wrote: > >> It is a kind out of the way place but it would be a shame if someone > >> went there, esp. since the latest stuff is in the middle of the > >> list. > > > > OK, so I'll take it as a "yes" vote. Any suggestion for new names? > > One option is to go with the common misconception of "v372" -> > > "v3.72", another is a silly "v372" -> "z372". > > How about putting the date at the front of the tag? > > 1872/01/29-v372 The problem withi this is that it'll require changing the post-v4 tags also, and I like to keep them as they are now. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] tags on github
On Tue, Dec 7, 2010 at 7:52 PM, Eli Barzilay wrote: > 6 minutes ago, Robby Findler wrote: >> It is a kind out of the way place but it would be a shame if someone >> went there, esp. since the latest stuff is in the middle of the >> list. > > OK, so I'll take it as a "yes" vote. Any suggestion for new names? > One option is to go with the common misconception of "v372" -> > "v3.72", another is a silly "v372" -> "z372". How about putting the date at the front of the tag? 1872/01/29-v372 Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] tags on github
6 minutes ago, Robby Findler wrote: > It is a kind out of the way place but it would be a shame if someone > went there, esp. since the latest stuff is in the middle of the > list. OK, so I'll take it as a "yes" vote. Any suggestion for new names? One option is to go with the common misconception of "v372" -> "v3.72", another is a silly "v372" -> "z372". > But I wouldn't want you to spend too much time on it. (That's not an issue -- there's only 15 of them.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] tags on github
It is a kind out of the way place but it would be a shame if someone went there, esp. since the latest stuff is in the middle of the list. But I wouldn't want you to spend too much time on it. Robby On Tue, Dec 7, 2010 at 7:18 PM, Eli Barzilay wrote: > If you go to the racket page at github (https://github.com/plt/racket) > and hit the downloads button, you get a download with three ancient > versions. The reson for that is that it sorts the tags in reverse > lexicographic order. (The same holds for the "switch tags" dropdown > list.) > > I've asked on #github, and looks like there's no settings to change, > so the only way to change this is to rename the tags. > > Questions: > > 1. Does anyone think that this is important enough to do a rename? > > 2. If so, any suggestions for names for the old tags? > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > http://barzilay.org/ Maze is Life! > _ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] tags on github
If you go to the racket page at github (https://github.com/plt/racket) and hit the downloads button, you get a download with three ancient versions. The reson for that is that it sorts the tags in reverse lexicographic order. (The same holds for the "switch tags" dropdown list.) I've asked on #github, and looks like there's no settings to change, so the only way to change this is to rename the tags. Questions: 1. Does anyone think that this is important enough to do a rename? 2. If so, any suggestions for names for the old tags? -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
On Tue, Dec 7, 2010 at 1:17 PM, Jay McCarthy wrote: > > I've removed the coercive contracts and replaced them with a global > imperative any->response hook that defaults to "off" but can easily be > turned "on" to support X-exprs or the old behavior of the Web Server. > Great! Thanks. yc _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
Thanks, Jay. Robby On Tuesday, December 7, 2010, Jay McCarthy wrote: > I've just committed the culmination of this thread. > I've removed the coercive contracts and replaced them with a global > imperative any->response hook that defaults to "off" but can easily be turned > "on" to support X-exprs or the old behavior of the Web Server. > > Jay > > On Fri, Nov 26, 2010 at 5:55 PM, Jay McCarthy wrote: > > I would like to remove the implicit preference the Web Server gives to > Xexprs and the old esoteric bytes response format. This is backwards > incompatible change, but I think it will make the server better in the > long run as it will promote other HTML encodings, like the xml and > html modules, Eli's new system, SXML, etc. I am interested in your > opinion. > > -- Details -- > > Everywhere that the server expects a "response" uses the response/c contract > > http://pre.racket-lang.org/docs/html/web-server/http.html#(def._((lib._web-server/http/response-structs..rkt)._response/c)) > > This allows the native HTTP response data structures, Xexprs, and > lists that start with bytes (the MIME type) where everything after is > a byte string or normal string. [I have no idea where that last thing > came from, but it was in the legacy server and I've kept it > compatible.] > > In addition to backwards incompatibility, this could make Web > programming a bit more verbose, because you'd have to explicitly call > "make-xexpr-response" to construct the response from the Xexpr. I > could ease that a little bit by changing its name to "xexpr" or > something similar. > > Any ideas on the best way to deal with this? > > Jay > > -- > Jay McCarthy > Assistant Professor / Brigham Young University > http://faculty.cs.byu.edu/~jay > > "The glory of God is Intelligence" - D&C 93 > > > -- > Jay McCarthy > Assistant Professor / Brigham Young University > http://faculty.cs.byu.edu/~jay > > "The glory of God is Intelligence" - D&C 93 > > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
I've just committed the culmination of this thread. I've removed the coercive contracts and replaced them with a global imperative any->response hook that defaults to "off" but can easily be turned "on" to support X-exprs or the old behavior of the Web Server. Jay On Fri, Nov 26, 2010 at 5:55 PM, Jay McCarthy wrote: > I would like to remove the implicit preference the Web Server gives to > Xexprs and the old esoteric bytes response format. This is backwards > incompatible change, but I think it will make the server better in the > long run as it will promote other HTML encodings, like the xml and > html modules, Eli's new system, SXML, etc. I am interested in your > opinion. > > -- Details -- > > Everywhere that the server expects a "response" uses the response/c > contract > > > http://pre.racket-lang.org/docs/html/web-server/http.html#(def._((lib._web-server/http/response-structs..rkt)._response/c)) > > This allows the native HTTP response data structures, Xexprs, and > lists that start with bytes (the MIME type) where everything after is > a byte string or normal string. [I have no idea where that last thing > came from, but it was in the legacy server and I've kept it > compatible.] > > In addition to backwards incompatibility, this could make Web > programming a bit more verbose, because you'd have to explicitly call > "make-xexpr-response" to construct the response from the Xexpr. I > could ease that a little bit by changing its name to "xexpr" or > something similar. > > Any ideas on the best way to deal with this? > > Jay > > -- > Jay McCarthy > Assistant Professor / Brigham Young University > http://faculty.cs.byu.edu/~jay > > "The glory of God is Intelligence" - D&C 93 > -- Jay McCarthy Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Behavioral subtyping for editor<%> and its implementing classes
Sounds fine. At Tue, 7 Dec 2010 15:20:54 -0500, Matthias Felleisen wrote: > > > If we take it out of editor<%>, we should not encounter any problems > whatsoever. It is possible that additional implements-interface checks will > succeed, but I am doubtful. Other than that I can't think of any problems. > > Should Asumu try and just run the whole test suite and if it works you commit > the change? > > > > > On Dec 7, 2010, at 3:08 PM, Matthew Flatt wrote: > > > I think the mismatch was not intentional. > > > > Maybe `do-copy' originally had a consistent interface, or maybe it was > > written down in `editor<%>' before it became apparent that its > > interface would be be specific to each different kin of editor. I can't > > think of any reason to have `do-copy' in its present form in > > `editor<%>'. > > > > At Thu, 2 Dec 2010 16:29:52 -0500, Asumu Takikawa wrote: > >> Hi all, > >> > >> While writing contracts for classes in racket/gui, I noticed that the > >> implementations of text% and pasteboard% do not act as behavioral > >> subtypes of editor<%>, which both classes implement. > >> > >> In particular, consider the do-copy method from editor<%>. Its contract > >> looks like this: > >> > >> (send an-editor do-copy) → void? > >> > http://pre.racket-lang.org/docs/html/gui/editor___.html?q=do-copy#(meth._(((lib > >> ._mred/main..rkt)._editor~3c~25~3e)._do-copy)) > >> > >> However, the implementations have the following contracts: > >> > >> (send a-text do-copy start end time extend?) → void? > >> > http://pre.racket-lang.org/docs/html/gui/text_.html?q=do-copy#(meth._(((lib._mr > >> ed/main..rkt)._text~25)._do-copy)) > >> > >> and > >> > >> (send a-pasteboard do-copy time extend?) → void? > >> > http://pre.racket-lang.org/docs/html/gui/pasteboard_.html?q=do-copy#(meth._(((l > >> ib._mred/main..rkt)._pasteboard~25)._do-copy)) > >> > >> That is, do-copy in editor<%> has no mandatory arguments, do-copy in > >> text% has four mandatory arguments, and do-copy in pasteboard% has > >> two mandatory arguments. Thus, the do-copy methods in text% and > >> pasteboard% do not implement the editor<%> interface (in the behavioral > >> subtyping sense) nor do they implement a common interface despite > >> claiming to. > >> > >> There are several other examples of this issue in the same classes. (see > >> do-paste, paste-x-selection, etc.) > >> > >> Is there a design rationale for this? Is this method not meant to > >> implement a common interface? > >> > >> Cheers, > >> Asumu > > > > _ > > For list-related administrative tasks: > > http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Behavioral subtyping for editor<%> and its implementing classes
If we take it out of editor<%>, we should not encounter any problems whatsoever. It is possible that additional implements-interface checks will succeed, but I am doubtful. Other than that I can't think of any problems. Should Asumu try and just run the whole test suite and if it works you commit the change? On Dec 7, 2010, at 3:08 PM, Matthew Flatt wrote: > I think the mismatch was not intentional. > > Maybe `do-copy' originally had a consistent interface, or maybe it was > written down in `editor<%>' before it became apparent that its > interface would be be specific to each different kin of editor. I can't > think of any reason to have `do-copy' in its present form in > `editor<%>'. > > At Thu, 2 Dec 2010 16:29:52 -0500, Asumu Takikawa wrote: >> Hi all, >> >> While writing contracts for classes in racket/gui, I noticed that the >> implementations of text% and pasteboard% do not act as behavioral >> subtypes of editor<%>, which both classes implement. >> >> In particular, consider the do-copy method from editor<%>. Its contract >> looks like this: >> >> (send an-editor do-copy) → void? >> http://pre.racket-lang.org/docs/html/gui/editor___.html?q=do-copy#(meth._(((lib >> ._mred/main..rkt)._editor~3c~25~3e)._do-copy)) >> >> However, the implementations have the following contracts: >> >> (send a-text do-copy start end time extend?) → void? >> http://pre.racket-lang.org/docs/html/gui/text_.html?q=do-copy#(meth._(((lib._mr >> ed/main..rkt)._text~25)._do-copy)) >> >> and >> >> (send a-pasteboard do-copy time extend?) → void? >> http://pre.racket-lang.org/docs/html/gui/pasteboard_.html?q=do-copy#(meth._(((l >> ib._mred/main..rkt)._pasteboard~25)._do-copy)) >> >> That is, do-copy in editor<%> has no mandatory arguments, do-copy in >> text% has four mandatory arguments, and do-copy in pasteboard% has >> two mandatory arguments. Thus, the do-copy methods in text% and >> pasteboard% do not implement the editor<%> interface (in the behavioral >> subtyping sense) nor do they implement a common interface despite >> claiming to. >> >> There are several other examples of this issue in the same classes. (see >> do-paste, paste-x-selection, etc.) >> >> Is there a design rationale for this? Is this method not meant to >> implement a common interface? >> >> Cheers, >> Asumu > > _ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Behavioral subtyping for editor<%> and its implementing classes
I think the mismatch was not intentional. Maybe `do-copy' originally had a consistent interface, or maybe it was written down in `editor<%>' before it became apparent that its interface would be be specific to each different kin of editor. I can't think of any reason to have `do-copy' in its present form in `editor<%>'. At Thu, 2 Dec 2010 16:29:52 -0500, Asumu Takikawa wrote: > Hi all, > > While writing contracts for classes in racket/gui, I noticed that the > implementations of text% and pasteboard% do not act as behavioral > subtypes of editor<%>, which both classes implement. > > In particular, consider the do-copy method from editor<%>. Its contract > looks like this: > > (send an-editor do-copy) → void? > http://pre.racket-lang.org/docs/html/gui/editor___.html?q=do-copy#(meth._(((lib > ._mred/main..rkt)._editor~3c~25~3e)._do-copy)) > > However, the implementations have the following contracts: > > (send a-text do-copy start end time extend?) → void? > http://pre.racket-lang.org/docs/html/gui/text_.html?q=do-copy#(meth._(((lib._mr > ed/main..rkt)._text~25)._do-copy)) > > and > > (send a-pasteboard do-copy time extend?) → void? > http://pre.racket-lang.org/docs/html/gui/pasteboard_.html?q=do-copy#(meth._(((l > ib._mred/main..rkt)._pasteboard~25)._do-copy)) > > That is, do-copy in editor<%> has no mandatory arguments, do-copy in > text% has four mandatory arguments, and do-copy in pasteboard% has > two mandatory arguments. Thus, the do-copy methods in text% and > pasteboard% do not implement the editor<%> interface (in the behavioral > subtyping sense) nor do they implement a common interface despite > claiming to. > > There are several other examples of this issue in the same classes. (see > do-paste, paste-x-selection, etc.) > > Is there a design rationale for this? Is this method not meant to > implement a common interface? > > Cheers, > Asumu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
