Re: Backporting srcLoc to the GHC 7.10 branch

[Niklas Hambüchen]

On 22/04/15 01:33, Niklas Hambüchen wrote:
 I will upload that as a Phabricator Diff soon, and mention the URL here.

Here it is: https://phabricator.haskell.org/D861
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Backporting srcLoc to the GHC 7.10 branch

[Niklas Hambüchen]

On 22/04/15 02:42, RodLogic wrote:
 Fyi: what about assert? Afaik, there is special treatment in the
 compiler for the assert that could be replaced by this (?).

Yes, replacing the custom code for `assert` was also on Eric's plan, see
the comment he just made:

  https://phabricator.haskell.org/D861#23250
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Backporting srcLoc to the GHC 7.10 branch

[Niklas Hambüchen]

Hello everybody,

I'm glad to announce that I performed the suggested backporting as part of 
my work for FP Complete!

With the help of Eric (thanks for your support in #ghc!) we now have this 
patch for 7.10 and 7.8.

As promised, here are the commits:

* https://github.com/nh2/ghc/commits/ghc-7.10.1-release-srcloc-ip
* https://github.com/nh2/ghc/commits/ghc-7.8.4-release-srcloc-ip

You can see in the history that I only needed to cherry-pick Make the 
location in TcLclEnv and CtLoc into a RealSrcSpan as a dependent commit, 
so the changes beyond the actual feature are fairly minimal.

For 7.8, I had to do a little more cleanup, see the Use wrapIPTc instead 
of coercionToTcCoercion on wrapIP commit.

Regarding the commit of the feature itself, I had to do quite some merge 
resolution, especially due to the (lack of) the -fwarn-redundant-
constraints patch https://github.com/nh2/ghc/commit/32973bf3 (alias but it 
was Christmas, so I did some recreational programming that went much 
further).
However, the type checker had a strong opinion of what the right merge 
decision was, at least for the 7.10 backport; for 7.8 there was an 
ambiguity (whether to return `Nothing` or `Just` in `interactDict`), which 
was resolved with Eric's help.

Please be invited to review the two commits.

We would like to make 7.8 and 7.10 binaries with this feature available as 
well, and will do so after getting a review!

Niklas

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Backporting srcLoc to the GHC 7.10 branch

[Niklas Hambüchen]

Yes, I do have work in progress on using this feature in `error` and
`undefined`.

I will upload that as a Phabricator Diff soon, and mention the URL here.

Niklas

On 21/04/15 02:07, Greg Weber wrote:
 Thanks a lot! Is there any plan to make error or other partial functions
 in the base libraries use this feature?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: accept pull requests on GitHub

[Niklas Hambüchen]

Hi,

I would recommend against moving code reviews to Github.
I like it and use it all the time for my own projects, but for a large
project like GHC, its code reviews are too basic (comments get lost in
multi-round reviews), and its customisation an process enforcement is
too weak; but that has all been mentioned already on the
https://ghc.haskell.org/trac/ghc/wiki/WhyNotGitHub page you linked.

I do however recommend accepting pull requests via Github.

This is already the case for simple changes: In the past I asked Austin
"can you pull this from my branch on Github called XXX", and it went in
without problems and without me having to use arc locally.

But this process could be more automated:

For Ganeti (cluster manager made by Google, written largely in Haskell)
I built a tool (https://github.com/google/pull-request-mailer) that
listens for pull requests and sends them to the mailing list (Ganeti's
preferred way of accepting patches and doing reviews). We built it
because some people (me included) liked the Github workflow (push
branch, click button) more than `git format-patch`+`git send-email`. You
can see an example at https://github.com/ganeti/ganeti/pull/22.
The tool then replies on Github that discussion of the change please be
held on the mailing list. That has worked so far.
It can also handle force-pushes when a PR gets updated based on
feedback. Writing it and setting it up only took a few days.

I think it wouldn't be too difficult to do the same for GHC: A small
tool that imports Github PRs into Phabricator.

I don't like the arc user experience. It's modeled in the same way as
ReviewBoard, and just pushing a branch is easier in my opinion.

However, Phabricator is quite good as a review tool. Its inability to
review multiple commits is nasty, but I guess that'll be fixed at some
point. If not, such an import tool I suggest could to the squashing for you.

Unfortunately there is currently no open source review tool that can
handle reviewing entire branches AND multiple revisions of such
branches. It's possible to build them though, some companies have
internal review tools that do it and they work extremely well.

I believe that a simple automated import setup could address many of the
points in https://ghc.haskell.org/trac/ghc/wiki/WhyNotPhabricator.

Niklas

On 01/09/15 20:34, Thomas Miedema wrote:
> Hello all,
> 
> my arguments against Phabricator are here:
> https://ghc.haskell.org/trac/ghc/wiki/WhyNotPhabricator.
> 
> Some quotes from #ghc to pique your curiosity (there are some 50 more):
>  * "is arc broken today?"
>  * "arc is a frickin' mystery."
>  * "i have a theory that i've managed to create a revision that phab
> can't handle." 
>  * "Diffs just seem to be too expensive to create ... I can't blame
> contributors for not wanting to do this for every atomic change"
>  * "but seriously, we can't require this for contributing to GHC... the
> entry barrier is already high enough" 
> 
> GitHub has side-by-side diffs
>  nowadays, and
> Travis-CI can run `./validate --fast` comfortably
> .
> 
> *Proposal: accept pull requests from contributors on
> https://github.com/ghc/ghc.*
> 
> Details:
>  * use Travis-CI to validate pull requests.
>  * keep using the Trac issue tracker (contributors are encouraged to put
> a link to their pull-request in the 'Differential Revisions' field).
>  * keep using the Trac wiki.
>  * in discussions on GitHub, use https://ghc.haskell.org/ticket/1234 to
> refer to Trac ticket 1234. The shortcut #1234 only works on Trac itself.
>  * keep pushing to git.haskell.org , where the
> existing Git receive hooks can do their job keeping tabs, trailing
> whitespace and dangling submodule references out, notify Trac and send
> emails. Committers close pull-requests manually, just like they do Trac
> tickets.
>  * keep running Phabricator for as long as necessary.
>  * mention that pull requests are accepted on
> https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/FixingBugs.
> 
> My expectation is that the majority of patches will start coming in via
> pull requests, the number of contributions will go up, commits will be
> smaller, and there will be more of them per pull request (contributors
> will be able to put style changes and refactorings into separate
> commits, without jumping through a bunch of hoops).
> 
> Reviewers will get many more emails. Other arguments against GitHub are
> here: https://ghc.haskell.org/trac/ghc/wiki/WhyNotGitHub.
> 
> I probably missed a few things, so fire away.
> 
> Thanks,
> Thomas
> 
> 
> 
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: accept pull requests on GitHub

[Niklas Hambüchen]

On 02/09/15 22:42, Kosyrev Serge wrote:
> As a wild idea -- did anyone look at /Gitlab/ instead?

Hi, yes. It does not currently have a sufficient review functionality
(cannot handle multiple revisions easily).

On 02/09/15 20:51, Simon Marlow wrote:
> It might feel better
> for the author, but discovering what changed between two branches of
> multiple commits on github is almost impossible.

I disagree with the first part of this: When the UI of the review tool
is good, it is easy to follow. But there's no open-source implementation
of that around.

I agree that it is not easy to follow on Github.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: download all of Hackage?

[Niklas Hambüchen]

Thank you, this is exactly what I needed the other day to do a quick
survey of language extensions.

On 14/09/15 17:19, Alan & Kim Zimmerman wrote:
> You could clone https://github.com/bitemyapp/hackage-packages
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: How do I use CallStack?

[Niklas Hambüchen]

On 07/12/15 11:59, Ben Gamari wrote:
>> If the name "showCallStack" suggests the compiler-derived output, we
>> could change it to something like "prettyCallStack" or
>> "formatCallStack", I don't have a strong opinion there.
> 
> I have also struggled with these sorts of naming decisions. The
> overloading of the word "show" is a bit problematic. (+1) for "pretty".

As a total proponent of Show-is-derived, +1 for a better name.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1

[Niklas Hambüchen]

On 13/01/16 16:43, Ben Gamari wrote:
> If you have a ticket that you would like to see addressed that does
> not meet one of these criteria, please bring this to our
> attention.

I would like to nominate
https://ghc.haskell.org/trac/ghc/ticket/11172, the run-time segfault
bug I found when using TH with -O, because it currently forces us to
do some production builds with -O0.

Happy to provide more input/testing in the ticket if needed.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Spam filtering

[Niklas Hambüchen]

Hi Ben,

Could we not have a captcha instead of a reject, to avoid false positives? That 
would require no training.

Since I assume most Trac spammers are extremely unsophisticated, a simple 
hardcoded question like "What programming language is GC all about?" may be 
sufficient.

On 15/04/16 17:28, Ben Gamari wrote:
>
> Hello GHCers,
>
> As you may have noticed, the GHC Trac instance is currently being hit
> with a significant amount of spam traffic recently. I believe I've
> cleared up most of the garbage and the filter configuration has been
> tightened so that future spam attacks will be easier to quell.
>
> Of course, this tightening means that there is a greater chance of false
> positives. If you do find that your ticket comments or Wiki edits are
> being rejected by the spam filter, please notify either Austin or me so
> that we can train the filter on your example.
>
> Cheers,
>
> - Ben
>
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Add a signaling Nans rts option to ghc?

[Niklas Hambüchen]

Count me in as interested, I'd appreciate a feature to notice accidental
NaNs in my code.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Improving GHC GC for latency-sensitive networked services

[Niklas Hambüchen]

I'll be lazy and answer the simplest question in this thread :)

On 18/10/16 16:32, Simon Marlow wrote:
> If not, are you willing to recompile GHC and all your libraries?

Yes.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: many haskell's mails are detected as spam on gmail

[Niklas Hambüchen]

Despite Google's public claims to the contrary, I have found the Gmail
spam filter not to work too reliably; I've had cases where it blocked
important emails like "OK, here's my invoice (PDF attached)" in the
middle of long email threads, of which messages were otherwise let
through without problem.

As a result, I disabled the Gmail spam filter completely; these
instructions worked for me:

http://webapps.stackexchange.com/questions/69442/how-to-disable-gmail-anti-spam-completely

You may consider this too if the various technical things people are
working on in the other replies don't improve the situation for you.

On 25/12/16 09:35, Takenobu Tani wrote:
> Hi,
> 
> I'm using gmail.
> Recently, many haskell's mails are detected as spam on gmail.
> (ghc-devs, haskell-cafe, ghc-commit, ...)
> 
> Does anyone know why?
> Do you know the workaround?
> 
> Regards,
> Takenobu
> 
> 
> 
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Where do I start if I would like help improve GHC compilation times?

[Niklas Hambüchen]

I have some suggestions for low hanging fruits in this effort.

1. Make ghc print more statistics on what it spending time on

When I did the linking investigation recently
(https://www.reddit.com/r/haskell/comments/63y43y/liked_linking_3x_faster_with_gold_link_10x_faster/)
I noticed (with strace) that there are lots of interesting syscalls
being made that you might not expect. For example, each time TH is used,
shared libraries are loaded, and to determine the shared library paths,
ghc shells out to `gcc --print-file-name`. Each such invocation takes 20
ms on my system, and I have 1000 invocations in my build. That's 20
seconds (out of 2 minutes build time) just asking gcc for paths.

I recommend that for every call to an external GHC measures how long
that call took, so that it can be asked to print a summary when it's done.

That might give us lots of interesting things to optimize. For example,
This would have made the long linker times totally obvious.

At the end, I would love to know for each compilation (both one-shot as
used in ghc's build system, and `ghc --make`):

* What programs did it invoke and how long did they take
* What files did it read and how long did that take
* How long did it take to read all the `.hi` files in `ghc --make`
* High level time summary (parsing, typechecking, codegen, .hi files, etc)

That way we'll know at least what is slow, and don't have to resort to
strace every time in order to obtain this basic answer.

2. Investigate if idiotic syscalls are being done and how much

There's this concept I call "idiotic syscalls", which are syscalls of
which you know from before that they won't contribute anything
productive. For example, if you give a linker N many `-L` flags (library
dirs) and M many `-l` flags (library names to link), it will try to
`stat()` or `open()` N*M many files, out of which most are total
rubbish, because we typically know what library is in what dir.
Example: You pass `-L/usr/lib/opencv -L/usr/lib/imagemagick
-L/usr/lib/blas -lopencv -limagemagick -lblas`. Then you you will get
things like `open("/usr/lib/opencv/libimagemagick.so") = ENOENT` which
makes no sense and obviously that file doesn't exist. This is a problem
with the general "search path" concept; same happens for running
executables searching through $PATH. Yes, nonexistent file opens fail
fast, but in my typical ghc invocation I get millions of them (and we
should at least measure how much time is wasted on them), and they
clutter the strace output and make the real problems harder to investigate.
We should check if we can create ways to give pass those files that do
exist.

3. Add pure TemplateHaskell

It is well known that TH is a problem for incremental compilation
because it can have side effects and we must therefore be more
conservative about when to recompile; when you see a `[TH]` in your `ghc
--make` output, it's likely that time again.

I believe this could be avoided by adding a variant of TH that forbids
the use of the `runIO` function, and can thus not have side effects.

Most TH does not need side effects, for example any form of code
generation based on other data types (lenses, instances for whatever).
If that was made "pure TH", we would not have to recompile when inputs
to our TH functions change.

Potentially this could even be determined automatically instead of
adding a new variant of TH like was done for typed TH `$$()`, simply by
inspecting what's in the TH and if we can decide there's no `runIO` in
there, mark it as clean, otherwise as tainted.

4. Build ghc with `ghc --make` if possible

This one might be controversial or impossible (others can likely tell
us). Most Haskell code is built with `ghc --make`, not with the one-shot
compilation system + make or Hadrian as as done in GHC's build system.
Weirdly, often `ghc --make` scales much worse and has much worse
incremental recompilation times than the one-shot mode, which doesn't
make sense given that it has no process creation overhead, can do much
better caching etc. I believe that if ghc or large parts of it (e.g.
stage2) itself was built with `--make`, we would magically see --make
become very good, simply we make the right people (GHC devs) suffer
through it daily :D. I expect from this the solution of the `-j`
slowness, GHC overhead reduction, faster interface file loads and so on.

These are some ideas.

Niklas
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC and linker choice

[Niklas Hambüchen]

Hi Ben,

> For what it's worth, some of us have recognized for quite some time that
> BFD ld is a known slow spot in the compilation pipeline. However, up
> until now we have considered this to be more of an issue to be handled
> at the packaging level than in GHC issue. Currently, GHC relies on `gcc`
> to link and gcc has its own idea of the default linker. Many users (e.g.
> Debian packagers, users who are cross compiling) are quite unhappy when
> GHC coerces the system toolchain into changing its default behavior.
> 
> Consequently we have maintained the status quo and silently wished that
> Linux distributions would start moving to gold by default. Sadly there
> continues to be little progress on this matter.

This is a great point.

I don't know if using BFD ld vs gold is a controversial move, given that
they are both GNU projects. I would imagine if lld was in the game, that
might be more controversial.

I have the theory that both Haskell packagers and Linux distributions
are simply conservative about changing the linker not because they don't
want it, but because they are scared of breaking people's code, and
especially in the packagers' case, that they don't feel expert enough to
judge whether them making this move will be safe.

I can imagine that they would rather welcome if the GHC devs made this
decision, since after all they generate the linker invocations and have
the knowledge to judge whether they are supposed to work.

If a packager wants to *override* GHC's default behaviour, that should
certainly be possible, but as a packager I would find it unfair if GHC
pushed the burden of setting up the optimal defaults for my users on me.

For a comparison with other programming languages:

From tickets like https://github.com/golang/go/issues/1588 seems that go
also uses gold by default when available.

Rust switched to gold by default with
https://github.com/rust-lang/rust/pull/29974, but reverted the commit
with https://github.com/rust-lang/rust/pull/30913, with reasons being
the linked tickets.

The Rust tickets in particular have already discussed the various issues
we may be running into regarding autodetection, cross compilation and so
on, it may be good to get inspiration from there.

>  * Do we want to also enable it in source distributions as well? If yes
>then developers may be caught by surprise

I would recommend to do the same in source and binary distributions. The
surprise should be minimised by properly advertising it as a key thing
in the release notes. Packagers are supposed to read those, and in fact
and most users of GHC love to read them for they contain many goodies.

Another option is to not change the default or enable autodetection, but
make it trivial to use gold for the user, e.g. by at least fixing the
Cabal library (currently you need to put your linker options into a lot
of places to get the desired results, see
https://github.com/haskell/cabal/issues/4435, and even if you do, for
some invocations Cabal just doesn't pass on what you tell it to do, see
https://github.com/haskell/cabal/issues/4439).
We could run this for a GHC release term, and also have cabal-install
and stack recommend people that they should try to set some easy option
to use the gold linker if available. If that works well, we could switch
to autodetection the release after that.
I haven't though much about whether this is actually a better idea than
just enabling it where we can.

Niklas



signature.asc
Description: OpenPGP digital signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: 8.2.1: Ord TyCon is gone?

[Niklas Hambüchen]

Hi Levent,

that seems to be this commit, part of the making-ghc-deterministic effort:

  https://ghc.haskell.org/trac/ghc/ticket/4012#comment:213

CC @niteria who might be answer your question.

Niklas

On 29/07/17 08:12, Levent Erkok wrote:
> I'm trying to port some plugin code from GHC 8.0.2 to GHC 8.2.1; alas
> I'm getting an error suggesting that TyCon is no longer an instance of
Ord:
>
> Data/SBV/Plugin/Analyze.hs:580:33: error:
> • No instance for (Ord TyCon) arising from a use of ‘M.lookup’
>   There are instances for similar types:
> instance Ord GHC.Types.TyCon -- Defined in ‘GHC.Classes’
> • In the expression: k `M.lookup` tcMap
>   In the expression:
> case k `M.lookup` tcMap of
>   Just knd -> return knd
>   Nothing -> unknown
>   In a case alternative:
>   Just k
> -> case k `M.lookup` tcMap of
>  Just knd -> return knd
>  Nothing -> unknown
> |
> 580 |  Just k -> case k `M.lookup` tcMap of
> | ^^
>
> I was using TyCon's as a key in a map, but that code is no longer
> compiling. I've looked through the release notes but couldn't find what
> the new mechanism is.
>
> I'd appreciate if someone can point me in the right direction regarding
> how to use TyCon as a map key..
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Bringing back #ghc IRC logging

[Niklas Hambüchen]

Hi,

as you may have noticed, #ghc IRC logging has been broken for months
(though the channel topic still says "Logs: http://ircbrowse.net/ghc;).

Logs being unavailable is bad because many problems and topics that were
googleable before are no longer googleable.

We have discussed in the last 2 days on #ghc whether we should just join
#ghc with a 0-effort-on-our-side public logging service like botbot.me.

This one in particular doesn't have the best UI but I found it to be
very googleable, and many open-source projects use it successfully.

Is anybody opposed to this?

Niklas
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Crossreferenced GHC 8.0.2

[Niklas Hambüchen]

Hey Robin,

I find that super useful, thanks!

I hope some day we'll get to the stage where for any Haskell code I can
easily discover all inputs, like the Java world has in their IDEs for
decades already.

Niklas

On 30/06/17 09:55, Robin Palotai wrote:
> First, here you can click around [2] and find where beloved functions
> are called from
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Underscore in binary literals

[Niklas Hambüchen]

I'd find that quite useful for hex and binary.

It's useful for distinguishing e.g. 0x and 0xfff which when
confused accidentally and lead to big bugs.

Rust has exactly this feature for all numeric literals:

  https://rustbyexample.com/primitives/literals.html

On 26/09/17 14:40, Takenobu Tani wrote:
> GHC's BinaryLiterals extension is useful.
> (For example, x = 0b110111000101)
> 
> Is it difficult to include underscore(_) in the format like Verilog-HDL[1] ?
> (For example, x = 0b1101_1100_0101)
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC Threads affinity

[Niklas Hambüchen]

Hey Michael, greetings!

Here's a little side issue that may also be of interest to you in case
you've got HyperThreading on:

  https://ghc.haskell.org/trac/ghc/ticket/10229

Niklas
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Crossreferenced GHC 8.0.2

[Niklas Hambüchen]

On 17/08/17 18:22, Matthew Pickering wrote:
> 2. A nix function which builds and references all dependencies.

Very nice, it worked out of the box for me! (Almost, small issue with
https://github.com/mpickering/core-kythe/issues/10.)

I like how you can just add package names to a file and everything
magically works without setup effort.

Niklas
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Building on limited memory environments (or does -M really work?)

[Niklas Hambüchen]

Hey Saurabh,

from my experience with CircleCI it builds on machines with e.g. 32
cores showing up in htop (but allows you to use way less that that).

But ghc sees 32 cores so -j will compile up to 32 modules at the same
time (thus using tons of RAM).

I solved that by setting -jN to the actual number of cores I bought from
CircleCI.

Greetings!
Niklas

On 21/10/17 14:36, Saurabh Nanda wrote:
> We're struggling to get our build pipeline working on CircleCI, which
> has a 4GB RAM limit.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: How does the IO manager handle reading regular files?

[Niklas Hambüchen]

Hey Ben, thanks for your quick reply.

I think there's a problem.

On 14/05/2018 15.36, Ben Gamari wrote:
> I believe the relevant implementation is the RawIO instance defined in
> GHC.IO.FD. The read implementation in particular is
> GHC.IO.FD.readRawBufferPtr. There is a useful Note directly above
> this function.

Reading through the code at

  
http://hackage.haskell.org/package/base-4.11.1.0/docs/src/GHC.IO.FD.html#readRawBufferPtr

The first line jumped to my eye:

  | isNonBlocking fd = unsafe_read -- unsafe is ok, it can't block

This looks suspicious.
And indeed, the following program does NOT keep printing things in the printing 
thread, and instead blocks for 30 seconds:

```
module Main where

import   Control.Concurrent
import   Control.Monad
import qualified Data.ByteString as BS
import   System.Environment

main :: IO ()
main = do
  args <- getArgs
  case args of
[file] -> do

  forkIO $ forever $ do
putStrLn "still running"
threadDelay 10 -- 0.1 s
  bs <- BS.readFile file
  putStrLn $ "Read " ++ show (BS.length bs) ++ " bytes"

_ -> error "Pass 1 argument (a file)"
```

when compiled with

  ~/.stack/programs/x86_64-linux/ghc-8.2.2/bin/ghc --make -O -threaded 
blocking-regular-file-read-test.hs

on my Ubuntu 16.04 and on a 2GB file like

  ./blocking-regular-file-read-test /mnt/images/ubuntu-18.04-desktop-amd64.iso

And `strace -f -e open,read` on it shows:

  open("/mnt/images/ubuntu-18.04-desktop-amd64.iso", 
O_RDONLY|O_NOCTTY|O_NONBLOCK) = 11
  read(11,  

So GHC is trying to use `O_NONBLOCK` on regular files, which cannot work and 
will block when used through unsafe foreign calls like that.

Is this a known problem?

Otherwise I'll go ahead and file a ticket.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: How does the IO manager handle reading regular files?

[Niklas Hambüchen]

Also funny but perhaps not too surprising:

If in my code, you replace `forkIO` by e.g. `forkOn 2`, then 
nondeterministically, sometimes the program hangs and sometimes it works with 
+RTS -N2.

The higher you set -N, the more likely it is to work.

If you put both the putStrLn loop and the readFile into `forkOn 0` and `forkOn 
1` each, and run with +RTS -N3, then it always works as expected.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

How does the IO manager handle reading regular files?

[Niklas Hambüchen]

I just got reminded that epoll() has no effect on regular files on Linux by 
reading an nginx article [1] [2] and why that is [3] [4].

By what means does the IO manager make reads (wraps around the read() syscall 
on Linux) non-blocking?

Does it always use read() in `foreign import safe` (or `interruptible`) so that 
an OS thread is spawned?

It would be great if somebody could point me to the code where that's done (not 
again: for *regular* files).

Thanks!
Niklas


[1]: https://www.nginx.com/blog/thread-pools-boost-performance-9x/
[2]: https://stackoverflow.com/questions/8057892/epoll-on-regular-files
[3]: https://jvns.ca/blog/2017/06/03/async-io-on-linux--select--poll--and-epoll/
[4]: 
https://groups.google.com/forum/#!topic/comp.os.linux.development.system/K-fC-G6P4EA
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: ZuriHac 2018 GHC DevOps track - Request for Contributions

[Niklas Hambüchen]

On 08/04/2018 15.01, Michal Terepeta wrote:
> I'd be happy to help. :) I know a bit about the backend (e.g., cmm level), 
> but it might be tricky to find there some smaller/self-contained projects 
> that would fit ZuriHac.

Hey Michal,

that's great. Is there a topic you would like to give a talk about, or a pet 
peeve task that you'd like to tick off with the help of new potential 
contributors in a hacking session?

Other topics that might be nice and that you might know about are "How do I add 
a new primop to GHC", handling all the way from the call on the Haskell side to 
emitting the code, or (if I remember that correctly) checking out that issue 
that GHC doesn't do certain optimisations yet (such as emitting 
less-than-full-word instructions e.g. for adding two Word8s, or lack of some 
strength reductions as in [1]).

> You've mentioned performance regression tests - maybe we could also work on 
> improving nofib?

For sure!
Shall we run a hacking session together where we let attendees work on both 
performance regression tests and nofib? It seems these two fit well together.

Niklas

[1]: 
https://stackoverflow.com/questions/23315001/maximizing-haskell-loop-performance-with-ghc/23322255#23322255


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: ZuriHac 2018 GHC DevOps track - Request for Contributions

[Niklas Hambüchen]

Hey Ömer,

On 09/04/2018 06.56, Ömer Sinan Ağacan wrote:
> I'd also be happy to help. At the very least I can be around as a mentor, but
> if I can find a suitable hask I may also host a hacking session.

That's awesome!

Do you have a topic that you'd be especially interested in for running as a 
hacking session?

In case not, mentoring help would also be very appreciated for other hacking 
sessions.
The tentative topics we have right now are:

* Adding performance regressions tests
* Finding and fixing Hadrian issues
* Back-end/Codegen
* CI infrastructure
* General mentoring & working on any GHC topic

Best,
Niklas
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: ZuriHac 2018 GHC DevOps track - Request for Contributions

[Niklas Hambüchen]

Hey Michal,

sorry for the late reply on my side too, I had a surprisingly busy weekend.

I think what you propose is great, let's do it and allocate you a talk slot.
Do you have a preferred time?

I think having some improvisation in it is totally OK:
After all, we're aiming at GHC beginners, so the point of the talks is to get 
them motivated and some ideas what topics they could work on.

Best,
Niklas

On 28/05/2018 19.13, Michal Terepeta wrote:
> Hi Niklas,
> 
> Sorry for slow reply - I'm totally snowed under at the moment.
> 
> I should be able to give some overview/examples of what are primops and how 
> they go through the compilation pipeline. And talk a bit about the Cmm-level 
> parts of GHC. But I won't have much time to prepare, so there might be fair 
> amount of improvisation...
> 
> Are you coming to this week's HaskellerZ meetup? We could chat a bit more 
> about this.
> 
> Cheers!
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Backing up and downloading Trac contents?

[Niklas Hambüchen]

Working on something today, it came to my mind how much useful
information is stored in Trac and how much time would get lost if it
went down, corrupted or missing.

With the source code there's no such issue as with git being a DVCS,
everybody has the full history. But not so with Trac.

Are there backups of Trac?
Are there some publicly available ones that one could download and thus
conveniently use offline?

Thanks!
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: DoAndIfThenElse

[Niklas Hambüchen]

I've filed https://ghc.haskell.org/trac/ghc/ticket/14842 for it.

On 09/02/2018 10.24, Simon Peyton Jones via ghc-devs wrote:
> At very least the extension should be documented! Would you like to open
> a ticket for that?  And even offer a patch?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

ZuriHac 2018 GHC DevOps track - Request for Contributions

[Niklas Hambüchen]

Hi GHC devs,

The ZuriHac 2018 conference will feature a GHC DevOps track (which
Andreas and I are coordinating), that will be all about fostering
contributions to GHC and learning to hack it. There will be a room or
two allocated at Zurihac for this purpose.

We hope to focus on roughly these topics:

* How to build GHC from source
* How to iterate on changes quickly
* What's the development workflow, how do I get my patch merged?
* How do specific parts of GHC work
* Extending GHC's test suite
* Improving automation, processes and release quality
* Documenting the undocumented

If we are successful, we will have more GHC contributers after ZuriHac
than before.

But we need your contributions to add content to the track!

Specifically, we're looking for ZuriHac attendees who could (help) run a
session in this track. Such as:

* Giving a talk about one of the above or related topics
* Hosting a hack session where participants of the track work together
on the GHC code base towards a specific goal
* Being around as a "GHC mentor" during open hack sessions, helping new
GHC contributors out

To give some examples, I could offer to give a talk on a recent effort
to improve Ctrl+C and signal handling in the RTS, and I would like to
run a hack session where we add performance regression tests based on
CPU instruction counters.

Please contact Andreas or me (on this list or privately) if you think
you could help in any of these directions!
If you're not sure, contact us anyway and tell us your idea!

Best,
Niklas and Andreas
ZuriHac 2018 GHC DevOps track coordinators
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: ZuriHac 2018 GHC DevOps track - Request for Contributions

[Niklas Hambüchen]

On 07/04/2018 16.06, Oleg Grenrus wrote:
> I hope Hadrian topics qualify under "building GHC from source"?

Of course!
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Phabricator workflow vs. GitHub

[Niklas Hambüchen]

There are some things in these argumentations that I don't get.

When you have a stack of commits on top of master, like:

* C
|
* B
|
* A
|
* master

What do you use as base for `arc diff` for each of them?

If B depends on A (the patch expressed by B doesn't apply if A was applied 
first),
do you still use master as a base for B, or do you use Phabricator's feature to 
have diffs depend on other diffs?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Parser.y rewrite with parser combinators

[Niklas Hambüchen]

Another thing that may be of interest is that parser generators can guarantee 
you complexity bounds of parsing time (as usual, the goal is linear).

Some of the conflicts that annoy us about parser generators are often hints on 
this topic; if the parser generator succeeds, you are guaranteed to have a 
linear parser.

If backtracking is allowed in parser combinators, it is comparatively easy to 
get that wrong.

Niklas
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Gitlab email

[Niklas Hambüchen]

Hey Simon,

try the checkbox setting "Receive notifications about your own activity" at

https://gitlab.haskell.org/profile/notifications

In Gitlab thread https://gitlab.com/gitlab-org/gitlab-ce/issues/26395 somebody 
requested "Send email notifications to yourself for your own comments", and 
this checkbox is what people claimed there implements it.

Niklas
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Can't build HEAD with the old build system

[Niklas Hambüchen]

Can you reproduce this reliably?

Googling the error message "internal error in find_view" yields:

  https://www.mail-archive.com/bug-binutils@gnu.org/msg28716.html

where somebody encountered it, but only in proprietary code.
It would probably be very useful if we could provide a repro of it in an 
open-source code base like GHC.

By the way, the attachment there is called "Corrupt elf file which causes 
linker to crash", so perhaps you also have a corrupt ELF file somewhere?

Niklas
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Can't build HEAD with the old build system

[Niklas Hambüchen]

That sounds good. A few more questions:

What's the exact version of your OS, and of gold?

After getting to the error, can you run the failing ghc invocation directly, 
and see if the error remains? The one starting with

"/home/omer/ghc_bins/ghc-8.6.4-bin/bin/ghc" -o
utils/hsc2hs/dist/build/tmp/hsc2hs ...

If yes, can you add a `-v` to it, so we can see the invocations to the programs 
it calls?

Then, it should show a gcc invocation (which eventually calls gold).
Can you then manually run and add a `-v` to to the gcc invocation as well, so 
we can see the linker command it runs (see also 
https://stackoverflow.com/questions/1170809/how-to-get-gcc-linker-command)?
You may have to run ghc with `-keep-tmp-files` if it invokes the gcc on 
temporary files.

Finally, can you run the printed ld.gold invocation manually, and add a `-v` to 
that, so we get more detail about what gold is doing?

If you are on Linux (and also in some other cases), you can also run ghc under 
`strace -fy -e execve` to see all programs started recursively by any 
subprogram; this may also easily provide the linker invocation.

Thank you!

On 01/04/2019 7:35 AM, Ömer Sinan Ağacan wrote:
> Yeah I can reproduce it reliably. I tried a few `git clean -xfd`s, and tried
> with no build.mk and with a debug build.mk, it happened with all 
> configurations,
> when building the same file (the hsc2hs executable).
> 
> The repro is simple: clone the GHC repo, build at 6f7115dfd4. If this doesn't
> reproduce the bug then I don't know what else to try.
> 
>> so perhaps you also have a corrupt ELF file somewhere
> 
> How do I check this? Maybe gold.ld produces a corrupt ELF file during the 
> build,
> and then tries to read it to link an executable.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Can't build HEAD with the old build system

[Niklas Hambüchen]

r/lib/../lib", 
"-L/usr/lib/gcc/x86_64-linux-gnu/5/../../..", "--no-as-needed", "-lm", 
"--gc-sections", "utils/hsc2hs/dist/build/Main.o", 
"utils/hsc2hs/dist/build/C.o", "utils/hsc2hs/dist/build/Common.o", 
"utils/hsc2hs/dist/build/CrossCodegen.o", 
"utils/hsc2hs/dist/build/DirectCodegen.o", "utils/hsc2hs/dist/build/Flags.o", 
"utils/hsc2hs/dist/build/HSCParser.o", "utils/hsc2hs/dist/build/ATTParser.o", 
"utils/hsc2hs/dist/build/UtilsCodegen.o", 
"utils/hsc2hs/dist/build/Compat/ResponseFile.o", 
"utils/hsc2hs/dist/build/Paths_hsc2hs.o", "/tmp/ghc2447_0/ghc_2.o", 
"/tmp/ghc2447_0/ghc_5.o", "-u", "base_GHCziTopHandler_runIO_closure", "-u", 
"base_GHCziTopHandler_runNonIO_closure", "-u", 
"ghczmprim_GHCziTuple_Z0T_closure", "-u", "ghczmprim_GHCziTypes_True_closure", 
"-u", "ghczmprim_GHCziTypes_False_closure", "-u", 
"base_GHCziPack_unpackCString_closure", "-u", 
"base_GHCziWeak_runFinalizzerBatch_closure", "-u", 
"base_GHCziIOziException_stackOverflow_closure", "-u", 
"base_GHCziIOziException_heapOverflow_closure", "-u", 
"base_GHCziIOziException_allocationLimitExceeded_closure", "-u", 
"base_GHCziIOziException_blockedIndefinitelyOnMVar_closure", "-u", 
"base_GHCziIOziException_blockedIndefinitelyOnSTM_closure", "-u", 
"base_GHCziIOziException_cannotCompactFunction_closure", "-u", 
"base_GHCziIOziException_cannotCompactPinned_closure", "-u", 
"base_GHCziIOziException_cannotCompactMutable_closure", "-u", 
"base_ControlziExceptionziBase_absentSumFieldError_closure", "-u", 
"base_ControlziExceptionziBase_nonTermination_closure", "-u", 
"base_ControlziExceptionziBase_nestedAtomically_closure", "-u", 
"base_GHCziEventziThread_blockedOnBadFD_closure", "-u", 
"base_GHCziConcziSync_runSparks_closure", "-u", 
"base_GHCziConcziIO_ensureIOManagerIsRunning_closure", "-u", 
"base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure", "-u", 
"base_GHCziConcziSignal_runHandlersPtr_closure", "-u", 
"base_GHCziTopHandler_flushStdHandles_closure", "-u", 
"base_GHCziTopHandler_runMainIO_closure", "-u", 
"ghczmprim_GHCziTypes_Czh_con_info", "-u", "ghczmprim_GHCziTypes_Izh_con_info", 
"-u", "ghczmprim_GHCziTypes_Fzh_con_info", "-u", 
"ghczmprim_GHCziTypes_Dzh_con_info", "-u", "ghczmprim_GHCziTypes_Wzh_con_info", 
"-u", "base_GHCziPtr_Ptr_con_info", "-u", "base_GHCziPtr_FunPtr_con_info", 
"-u", "base_GHCziInt_I8zh_con_info", "-u", "base_GHCziInt_I16zh_con_info", 
"-u", "base_GHCziInt_I32zh_con_info", "-u", "base_GHCziInt_I64zh_con_info", 
"-u", "base_GHCziWord_W8zh_con_info", "-u", "base_GHCziWord_W16zh_con_info", 
"-u", "base_GHCziWord_W32zh_con_info", "-u", "base_GHCziWord_W64zh_con_info", 
"-u", "base_GHCziStable_StablePtr_con_info", "-u", "hs_atomic_add8", "-u", 
"hs_atomic_add16", "-u", "hs_atomic_add32", "-u", "hs_atomic_add64", "-u", 
"hs_atomic_sub8", "-u", "hs_atomic_sub16", "-u", "hs_atomic_sub32", "-u", 
"hs_atomic_sub64", "-u", "hs_atomic_and8", "-u", "hs_atomic_and16", "-u", 
"hs_atomic_and32", "-u", "hs_atomic_and64", "-u", "hs_atomic_nand8", "-u", 
"hs_atomic_nand16", "-u", "hs_atomic_nand32", "-u", "hs_atomic_nand64", "-u", 
"hs_atomic_or8", "-u", "hs_atomic_or16", "-u", "hs_atomic_or32", "-u", 
"hs_atomic_or64", "-u", "hs_atomic_xor8", "-u", "hs_atomic_xor16", "-u", 
"hs_atomic_xor32", "-u", "hs_atomic_xor64", "-u", "hs_cmpxchg8", "-u", 
"hs_cmpxchg16", "-u", "hs_cmpxchg32", "-u", "hs_cmpxchg64", "-u", 
"hs_atomicread8", "-u", "hs_atomicread16", "-u&q

Re: Request for comments on dry-run Trac -> GitLab migration

[Niklas Hambüchen]

I find that commits aren't mentioned on the corresponding issues, for example 
there's no equivalent of

https://ghc.haskell.org/trac/ghc/ticket/13497#comment:27

on

https://gitlab.staging.haskell.org/ghc/ghc/issues/13497

I vaguely remember these "commit posts" being discussed before somewhere.
But that's not even what I'm after.

The commit itself mentions the ticket ("This fixes #13497").
Usually when such a commit is pushed to Gitlab, it automatically creates an 
entry like:

 Niklas Hambüchen @nh2 mentioned in commit abc123456 3 months ago

But this isn't the case here.
Is it because the issues were imported *after* the repo commits already exist?

Can it be fixed?
E.g. can Gitlab be told to re-index the repo accordingly?
Or could it be done by deleting `master` and re-pushing the entire history?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Request for comments on dry-run Trac -> GitLab migration

[Niklas Hambüchen]

On 05/02/2019 4:49 AM, Ben Gamari wrote:> Yes, this is the cause and the import 
does handle this; I just (yet

again) forgot to rerun this stage of the import. This should be fixed now.


For me, nothing seems to have changed on 
https://gitlab.staging.haskell.org/ghc/ghc/issues/13497
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Pushing to gitlab.haskell.org

[Niklas Hambüchen]

Hey Simon,

you mention SSH keys, but in your quoted config I can see HTTPS, not SSH:

> [remote "origin"]
>   url = https://gitlab.haskell.org/ghc/ghc

Should this perhaps be

url = g...@gitlab.haskell.org:ghc/ghc.git

instead?

> So I tried ssh -v gitlab.haskell.org

You need to include the user name "git" for this. Otherwise it will try to use 
your local user name on the remote server.
This is the command to run and the output you should get if it's working:

$ ssh g...@gitlab.haskell.org
PTY allocation request failed on channel 0
Welcome to GitLab, @nh2!
Connection to gitlab.haskell.org closed.

Hope this helps,

Niklas
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Justifying sched_yield() in the RTS

[Niklas Hambüchen]

There are more related updates in 
https://gitlab.haskell.org/ghc/ghc/issues/9221, also including a short 
discussion of Linus's post.

Simon Marlow's overall response was:

> I'm very supportive of making this better, but as usual I will require 
> thorough data to back up any changes :)
>
> Everything I tried in the past made things worse. Including an experiment I 
> did to use futexes directly: 
> https://gitlab.haskell.org/ghc/ghc/issues/3553?cversion=0_hist=14#note_39009

So it sounds like this topic is currently in the stage of:

Somebody needs to take the time to re-do that benchmark done 10 years ago.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [Haskell-cafe] Decorating exceptions with backtrace information

[Niklas Hambüchen]

On 5/12/20 10:55 PM, Henning Thielemann wrote:
> "This operation may fail with:
> 
> * ResourceVanished if the handle is a pipe or socket, and the reading end is 
> closed."
> 
> That is, ResourceVanished is part of the public interface and in no way 
> unexpected (or what "unintended" may be). I would prefer to make this 
> explicit in the type of hPutBuf:
> 
> hPutBuf ::
>    (ResourceVanishedException e) =>
>    Handle -> Ptr a -> Int -> ExceptT e IO ()
> 
> Now, what do you intend to do with the call-stack? Isn't it something you can 
> attach to the e value?

Why is this relevant?

The point of debugging is to find programming errors.
It does not matter what the Haddocks say; if a programmer uses the function 
wrong, the exception will occur.

hPutBuf does not currently have that type, nor can anybody rewrite all the 
existing libraries easily.

The point of the proposal is to make the RTS help us debug problems in code as 
it exists today.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [Haskell-cafe] Decorating exceptions with backtrace information

[Niklas Hambüchen]

On 5/8/20 5:37 PM, Henning Thielemann wrote:
> I can imagine that it would be helpful for the user to get a stacked 
> exception information like:
>    Parse error on line 42, column 23
>    while reading file "foo/bar"
>    while traversing directory "blabla"

That seems to be rather specific use case.
It'd be a cool feature but I'm not aware of any programming language following 
that interpretation so far.

I personally would be happy to be able to get the same type of stack trace for 
exceptions as in other programming langues (and as the proposal suggests).

> If you must debug exceptions, then this sounds like exceptions were abused 
> for programming errors.

I'd be pretty happy to be able to debug them better; no matter if they were 
"abused" for anything or not, I must still debug them in practice.

Given that they traverse program flow invisibly (e.g. not lexically, like 
return values) and can become visible in different places than they arose, 
having a call stack to debug their creation would be useful.

> a callstack is not useful for a user.

Call stacks have been very useful to me as a user of non-Haskell tools so far, 
because they are excellent for attaching to bug reports and usually led to 
developers fixing my problems faster.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [Haskell-cafe] Decorating exceptions with backtrace information

[Niklas Hambüchen]

On 5/8/20 7:32 PM, Henning Thielemann wrote:
> This confirms that they are not for you, but you only forward them to the 
> developer.

Yes, stack traces are in general for developers.

> Can someone please give me examples where current state lacks

* Currently stack traces are not printed, so users cannot forward them to the 
developer, even if both the users and the developers would like that.
* Developers cannot easily produce stack traces do debug unintended exceptions.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [Haskell-cafe] Decorating exceptions with backtrace information

[Niklas Hambüchen]

On 5/8/20 7:52 PM, Henning Thielemann wrote:
> We are talking about the HasCallStack stack traces, yes?
> How is their emission addressed by extending exceptions with stack traces?

The way I understand the proposal, we may be equally talking about DWARF or 
profiling cost-center based stack traces.
From a debugging perspective, I guess the developer does not care so much about 
which implementation is used, as long as the trace points out the code path 
that led to the creation of the exception.

> What are "unintended exceptions"?
> What is an example of an "unintended exception"?

A recent example from my production server:

hPutBuf: resource vanished (Broken pipe)

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC Logo

[Niklas Hambüchen via ghc-devs]

Hey Ben,

it may make sense to make a copy of the SVG that has the font turned into paths;
for me it looks different in Firefox, Thunderbird, and eog, probably because I 
don't have the font installed.
(This is probably also why the logo is cut off for me in some of them).
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: The future of Phabricator

[Niklas Hambüchen via ghc-devs]

For those interested:

Three years later, Phabricator shut down.

May 29, 2021:
https://admin.phacility.com/phame/post/view/11/phacility_is_winding_down_operations/

On 10/30/18 5:54 AM, Ben Gamari wrote:
> For one, at this point we have no options for support in the event that
> something goes wrong as the company responsible for Phabricator,
> Phacility, has closed their support channels to non-paying customers.
> Furthermore, in the past year or two Phacility has been placing their
> development resources in the parts their customers pay them for, which
> appear to be much different that the parts that we actively use. For
> this reason, some parts that we rely on seem oddly half-finished.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs