David Luposchainsky writes:
> Hey list,
>
> I am strongly in favour of the proposal. As a pedestrian-level GHC
> contributor, the *vast* majority of my time is spent trying to figure
> out what certain things do, when the answer could be found in a one-
> or two-line comment above a definition.
>
Hello Simon,
b0534f7 [1] and the subsequent reversion f0fcc41d7 touched
`includes/CodeGen.Platform.hs`, the former removing a panic in the case
of `globalRegMaybe` being undefined for a platform and replacing it with
`Nothing`.
Recently I've found that my ARM builds (with -fllvm) crash at this p
I submitted two unrelated differentials today, D152 and D150. Somehow
the Harbormaster builds of both have failed in the same peculiar way,
silently dying apparently after right after finishing the initial
ghc-cabal build.
It's entirely possible I'm missing something silly here, but neither of
th
Luke Iannini writes:
> Indeed, the float register stuff was a red herring -- restoring it caused no
> problems and all my tests are working great. So yahoo!! We've got ARM64
> support.
>
Yay! Awesome work!
Cheers,
- Ben
pgpC53b1AIFVm.pgp
Description: PGP signature
___
Peter Wortmann writes:
> Okay, I have uploaded the “core” set of patches to Phab:
>
> https://phabricator.haskell.org/D155
>
Surely you mean D169 [1]?
Cheers,
- Ben
[1] https://phabricator.haskell.org/D169
pgppRR0lUBx18.pgp
Description: PGP signature
__
Austin Seipp writes:
snip.
>
> We do not believe we will ship a 7.8.4 at all, contrary to what you
> may have seen on Trac - we never decided definitively, but there is
> likely not enough time. Over the next few days, I will remove the
> defunct 7.8.4 milestone, and re-triage the assigned ticke
Murray Campbell writes:
> Hi,
>
> I am trying to help solve #9125 in which an ARM build creates binaries
> that mangle Float values.
>
> After a great deal of help from rwbarton (detailed in the comments) it
> would appear that the problem is actually in LLVM 3.0. (v3.0 is
> virtually insisted up
Richard Eisenberg writes:
> I've just finished reading this:
> http://www.reddit.com/r/haskell/comments/2hes8m/the_ghc_source_code_contains_1088_todos_please/
>
> For better or worse, I don't read reddit often enough to hold a
> conversation there, so I'll ask my question here: Is there a way we
Andreas Abel writes:
> On 05.10.2014 07:03, Ben Gamari wrote:
>> and yet aren't willing to take the five (twenty?) minutes to familiarize
>> themselves with Phabricator and the arc toolchain.
>
> Are you serious about this? I think your time estimate is a grand
>
Herbert Valerio Riedel writes:
> On 2014-10-05 at 04:51:41 +0200, Richard Eisenberg wrote:
>> I've just finished reading this:
>> http://www.reddit.com/r/haskell/comments/2hes8m/the_ghc_source_code_contains_1088_todos_please/
>>
>> For better or worse, I don't read reddit often enough to hold a
Richard Eisenberg writes:
> I absolutely believe that we should use the best tools available and
> that committed GHC contributors should have to learn these tools as
> necessary. Though I've had my problems with Phab and `arc`, I'm
> confident that this tool was chosen after a deliberative proce
Simon Peyton Jones writes:
> My conclusion
>
> * I think we (collectively!) should make a serious attempt to fix
> show-stopping
>bugs on a major release branch. (I agree that upgrading to the next major
>release often simply brings in a new wave of bugs because of GHC's
>rapid de
In ba2555ef and a6f52b19 one-shot semantics were added to event manager
in `base`. If my understanding of this code is correct, in this mode the
event manager will use only notify the user of the first event on a
registered fd after which point the fd will need to be re-registered to
get another n
Thanks for your quick reply!
Andreas Voellmy writes:
> On Sat, Oct 11, 2014 at 12:17 AM, Ben Gamari wrote:
>>
>> I'm a bit perplexed as to why the change was made in the way that it
>> was. Making one-shot a event-manager-wide attribute seems to add a fair
&
Andreas Voellmy writes:
> Another way to fix usb would be to re-register the callback after a
> previously registered callback is fired. Of course it is cheaper not to
> have to re-register, but re-registration in the latest IO manager should be
> fairly cheap, so this may not be a performance pr
Andreas Voellmy writes:
> On Sat, Oct 11, 2014 at 1:07 AM, Ben Gamari wrote:
>
>> Thanks for your quick reply!
>>
>>
>> What I'm wondering is what the extra complexity bought us. It seems like
>> the same thing could have been achieved with less breakag
Andreas Voellmy writes:
> On Sat, Oct 11, 2014 at 12:17 PM, Ben Gamari wrote:
>
> Yes, but it will be invoked by GHC.Thread and any other callers of it will
> simply block indefinitely waiting for the thread that is running loop to
> give it up - which will typically never
Ben Gamari writes:
> Andreas Voellmy writes:
>
>> On Sat, Oct 11, 2014 at 12:17 PM, Ben Gamari wrote:
>>
>> Ah... so this is not useful to you. I guess we could add `loop` to
>> GHC.Event's export list. On the other hand, I like your LifeTime proposal
>>
Andreas Voellmy writes:
> This is awesome. I'd like to try to recreate some of the evaluations for
> the multicore IO manager paper on that 40 core system at backspace. How can
> I get access to this? I'll jump on IRC - maybe it is easier to chat in
> realtime.
>
Do you suppose you could document
Austin Seipp writes:
> The catch with such a change is that there is no macro to determine
> whether we're using 7.8.3 or 7.8.4, so it's harder for users to figure
> things out (they have to use `MIN_VERSION_base` from Cabal). But maybe
> that doesn'tm atter too much. So, yes, I think it's doable
Austin Seipp writes:
> The catch with such a change is that there is no macro to determine
> whether we're using 7.8.3 or 7.8.4, so it's harder for users to figure
> things out (they have to use `MIN_VERSION_base` from Cabal). But maybe
> that doesn'tm atter too much. So, yes, I think it's doable
Simon Peyton Jones writes:
> Christopher
>
> You are doing very cool things. Thank you.
>
> What I’m puzzled about is this: the GHC API *is* a programmatic
> interface to GHC. Why not just use it?
One issue that sometimes bites me when trying to compile against GHC is
that of dependencies. Whe
Christopher Allen writes:
> Sorry to bother everybody, but where is this documented? What happens if
> incompatible versions pass data between each other?
>
I would hope this would manifest as a type error.
Cheers,
- Ben
pgpfrATN2ZiHY.pgp
Description: PGP signature
__
Richard Eisenberg writes:
> I've just finished reading this:
> http://www.reddit.com/r/haskell/comments/2hes8m/the_ghc_source_code_contains_1088_todos_please/
>
> For better or worse, I don't read reddit often enough to hold a
> conversation there, so I'll ask my question here: Is there a way we
Kazu Yamamoto writes:
> Hi,
>
>>> Andreas - want me to go ahead and get you some hardware to test Ben's
>>> patch in the mean time? This way we'll at least not leave it hanging
>>> until the last moment...
>>
>> I will also try this with two 20-core machines connected 10G on
>> Monday.
>
> I mea
Kazu Yamamoto writes:
> Hi,
>
> I measured the performace of GHC head, 7.8.3 and 7.8.3 + Ben's patch
> set.
>
> Server: witty 8080 -r -a -s +RTS -N *1
> Measurement tool: weighttp -n 10 -c 1000 -k -t 19 http://192.168.0.1:8080/
> Measurement env: two 20 core (w/o HT) machines directly connec
Kazu Yamamoto writes:
> Hi,
>
Hi Kazu,
>>> Andreas - want me to go ahead and get you some hardware to test Ben's
>>> patch in the mean time? This way we'll at least not leave it hanging
>>> until the last moment...
>>
>> I will also try this with two 20-core machines connected 10G on
>> Monday.
Kazu Yamamoto writes:
> Ben,
>
>> This may be due to lacking INLINEs on definitions added in
>> GHC.Event.Internal [1]. I'm currently in the middle of reproducing these
>> results on an EC2 instance to confirm this. So far the results look much
>> more consistent than my previous attempts at benc
Kazu Yamamoto writes:
>> I already pushed it. The commit in question is
>> 5dce47eb8415eb31e1c6759b6f6a2ef5bfe32470. Thanks for the benchmarking!
>
> I believe this is in bgamari/ghc (for GHC 7.10?).
> I'm using bgamari/packages-base for GHC 7.8 and asking to push the
> same commit to this repo.
Kazu Yamamoto writes:
>> Ahh, yes. Sorry, I forgot you were on 7.8. Just pushed a new patch to
>> the event-rework-squashed branch [1].
>
> I believe that you are trying to merge your patches to GHC 7.8.4?
> If not, I will work on the GHC head branch.
>
Well, Bas was wondering whether this would
Kazu Yamamoto writes:
>> Well, Bas was wondering whether this would be possible. At this point
>> I'm a bit on the fence; on one hand it's not a crucial fix (we have a
>> workaround in usb) and it may involve changes to exported interfaces
>> (although not very high visibility). On the other hand
Kazu Yamamoto writes:
> Ben,
>
> I have some comments and questions about your code:
>
> C: registerFd' is exported. So, it should have document.
>
It is documented [1] in the 7.10 branch. I didn't bother to bring this patch
over to 7.8 (although I will do so when it becomes clear that this is
go
Austin Seipp writes:
> Hi *,
>
> A few days ago a discussion on IRC occurred about the LLVM backend,
> its current status, and what we could do to make it a rock solid part
> of GHC for all our users.
>
> Needless to say, the situation right now isn't so hot: we have no
> commitment to version su
Austin Seipp writes:
> Joachim, thanks for the forward and discussion.
>
> Just to rehash two points for the people reading at home:
>
> - I *do not* want to ship GHC specific patches to LLVM in the builds
> we use, anymore than anyone else does. I don't have any plans or even
> patches I would
Austin Seipp writes:
> On Sat, Nov 1, 2014 at 10:43 AM, Ben Gamari wrote:
>>
>> I'm certainly not opposed to this idea and there is precedent in this
>> area set by the Rust folks. That being said, I suspect some
>> distributions may care pretty deeply abo
Austin Seipp writes:
> On Sat, Nov 1, 2014 at 11:12 AM, Joachim Breitner
> wrote:
>> Hi,
>>
>> for the Distributions it would be most easy if the custom llvm would
>> come within the source tarball, would be built by the regular build
>> process and installed along with GHC, in a private path
>>
Austin Seipp writes:
> Hi *,
>
> A few days ago a discussion on IRC occurred about the LLVM backend,
> its current status, and what we could do to make it a rock solid part
> of GHC for all our users.
>
As if we needed another reason to do this, it seems that LLVM 3.6 will
backwards incompatibly
David Terei writes:
> Late to the conversation sorry.
>
> I think this sounds like a good plan. Given we are planning to stick
> with a vanilla LLVM but just fix the version, it seems it should make
> it reasonable to have distro’s support this. We can provide binaries
> easily, but also just a d
I've written down some thoughts on the current status and future
direction of the LLVM backend here [1]. Have a look when you get a chance.
To summarize,
* it seems like LLVM 3.4 chokes on the code produced by my 3.5 rework
when the `$def` symbols are marked as internal
* ARM is broken
Joachim Breitner writes:
> Hi Ben,
>
>
> Am Freitag, den 28.11.2014, 18:27 -0500 schrieb Ben Gamari:
>> I've written down some thoughts on the current status and future
>> direction of the LLVM backend here [1].
>
> thanks. I tried to build ghc-7.8.4-rc1 on Deb
Joachim Breitner writes:
> [Resent, as ghc-dev does not like my other address. Sorry Ben]
>
> Hi,
>
>
> Am Sonntag, den 30.11.2014, 10:56 -0500 schrieb Ben Gamari:
>> > thanks. I tried to build ghc-7.8.4-rc1 on Debian, and it failed on arm*.
>> > First,
Joachim Breitner writes:
> Hi,
>
>
> Am Sonntag, den 30.11.2014, 16:48 -0500 schrieb Ben Gamari:
>> > What would be a reliable way to make the build system pass
>> > -B/usr/bin/ld.gold to gcc? Is
>> > SRC_HC_OPTS += -optc-B/usr/bin/ld.gold
>> >
Joachim Breitner writes:
> Hi,
>
>
> Am Montag, den 01.12.2014, 09:42 +0100 schrieb Joachim Breitner:
>> Am Sonntag, den 30.11.2014, 18:49 -0500 schrieb Ben Gamari:
>> > I suspect that it this is the gold issue. I should have looked at your
>> > command line
Joachim Breitner writes:
> Hi,
>
>
> Am Samstag, den 06.12.2014, 15:59 +0100 schrieb Joachim Breitner:
>> any idea what might be causing this? I started the build from a fresh
>> checkout.
>
> nevermind, I found
> https://ghc.haskell.org/trac/ghc/ticket/9552 and
> https://git.haskell.org/ghc.git/
Joachim Breitner writes:
> Hi,
>
>
> Am Samstag, den 06.12.2014, 16:19 +0100 schrieb Joachim Breitner:
>> nevermind, I found
>> https://ghc.haskell.org/trac/ghc/ticket/9552 and
>> https://git.haskell.org/ghc.git/patch/2a8ea4745d6ff79d6ce17961a64d9013243fc3c6
>> and will try with these.
>>
>> Onc
Joachim Breitner writes:
> Hi,
>
>
> Am Montag, den 08.12.2014, 08:20 -0500 schrieb Ben Gamari:
>> > Again Google finds me a bug, but this time one that has no fix
>> > associated with it:
>> > https://ghc.haskell.org/trac/ghc/ticket/8951
>> >
Joachim Breitner writes:
> Hi,
>
>
> Am Montag, den 08.12.2014, 16:34 +0100 schrieb Karel Gardas:
>> On 12/ 8/14 03:49 PM, Joachim Breitner wrote:
>> > So what does that tell us? Maybe Peter can help us: Is it normal for a
>> > Debian system to pretend that its a pre-v6 ARM, even if the actual
>>
Lennart Augustsson writes:
> I'm running the 32-bit Windows version of ghc-7.8.3.
>
> Here are two runs:
>
> $ RunMu +RTS -A64M -h -Sstat.log -i1 -RTS -c Strat.App.Abacus.Main
> Compiling afresh Strat.App.Abacus.Main
> Compiled afresh Strat.App.Abacus.Main, 1302.84s
>
> $ RunMu +RTS -A64M -Sstat
Johan Tibell writes:
> Ben,
>
> Is this something that worked in cabal-install 1.18.0.5 and that stopped
> working in 1.18.0.6 or is it something that didn't work in 1.18.0.5 but you
> expected to be fixed in 1.18.0.6? These 1.18 and 1.20 releases just target
> a very few critical bugs. They are
Ben Gamari writes:
> Johan Tibell writes:
>
>> Ben,
>>
>> Is this something that worked in cabal-install 1.18.0.5 and that stopped
>> working in 1.18.0.6 or is it something that didn't work in 1.18.0.5 but you
>> expected to be fixed in 1.18.0.6? Thes
Joachim Breitner writes:
> Hi,
>
> Am Sonntag, den 14.12.2014, 22:37 -0500 schrieb Richard Eisenberg:
snip
>
>> - Travis has not picked up on these errors.
>
> unfortunately, travis is slighly less useful since a few weeks due to
> T5681 failing (possibly due to the use of LLVM-3.4), but I’m sti
Joachim Breitner writes:
> Hi,
>
> Am Montag, den 15.12.2014, 10:58 -0500 schrieb Ben Gamari:
>> >> - Travis has not picked up on these errors.
>> >
>> > unfortunately, travis is slighly less useful since a few weeks due to
>> > T5681 failing (pos
Hi Simon,
A few of us are puzzling over a cross-compilation bug, #9920.
stg_init_finish appears to be loading a zero Sp from the saved thread
state. None of us have been able to figure out how execution makes it to
stg_init_finish. The only references to the symbol are its definition in
StgStartu
Hello Simon,
Today I've been working on trying to whip bytestring's Builder into
shape [1,2]. The last remaining issue is a performance problem that
appears to be due to over-zealous floating of some small literals in
every GHC version I've tested (7.6, 7.8, and 7.10). The test case can be
found
Kazu Yamamoto writes:
> Hi,
>
> This is just confirmation. Ben's one-shot patch (*1) is included in
> master but not included in the ghc-7.10 branch. Is this intentional?
> Is it supposed to be merged in GHC 7.12?
>
I merged it to master, asked thoughtpolice on #ghc how I should merge it
to the 7
Herbert Valerio Riedel writes:
> On 2015-01-30 at 05:36:21 +0100, Austin Seipp wrote:
>> You won't have permissions to push it to 7.10. I can try to get to it soon,
>> but I make no guarantees until next week (out of town atm).
>>
>> CC Herbert, who can probably get to it more promptly than I can
Michael Snoyman writes:
> I'm not really able to follow the details of this, but I wanted to raise to
> everyone's attention a serious bug with the current GHC 7.10 RC, Cabal
> 1.22, and/or Haddock. Currently, running `cabal haddock --hoogle` does not
> work. There seem to be two different issues
Ben Gamari writes:
> Michael Snoyman writes:
>
>> I'm not really able to follow the details of this, but I wanted to raise to
>> everyone's attention a serious bug with the current GHC 7.10 RC, Cabal
>> 1.22, and/or Haddock. Currently, running `cabal haddock
In Bug #9661, Comment #12 Simon Peyton-Jones wrote [1],
> Annoyingly, the `CoreSyn.RuleFun` API for built-in rules does not give
> access to the context of an application (the `SimplCont`), but it
> would not be hard to make it do so.
>
> So if that is the right rewrite, then it'd be another use
Simon Peyton Jones writes:
> Ben
>
> Is there a wiki page that describes this project?
> - goals, and motivation
> - design of the change
> - any implementation notes
>
Not that I'm aware of. I can perhaps fix this.
> I've lost context and #9661 is too long to suck up. A wiki page can
> car
Simon Peyton Jones writes:
> | > Is there a wiki page that describes this project?
> | > - goals, and motivation
> | > - design of the change
> | > - any implementation notes
> | >
> | Not that I'm aware of. I can perhaps fix this.
>
> Yes please! It is SO helpful.
>
How does this [1] l
George Colpitts writes:
> A side question, my understanding is that llvm-3.5 is the "official" llvm
> for ghc 7.10. Does anybody know if llvm-3.6 works with ghc 7.10?
>
I'm afraid that we won't have support for LLVM 3.6 until GHC 7.12 due to
non-backwards compatible syntax changes in LLVM's inte
Erik de Castro Lopo writes:
> Reid Barton wrote:
>
>> Why do we need to revert anything, can't we just make a one-character fix
>> of 3.6 to 3.5 on the ghc-7.10 branch?
>
> Even with that one character change the LLVM detection is not complete
> or correct. Specifically, building the compiler wil
Joachim Breitner writes:
> Dear devs,
>
> in https://ghc.haskell.org/trac/ghc/ticket/10124 bgamari suggested that
> code like
>
> f :: Int -> Bool
> f a = case a of
> 1 -> True
> 5 -> True
> 8 -> True
> 9
Tamar Christina writes:
> Hi All,
>
>
> I’m currently busy rewriting the GHC-split perl script into Haskell and
> require some for the platforms I don’t have at the moment.
>
>
> I require an example file(s) for:
>
> - Apple Darwin
>
> - Sparc
>
> - PowerPC Linux
>
> - X86 Linux
>
> - X86
Michael Snoyman writes:
> Hi Simon,
>
> We had a small pow-wow over here. We're already providing relevant
> customers with a custom-built GHC, and only using this feature internally
> to their codebases, so it's not a necessity to get this into upstream GHC
> 7.10. It would be nice if the librar
Ben Gamari writes:
> Michael Snoyman writes:
>
>> Hi Simon,
>>
>> We had a small pow-wow over here. We're already providing relevant
>> customers with a custom-built GHC, and only using this feature internally
>> to their codebases, so it's not a n
Oleg Grenrus writes:
> Hi,
>
> first some background: there is an issue with having Haskell on the
> next OS X “El Capitan”: [1] caused by security updates in the
> operating system. The cause is too old `unix` package, the same issue
> as in [2]
>
I would like to understand the root-cause of the
Oleg Grenrus writes:
> Hi,
> first some background: there is an issue with having Haskell on the
> next OS X “El Capitan”: [1] caused by security updates in the
> operating system. The cause is too old `unix` package, the same issue
> as in [2]
I would like to understand the root-cause of the is
Hello everyone,
Earlier today I merged a clean-up [1] to the master branch which
removed some #ifdefs which ensured that the tree could be built with GHC 7.6
Thomas Miedema correctly pointed out that some nightly builders may not
be on GHC 7.8 yet. Do any of the nightly builders call in this cat
=
The (Interactive) Glasgow Haskell Compiler -- version 7.10.2
=
The GHC Team is pleased to announce a new bug-fix release of GHC,
7.10.2.
There have been a
Andrés Sicard-Ramírez writes:
> Hi,
>
> On 29 July 2015 at 10:26, Ben Gamari wrote:
>> The GHC Team is pleased to announce a new bug-fix release of GHC,
>> 7.10.2.
>
> Thanks for the release!
>
> FYI, there are various missing *.tar.xz files in
Mikhail Glushenkov writes:
> Hi,
>
> On 29 July 2015 at 17:26, Ben Gamari wrote:
>> [...]
>> The full release notes including a complete listing of the changes in
>> this release can be found here,
>>
>>
>> https://downloads.haskell.org/~ghc/7.1
Hello again!
See below for an important announcement regarding the `text` issue
described earlier.
Ben Gamari writes:
> =
> The (Interactive) Glasgow Haskell Compiler -- version
James M writes:
> There was talk from an earlier email thread of releasing the Haskell
> Platform at the same time as 7.10.2.
>
> I am referring to the weekly news of 2015/05/11:
> https://ghc.haskell.org/trac/ghc/blog/weekly20150511
>
> and this email thread:
> https://mail.haskell.org/pipermail
Alain O'Dea writes:
> On 21 July 2015 at 13:31, Ben Gamari wrote:
>
>>
>> Hello everyone,
>>
>> Earlier today I merged a clean-up [1] to the master branch which
>> removed some #ifdefs which ensured that the tree could be built with GHC
>> 7.6
Hello everyone!
With the 7.10.1 release nearly six months behind us and 7.10.2 out of the
way, now is a good time to begin looking forward to 7.12. In keeping
with the typical release pace, we are aiming to have a release
candidate ready in mid-December 2015 and a final release in January
2016.
David Luposchainsky writes:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hey Ben,
>
> my summer was pretty busy, but we recently fixed our MonadFail implementation
> to
> work as desired, so that should make it in as well. We'll have to survive a
> heroic rebase/squash that we'll probab
Matthew Pickering writes:
> Hi Ben,
>
> I think that D1152 (Record Pattern Synonyms) will be ready for 7.12.
> https://phabricator.haskell.org/D1152
>
Ahh yes. Thanks for pointing this out. I've added it to the list.
Cheers,
- Ben
signature.asc
Description: PGP signature
_
Elliot Cameron writes:
> I can't seem to find the exact trac ticket, but the ability to swap
> out "Integer" implementations at link time would be a huge relief on
> Windows, which suffers from various problems with dynamic linking. I
> believe it was originally slated for 7.12. Can someone find
Kosyrev Serge <_deepf...@feelingofgreen.ru> writes:
> Ben Gamari writes:
>> These items are a bit less certain but may make it in if the authors
>> push forward quickly enough,
>
> [..]
>
>> * A (possible) overhaul of GHC's build system to use Shake
Simon Peyton Jones writes:
> | If this is intended to be an immediate wholesale switch to Shake I
> | would be very skeptical of merging for 7.12 as three months is, in my
> | opinion, very little time to test such a sweeping change.
>
> No there is no chance that we switch over to Shake for 7
Simon Peyton Jones writes:
> Actually that’s a good idea.
>
> Simon
>
>
> From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Greg Weber
> Sent: 28 August 2015 16:43
> To: Ben Gamari
> Cc: GHC developers
> Subject: Re: Planning for the 7.12 releas
Andrey sent this report regarding the status of the new Shake build
system he is working on but it seems it must have bounced from ghc-devs.
Hopefully this time it makes it.
Cheers,
- Ben
Andrey Mokhov writes:
> Hi all,
>
> I aim at releasing a first working prototype of the new build system
Richard Eisenberg writes:
> On Sep 1, 2015, at 12:01 AM, Herbert Valerio Riedel
> wrote:
>
>> I'd say mostly organisational overhead which can't be fully automated
>> (afaik, Ben has already automated large parts but not everything can be):
>>
>> - Coordinating with people creating and testing
Richard Eisenberg writes:
> I think some of my idea was misunderstood here: my goal was to have
> quick releases only from the stable branch. The goal would not be to
> release the new and shiny, but instead to get bugfixes out to users
> quicker. The new and shiny (master) would remain as it is
Jan Stolarek writes:
>> In general we shouldn't commit anything that breaks validate, because
>> this causes problems for other developers. The right thing to do would
>> be to mark it expect_broken before committing.
>
> Sorry for that. I was actually thinking about marking the test as
> expec
Simon Peyton Jones writes:
> Is there currently any planned work around making the haskell error
> messages able to support something like the ones in IDRIS, as shown in
> David Christianson's talk "A Pretty printer that says what it means"
> at HIW?
>
> Not that I know of, but it would be a Good
Hello all!
Last year there was a brief thread [1] on this list discussing the
choice of markup language used for GHC's users guide. At this point
DocBook is showing signs of age,
* The format's documentation is ancient and isn't terribly approachable.
* Writing XML by hand is a terrible, ter
Ben Gamari writes:
> Hello all!
>
I have collected the details of this proposal into a Wiki page[1]. Feel
free to leave thoughts there as well as this thread.
Cheers,
- Ben
[1] https://ghc.haskell.org/trac/ghc/wiki/UsersGuide/MoveFromDocBook
signature.asc
Description: PGP sig
Hello friendly GHCers,
Last week I sent out poll asking opinions on moving the Users' Guide
From Docbook to ReStructuredText. While the response wasn't particularly
large in volume, those that did reply were quite supportive of the idea.
This week I took the time to clean up my hacked prototype.
Ben Gamari writes:
> Hello friendly GHCers,
>
> Last week I sent out poll asking opinions on moving the Users' Guide
> From Docbook to ReStructuredText. While the response wasn't particularly
> large in volume, those that did reply were quite supportive of the idea.
>
Simon Peyton Jones writes:
> It looks lovely.
>
> Please please can we have section numbers?! It is so helpful to be
> able to say "see section 3.2.42 in the user manual". And the numbers
> give a clearer indication of sub-nesting than does the font in which
> the heading is rendered. It's a big
Simon Peyton Jones writes:
> | I should also point out that our documentation now has documentation,
> |
> |
> | https://na01.safelinks.protection.outlook.com/?url=http:%2f%2fsmart-
> | cactus.org%2f~ben%2fghc-users-guide%2fhtml%2fediting-
> | guide.html&data=01%7C01%7Csimonpj%40064d.mgd.
Alexey Vagarenko writes:
>> Ahh, that's a good point. Indeed we can. I've uploaded an updated
>> build with section numbers.
>
> Perhaps also hide bullets on list items on contents page? They look
> redundant.
Fair point. I'll take care of this.
Cheers,
- Ben
signature.asc
Description: PGP
Hello everyone!
Over the last month or so I've been working on better incorporating
Peter Wortmann's DWARF work into the GHC. The immedate goals are
two-fold,
* Allow access to reified stacks in the RTS and user programs
* Introduce some basic statistical profiling functionality into the
Joachim Breitner writes:
> Hi,
>
> Am Freitag, den 02.10.2015, 15:14 +0200 schrieb Ben Gamari:
>> In addition to converting the DocBook to ReST, this also involved
>> ripping out the previously rather fragile system for building the
>> `ghc` manpage and desc
Michael Walker writes:
> Hello,
>
> I've been trying to figure out where exactly the synchronisation guarantee of
> `atomicModifyIORef` comes from, I've gone down a bit of a rabbit-hole of
> function
> calls and macro expansions, and wanted to check I'd got the right idea.
>
> **Assumption:** `s
Gabor Greif writes:
> Hi all,
>
> look:
>
> $ git grep "typedef struct LibDwSession_ "
> rts/Libdw.c:typedef struct LibDwSession_ LibDwSession;
> rts/Libdw.h:typedef struct LibDwSession_ LibDwSession;
>
> $ which gcc
> /usr/bin/gcc
>
> $ gcc --version
> gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4)
Simon Peyton Jones writes:
> I have not tried that. But 'pip' gives "command not found".
>
> Maybe I need something in my path? I appear to have python 2.7.5 installed;
> it does not appear to have pip.exe.
>
Pip ships with Python 2.7.9 and later. Alternatively, you this script
[1] will instal
1 - 100 of 1812 matches
Mail list logo
