November 2014 - Glasgow-haskell-users

More flexible literate Haskell extensions (Trac #9789), summary on wiki
by Merijn Verstraaten 16 Nov '14

16 Nov '14

As requested on my ticket I summarised the entire proposal on the wiki here: https://ghc.haskell.org/trac/ghc/wiki/FlexibleLiterateExtension I don't expect a lot of disagreement on discussion, aside from minor bike shedding on the flavour of the extension. I've started implementing this already. I'm open to bikesheds on exact extension, as it shouldn't affect the implementation. Unless there's any vehement objections, I'll produce a diff on fabricator asap. Cheers, Merijn

3 5

Re: More flexible literate Haskell extensions (Trac #9789), summary on wiki
by Simon Hengel 14 Nov '14

14 Nov '14

On Fri, Nov 14, 2014 at 03:53:13PM +0800, Simon Hengel wrote: > > Can you explain why this would not solve your usecase? i.e., why would > > README.lhs.md not suffice? > > I haven't tried, but my assumption was that this is not picked up by > GitHub. I just verified, GitHub dose not pick up README.lhs.md files as READMEs, meaning that a README.lhs.md file will not be rendered as a projects README file on GitHub. Cheers, Simon

1 0

Re: More flexible literate Haskell extensions (Trac #9789), summary on wiki
by Jan Stolarek 14 Nov '14

14 Nov '14

.lhs = Literate Haskell So maybe .mhs = Markdown Haskell instead of .lhs+md? Jan

1 0

Rules for class methods and Safe Haskell
by Wolfgang Jeltsch 13 Nov '14

13 Nov '14

Hi, the module Control.Arrow declares a set of rules for the Arrow class. It is marked “Trustworthy”, probably to allow these rules to actually fire. Now these rules are only correct for class instances that actually satisfy the arrow laws. If the author of another module defines an instance of Arrow that does not respect the laws, this other module could still be considered “Safe” by GHC, although the rules from Control.Arrow are bogus now. Is this considered a problem? All the best, Wolfgang

2 2

Under what conditions are finalizers not run?
by Wolfgang Jeltsch 13 Nov '14

13 Nov '14

Hi, the documentation of System.Mem.Weak under <http://hackage.haskell.org/package/base-4.7.0.1/docs/System-Mem-Weak.html> says the following: > It is not guaranteed that a finalizer will eventually run, and no > attempt is made to run outstanding finalizers when the program exits. In which situations are finalizers not run? I see that they might not be run when the program ends while the weak pointer is still alive, but are there also other situations? The above quote seems to say that even an implementation that ignores any finalizers would conform to the API specification. I think it is actually quite bad if you do not have any guarantees about when finalizers are run. In the memo table example, for instance, this would mean that the memo table could grow very large, which would not just result in bad space complexity, but also bad time complexity for lookups. I am actually particularly interested in adding finalizers to IORefs. Are there any stronger guarantees for finalizers attached to IORefs and MVars? All the best, Wolfgang

1 0

RFC: Dropping Windows XP support
by Austin Seipp 13 Nov '14

13 Nov '14

Hi all, This is a quick discussion about the current system requirements for Windows builds. Spurred by a recent[1] LLVM discussion, I'd like to raise the question of dropping support for Windows XP, and bumping the minimum required version to Windows Vista or even Windows 7. For one, Microsoft doesn't support XP anymore, so most people are moving off it anyway. 'Soon' even XP Embedded will be obsoleted. But second, Vista and beyond introduced useful new APIs we could use. I was digging through the LLVM thread and two came out to me: 1) We could switch to using slim reader/writer locks, which in some workloads may work out better than critical sections (they'll win on more read-heavy workloads). The downsides is there's no recursive locking but we don't use that anyway (and recursive locks are considered bad by many anyway[2]). 2) We could probably use an actual condition variables API that was introduced with Vista. Currently we use a giant EVENT object to emulate the API, which could be replaced with the real deal. Both of these could be nice wins for simplicity and performance I think. I know there are some corporate users out there who this may impact, and users as well. I'd like to know what people think. Particularly what version we should standardize on. FWIW, I don't plan on changing any of this until the 7.12 release at least. [1] http://article.gmane.org/gmane.comp.compilers.llvm.devel/78419 [2] http://www.zaval.org/resources/library/butenhof1.html -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

5 4

GHC 7.8.3 thread hang
by Michael Jones 13 Nov '14

13 Nov '14

I am trying to debug a lockup problem (and need help with debugging technique), where hang means a thread stops at a known place during evaluation, and other threads continue. The code near the problem is like: ec <- return $ encode command l <- return $ BSL.length ec ss <- return $ BSC.unpack ec It does not matter if I use let or return, or if the length is taken after unpack. I used return so I could use this code for tracing, with strictness to try to find the exact statement that is the problem: traceEventIO "sendCommand" ec <- return $ encode command traceEventIO $ "sendCommand: encoded" l <- ec `seq` return $ BSL.length ec traceEventIO $ "sendCommand: size " ++ (show l) ss <- ec `seq` return $ BSC.unpack ec When this runs, the program executes this many times, but always hangs under a certain condition. For good evaluations: 7f04173ff700: cap 0: sendCommand 7f04173ff700: cap 0: sendCommand: encoded 7f04173ff700: cap 0: sendCommand: size 4 7f04173ff700: cap 0: sendCommand: unpacked 7f04173ff700: cap 0: Sending command of size 4 7f04173ff700: cap 0: Sending command of size "\NUL\EOT" 7f04173ff700: cap 0: sendCommand: sent 7f04173ff700: cap 0: sendCommand: flushed for bad evaluation: 7f04173ff700: cap 0: sendCommand 7f04173ff700: cap 0: sendCommand: encoded The lockup occurs when length is taken. The difference between the working and non-working case is as follows: A wxHaskell callback stuffs some data in a TChan. A thread started at application startup is reading the TChan and calling the code that hangs. If it did not hang, it would send it by TCP to another process/computer. In the working case the callback pops a dialog, and passes data from one TChan to another TChan. In the failing case, the data is used to generate strings in a wxHaskell grid, then it is parsed, and a new data is made. The new data is a combination of old and new pieces of sub data. The shape of the date is identical, because I am not making any edits to the rows. So when data that the callback sends to TChan is unmodified, no hang. But when the data is used to make text, put it in the gui, process it, and generate new data, it hangs. As a test I modified the code so that the text is not put into the gui. The results are the same. This indicates it has something to do with creating strings and then data from strings and mixing old and new subdata. Strings are created with show. Data is created by pattern matching and generating numbers from strings. I should also point out that in the working case, the size of the resulting string is small, say 3. In the hang case, the resulting string would be long, say 5000-10000. I assume there are no limits to the size of ByteStrings or fundemental issues with the RTS stack/heap that require special settings. I am using the following revisions: GHC 7.8.3 base ==4.7.*, mtl ==2.2.1, containers == 0.5.5.1, transformers ==0.4.1.0, random == 1.0.1.1, wx == 0.91.0.0, wxcore == 0.91.0.0, wxdirect == 0.91.0.0, colour == 2.3.3, stm == 2.4.2, monad-loops == 0.4.2.1, time == 1.4.2, old-locale == 1.0.0.6, fast-logger == 2.2.3, network == 2.6.0.2, bytestring == 0.10.4.0, control-monad-loop == 0.1, binary == 0.7.2.2, I know that nobody can have an answer based on this. But what I am hoping is either there is some known bug, or someone can guide me in narrowing it down. The event log does not have anything unusual in it. Other threads keep running, and I can exit the application normally. The thread does not throw an exception. It just hangs. When I run the app, I just use +RTS -v Perhaps there are some other options that might give more info? — SNIPPET of log — 7fe544cfea40: cap 0: running thread 5 (ThreadRunGHC) 7fe544cfea40: cap 0: thread 5 stopped (yielding) 7fe544cfea40: cap 0: running thread 5 (ThreadRunGHC) 7fe544cfea40: cap 0: thread 5 stopped (suspended while making a foreign call) 7fe544cfea40: cap 0: running thread 5 (ThreadRunGHC) 7fe544cfea40: cap 0: thread 5 stopped (blocked on an MVar) 7fe537eff700: cap 0: running thread 2 (ThreadRunGHC) 7fe537eff700: cap 0: waking up thread 5 on cap 0 7fe537eff700: cap 0: thread 2 stopped (yielding) 7fe544cfea40: cap 0: running thread 5 (ThreadRunGHC) 7fe544cfea40: cap 0: sendCommand 7fe544cfea40: cap 0: sendCommand: encoded 7fe544cfea40: cap 0: sendCommand: size 3 WORKS HERE 7fe544cfea40: cap 0: sendCommand: unpacked 7fe544cfea40: cap 0: Sending command of size 3 7fe544cfea40: cap 0: Sending command of size "\NUL\ETX" 7fe544cfea40: cap 0: sendCommand: sent 7fe544cfea40: cap 0: sendCommand: flushed 7fe544cfea40: cap 0: thread 5 stopped (blocked on an MVar) 7fe537eff700: cap 0: running thread 2 (ThreadRunGHC) 7fe537eff700: cap 0: thread 2 stopped (yielding) 7fe537eff700: cap 0: running thread 2 (ThreadRunGHC) 7fe537eff700: cap 0: thread 2 stopped (suspended while making a foreign call) 7fe537eff700: cap 0: running thread 2 (ThreadRunGHC) 7fe537eff700: cap 0: waking up thread 5 on cap 0 … 7fe537eff700: cap 0: fetchTelemetryServer: got lock 7fe537eff700: cap 0: thread 45 stopped (yielding) 7fe537eff700: cap 0: running thread 7 (ThreadRunGHC) 7fe537eff700: cap 0: thread 7 stopped (heap overflow) 7fe537eff700: cap 0: requesting parallel GC 7fe537eff700: cap 0: starting GC 7fe537eff700: cap 0: GC working 7fe537eff700: cap 0: GC idle 7fe537eff700: cap 0: GC done 7fe537eff700: cap 0: GC idle 7fe537eff700: cap 0: GC done 7fe537eff700: cap 0: all caps stopped for GC 7fe537eff700: cap 0: finished GC 7fe537eff700: cap 0: running thread 7 (ThreadRunGHC) 7fe537eff700: cap 0: sendCommand 7fe537eff700: cap 0: sendCommand: encoded PROBLEM HERE 7fe537eff700: cap 0: thread 7 stopped (heap overflow) 7fe537eff700: cap 0: requesting parallel GC 7fe537eff700: cap 0: starting GC 7fe537eff700: cap 0: GC working 7fe537eff700: cap 0: GC idle 7fe537eff700: cap 0: GC done 7fe537eff700: cap 0: GC idle 7fe537eff700: cap 0: GC done 7fe537eff700: cap 0: all caps stopped for GC 7fe537eff700: cap 0: finished GC 7fe537eff700: cap 0: running thread 7 (ThreadRunGHC) 7fe537eff700: cap 0: thread 7 stopped (yielding) 7fe537eff700: cap 0: running thread 2 (ThreadRunGHC) 7fe537eff700: cap 0: thread 2 stopped (yielding) 7fe544cfea40: cap 0: running thread 442 (ThreadRunGHC) 7fe544cfea40: cap 0: thread 442 stopped (suspended while making a foreign call) 7fe544cfea40: cap 0: running thread 442 (ThreadRunGHC) 7fe544cfea40: cap 0: thread 442 stopped (suspended while making a foreign call) 7fe537eff700: cap 0: running thread 45 (ThreadRunGHC) 7fe537eff700: cap 0: fetchTelemetryServer: unlock 7fe537eff700: cap 0: fetchTelemetryServer 7fe537eff700: cap 0: fetchTelemetryServer: got lock 7fe537eff700: cap 0: fetchTelemetryServer: pump seq

5 11

Annotations: status and documentation
by Greg Weber 06 Nov '14

06 Nov '14

I would like to be able to retrieve user-supplied annotations in Template Haskell. The 7.8 user manual doesn't mention this ability. However, I see this Trac page: https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Annotations Where it appears that this feature may exist in 7.8. I will gladly tinker with annotations and update the user manual if someone will help me understand what the situation is. On a related note, it looks like this patch pointed to from the Wiki page for annotations got ignored. Should i submit it to phabricator? https://ghc.haskell.org/trac/ghc/ticket/8460 Thanks, Greg Weber

1 2

Re: GHC Trac
by John Wiegley 03 Nov '14

03 Nov '14

>>>>> Simon Peyton Jones <simonpj(a)microsoft.com> writes: > Is it just me, or is the GHC Trac soul-destroyingly slow at the moment? IT > takes minutes to load one page! You may be interested in the Mylyn plugin for the Eclipse IDE, which allows for downloading and offline browsing of issues in Trac. That could speed up your "hop to next bug" time, at the cost of installing Eclipse solely for that purpose. John

1 0