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
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:
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:
*
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
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
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
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
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
>
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
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
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
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
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
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)
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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?
___
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
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
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
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
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
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
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
ot;, "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_
sed 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
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
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
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 :)
>
>
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
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
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
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
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).
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
48 matches
Mail list logo
