Happy Holidays!

As a present for all Yesod users we are pleased to announce the 0.9.4 release! This release features a fast production logger, improved configuration, a lot of package upgrades and bug fixes, and paves the way for a 1.0 release.

Features

production quality logger - integration with Kazu Yamamoto's fast-logger

In the 0.9 release we built a logging interface for Yesod. The logger code it uses to write the logs out is very simple and easy to understand. Since that release, Kazu Yamamoto released a really fast logger he has been using that we are very happy to upgrade to, appropriately named fast-logger. Kazu has written about some details of the original design and shared some of his bench-marking. This should be the fastest logger known to Haskell, and with it we implemented a production request logger. Previously there was just a development request logger focused entirely on convenience, without a thought to performance. One current limitation we will eventually improve is that the production logger doesn't log POST parameters, but the development logger still has that covered.

Note that we output logs to stdout by default. We expect you to pipe to syslog or the logging tool of your choice (but you can supply a different handle if you like). This keeps Yesod out of the business of dealing with log files and lets you pick a much more robust solution.

We still need to add the needed documentation to the logger. One nice feature that users may be unaware of is the ability to easily add file & line number information to your logging statement by using the Template Haskell versions.

$(logDebug) "This is a debug log message with file location information"

configuration/scaffolding/devel changes

Yesod generates scaffolding code for a few purposes - to do some boilerplate customization of your site based on some details that you provide, allow you to change functionality based on your application compilation flags, and also because we think you will likely want to change the scaffolding code (and it that is easier than dealing with complex configuration options). We have moved as much scaffolding code into the yesod-default package where it exists as real code as opposed to code templates in the scaffolding system . The scaffolding code now just references these default functions. This helps us maintain the code better, and will keep your boilerplate to a minimum. There is still nothing to stop you from overriding the default functions as you would have with scaffolding code, but you will probably want to copy the default function source code first.

We now have several techniques for configuring Yesod * YAML configuration files * cabal flags (use -fdev for a development build) corresponding to CPP defines for compile-time settings - these work extremely well if you know exactly what you want * command line arguments (-p --port).

By default the executable now requires an environment argument to prevent users from accidently using the wrong settings in production. Application configuration is different depending on the environment.

The core per-environment application settings are now maintained in the following configuration structure.

data ConfigSettings environment extra = ConfigSettings 
{csEnv :: environment 
,csLoadExtra :: TextObject -> IO extra 
,csFile :: environment -> IO FilePath 
} 

This is a type signature change in the release. Where you used to have just AppConfig, it should be changed to: AppConfig DefaultEnv ∅

The extra parameter allows you to define a function that will load arbitrary data into your configuration.

As another point of flexibility, "yesod devel" now takes an optional parameter giving it a file to be used as the "dist/devel.hs" to allow people who need it to control how their devel environment is launched.

Upgrade notes

Please see the above on the mandatory change to AppConfig. Another change to types is that you may need to add a type signature of ::Wiget where you invoke widgetFile or otherwise create widgets.

The below changes are not all required. We recognize that upgrading scaffolding code is painful, and this release continues to addresses that point by moving more functionality into configuration/default code in a way that will make future upgrades less painful. However, coming with us for that change does require you to undertake another effort to change your scaffolding generated code.

We have changed the flag system: in the cabal file there are now -flibrary-only and -fdev flags instead of a -fdevel flag. These now set a DEVELOPMENT CPP define instead of PRODUCTION.

When you upgrade to the latest Yesod, please note that the logger was moved to the scaffolding so that it can be switched on the #ifdef DEVELOPMENT flag. Please make sure your code looks like this in Application.hs to take advantage of logging:

import Yesod.Logger (Logger, logBS, flushLogger)
import Network.Wai.Middleware.RequestLogger

-- inside your with<Site> function where you would now invoke the defaultRunner function
defaultRunner (f . logWare) h
where
#ifdef DEVELOPMENT
logWare = logHandleDev (\msg -> logBS logger msg » flushLogger logger)
#else
logWare = logStdout
#endif

For the rest of the upgrade, you may want to do a yesod init and take a look at how the current files are generated. One important change is we have defined an Import module that is a modified Prelude that you can add your frequently used functions to.

Here is a diff of a public site that just upgraded There are a things in the diff that won't apply to you, but it should be fairly obvious.

More Changelog

• Yesod
  • yesod version now correctly uses the Cabal generated version
  • RedirectTemporary now results in a 307 for HTTP 1.1 clients (still 302 for HTTP 1.0)
• Shakespeare/Hamlet
  • Hamlet supports Haskell's case pattern match with $case/$of
  • use the less obscure $doctype instead of !!! to declare your doctype
  • much of Yesod's i18n code is now moved into the shakespeare-i18n package so that non-Yesod hamlet users can benefit from i18n
  • clearer error reporting when incorrect $tokens are used
• WAI
  • support for custom development actions, which is being used for automatic browser refresh - something we look forward to better integrating in the development mode environment
  • allow proxies to pass along the server field setting
  • wai-websockets upgraded to websockets 0.4 library.
• authenticate - improved facebook integration
• monad-control - 0.3 (much improved) is now supported, and there is still support for 0.2 (which MongoDB users will be stuck on for a little bit longer).
• persistent - bug fixes for !=. against non-nullable SQL columns and empty FilterOr/FilterAnd filters

infrastructure improvements

A big thanks to Arash Rouhani, who got another build server up and running for us!

We have revised the source installation scripts and instructions. Please speak up if you encounter any problems building Yesod from source. We are expecting dependency hell to be a very limited occurrence, particularly if you use virthualenv when building Yesod from source.

And a Happy New Year!

2012 is going to be a great year for Haskell! The official GHC 7.4 release will be out soon, which features some amazing new features. Much of the Yesod code base already compiles under the first 7.4 release candidates, so we will likely have 7.4 support soon after the official release.

We think we are ready for our 1.0 milestone. Almost all of the 1.0 features we laid out have now been implemented. One of the biggest aspects we wanted for 1.0 was API stability, and there are few disruptive API changes we want to make for the 1.0 release.

The biggest change we are planning on making is switching to conduits from enumerators. Although we expect that most of our users will not notice a difference, for anyone that has integrated with enumerator functionality, this will mean changes, although most changes should not be difficult.

Given that conduits could use more time to stabilize, we are planning on a 0.10 release very soon that will have all of the other API changes we want to make, and possibly the switch to conduits. Then we will be ready for the 1.0.

Please upgrade and get your feedback in. We are now starting the API changes for the 0.10 branch. For 0.10 you can look forward to a significant upgrade to a more modular and featureful Persistent. However, the new Persistent should require few, if any changes to your Persistent code.