release in time for the final 7.8, and a recompile of Hackage to pick it
> > > up so that people can start using the new 'TypedHoles' token in their
> > > .cabal files... so there's a bit of coordination required to make this
> > > happen in a timely manner... Or put different
On 23 January 2013 05:41, Nathan Hüsken wrote:
> Hey,
>
> I am working on getting ghc to cross compile to android.
>
> When trying to get haskeline to compile. I want to change the cabal file
> such that it sets a flag when compiling for android.
>
> For that I changed cabal so that it recognizes
On 12 January 2013 16:05, Ian Lynagh wrote:
> On Tue, Jan 08, 2013 at 08:10:18PM +0000, Duncan Coutts wrote:
>>
>> Either way, lemme know if this is all fine, and I'll make the 0.10.0.2
>> release.
>
> Looks good, thanks! I've updated the GHC
On 28 May 2012 05:36, Tim Cuthbertson wrote:
> - ghc doesn't seem to support ${pkgroot} prefixes. I thought it did,
> but I'm new to this so I may be misunderstanding where they can be
> used.
I thought it did too since I think I wrote the code for it. I don't
recall exactly what version it got
On 18 May 2012 22:03, Joe Buehler wrote:
> Duncan Coutts wrote:
>
>> I'm very surprised it's not working on some version of Red Hat. This
>> has worked on many varieties of linux for many years. You don't have
>> some non-standard ar installed do you?
On 18 May 2012 20:20, Joe Buehler wrote:
> I built GHC 7.2.2 on a LINUX box running RHEL 3. When compiling a package
> using
> this GHC it is trying to invoke ar thus:
>
> execve("/usr/bin/ar", ["/usr/bin/ar", "-r", "-c",
> "dist/build/libHSregex-base-0.93."..., "dist/build/Text/Regex/Base.o",
>
On 8 February 2012 10:24, Joachim Breitner wrote:
> Dear interested parties :-),
>
> GHC 7.4.1 started to ship and expose the binary library, version
> 0.5.0.3. On hackage is binary-0.5.1.0.
It was firmly my opinion that shipping and exposing binary in GHC was
and is a mistake. Previously it was
On 23 December 2011 20:09, Stefan Holdermans wrote:
>> Here are the kinds of the type constructors:
>>
>> (,,) :: * -> * -> * -> *
>> (,) :: * -> * -> *
>> () :: *
>>
>> (# ,, #) :: * -> * -> * -> #
>> (# , #) :: * ->
On Tue, 2011-11-08 at 15:43 +, Simon Marlow wrote:
> Hmm, but there is something you could do. Suppose a thread could be in
> a mode in which instead of blocking on a BLACKHOLE it would just throw
> an asynchronous exception WouldBlock. Any computation in progress would
> be safely abando
d, Nov 9, 2011 at 3:18 AM, Duncan Coutts
> wrote:
>>
>> On 9 November 2011 00:17, Felipe Almeida Lessa
>> wrote:
>> > On Tue, Nov 8, 2011 at 3:01 PM, Daniel Fischer
>> > wrote:
>> >> On Tuesday 08 November 2011, 17:16:27, Simon Marlow wrote:
&
On 9 November 2011 00:17, Felipe Almeida Lessa wrote:
> On Tue, Nov 8, 2011 at 3:01 PM, Daniel Fischer
> wrote:
>> On Tuesday 08 November 2011, 17:16:27, Simon Marlow wrote:
>>> most people know about 1, but I think 2 is probably less well-known.
>>> When in the edit-compile-debug cycle it really
On Tue, 2011-04-26 at 14:05 -0700, Brandon Moore wrote:
> Based on my own misadventures and Albert Y. C. Lai's SICP
> (http://www.vex.net/~trebla/haskell/sicp.xhtml)
> it seems the that root of all install problems is that reinstalling a
> particular version of a particular package deletes any oth
On Thu, 2011-04-28 at 23:31 +0200, Johan Tibell wrote:
> The RTS would invoke listeners every time a new event is written. This
> design has many benefits:
>
> - We don't need to introduce the serialization, deserialization, and
> I/O overhead of first writing the eventlog to file and then parsin
On 16 December 2010 10:02, Simon Marlow wrote:
>> ghc-cabal: Missing dependency on a foreign library:
>> * Missing header file: HsBase.h
>> This problem can usually be solved by installing the system package that
>> provides this library (you may need the "-dev" version). If the library is
>> alr
On 8 November 2010 13:28, Simon Marlow wrote:
>
> There's another approach in Jan Sparud's paper here:
>
> http://portal.acm.org/citation.cfm?id=165196
>
> although it's not clear that this interacts very well with inlining either,
> and it has a suspicious-looking side-effecting operation. It al
On 12 August 2010 02:20, Greg Fitzgerald wrote:
> Is there a way for a package.conf file to contain paths that are relative to
> the directory containing the .conf file? GHC 6.12.1 chokes on relative
> paths. I see the problem is solved for GHC's core libraries with the
> $topdir variable. Is t
On Tue, 2010-05-18 at 17:31 -0400, Anthony LODI wrote:
> Hello,
>
> I'm trying to build some haskell code as a .so/.dll so that it can
> ultimately be used by msvc. I have it working when I compile by hand
> (listed below) but I can't get the exact same thing built/linked with
> cabal. On linux
On Wed, 2010-05-05 at 21:24 +1000, Roman Leshchinskiy wrote:
> Whenever I do cabal sdist on one of my projects, I get this warning:
>
> Distribution quality warnings:
> 'ghc-options: -O2' is rarely needed. Check that it is giving a real benefit
> and not just imposing longer compile times on your
On Fri, 2010-04-30 at 10:25 -0400, Tyson Whitehead wrote:
> On April 30, 2010 06:32:55 Duncan Coutts wrote:
> > In the last few years GHC has gained impressive support for parallel
> > programming on commodity multi-core systems. In addition to traditional
> > threads and
organisations and the Simons at GHC HQ. If you think your
organisation may be interested then get in touch with me, Duncan Coutts,
via i...@well-typed.com.
--
Duncan Coutts, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
Glasgow-haskell
On Thu, 2009-12-24 at 18:18 -0500, Antoine Latter wrote:
> Folks,
>
> I found some of the documentation in GHC.Prim confusing - so I thought
> I'd share. The documentation for the ByteArray# type[1] explains
> that's it's a raw region in memory that also remembers it's size.
>
> Consequently I ex
On Wed, 2009-12-23 at 21:49 +, Simon Marlow wrote:
> I personally think we should revert to using the standard config.guess
> and normalising the result as we used to.
Aye.
> It was changed due to this:
>
> http://hackage.haskell.org/trac/ghc/ticket/1717
>
> so we should find another way
On Mon, 2009-12-21 at 11:34 +, Gracjan Polak wrote:
> Duncan Coutts googlemail.com> writes:
>
> > if flag(test)
> > Buildable: True
> > Build-depends: base<5, bytestring, HUnit, directory
> > else
> > Buildable: False
> >
All,
Conor's problems on OSX with libiconv reminds me of something I've been
thinking about for a little while.
So the problem is that the semantics of static linking does not at all
match what we really want. We can easily accidentally "interpose" a
wrong library in place of the one we wanted.
On Mon, 2009-12-21 at 12:44 +, Simon Marlow wrote:
> > The current Cabal code takes a slightly different approach. It says at
> > the end "oh this exe isn't buildable, so its deps do not contribute to
> > the deps of the package".
> >
> > The problem is what it was doing before that. It sees t
On Fri, 2009-12-18 at 19:44 -0800, Dave Bayer wrote:
> Hi Duncan,
>
> Installation was easy (I typed "cabal-install HTTP zlib
> cabal-install" ;-).
Thanks for testing it. I've uploaded it to hackage.
> Overall, seems to work fine. I couldn't build darcs, but I couldn't do
> that by hand either;
All,
If you'd like to help test the new cabal-install-0.8 release then grab
it here:
http://haskell.org/cabal/release/cabal-install-0.8.0/
It should work with ghc-6.10 and 6.12 (and indeed 6.8 and 6.6).
If nobody reports any major show stoppers then I'll upload this to
hackage.
Duncan
___
On Thu, 2009-12-17 at 14:00 -0800, Dave Bayer wrote:
> Background: I never got "cabal install" to work on OS X 10.5 with GHC
> 6.10.4, basically because zlib wouldn't work. Odd, because a perfectly
> good version of gunzip already exists on most platforms, and the code
> doesn't fall back to this
On Tue, 2009-12-15 at 12:48 -0800, Bryan O'Sullivan wrote:
>
> Yes, that would amount to double-buffering, and would work nicely,
> only the current buffers go through foreign pointers while text uses
> an unpinned array. I can see why this is (so iconv can actually work),
> but it does introduce
On Mon, 2009-12-14 at 22:49 +0100, Daniel Fischer wrote:
> Oh great, that's not what I expected:
>
> $ cabal install cabal-install
> cabal: This version of the cabal program is too old to work with ghc-6.12+.
> You will need to install the 'cabal-install' package version 0.8 or higher.
> If you st
All,
I've tried building 1324 out of the ~1700 packages from hackage using
ghc-6.10.4 and ghc-6.12.0. This is the subset of packages that I could
build in one go.
Compared to the subset that I could build with ghc-6.10.4, I had to
chuck out 125 packages because their build dependency constraints
On Mon, 2009-11-30 at 12:20 +, Simon Peyton-Jones wrote:
> | For ghc-6.12, we should just fix ticket #3681.
>
> OK, good. But who is "we"?
I think the short-term fix is just to change the hsc2hs wrapper script.
So that'd be Ian.
Longer term we might want to do it differently to allow a si
On Mon, 2009-11-30 at 08:44 +, Simon Peyton-Jones wrote:
> Should this go in a FAQ? For GHC? Or for a particular architecture?
For ghc-6.10, yes. It'd should be a section "GHC on OSX 10.6 (Snow
Leopard)" and should describe the changes required to the shell script
wrappers of ghc and hsc2hs. I
On Wed, 2009-11-25 at 04:56 +, Malcolm Wallace wrote:
> Moreover, when I attempt to use the flag, like so:
>
> $ ghc -package-name hat-2.06 ...
> : cannot parse 'hat-2.06' as a package identifier
>
> This used to work with ghc-6.6.x and ghc-6.8.x, but seems to have
> stopped worki
On Sun, 2009-11-22 at 22:00 -0600, Tom Tobin wrote:
> On Nov 22, 2009, at 11:53 AM, Ian Lynagh wrote:
> > Hi all,
> >
> > We are pleased to announce the second release candidate for GHC 6.12.1:
> >
> >http://www.haskell.org/ghc/dist/6.12.1-rc2/
>
> IIRC, an earlier 6.12 RC announcement menti
On Fri, 2009-11-13 at 17:18 +0300, Daniil Elovkov wrote:
> > Did you use "-auto-all", to automatically create cost centers for all
> > top-level functions? I find that I get very verbose cost info for
> > definitions under imported libraries.
>
> Yeah, I've got it. Modules in packages were done
On Thu, 2009-11-12 at 10:46 +0100, Daniel Kahlenberg wrote:
> to answer this question myself how the use of another gcc is specified
> with effect, I used the following options with the 'cabal install' call:
>
> --ghc-options="-pgmc e:/programme/ghc/mingw-gcc4/bin/gcc.exe -pgml
> e:/programme/ghc
On Fri, 2009-11-06 at 01:13 +0100, Niklas Broberg wrote:
> > Can someone please comment on these two proposed changes. I agree with
> > Niklas but I'm a bit reluctant to apply the patches without at least
> > some sign of agreement from someone else.
> >
> > Deprecating PatternSignatures seems unc
On Fri, 2009-10-30 at 17:17 +, Neil Brown wrote:
> Hi,
>
> The GHC manual says that if you pass -cpp to GHC, it runs the C
> preprocessor, "cpp" on your code before compilation
> (http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.html#c-pre-processor).
> But why, in that
On Wed, 2009-10-28 at 22:55 +, Simon Peyton-Jones wrote:
> SECOND, we have produced Release Candidate 1 for GHC 6.12.1, and are
> about to produce RC2. However, before releasing 6.12 we'd like to
> compile all of Hackage, in case doing so reveals bugs in GHC's APIs
> (which are not supposed t
On Sun, 2009-10-18 at 16:01 -0200, Marco Túlio Gontijo e Silva wrote:
> Hi.
>
> I sent a mail to gtk2hs-devel about this bug, and I'm forwarding it's
> response to here.
This limitation might be different now that ghc is using libffi.
Duncan
> > I don't have a clue about this bug:
> > http://bu
On Mon, 2009-10-12 at 18:43 +0200, Christian Maeder wrote:
> P.S. I wonder why "Registering" is done twice
It's Cabal's fault. It's a new feature to let components within a
package depend on each other. To do that it needs to register the lib
into a local inplace package db. At the moment it's al
On Mon, 2009-10-12 at 16:04 -0400, Brent Yorgey wrote:
> What's the canonical way to install a version of ghc but not have it
> be the default? i.e., I'd like to try testing this release candidate
> but I want to have to call it explicitly; I want 'ghc', 'ghc-pkg'
> etc. to still be aliases to ghc
On Mon, 2009-10-12 at 19:29 +0400, Bulat Ziganshin wrote:
> Hello Duncan,
>
> Monday, October 12, 2009, 6:58:43 PM, you wrote:
>
> >> also, i propose to enable +RTS -N by default. Haskell is very popular
> >> as multithreaded language, don't fool novices!
>
> > Note that you'd also have to enabl
On Mon, 2009-10-12 at 13:07 +0400, Bulat Ziganshin wrote:
> also, i propose to enable +RTS -N by default. Haskell is very popular
> as multithreaded language, don't fool novices!
Note that you'd also have to enable -threaded by default. This would
have other surprising effects (like breaking most
On Thu, 2009-10-08 at 19:27 +0100, Colin Paul Adams wrote:
> I've been using ghc 6.10.3 on 64-bit Linux to compile my application,
> and it runs OK, modulo bugs.
>
> I want to debug a problem, so I load it in ghci, but when i type main
> I get:
>
> Loading package network-2.2.1.1 ...
>
> GHCi
On Thu, 2009-10-08 at 18:32 +1100, Manuel M T Chakravarty wrote:
> 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
>
On Tue, 2009-09-15 at 16:56 +0200, Karel Gardas wrote:
> Hello,
>
> recently I've found out that my solaris-based GHC buildbot is completely
> unusable since it always (when it get to, which means it does not fail
> with usual magic number mismatch: old/corrupt interface file?) fails with:
> ghc-
On Mon, 2009-09-07 at 11:24 -0700, Judah Jacobson wrote:
> I'm not sure I understand. Are you saying that you can't use
> backspace/arrows/etc when the getLine command itself is waiting for
> input? But otherwise at the "Prelude>" prompt, where you type in the
> commands, everything behaves fine
On Fri, 2009-08-28 at 11:42 +0100, Simon Marlow wrote:
> Can anyone think of a good reason not to upgrade darcs to 2.3.0 on
> darcs.haskell.org? I can think of 3 reasons to do so:
>
> - this script, for preventing accidental divergence from upstream
> - faster pushes, due to transfer-mode
>
On Wed, 2009-08-26 at 17:15 +0100, Simon Marlow wrote:
> * Sometimes we want to make local modifications to INDEPENDENT
> libraries:
> - when GHC adds a new warning, we need to fix instances of the
> warning in the library to keep the GHC build warning-free.
I have to say I th
On Sat, 2009-08-22 at 15:52 +1000, John Lask wrote:
> in declaring fixity for an operator (\\) to get it to compile using ghc
> 6.10.4, I needed to use the following code
>
> infixl 9 \\\
> (\\) a b = etc ...
>
> where I assume the first \ escapes the second \, using infixl 9 \\ generates
> a s
On Thu, 2009-07-30 at 15:12 +0200, Christian Maeder wrote:
> Don Stewart wrote:
> > Heads up lads, we're about 24 hours from Haskell Platform 2009.2.0.2
> >
> > http://code.haskell.org/haskell-platform/haskell-platform.cabal
>
> I still see
>
> time ==1.1.2.4,
>
> although ghc-
On Fri, 2009-08-07 at 13:14 +0200, Christian Maeder wrote:
> Christian Maeder wrote:
> > Matthias Kilian wrote:
> >> However, to create an archive, you can use something like
> >>
> >> $ pax -wf foo.tar directory
> >
> > Do you think "gtar --format=posix" would be different from pax?
I would expe
On Fri, 2009-08-07 at 10:55 +0200, Christian Maeder wrote:
> Duncan Coutts wrote:
> > I should also note that there is a GHC 6.10.4 binary for Sparc/Linux
> > that is now included with Gentoo. It's got all features turned on except
> > for split objects (which fails due t
On Thu, 2009-08-06 at 12:30 +0100, Duncan Coutts wrote:
> On Tue, 2009-08-04 at 10:15 +0200, Christian Maeder wrote:
> > Hi,
> >
> > I've just been informed that unpacking the binary (i386) solaris
> > distribution using bunzip2 and tar:
>
> It may work bet
On Thu, 2009-08-06 at 10:04 +0200, Christian Maeder wrote:
> Hi Ian,
>
> could you add a note on the download page that
> GCC version 4.3.x is not suited for:
>
> http://www.haskell.org/ghc/dist/6.10.4/maeder/ghc-6.10.4-sparc-sun-solaris2.tar.bz2
>
> The binary-dist was compiled using gcc-4.2.2
On Tue, 2009-08-04 at 10:15 +0200, Christian Maeder wrote:
> Hi,
>
> I've just been informed that unpacking the binary (i386) solaris
> distribution using bunzip2 and tar:
It may work better in future if you use a non-GNU tar to pack it up in
the first place. GNU tar uses a non-standard tar forma
On Tue, 2009-06-30 at 14:45 +0100, Simon Peyton-Jones wrote:
> I've dumped all this on a release plans wiki page:
> http://hackage.haskell.org/trac/ghc/wiki/Status/Releases
>
> Manuel, Duncan: maybe you can modify the wiki directly?
Done. Fortunately there's not much left to do for shared l
On Wed, 2009-06-03 at 16:41 +0200, Niklas Broberg wrote:
> Second there's the constructor NoMonoPatBinds, which actually
> describes the default Haskell 98 behavior, even if GHC has a different
> default. It's GHC's behavior that is the extension, so the constructor
> in cabal should really be nam
On Thu, 2009-06-04 at 08:43 +0100, Simon Peyton-Jones wrote:
> I'd be quite happy to rename the flag to GeneralisedisedListComp, and
> clarify the user manual. Would that suit everyone?
>
> I suppose the alternative is to leave it as TransformListComp, and
> document that fact. But I rather agre
On Wed, 2009-06-03 at 15:59 -0400, David Menendez wrote:
> On Tue, Jun 2, 2009 at 5:38 AM, Duncan Coutts
> wrote:
> > OSX users,
> >
> > please could you try out Gregory's Haskell Platform package below and
> > send commentary to the platform list, or file ticke
On Wed, 2009-06-03 at 16:33 +0100, Max Bolingbroke wrote:
> 2009/6/3 Niklas Broberg :
> > First there's the constructor called TransformListComp, which should
> > really be named GeneralizedListComp, since the constructor should
> > describe the extension and not the implementation scheme.
>
> It'
OSX users,
please could you try out Gregory's Haskell Platform package below and
send commentary to the platform list, or file tickets in the platform
trac, that'd be great.
http://trac.haskell.org/haskell-platform/newticket?component=OSX%20installer
The plan is that for ghc-6.12 and onwards, tha
All,
This is a draft proposal for a common mechanism for implementing
relative paths in installed package descriptions.
Comments and feedback are welcome. I'm cc'ing this to the cabal and
ghc-users lists but let's keep the discussion on the libraries list.
There has been some discussion of this
On Thu, 2009-05-28 at 23:40 +0100, Claus Reinke wrote:
> >> If you don't want to move from absolute paths for non-core packages,
> >> the current system should just work, right?
> >
> > Yes.
>
> The current system being the $topdir one.
Yep. It works, it's just not nice, it's ghc-specific and on
On Thu, 2009-05-28 at 14:12 +0100, Claus Reinke wrote:
> > But if you're registering global packages that are installed outside of
> > the GHC tree then you wouldn't register them using relative paths. I'm
> > not saying everything must use relative paths.
>
> Please don't move your windmills whil
On Wed, 2009-05-27 at 21:17 +0100, Duncan Coutts wrote:
> To be clear, here's what I'm imagining:
>
> blah/package.conf
> blah/lib/foo-1.0/libfoo-1.0.a
>
> and package.conf would contain foo-1.0 with paths looking like
> "$dbdir/lib/foo-1.0". That is,
On Thu, 2009-05-28 at 11:16 +0100, Claus Reinke wrote:
> >> > How about this: a way to specify paths in the package registration info
> >> > that
> >> > are relative to the location of the package db they are in.
> >> ahem. That sounds like a backwards step, being dependent on two
> >> locations
On Wed, 2009-05-27 at 19:47 +0100, Claus Reinke wrote:
> > We need a clear spec on what variables tools are expected to handle and
> > how they are to be interpreted.
>
> Currently, there seem to be $topdir and $httptopdir.
And I can't see a justification for there being two.
> Given the split
On Wed, 2009-05-27 at 15:10 +0100, Alistair Bayley wrote:
> Andrea,
>
> 2009/3/19 Andrea Vezzosi :
> > It turns out that those variables are there to allow relocation, in
> > fact $topdir is expanded by
> > Distribution.Simple.GHC.getInstalledPackages, it seems that
> > $httptopdir has been overlo
On Fri, 2009-05-22 at 16:34 +0200, Daniel Fischer wrote:
> > That's great, thank you. I am still baffled, though.
I'm baffled too! I don't see the same behaviour at all (see the other
email).
> > Must every exported function that uses `par' be INLINEd? Does every
> > exported caller of such
On Fri, 2009-05-22 at 05:30 -0700, Don Stewart wrote:
> Answer recorded at:
>
> http://haskell.org/haskellwiki/Performance/Parallel
I have to complain, this answer doesn't explain anything. This isn't
like straight-line performance, there's no reason as far as I can see
that inlining should c
On Sat, 2009-05-16 at 22:31 +0400, Bulat Ziganshin wrote:
> Hello glasgow-haskell-users,
>
> http://www.nongnu.org/cinvoke/faq.html
>From the page:
How does C/Invoke compare to libFFI?
At the C API level they're pretty similar, aside from some minor
quibbles. lib
On Sat, 2009-05-16 at 11:07 +0100, Neil Mitchell wrote:
> I don't, although having that option wouldn't be a bad thing - having
> a minimal .lib is perfectly reasonable as a default. Having a massive
> .lib seems crazy. (The fact that .lib is named .dll.a isn't too much
> of an issue)
It's possib
On Fri, 2009-05-15 at 15:31 +0100, Neil Mitchell wrote:
> Hi,
>
> I've just built a Haskell dll on Windows. As part of the process it
> generated an 14Mb foo.dll, and a 40Mb foo.dll.a. Looking at the flags
> passed to ld I see --out-implib=foo.dll.a. What is the purpose of the
> .a file? What migh
On Thu, 2009-05-07 at 15:12 +0100, Neil Mitchell wrote:
> >> This is a test framework that spawns system commands. My guess is the
> >> Haskell accounts for a few milliseconds of execution per hour. Running
> >> two system commands in parallel gives a massive boost.
> >
> > That still doesn't expl
On Tue, 2009-05-05 at 00:43 +0100, Geraint Jones wrote:
> Sorry to revive a year-old thread, but...
>
> On Fri, 25 Apr 2008 at 20:17:53 +0100 Duncan Coutts wrote:
> > On Fri, 2008-04-25 at 09:08 -0700, Don Stewart wrote:
> > > Geraint.Jones:
> > > > Are
On Fri, 2009-04-24 at 12:56 +0200, Philip K.F. Hölzenspies wrote:
> Dear GHCers,
>
> I am trying to write a wrapper library for lab work to give to students.
> My problem is, that the libraries I use require initialization that I
> really want to hide from our students. The wrapper I'm writing is
On Thu, 2009-04-23 at 05:59 -0700, Sigbjorn Finne wrote:
> On 4/23/2009 02:05, Duncan Coutts wrote:
> > On Wed, 2009-04-22 at 18:55 -0700, Sigbjorn Finne wrote:
> >
> >> Hi Ian,
> >>
> >> thanks for the update on plans and the willingness to jump in
On Wed, 2009-04-22 at 18:55 -0700, Sigbjorn Finne wrote:
> Hi Ian,
>
> thanks for the update on plans and the willingness to jump in and do another
> release cycle so soon after 6.10.2. The suggested fixes seem agreeable to
> me, but I have one _minor_ additional request for 6.10.3 if you end havi
On Sat, 2009-04-11 at 21:07 +0400, Bulat Ziganshin wrote:
> Hello Bertram,
>
> Saturday, April 11, 2009, 8:09:46 PM, you wrote:
>
> > What does "same thread" mean? I'll risk a guess.
>
> well, that's possible - i'll ask on gtk2hs list too
>
> currently, i believe that mainGUI just runs endless
On Thu, 2009-04-02 at 13:47 +0900, Benjamin L.Russell wrote:
> On Wed, 1 Apr 2009 18:48:13 -0700, Lyle Kopnicky
> wrote:
>
> >Great! But what happened to the time package? It was in 6.10.1. Has it been
> >intentionally excluded from 6.10.2?
Yes, the maintainer of the time package asked for it to
On Wed, 2009-03-25 at 18:01 +, Claus Reinke wrote:
> With the hint about branch prediction, I also found this old ticket
> (which seems to have been waiting for the new backend, and
> indicates rather larger performance differences):
>
> Offer control over branch prediction
> http:/
On Wed, 2009-03-25 at 09:18 +, Simon Peyton-Jones wrote:
> * More promising might be to say "this is the hot branch". That information
> about frequency could in principle be used by the back end to generate better
> code. However, I am unsure how
> a) to express this info in sourc
On Thu, 2009-03-19 at 16:34 -0700, Don Stewart wrote:
> We must have the gtk2hs team invovled in this discussion. They were
> using an undocumented feature. It may be trivial to fix.
> > > This will need to be fixed in gtk2hs. Previously GHC allowed finalizers
> > > to call back into Haskell, but
On Tue, 2009-03-17 at 21:12 -0400, Brandon S. Allbery KF8NH wrote:
> On 2009 Mar 17, at 20:28, Duncan Coutts wrote:
> > It works for me under Solaris 10. Perhaps Solaris 9 or older do not
> > have a standard compliant /bin/sh program. What do you suggest we use
> > in
On Tue, 2009-03-17 at 11:09 +0100, Christian Maeder wrote:
> GHC 6.10.2 will have a problem with cabal-install-0.6.2!
>
> When I tried to install cabal-install-0.6.2 for ghc-6.10.1.20090314
> I needed to change #!/bin/sh to #!/bin/bash in bootstrap.sh to avoid the
> following errors:
>
> -bash-3.
On Tue, 2009-03-17 at 08:53 +, Simon Marlow wrote:
> Duncan Coutts wrote:
> > On Mon, 2009-03-16 at 12:13 +, Simon Marlow wrote:
> >
> > Yes, if we know we're using it. If we specify -package blah on the
> > command line then we do know we're using it
On Mon, 2009-03-16 at 16:04 -0700, Conal Elliott wrote:
> On Mon, Mar 16, 2009 at 2:47 PM, Duncan Coutts
> wrote:
> On Mon, 2009-03-16 at 12:13 +, Simon Marlow wrote:
> > Perhaps I'm missing something, but if applicative-numbers is
> an expo
On Mon, 2009-03-16 at 12:13 +, Simon Marlow wrote:
> > This sounds like a chicken and egg problem. To know which package
> > include directories to use GHCi needs to know which packages your module
> > uses. However to work out which packages it needs it has to load the
> > module which means
On Sun, 2009-03-15 at 09:13 -0700, Conal Elliott wrote:
> That did it. I've added ":set -package applicative-numbers" to
> my .ghci and am back in business. Thanks!
>
> IIUC, there's an inconsistency in ghci's treatment of modules vs
> include files, in that modules will be found without -packag
On Sat, 2009-03-14 at 23:43 -0700, Conal Elliott wrote:
> The applicative-numbers package [1] provides an include file. With
> ghci, the include file isn't being found, though with cabal+ghc it is
> found.
>
> My test source is just two lines:
>
> {-# LANGUAGE CPP #-}
> #include "ApplicativeNume
On Sun, 2009-03-08 at 12:29 +, Tuomo Valkonen wrote:
> I want a _real_ cygwin version of darcs. The non-deterministic
> pseudo-cygwin *nix/Windows hybrid currently available has just
> too many problems integrating into cygwin, that I want to use as
> my TeXing and minor coding environment. A
On Tue, 2009-02-10 at 17:15 +, Ian Lynagh wrote:
> Hi all,
>
> Currently, hsc2hs (as shipped with GHC) cannot be used with just
> hsc2hs Foo.hsc
> as it cannot find HsFFI.h (http://hackage.haskell.org/trac/ghc/ticket/2897).
> To make it work you need to run something like
> hsc2hs -I /
On Tue, 2009-02-17 at 08:47 +, Simon Marlow wrote:
> Duncan Coutts wrote:
> > Maybe. Dealing with linker scripts properly is probably rather tricky
> > and we get it for free when we switch to shared libraries.
>
> I don't follow this last point - how does switchi
On Sun, 2009-02-15 at 11:06 +, Duncan Coutts wrote:
> On Sun, 2009-02-15 at 09:24 +, Neil Mitchell wrote:
> > Hi
> >
> > >> What have I done wrong? Did createProcess close the handle, and is
> > >> there a way round this?
> > >
> >
On Thu, 2009-02-12 at 10:11 +0100, Christian Maeder wrote:
> Duncan Coutts wrote:
> > On Wed, 2009-02-11 at 15:49 +0100, Lennart Augustsson wrote:
> >> Does this version work from ghci?
> >>
> >> -- Lennart
> >
> > Specifically I believe Lennart
On Tue, 2009-02-10 at 13:43 +, Simon Marlow wrote:
> Simon Peyton-Jones wrote:
> > I'm guessing a bit here, but it looks as if you intend this:
> >
> > * GHC should read Foo.hs, and see {-# LANGUAGE CPP #-}
> > * Then it should run cpp
> > * Then it should look *again* in the result of running
On Thu, 2009-02-05 at 00:11 +0100, Deniz Dogan wrote:
> I'm currently working on "hacking" Data.Generics for my master thesis.
> I'm basically trying to find out whether it can be made any faster
> using e.g. rewrite rules. The problem I'm having is that I need an
> easy way to import my own modifi
1 - 100 of 458 matches
Mail list logo
