November 2013 - ghc-tickets

Re: [GHC] #5013: sporadic failures during compilation under solaris
by GHC 05 Nov '13

05 Nov '13

#5013: sporadic failures during compilation under solaris ----------------------------------+--------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 7.0.4 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+--------------------------- Comment (by maeder): Replying to [comment:22 simonmar]: > yes, `stat` is returning `EINTR` and we're not expecting it to. Change the call to `stat` in `getFileStatus` to use `throwErrnoIfMinus1Retry` (hope I've got that right from memory). I do not see what to try out here. I'm looking at `libraries/unix/System/Posix/Files.hsc` of ghc-7.6.3 (lines 179-189) {{{ -- | @getFileStatus path@ calls gets the @FileStatus@ information (user ID, -- size, access times, etc.) for the file @path@. -- -- Note: calls @stat@. getFileStatus :: FilePath -> IO FileStatus getFileStatus path = do fp <- mallocForeignPtrBytes (#const sizeof(struct stat)) withForeignPtr fp $ \p -> withFilePath path $ \s -> throwErrnoPathIfMinus1_ "getFileStatus" path (c_stat s p) return (FileStatus fp) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5013#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1480: Template Haskell should allow reification of modules
by GHC 05 Nov '13

05 Nov '13

#1480: Template Haskell should allow reification of modules ----------------------------+---------------------------------------------- Reporter: igloo | Owner: Type: feature | Status: closed request | Milestone: 7.8.1 Priority: highest | Version: 7.7 Component: | Keywords: Template Haskell | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: 8398 | ----------------------------+---------------------------------------------- Comment (by errge): Yes, you're correct, I want to reify not just the current module, but any module, even in packages. Therefore `ModGuts` is out of the question, and we can only depend on `ModIface`, that is actually serialized to `.hi` files. Your first option (to extend the serialization format with the Boolean) seems to be the correct way, that's what I will try first, when I sit down to do it. But first, I want to look around and get a better understanding about the whole recompilation checking stuff. This discussion and the wikipage will help a lot, I hope. The second option is unsatisfactory: as you pointed out before, it's different between different haskell implementations (or even between different versions of cabal libraries). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1480#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1480: Template Haskell should allow reification of modules
by GHC 05 Nov '13

05 Nov '13

#1480: Template Haskell should allow reification of modules ----------------------------+---------------------------------------------- Reporter: igloo | Owner: Type: feature | Status: closed request | Milestone: 7.8.1 Priority: highest | Version: 7.7 Component: | Keywords: Template Haskell | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: 8398 | ----------------------------+---------------------------------------------- Comment (by simonpj): Simon, I don't understand the relationship between `mi_deps` and `mi_usages` fields of `ModIface`. Both seem implicated in the recompilation check. Can you clarify? Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1480#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1480: Template Haskell should allow reification of modules
by GHC 05 Nov '13

05 Nov '13

#1480: Template Haskell should allow reification of modules ----------------------------+---------------------------------------------- Reporter: igloo | Owner: Type: feature | Status: closed request | Milestone: 7.8.1 Priority: highest | Version: 7.7 Component: | Keywords: Template Haskell | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: 8398 | ----------------------------+---------------------------------------------- Comment (by simonpj): Gergely wants to be able walk the entire module-import tree, including deep into packages. (Correct?) So given a module M (presumably including the current one) he'd like to produce a list of all modules that M directly imported. We can get from M to M's `ModIface`, but then we need to find its direct imports. But if M uses a module X, but X is from a package, we can't tell if X is directly imported by M or not. I can see two approaches: * It would be easy enough to record a boolean flag in `UsagePackageModule` for this purpose. * Alternatively, but less satisfactorily, we could say that `reifyModule` returns a superset of the direct imports. That's what happens now I think. But that seems yukky. I prefer the first. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1480#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1480: Template Haskell should allow reification of modules
by GHC 05 Nov '13

05 Nov '13

#1480: Template Haskell should allow reification of modules ----------------------------+---------------------------------------------- Reporter: igloo | Owner: Type: feature | Status: closed request | Milestone: 7.8.1 Priority: highest | Version: 7.7 Component: | Keywords: Template Haskell | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: 8398 | ----------------------------+---------------------------------------------- Comment (by simonmar): The source of truth for the design around usages and recompilation is [wiki:Commentary/Compiler/RecompilationAvoidance]. You're right that !UsagePackageModule doesn't have a usg_exports field. For package modules we record a lower resolution dependency, just the hash of the whole module. The rationale is that package modules don't change very often, so we don't need to track fine-grained dependency information about them. This does mean that we can't tell the difference between a direct import and an indirect import of a packages module from the `Usages`. Probably if you need to get a list of direct imports you should get it from somewhere else, e.g. `mg_dir_imps` from `ModGuts`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1480#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1480: Template Haskell should allow reification of modules
by GHC 04 Nov '13

04 Nov '13

#1480: Template Haskell should allow reification of modules ----------------------------+---------------------------------------------- Reporter: igloo | Owner: Type: feature | Status: closed request | Milestone: 7.8.1 Priority: highest | Version: 7.7 Component: | Keywords: Template Haskell | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: 8398 | ----------------------------+---------------------------------------------- Comment (by errge): I have to experiment a bit more around this, but at a first glance, I see this in ```HscTypes.lhs```: {{{ -- | Records modules that we depend on by making a direct import from data Usage -- | Module from another package = UsagePackageModule { usg_mod :: Module, -- ^ External package module depended on usg_mod_hash :: Fingerprint, -- ^ Cached module fingerprint usg_safe :: IsSafeImport -- ^ Was this module imported as a safe import } -- | Module from the current package | UsageHomeModule { usg_mod_name :: ModuleName, -- ^ Name of the module usg_mod_hash :: Fingerprint, -- ^ Cached module fingerprint usg_entities :: [(OccName,Fingerprint)], -- ^ Entities we depend on, sorted by occurrence name and fingerprinted. -- NB: usages are for parent names only, e.g. type constructors -- but not the associated data constructors. usg_exports :: Maybe Fingerprint, -- ^ Fingerprint for the export list we used to depend on this module, -- if we depend on the export list usg_safe :: IsSafeImport -- ^ Was this module imported as a safe import } -- ^ Module from the current package -- | A file upon which the module depends, e.g. a CPP #include, or using TH's -- 'addDependentFile' | UsageFile { usg_file_path :: FilePath, -- ^ External file dependency. From a CPP #include or TH -- addDependentFile. Should be absolute. usg_file_hash :: Fingerprint -- ^ 'Fingerprint' of the file contents. -- Note: We don't consider things like modification timestamps -- here, because there's no reason to recompile if the actual -- contents don't change. This previously lead to odd -- recompilation behaviors; see #8114 } deriving( Eq ) -- The export list field is (Just v) if we depend on the export list: -- i.e. we imported the module directly, whether or not we -- enumerated the things we imported, or just imported -- everything -- We need to recompile if M's exports change, because -- if the import was import M, we might now have a name clash -- in the importing module. -- if the import was import M(x) M might no longer export x -- The only way we don't depend on the export list is if we have -- import M() -- And of course, for modules that aren't imported directly we don't -- depend on their export lists }}} As you can see, UsagePackageModule doesn't have a usg_exports field, only UsageHomeModule. So I can't decide about directness of the import based on usg_exports alone. Maybe we should make this info more explicit in Usages if we want to depend on it for TH reification. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1480#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1201: ghci runs Template Haskell splices 4 times
by GHC 04 Nov '13

04 Nov '13

#1201: ghci runs Template Haskell splices 4 times -------------------------------------+------------------------------------ Reporter: igloo | Owner: simonpj Type: bug | Status: closed Priority: low | Milestone: _|_ Component: Template Haskell | Version: 6.6 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: ghci018 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by monoidal): * status: new => closed * resolution: => fixed Comment: This is now fixed, thanks to new TH. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1201#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7263: Add derived Show instances to GHC.Generics
by GHC 04 Nov '13

04 Nov '13

#7263: Add derived Show instances to GHC.Generics -------------------------------------+------------------------------------ Reporter: dag | Owner: dreixel Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: GHC API | Version: 7.7 Resolution: fixed | Keywords: generics Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by monoidal): I added it in 9f507c6b73470874d2e7db3abd83a21d446b4a23. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7263#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1480: Template Haskell should allow reification of modules
by GHC 04 Nov '13

04 Nov '13

#1480: Template Haskell should allow reification of modules ----------------------------+---------------------------------------------- Reporter: igloo | Owner: Type: feature | Status: closed request | Milestone: 7.8.1 Priority: highest | Version: 7.7 Component: | Keywords: Template Haskell | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Moderate (less than a day) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: 8398 | ----------------------------+---------------------------------------------- Comment (by simonmar): Regarding `mi_usages`, it does contain all the direct imports, and you can tell which entries are direct imports by the `usg_exports` field, which is `Just` for a direct import and `Nothing` otherwise. There are more comments on the `Usages` type, but feel free to reorganise the comments. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1480#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8495: Infinite loop when using Data.HashTable.newHint and Data.HashTable.update
by GHC 04 Nov '13

04 Nov '13

#8495: Infinite loop when using Data.HashTable.newHint and Data.HashTable.update ------------------------------------+------------------------------------- Reporter: erszcz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.4.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When using Data.!HashTable.newHint and Data.!HashTable.update to read a big (~1.5mln words) file into a !HashTable the program seems to fall into an infinite loop. "Seems to" since I couldn't wait long enough for it to finish computation. At least the execution time is way bigger than expected (orders of magnitude, like hours vs. expected seconds). Data.!HashTable.new doesn't cause the same issue. Attached to the report is an example program reproducing the bug along with a data file the issue occurs with. The bug was discussed on haskell-beginners mailing list quite a while ago, though I've summarized the findings in this bug report. See: - http://article.gmane.org/gmane.comp.lang.haskell.beginners/9811 - http://article.gmane.org/gmane.comp.lang.haskell.beginners/9828 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8495> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3