have now.
Last Call: Are there any objections with GHC adopting "plan 4"[1]?
[1]: <https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp>
[2]: <http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/8869>
Thanks,
HVR
On 2015-05-06 at 13:08:03 +0200, Herbert Vale
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello *,
What?
=
We (see From: & CC: headers) propose, plain and simple, to turn the
currently defined type-synonym
type FilePath = String
into an abstract/opaque data type instead.
Why/How/When?
=
For details (including motivat
On 2015-06-27 at 03:30:56 +0200, Bardur Arantsson wrote:
[...]
> I am *entirely* behind this in priciple and if it doesn't break too much
> of Hackage, also in practice, but...
>
> ... how much of Hackage *does* this break?
This won't be for free: I expect most packages which currently do more
t
On 2015-06-27 at 14:56:33 +0200, David Fox wrote:
[...]
> I've had success with a slightly different "How":
What was your concrete use-case btw?
> Phase 1: Replace FilePath with a type class, with instances for the old
> FilePath (i.e. String) and the new implementation.
what would that compr
On 2015-07-03 at 05:26:44 +0200, Greg Weber wrote:
> Is the 7.10.2 hvr ppa using this RC?
...it's easy to check, as since 7.10 we embed the Git commit id into the
source-tarball as well as into the generated ghc binary:
$ /opt/ghc/7.10.2/bin/ghc --info | grep Git
,("Project Git commit id","5
On 2015-08-27 at 18:38:46 +0200, Simon Peyton Jones wrote:
> Great. Is there a ticket? If not, we'll probably lose track of it.
https://ghc.haskell.org/trac/ghc/ticket/10751
:-)
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cg
For the record,
I wanted to implement this feature a couple of months ago but then got
side-tracked. If somebody wants to pick it up (which would be great),
please lemme know.
In the meantime I've created
https://ghc.haskell.org/trac/ghc/ticket/10803
and write up the little information I have
On 2015-08-28 at 12:31:13 +0200, Kosyrev Serge wrote:
[...]
>> * A (possible) overhaul of GHC's build system to use Shake instead
>> of Make.
>
> Is there a breakdown of what remains to be done on this front?
Btw, here's the GitHub repo were you can track the progress:
https://github.
On 2015-08-28 at 11:48:08 +0200, Ben Gamari wrote:
[...]
> Hmm, interesting. I'm not sure how realistic it is to make this a
> link-time option, however, considering that we may inline bindings from
> whatever integer package we compile against into the user's program.
>
> Herbert, do you have an
Good news, everyone!
...you may be interested to know this has finally come to fruition (just
in time for HIW):
http://blog.ezyang.com/2015/08/help-us-beta-test-no-reinstall-cabal/
Cheers,
hvr
On 2015-03-23 at 09:45:48 +0100, Simon Peyton Jones wrote:
> Dear Cabal developers
>
> You'll prob
On 2015-09-01 at 08:45:40 +0200, Richard Eisenberg wrote:
> An interesting topic came up over dinner tonight: what if GHC made
> more releases? As an extreme example, we could release a new point
> version every time a bug fix gets merged to the stable branch. This
> may be a terrible idea. But wha
On 2015-09-01 at 13:57:17 +0200, Harry . wrote:
> Proposal: Make Semigroup as a superclass of Monoid
> https://mail.haskell.org/pipermail/libraries/2015-April/025590.html
The plan is to (at the very least) move Data.Semigroups and
Data.List.NonEmpty to base for GHC 7.12
If we have enough time we
On 2015-09-02 at 12:43:57 +0200, Ben Gamari wrote:
[...]
> The question is whether users want more rapid releases. Those working on
> GHC will use their own builds. Most users want something reasonably
> stable (in both the interface sense and the reliability sense) and
> therefore I suspect woul
On 2015-09-02 at 10:00:40 +0200, Matthew Pickering wrote:
> Surely the easiest way here (including for other tooling - ie
> haskell-src-exts) is to create a package which just provides this
> enumeration. GHC, cabal, th, haskell-src-exts and so on then all
> depend on this package rather than creat
On 2015-09-03 at 11:53:40 +0200, Thomas Miedema wrote:
[...]
> In my opinion it's is a waste of our time trying to improve `arc` (it is
> 34000 lines of PHP btw + another 7 LOC for libphutil), when `pull
> requests` are an obvious alternative that most of the Haskell community
> already uses.
On 2015-09-14 at 16:43:44 +0200, Richard Eisenberg wrote:
> Is there an easy way to download (but not compile) all of Hackage? I
> know of the hackager package, but that's about compiling. I just want
> a whole big load of Haskell code to play with. I thought I could find
> a link on Hackage to do
Dear Haskell Community,
In short, it's time to assemble a new Haskell Prime language
committee. Please refer to the CfN at
https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html
for more details.
Cheers,
hvr
--
PGP fingerprint: 427C B69A AC9D 00F2 A43C AF1C BA3C BA3F
On 2015-09-25 at 20:48:52 +0200, Richard Eisenberg wrote:
> I've run into this issue, too. Post a feature request! I can't imagine
> it's too hard to implement.
For the current external CPP we'll probably have to create a temporary
file with the definitions (just like cabal does) to -include (as a
On 2015-09-28 at 04:56:13 +0200, David Feuer wrote:
[...]
> That's an excellent idea, and I think it makes sense to offer it at the
> module level as well as the class level. Just change DEPRECATED to REMOVED
> when it's actually removed. Speaking of such, has the deprecated export
> proposal mad
Hi,
On 2015-10-26 at 08:59:26 +0100, Simon Peyton Jones wrote:
> The GHC wiki says you need Sphinx to build docs,
> https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Tools
> and refers to the Preparation doc for how to install Sphinx
> https://ghc.haskell.org/trac/ghc/wiki/Bui
In the GHC tree:
$ grep haddock packages
utils/haddock- -
ssh://g...@github.com/haskell/haddock.git
says that the upstream repo for Haddock is ssh://...
(there are some comments in the 'packages' file that explain what the
last column me
originally,
http://git.haskell.org/ghc.git/commitdiff/7eb5e29b4a7b6fef55512bc7bf3308e712ca3eba
the import looked like this:
import qualified HsSyn -- hack as we want to reexport the whole module
import HsSyn hiding ((<.>))
so it wasn't redundant back then at least.
> commit da58d1517ce9c5
Hi,
Btw, I also used that annoying pattern in
https://phabricator.haskell.org/D1185
to represent type-signature sections before/after typechecking:
-- | Type-signature operator sections
| TySigSection(LHsType id)
(PostRn id [Name]) -- wildcards
| TySigS
On 2016-01-13 at 16:43:35 +0100, Ben Gamari wrote:
> The GHC Team is very pleased to announce the first release candidate of
> the Glasgow Haskell Compiler 8.0.1 release. Source and binary
> distributions as well as the newly revised users guide can be found at
>
> http://downloads.haskell.org/
On 2016-01-20 at 06:39:32 +0100, Richard Eisenberg wrote:
> I'm sure there's an easy answer to this, but I'm wondering: why is the
> CallStack feature implemented with implicit parameters instead of just
> a magical constraint? Whenever I use this feature, I don't want to
> have to enable -XImplici
On 2016-01-22 at 17:23:18 +0100, Geoffrey Mainland wrote:
> I didn't mean to suggest that DPH should be part of every build, just
> that it should be part of *some* regular build.
>
> If we're willing to do that, then I'm certainly willing to get DPH
> back up and running.
What's the situation wit
On 2016-01-23 at 14:05:56 +0100, Andrey Mokhov wrote:
>> Are there any plans as to how to include it in the GHC tree? Does it
>> ship with all the libraries required to build the build system, will we
>> have a mini-build system to bootstrap it? If I recall correctly, we rely
>> on Cabal sandboxes
On 2016-01-23 at 17:58:12 +0100, Tuncer Ayaz wrote:
[...]
> My suggestion, and what I'd expect, is to make Shake part of GHC's
> included lib, just like process or xhtml.
please don't; the only reason we include process and xhtml because we
*have* to. The less we *have* to bundle, the better.
_
On 2016-02-15 at 04:47:56 +0100, Richard Eisenberg wrote:
> On Feb 14, 2016, at 1:51 PM, Sven Panne wrote:
>>
>> IMHO, the distinction between "during development" and "outside of it" is
>> purely hypothetical.
>
> I find this comment quite interesting, as I see quite a large
> difference betwe
On 2016-02-14 at 19:51:19 +0100, Sven Panne wrote:
[...]
> As stated on the Wiki, stuff in -Wcompat will often be non-actionable,
> so the only option I see if -Wcompat is included in -Wall will be
> -Wno-compat for all my projects.
This depends on what we mean by "actionable". I'm not sure I'd
On 2016-02-15 at 11:33:09 +0100, Boespflug, Mathieu wrote:
[...]
> * include -Wcompat and -Wall, but make it "magic" so that -Wcompat
> never causes a build to fail even when users set -Wall -Werror.
Tbh, I don't like the "magic" part at all. In fact, I currently rely on
`-Wcompat -Werror` trigg
On 2016-02-15 at 12:00:23 +0100, Yuras Shumovich wrote:
[...]
>> - It is possible to have unlifted types about even without
>> -XMagicHash. -XMagicHash is simply a lexer extension, nothing more.
>> By convention, we use the # suffix with unlifted things, but there's
>> no requirement here. Having
On 2016-02-15 at 21:05:29 +0100, Sven Panne wrote:
[...]
>* Given the myriad of warning-related options, It is *extremely* hard to
> figure out which one caused the actual warning in question. The solution to
> this is very easy and done this way in clang/gcc (don't remember which one,
> I'm
On 2016-02-16 at 08:00:49 +0100, Sven Panne wrote:
>> I have renamed it to -Wmissing-pat-syn-signatures.
>>
>
> Hmmm, things are still wildly inconsistent:
>
>* "pat" is spelled "pattern" in other flags.
>
>* We still have both "sigs" and "signatures" as parts of the names.
I simple head-c
On 2016-02-18 at 04:02:24 +0100, Eric Seidel wrote:
> On Wed, Feb 17, 2016, at 08:09, Christopher Allen wrote:
>> I have tried a beginner's Prelude with people. I don't have a lot of data
>> because it was clearly a failure early on so I bailed them out into the
>> usual thing. It's just not worth
On 2016-02-18 at 13:32:59 +0100, Andrey Mokhov wrote:
[...]
> Interesting! In the new Shake-based build system we also need to
> automagically generate .hs files using Alex et al. My first
> implementation was slow but then I realised that it is possible to
> scan the source tree only once and re
On 2016-04-14 at 23:11:26 +0200, Iavor Diatchki wrote:
[...]
> If we were to delay things, we would ship a version of the library that has
> missing functionality *and* we'll break everyone's code on the next
> release.
> If we make the change now, then at least when people fix their TH
> code
On 2016-04-15 at 00:04:05 +0200, Iavor Diatchki wrote:
> Sure, I'd be happy to help whoever needs help---just let me know.
Great... :-)
> The change that one would have to do is: whenever you'd used "InstaceD"
> replace it with "InstanceD Nothing".
I've done a quick grep for InstanceD over the
On 2016-05-12 at 12:47:05 +0200, Ben Gamari wrote:
[...]
> I've pushed the result to the ghc-8.0 branch and have pushed a set of
> new source tarballs to the usual URL. The new release commit is
>
> b594f8191273f4c913bc8413d30fd3061bb577c1
fyi, an easy way to verify you have the intended tar
On 2016-05-13 at 00:40:03 +0200, Edward Z. Yang wrote:
> Currently the commit hooks reject commit messages that look like:
>
> Summary: Signed-off-by: Edward Z. Yang
>
> Unfortunately, if I do a one line commit message with -s, Phabricator
> will automatically reformat my message to have this.
Hello!
In short, the right-associative fixity of (Data.{Monoid,Semigroup}.<>)
subtly conflicts with definitions of (<>) in pretty printing APIs, for
which the left-associative variant is sometimes desirable. This subtle
overloading of (<>) is error-prone, as one has to remember which version
of (<
On 2016-06-07 at 02:58:34 +0200, Dominick Samperi wrote:
> I guess what you are saying is that this policy will prevent packages
> from installing with new versions of ghc until the maintainer has had
> a chance to test the package with the new version, and has updated the
> upper version limit. Th
On 2016-06-09 at 19:43:42 +0200, David Fox wrote:
>> or even worse silent failures where the code behaves
>> subtly wrong or different than expected. Testsuites mitigate this to
>> some degree, but they too are an imperfect solution to this hard
>> problem.
> It seems to me that if you have any t
On 2016-06-13 at 23:44:14 +0200, Ben Gamari wrote:
> Simon Peyton Jones writes:
>> Devs,
>> I want to push to the haddock repo, to fix the build. But I can’t.
>> .git/modules/utils/haddock/ contains
>>
>> [remote "origin"]
>>
>>url = git://git.haskell.org/haddock.git
>>
>> pushurl = s
On 2016-09-28 at 03:51:22 +0200, Richard Eisenberg wrote:
[...]
> Despite agreeing that wikis are sometimes wonky, I thought of a solid
> reason against moving: we lose the Trac integration. A Trac wiki page
> can easily link to tickets and individual comments, and can use
> dynamic features such
Hi *,
I seem to recall this was already suggested in the past, but I can't
seem to find it in the archives. For simplicity I'll restate the idea:
foo :: Int -> Int -> (Int,Int)
foo x y = (bar x, bar y)
where
bar x = x+x
results merely in a name-shadowing warning (for -Wall
Hi,
On 2016-10-04 at 13:12:54 +0200, Yuras Shumovich wrote:
> On Tue, 2016-10-04 at 04:48 -0400, Edward Kmett wrote:
>
>> It makes additions of names to libraries far less brittle. You can
>> add a
>> new export with a mere minor version bump, and many of the situations
>> where
>> that causes bre
$ tar xOf ghc-8.2.0.20170404-src.tar.xz ghc-8.2.0.20170404/GIT_COMMIT_ID ;
echo
d67f0471cd3584c5a548ff30c9023b599b598d3e
On Tue, Apr 4, 2017 at 9:01 AM Alan & Kim Zimmerman
wrote:
> There is no tag in the source tree, which commit has been used?
>
> Alan
>
> On 4 April 2017 at 06:21, Ben Gamar
On Wed, May 17, 2017 at 10:56 AM, Simon Peyton Jones via ghc-devs
wrote:
> That's great news! Faster than GHC 7.8! We should advertise this :-).
However, not everything is back to 7.8 levels when looking at the
time-dimension, e.g. for regex-tdfa-1.2.2 (with reasonably similar
versions of de
On 2017-05-27 at 19:58:11 +0200, Michal Terepeta wrote:
[...]
> I've done an experiment in [1] (to see how much we'd need to actually
> copy) and I really like the result:
> - We can remove one external dependency and git submodule at the
> cost of only 5 new modules in `cmm/Hoopl` (net gain of
Hi Simon,
On 2017-06-09 at 09:50:51 +0200, Simon Peyton Jones via ghc-devs wrote:
[...]
>> Stackage only allows one version of each package
>
> I didn’t know that, but I can see it makes sense. That makes a strong
> case for re-doing it as a new package hoopl2
The limitations of Stackage's des
f genprimcode or similiar)
or the lazy option,
b) simply have those files installed in a place we can easily locate
(again, from a custom Setup.hs)
Does this make any sense; which option do you prefer?
Also, I'd like to know if you can think of reasons why or situations
when the reinsta
Hi!
On 2017-08-03 at 08:41:59 +0200, Ara Adkins wrote:
[...]
> I nevertheless see `stack` as a huge boon for easing adoption of new
> compiler versions (and hence new language features/extensions).
Since I totally disagree about Stack being beneficial to the quick
adoption of new features, woul
On Sat, Aug 19, 2017 at 12:43 AM, Simon Peyton Jones via ghc-devs
wrote:
> | Hmm. Here's a shot in the dark: is home home directory mounted via NFS by
> | any chance?
>
> Direct hit! (for the shot in the dark). Yes it's NFS mounted I think. So
> what?
Then you're another victim of
https://gh
Good idea!
...btw, note that a couple years ago, I set up the little known
http://ghc.haskell.org/ticket/1234
alias... :-)
On Fri, Sep 1, 2017 at 8:26 PM, Ben Gamari wrote:
> Hello everyone,
>
> Earlier today a contributor requested that we have an easier-to-remember URL
> for Trac tickets
Hi,
On Sun, Sep 10, 2017 at 9:24 AM, Harendra Kumar
wrote:
> I could not find a function that repeats a value using a semigroup append. I
> am looking for something like this:
>
> srepeat :: Semigroup a => a -> a
> srepeat x = xs where xs = x <> xs
>
> Is it already available somewhere? Does it m
Hi GHC devs,
A long-standing common problem when testing/dogfooding GHC HEAD is that
at some point during the development cycle more and more packages from
Hackage will run into build failures.
Obviously, constantly nagging upstream maintainers to release quickfixes
for unreleased GHC HEAD snapsh
"Edward Z. Yang" writes:
> Ever wanted to write this?
>
> -- | Forks a thread, but kills it if it has more than 'limit'
> -- bytes resident on the heap.
> forkIOWithSpaceLimit :: IO () -> {- limit -} Int -> IO ThreadId
>
> I have a proposal (and some unpublished experimental patches)
On 2013-05-24 23:52:47 +0200, Austin Seipp wrote:
> The catch is that we don't want to move off of what it's in Debian,
> from what I remember. These are obviously slightly dated versions of
> Trac.
Being the author of the original git plugin[1], I feel the need to make
a few comments:
- The gi
On 2013-07-31 at 03:21:48 +0200, Simon Peyton-Jones wrote:
[...]
> * I have lots of check-out repos. Each contains lots of .git/config files
>because of the multi-repo nature of the GHC build system. It would be
>a pain to have to edit each individually. Maybe you can tell us a sync-a
Hello Richard,
On 2013-08-05 at 11:51:27 +0200, Richard Eisenberg wrote:
[...]
> Do we think such a page is a good idea? As I said, I'm happy to write
> it and maintain it, as well as serve as an email contact to people who
> want to contribute and want help. And, is there someone willing to
> c
Hello GHC devs,
in the current ghc.git's .gitmodules file, the entries look like
,
| [submodule "libraries/binary"]
| path = libraries/binary
| url = http://darcs.haskell.org/libraries/binary.git/
`
I'd like to normalize the urls above to use the
http://darcs.haskell.org/pack
On 2013-08-06 at 05:27:47 +0200, Erik de Castro Lopo wrote:
> Got the error below.
[...]
> remote: trac.db.pool.TimeoutError: Unable to get database connection within 0
> seconds. (TracError: The user erikd requires read _and_ write permissions to
> the database file /home/trac/ghc/db/trac.db a
Hello GHC Devs,
Let me add some details and clarifications to yesterday's
migration completion notice:
On 2013-08-10 at 00:19:53 +0200, Austin Seipp wrote:
> Push access is now restored and Gitolite is in place! This brings some
> nice updates:
> * There's now access to the 'git' protocol for c
On 2013-08-10 at 11:06:06 +0200, Herbert Valerio Riedel wrote:
> And finally, the changes resulting from the new Trac commit-hook
> integration is worth a separate posting of its own to follow shortly.
The new post-receive hook for notifying Trac about new commits has been
updated to use
Hello Malcolm,
On 2013-08-10 at 09:57:34 +0200, Malcolm Wallace wrote:
>> * None of you have shell access to ghc.haskell.org anymore (well,
>> this is a nice update for us administrators :)
> Is ghc.haskell.org the same machine as darcs.haskell.org?
Yes
> I notice that my nightly build of nhc98
Hello Edward,
On 2013-08-13 at 15:39:20 +0200, Edward Z. Yang wrote:
> What happened to the libraries repositories?
They are still there, but only in the /packages directory (as declared
in the 'packages' file in the remotepath columns, see also [1]); you
need to run
>> ./sync-all -r git://ghc
On 2013-08-13 at 14:20:59 +0200, Simon Marlow wrote:
[...]
> I have updated
> http://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git to mention
> this, but it could probably do with more complete docs since the
> standard Trac docs don't take into account our local settings.
> Herbert, coul
Hello Simon,
On 2013-08-15 at 04:26:38 +0200, Simon Peyton-Jones wrote:
> My gut feel is that it's fragile and unexpected to have tickets change
> status based on commit messages. Revisiting the ticket itself can
> remind you
> that the fix is only partial, or
> that there is another related t
Hello GHC Devs,
Hopefully, the new DNS entry for git.haskell.org should be visible for
all of you by the time you read this. This mostly completes the
migration part of the GitolitePlan[1].
With the new hostname, the URLs to use for `sync-all` to fetch via
git://, http://, or ssh:// (ordered by i
Hello Simon,
On 2013-08-20 at 08:48:26 +0200, Simon Peyton-Jones wrote:
> Thanks. Some quick questions
>
> 1. What's the difference between ghc.haskell.org and git.haskell.org?
ghc.haskell.org *currently* points to the same IP address as
git.haskell.org, so it makes only a difference for service
On 2013-08-20 at 09:48:48 +0200, Simon Peyton-Jones wrote:
> | However, in order to facilitate future migrations, git.haskell.org
> | should be used, as then we could relocate git.haskell.org to a different
> | IP without needing to update the URLs in all documents again.
>
> Why? If we only had g
On 2013-08-20 at 13:21:02 +0200, Geoffrey Mainland wrote:
> How about a third hook that disallows commits that include
> whitespace-only changes unless *all* changes are whitespace-only? ;)
The other two validations were about preserving an invariant ("file has
no tabs" & "file has no trailing whi
On 2013-08-22 at 15:35:29 +0200, Ben Lippmeier wrote:
[...]
> I was confused because the ./sync-all script gets most of the repos
> with git:// style URLs, but then switches to http:// style URLs for
> sub modules.
well, that's because the 'sync-all' script is not clever enough to
rewrite the ur
Hello Simon,
On 2013-08-24 at 08:54:20 +0200, GHC wrote:
[...]
> Comment (by simonmar):
>
> @bos: GHC has a `FastMutInt` type for this purpose, which is a 1-element
> mutable unboxed array. I'd be interested to know whether performance
> differs between this and `ForeignPtr`.
>
> source:ghc/c
Hello Gabor,
On 2013-08-22 at 22:51:31 +0200, g...@git.haskell.org wrote:
> Link :
> http://ghc.haskell.org/trac/ghc/changeset/cbe3dba89c085f7556fe32126381dac68d93dd8b/ghc
> commit cbe3dba89c085f7556fe32126381dac68d93dd8b
> Author: Gabor Greif
> Date: Mon Aug 19 11:31:15 2013 +0200
>
>
On 2013-08-26 at 10:56:15 +0200, Gregory Collins wrote:
> On Sun, Aug 25, 2013 at 9:47 PM, Simon Marlow wrote:
>> On 25/08/13 20:16, Jan Stolarek wrote:
>>> We really want people to use the new primops, not the wrappers
>>> We do? Could you justify why we want to people to use primops?
>>>
>>
I've compared what versions current GHC HEAD uses w/ vs. what's
currently available on Hackage (see below);
So currently, the following packages have newer versions available on
hackage than are used in GHC HEAD:
- binary
- containers
- primitive
- time
- vector
In order to clarify a point
Hello Simon,
On 2013-08-28 at 10:14:36 +0200, Simon Peyton-Jones wrote:
> With Gitolite, the Trac tickets now get messages like this:
[...]
> I liked the old version:
> the author is more explicit
> the modified files are listed
> if the patch is small you see it all
>
> Might it be
Hello GHC Devs,
Which of the language extensions listed in `expectedGhcOnlyExtensions` in
http://ghc.haskell.org/trac/ghc/browser/testsuite/tests/driver/T4437.hs#L33
are deemed ready for public consumption in GHC 7.8.1, and can be
registered with upstream Cabal now (maybe even for the upcoming
On 2013-09-03 at 23:15:43 +0200, Ian Lynagh wrote:
[...]
> I'm afraid I can't even remember what RelaxedLayout does OTTOMH.
fwiw, here's the commit that introduced it:
http://git.haskell.org/?p=ghc.git;a=commitdiff;h=9a82b1ffa35fa4c3927c66a1037a37d436cf6aac
...and moreover, you disabled it by
Hello Nicolas,
On 2013-09-08 at 09:41:04 +0200, Nicolas Frisby wrote:
> I just merged in my -fdicts-strict work, so I was deleting the old branch…
> but it's rejected for some reason.
>
> $ git push origin --delete dicts-strict
> remote: performing tab-check...
> remote: + refs/heads/dicts-strict
Hello GHC devs,
...as the topic came up in #ghc, what's the current rationale for keeping
HUGS-specific code sprinkled throughout GHC boot libraries?
I quick tally in GHC's source tree via
find -type f -iname '*.*hs' | xargs grep '#if.*HUGS' | cut -f1-3 -d/ | uniq -c
results in
1 ./lib
Hello Geoffrey,
On 2013-09-11 at 22:29:04 +0200, Geoffrey Mainland wrote:
[...]
> Is there any chance we could get the wip namespace up and running soon?
Sure, I've enabled it right now (and we can change the "wip/"
branch-prefix lateron should we come up with a better naming); there's
only the
Hi,
On 2013-09-15 at 09:06:13 +0200, Austin Seipp wrote:
> I'm voting we delete it. In fact: I say if nobody pipes up and is
> *committed* to maintaining it, we delete it, oh, two weeks. That's
> standard library-proposal timeframe. (And I do mean maintenance - not
> "drop barely enough work to ge
Hello Jan,
On 2013-09-24 at 20:47:31 +0200, Jan Stolarek wrote:
>> Your patches are based on an outdated version of the library.
> That's really surprising - I based them on code available at
> http://code.haskell.org/primitive,
> which I believe was version 0.5.0.1. Was there anything newer?
On 2013-09-25 at 05:50:23 +0200, Bryan O'Sullivan wrote:
> On Tue, Sep 24, 2013 at 6:17 PM, Herbert Valerio Riedel wrote:
>
>> However, I've tried integrating the new vector/primitive versions
>> released into the GHC build (after patching up the DPH libs), b
On 2013-09-25 at 02:40:51 +0200, Geoffrey Mainland wrote:
[...]
>> However, I've tried integrating the new vector/primitive versions
>> released into the GHC build (after patching up the DPH libs), but I get
>> Core lint errors:
>>
>> http://lpaste.net/93354
>>
>> any idea what's going on here?
Hello Jan,
On 2013-09-25 at 08:26:15 +0200, Jan Stolarek wrote:
>> However, I've tried integrating the new vector/primitive versions
>> released into the GHC build (after patching up the DPH libs), but I get
>> Core lint errors:
>>
>> http://lpaste.net/93354
>>
>> any idea what's going on here?
Fyi, I've been able to reproduce this failure on GHC 7.6.3 as well, and
filed a ticket at
http://ghc.haskell.org/trac/ghc/ticket/8355
On 2013-09-25 at 09:24:22 +0200, Herbert Valerio Riedel wrote:
> Hello Jan,
>
> On 2013-09-25 at 08:26:15 +0200, Jan Stolarek wrote:
>>&
On 2013-09-25 at 04:52:33 +0200, Kazu Yamamoto (山本和彦) wrote:
> It seems to me that "newSession" does not exist. But it is used in
> comments and error messages.
fwiw, it seems to have been removed back in 2008:
http://git.haskell.org/ghc.git/commitdiff/1c7d0ac0a433f85effeb5e9cfb6b303c26b201d1
On 2013-09-30 at 08:26:10 +0200, Bryan O'Sullivan wrote:
[...]
> Most of the breakage could be fixed by loosening the dependencies on the
> template-haskell and primitive packages, and here are the rest.
Btw/fyi, as one of the new killer features of Hackage 2, incorrect
build-deps were supposed
On 2013-10-01 at 12:19:16 +0200, Simon Marlow wrote:
> That would help, but since this regression is quite recent I'm hoping
> that someone will know what caused it. Did anyone notice when these
> failures first appeared? It is certainly not the patches I'm working
> on, because I see the same fa
Hello *,
The Trac instances at ghc.haskell.org have been upgraded to the current
stable Trac 1.0.1 release in order to alleviate some technical issues
with the aging Trac 0.12.x line.
Ideally, you shouldn't notice any regressions; however, as a side-effect
Trac 1.0.x has a slightly different look
On 2013-10-12 at 00:07:44 +0200, Gabor Greif wrote:
> Herbert,
>
> I guess you have excluded 0.4.x with these changes. Do you have 0.5.x
> already installed?
Yes, that excludes 0.4.*, as I assumed that the DPH libs need only to be
built with the GHC source tree's array package (which has been bump
Hello Bryan,
On 2013-10-11 at 20:27:08 +0200, Bryan O'Sullivan wrote:
[...]
> For packages that are listed in blue, the versions that are breaking are
> the latest available. I've CCed the authors of said packages on this email.
> Folks, please fix your stuff!
btw, is there somewhere some wiki-
Hello Simon!
On 2013-10-11 at 12:59:07 +0200, Simon Marlow wrote:
[...]
> This is great. With a bit of extra tool support for this we could
> actually do without submodules and go back to individual
> repos. Checking out a GHC revision in the past could consist of
> querying your ghc-complete r
Hello Bryan,
Thanks for catching this!
(see also comment below)
[...]
> commit b092e35f4c99bfab12247e93c7fa478de638276a
> Author: Bryan O'Sullivan
> Date: Sat Oct 12 16:45:50 2013 -0700
>
> Fix assumption that RLIM_INFINITY is a simple number
>
> On MacOS X, it is defined as "(((
On 2013-10-14 at 06:07:01 +0200, Bryan O'Sullivan wrote:
[...]
> You'll want to take a look at what hsc2hs actually does here to really
> understand :-)
>
> In short, a constant C-level expression is fine if used in a #const
> construct, regardless of it containing embedded casts and whatnot.
th
Hello Simon,
On 2013-10-15 at 14:45:05 +0200, Simon Marlow wrote:
[...]
> If we can get the tooling right I would probably have no objections to
> submodules. Right now it's a bit of a pain though.
>
> - extra steps in the workflow for modifying a library (git checkout
>master, etc.)
Ok,
201 - 300 of 426 matches
Mail list logo
