Heads-up on a yesod devel change

Hi all,

Just a little heads-up on a change I pushed for yesod devel. When
building your code, yesod devel will now hide all of the "Loading
package " messages that clutter up the output. This has been a
long-desired feature[1] and I finally decided to just do it. It won't
be in any of the release notes since it's minor, but I figured
existing users might be confused to suddenly have none of those
messages show up.

Michael

[1] That is, by me.

Re: Heads-up on a yesod devel change

Nice..  I know this is a long shot, but does this mean that GHC will be run in a kind of daemon mode and won't need
to constantly reload them?

Max

On Apr 3, 2012, at 12:03 AM, Michael Snoyman wrote:

> Hi all,
> 
> Just a little heads-up on a change I pushed for yesod devel. When
> building your code, yesod devel will now hide all of the "Loading
> package " messages that clutter up the output. This has been a
> long-desired feature[1] and I finally decided to just do it. It won't
> be in any of the release notes since it's minor, but I figured
> existing users might be confused to suddenly have none of those
> messages show up.
> 
> Michael
> 
> [1] That is, by me.

Re: Heads-up on a yesod devel change

Nope, nothing like that. This is just a really simple patch that
filters the output from calling `cabal build`.

On Tue, Apr 3, 2012 at 10:24 AM, Max Cantor <mxcantor@...> wrote:
> Nice..  I know this is a long shot, but does this mean that GHC will be run in a kind of daemon mode and won't
need to constantly reload them?
>
> Max
>
> On Apr 3, 2012, at 12:03 AM, Michael Snoyman wrote:
>
>> Hi all,
>>
>> Just a little heads-up on a change I pushed for yesod devel. When
>> building your code, yesod devel will now hide all of the "Loading
>> package " messages that clutter up the output. This has been a
>> long-desired feature[1] and I finally decided to just do it. It won't
>> be in any of the release notes since it's minor, but I figured
>> existing users might be confused to suddenly have none of those
>> messages show up.
>>
>> Michael
>>
>> [1] That is, by me.
>

Re: RedisSessions

Re: Heads-up on a yesod devel change

I have an experimental version of yesod devel that does use the GHC
API to build. It doesn't need to reload all packages or parse cabal
files every time, so it's much faster. It's a bit rough, with lots of
code copied from GHC, but it seems to work. Will push it in an
experimental branch after i get it cleaned up a bit.

luite

On Tue, Apr 3, 2012 at 9:31 AM, Michael Snoyman <michael@...> wrote:
> Nope, nothing like that. This is just a really simple patch that
> filters the output from calling `cabal build`.
>
> On Tue, Apr 3, 2012 at 10:24 AM, Max Cantor <mxcantor@...> wrote:
>> Nice..  I know this is a long shot, but does this mean that GHC will be run in a kind of daemon mode and won't
need to constantly reload them?
>>
>> Max
>>
>> On Apr 3, 2012, at 12:03 AM, Michael Snoyman wrote:
>>
>>> Hi all,
>>>
>>> Just a little heads-up on a change I pushed for yesod devel. When
>>> building your code, yesod devel will now hide all of the "Loading
>>> package " messages that clutter up the output. This has been a
>>> long-desired feature[1] and I finally decided to just do it. It won't
>>> be in any of the release notes since it's minor, but I figured
>>> existing users might be confused to suddenly have none of those
>>> messages show up.
>>>
>>> Michael
>>>
>>> [1] That is, by me.
>>

Re: Heads-up on a yesod devel change

On Tue, Apr 3, 2012 at 9:51 AM, Luite Stegeman <stegeman@...> wrote:
> I have an experimental version of yesod devel that does use the GHC
> API to build. It doesn't need to reload all packages or parse cabal
> files every time, so it's much faster. It's a bit rough, with lots of
> code copied from GHC, but it seems to work. Will push it in an
> experimental branch after i get it cleaned up a bit.

Reloading the .cabal file is something I like since I don't need to
remember to restart 'yesod devel' after some changes.  I guess this
could be explicitly supported by looking for changes in the .cabal
file and falling back to slow path, though.

Cheers,

--

-- 
Felipe.

Re: Heads-up on a yesod devel change

On Tue, Apr 3, 2012 at 5:04 PM, Felipe Almeida Lessa
<felipe.lessa@...> wrote:

> Reloading the .cabal file is something I like since I don't need to
> remember to restart 'yesod devel' after some changes.  I guess this
> could be explicitly supported by looking for changes in the .cabal
> file and falling back to slow path, though.

Yes that's what it does. It uses some wrapper programs to capture the
command-line arguments for ghc, ld and ar, if the .cabal file is newer
than the captured commands, it calls cabal build.

luite

Re: Sessions and Languages

Re: Heads-up on a yesod devel change

On Tue, Apr 3, 2012 at 5:37 PM, Luite Stegeman <stegeman@...> wrote:
> On Tue, Apr 3, 2012 at 5:04 PM, Felipe Almeida Lessa
> <felipe.lessa@...> wrote:
>
>> Reloading the .cabal file is something I like since I don't need to
>> remember to restart 'yesod devel' after some changes.  I guess this
>> could be explicitly supported by looking for changes in the .cabal
>> file and falling back to slow path, though.
>
> Yes that's what it does. It uses some wrapper programs to capture the
> command-line arguments for ghc, ld and ar, if the .cabal file is newer
> than the captured commands, it calls cabal build.

first version is in the develbuildghcapi branch, see
https://github.com/yesodweb/yesod/commit/1cb7a494a9b068c56f2e9de86b7ad81e87f0af7e

I've only tested it on GHC 7.4.1 and Linux so far (and there are some
hardcoded 'ar' and 'ld' program names, so I'm afraid it won't work on
Windows yet).

luite

Runtime theming?

I'm trying to write a blog engine in Yesod, and part of the features set I'd like is that you can edit your
themes at runtime without having to recompile, or even having ghc installed. The problem is, I obviously
can't use any functions in my Hamlet RT templates if I do that. So I was thinking of something like

postWidget post =
tags <- HDList . map (\tag -> (["tag"], tagWidget tag) <$> tagsForPost
yesod <- getMaster
let renderer = yesodRender yesod "/"
liftIO $ renderHamletRT postTemplate [(["post"], HDHtml $ toHtml post), (["tags"], HDList [(["tag"],
tags)] renderer

where we also have tagWidget :: Tag -> IO Widget (modulo caching so the theme isn't reloaded from disk every
time, etc.). The problem with that is that I'd have one theme file for the 'main' part, one part for
rendering a post, one part for rendering a per-post taglist, one for rendering comments, etc.

Alternately, I could just say 'okay you get these N themes compiled in, if you want to write your own set up
ghc'. But that'd raise the barrier to entry significantly. Thoughts?

Patrick