[Haskell-cafe] Upgrading GHC 7.6.3 global packages to latest versions
Hi, I am trying to install the latest version of some hackage packages I use often in GHC 7.6.3. However, I am having some problems with packages like [containers] and [time], which are shipped with GHC as global packages. Now when I try to install the latest version of the [time] package, I have 2 time packages, 1 in the global package db (the older version), and 1 in the user package db (the newer version). Now I would like subsequent installed packages to always use the latest version of the [time] package. But if i try to install the [plugins] package, cabal says: #In order, the following would be installed: #ghc-paths-0.1.0.9 (new package) #random-1.0.1.1 (reinstall) changes: time-1.4.1 - 1.4.0.1 #plugins-1.5.3.0 (new package) So I guess I have 2 options here: 1. unregister all the global packages so that I can install the latest versions of all the global packages. 2. force cabal to only look at latest packages in user package db (not sure if this is possible). Can anyone please point me in the right direction here. I have read about [cabal-dev], but I am not sure if it can be used to solve my problem. Regards --Rouan___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: module-management-0.9.3 - clean import lists, split and merge modules
David Fox d...@seereason.com writes: Cliff Beshers wrote a CLI for this, I will add it as a cabal executable in the next version. Oh, also, I was unable to build the library using GHC 7.4.2. It looks like it still depends on the old Exception stuff that used to be Prelude? -- John Wiegley FP Complete Haskell tools, training and consulting http://fpcomplete.com johnw on #haskell/irc.freenode.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] LLVM Backend status
Great! Its very very nice to hear that! Has Haskell somewhere a technical documentation focused on LLVM usage? (for exampel about GHC's custom calling convention) 2013/6/28 Erik de Castro Lopo mle...@mega-nerd.com Erik de Castro Lopo wrote: B B wrote: 1) Is the LLVM Backend actively developed or should I be afraid it will be discontinued or broken? My understanding is that it is being actively developed. Currently for numerical code, the LLVM backend performs better than the native codegen. I also think that the LLVM backend is the only option for ARM. And there was a lareg set of patches for the LLVM backend applied just now: http://www.haskell.org/pipermail/ghc-commits/2013-June/002324.html and the following 10 or so commit. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ghci ghc - JS (Emscripten)
Hi! Does anybody tried, or is there anywhere a project, of online ghc or ghci (compiled to JavaScript with Emscripten)? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: module-management-0.9.3 - clean import lists, split and merge modules
Excerpts from John Wiegley's message of Fri Jun 28 05:46:31 +0200 2013: How about building an executable along with the library called cleanImports, Does it require knowledge about the libraries to be used? If so eventually it should be a cabal option? Or it should be able to load dependencies from a cabal configure file (.dist/something). Then there should also be an env var CABAL_CURRENT_DIST_DIR or such, because sometimes you want to work on multiple dist directories. cabal could honor this itself. Then you could export CABAL_CURRENT_DIST_DIR=dist-foo ./Setup configure ./Setup build cleanImports FOO And everything would work without --dist-dir=dist-foo parameter ? Marc Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ghci ghc - JS (Emscripten)
I don't know of any complete implementation. The LLVM code produced by GHC might be hard to compile to JavaScript, since JS does not have tail call optimization. You would also need to get the RTS working, including the garbage collector. It's written in C and Cmm, both of which can be compiled to LLVM, but often in practice it's not that easy to get it working properly. We do have a working Haskell compiler based on GHC with GHCJS [1], which uses the GHC API to translate STG code to JavaScript. We do a fairly high-level translation, compiling Haskell closures to JavaScript objects, so that we use as much of the JS runtime, like the garbage collector, as possible. I have spent some time optimizing the performance, making sure that the code is reasonably optimizable by the JS JIT compilers, makes effective use of the inline caches etc, but it's quite possible that a lower level LLVM/asm.js would give us better performance. For the moment though, we want to concentrate on other things, like getting a release ready before GHC 7.8.1 is out (and getting the patches to support GHCJS merged in GHC), building more libraries, and reducing the size of the generated code. Dan Frumin [2] is working for his Google Summer of Code project on an pastebin that uses GHCJS and the diagrams [3] library that lets the user run the code directly. Generated code supports graphics, functional reactive programming etc, and can be included on other pages. Code is compiled on the server, since GHC itself is a bit too big to compile to JavaScript. For more information on GHCJS, see my weblog [4] [5]. In the past we have already had multiple code generators, if you want to work on one that uses LLVM as the source language we would be happy to add it, and you can use the GHCJS Cabal support, testsuite etc. If it's clearly better than the existing one, it can replace it one day as the default generator. luite [1] GHCJS: https://github.com/ghcjs [2] Dan Frumin's weblog: http://parenz.wordpress.com/ [3] Diagrams library: http://hackage.haskell.org/package/diagrams [4] GHCJS introduction: http://weblog.luite.com/wordpress/?p=14 [5] Functional Reactive Programming with GHCJS and sodium: http://weblog.luite.com/wordpress/?p=127 On Fri, Jun 28, 2013 at 3:25 PM, B B blackbox.dev...@gmail.com wrote: Hi! Does anybody tried, or is there anywhere a project, of online ghc or ghci (compiled to JavaScript with Emscripten)? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ghci ghc - JS (Emscripten)
On Fri, 28 Jun 2013 15:25:59 +0200, B B blackbox.dev...@gmail.com wrote: Hi! Does anybody tried, or is there anywhere a project, of online ghc or ghci (compiled to JavaScript with Emscripten)? There is Try Haskell![0], source code can be found on GitHub[1] Regards, Henk-Jan van Tuyl [0] http://tryhaskell.org/ [1] https://github.com/chrisdone/tryhaskell -- Folding@home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ghci ghc - JS (Emscripten)
My understanding is that Try Haskell actually runs the submitted code on a server with mueval rather than compiling it to JavaScript and running it in the client. This is different from some of the other try websites (like try.ocamlpro.com), so it's easy to get confused. On Fri, Jun 28, 2013 at 11:24 AM, Henk-Jan van Tuyl hjgt...@chello.nlwrote: On Fri, 28 Jun 2013 15:25:59 +0200, B B blackbox.dev...@gmail.com wrote: Hi! Does anybody tried, or is there anywhere a project, of online ghc or ghci (compiled to JavaScript with Emscripten)? There is Try Haskell![0], source code can be found on GitHub[1] Regards, Henk-Jan van Tuyl [0] http://tryhaskell.org/ [1] https://github.com/chrisdone/**tryhaskellhttps://github.com/chrisdone/tryhaskell -- Folding@home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/**hjgtuyl/tourdemonad.htmlhttp://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- __**_ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Upgrading GHC 7.6.3 global packages to latest versions
Hi! In shipped with GHC, did you mean Haskell Platform? If so, cabal-dev is one way to solve your problem here. You can do #1 too, but that would probably break some packages. On 28 June 2013 10:06, Rouan van Dalen rvda...@yahoo.co.uk wrote: Hi, I am trying to install the latest version of some hackage packages I use often in GHC 7.6.3. However, I am having some problems with packages like [containers] and [time], which are shipped with GHC as global packages. Now when I try to install the latest version of the [time] package, I have 2 time packages, 1 in the global package db (the older version), and 1 in the user package db (the newer version). Now I would like subsequent installed packages to always use the latest version of the [time] package. But if i try to install the [plugins] package, cabal says: #In order, the following would be installed: #ghc-paths-0.1.0.9 (new package) #random-1.0.1.1 (reinstall) changes: time-1.4.1 - 1.4.0.1 #plugins-1.5.3.0 (new package) So I guess I have 2 options here: 1. unregister all the global packages so that I can install the latest versions of all the global packages. 2. force cabal to only look at latest packages in user package db (not sure if this is possible). Can anyone please point me in the right direction here. I have read about [cabal-dev], but I am not sure if it can be used to solve my problem. Regards --Rouan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Who uses Travis CI and can help write a cookbook for those guys?
The Travis folks have decided they want to support Haskell better (multiple compiler versions): https://github.com/travis-ci/travis-ci/issues/882#issuecomment-20165378 (Yay!) They're asking for someone to help them up with setup scripts. They mention their cookbook collection here: https://github.com/travis-ci/travis-cookbooks In that thread above, I pasted our little script that fetches and installs multiple GHC versions, but I have little experiences with cloud technologies VMs. Can someone jump in and help push this forward? As a community I'm sure it would be great to get a higher percentage of Hackage packages using simple, hosted continuous testing... I'd personally like to replace my Jenkins install if they can get the necessary GHC versions in there. Best, -Ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] some questions about Template Haskell
Hi everybody,
I am trying to learn Template Haskell, and I have two independent questions.
1/ First, the following code (which is not in its final version, but it is a
test) does not compile:
---
{-# LANGUAGE TemplateHaskell #-}
module Pr where
import Language.Haskell.TH
pr :: Name - ExpQ
pr n = [| putStrLn $ (nameBase n) ++ = ++ show $(varE n) |]
---
I obtain:
---
No instance for (Lift Name) arising from a use of `n'
Possible fix: add an instance declaration for (Lift Name)
In the first argument of `nameBase', namely `n'
---
Why? Indeed, there is no typeclass constraint on n in the definition of
nameBase:
ghci :t nameBase
nameBase :: Name - String
Contrary to lift for example:
ghci :t lift
lift :: Lift t = t - Q Exp
2/ If I define in a module:
j = 3
and then define in another module:
---
h x = $([|j|])
main = do
print $ h undefined
---
I obtain 3 as expected.
However, I do not achieve to make this system work with an infix
declaration:
infix $([| j |]) +
I obtain:
parse error on input `$('
What is the problem?
Thanks in advance,
TP
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] LLVM Backend status
B B wrote: Great! Its very very nice to hear that! Has Haskell somewhere a technical documentation focused on LLVM usage? (for exampel about GHC's custom calling convention) Root page of the compiler comentary is here: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler with info about the LLVM backend here: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM It seems the custom calling convention may only be documented in the code. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Improving GHC's LLVM Backend
Hello, I'm interested in improving the LLVM backend of GHC by using the existing Haskell LLVM bindings to the C API, as suggested by option 1 in the LLVM FAQ: http://llvm.org/docs/FAQ.html#i-d-like-to-write-a-self-hosting-llvm-compiler-how-should-i-interface-with-the-llvm-middle-end-optimizers-and-back-end-code-generators At the moment, the backend uses the option 2: emitting LLVM assembly code which is then assembled to LLVM bitcode, optimised, and compiled to machine code by standard LLVM tools. Changing this to use the Haskell FFI bindings to the LLVM C API would allow better tracking of any changes to the LLVM IR, and hopefully a reasonable speed increase by avoiding the overhead of first emitting LLVM Assembly to be assembled. In his bachelor's thesis, David Terei considered this approach when initially writing the LLVM backend, but dismissed it due to the existing Haskell bindings being too large and high level to use with GHC. I have not personally looked at the high level Haskell bindings in much depth, but the low level (llvm-base) bindings appear to be somewhat incomplete with respect to LLVM 3.3. Therefore, I plan to extend the FFI bindings to cover more or all of the C API, and then to modify the GHC LLVM backend to use these bindings to call into the LLVM libraries directly. http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVMcontains a link to David's thesis, as well as documentation of the LLVM backend. I'd really appreciate it if anyone who knows about the Haskell LLVM bindings or about the GHC LLVM backend could give any advice regarding what sort of work needs to be done with the LLVM bindings to make them more appropriate for use within GHC, or how to approach modifying the existing LLVM backend. Many thanks, Alex ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Improving GHC's LLVM Backend
Alex, I really suggest you take this to the ghc-devs mailing list. Cheers, Erik Alex Ford wrote: Hello, I'm interested in improving the LLVM backend of GHC by using the existing Haskell LLVM bindings to the C API, as suggested by option 1 in the LLVM FAQ: http://llvm.org/docs/FAQ.html#i-d-like-to-write-a-self-hosting-llvm-compiler-how-should-i-interface-with-the-llvm-middle-end-optimizers-and-back-end-code-generators At the moment, the backend uses the option 2: emitting LLVM assembly code which is then assembled to LLVM bitcode, optimised, and compiled to machine code by standard LLVM tools. Changing this to use the Haskell FFI bindings to the LLVM C API would allow better tracking of any changes to the LLVM IR, and hopefully a reasonable speed increase by avoiding the overhead of first emitting LLVM Assembly to be assembled. In his bachelor's thesis, David Terei considered this approach when initially writing the LLVM backend, but dismissed it due to the existing Haskell bindings being too large and high level to use with GHC. I have not personally looked at the high level Haskell bindings in much depth, but the low level (llvm-base) bindings appear to be somewhat incomplete with respect to LLVM 3.3. Therefore, I plan to extend the FFI bindings to cover more or all of the C API, and then to modify the GHC LLVM backend to use these bindings to call into the LLVM libraries directly. http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVMcontains a link to David's thesis, as well as documentation of the LLVM backend. I'd really appreciate it if anyone who knows about the Haskell LLVM bindings or about the GHC LLVM backend could give any advice regarding what sort of work needs to be done with the LLVM bindings to make them more appropriate for use within GHC, or how to approach modifying the existing LLVM backend. Many thanks, Alex -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
