I am trying to install Haskell on Mac, and doing it as instructed on Haskell site Haskell site.
When I run the script from above website on terminal, it says to install "ghcup", "ghc" and "cabal". However, it seems that it installs "ghcup" successfully, but an error occurs when it comes to install "ghc".
Error: ghc: unknown version :lion
how can I fix this? or, is there another way to install Haskell on Mac?
(I saw similar posts but they are too old)
You seem to be running macOS Lion, which is ancient, insecure, and no longer supported by Apple. As such, most modern software isn't tested for compatibility with it anymore, and a lot of it won't work. Upgrading to a modern version of macOS such as Catalina will make it work.
There are different options to get a working Haskell development environment on your Mac. The most popular seem to be
Haskell Platform
Install via homebrew
The Haskell Tool Stack
Of course, you can also install most tools individually by hand or compile everything from source.
Together with the type of installation, you need to choose how to build your projects: Using Cabal or Stack.
My personal preferences as a beginner is Stack, because (a) the entire Haskell tool stack is installed locally for each project, so you don't get into problems with conflicting versions of certain tools; (b) dependencies are curated, such that you do not need to deal with incompatible versions of libraries. From a beginner's perspective, it is very helpful that I can focus on actual development work and less on infrastructure and tooling.
Related
I'm building my open-source game for MacOS in AppVeyor CI (which uses Catalina). I'm installing compiler and dependencies with brew and package it in .app format, and everything seems to work fine, except that when trying to launch resulting application in older MacOS versions (I only have High Sierra available for experimentation) I'm getting errors about newer MacOS version. I suppose if I can force Homebrew to install binaries for older MacOS versions, this would fix the problem, but how exactly can I do that?
I'm aware there's ability to build software from sources in brew, but I don't want to go that route considering I want my CI to be fast.
EDIT: To clarify, I'm trying to fix the following error: "You can't use this version of the application MyCoolGame with this version of macOS. You have macOS 10.13.6. The application requires macOS 10.15 or later."
Since time immemorial†, there have been two package managers for Macintosh computers: Homebrew and MacPorts. These projects are different in a variety of ways that some folks care about very deeply, and lots of people have opinions about which package manager is better. Once they all get tired of arguing, however, they usually acknowledge that Homebrew and MacPorts do basically the same thing, and return to more important topics like why tabs are better than spaces.
There is one particular difference between Homebrew and MacPorts which may interest you:
Homebrew supports the three most recent versions of macOS, which as of this writing is Monterrey, Ventura, and Big Sur. Homebrew can sometimes be installed on older operating systems too, but Homebrew's developers make zero effort to support these systems. The result is lots of breakage.
MacPorts also supports the three most recent versions of macOS. However, it also supports older versions of macOS on a "best-effort" basis. Notably, "best-effort" in this context is a term used to mean "a lot of f*cking effort." MacPorts actively maintains bespoke patches, hardware buildbots, and compatibility libraries for every version of macOS going back to OS X Tiger. (OS X Tiger, for those who don't know, is an operating system released in 2005. And 2005, for those who don't know, is a long forgotten age when phones were actually used to make phone calls, Zoom was just a TV series on PBS Kids, and Mug Cake hadn't been invented yet).
You stand at a crossroads. You have two choices. Do you:
Continue using Homebrew, with full knowledge that most packages will be broken and anything that is not broken will likely become broken in due course and at the least opportune time.
Use MacPorts, which actively supports your operating system and will continue to do so for the foreseeable future.
Choose wisely.
† aka the year of our lord 2009. That's basically the same thing, right?
I have noticed that often, MacPorts will install dependent software that is already embedded into my OS (OSX). Particularly, Python is a frequent example of this.
Is the MacPorts software so intelligent that it will check for native installations and install dependencies ONLY if the native installation is not compatible with the port I am trying to install?
Or, does it simply see in the list of dependencies that, "Aha, I need Python, and Python is not installed as a port, so I will install it" (even though there is a native installation of Python)?
Note: This question is meant generally, not only regarding Python. Just using that as an example.
The package systems usually distrust the pre-installed software and install their own. It’s easier to control it, you get a more recent versions of the software and also have greater control over versioning, which helps with dependency management.
I need some smalltalk with GUI for my homework, and I'm running Mac OS X Lion (10.7).
I've seen that unix users usually use GNU Smalltalk and GTK+.
I've tried to install them from different versions of sources and all of them give some errors.
Then I've used MacPorts, but that installation breaks GTK+ bindings for gst.
Finally I've tried to install it using fing package manager (because GNU states that I should install everything nice) but there is no smalltalk package for 10.7 OS (though there is for previous ones).
Is there some way to use smalltalk under Mac OS Lion, or should I for example run Ubuntu on virtual machine?
You could also try Pharo, which is a fork of Squeak.
http://www.pharo-project.org/home
Uko,
Have you looked at Squeak? Its an open source version of Smalltalk which is really fun to use and is supported on most platforms.
See:
http://squeak.org/
You will need a specific SqueakVM for the Mac:
http://www.squeakvm.org/mac/
Let me know if you have any further questions...
Squeak or Pharo are real Smalltalks (unlike GNU). This means they have a Smalltalk specific IDE. IDEs were invented by the creators of Smalltalk, so whatever you think you know about IDEs, you probably don't.
My video series, Squeak from the very start, shows how to download the latest Squeak Smalltalk and get started with it. Pharo isn't any harder to install either.
http://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all
You can also give the Personal Use version of VisualWorks a spin:
http://www.cincomsmalltalk.com/main/developer-community/trying-cincom-smalltalk/try-cincom-smalltalk/
I'm assuming you'll get a 7.8(.1?) version there. The OSX skin is pretty dated. I promise it's getting better. Look for 7.9 soon now.
I wrote a bunch of Ruby scripts that integrate different tools to create a "workflow for academics". A number of my friends have been very interested in trying this out, however they are held back by how hard it is to install or replicate my environment.
Although Ruby comes built-in with Mac OSX (the applications I integrate are all Mac applications, so unfortunately the solution can only work on Mac), I use a few binary gems, including Appscript (bridge to AppleScript). The problem is that this requires XCode, which my non-programmer friends do not have installed (and it seems a bit demanding to ask them to install 3GB of software to run a few kbs of code).
I tried freezing the gems by installing them with gem -i, into a subdirectory of the source (on github), and tried removing my entire central gems directory on my local computer - it worked fine, the scripts still ran, etc. However, when my friends tried running the scripts, they got error messages about missing library files etc.
So my two questions are:
* how specific are compiled binary gems? will they work on other Mac OSX versions? with other versions of Ruby? etc
* how can I find out exactly which binary files (located in central locations) a Ruby gem depends on, and package this with the source (and how do I tell the gem where to find these files in non-standard locations)
I know this might not be "standard procedure", and I should just package it as a gem and let my friends deal with the problems etc - but I'd really like to solve this, and I am sure there must be some way of doing this?
Thanks a lot
In my experience, compiled gems are not portable. They're dependent on the exact version of ruby and whatever other libraries they use. A better solution would be to have your friends install the "Command Line Tools" version of Xcode -- it's only 100-150 MB and includes everything you need to build gems (and other software). You'll need a (free) Apple Developer ID to download it though.
https://developer.apple.com/downloads?q=Command%20Line%20Tools
Hobbyist and newbie, so no laughing ;)
I have been developing some toy programs on my Mac for a long time and everything is nice and straightforward.
I was trying to port one of my existing projects to Windows (as a way to get started in developing for Windows) but am stuck trying to build the libraries I have come to love in a Unix environment under Windows (and MinGW).
At the risk of revealing my naïvety, could someone just run through how to build and install a library on Windows (including any special software required)?
For example, an install readme might look like this:
Do this to install:
./configure
make
make install
Obviously on Windows that pukes...so what are the analogous steps on Windows?
You have a couple of options wrt building unix style libraries on windows:
Google for a pre-built binary distribution made for windows of the library in question.
If the libraries authors have bothered to support it, you can try installing Cygwin to get a posix like build environment on windows
Some libraries - like OpenSSL - have a set of build instructions for windows that include installing ActiveState Perl, and then running the appropriate configure script manually.
Where the authors of the library have made no special effort, you are pretty stuck: Create a static library project in the dev environment, add the libraries files to it, create (or move) the headers that the ./configure step usually creates or moves and build it yourself.
It is a tragic state of affairs that doing this "simple" task is so hard. Developers seem to take one of two lessons away from this:
Microsoft is the devil. Microsoft hates developers. Hates open source software. And is ###$. Compiling libraries and software from source via a standardized ./configure & make install process is the one true way.
Microsoft is the one true way. The microsoft eco system of pre-built .lib files and headers is perfection and people who build everything from source using arcane perl scripts and install into a standardized filesystem are mentally defective.
Your pick :P