Re: Reconsidering -Wall and -Wcompat

Just as one data point, the Swift compiler is by default showing warnings about upcoming changes. Just like deprecation warnings, I do find that helpful. Based on that experience, including -Wcompat in -Wall seems like a good plan to me. Manuel > Ben Gamari : > > tl;dr.

Re: Associated type instances

Simon, I’m not sure when this ”feature” was added, but I’m pretty sure that my original implementation of associated types was exactly what you describe in the solution. Or did I miss anything? Manuel Simon Peyton Jones simo...@microsoft.com: Friends I want to make withdraw (or, rather,

Re: GHC 7.8.3 release

I believe #9078 affects all EDSLs that use Andy Gill’s stable name method to implement observable sharing. It certainly crashes Accelerate. I would very much appreciate if 7.8.3 would be released in time to make it into the upcoming Haskell Platform. (If the platform would ship with 7.8.2.,

Re: GHC 7.8 release?

Simon Peyton-Jones simo...@microsoft.com: | You may ask what use is a GHC release that doesn't cause a wave of updates? | And hence that doesn't work with at least some libraries. Well, it's a very useful | forcing function to get new features actually out and tested. | | But the

Re: GHC 7.8 release?

Simon Peyton-Jones simo...@microsoft.com: If there's a path to having a release strategy as Manuel suggests, and having an intermediate release with the new vector primops, type extensions and such goodness, then I'm all for it. A lot of these bits are things ill start using almost

Re: GHC 7.8 release?

a fork doesn't require any special privileges in GHC repos. Finally, we can use GitHub pull requests to track contributions that are pending integration. This is IMHO also much nicer than attaching patches at Trac tickets. Manuel On 09/02/13 02:04, Manuel M T Chakravarty wrote: I completely

Re: GHC 7.8 release?

I completely agree with Johan. The problem is to change core APIs too fast. Adding, say, SIMD instructions or having a new type extension (that needs to be explicitly activated with a -X option) shouldn't break packages. I'm all for restricting major API changes to once a year, but why can't we

Re: Mailing list reorganisation

Good plan! Ian Lynagh i...@well-typed.com: Hi all, Following a recent discussion, we propose to reorganise the GHC-related mailing lists so that we end up with: glasgow-haskell-users For user discussions ghc-devs For developer discussions ghc-commits

Re: Dynamic libraries by default and GHC 7.8

Simon Marlow marlo...@gmail.com: This has some advantages and some disadvantages, so we need to make a decision about what we want to do in GHC 7.8. There are also some policy questions we need to answer about how Cabal will work with a GHC that uses dynamic libraries by default. We would like

Re: Comparing StableNames of different type

Emil Axelsson e...@chalmers.se: 2012-08-26 08:03, Manuel M T Chakravarty skrev: Emil Axelsson e...@chalmers.se: 2012-08-24 11:08, Simon Marlow skrev: On 24/08/2012 07:39, Emil Axelsson wrote: Hi! Are there any dangers in comparing two StableNames of different type? stEq :: StableName

Re: Comparing StableNames of different type

Emil Axelsson e...@chalmers.se: 2012-08-24 11:08, Simon Marlow skrev: On 24/08/2012 07:39, Emil Axelsson wrote: Hi! Are there any dangers in comparing two StableNames of different type? stEq :: StableName a - StableName b - Bool stEq a b = a == (unsafeCoerce b) I could guard the

Re: GADTs in the wild

Most academic papers do use the eval example, but it is a practical example. This use of GADTs is nice for embedded languages. For example, Accelerate uses a supercharged version of it to catch as many errors as possible during Haskell host program compile-time (as opposed to Accelerate compile

Re: parallel garbage collection performance

I wonder, do we have a Repa FAQ (or similar) that explain such issues? (And is easily discoverable?) Manuel Ben Lippmeier b...@ouroborus.net: On 19/06/2012, at 24:48 , Tyson Whitehead wrote: On June 18, 2012 04:20:51 John Lato wrote: Given this, can anyone suggest any likely causes of

Re: parallel garbage collection performance

Bryan O'Sullivan b...@serpentine.com: On Mon, Jun 18, 2012 at 9:32 PM, John Lato jwl...@gmail.com wrote: I had thought the last core parallel slowdown problem was fixed a while ago, but apparently not? Simon Marlow has thought so in the not too distant past (since he did the work), if my

[ANN] Accelerate version 0.12: GPU computing with Haskell

We just released version 0.12 of Data.Array.Accelerate, the GPGPU[1] library for Haskell: http://justtesting.org/gpu-accelerated-array-computations-in-haskell This is a beta release. The library is not perfect, but it is definitely usable, and we are looking for early adopters. Manuel [1]

Fwd: GHC, Clang XCode 4.2

I think, you meant to reply to the list and not just to me. Von: B. Scott Michel scooter@gmail.com Betreff: Re: GHC, Clang XCode 4.2 Datum: 15 October 2011 12:32:36 An: Manuel M T Chakravarty c...@cse.unsw.edu.au Antwort an: scooter@gmail.com Simon: What are the performance

Re: GHC, Clang XCode 4.2

Just FYI, Xcode 4.2 is live in the Mac App Store now, and it has some nice goodies (i.e., many who develop for iOS and probably also OS X will probably adopt it soon). Manuel PS: Sorry for not having participated in the discussion on how to solve this, but I have too many loose ends right

Re: Two Proposals

Roman Leshchinskiy: Simon Peyton-Jones wrote: I'm not sure if this plan would support [(fred,45), (bill,22)] :: Map String Int. Probably not. Maybe that's a shortcoming... but such Maps are a rather surprising use of list literals. What data structures other than lists do we want to

Re: Two Proposals

Roman Leshchinskiy: Manuel M T Chakravarty wrote: Roman Leshchinskiy: What data structures other than lists do we want to construct using list literals? I'm not really sure what the use cases are. Parallel arrays! (I want to get rid of our custom syntax.) Why? Don't you think

Re: ANNOUNCE: GHC version 7.2.1

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

Re: ANNOUNCE: GHC 7.2.1 Release Candidate 1

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

Re: ANNOUNCE: GHC 7.2.1 Release Candidate 1

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

Re: ANNOUNCE: GHC 7.2.1 Release Candidate 1

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)

Re: How to install GhC on a Mac without registering?

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

Re: How to install GhC on a Mac without registering?

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

Re: How to install GhC on a Mac without registering?

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

Re: How to install GhC on a Mac without registering?

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

Re: How to install GhC on a Mac without registering?

[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

Re: RFC: migrating to git

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

Re: packaging options for Mac OS X

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

ANN: Data.Array.Accelerate 0.8.0.0 — an EDSL for accelerated array computations

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

Re: Removing/deprecating -fvia-c

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

Re: DPH and CUDA status

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

Re: DPH and CUDA status

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

Re: DPH and CUDA status

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

Re: GHC 6.12 + zlib + Mac OS 10.6

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

Re: 6.12.1 release

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

Re: ANNOUNCE: GHC 6.12.1 Release Candidate 1

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

Re: GHC on Snow Leopard: best practices?

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

Re: Snow Leopard GHC

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

Re: GHC API: How to determine Type.Type equality when using type operators?

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

Re: 6.10.3 plans

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

Re: No last core parallel slowdown on OS X

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.

Re: ANNOUNCE: GHC 6.10.2 Release Candidate 1

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

Re: Adding DPH to HEAD

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

Re: Deep fmap with GADTs and type families.

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

Re: DPH Questions

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

Re: DPH Questions

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

Re: Plans for GHC 6.10.2

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:

Re: Type checker loops with type families, overlapping and undecidable instances

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.

Using Data Parallel Haskell

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

Re: ANNOUNCE: GHC version 6.10.1 - MacOS installer

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

Re: ANNOUNCE: GHC version 6.10.1 - MacOS installer

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

Re: ANNOUNCE: GHC version 6.10.1 - MacOS installer

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

Re: Illegal type synonym family application in instance (Was: Breakage with 6.10)

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)´

Re: Version control systems

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

Re: Version control systems

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

Re: Version control systems

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

Re: Version control systems

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

Re: Version control systems

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

Re: Version control systems

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,

Re: Version control systems

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

Re: Version control systems

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

Re: Version control systems

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

Re: Version control systems

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

Re: Version control systems

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

Re: Version control systems

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

Re: Version control systems

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

Re: Version control systems

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

Re: Version control systems

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

Re: Version control systems

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

Re: Version control systems

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

Re: Version control systems

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

Re: Version control systems

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

Re: ANNOUNCE: GHC version 6.8.3 - Mac OS X, Intel/Leopard

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

Re: ANNOUNCE: GHC 6.8.3 Release Candidate - MacOS X (Intel/Leopard) installer, updated!

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

Re: ANNOUNCE: GHC 6.8.3 Release Candidate

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

Re: Type checker loops with innocent looking associated type synonym

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

Re: Inconsistent .hi files with associated types?

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

Re: Bug or not-yet-supported?

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

Re: Tiger installer [was: Re: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel)]

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

Re: Tiger installer [was: Re: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel)]

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

Re: GHC build failures on Mac OS X Leopard: ppc x86

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

Re: GHC build failures on Mac OS X Leopard: ppc x86

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

Re: problems with ghc-6.8.2-powerpc-apple-darwin.tar.bz2 from GHC home page

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

Re: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel)

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

Re: Tiger installer [was: Re: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel)]

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

ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel)

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

Re: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel)

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

Re: Bootstrapping for Leopard

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

Re: Bootstrapping for Leopard

Philip K.F. Hölzenspies: I'm trying toupdate the Portfile so that ghc-6.8.2 can be built using MacPorts (handy for installing other ghc-dependent material from MacPorts like gtk2hs). The problem seems to be that the available bootstrap binary

Re: Integrating editline with ghc

Christian Maeder: Manuel M T Chakravarty wrote: Christian Maeder: 1. a _new_ readline package that only contains the interface that can be implemented using libeditline _or_ libreadline. If this package is call readline (with a new version number) most libraries i.e. like Shellac would

Re: Re[4]: bindist for Intel MacOS X 10.4 (Tiger) with static libs

Yitzchak Gale: Bulat Ziganshin wrote: for me, GMP is much more problematic issue. strictly speaking, we can't say that GHC is BSD-licensed because it includes LGPL-licensed code (and that much worse, it includes this code in run-time libs) Manuel M T Chakravarty wrote: ..binary distributions

Re: Integrating editline with ghc

Alex Young: Yitzchak Gale wrote: Isaac Dupree wrote: GHC is in no legal trouble whatsoever... only if proprietary Haskell code uses the readline library and doesn't switch to using the editline backend. Agreed. I didn't mean that GHC itself was ever in any legal trouble. But as a compiler,

Re: Integrating editline with ghc

Christian Maeder: Judah Jacobson wrote: - System.Console.Editline.Readline contains the readline APIs provided by the editline library (mostly a cut/paste of System.Console.Readline). I would like to see a restructuring of the old readline package: 1. a _new_ readline package that only

Re: gmp

Yitzchak Gale: OK for the time being, but it would be really, really good to be able to compile ghc without gmp. Well, just go ahead and write an alternative portable high- performance implementation of Integer. This idea of a Mac OS X binary with statically-linked gmp is nice, it is

Re: bindist for Intel MacOS X 10.4 (Tiger) with static libs

Thorkil Naur: Hello, On Tuesday 08 January 2008 15:07, Christian Maeder wrote: Hi, I've succeeded in building a binary distribution that uses static libraries for gmp and readline. libreadline.a, libncurses.a and libgmp.a with corresponding header files are included. (For license issues

Re: Re[4]: bindist for Intel MacOS X 10.4 (Tiger) with static libs

Bulat Ziganshin: for me, GMP is much more problematic issue. strictly speaking, we can't say that GHC is BSD-licensed because it includes LGPL-licensed code (and that much worse, it includes this code in run-time libs) Of course, GHC is BSD3 licensed. It includes the GMP code as part of its

Re: Integrating editline with ghc

Judah Jacobson: Hackage link: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/editline-0.1 Haddock: http://code.haskell.org/editline/dist/doc/html/editline/ As I've mentioned before, there are two independent modules: - System.Console.Editline is a very basic (and experimental)

Re: readline package with libedit

Judah, I completely agree that, at the least on the Mac, using editline is the best solution (as long all necessary functionality is supported). I am wondering, though, whether you are testing on Tiger or Leopard. When looking at the readline-emulation API of editline after upgrading to

  1   2   3   >