Re: [ANNOUNCE] GHC 8.0.1 source tarball available
2016-05-13 7:55 GMT+02:00 Páli Gábor János : > That is probably because FreeBSD has GNU make(1) as `gmake`, it should > be invoked with that name. I suspect that, for some reason (which is > unknown to me), the value of the $(MAKE) variable is not respected at > the recursive invocation of make(1). > > Unfortunately, I will not have the time to figure this out today, so I > am just reporting this without a proposal for the fix. Ohh, I was quick to surrender: all you have to do is to s/make/$(MAKE)/ in line 22 at utils/haddock/doc/ghc.mk. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [ANNOUNCE] GHC 8.0.1 source tarball available
Hi there, 2016-05-12 12:47 GMT+02:00 Ben Gamari : > Ben Gamari writes: > Sorry about the false start earlier. It seems there were a few tricky > bits in the integration between haddock and GHC's build system that > weren't quite right. This should be fixed now. I have tried to build the source tarball on FreeBSD, but it always stops somewhere around the documentation bits with the following error message: [..] make -C utils/haddock/doc html SPHINX_BUILD=/usr/local/bin/sphinx-build make: illegal option -- - usage: make [-BPSXeiknpqrstv] [-C directory] [-D variable] [-d flags] [-E variable] [-f makefile] [-I directory] [-j max_jobs] [-m directory] [-V variable] [variable=value] [target ...] utils/haddock/doc/ghc.mk:22: recipe for target 'html_utils/haddock/doc' failed gmake[1]: *** [html_utils/haddock/doc] Error 2 Makefile:129: recipe for target 'all' failed gmake: *** [all] Error 2 That is probably because FreeBSD has GNU make(1) as `gmake`, it should be invoked with that name. I suspect that, for some reason (which is unknown to me), the value of the $(MAKE) variable is not respected at the recursive invocation of make(1). Unfortunately, I will not have the time to figure this out today, so I am just reporting this without a proposal for the fix. Thanks, Gábor ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Stop rejecting Summary: Signed-off-by: ... OR patch Phabricator
Hey guys, Currently the commit hooks reject commit messages that look like: Summary: Signed-off-by: Edward Z. Yang Unfortunately, if I do a one line commit message with -s, Phabricator will automatically reformat my message to have this. This is dumb. Either: 1) You should stop rejecting these commit messages, or 2) You should patch Phabricator to stop munging the messages this way. The message formatting is done server-side so as a client I have no way of changing it, you need to fix it. This URL has some guidance on how to do it: https://secure.phabricator.com/T6055 I'd offer to edit the hook myself but there does not seem to be any canonical location where the hooks are versioned. Thanks, Edward ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [ANNOUNCE] GHC 8.0.1 source tarball available
my built with the fresher tarball (matching the md5 sum that herbert mentions) is at https://wellposed-carter-files.s3.amazonaws.com/opensource/ghc/releasebuild-unofficial/ghc-8.0.1-x86_64-apple-darwin-built-with-gcc5.tar.xz and the sha info is shasum -a512 ghc-8.0.1-x86_64-apple-darwin-built-with-gcc5.tar.xz e6a1688e4bdb96328f866ec79bb6182e3d49833a86099026078effa3556d5d96832a10e095a0fe92d35480fbe243f6472c3361217955ac0e758ea6814cd295bd On Thu, May 12, 2016 at 6:52 AM, Herbert Valerio Riedel wrote: > On 2016-05-12 at 12:47:05 +0200, Ben Gamari wrote: > > [...] > > > I've pushed the result to the ghc-8.0 branch and have pushed a set of > > new source tarballs to the usual URL. The new release commit is > > > > b594f8191273f4c913bc8413d30fd3061bb577c1 > > fyi, an easy way to verify you have the intended tarball is: > > $ tar xOf ghc-8.0.1-src.tar.xz ghc-8.0.1/GIT_COMMIT_ID; echo > e99c1e2516aeb283172c7e6898508238e33cf065 > > (that's the old one) > > > PS: I've just been told the md5sum of the new tarball is > 94da3386c0de519eeea37586edd90187 > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Mentor for a JVM backend for GHC
Hi Alois, I can see a nice feedback loop between GHCVM and Kuna that can help accelerate both projects. Let's this discuss offline so that this thread isn't flooded with a discussion that will probably get lost in time later? We'll try to keep the results of our discussions public, either in the GHCVM Wiki or elsewhere so that people know what's going on. Thanks, Rahul On Wed, May 11, 2016 at 4:40 PM, Aloïs Cochard wrote: > Hi Rahul, > > Thanks for the feedback, and good to hear you are thinking about using it > as an assembler! > First thing I'll have to do is to extract the assembler itself from > "Kuna", so it can be reused by yourself. I'll be happy to give support and > implement new features as needed, I know some important operations are > still missing but have a clear idea how to ad dthem. > > Then a bit of history, where this project comes from, and why it had no > commit since December... > > Long story short, I got trapped working on a FP library in Scala, and had > left this project aside in the meantime (had strong interest from folks > asking for me to look into this Scala stuff, and at the time not much > interest in Kuna... which the opposite of my personal preference... so I > was extremely happy to read your initial message here!). > > Now back to our common interest, the reason I "chose" Core, it's because > it seems fundamentally impossible to avoid having an interpreter in order > to get stack safe execution of STG on the JVM. That is a fundamental > limitation, that is the core thing I want to experiment with... Creating a > JVM assembler and a minimal Lambda core calculus was kind of just an excuse > to get to this core issue (I'm thinking about control flow analysis and > complex program transformation/optimization in order to get there). > > That being said, the path I would like to take is quite complex, full of > unknowns, I would love to share the ideas I have in mind, but I fear it > might be out of scope of your actual goal: getting a workable > implementation ASAP. > > So, I suppose you are fine writing a small (hopefully performant) STG-like > Java interpreter used during runtime (that's basically what I'm trying to > avoid with my experiment), which I think is a reasonable path to follow in > order to get a GHC JVM implementation soon. I would be very interested to > help you on this, first by giving support on the JVM assembler (that will > be extracted from Kuna), then also by proposing myself as a mentor. I'm not > sure exactly how things goes there, how the process is handled... but I'll > learn about it, I did notify Edward Kmett of my interest. > > My gut feeling is that it should be fine to use STG with the approach you > follow, I also feel some technics could be shared between GHC JVM and the > Kuna experiment (where the later could be seen as the a sandbox/test-bed > for the former). > > Anyway as you said: "Again, all these issues can be looked at once a > performance baseline has been established.". > > Totally agree, that's why I don't want to share too much of my > experimental ideas atm, let's focus on a realistic initial implementation > (for which I have lot of ideas to share as well). Again, I'm ready to > assist you as much as possible, implementation missing features in the > assembler, I already read so much of this specification. ;-) > > In case you are using IRC/IM/Gitter let me knows, so we could discuss more > directly. > > Looking forward hearing from you, > > Aloïs > > > On 10 May 2016 at 04:43, wrote: > >> Hi Alois, >> >> I just checked out Kuna, and it looks like a great project. For others >> the link to the repo is https://github.com/aloiscochard/kuna. I think >> I'll go with it since not having to implement StackMapTables will save me a >> lot of time. >> >> I'm interested in your approach, can you explain more, especially the >> stack-safe bytecode part? And I noticed the last commit was in December. Is >> there any particular reason you stopped the project? >> >> I chose STG over Core because Core has an embedded language of coercions >> which complicates the code generation (or maybe they can simply be >> ignored?), and the terms are not in administrative normal form which >> requires more effort to manage. But a thought did cross my mind that >> certain Core optimizations might actually need to be turned off because >> the resulting STG might be in a form that might not get translated to the >> most efficient JVM bytecode. Again, all these issues can be looked at once >> a performance baseline has been established. >> >> Thanks, >> Rahul Muttineni >> >> Sent from my BlackBerry 10 smartphone. >> *From: *Alois Cochard >> *Sent: *Monday 9 May 2016 10:21 PM >> *To: *Edward Kmett >> *Cc: *ghc-devs@haskell.org >> *Subject: *Re: Mentor for a JVM backend for GHC >> >> Totally agree, Cmm is too late. >> >> My aim in Kuna was to start the transformation from Core, targeting >> stack-safe JVM bytecode without using Graal or the like. >>
Re: [ANNOUNCE] GHC 8.0.1 source tarball available
On 2016-05-12 at 12:47:05 +0200, Ben Gamari wrote: [...] > I've pushed the result to the ghc-8.0 branch and have pushed a set of > new source tarballs to the usual URL. The new release commit is > > b594f8191273f4c913bc8413d30fd3061bb577c1 fyi, an easy way to verify you have the intended tarball is: $ tar xOf ghc-8.0.1-src.tar.xz ghc-8.0.1/GIT_COMMIT_ID; echo e99c1e2516aeb283172c7e6898508238e33cf065 (that's the old one) PS: I've just been told the md5sum of the new tarball is 94da3386c0de519eeea37586edd90187 pgp0cXZLYZgay.pgp Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [ANNOUNCE] GHC 8.0.1 source tarball available
Ben Gamari writes: > [ Unknown signature status ] >> [ Unknown signature status ] > tl;dr: If you would like to produce a binary distribution for GHC >8.0.1 then let us know, grab the source distribution and start >building. The binary distributions will be all released one week >from today. > > > Hello GHC packagers, > > I am happy to at long last announce the release of the 8.0.1 source > distribution to binary packagers. You will find the usual artifacts at > > http://downloads.haskell.org/~ghc/8.0.1/ > > These tarballs are derived from GHC commit > Sorry about the false start earlier. It seems there were a few tricky bits in the integration between haddock and GHC's build system that weren't quite right. This should be fixed now. I've pushed the result to the ghc-8.0 branch and have pushed a set of new source tarballs to the usual URL. The new release commit is b594f8191273f4c913bc8413d30fd3061bb577c1 Again, I'll hold off a bit longer in pushing the tag in case there are further issues. As always, let me know if you have any issues (and thanks to those who alerted me of the Haddock issue). Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
