Plugin from ghci REPL?

[Conal Elliott]

Is it possible to have GHC plugins get invoked from the ghci *REPL* (in
addition to loaded source modules)? I'm doing some monomorphization-based
transformation, and currently I write scads of trivial monomorphic
specialization definitions like

> sumt6 = sum :: Tree 6 Int -> Int

I'd instead love to enter "let sumt6 = sum :: Tree 6 Int -> Int" or
(better) just "sum :: Tree 6 Int -> Int" into the REPL and have my plugin
run, without having to keep monkeying with a source file and reloading. As
I understand it, an expression is turned into "let it = ...", so maybe the
expression option would come for free with the ability to run plugins on
in-REPL definitions.

-- Conal
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: ghci and unfoldings?

[Conal Elliott]

Oh! I spoke too soon. Yes, that flag does seem to make unfoldings
available. Thanks! Now more experimentation. Thanks again!

-- Conal

On Sun, Jan 17, 2016 at 10:45 PM, Conal Elliott  wrote:

> Thanks for the suggestion. That flag doesn't appear to help. Still no
> unfolding info.
>
> On Sun, Jan 17, 2016 at 10:37 PM, Edward Z. Yang  wrote:
>
>> Does passing -fobject-code solve your problem?
>>
>> Edward
>>
>> Excerpts from Conal Elliott's message of 2016-01-17 22:18:49 -0800:
>> > Hi Brandon. Thanks for the reply. I’m not sure that it addresses what I
>> was
>> > trying to ask. GHCi *does* invoke plugins and even reloads those plugins
>> > dynamically when their source code changes. So in this sense ghci does
>> > enable optimization, even if it doesn’t perform much optimization on its
>> > own. And of course plugins and unfolding are not just about
>> optimization.
>> >
>> > I’m not looking for ghci to do optimization, but rather to enable me to
>> > more easily develop my GHC plugins. It’s *almost* there already. I just
>> > need access to unfoldings from other modules for my plugin’s use.
>> >
>> > For context, I’m rebuilding my Haskell-to-hardware compiler
>> > , which relies
>> on
>> > giving a non-standard but principled interpretation of Haskell programs
>> via
>> > a conversion through the language of cartesian closed categories (CCCs).
>> > The first back-end is hardware generation (e.g., via Verilog), and I
>> have
>> > plans for several other CCC-based interpretations.
>> >
>> > In addition to facilitating my plugin development, hosting in ghci will
>> > make it much more pleasant for others to *use* the plugin during
>> > exploratory programming, just as with ghci use in general. With access
>> to
>> > unfoldings, users will be able to generate circuit diagrams and Verilog
>> > like those in my compiler talk immediately and directly from within
>> ghci. I
>> > also intend to make a GPU back-end for fast interactive graphics etc,
>> which
>> > would be much more fun in ghci than with batch compilation.
>> > I hope this explanation clarifies my goals and motivation. I hope
>> there’s a
>> > way to access unfoldings from ghci currently or with a small amount of
>> > effort.
>> >
>> > Regards, - Conal
>> >
>> > On Sun, Jan 17, 2016 at 7:00 PM, Brandon Allbery 
>> > wrote:
>> >
>> > > On Sun, Jan 17, 2016 at 9:40 PM, Conal Elliott 
>> wrote:
>> > >
>> > >> I'm developing a GHC plugin (using HERMIT), and I'd like to use ghci
>> to
>> > >> speed up development. I'm able to do so, except that my plugin
>> critically
>> > >> needs access to unfoldings, which appear to be unavailable in ghci. A
>> > >> little experimenting with ghc shows me that "-O" is the key, but
>> "-O" is
>> > >> incompatible with "--interactive" (as in ghci). Is there any way to
>> > >> persuade ghci to make unfoldings available?
>> > >
>> > >
>> > > I think unfoldings are only done as part of optimization, and the
>> bytecode
>> > > backend doesn't support optimization at all.
>> > >
>> > > --
>> > > brandon s allbery kf8nh   sine nomine
>> > > associates
>> > > allber...@gmail.com
>> > > ballb...@sinenomine.net
>> > > unix, openafs, kerberos, infrastructure, xmonad
>> > > http://sinenomine.net
>> > >
>>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: ghci and unfoldings?

[Conal Elliott]

Thanks for the suggestion. That flag doesn't appear to help. Still no
unfolding info.

On Sun, Jan 17, 2016 at 10:37 PM, Edward Z. Yang  wrote:

> Does passing -fobject-code solve your problem?
>
> Edward
>
> Excerpts from Conal Elliott's message of 2016-01-17 22:18:49 -0800:
> > Hi Brandon. Thanks for the reply. I’m not sure that it addresses what I
> was
> > trying to ask. GHCi *does* invoke plugins and even reloads those plugins
> > dynamically when their source code changes. So in this sense ghci does
> > enable optimization, even if it doesn’t perform much optimization on its
> > own. And of course plugins and unfolding are not just about optimization.
> >
> > I’m not looking for ghci to do optimization, but rather to enable me to
> > more easily develop my GHC plugins. It’s *almost* there already. I just
> > need access to unfoldings from other modules for my plugin’s use.
> >
> > For context, I’m rebuilding my Haskell-to-hardware compiler
> > , which relies
> on
> > giving a non-standard but principled interpretation of Haskell programs
> via
> > a conversion through the language of cartesian closed categories (CCCs).
> > The first back-end is hardware generation (e.g., via Verilog), and I have
> > plans for several other CCC-based interpretations.
> >
> > In addition to facilitating my plugin development, hosting in ghci will
> > make it much more pleasant for others to *use* the plugin during
> > exploratory programming, just as with ghci use in general. With access to
> > unfoldings, users will be able to generate circuit diagrams and Verilog
> > like those in my compiler talk immediately and directly from within
> ghci. I
> > also intend to make a GPU back-end for fast interactive graphics etc,
> which
> > would be much more fun in ghci than with batch compilation.
> > I hope this explanation clarifies my goals and motivation. I hope
> there’s a
> > way to access unfoldings from ghci currently or with a small amount of
> > effort.
> >
> > Regards, - Conal
> >
> > On Sun, Jan 17, 2016 at 7:00 PM, Brandon Allbery 
> > wrote:
> >
> > > On Sun, Jan 17, 2016 at 9:40 PM, Conal Elliott 
> wrote:
> > >
> > >> I'm developing a GHC plugin (using HERMIT), and I'd like to use ghci
> to
> > >> speed up development. I'm able to do so, except that my plugin
> critically
> > >> needs access to unfoldings, which appear to be unavailable in ghci. A
> > >> little experimenting with ghc shows me that "-O" is the key, but "-O"
> is
> > >> incompatible with "--interactive" (as in ghci). Is there any way to
> > >> persuade ghci to make unfoldings available?
> > >
> > >
> > > I think unfoldings are only done as part of optimization, and the
> bytecode
> > > backend doesn't support optimization at all.
> > >
> > > --
> > > brandon s allbery kf8nh   sine nomine
> > > associates
> > > allber...@gmail.com
> > > ballb...@sinenomine.net
> > > unix, openafs, kerberos, infrastructure, xmonad
> > > http://sinenomine.net
> > >
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: ghci and unfoldings?

[Edward Z. Yang]

Does passing -fobject-code solve your problem?

Edward

Excerpts from Conal Elliott's message of 2016-01-17 22:18:49 -0800:
> Hi Brandon. Thanks for the reply. I’m not sure that it addresses what I was
> trying to ask. GHCi *does* invoke plugins and even reloads those plugins
> dynamically when their source code changes. So in this sense ghci does
> enable optimization, even if it doesn’t perform much optimization on its
> own. And of course plugins and unfolding are not just about optimization.
> 
> I’m not looking for ghci to do optimization, but rather to enable me to
> more easily develop my GHC plugins. It’s *almost* there already. I just
> need access to unfoldings from other modules for my plugin’s use.
> 
> For context, I’m rebuilding my Haskell-to-hardware compiler
> , which relies on
> giving a non-standard but principled interpretation of Haskell programs via
> a conversion through the language of cartesian closed categories (CCCs).
> The first back-end is hardware generation (e.g., via Verilog), and I have
> plans for several other CCC-based interpretations.
> 
> In addition to facilitating my plugin development, hosting in ghci will
> make it much more pleasant for others to *use* the plugin during
> exploratory programming, just as with ghci use in general. With access to
> unfoldings, users will be able to generate circuit diagrams and Verilog
> like those in my compiler talk immediately and directly from within ghci. I
> also intend to make a GPU back-end for fast interactive graphics etc, which
> would be much more fun in ghci than with batch compilation.
> I hope this explanation clarifies my goals and motivation. I hope there’s a
> way to access unfoldings from ghci currently or with a small amount of
> effort.
> 
> Regards, - Conal
> 
> On Sun, Jan 17, 2016 at 7:00 PM, Brandon Allbery 
> wrote:
> 
> > On Sun, Jan 17, 2016 at 9:40 PM, Conal Elliott  wrote:
> >
> >> I'm developing a GHC plugin (using HERMIT), and I'd like to use ghci to
> >> speed up development. I'm able to do so, except that my plugin critically
> >> needs access to unfoldings, which appear to be unavailable in ghci. A
> >> little experimenting with ghc shows me that "-O" is the key, but "-O" is
> >> incompatible with "--interactive" (as in ghci). Is there any way to
> >> persuade ghci to make unfoldings available?
> >
> >
> > I think unfoldings are only done as part of optimization, and the bytecode
> > backend doesn't support optimization at all.
> >
> > --
> > brandon s allbery kf8nh   sine nomine
> > associates
> > allber...@gmail.com
> > ballb...@sinenomine.net
> > unix, openafs, kerberos, infrastructure, xmonad
> > http://sinenomine.net
> >
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: ghci and unfoldings?

[Conal Elliott]

Hi Brandon. Thanks for the reply. I’m not sure that it addresses what I was
trying to ask. GHCi *does* invoke plugins and even reloads those plugins
dynamically when their source code changes. So in this sense ghci does
enable optimization, even if it doesn’t perform much optimization on its
own. And of course plugins and unfolding are not just about optimization.

I’m not looking for ghci to do optimization, but rather to enable me to
more easily develop my GHC plugins. It’s *almost* there already. I just
need access to unfoldings from other modules for my plugin’s use.

For context, I’m rebuilding my Haskell-to-hardware compiler
, which relies on
giving a non-standard but principled interpretation of Haskell programs via
a conversion through the language of cartesian closed categories (CCCs).
The first back-end is hardware generation (e.g., via Verilog), and I have
plans for several other CCC-based interpretations.

In addition to facilitating my plugin development, hosting in ghci will
make it much more pleasant for others to *use* the plugin during
exploratory programming, just as with ghci use in general. With access to
unfoldings, users will be able to generate circuit diagrams and Verilog
like those in my compiler talk immediately and directly from within ghci. I
also intend to make a GPU back-end for fast interactive graphics etc, which
would be much more fun in ghci than with batch compilation.
I hope this explanation clarifies my goals and motivation. I hope there’s a
way to access unfoldings from ghci currently or with a small amount of
effort.

Regards, - Conal

On Sun, Jan 17, 2016 at 7:00 PM, Brandon Allbery 
wrote:

> On Sun, Jan 17, 2016 at 9:40 PM, Conal Elliott  wrote:
>
>> I'm developing a GHC plugin (using HERMIT), and I'd like to use ghci to
>> speed up development. I'm able to do so, except that my plugin critically
>> needs access to unfoldings, which appear to be unavailable in ghci. A
>> little experimenting with ghc shows me that "-O" is the key, but "-O" is
>> incompatible with "--interactive" (as in ghci). Is there any way to
>> persuade ghci to make unfoldings available?
>
>
> I think unfoldings are only done as part of optimization, and the bytecode
> backend doesn't support optimization at all.
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: ghci and unfoldings?

[Brandon Allbery]

On Sun, Jan 17, 2016 at 9:40 PM, Conal Elliott  wrote:

> I'm developing a GHC plugin (using HERMIT), and I'd like to use ghci to
> speed up development. I'm able to do so, except that my plugin critically
> needs access to unfoldings, which appear to be unavailable in ghci. A
> little experimenting with ghc shows me that "-O" is the key, but "-O" is
> incompatible with "--interactive" (as in ghci). Is there any way to
> persuade ghci to make unfoldings available?


I think unfoldings are only done as part of optimization, and the bytecode
backend doesn't support optimization at all.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

ghci and unfoldings?

[Conal Elliott]

I'm developing a GHC plugin (using HERMIT), and I'd like to use ghci to
speed up development. I'm able to do so, except that my plugin critically
needs access to unfoldings, which appear to be unavailable in ghci. A
little experimenting with ghc shows me that "-O" is the key, but "-O" is
incompatible with "--interactive" (as in ghci). Is there any way to
persuade ghci to make unfoldings available?

Thanks, - Conal
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Trac internal error

[Edward Z. Yang]

When I posted the (attached) POST request to newticket, I got the
following error.  It did correctly add the ticket to the
database.  I've elided the form token from this.

Trac detected an internal error:

AttributeError: 'NoneType' object has no attribute 'split'

Here's the contents of the POST request (my guess is that I put
something bad in the CC field):

field_summary=Turn+on+SplitSections+by+default
field_reporter=ezyang
field_description=This+is+a+general+tracking+bug+for+what+is+blocking+us+from+turning+on+`SplitSections`+by+default,+implemented+in+#8405.+Fixing+this,+and+mandating+use+of+the+gold+linker,+will+help+solve+#11285+(split+objects+make+linking+slow),+and+will+make+ghc-split+unnecessary,+mooting+#9832.

I+encountered+some+misinformation+while+talking+to+people+about+this+feature,+regarding+whether+or+not+this+feature+only+supported+by+Apple-style+linkers+(i.e.+on+Mac+OS+X)?+On+IRC+I+heard+a+claim+made+that+`--split-sections`+was+only+supported+by+Mac+OS+X.+However,+olsner+pointed+out+that+`-split-sections`+on+GHC+was+OUR+reimplementation+of+the+feature,+and+likely+does+not+work+on+Mac+OS+X.+https://github.com/snowleopard/shaking-up-ghc/issues/153#issuecomment-171078800++A+later+comment+mentioned+that+

So,+can+we+turn+on+this+feature+by+default?+Does+it+subsume+split-objs?+Does+it+work+on+all+the+tier-1+platforms?+It+would+be+nice+if+bgamari,+olsner+and+co+could+weigh+in+here.+Thanks!
field_type=task
field_priority=normal
field_milestone=8.2.1
field_component=Build+System
field_version=8.0.1-rc1
field_keywords
field_cc=bgamari,+olsner
field_os=Unknown/Multiple
field_architecture=Unknown/Multiple
field_failure=None/Unknown
field_testcase
field_blockedby
field_blocking=#11285
field_related
field_differential
field_wikipage
field_owner=<+default+>
sfp_email
sfph_mail
submit=Create+ticket
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Multiple GHC sessions

[Ben Gamari]

Alan & Kim Zimmerman  writes:

> At the moment there are issues with having multiple GHC API sessions
> in a single executable, which boil down to GHC having global
> variables.
>
> A quick grep over the GHC sources shows the following instances
>
> compiler/ghci/Linker.hs:90:GLOBAL_VAR_M(v_PersistentLinkerState, ...
> compiler/ghci/Linker.hs:91:GLOBAL_VAR(v_InitLinkerDone, 
>
This isn't the only global state had by the linker; have a look at
rts/Linker.c. Unfortunately this would take a fair amount of work to
resolve. The easiest solution here would probably be to put a lock
around the linker and have all sessions in a process use the same
linker.

> compiler/main/StaticFlags.hs:94:GLOBAL_VAR(v_opt_C, 
> compiler/main/StaticFlags.hs:95:GLOBAL_VAR(v_opt_C_ready, 
>
We've been meaning to get rid of the remaining static flags for quite
some time.

I was a bit surprised to find that opt_NoStateHack is static. This is a
bit of an ugly one: the only user is a test in Id.isStateHackType which
is buried inside several layers [1] of pure predicates that have no
DynFlags. It would be a shame to pass a DynFlags through all of these
calls just to support the state hack (which we threaten drop about once
every six months).

One option, of course, would be to merge all of the static flags into
DynFlags and rework their users to use unsafeGlobalDynFlags.

[1] One particular callpath is,

Id.isStateHackType
Id.typeOneShot
CoreArity.typeArity
CoreArity.exprArity
CorePrep.rhsToBody
CorePrep.cpeBody


> compiler/main/DynFlags.hs:4453:GLOBAL_VAR(v_unsafeGlobalDynFlags,
>
The principle user of this is Outputable, which uses it to provide
DynFlags for pprTrace and friends. As you say, these are rather special
cases and it's probably fine if they behave a bit funky in the case of
more than one session in a process.

> ghc/GHCi/UI.hs:149:GLOBAL_VAR(macros_ref,
>
It is completely unclear why this is global at all. It seems like it
would fit just fine in the GHCi monad. I've opened D1789 doing exactly
this.

There may be other global state that I'm not thinking of, but if this is
everything then it seems quite possible to fix this up for 8.2.

Cheers,

- Ben


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Phab failing to apply patches

[Jan Stolarek]

Can we somehow force Phab to apply a patch against a base commit from which the 
patch was created? 
Current setting does not seem very useful - it will probably force me to rebase 
my patches once a 
week or so. That will be very painful.

Janek

Dnia piątek, 15 stycznia 2016, Thomas Miedema napisał:
> It changed some time last year.
>
> Before, Harbormaster would sometimes try to build some bizarro intermediate
> mix of base commit + patch + master. See
> https://ghc.haskell.org/trac/ghc/ticket/9855.
>
>
> On Fri, Jan 15, 2016 at 7:06 PM, Jan Stolarek 
>
> wrote:
> > Somehow I always I believed that Harbormaster does not apply a patch onto
> > master but onto the
> > revision it was created from. Has there been any change in this behaviour
> > recently?
> >
> > Janek
> >
> > Dnia piątek, 15 stycznia 2016, Thomas Miedema napisał:
> > > "Unable to apply patch!" means just that. Harbormaster is unable to
> > > apply the patch (to master). You can test it yourself by running 'arc
> > > patch --nobranch D1778` on an up-to-date checkout of the master branch,
> > > and it will fail in the same way.
> > >
> > > Solution: rebase your patch onto master, and update the Diff. You'll
> >
> > notice
> >
> > > there are indeed merge problems.
> > >
> > >
> > > On Fri, Jan 15, 2016 at 6:49 PM, Jan Stolarek 
> > >
> > > wrote:
> > > > It seems that Phab is once again failing to apply patches (eg. D1778,
> > > > which built perfectly fine
> > > > until latest update). Is anyone else experiencing this?
> > > >
> > > > Janek
> > > >
> > > > ---
> > > > Politechnika Łódzka
> > > > Lodz University of Technology
> > > >
> > > > Treść tej wiadomości zawiera informacje przeznaczone tylko dla
> >
> > adresata.
> >
> > > > Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją
> > > > przez pomyłkę
> > > > prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
> > > >
> > > > This email contains information intended solely for the use of the
> > > > individual to whom it is addressed.
> > > > If you are not the intended recipient or if you have received this
> > > > message in error,
> > > > please notify the sender and delete it from your system.
> > > > ___
> > > > ghc-devs mailing list
> > > > ghc-devs@haskell.org
> > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> > ---
> > Politechnika Łódzka
> > Lodz University of Technology
> >
> > Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
> > Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez
> > pomyłkę
> > prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
> >
> > This email contains information intended solely for the use of the
> > individual to whom it is addressed.
> > If you are not the intended recipient or if you have received this
> > message in error,
> > please notify the sender and delete it from your system.



---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Multiple GHC sessions

[Alan & Kim Zimmerman]

Yes, but this solution is bypassing the problem by using remote execution.

My question is what could be done to make the remote execution
unnecessary, i.e addressing the "Right now" part.

Alan

On Sun, Jan 17, 2016 at 4:58 PM, Bartosz Nitka  wrote:
> From https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi:
> "We can have multiple instances of a GHC Session on the GHC API, each
> running TH and/or interpreted code. Right now this is not possible because
> the linker's state is global."
>
> Regards,
> Bartosz
>
> 2016-01-17 14:49 GMT+00:00 Alan & Kim Zimmerman :
>>
>> At the moment there are issues with having multiple GHC API sessions
>> in a single executable, which boil down to GHC having global
>> variables.
>>
>> A quick grep over the GHC sources shows the following instances
>>
>> compiler/ghci/Linker.hs:90:GLOBAL_VAR_M(v_PersistentLinkerState, ...
>> compiler/ghci/Linker.hs:91:GLOBAL_VAR(v_InitLinkerDone, 
>>
>> compiler/main/StaticFlags.hs:94:GLOBAL_VAR(v_opt_C, 
>> compiler/main/StaticFlags.hs:95:GLOBAL_VAR(v_opt_C_ready, 
>>
>> compiler/main/DynFlags.hs:4453:GLOBAL_VAR(v_unsafeGlobalDynFlags,
>>
>> ghc/GHCi/UI.hs:149:GLOBAL_VAR(macros_ref,
>>
>> Of these the v_unsafeGlobalDynFlags can probably be ignored, as they
>> are intended to be used in very specific, limited circumstances only.
>>
>> So, would it be possible to create a structure housing the remaining
>> ones, and somehow make it possible to access these in some kind of
>> session? Or preferably get rid of them, or move them into existing
>> structures such as DynFlags.
>>
>> This is an exploratory email, more to get a handle on what has been
>> done/considered already in this space.
>>
>> The issue does have a major impact on tooling developers though.
>>
>> Regards
>>   Alan
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Multiple GHC sessions

[Bartosz Nitka]

>From https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi:
"We can have multiple instances of a GHC Session on the GHC API, each
running TH and/or interpreted code. Right now this is not possible because
the linker's state is global."

Regards,
Bartosz

2016-01-17 14:49 GMT+00:00 Alan & Kim Zimmerman :

> At the moment there are issues with having multiple GHC API sessions
> in a single executable, which boil down to GHC having global
> variables.
>
> A quick grep over the GHC sources shows the following instances
>
> compiler/ghci/Linker.hs:90:GLOBAL_VAR_M(v_PersistentLinkerState, ...
> compiler/ghci/Linker.hs:91:GLOBAL_VAR(v_InitLinkerDone, 
>
> compiler/main/StaticFlags.hs:94:GLOBAL_VAR(v_opt_C, 
> compiler/main/StaticFlags.hs:95:GLOBAL_VAR(v_opt_C_ready, 
>
> compiler/main/DynFlags.hs:4453:GLOBAL_VAR(v_unsafeGlobalDynFlags,
>
> ghc/GHCi/UI.hs:149:GLOBAL_VAR(macros_ref,
>
> Of these the v_unsafeGlobalDynFlags can probably be ignored, as they
> are intended to be used in very specific, limited circumstances only.
>
> So, would it be possible to create a structure housing the remaining
> ones, and somehow make it possible to access these in some kind of
> session? Or preferably get rid of them, or move them into existing
> structures such as DynFlags.
>
> This is an exploratory email, more to get a handle on what has been
> done/considered already in this space.
>
> The issue does have a major impact on tooling developers though.
>
> Regards
>   Alan
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Multiple GHC sessions

[Alan & Kim Zimmerman]

At the moment there are issues with having multiple GHC API sessions
in a single executable, which boil down to GHC having global
variables.

A quick grep over the GHC sources shows the following instances

compiler/ghci/Linker.hs:90:GLOBAL_VAR_M(v_PersistentLinkerState, ...
compiler/ghci/Linker.hs:91:GLOBAL_VAR(v_InitLinkerDone, 

compiler/main/StaticFlags.hs:94:GLOBAL_VAR(v_opt_C, 
compiler/main/StaticFlags.hs:95:GLOBAL_VAR(v_opt_C_ready, 

compiler/main/DynFlags.hs:4453:GLOBAL_VAR(v_unsafeGlobalDynFlags,

ghc/GHCi/UI.hs:149:GLOBAL_VAR(macros_ref,

Of these the v_unsafeGlobalDynFlags can probably be ignored, as they
are intended to be used in very specific, limited circumstances only.

So, would it be possible to create a structure housing the remaining
ones, and somehow make it possible to access these in some kind of
session? Or preferably get rid of them, or move them into existing
structures such as DynFlags.

This is an exploratory email, more to get a handle on what has been
done/considered already in this space.

The issue does have a major impact on tooling developers though.

Regards
  Alan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs