Re: Options for targeting Windows XP?

[Clinton Mead]

Thanks again for the detailed reply Ben.

I guess the other dream of mine is to give GHC a .NET backend. For my
problem it would be the ideal solution, but it looks like other attempts in
this regard (e.g. Eta, GHCJS etc) seem to have difficulty keeping up with
updates to GHC. So I'm sure it's not trivial.

It would be quite lovely though if I could generate .NET + Java + even
Python bytecode from GHC.

Whilst not solving my immediate problem, perhaps my efforts are best spent
in giving GHC a plugin architecture for backends (or if one already
exists?) trying to make a .NET backend.

I believe "Csaba Hruska" is working in this space with GRIN, yes?

I read SPJs paper on Implementing Lazy Functional Languages on Stock
Hardware: The Spineless Tagless G-machine

which
implemented STG in C and whilst it wasn't trivial, it didn't seem
stupendously complex (even I managed to roughly follow it). I thought to
myself also, implementing this in .NET would be even easier because I can
hand off garbage collection to the .NET runtime so there's one less thing
to worry about. I also, initially, don't care _too_ much about performance.

Of course, there's probably a whole bunch of nuance. One actually needs to,
for example, represent all the complexities of GADTs into object orientated
classes, maybe converting sum types to inheritance hierarchies with Visitor
Patterns. And also you'd actually have to make sure to do one's best to
ensure exposed Haskell functions look like something sensible.

So I guess, given I have a bit of an interest here, what would be the best
approach if I wanted to help GHC develop more backends and into an
architecture where people can add backends without forking GHC? Where could
I start helping that effort? Should I contact "Csaba Hruska" and get
involved in GRIN? Or is there something that I can start working on in GHC
proper?

Considering that I've been playing around with Haskell since 2002, and I'd
like to actually get paid to write it at some point in my career, and I
have an interest in this area, perhaps this is a good place to start, and
actually helping to develop a pluggable backend architecture for GHC may be
more useful for more people over the long term than trying to hack up an
existing GHC to support 32 bit Windows XP, a battle I suspect will have to
be refought every time a new GHC version is released given the current
structure of GHC.

On Fri, Mar 26, 2021 at 1:34 PM Ben Gamari  wrote:

> Clinton Mead  writes:
>
> > Thanks all for your replies. Just going through what Ben has said step by
> > step:
> >
> > My sense is that if you don't need the threaded runtime system it would
> >> probably be easiest to just try to make a modern GHC run on Windows XP.
> >>
> >
> > Happy to run non-threaded runtime. A good chunk of these machines will be
> > single or dual core anyway.
> >
> That indeed somewhat simplifies things.
>
> >> As Tamar suggested, it likely not easy, but also not impossible. WinIO
> >> is indeed problematic, but thankfully the old MIO IO manager is still
> >> around (and will be in 9.2).
> >>
> >
> > "Is still around"? As in it's in the code base and just dead code, or
> can I
> > trigger GHC to use the old IO manager with a GHC option?
> >
> > The possible reasons for Windows XP incompatibility that I can think of
> >> off the top of my head are:
> >>
> >>  * Timers (we now use QueryPerformanceCounter)
> >>
> >
> > This page suggests that QueryPerformanceCounter
> > <
> https://docs.microsoft.com/en-us/windows/win32/api/profileapi/nf-profileapi-queryperformancecounter
> >
> > should
> > run on XP. Is this incorrect?
> >
> It's supported, but there are caveats [1] that make it unreliable as a
> timesource.
>
> [1]
> https://docs.microsoft.com/en-us/windows/win32/sysinfo/acquiring-high-resolution-time-stamps#windowsxp-and-windows2000
> >
> >>  * Big-PE support, which is very much necessary for profiled builds
> >>
> >
> > I don't really need profiled builds
> >
>
> Alright, then you *probably* won't be affected by PE's symbol limit.
>
> >>  * Long file path support (mostly a build-time consideration as Haskell
> >>build systems tend to produce very long paths)
> >>
> >>
> > I don't need to build on Windows XP either. I just need to run on Windows
> > XP so hopefully this won't be an issue. Although if GHC was modified for
> > long file path support so it could build itself with long file path
> support
> > presumably it will affect everything else it builds also.
> >
> If you don't need to build on XP then I suspect this won't affect you.
>
> >
> >> There may be others, but I would start looking there. I am happy to
> >> answer any questions that might arise.
> >>
> > I'm guessing the way forward here might be a patch with two options:
> >
> > 1. -no-long-path-support/-long-path-support (default -long-path-support)
> > 

Re: Options for targeting Windows XP?

[Ben Gamari]

Clinton Mead  writes:

> Thanks all for your replies. Just going through what Ben has said step by
> step:
>
> My sense is that if you don't need the threaded runtime system it would
>> probably be easiest to just try to make a modern GHC run on Windows XP.
>>
>
> Happy to run non-threaded runtime. A good chunk of these machines will be
> single or dual core anyway.
>
That indeed somewhat simplifies things.

>> As Tamar suggested, it likely not easy, but also not impossible. WinIO
>> is indeed problematic, but thankfully the old MIO IO manager is still
>> around (and will be in 9.2).
>>
>
> "Is still around"? As in it's in the code base and just dead code, or can I
> trigger GHC to use the old IO manager with a GHC option?
>
> The possible reasons for Windows XP incompatibility that I can think of
>> off the top of my head are:
>>
>>  * Timers (we now use QueryPerformanceCounter)
>>
>
> This page suggests that QueryPerformanceCounter
> 
> should
> run on XP. Is this incorrect?
>
It's supported, but there are caveats [1] that make it unreliable as a 
timesource.

[1] 
https://docs.microsoft.com/en-us/windows/win32/sysinfo/acquiring-high-resolution-time-stamps#windowsxp-and-windows2000
>
>>  * Big-PE support, which is very much necessary for profiled builds
>>
>
> I don't really need profiled builds
>

Alright, then you *probably* won't be affected by PE's symbol limit.

>>  * Long file path support (mostly a build-time consideration as Haskell
>>build systems tend to produce very long paths)
>>
>>
> I don't need to build on Windows XP either. I just need to run on Windows
> XP so hopefully this won't be an issue. Although if GHC was modified for
> long file path support so it could build itself with long file path support
> presumably it will affect everything else it builds also.
>
If you don't need to build on XP then I suspect this won't affect you.

>
>> There may be others, but I would start looking there. I am happy to
>> answer any questions that might arise.
>>
> I'm guessing the way forward here might be a patch with two options:
>
> 1. -no-long-path-support/-long-path-support (default -long-path-support)
> 2. -winxp
>
> The winxp option shall:
>
> - Require -no-long-path-support
> - Conflicts with -threaded
> - Conflicts with profiled builds
> - Uses the old IO manager (I'm not sure if this is an option or how this is
> done).
>
The old IO manager is still the default, although this will likely
change in 9.2.

> What do you think (roughly speaking)?

Yes, that is essentially correct. I would probably start by trying to
run a 32-bit GHC build on Windows XP under gdb and see where
things fall over.

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: Options for targeting Windows XP?

[Ben Gamari]

Clinton Mead  writes:

> Another gotcha that I didn't think of. The machines I'm targeting often
> have 32 bit versions of Windows, which it looks like isn't supported after
> GHC 8.6.
>
> Does this move it into the too hard basket?

Ooph, yeah, this makes matters a bit worse. The reason we
ultimately dropped 32-bit Windows support wasn't even a GHC bug;
rather, a (rather long-standing at this point) bug in binutils
(#17961) which made it impossible to reliably produce binary
distributions.

My recollection is that this but only affected builds of the object
files used by GHCi. If you don't use GHCi then you can likely disable
the production of these objects.

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: HLint in the GHC CI, an eight-months retrospective

[Richard Eisenberg]

Thanks for this update! Glad to know this effort is going well.

One quick question: suppose I am editing something in `base`. My understanding 
is that my edit will be linted. How can I run hlint locally so that I can 
easily respond to trouble before CI takes a crack? And where would I learn this 
information (that is, how to run hlint locally)?

Thanks!
Richard

> On Mar 25, 2021, at 11:19 AM, Hécate  wrote:
> 
> Hello fellow devs,
> 
> this email is an activity report on the integration of the HLint[0] tool in 
> the Continuous Integration (CI) pipelines.
> 
> On Jul. 5, 2020 I opened a discussion ticket[1] on the topic of code linting 
> in the several components of the GHC code-base. It has served as a reference 
> anchor for the Merge Requests (MR) that stemmed from it, and allowed us to 
> refine our expectations and processes. If you are not acquainted with its 
> content, I invite you to read the whole conversation.
> 
> Subsequently, several Hadrian lint rules have been integrated in the 
> following months, in order to run HLint on targeted components of the GHC 
> repository (the base library, the compiler code-base, etc).
> Being satisfied with the state of the rules we applied to the code-base, such 
> as removing extraneous pragmata and keywords, it was decided to integrate the 
> base library linting rule in the CI. This was five months ago, in 
> September[2], and I am happy to report that developer friction has been so 
> far minimal.
> In parallel to this work on the base library, I took care of cleaning-up the 
> compiler, and harmonised the various micro coding styles that have emerged 
> quite organically during the decades of development that are behind us (I 
> never realised how many variations of the same ten lines of pragmata could 
> coexist in the same folders).
> Upon feedback from stakeholders of this sub-code base, the rules file was 
> altered to better suit their development needs, such as not removing 
> extraneous `do` keywords, as they are useful to introduce a block in which 
> debug statements can be easily inserted.
> 
> Since today, the linting of the compiler code-base has been integrated in our 
> CI pipelines, without further burdening our CI times.
> Things seem to run smoothly, and I welcome comments and requests of any kind 
> related to this area of our code quality process.
> 
> Regarding our future plans, there has been a discussion about integrating 
> such a linting mechanism for our C code-base, in the RTS. Nothing is formally 
> established yet, so I would be grateful if people who have experience and 
> wisdom about it can chime in to contribute to the discussion: 
> https://gitlab.haskell.org/ghc/ghc/-/issues/19437.
> 
> And I would like to say that I am overall very thankful for the involvement 
> of the people who have been giving us feedback and have been reviewing the 
> resulting MRs.
> 
> Have a very nice day,
> Hécate
> 
> ---
> [0]: https://github.com/ndmitchell/hlint
> [1]: https://gitlab.haskell.org/ghc/ghc/-/issues/18424
> [2]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4147
> 
> -- 
> Hécate ✨
> : @TechnoEmpress
> IRC: Uniaika
> WWW: https://glitchbra.in
> RUN: BSD
> 
> ___
> 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: Options for targeting Windows XP?

[Clinton Mead]

Another gotcha that I didn't think of. The machines I'm targeting often
have 32 bit versions of Windows, which it looks like isn't supported after
GHC 8.6.

Does this move it into the too hard basket?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

HLint in the GHC CI, an eight-months retrospective

[Hécate]

Hello fellow devs,

this email is an activity report on the integration of the HLint[0] tool 
in the Continuous Integration (CI) pipelines.


On Jul. 5, 2020 I opened a discussion ticket[1] on the topic of code 
linting in the several components of the GHC code-base. It has served as 
a reference anchor for the Merge Requests (MR) that stemmed from it, and 
allowed us to refine our expectations and processes. If you are not 
acquainted with its content, I invite you to read the whole conversation.


Subsequently, several Hadrian lint rules have been integrated in the 
following months, in order to run HLint on targeted components of the 
GHC repository (the base library, the compiler code-base, etc).
Being satisfied with the state of the rules we applied to the code-base, 
such as removing extraneous pragmata and keywords, it was decided to 
integrate the base library linting rule in the CI. This was five months 
ago, in September[2], and I am happy to report that developer friction 
has been so far minimal.
In parallel to this work on the base library, I took care of cleaning-up 
the compiler, and harmonised the various micro coding styles that have 
emerged quite organically during the decades of development that are 
behind us (I never realised how many variations of the same ten lines of 
pragmata could coexist in the same folders).
Upon feedback from stakeholders of this sub-code base, the rules file 
was altered to better suit their development needs, such as not removing 
extraneous `do` keywords, as they are useful to introduce a block in 
which debug statements can be easily inserted.


Since today, the linting of the compiler code-base has been integrated 
in our CI pipelines, without further burdening our CI times.
Things seem to run smoothly, and I welcome comments and requests of any 
kind related to this area of our code quality process.


Regarding our future plans, there has been a discussion about 
integrating such a linting mechanism for our C code-base, in the RTS. 
Nothing is formally established yet, so I would be grateful if people 
who have experience and wisdom about it can chime in to contribute to 
the discussion: https://gitlab.haskell.org/ghc/ghc/-/issues/19437.


And I would like to say that I am overall very thankful for the 
involvement of the people who have been giving us feedback and have been 
reviewing the resulting MRs.


Have a very nice day,
Hécate

---
[0]: https://github.com/ndmitchell/hlint
[1]: https://gitlab.haskell.org/ghc/ghc/-/issues/18424
[2]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4147

--
Hécate ✨
: @TechnoEmpress
IRC: Uniaika
WWW: https://glitchbra.in
RUN: BSD

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