Re: [Haskell-cafe] Integrate GHC-API with Cabal
cabal-install package includes useful modules. With these modules it is possible to read the actual build info. These modules could be added to the Cabal API. What are the reasons cabal-install can not be added as a project dependency? Can some modules be moved from cabal-install to Cabal library? On 25 July 2018 at 11:33, Félix Baylac wrote: > Dear cafe, > > I am currently working on a project [1] which aims to index the code > published on > Stackage in order to provide a "code example" database. Basically, for each > library, I want to generate a real-world example corpus for each exported > symbol. > > Before generating this database, I need to retrieve the exported symbol of > a > package. So far, I have been gathering the dependencies and integrating > them in > the GHC pkg database using an external stack call, I then parse the cabal > file > and load the exposed modules using the GHC API and gather the exported > symbols*. > > It works pretty reliably on the simple packages, however, I end up with > some > missing dynamic flags for some more advanced packages (missing c includes, > c > libraries, ASM flags, etc.). I then started to parse and load these > missing > attributes to GHC until I stepped back for a moment and realized I was > re-implementing cabal build. > > I then looked for a way to "hook" my GHC API code in cabal build. This > would > allow cabal to both handle the dependencies gathering as well as setting > up the > correct GHC dyn-flags. The only resource I found was [2]. It's really > clever, > however, looks a bit hacky to me. > > Is there a better way to perform this kind of "hook"? > > > [1] https://git.alternativebit.fr/NinjaTrappeur/Exhs > [2] http://blog.ezyang.com/2017/02/how-to-integrate-ghc-api- > programs-with-cabal/ > > * I am aware of the hoogle index generated by haddock. However, this index > is > missing when the haddock documentation of a package cannot be generated. > ___ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Re: Cabal website
The lads took it up: https://github.com/haskell/cabal/issues/4013 Please join the discussion if interested. ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Re: Cabal website
> Writing software anew is the fun part, the not-fun part is the maintenance. Agree. Writing a new version is often faster and easier. In this case the website is compact, so it is doable: why not use a new framework every time someone wants to do a full rewrite? Does the ticket rule out React? I just used the framework I knew and found fast and convenient. It is not that new, btw. If this version is not acceptable, so be it. Maybe let's add a note to the ticket: no React can be used. So we benefit from this experience in some way at least. ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Re: Cabal website
Well, I put in a full week in this version. If this website is not usable, fair enough. Let's wait for the version that suits. ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Re: Cabal website
> doesn't seem to be any particular reason to require JS for basic functionality on a documentation site.) Js is widely used these days. E.g., ReadTheDocs use Js [1]. Users without Js in the browser may be redirected to a static html version of the website. This version uses the material design [2] concept. CSS - although minimal - came with the library which allowed for faster coding time, focusing on the content and functionality. For someone with basic React knowledge the website is easy to maintain. SPA arch allows for faster navigation between the pages. Client side rendering frees up the server. The content largely follows the content from the existing website, with an attempt at improving content organisation and navigation. Does rendering by search robots need to be verified or may we take it as most likely working? [1] https://docs.readthedocs.io/en/latest/development/standards.html#background [2] https://en.m.wikipedia.org/wiki/Material_Design ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Re: Cabal website
Please use this link instead to access the demo: https://ciezbit.bitbucket.io/cabal On Sun, 17 Jun 2018 13:32 Imants Cekusins, wrote: > Hi all, > > Re: > https://github.com/haskell/cabal/issues/4013 > > Would > https://ciezbit.bitbucket.io/cabal/doc > be an improvement over > https://www.haskell.org/cabal/ > ? > > This link points to a temporary demo deployment. The app is written in > React with material-ui lib. > ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Cabal website
Hi all, Re: https://github.com/haskell/cabal/issues/4013 Would https://ciezbit.bitbucket.io/cabal/doc be an improvement over https://www.haskell.org/cabal/ ? This link points to a temporary demo deployment. The app is written in React with material-ui lib. ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
