This must be a recent development, because I installed Haskell using the "self-contained, all-in-one installer" only a month or two ago. The page on haskell.org still talks about this: "The Haskell Platform is a self-contained, all-in-one installer. After download, you will have everything necessary to build Haskell programs against a core set of useful libraries." (That really should be edited to reflect the current state of affairs.) On 2020-04-25 12:27 a.m., Richard O'Keefe wrote:

I ran into the same 403 with HaskellStack.org, but using the "Cached" link that Google offered, the page that *should* be there has a link to a Windows 64-bit installer for stack, and stack is currently installing ghc-8.8.3 for me, although it warns that stack has not been tested with GHC versions about 8.6.

The irony is that I ran stack.exe from an Ubuntu 18 shell.

On Sat, 25 Apr 2020 at 15:24, José Pedro Magalhães mailto:dreixel@gmail.com> wrote:

Hi,

I haven't used Haskell in my personal computer in a while. I decided to install it again. I used the Haskell Platform in the past, so I went for that again - and a quick Google search on "install haskell windows" brings up the HP page, so I thought I was on the right track.

At the HP page for Windows, I'm greeted with this: image.png

In the past I'd just download an installer which would take care of things - now it seems to be more complicated. But fine, I followed the link to configure Chocolatey. That's where it starts getting really scary: image.png

First, I have to subscribe to a newsletter? Really? I guess this is entirely optional, but the instructions don't make it sound so. Then I have to know what powershell.exe is, use an administrative prompt, and enter scary commands in it.

I gave up at this stage. But going back to the HP page, it appears that even this wouldn't be enough, because I would still need to follow "the instructions at haskellstack.org http://haskellstack.org to install stack". The link to haskellstack.org http://haskellstack.org takes me to a 403 Forbidden https://docs.haskellstack.org/en/stable/README/.

I honestly don't want this to sound like a rant. I genuinely would like to understand why this multi-step, multi-tool, multi-website process was introduced, how it is superior to a single installer, and whether this is really the process we want newcomers to the language have to follow.

Thanks, Pedro _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

On Sat, 25 Apr 2020, lonetiger@gmail.com wrote:

Yes, this was changed recently as it provides a way to manage all 3 components individually.

Friends, could you please stop including the pictures from the original posts? Even more than once ...

I'll give my perspective below. Not being intimately familiar with the Platform's Windows packaging effort, some of this may not be spot-on. However, I do think I have some context that lennart spitzner writes:

On 25/04/2020 11:20, lonetiger@gmail.com wrote:

...

Yes, this was changed recently as it provides a way to manage all 3 components individually. As in should you want to you can have any number of versions of GHC installed at the same time.

By decoupling the components it allows for quicker updates and releases and for a better user experience. Platform was for instance still using GHC 8.6.5 and cabal 3.0.

For the record these packages aren’t new, they’re only now being recommended.

[snip] Having looked at the Chocolatey installation instructions, I will agree that they are a bit rough, particularly in the case of a user without administrative access. However, the benefits of piggy-backing on Chocolatey seem significant: * having worked on projects which were locked to a particular GHC version, I can attest that multiple side-by-side compilers is a need that many industrial users certainly have. * our previous Windows installer infrastructure [1] is essentially unmaintained. It would take time and effort on the part of someone to bring it into a working state. Moreover, even when it "worked" it had serious issues (%PATH% issues were a constant headache, the msys installation could be easily broken by the user), was not built on the MSI installer subsystem officially sanctioned by Microsoft, and imposed a significant maintenance overhead (building a functional distribution required no small amount of luck) * the Windows developer community seems to have largely consolidated around nuGet and Chocolatey; following this trend seems wise given how tricky (proper) packaging for Windows tends to be My sense is that Chocolatey is the right approach here. We simply need to make it more accessible. After a long discussion with Tamar, I think we have a plan that could move us in this direction. I have documented this plan in #18104 [2]. While it's possible that Tamar or I could get to working on this eventually, it would be much better if we could get help from the broader community since there is little GHC-specific knowledge necessary. In general we have precious few developer-hours looking at GHC Windows issues; it would be a shame to have to spend them on packaging issues. If you are interesting in contributing please comment on the ticket. Cheers, - Ben [1] https://github.com/haskell/haskell-platform/blob/master/windows-platform.sh [2] https://gitlab.haskell.org/ghc/ghc/issues/18104

I appreciate that these things are standard tools for Windows developers, but it's worth noting how much harder it can make things for completely new people (either new developers or new to Windows). At the start of the year, I prepared install instructions for university students who would be using Haskell as part of a first year CS course. We needed to use GHC 8.6.5 because certain libraries were not available for GHC 8.8.x (their base upper bounds hadn't updated, which ruled out haskell-dev), and tried to use Chocolatey as an experiment. It was remarkably tough to get students set up on their own machines. I was planning on recommending the Haskell Platform installer for Semester 2 this year, and am disappointed to find that it no longer exists. If it becomes too hard for students to install Haskell on their own Windows machines, it may become too hard for us to use Haskell as an educational tool, and I'd consider that a tragedy. -- Jack writes:

Hi Pedro,

I’m the maintainer of those chocolatey packages.

➢ First, I have to subscribe to a newsletter? Really? I guess this is entirely optional, but the instructions don't make it sound so.

Step 1 is completely optional and you don’t have to subscribe to any news letter.

➢ Then I have to know what powershell.exe is, use an administrative prompt, and enter scary commands in it.

Powershell has been the standard shell in Windows for well over the past decade. Every single script from Microsoft or third parties come with powershell for automation. It’s understandable that you may not know it since your primary platform isn’t Windows. But it’s been included in every single Windows version for the past 13 years.

An administrative prompt is nothing different than running sudo or clicking on that installer that you *assumed* not to be scary because you didn’t see the actions it was performing. That scary looking command is nothing but a curl command allowing the one time execution of a script from a remote source. As in a script that’s not physically on your machine.

So what exactly makes this scary? Is it because

Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))

Is more verbose than

curl -sSL https://path.to.some.script/ | sh

or because the technologies used while completely standard on Windows aren’t known to the casual user?

Thanks, Tamar

From: José Pedro Magalhães Sent: Saturday, April 25, 2020 04:24 To: haskell Subject: [Haskell-cafe] When did it become so hard to install Haskell onWindows?

Hi,

I haven't used Haskell in my personal computer in a while. I decided to install it again. I used the Haskell Platform in the past, so I went for that again - and a quick Google search on "install haskell windows" brings up the HP page, so I thought I was on the right track.

At the HP page for Windows, I'm greeted with this:

In the past I'd just download an installer which would take care of things - now it seems to be more complicated. But fine, I followed the link to configure Chocolatey. That's where it starts getting really scary:

First, I have to subscribe to a newsletter? Really? I guess this is entirely optional, but the instructions don't make it sound so. Then I have to know what powershell.exe is, use an administrative prompt, and enter scary commands in it.

I gave up at this stage. But going back to the HP page, it appears that even this wouldn't be enough, because I would still need to follow "the instructions at haskellstack.org to install stack". The link to haskellstack.org takes me to a 403 Forbidden.

I honestly don't want this to sound like a rant. I genuinely would like to understand why this multi-step, multi-tool, multi-website process was introduced, how it is superior to a single installer, and whether this is really the process we want newcomers to the language have to follow.

Thanks, Pedro

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

And to be clear, if it because you don’t want to use a commandline and want an installer Chocolatey also provides a GUI overlay, It is after all. A bog standard package manager. https://github.com/chocolatey/ChocolateyGUI/releases/download/0.17.0/Chocola... Is the latest release. It has the familiar “Click and installer asks for UAC and magic happens in background”. That Pedro may be looking for as well. Afterwards you just check the box for Haskell-dev and click install. If you want GHC 8.6.5, you click the all versions button and install that. Haskell-dev is nothing but a wrapper to Install msys2, ghc and cabal. Select those 3 components and you get the same thing. So whether you install Haskell-dev and then downgrade to GHC 8.6.5 or you install GHC 8.6.5 + msys2, both should work Tamar From: lonetiger@gmail.com Sent: Saturday, April 25, 2020 10:20 To: Jack Kelly Cc: dreixel@gmail.com; haskell Subject: RE: [Haskell-cafe] When did it become so hard to installHaskellonWindows? Hi Jack, What made it remarkably tough for students to set up on their machines? You can still use Haskell-dev if you want older GHCs. Just install it and then Downgrade the ghc. I would be quite interested to figure out what the pain points were. Surely if they are new to Windows they would have come from a platform where they know what a package manager is. Would providing a binary to automate the steps work for you? I have been reluctant to do so because I don’t want to hide what the installer is doing. Thanks, Tamar Sent from Mail for Windows 10 From: Jack Kelly Sent: Saturday, April 25, 2020 10:15 To: lonetiger@gmail.com Cc: dreixel@gmail.com; haskell Subject: Re: [Haskell-cafe] When did it become so hard to install HaskellonWindows? I appreciate that these things are standard tools for Windows developers, but it's worth noting how much harder it can make things for completely new people (either new developers or new to Windows). At the start of the year, I prepared install instructions for university students who would be using Haskell as part of a first year CS course. We needed to use GHC 8.6.5 because certain libraries were not available for GHC 8.8.x (their base upper bounds hadn't updated, which ruled out haskell-dev), and tried to use Chocolatey as an experiment. It was remarkably tough to get students set up on their own machines. I was planning on recommending the Haskell Platform installer for Semester 2 this year, and am disappointed to find that it no longer exists. If it becomes too hard for students to install Haskell on their own Windows machines, it may become too hard for us to use Haskell as an educational tool, and I'd consider that a tragedy. -- Jack writes:

Hi Pedro,

I’m the maintainer of those chocolatey packages.

➢ First, I have to subscribe to a newsletter? Really? I guess this is entirely optional, but the instructions don't make it sound so.

Step 1 is completely optional and you don’t have to subscribe to any news letter.

➢ Then I have to know what powershell.exe is, use an administrative prompt, and enter scary commands in it.

Powershell has been the standard shell in Windows for well over the past decade. Every single script from Microsoft or third parties come with powershell for automation. It’s understandable that you may not know it since your primary platform isn’t Windows. But it’s been included in every single Windows version for the past 13 years.

An administrative prompt is nothing different than running sudo or clicking on that installer that you *assumed* not to be scary because you didn’t see the actions it was performing. That scary looking command is nothing but a curl command allowing the one time execution of a script from a remote source. As in a script that’s not physically on your machine.

So what exactly makes this scary? Is it because

Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))

Is more verbose than

curl -sSL https://path.to.some.script/ | sh

or because the technologies used while completely standard on Windows aren’t known to the casual user?

Thanks, Tamar

From: José Pedro Magalhães Sent: Saturday, April 25, 2020 04:24 To: haskell Subject: [Haskell-cafe] When did it become so hard to install Haskell onWindows?

Hi,

I haven't used Haskell in my personal computer in a while. I decided to install it again. I used the Haskell Platform in the past, so I went for that again - and a quick Google search on "install haskell windows" brings up the HP page, so I thought I was on the right track.

At the HP page for Windows, I'm greeted with this:

In the past I'd just download an installer which would take care of things - now it seems to be more complicated. But fine, I followed the link to configure Chocolatey. That's where it starts getting really scary:

First, I have to subscribe to a newsletter? Really? I guess this is entirely optional, but the instructions don't make it sound so. Then I have to know what powershell.exe is, use an administrative prompt, and enter scary commands in it.

I gave up at this stage. But going back to the HP page, it appears that even this wouldn't be enough, because I would still need to follow "the instructions at haskellstack.org to install stack". The link to haskellstack.org takes me to a 403 Forbidden.

I honestly don't want this to sound like a rant. I genuinely would like to understand why this multi-step, multi-tool, multi-website process was introduced, how it is superior to a single installer, and whether this is really the process we want newcomers to the language have to follow.

Thanks, Pedro

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Hi Jack, Thanks for this! I’ll respond in turn.

* The big one was students who installed ghc without msys. Installing msys afterwards does not make GHC aware of it. Is there an equivalent of dpkg-reconfigure for chocolatey?

Yes, the msys2 detection is part of cabal not ghc, (ghc just has a dependency on cabal) As such choco install cabal -y --reinstall Would have corrected it.

* Some students who were repeating the course had old %appdata%/cabal/config files, which meant that programs failed to copy across.

The presence of an old cabal file itself is not an issue. The issue is the presence of an old broken cabal config file. There were some circumstances (mainly to do with paths with whitespaces) where the haskell-platform installer may create an invalid config file. The cabal user-config command won't behave properly if the config file is syntactically damaged. So my chocolatey packages refuse to modify it because it's not in a sane state. This is why the Haskell platform site recommend running cabal user-config init -f which resets the config file to a clean state. I should however emit a warning when it can’t modify the config file with instructions on how to fix it.

* Some students somehow managed to wind up with cabal-install installed but not GHC.

cabal is a dependency of ghc, so it will always be installed after GHC, the only exception here is if you manually install cabal first. e.g. choco install cabal ghc. haskell-dev prevents this by having dependencies to all three packages.

* Some students somehow managed to wind up with cabal-install and ghc installed, but not on %path%.

If the install finished (because of a quirk in how Windows shells update paths) you need to either run `refreshenv` to refresh your PATH or simply close and open a new shell. (You really MUST use one of these two, just running cmd again from the outdated cmd won't work for instance). chocolatey runs scripts in a separate shell then the one you're executing in, so it can't update your running session automatically.

* Some students hit the following error when starting GHCi:

GHCi, version 8.8.3: https://www.haskell.org/ghc/ :? for help <command line>: user specified .o/.so/.DLL could not be loaded (addDLL: pthread or dependencies not loaded. (Win32 error 5)) Whilst trying to load: (dynamic) pthread

This is an ABI issue, generally happens when you have a program installed on your computer that has put an incompatible version of pthreads on your PATH. This is why you shouldn't put MSYS2 on your path either as when the versions of pthread changes in msys2 it may become incompatoble with the one in GHC. The GHC 8.8.x series is using GCC 8, and so GHC expects an ABI compatible pthreads. We have been trying to tighten up where GHC loads dependencies from, but this is a GHC issue not a chocolatey one.

* There were also a number of minor issues around spaces in paths, or possibly non-Latin characters in paths, or non-Latin system locale. Many of these will happen regardless of installation method, so it's not fair to lay them at Chocolatey's feet.

Path with white spaces is indeed a general issue when using configure, The approach platform took was using dos 8.3 short paths, I haven't taken the same approach primarily because dos short names have a performance overhead, can be disabled and not available on all filesystems. So the solution should be something with how configure is invoked. I am looking into that. For non-latin locales we are at the mercy of the fact that GCC and binutils on Windows can't handle them. While we've always had tickets for them we haven't been able to do much about it. However since we have now started experimenting with binary patch gcc we might be able to.

...

You can still use Haskell-dev if you want older GHCs. Just install it and then Downgrade the ghc.

I was not aware that this was possible. Thanks for telling me.

It's also possible to install any number of GHCs concurrently. Just give chocolatey the -m flag when installing ghc, which stands for multiple From: Jack Kelly Sent: Saturday, April 25, 2020 11:00 To: lonetiger@gmail.com Cc: dreixel@gmail.com; haskell Subject: Re: [Haskell-cafe] When did it become so hard toinstallHaskellonWindows? Dear Tamar, Thanks for your response and suggestions. I'll respond pointwise:

What made it remarkably tough for students to set up on their machines?

* The big one was students who installed ghc without msys. Installing msys afterwards does not make GHC aware of it. Is there an equivalent of dpkg-reconfigure for chocolatey? * Some students who were repeating the course had old %appdata%/cabal/config files, which meant that programs failed to copy across. * Some students somehow managed to wind up with cabal-install installed but not GHC. * Some students somehow managed to wind up with cabal-install and ghc installed, but not on %path%. * Some students hit the following error when starting GHCi: GHCi, version 8.8.3: https://www.haskell.org/ghc/ :? for help <command line>: user specified .o/.so/.DLL could not be loaded (addDLL: pthread or dependencies not loaded. (Win32 error 5)) Whilst trying to load: (dynamic) pthread * Some students seem to have computers that are straight-up haunted. * There were also a number of minor issues around spaces in paths, or possibly non-Latin characters in paths, or non-Latin system locale. Many of these will happen regardless of installation method, so it's not fair to lay them at Chocolatey's feet. Unfortunately, I can't give you more detailed information than this. This semester was tougher than usual because of the remote troubles with COVID-19, and on top of that many of the students who had the really cursed problems stopped responding before we could get to the bottom of things. Perhaps they dropped the course?

You can still use Haskell-dev if you want older GHCs. Just install it and then Downgrade the ghc.

I was not aware that this was possible. Thanks for telling me.

I would be quite interested to figure out what the pain points were.

Surely if they are new to Windows they would have come from a platform where they know what a package manager is.

Not necessarily. These are first-year CS students, some of whom have never programmed before, although they're computer-literate. I have personally seen students who ask questions like "what's a terminal?" in the first lab session pass the course with very good marks.

Would providing a binary to automate the steps work for you? I have been reluctant to do so because I don’t want to hide what the installer is doing.

I think this would be extremely helpful.

And to be clear, if it because you don’t want to use a commandline and want an installer Chocolatey also provides a GUI overlay, It is after all. A bog standard package manager.

https://github.com/chocolatey/ChocolateyGUI/releases/download/0.17.0/Chocola...

Is the latest release. It has the familiar “Click and installer asks for UAC and magic happens in background”.

I was not aware that this existed. It may help, thanks for showing it to me. Thanks again. Best, -- Jack

Dear Simon, Thanks for your suggestion. I personally don't consider in-browser solutions like repl.it suitable for this problem in this context, though they definitely have value in other context. Major reason: many students in this course will go on to complete an IT or CS major, which means they have to grapple with this kind of thing at some point. On a personal level, I am wary of browser-based or cloud-based development environments as their acceptance accelerates the loss of control users have over their own computers. -- Jack Simon Thompson writes:

Jack, a saviour for me is to suggest repl.it … all in the browser, so no installation at all. Beginners can begin with the language and not the installation :-)

Simon

Sent from my iPhone

...

On 25 Apr 2020, at 10:17, Jack Kelly wrote:

I appreciate that these things are standard tools for Windows developers, but it's worth noting how much harder it can make things for completely new people (either new developers or new to Windows).

At the start of the year, I prepared install instructions for university students who would be using Haskell as part of a first year CS course. We needed to use GHC 8.6.5 because certain libraries were not available for GHC 8.8.x (their base upper bounds hadn't updated, which ruled out haskell-dev), and tried to use Chocolatey as an experiment.

It was remarkably tough to get students set up on their own machines. I was planning on recommending the Haskell Platform installer for Semester 2 this year, and am disappointed to find that it no longer exists.

If it becomes too hard for students to install Haskell on their own Windows machines, it may become too hard for us to use Haskell as an educational tool, and I'd consider that a tragedy.

-- Jack

writes:

...

Hi Pedro,

I’m the maintainer of those chocolatey packages.

➢ First, I have to subscribe to a newsletter? Really? I guess this is entirely optional, but the instructions don't make it sound so.

Step 1 is completely optional and you don’t have to subscribe to any news letter.

➢ Then I have to know what powershell.exe is, use an administrative prompt, and enter scary commands in it.

Powershell has been the standard shell in Windows for well over the past decade. Every single script from Microsoft or third parties come with powershell for automation. It’s understandable that you may not know it since your primary platform isn’t Windows. But it’s been included in every single Windows version for the past 13 years.

An administrative prompt is nothing different than running sudo or clicking on that installer that you *assumed* not to be scary because you didn’t see the actions it was performing. That scary looking command is nothing but a curl command allowing the one time execution of a script from a remote source. As in a script that’s not physically on your machine.

So what exactly makes this scary? Is it because

Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))

Is more verbose than

curl -sSL https://path.to.some.script/ | sh

or because the technologies used while completely standard on Windows aren’t known to the casual user?

Thanks, Tamar

From: José Pedro Magalhães Sent: Saturday, April 25, 2020 04:24 To: haskell Subject: [Haskell-cafe] When did it become so hard to install Haskell onWindows?

Hi,

I haven't used Haskell in my personal computer in a while. I decided to install it again. I used the Haskell Platform in the past, so I went for that again - and a quick Google search on "install haskell windows" brings up the HP page, so I thought I was on the right track.

At the HP page for Windows, I'm greeted with this:

In the past I'd just download an installer which would take care of things - now it seems to be more complicated. But fine, I followed the link to configure Chocolatey. That's where it starts getting really scary:

First, I have to subscribe to a newsletter? Really? I guess this is entirely optional, but the instructions don't make it sound so. Then I have to know what powershell.exe is, use an administrative prompt, and enter scary commands in it.

I gave up at this stage. But going back to the HP page, it appears that even this wouldn't be enough, because I would still need to follow "the instructions at haskellstack.org to install stack". The link to haskellstack.org takes me to a 403 Forbidden.

I honestly don't want this to sound like a rant. I genuinely would like to understand why this multi-step, multi-tool, multi-website process was introduced, how it is superior to a single installer, and whether this is really the process we want newcomers to the language have to follow.

Thanks, Pedro

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

---

Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Am 27.04.20 um 12:36 schrieb Joachim Durchholz:

It's a bit like with a car mechanic. If the workplace is grubby, people start questioning the attention to detail, and overall competence; they may still send cars for repair, but they will be more intent on finding issues, sometimes asking about things that don't matter (but they don't know this), sometimes being overly suspicious (but they don't really know how much suspicion is appropriate). If the workplace is clean, the standard assumption is that in this shop, there's attention to detail and they don't have to check every detail on their own.

Funny, for me it's exactly the other way around: when I see a repair shop which is dirty and with tools and parts strewn around I think: They are doing acual work here. When I see a clean and orderly shop I tend to think: They care about appearances, rather than getting the work done. This very much differs from how I view the /result/ of the work: here I regard everything that has not been done in a clean and orderly fashion as deficient. (And that goes for software, too, especially if it is mature.) Cheers Ben

Am 27.04.20 um 17:34 schrieb Joachim Durchholz:

Am 27.04.20 um 12:55 schrieb Ben Franksen:

...

This very much differs from how I view the /result/ of the work: here I regard everything that has not been done in a clean and orderly fashion as deficient. (And that goes for software, too, especially if it is mature.)

Sure, but how do you judge that work if you're not an expert? With old-style cars, you could inspect the machinery, even if you weren't fully educated you could see if there was grime in the gears or not. With today's cars and their electronics, and today's millions-of-lines software, that kind of check has become impossible.

Which is why I dislike modern cars. If I ever happen to buy another one in my lifetime it will be an oldtimer. Cheers Ben

Am 28.04.20 um 14:59 schrieb Joachim Durchholz:

Am 27.04.20 um 19:32 schrieb Ben Franksen:

...

Am 27.04.20 um 17:34 schrieb Joachim Durchholz:

...

Am 27.04.20 um 12:55 schrieb Ben Franksen:

...

This very much differs from how I view the /result/ of the work: here I regard everything that has not been done in a clean and orderly fashion as deficient. (And that goes for software, too, especially if it is mature.)

Sure, but how do you judge that work if you're not an expert? With old-style cars, you could inspect the machinery, even if you weren't fully educated you could see if there was grime in the gears or not. With today's cars and their electronics, and today's millions-of-lines software, that kind of check has become impossible.

Which is why I dislike modern cars. If I ever happen to buy another one in my lifetime it will be an oldtimer.

And that's the rub: you won't get a silent, safer, low-emission car,

More silent: Okay, I'll give you that one. Safer: Physically, yes. OTOH, the manufacturer will constantly spy on you and some evil hacker may remotely control your car & crash it. Just like your "smart home" devices & the "smart health" devices. No, thank you. Low-emission: Ever heard of the rebound effect? Modern cars could indeed have much lower emission if that wasn't over-compensated by featurism and added weight. Production side must also be taken into account, but I have no numbers for that. After all, what I miss mostly is being in control of the machine, instead of the machine (or its vendor) controlling me. This also readily translates to (pure) software / operating systems. Call me old-fashioned, if you will.

I agree that much of the non-repairability modern cars is just lock-in, not by necessity. That's where the analogy breaks down: some things in software are too complicated for the casual user by necessity. Though... it's not that much of a break-down actually: Some OS vendors are indeed known for their persistent attempts to lock their users in, and making stuff needlessly complicated to that end.

Yeah, first Microsoft/Windows, now quite similarly IBM/systemd. Cheers Ben

I've used Advanced Installer (https://www.advancedinstaller.com/) to create Windows installers. There is a freeware version; I don't have enough experience with it to know if it has the necessary features or not. -Steve Schafer ________________________________ From: Haskell-Cafe on behalf of Imants Cekusins Sent: Sunday, April 26, 2020 12:26 PM To: haskell Cafe Subject: Re: [Haskell-cafe] When did it become so hard to install Haskell on Windows? Installshield (a commercial product) could be one way to offer an easy (for both packagers and users alike) installation experience. I am not aware of free licenses though. Shall we inquire? https://store.flexerasoftware.com/en/productselect.aspx

I wanted to chime in with a bit of positiveness. I really appreciate the work that Tamar has put into the Chocolatey packages, and when I personally needed to debug a windows-only issue, I found the installation experience to be better than Haskell Platform (which I had previously used when in university). It was clearer to see what I was installing (and I was able to directly manage what I had installed through Chocolatey - including installing other GHC’s and Cabal's). The Chocolatey packages also make setting up CI for windows much simpler. I can see why the new process is more complicated for university students who are accustomed to more GUIs and probably don’t have Chocolatey installed. Since there is a graphical installer for Chocolatey, couldn’t this mostly be solved by writing up more detailed setup instructions (including all the right GUI installer links and walkthrough) on the course’s home page site? The instructions could be reviewed once at the beginning of every term to make sure they are still accurate. That seems like the sort of thing that could eventually also be put on the official Haskell website. Packaging software for windows, GHC in particular, is a pretty huge task. The volunteers who maintain this stuff are heroes, and it is disheartening that the only time this difficult work ever gets recognized is when people are angry something isn’t working as expected. Alec

While I did email Tamar off-list, I should probably also thank him publicly. Packaging is a frustrating and often thankless part of Free Software development, and I appreciate that I can help a university teach Haskell to first-year students _at all_. We do refresh the installation instructions each semester, and re-test them before each run of the course to make sure they're up-to-date. Even with direct links to installers and explicit step-by-step instructions, I have been very surprised by the knots some students have managed to tie their computers into, and while Chocolatey has given us teething issues it also gives us a single set of commands to install GHC/cabal-install/MSYS2 and a decent text editor. -- Jack Alec Theriault writes:

I wanted to chime in with a bit of positiveness. I really appreciate the work that Tamar has put into the Chocolatey packages, and when I personally needed to debug a windows-only issue, I found the installation experience to be better than Haskell Platform (which I had previously used when in university). It was clearer to see what I was installing (and I was able to directly manage what I had installed through Chocolatey - including installing other GHC’s and Cabal's). The Chocolatey packages also make setting up CI for windows much simpler.

I can see why the new process is more complicated for university students who are accustomed to more GUIs and probably don’t have Chocolatey installed. Since there is a graphical installer for Chocolatey, couldn’t this mostly be solved by writing up more detailed setup instructions (including all the right GUI installer links and walkthrough) on the course’s home page site? The instructions could be reviewed once at the beginning of every term to make sure they are still accurate. That seems like the sort of thing that could eventually also be put on the official Haskell website.

Packaging software for windows, GHC in particular, is a pretty huge task. The volunteers who maintain this stuff are heroes, and it is disheartening that the only time this difficult work ever gets recognized is when people are angry something isn’t working as expected.

Alec _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Yes, you need to know several magic things to go this route. The first is to have that link that Ben Gamari provided in the first place, which is not an obvious thing at all. The second is to know about compression formats that nobody uses on Windows. The .tar.lz file is much smaller can be decoded on Windows using lzip. lzip is available for windows as a 32-bit command-line utility from here: https://www.nongnu.org/lzip/ You need to unzip the file, copy the binaries to somewhere handy (probably a folder you create in c:\Program Files (x86) ), and then add that folder to the path. Then you need to go to the command line and use lzip -d {filename} to decompress the file. This leaves you with a .tar file, which Windows also cannot handle. Installing 7zip makes that extractable, however. You can, however, reduce the complexity of the process at the expense of bandwidth (which most people have copious amounts of these days) by downloading the .tar.xz version. Windows still can't handle this natively, but 7zip can handle both the .xz and .tar decompressions using a single program. The third thing you need to know is that: ghc-8.10.1-windows-extra-src.tar.lz (or .xz) ...which is the only thing in there with "Windows" in the name, is not, in fact, the one you want. Or at least, not that I can tell. It appears to be a bunch of extra tools required to build the source code on Windows. There's a lot in it, so I didn't explore it fully. Also, within the .lz is a bunch of .xz files, but fortunately 7zip can handle those. In any case, the file you actually want is the cryptically-named: ghc-8.10.1-x86_64-unknown-mingw32.tar.lz ...because of course "unknown" in this case means Windows, I guess? Decompressing that, untarring the result, moving the resulting folder to your 'c:\Program Files' folder, and adding the bin subfolder to your path does indeed get you a working ghc and ghci -- from the command line. It doesn't include the GUI versions that I can discern. Nonetheless, this is still probably the easiest current method of installing it. It's not actually hard to do, it just requires you to know several non-obvious things that a new user probably won't know. I'm honestly baffled by the use of .tar.lz or .tar.xz for distributing Windows software. Just using .zip would guarantee that anyone can decompress it without having to install any tools -- Windows supports .zip files natively. In any case, since it doesn't appear to be obviously documented anywhere, the steps to go this route are: 1. Download and install 7zip from here: https://www.7-zip.org/download.html 2. Navigate to the latest version's folder from here: https://downloads.haskell.org/ghc/ 3. Download ghc-[latest version]-x86_64-unknown-mingw32.tar.xz 4. Right-click it, choose 7zip, and choose Extract to Here 5. Right-click the resulting .tar file, and choose Extract to [folder named after file] 6. In that folder, you should find a folder named ghc-[version]. Copy that to 'C:\Program Files'. 7. In Control Panel, search for "Environment Variables", and click "Edit the System Environment Variables" or "Edit the Environment Variables for your Account" depending on whether you wish other users to be able to use the software. 8. Click "Environment Variables". 9. Scroll to "Path" under either your username or 'System Variables' [see note above] and click Edit. 10. Click "New" and add the 'bin' subfolder of the folder you copied (ex. C:\Program Files\ghc-8.10.1\bin) 11. It should now be installed. To test it, open a command prompt of your choice and type "ghci" or "ghc". On 2020-05-10 6:20 a.m., Francesco Ariis wrote:

Il 25 aprile 2020 alle 11:22 José Pedro Magalhães ha scritto:

...

I honestly don't want this to sound like a rant. I genuinely would like to understand why this multi-step, multi-tool, multi-website process was introduced, how it is superior to a single installer, and whether this is really the process we want newcomers to the language have to follow. A data point from a user (OS: Win10) on freenode/#haskell-it today. Shared with permission, translated by me:

- he asked: «Hello. To Windows users, can you link the installer to me? It disappeared from the site, now I need to install Chocolatey and to be honest I would prefer not to». I redirected him to the page mentioned here [1] by Ben Gamari and asked why Chocolatey was not an option for him. Reply: «I don't want to use a third party tool, Chocolatey immediately asks me to register to its newsletter... why? Those things are very annoying, I'd rather install Haskell on an RPi and use it via ssh 😅»;

- once the download from [1] was over: «I have downloaded it (400Mb) but I cannot extract it and I don't know what to do with it, it's a .tar.lz file». Indeed after a cursory search, it seems a common (on Windows) open-source extracting tool like 7-zip does not natively support the format [2]. Not having used Windows in 10 years I suggested to try WinZip -- stupid idea, as it does not support ".tar.lz" either and it is proprietary nagware;

- I then directed him to the Stack Win64 installer [3]. Feedback: «Microsoft Defender blocks it! 😂»;

- after this, the user created an Ubuntu VM and installed Haskell via "apt-get install haskell-platform". The installation took a few minutes, he seemed satisfied with it.

[1] https://mail.haskell.org/pipermail/haskell-cafe/2020-April/132150.html [2] https://sourceforge.net/p/sevenzip/discussion/45798/thread/9e77409b/?limit=2... [3] https://get.haskellstack.org/stable/windows-x86_64-installer.exe _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.