I started working on a new snap barebones project with stack. When I stack init, it resolves to an older ghc compiler. When I upgraded the compiler, I got errors for the MonadCatchIO-transformer dependency. I went MonadCatchIO docs they say it is deprecated for exceptions library. So I replaced the dependency in my cabal file and was able to get my project to build and run hello world.
I want to know if I should expect errors later on in the Snap framework if/when I get more complex than a hello world project.
Why was MonadCatchIO-transformer part of the barebones template if it isn't necessary and several years obsolete.
After going through the git repository for snap-templates, I found that the template file doesn't even reference a MonadCatchIO-transformers. It seems whatever I downloaded with cabal install snap-templates isn't the current source code.
I have asked them to update hackage in an issue request.
Related
I am using VS Code 1.68.1 on Windows 10 and have installed the Haskell language support plugin. I tried to install ghcup but the installation script just fails with no error message and the IRC channel #ghcup wasn't able to help so I've given up on ghcup and decided to handle this manually. I just installed HLS 1.7.0 and pointed VS Code at it. The problem is I get an error message from VS Code:
ghcide compiled against GHC 9.2.2 but currently using 8.6.5
This is unsupported, ghcide must be compiled with the same GHC version as the project.
Upon further investigation, this seems to be complaining that the ghcide library that's a part of HLS was built using ghc 9.2.2 but my current codebase was built (by Stack) using ghc 8.6.5. At least that's my reading of it, since the HLS page itself says that 1.7.0 is compatible with 8.6.5! So my first question is how on earth am I supposed to know what version of ghc was used to build HLS, and honestly why should I care?? And my second question is, how do I find the version of HLS that's compatible with my current ghc?
(Another option is to migrate Stack from 8.6.5 to 9.2.2 but I'm not sure exactly how to do this. It appears to be just a case of changing the resolver entry in stack.yaml which is currently resolver: lts-14.21. But what do I change it to? It looks like the most recent version of LTS is 19.14 https://www.stackage.org/lts-19.14. But I'm a bit nervous about making that change since the page says ghc 9.0.2 not 9.2.2. The entire Haskell ecosystem just seems really finicky and I'm new enough to Stack that don't want to end up with a messed up Stack config and possibly in Haskell package mismatch hell.
Can anyone offer any good solutions?
Unfortunately, we have projects with different nodejs versions. I am not sure if this is like java where I can have multiple jdks installed(multiple nodejs installed) and each project magically uses the correct version via a config file? Also, most commands in tutorials are not including version numbers when installing tools and libraries like so
npm install -g expo-cli (tool)
npm install #react-navigation/native (library)
Coming from gradle with the gradle wrapper where everyone on the team uses the tools and library versions defined in the build.gradle file, this is odd to me. In the gradle world, everyone on the team uses the same exact version of gradle(gradle itself ensures if one person upgrades it in the repo, everyone gets the upgrade and stays in sync on the same version). Then there is plugins/tools and those versions are defined and then libraries and those versions are defined.
How do I guarantee everyone is using the same npm, node, expo, etc. tools?
How do I guarantee everyone is using the same libraries?
How do I guarantee everyone is using the same typescript?
Ideally, we upgrade any of these in the repo + any fixes to the upgrade so on checkout, developers start using the new tool + new *.tsx files so it is seamless much like in the gradle world. In gradle, I upgrade the
version via a property
versions of plugins/tools
build.gradle files
any source code files
and check that all in as a unit such that any developer that checks out is using all the correct versions together. I want this in react-native for our ios/android mobile project or as close as I can get.
I have hacked things before as in installing 'ant' into the git repo and this worked wonders(even though it is such an ugly hack) and everyone used the tool in the repo instead of the one on their OS. Perhaps there is a way to do that?
A bloated repo with binaries was worth it's weight in gold to prevent version compatibility hell as people upgraded libraries over time. NOT only that we found that tool bugs were easier to track down as we could revert the repo. NOT only that, we could reproduce builds form 1 year ago as the tooling was reverted where todays npm tools can't build the 1 year ago thing due to all the changes. The advantages just kept piling up and up and I can't even remember all of them.
Tooling running from the repo either via bootstrap like gradle wrapper or full blown thing is generally the best option until the full blown thing is really bloated but even then locking it to a hash on another tool repo could be better
Any ideas welcome here to put my team on all the same tooling(works great for people joining the company or team from another project as well to not have to install much).
thanks,
Dean
Typescript and libraries should be taken care of by removing any carets and tildes in your package.json and specifying exact versions.
One low overhead possibility for the rest could be shell scripting and a private package repo. You could host the versions you want to install internally, and get it all through cURLs.
Or you could add some simple scripts in your npm pre-install, for example nvm use 12.2.1 should, through error messages, guide the user to installing nvm and using the proper version.
I am using debian and the haskell-platform on the system gets really old. So I download the newest haskel-platform binary version and place it under /usr/local/haskell and activate it. Now there're 2 versions of ghc. If I type ghc then the old ghc-7.4 will be used and ghc-7.8.3 will certainly call the new one. But I have trouble with cabal. The new cabal cannot be used because of glibc version. Can I make the old cabal work with the new haskell platform ? If so how can I make it work just like there're two cabals. In the other word, I want the default directory of the cabal working with the old platform to still remain $HOME/.cabal and the cabal working with new platform to become the new directory (actually I don't know where). Can anyone help me to configure it so that I can have two versions of haskell-platform working separately on my Linux.
You can use lots of GHC installations at the same time without problems, but I don't think that's true for multiple Cabal installations. All you need is to use up-to-date Cabal, no need to keep any other versions. See this blog post for how to use multiple GHC's: http://osa1.net/posts/2014-12-09-ghc-cabal-installation-guide.html
I'm trying to get started with Node.js on a Windows machine. Yes, I found the installer on their site. That worked just fine and I can run it. However, after that there's no instructions or requirements. Some issues I ran into:
I learned that most of these cool modules need to be built locally.
I was told I needed Git installed
I found I needed Python to build modules
I discovered I needed Visual Studio to compile
Once things are built they should be executable. However, they are not natively found in the path. I discovered them under %APPDATA%\npm, but there's no mention of adding that to the PATH.
What else am I going to discover? Is there a guide to this anywhere?
Altough I might suggest you to develope node on a unix based os (Ubuntu 12.04+WebStorm is my favorite combination for many reasons I can mention) I found my self in your situation at work when Windows 7 is a must.
I found this video really helpful
Once youe have node installed on your machine (window or any other) I (and most community) would recommend you to use WebStorm as IDEA it contains every inch of support to make your development process easy and clean, mange your global and local modules and build/debug your code easily.
It sounds like you've actually installed Node.js fine, but are having problems with the packages built by people in the community, some of which use Python or a native C compiler. Git shouldn't be necessary unless you're perhaps cloning projects from a remote repository? Or maybe the packages have dependencies on projects hosted in GitHub?
Keep in mind that Node is separate from all the modules and packages available in the community, accessed through the npm registry. Node provides you the ability to execute JavaScript locally, additional APIs, and an ecosystem to build additional packages which can do, as you've said, really cool things. But each of these packages can have unique installation requirements.
Most packages have dependencies of their own, and are often installed using the npm install command. This (usually) downloads other packages from https://www.npmjs.org/, and in some cases requires compiling additional files. This might have been the issue you hit.
The other thing to keep in mind is that a lot of people might assume things are installed and available since they have it installed for them, or are running a different operating system than you. I've often found that folks will hard code / somewhere in their scripts, which cause problems on Windows based systems. This can lead to problems with the executables that are created as part of the node packages created by the community.
To better understand what Node has and what's available, I'd recommend the nodeschool.io projects. These cover some of the main areas provided by the base Node platform, and get you used to playing around with things from GitHub and npm. Maybe if you run into specific issues there folks can help more directly.
Setup:
I have created a module that works fine in the solution where it was created, ie, the orchard source code. I then package it up using package create.
Edit: I now realize that the problem appeared IMMEDIATELY after installing visual studio 2012.
Problem:
If I now install the module on a different app using the package and install from file, all the alerts show the module is installed, it appears in the features list, it is enabled... but there are no menu items, no entry in the migrations table, nothing.
Edit: Nothing appears in the logs. The files are, however, installed correctly in the modules folder of the site.
Question:
What could be going wrong that stops the module being properly installed using the package given that the module works fine in the source code solution where it was created??
Any suggestions?
Edit:
How could installing visual studio 2012 have affected Orchard?
I notice that installing visual studio 2012 resulted in various bits of sql server 2012 being installed at the same time. Could this be relevant? EG, is this why the migrations code never runs?
Edit on the basis of Bertrand Le Roy's comments (see below this question):
BertrandLeRoy says that having ASP.NET MVC 4 installed in the GAC, as well as Razor 2 (both of which came with VS 2012), is the problem.
He suggests upgrading to Orchard 1.5.x.
However:
I have tried using a new install of Orchard 1.5.1, and the problem is the same:
Creating a new module using VS 2012 and Source Code for Orchard 1.5.1 and the module appears correctly when running the orchard site from VS.
Creating a package and then installing that into an Orchard 1.5.1 site, eg, using WebMatrix, running and then installing the package has the following effect:
2.1. The alerts in the dashboard tell me that the package has installed correctly.
2.2. However, enabling the feature does nothing.
2.3. This is hardly surprising, as installing the package has not even run the migrations.
The last test I can do is to see if the package runs on a web server that doesn't have asp.net mvc4 installed. I will post back once that is done.
However, the main point is that using Orchard 1.5.1 produces the exact same result. So, if the problem really is the fact that MVC 4 and Razor 2 are on the machine, then Orchard 1.5.1 is not solving it.
Ie, what will happen when I install mvc 4 on the web server as I will inevitably have to for other, non Orchard apps?
I experienced the same thing on version 1.8.1. That is, the module appeared to install fine, but it didn't actually perform migrations or load correctly.
Initially, I saw nothing in the log to indicate a problem. However, after adjusting the /Config/log4net.config file to log ALL instead of just ERROR messages. I got this:
... Orchard.Environment.Extensions.Loaders.PrecompiledExtensionLoader -
- Extension "Transformalize" will not be loaded as pre-compiled extension
because one or more referenced extension is dynamically compiled
The part saying my module "will not be loaded as pre-compiled extension because one or more referenced extension is dynamically compiled" seemed to explain why my module wasn't loading. So, I Googled and found this documentation regarding the Orchard module loader and dynamic compilation. It's a bit complicated at 2 AM, but what I gathered is my module's reference to another module (Orchard.Autoroute in this case) caused the log message (above) in the production environment. I removed my module's reference and dependency on Orchard.Autoroute, and then it installed fine.
The documentation explains how modules are dynamically compiled and how the settings in /Config/HostComponents.config can change how things work.