GHC (API?) question: GHC Core for Base libraries

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

GHC (API?) question: GHC Core for Base libraries

Bill Hallahan
Hi,

I'm writing a program analyzer that operates on GHC Core.  Currently, I'm using the GHC API to get Core from .hs files.  I'd like to be able to run this analysis on the standard libraries that come with GHC, which requires getting those as Core.

Unfortunately, the build process for these libraries is not entirely straightforward, and relies on a make script.  I eventually came up with the plan of writing a GHC plugin, which, rather than performing any optimizations, would simply run the analysis, and then print the results out to a file.  I was able to write the plugin successfully, and test it on several files that were not from the base library.

Then, i turned to modify the GhcLibHcOpts flag in mk/build.mk, so that the make script would call the plugin.  I ended up with the following:

GhcLibHcOpts = -package-db /usr/local/lib/ghc-8.0.2/package.conf.d -package-db /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d -package hplugin -fplugin HPlugin.Plugin -v

The two package databases are to get to (1) the GHC API and (2) the plugin ("hplugin") itself.  With this I get an error message, which I have not been able to find a way to resolve:

"inplace/bin/ghc-stage1" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O -Wall      -this-unit-id ghc-prim-0.5.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/.    -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package-id rts -this-unit-id ghc-prim -XHaskell2010 -package-db /usr/local/lib/ghc-8.0.2/package.conf.d -package-db /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d -package hplugin -fplugin HPlugin.Plugin  -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags     -Wnoncanonical-monad-instances  -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -split-objs  -dynamic-too -c libraries/ghc-prim/./GHC/Types.hs -o libraries/ghc-prim/dist-install/build/GHC/Types.o -dyno libraries/ghc-prim/dist-install/build/GHC/Types.dyn_o
<command line>: not built for interactive use - can't load plugins (HPlugin.Plugin)
make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Types.o] Error 1
make: *** [all] Error 2

So I'm now wondering (an answer to either of these two questions would be helpful):
(1) Is this a viable path?  That is, is it possible to use a plugin when building Base?  If so, does anyone know what I might be doing wrong/what could be causing this error message?
(2) Is there some other better/easier way I could get Core representations of the standard libraries?  I guess, in theory, it must be possible to compile the standard libraries with the GHC API, but I have no idea how/where to look to figure out how?

Thanks,
Bill

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GHC (API?) question: GHC Core for Base libraries

Shao, Cheng
Hi,

Joachim Breitner's veggies(https://github.com/nomeata/veggies) project is a good example of using a vanilla ghc installation to compile standard libraries like base.

On Tue, Dec 4, 2018, 10:11 AM Bill Hallahan <[hidden email]> wrote:
Hi,

I'm writing a program analyzer that operates on GHC Core.  Currently, I'm using the GHC API to get Core from .hs files.  I'd like to be able to run this analysis on the standard libraries that come with GHC, which requires getting those as Core.

Unfortunately, the build process for these libraries is not entirely straightforward, and relies on a make script.  I eventually came up with the plan of writing a GHC plugin, which, rather than performing any optimizations, would simply run the analysis, and then print the results out to a file.  I was able to write the plugin successfully, and test it on several files that were not from the base library.

Then, i turned to modify the GhcLibHcOpts flag in mk/build.mk, so that the make script would call the plugin.  I ended up with the following:

GhcLibHcOpts = -package-db /usr/local/lib/ghc-8.0.2/package.conf.d -package-db /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d -package hplugin -fplugin HPlugin.Plugin -v

The two package databases are to get to (1) the GHC API and (2) the plugin ("hplugin") itself.  With this I get an error message, which I have not been able to find a way to resolve:

"inplace/bin/ghc-stage1" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O -Wall      -this-unit-id ghc-prim-0.5.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/.    -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package-id rts -this-unit-id ghc-prim -XHaskell2010 -package-db /usr/local/lib/ghc-8.0.2/package.conf.d -package-db /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d -package hplugin -fplugin HPlugin.Plugin  -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags     -Wnoncanonical-monad-instances  -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -split-objs  -dynamic-too -c libraries/ghc-prim/./GHC/Types.hs -o libraries/ghc-prim/dist-install/build/GHC/Types.o -dyno libraries/ghc-prim/dist-install/build/GHC/Types.dyn_o
<command line>: not built for interactive use - can't load plugins (HPlugin.Plugin)
make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Types.o] Error 1
make: *** [all] Error 2

So I'm now wondering (an answer to either of these two questions would be helpful):
(1) Is this a viable path?  That is, is it possible to use a plugin when building Base?  If so, does anyone know what I might be doing wrong/what could be causing this error message?
(2) Is there some other better/easier way I could get Core representations of the standard libraries?  I guess, in theory, it must be possible to compile the standard libraries with the GHC API, but I have no idea how/where to look to figure out how?

Thanks,
Bill
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: GHC (API?) question: GHC Core for Base libraries

Brandon Allbery
In reply to this post by Bill Hallahan
The problem here is that you're using a stage 1 build, and stage 1 lacks support for the bytecode backend used by TH, plugins, ghci, etc. A base build with a stage 2 compiler should work.

On Mon, Dec 3, 2018 at 9:11 PM Bill Hallahan <[hidden email]> wrote:
Hi,

I'm writing a program analyzer that operates on GHC Core.  Currently, I'm using the GHC API to get Core from .hs files.  I'd like to be able to run this analysis on the standard libraries that come with GHC, which requires getting those as Core.

Unfortunately, the build process for these libraries is not entirely straightforward, and relies on a make script.  I eventually came up with the plan of writing a GHC plugin, which, rather than performing any optimizations, would simply run the analysis, and then print the results out to a file.  I was able to write the plugin successfully, and test it on several files that were not from the base library.

Then, i turned to modify the GhcLibHcOpts flag in mk/build.mk, so that the make script would call the plugin.  I ended up with the following:

GhcLibHcOpts = -package-db /usr/local/lib/ghc-8.0.2/package.conf.d -package-db /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d -package hplugin -fplugin HPlugin.Plugin -v

The two package databases are to get to (1) the GHC API and (2) the plugin ("hplugin") itself.  With this I get an error message, which I have not been able to find a way to resolve:

"inplace/bin/ghc-stage1" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O -Wall      -this-unit-id ghc-prim-0.5.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/.    -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package-id rts -this-unit-id ghc-prim -XHaskell2010 -package-db /usr/local/lib/ghc-8.0.2/package.conf.d -package-db /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d -package hplugin -fplugin HPlugin.Plugin  -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags     -Wnoncanonical-monad-instances  -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -split-objs  -dynamic-too -c libraries/ghc-prim/./GHC/Types.hs -o libraries/ghc-prim/dist-install/build/GHC/Types.o -dyno libraries/ghc-prim/dist-install/build/GHC/Types.dyn_o
<command line>: not built for interactive use - can't load plugins (HPlugin.Plugin)
make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Types.o] Error 1
make: *** [all] Error 2

So I'm now wondering (an answer to either of these two questions would be helpful):
(1) Is this a viable path?  That is, is it possible to use a plugin when building Base?  If so, does anyone know what I might be doing wrong/what could be causing this error message?
(2) Is there some other better/easier way I could get Core representations of the standard libraries?  I guess, in theory, it must be possible to compile the standard libraries with the GHC API, but I have no idea how/where to look to figure out how?

Thanks,
Bill
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


--
brandon s allbery kf8nh

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: GHC (API?) question: GHC Core for Base libraries

Bill Hallahan
Joachim Breitner's veggies(https://github.com/nomeata/veggies) project is a good example of using a vanilla ghc installation to compile standard libraries like base.
Thanks Cheng, this looks interesting and helpful!  I'm still trying to understand it fully, but it seems like the important pieces for building base are in the boot and Setup scripts?

The problem here is that you're using a stage 1 build, and stage 1 lacks support for the bytecode backend used by TH, plugins, ghci, etc. A base build with a stage 2 compiler should work.
Thanks Brandon.  Is there a recommended/documented way to build base with a stage 2 compiler?  I haven't been able to find anything about this on the wiki. 

On Dec 3, 2018, at 11:10 PM, Brandon Allbery <[hidden email]> wrote:

The problem here is that you're using a stage 1 build, and stage 1 lacks support for the bytecode backend used by TH, plugins, ghci, etc. A base build with a stage 2 compiler should work.

On Mon, Dec 3, 2018 at 9:11 PM Bill Hallahan <[hidden email]> wrote:
Hi,

I'm writing a program analyzer that operates on GHC Core.  Currently, I'm using the GHC API to get Core from .hs files.  I'd like to be able to run this analysis on the standard libraries that come with GHC, which requires getting those as Core.

Unfortunately, the build process for these libraries is not entirely straightforward, and relies on a make script.  I eventually came up with the plan of writing a GHC plugin, which, rather than performing any optimizations, would simply run the analysis, and then print the results out to a file.  I was able to write the plugin successfully, and test it on several files that were not from the base library.

Then, i turned to modify the GhcLibHcOpts flag in mk/build.mk, so that the make script would call the plugin.  I ended up with the following:

GhcLibHcOpts = -package-db /usr/local/lib/ghc-8.0.2/package.conf.d -package-db /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d -package hplugin -fplugin HPlugin.Plugin -v

The two package databases are to get to (1) the GHC API and (2) the plugin ("hplugin") itself.  With this I get an error message, which I have not been able to find a way to resolve:

"inplace/bin/ghc-stage1" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O -Wall      -this-unit-id ghc-prim-0.5.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/.    -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package-id rts -this-unit-id ghc-prim -XHaskell2010 -package-db /usr/local/lib/ghc-8.0.2/package.conf.d -package-db /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d -package hplugin -fplugin HPlugin.Plugin  -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags     -Wnoncanonical-monad-instances  -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -split-objs  -dynamic-too -c libraries/ghc-prim/./GHC/Types.hs -o libraries/ghc-prim/dist-install/build/GHC/Types.o -dyno libraries/ghc-prim/dist-install/build/GHC/Types.dyn_o
<command line>: not built for interactive use - can't load plugins (HPlugin.Plugin)
make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Types.o] Error 1
make: *** [all] Error 2

So I'm now wondering (an answer to either of these two questions would be helpful):
(1) Is this a viable path?  That is, is it possible to use a plugin when building Base?  If so, does anyone know what I might be doing wrong/what could be causing this error message?
(2) Is there some other better/easier way I could get Core representations of the standard libraries?  I guess, in theory, it must be possible to compile the standard libraries with the GHC API, but I have no idea how/where to look to figure out how?

Thanks,
Bill
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


--
brandon s allbery kf8nh


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GHC (API?) question: GHC Core for Base libraries

Brandon Allbery
It's more complicated than that, because unless your'e just doing some transient experimentation this will bite you over and over. What you'll want to do is check the stage during compilation (it should be available as macros via the CPP extension) and disable the plugin for stage 1. Then (I think; it's even worse if not...) use the base built during stage 2.

The comlication there being that it may use the stage 1 compiler to build the stage 2 base. In this case, you probably can't e.g. get this integrated into ghc, because it has to be possible to get it in stage 1 and ideally stage 2 (some platforms can't do stage 2 builds yet; ARM at least used to be in this category, hence e.g. no ghci or TH). Which places limits on what features can be used in the base package.

On Tue, Dec 4, 2018 at 1:37 PM Bill Hallahan <[hidden email]> wrote:
Joachim Breitner's veggies(https://github.com/nomeata/veggies) project is a good example of using a vanilla ghc installation to compile standard libraries like base.
Thanks Cheng, this looks interesting and helpful!  I'm still trying to understand it fully, but it seems like the important pieces for building base are in the boot and Setup scripts?

The problem here is that you're using a stage 1 build, and stage 1 lacks support for the bytecode backend used by TH, plugins, ghci, etc. A base build with a stage 2 compiler should work.
Thanks Brandon.  Is there a recommended/documented way to build base with a stage 2 compiler?  I haven't been able to find anything about this on the wiki. 

On Dec 3, 2018, at 11:10 PM, Brandon Allbery <[hidden email]> wrote:

The problem here is that you're using a stage 1 build, and stage 1 lacks support for the bytecode backend used by TH, plugins, ghci, etc. A base build with a stage 2 compiler should work.

On Mon, Dec 3, 2018 at 9:11 PM Bill Hallahan <[hidden email]> wrote:
Hi,

I'm writing a program analyzer that operates on GHC Core.  Currently, I'm using the GHC API to get Core from .hs files.  I'd like to be able to run this analysis on the standard libraries that come with GHC, which requires getting those as Core.

Unfortunately, the build process for these libraries is not entirely straightforward, and relies on a make script.  I eventually came up with the plan of writing a GHC plugin, which, rather than performing any optimizations, would simply run the analysis, and then print the results out to a file.  I was able to write the plugin successfully, and test it on several files that were not from the base library.

Then, i turned to modify the GhcLibHcOpts flag in mk/build.mk, so that the make script would call the plugin.  I ended up with the following:

GhcLibHcOpts = -package-db /usr/local/lib/ghc-8.0.2/package.conf.d -package-db /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d -package hplugin -fplugin HPlugin.Plugin -v

The two package databases are to get to (1) the GHC API and (2) the plugin ("hplugin") itself.  With this I get an error message, which I have not been able to find a way to resolve:

"inplace/bin/ghc-stage1" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O -Wall      -this-unit-id ghc-prim-0.5.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/.    -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package-id rts -this-unit-id ghc-prim -XHaskell2010 -package-db /usr/local/lib/ghc-8.0.2/package.conf.d -package-db /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d -package hplugin -fplugin HPlugin.Plugin  -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags     -Wnoncanonical-monad-instances  -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -split-objs  -dynamic-too -c libraries/ghc-prim/./GHC/Types.hs -o libraries/ghc-prim/dist-install/build/GHC/Types.o -dyno libraries/ghc-prim/dist-install/build/GHC/Types.dyn_o
<command line>: not built for interactive use - can't load plugins (HPlugin.Plugin)
make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Types.o] Error 1
make: *** [all] Error 2

So I'm now wondering (an answer to either of these two questions would be helpful):
(1) Is this a viable path?  That is, is it possible to use a plugin when building Base?  If so, does anyone know what I might be doing wrong/what could be causing this error message?
(2) Is there some other better/easier way I could get Core representations of the standard libraries?  I guess, in theory, it must be possible to compile the standard libraries with the GHC API, but I have no idea how/where to look to figure out how?

Thanks,
Bill
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


--
brandon s allbery kf8nh



--
brandon s allbery kf8nh

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: GHC (API?) question: GHC Core for Base libraries

Shao, Cheng
In reply to this post by Bill Hallahan
Indeed, the boot.sh script is likely what you are looking for. To
compile `base` and retrieve Core for it, you just need to set up an
empty package database, use the Setup.hs script in base to compile it,
and load your plugin via "--ghc-option=.." provided to `Setup
configure`.
On Wed, Dec 5, 2018 at 2:37 AM Bill Hallahan <[hidden email]> wrote:

>
> Joachim Breitner's veggies(https://github.com/nomeata/veggies) project is a good example of using a vanilla ghc installation to compile standard libraries like base.
>
> Thanks Cheng, this looks interesting and helpful!  I'm still trying to understand it fully, but it seems like the important pieces for building base are in the boot and Setup scripts?
>
> The problem here is that you're using a stage 1 build, and stage 1 lacks support for the bytecode backend used by TH, plugins, ghci, etc. A base build with a stage 2 compiler should work.
>
> Thanks Brandon.  Is there a recommended/documented way to build base with a stage 2 compiler?  I haven't been able to find anything about this on the wiki.
>
> On Dec 3, 2018, at 11:10 PM, Brandon Allbery <[hidden email]> wrote:
>
> The problem here is that you're using a stage 1 build, and stage 1 lacks support for the bytecode backend used by TH, plugins, ghci, etc. A base build with a stage 2 compiler should work.
>
> On Mon, Dec 3, 2018 at 9:11 PM Bill Hallahan <[hidden email]> wrote:
>>
>> Hi,
>>
>> I'm writing a program analyzer that operates on GHC Core.  Currently, I'm using the GHC API to get Core from .hs files.  I'd like to be able to run this analysis on the standard libraries that come with GHC, which requires getting those as Core.
>>
>> Unfortunately, the build process for these libraries is not entirely straightforward, and relies on a make script.  I eventually came up with the plan of writing a GHC plugin, which, rather than performing any optimizations, would simply run the analysis, and then print the results out to a file.  I was able to write the plugin successfully, and test it on several files that were not from the base library.
>>
>> Then, i turned to modify the GhcLibHcOpts flag in mk/build.mk, so that the make script would call the plugin.  I ended up with the following:
>>
>> GhcLibHcOpts = -package-db /usr/local/lib/ghc-8.0.2/package.conf.d -package-db /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d -package hplugin -fplugin HPlugin.Plugin -v
>>
>> The two package databases are to get to (1) the GHC API and (2) the plugin ("hplugin") itself.  With this I get an error message, which I have not been able to find a way to resolve:
>>
>> "inplace/bin/ghc-stage1" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O -Wall      -this-unit-id ghc-prim-0.5.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/.    -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package-id rts -this-unit-id ghc-prim -XHaskell2010 -package-db /usr/local/lib/ghc-8.0.2/package.conf.d -package-db /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d -package hplugin -fplugin HPlugin.Plugin  -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags     -Wnoncanonical-monad-instances  -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -split-objs  -dynamic-too -c libraries/ghc-prim/./GHC/Types.hs -o libraries/ghc-prim/dist-install/build/GHC/Types.o -dyno libraries/ghc-prim/dist-install/build/GHC/Types.dyn_o
>> <command line>: not built for interactive use - can't load plugins (HPlugin.Plugin)
>> make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Types.o] Error 1
>> make: *** [all] Error 2
>>
>> So I'm now wondering (an answer to either of these two questions would be helpful):
>> (1) Is this a viable path?  That is, is it possible to use a plugin when building Base?  If so, does anyone know what I might be doing wrong/what could be causing this error message?
>> (2) Is there some other better/easier way I could get Core representations of the standard libraries?  I guess, in theory, it must be possible to compile the standard libraries with the GHC API, but I have no idea how/where to look to figure out how?
>>
>> Thanks,
>> Bill
>> _______________________________________________
>> ghc-devs mailing list
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
> --
> brandon s allbery kf8nh
> [hidden email]
>
>
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: GHC (API?) question: GHC Core for Base libraries

Christopher Done-2
In reply to this post by Bill Hallahan
Hi Bill,

I use a different approach, using docker, and that's to use a patched
`Main.hs` (https://github.com/chrisdone/prana/commits/master/ghc-8.0/Main.hs)
and compile GHC with that patched file. It's a little unorthodox but
has so far been highly effective.

Here is a repo of a core interpreter I've been dabbling with:
https://github.com/chrisdone/prana

Here I have a Dockerfile that copies my edited version of `Main.hs`
and builds base, ghc-prim and integer-gmp together into an isolated
package database:
https://github.com/chrisdone/prana/blob/master/Dockerfile.ghc-8.0#L56-L114

My Main.hs writes a .prana file for every module. At the end of the
Dockerfile, I export that to a .tar.gz archive:
https://github.com/chrisdone/prana/blob/master/Dockerfile.ghc-8.0#L113

Then I have a set of scripts
https://github.com/chrisdone/prana/tree/master/scripts
To build the image, and one to copy the libraries to the current
directory under `libraries/`.

Hope that's of some help!
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: GHC (API?) question: GHC Core for Base libraries

Christopher Done-2
Here is the simplest possible way to print core in the Main.hs, by the way:

https://github.com/chrisdone/prana/commit/1303c7bb385a95eef7bb4752997897455853ca72#diff-28e5b5a88ae58fa953c1ad5ab5a7bfe0

That's taking GHC 8.0's Main.hs and patching it.
On Wed, 19 Dec 2018 at 10:50, Christopher Done <[hidden email]> wrote:

>
> Hi Bill,
>
> I use a different approach, using docker, and that's to use a patched
> `Main.hs` (https://github.com/chrisdone/prana/commits/master/ghc-8.0/Main.hs)
> and compile GHC with that patched file. It's a little unorthodox but
> has so far been highly effective.
>
> Here is a repo of a core interpreter I've been dabbling with:
> https://github.com/chrisdone/prana
>
> Here I have a Dockerfile that copies my edited version of `Main.hs`
> and builds base, ghc-prim and integer-gmp together into an isolated
> package database:
> https://github.com/chrisdone/prana/blob/master/Dockerfile.ghc-8.0#L56-L114
>
> My Main.hs writes a .prana file for every module. At the end of the
> Dockerfile, I export that to a .tar.gz archive:
> https://github.com/chrisdone/prana/blob/master/Dockerfile.ghc-8.0#L113
>
> Then I have a set of scripts
> https://github.com/chrisdone/prana/tree/master/scripts
> To build the image, and one to copy the libraries to the current
> directory under `libraries/`.
>
> Hope that's of some help!
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: GHC (API?) question: GHC Core for Base libraries

Bill Hallahan
Thanks!  That's an interesting approach.  I hadn't considered just patching GHC.

> On Dec 19, 2018, at 5:58 AM, Christopher Done <[hidden email]> wrote:
>
> Here is the simplest possible way to print core in the Main.hs, by the way:
>
> https://github.com/chrisdone/prana/commit/1303c7bb385a95eef7bb4752997897455853ca72#diff-28e5b5a88ae58fa953c1ad5ab5a7bfe0
>
> That's taking GHC 8.0's Main.hs and patching it.
> On Wed, 19 Dec 2018 at 10:50, Christopher Done <[hidden email]> wrote:
>>
>> Hi Bill,
>>
>> I use a different approach, using docker, and that's to use a patched
>> `Main.hs` (https://github.com/chrisdone/prana/commits/master/ghc-8.0/Main.hs)
>> and compile GHC with that patched file. It's a little unorthodox but
>> has so far been highly effective.
>>
>> Here is a repo of a core interpreter I've been dabbling with:
>> https://github.com/chrisdone/prana
>>
>> Here I have a Dockerfile that copies my edited version of `Main.hs`
>> and builds base, ghc-prim and integer-gmp together into an isolated
>> package database:
>> https://github.com/chrisdone/prana/blob/master/Dockerfile.ghc-8.0#L56-L114
>>
>> My Main.hs writes a .prana file for every module. At the end of the
>> Dockerfile, I export that to a .tar.gz archive:
>> https://github.com/chrisdone/prana/blob/master/Dockerfile.ghc-8.0#L113
>>
>> Then I have a set of scripts
>> https://github.com/chrisdone/prana/tree/master/scripts
>> To build the image, and one to copy the libraries to the current
>> directory under `libraries/`.
>>
>> Hope that's of some help!

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (859 bytes) Download Attachment