Re: GHC 7.4.2 on Ubuntu Trusty

2014-10-28 Thread Yitzchak Gale
I wrote:
>> This thread makes it clear what a mess
>> we have inherited from the days when GHC was primarily a
>> research compiler. Let's face it - GHC is now also a serious
>> production compiler, and this urgently needs to be cleaned up.

hvr wrote:
> Are you referring to the GMP dependency or something else?
> ...I'm not sure what can be done differently here.

Agreed. No, not any one of those many little details. I mean
the general extreme difficulty of getting almost any version
of GHC working on almost any platform, unless the two
were released within a fairly short time of each other.

Well, that is, not counting your wonderful ppa for Ubuntu.
That is fantastic - but the dire need for it is evidence for
the severity of the problem.

How about this: Currently, every GHC source distribution
requires no later than its own version of GHC for bootstrapping.
Going backwards, that chops up the sequence of GHC versions
into tiny incompatible pieces - there is no way to start with a
working GHC and work backwards to an older version by compiling
successively older GHC sources.

If instead each GHC could be compiled using at least one
subsequent version, the chain would not be broken. I.e.,
always provide a compatibility flag or some other reasonably
simple mechanism that would enable the current GHC to
compile the source code of at least the last previous released
version.

I realize that this might be disruptive to GHC devs, because
as a compiler with a research heritage, GHC experiments with
its own new features on its own source code. But as a compiler
that is used commercially, some general kind of backward
portability is critically important.

The other direction is equally problematic. Although
GHC does support bootstrapping itself from a few previous
releases, porting GHC to a new platform has become harder
and harder as GHC becomes more complex. I think this could
become a threat to the viability of GHC - technology is always
changing.

As a commercial developer, I am always plagued by nagging
worry about GHC portability, forward and backward. Will we
always be able in the future to support code we release, or will
it die someday because there will no longer exist a GHC able
to compile it? Will our whole technology die someday just
because we can't get GHC working on a platform we need
to support?

Thanks,
Yitz
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: GHC 7.4.2 on Ubuntu Trusty

2014-10-28 Thread Edward Z. Yang
Excerpts from Yitzchak Gale's message of 2014-10-28 13:58:08 -0700:
> How about this: Currently, every GHC source distribution
> requires no later than its own version of GHC for bootstrapping.
> Going backwards, that chops up the sequence of GHC versions
> into tiny incompatible pieces - there is no way to start with a
> working GHC and work backwards to an older version by compiling
> successively older GHC sources.
> 
> If instead each GHC could be compiled using at least one
> subsequent version, the chain would not be broken. I.e.,
> always provide a compatibility flag or some other reasonably
> simple mechanism that would enable the current GHC to
> compile the source code of at least the last previous released
> version.

Here is an alternate proposal: when we make a new major version release,
we should also make a minor version release of the previous series, which
is prepped so that it can compile from the new major version.  If it
is the case that one version of the compiler can compile any other
version in the same series, this would be sufficient to go backwards.

Concretely, the action plan is very simple too: take 7.6 and apply as
many patches as is necessary to make it compile from 7.8, and cut
a release with those patches.

Edward
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: Recursion on TypeNats

2014-10-28 Thread Iavor Diatchki
Hello,

actually type-level integers are easier to work with than type-level
naturals (e.g., one can cancel things by subtracting at will).   I agree
that ideally we want to have both integers and naturals (probably as
separate kinds).  I just don't know what notation to use to distinguish the
two.

-Iavor



On Mon, Oct 27, 2014 at 2:13 PM, Barney Hilken 
wrote:

> Ok, I've created a ticket https://ghc.haskell.org/trac/ghc/ticket/9731
>
> Unfortunately I don't know enough about ghc internals to try implementing
> it.
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Thread behavior in 7.8.3

2014-10-28 Thread Michael Jones
I have a general question about thread behavior in 7.8.3 vs 7.6.X

I moved from 7.6 to 7.8 and my application behaves very differently. I have 
three threads, an application thread that plots data with wxhaskell or sends it 
over a network (depends on settings), a thread doing usb bulk writes, and a 
thread doing usb bulk reads. Data is moved around with TChan, and TVar is used 
for coordination.

When the application was compiled with 7.6, my stream of usb traffic was 
smooth. With 7.8, there are lots of delays where nothing seems to be running. 
These delays are up to 40ms, whereas with 7.6 delays were a 1ms or so.

When I add -N2 or -N4, the 7.8 program runs fine. But on 7.6 it runs fine 
without with -N2/4.

The program is compiled -O2 with profiling. The -N2/4 version uses more memory, 
 but in both cases with 7.8 and with 7.6 there is no space leak.

I tired to compile and use -ls so I could take a look with threadscope, but the 
application hangs and writes no data to the file. The CPU fans run wild like it 
is in an infinite loop. It at least pops an unpainted wxhaskell window, so it 
got partially running.

One of my libraries uses option -fsimpl-tick-factor=200 to get around the 
compiler.

What do I need to know about changes to threading and event logging between 7.6 
and 7.8? Is there some general documentation somewhere that might help?

I am on Ubuntu 14.04 LTS. I downloaded the 7.8 tool chain tar ball and 
installed myself, after removing 7.6 with apt-get.

Any hints appreciated.

Mike


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users