Re: [Haskell-cafe] how to force hackage to use ghc 6.12.3
On Monday 09 May 2011 12:09:22 Ross Paterson wrote: That will stop users from building it with ghc 7.0, but I'm afraid the build client only uses the latest version, so these won't be fixed until ghc 7.2 is released. Daniel, Ross, Thank you for your help. I decided to add base 4.3 to stop users trying to compile it with ghc 7.* and provided links to haddock documentation hosted elsewhere for the time being. Michal -- |o| Michal Konecny mikkone...@gmail.com |o|http://www-users.aston.ac.uk/~konecnym/ |o|office: (+42) (0)121 204 3462 |o| PGP key http://www-users.aston.ac.uk/~konecnym/ki.aston signature.asc Description: This is a digitally signed message part. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: AERN-Real-Double-2011.1
Dear all, I am pleased to announce the first release of (a large part of) a newly designed AERN. AERN (approximating exact real numbers) is a set of Haskell libraries providing arbitrary precision interval arithmetic, polynomial arithmetic and distributed lazy exact real computation. Anyone is welcome to join in the development of AERN via http://code.google.com/p/aern/ . This release contains the following features: * Type classes for rounded arithmetic and rounded interval arithmetic with explicit control of rounding direction and the possibility to increase the rounding precision arbitrarily for types that support it. For example, type classes for types with rounded addition, multiplication, exponentiation etc. * Over 150 QuickCheck properties for these type classes, such as associativity of multiplication modulo rounding. * Interval arithmetic using Double endpoints, rounded outwards or inwards. Outwards rounding allows to safely approximate exact real arithmetic while a combination of both outwards and inwards rounding allows one to safely approximate exact interval arithmetic. Inverted intervals with Kaucher arithmetic are also supported. * For most of the type classes there are also in-place versions that act in the ST monad on mutable variables containing numbers or intervals. This facilitates some explicit memory allocation optimisation, especially for data on the C heap. The best starting point for experimenting with these features are the demo programs included in the bundle and the documentation for the AERN-Real-Double package: http://www-users.aston.ac.uk/~konecnym/aern/AERN-Real-Double (The HackageDB page does not have Haddock documentation because AERN fails to build with ghc 7.0.* due to a compiler bug.) The following features are planned for future releases: * Interval arithmetic with MPFR arbitrary precision endpoints. * Polynomial interval arithmetic with an optimised C core * Distributed exact real and geometric computation with lazy query-driven communication. For those familiar with the old AERN design, the main changes in the new design are: * use of many smaller type classes instead of few large ones * use of associated types instead of multi-parameter type classes * a much more systematic approach to representing the numerical order on real numbers and the information refinement (ie the inverse set inclusion) order on intervals * ability to specify different effort indicator types for each type of operation and each numerical type instead of Int. (For example, Double has () as its effort indicator for almost all operations while MPFR will have Precision as the effort indicator type.) * a more systematic approach to specifying QuickCheck properties and applying them to form test suites * a unified implementation of interval elementary operations (only sqrt and exp at the moment) that is efficient when applied to Double intervals as well as polynomial intervals * new support for in-place rounded numerical operations The current development team will be grateful for any feedback and suggestions. Best regards, Michal -- |o| Michal Konecny mikkone...@gmail.com |o|http://www-users.aston.ac.uk/~konecnym/ |o|office: (+42) (0)121 204 3462 |o| PGP key http://www-users.aston.ac.uk/~konecnym/ki.aston signature.asc Description: This is a digitally signed message part. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] how to force hackage to use ghc 6.12.3
Hi, I have been releasing packages on hackage that do not build with ghc 7.0.* due to a bug that will be fixed in ghc 7.2.1. (One of the packages is http://hackage.haskell.org/package/AERN-Basics) I was hoping hackage will try also ghc 6.12.3 but it does not. Is there some way I can change the cabal file to help hackage to compile it with 6.12.3 and generate haddock? The package requires base = 4 so I cannot try base 4. Michal -- |-| Dr. Michal Konecny, Computer Science, Aston University |-| Room MB212D | Tel +44 121 204 3462 | Fax +44 121 204 3681 |-| http://www.aston.ac.uk/~konecnym |-| OpenPGP key http://www.aston.ac.uk/~konecnym/ki.aston -- |o| Michal Konecny mikkone...@gmail.com |o|http://www-users.aston.ac.uk/~konecnym/ |o|office: (+42) (0)121 204 3462 |o| PGP key http://www-users.aston.ac.uk/~konecnym/ki.aston signature.asc Description: This is a digitally signed message part. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ghc7 bug? associated type + implicit parameters
Hi,
I have stumbled across some strange behaviour in ghc7.
The following compiles fine with ghc 6.12.3:
{-# LANGUAGE ImplicitParams #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE NoMonomorphismRestriction #-}
module Test where
class C t where
type TF t
ttt :: TF t - t
b :: (C t, ?x :: TF t) = t
b = ttt ?x
but ghc7 says:
Could not deduce (?x::TF t)
arising from a use of implicit parameter `?x'
from the context (C t, ?x::TF t)
bound by the type signature for b :: (C t, ?x::TF t) = t
at Test.hs:13:1-10
In the first argument of `ttt', namely `?x'
In the expression: ttt ?x
In an equation for `b': b = ttt ?x
Moreover, when I comment out the type declaration for b, it compiles and the
inferred type for b is identical to the one in the above program:
*Test :t b
b :: (C t, ?x::TF t) = t
It feels to me like a bug but I am not entirely confident. Any ideas?
Michal
--
|o| Michal Konecny mikkone...@gmail.com
|o|http://www-users.aston.ac.uk/~konecnym/
|o|office: (+42) (0)121 204 3462
|o| PGP key http://www-users.aston.ac.uk/~konecnym/ki.aston
--
|o| Michal Konecny mikkone...@gmail.com
|o|http://www-users.aston.ac.uk/~konecnym/
|o|office: (+42) (0)121 204 3462
|o| PGP key http://www-users.aston.ac.uk/~konecnym/ki.aston
--
|o| Michal Konecny mikkone...@gmail.com
|o|http://www-users.aston.ac.uk/~konecnym/
|o|office: (+42) (0)121 204 3462
|o| PGP key http://www-users.aston.ac.uk/~konecnym/ki.aston
signature.asc
Description: This is a digitally signed message part.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: hmpfr-0.3.2 (requires integer-simple, supports mpfr 3.0.0)
Hi Dan, On Friday 04 Mar 2011 21:59:12 Daniel Peebles wrote: I'm adding Ed to the conversation as he's very interested in this topic, too. I do apologise - I was meant to post the previous email back to haskell-cafe but by mistake it went only to you. I hope you do not mind that I am taking the discussion back to the cafe. I attach my email so that other readers of the cafe can see it. The experts were right about it being impossible to work with GHC's GMP – until recently. foreign import c calls are indeed going to call GC when you don't want it, but when they split integer-gmp out of GHC's own RTS, Duncan Coutts (one of those experts) added the foreign import prim construct so that he could do exactly what you want, and operate on GMP integers with GHC-allocated memory without worrying about temporary storage blowing up while you aren't looking. So in general, I'd lean more towards replacing all your ccall bindings to MPFR with cmm bindings. It does require some GHC internals knowledge but is fairly mechanical, and would solve all the problems, without requiring a rewrite of GMP (that would be slower anyway). Ed is actually going to get started on a fairly simple binding to a subset of MPFR for one of his projects, using the CMM approach based on the structure of my natural-gmp package (https://github.com/pumpkin/natural-gmp, which is itself based heavily on integer-gmp, but reworked to work fine from cabal rather than depending on GHC's build process). Once he is done with that, you might want to refer to his implementation to make your more complete MPFR binding work with integer-gmp (and thus make no speed sacrifices). If this is the best approach, I would welcome help with this as I will not have much time to work on it until the summer due to teaching commitments and the need to publish work done earlier. I would also like a gmp-compatible replacement, but it's going to necessarily be slower and would prefer to be able to have fast computations over floating-point numbers AND integers/naturals. Eek, I made a mistake, I apologise again - the proposal I was quoting in the announcement is not what I had in mind. I was meant to refer to a mention by igloo at the very end of http://hackage.haskell.org/trac/ghc/ticket/311 which is a very different proposal from the one I linked to and the one you seem to refer to here. I was not at all thinking of writing a gmp compatible replacement. I was thinking of taking gmp sources and mechanically modify the exported names and modify integer-gmp to use those modified names. Thus there would be no difference in the speed of Integer as it would still use an exact clone of the original gmp in exactly the same way as now but not interfere with what the usual gmp code does via other libraries. Please correct me if I this approach is not feasible or if there is some advantage in using cmm over this proposal that I am missing. Michal -- |o| Michal Konecny mikkone...@gmail.com |o|http://www-users.aston.ac.uk/~konecnym/ |o|office: (+42) (0)121 204 3462 |o| PGP key http://www-users.aston.ac.uk/~konecnym/ki.aston ---BeginMessage--- Hello Dan, Thank your for your suggestions. I implemented the dependency on integer-simple because I need hmpfr to work in the short term. In the long term, I would like to adopt a better approach. At the moment I do not know enough about ghc internals to be able to determine the approach, so I welcome your pointers. I know that Aleš, who knows more about the ghc internals, has tried various things but could not make hmpfr work with the current integer-gmp. I did not file a bug because there was a similar ghc ticket open for quite some time (#601) and it has been closed when it became possible to use integer-simple instead of integer-gmp. That is why I felt that the best solution to the problem at present is to use integer-simple. I am not an expert but based on what I read experts say on the topic I concluded that it is close-to-impossible to make ghc+integer-gmp work with libraries such as mpfr that heavily use gmp. Of the suggested solutions we are aware of, the one that seems to me and Aleš most promising is to create a clone of gmp that differs from the original only in the names of all exported symbols and distribute it as a part of ghc to be dynamically linked with all executables produced by ghc. The clone could be produced using a script to allow easy updates with new versions of gmp. I would be interested whether someone has been trying or has plans to try to implement this approach. The reason why I like this approach than writing cmm wrappers around MPFR and prim importing them is that it is more maintainable and also opens the way for other libraries that depend on gmp to work with ghc. Michal On Friday 04 Mar 2011 20:27:10 you wrote: According to Duncan Coutts (whom I asked about this issue in #ghc), the solution here is to use
Re: [Haskell-cafe] ANN: hmpfr-0.3.2 (requires integer-simple, supports mpfr 3.0.0)
On Friday 04 Mar 2011 21:06:45 Edward Kmett wrote: I'd be more than willing to tackle flipping things over to use foreign prims, so that I have something I can build on top without requiring the contortions to get a ghc build with integer-simple. Dan has a cabal buildable library with foreign prims to use as a model. Is the google code repository up to date? Hi Ed, Yes, it is up to date. Moreover, I am not planning to do any development on it in the next few weeks. I would be very happy if you would experiment with the foreign prims in hmpfr. Michal -- |o| Michal Konecny mikkone...@gmail.com |o|http://www-users.aston.ac.uk/~konecnym/ |o|office: (+42) (0)121 204 3462 |o| PGP key http://www-users.aston.ac.uk/~konecnym/ki.aston signature.asc Description: This is a digitally signed message part. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell IDE
On Thu, Mar 3, 2011 at 9:05 AM, Hauschild, Klaus (EXT) klaus.hauschild@siemens.com wrote: whats your Haskell IDE of choise? Currently I use leksah. Is the EclipseFP Plugin for Eclipse a real alternative? I use EclipseFP 2.0.2 on a few fairly large projects and am overall very happy with it despite a few flaws, eg: - it currently signals an error in source code files with non-latin-1 unicode characters - it does not build projects that include C files - I find it fairly slow on very large projects as it continuously rebuilds them as you type, but it is not as slow as this kind of approach may seem to imply I especially appreciate: - how well it highlights compiler errors - the outline of a module I do not use code completion beyond the generic Alt-/, so I do not have an opinion on how well this is supported in eclipsefp. Michal -- |o| Michal Konecny mikkone...@gmail.com |o|http://www-users.aston.ac.uk/~konecnym/ |o|office: (+42) (0)121 204 3462 |o| PGP key http://www-users.aston.ac.uk/~konecnym/ki.aow signature.asc Description: This is a digitally signed message part. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: hmpfr-0.3.2 (requires integer-simple, supports mpfr 3.0.0)
Dear all, I am pleased to announce hmpfr-0.3.2, a new version of Aleš Bizjak's bindings to the MPFR arbitrary precision floating point arithmetic library. The changes in this version are quite small but significant: - support for MPFR 3.0.0 as well as MPFR 2.4.* - dependency on integer-simple instead of integer-gmp The latter is most significant because unfortunately it makes it rather more difficult to install hmpfr. Currently almost all binary distributions of ghc have integer-gmp compiled in to provide the Integer type via the standard GMP library. Also haskell platform 2010.2.0.0 assumes that ghc has been compiled with integer-gmp although it makes no specific use of it. Instructions on how to compile ghc and haskell platform with integer-simple instead of integer-gmp are on: http://code.google.com/p/hmpfr/wiki/GHCWithoutGMP The rationale for this change is the fact that despite much effort hmpfr is very unreliable on ghc that includes integer-gmp due to ghc deallocating GMP data that was allocated by MPFR at unpredictable times. Aleš and I hope that hmpfr can return to using integer-gmp once the proposal http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes#BinaryDropinReplacementforGMP to replace gmp with a modified gmp in ghc is implemented and made the default. Best regards, Michal -- |o| Michal Konecny mikkone...@gmail.com |o|http://www-users.aston.ac.uk/~konecnym/ |o|office: (+42) (0)121 204 3462 |o| PGP key http://www-users.aston.ac.uk/~konecnym/ki.aston signature.asc Description: This is a digitally signed message part. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
