Things are complicated because
- on Cygwin, pwd gives you /cygdrive/c/...
- on MSYS, pwd gives you /c/...
(remember we still support MSYS), and we want c:/...
So we used to use cygpath on cygwin, and some horrible sed command
on MSYS, IIRC. It was a mess, and frequently went wrong.
Sure
Ladies and Gentlemen,
Finally, you can have the glorious GHC in a format satisfying the
discerning Mac user:
http://www.cse.unsw.edu.au/~chak/haskell/GHC-6.8.2.20080211-i386.pkg
Installation instructions: nil
This is *not* the same compiler as in the official 6.8.2 release. It
is the
Don Stewart:
Great!
Does this mean we can submit GHC to be distributed from Apple's
hackage, http://www.apple.com/downloads/ ? (Click the Submit
Downloads button).
Yes, I was thinking about that, too. However, I think we should wait
until 6.8.3 and until we have a stable download url
Chris Kuklewicz:
Manuel M T Chakravarty wrote:
The above package is for Intel Leopard. I expect that a separate
PPC version is easy to build (but cross-compilation and fat
binaries are not supported by GHC).
I have not seen any announcement that GHC 6.8.x is working on OS X
Leopard
The above package is for Intel Leopard... it should be possible to
build packages on Leopard that run on both Tiger and Leopard. (I
could give that a try if anybody with a Tiger box is willing to play
guinea pig.)
I volunteer. What do I need to do?
Try this
Christian Maeder:
Chris Kuklewicz wrote:
The ./setup build causes a segmentation fault. This is for every
project I try (including ones with very default Setup.hs contents).
I can at least reproduce the segmentation fault by running my PPC-
Tiger
binary on an i386-Leopard, by compiling
Sean Leather:
I tried to build GHC stable on my two computers, a PowerBook G4 and
a MacBook, both running 10.5.2. This is the first time I've ever
tried, so I'm somewhat clueless about a lot of it. I went with the
basic instructions (./configure; make) with no 'mk/build.mk' and no
configure
Sean Leather:
Manuel M T Chakravarty:
I can't help you with the PPC, but on the MacBook try building with
make EXTRA_AR_ARGS=-s
It's a known bug with Cabal.
Thanks, Manuel, it builds now.
Afterwards, I ran 'make' in 'testsuite/tests/ghc-regress' and got
this:
OVERALL SUMMARY for test
Christian Maeder:
Manuel M T Chakravarty wrote:
$ ./HelloWorld-Tiger
Hello World!
$ ./HelloWorld-Leopard
Bus error
only setting
export MACOSX_DEPLOYMENT_TARGET=10.4
on Leopard during compilation should make it run on a Tiger, too.
I tried that, too, but it somehow only works partially
Christian Maeder:
Manuel M T Chakravarty wrote:
Christian Maeder:
export MACOSX_DEPLOYMENT_TARGET=10.4
Specifically, I am seeing
dyld: bind: ghc-6.9.20080219:_fcntl$UNIX2003$lazy_ptr =
libSystem.B.dylib:_fcntl$UNIX2003, *0x0108a413 = 0x92c7b7bc
what tells you that this is Leopard
Niklas Broberg:
I haven't payed much attention to how much of type families is/should
be implemented for 6.8.2. What of equality constraints? The following
parses alright, but can't be used it seems.
module Foo where
class C a where
proof :: a
instance (a
Niklas,
=
$ runhaskell Setup build
Preprocessing library hsp-hjscript-0.3.4...
Building hsp-hjscript-0.3.4...
[1 of 1] Compiling HSP.HJScript ( HSP/HJScript.hs,
dist\build/HSP/HJScript.o )
C:\Program\Haskell\hsp-0.3.5\ghc-6.8.2/HSP/Monad.hi
Declaration for $f35
Unfolding
Stefan Holdermans:
Should I report this a bug? Or is it perhaps already been taken care
of in the head?
Probably the latter.
But really as, Bulat wrote, type families in 6.8 are unsupported.
Please test your code with a HEAD snapshot. If that goes wrong, a bug
report on Trac would be
A Mac installer version of the release candidate for Intel/Leopard
Macs is at
http://www.cse.unsw.edu.au/~chak/haskell/GHC-6.8.2.20080529-i386.pkg
This version of GHC includes neither editline nor readline at the
moment (this will be fixed for the final release). It also only works
for
currently best effort at cross-compiling for 10.4- and tell me
why it won't run on Tiger.
Manuel M T Chakravarty:
A Mac installer version of the release candidate for Intel/Leopard
Macs is at
http://www.cse.unsw.edu.au/~chak/haskell/GHC-6.8.2.20080529-i386.pkg
This version of GHC includes
Ian Lynagh:
=
The (Interactive) Glasgow Haskell Compiler -- version 6.8.3
=
The GHC Team is pleased to announce a new patchlevel release of GHC.
This release contains a
Max Bolingbroke:
2008/8/6 Duncan Coutts [EMAIL PROTECTED]:
On Tue, 2008-08-05 at 22:12 -0700, Don Stewart wrote:
marlowsd:
Following lots of useful discussion and evaluation of the
available DVCSs
out there, the GHC team have made a decision: we're going to
switch to git.
Hooray, this
Ian Lynagh:
On Fri, Aug 08, 2008 at 12:04:15PM +1000, Manuel M T Chakravarty
wrote:
I seriously hope the plan is to move all *core* libraries (including
GHC's cabal repo) etc over to git, too. In other word, everything
that you need to build the development version of GHC should come via
git
Duncan Coutts:
On Sat, 2008-08-09 at 15:46 +1000, Manuel M T Chakravarty wrote:
Raising the bar for developers to contribute to a project has been
proven to be a very bad idea many times. Let's not take GHC down
that
path.
I don't especially relish having to learn another vcs tool
Ian Lynagh:
On Sat, Aug 09, 2008 at 03:46:50PM +1000, Manuel M T Chakravarty
wrote:
I am not talking about all libs, I am talking about the core libs.
Most developers of the core libs are also GHC developers.
I'm not sure that's true. e.g. Malcolm and Ross both commit to the
bootlibs, and we
Malcolm Wallace:
I seriously hope the plan is to move all *core* libraries
(including
GHC's cabal repo) etc over to git, too.
* one build system
* one vcs
This is a chance to make a big step towards accessibility, let's
make that step.
Ultimately, I don't think git would make ghc
Jason Dagit:
On Sat, Aug 9, 2008 at 10:44 PM, Roman Leshchinskiy [EMAIL PROTECTED]
wrote:
Maybe investing some time in fixing the most obvious darcs problems
would be a better solution?
We're working on that over at Darcs HQ, but there is no guarantee
that we'd come close to fixing the
Ian Lynagh:
On Sun, Aug 10, 2008 at 02:16:25PM +1000, Manuel M T Chakravarty
wrote:
Duncan Coutts:
I don't especially relish having to learn another vcs tool or
raising
the bar for contributions to Cabal either (we have lots of people
who
make small one-off contributions).
I don't
Thomas Schilling:
I had my share of problems with Darcs; working on the GHC API I
constantly have to avoid conflicts. My temporary workaround is to
not update at all. Maybe switching to Darcs 2 format would help
here, but there are other issues.
I initially converted GHC to Git to be
Simon Marlow:
Manuel M T Chakravarty wrote:
To be honest, if you ask me, I'd go back to the old makefile based
system and remove Cabal from everywhere except building of the
library packages.
I wouldn't object to dropping the use of Cabal for other tools in
the build tree; the reasons
Ian Lynagh:
On Tue, Aug 12, 2008 at 10:20:14AM +1000, Manuel M T Chakravarty
wrote:
To be honest, if you ask me, I'd go back to the old makefile based
system and remove Cabal from everywhere except building of the
library
packages.
Manuel
PS: Just for some more collateral damage. Did
Simon Peyton-Jones:
2. The version control system (VCS)
GHC needs core libraries without which it cannot be built. It is
obviously highly desirable that a developer can build GHC with just
one VCS, which suggests that the core libraries should be in git too.
But those same core libraries are
Duncan Coutts:
On Mon, 2008-08-11 at 13:57 +0100, Simon Marlow wrote:
- Performance. darcs2 regressed in performance for many
operations we
commonly use. I've submitted some measurements for some things,
but
it's pretty easy to find your own test cases: things like darcs
add,
Neil Mitchell:
If it really makes the life easier for people who are having lots of
VCS pain at the moment, then its hard to object. But many of the
comments in this discussion, about how everyone is going to flock to
GHC just as soon as it switches to Git, seem overly optimistic. I
think GHC is
to be
addressed if some crucial code still needs to be obtained using darcs?
Manuel
On Fri, Aug 15, 2008 at 1:59 AM, Manuel M T Chakravarty
[EMAIL PROTECTED] wrote:
Neil Mitchell:
If it really makes the life easier for people who are having lots of
VCS pain at the moment, then its hard
Max Bolingbroke:
Then, adding complexity, git branches are normally done by
switching in-place. So how does this interact with VCS like darcs
that
doesn't have a concept of in-place switching of branches?
Since we will set up Git to ignore the contents of the Darcs repos, it
will simply
Gregory Wright:
On Aug 14, 2008, at 9:12 PM, Manuel M T Chakravarty wrote:
Moreover, as I wrote a few times before, some reasons for switching
in the first place are invalidated by not having the core libraries
in git, too. For example, one complaint about darcs is that it
either doesn't
From what you are saying, it seems that one advantage of git (in-
place branch switching) is not going to be useful to GHC in any case
(because we use nested repositories).
Manuel
Ian Lynagh:
On Fri, Aug 15, 2008 at 01:01:08PM +0100, Max Bolingbroke wrote:
2008/8/15 Isaac Dupree [EMAIL
Ian Lynagh:
On Fri, Aug 15, 2008 at 04:24:12PM +0100, Ian Lynagh wrote:
On Fri, Aug 15, 2008 at 05:09:55PM +0200, Thomas Schilling wrote:
On Fri, Aug 15, 2008 at 4:38 PM, Ian Lynagh [EMAIL PROTECTED] wrote:
One way that it is worse is that you will get a lot more automatic
merge commits when
Ian Lynagh:
On Mon, Aug 18, 2008 at 12:21:47PM +1000, Manuel M T Chakravarty
wrote:
From what you are saying, it seems that one advantage of git (in-
place branch switching) is not going to be useful to GHC in any case
Yes.
(because we use nested repositories).
That does make it harder
Niklas Broberg:
On 10/11/08, David Menendez [EMAIL PROTECTED] wrote:
On Fri, Oct 10, 2008 at 8:40 PM, Niklas Broberg
[EMAIL PROTECTED] wrote:
src\HSX\XMLGenerator.hs:71:0
Illegal type synonym family application in instance: XML m
In the instance declaration for `EmbedAsChild m (XML m)´
Jason Dagit:
On Tue, Nov 4, 2008 at 10:11 AM, Ian Lynagh [EMAIL PROTECTED] wrote:
How to get it
~
The easy way is to go to the web page, which should be self-
explanatory:
http://www.haskell.org/ghc/
We supply binary builds in the native package format for many
Ian Lynagh:
On Tue, Nov 04, 2008 at 09:02:12PM -0500, Brandon S. Allbery KF8NH
wrote:
On 2008 Nov 4, at 20:26, Jason Dagit wrote:
On Tue, Nov 4, 2008 at 4:26 PM, Manuel M T Chakravarty
[EMAIL PROTECTED] wrote:
Are you sure it does deinstall the 6.8 compiler?
After installing 6.10
Jason Dagit:
On Wed, Nov 5, 2008 at 5:36 PM, Manuel M T Chakravarty [EMAIL PROTECTED]
wrote:
Ian Lynagh:
On Tue, Nov 04, 2008 at 09:02:12PM -0500, Brandon S. Allbery KF8NH
wrote:
On 2008 Nov 4, at 20:26, Jason Dagit wrote:
On Tue, Nov 4, 2008 at 4:26 PM, Manuel M T Chakravarty
[EMAIL
As previously announced, GHC 6.10.1 includes a technology preview of
Data Parallel Haskell. However, so far, there was no documentation on
how to use it. That is different now:
http://haskell.org/haskellwiki/GHC/Data_Parallel_Haskell
Please keep in mind that this is a very preliminary
As Lennart wrote, with UndecideableInstances all bets are off.
Concerning the fixed-depth recursion stack. It is currently only used
for the simplification of class instance declarations, but if
improvement rules are involved (either FDs or TFs) that check will not
catch all cases anyway.
Ian wrote,
This is just a quick summary of our plans for GHC 6.10.2.
While it is possible that we will fix some others, for the 6.10.2
release we mainly intend to look at the high-priority bugs in the
6.10.2
milestone. They are listed here:
James Swaine:
I was wondering if anyone could point me to a more in-depth
explanation of why we are (currently) restricted to using a special-
purpose standard Prelude when writing vectorised code with DPH.
The reason is simply that the standard version of the Prelude uses
Haskell features
Roman Cheplyaka:
* Manuel M T Chakravarty c...@cse.unsw.edu.au [2009-02-12
12:16:26+1100]
Also - there are several papers which mention foldP as being part of
the (prospective) implementation, but I couldn't find this in any of
the modules. Has this one not been implemented yet?
Up to now
David Menendez:
On Thu, Mar 5, 2009 at 10:07 PM, Dan Doel dan.d...@gmail.com wrote:
But we've so far not been able to find a way of merely annotating
the original
into working. So, I was wondering if any of the more knowledgeable
folks here
could illuminate what's going wrong here, and
Colin Paul Adams:
I tried following the advice on the DPH wiki:
./sync-all --dph get
This wouldn't run because of permissions, so I tried putting sh in
front of the command. This produced a lot of error messages:
Some guy by the handle of Megacz added this to the page. No idea
why. I'll
jutaro:
This is the first answer I got from the gtk2hs mailing list. Please
consider
this issue seriously.
Well there is a simple fix as Simon Marlow wrote,
The fix is fiarly easy: use Foreign.Concurrent.mkForeignPtr with a
foreign import.
In fact, if as Axel writes, these finalisers are
Dave Bayer:
In that paper, they routinely benchmark N-1 cores on an N core Linux
box, because of a noticeable falloff using the last core, which can
do more harm than good. I had confirmed this on my four core Linux
box, but was puzzled that my two core MacBook showed no such
falloff.
Ian Lynagh:
On Fri, Apr 24, 2009 at 11:08:38AM +0100, Simon Marlow wrote:
We do have a WARNING pragma, incedentally:
http://www.haskell.org/ghc/docs/latest/html/users_guide/pragmas.html#warning-deprecated-pragma
I don't think that using it for this would be a good idea, though. It
would
Christiaan Baaij:
I believe that you are asking about type functions. Specifically,
I think what you are asking is this:
How can I normalise a type, by rewriting it exhaustively using
the top-level type-function definitions
That is indeed a better formulation of my original question
I
Simon Marlow:
On 24/09/2009 23:54, Barney Stratford wrote:
I've tried just letting the dynamic linker (dyld) sort everything out
for us, but this failed because not all symbols are dynamically
linked,
and the statically linked ones are invisible to it.
One change that will be necessary in
David Menendez:
Is there any consensus about what needs to be done to get a working
ghc installation on a Snow Leopard (Mac OS X 10.6) system? The Mac OS
X wiki page[1] currently links to a blog post[2] that recommends
manually patching /usr/bin/ghc, but I have also seen recommendations
that
Barney Stratford:
this one built and installed fine on Mac OS X 10.6 :).
Interesting, I thought there were still problems there.
I assume that's a 32-bit version. The problems manifest themselves
only when you compile a 64-bit GHC.
That's incorrect. The 32-bit version is only partially
Simon Marlow:
Or, we could just make a 6.12.1 RC2, and advertise it with the same
caveats, putting out 6.12.1 when cabal-install works and we've had a
chance to see the state of Hackage and alert package authors.
Simon and I favour the RC2 option. What do others think?
I agree. I don't
Antoine Latter:
On Sat, Nov 28, 2009 at 3:54 PM, Yusaku Hashimoto nonow...@gmail.com wrote:
I think you installed zlib without proper flags to link with 32-bit
libraries. configuring with ./Setup configure
--with-hsc2hs='--cc-flag=-m32 --ld-flag=-m32' should do the tricks.
See also
Felipe Lessa:
On Wed, Feb 03, 2010 at 11:37:09AM -0600, Donnie Jones wrote:
Hello Felipe,
I copied this email to Sean Lee Manuel M T Chakravarty as they
worked on Haskell+CUDA, maybe they can comment on the current status?
Here's their paper...
GPU Kernels as Data-Parallel Array
Felipe Lessa:
I would suggest that any GSoC project in this space should be based
on D.A.Accelerate (rather than DPH), simply because the code base is
much smaller and more accessible. There is not much point in
writing a CUDA backend, as we already have a partially working one
that we are
Scott Michel wrote,
Are you also planning a LLVM backend for ghc, in a general sense, or just for
the accelerated work you're doing? It seems to me that ghc itself could be
well served with a LLVM backend, especially if one relies on the JIT mode.
That could help identify code paths in the
Simon Marlow:
[..]
But let's face it, all of this code is crappy. It should be a tiny little
loop rather than a tail-call with argument passing, and that's what we'll get
with the new backend (eventually). LLVM probably won't turn it into a loop
on its own, that needs to be done before
Data.Array.Accelerate defines an embedded language of array computations for
high-performance computing. Computations on multi-dimensional, regular arrays
are expressed in the form of parameterised collective operations (such as maps,
reductions, and permutations). Version 0.8.0.0 of
Ian Lynagh:
On Sun, Nov 28, 2010 at 12:56:00PM -0800, Mark Lentczner wrote:
Outstanding question is what should this framework be called? I would like
to continue to call it GHC.framework, but change the version to something
like 7.0.1+HP-i386,
I think it ought to be called
I agree with Roman's position. I would prefer to stay with darcs (it has its
advantages and disadvantages, but has definitely been improving much in the
past).
In any case, all of GHC including all dependencies must be available and
patchable with a *single* VCS. Mixing VCS' will lead to
[Ian, sorry for the duplicate — wrong sender email at first.]
Ian Lynagh:
On Mon, Jun 06, 2011 at 03:47:57PM +0100, Malcolm Wallace wrote:
On 6 Jun 2011, at 13:49, Lyndon Maydwell wrote:
I would be fantastic if XCode wasn't a dependency. ...
Not to detract at all from the work of the
Sean Leather:
On Fri, Jun 10, 2011 at 03:15, Manuel M T Chakravarty wrote:
Ian Lynagh:
On Mon, Jun 06, 2011 at 03:47:57PM +0100, Malcolm Wallace wrote:
On 6 Jun 2011, at 13:49, Lyndon Maydwell wrote:
I would be fantastic if XCode wasn't a dependency. ...
Not to detract at all from
Lars Viklund:
On Fri, Jun 10, 2011 at 09:24:41PM +1000, Manuel M T Chakravarty wrote:
Well, then get the DVDs bundled with your Mac and install Xcode from those,
or sign up at developer.apple.com and get it there. BTW, Mac users (and
esp devs) upgrade very quickly, much faster than, say
Malcolm Wallace:
On 10 Jun 2011, at 02:15, Manuel M T Chakravarty wrote:
Anybody who is halfway serious about developing software on a Mac will have
Xcode installed anyway.
As the original poster clarified, the motivating use-case is education
(specifically a class of 12-13 year olds
malcolm.wallace:
For use at high school level, I would imagine that you would want to build a
special distribution anyway. One that for example already includes packages,
such as Gloss, that would be useful in teaching children programming in
Haskell without they having to go through
Ian,
The RC unfortunately doesn't build on Lion (OS X 10.7). It needs two patches I
recently pushed to the master branch (and suggested to be merged into stable).
They are the following patches:
eb01af6ba964fe74375e461723b83597ef97155d (On OS X, use gcc-4.2 with Xcode 4
and up)
Ian Lynagh:
On Sat, Jul 30, 2011 at 10:57:40PM +1000, Manuel M T Chakravarty wrote:
The RC unfortunately doesn't build on Lion (OS X 10.7).
I've put the latest 7.2 source here, along with OS X builds:
http://www.haskell.org/ghc/dist/7.2.1-rc2/
My guess is that the bindists will work
Ian Lynagh:
On Mon, Aug 08, 2011 at 11:20:18PM +1000, Manuel M T Chakravarty wrote:
Ian Lynagh:
You are right that the bindists use the default gcc (i.e., the one with the
LLVM backend). That is ok, though, as GHC supplies the stack unwinding
linker option.
Do you really mean
At the request of the Haskell Platform folks, we are shipping the Data Parallel
Haskell libraries separately from GHC (i.e., they are not bundled in the GHC
distribution, nor will they be bundled in any Haskell Platform distribution).
To use DPH with GHC 7.2.1, you need to install the DPH
On Thu, 2005-03-10 at 14:32 +, Ross Paterson wrote:
There's currently no way to give a permanent URL for the best available
version of the 6.4 documentation, i.e. the latest minor release.
How about either a symlink 6.4-latest, or renaming the directory 6.4
as 6.4.0 and making 6.4 a
Assume the following type class declarations with functional
dependencies:
{-# OPTIONS -fglasgow-exts #-}
class C a b c | a b - c where
foo :: (a, b) - c
instance C a a r = C a (b, c) r where
foo (a, (b, c)) = foo (a, a)
Now, in GHCi (version 6.4),
*FDs let bar x = foo ((x, x), (x,
Iavor Diatchki wrote:
Hi,
On Apr 3, 2005 7:33 AM, Manuel M T Chakravarty [EMAIL PROTECTED] wrote:
Assume the following type class declarations with functional
dependencies:
{-# OPTIONS -fglasgow-exts #-}
class C a b c | a b - c where
foo :: (a, b) - c
instance C a a r
Simon Peyton-Jones wrote:
| {-# OPTIONS -fglasgow-exts #-}
|
| class C a b c | a b - c where
| foo :: (a, b) - c
|
| instance C a a r = C a (b, c) r where
|foo (a, (b, c)) = foo (a, a)
You are already on dodgy ground here, because the instance decl doesn't
guarantee that the
I like to announce version 0.14.3 of C-Haskell, which brings the
following advances over 0.14.1:
* gcc's asm construct is supported, which is apparently important for
some libraries on Mac OS X (thanks to Duncan Coutts for the patch);
* C-Haskell supports cross compilation (see details
Am Donnerstag, den 06.04.2006, 16:37 -0700 schrieb John Meacham:
On Thu, Apr 06, 2006 at 04:28:01PM -0700, John Meacham wrote:
I was curious if ghc could support the following basic types, they will
likely just be aliases of existing types.
WordPtr uintptr_t
WordMax uintmax_t
IntPtr
John Meacham:
On Tue, May 02, 2006 at 03:29:16AM +, Aaron Denney wrote:
On 2006-04-29, Manuel M T Chakravarty [EMAIL PROTECTED] wrote:
Am Donnerstag, den 06.04.2006, 16:37 -0700 schrieb John Meacham:
On Thu, Apr 06, 2006 at 04:28:01PM -0700, John Meacham wrote:
I was curious
Simon Peyton-Jones wrote:
3. Dictionaries are packaged in data constructors
~~
A very useful new feature is this. When a data type is declared in in
GADT syntax, the context of the constructor is
*required* when constructing
*available* when
There is now also a draft paper that explains the rational for the
restrictions described on the wiki page referenced by Lennart. You
can eg find it at
http://www.cse.unsw.edu.au/~chak/papers/SSPC07.html
Manuel
PS: I also just added a link to the paper to the wiki page.
Lennart
Jean-Philippe Bernardy schrieb:
On 10/17/07, Simon Peyton-Jones [EMAIL PROTECTED] wrote:
| on http://hackage.haskell.org/trac/ghc/ticket/1716#comment:2 I read: we are
| not advertising type equalities for 6.8. What does this mean? Is it
| possible that type family support will be removed from
R Hayes wrote,
What resembles an old issue has reappeared when building HEAD on
Leopard.
The build of the stage two compiler fails with:
ld: in /Users/rfh/3rdParty/builds/ghc-6.9.20071028/libraries/
haskell98/dist/build/libHShaskell98-1.0.1.a, archive has no table of
contents
I assume
A full binary distribution of GHC 6.8.1 for Mac OS X 10.5 (Leopard) is
available from
http://www.cse.unsw.edu.au/~chak/haskell/ghc-6.8.1-i386-apple-darwin.tar.bz2
To use it, you need two other pieces of software installed:
Xcode 3.0-- as available from the Leopard upgrade/install DVD
Christian Maeder:
Manuel M T Chakravarty wrote:
A full binary distribution of GHC 6.8.1 for Mac OS X 10.5 (Leopard)
is
available from
http://www.cse.unsw.edu.au/~chak/haskell/ghc-6.8.1-i386-apple-darwin.tar.bz2
The name of a binary distribution for Mac OS X 10.4 (Tiger) would
[EMAIL PROTECTED]:
Brian P. O'Hanlon wrote:
On Nov 6, 2007 1:29 AM, Manuel M T Chakravarty
[EMAIL PROTECTED] wrote:
A full binary distribution of GHC 6.8.1 for Mac OS X 10.5
(Leopard) is
available from
http://www.cse.unsw.edu.au/~chak/haskell/ghc-6.8.1-i386-apple-darwin.tar.bz2
You do
Benedikt,
Manuel M T Chakravarty wrote:
A full binary distribution of GHC 6.8.1 for Mac OS X 10.5 (Leopard)
is available from
http://www.cse.unsw.edu.au/~chak/haskell/ghc-6.8.1-i386-apple-darwin.tar.bz2
Thanks, it's great you provided a binary distribution, especially
since macports' ghc
Christian Maeder:
Manuel M T Chakravarty wrote:
I wasn't expecting any backwards compatibility from Leopard-built
software to Tiger, but then I am also a Mac-noob and maybe there are
ways to achieve that that I don't know of. Any suggestions?
Could you, or someone else with Leopard, check
Christian Maeder:
Manuel M T Chakravarty wrote:
What we really need is a proper .mpkg
How about a simple disk image (.dmg) that can be moved
around as long as the relative paths within the image remain the same?
This would require to allow relative paths in package.conf files
(which
would
Deborah Goldsmith wrote,
If you want to get the path to the main executable on Mac OS X, use
_NSGetExecutablePath. See:
man 3 dyld
That's exactly what we need. The man page is on the web for those
without a mac:
Jan-Willem Maessen:
Is it really a good idea to permit a type signature to include
equality constraints among unifiable types? Does the above type
signature mean something different from a -a? Does the type
signature:
foo :: (a~Bar b) = a - Bar b
mean something different from:
foo
Simon Peyton-Jones:
Nothing deep. Just that = means so many things that it seemed
better to use a different notation.
Also, using = would have entailed significant changes to GHC's
parser. Type constraints are in the same syntactic category as types
and types can appear as part of
Isaac Dupree:
Manuel M T Chakravarty wrote:
Simon Peyton-Jones:
Nothing deep. Just that = means so many things that it seemed
better to use a different notation.
Also, using = would have entailed significant changes to GHC's
parser. Type constraints are in the same syntactic category
Wolfgang Jeltsch:
Am Mittwoch, 5. Dezember 2007 17:05 schrieb Simon Peyton-Jones:
[…]
Anyway, while on this subject, I am considering making the following
change:
make all operator symbols into type constructors
(currently they are type variables)
This would be highly
Carsten Keßler:
Basically, I just wanted to get this thing running without too much
hassle... Does anyone have an idea why the GHC distribution
available via MacPorts does not work at the moment?
Install gmp from MacPorts. That will make the configure error go
away. (The installed
Carsten Keßler:
OK, now I get no GMP error any longer, instead, I got my good old
OpenGL-error back...
Installing: /Library/GHC/lib/ghc-6.8.1/lib/OpenGL-2.2.1.1
installPackage: Error: Could not find module:
Graphics.Rendering.OpenGL.GL.PixelRectangles.PixelStorage with any
suffix: [p_hi]
Ian Lynagh wrote:
=
The (Interactive) Glasgow Haskell Compiler -- version 6.8.2
=
The GHC Team is pleased to announce a new patchlevel release of GHC.
This release
Christian Maeder:
Manuel M T Chakravarty wrote:
To use this binary distribution, you need to have readline from
MacPorts installed.
Manuel
PS: This time around, there should be no dependency on MacPorts'
gmp,
but this is hard for me to test locally.
What does your otool -L say to your
Alex Jacobson:
Will this also work with Tiger or do I have to upgrade?
I don't know. I have no box with Tiger to test. Give it a try. The
worst that can happen is that it is going to complain about some
missing libraries or similar.
Manuel
Manuel M T Chakravarty wrote:
Ian Lynagh
Ian Lynagh:
On Fri, Dec 14, 2007 at 12:11:17PM +1100, Manuel M T Chakravarty
wrote:
otool -L compiler/stage2/ghc-6.8.2
/opt/local/lib/libgmp.3.dylib (compatibility version 8.0.0,
current version 8.1.0)
Yes, it does. That's very strange for the *stage2* compiler. I ran
otool on pwd
I wrote,
Ian Lynagh wrote:
=
The (Interactive) Glasgow Haskell Compiler -- version 6.8.2
=
The GHC Team is pleased to announce a new patchlevel release of GHC.
This
1 - 100 of 251 matches
Mail list logo
