RE: Building ghc on Windows with msys2
I think the potential difficulty is (1). Maybe they take it down (e.g. they move on to version X so they take down old version Y). An alternative would be to stash a copy somewhere on GHC’s main web server, and wget that. I’d be more comfortable doing that; less dependence on others. but I am a babe in these particular woods, and defer to others wisdom. Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Gintautas Miliauskas Sent: 12 October 2014 23:06 To: kyra Cc: ghc-devs@haskell.org Subject: Re: Building ghc on Windows with msys2 However, overall (not GHC use cases) gcc 4.9.1 still looks more buggy on Windows than 4.8.3. 'Mingw-builds' project (which is now a part of mingw-w64 project and is considered to be an official mingw-w64 gcc distribution and is maintained by a man close to Msys2 project) has very nice and complete build of 4.8.3 (64-bit build, for example, is here: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.8.3/threads-posix/seh/). I am looking into migrating ghc to the newer gcc package linked above. There is also the associated question of what to do with ghc-tarballs. Here's an idea: how about downloading the mingw package directly from sourceforge at configure time with curl/wget? That should work pretty well. I see two potential issues: 1. URL stability. The sourceforge repo is not in our control and files in it could go away any time. The repo seems stable though, with some files from 2011. If we're concerned about this, copying the file to a domain under our control should not be a problem. I did not get any responses about who to contact about that though... 2. Download failing due to internet connectivity issues or missing proxy configuration. This could easily be addressed by printing a message with a URL and a filesystem location to put the file in the case that the download fails. If there are no objections, I'll proceed with whipping up a patch. -- Gintautas Miliauskas ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
GHC HEAD breakage by pthread_setname_np usage.
Hello Simon, I'm sorry to disturb you, but your recent patch: commit 674c631ea111233daa929ef63500d75ba0db8858 Author: Simon Marlow marlo...@gmail.com Date: Fri Oct 10 14:26:19 2014 +0100 Name worker threads using pthread_setname_np This helps identify threads in gdb particularly in processes with a lot of threads. breaks build on FreeBSD and Solaris at least. The problem is that pthread_setname_np is GNU extension and so far I've seen it just in linux using glibc =2.12, modern NetBSD and modern QNX. Builds on Solaris and FreeBSD result in unresolved symbol failure. Two examples showing this are here: http://haskell.inf.elte.hu/builders/smartos-x86-head/147/10.html http://haskell.inf.elte.hu/builders/freebsd-amd64-head/411/10.html The problem is that I cannot simply #ifdef usage of this since it's using `name' parameter of the createOSThread function and if I #ifdef this, then the compiler emits obvious warning: rts/posix/OSThreads.c: In function ‘createOSThread’: rts/posix/OSThreads.c:132:40: warning: unused parameter ‘name’ which is probably going to break validate build which builds with -Werror. Perhaps if pthread_setname_np is not available on the target platform we can define it ourself (as empty macro or inline function doing nothing?) and use that, but in this case we would probably need proper configure check for the presence of this function. As rts is your domain, I'm just writing this in a hope that you will either revert the patch for now or solve it in a way you like. Thanks! Karel ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC HEAD breakage by pthread_setname_np usage.
Thanks for letting me know, I'll add a configure test to check for this. Cheers, Simon On 13/10/2014 10:12, Karel Gardas wrote: Hello Simon, I'm sorry to disturb you, but your recent patch: commit 674c631ea111233daa929ef63500d75ba0db8858 Author: Simon Marlow marlo...@gmail.com Date: Fri Oct 10 14:26:19 2014 +0100 Name worker threads using pthread_setname_np This helps identify threads in gdb particularly in processes with a lot of threads. breaks build on FreeBSD and Solaris at least. The problem is that pthread_setname_np is GNU extension and so far I've seen it just in linux using glibc =2.12, modern NetBSD and modern QNX. Builds on Solaris and FreeBSD result in unresolved symbol failure. Two examples showing this are here: http://haskell.inf.elte.hu/builders/smartos-x86-head/147/10.html http://haskell.inf.elte.hu/builders/freebsd-amd64-head/411/10.html The problem is that I cannot simply #ifdef usage of this since it's using `name' parameter of the createOSThread function and if I #ifdef this, then the compiler emits obvious warning: rts/posix/OSThreads.c: In function ‘createOSThread’: rts/posix/OSThreads.c:132:40: warning: unused parameter ‘name’ which is probably going to break validate build which builds with -Werror. Perhaps if pthread_setname_np is not available on the target platform we can define it ourself (as empty macro or inline function doing nothing?) and use that, but in this case we would probably need proper configure check for the presence of this function. As rts is your domain, I'm just writing this in a hope that you will either revert the patch for now or solve it in a way you like. Thanks! Karel ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Building ghc on Windows with msys2
On 2014-10-13 at 10:57:10 +0200, Simon Peyton Jones wrote: I think the potential difficulty is (1). Maybe they take it down (e.g. they move on to version X so they take down old version Y). An alternative would be to stash a copy somewhere on GHC’s main web server, and wget that. I’d be more comfortable doing that; less dependence on others. I guess storing a copy somewhere on https://ghc.haskell.org/ should be ok (I'm hoping Austin may weigh in wrt CDN-related considerations). I'd suggest using it as a fallback location though. I.e. try downloading from the official upstream location, and if that fails (either due to I/O errors and/or unexpected checksum), fallback to using our locally mirrored copy. However, we may need to take into account license issues, such as hosting the source-code as well, if we host binary distributions depending on the licenses involved (I'm not sure if this was ever considered for ghc-tarballs.git to begin with) Cheers, hvr ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions
Ok, will do.
An integer can potentially have any number of leading zeros, and I will
have to check what escaping exists in the others.
On Mon, Oct 13, 2014 at 11:33 AM, GHC ghc-devs@haskell.org wrote:
#9628: Add Annotations to the AST to simplify source to source conversions
-+-
Reporter: alanz |Owner: alanz
Type: feature | Status: new
request|Milestone:
Priority: normal | Version: 7.9
Component: Compiler| Keywords:
Resolution: | Architecture: Unknown/Multiple
Operating System: | Difficulty: Unknown
Unknown/Multiple | Blocked By:
Type of failure: | Related Tickets:
None/Unknown |
Test Case: |
Blocking: |
Differential Revisions: D297|
-+-
Comment (by simonpj):
I suggest doing so only if the two can differ. In the case of `String`
there can be string gaps, thus
{{{
foo :: String
foo = blah blah\
\more blah blah\
\and more
}}}
and I guess you want to have all that layout reproduced. Fine. But for
integers like `3234242329423`, I don't see how the displayed form could
differ.
For `Words` perhaps there is binary/hex forms?
Regardless, I'm not against this, but very keen that the reasons for
keeping the two are documented on a per-literal basis, as I have begun to
do above.
--
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9628#comment:29
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Building ghc on Windows with msys2
Thank you, that is brilliant. Simon From: Gintautas Miliauskas [mailto:gintautas.miliaus...@gmail.com] Sent: 10 October 2014 21:01 To: Simon Peyton Jones Cc: loneti...@gmail.com; Randy Polen; kyra; Marek Wawrzos; Roman Kuznetsov; Neil Mitchell; ghc-devs@haskell.org Subject: Re: Building ghc on Windows with msys2 Hey, I have created https://ghc.haskell.org/trac/ghc/wiki/WindowsTaskForce, and added the two people from whom I heard a confirmation that they want to be on the list. Please edit the page and add yourself if you should be on that list. Feel free to hack the page up and add additional info as you see fit. On Thu, Oct 9, 2014 at 9:51 AM, Simon Peyton Jones simo...@microsoft.commailto:simo...@microsoft.com wrote: I think I’m fairly behind on the current build process of GHC, but as I do use GHC mainly on Windows, at such a time as you would like to move on to other things, I would certainly throw my hat In the ring. That sounds helpful, thank you. Are we at the point where we could form a GHC-on-Windows Task Force? With its own wiki page on the GHC Trac, and with named participants. (Of course you can drop off again.) But it would be really helpful to have an explicit group who feels a sense of ownership about making sure GHC works well on Windows. At the moment we are reduced to folk memory “I recall that Gintautas did something like that a few months ago”. It sounds as if Tamar would be a willing member. Would anyone else be willing? I’d say that being a member indicates a positive willingness to help others, along with some level of expertise, NOT a promise to drop everything to attend to someone else’s problem. Simon From: loneti...@gmail.commailto:loneti...@gmail.com [mailto:loneti...@gmail.commailto:loneti...@gmail.com] Sent: 09 October 2014 06:04 To: Gintautas Miliauskas; Simon Peyton Jones Cc: Randy Polen; kyra; Marek Wawrzos; Roman Kuznetsov; Neil Mitchell; ghc-devs@haskell.orgmailto:ghc-devs@haskell.org Subject: Re: Building ghc on Windows with msys2 Hi Gintautas, Indeed, the next thing I was going to ask was about expediting the decision process. I would be happy to try and coordinate a push in Windows matters. There is a caveat though: I don't have any skin in the GHC-on-Windows game, so I will want to move on to other things afterwards. I think I’m fairly behind on the current build process of GHC, but as I do use GHC mainly on Windows, at such a time as you would like to move on to other things, I would certainly throw my hat In the ring. Cheers, Tamar From: Gintautas Miliauskasmailto:gintautas.miliaus...@gmail.com Sent: Thursday, October 2, 2014 22:32 To: Simon Peyton Jonesmailto:simo...@microsoft.com Cc: Randy Polenmailto:randyhask...@outlook.com, kyramailto:ky...@mail.ru, Marek Wawrzosmailto:marek.28...@gmail.com, Tamar Christinamailto:loneti...@gmail.com, Roman Kuznetsovmailto:kuzn...@hotmail.com, Neil Mitchellmailto:ndmitch...@gmail.com, ghc-devs@haskell.orgmailto:ghc-devs@haskell.org Hi, All we need is someone to act as convenor/coordinator and we are good to go. Would any of you be willing to play that role? Indeed, the next thing I was going to ask was about expediting the decision process. I would be happy to try and coordinate a push in Windows matters. There is a caveat though: I don't have any skin in the GHC-on-Windows game, so I will want to move on to other things afterwards. An advantage of having a working group is that you can decide things. At the moment people often wait for GHC HQ to make a decision, and end up waiting a long time. It would be better if a working group was responsible for the GHC-on-Windows build and then if (say) you want to mandate msys2, you can go ahead and mandate it. Well, obviously consult ghc-devs for advice, but you are in the lead. Does that make sense? Sounds great. The question still remains about making changes to code: is there a particular person with commit rights that we could lean on for code reviews and committing changes to the main repository? I think an early task is to replace what Neil Mitchell encountered: FIVE different wiki pages describing how to build GHC on Windows. We want just one! (Others can perhaps be marked “out of date/archive” rather than deleted, but it should be clear which is the main choice.) Indeed, it's a bit of a mess. I intended to shape up the msys2 page to serve as the default, but wanted to see more testing done before before dropping the other pages. I agree with using msys2 as the main choice. (I’m using it myself.) It may be that Gintautas’s page https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2 is already sufficient. Although I’d like to see it tested by others. For example, I found that it was CRUCIAL to set MSYSYSTEM=MINGW whereas Gintautas’s page says nothing about that. Are you sure that is a problem? The page specifically instructs to use the msys64_shell.bat
Re: ExtraCommas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Just to let everyone know ExtraCommas is still alive: Alan and I just had a pleasant chat as alluded to in the forwarded message below. Despite being busy with other engagements lately, I am now picking up the ExtraCommas work again. I will be operating on the same level as Alan is in his work, and we'll be colliding a bit, no doubt. As such I will make efforts to collaborate with Alan in making the merge process nice before I submit any patches to phab. My plan now is simply: -hack around and get confident with the hsSyn code (I am quite confident in the Happy code already), -make a Wiki article with my idea and the details, -hack hack hack, -work with Alan to make sure merging is smooth, - finally, submit a patch (or several). - -Alexander - Original Message Subject: Re: Capturing commas in the GHC parser Date: Mon, 13 Oct 2014 13:37:28 +0200 From: Alan Kim Zimmerman alan.z...@gmail.com To: Alexander Berntsen alexan...@plaimi.net On Mon, Oct 13, 2014 at 12:30 PM, Alexander Berntsen alexan...@plaimi.net wrote: Hallo Alan, I've been away for a week on a conference. In my absence I see you have made some posts about capturing commas in API annotations. Prior to leaving I was working on an ExtraCommas language pragma. I had accomplished trailing leading commas for signature variables, fixity declarations, list expressions, import export declarations, record updates, record declaration maybe more that I don't remember. The way I had accomplished this was by manually editing the happy code. SPJ showed me that I should have been messing about a level up, like you are doing. Consequently, I have a few questions. How much does your work overlap with what I am doing? How far have you come? Do you have some advice for what I want to do? If we could schedule a little meeting for us to have a chat via instant messaging, that would be great. I am on irc.freenode.net as bernalex, on XMPP via alexanderbernt...@dukgo.com, and you can call me via SIP if you want to do audio/video chat using alexan...@sip.linphone.org. Hi I am alanz on freenode, and alan.z...@gmail.com which may still come through on XMPP via hangouts. I actually did a large part of working a HsCommaList through the AST, including all the subsequent phases (renamer,typechecker etc), but have since backed it out as I was misusing the structure firstly, and I had come up with another means of doing it. My last commit with this in is https://github.com/alanz/ghc/tree/b970d42e1e6bc46077a60a602413d990615e3896 As you can see it is quite a far-reaching change, and mingled in with my annotations stuff too. I will be happy to talk to you about this, because it makes sense for our stuff to work together, otherwise it will be much harder to merge at a later date. I am hoping to get my annotation changes to the AST and parser firmed up this week, so that I can then just try to work with it to see that I have everything captured. Is there a place I can see what you have done? Regards Alan -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlQ72icACgkQRtClrXBQc7XtzwEAt2zTN8AVkY6Jox75TcyFG9Ks l26QndI+gvszGao89xEA/RfYpGMEarMB4tM2mtIZDI3dE53LC64zOnHfzE7N3G7f =FViZ -END PGP SIGNATURE- ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
GHC 7.8.4: call for tickets, show stoppers, and timelines - oh my!
Hi *, After some discussion with Simon Mikolaj today, I'd like to direct you all at this: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8.4 This status page is the basic overview of what we plan on doing for 7.8.4. There are two basic components to this page: - Show stopping bugs. - Everything else, which is nice to have. Show stoppers are listed at the top of the page, in the first paragraph. Right now, this includes: - #9439 - LLVM mangling too vigorously. - #8819 - Arithmetic failures for unregistered systems - #8690 - SpecConstr blow-up And that's all. But what's all the other stuff? That's everything else. Aside from these tickets listed here - and any future amendments to it - all other tickets will only be considered nice-to-have. What does that mean? - It's low risk to include. - It clearly fixes the problem - It doesn't take Austin significant amounts of time to merge. For example, Tickets marked merge with no milestone are all nice-to-have. Similarly, all the *closed tickets* on this page may be re-opened and merged again[1], since most didn't make it to 7.8.4. Ditto with the remaining categories. OK, so that's the gist. Now I ask of you the following: - If you have a show-stopping bug with GHC 7.8.3, **you really, _positively_ need to file a bug, and get in contact with me ASAP**. Otherwise you'll be waiting for 7.10 most likely. - Again: if you have a show stopper, contact me. Very soon. - If there are bugs you *think* are showstoppers, but we didn't categorize them properly, let me know. Anything we accept as a show-stopper will delay the release of 7.8.4. Anything else can (and possibly will) be left behind. Luckily, almost all of the show stoppers have patches. Only #8819 does not, but I have asked Sergei to look into it for me if he has time today. Finally, I would please ask that users/developers do not include their own personal pet tickets under show stoppers without consulting me first, at least. :) If it's just nice to have, you can still pester me, of course, and I'll try to make it happen. I would like to have 7.8.4 out and done with by mid November, before we freeze the new STABLE branch for 7.10.1. That's not a hard deadline; just a timeframe I'd like to hit. Let me know if you have any questions or comments; thanks! [1] A lot of the closed tickets on this page had an improper milestone set, which is why they show up. You can mostly ignore them, I apologize. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: One-shot semantics in GHC event manager
Ben Gamari bgamari.f...@gmail.com writes: Andreas Voellmy andreas.voel...@gmail.com writes: On Sat, Oct 11, 2014 at 12:17 PM, Ben Gamari bgamari.f...@gmail.com wrote: Ah... so this is not useful to you. I guess we could add `loop` to GHC.Event's export list. On the other hand, I like your LifeTime proposal better and then no one needs `loop`, so let's try this first. I have a first cut of this here [1]. It compiles but would be I shocked if it ran. All of the pieces are there but I need to change EventLifetime to a more efficient encoding (there's no reason why it needs to be more than an Int). As it turns out the patch seems to get through the testsuite after a few minor fixes. What other tests can I subject this to? I'm afraid I don't have the access to any machine even close to the size of those that the original event manager was tested on so checking for performance regressions will be difficult. Cheers, - Ben pgpzECC_p7Qyi.pgp Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Building ghc on Windows with msys2
I've updated the configure script to download the mingw distribution on the fly (D339 https://phabricator.haskell.org/D339, #9218 https://ghc.haskell.org/trac/ghc/ticket/9218). I could use some help with a few things: 1. Validating the update to gcc 4.8.3. I tried to run the tests and got some failures, but I am not sure if they indicate problems with gcc or it's just noise. 2. Some general testing of the updated configure script. 3. Testing the build process on a 32-bit platform. 4. Setup of a local mirror of the distribution files on haskell.org. On Mon, Oct 13, 2014 at 11:34 AM, Herbert Valerio Riedel hvrie...@gmail.com wrote: On 2014-10-13 at 10:57:10 +0200, Simon Peyton Jones wrote: I think the potential difficulty is (1). Maybe they take it down (e.g. they move on to version X so they take down old version Y). An alternative would be to stash a copy somewhere on GHC’s main web server, and wget that. I’d be more comfortable doing that; less dependence on others. I guess storing a copy somewhere on https://ghc.haskell.org/ should be ok (I'm hoping Austin may weigh in wrt CDN-related considerations). I'd suggest using it as a fallback location though. I.e. try downloading from the official upstream location, and if that fails (either due to I/O errors and/or unexpected checksum), fallback to using our locally mirrored copy. However, we may need to take into account license issues, such as hosting the source-code as well, if we host binary distributions depending on the licenses involved (I'm not sure if this was ever considered for ghc-tarballs.git to begin with) Cheers, hvr -- Gintautas Miliauskas ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: One-shot semantics in GHC event manager
For the record, I talked to Ben earlier on IRC, and I can provide him with a machine to do intense benchmarks of the new I/O manager. Also, if any other developers (like Andreas, Johan, Bryan, etc) in this space want a big machine to test it on, I can probably equip you with one (or several). Since Rackspace is so gracious to us, we can immediately allocate high-powered, physical (i.e. not Xen, but real machines) machines to do high-scale testing on.[1] In any case, it's not hard to do and only takes a few minutes, so Ben: let me know. (I've thought it would be neat to implement a leasing system somehow, where a developer could lease a few machines for a short period of time, at which point they expire and a background job cleans them up.) [1] You can find the hardware specs here; GHC benchmarking is probably best suited for the OnMetal I/O type, which has 40 cores, 2x PCIe flash and 128GB of RAM - http://www.rackspace.com/cloud/servers/onmetal/ On Mon, Oct 13, 2014 at 2:05 PM, Ben Gamari bgamari.f...@gmail.com wrote: Ben Gamari bgamari.f...@gmail.com writes: Andreas Voellmy andreas.voel...@gmail.com writes: On Sat, Oct 11, 2014 at 12:17 PM, Ben Gamari bgamari.f...@gmail.com wrote: Ah... so this is not useful to you. I guess we could add `loop` to GHC.Event's export list. On the other hand, I like your LifeTime proposal better and then no one needs `loop`, so let's try this first. I have a first cut of this here [1]. It compiles but would be I shocked if it ran. All of the pieces are there but I need to change EventLifetime to a more efficient encoding (there's no reason why it needs to be more than an Int). As it turns out the patch seems to get through the testsuite after a few minor fixes. What other tests can I subject this to? I'm afraid I don't have the access to any machine even close to the size of those that the original event manager was tested on so checking for performance regressions will be difficult. Cheers, - Ben ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
