http://blog.gmane.org/gmane.comp.lang.haskell.glasgow.user hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.user/15112 Hi Claus, I was reading your instructions on the GHC wiki page, http://hackage.haskell.org/trac/ghc/wiki/Building/Windows, and they are wonderful - exactly what I wanted. However, they don't work. When downloading Cygwin you are told to add haskell.org/ghc/cygwin as a path so it can pick up the setup.ini file. However, in the latest version of Cygwin it obvious wants signatures for all the .ini files: --------------------------- Cygwin Setup --------------------------- Unable to get http://www.haskell.org/ghc/cygwin/setup.ini.sig from <http://www.haskell.org/ghc/cygwin> --------------------------- OK --------------------------- Could someone please add the appropriate signature file? Thanks Neil ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== Mitchell, Neil 2008-09-05T14:14:49 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.user/15104 Section 8.3.5 of the documentation says: Arrow notation (see Section 8.9, “Arrow notation ”) uses whatever arr, (>>>), first, app, (|||) and loop functions are in scope. But unlike the other constructs, the types of these functions must match the Prelude types very closely. Details are in flux; if you want to use this, ask! I want to do this. Is there anything special I should know? Pete Peter Gavin 2008-09-03T03:57:57 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.user/15101 While perusing the tickets in the 6.10.1 milestone I spotted 3 that look to be FreeBSD-specific: 2476internal error: awaitEvent: descriptor out of range 2502segfault with GHC.Handle.fdToHandle' 2511unix package doesnt load in ghci on freebsd/amd64 It's unlikely that we'll get to these in time for 6.10.1. Any FreeBSD hackers out there want to take a look? Help/advice is available as usual. There's also one NetBSD-specific ticket: 2351NetBSD defines ELF_ST_TYPE (that one is easy), and one that I think applies to all the *BSDs: 2063Breackage on OpenBSD due to mmap remap (actually the latter one is a top priority, because without it GHCi can't work, so we need it fixed for 6.10.1). Cheers, Simon Simon Marlow 2008-09-02T12:37:27 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.user/15099 Hello, I have some code giving me the error message: “GADT pattern match in non-rigid context for … Tell GHC HQ if you'd like this to unify the context”. I reduced my code to the following example which still gives this error message: How do I work around this error? Some former e-mail discussion gave the hint of adding a type signature but this probably doesn’t work in my case. Note also that specializing the type of the argument t to T a b inside the definition of f is not an option since in the real code I need the first argument of T to be universally quantified for calling another function which needs this quantification. I use GHC 6.8.2. Don’t know whether this problem still shows up with GHC HEAD but am interested in hearing whether this is the case. I’m thankful for any help. Best wishes, Wolfgang Wolfgang Jeltsch 2008-09-02T11:20:01 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.user/15098 Hi, Looking at: http://www.haskell.org/ghc/dist/current/dist/ The latest Windows binary appears to be the 22nd of June, and thus is before things such as the Control.Exception changes, and will not work with the current version of Haddock. Is it possible to get an updated binary? From what I remember, these snapshots are also used for the Windows binary release, so will have to be fixed before 6.10 can be released. Thanks Neil ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== Mitchell, Neil 2008-09-02T09:49:09 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.user/15096 This email is inspired by the discussion here: http:// hackage.haskell.org/trac/ghc/ticket/2401 As the ticket discusses, unsafeIOToSTM is, unlike unsafePerformIO or unsafeInterleaveIO, genuinely completely unsafe in that there is no way to use it such that a segfault or deadlock is not at least somewhat encouraged. The code attached to the ticket creates a deadlock solely through using it to write to stdout. But, for the same reason that unsafeIOToSTM is unstable, unsafeInterleaveIO now is very unstable as well -- conceivably, data generated from functions with lazy IO (including those in the prelude) could cause deadlocks within STM, and even segfaults. In summary, a "validation" step is performed on all threads inside atomically blocks during garbage collection. This validation step will, on encountering invalid threads (i.e. ones which should be rolled back) immediately kill them dead and retry. This is different than the implementation described in the STM paper, where rollbacks only occur on commit. However, it does add a measure of efficiency. The problem is that the validation code disregards exception handlers, since rollback is not an exception, and so anything embedded in STM that brackets an IO action, for example, can be rolled back without the final part of the exception even being called. As Simon M. notes, the obvious solution would be to turn rollbacks into regular exceptions, but this would open a number of cans of worms. A start, though not sufficient, would be for stm validation to respect blocked status -- not to block on it, obviously, but simply to refuse to rollback a transaction within it. Validation on GC is, after all, only an efficiency trick and implementation detail, and if it lets the occasional invalid transaction stand due to its blocked status, that transaction will simply be cleaned up later anyway. A more thorough solution would be, as I suggest at the end of the ticket, to add a new primitive with similar semantics to block -- blockRollback, of type STM () -> STM (). Anything that took place within blockRollback could not be stopped by validation. Finally, we could "split the difference" between block and blockRollback, by simply setting a rollbackBlocked flag on a *top level* invocation of block within STM, and thenceforth, not unsetting it until that block is exited, regardless of calls to unblock nested inside. This would effectively, without introducing a new primitive, ensure that rollback did not disrupt things terribly, and thus would be the solution that handled the lazyIO issue the best as well. There are lots of interesting applications of STM that require the ability to extend its semantics. To do this is going to require unsafeIOToSTM, just as unsafePerformIO is used on occasion as a low level tool to create safer and better things on top of (or as unsafeCoerce is, for that matter). However, the current state of STM means that writing these extensions of STM semantics safely is 100% impossible. I'm not sure which, if any, of the solutions that I'm presenting seem the most reasonable. However, without some sort of resolution for this issue, STM is far less powerful and useful than it can and should be. --Sterl. Sterling Clover 2008-08-30T18:53:19 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.user/15057 Friends There's been quite a bit of discussion about GHC's build system recently, and in particular about the use of Cabal. Responding to that discussion we now have a new plan, described here: http://hackage.haskell.org/trac/ghc/wiki/Design/BuildSystem If you've taken an interest in the earlier thread, now would be a good time to look at our plan and help us improve it. In concrete terms, we propose to develop the changes (which should not be a radical upheaval) on a branch, and merge them into the head *after* the 6.10 code fork. So the new build system won't be on the 6.10 branch. It'll take a while to make the new system stabilise, and we want to get 6.10 out! Some comments and suggestions are best done by email, but please feel free to clarify or amplify wording on the Wiki itself, or add lists of questions and open issues. The two media are suitable for different things. But we do want to end up with a *comprehensible* description, with long-term value, of how the new system works, so where things are obscure please help us to clarify it. All this is somewhat separate to the question of what version control system to use for what. We're still working on that question! Simon Simon Peyton-Jones 2008-08-26T15:50:51 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.user/15054 Hello GHC, This page http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/IntegratedCodeGen mentions a to-be-developed "dataflow rewriting engine". Can someone please send a description of what this will do? Thanks! Chad Scherrer 2008-08-22T21:20:32 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.user/15044 _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users< at >haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users Venkat Ramanan 2008-08-21T20:19:00 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.user/15039 I seem to be unable to join the ghc chatroom at irc.freenode.net at the moment (using Opera). Is that an issue with my irc client or a general problem? 15:47 Joining chat room... Disconnected from chat Claus Claus Reinke 2008-08-20T14:52:13 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.user/15023 I have a Haskell script called "notify", without a .hs extension, which causes some problems. (I'm using ghc 6.8.3.) First attempt: runhaskell notify Without the .hs extension, ghc doesn't know it's a Haskell script, and so I get "Could not find module `notify'". Maybe runhaskell should automatically add "-x hs" to the ghc command? Second attempt: runhaskell -x hs notify This get me "Not in scope: `main'". runhaskell is invoking ghc with these arguments: -ignore-dot-ghci -x -e ':set prog "hs"' -e ':main ["notify"]' hs So it looks like runhaskell it treating "-x" as an argument to be relayed to ghc, "hs" as the name of the script, and "notify" as an argument to the script. I guess I need to use "--" to make it clear where the ghc arguments end and where the script and its arguments begin. Third attempt: runhaskell -- -x hs -- notify This gets me "Not in scope: `main'" again. runhaskell is invoking ghc with these arguments: -ignore-dot-ghci -x -e ':set prog "hs"' -e ':main ["--","notify"]' hs This looks like a bug in the "--" handling, unless I'm misinterpreting the usage message I get from running plain "runhaskell". Fourth attempt: ghc -ignore-dot-ghci -e ':set prog "notify"' \ -e ':main []' -x hs notify This works, but passing arguments becomes rather cumbersome. If there's a way to get runhaskell to pass "-x hs" in the right place, that would be much better. A somewhat related issue: I'd like to avoid hard-coding the path to runhaskell or ghc in the #! line. Instead, I'd like to use #!/bin/sh, and have the shell find runhaskell or ghc in $PATH. This means the first few lines of the script would have to be executed by sh, but ignored by ghc. Most scripting langauges have some way of doing this, although it's often by accident. The best way I've seen is in Guile, where "#!" starts a multi-line comment, and "!#" ends it. For Haskell, this is the best I could come up with: #!/bin/sh {- > /dev/null 2>&1 exec ghc -ignore-dot-ghci \ -e ":set prog \"$0\"" \ -e ':main []' -x hs "$0" -} But this depends on "{-" not existing as an executable command, or at least not doing anything harmful when invoked like this. I'd like to avoid depending on anything like that. Does anyone have any better ideas? paul Paul Jarc 2008-08-18T03:45:30 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.user/15002 _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users< at >haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users Sean Leather 2008-08-15T15:06:19 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.user/14994 Hello folks, Christian I'm trying to get ghc 6.8.2 running on Solaris 10 and having problems. To be precise, I'm trying to compile a 'hello world' program by ghc 6.8.2 which I got in binary form haskell.org. gcc is 2.95, it uses sun linker. I remember there were problems with that in the past. Is ghc supposed to work only with gnu ld or sun ld as well? So, how it went first I got compiler errors in many places of Reg.hs: global register variable follows a function definition Googling showed that Don Stewart used to fix it by swapping 2 includes in Stg.h - putting MachRegs.h after Regs.h instead of before. It helped Then there was assembler error: cannot use v8plus instructions in a non-v8plus target binary It was caused by -mcpu=v9, which ghc passes to gcc. I blindly added -optc -mcpu=v8 and it helped :) Then the linker complained that it could not resolve aio_fork and __aio_suspend64, referenced from librt.so. -lrt is passed by ghc to the linker. On this machine there is /lib/libaio.so. Linking with it didn't help. It doesn't really contain exactly those functions, only with slightly different names, like _aio_forkinit, _libaio_fork. Also, librt which was linked in was the one lying close to where gcc is installed. Apart from that, there is also librt.so in /lib. I thought, maybe the wrong librt was used and said -optl -L/lib to link against the one in /lib. No complaints, but the resulting binary segfaults. Does anybody have any ideas? Daniil Elovkov 2008-08-15T12:54:46 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.user/14970 _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users< at >haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users Sean Leather 2008-08-14T17:27:08 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.user/14921 _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users< at >haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users Nicola Squartini 2008-08-12T19:36:12 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.user/14903 Simon PJ and I had a talk about the build system earlier today, I thought I'd float the idea we discussed (I should admit that the idea was mine, lest Simon PJ think I'm attributing bad ideas to him :-). This is not completely thought through, but I'm pretty sure a solution exists along these lines that would improve things for us. Ok, the starting point is this: - Cabal has code to generate Makefiles. Almost nobody uses it except for the GHC build system. It essentially duplicates the build system for compiling Haskell source (but not for installation, haddocking, registration, configuration, etc.) - Cabal is a library I propose we do this: - Extract the code from Cabal that generates Makefiles, and treat it as part of the GHC build system. Rather than generating a Makefile complete with build rules, we generate a Makefile that just has the package-specific metadata (list of modules, etc.), and put the code to actually build the package in the GHC build system. This means we still get to use 'make', we still get to use the .cabal files as metadata, but the build system is more private to GHC, more extensible, and hopefully more understandable and modifiable. We can express dependencies that Cabal currently doesn't know about. It would let us avoid the current uncomfortable situation where we have to feed all kinds of configuration information from the GHC build system into Cabal - Cabal would be essentially just a mechanism for translating the .cabal file into Makefile bindings and package metadata for ghc-pkg. There will undoubtedly be some sticking points where we have to tradeoff duplicating things from Cabal against re-using parts of Cabal which might require modifying Cabal itself. For instance, we could use Cabal for installation, but that means that our build system has to leave everything in the places that Cabal's installation code expects, so it might be more feasible to do installation ourselves, but that means duplicating parts of Cabal. It will probably mean that we have a tighter dependency on Cabal, because we use it as a library rather than a black box; but hopefully we can keep our branch of Cabal more stable and not have to update it so often. Anyway, this is an idea that I think is interesting. Obviously it needs a lot more fleshing out to be a real proposal, but I'm interested in whether anyone thinks this idea is worth persuing, or whether there are better alternatives. Cheers, Simon Simon Marlow 2008-08-12T10:11:38 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.user/14886 Eric Mertens kindly did some experiments on the various git repos, and servers, and approaches to serving. * We're looking at >45 mins for a full history darcs get of ghc, over http, from darcs.haskell.org. * git clone of full ghc over http, from darcs.haskell.org, completes in the range of 6-7 minutes (roughly 150KiB/s) * git clone over git protocol, using github's bandwidth, completes in 2.1 minutes. (roughly 560KiB/s) So that indicates a significant improvment by switching to the git:// server protocol. Can we get that on darcs.haskell.org? In general git is doing a good job here addressing slow 'darcs get ' times, which are now way way down. This will make life easier for some of us. Mirroring automatically to github could also address some of our redundancy concerns. Don Stewart 2008-08-11T21:15:37 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.user/14879 Friends The use of flags to control rewrite rules in GHC is very confusing. Several bug reports arise from this. There is a summary here: http://hackage.haskell.org/trac/ghc/ticket/2497 The final comment is a proposal, which I append below. This email is just to allow others to comment on the proposed change. It's all minor and tiresome, but I don't want to change it and then find it's still awkward. NB: please read the whole ticket if you want to comment on these proposals. And add your comments to the ticket. Simon * Do not add -XRewriteRules. A RULE is in a pragma, and so is silently ignored by other compilers anyway. Other pragmas like SPECIALISE do not have a language extension flag. They will generate errors if they are plain wrong (e.g. variables out of scope). But adding a language flag would be inconsistent. * Inside a RULE, switch on the forall-as-keyword in the lexer, unconditionally. Simon M will do this, and send a patch to Simon PJ for validation. * Merge the -XScopedTypeVariables and -XPatternSignatures flags. Distinguishing them isn't senseless, but it's jolly confusing. * Inside a RULE, switch on -XScopedTypeVariables unconditionally. * Change -frewrite-rules to -fuse-rewrite-rules; deprecate the former. Simon Peyton-Jones 2008-08-11T12:14:47 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.user/14841 Hi all, With the upcoming switchover to git, has any thought gone into merging in the libraries into the main ghc tree (eliminating the need for a 'git-all')? git can merge two histories with no common ancestor, so no history would be lost - though you'd have to ask greater gurus than I the proper procedure. It's been done a few times on git itself to fold in externally developed tools. As I understand it, you could even continue development of the libraries on a seperate tree, as long as you don't try merging changes on ghc.git to $library.git, unless you filter out the GHC-only changes first somehow (merging $library.git back into ghc.git, as I understand it, should work...). Not sure if I'm missing something here, or if it's impractical for some reason... Thanks, Bryan Donlan Bryan Donlan 2008-08-07T18:07:07 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.user/14838 IRC Meeting today at 1600 UK time as usual (1500 UTC, 0800 PDT, 1100 EDT). A couple of suggestions for topics; - HEAD stability (re previous disccusion on cvs-ghc) - mechanics of the git switchover Cheers, Simon Simon Marlow 2008-08-06T13:43:35 http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.user/14821 I am pleased to announce the release of prof2dot version 0.4.1, a graphical profiling tool for use with GHC. The program is a filter that takes the profiling output generated by running a GHC-compiled program with the "+RTS -px -RTS" option and turns it into a dot file. (The "dot" format is a textual representation of a directed or undirected graph.) The dot file can rendered in any format supported by Graphviz's dot program, and the file itself can be post-processed or edited to adjust the layout. The new release fixes a number of bugs and has some significant improvements in its internal organization over the previous 0.3.1 ("Premature Optimizations 'r' Us") release. Version 0.4.1 ("Triumph of Hope Over Experience") defaults to generating a call graph colored by number of entries into each call center. There is now an option to annotate the graph edges with the triple of (cost center entries, ticks, allocations). Module names are also given in each cost center. The latest version has been tested on the profiling output of some moderately large programs, e.g., the profile produced by a "darcs get" of the entire ghc repository: $ darcs get http://darcs.haskell.org/ghc +RTS -px -RTS There is also better error reporting of parser errors and consistency checking of the internal graph data structure. If anyone comes across a parse failure or an assertion failure, please report it to the author. The "dot" program from the graphviz tools is required to render the output of prof2dot. Very large graphs, or graphs with extensive annotations, can exceed the capabilities of dot. Prof2dot is available from Hackage in the "development" category. -Greg Gregory Wright 2008-08-05T19:50:26 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lang.haskell.glasgow.user