Re: HEADS UP: Final call for 7.10.2 is soon
There have been some requests for a Cabal library release for 7.10.2. I remember something about truncate directories/symbol names being an issue. I'm CC:ing the Cabal mailing list for comments. On Wed, Jun 3, 2015 at 3:40 PM, Sergei Meshveliani mech...@botik.ru wrote: Please, consider my recent bug report overlapping instances in 7.10.1 (see my resent email to this list). -- Sergei On Tue, 2015-06-02 at 16:31 -0500, Austin Seipp wrote: Hi *, I've just finished merging all the latest patches for GHC 7.10.2 into the STABLE branch. All in all, we've fixed a lot of bugs (over 80 tickets closed)! So, we'll probably be doing a 7.10.2 release here in a few weeks. The tentative plan was around the 14th, although it's not set in stone. (At worst, it would be pushed from the 14th to the 21st). With that in mind, if I could quickly direct your attention to the GHC bug tracker and the status page[1] - it would be really helpful if you check if the things you want are fixed! Specifically, if you want something fixed for the 7.10.2 release: - Make sure there is a ticket. It really needs to exist or we'll just forget! - If your bug is critical, please explain why! We really want to kill showstoppers ASAP, because bugs are much cheaper to fix early. If that's the case we can bump the priority if it's necessary to make things clear. - Set the milestone to 7.10.2. It'll automatically appear on the status page. That should be it - we'll be monitoring the status page regularly to keep track of new things. The current bug list is pretty small - we may move some of them out, or fix several more. So just try to let us know. As a sidenote, I'm quite happy with this release - it's fixed dozens of tricky bugs, improved some nasty corner cases in compiler performance, and overall seems like it will be high quality. Thanks to everyone who submitted patches! I'll send out another email next week as another reminder. [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.2 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - problem with latest cabal-install
Try cabal install --allow-newer=base -j3 cabal-install Once GHC 7.10 is out we might make another Cabal 1.20 release to bump the upper bound on the base dependency if 1.20 is indeed compatible with the latest base. On Thu, Jan 1, 2015 at 12:08 PM, George Colpitts george.colpi...@gmail.com wrote: $ cabal update Downloading the latest package list from hackage.haskell.org Note: *there is a new version of cabal-install available.* To upgrade, run: cabal install cabal-install bash-3.2$ *cabal install -j3 cabal-install * *...* *Resolving dependencies...cabal: Could not resolve dependencies:* trying: cabal-install-1.20.0.6 (user goal) trying: base-4.8.0.0/installed-779... (dependency of cabal-install-1.20.0.6) next goal: process (dependency of cabal-install-1.20.0.6) rejecting: process-1.2.1.0/installed-2db... (conflict: unix==2.7.1.0, process = unix==2.7.1.0/installed-4ae...) trying: process-1.2.1.0 next goal: directory (dependency of cabal-install-1.20.0.6) rejecting: directory-1.2.1.1/installed-b08... (conflict: directory = time==1.5.0.1/installed-c23..., cabal-install = time=1.1 1.5) rejecting: directory-1.2.1.0 (conflict: base==4.8.0.0/installed-779..., directory = base=4.5 4.8) rejecting: directory-1.2.0.1, 1.2.0.0 (conflict: base==4.8.0.0/installed-779..., directory = base=4.2 4.7) rejecting: directory-1.1.0.2 (conflict: base==4.8.0.0/installed-779..., directory = base=4.2 4.6) rejecting: directory-1.1.0.1 (conflict: base==4.8.0.0/installed-779..., directory = base=4.2 4.5) rejecting: directory-1.1.0.0 (conflict: base==4.8.0.0/installed-779..., directory = base=4.2 4.4) rejecting: directory-1.0.1.2, 1.0.1.1, 1.0.1.0, 1.0.0.3, 1.0.0.0 (conflict: process = directory=1.1 1.3) Dependency tree exhaustively searched. ___ ghc-devs mailing list ghc-d...@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Permitting trailing commas for record syntax ADT declarations
That would be nice if we had a clean slate, but I don't people are going to change their whole import lists now. Adding a comma at the end is less disruptive. On Fri, Sep 26, 2014 at 11:06 PM, John Wiegley jo...@newartisans.com wrote: Richard Eisenberg e...@cis.upenn.edu writes: What if we just stopped requiring commas in import/export lists? As far as I can tell, they're not necessary for proper parsing. +1 John ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Permitting trailing commas for record syntax ADT declarations
I don't think that's necessarily is good style. I don't think we want two different ways of doing import lists. The original proposal was to address a quite small but important engineer issue: without allow *one* trailing comma your version control history gets messed up, because the wrong person gets blamed for a line of code. The standard programming language way of solving that problem is to allow a trailing comma. On Fri, Sep 26, 2014 at 11:16 PM, Brandon Allbery allber...@gmail.com wrote: On Fri, Sep 26, 2014 at 5:12 PM, Johan Tibell johan.tib...@gmail.com wrote: That would be nice if we had a clean slate, but I don't people are going to change their whole import lists now. I read the proposal as making all commas optional, not as requiring them to not be present. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 'import ccall unsafe' and parallelism
Hi! On Thu, Aug 14, 2014 at 5:54 PM, Christian Höner zu Siederdissen choe...@tbi.univie.ac.at wrote: However, due to the way ghc handles unsafe imports, namely block everything else whenever 'cfun' is called, I happen to have only one active 'go'. Lets assume 'cfun' is cheap and would suffer from 'ccall safe' more than I'd be willing to pay. Calls to unsafe functions do not block everything! Other Haskell threads can continue running on other capabilities (make sure you run your program with +RTS -N). However, make sure that the C function itself never blocks, or it might deadlock your program. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overlapping and incoherent instances
On Wed, Jul 30, 2014 at 2:50 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 30 July 2014 22:07, Andreas Abel andreas.a...@ifi.lmu.de wrote: I am a bit surprised by the distinction you outline below. This is maybe because I am native German, not English. The German equivalent of overlap, überschneiden/überlappen, is used exclusively in a symmetrical fashion. It's like in English, if I say our interests overlap, then it is pointless to ask whether my interest are overlapping yours or are overlapped by yours. I want to alert you to the fact that non-native English speaker might have little understanding for a distinction between OVERLAPPING and OVERLAPPABLE. Let's try to guess what it meant: Given A) instance Bla Char B) instance Bla a = Bla [a] C) instance Bla String you will in context A,B write C as OVERLAPPING, and in context A,C write B as OVERLAPPABLE? IIUC, B will be OVERLAPPABLE (you can overlap this) and C will be OVERLAPPING (I'm overlapping an existing one) whereas C will be plain. Apologies if this question doesn't make sense. Can we really talk about overlapping, given that instances can be written in different modules, moved between modules, or removed? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overlapping and incoherent instances
On Tue, Jul 29, 2014 at 11:50 AM, Herbert Valerio Riedel h...@gnu.org wrote:
On 2014-07-29 at 11:29:45 +0200, Niklas Hambüchen wrote:
instance {-# OVERLAPPABLE #-} Show a = Show [a] where …
Is the syntax somewhat flexible in where the pragma can be placed?
For example, some might prefer
{-# OVERLAPPING #-}
instance Show [Char] where …
This variant may also be more convenient in cases where you need to
CPP-guard that pragma, as it's on a separate line.
Agreed, and if we remove the old pragma (even with a deprecation
cycle) you'll see quite a few of those as many library authors try to
have their libraries compile with the last 3 major GHC versions.
P.S. For e.g. INLINABLE we require that you mention the function name
next to the pragma (which means that you can e.g. put the pragma after
the declaration). What's the rationale to not require
{-# OVERLAPPING Show [Char] #-}
here? Perhaps it's too annoying to have to repeat the types?
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Overlapping and incoherent instances
On Tue, Jul 29, 2014 at 12:37 PM, Daniel Trstenjak
daniel.trsten...@gmail.com wrote:
On Tue, Jul 29, 2014 at 12:02:19PM +0200, Johan Tibell wrote:
What's the rationale to not require
{-# OVERLAPPING Show [Char] #-}
here? Perhaps it's too annoying to have to repeat the types?
This one might be written at the top of the file, so it would be easier
to overlook it, than having it directly at the instance declaration,
which seems to be one of the major points for OVERLAPPING and OVERLAPPABLE.
The same could be said for e.g. INLINE. The extra flexibility is nice
to have (e.g. because you can opt to put the pragma after the
declaration, to de-emphasize it.)
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8.3 release
I would say sooner. Here are still unmerged things that I think we could merge before (i.e. easy to merge): https://ghc.haskell.org/trac/ghc/ticket/9001 https://ghc.haskell.org/trac/ghc/ticket/9078 https://ghc.haskell.org/trac/ghc/ticket/8475 https://ghc.haskell.org/trac/ghc/ticket/8783 https://ghc.haskell.org/trac/ghc/ticket/9068 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: include a cabal-install executable in future GHC releases
Thanks. Between you and Mikhail we got the Windows side covered. :) On Sun, May 4, 2014 at 11:13 AM, Niklas Larsson metanik...@gmail.comwrote: Hi! I put a Windows build here: https://www.dropbox.com/s/at7wc1dh0lfr7lc/cabal.exe.zip Niklas 2014-05-04 2:24 GMT+02:00 Johan Tibell johan.tib...@gmail.com: I just uploaded 1.20.0.1 so there's only an OS X binary so far. I'm waiting for someone to send me a Windows one. On Sun, May 4, 2014 at 2:06 AM, Ashley Yakeley ash...@semantic.orgwrote: I couldn't find them, and they're not listed at http://www.haskell.org/cabal/download.html (except OS X), or at http://www.haskell.org/haskellwiki/Cabal-Install, or at http://hackage.haskell.org/package/cabal-install. -- Ashley On 2014-05-03 17:00, Carter Schonwald wrote: I think there's now hosted official cabal install binaries online. I'm Afk but they should be a short google away. Should be linked more prominently though On Saturday, May 3, 2014, Ashley Yakeley ash...@semantic.org mailto: ash...@semantic.org wrote: So I want to install GHC + cabal on a new system, building cabal packages with profiling and documentation. Here's what I have to do: 1. Download, unpack and install GHC. 2. Download and unpack cabal-install, and run bootstrap.sh. As part of the bootstrap, it will download and build a bunch of packages. 3. Delete the downloaded packages (rm -rf ~/.ghc/*) because they were built without profiling or documentation. 4. Call cabal update to get a default .cabal/config file. 5. Edit .cabal/config to switch on library-profiling, executable-profiling, and documentation. 6. Build my stuff. This would be much simplified if binary versions of cabal-install were available. (It would be even simpler if they were just included in the GHC builds -- I could eliminate 2 3.) -- Ashley Yakeley ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: include a cabal-install executable in future GHC releases
I just uploaded 1.20.0.1 so there's only an OS X binary so far. I'm waiting for someone to send me a Windows one. On Sun, May 4, 2014 at 2:06 AM, Ashley Yakeley ash...@semantic.org wrote: I couldn't find them, and they're not listed at http://www.haskell.org/cabal/download.html (except OS X), or at http://www.haskell.org/haskellwiki/Cabal-Install, or at http://hackage.haskell.org/package/cabal-install. -- Ashley On 2014-05-03 17:00, Carter Schonwald wrote: I think there's now hosted official cabal install binaries online. I'm Afk but they should be a short google away. Should be linked more prominently though On Saturday, May 3, 2014, Ashley Yakeley ash...@semantic.org mailto: ash...@semantic.org wrote: So I want to install GHC + cabal on a new system, building cabal packages with profiling and documentation. Here's what I have to do: 1. Download, unpack and install GHC. 2. Download and unpack cabal-install, and run bootstrap.sh. As part of the bootstrap, it will download and build a bunch of packages. 3. Delete the downloaded packages (rm -rf ~/.ghc/*) because they were built without profiling or documentation. 4. Call cabal update to get a default .cabal/config file. 5. Edit .cabal/config to switch on library-profiling, executable-profiling, and documentation. 6. Build my stuff. This would be much simplified if binary versions of cabal-install were available. (It would be even simpler if they were just included in the GHC builds -- I could eliminate 2 3.) -- Ashley Yakeley ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Removing -fext-core
+1 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Buildbots
We now have a (Linux) travis-ci buildbot so we should be able to use whatever script that buildbot runs. To make a full validate you simply check out the source repos and run: CPUS=N sh validate (CPUS=N is optional of course.) On Tue, Apr 1, 2014 at 9:42 AM, harry volderm...@hotmail.com wrote: It having been suggested that a buildbot for Windows may be needed, and it being possible that I may receive permission from management for setting one up in my department's server room, I set about attempting to discover what this actually entails. A Google search led me to https://ghc.haskell.org/trac/ghc/wiki/BuildBot, which tells me that Buildbot is currently down, and we are working on a replacement. See Builder for more details. If I follow the 'down' link , I get to the GHC status April 2010 page, which says that buildbot has been abandoned, suggesting that the page should be deleted. Could someone confirm before I go ahead and delete it? The Builder page has clear instructions on how to set up a build slave, and a link to the build results. The build results contains an assortment of dud links and builds from August and earlier. What is the current state of automated builds? -- View this message in context: http://haskell.1045720.n5.nabble.com/Buildbots-tp5746770.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Buildbots
On Tue, Apr 1, 2014 at 10:07 AM, harry volderm...@hotmail.com wrote: Johan Tibell-2 wrote We now have a (Linux) travis-ci buildbot so we should be able to use whatever script that buildbot runs. Does this mean that the Builder page is also no longer relevant? And if so, how could a Windows buildbot be set up? I don't know whether the old buildbot is still in use. I haven't seen any emails from it in quite a while. I'll wait for some other people on the list to chime in. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Buildbots
On Tue, Apr 1, 2014 at 12:46 PM, Joachim Breitner m...@joachim-breitner.dewrote: Hi, Am Dienstag, den 01.04.2014, 10:25 + schrieb Simon Peyton Jones: Joachim Breitner has set up Travis-CI. (I don't know exactly what that is, but it sounds useful.) Travis is a free cloud service that runs arbitrary tests (in our case, a stripped version of validate) upon pushes to git repositories on github. I set it up to validate our master, so we get a nice history of successes and failures on https://travis-ci.org/nomeata/ghc-complete/builds and I get mails when things fail; that is when I send hopefully polite enough mails to ghc-dev, asking people to fix their commits. (Unless I broke it myself; then I silently fix it and hide.) If the false positive rate is low, feel free to automatically have the emails sent to ghc-devs@. We want to know when we broke stuff ASAP. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Haskell Support on Windows
On Mon, Mar 31, 2014 at 2:57 PM, Niklas Larsson metanik...@gmail.comwrote: Seems to me that a less pessimistic solution would be to set up a windows buildbot. +1 I believe there's at least one investment bank that uses Haskell on Windows. Perhaps they could set one up. ;) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: include a cabal-install executable in future GHC releases
On Wed, Jan 22, 2014 at 12:57 AM, Herbert Valerio Riedel h...@gnu.orgwrote: On 2014-01-21 at 20:22:48 +0100, Ganesh Sittampalam wrote: I feel this blurs the roles of GHC and the Platform. IMO, that's a weak argument, as the roles are already blurred: GHC comes with `haddock`, `hp2ps`, and `hpc` executables which could be provided by the HP instead. Moreover, GHC ships with a set of base libraries (which, and thus effectively GHC forces 20 or so packages (fixed to specific package versions) into the HP and takes away authority from the HP release process. But now the difficult to explain thing is that GHC also bundles the library part of CABAL but deliberately leaves out CABAL's frontend tool `cabal-install` only to justify the existence of the HP a bit more? :-) Cabal is part of GHC's build process and GHC uses data types from Cabal. That's why it's there. It's not because we want Cabal to be included (just like we don't want to ship those libs.) These are technical limitations. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: include a cabal-install executable in future GHC releases
We could offer OS X and Linux binaries in addition to the Windows binaries already downloaded on the cabal home page (http://www.haskell.org/cabal/) if someone could commit to building them. Aside: Right now building the Windows binaries is a very ad-hoc process (I email Mikhail who has a Windows machine and ask him to build one). I'm not very keen to make the process even slower, given that that will mean I will make fewer cabal releases. Ideally the binaries could be produced on a build bot. The very least we should have the Makefile in the cabal repo being able to create the binary in a reproducible manner. -- Johan On Tue, Jan 21, 2014 at 11:22 AM, Ganesh Sittampalam gan...@earth.liwrote: I feel this blurs the roles of GHC and the Platform. Can't the cabal-install that comes with the Platform can be used with a later GHC installation? If that's correct, then the only use case that this proposal covers is someone who wants to use a bleeding edge GHC and no other version on a new machine. A separate binary distribution of cabal-install should be more than adequate for that and it avoids coupling GHC to other things. So a weak -1. On 20/01/2014 00:02, Carter Schonwald wrote: Hey everyone, I'd like to propose that GHC releases 7.8.1 onwards include a cabal-install (aka cabal) executable, but not include the library deps of cabal-install that aren't already distributed with ghc.(unless ghc should have those deps baked in, which theres very very good reasons not to do.). currently if someone wants just a basic haskell install of the freshest ghc they have to install a ghc bindist, then do a boostrap build of cabal-install by hand (if they want to actually get anything done :) ). This is not a human friendly situation for folks who are new to haskell tooling, but want to try out haskell dev on a server style vm or the like! point being: It'd be great for haskell usability (and egads amounts of config time, even by seasoned users) the ghc bindists / installers included a cabal-install binary thoughts? -Carter ___ Libraries mailing list librar...@haskell.org http://www.haskell.org/mailman/listinfo/libraries ___ Libraries mailing list librar...@haskell.org http://www.haskell.org/mailman/listinfo/libraries ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Enabling TypeHoles by default
I can make another cabal release if needed, if someone submits a pull request with the right fix (i.e. add TypedHoles with TypeHoles as a synonym.) On Tue, Jan 14, 2014 at 5:33 PM, Austin Seipp aus...@well-typed.com wrote: At the very least, Type(d)Holes would never appear explicitly since it would be enabled by default. But it might be turned off (but I don't know who would do that for the most part.) Cabal at least might still need an update. In any case, Herbert basically summed it up: the time window is kind of close, and we would need to re-release/redeploy a few things most likely. I really think it mostly depends on the Cabal team and what their priorities are. I've CC'd Duncan and Johan for their opinions. On Tue, Jan 14, 2014 at 10:27 AM, Herbert Valerio Riedel h...@gnu.org wrote: Hi, On 2014-01-14 at 17:14:51 +0100, David Luposchainsky wrote: On 14.01.2014 17:07, Austin Seipp wrote: We probably won't change the name right now however. It's already been put into Cabal (as a recognized extension,) so the name has propagated a slight bit. We can however give it a new name and deprecate the old -XTypeHoles in the future. Or, we could change it, but I'm afraid it's probably a bit too late in the cycle for other devs to change. Removing a name later on is more time-consuming, with or without deprecation. People get used to the wrong name and stop caring, but I can already picture the type holes are really typed holes discussions on IRC. I'm strongly in favour of introducing the new name (and the deprecation for the synonym) as early as possible. This change should not be very extensive anyway, so why not slip it in? Well, as Austin hinted at, this would also require a Cabal-1.18.x 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 differently, somebody has to care enough to invest some time and pull this through :-) Cheers, hvr -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Enabling TypeHoles by default
Stupid question: is it really only better error messages? What about being allowed to use _ on the RHS? On Tue, Jan 14, 2014 at 6:23 PM, Joachim Breitner m...@joachim-breitner.dewrote: Hi, heh, I wanted to throw in the same argument: If its just more elaborate error messages, why do we need a flag for it? So count that as +1 from me. Greetings, Joachim Am Dienstag, den 14.01.2014, 11:12 -0600 schrieb Austin Seipp: I'm actually more in favor of Richard's proposal of just removing the flag to be honest, now that he mentioned it. And it's not like it's much more code. In any case, as Duncan informed me we'll have a Cabal release anyway, so I'll work on sorting this out and enabling it. On Tue, Jan 14, 2014 at 10:54 AM, Duncan Coutts dun...@well-typed.com wrote: On Tue, 2014-01-14 at 17:44 +0100, Johan Tibell wrote: I can make another cabal release if needed, if someone submits a pull request with the right fix (i.e. add TypedHoles with TypeHoles as a synonym.) Thanks Johan, or I'm happy to do it. Duncan On Tue, Jan 14, 2014 at 5:33 PM, Austin Seipp aus...@well-typed.com wrote: At the very least, Type(d)Holes would never appear explicitly since it would be enabled by default. But it might be turned off (but I don't know who would do that for the most part.) Cabal at least might still need an update. In any case, Herbert basically summed it up: the time window is kind of close, and we would need to re-release/redeploy a few things most likely. I really think it mostly depends on the Cabal team and what their priorities are. I've CC'd Duncan and Johan for their opinions. On Tue, Jan 14, 2014 at 10:27 AM, Herbert Valerio Riedel h...@gnu.org wrote: Hi, On 2014-01-14 at 17:14:51 +0100, David Luposchainsky wrote: On 14.01.2014 17:07, Austin Seipp wrote: We probably won't change the name right now however. It's already been put into Cabal (as a recognized extension,) so the name has propagated a slight bit. We can however give it a new name and deprecate the old -XTypeHoles in the future. Or, we could change it, but I'm afraid it's probably a bit too late in the cycle for other devs to change. Removing a name later on is more time-consuming, with or without deprecation. People get used to the wrong name and stop caring, but I can already picture the type holes are really typed holes discussions on IRC. I'm strongly in favour of introducing the new name (and the deprecation for the synonym) as early as possible. This change should not be very extensive anyway, so why not slip it in? Well, as Austin hinted at, this would also require a Cabal-1.18.x 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 differently, somebody has to care enough to invest some time and pull this through :-) Cheers, hvr -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ -- Duncan Coutts, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Giving function a larger arity
And plan 2 doesn't require a magic data type. :)
On Tue, Nov 12, 2013 at 9:36 AM, Simon Peyton-Jones
simo...@microsoft.comwrote:
There is a difference between plan A and B. For example, if
f :: (OneShot a - b) - [a] - [b]
then EVERY function passed to f would have to be one-shot (Plan A). But
under plan B you could have two calls
…f (\x. blah)….. f (\y{-#ONESHOT#-}. blah2)….
and only the second would be a one-shot lambda.
So if anything plan B seems more flexible.
Simon
*From:* John Lato [mailto:jwl...@gmail.com]
*Sent:* 12 November 2013 00:12
*To:* Simon Peyton-Jones
*Cc:* glasgow-haskell-users@haskell.org; Akio Takano
*Subject:* Re: Giving function a larger arity
Yes, that's what I meant. I was thinking that from an implementation
perspective, it would be nice if all the one-shot hacks were in a single
place, and if plan A facilitated that it would be a good reason to support
that approach. But I suppose checking an annotation is no harder than
checking a type, so it's probably irrelevant.
On Mon, Nov 11, 2013 at 3:29 PM, Simon Peyton-Jones simo...@microsoft.com
wrote:
Well, Plan A is indeed an extended version of the ”state hack”. Instead
of just (State# RealWorld#) being magically considered one-shot, we’d also
add (OneShot t).
Simon
*From:* John Lato [mailto:jwl...@gmail.com]
*Sent:* 11 November 2013 17:29
*To:* Simon Peyton-Jones
*Cc:* glasgow-haskell-users@haskell.org; Akio Takano
*Subject:* RE: Giving function a larger arity
Originally I thought Plan B would make more sense, but if Plan A were
implemented could this one-shot type annotation be unified with the state
hack? I'm envisioning something like RULES, where if the type matches ghc
knows it's a one-shot lambda.
I think it would be better to not do any analysis and leave this
completely up to the user. My intention is to get a mechanism to tell ghc
it's okay to recompute something in a lambda, essentially a manual state
hack. I seem to recall wanting this, but I don't remember the exact use
case. It's possible it was one-shot anyway.
John L.
On Nov 11, 2013 5:12 AM, Simon Peyton-Jones simo...@microsoft.com
wrote:
Strangely enough I’ve been thinking about eta expansion in the last day
or two. It’s one of GHC’s more delicate corners, because
1. There can be big performance boosts
2. If you push a redex inside a lambda
But as you point out (2) may be arbitrarily bad unless you know the lambda
is called at most once (is “one-shot”).
There is really no good way to declare a lambda to be one-shot right now.
As you discovered, full laziness tends to defeat your attempts to do so!
(A workaround is to switch off full laziness, but that doesn’t feel right.)
What is a more general solution? I can think of two.
A. Declare one-shot-ness in the type. Something like this:
newtype OneShot a = OS a
newtype Builder = Builder (OneShot (Ptr ()) - IO (Ptr ()))
plus telling GHC that anything with a OneShot type is a
one-shot lambda.
B. Declaring one-shot-ness in the terms. Something like
..Builder (\x {-# ONESHOT #-} - blah)…
That would declare this particular lambda to be one-shot,
but not any other.
Notes
· Plan A would require a bit of fiddling to move your values in
and out of the OneShot type. And it’d make the terms a bit bigger at
compile time.
· Plan B is more explicit all the use sites.
· Both plans would be vulnerable to user error. I could imagine
and analysis that would guarantee that you met the one-shot claim; but it
would necessarily be quite conservative. That might or might not be OK
· GHC already embodies a version of (A): the “state hack” means
that a lambda whose binder is a state token (State# RealWorld#) is treated
as one-shot. We have many bug reports describing when this hack makes
things bad, but it is such a huge win for more programs that it is on by
default.(Your “rebuild” idea might work better with (State# Realorld#
- Builder) rather than (() - Builder) for that reason.)
Simon
*From:* Glasgow-haskell-users [mailto:
glasgow-haskell-users-boun...@haskell.org] *On Behalf Of *Akio Takano
*Sent:* 11 November 2013 09:19
*To:* glasgow-haskell-users@haskell.org
*Subject:* Giving function a larger arity
Hi,
I've been trying to get a certain type of programs compiled into efficient
code, but I haven't been able to find a good way to do it, so I'm asking
for help.
Specifically, it involves a library that defines a newtype whose
representation is a function. Attached Lib.hs is an example of such a
library. It defines a newtype (Builder), and functions (fromInt, mappend)
that deal with it.
In user code I want to write a (often-recursive) function that produces a
value of the newtype (the 'upto' function in arity.hs is an example). The
Re: love for hpc?
Aside: cabal supports hpc and puts the various files (e.g. .tix) in separate directories to avoid problems like these. On Thu, Nov 7, 2013 at 8:55 AM, Roman Cheplyaka r...@ro-che.info wrote: So Evan's prediction was accurate ;-) * Carter Schonwald carter.schonw...@gmail.com [2013-11-07 00:29:24-0500] Evan, if you want to get involved in working on HPC, go for it! theres many many pieces of ghc that need more proactive ownership. i should probably use HPC a bit as i start getting my numerical libs out, and i'm sure future me will appreciate current you working on making it better -Carter On Thu, Nov 7, 2013 at 12:03 AM, Evan Laforge qdun...@gmail.com wrote: Is anyone out there using HPC? It seems like it was gotten into a more or less working if not ideal state, and then abandoned. Things I've noticed lately: The GHC runtime just quits on the spot if there's already a tix file. This bit me when I was parallelizing tests. It's also completely unsafe when run concurrently, mostly it just overwrites the file, sometimes it quits. Sure to cause headaches for someone trying to parallelize tests. You can't change the name of the output tix file, so I worked around by hardlinking the binary to a bunch of new ones, and then doing 'hpc sum' on the results. The hpc command is super slow. It might have to do with it doing its parsing with Prelude's 'read', and it certainly doesn't help the error msgs. And the whole thing is generally minimally documented. I can already predict the answer will be yes, HPC could use some love, roll up your sleeves and welcome! It does look like it could be improved a lot with just a bit of effort, but that would be a yak too far for me, at the moment. I'm presently just curious if anyone else out there is using it, and if they feel like it could do with a bit of polishing. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 7.8 Release Update
Is it OK if I release Cabal-1.18.0.1 on Monday if we want it to ship with GHC 7.8? 1.18.0.1 is a tiny bugfix release on top of 1.18.0. On Mon, Sep 9, 2013 at 8:44 AM, Simon Peyton-Jones simo...@microsoft.com wrote: Yes I will try to review it this week. (This is the first time I've had access to the code.) Simon | -Original Message- | From: Austin Seipp [mailto:ase...@pobox.com] | Sent: 09 September 2013 16:25 | To: Trevor Elliott | Cc: Austin Seipp; ghc-d...@haskell.org; glasgow-haskell- | us...@haskell.org; Simon Peyton-Jones | Subject: Re: 7.8 Release Update | | Excellent. Simon, are you privvy to this work at all? We lightly | talked about it last week, but I'm not sure if you've reviewed it. Or | perhaps Pedro or someone else could if we have time (I seem to | remember he drew up the initial design points.) | | On Sun, Sep 8, 2013 at 11:08 PM, Trevor Elliott tre...@galois.com | wrote: | Hi Austin, | | Iavor and I have got the data kinds syntax changes up to date with | master, | on the data-kind-syntax branch. The -XDataKinds section of the manual | has | been updated to describe the new syntax. During a validate run, there | were | some problems building haddock, so I'm going to look into that | tonight. | | There are tests for the data kind syntax in the test suite, currently | on the | data-kind-syntax branch. | | Other than the haddock fix, I think that we're ready to go. | | Thanks! | | --trevor | | | On Sun 08 Sep 2013 04:27:33 PM PDT, Austin Seipp wrote: | | Friends, | | After talking with SPJ, we've decided that the cutoff date for the | 7.8 | feature window will essentially start on Monday, the 16th. This is | the | beginning of the week before ICFP. This is a week from tomorrow. | | Afterwords, I suspect we will cut the 7.8 branch in early October (my | notes tentatively say Oct. 9th.) This will give us a few weeks of | straight bugfixing. | | Don't let this scare you too much. We're doing this at the beginning | of the week so we have time to sort things out. Bug fixes will of | course continuously be welcome until the 7.8 branch. | | However, for pending features, I'd like a status update. Everyone | mentioned below, please reply to clarify anything: | |* Iavor Diatchki and SPJ are working together on the type-nats- | simple | branch. I believe this will hopefully land in time. Iavor, SPJ - can | you comment here? | |* Trevor and Iavor are also working on kinds without data. Any word | here? | |* Geoffrey is currently moving, but he says the SIMD work and new | template-haskell work will land by the end of this week, which is | great. | |* Patrick Palka has a few loose ends to tie off for the parallel | compilation driver. I talked to him today, and after Andreas | committed | his bugfix to base, I believe everything is now working, with the | deadlocks sorted out. Patrick, can you confirm? We can get this | merged | ASAP if so. | |* Pedro and Richard - what's the story on propositional equality, | etc? This is mentioned on the status page[1] but I'm not sure what | else needs to be done. I know Pedro committed the work to make manual | Typeable instances an error, which is great. | |* Luite and Edsko will be talking about some final changes to the | hooks patch, and afterwords it can hopefully be integrated. I'll keep | up with them this week. | |* I am currently working on integrating the Applicative-Monad | warning, but this requires some upstream patches for the build to | work. However, we still need to sync several upstream libraries, and | this will be happening over the next few weeks. Therefore, I may | commit it, and incrementally fix validation errors as time goes on | and | me and Herbert sync upstreams. | | IMO, most of these look to be in good shape, I think. | | If you *do not think you'll make it by the 16th*, please let me know. | We can possibly still land it the week of the 16th, provided I know | ASAP. But we really really need to know, because many people will be | gone the following week. | | In the following few days, I'm hoping going to finish off everything | I | can in the patch queue, and fix my remaining bugs, and investigate | Dynamic GHCi in particular. | | Again, if you don't think you can make it on the 16th, but still | within the week, we can of discuss it. | | | | | | -- | Regards, | Austin - PGP: 4096R/0x91384671 ___ ghc-devs mailing list ghc-d...@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 7.8 Release Update
On Mon, Sep 9, 2013 at 1:14 PM, Edward Z. Yang ezy...@mit.edu wrote: I think Kazu is saying that when he builds something with profiling using cabal-install, it fails because cabal-install tries to build a dynamic version too. We don't want dyanmic/profiled libraries (there's no point, you can't load them into GHCi). Perhaps this is something that needs fixing in cabal-install? Agreed, sounds like a Cabal install bug. I don't know what the right fix is. Can someone who understands the issue submit a pull request to cabal-install? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 7.8 Release Update
That sounds terrible expensive to do on every `cabal build` and its a cost most users won't understand (what was broken before?). On Mon, Sep 9, 2013 at 4:06 PM, Edward Z. Yang ezy...@mit.edu wrote: If I am building some Haskell executable using 'cabal build', the result should be *statically linked* by default. However, subtly, if I am building a Haskell library, I would like to be able to load the compiled version into GHCi. So it seems to me cabal should produce v, dyn (libs only, not final executable) and p ways by default (but not dyn_p). Edward Excerpts from Kazu Yamamoto (山本和彦)'s message of Mon Sep 09 15:37:10 -0700 2013: Hi, Kazu (or someone else), can you please file a ticket on the Cabal bug tracker [1] if you think that this a Cabal bug? I'm not completely sure yet. GHCi 7.8 uses dynamic linking. This is true. So, what is a consensus for GHC 7.8 and cabal-install 1.18? Are they supposed to use dynamic linking? Or, static linking? If dynamic linking is used, GHC should provide dynamic libraries for profiling. If static linking is used, cabal-install should stop using dynamic libraries for profiling. And of course, I can make a ticket when I'm convinced. P.S. Since doctest uses GHCi internally, I might misunderstand GHC 7.8 uses dynamic linking. Anyway, I don't understand what is right yet. --Kazu ___ ghc-devs mailing list ghc-d...@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Simplifying Core pretty-printing via GHC API?
On Wed, May 1, 2013 at 2:13 PM, Conal Elliott co...@conal.net wrote: I'm using the GHC API to compile Haskell source code to Core. I'd like to pretty-print the result with the sort of simplifications I get with -dsuppress-type-applications, -dsuppress-uniques, etc (used in combination with -ddump-simpl on ghc's command line). How can I set these options via the GHC API? Has the answer changed since 7.4.1 (which I'm currently using)? I'd also be interested in the answer and whatever you're working on Conal. I spend more time looking at core than I like and anything that can made that time more efficient would be great. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: base package -- goals
On Wed, Mar 13, 2013 at 7:04 AM, Simon Peyton-Jones simo...@microsoft.comwrote: Most people won't care and will continue to depend on enough to get Prelude. Let me just put this out here so keep it in the back of our heads: most people don't care about this whole thing (splitting base) so lets make sure there's still a base package to import that gives people what they have before. :) Other than that I'm quite excited about the prospects of splitting up base a bit. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: base package -- goals
On Mon, Mar 11, 2013 at 4:45 PM, Simon Peyton-Jones simo...@microsoft.comwrote: B Better for internal implementation (eg using containers or bytestring in base) Note that this also means better code for external clients, as we can offer e.g. a better System.IO that lets people use Handles to read Text and ByteStrings in a more natural way (i.e. the I/O functions will be in one place, not spread out throughout N data structure libraries). ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: base package -- goals
Hi all, Let me add the goals I had in mind last time I considered trying to split base. 1. I'd like to have text Handles use the Text type and binary Handles use the ByteString type. Right now we have this somewhat awkward setup where the I/O APIs are spread out and bundled with pure types. Splitting base would let us fix this and write a better I/O layer. 2. The I/O manager currently has a copy of IntMap inside its implementation because base cannot use containers. Splitting base would let us get rid of this code duplication. I'm less interested in having super fine-grained dependencies in my libraries. More packages usually means more busy-work managing dependencies. Taken to its extreme you could imagine having base-maybe, base-bool, and whatnot. I don't think this is an improvement. Splitting base into perhaps 3-5 packages (e.g. GHC.*, IO, pure types) should let us get a bunch of benefits without too many downsides. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Race-condition in alternative 'System.Timeout.timeout' implementation
On Sun, Feb 24, 2013 at 2:31 PM, Herbert Valerio Riedel h...@gnu.org wrote: I've been experimenting with an alternative implementation of 'System.Timeout.timeout'[1] which avoids the overhead of spawning a new thread for each invocation. Part of my motivation is to see if I can implement a faster version of threadWaitReadTimeout :: Int - Fd - IO Bool threadWaitReadTimeout to = liftM (maybe False (const True)) . timeout to . threadWaitRead and thus exploit GHC's event notification system instead of having to reimplement a timeout-manager myself (like popular HTTP server libraries such as Snap or Warp do currently). The following Haskell program shows a proof-of-concept implementation derived directly from 'System.Timeout.timeout' together with a Criterion benchmark comparing the performance between the original and the alternative 'timeout' function wrapping a 'readMVar' call. On a i7-3770 with GHC-7.6.2/Linux/64bit ran with +RTS -A4m -N4, the benchmark shows a 15x improvement for the new implementation (below 1 uS) compared to the original implementation (~13 uS): Fast timeouts is really important for real world web servers, which typically need one timeout per connection (e.g. to avoid slowloris DOS attacks). We should make sure timeouts are as cheap and fast as possible. This seems like a step in the right direction. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: base package
Hi Joachim. 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 and consider what logical groupings makes sense. For example, even if the float functionality can be split from the int functionality, I don't think that makes for a very logical grouping. In addition, I don't think we want to say that e.g. pure data structures can't depend on the FFI. While their current implementation might not use the FFI, what if we want to use it in the future. We'd have to reshuffle the packages again. Just my 2 cents. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: base package
On Fri, Feb 22, 2013 at 3:34 PM, Joachim Breitner m...@joachim-breitner.dewrote: right, there is a tension between having just independent APIs and having also independent implementations. My main goal is to allow packages to specify their imports more precisely, to require less changes as not-so-common stuff in base evolves and to make it easier for alternative compiler/targets to implement parts of base; this would just require providing better grouped APIs. But if we want that while retaining the freedom to have an entangled implementation, we are back at the large base + specific re-exporting packages approach, which wasn’t particularly well received here. I don't know about entangled implementations. But I'd like to have a base package (e.g. your base-pure) that has a consistent set of basic data types e.g. Int, Word, Float, Double, Char, String, ByteString, Text, [a], Maybe, Either, and so forth. These are logically at the same layer. I think splitting them according to how they happen to be implemented at the moment is a misstake. It would give us a illogical and unstable layering in the long run. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: base package (Was: GHC 7.8 release?)
On Thu, Feb 14, 2013 at 6:48 AM, Joachim Breitner m...@joachim-breitner.dewrote: Maybe the proper is to reverse the whole approach: Leave base as it is, and then build re-exporting smaller packages (e.g. a base-pure) on top of it. The advantage is: * No need to rewrite the tightly intertwined base. * Libraries still have the option to have tighter dependencies. * Base can evolve with lots of breaking changes, as long as they do not affect the API by the smaller packages. * Development of this collection can happen outside the GHC tree. * Alternative implementations for (some of) these packages can be created, if the reason why they could not be moved out of base is one of implementation, not of API How does that sound? I'm not in favor of this approach as it precludes pushing any data types down the stack. In particular, we want text and bytestring to be below the I/O layer, so we can defined Handles that work with those in base itself. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: base package (Was: GHC 7.8 release?)
On Thu, Feb 14, 2013 at 8:45 AM, Joachim Breitner m...@joachim-breitner.dewrote: ./Control/Applicative.hs ./Control/Arrow.hs ./Control/Category.hs ./Control/Monad/Fix.hs ./Control/Monad.hs ./Data/Bits.hs ./Data/Bool.hs ./Data/Either.hs ./Data/Eq.hs ./Data/Foldable.hs ./Data/Function.hs ./Data/Functor.hs ./Data/Int.hs ./Data/List.hs ./Data/Maybe.hs ./Data/Monoid.hs ./Data/Ord.hs ./Data/Ratio.hs ./Data/Traversable.hs ./Data/Tuple.hs ./Data/Typeable.hs ./Data/Typeable.hs-boot ./Data/Typeable/Internal.hs ./Data/Typeable/Internal.hs-boot ./dist/build/autogen/Paths_base_pure.hs ./GHC/Base.lhs ./GHC/Char.hs ./GHC/Enum.lhs ./GHC/Err.lhs ./GHC/Err.lhs-boot ./GHC/Exception.lhs ./GHC/Fingerprint.hs ./GHC/Fingerprint/Type.hs ./GHC/Int.hs ./GHC/List.lhs ./GHC/Num.lhs ./GHC/Real.lhs ./GHC/Show.lhs ./GHC/Word.hs ./Prelude.hs (contains just $!) ./Unsafe/Coerce.hs That's great. I'm curious I was under the impression that it was hard to split out a pure subset as functions might call 'error' (e.g. due to incomplete pattern matches) and that would pull in the whole I/O subsystem. How did you avoid that? -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: base package (Was: GHC 7.8 release?)
On Thu, Feb 14, 2013 at 2:53 PM, Joachim Breitner m...@joachim-breitner.dewrote: Hi, Am Donnerstag, den 14.02.2013, 13:19 -0800 schrieb Johan Tibell: That's great. I'm curious I was under the impression that it was hard to split out a pure subset as functions might call 'error' (e.g. due to incomplete pattern matches) and that would pull in the whole I/O subsystem. How did you avoid that? as mentioned before: By crippling GHC.Fingerprint. error foo just calls raise (ErrorCall foo), which calls raise# (SomeException (ErrorCall foo). The problem is that the definition of SomeException pulls in the Exception type class, which pulls in Typeable, which pulls in GHC.Fingerprint, which uses FFI and IO code to to fingerprinting... I don't think having FFI far down the stack is a problem. There are lots of pure data types we'd like in the pure data layer (e.g. bytestring) that uses FFI. As long as the I/O layer itself (System.IO, the I/O manager, etc) doesn't get pulled in there's no real problem in depending on the FFI. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
Hi, I think reducing breakages is not necessarily, and maybe not even primarily, an issue of releases. It's more about realizing that the cost of breaking things (e.g. changing library APIs) has gone up as the Haskell community and ecosystem has grown. We need to be conscious of that and carefully consider if making a breaking change (e.g. changing a function instead of adding a new function) is really necessary. Many platforms (e.g. Java and Python) rarely, if ever, make breaking changes. If you look at compiler projects (e.g. LLVM and GCC) you never see intentional breakages, even in major releases*. Here's a question I think we should be asking ourselves: why is the major version of base bumped with every release? Is it really necessary to make breaking changes this often? How about aiming for having GHC 7.10 be a release where we only add new stuff and improve old stuff? -- Johan * A major GCC release usually signifies that some large change to the code generator was made. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On Mon, Feb 11, 2013 at 4:34 PM, Gabriel Dos Reis g...@integrable-solutions.net wrote: I have some experience with GCC releases -- having served as a GCC Release Manager for several years. In fact, the release scheme we currently have has gone through several iterations -- usually after many existential crisis. Yes, we don't break GCC ABI lightly, mostly because GCC isn't a research compiler and most research works are done on forgotten branches that nobody cares about anymore. Implementing new standards (e.g. moving from C++03 to C++11 that has several mandated API and ABI breakage) is a royal pain that isn't worth replicating in GHC -- at least if you want GHC to remain a research compiler. Concerning your question about release number, I would venture that there is a certain marketing aspect to it. I can tell you that we, the GCC community, are very poor at that -- otherwise, we would have been at version 26 or something :-) Thanks for sharing! My perspective is of course as a user. I don't think I've ever run into a case where the compiler broken a previous work e.g. C++ program. On the other hand I have to make a release of most of the libraries I maintain with every GHC release (to bump cabal version constraints to accept the new base version, if nothing else). -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On Fri, Feb 8, 2013 at 6:28 AM, Simon Marlow marlo...@gmail.com wrote: For a while we've been doing one major release per year, and 1-2 minor releases. We have a big sign at the top of the download page directing people to the platform. We arrived here after various discussions in the past - there were always a group of people that wanted stability, and a roughly equally vocal group of people who wanted the latest bits. So we settled on one API-breaking change per year as a compromise. Since then, the number of packages has ballooned, and there's a new factor in the equation: the cost to the ecosystem of an API-breaking release of GHC. All that updating of packages collectively costs the community a lot of time, for little benefit. Lots of package updates contributes to Cabal Hell. The package updates need to happen before the platform picks up the GHC release, so that when it goes into the platform, the packages are ready. So I think, if anything, there's pressure to have fewer major releases of GHC. However, we're doing the opposite: 7.0 to 7.2 was 10 months, 7.2 to 7.4 was 6 months, 7.4 to 7.6 was 7 months. We're getting too efficient at making releases! I think we want to decouple GHC major releases (as in, we did lots of work) from API breaking releases. For example, GCC has lots of major (or big) releases, but rarely, if ever, break programs. I'd be delighted to see a release once in a while that made my programs faster/smaller/buggy without breaking any of them. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On Thu, Feb 7, 2013 at 6:48 PM, Ben Lippmeier b...@ouroborus.net wrote: Right now, the latest packages uploaded to Hackage get built with ghc-7.6 (only), and all the pages say Built on ghc-7.6. By doing this we force *all* library developers to run GHC 7.6. I think this sends the clearest message about what the real GHC version is. I don't know how closely users look at the built on line on the package page. Perhaps they look there, perhaps they don't. Between Bryan and me we build all of our own packages and all HP packages on the latest 3 GHC versions: http://ci.johantibell.com/ https://jenkins.serpentine.com/ That doesn't mean that it would be a bad idea to build all Hackage packages on using more GHC versions, but that won't happen until the Hackage project is unstuck (it has been stuck for years!). -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Should ghc -msse imply gcc -msse
Hi all, I forgot I once raised this on the GHC bug tracker: http://hackage.haskell.org/trac/ghc/ticket/7025 Here's what Simon M had to say back then: The right thing is to put -msse in the cc-options field of your .cabal file, if that's what you want. I'm distinctly uneasy about having -msse magically pass through to gcc. * There are many flags that we do not pass through to gcc, so having one that we do pass through could be confusing (and lead to lots more requests for more flags to be passed through) * What if there is a variant of -msse that gcc supports but we don't? Wouldn't we have to keep them in sync? I'm going to close this as wontfix, but please feel free to reopen and disagree. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Should ghc -msse imply gcc -msse
On Thu, Jan 17, 2013 at 12:01 PM, Johan Tibell johan.tib...@gmail.com wrote: I forgot I once raised this on the GHC bug tracker: http://hackage.haskell.org/trac/ghc/ticket/7025 Here's what Simon M had to say back then: The right thing is to put -msse in the cc-options field of your .cabal file, if that's what you want. I'm distinctly uneasy about having -msse magically pass through to gcc. * There are many flags that we do not pass through to gcc, so having one that we do pass through could be confusing (and lead to lots more requests for more flags to be passed through) * What if there is a variant of -msse that gcc supports but we don't? Wouldn't we have to keep them in sync? I'm going to close this as wontfix, but please feel free to reopen and disagree. One problem with having the user set cc-options in addition to passing -msse to GHC, is that the user might not realize that he/she needs to do this. This is bad if you use -fllvm, as your -msse will essentially just be ignored as the LLVM primitives we use in the LLVM backend (e.g. for popcnt) won't convert to SSE instructions. Even worse, LLVM doesn't support a -msse flag, instead you need to use -mattr=+sse, so the user needs to be aware of this difference and change his/her flags depending on if we use the native backend or the LLVM backend. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Should ghc -msse imply gcc -msse
On Thu, Jan 17, 2013 at 12:29 PM, Simon Marlow marlo...@gmail.com wrote: If the intended meaning of -msse is Use SSE instructions in Haskell compilations then of course we should pass -mattr=+sse to LLVM, because it is the backend for Haskell compilations. But we should not pass it to gcc, unless we're using the C backend. Lets do at least this then. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Newtype wrappers
On Mon, Jan 14, 2013 at 11:14 AM, Andrea Vezzosi sanzhi...@gmail.com wrote: Have you considered the effect on types like Data.Set that use the uniqueness of typeclass instances to maintain invariants? e.g. even when we have newtype X = X Y coercing Set X to Set Y can produce a tree with the wrong shape for the Ord instance of Y. I was just going to say that. Changing newtypes changes instances, which isn't safe in the general case. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Newtype wrappers
On Mon, Jan 14, 2013 at 1:19 PM, Simon Peyton-Jones simo...@microsoft.com wrote: Have you considered the effect on types like Data.Set that use the uniqueness of typeclass instances to maintain invariants? e.g. even when we have newtype X = X Y coercing Set X to Set Y can produce a tree with the wrong shape for the Ord instance of Y. Good point. I should add this. The wrapper should only work if the relevant data constructors are in scope; rather like GHC’s existing auto-unwrapping on foreign calls (http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi.html#ffi-newtype-io) I don't follow. Are you saying that adding an import, even if nothing from that import is used, can effect if the program compiles? Does that mean if we ever add Data.Map.Internal that exposes the data constructors to users who know what they're doing (i.e. are willing to take it upon themselves to maintain the invariants) then code that used to compile will stop to do so? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Newtype wrappers
On Mon, Jan 14, 2013 at 1:45 PM, Roman Cheplyaka r...@ro-che.info wrote: * Johan Tibell johan.tib...@gmail.com [2013-01-14 13:32:54-0800] On Mon, Jan 14, 2013 at 1:19 PM, Simon Peyton-Jones simo...@microsoft.com wrote: Have you considered the effect on types like Data.Set that use the uniqueness of typeclass instances to maintain invariants? e.g. even when we have newtype X = X Y coercing Set X to Set Y can produce a tree with the wrong shape for the Ord instance of Y. Good point. I should add this. The wrapper should only work if the relevant data constructors are in scope; rather like GHC’s existing auto-unwrapping on foreign calls (http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi.html#ffi-newtype-io) I don't follow. Are you saying that adding an import, even if nothing from that import is used, can effect if the program compiles? Does that mean if we ever add Data.Map.Internal that exposes the data constructors to users who know what they're doing (i.e. are willing to take it upon themselves to maintain the invariants) then code that used to compile will stop to do so? Now I don't follow you. Why will it stop compiling? If you define wrappers/unwrappers involving Data.Map, then they will compile if Data.Map.Internal is imported and will not compile if it isn't. Let me rephrase: how will Simon's proposed data constructors are in scope mechanism work? For example, will let xs :: Map = ... in map MyNewtype xs behave differently if the constructors of Map are in scope or not? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Newtype wrappers
On Mon, Jan 14, 2013 at 2:33 PM, Roman Cheplyaka r...@ro-che.info wrote: * Johan Tibell johan.tib...@gmail.com [2013-01-14 14:29:57-0800] Let me rephrase: how will Simon's proposed data constructors are in scope mechanism work? For example, will let xs :: Map = ... in map MyNewtype xs behave differently if the constructors of Map are in scope or not? Coercion is never implicit. In Simon's original proposal, for example, you need to define coercion functions using a special syntax. So this code will always work in the same, traditional way. I'm completely lost. What is Simon's proposal? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Newtype wrappers
On Mon, Jan 14, 2013 at 2:57 PM, Roman Cheplyaka r...@ro-che.info wrote: It's described here: http://hackage.haskell.org/trac/ghc/wiki/NewtypeWrappers We seem to be talking past each other. There's a specific problem related to type classes and invariants on data types mentioned earlier on this thread. Simon's solution here seems to be that we only coerce a structure from one newtype to the base type if the constructors are exposed, hence my question if the code changes semantics due to adding imports. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Newtype wrappers
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(..)), then 'foreign ... :: T - IO ()' gives an error, but import it and coerces T to its underlying type (hopefully that's a C type). This is what I thought Simon meant. If so, I don't think it's a good idea, as adding the import removes a compiler error in favor of a runtime error. If the programmer really wanted to do something this unsafe, she should use unsafeCoerce. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Newtype wrappers
On Mon, Jan 14, 2013 at 3:40 PM, Evan Laforge qdun...@gmail.com wrote: Wait, what's the runtime error? Do you mean messing up Set's invariants? Yes. If you as the library writer don't want to allow unsafe things, then don't export the constructor. Then no one can break your invariants, even with newtype malarky. If you as the the library user go and explicitly import the bare Set constructor from (theoretical) Data.Set.Unsafe, then you are in the position to break Set's internal invariants anyway, and have already accepted the great power / great responsibility tradeoff. If it's explicit that this is what you're doing I'm fine with it. I just don't want magic coercing depending on what's in scope. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Should ghc -msse imply gcc -msse
Hi all, You can turn on e.g. SSE 4.1 by passing -msse4.2 to ghc. This doesn't currently imply that we compile any C code with -msse4.2 turned on, so if someone really want to use SSE4.2, they have to do: ghc -msse4,2 -optc-msse4.2 Do we want to change this so it's enough to pass -msse4.2 to ghc? -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Tagging subjects of emails sent from the list
I'd prefer if they weren't tagged. My mail reader (GMail) can do the tagging for me and I'll end up with duplicated tags and the list of subjects get harder to scan. On Thu, Dec 20, 2012 at 9:57 AM, Jan Stolarek jan.stola...@p.lodz.pl wrote: Would it be possible to change mailing list settings so that topics of emails begin with [glasgow-haskell-users] (and for upcoming lists: [ghc-devs], [ghc-commits] and so on. No quotation marks of course). It would make filtering and searching in the mailbox easier. Janek ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Suggested policy: use declarative names for tests instead of increasing integers
Hi, I find our tests to be quite hard to navigate, as the majority have names like tc12345.hs or some such. I suggest we instead use descriptive names like GADT.hs or PrimOps.hs instead. What do people think? -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Need workaround for lack of fromIntegral/Int-Word rules in 7.4.2
This compiles badly in 7.4.2:
f :: Int - Word
f = fromIntegral
I need a workaround.
On Mon, Dec 17, 2012 at 2:35 AM, Simon Peyton-Jones
simo...@microsoft.com wrote:
I don't understand the problem clearly enough to help. Can you give a
concrete example?
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-
| users-boun...@haskell.org] On Behalf Of Johan Tibell
| Sent: 14 December 2012 23:17
| To: glasgow-haskell-users
| Subject: Need workaround for lack of fromIntegral/Int-Word rules in
| 7.4.2
|
| I'm trying to work around the lack of some fromIntegral/Int-Word rules
| in 7.4.2. I tried something like:
|
| int2Word :: Int - Word
| #if defined(__GLASGOW_HASKELL__)
| int2Word (I# i#) = W# (int2Word# i#)
| #else
| int2Word = fromIntegral
| #endif
|
| {-# RULES fromIntegral/Int-Word fromIntegral = int2Word #-}
|
| but that didn't work as some fromSmallInteger and integerToWord function
| calls got inserted before my rule had a chance to fire. Can anyone think
| of a workaround that would work with 7.4.2?
|
| P.S. The reason I want this workaround is that some of my users are
| stuck on 7.4.2 and this regression is affecting them quite badly, making
| me want to try to fix it in my library.
|
| Cheers,
| Johan
|
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Need workaround for lack of fromIntegral/Int-Word rules in 7.4.2
Hi, Turns out that I need a larger example to trigger the bug. I can reliable trigger it using the unordered-containers library. I won't bore you with the details. The workaround I need is this: forall x. integerToWord (smallInteger x) = int2Word# x ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Need workaround for lack of fromIntegral/Int-Word rules in 7.4.2
I'm trying to work around the lack of some fromIntegral/Int-Word
rules in 7.4.2. I tried something like:
int2Word :: Int - Word
#if defined(__GLASGOW_HASKELL__)
int2Word (I# i#) = W# (int2Word# i#)
#else
int2Word = fromIntegral
#endif
{-# RULES fromIntegral/Int-Word fromIntegral = int2Word #-}
but that didn't work as some fromSmallInteger and integerToWord
function calls got inserted before my rule had a chance to fire. Can
anyone think of a workaround that would work with 7.4.2?
P.S. The reason I want this workaround is that some of my users are
stuck on 7.4.2 and this regression is affecting them quite badly,
making me want to try to fix it in my library.
Cheers,
Johan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Hoopl vs LLVM?
On Wed, Dec 12, 2012 at 4:35 AM, Simon Marlow marlo...@gmail.com wrote: On 11/12/12 21:33, Johan Tibell wrote: I'd definitely be interesting in understanding why as it, like you say, makes it harder for LLVM to understand what our code does and optimize it well. The example that Simon gave is a good illustration: snip My question was more: why do we CPS transform? I guess it's because we manage our own stack? -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Mailing list reorganisation
On Tue, Dec 11, 2012 at 7:04 AM, Ian Lynagh i...@well-typed.com wrote: Does that sound reasonable? Does anyone have any further questions or comments? Sound good to me. Thanks for working on this. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Hoopl vs LLVM?
On Tue, Dec 11, 2012 at 11:16 AM, Simon Peyton-Jones simo...@microsoft.com wrote: Notice that the stack is now *explicit* rather than implicit, and LLVM has no hope of moving the assignment to z past the call to g (which is trivial in the original). I can explain WHY we do this (there is stuff on the wiki) but the fact is that we do, and it's no accident. I'd definitely be interesting in understanding why as it, like you say, makes it harder for LLVM to understand what our code does and optimize it well. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Hoopl vs LLVM?
On Mon, Dec 10, 2012 at 2:24 PM, Greg Fitzgerald gari...@gmail.com wrote: Should one group be stealing ideas from the other? Or apples and oranges? In my opinion we should only implement optimizations in Hoopl that LLVM cannot do due to lack high-level information that we might have gotten rid of before we reach the LLVM code generator*. I don't think we should spend time re-implementing LLVM passes in Hoopl. We have limited time on our hands (much less than the LLVM team) and we're unlikely to do a better job than them here, as we're talking about implementing standard, imperative code optimization. I think our time is better spent on 1) making sure we pass enough information to LLVM for it to do a good job and 2) working on higher-level optimizations (e.g. Core-to-Core). * This also means that I think we should try to preserve any information LLVM might need all the way down to the code generator. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Which of the following PrimTyCons have a pointer-sized representations
On Fri, Dec 7, 2012 at 3:36 AM, Simon Peyton-Jones simo...@microsoft.com wrote: You can use TyCon.tyConPrimRep, followed by primRepSizeW Looking at primRepSizeW I see that the only PrimRep that is bigger than one word is Doubles, Int64s, and Word64s on 32-bit platforms. Manuel (I think wisely) suggested that we should make an exception for these types and unpack them on 32-bit platforms if -funbox-strict-primitive-fields is set, even thought technically they will occupy more space than a pointer. The reasoning is that we want to avoid surprising behavior when users move code between 32-bit and 64-bit platforms, as e.g. unpacking vs not-unpacking Doubles can make a large difference in certain tight loops. But this means that checking the size in can_unbox_prim is no longer necessary, so I could remove that check. This does mean that if we ever add a new PrimTyCon that has a size that's larger than a pointer, the implementation of -funbox-strict-primitive-fields has to change. The alternative would be for me to add primRepSizeForUnboxW :: PrimRep - Int primRepSizeForUnboxW IntRep = 1 primRepSizeForUnboxW WordRep = 1 primRepSizeForUnboxW Int64Rep = 1-- [Note: Primitive size exception] primRepSizeForUnboxW Word64Rep= 1-- [Note: Primitive size exception] primRepSizeForUnboxW FloatRep = 1-- NB. might not take a full word primRepSizeForUnboxW DoubleRep= 1-- [Note: Primitive size exception] primRepSizeForUnboxW AddrRep = 1 primRepSizeForUnboxW PtrRep = 1 primRepSizeForUnboxW VoidRep = 0 And use that function in can_unbox_prim. That way we'd get a pattern match warning if we ever add a new PrimRep (and thus need to evaluate if PrimTyCons with that PrimRep should be unpacked by -funbox-strict-primitive-fields). What do you think? Cheers, Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Which of the following PrimTyCons have a pointer-sized representations
On Fri, Dec 7, 2012 at 10:48 AM, Johan Tibell johan.tib...@gmail.com wrote: On Fri, Dec 7, 2012 at 3:36 AM, Simon Peyton-Jones simo...@microsoft.com wrote: You can use TyCon.tyConPrimRep, followed by primRepSizeW Looking at primRepSizeW I see that the only PrimRep that is bigger than one word is Doubles, Int64s, and Word64s on 32-bit platforms. Manuel (I think wisely) suggested that we should make an exception for these types and unpack them on 32-bit platforms if -funbox-strict-primitive-fields is set, even thought technically they will occupy more space than a pointer. The reasoning is that we want to avoid surprising behavior when users move code between 32-bit and 64-bit platforms, as e.g. unpacking vs not-unpacking Doubles can make a large difference in certain tight loops. But this means that checking the size in can_unbox_prim is no longer necessary, so I could remove that check. This does mean that if we ever add a new PrimTyCon that has a size that's larger than a pointer, the implementation of -funbox-strict-primitive-fields has to change. The alternative would be for me to add primRepSizeForUnboxW :: PrimRep - Int primRepSizeForUnboxW IntRep = 1 primRepSizeForUnboxW WordRep = 1 primRepSizeForUnboxW Int64Rep = 1-- [Note: Primitive size exception] primRepSizeForUnboxW Word64Rep= 1-- [Note: Primitive size exception] primRepSizeForUnboxW FloatRep = 1-- NB. might not take a full word primRepSizeForUnboxW DoubleRep= 1-- [Note: Primitive size exception] primRepSizeForUnboxW AddrRep = 1 primRepSizeForUnboxW PtrRep = 1 primRepSizeForUnboxW VoidRep = 0 And use that function in can_unbox_prim. That way we'd get a pattern match warning if we ever add a new PrimRep (and thus need to evaluate if PrimTyCons with that PrimRep should be unpacked by -funbox-strict-primitive-fields). I went with the latter approach as it seems safer. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Generating a C call from a MachOp
Hi, I'm trying to implement word2Double#, which I represent as a MachOp I call MO_UF_Conv (which is very similar to MO_SF_Conv). On some platform I need to implement this MachOp as a call to a C function. Here's what I did in the PPC backend (PPC/CodeGen.hs) for example: getRegister' dflags (CmmMachOp mop [x]) -- unary MachOps = case mop of MO_UF_Conv from to - coerceWord2FP from to x coerceWord2FP :: Width - Width - CmmExpr - NatM Register coerceWord2FP fromRep toRep x = do dflags - getDynFlags (src, src_code) - getSomeReg x -- This is not the type of register I need! dst - getNewRegNat (floatSize toRep) targetExpr - cmmMakeDynamicReference dflags addImportNat CallReference lbl let target = ForeignTarget targetExpr (ForeignConvention CCallConv [NoHint] [NoHint] CmmMayReturn) call_code - genCCall target [src] [dst] let code' = src_code `appOL` call_code return (Fixed (floatSize toRep) dst code') where lbl = mkCmmCodeLabel primPackageId (fsLit $ word2FloatLabel toRep) This doesn't work. The issue is that to make a C call I need CmmFormals and CmmActuals. I cannot figure out how to get the former, as I need to get hold of a LocalReg, which I don't see any way of creating. I could try to make MO_UF_Conv a CallishMachOp, but then I'll have a more difficult time implementing this MachOp in e.g. the LLVM backend, where I don't want to generate a C call but instead output some instructions. I could use some pointers. Cheers, Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Emitting constants to the .data section from the NatM monad
On Thu, Dec 6, 2012 at 1:34 PM, Simon Marlow marlo...@gmail.com wrote: So are you going to add the two missing MachOps, MO_UF_Conv MO_FU_Conv? I'm trying to add those. I'm now thinking that I will use C calls (which is still much faster than going via Integer) instead of emitting some assembly, as the former is much easier but still allows us to do the latter later. The LLVM backend will use the dedicated LLVM instruction for conversions so it will generate really good code. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Which of the following PrimTyCons have a pointer-sized representations
Hi, As part of some work I'm doing I need to classify all PrimTyCons by the size of their representation as fields*. I need to classify them into two classes: pointer-sized (or smaller) and larger-than-pointer-sized. I've managed to figure out a bunch of them myself: Pointer-sized: addrPrimTyCon arrayPrimTyCon byteArrayPrimTyCon -- Represented as a pointer to heap object arrayArrayPrimTyCon -- Represented as a pointer to heap object charPrimTyCon doublePrimTyCon -- Only on 64-bit floatPrimTyCon intPrimTyCon int32PrimTyCon int64PrimTyCon -- Only on 64-bit mutableArrayPrimTyCon -- Represented as a pointer to heap object mutableByteArrayPrimTyCon -- Represented as a pointer to heap object mutableArrayArrayPrimTyCon -- Represented as a pointer to heap object wordPrimTyCon word32PrimTyCon word64PrimTyCon -- Only on 64-bit These ones I need help with: bcoPrimTyCon weakPrimTyCon mVarPrimTyCon tVarPrimTyCon mutVarPrimTyCon realWorldTyCon stablePtrPrimTyCon stableNamePrimTyCon statePrimTyCon threadIdPrimTyCon anyTyCon eqPrimTyCon liftedTypeKindTyCon unliftedTypeKindTyCon openTypeKindTyCon constraintKindTyCon superKindTyCon anyKindTyCon I would appreciate any help classifying the bottom half. I will use this to implement -funbox-strict-primitive-fields * For example: while the StgArrWords heap object is a multi-byte object its representation as a field e.g. in data T = C ByteArray# is one pointer (to the StgArrWords heap object). -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
validate fails: No rule to make target `fast'
I'm getting this build failure from a: make maintainer clean perl boot; ./configure CPUS=2 sh validate ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final validate_build_transformers cd libraries/transformers /Users/tibell/src/ghc/bindisttest/install dir/bin/ghc --make Setup [1 of 1] Compiling Main ( Setup.hs, Setup.o ) Linking Setup ... cd libraries/transformers ./Setup configure --with-ghc=/Users/tibell/src/ghc/bindisttest/install dir/bin/ghc --with-haddock=/Users/tibell/src/ghc/bindisttest/install dir/bin/haddock --enable-library-vanilla --disable-shared --disable-library-prof --global --builddir=dist-bindist --prefix=/Users/tibell/src/ghc/bindisttest/install dir Configuring transformers-0.3.0.0... cd libraries/transformers ./Setup build --builddir=dist-bindist Building transformers-0.3.0.0... Preprocessing library transformers-0.3.0.0... [ 1 of 24] Compiling Data.Functor.Product ( Data/Functor/Product.hs, dist-bindist/build/Data/Functor/Product.o ) [ 2 of 24] Compiling Data.Functor.Compose ( Data/Functor/Compose.hs, dist-bindist/build/Data/Functor/Compose.o ) [ 3 of 24] Compiling Data.Functor.Identity ( Data/Functor/Identity.hs, dist-bindist/build/Data/Functor/Identity.o ) [ 4 of 24] Compiling Control.Monad.Trans.Class ( Control/Monad/Trans/Class.hs, dist-bindist/build/Control/Monad/Trans/Class.o ) [ 5 of 24] Compiling Control.Monad.IO.Class ( Control/Monad/IO/Class.hs, dist-bindist/build/Control/Monad/IO/Class.o ) [ 6 of 24] Compiling Control.Monad.Trans.Cont ( Control/Monad/Trans/Cont.hs, dist-bindist/build/Control/Monad/Trans/Cont.o ) [ 7 of 24] Compiling Control.Monad.Trans.Error ( Control/Monad/Trans/Error.hs, dist-bindist/build/Control/Monad/Trans/Error.o ) [ 8 of 24] Compiling Control.Monad.Trans.Identity ( Control/Monad/Trans/Identity.hs, dist-bindist/build/Control/Monad/Trans/Identity.o ) [ 9 of 24] Compiling Control.Monad.Trans.List ( Control/Monad/Trans/List.hs, dist-bindist/build/Control/Monad/Trans/List.o ) [10 of 24] Compiling Control.Monad.Trans.Maybe ( Control/Monad/Trans/Maybe.hs, dist-bindist/build/Control/Monad/Trans/Maybe.o ) [11 of 24] Compiling Control.Monad.Trans.Reader ( Control/Monad/Trans/Reader.hs, dist-bindist/build/Control/Monad/Trans/Reader.o ) [12 of 24] Compiling Control.Monad.Trans.RWS.Lazy ( Control/Monad/Trans/RWS/Lazy.hs, dist-bindist/build/Control/Monad/Trans/RWS/Lazy.o ) [13 of 24] Compiling Control.Monad.Trans.RWS ( Control/Monad/Trans/RWS.hs, dist-bindist/build/Control/Monad/Trans/RWS.o ) [14 of 24] Compiling Control.Monad.Trans.RWS.Strict ( Control/Monad/Trans/RWS/Strict.hs, dist-bindist/build/Control/Monad/Trans/RWS/Strict.o ) [15 of 24] Compiling Control.Monad.Trans.State.Lazy ( Control/Monad/Trans/State/Lazy.hs, dist-bindist/build/Control/Monad/Trans/State/Lazy.o ) [16 of 24] Compiling Control.Monad.Trans.State ( Control/Monad/Trans/State.hs, dist-bindist/build/Control/Monad/Trans/State.o ) [17 of 24] Compiling Control.Monad.Trans.State.Strict ( Control/Monad/Trans/State/Strict.hs, dist-bindist/build/Control/Monad/Trans/State/Strict.o ) [18 of 24] Compiling Control.Monad.Trans.Writer.Lazy ( Control/Monad/Trans/Writer/Lazy.hs, dist-bindist/build/Control/Monad/Trans/Writer/Lazy.o ) [19 of 24] Compiling Control.Monad.Trans.Writer ( Control/Monad/Trans/Writer.hs, dist-bindist/build/Control/Monad/Trans/Writer.o ) [20 of 24] Compiling Control.Monad.Trans.Writer.Strict ( Control/Monad/Trans/Writer/Strict.hs, dist-bindist/build/Control/Monad/Trans/Writer/Strict.o ) [21 of 24] Compiling Data.Functor.Constant ( Data/Functor/Constant.hs, dist-bindist/build/Data/Functor/Constant.o ) [22 of 24] Compiling Control.Applicative.Lift ( Control/Applicative/Lift.hs, dist-bindist/build/Control/Applicative/Lift.o ) [23 of 24] Compiling Control.Applicative.Backwards ( Control/Applicative/Backwards.hs, dist-bindist/build/Control/Applicative/Backwards.o ) [24 of 24] Compiling Data.Functor.Reverse ( Data/Functor/Reverse.hs, dist-bindist/build/Data/Functor/Reverse.o ) In-place registering transformers-0.3.0.0... cd libraries/transformers ./Setup haddock --builddir=dist-bindist Running Haddock for transformers-0.3.0.0... Preprocessing library transformers-0.3.0.0... Warning: The documentation for the following packages are not installed. No links will be generated to these packages: rts-1.0 Haddock coverage: 100% ( 2 / 2) in 'Data.Functor.Product' 100% ( 2 / 2) in 'Data.Functor.Compose' 100% ( 2 / 2) in 'Data.Functor.Identity' 100% ( 8 / 8) in 'Control.Monad.Trans.Class' 100% ( 2 / 2) in 'Control.Monad.IO.Class' 100% ( 14 / 14) in 'Control.Monad.Trans.Cont' 100% ( 15 / 15) in 'Control.Monad.Trans.Error' 100% ( 7 / 7) in 'Control.Monad.Trans.Identity' 100% ( 7 / 7) in 'Control.Monad.Trans.List' 100% ( 9 / 9) in 'Control.Monad.Trans.Maybe' 100% ( 18 / 18) in 'Control.Monad.Trans.Reader' 100% ( 37 / 37) in 'Control.Monad.Trans.RWS.Lazy' 100% ( 2 / 2) in 'Control.Monad.Trans.RWS' 100% ( 37 / 37) in
Re: The end of an era, and the dawn of a new one
On Wed, Dec 5, 2012 at 12:37 PM, David Terei davidte...@gmail.com wrote: I have always considered the LLVM code generator my responsibility and will continue to do so. 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 LLVM releases. So if others want are interested in working on it then there is plenty of room for that but I'll continue to maintain it and be responsible for it at the least. I will maintain the I/O manager as per usual, probably together with Bryan and Andreas (but I cannot speak for them of course). ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Emitting constants to the .data section from the NatM monad
Hi!
I'm trying to implement word2Double# and I've looked at how e.g. LLVM
does it. LLVM outputs quite clever branchless code that uses two
predefined constants in the .data section. Is it possible to add
contents to the current .data section from a function in the NatM
monad e.g.
coerceWord2FP :: Width - Width - CmmExpr - NatM Register
?
Cheers,
Johan
P.S. Given this C code
double f(unsigned long long u) { return u; }
LLVM generates this rather clever code:
.section__TEXT,__text,regular,pure_instructions
.section__TEXT,__literal8,8byte_literals
.align 3
LCPI1_0:
.long 1602224128 // constant we'd like to ouput
.long 0 // constant we'd like to ouput
.section__TEXT,__text,regular,pure_instructions
.globl _f
.align 4, 0x90
_f:
pushl %ebp
movl%esp, %ebp
subl$16, %esp
movl8(%ebp), %eax
movl12(%ebp), %ecx
movl%ecx, -4(%ebp)
movl%eax, -8(%ebp)
testl %ecx, %ecx // check sign
sets%al // check sign
xorb$1, %al // check sign
movzbl %al, %eax // 0 if signed
fildll -8(%ebp)// load integer
fadds LCPI1_0(,%eax,4)// add one of two constants
fstpl -16(%ebp) // store and pop
fldl-16(%ebp)
addl$16, %esp
popl%ebp
ret
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Does GHC still support x87 floating point math?
Hi, I'm currently trying to implement word2Double#. Other such primops support both x87 and sse floating point math. Do we still support x87 fp math? Which compiler flag enables it? -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC Performance Tsar
Hi Simon, I will try to find some time to set up a automatic run of nofib on my buildbot (which is powerful enough) and have it graph the results over time (and perhaps even email us when a benchmark dips). -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC Performance Tsar
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 script that we run today that would be a great start. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Computing the final representation type of a TyCon (Was: Unpack primitive types by default in data)
Hi,
I've created an initial implementation that seems to work. I'd
appreciate it if someone could review the code (it's short!) to tell
me if it's sane, can be improved, etc:
https://github.com/tibbe/ghc/commit/6b44024173eae3029b7b43f7cc9fc7d9d801c367
On Thu, Nov 29, 2012 at 12:27 AM, Johan Tibell johan.tib...@gmail.com wrote:
I've decided to try to implement the proposal included in the end of
this message. To do so I need to write a function
hasPointerSizedRepr :: TyCon - Bool
This function would check that that the TyCon is either
* a newtype, which representation type has a pointer-sized representation, or
* an algebraic data type, with one field that has a pointer-sized
representation.
I'm kinda lost in all the data types that GHC defines to represent
types. I've gotten no further than
hasPointerSizedRepr :: TyCon - Bool
hasPointerSizedRepr tc@(AlgTyCon {}) = case algTcRhs tc of
DataTyCon{ data_cons =
[data_con] }
- ...
NewTyCon { data_con = [data_con]
}
- ...
_ - False
hasPointerSizedRepr _= False
I could use some pointers (no pun intended!) at this point. The
function ought to return True for all the following types:
data A = A Int#
newtype B = B A
data C = C !B
data D = D !C
data E = E !()
data F = F !D
One part that confuses me is figuring out the representation type of a
data constructor after unpacking. For example, the function should not
return true if called on G in this example:
data G = G !H
data H = H {-# UNPACK #-} !I
data I = I !Int !Int
because if we unpacked H into G's constructor it would take up two
words, due to I being unpacked.
Does DataCon contain the unpacked representation of the data
constructor or only the before-optimizations representation?
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Is the GHC release process documented?
Friends, While writing a new nofib benchmark today I found myself wondering whether all the nofib benchmarks are run just before each release, which the drove me to go look for a document describing the release process. A quick search didn't turn up anything, so I thought I'd ask instead. Is there a documented GHC release process? Does it include running nofib? If not, may I propose that we do so before each release and compare the result to the previous release*. * This likely means that nofib has to be run for the upcoming release and the prior release each time a release is made, as numbers don't translate well between machines so storing the results somewhere is likely not that useful. Cheers, Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
What does gcc do? Does it link statically or dynamically by default? Does it depend on if it can find a dynamic version of libraries or not? -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Where has the special built-in inline function gone?
Hi all,
For the first time, I wanted to use the special built-in inline function.
To my dismay, I can't find it anywhere! Here's a minimal example:
--8-
module Main where
import GHC.Prim
f x = x + 1
{-# INLINE f #-}
g h x = inline h x
main = print $ g f 1
--8-
$ ghc /tmp/Repro.hs
[1 of 1] Compiling Main ( /tmp/Repro.hs, /tmp/Repro.o )
/tmp/Repro.hs:8:9:
Not in scope: `inline'
Perhaps you meant `unlines' (imported from Prelude)
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.4.1
-- Johan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Where has the special built-in inline function gone?
Thanks all. I've filed a bug for improving the docs. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Status of stack trace work
Hi! I can't wait until we have some for of stack traces in GHC. What's the current status? Did the semantics you presented at HIW12 work out? Even though the full bells and whistles of full stack traces is something I'd really like to see, even their more impoverished cousins, the lexical stack trace, would be helpful in tracking down just which call to head gave rise to a head: empty list error. Once we do have some sort of stack traces, could we have throw automatically attach it to the exception, so we can get a printed stack trace upon crash? Is that how e.g. Java deals with that? Will that make other uses of exceptions (such as throwing async exceptions to kill threads) get much more expensive if we try to attach stack traces? A frequent user of async exceptions are web servers that start a timeout call per request. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Proposal: EPHEMERAL pragma
Interesting idea. On Thu, Oct 25, 2012 at 6:56 AM, José Pedro Magalhães j...@cs.uu.nl wrote: 3. Emit a warning if the generated core code still contains uses of Rep. I think this part will be really annoying, as GHC might end up generating warnings that the programmer can do nothing about (because some optimization failed to remove Rep). -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: copyArray# bug
On Tue, Oct 9, 2012 at 1:26 AM, Roman Leshchinskiy r...@cse.unsw.edu.au wrote: Johan Tibell wrote: Hi, I did quite a bit of work to make sure copyArray# and friends get unrolled if the number of elements to copy is a constant. Does this still work with the extra branch? I would expect it to but I don't know. Does the testsuite check for this? Simon, the assembly testing support I added would be very useful now. It would tell us if this change preserved unrolling or not. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: copyArray# bug
Hi, I did quite a bit of work to make sure copyArray# and friends get unrolled if the number of elements to copy is a constant. Does this still work with the extra branch? -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 7.6.1
On Fri, Sep 7, 2012 at 11:05 AM, Herbert Valerio Riedel h...@gnu.org wrote: Ian Lynagh i...@well-typed.com writes: 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. ...why has bytestring-0.10.0.0 been held back? (afaics, the last couple of versions on Hackage were uploaded by you as well) Just a reminder that we need that bytestring version on Hackage as other compilers have no way of getting hold of it to fulfill a depedency on bytestring = 0.10. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 7.6.1
Woho! I love new GHC releases. On Thu, Sep 6, 2012 at 9:05 AM, Ian Lynagh i...@well-typed.com wrote: Full release notes are here: http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/release-7-6-1.html 1. There are a bunch of TODOs in the release notes. :) 2. Could you please push all the packages that were released in GHC 7.6.1 to Hackage as well? -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: Adding support for an API-since-version-attribute to Haddock?
On Tue, Sep 4, 2012 at 2:29 PM, Herbert Valerio Riedel h...@gnu.org wrote: Bryan O'Sullivan b...@serpentine.com writes: I think it would be very useful. We don't have any way of specifying identifier-level attributes right now that I know of, and such a capability would be helpful beyond just this use, too. ...what other use-cases for identifier-level attributes do you have in mind? Have a look at the Javadoc specification from ideas. Things like @see seems useful. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.6.1 Release Candidate 1
On Tue, Aug 14, 2012 at 6:47 AM, Christian Maeder christian.mae...@dfki.de wrote: I cannot test much, as long as the text package cannot be installed. dependency integer-gmp needs to be increased and: The latest released version of text now compiles with ghc-7.6.1-rc1. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Imported foreign functions should be strict
On Thu, Jul 12, 2012 at 11:29 AM, Favonia favo...@gmail.com wrote: I see. Thanks for the response! Perhaps it is better for the pretty printer to print out U(S) instead? Regards, Favonia I'd love to see a cheat sheet documenting the strictness output. It confuses me every time, even when I make the effort to read the source code that generates the demand signature! -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Fwd: ghc-7.6 branch
Hi Ian, On Thu, Jun 28, 2012 at 6:26 AM, Ian Lynagh ig...@earth.li wrote: You didn't give a clear answer to my question. Am I right in thinking that your answer would be Yes, the GHC release should be delayed indefinitely? I did answer it, just not with a yes or no as it's a false dichotomy. I gave you the 4 options that I think are reasonable. Perhaps someone could think of others, but those are the standard ones typically used by open source communities. (or at least, for long enough for the maintainer to be declared MIA) Something reasonable. Perhaps a few weeks to a month. Since this hasn't actually ever been a problem from what I can tell it doesn't matter much at this point. I had a quick look at the list of packages in question (http://hackage.haskell.org/trac/ghc/wiki/Repositories) and to my knowledge all these maintainers are around (and typically well-known contributors in the community.) I think the problem is one of misunderstanding how the process of managing dependencies ought to work (and how it works elsewhere.) We must release a new version of so-and-so lib because we made such-and-such change is wrong. Upstream changes (i.e. to GHC deps) ought to happen before downstream releases of dependent code (i.e. GHC.) This is actually the main reason that the situation between GHC and the libraries it uses is different to most other packages, both within Haskell and without: It is true that ghc depends on (for example) containers; but containers also depends on base, and base/ghc are so intertwined that they are essentially the same package (at least, I don't think you're suggesting that we should make separate base and ghc releases). That is what I mean by them being part of the same system. For example, I recently removed the 'catch' export from Prelude, and this required corresponding changes in Cabal, Win32 and haskeline. It's not possible to make the change in the base library without making the corresponding changes, or the GHC build would break, and there's no reason the maintainers of the other packages would make the change if I didn't ask them to. A more mundane example is library dependencies. If we make a change in filepath that requires bumping its major version, then we need libraries such as Cabal to relax their dependency on filepath or, again, the GHC build would break. Go ahead and make those changes to your local clones. That's reasonable. That in no way forces you to make releases of those packages. You have the time from you make the changes to the next GHC release to get the changes pushed upstream and released. Yes. Some of the upstreams respond so fast that it makes my head spin, while others often either don't respond or continually promise to get to things soon. (again, these are good, well-meaning people, who do a lot for the community). Have you tried pointing out that this is a problem for GHC and perhaps suggest that they let you make a release on their behalf? I believe this is the first time I've seen an email of this kind from GHC HQ. Generally these mails are all directly to maintainers. They're generally longer than this, but in essence it normally goes something like mail 1: Could you take a look at this patch please? mail 2: Did you have a minute to look at that patch? mail 3: I think the patch is good. Would it help if I pushed it for you? mail 4: This is blocking other things, so I'd like to push it. Please let me know within a week if you object (there may be multiple mail 2s, and mail 3 sometimes gets an affirmative response). Once this has happened a few times, we tend to suggest switching to a system where we just push by default, without the need for the mails and the delay (in fact, more-or-less what Gershom suggested). If the maintainer is fine with such a solution this is of course fine. But what if they're not? Note that this has nothing to do with releasing from HEAD, which GHC has typically done in the past. Such patches typically only require a patch release. P.S. The Haskell Platform is most likely moving to the complete opposite approach of what GHC uses; a call for version bumps will go out some time before the release and if maintainers don't ask to have their package version bumped, it will stay at the same version used for the last release. Cheers, Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Fwd: ghc-7.6 branch
On Thu, Jun 28, 2012 at 10:47 AM, Simon Peyton-Jones simo...@microsoft.com wrote: | Has maintainer's not being responsive been a problem for GHC in the | past? | | Yes. Some of the upstreams respond so fast that it makes my head spin, | while others often either don't respond or continually promise to get to | things soon. (again, these are good, well-meaning people, who do a lot | for the community). The obvious solution, as someone else pointed out, is for someone at GHC HQ (perhaps Ian) to be a co-maintainer of these critical dependencies -- except perhaps for libraries whose maintainers are the make your head spin responsive kind. This would of course need the maintainer to trust the GHC person to push patches and make releases in sync with GHC. But my guess is they'd be willing. After all, we're all on the same side here! That works for me. If maintainers want to delegate to GHC HQ (and GHC HQ has the bandwidth to deal with these releases) that is of course fine. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Fwd: ghc-7.6 branch
On Wed, Jun 27, 2012 at 3:20 AM, Paolo Capriotti p.caprio...@gmail.com wrote: On Wed, Jun 27, 2012 at 12:30 AM, Johan Tibell johan.tib...@gmail.com wrote: * Some libraries will need to have version bumps, which means that other libraries will need to loosen their dependencies, which means another release will be needed anyway GHC is no different that any other library here though. Library A is released and thus library B needs to be updated and released. The argument here is that the author of library A needs to make a release of the author of library B's package. The difference is that here the dependency is mutual, in a way. GHC needs library B to build, and library B needs to adapt to changes to GHC. Making a local change is not the same as making a release though. I make local changes to other people's code all the time, to unblock myself until the patches have made their way upstream. I'm not against that, I'm against releasing other people's code except they explicitly ask you to. That's not what I wrote, however. We are just creating branches at this stage. If we do make changes and need a version bump, we will coordinate again with the maintainer to ensure everything goes upstream normally. I know that's not what you wrote (hence the has not happened yet part.) But consider the scenario for a second. If GHC adds a new package as a dependency now all of a sudden the maintainer of that package is in a situation where he/she explicitly needs to state a preference to have someone else not make release versions of his/her package! It still makes sense for us to maintain a 'ghc-x.x' branch in each of the mirrored resositories. It doesn't have to mirror an upstream branch necessarily, but that's the easiest way to ensure all commits end up upstream. Except this is not what happens always. Commits have not always made it upstream in the past and sometimes packages released by GHC aren't uploaded to Hackage. The current workflow is: - library needs a change - make the change locally, validate, test - send the patch upstream This doesn't always happen. - wait for the patch to be integrated - pull changes into the corresponding GHC mirror Just amend - Before release, ask maintainer to make new release the package. and we'll be in the same situation of all other packages on Hackage. Using tags as you propose should also be possible, but it would require a release on the part of the library maintainer every time a change is made, and then we need to update our mirror and point it to the new tag. I don't really object to you having unreleased changes for shorter periods of time. Just you releasing them. The advantage would be that no revision of GHC ever depends an unreleased revision of a library, but is this really worth the extra trouble? Those intermediate releases are not particularly meaningful, and they may even end up being unusable with every released version of GHC. I don't think this is necessary. The problem is releasing other people's code, not having temporary deviating branches. P.S. All these problems will disappear once we have proper ACLs on Hackage, as at that point no one but the maintainer and people he/she gives permission to can upload his/her package to Hackage. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Fwd: ghc-7.6 branch
On Wed, Jun 27, 2012 at 8:12 AM, Ian Lynagh i...@well-typed.com wrote: On Tue, Jun 26, 2012 at 04:30:02PM -0700, Johan Tibell wrote: I just want to see things changed. :) We're happy to try to improve things, but I'm not sure what change you want exactly. I want GHC to stop releasing other people's code, unless they've explicitly asked GHC to do so. Other than that, you can do what you want. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Fwd: ghc-7.6 branch
Hi, On Wed, Jun 27, 2012 at 12:53 PM, Ian Lynagh ig...@earth.li wrote: If a GHC release needs an unreleased change in one of the libraries, and the maintainer (for whatever reason) is not responding to e-mails, should the GHC release be held up indefinitely? Again, note that GHC is no different from any other package here. If the maintainer is not responsive a person depending on his/her package can: 1) Try to convince him/her to become responsive. 2) Try to change the maintainer (this has happened for a few Hackage libraries, with the previous maintainer's approval usually.) 3) Drop the dependency. 4) Fork the package. This is how open source works outside GHC (including in different community's.) I don't see a need for doing anything differently here. Has maintainer's not being responsive been a problem for GHC in the past? I believe this is the first time I've seen an email of this kind from GHC HQ. If the answer is no, then there are going to be times when we need to ship GHC with a version of a library that is not yet released. With the best will in the world, there are always going to be people who are swamped by real life, people on vacation, or even people who unbeknownst to us have died. If people don't have time I'm sure they won't mind handing over maintenance to GHC HQ. I don't think it's OK to say if you're on vacation and don't reply in X days we're making a release of your package. Imagine if someone did that on Hackage: I really needed change X to your package to make my package work but since you didn't reply to my email I made the change and released a new version of your package. But all that is really tangential to the main issue: even if the answer to the above question is no, that does not mean that we need to routinely release libraries maintained by active upstreams. If upstream is responsive, then we can discuss with them what code to use and what releases need to be made. The original e-mail was intended to be the first in that discussion. Perhaps we phrased it badly, or perhaps you have bad memories of previous mistakes or of previous systems of releasing, but all we were trying to do is to find out what code we should set up the new stable branch to use. Phrasing aside, I think the problem is one of misunderstanding how the process of managing dependencies ought to work (and how it works elsewhere.) We must release a new version of so-and-so lib because we made such-and-such change is wrong. Upstream changes (i.e. to GHC deps) ought to happen before downstream releases of dependent code (i.e. GHC.) The current system is only possible due to GHC shipping libraries together with the compiler, several of it only uses internally to boot! This is not a theoretical issue. We have had all of the following problems happen in the past due to the current process: * patches never making it upstream * releases of libraries without knowledge of the maintainer (who finds out by finding a new version of his/her package on Hackage.) * packages being released by GHC never ending up on Hackage, causing build breakages for people who use older GHCs and can't install the packages as they aren't available on Hackage. Cheers, Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Fwd: ghc-7.6 branch
(Moving lots of people to BCC. If you want to follow this discussion it will continue on the glasgow-haskell-users@haskell.org list.) On Tue, Jun 26, 2012 at 3:40 PM, Ian Lynagh i...@well-typed.com wrote: Please attribute any blame to me, not Paolo; he's only doing what I asked him to :-) No blame to attribute. I just want to see things changed. :) When following option 1, I think starting from the HEAD rather than the last release makes sense in general: Maybe. It doesn't matter as I want (2). * Some of the recent changes may have been to make the library work with GHC HEAD, and will therefore be necessary to work with the 7.6 branch This works already today. I periodically get patches to e.g. network and containers to make it work with the current GHC HEAD. That seems to work fine. * Some libraries will need to have version bumps, which means that other libraries will need to loosen their dependencies, which means another release will be needed anyway GHC is no different that any other library here though. Library A is released and thus library B needs to be updated and released. The argument here is that the author of library A needs to make a release of the author of library B's package. so I think it's a reasonable default. But if it doesn't apply for a particular library, then no problem, just let us know - that's why we're e-mailing you :-) So at least don't make releases of containers (I think that's the only library I maintain that's released by GHC nowadays.) Can I please have this preference sticky in case I'm on vacation next time one of these emails go out? Aside: I don't believe this has happened yet but imagine the odd feeling of a library author, whose library was recently added as a GHC dependency, getting an email saying that if he/she doesn't reply GHC will make a release of his/her library! That sounds like it would also work. I assume there's some way to pull to a tag. git fetch (and thus pull) retrieves all branches and tags by default (and thus all commits pointed to by them.) Cheers, Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Is stderr flushed automatically after exceptions are printed
Hi, If a program throws an exception that will cause it to be terminated (i.e. the exception isn't caught), will the code that prints out the error message to stderr make sure to flush stderr before terminating the process? -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Explicit calls to the garbage collector.
Hi, On Mon, May 7, 2012 at 6:33 AM, Jurriaan Hage j.h...@uu.nl wrote: LS. I have a very memory intensive application. It seems that the timing of my application depend very much on the precise setting of -H...M in the runtime system (-H2000M seems to work best, computation time becomes a third of what I get when I pass no -H option). I conjecture that this good behaviour is the result of gc happening at the right time. So I wondered: if I can one when is the right time, is it possible then to trigger GC explicitly from within the Haskell code? You have to be very careful when benchmarking programs in garbage collected languages. If you set the nursery size high enough the GC might never run during your benchmark, but in a real program a big nursery might perform worse than a smaller one. For any small GC bound benchmark you can typically get it to run much faster by setting -A to some ridiculous high number. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Explicit calls to the garbage collector.
On Mon, May 7, 2012 at 7:00 AM, Christopher Done chrisd...@googlemail.com wrote: I would also be interested to know this. A web server is an example of a Haskell program that could force garbage collection at the end of every request reply, especially a multi-threaded server where the memory use is localized to threads. For long-running applications, a GC at this point would be nice. In non-GCed language people often use an arena allocator in situations like this. However, a semi-space collector (which is what we use) we get that behavior for free. If your request is processed in less time than the minor GC cycle, all your data will be dead by the time the GC run and thus collecting it is free. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Potential GSoC proposal: Reduce the speed gap between 'ghc -c' and 'ghc --make'
On Thu, Apr 26, 2012 at 2:34 PM, Mikhail Glushenkov the.dead.shall.r...@gmail.com wrote: Thanks. I'll look into how to optimise .hi loading by more traditional means, then. Lennart is working on speeding up the binary package (which I believe is used to decode the .hi files.) His work might benefit this effort. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: default instance for IsString
On Wed, Apr 25, 2012 at 8:19 AM, Tyson Whitehead twhiteh...@gmail.com wrote: Is there a technical reason this couldn't be done? The Haskell report only says doing this is not part of haskell. It doesn't say why. I think the problem is incoherence, what if the same Map value got used with two different instances of Int? -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: default instance for IsString
On Sun, Apr 22, 2012 at 10:37 AM, Brent Yorgey byor...@seas.upenn.edu wrote: I do not think this is a bug. Since type classes are open, GHC does not do any reasoning of the form X is the only instance in scope, so I will pick that one. Other instances could be added at any time (perhaps in other modules). In this particular instance, GHC has no reason to choose the Text instance other than the fact that it is the only instance in scope -- that is, type inference is not enough to determine that the Text instance should be chosen. However, I do agree that it would be nice to have a mechanism for specifying default instances for arbitrary (user-defined) type classes. Couldn't we make a special case for IsString, like we do for Num, given it's special syntactic association with OverloadedStrings? -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Invariants for GHC.Event ensureIOManagerIsRunning
The intention is that the I/O manager should start with the RTS. It's started in hs_init_ghc if you're running the threaded RTS. I don't know enough about using ghc as a library to know if it needs to be started in some other context as well. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Potential GSoC proposal: Reduce the speed gap between 'ghc -c' and 'ghc --make'
I for one think this would make a good GSoC project. Make sure you get your application in in time though. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Stealing ideas from the latest GCC release
Hi all,
While looking at the GCC 4.7 [1] release notes I saw something that's
perhaps worth stealing. Taken from the release notes:
The inter-procedural constant propagation pass has been rewritten. It
now performs generic function specialization. For example when
compiling the following:
void foo(bool flag)
{
if (flag)
... do something ...
else
... do something else ...
}
void bar (void)
{
foo (false);
foo (true);
foo (false);
foo (true);
foo (false);
foo (true);
}
GCC will now produce two copies of foo. One with flag being true,
while other with flag being false. This leads to performance
improvements previously possibly only by inlining all calls. Cloning
causes a lot less code size growth.
I found myself wanting something like this just today. A common
pattern I see in code is this:
data Options = Options { ... }
defaultOptions :: Options
defaultOptions = ...
foo :: ...
foo = fooWith defaultOptions
fooWith :: Options - ...
fooWith = ...
It'd be nice if we could get foo to specialize on its input arguments,
without having to mark all of fooWith as INLINE.
1. http://gcc.gnu.org/gcc-4.7/changes.html
-- Johan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Stealing ideas from the latest GCC release
On Thu, Mar 22, 2012 at 3:52 PM, Jan-Willem Maessen jmaes...@alum.mit.edu wrote: Wait, I thought this is essentially what constructor specialization does? I suppose we might then keep around the old body. Or will these behave differently in the presence of, say, different constant Int arguments? We do want to keep around the old body (but constructor specialization already does that.) We also want to be able to specialize things like 5 :: Int, which I don't think constructor specialization handles. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
