Thanks everyone for the help!
I'm working now on reproducing this with HEAD, and if I do, I'll write a
ticket. On the other hand, it only seems to be an issue when one is
recompiling a file within one second of the first attempt, and Felipe's
workaround of deleting the .hi and .o files fixes it e
On Tue, Oct 4, 2011 at 5:32 PM, Felipe Almeida Lessa
wrote:
> This may have something to do with timestamps on the files. I cannot
> reproduce the error with
>
> $ while ./T; do sleep 1; done
> ...
>
> However, I *am* able to reproduce the error with
>
> $ while ./T ; do sleep 0.9; done
> Jus
Here's a version with fewer flags/features, that acts the same.
I tried removing the loading of an external module, and that did *not*
exhibit the problem. It also does *not* fail when the file name is
different each time, so the fact that it's the same file, A.hs, each
time is somehow part of th
This may have something to do with timestamps on the files. I cannot
reproduce the error with
$ while ./T; do sleep 1; done
...
However, I *am* able to reproduce the error with
$ while ./T ; do sleep 0.9; done
Just 42
Just 42
Just 42
Just 42
Just 42
T: mkTopLevEnv: not interpr
Here's a test case: the complete source code is in the following. I
compile it with:
ghc -package ghc --make Test.hs
The GHC version is
cdsmith@godel:~$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.2.1
Then run the application several times in a row. If
Yitzchak Gale wrote:
> Roman Leshchinskiy wrote:
>> In general, if we are going to overload list literals then forcing the
>> desugaring to always go through lists seems wrong to me. There are
>> plenty
>> of data structures where that might result in a significant performance
>> hit.
>
> These are
On Fri, Sep 30, 2011 at 7:28 PM, George Giorgidze wrote:
> GHC Users,
>
> I would like to make to the following two proposals:
> * Eliminate the default grouping close from SQL-like comprehensions
> * Introduce a GHC extension for list literal overloading
>
> OK, let me start with the first prop
2011/10/4 Gábor Lehel :
> On Tue, Oct 4, 2011 at 3:25 PM, Yitzchak Gale wrote:
>> George Giorgidze wrote:
>>> My second proposal is to introduce the
>>> OverloadedLists extension that overloads
>>> list literals...
>>
>> I am opposed to this proposal as stated.
>>
>> But I think that with a modifi
On Tue, Oct 4, 2011 at 3:25 PM, Yitzchak Gale wrote:
> George Giorgidze wrote:
>> My second proposal is to introduce the
>> OverloadedLists extension that overloads
>> list literals...
>
> I am opposed to this proposal as stated.
>
> But I think that with a modification,
> it can not only be impro
Just anecdotally I remember we had this problem with Accelerate.
Back when we were using it last Spring for some reason we were forced by the
API to at least nominally go through lists on our way to the GPU -- which we
sorely hoped were deforested! At times (and somewhat unpredictably), we'd
be f
Roman Leshchinskiy wrote:
> In general, if we are going to overload list literals then forcing the
> desugaring to always go through lists seems wrong to me. There are plenty
> of data structures where that might result in a significant performance
> hit.
These are literals. So the lists will almo
George Giorgidze wrote:
>
> This extension could also be used for giving data-parallel array literals
> instead of the special syntax used currently.
Unfortunately, it couldn't. DPH array literals don't (and can't really) go
through lists.
In general, if we are going to overload list literals the
Hi,
Am Donnerstag, den 29.09.2011, 11:39 +0100 schrieb Simon Marlow:
> > I’m not sure if I got your conclusion: Do you expect problems if the RTS
> > and libraries were built against different versions of libffi, or not?
> To answer your question: yes I would expect problems.
Thanks for your as
George Giorgidze wrote:
> My second proposal is to introduce the
> OverloadedLists extension that overloads
> list literals...
I am opposed to this proposal as stated.
But I think that with a modification,
it can not only be improved, but also solve
the problems with the current OverloadedStrings
I like both George's proposals.
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of George Giorgidze
| Sent: 30 September 2011 18:28
| To: glasgow-haskell-users@haskell.org
| Subject: Two Proposals
| I will work on building a smaller complete test case that reproduces the
| issue, and I could have done a better job of at least pointing out the
| relevant code for you. Sorry about that.
I'm afraid I still can't guess what's happening. It'd be really helpful if you
could build a smaller test
Combining lambdas makes a big difference in GHC. For example
f = \x. let y = E in \z. BODY
The function f takes one argument, and returns a heap-allocated lambda. If E
is cheap (say just a constructor) it might well be more efficient to transform
to
f = \xz. let y = E in BODY
Pa
17 matches
Mail list logo