Re: [Haskell-cafe] Using stack outside the project box

I like org-babel and I like haskell, but getting org babel to work with compiled languages showed a big impedance mismatch. I ended up writing my own tangler (reusing many parts of org) for reasons I document in the readme of the repo. Unfortunately I the repo is not public and I don't have much time to work on it for the next month or so

...

README Simple tangling for org buffers Reason I like org and org-babel but they have some problems with compiled languages.

Not possible to tangle all code going to a specified file Not possible to add line directives without major surgery Not all modes do the correct thing No way to prevent overwriting an unchanged file Special casing e.g. Don’t tangle to a file called ‘no’. :prologue and :epilogue are not honoured by all modes Try this #+ BEGIN_SRC emacs-lisp :prologue "hello" :epilogue "goodbye" :tangle ex1.el (+ 1 2) #+ END_SRC #+ BEGIN_SRC haskell :tangle ex1.hs :prologue "hello" :epilogue "goodbye" hey #+ END_SRC hey #+HEADER: :tangle ex1.cpp #+ BEGIN_SRC cpp :prologue "hello" :epilogue "goodbye" main() {} #+ END_SRC #+ BEGIN_SRC bash :tangle ex1.bash :prologue "hello" :epilogue "goodbye" aha #+ END_SRC Sometimes they do, sometimes they don’t. Prologue and epilogue are written after and before the links respectively Quite annoying if you’d like all your emacs code have a ;;; -*- lexical-binding: t -*- header. Although you can specify :lexical t as a header argument, it’s not written in the tangled code. Simple tangling Write a simple tangler that is mostly compatible with org mode and reuses it’s functionality. The basic idea is to tangle the code with a hashmap holding callbacks for the languages you are interested in. These callbacks happen at start and end of tangling to a file start and end of tangling a block start and end of tangling a noweb reference and are called in the context of the buffer you are tangling to. No language support required by the core tangle Tangling in org requires the mode of the language to be available. This can be a problem when batch tangling – you don’t want batch emacs to go through your complete emacs init file then. Flexible decisions You get full control over what is happening: Tangling doesn’t need to write the buffer, it can e.g. choose to send it to a program. You get information about the complete tangling context e.g. a noweb expansion will know all the parent blocks it is expanded from. Reuse as much of the org machinery as possible To ensure grosso modo compatibility with org, the org mode calls are reused. The rules Only blocks with :tangle header args are tangled Noweb is enabled by default with but you can configure it via the org way – org-babel-noweb-wrap-start and org-babel-noweb-wrap-end Do minimal work outside the callbacks, the tangled buffer is not even written to a file unless you request it.

...

Immanuel

On Tue, Jun 8, 2021 at 1:00 AM Jeff Clites via Haskell-Cafe wrote:

Was there a stack.yaml file in the directory you were in when you ran stack? If it finds a stack.yaml in your current directory when you run stack, it uses it.

Jeff

On Jun 7, 2021, at 2:22 PM, Galaxy Being wrote:

I installed stack on my Windows computer using chocolatey, which went smoothly. But I had nothing anywhere I could find. On a hunch, at the prompt I tried to run stack ghci, then it started downloading and installing stuff. Good. I then was able to track down an example of a stack.yaml in the ...stack/global-project directory. My whole motivation was to see an actual global stack.yaml in the wild, and not have to guess-and-test from the stack docs. Good. I duplicated

packages: [] resolver: lts-17.15

on my Ubuntu 21.04 in the .stack/global-project/stack.yaml. Tried running stack ghci from the Ubuntu prompt, and, similarly, it started installing lots of stuff. (The resolver version I replaced was lts-17.08. Why that old I don't know.). But then I got a cryptic error as it seemed to clash or not like something it saw in some obscure github directory I had cloned ages ago with Haskell example code. I deleted everything in the github directory that looked stack/cabal-ish and tried stack ghci again. Now it says

Warning (added by new or init): Some packages were found to have names conflicting with others and have been commented out in the packages section. Warning (added by new or init): Some packages were found to be incompatible with the resolver and have been left commented out in the packages section. You can omit this message by removing it from stack.yaml

Stack looks for packages in the directories configured in the 'packages' and 'extra-deps' fields defined in your stack.yaml The current entry points to /home/galaxybeing/Dropbox/org/HaskellRoad/, but no .cabal or package.yaml file could be found there.

Yes, that was the directory I purged. My .stack/global-project/stack.yaml contains only

packages: [] resolver: lts-17.15

Not sure how to proceed. Seeing how that vast majority of Haskell intro books don't use projects, just install, start ghci, load code at the REPL prompt, I'd really like to nail this "global", non-project stack down.

On Sun, Jun 6, 2021 at 7:10 PM Travis Cardwell wrote:

...

The Stack configuration that is used outside of projects is stored in the following location:

~/.stack/global-project/stack.yaml

This configuration file is used when you run `stack ghci` outside of a project. Such project configuration files can specify the Stackage snapshot to be used (`resolver`), any packages that should be used that are different from or not in the specified Stackage snapshot (`extra-deps`), a list of packages that are being developed (`packages`, none by default in the "global project"), as well as some other settings documented at the following location.

https://docs.haskellstack.org/en/stable/yaml_configuration/

Such a project configuration file determines what packages are *available* for use. The motivation is to provide an environment where all of the available packages work together, saving you from having to deal with dependency conflicts. It does not *expose* packages to the compiler or REPL. Packages are usually exposed by specifying them in a `.cabal` file (or `package.yaml` file when using hpack).

In my experience, the `~/.stack/global-project/stack.yaml` configuration is most often used when installing executables using Stack. For example, one can install the version of `hlint` that is in the Stackage snapshot configured in the configuration file as follows:

stack install hlint

What you would like to do is not normal usage of Stack, but I understand your motivation. It is possible to do what you want by configuring a global project with the packages that you would like to make available. First, create file `~/.stack/global-project/global-project.cabal` with the following content:

name: global-project version: 0.0.0.0 cabal-version: 1.24 build-type: Simple

library build-depends: base , safe default-language: Haskell2010

Add any packages that you would like to expose to the `build-depends` list. Next, configure `~/.stack/global-project/stack.yaml` as follows:

resolver: lts-17.14

packages: - .

Update the `resolver` configuration whenever you want to change Stackage snapshots. Note that you will need to add `extra-deps` configuration to this file if you ever want to expose a package that is not in the configured snapshot, in addition to adding it to the `build-depends` list.

With this configuration, the listed packages should be exposed when you run `stack ghci` to run a REPL.

Good luck!

Travis

-- ⨽ Lawrence Bottorff Grand Marais, MN, USA borgauf@gmail.com

_______________________________________________ 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.

-- -- Researching the dual problem of finding the function that has a given point as fixpoint.