Re: Anybody using the "top-down" solver?

On Mon, Nov 9, 2015 at 4:30 AM Bardur Arantsson wrote: > Hi all, > > Just to get input from as many people as possible: I was pondering a > plan for modularizing the solver[1] and wanted to reach as many people > as possible with my question: > >Is anybody is still

New minor 1.22 release?

Hi all, Unfortunately GHC 7.10.1 shipped with a Cabal library that handles ghcjs-pkg version numbers wrong, making it unusable to boot GHCJS. I'd like 7.10.2 to ship with a working version (7.10.2 itself also contains an important bugfix for GHCJS), which would require a new minor version

Re: New minor 1.22 release?

home. Cheers, Ryan On Wednesday, 15 April 2015, Luite Stegeman stege...@gmail.com wrote: Hi all, Unfortunately GHC 7.10.1 shipped with a Cabal library that handles ghcjs-pkg version numbers wrong, making it unusable to boot GHCJS. I'd like 7.10.2 to ship with a working version (7.10.2

Re: Getting Cabal 1.2[12] ready for GHC 7.10.1 RC1

Status update: All functionality from the ghcjs Cabal branch is now in pull requests [1] [2]. I have changed a few things in the GHCJS command line options (more consistent with GHC now), and GHCJS produces library archives (libHSpackage.js_a) for packages now, which makes GHCJS easier and more

Re: New fields/flags and semantics for GHCJS

One more thing I had forgotten to mention, and still need to implement in GHCJS: If a library has web assets, for example CSS files or images for a GUI framework library, they should be listed under `data-files` of a package. The compiler then makes all data directories of dependencies available

Re: New fields/flags and semantics for GHCJS

On Wed, Oct 29, 2014 at 2:10 AM, Mikhail Glushenkov the.dead.shall.r...@gmail.com wrote: The user-visible changes look reasonable in my opinion. Looking forward to merging your patches! When merging the latest master I found that ghcjs-options are actually mappended to ghc-options in the

Re: New fields/flags and semantics for GHCJS

# new js-sources field A js-sources field is treated like the c-sources field. JS sources of all dependencies of a an executable are collected into a big JavaScript file. GHCJS also outputs some data about the collected files for custom deployment scripts. JS sources are not compiled,

New fields/flags and semantics for GHCJS

Hi all, I've been maintaining a Cabal fork for GHCJS. The GHCJS-specific bits have been relatively stable for a while now, and are feature complete, apart from a few small features that I'll complete later this week. So I think it's time to discuss merging the branch. This discussion is for the

Re: Gearing up for a 1.18 release

. The value of GHCJS is that it's supposed to be able to compile most existing packages as-is. Just my two cents. :-) On Sun, Aug 25, 2013 at 6:53 PM, Luite Stegeman stege...@gmail.com wrote: I think we should definitely fix the packages, not put a hack in Cabal

Re: Gearing up for a 1.18 release

I'm not worried about these packages, but about the Cabal code base itself. The Cabal code base hardly creates CompilerId directly, in almost all cases the change is ignoring the third field. This is where CompilerId is created: All existing flavours add Nothing, 6x one-line change: -

Re: Gearing up for a 1.18 release

Yes, I've updated the patch [1], but I still have a problem loading dynlibs for TH in some cases. I don't think it's related to Cabal (which appears to be running all the right commands), but I can't completely rule it out either. The Cabal patch was fine indeed. It was a problem with the

Re: Gearing up for a 1.18 release

I think we should definitely fix the packages, not put a hack in Cabal. In the latest hackage archive, there are 462 packages that use the impl(ghc) flag, including lots of very common packages. For example binary: if impl(ghc = 7.2.1) cpp-options: -DGENERICS other-modules:

Re: GHCJS support for Cabal

(1) feels like an implementation detail of GHCJS that has been promoted into something everyone will have to deal with. I would like us to give this design some more thought (preferably with input from Duncan) before we merge these changes. It's not so much an implementation detail of GHCJS

Re: Gearing up for a 1.18 release

On Sat, Aug 24, 2013 at 5:08 AM, Carter Schonwald carter.schonw...@gmail.com wrote: Just so you guy's know, Luite should have a patch ready for consideration very soon. (just spoke with him) Yes, I've updated the patch [1], but I still have a problem loading dynlibs for TH in some cases. I

GHCJS support for Cabal

hi all, We're readying the GHCJS [1] compiler for the first release, to coincide with GHC's 7.8.1 release. For now, GHCJS is a stand-alone executable that uses the GHC API and manages its own package database. We've been maintaining a Cabal patch with the intention to get it merged in 1.18, but