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 wro
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).
_
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 w
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
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 use
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
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 :)
>
> Every
Not sure if the reason, but there was a BGP problem on the Internet today:
https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today/
On 24/06/2019 8:07 PM, Alan & Kim Zimmerman wrote:
> 502 is a gateway timeout, maybe it is the CDNs gone flaky
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 u
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
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", &q
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/t
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 a
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
___
ing 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 mont
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 h
> I think the article is assuming the base for `arc diff` is always the parent
> revision, i.e. `arc diff HEAD^`, which is how the workflow works best.
> Strangely I don't think the open source Phabricator is set up to do this by
> default so you have to actually type `arc diff HEAD^`
Perhaps t
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
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 t
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
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
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 readFi
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 abov
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 `int
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
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 topi
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-
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
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 nu
Hey Ben,
I haven't heard of a single concern of enabling botbot.me over the last
3 months.
Can we go ahead and enable it?
All we need is a channel op to fill out https://botbot.me/request/.
On 12/07/17 17:29, Ben Gamari wrote:
> I am very much in favor of doing something about this. Unfortunate
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/c
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, Take
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 everythi
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
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 d
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 f
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 `g
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)
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
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
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
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:2
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
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
> ov
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.
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 dis
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 al
On 28/08/15 13:46, Ben Gamari wrote:
> 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.
One thing I don't understand in this discussion:
Why need th
On 21/04/15 01:29, Niklas Hambüchen wrote:
> 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!
Here's a 64-bit Linux binary distribution of 7.10 including this backport:
https://github.com/nh2/ghc/releases/tag
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/
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/mail
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 librarie
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.
53 matches
Mail list logo
