- Haskell-Cafe - Haskell.org

AES on 32-bit system
by Michael Snoyman 08 Feb '11

08 Feb '11

Hi everyone, Does anyone else have trouble installing the AES package on a 32-bit system? My system at home installs it just fine, but my VPS chokes with the following error messages (plus a bunch of warnings): cbits/ctr_inc.c:11:0: error: 'uint_64t' undeclared (first use in this function) cbits/ctr_inc.c:11:0: error: (Each undeclared identifier is reported only once cbits/ctr_inc.c:11:0: error: for each function it appears in.) cbits/ctr_inc.c:11:0: error: 'ctr' undeclared (first use in this function) cbits/ctr_inc.c:11:0: error: expected expression before ')' token It's actually for this very reason that I'm still maintaining the OpenSSL backend for http-enumerator: I think the tls package is stable enough now to be used in production environments (kudos to Vincent by the way). However, I can't use it in production if I can't build one of its dependencies. This bug is also preventing me from adding some nice features to http-enumerator, such as checking validity of SSL certificates. Anyone have any thoughts? Michael

4 7

coding style vs. foreign interfaces
by Donn Cave 08 Feb '11

08 Feb '11

I just noticed a handful of spelling errors, in a package that isn't all that obscure. Enums from a C interface - data AlarmingNews = -- ALARM_STUFF_WENT_WRONG AlarmStufWentWrong | ... (oops, should have been Stuff, not Stuf.) Who can blame the guy, after all, because this renaming work is not only kind of a mind-numbing and trivial job, it's quite gratuitous. Of the people who are apt to be interested, a sizeable percentage already will be familiar with ALARM_STUFF_WENT_WRONG, and as the "nice" Haskell spelling offers no practical advantage at all, it's purely a waste of their time to translate from one to the other. Is screenflicker_frequency() going to be screenFlickerFrequency, or screenflickerFrequency? gah! I know it's enshrined in many years of convention by now, but if anyone might ever consider the matter again, my vote would be, when adopting foreign interfaces essentially unchanged, that the spellings also be preserved to whatever extent practicable. thanks! Donn Cave

4 4

Building doc for yesod-json
by Magnus Therning 07 Feb '11

07 Feb '11

Michael, I've now gotten part of the way through the *long* list of dependencies for yesod 0.7.0, and I'm stuck on yesod-json. It's the documentation that fails actually, but I'm not sure why it would: dist/build/tmp20668/Yesod/Json.hs:4:6: parse error on input `-- ^ Convert from a JSON value' It's the very first bit in that file: module Yesod.Json ( -- ^ Convert from a JSON value defaultLayoutJson Do you have any clue as to why this would fail? I should probably mention that I'm compiling this on a system with GHC 6.12.3. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus

4 4

http-enumerator: redirects, streaming and keep-alive
by Michael Snoyman 07 Feb '11

07 Feb '11

Hi all, There are a number of new feature requests for http-enumerator, and I wanted to discuss some possible API changes with everyone: * Allow keep-alive requests, which will reuse the same connection. * Allow client code to determine whether it accepts a server's SSL certificate. * Allow the request body to be an Enumerator so we can send large request bodies without using lazy IO. This is already implemented via streamingHttp, but it would make more sense to modify the Request datatype to replace L.ByteString with (Int, Enumerator ByteString IO ()). * Fix redirect behavior. It seems that the right thing to do is change a POST into a GET and remove the request body for a 303, and resend the same request for all other 3xx codes. However, when using an Enumerator for the request body, it is not guaranteed that we can resend an Enumerator. For addressing the last two, my plan is to: * Change the Request datatype as mentioned, but provide a convenience method for converting a lazy ByteString into a (Int, Enumerator ByteString IO ()). * Implement redirecting as I have described, and explain in the documentation that automatic redirecting can only work with Enumerators that can be run multiple times. AFAIK, this works with most standard Enumerators, such as enumFile, and with the helper function I will provide to convert lazy ByteStrings to Enumerators. * Remove streamingHttp, as it will no longer be necessary. As far as keep-alive goes, I still need to do a bit more research, but my basic idea (with credit to Bryan O'Sullivan): * http (and family) will all take an extra argument, Maybe Manager. * Manager will be an abstract type that will keep an MVar (Map (Host, Port, IsSecure) Socket). * If http is provided with a Manager, then it uses the Socket available in the Manager. If none is available, it creates a new Socket and places it in the Manager. * If http is *not* provided with a Manager, then it creates a new socket and closes it before returning. * There will be a newManager :: IO Manager, and a closeManager :: Manager -> IO (), which closes all Sockets in the Manager and empties out the inner Map. Some open questions are: * Who is responsible to recover if a server is no longer responding on a Socket from the Manager: http or the client code? I would assume http. * I haven't fully thought through how this will work with secure connections: most likely in addition to storing the Socket in the Manager I will need to store some certificate data. And speaking of certificates, the main concern I have here is data types: since http-enumerator can use either tls or OpenSSL, there isn't a single certificate datatype I can use. If someone wants to help out and write some code to convert an OpenSSL X509 datatype into a Certificate from the certificate package (which tls uses), I will be very grateful. Assuming we had such a unified datatype, I would recommend changing Request's secure record to be Certificate -> IO Bool, where returning True means the certificate is accepted and False means it is rejected. To get the current functionality of trusting any certificate, we would use (const $ return True). Any thoughts? Michael

4 8

ANN: case-insensitive-0.1
by Bas van Dijk 07 Feb '11

07 Feb '11

Dear all, I had this old module laying around that I wrote some time ago. I dusted it off and uploaded it to Hackage: http://hackage.haskell.org/package/case-insensitive-0.1 The package provides the module Data.CaseInsensitive which exports the CI type constructor which can be parameterised by a string-like type like: String, ByteString, Text, etc.. Comparisons of values of the resulting type are then insensitive to cases. It is my hope that one day packages like snap-core[1], http-types[2] or wai[3] all use this common way of making strings case insensitive. Regards, Bas [1] http://hackage.haskell.org/packages/archive/snap-core/latest/doc/html/Data-… [2] http://hackage.haskell.org/packages/archive/http-types/0.3.0/doc/html/Netwo… [3] http://hackage.haskell.org/packages/archive/wai/latest/doc/html/Network-Wai…

2 2

hsc2hs not using foreign.c types?
by Edward Amsden 07 Feb '11

07 Feb '11

I'm just now trying to figure out how to use the FFI, along with hsc2hs. When I use the #type ... directive in my .hsc files to pull in a c typedef that is aliased to an integer, it puts in "Word32" instead of CInt. I was hoping to use this in my foreign imports: Two questions: - Can I declare a foreign import of a c function that takes a c 'int' to have a 'word32' input type in Haskell and will that function correctly? - Why doesn't hsc2hs use 'CInt' instead? -- Edward Amsden Undergraduate Computer Science Rochester Institute of Technology www.edwardamsden.com

1 0

Extending GHCi
by C K Kashyap 07 Feb '11

07 Feb '11

Hi, I am looking for a way to extend GHCI such that I can do something like this $ ghci GHCi, version 6.12.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. Prelude> startMyFunction Prelude> startMyFunction will do a forkIO and listen on a network port for interaction with a remote process and will drop back to GHCI prompt where I can invoke haskell functions that'll control the way the interaction with the remote process occurs. Can this be done? Regards, Kashyap

4 10

fetching BLOBs
by Dmitry Olshansky 07 Feb '11

07 Feb '11

Hello, cafe, Is there a way to get BLOB fields from OracleDB using Takusen? What about other possibilities (through HDBC - ODBC)? Dima

1 0

Re: [Haskell-cafe] Extending GHCi
by Kashyap C 07 Feb '11

07 Feb '11

I tried a fresh install of Haskell platform on my Vista box and I find that starting the thread does not return to the prompt. Is there some setting I need to do? Sent from my Windows Phone ------------------------------ From: Steffen Schuldenzucker Sent: Monday, 7 February 2011 6:46 PM To: C K Kashyap Cc: Haskell Cafe Subject: Re: [Haskell-cafe] Extending GHCi On 02/07/2011 12:45 PM, C K Kashyap wrote: > $ ghci > GHCi, version 6.12.3: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > Loading package ffi-1.0 ... linking ... done. > Prelude> :m +Data.IORef Control.Concurrent Control.Monad > Prelude Data.IORef Control.Concurrent Control.Monad> msg <- newIORef > "Hello" > Prelude Data.IORef Control.Concurrent Control.Monad> let echo = > forever $ readIORef msg >>= putStrLn >> threadDelay 3000000 > Prelude Data.IORef Control.Concurrent Control.Monad> t <- forkIO echo > Hello > Prelude Data.IORef Control.Concurrent Control.Monad> Hello > Hello > writeIORefHello msg "World" > Prelude Data.IORef Control.Concurrent Control.Monad> World > World > On my mac, this works..but on Linux, the moment I do t <- forkIO ... , it starts off a thread in the foreground and does not return to the prompt. Strange. Works for me (ghc 6.12.1 on Debian squeeze).

1 0

Re: [Haskell-cafe] Byte Histogram
by John Lato 07 Feb '11

07 Feb '11

> > From: Ivan Lazar Miljenovic <ivan.miljenovic(a)gmail.com> > > On 7 February 2011 12:30, wren ng thornton <wren(a)freegeek.org> wrote: > > On 2/6/11 4:53 PM, Ivan Lazar Miljenovic wrote: > >> > >> On 7 February 2011 08:12, Alexey Khudyakov<alexey.skladnoy(a)gmail.com> > >> ?wrote: > >>> > >>> Also there is a container-classes package which provide set of type > class > >>> for containers. > >>> > >>> [1] http://hackage.haskell.org/package/container-classes > >> > >> Don't use that package: it's broken. ?I did start on a re-write that > >> works (and there are similar libraries around that I believe do work), > >> but gave up because it was a) too fiddly, and b) I decided that the > >> use case I had for them wasn't worth it (as it would just make that > >> library more complicated and difficult to use, possibly also less > >> efficient). ?If anyone wants it I can certainly send them what I've > >> got though. > > > > Any chance you could push a 0.0.0.1 version which tells people this, so > that > > they know to avoid it? > > Didn't think about that; I'll try to do so tonight. > Perhaps a better approach would be to ask the hackage maintainer (Ross Patterson, if I'm not mistaken) to deprecate container-classes. John

2 1