It seems the OS X distribution is missing profiling libs, details at
https://gitlab.haskell.org/ghc/ghc/-/issues/20707 but that's basically
the whole story :)
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/
The issue uses consistency with -odir and -hieDir as a
rationalization. I think it's not quite right because inputs can have
a search path while outputs don't, but if it is true that -odir
simultaneously sets the output and input dir for `*.o`, that seems
confusing too. Shouldn't -odir set *only*
Hi, I read your post back when you posted it and meant to respond, but got
distracted! Anyway, I think the profiling tools in ghc could definitely use
some attention, so I'm glad you're looking into this!
The below is going to seem like a rant, and maybe it is in some parts, but
I mean it to be a
I'm not sure if I'm doing the same thing as you, but I use a GHC repl
for my program. It loads a 200-300 modules in under a second, and is
able to reload changed ones dynamically, just like ghci.
The source is https://github.com/elaforge/karya/blob/work/Cmd/ReplGhc.hs,
see 'parse_flags' and its c
Where I work we use marge, and I wound up adding a patch to run an
especially expensive "on merge only" CI run. The two pieces are:
- patch marge to add a --require-ci-run-by-me flag, which makes marge
want to see a CI completion by margebot and start one otherwise
- modify the .gitlab-ci.yml to
At work we use "marge bot", https://github.com/smarkets/marge-bot
which is an automatic bot that will do the rebase and resubmit thing.
I think it's pretty essential, because otherwise any intervening merge
means you have to babysit the merge button. It's also more efficient
if you have expensive
On Tue, Jan 8, 2019 at 8:54 PM Simon Peyton Jones wrote:
> | > When submitting a review, I often want to add an overall comment, not
> | related to a particular line of code? How do I do that?
> |
> | I do that by going back to the "Discussion" tab and adding something at the
> | bottom.
>
>
On Tue, Jan 8, 2019 at 6:01 PM Simon Peyton Jones via ghc-devs
wrote:
>
> When reviewing a MR, I sometimes want to look at (and even add comments to)
> code that isn’t displayed in the MR window. With Phab there was a “show 20
> more lines” link, and even “show the whole file”. How do I do tha
The diff in https://gitlab.haskell.org/ghc/ghc/merge_requests/10/diffs
is the ground truth for the source code. However, it's not ground
truth for comments. You only get to see the ones attached to the
revisions selected in "Changes between x and y", which means they tend
to get lost. The Discus
There are some incomplete sentences under "Further improvements to
runtime performance:"
Also, congratulations to Tamar Christina for becoming the new IO manager!
Also, when I copy paste the links in the "At the time of writing"
section, the backslashes in the search query mess it up. Maybe a
ma
On Thu, Oct 18, 2018 at 12:23 AM Kazu Yamamoto wrote:
> > I met the same problem.
>
> See https://ghc.haskell.org/trac/ghc/ticket/15769 for workaround.
Thanks for the note, this helped me find a solution. I updated the
ticket with my experience.
___
gh
Has anyone installed the OS X binary distribution? I get:
"utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy
libraries/ghc-prim dist-install "strip" '' '/usr/local'
'/usr/local/lib/ghc-8.6.1'
'/usr/local/share/doc/ghc-8.6.1/html/libraries' 'v p dyn'
dyld: Library not loaded: /usr/loc
Tiny bug, so I'll just throw it out here instead of trying to get arc
set up again:
aclocal.m4 line 2438, at head (commit
7e77f41430ae1cad84d5b0c90328331d38f3eda0) has # typo'd as $. It
causes a harmless but alarming error in configure.
Also `ld --version` causes an error on OS X since OS X ld d
I agree that tags are necessary, and in fact I recently ported my
internal debug library to cabal because now that I'm doing more stuff
with cabal I find life too difficult without my accustomed debug
library. For reference, it is this, but nothing fancy:
https://github.com/elaforge/el-debug/blob/
On Fri, Jun 8, 2018 at 11:46 AM, Simon Marlow wrote:
> I'm slightly surprised that it keeps breaking for you, given that this is a
> core feature of GHCi and we have multiple tests for it. You'll need to
> remind me - what were the bugs specifically? Maybe we need more tests.
Most recently, 8.2
On Fri, Jun 8, 2018 at 12:29 AM, Simon Marlow wrote:
> heap profiler for a while. However, I imagine at some point loading
> everything into GHCi will become unsustainable and we'll have to explore
> other strategies. There are a couple of options here:
> - pre-compile modules so that GHCi is load
On Thu, Jun 7, 2018 at 2:48 PM, Bartosz Nitka wrote:
> What version of GHC are you using?
> There have been some significant improvements like
> https://phabricator.haskell.org/rGHCb8fec6950ad99cbf11cd22698b8d5ab35afb828f,
> that only just made it into GHC 8.4.
I did in fact notice a very nice sp
On Thu, Jun 7, 2018 at 1:47 PM, Simon Marlow wrote:
> For loading large amounts of code into GHCi, you want to add -j +RTS
> -A128m where is the number of cores on your machine. We've found that
> parallel compilation works really well in GHCi provided you use a nice large
> allocation area for t
On Tue, May 29, 2018 at 11:46 PM, Kim-Ee Yeoh wrote:
>> It turns out that git checkouts update the modtime on checked-out files,
>> even
> when they get reverted back to their original contents.
>
> Looks to me the problem's right here. Namely, git checkout.
>
> If the contents didn't change, the
After switching to git, I discovered that ghci is interpreting a lot of modules
when it should have loaded the .o files (i.e. I get 'SomeModule (interpreted)'
instead of 'Skipped SomeModule').
It turns out that git checkouts update the modtime on checked-out files, even
when they get reverted back
Also -fdefer-type-errors in ghci is broken for 8.4:
https://ghc.haskell.org/trac/ghc/ticket/14963
I understand it's a complicated problem, but it would be sad if it
were broken for all of 8.6 as well.
At least how about a quick patch that emits a warning when it sees
--interactive -fdefer-type-e
On Wed, May 2, 2018 at 12:27 PM, Simon Peyton Jones
wrote:
> Wow. Could you open a ticket?
Done: https://ghc.haskell.org/trac/ghc/ticket/15114
> I just tried with 8.2.2 which is what I have on this laptop, but it printed
> "all is well". Does that mean it was fine in 8.2, went wrong in 8.4.1
Ok, here's a short module:
import qualified Control.Exception as Exception
main :: IO ()
main = do
unserialize
putStrLn "all is well"
unserialize :: IO Char
unserialize =
if definitelyTrue
then do
return 'a'
else do
Exception.evaluate (error "w
On Wed, May 2, 2018 at 1:24 AM, Simon Peyton Jones
wrote:
> | I recently noticed that with -O1, ghc was optimizing some code
> |
> | if Trace.traceShowId "b" $ True
> | then ...
> | else ...
> |
> | to always evaluate the 'else' branch.
>
> Are you certain this is #13930?
On Tue, May 1, 2018 at 9:58 PM, Ben Gamari wrote:
> Yes, I suppose the language in the release notes does rather understate
> the degree of the incorrectness.
>
> I'll push a new version of the manual with some stronger language
> tomorrow.
Good deal, thanks for the quick response.
__
I recently noticed that with -O1, ghc was optimizing some code
if Trace.traceShowId "b" $ True
then return $ Left $ Serialize.BadMagic (Serialize.magicBytes
magic) file_magic
else first Serialize.UnserializeError <$> Exception.evaluate
(Serialize.decode rest)
to always evaluat
I just filed this bug:
#14963: ghci -fdefer-type-errors can't run IO action from another module
https://ghc.haskell.org/trac/ghc/ticket/14963
It seems like -fdefer-type-errors and ghci just don't get along at all now.
But on the good news side, ghci reloading a changed module in 8.4.1 is
much
Ok, done, I created https://ghc.haskell.org/trac/ghc/ticket/14964
But first:
On Thu, Mar 22, 2018 at 3:26 AM, Simon Peyton Jones
wrote:
> score max mb total mb prdderive lily perform
> ghc
> 6 72.26 3279.22 0.88 0.79~0.84 0.70~0.74 0.31~0.33
> 8.0.
I have my own list library with a bunch of things like this. I think
it's what most people do, and some upload them to hackage, e.g.
utility-ht or the split package, or data-ordlist.
Specifically, I think rollingGroupBy is what I call splitWith:
-- | Split @xs@ before places where @f@ matches.
-
https://ghc.haskell.org/trac/ghc/ticket/13604 was just closed, I look
forward to trying it out. Thanks to dfeuer for the fix!
On Wed, Nov 22, 2017 at 12:41 AM, Simon Marlow wrote:
> David,
>
> Perhaps it would be good to defer changing the behaviour of :load *M (I
> believe you that it's hard, t
Here's what I use:
:set prompt "\ESC[46m\STX%s>\ESC[39;49m\STX "
I believe \STX is a signal to haskeline for control sequences.
Documentation is here:
https://github.com/judah/haskeline/wiki/ControlSequencesInPrompt
On Tue, Dec 5, 2017 at 12:57 PM, Brandon Allbery wrote:
> On Tue, Dec 5, 2017 a
On Sun, Nov 5, 2017 at 4:56 AM, Sven Panne wrote:
> This is not an issue about 8.2.2 per se, but 8.2 changes in general: Recent
> discussions on Haskell Cafe showed serious problems with Emacs' haskell-mode
> due to some ad hoc changes like https://phabricator.haskell.org/D3651.
I've long used gh
On Wed, Nov 1, 2017 at 1:46 AM, Simon Peyton Jones via ghc-devs
wrote:
> I'm lost.
>
> * What causes the undesired behaviour in GHC 8.2.1?
> Is it this?
> - GHCi wants to load module B with flags F
> - There is a B.o but the flags differ
> - So GHCi recompiles B to bytecode
>
> * How
I updated the trac ticket, but here's a copy-paste:
I still don't feel like 1 is necessary, I'd rather flags cause other
flags to be ignored with a warning, rather than turn on other flags.
But that's just a vague preference, with no strong evidence for it.
Maybe it could emit a warning if you did
I'd like to see this fixed: https://ghc.haskell.org/trac/ghc/ticket/13604
It's a show stopper that prevented me from being able to use 8.2 at all.
Once again, if no one has time to address it, I'd be happy to take a
look myself.
On Mon, Oct 9, 2017 at 9:15 AM, Ben Gamari wrote:
> Hello everyone
On Fri, Sep 1, 2017 at 2:23 PM, Wolfgang Jeltsch
wrote:
> Hi!
>
> Before starting with generics support at the type level, please first
> improve the generics support at the value level. When I looked at it the
> last time, there were some apparent leftovers in the form of types or
> type paramete
le from
> these packages, so that it can be installed without using some Linux
> distribution package manager.
>
> All the best,
> Wolfgang
>
> Am Mittwoch, den 26.07.2017, 18:45 -0700 schrieb Evan Laforge:
>> This seems like a silly question, but how can we install cabal-install
>
This seems like a silly question, but how can we install cabal-install
now? The latest hackage version 1.24.0.2 has Cabal (>=1.24.2 &&
<1.25), but it looks like ghc Cabal is now at 2.*.
I ran into this because if I get:
% cabal install --only-dependencies
Resolving dependencies...
cabal: interna
On Fri, Jul 7, 2017 at 9:28 AM, Ben Gamari wrote:
> Ryan Scott writes:
>
>> Another things to note about 8.2 build times is that a bulk of the time is
>> probably being spent during the linking phase. This is because GHC 8.2 has
>> switched over to split-sections by default, but unfortunately, ol
This is a bit off topic, but is there a collection of not-so-great
error messages along with opinions about what they should be? Like a
wiki page or something?
I just stumbled across one and was going to complain, but didn't know
the most productive way to do that, aside from try to fix it myself
Way back when I started with haskell I noticed this, and switched to using
this:
-- | Enumerate an inclusive range. Uses multiplication instead of
successive
-- addition to avoid loss of precision.
--
-- Also it doesn't require an Enum instance.
range :: (Num a, Ord a) => a -> a -> a -> [a]
range
On Tue, Jun 28, 2016 at 12:15 PM, Christopher Done wrote:
> Thanks! It's strange to think there was once no GHCi. This is an interesting
> piece of Haskell implementation history! =)
It was really exciting when ghci showed up. No need to separately
load everything into hugs!
There was recently a discussion about it, search for subject "Can we
improve Show instance for non-ascii charcters?"
You can read for yourself but my impression was that people were
generally favorable, but had some backward compatibility worries, and
came up with some workarounds, but no one comm
On Wed, Feb 17, 2016 at 2:14 AM, Edward Z. Yang wrote:
> Another large culprit for performance is that the fact that ghc --make
> must preprocess and parse the header of every local Haskell file:
> https://ghc.haskell.org/trac/ghc/ticket/618 (as well
> as https://ghc.haskell.org/trac/ghc/ticket/12
On Wed, Feb 17, 2016 at 4:38 AM, Ben Gamari wrote:
> Multiple modules aren't a problem. It is dependencies on Hackage
> packages that complicate matters.
I guess the problem is when ghc breaks a bunch of hackage packages,
you can't build with it anymore until those packages are updated,
which won
Also, a call stack frame is just a (name, srcloc) pair, so you can
format it yourself. I use:
show_stack :: CallStack -> String
show_stack = maybe "" show_frame . Seq.last . Stack.getCallStack
where
show_frame (name, srcloc) =
SrcLoc.srcLocFile srcloc ++ ":" ++ show (SrcLoc.srcLoc
On Tue, Nov 24, 2015 at 7:23 PM, Richard Eisenberg wrote:
> Thanks for volunteering to do this work, but I'm afraid now is a terrible
> time to do it. I know of three significant patches that are about to be
> committed, and your reformatting would cause quite a few merge conflicts. If
> there
When I was doing a recent patch, I was annoyed by lint errors about
>80 lines when I was just conforming to the existing style. To avoid
cluttering my commit with unrelated changes, I decided to fix the
lints in a formatting-only commit afterwards. Looking in the
archives, I see there was some re
48 matches
Mail list logo
