Re: GHCi and line numbers (with ghc-7.4.1)
On 20/03/2012 20:12, Simon Hengel wrote: Hi, ghc --interactive now behaves different in regards to line numbers in error messages than previous versions. They are now incremented with each evaluated expression. $ ghc --interactive -ignore-dot-ghci Prelude foo interactive:2:1: Not in scope: `foo' Prelude bar interactive:3:1: Not in scope: `bar' Is there a way to disable this (or alternatively reset the counter for a running session)? Sorry, there's no way to reset it at the moment. What do you need that for? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCi and line numbers (with ghc-7.4.1)
On 22 March 2012 12:13, Simon Marlow marlo...@gmail.com wrote:
On 20/03/2012 20:12, Simon Hengel wrote:
They are now incremented with each evaluated expression.
Why *are* they incremented with each evaluation? Surely the only use
for line numbers would be in multi-line statements:
:{
Prelude| do x - [1..10]
Prelude| return y
Prelude| :}
interactive:6:11: Not in scope: `y'
Would it not make more sense to have
interactive:2:11: Not in scope: `y'
as it would do if compiling the file in a source file? From the older
GHCs, this always gives 1, indicating that multi-line statements are
somehow parsed and collapsed before being compiled, or maybe the line
number was just hard coded to 1.
FWIW, in my Emacs mode (making good progress on adding to
haskell-mode) I use the column number in the REPL to highlight on the
line where the problem is (e.g. here
http://chrisdone.com/images/hs-repl-error-demo.png), for GHC 7.* with
proper multi-line support I will automatically wrap any multi-line
expressions entered in the REPL in :{ and :}, it would be cool for
line numbers in errors to be useful for that. (Arguably we should be
using the GHC API and Scion or something like it, but these change
quite often and are hard to support whereas interfacing with GHCi is
quite stable across around seven releases and just works.)
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCi and line numbers (with ghc-7.4.1)
ghc --interactive now behaves different in regards to line numbers in error messages than previous versions. They are now incremented with each evaluated expression. $ ghc --interactive -ignore-dot-ghci Prelude foo interactive:2:1: Not in scope: `foo' Prelude bar interactive:3:1: Not in scope: `bar' Is there a way to disable this (or alternatively reset the counter for a running session)? Sorry, there's no way to reset it at the moment. What do you need that for? I use ghci for doctest [1] to evaluate examples. All examples within one Haddock comment are grouped to a /session/. And I reuse the same ghci process to run several sessions. Before a new session is run, I try (as far as possible) to reset ghci into a pristine state. The counter for line numbers is just one more thing that is carried over. A contrived example where this makes a difference is at [2]. I think this is not critical. But putting doctest aside, I still preferred the old behavior. Cheers, Simon [1] http://hackage.haskell.org/package/doctest [2] http://hpaste.org/65736 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
7.4.2 release plans
Hi all, Just a quick note to let you know about our release plans: We plan to put out a GHC 7.4.2 release candidate around the end of the March. The final release will probably not happen until around the end of April. Thanks Ian, on behalf of the GHC team ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Stealing ideas from the latest GCC release
Hi all,
While looking at the GCC 4.7 [1] release notes I saw something that's
perhaps worth stealing. Taken from the release notes:
The inter-procedural constant propagation pass has been rewritten. It
now performs generic function specialization. For example when
compiling the following:
void foo(bool flag)
{
if (flag)
... do something ...
else
... do something else ...
}
void bar (void)
{
foo (false);
foo (true);
foo (false);
foo (true);
foo (false);
foo (true);
}
GCC will now produce two copies of foo. One with flag being true,
while other with flag being false. This leads to performance
improvements previously possibly only by inlining all calls. Cloning
causes a lot less code size growth.
I found myself wanting something like this just today. A common
pattern I see in code is this:
data Options = Options { ... }
defaultOptions :: Options
defaultOptions = ...
foo :: ...
foo = fooWith defaultOptions
fooWith :: Options - ...
fooWith = ...
It'd be nice if we could get foo to specialize on its input arguments,
without having to mark all of fooWith as INLINE.
1. http://gcc.gnu.org/gcc-4.7/changes.html
-- Johan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Stealing ideas from the latest GCC release
On Thu, Mar 22, 2012 at 5:09 PM, Johan Tibell johan.tib...@gmail.comwrote:
Hi all,
While looking at the GCC 4.7 [1] release notes I saw something that's
perhaps worth stealing. Taken from the release notes:
The inter-procedural constant propagation pass has been rewritten. It
now performs generic function specialization. For example when
compiling the following:
void foo(bool flag)
{
if (flag)
... do something ...
else
... do something else ...
}
void bar (void)
{
foo (false);
foo (true);
foo (false);
foo (true);
foo (false);
foo (true);
}
GCC will now produce two copies of foo. One with flag being true,
while other with flag being false. This leads to performance
improvements previously possibly only by inlining all calls. Cloning
causes a lot less code size growth.
Wait, I thought this is essentially what constructor specialization does?
I suppose we might then keep around the old body. Or will these behave
differently in the presence of, say, different constant Int arguments?
-Jan-Willem Maessen
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Stealing ideas from the latest GCC release
I support a form of this in jhc by allowing specialization of values,
not just types.
It is actually the same mechanism as type specialization since that is
just value specialization where the value being specialized on is the
type parameter.
foo :: Bool - Int
{-# SPECIALIZE foo True :: Int #-}
(I think this is the current syntax, I changed it a couple times in
jhc's history)
will create a
foo_True :: Int
foo_True = inline foo True
and a
{-# RULE foo True = foo_True #-}
John
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Stealing ideas from the latest GCC release
On Thu, Mar 22, 2012 at 3:52 PM, Jan-Willem Maessen jmaes...@alum.mit.edu wrote: Wait, I thought this is essentially what constructor specialization does? I suppose we might then keep around the old body. Or will these behave differently in the presence of, say, different constant Int arguments? We do want to keep around the old body (but constructor specialization already does that.) We also want to be able to specialize things like 5 :: Int, which I don't think constructor specialization handles. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 7.4.2 release plans
On Thu, Mar 22, 2012 at 6:49 AM, Ian Lynagh ig...@earth.li wrote: Hi all, Just a quick note to let you know about our release plans: We plan to put out a GHC 7.4.2 release candidate around the end of the March. The final release will probably not happen until around the end of April. Looking forward to it... will it have :seti and the why did this recompile patches? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
