February 2012 - web-devel

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

Adding Html formatting to formlets
by Alberto G. Corona 03 Feb '12

03 Feb '12

I came across the idea that is easy to define additional operators to Text.FormLets for adding custom HTML formatting. Had anyone tried that? For example to enclose the Prod formulary in a Table using Text.XHtml tags. I defined additional operators <<< and <++ for enclosing and prepending Html to a formLet, respectively: >data Prod= Prod{pname :: String, pprice :: Int} >getProd= table <<< ( > Prod <$> tr <<< (td << "enter the name" <++ td <<< getString (pname <$> mp)) > <*> tr <<< (td << "enter the price" <++ td <<< getInt ( pprice <$> mp))) even: >p << "paragraph" <++ getProd ++> (more Html stuff) is possible or even it is possible an operator <+> > getProd <+> someOtherStuff to return Either Prod OtherStuff I did it in my own version of FormLets. So It is too heavy to put here a running example. It is part of a package that I will upload soon to hackage. This also may work for embedding formLets in other haskell HTML formats besides Text.XHtml.

2 2

FYI: conduit 0.1 is buggy?
by Kazu Yamamoto 02 Feb '12

02 Feb '12

Hello, This is just for your information. I have run the Migthy web server based on conduit 0.1/WAI 1.0 on a real world server for severals days. And I found Mighty dies sometimes. I suspect that conduit 0.1 is buggy. I'm not sure but the socket leak problem might affect. I compiled Mighty with conduit 0.2 and run it to watch what will happen. --Kazu

2 1