Re: tedu lang/ghc?
Even though I am using GHC almost daily, I agree it is a pile of junk. I still wonder how you are going to manage to keep Haskell but not having GHC anymore. As far as I know there are only two Haskell compilers actively developed except for GHC: UHC and JHC. The other implementations are not maintained anymore. These two will probably not work well with xmonad and xmobar (I am a user of both also). Hugs (already in ports) is not a good alternative as it is not even maintained upstream anymore. Sometimes piles of junk are kept in a system because the alternatives have not caught up. But on the other hand, it is your spare time and you do with it as you want :) On 05/08/13 00:50, Matthias Kilian wrote: Spoiler: I'm not talking about Haskell but about ghc here. I'd like to remove lang/ghc from the ports tree, because it's fucked up beyond repair: - configure runs ghc-pwd (instead of just pwd) to determine the current working directory. ghc-pwd is a program written in Haskell. In the past, when ghc-pwd appeared, configure first compiled that ghc-pwd program, which wouldn't work unless you already have a working Haskell compiler installed. - after replacing all occurrences of ghc-pwd by /bin/pwd, the build fails because it runs ghc-stage2 from the bootstrapper. (Note that binaries for ghc-pwd as well as ghc-stage2 and much more are included in the ghc sources and/or the bootstrapper for this purpose). - bootstrapping without a pre-installed ghc still doesn't work, and upstream doesn't careA - the ghc compiler is not deterministic, because function names (in hs-libraries) depend on what's already built. So if you start a build of ghc, interrupt it and restart it, you may end up with binary incompatible libraries to an uninterrupted build. This is also the reason for all those package bumps we do on hs-* ports. - with every new major ghc release, interfaces break. For example, last summer I had to fix various Num doesn't imply EQ issues as well as a lot of general typesystem issues. Imagine annual changes to the C programming language that require not only recompiliton but rewrites! So let's get rid of this crap. Ciao, Kili
Re: tedu lang/ghc?
How are other distros/OS doing? Do we really need to bootstrap each time? Could not the old working binary be saved to some kind of semiofficial porttools.tgz used on the computer for building all the ports? We would then have two flavors of GHC: The normal one installed to /usr/local/ and one that would install to /usr/porttools/ from where a porttool.tgz can be generated easily. Would a porttools.tgz together with all the other base-tgz files be a bad idea? Would it help any other port? On 05/08/13 09:40, Matthias Kilian wrote: On Wed, May 08, 2013 at 08:00:42AM +0200, Dawe wrote: To lower the impact of ghc we could remove all hs-ports that don't need patching and work out of the box with cabal. The biggest current problem is that there'll be a flag day when we switch to 64 bit time_t. After this day, neiter an installed ghc nor the ghc bootstrapping binaries will work any longer. I've prepared a bootstrapping sequence starting with ghc-6.6 (bootstrapping from .hc files), going through several ghc versions up to 7.4, but this still not working. After all the years dealing with all this ghc bullshit (broken bootstrapping, non-deterministic symbol names, incompatible changes with every release) I'm seriously loosing interest. Ciao, Kili
Re: tedu lang/ghc?
On 2013/05/08 11:04, Lars Engblom wrote: How are other distros/OS doing? Do we really need to bootstrap each time? Could not the old working binary be saved to some kind of semiofficial porttools.tgz used on the computer for building all the ports? This is what we do at present, the port uses binaries saved in a bootstrap tgz in the build. Same for some others e.g. gnats, freepascal, jdk. Moving time_t, tv_sec and ino_t to 64-bit is a flag day change - everything will need to be updated - there will not be an old working binary. All bootstraps need to be rebuilt. In some cases this can be done via a temporary kernel which wraps enough of the old system calls to work for *some* software, but this is only done to get across the bump. It doesn't work for everything requiring a bootstrap, and other changes are needed for software which access system calls directly by number (e.g. freepascal, go) or software which has a hardcoded definition of struct timeval, struct stat, etc. For reference this is what I'm currently aware of that has problems devel/jdk/1.6 bootstrap lang/fpcbootstrap + other changes lang/go asm lang/sbcl hangs during build on i386, amd64 seems ok misc/findutils current alpha works, but not releases multimedia/mediatombcall of overloaded 'quote(time_t)' is ambiguous net/socat HAVE_BASIC_TIME_T is out of range (probably also HAVE_TYPEOF_ST_INO) net/spectrumcall of overloaded 'addAttribute(const char [6], long long int)' is ambiguous productivity/taskjuggler has sanity tests during build which fail (wrong times) x11/blackboxno matching function for call to 'max(long int, long long int)' x11/nx/opennx no matching function for call to 'wxConfigBase::Read(const wchar_t [18], time_t*, int)' call of overloaded 'Write(const wchar_t [18], time_t)' is ambiguous
Re: tedu lang/ghc?
On Wed, May 08, 2013 at 07:43:57AM +0300, Lars Engblom wrote: Even though I am using GHC almost daily, I agree it is a pile of junk. I still wonder how you are going to manage to keep Haskell but not having GHC anymore. I won't. What I meant with this is not about Haskell but about ghc was that it's not the programming language but the (almost) only usable implementation that causes trouble. As far as I know there are only two Haskell compilers actively developed except for GHC: UHC and JHC. The other implementations are not maintained anymore. These two will probably not work well with xmonad and xmobar (I am a user of both also). Hugs (already in ports) is not a good alternative as it is not even maintained upstream anymore. I doubt that any usefull hs-port today is even buildable with anything else than ghc (or some hpothetical implementation which includes some of the ghc extensions). Sometimes piles of junk are kept in a system because the alternatives have not caught up. The proper alternative would be to write some very simple, very small, probably very slow (wrt produced binaries) Haskell compiler in a commonly known and portable and beloved programming language like C that implements enough ghc extensions to be usable for most hs-ports. Or even to be used to bootstrap ghc with it (but then you'd also had to dive into ghc and its build system). But on the other hand, it is your spare time and you do with it as you want :) At the moment, I'm running a test-build of ghc-7.4 using ghc-7.0 bootstrapped from ghc-6.12 bootstrapped from ghc-6.10 boostrapped from 6.6 bootstrapped from nothing but a (still machine and os dependent) .hc file bundle on amd64 running inside qemu on the desktop pc in my office (and -- whow -- it's crappy). If this succeeds, and if the whole process also works on i386 without too many additional fixes, the ghc port will survive at least until the flag day and until I start to work on an update to ghc-7.6.3 and haskell-platform-2013.2.0.0. Ciao, Kili
Re: tedu lang/ghc?
please don't! we still need ghc! https://twitter.com/id_aa_carmack/status/331918309916295168 ;-) Matthias Kilian(k...@outback.escape.de) on 2013.05.07 23:50:25 +0200: Spoiler: I'm not talking about Haskell but about ghc here. I'd like to remove lang/ghc from the ports tree, because it's fucked up beyond repair: - configure runs ghc-pwd (instead of just pwd) to determine the current working directory. ghc-pwd is a program written in Haskell. In the past, when ghc-pwd appeared, configure first compiled that ghc-pwd program, which wouldn't work unless you already have a working Haskell compiler installed. - after replacing all occurrences of ghc-pwd by /bin/pwd, the build fails because it runs ghc-stage2 from the bootstrapper. (Note that binaries for ghc-pwd as well as ghc-stage2 and much more are included in the ghc sources and/or the bootstrapper for this purpose). - bootstrapping without a pre-installed ghc still doesn't work, and upstream doesn't careA - the ghc compiler is not deterministic, because function names (in hs-libraries) depend on what's already built. So if you start a build of ghc, interrupt it and restart it, you may end up with binary incompatible libraries to an uninterrupted build. This is also the reason for all those package bumps we do on hs-* ports. - with every new major ghc release, interfaces break. For example, last summer I had to fix various Num doesn't imply EQ issues as well as a lot of general typesystem issues. Imagine annual changes to the C programming language that require not only recompiliton but rewrites! So let's get rid of this crap. Ciao, Kili --
Re: tedu lang/ghc?
On Tue, May 7, 2013 at 2:50 PM, Matthias Kilian k...@outback.escape.de wrote: Spoiler: I'm not talking about Haskell but about ghc here. To ask a possibly dumb question, what are our other options for Haskell at the moment? E.g., it looks like x11/xmonad depends on lang/ghc, so does removing ghc mean removing xmonad?
