Re: Language extensions - backwards compatibility
On 28 Jan 2010 at 15:45, Don Stewart wrote: > 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? Good question. The code was developed on 6.4, and I would really quite like to continue 6.4 support for personal reasons, if nothing else. But I would like to release it on Hackage eventually, so I really need to consider support for later releases. :-) In principle, I don't anticipate any portability problems, other than this practical one of managing the way the various versions of the compiler handle language extensions. Obviously, there may come a point where I cut 6.4 loose, and to some extent this depends on what sort of solution (if any) to this problem arises. -- 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: Language extensions - backwards compatibility
On 29 Jan 2010 at 13:50, Bulat Ziganshin wrote: > you can use compiler options or preprocess source before feeding it to ghc Separate preprocessing: If there were a preprocessor which was readily available in a typical Haskell installation and could be simply persuaded to do the job (e.g. as a -F "Haskell" preprocessor), that might fit my requirements. I can't think of anything off-hand, but thanks for the suggestion. Compiler options: I want to use Cabal, so this would mean feeding the same options to all the source files, which isn't ideal. On the other hand, this would only apply to the earlier releases, perhaps only 6.4, and the detailed breakdown would be there in the LANGUAGE pragma for later releases, so this might actually be the most practical solution. -- 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: Language extensions - backwards compatibility
On 29 Jan 2010 at 15:14, Malcolm Wallace wrote:
> > The flag -P for traditional gnu cpp (or --noline for stand-alone
> > cpphs) should suppress the initial #line noise.
> >
> > Does ghc still fail to recognise a module-start pragma, even if the
> > only characters preceding it are whitespace?
I'm not sure, but ghci apparently fails to recognise a file-header pragma if it
is preceded by a {-# LINE ... #-} pragma.
>
> I intended to give an example.
>
> file foo.h
> #if __GLASGOW_HASKELL__ == 604
> #define PRAGMA(foo) {-# OPTIONS_GHC -X foo #-}
> #else
> #define PRAGMA(foo) {-# LANGUAGE foo #-}
>
> file Bar.hs
> #include "foo.h"
> PRAGMA(MyLanguageOption)
> module Bar where
>
> result
> $ ghc-6.8.2 -E -cpp -optP-P Bar.hs
> $ cat Bar.hspp
> {-# LINE 1 "Bar.hs" #-}
How on earth does the *C* preprocessor manage to insert a *Haskell* {-# LINE
... #-} pragma? (I see that myself as well in some configurations, some cpphs
(which I could understand), but some not.)
>
>
>
> {-# LANGUAGE MyLanguageOption #-}
> module Bar where
>
> $ ghc-6.4.1 -E -cpp -optP-P Bar.hs
> $ cat Bar.hspp
>
> {-# OPTIONS_GHC -X MyLanguageOption #-}
> module Bar where
>
--
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: cross-compiling ghc to openbsd
Why cross compile when we already have a native GHC on OpenBSD/x86_64 .. use that to build the source directly. khaelin: > Hi, > > I'm trying to cross-compile GHC as follows: > > Host: Linux, x86_64, GHC 6.12.1 > Target: OpenBSD 4.6 stable, i386 > > I follow the guide at: > http://hackage.haskell.org/trac/ghc/wiki/Building/Porting > > I downloaded the last stable source tarball (ghc-6.12.1-src.tar.bz2), then ran > the following commands: > > export AUTOCONF_VERSION=2.62 > export AUTOMAKE_VERSION=1.9 > cp /bin/pwd utils/ghc-pwd/ghc-pwd > sh boot > ./configure --enable-hc-boot --build=i386-unknown-openbsd > --host=i386-unknown-openbsd --target=i386-unknown-openbsd > gmake bootstrapping-files > > The latest fails, with the following trace: > http://pastebin.ca/1770926 > > The following errors are quite interesting: > includes/stg/Types.h:103:2: #error GHC untested on this architecture: > sizeof(void *) != 4 or 8 > includes/rts/Constants.h:156:2: #error unknown SIZEOF_VOID_P > > Does someone what's going on with this build ? > Is there something I can to to help on these issues ? > > Regards, > > -- > Nicolas Martyanoff >http://codemore.org >khae...@gmail.com > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: cross-compiling ghc to openbsd
On Fri, Jan 29, 2010 at 09:42:27PM +0100, Nicolas Martyanoff wrote: > > This probably means some type identifier used at that point hasn't > > been declared, or macro defined or whatever. You'd have to see > > what it is, and maybe it will be more obvious what went wrong. > It seems that SIZEOF_VOID_P isn't defined anywhere. It's defined in includes/ghcautoconf.h (which is created during configure and make bootstrapping-files on the target platform). > All right, I'll try again with the last darcs version when I get access to a > i386 Linux machine. You don't need any linux machine for this. The current darcs port for OpenBSD may be a little bit outdated, but it still works. > In the mean time, I'll try to run a GHC 6.6 -> 6.10 -> 6.12 build chain, 6.6 > being the latest version available in OpenBSD's ports. I sent you a (admittedly horrible) script to do this chain. Use it. If it doesn't work, sent complaints. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: cross-compiling ghc to openbsd
Quoth Nicolas Martyanoff , > It seems that SIZEOF_VOID_P isn't defined anywhere. I guess it's immaterial if you aren't going to pursue the port strategy any farther, but from a cursory look, this would happen at the point where the configuration log says "checking size of void *". That's failing because of an autoconf error, or a C compiler configuration issue, I would guess. Donn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Question regarding combinator call convention
I was looking through the code for 6.12.1 and am a bit confused about 11.1.3 in the runtime system documentation docs/rts/rts.tex. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.79.641&rep=rep1&type=pdf It says the arguments passing convention to a known combinator differs from that of the others in that it starts the arguments with R1 instead of R2 (R1 points to the associated memory data structure for non-combinators). The thing I'm confused with is I would expect this would require treating combinators special, and yet I don't see an combinator specific stuff (in either ClosureTypes.h or the generated AutoApply.cmm) to treat them special. Ive also looking at functions like plusInt and a few of my own, but, apart from internal functions like stg_app_*, I'm not finding any code using the the combinator passing convention. Am I missing something? Thanks! -Tyson signature.asc Description: This is a digitally signed message part. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: cross-compiling ghc to openbsd
On 10-01-29 11:54, Donn Cave wrote: > Quoth Nicolas Martyanoff , > ... > > The latest fails, with the following trace: > > http://pastebin.ca/1770926 > > Can you look at the include files, at the locations where all these > errors crop up? like, > includes/stg/Types.h:118: error: syntax error before '*' token > > This probably means some type identifier used at that point hasn't > been declared, or macro defined or whatever. You'd have to see > what it is, and maybe it will be more obvious what went wrong. It seems that SIZEOF_VOID_P isn't defined anywhere. > But of course Matthias is right, the configuration of build and > target hosts you propose to use probably isn't going to work. The > idea is that you do this configure step on the OpenBSD host, right? > and then transplant this configuration (a couple of .h files, etc.) > to the build host and proceed to build the .hc files. That means > the build host has to be a lot like the target host, or that build > will be radically misconfigured. Same hardware architecture, at a > minimum. All right, I'll try again with the last darcs version when I get access to a i386 Linux machine. In the mean time, I'll try to run a GHC 6.6 -> 6.10 -> 6.12 build chain, 6.6 being the latest version available in OpenBSD's ports. Thank you for your help ! Regards, -- Nicolas Martyanoff http://codemore.org khae...@gmail.com pgppoD8R6yFu6.pgp Description: PGP signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: cross-compiling ghc to openbsd
Quoth Nicolas Martyanoff , ... > The latest fails, with the following trace: > http://pastebin.ca/1770926 Can you look at the include files, at the locations where all these errors crop up? like, includes/stg/Types.h:118: error: syntax error before '*' token This probably means some type identifier used at that point hasn't been declared, or macro defined or whatever. You'd have to see what it is, and maybe it will be more obvious what went wrong. But of course Matthias is right, the configuration of build and target hosts you propose to use probably isn't going to work. The idea is that you do this configure step on the OpenBSD host, right? and then transplant this configuration (a couple of .h files, etc.) to the build host and proceed to build the .hc files. That means the build host has to be a lot like the target host, or that build will be radically misconfigured. Same hardware architecture, at a minimum. Donn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: cross-compiling ghc to openbsd
On Fri, Jan 29, 2010 at 06:10:52PM +0100, Nicolas Martyanoff wrote: > I'm trying to cross-compile GHC as follows: > > Host: Linux, x86_64, GHC 6.12.1 > Target: OpenBSD 4.6 stable, i386 IMHO, you shouldn't go that way, because it adds much more complexity than you already have with OpenBSD as host *adn* target. During my last tests back in december, not even OpenBSD/i386 -> OpenBSD/i386 worked with .hc files. That should be fixed first. Then, something like OpenBSD/i386 -> OpenBSD-amd64 (and vice versa) should be done. And if this works, it's questionable wether one should work on cross building with .hc files using differen host an target operating systems or wether it would be more useful to start getting GHC running on other OpenBSD archs. > I follow the guide at: > http://hackage.haskell.org/trac/ghc/wiki/Building/Porting > > I downloaded the last stable source tarball (ghc-6.12.1-src.tar.bz2), then ran > the following commands: > > export AUTOCONF_VERSION=2.62 > export AUTOMAKE_VERSION=1.9 > cp /bin/pwd utils/ghc-pwd/ghc-pwd > sh boot > ./configure --enable-hc-boot --build=i386-unknown-openbsd > --host=i386-unknown-openbsd --target=i386-unknown-openbsd [...] IIRC there where some discussions (or even patches pushed?) about the build/host/target combo, so you may try to pull ghc sources with darcs (head or the 6.12 branch). > The latest fails, with the following trace: > http://pastebin.ca/1770926 > > The following errors are quite interesting: > includes/stg/Types.h:103:2: #error GHC untested on this architecture: > sizeof(void *) != 4 or 8 > includes/rts/Constants.h:156:2: #error unknown SIZEOF_VOID_P Your build is (re)creating includes/ghcautoconf.h -- this looks very wrong to me, since ghcautoconf.h is supposed to be created by a former configure / make bootstrapping-files on the target platform and then used on the host for creating the .hc files. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
cross-compiling ghc to openbsd
Hi, I'm trying to cross-compile GHC as follows: Host: Linux, x86_64, GHC 6.12.1 Target: OpenBSD 4.6 stable, i386 I follow the guide at: http://hackage.haskell.org/trac/ghc/wiki/Building/Porting I downloaded the last stable source tarball (ghc-6.12.1-src.tar.bz2), then ran the following commands: export AUTOCONF_VERSION=2.62 export AUTOMAKE_VERSION=1.9 cp /bin/pwd utils/ghc-pwd/ghc-pwd sh boot ./configure --enable-hc-boot --build=i386-unknown-openbsd --host=i386-unknown-openbsd --target=i386-unknown-openbsd gmake bootstrapping-files The latest fails, with the following trace: http://pastebin.ca/1770926 The following errors are quite interesting: includes/stg/Types.h:103:2: #error GHC untested on this architecture: sizeof(void *) != 4 or 8 includes/rts/Constants.h:156:2: #error unknown SIZEOF_VOID_P Does someone what's going on with this build ? Is there something I can to to help on these issues ? Regards, -- Nicolas Martyanoff http://codemore.org khae...@gmail.com pgpiZFiuYByj6.pgp Description: PGP signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Language extensions - backwards compatibility
The flag -P for traditional gnu cpp (or --noline for stand-alone
cpphs) should suppress the initial #line noise.
Does ghc still fail to recognise a module-start pragma, even if the
only characters preceding it are whitespace?
I intended to give an example.
file foo.h
#if __GLASGOW_HASKELL__ == 604
#define PRAGMA(foo) {-# OPTIONS_GHC -X foo #-}
#else
#define PRAGMA(foo) {-# LANGUAGE foo #-}
file Bar.hs
#include "foo.h"
PRAGMA(MyLanguageOption)
module Bar where
result
$ ghc-6.8.2 -E -cpp -optP-P Bar.hs
$ cat Bar.hspp
{-# LINE 1 "Bar.hs" #-}
{-# LANGUAGE MyLanguageOption #-}
module Bar where
$ ghc-6.4.1 -E -cpp -optP-P Bar.hs
$ cat Bar.hspp
{-# OPTIONS_GHC -X MyLanguageOption #-}
module Bar where
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Language extensions - backwards compatibility
Hello Iain, Friday, January 29, 2010, 2:38:27 AM, you wrote: > 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. you can use compiler options or preprocess source before feeding it to ghc -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Language extensions - backwards compatibility
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.) The flag -P for traditional gnu cpp (or --noline for stand-alone cpphs) should suppress the initial #line noise. Does ghc still fail to recognise a module-start pragma, even if the only characters preceding it are whitespace? Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC core plugins
On 29/01/10 09:32, José Pedro Magalhães wrote: Hi, 2010/1/28 Max Bolingbroke mailto:batterseapo...@hotmail.com>> 2010/1/28 José Pedro Magalhães mailto:j...@cs.uu.nl>>: > 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. Thanks. Doing this reduces compilation time to about 30s, but unfortunately my pass is not updated (even though it is compiled). I have to do 'make stage=2' at the root directory, not inside compiler. This brings compilation time to 1m10s (which is still better than what I was doing), but I really don't know what would need building outside the compiler directory... The correct way to update your stage 2 compiler without rebuilding extraneous dependencies is: $ cd ghc $ make 2 for more info, see http://hackage.haskell.org/trac/ghc/wiki/Building/Using#RebuildingtheGHCbinaryaftermakingchanges As an aside, is there any hope of using SYB in the core pass? As a generic programmer I quickly get tired of traversing the entire AST when I want just a few changes in specific places... That's a discussion we ought to have at some point. Note however that Core is actually a very deep data type (Ids contain unfoldings, which contain more expressions, which contain Ids, which contain types, and so on), and is also cyclic. Simply traversing the whole thing would be a very bad idea. There is a ghc-syb package which has SYB instances for HsSyn I think. HsSyn is not as deep or cyclic as Core. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Language extensions - backwards compatibility
On 28/01/10 23:38, Iain Alexander wrote:
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?
There are a little cluster of bugs to do with this, see
http://hackage.haskell.org/trac/ghc/ticket/3457
We need to re-read the pragmas after preprocessing. Ironically though,
you will only be able to use this facility with a GHC that supports it,
so we'll see a lot of source files like
{-# LANGUAGE ... #-}
#if __GLASGOW_HASKELL__ >= 614
{-# LANGUAGE .. more .. #-}
#endif
because GHC before 6.14 will stop at the first #if. (that's assuming we
implement this for 6.14, it hasn't been done yet)
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC core plugins
Hi, 2010/1/28 Max Bolingbroke > 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. > Thanks. Doing this reduces compilation time to about 30s, but unfortunately my pass is not updated (even though it is compiled). I have to do 'make stage=2' at the root directory, not inside compiler. This brings compilation time to 1m10s (which is still better than what I was doing), but I really don't know what would need building outside the compiler directory... As an aside, is there any hope of using SYB in the core pass? As a generic programmer I quickly get tired of traversing the entire AST when I want just a few changes in specific places... Thanks, Pedro > > Hope that helps, > Max > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
