#7544: GHC downloads are unsigned
--+-
Reporter: afcowie| Owner:
Type: feature request| Status: new
Priority: normal | Component: Build System
#7216: Compositional blocking on file descriptors
---+
Reporter: AndreasVoellmy| Owner: igloo
Type: feature request | Status: patch
Priority: normal|
#7526: Minor typo in error message
-+--
Reporter: parcs | Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
#7536: Panic with TypeFamilies with type synonym instances
---+
Reporter: snowleopard | Owner:
Type: bug | Status: new
Priority: normal
#7216: Compositional blocking on file descriptors
---+
Reporter: AndreasVoellmy| Owner: igloo
Type: feature request | Status: patch
Priority: normal|
#7526: Minor typo in error message
---+
Reporter: parcs | Owner:
Type: bug | Status: closed
Priority: normal| Milestone:
#7536: Panic with TypeFamilies with type synonym instances
-+--
Reporter: snowleopard | Owner:
Type: bug | Status: merge
#7533: References to very old GHC in the docs
+---
Reporter: benmachine | Owner:
Type: bug| Status: closed
Priority: normal |
As far as I understand, the reason that GHC does not construct such proofs is
that it can't express them in its internal proof language (System FC).
Iavor is quite right
It seems to me that it should be fairly straight-forward to extend FC to
support this sort of proof, but I have not been
#7543: Constraint synonym instances
-+--
Reporter: monoidal | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
#3282: How to start an emacs editor within ghci asynchronously with :edit
filename.hs :set editor emacsdon't go
-+--
Reporter: petersonx | Owner:
Type: feature request |
#1407: Add the ability to :set -l{foo} in .ghci files
+---
Reporter: guest| Owner:
Type: feature request | Status: new
Priority: normal
#1407: Add the ability to :set -l{foo} in .ghci files
+---
Reporter: guest| Owner: igloo
Type: feature request | Status: new
Priority: normal
#7532: -ddump-splices output doesn't match generated code for data instances
inside instances.
-+--
Reporter: Aninhumer | Owner:
Type: bug | Status: new
#7541: Unavoidable duplicate constraint warning
--+-
Reporter: blamario | Owner:
Type: bug| Status: new
#7541: Unavoidable duplicate constraint warning
+---
Reporter: blamario | Owner:
Type: bug| Status: closed
#7532: -ddump-splices output doesn't match generated code for data instances
inside instances.
---+
Reporter: Aninhumer | Owner:
Type: bug | Status: closed
#7436: Derived Foldable and Traversable instances become extremely inefficient
due
to eta-expansion
-+--
Reporter: shachaf | Owner:
Type: bug | Status:
#7545: Type variable capture in InstanceSigs message
-+--
Reporter: Feuerbach | Owner:
Type: bug | Status: new
Priority: normal|
#7436: Derived Foldable and Traversable instances become extremely inefficient
due
to eta-expansion
-+--
Reporter: shachaf | Owner:
Type: bug | Status:
#7546: Manual 6.2 doesn't match current output formatting
-+--
Reporter: chrisseaton | Owner:
Type: bug | Status: new
Priority: normal|
#7436: Derived Foldable and Traversable instances become extremely inefficient
due
to eta-expansion
-+--
Reporter: shachaf | Owner:
Type: bug | Status:
#619: Port Hugs's Windows front end to GHCi.
---+
Reporter: simonmar | Owner:
Type: task | Status: new
Priority: normal
#7547: Loop when printing External Core
-+--
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
#7547: Loop when printing External Core
-+--
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
#7546: Manual 6.2 doesn't match current output formatting
-+--
Reporter: chrisseaton | Owner:
Type: bug | Status: new
Priority: normal|
#7510: Immediate seg-fault on 32-bit windows build
-+--
Reporter: simonpj | Owner: simonmar
Type: bug | Status: new
Priority: highest |
#7545: Type variable capture in InstanceSigs message
-+--
Reporter: Feuerbach | Owner:
Type: bug | Status: new
Priority: normal|
#7258: Compiling DynFlags is jolly slow
-+--
Reporter: simonpj | Owner: simonpj
Type: bug | Status: new
Priority: normal| Milestone:
#7360: Case-of-identical-alts optimisation fails abjectly
-+--
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: normal
#7360: Case-of-identical-alts optimisation fails abjectly
-+--
Reporter: simonpj | Owner:
Type: bug | Status: closed
#7546: Manual 6.2 doesn't match current output formatting
-+--
Reporter: chrisseaton | Owner:
Type: bug | Status: merge
Priority: normal
#7547: Loop when printing External Core
-+--
Reporter: simonpj | Owner:
Type: bug | Status: merge
Priority: normal| Milestone:
#7545: Type variable capture in InstanceSigs message
-+--
Reporter: Feuerbach | Owner:
Type: bug | Status: merge
Priority:
#7519: CLK_TCK is not always a constant
-+--
Reporter: singpolyma| Owner:
Type: bug | Status: patch
Priority: normal|
#7539: Hard ghc api crash when calling runStmt on code which has not been
compiled
-+--
Reporter: edsko | Owner:
Type: bug | Status: new
#7510: Immediate seg-fault on 32-bit windows build
-+--
Reporter: simonpj | Owner: simonmar
Type: bug | Status: new
Priority: highest |
#7519: CLK_TCK is not always a constant
-+--
Reporter: singpolyma| Owner:
Type: bug | Status: patch
Priority: normal|
#7542: GHC doesn't optimize (strict) composition with id
-+--
Reporter: shachaf | Owner:
Type: bug | Status: infoneeded
Priority:
#7548: GHC API dependency analysis is broken
+---
Reporter: MikolajKonarski | Owner:
Type: bug | Status: new
Priority: normal | Component: GHC
Serge
That's odd. I've tried with both 7.6 and HEAD, and both fail on T_cubeext thus:
T_cubeext.hs:102:10:
Overlapping instances for LinSolvRing (UPol k)
arising from a use of `upEucRing'
Matching instances:
instance [overlap ok] EuclideanRing a = LinSolvRing (UPol a)
#7510: Immediate seg-fault on 32-bit windows build
-+--
Reporter: simonpj | Owner: simonmar
Type: bug | Status: new
Priority: highest |
#7548: GHC API dependency analysis is broken
+---
Reporter: MikolajKonarski | Owner:
Type: bug | Status: new
Priority: highest | Milestone: 7.8.1
#7510: Immediate seg-fault on 32-bit windows build
-+--
Reporter: simonpj | Owner: simonmar
Type: bug | Status: new
Priority: highest |
#7548: GHC API dependency analysis is broken
--+-
Reporter: MikolajKonarski | Owner:
Type: bug | Status: closed
Priority: highest | Milestone:
#7548: GHC API dependency analysis is broken
--+-
Reporter: MikolajKonarski | Owner:
Type: bug | Status: closed
Priority: highest | Milestone:
#7548: GHC API dependency analysis is broken
--+-
Reporter: MikolajKonarski | Owner:
Type: bug | Status: closed
Priority: highest | Milestone:
#7473: getModificationTime gives only second-level resolution
--+-
Reporter: duncan | Owner:
Type: bug | Status: new
Priority: normal
#7548: GHC API dependency analysis is broken
--+-
Reporter: MikolajKonarski | Owner:
Type: bug | Status: closed
Priority: highest | Milestone:
#619: Port Hugs's Windows front end to GHCi.
---+
Reporter: simonmar | Owner:
Type: task | Status: closed
Priority: normal
#7475: Mysterious Data.Word Segmentation Fault in GHCi
--+-
Reporter: VKS| Owner:
Type: bug| Status: new
Priority: normal
#7043: 32-bit GHC ceiling of negative float SEGFAULT: 11
--+-
Reporter: DrGodCarl | Owner: igloo
Type: bug| Status: new
#2431: Allow empty case analysis
+---
Reporter: RalfHinze| Owner:
Type: feature request | Status: new
Priority: low | Milestone:
#7549: Deriving Bug?
-+--
Reporter: davorak | Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
#7549: Deriving Bug?
-+--
Reporter: davorak |Owner:
Type: bug | Status: closed
Priority: normal|Component: Compiler
#7550: incorrect bang patterns rejected with report a ghc bug
--+-
Reporter: aavogt | Owner:
Type: bug| Status: new
#7550: incorrect bang patterns rejected with report a ghc bug
-+--
Reporter: aavogt|Owner:
Type: bug | Status: closed
#7490: ghc-stage1 panic when building QNXNTO cross-compiler
+---
Reporter: singpolyma | Owner:
Type: bug | Status: new
Priority: normal |
#7490: ghc-stage1 panic when building a cross-compiler or cross-building a
compiler
+---
Reporter: singpolyma | Owner:
Type: bug | Status: new
As far as I understand, the reason that GHC does not construct such proofs is
that it can't express them in its internal proof language (System FC).
Iavor is quite right
It seems to me that it should be fairly straight-forward to extend FC to
support this sort of proof, but I have not been
On Tue, Jan 1, 2013 at 3:41 PM, Brandon Allbery allber...@gmail.com wrote:
On Tue, Jan 1, 2013 at 9:13 AM, Bernhard Urban lew...@gmail.com wrote:
The main issue: The GHC runtime relies on glibc
I have to assume this is not meant literally, because ghc works on OS X and
*BSD.
Right. I was
On Wed, Jan 02, 2013 at 05:21:43PM +, Simon Peyton-Jones wrote:
Serge
That's odd. I've tried with both 7.6 and HEAD, and both fail on T_cubeext
thus:
T_cubeext.hs:102:10:
Overlapping instances for LinSolvRing (UPol k)
arising from a use of `upEucRing'
Matching
| The solution is to add (EuclideanRing k) to the type sig of cubicExt.
| Then it compiles all the way up to the top.
|
| But the DoCon declares
|class (EuclideanRing a, FactorizationRing a) = Field a
|
| (EuclideanRing is a superclass for Field),
| and the test
I agree with Iavor that it is fairly straight-forward to extend FC to
support FD-style type improvement. In fact, I've formalized such a proof
language in a PPDP'06 paper:
Extracting programs from type class proofs
(type improvement comes only at the end)
Similar to FC, coercions (proof terms)
On Wed, Jan 02, 2013 at 08:23:37PM +, Simon Peyton-Jones wrote:
| The solution is to add (EuclideanRing k) to the type sig of cubicExt.
| Then it compiles all the way up to the top.
|
| But the DoCon declares
|class (EuclideanRing a, FactorizationRing a) = Field a
I made a second mistake. I meant (LinSolvRing (UPol k)). Apologies.
| I don't know why 7.4 accepts it, but I'm not inclined to investigate...
| looks like a bug in 7.4.
|
| ghc-7.4.1 may use a special trick, but is correct.
I don't understand your explanation. What is wrong with this
I'm trying to build ghc-7.4.1 using ghc-7.4.1 on my raspberry pi (armv6l)
and I get the following error:
inplace/bin/ghc-stage1 -H32m -O-package-name ghc-prim-0.2.0.0
-hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build
My random guess is that /tmp is mounted using tmpfs (aka a RAM drive)
and it got full. Try remounting /tmp to use the sdcard instead ?
On Wed, Jan 2, 2013 at 7:32 PM, rocon...@theorem.ca wrote:
I'm trying to build ghc-7.4.1 using ghc-7.4.1 on my raspberry pi (armv6l)
and I get the following
Thanks for your help, but unfortunately this isn't the issue
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 924G 584G 294G 67% /tmp
So there is pleanty of room on temp.
BTW, I also tried building it twice and I got the same error at the same
place.
On Wed, 2 Jan 2013,
Some further information it seems that llc is segfaulting:
pi@raspberrypi /tmp/ghc-7.4.1 $ llc -O3 -relocation-model=static /tmp/ghc7189_0/ghc7189_0.bc -o /tmp/ghc7189_0/ghc7189_0.lm_s
Stack dump:
0. Program arguments: llc -O3 -relocation-model=static /tmp/ghc7189_0/ghc7189_0.bc -o
Dear Haskellers
Happy New Year!
Did you see our friend Ranjit Jhala's (of liquid type fame) Lambda Style video?
Haskell hits the pop scene.
http://www.youtube.com/watch?v=Ci48kqp11F8
Simon
___
Haskell mailing list
Haskell@haskell.org
Hello all, please help me with cabal updating.
When i run:
cabal update -v3
I get this message:
Downloading the latest package list from hackage.haskell.org
Sending:
GET /packages/archive/00-index.tar.gz HTTP/1.1
Host: hackage.haskell.org
User-Agent: cabal-install/0.10.2
Creating new connection to
On 2 January 2013 23:07, Chernin, Nadav chern...@corning.com wrote:
Hello all, please help me with cabal updating.
When i run:
cabal update –v3
I get this message:
Downloading the latest package list from hackage.haskell.org
Sending:
GET /packages/archive/00-index.tar.gz HTTP/1.1
I am SO SCARED.
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Happy new year from Japan.
A young talented guy, @fumieval, has released Monaris, a Tetoris clone based
on OpenGL. You can install it:
% cabal install Monaris
To my surprise, this game is implemented with free Monad. ;-)
Regards,
--Kazu
___
Le Tue, 01 Jan 2013 14:24:04 -0900,
Christopher Howard christopher.how...@frigidcode.com a écrit :
I'm working through a video lecture describing how to prove programs
correct, by first translating the program into a control flow
representation and then using propositional logic. In the
On Jan 2, 2013, at 2:26 AM, Bob Hutchison hutch-li...@recursive.ca wrote:
On 2013-01-01, at 3:47 PM, MigMit miguelim...@yandex.ru wrote:
Well, probably one of the reasons is that I've learned Eiffel later than
Haskell.
But really, Design by Contract — a theory? It certainly is a
On Jan 2, 2013, at 8:44 AM, Никитин Лев leon.v.niki...@pravmail.ru wrote:
I said theoratical, but not mathematical or a scientific theory.
Than what kind of theory did you mean?
image1.gif Meyer have built a quite coherent construction in comparison
with other OOP langs.
More than
On Jan 2, 2013, at 10:52 AM, Mike Meyer m...@mired.org wrote:
[Context destroyed by top posting.]
MigMit miguelim...@yandex.ru wrote:
But really, Design by Contract — a theory? It certainly is a useful
approach, but it doesn't seem to be a theory, not until we can actually
prove
On Wed, 2 Jan 2013 13:48:07 +0400
MigMit miguelim...@yandex.ru wrote:
On Jan 2, 2013, at 10:52 AM, Mike Meyer m...@mired.org wrote:
MigMit miguelim...@yandex.ru wrote:
But really, Design by Contract — a theory? It certainly is a useful
approach, but it doesn't seem to be a theory, not until
Hi list,
I am a bit puzzled by the behaviour exemplified by this code:
{-# LANGUAGE RankNTypes #-}
one :: (forall a. a - a) - b - b
one f = f
two = let f = flip one in f 'x' id
three = (flip one :: b - (forall a. a - a) - b) 'x' id
four = flip one 'x' id
Try to guess
At Wed, 02 Jan 2013 12:32:53 +0100,
Francesco Mazzoli wrote:
Hi list,
I am a bit puzzled by the behaviour exemplified by this code:
{-# LANGUAGE RankNTypes #-}
one :: (forall a. a - a) - b - b
one f = f
two = let f = flip one in f 'x' id
three = (flip one :: b
Well, we can say "concepts" in place of "theory". And I'm comparing Eiffel with other OOP lang, not with some langs based on a solid math theory (lambda calcules for FP langs, for example). ok? DbC is not the same as "assert macros". First, it has a lang semantic. There is an interesting
Opps... I forgot about Eiffel agents! PS. After participationing in this discussion I'm tempting to reread Meyer's book after 10 years interval, to have a detailed look at the eiffel from the FP position. When I read this book first I know nothing about FP.
* Francesco Mazzoli f...@mazzo.li [2013-01-02 13:04:36+0100]
At Wed, 02 Jan 2013 12:32:53 +0100,
Francesco Mazzoli wrote:
Hi list,
I am a bit puzzled by the behaviour exemplified by this code:
{-# LANGUAGE RankNTypes #-}
one :: (forall a. a - a) - b - b
one f =
On 2013-01-02, at 4:41 AM, MigMit miguelim...@yandex.ru wrote:
On Jan 2, 2013, at 2:26 AM, Bob Hutchison hutch-li...@recursive.ca wrote:
On 2013-01-01, at 3:47 PM, MigMit miguelim...@yandex.ru wrote:
Well, probably one of the reasons is that I've learned Eiffel later than
Haskell.
At Wed, 2 Jan 2013 14:49:51 +0200,
Roman Cheplyaka wrote:
I don't see how this is relevant.
Well, moving `flip one' in a let solves the problem, and The fact that let-bound
variables are treated differently probably has a play here. I originally
thought that this was because the quantifications
On 2013-01-02, at 7:56 AM, Bob Hutchison hutch-li...@recursive.ca wrote:
You should read OOSC2. You'll find that this is completely consistent with
it. Don't forget that the 'C' in OOSC2 is 'contraction'.
'Construction' of course… the automated spell checker is not my friend :-(
Hi,
First, I see (posts on this mailing list) that OO ideas are well known
in functional community :)
So my questions for you all are:
* Is it really worthwhile for me to learn OO-programming?
Learn or not to learn? I would say: yes! There is whole new universe
to discover: UML,
On 2013-01-02, at 1:52 AM, Mike Meyer m...@mired.org wrote:
[Context destroyed by top posting.]
MigMit miguelim...@yandex.ru wrote:
But really, Design by Contract — a theory? It certainly is a useful
approach, but it doesn't seem to be a theory, not until we can actually
prove something
Your example doesn't work for the same reason the following doesn't work:
id runST (some st code)
It requires the inferencer to instantiate certain variables of id's type to
polymorphic types based on runST (or flip's based on one), and then use
that information to check some st code (id in
On Tue, Jan 1, 2013 at 3:41 PM, Brandon Allbery allber...@gmail.com wrote:
On Tue, Jan 1, 2013 at 9:13 AM, Bernhard Urban lew...@gmail.com wrote:
The main issue: The GHC runtime relies on glibc
I have to assume this is not meant literally, because ghc works on OS X and
*BSD.
Right. I was
On Wed, Jan 2, 2013 at 11:20 AM, Dan Doel dan.d...@gmail.com wrote:
Note that even left-to-right behavior covers all cases, as you might have:
f x y
such that y requires x to be checked polymorphically in the same way.
There are algorithms that can get this right in general, but it's a
At Wed, 2 Jan 2013 11:20:46 -0500,
Dan Doel wrote:
Your example doesn't work for the same reason the following doesn't work:
id runST (some st code)
It requires the inferencer to instantiate certain variables of id's type to
polymorphic types based on runST (or flip's based on one),
Hello,
rather than native GHC run on top of Android, I would recommend to have
a look at GHC HEAD and attempt to cross-compile to Android. On ghc-cvs@
mailing list I've seen some work done for cross-compiling to
QNX/BlackBerry OS 10 so I think Androind should be also doable with some
Christopher, there's an introduction to proof for functional programs at
http://www.cs.kent.ac.uk/people/staff/sjt/Pubs/ProofChapter.pdf
I hope that you find it useful.
Kind regards
Simon
On 1 Jan 2013, at 23:24, Christopher Howard christopher.how...@frigidcode.com
wrote:
1. Does this
If you want to know the inner workings, you probably need to read the
OutsideIn(X) paper.*
I'm not that familiar with the algorithm. But what happens is something
like this When GHC goes to infer the type of 'f x' where it knows that
f's argument is expected to be polymorphic, this triggers a
At Wed, 2 Jan 2013 13:35:24 -0500,
Dan Doel wrote:
If you want to know the inner workings, you probably need to read the
OutsideIn(X) paper.*
I'm not that familiar with the algorithm. But what happens is something
like this When GHC goes to infer the type of 'f x' where it knows that
On Jan 2, 2013, at 4:24 PM, Никитин Лев leon.v.niki...@pravmail.ru wrote:
Well, we can say concepts in place of theory. And I'm comparing Eiffel
with other OOP lang, not with some langs based on a solid math theory (lambda
calcules for FP langs, for example). ok?
I agree that there are
2) prepost conditions and class invariants have defined behaviour in cases
of inheritance, even/especially multiple inheritance. They are combined
non-trivially in subclasses. Without this I don't think you have DbC.
Yes, I forgot about that. Thanks.
Feel free to enlighten me about these
1 - 100 of 105 matches
Mail list logo
