July 2015 - ghc-tickets

[GHC] #9229: Compiler memory use regression
by GHC 24 Jul '15

24 Jul '15

#9229: Compiler memory use regression -------------------------+------------------------------------------------- Reporter: | Owner: augustss | Status: new Type: bug | Milestone: Priority: | Version: 7.8.2 normal | Operating System: Windows Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- I have a module which compiles fine with ghc 7.6, but where ghc 7.8.2 runs out of memory (32-bit Windows). Sadly, I cannot supply the source code since it's proprietary, so I realize that this bug will be almost impossible to fix. It is possible to compile the module with -O0 and -O1, but not -O2. (This is a very performance critical module so I'd like -O2.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9229> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #1498: Optimisation: eliminate unnecessary heap check in recursive function
by GHC 24 Jul '15

24 Jul '15

#1498: Optimisation: eliminate unnecessary heap check in recursive function -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: 4258 | Blocking: Related Tickets: 8326 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * cc: rwbarton (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1498#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10683: Haare schneller wachsen lassen mit Hair Vox
by GHC 24 Jul '15

24 Jul '15

#10683: Haare schneller wachsen lassen mit Hair Vox -------------------------------------+------------------------------------- Reporter: | Owner: schulzwinter | Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Hair Vox – Hair growth und Anti-Hairloss Spray Durch Hair Vox gibt es endlich das Produkt, welches den Haarausfall ein Ende setzt und neuen Haarwuchs in Gang setzt. Durch die raffinierte Kombination von Anti-Haarausfall-Tabletten plus einem aktivierenden Spray wird ermöglicht, innerhalb von nur 4 Monaten zu dichtem sowie schönerem Haar zu gelangen, ohne dabei Haartransplantationen machen zulassen. Die Produktkombination ist dadurch der simpelste und sicherste Weg, die Probleme mit dem Haarwuchs in den Griff zu bekommen. Der Gebrauch von [http://www.beauty-health-produkte.com/hair-vox-selbsttest/ Hair Vox] schont auf diesem Weg auch den Geldbeutel. Das Mittel beinhaltet nur Natur-basierte Inhaltsstoffe, dessen Erfolge klinisch bewiesen ist. Eine Zusammenstellung der Wirksubstanzen bringen optimalen Haarwuchs. Hair Vox Erfahrungen Falls man ausreichend im WWW nachschaut, sind haufenweise überaus positiven Berichten über die Produkte zu finden, die alle einen wiedererlangten Haarwuchs beschreiben. Die [http://www.beauty-health- produkte.com/ Hair Vox Erfahrungen] zeigen, dass augenscheinlich innerhalb von nur ein paar Monaten das Haar zur Gänze nachwächst und überhauptkeine kahlen Stellen mehr zu sehen sind. Das Resultat ist überaus ansehnlich. Dazu hilft das Produkt Männern und Frauen gleichermaßen. Die Verbraucher sind sehr froh, dass dieses Produkt so effektiv aber trotzdem sanft wirkt. Während des Anwendens berichten viele über ein Hautkribbeln, dass den beginnenden Haarwuchs bezeichnet. Ab da a kann der Anwender buchstäblich beim Wachsen der Haare zugucken. Hair Vox Wirkung und Hair Vox Inhaltsstoffe Das Erfolgsgeheimnis hinter dem Produkt ist ein Eiweiß-Komplex, welcher von Fischen aus der Tiefsee stammt. Solche Tierarten sind wahre Künstler des rasanten Zellwachstums und haben die Fähigkeit alle Teile ihres Körpers flink zu reparieren. Dieses einzigartige Merkmal wurde nun auf den Menschen übertragen. Haarausfall und kahle Stellen sind ein Zeichen von sterbenden Follikeln, die zuvor für das Bilden von Haaren zuständig sind. Durch die Tiefsee-Eiweiße werden unsere Haarfollikel wieder belebt und können dann neue Haare wachsenlassen. Daneben sind noch andere Stoffe wie z.B. Aminosäuren und Vitamin-B-Komplexe. Das Zusammenwirken dieser Stoffe regt das Haarwachstum außerordentlich an und verleiht den Menschen schönes Haar. Hair Vox Test Unser eigener Hair Vox Test konnte die extremen Ergebnisse sogar bestätigen. Es wurde bewiesen, dass innerhalb des beschriebenen Zeitfensters alle Haare sichtbar wachsen und nicht eine von den kahlen Stellen übrig bleiben. Unser Tester war wahnsinnig überzeugt von der wundervollen Wirkung des Haarwuchsmittels und ist heute stolzer Besitzer einer üppigen Frisur. Ein weiterer und lobenswerter Bonuspunkt für das Produkt ist, dass mit Hair Vox Nebenwirkungen komplett ausbleiben. Damit ist dieses Haarwuchsprodukt gesund anwendbar. Unsere Testperson hat Hair Vox über 2 Wochen genommen und ist bereits kaum wiedererkennbar. Man kann meinen, die Person hätte eine Transplantation machen lassen, doch war es bloß ein günstiges Haarwuchsmittel, das die Haare spriessen lässt. Hair Vox kaufen Zu der Frage, wie man am billigsten Hair Vox kaufen kann, gibt es nur eine Antwort: direkt bei dem Hersteller. Dort ist das Haarwuchsprodukt am billigsten und ab und zu findet man dort sogar einen Hair Vox Rabatt. Der Produkthersteller ist sehr vertrauenswürdig und kommt den Käufern sehr entgegen. Sein Versprechen, durch das Mittel den Haarwuchs um über 61,2 Prozent zu optimieren, wird eingehalten und erweist sich als wahrheitsgemäße Angabe. Sollte die Behandlung widererwarten keinen Erfolg bringen, kommt der Verkäufer dem Kunden mit der Hair Vox Geld-zurück- Garantie entgegen, durch welche bei Unzufriedenheit mit Hair Vox der komplette Kaufpreis zurück gegeben werden kann. Wurde Hair Vox erfolgreich bestellt, dauert es nur 2 bis 5 Tage, bis es geliefert wird. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10683> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5916: runST isn't free
by GHC 24 Jul '15

24 Jul '15

#5916: runST isn't free -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): See also #10678 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5916#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3549: unlit does not follow H98 spec
by GHC 24 Jul '15

24 Jul '15

#3549: unlit does not follow H98 spec -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: patch Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3549#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10679: Generalize hi-boot/hi for signatures, to manage intermediate merged interfaces
by GHC 24 Jul '15

24 Jul '15

#10679: Generalize hi-boot/hi for signatures, to manage intermediate merged interfaces -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Package | Version: 7.11 system | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- == The problem == In some situations, we need to output multiple interface files for what is morally the same module name. === Example 1: Merging external and home signatures === {{{ unit a-sig where signature A unit p where include a-sig signature A }}} Compiling `p/A.hsig` produces an interface file which contains just the definitions declared in `p`. However, someone including `p` should see the merge of the interface of `p/A.hsig` AND `a-sig/A.hsig` (which was included.) === Example 2: Merging two home signatures === {{{ unit p where signature A signature B where import A ... signature A where import B ... }}} What should we do if a signature is specified multiple times in the same unit? The compilation of each produces a distinct interface, and the public interface we want to expose is the merge of the two. (And by the way, what's the source file name of `A`, if we are not using the inline syntax?) === Example 3: Merging a signature and a module === {{{ unit p where signature A module B where import A ... module A where import B ... }}} `A` and `B` are mutually recursive, and we want to use a signature file to break the gap. The signature produces an interface file, only to be overwritten when we actually define the module proper. But wait! We have a solution for this example already: the first interface file for `A` is not saved to `A.hi`, but `A.hi-boot`... == The proposal == I want to take the `A.hi-boot` versus `A.hi` distinction and generalize it: we should be able to name intermediate interface files A.1.hi, A.2.hi, ... and finally A.hi (which is publically visible outside the unit.) This naming convention applies to Haskell files too. === User-visible consequences === Every signature file is numbered, and every import of a signature file refers to a specific number. This number is unique among all other modules in a unit which share the same name. For backwards compatibility, some number/file name extensions are treated specially: 1. `.hs` files compile to `.hi` (implicitly numbered 0) 2. `.hs-boot` files compile to `.hi-boot` (implicitly numbered 1) 3. `.hsig` files compile to `.hi-boot` (implicitly numbered 1) 4. `.n.hsig` files compile to `.n.hi-boot` (numbered n, where n is greater than 1) **Flex point:** We could give `.hsig` files their own file extension for interface files; just would require some more work to distinguish between `hs-boot` and `hsig` as well as record the numbering. To import, the `{-# SOURCE n #-}` pragma can be used (with `{-# SOURCE #-}` being equivalent `{-# SOURCE 1 #-}`.) Inline Backpack files can omit numbering, since we can figure it out based on the ordering of declarations (numbering in REVERSE order of occurrence). Example 2 can be numbered as follows: {{{ signature {-# SOURCE 2 #-} A signature {-# SOURCE 1 #-} B where import {-# SOURCE 2 #-} A ... signature {-# SOURCE 1 #-} A where import {-# SOURCE 1 #-} B ... }}} === Internal consequences === In many places in the code today, we record a boolean indicating if we depended on the boot interface `hi-boot` or the normal interface `hi`. We now replace this marker with an integer which records the numbering. The primary affected components are dependency recording in interfaces, interface loading code in GHC, and the implementation of `--make`. === Interaction with signature merging === Unlike `hs-boot` files, `hsig` files can be included from external units, in which case the semantics are that all signatures in scope are merged together. The key rule is that we **generate an hi file for each partial merge**; this means that whenever we want to typecheck a module, there is exactly one interface file per module we import. Consider this example: {{{ unit a-sig where signature A unit a-sig2 where signature A unit p where include a-sig module B include a-sig2 module C signature A module D }}} When compiling this, we generate four interface files for `A`: {{{ unit p where include a-sig -- Produces A.3.hi-boot (a-sig) module B -- uses A.3.hi-boot include a-sig2 -- Produces A.2.hi-boot (a-sig + a-sig2) module C -- uses A.2.hi-boot signature A -- Produces A.hi-boot (everything) module D -- uses A.hi-boot -- At the end, A.hi-boot copied to A.hi to be publically visible }}} == Can we do anything simpler? == There are a few barriers to doing something simpler: 1. We can avoid generating extra interface files if we instead merge them on-the-fly when we use them. However, this forces later instances of GHC to do repeated work remerging interface files, so it seems desirable from a performance perspective to merge before writing. Another scheme is that we could merge on use for signatures in the home package, and then write out a unified file at the very end, trading off performance for less written interface files. 2. The Backpack language is defined in a way that allows modules, signatures and includes to be ordered in a semantically meaningful way. For example: {{{ unit q where signature M signature A where f :: Int -> Int ... unit p where signature A where data T module M where import A -- should get T but not f ... include q -- fill in M module S where import A -- should get T and f }}} This means that even within a unit, the interface of a signature file may differ. We could rule this out, but we would have to work out how to explain this limitation to users. (For example, we could solve the example above by saying that units which define modules do not bring their signatures into scope for a package which imports them; but this is a pretty ad hoc rule! And you still have to deal with repeated signatures, or a signature importing a module importing a signature. There are a lot of cases.) 3. This problem cannot be avoided at all if you are truly doing recursive modules, since you need the intermediate interface file to do compilation at all prior to getting the real implementation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10679> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything)
by GHC 24 Jul '15

24 Jul '15

#1409: Allow recursively dependent modules transparently (without .hs-boot or anything) -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.2 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9256 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): Hi guys, I have another proposal for how to fix this: #10681 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1409#comment:67> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9256: Support automatic derivation of an hs-boot file from an hs file
by GHC 24 Jul '15

24 Jul '15

#9256: Support automatic derivation of an hs-boot file from an hs file ------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: backpack | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This is essentially augustss's proposal from ticket #1409: I would settle for a solution where I annotate those entities in a module that would go in the hs-boot file. So instead of me having to go through the trouble of creating an extra file I could just say, e.g., Replying to [comment:13 augustss]: > I would settle for a solution where I annotate those entities in a module that would go in the hs-boot file. So instead of me having to go through the trouble of creating an extra file I could just say, e.g., > > {{{ > {-# MODULE_MUTUAL_RECURSION_BREAKER T, foo #-} > data T = ... > foo :: ... > foo = ... > }}} > > The values that have an annotation would have to have a type signature. This should be eminently doable. Here is a more fleshed out proposal. First, consider the definition of an hs-boot file in the absence of mutual recursion (i.e. no breakers are necessary). In this case, the hi-boot file for an hs file is precisely the hi file produced after ordinary renaming and typechecking of the module. As an optimization, we would like to avoid typechecking definitions if an explicit type signature is present (if the type signature is absent, we have no choice.) There are a few choices here: we can force users to give top-level declarations for all exported functions (so unconditionally error if something is missing, by filtering out the relevant value declarations from the source), or we can go ahead and do full typechecking when the signature is missing. (The former is probably the simplest.) Now, how to handle breakers? We need to avoid typechecking them, since their recursive dependence means that they would not type check properly. So we should also filter out their type signatures. (Furthermore, if we are inferring some signatures, we need to make sure that their definitions don't rely on any breakers. For this reason, it is probably simplest to just require explicit type signatures.) If the mechanism for specifying breakers is exclusionary (as opposed to an inclusionary method of saying what values are in the signature), there is an awkward problem of syntax for exporting only an abstract type: the logical choices mean the wrong thing (`T(..)` seem to imply the type is eliminated entirely, whereas `T` seems to imply that the type should be eliminated, but not eh constructors.) Summary: 1. Require top-level signatures in hs to hs-boot files(?) 2. Exclusionary or inclusionary signature pragma? 3. Filter out value declarations and excluded files, then rename/typecheck as normal, producing hi-boot file -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9256> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10673: GHCi crashes when decoding with Aeson
by GHC 24 Jul '15

24 Jul '15

#10673: GHCi crashes when decoding with Aeson -----------------------------------------+------------------------------- Reporter: orion | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Keywords: | Operating System: FreeBSD Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+------------------------------- {{{ $ ghci GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> :set -XOverloadedStrings Prelude> let r = "{\"took\":1,\"timed_out\":false,\"_shards\":{\"total\":5,\"successful\":5,\"failed\":0},\"hits\":{\"total\":7,\"max_score\":1.0,\"hits\":[{\"_index\":\"foo\",\"_type\":\"group\",\"_id\":\"2725954419\",\"_score\":1.0,\"fields\":{\"updated\":[\"20150722T053908+0000\"]}},{\"_index\":\"foo\",\"_type\":\"group\",\"_id\":\"9580897143\",\"_score\":1.0,\"fields\":{\"updated\":[\"20150716T205624+0000\"]}},{\"_index\":\"foo\",\"_type\":\"group\",\"_id\":\"3511215163\",\"_score\":1.0,\"fields\":{\"updated\":[\"20150701T024616+0000\"]}},{\"_index\":\"foo\",\"_type\":\"group\",\"_id\":\"22006\",\"_score\":1.0,\"fields\":{\"updated\":[\"20150723T040619+0000\"]}},{\"_index\":\"foo\",\"_type\":\"group\",\"_id\":\"4240142128\",\"_score\":1.0,\"fields\":{\"updated\":[\"20150713T222827+0000\"]}},{\"_index\":\"foo\",\"_type\":\"group\",\"_id\":\"1258498\",\"_score\":1.0,\"fields\":{\"updated\":[\"20150722T134305+0000\"]}},{\"_index\":\"foo\",\"_type\":\"group\",\"_id\":\"1675836265\",\"_score\":1.0,\" fields\":{\"updated\":[\"20150720T222152+0000\"]}}]}}" Prelude> import Data.Aeson Prelude Data.Aeson> decode r :: Maybe Object Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package text-1.1.0.0 ... linking ... done. Loading package attoparsec-0.10.4.0 ... linking ... done. Loading package hashable-1.2.2.0 ... linking ... done. Loading package unordered-containers-0.2.4.0 ... linking ... done. Loading package primitive-0.5.2.1 ... linking ... done. Loading package vector-0.10.9.1 ... linking ... done. Loading package old-locale-1.0.0.6 ... linking ... done. Loading package time-1.4.2 ... linking ... done. Loading package dlist-0.7.1 ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package mtl-2.1.3.1 ... linking ... done. Loading package scientific-0.3.3.0 ... linking ... done. Loading package syb-0.4.1 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package aeson-0.7.0.6 ... linking ... done. Just fromList [("took",Number 1.0),("_shards",Object fromList [("successful",Number 5.0),("total",Number 5.0),("failed",Number 0.0)]),("timed_out",Bool False),("hits",Object fromList [("max_score",Number 1.0),("total",Number 7.0),("hits",Array (fromList [Object fromList [("_type",String "group"),("_score",Number 1.0),("_id",String "2725954419"),("_index",String "foo"),("fields",Object fromList [("updated",Array (fromList [String "20150722T053908+0000"]))])],Object fromList [("_type",String "group"),("_score",Number 1.0),("_id",String "9580897143"),("_index",String "foo"),("fields",Object fromList [("updated",Array (fromList [String "20150716T205624+0000"]))])],Object fromList [("_type",String "group"),("_score",Number 1.0),("_id",String "3511215163"),("_index",String "foo"),("fields",Object fromList [("updated",Array (fromList [String "20150701T024616+0000"]))])],Object fromList [("_type",String "group"),("_score",Number 1.0),("_id",String "22006"),("_index",String "foo"),("fields",Object fromList [("updated",Array (fromList [String "20150723T040619+0000"]))])],Object fromList [("_type",String "group"),("_score",Number 1.0),("_id",String "4240142128"),("_index",String "foo"),Segmentation fault (core dumped) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10673> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #3549: unlit does not follow H98 spec
by GHC 24 Jul '15

24 Jul '15

#3549: unlit does not follow H98 spec -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by lenish): I recently ran into this bug when trying to learn Haskell. I always indent my LaTeX blocks to improve readability, but that doesn't work properly with unlit. The readline function handles prefixed whitespace properly. It's when we get to checking for `\end{code}` after `\begin{code}` that things break. The file I'm working with: {{{ \documentclass[12pt]{article} \begin{document} \maketitle \section{Type Declaration} \begin{code} data Thingy = Thing \end{code} \end{document} }}} Unfortunately, from the original report, it sounds as though the specification requires these lines to not be indented? Being new to Haskell & GHC I've no idea how to go about changing things like that or if such a change is possible. My general impression is that the 'correct' way to do this would be to parse the file, locate `\begin{code}` and `\end{code}` sections that TeX would treat as such (not in comments, etc), and then strip out everything but those blocks. That it does not work this way currently makes this feature way less enticing to me, as I won't be able to create maintainable and readable LaTeX files without proper indentation. If there were a desire for this to be reimplemented in Haskell with proper (or a reasonable approximation of proper) TeX parsing then I wouldn't mind trying to figure out how to do that as part of my learning how to program in Haskell project. Again, not sure what the situation is with the specification or even if such a patch would be accepted? I have a relatively simple, hacky patch which prevents leading whitespace from causing `\end{code}` to fail to match. I also modified the PSEUDOCODE section, as it seems to have the same issue. There may be issues with this patch in the event someone had a 1000 character line, but that seems... excessive. {{{#!diff diff --git a/utils/unlit/unlit.c b/utils/unlit/unlit.c index a367a0a..dff43bc 100644 --- a/utils/unlit/unlit.c +++ b/utils/unlit/unlit.c @@ -273,7 +273,15 @@ void unlit(char *file, FILE *istream, FILE *ostream) exit(1); } linesread++; - if (strncmp(lineb,ENDCODE,LENENDCODE) == 0) { + + size_t offset = 0; + for(offset = 0; offset < sizeof lineb; ++offset) { + if (!isWhitespace(lineb[offset])) { + break; + } + } + + if (strncmp(&lineb[offset],ENDCODE,LENENDCODE) == 0) { myputc('\n', ostream); break; } @@ -289,9 +297,17 @@ void unlit(char *file, FILE *istream, FILE *ostream) complain(file, linesread, MISSINGENDPSEUDOCODE); exit(1); } + + size_t offset = 0; + for(offset = 0; offset < sizeof lineb; ++offset) { + if (!isWhitespace(lineb[offset])) { + break; + } + } + linesread++; myputc('\n', ostream); - if (strncmp(lineb,ENDPSEUDOCODE,LENENDPSEUDOCODE) == 0) { + if (strncmp(&lineb[offset],ENDPSEUDOCODE,LENENDPSEUDOCODE) == 0) { break; } } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3549#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0