- web-devel - Haskell.org

happstack code reloading
by Asafe Ribeiro 19 Mar '12

19 Mar '12

Hi, Since one extra parameters was added to the plugin lambda my hmt code does no update when I refresh the page. As my code is in hierarchical modules , I tried the hack of changing System.Plugin.Make.build but to no sucess. Maybe am I missing something? {-# LANGUAGE CPP, TemplateHaskell,NoOverloadedStrings #-} module Main where import Control.Monad(msum) import Happstack.Server import Control.Monad.IO.Class(liftIO) import qualified Page as P import qualified Handler as H #define DESENVOLVIMENTO --plugins #ifdef DESENVOLVIMENTO import Happstack.Server.Plugins.Dynamic #else import Happstack.Server.Plugins.Static #endif main = do dev <- initPlugins simpleHTTP nullConf $ do decodeBody (defaultBodyPolicy "/tmp/" 106496 106496 106496) msum [ $(withServerPart 'H.user) dev devHandler , dir "book" $ $(withServerPart 'H.book) dev devHandler } where devHandler = (\ _ handler -> handler)

2 1

WAI routing?
by Stephen Paul Weber 18 Mar '12

18 Mar '12

I looked around, but could not find a lot of routing packages for WAI. There is wai-routes, but QuasiQuote makes me nervous. So, I hacked together a very simple router (attached). It works, though it is not efficient for large routing tables (it just does a linear scan over all possible routes in the worst case). I'm curious: (a) what are other people using? (b) are there glaringly stupid things I've done in my code? Thanks :) -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph

5 8

WAI and ^C
by Stephen Paul Weber 17 Mar '12

17 Mar '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 My simple WAI apps will not die when I hit ^C, but when I use Scotty, ^C seems to work fine. I've read through the Scotty code and do not see anything that would cause this. Any tips? - -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPZTv0AAoJENEcKRHOUZze7CkQAMz6Hm9szR8td15Nc67uq1HD lYVsAkPnrwk3vPkLbzYmnVxIjkaXejVXS7GDT/snSHFA/JjxWsQxL4EoDhHjqVOB zSJFutGXPO8yPUSSy2B6NVFLeXG8f+l+8sf+SEq0N4xdq3gpdMfb6J+BoHJ/MkW9 E0CEAWHlOFkePuBL3L18KWcZpaFXVpcrWr8SNv1/ZfIDgo3NYX9Yz2sfjGzuBnDq da6uAPwkEtNHJTCDNS47OZf8jsqi9yVH5xSuQ388WzD3oK1uXl79nRhOsptXGm/b 2xehxCnkFeW/KALvFl6zzlL4pzMSt2u/FnhFOIfhFHs+A2ZJfzJwl0nN/9Af5Vqe Rfx6jQyKOMgvjNp2f3ng9BCfgcj9J7UjpLmjBBqtaTWeGVY+Fx9LNYIeiPK4oFLb 8OMaPbVCU93Fz+3yUSily3rw4nH+/7e8fOksUnZAd1UTThIvL7n9rjZlu2Pg+My8 8G410tMSabGPagkTkm682E1gaW8aHLhsWvCcNFaknElYso13aUxBFN5TcivnnxSh qf0Hpic3G9/AqGhUmoEgC/HPq7LTeZk4o3cfplUedsyvLrTW8Fv3AwIcvh16Y5UQ CW8WVzpoZEUIwUnbeZKLmPsJVACw+e2Sv8PUPpMXOR2bH5YNThWelhDeW+Pyo1M4 7q3E422kOUIHXjlDDL2b =Hd77 -----END PGP SIGNATURE-----

1 0

ANN, WARNING: new boomerang 1.3.0 silently breaks your code
by Jeremy Shaw 04 Mar '12

04 Mar '12

I just uploaded boomerang-1.3.0. The only change is that 'anyString' no longer has an implied 'eos'. It is common to want to write: > rPair . anyString </> anyString to parse, ["foo","bar"] to ("foo","bar") or to unparse ("foo","bar") to ["foo","bar"]. however, that did not work before because anyString implied eos. So you actually had to write the less obvious: > rPair . anyString . anyString to get similar behavior. I have changed 'anyString' so that it no longer implies 'eos', which means that the first example now works as expected. Unfortunately, it means that any parsers currently using anyString will (probably) start failing. There is also a second downside. The new behavior of: > rPair . anyString . anyString is somewhat ill defined. That is because unparse will convert ("foo","bar") to ["foobar"]. But when you try to parse ["foobar"], you get ("foobar",""). In general you should always follow 'anyString' by 'eos' or </>. Unfortunately, I do not see a way to enforce that at compile time. Something to think about for boomerang 2 though. - jeremy

1 0

A trouble with hamlet quasiquoter
by Dmitry Vyal 24 Feb '12

24 Feb '12

Greetings, I'm trying to write a custom Yesod field for displaying a list of words. I copied the code from textareaField and played with it. Unfortunately, I'm getting a rather strange error message from the compiler. What's I'm doing wrong? data GenTask = GenTask { gtWords :: [String], gtNumResults :: Int } blank :: (Monad m, RenderMessage master FormMessage) => (Text -> Either FormMessage a) -> [Text] -> m (Either (SomeMessage master) (Maybe a)) blank _ [] = return $ Right Nothing blank _ ("":_) = return $ Right Nothing blank f (x:_) = return $ either (Left . SomeMessage) (Right . Just) $ f x textListField = Field { fieldParse = blank $ Right . map T.unpack . T.words , fieldView = \theId name theClass val isReq -> addHamlet [hamlet|\ <textarea id="#{theId}" name="#{name}" :not (null theClass):class="#{T.intercalate " " theClass}" type="text" :isReq:required=""> #{either id (T.pack . unwords) val} |] } gtAForm = GenTask <$> areq textListField "List of words" Nothing <*> areq intField "Number of results to show" (Just 10) [1 of 1] Compiling Main ( src/Web.hs, interpreted ) src/Web.hs:42:9: Exception when trying to run compile-time code: "\ <textarea id="#{theId}" name="#{name}" :not (null theClass):class="#{T.intercalate " " theClass}" type="text" :isReq:required=""> #{either id (T.pack . unwords) val} " (line 2, column 143): unexpected "(" expecting "}" Code: Language.Haskell.TH.Quote.quoteExp hamlet "\\\n<textarea id=\"#{theId}\" name=\"#{name}\" :not (null theClass):class=\"#{T.intercalate \" \" theClass}\" type=\"text\" :isReq:required=\"\"> #{either id (T.pack . unwords) val}\n" Failed, modules loaded: none.

1 0

simple-sendfile v0.2.1
by Kazu Yamamoto 15 Feb '12

15 Feb '12

Hello, I have released simple-sendfile v0.2.1. I made two changes: 1) Eugene Crosser kindly pointed out that old simple-senfile cannot work well in a certain Linux environment. This is because simple-senfile call "sendfile64()" which is inherited from the sendfile package. He told me that using "sendfile()" is a right way. 2) Fallback implementation switched from enumerator to Conduit. If you find any problems, please let me know. Eugene, thank you again! --Kazu

1 0

Re: [web-devel] [Haskell-cafe] network-2.3.0.10 compiled for ghc 7.4.1 windows
by Johan Tibell 13 Feb '12

13 Feb '12

Version 2.3.0.11 released. On Mon, Feb 13, 2012 at 9:58 AM, Holger Reinhardt <hreinhardt(a)gmail.com>wrote: > Did as requested and everything seems to work fine. Test suite also passes: > > Test Cases Total > Passed 10 10 > Failed 0 0 > Total 10 10 > Test suite simple: PASS > > > > 2012/2/13 Johan Tibell <johan.tibell(a)gmail.com> > >> I've merged and pushed the changes to the "stable" branch on GitHub. If >> someone could verify that it works fine on Windows, I'll make another >> release. >> >> In addition to running whatever program you're interested in, also run: >> >> cabal clean >> autoreconf >> cabal configure --enable-tests >> cabal build >> cabal test >> >> All tests should pass. >> >> -- Johan >> >> >> On Wed, Feb 8, 2012 at 11:04 AM, Johan Tibell <johan.tibell(a)gmail.com>wrote: >> >>> I will merge this as soon as I get back from vacation. >>> On Feb 8, 2012 8:54 AM, "Holger Reinhardt" <hreinhardt(a)gmail.com> wrote: >>> >>>> Having discussed the issue privately with Alberto, I've found another >>>> bug and updated my pull request [1]. Using that code it should be possible >>>> to build the network library on Windows using MSys on GHC 7.4.1. >>>> >>>> [1] https://github.com/haskell/network/pull/25 >>>> >>>> 2012/2/8 Alberto G. Corona <agocorona(a)gmail.com> >>>> >>>>> yes i did it,. >>>>> >>>>> the error is as follows: >>>>> >>>>> shop.exe: NetworkSocket.hsc:(948,3)-(1007,23): Non-exhaustive patterns >>>>> in case >>>>> >>>>> I will download network form hackage and will do it form the >>>>> beginning. . >>>>> >>>>> >>>>> >>>>> 2012/2/8 Holger Reinhardt <hreinhardt(a)gmail.com>: >>>>> > Did you run "cabal clean" before rebuilding with Git Bash? And can >>>>> you post >>>>> > the exact runtime error you get? >>>>> > >>>>> > 2012/2/8 Alberto G. Corona <agocorona(a)gmail.com> >>>>> > >>>>> >> I switched to Git bash and the runtime error produced by the library >>>>> >> is the same. >>>>> >> This error may be produced because the configuration it does not >>>>> >> detect the netwiorkin related includes such is socket.h. This does >>>>> not >>>>> >> exist neither in the ghc installation neither in GIT/Mingw >>>>> >> >>>>> >> >>>>> >> 2012/2/7 Holger Reinhardt <hreinhardt(a)gmail.com>: >>>>> >> > I just use the version of MSys that is included with Git [1]. >>>>> This puts >>>>> >> > a >>>>> >> > "Git bash" icon on your desktop which you can then use to build >>>>> the >>>>> >> > network >>>>> >> > library. >>>>> >> > >>>>> >> > [1] http://code.google.com/p/msysgit/ >>>>> >> > >>>>> >> > >>>>> >> > 2012/2/7 Alberto G. Corona <agocorona(a)gmail.com> >>>>> >> >> >>>>> >> >> Nothing bur a long history of failures. The problem is the >>>>> >> >> configuration and versioning of MinGW and MSys. This is a >>>>> nighmare. >>>>> >> >> >>>>> >> >> 2012/2/7 Holger Reinhardt <hreinhardt(a)gmail.com>: >>>>> >> >> > Oh you are using Cygwin. I'm using MSys so this is why I cannot >>>>> >> >> > reproduce >>>>> >> >> > your problem. Is there anything preventing you from using MSys? >>>>> >> >> > >>>>> >> >> > >>>>> >> >> > 2012/2/7 Alberto G. Corona <agocorona(a)gmail.com> >>>>> >> >> >> >>>>> >> >> >> The "problem" this time is in "Configure" : >>>>> >> >> >> >>>>> >> >> >> case "$host" in >>>>> >> >> >> *-mingw32) >>>>> >> >> >> EXTRA_SRCS="cbits/initWinSock.c, cbits/winSockErr.c, >>>>> >> >> >> cbits/asyncAccept.c" >>>>> >> >> >> EXTRA_LIBS=ws2_32 >>>>> >> >> >> CALLCONV=stdcall ;; >>>>> >> >> >> *-solaris2*) >>>>> >> >> >> EXTRA_SRCS="cbits/ancilData.c" >>>>> >> >> >> EXTRA_LIBS="nsl, socket" >>>>> >> >> >> CALLCONV=ccall ;; >>>>> >> >> >> *) >>>>> >> >> >> EXTRA_SRCS="cbits/ancilData.c" >>>>> >> >> >> EXTRA_LIBS= >>>>> >> >> >> CALLCONV=ccall ;; >>>>> >> >> >> esac >>>>> >> >> >> >>>>> >> >> >> >>>>> >> >> >> >>>>> >> >> >> Since I´m cross-compiling with cygwin, the variable Host does >>>>> not >>>>> >> >> >> contain ¨*-muingw32" but "i686-pc-cygwin" >>>>> >> >> >> >>>>> >> >> >> changing the case , the library incorporates the lost C coded >>>>> files. >>>>> >> >> >> >>>>> >> >> >> Now the library links fine win imported, but there is a >>>>> runtime >>>>> >> >> >> error: >>>>> >> >> >> >>>>> >> >> >> NetworkSocket.hsc:(948,3)-(1007,23): Non-exhaustive patterns >>>>> in case >>>>> >> >> >> >>>>> >> >> >> maybe it is due to some other preprocessor directive mismatch >>>>> >> >> >> >>>>> >> >> >> >>>>> >> >> >> 2012/2/7 Holger Reinhardt <hreinhardt(a)gmail.com>: >>>>> >> >> >> > Did you also change the files in the /cbits/ folder? >>>>> Because they >>>>> >> >> >> > also >>>>> >> >> >> > check >>>>> >> >> >> > for HAVE_WINSOCK_H. >>>>> >> >> >> > >>>>> >> >> >> > >>>>> >> >> >> > 2012/2/7 Alberto G. Corona <agocorona(a)gmail.com> >>>>> >> >> >> >> >>>>> >> >> >> >> The code is evolving and none of the versions match >>>>> exactily with >>>>> >> >> >> >> the >>>>> >> >> >> >> patch, but substituting HAVE_WINSOCK by HAVE WINSOCK2 in >>>>> these >>>>> >> >> >> >> files >>>>> >> >> >> >> solves the compilation problem at least in the network >>>>> 2.3.0.10 >>>>> >> >> >> >> version from hackage. >>>>> >> >> >> >> >>>>> >> >> >> >> However it produces the same undefined references when this >>>>> >> >> >> >> library >>>>> >> >> >> >> is >>>>> >> >> >> >> imported in my application. It seems that some object code >>>>> is not >>>>> >> >> >> >> included in the final library. I verified that at least >>>>> some of >>>>> >> >> >> >> these >>>>> >> >> >> >> undefined references correspond with C code in the >>>>> source, but >>>>> >> >> >> >> somehow this is not included in the object library.... >>>>> >> >> >> >> >>>>> >> >> >> >> 2012/2/7 Johan Tibell <johan.tibell(a)gmail.com>: >>>>> >> >> >> >> > Note that there are two branches on github, master and >>>>> stable. >>>>> >> >> >> >> > You >>>>> >> >> >> >> > want >>>>> >> >> >> >> > the >>>>> >> >> >> >> > latter. >>>>> >> >> >> >> > >>>>> >> >> >> >> > On Feb 7, 2012 8:23 AM, "Alberto G. Corona" >>>>> >> >> >> >> > <agocorona(a)gmail.com> >>>>> >> >> >> >> > wrote: >>>>> >> >> >> >> >> >>>>> >> >> >> >> >> This is quite different. >>>>> >> >> >> >> >> I don´t know how but I was looking at some other older >>>>> patch >>>>> >> >> >> >> >> around >>>>> >> >> >> >> >> the same issue and I supposed that it was the one >>>>> refered by >>>>> >> >> >> >> >> Yohan >>>>> >> >> >> >> >> Tibell. >>>>> >> >> >> >> >> >>>>> >> >> >> >> >> I´ll try your patch. >>>>> >> >> >> >> >> >>>>> >> >> >> >> >> Thanks!. >>>>> >> >> >> >> >> >>>>> >> >> >> >> >> 2012/2/7 Holger Reinhardt <hreinhardt(a)gmail.com>: >>>>> >> >> >> >> >> > Hi, >>>>> >> >> >> >> >> > >>>>> >> >> >> >> >> > (I submitted the patch that Johan linked to) >>>>> >> >> >> >> >> > Network/Socket/Internal.hsc has the following code: >>>>> >> >> >> >> >> > >>>>> >> >> >> >> >> > #if defined(WITH_WINSOCK) || defined(cygwin32_HOST_OS) >>>>> >> >> >> >> >> > type CSaFamily = (#type unsigned short) >>>>> >> >> >> >> >> > #elif defined(darwin_HOST_OS) >>>>> >> >> >> >> >> > type CSaFamily = (#type u_char) >>>>> >> >> >> >> >> > #else >>>>> >> >> >> >> >> > type CSaFamily = (#type sa_family_t) >>>>> >> >> >> >> >> > #endif >>>>> >> >> >> >> >> > >>>>> >> >> >> >> >> > You have patched this part to always use 'unsigned >>>>> short'. >>>>> >> >> >> >> >> > But >>>>> >> >> >> >> >> > the >>>>> >> >> >> >> >> > real >>>>> >> >> >> >> >> > issue is that WITH_WINSOCK is not defined, even >>>>> though it >>>>> >> >> >> >> >> > should >>>>> >> >> >> >> >> > be. The >>>>> >> >> >> >> >> > reason for this lies in include/HsNet.h: >>>>> >> >> >> >> >> > >>>>> >> >> >> >> >> > #if defined(HAVE_WINSOCK_H) && >>>>> !defined(cygwin32_HOST_OS) >>>>> >> >> >> >> >> > # define WITH_WINSOCK 1 >>>>> >> >> >> >> >> > #endif >>>>> >> >> >> >> >> > >>>>> >> >> >> >> >> > The problem here is that it checks for >>>>> HAVE_WINSOCK_H, but >>>>> >> >> >> >> >> > the >>>>> >> >> >> >> >> > configure >>>>> >> >> >> >> >> > script never defines this variable. Instead it >>>>> >> >> >> >> >> > defines HAVE_WINSOCK2_H. >>>>> >> >> >> >> >> > It >>>>> >> >> >> >> >> > seems that the network library used Winsock1 in the >>>>> past and >>>>> >> >> >> >> >> > in >>>>> >> >> >> >> >> > the >>>>> >> >> >> >> >> > transition to Winsock2 someone forgot to change a few >>>>> of the >>>>> >> >> >> >> >> > #ifdefs. >>>>> >> >> >> >> >> > >>>>> >> >> >> >> >> > My patch just changes all occurences of HAVE_WINSOCK_H >>>>> >> >> >> >> >> > to HAVE_WINSOCK2_H. >>>>> >> >> >> >> >> > You might want to try that and report back if it >>>>> works for >>>>> >> >> >> >> >> > you. >>>>> >> >> >> >> >> > >>>>> >> >> >> >> >> > 2012/2/7 Alberto G. Corona <agocorona(a)gmail.com> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> Hi Johan, >>>>> >> >> >> >> >> >> The patch is not for the current version of network >>>>> and the >>>>> >> >> >> >> >> >> code >>>>> >> >> >> >> >> >> is >>>>> >> >> >> >> >> >> quite different. Basically it is necesary to define >>>>> this >>>>> >> >> >> >> >> >> variable >>>>> >> >> >> >> >> >> as >>>>> >> >> >> >> >> >> "unsigned short" that is the thing intended in the >>>>> patch. >>>>> >> >> >> >> >> >> however >>>>> >> >> >> >> >> >> I >>>>> >> >> >> >> >> >> put it by brute force, without regard of the >>>>> prerpocessor >>>>> >> >> >> >> >> >> directives. >>>>> >> >> >> >> >> >> With this change the code compiles well with: >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> http://neilmitchell.blogspot.com/2010/12/installing-haskell-network-library… >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> However my compiled library lack the methods defined >>>>> as >>>>> >> >> >> >> >> >> foreign. >>>>> >> >> >> >> >> >> I´ll >>>>> >> >> >> >> >> >> keep trying. >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> 2012/2/6 Johan Tibell <johan.tibell(a)gmail.com>: >>>>> >> >> >> >> >> >> > Hi, >>>>> >> >> >> >> >> >> > >>>>> >> >> >> >> >> >> > Someone recently contributed a fix that should make >>>>> >> >> >> >> >> >> > network >>>>> >> >> >> >> >> >> > build >>>>> >> >> >> >> >> >> > with >>>>> >> >> >> >> >> >> > 7.4: https://github.com/haskell/network/pull/25 >>>>> >> >> >> >> >> >> > >>>>> >> >> >> >> >> >> > Can you see if that works for you? I haven't yet >>>>> had time >>>>> >> >> >> >> >> >> > to >>>>> >> >> >> >> >> >> > merge >>>>> >> >> >> >> >> >> > and >>>>> >> >> >> >> >> >> > release that fix (I'm on vacation.) >>>>> >> >> >> >> >> >> > >>>>> >> >> >> >> >> >> > -- Johan >>>>> >> >> >> >> >> >> > >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> _______________________________________________ >>>>> >> >> >> >> >> >> Haskell-Cafe mailing list >>>>> >> >> >> >> >> >> Haskell-Cafe(a)haskell.org >>>>> >> >> >> >> >> >> http://www.haskell.org/mailman/listinfo/haskell-cafe >>>>> >> >> >> >> >> > >>>>> >> >> >> >> >> > >>>>> >> >> >> > >>>>> >> >> >> > >>>>> >> >> > >>>>> >> >> > >>>>> >> > >>>>> >> > >>>>> > >>>>> > >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe(a)haskell.org >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>>> >>>> >> >

1 1

Re: [web-devel] [Haskell-cafe] network-2.3.0.10 compiled for ghc 7.4.1 windows
by Johan Tibell 13 Feb '12

13 Feb '12

I will merge this as soon as I get back from vacation. On Feb 8, 2012 8:54 AM, "Holger Reinhardt" <hreinhardt(a)gmail.com> wrote: > Having discussed the issue privately with Alberto, I've found another bug > and updated my pull request [1]. Using that code it should be possible to > build the network library on Windows using MSys on GHC 7.4.1. > > [1] https://github.com/haskell/network/pull/25 > > 2012/2/8 Alberto G. Corona <agocorona(a)gmail.com> > >> yes i did it,. >> >> the error is as follows: >> >> shop.exe: NetworkSocket.hsc:(948,3)-(1007,23): Non-exhaustive patterns in >> case >> >> I will download network form hackage and will do it form the beginning. . >> >> >> >> 2012/2/8 Holger Reinhardt <hreinhardt(a)gmail.com>: >> > Did you run "cabal clean" before rebuilding with Git Bash? And can you >> post >> > the exact runtime error you get? >> > >> > 2012/2/8 Alberto G. Corona <agocorona(a)gmail.com> >> > >> >> I switched to Git bash and the runtime error produced by the library >> >> is the same. >> >> This error may be produced because the configuration it does not >> >> detect the netwiorkin related includes such is socket.h. This does not >> >> exist neither in the ghc installation neither in GIT/Mingw >> >> >> >> >> >> 2012/2/7 Holger Reinhardt <hreinhardt(a)gmail.com>: >> >> > I just use the version of MSys that is included with Git [1]. This >> puts >> >> > a >> >> > "Git bash" icon on your desktop which you can then use to build the >> >> > network >> >> > library. >> >> > >> >> > [1] http://code.google.com/p/msysgit/ >> >> > >> >> > >> >> > 2012/2/7 Alberto G. Corona <agocorona(a)gmail.com> >> >> >> >> >> >> Nothing bur a long history of failures. The problem is the >> >> >> configuration and versioning of MinGW and MSys. This is a nighmare. >> >> >> >> >> >> 2012/2/7 Holger Reinhardt <hreinhardt(a)gmail.com>: >> >> >> > Oh you are using Cygwin. I'm using MSys so this is why I cannot >> >> >> > reproduce >> >> >> > your problem. Is there anything preventing you from using MSys? >> >> >> > >> >> >> > >> >> >> > 2012/2/7 Alberto G. Corona <agocorona(a)gmail.com> >> >> >> >> >> >> >> >> The "problem" this time is in "Configure" : >> >> >> >> >> >> >> >> case "$host" in >> >> >> >> *-mingw32) >> >> >> >> EXTRA_SRCS="cbits/initWinSock.c, cbits/winSockErr.c, >> >> >> >> cbits/asyncAccept.c" >> >> >> >> EXTRA_LIBS=ws2_32 >> >> >> >> CALLCONV=stdcall ;; >> >> >> >> *-solaris2*) >> >> >> >> EXTRA_SRCS="cbits/ancilData.c" >> >> >> >> EXTRA_LIBS="nsl, socket" >> >> >> >> CALLCONV=ccall ;; >> >> >> >> *) >> >> >> >> EXTRA_SRCS="cbits/ancilData.c" >> >> >> >> EXTRA_LIBS= >> >> >> >> CALLCONV=ccall ;; >> >> >> >> esac >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Since I´m cross-compiling with cygwin, the variable Host does not >> >> >> >> contain ¨*-muingw32" but "i686-pc-cygwin" >> >> >> >> >> >> >> >> changing the case , the library incorporates the lost C coded >> files. >> >> >> >> >> >> >> >> Now the library links fine win imported, but there is a runtime >> >> >> >> error: >> >> >> >> >> >> >> >> NetworkSocket.hsc:(948,3)-(1007,23): Non-exhaustive patterns in >> case >> >> >> >> >> >> >> >> maybe it is due to some other preprocessor directive mismatch >> >> >> >> >> >> >> >> >> >> >> >> 2012/2/7 Holger Reinhardt <hreinhardt(a)gmail.com>: >> >> >> >> > Did you also change the files in the /cbits/ folder? Because >> they >> >> >> >> > also >> >> >> >> > check >> >> >> >> > for HAVE_WINSOCK_H. >> >> >> >> > >> >> >> >> > >> >> >> >> > 2012/2/7 Alberto G. Corona <agocorona(a)gmail.com> >> >> >> >> >> >> >> >> >> >> The code is evolving and none of the versions match exactily >> with >> >> >> >> >> the >> >> >> >> >> patch, but substituting HAVE_WINSOCK by HAVE WINSOCK2 in these >> >> >> >> >> files >> >> >> >> >> solves the compilation problem at least in the network >> 2.3.0.10 >> >> >> >> >> version from hackage. >> >> >> >> >> >> >> >> >> >> However it produces the same undefined references when this >> >> >> >> >> library >> >> >> >> >> is >> >> >> >> >> imported in my application. It seems that some object code is >> not >> >> >> >> >> included in the final library. I verified that at least some >> of >> >> >> >> >> these >> >> >> >> >> undefined references correspond with C code in the source, >> but >> >> >> >> >> somehow this is not included in the object library.... >> >> >> >> >> >> >> >> >> >> 2012/2/7 Johan Tibell <johan.tibell(a)gmail.com>: >> >> >> >> >> > Note that there are two branches on github, master and >> stable. >> >> >> >> >> > You >> >> >> >> >> > want >> >> >> >> >> > the >> >> >> >> >> > latter. >> >> >> >> >> > >> >> >> >> >> > On Feb 7, 2012 8:23 AM, "Alberto G. Corona" >> >> >> >> >> > <agocorona(a)gmail.com> >> >> >> >> >> > wrote: >> >> >> >> >> >> >> >> >> >> >> >> This is quite different. >> >> >> >> >> >> I don´t know how but I was looking at some other older >> patch >> >> >> >> >> >> around >> >> >> >> >> >> the same issue and I supposed that it was the one refered >> by >> >> >> >> >> >> Yohan >> >> >> >> >> >> Tibell. >> >> >> >> >> >> >> >> >> >> >> >> I´ll try your patch. >> >> >> >> >> >> >> >> >> >> >> >> Thanks!. >> >> >> >> >> >> >> >> >> >> >> >> 2012/2/7 Holger Reinhardt <hreinhardt(a)gmail.com>: >> >> >> >> >> >> > Hi, >> >> >> >> >> >> > >> >> >> >> >> >> > (I submitted the patch that Johan linked to) >> >> >> >> >> >> > Network/Socket/Internal.hsc has the following code: >> >> >> >> >> >> > >> >> >> >> >> >> > #if defined(WITH_WINSOCK) || defined(cygwin32_HOST_OS) >> >> >> >> >> >> > type CSaFamily = (#type unsigned short) >> >> >> >> >> >> > #elif defined(darwin_HOST_OS) >> >> >> >> >> >> > type CSaFamily = (#type u_char) >> >> >> >> >> >> > #else >> >> >> >> >> >> > type CSaFamily = (#type sa_family_t) >> >> >> >> >> >> > #endif >> >> >> >> >> >> > >> >> >> >> >> >> > You have patched this part to always use 'unsigned >> short'. >> >> >> >> >> >> > But >> >> >> >> >> >> > the >> >> >> >> >> >> > real >> >> >> >> >> >> > issue is that WITH_WINSOCK is not defined, even though it >> >> >> >> >> >> > should >> >> >> >> >> >> > be. The >> >> >> >> >> >> > reason for this lies in include/HsNet.h: >> >> >> >> >> >> > >> >> >> >> >> >> > #if defined(HAVE_WINSOCK_H) && !defined(cygwin32_HOST_OS) >> >> >> >> >> >> > # define WITH_WINSOCK 1 >> >> >> >> >> >> > #endif >> >> >> >> >> >> > >> >> >> >> >> >> > The problem here is that it checks for HAVE_WINSOCK_H, >> but >> >> >> >> >> >> > the >> >> >> >> >> >> > configure >> >> >> >> >> >> > script never defines this variable. Instead it >> >> >> >> >> >> > defines HAVE_WINSOCK2_H. >> >> >> >> >> >> > It >> >> >> >> >> >> > seems that the network library used Winsock1 in the past >> and >> >> >> >> >> >> > in >> >> >> >> >> >> > the >> >> >> >> >> >> > transition to Winsock2 someone forgot to change a few of >> the >> >> >> >> >> >> > #ifdefs. >> >> >> >> >> >> > >> >> >> >> >> >> > My patch just changes all occurences of HAVE_WINSOCK_H >> >> >> >> >> >> > to HAVE_WINSOCK2_H. >> >> >> >> >> >> > You might want to try that and report back if it works >> for >> >> >> >> >> >> > you. >> >> >> >> >> >> > >> >> >> >> >> >> > 2012/2/7 Alberto G. Corona <agocorona(a)gmail.com> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Hi Johan, >> >> >> >> >> >> >> The patch is not for the current version of network and >> the >> >> >> >> >> >> >> code >> >> >> >> >> >> >> is >> >> >> >> >> >> >> quite different. Basically it is necesary to define >> this >> >> >> >> >> >> >> variable >> >> >> >> >> >> >> as >> >> >> >> >> >> >> "unsigned short" that is the thing intended in the >> patch. >> >> >> >> >> >> >> however >> >> >> >> >> >> >> I >> >> >> >> >> >> >> put it by brute force, without regard of the >> prerpocessor >> >> >> >> >> >> >> directives. >> >> >> >> >> >> >> With this change the code compiles well with: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> http://neilmitchell.blogspot.com/2010/12/installing-haskell-network-library… >> >> >> >> >> >> >> >> >> >> >> >> >> >> However my compiled library lack the methods defined as >> >> >> >> >> >> >> foreign. >> >> >> >> >> >> >> I´ll >> >> >> >> >> >> >> keep trying. >> >> >> >> >> >> >> >> >> >> >> >> >> >> 2012/2/6 Johan Tibell <johan.tibell(a)gmail.com>: >> >> >> >> >> >> >> > Hi, >> >> >> >> >> >> >> > >> >> >> >> >> >> >> > Someone recently contributed a fix that should make >> >> >> >> >> >> >> > network >> >> >> >> >> >> >> > build >> >> >> >> >> >> >> > with >> >> >> >> >> >> >> > 7.4: https://github.com/haskell/network/pull/25 >> >> >> >> >> >> >> > >> >> >> >> >> >> >> > Can you see if that works for you? I haven't yet had >> time >> >> >> >> >> >> >> > to >> >> >> >> >> >> >> > merge >> >> >> >> >> >> >> > and >> >> >> >> >> >> >> > release that fix (I'm on vacation.) >> >> >> >> >> >> >> > >> >> >> >> >> >> >> > -- Johan >> >> >> >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> >> >> >> >> Haskell-Cafe mailing list >> >> >> >> >> >> >> Haskell-Cafe(a)haskell.org >> >> >> >> >> >> >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> > >> >> >> > >> >> > >> >> > >> > >> > >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >

1 1

[ANNOUNCE] fb package, bindings to Facebook's API
by Felipe Almeida Lessa 13 Feb '12

13 Feb '12

Hello, everyone! I'm pleased to finally announce the fb package, a Haskell-only package that provides bindings to Facebook's API. This package is sponsored by my employer, which will soon enough be able to become the copyright holder of all of our open source contributions. http://hackage.haskell.org/package/fb It's by no means complete, but we thrive to be as correct as possible and to turn API errors into type errors caught at compile time. Right now the current version is fb 0.7.2. While this is the first announcement, this package is already being actively used by Facebook authentication code on Yesod (yesod-auth-fb package) and internally at my day job's projects. Hope you find it useful! =) Cheers, -- Felipe.

1 0

Re: [web-devel] How to use Yesod.Auth.HashDB?
by Michael Lazarev 12 Feb '12

12 Feb '12

Thanks, and sorry about posting it here. It looks I did this by old memory, back when Yesod was mainly discussed in web-devel list. 2012/2/11 Greg Weber <greg(a)gregweber.info>: > This question seems Yesod specific - I am forwarding to the Yesod mail list. > > On Fri, Feb 10, 2012 at 2:59 PM, Michael Lazarev > <lazarev.michael(a)gmail.com> wrote: >> Hello everybody! >> >> In one app I develop, users will not register by themselves. Instead, >> they will be added to the system and assigned roles by administrator. >> For that case, HashDB auth plugin looked the right choice for me. >> >> TL;DR: The setup proposed in Yesod.Auth.HashDB documentation didn't >> work for me. Finally I found the solution. I wonder if putting User >> entity definition in Yesod.Auth.HashDB module is a good idea. >> >> There are three reasons I post this: to publish my solution for >> anybody having the same problem, to ask a question if I am doing it >> right, and, last but not least, to submit a feedback to Yesod authors. [Skipped]

1 0