On Tue, May 13, 2014 at 11:20:25PM -0700, John Meacham wrote:
Okay, I believe I have come up with a modified version that accepts many more
programs and doesn't require complicated comma handling, you can make all
decisions based on the top of the context stack. It also allows many useful
On Tue, May 13, 2014 at 09:32:31PM +0100, Simon Marlow wrote:
On 13/05/14 15:04, John Meacham wrote:
Hi, I noticed that ghc now supports an 'AlternateLayoutRule' but am
having trouble finding information about it. Is it based on my
proposal and sample implementation?
On Tue, May 13, 2014 at 03:11:16PM -0700, John Meacham wrote:
ah cool, can you point me to which file it is implemented in in the source
so I can copy your new rules?
It's lexTokenAlr and friends in compiler/parser/Lexer.x
It's a while since I looked at it, but IIRC it's not as clean to read
On Tue, Apr 01, 2014 at 12:46:05PM +0200, Joachim Breitner wrote:
happy with buildbot, it might not be the worst choice.
For reference, the reason we moved away from buildbot is that it needs
to maintain a TCP connection for the duration of the build. With some
builds taking many hours (either
On Tue, Aug 13, 2013 at 09:47:49PM +0100, Simon Marlow wrote:
On 17/05/13 20:01, Ian Lynagh wrote:
I'd be in favour of allowing a trailing or leading comma anywhere that
comma is used as a separator. TupleSections would need to be changed or
removed, though.
The type constructors
On Tue, Jun 04, 2013 at 01:06:25PM +0100, Simon Marlow wrote:
Hardly anybody uses haskell98 or haskell2010, so we would still have
a backwards compatibility problem.
I meant 'base' to be included in 'these packages'; I've clarified the
wiki page.
Thanks
Ian
--
Ian Lynagh, Haskell
these?:
import Prelude.XYZ as Foo
import Foo as Prelude.XYZ
Thanks
Ian
--
Ian Lynagh, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman
on an earlier draft.
Thanks
Ian
--
Ian Lynagh, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
step, which hasn't seen much support.
Just to clarify: This proposal is to stop importing the module
implicitly, not to actually remove the module.
Thanks
Ian
--
Ian Lynagh, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
Haskell
be maintained, with
additional imports not being needed until code migrates to the
split-base packages.
Thanks
Ian
--
Ian Lynagh, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http
On Sun, May 12, 2013 at 04:50:40PM -0400, Carter Schonwald wrote:
huh you're right!
I seem to recall that that snapshots hadn't been updated since december
while they were still up though...
Yes, uploading new snapshots is waiting for me to find some time to
implement a way to upload without
report will be updated as proposals are
accepted, but new versions of the standard will only be released once a
year, during January.
The Haskell 2014 committee is comprised of:
* Carlos Camarão
* Iavor Diatchki
* Ian Lynagh (chair)
* John Meacham
* Neil Mitchell
* Ganesh
report will be updated as proposals are
accepted, but new versions of the standard will only be released once a
year, during January.
The Haskell 2014 committee is comprised of:
* Carlos Camarão
* Iavor Diatchki
* Ian Lynagh (chair)
* John Meacham
* Neil Mitchell
* Ganesh
=
The (Interactive) Glasgow Haskell Compiler -- version 7.6.3
=
The GHC Team is pleased to announce a new patchlevel release of GHC, 7.6.3.
This is a bugfix release
On Thu, Apr 18, 2013 at 06:48:12AM -0400, Dubiousjim wrote:
On Wed, Apr 17, 2013 at 11:18:52PM +0100, Ian Lynagh wrote:
On Fri, Apr 05, 2013 at 11:12:38PM -0400, Dubiousjim wrote:
target$ inplace/bin/ghc-stage2 -o hello-cross hello.hs
[1 of 1] Compiling Main ( hello.hs
=
The (Interactive) Glasgow Haskell Compiler -- version 7.6.3
=
The GHC Team is pleased to announce a new patchlevel release of GHC, 7.6.3.
This is a bugfix release
On Thu, Apr 18, 2013 at 12:21:26PM -0400, Ben Gamari wrote:
what is the plan for
7.8? Will it admit API breakage? Should we establish a timeframe for getting
work in before a formal release candidate is cut?
7.8 will be released as shortly after ICFP as we can. It will allow API
changes.
On Fri, Apr 05, 2013 at 11:12:38PM -0400, Dubiousjim wrote:
target$ inplace/bin/ghc-stage2 -o hello-cross hello.hs
[1 of 1] Compiling Main ( hello.hs, hello.o )
Linking hello-cross ...
target$ ./hello-cross
Can't modify application's text section; use the GCC
On Sun, Mar 24, 2013 at 10:19:14AM +0200, kudah wrote:
Does ghc still build under cygwin
Sorry, no; we only support targetting mingw, not cygwin.
Also, is it possible yet to build a ghc cross-compiler targeting
windows?
I don't think anyone's tried.
Thanks
Ian
On Thu, Mar 21, 2013 at 10:21:25AM +0800, John Lato wrote:
What would be ideal would be if this library API freeze coincided with
the snapshot (odd-numbered) release.
I was only thinking of about a 2 week period, and only on the stable
branch. Freezing the library APIs in HEAD after a
We've had long discussions about snapshot releases, and the tricky part
is that while we would like people to be able to try out new GHC
features, we don't want to add to the burden of library maintainers by
requiring them to update their libraries to work with a new GHC release
more than once a
Hi David,
On Tue, Jan 22, 2013 at 09:39:40PM -0800, David Terei wrote:
This bug is still present in mainline. Any chance of it being fixed?
I've just built HEAD with 7.6.2, so I think this has been fixed. If not,
please give me more details on how to reproduce it.
Thanks
Ian
Hi all,
Thank you to everyone who gave us feedback on when we should release
7.8.1, and on future release plans in general. We've looked at all the
responses, and we think that the best plan is to continue to make major
releases annually, with minor patch-level releases between them.
On Tue, Mar 12, 2013 at 09:47:21AM +0100, Joachim Breitner wrote:
This is especially true when the shim packages are less simple to use,
due to the handling of Prelude.
Just to make sure I am following you, I think you are saying:
Everything would work fine if there was a Prelude in base
On Tue, Mar 12, 2013 at 03:58:28PM +0100, Joachim Breitner wrote:
Both have issues: Putting it in file-io will cause everyone to depend on
file-io
If it ended up there, then we'd presumably encourage people to use
NoImplicitPrelude and import e.g. list functions from Data.List rather
than
On Wed, Feb 27, 2013 at 04:54:35PM +, Simon Marlow wrote:
On 25/02/13 18:05, Ian Lynagh wrote:
Personally, I don't think the language report should be specifying the
content of libraries at all,
It's not that straightforward, because the language report refers to
various library
On Mon, Feb 25, 2013 at 02:25:03PM +, Simon Peyton-Jones wrote:
| I added a Goals section to
| http://hackage.haskell.org/trac/ghc/wiki/SplitBase
Thanks. But the first goal, which is the dominant one, is very unclear to me
as my comments mentioned. A description of what the problem
On Mon, Feb 25, 2013 at 02:31:56PM +0100, Joachim Breitner wrote:
Hopefully the problem here (often-changing base) is big enough and the
alternative (more purpose-oriented and more stable) packages are
attractive enough to make people use the new set.
I'm pretty confident that most packages
On Mon, Feb 25, 2013 at 11:29:42AM -0500, Stephen Paul Weber wrote:
Somebody claiming to be Ian Lynagh wrote:
On Mon, Feb 25, 2013 at 02:31:56PM +0100, Joachim Breitner wrote:
In any case there is still the problem: What and where is the Prelude...
but maybe let’s postpone this.
I'd put
On Mon, Feb 25, 2013 at 06:38:46PM +0100, Herbert Valerio Riedel wrote:
Ian Lynagh i...@well-typed.com writes:
[...]
If we did that then every package would depend on haskell2010, which
is fine until haskell2013 comes along and they all need to be changed
(or miss out on any
On Fri, Feb 22, 2013 at 07:52:00PM +0100, Joachim Breitner wrote:
Of course with too much splitting one runs in the Bane of the Orphaned
Instances – neither should base-foreign require base-float nor the other
way around, but Storable Double needs to be define somewhere...
This is no
On Fri, Feb 22, 2013 at 11:38:04AM -0800, Johan Tibell wrote:
Glad to see you're making progress on this. Once we're done exploring how
fine-grained we can make the division we might want to pull back a bit
I definitely agree with Once we're done. Once we have made all the
splits we might
On Fri, Feb 15, 2013 at 02:45:19PM +, Simon Marlow wrote:
Remember that fingerprinting is not hashing. For fingerprinting we
need to have a realistic expectation of no collisions. I don't
think FNV is suitable.
I'm sure it would be possible to replace the C md5 code with some
On Thu, Feb 14, 2013 at 03:48:51PM +0100, Joachim Breitner wrote:
Yesterday, I experimented a bit with base’s code, first beginning with
as few modules as possible and adding what’s required; then starting
with the whole thing and trying to remove e.g. IO.
But clearly it is not easy:
On Wed, Feb 13, 2013 at 09:00:15AM +, Simon Marlow wrote:
I believe Ian has done some experiments with splitting base further,
so he might have more to add here.
There are some sensible chunks that can be pulled out, e.g. Foreign.*
can be pulled out into a separate package fairly easily
On Wed, Feb 13, 2013 at 06:28:22PM +0100, Joachim Breitner wrote:
Am Mittwoch, den 13.02.2013, 13:58 + schrieb Ian Lynagh:
If we go this route, then we would probably want to end up without a
package called 'base', and then to make a new package called 'base'
that just re-exports
On Wed, Feb 13, 2013 at 07:32:06PM +0100, Joachim Breitner wrote:
I have started a wikipage with the list of all modules from base, for a
first round of shuffling, grouping and brainstorming:
http://hackage.haskell.org/trac/ghc/wiki/SplitBase
Great, thanks for taking the lead on this!
On Mon, Feb 11, 2013 at 10:09:56AM +0800, John Lato wrote:
What I would like to see are more patch-level bugfix releases. I suspect
the reason we don't have more is that making a release is a lot of work.
So, Ian, what needs to happen to make more frequent patch releases
feasible?
Well,
*
On Sun, Feb 10, 2013 at 06:35:25PM +0800, Magicloud Magiclouds wrote:
Linuxmint Nadia, ghc-7.6.1 was built and running OK.
Just downloaded ghc-7.6.2, without changing anything and environment, and
boot and configure returned OK, I got these. What happened?
/usr/local/bin/ghc -H32m -O
On Sun, Feb 10, 2013 at 09:02:18PM +, Simon Peyton-Jones wrote:
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.
On Sun, Feb 10, 2013 at 09:30:23PM +, Simon Peyton-Jones wrote:
| 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
On Sat, Feb 09, 2013 at 12:06:12PM +, Simon Marlow wrote:
As a straw man, let's suppose we want to do annual API releases in
September, with intermediate non-API releases in February.
That's a non-API release 5 months after the API release.
6.10.2 was 5 months after 6.10.1 (.3 was 1
On Thu, Feb 07, 2013 at 09:42:39AM -0800, Mark Lentczner wrote:
I wish GHC would radically change it's release process. Things like 7.8
shouldn't be release as 7.8. That sounds major and stable. The web site
will have 7.8 at the top. The warning to use the platform will fall flat
because it
, library maintainers, the HP, etc. But I
wouldn't advocate it either; from GHC's point of view, historically
we've always had enough new stuff to justify a new major release after a
year.
Thanks
Ian
--
Ian Lynagh, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com
I'm not too optimistic we could actually get the final release out
during February, assuming we want to allow a couple of weeks for people
to test an RC.
Does the Haskell Platform actually want to commit to using a GHC release
with tons of [new] stuff, that has had little testing, days or weeks
On Mon, Feb 04, 2013 at 07:26:16PM -0500, Edward Kmett wrote:
If space sensitivity or () disambiguation is being used on !, could one of
these also be permitted on ~ to permit it as a valid infix term-level
operator?
I don't think there's any reason ~ couldn't be an operator, defined with
the
On Mon, Feb 04, 2013 at 10:37:44PM +, Simon Peyton-Jones wrote:
I don't have a strong opinion about whether
f ! x y ! z = e
should mean the same; ie whether the space is significant. I think it's
probably more confusing if the space is significant (so its presence or
absence
On Sun, Feb 03, 2013 at 10:34:04PM +, Ben Millwood wrote:
On Fri, Feb 01, 2013 at 05:10:42PM +, Ian Lynagh wrote:
The first is suggested by A bang only really has an effect if it
precedes a variable or wild-card pattern on
http://hackage.haskell.org/trac/haskell-prime/wiki
On Fri, Jan 18, 2013 at 01:05:05PM -0700, Caitlin wrote:
I deleted the Haskell Platform installation, manually removed all traces of
GHC and the Hakell Platform from my registry and various folders, then
re-installed the Haskell Platform. I created a folder under the 'C:\'
drive, copied my
Hi all,
I would like to get a full specification of the bang patterns syntax,
partly so it can be proposed for H', and partly so we can resolve
tickets like http://hackage.haskell.org/trac/ghc/ticket/1087 correctly.
I think there are 3 possibilities:
The first is suggested by A bang only
Hi Malcolm,
On Wed, Dec 12, 2012 at 10:40:53AM +, Malcolm Wallace wrote:
Please send nominations to haskell-2011-commit...@haskell.org, summarising
your interest and experience. The existing committee will (I hope) make some
decision on how to proceed, in early January 2013.
Any
On Fri, Feb 01, 2013 at 05:31:53PM +, Malcolm Wallace wrote:
The committee has received no nominations.
At least one was sent. Does haskell-2011-commit...@haskell.org accept
mails from non-members?
Thanks
Ian
___
Haskell-prime mailing list
=
The (Interactive) Glasgow Haskell Compiler -- version 7.6.2
=
The GHC Team is pleased to announce a new patchlevel release of GHC, 7.6.2.
This release fixes a
=
The (Interactive) Glasgow Haskell Compiler -- version 7.6.2
=
The GHC Team is pleased to announce a new patchlevel release of GHC, 7.6.2.
This release fixes a
On Mon, Jan 14, 2013 at 03:28:15PM -0800, Johan Tibell wrote:
On Mon, Jan 14, 2013 at 3:18 PM, Evan Laforge qdun...@gmail.com wrote:
I assume it would change from doesn't compile to works if you add
the required import. It's the same as the FFI thing, right? If you
don't import M (T(..)),
On Mon, Jan 14, 2013 at 09:03:38PM +0200, Roman Cheplyaka wrote:
* Simon Peyton-Jones simo...@microsoft.com [2013-01-14 18:09:50+]
Friends
I'd like to propose a way to promote newtypes over their enclosing type.
Here's the writeup
Hi Sean,
On Mon, Dec 10, 2012 at 04:04:34PM +0100, Sean Leather wrote:
On Sun, Dec 9, 2012 at 10:39 PM, Ian Lynagh wrote:
Please test as much as possible; bugs are much cheaper if we find them
before the release!
I tried to build the source tarball on Mac OS X 10.5.8. I used GHC
On Thu, Dec 13, 2012 at 12:31:09PM +0100, Goetz Isenmann wrote:
This change
https://github.com/ghc/ghc/commit/106f0434144199276add8860c146c542cc67513b
is missing for a success build on DragonFly-3.2/x86_64
Thanks, I've merged it to the 7.6 branch now.
Thanks
Ian
On Tue, Jan 08, 2013 at 08:10:18PM +, 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 7.6 repo to match the tag.
Thanks
Ian
___
Hi Jan,
On Sat, Dec 15, 2012 at 04:08:23PM +0100, Jan Stolarek wrote:
[killy@xerxes : /dane/uczelnia/projekty/ghc-build] ./configure
checking for gfind... no
checking for find... /usr/bin/find
checking for GHC version date... configure: WARNING: cannot determine
snapshot version: no .git
Hi Tim,
On Sun, Dec 09, 2012 at 11:53:32AM -0300, tim.beech wrote:
My build script unpacks the binary distribution for unknown linux and
builds GHC against that. (Both are version 7.4.2.) I have avoided
installing anything else (such as the Haskell Platform) so as to keep as
close as
On Sat, Dec 15, 2012 at 09:41:12AM +0100, Jan Stolarek wrote:
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
On Fri, Dec 14, 2012 at 02:44:19PM +, Simon Peyton-Jones wrote:
This thread has made it clear that we should do more to help people find a
way in to GHC.
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
On Fri, Dec 14, 2012 at 12:53:36PM -0800, Johan Tibell wrote:
I've been tracking down a few (unrelated) performance bugs related to
conversions between primitive types. What these issues had in common
is that some rule failed to fire and the conversion went via Integer,
killing performance.
Hi Carter,
On Fri, Dec 14, 2012 at 04:34:29PM -0500, Carter Schonwald wrote:
A related question I have is that I've some code that will map the
singleton Nats to Ints, and last time I looked into this/ had a chat on the
ghc-users list, it sounded like sometimes having Integer values
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
For automated commit messages from the git
Hi Joachim,
On Wed, Dec 12, 2012 at 12:20:35AM +0100, Joachim Breitner wrote:
I built GHC 7.6.2-rc1 for Debian.
Thanks for testing!
Provides: haddock, [-haddock-interface-21-] {+haddock-interface-22+}
i.e. upstream has bumped the haddock interface number. I really was not
expecting
We are pleased to announce the first release candidate for GHC 7.6.2:
http://www.haskell.org/ghc/dist/7.6.2-rc1/
This includes the source tarball, installers for Windows, and
bindists for Windows, Linux, OS X and FreeBSD, on x86 and x86_64.
We plan to make the 7.6.2 release early in 2013.
On Sun, Dec 09, 2012 at 05:45:17PM -0500, wren ng thornton wrote:
I'm one of those curmudgeons still working on OSX 10.5.8. Recently I
finally got around to building the latest GHC and, FWIW, everything
seems to have worked out fine. I did get a few failed tests in the
testsuite though, and
Hi Ron,
On Fri, Dec 07, 2012 at 03:33:01PM -0500, Ron Alford wrote:
I'm trying to see if this is reproducible, or it's just my machine.
This sounds like
http://hackage.haskell.org/trac/ghc/ticket/7043
Thanks
Ian
___
Glasgow-haskell-users
On Thu, Dec 06, 2012 at 09:15:06PM +, Simon Marlow wrote:
On 06/12/12 17:04, Ian Lynagh wrote:
It's true that we do give e-mailing it as a (less preferred) way for
users to submit a bug on
http://hackage.haskell.org/trac/ghc/wiki/ReportABug
but I wonder if we shouldn't change
On Thu, Dec 06, 2012 at 06:25:49PM +0200, Roman Cheplyaka wrote:
+1. I'd like to follow GHC development discussions, but getting all the
commits is too much.
I'm surprised by this, FWIW. I think skimming the commits is a good way
to get an idea of what's going on, while discussions between
On Thu, Dec 06, 2012 at 12:29:01PM +, Simon Peyton-Jones wrote:
My own understanding is this:
A GHC *user* is someone who uses GHC, but doesn't care how it is implemented.
A GHC *developer* is someone who wants to work on GHC itself in some way.
The current mailing lists:
*
On Thu, Dec 06, 2012 at 09:56:55PM +1100, Ben Lippmeier wrote:
I suppose I'm the default owner of the register allocators and non-LLVM
native code generators.
Great, thanks!
By the way, if you feel like doing some hacking this holiday season,
then you might be interested in
On Wed, Dec 05, 2012 at 12:42:33PM -0800, Johan Tibell wrote:
I will maintain the I/O manager as per usual
Excellent, thanks!
There are a couple of tickets that are currently assigned to me that
look like they might be IO manager bugs:
http://hackage.haskell.org/trac/ghc/ticket/4245
On Wed, Dec 05, 2012 at 12:37:22PM -0800, David Terei wrote:
I have always considered the LLVM code generator my responsibility and
will continue to do so.
Great, thanks!
I don't seem to find the time to make
improvements to it but make sure to keep it bug free and working with
the latest
On Mon, Dec 03, 2012 at 09:11:07PM +0100, Joachim Breitner wrote:
Dear GHC HQ: Would you advice against or for providing a RTS in the
thr_debug_p and thr_debug ways in the Debian package?
The main reasons not to add RTS ways are that they take time to build,
and use disk space once built. For
On Tue, Dec 04, 2012 at 04:23:02PM +0100, Dennis Felsing wrote:
Is there a way to extend GHCi without copying some of its source code?
Someone was looking at moving the ghci code into a library, which may
mean you need to copy less code, at least. I'm not sure what the status
of that is,
On Fri, Nov 30, 2012 at 12:28:41PM +, Simon Marlow wrote:
Static by default, GHCi is dynamic:
* still can't do this on Windows
We can do it on Windows: We can use side-by-side assemblies.
(well, assuming we fix #5987).
Thanks
Ian
___
On Fri, Nov 30, 2012 at 09:38:10AM -0800, Johan Tibell wrote:
On Fri, Nov 30, 2012 at 9:11 AM, Simon Peyton-Jones
simo...@microsoft.com wrote:
If Bryan and Johan are the Performance Tsars the future looks bright. Or at
least fast. Thank you.
If someone could point me to the build bot
On Wed, Nov 28, 2012 at 12:34:03PM +0100, Herbert Valerio Riedel wrote:
Ian Lynagh i...@well-typed.com writes:
[...]
There are also some policy questions we need to answer about how Cabal
will work with a GHC that uses dynamic libraries by default.
btw, how is it planned to have .so
On Wed, Nov 28, 2012 at 12:28:31AM +0100, Joachim Breitner wrote:
here comes the obligatory butting in by the Debian Haskell Group:
Given the current sensitivity of the ABI hashes we really do not want to
have Programs written in Haskell have a runtime dependency on all the
included
On Wed, Nov 28, 2012 at 09:09:58AM +, Simon Marlow wrote:
On 27/11/12 23:28, Joachim Breitner wrote:
Hence, Debian will continue to provide its libraries built the static
way.
So let me try to articulate the options, because I think there are
some dependencies that aren't obvious
On Wed, Nov 28, 2012 at 09:20:57AM +, Simon Marlow wrote:
My personal opinion is that we should switch to dynamic-by-default
on all x86_64 platforms, and OS X x86. The performance penalty for
x86/Linux is too high (30%),
FWIW, if they're able to move from x86 static to x86_64 dynamic
On Wed, Nov 28, 2012 at 04:00:02PM +0900, Jens Petersen wrote:
Could you say more about the impact to ghc-7.6.2 Cabal?
For example, question 8 is about whether Cabal should also build static
libraries for a dynamic-by-default compiler. We would like to ship a
version of Cabal that does the
On Wed, Nov 28, 2012 at 06:43:09AM +, Ganesh Sittampalam wrote:
On 27/11/2012 14:52, Ian Lynagh wrote:
GHC HEAD now has support for using dynamic libraries by default (and in
particular, using dynamic libraries and the system linker in GHCi) for a
number of platforms.
This has
On Wed, Nov 28, 2012 at 01:28:54PM +, Simon Marlow wrote:
On 28/11/12 12:48, Ian Lynagh wrote:
On Wed, Nov 28, 2012 at 09:20:57AM +, Simon Marlow wrote:
My personal opinion is that we should switch to dynamic-by-default
on all x86_64 platforms, and OS X x86.
I should have deleted
On Wed, Nov 28, 2012 at 01:34:22PM +, Ganesh Sittampalam wrote:
On 28/11/2012 13:13, Ian Lynagh wrote:
More generally, if you can implement the half a plan you mentioned
elsewhere in the thread for quickly building both static and dynamic
ways, then the combination of the ABI
On Wed, Nov 28, 2012 at 11:04:44AM -0500, Stephen Paul Weber wrote:
Building them also in the dynamic way for the sake of GHCi users seems
possible.
Perhaps Debian could just ship a GHCi that uses the RTS linker, as
now? The change is to be made for some platforms, we could opt to
have
:
http://hackage.haskell.org/trac/ghc/wiki/DynamicByDefault
If you have a few minutes to read it then we'd be glad to hear your
feedback, to help us in making our decisions
Thanks
Ian
--
Ian Lynagh, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com
On Tue, Nov 27, 2012 at 10:22:12AM -0500, Stephen Paul Weber wrote:
Somebody claiming to be Ian Lynagh wrote:
GHC HEAD now has support for using dynamic libraries by default (and in
particular, using dynamic libraries and the system linker in GHCi) for a
number of platforms.
The various
On Tue, Nov 27, 2012 at 12:07:34PM -0500, Stephen Paul Weber wrote:
Somebody claiming to be Ian Lynagh wrote:
On Tue, Nov 27, 2012 at 10:22:12AM -0500, Stephen Paul Weber wrote:
IIRC, one of the problems with dynamic linking in GHC is that when
the GHC version is different, the ABI can often
On Tue, Nov 27, 2012 at 08:38:21PM +0100, Matthias Kilian wrote:
On Tue, Nov 27, 2012 at 02:52:48PM +, Ian Lynagh wrote:
The various issues are described in a wiki page here:
http://hackage.haskell.org/trac/ghc/wiki/DynamicByDefault
If you have a few minutes to read it then we'd
On Tue, Nov 27, 2012 at 01:34:59PM -0800, Evan Laforge wrote:
I don't totally understand how ghci loading would work. I assume that
for external packages it will go load x.so instead of x.a, but what
about local modules? I assume ghc -c is still going to produce .o
files, so does that mean
On Sun, Nov 11, 2012 at 05:24:06PM -0800, Iavor Diatchki wrote:
There used to be a value called `tracingDynFlags` that I could use to dump
values, but it has disappeared... Did it get moved somewhere, or is there
a better way to get the same effect?
There is now
Hi Kazu,
On Tue, Aug 28, 2012 at 01:37:32PM +0900, Kazu Yamamoto wrote:
I seems to us (my friends and me) that term rewriting rules for
ByteString are not fired in recent GHCs.
Thanks for the report. I've filed a ticket here:
http://hackage.haskell.org/trac/ghc/ticket/7374
Thanks
Ian
Hi Apostolos,
On Sun, Sep 16, 2012 at 09:07:56AM -0400, asyropou...@aol.com wrote:
http://www.haskell.org/ghc/docs/6.4.1/html/building/sec-porting-ghc.html#sec-booting-from-hc
Some community members have made Solaris binary distributions in the
past. It would be easier to start from one of
On Tue, Sep 18, 2012 at 12:48:13PM -0700, Iavor Diatchki wrote:
Hello,
I was just trying to build the GHC-7.6 branch from source and the build
failed with type-errors, because the libraries used by GHC have moved on
since the release, and sync all just gets the most recent version.
Use
On Thu, Sep 06, 2012 at 09:42:53AM -0700, Johan Tibell wrote:
2. Could you please push all the packages that were released in GHC
7.6.1 to Hackage as well?
I've now uploaded those that we maintain.
Thanks
Ian
___
Glasgow-haskell-users mailing
On Thu, Sep 06, 2012 at 06:32:38PM +0200, Christian Hoener zu Siederdissen
wrote:
Awesome,
I have been playing with GHC 7.6.0 until today and been very happy. Btw.
isn't this the version that officially includes -fnew-codegen / HOOPL?
Because the new codegen is optimizing the my ADPfusion
1 - 100 of 1147 matches
Mail list logo
