Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to detect file changes on hamlet templates on stack devel for lts-12.5 #1551

Closed
jvliwanag opened this issue Aug 8, 2018 · 9 comments

Comments

@jvliwanag
Copy link

On a new project initialized with the yesod templates, with the resolver automatically set to lts-12.5, hamlet templates are not watched. That is, running yesod devel fails to rebuild the app on changes to the template files.

Tested on both macos 10.13.6 and Ubuntu 18.04.

What worked however is changing the stack resolver from the picked up lts-12.5 stack resolver to lts-11.20.

Running watched command from stack build --file-watch confirms that the hamlet files are missing when on lts-12.5, but are present on lts-11.20.

@snoyberg
Copy link
Member

That's most likely a different in how GHC is reporting the watched files in the two different versions. There should be some .hi-dump files in your .stack-work directory. Can you report whether those files reference your Hamlet files with the two different resolvers?

@jvliwanag
Copy link
Author

jvliwanag commented Aug 10, 2018

Looks like they point to the same file, but have the 12.5 has an additional hex string.

11.20 (working auto build)
Path: ./.stack-work/dist/x86_64-osx/Cabal-2.0.1.0/build/src/Handler/Home.dump-hi

addDependentFile "templates/homepage.hamlet"
54086c982e9b4ed881fcb2d9d3c2aa4d
  $trModule :: GHC.Types.Module
  {- HasNoCafRefs, Strictness: m,
     Unfolding: (GHC.Types.Module
                   Handler.Home.$trModule3
                   Handler.Home.$trModule1) -}

12.5 (auto build not working)
Path: ./.stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build/src/Handler/Home.dump-hi

addDependentFile "templates/homepage.hamlet" 64b74188b62bac042119e8a0d26c3289
3886f14f725c6b9c0e89769a9758c7a7
  $trModule :: GHC.Types.Module
  {- HasNoCafRefs, Strictness: m,
     Unfolding: (GHC.Types.Module
                   Handler.Home.$trModule3
                   Handler.Home.$trModule1) -}

@snoyberg
Copy link
Member

Good catch, looks like Stack needs to be updated to support that hex. I'm running out for the weekend right now, but a patch along these lines would probably do the trick. But I won't be able to try this out myself until next week:

diff --git a/src/Stack/Package.hs b/src/Stack/Package.hs
index ef986e95..d5ceb779 100644
--- a/src/Stack/Package.hs
+++ b/src/Stack/Package.hs
@@ -1184,8 +1184,9 @@ parseDumpHI dumpHIPath = do
             -- It can be an absolute or relative path.
             mapMaybe
                 (fmap TL.unpack .
-                  (TL.stripSuffix "\"" <=< TL.stripPrefix "\"") .
-                  TL.dropWhileEnd (== '\r') . TLE.decodeUtf8 . CL8.dropWhile (/= '"')) $
+                  TL.stripPrefix "\"" .
+                  -- Starting with GHC 8.4.3, there's a hash following the path
+                  TL.takeWhile (/= '\"') . TLE.decodeUtf8 . CL8.dropWhile (/= '"')) $
             filter ("addDependentFile \"" `CL8.isPrefixOf`) dumpHI
     thDepsResolved <- liftM catMaybes $ forM thDeps $ \x -> do
         mresolved <- liftIO (forgivingAbsence (resolveFile dir x)) >>= rejectMissingFile

snoyberg added a commit to commercialhaskell/stack that referenced this issue Aug 13, 2018
snoyberg added a commit to commercialhaskell/stack that referenced this issue Aug 13, 2018
snoyberg added a commit to commercialhaskell/stack that referenced this issue Aug 13, 2018
StevenXL added a commit to StevenXL/heroku-buildpack-stack that referenced this issue Aug 31, 2018
The current version of stack is unable to [detect changes in
hamlet](yesodweb/yesod#1551).

This updates the buildpack to always clean out the old build, so even
though the change to hamlet files is not detected, they will be rebuilt
anyway.

The issue with stack [should be
fixed](https://github.com/commercialhaskell/stack/blob/aae15e3ae5767febe9fcad36bf5a5e184c635de1/ChangeLog.md)
in the next release.
@ygale
Copy link

ygale commented Oct 24, 2018

Even with versions of stack that include the linked fix, yesod devel still does not detect changes to hamlet files.

In GHC 8.2 and earlier, referenced hamlet files appear as addDependentFile lines in the .dump-hi file. But in GHC 8.4 these lines do not appear. That appears to be the cause of the problem.

borsboom pushed a commit to commercialhaskell/stack that referenced this issue Oct 24, 2018
@ygale
Copy link

ygale commented Oct 25, 2018

I am still experiencing this issue. Perhaps it should be re-opened?

The underlying stack issue is commercialhaskell/stack#4360.

@ygale
Copy link

ygale commented Oct 25, 2018

The problem was that you also need shakespeare >= 2.0.19, which is only in the latest LTS 12.14. Thanks to @tolysz for pointing that out. You need stack >= 1.9.3 (not yet released) to get @snoyberg's fix, or in the meantime you can build >= 1.9.2 from the stable branch on github.

I am now convinced that this issue is fixed. Thanks!

@spacekitteh
Copy link

I'm not. I just updated to 1.9.3, and addDependentFile generates the following error from within GHC:

*** Core Linted result of Desugar (after optimization): *** Deleting temp files: Deleting: C:\Users\SPACEK~1\AppData\Local\Temp\ghc3940_0\ghc_1.hscpp C:\Users\SPACEK~1\AppData\Local\Temp\ghc3940_0\ghc_3.hscpp C:\Users\SPACEK~1\AppData\Local\Temp\ghc3940_0\ghc_5.hscpp *** Deleting temp dirs: Deleting: C:\Users\SPACEK~1\AppData\Local\Temp\ghc3940_0 C:\Users\spacekitteh: openBinaryFile: permission denied (Permission denied)

@ygale
Copy link

ygale commented Feb 2, 2019

@spacekitteh Could you please post more details? So far I don't see the connection with addDependentFile. Thanks!

@spacekitteh
Copy link

@ygale I just realised I posted this in the yesod tracker, rather than stack. But, when I comment out the addDependentFile line in my TH code, it works; when I leave it in, it gets permission errors.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants