Re: End of Windows Vista support in GHC-8.6?

[Simon Jakobi via ghc-devs]

Thanks a lot, Tamar! I'll make the PR for Hadrian once my patch is accepted.

2018-05-09 20:12 GMT+02:00  :
> I’ve started a build, note that you will also need a PR to Hadrian to update
> WINVER.
>
>
>
> From: Simon Jakobi
> Sent: Wednesday, May 9, 2018 09:49
> To: Phyx
> Cc: Ben Gamari; ghc-devs@haskell.org Devs
> Subject: Re: End of Windows Vista support in GHC-8.6?
>
>
>
> Thanks for the reminder, Tamar!
>
>
>
> I have just created https://phabricator.haskell.org/D4679. I would be
>
> very grateful if you could test it on 32bit Windows.
>
>
>
> Cheers,
>
> Simon
>
>
>
> 2018-05-05 12:07 GMT+02:00 Phyx :
>
>> Hi Simon,
>
>>
>
>> Whatever happened to this? The wiki was updated but I don't see a commit
>
>> actually removing vista support.
>
>>
>
>> Did you end up not doing this anymore?
>
>>
>
>> Thanks,
>
>> Tamar
>
>>
>
>> On Mon, Mar 5, 2018 at 7:21 PM, Simon Jakobi 
>
>> wrote:
>
>>>
>
>>> Thanks everyone!
>
>>>
>
>>> I have updated https://ghc.haskell.org/trac/ghc/wiki/Platforms/Windows
>
>>> accordingly.
>
>>>
>
>>> Cheers,
>
>>> Simon
>
>>>
>
>>> 2018-03-05 18:29 GMT+01:00 Phyx :
>

>

>

>
 On Mon, Mar 5, 2018, 17:23 Ben Gamari  wrote:
>
>
>
> Simon Jakobi via ghc-devs  writes:
>
>
>
> > Hi!
>
> >
>
> > Given that Vista’s EOL was in April 2017
>
> >
>
> >
> > 
>
> > i assume that there’s no intention to keep supporting it in GHC-8.6!?
>
> >
>
> > I’m asking because I intend to use a function
>
> >
>
> >
> > 
>
> > that requires Windows 7 or newer for #13362
>
> > .
>
> >
>
> Given that it's EOL'd, dropping Vista sounds reasonable to me.
>
>
>
> Tamar, any objection?
>

>

>
 No objections, however do make sure to test both 32 and 64 bit builds of
>
 ghc when you use the API, it's new enough and rare enough that it may
 not be
>
 implemented in both mingw-64 tool chains (we've had similar issues
 before).
>

>
 Thanks,
>
 Tamar
>

>
>
>
> Cheers,
>
>
>
> - Ben
>
>>>
>
>>>
>
>>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: TTG hsSyn for Batch and Interactive Parsing

[Alan & Kim Zimmerman]

I have updated the Wiki.

On 9 May 2018 at 10:15, Simon Peyton Jones  wrote:

> Thanks.
>
>
>
> I am absolutely behind this objective:
>
> I propose to move the API Annotations to where they belong, inside the AST.
>
> Indeed I thought that was always part of the TTG plan.
>
>
>
> *But I don’t understand what this has to do with interactive vs batch
> parsing.  *Why don’t you unconditionally retain API-annotation info?  How
> would GhcPs be used differently to GhcPsI?
>
>
>
> You might want to answer by clarifying on the wiki page, so that it is a
> persistent record of the design debugged in dialogue by email.
>
>
>
> Simon
>
>
>
> *From:* Alan & Kim Zimmerman 
> *Sent:* 08 May 2018 21:02
> *To:* Simon Peyton Jones 
> *Cc:* ghc-devs 
> *Subject:* Re: TTG hsSyn for Batch and Interactive Parsing
>
>
>
> I have started a wiki page at https://ghc.haskell.org/trac/ghc/wiki/
> ImplementingTreesThatGrow/IdeSupport
>
>
>
> On 8 May 2018 at 10:54, Simon Peyton Jones  wrote:
>
> At first blush, “running the parser in two modes” and “changing the Pass”
> type don’t match up in my mind.  One seems quite local (how to run the
> parser).  The other seems more pervasive.
>
>
>
> Can you say more about your proposed design, perhaps even on a wiki page?
>
>
>
> Simon
>
>
>
> *From:* ghc-devs  *On Behalf Of *Alan & Kim
> Zimmerman
> *Sent:* 07 May 2018 16:17
> *To:* ghc-devs 
> *Subject:* TTG hsSyn for Batch and Interactive Parsing
>
>
>
> I want to be able to run the GHC parser in one of two modes, batch which
> functions as now, and interactive which will (eventually) be incremental.
>
> In addition, the hsSyn AST for each will have different TTG[1]
> annotations, so that it can better support IDE usage.
>
> I think this can be done by changing the types in HsExtension to introduce
> a 'Process'  type as follows
>
> data Pass = Parsed Process | Renamed | Typechecked
>  deriving (Data)
>
> data Process = Batch | Interactive
>   deriving (Show, Data)
>
> We then rename the pass synonyms so that batch is the default
>
> type GhcPs   = GhcPass ('Parsed 'Batch)
> type GhcPsI  = GhcPass ('Parsed 'Interactive)
>
> I have attached a simple proof of concept file, which emulates parsing and
> renaming.
>
> Is this an appropriate approach to take?
>
> Alan
>
>
>
> [1] Trees That Grow https://ghc.haskell.org/trac/ghc/wiki/
> ImplementingTreesThatGrow
>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: End of Windows Vista support in GHC-8.6?

[Simon Jakobi via ghc-devs]

Thanks for the reminder, Tamar!

I have just created https://phabricator.haskell.org/D4679. I would be
very grateful if you could test it on 32bit Windows.

Cheers,
Simon

2018-05-05 12:07 GMT+02:00 Phyx :
> Hi Simon,
>
> Whatever happened to this? The wiki was updated but I don't see a commit
> actually removing vista support.
>
> Did you end up not doing this anymore?
>
> Thanks,
> Tamar
>
> On Mon, Mar 5, 2018 at 7:21 PM, Simon Jakobi 
> wrote:
>>
>> Thanks everyone!
>>
>> I have updated https://ghc.haskell.org/trac/ghc/wiki/Platforms/Windows
>> accordingly.
>>
>> Cheers,
>> Simon
>>
>> 2018-03-05 18:29 GMT+01:00 Phyx :
>>>
>>>
>>>
>>> On Mon, Mar 5, 2018, 17:23 Ben Gamari  wrote:

 Simon Jakobi via ghc-devs  writes:

 > Hi!
 >
 > Given that Vista’s EOL was in April 2017
 >
 > 
 > i assume that there’s no intention to keep supporting it in GHC-8.6!?
 >
 > I’m asking because I intend to use a function
 >
 > 
 > that requires Windows 7 or newer for #13362
 > .
 >
 Given that it's EOL'd, dropping Vista sounds reasonable to me.

 Tamar, any objection?
>>>
>>>
>>> No objections, however do make sure to test both 32 and 64 bit builds of
>>> ghc when you use the API, it's new enough and rare enough that it may not be
>>> implemented in both mingw-64 tool chains (we've had similar issues before).
>>>
>>> Thanks,
>>> Tamar
>>>

 Cheers,

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

RE: TTG hsSyn for Batch and Interactive Parsing

[Simon Peyton Jones via ghc-devs]

Thanks.

I am absolutely behind this objective:
I propose to move the API Annotations to where they belong, inside the AST.
Indeed I thought that was always part of the TTG plan.

But I don’t understand what this has to do with interactive vs batch parsing.  
Why don’t you unconditionally retain API-annotation info?  How would GhcPs be 
used differently to GhcPsI?

You might want to answer by clarifying on the wiki page, so that it is a 
persistent record of the design debugged in dialogue by email.

Simon

From: Alan & Kim Zimmerman 
Sent: 08 May 2018 21:02
To: Simon Peyton Jones 
Cc: ghc-devs 
Subject: Re: TTG hsSyn for Batch and Interactive Parsing

I have started a wiki page at 
https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/IdeSupport

On 8 May 2018 at 10:54, Simon Peyton Jones 
> wrote:
At first blush, “running the parser in two modes” and “changing the Pass” type 
don’t match up in my mind.  One seems quite local (how to run the parser).  The 
other seems more pervasive.

Can you say more about your proposed design, perhaps even on a wiki page?

Simon

From: ghc-devs 
> On Behalf 
Of Alan & Kim Zimmerman
Sent: 07 May 2018 16:17
To: ghc-devs >
Subject: TTG hsSyn for Batch and Interactive Parsing

I want to be able to run the GHC parser in one of two modes, batch which 
functions as now, and interactive which will (eventually) be incremental.
In addition, the hsSyn AST for each will have different TTG[1] annotations, so 
that it can better support IDE usage.
I think this can be done by changing the types in HsExtension to introduce a 
'Process'  type as follows

data Pass = Parsed Process | Renamed | Typechecked
 deriving (Data)

data Process = Batch | Interactive
  deriving (Show, Data)
We then rename the pass synonyms so that batch is the default

type GhcPs   = GhcPass ('Parsed 'Batch)
type GhcPsI  = GhcPass ('Parsed 'Interactive)
I have attached a simple proof of concept file, which emulates parsing and 
renaming.
Is this an appropriate approach to take?
Alan

[1] Trees That Grow 
https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow

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