Re: Language extensions - backwards compatibility
ia: > I'm looking for a way of specifying language extensions in a way which will > work in all versions of GHC from 6.4 onwards. > > GHC 6.4 does not support the LANGUAGE pragma. Specifying language options in > the OPTIONS_GHC pragma starts to produce deprecation warnings in 6.10, and > will > presumably eventually fail altogether. > > Any sort of preprocessing at the beginning of a file appears to insert enough > noise to inhibit recognition of file-header pragmas. (Cpphs doesn't appear to > help here.) Attempting preprocessing inside a leading OPTIONS_GHC pragma > fails > because it apparently attempts to interpret the pragma *before* invoking the > preprocessor. > > The only remaining option I can see is to have a completely separate version > of > the file for GHC 6.4. Have I missed anything? Could you talk a bit about why you need to support 6.4 onwards -- that seems like quite a burden. Is the effort worth it? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Language extensions - backwards compatibility
I'm looking for a way of specifying language extensions in a way which will work in all versions of GHC from 6.4 onwards. GHC 6.4 does not support the LANGUAGE pragma. Specifying language options in the OPTIONS_GHC pragma starts to produce deprecation warnings in 6.10, and will presumably eventually fail altogether. Any sort of preprocessing at the beginning of a file appears to insert enough noise to inhibit recognition of file-header pragmas. (Cpphs doesn't appear to help here.) Attempting preprocessing inside a leading OPTIONS_GHC pragma fails because it apparently attempts to interpret the pragma *before* invoking the preprocessor. The only remaining option I can see is to have a completely separate version of the file for GHC 6.4. Have I missed anything? -- Iain Alexander i...@stryx.demon.co.uk ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: bug in template haskell (with recursion?)
Sorry for posting this on the wrong mailing list. I added the bug to the tracker here: http://hackage.haskell.org/trac/ghc/ticket/3845 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: tracing messages
On Thu, Jan 28, 2010 at 02:39:56PM +, Simon Marlow wrote:
> On 28/01/2010 14:27, Serge D. Mechveliani wrote:
> >Dear GHC team,
> >
> >this is on tracing in ghc-6.12.1
> >(made from source on Debian Linux i-386-like machine).
> >
> >I wonder what is the reason for this tracing message
> >(starting with `Step1 ...' ):
> >
> >
> >...
> >equations calc =
> >[j< i -> true,
> >m<= p -> true,
> >p<= q -> true,
> >q<= n -> true,
> >(A p)<= (A q) -> false,
> >(X<= Y) | (Y< X) -> true,
> >| {not (Y<= n), not (m<= X), not (X< i), not (j< Y), (A X)<= (A Y)} ->
> >true,
> >| {not (X<= Y), not (Y<= j), not (m<= X), (A X)<= (A Y)} -> true,
> >| {not (XStep 1. Starting mutual pre-reduction. The number of rules is
> >25.
> >Pre-reduction done. Initial numbers of equations is 9,
> >after reduction: 9, the pre-reduction cost is 484.
> >...
> >...
> >
> >
> >The main program does the following in succession:
> >1) finds eqs,
> >2) prints
> >"equations calc =\n", shows eqs "\n\n",
> >"Starting completion.\n",
> >"remaining goals = ",
> >3) finds res by completion (`complete'),
> >4) prints
> > shows (completionGoalRem res) "\n"
> >
> >The trace calls are set only in the function `complete'.
> >The above message
> > Step 1. Starting mutual pre-reduction. The number of rules is 25.
> > Pre-reduction done. Initial numbers of equations is 9,
> >
> >occurs the first message of this tracing.
> >But the main program must have printed the full last equation in
> >eqs, and only after this any tracing message could appear.
> >Instead, it breaks the last equation printing with the tracing messages.
> >The further evaluation is long, so I interrupted it, without seeing the
> >final result. But this printing break looks strange, because eqs
> >does not depend on the results of `complete', the reverse holds: the
> >latter applies to eqs.
> >Generally, I often observe an effect of this kind; it is harmless, but
> >I wonder, what might be the reason.
>
> Perhaps your program output is going to stdout, and the trace messages
> are going to stderr? Buffering would make them appear out of order.
>
> If you're using Debug.trace, I wouldn't recommend that for production
> use, only debugging.
>
> Cheers,
> Simon
Thank you.
Probably, this is the matter of stdout+stderr+bufering.
I run it by Main > & log, and then, see ./log.
-
Serge Mechveliani
mech...@botik.ru
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC core plugins
2010/1/28 José Pedro Magalhães : > Yes, that helped quite a lot. One last thing: currently it takes me about 6 > minutes to rebuild the compiler after I change the core pass. Are there any > tricks of the build system I can use to speed this up? I'm already using a > fast build without optimizations and docs... Hmm. Some things that help with this for me are to: 1) Compile with -j12 (or lower, depending on your hardware spec) 2) Compile with "cd compiler && make stage=2" to only build the stage 2 compiler (if this isn't already happening). Make sure the stage 1 compiler is built with optimisations! (I use the stage2devel configuration, which already does this) This reduces compile times to a few minutes for me. Still tedious, but not too bad. Hope that helps, Max ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC core plugins
Hi Max, 2010/1/27 Max Bolingbroke > 2010/1/27 José Pedro Magalhães : > > Alright, ticket created: http://hackage.haskell.org/trac/ghc/ticket/3843 > > > > In any case, for now I am willing to hard-code a new core-to-core pass on > > the compiler. Any pointers for where I have to look at? > > I recommend you look at compiler/simplCore/CSE.lhs. It is a simple > example of a core-to-core pass. > > However, in short you'll need to: > 1) Create a function which implements your core to core pass, of a > type such as [CoreBind] -> [CoreBind] > *) If that function lives in a new module, edit ghc.cabal.in to tell > the build system about the module > 2) Add a constructor to the CoreToDo data type in > compiler/simplCore/CoreMonad.lhs > 3) Add a case for it to the coreDumpFlag and Outputable instance > 4) Add that pass to the list returned by getCoreToDo in CoreMonad. The > order of the list is the order the passes will be run in. > *) If you want the pass to be under the control of a new flag, you'll > need to add a new dynflag - add a constructor to the DOpt data type in > compiler/main/DynFlags.lhs, and add something to build that > constructor to one of the lists that get fed to the command line > handling code in the same module. It should be fairly obvious how to > do this. > 5) Add a handler for the new constructor to > compiler/simplCore/SimplCore.lhs, in the doCorePass function which > calls into the core pass function you wrote > > Hope that helps, > Max > Yes, that helped quite a lot. One last thing: currently it takes me about 6 minutes to rebuild the compiler after I change the core pass. Are there any tricks of the build system I can use to speed this up? I'm already using a fast build without optimizations and docs... Thanks, Pedro ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: tracing messages
On 28/01/2010 14:27, Serge D. Mechveliani wrote:
Dear GHC team,
this is on tracing in ghc-6.12.1
(made from source on Debian Linux i-386-like machine).
I wonder what is the reason for this tracing message
(starting with `Step1 ...' ):
...
equations calc =
[j< i -> true,
m<= p -> true,
p<= q -> true,
q<= n -> true,
(A p)<= (A q) -> false,
(X<= Y) | (Y< X) -> true,
| {not (Y<= n), not (m<= X), not (X< i), not (j< Y), (A X)<= (A Y)} ->
true,
| {not (X<= Y), not (Y<= j), not (m<= X), (A X)<= (A Y)} -> true,
| {not (XStep 1. Starting mutual pre-reduction. The number of rules is 25.
Pre-reduction done. Initial numbers of equations is 9,
after reduction: 9, the pre-reduction cost is 484.
...
...
The main program does the following in succession:
1) finds eqs,
2) prints
"equations calc =\n", shows eqs "\n\n",
"Starting completion.\n",
"remaining goals = ",
3) finds res by completion (`complete'),
4) prints
shows (completionGoalRem res) "\n"
The trace calls are set only in the function `complete'.
The above message
Step 1. Starting mutual pre-reduction. The number of rules is 25.
Pre-reduction done. Initial numbers of equations is 9,
occurs the first message of this tracing.
But the main program must have printed the full last equation in
eqs, and only after this any tracing message could appear.
Instead, it breaks the last equation printing with the tracing messages.
The further evaluation is long, so I interrupted it, without seeing the
final result. But this printing break looks strange, because eqs
does not depend on the results of `complete', the reverse holds: the
latter applies to eqs.
Generally, I often observe an effect of this kind; it is harmless, but
I wonder, what might be the reason.
Perhaps your program output is going to stdout, and the trace messages
are going to stderr? Buffering would make them appear out of order.
If you're using Debug.trace, I wouldn't recommend that for production
use, only debugging.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
tracing messages
Dear GHC team,
this is on tracing in ghc-6.12.1
(made from source on Debian Linux i-386-like machine).
I wonder what is the reason for this tracing message
(starting with `Step1 ...' ):
...
equations calc =
[j < i -> true,
m <= p -> true,
p <= q -> true,
q <= n -> true,
(A p) <= (A q) -> false,
(X <= Y) | (Y < X) -> true,
| {not (Y <= n), not (m <= X), not (X < i), not (j < Y), (A X) <= (A Y)} ->
true,
| {not (X <= Y), not (Y <= j), not (m <= X), (A X) <= (A Y)} -> true,
| {not (XStep 1. Starting mutual pre-reduction. The number of rules is 25.
Pre-reduction done. Initial numbers of equations is 9,
after reduction: 9, the pre-reduction cost is 484.
...
...
The main program does the following in succession:
1) finds eqs,
2) prints
"equations calc =\n", shows eqs "\n\n",
"Starting completion.\n",
"remaining goals = ",
3) finds res by completion (`complete'),
4) prints
shows (completionGoalRem res) "\n"
The trace calls are set only in the function `complete'.
The above message
Step 1. Starting mutual pre-reduction. The number of rules is 25.
Pre-reduction done. Initial numbers of equations is 9,
occurs the first message of this tracing.
But the main program must have printed the full last equation in
eqs, and only after this any tracing message could appear.
Instead, it breaks the last equation printing with the tracing messages.
The further evaluation is long, so I interrupted it, without seeing the
final result. But this printing break looks strange, because eqs
does not depend on the results of `complete', the reverse holds: the
latter applies to eqs.
Generally, I often observe an effect of this kind; it is harmless, but
I wonder, what might be the reason.
Regards,
-
Serge Mechveliani
mech...@botik.ru
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
