Dear list,
I'm reposting my message from Haskell-cafe here since this seems like a more
appropriate place to
ask this question. I would like to learn about internals of GHC and contribute
to its development
in the future. I read a couple of papers that give a very general overview of
GHC
So to some extent, to work on it probably does require bashing against some
theory for
a while.
I don't mind that, but on the other hand I don't want to get stuck *only* in
theory.
It also depends on the part of the pipeline that you're interested in.
There's quite a difference between,
Sorry! That wasn't what I intended.
I know, but still... :)
I meant more that I have a reasonably, good idea of *how* to work on ghc
That's what I'm trying to figure out right now. GHC build system looks very
complicated and it
seems I'll be spending weeks on understanding it before I can
make it more useful. It's a wiki.
What else would help? If the answer is X, can anyone help do X?
Thanks
Simon
From: glasgow-haskell-users-boun...@haskell.org
[mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Chris
Nicholls Sent: 13 December 2012 12:00
To: Jan Stolarek
Dnia piątek, 14 grudnia 2012, Ian Lynagh napisał:
I think the main problem is that it's a very broad question. The answer
to how should I get started would be completely different for if you
wanted to implement a type system extension, port GHC to a new platform,
or fix a bug in ghci
All three
OK, so how can we improve it?
First of all I think that materials in the wiki are well organized for people
who already have
some knowledge and only need to learn about particular things they don't yet
know. In this case I
think it is fine to have wiki pages connected between one another so
Dear list,
I have a GHC source tree in ghc-working. I would like to have a separate build
tree in ghc-build,
so I did something like this:
mkdir ghc-build
cd ghc-build
lndir ../ghc-working
Now, I have two different machines. On openSUSE with git 1.8.0 I get something
like this:
It turns out that running 'perl boot' in symlinked directory (ghc-build) is not
enough. I had to
run 'perl boot' in the original ghc-working dir and now configure succeedes in
ghc-build.
Janek
___
Glasgow-haskell-users mailing list
Dnia wtorek, 18 grudnia 2012, Simon Marlow napisał:
On 18/12/12 10:09, Jan Stolarek wrote:
It turns out that running 'perl boot' in symlinked directory (ghc-build)
is not enough. I had to run 'perl boot' in the original ghc-working dir
and now configure succeedes in ghc-build.
You
So the first page here tells you how to get a single source tree so that
you can build it. The second page tells you how to create a 2-tree
setup for use with GHC's validate; the latter is aimed at people doing
lots of GHC development (which is why it's under WorkingConventions).
I think that
Try this:
http://hackage.haskell.org/trac/ghc/wiki/Repositories
Very nice! WorkingConventions/Repositories still duplicates some information
but that's not a big
problem since neither Repositories nor Repositories/Upstream link to it.
Perhaps it would be good
to give a short explanation
The workaround is to link your .git directory from your build tree, like
so:
$ cd ghc-build
$ ln -s $source/.git .
where $source is your source tree.
I managed to get it working on Debian though there were some small issues.
Lndir linked .git
directory by default, but it was not
Would it be possible to change mailing list settings so that topics of emails
begin
with [glasgow-haskell-users] (and for upcoming lists: [ghc-devs],
[ghc-commits] and so on.
No quotation marks of course). It would make filtering and searching in the
mailbox easier.
Janek
I see you're using KMail. Surely that has automatic filtering
facilities?
Of course, though I use filters on Zimbra so that I don't need to redefine them
on each of my
machines. Zimbra filters are a bit crappy though and it would be easier for me
to write filters
based on subject. I can
How about, in the source directory:
git clean -dfx
or perhaps with -X instead. You can use -n instead of -f to see what
it'd do.
Thanks! I inspected the Makefile and it turns out that there is no need for a
workaround:
make maintainer-clean
does the job.
Janek
Hi all,
I've been reading Commentary about PrimOps and code generation and I noticed
that it is partially
outdated (e.g. references to old code gen files: compiler/codeGen/CgPrimOp.hs):
http://hackage.haskell.org/trac/ghc/wiki/Commentary/PrimOps
Hi Ian,
I think it would make sense to post this on haskell-cafe. I think we can expect
larger response
from there than from glasgow-haskell-users.
Janek
Dnia wtorek, 19 marca 2013, Ian Lynagh napisał:
Hi all,
Thank you to everyone who gave us feedback on when we should release
7.8.1, and
I had the same problem on Debian Squeeze:
https://ghc.haskell.org/trac/ghc/ticket/8666
What is your distro?
CCing ghc-devs.
Janek
Dnia czwartek, 6 lutego 2014, Sergei Meshveliani napisał:
Dear GHC team,
I am trying to testghc-7.8.20140130-src.tar.bz2
I make it from source with
with more intimate knowledge of GHC
development might be able to speak on this issue.
Regards,
Tyler Huffman
On Thu, Feb 6, 2014 at 1:50 PM, Jan Stolarek jan.stola...@p.lodz.pl wrote:
I had the same problem on Debian Squeeze:
https://ghc.haskell.org/trac/ghc/ticket/8666
What is your
Hi all,
GHC 7.8 adds --show-options flag that prints all supported command line flags
on standard output.
This can be used to enable autocompletion of command line options for ghc in
shells that support
autocompletion. If you're using bash add this snippet to your ~/.bashrc file:
START
#
Thanks Philip.
ps - I tried to register on trac to add this info to your page but my
registration was marked as spam (even after answering a math question)
I believe you have to contact Herbert about that (CC'd).
In the meantime I added this information to GHC wiki, although it would be nice
Haskellers,
recently I've been looking into the possibility of creating some new
optimisations for GHC. These
would be mostly aimed at list comprehensions. Here's where I need your help:
1. Do you have complex list comprehensions usage examples from real code? By
complex I mean
nested list
On a somewhat related note, I'd love to be able to do this in Haskell:
import Basics.Nat renaming (_≥_ to _≥ℕ_)
(this is taken from Agda).
Janek
Dnia poniedziałek, 29 września 2014, Herbert Valerio Riedel napisał:
Hello *,
Here's a situation I've encountered recently, which mades me wish
.lhs = Literate Haskell
So maybe .mhs = Markdown Haskell instead of .lhs+md?
Jan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Haskellers,
I am finishing work on adding injective type families to GHC. I know that in
the past many people
have asked for this feature. If you have use cases for injective type families
I would appreciate
if you could show them to me. My implementation has some restrictions and I
want to
Thank you Adam.
One example is https://github.com/haskell/vector/issues/34
Yes, this looks like an example where injectivity will work. One question here:
how does one build
vector with GHC HEAD? I tried but failed because of dependencies.
I see lots of potential uses in HList. For example
The current version of cabal-install located at Hackage can not be
installed for the RC because of the following dependency error:
Setup: At least the following dependencies are missing:
filepath =1.0 1.4
The problem is that cabal-install require filepath 1.4, while the RC
ships with
Forall hi,
I just uprgaded both of my machines to use GHC 7.10.1. I keep sandboxed
installations of GHC and
this means I had to rebuild Agda and Idris because the binaries built with GHC
7.8.4 were stored
inside deactivated 7.8.4 sandbox. Sadly, I had problems building both Agda and
Idris
Austin, links to x86_64 linux versions for CentOS don't work.
Janek
Dnia piątek, 27 marca 2015, Austin Seipp napisał:
==
The (Interactive) Glasgow Haskell Compiler -- version 7.10.1
:19 AM, Jan Stolarek jan.stola...@p.lodz.pl wrote:
An update frrom my second machine, this time with 4GB of RAM. Compiling
Agda ran out of memory (again Agda.TypeChecking.Serialise module) and I
had to kill the build. But once I restarted the build the module was
compiled succesfully
.
This looks like some kind of memory leak in GHC.
Janek
Dnia środa, 1 kwietnia 2015, Jan Stolarek napisał:
Forall hi,
I just uprgaded both of my machines to use GHC 7.10.1. I keep sandboxed
installations of GHC and this means I had to rebuild Agda and Idris because
the binaries built with GHC
One thing to keep in mind is that while cpphs will solve some problems of
system-cpp, it will also
bring problems of its own. I, for one, have run into problems with it when
installing Agda. There
is a very long thread here:
https://lists.chalmers.se/pipermail/agda/2014/006975.html
and twice
recall someone
else reported
being affected by the same problem. So, until that problem is solved I would
say it is a blocker
as it would essentialy make development of GHC impossible for some people.
Janek
On 6 May 2015 at 06:38, Jan Stolarek jan.stola...@p.lodz.pl wrote:
One thing to keep
I'm curious why the amount of RAM is relevant as all of our OS have virtual
memory so it is only the size of the heap and the amount of swap that
should be relevant for an Out Of Memory error, right? How big is your heap?
Amount of RAM should only affect speed (i.e. if there is excessive
GHC Users,
I am working on adding proper support for GADTs in Template Haskell. By proper
I mean that GADTs
data constructors will no longer be encoded using H98 data constructors, but
will be represented
explicity.
GADTs allow to declare several constructors with the same signature:
data
35 matches
Mail list logo
