Re: [Haskell-cafe] [ANNOUNCE] GHC 9.8.1-alpha4 is now available

[Carter Schonwald]

George can you share the generated settings file?

On Fri, Sep 22, 2023 at 8:34 PM Ben Gamari  wrote:

> George Colpitts  writes:
>
> > It seems unlikely that the current tests wouldn't find this bug. Is it
> the
> > case that the tests are never run on aarch64-darwin Macs?
> >
> The tests are certainly run; see, for instance, the 9.8.1-alpha4 release
> pipeline [1].
>
> The problem is that #21570 requires very particular (mis)configuration
> of the host toolchain (e.g. Richard had multiple, incompatible
> toolchains in PATH). We can usually side-step this sort of
> misconfiguration by disabling the `configure` script's ld-override
> logic, since we using anything but Apple's linker is generally a bad
> idea on Darwin. This measure (!8437) is present in the 9.8 branch so I can
> only
> guess that something else is wrong.
>
> Perhaps you could open a ticket and attach config.log?
>
> Cheers,
>
> - Ben
>
>
> [1]: https://gitlab.haskell.org/ghc/ghc/-/jobs/1668689
> ___
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] [ANNOUNCE] GHC 9.4.6 is now available

[Carter Schonwald]

you like to 9.4.6 instead of .7 ...

On Mon, Aug 7, 2023 at 11:58 AM Ben Gamari  wrote:

>
> The GHC developers are happy to announce the availability of GHC 9.4.6.
> Binary
> distributions, source distributions, and documentation are available at
>
> https://downloads.haskell.org/ghc/9.4.6
>
> This release is primarily a bugfix release addressing some issues
> found in 9.4.6. These include:
>
>  * Many bug fixes for the simplifier, preventing compiler panics, loops and
>incorrect code generation (#22761, #22549, #23208, #22761, #22272,
> #23146,
>#23012, #22547).
>  * Bug fixes for the typechecker involving newtype family instances, making
>type equalities more robust and bugs having to do with defaulting
> representation
>polymorphic type variables (#23329, #2, #23143, #23154, #23176).
>  * Some bug fixes for code generation, particularly on the aarch64 backend,
>including adding more memory barriers for array read operations
> (#23541, #23749).
>  * Some bug fixes for windows builds, ensuring the reliablility of IO
> manager shutdown
>and a bug fix for the RTS linker on windows (#23691, #22941).
>  * A bug fix for the non-moving GC ensuring mutator allocations are
> properly
>accounted for (#23312).
>  * A bug fix preventing some segfaults by ensuring that pinned allocations
> respect
>block size (#23400).
>  * Many bug fixes for the bytecode interpreter, allowing a greater subset
>of the language to be interpreted (#22376, #22840, #22051, #21945,
> #23068, #22958).
>  * ... and a few more. See the [release notes] for a full accounting.
>
> As some of the fixed issues do affect correctness users are encouraged to
> upgrade promptly.
>
> We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool,
> Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and
> other anonymous contributors whose on-going financial and in-kind support
> has
> facilitated GHC maintenance and release management over the years. Finally,
> this release would not have been possible without the hundreds of
> open-source
> contributors whose work comprise this release.
>
> As always, do give this release a try and open a [ticket] if you see
> anything amiss.
>
> Happy compiling,
>
> - Zubin & Ben
>
>
> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new
> [release notes]:
> https://downloads.haskell.org/~ghc/9.4.6/docs/users_guide/9.4.6-notes.html
> ___
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: success on a slightly modified version of your suggestion for 21506

[Carter Schonwald]

that matches my experience, namely that i've successfully installed ghc
9.2.2 on osx 12.4 aka monterey a few times

On Sun, Jul 24, 2022 at 12:59 PM George Colpitts 
wrote:

> Hi Ben
>
> Thanks for the quick responses particularly on the weekend before your
> vacation.
>
> you wrote:
>
> What happens
> if you try to install to do something like (in the extracted binary
> distribution),
>
>
> $ ./configure --prefix=`pwd`/tmp
> $ make install# this will fail
> $ xattr -rc .
> $ make install# perhaps this will finish successfully?
> # tmp/bin/ghc --version   # GHC should be usable
>
>
> success on both my machines using a slightly modified version of your
> suggestion above for 21506:
>
>  ./configure --prefix=`pwd`/tmp# specifying ./tmp seems to be critical
>
> xattr -rc .# seems to be necessary
> also
>
> sudo make install   # seems to works , output ends
> with "recache"
>
> ./tmp/bin/ghc --version  # success , although admittedly
> the smallest smoke test possible
>
> You wrote:
>
> >
> Ultimately I think we may just need to bite the bullet and start
> properly notarising/codesigning releases (resolving #17418). At this point
> we have
> spent more time trying to avoid the notarisation requirement than
> it would likely take to satisfy it. Unfortunately, this will require
> that I find an Apple device somewhere which may take a few weeks.
>
>
> I'm afraid I am on holiday next week but I would quite grateful if we
> could arrange for a chat after I return such that we can debug this in
> realtime.
>
>
> Sure, we can chat when you return from your vacation.
>
> Not sure if it is worth trying to fix the release on the basis of what I
> write above. My opinion is: it is if we can get reports of at least one
> other person having this issue. I am fine with not doing this for 9.4.1
>
> I agree that we should raise the priority of "notarising/codesigning
> releases (resolving #17418)". My opinion is that it is not worth delaying
> 9.4.1 for this.
>
> Have a great vacation.
>
> Cheers
> George
>
>
>
>
>
>
> On Sun, Jul 24, 2022 at 11:33 AM Ben Gamari  wrote:
>
>> George Colpitts  writes:
>>
>> > +Kazu Yamamoto 
>> >
>> > Hi Ben
>> >
>> > My 2 machines also have:
>> >
>> > $ spctl --status
>> > assessments enabled
>> >
>> Hmm, interesting. Then I am truly perplexed.
>>
>> > Speculations:
>> >
>> >
>> /usr/local/lib/ghc-9.4.0.20220721/bin/../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib
>> > is created after xattr -rc . was run so it doesn't have the necessary
>> > attributes. Is it possible that ghc developers and/or the test machines
>> > have this file on another of the paths in the error message and that is
>> why
>> > it works for them?
>> >
>> I'm not sure where this would be but at this point anything is possible.
>> What happens
>> if you try to install to do something like (in the extracted binary
>> distribution),
>>
>> $ ./configure --prefix=`pwd`/tmp
>> $ make install# this will fail
>> $ xattr -rc .
>> $ make install# perhaps this will finish successfully?
>> # tmp/bin/ghc --version   # GHC should be usable
>>
>> > I hope I didn't offend you by asking if the fix had been tested; I
>> assume
>> > it had been but I thought it was important to rule that out.
>> >
>> Not to worry; it's a very reasonable question to ask given the
>> circumstances.
>>
>> > More than happy to test. I really appreciate all the work you and others
>> > have put into GHC !
>> >
>> Ultimately I think we may just need to bite the bullet and start
>> properly notarising/codesigning releases (resolving #17418). At this
>> point we have
>> spent more time trying to avoid the notarisation requirement than
>> it would likely take to satisfy it. Unfortunately, this will require
>> that I find an Apple device somewhere which may take a few weeks.
>>
>> I'm afraid I am on holiday next week but I would quite grateful if we
>> could arrange for a chat after I return such that we can debug this in
>> realtime.
>>
>> Cheers,
>>
>> - Ben
>>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: osx conundrum

[Carter Schonwald]

The issue would be macports.  It uses its own version of the iconv lib and
that always gets headaches if the ghc touches anything else.

if you’re using macports you have to make sure everything is Mac ports only
for ghc linking.

Else you have to make sure you don’t touch any macports c Libs via ghc.

On Wed, Oct 13, 2021 at 7:57 AM David Duke  wrote:

> Thanks Steven. Looks like it might be something with my system.
> I reinstalled from macports  8.10.7
> @ Carter yes I've been carefully   check the compiler version on each
> trial.
> However trying to compile a Haskell source gives the same libHSbase error
>
>
>
> ndefined symbols for architecture x86_64:
>
>   "_iconv", referenced from:
>
>   _hs_iconv in libHSbase-4.14.3.0.a(iconv.o
>
>
>
>
>
> On Tue, Oct 12, 2021 at 2:54 AM Steven Smith 
> wrote:
>
>> I’m a maintainer of the MacPorts ghc port. The MacPorts installations do
>> not have this issue, whether installed from the buildbot binaries or
>> compiled from source, that all work on multiple macOS versions 10.9–11.
>> Here’s the build recipe:
>> https://github.com/macports/macports-ports/blob/master/lang/ghc/Portfile
>>
>> The iconv symbol issue is known,
>> https://gitlab.haskell.org/ghc/ghc/-/issues/18752, and packages like
>> MacPorts must build around it.
>>
>> This looks like something specific to your configuration.
>>
>> If you believe that there is an issue outside your system, please
>> initiate a trac ticket at https://trac.macports.org.
>>
>>
>> On Oct 11, 2021, at 5:00 AM, David Duke  wrote:
>>
>> I have a conundrum on which advice would be appreciate. Does
>> anyone know how to successfully install ghc on OSX
>> I've tried various binary instalation routes:
>> macports, brew, direct binary downloads from haskel.org
>>
>>
>>
>
> --
> David Duke
> Emeritus Professor of Computer Science
> School of Computing University of Leeds UK
> E:duke.j.da...@gmail.com
> W:https://engineering.leeds.ac.uk/staff/334/Professor_David_Duke
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: osx conundrum

[Carter Schonwald]

i would make sure you're using the ghc version you *think*  you're using

i've never had that problem with a self managed style install (which should
be equiv to using ghcup's setup). i'm at 8.10.7 at the moment.

whats the output of `which -a ghc`  and `which ghc`?

mixing several ghc installs of the same version can be a problem.  ghcup
should just match the official builds generally


On Mon, Oct 11, 2021 at 9:55 PM Steven Smith 
wrote:

> I’m a maintainer of the MacPorts ghc port. The MacPorts installations do
> not have this issue, whether installed from the buildbot binaries or
> compiled from source, that all work on multiple macOS versions 10.9–11.
> Here’s the build recipe:
> https://github.com/macports/macports-ports/blob/master/lang/ghc/Portfile
>
> The iconv symbol issue is known,
> https://gitlab.haskell.org/ghc/ghc/-/issues/18752, and packages like
> MacPorts must build around it.
>
> This looks like something specific to your configuration.
>
> If you believe that there is an issue outside your system, please initiate
> a trac ticket at https://trac.macports.org.
>
>
> On Oct 11, 2021, at 5:00 AM, David Duke  wrote:
>
> I have a conundrum on which advice would be appreciate. Does
> anyone know how to successfully install ghc on OSX
> I've tried various binary instalation routes:
> macports, brew, direct binary downloads from haskel.org
>
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] Bundle patterns with type aliases

[Carter Schonwald]

These are great ideas! Could you please create a ghc tracker ticket with a
tiny examples or two?

There may be specific technical reasons we might not be able to do so for
type synonyms in ghc, but I don’t see any obvious barriers in the case of
David’s excellent idea, I’ve def seen lots of great code out there where
you’d really want either associated pattern synonyms or to bundle pattern
synonyms with the exported public interface for a type class.

I’m sure there’s some devil in the details but these sound lovely.  Step -1
is making up 1-2 toy examples and explaining what and why you want it on a
ghc ticket!

On Wed, Sep 8, 2021 at 1:25 PM David Feuer  wrote:

> I would like that, along with the ability to bundle patterns with classes.
>
> On Wed, Sep 8, 2021, 1:13 PM Keith  wrote:
>
>> Is there currently a way to 'bundle' a pattern with a type alias? And if
>> not, could that capability be added to the PatternSynonyms GHC extension?
>> (Is this the right place to ask, or should I be asking a GHC list?)
>>
>> --Keith
>> Sent from my phone with K-9 Mail.
>> ___
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>
> ___
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: -dinline-check for symbolic names?

[Carter Schonwald]

I’m not sure about the pragma debugging, but are you using it in point free
style? Cause I’m that case it may not be inclined because it’s not being
fully applied on the left hand side?

On Wed, Aug 4, 2021 at 11:36 AM Michael Sperber 
wrote:

>
> I'm trying to figure out why this function from ConCat.AltCat is not
> getting inlined:
>
> (&&&) :: forall k a c d. (MProductCat k, Ok3 k a c d)
>   => (a `k` c) -> (a `k` d) -> (a `k` Prod k c d)
> f &&& g = (f *** g) . dup
>   <+ okProd @k @a @a
>   <+ okProd @k @c @d
> {-# INLINE (&&&) #-}
>
> So I put
>
> {-# OPTIONS_GHC -dinline-check ConCat.AltCat.&&& #-}
>
> in the importing module.  Alas, I'm getting no output on &&&.  I can get
> output from lots of other functions - I'm guessing it might be because
> of the name.
>
> Could somebody help me enable the inline check?  Would be much
> appreciated!
>
> --
> Regards,
> Mike
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: How to user-define a type equality constraint?

[Carter Schonwald]

That sounds like a bug/oversight!  Is that not fixed in 9.2?

On Mon, Apr 5, 2021 at 11:08 PM David Feuer  wrote:

> `Char` is defined in user code. What you really can't define are Char# and
> TYPE, and you can't modify `RuntimeRep`. Speaking of `Char#`, I see that in
> 9.0, at least, it has kind TYPE 'WordRep. Why is that not Word32Rep?
>
> On Mon, Apr 5, 2021, 10:50 PM Richard Eisenberg  wrote:
>
>>
>>
>> On Apr 1, 2021, at 8:12 PM, Anthony Clayden 
>> wrote:
>>
>> Can I user-define a conventional type-class that behaves more like `(~)`?
>>
>>
>> I don't think so.
>>
>> But why does this matter? I can't define `Char` in user code, but it's
>> exported from the Prelude and requires no extensions. While I can define Eq
>> in user code, I can't make `deriving` work with my version. I can't define
>> `error` in user code. There are many others, I'm sure.
>>
>> So: why does this matter?
>>
>> Thanks,
>> Richard
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Decorating exceptions with backtrace information

[Carter Schonwald]

On Fri, May 8, 2020 at 9:32 AM Carter Schonwald 
wrote:

> ben, could you please email the libraries list with this too? This seems
> like a core libraries / base change rather than a ghc-the-compiler change
>
> On Thu, May 7, 2020 at 6:57 PM Michael Sloan  wrote:
>
>> Thanks so much for making a proposal for this, Ben!!  It's great to see
>> progress here.
>>
>> I'm also glad that there is now a proposal process.  I made a fairly
>> similar proposal almost exactly 5 years ago to the libraries list -
>> https://mail.haskell.org/pipermail/libraries/2015-April/025471.html -
>> but without the subtlety of particular backtrace representations.  Skimming
>> the ensuing thread may still be informative.
>>
>> In particular, there is one thing I would like to highlight from that old
>> proposal.  I think it'd be good to have a standard way to represent a chain
>> of exceptions, and build this into `catch` and `finally`.  Python and Java
>> both have a mechanism for this, and both refer to it as a "cause"
>> exception.  When an exception is thrown during exception handling, the
>> exception being handled is preserved as its "cause".  I find this mechanism
>> to be incredibly useful in Java, it has made the underlying issue much
>> clearer in many cases, and in other cases at least provides helpful
>> context.  I have no doubt such a mechanism would have saved me many hours
>> of debugging exceptions in Haskell systems I've worked on in the past.
>>
>> I considered commenting about that directly on the proposal, but I figure
>> this is a better place to suggest expanding the scope of the change :) .
>> Totally understandable if you want to keep this proposal focused on
>> stacktraces, but I think it'd be good to consider this as a potential
>> future improvement.
>>
>> -Michael
>>
>> On Thu, May 7, 2020 at 3:55 PM Ben Gamari  wrote:
>>
>>>
>>> Hi everyone,
>>>
>>> After a nice discussion on IRC about the unfortunate state of error
>>> reporting in Haskell, I felt compelled to write down some long-lingering
>>> thoughts regarding backtraces on exceptions. The result is GHC proposal
>>> #330 [1]. I think the approach is viable and perhaps even
>>> straightforward. I have the sketch of an implementation here [2].
>>>
>>> Please have a look at the proposal and leave your comments. If there is
>>> consensus it is possible that we could have this done for 8.12.
>>>
>>> Cheers,
>>>
>>> - Ben
>>>
>>>
>>> [1] https://github.com/ghc-proposals/ghc-proposals/pull/330
>>> [2] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3236
>>> ___
>>> ghc-devs mailing list
>>> ghc-d...@haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>> ___
>> ghc-devs mailing list
>> ghc-d...@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Decorating exceptions with backtrace information

[Carter Schonwald]

ben, could you please email the libraries list with this too? This seems
like a core libraries / base change rather than a ghc-the-compiler change

On Thu, May 7, 2020 at 6:57 PM Michael Sloan  wrote:

> Thanks so much for making a proposal for this, Ben!!  It's great to see
> progress here.
>
> I'm also glad that there is now a proposal process.  I made a fairly
> similar proposal almost exactly 5 years ago to the libraries list -
> https://mail.haskell.org/pipermail/libraries/2015-April/025471.html - but
> without the subtlety of particular backtrace representations.  Skimming the
> ensuing thread may still be informative.
>
> In particular, there is one thing I would like to highlight from that old
> proposal.  I think it'd be good to have a standard way to represent a chain
> of exceptions, and build this into `catch` and `finally`.  Python and Java
> both have a mechanism for this, and both refer to it as a "cause"
> exception.  When an exception is thrown during exception handling, the
> exception being handled is preserved as its "cause".  I find this mechanism
> to be incredibly useful in Java, it has made the underlying issue much
> clearer in many cases, and in other cases at least provides helpful
> context.  I have no doubt such a mechanism would have saved me many hours
> of debugging exceptions in Haskell systems I've worked on in the past.
>
> I considered commenting about that directly on the proposal, but I figure
> this is a better place to suggest expanding the scope of the change :) .
> Totally understandable if you want to keep this proposal focused on
> stacktraces, but I think it'd be good to consider this as a potential
> future improvement.
>
> -Michael
>
> On Thu, May 7, 2020 at 3:55 PM Ben Gamari  wrote:
>
>>
>> Hi everyone,
>>
>> After a nice discussion on IRC about the unfortunate state of error
>> reporting in Haskell, I felt compelled to write down some long-lingering
>> thoughts regarding backtraces on exceptions. The result is GHC proposal
>> #330 [1]. I think the approach is viable and perhaps even
>> straightforward. I have the sketch of an implementation here [2].
>>
>> Please have a look at the proposal and leave your comments. If there is
>> consensus it is possible that we could have this done for 8.12.
>>
>> Cheers,
>>
>> - Ben
>>
>>
>> [1] https://github.com/ghc-proposals/ghc-proposals/pull/330
>> [2] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3236
>> ___
>> ghc-devs mailing list
>> ghc-d...@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
> ___
> ghc-devs mailing list
> ghc-d...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [ANNOUNCE] Glasgow Haskell Compiler 8.10.1-rc1 released

[Carter Schonwald]

Yeah, like how we removed x87 support from code gen except one tiny piece
in the abi, so 32bit x86 code gen is always -msse2 flavor so rounding now
acts sane :)

(A tiny step in a long running make floating point great effort of mine)

On Sat, Jan 25, 2020 at 7:39 AM Brandon Allbery  wrote:

>
>
> On Fri, Jan 24, 2020 at 11:58 PM Ben Gamari  wrote:
>
>>  * A number of improvements in code generation, including changes
>>
>
> This seems like it's missing some detail.
>
> --
> brandon s allbery kf8nh
> allber...@gmail.com
> ___
> ghc-devs mailing list
> ghc-d...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [ANNOUNCE] GHC 8.8.1 and cabal-install version

[Carter Schonwald]

V1 or v2 install?

On Mon, Sep 2, 2019 at 11:42 AM George Colpitts 
wrote:

> https://www.haskell.org/ghc/blog/20190825-ghc-8.8.1-released.html says
>
> cabal-install users should note that cabal-install-3.0 or later is
> required for use with GHC 8.8.
>
> but this seems wrong or have I done something wrong?
>
> $ cabal install cabal-install
> cabal install cabal-install
> ...
>
> Resolving dependencies...
> cabal: Could not resolve dependencies:
> [__0] trying: cabal-install-3.0.0.0 (user goal)
> [__1] next goal: time (dependency of cabal-install)
> [__1] rejecting: time-1.9.3/installed-1.9... (conflict: cabal-install =>
> base>=4.8 && <4.13, time => base==4.13.0.0/installed-4.1...)
> [__1] trying: time-1.9.3
> [__2] next goal: stm (dependency of cabal-install)
> [__2] rejecting: stm-2.5.0.0/installed-2.5... (conflict: cabal-install =>
> base>=4.8 && <4.13, stm => base==4.13.0.0/installed-4.1...)
> [__2] trying: stm-2.5.0.0
> [__3] next goal: process (dependency of cabal-install)
> [__3] rejecting: process-1.6.5.1/installed-1.6... (conflict: cabal-install
> =>
> base>=4.8 && <4.13, process => base==4.13.0.0/installed-4.1...)
> [__3] trying: process-1.6.5.1
> [__4] next goal: pretty (dependency of cabal-install)
> [__4] rejecting: pretty-1.1.3.6/installed-1.1... (conflict: cabal-install
> =>
> base>=4.8 && <4.13, pretty => base==4.13.0.0/installed-4.1...)
> [__4] trying: pretty-1.1.3.6
> [__5] next goal: network (dependency of cabal-install)
> [__5] rejecting: network-3.1.0.1/installed-CeX... (conflict: cabal-install
> =>
> base>=4.8 && <4.13, network => base==4.13.0.0/installed-4.1...)
> [__5] trying: network-3.1.0.1
> [__6] trying: hackage-security-0.5.3.0 (dependency of cabal-install)
> [__7] next goal: template-haskell (dependency of hackage-security)
> [__7] rejecting: template-haskell-2.15.0.0/installed-2.1... (conflict:
> cabal-install => base>=4.8 && <4.13, template-haskell =>
> base==4.13.0.0/installed-4.1...)
> [__7] rejecting: template-haskell-2.15.0.0, template-haskell-2.14.0.0,
> template-haskell-2.13.0.0, template-haskell-2.12.0.0,
> template-haskell-2.11.1.0, template-haskell-2.11.0.0,
> template-haskell-2.10.0.0, template-haskell-2.9.0.0,
> template-haskell-2.8.0.0,
> template-haskell-2.7.0.0, template-haskell-2.6.0.0,
> template-haskell-2.5.0.0,
> template-haskell-2.4.0.1, template-haskell-2.4.0.0,
> template-haskell-2.3.0.1,
> template-haskell-2.3.0.0, template-haskell-2.2.0.0 (constraint from
> non-upgradeable package requires installed instance)
> [__7] fail (backjumping, conflict set: cabal-install, hackage-security,
> template-haskell)
> After searching the rest of the dependency tree exhaustively, these were
> the
> goals I've had most trouble fulfilling: base, cabal-install, directory,
> template-haskell, process, time, network, pretty, hackage-security,
> deepseq,
> HTTP, stm, cabal-install:lib
>
>
> On Mon, Aug 26, 2019 at 6:25 AM Ben Gamari  wrote:
>
>>
>> Hello everyone,
>>
>> The GHC team is pleased to announce the release candidate for GHC 8.8.1.
>> The source distribution, binary distributions, and documentation are
>> available at
>>
>> https://downloads.haskell.org/ghc/8.8.1
>>
>> This release is the culmination of over 3000 commits by over one hundred
>> contributors and has several new features and numerous bug fixes
>> relative to GHC 8.6:
>>
>>  * Visible kind applications are now supported (GHC Proposal #15)
>>
>>  * Profiling now works correctly on 64-bit Windows (although still may
>>be problematic on 32-bit Windows due to platform limitations; see
>>#15934)
>>
>>  * A new code layout algorithm for amd64's native code generator
>>significantly improving the runtime performance of some kernels
>>
>>  * The introduction of a late lambda-lifting pass which may reduce
>>allocations significantly for some programs.
>>
>>  * Further work on Trees That Grow, enabling improved code re-use of the
>>Haskell AST in tooling
>>
>>  * Users can write `forall` in more contexts (GHC Proposal #7)
>>
>>  * The pattern-match checker is now more precise in the presence of
>>strict fields with uninhabited types.
>>
>>  * A comprehensive audit of GHC's memory ordering barriers has been
>>performed, resulting in a number of fixes that should significantly
>>improve the reliability of programs on architectures with
>>weakly-ordered memory models (e.g. PowerPC, many ARM and AArch64
>>implementations).
>>
>>  * A long-standing linker limitation rendering GHCi unusable with
>>projects with cyclic symbol dependencies has been fixed (#13786)
>>
>>  * Further work on the Hadrian build system
>>
>>  * Countless miscellaneous bug-fixes
>>
>> Unfortunately, due to a build issue (#17108) found late in the release
>> process
>> i386 Windows builds are currently unavailable. These will be provided in
>> the coming weeks.
>>
>> As always, if anything looks amiss do let us know.
>>
>> Happy compiling!
>>
>> Cheers,
>>
>> - Ben
>>
>>
>> [1]
>> https://downlo

Re: [ANNOUNCE] GHC 8.4.4 released

[Carter Schonwald]

Hey David, i'm looking at the git history andit doesn't seem to have any
commits between 8.4.3 and 8.4.4 related to the dataToTag issue

does any haskell code in the while trigger the bug on 8.4 series?

On Sun, Oct 21, 2018 at 11:06 AM David Feuer  wrote:

> Did  this release fix the dataToTag# issue? I think that has a number of
> people concerned.
> On Oct 18, 2018, at 11:46 AM, Ben Gamari  wrote:
>>
>> Jens Petersen  writes:
>>
>>  On Mon, 15 Oct 2018 at 07:17, Ben Gamari  wrote:
>>>
  The GHC team is pleased to announce the availability of GHC 8.4.4

>>>
>>>  Thank you
>>>
>>>  As always, the full release notes can be found in the users guide,

>>>
>>>  
>>> https://downloads.haskell.org/~ghc/8.4.4/docs/html/users_guide/8.4.4-notes.html#base-library
>>>
>>>  I think this base text is out of date, and could be dropped, right?
>>
>>
>> Indeed it is.
>>
>>  I see that stm was also bumped: though it is not listed in
>>>  
>>> https://downloads.haskell.org/~ghc/8.4.4/docs/html/users_guide/8.4.4-notes.html#included-libraries
>>
>>
>> Also true. However, in my mind this isn't nearly as significant as the
>> `text` bump, which affects many users and fixes extremely bad
>> misbehavior.
>>
>> Thanks for noticing these!
>>
>> Cheers
>>
>> - Ben
>>
>> --
>>
>> ghc-devs mailing list
>> ghc-d...@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>> ___
> ghc-devs mailing list
> ghc-d...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Testing that packages still compile

[Carter Schonwald]

It may be that there’s quite a bit of code that doesn’t have explicit top
level type signatures?  That’s legal in Haskell but considered bad style /
bad practice for packages.  I’m not sure if the norms in O’Caml reflect the
same inclination. This may complicate localizing type errors

On Thu, May 31, 2018 at 11:51 AM davean  wrote:

> My experience may not be representative, but I've done waves of updating
> packages for a new major GHC release a few times now. I believe for the
> AMP-containing update of GHC I submitted patches to over 40 packages. My
> experience is far from universal, but I extensive enough to be informative.
>
> In my experience, Haskell's types gave precise sources for the error. As
> the packages form a DAG, issues with dependency packages were sorted out
> before I got to packages using them since the types caught any issues at
> the point that package was compiled. By when the dependent package was
> compiled, the type signatures of the dependency package was decided, and
> any compilation issues represented a legitimate API change requiring a
> patch to the package failing to compile. GHC flagged these issues at the
> point of use. Only rarely did I have to look in more than one place, and in
> those cases, it was universally inside the same package. Most of these were
> caused by changes in the unifier and were from the use of moderately exotic
> type system extensions that were purposefully changed causing disagreement
> inside the package about how to resolve the types since the design depended
> on ambiguity.
>
> Other than this last case, fixing the packages has been almost entirely
> procedural. It might take some time and familiarization with the package to
> make sure the change made was of sufficient quality to warrant submitting a
> patch instead of merely being correct, but it was never any mystery where
> the problem lay. I'd be curious what sort of issues you're encountering
> that caused confusion about the origin point of the issue. Its been over a
> decade since I used an ML language though so I'm not sure how Ocaml's type
> level specifications interact across packages. OCaml has some features that
> seem like they may lead to less orderly resolution of such problems (module
> functors come to mind as potentially interfering with the orderly nature of
> package dependencies).
>
> -davean
>
> On Thu, May 31, 2018 at 5:32 AM, Sébastien Hinderer <
> sebastien.hinde...@inria.fr> wrote:
>
>> Dear all,
>>
>> I am part of the OCaml development team. As you may know, OCaml has a
>> package manager a bit similar to cabal whose name is opam.
>>
>> One of my colleagues spends quite a lot of time trying to make sure that
>> packages still compile with a new version of the compiler, when we
>> release it. When a package does not compile any longer, it seems it is a
>> highly non-trivial task to figure out what exactly is broken: is it the
>> package itself which has been broken by a change in the compiler, or is
>> it one of its dependencies.
>>
>> I am assuming the same kind of problems occur with Haskell and am
>> wondering how they are handle.
>>
>> Has there been something published on this kind of problem?
>>
>> Any pointer, comment or contact appreciated.
>>
>> Best wishes,
>>
>> Sébastien.
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Scoped Type Variables discussion forum [was: open up the issues tracker on ghc-proposals]

[Carter Schonwald]

I mean for the fixed / new one I’m proposing :)

On Sun, May 20, 2018 at 8:21 PM Carter Schonwald 
wrote:

> No. I’m saying make same variables get the parent quantified, even if it’s
> implicit.
>
> Breaking changes are ok if they make things better.
>
> Measuring impact really comes down to making the patch and measuring. It
> will be an easy to fix breaking change and my experience has been that
> teams in an industrial context are a ok with none silent breaking changes.
> This would be very easy to catch :)
>
> On the pedagogy side it actually makes learning simpler afaict :)
>
> On Sun, May 20, 2018 at 8:03 PM Anthony Clayden <
> anthony_clay...@clear.net.nz> wrote:
>
>> On Mon, 21 May 2018 at 11:23 AM, Carter Schonwald <
>> redir...@vodafone.co.nz> wrote:
>>
>>> indeed .. and we can reasonably say "lets deal with the bandaid in one
>>> go by cleaning it up  in the next standard"
>>>
>>
>> Thanks Carter/Brandon, the reason for asking how we should go about the
>> discussion was exactly: where/how are we going to maximise the chance of
>> finding out what code is out there, and how disruptive any 'clean up' might
>> be?
>>
>> Ghc has occasionally made breaking releases (not saying that's what we
>> want to do), usually with some advance warning/deprecation period. And
>> generally the Haskell community has accommodated that with understanding of
>> the decision, to fix their code.
>>
>>
>>
>>> so what would the next gen look like?
>>>
>>> eg: fresh variables get the usual implicit forall at the front of the
>>> type, and everything else either needs an explicit quantifier OR it refers
>>> to the outer implicit quantified variable?
>>>
>>
>> I wanted to avoid discussing 'next gen' in possibly-obscure/write-only
>> mailing lists; and preferably get the discussion where posterity can see
>> the reasoning/examination of options.
>>
>> "fresh variables get the usual implicit forall" is what happens now.
>> (It's just that the User Guide explains it really badly -- I'm trying to
>> fix that separately https://ghc.haskell.org/trac/ghc/ticket/15146 .) If
>> the outer variable(s) are not explicitly forall-quantified, then even
>> same-named variables count as fresh. IOW merely putting a `forall` can
>> change the meaning of a program -- that's what causes the most confusion
>> (judging by SO).
>>
>> The exception is variables bound in a pattern signature for an
>> existentially-quantified data constructor: they *must* be fresh. This is
>> hard for a reader to follow because the pattern signature with data
>> constructor looks the same whether or not the constructor is
>> existentially-quantified. What's worse a constructor might have a mix of
>> existential and universal variables.
>>
>> AntC
>>
>>
>>> On Sat, May 19, 2018 at 2:56 PM, Brandon Allbery 
>>> wrote:
>>>
>>>> On Sat, May 19, 2018 at 7:32 AM, Anthony Clayden <
>>>> anthony_clay...@clear.net.nz> wrote:
>>>>
>>>>> So the explanation I've seen for the current design is it was 
>>>>> deliberately idiosyncratic, to minimise any disruption to existing code. 
>>>>> Then I'm asking whether any of that code is still around? If not/if it's 
>>>>> been re-factored to use ScopedTypeVariables, then any tweak to the design 
>>>>> could have a freer hand.
>>>>>
>>>>>
>>>> The reason there's no discussion about that is that nobody here has the
>>>> ability to go hunt down every last piece of code in every public or private
>>>> (think Standard Chartered, Facebook, etc.) code base and its current owner,
>>>> and order them to "fix" it. You can't win that battle.
>>>>
>>>> --
>>>> brandon s allbery kf8nh   sine nomine
>>>> associates
>>>> allber...@gmail.com
>>>> ballb...@sinenomine.net
>>>> unix, openafs, kerberos, infrastructure, xmonad
>>>> http://sinenomine.net
>>>>
>>>
>>>> ___
>>>> Glasgow-haskell-users mailing list
>>>> Glasgow-haskell-users@haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>>>
>>>>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Scoped Type Variables discussion forum [was: open up the issues tracker on ghc-proposals]

[Carter Schonwald]

No. I’m saying make same variables get the parent quantified, even if it’s
implicit.

Breaking changes are ok if they make things better.

Measuring impact really comes down to making the patch and measuring. It
will be an easy to fix breaking change and my experience has been that
teams in an industrial context are a ok with none silent breaking changes.
This would be very easy to catch :)

On the pedagogy side it actually makes learning simpler afaict :)

On Sun, May 20, 2018 at 8:03 PM Anthony Clayden <
anthony_clay...@clear.net.nz> wrote:

> On Mon, 21 May 2018 at 11:23 AM, Carter Schonwald 
> wrote:
>
>> indeed .. and we can reasonably say "lets deal with the bandaid in one go
>> by cleaning it up  in the next standard"
>>
>
> Thanks Carter/Brandon, the reason for asking how we should go about the
> discussion was exactly: where/how are we going to maximise the chance of
> finding out what code is out there, and how disruptive any 'clean up' might
> be?
>
> Ghc has occasionally made breaking releases (not saying that's what we
> want to do), usually with some advance warning/deprecation period. And
> generally the Haskell community has accommodated that with understanding of
> the decision, to fix their code.
>
>
>
>> so what would the next gen look like?
>>
>> eg: fresh variables get the usual implicit forall at the front of the
>> type, and everything else either needs an explicit quantifier OR it refers
>> to the outer implicit quantified variable?
>>
>
> I wanted to avoid discussing 'next gen' in possibly-obscure/write-only
> mailing lists; and preferably get the discussion where posterity can see
> the reasoning/examination of options.
>
> "fresh variables get the usual implicit forall" is what happens now. (It's
> just that the User Guide explains it really badly -- I'm trying to fix that
> separately https://ghc.haskell.org/trac/ghc/ticket/15146 .) If the outer
> variable(s) are not explicitly forall-quantified, then even same-named
> variables count as fresh. IOW merely putting a `forall` can change the
> meaning of a program -- that's what causes the most confusion (judging by
> SO).
>
> The exception is variables bound in a pattern signature for an
> existentially-quantified data constructor: they *must* be fresh. This is
> hard for a reader to follow because the pattern signature with data
> constructor looks the same whether or not the constructor is
> existentially-quantified. What's worse a constructor might have a mix of
> existential and universal variables.
>
> AntC
>
>
>> On Sat, May 19, 2018 at 2:56 PM, Brandon Allbery 
>> wrote:
>>
>>> On Sat, May 19, 2018 at 7:32 AM, Anthony Clayden <
>>> anthony_clay...@clear.net.nz> wrote:
>>>
>>>> So the explanation I've seen for the current design is it was deliberately 
>>>> idiosyncratic, to minimise any disruption to existing code. Then I'm 
>>>> asking whether any of that code is still around? If not/if it's been 
>>>> re-factored to use ScopedTypeVariables, then any tweak to the design could 
>>>> have a freer hand.
>>>>
>>>>
>>> The reason there's no discussion about that is that nobody here has the
>>> ability to go hunt down every last piece of code in every public or private
>>> (think Standard Chartered, Facebook, etc.) code base and its current owner,
>>> and order them to "fix" it. You can't win that battle.
>>>
>>> --
>>> brandon s allbery kf8nh   sine nomine
>>> associates
>>> allber...@gmail.com
>>> ballb...@sinenomine.net
>>> unix, openafs, kerberos, infrastructure, xmonad
>>> http://sinenomine.net
>>>
>>
>>> ___
>>> Glasgow-haskell-users mailing list
>>> Glasgow-haskell-users@haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>>
>>>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Scoped Type Variables discussion forum [was: open up the issues tracker on ghc-proposals]

[Carter Schonwald]

indeed .. and we can reasonably say "lets deal with the bandaid in one go
by cleaning it up  in the next standard"

so what would the next gen look like?

eg: fresh variables get the usual implicit forall at the front of the type,
and everything else either needs an explicit quantifier OR it refers to the
outer implicit quantified variable?

On Sat, May 19, 2018 at 2:56 PM, Brandon Allbery 
wrote:

> On Sat, May 19, 2018 at 7:32 AM, Anthony Clayden <
> anthony_clay...@clear.net.nz> wrote:
>
>> So the explanation I've seen for the current design is it was deliberately 
>> idiosyncratic, to minimise any disruption to existing code. Then I'm asking 
>> whether any of that code is still around? If not/if it's been re-factored to 
>> use ScopedTypeVariables, then any tweak to the design could have a freer 
>> hand.
>>
>>
> The reason there's no discussion about that is that nobody here has the
> ability to go hunt down every last piece of code in every public or private
> (think Standard Chartered, Facebook, etc.) code base and its current owner,
> and order them to "fix" it. You can't win that battle.
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: PSA for Cabal 2.2 new-* users regarding .ghc.environment files

[Carter Schonwald]

Seems like that’d be a worthwhile cleanup / fix up  release so this can be
more visible / less silent.  :)

On Sat, May 12, 2018 at 6:11 PM Herbert Valerio Riedel 
wrote:

> On Sat, May 12, 2018 at 10:41 PM, Gershom B  wrote:
> > In particular, there is not good information provided by ghc about
> > when these files are picked up and used.
>
> Fwiw, there's already an overdue patch up for that at
> https://phabricator.haskell.org/D4689
>
> If there's enough demand, this could in theory even make it into a
> future GHC 8.4.3
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Scoped type variables Re: Open up the issues tracker on ghc-proposals

[Carter Schonwald]

Please do this!

I don’t care what forums or list or whatever. As long as it’s collated and
such

It could even be on the prime issue tracker for prime proposals.  Just that
it’s written down :)

On Wed, May 2, 2018 at 7:17 PM Anthony Clayden 
wrote:

> On Th, 3 May 2018 at 13:53 UTC, Joachim Breitner wrote:
> > I am worried about the signal-to-noise ratio for those poor committee
> members ...
>
> Thanks Joachim, Yes that's exactly the worry. So please tell the rest of
> us how to best use your collective time.
>
> First help yourselves/get your own shit together:
> there's now a long discussion on the committee mailing list about the
> specifics of #99. There are good questions, good answers, good ideas. None
> of the rest of use can contribute to that. The committee list is supposed
> to be low volume/decision making only. WTF?
>
> (That seems to be triggered by one particular committee member who
> seldom/never looks at github, and prefers email discussion. Yous others
> could perhaps coach him?)
>
> > hmm, some of that sounds like it would be better suited for haskell-cafe,
> StackOverflow, ...
>
> My point about "sometimes it's more of a niggle" was aimed at exactly your
> (Joachim's) series of proposals 'Resurrect Pattern Signatures'. The
> motivation is it helps "confused beginners". But those beginners won't be
> providing feedback on github. Instead you've got feedback from experienced
> users who've all said they see no point in the proposal. So the discussion
> has gone round and round and spun off other proposals. That whole series of
> discussions would be better happening somewhere else: where?
>
> David's quite correct
> >> Haskell-cafe might work, but it's a bit tricky to pull up all the
> language extension ideas discussed there.
>
> My impression is not many people who could help refine a pre-proposal ever
> take part in the cafe.
>
> Stackoverflow likewise. (I did raise a 'how do I do this?' type question
> there. It was David who responded, thank you. But I ended up answering it
> myself; and it turned out there was already a proposal on the slate.)
>
> >> My limited experience with glasgow-haskell-users is that it's where
> threads go to die.
>
> (I did try to continue one of David's threads there a few months ago.) But
> yes, my experience too. And that's sad because it's a wasted resource. I'm
> grateful to Simon for noticing this thread; but most topics I've raised on
> ghc-users have gone nowhere. So then I've tried pursuing them by poaching
> on Trac or github -- which is an abuse, I know.
>
> > Most vague ideas get better when the proposer is nudged to sit down and 
> > write
> it up properly! (And some get dropped in the process, which is also good
> :-)).
>
> Yes exactly what I'm trying to get to happen. How/where?
>
> Here's a specific example: there's talk of baking ScopedTypeVariables into
> the H2020 standard. There's also people unhappy with ScopedTypeVariables as
> currently (I'm one, but I don't know if my reservations are the same as
> others'). If we don't have an alternative proposal (and preferably an
> experimental extension) by 2020, the committee can only go with the as
> currently fait accompli or continue the H2010 status quo.
>
> I can volunteer to at least scrape together all the objections to
> ScopedTypeVariables as currently. It's not yet a proposal, so not on
> github. Start a wiki page? A cafe thread? (It'll get lost.) A ghc-users
> thread? (It'll get ignored.)
>
>
> AntC
>
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] PSA: `cabal update` command needs manual unsticking

[Carter Schonwald]

My cabal v2 seemed to be using 00 indices.  Much to my confusion.  Maybe I
should reinstall it and check my config ;)

On Thu, Jan 4, 2018 at 5:25 PM Brandon Allbery  wrote:

> Correct: cabal-install 1.x still uses the old index format (00-index). The
> logic is different for 01-index, in order to support incremental update
> (appending when possible, instead of always having to download the whole
> thing again like with 00-index).
>
> On Thu, Jan 4, 2018 at 1:38 PM, Nathan Collins 
> wrote:
>
>> In case this confuses anyone else, I think this PSA only applies if
>> you're using cabal-install version 2.*, but please correct me if I'm
>> wrong.
>>
>> I had some ~/.cabal/packages/hackage.haskell.org/00-index.* files, but
>> not any 01-index.* files, and running `cabal update` didn't change
>> that. Then I noticed I was using cabal-install version 1.24.0.2. When
>> I upgraded to cabal-install version 2.0.0.1 and did another `cabal
>> update` the 01-index.* files appeared.
>>
>> Cheers,
>>
>> -nathan
>>
>> On Mon, Jan 1, 2018 at 5:24 PM, Gershom B  wrote:
>> > Dear Haskellers,
>> >
>> > A recent update to hackage, which fixed up the 01-index.tar.gz file,
>> > revealed a bug in existing versions of cabal-install, when index files
>> > are cleaned up. This bug means that the `cabal update` command, which
>> > updates the hackage index file, will fail silently and leave the old
>> > file in place. It is easy to get things working again, but it requires
>> > manual intervention. Here is the most straightforward way to get
>> > things working again:
>> >
>> > On gnu/linux or mac: rm ~/.cabal/packages/
>> hackage.haskell.org/01-index.*
>> > On windows: remove the same files, but from
>> > %appdata%\cabal\packages\hackage.haskell.org
>> >
>> > rerun `cabal update` to fetch a new 01-index.
>> >
>> > Apologies all for the inconvenience and any confusion this may have
>> > caused. There is a PR to fix this behavior in the works, but since the
>> > problem is on the client side, the fix will only improve the
>> > situations for new versions of `cabal`.
>> >
>> > Happy New Years to all, and cheers to a very functional 2018,
>> > Gershom
>> >
>> > p.s.: since the problem comes in unpacking the 01-index.tar.gz into
>> > the 01-index.tar, you can also just untar that file in place manually,
>> > or force cabal into doing the same by running `touch
>> > ~/.cabal/packages/hackage.haskell.org/01-index.tar`
>> 
>> > ___
>> > Haskell-Cafe mailing list
>> > To (un)subscribe, modify options or view archives go to:
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> > Only members subscribed via the mailman list are allowed to post.
>> ___
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>
>
>
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [was ghc-devs] Reasoning backwards with type families

[Carter Schonwald]

This was / perhaps still is one goal of injective type families too!  I’m
not sure why the current status is, but it’s defjnitely related

On Mon, Nov 20, 2017 at 3:44 AM Anthony Clayden <
anthony_clay...@clear.net.nz> wrote:

> > On Thu Nov 16 01:31:55 UTC 2017, David Feuer wrote:
>
> (Moving to ghc-users, there's nothing particularly dev-y.)
>
> > Sometimes it woulld be useful to be able to reason
> backwards
> > about type families.
>
> Hi David, this is a well-known issue/bit of a sore.
> Discussed much in the debate between type families
> compared to FunDeps.
>
> > For example, we have
> >
> > type family a && b where
> >   'False && b  = 'False
> >   'True  && b  = b
> >   a  && 'False = 'False
> >   a  && 'True  = a
> >   a  && a  = a
>
> > ... if we know something about the *result*,
> > GHC doesn't give us any way to learn anything about the
> arguments.
>
> You can achieve the improvement you want today.
>
> You'll probably find Oleg has a solution
> With FunDeps and superclass constraints, it'll go like this
>
> class (OnResult r a b, OnResult r b a) => And a b r | a b ->
> r
>
> instance And 'False b 'False
> -- etc, as you'd expect following the tf equations
> -- the instances are overlapping but confluent
>
> class OnResult r a b | r a -> b
> instance OnResult 'True a 'True
> instance OnResult 'False 'True 'False
>
> You could equally make `OnResult` a type family.
>
> If you can trace backwards to where `&&` is used,
> you might be able to add suitable constraints there.
>
> So there's a couple of futures:
> * typechecker plugins, using an SMT solver
> * injective type families
>the next phase is supposed to allow
>
> type family a && b = r | r a -> b, r b -> a where ...
>
> That will help with some type families
> (such as addition of Nats),
> plug1
>
> https://github.com/AntC2/ghc-proposals/blob/instance-apartness-guards/proposals/-instance-apartness-guards.rst#injective-type-families
>
> but I don't see it helping here.
> plug2 (this example)
>
> https://github.com/AntC2/ghc-proposals/blob/instance-apartness-guards/proposals/-instance-apartness-guards.rst#type-family-coincident-overlap
>
> Because (for example) if you unify the first two equations,
> (that is, looking for coincident overlap)
>
> 'False && 'False = 'False
> 'True && 'False = 'False
>
> That's inconsistent on dependency ` r b -> a`.
>
> And you can't fix it by re-ordering the closed equations.
>
> > For (&&), the obvious things you'd want are ...
> >
> > There's nothing inherently impossible about this sort of
> reasoning.
>
> No-ish but. It relies on knowing kind `Bool` is closed.
> And GHC doesn't pay attention to that.
> So you need to bring type family `Not`
> into the reasoning; hence a SMT solver.
>
> > ...
> > I wouldn't necessarily expect GHC
> > to be able to work something like this out on its own.
>
> That's a relief ;-)
>
> > But it seems like there should be some way to allow the
> user
> > to guide it to a proof.
>
> Yes, an SMT solver with a model for kind `Bool`.
> (And a lot of hard work to teach it, by someone.)
>
> AntC
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: ConstraintKinds seems to be automatically enabled

[Carter Schonwald]

woops, i mispoke, its probably that bug brandon spoke of or somesuch,
didn't look closely enough at the previous email :)

On Fri, May 5, 2017 at 10:14 AM, Carter Schonwald <
carter.schonw...@gmail.com> wrote:

> in newer versions of ghc, client code of a module that uses constraint
> kinds gets constraint kinds enabled.
>
> this is to make it pleasant to use constraint kinds in libraries.
>
> this is deliberate feature :)
>
> On Thu, May 4, 2017 at 6:46 PM, Brandon Allbery 
> wrote:
>
>> On Thu, May 4, 2017 at 6:42 PM, Wolfgang Jeltsch <
>> g9ks1...@acme.softbase.org> wrote:
>>
>>> In my previous e-mail, I showed some code that uses the Constraint kind.
>>> I forgot to enable the ConstraintKinds extension though, but GHC 8.0.1
>>> did not complain. Is this a bug?
>>>
>>
>> I think it's a known side effect of * being conflated with Constraint, a
>> problem that is actively being worked on ( https://ghc.haskell.org/trac/g
>> hc/ticket/11715 ).
>>
>> --
>> brandon s allbery kf8nh   sine nomine
>> associates
>> allber...@gmail.com
>> ballb...@sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonad
>> http://sinenomine.net
>>
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>
>>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: ConstraintKinds seems to be automatically enabled

[Carter Schonwald]

in newer versions of ghc, client code of a module that uses constraint
kinds gets constraint kinds enabled.

this is to make it pleasant to use constraint kinds in libraries.

this is deliberate feature :)

On Thu, May 4, 2017 at 6:46 PM, Brandon Allbery  wrote:

> On Thu, May 4, 2017 at 6:42 PM, Wolfgang Jeltsch <
> g9ks1...@acme.softbase.org> wrote:
>
>> In my previous e-mail, I showed some code that uses the Constraint kind.
>> I forgot to enable the ConstraintKinds extension though, but GHC 8.0.1
>> did not complain. Is this a bug?
>>
>
> I think it's a known side effect of * being conflated with Constraint, a
> problem that is actively being worked on ( https://ghc.haskell.org/trac/
> ghc/ticket/11715 ).
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Floating Point Exceptions

[Carter Schonwald]

Adding sigfpe handling doesn't have a writeupnyet because it's on my
holiday project queue and the specifics of doing it nicely depend somewhat
on the target architecture.

If you want to get good errors in the mean time, register a sigfpe signal
handler at the top level and invoke a smidge of c code to get info.

Granted this doesn't give you a stack trace ...

On Wed, Dec 7, 2016 at 11:52 AM Dominic Steinitz 
wrote:

> Hello again,
>
>
>
> I removed my dependency on hmatrix and enabled floating point exceptions
> via `feenableexcept` hoping to get a call stack showing me where the
> exception was being raised but alas all I get is
>
>
>
> > *Main> main
>
> > ghc: ghc-iserv terminated (-8)
>
> > Leaving GHCi.
>
>
>
>
>
> My googling didn’t turn up much but as far as I can tell ghc does *not*
> handle sigfpe (googling "haskell sigfpe” turns up blog posts on Haskell by
> someone called “sigfpe”). I think it would be jolly useful to be able to
> get stack traces of floating point exceptions. How much work would this be?
> I’d be happy to have a go at it if someone could provide help and guidance.
>
>
>
> There seems to have been some discussion of it on the ghc-devs mailing
> list in September (
> https://mail.haskell.org/pipermail/ghc-devs/2016-September/date.html) but
> not much in the way of write up.
>
>
>
> Dominic Steinitz
>
> domi...@steinitz.org
>
> http://idontgetoutmuch.wordpress.com
>
>
>
> ___
>
> Glasgow-haskell-users mailing list
>
> Glasgow-haskell-users@haskell.org
>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal process status

[Carter Schonwald]

On Wednesday, July 20, 2016, Ben Gamari  wrote:

> Yuras Shumovich > writes:
>
> > Looks like reddit is a wrong place, so I'm replicating my comment here:
> >
> Thanks for your comments Yuras!
>
> >>   * Do you feel the proposed process is an improvement over the
> >> status quo?
> >
> > Yes, definitely. The existing process is too vague, so formalizing it
> > is a win in any case.
> >
> Good to hear.
>
> >>   * What would you like to see changed in the proposed process, if
> >> anything?
> >
> > The proposed process overlaps with the Language Committee powers. In
> > theory the Committee works on language standard, but de facto Haskell
> > is GHC/Haskell and GHC/Haskell is Haskell. Adding new extension to GHC
> > adds new extension to Haskell. So I'd like the process to enforce
> > separation between experimental extensions (not recommended in
> > production code) and language improvements. I'd like the process to
> > specify how the GHC Committee is going to communicate and share powers
> > with the Language Committee.
> >
> To clarify I think Language Committee here refers to the Haskell Prime
> committee, right?
>
> I think these two bodies really do serve different purposes.
> Historically the Haskell Prime committee has been quite conservative in
> the sorts of changes that they standardized; as far as I know almost all
> of them come from a compiler. I would imagine that the GHC Committee
> would be a gate-keeper for proposals entering GHC and only some time
> later, when the semantics and utility of the extension are
> well-understood, would the Haskell Prime committee consider introducing
> it to the Report. As far as I understand it, this is historically how
> things have worked in the past, and I don't think this new process would
> change that.
>
> Of course, let me know if I'm off-base here.


As one of the 20 members of the Haskell (Prime) 2020 committee id like to
interject on this front: the preliminary discussions the committee has had
thus far had a clear agreement that we shall aim to be a bit more
progressive about what shall be included in the standard. The main bar will
be the extent to which features or capabilities can be articulated without
over specifying implementation details and can tractably have compatible
but different compilers for the standard.

  I think some of the other prime committee members can articulate this a
bit better than I, so don't hold me to this precise phrasing ;)




>
> Cheers,
>
> - Ben
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal: ArgumentDo

[Carter Schonwald]

On Saturday, July 9, 2016, Henrik Nilsson 
wrote:

> Hi all,
>
> On 07/09/2016 08:09 AM, C Maeder wrote:
>
>> The asymmetry that you mention is already apparent for (Haskell98) infix
>> expressions, i.e. when "composing" lambda- or if-expression:
>>
>>   (if c then f else g) . \ x -> h x
>>
>> Parentheses around the last argument of "." do not matter, but
>> parentheses around the first argument make a real difference
>>
>
> But that has to do with how grammatical ambiguity related to
> in this case "if" and "lambda" are resolved by letting
> the constructs extend as far as possible to the right.
>
> This the standard way of resolving that kind of ambiguity
> across a very wide range of programming languages and parsing
> tools (e.g. preferring shift over reduce in an LR parser).
> (And also in principle how lexical ambiguities are typically
> resolved, sometimes referred to as the "maximal munch rule".)
>
> In contrast, the present proposal suggests treating
> different argument positions in grammatically
> different ways (different non-terminals). As far as I know,
> that is unprecedented. And in any case, it manifestly
> complicates the grammar (more non-terminals) and as
> a consequence adds another grammatical hurdle to
> learning the language.
>
>
Well said, I think this articulates exactly what I'm reacting to.  Thanks
for taking the time to articulate this.  I agree.



> I think we often tend to forget just how exotic
> Haskell syntax can be to the uninitiated. Which is
> the vast majority of the rest of the programmer world
> as well as beginners. Only the other week I gave a
> presentation to a group of highly skilled developers
> at a tech-savvy London-based company. The emphasis of
> the talk was not at all on Haskell as such, but small
> Haskell fragments did feature here and there, which I
> (naively) thought would be mostly self explanatory.
> Well, let's just say I was wrong.
>
> Now, we can't make Haskell syntax less exotic (not that I'd
> advocate that: I think basic Haskell syntax for the most part
> strikes a pretty good balance on a number of counts), but we can
> certainly avoid making it even more complicated and exotic.
> Which the present proposal would, in my opinion.
>
> Best,
>
> /Henrik
>
> --
> Henrik Nilsson
> School of Computer Science
> The University of Nottingham
> n...@cs.nott.ac.uk
>
>
>
>
> This message and any attachment are intended solely for the addressee
> and may contain confidential information. If you have received this
> message in error, please send it back to me, and immediately delete it.
> Please do not use, copy or disclose the information contained in this
> message or in any attachment.  Any views or opinions expressed by the
> author of this email do not necessarily reflect the views of the
> University of Nottingham.
>
> This message has been checked for viruses but the contents of an
> attachment may still contain software viruses which could damage your
> computer system, you are advised to perform your own checks. Email
> communications with the University of Nottingham may be monitored as
> permitted by UK legislation.
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal: ArgumentDo

[Carter Schonwald]

Can you walk me through how this simplifies the grammar etc in concrete
compare contrast or what the diffs between the grammar and associated
engineering would be?

I don't see how it simplifies the grammar, but I could be a bit obtuse.

That aside, I'm also a bit fuzzy on the other claim, that this change will
simplify post parsing engineering,
On Jul 7, 2016 4:47 PM, "Jon Purdy"  wrote:

> > ambiguity is bad for humans, not just parsers.
>
> This is not ambiguous. It’s removing the need for a redundant set of
> parentheses, whichever way you slice it. Of course, some redundancy is
> useful for readability (look at natural language), but you should
> really be explicit if you’re arguing from that position.
>
> > perhaps most damningly,
> >>
> >>
> >> f do{ x } do { y }
> >
> >
> > is just reallly really weird/confusing to me
>
> By “weird”, do you mean anything other than “I don’t understand it,
> and I blame it”? Can you give an example of how you might misparse it,
> as a human reader?
>
> >> It's harder to read than the alternative.
> >>
> >> Creating a language extension to get rid of a single character is
> overkill
> >> and unnecessary.
>
> It’s only a language extension for backward compatibility. It’s really
> fixing a bug in the grammar.
>
> > I'm all in favor of doing engineering work to *improve*
> > our parser error messages and suggestions, but not stuff that complicates
> > parsing for humans  as well as machines
>
> This would be a simplification of the parser if the bug hadn’t been
> standardised originally.
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal: ArgumentDo

[Carter Schonwald]

the fact that its perilously close to looking like *1 typo* away from a
parser error about record syntax makes me
*-1000* now

thanks for pointing this out!

On Thu, Jul 7, 2016 at 1:32 PM, Brandon Allbery  wrote:

> Didn't they already say they disliked record syntax for exactly that
> reason?
>
> On Thu, Jul 7, 2016 at 1:23 PM, David Feuer  wrote:
>
>> What makes
>>
>> f do{x} do{y}
>>
>> any harder to read than similar record syntax?
>>
>> f Foo{foo=3} Foo{foo=4}
>>
>> On Thu, Jul 7, 2016 at 1:15 PM, Carter Schonwald
>>  wrote:
>> > agreed -1,
>> > ambiguity is bad for humans, not just parsers.
>> >
>> > perhaps most damningly,
>> >>
>> >>
>> >> f do{ x } do { y }
>> >
>> >
>> > is just reallly really weird/confusing to me, and as the proposal itself
>> > says at the end as the cons:
>> >
>> >
>> >> It's harder to read than the alternative.
>> >>
>> >> Creating a language extension to get rid of a single character is
>> overkill
>> >> and unnecessary.
>> >>
>> >> You can already get rid of the $ by just adding parentheses.
>> >
>> > which kinda kills any benefit in my mind. thats a HUGE complexity vs
>> > alternative ratio. I'm all in favor of doing engineering work to
>> *improve*
>> > our parser error messages and suggestions, but not stuff that
>> complicates
>> > parsing for humans  as well as machines
>> >
>> >
>> > On Wed, Jul 6, 2016 at 9:50 PM, Evan Laforge  wrote:
>> >>
>> >> On Wed, Jul 6, 2016 at 10:39 AM, Bardur Arantsson <
>> s...@scientician.net>
>> >> wrote:
>> >> > On 07/04/2016 12:31 PM, Akio Takano wrote:
>> >> >> Hi glasgow-haskell-users,
>> >> >>
>> >> >> I have written a wiki page about a proposed extension called
>> >> >> ArgumentDo. It's a small syntactic extension that allows "do"
>> >> >> expressions, lambdas and a few other kinds of expressions to be used
>> >> >> as function arguments, without parentheses.
>> >> >>
>> >> >> https://ghc.haskell.org/trac/ghc/wiki/ArgumentDo
>> >> >>
>> >> >> Any feedback is appreciated. In particular, since the idea has
>> >> >> received mixed support (see the "Discussion" section on the wiki
>> >> >> page), I'd like to make sure that there is enough support for this
>> >> >> feature to justify an implementation in GHC.
>> >> >>
>> >> >
>> >> > -1
>> >> >
>> >> > Reasons have already been given in previous threads on this. However,
>> >> > I'd point especially to the fact that people don't *agree* that this
>> is
>> >> > more readable as a very strong point against -- regardless of whether
>> >> > any one individual thinks it's more readable or not. The point is the
>> >> > there seems to be a lot of disagreement -- that indicates to me that
>> >> > this cannot by definition be a "clear win"[1]. Disclosure: I
>> personally
>> >> > find it less readable because of the implicitness. Implicitness which
>> >> > has a non-trivial probability of affecting semantics is bad in my
>> book.
>> >> > Frankly, if it came to it, I'd rather just remove $ and deal with the
>> >> > parentheses.
>> >>
>> >> I'm -1 because I think there are already too many styles.  So I don't
>> >> agree with the general sentiment that the parser should accept lots of
>> >> stuff and to rely on style guides to specify something, because in
>> >> practice everyone has their own style guide.
>> >>
>> >> I trained myself to see juxtaposition as highest precedence (which
>> >> newcomers still struggle over) and it's confusing to see juxtaposition
>> >> that has higher precedence because one of them is a keyword.  In the
>> >> same way I'm confused by 'f a { b = c }', but it's too late to change
>> >> that one.  I suppose this is already on the wiki page in the "cons"
>> >> section.
>> >> ___
>> >> Glasgow-haskell-users mailing list
>> >> Glasgow-haskell-users@haskell.org
>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>> >
>> >
>> >
>> > ___
>> > Glasgow-haskell-users mailing list
>> > Glasgow-haskell-users@haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>> >
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>
>
>
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal: ArgumentDo

[Carter Schonwald]

agreed -1,
ambiguity is bad for humans, not just parsers.

perhaps most damningly,


> f do{ x } do { y }


is just reallly really weird/confusing to me, and as the proposal
itself says at the end as the cons:



   - It's harder to read than the alternative.
>- Creating a language extension to get rid of a single character is 
> overkill and unnecessary.
>- You can already get rid of the $ by just adding parentheses.
>

which kinda kills any benefit in my mind. thats a HUGE complexity vs
alternative ratio. I'm all in favor of doing engineering work to
*improve* our parser error messages and suggestions, but not stuff
that complicates parsing for humans  as well as machines


On Wed, Jul 6, 2016 at 9:50 PM, Evan Laforge  wrote:

> On Wed, Jul 6, 2016 at 10:39 AM, Bardur Arantsson 
> wrote:
> > On 07/04/2016 12:31 PM, Akio Takano wrote:
> >> Hi glasgow-haskell-users,
> >>
> >> I have written a wiki page about a proposed extension called
> >> ArgumentDo. It's a small syntactic extension that allows "do"
> >> expressions, lambdas and a few other kinds of expressions to be used
> >> as function arguments, without parentheses.
> >>
> >> https://ghc.haskell.org/trac/ghc/wiki/ArgumentDo
> >>
> >> Any feedback is appreciated. In particular, since the idea has
> >> received mixed support (see the "Discussion" section on the wiki
> >> page), I'd like to make sure that there is enough support for this
> >> feature to justify an implementation in GHC.
> >>
> >
> > -1
> >
> > Reasons have already been given in previous threads on this. However,
> > I'd point especially to the fact that people don't *agree* that this is
> > more readable as a very strong point against -- regardless of whether
> > any one individual thinks it's more readable or not. The point is the
> > there seems to be a lot of disagreement -- that indicates to me that
> > this cannot by definition be a "clear win"[1]. Disclosure: I personally
> > find it less readable because of the implicitness. Implicitness which
> > has a non-trivial probability of affecting semantics is bad in my book.
> > Frankly, if it came to it, I'd rather just remove $ and deal with the
> > parentheses.
>
> I'm -1 because I think there are already too many styles.  So I don't
> agree with the general sentiment that the parser should accept lots of
> stuff and to rely on style guides to specify something, because in
> practice everyone has their own style guide.
>
> I trained myself to see juxtaposition as highest precedence (which
> newcomers still struggle over) and it's confusing to see juxtaposition
> that has higher precedence because one of them is a keyword.  In the
> same way I'm confused by 'f a { b = c }', but it's too late to change
> that one.  I suppose this is already on the wiki page in the "cons"
> section.
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

CMM-to-ASM: Register allocation wierdness

[Carter Schonwald]

Agreed. There's also some other mismatches between ghc and llvm in a few
fun / interesting ways!



There's a lot of room for improvement in both code gens, but there's also a
lot of room to improve the ease of experimenting with improvements.  Eg we
don't have a peephole pass per target, so those get hacked into the pretty
printing code last time I checked

On Thursday, June 16, 2016, Ben Gamari > wrote:

>
> Ccing David Spitzenberg, who has thought about proc-point splitting, which
> is relevant for reasons that we will see below.
>
>
> Harendra Kumar  writes:
>
> > On 16 June 2016 at 13:59, Ben Gamari  wrote:
> >>
> >> It actually came to my attention while researching this that the
> >> -fregs-graph flag is currently silently ignored [2]. Unfortunately this
> >> means you'll need to build a new compiler if you want to try using it.
> >
> > Yes I did try -fregs-graph and -fregs-iterative both. To debug why
> nothing
> > changed I had to compare the executables produced with and without the
> > flags and found them identical.  A note in the manual could have saved me
> > some time since that's the first place to go for help. I was wondering
> if I
> > am making a mistake in the build and if it is not being rebuilt
> > properly. Your note confirms my observation, it indeed does not change
> > anything.
> >
> Indeed; I've opened D2335 [1] to reenable -fregs-graph and add an
> appropriate note to the users guide.
>
> >> All-in-all, the graph coloring allocator is in great need of some love;
> >> Harendra, perhaps you'd like to have a try at dusting it off and perhaps
> >> look into why it regresses in compiler performance? It would be great if
> >> we could use it by default.
> >
> > Yes, I can try that. In fact I was going in that direction and then
> stopped
> > to look at what llvm does. llvm gave me impressive results in some cases
> > though not so great in others. I compared the code generated by llvm and
> it
> > perhaps did a better job in theory (used fewer instructions) but due to
> > more spilling the end result was pretty similar.
> >
> For the record, I have also struggled with register spilling issues in
> the past. See, for instance, #10012, which describes a behavior which
> arises from the C-- sinking pass's unwillingness to duplicate code
> across branches. While in general it's good to avoid the code bloat that
> this duplication implies, in the case shown in that ticket duplicating
> the computation would be significantly less code than the bloat from
> spilling the needed results.
>
> > But I found a few interesting optimizations that llvm did. For example,
> > there was a heap adjustment and check in the looping path which was
> > redundant and was readjusted in the loop itself without use. LLVM either
> > removed the redundant  _adjustments_ in the loop or moved them out of the
> > loop. But it did not remove the corresponding heap _checks_. That makes
> me
> > wonder if the redundant heap checks can also be moved or removed. If we
> can
> > do some sort of loop analysis at the CMM level itself and avoid or remove
> > the redundant heap adjustments as well as checks or at least float them
> out
> > of the cycle wherever possible. That sort of optimization can make a
> > significant difference to my case at least. Since we are explicitly aware
> > of the heap at the CMM level there may be an opportunity to do better
> than
> > llvm if we optimize the generated CMM or the generation of CMM itself.
> >
> Very interesting, thanks for writing this down! Indeed if these checks
> really are redundant then we should try to avoid them. Do you have any
> code you could share that demosntrates this?
>
> It would be great to open Trac tickets to track some of the optimization
> opportunities that you noted we may be missing. Trac tickets are far
> easier to track over longer durations than mailing list conversations,
> which tend to get lost in the noise after a few weeks pass.
>
> > A thought that came to my mind was whether we should focus on getting
> > better code out of the llvm backend or the native code generator. LLVM
> > seems pretty good at the specialized task of code generation and low
> level
> > optimization, it is well funded, widely used and has a big community
> > support. That allows us to leverage that huge effort and take advantage
> of
> > the new developments. Does it make sense to outsource the code generation
> > and low level optimization tasks to llvm and ghc focussing on higher
> level
> > optimizations which are harder to do at the llvm level? What are the
> > downsides of using llvm exclusively in future?
> >
>
> There is indeed a question of where we wish to focus our optimization
> efforts. However, I think using LLVM exclusively would be a mistake.
> LLVM is a rather large dependency that has in the past been rather
> difficult to track (this is why we now only target one LLVM release in a
> given GHC release). Moreover, it's significantly slower than our
> existin

Re: CMM-to-ASM: Register allocation wierdness

[Carter Schonwald]

This email would have been marked spam had I not unmarked all your emails
as spam.  Also a gmail user :/

On Saturday, June 18, 2016, Simon Peyton Jones 
wrote:

> Takenobu, and others
>
> Thanks.  Several people have mentioned that email from me is ending up in
> spam.
>
> It turns out to be a fault in the Haskell.org mailman setup, which was
> mis-forwarding my email.
>
> Apparently it is fixed now.  *If THIS message ends up in spam with a
> complaint like that below, could you let me know?*
>
> Thanks
>
> Simon
>
>
>
>
> *From:* Takenobu Tani [mailto:takenobu...@gmail.com
> ]
> *Sent:* 18 June 2016 08:18
> *To:* Simon Peyton Jones  >
> *Subject:* Re: CMM-to-ASM: Register allocation wierdness
>
>
>
> Hi Simon,
>
>
>
> I report to you about your mails.
>
>
>
> Maybe, your mails don't reach to Gmail users.
>
> I don't know why, but your mails have been distributed to "Spam" folder in
> Gmail.
>
>
>
> Gmail displays following message:
>
>   "Why is this message in Spam? It has a from address in microsoft.com
> 
> but has failed microsoft.com
> 's
> required tests for authentication."
>
>
>
>
>
> For reference, I attach the screen of my Gmail of spam folder.
>
> Recent your mails have been detected as spam.
>
> Please check your mail settings.
>
>
>
> Regards,
>
> Takenobu
>
>
>
> 2016-06-16 21:10 GMT+09:00 Simon Peyton Jones  >:
>
> | All-in-all, the graph coloring allocator is in great need of some love;
> | Harendra, perhaps you'd like to have a try at dusting it off and perhaps
> | look into why it regresses in compiler performance? It would be great if
> | we could use it by default.
>
> I second this.   Volunteers are sorely needed.
>
> Simon
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> 
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
> 
>
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Feedback on -Wredundant-constraints

[Carter Schonwald]

Either way, do we have a strong agreement that for ghc 8.2 that this
warning should be split up and the noiser part should be moved out of the
default wall set?

On Monday, June 6, 2016, Carter Schonwald 
wrote:

> To better elaborate :  I definitely want this for the next major version
> i.e. 8.2.* , but I'm also wondering if perhaps the "overly constrained
> type" warning should be flat out removed from Wall even in ghc 8.0.2,
>
> On Monday, June 6, 2016, Carter Schonwald  > wrote:
>
>> It's a tall ask, but why not?
>> On Jun 6, 2016 12:16 PM, "Eric Seidel"  wrote:
>>
>>>
>>>
>>> On Mon, Jun 6, 2016, at 07:37, Carter Schonwald wrote:
>>> > I don't suppose there's any hope of having this resolved prior to GHC
>>> 8.2
>>> > because it is a real usability regression? Because I think we can all
>>> > agree
>>> > that the proposed change would not break any 8.0 series code, and
>>> > positively impact everyone.
>>>
>>> Do you mean prior to 8.0.2?
>>> ___
>>> Glasgow-haskell-users mailing list
>>> Glasgow-haskell-users@haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>>
>>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Feedback on -Wredundant-constraints

[Carter Schonwald]

To better elaborate :  I definitely want this for the next major version
i.e. 8.2.* , but I'm also wondering if perhaps the "overly constrained
type" warning should be flat out removed from Wall even in ghc 8.0.2,

On Monday, June 6, 2016, Carter Schonwald 
wrote:

> It's a tall ask, but why not?
> On Jun 6, 2016 12:16 PM, "Eric Seidel"  > wrote:
>
>>
>>
>> On Mon, Jun 6, 2016, at 07:37, Carter Schonwald wrote:
>> > I don't suppose there's any hope of having this resolved prior to GHC
>> 8.2
>> > because it is a real usability regression? Because I think we can all
>> > agree
>> > that the proposed change would not break any 8.0 series code, and
>> > positively impact everyone.
>>
>> Do you mean prior to 8.0.2?
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> 
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Feedback on -Wredundant-constraints

[Carter Schonwald]

It's a tall ask, but why not?
On Jun 6, 2016 12:16 PM, "Eric Seidel"  wrote:

>
>
> On Mon, Jun 6, 2016, at 07:37, Carter Schonwald wrote:
> > I don't suppose there's any hope of having this resolved prior to GHC 8.2
> > because it is a real usability regression? Because I think we can all
> > agree
> > that the proposed change would not break any 8.0 series code, and
> > positively impact everyone.
>
> Do you mean prior to 8.0.2?
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Feedback on -Wredundant-constraints

[Carter Schonwald]

Strong emphatic agreement. Both that it should split up thusly and that the
latter shouldn't be in WALL. Otherwise it poisons the well for all be the
most sophisticated users of type level programming.

I don't suppose there's any hope of having this resolved prior to GHC 8.2
because it is a real usability regression? Because I think we can all agree
that the proposed change would not break any 8.0 series code, and
positively impact everyone.
On Jun 6, 2016 9:40 AM, "Richard Eisenberg"  wrote:

> I've been bitten by this too and had to disable the warning.
>
> Let me propose an alternative;
> * -Wredundant-constraints becomes only your Warning 1. That is, it reports
> when a user writes a constraint that is fully equivalent to some other,
> strictly smaller constraint, like suggesting simplifying (Eq a, Ord a) to
> (Ord a).
>
> * -Wtype-overly-specific takes on Warning 2, and adds the ability to catch
> any type signature that's more specific than it needs to be. (Whether or
> not to add this to -Wall is for others to decide.) This is indeed a more
> lint-like warning, but HLint would be hard-pressed to figure this one out.
>
> * We really need a way of disabling/enabling warnings per declaration. I
> propose something like this:
>
> > {-# WARNINGS foo -Wno-type-overly-specific #-}
> > foo :: Int -> Int
> > foo x = x
>
> Richard
>
> On Jun 4, 2016, at 9:11 AM, Carter Schonwald 
> wrote:
>
> Agreed.  Ive hit exactly these issues myself to the point where i err on
> suppressing that warning in my code now.  In part because i use those
> unused constraints as a semantic contract.
>
> On Friday, June 3, 2016, Adam Foltzer  wrote:
>
>> With 8.0.1 freshly arrived, I'm taking on the task of updating a number
>> of our larger projects here at Galois. I made a couple of these comments
>> briefly on a relevant Trac ticket[1], but I wanted to open this discussion
>> to a wider audience.
>>
>> We tend to use -Wall (and -Werror, in CI environments), and so I've had
>> to make decisions about how to handle the new -Wredundant-constraints
>> warnings. So far, I've come to think of it as two different warnings that
>> happen to be combined:
>>
>> Warning 1: a warning for constraints made redundant by superclass
>> relationships, and
>> Warning 2: a warning for unused constraints
>>
>> Overall I'm a fan of Warning 1. It seems very much in the spirit of other
>> warnings such as unused imports. The only stumbling block is how it affects
>> the 3-release compatibility plan with respect to, e.g., the AMP. Most of
>> our code targets a 2-release window, though, so in every such case it has
>> been fine for us to simply remove the offending constraint.
>>
>> Warning 2 on the other hand is far more dubious to me. In the best case,
>> it finds constraints that through oversight or non-local changes are truly
>> no longer necessary in the codebase. This is nice, but the much more common
>> case in our code is that we've made a deliberate decision to include that
>> constraint as part of our API design.
>>
>> The most painful example of this I've hit so far is in an API of related
>> functions, where we've put the same constraint on each function even when
>> the implementation of that particular function might not need that
>> constraint. This is good for consistency and forward-looking compatibility
>> (what if we need that constraint in the next version?). The warning's
>> advice in this case makes the API harder to understand, and less abstract
>> (the client shouldn't care or know that f needs Functor, but g doesn't, if
>> both will always be used in a Functor context).
>>
>> On another level, Warning 2 is a warning that we could have given a more
>> general type to a definition. We quite rightly don't do this for the
>> non-constraint parts of the type signatures, so why are we doing it for the
>> constraints?
>>
>> I'm happy that Warning 1 is now around, but Warning 2 feels much more
>> like an opinionated lint check, and I really wish it wasn't part of -Wall.
>>
>> [1]: https://ghc.haskell.org/trac/ghc/ticket/10635#comment:15
>>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Feedback on -Wredundant-constraints

[Carter Schonwald]

Agreed.  Ive hit exactly these issues myself to the point where i err on
suppressing that warning in my code now.  In part because i use those
unused constraints as a semantic contract.

On Friday, June 3, 2016, Adam Foltzer  wrote:

> With 8.0.1 freshly arrived, I'm taking on the task of updating a number of
> our larger projects here at Galois. I made a couple of these comments
> briefly on a relevant Trac ticket[1], but I wanted to open this discussion
> to a wider audience.
>
> We tend to use -Wall (and -Werror, in CI environments), and so I've had to
> make decisions about how to handle the new -Wredundant-constraints
> warnings. So far, I've come to think of it as two different warnings that
> happen to be combined:
>
> Warning 1: a warning for constraints made redundant by superclass
> relationships, and
> Warning 2: a warning for unused constraints
>
> Overall I'm a fan of Warning 1. It seems very much in the spirit of other
> warnings such as unused imports. The only stumbling block is how it affects
> the 3-release compatibility plan with respect to, e.g., the AMP. Most of
> our code targets a 2-release window, though, so in every such case it has
> been fine for us to simply remove the offending constraint.
>
> Warning 2 on the other hand is far more dubious to me. In the best case,
> it finds constraints that through oversight or non-local changes are truly
> no longer necessary in the codebase. This is nice, but the much more common
> case in our code is that we've made a deliberate decision to include that
> constraint as part of our API design.
>
> The most painful example of this I've hit so far is in an API of related
> functions, where we've put the same constraint on each function even when
> the implementation of that particular function might not need that
> constraint. This is good for consistency and forward-looking compatibility
> (what if we need that constraint in the next version?). The warning's
> advice in this case makes the API harder to understand, and less abstract
> (the client shouldn't care or know that f needs Functor, but g doesn't, if
> both will always be used in a Functor context).
>
> On another level, Warning 2 is a warning that we could have given a more
> general type to a definition. We quite rightly don't do this for the
> non-constraint parts of the type signatures, so why are we doing it for the
> constraints?
>
> I'm happy that Warning 1 is now around, but Warning 2 feels much more like
> an opinionated lint check, and I really wish it wasn't part of -Wall.
>
> [1]: https://ghc.haskell.org/trac/ghc/ticket/10635#comment:15
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: RFC: Removing the `-hb` profiling option

[Carter Schonwald]

What about disallowing -hb on threaded builds? That does just sort of punt
it a little bit, it a not quite satisfactory way perhaps

On Friday, May 6, 2016, Evan Laforge  wrote:

> I've used this a lot when looking for leaks.  Especially combined with
> other things like -hbdrag -hc, so I'd be sad to see it go.  Without
> it, how do you find lag and drag?
>
> On the other hand, the entire profiling system has been hard to use
> because of crashes (perhaps due to that thread-unsafety thing), but
> also because of lack of documentation, the fact that SCCs can
> drastically change the performance of the things they are trying to
> measure, and probably just personal incompetence.  But that's not
> really directly relevant to -hb, except to say I'd rather fix it than
> delete it.
>
> On Fri, May 6, 2016 at 2:04 AM, Erik de Castro Lopo
> > wrote:
> > Hi all,
> >
> > After a bit of rather tedious and frustrating debugging I came to the
> > realisation that the code for the `-hb` profiling option is not thread
> > safe. See https://ghc.haskell.org/trac/ghc/ticket/12019
> >
> > This gives us an opportunity to simply remove it instead of fixing it.
> > If there is anyone that thinks this future is really useful (ie more
> > useful than the other profiling modes) then I'm willing to fix it.
> > But if noone would miss it. I'd much rather remove it.
> >
> > Thoughts?
> >
> > Erik
> > --
> > --
> > Erik de Castro Lopo
> > http://www.mega-nerd.com/
> > ___
> > Glasgow-haskell-users mailing list
> > Glasgow-haskell-users@haskell.org 
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org 
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Looking for GHC compile-time performance tests

[Carter Schonwald]

It also helped that the test suite got added back to the main cabal. And
the test suite took a WHILE, due to some sort of coercion seize blowup that
I think was fixed in 8,0.  But yes. Definitely vector build times decayed.
Partly due to the shift to the general bundle rep, and partly due to ...
Ghc builds getting slower

On Thursday, May 5, 2016, Erik de Castro Lopo  wrote:

> Ben Gamari wrote:
>
> > So, if you would like to see your program's compilation time improve
> > in GHC 8.2, put some time into reducing it to something minimal, submit
> > it to us via a Trac ticket, and let us know in this thread.
>
> The vector package is probably a good candidate. Compling vector slowed
> down signicantly between 7.8 and 7.10, only to speed up again with 8.0.
>
> Erik
> --
> --
> Erik de Castro Lopo
> http://www.mega-nerd.com/
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org 
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: suppress warning "Defined but not used: type variable ‘x’" in GHC-8.0

[Carter Schonwald]

Have you tried _x instead?

On Saturday, January 9, 2016, Henning Thielemann <
lemm...@henning-thielemann.de> wrote:

>
> GHC-8.0 emits several new warnings of this kind:
>
>Defined but not used: type variable ‘x’
>
> for declarations like
>
>type instance Snd x y = y
>
> Enthusiastically, I started to replace unused type function arguments by
> underscores, only to find out that older GHC versions do not accept that.
> With what option can I disable this warning? Or can it be removed from
> -Wall for now?
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: cannot build 'vector' with profiling

[Carter Schonwald]

I just always set profiling to True in ~/.cabal/config and then call it a
day :)

I believe cabal or something has a notion of profiling ghc options that are
only supplied when building profiling libs, but I don't remember precisely
where they are or if they are a thing

On Thursday, June 11, 2015, Ranjit Jhala  wrote:

> Thanks Carter and Reid! (I suspect I'd copied those options from somewhere
> a long time ago when they worked...) Things seem to be building now! Thanks
> a bunch!​
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: cannot build 'vector' with profiling

[Carter Schonwald]

Remove the prof flag and it will work. GHC is trying to do dylib with
profiling
On Jun 11, 2015 11:12 AM, "Ranjit Jhala"  wrote:

> Hi Carter,
>
> OK, here's the full info (see log below), this is on an MBP,
> running ghc 7.8.3 (From ghcformac).
>
> In a new directory, I create a FRESH cabal sandbox, and then do:
>
>$ cabal install --enable-library-profiling --ghc-options="-O2 -rtsopts
> -prof -auto-all -caf-all" vector
>
> In doing so I get errors about unable to build 'primitive' because
>
> Failed to load interface for ‘GHC.Integer.Type’
> Perhaps you haven't installed the "p_dyn" libraries for package
> ‘integer-gmp’?
> Use -v to see a list of the files searched for.
>
> Googling the above takes me to
>
> https://ghc.haskell.org/trac/ghc/ticket/8677
>
> But unfortunately I can't from the above tell exactly how to proceed.
>
> 1. Can you tell me how to get a profiling version of vector built in
>a new sandbox? i.e. what options are you using?
>
> 2. Is there any other information you need? I'm assuming since its in
>a sandbox I needn't nuke my global cabal directory but happy to if
>needed.
>
> Thanks! (log below)
>
> -- Ranjit.
>
> rjhala@borscht ~/r/l/tmp> mkdir vector-build
> rjhala@borscht ~/r/l/tmp> cd vector-build/
> rjhala@borscht ~/r/l/t/vector-build> cabal sandbox init
> Writing a default package environment file to
> /Users/rjhala/research/liquid/tmp/vector-build/cabal.sandbox.config
> Creating a new sandbox at
> /Users/rjhala/research/liquid/tmp/vector-build/.cabal-sandbox
> rjhala@borscht ~/r/l/t/vector-build> cabal install
> --enable-library-profiling --ghc-options="-O2 -rtsopts -prof -auto-all
> -caf-all" vector
> Resolving dependencies...
> Notice: installing into a sandbox located at
> /Users/rjhala/research/liquid/tmp/vector-build/.cabal-sandbox
> Configuring primitive-0.6...
> Building primitive-0.6...
> Failed to install primitive-0.6
> Last 10 lines of the build log (
> /Users/rjhala/research/liquid/tmp/vector-build/.cabal-sandbox/logs/primitive-0.6.log
> ):
> Configuring primitive-0.6...
> Building primitive-0.6...
> Preprocessing library primitive-0.6...
> [ 1 of 10] Compiling Data.Primitive.Internal.Compat (
> Data/Primitive/Internal/Compat.hs,
> dist/dist-sandbox-34ea82/build/Data/Primitive/Internal/Compat.o )
>
> Top level:
> Failed to load interface for ‘GHC.Integer.Type’
> Perhaps you haven't installed the "p_dyn" libraries for package
> ‘integer-gmp’?
> Use -v to see a list of the files searched for.
> cabal: Error: some packages failed to install:
> primitive-0.6 failed during the building phase. The exception was:
> ExitFailure 1
> vector-0.10.12.3 depends on primitive-0.6 which failed to install.
> rjhala@borscht ~/r/l/t/vector-build [1]> which ghc
> /Applications/ghc-7.8.3.app/Contents/bin/ghc
>
>
>
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: cannot build 'vector' with profiling

[Carter Schonwald]

Please share the exact way you're doing things.

Vector does build fine as a static profiled lib on Mac, so the challege
lies in understanding where your local configuration is broken. Please
share more info. Or reinstall stuff
On Jun 11, 2015 12:51 AM, "Ranjit Jhala"  wrote:

> ​Hi Carter,
>
> Are you referring to the '--disable-shared' flag?
>
> If so -- I added it because otherwise I got a bunch
> of errors about:
>
> Perhaps you haven't installed the "p_dyn"
> ​​
> libraries for package ‛integer-gmp’
>
> Or were you referring to some other flag?
>
> Thanks!
>
> Ranjit.
>
>
>
> On Wed, Jun 10, 2015 at 9:41 PM, Carter Schonwald <
> carter.schonw...@gmail.com> wrote:
>
>> why were you trying to build profiling dylibs? i thought we only support
>> static linked profiling libs? (i could be wrong though)
>>
>> On Wed, Jun 10, 2015 at 9:26 AM, Ranjit Jhala  wrote:
>>
>>> ah, my bad I thought I'd included that -- this is ghc 7.8.3, on MacOS,
>>> installed from https://ghcformacosx.github.io ...
>>>
>>> Should I just move to 7.10?
>>>
>>> On Wed, Jun 10, 2015 at 4:59 AM, Carter Schonwald <
>>> carter.schonw...@gmail.com> wrote:
>>>
>>>> What ghc version and how was it built?
>>>>
>>>>
>>>> On Wednesday, June 10, 2015, Ranjit Jhala  wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I cannot build 'vector' (or 'cmdargs') with profiling on.
>>>>>
>>>>> specifically when I run:
>>>>>
>>>>> $ cabal install --enable-executable-profiling
>>>>> --enable-library-profiling --ghc-options="-O2 -rtsopts -prof -auto-all
>>>>> -caf-all" vector
>>>>>
>>>>>
>>>>> I get the message:
>>>>>
>>>>> Perhaps you haven't installed the "p_dyn" libraries for package
>>>>> ‛integer-gmp’
>>>>>
>>>>> https://ghc.haskell.org/trac/ghc/ticket/8677
>>>>>
>>>>> Per some advice I tried to add the '--disable-shared'
>>>>>
>>>>>
>>>>> $ cabal install --disable-shared --enable-executable-profiling
>>>>> --enable-library-profiling --ghc-options="-O2 -rtsopts -prof -auto-all
>>>>> -caf-all" vector
>>>>>
>>>>> but then I get this:
>>>>>
>>>>> Loading package primitive-0.6 ... : can't load
>>>>> .so/.DLL for: libHSprimitive-0.6.dylib (dlopen(libHSprimitive-0.6.dylib,
>>>>> 9): image not found)
>>>>>
>>>>>
>>>>> Any idea whats going on or for any work arounds? Pretty stumped!
>>>>> Thanks in advance!
>>>>>
>>>>> Ranjit.
>>>>>
>>>>
>>>
>>>
>>> --
>>> Ranjit.
>>>
>>
>>
>
>
> --
> Ranjit.
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: cannot build 'vector' with profiling

[Carter Schonwald]

why were you trying to build profiling dylibs? i thought we only support
static linked profiling libs? (i could be wrong though)

On Wed, Jun 10, 2015 at 9:26 AM, Ranjit Jhala  wrote:

> ah, my bad I thought I'd included that -- this is ghc 7.8.3, on MacOS,
> installed from https://ghcformacosx.github.io ...
>
> Should I just move to 7.10?
>
> On Wed, Jun 10, 2015 at 4:59 AM, Carter Schonwald <
> carter.schonw...@gmail.com> wrote:
>
>> What ghc version and how was it built?
>>
>>
>> On Wednesday, June 10, 2015, Ranjit Jhala  wrote:
>>
>>> Hi all,
>>>
>>> I cannot build 'vector' (or 'cmdargs') with profiling on.
>>>
>>> specifically when I run:
>>>
>>> $ cabal install --enable-executable-profiling
>>> --enable-library-profiling --ghc-options="-O2 -rtsopts -prof -auto-all
>>> -caf-all" vector
>>>
>>>
>>> I get the message:
>>>
>>> Perhaps you haven't installed the "p_dyn" libraries for package
>>> ‛integer-gmp’
>>>
>>> https://ghc.haskell.org/trac/ghc/ticket/8677
>>>
>>> Per some advice I tried to add the '--disable-shared'
>>>
>>>
>>> $ cabal install --disable-shared --enable-executable-profiling
>>> --enable-library-profiling --ghc-options="-O2 -rtsopts -prof -auto-all
>>> -caf-all" vector
>>>
>>> but then I get this:
>>>
>>> Loading package primitive-0.6 ... : can't load
>>> .so/.DLL for: libHSprimitive-0.6.dylib (dlopen(libHSprimitive-0.6.dylib,
>>> 9): image not found)
>>>
>>>
>>> Any idea whats going on or for any work arounds? Pretty stumped! Thanks
>>> in advance!
>>>
>>> Ranjit.
>>>
>>
>
>
> --
> Ranjit.
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: cannot build 'vector' with profiling

[Carter Schonwald]

What ghc version and how was it built?

On Wednesday, June 10, 2015, Ranjit Jhala  wrote:

> Hi all,
>
> I cannot build 'vector' (or 'cmdargs') with profiling on.
>
> specifically when I run:
>
> $ cabal install --enable-executable-profiling
> --enable-library-profiling --ghc-options="-O2 -rtsopts -prof -auto-all
> -caf-all" vector
>
>
> I get the message:
>
> Perhaps you haven't installed the "p_dyn" libraries for package
> ‛integer-gmp’
>
> https://ghc.haskell.org/trac/ghc/ticket/8677
>
> Per some advice I tried to add the '--disable-shared'
>
>
> $ cabal install --disable-shared --enable-executable-profiling
> --enable-library-profiling --ghc-options="-O2 -rtsopts -prof -auto-all
> -caf-all" vector
>
> but then I get this:
>
> Loading package primitive-0.6 ... : can't load .so/.DLL
> for: libHSprimitive-0.6.dylib (dlopen(libHSprimitive-0.6.dylib, 9): image
> not found)
>
>
> Any idea whats going on or for any work arounds? Pretty stumped! Thanks in
> advance!
>
> Ranjit.
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: ghc 7.10.1 hard lock on exit with shake, OS X 10.10

[Carter Schonwald]

could you share a minimal program that reproduces the problem?

On Tue, Jun 2, 2015 at 9:36 PM, Evan Laforge  wrote:

> After I upgraded to 7.10.1 I started noticing that my shakefile would
> lock up on exit.  It's after the 'main' function exits, and none of
> the shake tests have a problem, so presumably it's a GHC thing, that
> shake somehow causes to happen.  Only kill -9 gets it to quit.  Here's
> a stack trace from the OS X sampler:
>
> Call graph:
> 2801 Thread_909901   DispatchQueue_2:
> com.apple.libdispatch-manager  (serial)
>   2801 _dispatch_mgr_thread  (in libdispatch.dylib) + 52
> [0x7fff8828ca6a]
> 2801 kevent64  (in libsystem_kernel.dylib) + 10  [0x7fff90ec0232]
>
> Total number in stack (recursive counted multiple, when >=5):
>
> Sort by top of stack, same collapsed (when >= 5):
> kevent64  (in libsystem_kernel.dylib)2801
>
>
> I know there aren't a lot of details here, but does this sound
> familiar to anyone?  I can't see anything on
> https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.2 that looks
> like this.  Is there any way I can get more information I can get to
> report this?
>
> It used to be frequent (once in 10 runs maybe), but later became quite
> infrequent (once in a couple hundred runs, maybe).  I downgraded to
> 7.8.4 and it hasn't happened again.
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: RFC: "Native -XCPP" Proposal

[Carter Schonwald]

To clarify my point more concretely:

Adding cpphs the cli tool to ghc build process / bin dist has no more
licensing implications than does using gcc as a compiler / assembler. Ie
NONE

Using cpphs as a library is Another discussion. But I don't think it's the
one we're having today.



On Friday, May 8, 2015, Carter Schonwald  wrote:

> Indeed. This is also how we use gcc and the llvm tooling.
>
> If we want the cpp tooling to be available as a library, that's a whole
> nother set of needs.
>
> Gmp lgpl I can brush under the rug at work because there's the various
> integer simple options, this gets a bit more squirrelly otherwise.
>
> Maybe it'd be simpler for two people to sit down for a weekend, one only
> narrating the cpphs code, the other only listening and paraphrasing it into
> a new program.  Copyright on text only covers literal copying.  Nontrivial
> rephrasing of everything plus some rejiggering of non local structure is
> not prevented by copyright law, and I doubt there are any patents in play.
>
>
>
> On Friday, May 8, 2015, Mathieu Boespflug  > wrote:
>
>> [Gah, wrong From: email address given the list subscriptions, sorry
>> for the duplicates.]
>>
>> I'm unclear why cpphs needs to be made a dependency of the GHC API and
>> included as a lib. Could you elaborate? (in the wiki page possibly)
>>
>> Currently, GHC uses the system preprocessor, as a separate process.
>> Couldn't we for GHC 7.12 keep to exactly that, save for the fact that
>> by default GHC would call the cpphs binary for preprocessing, and have
>> the cpphs binary be available in GHC's install dir somewhere?
>>
>> fork()/execvce() is cheap. Certainly cheaper than the cost of
>> compiling a single Haskell module. Can't we keep to this
>> separate-(and-pluggable)-preprocessor-executable scheme? We'd sidestep
>> most license tainting concerns that way.
>>
>>
>> On 8 May 2015 at 11:39, Herbert Valerio Riedel 
>> wrote:
>> > Hello,
>> >
>> > On 2015-05-08 at 11:28:08 +0200, Niklas Larsson wrote:
>> >> If the intention is to use cpphs as a library, won't the license
>> >> affect every program built with the GHC API? That seems to be a high
>> >> price to pay.
>> >
>> > Yes, every program linking the `ghc` package would be affected by
>> > LGPL+SLE albeit in a contained way, as it's mentioned on the Wiki page:
>> >
>> > | - As a practical consequence of the //LGPL with
>> static-linking-exception//
>> > |   (LGPL+SLE), **if no modifications are made to the `cpphs`-parts**
>> > |   (i.e. the LGPL+SLE covered modules) of the GHC code-base,
>> > |   **then there is no requirement to ship (or make available) any
>> source code**
>> > |   together with the binaries, even if other parts of the GHC code-base
>> > |   were modified.
>> >
>> > However, don't forget we already have this issue w/ integer-gmp, and
>> > with that the LGPL is in full effect (i.e. w/o a
>> static-linkage-exception!)
>> >
>> > In that context, the suggestion was made[1] to handle the cpphs-code
>> > like the GMP code, i.e. allow a compile-time configuration in the GHC
>> > build-system to build a cpphs-free (and/or GMP-free) GHC for those
>> > parties that need to avoid any LGPL-ish code whatsoever in their
>> > toolchain.
>> >
>> > Would that address this concern?
>> >
>> >
>> >  [1]:
>> http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1cdhb
>> > ___
>> > Haskell-Cafe mailing list
>> > haskell-c...@haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> ___
>> ghc-devs mailing list
>> ghc-d...@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: RFC: "Native -XCPP" Proposal

[Carter Schonwald]

Indeed. This is also how we use gcc and the llvm tooling.

If we want the cpp tooling to be available as a library, that's a whole
nother set of needs.

Gmp lgpl I can brush under the rug at work because there's the various
integer simple options, this gets a bit more squirrelly otherwise.

Maybe it'd be simpler for two people to sit down for a weekend, one only
narrating the cpphs code, the other only listening and paraphrasing it into
a new program.  Copyright on text only covers literal copying.  Nontrivial
rephrasing of everything plus some rejiggering of non local structure is
not prevented by copyright law, and I doubt there are any patents in play.



On Friday, May 8, 2015, Mathieu Boespflug  wrote:

> [Gah, wrong From: email address given the list subscriptions, sorry
> for the duplicates.]
>
> I'm unclear why cpphs needs to be made a dependency of the GHC API and
> included as a lib. Could you elaborate? (in the wiki page possibly)
>
> Currently, GHC uses the system preprocessor, as a separate process.
> Couldn't we for GHC 7.12 keep to exactly that, save for the fact that
> by default GHC would call the cpphs binary for preprocessing, and have
> the cpphs binary be available in GHC's install dir somewhere?
>
> fork()/execvce() is cheap. Certainly cheaper than the cost of
> compiling a single Haskell module. Can't we keep to this
> separate-(and-pluggable)-preprocessor-executable scheme? We'd sidestep
> most license tainting concerns that way.
>
>
> On 8 May 2015 at 11:39, Herbert Valerio Riedel  > wrote:
> > Hello,
> >
> > On 2015-05-08 at 11:28:08 +0200, Niklas Larsson wrote:
> >> If the intention is to use cpphs as a library, won't the license
> >> affect every program built with the GHC API? That seems to be a high
> >> price to pay.
> >
> > Yes, every program linking the `ghc` package would be affected by
> > LGPL+SLE albeit in a contained way, as it's mentioned on the Wiki page:
> >
> > | - As a practical consequence of the //LGPL with
> static-linking-exception//
> > |   (LGPL+SLE), **if no modifications are made to the `cpphs`-parts**
> > |   (i.e. the LGPL+SLE covered modules) of the GHC code-base,
> > |   **then there is no requirement to ship (or make available) any
> source code**
> > |   together with the binaries, even if other parts of the GHC code-base
> > |   were modified.
> >
> > However, don't forget we already have this issue w/ integer-gmp, and
> > with that the LGPL is in full effect (i.e. w/o a
> static-linkage-exception!)
> >
> > In that context, the suggestion was made[1] to handle the cpphs-code
> > like the GMP code, i.e. allow a compile-time configuration in the GHC
> > build-system to build a cpphs-free (and/or GMP-free) GHC for those
> > parties that need to avoid any LGPL-ish code whatsoever in their
> > toolchain.
> >
> > Would that address this concern?
> >
> >
> >  [1]:
> http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1cdhb
> > ___
> > Haskell-Cafe mailing list
> > haskell-c...@haskell.org 
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> ___
> ghc-devs mailing list
> ghc-d...@haskell.org 
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Increased memory usage with GHC 7.10.1

[Carter Schonwald]

as a near term mitigation, could you enable having swap files on your VM ?

On Fri, May 1, 2015 at 5:00 AM, Paolino  wrote:

> Ghc trac is not sending the verification emails and won't let me file a
> bug without. As soon as this gets fixed I will.
>
> Thanks
>
> paolino
>
> 2015-05-01 10:44 GMT+02:00 Simon Peyton Jones :
>
>>  Can you open a ticket, please? And put as much data as you can.  Using
>> `-dshow-passes` (both for 7.10 and prior versions) and showing the output
>> would be helpful.
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* Glasgow-haskell-users [mailto:
>> glasgow-haskell-users-boun...@haskell.org] *On Behalf Of *Paolino
>> *Sent:* 01 May 2015 09:42
>> *To:* glasgow-haskell-users@haskell.org
>> *Subject:* Re: Increased memory usage with GHC 7.10.1
>>
>>
>>
>> Hello, I'm using ghc 7.10.1 to compile OpenGLRaw which is now impossible
>> with -O1 and -O2 due to "ghc : out of memory error" on a 4GB linux host.
>> The file making memory explode is
>> Graphics.Rendering.OpenGL.Raw.Functions
>> .
>> With -O0 it uses 600 MB.
>>
>> The file is really huge, but I could compile it with prior versions of
>> ghc.
>>
>> Regards
>>
>> paolino
>>
>>
>>
>> 2015-04-17 1:33 GMT+02:00 David Laing :
>>
>>   Hi all,
>>
>> I've been playing around with profiling GHC recently, so I thought I'd
>> chime in with a pointer that might save people searching for the right docs
>> - you could configure a cabal sandbox to work with multiple version of ghc,
>> which I've found useful:
>>
>>
>> https://www.haskell.org/cabal/users-guide/installing-packages.html#sandboxes-advanced-usage
>>
>>
>> Cheers,
>>
>>
>>
>> Dave
>>
>>
>>
>> On Fri, Apr 17, 2015 at 6:01 AM, Michal Terepeta <
>> michal.terep...@gmail.com> wrote:
>>
>>  Hi Richard,
>>
>> Thanks updating the ticket! What I did was: build GHC HEAD/7.8.4 with
>> build flavor 'prof' then get the haskell-src-exts sources, install the
>> dependencies and finally add +RTS -p -RTS to the cabal file and compile it,
>> the resulting ghc.prof contains the profiling information.
>>
>>
>>
>> For anyone interested about CallArity slowness, the problem is tracked in
>> https://ghc.haskell.org/trac/ghc/ticket/10293
>>
>>
>>
>> Cheers,
>>
>> Michal
>>
>>
>>
>> On Wed, Apr 15, 2015 at 1:40 AM Richard Eisenberg 
>> wrote:
>>
>>  I've pasted Michal's numbers in #9630, which seems like a good place to
>> track this. Michal, would you mind fleshing out a bit precisely what you
>> did to get those numbers? That would be helpful (though you've already been
>> very helpful indeed in getting the data together)!
>>
>> Thanks,
>> Richard
>>
>> On Apr 14, 2015, at 9:09 PM, Joachim Breitner 
>> wrote:
>>
>> > Hi,
>> >
>> > Am Dienstag, den 14.04.2015, 21:54 +0200 schrieb Michal Terepeta:
>> >> On Mon, Apr 13, 2015 at 10:34 PM, Christiaan Baaij
>> >>  wrote:
>> >>> Actually, I meant only with -fno-specialise.
>> >>
>> >> Done. Helps quite a bit but CallArity is still a pretty expensive.
>> >
>> > I’m on that, and I think I have a quite neat fix for it. I’ll report on
>> > that in the trac ticket:
>> > https://ghc.haskell.org/trac/ghc/ticket/10293#comment:4
>> >
>> > Greetings,
>> > Joachim
>> >
>> > --
>> > Joachim “nomeata” Breitner
>> >  m...@joachim-breitner.de • http://www.joachim-breitner.de/
>> >  Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
>> >  Debian Developer: nome...@debian.org
>> > ___
>> > Glasgow-haskell-users mailing list
>> > Glasgow-haskell-users@haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>
>>
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>
>>
>>
>>
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>
>>
>>
>
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: SIMD

[Carter Schonwald]

indeed, dont use it. the current design is only -fllvm, and the choice in
api is exactly the wrong one for those who actually want to use SIMD
correctly

 If you want to use Simd today, write C code and ffi call it!
https://github.com/wellposed/vector-vectorized is an example effort I did
nearly 2 years ago


On Sat, Apr 11, 2015 at 1:28 PM, David Feuer  wrote:

> Last I heard, it was extremely experimental and somewhat broken. Carter
> was working on some of the worst problems, but he's been kind of busy.
>
> On Sat, Apr 11, 2015 at 12:44 PM, Dominic Steinitz 
> wrote:
>
>> What’s the story with this? I tried to follow the instructions here:
>> https://ghc.haskell.org/trac/ghc/wiki/SIMD but I get
>>
>> ~ $ git clone -b simd http://git.haskell.org/ghc.git
>> Cloning into 'ghc'...
>> fatal: Remote branch simd not found in upstream origin
>>
>>
>> Dominic Steinitz
>> domi...@steinitz.org
>> http://idontgetoutmuch.wordpress.com
>>
>>
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>
>>
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Binary bloat in 7.10

[Carter Schonwald]

Great sleuthing!! Thanks for pinning down whats going on!
On Apr 2, 2015 8:48 PM, "Thomas Miedema"  wrote:

> Jeremy,
>
> On Thu, Apr 2, 2015 at 2:12 PM, Thomas Miedema 
> wrote:
>
>> Maybe `split-objs` is not applied?
>>
>
> That suggestion was completely misguided. Compiling with `-split-objs`
> makes a library _grow_ in size, but makes executables that link against it
> _smaller_.
>
> Size of `libHSCabal-1.22.2.0` obtained by running `cabal install
> Cabal==1.22.2.0 --with-ghc=ghc-x.x.x (--enable-split-objs)`, on 64bit
> Ubuntu:
>
> default   --enable-split-objs
> 7.8.4:  19Mb  46Mb
> 7.10.1: 21Mb  52Mb
>
> So the 7.10 versions are indeed somewhat larger, but I wouldn't call it
> ballooned or bloated. Note that a ghc build compiles the libraries with
> -O2 , which increases the binary size another 5% or so.
>
> All these numbers are not far off from the ones you were getting. I think
> you have been comparing a 7.8.4 build of Cabal without split objects, with
> a 7.10.1 build of Cabal with split objects.
>
> I don't think there is a bug here.
>
> -Thomas
>
>
> P.S. To show that binary sizes not only grow with new ghc releases, here
> is the same experiment with random:
>
> `cabal install random==1.0.1.1 --with-ghc=ghc-x.x.x (--enable-split-objs)`
>
> default  --enable-split-objs
> 7.0.4:  0.94M1.9M
> 7.2.2:  1.1M 2.1M
> 7.4.2:  0.86M1.8M
> 7.6.3:  0.85M1.8M
> 7.8.4:  0.76M1.7M
> 7.10.1: 0.69M1.6M
>
>
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Binary bloat in 7.10

[Carter Schonwald]

Woops, never mind.
On Apr 2, 2015 7:53 AM, "Carter Schonwald" 
wrote:

> Do you have profiling enabled locally?
> On Apr 2, 2015 5:19 AM, "Jeremy"  wrote:
>
>> Very strange. If I download Cabal from hackage and build it with 'cabal
>> build' the bloat disappears.
>>
>> cabal build:
>>
>> 18M HSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.o
>> 21M libHSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.a
>>
>> /usr/local/lib/ghc-7.10.1:
>>
>> 23M HSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.o
>> 53M libHSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.a
>>
>> This is my build.mk:
>>
>> SRC_HC_OPTS = -O -H64m
>> GhcRTSWays = thr
>> HADDOCK_DOCS = NO
>> GhcHcOpts =
>> GhcLibWays = v
>> DYNAMIC_GHC_PROGRAMS = NO
>>
>> This is the same as I used for 7.8 without issue, except the addition of
>> GhcHcOpts (because 7.8 ignored the default).
>>
>>
>>
>> --
>> View this message in context:
>> http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768133.html
>> Sent from the Haskell - Glasgow-haskell-users mailing list archive at
>> Nabble.com.
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Binary bloat in 7.10

[Carter Schonwald]

Do you have profiling enabled locally?
On Apr 2, 2015 5:19 AM, "Jeremy"  wrote:

> Very strange. If I download Cabal from hackage and build it with 'cabal
> build' the bloat disappears.
>
> cabal build:
>
> 18M HSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.o
> 21M libHSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.a
>
> /usr/local/lib/ghc-7.10.1:
>
> 23M HSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.o
> 53M libHSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.a
>
> This is my build.mk:
>
> SRC_HC_OPTS = -O -H64m
> GhcRTSWays = thr
> HADDOCK_DOCS = NO
> GhcHcOpts =
> GhcLibWays = v
> DYNAMIC_GHC_PROGRAMS = NO
>
> This is the same as I used for 7.8 without issue, except the addition of
> GhcHcOpts (because 7.8 ignored the default).
>
>
>
> --
> View this message in context:
> http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768133.html
> Sent from the Haskell - Glasgow-haskell-users mailing list archive at
> Nabble.com.
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Binary bloat in 7.10

[Carter Schonwald]

Mind you I'm just trying to come up with theories we can test, I'm not
assigning blame.  :)

I'm not sure how to do the apples to apples comparison, but it sounds like
some sleuthing Is In order.

I dont have a 7.10 setup yet, but if someone can put a tarballed dist build
folder for a 7.10 and the same for 7.8 for some lib that blows up,I'm happy
to try to dig i n.  Or I'll get things setup later this week to do the full
comparison locally.
On Apr 1, 2015 11:12 AM, "Edward Z. Yang"  wrote:

> Yes, this does seem like a potential culprit, although
> we did do some measurements and I didn't think it was too bad.
> Maybe we were wrong!
>
> Edward
>
> Excerpts from Jeremy's message of 2015-04-01 07:26:55 -0700:
> > Carter Schonwald wrote
> > > How much of this might be attributable to longer linker symbol names?
> Ghc
> > > 7.10 object  code does have larger symbols!  Is there a way to easily
> > > tabulate that?
> >
> > That would explain why the hi files have also increased many-fold. Is
> there
> > any way to avoid the larger symbols?
> >
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Binary bloat in 7.10

[Carter Schonwald]

How much of this might be attributable to longer linker symbol names? Ghc
7.10 object  code does have larger symbols!  Is there a way to easily
tabulate that?
On Apr 1, 2015 9:40 AM, "Jeremy"  wrote:

> Roman Cheplyaka-2 wrote
> > I'm not denying (or confirming) your claim, but it would look more
> > legitimate if you compared the same version of Cabal compiled with
> > different versions of GHC.
> >
> > At least some of this bloat could be because Cabal simply gained more
> > code.
>
> I was going to prove you wrong by identifying packages which have barely
> changed for 7.10 ... and found that those packages were a similar size to
> their 7.8 versions.
>
> However, the size increase in other packages is huge, and "simply gained
> more code" doesn't seem like an adequate explanation, with some package
> more
> than doubling.
>
> Here are the full results:
>
> 7.8:
>
> 34M Cabal-1.18.1.5
> 3.8Marray-0.5.0.0
> 50M base-4.7.0.2
> 52M bin
> 368Kbin-package-db-0.0.0.0
> 2.7Mbinary-0.7.1.0
> 5.4Mbytestring-0.10.4.0
> 9.4Mcontainers-0.5.5.1
> 196Kdeepseq-1.3.0.2
> 608Kdirectory-1.2.1.0
> 740Kfilepath-1.3.0.2
> 105Mghc-7.8.4
> 2.7Mghc-prim-0.3.1.0
> 8.7Mhaskeline-0.7.1.2
> 3.4Mhoopl-3.10.0.1
> 1020K   hpc-0.6.0.1
> 556Kinteger-gmp-0.5.1.0
> 680Kpretty-1.1.1.1
> 684Kprocess-1.2.0.0
> 1.6Mrts-1.0
> 13M template-haskell-2.9.0.0
> 1.4Mterminfo-0.4.0.0
> 6.1Mtime-1.4.2
> 4.4Mtransformers-0.3.0.0
> 5.2Munix-2.7.0.1
>
> 7.10:
>
> 83M Cabal_HWT8QvVfJLn2ubvobpycJY
> 3.7Marray_FaHmcBFfuRM8kmZLEY8D5S
> 52M base_I5BErHzyOm07EBNpKBEeUv
> 56M bin
> 2.9Mbinar_EKE3c9Lmxb3DQpU0fPtru6
> 832Kbinpa_JNoexmBMuO8C771QaIy3YN
> 5.7Mbytes_6vj5EoliHgNHISHCVCb069
> 11M conta_47ajk3tbda43DFWyeF3oHQ
> 432Kdeeps_FpR4obOZALU1lutWnrBldi
> 912Kdirec_3TcTyYedch32o1zTH2MR00
> 796Kfilep_5HhyRonfEZoDO205Wm9E4h
> 113Mghc_EMlWrQ42XY0BNVbSrKixqY
> 2.9Mghcpr_8TmvWUcS1U1IKHT0levwg3
> 8.9Mhaske_IlDhIe25uAn0WJY379Nu1M
> 3.4Mhoopl_JxODiSRz1e84NbH6nnZuUk
> 1.1Mhpc_CmUUQl5bURfBueJrdYfNs3
> 1.3Minteg_2aU3IZNMF9a7mQ0OzsZ0dS
> 1.8Mprett_7jIfj8VCGFf1WS0tIQ1XSZ
> 764Kproce_0hwN3CTKynhHQqQkChnSdH
> 1.7Mrts
> 19M templ_BVMCZyLwIlfGfcqqzyUAI8
> 1.4Mtermi_7qZwBlx3clR8sTBilJl253
> 6.2Mtime_Hh2clZW6in4HpYHx5bLtb7
> 7.3Mtrans_ALYlebOVzVI4kxbFX5SGhm
> 5.4Munix_G4Yo1pNtYrk8nCq1cx8P9d
>
>
>
>
> --
> View this message in context:
> http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768083.html
> Sent from the Haskell - Glasgow-haskell-users mailing list archive at
> Nabble.com.
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] PowerPC variants (GHC 7.8.3)

[Carter Schonwald]

Hey Jon, I do know that some of the GHC dev team is probably best equipped
to answer your question, i'm cc'ing the ghc dev and users lists so they can
jump in and help!
-Carter

On Wed, Feb 25, 2015 at 7:11 AM, Jon Schneider 
wrote:

> Good morning,
>
> We have a product with an MPC8544E we might want to target. Also known as
> PowerQUICC and e500v2. The ABI is gnuspe rather than gnueabi.
>
> I have built a powerpc---ghc cross compiler but the thing stopping "hello
> world" is a SIGILL happening in StgCRun.c where the stfd and lfd
> instructions are used to stash registers. The e500 has different
> instructions but that cannot be dropped in trivially because of offset
> encoding Commenting these out fixes "hello world" though this surely only
> scratches the surface of what would need doing.
>
> I notice that whereas ARMv5, v6 and v7 appear to be catered for along with
> various knobs and whistles there appears to be no such thing for PowerPC.
>
> Is anybody else out there working on this area ?
>
> Jon
>
> ___
> Haskell-Cafe mailing list
> haskell-c...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal: ValidateMonoLiterals - Initial bikeshed discussion

[Carter Schonwald]

Its worth pointing out that when / if luites out of process TH design
happens for ghc, TH will be usable in cross compile builds of ghc as well.
So we shouldn't let that constraint we have for now dictate future tooling
ideas.
On Feb 6, 2015 3:50 PM, "Evan Laforge"  wrote:

> Would it be feasible to make a lighter-weight mode for quasiquotes
> that doesn't require the whole "load the module in ghci" runaround?
> If it didn't need to do that, there wouldn't be much downside to
> turning it on everywhere.  And it would enable lots of QQ conveniences
> that at least I don't think its worth enabling TH for, due to the ghci
> hassle.
>
> Greg Weber recently asked for input on the idea of restricted TH
> modes, this seems related.
>
> If a splice was pure and had no non-Prelude dependencies, could it be
> run without ghci loading and stage restrictions?
>
> I think it's really awkward how numeric literals use fromInteger and
> fromRational, and those functions are grouped into Num and Fractional.
> So if you want to use (+), you also have to accept literals, which
> means you have to accept anything anyone might type.  Has there been
> any kind of proposal to split fromInteger and fromRational into their
> own typeclasses analogous to IsString?
>
> On Fri, Feb 6, 2015 at 9:24 AM, Dan Doel  wrote:
> > Assuming a separate syntax, I believe that the criterion would be as
> simple
> > as ensuring that no ValidateFoo constraints are left outstanding. The
> syntax
> > would add the relevant validate call, and type variables involved in a
> > ValidateFoo constraint would not be generalizable, and would have to be
> > defaulted or inferred from elsewhere, similar to the monomorphism
> > restriction. I'm not sure how difficult that would be to implement.
> >
> > I'm not terribly gung ho on this, though. It feels very ad hoc. Making
> > validation vs. non-validation syntactic rather than just based on
> > polymorphism seems somewhat less so, though; so I'd prefer that
> direction.
> > Finding unused syntax is always a problem, of course.
> >
> > On Fri, Feb 6, 2015 at 11:38 AM, Ryan Trinkle 
> > wrote:
> >>
> >> My greatest concern here would be that, as an application is
> maintained, a
> >> literal might go from monomorphic to polymorphic, or vice versa, without
> >> anybody noticing.  It sounds like this could result in a value silently
> >> becoming partial, which would be a big problem for application
> stability; in
> >> the opposite case - a partial value becoming a compile-time error - I am
> >> somewhat less concerned, but it could still be confusing and disruptive.
> >>
> >> I would prefer that there be some syntactic indication that I want my
> >> literal to be checked at compile time.  This syntax could also add
> whatever
> >> monomorphism requirement is needed, and then it would become a
> compile-time
> >> error for the value to become polymorphic.  I don't know nearly enough
> about
> >> the type system to know whether this is possible.
> >>
> >> Also, it seems to me that it might not be so clean as "monomorphic"
> versus
> >> "polymorphic".  For example, suppose I have this:
> >>
> >> newtype PostgresTableName s = PostgresTableName String
> >>
> >> where 's' is a phantom type representing the DB schema that the name
> lives
> >> in.  The validation function is independent of the schema - it simply
> fails
> >> if there are illegal characters in the name, or if the name is too long.
> >> So, ideally, ("foo\0bar" :: forall s. PostgresTableName s) would fail at
> >> compile time, despite being polymorphic.
> >>
> >>
> >> Ryan
> >>
> >> On Fri, Feb 6, 2015 at 11:16 AM, Merijn Verstraaten
> >>  wrote:
> >>>
> >>> Ryan,
> >>>
> >>> Unfortunately, yes, you are understanding that correctly.
> >>>
> >>> The reason I qualified it with "monomorphic only" is that, I want to
> >>> avoid breakage that would render the extension practically unusable in
> real
> >>> code.
> >>>
> >>> Let's say I right now have:
> >>>
> >>> foo :: Num a => [a] -> [a]
> >>> foo = map (+1)
> >>>
> >>> I have two options 1) we compile this as currently using fromIntegral
> and
> >>> it WILL break for Even or 2) we reject any polymorphic use of literals
> like
> >>> this. Given the amount of numerical code relying on the polymorphism
> of Num,
> >>> I think the option of not being able to compile Num polymorphic code is
> >>> completely out of the question. Almost no application  would work.
> >>>
> >>> I would advocate in favour of not requiring an IsList/IsString instance
> >>> for the validation class, this would allow you to write a conversion
> that
> >>> ONLY converts literals in a validated way and will never successfully
> >>> convert literals without the extension, since with the extension
> disabled
> >>> GHC would try to use the fromList/fromString from the IsString/IsList
> >>> classes which do not exist.
> >>>
> >>> Unfortunately, given how deeply fromIntegral is tied to the Num class I
> >>> don't see any way to achieve the same

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 2

[Carter Schonwald]

George, what version of llvm are you using? afaik, only llvm 3.5 is
supported for 7.10 (though I could be wrong)

On Tue, Jan 27, 2015 at 8:39 PM, George Colpitts 
wrote:

> Has anybody successfully build and used this on the Mac on 10.10 using the
> latest XCode? While it is better than RC1 I am still seeing the following
> two issues:
>
>
>- programs compiled with llvm fail at runtime with illegal instruction
>- calling main from the ghci inerpreter after loading compiled code
>results in
>- Prelude Main> main
>   Too late for parseStaticFlags: call it before runGhc or runGhcT
>   *** Exception: ExitFailure 1
>
> Instead of solving the above, I'd be happy to switch to a Mac OS bindist
> and see if I have the same problems there. Do we have an ETA for a Mac OS
> bindist?
>
>
> Thanks
>
> George
>
>
> On Mon, Jan 26, 2015 at 8:13 PM, Austin Seipp 
> wrote:
>
>> We are pleased to announce the second release candidate for GHC 7.10.1:
>>
>> https://downloads.haskell.org/~ghc/7.10.1-rc2/
>>
>> This includes the source tarball and bindists for 64bit/32bit Linux
>> and Windows. Binary builds for other platforms will be available
>> shortly. (CentOS 6.5 binaries are not available at this time like they
>> were for 7.8.x). These binaries and tarballs have an accompanying
>> SHA256SUMS file signed by my GPG key id (0x3B58D86F).
>>
>> We plan to make the 7.10.1 release sometime in February of 2015.
>>
>> Please test as much as possible; bugs are much cheaper if we find them
>> before the release!
>>
>> --
>> Regards,
>>
>> Austin Seipp, Haskell Consultant
>> Well-Typed LLP, http://www.well-typed.com/
>> ___
>> ghc-devs mailing list
>> ghc-d...@haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
>
> ___
> ghc-devs mailing list
> ghc-d...@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Thread behavior in 7.8.3

[Carter Schonwald]

woops, forgot to attach the relevant links, (i shouldn't email late at
night :) )

https://github.com/basvandijk/usb/issues/7 is the lib usb matter
https://phabricator.haskell.org/D347

point being: on ghc 7.8, certain hanging behavior from libusb (at least as
of a few months ago) was due to one shotedness

On Wed, Jan 21, 2015 at 5:18 AM, Simon Marlow  wrote:

> On 21/01/2015 03:43, Michael Jones wrote:
>
>> Simon,
>>
>> The code below hangs on the frameEx function.
>>
>> But, if I change it to:
>>
>> f  <- frameCreate objectNull idAny "linti-scope PMBus Scope Tool"
>> rectZero (frameDefaultStyle .|. wxMAXIMIZE)
>>
>> it will progress, but no frame pops up, except once in many tries. Still
>> hangs, but progresses through all the setup code.
>>
>> However, I did make past statements that a non-GUI version was hanging.
>> So I am not blaming wxHaskell. Just noting that in this case it is where
>> things go wrong.
>>
>> Anyone,
>>
>> Are there any wxHaskell experts around that might have some insight?
>>
>> (Remember, works on single core 32 bit, works on quad core 64 bit,
>> fails on 2 core 64 bit. Using GHC 7.8.3. Any recent updates to the
>> code base to fix problems like this?)
>>
>
> No, there are no recently fixed or outstanding bugs in this area that I'm
> aware of.
>
> From the symptoms I strongly suspect there's an unsafe foreign call
> somewhere causing problems, or another busy-wait loop.
>
> Cheers,
> Simon
>
>
>
>
>> — CODE SAMPLE 
>>
>> gui :: IO ()
>> gui
>>= do
>> values <- varCreate []-- Values to be
>> painted
>> timeLine <- varCreate 0   -- Line time
>> sample <- varCreate 0 -- Sample Number
>> running <- varCreate True -- True when
>> telemetry is active
>>
>> <>
>>
>> f <- frameEx frameDefaultStyle [ text := "linti-scope PMBus Scope
>> Tool"] objectNull
>>
>> Setup GUI components code was here
>>
>> return ()
>>
>> go :: IO ()
>> go = do
>>  putStrLn "Start GUI"
>>  start $ gui
>>
>> exeMain :: IO ()
>> exeMain = do
>>hSetBuffering stdout NoBuffering
>>getArgs >>= parse
>>where
>>  parse ["-h"] = usage   >> exit
>>  parse ["-v"] = version >> exit
>>  parse [] = go
>>  parse [url, port, session, target] = goServer url port (read
>> session) (read target)
>>
>>  usage   = putStrLn "Usage: linti-scope [url, port, session, target]"
>>  version = putStrLn "Haskell linti-scope 0.1.0.0"
>>  exit= System.Exit.exitWith System.Exit.ExitSuccess
>>  die = System.Exit.exitWith (System.Exit.ExitFailure 1)
>>
>> #ifndef MAIN_FUNCTION
>> #define MAIN_FUNCTION exeMain
>> #endif
>> main = MAIN_FUNCTION
>>
>> On Jan 20, 2015, at 9:00 AM, Simon Marlow  wrote:
>>
>>  My guess would be that either
>>> - a thread is in a non-allocating loop
>>> - a long-running foreign call is marked unsafe
>>>
>>> Either of these would block the other threads.  ThreadScope together
>>> with some traceEventIO calls might help you identify the culprit.
>>>
>>> Cheers,
>>> Simon
>>>
>>> On 20/01/2015 15:49, Michael Jones wrote:
>>>
 Simon,

 This was fixed some time back. I combed the code base looking for other
 busy loops and there are no more. I commented out the code that runs the
 I2C + Machines + IO stuff, and only left the GUI code. It appears that just
 the wxhaskell part of the program fails to start. This matches a previous
 observation based on printing.

 I’ll see if I can hack up the code to a minimal set that I can publish.
 All the IP is in the I2C code, so I might be able to get it down to one
 file.

 Mike

 On Jan 19, 2015, at 3:37 AM, Simon Marlow  wrote:

  Hi Michael,
>
> Previously in this thread it was pointed out that your code was doing
> busy waiting, and so the problem can be fixed by modifying your code to 
> not
> do busy waiting.  Did you do this?  The -C flag is just a workaround which
> will make the RTS reschedule more often, it won't fix the underlying
> problem.
>
> The code you showed us was:
>
> sendTransactions :: MonadIO m => SMBusDevice DeviceDC590 -> TVar Bool
> -> ProcessT m (Spec, String) ()
> sendTransactions dev dts = repeatedly $ do
>   dts' <- liftIO $ atomically $ readTVar dts
>   when (dts' == True) (do
>   (_, transactions) <- await
>   liftIO $ sendOut dev transactions)
>
> This loops when the contents of the TVar is False.
>
> Cheers,
> Simon
>
> On 18/01/2015 01:15, Michael Jones wrote:
>
>> I have narrowed down the problem a bit. It turns out that many times
>> if
>> I run the program and wait long enough, it will start. Given an event
>> log, it may take from 1000-1 entries sometimes.
>>
>> When I look at a good start vs. slow start, I see th

Re: Thread behavior in 7.8.3

[Carter Schonwald]

i think ben gamari hit similar/related issues with the lib usb bindings in
7.8, and i believe some / all of them are fixed in 7.10
(i could be mixing things up though)

On Tue, Jan 20, 2015 at 10:43 PM, Michael Jones  wrote:

> Simon,
>
> The code below hangs on the frameEx function.
>
> But, if I change it to:
>
>f  <- frameCreate objectNull idAny "linti-scope PMBus Scope Tool"
> rectZero (frameDefaultStyle .|. wxMAXIMIZE)
>
> it will progress, but no frame pops up, except once in many tries. Still
> hangs, but progresses through all the setup code.
>
> However, I did make past statements that a non-GUI version was hanging. So
> I am not blaming wxHaskell. Just noting that in this case it is where
> things go wrong.
>
> Anyone,
>
> Are there any wxHaskell experts around that might have some insight?
>
> (Remember, works on single core 32 bit, works on quad core 64 bit, fails
> on 2 core 64 bit. Using GHC 7.8.3. Any recent updates to the code base to
> fix problems like this?)
>
> — CODE SAMPLE 
>
> gui :: IO ()
> gui
>   = do
>values <- varCreate []-- Values to be
> painted
>timeLine <- varCreate 0   -- Line time
>sample <- varCreate 0 -- Sample Number
>running <- varCreate True -- True when
> telemetry is active
>
> <>
>
>f <- frameEx frameDefaultStyle [ text := "linti-scope PMBus Scope
> Tool"] objectNull
>
> Setup GUI components code was here
>
>return ()
>
> go :: IO ()
> go = do
> putStrLn "Start GUI"
> start $ gui
>
> exeMain :: IO ()
> exeMain = do
>   hSetBuffering stdout NoBuffering
>   getArgs >>= parse
>   where
> parse ["-h"] = usage   >> exit
> parse ["-v"] = version >> exit
> parse [] = go
> parse [url, port, session, target] = goServer url port (read session)
> (read target)
>
> usage   = putStrLn "Usage: linti-scope [url, port, session, target]"
> version = putStrLn "Haskell linti-scope 0.1.0.0"
> exit= System.Exit.exitWith System.Exit.ExitSuccess
> die = System.Exit.exitWith (System.Exit.ExitFailure 1)
>
> #ifndef MAIN_FUNCTION
> #define MAIN_FUNCTION exeMain
> #endif
> main = MAIN_FUNCTION
>
> On Jan 20, 2015, at 9:00 AM, Simon Marlow  wrote:
>
> > My guess would be that either
> > - a thread is in a non-allocating loop
> > - a long-running foreign call is marked unsafe
> >
> > Either of these would block the other threads.  ThreadScope together
> with some traceEventIO calls might help you identify the culprit.
> >
> > Cheers,
> > Simon
> >
> > On 20/01/2015 15:49, Michael Jones wrote:
> >> Simon,
> >>
> >> This was fixed some time back. I combed the code base looking for other
> busy loops and there are no more. I commented out the code that runs the
> I2C + Machines + IO stuff, and only left the GUI code. It appears that just
> the wxhaskell part of the program fails to start. This matches a previous
> observation based on printing.
> >>
> >> I’ll see if I can hack up the code to a minimal set that I can publish.
> All the IP is in the I2C code, so I might be able to get it down to one
> file.
> >>
> >> Mike
> >>
> >> On Jan 19, 2015, at 3:37 AM, Simon Marlow  wrote:
> >>
> >>> Hi Michael,
> >>>
> >>> Previously in this thread it was pointed out that your code was doing
> busy waiting, and so the problem can be fixed by modifying your code to not
> do busy waiting.  Did you do this?  The -C flag is just a workaround which
> will make the RTS reschedule more often, it won't fix the underlying
> problem.
> >>>
> >>> The code you showed us was:
> >>>
> >>> sendTransactions :: MonadIO m => SMBusDevice DeviceDC590 -> TVar Bool
> -> ProcessT m (Spec, String) ()
> >>> sendTransactions dev dts = repeatedly $ do
> >>>  dts' <- liftIO $ atomically $ readTVar dts
> >>>  when (dts' == True) (do
> >>>  (_, transactions) <- await
> >>>  liftIO $ sendOut dev transactions)
> >>>
> >>> This loops when the contents of the TVar is False.
> >>>
> >>> Cheers,
> >>> Simon
> >>>
> >>> On 18/01/2015 01:15, Michael Jones wrote:
>  I have narrowed down the problem a bit. It turns out that many times
> if
>  I run the program and wait long enough, it will start. Given an event
>  log, it may take from 1000-1 entries sometimes.
> 
>  When I look at a good start vs. slow start, I see that in both cases
>  things startup and there is some thread activity for thread 2 and 3,
>  then the application starts creating other threads, which is when the
>  wxhaskell GUI pops up and IO out my /dev/i2c begins. In the slow case,
>  it just gets stuck on thread 2/3 activity for a very long time.
> 
>  If I switch from -C0.001 to -C0.010, the startup is more reliable, in
>  that most starts result in an immediate GUI and i2c IO.
> 
>  The behavior suggests to me that some initial threads are starving the
>  ability for other threads to star

Re: ANNOUNCE: GHC version 7.8.4

[Carter Schonwald]

sure, please verify first.  (also make sure haddock etc works for you, i
had to remove a haddock binary from ~/.cabal/bin before haddocks were
building correctly for me)

On Wed, Dec 24, 2014 at 10:52 AM, Alfredo Di Napoli <
alfredo.dinap...@gmail.com> wrote:

> Thanks Carter!
>
> I have just asked basically about it on Reddit, in the announce thread.
> I'll give it a spin, and if it works I will share the link (if you are ok
> with that!) on the
> same Reddit post.
>
> Alfredo
>
>
> On Tuesday, 23 December 2014, Carter Schonwald 
> wrote:
> > Heres a OS X build that should work with >= 10.7
> >
> http://www.wellposed.com/opensource/ghc/releasebuild-unofficial/ghc-7.8.4-x86_64-apple-darwin.tar.bz2
> >
> > and the sha 512
> > shasum -a512 ghc-7.8.4-x86_64-apple-darwin.tar.bz2
> >
> c6e76a2cd7ec7820d071ef1f417981845bb86c4c8337a57431136a375cbd0695fe810ec10963109ab1971d1a0ab80318c62d71b95eddb5657800cac296a260bd
>  ghc-7.8.4-x86_64-apple-darwin.tar.bz2
> > On Tue, Dec 23, 2014 at 8:12 AM, Austin Seipp 
> wrote:
> >
> > ==
> > The (Interactive) Glasgow Haskell Compiler -- version 7.8.4
> > ==
> >
> > The GHC Team is pleased to announce a new patchlevel release of GHC,
> 7.8.4.
> >
> > This is an important bugfix release relative to 7.8.3 (with over 30
> > defects fixed), so we highly recommend upgrading from the previous 7.8
> > releases.
> >
> > The full release notes are here:
> >
> >
> https://downloads.haskell.org/~ghc/7.8.4/docs/html/users_guide/release-7-8-4.html
> >
> > How to get it
> > ~
> >
> > The easy way is to go to the web page, which should be self-explanatory:
> >
> > https://www.haskell.org/ghc/
> >
> > We supply binary builds in the native package format for many
> > platforms, and the source distribution is available from the same
> > place.
> >
> > Packages will appear as they are built - if the package for your
> > system isn't available yet, please try again later.
> >
> >
> > Background
> > ~~
> >
> > Haskell is a standard lazy functional programming language.
> >
> > GHC is a state-of-the-art programming suite for Haskell.  Included is
> > an optimising compiler generating good code for a variety of
> > platforms, together with an interactive system for convenient, quick
> > development.  The distribution includes space and time profiling
> > facilities, a large collection of libraries, and support for various
> > language extensions, including concurrency, exceptions, and foreign
> > language interfaces (C, whatever).  GHC is distributed under a
> > BSD-style open source license.
> >
> > A wide variety of Haskell related resources (tutorials, libraries,
> > specifications, documentation, compilers, interpreters, references,
> > contact information, links to research groups) are available from the
> > Haskell home page (see below).
> >
> >
> > On-line GHC-related resources
> > ~~
> >
> > Relevant URLs on the World-Wide Web:
> >
> > GHC home page  http://www.haskell.org/ghc/
> > GHC developers' home page  http://ghc.haskell.org/trac/ghc/
> > Haskell home page  http://www.haskell.org/
> >
> >
> > Supported Platforms
> > ~~~
> >
> > The list of platforms we support, and the people responsible for them,
> > is here:
> >
> >http://ghc.haskell.org/trac/ghc/wiki/Platforms
> >http://ghc.haskell.org/trac/ghc/wiki/CodeOwners
> >
> > Ports to other platforms are possible with varying degrees of
> > difficulty.  The Building Guide describes how to go about porting to a
> > new platform:
> >
> > http://ghc.haskell.org/trac/ghc/wiki/Building
> >
> >
> > Developers
> > ~~
> >
> > We welcome new contributors.  Instructions on accessing our source
> > code repository, and getting started with hacking on GHC, are
> > available from the GHC's developer's site run by Trac:
> >
> >   http://ghc.haskell.org/trac/ghc/
> >
> >
> > Mailing lists
> > ~
> >
> > We run mailing lists for GHC users and bug reports; to subscribe, use
> > the web interfaces at
> >
> > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> > http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
> >
> > There are several other haskell and ghc-related mailing lists on
> > www.haskell.org; for the full list, see
> >
> > http://www.haskell.org/mailman/listinfo/
> >
> > Some GHC developers hang out on #haskell on IRC, too:
> >
> > http://www.haskell.org/haskellwiki/IRC_channel
> >
> > Please report bu
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC version 7.8.4

[Carter Schonwald]

Heres a OS X build that should work with >= 10.7

http://www.wellposed.com/opensource/ghc/releasebuild-unofficial/ghc-7.8.4-x86_64-apple-darwin.tar.bz2

and the sha 512
shasum -a512 ghc-7.8.4-x86_64-apple-darwin.tar.bz2
c6e76a2cd7ec7820d071ef1f417981845bb86c4c8337a57431136a375cbd0695fe810ec10963109ab1971d1a0ab80318c62d71b95eddb5657800cac296a260bd
 ghc-7.8.4-x86_64-apple-darwin.tar.bz2

On Tue, Dec 23, 2014 at 8:12 AM, Austin Seipp  wrote:

> ==
> The (Interactive) Glasgow Haskell Compiler -- version 7.8.4
> ==
>
> The GHC Team is pleased to announce a new patchlevel release of GHC, 7.8.4.
>
> This is an important bugfix release relative to 7.8.3 (with over 30
> defects fixed), so we highly recommend upgrading from the previous 7.8
> releases.
>
> The full release notes are here:
>
>
> https://downloads.haskell.org/~ghc/7.8.4/docs/html/users_guide/release-7-8-4.html
>
> How to get it
> ~
>
> The easy way is to go to the web page, which should be self-explanatory:
>
> https://www.haskell.org/ghc/
>
> We supply binary builds in the native package format for many
> platforms, and the source distribution is available from the same
> place.
>
> Packages will appear as they are built - if the package for your
> system isn't available yet, please try again later.
>
>
> Background
> ~~
>
> Haskell is a standard lazy functional programming language.
>
> GHC is a state-of-the-art programming suite for Haskell.  Included is
> an optimising compiler generating good code for a variety of
> platforms, together with an interactive system for convenient, quick
> development.  The distribution includes space and time profiling
> facilities, a large collection of libraries, and support for various
> language extensions, including concurrency, exceptions, and foreign
> language interfaces (C, whatever).  GHC is distributed under a
> BSD-style open source license.
>
> A wide variety of Haskell related resources (tutorials, libraries,
> specifications, documentation, compilers, interpreters, references,
> contact information, links to research groups) are available from the
> Haskell home page (see below).
>
>
> On-line GHC-related resources
> ~~
>
> Relevant URLs on the World-Wide Web:
>
> GHC home page  http://www.haskell.org/ghc/
> GHC developers' home page  http://ghc.haskell.org/trac/ghc/
> Haskell home page  http://www.haskell.org/
>
>
> Supported Platforms
> ~~~
>
> The list of platforms we support, and the people responsible for them,
> is here:
>
>http://ghc.haskell.org/trac/ghc/wiki/Platforms
>http://ghc.haskell.org/trac/ghc/wiki/CodeOwners
>
> Ports to other platforms are possible with varying degrees of
> difficulty.  The Building Guide describes how to go about porting to a
> new platform:
>
> http://ghc.haskell.org/trac/ghc/wiki/Building
>
>
> Developers
> ~~
>
> We welcome new contributors.  Instructions on accessing our source
> code repository, and getting started with hacking on GHC, are
> available from the GHC's developer's site run by Trac:
>
>   http://ghc.haskell.org/trac/ghc/
>
>
> Mailing lists
> ~
>
> We run mailing lists for GHC users and bug reports; to subscribe, use
> the web interfaces at
>
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
>
> There are several other haskell and ghc-related mailing lists on
> www.haskell.org; for the full list, see
>
> http://www.haskell.org/mailman/listinfo/
>
> Some GHC developers hang out on #haskell on IRC, too:
>
> http://www.haskell.org/haskellwiki/IRC_channel
>
> Please report bugs using our bug tracking system.  Instructions on
> reporting bugs can be found here:
>
> http://www.haskell.org/ghc/reportabug
>
>
> Hashes & Signatures
> ~
>
> On https://downloads.haskell.org/~ghc/7.8.4/ you will find a signed
> copy of the SHA256 hashes for the tarballs, using my GPG key (keyid
> 0x3B58D86F).
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> ___
> ghc-devs mailing list
> ghc-d...@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: CPP Help (was Re: Latest Template Haskell Breaks Package)

[Carter Schonwald]

what version of cabal-install are you using?

On Tue, Dec 23, 2014 at 10:46 AM, Dominic Steinitz 
wrote:

> Ok I have a cut down version of the problem and am cross posting to
> glasgow-haskell-users.
>
> To restate the problem: this is from code that has not been changed for 2
> years. I get
>
> > Examples.hs:42:42: Parse error in pattern: con
> > Failed, modules loaded: none.
>
> Any help would be very gratefully received.
>
> > {-# LANGUAGE TypeFamilies, MultiParamTypeClasses,
> FunctionalDependencies #-}
> > {-# LANGUAGE FlexibleContexts #-}
> > {-# LANGUAGE EmptyDataDecls #-}
> > {-# LANGUAGE FlexibleInstances, TypeSynonymInstances #-}
> > {-# LANGUAGE UndecidableInstances, OverlappingInstances #-}
> > {-# LANGUAGE GeneralizedNewtypeDeriving, StandaloneDeriving #-}
> > {-# LANGUAGE RankNTypes, ScopedTypeVariables #-}
> > {-# LANGUAGE MagicHash, BangPatterns, UnboxedTuples #-}
> > {-# LANGUAGE TemplateHaskell, CPP #-}
> >
> > module Examples where
> >
> > import GHC.Prim
> > import GHC.Exts
> > import GHC.Types
> > import GHC.Word
> > import GHC.Int
> >
> > class Touchable a where
> > touch :: a -> IO ()
> >
> > instance Touchable Bool where
> > touch b = IO (\s -> case touch# b s of s' -> (# s', () #))
> > {-# INLINE touch #-}
> >
> > #define TOUCHABLE_INST(ty,con)  \
> > instance Touchable ty where {   \
> > touch (con x#) = IO (\s -> case touch# x# s of s' -> (# s', () #)); \
> > {-# INLINE touch #-};   \
> > }
> >
> > TOUCHABLE_INST(Int, I#)
> >
> > #define PRIM_COMP_INST(ty,con,le,ge) \
> > instance PrimitiveOrd ty where { \
> > minM' (con a#) (con b#) =\
> > IO (\s ->\
> > let r# = if le a# b# then a# else b# \
> > in case touch# r# s of s' -> (# s', (con r#) #));\
> > }
> >
> > PRIM_COMP_INST(Int, I#, (<=#), (>=#))
>
> Dominic Steinitz
> domi...@steinitz.org
> http://idontgetoutmuch.wordpress.com
>
> On 23 Dec 2014, at 15:06, Dominic Steinitz  wrote:
>
> > Hi Erik,
> >
> > Thank you very much. With that clue the compilation now doesn’t fail at
> that particular point.
> >
> > The bad news is it now fails to compile this module
> >
> >
> https://hackage.haskell.org/package/yarr-1.3.2/docs/src/Data-Yarr-Utils-Primitive.html#clampM%27
> >
> > with a parse error(!). Not only do I not have much experience with TH
> but this has now exposed my ignorance of CPP.
> >
> >> Data/Yarr/Utils/Primitive.hs:119:126: Parse error in pattern: con
> >
> > If I comment out the last four lines
> >
> >> PRIM_COMP_INST(Int, I#, (<=#), (>=#))
> >> PRIM_COMP_INST(Char, C#, leChar#, geChar#)
> >> PRIM_COMP_INST(Word, W#, leWord#, geWord#)
> >> PRIM_COMP_INST(Double, D#, (<=##), (>=##))
> >> PRIM_COMP_INST(Float, F#, leFloat#, geFloat#)
> >
> > then the module compiles but of course then the whole package does *not*
> compile.
> >
> > Did something change in 7.8.3 with regard to CPP (this code has not been
> modified for at least two years)?
> >
> > Thanks once again.
> >
> > Dominic Steinitz
> > domi...@steinitz.org
> > http://idontgetoutmuch.wordpress.com
> >
> > On 23 Dec 2014, at 13:42, Erik Hesselink  wrote:
> >
> >> Hi Dominic,
> >>
> >> It looks like just a representation change: a TySynEqn is a data type
> >> containing a [Type] and a Type, and those were the original two
> >> arguments. So it looks like with a little bit of CPP, you could
> >> support both versions. Something like
> >>
> >> #if MIN_VERSION_template_haskell(2,9,0)
> >> ...
> >> #else
> >> ...
> >> #endif
> >>
> >> In general, I think each major release of template haskell has quite
> >> some breaking changes, but I don't know of any place where they're
> >> enumerated. The GHC changelog only has a couple of high level bullet
> >> points.
> >>
> >> Regards,
> >>
> >> Erik
> >>
> >> On Tue, Dec 23, 2014 at 2:20 PM, Dominic Steinitz 
> wrote:
> >>> I realise I should have sent this to the libraries list.
> >>>
> >>> Dominic Steinitz
> >>> domi...@steinitz.org
> >>> http://idontgetoutmuch.wordpress.com
> >>>
> >>> Begin forwarded message:
> >>>
> >>> From: Dominic Steinitz 
> >>> Subject: Latest Template Haskell Breaks Package
> >>> Date: 23 December 2014 13:14:26 GMT
> >>> To: Haskell-Cafe 
> >>>
> >>> Hello Fellow Haskellers,
> >>>
> >>> I have become a maintainer for yarr
> >>> (https://hackage.haskell.org/package/yarr). This no longer compiles
> with
> >>> ghc-7.8.3 because it specifies base == 4.6. Relaxing this to base
> >=4.6 &&
> >>> <4.8 tells me I need a newer version of Template Haskell
> >>>
> >>> rejecting: template-haskell-2.7.0.0, 2.6.0.0, 2.5.0.0, 2.4.0.1,
> 2.4.0.0,
> >>> 2.3.0.1, 2.3.0.0, 2.2.0.0 (conf

Re: Behavior of touch#

[Carter Schonwald]

the point of touch is to prevent premature GC, it actually gets erased at
the CMM level i believe.
That is, it only makes sense to apply touch to lifted types on the heap!

On Mon, Dec 15, 2014 at 4:21 PM, Brandon Simmons <
brandon.m.simm...@gmail.com> wrote:
>
> The `primitive` package exports a lifted version of the undocumented
> `touch#`
>
> http://hackage.haskell.org/package/ghc-prim-0.3.1.0/docs/GHC-Prim.html
>
> which has type:
>
> touch :: PrimMonad m => a -> m ()
>
> I'd like to know if this works correctly in general, or will it suffer
> from the same gotches w/r/t unboxing as with addFinalizer and Weak
> references? i.e. must it only be passed an unboxed type?
>
> Brandon
> ___
> 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

Re: Behavior of touch#

[Carter Schonwald]

https://github.com/ghc/ghc/blob/8c10b67ba049477cc9ed23e61f5bd119e1cefc29/compiler/cmm/CmmMachOp.hs#L556

and
https://github.com/ghc/ghc/blob/8c10b67ba049477cc9ed23e61f5bd119e1cefc29/compiler/nativeGen/X86/CodeGen.hs#L1731

spell it out a bit more

so touch is preserved through the CMM level, and then gets erased when
doing final code gen.
Its meant to ensure on heap pointers remain reachable

On Tue, Dec 16, 2014 at 1:43 AM, Carter Schonwald <
carter.schonw...@gmail.com> wrote:
>
> the point of touch is to prevent premature GC, it actually gets erased at
> the CMM level i believe.
> That is, it only makes sense to apply touch to lifted types on the heap!
>
> On Mon, Dec 15, 2014 at 4:21 PM, Brandon Simmons <
> brandon.m.simm...@gmail.com> wrote:
>>
>> The `primitive` package exports a lifted version of the undocumented
>> `touch#`
>>
>>
>> http://hackage.haskell.org/package/ghc-prim-0.3.1.0/docs/GHC-Prim.html
>>
>> which has type:
>>
>> touch :: PrimMonad m => a -> m ()
>>
>> I'd like to know if this works correctly in general, or will it suffer
>> from the same gotches w/r/t unboxing as with addFinalizer and Weak
>> references? i.e. must it only be passed an unboxed type?
>>
>> Brandon
>> ___
>> 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

Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1

[Carter Schonwald]

Thomas and I have found some bugs in HPC on OSX, and we're in the midst of
tracking those down,

Those fixes should get into 7.8.4 and 7.10 both.  Currently HPC on OSX is
broken in pretty fundamental ways, and thats not ok!

-Carter


On Wed, Dec 3, 2014 at 5:53 PM, George Colpitts 
wrote:
>
> Would it be possible to get a RC for the Mac up at
> https://downloads.haskell.org/~ghc/7.8.4-rc1/ ?
>
> Thanks
> George
>
>
> On Wed, Nov 26, 2014 at 10:31 AM, Herbert Valerio Riedel 
> wrote:
>
>> On 2014-11-26 at 12:40:37 +0100, Sven Panne wrote:
>> > 2014-11-25 20:46 GMT+01:00 Austin Seipp :
>> >> We are pleased to announce the first release candidate for GHC 7.8.4:
>> >>
>> >> https://downloads.haskell.org/~ghc/7.8.4-rc1/ [...]
>> >
>> > Would it be possible to get the RC on
>> > https://launchpad.net/~hvr/+archive/ubuntu/ghc? This way one could
>> > easily test things on Travis CI.
>>
>> I'll put a 7.8.4rc .deb up soon (probably right after the GHC 7.10
>> branch has been created)
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>
>
> ___
> ghc-devs mailing list
> ghc-d...@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: New implementation draft for -XStaticPointers

[Carter Schonwald]

Hey Facundo... the merge window for 7.10 closed a few days ago. (i myself
have some work thats missed that merge window too)

that said, great work and I look forward to helping with the code review.
-Carter

On Tue, Dec 2, 2014 at 4:22 PM, John Wiegley  wrote:

> > Facundo Domínguez  writes:
>
> >   We are pleased to announce a new implementation draft of the
> > StaticPointers extension [1].
>
> Very nice, thank you!
>
> John
> ___
> 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

Re: Defining a custom newByteArray primop that uses calloc?

[Carter Schonwald]

you cant provide > 1 word alignment guarantees if the bytearray isnt
pinned, ... at least with the current RTS setup. (though that would be
pretty handy if possible)

On Wed, Nov 26, 2014 at 8:55 PM, Erik de Castro Lopo 
wrote:

> Brandon Simmons wrote:
>
> > In my tests, using calloc from:
> >
> >
> https://hackage.haskell.org/package/missing-foreign-0.1.1/docs/Foreign-Marshal-MissingAlloc.html
> >
> > was about twice as fast as allocating and zeroing the same amount of
> > memory with `newByteArray` + any of `copy/set/fillMutableByteArray`
> > (all three were nearly identical). Is there a way I can reasonably
> > define my own `newByteArray` that uses calloc?
> >
> > FWIW here are a couple of the benchmarks I'm working with in criterion:
> >
> > arrTestSet :: Int -> IO ()
> > arrTestSet len = do
> > let eBytes = (P.sizeOf (undefined::Int))*len
> > a <- P.newAlignedPinnedByteArray
>
> Why pinned memory?
>
> Erik
> --
> --
> Erik de Castro Lopo
> http://www.mega-nerd.com/
> ___
> 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

Re: GHC 7.8.3 thread hang

[Carter Schonwald]

what OS are you on?
what build options did you use?

On Tue, Nov 11, 2014 at 2:11 AM, Michael Jones  wrote:

> I am trying to debug a lockup problem (and need help with debugging
> technique), where hang means a thread stops at a known place during
> evaluation, and other threads continue.
>
> The code near the problem is like:
>
>ec <- return $ encode command
>l <- return $ BSL.length ec
>ss <- return $ BSC.unpack ec
>
> It does not matter if I use let or return, or if the length is taken after
> unpack. I used return so I could use this code for tracing, with strictness
> to try to find the exact statement that is the problem:
>
>traceEventIO "sendCommand"
>ec <- return $ encode command
>traceEventIO $ "sendCommand: encoded"
>l <- ec `seq` return $ BSL.length ec
>traceEventIO $ "sendCommand: size " ++ (show l)
>ss <- ec `seq` return $ BSC.unpack ec
>
> When this runs, the program executes this many times, but always hangs
> under a certain condition.
>
> For good evaluations:
>
> 7f04173ff700: cap 0: sendCommand
> 7f04173ff700: cap 0: sendCommand: encoded
> 7f04173ff700: cap 0: sendCommand: size 4
> 7f04173ff700: cap 0: sendCommand: unpacked
> 7f04173ff700: cap 0: Sending command of size 4
> 7f04173ff700: cap 0: Sending command of size "\NUL\EOT"
> 7f04173ff700: cap 0: sendCommand: sent
> 7f04173ff700: cap 0: sendCommand: flushed
>
> for bad evaluation:
>
> 7f04173ff700: cap 0: sendCommand
> 7f04173ff700: cap 0: sendCommand: encoded
>
> The lockup occurs when length is taken.
>
> The difference between the working and non-working case is as follows:
>
> A wxHaskell callback stuffs some data in a TChan. A thread started at
> application startup is reading the TChan and calling the code that hangs.
> If it did not hang, it would send it by TCP to another process/computer.
>
> In the working case the callback pops a dialog, and passes data from one
> TChan to another TChan.
>
> In the failing case, the data is used to generate strings in a wxHaskell
> grid, then it is parsed, and a new data is made. The new data is a
> combination of old and new pieces of sub data. The shape of the date is
> identical, because I am not making any edits to the rows.
>
> So when data that the callback sends to TChan is unmodified, no hang. But
> when the data is used to make text, put it in the gui, process it, and
> generate new data, it hangs.
>
> As a test I modified the code so that the text is not put into the gui.
> The results are the same. This indicates it has something to do with
> creating strings and then data from strings and mixing old and new subdata.
> Strings are created with show. Data is created by pattern matching and
> generating numbers from strings. I should also point out that in the
> working case, the size of the resulting string is small, say 3. In the hang
> case, the resulting string would be long, say 5000-1.
>
> I assume there are no limits to the size of ByteStrings or fundemental
> issues with the RTS stack/heap that require special settings.
>
> I am using the following revisions:
>
> GHC 7.8.3
> base ==4.7.*,
> mtl ==2.2.1,
> containers == 0.5.5.1,
> transformers ==0.4.1.0,
> random == 1.0.1.1,
> wx == 0.91.0.0,
> wxcore == 0.91.0.0,
> wxdirect == 0.91.0.0,
> colour == 2.3.3,
> stm == 2.4.2,
> monad-loops == 0.4.2.1,
> time == 1.4.2,
> old-locale == 1.0.0.6,
> fast-logger == 2.2.3,
> network == 2.6.0.2,
> bytestring == 0.10.4.0,
> control-monad-loop == 0.1,
> binary == 0.7.2.2,
>
> I know that nobody can have an answer based on this. But what I am hoping
> is either there is some known bug, or someone can guide me in narrowing it
> down. The event log does not have anything unusual in it. Other threads
> keep running, and I can exit the application normally. The thread does not
> throw an exception. It just hangs.
>
> When I run the app, I just use +RTS -v
>
> Perhaps there are some other options that might give more info?
>
> — SNIPPET of log —
>
> 7fe544cfea40: cap 0: running thread 5 (ThreadRunGHC)
> 7fe544cfea40: cap 0: thread 5 stopped (yielding)
> 7fe544cfea40: cap 0: running thread 5 (ThreadRunGHC)
> 7fe544cfea40: cap 0: thread 5 stopped (suspended while making a foreign
> call)
> 7fe544cfea40: cap 0: running thread 5 (ThreadRunGHC)
> 7fe544cfea40: cap 0: thread 5 stopped (blocked on an MVar)
> 7fe537eff700: cap 0: running thread 2 (ThreadRunGHC)
> 7fe537eff700: cap 0: waking up thread 5 on cap 0
> 7fe537eff700: cap 0: thread 2 stopped (yielding)
> 7fe544cfea40: cap 0: running thread 5 (ThreadRunGHC)
> 7fe544cfea40: cap 0: sendCommand
> 7fe544cfea40: cap 0: sendCommand: encoded
> 7fe544cfea40: cap 0: sendCommand: size 3
>  WORKS HERE
> 7fe544cfea40: cap 0: sendCommand: unpacked
> 7fe544cfea40: cap 0: Sending command of size 3
> 7fe544cfea40: cap 0: Sending command of size "\NUL\ETX"
> 7fe544cfea40: cap 0: sendCommand: sent
> 7fe544cfea40: 

Re: Recursion on TypeNats

[Carter Schonwald]

derp, my bad
https://github.com/wellposed/numerical/blob/master/src/Numerical/Nat.hs has
a fuller implementation of this though, that i've been using for a few
months

as for the plugin question, i think about adding constraint solves to the
type system... so i dont know if thats quite what you want though,

On Sat, Oct 25, 2014 at 2:33 PM, Barney Hilken 
wrote:

> >
> > because you haven't helped write a patch change it yet :)
> >
> > -Carter
> >
>
> Would this be possible with the new type checker plugins?
>
> btw, your example gives me
>
> Nested type family application
>   in the type family application: U (n - 1)
> (Use UndecidableInstances to permit this)
> In the equations for closed type family ‘U’
> In the type family declaration for ‘U’
> Failed, modules loaded: none.
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Recursion on TypeNats

[Carter Schonwald]

because you haven't helped write a patch change it yet :) 


-Carter

On Sat, Oct 25, 2014 at 9:53 AM, Barney Hilken 
wrote:

> If you define your own type level naturals by promoting
> data Nat = Z | S Nat
> you can define data families recursively, for example
> data family Power :: Nat -> * -> *
> data instance Power Z a = PowerZ
> data instance Power (S n) a = PowerS a (Power n a)
> But if you use the built-in type level Nat, I can find no way to do the same 
> thing. You can define a closed type family
> type family Power (n :: Nat) a where
>   Power 0 a = ()
>   Power n a = (a, Power (n-1) a)
> but this isn't the same thing (and requires UndecidableInstances).
> Have I missed something? The user guide page is pretty sparse, and not up to 
> date anyway.
> If not, are there plans to add a "Successor" constructor to Nat? I would have 
> thought this was the main point of using Nat rather than Int.
> Barney.
> ___
> 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

Re: Recursion on TypeNats

[Carter Schonwald]

you want the following (which doesnt require undediable instances)

data Nat = Z | S Nat

type family U (x :: Nat) where
  U  0 = Z
  U n = S (U (n-1))

this lets you convert type lits into your own peanos or whatever

hat tip to richard eisenburg for showing me this trick on the mailing list
a while ago


On Sat, Oct 25, 2014 at 9:53 AM, Barney Hilken 
wrote:

> If you define your own type level naturals by promoting
>
> data Nat = Z | S Nat
>
> you can define data families recursively, for example
>
> data family Power :: Nat -> * -> *
> data instance Power Z a = PowerZ
> data instance Power (S n) a = PowerS a (Power n a)
>
> But if you use the built-in type level Nat, I can find no way to do the
> same thing. You can define a closed type family
>
> type family Power (n :: Nat) a where
> Power 0 a = ()
> Power n a = (a, Power (n-1) a)
>
> but this isn't the same thing (and requires UndecidableInstances).
>
> Have I missed something? The user guide page is pretty sparse, and not up
> to date anyway.
>
> If not, are there plans to add a "Successor" constructor to Nat? I would
> have thought this was the main point of using Nat rather than Int.
>
> Barney.
>
> ___
> 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

Re: GHC 7.8.4: call for tickets, show stoppers, and timelines - oh my!

[Carter Schonwald]

would https://ghc.haskell.org/trac/ghc/ticket/9284 be good candidate for
7.8.4 ?
It looks like its the only forkProcess related bug fix that wasnt merged
into 7.8.3, and impacts OS X

On Mon, Oct 13, 2014 at 12:37 PM, Austin Seipp 
wrote:

> Hi *,
>
> After some discussion with Simon & Mikolaj today, I'd like to direct
> you all at this:
>
> https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8.4
>
> This status page is the basic overview of what we plan on doing for
> 7.8.4. There are two basic components to this page:
>
>  - Show stopping bugs.
>  - Everything else, which is "nice to have".
>
> Show stoppers are listed at the top of the page, in the first
> paragraph. Right now, this includes:
>
>  - #9439 - LLVM mangling too vigorously.
>  - #8819 - Arithmetic failures for unregistered systems
>  - #8690 - SpecConstr blow-up
>
> And that's all. But what's all the other stuff? That's "everything else".
>
> Aside from these tickets listed here - and any future amendments to it
> - all other tickets will only be considered nice-to-have. What does
> that mean?
>
>  - It's low risk to include.
>  - It clearly fixes the problem
>  - It doesn't take Austin significant amounts of time to merge.
>
> For example, "Tickets marked merge with no milestone" are all
> nice-to-have. Similarly, all the *closed tickets* on this page may be
> re-opened and merged again[1], since most didn't make it to 7.8.4.
>
> Ditto with the remaining categories.
>
> OK, so that's the gist. Now I ask of you the following:
>
>  - If you have a show-stopping bug with GHC 7.8.3, **you really,
> _positively_ need to file a bug, and get in contact with me ASAP**.
> Otherwise you'll be waiting for 7.10 most likely.
>  - Again: if you have a show stopper, contact me. Very soon.
>  - If there are bugs you *think* are showstoppers, but we didn't
> categorize them properly, let me know.
>
> Anything we accept as a show-stopper will delay the release of 7.8.4.
> Anything else can (and possibly will) be left behind. Luckily, almost
> all of the show stoppers have patches. Only #8819 does not, but I have
> asked Sergei to look into it for me if he has time today.
>
> Finally, I would please ask that users/developers do not include their
> own personal pet tickets under "show stoppers" without consulting me
> first, at least. :) If it's just nice to have, you can still pester
> me, of course, and I'll try to make it happen.
>
> I would like to have 7.8.4 out and done with by mid November, before
> we freeze the new STABLE branch for 7.10.1. That's not a hard
> deadline; just a timeframe I'd like to hit.
>
> Let me know if you have any questions or comments; thanks!
>
> [1] A lot of the closed tickets on this page had an improper milestone
> set, which is why they show up. You can mostly ignore them, I
> apologize.
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> ___
> ghc-devs mailing list
> ghc-d...@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Type checker plugins

[Carter Schonwald]

mind you, i'm not sure what the ordering is specified to be :)

On Thu, Oct 16, 2014 at 9:24 PM, Carter Schonwald <
carter.schonw...@gmail.com> wrote:

> http://hackage.haskell.org/package/base-4.7.0.1/docs/GHC-TypeLits.html
>
> type family CmpSymbol m n :: Ordering
> <http://hackage.haskell.org/package/base-4.7.0.1/docs/Data-Ord.html#t:Ordering>
>
> On Thu, Oct 16, 2014 at 7:14 PM, Barney Hilken 
> wrote:
>
>> Ok, I hadn't realised that. Looking in the user's guide, I see <= and <=?
>> for Nat, but I couldn't find anything about Symbol. I must try them out!
>>
>>
>> > From: Carter Schonwald 
>> >
>> > the alphabetical ordering on Symbol is already exposed via TypeLits...
>> this would be some machinery to help maintain that ordering with less user
>> intervention?
>> >
>> > On Thu, Oct 16, 2014 at 6:59 PM, Barney Hilken 
>> wrote:
>> > I can think of a use for a non-equality constraint: an alphabetical
>> ordering on Symbol. This would allow experimental implementations of
>> extensible records (without shadowing) which keep the labels sorted.
>> >
>> > An order constraint on Nat might be useful, too.
>> >
>> > Barney.
>> >
>> > ___
>> > 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

Re: Type checker plugins

[Carter Schonwald]

http://hackage.haskell.org/package/base-4.7.0.1/docs/GHC-TypeLits.html

type family CmpSymbol m n :: Ordering
<http://hackage.haskell.org/package/base-4.7.0.1/docs/Data-Ord.html#t:Ordering>

On Thu, Oct 16, 2014 at 7:14 PM, Barney Hilken 
wrote:

> Ok, I hadn't realised that. Looking in the user's guide, I see <= and <=?
> for Nat, but I couldn't find anything about Symbol. I must try them out!
>
>
> > From: Carter Schonwald 
> >
> > the alphabetical ordering on Symbol is already exposed via TypeLits...
> this would be some machinery to help maintain that ordering with less user
> intervention?
> >
> > On Thu, Oct 16, 2014 at 6:59 PM, Barney Hilken 
> wrote:
> > I can think of a use for a non-equality constraint: an alphabetical
> ordering on Symbol. This would allow experimental implementations of
> extensible records (without shadowing) which keep the labels sorted.
> >
> > An order constraint on Nat might be useful, too.
> >
> > Barney.
> >
> > ___
> > 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

Re: Type checker plugins

[Carter Schonwald]

the alphabetical ordering on Symbol is already exposed via TypeLits... this
would be some machinery to help maintain that ordering with less user
intervention?

On Thu, Oct 16, 2014 at 6:59 PM, Barney Hilken 
wrote:

> I can think of a use for a non-equality constraint: an alphabetical
> ordering on Symbol. This would allow experimental implementations of
> extensible records (without shadowing) which keep the labels sorted.
>
> An order constraint on Nat might be useful, too.
>
> Barney.
>
> ___
> 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

Re: Type checker plugins

[Carter Schonwald]

yay :)

On Mon, Oct 6, 2014 at 2:42 PM, Iavor Diatchki 
wrote:

> Hi Adam,
>
> I am back from vacation, and I think I should have some time to try to
> implement something along these lines.
>
> Cheers,
> -Iavor
>
> On Fri, Sep 12, 2014 at 9:41 AM, Adam Gundry  wrote:
>
>> Hi folks,
>>
>> Those of you at HIW last week might have been subjected to my lightning
>> talk on plugins for the GHC type checker, which should allow us to
>> properly implement nifty features like units of measure or type-level
>> numbers without recompiling GHC. I've written up a wiki page summarising
>> the idea:
>>
>> https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker
>>
>> Feedback is very welcome, particularly if (a) you have an interesting
>> use for this feature or (b) you think this is a terrible idea!
>>
>> Thanks,
>>
>> Adam
>>
>>
>> --
>> Adam Gundry, Haskell Consultant
>> Well-Typed LLP, http://www.well-typed.com/
>>
>
>
> ___
> 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

Re: Type checker plugins

[Carter Schonwald]

i'm looking at the record type

data TcPlugin = forall t . TcPlugin
  { init  :: TcM t
  , solve :: t -> [Ct] -> [Ct] -> TcS ([SolveResult], [Ct])
  , close :: t -> TcM ()
  }

it might be helpful to add a remark that
data Ct = ...
is defined in compiler/typechecker/TcRnTypes.lhs so folks who aren't
already intimately familiar with the constraint solver machinery in GHC can
get some wee hints about where to start digging around if they wanted to
understand the implications of the proposal :)

On Fri, Sep 12, 2014 at 12:41 PM, Adam Gundry  wrote:

> Hi folks,
>
> Those of you at HIW last week might have been subjected to my lightning
> talk on plugins for the GHC type checker, which should allow us to
> properly implement nifty features like units of measure or type-level
> numbers without recompiling GHC. I've written up a wiki page summarising
> the idea:
>
> https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker
>
> Feedback is very welcome, particularly if (a) you have an interesting
> use for this feature or (b) you think this is a terrible idea!
>
> Thanks,
>
> Adam
>
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> ___
> 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

Re: hmatrix-0.16.0.4 installation problem

[Carter Schonwald]

What Linux distro?  If you're on an unusual distro  You might just need to
patch the build process to look up the right names.

Also have you contacted the hmatrix maintainer to ask him for help. HMATRIX
does have an issue tracker on github etc

On Friday, August 22, 2014, Adrian Victor Crisciu 
wrote:

> I tried the following command line:
>
> cabal install --enable-documentation
> --extra-include-dirs=/usr;local/include --extra-lib-dirs=/usr/local/lib
> hmatrix
>
> and got the following:
>
> Resolving dependencies...
> Configuring hmatrix-0.16.0.4...
> cabal: Missing dependencies on foreign libraries:
> * Missing C libraries: blas, lapack
> This problem can usually be solved by installing the system packages that
> provide these libraries (you may need the "-dev" versions). If the
> libraries
> are already installed but in a non-standard location then you can use the
> flags --extra-include-dirs= and --extra-lib-dirs= to specify where they
> are.
> Failed to install hmatrix-0.16.0.4
> cabal: Error: some packages failed to install:
> hmatrix-0.16.0.4 failed during the configure step. The exception was:
> ExitFailure 1
>
> As I said before, the libraries for blas and lapack ARE in /usr/local/lib
> and the header files ARE in /usr/local/include.
>
> Is it possible for hmatrix to look for another version of atlas/blas and
> lapack? I have installed atlas-3.3.8 and lapack-3.4.0
>
> Adrian.
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: hmatrix-0.16.0.4 installation problem

[Carter Schonwald]

You need to pass cabal the extra includes and extra lib dirs flags with the
explicit paths to the lib and include folders that have your blas and
lapack.  The logic in hmatrix can only check stadard paths.

On Thursday, August 21, 2014, Adrian Victor Crisciu 
wrote:

> Hi,
>
> Yes, they are in /usr/local/include. Moreover, /usr/local/lib64 is a
> symbolic link to /usr/local/lib (as may system is a 64-bit anyway), so the
> libraries should be found regardless of the path they are searched on.
>
> I have atlas-3.3.8 and lapack-3.4.0. Are newer versions required?
>
> Thanks!
> Adrian.
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Revival: PROPOSAL: Literate haskell and module file names

[Carter Schonwald]

i personally think the .format+lhs pattern/convention is a good one, and
prevents any misinterpretations that current plague literate tools + willl
be treated as an unknown format rather than eagerly as .format or .lhs


On Sat, Aug 16, 2014 at 5:05 PM, Merijn Verstraaten 
wrote:

> Hey Philip,
>
> This proposal is not because *GHC* needs to know anything about
> markdown/rST, in fact, GHC is already perfectly happy to take a literate
> haskell files that’s written in markdown, since it just strips the
> non-haskell bits and only compiles the haskell code.
>
> The problem is OTHER tools. For example, I have literate haskell files for
> my blog posts, how does my blog software know whether my lhs file is
> markdown, rST, TeX, or what not? I can just name my files using anyway I
> want (like “Foo.md.lhs”) to have these tools detect the format, but then
> GHC will no longer compile my files.
>
> This is the problem I’m trying to solve with this proposal, once we settle
> on some extension format like this, it’s trivial to patch (for example)
> pandoc to use this to detect which contents are in the file.
>
> Cheers,
> Merijn
>
>
> On 16 Aug 2014, at 06:51 , p.k.f.holzensp...@utwente.nl wrote:
> > Dear Merijn,
> >
> > Do you even need a separate extension or filename convention for this?
> Can't you just call it lhs and expand the definition thereof to include
> markdown? (I suggested something similar before, but objections were raised
> that having too good and too broad an unlitter might lead to the bit-rot of
> the flag to employ external unlitters. I didn't quite understand that
> objection, but didn't pursue it)
> >
> > Regards,
> > Philip
> >
> >
> > 
> > Van: Glasgow-haskell-users 
> namens Merijn Verstraaten 
> > Verzonden: zaterdag 16 augustus 2014 00:40
> > Aan: haskell-pr...@haskell.org; glasgow-haskell-users@haskell.org
> > Onderwerp: Revival: PROPOSAL: Literate haskell and module file names
> >
> > Ola!
> >
> > I raised this proposal earlier this year and got to busy to follow up,
> this week I was suddenly reminded and decided to reraise this. To summarise
> the discussion up until this point:
> >
> > There was no real opposition to the general idea, the only real
> objection to the original proposal was that “Foo.lhs.md” and “Foo.md.lhs”
> would collide with the naming scheme used by JHC on case insensitive
> filesystems. Alternative proposal raised during the discussion:
> "Foo+md.lhs", "Foo.lhs+md” and “Foo.md+lhs”.
> >
> > According to MS documentation and testing the + should not be an issue
> on windows, the + doesn’t collide with any other haskell compiler (at
> least, not any I’m aware off) and since the report doesn’t specify any
> module name resolution mechanism, it does not conflict with the report
> either.
> >
> > My personal preferences goes to either “.lhs+md” or “.md+lhs”, since GHC
> currently tries every alternative in turn, I propose to just extend this
> list to look for any file whose extension is “.lhs+*” or “.*+lhs”.
> >
> > Are there any objections to this? If not, I’m just going to produce a
> patch + ticket as there were no real objections to the proposal last time.
> >
> > Cheers,
> > Merijn
> >
> > On 16 Mar 2014, at 05:56 , Merijn Verstraaten 
> wrote:
> >> Ola!
> >>
> >> I didn't know what the most appropriate venue for this proposal was so
> I crossposted to haskell-prime and glasgow-haskell-users, if this isn't the
> right venue I welcome advice where to take this proposal.
> >>
> >> Currently the report does not specify the mapping between filenames and
> module names (this is an issue in itself, it essentially makes writing
> haskell code that's interoperable between compilers impossible, as you
> can't know what directory layout each compiler expects). I believe that a
> minimal specification *should* go into the report (hence, haskell-prime).
> However, this is a separate issue from this proposal, so please start a new
> thread rather than sidetracking this one :)
> >>
> >> The report only mentions that "by convention" .hs extensions imply
> normal haskell and .lhs literate haskell (Section 10.4). In the absence of
> guidance from the report GHC's convention of mapping module Foo.Bar.Baz to
> Foo/Bar/Baz.hs or Foo/Bar/Baz.lhs seems the only sort of standard that
> exists. In general this standard is nice enough, but the mapping of
> literate haskell is a bit inconvenient, it leaves it completelyl ambiguous
> what the non-haskell content of said file is, which is annoying for tool
> authors.
> >>
> >> Pandoc has adopted the policy of checking for further file extensions
> for literate haskell source, e.g. Foo.rst.lhs and Foo.md.lhs. Here .rst.lhs
> gets interpreted as being reStructured Text with literate haskell and
> .md.lhs is Markdown with literate haskell. Unfortunately GHC currently maps
> filenames like this to the module names Foo.rst and Foo.md, breaking
> anything that wants to import the module Foo.
> >>
> >> I

Re: 'import ccall unsafe' and parallelism

[Carter Schonwald]

glad I could help,
https://github.com/wellposed/hblas/blob/master/src/Numerical/HBLAS/BLAS/Internal.hs#L146
is
an example of the "choose to do the safe vs unsafe ffi call" trick
in the case of blas / lapack routines, i can always estimate how long a
compute job will take as a function of its inputs, and i use that estimate
to decide which ffi strategy to use (ie i use unsafe ffi on < 10
microsecond computations so that the overhead doesn't dominate the compute
time on tiny inputs)


On Thu, Aug 14, 2014 at 5:38 PM, Christian Höner zu Siederdissen <
choe...@tbi.univie.ac.at> wrote:

> That's actually a great idea, especially since the safe variants of the
> calls are already in place.
>
> * Carter Schonwald  [14.08.2014 23:10]:
> >have a smart wrapper around you ffi call, and if when you think the
> ffi
> >call will take more than 1 microsecond, ALWAYS use the safe ffi call,
> >i do something like this in an FFI i wrote, it works great
> >
> >On Thu, Aug 14, 2014 at 1:20 PM, Christian HAP:ner zu Siederdissen
> > wrote:
> >
> >  Thanks,
> >
> >  I've played around some more and finally more than one capability is
> >  active. And indeed, unsafe calls don't block everything. I /had/
> >  actually read that but when I saw the system spending basically only
> >  100% cpu time, I'd thought to ask.
> >
> >  One problem with this program seems to be that the different tasks
> are
> >  of vastly different sizes. Inputs range from ~ 7x10^1 to ~ 3x10^7
> >  elements inducing waits with the larger problem sizes.
> >
> >  We'll keep the program single-threaded for now as this also keeps
> memory
> >  consumption at only 25 gbyte instead of the more impressive 70
> gbyte in
> >  multi-threaded mode ;-)
> >
> >  Viele Gruesse,
> >  Christian
> >
> >  ___
> >  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

Re: 'import ccall unsafe' and parallelism

[Carter Schonwald]

have a smart wrapper around you ffi call, and if when you think the ffi
call will take more than 1 microsecond, ALWAYS use the safe ffi call,
i do something like this in an FFI i wrote, it works great


On Thu, Aug 14, 2014 at 1:20 PM, Christian Höner zu Siederdissen <
choe...@tbi.univie.ac.at> wrote:

> Thanks,
>
> I've played around some more and finally more than one capability is
> active. And indeed, unsafe calls don't block everything. I /had/
> actually read that but when I saw the system spending basically only
> 100% cpu time, I'd thought to ask.
>
> One problem with this program seems to be that the different tasks are
> of vastly different sizes. Inputs range from ~ 7x10^1 to ~ 3x10^7
> elements inducing waits with the larger problem sizes.
>
> We'll keep the program single-threaded for now as this also keeps memory
> consumption at only 25 gbyte instead of the more impressive 70 gbyte in
> multi-threaded mode ;-)
>
> Viele Gruesse,
> Christian
>
>
> ___
> 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

Re: 'import ccall unsafe' and parallelism

[Carter Schonwald]

if your computation in the C call takes more than 400 nano seconds, the
overhead of the safe ffi convention is less onerous and you should do that
when applicable.

an alternative is so use forkOn to setup a worker thread on various GHC
capabilities, and have them in parallel work on different chunks of the
list. that way you're pausing ALL the capabilities (which again, you should
only use the unsafe ffi convention for computations that take <= 10
microseconds if you want things to be well behaved)


On Thu, Aug 14, 2014 at 12:21 PM, Donn Cave  wrote:

> I'm no judge of what's true about safe and unsafe, but this account of
> the system has at least to my ear the ring of authenticity:
>
>
> http://blog.melding-monads.com/2011/10/24/concurrency-and-foreign-functions-in-the-glasgow-haskell-compiler/
>
> The FFI section is short and readable.
>
> With respect to whether "unsafe" does or does not block other threads,
> I can never penetrate the verbiage about capabilities to know for sure
> what to expect in practice, but when I checked, in practice, "unsafe"
> blocks other threads.  I use "safe" to avoid this.
>
> Donn
> ___
> 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

Re: Old code broken by new Typeable class

[Carter Schonwald]

thats what i meant. I meant you can't WRITE the body of a typeable in 7.8,
you can derive though


On Tue, Aug 5, 2014 at 1:59 PM, Brandon Allbery  wrote:

> On Tue, Aug 5, 2014 at 1:47 PM, Volker Wysk 
> wrote:
>
>> Am Dienstag, 5. August 2014, 12:46:23 schrieb Carter Schonwald:
>> > i assume 7.6 and 7.8, if we're talking GHC rather than GCC :)
>> >
>> > in 7.8 you can't define userland typeable instances, you need only write
>> > deriving (Typeable) and you're all set.
>> > add some CPP to select the instances suitable
>>
>> So you need to be able to change the definition of the data type, in
>> order to
>> add deriving (Typeable). It's not possible to add a Typeable instance
>> declaration later.
>>
>
> Are you sure? There is a standalone deriving syntax.
>
> deriving instance Typeable ProcessStatus
>
>
> http://www.haskell.org/ghc/docs/latest/html/users_guide/deriving.html#stand-alone-deriving
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
> ___
> 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

Re: Old code broken by new Typeable class

[Carter Schonwald]

more concretely
#if defined(__GLASGOW_HASKELL__) && ( __GLASGOW_HASKELL__ >= 707)
 --- do the deriving version here
#else
--- your current stuff
#endif


On Tue, Aug 5, 2014 at 12:46 PM, Carter Schonwald <
carter.schonw...@gmail.com> wrote:

> i assume 7.6 and 7.8, if we're talking GHC rather than GCC :)
>
> in 7.8 you can't define userland typeable instances, you need only write
> deriving (Typeable) and you're all set.
> add some CPP to select the instances suitable
>
>
> On Tue, Aug 5, 2014 at 12:41 PM, Volker Wysk 
> wrote:
>
>>  Hi!
>>
>> I've been working with GHC-4.6.3, and updating to GHC-4.8.3 breaks my
>> code,
>>
>> because the Typeable class has been changed. The compiler produces this
>>
>> message:
>>
>> -
>>
>> src/HsShellScript/ProcErr.chs:2294:4:
>>
>> ‘typeOf’ is not a (visible) method of class ‘Typeable’
>>
>> -
>>
>> I want to define System.Posix.Process.ProcessStatus to be an instance of
>>
>> Typeable, so I can throw and catch it as an exception. ProcessStatus
>> isn't
>>
>> typeable by default.
>>
>> Is it still possible to make ProcessStatus a member of Typeable? How?
>>
>> Obviously, you can't accomplish it by deriving Typeable, because the
>> definition
>>
>> can't be changed any longer.
>>
>> This is the spot in question:
>>
>> --
>>
>> import System.Posix.Process
>>
>> import Data.Typeable
>>
>> {-
>>
>> data ProcessStatus = Exited ExitCode
>>
>>| Terminated Signal
>>
>>| Stopped Signal
>>
>>deriving (Eq, Ord, Show)
>>
>> -}
>>
>> instance Typeable ProcessStatus where
>>
>>typeOf = const tyCon_ProcessStatus
>>
>> tyCon_ProcessStatus = mkTyConApp (mkTyCon3 "hsshellscript"
>>
>>"HsShellScript.ProcErr"
>>
>>"Posix.ProcessStatus") []
>>
>> instance Exception ProcessStatus
>>
>> --
>>
>> Thanks,
>>
>> V.W.
>>
>> ___
>> 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

Re: Old code broken by new Typeable class

[Carter Schonwald]

i assume 7.6 and 7.8, if we're talking GHC rather than GCC :)

in 7.8 you can't define userland typeable instances, you need only write
deriving (Typeable) and you're all set.
add some CPP to select the instances suitable


On Tue, Aug 5, 2014 at 12:41 PM, Volker Wysk 
wrote:

>  Hi!
>
> I've been working with GHC-4.6.3, and updating to GHC-4.8.3 breaks my
> code,
>
> because the Typeable class has been changed. The compiler produces this
>
> message:
>
> -
>
> src/HsShellScript/ProcErr.chs:2294:4:
>
> ‘typeOf’ is not a (visible) method of class ‘Typeable’
>
> -
>
> I want to define System.Posix.Process.ProcessStatus to be an instance of
>
> Typeable, so I can throw and catch it as an exception. ProcessStatus isn't
>
> typeable by default.
>
> Is it still possible to make ProcessStatus a member of Typeable? How?
>
> Obviously, you can't accomplish it by deriving Typeable, because the
> definition
>
> can't be changed any longer.
>
> This is the spot in question:
>
> --
>
> import System.Posix.Process
>
> import Data.Typeable
>
> {-
>
> data ProcessStatus = Exited ExitCode
>
>| Terminated Signal
>
>| Stopped Signal
>
>deriving (Eq, Ord, Show)
>
> -}
>
> instance Typeable ProcessStatus where
>
>typeOf = const tyCon_ProcessStatus
>
> tyCon_ProcessStatus = mkTyConApp (mkTyCon3 "hsshellscript"
>
>"HsShellScript.ProcErr"
>
>"Posix.ProcessStatus") []
>
> instance Exception ProcessStatus
>
> --
>
> Thanks,
>
> V.W.
>
> ___
> 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

Re: Cross compiling for Cortex A9

[Carter Schonwald]

hrmmm, i seem to recall it being said that you need to use the GOLD linker
on ARM. (i think some of this is detailed in
http://bgamari.github.io/posts/2014-03-06-compiling-ghc-7.8-on-arm.html  )

 ,("ld command","arm-poky-linux-gnueabi-ld")
is that GOLD?


On Tue, Jul 8, 2014 at 1:51 AM, Michael Jones  wrote:

> I am pasting both the info from the HOST and TARGET compilers:
>
> HOST
> 
>
>  [("Project name","The Glorious Glasgow Haskell Compilation System")
>  ,("GCC extra via C opts"," -fwrapv")
>  ,("C compiler command","/usr/bin/gcc")
>  ,("C compiler flags"," -fno-stack-protector  -Wl,--hash-size=31
> -Wl,--reduce-memory-overheads")
>  ,("ar command","/usr/bin/ar")
>  ,("ar flags","q")
>  ,("ar supports at file","YES")
>  ,("touch command","touch")
>  ,("dllwrap command","/bin/false")
>  ,("windres command","/bin/false")
>  ,("perl command","/usr/bin/perl")
>  ,("target os","OSLinux")
>  ,("target arch","ArchX86_64")
>  ,("target word size","8")
>  ,("target has GNU nonexec stack","True")
>  ,("target has .ident directive","True")
>  ,("target has subsections via symbols","False")
>  ,("LLVM llc command","llc")
>  ,("LLVM opt command","opt")
>  ,("Project version","7.6.3")
>  ,("Booter version","7.6.3")
>  ,("Stage","2")
>  ,("Build platform","x86_64-unknown-linux")
>  ,("Host platform","x86_64-unknown-linux")
>  ,("Target platform","x86_64-unknown-linux")
>  ,("Have interpreter","YES")
>  ,("Object splitting supported","YES")
>  ,("Have native code generator","YES")
>  ,("Support SMP","YES")
>  ,("Unregisterised","NO")
>  ,("Tables next to code","YES")
>  ,("RTS ways","l debug  thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn
> thr_debug_dyn thr_debug_p")
>  ,("Leading underscore","NO")
>  ,("Debug on","False")
>  ,("LibDir","/usr/lib/ghc")
>  ,("Global Package DB","/usr/lib/ghc/package.conf.d")
>  ,("Gcc Linker
> flags","[\"-Wl,--hash-size=31\",\"-Wl,--reduce-memory-overheads\"]")
>  ,("Ld Linker flags","[\"--hash-size=31\",\"--reduce-memory-overheads\"]")
>  ]
>
>
> TARGET
> ===
>
>  [("Project name","The Glorious Glasgow Haskell Compilation System")
>  ,("GCC extra via C opts"," -fwrapv")
>  ,("C compiler command","arm-poky-linux-gnueabi-gcc")
>  ,("C compiler flags"," -fno-stack-protector")
>  ,("C compiler link flags","")
>  ,("ld command","arm-poky-linux-gnueabi-ld")
>  ,("ld flags","")
>  ,("ld supports compact unwind","YES")
>  ,("ld supports build-id","YES")
>  ,("ld supports filelist","NO")
>  ,("ld is GNU ld","YES")
>  ,("ar command","/usr/bin/ar")
>  ,("ar flags","q")
>  ,("ar supports at file","YES")
>  ,("touch command","touch")
>  ,("dllwrap command","/bin/false")
>  ,("windres command","/bin/false")
>  ,("libtool command","libtool")
>  ,("perl command","/usr/bin/perl")
>  ,("target os","OSLinux")
>  ,("target arch","ArchARM {armISA = ARMv5, armISAExt = [], armABI = HARD}")
>  ,("target word size","4")
>  ,("target has GNU nonexec stack","False")
>  ,("target has .ident directive","True")
>  ,("target has subsections via symbols","False")
>  ,("Unregisterised","NO")
>  ,("LLVM llc command","llc")
>  ,("LLVM opt command","opt")
>  ,("Project version","7.8.2")
>  ,("Booter version","7.6.3")
>  ,("Stage","1")
>  ,("Build platform","x86_64-unknown-linux")
>  ,("Host platform","x86_64-u

Re: Cross compiling for Cortex A9

[Carter Schonwald]

could you share the output of ghc --info?


On Tue, Jul 8, 2014 at 12:10 AM, Michael Jones  wrote:

> I am having problems building a GHC cross compiler for Linux (Yocto on a
> Wandboard) running on a Cortex A9, and need some advice on how to debug it.
>
> The cross compiler produces an executable that runs on the Target, but
> fails to print. So I need help coming up with a strategy to narrow down the
> root cause.
>
> Some details:
>
> The application:
>
> main = do
> putStrLn "Haskell start"
>
>
> The command line options work. The program runs, and I can step through
> assembly. Debug data is printed to the console. But putStrLn fails, and
> program enters an infinite loop.
>
> I compile my app as follows:
>
> arm-unknown-linux-gnueabi-ghc -debug -static Main.hs
>
> Using -threaded does not fix the problem.
>
> Let me compare debug data from a run on my HOST, with a run on my TARGET.
> First, a run from my HOST:
>
> created capset 0 of type 2
> created capset 1 of type 3
> cap 0: initialised
> assigned cap 0 to capset 0
> assigned cap 0 to capset 1
> cap 0: created thread 1
> cap 0: running thread 1 (ThreadRunGHC)
> cap 0: thread 1 stopped (suspended while making a foreign call)
> cap 0: running thread 1 (ThreadRunGHC)
> cap 0: thread 1 stopped (finished)
> cap 0: created thread 2
> cap 0: running thread 2 (ThreadRunGHC)
> cap 0: thread 2 stopped (finished)
> cap 0: starting GC
> cap 0: GC working
> cap 0: GC idle
> cap 0: GC done
> cap 0: GC idle
> cap 0: GC done
> cap 0: GC idle
> cap 0: GC done
> cap 0: GC idle
> cap 0: GC done
> cap 0: all caps stopped for GC
> cap 0: finished GC
> removed cap 0 from capset 0
> removed cap 0 from capset 1
> cap 0: shutting down
> deleted capset 0
> deleted capset 1
>
> And, it prints properly. So this is my referenced for what it should do on
> the TARGET.
>
> When I run on my TARGET, I get:
>
> created capset 0 of type 2
> created capset 1 of type 3
> cap 0: initialised
> assigned cap 0 to capset 0
> assigned cap 0 to capset 1
> cap 0: created thread 1
> cap 0: running thread 1 (ThreadRunGHC)
> cap 0: thread 1 stopped (yielding)
> cap 0: running thread 1 (ThreadRunGHC)
> cap 0: thread 1 stopped (yielding)
> cap 0: running thread 1 (ThreadRunGHC)
> cap 0: thread 1 stopped (yielding)
> cap 0: running thread 1 (ThreadRunGHC)
> cap 0: thread 1 stopped (yielding)
> cap 0: running thread 1 (ThreadRunGHC)
> cap 0: thread 1 stopped (yielding)
> cap 0: running thread 1 (ThreadRunGHC)
> cap 0: thread 1 stopped (yielding)
> cap 0: running thread 1 (ThreadRunGHC)
> cap 0: thread 1 stopped (stack overflow)
> cap 0: running thread 1 (ThreadRunGHC)
> cap 0: thread 1 stopped (stack overflow)
> cap 0: running thread 1 (ThreadRunGHC)
> cap 0: thread 1 stopped (stack overflow)
> cap 0: running thread 1 (ThreadRunGHC)
> cap 0: thread 1 stopped (yielding)
> cap 0: running thread 1 (ThreadRunGHC)
> cap 0: thread 1 stopped (stack overflow)
> cap 0: running thread 1 (ThreadRunGHC)
> cap 0: thread 1 stopped (stack overflow)
> cap 0: running thread 1 (ThreadRunGHC)
> cap 0: thread 1 stopped (stack overflow)
> cap 0: running thread 1 (ThreadRunGHC)
> cap 0: thread 1 stopped (yielding)
> cap 0: running thread 1 (ThreadRunGHC)
> cap 0: thread 1 stopped (stack overflow)
> cap 0: running thread 1 (ThreadRunGHC)
> cap 0: thread 1 stopped (heap overflow)
> cap 0: starting GC
> cap 0: GC working
> cap 0: GC idle
> cap 0: GC done
> cap 0: GC idle
> cap 0: GC done
> cap 0: GC idle
> cap 0: GC done
> cap 0: all caps stopped for GC
> cap 0: finished GC
> cap 0: running thread 1 (ThreadRunGHC)
> cap 0: thread 1 stopped (yielding)
> cap 0: running thread 1 (ThreadRunGHC)
> cap 0: thread 1 stopped (stack overflow)
> ...
>
> And the debug data goes on forever, just as debugging assembly
> demonstrated an infinite loop.
>
> Clearly, the following does not occur:
>
> cap 0: thread 1 stopped (suspended while making a foreign call)
>
> And there are overflows.
>
> If I had to guess, it is possible that some code is in a loop retrying to
> foreign call, and failing. Certainly, it is in some kind of a loop, because
> I found a place I can put a break point and and telling GDB to continue
> will cause the break over and over at the same place. So somewhere there is
> a loop.
>
> I can step through the application with GDB and see names of files and
> offsets in assembly. But without a true source code debug, that is a bit
> rough, especially for someone that does not know the RTS code. If there was
> a way to compile such that C source code was available and a place to
> break, that would help. However, I suspect since it never makes a foreign
> call, there is no place in C to place the breakpoint anyway. So I am also
> assuming there is no direct way to debug with GDB.
>
> But, I can see debug output printed to the console. My hope is there is a
> way to enable more printing, or a place I can add more print functions to
> help find the problem.
>
> So I think I need one of the following:
>
> - A solution fr

Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?

[Carter Schonwald]

does JHC support template haskell?


On Sat, Jul 5, 2014 at 12:02 PM, Scott Turner <2hask...@pkturner.org> wrote:

> It installed and worked on my Nexus 5.
>
> On 2014-07-04 00:43, Dominick Samperi wrote:
> > Hello John,
> > I tried to install the Haskell demo Cube on my Nexus 7
> > and got: Error: package file was not signed correctly.
> > D
> >
> > On Thu, Jul 3, 2014 at 4:47 PM, John Meacham  wrote:
> >> In case anyone wanted to start writing haskell android code now, jhc
> >> fully supports android as a target. here is an app made with it
> >>
> >>
> https://play.google.com/store/apps/details?id=org.metasepi.ajhc.android.cube
> >>
> >> this was made with Kiwamu's ajhc branch but code has been merged back
> >> into the main tree.
> >>
> >> On Wed, Jul 2, 2014 at 5:54 PM, Carter Schonwald
> >>  wrote:
> >>> This would probably be a great boon for those trying to use haskell for
> >>> Android and IOS right? how might the emulation setup work for those?
> >>>
> >>>
> >>>
> >>>
> >>> On Wed, Jul 2, 2014 at 2:20 PM, Carter Schonwald
> >>>  wrote:
> >>>> wow, this is great work!
> >>>>
> >>>> If theres a clear path to getting the generic tooling into 7.10, i'm
> all
> >>>> for it :) (and willing to help on concrete mechanical subtasks)
> >>>>
> >>>>
> >>>> On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman 
> >>>> wrote:
> >>>>> hi all,
> >>>>>
> >>>>> I've added some code [1] [2] to GHCJS to make it run Template Haskell
> >>>>> code on node.js, rather than using the GHC linker. GHCJS has
> supported TH
> >>>>> for a long time now, but so far always relied on native (host) code
> for it.
> >>>>> This is the main reason that GHCJS always builds native and
> JavaScript code
> >>>>> for everything (another is that Cabal Setup.hs scripts need to be
> compiled
> >>>>> to some host-runnable form, but that can also be JavaScript if you
> have
> >>>>> node.js)
> >>>>>
> >>>>> Now besides the compiler having to do twice the work, this has some
> other
> >>>>> disadvantages:
> >>>>>
> >>>>> - Our JavaScript code has the same dependencies (packages) as native
> >>>>> code, which means packages like unix or Win32 show up somewhere,
> depending
> >>>>> on the host environment. This also limits our options in choosing
> >>>>> JS-specific packages.
> >>>>> - The Template Haskell code runs on the host environment, which
> might be
> >>>>> slightly different from the target, for example in integer size or
> operating
> >>>>> system specific constants.
> >>>>>
> >>>>> Moreover, building native code made the GHCJS installation procedure
> more
> >>>>> tricky, making end users think about libgmp or libiconv locations,
> since it
> >>>>> basically required the same preparation as building GHC from source.
> This
> >>>>> change will make installing much easier and more reliable (we still
> have to
> >>>>> update the build scripts).
> >>>>>
> >>>>> How it works is pretty simple:
> >>>>>
> >>>>> - When any code needs to be run on the target (hscCompileCoreExpr,
> >>>>> through the Hooks API new in GHC 7.8), GHCJS starts a node.js
> process with
> >>>>> the thrunner.js [3] script,
> >>>>> - GHCJS sends its RTS and the Template Haskell server code [1] to
> >>>>> node.js, the script starts a Haskell thread running the server,
> >>>>> - for every splice, GHCJS compiles it to JavaScript and links it
> using
> >>>>> its incremental linking functionality. The code for the splice,
> including
> >>>>> dependencies that have not yet been sent to the runner (for earlier
> >>>>> splices), is then sent in a RunTH [4] message,
> >>>>> - the runner loads and runs the code in the Q monad, can send
> queries to
> >>>>> GHCJS for reification,
> >>>>> - the runner sends back the result as a serialized Template Haskell
> AST
> >>>>> (using GHC.Generics for the Binary instances).
> >

Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?

[Carter Schonwald]

This would probably be a great boon for those trying to use haskell for
Android and IOS right? how might the emulation setup work for those?




On Wed, Jul 2, 2014 at 2:20 PM, Carter Schonwald  wrote:

> wow, this is great work!
>
> If theres a clear path to getting the generic tooling into 7.10, i'm all
> for it :) (and willing to help on concrete mechanical subtasks)
>
>
> On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman 
> wrote:
>
>> hi all,
>>
>> I've added some code [1] [2] to GHCJS to make it run Template Haskell
>> code on node.js, rather than using the GHC linker. GHCJS has supported TH
>> for a long time now, but so far always relied on native (host) code for it.
>> This is the main reason that GHCJS always builds native and JavaScript code
>> for everything (another is that Cabal Setup.hs scripts need to be compiled
>> to some host-runnable form, but that can also be JavaScript if you have
>> node.js)
>>
>> Now besides the compiler having to do twice the work, this has some other
>> disadvantages:
>>
>> - Our JavaScript code has the same dependencies (packages) as native
>> code, which means packages like unix or Win32 show up somewhere, depending
>> on the host environment. This also limits our options in choosing
>> JS-specific packages.
>> - The Template Haskell code runs on the host environment, which might be
>> slightly different from the target, for example in integer size or
>> operating system specific constants.
>>
>> Moreover, building native code made the GHCJS installation procedure more
>> tricky, making end users think about libgmp or libiconv locations, since it
>> basically required the same preparation as building GHC from source. This
>> change will make installing much easier and more reliable (we still have to
>> update the build scripts).
>>
>> How it works is pretty simple:
>>
>> - When any code needs to be run on the target (hscCompileCoreExpr,
>> through the Hooks API new in GHC 7.8), GHCJS starts a node.js process with
>> the thrunner.js [3] script,
>> - GHCJS sends its RTS and the Template Haskell server code [1] to
>> node.js, the script starts a Haskell thread running the server,
>> - for every splice, GHCJS compiles it to JavaScript and links it using
>> its incremental linking functionality. The code for the splice, including
>> dependencies that have not yet been sent to the runner (for earlier
>> splices), is then sent in a RunTH [4] message,
>> - the runner loads and runs the code in the Q monad, can send queries to
>> GHCJS for reification,
>> - the runner sends back the result as a serialized Template Haskell AST
>> (using GHC.Generics for the Binary instances).
>>
>> All Template Haskell functionality is supported, including recent
>> additions for reifying modules and annotations. I still need to clean up
>> and push the patches for the directory and process packages, but after
>> that, the TH code can read/write files, run processes and interact with
>> them and make network connections, all through node.js.
>>
>> Now since this approach is in no way specific to JavaScript, I was
>> wondering if there's any interest in getting this functionality into GHC
>> 7.10 for general cross compilation. The runner would be a native (target)
>> program with dynamic libraries (or object files) being sent over to the
>> target machine (or emulator) for the splices.
>>
>> Thanks to Andras Slemmer from Prezi who helped build the initial proof of
>> concept (without reification) at BudHac.
>>
>> cheers,
>>
>> Luite
>>
>> [1]
>> https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/src/Gen2/TH.hs
>> [2]
>> https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Eval.hs
>> [3]
>> https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/lib/etc/thrunner.js
>> [4]
>> https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Types.hs#L29
>>
>> ___
>> 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

Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?

[Carter Schonwald]

wow, this is great work!

If theres a clear path to getting the generic tooling into 7.10, i'm all
for it :) (and willing to help on concrete mechanical subtasks)


On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman  wrote:

> hi all,
>
> I've added some code [1] [2] to GHCJS to make it run Template Haskell code
> on node.js, rather than using the GHC linker. GHCJS has supported TH for a
> long time now, but so far always relied on native (host) code for it. This
> is the main reason that GHCJS always builds native and JavaScript code for
> everything (another is that Cabal Setup.hs scripts need to be compiled to
> some host-runnable form, but that can also be JavaScript if you have
> node.js)
>
> Now besides the compiler having to do twice the work, this has some other
> disadvantages:
>
> - Our JavaScript code has the same dependencies (packages) as native code,
> which means packages like unix or Win32 show up somewhere, depending on the
> host environment. This also limits our options in choosing JS-specific
> packages.
> - The Template Haskell code runs on the host environment, which might be
> slightly different from the target, for example in integer size or
> operating system specific constants.
>
> Moreover, building native code made the GHCJS installation procedure more
> tricky, making end users think about libgmp or libiconv locations, since it
> basically required the same preparation as building GHC from source. This
> change will make installing much easier and more reliable (we still have to
> update the build scripts).
>
> How it works is pretty simple:
>
> - When any code needs to be run on the target (hscCompileCoreExpr, through
> the Hooks API new in GHC 7.8), GHCJS starts a node.js process with the
> thrunner.js [3] script,
> - GHCJS sends its RTS and the Template Haskell server code [1] to node.js,
> the script starts a Haskell thread running the server,
> - for every splice, GHCJS compiles it to JavaScript and links it using its
> incremental linking functionality. The code for the splice, including
> dependencies that have not yet been sent to the runner (for earlier
> splices), is then sent in a RunTH [4] message,
> - the runner loads and runs the code in the Q monad, can send queries to
> GHCJS for reification,
> - the runner sends back the result as a serialized Template Haskell AST
> (using GHC.Generics for the Binary instances).
>
> All Template Haskell functionality is supported, including recent
> additions for reifying modules and annotations. I still need to clean up
> and push the patches for the directory and process packages, but after
> that, the TH code can read/write files, run processes and interact with
> them and make network connections, all through node.js.
>
> Now since this approach is in no way specific to JavaScript, I was
> wondering if there's any interest in getting this functionality into GHC
> 7.10 for general cross compilation. The runner would be a native (target)
> program with dynamic libraries (or object files) being sent over to the
> target machine (or emulator) for the splices.
>
> Thanks to Andras Slemmer from Prezi who helped build the initial proof of
> concept (without reification) at BudHac.
>
> cheers,
>
> Luite
>
> [1]
> https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/src/Gen2/TH.hs
> [2]
> https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Eval.hs
> [3]
> https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/lib/etc/thrunner.js
> [4]
> https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Types.hs#L29
>
> ___
> 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

Re: vector and GeneralizedNewtypeDeriving

[Carter Schonwald]

this is an issue i'll be running into shortly, otoh I don't think many
folks are writing new unboxed vector instances and related engineering :)


On Wed, May 14, 2014 at 10:02 PM, John Lato  wrote:

> Hi Richard,
>
> Thanks for pointing me to the ticket; I agree that's the issue (although
> I'm glad to have you and Simon confirm it).  I've summarized the issue and
> raised the priority, and Simon linked to this thread.
>
> I would have expected this would have affected a lot users, but as I
> haven't heard many complaints (and nobody else said anything here!) maybe
> the impact is smaller than I thought.
>
> Thanks,
> John
>
>
> On Wed, May 14, 2014 at 6:02 AM, Richard Eisenberg wrote:
>
>> Is this an instance of https://ghc.haskell.org/trac/ghc/ticket/8177 ? I
>> think so.
>>
>> The problem boils down to the fact that Vector and MVector are data
>> families and are thus (currently) exempted from the roles mechanism. (Or,
>> more properly, may *only* have nominal roles.) There is no technical reason
>> for this restriction. It's just that the feature would take a few solid
>> days of work to implement and I wasn't aware of a concrete use case.
>>
>> Here is such a use case.
>>
>> If you agree that you've hit #8177, please post to that bug report and
>> raise the priority to High -- being able to coerce Vectors seems very
>> reasonable indeed, and we should support it. I doubt the feature will land
>> in 7.8.3 (depending on the timeline for that release), but I'll get to it
>> eventually. (Or, if you feel this is more critical in the larger picture,
>> shout more loudly on the ticket and perhaps I can squeeze it in before
>> 7.8.3.)
>>
>> Thanks,
>> Richard
>>
>> On May 13, 2014, at 9:39 PM, John Lato  wrote:
>>
>> Hello,
>>
>> Prior to ghc-7.8, it was possible to do this:
>>
>> > module M where
>> >
>> > import qualified Data.Vector.Generic.Base as G
>> > import qualified Data.Vector.Generic.Mutable as M
>> > import Data.Vector.Unboxed.Base -- provides MVector and Vector
>> >
>> > newtype Foo = Foo Int deriving (Eq, Show, Num,
>> > M.MVector MVector, G.Vector Vector, Unbox)
>>
>> M.MVector is defined as
>>
>> > class MVector v a where
>> > basicLength :: v s a -> Int
>> etc.
>>
>> With ghc-7.8 this no longer compiles due to an unsafe coercion, as
>> MVector s Foo and MVector s Int have different types.  The error suggests
>> trying -XStandaloneDeriving to manually specify the context, however I
>> don't see any way that will help in this case.
>>
>> For that matter, I don't see any way to fix this in the vector package
>> either.  We might think to define
>>
>> > type role M.MVector nominal representational
>>
>> but that doesn't work as both parameters to M.MVector require a nominal
>> role (and it's probably not what we really want anyway).  Furthermore
>> Data.Vector.Unboxed.Base.MVector (which fills in at `v` in the instance) is
>> a data family, so we're stuck at that point also.
>>
>> So given this situation, is there any way to automatically derive Vector
>> instances from newtypes?
>>
>> tl;dr: I would really like to be able to do:
>>
>> > coerce (someVector :: Vector Foo) :: Vector Int
>>
>> am I correct that the current machinery isn't up to handling this?
>>
>> Thanks,
>> John
>> ___
>> 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
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: vector and GeneralizedNewtypeDeriving

[Carter Schonwald]

can you get the deriving to work on
a newtype instance MVector s Foo = 
?


On Tue, May 13, 2014 at 9:39 PM, John Lato  wrote:

> Hello,
>
> Prior to ghc-7.8, it was possible to do this:
>
> > module M where
> >
> > import qualified Data.Vector.Generic.Base as G
> > import qualified Data.Vector.Generic.Mutable as M
> > import Data.Vector.Unboxed.Base -- provides MVector and Vector
> >
> > newtype Foo = Foo Int deriving (Eq, Show, Num,
> > M.MVector MVector, G.Vector Vector, Unbox)
>
> M.MVector is defined as
>
> > class MVector v a where
> > basicLength :: v s a -> Int
> etc.
>
> With ghc-7.8 this no longer compiles due to an unsafe coercion, as MVector
> s Foo and MVector s Int have different types.  The error suggests trying
> -XStandaloneDeriving to manually specify the context, however I don't see
> any way that will help in this case.
>
> For that matter, I don't see any way to fix this in the vector package
> either.  We might think to define
>
> > type role M.MVector nominal representational
>
> but that doesn't work as both parameters to M.MVector require a nominal
> role (and it's probably not what we really want anyway).  Furthermore
> Data.Vector.Unboxed.Base.MVector (which fills in at `v` in the instance) is
> a data family, so we're stuck at that point also.
>
> So given this situation, is there any way to automatically derive Vector
> instances from newtypes?
>
> tl;dr: I would really like to be able to do:
>
> > coerce (someVector :: Vector Foo) :: Vector Int
>
> am I correct that the current machinery isn't up to handling this?
>
> Thanks,
> John
>
> ___
> 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

Re: Using mutable array after an unsafeFreezeArray, and GC details

[Carter Schonwald]

true enough


On Fri, May 9, 2014 at 7:55 PM, Edward Z. Yang  wrote:

> Excerpts from Carter Schonwald's message of 2014-05-09 16:49:07 -0700:
> > Any chance you could try to use storable or unboxed vectors?
>
> Neither of those will work if, at the end of the day, you need to
> store pointers to heap objects
>
> Edward
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Using mutable array after an unsafeFreezeArray, and GC details

[Carter Schonwald]

Any chance you could try to use storable or unboxed vectors?

On Friday, May 9, 2014, Brandon Simmons  wrote:

>
> On May 9, 2014 5:13 PM, "Edward Z. Yang" 
> >
> wrote:
> >
> > Hello Brandon,
> >
> > Excerpts from Brandon Simmons's message of 2014-05-08 16:18:48 -0700:
> > > I have an unusual application with some unusual performance problems
> > > and I'm trying to understand how I might use unsafeFreezeArray to help
> > > me, as well as understand in detail what's going on with boxed mutable
> > > arrays and GC. I'm using the interface from 'primitive' below.
> > >
> > > First some basic questions, then a bit more background
> > >
> > > 1) What happens when I do `newArray s x >>= \a-> unsafeFreezeArray a
> > > >> return a` and then use `a`? What problems could that cause?
> >
> > Your code as written wouldn't compile, but assuming you're talking about
> > the primops newArray# and unsafeFreezeArray#, what this operation does
> > is allocate a new array of pointers (initially recorded as mutable), and
> > then freezes it in-place (by changing the info-table associated with
> > it), but while maintaining a pointer to the original mutable array.
>  Nothing bad
> > will happen immediately, but if you use this mutable reference to mutate
> > the pointer array, you can cause a crash (in particular, if the array
> > makes it to the old generation, it will not be on the mutable list and
> > so if you mutate it, you may be missing roots.)
> >
> > > 2) And what if a do a `cloneMutableArray` on `a` and likewise use the
> > > resulting array?
> >
> > If you do the clone before freezing, that's fine for all use-cases;
> > if you do the clone after, you will end up with the same result as (1).
> >
> > > Background: I've been looking into an issue [1] in a library in which
> > > as more mutable arrays are allocated, GC dominates (I think I verified
> > > this?) and all code gets slower in proportion to the number of mutable
> > > arrays that are hanging around.
> > >
> > > I've been trying to understand how this is working internally. I don't
> > > quite understand how the "remembered set" works with respect to
> > > MutableArray. As best I understand: the remembered set in generation G
> > > points to certain objects in older generations, which objects hold
> > > references to objects in G. Then for MutableArrays specifically,
> > > card-marking is used to mark regions of the array with garbage in some
> > > way.
> > >
> > > So my hypothesis is the slowdown is associated with the size of the
> > > remembered set, and whatever the GC has to do on it. And in my tests,
> > > freezing the array seems to make that overhead (at least the overhead
> > > proportional to number of arrays) disappear.
> >
> > You're basically correct.  In the current GC design, mutable arrays of
> > pointers are always placed on the mutable list.  The mutable list of
> > generations which are not being collected are always traversed; thus,
> > the number of pointer arrays corresponds to a linear overhead for minor
> GCs.
> >
> > Here is a feature request tracking many of the infelicities that our
> > current GC design has:  https://ghc.haskell.org/trac/ghc/ticket/7662
> > The upshot is that the Haskell GC is very nicely tuned for mostly
> > immutable workloads, but there are some bad asymptotics when your
> > heap has lots of mutable objects.  This is generally a hard problem:
> > tuned GC implementations for mutable languages are a lot of work!
> > (Just ask the JVM implementors.)
> >
>
> Very helpful, thanks! And take some internet points.
>
> > > Now I'm really lost in the woods though. My hope is that I might be
> > > able to safely use unsafeFreezeArray to help me here [3]. Here are the
> > > particulars of how I use MutableArray in my algorithm, which are
> > > somewhat unusual:
> > >   - keep around a small template `MutableArray Nothing`
> > >   - use cloneMutableArray for fast allocation of new arrays
> > >   - for each array only a *single* write (CAS actually) happens at
> each position
> > >
> > > In fact as far as I can reason, there ought to be no garbage to
> > > collect at all until the entire array becomes garbage (the initial
> > > value is surely shared, especially since I'm keeping this template
> > > array around to clone from, right?). In fact I was even playing with
> > > the idea of rolling a new CAS that skips the card-marking stuff.
> >
> > I don't understand your full workload, but if you have a workload that
> > involves creating an array, mutating it over a short period of time,
> > and then never mutating it afterwards, you should simply freeze it after
> > you are done writing it.  Once frozen, the array will no longer be kept
> > on the mutable list and you won't pay for it when doing GC.  However,
> > the fact that you are doing a CAS makes it seem to me that your workflow
> > may be more complicated than that...
>
> Yes I think for my use case the overhead required to determine when the
> array can be frozen wo

Re: RFC: include a cabal-install executable in future GHC releases

[Carter Schonwald]

I think there's now hosted official cabal install binaries online.  I'm Afk
but they should be a short google away. Should be linked more prominently
though

On Saturday, May 3, 2014, Ashley Yakeley  wrote:

> So I want to install GHC + cabal on a new system, building cabal packages
> with profiling and documentation. Here's what I have to do:
>
> 1. Download, unpack and install GHC.
>
> 2. Download and unpack cabal-install, and run bootstrap.sh. As part of the
> bootstrap, it will download and build a bunch of packages.
>
> 3. Delete the downloaded packages ("rm -rf ~/.ghc/*") because they were
> built without profiling or documentation.
>
> 4. Call "cabal update" to get a default .cabal/config file.
>
> 5. Edit .cabal/config to switch on library-profiling,
> executable-profiling, and documentation.
>
> 6. Build my stuff.
>
> This would be much simplified if binary versions of cabal-install were
> available. (It would be even simpler if they were just included in the GHC
> builds -- I could eliminate 2 & 3.)
>
> -- Ashley Yakeley
> ___
> 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

Re: how to compile non-dynamic ghc-7.8.2 ?

[Carter Schonwald]

@john, what version of cabal-install were you using? (i realize you're
probably using the right one, but worth asking :) )


On Fri, Apr 25, 2014 at 12:25 PM, John Lato  wrote:

>
> On Apr 25, 2014 5:36 AM, "Bertram Felgenhauer" <
> bertram.felgenha...@googlemail.com> wrote:
> >
> > John Lato wrote:
> > > I'd like to compile ghc-7.8.2 with DynamicGhcPrograms disabled (on
> 64-bit
> > > linux).  I downloaded the source tarball, added
> > >
> > > DYNAMIC_GHC_PROGRAMS = NO
> >
> > I've had success with setting both
> >
> > DYNAMIC_BY_DEFAULT   = NO
> > DYNAMIC_GHC_PROGRAMS = NO
> >
> > and removing the 'dyn' way altogether from GhcLibWays by setting
> > GhcLibWays = v explicitely. I expect that the latter is optional;
> > my goal was only to speed up the build.
> >
> > (The lines were copied from the perf-cross settings.)
>
> I tried disabling dynamicByDefault also, but that didn't help. It may be a
> problem with lib ways though, I'll try that.
>
> Thanks, John
>
> > Cheers,
> >
> > Bertram
> > ___
> > 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
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: 7.8.1 cabal install of vector package (dependent on primitive package) fails

[Carter Schonwald]

i bet you have cabal --version reply with  1.16 :)

1) cabal update
2) cabal install cabal-install
3) rm ~/.cabal/config # old pre 1.18 config should go!
4) cabal update # also probably add ~/.cabal/bin to path
5)  cabal install vector



On Wed, Apr 9, 2014 at 11:24 PM, Vivian McPhail <
haskell.vivian.mcph...@gmail.com> wrote:

> Hi,
>
> Ubuntu 12.04, 64 bit x86, ghc 7.8.1 gives the following:
>
> # cabal install --global vector
> ...
> [ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic (
> Data/Vector/Fusion/Stream/Monadic.hs,
> dist/build/Data/Vector/Fusion/Stream/Monadic.o )
> Loading package ghc-prim ... linking ... done.
> Loading package integer-gmp ... linking ... done.
> Loading package base ... linking ... done.
> Loading package primitive-0.5.2.1 ... : can't load .so/.DLL
> for: libHSprimitive-0.5.2.1.so (libHSprimitive-0.5.2.1.so: cannot open
> shared object file: No such file or directory)
> cabal: Error: some packages failed to install:
> vector-0.10.9.1 failed during the building phase. The exception was:
> ExitFailure 1
>
> Cheers,
>
> Vivian
>
>
> ___
> 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

Re: Buildbots

[Carter Schonwald]

good to know (i assumed it was in working order from your remarks)

I think making it more surfaced / discoverable might enable a lot more
volunteer build bots (which is an issue aside from maintaining it)

of course, officially moving it to github should be with ian's blessing,
its mostly his work afaik :)


On Tue, Apr 1, 2014 at 2:45 PM, Páli Gábor János wrote:

> 2014-04-01 20:15 GMT+02:00 Alain O'Dea :
> > until we are certain it is fully working again.
>
> In what sense?  I have been using the latest checkout from the darcs
> repository for both the server and the clients, I seldom experienced
> any serious problems.  Of course, there is place for improvements and
> there are some rough edges, but I think it is quite usable, even in
> its current state.
> ___
> ghc-devs mailing list
> ghc-d...@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Buildbots

[Carter Schonwald]

hey all, I just exported the igloo builder code from darcs to git, and put
it here https://github.com/cartazio/ghc-builder
would this be something worth adding to github.com/haskell  ? (i can easily
add it if other folks it should be surfaced more visibly)


On Tue, Apr 1, 2014 at 11:04 AM, Páli Gábor János wrote:

> 2014-04-01 14:03 GMT+02:00 Simon Peyton Jones :
> > Indeed, there is no reason not to use Ian et al's Builder stuff.  It's
> one of the
> > options.  But it depends on a critical evaluation of what the advantages
> and
> > disadvantages of different approaches are
>
> I found Ian's buildbot an appealing alternative as it does a full
> build, including testing, and uploads the resulting binaries to a
> common place where anybody can access them (but it can be configured
> to do almost anything).  The builders may be configured individually
> from a single (Haskell-language) configuration file and they are run
> on various volunteer-supplied systems so it is also distributed.
>
> I use this to keep track of the status of the FreeBSD builds to make
> my work easier on building the releases and maintaining the associated
> ports in the FreeBSD Ports Collection, while offering regular
> developer snapshots for the users.  This approach also allows me to
> control and maintain the builder environment too as it may require
> minor or major changes and fixes over time that I can do myself as a
> FreeBSD developer.  In the past, there were cases where the build was
> failing due to bugs in the kernel or the userland, so this is not
> purely about GHC itself (unfortunately).
>
> In my humble opinon, there are merits for the Travis-based Continuous
> Integration, so as for the daily snapshot building on each supported
> platform.  I do not care if it is not Haskell-based or it is hosted at
> a central place with individual Virtual Machines for each platform --
> until I can keep doing what I have been doing for 4 years now.
> ___
> ghc-devs mailing list
> ghc-d...@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users