Hi,
It seems to me that #8116 (only for GHC head) was also fixed. :-)
--Kazu
> And just for the record, people reported this morning they couldn't
> reproduce #8103 anymore, and I'd bet this probably fixes that one,
> too.
>
> On Tue, Aug 13, 2013 at 10:17 PM, Austin Seipp wrote:
>> Kazu,
>>
>
On Mon, Aug 12, 2013 at 9:33 AM, Richard Eisenberg wrote:
> My proposal below doesn't really give different behavior for EmptyDataDecls
> in the two scenarios… the available constructs are the same under either H98
> or H2010. It's just that the "distance" from the spec is different.
>
> Persona
Austin,
Great! Thank you!
--Kazu
> And just for the record, people reported this morning they couldn't
> reproduce #8103 anymore, and I'd bet this probably fixes that one,
> too.
>
> On Tue, Aug 13, 2013 at 10:17 PM, Austin Seipp wrote:
>> Kazu,
>>
>> What about 3e598fe0b01f4692f50c377ac910100
And just for the record, people reported this morning they couldn't
reproduce #8103 anymore, and I'd bet this probably fixes that one,
too.
On Tue, Aug 13, 2013 at 10:17 PM, Austin Seipp wrote:
> Kazu,
>
> What about 3e598fe0b01f4692f50c377ac91010040227e7ce in ghc? This was a
> calling convention
Kazu,
What about 3e598fe0b01f4692f50c377ac91010040227e7ce in ghc? This was a
calling convention bug that Geoffrey fixed.
It looks like it is almost certainly the culprit.
On Tue, Aug 13, 2013 at 10:14 PM, Kazu Yamamoto wrote:
> Hi,
>
> Some changes in the last 8 days fixed segfault on 32bit x86
Hi,
Some changes in the last 8 days fixed segfault on 32bit x86 with -O2:
http://ghc.haskell.org/trac/ghc/ticket/7953
I read recent log messages but I cannot guess which commits fixed this
bug. Does anyone guess?
P.S.
Thanks to this, now I started running Mighty with multicore IO manag
Hello Edward,
On 2013-08-13 at 15:39:20 +0200, Edward Z. Yang wrote:
> What happened to the libraries repositories?
They are still there, but only in the /packages directory (as declared
in the 'packages' file in the remotepath columns, see also [1]); you
need to run
>> ./sync-all -r git://ghc
> The next question is "well how do I do this then?". I'm not quite sure,
> maybe you need to use a deterministic name supply monad.
So why are Hoopl's rewrite functions specialized to UniqSM monad? My
understanding so far was that this is precisely because we need access to Uniq
supply to gene
What happened to the libraries repositories?
ezyang@javelin:~/Dev/ghc-clean/libraries/binary$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
ignorecase = true
[remote "o
Forgive me for asking the classic question: "What are you really trying to do?"
Edward
Excerpts from Simon Marlow's message of Tue Aug 13 09:25:51 -0400 2013:
> On 13/08/13 13:03, Jan Stolarek wrote:
> > I have yet another Hoopl question. One of my rewrites allocates a new
> > unique local regis
On 13/08/13 13:03, Jan Stolarek wrote:
I have yet another Hoopl question. One of my rewrites allocates a new unique
local register and this register is later added as a fact. So I have Cmm code
that looks like this:
I32[(old + 4)] = complicated_expr
which is rewritten to:
newReg1 = com
> But perhaps there's another way to achieve your goals - what are the
> interesting features you want to add?
Yeah. The key thing I need to change is how the GC decides where
live objects are evacuated to, to support a more efficient implementation
of resource limits (think BiBoP for cost center
Just in case there are other people (like me) who didn't notice this,
the syntax for telling git that you want to update a Trac ticket in the
commit log has changed. Read Herbet's message for details.
I used to just mention the ticket number in the commit message "blah
blah (#1234)", the new
On 10/08/13 10:57, Herbert Valerio Riedel wrote:
The command verbs currently recognized for referencing a ticket are
currently:
| addressing addresses re references refs see Trac
...and the verbs currently recognized for referencing *and* closing a
ticket are
| close closed closes fix fixed f
I have yet another Hoopl question. One of my rewrites allocates a new unique
local register and this register is later added as a fact. So I have Cmm code
that looks like this:
I32[(old + 4)] = complicated_expr
which is rewritten to:
newReg1 = complicated_expr
I32[(old + 4)] = newReg1
a
It's probably best not to rely on external libraries for this.
I'd be happy with representing the options as data rather than code,
along with a generic parser. Performance is very likely a non-issue,
but you could always do something really simple like bucketing the
options based on the firs
On 10/08/13 00:58, Edward Z. Yang wrote:
How would people feel about an alternate GC implementation in GHC which
is not parallel? A GC like this would be simpler to understand, maybe a
little faster when parallel collection is not being used, and (most
importantly for my case) easier to extend
On 26/07/13 22:56, Edward Z. Yang wrote:
Thank you Edward. I am aware of these requirements - my problem is writing the
code in which these
will always hold (I'm optimizing Cmm and hand-written Cmm files tend to cause
many problems that
don't appear in automatically generated Cmm). Having a deb
Right - I made a lot of changes while working on the new codegen.
Norman signed off on them (in principle at least) so it should be fine
to upload the package. I should admit I did very limited testing
outside of GHC's use case, and GHC even contains a copy of some of the
hoopl code with its o
Hello all!
I'm extremely happy to report (thanks to invaluable help from Stephen) that
my issues were my own dumb fault : ) — I was using LLVM 3.0's Clang but not
its llc or opt. With some other tweaks to Stephen's above patch[1], we now
have a perfectly working GHC-iOS on OS X 10.9 Mavericks. Hur
20 matches
Mail list logo
