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
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] 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 jay.mccar...@gmail.comwrote: 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 j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ 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 jay.mccar...@gmail.com 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 jay.mccar...@gmail.com 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 j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ 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 jay.mccar...@gmail.com 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
[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] 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 e...@barzilay.org 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
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
On Tue, Dec 7, 2010 at 7:52 PM, Eli Barzilay e...@barzilay.org 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
Four minutes ago, Robby Findler wrote: On Tue, Dec 7, 2010 at 7:52 PM, Eli Barzilay e...@barzilay.org 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 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
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
