profile
viewpoint

purescript/spago 539

๐Ÿ PureScript package manager and build tool powered by Dhall and package-sets

btrepp/docker-cntlm 12

Cntlm image for docker

btrepp/rust-midi-stomp 4

Usb midi firmware for stm32/bluepill

btrepp/purescript-tiled 3

Tiled map editor parser for purescript

btrepp/awesome-bevy 0

A collection of awesome Bevy projects

btrepp/bevy-prototype-parallax 0

Parallax backgrounds for bevy cameras

issue commentpurescript/spago

Error: Remote host not found on `spago build` inside container

I'm getting this same error when trying to run spago build during the install phase of a nix build, and there is not netbase in nixpkgs. Any alternatives?

ericbmerritt

comment created time in 6 days

issue commentpurescript/spago

Spago tries to create a global cache when `-c skip` is used

Okay according to the README it looks like you're supposed to use this flag with an =. Using --global-cache=skip I get the same behaviour. Using -c=skip I get the help text.

ursi

comment created time in 6 days

issue openedpurescript/spago

Spago tries to create a global cache when `-c skip` is used

Spago will still try to create a global cache when -c skip/--global-cache skip is used. This tripped me up when trying to use spago to build something with nix, as HOME is set to /homeless-shelter (which doesn't exist) and spago tries to create it (which it doesn't have permission to do).

created time in 6 days

issue commentpurescript/spago

add --depth 1 on git clone

This would work only if we'd need to use the latest commit right?

dont really understand

nix builtins.fetchGit creates cache dir with a .git dir content and then creates tarball with git archive and then extracts that tarball

forkuri=https://github.com/purescript/purescript-lazy
forkname=$(basename $forkuri)
forkrev=master
forkdir="$HOME/projects/$forkname"
forkcachedir="$HOME/projects/$forkname-cache"
# forkrev="v3.0.0"
# forkrev="bfef53b20d4e3450c8bba83a69ddfe5a14c74c9f"
git init --bare $forkcachedir
git -C $forkcachedir fetch --depth=1 --quiet --force -- $forkuri $forkrev

ls -al $forkcachedir
total 48
drwxr-xr-x  7 srghma users 4096 Nov 24 18:38 .
drwxr-xr-x 89 srghma users 4096 Nov 24 18:38 ..
drwxr-xr-x  2 srghma users 4096 Nov 24 18:38 branches
-rw-r--r--  1 srghma users   66 Nov 24 18:38 config
-rw-r--r--  1 srghma users   73 Nov 24 18:38 description
-rw-r--r--  1 srghma users  105 Nov 24 18:38 FETCH_HEAD
-rw-r--r--  1 srghma users   23 Nov 24 18:38 HEAD
drwxr-xr-x  2 srghma users 4096 Nov 24 18:38 hooks
drwxr-xr-x  2 srghma users 4096 Nov 24 18:38 info
drwxr-xr-x 17 srghma users 4096 Nov 24 18:38 objects
drwxr-xr-x  4 srghma users 4096 Nov 24 18:38 refs
-rw-r--r--  1 srghma users   41 Nov 24 18:38 shallow

git -C $forkdir argive $forkrev > /tmp/asdf.tar
tar extract /tmp/asdf.tar $forkdir
srghma

comment created time in 8 days

issue openedpurescript/spago

Spago doesn't globally cache packages that use spago

Operative system Spago version
macOS 10.15.5 0.17.0

I've noticed that the global cache for spago at ~/.cache/spago only seems to contain bower packages. Any package that uses spago.dhall leaves an empty directory. Example:

$ tree ~/.cache/spago/halogen*
~/.cache/spago/halogen
~/.cache/spago/halogen-formless
~/.cache/spago/halogen-vdom
โ””โ”€โ”€ v6.1.3
    โ”œโ”€โ”€ GUIDE.md
    โ”œโ”€โ”€ LICENSE
    โ”œโ”€โ”€ README.md
    โ”œโ”€โ”€ bower.json
    โ”œโ”€โ”€ index.html
    โ”œโ”€โ”€ package.json
    โ”œโ”€โ”€ src
    โ”‚   โ””โ”€โ”€ Halogen
    โ”‚       โ”œโ”€โ”€ VDom
    โ”‚       โ”‚   โ”œโ”€โ”€ DOM
    โ”‚       โ”‚   โ”‚   โ””โ”€โ”€ Prop.purs
    โ”‚       โ”‚   โ”œโ”€โ”€ DOM.purs
    โ”‚       โ”‚   โ”œโ”€โ”€ Machine.purs
    โ”‚       โ”‚   โ”œโ”€โ”€ Thunk.purs
    โ”‚       โ”‚   โ”œโ”€โ”€ Types.purs
    โ”‚       โ”‚   โ”œโ”€โ”€ Util.js
    โ”‚       โ”‚   โ””โ”€โ”€ Util.purs
    โ”‚       โ””โ”€โ”€ VDom.purs
    โ””โ”€โ”€ test
        โ”œโ”€โ”€ Main.js
        โ””โ”€โ”€ Main.purs

When running the spago install -v we see that it seems to attempt to globally cache halogen and halogen-formless as well, but it doesn't seem to work.

$ spago install -v
...
[debug] Fetching package halogen
[debug] Directory ".spago/__download-halogen-v5.1.0-67ee1bb8e495e2bf/download" does not exist, creating...
[debug] Fetching package halogen-formless
[debug] Directory ".spago/halogen" does not exist, creating...
[debug] Running `globallyCache`: PackageName {packageName = "halogen"} https://github.com/slamdata/purescript-halogen.git v5.1.0
[debug] Directory ".spago/__download-halogen-formless-v1.0.0-a6f3416ae37f31e5/download" does not exist, creating...
[debug] Directory ".spago/halogen-formless" does not exist, creating...
[debug] Running `globallyCache`: PackageName {packageName = "halogen-formless"} https://github.com/thomashoneyman/purescript-halogen-formless.git v1.0.0
[debug] Fetching package halogen-vdom
[info] Copying from global cache: "halogen-vdom"
[info] Installing "halogen-formless"
[info] Installing "halogen"
[debug] Directory ".spago/halogen-vdom" does not exist, creating...

Ideally, spago should support globally caching spago packages as well.

created time in 10 days

issue commentpurescript/spago

embedFileUtf8 prevents installation with cabal new-install problem with

Contemporary cabal uses a nix inspired build system to create a store of packages that are hashed based on their versions and dependencies to allow multiple packages of the same name and even version to be stored on a single system without creating conflicts. The basic overview is here: cabal.34.readthedocs.

I believe that cabal install now defaults to the nix style, but I use cabal new-install out of habit. There are also cabal new-build and many other "new" variants of cabal commands. cabal new-build will build things deep in a sub-directory of the package while the new-install command gives you a link in your ~/.cabal/bin directory.

So, to get purescript I just did cabal new-install purescript and it went to hackage and got me the current version and downloaded all the dependencies and spent awhile building all. For spago I cloned your repository and then cd'd into that directory to run cabal new-install alone which triggered cabal to look locally for the package cabal file and src. The only other step was using ghcup to get and set the versions of ghc (8.6.4 for purescript and 8.6.5 for spago) that seemed like the right ones for building.

In practice it wasn't too complicated. Get/set ghc 8.6.4 install purescript. clone spago. Get/set 8.6.5 install spago. (and make sure I had nodejs). If it hadn't been for the path issue which @hdgarrod seems to have figured out it would only have meant waiting for things to compile.

Hope this gives you the information you are looking for.

brittAnderson

comment created time in 12 days

pull request commentbtrepp/rust-midi-stomp

Move to RTIC and update dependencies

Hi. I'm thinking about supporting midi out from the host. I haven't looked at that since my early experiments some years back, but I don't think it should be that hard. There is this Rust+USB group on Matrix (I tried to invite you but failed as the bridge did not support PMs it seems). The group discusses the audio class and other USB related stuff. As Midi is part of the Audio Class, I think we could discuss it there to start out.

perlindgren

comment created time in 12 days

issue commentpurescript/spago

embedFileUtf8 prevents installation with cabal new-install problem with

I think what happens is that newer versions of cabal build in a source distribution, ie they run cabal sdist, unpack the created tar.gz file into a temporary directory, and then build in that directory. This is nice because it means you canโ€™t accidentally depend on files which you have forgotten to include in the source distribution.

brittAnderson

comment created time in 13 days

issue commentpurescript/spago

embedFileUtf8 prevents installation with cabal new-install problem with

I donโ€™t think a patch is needed, I think this is failing because the files we want to embed are not listed in extra-source-files. See https://github.com/haskell/cabal/issues/6118

brittAnderson

comment created time in 13 days

issue commentpurescript/spago

embedFileUtf8 prevents installation with cabal new-install problem with

@brittAnderson thank you for reporting this! I am actually interested in switching the build to cabal entirely, so any instructions you have for building this are very welcome! (note: last time I used Cabal was more than 5y ago, so I am totally in the dark when it comes to the new build commands)

To get back to the issue at hand here - it looks like makeRelativeToProject is stack-specific. The link points to the implementation, but I'll report the docstring here for convenience:

-- | Take a relative file path and attach it to the root of the current
-- project.
--
-- The idea here is that, when building with Stack, the build will always be
-- executed with a current working directory of the root of the project (where
-- your .cabal file is located). However, if you load up multiple projects with
-- @stack ghci@, the working directory may be something else entirely.
--
-- This function looks at the source location of the Haskell file calling it,
-- finds the first parent directory with a .cabal file, and uses that as the
-- root directory for fixing the relative path.

So at this point I have two questions:

  • can we patch this function somehow to work with both build systems?
  • if not, is there a better way to include static files with Cabal?
brittAnderson

comment created time in 13 days

issue openedpurescript/spago

embedFileUtf8 prevents installation with cabal new-install problem with

Was trying to install purescript and spago with cabal new style commands. Purescript/purs worked without error, but spago fails. It loads and builds all the dependencies but fails with an error about the embedding of files and url fall backs. It can't find the file. I just took a guess and fixed it by putting the full path in the lines of Templates.hs like this, e.g.

packagesDhall = $(embedFileUtf8 "/home/britt/progLang/purescript/spago/templates/packages.dhall") where formerly there was only a templates/packages.dhall I had to do that for every such reference in this file. I suspect this has something to do with the makeRelativeToProject command in TH.hs file, e.g.

[| LT.decodeUtf8 $(makeRelativeToProject filePath >>= embedFile) |]

If this relative file location could be fixed somehow than installation would only require having the right ghc versions, a couple of cabal new-install commands and some patience - at least on my machine.

I guess this mistake does not come up with stack install for some reason. Don't know if it is worth fixing or not, but I thought I should report it since it doesn't seem that hard to fix manually if someone else runs into it. `

created time in 14 days

issue commentpurescript/spago

add --depth 1 on git clone

This would work only if we'd need to use the latest commit right?

srghma

comment created time in 15 days

issue commentpurescript/spago

Is it safe to cache `output`?

For what itโ€™s worth, the PureScript Contributors libraries all cache the output directory in CI, and it appeared to work fine when I tested builds with changed compiler versions. That is, if I remember correctly, changing the compiler version essentially invalidated the output directory.

kindaro

comment created time in 16 days

issue commentpurescript/spago

Is it safe to cache `output`?

Wonderful, thank you @hdgarrood for chiming in! Then I think we should definitely document this somewhere - probably in a section under "how to", with the same title as this issue)

kindaro

comment created time in 16 days

issue commentpurescript/spago

Is it safe to cache `output`?

It should actually be safe to cache the output directory, and we do this in our CI at Lumi. The compiler version is stored in the output directory so that the compiler knows when to invalidate existing build products. In general, as long you havenโ€™t fiddled with the contents of the output directory, incremental builds should just work: in cases where the compiler can identify that work can be reused, it should do so, and otherwise it should rebuild as necessary. If deleting the output directory and rebuilding ever causes a successful build to start failing or a failing build to start succeeding, thatโ€™s a compiler bug.

kindaro

comment created time in 16 days

issue commentpurescript/spago

Is it safe to cache `output`?

I feel that caching the output folder is likely to not be a safe thing to do at least whenever the compiler version changes. A very-closely-related ticket we have about this is #527, maybe reading that could help with some context.

Since the build products are owned by the compiler (i.e. when building Spago mainly takes care of getting the sources and feeding them to the compiler), I'd suggest raising an issue in there to see if enabling such caching could be something worth pursuing.

Something that you could cache though is the .spago folder, so that you wouldn't have to download all the sources on every build.

Also, would newer versions of dependencies be downloaded and re-built automatically if such are available?

No. The basic principles of package-sets (on which Spago is based) is the version of every dependency is pinned exactly, and will always be the same - as only in this way we can make sure that the project will continue building over time - until you upgrade the package-set version, which you can do with spago upgrade-set

kindaro

comment created time in 16 days

fork paf31/pg-client-hs

A low level Haskell library to connect to postgres

fork in 16 days

issue openedpurescript/spago

add --depth 1 on git clone

for faster cloning of big repos

created time in 16 days

push eventpurescript/spago

Fabrizio Ferrai

commit sha 6258ac601480e776c215c989cc5faae46d5ca9f7

Move CI to GitHub Actions, upgrade to GHC 8.6.5 and Dhall 1.36 (#695)

view details

Fabrizio Ferrai

commit sha 77cfffbe64826b31c9eadf5864c5e7093c9da420

Merge remote-tracking branch 'origin/master' into refactor-environments

view details

Fabrizio Ferrai

commit sha c517bfb9e29a4484a837ac6afb563db1e63c2ef7

wip

view details

push time in 17 days

issue openedpurescript/spago

Is it safe to cache `output`?

My understanding is that Spago puts all build products into the output sub-directory.โ€‚This includes both all the dependencies and the project code itself.

I would like to speed up continuous integration by caching this directory.โ€‚Is it expected by design that exactly the updated project code will be re-built in the presence of output filled with earlier build products?

created time in 17 days

pull request commentbtrepp/rust-midi-stomp

Move to RTIC and update dependencies

Just a small comment. It seems that the usb-device + usbd-midi + stm32-usbd actually works out the box on OSX as well. Under OSX it appears as a midi device with one input (to host) and 0 outputs, thus its not required to actually implement the midi-out on the device (meaning midi-in from the embedded target point of view).

In any case, the usbd-midi could be extended with more functionality, and some constants currently defined in the application could potentially be moved to the library.

perlindgren

comment created time in 17 days

pull request commentbtrepp/rust-midi-stomp

Move to RTIC and update dependencies

(I think the only "controversial" potentially breaking change should be the move to

stm32f1xx-hal = {version="0.7.0", features = ["rt", "stm32f103", "stm32-usbd"]}

perlindgren

comment created time in 18 days

PR opened btrepp/rust-midi-stomp

Move to RTIC and update dependencies

Hi

Cool project!

I have updated your repo to RTIC v5, and changed up the dependencies. As I don't have a "stomp" box, I cannot test that it actually stomps as intended :) It compiles, that is the only thing I checked.

So please try it before accepting the PR.

I would be happy to discuss further capabilities of the usbd-midi implementation. A while back I implemented a midi-fader (used for scratching) in Rust (and just the bare necessity to get midi working). I experienced some compatibility problems, it worked in Linux and Windows, but not under OSX. Comparing the behavior of USB communication using Wire shark, and found that OSX is actually assuming even an input device to accept outgoing packages. With this implemented on the target side (actually just ignoring the data) I got it working also under OSX. I used a bluepill as well by the way.

Best regards. Per

+9 -9

0 comment

2 changed files

pr created time in 18 days

fork perlindgren/rust-midi-stomp

Usb midi firmware for stm32/bluepill

fork in 18 days

pull request commentpurescript/spago

Move CI to GitHub Actions, upgrade to GHC 8.6.5 and Dhall 1.36

It's using the latest Dhall and GHC 8.6.5, so I imagine that if we're not already compatible with GHC 8.8 it should at least be much easier to do that. I did actually try to upgrade to GHC 8.8, but the Windows build hangs. So I'll skip this and instead try to move to GHC 8.10 once an LTS is out for that.

f-f

comment created time in 21 days

pull request commentpurescript/spago

Move CI to GitHub Actions, upgrade to GHC 8.6.5 and Dhall 1.36

@f-f

From https://github.com/purescript/spago/pull/647#issuecomment-725004951:

let me know I missed something here (i.e. do we still need patches for nixpkgs after this went in?)

Thanks for the update!

When spago is released next, I'll update it in nixpkgs. I imagine that now it is on ghc-8.8 and using a recent version of dhall, it will be much easier to keep it up to date in nixpkgs.

f-f

comment created time in 22 days

issue closedpurescript/spago

spago build for voidlinux

Hi Guys,

I've been trying to create a pre built binary for void linux as part of the xbps system. This means that users using voidlinux or the X Binary Package System (XBPS) don't need to install stack or GHC, because it's all been done by the host (cloud) in advance.

It's critical that these binaries are compiled from source by the host so it can be run on all available architectures without any issues.

When building using the recommended settings by the voidlinux community (build_style=haskell-stack), I get the message below:

basement > /tmp/stack-48a6ffdab601d322/basement-0.0.8/Basement/Block/Base.hs:398:9: error:
basement >     Not in scope: โ€˜failโ€™
basement >    Perhaps you meant โ€˜Data.List.tailโ€™ (imported from Data.List)
basement >     |
basement > 398 |         arr@(Block arrBa) <- makeTrampoline
basement >     |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
basement >
basement > /tmp/stack-48a6ffdab601d322/basement-0.0.8/Basement/Block/Base.hs:481:9: error:
basement >     Not in scope: โ€˜failโ€™
basement >     Perhaps you meant โ€˜Data.List.tailโ€™ (imported from Data.List)
basement >     |
basement > 481 |         b@(Block ba) <- unsafeFreeze pinnedMb
basement >     |  

From what I've read, this happens because RebindingSyntax is declared in the file somewhere, therefore NoImplicitPrelude applies.

I can get this building on my machine with stack install and some dependencies, but not using the required setup.

I don't use haskell, so everything I know so far is solely off building purescript and spago from source via npm and creating this template. Do you have any recommendations?

Here is the template file I'm working on: https://github.com/waynevanson/void-packages/tree/package/spago_dev/srcpkgs/spago

closed time in 22 days

waynevanson

issue commentpurescript/spago

spago build for voidlinux

I'd like to keep the issue tracker as "actionable" as possible, so I wouldn't like to keep an issue open just to track the status of a ticket in another repo - that is, https://github.com/void-linux/void-packages/pull/24723 is a fine place to track itself. So I'll close this, and note that now that we merged #695 (which upgrades to GHC 8.6.5) things might have improved wrt the compatibility with the GHC that Void is shipping.

waynevanson

comment created time in 22 days

PR closed purescript/spago

Bump to LTS-16 with GHC-8.8.3.

Description of the change

Hey, I noticed that spago-0.15.3 was released, so I wanted to update spago in nixpkgs.

I went to bump the version to 0.15.3, but I noticed that spago was no longer building. This is because nixpkgs recently moved to the LTS-16 package set (GHC-8.8.3). I needed to figure out how to get spago building with the LTS-16 package set.

This PR is the few small changes I needed to make.

I thought that you might be interested in this if you ever wanted to update spago to LTS-16, but if not, please feel free to just close this!

Checklist:

  • [ ] Added the change to the "Unreleased" section of the changelog
  • [ ] Added some example of the new feature to the README
  • [ ] Added a test for the contribution (if applicable)

P.S.: the above checks are not compulsory to get a change merged, so you may skip them. However, taking care of them will result in less work for the maintainers and will be much appreciated ๐Ÿ˜Š

+33 -300

12 comments

4 changed files

cdepillabout

pr closed time in 22 days

more