Michael Snoyman | 1 Jan 06:18 2012

Re: Support for raw SQL on persistent

On Sat, Dec 31, 2011 at 4:53 PM, Felipe Almeida Lessa
<felipe.lessa@...> wrote:
> On Fri, Dec 30, 2011 at 3:19 PM, Felipe Almeida Lessa
> <felipe.lessa@...> wrote:
>> Pull request here: https://github.com/yesodweb/persistent/pull/34
>>
>> Note that I went with 'rawSql' and 'RawSql' anyway because I've put
>> 'rawSql' into the Datatabase.Persist.GenericSql.
>
> Michael, what do you think about using 'Entity' data type on other
> places as well?  For example, instead of
>
>  (uid, user) <- getBy ...
>
> having
>
>  Entity uid user <- getBy ...
>
> I don't like having to type more characters, but I like having a more
> descriptive API and having 'rawSql' consistent with the rest of the
> API.  Also, the types would get simpler:
>
>  getBy :: (...) => Unique val b -> b m (Maybe (Key b val, val))
>
> vs.
>
>  getBy :: (...) => Unique val b -> b m (Maybe (Entity b val))
>
> Cheers,
>
(Continue reading)

Michael Snoyman | 1 Jan 06:33 2012

Re: An i18n question

On Fri, Dec 30, 2011 at 4:54 PM, Piyush P Kurur <ppk@...> wrote:
> On Fri, Dec 30, 2011 at 04:00:12PM +0200, Michael Snoyman wrote:
>> On Friday, December 30, 2011, Piyush P Kurur <ppk@...> wrote:
>> > On Fri, Dec 30, 2011 at 03:45:04PM +0200, Michael Snoyman wrote:
>
> [snip]
>
>> >>
>> >> I think the right thing to do is for Yesod to take the language list
>> >> provided by the user, lower-case it, and then append to that list the
>> >> two-letter versions, stripping out duplicates. For example, if a user
>> >> specifies that he/she accepts:
>> >>
>> >>     en_GB, fr_FR, fr, de
>> >>
>> >> we would produce the list:
>> >>
>> >>     en_gb, fr_fr, fr, de, en
>> >>
>> >> I think everything else can remain as-is.
>> >
>> > This clarifies the stuff. This is what I meant by canonisation. But is
>> > this the current behaviour
>>
>> No will you open an issue on girhub?
>
>
> Done let me know where to look for this code and I can try to send a pull
> request.
>
(Continue reading)

Michael Snoyman | 1 Jan 11:12 2012

Initial, barebones yesodweb.com repo ready for styling

Hi Bas (and everyone else),

I've put together a repo for the new yesodweb.com:

https://github.com/yesodweb/yesodweb.com

Note that this repo has two submodules: one for the content, and one
for the work-in-progress markdown library. So after pulling, just run:

git submodule update --init

Also, the code is using the Git version of the wai, persistent, and
yesod repos. In order to get these installed, it should be sufficient
to run:

for f in wai persistent yesod ; do git clone
https://github.com/yesodweb/$f.git && cd $f && git submodule update
--init && ./scripts/install && cd .. ; done

If anyone wants to play around, wants commit access to any of the
three repos involved, or has issues getting started, let me know.

Michael

Piyush P Kurur | 1 Jan 14:44 2012
Picon

Exposing some parsers

Hi,

Yesod has many quasi-quoters. They have a common syntactic
structure. E.g. indentation for delimitig blocks, -- for comments. Can
a unified api for such parsers be exposed (may be as a seperate
package) so that designing quasi-quoters for alied projects like
yesod-admin can be simplified ? Besides simplification, this also has
other the advantages like of having a unified syntax for all these
projects and seperate testing.

Regards

ppk

Greg Weber | 1 Jan 16:41 2012

Re: Exposing some parsers

Hi Piyush,


That is a great idea - which is why we already do it :)
We expose the common functionality of the shakespeare languages in the shakespeare package. If you look at the shakespeare repos, it is easy to look at the pass-through filters (js, coffed, and text) and see how to create another simple pass-through filter. Comments and indentation is not shared, but the main variable interpolation is.

Greg Weber

On Sun, Jan 1, 2012 at 10:44 AM, Piyush P Kurur <ppk-GzeMgTWoQaeuj8VC67ciSw@public.gmane.org> wrote:
Hi,

Yesod has many quasi-quoters. They have a common syntactic
structure. E.g. indentation for delimitig blocks, -- for comments. Can
a unified api for such parsers be exposed (may be as a seperate
package) so that designing quasi-quoters for alied projects like
yesod-admin can be simplified ? Besides simplification, this also has
other the advantages like of having a unified syntax for all these
projects and seperate testing.

Regards

ppk

Brian Victor | 1 Jan 17:33 2012

Improving devel server reloading

Disclaimer: I've been learning on Haskell for over a year now, but still 
consider myself somewhat novice.

In order to get my feet wet with the yesod code, I wanted to look into 
trying to improve the devel server reloading. On IRC, Greg suggested 
looking into using the plugins-auto package to monitor file changes.

What I discovered first is that the plugins package (on which 
plugins-auto depends) fails to build on GHC 7.2 due to an API change. I 
created a patch for that which I'll try to get pushed upstream.

The second and more challenging issue is that plugins-auto depends on 
inotify, which is a linux-only API.

Now, my understanding is that GHC 7.4 will include functionality that 
will allow us to do what we want, and that patches to use that 
functionality would be welcomed.

What I'd like to know is whether it would be satisfactory to use the 7.4 
API when we have it and to fallback to the current "dumb" monitoring 
code for older versions. It seems to me that trying to support more 
intelligent monitoring on GHC < 7.4 would be more trouble than it's 
worth, but I also tend to upgrade to current releases pretty quickly.

Also, if someone can point me to information about the new feature in 
GHC, I'd be happy to start looking into it.

--

-- 
Brian

Piyush P Kurur | 1 Jan 19:45 2012
Picon

Re: Exposing some parsers

On Sun, Jan 01, 2012 at 12:41:14PM -0300, Greg Weber wrote:
> Hi Piyush,
> 
> On Sun, Jan 1, 2012 at 10:44 AM, Piyush P Kurur <ppk@...> wrote:
> 
> > Hi,
> >
> > Yesod has many quasi-quoters. They have a common syntactic
> > structure. E.g. indentation for delimitig blocks, -- for comments. Can
> > a unified api for such parsers be exposed (may be as a seperate
> > package) so that designing quasi-quoters for alied projects like
> > yesod-admin can be simplified ? Besides simplification, this also has
> > other the advantages like of having a unified syntax for all these
> > projects and seperate testing.
> >
> > Regards
> >
> > ppk
> >

> That is a great idea - which is why we already do it :)
> We expose the common functionality of the shakespeare languages in the
> shakespeare package.

Actually I was not refering to the quasi-quoters of shakespearen
languages but more to do with the stuff like parseRoute, persist
etc. Let me explain the context in which I asked the question:

 1. I need a parseRoute like quasiquotter to hook admin subsites of
    each persist entity to the main sites.  

 2. I need a persit like quasiquotter to configure the admin interfaces
    for entities.

Is there something along that lines.

Regards

ppk

Greg Weber | 1 Jan 21:05 2012

Re: Exposing some parsers

On Sun, Jan 1, 2012 at 3:45 PM, Piyush P Kurur <ppk-GzeMgTWoQae3199FpKW2+w@public.gmane.orgin> wrote:
On Sun, Jan 01, 2012 at 12:41:14PM -0300, Greg Weber wrote:
> Hi Piyush,
>
> On Sun, Jan 1, 2012 at 10:44 AM, Piyush P Kurur <ppk-GzeMgTWoQaeuj8VC67ciSw@public.gmane.org> wrote:
>
> > Hi,
> >
> > Yesod has many quasi-quoters. They have a common syntactic
> > structure. E.g. indentation for delimitig blocks, -- for comments. Can
> > a unified api for such parsers be exposed (may be as a seperate
> > package) so that designing quasi-quoters for alied projects like
> > yesod-admin can be simplified ? Besides simplification, this also has
> > other the advantages like of having a unified syntax for all these
> > projects and seperate testing.
> >
> > Regards
> >
> > ppk
> >

> That is a great idea - which is why we already do it :)
> We expose the common functionality of the shakespeare languages in the
> shakespeare package.

Actually I was not refering to the quasi-quoters of shakespearen
languages but more to do with the stuff like parseRoute, persist
etc. Let me explain the context in which I asked the question:

 1. I need a parseRoute like quasiquotter to hook admin subsites of
   each persist entity to the main sites.

 2. I need a persit like quasiquotter to configure the admin interfaces
   for entities.

Is there something along that lines.

No. A quasi-quoter is a parser (that emits a fairly typeless Q Exp) - so to the extent that parsers can be re-used it should be possible to try to re-use Yesod parsing. With shakespeare we started from Hamlet and abstracted out after Michael had already pragmatically just duplicated some of the code. I suggest trying to do something similar here. If you can outline a more specific design for both of your points we can help you write the code.
 

Regards

ppk

Greg Weber | 1 Jan 21:16 2012

Re: Improving devel server reloading

Hi Brian,


For the devel server we do 2 things
1) watch for changes to files, and trigger a re-compile 
2) dependency tracking we would rather have GHC do

The new feature of GHC that I added is that it can do dependency tracking for our (Template Haskell loaded) templates, so for 7.4 users we can stop doing that ourselves once we add that capability to Hamlet.
What we are hoping to work with Happstack on is the first point, which my patch does not help. We need a package that is conditionally compiled based on the platform. On Linux it will use inotify.
On non-linux systems it will use Yesod's slow file watching code. In the future, it can use native file-watching capabilites of Windows and Mac.

I am assuming that plugins-auto reloads code with plugins, whereas in Yesod we trigger a normal re-compile (which is probably slower, but very reliable).
So going forward we need:
* abstract file watching library that works on different platforms. This will combine the useful inotify code from plugins-auto and the file watching code from yesod-devel
* plugins-auto will depend on the file watching library
* yesod devel will also depend on it.
* Yesod can experiment with using plugins-auto to reload code. There will probably always be concerns with using plugins, so we probably want the option to use both.

There might end up being a lot of questions to resolve - we are probably better taking this discussion off the Yesod mail list and limiting it to the contributors I sent this message to (if anyone else is interested in helping out in development let us know).

We are very glad to have you lend a hand to this - it is something that seems to get perpetually put off.
 
Greg Weber

On Sun, Jan 1, 2012 at 1:33 PM, Brian Victor <gmane-KNwjVI4xri1AfugRpC6u6w@public.gmane.org> wrote:
Disclaimer: I've been learning on Haskell for over a year now, but still consider myself somewhat novice.

In order to get my feet wet with the yesod code, I wanted to look into trying to improve the devel server reloading. On IRC, Greg suggested looking into using the plugins-auto package to monitor file changes.

What I discovered first is that the plugins package (on which plugins-auto depends) fails to build on GHC 7.2 due to an API change. I created a patch for that which I'll try to get pushed upstream.

The second and more challenging issue is that plugins-auto depends on inotify, which is a linux-only API.

Now, my understanding is that GHC 7.4 will include functionality that will allow us to do what we want, and that patches to use that functionality would be welcomed.

What I'd like to know is whether it would be satisfactory to use the 7.4 API when we have it and to fallback to the current "dumb" monitoring code for older versions. It seems to me that trying to support more intelligent monitoring on GHC < 7.4 would be more trouble than it's worth, but I also tend to upgrade to current releases pretty quickly.

Also, if someone can point me to information about the new feature in GHC, I'd be happy to start looking into it.

--
Brian


Greg Weber | 2 Jan 01:23 2012

Re: Re: Deploying Yesod to Heroku, can't build statically.

Glad you got it all figured out, and thanks for showing the code!


Do you actually need to combine the mappings with combineMappings, or do we want to completely ignore the database config file in production?
As discussed on the mail list, we are going to prefer using JSON rather than the data-object API, so that will make for some more small changes.

I can add canonicalizeKey (just the key) to the Heroku package or possibly to Yesod somewhere.
I will update the deploy/Procfile with your changes.
A tutorial definitely seems useful, particularly one that can be deployed to Heroku. You are in a much better position to judge though - whatever would have helped you just now. If it is easier you could put the information on Yesod wiki. We can think about duplication with the deploy/Procfile later. We should also make sure this information gets linked to from the deployment chapter of the book.




On Fri, Dec 30, 2011 at 3:34 PM, Andrew Myers <asm198-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Alright, after doing some code cleanup I have something that I can run
on Heroku and locally with `yesod --dev devel`.  Any comments or
suggestions are welcome!  I was thinking about making a little self
hosting tutorial and putting the code on github and hosting it on
Heroku.  Is this something that would be helpful or would that be
duplicating additions changes to be made to the Procfile?

Thanks for the help,
Andrew

canonicalizeKey :: (Text, val) -> (Text, val)
canonicalizeKey ("dbname", val) = ("database", val)
canonicalizeKey pair = pair

toMapping :: [(key, val)] -> DO.Object key val
toMapping = DO.Mapping . map (\(key, val) -> (key, DO.Scalar val))

combineMappings :: DO.Object key val -> DO.Object key val -> DO.Object
key val
combineMappings (DO.Mapping m1) (DO.Mapping m2) = DO.Mapping $ m1 ++
m2
combineMappings _ _ = error "Data.Object is not a Mapping."

loadHerokuConfig :: DO.TextObject -> IO Settings.PersistConfig
loadHerokuConfig ymlenv = do
#if DEVELOPMENT
 let urlMap = DO.Mapping []
#else
 urlMap <- Web.Heroku.dbConnParams >>= return . toMapping . map
canonicalizeKey
#endif
 either error return $ Database.Persist.Base.loadConfig
(combineMappings urlMap ymlenv)

-- This function allocates resources (such as a database connection
pool),
-- performs initialization and creates a WAI application. This is also
the
-- place to put your migrate statements to have automatic database
-- migrations handled by Yesod.
withYesodHeroku :: AppConfig DefaultEnv () -> Logger -> (Application -
> IO ()) -> IO ()
withYesodHeroku conf logger f = do
   s <- staticSite
   dbconf <- withYamlEnvironment "config/postgresql.yml" (appEnv
conf) loadHerokuConfig
   Database.Persist.Base.withPool (dbconf :: Settings.PersistConfig)
$ \p -> do
       Database.Persist.Base.runPool dbconf (runMigration migrateAll)
p
       let h = YesodHeroku conf logger s p
       defaultRunner (f . logWare) h
 where
#ifdef DEVELOPMENT
   logWare = logHandleDev (\msg -> logBS logger msg >> flushLogger
logger)
#else
   logWare = logStdout
#endif


On Dec 29, 9:51 pm, Andrew Myers <asm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Thanks for bearing with me Greg, I've got something that hosts the
> default hello page on Heroku now.  I'm quite sure it's not at all
> kosher though :p Maybe you can give me some pointers on a sane way to
> do it.
>
> All the code changes were in Application.hs generated by the
> scaffolding.
> Created this function for making keys that the
> `Database.Persist.Base.loadConfig` expects.  There's only one
> different from what `Web.Heroku.dbConnParams` does so it doesn't
> actually do much.
>
> canonicalizeKey :: Text -> Text
> canonicalizeKey "dbname" = "database"
> canonicalizeKey key = key
>
> I then modified withYesodHeroku as follows.
>
> withYesodHeroku :: AppConfig DefaultEnv () -> Logger -> (Application -> IO ()) -> IO ()
>
> withYesodHeroku conf logger f = do
>     s <- staticSite
> -- This line is pretty heinous.  It seems like I should somehow get
> the port and poolsize from the yaml
> -- configs and then combine that with the parameters from
> `Web.Heroku.dbConnParams`
> -- This takes the parameters from the DATABASE_URL and puts them in
> the form that `loadConfig`
> -- expects, adding port and poolsize.
>     dbparams <- Web.Heroku.dbConnParams >>= return . DO.Mapping .
> ([("port", DO.Scalar "5432"), ("poolsize", DO.Scalar "10")] ++) . map
> (\(key, val) -> (canonicalizeKey key, DO.Scalar val))
> -- Create the Database.Persist.PersistConfig with loadConfig of
> dbparams
>     let dbconf = either error id $ Database.Persist.Base.loadConfig
> dbparams
>     -- These two lines are how the original config was loaded.
>     -- dbconf <- withYamlEnvironment "config/postgresql.yml" (appEnv
> conf)
>     --         $ either error return .
> Database.Persist.Base.loadConfig
>     Database.Persist.Base.withPool (dbconf :: Settings.PersistConfig)
> $ \p -> do
>         Database.Persist.Base.runPool dbconf (runMigration migrateAll)
> p
>         let h = YesodHeroku conf logger s p
>         defaultRunner (f . logWare) h
>   where
> #ifdef DEVELOPMENT
>     logWare = logHandleDev (\msg -> logBS logger msg >> flushLogger
> logger)
> #else
>     logWare = logStdout
> #endif
>
> As I said, it's pretty grotesque :p, but it at least allows me to see
> a webpage on my heroku site.  I'm going to look at withYamlEnvironment
> and see if I can combine the parameters from the database variable and
> the yaml configs.  Do you have any suggestions?  Am I at least on the
> right track or am I doing something crazy?
>
> Thanks again,
> Andrew
>
> On Dec 29, 8:05 pm, Greg Weber <g...-6Rig8Yl2aw4Die4ONvY22w@public.gmane.org> wrote:
>
>
>
>
>
>
>
> > On Thu, Dec 29, 2011 at 3:02 PM, Andrew Myers <asm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > Some pointers on the postgre setup might be helpful if you don't
> > > mind.  Not knowing anything about Yesod beyond what I've read in the
> > > book I don't really understand the instructions in the Procfile.
>
> > > From the instructions (pasted below) I have the following questions:
>
> > > - Why do I have to parse the DATABASE_URL variable in main?
>
> > You need to parse it and then used it to make the database connection.
>
> > I can't find any references to 'withConnectionPool' or 'loadConnStr' except
>
> > > inside Yesod itself.  In the Scaffold generated Settings.hs there's a
> > > reference to Database.Persist.Base.withPool inside 'withYesodHeroku',
> > > is this what I want to pass arguments to?  Right now they're read from
> > > the "config/postgresql.yml" file which of course is wrong when
> > > deployed to heroku with a free shared db.
>
> > > - Where does the `dbConnParams _ = Web.Heroku.dbConnParams` bit of
> > > code from the ProcFile fit?  I can't find any references to it
> > > anywhere so adding that code to Settings.hs doesn't do anything.
> > > Web.Heroku.dbConnParams parses the DATABASE_URL variable itself, how
> > > does this relate to the parsing that's supposed to be done in main?
>
> > > - Looking at The Database.Persist.Postgresql [1] package docs it looks
> > > like a PersistConf is just a url and a pool size for PostGres, should
> > > I just create one of these in `withYesodHeroku?
>
> > Oh, the Procfile instructions are now out of date with the new scaffolding
> > changes. We need to override how Yesod connects to the database so that it
> > uses the parsed DATABASE_URL. I am busy at the moment, but will get back to
> > you soon.
>
> > > Thanks again for the help Greg!
>
> > > [1]
> > >http://hackage.haskell.org/packages/archive/persistent-postgresql/0.6...
>
> > > # Postgresql Yesod setup:
> > > #
> > > # * add code to read DATABASE_URL environment variable.
> > > #
> > > #   import System.Environment
> > > #   main = do
> > > #     durl <- getEnv "DATABASE_URL"
> > > #     # parse env variable
> > > #     # pass settings to withConnectionPool instead of directly using
> > > loadConnStr
> > > #
> > > # * add a dependency on the "heroku" package in your cabal file
> > > #
> > > # * add code in Settings.hs to turn that url into connection
> > > parameters. The below works for Postgresql.
> > > #
> > > #     #ifdef !DEVELOPMENT
> > > #     import qualified Web.Heroku
> > > #     #endif
> > > #
> > > #     dbConnParams :: AppEnvironment -> IO [(Text, Text)]
> > > #     #ifdef !DEVELOPMENT
> > > #     dbConnParams _ = Web.Heroku.dbConnParams
> > > #     #else
> > > #     dbConnParams env = do
> > > #       ...
>
> > > On Dec 29, 11:58 am, Greg Weber <g...-6Rig8Yl2aw4Die4ONvY22w@public.gmane.org> wrote:
> > > > yes that looks correct. I just modified the scaffolding Procfile to
> > > include
> > > > the environment argument. There is detailed information in the Procfile
> > > for
> > > > setting up the heroku port. Let us know if anything else needs to be
> > > > changed.
>
> > > > On Thu, Dec 29, 2011 at 1:25 PM, Andrew Myers <asm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > > > I see, I now have
> > > > > web: ./dist/build/yesod-heroku/yesod-heroku -p $PORT production
> > > > > in my Procfile.  This seems to work (in as much as the application now
> > > > > starts, need to point it at the right postgres db now) is this the
> > > > > correct way to do this?
> > > > > Thanks Greg
>
> > > > > On Dec 29, 11:01 am, Greg Weber <g...-6Rig8Yl2aw4Die4ONvY22w@public.gmane.org> wrote:
> > > > > > yesod devel is somewhat magical. You should be able to compile your
> > > > > > application and run it without it though. It is `cabal install
> > > -fdev`.
> > > > > Then
> > > > > > run the binary created in the dist folder and give an environment
> > > > > argument
> > > > > > of "development". for production compile with no flags and give an
> > > > > > environment argument of "production". This definitely needs to be
> > > > > > incorporated into the book now.
>
> > > > > > On Thu, Dec 29, 2011 at 12:43 PM, Andrew Myers <asm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > > wrote:
> > > > > > > Sorry if I'm being dense but could you clarify that or point me to
> > > > > > > some documentation?  I've been looking for documentation on that
> > > and
> > > > > > > trying to figure out how `yesod devel` starts the application but
> > > it
> > > > > > > hasn't been very fruitful so far.
> > > > > > > Thanks,
> > > > > > > Andrew
>
> > > > > > > On Dec 28, 6:23 pm, Greg Weber <g...-6Rig8Yl2aw4Die4ONvY22w@public.gmane.org> wrote:
> > > > > > > > Glad SO could help you out. We now require an environment
> > > argument
> > > > > for
> > > > > > > the
> > > > > > > > executable. I think the poor error message is a limitation of
> > > > > cmdargs.
>
> > > > > > > > On Wed, Dec 28, 2011 at 8:04 PM, Andrew Myers <asm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > > > > wrote:
> > > > > > > > > Thanks Greg,
>
> > > > > > > > > I posted on SO as suggested and someone helped me out.
> > > > > > > > > Turned out the problem was that by libc is newer than the libc
> > > on
> > > > > > > > > Heroku hosts (Archlinux is a rolling release distro).  I
> > > solved the
> > > > > > > > > problem
> > > > > > > > > by creating an ubuntu virtual machine and building/deploying
> > > from
> > > > > > > > > there.
>
> > > > > > > > > The relevant answer is herehttp://
> > > > > stackoverflow.com/a/8658468/166732
>
> > > > > > > > > Now I'm getting an error from the application processing
> > > arguments,
> > > > > > > > > not sure what it means or why yet.
>
> > > > > > > > > 2011-12-28T22:51:49+00:00 heroku[web.1]: Starting process with
> > > > > command
> > > > > > > > > `./dist/build/yesod-heroku/yesod-heroku -p 23748`
> > > > > > > > > 2011-12-28T22:51:49+00:00 app[web.1]: Requires at least 1
> > > > > arguments,
> > > > > > > > > got 0
>
> > > > > > > > > Has anyone seen that?  I haven't figured out what code I'm
> > > > > supposed to
> > > > > > > > > modify from
> > > > > > > > > the directions in the Procfile yet.  The indicated changes in
> > > > > > > > > Settings.hs don't seem
> > > > > > > > > to be relevant to what's actually there and I'm not sure what
> > > file
> > > > > the
> > > > > > > > > other code
> > > > > > > > > block is referencing.  It could be that though.
>
> > > > > > > > > Thanks,
> > > > > > > > > Andrew
>
> > > > > > > > > On Dec 28, 6:11 am, Greg Weber <g...-6Rig8Yl2aw4Die4ONvY22w@public.gmane.org> wrote:
> > > > > > > > > > Hi Andrew,
>
> > > > > > > > > > For my deployment I used a very simple application, and
> > > building
> > > > > with
> > > > > > > > > > -static just worked for me. I have definitely heard that it
> > > > > tends to
> > > > > > > be
> > > > > > > > > > much harder. I think you will be better off engaging the
> > > wider
> > > > > > > Haskell
> > > > > > > > > > community more experienced with static builds, perhaps by
> > > posting
> > > > > > > your
> > > > > > > > > > question to StackOverflow. Let us know how it turns out - we
> > > > > should
> > > > > > > be
> > > > > > > > > able
> > > > > > > > > > to point people to documentation on how to perform a static
> > > > > build.
>
> > > > > > > > > > Greg Weber
>
> > > > > > > > > > On Tue, Dec 27, 2011 at 11:21 PM, Andrew Myers <
> > > asm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>
> > > > > > > wrote:
> > > > > > > > > > > I'm very new to Yesod and I'm having trouble building Yesod
> > > > > > > statically
> > > > > > > > > > > so I can deploy to Heroku.
>
> > > > > > > > > > > I have changed the default .cabal file to reflect static
>
> ...
>
> read more »


Gmane