- User Since
- Jul 4 2014, 4:34 AM (276 w, 4 d)
May 22 2019
Oct 9 2018
Oct 8 2018
Is there a discussion somewhere else (other than the ghc-devs mailing list) about this? For example I'm still not sure why for the motivating example (custom backends) you prefer plugins over hooks. Perhaps I missed it.
Dec 14 2015
Yes I'd like to update the patch, but the list being used in HeaderInfo.checkExtension, which causes the validate failure, is actually also causing problems for GHCJS, since it's impossible to customize the check through the GHC API. Adding the list to DynFlags would be an option.
Dec 13 2015
Yes GHCJS adds the extension.
Nov 11 2015
- Add testcase for Trac #11076 and adjust strictness sig for T8598
Jul 15 2015
Oh sorry, didn't notice that it was already merged in 7.10 (thanks!). The only change was a comment.
I've updated the backported patch for 7.10 in the trac ticket to reflect the latest changes (minus the new test case)
- add test case and comment to clarify the way calling conventions are handled in TH
I implemented the TH behaviour to behave like the non-TH version:
Jul 14 2015
Apr 8 2015
Jan 5 2015
Dec 22 2014
Dec 17 2014
It's really not that hard to find some if you take the time to carefully read the commit
the rest of the StaticPointers patch also looks rather sloppy, with examples in the documentation not compiling and names in comments being different from the things they refer to.
Dec 16 2014
can this be merged before 7.10 is cut? as far as i know there are no outstanding issues. if there are any i'd be happy to resolve them.
can this be merged before 7.10 is cut?
Dec 7 2014
rebase on latest master
Nov 30 2014
Can we get rid of the GHCI requirement for this type of plugins, even if it's just for when GHC has been linked with dynamic libs? If we can, it'd require just a few more changes to make runMeta reachable again in stage1 compilers, making this plugin thing usable in the short term for oopth for cross compilers.
A few things to note:
Nov 24 2014
looks ok, validate passes now where it failed before with the same starting state (OS X 10.10 using in-tree GMP, with in-tree GMP already built)
Nov 22 2014
alternative has been merged
Nov 21 2014
Is there anything I can do to help at this point? I've been preparing the GHCJS code generator and pretty printer to keep track of source locations for source maps, so I'm very interested in this. Unfortunately the new codegen branch is still based on GHC 7.8, the 7.9 branch still uses jmacro, so I can't yet do a full end-to-end test. I'd be happy to help out resolving failing test cases or reviewing/testing parts of the code though.
Nov 20 2014
This patch is a replacement for D499. It exposes just enough of the Packages API so that GHCJS can find the package databases and can then use Cabal (possibly through ghcjs-pkg) to retrieve the metadata that it needs to link an executable with data files.
I'll submit an alternative discussed with dcoutts that does not require a change in the binary package database but instead exposes a bit more functionality of Packages to make it possible to implement the functionality in GHCJS in a different, but still reasonably palatable (calling out to an external program rather than lookupPackage and 10-100x as much code) way.
Hmm, curious that this breaks LLVM, since the constructors shouldn't have been used yet. I realized that the new names are still missing from the templateHaskell names list though!
Nov 19 2014
- add test case for new foreign calling conventions in Template Haskell
looks like quoting foreign declarations does not yet work:
It will take me a bit longer to update the wiki since i really really want to finish the GHCJS support Cabal patch first, to get it into the Cabal that will ship with 7.10, since lack of mainline Cabal support has been hurting GHCJS adoption (packages using js-sources, the impl(ghcjs) flag and ghcjs-options can't be uploaded to hackage).
This only defines the hook where alternative TH runners can take over, and it makes the various meta expression types explicit in the MetaRequest and MetaResult types.
I've rebased it on the latest master and added the missing DsMeta / Language.Haskell.TH.Lib bits
- Add missing calling conventions to DsMeta and Language.Haskell.TH.Lib
adding missing bits
Nov 18 2014
In my first version, I had a GADT for the various TH request types, with type parameters for the Template Haskell and the result type. Unfortunately, using a GADT like this in a hook requires ImpredicativeTypes, and setting the hook required frighteningly explicit type signatures.
haddock submodule is on wip branch now, i can merge it to the ghc-head branch if this gets accepted. let me know if there's a better procedure for this.
- update haddock submodule to fix clash with projectVersion name in DynFlags
GHCJS uses this to load the package database from ~/.ghcjs and not ~/.ghc, and to have its own version number in library names, rather than just GHC's (it produces native libraries when installed in --native-too mode). This required quite horrible hacks before.
mgsloan requested these, he currenly supplies them with th-orphans: http://hackage.haskell.org/package/th-orphans
sorry for the double message, had a MySQL connection failure error the first time
this adds a projectVersion exported name to DynFlags, haddock uses the same name somewhere so it needs to be patched (hiding that name from DynFlags is enough). I don't know if I can make that change in a diff since it's in a submodule.
Nov 16 2014
Oct 20 2014
Can you add tests for this and check that unsupported imports give a decent error message? I recall that it's easy to make GHC panic with an invalid C label in a spliced CCall import, which should probably also be fixed.
Oct 19 2014
Conversion of the calling convention is still missing. See compiler/hsSyn/Convert.lhs, cvt_conv
Sep 17 2014
The current implementation does not appear to keep the heap references alive correctly:
Sep 16 2014
I just read the patch and I wonder if CAFs for statics are kept alive correctly. Since symbols are loaded directly from the library by name, it looks like they may resurrect objects that have already been finalized. At first I thought mkExport was used for this, but I think it generates an exported binding and not a foreign export.