1. 02 Mar, 2021 2 commits
  2. 28 Feb, 2021 7 commits
    • Hardy Jones's avatar
      Merge branch '235-use-posix-compatible-flags-in-bash-scripts' into 'master' · b370887f
      Hardy Jones authored
      Resolve "Use POSIX-compatible flags in bash scripts"
      Closes #235
      See merge request joneshf/purty!216
    • Hardy Jones's avatar
      Remove path to GNU binaries · 63e926d7
      Hardy Jones authored
      We no longer need to put the GNU binaries on the path for macOS.
      The only reason we had this path was for macOS to have access to the GNU
      binaries so we didn't have to write the bash scripts a certain way. Now
      that we're relying on the POSIX behavior, we ought to be able to use
      whatever binaries are on the path (since macOS has POSIX-compliant
    • Hardy Jones's avatar
      Use POSIX flags · 6b14cf25
      Hardy Jones authored
      We want to use something more consistent to different environments.
      Changing environments shouldn't mean scripts break. We were relying on
      the fact that every environment would have GNU programs around for
      things like `rm` and `tee`. That assumption meant that something like
      setting up CI or a new laptop would have to install a bunch of extra
      Instead of depending on GNU programs, we can depend on POSIX programs.
      More environments supply at least POSIX-compliant programs than
      GNU-compliant programs. So, we ought to have fewer environmental
      failures when setting up for a different environment.
    • Hardy Jones's avatar
      Merge branch '234-support-0-14-0' into 'master' · 1904c577
      Hardy Jones authored
      Resolve "Support 0.14.0"
      Closes #234
      See merge request joneshf/purty!215
    • Hardy Jones's avatar
      Remove superfluous prime · ee2c8f59
      Hardy Jones authored
      `kind` is no longer squatting at the top-level.
      We don't need the extra prime since we don't have a top-level `kind`
      value anymore.
    • Hardy Jones's avatar
      Bump `purescript-ast`/`purescript-cst` to 0.14.0 · 84e11986
      Hardy Jones authored
      We upgrade our dependencies to the latest versions.
      This change is fairly straight-forward. We're mostly just updating any
      of the stuff that worked with kinds to now work with types.
      We also make sure we format according to our golden tests. The change
      for the now deprecated octothorpe row constructor was basically moved
      What's nice is that it seems like we can still parse valid 0.13.x syntax
      as well. Which means this ought not be a breaking change.
    • Hardy Jones's avatar
      Add golden tests for new syntax · fe66a628
      Hardy Jones authored
      Kind signatures and roles were added, so validate how we format them.
      For kind signatures, we follow what we do for type signatures:
      - Don't put a newline after the signature.
      - Format over multiple lines if there's a break.
      For roles, we take an approach similar to fixities:
      - Put everything on a single line no matter what.
      These definitely aren't the only way to format these new constructs, but
      it should be non-controversial to format them this way.
  3. 09 Feb, 2021 2 commits
  4. 22 Jan, 2021 4 commits
  5. 21 Jan, 2021 11 commits
  6. 20 Jan, 2021 8 commits
  7. 04 Jan, 2021 1 commit
    • Hardy Jones's avatar
      Change each goal/non-goal to a heading · b3a57fe5
      Hardy Jones authored
      We want to be able to link directly to a goal/non-goal.
      Although these are lists, most markdown processors don't automatically
      create links for each element in a list. In particular, GitLab doesn't
      make a link for each of the list items.
      Since we want links, we have at least two options:
      1. We could manually make anchor tags with our own links.
      2. We could change the markdown we use to something that generate links.
      We choose to do the second option. Maybe it's more correct semantically
      to use headings and we should have done this from the start?
      In any case, this should give us the ability to link directly to an
      individual goal/non-goal when we want to.
  8. 17 Nov, 2020 2 commits
  9. 15 Nov, 2020 2 commits
  10. 13 Nov, 2020 1 commit
    • Hardy Jones's avatar
      Use the correct `bazel` binary for `ibazel` · c327d783
      Hardy Jones authored
      We don't want to use whatever `bazel` is on the `$PATH`.
      If we don't specify `-bazel_path`, `ibazel` will use whatever `bazel` it
      finds on the `$PATH`. That means that the call to `ibazel` could use a
      version of `bazel` that would invalidate all of the building we do with
      our project-local version of `bazel`.
      To make things a bit more consistent, we specify the `-bazel_path` as
      the `bazel` we use all throughout the rest of the `Makefile`.