[racket-dev] strange error
Welcome to DrRacket, version 5.1.1.5--2011-06-15(d5b25eb/g) [3m]. Language: racket. compile: access from an uncertified context to unexported variable from module: /Users/matthias/plt/collects/racket/private/define-struct.rkt in: make-self-ctor-checked-struct-info I don't know yet how to create it in a few lines. Any hints? _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] net/url and https
Does anyone have any objection to dropping the unitized interface for `net/url'? Specifically, did anyone ever used it for any purpose other than making up an `ssl:*' variant of the library? I'm looking into making it deal properly with ssl connections, and I think that the right way to do it is by making the code dispatch to the plain tcp functions or the ssl versions based on the scheme of the input url. 1. Looking at the code, there are only two tcp functions used (`tcp-connect' and `tcp-abandon-port'), so eliminating the unit interface and just hooking things up so that an https scheme uses the ssl functions is relatively easy. 2. Another possibly solution is to make the `net/url-unit' import two tcp units, one for plain connections and one for https connextions. The problem with that is that it still breaks compatibility since the imports are different. 3. Yet another solution is to make it do the same thing it does now, but for https urls it will always use the ssl bindings. This means that you can still parameterize the code over the tcp functions, but https urls bypass that parameterization and use the ssl things directly. I dislike #2 since it's making things even more hairy in the unit sense, and I don't think that that's a good direction. I dislike #3 since it feels like a bad hack. -- ((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] net/url and https
I think we should not remove anything from the net/url library (including the unitized interface) as I believe that will break old code. Robby On Mon, Jun 20, 2011 at 5:57 AM, Eli Barzilay e...@barzilay.org wrote: Does anyone have any objection to dropping the unitized interface for `net/url'? Specifically, did anyone ever used it for any purpose other than making up an `ssl:*' variant of the library? I'm looking into making it deal properly with ssl connections, and I think that the right way to do it is by making the code dispatch to the plain tcp functions or the ssl versions based on the scheme of the input url. 1. Looking at the code, there are only two tcp functions used (`tcp-connect' and `tcp-abandon-port'), so eliminating the unit interface and just hooking things up so that an https scheme uses the ssl functions is relatively easy. 2. Another possibly solution is to make the `net/url-unit' import two tcp units, one for plain connections and one for https connextions. The problem with that is that it still breaks compatibility since the imports are different. 3. Yet another solution is to make it do the same thing it does now, but for https urls it will always use the ssl bindings. This means that you can still parameterize the code over the tcp functions, but https urls bypass that parameterization and use the ssl things directly. I dislike #2 since it's making things even more hairy in the unit sense, and I don't think that that's a good direction. I dislike #3 since it feels like a bad hack. -- ((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] net/url and https
I appreciate the conscientiousness about backward-compatibility here, but, as a data point of one developer, I would be happy to incur the backward-incompatibility of option #1 in exchange for getting rid of the Cookbook HTTPS hack sooner rather than later. I also think that Eli's option #1 could be done without breaking backward-compatibility, but I'm not sure it's worth the effort in code and documentation, and I don't want to discourage him moving forward with #1 by making the task harder than it has to be. (Full disclosure: Breaking backward-compatibility in the option #1 way would generate approx. one billable hour of consulting work for me. Just to edit some require forms, quickly inspect the call sites with Emacs grep, test, and remove a Cookbook hack file from the CM branch.) Thanks for tackling this, Eli. Robby Findler wrote at 06/19/2011 06:26 PM: I think we should not remove anything from the net/url library (including the unitized interface) as I believe that will break old code. On Mon, Jun 20, 2011 at 5:57 AM, Eli Barzilay e...@barzilay.org wrote: 1. Looking at the code, there are only two tcp functions used (`tcp-connect' and `tcp-abandon-port'), so eliminating the unit interface and just hooking things up so that an https scheme uses the ssl functions is relatively easy. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] net/url and https
15 minutes ago, Robby Findler wrote: I think we should not remove anything from the net/url library (including the unitized interface) as I believe that will break old code. This means one of 2.5 new options: 4. Create a new library that will do exactly what `net/url' is doing, except without the unit interface (or the two-tcp-imports interface), and with the desired dispatching over https urls. 5. Create a new library that will do the right thing, extending what net/url does by a whole bunch of stuff. That means a complete redesign of the library. 6. Do #4 first, then do #5. I think that #5 is inevitable. The `net/url' is designed in a way that dooms it to be a toy. For example, it just gives you the contents, possibly with the HTTP reply headers pretty much as is -- which means that there is no way to distinguish a 404 result (should result in an error) or a 301 result (should follow the redirection). To properly deal with these things, you currently need to manually look at the impure port and parse it yourself. Further, there's a bunch of additional functionality that is missing from it. I do plan to write it (a new library, the #5 option). Of course unless someone else does that (*wink* *wink* *nudge* *nudge*). It might even be compatible with the current `net/url', but probably not with the unit part. Given that there is a need for such a library, #4 is not a viable option. However, doing this will require more time. (Specifically, I can change the `net/url' as previously described right now, but a new library will probably take much more time.) This leaves #6 as the only other alternative if there's a need to get a solution right now. But I dislike it, since I consider `net/url' a toy in terms of functionality, and #6 means duplicating that toy only to solve a problem temporarily. On Mon, Jun 20, 2011 at 5:57 AM, Eli Barzilay e...@barzilay.org wrote: Does anyone have any objection to dropping the unitized interface for `net/url'? Specifically, did anyone ever used it for any purpose other than making up an `ssl:*' variant of the library? I'm looking into making it deal properly with ssl connections, and I think that the right way to do it is by making the code dispatch to the plain tcp functions or the ssl versions based on the scheme of the input url. 1. Looking at the code, there are only two tcp functions used (`tcp-connect' and `tcp-abandon-port'), so eliminating the unit interface and just hooking things up so that an https scheme uses the ssl functions is relatively easy. 2. Another possibly solution is to make the `net/url-unit' import two tcp units, one for plain connections and one for https connextions. The problem with that is that it still breaks compatibility since the imports are different. 3. Yet another solution is to make it do the same thing it does now, but for https urls it will always use the ssl bindings. This means that you can still parameterize the code over the tcp functions, but https urls bypass that parameterization and use the ssl things directly. I dislike #2 since it's making things even more hairy in the unit sense, and I don't think that that's a good direction. I dislike #3 since it feels like a bad hack. -- ((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 -- ((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] net/url and https
Two minutes ago, Neil Van Dyke wrote: I also think that Eli's option #1 could be done without breaking backward-compatibility, but I'm not sure it's worth the effort in code and documentation, and I don't want to discourage him moving forward with #1 by making the task harder than it has to be. Heh, I just thought about a way to do that, which is likely what you're thinking of: * `net/url-unit' and `net/url-sig' stay the same. Code that uses them works as before. * `net/url' becomes the (non-unit, of course) library that does dispatching over https with an ssl connection. This might work, but would be very odd. Specifically, the description of `net/url-unit' will need to mumble something about creating a result that is *not* like `net/url' in that there is no such dispatch. Backwards compatible, but IMO very ugly. But perhaps it's worth it? -- ((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] net/url and https
On Sun, Jun 19, 2011 at 3:47 PM, Eli Barzilay e...@barzilay.org wrote: Two minutes ago, Neil Van Dyke wrote: I also think that Eli's option #1 could be done without breaking backward-compatibility, but I'm not sure it's worth the effort in code and documentation, and I don't want to discourage him moving forward with #1 by making the task harder than it has to be. Heh, I just thought about a way to do that, which is likely what you're thinking of: * `net/url-unit' and `net/url-sig' stay the same. Code that uses them works as before. * `net/url' becomes the (non-unit, of course) library that does dispatching over https with an ssl connection. This might work, but would be very odd. Specifically, the description of `net/url-unit' will need to mumble something about creating a result that is *not* like `net/url' in that there is no such dispatch. Backwards compatible, but IMO very ugly. But perhaps it's worth it? I don't have a strong opinion about which option is best. I don't have much code that deals with URLs at all (and let's be blunt; it's _all_ hobby code). And I don't understand units enough to comment on anything involving them. I do feel strongly that Racket should have a way to deal with https reasonably painlessly. I also think that Eli is right about the awkwardness of the current interface -- in order to get the status code from the response, I have to parse the headers myself, which seems silly. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] net/url and https
+1 to that sentiment. I think this whole conversation is meant to be about how do we best get from here to there. The question pending is how much is it reasonable to break code that might use more obscure parts of the current api. I'm taking the relatively hard-line stance that we should not break any of it (even without really knowing how much of it exists), partly just because I think preserving backwards compatibility (esp. for core libraries) is important and partly because there is not yet a authoritative response of the form well, please just go use this well-designed library instead available yet. Robby On Mon, Jun 20, 2011 at 9:52 AM, Eric Hanchrow eric.hanch...@gmail.com wrote: On Sun, Jun 19, 2011 at 3:47 PM, Eli Barzilay e...@barzilay.org wrote: Two minutes ago, Neil Van Dyke wrote: I also think that Eli's option #1 could be done without breaking backward-compatibility, but I'm not sure it's worth the effort in code and documentation, and I don't want to discourage him moving forward with #1 by making the task harder than it has to be. Heh, I just thought about a way to do that, which is likely what you're thinking of: * `net/url-unit' and `net/url-sig' stay the same. Code that uses them works as before. * `net/url' becomes the (non-unit, of course) library that does dispatching over https with an ssl connection. This might work, but would be very odd. Specifically, the description of `net/url-unit' will need to mumble something about creating a result that is *not* like `net/url' in that there is no such dispatch. Backwards compatible, but IMO very ugly. But perhaps it's worth it? I don't have a strong opinion about which option is best. I don't have much code that deals with URLs at all (and let's be blunt; it's _all_ hobby code). And I don't understand units enough to comment on anything involving them. I do feel strongly that Racket should have a way to deal with https reasonably painlessly. I also think that Eli is right about the awkwardness of the current interface -- in order to get the status code from the response, I have to parse the headers myself, which seems silly. _ 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] net/url and https
It seems really bad form to take away the only option (it is the only option when using net/url, right?) existing code has for using ssl in order to provide a new way that isn't even something we consider the final say. No one seems to be actually taking the position of wanting to scuttle the unitized interface, but if someone were to, I think a survey of planet would be in order. Robby On Mon, Jun 20, 2011 at 10:29 AM, Eli Barzilay e...@barzilay.org wrote: Three minutes ago, Robby Findler wrote: +1 to that sentiment. I think this whole conversation is meant to be about how do we best get from here to there. The question pending is how much is it reasonable to break code that might use more obscure parts of the current api. I'm taking the relatively hard-line stance that we should not break any of it (even without really knowing how much of it exists), partly just because I think preserving backwards compatibility (esp. for core libraries) is important and partly because there is not yet a authoritative response of the form well, please just go use this well-designed library instead available yet. FWIW, I'm not convinced by the first point -- especially given that it's about a unitized interface in net/*, and I'd like to see them all go away together with undusting some of the code. But I am fine with hacking around it given the second point. -- ((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] net/url and https
About a minute ago, Robby Findler wrote: It seems really bad form to take away the only option (it is the only option when using net/url, right?) existing code has for using ssl in order to provide a new way that isn't even something we consider the final say. Yes, that's exactly the point that I'm fine with. No one seems to be actually taking the position of wanting to scuttle the unitized interface, but if someone were to, I think a survey of planet would be in order. That would be fine. (And yes, this is mostly OT here.) -- ((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
