On Thu, 2016-07-21 at 14:38 -0400, Richard Eisenberg wrote:
> >
> > On Jul 21, 2016, at 2:25 PM, Yuras Shumovich
> > wrote:
> >
> > It is hopeless. Haskell2020 will not include TemplateHaskell,
> > GADTs,
> > etc.
>
> Why do you say this? I don&
On Thu, 2016-07-21 at 13:25 -0400, Richard Eisenberg wrote:
> >
> > On Jul 21, 2016, at 11:29 AM, Yuras Shumovich > > wrote:
> >
> > Unfortunately Haskell *is* implementation-defined language. You
> > can't
> > compile any nontrivial package fr
On Thu, 2016-07-21 at 10:32 -0400, Gershom B wrote:
> On July 21, 2016 at 8:51:15 AM, Yuras Shumovich (shumovi...@gmail.com
> ) wrote:
> >
> > I think it is what the process should change. It makes sense to
> > have
> > two committees only if we have multiple lan
On Wed, 2016-07-20 at 18:37 +0200, 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
Looks like reddit is a wrong place, so I'm replicating my comment here:
On Wed, 2016-07-20 at 11:36 +0200, Ben Gamari wrote:
> Hello everyone,
>
> As you hopefully know, a few weeks ago we proposed a new process [1]
> for
> collecting, discussing, and deciding upon changes to GHC and its
> Haske
On Sat, 2015-03-07 at 22:18 +1100, Sean Seefried wrote:
> Hi all,
>
> Can anyone explain the following problem I'm having?
>
> I'm currently writing a game in Haskell. When I produce a plain old
> executable (for local testing) it's about 23M. However, when I create a
> static lib using the -stat
It seems to be an instance of
https://ghc.haskell.org/trac/ghc/ticket/7869
But it is fixed (both in HEAD and 7.8). Probably the fix is partial?
On Thu, 2014-12-04 at 14:53 -0500, Richard Eisenberg wrote:
> This seems straightforwardly to be a bug, to me. HEAD gives the same behavior
> you report
On Wed, 2014-10-22 at 13:48 +0300, Yitzchak Gale wrote:
> In order support some older software that we released, we need
> to get a working GHC 7.4.2 on Ubuntu Trusty. We currently have
> GHC 7.8.3.
>
> The binary tarball for GHC 7.4.2 does not install on Trusty due to
> multiple incompatibilities
Hello,
It is recommended to checkout 7.8 in special way, see
https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources#checkout-old-branch
That is because repo structure was changed after 7.8
Thanks,
Yuras
13 Окт 2014 г. 4:03 пользователь "Magicloud Magiclouds" <
magicloud.magiclo...@gmai
On Thu, 2014-04-10 at 18:49 +0200, Karel Gardas wrote:
> On 04/10/14 06:39 PM, Yuras Shumovich wrote:
> > ...and other linker options must come after, like in my case. So what?
> > Are there any ticket where people complain about the old behavior? I'm
> > not advocating
On Thu, 2014-04-10 at 12:13 -0400, Brandon Allbery wrote:
> On Thu, Apr 10, 2014 at 12:02 PM, Yuras Shumovich wrote:
>
> > On Thu, 2014-04-10 at 11:54 -0400, Brandon Allbery wrote:
> > > On Thu, Apr 10, 2014 at 11:44 AM, Yuras Shumovich > >wrote:
>
On Thu, 2014-04-10 at 11:54 -0400, Brandon Allbery wrote:
> On Thu, Apr 10, 2014 at 11:44 AM, Yuras Shumovich wrote:
>
> > ghc-7.6.3 passes additional linker options after all the haskell object
> > files, while ghc-7.8.1 does the opposite.
>
> (...)
>
&
Hi,
I found that -optl behavior was changed in ghc-7.8.1
ghc-7.6.3 passes additional linker options after all the haskell object
files, while ghc-7.8.1 does the opposite.
$ /opt/ghc-7.6.3/bin/ghc --make main.hs -optl=hello -v
...
'/usr/bin/gcc' '-fno-stack-protector' '-Wl,--hash-size=31'
'-Wl,-
On Thu, 2012-12-13 at 09:41 +, Chris Nicholls wrote:
> What's the best way to get started? Bug fixes? Writing a toy plugin? I
> don't have a huge amount of time to offer, but I would like to learn to
> help!
>
GHC bug sweep is the way I'm trying to start with:
http://hackage.haskell.org/trac
On Mon, 2012-12-10 at 10:58 +, Simon Marlow wrote:
> On 08/12/12 23:12, Yuras Shumovich wrote:
> > I tried to hack stg_putMVarzh directly:
> >
> > if (enabled_capabilities == 1) {
> > info = GET_INFO(mvar);
> > } else {
> > (&q
Hi,
I'm working on that issue as an exercise/playground while studding the
GHC internals: http://hackage.haskell.org/trac/ghc/ticket/693
First I tried just to replace "ccall lockClosure(mvar "ptr")" with
GET_INFO(mvar) in stg_takeMVarzh and stg_putMVarzh and got 60% speedup
(see the test case at
16 matches
Mail list logo