- web-devel - Haskell.org

How to use Yesod.Auth.HashDB?
by Michael Lazarev 10 Feb '12

10 Feb '12

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. In a freshly scaffolded sqlite-based setup made with Yesod-0.10.1, I did changes recommended in Yesod.Auth.HashDB haddock. See these instructions here: http://hackage.haskell.org/packages/archive/yesod-auth/0.8.1/doc/html/Yesod… Here you can see how I applied these instructions to my project: https://gist.github.com/1793058 . That led to errors shown in the same gist below. These errors do make sense: if User is defined in Yesod.Auth.HashDB, I have to delete the duplicate of definition from my config/models file. But then I get another error: `Model.hs:13:1: Not in scope: type constructor or class `UserGeneric'` Ok, fair enough again. Because now I don't define User entity in config/models, Model.hs must take it from HashDB module. Let's add `import Yesod.Auth.HashDB` to Model.hs file. This fixes the error, but then another one appears: Foundation.hs:158:19: Couldn't match expected type `FCCS -> [AuthPlugin FCCS]' with actual type `[t0]' In the expression: [authHashDB (Just . UniqueUser)] In an equation for `authPlugins': authPlugins = [authHashDB (Just . UniqueUser)] In the instance declaration for `YesodAuth FCCS' Ok, the underscore must be added after definition of authPlugins instance method. Of course, it should be there, even if it's missing in example on top of Yesod.Auth.HashDB haddock. Now, another error: Devel application launched, listening on port 3000 devel.hs: Table not found: User Exit code: ExitFailure 1 Table not found. I checked the database, there is "user" table there. What can this be? Let's swap these lines in Application.hs Now they will be like this: Database.Persist.Store.runPool dbconf (runMigration migrateUsers) p Database.Persist.Store.runPool dbconf (runMigration migrateAll) p Before they were in reverse order. Let's see that happens: Devel application launched, listening on port 3000 Migrating: CREATE TABLE "User"("id" INTEGER PRIMARY KEY,"username" VARCHAR NOT NULL,"password" VARCHAR NOT NULL,"salt" VARCHAR NOT NULL,CONSTRAINT "UniqueUser" UNIQUE ("username")) devel.hs: user error (SQLite3 returned ErrorError while attempting to perform prepare "CREATE TABLE \"User\"(\"id\" INTEGER PRIMARY KEY,\"username\" VARCHAR NOT NULL,\"password\" VARCHAR NOT NULL,\"salt\" VARCHAR NOT NULL,CONSTRAINT \"UniqueUser\" UNIQUE (\"username\"))": table "User" already exists) Exit code: ExitFailure 1 Other error, but no luck yet. What if we drop the table "User"? Migrating: CREATE TABLE "User"("id" INTEGER PRIMARY KEY,"username" VARCHAR NOT NULL,"password" VARCHAR NOT NULL,"salt" VARCHAR NOT NULL,CONSTRAINT "UniqueUser" UNIQUE ("username")) devel.hs: Table not found: User Exit code: ExitFailure 1 What if we delete the database altogether? `devel.hs: Table not found: User` Of course it is not found. But what can I do to fix this? Surely I don't know what I am doing here. Any clarifications? And then it occurred to me that even if I managed to get it working that way, this still will be not quite right. What if I will decide to add some fields to User entity later? I can't do it if User is exported from HashDB. And I really plan to add one field just after I make this work. The "role" field to manage permissions. So, instead, I copied the definition from HashDB source to my config/models: User username Text Eq password Text salt Text UniqueUser username And then copied the instance definition to Model.hs: instance HashDBUser (UserGeneric backend) where userPasswordHash = Just . userPassword userPasswordSalt = Just . userSalt setSaltAndPasswordHash s h u = u { userSalt = s , userPassword = h } To eliminate conflicts, in Model.hs the import was restricted to `import Yesod.Auth.HashDB (HashDBUser(..))` In Application.hs it was removed along with migration command, and Foundation.hs it was narrowed to `import Yesod.Auth.HashDB (authHashDB, getAuthIdHashDB)` Finally, it worked. You may want to look at https://gist.github.com/1793594 for the set of changes needed to achieve this. Anyway, I can't get rid of the feeling that there is some "right" method to do this, that I either overlooked, or couldn't come up with myself. Any advice?

1 0

[conduit 0.2.x] generalizing sourceIO?
by Bardur Arantsson 08 Feb '12

08 Feb '12

Hi all, I was just wondering - would it be reasonable to generalize sourceIO :: ResourceIO m => IO state -> (state -> IO ()) -> (state -> m (SourceIOResult output)) -> Source m output to sourceIO :: ResourceIO m => IO state -> (state -> IO ()) -> (state -> m (state, SourceIOResult output)) -> Source m output so that the state could be "updated" while producing results? I've found there are a few situations where the lack of "state threading" is forcing me to use MVars where it would actually be a lot nicer and simpler to just thread an accumulator. AFAICT from the sourceIO implementation there shouldn't really be any problem with doing this. Am I overlooking something? Regards,

3 5

Re: [web-devel] [Haskell-cafe] network-2.3.0.10 compiled for ghc 7.4.1 windows
by Alberto G. Corona 08 Feb '12

08 Feb '12

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 >> >> >> >> >> > >> >> >> >> >> > >> >> >> > >> >> >> > >> >> > >> >> > >> > >> > > >

1 0

Re: [web-devel] [Haskell-cafe] network-2.3.0.10 compiled for ghc 7.4.1 windows
by Alberto G. Corona 07 Feb '12

07 Feb '12

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 >> >> >> >> > >> >> >> >> > >> >> > >> >> > >> > >> > > >

1 0

Re: [web-devel] [Haskell-cafe] network-2.3.0.10 compiled for ghc 7.4.1 windows
by Alberto G. Corona 07 Feb '12

07 Feb '12

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 >> >> > >> >> > > >

1 0

Re: [web-devel] [Haskell-cafe] network-2.3.0.10 compiled for ghc 7.4.1 windows
by Alberto G. Corona 07 Feb '12

07 Feb '12

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 > >

2 2

network-2.3.0.10 compiled for ghc 7.4.1 windows
by Alberto G. Corona 07 Feb '12

07 Feb '12

Hi, After some pains, I compiled the package Network. sa_family_t is needed in network.Socket.Internal.asc and MinGW seems that it has no such variable defined. I share here the package with the compiled binaries included: http://skydrive.live.com/?cid=2F229EB748D4CBA3&id=2F229EB748D4CBA3%21105

2 2

ANNOUNCE MFlow-0.0.3 an Application Server for stateful web apps with statically typed widget combinators
by Alberto G. Corona 07 Feb '12

07 Feb '12

Hi Haskellers I I´m happy to announce the first version of MFlow http://hackage.haskell.org/package/MFlow MFlow permits the execution of web applications in a procedural form, that is, with multiple requests-response interactions in a single procedure. MFlow stores the execution state, manage timeouts, shutdown and restart the procedure on demand at the point of execution, even after server stop. These services are transparent for the programmer. The other aspect of MFlow are combinators for the definition of widgets and formlets that can be mixed freely with HTML formatting and produce statically typed values using the "traditional" formlet/applicative approach. There are bindings for the package XHtml, so no need to learn new paradigms/scripting/formatting.. Console and window oriented apps are possible. Out of te box serialization in files permits very rapid prototyping, but any backend can be used . MFlow (MessageFlow) was created initially as the user interface for the Workflow package . Currently is an alpha version. It has only basic authentication but I plan to inprove it for serious applications. I upload this version just in case anyone wants to play with it.

1 1

WAI/Warp 1.1 released
by Michael Snoyman 05 Feb '12

05 Feb '12

Hi all, I've just released WAI and Warp 1.1, which is a minor (but breaking) change to 1.0. The differences are: * We now use a Source instead of a BufferedSource for requestBody * Support for conduit 0.2 This release includes updates to the entire WAI family of packages. As usual, there are various bug fixes/performance enhancements throughout the code base. Michael

2 4

Abstracting permissions with Yesod
by Felipe Almeida Lessa 03 Feb '12

03 Feb '12

Hello, everyone! I'm going to try creating a blog and my first post is dedicated to how I am writing my isAuthorized function: http://blog.felipe.lessa.nom.br/?p=7 I'd be thrilled if you could tell me if you like the idea! Something similar could be done on Yesod 0.10, either on yesod-core or on the scaffold. I didn't try writing some generic code yet because I'd like to gather comments here first. Cheers, =) -- Felipe.

4 7