[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Fw: Re: Mentoring a haskell port



On Fri, Apr 04, 2014 at 03:20:59PM +0100, Wookey wrote:
> I'm involved as a Linaro Google summer of code (GSOC) admin as well as
> Debian GSOC mentor. (linaro is an arm linux/open source non-profit
> engineering organisation if you've never heard of it http://linaro.org/
> who have been paying for me to do a lot of good stuff in Debian)
> 
>      We have one student proposing to port ghc to arm64, which is a very
>      useful and interesting piece of work, which I'd like to see happen,
>      but I know absolutely nothing about haskell so would need a
>      co-mentor. (but obviously I do know about arm64/aarch64, porting in
>      general and debian bootstrapping/crossbuilding machinery).

This is an unfortunate thing for me to have to say in the context of
somebody obviously enthusiastic about contributing, but in some ways
this is a bit late really.  As I mentioned recently in
https://lists.debian.org/debian-haskell/2014/04/msg00000.html I've been
working with a developer involved in
https://ghc.haskell.org/trac/ghc/ticket/7942 to get this up and running,
and I already have a complete native unregisterised build of GHC 7.8
built on real hardware (I'll post a finalised patch to the upstream bug
shortly, although it'll be a fairly minor variation on Karel's).

Cross-building 7.6 was unrealistically painful and I would say
impractical, but it's much easier with the build system improvements
that went into 7.8, so I started there.  I'm currently working on
bootstrapping 7.6 from 7.8.  There've been a fair few roadblocks as
nobody really tests bootstrapping GHC from a *newer* version of itself,
but I've made a great deal of progress just today and I'm very close to
having a natively-built ghc-stage1 from 7.6 (my last attempt was
tantalisingly close with just one linker error, but fixing that caused
make(1) to rebuild most of the compiler ...).  At this point I would say
that there is a good chance that I will be able to upload working arm64
GHC 7.6 binaries to Ubuntu by next week, and Debian will be able to
easily bootstrap off that once its arm64 port is far enough along to
support it.

So this kind of cuts the start off your prospective student's proposal,
removing steps i) to iv).  There is still the possibility that I'll
encounter some new roadblock - I'd probably have waited for a little
more certainty before replying if not for your weekend deadline - but
things are looking pretty good at this point and it's not clear to me
that it makes sense for a GSoC student to duplicate all the work Karel
and I have been doing from scratch.

On the other hand, it still leaves a good deal of interesting work
further down the line, and perhaps actually work that would be more
rewarding in some ways.  All I'm doing is the bare minimum: an
unregisterised port, which gets us a good chunk of the dependency chain
behind ghc but not all of it.  I rather doubt Template Haskell will work
with it, for instance.

I know Karel has been interested in doing more and getting LLVM up and
running (see
https://ghcarm.wordpress.com/2014/01/18/unregisterised-ghc-head-build-for-arm64-platform/),
but he estimates that a build using an unregisterised compiler will take
weeks on the Foundation Model so it isn't very practical; there's also
the possibility of writing a native code generator.  I'm quite sure that
doing one or other of these would make a worthwhile and interesting
project, although if there's some way that hardware access could be
procured for this student (I have access myself, but I'm afraid I'm not
permitted to share it outside my company) it would make it much less
frustratingly slow.

I'm afraid I'm not a good person to mentor either project.  I'm strictly
a porter and no kind of GHC expert, although I've sort of picked up
enough to get by in places: I was very much reliant on Karel's initial
work.  A mentor would need a good deal more clue than I possess to be
able to evaluate the student's work and avoid leading them down blind
alleys.  However, perhaps somebody else here can help, or suggest
alternatives to the above.

-- 
Colin Watson                                       [cjwatson@debian.org]


Reply to: