We recommend that all users of Happstack update to 0.4.1 immediately. Migration from Happstack 0.3 should be trivial. There was one race condition in happstack-state which could cause a state event to fail under heavy congestion.
Happstack is the Haskell Application Server Stack. It is a scalable framework for developing web applications. It is similar in purpose to Django, RoR, Turbogears, Grails, Seaside, etc.
Using less buzzwords, it is a collection of libraries which can be used to develop a self-contained server application which does not require SQL or Apache (though it can integrate with both).
It includes:
* an HTTP server * a rich DSL for deconstructing HTTP Requests and generating Responses * HTML/XML/etc templating via HStringTemplate, HSP, or Text.XHtml * a persistent data store based on user defined Haskell data types with ACID properties and state migration * and more!!
Happstack's modular nature means it is easy to integrate unrelated 3rd party modules such as Pandoc, or to add support for an alternative templating system. Additionally, it does not exclude you from using SQL, or supporting other protocols besides HTTP.
* happstack-contrib has been completely removed. If you were using something in it, please complain on the mailing list. * removed Happstack.Server.S3 -- newer, better maintained S3 libraries are on hackage now * removed unsupported spread-based multimaster support
fileServe:
* now with sendfile() support! On supported platforms sendfile allows files to be served from the disk to the network in a zero-copy fashion. This means faster transfers, less memory and CPU usage, and no file handle leaks. (hopefully). sendfile uses native sendfile() support on Linux, Windows, OS X, and FreeBSD. Other platforms will use a sendfile emulation mode. We recommend that you use sendFile instead of sendFileStrict or sendFileLazy, unless you have specific needs and know some reason why you must use sendFileStrict or sendFileLazy.
* FileServe internals majorly refactored. FileServe now provides a modular way of building your own fileServe-like functions. Also includes functions for serving a single file instead of the contents of a directory.
* added more complete list of mime-types * automatically redirect from foo to foo/ if foo is a directory * filter . and .. from request path, but allow filenames and directories which start with .
happstack-server:
* ServerMonad instance for ErrorT * Added ServerMonad, FilterMonad, and WebMonad for XMLGenT * Added secure flag to cookies. Defaults to False. * fix supportsIPv6 to work with newer versions of network library * simpleHTTPWithSocket + bindPort for H.S.SimpleHTTP (you can use this to start the server as root, bind to the socket, and then drop privileges.) * Fixed Accept-Encoding parser to accepts encodings with a - in them. Added additional tests to acceptEncodingParserTest * fix so basicAuth sets correct response code and headers. * SimpleHTTP: added trailingSlash. Guard which checks that Request URI ends with a / * decode body of PUT requests not just POST * added ifModifiedSince guard * added host and withHost guards to SimpleHTTP (similar to dir and path, but for the requested hostname)
other:
* happstack-state: Correct an embarrassing race condition bug. * happstack-data: Exported getSafeGet and getSafePut * happstack: add state transition code to guestbook (add email to form, handler, and state), and tar of example _local state before transition
experimental:
* happstack-state: now has experimental replication support using Amazon Web Services. This support is disabled by default. This feature is highly experimental, may not work, and may even be completely removed in future versions (though, hopefully not).
THANKS:
Alex Jacobson David Himmelstrup / Lemmih Matthew Elder / mae Antoine Latter Erik Hesselink Pasqualino 'Titto' Assini Nils / McManiaC Thomas Hartman Creighton Hogg / wchogg John MacFarlane Jochem Berndsen / koeien MightByte
And everyone who filed bug reports, tested RC1 and RC2, and anyone else I missed.
src/HJScript/Events.hs:1:0: Warning: Module `Prelude' is deprecated: You are using the old package `base' version 3.x. Future GHC versions will not support base version 3.x. You should update your code to use the new base version 4.x. [ 2 of 26] Compiling HJScript.Monad ( src/HJScript/Monad.hs, dist/build/HJScript/Monad.o )
src/HJScript/Monad.hs:51:10: A pattern match on a GADT requires -XGADTs In the pattern: EmptyBlock In the definition of `mappend': mappend EmptyBlock b = b In the instance declaration for `Monoid (Block ())' cabal: Error: some packages failed to install: HJScript-0.4.5 failed during the building phase. The exception was: ExitFailure 1 =========
So I had to add GADTs to the list of extensions in the cabal file before getting it to work here.
> We recommend that all users of Happstack update to 0.4.1 > immediately. Migration from Happstack 0.3 should be trivial. There was > one race condition in happstack-state which could cause a state event > to fail under heavy congestion.
> Happstack is the Haskell Application Server Stack. It is a scalable > framework for developing web applications. It is similar in purpose to > Django, RoR, Turbogears, Grails, Seaside, etc.
> Using less buzzwords, it is a collection of libraries which can be > used to develop a self-contained server application which does not > require SQL or Apache (though it can integrate with both).
> It includes:
> * an HTTP server > * a rich DSL for deconstructing HTTP Requests and generating > Responses > * HTML/XML/etc templating via HStringTemplate, HSP, or Text.XHtml > * a persistent data store based on user defined Haskell data types > with ACID properties and state migration > * and more!!
> Happstack's modular nature means it is easy to integrate unrelated 3rd > party modules such as Pandoc, or to add support for an alternative > templating system. Additionally, it does not exclude you from using > SQL, or supporting other protocols besides HTTP.
> * happstack-contrib has been completely removed. If you were > using something in it, please complain on the mailing list. > * removed Happstack.Server.S3 -- newer, better maintained S3 > libraries are on hackage now > * removed unsupported spread-based multimaster support
> fileServe:
> * now with sendfile() support! On supported platforms sendfile > allows files to be served from the disk to the network in a > zero-copy fashion. This means faster transfers, less memory and > CPU usage, and no file handle leaks. (hopefully). sendfile uses > native sendfile() support on Linux, Windows, OS X, and > FreeBSD. Other platforms will use a sendfile emulation mode. We > recommend that you use sendFile instead of sendFileStrict or > sendFileLazy, unless you have specific needs and know some reason > why you must use sendFileStrict or sendFileLazy.
> * FileServe internals majorly refactored. FileServe now provides > a modular way of building your own fileServe-like functions. Also > includes functions for serving a single file instead of the > contents of a directory.
> * added more complete list of mime-types > * automatically redirect from foo to foo/ if foo is a directory > * filter . and .. from request path, but allow filenames and > directories which start with .
> happstack-server:
> * ServerMonad instance for ErrorT > * Added ServerMonad, FilterMonad, and WebMonad for XMLGenT > * Added secure flag to cookies. Defaults to False. > * fix supportsIPv6 to work with newer versions of network library > * simpleHTTPWithSocket + bindPort for H.S.SimpleHTTP (you can > use this to start the server as root, bind to the socket, and then > drop privileges.) > * Fixed Accept-Encoding parser to accepts encodings with a - in > them. Added additional tests to acceptEncodingParserTest > * fix so basicAuth sets correct response code and headers. > * SimpleHTTP: added trailingSlash. Guard which checks that > Request URI ends with a / > * decode body of PUT requests not just POST > * added ifModifiedSince guard > * added host and withHost guards to SimpleHTTP (similar to dir > and path, but for the requested hostname)
> other:
> * happstack-state: Correct an embarrassing race condition bug. > * happstack-data: Exported getSafeGet and getSafePut > * happstack: add state transition code to guestbook (add email > to form, handler, and state), and tar of example _local state before > transition
> experimental:
> * happstack-state: now has experimental replication support using > Amazon Web Services. This support is disabled by default. This > feature is highly experimental, may not work, and may even be > completely removed in future versions (though, hopefully not).
> THANKS:
> Alex Jacobson > David Himmelstrup / Lemmih > Matthew Elder / mae > Antoine Latter > Erik Hesselink > Pasqualino 'Titto' Assini > Nils / McManiaC > Thomas Hartman > Creighton Hogg / wchogg > John MacFarlane > Jochem Berndsen / koeien > MightByte
> And everyone who filed bug reports, tested RC1 and RC2, and anyone > else I missed.
On Mon, Dec 21, 2009 at 12:31 AM, <jer...@n-heptane.com> wrote: > Hello,
> That sort of missing symbol error at link time is often (but not always) a > sign that some libraries got recompiled but not others. So there are > references to the old symbol names hanging around.
> I would try to ghc-pkg unregister syb-with-class and everything that depends > on it, and then try cabal install happstack again.
> We have successfully built Happstack with GHC 6.10 on OS X, and GHC 6.12 on > Linux. But, you might be the first to try GHC 6.12 on OS X. However, I am > leaning towards it being something stale on your system from a previous > attempt right now...
Thanks for the tip. That gives me a project for the day.
On Mon, Dec 21, 2009 at 12:31 AM, <jer...@n-heptane.com> wrote: > Hello,
> That sort of missing symbol error at link time is often (but not always) a > sign that some libraries got recompiled but not others. So there are > references to the old symbol names hanging around.
> I would try to ghc-pkg unregister syb-with-class and everything that depends > on it, and then try cabal install happstack again.
No luck! I unregistered everything in my user package db (which is everything but the GHC boot libs) and then did a "caball install happstack-data" and got the same error (eventually!).
I'll pull GHC 6.12 branch head, rebuild and then try again.
> On Mon, Dec 21, 2009 at 12:31 AM, <jer...@n-heptane.com> wrote: > > Hello,
> > That sort of missing symbol error at link time is often (but not always) a > > sign that some libraries got recompiled but not others. So there are > > references to the old symbol names hanging around.
> > I would try to ghc-pkg unregister syb-with-class and everything that depends > > on it, and then try cabal install happstack again.
> No luck! I unregistered everything in my user package db (which is > everything but the GHC boot libs) and then did a "caball install > happstack-data" and got the same error (eventually!).
> I'll pull GHC 6.12 branch head, rebuild and then try again.
I'm getting a similar thing in an Ubuntu (64bit) VM (on top of Mac OS X 10.5, but that shouldn't matter) building with GHC 6.12. I've removed and reinstalled syb-with-class, but still get the following when trying to build happstack-data 0.4.1:
Resolving dependencies... Configuring happstack-data-0.4.1... Preprocessing library happstack-data-0.4.1... Preprocessing executables for happstack-data-0.4.1... Building happstack-data-0.4.1... [ 1 of 16] Compiling Happstack.Data.GOps ( src/Happstack/Data/GOps.hs, dist/build/Happstack/Data/GOps.o )
src/Happstack/Data/Serialize.hs:1:85: Warning: -XPatternSignatures is deprecated: use - XScopedTypeVariables or pragma {-# LANGUAGE ScopedTypeVariables #-} instead
On Mon, Dec 21, 2009 at 6:31 AM, <jer...@n-heptane.com> wrote: > Hello,
> That sort of missing symbol error at link time is often (but not always) a > sign that some libraries got recompiled but not others. So there are > references to the old symbol names hanging around.
> I would try to ghc-pkg unregister syb-with-class and everything that depends > on it, and then try cabal install happstack again.
I'm pretty well stumped at this point. I've cleared off everything and gone up to GHC 6.12 HEAD, and a 'cabal install happstack-data' gives me the same symbol not defined error in Happstack.Data.Xml.Base.
But here's the spooky part, if I run it by hand like so:
after resolving issues due to CPP not being run, everything runs to completion, no errors. Also, the list of things we're pulling in during the template-haskell execution is much smaller (see bellow).
Has anyone seen this, where template-haskell behaves different when run from cabal-install (or Setup.hs) than from ghc --make (or ghci)?
> If you check the load-list, we are loading syb-with-class.
> This is on Mac OS X 10.6 on a 64-bit intel chip, if that makes any > difference.
> Has anyone seen anything like this? Is it likely I've screwed up my > GHC install somehow?
> Antoine
> --
> You received this message because you are subscribed to the Google Groups > "HAppS" group. > To post to this group, send email to happs@googlegroups.com. > To unsubscribe from this group, send email to > happs+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/happs?hl=en.
On Mon, Dec 21, 2009 at 12:31 AM, <jer...@n-heptane.com> wrote: > We have successfully built Happstack with GHC 6.10 on OS X, and GHC 6.12 on > Linux. But, you might be the first to try GHC 6.12 on OS X. However, I am > leaning towards it being something stale on your system from a previous > attempt right now...
FWIW, I just successfully built Happstack on GHC 6.12 on OS X 10.6 (and cabal-install 0.8.0). I deleted my .ghc and .cabal dirs beforehand so I would get a clean build. I had to make sure to *not* add the MacPorts dirs to .cabal/config (via extra-include-dirs and extra-lib-dirs), or else various packages (e.g., cpphs) would fail to compile as they got confused between the OS X and the MacPorts versions of various libraries.
I ran into exactly one build failure in the process when compiling HJScript:
src/HJScript/Monad.hs:51:10: A pattern match on a GADT requires -XGADTs In the pattern: EmptyBlock In the definition of `mappend': mappend EmptyBlock b = b In the instance declaration for `Monoid (Block ())' cabal: Error: some packages failed to install: HJScript-0.4.5 failed during the building phase. The exception was: ExitFailure 1 **********
I mentioned this on haskell-cafe, and someone pointed out a fix:
On Mon, Dec 21, 2009 at 4:05 PM, Antoine Latter <aslat...@gmail.com> wrote: > This one I can help with. You need to modify the .cabal file for > HJScript slightly. To do this:
> cabal unpack HJScript > cd HJScript-0.4.5 > ${EDITOR} HJScript.cabal
> And then add 'GADTs' to the 'Extensions:' list.
I then ran "cabal install" inside the unpacked directory, and re-ran "cabal install happstack". I'm now working my way through the tutorial, and noticing several discrepancies; I guess that's a subject for another thread. :-)
> On Mon, Dec 21, 2009 at 6:31 AM, <jer...@n-heptane.com> wrote: > > Hello,
> > That sort of missing symbol error at link time is often (but not always) a > > sign that some libraries got recompiled but not others. So there are > > references to the old symbol names hanging around.
> > I would try to ghc-pkg unregister syb-with-class and everything that depends > > on it, and then try cabal install happstack again.
> I'm pretty well stumped at this point. I've cleared off everything and > gone up to GHC 6.12 HEAD, and a 'cabal install happstack-data' gives > me the same symbol not defined error in Happstack.Data.Xml.Base.
> But here's the spooky part, if I run it by hand like so:
> after resolving issues due to CPP not being run, everything runs to > completion, no errors. Also, the list of things we're pulling in > during the template-haskell execution is much smaller (see bellow).
I've found that if I log the command cabal executes (cabal install -v) and execute that by hand, it doesn't work. However, if I remove the -O flag from there, it _does_ work. So a workaround is this:
cabal install -O0 happstack-data
I have no idea _why_ it is failing with optimizations on, though.
> Has anyone seen this, where template-haskell behaves different when > run from cabal-install (or Setup.hs) than from ghc --make (or ghci)?
Yes, I have seen that before, but in that case, I think it was the ghc linker doing something different from the standard linker, possibly related to GHC bug 3333 [1]. I think every bug or limitation that applies to ghci also applies to cabal if you're using template haskell (at least that's my suspicion).
Good find! Now that you mention it, I remember that I recently ran into the same issue with some other package, and had to use the same workaround :( - jeremy On Wed 12/23/2009 5:58 AM , Erik Hesselink hessel...@gmail.com sent: On Dec 22, 4:33 am, Antoine Latter wrote: > On Mon, Dec 21, 2009 at 6:31 AM, wrote: > > Hello, > > > That sort of missing symbol error at link time is often (but not always) a > > sign that some libraries got recompiled but not others. So there are > > references to the old symbol names hanging around. > > > I would try to ghc-pkg unregister syb-with-class and everything that depends > > on it, and then try cabal install happstack again. > > I'm pretty well stumped at this point. I've cleared off everything and > gone up to GHC 6.12 HEAD, and a 'cabal install happstack-data' gives > me the same symbol not defined error in Happstack.Data.Xml.Base. > > But here's the spooky part, if I run it by hand like so: > > ghc --make src/Happstack/Data/Xml/Base.hs > src/Happstack/Data/Default.hs src/Happstack/Data/ > DeriveAll.hs src/Happstack/Data/Normalize.hs src/Happstack/Data/Migrate.hs > > after resolving issues due to CPP not being run, everything runs to > completion, no errors. Also, the list of things we're pulling in > during the template-haskell execution is much smaller (see bellow). I've found that if I log the command cabal executes (cabal install -v) and execute that by hand, it doesn't work. However, if I remove the -O flag from there, it _does_ work. So a workaround is this: cabal install -O0 happstack-data I have no idea _why_ it is failing with optimizations on, though. > Has anyone seen this, where template-haskell behaves different when > run from cabal-install (or Setup.hs) than from ghc --make (or ghci)? Yes, I have seen that before, but in that case, I think it was the ghc linker doing something different from the standard linker, possibly related to GHC bug 3333 [1]. I think every bug or limitation that applies to ghci also applies to cabal if you're using template haskell (at least that's my suspicion). [1] http://hackage.haskell.org/trac/ghc/ticket/3333 Erik -- You received this message because you are subscribed to the Google Groups "HAppS" group. To post to this group, send email to . To unsubscribe from this group, send email to happs+. For more options, visit this group at http://groups.google.com/group/happs?hl=en.
On Wed, Dec 23, 2009 at 10:58 AM, Erik Hesselink <hessel...@gmail.com> wrote: > On Dec 22, 4:33 am, Antoine Latter <aslat...@gmail.com> wrote:
>> I'm pretty well stumped at this point. I've cleared off everything and >> gone up to GHC 6.12 HEAD, and a 'cabal install happstack-data' gives >> me the same symbol not defined error in Happstack.Data.Xml.Base.
>> But here's the spooky part, if I run it by hand like so:
>> after resolving issues due to CPP not being run, everything runs to >> completion, no errors. Also, the list of things we're pulling in >> during the template-haskell execution is much smaller (see bellow).
> I've found that if I log the command cabal executes (cabal install -v) > and execute that by hand, it doesn't work. However, if I remove the -O > flag from there, it _does_ work. So a workaround is this:
> cabal install -O0 happstack-data
> I have no idea _why_ it is failing with optimizations on, though.
>> Has anyone seen this, where template-haskell behaves different when >> run from cabal-install (or Setup.hs) than from ghc --make (or ghci)?
> Yes, I have seen that before, but in that case, I think it was the ghc > linker doing something different from the standard linker, possibly > related to GHC bug 3333 [1]. I think every bug or limitation that > applies to ghci also applies to cabal if you're using template haskell > (at least that's my suspicion).
That did the trick. Thanks a million. That was the last piece in the way of me having a fully functionally dev setup on my laptop, which has been in a state of disfunction since my upgrade to Snow Leopard.
> On 22/12/09 03:33, Antoine Latter wrote: >> On Mon, Dec 21, 2009 at 6:31 AM,<jer...@n-heptane.com> wrote: >>> Hello,
>>> That sort of missing symbol error at link time is often (but not >>> always) a >>> sign that some libraries got recompiled but not others. So there are >>> references to the old symbol names hanging around.
>>> I would try to ghc-pkg unregister syb-with-class and everything >>> that depends >>> on it, and then try cabal install happstack again.
>> I'm pretty well stumped at this point. I've cleared off everything >> and >> gone up to GHC 6.12 HEAD, and a 'cabal install happstack-data' gives >> me the same symbol not defined error in Happstack.Data.Xml.Base.
>> But here's the spooky part, if I run it by hand like so:
>> after resolving issues due to CPP not being run, everything runs to >> completion, no errors. Also, the list of things we're pulling in >> during the template-haskell execution is much smaller (see bellow).
>> Has anyone seen this, where template-haskell behaves different when >> run from cabal-install (or Setup.hs) than from ghc --make (or ghci)?
I ran into this same problem yesterday on my Mac when installing happstack. I did quite a bit of triage on it today, and traced down many specifics. In particular, I've shown that it is not due to anything in happstack and related packages. The comes from manner in which syb-with-class get built. The error shows up when installing happstack because it is using Data instance of ByteString provided by syb-with-class - and one of the symbols for it in the .hi file (of Instances.hs in syb-with-class) doesn't match the symbol that is in syb-with-class's lib file.
The fix has to do with building syb-with-class correctly. I suspect that the -O0 trick works only because it probably doesn't make use of the particular symbol (which I believe is a partial closure only used in optimized code).
=== Short Story ===
If I build syb-with-class-0.6 via cabal (cabal configure; cabal build) in the unpacked tar directory, it builds correctly.
If I build it via "cabal install" (either from the unpacked directory, or by letting cabal fetch it), then the resulting package is corrupted. In particular, the .hi interface file for Data.Generics.SYB.WithClass.Instances mentions symbols that aren't in the .a file. (Or rather, they have the wrong names.)
I compared verbose logs of both builds and the differ only in temporary file names.... execpt that the "cabal install" version builds haddock, as my .cabal/conf file has documentation: True. Turns out that if turn documentation off, then then "cabal install" builds a .hi file that matches the .a file... and all is well.
Is this a bug in cabal? cabal-install? ghc? haddock?
[2373] : cabal -V cabal-install version 0.8.0 using version 1.8.0.2 of the Cabal library
[2374] : ghc -V The Glorious Glasgow Haskell Compilation System, version 6.10.4
[2376] : ghc-pkg describe haddock | grep version version: 2.4.2
=== Background & Details ===
I was installing happstack on my Mac with my Haskell Platform (GHC 6.10.4) installation. I have successfully installed dozens of other packages in this environment before, and these results are annomalous.
I kicked this off via: cabal install --user happstack
This installs many packages, including syb-with-class-0.6, which compiled and installed just fine.
When installing happstack-data, and compiling the file Happstack/Data/ Proxy.hs, during the Template Haskell step (where things get loaded up in ghci), the build encounters this link error:
On Sat, Jan 16, 2010 at 7:12 PM, MtnViewMark <mark.lentcz...@gmail.com> wrote: > I ran into this same problem yesterday on my Mac when installing > happstack. I did quite a bit of triage on it today, and traced down > many specifics. In particular, I've shown that it is not due to > anything in happstack and related packages. The comes from manner in > which syb-with-class get built. The error shows up when installing > happstack because it is using Data instance of ByteString provided by > syb-with-class - and one of the symbols for it in the .hi file (of > Instances.hs in syb-with-class) doesn't match the symbol that is in > syb-with-class's lib file.
> The fix has to do with building syb-with-class correctly. I suspect > that the -O0 trick works only because it probably doesn't make use of > the particular symbol (which I believe is a partial closure only used > in optimized code).
> === Short Story ===
> If I build syb-with-class-0.6 via cabal (cabal configure; cabal build) > in the unpacked tar directory, it builds correctly.
> If I build it via "cabal install" (either from the unpacked directory, > or by letting cabal fetch it), then the resulting package is > corrupted. In particular, the .hi interface file for > Data.Generics.SYB.WithClass.Instances mentions symbols that aren't in > the .a file. (Or rather, they have the wrong names.)
> I compared verbose logs of both builds and the differ only in > temporary file names.... execpt that the "cabal install" version > builds haddock, as my .cabal/conf file has documentation: True. Turns > out that if turn documentation off, then then "cabal install" builds > a .hi file that matches the .a file... and all is well.
> Is this a bug in cabal? cabal-install? ghc? haddock?
> I was installing happstack on my Mac with my Haskell Platform (GHC > 6.10.4) installation. I have successfully installed dozens of other > packages in this environment before, and these results are annomalous.
> I kicked this off via: > cabal install --user happstack
> This installs many packages, including syb-with-class-0.6, which > compiled and installed just fine.
> When installing happstack-data, and compiling the file Happstack/Data/ > Proxy.hs, during the Template Haskell step (where things get loaded up > in ghci), the build encounters this link error:
> That symbol decodes to something referring to: > package: syb-with-class-0.6 > module: Data.Generics.SYB.WithClass.Instances > reference: dataType[abOQ]
> The reference turns out to be from Loading Happstack.Data.Default, > which in turn imports Data.Generics.SYB.WithClass.Instances.
> Poking around, I found that the interface (.hi) file for > Data.Generics.SYB.WithClass.Instances does indeed export such an > object:
> -- > You received this message because you are subscribed to the Google Groups "HAppS" group. > To post to this group, send email to happs@googlegroups.com. > To unsubscribe from this group, send email to happs+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/happs?hl=en.
I probably never noticed this with the older versions of happstack as back then I didn't have cabal-install setup to automatically install documentation.
