Re: [Haskell-cafe] haskell platform - mac lion - installation error
XCode 4.3 does not install the Unix development environment by default anymore. Go to the XCode preferences, and then to the Download pane, there should be an Install button for that. Aristid 2012/3/10 Peter smeldr...@gmail.com Hello - I'm a new user, having some trouble installing the Haskell Platform (2011.4.0.0 64bit.pkg) on a Macbook Pro (10.7.3). I installed Xcode 4.3.1 (4E1019), then the Haskell Platform. When I double-click on the Platform package icon, I get an installation dialogue with an error message reading Developer Tools Missing - Please install Xcode developer tools first. Are Xcode developer tools something distinct from Xcode itself? I'm mystified by this error message. Any assistance would be greatly appreciated - thank you. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell implementation of a database?
Are you looking for something like acid-state? Aristid Am 17.02.2012 07:57 schrieb Vasili I. Galchin vigalc...@gmail.com: Hello, I have been looking through Hackage database for a Haskell implementation of a database(not a binding) but couldn't find anything. Probably it was under my nose?? Vasili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [haskell-cafe] Some reflections on Haskell
In the source file, the Haddock documentation is there, no idea why it doesn't show up. Am 15.02.2012 04:00 schrieb Doug McIlroy d...@cs.dartmouth.edu: Markus: What about hoogle/hayoo and hackage? Antoine: Do you have any links to examples that we should imitate? Hackage is notionally similar to the Java API documentation at http://www.oracle.com/technetwork/java/javase/documentation/ But Hackage Documentation pages typically only give syntax, while Java pages invariably summarize semantics. This makes a world of difference. The quality of the summaries bespeaks a lot of editorial attention above and beyond culling annotations from source code. Considerable care has been taken in describing the GHC library at http://www.haskell.org/ghc/docs/ but even there one can find absolute mystery entries like http://www.haskell.org/ghc/docs/latest/html/libraries/haskell98-2.0.0.1/Locale.html Doug It is hard to find one's way in this ecosystm. It needn't be, as Java illustrates. To my mind Java's great contribution to the world is its library index--light years ahead of typical documentation one finds at haskell.org, which lacks the guiding hand of a flesh-and-blood librarian. In this matter, it seems, industrial curation can achieve clarity more easily than open source. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Contributing to http-conduit
I would say: if it adds no package dependencies, put it right in. Aristid Am 06.02.2012 22:09 schrieb Myles C. Maxfield myles.maxfi...@gmail.com: After all these commits have been flying around, I have yet another question: the 'HTTP' package defines Network.Browser which is a State monad which keeps state about a browser (i.e. a cookie jar, a proxy, redirection parameters, etc.) It would be pretty straightforward to implement this kind of functionality on top of http-conduit. I was originally going to do it and release it as its own package, but it may be beneficial to add such a module to the existing http-conduit package. Should I add it in to the existing package, or release it as its own package? --Myles On Mon, Feb 6, 2012 at 12:15 AM, Michael Snoyman mich...@snoyman.comwrote: Just an FYI for everyone: Myles sent an (incredibly thorough) pull request to handle cookies: https://github.com/snoyberg/http-conduit/pull/13 Thanks! On Sun, Feb 5, 2012 at 8:20 AM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: 1. The spec defines a grammar for the attributes. They're in uppercase. 2. Yes - 1.3 is the first version that lists DiffTime as an instance of RealFrac (so I can use the 'floor' function to pull out the number of seconds to render it) 3. I'll see what I can do. --Myles On Sat, Feb 4, 2012 at 9:06 PM, Michael Snoyman mich...@snoyman.com wrote: Looks good, a few questions/requests: 1. Is there a reason to upper-case all the attributes? 2. Is the time = 1.3 a requirements? Because that can cause a lot of trouble for people. 3. Can you send the patch as a Github pull request? It's easier to track that way. Michael On Sat, Feb 4, 2012 at 1:21 AM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: Here is the patch to Web.Cookie. I didn't modify the tests at all because they were already broken - they looked like they hadn't been updated since SetCookie only had 5 parameters. I did verify by hand that the patch works, though. Thanks, Myles On Thu, Feb 2, 2012 at 11:26 PM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: Alright, I'll make a small patch that adds 2 fields to SetCookie: setCookieMaxAge :: Maybe DiffTime setCookieSecureOnly :: Bool I've also gotten started on those cookie functions. I'm currently writing tests for them. @Chris: The best advice I can give is that Chrome (what I'm using as a source on all this) has the data baked into a .cc file. However, they have directions in a README and a script which will parse the list and generate that source file. I recommend doing this. That way, the Haskell module would have 2 source files: one file that reads the list and generates the second file, which is a very large source file that contains each element in the list. The list should export `elem`-type queries. I'm not quite sure how to handle wildcards that appear in the list - that part is up to you. Thanks for helping out with this :] --Myles On Thu, Feb 2, 2012 at 10:53 PM, Michael Snoyman mich...@snoyman.com wrote: Looks good to me too. I agree with Aristid: let's make the change to cookie itself. Do you want to send a pull request? I'm also considering making the SetCookie constructor hidden like we have for Request, so that if in the future we realize we need to add some other settings, it doesn't break the API. Chris: I would recommend compiling it into the module. Best bet would likely being converting the source file to Haskell source. Michael On Fri, Feb 3, 2012 at 6:32 AM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: Alright. After reading the spec, I have these questions / concerns: The spec supports the Max-Age cookie attribute, which Web.Cookies doesn't. I see two possible solutions to this. The first is to have parseSetCookie take a UTCTime as an argument which will represent the current time so it can populate the setCookieExpires field by adding the Max-Age attribute to the current time. Alternatively, that function can return an IO SetCookie so it can ask for the current time by itself (which I think is inferior to taking the current time as an argument). Note that the spec says to prefer Max-Age over Expires. Add a field to SetCookie of type Maybe DiffTime which represents the Max-Age attribute Cookie code should be aware of the Public Suffix List as a part of its domain verification. The cookie code only needs to be able to tell if a specific string is in the list (W.Ascii - Bool) I propose making an entirely unrelated package, public-suffix-list, with a module Network.PublicSuffixList, which will expose this function, as well as functions about parsing the list
Re: [Haskell-cafe] Contributing to http-conduit
Is it possible to have both an Expires and a Max-age? If not, maybe you should make a type like data Expiry = NeverExpires | ExpiresAt UTCTime | ExpiresIn DiffTime 2012/2/4 Myles C. Maxfield myles.maxfi...@gmail.com: Here is the patch to Web.Cookie. I didn't modify the tests at all because they were already broken - they looked like they hadn't been updated since SetCookie only had 5 parameters. I did verify by hand that the patch works, though. Thanks, Myles On Thu, Feb 2, 2012 at 11:26 PM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: Alright, I'll make a small patch that adds 2 fields to SetCookie: setCookieMaxAge :: Maybe DiffTime setCookieSecureOnly :: Bool I've also gotten started on those cookie functions. I'm currently writing tests for them. @Chris: The best advice I can give is that Chrome (what I'm using as a source on all this) has the data baked into a .cc file. However, they have directions in a README and a script which will parse the list and generate that source file. I recommend doing this. That way, the Haskell module would have 2 source files: one file that reads the list and generates the second file, which is a very large source file that contains each element in the list. The list should export `elem`-type queries. I'm not quite sure how to handle wildcards that appear in the list - that part is up to you. Thanks for helping out with this :] --Myles On Thu, Feb 2, 2012 at 10:53 PM, Michael Snoyman mich...@snoyman.com wrote: Looks good to me too. I agree with Aristid: let's make the change to cookie itself. Do you want to send a pull request? I'm also considering making the SetCookie constructor hidden like we have for Request, so that if in the future we realize we need to add some other settings, it doesn't break the API. Chris: I would recommend compiling it into the module. Best bet would likely being converting the source file to Haskell source. Michael On Fri, Feb 3, 2012 at 6:32 AM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: Alright. After reading the spec, I have these questions / concerns: The spec supports the Max-Age cookie attribute, which Web.Cookies doesn't. I see two possible solutions to this. The first is to have parseSetCookie take a UTCTime as an argument which will represent the current time so it can populate the setCookieExpires field by adding the Max-Age attribute to the current time. Alternatively, that function can return an IO SetCookie so it can ask for the current time by itself (which I think is inferior to taking the current time as an argument). Note that the spec says to prefer Max-Age over Expires. Add a field to SetCookie of type Maybe DiffTime which represents the Max-Age attribute Cookie code should be aware of the Public Suffix List as a part of its domain verification. The cookie code only needs to be able to tell if a specific string is in the list (W.Ascii - Bool) I propose making an entirely unrelated package, public-suffix-list, with a module Network.PublicSuffixList, which will expose this function, as well as functions about parsing the list itself. Thoughts? Web.Cookie doesn't have a secure-only attribute. Adding one in is straightforward enough. The spec describes cookies as a property of HTTP, not of the World Wide Web. Perhaps Web.Cookie should be renamed? Just a thought; it doesn't really matter to me. As for Network.HTTP.Conduit.Cookie, the spec describes in section 5.3 Storage Model what fields a Cookie has. Here is my proposal for the functions it will expose: receiveSetCookie :: SetCookie - Req.Request m - UTCTime - Bool - CookieJar - CookieJar Runs the algorithm described in section 5.3 Storage Model The UTCTime is the current-time, the Bool is whether or not the caller is an HTTP-based API (as opposed to JavaScript or anything else) updateCookieJar :: Res.Response a - Req.Request m - UTCTime - CookieJar - (CookieJar, Res.Response a) Applies receiveSetCookie to a Response. The output CookieJar is stripped of any Set-Cookie headers. Specifies True for the Bool in receiveSetCookie computeCookieString :: Req.Request m - CookieJar - UTCTime - Bool - (W.Ascii, CookieJar) Runs the algorithm described in section 5.4 The Cookie Header The UTCTime and Bool are the same as in receiveSetCookie insertCookiesIntoRequest :: Req.Request m - CookieJar - UTCTime - (Req.Request m, CookieJar) Applies computeCookieString to a Request. The output cookie jar has updated last-accessed-times. Specifies True for the Bool in computeCookieString evictExpiredCookies :: CookieJar - UTCTime - CookieJar Runs the algorithm described in the last part of section 5.3 Storage Model This will make the relevant part of 'http' look like: go count req'' cookie_jar'' = do now - liftIO $ getCurrentTime let (req', cookie_jar') =
Re: [Haskell-cafe] Contributing to http-conduit
Sounds good. I think the nicest way to handle maxage would be changing SetCookie, not handling it at parsing time. Aristid Am 03.02.2012 05:35 schrieb Myles C. Maxfield myles.maxfi...@gmail.com: Alright. After reading the spec, I have these questions / concerns: - The spec supports the Max-Age cookie attribute, which Web.Cookies doesn't. - I see two possible solutions to this. The first is to have parseSetCookie take a UTCTime as an argument which will represent the current time so it can populate the setCookieExpires field by adding the Max-Age attribute to the current time. Alternatively, that function can return an IO SetCookie so it can ask for the current time by itself (which I think is inferior to taking the current time as an argument). Note that the spec says to prefer Max-Age over Expires. - Add a field to SetCookie of type Maybe DiffTime which represents the Max-Age attribute - Cookie code should be aware of the Public Suffix Listhttp://mxr.mozilla.org/mozilla-central/source/netwerk/dns/effective_tld_names.dat as a part of its domain verification. The cookie code only needs to be able to tell if a specific string is in the list (W.Ascii - Bool) - I propose making an entirely unrelated package, public-suffix-list, with a module Network.PublicSuffixList, which will expose this function, as well as functions about parsing the list itself. Thoughts? - Web.Cookie doesn't have a secure-only attribute. Adding one in is straightforward enough. - The spec describes cookies as a property of HTTP, not of the World Wide Web. Perhaps Web.Cookie should be renamed? Just a thought; it doesn't really matter to me. As for Network.HTTP.Conduit.Cookie, the spec describes in section 5.3 Storage Model what fields a Cookie has. Here is my proposal for the functions it will expose: - receiveSetCookie :: SetCookie - Req.Request m - UTCTime - Bool - CookieJar - CookieJar - Runs the algorithm described in section 5.3 Storage Model - The UTCTime is the current-time, the Bool is whether or not the caller is an HTTP-based API (as opposed to JavaScript or anything else) - updateCookieJar :: Res.Response a - Req.Request m - UTCTime - CookieJar - (CookieJar, Res.Response a) - Applies receiveSetCookie to a Response. The output CookieJar is stripped of any Set-Cookie headers. - Specifies True for the Bool in receiveSetCookie - computeCookieString :: Req.Request m - CookieJar - UTCTime - Bool - (W.Ascii, CookieJar) - Runs the algorithm described in section 5.4 The Cookie Header - The UTCTime and Bool are the same as in receiveSetCookie - insertCookiesIntoRequest :: Req.Request m - CookieJar - UTCTime - (Req.Request m, CookieJar) - Applies computeCookieString to a Request. The output cookie jar has updated last-accessed-times. - Specifies True for the Bool in computeCookieString - evictExpiredCookies :: CookieJar - UTCTime - CookieJar - Runs the algorithm described in the last part of section 5.3 Storage Model This will make the relevant part of 'http' look like: go count req'' cookie_jar'' = do now - liftIO $ getCurrentTime let (req', cookie_jar') = insertCookiesIntoRequest req'' (evictExpiredCookies cookie_jar'' now) now res' - httpRaw req' manager let (cookie_jar, res) = updateCookieJar res' req' now cookie_jar' case getRedirectedRequest req' (responseHeaders res) (W.statusCode (statusCode res)) of Just req - go (count - 1) req cookie_jar Nothing - return res I plan to not allow for a user-supplied cookieFilter function. If they want that functionality, they can re-implement the redirection-following logic. Any thoughts on any of this? Thanks, Myles On Wed, Feb 1, 2012 at 5:19 PM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: Nope. I'm not. The RFC is very explicit about how to handle cookies. As soon as I'm finished making sense of it (in terms of Haskell) I'll send another proposal email. On Feb 1, 2012 3:25 AM, Michael Snoyman mich...@snoyman.com wrote: You mean you're *not* making this proposal? On Wed, Feb 1, 2012 at 7:30 AM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: Well, this is embarrassing. Please disregard my previous email. I should learn to read the RFC *before* submitting proposals. --Myles On Tue, Jan 31, 2012 at 6:37 PM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: Here are my initial ideas about supporting cookies. Note that I'm using Chrome for ideas since it's open source. Network/HTTP/Conduit/Cookies.hs file Exporting the following symbols: type StuffedCookie = SetCookie A regular SetCookie can have Nothing for its Domain and Path attributes. A StuffedCookie has to have these
Re: [Haskell-cafe] Contributing to http-conduit
The nice thing is that this way, nobody can force me to handle cookies. ;-)
Might be that usage patterns emerge, which we can then codify into
functions later.
Am 25.01.2012 08:09 schrieb Michael Snoyman mich...@snoyman.com:
On Wed, Jan 25, 2012 at 9:01 AM, Myles C. Maxfield
myles.maxfi...@gmail.com wrote:
Sorry, I think I'm still a little confused about this.
From the point of view of a library user, if I use the 'http' function,
but
want to know what final URL I ended up at, I would have to set redirects
to
0, call http, call checkRedirect, and recurse until checkRedirect returns
Nothing (or a count runs out). I would be handling the recursion of
redirects myself.
On one hand, this solution is lightweight and easy to implement in the
library. On the other hand, the caller has to run each individual request
themselves, keeping track of the number of requests (so there isn't an
infinite loop). The loop is already implemented in the http function - I
think it's reasonable to modify the existing loop rather than expect the
caller to re-implement that logic.
However, it's probably just as reasonable to say if you want to know
what
URL you end up at, you have to re-implement your own
redirection-following
logic.
I do agree, however, that including an (possibly long, though explicitly
bounded) [Ascii] along with every request is arbitrary, and probably not
the
best solution. Can you think of a solution which allows the caller to
know
the url chain (or possibly just the last URL - that's the important one)
without having to re-implement the redirection-following logic
themselves?
It sounds like if you had to choose, you would rather force a caller to
re-implement redirection-following rather than include a URL chain in
every
Response. Is this correct?
That's correct. I think knowing the final URL is a fairly arbitrary
requirement, in the same boat as wanting redirect handling without
supporting cookies. These to me fall well within the 20%: most people
won't need them, so the API should not be optimized for them.
There's also the fact that [Ascii] isn't nearly enough information to
properly follow the chain. Next someone's going to want to know if a
request was GET or POST, or whether it was a permanent or temporary
redirect, or the exact text of the location header, or a million other
things involved. If someone wants this stuff, they should reimplement
the redirect logic.
But I don't really see this as being such a burden. If we had the
checkRedirect function, it would look something like:
myHttp req = do
let req' = req { redirectCount = 0 }
res - http req'
case checkRedirect res of
Just req2 - myHttp req2
Nothing - return res
I don't think that's a terrible burden.
Michael
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Contributing to http-conduit
Yeah, a more combinatorial approach to making HTTP requests would be good. So +1 for checkRedirect or anything similar. 2012/1/24 Michael Snoyman mich...@snoyman.com: On Tue, Jan 24, 2012 at 6:57 PM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: On Mon, Jan 23, 2012 at 10:43 PM, Michael Snoyman mich...@snoyman.com wrote: On Tue, Jan 24, 2012 at 8:37 AM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: I have attached a patch to add a redirect chain to the Response datatype. Comments on this patch are very welcome. I thought that this isn't necessary since a client wanting to track all the redirects could just handle them manually by setting the redirect count to 0. It seems like a lot of work to re-implement the redirection-following code, just to know which URL the bytes are coming from. I feel that adding this field makes the library easier to use, but it's your call. If that's the concern, I'd much rather just expose a function to help with dealing with redirects, rather than sticking a rather arbitrary [Ascii] in everyone's Response. I think a function along the lines of: checkRedirect :: Response - Maybe Request would fit the bill, and could be extracted from the current `http` function. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Contributing to http-conduit
Rejecting cookies is not without precedent. If you must force cookie handling upon us, at least make it possible to selectively reject them. Aristid Am 23.01.2012 08:44 schrieb Michael Snoyman mich...@snoyman.com: That's a violation of the spec. Having a server set a cookie and then not really mean it or something along those lines would be invalid. And having a server not set a cookie at all means having this feature would be irrelevant. On Mon, Jan 23, 2012 at 9:42 AM, Aristid Breitkreuz arist...@googlemail.com wrote: Indeed, I disagree on 2. Sometimes there is an API and cookies are just not part of it (and redirects are). Aristid Am 23.01.2012 08:16 schrieb Michael Snoyman mich...@snoyman.com: The only times cookies would be used would be: 1. If you explicitly use it. 2. If you have redirects turned on, and a page that redirects you also sets a cookie. I would think that we would want (2) to be on regardless of user setting, do you disagree? Michael On Mon, Jan 23, 2012 at 8:46 AM, Aristid Breitkreuz arist...@googlemail.com wrote: Just make sure Cookie handling can be disabled completely. Aristid Am 23.01.2012 07:44 schrieb Michael Snoyman mich...@snoyman.com: On Mon, Jan 23, 2012 at 8:31 AM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: 1. Oops - I overlooked the fact that the redirectCount attribute of a Request is exported (it isn't listed on the documentation probably because the constructor itself isn't exported. This seems like a flaw in Haddock...). Silly me. No need to export httpRaw. 2. I think that stuffing many arguments into the 'http' function is ugly. However, I'm not sure that the number of arguments to 'http' could ever reach an unreasonably large amount. Perhaps I have bad foresight, but I personally feel that adding cookies to the http request will be the last thing that we will need to add. Putting a bound on this growth of arguments I completely disagree here. If we'd followed this approach, rawBody, decompress, redirectCount, and checkStatus all would have been arguments. There's a reason we use a settings data type[1] here. [1] http://www.yesodweb.com/blog/2011/10/settings-types makes me more willing to think about this option. On the other hand, using a BrowserAction to modify internal state is very elegant. Which approach do you think is best? I think I'm leaning toward the upper-level Browser module idea. If there was to be a higher-level HTTP library, I would argue that the redirection code should be moved into it, and the only high-level function that the Network.HTTP.Conduit module would export is 'http' (or httpRaw). What do you think about this? I actually don't want to move the redirection code out from where it is right now. I think that redirection *is* a basic part of HTTP. I'd be more in favor of just bundling cookies in with the current API, possibly with the IORef approach I'd mentioned (unless someone wants to give a different idea). Having a single API that provides both high-level and low-level approaches seems like a win to me. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Contributing to http-conduit
Just make sure Cookie handling can be disabled completely. Aristid Am 23.01.2012 07:44 schrieb Michael Snoyman mich...@snoyman.com: On Mon, Jan 23, 2012 at 8:31 AM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: 1. Oops - I overlooked the fact that the redirectCount attribute of a Request is exported (it isn't listed on the documentation probably because the constructor itself isn't exported. This seems like a flaw in Haddock...). Silly me. No need to export httpRaw. 2. I think that stuffing many arguments into the 'http' function is ugly. However, I'm not sure that the number of arguments to 'http' could ever reach an unreasonably large amount. Perhaps I have bad foresight, but I personally feel that adding cookies to the http request will be the last thing that we will need to add. Putting a bound on this growth of arguments I completely disagree here. If we'd followed this approach, rawBody, decompress, redirectCount, and checkStatus all would have been arguments. There's a reason we use a settings data type[1] here. [1] http://www.yesodweb.com/blog/2011/10/settings-types makes me more willing to think about this option. On the other hand, using a BrowserAction to modify internal state is very elegant. Which approach do you think is best? I think I'm leaning toward the upper-level Browser module idea. If there was to be a higher-level HTTP library, I would argue that the redirection code should be moved into it, and the only high-level function that the Network.HTTP.Conduit module would export is 'http' (or httpRaw). What do you think about this? I actually don't want to move the redirection code out from where it is right now. I think that redirection *is* a basic part of HTTP. I'd be more in favor of just bundling cookies in with the current API, possibly with the IORef approach I'd mentioned (unless someone wants to give a different idea). Having a single API that provides both high-level and low-level approaches seems like a win to me. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Contributing to http-conduit
Indeed, I disagree on 2. Sometimes there is an API and cookies are just not part of it (and redirects are). Aristid Am 23.01.2012 08:16 schrieb Michael Snoyman mich...@snoyman.com: The only times cookies would be used would be: 1. If you explicitly use it. 2. If you have redirects turned on, and a page that redirects you also sets a cookie. I would think that we would want (2) to be on regardless of user setting, do you disagree? Michael On Mon, Jan 23, 2012 at 8:46 AM, Aristid Breitkreuz arist...@googlemail.com wrote: Just make sure Cookie handling can be disabled completely. Aristid Am 23.01.2012 07:44 schrieb Michael Snoyman mich...@snoyman.com: On Mon, Jan 23, 2012 at 8:31 AM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: 1. Oops - I overlooked the fact that the redirectCount attribute of a Request is exported (it isn't listed on the documentation probably because the constructor itself isn't exported. This seems like a flaw in Haddock...). Silly me. No need to export httpRaw. 2. I think that stuffing many arguments into the 'http' function is ugly. However, I'm not sure that the number of arguments to 'http' could ever reach an unreasonably large amount. Perhaps I have bad foresight, but I personally feel that adding cookies to the http request will be the last thing that we will need to add. Putting a bound on this growth of arguments I completely disagree here. If we'd followed this approach, rawBody, decompress, redirectCount, and checkStatus all would have been arguments. There's a reason we use a settings data type[1] here. [1] http://www.yesodweb.com/blog/2011/10/settings-types makes me more willing to think about this option. On the other hand, using a BrowserAction to modify internal state is very elegant. Which approach do you think is best? I think I'm leaning toward the upper-level Browser module idea. If there was to be a higher-level HTTP library, I would argue that the redirection code should be moved into it, and the only high-level function that the Network.HTTP.Conduit module would export is 'http' (or httpRaw). What do you think about this? I actually don't want to move the redirection code out from where it is right now. I think that redirection *is* a basic part of HTTP. I'd be more in favor of just bundling cookies in with the current API, possibly with the IORef approach I'd mentioned (unless someone wants to give a different idea). Having a single API that provides both high-level and low-level approaches seems like a win to me. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [web-devel] [ANNOUNCE] First release of crypto-conduit
To use the hash, I have to convert it to a ByteString, and then I suddenly have lost all this safety. I don't really see how there is any real safety gained. That said, just exposing a direct method of getting to that ByteString without cereal (as Thomas proposed) would be an improvement. Aristid 2012/1/8 Vincent Hanquez t...@snarc.org: On 01/08/2012 04:12 AM, Aristid Breitkreuz wrote: Why? I don't actually need the hash object for anything, usually. All I need is the ByteString, and then I need to learn how to use the cereal package to get it... The whole rationale i believe, is having meaningful types associated to your values so that the type checker can do its job. i.e. you don't start mixing a hash (in binary form) and a random piece of file. My only problem with the Serialize instance, is that dependencies (cereal in this case) trickle through to the user of the API, which would be solved by Thomas' suggestion. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [web-devel] [ANNOUNCE] First release of crypto-conduit
And while we're at it, some code to deal with the cumbersome decoding of those hash objects would be nice! Cheers, Aristid Am 07.01.2012 11:07 schrieb Greg Weber g...@gregweber.info: great! I am wondering if you can provide even higher-level APIs for the common case: hash - runResourceT $ hashFile my-file and possibly something that runs the ResourceT transformer: hash - runHashFile my-file On Sat, Jan 7, 2012 at 12:16 AM, Felipe Almeida Lessa felipe.le...@gmail.com wrote: Hello! I'm pleased to announce the first release of crypto-conduit [1]! The crypto-api [2] package provides APIs for many cryptographic operations, such as cryptographic hashes and block ciphers. This new crypto-conduit package allows you to use many of these operations with conduits [3], giving you safe I/O using constant memory and no leaks. As an example, here's how you could get the SHA1 hash a file: import Crypto.Conduit -- from crypto-conduit import Crypto.Hash.SHA1 (SHA1) -- from cryptohash import Data.Conduit -- from conduit import Data.Conduit.Binary (sourceFile) -- from conduit main = do hash - runResourceT $ sourceFile my-file $$ sinkHash print (hash :: SHA1) The code snippet above, despite having only sourceFile ... $$ sinkHash on its core, guarantees that the file handle is not kept open and uses a constant amount of memory. Sweet! Please break this package! Although it comes with a test suite, it has just seen the light of the day. Cheers, =) [1] http://hackage.haskell.org/package/crypto-conduit [2] http://hackage.haskell.org/package/crypto-api [3] http://hackage.haskell.org/package/conduit -- Felipe. ___ web-devel mailing list web-de...@haskell.org http://www.haskell.org/mailman/listinfo/web-devel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [web-devel] [ANNOUNCE] First release of crypto-conduit
Well, how do you get a ByteString from the hash object? Aristid Am 07.01.2012 13:04 schrieb Felipe Almeida Lessa felipe.le...@gmail.com: On Sat, Jan 7, 2012 at 9:12 AM, Aristid Breitkreuz arist...@googlemail.com wrote: And while we're at it, some code to deal with the cumbersome decoding of those hash objects would be nice! I'm sorry, but what do you mean by cumbersome decoding? Cheers, =) -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [web-devel] [ANNOUNCE] First release of crypto-conduit
Yeah and that's annoying IMHO. :) It's not really important though. Aristid Am 07.01.2012 15:39 schrieb Felipe Almeida Lessa felipe.le...@gmail.com: ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [web-devel] [ANNOUNCE] First release of crypto-conduit
2012/1/8 Vincent Hanquez t...@snarc.org: What would you prefer ? At the moment, i'm inclined to someday move cryptohash apis to be similar to crypto-api. i.e. from a result type being a bytestring to an opaque type with serialize/show instance. Why? I don't actually need the hash object for anything, usually. All I need is the ByteString, and then I need to learn how to use the cereal package to get it... So talking purely about convenience, I would prefer hash :: HashType - InputData - ByteString. That would probably not be extensible enough, so I'm not sure how to optimally do it. Aristid ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] porting feed to xml-enumerator
Hi Simon and all, You might want to consider using xml-conduit instead of xml-enumerator. Michael Snoyman has shifted his attention to this new alternative. Cheers, Aristid 2012/1/2 Simon Michael si...@joyful.com: Hi Sigbjorn (and Don), I'm back for another reason. feed leaks and uses a lot of memory due to the xml package. Rather than fix xml I ported feed to xml-enumerator, which is used by yesod and more actively maintained than xml. This seems to have fixed the problem so I'm thinking of uploading this version to hackage as feed-1.0 (which I'll use for rss2irc and hackagebot.) Please let me know whether you agree. Also you might be interested in moving your repo (http://code.galois.com/cgi-bin/gitweb?p=feed.git;a=summary) to github ? This would make it easier to publish my changes, either to the main repo or a branch or fork. Otherwise I'll need to get them to your repo somehow. Thanks again, -Simon On Feb 21, 2011, at 5:14 PM, Simon Michael wrote: thanks for feed. I'm just investigating a bug with rss2irc, and I think I'm seeing problems in the current feed on hackage. It lookas as if there's no way to get item updated date as opposed item published date, and getItemPublishDate actually gets the updated date in the case of an atom feed (http://hackage.haskell.org/packages/archive/feed/0.3.8/doc/html/src/Text-Feed-Query.html#getItemPublishDate). I'd like to contribute a fix. Would you be able to make feed's repo public, eg on darcsden.com or github ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Conduits: Is Source a valid instance of Monad?
Hi all,
As you may have noticed, Michael Snoyman has been working on an
alternative approach to I/O, called conduits. You can find it here:
https://github.com/snoyberg/conduit
When looking at the Source type (explained here:
http://www.yesodweb.com/blog/2011/12/conduits), I noticed that they
seem to behave like lists, and naturally wondered if I could write a
Monad instance for them. But first, let's have a brief look at the
definition of Source:
data SourceResult a = Open a | Closed
data PreparedSource m a = PreparedSource
{ sourcePull :: ResourceT m (SourceResult a)
, sourceClose :: ResourceT m ()
}
newtype Source m a = Source { prepareSource :: ResourceT m
(PreparedSource m a) }
ResourceT deals with resource acquisition and releasing (making sure
that all resources are released), and provides a an abstraction over
IORef/STRef. For our purposes here, ResourceT is probably close enough
to IO.
So now the question again is, can we write a Monad instance for this?
I have been able to write join (concatenate) and return (a source with
a single non-repeated) element.
https://gist.github.com/1525471
I _think_ it behaves properly like a Monad, but I'm not quite sure,
and neither was Michael. Greg Weber then suggested bringing the
question to this forum. What made the question difficult for me is
that this would be a stateful Monad transformer, so I'm not quite sure
how to test the Monad laws properly.
There's a second part to this question: If Source turns out not to be
a Monad, is it possibly a ZipList-like Applicative? And either way,
which is more useful: The list-like or the ziplist-like instances (of
Applicative/Monad)?
Thank you,
Aristid
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
