GF release 3.11

Question

GF release 3.11

johnjcamilleri opened this issue 4 years ago · 31 comments

It feels like the time is becoming [over?]ripe for a new GF release. There's a number of issues/suggestions that I think should be discussed, which is the purpose of this issue.

Version number and milestones

I guess 3.11 should be the next version, that's probably uncontroversial.
We need to decide what milestones we want included in the release. I can think of at least 2 which @inariksit has mentioned elsewhere:

Fix all issues related to MonadFail update
Get the testsuite working again

Also, the GF binaries include pre-compiled RGL, so we need to decide if there are any upcoming RGL milestones which should block the release.

Release recipe

I think we should document the exact steps to make a release in some appropriately named file like RELEASE.md.
Previously @Thomas-H has taken care of releases, but since he is no longer actively working with GF it is even more important that all information is recorded somewhere.

Some things which this needs to include:

Bumping version numbers (and temporarily removing the -git suffix in gf.cabal)
Updates to web page (various places)
Uploading to Hackage

Hosting binaries on GitHub

Until now, the binaries have been built locally by Thomas and then uploaded to www.grammaticalframework.org. I believe that for the next release, we should have everything built on GitHub and host the binaries there too. Of course we can copy them to the GF server, in case we one day do not use GitHub anymore, but the recent GF server outage has shown that we need to have them stored elsewhere.

I have written GitHub Actions workflows for building Debian and macOS packages (the latter still needs some work). I am hoping it will then be easy to attach those generated artifacts to the releases in GitHub although I don't know too much about this, maybe someone else is willing to help out here.

Answer 1 · 2020-11-11T07:31:58.000Z

Yes, definitely time for a release! Thanks for the initiative 🎉
I agree with your suggestions, here are a few comments on milestones.

Milestones

Test suite fixing is happening here, looking good except for some problems with the RGL path.
Regarding RGL milestones, I think @bamutra is actively developing Runyankore resource grammar. How is that development looking, would it make sense to wait for some significant improvements for a new release, or just take it in whatever shape it is?

(Anyone else who is working on RGL, let us know if you're in the middle of something, or just discovered a massive bug you want to fix for the release!)

Answer 2 · 2020-11-11T07:52:22.000Z

Yes, an excellent initiative! If this version is 3.11 then the next one will of course be GF 95 😊 Bringing the test suite up to date and hosting binaries on GitHub are excellent ideas. How is it with the main web page? Should it also be hosted on GitHub? To avoid downtimes and minimize maintenance load. This would not solve it for the GF Cloud, but would at least guarantee access to the other things. Somehow I don't think RGL should stop releases, since it is an independent project following lots of parallel tracks. My own plan is to work on the Extend module, at last, now to make sure it can implement what is needed in the ParseExtend module in gf-wordnet. This would speed up porting the WordNet grammar to new languages and eliminate duplicate work. The gf-wordnet grammar and lexicon itself is taking the role that the wide-coverage translator once had. But I think it should also be seen independently of GF, and also of RGL. Morphological lexica is another project I have been gradually developing, and I think it should become a part of the standard RGL, so that one can easily pick words with their inflections, using native names as keys. This is simply an extension of the Irreg modules, where all we care about are the morphological properties of words, not their senses, English equivalents, or subcategorization patterns (which is done in gf-wordnet). When working with application grammars, I find myself constantly importing these dictionaries, and have to create specific paths for them since they are not in the standard RGL yet. The emerging modules are in gf-rgl/src/morphodict/. Needless to say, GF 3.11 should not wait for this project either. Regards Aarne.

…

________________________________ From: Inari Listenmaa <notifications@github.com> Sent: Wednesday, November 11, 2020 8:32:12 AM To: GrammaticalFramework/gf-core Cc: Subscribed Subject: Re: [GrammaticalFramework/gf-core] Next GF release (#85) Yes, definitely time for a release! Thanks for the initiative 🎉 I agree with your suggestions, here are a few comments on milestones. Milestones * Test suite fixing is happening here<https://github.com/kharus/gf-core/tree/enable-tests>, looking good except for some problems with the RGL path. * Regarding RGL milestones, I think @bamutra<https://github.com/bamutra> is actively developing Runyankore resource grammar. How is that development looking, would it make sense to wait for some significant improvements for a new release, or just take it in whatever shape it is? (Anyone else who is working on RGL, let us know if you're in the middle of something, or just discovered a massive bug you want to fix for the release!) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#85 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAWBQXNQGKQJKQOTK3TIX4LSPI4XZANCNFSM4TRBQEJQ>.

Answer 3 · 2020-11-11T20:27:47.000Z

A bolder suggestion is then that the GF packages should not include any RGL at all. To me this makes more sense than including a snapshot of whatever the RGL happened to be on the day of the release, and reinforces the separation between the projects. Actually, as I look into it, this is already the case for some of the packages, e.g. the Debian package contains no RGL but the Windows one does, even though this information is not actually communicated on the GF download page. So, my suggestion is that to make everything consistent, we provide the following GF binary packages, none of which include RGL:

macOS (.pkg)
This is built using make pkg, I am working on a GitHub Actions workflow which does this (here).
Debian (.deb)
This is built using make deb, I wrote a workflow which does this (here) although I don't know how to produce both 32-bit and 64-bit versions.
Windows (.zip)
I'm not sure how this is built, there doesn't seem to be any script for this in the repository. I can start experimenting with a workflow for this too but will likely need some help.

Notably: I don't know why there currently is a GF binary for Raspbian, and I think we should drop it since I don't know to create it and I don't know if there's any demand for it.

In addition to the above, we also need to set up a GitHub Actions workflow in the gf-rgl repository which builds compiled versions of the RGL, and then have some sort of regular release cycle there so that it is easy to grab a not-too-old binary snapshot of the RGL.

Answer 4 · 2020-11-11T20:39:16.000Z

Update: the RGL workflow is under development here

Answer 5 · 2020-11-12T06:53:52.000Z

Dear All, I am in support of having GF-core and gf-rgl separate because I think their release cycles are quite different. Regarding the rukiga RGL, I am still working on it so it can wait for the next RGL release. We could have it released in its current version with an expected update at the next release cycle. Regards, David On 11 Nov 2020, at 23:28, John J. Camilleri <notifications@github.com<mailto:notifications@github.com>> wrote: A bolder suggestion is then that the GF packages should not include any RGL at all. To me this makes more sense than including a snapshot of whatever the RGL happened to be on the day of the release, and reinforces the separation between the projects. Actually, as I look into it, this is already the case for some of the packages, e.g. the Debian package contains no RGL but the Windows one does, even though this information is not actually communicated on the GF download page. So, my suggestion is that to make everything consistent, we provide the following GF binary packages, none of which include RGL: * macOS (.pkg) This is built using make pkg, I am working on a GitHub Actions workflow which does this (here<https://github.com/GrammaticalFramework/gf-core/actions?query=workflow%3A%22Build+macOS+Package%22>). * Debian (.deb) This is built using make deb, I wrote a workflow which does this (here<https://github.com/GrammaticalFramework/gf-core/actions?query=workflow%3A%22Build+Debian+Package%22>) although I don't know how to produce both 32-bit and 64-bit versions. * Windows (.zip) I'm not sure how this is built, there doesn't seem to be any script for this in the repository. I can start experimenting with a workflow for this too but will likely need some help. Notably: I don't know why there currently is a GF binary for Raspbian, and I think we should drop it since I don't know to create it and I don't know if there's any demand for it. In addition to the above, we also need to set up a GitHub Actions workflow in the gf-rgl repository which builds compiled versions of the RGL, and then have some sort of regular release cycle there so that it is easy to grab a not-too-old binary snapshot of the RGL. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#85 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AFID7QXSD5FMJFXFEMDTIFLSPLXVDANCNFSM4TRBQEJQ>.

Answer 6 · 2020-11-12T07:22:24.000Z

I'm fine with the GF binary package not including RGL and dropping the Raspbian package.

Answer 7 · 2020-11-12T07:42:53.000Z

One should just still make it clear that people are recommended to install the RGL, and make it as easy as it is now with automated setting of GF_LIB_PATH etc.

…

________________________________ From: Inari Listenmaa <notifications@github.com> Sent: Thursday, November 12, 2020 8:22:38 AM To: GrammaticalFramework/gf-core Cc: Aarne Ranta; Comment Subject: Re: [GrammaticalFramework/gf-core] Next GF release (#85) I'm fine with the GF binary package not including RGL and dropping the Raspbian package. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#85 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAWBQXMGVQRYR3JAFKR3B3TSPOEL5ANCNFSM4TRBQEJQ>.

Answer 8 · 2020-11-12T10:04:46.000Z

Notably: I don't know why there currently is a GF binary for Raspbian, and I think we should drop it since I don't know to create it and I don't know if there's any demand for it.

Thomas had a Raspberry PI and he built GF on it. If someone else wants it in the future then he/she can build it himself/herself.

Answer 9 · 2020-11-17T00:16:53.000Z

Some small updates:

We now have a GitHub workflow for building RGL binaries and publishing them as releases here: https://github.com/GrammaticalFramework/gf-rgl/releases
I'm working on setting up the gf-core builds as workflows, that work is on the build-binary-packages branch.
I added a preliminary RELEASE.md file.
I added stubs of the download page and changelog for GF 3.11. These are very work WIP, feel free to add stuff there.

Answer 10 · 2020-11-17T11:37:22.000Z

On a slightly related note, I've made nix-expressions for building GF. They are available here: https://github.com/anka-213/cclaw-nix-stuff.

There is still some work to do, but it is an easy way to install GF with dependencies if you have nix.

Answer 11 · 2020-11-18T20:33:32.000Z

@anka-213 I still don't really understand what nix is (🙈). Is your work something that can and should be included in the release somehow? Or maybe the installation page should link to your work?

Answer 12 · 2020-11-19T10:12:17.000Z

No worries, you don't need to include anything. 😄 Nix is a package manager, kind of like pacman or apt, but declarative. My nix expressions is code that can be used for building the project (or downloading binaries that were previously built with these expressions). Nix supports Mac and Linux, but unfortunately not windows (outside WSL). See here for more info: https://nixos.org/

So the later option might be the most useful. I should name the project something better though. 😛

Another thing I could do is to submit this to the official nix package repository, so it can be installed using nix-env -iA nixpkgs.gf, or run it without installing using nix run nixpkgs.gf -c gf SomeFile.gf. That way they will be included in nix's official binary cache. This will be easier to do when the new version is released on hackage.

Answer 13 · 2020-11-20T11:07:19.000Z

Right, ok! Whenever you do that, you can then add some instructions on the GF web page, namely in download/index-3.11.md.

Answer 14 · 2020-12-07T09:34:08.000Z

I have gone through all the commit messages since the last release and tried to update the changelog for 3.11 accordingly, see download/release-3.11.md. But it is extremely high level, so if you feel there are more things/details which should be added there then please do so. I think it makes sense that everyone adds/updates the features which they have been involved in.

Answer 15 · 2020-12-07T19:25:18.000Z

Great! To my eye it looks good, but I may also have missed some things other people have been doing in the past 2 years.

Answer 16 · 2021-06-29T07:30:42.000Z

I have written GitHub Actions workflows for building Debian and macOS packages (the latter still needs some work)

What is the status of the MacOS build scripts? What problems does it have?

Answer 17 · 2021-06-29T07:34:53.000Z

I don't think there are any problems remaining, as per my message on 2020-11-17.

Answer 18 · 2021-06-29T09:07:38.000Z

Can you write a check-list of what remains to be done for the release?

- [ ] Thing 1
- [x] Thing 2 (done)

Thing 1
Thing 2 (done)

Answer 19 · 2021-06-29T12:42:32.000Z

Yes, a checklist is a good idea. I'm not too sure of everything it should contain, but here's my first sketch of what should make it into the release. I think what gets added to (or removed from) this list should be a community effort.

Must have

Building binaries on Github actions (#63)
Working (and passing) test suite (#114)
Fix version bounds in cabal files (#115) — @2jacobtan will work on it
Support for Ubuntu 20.04 (#74) — @anka-213 is working on it at #116
Remove the Either Int from value2term (#87)

Nice to have

Fix pip3 install pgf on macOS (#108) — Seems to be a general Python problem, @inariksit added link to instructions about it in developers' duide.
Fixes in canonical compilation (#100, #101, #102) — @johnjcamilleri has fixed it, #118
Add flag for making Haskell export PGF2 compatible (#90) — @johnjcamilleri will work on it
Various deprecations during compilation of GF (#46)
Fix line breaks in GF shell (@Meowyam and @1Regina working on it based on #97)
Reload import specified from command line #64

Answer 20 · 2021-06-30T07:16:46.000Z

I created a PR to fix Ubuntu failures on the "Build Ubuntu package" workflow:

#116

Answer 21 · 2021-07-25T12:02:05.000Z

Great work on the release, guys! 🥂
I guess this issue can now be closed?

Answer 22 · 2021-07-25T12:08:22.000Z

Actually, I noticed one thing: the gf.cabal file in the release contains:

version: 3.11.0-git

Is this a problem (that the -git suffix is still there)?
Is adding this -git suffix to distinguish release from development code really a good idea? Feels like there should be a better way; removing it just to make the release and then adding it back is all too easy to forget...

Answer 23 · 2021-07-25T13:47:17.000Z

We didn't release on Hackage yet, just wanted to put binaries out for the summer school. I have no idea on the -git suffix or whether it will be a problem for Hackage (or for anything else).

Answer 24 · 2021-07-26T01:40:19.000Z

Since 3.11.0-git is larger than 3.11.0 according to most version number comparisons, we should probably use something different that indicates that it is a pre-release. Some projects (e.g. ghc) use odd version numbers for pre-releases and even for real releases (probably also with a suffix to indicate that it is a pre-release).
Debian/ubuntu uses the suffix +1... to indicate that it is a pre-release for the next version https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage

We could either manually set the version number right before a release and then change it back to a pre-release style number immediately after or try to automate the process.

Answer 25 · 2021-08-07T05:21:09.000Z

@johnjcamilleri can you do the last step and upload to Hackage? Is there anything you're missing or need others to do?

Answer 26 · 2021-08-09T09:44:32.000Z

Trying to upload to Hackage, I get this:

Invalid package
The package tarball contains a non-portable entry type. For portability, package tarballs should use the 'ustar' format and only contain normal files, directories and file links.

I'm investigating further.

Answer 27 · 2021-08-09T10:21:53.000Z

I had more luck creating the source distribution tarball with stack sdist. There's some historical reason why the Makefile uses git archive, but I suspect/hope this is not relevant anymore.

There's now a release candidate here: https://hackage.haskell.org/package/gf-3.11.0/candidate which I have successfully installed inside a Docker container. Maybe someone else can review it, then we can publish it for real.

Answer 28 · 2021-08-09T10:38:27.000Z

BUT stack sdist --test-tarball fails in the following way:

Cabal file warning in/Users/john/repositories/GF/gf-core/gf.cabal@2:20: version with tags
Getting file list for /Users/john/repositories/GF/gf-core/
gf> Warning: gf.cabal:2:20: version with tags
gf> List of package sources written to file
gf> '/private/var/folders/7k/0wclgzcs01d8jrsrzn4_nbbh0000gn/T/stack-sdist-4d712be56bea188c/source-files-list'
Building sdist tarball for /Users/john/repositories/GF/gf-core/
Wrote sdist tarball to /Users/john/repositories/GF/gf-core/.stack-work/dist/x86_64-osx/Cabal-3.2.1.0/gf-3.11.0.tar.gz
Cabal file warning in/private/var/folders/7k/0wclgzcs01d8jrsrzn4_nbbh0000gn/T/stack-9bab6fb825cf9963/gf-3.11.0/gf.cabal@2:20: version with tags
Building all executables for `gf' once. After a successful build of all of them, only specified executables will be rebuilt.
gf> configure (lib + exe + test)
[1 of 3] Compiling WebSetup         ( WebSetup.hs, /private/var/folders/7k/0wclgzcs01d8jrsrzn4_nbbh0000gn/T/stack-9bab6fb825cf9963/gf-3.11.0/.stack-work/dist/x86_64-osx/Cabal-3.2.1.0/setup/WebSetup.o )
[2 of 3] Compiling Main             ( /private/var/folders/7k/0wclgzcs01d8jrsrzn4_nbbh0000gn/T/stack-9bab6fb825cf9963/gf-3.11.0/Setup.hs, /private/var/folders/7k/0wclgzcs01d8jrsrzn4_nbbh0000gn/T/stack-9bab6fb825cf9963/gf-3.11.0/.stack-work/dist/x86_64-osx/Cabal-3.2.1.0/setup/Main.o )
[3 of 3] Compiling StackSetupShim   ( /Users/john/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs, /private/var/folders/7k/0wclgzcs01d8jrsrzn4_nbbh0000gn/T/stack-9bab6fb825cf9963/gf-3.11.0/.stack-work/dist/x86_64-osx/Cabal-3.2.1.0/setup/StackSetupShim.o )
Linking /private/var/folders/7k/0wclgzcs01d8jrsrzn4_nbbh0000gn/T/stack-9bab6fb825cf9963/gf-3.11.0/.stack-work/dist/x86_64-osx/Cabal-3.2.1.0/setup/setup ...
Warning: gf.cabal:2:20: version with tags
Configuring gf-3.11.0...
gf> build (lib + exe + test)
Preprocessing library for gf-3.11.0..
Building library for gf-3.11.0..
[  1 of 165] Compiling CGI
[  2 of 165] Compiling CGIUtils
[  3 of 165] Compiling Cache
[  4 of 165] Compiling Data.Binary.Builder
[  5 of 165] Compiling Data.Binary.Get
[  6 of 165] Compiling Data.Binary.Put
[  7 of 165] Compiling Data.Binary.IEEE754
[  8 of 165] Compiling Data.Binary
[  9 of 165] Compiling GF.Compile.Multi
[ 10 of 165] Compiling GF.Data.BacktrackM
[ 11 of 165] Compiling GF.Data.ErrM
[ 12 of 165] Compiling GF.Data.Graph
[ 13 of 165] Compiling GF.Data.Str
[ 14 of 165] Compiling GF.Data.Utilities
[ 15 of 165] Compiling GF.Data.Relation
[ 16 of 165] Compiling GF.Data.Operations
[ 17 of 165] Compiling GF.Data.Graphviz
[ 18 of 165] Compiling GF.Data.XML
[ 19 of 165] Compiling GF.Infra.BuildInfo
[ 20 of 165] Compiling GF.Infra.Concurrency
[ 21 of 165] Compiling GF.Infra.GetOpt
[ 22 of 165] Compiling GF.JavaScript.AbsJS
[ 23 of 165] Compiling GF.JavaScript.PrintJS
[ 24 of 165] Compiling GF.Speech.FiniteState
[ 25 of 165] Compiling GF.Speech.RegExp
[ 26 of 165] Compiling GF.System.Catch
[ 27 of 165] Compiling GF.System.Concurrency
[ 28 of 165] Compiling GF.System.Console
[ 29 of 165] Compiling GF.System.Directory
[ 30 of 165] Compiling GF.System.Process
[ 31 of 165] Compiling GF.System.UseSignal
[ 32 of 165] Compiling GF.System.Signal
[ 33 of 165] Compiling GF.Text.Clitics
[ 34 of 165] Compiling GF.Text.Coding
[ 35 of 165] Compiling GF.Text.Pretty
[ 36 of 165] Compiling GF.Infra.Location
[ 37 of 165] Compiling GF.Text.Transliterations
[ 38 of 165] Compiling GF.Text.Lexing
[ 39 of 165] Compiling PGF.CId
[ 40 of 165] Compiling PGF.ByteCode
[ 41 of 165] Compiling PGF.Expr[boot]
[ 42 of 165] Compiling PGF.Haskell
[ 43 of 165] Compiling PGF.TrieMap
[ 44 of 165] Compiling PGF.Type
[ 45 of 165] Compiling PGF.Expr
[ 46 of 165] Compiling PGF.Tree
[ 47 of 165] Compiling PGF.Data
[ 48 of 165] Compiling PGF.SortTop
[ 49 of 165] Compiling PGF.Printer
[ 50 of 165] Compiling PGF.Paraphrase
[ 51 of 165] Compiling PGF.Morphology
[ 52 of 165] Compiling PGF.Macros
[ 53 of 165] Compiling PGF.Probabilistic
[ 54 of 165] Compiling PGF.Optimize
[ 55 of 165] Compiling PGF.OldBinary
[ 56 of 165] Compiling PGF.Linearize
[ 57 of 165] Compiling PGF.Binary
[ 58 of 165] Compiling PGF.TypeCheck
[ 59 of 165] Compiling PGF.Generate
[ 60 of 165] Compiling PGF.Utilities
[ 61 of 165] Compiling PGF.Internal
[ 62 of 165] Compiling GF.Infra.Ident
[ 63 of 165] Compiling GF.Haskell
[ 64 of 165] Compiling GF.Grammar.Predef
[ 65 of 165] Compiling GF.Infra.Option
[ 66 of 165] Compiling GF.Infra.CheckM
[ 67 of 165] Compiling GF.Grammar.Lexer
[ 68 of 165] Compiling GF.Grammar.Canonical
[ 69 of 165] Compiling GF.Grammar.CanonicalJSON
[ 70 of 165] Compiling GF.Grammar.Grammar
[ 71 of 165] Compiling GF.Infra.Dependencies
[ 72 of 165] Compiling GF.Grammar.Values
[ 73 of 165] Compiling GF.Grammar.Printer
[ 74 of 165] Compiling GF.Grammar.Macros
[ 75 of 165] Compiling GF.Grammar.PatternMatch
[ 76 of 165] Compiling GF.Grammar.Lockfield
[ 77 of 165] Compiling GF.Grammar.Lookup
[ 78 of 165] Compiling GF.Grammar.ShowTerm
[ 79 of 165] Compiling GF.Grammar.Analyse
[ 80 of 165] Compiling GF.Grammar
[ 81 of 165] Compiling GF.Grammar.Unify
[ 82 of 165] Compiling GF.Compile.TypeCheck.TC
[ 83 of 165] Compiling GF.Compile.TypeCheck.Primitives
[ 84 of 165] Compiling GF.Compile.TypeCheck.Concrete
[ 85 of 165] Compiling GF.Compile.TypeCheck.Abstract
[ 86 of 165] Compiling GF.Compile.Update
[ 87 of 165] Compiling GF.Compile.SubExOpt
[ 88 of 165] Compiling GF.Compile.Rename
[ 89 of 165] Compiling GF.Compile.Compute.Value
[ 90 of 165] Compiling GF.Compile.Compute.Predef
[ 91 of 165] Compiling GF.Compile.Compute.Concrete
[ 92 of 165] Compiling GF.Compile.TypeCheck.ConcreteNew
[ 93 of 165] Compiling GF.Compile.Optimize
[ 94 of 165] Compiling GF.Compile.GrammarToCanonical
[ 95 of 165] Compiling GF.Compile.ConcreteToHaskell
[ 96 of 165] Compiling GF.Compile.CheckGrammar
[ 97 of 165] Compiling PGF.Forest
[ 98 of 165] Compiling PGF.Parse
[ 99 of 165] Compiling PGF.VisualizeTree
[100 of 165] Compiling PGF
[101 of 165] Compiling GF.Speech.VoiceXML
[102 of 165] Compiling GF.Quiz
[103 of 165] Compiling GF.Grammar.CFG
[104 of 165] Compiling GF.Speech.PGFToCFG
[105 of 165] Compiling GF.Speech.CFGToFA
[106 of 165] Compiling GF.Speech.SRG
[107 of 165] Compiling GF.Speech.SISR
[108 of 165] Compiling GF.Speech.SRGS_XML
[109 of 165] Compiling GF.Speech.SRGS_ABNF
[110 of 165] Compiling GF.Speech.JSGF
[111 of 165] Compiling GF.Speech.GSL
[112 of 165] Compiling GF.Speech.SLF
[113 of 165] Compiling GF.Speech.PrRegExp
[114 of 165] Compiling GF.Grammar.EBNF
[115 of 165] Compiling GF.Grammar.BNFC
[116 of 165] Compiling GF.Grammar.Parser
[117 of 165] Compiling GF.Compile.ToAPI
[118 of 165] Compiling GF.Compile.PGFtoPython
[119 of 165] Compiling GF.Compile.PGFtoProlog
[120 of 165] Compiling GF.Compile.PGFtoJava
[121 of 165] Compiling GF.Compile.PGFtoJSON
[122 of 165] Compiling GF.Compile.PGFtoJS
[123 of 165] Compiling GF.Compile.PGFtoHaskell
[124 of 165] Compiling GF.Compile.GenerateBC
[125 of 165] Compiling GF.Compile.Export
[126 of 165] Compiling GF.Compile.ExampleBased
[127 of 165] Compiling GF.Command.TreeOperations
[128 of 165] Compiling GF.Command.Abstract
[129 of 165] Compiling GF.Command.Parse
[130 of 165] Compiling GF.Command.CommandInfo
[131 of 165] Compiling Fold
[132 of 165] Compiling ExampleDemo
[133 of 165] Compiling ExampleService
[134 of 165] Compiling Paths_gf
[135 of 165] Compiling GF.Infra.UseIO
[136 of 165] Compiling GF.Support
[137 of 165] Compiling GF.Grammar.Binary
[138 of 165] Compiling GF.Compile.Tags
[139 of 165] Compiling GF.Compile.ReadFiles
[140 of 165] Compiling GF.Compile.GetGrammar
[141 of 165] Compiling GF.Compile.GeneratePMCFG
[142 of 165] Compiling GF.CompileOne
[143 of 165] Compiling GF.CompileInParallel
[144 of 165] Compiling GF.Compile.GrammarToPGF
[145 of 165] Compiling GF.Compile.CFGtoPGF
[146 of 165] Compiling GF.Compile
[147 of 165] Compiling GF.Compiler
[148 of 165] Compiling GF.Command.Interpreter
[149 of 165] Compiling GF.Command.Importing
[150 of 165] Compiling GF.Infra.SIO
[151 of 165] Compiling GF.Command.SourceCommands
[152 of 165] Compiling GF.Command.CommonCommands
[153 of 165] Compiling GF.Command.Commands
[154 of 165] Compiling GF.Command.Messages
[155 of 165] Compiling GF.Command.Help
[156 of 165] Compiling SimpleEditor.Syntax
[157 of 165] Compiling SimpleEditor.JSON
[158 of 165] Compiling SimpleEditor.Convert
[159 of 165] Compiling URLEncoding
[160 of 165] Compiling RunHTTP
[161 of 165] Compiling PGFService
[162 of 165] Compiling GF.Server
[163 of 165] Compiling GF.Interactive
[164 of 165] Compiling GF.Main
[165 of 165] Compiling GF
Preprocessing executable 'gf' for gf-3.11.0..
Building executable 'gf' for gf-3.11.0..
[1 of 1] Compiling Main
Linking .stack-work/dist/x86_64-osx/Cabal-3.2.1.0/build/gf/gf ...
Preprocessing test suite 'gf-tests' for gf-3.11.0..
Building test suite 'gf-tests' for gf-3.11.0..
[1 of 1] Compiling Main
Linking .stack-work/dist/x86_64-osx/Cabal-3.2.1.0/build/gf-tests/gf-tests ...
gf> copy/register
Installing library in /Users/john/repositories/GF/gf-core/.stack-work/install/x86_64-osx/75c10a87f0c2163a204d68c93b9bb9475846e3b8dc79d214673b3197f19c31b0/8.10.4/lib/x86_64-osx-ghc-8.10.4/gf-3.11.0-IKFYsq6cVU8CmlaGtHrrcX
Installing executable gf in /Users/john/repositories/GF/gf-core/.stack-work/install/x86_64-osx/75c10a87f0c2163a204d68c93b9bb9475846e3b8dc79d214673b3197f19c31b0/8.10.4/bin
doc/Logos/gf0.png: copyFile:atomicCopyFileContents:withReplacementFile:copyFileToHandle:openBinaryFile: does not exist (No such file or directory)
Progress 1/2
'cabal copy' failed.  Error message:

--  While building package gf-3.11.0 (scroll up to its section to see the error) using:
      /private/var/folders/7k/0wclgzcs01d8jrsrzn4_nbbh0000gn/T/stack-9bab6fb825cf9963/gf-3.11.0/.stack-work/dist/x86_64-osx/Cabal-3.2.1.0/setup/setup --builddir=.stack-work/dist/x86_64-osx/Cabal-3.2.1.0 copy
    Process exited with code: ExitFailure 1

Possible causes of this issue:
* No module named "Main". The 'main-is' source file should usually have a header indicating that it's a 'Main' module.
* A cabal file that refers to nonexistent other files (e.g. a license-file that doesn't exist). Running 'cabal check' may point out these issues.
* The Setup.hs file is changing the installation target dir.

Answer 29 · 2021-08-09T12:03:19.000Z

Ok, the above problem is fixed and a new release candidate is uploaded to Hackage.

There is still some mystery surrounding the way sdist is treated in the past, in particular this comment in Setup.hs:

cabal sdist will not make a proper dist archive, for that see make sdist

I suspect this has something to do with what WebSetup does...

Answer 30 · 2021-08-12T07:40:05.000Z

So I published the package on Hackage package as 3.11.0.
But then I realised that the version number should probably have been 3.11 not 3.11.0, as was the convention in the past, and what has also been used as the GitHub release version.

So I uploaded version 3.11 to Hackage too, and marked 3.11.0 as deprecated (since you can't delete it once it's published). They are exactly the same version in terms of source code.

Hope this doesn't cause too much confusion (I knew something would go wrong...)

Answer 31 · 2021-08-16T01:09:42.000Z

Haha, that's a very minor thing to me! I uncommented the Hackage instructions from the documentation at 8ec13b1 , feel free to update if something is still out of date.