Thanks Richard !
I followed your advice and posted a new comment to the ticket
Yorick
2014/1/6 Richard Eisenberg
> Hello Yorick,
>
> Thanks for taking this one on!
>
> First off, this kind of question/post is appropriate for putting right
> into the ticket itself. Posting a comment to the tic
Simon Marlow writes:
> On 27/12/13 20:21, Ben Gamari wrote:
>> Simon Marlow writes:
>>
>>> This sounds right to me. Did you submit a patch?
>>>
>>> Note that dynamic linking with LLVM is likely to produce significantly
>>> worse code that with the NCG right now, because the LLVM back end uses
>
Hi Gergo,
As pattern synonyms are user-facing, you should update the user manual along
with (perhaps) the wiki. The file to edit is docs/users_guide/glasgow_exts.xml.
You should also add a note to docs/users_guide/7.8.1_notes.xml.
Apologies if someone has already said this to you.
Richard
On
Of course :) It made sense once I realized that the `show` was generating
the string, and that it was not generated when the datatype was being
constructed.
However, I don't think the `showSDocForUser` call works (I tested). It uses
`runSDoc` to generate a `Doc`. It then uses `show` on that Doc:
Well, the Show instance for a type (any type) cannot possibly respect pprCols.
It can't: show :: a -> String! No command-line inputs.
I suggest something more like
doc sdoc = do { dflags <- getDynFlags; unqual <- getPrintUnqual; return
(showSDocForUser dflags unqual doc }
Simon
From: Andre
Hi,
please don't commit it just yet, I'd like the eventual single commit to
also include the user documentation.
Thanks,
Gergo
On Jan 8, 2014 10:46 PM, "Austin Seipp" wrote:
> Oh, to be honest, I was just going to squash it into a single Big
> Commit, with you set as the author, Gergo. This seem
On Wed, 8 Jan 2014, Austin Seipp wrote:
Oh, to be honest, I was just going to squash it into a single Big
Commit, with you set as the author, Gergo. This seems to be the
general way we do it for new features.
If you'd like I can just go ahead and do this for you.
Sure, thanks.
I'm getting 8
On Wed, 8 Jan 2014, Simon Peyton Jones wrote:
It'd be good if what we finally commit to HEAD has a sensible history
Yes, of course. I'll clean that up next week. I just have to run now.
--
.--= ULLA! =-.
\ http://gergo.erdi.hu \
`---= ge...@erdi.hu =---'
Ha
It'd be good if what we finally commit to HEAD has a sensible history
S
| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Dr.
| ERDI Gergo
| Sent: 08 January 2014 14:20
| To: Austin Seipp
| Cc: Joachim Breitner; ghc-devs@haskell.org
| Subject: Re: Pa
On Tue, 7 Jan 2014, Austin Seipp wrote:
Hi Gergo,
Thanks for rebasing your changes. Unfortunately, they do not compile
cleanly with ./validate, which we really need to have working for all
incoming patches.
I've fixed validation (but the commit history is a bit of a mess --
expect another hi
Dear Benno, Simon,
> I think that both ought to be ok, but I'd welcome other input.
>
> GHC.runGHC calls initGhcMonad, which allocates an entirely new session (in
> newHscEnv). So the two will work entirely independently.
>
> Unfortunately that's not 100% true. If you search for GLOBAL_VAR you
On 07/01/14 09:59, Ben Lippmeier wrote:
On 06/01/2014, at 19:43 , Simon Peyton-Jones wrote:
| Note that removing the flag isn't a "solution" to the underlying problem
| of the intermediate code being awful. Switching to the linear allocator
| just permits compilation of core code that was wor
On 08/01/14 07:35, Carter Schonwald wrote:
well said iavor.
It perhaps hints at the register allocators needing some love? I hope to
dig deep into those myself later this year, but maybe it needs some
wibbles to clean up for 7.8 right now?
There's a bit of confusion here. Let me try to clarify
On 27/12/13 20:21, Ben Gamari wrote:
Simon Marlow writes:
This sounds right to me. Did you submit a patch?
Note that dynamic linking with LLVM is likely to produce significantly
worse code that with the NCG right now, because the LLVM back end uses
dynamic references even for symbols in the
| > Can't we just allocate a Cmm "area"? The address of an area is a
| perfectly well-defined Cmm value.
What about this idea?
Simon
| -Original Message-
| From: Simon Marlow [mailto:marlo...@gmail.com]
| Sent: 08 January 2014 09:26
| To: Simon Peyton Jones; Herbert Valerio Riedel
| Cc:
On 07/01/14 22:53, Simon Peyton Jones wrote:
| Yes, this is technically wrong but luckily works. I'd very much like
| to
| have a better solution, preferably one that doesn't add any extra
| overhead.
| __decodeFloat_Int is a C function, so it will not touch the Haskell
| stack.
This all seems
Benno
I think that both ought to be ok, but I'd welcome other input.
GHC.runGHC calls initGhcMonad, which allocates an entirely new session (in
newHscEnv). So the two will work entirely independently.
Unfortunately that's not 100% true. If you search for GLOBAL_VAR you'll see a
handful of di
Any time GHC simply falls over, it's a bug. Even if you give GHC a 100 Gbyte
input program and try to compile it on a 1 Gbyte machine, it's a bug if GHC
simply falls over with "heap exhausted". It would be better if it chopped the
program into pieces and compiled them one at a time; or failed
On 08/01/14 07:46, Austin Seipp wrote:
> Excellent, thank you. We should really fix the 32bit performance
> numbers too I think, based on what we discussed on IRC earlier. Would
> you like to submit a patch for that too please? You can find the
> numbers in testsuite/tests/perf/haddock/all.T.
I ha
well said points. Theres a lot we can do, and i think I many of those
active in GHC have discussed various ideas to explore in this area for
after the ghc 7.8 release.
I believe someone did an experiment with llvm-general as an alternative ghc
backend a few months back, who was it who did that?
(
one approach for the sha near term fix is to add some CPP such that certain
inlines are suppressed on x86_32 perhaps?
On Wed, Jan 8, 2014 at 2:43 AM, Austin Seipp wrote:
> Just a guess, but I imagine it works for you because on amd64 the NCG
> will have more registers available to satisfy all t
Personally I'd be in favor of that to keep it easy, but there hasn't
really been any poll about what to do. For the most part it tends to
work fine, but I think it's the wrong thing to do in any case.
IMO the truly 'correct' thing to do, is not to rely on the system LLVM
at all, but a version spec
22 matches
Mail list logo
